Connect public, paid and private patent data with Google Patents Public Datasets

Digital receipt for a transaction

Info

Publication number
CA2417406C
CA2417406C CA 2417406 CA2417406A CA2417406C CA 2417406 C CA2417406 C CA 2417406C CA 2417406 CA2417406 CA 2417406 CA 2417406 A CA2417406 A CA 2417406A CA 2417406 C CA2417406 C CA 2417406C
Authority
CA
Grant status
Grant
Patent type
Prior art keywords
digital
receipt
user
document
transaction
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CA 2417406
Other languages
French (fr)
Other versions
CA2417406A1 (en )
Inventor
Xinhong Yuan
Stan J. Simon
Robert W. Pratt
Gregory R. Whitehead
Atul Tulshibagwale
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
VeriSign Inc
Original Assignee
VeriSign Inc
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
Grant date

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/045Payment circuits characterized in that the payment protocol involves at least one ticket
    • G06Q20/0453Payment circuits characterized in that the payment protocol involves at least one ticket the ticket being an electronic receipt
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes involving intelligent token, e.g. electronic purse
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/12Card verification

Abstract

A first user (110) requests a service provider (130) to create (200,400) a record of a transaction. The service provider (130) creates (230,430) a digital receipt (300,700,900), which includes a description (310,710,910,1020) of the transaction understandable by humans, tamper-proof evidence (320) of the transaction, and a verification prompt (330,740,940,1030). A second user (120) who desires to verify the transaction displays (265,465) the digital receipt (300,700,900) and activates (270,470) the verification prompt (330,740,940,1030). Upon activation, the tamper-proof evidence (320) is verified without requiring further human interaction to identify the tamper-proof evidence.

Description

DIGITAL RECEIPT FOR A TRANSACTION
Inventors: Xinhong Yuan Stan J. Simon Robert W. Pratt Gregory R. Whitehead Ati.11 Tulshibagwale [0001]
BACKGROUND OF THE INVENTION
1. Technical Field [0002] This invention relates generally to public key cryptography, digital signatures and public key infrastructure (PKI). More specifically, it relates to the generation and use of records and digital receipts for transactions.
2. Background Art [0003] As a result of the increasing popularity and acceptance of the computer and the Internet and other forms of networked communications, electronic transactions and documents are increasing in number and significance. For example, the volume of consumer purchases, business to business commerce, and stock trading and other forms of investing which occur over the Internet and/or wireless networks is steadily increasing, as are other forms of online commerce. In addition, the number of documents which are generated or available electronically and the number of documents which exist only in electronic form (e.g., the paperless office) are also steadily increasing.

[0004] The increasing number of electronic transactions and documents leads to a corresponding need for reliable methods for making records of these transactions and documents. For example, when a consumer purchases an item over the Internet using his credit card, it is desirable to make a reliable, non-disputable record of the purchase. If two [0005] One approach to the records problem makes use of cryptography.
The [0006] However, in order to gain widespread acceptance, these approaches should be intuitive and easy to use. One problem with past attempts to create an infrastructure of transaction records is that they were too cumbersome and difficult to use. For example, in [0007] These functions are often performed by separate pieces of software. For example, database software may be used to store the digital signatures and their corresponding software in a large central database. Browser plug-in software may be used to process the correct digital signature once it is located. However, this approach may be both cumbersome and non-another entity, particularly if either entity does not have access to the database at the time. A
similar problem occurs if an entity does not have the correct browser plug-in or does not know how to use the plug-in.

[0008] Thus, there is a need for simple and intuitive approaches to making and using DISCLOSURE OF INVENTION

[0009] In accordance with the present invention, a computer readable medium serves as [0010] In one embodiment, the computer readable medium serves as a record of the existence of a document at a specific time. The digital receipt (700) includes a form in a [0011] In another aspect of the invention, a method (200,400) for creating a record of an occurrence of a transaction includes the following steps. A request to create a digital receipt (300,700) of the transaction is received (210,410). Tamper-proof evidence (320) of the occurrence of the transaction is generated (220,420). A digital receipt (300,700,900) of the transaction is created (230,430). The digital receipt (300,700,900) is suitable for display to humans and includes a description (310,710,720,910,1020) of the transaction, the generated [0012] In another aspect of the invention, a method (250,450) for verifying the past occurrence of the transaction includes the following steps. The digital receipt (300,700,900) 15 [0013] The methods (200,250,400,450) in the previous two paragraphs are preferably implemented by software executing on a processor.
[0014] The present invention is particularly advantageous because the digital receipt (300,700,900) includes both a verification prompt (330,740,940,1030) and the tamper-proof evidence (320) to be verified. This makes the digital receipt (300,700,900) easier and more BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The invention has other advantages and features which will be more readily apparent from the following detailed description of the invention and the appended claims, when taken in conjunction with the accompanying drawing, in which:
[0016] FIG. 1 is a block diagram of a system according to the present invention;
[0017] FIGS. 2A and 2B are event traces illustrating a method of operating the system of FIG. 1;
[0018] FIG. 3 is an illustration of a preferred embodiment of a digital receipt of a transaction according to the present invention;
[0019] FIGS. 4A and 4B are event traces illustrating a preferred method of operating the system of FIG. 1;
[0020] FIGS. 5-8 are various forms and dialog boxes illustrating the method of FIG. 4;
[0021] FIG. 9 is a form illustrating an alternate embodiment of the method of FIG. 4;
and [0022] FIG. 10 is a screen shot illustrating yet another embodiment according to the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0023] This invention relates generally to public key cryptography, digital signatures, [0024] Public key cryptography is an approach to secure communications using key pairs. Each key pair includes a public key and a private key, each of which is typically a large available. The public key and private key are mathematically related so that a message encrypted by one key may be decrypted by the other, but the relationship is such that it is computationally infeasible to calculate one key given the other. In other words, if a third party knows an entity's public key (which is typically the case), it is computationally infeasible to deduce the corresponding private key (which is typically held securely by the entity). Well-known public key encryption algorithms include RSA, DSA and EIGamal.
[0025] These key pairs may be used to "digitally sign" documents. An entity "digitally signs" a document by encrypting either the document or a processed version of the document using the entity's private key. This allows a third party to authenticate the document by verifying that (i) it is the entity's private key (rather than some other key) which has been used to digitally sign the document; (ii) the contents of the document have not changed since the document has been digitally signed; and (iii) the entity cannot later deny that he digitally signed the document. The first characteristic is often referred to as "paternity," the second as "integrity," and the third as "non-repudiation."
[0026] Preferably, a document is digitally signed by first producing a one-way hash (see below) of the document, creating what is commonly referred to as a document digest. The document digest is then encrypted using the entity's private key to produce the digital signature for the document. A third party typically receives both the document and corresponding digital signature and then authenticates the document as follows. The third party decrypts the received digital signature using the entity's public key to yield a decrypted document digest, which should be identical to the original document digest.
The third party also generates a one-way hash of the received document, using the same hash function as was used by the entity, to yield a newly generated document digest. The third party then compares the decrypted document digest and the newly generated document digest. If they are identical, the third party has authenticated the document.
[0027] A hash function is a transformation that takes a variable-size input and returns a fixed-size output, which is typically smaller than the input and is referred to as the hash of the input. A one-way function is a transformation that is significantly easier to perform in one direction than in the opposite direction. A one-way hash function is thus a transformation with both of these characteristics. One-way hash functions used to produce digital signatures preferably also produce outputs which are generally smaller in size than the input, are able to handle inputs of any size, and are collision-free to some degree. Hash functions, by their nature, are many-to-one functions, meaning that many inputs may map to the same output.
However, if the hash function is collision free, this potential problem is obviated for all practical purposes. A hash function is weakly collision free if, given an input, it is computationally infeasible to find another input which maps to the same output. A hash function is strongly collision free if it is computationally infeasible to find any two inputs which map to the same output. Well-known one-way hash functions include MD2, MD5 and SHA-1.
[0028] The use of public key cryptography addresses many of the inherent security problems in an open network such as the Internet. However, without more, two significant problems remain. First, parties must be able to access the public keys of many entities in an efficient manner. Second, since communications and transactions are secured by the key pairs and entities are associated with and in some sense identified by their public keys, there must be a secure method for third parties to verify that a certain public key really belongs to a certain entity.
[0029] Digital certificates are one method for addressing both of these problems. A
"digital certificate" is a document which binds a certain public key to a certain entity, such as individuals, legal entities, web servers, and the like, in a trustworthy manner. More specifically, a digital certificate preferably is issued by a trusted third party, commonly refened to as the certification authority (CA). The digital certificate contains information pertaining to the identity of the entity (a.k.a., subscriber of the digital certificate) and the entity's public key, and the digital certificate is digitally signed by the CA.
[0030] The digital certificate documents in a trustworthy manner that the public key in the digital certificate is bound to the certificate's subscriber. Third parties who wish to verify this information may verify the authenticity of the CA's digital signature and the integrity of the contents of the digital certificate in the manner described above. If the third party trusts the CA, then he can also trust that the public key in the digital certificate is bound to the certificate's subscriber. Hence, if an unknown party communicates with the third party using the private key corresponding to the public key in the digital certificate, the third party can further trust that the unknown party is the subscriber named in the digital certificate. If the third party does not have a basis for trusting the CA, the third party will begin to establish such a basis by authenticating the CA's digital certificate. The third party will continue to authenticate digital certificates, traversing up a chain of digital certificates issued to CAs, until it reaches a CA which it trusts, at which point, the third party can trust that the public key in the digital certificate is bound to the certificate's subscriber.
[0031] Digital certificates preferably comply with the format defined by ITT]
Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection -The Directory: Authentication Framework, June 1997. The digital certificate may be stored on or in any type of computer readable media, including but not limited to hard drives, smart cards, flash memory, magnetic stripes such as on the back of credit cards, or as printed bar codes.
[0032] For security and other reasons, digital certificates typically are valid for a limited period of time only. For example, when digital certificates are issued, they may have an effective date and an expiration date, with the digital certificate being valid only between these dates. Furthermore, if a digital certificate is compromised prior to its expiration date, it may [0033] A PKI is a system for implementing security using public key cryptography and digital certificates. Certain services are used to establish, disseminate, maintain, and service the public keys and associated digital certificates used in a PKI. These services are provided by entities which shall be referred to as service providers. For security, efficiency, and other [0034] FIG. 1 is a block diagram of an example system 100 according to the present [0035] The users 110 and 120 may be individuals, groups of individuals, legal entities provides services associated with the operation of a PICT. In this particular example, service provider 130 provides digital notary services to generate and subsequently verify records of transactions. The service provider 130's records are stored in database 140, which typically is maintained with high security and reliability in order to enhance the trustworthiness of the [0036] The users 110 and 120 communicate with the service provider 130 and may also communicate with each other. The communications connections may be made by any number of means, including over computer networks such as the Internet and/or by wireless connections. The connections need not be permanent or persistent. In a preferred [0037] The requesting user 110 wishes to make a record of a transaction and engages the service provider 130 to do so. The relying user 120 later wants to verify the occurrence of the transaction and does so by relying on the record created by the service provider 130. The [0038] The term "transaction" is used broadly. It includes events, such as an online purchase of goods or the electronic signing of a contract, as well as documents. The example of FIG. 2 is illustrated in the context of creating a record of a "transaction" in the general sense of the term. The preferred embodiment of FIGS. 4-8 uses a notary example, where witnessing [0039] FIGS. 2A and 2B are event traces illustrating operation of system 100. FIG. 2A
illustrates record creation 200, during which the service provider 130 creates a digital record of the transaction for the requesting user 110. FIG. 2B illustrates record verification 250, during which the service provider 130 (which could be a different service provider) verifies the digital [0040] In FIGS. 2A and 2B, each of the dashed boxes 110, 120, and 130 represents one [0041] Referring to FIG. 2A, the requesting user 110 begins by sending 210 to the service provider 130 a request to create a digital record of a transaction.
The request typically includes a description of the transaction in a format understandable by humans. For example, the requesting user 110 might create a short text description of the transaction or send an icon digital certificates or similar information of the signing parties might be included. In the document notary scenario, the document itself might be included.
[0042] The service provider 130 receives 210 both the human-understandable description and the additional information. It processes the additional information to generate 220 tamper-15 [0043] The service provider 130 also creates 230 a second digital record of the transaction, an example of which is shown in FIG. 3. For convenience, this digital record will be referred to as a digital receipt. The digital receipt 300 typically includes a description 310 of the transaction. For example, it might include all or part of the human-understandable description received from the requesting user 110. The digital receipt also includes the 320. Referring again to FIG. 2A, after the service provider 130 creates 230 the digital receipt, the digital receipt is transmitted 235 to the requesting user 110, who typically stores 237 it for later use. In one embodiment, the requesting user's software automatically stores 237 the digital receipt, transparent to the requesting user 110.
[0044] FIG. 2B illustrates one example of how a relying user 120 would use the digital receipt 300 to verify the past occurrence of the transaction. The relying user 120 accesses 260 the digital receipt 300. For example, the requesting user 110 might email or otherwise send a copy of the receipt 300 to the relying user 120 or the relying user 120 might request the receipt 300 from service provider 130 or retrieve the receipt 300 from a central database or directory.
Upon display 265 of the receipt 300, the relying user 120 sees the description 310 of the transaction and the verification prompt 330. User 120 may also see the tamper-proof evidence 320, but not necessarily since the evidence 320 preferably is hidden from view. The relying user activates 270 the verification prompt 330, which initiates the verification process. In this particular example, the tamper-proof evidence 320 is extracted from the digital receipt and sent 280 to the service provider 130, which compares 290 the received evidence 320 against the corresponding record in database 140. If there is a match, the evidence 320 is verified.
Otherwise, there is a lack of verification (assuming that the evidence has not been verified by other means). Either way, the result is sent 295 to the relying user 120. In a preferred embodiment, if the evidence 320 is verified, a second verification prompt is displayed.
Activating 202 this prompt allows the relying user 120 to go one step further and verify 204 the underlying transaction (e.g., verify the integrity of the underlying document in the digital notary scenario).
[0045] Note that the digital receipt 300 includes both a verification prompt 330 and the tamper-proof evidence 320 to be verified. Hence, it is fairly self-contained and is in some sense "auto-verifying." This is a significant advantage since it makes the digital receipt 300 much easier and more intuitive to use. For example, there is no need for the requesting user 120 to independently identify Which piece of evidence is to be verified. As another example, if the digital receipt did not include the verification prompt 330, separate software or instructions would be required to verify the evidence 320. This adds extra complexity since the relying user 120 might not know or have access to the required software and instructions, particularly since the relying user 120 and the requesting user 110 likely will be different entities and may use different service providers with incompatible systems. Even if the relying user 120 did use the same software, it simply might not be available at the moment. For example, the software might reside on one computer and the digital receipt 300 on a different one.
By including both the tamper-proof evidence 320 and the verification prompt 330 in the same location, these [00461 FIGS. 4-8 illustrate a preferred embodiment of system 100 and method 200 which occurs over an HTTP-based system, specifically the Internet. The users 110 and 120 [00471 Referring to FIG. 4A, the requesting user 110 begins by sending 410 to the service provider 130 a request to create a digital record of a transaction. In this embodiment, digitally signed by the user 110 and sent to the service provider 130. In addition to the document name 510 and description 520, the document itself is also sent to the service provider 130.
[0048] From the information received from the user 110, the service provider 130 [0049] The service provider 130 stores 440 a record of the notarization in its database 140. This record includes the user 110's request for notarization (which was digitally signed [0050] The service provider 130 also creates 430 a digital receipt of the transaction for transmission to the requesting user 110. FIG. 7 shows an example of this digital receipt 700.
It is an HTML document which includes the following as viewable elements: the name 710 and description 720 of the document as received from the requesting user 110, and the time <form method = post action = "https://serviceprovidencom/">
<input type = "hidden" value = "Vl.">
<input type = submit value = "Verify">
</form>
"https://serviceprovider.com/" is the SSL URL of the service provider 130. The value "V1"
is the BASE64 encoded version of the time stamp token. Other fields may be used to support additional functionality or provide additional information. For example, the requesting user 110 may also be identified in the digital receipt 700.
[0051] In a preferred embodiment, the digital receipt 700 is not automatically generated and sent to the requesting user 110. Rather, the service provider 130 sends 432 the results of the notarization to the user 110, as shown in FIG. 6. If the notarization was successful, the results screen 600 also prompts the user 110 whether it would like to have a copy of the digital receipt 700. If the user 110 requests 434 a copy (e.g., by clicking on button 610 in this example), the service provider creates 436 and transmits 435 the digital receipt 700 to the user 110. The requesting user 110 stores 437 the digital receipt 700, for example on its local hard drive.
[0052] FIG. 4B illustrates one example of how a relying user 120 would use the digital receipt 700 to verify the notarization. The relying user 120 accesses 460 the digital receipt 700. User 120 might have access to the copy of receipt 700 saved by the requesting user 110.
Alternately, user 120 might receive a copy from the requesting user 110 or from the service provider 130. In an alternate scenario, the requesting user 110 posts both the digital receipt and the underlying document on the Internet. For example, the requesting user 110 might be a company issuing press releases and would post both the press release and the digital receipt on its web site, so that interested parties can verify the authenticity of the press release.
[0053] The relying user 120 opens 465 the digital receipt 700, including the HTML
form, using its web browser. As mentioned previously, the display of the digital receipt includes the name 710 and description 720 of the document, the time 730 for the time stamp, and a "Verify Receipt" button 740.
[0054] Clicking 470 button 740 transmits 480 the time stamp token which is embedded in the HTML form as hidden text to the service provider 130. In this embodiment, the hidden text is POSTed 480 to the service provider 130. The service provider 130 decodes 484 the BASE64 text encoding in order to retrieve the original time stamp token. It verifies 482 the trustworthiness of the time stamp token by examining the digital signature and then compares 490 the recovered time stamp token with those in its own database 140. The time stamp token is verified if it exactly matches the one in the serivce provider 130's database. The service provider 130 sends 495 the results of the comparison to the relying user 120, thus either verifying or not verifying the trustworthiness of the digital receipt 700.
[00551 If the digital receipt 700 is verified, the service provider 130 also sends the requesting user 110's identity, the original name of the document 810, the description of the /0 document 820 and the time 830 for the time stamp, as retrieved from the service provider 130's database 140, as shown in FIG. 8. The response 800 also includes a form with a second verification prompt 840, which allows the relying user 120 to go one step further and verify the underlying document in addition to verifying the notarization.
[0056] Note that so far, only the digital receipt 700 has been verified but the underlying document itself has not been verified. Furthermore, the service provider 130 does not provide a copy of the document nor does it store a copy of the document in this embodiment, although it could do so in alternate embodiments. If the relying user 120 wishes to rely on the contents of the document, it may first want to verify the integrity of those contents.
It can do so by using the "Verify Document" button 840. For example, if it is represented that the document D:\documents\doc-schedules\SalePricelist.doc is the same as the document which was notarized, the relying user 120 identifies the document using the "Browse"
field 850 and then clicks 402 the "Verify Document" button 840. This POSTs 404 the document DAdocuments\doc-schedules\SalePricelist.doc to the service provider 130.
Information used to identify the time stamp token is also POSTed to the service provider 130.
For example, in a preferred embodiment, the serial number of the time stamp token and the hash of the document (as retrieved from the service provider's database) are embedded in the response 800 as hidden form fields and then POSTed to the service provider 130 when the "Verify Document" button 840 is activated. The service provider 130 hashes 406 the received document.
The newly generated hash is compared 408 with the hash in the time stamp token, with the result returned 409 to the relying user 120. If the two hashes match, there is a good basis to believe that the received document is the same as the original. If the hashes do not match, there is reason to believe that the document has been altered.
[0057] In an alternate embodiment, the document itself is included as part of the digital receipt and so can be verified at the same time as the digital receipt. FIG. 9 is an example of a 15 [0058] In one implementation, the digital receipt also includes an HTML form and document 910 is encoded into BASE64 text format and embedded into the form as a hidden form field. The digital receipt 900 also includes javascript code, which decodes and displays the BASE64 hidden text, which is why document 910 is viewable within digital receipt 900.
In this example, the document 910 also serves as a description of the transaction. The form 25 <form method = post action = "https://serviceprovider.com/">
<input type = "hidden" value = "VI.">
<input type = "hidden" value = "V2">
<input type = submit value = "Verify">
</form>
is the BASE64 encoded version of the time stamp token and the value "V2" is the BASE64 encoded version of the document 910. In an alternate embodiment, the values "V1" and "V2"
are pointers to the time stamp token and document, respectively, rather than the actual token and document.
[0059] Clicking button 940 POSTs values V1 and V2 (i.e., the BASE64-encoded versions of the time stamp token and document 910) to the service provider 130. The service provider 130 decodes the BASE64 text encoding in order to retrieve the original time stamp token and document 910. It verifies the trustworthiness of the time stamp token by examining the digital signature and compares the recovered time stamp token with those in its own database 140. The service provider 130 also verifies the authenticity of document 910. The service provider 130 sends the results of these comparisons to the relying user 120, thus either verifying or not verifying the trustworthiness of the digital receipt 900, including document 910. In an alternate embodiment, some or all of the computations (e.g., verifying the authenticity of the document 910) may occur locally at the relying user 120's client.
[0060] In a variation of this approach, rather than having the digital receipt contain the timestamp token, the underlying document, and the Verify button, these three elements are posted to the Internet separately, as shown in FIG. 10. In FIG. 10, the underlying document 1010, a press release, is presented in one location. A "notary receipt" 1020, which contains the timestamp token, is presented separately; as is a "seal" 1030, which is a form containing the Verify button 1040 and pointers to the document and the timestamp token. In this example, the physical placement is used to indicate that notary receipt 1020 and seal 1030 correspond to press release 1010. Although the physical placement looks different, activating the Verify button 1040 has the same effect as activating the Verify button in the previous examples.
Specifically, both the timestamp token and the underlying document are POSTed to the service provider 130 for verification. In other words, the seal 1030 in this scenario plays a similar role as the digital receipts 700 and 900 with respect to initiating the verification process.
[0061] Although the invention has been described in considerable detail with reference to certain preferred embodiments thereof, other embodiments will be apparent.
For example, the examples of FIGS. 4-10 were described in the context of HTML documents, but XML and other standard markup languages are equally suitable for use. In one embodiment using XML, a document type for the digital receipt is defined, and element types, attributes, entities and notations for the content in the digital receipt are declared. In an alternate embodiment, binary files may also be used, with fields within the files defined to provide similar functionality. As another example, most of the examples have been discussed in the context of documents and timestamp tokens themselves (or, more generally, in the context of transactions and the corresponding evidence). However, as illustrated in some of the examples, alternate implementations may use references or pointers instead. As a final example, in most of the discussion, the service provider 130 implements the functionality required to verify certain facts. However, some or all of this functionality may also be implemented by clients residing with the users 110,120. In addition, the functionality may be implemented offline or processed in batch mode. Therefore, the scope of the appended claims should not be limited to the description of the preferred embodiments contained herein.

Claims (22)

1. A computer readable medium storing instructions that are configured to be executed by a computer, the instructions causing a computer to perform steps of:
receiving a request from a requesting user to create a digital receipt of a transaction including verifying an existence of a user-specified document at a specific time;
generating tamper-proof evidence of the transaction; and creating a digital receipt of the transaction suitable for display to humans, the digital receipt comprising:
a description of the transaction in a format understandable by humans;
the tamper-proof evidence of the occurrence of the transaction;
a verification prompt for display to the requesting or other user, activated by interaction of the requesting or other user, for verifying the tamper-proof evidence without requiring further human interaction to identify the tamper-proof evidence; and a second verification prompt for display to the requesting user upon receipt of verification of the tamper-proof evidence, activated by interaction of the requesting user, for verifying the transaction, wherein, the tamper-proof evidence comprises a digitally signed time stamp token comprising:
a fingerprint of the document; and a time stamp for the document.
2. The computer readable medium of claim 1 wherein, upon display of the digital receipt, the description of the transaction and the verification prompt are displayed but the tamper-proof evidence is not displayed.
3. The computer readable medium of claim 1 wherein the document is provided by the requesting user.
4. The computer readable medium of claim 1 wherein the tamper-proof evidence is included by reference in the digital receipt.
5. The computer readable medium of claim 1 wherein the digital receipt is in a standard markup language.
6. The computer readable medium of claim 5 wherein the tamper-proof evidence is encoded as hidden text.
7. The computer readable medium of claim 6 wherein:
the digital receipt includes a form in the standard markup language;
the tamper-proof evidence is encoded as hidden text in the form; and the verification prompt comprises a user-activated element in the form, wherein activation of the user-activated element transmits the hidden text to a service provider for verification.
8. The computer readable medium of claim 6 wherein:
the digital receipt includes a form in the standard markup language;
the description of the transaction comprises:
a name identifying the document, and a time identifying the specific time;
the tamper-proof evidence comprises a digitally signed time stamp token encoded as hidden text in the form, and the verification prompt comprises a user-activated element in the form, wherein activation of the user-activated element transmits the hidden text to a service provider for verification.
9. A method for creating a record of an occurrence of a transaction executed by a computer processor including verifying an existence of a user-specified document at a specific time comprising:
receiving a request from a requesting user to create a digital receipt of the transaction, the transaction including verifying the existence of the user-specified document at a specific time;
generating tamper-proof evidence of the occurrence of the transaction; and creating a digital receipt of the transaction suitable for display to humans, the digital receipt comprising:
a description of the transaction in a format understandable by humans;
the tamper-proof evidence of the occurrence of the transaction;
a verification prompt for display to the requesting user, activated by interaction of the requesting user, for verifying the tamper-proof evidence without requiring further human interaction to identify the tamper-proof evidence; and a second verification prompt for display to the requesting user upon receipt of verification of the tamper-proof evidence, activated by interaction of the requesting user, for verifying the transaction, wherein, the tamper-proof evidence comprises a digitally signed time stamp token comprising:
a fingerprint of the document; and a time stamp for the document.
10. The method of claim 9 wherein, upon display of the digital receipt, the description of the transaction and the verification prompt are displayed but the tamper-proof evidence is not displayed.
11. The method of claim 9 wherein the tamper-proof evidence is included by reference in the digital receipt.
12. The method of claim 9 wherein the step of generating tamper-proof evidence of the occurrence of the transaction comprises: receiving the tamper-proof evidence from a third party.
13. The method of claim 9 wherein the step of creating a digital receipt comprises creating the digital receipt in a standard markup language.
14. The method of claim 13 wherein the step of creating the digital receipt further comprises encoding the tamper-proof evidence as hidden text in the digital receipt.
15. The method of claim 14 wherein:
the digital receipt includes a form in the standard markup language; and the step of creating the digital receipt further comprises:
encoding the tamper-proof evidence as hidden text in the form; and implementing the verification prompt as a user-activated element in the form, wherein activation of the user-activated element transmits the hidden text to a service provider for verification.
16. The method of claim 14 wherein:
the digital receipt includes a form in the standard markup language; and the step of creating the digital receipt comprises:
including a name identifying the document and a time identifying the specific time as part of the description of the transaction;
encoding the digitally signed time stamp token as hidden text in the form; and implementing the verification prompt as a user-activated element in the form, wherein activation of the user-activated element transmits the hidden text to a service provider for verification.
17. The method of claim 9 further comprising: transmitting the digital receipt to the requesting user.
18. A method for verifying the past occurrence of a transaction using a computer processor, the transaction including verifying an existence of a user-specified document at a specific time, said method comprising:
displaying a digital receipt of the transaction to a requesting user, the digital receipt comprising:
a description of the transaction in a format understandable by humans;
tamper-proof evidence of the occurrence of the transaction; and a verification prompt;
activating, by a first human interaction of the requesting user, the verification prompt, whereby the tamper-proof evidence is verified without requiring further human interaction to identify the tamper-proof evidence;
receiving verification of the tamper-proof evidence; and upon receipt of verification of the tamper-proof evidence, displaying a second verification prompt for verifying the transaction, wherein, the tamper-proof evidence comprises a digitally signed time stamp token comprising:
a fingerprint of the document; and a time stamp for the document.
19. The method of claim 18 wherein the step of displaying the digital receipt comprises:
displaying the description of the transaction and the verification prompt; and not displaying the tamper-proof evidence.
20. The method of claim 18 wherein: the digital receipt is in a standard markup language;
and the tamper-proof evidence is encoded as hidden text.
21. The method of claim 18 wherein:
the digital receipt is in a standard markup language;
the step of displaying the digital receipt comprises:
displaying the digital receipt as a form;
displaying a name identifying the document and a time identifying the specific time;
not displaying the digitally signed time stamp token encoded as hidden text in the form; and displaying the verification prompt as a user-activated element in the form, wherein activation of the user-activated element transmits the hidden text to a service provider for verification;
the step of receiving verification of the tamper-proof evidence comprises receiving verification from the service provider as to whether the fingerprint and time stamp in the hidden text transmitted to the service provider match an independently maintained record of the transaction; and the step of displaying a second verification prompt comprises displaying a prompt to verify whether the fingerprint in the hidden text matches a fingerprint of a second document alleged to be identical to the document in existence at the specific time.
22. The method of claim 20 wherein:
the digital receipt includes a form in the standard markup language;
the tamper-proof evidence is encoded as hidden text in the form; and the verification prompt comprises a user-activated element in the form, wherein activation of the user-activated element transmits the hidden text to a service provider for verification.
CA 2417406 2000-07-28 2001-07-19 Digital receipt for a transaction Active CA2417406C (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US22185400 true 2000-07-28 2000-07-28
US60/221,854 2000-07-28
US09907788 US7694332B2 (en) 2000-07-28 2001-07-17 Digital receipt for a transaction
US09/907,788 2001-07-17
PCT/US2001/022969 WO2002011091A1 (en) 2000-07-28 2001-07-19 Digital receipt for a transaction

Publications (2)

Publication Number Publication Date
CA2417406A1 true CA2417406A1 (en) 2002-02-07
CA2417406C true CA2417406C (en) 2014-04-22

Family

ID=26916219

Family Applications (1)

Application Number Title Priority Date Filing Date
CA 2417406 Active CA2417406C (en) 2000-07-28 2001-07-19 Digital receipt for a transaction

Country Status (6)

Country Link
US (2) US7694332B2 (en)
CA (1) CA2417406C (en)
DE (2) DE60126096D1 (en)
EP (1) EP1307863B1 (en)
ES (1) ES2275702T3 (en)
WO (1) WO2002011091A1 (en)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050120217A1 (en) * 2000-06-05 2005-06-02 Reallegal, Llc Apparatus, System, and Method for Electronically Signing Electronic Transcripts
GB2376323B (en) * 2001-06-09 2006-03-15 Hewlett-Packard Company Trusted and verifiable data storage system
US7660988B2 (en) * 2002-03-18 2010-02-09 Cognomina, Inc. Electronic notary
US6934846B2 (en) * 2003-01-22 2005-08-23 Walter Szrek Method of generating unpredictable and auditable random numbers
US20040221162A1 (en) * 2003-02-03 2004-11-04 Phill Kongtcheu Method and systems to facilitate online electronic notary, signatures and time stamping
US7565545B2 (en) * 2003-02-19 2009-07-21 International Business Machines Corporation Method, system and program product for auditing electronic transactions based on biometric readings
US7320073B2 (en) 2003-04-07 2008-01-15 Aol Llc Secure method for roaming keys and certificates
US7500099B1 (en) * 2003-05-16 2009-03-03 Microsoft Corporation Method for mitigating web-based “one-click” attacks
US8171416B2 (en) * 2005-03-29 2012-05-01 International Business Machines Corporation Confirmation system and method for instant messaging
US7673135B2 (en) * 2005-12-08 2010-03-02 Microsoft Corporation Request authentication token
KR100816184B1 (en) * 2006-08-10 2008-03-21 한국전자거래진흥원 System of electronic document repository which guarantees authenticity of the electronic document and issues certificates and method of registering, reading, issuing, transferring, a certificate issuing performed in the system
US8424073B2 (en) * 2006-11-13 2013-04-16 Microsoft Corporation Refreshing a page validation token
FR2914763B1 (en) * 2007-04-06 2013-02-15 Grp Des Cartes Bancaires dynamic cryptogram
US9747598B2 (en) * 2007-10-02 2017-08-29 Iii Holdings 1, Llc Dynamic security code push
WO2010006069A3 (en) * 2008-07-08 2010-04-29 Andre Arzumanyan Transaction data capture device and system
US8386773B2 (en) * 2008-12-09 2013-02-26 Research In Motion Limited Verification methods and apparatus for use in providing application services to mobile communication devices
US20110137803A1 (en) * 2009-12-03 2011-06-09 Symbol Technologies, Inc. Secure electronic receipt systems and methods
US9171271B2 (en) * 2010-01-15 2015-10-27 New York University Computer system, client device and method
WO2012155081A1 (en) * 2011-05-11 2012-11-15 Visa International Service Association Electronic receipt manager apparatuses, methods and systems
US20130124870A1 (en) * 2011-11-16 2013-05-16 Certicom Corp. Cryptographic document processing in a network
WO2013080062A1 (en) * 2011-12-01 2013-06-06 International Business Machines Corporation Cross system secure logon
US9191405B2 (en) 2012-01-30 2015-11-17 Microsoft Technology Licensing, Llc Dynamic cross-site request forgery protection in a web-based client application
US9626701B2 (en) 2012-05-23 2017-04-18 Paynearme, Inc. System and method for facilitating cash payment transactions using a mobile device
US20140074675A1 (en) * 2012-09-12 2014-03-13 Bank Of America Corporation Digital receipt management
US20140358708A1 (en) * 2013-05-30 2014-12-04 Paynearme, Inc. Payment Processing with Restricted Receipt Information
US20150269539A1 (en) * 2014-03-18 2015-09-24 nTrust Technology Solutions Corp. Virtual currency system
US9830580B2 (en) 2014-03-18 2017-11-28 nChain Holdings Limited Virtual currency system
EP3120309A4 (en) * 2014-03-18 2017-10-11 Ntrust Tech Solutions Corp Virtual currency system
US9467299B1 (en) * 2014-03-19 2016-10-11 National Security Agency Device for and method of controlled multilevel chain of trust/revision
US9467298B1 (en) * 2014-03-19 2016-10-11 National Security Agency Device for and method of multilevel chain of trust/revision

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2703800B1 (en) 1993-04-06 1995-05-24 Bull Cp8 The process of signing a computer file and device for setting Óoeuvre.
US5497422A (en) * 1993-09-30 1996-03-05 Apple Computer, Inc. Message protection mechanism and graphical user interface therefor
CA2203779C (en) 1994-10-28 2001-11-20 Stuart A. Haber Digital document authentication system for providing a certificate which authenticates and uniquely identifies a document
US5915022A (en) * 1996-05-30 1999-06-22 Robinson; Rodney Aaron Method and apparatus for creating and using an encrypted digital receipt for electronic transactions
US6327656B2 (en) * 1996-07-03 2001-12-04 Timestamp.Com, Inc. Apparatus and method for electronic document certification and verification
US6868391B1 (en) * 1997-04-15 2005-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Tele/datacommunications payment method and apparatus
EP1029262A4 (en) * 1997-10-06 2005-04-13 Inc Crisnet Single-document active user interface, method and system for implementing same
JP2000036000A (en) 1998-06-30 2000-02-02 Sun Microsyst Inc Neutral observer in electronic commercial transaction
WO2000025245A9 (en) 1998-10-27 2000-10-26 Receipt Com Inc Mechanism for multiple party notarization of electronic transactions
US6584507B1 (en) * 1999-03-02 2003-06-24 Cisco Technology, Inc. Linking external applications to a network management system
WO2000075835A3 (en) 1999-06-04 2001-05-03 Receiptcity Com Inc A secure internet vault for consumer receipts, legal documents and commerce
US7142676B1 (en) * 1999-06-08 2006-11-28 Entrust Limited Method and apparatus for secure communications using third-party key provider
GB2359156B (en) 2000-02-14 2004-10-13 Reuters Ltd Methods of computer programs for and apparatus for providing and accessing digital content

Also Published As

Publication number Publication date Type
US7694332B2 (en) 2010-04-06 grant
DE60126096D1 (en) 2007-03-08 grant
CA2417406A1 (en) 2002-02-07 application
ES2275702T3 (en) 2007-06-16 grant
EP1307863A1 (en) 2003-05-07 application
DE60126096T2 (en) 2007-10-18 grant
EP1307863B1 (en) 2007-01-17 grant
US20020161721A1 (en) 2002-10-31 application
US8370916B2 (en) 2013-02-05 grant
US20100154048A1 (en) 2010-06-17 application
WO2002011091A1 (en) 2002-02-07 application

Similar Documents

Publication Publication Date Title
Adams et al. Understanding PKI: concepts, standards, and deployment considerations
US7231659B2 (en) Entity authentication in a shared hosting computer network environment
US6539093B1 (en) Key ring organizer for an electronic business using public key infrastructure
US6085320A (en) Client/server protocol for proving authenticity
US7003497B2 (en) System and method for confirming electronic transactions
Cox et al. NetBill Security and Transaction Protocol.
US6854056B1 (en) Method and system for coupling an X.509 digital certificate with a host identity
Bellare et al. iKP-A Family of Secure Electronic Payment Protocols.
US7353383B2 (en) System and method for single session sign-on with cryptography
US5774552A (en) Method and apparatus for retrieving X.509 certificates from an X.500 directory
US7203838B1 (en) System and method for authenticating a web page
US20030093678A1 (en) Server-side digital signature system
US6901509B1 (en) Apparatus and method for demonstrating and confirming the status of a digital certificates and other data
US6247127B1 (en) Method and apparatus for providing off-line secure communications
US7206936B2 (en) Revocation and updating of tokens in a public key infrastructure system
US20090271321A1 (en) Method and system for verification of personal information
US6430688B1 (en) Architecture for web-based on-line-off-line digital certificate authority
US20020131601A1 (en) Cryptographic key management method
US20020144119A1 (en) Method and system for network single sign-on using a public key certificate and an associated attribute certificate
US20020184485A1 (en) Method for electronic communication providing self-encrypting and self-verification capabilities
US6102287A (en) Method and apparatus for providing product survey information in an electronic payment system
US20030196106A1 (en) Multiple-use smart card with security features and method
US7050589B2 (en) Client controlled data recovery management
US6938157B2 (en) Distributed information system and protocol for affixing electronic signatures and authenticating documents
US5915022A (en) Method and apparatus for creating and using an encrypted digital receipt for electronic transactions

Legal Events

Date Code Title Description
EEER Examination request