WO2000022787A2 - Procede, systeme et produit de programme informatique pour des services de courrier electronique renforces - Google Patents

Procede, systeme et produit de programme informatique pour des services de courrier electronique renforces Download PDF

Info

Publication number
WO2000022787A2
WO2000022787A2 PCT/US1999/023453 US9923453W WO0022787A2 WO 2000022787 A2 WO2000022787 A2 WO 2000022787A2 US 9923453 W US9923453 W US 9923453W WO 0022787 A2 WO0022787 A2 WO 0022787A2
Authority
WO
WIPO (PCT)
Prior art keywords
message
party
receipt
protocol
user
Prior art date
Application number
PCT/US1999/023453
Other languages
English (en)
Other versions
WO2000022787A3 (fr
Inventor
Frank Wells Sudia
Original Assignee
Bankers Trust Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bankers Trust Company filed Critical Bankers Trust Company
Priority to AU11052/00A priority Critical patent/AU1105200A/en
Publication of WO2000022787A2 publication Critical patent/WO2000022787A2/fr
Publication of WO2000022787A3 publication Critical patent/WO2000022787A3/fr

Links

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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/23—Reliability checks, e.g. acknowledgments or fault reporting
    • 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
    • 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations

Definitions

  • the present invention relates generally to simultaneous electronic transactions, and more particularly to electronic authorization functions such as certified electronic mail and the like.
  • Electronic commerce includes businesses, individual entrepreneurs, organizations, and the like who offer their services and products to people all over the world via the Internet.
  • SUBSTITUTE SHEET (RULE 26 ⁇ Electronic commerce, like traditional commerce, depends on the ability of parties to perform transactions (e.g., an exchange of goods for some value). Thus, communications and electronic mail in general, must develop certain protocols in order to ensure transactions occur in an orderly and secure fashion. Similar to traditional commerce, parties must be able to assure the identity of those they deal with, verify the integrity of messages (e.g., orders) they receive, expect that any desired privacy of a transaction be maintained, and rely on the finality of a transaction by exchanging receipts and payments. In sum, the communications mechanism of electronic commerce, electronic mail, must provide the basic assurances found in traditional commerce.
  • FIG. 1 uses notations that will be apparent to one skilled in the relevant art(s) (e.g., cryptography). However, for completeness, the cryptographic notations used in FIG. 1 as well as throughout herein are summarized in Table 1. A detailed discussion of Cryptography and its associated notations can be found in B. Schneier, Applied Cryptography, John Wiley & Sons, 2nd ed. 1996 (USA) ("Schneier"). Furthermore, it is assumed, for simplicity, that the parties A and B are using a secure public-key encryption algorithm (e.g., RSA) and that the parties are able to communicate electronically via a computer network or the like.
  • RSA secure public-key encryption algorithm
  • FIG. 1 illustrates a party A who desires to send a message to another party B and obtain a receipt.
  • the ECM protocol uses an "invisible" trusted third- party, referred to as a post office (PO), to facilitate the transaction.
  • PO post office
  • This second encryption process of the inner message, M B is called super-encryption.
  • step 112 the post office will send to A, B ' s signed receipt R.
  • the above-described Micali protocol (steps 102-112) is summarized in Table 2 below. While only the transmissions between party A and B are labeled "steps,” it will be apparent to one skilled in the relevant art(s) that the intermediary steps shown in Table 2 are also part of the Micali protocol.
  • the present invention is directed to a method, system, and computer program product for providing enhanced electronic mail services.
  • the system includes a plurality of user sites, and a central post office (i.e., trusted third-party) complex.
  • the method includes an enhanced electronic mail protocol with several embodiments that allows, for example, facilitation of recipient's reconstruction of electronic mail messages, eliminates full resend of messages, minimizes communication during the recovery process, eliminates the need for super encryption, and allows parties (both recipients and senders) to delegate performance to (proxy) agents.
  • FIG. 1 is a flow diagram illustrating a conventional simultaneous electronic transaction
  • FIG. 2 is a block diagram representing the overall system architecture according to a preferred embodiment of the present invention.
  • FIGS. 3 A and 3B are flow diagrams illustrating the use of agents within a protocol according to a preferred embodiment of the present invention.
  • FIG. 4 is an L-Shaped Model of a protocol according to a preferred embodiment of the present invention
  • FIGS. 5A and 5B are a flow diagrams representing an enhanced electronic mail protocol implementing billing and policy signals according to an embodiment of the present invention.
  • FIG. 6 is a block diagram of an exemplary computer system useful for implementing the present invention.
  • the present invention relates to a method, system, and computer program product for providing enhanced electronic mail (EEM) services.
  • EEM enhanced electronic mail
  • business- to-business, customer-to-supplier, and business-to-consumer communications require not only simultaneity, but also security against many operation risks.
  • the use of EEM allows electronic commerce participants (i.e., "users") to exchange actual value (e.g., electronic cash and checks), confidential information, formal notifications, orders, etc. while addressing both simultaneity and security.
  • an organization provides an infrastructure, protocol, and facilities so that electronic commerce participants may utilize EEM to address their electronic commerce communications needs. More specifically, the EEM providing organization would furnish users with software and documentation to implement a particular embodiment of an EEM protocol, maintain one or more trusted third-party (post office) facilities, provide user customer service and support, as well as provide customer billing.
  • the present invention is described in terms of the above example. This is for convenience only and is not intended to limit the application of the present invention. In fact, after reading the following description, it will be apparent to one skilled in the relevant art how to implement the following invention in alternative embodiments (e.g., various electronic payment schemes, delivery of legal papers and summonses, tax filings, military orders, etc.). Furthermore, it will be appreciated by one skilled in the relevant art(s), that the protocol described herein can be applied to many other communications besides electronic mail. For example, the present invention may be applied to electronic data interchange (EDI), communication system protocols such as the Simple Network
  • SNMP Network Management Protocol
  • electronic process or machine control protocols electronic bidding or auctions, etc.
  • M can refer to any digital data, or may be null (e.g., a message of zero length containing no data).
  • M can refer to a set of files that are being sent as a group, which in existing secure mail systems, such as NetDoxTM, is sometimes called a "package.” This is analogous to a conventional express mail envelope that may contain several different documents or attachments. Most secure and non-secure mail or messaging systems, in practice, may involve a given message that contains any number of attachments. These are typically referred to as "attached files” having stated or recommended file names and file types, which can be "detached” and reconstituted as named files on the receiving computer system.
  • M may also contain a pointer to a message, file, or document.
  • M may be a uniform resource locator (URL) address pointing to where the actual message, file, or document is stored. It is preferable that the URL be accompanied by a hash value of the message, file, or document to which the URL is pointing, and potentially also a decryption key which can decrypt it after it has been retrieved, and optionally a user ID and password with which to retrieve it.
  • the present invention could be modified such that B. upon signing the receipt R, opens M B which preferably contains an URL, associated hash value, decryption key, user ID, and password. B can then use those values to retrieve the message, file, or document and decrypt it. and verify that the content matches the hash value.
  • the system architecture 200 includes a plurality of users (or participant) "sites" 206 (shown as sites 206a-206n in FIG. 2).
  • a user A or user B refers to a party who can access enhanced electronic mail (EEM) service provided by a EEM organization as explained above.
  • EEM enhanced electronic mail
  • Each user of the EEM system architecture 200 would employ a user mail agent 208, a user database 210, and a user set-up and administration application 212.
  • Each user site 206 is linked to the Internet 220 via an Internet Service Provider (ISP) 204 or in large companies an internal enterprise Service Provider (ESP) with substantially similar functions.
  • ISP Internet Service Provider
  • ESP enterprise Service Provider
  • a user ISP proxy 202 is also linked to the ISP provider 204 and constitutes a value added service of the ISP (or ESP) 204 whereby the user will appoint the ISP (or ESP) 104 to assist him or her in completing one (or both) sides of the user processing for the EEM protocol. This is desirable in view of the potential delays in completing the protocol (due to uncertain transit times) and the propensity of users to turn off their computers making them unavailable to complete the protocol.
  • PO trusted third-party Post Office
  • the PO complex 240 provides an infrastructure support for the "invisible" protocol, and administrative functions so that electronic commerce participants may utilize EEM services. As mentioned above, the PO complex 240 remains 'invisible” to the users until any recovery features of a EEM protocol are required.
  • the PO complex 240 includes a customer service Web site server 222 that allows users to access their accounts for billing, receipts, and other like services.
  • the PO complex 240 also includes an EEM recovery daemon 224, a billing information server 226, a developer Web site server 228. a PO database 230, and an administrative workstation 232.
  • the administrative workstation 232 allows
  • PO complex 240 The functions of the individual components of the PO complex 240, as well as the EEM system architecture 200 in general, are described more fully below. Furthermore, while only one PO complex 240 is shown in FIG.2, it will be apparent to one skilled in the relevant art(s) that a plurality of PO complexes 240 (each maintained by the same or a different EEM provider) may be connected to the Internet 220, all using interoperable embodiments of the EEM protocol of -l i ⁇
  • the system, method, and computer program product for providing enhanced electronic mail (EEM) services of the present invention provides benefits not found in the Micali ECM protocol described above with reference to FIG. 1 and Table 2, nor in the conventional electronic commerce services.
  • the different embodiments of the present invention provide different enhancements to the Micali ECM protocol 100. The following discussion highlights these enhancements and their respective benefits with reference to the EEM system architecture 200 (as shown in FIG. 2).
  • user B ' s reconstruction of the initial message, M is facilitated in comparison with Micali ECM protocol.
  • B must use the purported inner message
  • M B he has received to attempt to reconstruct the original message M 0 , in order to verify whether he now possesses the actual message for which he has signed.
  • the results of encrypting M with K + PO can be deterministic, when the "full message recovery" public key encryption method is used, but this is impractical for messages of normal size, in which case it is common to "envelope" the message with a random DES key and then encrypt that DES key using K ⁇ P0 , a process known as key transport (as in the popular RSA-DES mode of operation known as "RSA Key Transport").
  • user A may return the bitstring along with E B (M) on the third pass (i.e., step 106 of FIG. 1), preferably also encrypted using K + B .
  • the bitstring may be formed deterministically using bits taken from the inner message, either M or E B (M) (e.g., H(M) may be used as the bitstring), because these values are unknown to "outsiders.”
  • M E B
  • H(M) H(M)
  • the bitstring values e.g., a DES key
  • M E B
  • K K
  • B B can easily obtain it.
  • party A upon receiving R, party A more efficiently sends B a second copy of that DES key, preferably in the form of another message addressed to B.
  • That message may also contain a linkage indicator (e.g., the hash of the original inner message) and be encrypted using that same DES key formerly under K + P0 , except now that same DES key is being sent to B under K + B .
  • a linkage indicator e.g., the hash of the original inner message
  • A may send the third message encrypted under K * B using yet another random DES key, yet containing the original DES key and the hash as a separate short message, such as: A ⁇ B: E B ( K DES
  • the third message from A-*B may be a "detached substitute mail header" addressed to B, that may be merely affixed onto the front of the original message by B, such that B is now made a recipient of the original message, whereupon he opens the outer (PO) envelope as if it had been originally addressed to him. Both headers may be stored with the message for archival purposes.
  • the inner message remains encrypted (i.e., double encrypted) such that even if the PO 240 comes into possession of, and decrypts the outer envelope, the inner message to B remains unreadable by it. This enhances B's confidentiality and decreases the PO's potential liability for improper disclosure.
  • an embodiment of the present invention that does not require double encryption (or super-encryption) of M (as seen in step 102 of FIG. 1) can be implemented.
  • the PO 240 recovery process is reduced to one which B merely sends the header and signature blocks of M 0 , without sending the actual super-encrypted message body.
  • M being encrypted only once, using a DES key that is a blended value (e.g., using the XOR " ⁇ " operation) of two DES keys, one available to both user A and the PO. and the other available only to B.
  • a DES key that is a blended value e.g., using the XOR " ⁇ " operation
  • B can open his side of the header, but now he gets only a partial DES key K DESi .
  • B can decrypt M in a single step.
  • Table 4 The advantage of the embodiment, in this respect (i.e., single-step decryption), can be summarized as shown in Table 4 below. (Random number and linkage values are omitted for clarity.)
  • this above-described advantage of the present invention does not provide a large computational advantage for the average user. This is because DES is a relatively fast algorithm and decrypting M twice does not generally consume noticeably more resources than decrypting it only once. This is especially true if the Micali protocol is implemented such that both the outer and inner decryptions are processed simultaneously, on a streaming basis, eliminating the need to fully buffer the intermediate result.
  • This single decryption embodiment of the EEM protocol does provide a significant advantage to a party that must rapidly process a large number of long messages.
  • B may receive service from the PO 240 by merely sending that detached header to the PO, along with B's receipt, rather then B having to send M 0 in its entirety to the PO.
  • This reformatting seeks to: (a) provide the PO 240 enough information to permit recovery without sending M 0 in its entirety, (b) convince that PO 240 that A really sent M 0 , and (c) provide a receipt R signed by B that will be convincing to A. This can be achieved by formatting M 0 in detail as follows:
  • M 0 [ ⁇ E(r p 0 , (K DES I (A I B I H(M))))
  • E( K DES , E B (M)) ⁇ Q
  • Q ⁇ E( K% 0 , (K DES
  • A adds "A
  • Q represents the header and message body up to but not including the double signature.
  • This example envisions an RSA-type full message recovery signature process, whereby the signature verification step returns the original and complete values of H(M)
  • the PO 240 After verifying both A's signature and B's receipt, the PO 240 opens the header and obtains the inner values, which include most or all the information it would have gotten from opening M 0 under the Micali system.
  • the PO 240 checks the ID's of A and B, and retrieves H(M) which is the hash of the inner message which it has not received. However, it can check this H(M) against the one that it has recovered by verifying A ' s signature block, which provides adequate comfort to the PO 240 that A really did send the message that B is seeking to recover. After making these two checks, the PO 240 is ready to allow B to recover the message (which is still in B's possession) and the PO 240 does this by sending E B ( K DES
  • the EEM protocol of the present invention would include various methods to easily link all message components, including the placement of sequence numbers, record ID types (e.g., object identifiers), date-time stamps, and random number values in all related message components, as will be apparent and is well known to those skilled in the relevant art(s).
  • All users of system architecture 200 are equipped with public-private key pairs and certificates, and sign all protocol messages that they originate. Certificates to enable verification of these signatures are either sent along with the messages, or made available via a readily accessible directory service. Where needed, unique names or ID's would be provided for all system architecture 200 participants.
  • Each message and signature may also contain or refer to a policy-ID that contains or points to a legal policy or rule that governs the use or interpretation of that message or component.
  • This enhancement of the present invention has the further advantage that the PO 240 never possesses any form of the inner message. M. which may further limit its risks of legal liability to either party for accidental disclosure of M.
  • the PO 240 still receives the identities of A and B, which expose it to possibly unwanted "traffic analysis” data about its clients.
  • the PO 240 need not receive nor store the M 0 , which may be very large, and the double or multi-condition layer concept is preserved so that the PO 240 cannot read M without the active participation of B.
  • the private decryption key of B is also required, thus minimizing the PO's potential liability for improper disclosure of M as in the basic Micali protocol. Certain new elements have been added to this embodiment of the protocol, as shown in Table 5.
  • the signature of A, S A , over M 0 is enhanced to include signature attributes, which are delivered along with the signature block, containing separate hash values for: (1) H(M) - placing the hash of the inner content, M, into the signature links A to M in the eyes of both B and the PO 240; (2) H(Q) - A signs over the entire message; and (3) H( HDR P0 ) - A signs the PO header separately, to enable compact recovery, so that it is enough to send to the PO HDRp 0 and S A , without having to send the much larger M B . If the PO header is not signed separately it cannot be detached from M 0 and sent to the PO 240, as the PO 240 cannot verify it separately from M 0 . Second, B's header, HDR B , along with K DES2 , also includes H(M) and
  • H(K DES1 ) further links B's header to the content to which B receives access when he signs and returns the receipt.
  • H(K DES1 ) helps to inform B whether A (or PO) has sent him the correct second access key, and its presence in the header, signed over by A within Q, constitutes a representation by A that a symmetric key hashable to that value will be provided, breach of which will cause B's receipt to become legally void.
  • an "Info" element has been specified at various points. This represents generic information that a competent protocol designer or programmer would consider useful for tracking messages, transactions, and their components, matching and reassembling separated components, creating or updating entries in the local databases of each participant, generating payment system messages and records of monetary payments and balances, reconciling each message component with any pre-existing entries, etc.
  • Information field includes, but are not limited to: (1) each participant's system or user generated message tracking sequence reference numbers; (2) the date and time of the last action, and any prior actions for the same message; (3) hash values or sequence numbers of any prior or related message components; (4) random numbers or other nonce values used to link components together; and (5) software and protocol version release numbers and related version data.
  • any symmetric cipher, other than the DES algorithm specified herein, suited to securely encrypting comparably sized blocks of information may be used with equal efficacy.
  • a key- agreement methodology such as Diffie-Hellman
  • a key agreement protocol such as the above-mentioned Diffie-Hellman (D-H) protocol which is well known in the relevant art(s)
  • D-H Diffie-Hellman
  • This embodiment permits both A and B to contribute random material to the symmetric key that will be used to encrypt M, the content.
  • This approach is preferred in a military or intelligence grade communication system because the recipient B may not trust A to wisely, competently, or honestly choose a highly random symmetric (e.g., DES) key.
  • DES highly random symmetric
  • a and B both pre-agree to use two system- wide values: (1) g ⁇ the base; and (2) P ⁇ the modulus, which should be a prime number. Then A and B both choose random numbers (x and y, respectively) and perform the steps outlined in Table 5.
  • D-H is used as the public key encryption method for the basic Micali protocol 100. This is illustrated in Table 6.
  • the D-H public key encryption scheme can also be used for the PO 240 encryption layer, in which case, the PO would generally be required to publish its D-H public key in its public key certificate to permit multiple entities to use the services of the PO 240 over a period of time.
  • D-H Differentiations of the D-H scheme exist, in which the parties may generate one or more sets of temporary intermediate public and private keys to minimize exposure of their long term keys, and preferably the output of the D-H function is also passed through a hash function (keyed or unkeyed) to avoid any direct use of the actual D-H output material. In alternative embodiments, other "key agreement" protocols may be used. D-H, however, is the best known. An embodiment that employs D-H will be suitable for military and national security users, where B typically desires to participate with A in generating K DES , to assure a high quality key.
  • PO assures B it is okay to sign the receipt R without fear of cheating or non- performance by A, and the requirement of further access by B assures B that only he can read the inner message M in any event.
  • similar results can be achieved using a threshold cryptosystem in which any two of three parties can act together to gain access to the inner message M.
  • a and B can together grant access to B in the normal case, and in the recovery case, the PO 240 can act together with B to grant B access to M.
  • Party A should utilize an encryption scheme that can allow "2-of-3" access by A, B, and the PO to decrypt the inner message. This may require that the three parties initially generate a temporary master public key for any given message (or sequence of messages involving these three parties) that can be accessed by any two of their three private keys (which may be temporary or long term). Also, it will be desirable to select a threshold scheme that permits each party to perform their part of the "access" computation separately, forwarding their partial results on to the next party for completion.
  • each party may also be possible to utilize a threshold computer system in which each party generates a public-private key pair, and then (in this case) the three ("little") public keys are combined, to produce a master public key that can encrypt data where two of the three participants may act together to decrypt the data.
  • A to send a message, A generates a symmetric message encryption key, typically a random number K DES , uses K DES to encrypt the inner message M, and then wraps K DES using the 2-of-3 master public key K + 3 .
  • K DES a symmetric message encryption key
  • K DES uses K DES to encrypt the inner message M
  • K DES uses K DES to encrypt the inner message M
  • K + 3 the recovery information "A
  • this method will be combined with the "eliminate full resend" embodiment described above in Section III.B. However, it is shown in a simplified form, with a full send of M 0 to the PO, to reduce the complexity of the protocol and make it easier to see the use of the threshold enhancement.
  • A might separately encrypt both KK and the PO header using the same scheme, thereby requiring B ' s involvement for the PO 240 to access the PO header. This would strengthen B ' s control over the recovery process.
  • A can encrypt both M B and the PO header using the shared master public key K 3 ⁇ such that the participation of at least two parties (of A, B, and C) is required to access both M B and the PO header. Access to the PO header is not required unless B requests recovery by the PO 240. If B requires assistance from the PO 240 to recover the message, he sends R and the PO header to the PO 240, along with his own partial decryption of the PO header access point, PD B (analogous to the quantity PD A in the prior example). The PO 240 then performs a final decryption of PD B to recover the symmetric (e.g., DES) key giving access to the PO header.
  • symmetric e.g., DES
  • the present invention with an "invisible" PO 240, provides a convenient method for A and B to exchange a message, with A getting strong proof of receipt from B, and B getting strong assurance that he will get the message, without routine involvement by any third party.
  • B when recovery is desired by B, in the event of A's non-performance, it will be desirable for all system architecture 200 participants to have an unambiguous way to identify all the other possible participants, the role they will play, the services they will provide, for whom, the fees that will be billed and paid, and who will be liable for any damages in the event of non-performance or system failures.
  • B prior to signing the receipt, B will want to know that the PO 240 selected by A in fact stands ready to provide reliable recovery service to B if requested, at a reasonable price.
  • the PO 240 may be chosen by either A or B.
  • A might prefer a PO 240 that charges a lower fee for a recovery that would be billed to her, or one located in the same country as her and subject to the same national laws.
  • B may prefer a PO 240 he deemed more reliable, in the event he needed to look to it for recovery, or possibly a cheaper one, if he would be required to pay the recovery fee himself.
  • a initiated a given message using the key of a given PO where that PO 240 required either A or B to be a member to receive recovery services, then each needs to know that the other is in fact a member of the particular PO 240 chosen.
  • the PO 240 choice may be imposed by a third party, such as the employer of A or B, or a PO 240 might refuse service to some class of users or messages.
  • a third party such as the employer of A or B
  • a PO 240 might refuse service to some class of users or messages.
  • the system may be a closed system, such that the PO 240 cannot recover messages unless one or both of the parties are employees, agents, customers, or suppliers of that company, and their certificates clearly evidence that relationship (e.g., the user's e-mail addresses must belong to the same domain name as the company PO).
  • the present invention allows multiple recipients and/or senders of the same message, which may further enhance the basic Micali protocol 100.
  • the recipient's name inside and outside of the initial message M 0 can be enhanced to contain a list of several possible recipients [B,, B 2 ... B N ], any or all of whom can sign a receipt R and individually complete the protocol with sender A, and/or request and receive recovery services from the PO 240. This may be expressed in notational form as:
  • M 0 E PO ( A
  • each B x decodes and reads the message M.
  • each such header will normally be encrypted using B + x , the public key of B x and will contain the same partial DES key.
  • each header may contain a different partial DES key in which case, A must retain the matching partial DES key to be sent to recipient, and place each separate partial DES key into the PO header, associated with the name and ID data of each B x .
  • A may also create multi-way key splits that would require two or more recipients to combine their partial DES keys and act in concert to access the message M. 2.
  • a message could also be originated by a group of senders, A,, A 2 ... A N , such that each one represents to B that she can complete the protocol and deliver E B (M) to
  • A's might designate one A x as the lead A x to complete the protocol by sending a copy of E B (M).
  • M B E B
  • parties i.e., users at sites 206) using the architecture 200 may wish to specify more than one PO 240 that can perform the recovery service, should it become necessary.
  • party B might indicate to party A that he desires A to utilize both a primary and backup PO 240, if the need should arise.
  • A might choose one PO 240 and B another.
  • B might select one that operates using his preferred language and Jurisdiction's laws, whereas A might specify one that she believes offers a more reliable service, and hence is less likely to create a service problem that could reflect badly on A.
  • a and/or B have made an appropriate selection of 2 (or more) POs, A can proceed as usual to construct M 0 , except A will create as many additional PO headers as needed, each one encrypted using the public key K + P0 of its respective PO 240, and identifying the PO name in readable external form, and containing the recovery information needed by that PO 240.
  • Party A may, if needed, form each PO header using a different version release number and PO header data format of the EEM protocol, as each PO 240 may specify in its public key certificate the EEM version it is currently capable of processing.
  • each separate installment can be handled, signed for, and (potentially) recovered as a separate M 0 with a message M-of-N indicator preferably both inside and outside the outer encryption layer of M 0 for tracking purposes.
  • B would then sign a separate receipt R for each message, and would receive a separate send from A of either the inner message
  • M B (as in the basic Micali protocol) or the key or key share which allows B to access the message (in the enhanced versions of the present invention). It may also be desirable to place a hash value of the prior message in each successive message, or a cumulative hash value of all the messages sent so far.
  • the EEM protocol may be modified such that B only needs to sign one receipt for all the files in a large related series of transmissions. This may be preferred by B, who would rather not sign for anything until assured that he will in fact receive the entire shipment (i.e., all components).
  • A might encrypt the entire shipment of messages with a single access key (or key split), and upon receiving B's single receipt, send to B a single message containing the access key (or key split) that grants to B access to read the message.
  • proof-of-decryption (POD) and post-on-send (POS) embodiments described in Section VI below may be further enhanced in accordance with this embodiment so that they are configured to work with either a single setup and fulfillment of each respective protocol for the entire transmission of related messages, or a separate setup and fulfillment of each respective protocol for each individual message within the series.
  • POD proof-of-decryption
  • POS post-on-send
  • an “agent” can be any entity selected by the primary parties (i.e., users A and B), and that are also connected to the same communications network. Generally, these agent entities will be “trusted” in the sense that they will be subject to contractual (or other legal) obligations to perform. Thus, in the case of nonperformance, these entities will be subject to financial or other legal remedies for breach, improper disclosure of confidential information, etc.
  • an "agent” process “C” is created on the mail server used by user A, to allow A to appoint C as her agent.
  • M the information needed to complete the protocol in her absence
  • B the information needed to send his receipt to C.
  • M her plaintext message
  • at least four embodiments may be distinguished.
  • A sends M 0 to B and B's message (E B (M)), to C, as shown in FIG. 3A.
  • C may just intervene directly to receive the receipt from A's mailbox and complete the protocol, where C is a process running on A ' s mail server which has access to her account, or C may be named in either the message header or in A's certificate as A's "protocol completion agent.”
  • user A may construct and send both M 0 and E B (M) to C, and have C send M 0 on to B.
  • user A may merely send E B (M) to C, specifying which PO 240 to use, and let the PO 240 construct and send the M 0 .
  • user A could send the unencrypted inner message M to agent C.
  • an "agent" process “D” is created on the mail server used by user B in order to allow B to appoint an agent.
  • D can sign and return the receipt on his behalf, and then receive and hold the inner message when it arrives. Further, if the inner message fails to arrive during a pre-defined time, D may also apply automatically to the PO 240 for recovery of the message for which it has signed.
  • B may convey to A information about his delegation of authority to D.
  • B may issue to D an authorization or delegation certificate formally delegating to D authority to sign receipts on B's behalf.
  • This may take the form of a user-issued attribute certificate, signed by B, naming D as the subject, and including possibly D's public key, a hash of D's public key, or the CA name and serial number on D's public key certificate that will be used for signing and verifying receipts. It may also contain an attribute calling out "EEM
  • Receipts as a class of transactions for which authority is being conferred, and also possibly including an expiration date, and referencing an external document containing a text of all or part of the EEM system 200 rules agreement, and/or any other legal understanding between B, D, (and A).
  • user issued digital certificates are difficult to manage, because the user who grants or delegates may not have enough information (e.g., about some compromise of the agent) or technical capability to effectively revoke them when required.
  • the attribute certificate conferring authority on D will be issued by B's CA (or possibly D's CA, or any other CA selected by the parties), and will contain a representation satisfactory to A that B's consent for D to act on his behalf is on file (and of course that B retains the power to revoke that consent if desired).
  • B may cause its C A to issue (or reissue) B ' s base public key certificate with an extension naming D and stating that D will have authority to sign receipts for B.
  • This extension may contain any or all of the elements of the user-issued attribute certificate described above. It may also contain D's public key D ⁇ , so that A will not need to search for it.
  • D's authority to sign may be listed in a database or directory, publicly accessible using a secure protocol, where A (or C) may look it up when needed. This is similar to the standard practice for corporate authorities in England, where a similar database would merely be hosted on a Web server. It would not involve the creation, issuance, management, or revocation of any authority certificates.
  • a sender A may not wish to complete the protocol, either herself or via a proxy agent (C).
  • A may place a flag in the message M 0 telling B that B's only recourse will be to recover from the designated PO 240.
  • A signals B to recover from the PO 240 by default.
  • B will receive M 0 , read this signal flag, and send the message plus his receipt R to the PO 240, which will (in effect) play the role of A's proxy agent to complete A's duties in the transaction.
  • the PO 240 will verify with the proper parties that M 0 is properly formed and authorized and that R is a valid receipt signed by B or his agent. Then, the
  • PO 240 will (1) send E B (M) (or the recovery data, from another variant) back to B, and (2) either forward B's receipt R to A, or hold it for A to pick up.
  • A may simultaneously signal her intent to accept the recovery charges charged by the PO 240, if any, (i.e., "bill sender"), since she is forcing B to utilize the recovery center (the PO 240) involuntarily.
  • This embodiment may be the preferred approach when A is using an undesirable end-user PC and has no sender proxy agent (e.g., C) of its own. If A expects to use this model repetitively, the PO 240 may give A a bulk discount on the recovery charges.
  • the present invention making use of the PO complex 240, is readily extensible by defining inner and outer vectors using a sequence of attributes.
  • S-MIME Secure Multipurpose Internet Mail Extensions
  • IETF Internet Engineering Task Force ' s
  • CMS CMS protocols
  • these elements can also be placed in the signature blocks of the inner and outer envelopes.
  • sequence of attributes allows the EEM protocol to ensure that all participants (i.e., system 200 users) have a high degree of confidence and make electronic commerce as secure and trustworthy as traditional commerce.
  • the EEM protocol and EEM architecture 200 of the present invention address these concerns.
  • identifying the PO 240 in the outer vector and providing access to the certificate of the PO 240 and by defining an "is-cem-po" extension in the PO's certificate to allow major certificate authorities (CA's) to certify them, user B is assured that the PO 240 is a valid post office complex that will actually deliver the inner message.
  • CA's are well known in the relevant arts(s).
  • a particular certificate authority is an entity (i.e., a service provider) that issues digital certificates to other entities (organizations or individuals) to allow them to prove their identity to others.
  • a certificate authority might be a separate company that offers digital certificate services to the public or an internal organization such as a management information systems department within a larger enterprise.
  • the participants of the EEM system 200 must agree (e.g., via a EEM System 200 Subscriber Rules Agreement) that the recipient's receipt is not valid or binding if the PO 240 declared by user A in the outer vector cannot actually recover the message, does not exists, etc., or if the inner vector does not match as to A, B, etc.
  • the PO complex 240 may allow L to be multi-valued so that a message written in several languages (e.g.. a bi-lingual contract) may be sent.
  • the intended recipient B may be unwilling to sign a receipt for an electronic mail message under the EEM system described herein unless provided with a representation by A that the message is in a known language and/or data format that B can properly inte ⁇ ret. B may be unwilling to provide A with a receipt, which A can use to hold B responsible for having read the content, unless he is assured, for example, that the document is in, for example, English (US), and in, for example, Microsoft Word 97 Format.
  • IETF-CMS formats it could be contained in a signature attribute within A's signature block over the outer envelope.
  • the system rules agreement will preferably provide that A is bound to honor this promise, and B's receipt R is not valid against B if A has breached this representation as to language and format.
  • This language/format attribute may also be replicated in the "Info" fields inside M 0 and possibly within the receipt R, etc.
  • A may wish to ascertain what languages and formats are acceptable to B prior to sending M 0 .
  • B may place one or more attributes or extensions in his public key certificate, or may publish such information in a directory that is accessible to A.
  • the PO may wish to require A to state (or declare, or legally represent) the monetary value of the message M, inter alia to place a cap on the PO's liability in the event of failure by the PO to perform the recovery operation.
  • Party A may also wish to state a time limit, "deadline,” or “stale date,” after which she will no longer be liable for non-performance of an underlying obligation to deliver M to B.
  • the monetary value field must be placed in the "Info" vector inside the PO layer of M 0 , and should also preferably be repeated inside B's message M B , so B can confirm that what was decrypted by the PO 240 matches what A represented.
  • the PO 240 may charge A and/or B a higher fee to cover the PO 240 's added insurance costs for higher value messages, and risk of non-performance in view of a shorter deadline for final delivery.
  • Such higher fees should preferably be billed on a per-message basis, rather than a per recovery basis, to better reflect the PO's true outstanding exposure to such potential liabilities.
  • the PO 240 may wish to control which parties can expose it to such liabilities, especially to assure itself that such parties have access to more reliable communications facilities, so the PO 240 need not assume the risk of failures by communications providers over which it has no control.
  • Party A the sender, will be concerned with the quality of the receipt to be received from party B, the intended recipient, prior to handing over (or granting conditional access to) the inner message M B .
  • Party B may have many different e-mail accounts and public key certificates.
  • party A will have selected one (or more) specific public key certificates and utilized the certified public encryption keys contained therein to construct M B and M 0 .
  • One (default) policy is to require that the receipt R be signed using a private key of B whose digital signatures are verifiable using a public signature verification key contained within one of the certificates initially selected by A.
  • Current secure electronic mail systems such as NetDoxTM , generally require that each party have the other party's exact certificate prior to initiating any communication.
  • This policy of requiring in advance the exact certificate of B will become burdensome as system use grows and as users demand increased flexibility.
  • party B decides to use a proxy agent D to sign for him, then the quality of D's signature on the receipt must be addressed.
  • party A may send one or more electronic instructions to proxy C regarding: ( 1 ) the type of certificate C may accept from B; (2) ancillary actions to be performed by C; and (3) quality of delegation of authority that C may accept in cases where B may have delegated his receipt-signing authority such as to his proxy agent D.
  • party A may send messages to C relating to the type of certificate that C may accept as constituting a signature of B on the receipt R. For example, A may specify one or more of the following rules:
  • B's CA be located in a given geographic area (nation or region)
  • party A may send messages to C relating to ancillary actions to be performed by C on A's behalf.
  • A may send C electronic instructions directing C to perform one or more of the following actions:
  • party A may send messages to C relating to quality of delegation of authority to sign receipt R granted from B to D that will be acceptable to A.
  • A will be concerned that B must not be in a position to legally deny or disavow the receipt R signed by D.
  • A may send electronic instructions to C directing C to apply one or more of the following rules: -Disallow delegation and require exact match to B's certificate (default)
  • D is certified by B's employer or B's bank
  • D created a separate and unique key pair and certificate, certified properly by B's CA, for the sole purpose of signing receipts on B's behalf.
  • B must instead be signed by an entity that pledges adequate security or collateral to cover any loss that may be sustained by A in the event B successfully disavows a receipt signed by D.
  • S A may entirely control the profile of instructions given to C on A's behalf, may specify some things and leave others for A to specify, or may specify, with regard to any given parameter, certain ranges of options that can be selected by A.
  • B may send an electronic instruction to D instructing D not to sign receipts or acknowledgments for messages that appear to have been sent by: -Specific named senders, or a list of persons or organizations, specified by B
  • B may also send an electronic instruction to D instructing D not to sign receipts or acknowledgments for messages where:
  • S B The above requirements placed on D's activities can also be specified in whole or in part by a system administrator S B . empowered by B ' s employer or other organizational sponsor, who may alter or override similar instructions from B. S B may entirely control the profile of instructions given to D on B's behalf, or may specify some things, and leave others for B to specify, or may specify, with regard to any given parameter, certain ranges of options that can be selected by B.
  • the PO 240 cannot know how many messages have been sent at any given time, or their value, or even whether they were ever completed, in cases where B either never received the message, declines to sign the receipt, or declines after signing the receipt and not getting M B from A, and for some reason does not bother to request recovery.
  • the proxy server can, for example, impose usage charges one or more of the following ways:
  • the charges assessed by the proxy can be billed to either the sender or recipient, or the sender or recipient's organizational sponsor or their department within the sponsor;
  • the financial account to be billed can be prepaid, accrued and invoiced, or can be billed to an outside electronic payment or billing service, such as a digital wire transfer, ACH debit, e-check, credit card, direct debit, digital coin, subscription, electronic scrip, or an invoice by proper mail service;
  • an outside electronic payment or billing service such as a digital wire transfer, ACH debit, e-check, credit card, direct debit, digital coin, subscription, electronic scrip, or an invoice by proper mail service;
  • the choice of the account to be billed can be fixed, or may vary depending on the identity of the sender, receiver, sender's sponsor, receiver's sponsor, sender ' s preferred PO, receiver's preferred PO, message size or type, message priority, level of insurance or other financial assurance requested or required;
  • the amounts to be billed to the designated account can be fixed per message, based on the declared value field (assuming it is readable or else separately stated by the sender), based on volume discounts, based on time of day or day of week discounts, or may vary depending on the type of quality of communications network used or to be used;
  • the users can be billed on a per use basis, with an optional monthly cap (to limit the size of the bill they can run up), or on a pre-paid subscription basis, where an amount is deducted from their financial account inside or (or associated with) the proxy agent server, for each use;
  • the amounts to be billed may reflect a discount for prepayment on a subscription basis, or may differ depending on which form of payment is used, and whether that payment is immediate, same day, several days later, or end of month plus 15 days (e.g., T+45 days).
  • the system may notify a "reviewing officer," which could be a human or artificial agent that is empowered to review such a request and approve or deny it.
  • several different accounts may be established, either inside the proxy agent server, or associated with it, to which fee payments are to be credited, and eventually settled and remitted.
  • Such accounts may be for the benefit of the operator of the proxy server, a sponsoring post office (if any) which accredits the proxy agent and may assume liability for its reliable and correct operation, a seller or licensor of software (for collecting pay-per-use fees) or a licensor of intellectual property rights (for collecting royalties), or for the user's sponsor or for the user themselves (for accruing refunds, credits, or loyalty points, such as frequent flyer miles, as a reward for using the system).
  • the proxy agent and its financial accounting system can also notify system users of available user-software upgrades, respond to requests for upgrades, and bill the price of those upgrades (if any) to the user's individual or organizational accounts, in accord with any applicable pricing plan that may be in effect with regard to that sponsoring organization.
  • the accounting capabilities of the proxy agent servers can be enhanced to include registers, counters, or accounts for recording such data as:
  • the sponsoring post office may issue an electronic instruction to the proxy agent requesting it to transmit the data it has collected to a centralized location for further collation, summarization, and processing to monitor and assess system use and performance characteristics and systemic risks.
  • Such data will not be deleted from the memory of the proxy agent, nor counters reset to zero for any given period, until the proxy agent receives a confirmation of successful receipt and decryption from the sponsoring post office or other system-wide authority that issued the request.
  • the proxy agent may be instructed to forward such information spontaneously to the sponsoring post office, or other system-wide authority, on a daily, weekly, monthly, quarterly, etc. basis.
  • FIGs. 5A and 5B a flow diagram 500 representing an EEM protocol according to an embodiment of the present invention is shown.
  • the EEM protocol is handled by the EEM system architecture 200 presented above. More specifically, FIGs.5A and 5B illustrate the Micali protocol as enhanced by the policy and billing signals discussed above in Sections V.A to V.E (i.e., an embodiment of the EEM protocol of the present invention) with respect to parties A and B at user sites 206a and 206b, respectively, and the PO 240.
  • the normal steps (i.e.. non-recovery) of the embodiment of the EEM protocol presented in FIGs. 5A and 5B is presented and summarized (with examples) in Table 3 below. In this embodiment, a different notation is utilized where M 0 is the cleartext and the M x 's are the larger constructs.
  • A may wish to receive an intermediate receipt R, from an intermediate party V (such as a value added network (VAN) or internal co ⁇ orate mail server), and also a final receipt R 2 from B, the ultimate recipient.
  • V value added network
  • A can form a nested version of M 0 that first requires a receipt from V, and once V gets access, V can forward an inner M 0 on to B, which will then require a second receipt signed by B prior to A completing the protocol with B.
  • V is a service provider under contract with A to provide prompt receipts according to a contract-specified service level.
  • party V will put A ' s message on the wire to B and mark the time of sending ajournal.
  • V because A already trusts V to return a proof of send receipt, it will often be sufficient for A's contract with V to specify that V will send A an ordinary receipt (signed or unsigned) upon receiving M 0 from A.
  • A may wish to receive an intermediate receipt R, from an intermediate party V (such as a value added network or internal co ⁇ orate mail server), but further direct that B send the final receipt R 2 to V.
  • V such as a value added network or internal co ⁇ orate mail server
  • A can form a nested version of M 0 that first requires a receipt from V, and once V gets access, V can forward an inner M 0 on to B, which will then require a second receipt signed by B prior to Vs completing the protocol with B.
  • V could re-wrap M B with someone (anyone) else as the sender.
  • V could recover his own fragment of the symmetric (DES) key. and then, although V could not read M B without also having B ' s symmetric key fragment. V could form a new EEM message encrypting his own former fragment in the new header under another party ' s public encryption key. thereby redirecting the protocol completion steps to that other party, perhaps subverting A's intent that V serve as the protocol completion party.
  • DES symmetric symmetric
  • V can simply reapply the EEM protocol when forwarding to B a message received from A.
  • A can enhance M 0 to include a request for payment, which B may be required or permitted to remit back to A in the receipt R.
  • A may state that A's completion of the exchange protocol is conditioned on prior receipt by A of monetary payment or credit (or other exchange of value or rights) by a means acceptable to A.
  • an optional unencrypted (visible) attribute or extension is added to signal B that payment is required, along with the amount and other remittance instructions, such as the payment technology (e.g., digital cash mechanism), and A's bank number and account number, or the like.
  • This "COD Extension” should appear outside the outer (PO) envelope, but within the scope of A's external signature over the outer envelope, preferably for current secure mail systems as a signature attribute to A's external signature. Where a split key scheme is used, there is no "outer envelope” as such, because there is only one envelope requiring two keys to open.
  • B If B does not wish to make the requested payment, he is advised to reject M 0 without signing the receipt or return a negative (“DECLINE") receipt with the reason of "declined to accept COD charges.”
  • B's software system will request user confirmation and prompt B, showing the nature of the request and seeking B's authorization to initiate the payment instruction.
  • B can initiate the payment using any payment methodology (even mailing a paper check) and then reference A's M 0 message number and his own R B receipt serial number on that payment in the memo field. Such a memo reference will allow both A and B to reconcile their payment records with their messages and receipts. This approach is less desirable, as it may be unduly difficult to reconcile disconnected payments with receipts.
  • the EEM receipt may be modified to include a "payment memo" field, in which B, prior to signing the receipt, may include a payment system identifier and transaction reference number or optionally a hash value of the payment message.
  • B prior to signing the receipt
  • the receipt provides information to facilitate automated linkage and reconciliation with the statements and/or remittance advices of the payment system.
  • it may be possible to directly integrate B's payment into the receipt R, thereby providing the highest degree of binding between the two related acts of performance by B (B's signed receipt and B's payment).
  • a "payment transmittal" extension may be provided to B's receipt message R, which will identify the payment system type and further contain the actual digital payment, valid for redemption by or credit to A, generated by or on behalf of B under the rules and procedures of that payment system.
  • DigiCashTM offered in the US by Mark Twain Bank (discontinued in September of 1998), provides a digital payment token that emulates a coin of fixed value, redeemable by A. CyberCashTM, an independent payment service located in Reston. VA. provides a payment message telling the recipient (usually a merchant who also subscribes to the CyberCash system) that CyberCash will credit his account with the funds.
  • GC TechTM an unreleased payment system designed by a French firm, provides B with a payment advice he can send to A, which is signed by a bank (or an agent of a bank), advising A that she will receive payment in good funds into her account (as designated her the "COD Extension” field within M 0 ) at a time certain, usually next business day.
  • Electronic Monetary System (EMSTM), proposed by Citibank, NA of New York, provides a form of digital message which emulates a piece of currency, and which can be sent by A's digital wallet and received and redeemed by
  • SETTM Secure Electronic Transactions
  • MondexTM a global electronic cash system sponsored by Mondex International, provides a message signed by B's payment smart card that will be accepted by A's smart card a proof that the desired funds have been debited from B's account (the balance of which is maintained on B's card), and may be redeemed by A upon transmission of a redemption request message from A's smart card to A's participating bank.
  • Financial EDITM a general methodology for creating and processing financial payment and advice messages, provides a payment advice message, called an "820" transaction, which when signed by B, may assure A that B has or will make the payment as described in the 820, and if signed by B's bank, would provide further assurance that said payment will occur in due course.
  • the COD payment extension field may contain information that must be encrypted prior to transmission from B to A, either to protect the confidentiality of the parties (e.g., as to transaction description), or to preserve the security and integrity of the payment system.
  • B may obtain the public encryption key of A and use it to protect any such information, prior to forming the receipt R and transmitting it to A.
  • the EEM protocol need not, and probably should not, make any alterations to the primary payment message (or value message) as specified and generated by the payment system used.
  • B's software will copy those value messages verbatim into the payload section of the "COD Payment" extension in the receipt R, possibly with the addition by B of an overlying layer of encryption readily removable by A.
  • A After A removes such encryption, if any, and extracts the value message from the COD payment extension, A will further process said value message (as or if required) and submit it to his bank or other payment service provider for conversion into good funds. Some payment systems may require or permit other messages between B and A in addition to those described above.
  • B ' s EEM user software may provide a function allowing B's payment software to request information regarding the transaction for which payment is being requested, including at least the transaction description and A's message reference number(s) present within M 0 .
  • the EEM user software can pre-generate the receipt ID numbers that it plans to use in the receipt that will be returned to A and that will contain the payment or value message. Based on this information, the payment software can place such transaction data and message reference numbers into the memo field of the payment or value message, form the rest of the value message, apply the appropriate digital signature, and then convey the entire value message (now containing the transaction data) to the EEM user software to be integrated with the receipt R.
  • multi-step (complex) transaction support may be provided by combining (1) receipt of transaction 1 with initial send of transaction 2 and/or (2) receipt of transaction 2 with fulfillment of transaction 1.
  • R B ⁇ S B ( H(M X )
  • H(M Y ) is embedded within the region signed by B, but the entire message M ⁇ , which could be quite large, is not itself embedded, but rather is appended, or perhaps transmitted via other means. This can keep the receipt RB small enough to be readily stored in a commercial database system. In this case, it is preferable to embed an appropriate "external attachment" extension in the receipt, that provides transaction or message reference numbers, to help the recipient (i.e.. A) associate H(M Y ) with M ⁇ .
  • This enhancement can achieve two related objectives: (a) to provide proof to A that B has decrypted the message M B ; and (b) to link this proof to the original M 0 message header, so that such proof can also be furnished to the PO, or (c) in another embodiment, to provide this "has-read” proof to any predetermined party.
  • Table 11 shows how this feature can be integrated into the basic Micali protocol 100.
  • this POD feature can be incorporated into any of the EEM protocol embodiments presented herein.
  • B cannot be required to decrypt M B , to send back Z, or to examine or use M, but this mechanism may be provided to allow B to assure A that decryption has taken place, and make it easy for A and the PO to verify this fact.
  • A can form M 0 in a manner that directs B to send the POD to another party.
  • A does this by naming the third party (TP) and including a copy of (or a pointer to) TP's public encryption key, and providing an encapsulation of Z in a form that is verifiable only by TP.
  • TP third party
  • Table 12 shows how this feature can be integrated into the Micali protocol 100.
  • Info field is included as a generic concept, as used elsewhere within this document. It will typically contain such data elements as sender and receiver transaction and message ID numbers, date-time fields showing time of transmission or reception, hash values of various protocol elements for matching, and other system administrative control fields, such as billing information, as described in Section V above.
  • the proof of delivery (POD) embodiment described above can be combined with a "post on send” (POS) feature to produce a service level similar to "registered mail" as historically offered by the United States Postal Service.
  • POS post on send
  • registered mail also undertakes to track the entire process, and is used especially when the message may contain irreplaceable items of high intrinsic value, such as currency, negotiable securities, precious metals, etc.
  • the POS and POD tracking messages may be sent and received by a third party monitor service, which could be the PO 240, or A's proxy, even though the original message is never sent to the third party monitor service.
  • a third party monitor service which could be the PO 240, or A's proxy, even though the original message is never sent to the third party monitor service.
  • Table 13 shows the Micali protocol 100 as enhanced by both the POS and POD methods of the present invention. To facilitate comprehension, the new POS/POD material is shown in boldface.
  • the "Info" field will contain the time of each prior action, which will be of interest to A, especially the declared time of A's send, the time TP 0 was received by TP, the declared time of B's processing of M 0 , and the time TP 2 was received by TP. Because A's sending of TP 0 to TP occurs after A's sending of M 0 to B, TP 0 may be enhanced to attach or include any proof-of-sending receipt that A may have received from a "value added network provider" (VAN) or mailroom. Alternatively, A may send both M 0 and TP 0 to his mailroom simultaneously.
  • VAN value added network provider
  • TTP trusted third party
  • a time stamp service unrelated to the subject party, which will reliably affix the correct time, digitally sign the result (or secure it by other cryptographic means) and return the signed message.
  • TTP may be called a "heavy weight,” because it interposes its costs and delays on every message.
  • a time stamp service is described in detail in S. Haber and W.S. Stornetta, How to Time-Stamp a Digital Document, Advances in
  • EDI electronic data interchange
  • this party is called a "heavy weight" because it must stand between the two actual parties in each and every case, thereby imposing delays due to communications overhead, the inevitable high costs of running the
  • VAN as a separate business or legal organization
  • potential bottlenecks due to single points of failure or insufficient capacity to handle peak traffic etc.
  • heavy weight parties may typically exert an undue political influence over the structure of the industry, and gain access to large amounts of sensitive commercial data content and traffic analysis information.
  • TTP trusted third party
  • a trusted third party might be housed in a different part of the same organization, provided that the service was fully independent and separated by legal and procedural "firewalls" to prevent improper influence on the service's integrity.
  • the interposition of such an independent TTP in each transaction may be preferable.
  • each completed transaction may typically comprise a "set" of several related messages (the parts of which may often overlap with the parts of other message sets, then it will be preferable to stop sending every message to the heavy weight TTP for purposes of time stamping, because in accordance with the present invention the parties can achieve commercially adequate proof of date-time without the physical, economic, or political overhead it may impose.
  • the present invention contemplates the following new methodology, which uses an "invisible" arbitrator who is only called by the parties in case of a dispute, similar to the post office in the Micali protocol 100. For purposes herein, it will be referred to as a Time Arbitration Office (TAO).
  • TEO Time Arbitration Office
  • TAO may often also be an EEM PO 240, but the technical processes are different, and are invoked at different times, and hence must be considered separately.
  • the method can also work when at least one party to a given transaction or message is doing a high volume of traffic with other parties, even if the other party is not, because in this case, the TAO can rely principally on the evidence it gets from the high volume party (HVP), and especially the HVP's trading partners, despite the paucity of usable data from the low volume party (LVP) or its other trading partners.
  • HVP high volume party
  • LVP low volume party
  • A-* B M 0 ⁇ initial EM message send
  • Each party will have: ( 1 ) A system- wide unique party ID number; (2) their own transaction sequence number for the entire transaction; and (3) their own message sequence number for each message within a given transaction.
  • system- wide unique party ID numbers are:
  • TXN 20901 and that A and B each maintains their own unique sequence counter for all transactions in accordance with which they designate this transaction (TXN) as:
  • Parties A and B assign each message of this EEM transaction their own sequence number (1, 2, 3, etc.) for message numbers within this transaction.
  • each one will include both its own reference number for that message step, and the other party's message number from the prior step.
  • each party Upon receiving the first message of a new transaction, each party will utilize its own “next" sequence number for the entire transaction, and record the other party's transaction sequence (TSN) number for reference.
  • TSN transaction sequence
  • Each party will record all messages sent and received in a journal, such as a computer database, indexed at least by the unique TSN they have assigned, and each message entry will also contain the other party's TSN.
  • a journal such as a computer database
  • each party has a well managed and secure commercial data processing system with adequate fault-tolerant backup and recovery systems. That means each party will in all cases possess the physical data records contemplated by the present invention.
  • each party will insert a cryptographic checksum (or "hash") value derived from the prior message (in the same transaction sequence) into each subsequent message in that sequence, and each party will (in accordance with an embodiment of the EEM protocol) digitally sign each message they send, and store the digital signature of the counter-party from each message they receive.
  • a cryptographic checksum or "hash”
  • additional hash values which represent the cumulative hash value (the secure hash-chain concept of Haber and Stornetta) from the sequences of messages originated by only that party (only sent), or preferably both parties to that specific transaction (both sent and received), and/or, more importantly, all parties with which party X was exchanging other messages while waiting for all messages of the subject transaction to be completed.
  • the Haber-Stornetta "chaining" method may add assurance, it is not required, for an equivalent result can be achieved by simply including in each message sent (and digitally signed by its sender) the prior (non- chained) hash value from each
  • each party will maintain a journal of every transaction (both sent and received), in the following database format:
  • the database for each party i.e., A, B, C, and D
  • the database for each party now contains the entries shown in Table 17, Table 18, Table 19, and Table 20, respectively.
  • the sender A that initiates a the first message of transaction set cannot know the intended recipient B's "next" transaction set number in advance, but A can derive it from B's return message and write it back to A's database record of A's initial message, if desired.
  • the hash values assigned are intended as arbitrary unique values, such as cryptographic message digests. However, for clarity they have been numbered to align with the time interval in which they occur, to make them unique yet understandable within this example.
  • the variable in_time_ref_blk is the my_time_ref_blk received ("in") from the counter-party, which was taken from the counter-party's immediate (absolute) preceding journal entry, which contains the 8 fields from whatever message the counter-party was sending or receiving, to or from whomever, just prior to the subject message.
  • the letter in parenthesis following the in_time_ref_blk, e.g., "(A)" provides an informative reference to the ID of the counter-party's "prior counter-party" which is referenced in the in_time_ref_blk.
  • the parties will be concerned about the confidentiality of the data contained in the reference time blocks which they send to one trading partner, which contain identity and traffic analysis data about their dealings with other unrelated parties.
  • the TAO will provide a public key K ⁇ TAO to all system participants, which they may use to encrypt the reference time blocks they send. This will keep the recipients from reading the confidential traffic analysis data in the reference time blocks, while allowing the TAO to read them, when it is called upon to arbitrate.
  • each time any party receives (but not sends) a message they will receive a reference time block, in_ref_time_blk.
  • These time blocks which contain data about other contemporaneous transactions with unrelated parties, can be requested by the TAO in the event of any dispute among the parties, and upon being decrypted using the TAO's private decryption key, can allow the TAO to establish with certainty the relative time sequence of any given transaction, with reference to the interleaved transactions of the disputing parties with all their other unrelated counter-parties.
  • the TAO system rules will provide a standard format to be followed, so that the record will not be null.
  • the starting party will be instructed by the TAO to initiate a "first" transaction with an external time reference service (TRS) to acquire a starting record that contains an absolute time reference, and that record's data can then be used to form an appropriate reference time block for their first business message send.
  • TRS external time reference service
  • the participants and the TAO may generate and send to one another heartbeat messages to help keep the system full of unique messages.
  • the parties may send such messages to their nearest counterparts, or the TAO may send them to the parties.
  • the TAO might send a message to each subscribing party.
  • such a message might contain an instruction to the recipient party telling it to send another heartbeat message to another party selected by the TAO, which may not be a party that the recipient normally trades with, to help improve that party's saturation level.
  • the TAO's instruction might direct the recipient to initiate a cascade of messages.
  • the TAO might direct A to send further heartbeat messages to a definite or descriptive list of other system participants, such as "B, C, D and E" or "all known participants whose names begin with the letter B.”
  • the TAO's instruction to A could contain a further embedded instruction, to be passed on by
  • each recipient of the cascade from A might be further directed to send a cascade to yet other participants, such as "two other participants chosen by algorithm from a random number to be generated by the recipient.”
  • Such a heartbeat cascade process must be carefully controlled to prevent it from flooding the system with excessive messages and degrading performance.
  • the TAO will provide all participants with a list of network names and addresses of approved TRS providers, and will require such participants by contract to poll one or more of such TRS ' s at pre-determined time intervals.
  • Each participant may be assigned one or more primary TRS's, and be further directed to poll others on the list if their primary TRS is down or providing suspect data. It may be further desirable to require all participants to poll different available TRS's at random, to reduce the possibility of damage to system integrity if one TRS begins to malfunction and provide incorrect absolute time data.
  • the TAO and its system participants may specify the use of a Byzantine Agreement protocol, whereby participants may poll several TRS's simultaneously, and in the event of any discrepancies, whether from malfunction or sabotage, employ a suitable algorithm to determine which time value to enter into their respective journals.
  • Various parties can request or receive information to enable them to determine whether any given party's transaction flow has adequate saturation and temporal distribution to provide adequate assurance of proper date-time determination, at a future time, to the TAO and its other subscribers.
  • Parties may be required to periodically provide information summarizing the total numbers of transactions, sub-messages, counter-parties dealt with, and distribution over different time intervals.
  • the TAO can use this data to assess the party's adequacy of saturation, and the adequacy of their nearest partners and of the entire community, over various past, present, and future time frames.
  • the TAO can publish or provide this information to the parties or to other users, on request, or by subscription, or via publication.
  • DRO Lost Database
  • a neutral third party a Database Reconstruction Office or "DRO"
  • DRO Database Reconstruction Office
  • the essence of the present invention will be to combine the foregoing with a mechanism to continually refresh all party's databases with pertinent counter-party information, and to provide a method to perform complex multiparty trades (as are common in the world of global securities custody and settlement).
  • all messages may be sent over the open Internet with the benefit of EEM (proof of delivery), centerless time service, and self-updating "cc" lists, such that all the traditional functions of a VAN can be dispensed with, and replaced with a message transfer agent (MTA)- a EEM PO 240 combined with a TAO.
  • MTA message transfer agent
  • the present invention may be implemented using hardware, software or a combination thereof and may be implemented in a computer system or other processing system. In fact, in one embodiment, the invention is directed toward one or more computer systems capable of carrying out the functionality described herein.
  • An example of a computer system 600 is shown in FIG.6.
  • the computer system 600 includes one or more processors, such as processor 604.
  • the processor 604 is connected to a communication bus 606.
  • Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.
  • Computer system 600 also includes a main memory 608, preferably random access memory (RAM), and may also include a secondary memory 610.
  • main memory 608 preferably random access memory (RAM)
  • the secondary memory 610 may include, for example, a hard disk drive 612 and/or a removable storage drive 614, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc.
  • the removable storage drive 614 reads from and/or writes to a removable storage unit 618 in a well known manner.
  • Removable storage unit 618 represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 614.
  • the removable storage unit 618 includes a computer usable storage medium having stored therein computer software and/or data.
  • secondary memory 610 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 600. Such means may include, for example, a removable storage unit 622 and an interface 620.
  • Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 622 and interfaces 620 which allow software and data to be transferred from the removable storage unit 622 to computer system 600.
  • a program cartridge and cartridge interface such as that found in video game devices
  • a removable memory chip such as an EPROM, or PROM
  • PROM PROM
  • other removable storage units 622 and interfaces 620 which allow software and data to be transferred from the removable storage unit 622 to computer system 600.
  • Computer system 600 may also include a communications interface 624.
  • Communications interface 624 allows software and data to be transferred between computer system 600 and external devices. Examples of communications interface 624 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc.
  • Software and data transferred via communications interface 624 are in the form of signals 628 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 624. These signals 628 are provided to communications interface 624 via a communications path (i.e.. channel) 626.
  • This channel 626 carries signals 628 and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link and other communications channels.
  • computer program medium and “computer usable medium” are used to generally refer to media such as removable storage drive 614. a hard disk installed in hard disk drive 612, and signals 628. These computer program products are means for providing software to computer system 600. The invention is directed to such computer program products.
  • Computer programs are stored in main memory 608 and/or secondary memory 610. Computer programs may also be received via communications interface 624. Such computer programs, when executed, enable the computer system 600 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 604 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 600.
  • the software may be stored in a computer program product and loaded into computer system 600 using removable storage drive 614, hard drive 612 or communications interface 624.
  • the control logic when executed by the processor 604, causes the processor 604 to perform the functions of the invention as described herein.
  • the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs).
  • ASICs application specific integrated circuits
  • the invention is implemented using a combination of both hardware and software.

Landscapes

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

Abstract

L'invention concerne un procédé, un système et un produit de programme informatique destinés à assurer des services de courrier électronique renforcés tels que le courrier électronique certifié. Le procédé permet la reconstitution, par le destinataire, du message initial, l'élimination du renvoi intégral du message, la réduction de la communication pendant l'étape de récupération, l'élimination de la nécessité d'un cryptage supérieur, permet aux parties concernées de déléguer l'exécution à des agents (208a, 208n) et fournit des inscriptions systématiques explicites par des autorités de certification d'utilisateur. Le système comprend en outre une pluralité de sites utilisateurs et un complexe de bureau de poste central (240).
PCT/US1999/023453 1998-10-09 1999-10-08 Procede, systeme et produit de programme informatique pour des services de courrier electronique renforces WO2000022787A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU11052/00A AU1105200A (en) 1998-10-09 1999-10-08 Method, system, and computer program product for providing enhanced electronic mail services

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16893698A 1998-10-09 1998-10-09
US09/168,936 1998-10-09

Publications (2)

Publication Number Publication Date
WO2000022787A2 true WO2000022787A2 (fr) 2000-04-20
WO2000022787A3 WO2000022787A3 (fr) 2000-08-03

Family

ID=22613586

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/023453 WO2000022787A2 (fr) 1998-10-09 1999-10-08 Procede, systeme et produit de programme informatique pour des services de courrier electronique renforces

Country Status (2)

Country Link
AU (1) AU1105200A (fr)
WO (1) WO2000022787A2 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2394388A (en) * 2002-10-14 2004-04-21 Toshiba Res Europ Ltd Methods and systems for flexible delegation
US6766450B2 (en) 1995-10-24 2004-07-20 Corestreet, Ltd. Certificate revocation system
WO2006058419A1 (fr) * 2004-12-03 2006-06-08 Research In Motion Limited Procede et appareil permettant de gerer efficacement un fichier 'messages envoyes' et de renvoyer des messages depuis un dispositif de communication sans fil mobile
US7631043B2 (en) 2004-12-03 2009-12-08 Research In Motion Limited Method and apparatus for efficiently managing “messages sent” file and resending of messages from mobile wireless communication device
EP2750324A1 (fr) * 2012-12-27 2014-07-02 Gemalto SA Procédé permettant à un utilisateur de prouver la possession d'un document anonyme
DE112016004274B4 (de) 2015-09-22 2020-06-18 Google Llc Systeme und Verfahren zur Datenverlustvermeidung unter Wahrung von Vertraulichkeit
WO2022191887A1 (fr) * 2021-03-12 2022-09-15 Chetty Vijay Raghavan Système de distribution de contenu à plusieurs niveaux et son procédé

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4458109A (en) * 1982-02-05 1984-07-03 Siemens Corporation Method and apparatus providing registered mail features in an electronic communication system
US5481613A (en) * 1994-04-15 1996-01-02 Northern Telecom Limited Computer network cryptographic key distribution system
US5666420A (en) * 1995-03-21 1997-09-09 Micali; Silvio Simultaneous electronic transactions

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4458109A (en) * 1982-02-05 1984-07-03 Siemens Corporation Method and apparatus providing registered mail features in an electronic communication system
US5481613A (en) * 1994-04-15 1996-01-02 Northern Telecom Limited Computer network cryptographic key distribution system
US5666420A (en) * 1995-03-21 1997-09-09 Micali; Silvio Simultaneous electronic transactions

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6766450B2 (en) 1995-10-24 2004-07-20 Corestreet, Ltd. Certificate revocation system
GB2394388A (en) * 2002-10-14 2004-04-21 Toshiba Res Europ Ltd Methods and systems for flexible delegation
GB2394388B (en) * 2002-10-14 2005-10-19 Toshiba Res Europ Ltd Methods and systems for flexible delegation
WO2006058419A1 (fr) * 2004-12-03 2006-06-08 Research In Motion Limited Procede et appareil permettant de gerer efficacement un fichier 'messages envoyes' et de renvoyer des messages depuis un dispositif de communication sans fil mobile
US7631043B2 (en) 2004-12-03 2009-12-08 Research In Motion Limited Method and apparatus for efficiently managing “messages sent” file and resending of messages from mobile wireless communication device
US7930358B2 (en) 2004-12-03 2011-04-19 Research In Motion Limited Method and apparatus for efficiently managing “messages sent” file and resending of messages from mobile wireless communication device
EP2750324A1 (fr) * 2012-12-27 2014-07-02 Gemalto SA Procédé permettant à un utilisateur de prouver la possession d'un document anonyme
WO2014102277A1 (fr) * 2012-12-27 2014-07-03 Gemalto Sa Procédé permettant à un utilisateur de prouver son droit de propriété d'un document anonyme
DE112016004274B4 (de) 2015-09-22 2020-06-18 Google Llc Systeme und Verfahren zur Datenverlustvermeidung unter Wahrung von Vertraulichkeit
WO2022191887A1 (fr) * 2021-03-12 2022-09-15 Chetty Vijay Raghavan Système de distribution de contenu à plusieurs niveaux et son procédé
US20220295124A1 (en) * 2021-03-12 2022-09-15 Vijay Raghavan Chetty Multi-level content delivery system and method thereof
US11956483B2 (en) 2021-03-12 2024-04-09 Digital Mailbox, Inc. Multi-level content delivery system and method thereof

Also Published As

Publication number Publication date
WO2000022787A3 (fr) 2000-08-03
AU1105200A (en) 2000-05-01

Similar Documents

Publication Publication Date Title
EP0662673B1 (fr) Transactions anonymes à cartes de crédit
Ray et al. Fair exchange in e-commerce
Tygar Atomicity in electronic commerce
Medvinsky et al. NetCash: A design for practical electronic currency on the Internet
US5848161A (en) Method for providing secured commerical transactions via a networked communications system
US5671279A (en) Electronic commerce using a secure courier system
US7478239B1 (en) Electronic ticket vending system
Manasse The Millicent Protocols for Electronic Commerce.
US6363365B1 (en) Mechanism for secure tendering in an open electronic network
US10015149B2 (en) Method and system for the supply of data, transactions and electronic voting
US7028187B1 (en) Electronic transaction apparatus for electronic commerce
US7184988B1 (en) Methods for operating infrastructure and applications for cryptographically-supported services
Camp et al. Anonymous atomic transactions
US20020049670A1 (en) Electronic payment method and system
WO2020119298A1 (fr) Procédé et appareil de traitement d'événements basés sur une chaîne de blocs et dispositif électronique
CN101072114A (zh) 电信系统中计费的实现
WO2020119297A1 (fr) Procédé et appareil de traitement d'événements sur la base d'une chaîne de blocs et dispositif électronique
US20030195857A1 (en) Communication technique to verify and send information anonymously among many parties
US20230325791A1 (en) Proxied cross-ledger authentication
Neuman et al. NetCheque, NetCash, and the characteristics of Internet payment services
WO2000022787A2 (fr) Procede, systeme et produit de programme informatique pour des services de courrier electronique renforces
US20090204518A1 (en) System for electronically implementing a business transaction between a payee and a payor
WO2021060340A1 (fr) Système de traitement d'informations de transaction
Neuman et al. Internet payment services
Kravitz Highly scalable on-line payments via task decoupling

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref country code: AU

Ref document number: 2000 11052

Kind code of ref document: A

Format of ref document f/p: F

AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase