Coherency (e.g., same view to multiple users)

Methods and apparatus for secure electronic, certified, restricted delivery mail systems

6442571

Abstract

A computer data signal embodied in a propagation medium is provided. The signal enables a variable number of data transfers and includes an initial connection source code segment and a data transfer source code segment. The initial connection source code segment establishes a connection between at least two devices via predetermined listening ports, with at least one predetermined listening port residing within each device. The initial connection source code segment 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 source code segment is for each of the variable number of data transfer operations. The data transfer source code segment 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 of first and second data ports is established in response to each listening port connection.


Claims

What is claimed is:

1. A receiving data transfer device that receives data and data transfer attributes electronically transferred from at least one remote device originating a data transfer, the receiving data transfer device comprising:

a delivery receipt system that generates a delivery receipt comprising data transfer attributes verification after successfully verifying that the received data is the same as the data sent by the at least one remote device;

a certifying system that communicates with an independent certifying processing device that certifies delivery receipts, the independent certifying processing device sending receipt certification to at least one of the devices involved in the data transfer after processing a delivery receipt, which certification comprises authentication of the data transfer using a postmark of a postal authority which postmark is a unique digital characterization of the delivery receipt,

wherein at least one successful data transfer to the receiving data transfer device is certified by the independent certifying processing device.

2. The receiving data transfer device of claim 1, further comprising a data transfer system that transfers data and associated data transfer attributes electronically with the at least one remote device originating the data transfer.

3. The receiving data transfer device of claim 1, in which access to the data transferred to the receiving device is restricted to an intended recipient using public key cryptography, security being assured through user authentication and data encryption.

4. The receiving data transfer device of claim 1, in which data transferred is encrypted prior to transport to receiving devices using at least one public key associated with each destination, and received encrypted data can only be decrypted using the intended recipient's private key, with data access control characteristic of standard public key cryptography.

5. The receiving data transfer device of claim 1, in which encrypted data is transferred to the receiving device, along with authenticated user identity and electronic finger print of the data transferred, without passing through the independent certifier or a security server.

6. The receiving data transfer device of claim 1, in which a delivery receipt is generated with no action required by the intended recipient.

7. The receiving data transfer device of claim 1, in which the certified delivery receipt further comprises a verifiable electronic postmark representation by a postal authority.

8. The receiving data transfer device of claim 7, in which the certified delivery receipt is uniquely identified and linked to a specific data transfer transaction by data transfer attribute elements and the electronic postmark of a postal authority.

9. The receiving data transfer device of claim 1, in which the unique digital characterization comprises digitally signing the delivery receipt, assuring at least in part tampering and modification detection.

10. The receiving data transfer device of claim 1, in which the data transfer attributes verification is independent of data access by an intended data transfer recipient.

11. The receiving data transfer device of claim 1, wherein the data comprises at least one file.

12. A data transfer system comprising:

an originating data transfer device originating a transfer of data and data transfer attributes;

an independent certifying processing device that sends a data transfer certification to at least one device involved in the data transfer after processing a delivery receipt, which certification comprises authentication of the data transfer using a postmark of a postal authority which postmark is a unique digital characterization of the delivery receipt;

a receiving data transfer device that receives the data and data transfer attributes, verifies that the received data is the same as the data sent by an at least one remote device, processes the delivery receipt comprising data transfer attribute verification, which indicates successful receipt of the data, after successful receipt of the data transferred, and communicates with the independent certifying processing device;

wherein at least one data transfer to the receiving data transfer device is certified when successful by the independent certifying processing device.

13. The data transfer system of claim 12, further comprising a first data transfer system, the independent certifying processing device comprising a second data transfer system, and the receiving data transfer device comprising a third data transfer system.

14. The data transfer system of claim 12, in which access to the data transferred to the receiving device is restricted to the intended recipient using public key cryptography, security being assured through user authentication and data encryption.

15. The data transfer system of claim 12, in which data transferred is encrypted prior to transport to receiving devices using at least one public key associated with each destination, and received encrypted data can only be decrypted using an intended recipient's private key, with data access control characteristic of standard public key cryptography.

16. The data transfer system of claim 12, in which encrypted data is transferred to the receiving device, along with authenticated user identity and electronic finger print of the data transferred, without passing through the independent certifier or a security server.

17. The receiving data transfer system of claim 12, in which a delivery receipt is generated with no action required by an intended recipient.

18. The data transfer system of claim 12, in which the certified delivery receipt further comprises a verifiable electronic postmark representation by a postal authority.

19. The data transfer system of claim 18, in which the certified delivery receipt is uniquely identified and linked to a specific data transfer by data transfer attribute elements and the electronic postmark of a postal authority.

20. The data transfer system of claim 12, in which the unique digital characterization comprises digitally signing the delivery receipt, assuring at least in part tampering and modification detection.

21. The data transfer system of claim 12, in which the data transfer attributes verification is independent of data access by an intended data transfer recipient.

22. The data transfer system of claim 12, wherein the data comprises at least one file.

23. A computer readable medium that stores a data transfer program for receiving data and data transfer attributes and certifying successful receipt of a data transfer electronically transferred from at least one device involved in a transaction to a receiving device, the medium comprising:

a delivery receipt source code segment that generates a delivery receipt comprising data transfer attributes verification after successfully verifying that the received data is the same as the data sent by an at least one remote device;

a certifying source code segment that communicates with an independent certifying processing device that certifies delivery receipts, the independent certifying processing device providing certification to at least one of the devices involved in the data transfer after processing the delivery receipt, which certification comprises authentication using a postmark of a postal authority which postmark is a unique digital characterization of the delivery receipt,

wherein at least one successful data transfer is certified by the independent certifying processing device.

24. The medium of claim 23, in which access to the data transferred to the receiving device is restricted to an intended recipient using public key cryptography, security being assured through user authentication and data encryption.

25. The medium of claim 23, in which data transferred is encrypted prior to transport to receiving devices using public keys associated with each destination, and received encrypted data can only be decrypted using an intended recipient's private key, with data access control characteristic of standard public key cryptography.

26. The medium of claim 23, in which encrypted data is transferred to the receiving device, along with authenticated user identity and electronic finger print of the data transferred, without passing through the independent certifier or a security server.

27. The medium of claim 23, in which a delivery receipt is generated with no action required by an intended recipient.

28. The medium of claim 23, in which the delivery receipt further comprises a verifiable electronic postmark representation by a postal authority.

29. The medium of claim 23, in which the delivery receipt is uniquely identified and linked to a specific data transfer by data transfer attribute elements and the electronic postmark of the postal authority.

30. The medium of claim 23, in which the unique digital characterization further comprises digitally signing the delivery receipt, assuring at least in part tampering and modification detection.

31. The medium of claim 23, in which the data transfer attributes verification is independent of data access by an intended data transfer recipient.

32. The medium of claim 23, wherein the data comprises at least one file.

33. A method for receiving data and data transfer attributes and certifying successful receipt of a data transfer electronically transferred from at least one originating remote device to a receiving device, the method comprising:

generating a delivery receipt comprising data attributes verification after successfully verifying that the received data is the same as the data sent by the at least one remote device;

communicating with an independent certifying processing device that verifies delivery receipts; and

sending certification from the independent certifying processing device to at least one device involved in the data transfer after processing the delivery receipt, which certification comprises authentication using a postmark of a postal authority which postmark is a unique digital characterization of the delivery receipt,

wherein the independent certifying processing device certifies at least one successful data transfer to the receiving device.

34. The method of claim 33, transferring data and associated data transfer attributes electronically with at least one remote device originating a data transfer.

35. The method of claim 33, in which access to the data transferred to the receiving device is restricted to an intended recipient using public key cryptography, security being assured through user authentication and data encryption.

36. The method of claim 33, in which data transferred is encrypted prior to transport to receiving devices using public keys associated with each destination, and received encrypted data can only be decrypted using an intended recipient's private key, with data access control characteristic of standard public key cryptography.

37. The method of claim 33, in which encrypted data is transferred to the receiving device, along with authenticated user identity and electronic finger print of the data transferred, without passing through the independent certifier or a security server.

38. The method of claim 33, in which a delivery receipt is generated with no action required by an intended recipient.

39. The method of claim 33, in which the delivery receipt further comprises a verifiable electronic postmark representation by a postal authority.

40. The method of claim 39, in which the delivery receipt is uniquely identified and linked to a specific data transfer by data transfer attributes and the electronic postmark of the postal authority.

41. The method of claim 33, in which the unique digital characterization comprises digitally signing the delivery receipt, assuring at least in part tampering and modification detection.

42. The method of claim 33, in which the data transfer attributes verification is independent of data access by an intended data transfer recipient.

43. The method of claim 33, wherein the data comprises at least one file.

44. A method for transfer of data electronically over shared communication pathways from at least one remote device originating the transfer to a receiving device, the method comprising:

authenticating an identity of each intended party to the data transfer;

generating data transfer attributes characterizing the data transferred;

encrypting the data to restrict access to intended recipients of the data transferred;

sending the data transfer attributes and the encrypted data to the at least one receiving device;

receiving the data transfer attributes and the encrypted data by the at least one receiving device;

verifying received data transfer attributes providing verification that the received data is the same as the data sent by the at least one remote device;

processing a delivery receipt comprising data attributes verification after successfully verifying that the received data is the same as the data sent by the at least one remote device;

communicating with an independent certifying processor that certifies delivery receipts, the certification comprising authentication using a postmark of a postal authority which postmark is a unique digital characterization of a delivery receipt; and

sending certification from the independent certifying processor to at least one device involved in the data transfer after certifying the delivery receipt,

wherein the independent certifying processing device certifies at least one successful data transfer to the receiving device.

45. The method of claim 44, in which access to the data transferred to the receiving device is restricted to an intended recipient using public key cryptography, security being assured through user authentication and data encryption.

46. The method of claim 44, in which data transferred is encrypted prior to transport to receiving devices using public keys associated with each destination, and received encrypted data can only be decrypted using an intended recipient's private key, with data access control characteristic of standard public key cryptography.

47. The method of claim 44, in which encrypted data is transferred to the receiving device, along with authenticated user identity and electronic finger print of the data transferred, without passing through the independent certifier or a security server.

48. The method of claim 44, in which a delivery receipt is generated with no action required by an recipient.

49. The data transfer device of claim 44, in which the delivery receipt further comprises a verifiable electronic postmark representation by a postal authority.

50. The method of claim 49, in which the certified delivery receipt is uniquely identified and linked to a specific data transfer by data transfer attribute elements and the electronic postmark of the postal authority.

51. The method of claim 44 in which the unique digital characterization comprises digitally signing the delivery receipt, assuring at least in part tampering and modification detection.

52. The method of claim 44, in which the data transfer attributes verification is independent of data access by an intended data transfer recipient.

53. The method of claim 44, further comprising communicating with at least the originating remote device to certify successful data transfer.

54. The method of claim 53, wherein the data comprises at least one file.


Description

REFERENCE TO MICROFICHE APPENDIX

This application includes a microfiche appendix for Appendices A-D. The microfiche appendix consists of eight microfiche slides and 694 frames.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to transferring computer files electronically from one location to another, and more particularly to electronic transfer of computer files directly between two or more computers or computing devices.

2. Background of the Invention and Related Art

Expedited delivery of documents has for generations been of great concern to people and of great importance to their business interests. Methods of effecting expedited document delivery have progressed to include same day/next day physical delivery using international and domestic airways and roadways, as well as electronic delivery using interconnected networks of computers and telecommunications equipment, worldwide. Complex logistics systems have been erected by both government and commercial enterprises to effect relatively secure physical delivery of documents from the sender to the recipient. Examples include overnight express mail delivery offered by the U.S. Postal Service and express delivery service provided by private companies such as Federal Express, United Parcel Service, and DHL. Charges for delivery services rendered are typically on fixed fee basis (per delivery), with payment made at the time the service is performed, or made via a pre arranged account with the service provider or a third party credit provider (e.g. VISA or Master Card).

The complexity of these systems and the physical resources mobilized to support the expedited transfer service are relatively costly, with the costs being passed on to the service user. Extensive interconnected networks of computers and telecommunications equipment have been erected with the intent to lower the cost of communication, as well as to further expedite the transfer of information between sender and recipient. To an extent, the evolution from physical delivery to electronic delivery of documents has been successful as evidenced by the growth in the use of personal computers (PCS), the Internet and private intranets and extranets, albeit at the expense of the relative security of the document transfer. Examples of electronic transfer mechanisms in use across computer networks include electronic mail (e-mail) and file transfer protocol (FTP), both widely employed on the Internet. Examples of electronic transfer mechanisms in use across the public switched telephone network (PSTN) include facsimile transmissions, as well as file transfers using modems and various embodiments of computer programs enabling data communications between computers.

Hybrid systems are also employed to provide remote access to files stored on network servers. These hybrid systems typically employ specialized communications servers connected on a local area network and interconnected to a counterpart communications server on another local area network through a public network such as the Internet. Alternatively, a remote PC may be permitted to login to a communications server using a dial-up connection through the PSTN. Often referred to as "virtual private networks" or VPNs, these hybrid systems typically employ encrypting techniques to create relatively secure data packets for transmission through client-server connections across public networks. An example of a VPN product is Alta Vista, a software product available from Digital Equipment Corporation.

The approaches, as embodied in the physical and the electronic document delivery systems in use today, exhibit a number of shortcomings. While being relatively secure, slower express mail and delivery services are more costly to the sender than more immediate delivery electronic alternatives. With electronic transfers across networks, a more immediate delivery of documents, data files, images, and drawings can be accomplished. However, these methods generally employ intermediary computers in the form of e-mail servers, FTP servers, or Web servers. These intermediary computers reduce the relative security and timeliness of the transfers effected because neither the sender nor the recipient controls the intermediary server. Moreover, the intermediary servers themselves require significant administration and usually require login procedures and passwords in an attempt to overcome security issues, albeit at the expense of user convenience and system complexity. Further, these intermediary computers represent concentrated points of possible failure, as well as communication "bottlenecks" that set capacity limits for the collective number and size of files transferred.

Examples of an approach employing e-mail servers are cc:Mail available from Lotus Development Company, and Microsoft Mail available from Microsoft Corporation. An example of a system employing 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 of these systems require user login to a server and downloading of files. Thus, direct transfer of a specific file from a sending PC to a specific recipient at a receiving PC is not enabled by these systems, nor is the simultaneous exchange of files between multiple computers.

A variation of the e-mail concept is manifested in a recently introduced file transfer service called "e-Parcel" available over the Internet from Mitsubishi America. "e-Parcel" is a pay subscription service employing client-server connections through the Internet. A similar system called "NetDox" is available from NetDox, Inc. Both of these products employ client software to provide automatic login to a mediating server that forwards a transferred file to a registered recipient when the recipient logs in to the mediating server. E-mail addresses are used to create unique identifiers for each registered user for file routing and billing purposes. However, direct transfer of a file from the sender to the recipient without login to the forwarding server is not possible in server-based mediated systems such as e-Parcel or NetDox. Another drawback of server-based systems is that they are capacity 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 time period. Server capacity must be increased proportionally, at significant cost, as the number of users and system use increases. Another limitation of store and forward (mediated transfer) servers is that concentration of transmitted files represents a system-level point of failure that increases both security and reliability risks.

In any document delivery system, physical or electronic, a manageable method of obtaining payment for the services rendered to the user is a critical element for success. In physical delivery systems for expedited service, payments are often made for charges to a billing account accumulated monthly, with the account numbers being recorded on an "airbill" 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 United States Postal Service (USPS), as well as other national postal systems, have long offered mechanical postage meters for placing "metered stamps" on envelopes to be sent through the mail. These mechanical postage meters must be taken by the user to a "post office" to be reset. This enables a postal service to capture payment for future services to be delivered.

A variation of the traditional postal meter is a newer technology electronic postage meter offered by Pitney Bowes, Inc., called "PERSONAL POST OFFICE".RTM.. The electronic postage meter can be reset over telephone lines with charges made to a Pitney Bowes "POSTAGE BY PHONE".RTM. account. Pitney Bowes also offers a "Post Office for the PC" product that enables "metered" post marks to be printed onto envelopes using a personal computer printer. A peripheral device attached to the personal computer serves as the postage repository, with postage downloaded via modem over telephone lines.

Payment for the service provided by e-Parcel is via a prearranged flat rate monthly charge, with the charge being determined upon registration based upon projected use and transmission file size. An alternative payment plan, pay upon transfer service, has been advertised and charges a fee for each file sent through an e-Parcel server. Payment for the service provided by NetDox, Inc. is via NetDox server software licenses.

United Parcel Service, Inc. (UPS) has announced a mediated electronic document file delivery service based upon the NetDox product, and also based on another store and forward server based product called "Posta", available from Tumbleweed Software, Inc. The UPS system is represented to be 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 across the PSTN, compliant with CCIPP Group 3 facsimile standards, are relatively direct, immediate, and secure from third party interception. However, facsimile transmissions can pose a multitude of transmission management and processing problems for both the sender and recipient. For facsimile transmissions, the "service providers" are the local and long distance telephone companies that charge for the connect time required to send a fax.

Examples of devices using CCITT Group 3 facsimile transmission standards are widely deployed fax machines available from a multitude of manufacturers, such as Hewlett Packard Corporation and Panasonic Corporation. Additional examples of devices employing the Group 3 facsimile standard are the widely deployed PC fax modems available from manufacturers such as US Robotics Corporation. Both fax machines and fax modems communicate over the PSTN. An emerging technology is transmission of fax images over the Internet. While fax devices enable direct transmission of a specific document image from a sender to a specific recipient, the transmissions are not in the original file format of the document transmitted and typically suffer degraded visual quality. PC fax transmissions result in very large file sizes driving requirements for large storage capacity.

Unlike facsimile image transmissions, electronic file transfers across networks or through the PSTN using modems can render document files to the recipient in native format, whether text, graphics, drawings, video, or sound. Such files may contain large format drawings or large page count documents. Unlike e-mail with attachment files, electronic file transfers generally do not suffer problems with unpredictable delivery, third party mail server security, nor attachment file encoding compatibility. However, mediated file transfer using client/server communication across wide area networks typically requires login to a network server, and can pose security risks when access is permitted for remote users or an organizationally unrelated third party.

File transfers through the PSTN using modems and the prior communication architectures with accompanying computer programs usually require user attendance to effect the transfer between PCS. Alternatively, remote control of one PC from another PC with attendant security risks is allowed. Thus, all of the mechanisms in the prior art for effecting electronic file transfer, whether across the Internet, private intranets or extranets, or through the PSTN, require a multitude of process steps and a significant degree of user training.

An example of an approach designed to provide user access to document files across a network is described in U.S. Pat. No. 5,634,057. This patent describes groupware, in which multiple users logged on to a network can interactively collaborate regarding various aspects of documents such as form and content. Typically, groupware suffers from its own complexity of use and does not enable direct transmission of a specific file from one PC to another PC, or a simultaneous exchange with multiple PCS.

Another example of an approach accomplishing file transfers directly from a sending PC to a receiving PC through the PSTN, and in some instances through the Internet, is a class of products described as "remoteware". Within this category, specific products such as "pcAnywhere", available from Symantec Corporation, enable a user to login from one computer to another computer and effectively take control of the operation and stored files of the computer onto which login was accomplished. However, direct transfer of files without the third party security risk of login and control is not provided. Additionally, products such as "DynaComm", available from FutureSoft Engineering, Inc., are designed to provide dial-up terminal access to servers and mainframe computers across the PSTN. Such products are also typically capable of direct PC to PC transfer of files, provided a PC operator is available and ready at both the sending and receiving PC to setup the parameters and conditions under which the transfer will be made.

Another example of an approach that enables transmission of a single file from one PC to another PC interconnected to a Transmission Control Protocol/Internet Protocol (TCP/IP) network is a demonstration computer program called "Wormhole", available over the Internet from Microsoft Corporation. The purpose of this freeware computer program is to demonstrate how a socket data structure functions under the Microsoft Windows operating system. This demonstration program is capable of sending only one file to only one PC at a manually entered IP address. No restrictions can be placed on when or where files can be transmitted, nor from whom they are received. Simultaneous exchange of files with more than one PC is not enabled nor suggested. Furthermore, no PSTN communication and no error checking or verification of the file transfer is provided. Moreover, no indication of where files originate from is provided. In addition, no communication or file controls are enabled. Also, it is not possible to request a file from a PC operating the Wormhole computer program, nor is any form of file transport security provided.

Another example of an approach that enables direct PC to PC communication through the PSTN, developed by the current applicant, is the AEGIS Document Imaging System (ADIS). In ADIS, document management and communication functions are integrated to provide a system for creating a virtual PC network interconnected through the PSTN. In addition to imaging capable PC equipment, ADIS requires specific communication hardware (e.g., SatisFAXtion 400 fax modem developed by Intel Corporation, available from Pure Data, Ltd., Ontario, Canada), and uses a file transfer mechanism built into the SatisFAXtion board controlled by the ADIS computer program. No capability for direct file transfer across the PSTN using widely deployed standard Hayes compatible data modems, or across a TCP/IP network, is included in ADIS. Moreover, file requests can be made from one ADIS station by another ADIS station, but file requests can not be restricted to a specific station.

Another drawback of these conventional systems is that polling of a remote computer, when such capability is present, occurs serially. Thus, a long time is required to receive many files from many different destinations, particularly if one of the destinations is busy, causing the polling computer to repeatedly attempt to contact the destination before ultimately timing out.

Another example of a known file transfer system is DropChute+, available from Hilgraeve, Inc. of Monroe Michigan. Drop Chute+ utilizes a single port, thus limiting communication to one other computer at one time. DropChute+ cannot communicate simultaneously (transfer files in parallel) with one or more other computers. Moreover, with DropChute+ all transfers and commands take place on a single port. If more than one event is to occur, all events are multiplexed through the single port. Furthermore, if a user wants to send a file to a group of destinations, there is simply no way to do it under DropChute+.

Thus, there is a need for a system to provide immediate and secure assured delivery of documents from sender to recipient which retains the positive aspects of the prior art, but does not suffer from its shortcomings.

SUMMARY OF THE INVENTION

In view of the foregoing, the present invention is directed to providing a communication system for effecting peer to peer electronic transfer of computer files between PCS across the Internet, private intranets and extranets, and the PSTN.

File transfers are via the Internet, private intranets or extranets, and the PSTN without login to the remote computer and without intermediate storage of the files on an intervening computer. The present invention enables simultaneous transfers and incorporates functions including certified return receipt for transported files, transport initiation directly from any companion application program, and mechanisms for effecting payment to a service provider for each transported file.

The present invention is further directed to providing a communication system that enables file transfers between PCS in native format without requiring encoding or conversion of the format of the files transmitted.

The present invention is further directed to providing a communication system that enables file transfers between PCS without a requirement for login to an intervening computer other than to establish a communications pathway.

The present invention is further directed to providing a communication system that enables file transfers between PCS without the necessity for an operator to be present at either the sending or receiving PC. Thus, it enables file transfers between PCS at a scheduled time predetermined by the sender.

According to an aspect of the invention, the invention is directed to a file transfer system for transferring files between a local computer and at least one destination computer selected from a list of destination computers. The transfer is across at least one communications pathway, including a computer network and a public switched telephone network. The file transfer system includes a file selector that selects at least one file stored on the local computer for transferring to the at least one destination computer(s); a destination selector that selects, from a list of the at least one remote computer(s), at least one destination computer to which the file will be transferred; a transmitter that transfers the selected file(s) to the destination computer(s) via the communications pathway without storing the selected file(s) on any intermediate computers; and a receiver that receives the transferred file(s).

According to another aspect of the file transfer system of the present invention, the transmitter also includes a compressor that compresses files prior to transmission. The receiver also includes a decompressor that decompresses all compressed files upon receipt. Preferably the compressor compresses every file prior to transmission. Alternatively, the compressor only compresses user selected files.

The transmitter also includes an encryptor that encrypts each file prior to transmission. The receiver also includes a decryptor that decrypts each file upon receipt. In such a file transfer system the encryptor encrypts every file prior to transmission.

In accordance with a preferred embodiment, the file transfer system of the invention also includes a credit sufficiency verifier that 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 established transfer costs. Furthermore, the number of credits in the local machine is modified upon each successful file transfer by a corresponding transfer cost. A number of available credits for each local computer is displayed on the local computer.

The transmitter also includes an encryptor that encrypts selected files prior to transmission. The receiver also includes a decryptor that decrypts each encrypted file upon receipt, wherein dependent upon the policy of a service provider, the number of credits in the local machine may be modified at least one additional credit upon each successful file transfer employing encryption.

Additionally, the file transfer system can also include a credit purchaser that requests additional credits from an outside source in response to a user's request, the outside source validating accounting information of the user and dispensing additional credits if the account information is validated.

According to a preferred embodiment, the file transfer system also includes a transmission error doctor that determines an amount of a file successfully transferred when the file being transferred has been interrupted during transmission. The transmission error doctor transmits the portion of the file not yet transferred when an error-free connection between the local computer and the destination computer is established, thereby resulting in the destination computer receiving the file without errors.

According to a preferred embodiment, the file transfer system also includes a scheduler that schedules a file transfer at a time selected by a local computer user, thereby permitting the file transfer to occur without the presence of the local computer user.

The receiver can also include a recorder that records attributes of all file transfers. In such systems, the recorder can also inform an independent certifying computer of attributes of the file transfer when the file transfer is successful. The recorder can also inform the local computer of attributes of the file transfer when the file transfer is successful. Dependent upon the policy of a service provider, the number of credits in the local machine may be modified at least one additional credit upon each notification of file transfer attributes.

The transmitter can simultaneously transfer files to multiple destination computers through separate and discrete connections to each destination computer. Similarly, the receiver can simultaneously receive file transfers from multiple transmitters. Furthermore, 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 destination computers, such that the local computer can simultaneously exchange (send and receive) any number of files with multiple computers.

The receiver can also include a gate keeper that selectively and automatically accepts file transfers based upon the authenticated identity of a transmitting computer.

In certain preferred embodiments, the file transfer system includes an index generator that defines an index that can be requested by a remote computer via the communications pathway. The index includes at least one file of which the remote computer can request a copy via a file transfer. In such systems, the index can also include an associated remote computer which has exclusive access to the index.

In certain preferred embodiments, the file transfer via the communications pathway occurs without logging onto any intermediate store and forward computers and without logging onto the destination computer.

In preferred embodiments, the file transfer system may effect simultaneous transfer of files contained in specific destination linked directories at multiple remote computers by triggering file transfer initiation at the remote computers with a transfer request.

According to a preferred embodiment, criteria can be invoked in creating an index, including (a) location in file structure, (b) file type, (c) file date & time, (d) embedded serial number, and (e) destination authentication codes.

In a preferred embodiment each device includes at least a display monitor, a processor with memory, a file storage device, a keyboard, a pointing device, a communication interface, and graphically oriented (windows) operating system having drag & drop functionality. Each device operates a computer program for controlling system functions and a computer program for a windows operating environment. Each device is connected to the plurality of communication pathways, and generates a graphical user interface (GUI). Also utilized are a control module for controlling GUI functions and system communications; graphics modules that call or create display windows for indicating candidate files that can be transmitted (transmit windows), candidate personal computer destinations to which files can be transmitted (destination windows), and transmitted files that have been sent or received (event log window); and controls for initializing and invoking system operating criteria via dialog windows.

According to a preferred embodiment, a computer data signal embodied in a propagation medium is provided. The signal enables a variable number of data transfers and includes an initial connection source code segment and a data transfer source code segment. The initial connection source code segment establishes a connection between two devices via predetermined listening ports, with at least one predetermined listening port residing within each device. The initial connection source code segment 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 source code segment is for each of the variable number of data transfer operations. The data transfer source code segment dynamically assigns a second data port within the remaining device. The second data port corresponds to the first data port within the first device. The data transfer source code segment 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 dynamically assigned data ports. Each pair of first and second data ports is established in response to each listening port connection.

The initial connection source code segment may also exchange data transfer characteristics and authenticate the remaining device by verifying identifying information of the remaining device transmitted from the remaining device. Furthermore, the initial connection source code segment may include a selective acceptance source code segment that compares the remaining device's identifying information 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 substantially simultaneously sends and receives data to and from multiple devices.

The signal may also include a return receipt source code segment that generates and sends a return receipt. The return receipt typically includes point of origin, destination, and successful completion 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 signal may also include a certifying source code segment that communicates with an independent certifying processor that verifies return receipts for point of origin, destination, and successful completion information. The independent certifying processor sends verification certification to the device that originated the data transfer upon successful completion of the data transfer. The return receipt source code segment 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 socket data structures are dynamically managed and each data port is represented by a socket data structure. Further, each device may store the socket data structures in a linked list in order to manage the flow of data transfers. The linked list is traversed to enable substantially simultaneous data transfers.

The signal may also include a credit source code segment that maintains and monitors data transfer credits and detects each data transfer in order to deduct credit from a credit account after a successful data transfer. The data transfer is only permitted when the device initiating the transfer has sufficient credits.

According to a preferred embodiment, the data transfer occurs without logging onto any intermediate computers other than those establishing a communications pathway, without logging onto the destination computer, and without intermediate storage of transferred data on an intervening computer.

According to a preferred embodiment, a transmitting device includes an encrypting source code segment that encrypts selected data prior to transmission. Further, a receiving device includes a decrypting source code segment that decrypts each encrypted file upon receipt. Data transfer credits comprise a definite number of credits. The number of credits in the transmitting device is modified at least one additional credit upon each successful data transfer employing encryption.

The signal may also include a credit request source code segment 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 account information of the requesting device and dispenses additional credits if the account information is validated.

The signal may also include an index source code segment that defines an index for request by remote devices via a connection. The index is associated with at least one destination and lists information representative of at least one file that the remote devices can request. Devices corresponding to the associated destination have exclusive access to the index. An index request source code segment may be provided that permits 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 requesting device stores the index in a storage device. An index transfer source code segment may also be provided that, in response to each file listed in the index being selected by the requesting device, permits the requesting device to request a copy of the selected file to be transferred from the remote device. The remote device transfers each file in response to the request.

The initial source code segment may 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 ports from a predetermined range of available ports.

Each device may also include a variable number of destination linked directories that are associated with another device. Each destination linked directory is a file storage area on the device. A destination linked directory management source code segment is then provided that detects storing 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 the detection.

The signal may also include an active connection monitoring source code segment, a validating source code segment, and a monitoring source code segment. The active connection monitoring source code segment periodically determines whether each remote device in a list of at least one remote devices is currently actively connected to a communications pathway accessible to a local device. The validating source code segment validates each remote device in the list of at least one remote devices that is currently actively connected to the communications pathway accessible to the local device. The monitoring source code segment defers a file transfer to a time when the destination device becomes actively connected to the communications pathway accessible to the local device if the selected destination device is not currently actively connected to the communications pathway accessible to the local device.

The signal may also include a parallel polling source code segment that 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 data within the directory to be transferred to the local device. Thus, multiple remote devices are substantially simultaneously polled and the data is transferred substantially simultaneously to the local device from all of the remote devices. Further, the data transfers to the assigned destination.

A file transfer method is provided that enables data transfers between a local device and at least one remote device. The method includes establishing a connection with the at least one remote device via preestablished listening ports that reside within each device. Furthermore, the method includes dynamically assigning a data port within the local device with each data port within each device enabling a data transfer; and transmitting the address of the data port to the remote device via the listening ports. The method enables transferring data between the connected devices via the data ports so that the data is substantially simultaneously transferred between multiple remote devices and the local device via the dynamically assigned data ports.

The method also includes, after establishing the initial connection, receiving data transfer characteristics and authenticating the remote device by verifying identifying information of the remote device. The identifying information is transmitted from the remote device. In addition there is a comparing of the remote device's identifying information with a list of destination identities stored in the local device. Data transfers from devices not within the list of destination identities are prohibited. According to a preferred embodiment, the local device substantially simultaneously sends and receives data.

The method may also include generating and sending a return receipt, including point of origin, destination, and successful completion information, from a device that received a data transfer to a device that transferred data after successful completion of the data transfer. In addition, the method may further include communicating with an independent certifying processor that verifies return receipts for point of origin, destination, and successful completion information. The independent certifying processor sends a verification certification to a device that originated the data transfer upon 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 upon successful completion of the data transfer.

Preferably socket data structures are dynamically managed and each data port is represented by a socket data structure. Further, each device may store the socket data structures in a linked list in order to manage the flow of data transfers. The linked list is traversed to enable substantially simultaneous data transfers.

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 account information of the requesting device and dispenses additional credits if the account information is validated.

The method may also include defining an index that can be requested by remote devices via the initial connection. The index includes at least one file that the remote computer can request a copy of via the data transfer, and an associated destination. The associated destination is a specific destination, and devices corresponding to the specific destination have exclusive access to the index. The associated destination may alternatively be a general destination, such that any remote device has access to the index.

A requesting device may be permitted to select the remote device where a request for an index will be sent. When the request is sent to the selected remote device, the remote device returns the index to the requesting device, and the requesting device stores the index in a storage device. When any file listed in the index is selected by the requesting device, the 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 destination linked 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 storing 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 the 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 communications pathway accessible to a local device; validating each remote device in the list of at least one remote device that is currently actively connected to the communications pathway accessible to the local device. A file transfer is deferred to a time when the destination device becomes actively connected to the communications pathway accessible to the local device if the selected destination device is not currently actively connected to the communications pathway 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, multiple remote devices are substantially simultaneously polled and data is transferred substantially simultaneously to the local device from all of the multiple remote devices. Further, the data transfers to the assigned destination.

The established connection may include 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 ports from a predetermined range of available ports.

Another file transfer method is provided that enables data transfer between a local device and at least one remote device. The method includes establishing a connection with the remote device via preestablished listening ports that reside within each device; receiving an address of a first data port from the remote device via the listening ports; dynamically assigning a corresponding second data port (corresponding to the first data port within the remote device) within the local device, each data port within each device enabling a data transfer; and transferring data between the connected devices via the data ports. Thus, the data is substantially simultaneously transferred to multiple remote devices via the dynamically assigned data ports. After establishing the connection, data transfer characteristics may be transmitted. Further each local device may substantially simultaneously send and receive data to and from multiple devices.

The method may also include generating and sending a return receipt, including point of origin, destination, and successful completion information, from a device that received a data transfer to a device that transferred data upon successful completion of the data transfer. In addition, the method may further include communicating with an independent certifying processor that verifies return receipts for point of origin, destination, and successful completion information. The independent certifying processor sends a verification certification to a device that originated the data transfer upon 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 upon successful completion of the data transfer.

Preferably socket data structures are dynamically managed and each data port is represented by a socket data structure. Further, each device may store the socket data structures in a linked list in order to manage the flow of data transfers. The linked list is traversed to enable substantially simultaneous data transfers.

The method may also include maintaining and monitoring data transfer credits and detecting each data transfer in order to debit a credit account after a successful data transfer. The data transfer is only permitted when the device initiating the transfer has sufficient credits.

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 account information of the requesting device and dispenses additional credits if the account information is validated.

The method may also include defining an index that can be requested by remote devices via the initial connection. The index includes at least one file that the remote computer can request a copy of via the data transfer, and an associated destination. A requesting device may be permitted to select the remote device where a request for an index will be sent. When the request is sent to the selected remote device, the remote device returns the index to the requesting device, and the requesting device stores the index in a storage device. When any file listed in the index is selected by the requesting device, the requesting device requests that a copy of the selected file be transferred from the remote device. The remote device transfers each file in response to the request.

According to a preferred embodiment, each device may include a variable number of destination linked directories, each 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 storing 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 the 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 communications pathway accessible to a local device; and validating each remote device in the list of at least one remote devices that is currently actively connected to the communications pathway accessible to the local device. A file transfer is deferred to a time when the destination device becomes actively connected to the communications pathway accessible to the local device if the selected destination device is not currently actively connected to the communications pathway 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, multiple remote devices are substantially simultaneously polled, and data is transferred substantially simultaneously to the local device from all of the multiple remote devices. Further, the data transfers to the assigned destination.

A file transfer device is provided that transfers data with at least one remote device. The file transfer device includes at least one listening port through which a control connection is established with the remote device. The control connection is utilized to determine a remote data port for transferring data, each data port enabling a data transfer. At least one dynamically assigned data port is for data transfer with the remote data port, the data being substantially simultaneously transferred with multiple remote devices via the dynamically assigned data ports. The control connection may be further utilized to exchange data transfer characteristics. Further, each device may substantially simultaneously send and receive data to and from multiple devices.

The file transfer device may also include a return receipt system that generates and sends a return receipt. The return receipt typically includes point of origin, destination, and successful completion 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 file transfer device may also include a certifying system that communicates with an independent certifying processor that verifies return receipts for point of origin, destination, and successful completion information. The independent certifying processor sends verification certification 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 socket data structures are dynamically managed and each data port is represented by a socket data structure. Further, each device may store the socket data structures in a linked list in order to manage the flow of data transfers. The linked list is traversed to enable substantially simultaneous data transfers.

The file transfer device may also include a credit system that maintains and monitors data transfer credits and detects each data transfer in order to deduct credit from a credit account after a successful data transfer. The data transfer is only permitted when the device initiating the transfer has sufficient credits. The number of available credits for the device may be dynamically displayed on the device.

According to a preferred embodiment, a transmitting device includes an encrypting system that encrypts selected data prior to transmission. Further, a receiving device includes a decrypting system that decrypts each encrypted file upon receipt. Data transfer credits comprise a definite number of credits. The number of credits in the transmitting device is modified at least one additional credit upon each successful data transfer employing encryption.

The file transfer device may also include a credit request 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 account information of the requesting device and dispenses additional credits if the account information is validated.

The file transfer device may also include an index system that defines an index for request by remote devices via the connection. The index is associated with at least one destination and lists information representative of at least one file that the remote devices can request. Devices corresponding to the associated destination have exclusive access to the index. An index request system may be provided that permits 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 requesting device stores the index in a storage device. An index transfer system may also be provided that, in response to each file listed in the index being selected by the requesting device, permits the requesting device to request a copy of the selected file to be transferred from the remote device. The remote device transfers each file in response to the request.

Each device may also include a variable number of destination linked directories that are associated with another device. Each destination linked directory is a file storage area on the device or accessible to the device. A destination linked directory management system is then provided that detects storing 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 the detection.

The file transfer device may also include a parallel polling system that 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 data within the directory to be transferred to the local device. Thus, multiple remote devices are substantially simultaneously polled, and the data is transferred substantially simultaneously to the local device from all of the remote devices. Further, the data transfers to the assigned destination.

Another file transfer device is provided that transfers data with at least one remote device. The file transfer device includes at least one listening port that receives a control connection from the at least one remote device. The device also includes at least one dynamically assigned data port for data transfer with the remote device, each data port enabling a data transfer. The control connection is utilized to transmit the address of the at least one dynamically assigned data port. Thus, data may be substantially simultaneously transferred with multiple remote devices via the dynamically assigned data ports. The control connection may be further utilized to receive data transfer characteristics and authenticate the remote device by verifying the remote device's identifying information. The identifying information is transmitted from the remote device. Each device may substantially simultaneously send and receive data.

The control connection may also include a selective acceptance system that compares the remote device's identifying information with a list of destination identities stored in the first device and prohibits data transfers from devices not within the list of destination identities.

The file transfer device may also include a return receipt system that generates and sends a return receipt. The return receipt typically includes point of origin, destination, and successful completion 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 file transfer device may also include a certifying system that communicates with an independent certifying processor that verifies return receipts for point of origin, destination, and successful completion information. The independent certifying processor sends verification certification 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 socket data structures are dynamically managed and each data port is represented by a socket data structure. Further, each device may store the socket data structures in a linked list in order to manage the flow of data transfers. The linked list is traversed to enable substantially simultaneous data transfers.

The file transfer device may also include a credit request system that maintains and monitors data transfer credits, and detects each data transfer in order to debit a credit account after a successful data transfer. The data transfer is only permitted when the device initiating the transfer has sufficient credits. A number of available credits for the device may be dynamically displayed on the device.

According to a preferred embodiment, a transmitting device includes an encrypting system that encrypts selected data prior to transmission. Further, a receiving device includes a decrypting system that decrypts each encrypted file upon receipt. Data transfer credits comprise a definite number of credits. The number of credits in the transmitting device is modified at least one additional credit upon each successful data transfer employing encryption.

The file transfer device may also include a credit request 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 account information of the requesting device and dispenses additional credits if the account information is validated.

The file transfer device may also include an index system that defines an index for request by remote devices via a connection. The index is associated with at least one destination and lists information representative of at least one file that the remote devices can request. Devices corresponding to the associated destination have exclusive access to the index. An index request system may be provided that permits 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 requesting device stores the index in a storage device. An index transfer system may also be provided that, in response to each file listed in the index being selected by the requesting device, permits the requesting device to request a copy of the selected file to be transferred from the remote device. The remote device transfers each file in response to the request.

Each device may also include a variable number of destination linked directories that are associated with another device. Each destination linked directory is a file storage area on the device or accessible to the device. A destination linked directory management system is then provided that detects storing 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 the detection.

The file transfer device may also include a parallel polling system that 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 data within the directory to be transferred to the local device. Thus, multiple remote devices are substantially simultaneously polled, and the data is transferred substantially simultaneously to the local device from all of the remote devices. Further, the data transfers to the assigned destination.

The file transfer device may also include an active connection monitoring system that periodically determines whether each remote device in a list of at least one remote devices is currently actively connected to a communications pathway accessible to a local device; a validating system that validates each remote device in the list of at least one remote devices that is currently actively connected to the communications pathway accessible to the local device; and a monitoring system that defers a file transfer to a time when the destination device becomes actively connected to the communications pathway accessible to the local device if the selected destination device is not currently actively connected to the communications pathway accessible to the local device.

A data file delivery system is provided for delivering data files between a variable number of devices. The data file delivery system includes a variable number of peer systems. Each peer system has a connection negotiating system for opening at least one listening port for exchanging control data. Each peer also includes a data connection system for opening a variable number of data ports, each associated with a destination, for exchanging data files; a file selection system for selecting a variable number of data files residing on at least one peer system designated as a file source; and a destination selection system for selecting a variable number of destinations for receiving the selected data files. At least the file source has a transmitting system for storageless sending of the selected data files over a variable number of data communications pathways corresponding to the data ports. The destinations each have a receiving system for storageless receiving of the files sent via storageless sending. At least the file source or the destination has an initiating system for initiating operation of the transmitting system, via at least one communications negotiating pathway corresponding to the at least one listening port, from either the file source or the destination. Each file source is also a destination having a receiving system for storageless receiving of files sent via storageless sending by at least one other peer system acting as a subsequent file source at the same time that the transmitting system operates.

Each peer may also include a variable number of destination linked directories, each associated with another device. Each destination linked directory is a file storage area on the device or accessible to the device. Each peer may also include a destination linked directory management system for detecting storing of at least one data file in the corresponding file storage area and for controlling the initiating system to initiate operation of the transceiver system in response to the detection.

Each peer system may also include a return receipt system for generating and sending a return receipt including point of origin, destination, and successful completion information, from each destination peer system receiving the selected files to the file source peer system over the storageless communications pathway corresponding to the data ports upon successful completion of the storageless receiving of the selected files.

The system may also include a third party transaction certificate processor for examining and verifying return receipts for point of origin, destination, and successful completion information. The third party transaction certificate processor is also for sending verification certificate data files over a first additional storageless communications pathway corresponding to a first additional data port to the file source peer system upon successful completion of the storageless receiving of the selected files. The return receipt system generates and sends a return receipt from each destination peer system receiving the selected files to the third party transaction certificate processor over a second storageless communications pathway corresponding to a second additional data port upon successful completion of the storageless receiving of the selected files.

Each peer system may also include a file credit monitoring system for maintaining and monitoring file delivery credits. The file credit monitoring system detects each storageless sending of selected files and debits a credit account variable on an associated peer system in accordance with a function based on the storageless sending. The system may also include a credit processor for receiving credit requests and for incrementing a credit account variable on an associated one of the peer systems upon receipt of a credit request and successful comparison of the credit request against a credit authorization function. The file credit monitoring system generates and sends a credit request from one of the peer systems to the credit processor.

Each peer system may also include an index generating system for generating an index of files on a peer system; an index requesting system for requesting and retrieving an index of files from any one of the variable number of peer systems; a subset selecting system for selecting a subset of a variable number of files from the retrieved index of files from any of the variable number of peer systems; and a file subset requesting system for initiating operation of the transceiver system to transfer the subset from any one of the variable number of peer systems to the peer system.

Each peer system may also include a transceiver management system for managing substantially parallel and simultaneous operation of a variable number of transceiver systems for substantially parallel and simultaneous storageless sending and storageless receiving of the selected files over a plurality of communications pathways corresponding to a plurality of data ports.

The data transfer via the communications pathway occurs without logging onto any intermediate computers other than those needed to establish the communications pathway, without logging onto the destination computer, and without intermediate storage of transmitted files on an intervening computer. The connection with 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 to a predetermined directory associated with a destination, the file is transferred to the destination.

Another file transfer system is provided for transferring files between at least one local computer and at least one remote computer selected from a list of at least one remote computers, across at least one communications pathway. The file transfer system includes a file selector that selects at least one file stored on the local computer for transferring to the at least one remote computer; a destination selector that selects, from the list of at least one remote computers, at least one remote computer designated as a destination computer to which the file will be transferred; a transmitter that transfers the selected file to the destination computer via the communications pathway without storing the selected file on any intermediate computers; and a receiver that receives the transferred file.

The system also includes an initial connection system that establishes a connection between the local computer and the destination computer via predetermined listening ports. At least one predetermined listening port resides within each computer. Data transfer characteristics are exchanged during the initial connection. The identities of the local and destination computer are authenticated by verifying each computer's identifying information.

The system also includes a first allocator that dynamically assigns a first data port represented by a socket data structure within the destination computer; a first transmitter that transmits the address of the first data port to the local computer via the predetermined listening ports; a second allocator that dynamically assigns a second data port represented by a socket data structure within the local computer corresponding to the first data port within the destination computer, each pair of first and second data ports being dynamically assigned in response to each listening port connection; and a second transmitter that transfers data between the connected computers via the data ports. The data is substantially simultaneously transferred between a variable number of computers via the dynamically assigned data ports. Each computer is capable of substantially simultaneously sending and receiving data. Each computer dynamically manages socket data structures to enable substantially simultaneous data transfers.

The system also includes a generator that generates and sends a return receipt, including point of origin, destinations and successful completion information, from the computer that received the file transfer to the computer that transferred the file, and an independent certifying processor upon successful completion of the file transfer.

The system also includes a third transmitter that communicates with the independent certifying processor that verifies return receipts for point of origin, destination, and successful completion information. The independent certifying processor sends verification certification to the computer that originated the file transfer upon successful completion of the file transfer.

The system also includes a credit system that maintains and monitors file transfer credits and detects each file transfer in order to debit a credit account after a successful file transfer. The file transfer is only permitted when the computer initiating the transfer has sufficient credits.

The system also includes a credit request system that requests additional credits from an external credit processor in response to a request from a computer for additional credits. The external credit processor validates account information of the requesting computer and dispenses additional credits if the account information is validated.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is further described in the detailed description which follows, by reference to the noted drawings by way of non-limiting examples of preferred embodiments of the present invention, in which like reference numerals represent similar parts throughout several views of the drawings, and in which:

FIG. 1 is a schematic block diagram illustrating a system architecture with a limited number of personal computers connected to various communication pathways, according to an aspect of the present invention;

FIG. 2 is a flow diagram of exemplary logic of a main control module which controls automated functions and user invoked functions accessed through a graphical user interface, according to an aspect of the present invention;

FIGS. 3A and 3B are flow diagrams of exemplary logic of a send file module which controls the file transmit functions, according to an aspect of the present invention;

FIGS. 4A, 4B and 4C are flow diagrams of exemplary logic of a receive file module which controls the receive file functions, according to an aspect of the present invention;

FIG. 5 is a flow diagram showing exemplary logic for confirmation receipt request processing, according to an aspect of the present invention;

FIG. 6 is a flow diagram of exemplary logic of a create index module which creates an index of files that the user wishes to make available for request from another PC, according to an aspect of the present invention;

FIG. 7 is a flow diagram of exemplary logic of a request file module which creates a request file pending event in the main control module, according to an aspect of the present invention;

FIG. 8 is a flow diagram of exemplary logic of a return requested file module which processes requests for one or more files, or an index, and creates pending events to return the requested files or indexes in the main control module, according to an aspect of the present invention;

FIG. 9 is a flow diagram of exemplary logic of a request credits module which collects accounting information and the number of file transmissions to be authorized, and creates an authorization request pending event in the main control module, according to an aspect of the present invention;

FIG. 10 is a flow diagram of exemplary logic of a credits request processing module which operates on a credit server, according to an aspect of the present invention;

FIG. 11 is a flow diagram of exemplary logic of an add credits module which increments any remaining credits by the amount of the new authorized credits, according to an aspect of the present invention;

FIG. 12 is a flow diagram of exemplary logic of a remove credits module which decreases credits by-the amount of the transfer cost, according to an aspect of the present invention;

FIG. 13 is a flow diagram of exemplary logic for a check for active connections module which periodically checks for active connections for each address listed in the destination window, according to an aspect of the present invention;

FIG. 14 is a flow diagram showing exemplary logic for a third party authenticator's processing of confirmation receipt requests, according to an aspect of the present invention;

FIG. 15 shows an example of an event log window which records file transmission and receipt events, according to an aspect of the present invention;

FIG. 16 illustrates an example of an event properties window that shows the properties and listed files of events listed in the event log file, according to an aspect of the present invention;

FIG. 17 illustrates examples of the transmit window for selecting files to transfer, and the destination window for selecting destinations to transfer the file to, according to an aspect of the present invention;

FIG. 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;

FIG. 19 shows an example of a select destination window for selecting the destination for the file transfer and initiating the file transfer, according to an aspect of the present invention;

FIG. 20 shows alternative examples of a transmit window for selecting files to transfer, and the event properties window that shows the properties and listed files of events listed in the event log file, according to an aspect of the present invention;

FIG. 21 shows alternative examples of a transmit window for selecting files to transfer, and the event properties window that shows the properties and listed files of events listed in the event log file, according to an aspect of the present invention;

FIG. 22 shows an example of a build index window for creating the index of files that can be requested by a destination PC, according to an aspect of the present invention;

FIG. 23 shows an example of a request file window for requesting files from another PC, according to an aspect of the present invention;

FIG. 24 shows alternative examples of a transmit window for selecting files to transfer, and the destination window for selecting destinations to transfer the file to, along with a transport credit bar and credit request button, according to an aspect of the present invention; and

FIG. 25 is a flow diagram of exemplary logic of a send file scheduling module, according to an aspect of the present invention.

BRIEF DESCRIPTION OF APPENDICES

Appendix A is a source code listing of Tool Book script modules that are an exemplary implementation for generating the user interface for the file transfer system of the present invention, the scripts modules being coded in Tool Book (available from Asymetrix Corporation of Bellevue, Wash.);

Appendix B is a C++ source code listing of exemplary dynamic link libraries that implement the destination book features of the file transfer system of the present invention;

Appendix C is a C++ source code listing of exemplary dynamic link libraries that handle the file transferring functions of the file transfer system of the present invention; and

Appendix D is a C++ source code listing of exemplary dynamic link libraries that implement the logging and credit features of the file transfer system of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

Referring now to FIG. 1, there is shown a schematic illustration of one preferred embodiment of the present invention illustrating a system architecture with a limited number of personal computers (PCS) 10 connected to communications pathways, even though any number of PCS 10 may be connected without limitation. FIG. 1 shows that the PCS 10 may be connected to and may use one communications pathway (e.g., the Internet), another communications pathway (e.g., the public switched telephone network PSTN), or more than one communications pathway (e.g., Internet and PSTN) simultaneously. The preferred embodiment of FIG. 1 includes multiple PCS 10, without limitation as to the maximum number of PCS 10. Although each PC 10 is shown to be connected to the Internet, and/or the PSTN, alternative communications pathways may be employed, such as private intranets and extranets.

Each PC 10 is preferably, but is not limited to, an "IBM compatible" x86 or Pentium class machine, connected to a communications pathway. However, other computing devices, such as hand held computers, television set top boxes, mobile telephones, wearable computers, wireless computing devices, or any other device capable of connecting to a network and utilizing an operating system may be utilized. Of course, computers more advanced than Pentium class can be utilized as well. Each PC 10 can include a display monitor, a processor, memory such as ROM and RAM, a file storage device, a keyboard, a pointing device, a communication interface, and a graphic user interface GUI operating system having "drag & drop" functionality. Preferably, the operating system is Microsoft Windows NT, Windows 95, Windows 98, or Windows 3.1x, all available from Microsoft Corp. However, the operating system may be any other graphically oriented operating system such as Mac OS available from Apple Computer, Inc., Solaris, Xwindows, etc.

Each PC 10 runs a computer program incorporating functional modules, such as those illustrated in FIGS. 2-9 and 11-13, and has a GUI consisting of windows, such as those illustrated in FIGS. 15 through 24 described below. The file transfer system shown in FIG. 1, including the PCS 10 running the computer program and graphical user interface, enables direct transfer of electronic files between such interconnected PCS 10 without requiring login to each other PC 10, and without intermediate storage of files on an intervening computer. A credit request processor 16 and independent certification processor 18 may also be provided and are discussed in detail below.

The GUI is generated by a computer program designed for a windowed operating environment such as Microsoft Windows. The GUI consists of modules for controlling system communications and functions accessed from the GUI, and graphics modules that call or create display windows. Exemplary display windows include a transmit window for indicating candidate files that can be transmitted, a destination window displaying candidate PC destinations to which files can be transmitted, and an event log window that displays transmitted files that have been sent or received. Furthermore, the GUI provides user controls for initializing and invoking system operating criteria via dialog windows.

In greater detail, the following describes the operating functions of a preferred embodiment of the computer program and graphical user interface of the present invention from the perspective of both the sending PC and the receiving PC. Although the description is in terms of software, the present invention can also be implemented with firmware, a combination of hardware and software, or with only hardware such as a with a fixed function machine or application specific integrated circuits, etc. In order to effect a file transfer, the computer program of a preferred embodiment of the present invention must be operating 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, intranet or extranet, or a modem connection to the PSTN; "power-on" or standby state at both the sending and the receiving PC; and a windowed operating system such as Microsoft Windows NT, Windows 95 or Windows 3.1 installed and operating on both the sending PC and the receiving PC.

In a preferred embodiment, control modules govern and supervise the transmission and receipt of files across the connected communications pathway. Moreover, a transmit window displays a list of files stored on the file storage device. When files displayed in the transmit window are selected then dragged & dropped on to a graphical object, the drag & drop function of the windowed operating system internally creates a list of files with an associated file structure. The internal list is then linked by the operating system to the destination object represented by the graphical object.

In a preferred embodiment, each candidate PC destination is displayed as a user created "nick name" in a destination window. Still further, each nick name may be a graphical object, invoked by the user, generated by a computer program module and linked to a destination address (either IP address or PSTN number), and a computer program subroutine. When files are dragged and dropped onto the destination object in the destination window, a file list with associated file structure is created by the windowed operating system and a control module displays a dialog box prompting the user for confirmation that the selected files contained in the file list are to be transmitted to the destination selected.

In a preferred embodiment, after the user confirms the files to be transmitted, a compression control module calls a compression subroutine that copies and compresses the files contained in the file list, and stores the compressed file packet on the PC's file storage device. In the context of this specification, a "file packet" is preferably a grouped and compressed assembly of files, rather than a multiplexing or frame-transmission "packet". Then, the control module sends a packet file name and the address linked to the selected destination object to a pending event log file.

Later, at a predetermined time, a control module initiates a connection with the destination PC via an appropriate communications pathway, identifies the sending PC by its name and destination address, then transmits the packet containing the compressed files to the linked destination address across the connected communications pathway. The control module then indicates in an event log window by date, time, and content (which may include file names and associated file structure), when the transmission of the packet is complete.

The predetermined time is selected by the user. Thus, after selecting a file to send, the user may schedule the transfer to occur immediately, or at a later time and/or date. If the file transfer is scheduled for later, the packet file name and destination address remain in a pending event log file until the designated date and time.

In preferred embodiments, a control module responds to inbound file transmissions, captures, decompresses, and writes transmitted files to the computer file storage device using the associated file structure, and creates a received file list that is linked to the stored files and displayed in the event log window showing date, time and content. Still further, the control module initiates a continuous sequence for visibly indicating when a packet has been received by a destination PC. Preferably, user selection of the received file listed in the event log window launches any application that has been associated with the file type received.

System Control: FIG. 2 & FIG. 15

According to a preferred embodiment of the present invention, the computer program and graphical user interface operating on each interconnected PC 10 provides for system control and user interaction. A main control module, illustrated in FIG. 2, is provided for controlling automated system functions as well as functions accessed through the graphical user interface 1. When the user activates the computer program through the graphical user interface 1, the main control module initializes system variables and links DLL files required for system operation at step S2.

A DLL is a dynamic link library and is a standard Microsoft Windows convention for storing functions called by application programs. DLLs can be part of the Windows operating system, application program interfaces (APIs) from software vendors, or functions written for a specific application. Table 1 illustrates exemplary DLLs for the present invention and their purpose.

          TABLE 1
          Type:                  Purpose:
          Windows standard dlls
          user                   GUI interface
          shell                  Drag and drop support
          kernel                 File and memory functions
          Toolbox functions
          tb50dos.dll            File and directory support
          tb50win.dll            High level GUI support
          tb50dlg.dll            Common dialog functions
          Third Party APIs
          saxcom 10.dll          Modem file transfer functions
          compress.dll           Compression functions
          Custom DLLs
          adis.dll               Destination book functions
                                 Indexing functions
          hyper.dll              Log functions
          ftpip.dll              Internet file transfer functions


Saxcom 10.dll is available from Sax Software Corporation of Eugene, Oreg. and implements several file transfer protocols for use with analog telephones, including Zmodem.

Operation of the main control module in each PC 10 is centered on a pending events file. The pending events file contains a list of events initiated by user interactions or communication requests from other interconnected PCS 10. At step S3 the main control module monitors the contents of the pending events file to determine if any pending send events exist. If pending send events are detected, at step S4 the main control module calls a send file module, described below with reference to FIG. 3. After the send file module executes at step S4, or if no pending send events are detected at step S3, the pending event file is again monitored to determine if any pending receive events are present at step S5. If pending receive events are detected at step S5, the main control module calls a receive file module at step S6, described below with reference to FIG. 4. Otherwise, or after the receive file module executes, at step S7 user events are processed.

User events originate in response to user interaction with control windows provided by the graphical user interface 1, and resulting computer program functions initiated by such user interactions. An exemplary user event is scheduling a file transfer of a user selected file. Exemplary events are shown to originate from modules 2-7 shown in FIG. 2. Each module 2-7 is invoked from the graphical user interface 1. Processing the user events involves executing module specific logic and is described below.

At step S9, internet protocol (IP) connections are checked by a function described below with reference to FIG. 17. Subsequently, the logic returns to step S3 and repeats as described above.

Referring to the display screen shown in FIG. 15, both completed and pending events 24 can be viewed in an event log window, such as that shown in FIG. 15. Furthermore, file transfers are logged recording the date, time, and content of the transfer at both the sending and receiving PCS. Clicking on each tab 20 at the top of the event log window displays all events having the selected property indicated on the selected tab (e.g., failed, pending, etc.). The Decrypt button 21 launches a function (described below) which decrypts received files that were encrypted by the sender. Decryption can also be implemented without manual intervention depending on the functionality of encryption/decryption programs integrated into the file transfer system. The Close Log button 22 closes the event log window. Preferably, the contents of the event log window includes for each event: the sender and receiver of the file, the time and date the file transfer occurred, whether the event was a send event or a receive event, and the status of the file transfer. Exemplary file transfer statuses are: completed transfer, pending transfer and failed transfer. An additional symbol e.g., R or U, may be displayed to indicate whether a file has been read. When employing the additional symbols R signifies the file has been read, and U signifies that the file has not been read.

File Transfer System: See FIG. 3 and FIG. 4

A major aspect of the present invention is the file transfer system. There are several parts to such a system. The first is the Windows Sockets system. In the present invention, to send a file from one interconnected PC to another, each PC must be able to detect communication requests for other PCS. A preferred system for detecting communication requests requires each PC to create at least one data structure, called a socket, that listens for communication requests at a specific port on each PC. In a preferred embodiment, one listening port is created at port 789. However, any port or ports can be utilized, as long as all versions of the computer program on each interconnected PC recognize and connect to the ports used to initiate a transfer. As a result of the established socket, each PC listens continuously for a communication request from another PC.

In a preferred embodiment, a PC connection to the Internet or private intranets and extranets using TCP/IP is established by invoking subroutines which create data structures called sockets that enable communication using TCP/IP standards. A listening socket is established that permits the PC to monitor the Internet, intranet or extranet for inbound communication requests initiated by other PCS. When an inbound communication request is detected, a control module in the receiving PC evaluates the request within the context of selective acceptance criteria prior to accepting receipt of the communication request. In other words, the receiving PC automatically decides whether it will accept communication from the sending PC based on criteria such as authenticated identity. The receiving PC terminates transmissions from unauthorized PC destinations.

The selective acceptance criteria is established during system initialization. The receiving PC evaluates whether it will accept a request according to various user defined criteria. For example, the receiving PC may examine the addresses in the destination file and accept communication only from addresses listed in the destination file. Alternatively, the receiving PC may only allow receipt of communications from PCS using software having selected serial numbers. For example, license codes initialized during setup at each system PC can be utilized automatically in conjunction with the destination addresses to further authenticate the source identity for inbound communication requests. Alternatively, encrypted authentication codes initialized during setup at each system PC can be utilized in conjunction with the destination addresses and/or license codes to further authenticate the source identity for inbound communication requests. The user may configure the acceptance criteria at installation and may change the acceptance criteria at any time thereafter.

In preferred embodiments, if a control module at the receiving PC accepts the communication request from a sending PC, a separate socket is established by control modules at both the sending and receiving PCS. The file transfer is via the separate sockets. Meanwhile, the listening sockets at both the sending PC and the receiving PC are maintained. As communication requests from sending PCS are detected and accepted by PCS engaged in sending or receiving one or more concurrent and ongoing transmissions, multiple sockets enabling simultaneous file transfers are created by a control module at each PC receiving such communication requests. In preferred embodiments, a control module in a sending or receiving PC creates and places in a linked list one file transfer socket for each additional, concurrent inbound or outbound communication. This list facilitates managing the flow of file transfers. Thus, multiple discrete connections can be established with multiple remote computers across the various communications pathways to which the local computer is connected.

The process of sending a file is now described with reference to FIG. 3. Initially at step S30, it is determined whether sufficient credits exist for transferring the file. The credit sufficiency analysis is described below. If insufficient credits are found, at step S32 additional credits may be requested as described below. If sufficient credits are found, at step S34 it is determined whether the transfer is intended to be an Internet (or intranet/extranet) transfer.

If the transfer is an Internet transfer, at step S36 another socket is created. In addition, the sending PC connects to the listening socket on the remote PC at port 789. When another transmission is already executing, the newly created socket is added to the linked list of sockets in use. The program traverses the list, giving sockets time to perform 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 factors such as communications speed and processor time and speed.

At step S38 it is determined whether the connection to the remote PC is successful. If the connection has not been established, at step S40 it is determined whether the sending PC previously attempted to connect to the remote PC. If a previous attempt occurred, it is determined whether a maximum number of attempts have occurred; in a preferred embodiment three attempts. Thus, if three unsuccessful attempts occurred (any number can be specified), at step S46 the logic terminates execution and an error is logged indicating that a connection cannot be established with the remote PC. Alternatively, the local computer may be setup to delay the file transfer until the remote destination computer has an active connection to the communications pathway 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 at step S36.

If the connection is successfully established, at 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 is originating. The sending PC then waits for the remote PC to 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 terminates execution and an error is logged indicating that an invalid reply was received.

At step S48 upon receiving a valid data port assignment, a new data socket is created and a connection is established between the new data socket and a data port corresponding to the data port assignment received from the remote PC. In addition, a time-out timer commences and the starting point of the file is determined. When another transmission is already executing, the newly created data socket is added to a linked list of data sockets.

At step S50 data is sent to the remote PC. In a preferred embodiment, the file being transferred is transmitted 2048 bytes at a time. Thus, the first 2048 bytes are transmitted at step S50. Each time data is sent at step S50, the time-out is reset to zero. If the time-out reaches a maximum time, the connection is terminated and the data socket is destroyed.

At step S52 it is preferably determined whether other data sockets exist in the data socket linked list. If other data sockets exist, at step S54 data associated with the next data socket is sent, and the logic repeats from step S52 until no other data sockets are found.

At 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, at step S58 the connection is terminated, the data socket is destroyed, and the remove credits module is called. Finally, at step S60 the event is recorded in the log file.

A preferred embodiment of the present invention utilizes a single designated User Datagram Protocol (UDP) command port to exchange file characteristic information, user authentication information, and to initiate a transfer. Subsequently, a TCP data port is opened to exchange the file content. The UDP command port allows faster connections and quicker data transfer than a TCP port. However, a TCP port is more reliable for data exchange. Consequently, a preferred process for sending a file is as follows:

1) A sender initiates a transfer by sending file characteristic information and sender identification/authentication information to a specified UDP command port on a destination computer at a specific IP address. If the transfer is accepted, a data port is created randomly within a range of possible specified ports and its number is returned on the UDP connection. Otherwise, a notification that the transfer is rejected is sent, and the UDP connection is closed. Finally, the UDP command port waits for new transfers to be initiated.

2) If the transfer is accepted by the recipient, the sender connects to the TCP data port returned by the recipient over the UDP connection and starts sending the file. Both the recipient and sender resume "listening" on the UDP port for transfers initiated by other computers. This is accomplished while the file transfer over the TCP port is in progress. The process is repeated and managed for any number of subsequently initiated file transfers. Thus, multiple, simultaneous file transfers can be accomplished with any number of other computers, with only one instance of the computer program open and running. Advantages of the present invention include a simple user interface and operating approach, great efficiency in system resource utilization, and 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 matches the size of the file received or the sender closes its connection due to an error.

In other preferred embodiments of the invention, more than one UDP command port listens for or initiate file exchanges. To initiate a transfer, a sender PC randomly and automatically selects the UDP port from a set of specified ports. For example, one, two, or more UDP ports at predetermined port numbers could be designated as listening ports. A sender PC initiates a file exchange on a UDP port randomly selected from the set of specific listening ports. The recipient monitors the set of specified ports for initiated file transfers and responds on the UDP port utilized by a prospective sender to acknowledge the connection and return a designated data port. This configuration also lowers the probability 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 did occur, the attempted communication can be automatically retried at a random interval later in time.

If the file transfer is determined to be a PSTN transfer at step S34, at step S62 the sending PC dials the telephone number associated with the remote PC. At step S64 it is determined whether a connection has been successfully established. If no connection was established, the logic proceeds to step S40 where it is determined whether a connection attempt occurred previously. If a previous attempt occurred, it is determined whether a maximum number of attempts have occurred; in a preferred embodiment three attempts. Thus, if three unsuccessful attempts occurred, at step S46 the logic terminates execution and an error is logged indicating that a connection cannot be established with the remote PC. However, 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 at step S62.

After the connection is established handshaking occurs, and at step S66 the sending PC sends an identifier and waits for a response from the remote PC. At step S68 if a response is not received, at step S46 the logic terminates execution and an error is logged. If a response is received, at step S70 the sending PC sends file and station information to the remote machine. Then, the sending PC waits for a reply from the remote PC. If no reply is received, at step S46 the logic terminates execution and an error is logged. Once the reply is received, at step S74 the file is sent to the remote PC utilizing a file transfer protocol. In a preferred embodiment, Zmodem is the file transfer protocol. Upon completing the file transfer, the connection is terminated. Subsequently, the transfer status of the sent file is logged, and the logic proceeds to step S58 to continue as previously described.

The logic which executes at the remote/receiving computer is now described with reference to FIG. 4. Initially at step 400 it is determined whether the transfer will be an Internet (or intranet/extranet) transfer. If the transfer is expected to be an Internet transfer, at step 402 a socket is created on port 789 and the receiving PC waits for a connection. When someone connects, at step 404 all sent data is read. Then, at step 406 the received data (i.e., ID) is compared to IDs within a destination book of IDs from which transfers will be accepted. If the received ID is not found in the destination book, at step 410 an error occurs and the connection is terminated. If the ID is found at step 408, at step 412 it is determined whether the received data is valid. If the data is not valid, at 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 if the received data indicates an index or file request. If the received data indicates an index or file request, at 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 FIG. 11. Otherwise, at step 420 it is determined whether the received data indicates a request for identification. If the received data indicates a request for identification, at step 422 a response is sent to the requesting PC with the ID of the receiving PC. Otherwise it is determined whether the received data is a partial file at step 424.

The partial file determination occurs to decide whether an interrupted transfer is being resumed, or whether a new transfer is beginning. Thus, if the received data is a partial file, at step 426 a starting point is set to the size of the partial file because part of the file must be resent. In other words, the receiving machine informs the sending machine of where to resume the transmission depending on what portion of the file was previously received.. Subsequently, at step 430 a socket is created on a random port, the random port address is sent to the sending PC, and a time-out timer is set. If the received data is not a partial file, i.e., a new transfer is beginning, at 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 data on the port. When data is received, the time-out counter is again reset. Preferably, there is an automatic visible indication of receipt of files at the receiving PC. At step 434 it is determined whether other sockets exist. If other sockets do exist, at step 436 data is received for the next socket. Subsequently, the logic returns to step 434 and repeats until no other sockets are found. Similar to the sending PC, the data sockets may be stored on the receiving PC in a linked list.

At step 438 it is determined whether a file transfer is complete or if data times out. If the data times out, the connection is terminated and the socket is destroyed. Also, if the connection terminated on its own, the socket is destroyed. If no transfer is found to have completed, 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 file size is compared to the size indicated in the file data sent at step S42. If the sizes do not coincide, at step 442 a receive error is logged. Otherwise, if the file sizes are the same, transmission is deemed successful and the logic proceeds to step 444.

At step 444 the event received is logged, the packet is unpacked, and the received files are stored on the receiving PC's storage device. Although in the previous description the sending PC is identified, by name and IP address, to the receiving PC upon initial connection, the identification can come at a later time. However, preferably the sending PC is identified to the receiving PC before the receiving PC opens the received files. Next, at step 446 logic described with reference to FIG. 5 executes to process confirmation receipt requests. Subsequently, the logic proceeds to step 448.

At step 448 it is determined if any other data sockets exist. If additional data sockets are found, the logic returns to step 432 and the processing repeats. If no other data sockets are found, the logic flows to step 450 where an automatic update process executes.

Verifying the data is handled by the TCP/IP protocol that underlies the Windows Socket specification. Because the TCP/IP protocol handles sending and receiving data, file verification is automatic. That is, TCP/IP is an error responsive protocol that checks each TCP packet using cyclic redundancy checking (CRC) and retransmits bad packets. Accordingly, if a file is assembled from successfully received TCP packets, the probability that the received file is error-free is very high. Thus, it is only necessary to verify whether the entire file was received. This is accomplished by verifying that the size of the data transmitted matches the specified size of the file that is received. The file size specification is sent with the file being transmitted and arrives at the receiving PC at the beginning of the transmission.

For modem transfers, the process is different. Thus, if the transfer is determined not to be an internet transfer at step 400, at step 460 the modem is set to auto answer mode, so that it will answer if called. Preferably the modem is set to auto answer mode during initialization at step S2 on each PC.

After the modem is initialized, at step 462 the receiving PC waits for a telephone call. Upon receiving a call, the receiving PC answers and reads a data stream from the modem to determine the sending PC identifier. If no data is received before a time out occurs, the connection is terminated. If data is received, the receiving PC sends a response to the sending PC, which includes an identifier of the receiving PC.

At step 464 file data validity is checked. If the data is invalid, a receive error is logged at step 442. Otherwise if the data is valid, at step 466 the download commences with an agreed upon model protocol, preferably, Zmodem that checks each packet using CRC and retransmits bad packets. Subsequently, the logic proceeds to step 468 to determine whether the received file is the same size as expected, indicating a successful transfer. If the file is not the expected size, at step 442 a receive error is logged. If the received file is the expected size, at step 470 a receive event is logged, and the received packet is unpacked and stored on a storage device. Next, at step 472 logic described with reference to FIG. 5 executes to process confirmation receipt requests. Subsequently, the logic proceeds to step 450 and executes as previously described.

By using the Zmodem protocol, error checking is automatic. However, once again the file size is checked to ensure that the received file is the size it is supposed to be.

Confirmation Receipt Request and Third Party Authentication: See FIG. 5 & FIG. 14

According to another preferred embodiment, the present invention enables a sending PC to request from a recipient PC, confirmation of the attributes of a transferred file packet. The confirmation is a returned file containing a received file list, along with the identity of both recipient and sender, as well as various other attributes. The receipt file is returned from the recipient to the sender directly or through a third party authenticator 18 (FIG. 1) without requiring any action by the recipient computer's user. The sender may designate whether confirmation is by direct return or through a third party authenticator 18 common to all users. The destination address of the third party authenticator 18 is either incorporated into the computer program prior to distribution to users or entered by a user prior to initiating the confirmation requests as part of setup of the computer program on the sending PC.

A control module on the recipient PC, upon receipt of a request for a confirmation of the attributes of a transferred file packet, records the content of the received packet. This may be set up to occur before or after it is decrypted and decompressed. By creating a file list, the content files are written into the file structure of the recipient computer's storage device. Still further, the control module on the recipient PC combines into a confirmation receipt file attributes of the transferred file packet. The attributes may include (1) a file list that delineates the names of files actually found to be present in a received packet, whether containing encrypted or unencrypted files, (2) the size of the files received, (3) the identity of the sending PC (point of origin) as received with the file packet, (4) the identity of the recipient PC, (5) the date of packet receipt, (6) the time of packet receipt, and (7) the electronic fingerprint (hash) of the transmitted files. Alternatively, the confirmation receipt may be setup to provide only verification of a file transfer action accomplished at a specific date, time, and destination.

Still further, if direct return has been requested by the sending PC, the control module on the recipient PC creates a pending event for immediate return of the confirmation receipt file to the sending PC, designating the corresponding destination address. Moreover, if the requested confirmation is designated by the sender to be returned through a third party authenticator, the control module on the recipient PC creates a pending event for return of the confirmation receipt file to the sending PC through the third party authenticator, designating the corresponding destination address. The confirmation receipt file is transferred to the third party authenticator along with the destination address of the sending PC that requested the confirmation. Still further, the third party authenticator, upon receipt of the confirmation receipt file, processes the file stamping a unique digital characterization of the file using commercially available file authentication application programs. The file authentication application programs are designed to create files for which any tampering or modification can be readily detected. Finally, the authenticated confirmation receipt file is transferred, after processing by the third party authenticator, to the destination address of the sending PC that requested confirmation. A copy of the authenticated confirmation receipt may also be sent to the recipient of the associated file transfer.

The logic for processing confirmation receipt requests is now described with reference to FIG. 5. Initially, at step 500 it is determined whether a receipt has been requested. If no receipt has been requested, at step 502 the logic returns to FIG. 4. Otherwise, at step 504 a file list is created. Preferably, the file list includes file attributes of the transferred files such as the files sizes, and the dates and times the file were created. Next, at step 506 a text file is created. The text file preferably includes the sending PC's identification, the receiving PC's identification, and the date and time the file packet was received. Then, at step 508 a confirmation receipt file is created. The confirmation receipt file is a combination of the file list and the text file. Subsequently, at step 510 an immediate send event is created for the confirmation file.

At step 512 it is determined whether direct return has been requested. If direct return has been requested, at step 514 a pending event is created with the PC that requested the direct return as the destination address. If direct return has not been requested, third party authentication has been requested. Thus, at step 516 a pending event is created with an independent authenticator designated as the destination address. After completing either step 514 or step 516, the logic returns to FIG. 4 at step 518.

Exemplary logic which executes at the third party authenticating machine is now described with r