Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
  • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
  • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce

Definitions

• the invention relates generally to a system and method of establishing a network of members, and a system and method of enabling communication between an information provider and at least one intended recipient. More specifically, the invention relates to systems and methods that work in conjunction with a hybrid electronic mail and document delivery system.
• the Intemet is an international collection of interconnected networks currently providing connectivity among millions of computer systems.
• One part of the Intemet is the World Wide Web ("Web"), a graphics and sound-oriented technology used by computer systems to access avast variety of digital information, e.g., files, documents, images, and sounds, stored on other computer systems, called “Web sites” (or “Web servers”).
• Web sites or "Web servers”
• Web sites consists of electronic pages or documents called "Web pages”.
• GUI graphical user interface
• Browsers can view digital information at Web sites through a graphical user interface (GUI) produced by executing client software called a "browser". Examples of commercially available Web browsers include NETSCAPE NAVIGATORTM and MICROSOFT EXPLORERTM . Web browsers use a variety of standardized methods (i.e., protocols) for addressing and communicating with Web servers. A common protocol for publishing and viewing linked text documents is HyperText Transfer Protocol (HTTP).
• HTTP HyperText Transfer Protocol
• a computer system user To access a Web page at a Web server, a computer system user enters the address of the Web page, called a Uniform Resource Locator (URL), in an address box provided by the Web browser.
• the URL can specify the location of a Web server or a file on a Web server.
• An accessed Web page can include any combination of text, graphics, audio, and video information (e.g., images, motion pictures, animation, etc.). Often, the accessed Web page has links, called hyperlinks, to documents at other Web pages on the Web. Also, an accessed Web page can invoke execution of an application program.
• e-mail may not be a practical medium for transmitting formatted documents which frequently are large in size and sometimes exceed size limits of e-mail systems .
• Other protocols such as HTTP and FTP (file-transfer protocol), are able to transfer large files, but interruptions on the network can require repeated transfer attempts to successfully transfer a complete file.
• One known electronic document delivery system includes a server interposed between sending and receiving computers.
• the sending system transmits the document to the server, and the server transmits a notification to the receiving system after receiving the full document.
• This notification includes a direct reference to the document stored on the server.
• the receiving system uses the direct reference to locate and download the document from the server.
• Secure communications may be enabled between sending and receiving users of electronic mail and electronic parcel delivery systems through the exchange of secure information therebetween, such as passwords or security keys and certificates. Such communications may therefore require senders and receivers to exchange and thus divulge secure information, and to maintain secure information related to others. Furthermore, because secure information is generally exchanged between communicating senders and recipients before communications are enabled therebetween, deployment of communications among one or more users is sometimes difficult and time or resource intensive.
• a network of members is established.
• Electronic information including existing electronic mail addresses for more than one prospective network member is acquired from an information provider.
• Secure communications between the information provider and each of the prospective network members is then enabled based on the electronic information received from the information provider.
• Embodiments may include one or more of the following features.
• the acquiring of electronic information may include acquiring electronic information regarding at least one of a prospective network member's name, address and telephone number, acquiring security information from the first entity to limit access by a prospective network member to information available on the network, and/or acquiring information regarding the identity of the prospective network members.
• the enabling of secure communications may be performed automatically without requiring additional input from the information provider.
• the enabling of secure communications may include requesting authorization from the prospective network members to enable secure communications, receiving authorization from at least one of the prospective network members, and configuring the computer used by each authorizing prospective network member to enable communications between the information provider and the authorizing prospective network member based on the electronic information acquired from the information provider when authorization is received from the prospective network members.
• the requesting of authorization may include automatically sending an electronic mail message to the electronic mail addresses acquired to request authorization from the prospective network members, and the configuring may include automatically configuring the computer used by the authorizing prospective network member without requiring additional input from the authorizing prospective network member.
• the configuring may also include automatically configuring the computer used by the authorizing prospective network member without requiring additional input from the information provider, and/or automatically downloading and installing software to enable the computer of the prospective electronic parcel communicator to communicate with the information provider.
• the enabling may comprise enabling secure communications of electronic parcels between the information provider and each of the prospective network members based on the electronic information received from the information provider, the electronic parcels differing in protocol from electronic mail messages for which communications are also enabled on the network.
• the enabling may also comprise establishing security information for the at least one prospective network member including a cryptographic key enabling access to general information related to a group of related network members.
• Information may be acquired by an acquiring entity that is distinguished from the information provider and the prospective network members.
• the information provider, the acquiring party and the prospective network members may each comprise a computer.
• the acquiring may include acquiring information from more than one information provider specifying prospective network members for a secure network therefor, and the enabling may include enabling secure communications between each information provider and corresponding prospective network members specified by that information provider.
• a system for establishing a network of members includes an electronic interface that acquires. electronic information including existing electronic mail addresses regarding more than one prospective network member from a information provider, and a computer driven module enabling secure communications between the information provider and each of the prospective network members based on the electronic information received from the information provider.
• Embodiments may include one or more of the following features.
• the electronic interface may include at least one of a graphical user interface and a data port capable of receiving propagated signals carrying the electronic information.
• the electronic interface may acquire electronic information regarding at least one of a prospective network member's name, address and telephone number, security information from the information provider to limit access by a prospective network member to information available on the network, and/or information regarding the identity of the prospective network members.
• the computer driven module may enable secure communications automatically without requiring additional input from the information provider.
• the computer driven module may include a first module requesting authorization to enable secure communications from the prospective network members, a second module receiving authorization from at least one of the prospective network members, and a third module configuring the computer used by each authorizing prospective network member to enable communications between the information provider and the authorizing prospective network member based on the electronic information acquired from the information provider when authorization is received from the prospective network members.
• the first module automatically sends an electronic mail message to the electronic mail addresses acquired to request authorization from the prospective network members.
• the third module automatically configures the computer used by the authorizing prospective network member without requiring additional input from the authorizing prospective network member, generally without requiring additional input from the information provider.
• the third module automatically downloads and installs software to enable the computer of the prospective electronic parcel communicator to communicate with the information provider.
• the computer driven module may include a module that enables secure communications of electronic parcels between the information provider and each of the prospective network members based on the electronic information received from the information provider, the electronic parcels differing in protocol from electronic mail messages for which communications are also enabled on the network.
• the computer driven module may also comprise a module that establishes security information for the at least one prospective network member including a cryptographic key enabling access to general information related to a group of related network members.
• the information provider and the prospective network members each generally comprise a computer.
• the electronic interface generally acquires information from more than one information provider specifying prospective network members for a secure network therefor, and the computer driven module generally enables secure communications between each information provider and corresponding prospective network members specified by that information provider.
• electronic communication are enabled between a information provider and at least one second entity.
• Contact information for each of several second entities is acquired by electronically interfacing with an existing compilation of electronic contact information, and communication of electronic parcels with the second entities is enabled based on the contract information electronically obtained.
• Embodiments may include one or more of the following features.
• the contact information may include an existing electronic mail address
• the information provider may be an existing account holder
• the second entity may include a prospective account holder.
• communications are enabled between an information provider and at least one second entity.
• Electronic contact information is acquired for each of several second entities from the information provider, and communications are enabled between the information provider and at least one of the second entities by using the electronic contact information to contact and download communications software to the second entities and by establishing an electronic network of entities including the first and second entities based on the contact information electronically acquired.
• a system for enabling communications among clients of a network includes a sender that generates a first communication for an intended recipient that is encrypted using a public key associated with the sender, and a host that receives the first communication, deciphers the first communication using the public key for the sender, and uses the first communication to generate a second communication that is encrypted based on a public key associated with the intended recipient, and sends the second communication to the intended recipient.
• the public keys for the sender and intended recipient are both centrally stored at the host to enable communications between the host and each of the sender and the intended recipient without an exchange of public keys.
• communications among clients of a network are enabled.
• a first communication that is directed to an intended recipient and that is encrypted using a public key associated with the sender is received, the first communication is deciphered using the public key for the sender, a second communication is generated that is based on the first communication and that is encrypted based on a public key associated with the intended recipient, and the second communication is sent to the intended recipient.
• Embodiments include retrieving the public key for the sender from a centralized storage medium rather than from the sender incident to the communication, and/or retrieving
• FIG. 1 is a diagram of an electronic parcel delivery system including a sending system in communication with a receiving system through a server system.
• Fig. 2 is a diagram of a delivery system in which the sending system transmits a parcel to the server system and a notification to the receiving system.
• Fig. 3. is a diagram of graphical windows presented to the receiving system when accessing the parcel stored on the server system.
• Fig. 4 is a diagram of a delivery system in which the sending system communicates with a Web server, using a Web browser, to send the notification to the receiving system.
• Fig. 5 is a diagram of a delivery system in which the sending system communicates with a Web server, using a Web browser, to send the notification to the receiving system and the parcel to the server system.
• Fig. 6 is a diagram of a delivery system in which the sending system communicates with a Web server using client software to send the notification to the receiving system, and the receiving system communicates with the server system using client software to obtain the parcel.
• Fig. 7 is a diagram of a delivery system in which the sending system delivers the parcel to the receiving system without notifying the receiving system that a parcel has been transmitted.
• Fig. 8 is a diagram of a group of servers acting logically as the server system of the delivery system of Fig. 1.
• Fig. 9 is a diagram of the electronic parcel delivery system in which proxy servers separate the sending and receiving systems from the network.
• Fig. 10 illustrates a format and content of an HTTP transaction used to transmit a parcel through an HTTP proxy server.
• Fig. 11 A is a flow chart of a procedure by which the sending system transmits a parcel to the server system.
• Fig. 1 IB is a flow chart of a procedure by which the sending system or receiving system obtains approval from the server system to upload or download a parcel.
• Fig. 11C is a flow chart of a procedure by which the sending system prepares and transmits a parcel portion to the server system, and the server system prepares and transmits the parcel portion to the receiving system.
• Fig. 12 is a flow chart of a procedure that dynamically determines the byte size of a transaction for transmitting a parcel portion.
• Fig. 13 is a flow chart of a procedure by which a system transmitting the parcel dynamically determines the format of information encapsulated within a meta-protocol transaction.
• Fig. 14 is a diagram of an electronic parcel delivery system used to conduct electronic commerce.
• Fig. 15 A is a diagram of an electronic parcel delivery system used for coordinating order and receipt of goods among various entities.
• Fig. 15B is a flow chart of a procedure performed by the electronic parcel delivery system of Fig. 15 A.
• Fig. 16A is a diagram illustrating communications between different system entities.
• Fig. 16B is a flow chart illustrating a procedure by which the system of Fig. 16A coordinates work flow activities among the different system entities.
• Fig. 17 is a block diagram of a hybrid system that integrates an electronic mail system with an electronic parcel delivery system.
• Fig. 18 A is a flow chart of a procedure implemented by the system of Fig. 17.
• Figs. 18B-18C illustrate processes used to send and receive electronic mail messages and parcels in accordance with one embodiment of the present invention, respectively.
• Fig. 19 is a block diagram of another hybrid system that integrates an electronic mail system with an electronic parcel delivery system.
• Figs. 20A and 20B are a block diagram of an exemplary virtual private network and a flowchart describing its operation, respectively.
• Fig. 21 is a block diagram of another exemplary virtual private network.
• Figs. 22A-22D illustrate exemplary graphical user interfaces useful in enabling a receiving and sending automation module.
• Fig. 23 illustrates a process for converting a standard e-mail system to a hybrid system in accordance with one embodiment of the present invention.
• a hybrid electronic mail and electronic parcel delivery system combines features of an electronic mail (e-mail) system with those of an electronic parcel delivery system.
• an electronic parcel delivery system is discussed with reference to Figs. 1-16B prior to the discussion of the hybrid system.
• an electronic parcel delivery system 100 may be used to deliver files electronically over a network 105.
• the system may deliver files of any size or type, such as, for example, binary digital information, text, documents, parcels, multimedia content, video, audio, digital images, software, source code and folders.
• the parcel delivery system 100 includes a sending computer system 110, a receiving computer system 115, and server systems 120 and 125 connected to the network 105. It is to be understood that more than one sending system and more than one receiving system may be connected to the network 105.
• the network 105 can be, for example, a local-area network (LAN), a wide area network (WAN), such as the Intemet or the World Wide Web, or any other suitable network configuration.
• LAN local-area network
• WAN wide area network
• Each of the sending, receiving, and server systems can be connected to the network
• connections including, for example, standard telephone lines, LAN or WAN links (e.g., Tl, T3, 56kb, X.25), broadband connections (ISDN, Frame Relay, ATM), and wireless connections.
• the connections can be established using a variety of communication protocols (e.g., HTTP, TCP IP, IPX, SPX, NetBIOS, Ethernet, RS232, and direct asynchronous connections).
• Each of the sending and receiving systems 110, 115 can be any personal computer (e.g., 486, Pentium, Pentium ⁇ , Pentium m, Macintosh, RISC Power PC), thin-client device, Windows-based terminal, Network Computer, wireless device, information appliance, X- device, workstation, mini computer, main frame computer, or other computing device having a graphical user interface.
• Windows-oriented platforms supported by the sending and receiving systems 110, 115 can include Windows 3.x, Windows 95, Windows 98, Windows NT 3.51, Windows NT 4.0, Windows CE, Windows CE for Windows Based Terminals, Macintosh, Java, and Unix.
• the sending and receiving systems 110, 115 can include a display screen 130, 130', a keyboard 135, 135', memory 140, 140', a processor 145, 145', and a mouse 150, 150', respectively.
• Each server system 120, 125 can be any computing system able to operate as a Web server, to communicate according to the HTTP protocol, to maintain Web pages, to process URLs, and to control access to other portions of the network 105 (e.g., workstations, storage systems, printers) or to other networks.
• the server system 120 can also operate as an e-mail server for exchanging e-mail messages between the sending and receiving systems 110, 115.
• the server system 125 includes a storage device 155 for storing digital information received from sending systems and destined for subsequent transmission to receiving systems.
• the storage device 155 can be persistent storage, such as a hard-drive device, or volatile storage, such as dynamic RAM.
• the server system 125 can include a group of server computer systems logically acting as a single server system and organized in a scalable architecture (see Fig. 8).
• the server systems 120, 125 provide electronic parcel delivery service between the sending and receiving systems.
• Application software installed on the sending system 110 (referred to as client parcel software) and on the server system 125 (referred to as parcel server software) performs the parcel delivery service functions.
• the client parcel software can be installed on receiving system 115, although this is not necessary for the receiving system to receive parcels.
• the client parcel software collects proxy and protocol information from the configurations of Web browsers installed on the sending system 110 or receiving system 115. This information indicates whether a proxy is necessary to transmit parcels onto the network 105 and the necessary protocol (e.g., HTTP) to use.
• HTTP HyperText Transfer Protocol
• the client parcel software automatically configures the proxy and sets the protocol in the configuration files on the sending system 110 or the receiving system 115. If the client parcel software determines that the sending system 110 does not have any installed Web browsers, then the proxy and protocol remain set at default values, namely "no proxy" and "TCP/IP,” respectively.
• the client parcel software communicates with the server parcel software.
• the client parcel software provides the functionality for sending and receiving parcels. Consequently, the roles of the sending and receiving systems 110, 115 can reverse; senders may become receivers and receivers, senders.
• the server system 125 operates as a warehouse for received, but undelivered parcels.
• the parcel delivery service provides senders and receivers a variety of services. These services are described below and include data streaming, transmission interruptibility, data encryption and compression, parcel tracking, and parcel canceling.
• the sending and receiving systems 110, 115 can employ at least two techniques for accessing the parcel delivery service: (1) by executing the client parcel software; and (2) by executing a Web browser, e.g., NETSCAPE NAVIGATORTM or MICROSOFT INTERNET EXPLORERTM.
• Executing the client parcel software brings the senders and receivers into communication with the server parcel software executing on the server system 125; executing the browser brings the senders and receivers to a common-entry Web page (e.g., a home page) on the server system 125.
• a common-entry Web page e.g., a home page
• senders and the receivers Upon accessing the server system 125, the senders and the receivers are presented with a variety of graphical windows through which they can perform the desired parcel sending and receiving operations. These windows are described below in connection with Fig. 3. Although described with respect to Web pages and graphical windows, the system is not limited to the context of the World Wide Web, Web pages, and graphical windows. For example, senders and receivers can operate in a non-graphical environment, entering command line operations according to protocols, such as the file transfer protocol, to send parcels to and obtain file directories from the server system 125.
• protocols such as the file transfer protocol
• the senders and receivers can double-click with a mouse on a graphical, desktop icon representing the client parcel software.
• An alternative method for sending a parcel is to drag-and-drop a graphical representation of that parcel onto the icon.
• users of the sending and receiving systems 110, 115 can double-click on a graphical, desktop icon representing the browser and navigate to the URL associated with the common- entry Web page.
• the receiver of a parcel notification can click on a hyperlink
• This hyperlink causes the browser to launch and navigate to the common-entry Web page.
• Fig. 2 shows general operation of the parcel delivery system 100.
• the sending system 110 transmits digital information 200, here referred to as a parcel, to the server system 125.
• the sending system 110 also transmits a notification 205 to the receiving system 115.
• the transmission of the parcel 200 and the notification 205 can occur concurrently.
• the sending system 110 can issue the notification 205 before transmitting the parcel 200 or after successfully transmitting the complete parcel 200 to the server system 125.
• the notification 205 can be automatically or manually generated, whether before, after, or concurrently with transmission of the parcel 200.
• Both the sending system 110 and the receiving systemll5 run the client parcel software 208.
• the notification 205 signifies to the receiving system 115 that the sending system 110 has transmitted a parcel intended for the receiving system 115 to the server system 125.
• An e-mail message for example, can serve as the notification 205.
• An advantage to using e-mail for notifications is that the sending system 110 can be assured of the on-line availability of the receiving system 115.
• Typical e-mail services can report to senders that particular receivers have received the e-mail message. Some e-mail services also can inform senders that the particular receiver has read that e-mail message.
• the notification 205 can be a brief message, such as "You have a parcel.” If the user is familiar with the parcel delivery system 100 and knows the location of the common-entry page 210 (or, for example, has recorded the location as a bookmark in the Web browser), this notification indicating that the sending system 110 has sent the parcel, without more, may be sufficient to permit the user to access the parcel.
• the notification 205 can also include a resource locator (e.g., a URL) addressing the common-entry page 210 on the server system 125.
• This resource locator can operate as a hyperlink that launches the Web browser and navigates to the common-entry page 210 with a click of the mouse.
• the receiving system 115 can manually launch the browser and enter the URL corresponding to the common entry page 210.
• the sending system 110 notify the receiving system 115, rather than the server system 125
• the receiving system 115 acquires an earlier notification of the imminent delivery of a parcel. Consequently, the receiving system 115 can take advantage of data streaming capabilities of the parcel delivery service provided by the server system 125, described below, by requesting the parcel 200 while the parcel 200 is not yet completely transmitted from the sending system 110 to the server system 125.
• the server system 125 can store the parcel 200 in the storage system 155.
• the receiving system 115 can access the server system 125 (e.g., at the common-entry page 210) and send a request 215 for the parcel 200.
• This request 215 can be automatically generated by software installed on the receiving system 115 or deliberately initiated as described above.
• the server system 125 can then download the parcel 200 to the receiving system 115.
• the receiving system 115 can access the server system 125 (e.g., via the common-entry page 210) and then traverse a sequence of graphical windows as shown in Fig. 3.
• the windows produce a graphical user interface that can lead the receiver to access the parcel 200.
• the page 210 can be manually or automatically visited. Downloading the page 210 to the receiving system 115 can cause execution of a Common Gateway Interface (CGI) script.
• CGI Common Gateway Interface
• the script can require log-on authentication of the receiving system user and can prompt the user for log-on information 300, such as a user- name and a password.
• a second window 305 presents the user with a status of parcels received (“inbox") and sent ("outbox") by that user.
• inbox a status of parcels received
• outbox a status of parcels received
• the user can obtain a list of parcels previously and presently received, and information about those parcels.
• the information can include the size of each parcel and an indication as to whether the user has opened that parcel.
• the user can select one of the listed parcels by double clicking on the desired parcel identifier.
• the window 305 indicates that the user has three parcels.
• the next displayed window is a cover sheet 310 that provides information about attributes of the selected parcel, such as the identity of the sending system, the name of the parcel, the time sent, and the parcel size.
• the cover sheet 310 gives the receiving system user an opportunity to accept or reject delivery of the parcel.
• the receiving system user can view the attribute information, decide to refuse delivery, and consequently reject the parcel. This feature enables the user to avoid downloading oversized files, unwanted information, suspicious files, or transmissions from unknown or unwanted senders.
• the cover sheet 310 can also include a resource locator, here "file,” for obtaining the selected parcel.
• the resource locator can include parameters that indirectly reference the storage location of the digital information representing the selected parcel.
• One such parameter is a unique identifier associated with the selected parcel.
• Other parameters can include session information, such as the identification of the user and a session key.
• the server system 125 maintains a data structure (e.g., a database or a table) that maps parcel identifiers to the storage locations.
• a CGI script processes the parameters and accesses the data structure to identify the storage location of the selected parcel, obtain the stored parcel, and start streaming the digital information to the receiving system 115.
• Data streaming involves uploading the parcel 200 to the server system 125 while the server system 125 is downloading the parcel 200 to the receiving system 115. This process can reduce by almost half the amount of time for full delivery of the parcel 200. The time reduction occurs because the process of downloading the parcel to the receiving system 115 does not wait until the entire parcel is uploaded from the sending system 115 to the server system 125. Rather, the server system 125 can start transmitting upon receiving a first portion of the parcel 200. Data streaming can occur automatically, provided that the receiving system 115 is on-line. For implementations in which the receiving system user can reject the parcel, the receiving system 115 can request the parcel 200 from the server system 125 before the server system 125 completely receives the parcel 200 to talce advantage of data streaming.
• the transmission can continue until the entire parcel 200 is uploaded to the server system 125.
• the server system 125 then waits until the receiving system 115 comes on-line and requests the parcel 200 at which point the server system 125 downloads the parcel 200 to the receiving system 115.
• the server system 125 deletes the parcel 200 from the storage system 155 after successfully transmitting the parcel to the receiving system 115.
• the server system 125 also may delete portions of a parcel once those portions are delivered successfully.
• the receiving system 115 informs the server system 125 that a parcel or portions of the parcel have been successfully fransmitted by retirrriing acknowledgments to the server system 125 upon receiving the parcel or its portions.
• the server system 125 can make efficient use of available storage and reduce the amount of storage needed for parcels awaiting delivery to receiving systems.
• the server system 125 can reestablish the connection and then resume transmission of the parcel 200 from the point of interruption.
• the receiving system 115 determines the point of interruption from the size of the parcel and the time of interruption.
• the server system 125 initially sends the parcel 200 to the receiving system 115, the parcel includes a unique identifier that indicates the size of the parcel 200 to the receiving system 115.
• the receiving system 115 uses the parcel size and the time of interruption to request from the server system 125 only those portions of the parcel 200 not previously transmitted.
• the server system 125 automatically resends all portions of a parcel for which the receiving system 115 has not acknowledged receipt.
• the delivery system 100 provides security at various levels.
• the server system 125 can authenticate the user identities of the sending and receiving systems 110, 115. This authentication can include uniquely identifying the installations of the client software on the sending and receiving systems 110, 115.
• the delivery system 100 authenticates each delivery transaction.
• the client parcel software compresses and encrypts the parcel in real time.
• the server system 125 may compress and encrypt the parcel in real-time while transmitting the parcel to the receiving system.
• the receiving system user can reject parcel deliveries rather than download them from the server system 125.
• the server system 125 can also operate as a certificate authority so that each sending and receiving system can be assured of the identity of the originator and recipient of the parcel.
• the server system 125 manages the encryption keys of users of sending and receiving systems.
• Tracking information can include information concerning when the sending system 14 started transmitting the parcel 58 to the server system 26, the progress of uploading the parcel 58 to the server system 26 (or intermediate Web server as described below), the status of the receiving system 18 (e.g., unregistered, off-line, or on-line), the progress of downloading the parcel 58 to the receiving system, and the status of the received parcel (e.g., parcel being received, parcel moved to another location in memory, parcel delivered, parcel opened, or time of opening).
• Tracking information can include information concerning when the sending system 14 started transmitting the parcel 58 to the server system 26, the progress of uploading the parcel 58 to the server system 26 (or intermediate Web server as described below), the status of the receiving system 18 (e.g., unregistered, off-line, or on-line), the progress of downloading the parcel 58 to the receiving system, and the status of the received parcel (e.g., parcel being received, parcel moved to another location in memory, parcel delivered, parcel opened, or time of opening).
• the server system 26 can verify that the receiving system 18 has received the parcel 58 using a signature uniquely identifying the receiving system 18 user and, when the receiving system 18 executes client software to access the server system 26, a unique identifier associated with that client software.
• the signature and unique identifier can accompany a returned acknowledgment from the receiving system 18 to securely signify that the receiving system 18 has received from the server system 26 the last bit of digital information pertaining to the parcel 58.
• the server system 26 can record the progression of the transmission for the parcel 58 in a database, along with the signature and client software identification.
• the database can provide an audit trail for the sending and receiving systems 14, 18 to view. Accordingly, tracking provides the sending system 14 with a mechanism for confirming receipt and subsequent use of a parcel 58, a capability generally lacking in trans-Intemet communications. Delivery Cancellation
• the sending system 110 can cancel delivery of the parcel 200 at any time during the transmission of the parcel to the receiving system 115.
• the sending system 110 does so by signaling the server system 125 to stop the delivery. If the server system 125 has not started transmitting the parcel to the receiving system 115, then the server system 125 can forego forwarding the parcel and can delete the parcel from the storage system 155. If the server system 125 has transmitted the parcel to the receiving system 115, then the server system 125 can forward the cancel signal to the receiving system 115.
• the client software on the receiving system 115 deletes the parcel upon receiving the cancel signal from the server system 125, provided that the parcel has not completely received and opened.
• a completely delivered and opened parcel may be canceled, although permission by the user of the receiving system may be necessary to do so.
• the server system 125 can recover any canceled deliveries, provided that the parcel is still available (e.g., it has not been overwritten).
• another implementation of the electronic parcel delivery system 100 includes the sending system 110, the receiving system 115, the server system 125, and a Web server 400.
• the sending and receiving systems 100, 115 are in communication with the Web server 400 and the server system 125, and the Web server 400 is in communication with the server system 125.
• a parcel 405 passes directly from the sending system 110 to the server system 125, and the server system 125 stores the parcel 405 in the storage system 155.
• the sending system 110 sends a notification 410 to the Web server 400, and the Web server 400 provides the notification 410 to the receiving system 115.
• the notification 410 operates similarly to the notification 205 described with referenced to Fig. 2, and may be in the form of an e-mail message.
• the sending and receiving systems 110, 115 run Web browsers 415, 420 to access the coinmon-entry page 210 on the server system 125.
• the Web server 400 transmits graphical user interfaces 425 between the sending and receiving systems 110, 115 and the server system 125. The graphical user interfaces are displayed by the browsers 415, 420.
• the receiving system 115 uses browser 420 to request access to the Web page 210, and does so by sending a request 430 to the Web server 400.
• the Web server 400 responds by presenting the user interface 425, which permits the receiving system 115 to obtain a uniform resource locator ("URL") for use in accessing the parcel 405.
• the receiving system 115 then sends a request 435 containing the URL to the server system 125, which responds by sending the parcel 405.
• URL uniform resource locator
• the sending system 110 can track the status of a parcel by sending a tracking request 440 to the Web server 400.
• the Web server 400 forwards the tracking request 440 to the server 125, which responds with a tracking report 445.
• the tracking report 445 details the delivery status of parcel 405.
• the Web server 400 forwards the tracking report to the sending system 110.
• the sending system 110 transmits a parcel 500 to the Web server 400 instead of directly to the server system 125.
• the Web server 400 then forwards the parcel 500 to the server system 125.
• the system otherwise operates in the same way as the system of Fig. 4.
• the sending and receiving systems 110, 115 each execute the client parcel software 208 to access server parcel software 600 executing on the server system 125.
• the sending system 110 transmits a parcel 605 directly to the server system 125 and transmits a notification 610 to the Web server 400, preferably via an e-mail message or the like.
• the Web server 400 forwards the notification 610 to the receiving system 115.
• the receiving system 115 responds to the notification 610 by sending a request 615 to access the Web page 210 of the server system 125 and by sending a parcel request 620 to the server system 125.
• the server system 125 responds by forwarding the parcel 605 to the receivmg system 115.
• the user interfaces, tracking requests, and tracking reports pass directly between the sending system 110 (or the receiving system 115) and the server system 125, rather than through the Web server 400.
• the sending system 110 can execute a Web browser, as described, e.g., in Fig. 5, while the receiving system 115 executes the client parcel software.
• the sending system 110 can execute the client parcel software while the receiving system executes a Web browser as described, e.g., in Fig. 5.
• the client parcel software communicates directly with the server system 125 to exchange information, such as the user interface and the tracking information
• the Web browser communicates indirectly with the server system 125 through the Web server 400.
• the sending system 110 delivers a parcel 700 to the server system 120 without any notification mechanism to alert the receiving system 115 that the sending system 110 has sent the parcel 700.
• the sending system 110 can transmit the parcel 700 directly to the server system 115 or through the Web server 400.
• the sending system 110 executes the client parcel software
• the user interface 425 and the parcel 700 are communicated directly to the server system 125.
• the sending system 110 executes the Web browser 415
• the parcel and the user interface are communicated through the Web server 400.
• the receiving system 115 When the receiving system 115 goes online, a URL is presented to the user in a graphical user interface enabling the receiving system user to obtain the parcel. Alternatively, the receiving system 115 can periodically poll 705 the server system 125 to determine if any new parcel deliveries have occurred. When there is a parcel to be delivered, the receiving system 115 accesses 710 the Web page 210 and requests 715 the parcel. The server system 125 responds by sending the parcel.
• a group of servers may act logically as the server system 125.
• the group of servers includes a root server 800, one or more user servers 805, 810, and one or more data servers 815.
• the root server 800 tracks each user server 805, 810 and each data server 815 in the group.
• the root server 800 also can maintain information about other remote server systems or groups of server systems that can provide the electronic parcel delivery service in conjunction with the server system 125.
• the user of the sending system 110 and the user of the receiving system 115 are each assigned to a user server when the users first register with the server system 125.
• the root server 800 selects the user server to which each user is assigned. For example, the root server 800 can assign the sending system user to user server 805 and the receiving system user to user system 810, as shown, or may assign the sending and receiving system users commonly to a single user server, e.g., user server 805.
• the sending system 110 subsequently contacts the server system 125 to initiate delivery of a parcel
• the sending system 110 obtains the identity of the assigned user server 805 from the root server 800 (arrow 820).
• the sending system 110 then sends parcel information, including the name of the intended receiver, to the user server 805 (arrow 825).
• the user server 805 allocates one of the data servers 815 to store that parcel (arrow 855) and notifies the sending system 110 of the allocation (arrow 825).
• the sending system 110 can then transmit the parcel directly to the allocated data server 815 through link 830.
• the assigned user server 805 provides, each other user server 810 in the group (and remote user servers) with the identity of the intended receiver of the parcel through link 835.
• the receiving system 115 Upon logging on to the server system 125, the receiving system 115 obtains from the root server 800 the identity of the user server 810 assigned to the receiving system 115 (arrow 840). The receiving system 115 subsequently communicates with the user system 810 to determine that the new parcel is available on the data server 815 (arrow 845). The user server 810 is able to communicate this information to the receiving system 115 based on the information previously communicated by the user server 805 assigned to the sending system user to the user system 810 assigned to the receiving system user. However, it is also possible for the user system 810 assigned to the receiving system user to query the user system 805 assigned to the sending system user for such information. The user server 810 gives the receiving system user a session key with which the receiving system 115 contacts the data server 815 and retrieves the parcel (arrow 850). The data server 815 captures the transaction information as described above, which can be useful in preparing billing information.
• proxy servers 900 and 905 are connected between the network 105 and, respectively, the sending system 110 and the receiving system 115. While shown in Fig. 9 as two distinct proxy servers 900, 905, in some implementations the proxy servers 900, 905 can be included in the same proxy server. In addition, while shown in Fig. 9 as singular systems, proxy servers 900 and 905 may each include several interconnected servers or systems of servers. Each proxy server 900, 905 works in conjunction with a firewall (not shown) to allow cornmunications to and from the network 105 by the sending and receiving systems 110, 115. Consequently, for the sending and receiving systems 110, 115 to exchange parcels through the server system 125, the parcels must satisfy criteria established by the proxy servers 900, 905 to avoid being blocked from passing through the respective proxy server.
• the proxy servers 900, 905 are HTTP proxy servers that communicate using HTTP messages (i.e., transactions).
• the format of each HTTP transaction generally includes an initial line followed by zero or more header lines, an empty line (i.e., carriage return, line feed (CRLF)), and an optional message body: Initial line (e.g. request or response transaction)
• Optional header line 1 value 1 CRLF
• Optional header line 2 value2 CRLF
• Optional header line X valueX CRLF CRLF message body.
• Fig. 10 illustrates an exemplary format and content of an exemplary HTTP transaction 1000 for use in transmitting a parcel through an HTTP proxy server.
• the HTTP transaction 1000 includes an initial line 1005, one or more header lines 1010, a blank line (CRLF) 1015, and the digital information 1020 associated with the fransaction 1000.
• the digital information 1020 represents, for example, a portion of the parcel being transmitted, a parcel description, and parcel commands.
• the initial line 1005 indicates the type of HTTP transaction (e.g., POST and GET commands).
• the header lines 1010 include protocol information used by the sending, server, and receiving systems to direct the operation of the parcel delivery service.
• the parcel delivery service protocol specifies rales for conducting parcel deliveiy transactions such as, for example, authentication, uploading and downloading parcels, requesting a list of parcels that can be uploaded and downloaded, sending, receiving and tracking parcels, and performing commands, such as cancel delivery, mark parcel as open, and mark parcel as moved.
• parcels are large files or documents that cannot be completely transmitted with a single HTTP transaction. Accordingly, for large parcels, multiple HTTP transactions are typically necessary to transmit the entire parcel from the sending system 110 to the server system 125 or from the server system 125 to the receiving system 115. Each HTTP transaction therefore generally transfers only a portion of the parcel.
• the digital information 1020 represents the parcel data included in the transaction that is being transmitted by the sending system 110 or requested by the receiving system 115.
• the digital information 1020 is binary data.
• the proxy server objects to pure binary data other implementations may have the sending system 110 or the server system 125 convert the pure binary data into printable characters (e.g., by creating hexadecimal values for each byte).
• the receiver of the converted data either the server system 125 or the receiving system 115, converts the printable characters back into pure binary data.
• the sending system 110 transmits a parcel to the server system 125 according to a procedure 1100.
• the client parcel software executing on the sending system 110 follows a series of parcel delivery protocol steps until the sending system 110 obtains approval from the server system 125 to upload the parcel (step 1105), an example of which process is illustrated and described in greater detail with respect to Figs. 11B-1 IC.
• the sending system 110 determines an appropriate byte size for transmitting transactions through the proxy server 900 (step 1110), an example of which process is illustrated and described in greater detail with respect to Fig. 12.
• the sending system 110 generates a transaction that includes a portion of the parcel corresponding to the determined byte size (step 1115).
• the sending system 110 transmits that transaction to the server system 125 (step 1130). Steps 1110-1120 are repeated until the entire parcel passes to the server system 125 (step 1125).
• the receiving system 115 follows a similar process when requesting a parcel from the server system 125.
• the client software executing on the receiving system 115 follows a series of parcel delivery protocol steps until the receiving system 115 obtains approval from the server system 125 to download the parcel (step 1105).
• the receiving system 115 specifies the appropriate byte size when requesting delivery of the parcel from the server system 125 (step 1110).
• the receiving system 115 generates the transaction (step 1115) that the server system 125 fulfills by sending a portion of the parcel corresponding to the determined byte size (step 1120). Steps 1110-1120 are repeated until the entire parcel passes to the receiving system 115 (step 1125).
• the sending system 110 performs a series of parcel delivery protocol steps 1105 to obtain approval from the server system 125 to upload the parcel.
• the receiving system 115 follows a similar process when requesting a parcel for downloading from the server system 125.
• the sending system 110 issues a transaction (e.g., an HTTP transaction) to the server system 125 to request authentication from the server system 125 (step 1135).
• the server system 125 authenticates the sending system 110 by ensuring that the user of the sending system 110 has an account with the parcel delivery service, generally using a password authentication process. For instance, the server system 26 establishes such an account for the sending system user by having the user engage in a registration procedure.
• the sending system user provides personal information, such as a name, an address, and credit card information, to the server system 115.
• the systems 110, 125 then establish the password.
• the server system 125 responds to the authentication request from the sending system 110 by returning a session handle for use by the sending system 110 in subsequent transactions.
• the sending system 110 then sends a transaction to the server system 125 (step 1140) to provide parcel information associated with one or more parcels that the sending system 110 wants to deliver through the server system 125.
• the parcel information can include, for example, parcel attributes (such as size, name, and parcel type), a billing account number, recipients, and text message information.
• the server system 125 validates the parcel information. Upon successful validation, the server system 125 assigns a server for receiving the parcel. Also, the server system 125 notifies the assigned server to prepare for the pending parcel transfer and any server associated with the recipients designated in the parcel information.
• the sending system 110 then issues a transaction to get a list of those parcels that the server system 125 permits the sending system 110 to send (step 1145).
• the server system 125 responds with the list of parcels and the address of a server to which the sending system 110 is to send the parcels (step 1150).
• this address references the server system 125.
• the address references another server system in the group of server systems. Included in the response to the sending system 110 is an encrypted key that the sending system 110 uses for authentication with the server system referenced by the address.
• server system 125 When the referenced server system, e.g., server system 125, authenticates the sending system 110 with the key (step 1155), that server system 125 provides the sending system 110 with another session handle that is used for uploading the parcel from the sending system 110 to the server system 125.
• Fig. 11C illustrates an exemplary process 1160 by which the sending system 110 transmits a parcel to the server system 125, and by which the server system 125 transmits the parcel to the receiving system 115.
• the sending system 110 executes the client parcel software (step 1162).
• the sending system 110 includes encryption software for encrypting parcel data of each parcel portion (step 1104).
• the encryption software can employ any combination of one or more asymmetric or symmetric encryption algorithms to encrypt the parcel data. If the server system 125 is acting as a certificate authority, then the server system 125 possesses each key used in the encryption process. If another entity is acting as a certificate authority, in addition to or instead of the server system 125, then the server system 125 does not possess the key or keys for decrypting this encryption, such that the encryption seals the contents of the parcel from discovery by the server system 125.
• the sendmg system 110 then combines the encrypted parcel data with parcel delivery protocol information described above (step 1166). Before placing the encrypted and encapsulated parcel onto the network, the sending system may again encrypt and compress the parcel data along with the protocol information using encryption software that the server system 125 can decipher (step 1168). In some implementations, the parcel data is excluded from this second encryption step. The compression reduces the required network bandwidth for conveying the parcel. The sending system 110 then encapsulates the encrypted and compressed parcel delivery protocol information and parcel data within meta-protocol information, e.g., the HTTP protocol, to produce the transaction (step 1170).
• meta-protocol information e.g., the HTTP protocol
• the sending system 110 transmits the transaction to the server system 125 as described above and notifies the receiving system 115 (not shown).
• the server system 125 receives the transaction and processes the meta-protocol information in the transaction (step 1175).
• the server system 125 then decompresses and decrypts the processed meta-protocol information to obtain the parcel delivery protocol information (step 1177).
• the server system 125 processes the parcel delivery protocol information and stores the parcel data(step 1179). Steps 1162 to 1179 repeat until the server system 125 receives the entire parcel from the sending system 110.
• the parcel remains stored at the server system 125 until the receiving system 115 requests the parcel or until a predetermined time period elapses, at which point the server system 125 deletes the parcel.
• the receiving system 115 executes the client parcel software to access the parcel delivery service operating on the server system 125 as described above.
• the receiving system user provides logon information so that the server system 125 can authenticate the identity of the user.
• the server system 125 establishes an account for the receiving system user by having the user engage in a registration procedure during which the server system 125 obtains personal information about the receiving system user.
• the server system 125 To transmit the parcel, transaction by transaction, the server system 125 combines each portion of parcel data with parcel delivery protocol information (step 1181). The server system 125 then encrypts and compresses the parcel portion (step 1183).
• the server system 125 may use the encryption algorithm used by the sending system 110, and may also use an additional or alternative encryption algorithm. The use of different algorithms provides the flexibility to use the delivery system 100 across various international domains that can have varying resfrictions on the type of encryption.
• the server system 125 then encapsulates the encrypted and compressed data within meta-protocol information that enables the transaction to pass through the proxy server 905 (step 1185).
• the receiving system 115 Upon obtaining the parcel portion, the receiving system 115 processes the meta- protocol information (step 1190). The receiving system 115 then decompresses and decrypts the processed data to obtain the parcel delivery protocol information (step 1192). Next, the receiving system 115 processes the parcel delivery protocol information as directed by that information(step 1194), and then decrypts the parcel data in the transaction (step 1196). Finally, the receiving system passes the parcel data to the client parcel software .
• the electronic parcel delivery system 100 can deliver parcels of any size.
• proxy servers generally limit the amount of data that can pass through the firewall for a given transaction. Accordingly, the sending system 110 and the receiving system 115 keep each transmitted or requested parcel portion within the size limit imposed by the proxy servers. The number of portions needed to transmit a parcel depends upon the overall size of the parcel and this size limit.
• Fig. 12 illustrates an exemplary process 1110 by which the sending system 110 or the receiving system 115 dynamically determines the byte size of a transaction.
• the sending system 110 uses a predetermined size for a transaction (step 1205).
• the predetermined size corresponds to the maximum size limit typically imposed by proxy servers on the network 105, which is four megabytes.
• the sending system 110 transmits the transaction with the predetermined size (step 1210), and the proxy server 900 intercepts the transaction. If the size of the transaction exceeds the size limit allowed by the proxy server 900, then the proxy server 900 blocks further transmission of the transaction and reports an error.
• the sending system 110 Upon receiving an error message from the proxy server (step 1215), the sending system 110 reduces the transaction size (step 1220). In one embodiment, the transaction size is halved (e.g., a 4 Mb portion becomes a 2 Mb portion); however, other criteria for reducing the fransaction size can be used. The sending system 110 then attempts to transmit the transaction having the new, smaller size (step 1210). If the sending system 110 receives another error message (step 1215), the sending system reduces the transaction size again (step 1220). The process of transmitting and reducing continues until the sending system 110 no longer receives an error message from the proxy server 900 because of the size of the transmitted transaction (step 1215).
• the transaction size is halved (e.g., a 4 Mb portion becomes a 2 Mb portion); however, other criteria for reducing the fransaction size can be used.
• the sending system 110 attempts to transmit the transaction having the new, smaller size (step 1210). If the sending system 110 receives another error message (step 12
• the server system 110 then transmits the remaining portions of the parcel using the current parcel portion size that successfully passed through the proxy server 900 (step 1225).
• the sending system 110 further optimizes the parcel portion size by attempting to transmit a parcel portion with a larger size than the current size, but with a smaller size than the parcel portion that was last rejected by the proxy server 900.
• the receiving system 115 performs process 1110 in a similar manner when requesting the parcel from the server system 125. Initially, the receiving system 115 uses a predetermined size for a transaction (step 1205). The receiving system 115 requests the transaction with the predetermined size (step 1210), and the proxy server 905 intercepts the transaction. If the size of the transaction exceeds the size limit allowed by the proxy server 905, then the proxy server 905 prevents the receiving system 115 from receiving the transaction and produces an error message.
• the receiving system 115 Upon receiving an error message (step 1215), the receiving system 115 reduces the size of the transaction and requests the transaction having the reduced size (step 1210). If the receiving system receives another error message, the receiving system reduces the transaction size again (step 1220). The process of transmitting and reducing continues until the receiving system no longer encounters an error because of the size of the fransmitted transaction. The receiving system subsequently requests the remaining portions of the parcel using the current transaction size that successfully passed through the proxy server 905 (step 1225).
• the sending system 110 can also dynamically determine the format of information encapsulated within the header of the meta-protocol. For example, the inclusion of information following the required information within the header of the HTTP protocol can have a variety of formats. Some proxy servers impose restrictions on these formats. For example, one proxy server can restrict the number of bytes of information within a particular line within the HTTP header.
• Fig. 13 illustrates an exemplary process 1300 by which the sending system 110 or the receiving system 115 dynamically determines the format of the delivery service protocol information encapsulated within the meta-protocol information.
• the sending system 110 encapsulates delivery service protocol information using a predetermined format (step 1305).
• the predetermined format for encapsulating one kilobyte of protocol data can be four header lines with each header line having 256 bytes.
• the sending system 110 transmits the transaction with the initial format (step 1310), and the proxy server 900 intercepts the transaction. If the proxy server 900 objects to the current format, the proxy server 900 blocks further transmission of the transaction and reports an error to the sending system 110.
• the sending system 110 Upon receiving the error message (step 1315), the sending system 110 alters the format (step 1320). In one embodiment, the sending system 110 reduces the number of bytes per header line by half (e.g., 256 bytes per line become 128 bytes per line) and doubles the number of header lines. Again, the sending system 110 can use other criteria for reducing the number of bytes per line within the header. The sending system 110 then attempts to transmit the transaction with the new format (step • 1310).
• the sending system 110 again receives an error message (step 1315), the sending system alters the format again (step 1320). Transmitting the transaction (step 1310) and altering the format (step 1320) continue until the sending system 110 no longer receives an error message from the proxy server 900 because of the format of the transmitted transaction.
• the sending system 110 subsequently transmits the remaining parcel portions of the parcel using the current format that successfully passed through the proxy server 900 (step 1325).
• the sending system 110 optimizes the format by attempting to transmit a parcel portion with a format having more bytes per header line than the current format, but with fewer bytes per line than the format of the transaction that last failed to pass through the proxy server 900.
• the receiving system 115 performs the process described in Fig. 13 in a similar manner when requesting the parcel from the server system 26.
• the receiving system 18 encapsulates delivery service protocol information using a predetermined initial format as described above (step 1305).
• the receiving system 115 transmits the fransaction with the initial format (step 1310), and the proxy server 905 intercepts the transaction. If the proxy server 905 objects to the current format, the proxy server 905 blocks further transmission of the transaction and reports an error to the receiving system 115.
• the receiving system 115 alters the format (step 1320). The receiving system 115 then attempts to transmit the transaction with the new format (step 1310).
• the receiving system 115 again receives an error message (step 1315), the format is altered again (step 1320). Transmitting the transaction (step 1310) and altering the format (step 1320) continue until the receiving system 115 no longer receives an error message from the proxy server 905 because of the format of the fransmitted fransaction. The receiving system 115 subsequently transmits the remaining parcel portions of the parcel using the current formal that successfully passed through the proxy server 905 (step 1325).
• the electronic parcel delivery system 100 can be integrated into various business operations.
• Fig. 14 illustrates an exemplary implementation 1400 in which the electronic parcel delivery system 100 facilitates the conducting of electronic commerce.
• entity A 1405 operates the sending system 110
• entity B 1410 operates the receiving system 115
• entity C 1415 operates a second receiving system 1420.
• the server system 125 includes software 1425, e.g., APIs (Application Program Interfaces), for defining the transactions that can be performed by sending and receiving systems 110, 115, 1420.
• APIs Application Program Interfaces
• defined transactions can include, for example, delivering a newspaper, subscribing to the newspaper, opening a electronic newspaper by a receiving system, and canceling a subscription.
• the server system 125 also stores a software data structure 1430 (e.g., a table) that associates a fee with each defined transaction.
• the data structure 1430 operates as a price list.
• the software 1425 includes a software module that maintains a record 1435 of the transactions performed by the sending system 110 and each receiving system 115, 1420. Another software module calculates an amount owed by each sending and receiving system by referencing the record 1435 of performed transactions and the pricing list 1430.
• the server system 125 can then generate invoices 1440, 1445 specifying the amount owed by each system.
• the server system 125 can deliver such invoices 1440,1445 for payment to each receiving system 115, 1420, or can charge their respective accounts.
• Figs. 15A andl5B illustrate an exemplary implementation of the electronic delivery system 10 in which the delivery service, operating on the server system 125, coordinates the purchase and delivery of a product among a purchaser entity A 1505, a seller entity B 1510, and a delivery entity C 1515.
• the sending system 110 of the purchaser entity A 1505 transmits a parcel to the server system 125 for subsequent delivery to the receiving system 1520 of the seller entity B 1510 (step 1550).
• the parcel can be an order for 100 automobile parts.
• the server system 125 Upon receiving the parcel (e.g., order), the server system 125 transmits the parcel to the receiving system 1520 of seller entity 1510 (step 1555).
• the sending system 110 can send a notification of the parcel to the receiving system 1520 of seller entity 1510, which can then contact the server system 125 to request the parcel.
• the receiving system 1520 accepts the order (step 1560) and sends a notification of acceptance to the server system 125 (step 1565).
• the server system 125 delivers the notification of acceptance to the sending system 110 (step 1570), and then notifies the receiving system 115 of the order (step 1575).
• the receiving system 115 then confirms with the server system 125 that it intends to obtain and deliver the goods associated with the parcel (e.g., order) (step 1580), and the server system 125 delivers this confirmation to the sending system 110 (step 1585).
• entity C which includes the receiving system 115, obtains the goods from entity B, which includes the receiving system 1520 (step 1590), and delivers the goods to entity A, which includes the sending system 110 (step 1595). Goods may be delivered physically (e.g., by truck) or electronically, as appropriate.
• Figs. 16A and 16B illustrate an exemplary implementation 1600 of the electronic delivery system 100 in which the delivery service, operating on the server system 125, controls work flow in an operation involving a purchaser entity A 1605, a seller entity B 1610, and a seller entity C 1615.
• the sending system 110 of the purchaser entity A 1605 transmits a parcel to the server system 125 for subsequent delivery to receiving systems 1620, 1625 of entities 1610, 1615, respectively.
• the parcel is an invitation for offers regarding the price of particular goods (e.g., 100 automobile parts).
• the sending system 100 may notify each receiving system 1620, 1625 that the invitation is available at the server system 125.
• Each receiving system 1620, 1625 obtains the parcel (step 1655) and replies with an offer (steps 1660, 1665).
• the server system 125 selects an offer (step 1670) by, for example, executing software, that determines which offer to select. For example, the server system 125 might accept the offer from entity B (step 1675) and reject the offer from entity C (step 1680). The server system 125 then confirms the transaction with the sending system 110 (step 1685). In another implementation, the sending system 110, rather than the server system 125, selects the offer and issues the notices of acceptance and rejection.
• Other embodiments of the electronic parcel delivery system 100 can combine the various features shown in Figs. 14, 15A, 15B, 16A and 16B and discussed above.
• the electronic parcel delivery system 100 can cooperate with other parcel delivery mechanisms.
• the server system 125 can print a copy of the parcel received from the sending system 110. Rather than transmit the parcel to the receiving system 115 over the network 105, the server system 125 can fax the parcel to the receiving system 110.
• the server system 125 prints a copy of the parcel on a printer and sends the printed copy through a carrier service.
• a hybrid system 1700 integrates a parcel delivery system, such as the system 100 described above, with a standard electronic mail (e-mail) system.
• the hybrid system 1700 redirects relatively large transmissions from a standard e- mail system to a parcel delivery system, such that the hybrid system is capable of handling larger fransmissions than a standard e-mail system.
• the system 1700 provides a user with a standard e-mail user interface, while still providing the advantages of a parcel delivery system.
• the user only needs to maintain a single set of contacts and mailing lists.
• each of one or more local network users 1705 runs an e- mail program 1710, such as MICROSOFT OUTLOOKTM, on a local system.
• the e-mail program 1710 presents a standard user interface.
• the interface is generally a graphical user interface (GUI), such that a user familiar with the e-mail program 1710 does not need to learn a new interface in order to interact with the hybrid system 1700.
• GUI graphical user interface
• other interfaces may be used to replace or augment the standard e-mail interface, e.g., parallel serial/other data ports capable of receiving propagated signals carryiiig the electronic data.
• An e-mail server 1715 communicates with the e-mail program 1710 to coordinate transmission and receipt of messages and other items.
• messages and other items are classified as local messages, other local items, remote messages, and remote parcels.
• Local messages and other local items are transmitted between users of the same e-mail server 1715 (e.g., between a first user 1705 (user A) and a second user 1705 (user B)).
• Remote messages are messages transmitted between users of different e-mail servers (e.g., between a local user 1705 (user A) and a remote user 1720 (user D)).
• Remote parcels are items transmitted to remote users 1720 through the parcel delivery system.
• the e-mail server 1715 passes local messages and other local items between local users 1710.
• the e-mail server 1715 also directs remote messages to remote users 1720 over a network 1725, such as the Internet.
• a firewall 1730 isolates the e-mail server 1715 from the network 1725, and an e-mail proxy server 1735 is used to coordinate communications between the e-mail server 1715 and the network 1725.
• each different type of e-mail program 1710 may communicate with a different e-mail server 1715.
• the e-mail server 1715 identifies remote parcels to be transmitted using the parcel delivery system, and transmits the identified remote parcels to a local parcel server 1740.
• the users may affirmatively designate messages or other items to be transmitted using the parcel delivery system.
• the e-mail server 1715 may automatically direct items to the local parcel server 1740 using criteria such as file size and security indications. Rules may be established to identify items appropriate for delivery using the parcel delivery system, e.g., to direct traffic based on parcel characteristics. Referring to Fig. 18 A, in one implementation, the e-mail server 1715 processes outgoing items according to a procedure 1800.
• the server 1715 detennines whether an item to be communicated is directed to a local user 1705 (step 1805). If so, the server 1715 directs the item to the appropriate local user 1705 (step 1810). For communications not directed to local users (step 1805), the server 1715 determines whether the sending user 1705 has indicated that the parcel delivery system is to be used (step 1815), whether the size of the item being communicated exceeds a predetermined size threshold level (step 1820), whether the sending user 1705 has indicated that the item is sensitive or that it otherwise requires secure handling (step 1825), whether the sending user 1705 has indicated that the item requires controlled access (step 1830), and whether the item will overload the e-mail server 1715 (step 1835).
• the e-mail server 1715 directs the item being communicated to the local parcel server 1740 for transmission using the parcel delivery system (step 1840). Otherwise, the e-mail server 1715 directs the item being communicated to the e-mail proxy server 1735 for normal e-mail transmission (step 1845).
• the document delivery system has encryption and other controlled access capabilities making it particularly useful for sensitive communications and the like.
• Examples of the controlled access capabilities of the document delivery system may include the provision of detailed sender monitoring with regard to the status of the communication (e.g., delivered to or read by the intended recipient), as well as limitations on the recipient's ability to save, copy, or print the communication, and sender monitoring of which of those acts has been performed.
• the local parcel server 1740 functions in much the same way as the client parcel software of the sending system (e.g., sending system 110) of the document delivery system 100 described above with respect to Fig. 1.
• the system operates according to the procedure 1850 illustrated in Fig. 18B.
• local parcel server 1740 formats outgoing electronic parcels based on an electronic parcel protocol that differs from the standard electronic mail protocol used by e-mail server 1715 to format outgoing e-mail messages (step 1855).
• the electromc parcel and electronic mail protocols may differ with respect to an allowable maximum size for electronic parcels and mail messages, or they may differ with respect to other or additional criteria.
• the electronic parcel protocol may allow for a maximum parcel size that exceeds the maximum electronic mail message size permitted by the electronic mail protocol.
• local parcel server 1740 directs the outgoing electronic parcel to the intended recipient by, e.g., transmitting that parcel to an electronic parcel warehouse 1750 over the network 1725 (step 1860).
• local parcel server 1710 uses a proxy server 1745 to communicate over the network 1725.
• proxy server 1745 may or may not be used.
• the parcel warehouse 1750 functions in much the same way as the server (e.g., server
• the parcel warehouse 1750 communicates with a remote parcel server 1760 to deliver items to the remote parcel server 1760 and ultimately to remote users 1720 through remote e-mail server 1765.
• communications between the network 1725 and remote e-mail server 1765 may be through e-mail proxy server 1770 in much the same way that communications between the network 1725 and e-mail server 1715 were through e-mail proxy server 1735, and communications between electronic parcel warehouse 1750 and parcel server 1760 are through proxy server 1755 in much the same way as communications between electronic parcel warehouse 1750 and parcel server 1740 were through proxy server 1745.
• the remote parcel server 1760 includes software that functions in much the same way as the client software of the receiving system (e.g., receiving system 115) of the document delivery system described above. Upon receiving a communication, the remote parcel server 1760 forwards the communication to a remote e-mail server 1765 for delivery to an appropriate user 1720.
• the user 1720 receives the communication as if it were an e-mail message sent using the normal e-mail messaging channel, and makes the received communication available on a standard user interface of the hybrid system. This interface is also used to make e-mail communications available to the recipient, and may be implemented, for example, as a common graphical user interface.
• the hybrid system 1700 provides seamless operation that is essentially transparent to the users 1710, 1720.
• parcel server 1760 receives communications including electronic parcels that are directed to users D, E, F 1720 (step 1875). These communications are formatted according to the electronic parcel protocol. Parcel server 1760 directs received electronic parcels to e-mail server 1765. Similarly, electronic mail messages formatted based on the electronic mail protocol are received by e-mail server 1765 (step 1880). E-mail server 1765 may then operate as a controller to direct received electronic parcels and electronic mail to a common user interface (e.g., a graphical user interface ordinarily integrated into an e-mail system) at the appropriate user 1720 (step 1885). Accordingly, the electronic parcel delivery system is able to send and receive electronic parcels, even if they do not conform with electronic mail protocols. Furthermore, the elecfronic mail may be delivered using a channel that does not include electronic parcel delivery servers.
• one site 1905 may employ a hybrid system while another site 1910 employs isolated e-mail and document delivery systems with either site being capable of sending and/or receiving communications.
• all communications are transmitted and received through the common user interface as described above.
• normal e-mail messages are transmitted and received using an e-mail interface, while parcels delivered using the parcel delivery system are transmitted and received using an interface of the parcel delivery system.
• Combinations of the hybrid systems 1700 and 1900 may also be used.
• Both of the systems 1700, 1900 may use event-based e-mail messages to notify users of the status of communications. For example, when the e-mail server 1715 transfers a parcel to the local parcel server 1740, the e-mail server 1715 may send an e-mail message to the intended recipient indicating that the parcel is coming. Similarly, when the remote e-mail server 1760 receives a parcel from the remote parcel server 1755, it may send an e-mail message to the sender indicating that the parcel has been received. The e-mail server 1760 may also send messages to the sender indicating whether the parcel is opened, moved, read, deleted, or printed. In the event that a parcel is not delivered, e-mail messages may be sent to the sender, the intended recipient, or both.
• Figs. 20A and 20B illustrate an exemplary implementation of a deployment system employed in conjunction with an electronic parcel delivery system or a hybrid electronic mail and electronic parcel delivery system as described herein.
• the network 2000 is a secure, client-defined communications network that uses a parcel delivery server 2005 (e.g., server system 125 or elecfronic parcel warehouse 1750) as its central hub.
• a parcel delivery server 2005 e.g., server system 125 or elecfronic parcel warehouse 1750
• the communications over the network 2000, between the server 2005 and users 2010 or between users 2010 themselves, are secured by public/private key pairs.
• communications with a first user 2010 (user A) are protected by a first public/private key pair
• communications with a second user 2010 (user B) are protected by a second public/private key pair.
• Users 2010 of the network 2000 may have certificate-based identities, in which each user 2010 is identified by a certificate which is generally a downloaded file, and an associated password. This is in confrast to fraditional identification approaches in which a network user is identified by a user name and a password.
• a user's certificate contains the user's digital public/private keys, server connection information, a user identification, and an indication of certificate authority.
• a parcel server or group of parcel servers e.g., one or more local parcel servers 1740
• the server 2005 provides centrally-managed certificates to enable secure communications with each user 2010.
• a particular user 2010 only needs to know its own public key to enable communication with the server 2005 and thus to enable communications with other users 2010 that also communicate with the server 2005.
• users 2010 individually need not to know the public keys of other users 2010 in order to communicate with those users 2010, eliminating the need for an exchange of public keys otherwise required to enable communications between users 2010. Therefore, the protocol provides for a first secure communication between a transmitting user 2010 and server 2005 based on a first public key shared therebetween, and for a second secure communication between the server 2005 and a recipient user 2010 based on a second public key shared therebetween.
• the network 2000 may be implemented and used to permit a user 2010 to make secure data connections to a large number of other users 2010 in minimal time and with minimal traffic.
• a user 2010 can be added to the network in fifteen minutes or less, with multiple users being added simultaneously.
• the addition of a user 2010 only requires the user 2010 to install the client parcel software and to install a certificate corresponding to the public/private key pair for the user 2010.
• the installation of client software may be unnecessary.
• the client parcel software works through firewalls, enabling its installation on virtually any machine. Both the client parcel software and the certificate can be downloaded from a network, such that the installation can proceed completely electronically.
• the installation can be initiated with a single click of a prospective user's mouse, and can be completed entirely automatically such that only the single mouse click is required to complete the installation.
• identification and/or contact information for one or more prospective deployment candidates may be obtained using an electronic interface (step 2025).
• the electronic interface may be a graphical or other user interface that is accessible by a user.
• the electronic interface may be with a network such as the Internet, with a parallel, serial or other type of data port, or with any other system or device capable of receivmg propagated signals carrying electrical information.
• the identification information may be temporarily or permanently stored, and an account may be automatically created by the parcel delivery server 2005 for each of the prospective candidates (step 2030).
• Authorization is subsequently sought from each prospective deployment candidate to add that candidate to the communications network, thereby enabling secure communications between that candidate and the customer (step 2035).
• Authorization may be generally sought by automatically sending an e-mail request based on the identification information provided by the customer, which generally includes at least an e-mail address.
• the authorization request may be a general request to add the candidates to the network, or it may be more detailed request (e.g., listing information about the candidate for their review and/or requesting to configure the candidate's computer to enable communications of electronic parcels with the customer or other existing and/or prospective members of the network).
• the prospective deployment candidate may be given an opportunity to amend that information (step 2095). For instance, if errors are determined to exist within data defining the newly created account (step 2095 A), a prospective deployment candidate may be given an opportunity to provide corrective data (step 2095B). Prospective deployment candidates may be shown their account information repeatedly after each correction or series of several corrections, providing them an opportunity to again review newly added or changed information in their account, to identify additional or remaining errors in their account information, and to correct such errors (steps 2035, 2095).
• the candidate When authorization for the new account is received from the prospective deployment candidate (step 2040), the candidate is added to the network and communications are enabled (step 2045).
• customer software and login information are automatically downloaded and installed on the computer of the new user to enable future and secure access to their account (step 2045).
• the login information for an account generally includes public/private key pairs, such that a certificate is created and downloaded.
• the deployment Web site is updated with the new account information, enabling the customer to begin transactions with the newly added user (step 2055).
• a request is sent to the customer 2015 to review the account information stored regarding the prospective deployment candidate (step 2060). If an error exists in the contact information or other account information (step 2065), the customer 2015 is able to correct and update the account (step 2070) such that authorization may be again requested of the prospective deployment candidate (step 2035).
• the contact and account information is deemed acceptable (step 2065)
• a determination can be made as to whether personal contact with the prospective deployment candidate is appropriate (step 2075).
• personal contact is attempted (step 2080).
• the account information may be held for future use (step 2085). Personal contact is generally deemed appropriate when the prospective deployment candidate has been contacted only by electronic means.
• problems may be experienced while attempting to enable communications.
• a procedure 2090 is performed to resolve such problems.
• problems are technical in nature (step 2090A)
• they are generally directed to technical representatives for resolution (step 2090B), and a subsequent attempt is made to enable communications (step 2045).
• problems are not technical in nature (step 2090A)
• the prospective deployment candidate may be contacted by a customer service representative to resolve problems (step 2090C).
• server 2005 may be globally distributed while still providing a single, contiguous service.
• the server 2005 could include a first server portion 2100 located in the United States and a second server portion 2105 located in Japan.
• the premium components may be in the form of modules that are easily (and automatically) incorporated in the client parcel software and may be downloaded along with the client parcel software, or at a later date or time.
• Examples of premium component modules include a receive automation module, a send automation module, a notification module, and a copy protection module.
• the receive automation module provides for automatic processing of received communications including mail and parcels.
• the receive automation module uses sophisticated filtering techniques to pass received data to programs or scripts for post- delivery data processing. Different filtering parameters may include, for example, the identity of the parcel's sender, the description of the parcel, and the time at which the parcel is sent.
• the receive automation module can be used to incorporate data files enclosed in parcels from several sources into a single, combined data file, to generate a report using an application program that processes the combined data file, to incorporate the generated report into a parcel, and to send the parcel to a list of recipients.
• the send automation module works similarly to the receive automation module.
• the send automation module may be used, for example, to automatically send a group of files to a list of recipients at a specified time. For example, the send automation module could be used to send, on an hourly basis, all files from a particular folder or directory that have been edited or created within the previous hour.
• Figs. 22A-22D illustrate exemplary graphical user interfaces useful in enabling send and receive automation modules having characteristics as described above
• Figs. 22A and 22C illustrate exemplary graphical user interfaces 2200 and 2220 including interactive selectable buttons 2202 for enabling at least the receive automation module and send automation module.
• an example of a graphical user interface 2200 for the receive automation module permits a user to designate one or more software programs for automatically processing received documents. For instance, in the particular example illustrated in Fig. 22A, an automatic filtering process is made available to the customer, and the customer is allowed to specify conditions for accepting and rejecting documents from selected senders. For instance, as illustrated in area 2204, a user may list one or more senders along with associated filtering information and filtering status.
• Filtering information may indicate the software used to perform the filtering function.
• Fig. 22B illustrates an exemplary graphical user interface 2210 useful in specifying filter information. As illusfrated, it is possible to identify a software filter by name 2212, and to apply that filter to parcels received from one or more senders 2214 or parcels directed to one or more subjects 2216.
• Filtering status indicates how to handle parcels received from the corcesponding sender, e.g., accept or reject.
• a default filtering status 2206 may also be used to specify one of several default rules to be applied to senders for which filtering is not otherwise specified. Although countless other default states may be used, three are illusfrated in Fig. 22A, namely (1) always accept parcels from unlisted senders, (2) always reject parcels from unlisted senders, and (3) ask once to accept or reject parcels from each unlisted sender.
• FIG. 22C an example of a graphical user interface 2220 for the send automation module permits a user is able to designate one or more deliveries to be automatically initiated at a specified time.
• Fig. 22D illustrates a graphical user interface 2230 useful in entering information when designating deliveries to be automated by the send automation module.
• information solicited by this graphical user interface 2230 includes identifiers for the recipient and/or subject 2232, the location of folders/files to be sent 2234, the time for delivery 2236, message information to accompany the delivery 2238, and account information for billing purposes and the like 2240. Delivery time may include periodic deliveries.
• the notification module provides automatic notification of a variety of events associated with an electronic communication. For example, as noted above, a sender may receive e-mails when a parcel is received, opened, moved, read, deleted, processed, or printed. Similarly, a recipient may receive an e-mail noting that a parcel is coming when the parcel is transmitted. In the event that a parcel is not delivered, e-mail messages may be sent to the sender, the intended recipient, or both.
• the copy protection module provides a sender with the ability to control a recipient's access to the contents of a parcel.
• the sender can use the copy protection module to prevent a recipient from printing or copying the contents of a parcel.
• Techniques for controlling access to the contents of transmitted parcels are described in U.S Application No. 09/281,894, titled "Method And Apparatus For Protecting Documents From Unauthorized Copying And Distributing Of Electronic Messages Transmitted Over A Network" and filed March 31, 1999, which is incorporated by reference.
• the hybrid document and parcel delivery system described above may be configured to support use by groups of multiple users associated with a common account and login information. From a management perspective, such a configuration enables features such as centralized billing and account management. From the client's and/or the user's perspective, this configuration enables features such as centralized document handling.
• a multi-user account is established based on various criteria including general identification information, account characteristics, and/or user lists.
• General identification information may include login information and/or contact information.
• Login information typically includes an account login name (e.g., screen name) and/or password information.
• Contact information generally includes a company and/or account representative's name, an address (e.g., physical and/or elecfronic), and/or a telephone number.
• Account characteristics generally include billing information and information regarding limits (e.g., usage limits) placed on the account.
• One or more user lists may be established for each account. Users are added to an account in much the same way that users are added to the deployment lists, as discussed above with respect to Figs. 20A and 20B. For instance, the users may be added by entering identifying information and by creating login information including passwords or certifications. Users may be listed on more than one account, each account sharing identification information but maintainmg unique login information for the user. A single user may be listed on one or more accounts.
• an account can be updated and/or edited by any user having the account identification and login information. Additionally, users of an account may access information concerning their individual user name using a user-specified identification code. In this way, the general account becomes transparent to individual users therein.
• the hybrid electronic mail and electronic delivery system 1700 may be implemented by modifying an existing e-mail system according to a procedure 2300.
• a request for a hybrid system is received (step 2305).
• a request may be an explicit request made by a prospective user (e.g., by telephone, facsimile, e-mail, or otherwise), or a request may be a virtual request generated based on information gathered for one or more perspective users that indicates a desirability for the hybrid system on the part of the perspective users (e.g., information-based marketing information).
• a hybrid system module that is capable of modifying a previously-installed electronic mail system is supplied so as to cause a previously-installed electronic mail system to function in the manner described above (step 2310).
• a standalone hybrid system module that does not require modification of an existing e-mail system may be provided.
• Such a standalone hybrid system module can be loaded on computer systems having no e-mail capabilities to provide the functionality described herein.
• the systems and techniques described above may be implemented as one or more computer- readable software programs embodied on or in one or more articles of manufacture.
• the article of manufacture can be, for example, any one or combination of a floppy disk, a hard disk, hard-disk drive, a CD-ROM, a DVD-ROM, a flash memory card, an EEPROM, an EPROM, a PROM, a RAM, a ROM, or a magnetic tape.
• any standard or proprietary, programming or interpretive language can be used to produce the computer- readable software programs. Examples of such languages include C, C++, Pascal, JAVA, BASIC, Visual Basic, LISP, PERL, and PROLOG.
• the software programs may be stored on or in one or more articles of manufacture as source code, object code, interpretive code, or executable code.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Information Transfer Between Computers (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=24226186

Family Applications (1)

Country Status (4)

Families Citing this family (1)

• 2001
  • 2001-04-23 EP EP01930641A patent/EP1293071A2/de not_active Withdrawn
  • 2001-04-23 JP JP2001579517A patent/JP2003532339A/ja active Pending
  • 2001-04-23 WO PCT/US2001/013004 patent/WO2001082553A2/en not_active Application Discontinuation
  • 2001-04-23 AU AU2001257156A patent/AU2001257156A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events