MXPA99001554A - System and method for electroni transactions - Google Patents

Abstract

The present invention relates to a system and method for effecting an electronic transaction, which includes reliable recording, auditing and recovery characteristics. A transaction request message is received from a registered user that includes a validated certificate not protected, and a certificate not validated protected. If the unprotected validated certificate is determined to be legitimate, then a transaction can be made, and the protected non-validated certificate is validated to obtain a validated, protected certificate, which is sent to the user. An audit protocol can be used to further verify the legitimacy of the message of the transaction request, and a user can retrieve information from an interrupted connection by re-running a protocol run

Description

SYSTEM AND METHOD FOR ELECTRONIC TRANSACTIONS FIELD OF THE INVENTION The field of this invention is electronic transactions, and in particular the provision of electronic transactions that can not be linked to a part of the transaction, even when more than one related transaction occurs.

BACKGROUND OF THE INVENTION Electronic transactions must be convenient, reliable, accurate and resistant to fraud. Certain electronic transactions must also protect the privacy of at least part of the transaction. For example, a user who buys a service from a vendor over a network must be able to pay for the service in an electronic transaction without revealing his identity. The need for a part of the transaction to remain private (for example, anonymous.) May cause a conflict with the interests of the other party to the transaction, for example, a seller needs to make sure "Ref.029474 that an electronic transaction is Reliable, for example, that the customer or user in the transaction will pay for the services offered by the seller Typically, a seller uses information about a customer to assess the risk of the seller when contact is made in the transaction, and to trap delinquent users or customers when necessary A good electronic transaction system could accommodate both the privacy needs of one party and the reliability needs of the other party. • acquaintances usually fail to adapt both to the interests of privacy and to the interests of reliability of the different parties, typically sacrificing some in favor of the others. A known system, an anonymizer, protects or prevents the identity of a customer or user from being described to a vendor, but the identity of the customer is known by the anonymizer, and the client's activity can be profiled through the vendors. See Community ConneXion, Inc. < http: // www. anonymizer com > . In a certain sense, the anonymizer is worse than a simple seller, because a simple seller can only outline a behavior of the client or user with respect to the seller himself. On the other hand, the anonymizer can outline customer transactions through several sellers, not just one. The client or user is thus forced to deposit considerable confidence in the anonymizer, which if not guaranteed, could lead to a substantial violation of the privacy of the client or user. Other known systems use electronic funds ("e-cash"), where a customer or user obtains an electronic certificate that is redeemable in a seller for the seller's product. See D. Chaum, Unraceable Electronic Mail, Return Addresses, and Digital Pseudonyms, CACM 24, February 2, 1981, p. 84-88; D. Chaum, Security Without Identification: Transaction Systems to Make Big Brother Obsolete, CACM (28.10), October 1985, p. 1030-1044; D. Chaum. A. Fiat, and M. Naor, Untraceable Electronic Cash, CRYPT088, pp. 319-327, E. Brickell, P. Gemmell, and D. Kravitz, Trustee-based Tracing Extensions to Anonymous Cash and the Making of Anonymous Change, Proceedings of the Sixth Annual ACM-SIAM Sy posium on Discrete Algorithms, p. 457-466, San Francisco, California, January 22-24, 1995; M. Franklin and M. Yung, Towards Provably Secure Efficient Electronic Cash, Columbia University CS Technical Report, TR CUCS-018-92, 1992; and D. Simon, Anonymous Communication and Anonymous Cash, CRYPT096, pp. 61-73. A known system uses the information of the credit card to carry out an electronic transaction. Secure Electronic Transaction (SET) Specation, August 1, 1996. When used here, the term "product" includes an article and / or a service. Providing a service includes providing any kind of information. The electronic certificate is understood to be spent only once, and can be verified by the seller before the seller provides the product. One type of fraud to which these known systems may be vulnerable is the multiple expense of a certificate. Protections or elaborate guards have been designed to detect when a certificate presented for a product has already been spent. Many of these protections or protections involve revealing the identity of the client or user, which violates the privacy of the client or user. A known technique to protect the anonymity of a certificate holder is called a protection. See D. Chaum, Unraceable Electronic Mail, Return Adresses, and Digital Pseudonyms, CACM 24 ¿February 2, 1981, pp. 84-88; D. Chaum, Security Without Identification: Transaction Systems to Make Big Brother Obsolete, CACM (28.10), October 1985, p. 1030-1044; and D. Chaum, A. Fiat, and M. Naor, Untraceable Electronic Cash, CRYPT088, pp. 319-327. A customer or user chooses a purpose and a protection factor. A purpose is a piece of data that, for practical purposes, is used only once. For example, a random number can be a purpose. Both the purpose and the protection factor are known only to the user or customer. The client or user applies the protection factor to the purpose (for example, multiplying the purpose by the protection factor), and presents the protected purpose to a certification authority in the company of a payment. In the exchange of the payment, the certifying authority signs the protected purpose to obtain a protected certificate. The protected certificate is returned to the client. When the client or user wishes to make a purchase, the client or user checks out the certificate (for example, dividing the certificate between the protection factor) to obtain a non-protected certificate. Because only the user or client knows the protection factor, no other party can correlate the unprotected certificate with the protected certificate. The client or user presents the unprotected certificate in the company of the purpose to a seller with a request for the desired product. The seller can verify the validity of the unprotected certificate using the purpose on which it is based using the techniques known in the art. Because of the commutativity of modular arithmetic and the mathematical nature of the signaling process, the signed purpose corresponds to the unprotected certificate. If the unprotected certificate is determined to be valid, then the seller delivers the product to the customer. Otherwise, the product is not delivered to the customer or user. Although the use of protection only protects the anonymity of the client or user, it is not sufficient to safeguard against certain types of fraud. For example, a client or user can present a protected purpose to the certification authority in the company of $ 20, receive the protected certificate, check it out, and then present the unprotected certificate as if it were $ 100. This is possible because the certifying authority never really observes the actual certificate that it is signing, because of the protection factor. Therefore, although protection only protects privacy, it does not itself provide adequate reliability. The problem of the reliability that binds a denomination to a certificate is solved by the use of random check functions. A random check is a one-way function by which it is easy to obtain an output from a given input, but it is very difficult to derive an input from a given output. To obtain a certificate that can only be used by a particular client or user, the client presents a payment authority and a random verification purpose to a certifying authority (for example, a bank). The random check function used by the customer or user is also known by the bank. The bank signs the randomly verified purpose related to a denomination to obtain a certificate, which is returned to the client. To use the certificate, the client redeems or reveals the certificate, purpose and denomination to a seller, who in turn presents the certificate, purpose and denomination to the bank. The bank verifies the certificate using a publicly available verification key. If the certificate is verified to be valid, then the bank authorizes the seller to provide the customer with the requested product, and credits it to the seller's account. If the signature and the certificate do not correspond, then the bank notifies the seller that the certificate is not valid. After the certificate is spent, the bank must register the random number of the check to prevent it from being spent again. The use of random check functions is only reliable because in order to fraudulently spend a certificate, a third party would have to deduce the purpose of the certificate. This is practically impossible using a random check function to derive the certificate for a purpose. However, since the certificate of the client or user is known by the bank both during the initial certification process and in the redemption process, the identity (and therefore the privacy) of the client or user can be compromised by the bank. . Balancing the interests of privacy and reliability through more than one transaction is a challenge because the transaction which is reliable and private can often be correlated with other transactions of the same client or user to compromise privacy, reliability, or both in known systems. Consequently, a series of transactions could be unreliable and compromise privacy. When used here, a series of transactions is understood to include both a simple transaction as well as more than one transaction. Privacy and reliability should be provided for the case of a single transaction, as well as for more than one related transaction. An example of a series of transactions is a subscription service, for example, the payment of rights to a key that can be used repeatedly to access a service during a predetermined amount of time and / or usage. A subscription service is one in which the customer or user pays an initial amount to receive a product from a vendor on the premises. Note that in the degenerate case, a subscription service includes only a single transaction. In certain known e-commerce systems, the customer or user makes an initial payment to a subscription vendor, who in turn gives the customer the means (such as a password) to periodically obtain the vendor's product for a period of time predetermined. Subscriptions are commonly sold on an individual basis. Under such a policy, for example, two individuals seeking a subscription must pay the seller separately; each one could then receive their own subscription and password. If an individual pays a subscription and shares his password with a second person, then two people are able to receive the product from the subscription vendor while only one is paying for it. This sharing problem distinguishes an e-commerce system, suitable for subscription services of known systems such as electronic funds. In electronic fund systems, a certificate is understood to be interchangeable and easily transferable. In an electronic commerce system capable of supporting subscription services, such transfer capacity must be prevented or reduced. To counter the threat of sharing with respect to the reliability of a subscription transaction, the subscription vendor has a strong interest in verifying the behavior of the subscribing customer to ensure that the customer is not sharing their subscription with others. They have not paid the seller. For example, an unusually high activity in a single account could indicate fraud, for example, that many different individuals are making use of a single subscription. On the other hand, the client or user may prefer to have their privacy respected and not have their activity verified. For example, a customer who subscribes to a database service may wish to keep private searches that he does. Similarly, a customer who orders pay-per-use movies may want to keep the identity of the movies he or she orders confidential. These privacy interests must be adapted by a good electronic transaction system in an adjustment of the type of the subscription. There are known techniques for issuing pseudonyms, relating or linking the customer's behavior with the pseudonym instead of the client. However, this will still allow profiles to be built (for example, client behavior) even if a pseudonym transaction is interrupted or accidentally identified to the client. Then, the entire past and future behavior of the client or user can be related to this client or user. A better system for electronic transactions may not suffer from this limitation. A good electronic transaction system could be adapted to both the privacy needs of the customer and the reliability of the seller in a simple electronic transaction, and in more than one related transaction, preventing in part the sharing.

BRIEF DESCRIPTION OF THE INVENTION The present invention advantageously uses the exchange of protected certificates to provide a private, reliable system for electronic transactions, which prevents the illicit sharing of certificates for such transactions. Instead of operating in a similar way to electronic funds, in which a payment vehicle is redeemed for a product (when used here, the term "product" means articles and / or services) in a way that changes the available funds for the client or user, the present invention acts more like a membership pass. That is, the client starts with a certificate, obtains access to a product through the exchange of a certificate, and ends with both the product and the certificate. Unlike electronic funds, the use value of the client of the certificates according to the present invention is related to the amount of time (or number of certificates) remaining in the client's or user's contract (for example, the term of the subscription or membership). Theoretically, this could allow the client or user to be profiled to track the number of certificates used (or available for use) by the client. However, this might not be a practical problem for applications where, for example, thousands of people subscribe to something that can only be used 5 times. Actually, knowing that a customer has, say, three redemptions of certificates left, can not say much to a seller. Verification and reliability recovery methods are provided to improve the security and strength of the present invention. • The present invention is private and reliable for a single electronic transaction, as well as for a series of related transactions. According to one embodiment of the present invention, a first part (for example, a customer) is registered with a registrar to obtain an initial validity certificate. In one mode, the registrar is a second part. In subsequent transactions, a first party (for example, a customer or user) presents a legitimate certificate in the company of an invalid certificate to a third party (for example, a vendor) for each transaction. The third part proves the validity of the certificate assumed by the first part to be legitimized. If it is proven to be valid, the third party makes a response action (for example, provides a service) and commonly legitimizes the invalid certificate and returns it to the first part to be used as the legitimate or valid certificate for the next transaction. Alternatively, the registrar (if different from the third party, then in cooperation with the third party) may declare an audit or review, and determine whether the first party has submitted its certificate fraudulently. These changes are atomic in nature, which means that they can be reliably correlated with each other (for example, a virtually unforgettable secret session key is sent in the company of each related message in the exchange, ensuring that the messages are part of the same transaction). In an alternative mode, the registrar is a seller. The random random number check (ie, purposes) and the protection technique are used in the present invention to provide non-relatable certificates. As is known in the art, the protection technique is used differently, for example, to provide pseudonyms in an alternative to a universal identification system. See D. Chaum, Security Without Identification: Transaction Systems to Make Biq Brother Obsolete, CACM (28.10), October 1985, p. 1030-1044. Each one of these pseudonyms is supposed to identify its owner with some institution and it will not be relatable through different institutions. The present invention is designed to provide certificates that are designed to be non-relatable both through institutions and through transactions within a single institution. In particular, the present invention prevents a seller from relating transactions of a single client or user, even if this client or user has to identify himself initially (for example during the registration process). At the same time, the present invention advantageously allows the seller to protect himself against customers or users who abuse the seller's service. Another difference between the present invention and the prior art is the manner in which protection is effected. In known systems, some mechanism is necessary to ensure either the issuing bank or the receiving vendor that the certificate signed by the issuer has the correct form, that is, that the client or user has not defrauded the signer in the signature of something inappropriate. The present invention advantageously eliminates this requirement by providing security in other parts of the system, simplifying the protection scheme.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows a flow chart illustrating an embodiment of the initiation method of the present invention. Figure 2 shows a flow diagram illustrating one embodiment of the electronic transaction method of the present invention. Figure 3 shows a flow diagram illustrating one embodiment of the verification method according to the present invention. Figure 4 shows a flow chart illustrating one embodiment of the recovery method of a broken or interrupted connection according to the present invention. Figure 5 shows an embodiment of the apparatus according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION One embodiment of the registration method according to the invention is shown in Figure 1. A registrar receives a start request message that atomically links the authorization data with a protected invalid certificate that is to be legitimated, step 101. In one embodiment of the present invention, the registrar is a seller. In another mode, the registrar is a third party. An example of authorization data is a payment. Another example of authorization data is an access permission (for example, an access code, a one-time password, etc.). An example of a protected invalid certificate is a randomly checked purpose, combined with a protection factor. The registrar determines if the authorization data is valid, step 102. If it is determined to be valid, then the protected invalid certificate is legitimated to obtain a protected legitimate certificate, step 103. For example, the registrar signs the invalid certificate protected to legitimize it. The registering party then sends an initiation response message including the authenticated protected certificate atomically attached to the initiation request message, step 104. The initiation request message may be atomically attached to the initiation response message including a session key encoded secret that reliably identifies both messages that are linked or related to each other. One modality of the registration protocol is shown in the following message exchange: Message 1: C - > V:. { Payment, Kcv} , [Certificate request type S, C, h (NI)] Kcv Message 2: V - > C: [h (Nl)] s The first message is from a customer or user with the identifier C of the customer or user to a registrar, which in this mode is the seller V. The portion of the message in the brackets. { } It is confidential. For example, in a modality, the portion of the message in the brackets is encoded. In another modality, the confidentiality of this portion of the message is protected by sending it over a secure route between C and V. The confidential portion of the message in this modality is a Payment and a "session key", Kcv. Payment in one modality is a payment of electronic funds. In another modality it is a credit card number. The session key Kcv is used in a single run of the protocol (for example, registration, redemption, etc.), although it must be changing in a way that depends on the previous messages of this run. However, a session key of a transaction must not be related to the session key of any other transaction to prevent a set of transactions from being related. It should be noted that a "run" or single transaction refers to a single case mode of a method according to the present invention. For example, a single run of a modality of a redemption transaction might involve: receiving a transaction request message that atomically links an unprotected certificate and a protected invalid certificate that is going to be legitimized; determine if the unprotected certificate is valid; and if the unprotected certificate is valid, then make a response to the transaction that includes the validation of the protected invalid certificate to obtain a legitimate protected certificate, and send the validated or legitimate protected certificate attached atomically to the request message of the transaction, to a receiver of the response of the transaction in a response message of the transaction. The proportions of the Messages in the brackets [] are legitimized or authenticated. That is, the receiver is provided with the means to ensure that the sender involved is the true sender. As shown above, the portion of the message in the brackets is authenticated by signing it with the cryptographic key secretly sent in the confidential portion of the message. The authenticated portion includes a request for a certificate for a particular type of service, S, the identifier of the client or user, C, and a purpose randomly checked, protected H (Ni). The purpose NI is checked randomly so that, given the randomly proven purpose h (Nl), it is difficult to obtain the corresponding purpose, NI, but given the purpose, NI, it is relatively straightforward to obtain the purpose randomly proved, h (Nl). • This is an advantageous property during the redemption process. In one modality, the registration process also includes an authenticated acknowledgment message: Message 3 C - > V: [AckjKcv One embodiment of the redemption process according to the present invention is shown in Figure 2. A first party (for example, a customer or user) checks out a validated protected certificate, step 201. The validated protected certificate was validated either by a recorder as the result of a successful registration (see Figure 1, step 103), or by a second party (for example, a vendor) as the result of a successful initial relinquishment. A transaction request message is received in the second part of a registered first part (for example, a customer or registered user), step 202. The transaction request message atomically links an unprotected certificate with an unvalidated certificate protected which is going to be validated In one embodiment of the present invention, the protected non-validated certificate is a randomly protected protected purpose. The second part determines if the unprotected certificate is valid, step 203. If the unprotected certificate is valid, then a transaction response is made, step 204. A mode of the redemption process is shown in the following message exchange: Message 1: C - > V:. { [h (N (i))] s, Ni, Kcv} [Request for transaction type S, h (N (i + 1))] Kcv Message 2: V - > C: [Approved] Kcv 0 [No Approved] Kcv Message 3: C < - > V: [Transaction] Kcv Message 4: V - > C: [h (N (i + l))] s In Message 1, a randomly validated non-protected validated purpose h (Ni) is sent for the purpose, Ni and the Kcv key is sent confidentially from client C to vendor V. An authenticated request is also sent for a transaction of type S and a randomly validated protected purpose not validated (new), h (N (i + l)). The vendor performs the one-way random check function on the Ni purpose and compares the result with the randomly validated, unprotected validated purpose h (Ni). If the two correspond, then the seller determines that the randomly verified, unprotected, validated purpose is a valid certificate, sends an approval message in Message 2, and is linked in the transaction in Message 3. Finally, the seller validates the purpose randomly protected from Message 1 and send it to the client. In one embodiment, the client then sends an authenticated knowledge message upon receipt of the validated, validated, validated purpose of the vendor.

Message 5: C - > V: [AckjKcv In one embodiment of the present invention, a transaction response includes the validation of the protected non-validated certificate to obtain a validated protected certificate and the sending of the validated protected certificate atomically attached to the transaction request message, to a receiver of the response of the transaction. A response receiver of the transaction may be the first party (for example, the customer) or another party. For example, in one modality, a response to the transaction is a gift sent to a third party. In another embodiment, a response message of the transaction is a control signal sent to a piece of equipment of the factory. In one embodiment, the present invention provides a way to verify the anonymity of a piece of equipment. When the state of the equipment is desired by an authorized (ie registered) entity, the entity sends a validated certificate not protected and an uncertified certificate protected to the equipment, which sends the data of the return status in the company of a protected certificate validated according to the present invention. In a subscription service, the certificate exchange can be repeated each time the subscriber (the first part) buys a subscription fee from the seller (the second part). A subscription payment may include the transmission of the information that is sent each time a validated protected certificate is sent to the subscriber. For example, the results of the database investigation can be sent each time a validated protected certificate is sent to the subscriber. In one embodiment of the present invention, the verification data helps protect against fraud. The transaction request message is atomically linked to an unprotected certificate, a protected non-validated certificate that is to be validated, and protected verification data. Not every message is verified, so that the protection of the verification data protect the privacy of the first part when a verification is not carried out. The checks are typically performed at random in accordance with the present invention. However, verifications can also be triggered, for example, by an unusual service activity that may indicate that a subscriber is sharing their certificates with other parties that do not pay. For example, an exceptionally high volume of traffic that has access to a database or telephone service may indicate an intensified need for verifications of transaction requests that have access to the database or service. One embodiment of the verification method according to the present invention is shown in Figure 3. During registration, the client provides a secret verification for the registrar, step 301. In this mode, the registrar is also the vendor. In another mode, the registrar is a third party. During the redemption process, each client transaction request message includes a protected version of the secret verification. Accordingly, the vendor receives a transaction request message with a protected verification secret, step 302. Instead of sending a verification response message to the client, the vendor sends a verification request message atomically attached to the authentication message. transaction request, step 303. The vendor receives a reply message from the verification from the client, which includes the response data from the verification, step 304. In one embodiment, the response data from the verification include a secrecy of the verification and the protection factor of the verification. As with the protected certificate, the protection factor of the verification is combined with the secret of the verification in the transaction requests to hide the secret of the seller's verification until a verification is initiated by the seller. The vendor determines whether the transaction request message of step 302 is legitimate using the data of the verification response, step 305. In one embodiment, the request message of the transaction is legitimate if the secret of the verification combined with the protection factor provided in the verification response message corresponds to the secret of the protected verification received in the transaction request message of step 302. If the transaction message of step 302 is determined to be legitimate, step 306, then the vendor validates the protected non-validated certificate received from the client in the transaction request message of step 302, step 307. The vendor then sends the validated protected certificate to the client, step 308. If the request message of the transaction of step 302 it is determined that it will not be legitimate, step 306, then in a modality, the transaction with the client is terminated da, step 309. That is, no certificate is validated and returns to the client. A mode of the rendering process with verification features included in accordance with the present invention is shown in the following exchange of messages: Message 1: C - > V:. { [h (N (i))] s, Ni, Kcv} [Transaction request of type S, h (N (i + l)), h (Ni, Audit_Secret, Salt)] Kcv Message 2: V - > C: [Approved] Kcv 0 [Not Approved] Kcv O [Verification] Kcv Message 3: C < - > V: [Transaction] Kcv Message 4: V - > C: [h (N (i + l))] s The messages are the same as for the redemption protocol except for the following: First, a randomly checked combination of the purpose Ni, the secret of Audit_Secret and Salt verification is included in Message 1. Salt is a random number that It is a purpose Salt's goal is explained later. Secondly, a response option has been added to Message 2, that is, the start of a verification with a message initiating authenticated verification [Audit] Kcv. One embodiment of the verification process according to the present invention is shown as follows: Message 1: C - > V:. { [h (N (i))] s, Ni, Kcv} [Request for type S transaction, (N (i + 1)), h (Ni, Audit_Secret, Salt)] Kcv Message 2: V - > C: "[Audit] Kcv Message 3: C -> V: {C, Ni, Audit_Secret, Salt.}. Kcv Message 4: V -> C: [H (N (i + l)] s O [Not Approved] Kcv Message 1 is a transaction request with verification characteristics. In message 2, vendor V initiated a verification by sending an authenticated verification initiation message. The customer sends a verification response message to the seller. The verification response message in this mode includes the verification data comprising the client identifier, C, the Ni purpose, a secret of the Audit_Secret verification, and Salt. The seller in this mode is also the registrar, and thus has the Audit_Secret received from client C during the registration process. First, the vendor compares the secret of the verification received in Message 3 with the secret of the verification received from the client in the customer registration message. These must correspond so that the seller determines that message 1 is legitimate. The vendor also randomly checks the secret of the verification, the purpose and salt received in message 3 and compares them with the randomly checked combination of the verification secret, the purpose and the receipt received in Message 1. These must also correspond that the seller knows that the secret of the verification provided by the client in message 3 is the same as the secret of the verification interspersed in Message 1. If both of these correspondences are established, then the response message of the transaction ( Message 1) is determined to be legitimate, and a validated protected random check is sent to the client in Message 4. In an embodiment of the present invention, an authenticated knowledge message is sent from the customer to the vendor when the customer receive Message 4: Message 5: C - > V: [Ack] Kcv Salt's purpose in the above messages is to protect the client's anonymity and the inability to unite customer transactions based on the verification information. Without Salt, a vendor could associate a transaction request message with a customer identity using (Ni, Audit_Secret) received in the transaction request message. Recall that when the seller is the registrar, the seller has a record of the verification secrets received during the registration process from the customer, with each verification secret associated with a customer identifier. A vendor could randomly verify the purpose or received in a transaction request message with the secrets of the verification that he knows of the record until a correspondence with the verification data received in the message of the transaction request is found. To prevent such exhaustive search to reveal a customer identity, Salt's purpose is checked randomly with the secret of the verification and the purpose Neither in each response message of the transaction. Because Salt is a purpose, it changes from message to message, making the verification data untraceable in a message requesting the transaction by the seller. The verification features of the present invention advantageously prevent illicit sharing of certificates. A party that does not pay is not likely to have the secret of verification, which in a modality is a credit card number, or other valuable data for which the registered customer has a strong incentive to keep confidential. This provides a disincentive to share the data that needs to pass a verification. Unlawfully sharing a subscription also incurs the risk of termination of the subscription, and is therefore further banned by the present invention. The present invention terminates a series of transactions by simply not validating and returning a protected certificate not validated as part of the last transaction. The present invention further provides for the true recovery of an interrupted connection or connection, or other interruption in the methods of the present invention. In one embodiment of the present invention, an interrupted protocol is re-displayed in its entirety (except for the current transaction, which is always skipped) with the same session key, purpose and protection factor. The present invention advantageously does not release any information when a protocol is operated again. In one embodiment, the interrupted protocols are considered to be known automatically after some predetermined period of time, after which the client can not recover them from the interruption, and it is not allowed to display them again. If a connection is interrupted after the reception of a new protected certificate that has not been validated has been known to the client in the redemption protocol, then the client can simply use the new certificate in the next request for the transaction. If the connection is interrupted before the user has received the new protected certificate validated in the redemption protocol, then the protocol is reactivated. One mode of the true recovery protocol is shown in Figure 4. The vendor stores the messages of each protocol run (an example of Messages 1 to 4 of the previous redemption protocol), step 401 until the vendor receives the message from customer knowledge • indicating that the customer has received the new certificate (Message 5 in the redemption protocol), or until the default automatic knowledge time has elapsed, step 402. When the client achieves the connection that has been interrupted, step 403, the client returns to show the protocol run starting from the message of the request of the transaction (Message 1 of the protocol of the redemption), step 404. The seller identifies the certificate presented as already spent, and consults its database of the recovery (in which the protocol runs are stored), step 405. If the recovery database indicates that no knowledge has been received from the client, step 406, then the vendor returns the stored response, step 407. As mentioned above, the transaction is skipped, but the client receives a new validated protected certificate to be used in the next run of the protocol to establish contact in the transaction. Note that the client does not identify himself during recovery according to the present invention, advantageously protecting the anonymity of the client. One embodiment of the present invention provides a membership that charges a royalty payment for some or all of the transactions with a customer. For example, in one modality, the seller becomes a single-source, single-source digital signal source or mine. The digital signals correspond to the digital cash approximately as the signals in an arcade game correspond to the scams. The seller can bill these signals by credit card or some other suitable mechanism. The customer spends the signals previously purchased during an electronic transaction in accordance with the present invention. In one embodiment, the signals are spent in a transaction request message, and the seller does not send a protected, validated certificate to the customer unless the payment on signals is valid and sufficient. In another modality, a message of the transaction request includes a credit balance, which must be paid periodically. The use of a credit balance, however, can allow a vendor to link transactions and still relate them to customers, since the credit balance increases monotonically. According to one embodiment of the present invention, a certificate presented by the client operates as a support authentication note that serves to reliably identify an element of a particular group (for example, customers who have subscribed to a particular service ) without compromising the privacy of the group's elements. No certificate (carrier authentication note) can usually be related by the seller to any other, and thus the transactions are anonymous. Another embodiment of the present invention is used to vote. In this mode, a person who votes registers and receives a protected, validated certificate, to convert it into a vote. The registration process ensures, for example, that each voter is entitled to only cast one vote. In one modality, a different electronic destination is provided for each option for which the vote can be divided. The voter checks out the protected, validated voting certificate and sends it to the destination corresponding to the option for which the voter chooses to vote. In another modality, the voter indicates his choice in a certificate, protects it, sends it to be certified, receives it again, unprotects it, and sends it to an electronic destination. For example, in an election with two selections, an odd random number (purpose) corresponds to the first choice, and a random even number (purpose) corresponds to the second choice. The voter chooses a par or odd purpose according to the voter's choice, and votes in accordance with the present invention. This advantageously avoids having to designate different destinations for different votes. One embodiment of an apparatus in accordance with the present invention is shown in Figure 5. A server 501 includes a processor 502 coupled to a memory 503 that stores transaction instructions 504 that are adapted to be executed on a processor 502. server 501 further comprises a gate 505 that is adapted to be coupled to a network 506. Gate 505 is coupled to processor 502 and memory 503. A client (eg, a client) 507 is also coupled to network 506.

Examples of memory 503 include a hard disk, a Read Only Memory (ROM), a Random Access Memory (RAM), a flexible magnetic disk, and any other medium capable of storing digital information. The instructions of transaction 504 can be distributed according to the present invention, stored on a medium. Examples of a medium storing the transaction instructions adapted to be executed by the processor 502 include a hard disk, a flexible magnetic disk, a Compact Disk - Read Only Memory (CD-ROM), a temporary memory, and any other device that can store digital information. In one embodiment, the instructions are stored on the medium in a compressed and / or encoded format. When used herein, the phrase "adapted to be executed by a processor" is understood to mean encompassing instructions stored in a compressed and / or encoded format, as well as instructions that have to be compiled or installed by an installer before being executed by the processor. In one embodiment of the present invention, the instructions of transaction 504 are adapted to be executed by processor 502 to perform the steps of initiating a series of electronic transactions. For example, the instructions are adapted to be executed by the processor 502 to receive an initiation request message that atomically links the authorization data and an unvalidated, shielded certificate, which is to be validated; determine if the authorization data is valid; if the authorization data is valid, then validate the protected non-validated certificate to obtain a protected validated certificate; and sending an initiation response message to a registrant element that includes the validated protected certificate atomically attached to the initiation request message. In another embodiment of the present invention, the instructions of transaction 504 are adapted to be executed by processor 502 to perform an electronic transaction, for example, to receive a transaction request message that atomically links an unprotected certificate and a certificate not validated protected that is going to be validated; determine if the unprotected certificate is valid, and if the unprotected certificate is valid, then make a response from the transaction validating the uncertified certificate protected to obtain a validated protected certificate, and send the validated protected certificate attached atomically to the message transaction request, to a receiver of the response of the transaction in a response message of the transaction. In yet another embodiment, the instructions of transaction 504 are adapted to be executed by processor 502 to verify an electronic transaction, for example, to receive a transaction request message that atomically links an unprotected certificate and an unvalidated certificate protected that is going to be validated and the data of the • protected verification; to send a verification request message atomically attached to the message of the transaction request to a recipient of the verification; to receive a verification response message atomically attached to the message of the verification transaction, wherein the message of the verification response includes the response data of the verification; and to determine if the shielded verification data is valid using the verification response data. Still another embodiment of the present invention includes transaction instructions 504 that are adapted to be executed by processor 502 to retrieve information from an interruption in an electronic transaction in accordance with the method of the present invention. The present invention advantageously provides anonymous, non-linkable or relatable electronic transactions that assure the seller of payment while protecting the privacy of the customer.

It is noted that in relation to this date the best method known by the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Having described the invention as above, property is claimed as contained in the following

Claims (27)

1. A method for initiating a series of electronic transactions, characterized in that it comprises the steps of: a. receive an initiation request message that joins atomically: i. authorization data, and ii. a certificate not validated protected that is going to be validated; b. determine if the authorization data is valid; c. if the authorization data is valid, then validate the protected non-validated certificate to obtain a protected validated certificate; and d. send an initiation response message to a registrant that includes the validated protected certificate attached atomically to the initiation request message received in step a.

2. The method according to claim 1, characterized in that it further comprises the step of receiving a registration recognition message from a registrant who is aware that the registrant has received the initiation response message.

3. The method according to claim 1, characterized in that the message of the initiation request includes a purpose, and further comprises the step of storing the initiation request message and the initiation response message in a recovery database. .

4. A method for recovering from an interruption in the initiation an electronic transaction, characterized in that it comprises the steps of: a. receive a first registration request message from a registrant that includes a purpose, a key to the session, and a protection factor applied to the purpose, and which atomically links i. authorization data, and ii. a certificate not validated protected that is going to be validated; b. storing the message of the initiation request in a recovery database; c. determine if the authorization data is valid; d. if the authorization data is valid, then validate the protected non-validated certificate to obtain a protected validated certificate; and. sending a first initiation response message to a registrant that includes the validated protected certificate atomically attached to the initiation request message received in step a; 10 f. store the first initiation response message in a recovery database; g. receive a second initiation request message; h. determine if the second request message of The initiation has the same purpose, session key, and protection factor applied to the purpose as the first initiation request message stored in the recovery database; e 20 i. if the second initiation request message has the same purpose, session key, and protection factor applied to the purpose as the first initiation request message, then 1. recover the first response message from the initiation of the recovery database; and 2. sending the first initiation response message to the registrant.

5. A method for effecting an electronic transaction, characterized in that it comprises the steps of: a. receive a transaction request message that joins atomically i. an unprotected certificate, and ii. a certificate not validated protected that is going to be validated; b. determine if the unprotected certificate is valid; and c. If the unprotected certificate is valid, then make a response to the transaction that includes: i. validate the protected non-validated certificate to obtain a validated protected certificate, and ii. send the validated protected certificate attached atomically to the request message of the transaction, to a receiver of the response of the transaction in a response message of the transaction.

6. The method according to claim 5, characterized in that the response of the transaction also includes making available a product for a part.

7. The method according to claim 5, characterized in that the response of the transaction also includes obtaining payment for a product.

8. The method according to claim 5, characterized in that it further comprises the step of receiving a message of knowledge of the transaction from a registrant who knows that the receiver of the response of the transaction has received the response message of the transaction.

9. The method according to claim 5, characterized in that it further comprises the step of storing the request message of the transaction and the response message of the transaction in a recovery database.

10. A method for recovering information from an interruption in an electronic transaction, characterized in that it comprises the steps of: a. receive a first transaction request message that includes a key to the session, a purpose and a protection factor applied to the purpose, and that connects atomically i. an unprotected certificate, and ii. a protected non-validated certificate that is going to be validated; b. storing the first message of the transaction request in a recovery database; c. determine if the unprotected certificate is valid, and d. if the unprotected certificate is valid, then make a response to the transaction that includes i. validate the protected non-validated certificate to obtain a validated protected certificate, ii. send the validated protected certificate atomically attached to the transaction request message to a receiver of the transaction response in a first response message of the transaction, and iii. storing the first response message of the transaction in a recovery database; and. receive a second transaction request message that includes a key to the session, a purpose and a protection factor applied to the purpose, and that connects atomically 10 i. an unprotected certificate, and ii. a certificate not validated protected that is going to be validated; F. determine if the second message of the transaction request has the same purpose, key to 15 session, and protection factor applied to the purpose of the first transaction request message stored in the recovery database; and g. if the second message of the request for 20 transaction has the same purpose, session key, and protection factor applied to the purpose that the first message of the transaction request, then i. retrieve the first response message from the recovery database transaction, and ii. send the first response message of the transaction to the recipient of the transaction response.

11. A method for verifying or auditing an electronic transaction, characterized in that it comprises the steps of: a. receive a request message for the transaction that joins atomically i. an unprotected certificate, ii. a protected non-validated certificate that is going to be validated, and iii. protected verification or audit data; b. send the audit request message atomically attached to the transaction request message to an audit recipient; c. receive an audit response message atomically attached to the transaction message of the audit, where the audit response message includes audit response data; d. determine if the protected audit data is valid using the response data of the audit.

12. The method according to claim 11, characterized in that the response data of the audit is determined to be valid if i. the response data of the audit correspond to the protected audit data received in the message of the transaction request, and ii. the response data of the audit are legitimized.

13. An apparatus for initiating a series of electronic transactions, characterized in that it comprises: a. a processor; and b. a memory that stores the adapted instructions so that they are executed by the processor for, i. receive an initiation request message that atomically links the authorization data and a protected non-validated certificate that is going to be validated; ii. determine if the authorization data is valid; iii. if the authorization data is valid, then validate the protected non-validated certificate to obtain a protected validated certificate; and iv. send an initiation response message to a registrant that includes the validated protected certificate attached atomically to the message of the initiation request, the memory attached or connected to the processor.

14. The apparatus according to claim 13, characterized in that it also comprises a door adapted to be coupled to a network, the door coupled or connected to the memory and to the processor.

15. An apparatus for effecting an electronic transaction, characterized in that it comprises: a. a processor, and b. a memory that stores the adapted instructions so that they are executed by a processor for i. receive a transaction request message that atomically links an unprotected certificate and a protected non-validated certificate that is going to be validated; ii. determine if the unprotected certificate is valid, and iii. If the unprotected certificate is valid, then perform a response from the transaction that validates the protected non-validated certificate to obtain a validated protected certificate, and send the validated protected certificate attached atomically to the transaction request message, to a recipient of the response of the transaction in a message of the response of the transaction, the memory attached or connected to the processor.

16. The apparatus according to claim 15, characterized by further comprises a door adapted to be coupled or connected to a network, the door coupled or connected to the memory and to the processor.

17. An apparatus for auditing an electronic transaction, characterized in that it comprises: a. a processor; and b. a memory that stores the adapted instructions so that they are executed by the processor for i. receive a transaction request message that atomically links an unprotected certificate and a protected non-validated certificate that is to be validated and the protected audit data; ii. send an audit request message attached atomically to the request message of the transaction, to an audit recipient; iii. receive an audit response message atomically attached to the transaction message of the audit, where the audit response message includes the response data of the audit; and iv. determine if the protected audit data is valid using the data from the audit response, the memory attached or connected to the processor.

18. The apparatus according to claim 17, characterized in that it further comprises a door adapted to be coupled or connected to a network, the door coupled or connected to the processor and memory.

19. An apparatus for recovering information from an interruption in an electronic transaction, characterized in that it comprises: a. a processor; and b. a memory that stores the instructions adapted to be executed by the processor for i. receive a first message of the transaction request that includes a key to the session, a purpose and a protection factor applied to the purpose, and that atomically binds a certificate and a certificate not validated protected that is going to be validated; ii. storing the first request message of the transaction in a recovery database; iii. determine if the unprotected certificate is valid; iv. if the unprotected certificate is valid, then make a response from the transaction that validates the uncertified certificate protected to obtain a 10 validated protected certificate, send the validated protected certificate attached atomically to the message of the transaction request, to a receiver of the response of the transaction in a first message of 15 response of the transaction, and storing the first response message of the transaction in a recovery database; v. receive a second transaction request message that includes a key from the 20 session, a purpose and a protection factor applied to the purpose, and that atomically links an unprotected certificate and a protected non-validated certificate that is going to be validated; saw. determine if the second request message of the transaction has the same purpose, session key, and protection factor applied to the purpose that the first message of the transaction request stored in the recovery database; vii. if the second message of the transaction request has the same purpose, session key, and protection factor applied to the purpose of the first message of the transaction request, then retrieve the first response message of the transaction from the recovery database and send the first response message of the transaction to the receiver of the transaction response, the memory attached or connected to the processor.

20. The apparatus according to claim 19, characterized in that it also comprises a door adapted to be coupled or connected to a network, the door coupled or connected to the processor and memory.

21. A means that stores adapted instructions for execution by a processor to perform the steps of: a. receive an initiation request message that atomically i. authorization data, and ii. a certificate not validated protected that is going to be validated; b. determine if the authorization data is valid; c. if the authorization data is valid, then validate the protected non-validated certificate to obtain a protected validated certificate; and d. send an initiation response message to a registrant that includes the validated protected certificate attached atomically to the initiation request message received in step a.

22. A medium that stores instructions adapted to be executed by a processor to perform the steps of: a. receive a transaction request message that joins atomically i. an unprotected certificate, and ii. a certificate not validated protected that is going to be validated; b. determine if the unprotected certificate is valid; and c. if the unprotected certificate is valid, then make a response to the transaction that includes i. validate the protected non-validated certificate to obtain a validated protected certificate, and ii. send the validated protected certificate attached atomically to the request message of the transaction, to a receiver of the response of the transaction in a response message of the transaction.

23. A medium that stores instructions adapted to be executed by a processor to perform the steps of: a. receive a transaction request message that joins atomically i. a protected nc certificate, and ii. a certificate not validated protected that is going to be validated; and iii. protected audit data; b. send an audit request message attached atomically to the message of the transaction request, to an audit recipient; c. receive an audit response message atomically attached to the transaction message of the audit, where the audit response message includes the response data of the audit; d. determine if the protected audit data is valid using the response data of the audit.

24. A system for effecting an electronic transaction, characterized in that it comprises: a. means to receive a request message for the transaction that joins atomically i. an unprotected certificate, and ii. a certificate not validated protected that is going to be validated; b. means to determine if the unprotected certificate is valid, and c. means to validate the protected non-validated certificate to obtain a validated protected certificate; and d. means for sending the validated protected certificate atomically attached to the message of the transaction request, to a receiver of the response of the transaction in a response message of the transaction.

25. The system according to claim 24, characterized in that it also comprises means for auditing an electronic transaction.

26. The system according to claim 24, characterized in that it also comprises means for initiating a series of electronic transactions.

27. The system according to claim 2, characterized in that it also comprises means for recovering information of an interruption in an electronic transaction.