MXPA00004565A - File transfer system - Google Patents

Abstract

A file transfer device, system, and method are provided. The device, system, and method enable a variable number of data transfers and include an initial connection system and a data transfer system. The initial connection system establishes a connection between at least two devices via predetermined listening ports, with at least one predetermined listening port residing within each of the at least two devices. The initial connection system also dynamically assigns a first data port within a first device, and transmits the address of the first data port to a remaining device via the predetermined listening ports. The data transfer system is for each of the variable number of data transfer operations. The data transfer system dynamically assigns a corresponding second data port within the remaining device and transfers data between the connected devices via the data ports so that the data is substantially simultaneously transferred between a variable number of devices via the data ports. Each pair offirst and second data ports is established in response to each listening port connection.

Description

SYSTEM OF TRANSFER OF FILES CROSS REFERENCE TO RELATED REQUESTS This application claims the benefit of the US Provisional Patent Application, No. 60 / 065,533, in the name of Maurice Haff et al., Entitled "File Transfer System for the Direct Transfer between Computers" (No File of Attorney V16089), filed on November 13, 1997; Provisional Patent Application of E.U.A., No. 60 / 085,427, in the name of Maurice Haff et al., entitled "File Transfer System" (Proxy File No. V16057), filed May 14, 1998; and Provisional Application of E.U.A., No. 60 / 100,962, filed on September 17, 1998; whose descriptions are expressly incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to the electronic transfer of computer files, from one location to another and, more particularly, to the electronic transfer of computer files directly between two or more computers or computing devices t > 2. Antecedents of the Invention and Related Technique 5 The timely delivery of documents has been for generations of great concern for people and of great importance for their business interests. The methods to make the timely delivery of documents has progressed to include physical delivery on the same day / The next day, using international and local airways and roads, as well as electronic delivery using interconnected networks of computers and telecommunications equipment around the world. The complex logistic systems have been erected therefore the government as commercial enterprises, to perform the physical, relatively secure delivery of documents from the sender to the receiver. Examples include overnight express mail, offered by the US Postal Service, and express delivery service provided by companies private, such as the Federal Express, United Parcel Service and DHL. The charges for the delivery services provided are typically based on fixed charges (per delivery), with payment at the time the service is executed, or through an account previously agreed with the service provider or a credit provider of the service. • a third party (for example, the VISA credit card or Master Card). The complexity of these systems and the physical resources mobilized to support the timely transfer service are relatively expensive, with costs being passed on to the user of the service. The networks extensive interconnected computers and telecommunications equipment have been developed with the interest of decreasing the cost of communications, as well as accelerating more the transfer of information between the sender and receiver. To some extent, evolution from physical delivery to electronic document delivery has been successful, as is evident from the growth in the use of personal computers (PC), intra-networks and extra-networks of the Internet and private, albeit at the expense of the relative security of the transfer of documents.

Examples of electronic transfer mechanisms in use through computer networks include electronic mail (e-mail) and file transfer protocol (FTP), both widely used on the Internet. Examples of electronic transfer mechanisms in use through the telephone network connected to the public (PSTN) include [• facsimile transmissions, as well as file transfer 5 using modems and various modalities of computer programs that enable data communications between computers. Hybrid systems are also used to provide remote access to files stored in network servers. These hybrid systems typically employ specialized communications servers connected in a local area network and interconnected to a counterpart communication server in another local area network through a public network, such as the Internet. Alternatively, a remote PC may be allowed to register to a communication server, using the connection marked through the PSTN. Often referred to as "virtual private networks" or VPN, these hybrid systems typically employ encrypted techniques to create relatively secure data packets, for transmission through client-server connections through public networks. An example of a VPN product is Alta Vista, a software product (program), available from Digital Equipment Corporation. Approaches, as incorporated into physical systems and electronic document delivery, exhibit a number of drawbacks. While they are relatively safe, express mail and delivery services are slower and more expensive to the sender than many electronic delivery alternatives. With electronic transfers over networks, more immediate delivery of documents, data files, images and drawings can be achieved. However, these methods generally employ intermediary computers in the form of e-mail servers, FTP servers and Web servers. These intermediate computers reduce the relative security and time linearity of the transfers made, because neither the sender nor the receiver controls the intermediary server. Likewise, the intermediary servers themselves require significant administration and usually require registration procedures and passwords or passwords in an attempt to overcome the security problems, notwithstanding the user's convenience expense and the complexity of the system. In addition, these intermediate computers represent concentrated points of possible failures, as well as "bottlenecks" in the communication, which establish the capacity limits for the collective number and size of the transferred files. Examples of approaches that e-mail servers employ are cc: Mail, available from Lotus Development Company, and Microsoft Mail, available from Microsoft Corporation. An example of a system that uses FTP servers and Web servers for IP networks is Netscape Navigator, available from Netscape Communications Corporation. Each of these systems requires intermediary computers that function as servers to store text messages or document files for later retrieval by the intended recipient. All these systems require user registration to a server and downloading files. Thus, the direct transfer of a specific file from a sending PC to a specific receiver on a receiving PC is not enabled by these systems, nor is the simultaneous exchange of files between the multiple computers.

A variation of the mail concept is manifested in a file transfer service, recently introduced, called "e-Parcel", available on the Internet of Mitsubishi America. The "e-Parcel" is a paid subscription service, which uses client-server connections through the Internet. A similar system, named "NetDox", is available from NetDox, Inc. Both of these products use the client's software to provide automatic registration to a mediator server, which then sends a file transferred to a registered receiver, when the receiver is registered in the mediator server. Email addresses are used to create unique identifiers for each registered user for file guidance and for billing purposes. However, the direct transfer of a file from the sender to the receiver without registration to the forwarding server is not possible in server-based media systems, such as e-Parcel or NetDox. Another drawback of server-based systems is that they are limited in terms of the number of file transmissions that can be processed simultaneously, and the magnitude of the files that can be collectively stored during any given period of time. The capacity of the server must be increased proportionally, at a significant cost, as the number of users and the use of the system increases. Another limitation of storage and forward sending servers (mediated transfer) is that the concentration of transmitted files represents a point of failure of the system level, which increases the risks of both security and reliability. In any document delivery system, a manageable method, physical or electronic, to obtain payment for the services provided to the user is a critical element for success. In physical delivery systems for timely service, payments are often made for billing charges accrued monthly, with account numbers being recorded on a "flyer" that accompanies the document package. A record of the transaction must be captured, usually by a manual process, and entered into a computer accounting system. The Postal Service of the United States of America (USPS), like other national postal systems, has long offered mechanical postage meters to place "measured stamps" on envelopes to be sent by mail. These mechanical postage meters must be taken by the user in a "post office" that is going to reestablish. This enables the postal service to obtain payment for future services that will be delivered. A variant of the traditional postal meter is an electronic postage meter of newer technology, offered by Pitney Bowes, Inc., named "PERSONAL POST OFFICE" ®. This electronic postage meter can be re-established over phone lines with charges made to the Pitney Bowes account "POSTAGE BY PONE" ®. Piney Bowes also offers a "Post Office for PC" product, which makes it possible to "measure" the postal marks that will be printed on envelopes, which a personal computer printer uses. A peripheral device attached to the personal computer serves as the postal depository, with the postage downloaded through the modem over the telephone lines. The payment of the service provided by e-Parcel is by means of a monthly charge with a previously agreed fixed rate, with the charge being determined based on the record in the projected use and the size of the transmission files. An alternative payment plan, paid for in the transfer service, has been published and a fee is charged for each file sent through the e-Parcel server. Payment for the service provided by NetDox, Inc., is through the software licenses of the NetDox server. United Parcel Service, Inc. (UPS) has announced a mediated electronic document file delivery service, based on the NetDox product, and also based on another product based on the warehouse and forward server, called "Posta", available from Tumbleweed Software, Inc. The UPS system is represented as being an electronic document delivery service for which the user establishes a billing account that will be charged for each document file sent through the UPS servers. Facsimile transmissions through the PSTN, according to the facsimile rules of the CCIPP Group 3, are relatively direct, immediate and secure from interception by a third party. However, facsimile transmissions may have a multitude of transmission addresses and process problems for both the sender and receiver. For facsimile transmissions, the "service providers" are the local and long distance telephone companies, which charge the connection time required to send a fax. Examples of devices that use the CCITT Group 3 facsimile transmission standards, are widely deployed face machines, available from a multitude of manufacturers, such as Hewlett Packard Corporation and Panasonic Corporation. Additional examples of devices that employ the Group w facsimile standard are widely deployed PC fax modems, available from manufacturers, such as the US Robotic Corporation. Both fax machines and fax-modems communicate in the PSTN. An emergency technology in the transmission of fax images over the Internet. While fax devices enable the direct transmission of a specific document image, from a sender to a specific receiver, transmissions are not in the original file format of the transmitted document and typically suffer from degraded visual quality. PC fax transmissions result in very large file size impulse requirements, for a large storage capacity.

Unlike facsimile image transmissions, electronic file transfers over networks or through the PSTN, which uses modems, can supply the document files to the receiver in the native format, with text, graphics, drawings, video or sound These files can contain large format drawings, or documents that occupy a large page. Unlike e-mail with attachments, file transfers generally have no problems with non-predictable delivery, mail server security by a third party, or file attachment compatibility. However, mediated file transfer, which uses client / server communication through global networks, requires registration to a network server and may have security risks, when access is allowed to remote users or a third party. part not related in organization. File transfers through the PSTN, which uses modems and previous communication architectures, with accompanying computer programs, generally require user attention to effect the transfer between the PCs. Alternatively, remote control of a PC from another PC, with the inherent security risks, is allowed. Thus, all the mechanisms in the prior art that perform the electronic transfer of files, through the Internet, or intra-networks or extra-private networks, or through the PSTN, require multiple stages of process and a significant degree of training of the user. An example of an approach designed to provide the user with access to document files through a network is described in U.S. Patent No. 5,634,057. This patent describes sets of groups, in which multiple users are registered to a network and can collaborate interactively with respect to various aspects of the documents, such as form and content. Typically, groups suffer from their own complexity of use and do not enable the direct transmission of a specific file from one PC to another, or the simultaneous exchange with multiple PCs. Another example of an approach that achieves file transfers directly from a sending PC to a receiving PC through a PSTN, and, in some cases, through the Internet, is a class of products described as "remote products". Within this category, specific products, such as "pcAnywhere", available from Symantec Corporation, enable a user to register from one computer to another and effectively take control of the operation and stored files of the computer on which it was achieved. register. However, the direct transfer of the files without the risk of a third party's security, registration and control, is not provided. Additionally, products such as "DynaComm", available from FutureSoft Engineering, Inc., are designed to provide access to the marked terminal to servers and computers in the main board through the PSTN. These products are also typically capable of direct transfer from one PC to another of the files, when a PC operator is available and ready for both the sending and receiving PC, to re-establish the parameters and conditions under which the PC will be made. transfer. Another example of an approach that enables the transmission of a single file from one PC to another, interconnected to a network of Transmission Control Protocol / Internet Protocol (TCP / IP), is a demonstration computer program named "Wormhole". ", available on the Internet from Microsoft Corporation. The purpose of this free computer program is to demonstrate how a sleeve data structure works under the Microsoft Windows operating system. This demonstration program is able to send only one file to only one PC at an IP address manually entered. No restrictions can be placed on when or where the files can be transmitted, not from whom they are received. The simultaneous exchange of files with more than one PC is not enabled or suggested. Likewise, no communication from the PSTN and no error verification or verification of the file transfer is provided. Also, there is no indication of where the files originate is supplied. In addition, no communication or file control is provided. Similarly, it is not possible to request a file from a PC operator to the Wormhole computer program, nor is it any form of file transport security provided. Another example of an approach that enables direct communication from one PC to another, through the PSTN, developed by the present applicant, is the AEGIS Document Image System (ADIS). In ADIS, document handling and communication functions are integrated E »to provide a system for creating a virtual PC network 5 interconnected through the PSTN. In addition to PC equipment capable of forming images, the ADIS requires a specific communication hardware (equipment) (for example, SatisFAXtion 400, fax-modem developed by Intel Corporation, available from Puré Data, Ltd., Notary, Canada), and uses a file transfer mechanism built into the SatisFAXtion board, controlled by the ADIS computer program. No capacity of file transfer through the PSTN using Hayes compatible data modems of the standard deployed widely, or through a TCP / IP network, is included in ADIS. Also, file requests can be made from an ADIS station by another ADIS station, but file requests can not be restricted to a specific station. 20 Another drawback of these conventional systems is that the polling of a remote computer, when such capacity is present, occurs seriously. This requires a long time to receive many files from many different destinations, particularly if one of the destinations is busy, causing the computer to poll to repeatedly try to contact the destination before the end time out. Another example of a known file transfer system is DropChute +, available from Hilgraev, Inc., of Monroe Michigan. Drop Chuten- uses only one door, thus limiting communication to another computer in a moment. DropChute + can not communicate simultaneously (parallel transfer files) with one or more other computers. Also, with DropChute + all transfers and commands take place in a single door. If more than one event is going to happen, all the events are multichannelized through a single door. Also, if a user wants to send a file to a group of destinations, there is simply no way to do it under this DropChute +. Thus, there is a need for a system that provides immediate and secure delivery of documents from the sender to the receiver, which retains the positive aspects of the prior art, but does not have its disadvantages.

SUMMARY OF THE INVENTION In view of the foregoing, the present invention is directed to providing a communications system for effecting the electronic transfer of peer to peer computer files between the PCs through the Internet, intra-networks and extra-private networks and the PSTN. File transfers are by means of the Internet, intra-networks or private extra-networks and the PSTN, without registration to the remote computer and without intermediary storage of the files in an intervening computer. The present invention enables simultaneous transfers and incorporates functions that include the certified return receipt for the transported files, the initiation of transport directly from any related application program and mechanisms for making the payment to a service provider for each transported file. The present invention is further directed to provide a communication system that enables transfers between the PCs in the native format, without requiring the coding or conversion of the format of the transmitted files.

The present invention is also directed to the provision of a communications system that enables transfers between the PCs, without requiring registration to an intervening computer, in addition to establishing a communication path. The present invention is also directed to the provision of a communications system that enables file transfers between the PCs, without the need for the presence of an operator in any of the sending or receiving PCs. Thus, it enables file transfers between PCs at a programmed time predetermined by the sender. According to one aspect of the invention, it is directed to a file transfer system for transferring the files between a local computer and at least one destination computer, selected from a list of destination computers. The transfer is through at least one communication path, which includes a computer network and a telephone network connected to the public. The file transfer system includes a file selector, which selects at least one file stored on the local computer, to transfer it to at least one destination computer; a destination selector, which selects, from a list of at least one remote computer, at least one destination computer to which the file will be transferred; a transmitter, which transfers one or more selected files to one or more destination computers, by means of the communications path, without storing the selected files in any intermediate computer; and a receiver, who receives the transferred files. According to another aspect of the file transfer system of the present invention, the transmitter also includes a compressor, which compresses the files before transmission. The receiver also includes a decompressor, which decompresses all compressed files upon receipt. Preferably, the compressor compresses each file before transmission. Alternatively, the compressor only compresses the files selected by the user. The transmitter also includes an encryptor, which encrypts each file before transmission. The receiver also includes a decryptor, which decrypts each file upon receipt. In such a file transfer system, the cipher encrypts each file before transmission. According to a preferred embodiment, the file transfer system of the invention also includes a credit sufficiency verifier, which determines whether the local computer has sufficient credits to transfer each selected file. The credit sufficiency verifier allows the transmitter to operate only when sufficient credits are found. The sufficiency of credits is determined according to the established transfer costs. Also, the number of credits in the local machine is modified in each successful file transfer for a corresponding transfer cost. A number of credits available for each local computer is displayed on this local computer. The transmitter also includes a cipher, which encrypts files selected before transmission. The receiver also includes a decryptor, which decrypts each encrypted file upon receipt, in which, depending on the policy of the service provider, the number of credits in the local machine can be modified by the, minus one additional credit, in each transfer of successful file that uses encryption. Additionally, the file transfer system may also include a buyer of credits, which requires additional credits from an external source, in response to the user's request, this external source validates the user's accounting information and distributes additional credits if it is validated the accounting information. According to a preferred embodiment, the file transfer system also includes a transmission error repair, which determines the amount of a file successfully transferred when the file being transferred has been interrupted during transmission. The transmission error repairman transmits the portion of the file not yet transferred, when a connection free of errors, between the local computer and the destination computer, is established, resulting in the destination computer receiving the file without errors. According to a preferred embodiment, the file transfer system also includes a programmer, which programs the file transfer at a time selected by the user of the local computer, thus allowing the file transfer to occur without the presence of the user from the local computer. The receiver can also include a recorder that records the attributes of all file transfers. In such systems, the registrar can also inform a computer certification independent of the attributes of the file transfer, when this file transfer is successful. The registrar can also inform the local computer of the attributes of the file transfer, when this file transfer is successful. Depending on the policy of the service provider, the number of credits in the local machine can be modified by at least one additional credit in such notification of the file transfer attributes. The transmitter can simultaneously transfer files to multiple computer destinations, through separate and discrete connections, to each destination computer. Similarly, the receiver can simultaneously receive file transfers from multiple transmitters. Also, the local computer includes a receiver capable of simultaneously receiving file transfers from multiple transmitters. The transmitter is capable of simultaneously transferring files to multiple computer destinations, such that the local computer can simultaneously exchange (send and receive) any number of files with multiple computers. The receiver may also include a gatekeeper, who accepts, selectively and automatically, file transfers based on the authenticated identification of a transmitting computer. In certain preferred embodiments, the file transfer system includes an index generator, which defines an index that may be required by a remote computer, via the communication path. This index includes at least one file from which the remote computer may require a copy by means of a file transfer. In such systems, the index may also include an associated remote computer, which has exclusive access to the index. In certain preferred embodiments, the transfer of files by means of the communication path occurs without registration on any intermediate storage or sending computer forward and without registration on the destination computer. In preferred modalities, the file transfer system can perform simultaneous transfers of files contained in directories linked to specific destinations, in multiple remote computers, activating the initiation of the transfer of files in remote computers with a transfer request. According to a preferred embodiment, the criteria that can be invoked in the creation of an index include: (a) the location in the file structure, (b) the type of file, (c) date and time of the file, (d) embedded serial number and (e) destination authentication codes. In a preferred embodiment, each device includes at least one display monitor, a memory processor, a file storage device, a keyboard, an indicating device, a communication interface, and a graphically oriented operating system (windows) , which has drag and drop functionality. Each device operates a computer program to control the functions of the system and a computer program for a window operating environment. Each device is connected to the plurality of communication paths and generates a graphical user interface (GUI). A control module is also used to control GUI functions and system communications; graphic modules that require or create display windows to indicate candidate files that can be transmitted (transmission windows), candidate personal computer destinations, to which files can be transmitted (target windows) and transmitted files that have been sent or received (windows of the event record); and controls to initialize and invoke the system operation criteria through dialog windows. According to a preferred embodiment, a computer data signal, incorporated in a propagation medium, is provided. This signal enables a variable number of data transfers and includes a code segment of the initial connection source and a data transfer source code segment. This code segment of the initial connection source establishes a connection between two devices by means of predetermined listening ports, with at least one predetermined listening door residing within each device. The code segment of the initial connection source dynamically allocates a first data gate within a first device, and transmits the address of the first data gate to a remaining device by means of the predetermined listening ports. The segment of the data transfer source code is for each of the variable number of data transfer operations. This segment of the data transfer source code dynamically assigns a second data gate within the remaining device. The second data gate corresponds to the first data gate within the first device. The segment of the data transfer source code transfers the data between the connected devices by means of the data ports, so that the data is transferred substantially automatically between a variable number of devices by means of the assigned data ports dynamically. Each pair of the first and second data ports is established in response to each listening port connection.

The code segment of the initial connection source can also exchange the characteristics of the data transfer and authenticate the remaining device by verifying the identification information of the remaining device, transmitted from the remaining device. Also, the code segment of the initial connection source may include a code segment of the selective acceptance source, which compares the identification information of the remaining device with a list of destination identities stored in the first device and prohibits data transfers from devices not within the list of destination identities. In a preferred embodiment, each device simultaneously sends and receives data to and from multiple devices. The signal may also include a segment of the code of the source of return reception, which generates and sends a return reception. This return reception typically includes the point of origin, destination and complete success information, and is sent from the device that received the data transfer to the device that transferred the data at the successful completion of the data transfer.

The signal may also include a code segment of the certification source, which communicates with an independent certifying processor, which verifies the return receptions for the originating point, destination and successful completion information. The independent certification processor sends the verification certification to the device that originated the data transfer in the successful completion of the data transfer. The code segment of the return receiving source also generates and sends a return receipt from the device that received the data transfer to the independent certifying processor at the successful completion of the data transfer. The sleeve data structures are preferably dynamically handled and each data port is represented by a sleeve data structure. In addition, each device can store the sleeve data structures in a linked list, in order to handle the flow of data transfers. The linked list is crossed to enable data transfers substantially simultaneously.

The signal may also include a segment of the credit source code, which maintains and monitors the credits of the data transfer and detects each data transfer in order to deduct credits from a credit account, after a successful transfer of credit. data. Data transfer is only allowed when the device initiating the transfer has sufficient credits. According to a preferred embodiment, the data transfer occurs without registration on any intermediate computer in addition to those that establish a communication path, without registration on the destination computer and without intermediate storage of the data transferred on an intervening computer. According to a preferred embodiment, a transmission device includes an encryption source code segment, which encrypts data selected before transmission. In addition, a receiving device includes a code segment of the decryption source, which decrypts each encrypted file upon receipt. The credits of the data transfer comprise a defined number of credits. This number of credits in the transmission device is modified by at least one additional credit in each successful data transfer using encryption. The signal may also include a code segment of the credit application source requesting additional credits from an external credit processor, in response to a request for additional credits from a device. The external credit processor validates the information on the application device account and distributes additional credits if this account information is validated. The signal may also include a segment of the code of the index source, which defines an index for the request by remote devices by means of a connection. This index is associated with at least one destination and lists the representative information of at least one file that remote devices can request. The devices that correspond to the associated destination have exclusive access to the index. A code segment of the index request source can be provided, which allows the requesting device to select a particular remote device to which a request for an index will be sent. The request is sent to a selected remote device. In response to the request, the remote device returns the index to the requesting device. Then, the request device stores the index in a storage device. A code segment of the index transfer source can also be provided, which, in response to each file listed in the index, is selected by the request device, allows the requesting device to request a copy of the selected file that will be transferred from the remote device. This remote device transfers each file in response to the request. The code segment of the initial source can also establish more than one connection, with each connection being between two devices via a different pair of listening ports. In this case, each device selects listening doors from a predetermined range of available doors. Each device can also include a variable number of linked destination directories, which are associated with another device. Each destination linked directory is a file storage area on the device. A code segment of the destination linked directory management source is then provided, which detects the storage of at least one data file in the destination linked directory and initiates a transfer of the detected data file to the associated device in response to detection. The signal may also include a code segment of the active connection monitoring source, a code segment of the validation source and a code segment of the inspection source. This code segment of the active connection monitoring source periodically determines whether each remote device in a list of at least one remote device, is currently actively connected to a communication path, accessible to a local device. The code segment of the validation source validates each remote device in the list of at least one remote device, which is currently actively connected to the communications path, accessible to the local device. The code segment of the inspection source delegates a file transfer at a time when the target device becomes actively connected to the communication path, accessible to the local device, if the selected target device is not currently actively connected to the communication path accessible to the local device. The signal may also include a code segment of the parallel source of scrutiny, which causes a local device to collect a directory on at least one of the remote devices. The directory is associated with an assigned destination. The local device requires that all data within the directories be transferred to the local device. Thus, multiple remote devices are collected substantially simultaneously and data is transferred substantially simultaneously to the local device from all remote devices. In addition, the data is transferred to the assigned destination. A file transfer method is provided, which enables data transfers between a local device and at least one remote device. The method includes establishing a connection with this at least one remote device by means of previously established listening ports, which reside within each device. Also, the method includes dynamic allocation of a data gate within the local device, with each data gate within each device enabling data transfer; and transmitting the address of the data gate to the remote device, by means of the listening doors. The method makes it possible to transfer the data between the connected devices by means of the data ports, so that the data is transferred, substantially simultaneously, between multiple remote devices and the local device by means of dynamically assigned data ports. The method also includes, after establishing the initial connection, receiving the characteristics of the data transfer and authenticating the remote device by verifying the identification information of the remote device. The identification information is transmitted from the remote device. In addition, there is a comparison of the identification information of the remote device with a list of destination identities, stored in the local device. Transfers of data from devices not within the list of destination identities are prohibited. According to a preferred embodiment, the local device sends and receives substantially simultaneously these data.

The method can also include the generation and sending of a return receipt, which includes the point of origin, destination and successful termination information, from a device that received a data transfer to a device that transferred the data after successful completion. of data transfer. In addition, the method may also include communication with an independent certifying processor that verifies the return receipts for the point of origin, destination and successful termination information. The independent certifying processor sends a verification certification to a device that originated the transfer of data in the successful completion of the data transfer. Thus, the device that received the data transfer generates and sends a return receipt to the independent certifying processor at the successful completion of the data transfer. Preferably, the spike data structures are driven dynamically and each data port is represented by a sleeve data structure. In addition, each device can store the sleeve data structures in a linked list in order to handle the flow of data transfers. The linked list is crossed to enable data transfers substantially simultaneously. The method may also include requesting additional credits from an external credit processor, in response to a request from a device for additional credits. In this case, the external credit processor validates the accounting information of the requesting device and distributes additional credits if this accounting information is validated. The method can also include the definition of an index, which can be requested by remote devices through the initial connection. This index includes at least one file that the remote computer can request a copy of the data transfer path, and an associated destination. This associated destination is a specific destination, and devices that correspond to the specific destination have exclusive access to the index. The associated destination can alternatively be a general destination, so any remote device has access to the index. A request device can be allowed to select the remote device, where a request for an index will be sent. When the request is sent to the selected remote device, this remote device returns the index to the requesting device and this requesting device stores the index on a storage device. When any file listed in the index is selected by the requesting device, this requesting device requests that a copy of the selected file be transferred from the remote device. In response to the request, the remote device transfers each file. According to a preferred embodiment, each device may include a variable number of linked destination directories, each associated with another device. Each destination linked directory is a file storage area on the device or accessible to the device. In this case, the method also includes detecting the storage of at least one data file in the destination linked directory and initiating a transfer of the detected data file to the associated device, in response to detection. According to a preferred embodiment, the method also includes periodically determining whether each remote device in a list of at least one remote device is currently actively connected to a communication path accessible to a local device; validate each remote device in the list of at least one remote device, which is currently actively connected to the communication path accessible to the local device. A file transfer is delegated to a moment when the target device becomes actively connected to the communication path accessible to the local device if the selected target device is not currently actively connected to the communication path, accessible to the local device. According to a preferred embodiment, the method also includes polling a directory on at least one of the remote devices (the directory is associated with an assigned destination) and requesting all data within the directory to be transferred to a local device. Thus, the multiple remote devices are probed substantially simultaneously and the data is transferred substantially simultaneously to the local device from all the multiple remote devices. In addition, the - data is transferred to the assigned destination. The established connection can include more than one connection, with each connection being between two devices by means of a different pair of listening ports. In this case, each device selects the listening doors from a predetermined range of available doors. Another method of file transfer is provided, which makes it possible to transfer data between a local device and at least one remote device. The method includes establishing a connection to the remote device by means of previously established listening doors, which reside within each device; receiving an address of a first data gate from the remote device by means of the listening ports; dynamically assigning a corresponding second data gate (corresponding to the first data gate within the remote device) within the local device, each data gate within each device enables data transfer, and transferring data between connected devices through the data gates. Thus, the data is transferred substantially simultaneously to multiple remote devices through the dynamically assigned data ports. After establishing the connection, the characteristics of the data transfer can be transmitted. In addition, each local device can send and receive, in substantially simultaneous form, data to and from multiple devices. The method may also include the generation and sending of a return receipt, which includes the point of origin, destination and successful termination information, from a device that received a data transfer to a device that transfers data upon successful completion of this data transfer. In addition, the method may also include communication with an independent certifying processor that verifies the return receipts from the point of origin, destination and successful completion information. The independent certifying processor sends a verification certification to a device that originated the data transfer in the successful completion of this data transfer. Thus, the device that received the data transfer generates and sends a return receipt to the independent certification processor in the successful completion of the data transfer. Preferably, the sleeve data structures are dynamically handled and each data port is represented by a sleeve data structure. Also, each device can store the sleeve data structures in a linked list, in order to handle the flow of data transfers. The linked list is crossed to enable data transfers substantially simultaneously. The method may also include maintaining and monitoring the credits of the data transfers and detecting each data transfer in order to deduct a credit from the credit account, after a successful transfer of data. This data transfer is only allowed when the device that initiates the transfer has sufficient credits. The method may also include requesting additional credits from an external credit processor, in response to a request for a device for additional credits. In this case, the external credit processor validates the accounting information of the requesting device and distributes additional credits if the accounting information is valid. The method can also include defining an index that can be requested by remote devices through the initial connection. This index includes at least one file that the remote computer can request a copy of the data transfer path, and an associated destination. A request device can be allowed to select the remote device where a request for an index will be sent. When the request is sent to the selected remote device, this remote device returns the index to the device that requests it, and the device that requests it stores the index in a storage device. When any file listed in the index is selected by the request device, this device requests that a copy of the selected file be transferred from the remote device. This remote device transfers each file in response to the request. According to a preferred embodiment, each device may include a variable number of linked destination directories, each one associated with another device. Each destination linked directory is a file storage area on the device or accessible by the device. In this case, the method also includes detecting the storage of at least one data file in the linked directory of the destination and initiating a transfer of the detected data file to its associated device, in response to detection. According to a preferred embodiment, the method also includes periodically determining whether each remote device in a list of at least one remote device is currently actively connected to a communication path accessible to a local device.; and validate each remote device in the list of at least one remote device, which is currently actively connected to the communication path accessible to the local device. A file transfer is delegated to a moment when the destination device becomes actively connected to the communication path accessible to the local device if the selected destination device is not currently actively connected to the communication path accessible to the local device. According to a preferred embodiment, the method also includes polling a directory on at least one of the remote devices (the directory is associated with an assigned destination) and requesting that all data within the directory be transferred to a local device. Thus, multiple remote devices are probed substantially simultaneously, and data is transferred substantially simultaneously to the local device from all multiple remote devices. In addition, the data is transferred to the assigned destination. A file transfer device is provided, which transfers the data with at least one remote device. The data transfer device includes at least one listening gate, through which a control connection is established with the remote device. The control connection is used to determine a remote data gate for data transfer, each data gate makes data transfer possible. At least one data gate, dynamically assigned, is for the data transfer with the remote data gate, the data being transferred substantially simultaneously with multiple remote devices by means of dynamically assigned data ports. The control connection can also be used to exchange the characteristics of the data transfer. In addition, each device can send and receive, substantially simultaneously, data to and from multiple devices. The file transfer device may also include a return receipt system, which generates and sends a return receipt. This return receipt typically includes the point of origin, destination, and successful termination information, and is sent from the device that received the data transfer to the device that transferred the data upon successful completion of the data transfer. The data transfer device may also include a certification system, which communicates with an independent certifying processor, which verifies the return receipts to the destination point of origin and successful termination information. The independent certifying processor sends verification certification to the device that originated the transfer of data to the terminal successfully this data transfer. to? The return receipt system also generates and sends a 5 return receipt from the device, which received the data transfer to the independent certification processor, upon successful completion of the data transfer. Preferably, the data structures of cuffs are driven dynamically and each data port is represented by a cuff data structure. In addition, each device can store the sleeve data structures in a linked list, in order to handle the flow of data transfers. The list linked is cross-enabled to enable data transfers substantially simultaneously. The file transfer device may also include a credit system, which maintains and monitors the data transfer credits and detects each data transfer in order to deduct credits from the credit account after a successful transfer of data. Data transfer is only allowed when the device initiating the transfer has sufficient credits. The number of credits available for the device can be displayed dynamically on the device. According to a preferred embodiment, a transmission device includes an encoder system, which encodes selected data before transmission. In addition, a receiving device includes a decoder system, which decodes each encoded file in the reception. The credits of the data transfer comprise a defined number of these credits. The number of credits in the transmission device is modified by at least one additional credit in each successful data transfer using coding. The file transfer device may also include a credit application system, which requests additional credits from an external credit processor, in response to a request for additional credits from a device. This external credit processor validates the account information of the requesting device and distributes additional credits if the account information is valid.

The file transfer device may also include an index system, which defines an index requested by the remote devices by means of the initial connection. This index is associated with at least one destination and lists the representative information of at least one file, which remote devices can request. The devices that correspond to the associated destination have exclusive access to the index. An index request system can be provided, which allows a requesting device to select a particular remote device, to which a request for an index will be sent. The request is sent to the selected remote device. In response to the request, the remote device returns the index to the requesting device. Then, the request device stores the index in the storage device. An index transfer system can also be provided, which, in response to each file listed in the index, is selected by the requesting device, allows the requesting device to require a copy of the selected file to be transferred from the remote device. This remote device transfers each file in response to the request. Each device can include a variable number of linked destination directories, each associated with another device. Each destination linked directory is a file storage area on the device or accessible by the device. A destination linked directory management system is then provided, which detects storing at least one data file in the destination linked directory and initiates a transfer of the detected data file to the associated device, in response to detection. The file transfer device may also include a paging system, which causes a local device to poll a directory on at least one of the remote devices. The directory is associated with an assigned destination. The local device requests all the data within the directory, which will be transferred to the local device. Thus, multiple remote devices are probed substantially simultaneously, and data is transferred substantially simultaneously to the local device from all remote devices. In addition, the data is transferred to the assigned destination. Another transfer device is supplied ("Files, which transfers the data with at least one remote device." The data transfer device includes at least one listening gate, which receives a control connection from at least one remote device.) The device also includes at least one data gate, dynamically assigned, for data transfer with the remote device, each data gate enables data transfer. The control connection is used to transmit the address of at least one data gate dynamically assigned. Thus, the data can be transferred in a substantially simultaneous manner with multiple remote devices, by means of dynamically assigned data ports. The control connection can also be used to receive the data transfer characteristics and authenticate the remote device, verifying the identification information of the device remote. This identification information is transmitted from the remote device. Each device can send and receive, substantially simultaneously, data.

The control connection may also include a selective acceptance system that compares the remote identification information of the device with a list of destination identities stored in the first device or prohibits data transfers from devices that are not within the identity list. of destiny. The file transfer device may also include a return receipt system, which generates and sends a return receipt. This return receipt typically includes the point of origin, destination and the successful termination information, and is sent from the device that received the data transfer that transferred the data upon successful completion of the data transfer. The file transfer device may also include a certification system, which communicates with an independent certifying processor, which verifies the return receipts for the point of origin, destination and successful completion information. The independent certifying processor sends certification verification to the device that originated the data transfer upon successful completion of the data transfer. The return receipt system also generates and sends a return receipt from the device that received the data transfer to the independent certifying processor, upon successful completion of the data transfer. Preferably, the sleeve data structures are dynamically handled and each data port is represented by a sleeve data structure. In addition, each device can store the sleeve data structures in a linked list, in order to handle the flow of data transfers. The linked list is crossed to substantially enable data transfers simultaneously. The file transfer device may also include a credit application system, which maintains and monitors the credits of the data transfer, and detects each data transfer in order to deduct a credit from the credit account after a transfer of successful data. Data transfer is only allowed when the device initiating the transfer has sufficient credits. A number of credits available from the device can be displayed dynamically on the device.

According to a preferred embodiment, a transmission device includes an encoder system, which encodes the selected data before transmission. In addition, a receiving device includes a decoder system, which decodes each encoded file upon receipt. The data transfer credits comprise a defined number of credits. The number of credits in the transmission device is modified by at least one additional credit in each successful data transfer, which uses coding. The file transfer device may also include a credit application system that requests additional credits from an external credit processor in response to a request for additional credits from a device. The external credit processor validates the accounting information of the requesting device and distributes additional credits if the account information is valid. The file transfer device may also include an index system, which defines an index requested by the remote devices by means of a connection. This index is associated with at least one destination and lists the representative information of at least one file, which remote devices can request. The devices that correspond to the associated destination have [• exclusive access to the index. A 5-index request system can be provided, which allows a requesting device to select a particular remote device, to which a request for an index will be sent. The request is sent to the selected remote device. In response to the request, the remote device returns the index to application device. Then, the request device stores the index in the storage device. An index transfer system can also be provided, which, in response to each file listed in the index, is selected by the requesting device, allows the requesting device to require a copy of the selected file to be transferred from the remote device. This remote device transfers each file in response to the request. Each device can include a variable number of linked destination directories, each associated with another device. Each destination linked directory is a file storage area on the device or accessible by the device. A destination linked directory management system is then provided, which detects storing at least one data file in the destination linked directory and initiates a transfer of the detected data file to the associated device, in response to detection. The file transfer device may also include a parallel polling system, which causes a local device to poll a directory on at least one of the remote devices. The directory is associated with an assigned destination. The local device requests all the data within the directory, which will be transferred to the local device. Thus, multiple remote devices are probed substantially simultaneously, and data is transferred substantially simultaneously to the local device from all remote devices. In addition, the data is transferred to the assigned destination. The file transfer device may also include an active connection inspection system, which periodically determines whether each remote device in a list of at least one remote device is currently actively connected to a communication path accessible to a local device; a validity system, which validates each remote device in the list of at least one remote device, which is currently actively connected to the communication path accessible to the local device; and a surveillance system that delegates a file transfer to a moment when the destination device becomes actively connected to the communication path, accessible to the local device, if the selected destination device is not currently actively connected to the communication path, accessible to the local device. A data file delivery system is provided to deliver data files among a variable number of devices. This data file delivery system includes a variable number of similar systems. Each similar system has a connection negotiation system, to open at least one listening door for exchanging control data. Each similar system also includes a data connection system to open a variable number of data ports, each associated with a destination, to exchange data files; a file selection system, to select a variable number of data files, which resides in at least one such system, designed as a source of files; and a destination selection system, to select a variable number of destinations to receive the selected data files. At least the file source has a transmission system, for sending without storage of the selected data files in a variable number of data communications paths, which corresponds to the data gates. The destinations each have a receiving system to receive, without storage, the files sent without storing them. At least the source of files or the destination has a start system to start the operation of the transmission system, by means of at least one path that negotiates the communications, which corresponds to at least one listening door, from or the source of files or the destination. Each file source is also a destination that has a receiving system to receive, without storage, the files sent without storing by at least one other such system, which acts as a subsequent source of files at the same time as the transmission system operates . Each such system may also include a variable number of linked destination directories, each associated with another device. Each destination linked directory is a file storage area on the device or accessible to the device. Each such system may also include a target linked directory management system, to detect the storage of at least one data file in the corresponding file storage area and to control the system initiating the operation of the transceiver system (transmitter). receiver) in response to detection. Each such system may also include a return receipt system to generate and send a return receipt that includes the point of origin, destination and successful termination information, from each similar destination system that receives the selected files to the similar system of file source, on the communications path, without storage, which corresponds to the data ports in the successful completion of the reception, without storage, of the selected files. The system may also include a third-party transaction certificate processor, to examine and verify the return receipts for the originating point, destination and successful completion information. The processor of the third party transaction certificate is also for sending the verification certificate data files on a further first communication path, without storage, which corresponds to a first additional data gate to the similar file source system in the successful completion of the reception without storage of the selected files. The return receipt system generates and sends a return receipt from each similar destination system, which receives the selected files to the processor of the third party transaction certificate, in a second communication path, without storage, corresponding to a second Additional data gate in the successful completion of the reception without storage of the selected files.

Each similar system may also include a file credit inspection system to maintain and monitor file delivery credits. This file credit monitoring system detects each shipment, without storage, of selected files and deducts a credit from the variable account in a similar associated system, according to the function based on the shipment, without storage. The system may also include a credit processor to receive credit applications and to increase the variable credit account in a similar system associated with receiving a credit application and successfully comparing the credit application against a credit authorization function. The file credit monitoring system generates and sends a credit request from one of the systems similar to the credit processor. Each similar system can also include an index generator system, to generate a file index in a similar system; a system that requests an index, to request and recover a file index from any of the variable number of similar systems; a subset selection system, to select a subset of a variable number of files from the retrieved index of files from any of the variable number of similar systems; and a file subset request system, to initiate the operation of the transceiver system to transfer the subset from any of the variable number of systems similar to this system. Each such system may also include a transceiver management system for handling substantially parallel and simultaneous operations of a variable number of transceiver systems for substantially parallel and simultaneous sending, without storage, and receiving, without storage, the selected files in a plurality of communication paths corresponding to a plurality of data ports. The transfer of data through the communication path, occurs without registration on any intermediate computer in addition to those necessary to establish the communication path, without registration on the destination computer and without intermediate storage of the files transmitted on a computer intervener. The connection to the destination via the data port is to a destination address received with the control data. According to a preferred embodiment, when a file is saved in a predetermined directory, associated with a destination, this file is transferred to the destination. Another file transfer system is provided, for transferring the files between at least one local computer and at least one remote computer, selected from a list of at least one remote computer, through at least one communication path. The file transfer system includes a file selector that selects at least one file stored on the local computer to transfer this at least one remote computer; a destination selector, which selects, from the list of at least one remote computer, at least one remote computer designed as a destination computer to which the file will be transferred; a transmitter, which transfers the selected file to the destination computer through the communications path, without storing the selected file in any intermediate computer; and a receiver, who receives the transferred file.

The system also includes an initial connection system, which establishes a connection between the local computer and the target computer, by means of the predetermined listening ports. At least one predetermined listening door resides within each computer. The characteristics of the data transfer are exchanged during the initial connection. The identities of the local and destination computers are authenticated by verifying each computer identification information. The system also includes a first dispatcher, which dynamically allocates a first data gate, represented by a sleeve data structure, within the target computer; a first transmitter, which transmits the address of the first data port to the local computer, by means of the predetermined listening ports; a second dispatcher, which dynamically allocates a second data gate, represented by a sleeve data structure, inside the local computer, which corresponds to the first data gate enters the destination computer, each pair of first and second doors Data is assigned dynamically in response to each listening gate connection; and a second transmitter, which transfers the data between the computers connected through the data ports. The data is transferred substantially simultaneously between a variable number of computers by means of dynamically assigned data ports. Each computer is able to send in substantially simultaneous form and receive data. Each computer dynamically manages data structures of the sleeve to enable data transfers substantially simultaneously. The system also includes a generator, which generates and sends a return receipt, which includes the point of origin, destination and successful termination information, from the computer that received the data transfer to the computer that transferred the file, and a Independent certification processor in the successful completion of the file transfer. The system also includes a third transmitter, which communicates with the independent certification processor, which verifies the return receipts for the point of origin, destination and the successful termination information. The independent certification processor sends the certification of the verification to the computer, which originated the transfer of files, on the successful completion of the file transfer. The system also includes a credit system, which maintains and monitors file transfer credits and detects each file transfer in order to charge to the credit account after the successful transfer of files. This file transfer is only allowed when the computer initiating the transfer has sufficient credits. The system also includes a credit application system, which requests additional credits from an external credit processor, in response to a request from a computer for additional credits. The external credit processor validates the accounting information of the computer that requests and distributes additional credits, if this accounting information is validated.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention is further described in the following detailed description, with reference to the drawings mentioned and by way of non-limiting examples of the preferred embodiments of the present invention, in which like reference numbers represent similar parts throughout. of the various views of the drawings, and in which: Figure 1 is a schematic block diagram, illustrating a system architecture with a limited number of personal computers connected to various communication paths, according to an aspect of the invention. present invention; Figure 2 is a flowchart of an exemplary logic of a main control module, which controls the automatic functions and functions invoked by the user, with access through a graphical user interface, in accordance with an aspect of the present invention; Figures 3A and 3B are flow charts of the exemplary logic of a file sending module, which controls the file transmission functions, in accordance with an aspect of the present invention; Figures 4A, 4B and 4C are flow charts of the exemplary logic of a file receiving module, which controls the file functions, in accordance with an aspect of the present invention; Figure 5 is a flow diagram showing exemplary logic for confirmation of the reception request process, in accordance with an aspect of the present invention; Figure 6 is a flow diagram of the exemplary logic of an index creation module, which creates an index of files that the user wishes to have available for his request from another PC, in accordance with an aspect of the present invention; Figure 7 is a flowchart of the exemplary logic of a file request module, which creates a pending file request event in the main control module, in accordance with an aspect of the present invention; Figure 8 is a flowchart of the exemplary logic of a requested file module of return, which processes the requests of one or more files, or an index, and creates pending events to return the files or indexes requested in the module main control, according to one aspect of the present invention; Figure 9 is a flowchart of the exemplary logic of a module of requested credits, which collects the accounting information and the number of file transmissions to be authorized, and creates a pending application for authorization in the main control module, according to an aspect of the present invention; Figure 10 is a flowchart of the exemplary logic of a credit application process module, operating in a credit server, in accordance with an aspect of the present invention; Figure 11 is a flowchart of the exemplary logic of a credit addition module, which increases any remaining credit by the amount of new authorized credits, in accordance with an aspect of the present invention; Figure 12 is a flowchart of the exemplary logic of the credit removal module, which decreases the credits by the amount of the transfer cost, in accordance with an aspect of the present invention; Figure 13 is a flowchart of the exemplary logic for a check of the active connection module, which periodically checks the active connections for each address list in the destination window, in accordance with an aspect of the present invention; Figure 14 is a flowchart of exemplary logic for a third-party authentication process of confirmation of receipt requests, in accordance with an aspect of the present invention; Figure 15 shows an example of an event registration window, which records events of transmission and reception of files, according to an aspect of the present invention; Figure 16 illustrates an example of an event property window, showing the properties and listed files of events present in the event log file, in accordance with an aspect of the present invention; Figure 17 illustrates examples of the transmission window, for selecting files to be transferred, and the destination window, for selecting destinations to be transferred to the file, in accordance with an aspect of the present invention; Figure 18 shows an example of an add / edit destination window for adding and editing the destination addresses, in the destination window, according to an aspect of the present invention; Figure 19 shows an example of a destination window selection, to select the destination for file transfer and the initiation of file transfer, in accordance with an aspect of the present invention; Figure 20 shows alternative examples of a transmission window, to select files for the transfer, and the event properties window, which shows the properties and files listed of the events present in the event log file, according to an aspect of the present invention; Figure 21 shows alternative examples of a transmission window, to select transfer files, and the event properties window, which show the properties and the listed files of events present in the event log file, according to an aspect of the present invention; Figure 22 shows an example of a constructed index window for creating the index of files that can be requested by a destination PC, in accordance with an aspect of the present invention; Figure 23 shows an example of a file request window, for requesting the files from another PC, in accordance with an aspect of the present invention; Figure 24 shows alternative examples of a transmission window, to select transfer files, and the destination window, to select the destinations of the file transfer, together with a transport credit bar and a credit request button, according to an aspect of the present invention; and Figure 25 is a flowchart of the exemplary logic of a module that schedules the sending of files, in accordance with an aspect of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED MODALITIES OF THE INVENTION Referring now to Figure 1, there is shown a schematic illustration of a preferred embodiment of the present invention, which exhibits a system architecture with a limited number of personal computers (PCs) 10, connected to communication paths, although any number of PC 10 can be connected without limitation. Figure 1 shows that PCs 10 can be connected and can use a communication path (e.g., the Internet), another communication path (e.g., telephone network connected to the public, PSTN), or more than one path of communication. communications (for example, the Internet and the PSTN) simultaneously. The preferred embodiment of Figure 1 includes multiple PCs 10, without limitation to the maximum number of PCs 10. Although each PC 10 is shown to be connected to the Internet and / or to the PSTN, alternative communication paths may be employed, such as intra-networks. and extra-private networks. Each PC 10 is preferably, but not limited to, an "IBM compatible" x86 or Pentium class machine, connected to a communication path. However, other computing devices, such as handheld computers, television sets, mobile phones, transportable computers, wireless computing devices, or any other device capable of connecting to a network and using an operating system may be use. Of course, the most advanced Pentium class computers can also be used. Each PC 10 may include an exhibit monitor, a processor, memories, such as ROM and RAM, a file storage device, a keyboard, a pointing device, a communication interface and an interface GUI operation system. graph of the user, which has "drag and drop" functionality. Preferably, the operating system is Microsoft Windows NT, Window 95, Window 98 or Window 3. lx, all available from Microsoft Corp. However, the operating system can be any graphically oriented operating system, such as Mac OS, available from Apple Computer, Inc., Solaris, Xwindows, etc. Each PC 10 operates a computer program that incorporates functional modules, such as those illustrated in Figures 2-9 and 11-13 and has a GUI consisting of windows, such as those illustrated in Figures 15 to 24, described below. The file transfer system, shown in Figure 1, includes the PCs 10, which operate the computer program and the graphic user interface, make possible the direct transfer of electronic files between such interconnected PCs, without requiring mutual registration. of the PCs and without the intermediate storage of files in an intervenor computer. A credit application processor 16 and the independent certification processor 18 may also be provided and discussed in detail below. The GUI system is generated by a computer program designed for a "windows" operating environment, such as Microsoft Windows. This GUI consists of modules to control communications and system functions with GUI access, and graphic modules that require or create display windows. Exemplary display windows include a transmission window to indicate the candidate files that can be transmitted, a destination window, which displays candidate PC destinations, to which the files can be transmitted, and an event registration window, which display the transmitted files that have been sent or received. In addition, the GUI provides user controls to initialize and invoke system operation criteria through dialog windows. In more detail, the following describes the operation functions of a preferred embodiment of the computer program and the graphical user interface of the present invention from the perspective of both the sending PC and the receiving PC. Although the description is given in terms of the software (program), the present invention can also be realized with a firmware (fixed program), a combination of hardware (equipment) and software, or with only the hardware, such as with a machine fixed function or application-specific integrated circuits, etc. In order to effect the file transfer, the computer program of a preferred embodiment of the invention must be operated on both the sending PC and the receiving PC, during the time communication is attempted. Other required operating conditions include active connection to the Internet, intra-networks or extra-networks, or a modem connection to the PSTN; the "start-up" or wait state in both sending and receiving PCs; and the operating system with windows, such as Microsoft Windows NT, Windows 95 or Windows 3.1, are installed and operated on both sending and receiving PCs. In a preferred embodiment, the control modules govern and monitor the transmission and reception of the files through the connected communication path. Also, a transmission window displays a list of files stored on the file storage device. When the files displayed in the transmission window are selected, then dragged and dropped to a graphic object, this drag and drop function of the operating system with windows internally creates a list of files with an associated file structure. The internal list is then linked by the operating system to the target object, represented by the graphic object. In a preferred embodiment, each candidate destination of the PC is displayed as a "short name" created by the user in the destination window. Furthermore, each short name can be a graphic object, invoked by the user, generated by a computer program module and linked to a destination address (or IP address or PSTN number) and a subroutine of the computer program. When the files are dragged and dropped on the destination object in the destination window, a list of files with the associated file structure is created by the operating system with windows, and a control module displays a dialog box , which suggests to the user the confirmation that the selected files contained in the file list will be transmitted to the selected destination. In a preferred embodiment, after the user confirms the files to be transmitted, a compression control module requests a compression subroutine that copies and compresses the files contained in the file list, and stores the compressed file pack in the file storage device of the PC. In the context of this specification, the "file package" is preferably a set of files grouped and compressed, rather than a "package" of multichanneling or transmission of pictures. Then, the control module sends a name of the package file and the address bound to the selected destination object to a pending event log file. Then, after a predetermined time, a control module initiates a connection to the destination PC by means of an appropriate communications path, identifies the sending PC by its name and destination address, then transmits the packet containing the compressed files to the destination address linked through the connected communication path. The control module then displayed in a window registration event, date, time and content (which may include file names and structure of the associated file) when packet transmission is complete. The predetermined time is selected by the user. Thus, after selecting a file for delivery, the user can schedule the transfer to occur immediately or at a later time and / or date. If the file transfer is scheduled for later, the name of the package file and the destination address remain in a pending event log file until the designated date and time. In preferred embodiments, a control module responds to incoming file transmissions, captures, decompresses and writes the transmitted files to the file storage device of the computer, using the associated file structure, and creates a list of received files that It links to the stored files and display in the event registration window, which shows the date, time and content. Furthermore, the control module initiates a continuous sequence to visibly indicate when a packet has been received by a destination PC. Preferably, the selection of the user from the list of files received in the event registration window, launches any application that has been associated with the type of file received.

Control of the System; Figure 2 and Figure 15 In accordance with a preferred embodiment of the present invention, the computer program and the graphical user interface, which operate on each connected PC 10, provide system control and user interaction. A main control module, illustrated in Figure 2, is provided to control the functions of the automatic system as well as the functions with access through the graphical interface of the user. When the user activates the computer program through the graphical user interface 1, the main control module starts the system variables and links the DLL files required for the operation of the system in step S2. A DLL is a dynamic link collection and is a standard Microsoft Windows convention for storing functions requested by application programs. DLLs can be part of the Windows operating system, application program (API) interfaces of software vendors, or functions written for a specific application. Table 1 illustrates exemplary DLLs for the present invention and its purpose.

Table 1 F" The Saxcom 10. dll is available from Sax Software Corporation, of Eugene, Oregon and carries out various file transfer protocols for use with 5 analog phones, which include the Zmodem. The operation of the main control module on each PC 10 focused on a file of pending events. This pending events file contains a list of events initiated by the user interactions or 10 communication requests from other interconnected PCs 10. In step S3, the main control module inspects the contents of the pending event file to determine if any pending delivery event exists. If pending send events are detected, in step S4, the main control module requests a send file module, described below with reference to Figure 3. After the send file module executes step S4, or if there are no pending send events detected in step S3, the pending event file is again monitored to determine if any pending reception event is present in step S5. If reception pending events are detected in step S5, the main control module requests a reception file module in step S6, described below with reference to Figure 4. Otherwise, or after executing the file module of reception, in step S7, the user's events are processed. The user events originated in response to user interaction with the control windows provided by the user interface 1 of the graphical user, and the resulting computer program functions initiated by such user interactions. An exemplary user event schedules a file transfer of a file selected by the user. Exemplary events are shown to be originated from modules 2-7, shown in Figure 2. Each module 2-7 is invoked from the user's graphical interface. The process of user events that involve the execution of the specific logic of the module is described below. In step S9, the Internet protocol (IP) connections are checked by a function, described below with reference to Figure 17. Next, the logic returns to step S3 and is repeated as described above. Referring to the display screen, shown in Figure 15, events 24, both completed and pending, can be viewed in an event log window, such as the one shown in Figure 15. Also, file transfers record the date, time and content of the transfer of the PCs both for sending and receiving. By activating each fabulator 20 in the upper part of the event log window, all the events that have the selected probity indicated in the selected fabulator are displayed (for example, failure, pending, etc.). The 21 Decrypt button launches a function (described below) which decrypts the received files that were encoded by the sender. This decryption can also be performed without manual intervention, depending on the functionality of the coding / decoding programs integrated in the file transfer system. Button 22 Cióse Log (Close Record) closes the event registration window. Preferably, the contents of the event registration window includes for each event; the sender and receiver of the file, the time and date on which the file transfer occurred, whether the event was sending or receiving, and the state of the file transfer. Exemplary states of the file transfer are: completed transfer, pending transfer and failed transfer. An additional symbol, for example, R or U, can be displayed to indicate whether a file has been read. When additional symbols are used, R means that the file has been read and U means that the file has not been read.

System dß File Transfer; See Figure 3 and Figure 4 A main aspect of the present invention is the file transfer system. There are several parts in such a system. The first is the Windows Sockets system. In the present invention, in order to send a file from one interconnected PC to another, each PC must be able to detect requests for communication to other PCs. A preferred system for detecting communications requests, requires each PC to create at least one data structure, called a cuff, that listens to communications requests at a specific gate on each PC. In a preferred embodiment, a listening door is created in gate 789. However, any door or doors may be used, as long as all versions of the computer program in each interconnected PC recognize and connect to the doors used to initiate a transfer. As a result of the established cuff, each PC continuously listens to a communication request from another PC. In a preferred embodiment, a connection from the PC to the Internet or to intra-networks and private extra-networks, using TCP / IP is established by invoking subroutines that create the so-called data structures of the sleeve, which enable communication using the TCP standards / IP. A listening socket is established, which allows the PC to monitor the Internet, intra-networks or extra-networks for incoming communications requests, initiated by other PCs. When an incoming communication request is detected, a control module in the receiving PC evaluates the request within the context of the selective acceptance criteria, before accepting the reception of the communication request. In other words, the receiving PC automatically decides whether to accept communication from the sending PC, based on the criteria, such as the authenticated identity. The receiving PC terminates transmissions from unauthorized PC destinations. The selective acceptance criteria are established during system initialization. The receiving PC evaluates whether it will accept a request, according to several criteria defined by the user. For example, the receiving PC can examine the addresses in the destination file and accept communication only from the addresses listed in the destination file. Alternatively, the receiving PC may only allow receipt of communications from the PCs using software that has selected serial numbers. For example, the license codes initialized during the adjustment of each PC in the system can be automatically used in conjunction with the destination addresses to further authenticate the source identity for incoming communications requests. Alternatively, the encrypted authentication codes, initialized during the adjustment of each PC of the system, may be used in conjunction with the destination addresses and / or license codes to further authenticate the identity of the source for incoming communications requests. The user can configure the acceptance criteria in the installation and can change the acceptance criteria at any later time. In the preferred embodiments, if a control module in the receiving PC accepts the request for communications from a sending PC, a separate sleeve is established by the control modules in the sending and receiving PCs. The transfer of files is via separate sleeves. In the meantime, the listening sleeves on both the sending PC and the receiving PC are maintained. As communication requests from sending PCs are detected and accepted by the coupled PCs in the sending or receiving of one or more concurrent and start transmissions, multiple sockets that enable simultaneous file transfers are created by a control module in each PC that receives such communications requests. In preferred modalities, a control module in the sending or receiving PC creates and places in a linked list a file transfer sleeve for each additional concurrent communication, which enters or leaves. This list facilitates the management of the flow of file transfers. Thus, multiple discrete connections can be established with local remote computers, through several communication paths to which the local computer connects. The process of sending a file will now be described with reference to Figure 3. Initially, in step 30, it is determined whether there are sufficient credits to transfer the file. The credit adequacy analysis is described below. If there are not enough credits, in step S32, additional credits may be requested, as described below. If there are enough credits, in step S34, it is determined whether the attempted transfer is a transfer from the Internet (or intra-networks / extra-networks). If the transfer is a transfer of Inte, in step S36, another sleeve is created. In addition, the sending PC is connected to the listening sleeve on the remote PC at port 789. When another transmission is being executed, the newly created sleeve is added to the linked list of sleeves in use. The program crosses the list, giving time for the sleeves to execute their actions. Thus, multiple transactions can occur substantially simultaneously. In practical terms, the number of transactions that can be handled by the system depends on the factors, such as the speed of the communications and the time and speed of the processor. In step S38, it is determined whether the connection to the Remote PC is successful. If the connection has not been established, it was determined in step S40 whether the sending PC previously tried to connect to the remote PC. If a previous attempt occurred, it is determined whether a maximum number of attempts has occurred; in a preferred embodiment, three attempts. Thus, if three unsuccessful attempts occurred (any number can be specified), in step S46, the logic terminates execution and an error is logged, which indicates that a connection can not be established with the remote PC. Alternatively, the local computer can be adjusted to delay the file transfer until the remote destination computer has an active connection to the communications path at a known address. If the number of attempts is less than the maximum number of attempts allowed, the sending PC again attempts to connect to the remote PC in step S36. 5 If the connection was successfully established, in step S42, the sending PC sends information about the file to be sent and about the sending PC, thus informing the remote PC of where the transmission originated. The sending PC then waits for the remote PC send an address to which the file can be sent. If the data received from the remote PC corresponds to a valid data port assignment, the logic proceeds to step S48. Otherwise, the logic proceeds to step S46, where the logic ends the execution and an error is recorded indicating that an invalid reply was received. In step S48, upon receiving an assignment of I »valid data gate, a new data bus is created and a connection is established between the new data bus and a data gate, which corresponds to the assignment of the data data gate received from the remote PC. In addition, the time-out timer starts and the starting point of the file is determined. When another transmission is already running, the newly created data sleeve is added to a linked list of data links. In step S50, the data is sent to the remote PC. In a preferred embodiment, the file that is transferred is transmitted to 2048 bytes at a time. Thus, the first 2048 bytes are transmitted in step S50. Each time data is sent to step S50, the time out is readjusted to zero. If this time out reaches a maximum time, the connection is terminated and the data sleeve is destroyed. In step S52, it is preferably determined if other data links exist in the list linked to the data bus. If there are other data sleeves, in step S54, the data associated with the next data packet is sent, and the logic is repeated from step S52, until no other data packets are found. In step S56, it is determined whether the end of the file has been reached. If the end of the file has not been reached, the logic returns to step S50 and repeats. If the end of the file has been reached, in step S58, the connection is terminated, the data sleeve is destroyed and the removal of the credits module is requested. Finally, in step S60, the event is recorded in the log file. A preferred embodiment of the present invention uses a simple command gate designated User Datagram Protocol (UDP), to exchange the information characteristic of the exchange file, the user's authentication information and to initiate a transfer. Subsequently, the TCP data gate is opened to exchange the contents of the file. The UDP command gate allows faster connections and faster data transfer than a TCP gate. However, a TCP gate is more reliable for data exchange. As a result, a preferred process for sending a file is as follows: 1) A sender initiates a transfer by sending the characteristic file information and the sender identification / authentication information, to a specified UDP command gate, on a destination computer in a specific IP address. If the transfer is accepted, a data gate is created randomly within a range of specified possible gates and its number is returned in the UDP connection. Otherwise, a notification that the transfer is rejected is sent, and the UDP connection is closed. Finally, the UDP command gate waits to initiate new transfers. 2) If the transfer is accepted by the receiver, the sender connects to the TCP data gate returned by the receiver over the UDP connection and starts sending the file. Both the receiver and the sender resume the "listening" at the UDP gate for transfers initiated by other computers. This is achieved while the file transfer sip the TCP gate is in progress. The process is repeated and handled for any number of file transfers initiated subsequently. Thus, simultaneous, multiple file transfers can be accomplished with any number of other computers, with only one instance of the computer program open and operating. The advantages of the present invention include a single user interface and operation approach, great efficiency in the use of system resources and a fast file transfer speed. 3) The receiver closes the connection when the file size information (characteristic) sent over the UDP connection that initiated the transfer coincides with the size of the received file or the sender closes its connection due to an error. In other preferred modalities of the invention, more than one UDP command gate attends or initiates file exchanges. To initiate a transfer, a sender PC selects, randomly and automatically, the UDP gate from a set of specific gates. For example, one, two or more UDP gates in predetermined door numbers can be designed as listening doors. A sending PC initiates an exchange of files on a randomly selected UDP gate from a set of specific listening ports. The receiver monitors the set of specific doors for file transfers initiated and responds to the UDP gate used by a prospective sender to recognize the condition and return a designated data gate. This configuration also decreases the likelihood of a "collision" in the event that two or more computers attempt to communicate with the same PC at exactly the same time.

Alternatively, if such collisions occur, the attempted communication can be automatically recovered at a later random interval in time. If it is determined that the file transfer will be a transfer to the PSTN in step S34, in step S62 the sending PC shares the telephone number associated with the remote PC. In step S64, it is determined whether a connection has been established successfully. If a connection is not established, the logic proceeds to step S40, where it is determined whether a connection attempt has previously occurred. If a previous attempt has occurred, it is determined whether a maximum number of attempts have occurred; in a preferred embodiment, three attempts. Thus, if three unsuccessful attempts have occurred, in step S46 the logic terminates execution and an error is recorded, indicating that a connection to the remote PC could not be established. However, if the number of attempts is less than the maximum number of attempts allowed, the sending PC again tries to connect to the remote PC in step S62. After the connection is established, signaling occurs, and in step S66 the sending PC sends an identifier and waits for the response from the remote PC. In step S68, if a response is not received, in step S46 the logic ends the execution and an error is recorded. If a response is received, in step S70 the sending PC sends the file and station information to the remote machine. Then, the sending PC waits for a reply from the remote PC. If a reply is not received, in step S46, the logic ends the execution and an error is recorded. Once a reply is received, in step S74, the file is sent to a remote PC, which uses a file transfer protocol. In a preferred embodiment, the Zmodem is the file transfer protocol. Upon completion of the file transfer, the connection is terminated. Subsequently, the transfer status of the sending file is recorded and the logic proceeds in step S58 to continue as previously described. The logic executed by the remote computer / reception will now be described with reference to Figure 4. Initially, in step 400 it is determined whether the transfer will be a transfer from the Internet (or intra-networks / extra-networks). If the transfer is expected to be a transfer from the Internet, in step 402, a sleeve is created at gate 789 and the receiving PC waits for the connection. When something is connected, in the step 404 all the data sent is read. Then, in step 406, the received data (ie the ID) is compared with the IDs within a destination book of the IDs from which the transfers will be accepted. If the received ID is not found in the destination book, in step 410 an error occurs and the connection is terminated. If the ID is in step 408, in step 412 it is determined whether the received data is valid. If they are not valid, in step 410, a negative acknowledgment is sent to the sending PC and the connection is terminated. If the data is valid, at step 414, it is determined whether the received data indicates an index or file request. If the received data indicates an index or file request, in step 415, the request is processed. Otherwise, at step 416, it is determined whether the received data indicates a credit authorization. If the data indicates a credit authorization, at step 418 transmission credits are added, described in greater detail with reference to Figure 11. Otherwise, at step 420, it is determined whether the received data indicates a request for the ID. If the received data indicates a request for identification, at step 422 a response is sent to the request PC with the ID of the receiving PC. Otherwise, it is determined whether the data received is from a partial file, in step 424. The partial file determination occurs to decide whether an interrupted transfer has been summarized, or whether a new transfer begins. Thus, if the data received is from a partial file, in step 425 a starting point is adjusted to the size of the partial file, because part of the file must be present. In other words, the receiving machine informs the sending machine where to resume the transmission, depending on the portion of the previously received file. Next, in step 430, a cuff is created in a random door, the address of the random door is sent to the sending PC, and the time-out timer is set. If the data received is not a partial file, ie a new transfer is started, in step 428, the starting point is set to zero. Subsequently, the logic proceeds to step 430. From step 430, the logic proceeds to step 432, where the receiving PC waits for the data at the gate.

When the data is received, the time counter is readjusted again. Preferably, there is an automatic visible indication of the reception of files on the receiving PC. In step 434 it is determined whether there are other sleeves. If there are other sleeves, in step 436 the data is received for the next sleeve. Next, the logic returns to step 434 and repeats until no other sleeves are found. Similar to the sending PC, the data links can be stored on the receiving PC in a linked list. In step 438, it is determined whether a file transfer is complete or if the data is time-out. If the data is on timeout, the connection is terminated and the sleeve is destroyed. Likewise, if the connection ends by itself, the sleeve is destroyed. If the transfer was not found to be complete, the logic returns to step 432 and repeats. When a file transfer is complete, at step 440 it is determined whether the received file is the same size as expected. In other words, the size of the file is compared to the size indicated in the file data sent in step S42. If the sizes do not match, at step 442 a reception error is recorded. Otherwise, if the file sizes are equal, the transmission is considered successful and the logic proceeds to step 444. In step 444 the received event is recorded, the packet is unpacked and the received files are stored in the device. storage of the receiving PC. Although in the previous description the sender PC is identified, by name and IP address, to the receiving PC, in the initial connection, the identification may come at a later time. However, preferably the sending PC is identified to the receiving PC, before this receiving PC opens the received files. Next, in step 446, the logic described with reference to Figure 5 executes requests to receive confirmation of the process. Next, the logic proceeds to step 448. In step 448, it is determined whether there are other data packets. If e find additional data sleeves, the logic returns to step 432 and the process is repeated. If no other data links are found, the logic flows to step 450, where an automatic update process is executed.

Data verification is handled by the TCP / IP protocol that supports the Windows Socket specification (Windows Hoses). Because the TCP / IP protocol handles the sending and receiving of data, verification is automatic. That is, TCP / IP is an error-sensitive protocol, which checks every TCP packet that uses cyclic redundancy checking (CRC) and retransmits bad packets. Therefore, if a file is assembled from successfully received TCP packets, the probability that the received file is free of errors is very high. Thus, it is only necessary to verify if the entire file was received. This is accompanied by verifying that the size of the transmitted data matches the specified size of the file that was received. The file size specification is sent with the transmitted file and arrives at the receiving PC at the start of the transmission. For modem transfers, the process is different. Thus, if the transfer is determined is not an Internet transfer in step 400, in step 460 the modem is set to the auto-response mode, so the response will be requested. Preferably, the modem is set to the auto-response mode during initialization in step S2 on each PC. After the modem is initialized, in step 462, the receiving PC waits for a telephone call. Upon receipt, the receiving PC answers and reads a stream of data from the modem to determine the identifier of the sending PC. If data is not received before the timeout occurs,. the connection is terminated. If the data is received, the receiving PC sends a response to the sending PC, which includes an identifier of the receiving PC. In step 464, the validity of the data is checked. If the data is invalid, a reception error is recorded in step 442. Otherwise, if the data is valid, in step 466 the download begins with an agreement in the model protocol, preferably the Zmodem, which checks each packet using the CRC and retransmit bad packets. Subsequently, the logic proceeds to step 468 to determine whether the received file is the same size as expected, which indicates a successful transfer. If the file is not of the expected size, a reception error is recorded in step 442. If the received file is of the expected size, in step 470, a reception event is recorded, and the received packet is unpacked and stored in a storage device. Next, in step 472, the logic f »described with reference to Figure 5 executes requests for receipt of the confirmation of the process. Next, the logic proceeds to step 450 and is executed as previously described. Using the Zmodem protocol, the error checking is automatic. However, again once the 10 file size is checked, to ensure that the received file is of the size that it is supposed to be.

Request for Confirmation Receipt and Third Party Authentication; See Figure 5 and Figure 14. According to another preferred embodiment, the present invention makes it possible for a sending PC to request from a receiving PC, the confirmation of the attributes of a transferred file packet. The confirmation is a returned file that contains a list of received files, along with the identity of both the receiver and the sender, as well as several other attributes. The reception file is returned from the receiver to the sender directly or through a third party authenticator 18 (Figure 1) without requiring any action by the user of the receiving computer. The sender can designate whether the confirmation is by direct return or through a third party authenticator 18, common to all users. The destination address of the authenticator 18 of the third part is either incorporated in the computer program, before distribution to the users, or entered by a user before initiating the confirmation requests as part of the adjustment of the computer program in the Sender PC A control module in the receiving PC, upon receiving a request for a confirmation of the attributes of a transferred file packet, records the content of the received packet. This can be adapted to occur before or after decoding and decompression. By creating a file list, the content files are written into the file structure of the storage device of the recipient's computer. Furthermore, the control module in the receiving PC is combined in the file attributes of confirmation reception of the transferred file package. Attributes may include: (1) a list of files that indicates the names of the files found actually present in a received packet, whether they contain encoded or uncoded files, (2) the size of the received files, (3) the identity from the sending PC (point of origin) as received with the file package, (4) the identity of the receiving PC, (5) the date of receipt of the package, (6) the time of receipt of the package and (7) ) the electronic fingerprint (noise) of the transmitted files. Alternatively, the confirmation receipt can be adjusted to provide only the verification of a file transfer action achieved on a specific date, time and destination. Furthermore, if the direct return has been requested by the sending PC, the control module in the receiving PC creates a pending event for the immediate return of the confirmation reception file to the sending PC, which designates the corresponding destination address. Likewise, if the requested confirmation is designated by the sender to be returned through a third-party authenticator, the control module in the receiving PC creates a pending event to return the confirmation receiving file to the sending PC, through of the third party authenticator, which designates the corresponding destination address. The confirmation receipt file is transferred to the third-party authenticator together with the destination address of the sending PC that requested the confirmation. Furthermore, the third party authenticator, upon receipt of the confirmation receipt file, processes the printing of the file with a unique digital characterization of the file using the commercially available file authentication application programs. The file authentication application programs are designed to create files for which any violation or modification can be easily detected. Finally, the authenticated confirmation reception file is transferred, after processing by the third party authenticator, to the destination address of the PC sending the requested confirmation. A copy of the receipt of the authenticated confirmation may also be sent to the recipient of the associated file transfer. The logic for processing confirmation receipt requests will now be described with reference to Figure 5. Initially, in step 500 it is determined if a receipt has been requested. If a receipt has not been requested, in step 502 the logic returns to Figure 4. Otherwise, in step 504, a list of files is created. Preferably, the file list includes file attributes of the transferred files, such as the file sizes, and the data and times of creating the file. Then, in step 506, a text file is created. This text file preferably includes the identification of the sending PCs, the identification of the receiving PCs and the date and time of receipt of the file package. Then, in step 508, a confirmation receipt is created. This confirmation receipt file is a combination of the file list and the text files. Subsequently, in step 510, an immediate dispatch event is created for the confirmation file. In step 512 it is determined whether direct return has been requested. If direct return has been requested, in step 514, a pending event is created with the PC that requested this direct return as the destination address. If the direct return has not been requested, third-party authentication has been requested. Thus, in step 516, a pending event is created with an independent authenticator designated as the destination address. After completion or step 514 or step 516, the logic returns to Figure 4 in step 518. The exemplary logic running the third-party authentication machine will now be described with reference to Figure 14. Initially, in Stage 1400 a cuff is created to listen. In a preferred embodiment, the sleeve is a gate 789. Then, in step 1402 the third party authenticator listens at the listening door. When the data is received, in step 1404, it is determined whether a request is being sent. If a request is not sent, the logic returns to step 1402 and repeats. If a request is being sent, in step 1406, a random data sleeve is created and assigned to a gate, the number of which is sent to the requesting PC. Subsequently, at step 1408 the confirmation receipt file is received at the assigned gate and at step 1410 the file is authenticated. Next, in a step 1412 an immediate dispatch event is created for the authenticated confirmation receipt file and in step 1414 the requester is sent to the destination address received with the request. Finally, in step 1416, it is determined if there are other data sleeves. If there are other data links, the logic returns to step 1408 and repeats. If there are no other data headers, the logic returns to step 1402 and repeats.

Event Registration; See Figure 15. All communications events are automatically recorded by the computer program in an event log file, characterized by the properties of events, such as date, time, file structure and file name. The user can see and interact with the recorded events listed in the event log file, using a control window, such as the one shown in Figure 15. The received files can be opened for viewing directly from the Event Log window , when the file formats of the received files have been associated with an appropriate application program, available on the receiving PC. The opening of the files can be achieved by selecting an event 24, listed in the Event Registration window, using the signaling device, then initiating the control commands, using the PC signaling device or the keyboard, which opens a control window, such as that shown in Figure 16. The control window, shown in Figure 16, displays the properties of the recorded event. The listed files can be opened by selecting file 25, which initiates the control commands that use the pointing device or the PC keyboard, which opens the file using an associated application program, available on the PC. IF an application program has not been associated with the format of the file listed, a message informing the user or suggesting the user's action is displayed. Cancel button 26 closes the event properties window. The button 27 See Reception displays any return reception associated with a selected event.

Select and Send Files / Packages; See Figure 18, Figure 19, Figure 20, Figure 21 and Figure 25 The user, on any interconnected PC of the present invention, can initiate a send file event in a variety of ways. For example, by interacting with a control window, such as the window shown in Figure 17, the user can use the PC signaling device to select files listed in a transmission window 28. Subsequently, by invoking the drag and drop function of the Windows operating system, the user can drop the files on the destination objects 30 in the destination window. In response to the fall of the file on the target object 30, a list of files created by the Windows operator system is linked to the address of the target object 30 and the file will be sent. Preferably, the structure of the file residing on the transmission PC is duplicated on the receiving PC for each file sent. In a preferred embodiment, manual confirmation is required for each selected file that is to be sent to each destination of the PC. Manual confirmation requires the user's action in order to transfer each file. An automatic classification of the authorization of the file transfer can also be provided, which only allows authorized transfers to occur. Automatic classification can occur before transmission to each PC destination for each file to be transferred. The buttons at the bottom of the destination window can also be used in a preferred embodiment. Button 34 opens other target windows. Button 36 minimizes the destination window. The button 32 opens the transmission window 28. Alternatively, a package or file can be selected by means of the windows shown in Figures 20 and 21, and the destination can be selected by means of the window shown in Figure 19. According to the procedure employing the windows in the Figures 19-21, the user selects a file or package and creates a send event, which can be scheduled or as an immediate transfer or a delayed transfer. In Figure 20, a list 60 of Fall Units makes it possible to select a disk unit that stores the files to be sent. When a unit is selected, the directory structure is displayed in the display field 62, which displays directories, subdirectories and files. After the user selects a file, this selected file is displayed in a display field 64, together with the corresponding file structure. Preferably, any selected file shown in the display field 64 will be compressed (all together, if multiple files have been selected) in a file packet (also named simply as a packet) before being transmitted. Clicking ("clicking") in the Description box 66 results in a suggestion 68 to the user that allows the user to name the file package and add a text message that will be sent along with the selected files. In a preferred embodiment, the text that identifies the user's name, organization and address is inserted automatically. A text message can also be inserted in the dialog box by the user. Furthermore, the inserted text is then linked, by a control module, to the list of files to be compressed by the compression subroutine in a packet for transmission by a control module to a destination address of the PC linked The text information about the sender and text messages contained in the received packets are displayed in the event log window, when the associated received files are selected by the user. In a preferred embodiment, one or more files may be selected from one or more directories in the file structure for compression, by a compression control module in a packet for transmission to a destination PC address. The text message embedded in the files that are to be transmitted before compression to the reference computer is easily visible after decompression on the receiving computer. However, when coding is enabled, text messages may be embedded with the files to be transmitted before encoding on the sending PC and are easily visible on the receiving PC after decoding. Alternatively, text messages can be embedded with the files to be transmitted after encoding files on the referral PC. Consequently, text messages are easily visible before decoding the file on the receiving PC. Text messages are stored in a text file that the receiving computer recognizes and displays accordingly upon receipt. If the Description box 66 is not checked, no suggestion 68 to the user will be displayed and the package is created with a standard message and a random number as a name. The suggestion 68 to the user may also be displayed when the Compression button 65 is selected. The oppression in the approval button 69, initiates a compression function by requesting the compression function in compress.dll, which creates a file package. The suggestion 68 to the user is then closed and the Compression button 65 is repositioned by a Next button, which enables the user to change to the selected destination window (Figure 19). If the user wishes to send a package of files, previously created, the windows of existing packages of shipment (Figure 21) can be reached by the menu 50 of Packages, in Figure 19, or in any other screen where the menu of Packages appears . In Figure 21, the selection of a packet 70 then clicks on Next button 71, which changes the user to the selected destination window (Figure 19), where the destination for the selected packet can be designated. The double oppression ("click") in a packet 70 results in the display 72 showing the contents 73 of the packet and any associated message 74. The oppression of the button 75 Cancel, closes the display 72. The Cleaning Entry button 76 clears any selected package 70. The Cleaning List button 77 clears all the packages 70 in the list of displayed packages. eleven The selection of the destination window to select a destination to send the file will now be described with reference to Figure 19. The Package menu 50 enables the initiation of a file transfer, the index request, the file request or the display of the record. A Control menu 51 offers options for establishing a link to an active Internet / intra-network / extra-network connection and / or initializing a modem. An index menu 52, allows access to the index build / edit function and a volume adjustment. This volume adjustment makes it possible to name and delete volumes, which are logical divisions within an index. An Adjust menu 53 makes it possible to modify the setting of the computer program in terms of directories, modem parameters, user information, coding program interface and also enables access to destination books, which create destination lists. A Help menu 54 provides access to the instructions for use. A button 55 of Change, gives access to the books of destiny. A Browsing button 56 makes it easy to find previously created file packages. The packages are displayed in a dialog box, which appears when the Browsing button 56 is selected. A Previa button 57, returns the display to the previous display screen. A fall list 58 displays the candidate destinations from which the user can select the destination to which the files are to be sent. A Send 52 button initiates a transfer of selected files to the selected destination. Another procedure of sending a selected file to a selected destination will now be described. While the user works within an application program, the user can save the work file to a directory associated with a particular destination, that is, the linked destination directory (DLD). Files can be saved in the directory using the Save As option, or they can be automatically written to one or more DLDs as automatic output from a related application program. Subsequently, all files within the directory (ie, DLD) to which the files are stored are sent to a destination associated with the directory. In a preferred embodiment, the transfer occurs immediately after saving the file. However, the transport interval can be adjusted for immediate or delayed time periods. Thus, by saving the files to the directory associated with a particular destination or group of destinations, the files will be sent to that destination or group of destinations, without additional user action. Multiple directories, each associated with a particular destination, can also be used, allowing the user to select the destination to which the file will be sent. These directories can be created at the time of defining a destination in the destination book by the user. The DLDs enable the integration of the present invention with other application programs at the level of the operating system, without the use of an application programming interface. When a file is written in DLD, the file is sent to the destination that has been associated with the DLD, then deleted from this DLD. A user option allows the file to be written in DLD and then saved in a different file than DLD before deleting this file. The present invention allows the user to make multiple directories associated with the destinations and store them in the destination book. When a user places a file in one of those directories, it is sent to the associated destination. This enables seamless interfaces between large groups of computers over wide area networks. Computers that generate large numbers of files (such as invoices) that require distribution to a large number of receivers, which can automatically and directly link to the destination computer using the DLD structures. The receiving computer that receives the transfer must DLD be actively connected to a communication path accessible to the sending computer. If the receiving computer is not actively connected, the sending computer may repeatedly try to transfer the file. In a preferred embodiment, the attempts are stopped after a selected period of time has elapsed. Alternatively, the sending computer may wait until it is determined that the receiving computer has connected. The receiving computer receives the files in a directory designated to receive the files by the user of the receiving computer. A discrete connection is established for each file transfer initiated with each receiving PC, as described above. Referring to Figure 25, an exemplary process for scheduling a file submission event is now described. Initially, in step 2500, a file / packet and destination are selected, according to one of the procedures described above. Next, in step 2502 it is determined whether the user is authorized to send the selected file to the selected destination. If the authorization is not confirmed, in step 2504 the user is asked to confirm the selected destination, if it is the destination to which the user actually tries to send the file. If the confirmation is not received, in the step 2506 the file transfer is aborted. Otherwise, and also when the authorization occurs in step 2502, in step 208 it is determined whether the package, previously established, is being sent. If the packet has not been established in steps 2510, 2512 and 2514, the packet is compressed, the link identification information and the authentication codes are created and the packet is encoded. After compression, and also when it is determined that the packet already exists, in step 2516 it is determined whether the file transmission will occur now or later. If the transfer is to occur later, in step 2518 a program is opened, and in step 2520 the user enters the date and time when the file transfer must occur. Subsequently, and also when the file is to be sent immediately, in step 2522 a send event is created. Finally, in step 2524, the send event is programmed as a pending event in the main control module. At this point, the computer program treats the file as any other pending event set by the user. The program is constantly in the process of inspecting the rows and sending any pending event found with a time that is earlier than or equal to the current time.

Setting a destination: Figure 17, Figure 18 and Figure 19 In preferred modes, a user function is provided to invoke a destination window, with which one or more destination files can be created. The destination window can be used to select a destination file and add, delete or modify the destinations in a file of these destinations. A destination address may be selected from a destination window by the user, for use by a control module to transmit a packet. In preferred embodiments, a user function is provided to invoke a dialog window, from which the user can set a specific date and time when the control module initiates the transmission of a specific packet. In preferred embodiments, a user function is provided to add addresses of the destination PCs, such as short name objects in the destination window. These short name objects added to the destination window are linked to the specific destination addresses contained in the destination file. Preferably, the number of possible destination addresses allowed as destination targets for a sending PC is controlled by adjusting an adjustable limit not by the previously established user (a fixation limit) in a control module for the number of allowed entries in the destination file. Likewise, the number of destination files allowed for a sending PC is controlled by setting a fixation limit in a control module, for the number of destination files that can be created or viewed. This fixation limit can be previously established in the software by the software developer / manufacturer during the production of the installation disk, before the software is transported to the user for installation on the computer. In preferred embodiments, a user function is provided to invoke a dialog window enabling the modification of a destination address from a destination window. In addition, a user function is provided to invoke a dialog box from which the user can create or select additional destination windows for the display. In preferred embodiments, a user function is provided to launch a window displaying the file structure from a destination window. According to a preferred embodiment, a discrete destination and associated address can be defined or modified, and saved in a destination file by user interaction with a control window, such as that shown in Figure 18. Once defined and saved , a destination file can be selected and displayed in a destination window, such as that shown in Figure 19, and can be linked to a destination object in a destination window, such as that shown in Figure 17. Destination file can also be linked to a directory to create a DLD. A method for adding or modifying a destination will now be described, according to a preferred embodiment. The Adjust menu 53 is selected for access to the window shown in Figure 18. Then the user selects the New button 40, or selects a destination and the Edit button 42. The oppression ("clicking" on the button 40 results in a display of a dialog box that enables the entry of the destination information, comprising the name, address, type of address (e.g., the PSTN number, IP address) or creation of destination groups A group of destinations allows a file transfer to all destinations within the group with a single user action.The button 42 is used to edit parameters of an existing destination. operation on button 42 of Edit results in the display of a dialog box that enables the modification of the destination information.For modem destinations, the user enters the telephone number of the modem destination.For Internet addresses, the user enter the destination's IP address.

After entering the information, the user selects a Finished button 48 and the destination is added to the destination book. This Finished button 48 closes the destination book window. A table (not shown) can also be checked, causing a linked destination directory to be adjusted for that destination. An implicit name for the DLD can be set to the short destination name or the full destination name. The present invention preferably stores all the information near a destination in the destination book, which can be carried from one computer to another and easily shared among the users. The destination books provide an easy way to send a file to a group of users. The user simply selects the group as the destination of the data file that contains the information of the destination book. The present invention then sends the file to all users in its group. A button 44 of Remover, separates the listed destinations,. A button 46 of Add a Group, creates groups of destinations that allow the transfer of files to multiple destinations with a single user action to be initiated.

In order to add a destination to the destination bar, as shown in Figure 17, a user can click on a destination object 30 if this destination object 30 is empty (ie not associated with a destination). ). In response to the click, a drop box appears, which lists the destinations defined according to the procedure described above. The user can then select a destination from the destination list and change a short name associated with the destination, if desired. Consequently, this short name will appear in the destination bar if the destination object 30 is not empty (that is, not previously associated with a destination). Modifications to the destination parameters are then saved in a destination file.

Creating an index: See Figure 6 and Figure 22 In a preferred embodiment, the user can create an index of files stored in the file storage device of the PC, which can be requested by other PCs through a path of connected communications. The index is created by selecting files from the file list window. File names and file structure are then added to an index file in a display window by the control module. In preferred embodiments, a user function f is provided to invoke a 5 index request sequence in which the user can select a destination from the PC to which an index request will be sent. When selecting a PC destination for an index request, a control module initiates the transmission of the index request, the identification and the address of the PC that request. The destination of the PC receiving the index request checks the identification of the PC requesting the authorization and then returns the index linked to the PC that it requests (assuming it is authorized) to the address received from the PC it requests. Upon receiving the index, a control module stores the index linked to the associated destination address in an index file in I »the file storage device of the receiving PC. In a preferred embodiment, indexes may be requested from multiple destination addresses of the PC. In a preferred embodiment, the user can create one or more indexes of files stored in the storage device of the PC. Each created index can then be linked to a specific destination address (that is, a private index). Furthermore, an index linked to a specific destination address, which may include identifiers, such as the user's name, identity or site code, serial number, etc., is the only index that will be transmitted to the PC. destination that you request, that has that specific destination address. The private index capability enables users to recover files from another computer without allowing the user to register or control the computer that has the desired files. A) Yes, the private index reduces security risks. Likewise, an index linked to a non-specific destination address (ie a public index) will be transmitted to any destination address. In other words, the public index is accessible by all users. In other preferred embodiments, the index is created by selection from the target dialog window, the desired destination address to be linked, and then selecting the files from a file list window. The file names and their structure are then added by the control module to the linked index destination file and an index display window. In other preferred embodiments, a user may encode a packet containing the files in the list of files to be passed to the pending event log file. The control module requests a coding subroutine that encodes the packet containing the listed files. Using the coding software, commercially available, which has the technology of the "key to the public / private key", the key code to the public can be used to encode files. This key code to the public is linked to the destination address to which the files are to be sent. The key code to the public of each destination address is generated from a private key code, both of which are generated and linked to the destination address during system tuning in each PC destination. The key code to the public, but not the private key code, created for each PC destination, can be received by each PC of the system automatically in the request of another destination PC. The key code to the public linked to a destination is used for encoding files that are to be transmitted to that destination. Only the private key for a specific destination can be used to decrypt encrypted files with the key to the public for that destination. The files received in a destination of the PC that are encrypted using the key to the public for that destination, are automatically decrypted using the private key for the receiving PC. In still other preferred embodiments, the coding programs may be invoked by the user to encode files, manually selecting the appropriate key to the public, before selection for transmission to a destination PC. The decoding programs can also be invoked by the user to decrypt files with a manually selected private key code after receiving the files. Automatic encoding and decoding without the exchange of the key to the public, can be used. Such coding technology does not use the key technology to the public / private key, but rather a coding key of "a time filling". The present invention provides an option to the user that allows him to select a security product that the user wishes to use. It also provides the option to use the TriStrata Security Architecture, which provides centralized management of the security policy, which eliminates the requirement for the exchange of the public key and provides a very fast encoding or decoding. The TriStrata Security Architecture is a development team, publicly available from TriStrata Security Inc., of Redwood Shores, California. In a preferred embodiment, a user function is provided to invoke a file request sequence, which allows the user to request files from a selected index, in order to request files from the associated destination PC address. Furthermore, when one or more files listed in the index are selected by the user, a control module initiates the transmission of the request for the files together with the identification and address of the PC that it requests. When a PC destination receives a request for one or more files in an index, a control module requests a compression subroutine that copies and compresses the files contained in the received request, creates a package file and passes the package to the pending events file. In another preferred embodiment, if the automatic encoding is invoked, the packets containing the compressed files are encoded using a key to the public linked to the request destination or a time key linked to the exchange transaction. A preferred compression algorithm (compress.dll) is publicly available from Infozip Group. Other compression algorithms are commercially available and can be used in preferred embodiments. A control module initiates a connection to the destination PC, using the destination address received with the file request. Furthermore, a control module identifies the sending PC by its address, then transmits the packet containing the requested files compressed to the address linked through the connected path. When the packet transmission is complete, the control module indicates a successful transfer in the event log window, by date, time and content. In preferred embodiments, the control module responds to incoming file transmissions, captures, decompresses and writes the transmitted files to the file storage device of the computer, using the received associated file structure, and creates a list of received files , which is linked to the stored files and displayed in the event log window, which shows the date, time and content. According to a preferred embodiment, the user of any interconnected PC of the present invention can create a file index from which another designated PC can request files. Likewise, multiple indexes can be created, each authorizing a request for different interconnected PCs and comprising different lists of files. The multiple indexes are established by associating each index with a specific destination and then selecting the files that are to be listed in the index. Thus, different files can be in each index. In a preferred embodiment, the volume name (disk label) is used for an index authorized for transmission to any requesting PC. Alternatively, the destination name, destination address, internal serial numbers or authentication codes can be used to restrict the transmission of each created index to a specific destination PC. The index is created by the user's interaction with the control windows, such as those shown in Figure 22. In Figure 22, a 80 Drive button (unit) displays a drop box that enables the selection of a unit from which the files to be indexed can be selected. Check box 81 allows you to build an index that contains the specific directory tree. Check box 82 enables the reconstruction of a specific index. Check box 83 enables the construction of an index containing files, before and after a specific date and time. Button 84 varies the reference time for the index from the current time displayed. The button 85 modifies the reference date for the index from the current date displayed. Table 86 enables the construction of an index that contains only a specific file extension (for example, "doc"). Table 87 enables the construction of an index that contains all the files in a logical unit. Button 88 returns to the previous program screen of the computer. The button 89 starts the construction index process using the parameters selected by the designation of tables 81 to 87.

The created index comprises a database tree, which includes linked lists of the file block structures of the operating system. These structures are used by operating systems to store information about the file, and its status. Each node of the tree contains the signs to its "brothers and their descendants and parents". In this way, the index retains the information of the directory structure. When a file is added to the index, each level goes into the tree. An example to add a file to the index will now be described. Consider the file report.txt, with its associated unit and directory structure being E: \ sky \ clouds \ bird \ rport.txt. When the file is added to the index,! E: \ "is not used, because only the structure of the directory, and not the unit, is important.Therefore, the database is searched for" sky ", starting from the root of the database and moving through its siblings, if "sky" is not found, it is added to the list, preferably keeping this list in alphabetical order, then the search for "clouds" begins As the first descendant of the node "sky", moving through the brothers If "clouds" is not found, it is added to the list, preferably keeping this list in alphabetical order.The process is repeated with the first descendant of "clouds" "and the search for" bird "begins, the same process is executed with" report.txt. "The process is highly recursive because it is repeated for each tabulation level of the directory tree, until the file name is reached. The nodes of the file name in the index do not have descendants, but they can, of course, have "brothers". The process of creating each index using a control window, such as that shown in Figure 22, will now be described with reference to Figure 6. Initially in step 600, the user indicates that an index will be created. Then, in step 604, a list of the file name is generated based on the options selected by the user. For example, if you check From the Directory, the user can select specific file names to be included in the list. If other options are checked, the list is generated with the file structure based on the stored options. In step 606, the first name in the list is determined. Then, in steps 608-622, the structure of the index is recursively formed until the name is included in the list. When it is determined in step 610 that the file name has been added, in step 624, it is determined whether the list has been completely formed. If the list is finished, in step 626, the logic ends. Otherwise, in step 628 the next line in the list is determined and the process is repeated in step 608.

Request a File or Index: See Figure 7, Figure 8, Figure 19 and Figure 23. In accordance with a preferred embodiment, the user on any interconnected PC of the present invention, may initiate a file or index request event by interacting with the control windows, such as those shown in Figures 19 and 23. An application event of The file is initiated by using the PC signaling device to select an index from a list displayed in a control window, such as that shown in Figure 23, then select the files listed in the index and invoke a request event. . The user can initiate an index request event by invoking a request control from menu 52 of the index in a control window, such as that shown in Figure 19. and then selecting the destination from which the index is to be requested. ftv The computer program links an index request to the destination address associated with the selected destination 5, and then schedules a send event in the pending events file. The identification and address of the request PC is sent as part of the request. In the present invention, the computer program on each PC that receives an index request will return only one index created specifically and authorized for the requesting PC, unless the receiving PC has an index created and authorized for general distribution to the interconnected PCs. In addition, a file request can only be initiated from an interconnected PC, after download one or more indexes from other interconnected PCs. Referring to Figure 7, the exemplary logic for requesting a file or an index is now described. Initially, in step 700, the user selects the desired files from a remote index, previously downloaded or selects an address from which an index is downloaded. Then, in step 702, it is determined whether the request is for a file or an index. If an index has been requested, in step 704, an index text file is created. Alternatively, if a file was requested, in step 706, a file list text file is created. Then, after steps 704 and 706, the newly created text file is programmed as a pending event that will be sent by the send file module of Figure 3. Finally, in step 710 the logic ends the execution. Because the program is always waiting for files, the program is waiting for a return of the request. Referring to Figure 8, an exemplary logic running on the receiving computer will now be described. Initially, in step 800, the receiving computer receives a text file containing a request. Then, in step 802, it is determined whether the request is for an index. If the request is not for an index, it is analyzed in step 804, and the files are located. Next, in step 806 the requested files are compressed and in step 808 a send event linked to the requested PC is created. After the event is created, coding occurs in step 810, if this coding has been enabled, and in step 812 the files are sent to the requesting PC, according to the procedure described with respect to Figure 3. If in step 802 it was determined that an index has been requested, in step 816 it is determined whether the requested index is authorized for transmission to the requesting PC. If the index is authorized, in step 818 this index is compressed and the logic proceeds to step 808, for transmission as previously described. If the index is not authorized, in step 820 a message is created which informs the requesting PC of the denial. Subsequently, in step 822, the message is compressed and sent to the requesting PC in steps 808-812. In Figure 23, a button 90 displays a drop box that enables the selection of an index received from any PC listed in the target book. The files contained in the selected index are displayed in a display field 92, together with the structure of the associated file. The files are selected for the application by clicking on the files listed with the PC signaling device. The selected files are displayed in a display field 94. Pressing the Request button 96 starts the request for the selected files from the PC from which the selected index was received. A Delete button 98 clears an index, usually when a new, more current index has been requested to replace the index that has been deleted. The present invention may also include a self-polling feature, which provides the ability to poll groups of destinations, all at once and simultaneously receive all files transferred as a result of the poll. Auto-polling is enabled when the user places files in a directory, which correspond to a remote destination. This remote destination can subsequently poll that directory which causes those files to be transformed to the remote PC. The self-poll is similar to the index function previously described, except that with the auto-poll the remote PC does not require specific files, all the files in the directory are sent to the remote machine under scrutiny. Due to the ability to have multiple simultaneous connections, a computer polls all remote machines in parallel. Remote probing provides the advantage that many files can be received from many different locations quickly. The return receipt feature, described below, can be used with the parallel scrutiny feature, to provide benefits & addi-ci-ona1les In a preferred embodiment, if an inappropriate computer probes a directory to initiate a transfer, this transfer occurs. However, the transfer will not be to the unsuitable user. This transfer will go to the computer associated with the 10 directory that is being polled.

Automatic Update According to another modality, an automatic update feature can be provided. This automatic update feature allows the user electronically receive new disclosures from? software versions and automatically install software updates. Options are provided to update automatically and manually upon receiving the electronic transmission of a new version release software. When an update is transmitted to the receivers, if the automatic update has been selected during the setting of a receiving PC, the previous version, installed on the receiving PC, is automatically replaced by the new files of the published version. The automatic update is achieved by transmitting, together with a computer program of a new published version, (1) an update identifier in the header of the file list for the package that differentiates the update package from other types of files received; (2) a unique authentication code to the software manufacturer; and (3) an installation program and a set of control commands that are executed by the currently installed version of the software. Depending on the specific requirements of the new disclosure, the control commands may terminate the operation of the current version, copying new files and / or installing the modifications required for the new version. The operation of the new version is started by any control command or the installation program for the new version, depending on the extent of the improvement. The installation program preferably the DLLs without link, will copy the new DLL, will copy new executable files and will operate the new version of the program. Finally, the installation program ends by itself. ? t If the manual update was selected during the setting on the receiving PC, the updates of the software, received electronically, are stored in the storage device of the receiving PC with the same file structure as the file structure of the sending PC. The user on the receiving PC can manually start the install routine for the new version of disclosure at a later date, when the installation of the update is desired.

Credits; See Figure 9, Figure 11, Figure 12, Figure 13 and Figure 24. Another modality of the transmission window and 15 destination bar is shown in Figure 24. A Units button 100 enables selecting the unit where the files are stored. they will send will be stored. When a unit is selected, the directory structure is displayed in a display field 101, which displays directories, 20 subdirectories and files. When the files are selected using the pointing device, the selected files are displayed in a display field 102, together with the corresponding file structure. The oppression in the Coding button 103, requests an application program of IV encoding, to encode the files in public key 5 for the destination where the files are going to be sent. A button 104 of Add an index, enables the addition of the selected files to a specific index. Pressing the Next button changes to the selected destination window (Figure 19). 10 If the user stops pressing a destination object 30, the selected files are forwarded to the associated destination address, after which the confirmation of the selected destination is suggested and if a delivery confirmation receipt is requested. In a modality Preferred, the observer can select the confirmation receipt as direct or through an authenticator of ) third part. The button 108 initiates a request to transmit credits, displaying a dialog box that suggests to the user a number of credits that are requested and the user's accounting information. Display bar 109 (a.k.a., fuel gauge) indicates the number of credits transmitted remaining.

According to another preferred embodiment of the present invention, a credit system can be employed. This credit system controls the number of transmissions that a specific sender PC can send. The credit system operates by setting a value of a fixed adjustable limit, then decreasing the value of the fixed limit by a predetermined amount, after successfully completing each file transmission. The value of the fixed limit can be decreased until the value reaches zero, in this case no further transmissions will be allowed until the fixed limit has been reset to a non-zero value. In other words, a certain number of credits can be provided in the specific sender PC and the number of credits decreases after each successful transfer of files until there are no more credits left. The file transfer function is suspended in the specific PC once the value of the fixed limit, incrementally modified in the PC, reaches a null value. In other words, transfers are not allowed after the credit balance reaches zero. Therefore, before any transmission occurs, the sending file module, shown in Figure 3, checks the credit balance to determine whether the sending PC has sufficient credits for the requested transmission. If an insufficient balance is found, a message is sent to the user that indicates that this balance is insufficient, along with instructions on how to obtain additional credits. A message can also be displayed, which indicates when the number of credits falls below a certain predefined level, advising the user to obtain additional credits. According to another modality, a transaction account increases after each successful file transfer, and no further transfer is allowed when a predetermined maximum number of transactions has been reached. According to another embodiment of the present invention, the file transfer function is restored by resetting the fixing limit to a value different from a null value, ie, obtaining additional credits. The user obtains additional credits by invoking a user authorization request. To initiate a credit application, the user presses the request button 108 (shown in Figure 24) and the appropriate accounting information is subsequently suggested. If the information has been previously entered, an opportunity is provided to edit the information before sending it. The number of credits requested is also collected, or automatically (for example, an implicit amount) or through suggestions to the user. The exemplary accounting information that may be chosen includes a credit card number, or an account number that the applicant indicates, for example, a business account. Thus, to obtain credits, the user must have an account established before requesting the credits and provide the account number with each credit request, or alternatively, provide credit card information. Preferably, the accounting information and the number of credits required together with the authentication of the identity of the sending PC, and the IP address or the telephone number, are transmitted to a computer system 16 of independent authorization (credit processor) (Figure 1) that uses the method of > file transfer previously described, through a connected communication path. The request is sent to a specific credit processor 16 at a fixed IP address, specific, previously provided in the referral computer. According to another embodiment, the user's credit can be established by inserting an authentication device into the PC diskette or a device reader. As a result, the PC reads the information from the authentication device. After the authorization computer system 16 receives the authorization request, the connection between the request computer and the authorization computer system 16 terminates and the authorization computer system 16 begins the process. After the complete process, this authorization computer system 16 contacts the requesting computer by means of the standard listening gate and indicates the denial or the number of approved credits, without establishing an additional connection. Only a simple connection is used for this message for security reasons. When validating the accounting information, the credit processor returns an authorization and transmission control code to the requesting PC, which corresponds to the authorized number of transmissions. Preferably, the credit processors do not store and forward files, they do not process file transmissions.

Referring to Figure 9, the exemplary logic for requesting credits is now described. In step 900, the user selects the number of credits desired; in a preferred embodiment, 25, 50, 75 or 100 credits. Then, in step 902, the accounting information is displayed (if previously provided) and is edited, or collected (if not previously provided) by means of suggestions. Finally, in step 904, the request is sent forward to the main control module for transmission to the credit processor 16. At least one authorization computer system 16 must be provided for the purpose of authorizing and issuing credits, processing the accounting information received in the authorization request and, upon validating the accounting information, informing the requesting PC of the Successful validation of accounting information. If the validation of the accounting information is not successful, a message, indicating the denial, may be returned to the requesting PC, causing a message to be displayed to indicate the unsuccessful request for credits. Preferably, the credit processor 16 is a special computer adjusted exclusively to the process of credit applications, validating the accounting information. No document file is transferred through the credit processor 16 and there is no provision or application for registration. The credit processor 15 adjusts to a specific IP address and processes the accounting information received in the credit authorization request. The operation of the credit processor 16 will now be described with respect to Figure 10. In step 1000 a sleeve is created, at the door 789 in a preferred embodiment. In step 1002, the credit processor "hears" a credit request at gate 789. At step 1004, upon receiving a request, it is determined whether the received data represents a credit request. If it is determined that the received data is not a credit request, the logic returns to step 1002. Otherwise, if a credit request is received, in step 1006, a random data sleeve is created and a gate is opened. Assign to receive the authorization request. Subsequently, in step 1008 the authorization request is received at the assigned gate. In step 1010, the accounting information (for example, an account number, credit card number and expiration date) is extracted from the received data. In step 1012, the accounting is verified, ie it is checked for validity or the charging authorization process of the credit card is executed. If the accounting is verified, in step 1016, the authorization for the requested credits is returned to the requesting PC at gate 789. If in step 1018, it is determined that there are additional data links, the process returns to the stage 1008 to concurrently process other requests received, as described above. If there are no other data links, the process returns to step 1002 and the process repeats. If in step 1012 the accounting is not verified, in step 1014 an unauthorized account message for unapproved requests (for example, because there is no account number, credit card authorization not approved, etc.) is returns to the PC you are requesting. The authorization computer system 16 performs the standard process of the credit card to determine if the cost of the amount of credits required is available on the credit card sent. If an accounting number was sent in place of the credit card number, this accounting number is sent forward to a standard accounting system to verify if the account is valid and if the requested amount is available from that account. If the accounting information is validated, a confirmation message is sent back to the requesting PC along with the authorized number of credits. Upon receipt of confirmation, the application PC increases the credits by the authorized number of credits. Alternatively, the authorization computer system 16 can approve fewer credits than those requested. Upon receiving the credit authorization, the main control module requests to add the credit routine, shown in Figure 11, to add the new credits authorized to the current remaining credits. Referring to Figure 11, in step 1100 the requesting PC gives him the number of credits received returned by the credit processor. Then, in step 1102, the request PC decodes the current balance of remaining credits. Any known form of encoding / decoding can be used, in order to prevent users from making violations with the number of credits contained in their PC. Alternatively, an external device, such as a "Smart Card" # * can be used to store the authorization of received credits. In step 1104, the new authorized credits 5 are added to the remaining balance of credits. Then, in step 1106, the new credit value is encoded. Finally, in step 1108 the new credit balance is displayed, in a preferred embodiment, in bar 109 of credits, shown in Figure 24. 10 When a file is transferred by a PC, the main control module requests to remove the Credit routine, shown in Figure 12, to modify the remaining credits by one or more credits. According to a preferred embodiment, a different number of credits15 can be deducted for file transfers of different sizes. For example, file transfers of less than one megabyte may only require one credit per transfer, while files larger than or equal to one megabyte may require two credits per file. transfer. Referring to Figure 12, an exemplary process for removing credits for file transfers will now be described. In step 1200, the number of credits required for the present transfer is determined. The number of credits required for each file size can be stored in a look-up table. Then, in step 1202 the current credit balance is decoded. In step 1204, the cost of the transaction is subtracted from the current credit balance. Finally, in step 1206, the modified credit balance is coded, and in step 11208 the new credit balance is displayed. According to a preferred embodiment, a constant rate billing system is employed. For example, a business can pay a fixed amount for an unlimited number of transfers per month. In order to perform the constant rate billing system, a limit must be set for the total number of credits allowed on each PC at any given time. The number of credits must be limited in the case of a business that subscribes to the service of the constant regime implicit in the monthly payment. The fixed maximum number of credits prevents the business from having a number in excess of the free credits in the business PC after the implicit value and thus receiving extra free transfers. Of course, some credits may remain on the business PC after the implied value; however, the maximum reduces the loss. According to the constant rate system, the local machine limits the number of credits requested to maintain the machine without exceeding the maximum. For example, if the maximum number of credits allowed is 100 credits, the user currently has 90 credits and requests 50 credits, the request PC prevents the request from being transmitted. Alternatively, the request PC can reduce the request to the number of credits allowed, in this example 10 credit. When the number of credits in a PC that subscribes to the service of constant regime, it exhausts the credits in the PC, the authorization merely determines if the account number sent is a valid account, and the number of credits requested will be the number of credits necessary to reach the limit. According to another preferred embodiment, the number of authorized file transmissions, remaining on each PC, is displayed dynamically. Thus, the number of credits currently available is displayed, and when the number of credits changes, for example, due to a file transfer, the change is indicated on the user's display screen. One modality of the dynamic display is shown in Figure 24 as a credit fuel measure, 109, which shows the number of credits currently available. The percentage of available credits in relation to the maximum number of credits can also be displayed. Again, the number of credits displayed reflects any change in the adjustable fixed limit, due to the purchase of additional credits or credits spent on transfers. Although Figure 1 shows only a single credit processor 16 and the independent certification processor 18, multiple credit processors and multiple independent certification processors may exist. If there are multiple credit processors and independent certification processors, each PC 10 is preferably informed of each address and selects the systems for the random contact. In a preferred embodiment, each PC 10 contains a different subset of addresses, thus distributing the network traffic.

According to a preferred modality, even in the case of a transmission error, an error repairer enables the files to be sent successfully. In order to achieve successful transmission, the control module operating in the personal sending computer divides a group of files that are transferred between the personal computers in two discrete segments. Each discrete segment contains a portion of the files that are to be transferred. The division occurs at the point where the transmission error occurred, the first segment that has been successfully transmitted, the second segment that has a failed transmission. The protocol used to transfer the files, for example TCP / IP, informs the sending PC of when the transfer was interrupted, that is, when the connection was lost. After losing the connection, the sending PC establishes another connection and attempts to retransmit the entire group of files. However, the receiving PC immediately informs the sending PC that the last transfer was incomplete and informs the sending PC of the successfully received amount. In a preferred embodiment, the receiving PC subtracts a stored amount from the amount actually received to compensate for any errors that may have occurred near the end of the interrupted transmission. The sending PC, then calculates what portion of the group has not been sent, that is, the second segment, and sends the second segment to the same receiving computer.

Upon receipt, the receiving PC overwrites an equal amount in the store at the end of the first segment and then merges two discrete segments into a single pack of compressed files without losing the contents of the file. In the case of additional interruptions, the process is repeated until the entire file is successfully received or until the Send PC stops the attempt to send the group of files. Typically, the sending PC stops this shipment when it finds excessive errors.

Polling: See Figure 13 The present invention is also directed to polling connection status periodically of the destinations listed in the destination window. The polling of the connection state implies requesting a return of the destination identifiers from all the other registered PCs, in order to determine which destinations of the PC have active connections, through which the communication could be initiated. A visible indication can be provided, which shows each identified active connection, thus notifying the user of which PC destinations are available to receive a communication request. The polling destinations for the connection state are similar to treble sounds in remote sites in the UNIS system. However, polling the connection state is more sophisticated because it not only determines whether the site is active, but also determines that the identity of the site is indeed an intended recipient. The check for the routines of active IP connections, shown in Figure 13, update the connection status for the destinations listed in the destination window, as well as the number of credits remaining. Referring to Figure 13, the exemplary logic for executing the polling process of the connection state will now be described. In step 1300, the logic determines the first destination in the destination bar. Then, in step 1302, an ID packet is sent to the address listed for the destination. In cap 1304, the brand destinations as inactive and is displayed accordingly, for example, muffled. In step 1306 it is determined whether a response was received from the destination. If a response is received, the program compares the response to the station name, or another authentication code word, to ensure that it matches when it is in the file. If it matches, the destination is marked active and the file transfer can be done. Thus, in step 1308, the destination is marked as active and exhibited accordingly. Next, in step 1310, it is determined whether any other destination has not been polled in the state. Similarly, if it is determined in step 1306 that no response has been received or there is no match, the packet ID is simply thrown and the destination is left idle, and in step 1310 it is determined whether any other destination has not been polled in the state. If any destination has not been polled in the state, the next destination is determined in step 1312 and the logic returns to step 1302 and is repeated for that destination. If in step 1310 it is determined that all destinations have been canvassed in the state, in step 1312 the displayed credit is updated to show the number of remaining credits. Then, the process ends in step 1314. According to a preferred embodiment, the process of polling states repeats periodically, for example every 20 seconds. When a remote site receives the ID packet, the module of the receiving file, in step 422, sends again the name of the station of the receiving PC and any other required authentication data, as established in the adjustment, which could include the authentication codes, for example. As an example, a preferred embodiment of the present invention, applied to the business model of the International Postal Service, includes an unlimited number of user computer services, which have an active connection to a communications path., such as the Internet. Each computer operates the computer program of the present invention, enabling the coded, parallel, substantially simultaneous, direct transfer of files between a computer and any number of other computers. The electronic receivers are automatically generated and automatically returned to the senders by means of a "third party in trust" certification processor, which documents the files received in the destination computers. The transportation of files between senders and recipients is immediate and direct. Service users pay for the transportation of files through a reduction of credits in a credit account located locally on each user's computer, and credits are restored electronically in proportion to payments in specified current regimes, with both charges as the restoration being in accordance with a policy of the service provider. The security of file transport is ensured through user authentication and robust file coding. For example, computers that operate as the following service processors: (1) one or more credit request processors, (2) one or more return receipt certification processors, and / or (3) one or more issuers of coding / decoding keys, processors, the management of the authenticator or security policy (in second, the security server) are present, operating and available through an active connection to the communication path. The physical location of these process computers is important only for the security policy and reasons for payment of the user's service, however, the physical security of the processors is required. These emergencies are resolved in accordance with the policy of the service provider. Eligibility for service use is gained through authentication and registration of the user's identity in the security server. Access to the use of the service is gained through the installation and use of the computer program of the present invention. The computer program is obtained, for example, at the time of user registration. The use of the service consumes credits in the credit account stored in a user's computer or in an external device (for example, the Smart Card, obtained in the registry). The use of continuous service over time requires the replenishment of credits through automatic requests for credits issued to a credit processor. The payment of the credits issued is in accordance with the invoice or collection procedures and systems of the service providers. Credit authorization is returned from a credit processor to a user's computer over the communication path (ie, the Internet) and the user's credits are replenished.

Depending on the preference of the service provider, the coding of the public key or the time padding coding may be performed. Files can be encoded before transporting using public keys for each destination obtained by each sender from the third-party security server in charge. Alternatively, the time filings automatically obtained for each transaction between the sender and receiver from the third-party security server in charge, can be used to encode files before transport. The encoded files together with the identity of the authenticated user, and the "noise" ("electronic fingerprint") of the files that are sent, are transported directly between computers over the communication path (ie, the Internet) without passing through of the processors or the security server. The received files can be decoded using the private key of receivers if the coding of the public key is performed. Alternatively, the received files can be automatically decoded if the time padding coding is performed and the identity of the recipient and request for decoding in the security server comply with the security policy performed. Several security service policies, such as coding from station to station, or from person to person, can be performed. Full file transport transactions are certified by the sender for a return receipt that is (1) generated by the computer program of the present invention, installed on the file receiver computer, (2) automatically transported on the Internet to the certification processor, (3) "subsequently marked" by the third party processor in charge (certification processor), and (4) automatically transported from the certification processor to the file sender's computer. The return receipt generated by the file receiver's computer may contain certain information, such as the date and time of receipt of the file, parts in the exchange for the registered identity, an electronic fingerprint of the transported files and characteristics of the files received. Upon certification of the return receipt by the third-party certification processor in charge, a range of additional information may be added, such as the date and time of the certification, the date and time of the encoding and decoding (obtained from the server security) and the "subsequent mark" certification of the third party certification authority in charge. Other embodiments of various business models are considered in accordance with the present invention. Systems considered include those in which (1) large arrays of computers or switching devices transport files primarily to one or relatively few target computers; (2) one or relatively few computers transport files to computer arrays or switching devices; and (3) at least some of the functions of the system of the present invention are performed, enabling direct, substantially simultaneous, pallet, encoded, transfer of files between a computer and any number of other computers, and enabling the generation of receipts e-mails directly returned automatically or certified through a third party in charge, and then returned to the senders, documenting the files received on the destination computers.

Although the present specification describes the components and functions carried out in the modalities, with reference to particular standards and protocols, the invention is not limited to such standards and protocols. For example TCP / IP and the Internet are mentioned through this specification as representative examples of the state of the art. NeverthelessSuch rules are periodically dismissed by faster and more efficient equivalents, which essentially have the same functions. Therefore, replacement standards and protocols, which have the same functions, are considered equivalent. While the invention has been described with reference to several exemplary embodiments, it will be understood that the words that have been used are words of description and illustration, rather than words of limitation. Changes can be made, within the point of view of the appended claims, as stated herein and as amended, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described with reference to particular elements, materials and embodiments, this invention is not limited to these disclosed particulars; rather, the invention extends to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims.

Claims (17)

1. R E I V I N D I CA C I O N E S 1. A device for transferring files, which transfers data to at least one \ remote device, this device for transferring 5 files comprises: at least one listening door, which receives a control connection from at least one remote device; and at least one data gate, dynamically assigned 10, for data transfer with at least one remote device, each data gate enables data transfer; in which the control connection is used to transmit the address of at least one data gate, 15 dynamically assigned, k in which data is transferred substantially simultaneously, with multiple remote devices, by means of dynamically assigned data ports.
2. 2. The file transfer device 20 of claim 1, wherein the control connection is further used to receive the data transfer characteristics and authenticates the remote device, verifying the identification information of the remote device, this information of identification is transmitted from this remote device.
3. 3. The file transfer device of claim 1, wherein the control connection further comprises a selective acceptance system, which compares the identification information of the remote device with a list of destination identities, stored in a local device and prohibits the transfer of data from remote devices that are not within the list of destination identities.
4. 4. The device for file transfer of claim 1, wherein each device sends and receives, substantially simultaneously, data to and from multiple devices.
5. 5. The device for file transfer of claim 1, further comprising a return receipt system, which generates and sends a return receipt from a device that received the data transfer to a device that transferred the data, after completion successful of this data transfer.
6. 6. The device for file transfer of claim 5, which also comprises a certification system, which communicates with an independent certification processor, which verifies the return receipts, this independent certification processor sends verification certifications to a device that initiated the transfer of data, upon successful completion of this data transfer, in which the return receipt system generates and sends a return receipt from the device that received the data transfer to the independent processor of certifications, upon successful completion of the transfer of data. data.
7. 7. The device for file transfer of claim 1, wherein each data port is represented by a sleeve data structure.
8. 8. The file transfer device of claim 7, in which each device stores the sleeve data structures in a linked list, to handle the flow of data transfers, this linked list being cross-linked to enable data transfers substantially in shape. simultaneous 9. The file transfer device of claim 1, further comprising a credit system, which maintains and monitors data transfer credits, and detects each data transfer in order to download a credit account after a data transfer successful, this data transfer is only allowed when a device, which initiates the transfer, has sufficient credits. 10. The device for file transfer of claim 9, wherein a number of credits available for the device is displayed dynamically in each device. 11. The file transfer device of claim 9, wherein a transmission device comprises an encoder system, which encodes selected files prior to transmission, and a receiver device, comprising a decoder system, which decodes each encoded file in its reception, in which the number of credits in the transmission device is modified by at least one additional credit in each successful file transfer, which employs the encoding. 12. The device for file transfer of claim 9, further comprising a credit application system, which requests additional credits from an external credit processor, in response to a request from a device for additional credits, this external credit processor validates the accounting information of the device that requests and distributes additional credits and this accounting information is valid. 13. The device for file transfer of claim 1, further comprising an index system, which defines an index that can be requested by the remote devices by means of the connection, this index comprises information indicating at least one file of which the remote computer can request a copy by means of data transfer, and an associated destination, devices that correspond to the associated destination, that have exclusive access to the index. 14. The device for file transfer of claim 13, further comprising an index request system, which allows a requesting device to select the remote device, where a request for an index will be sent, this request is sent to the selected remote device , this selected remote device returns the index to the requesting device, this requesting device stores the index in a storage device. 15. The device for file transfer of claim 14, wherein each file listed in the index, is selected by the requesting device, this requesting device requests that a copy of the selected file be transferred from the selected remote device, this remote device selected file transfers each file in response to the request. 16. The file transfer device of claim 1, wherein each device further comprises: a variable number of linked destination directories, each destination linked directory is associated with another device, in addition each linked directory of [»Destination comprises a file storage area in the 5 device; and in which the file transfer device comprises a directory address system, bound to the destination, which detects the storage of at least one data file in the bound directory of the destination and initiates a transfer of the detected data file to the destination. associated device, in response to this detection. 17. The file transfer device of claim 1, further comprising: an active connection inspection system, which periodically determines whether each remote device in a list, from at least one remote device, is currently actively connected to a communication path, accessible to a local device; 20 a validation system, which validates each remote device in the list of at least one remote device, which is currently actively connected to the communication path accessible to the local device; and an inspection system, which delegates a fr file transfer to a moment when the selected remote device 5 becomes actively connected to the communications path, accessible to the local device, if this selected remote device is not currently actively connected to the communication path, accessible to the local device. 18. The file transfer device of claim 1, further comprising a parallel polling system, which causes a local device to scan a directory on at least one of the remote devices, this directory is associated with an assigned destination, he The local device requests all the data within the directory to be transferred to the local device, in which multiple remote devices are probed substantially simultaneously and the data is transferred substantially simultaneously to the 20 local device from all remote devices, and in which data is always transferred to the assigned destination. 19. The file transfer device of claim 1, wherein the data transfer occurs by only registering on any intermediate computer, which provides a means of signal propagation for the transfer, without storage, through the propagation medium. 20. A method for file transfer, which enables data transfers between a local device and at least one remote device, this method comprises: A. establishing a connection with this at least one remote device by means of the previously established listening ports, that reside within each device; B. dynamically assign a data gate within the local device, each data gate within the local device enables data transfer; and C. transmitting the address of the data gate to this at least one remote device, by means of listening doors; and D. transferring the data in a data transfer, between the connected devices, by means of the data ports, the data being transferred, substantially simultaneously, between multiple remote devices and the local device by means of assigned data ports dynamically 21. The method of claim 20, further comprising, after establishing the connection of A, receiving the data transfer characteristics and authenticating this at least one remote device, verifying the wake identification information minus a remote device, this information of identification being transmitted to at least one remote device. 22. The method of claim 21, further comprising comparing the identification information of the remote device with a list of destination identities, stored in the local device and prohibiting data transfers from remote devices that are not within the identity list. of destiny. 23. The method of claim 20, wherein the local device sends and receives, substantially simultaneously, data to and from multiple devices. 24. The method of claim 20, further comprising generating and sending a return receipt, which includes the destination origin point and the successful termination information, from a device that received the data transfer, to a device that transferred the data in the successful completion of this data transfer. 25. The method of claim 24, which further comprises communication with an independent certification processor, which verifies the return receipts for the originating point, information destination of the successful termination, this independent certification processor sends a certification of the verification to the device that transferred the data, after the successful completion of this data transfer in which the device that received the data transfer generates and sends a return receipt to an independent certification processor upon the successful completion of this data transfer . 26. The method of claim 20, wherein each data port is represented by a sleeve data structure. 27. The method of claim 26, wherein each device stores the sleeve data structures in a linked list, to handle the flow of 10 data transfers, this linked list being crossed to enable data transfers substantially simultaneously. 28. The method of claim 20, further comprising maintaining and monitoring the credits of the ? 15 data transfer and detect each data transfer, in order to load a credit account after a successful data transfer, this data transfer is only allowed when the device, which initiates the transfer, has sufficient credits. 29. The method of claim 28, further comprising requesting additional credits from an external credit processor, in response to a request from one of the devices for additional credits, this external credit processor validates the accounting information of the device. of application and distributes 5 additional credits, if the accounting information is validated. 30. The method of claim 20, further comprising defining an index, which may be requested by the remote devices by means of the connection, this The indicator includes the information indicating at least one file that the remote computer can request a copy by means of the data transfer, and an associated destination. 31. The method of claim 30, wherein the associated destination is a specific destination, and the devices corresponding to the specific destination have exclusive access to the index. 32. The method of claim 30, wherein the associated destination is a general destination, and all the 20 remote devices have access to the index. 33. The method of claim 30, further comprising allowing a requesting device to select a remote device, where a request for an index will be sent, this request being sent to the selected remote device, this selected remote device returns the index to the requesting device , this request device stores the index in a storage device. 34. The method of claim 33, wherein any file listed in the index is selected by the requesting device, this requesting device requests that a copy of the selected file be transferred from the selected remote device, this selected remote device transfers each file into response to the request. 35. The method of claim 20, wherein each device further comprises: a variable number of linked destination directories, each destination linked directory is associated with another device, in addition each destination linked directory comprises a file storage area in the device; and wherein the method further comprises detecting the storage of at least one data file in the destination linked directory, and initiating a transfer of the detected data file to the associated device, in response to such detection 36. The method of claim 20, further comprising: periodically determining whether each remote device in the list of at least one remote device is currently actively connected to a communication path accessible to the local device validate each remote device in the list of at least one remote device, which is currently actively connected to the communication path accessible to the local device; and delegate a file transfer at a time, when the selected remote device becomes actively connected to the communication path, accessible to the local device, if this selected remote device is not currently actively connected to the communication path, accessible to the local device. 37. The method of claim 20, further comprising polling a directory on at least one of the remote devices, this directory is associated with an assigned destination, and requesting that all data within the directory be transferred to the local device, in which multiple devices remotes are probed substantially simultaneously and the data is transferred substantially simultaneously to the local device from all the multiple remote devices, and in which data is always transferred to the assigned destination. 38. The method of claim 20, wherein the established connection comprises more than one connection, each connection being between two devices by means of a different pair of listening ports., each device selects listening doors from a predetermined range of available doors. 39. A method of file transfer, which makes it possible to transfer data between a local device and at least one remote device, this method comprises: establishing a connection with this at least one remote device, by means of established listening ports. previously, that reside within each device; receiving an address of a first data gate from this at least one remote device by means of the listening ports; dynamically assigning a second data gate, corresponding to the first data gate within the remote device, in the local device, each data gate within the local device enables data transfer; and transferring the data between the connected devices by means of the data ports, this data being transferred substantially simultaneously to multiple remote devices by means of the dynamically assigned data ports. 40. The method of claim 39, further comprising, after establishing the connection, transmitting the characteristics of the data transfer. 41. The method of claim 39, wherein each local device sends and receives, substantially simultaneously, data to and from multiple devices. 42. The method of claim 39, further comprising generating and sending a return receipt, which includes the point of origin, destination and the successful termination information, from a device that received the data transfer to a device that was transferred the data, after the successful completion of the data transfer. 43. The method of claim 42, which further comprises communicating with an independent certification processor, which verifies the return receipts for the point of origin, destination and the successful termination information, this independent certification processor sends the certification of the verification to the device that transferred the data, after the successful completion of the data transfer. in which the device that received the data transfer generates and sends a return receipt to the processor A * X 'independent certification, in the successful completion of the data transfer. 44. The method of claim 39, wherein each data port is represented by a sleeve data structure. 45. The method of claim 44, wherein each device stores the sleeve data structures in a linked list, to handle the flow of data transfers, the linked list being crossed to enable the data transfers substantially simultaneously. 46. The method of claim 39, which further comprises maintaining and monitoring the credits of the data transfer and detecting each data transfer in order to load a credit account after a successful data transfer, this data transfer is only allowed when the device, which initiates the transfer, has sufficient credits. 47. The method of claim 46, further comprising requesting additional credits from an external credit processor, in response to a request from a device for additional credits, this external credit processor validates the accounting information of the requesting device and distributes credits additional if this accounting information is validated. 48. The method of claim 39, further comprising defining an index, which may be requested by the remote devices by means of the connection, this index comprises the information indicating at least one file from which the remote device may request a copy by means of of the data transfer, and an associated destination, at least one device corresponding to the associated destination, which has exclusive access to the index. 49. The method of claim 48, further comprising allowing a requesting device to select a remote device, where a request for an index will be sent, this request being sent to the selected remote device, if the selected remote device stores the index in a remote device. storage . 50. The method of claim 49, wherein any file listed in the index is selected by the requesting device, this requesting device requests that a copy of the selected file be transferred from the selected remote device, which transfers each file in response to the request. 51. The method of claim 39, wherein each device further comprises: a variable number of linked destination directories, each destination linked directory is associated with another device, in addition each destination linked directory comprises a file storage area in the device; and wherein the method further comprises detecting the storage of at least one data file in the destination linked directory, and initiating a transfer of the detected data file to the associated device, in response to such detection 52. The method of claim 39, further comprising: periodically determining whether each remote device in the list of at least one remote device is currently actively connected to a communication path accessible to the local device to validate each remote device in the list of F. at least one remote device, which is currently actively connected to the communication path accessible to the local device; and delegate a file transfer at a time, when the selected remote device becomes actively connected to the communication path, accessible to the local device, if this selected remote device is not currently actively connected to the communication path, accessible to the local device. 53. The method of claim 39, further comprising polling a directory on at least one of the remote devices, this directory is associated with an assigned destination, and requesting that all data within the directory be transferred to the local device, in which multiple remote devices are probed 20 substantially simultaneously and the data is transferred substantially simultaneously to the local device, from all the multiple remote devices, and in which the data is transferred to the assigned destination. L? 54. A device for transferring files, which transfers data with at least one remote device, this device for data transfer comprises: at least one listening door, through which the control connection is established to the device remote, this control connection being used to Determine a remote data gate to transfer data, each data gate enables a data transfer; and at least one data gate, dynamically assigned, for the data transfer with the remote data gate, the data is transferred, 15 substantially simultaneously, with multiple f remote devices by means of dynamically assigned data ports. 55. The file transfer device of claim 54, wherein the control connection is further used to exchange the characteristics of the data transfer. 56. The device for file transfer of claim 54, wherein each device sends and receives, substantially simultaneously, data to and from multiple devices. 57. The device for file transfer, of claim 54, further comprising a return receipt system, which generates and sends a return receipt, which includes the point of origin, destination and the successful termination information, from a device that received the data transfer to a device that transferred the data, after the successful completion of the data transfer. 58. The file transfer device of claim 57, which also comprises an independent certification processor, which verifies the return receipts for the point of origin, destination and the successful termination information, this independent certification processor sends the certification from verification to the device that transferred the data, after the successful completion of the data transfer. in which the return receipt system generates and send a return receipt from the device you received the data transfer to the independent processor of f. certification, in the successful completion of the transfer 5 of data. 59. A device for the transfer of archives of claim 54, wherein each door of data is represented by a data structure of cuff 10 60. The device for file transfer of claim 59, in which each device stores the sleeve data structures in a list linked, to handle the flow of data transfers, the linked list being crossed to enable the 15 data transfers, substantially simultaneously. 61. The device for file transfer of claim 54, further comprising a system of credit, which maintains and monitors the credits of the 20 data transfer and detect each data transfer In order to charge a credit account after a successful data transfer, this data transfer is only allowed when the device, which initiates the transfer, has sufficient credits. 62. The device for file transfer of claim 61, wherein a number of credits available to the device, is displayed dynamically on each device. 63. The file transfer device of claim 61, wherein a transmission device further comprises an encoder system, encoding selected files, prior to transmission, and a receiving device further comprising a decoder system, which decodes each encoded file into reception, in which the number of credits in the transmission device is modified by at least one additional credit in each successful file transfer, which employs coding. 64. The device for file transfer of claim 61, further comprising a credit application system that requests additional credits from an external credit processor, in response to a request from a device for additional credits, this external credit processor validates the accounting information of the requesting device and distributes additional credits if this accounting information is validated. 65. The device for the file transfer of claim 54, further comprising an index system, which defines an index, which can be requested, by the remote devices by means of the connection, this index comprises the information indicating at least a file from which the remote device can request a copy by means of the data transfer, and an associated destination, devices that correspond to the specific destination, which has exclusive access to the index. 66. The device for file transfer of claim 65 further comprises an index request system, which allows a requesting device to select a remote device, where a request for an index will be sent, this request being sent to the selected remote device. , this selected remote device returns the index in a request device, the request device stores the index in a storage device. 67. The device for file transfer of claim 66, wherein each file listed in the index is selected by the requesting device, this requesting device requests that a copy of the selected file be transferred from the selected remote device, which transfers each file in response to the request. 68. The device for file transfer of claim 54, wherein each device further comprises: a variable number of linked destination directories, each destination linked directory is associated with another device, in addition each destination linked directory comprises an area of storage of file on the device; and wherein the file transfer device further comprises a linked directory management system, which detects the storage of at least one data file in the destination linked directory and initiates the transfer of the detected data file to the associated device, in response to such detection 69. The device for file transfer of claim 54, further comprising: an active connection monitoring system, which periodically determines whether each remote device in the list of at least one remote device is currently actively connected to a communication path accessible to the local device a validation system, which validates each remote device in the list of at least one remote device, which is currently actively connected to the communication path accessible to the local device; and a surveillance system, which delegates a file transfer at a time, when the selected remote device becomes actively connected to the communication path, accessible to the local device, if this selected remote device is not currently actively connected to the communication path, accessible to the device local f 70. The device for the transfer of archives of claim 54, which further comprises 5 poll a directory on at least one of the devices remote, this directory is associated with a destination assigned, the local device requests that all data within the directory are transferred to the device local, in which multiple remote devices are polled, 10 substantially simultaneously, and the data is transferred substantially simultaneously to the local device, from all the multiple devices remote, and in which the data is transferred to the destination assigned. 15 71. A computer data signal, incorporated r into a propagation medium, this signal enables a number variable of data transfers and comprises: A. a code segment of a connection source initial, which establishes a connection between two devices, 20 by means of predetermined listening doors, at least one predetermined listening door resides within each device; ^ dynamically assign a first data gate within a first device; and 5 transmitting the address of the first data gate to a remaining device by means of predetermined listening ports; and B. a segment of the code of the data transfer source for each of the variable number of 10 data transfer operations, which dynamically assign a second data gate within the remaining device, which corresponds to the first data gate within of the first device, each pair of the first and second data ports is established 15 in response to each listening gate connection; Y ? transferring data between the connected devices by means of the data ports, these data are transferred, in substantially simultaneous form, between a variable number of devices, by means of the doors of 20 data, assigned dynamically. 72. The signal of claim 71, wherein the code segment of the initial connection source also exchanges the characteristics of the data transfer and authenticates the remaining device, verifying the identification information of the remaining device transmitted from this remaining device. 73. The signal of claim 72, wherein the code segment of the initial connection further comprises a selective acceptance source code segment, which compares the identification information of the remaining device with a list of destination identities, stored in the first device and prohibits data transfers from devices that are not within the list of destination identities. 74. The signal of claim 71, wherein each device sends and receives, substantially simultaneously, data to and from multiple devices. 75. The signal of claim 71, further comprising a code segment of the return receipt source, which generates and sends a return receipt, which includes the destination origin point and the successful termination information, from a device that received the data transfer, to a device that transferred the data in the successful completion of this data transfer. If 76. The signal of claim 75, further comprising a segment of the certification source code, which communicates with an independent certification processor, which verifies the return receipts for the origin, destination and information point of the successful termination, this independent certification processor sends a certification of the verification to the device 10 that transferred the data, after the successful completion of this data transfer in which the source code segment of the return receipt generates and sends a receipt of return to an independent certification processor at the successful completion of this data transfer. ? eleven . The signal of claim 71, wherein each data port is represented by a sleeve data structure. 78. The signal of claim 77, wherein Each device stores the sleeve data structures in a linked list, to handle the flow of data transfers, this linked list being cross-linked to enable the data transfers substantially simultaneously. The signal of claim 71, which further comprises a segment of the code of a credit source, which maintains and monitors the credits of the data transfer and detects each data transfer, in order to charge a credit account after a successful data transfer, this data transfer is only allowed when the device, which initiates the transfer, has sufficient credits. 80. The signal of claim 79, wherein the remaining device comprises a transmission device, which includes a segment of the coding source code, which encodes the data selected before transmission; and the first device comprises a receiving device, which includes a code segment of the decoding source, which decodes each encoded file in the reception; in which the credits of the data transfer comprise a defined number of credits, and where this number of credits in the transmission device is modified by at least one additional credit in each successful data transfer using the coding. 81. The signal of claim 79, further comprising a code segment of the credit request source, requesting additional credits from an external credit processor, in response to a request from one of the devices for additional credits, this external processor of credits validates the accounting information of the application device and distributes additional credits, if the accounting information is validated. 82. The signal of claim 71, further comprising an index source code segment, which defines an index for the request by the remote devices by means of the connection, this index is associated with at least one destination and lists the representative information of at least one file that remote devices can request, the devices corresponding to the associated destination have exclusive access to the index. 83. The signal of claim 82, further comprising a code segment of the index request source, which allows a requesting device to select a particular remote device, to which a request for an index will be sent, this request is sent to the remote device selected, the remote device returns the index to the request device, and this request device stores the index in a storage device. 84. The signal of claim 83, further comprising a code segment of the index transfer source, which, in response to each file listed in the index selected by the requesting device, allows the requesting device to require a copy of the selected file, to be transferred from the remote device, this remote device transfers each file in response to the request. 85. The signal of claim 71, wherein the code segment of the initial source establishes more than one connection, each connection being between two devices by means of a different pair of listening ports, each device selects listening ports from a Default range of doors available. 86. The signal of claim 71, wherein each device further comprises: a variable number of linked destination directories, each destination linked directory is associated with another device, and each linked directory of 10 destination is a file storage area on the device; and wherein the signal further comprises a code segment of the address source of the destination linked directory, which detects storage of at least one 15 data file to the associated device, in response to detection. 87. The signal of claim 71, further comprising: a segment of surveillance code of the connection 20 active, which periodically determines whether each remote device in a list of at least one remote device, is currently actively connected to a communications path, accessible to a local device; a validation source code segment, which validates each remote device in the list of at least one remote device, which is currently actively connected to the communications path, accessible to the local device; and a surveillance source code segment, which delegates a file transfer to a moment when the selected remote device becomes actively connected to the communication path, accessible to the local device, if this selected remote device is not currently connected in the form activates the communication path accessible to the local device. The signal of claim 71, further comprising a parallel polling source code segment, which causes a local device to probe a directory on at least one of the remote devices, the directory associated with an assigned destination, the local device which requests all data within the directory to be transferred to the local device, in which multiple remote devices are substantially polled simultaneously and the data is transferred substantially simultaneously to the local device from all remote devices and in which the data is transfer to the assigned destination. 89. A system for the delivery of data files, which deliver data files among a variable number of devices, this system comprises: a variable number of similar systems, each similar system has: a connection negotiation system, to open at least one listening door for exchanging control data; a data connection system, to open a variable number of data gates, each associated with a destination, to exchange data files; a file selection system, to select a variable number of data files residing in at least one such system, designed as a source of files; and a destination selection system, to select a variable number of destinations, to receive the selected data files. at least the source of files, which has a transmission system for the sending, without storage, of the selected data files on a variable number of data communication paths, corresponding to data ports, the destinations of each have a receiving system to receive, without storage, the files sent by means of the shipment, without storage, and at least one of the source of files and the destination that has an initiation system, to start the operation of the transmission system, by means of at least one communication negotiation path to at least one listening door, from or the source of files or the destination. 90. The data file delivery system of claim 89, wherein each file source is also a destination having a receiving system for receiving, without storage, the files sent by the shipment without storage by at least one other such system, which acts as a subsequent file source at the same time as the transmission system operates. 91. The data file delivery system of claim 89, wherein each similar system further comprises: a variable number of linked destination directories, each associated with another device, each destination linked directory is also a storage area of files on the device; and a destination linked directory management system, to detect the storage of at least one data file in the corresponding file storage area and to control the initiation system to initiate the operation of a transreceptor system (transmitter-receiver) in response to detection. 92. The data file delivery system of claim 89, wherein each similar system further comprises: a return receipt system, for generating and sending a return receipt, which includes the point of origin, destination and information successful termination from each similar destination system, which receives the selected files to the file source on the communications path, without storage, which corresponds to the data ports in the successful completion of the reception, without storage, of the files selected. 93. The file delivery system of claim 92, further comprising: a processor of the third party transaction certificate, for examining and verifying the return receipts of the origin, destination and successful completion information, and for sending the certificate of verification of data files on a first additional communication path, without storage, corresponding to a first additional data gate to the similar file source system in the successful completion of the reception, without storage, of the selected files; in which the return receipt system generates and sends a return receipt from each destination, which receives the selected files to the processor of the third party transaction certificate on a second communication path, without storage, corresponding to a second gate of Additional data in the successful completion of the reception without storage of the selected files. 94. The file delivery system of claim 89, wherein each similar system further comprises: a file credit monitoring system, to maintain and monitor file delivery credits, the file credit monitoring system that detects each shipment, without storage, of selected file and load into the variable credit account in a similar associated system, according to a function based on the shipment, without storage. 95. The file delivery system of claim 89, further comprising: a credit processor, for receiving credit applications, and for increasing a variable credit account in an associated similar system, upon receipt of a credit application and the successful comparison of the credit application against a credit authorization function; in which the credit monitoring system generates and sends a request for credit from one of the systems similar to the credit processor. 96. The file delivery system of claim 89, wherein each similar system further comprises: an index generating system, for generating a file index in a similar system; an index request system, to request and retrieve an index of the files from any of the variable number of similar systems; a subset selection system, to select a subset of a variable number of files, from the retrieved index of files, from any of the variable number of similar systems; and a file subset request system, to initiate the operation of the transceiver system to transfer the subset of any of a variable number of systems similar to this similar system. 97. The file delivery system of claim 89, wherein each similar system further comprises: a transceiver management system, APRA to handle the substantially parallel and simultaneous operation of a variable number of transceiver systems, to send, without storage , in a substantially parallel and simultaneous manner, and receive, without storage, the selected files on a plurality of communication paths, corresponding to a plurality of data ports. 98. The file delivery system of claim 89, in which the transfer of data through the communications path occurs without registration on any intermediate computer, without registration on the destination and without the intermediate storage of the files transmitted on an intervening computer. 99. The file delivery system of claim 89, wherein the connection to the destination via the data gate is a destination address received with the control data. 100. The file delivery system of claim 89, wherein when a file is saved to a predetermined directory, associated with a destination, the file is transferred to the destination. 101. A file transfer system, to transfer the files between at least one local computer and at least one remote computer, selected from a list of at least one remote computer, through at least one communication path, this system of file transfer includes: a file selector, which selects at least one file stored on the local computer, to transfer to at least one remote computer; a destination selector, which selects from the list of at least one remote computer, at least one remote computer designed as a destination computer, to which the file will be transferred; a transmitter, which transfers the selected file to the destination computer via at least one communications path, without storing the selected file in any intermediate computer; a receiver, who receives the transferred file; an initial connection system, which establishes a connection between the local computer and the destination computer by means of predetermined listening ports, at least one predetermined listening door resides within each computer, the data transfer characteristics are exchanged during the initial connection, the identities of the local and destination computers are authenticated by verifying each computer identification information; a first allocation element, which dynamically allocates a first data gate, represented by a sleeve data structure, within the destination computer; a first transmitter, which transmits the address of the first data port to the local computer by means of the predetermined listening ports; a second allocation element, which dynamically allocates a second data port, represented by a sleeve data structure within the local computer, which corresponds to the first data gate within the destination computer, each first and second pair Data gate is assigned dynamically in response to each listening gate connection; a second transmitter, which transfers the data between the computers connected through the data ports, the data is transferred substantially simultaneously between a variable number of computers by means of the dynamically assigned data ports; in which each computer is capable of sending and receiving substantially simultaneously, data, in which each computer dynamically manages ft 'data structures of the sleeve to enable the 5 data transfers substantially simultaneously, a generator that generates and sends a receipt return, which includes the point of origin, destination and successful termination information, from the computer that received the file transfer to the computer that transferred the file, and an independent certification processor, in the successful completion of the transfer of files; a third transmitter, which communicates with the independent certification processor, which verifies the return receipts for the destination point of origin and the successful termination information, this independent certification processor sends the certification of the verification to the computer that originated the transfer 20 of files, in the successful completion of this file transfer; a credit system, which maintains and monitors the credits of the file transfer and detects each file transfer in order to charge to a credit account after the successful file transfer, this file transfer will only be allowed when the computer , that initiates this transfer, has sufficient credits; and a credit application system, which requests additional credits from an external credit processor, in response to a request from a computer for the additional credits, this external credit processor validates the accounting information of the requested computer and the distribution of additional credits, when the accounting information is valid. SUMMARY OF THE INVENTION A device, system and method of file transfer are disclosed. These devices, systems and methods make it possible to transfer a variable number of data and include an initial connection system and a data transfer system. The initial connection system establishes connections between at least two devices, by predetermined listening ports, with at least one listening door residing within each of at least two devices. The initial connection system also dynamically allocates a first data gate within a first device, and transmits the address of this first gate to the remaining device by means of predetermined listening ports. This data transfer system is for each of a variable number of data transfer operations. This data transfer system dynamically assigns a corresponding second data gate within the remaining device and transfers the data between the connected devices by means of data ports, so that the data is transferred, substantially simultaneously, between a variable number of devices, via data ports. Each pair of the first and second data ports is established in response to each listening port connection.