DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This Office Action is in response Applicant communication filed on 6/2/2026.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 6/2/2026 has been entered.
Claims
Claims 1 and 15 have been amended.
Claim 10-14 have been cancelled.
Claims 1-9 and 15-20 are currently pending in the application.
Response to Arguments
103
The applicant argues that Ejlersen does not teach or suggest the newly added limitation “storing the individual item-specific digital purchase receipt data structures such that the consumer owns and controls the data and can share the data as the consumer chooses”. Specifically the applicant argues that “Ejlersen discloses an accounting system where receipts are generated and transmitted to a user’s computer-based accounting system. However Ejlersen does not teach or suggest storing receipt data structures such that the consumer owns and controls the data and can share the data as the consumer chooses”, “these disclosures demonstrate that in Ejlersen, the data is stored and managed by accounting systems, ERP systems, and service providers – not owned and controlled by the consumer”, “Ejlersen’s architecture is designed for automated data flow to accounting systems, not for consumer ownership and control”, and “setting preferences within a system is fundamentally different from owning and controlling the underlying data such that the consumer can independently choose to share the data” (see applicant’s arguments/remarks pages 8 and 9).
However the examiner respectfully disagrees. Ejlersen in sections [0039] and [0040] discloses that when a purchase includes a plurality of items, a separate electronic receipt is stored in an electronic record for each individual item. Further, Ejlersen in section [0089] discloses that the accounting system may for instance store the electronic receipt in the dedicated folder on a server, where the dedicated folder may be associated with the user’s electronically generated and stored profile of the user. Furthermore, Ejlersen in sections [0081]-[0084] discloses that the user will have an option to accept or decline targeted advertisements, and may also configure whether this occurs as part of the user’s profile, that is, whether the user is willing to share this purchase information with third-parties. In summary, Ejlersen discloses that the user can control whether or not they are willing to share their purchase information, stored in their profile, with other parties so that the other parties can use the purchase information to send targeted offer/advertisements to the user. Therefore Ejlersen teaches the limitation “storing the individual item-specific digital purchase receipt data structures such that the consumer owns and controls the data and can share the data as the consumer chooses” as written.
Further the applicant argues that Ejlersen/Pattanaik/Balaraman do not teach or suggest “storing the individual item-specific digital purchase receipt data structures such that the consumer owns and controls the data and can share the data as the consumer chooses” and that there is no motivation in the references to modify any of the disclosed systems to provide consumer ownership and control of individual item-specific digital purchase receipt data (see applicants arguments/remarks pages 9-12).
However the main reference Ejlersen discloses this limitation as disclosed above.
Furthermore, the applicant argues that the combination of Ejlersen/Pattanaik/Balaraman do not disclose: “individual item-specific digital purchase receipt data structures – each receipt corresponds to exactly one purchased item (not transaction-level)” (see applicants arguments/remarks pages 12 and 13).
However the examiner respectfully disagrees. Ejlersen teaches “individual item-specific digital purchases receipt data structures – each receipt corresponds to exactly one purchase item (not transaction-level)”. Ejlersen in sections [0039]-[0040] recites that if a purchase involves more than one item, the computing device generates a separate electronic receipt for each item and generates a separate record for each item purchased.
Furthermore, the applicant argues that the combination of Ejlersen/Pattanaik/Balaraman do not disclose: “cryptographically authenticated per-item digital receipts distinct from transaction level smart contracts – the receipts are cryptographically signed and distinct form smart contracts” (see applicants arguments/remarks pages 12 and 13).
However the examiner respectfully disagrees. Pattanaik discloses “cryptographically authenticated per-item digital receipts distinct from transaction level smart contracts – the receipts are cryptographically signed and distinct form smart contracts”. Pattanaik discloses this in section [0084] which recites “For example, the envelope 515 can include a digital signature that was generated using the private key of the central service provider 150. This acts as a cryptographic guarantee that the transaction record 540 was written in a block to the blockchain. In various embodiments, the envelope 515 can include information corresponding to further processing of the payload 520. For example, the payload 520 in a transaction record 540 may be encrypted using either symmetric or asymmetric cryptographic techniques. Therefore, the envelope 515 can include information (e.g., a signature of the appropriate key that encrypted the payload) such that a device can identify and appropriately decrypt the encrypted payload”. Even though examiner believes that Pattanaik discloses this limitation as written, the examiner added reference 20040199435 A1 to Abrams to specifically disclose that a private key of a merchant is used for signing the purchase receipt.
Furthermore, the applicant argues that the combination of Ejlersen/Pattanaik/Balaraman do not disclose: “self-proving data structures with traditional receipt data – each receipt proves the purchase and includes traditional receipt data such as price paid, date of purchase, and merchant identifying data” (see applicants arguments/remarks pages 12 and 13).
However the examiner respectfully disagrees. Pattanaik discloses “self-proving data structures with traditional receipt data – each receipt proves the purchase and includes traditional receipt data such as price paid, date of purchase, and merchant identifying data”. Pattanaik in sections [0086]-[0088] and [0097] recites that the transaction records are recorded on the blockchain and each transaction record block contains a hash value that references the previous transaction record. Therefore if any detail of a transaction record or a block of transaction records is changed, then the block of transaction records is invalidated. The use of the blockchain by Pattanaik to store the transaction records ensures that the transaction records are self-proving data structures. One of ordinary skill in the art at the time the application was filed, knows that data structures stored on the blockchain are inherently “self-proving” data structures because it uses cryptography and distributed consensus to allow anyone to verify the integrity and accuracy of recorded transactions without needing a trusted third party.
Furthermore, the applicant argues that the combination of Ejlersen/Pattanaik/Balaraman do not disclose: “consumer ownership and control with selective sharing – the receipt data structures are stored such that the consumer owns and controls the data and can share the data as the consumer chooses” (see applicants arguments/remarks pages 12 and 13).
However the examiner respectfully disagrees. This is disclosed above with regards to applicant’s previous arguments.
The examiner has considered all of the applicant’s arguments but maintains the 103 rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-9 and 15-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. In this instant case,
Claims 1 and 15, the claims recite “wherein the digital purchase receipt is a self-proving data structure proving a consumer purchased the item and includes data identifying an item and at least some traditional receipt data such as price paid, date of purchase, and merchant identifying data (emphasis added). The phrase “such as” is interchangeable with the phrase "for example" which renders the claim indefinite because it is unclear whether the limitation(s) following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
Further, claims 2-9 and 16-20 are rejected as being dependent on claims 1 and 15 above.
Rejections under 35 § U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all
obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5-99 and 15, 16, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20160110821 A1 (“Ejlersen”) and US 20170366516 A1 (“Pattanaik”) and US 20040199435 A1 (“Abrams”).
Per claims 1 and 15, Ejlersen teaches:
electronically receiving an account identifier associated with a purchase transaction and, for each item of a plurality of items in the purchase transaction, an item identifier and price data (e.g. The information about the location or address, e.g. a telephone number, IP-address, or email address, of the user's accounting system 30 may be associated with the user profile 22 or by the payment method or account used. Thus, the point-of-sale computing device 10 may receive the information about the location or address from the user's electronically stored profile 22 or the payment method, after which the point-of-sale computing device 10 sends the information and price about the payment as well as the electronic receipt to said location or address) and (e.g. The information about the item may comprise any combination of information from the group of: purchase date, purchase time, name of the point-of-sale, location, price, number of purchased items, category of each purchased item, manufacturer, taxes paid, product identifier code (such as a UPC barcode or other scannable or computer readable product identifier), purchase date, purchase time, name of the point-of-sale, location, price, purchased items, category of purchased item, and the like) (Section [0039], [0061], and [0076]);
generating individual item-specific digital purchase receipt data structures on the memory device specifically for consumer possession and control, each individual item-specific digital purchase receipt data structure corresponding to exactly one purchased item and serving as a standalone verifiable digital receipt for a corresponding specific item, each individual item-specific digital purchase receipt data structure associated with of each item with a corresponding item identifier included in the purchase transaction, and each at least includes respective price data for the corresponding item identifier… (e.g. the user in step a purchases a plurality of items, and wherein the point-of-sale computing device generates a separate electronic receipt for each item in step b) and/or the user's computer based accounting system in steps e) and f) extracts price and information for each item and stores said price and information in separate electronic records for each item. A purchase often involves more than one item. The method according to the invention may automatically divide such a purchase into separate records, such that each purchased item is properly balanced and entered into the bookkeeping records) (Section [0039]-[0040]);
wherein the digital purchase receipt… proving a consumer purchased the item and includes data identifying an item and at least some traditional receipt data such as price paid, date of purchase, and merchant identifying data (e.g. The information about the purchased item may comprise one or more of the following: purchase date, purchase time, name of the point-of-sale, location, price, product name, manufacturer name, product type or category, and the like. Thus, a number of details may be stored in the bookkeeping module, which may be important for accounting and tax purposes) (Section [0039], [0054], [0077], and [0081]); Note: the limitation “wherein the digital purchase receipt is a self-proving data structure proving the consumer purchased the item and includes data identifying an item and at least some traditional receipt data such as price paid, date of purchase, and merchant identifying data” does not distinguish over the prior art as written because it is describing the digital purchase receipt and its data which does not affect the steps/functions of the claims in a manipulative sense.
storing the individual item-specific digital purchase receipt data structures such that the consumer owns and controls the data and can share the data as the consumer chooses (e.g. Once a purchase has been completed, the accounting system 30 may also update the user profile 32 associated with the user, e.g., updating a purchase history and an offer/advertising profile. The accounting system 30 may send the offer/advertising profile to the point-of-sale computing device 10 and other points-of-sales, i.e. shops, whereby the point-of-sale computing device may then generate and send targeted offer/advertisements to the user 20 based on the user's purchase history. The user will have an option to accept or decline such targeted advertisements, and may also configure whether this occurs as part of the user's profile, that is, whether the user is willing to share this purchase information) (Section [0081]-[0083]); Note: the applicant’s specification in section [0017] recites “Furthermore, consumers having possession of digital purchase receipts and generally own and control the data can share this data as they choose. For example, consumers may choose to share data with interested entities in exchange for a benefit, such as product discounts and even payment. Offers of payment, discounts, and other benefits for sharing data may be made through digital purchase receipt data marketplaces and consumers may choose to sell their data to enable the purchasers to use the data for purposes such as advertising, offers, market research, and the like”. Therefore “own” and “control” of the data in the digital purchase receipt data structures is defined as the consumer being able to choose to share the data with interested entities. Ejlersen discloses that the user can choose whether or not to share their purchase information with advertisers and therefore teaches this limitation as written.
transmitting each individual item-specific digital purchase receipt data structure generated for the purchase transaction as consumer-controlled digital proof of purchase to a location associated with the account identifier, wherein the consumer gains possession and control of individual digital receipts for each purchased item (e.g. The information about the location or address, e.g. a telephone number, IP-address, or email address, of the user's accounting system 30 may be associated with the user profile 22 or by the payment method or account used. Thus, the point-of-sale computing device 10 may receive the information about the location or address from the user's electronically stored profile 22 or the payment method, after which the point-of-sale computing device 10 sends the information and price about the payment as well as the electronic receipt to said location or address) (Section [0047]-[0054], [0076], and [0089]);
Although Ejlersen teaches a transaction system that generates separate receipt data structures for each item on a purchase receipt, stores the separate receipt data structures in a database, and sends/provides access to the separate receipt data structures to the purchaser, Ejlersen does not specifically teach:
a network interface device;
a computer processor;
a memory device, with instructions stored thereon, which when executed by the computer processor cause the system to perform data processing activities comprising:;
…wherein generating further includes maintaining a pointer to a hash value within each individual item-specific digital purchase receipt data structure, each corresponding hash value references or links to a previous individual item-specific digital purchase receipt data structure, wherein a first data structure generated for the corresponding item identifier lacks a corresponding pointer and a corresponding hash value;
signing each individual item-specific digital purchase receipt data structure in the memory with a private key of a private/public key-pair of a merchant of the purchase transaction to create cryptographically authenticated per-item digital receipts distinct from transaction-level smart contracts;
wherein the digital purchase receipt is a self-proving data structure…;
wherein each individual item-specific digital purchase receipt data structure is a verifiable claim indicating that a consumer and whomever the consumer shares a digital purchase receipt with can verify the verifiable claim is original, has not been tampered with, and came from a specific merchant
using each individual item-specific digital purchase receipt data structure as a self-proving and verifiable claim data structure that proves the consumer purchased the item.
However Pattanaik, in analogous art of storing payment transaction receipts on the blockchain, discloses:
a network interface device (e.g. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like) (Section [0135]-[0137]);
a computer processor (e.g. This apparatus may be specially constructed for the required purposes, and/or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory, tangible computer readable storage medium, or any type of media suitable for storing electronic instructions, which may be coupled to a computer system bus. Furthermore, any computing systems referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability) (Section [0135]-[0137]);
a memory device, with instructions stored thereon, which when executed by the computer processor cause the system to perform data processing activities comprising: (e.g. This apparatus may be specially constructed for the required purposes, and/or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory, tangible computer readable storage medium, or any type of media suitable for storing electronic instructions, which may be coupled to a computer system bus. Furthermore, any computing systems referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability) (Section [0135]-[0137]);
…wherein generating further includes maintaining a pointer to a hash value within each individual item-specific digital purchase receipt data structure, each corresponding hash value references or links to a previous individual item-specific digital purchase receipt data structure, wherein a first data structure generated for the corresponding item identifier lacks a corresponding pointer and a corresponding hash value (e.g. The block generation module 320 maintains a blockchain network for the central service provider 150 and generates new blocks of transaction records 525 that can be appended to the blockchain network. Each block of the blockchain contains a reference of a prior block of the blockchain, thereby ensuring that the blocks of transaction records 525 are immutable in the blockchain. For example, a reference may be a hash value representing the immediately prior block of the blockchain. Therefore, if any detail of a transaction record 540 or a block of transaction records 525 is changed, then the block of transaction records 525 is invalidated) (Section [0086]-[0089] and [0097]-[0098]);
wherein the digital purchase receipt is a self-proving data structure… (e.g. The block generation module 320 maintains a blockchain network for the central service provider 150 and generates new blocks of transaction records 525 that can be appended to the blockchain network. Each block of the blockchain contains a reference of a prior block of the blockchain, thereby ensuring that the blocks of transaction records 525 are immutable in the blockchain. For example, a reference may be a hash value representing the immediately prior block of the blockchain. Therefore, if any detail of a transaction record 540 or a block of transaction records 525 is changed, then the block of transaction records 525 is invalidated) (Section [0086]-[0089] and [0097]); Note: The use of the blockchain by Pattanaik to store the transaction records ensures that the transaction records are self-proving data structures. This is evidenced by Pattanaik reciting “For example, a reference may be a hash value representing the immediately prior block of the blockchain. Therefore, if any detail of a transaction record 540 or a block of transaction records 525 is changed, then the block of transaction records 525 is invalidated”. One of ordinary skill in the art at the time the application was filed, knows that data structures stored on the blockchain are inherently “self-proving” data structures because it uses cryptography and distributed consensus to allow anyone to verify the integrity and accuracy of recorded transactions without needing a trusted third party.
wherein each individual item-specific digital purchase receipt data structure is a verifiable claim indicating that a consumer and whomever the consumer shares a digital purchase receipt with can verify the verifiable claim is original, has not been tampered with, and came from a specific merchant (e.g. The block generation module 320 maintains a blockchain network for the central service provider 150 and generates new blocks of transaction records 525 that can be appended to the blockchain network. Each block of the blockchain contains a reference of a prior block of the blockchain, thereby ensuring that the blocks of transaction records 525 are immutable in the blockchain. For example, a reference may be a hash value representing the immediately prior block of the blockchain. Therefore, if any detail of a transaction record 540 or a block of transaction records 525 is changed, then the block of transaction records 525 is invalidated) (Section [0086]-[0089]);
using each individual item-specific digital purchase receipt data structure as a self-proving and verifiable claim data structure that proves the consumer purchased the item (e.g. The block generation module 320 maintains a blockchain network for the central service provider 150 and generates new blocks of transaction records 525 that can be appended to the blockchain network. Each block of the blockchain contains a reference of a prior block of the blockchain, thereby ensuring that the blocks of transaction records 525 are immutable in the blockchain. For example, a reference may be a hash value representing the immediately prior block of the blockchain. Therefore, if any detail of a transaction record 540 or a block of transaction records 525 is changed, then the block of transaction records 525 is invalidated) (Section [0086]-[0089]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction receipt record storage of Ejlersen to include the use of the blockchain to store the transaction receipts by linking the receipts using hash values which inherently makes the digital receipts self-proving data structures, as taught by Pattanaik, in order to achieve the predictable result of easily verifying transactions and making the transactions more reliable because of a traceable lineage (See Pattanaik Paragraphs 5 and 6).
Although Ejlersen/Pattanaik disclose generating individual item transaction receipts and storing the individual item transaction receipts on the blockchain linked by hash values, Ejlersen/Pattanaik do not specifically disclose:
signing each individual item-specific digital purchase receipt data structure in the memory with a private key of a private/public key-pair of a merchant of the purchase transaction to create cryptographically authenticated per-item digital receipts distinct from transaction-level smart contracts.
However Abrams, in analogous art of digital purchase receipts, discloses:
signing each individual item-specific digital purchase receipt data structure in the memory with a private key of a private/public key-pair of a merchant of the purchase transaction to create cryptographically authenticated per-item digital receipts distinct from transaction-level smart contracts (e.g. A related aspect of the present invention includes the generation of a digital receipt incorporating a digital image file of a purchased product. More specifically, after a user purchases a product, server 32 constructs a digital receipt comprising data relating to the details of the transaction (date, time, price, quantity, payment information, etc.) and a digital image file of the purchased product as captured by image acquisition system 20. In one form, this receipt includes a 25, digital signature using the merchant site's private key. This signed digital receipt can then be e-mailed to the purchaser as a confirmation of his or her purchase) (Section [0057]);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the digital transaction receipts of Ejlersen/Pattanaik to be digitally signed by a merchant’s private key, as taught by Abrams, in order to achieve the predictable result of providing enhanced security, data integrity, and authenticity ensuring that the merchant receipt has not been tampered with.
Per claim 2, Ejlersen/Pattanaik/Abrams discloses all the limitations of claim 1 above. Pattanaik further discloses:
wherein each individual item-specific digital purchase receipt data structure for associated with corresponding item identifier includes the account identifier (e.g. In some embodiments, each hash value (502, 505A, or 505B) corresponds to an immediately previous transaction in a transaction request from a party. In other words, each hash value (502, 505A, or 505B) represents the immediately prior transaction record of a transaction sent by the party. Thus, a chain of transaction records 540 can be created that is specific for the party of the blockchain) (Section [0059], [0083], [0085], and [0097]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the stored transaction receipt data of Ejlersen/Abrams to include a user account identifier, as taught by Pattanaik, in order to achieve the predictable result of simplifying traceability by making it easier to trace all the transactions of a specific user.
Per claim 3, Ejlersen/Pattanaik/Abrams discloses all the limitations of claim 1 above. Ejlersen further discloses:
wherein the account identifier is an address of the location associated with the account identifier to which each individual item-specific digital purchase receipt data structure is transmitted (e.g. The information about the location or address, e.g. a telephone number, IP-address, or email address, of the user's accounting system 30 may be associated with the user profile 22 or by the payment method or account used. Thus, the point-of-sale computing device 10 may receive the information about the location or address from the user's electronically stored profile 22 or the payment method, after which the point-of-sale computing device 10 sends the information and price about the payment as well as the electronic receipt to said location or address) (Section [0076]).
Per claims 5 and 16, Ejlersen/Pattanaik/Abrams discloses all the limitations of claims 1 and 15 above. Pattanaik further discloses:
storing each individual item-specific digital purchase receipt data structure over a network location to a ledger (e.g. The block generation module 320 maintains a blockchain network for the central service provider 150 and generates new blocks of transaction records 525 that can be appended to the blockchain network) (Section [0085]-[0087]).
The motivation to combine Pattanaik with Ejlersen/Abrams is disclosed above with reference to claims 1 and 15.
Per claim 6, Ejlersen/Pattanaik/Abrams discloses all the limitations of claim 5 above. Pattanaik further discloses:
wherein each individual item-specific digital purchase receipt data structure is a block of a blockchain and the ledger is a blockchain ledger (e.g. The block generation module 320 maintains a blockchain network for the central service provider 150 and generates new blocks of transaction records 525 that can be appended to the blockchain network) (Section [0085]-[0087]).
The motivation to combine Pattanaik with Ejlersen/Abrams is disclosed above with reference to claims 1 and 15.
Per claims 7 and 19, Ejlersen/Pattanaik/Abrams discloses all the limitations of claims 1 and 15 above. Ejlersen further discloses:
wherein each individual item-specific digital purchase receipt data structure associated with the corresponding item identifier is an electronic proof of purchase of the corresponding item (e.g. the user in step a) purchases a plurality of items, and wherein the point-of-sale computing device generates a separate electronic receipt for each item in step b) and/or the user's computer based accounting system in steps e) and f) extracts price and information for each item and stores said price and information in separate electronic records for each item. A purchase often involves more than one item. The method according to the invention may automatically divide such a purchase into separate records) (Section [0015], [0016], [0039] and [0040]).
Per claim 8, Ejlersen/Pattanaik/Abrams discloses all the limitations of claim 1 above. Ejlersen further discloses:
wherein each individual item-specific digital purchase receipt data structure includes further data of the transaction including data identifying the merchant and a date of the purchase transaction (e.g. The information about the item may comprise any combination of information from the group of: purchase date, purchase time, name of the point-of-sale, location, price, number of purchased items, category of each purchased item, manufacturer, taxes paid, product identifier code (such as a UPC barcode or other scannable or computer readable product identifier), purchase date, purchase time, name of the point-of-sale, location, price, purchased items, category of purchased item, and the like) (Section [0039] and [0040]).
Per claims 9 and 20, Ejlersen/Pattanaik/Abrams discloses all the limitations of claims 1 and 15 above. Ejlersen further discloses:
receiving a payment with regard to at least one of the transmitted data structures subsequent to the corresponding individual item-specific digital purchase receipt data structure having been forward to an entity as authorized by a holder of the account (e.g. Once a purchase has been completed, the accounting system 30 may also update the user profile 32 associated with the user, e.g., updating a purchase history and an offer/advertising profile. The accounting system 30 may send the offer/advertising profile to the point-of-sale computing device 10 and other points-of-sales, i.e. shops, whereby the point-of-sale computing device may then generate and send targeted offer/advertisements to the user 20 based on the user's purchase history. The user will have an option to accept or decline such targeted advertisements, and may also configure whether this occurs as part of the user's profile, that is, whether the user is willing to share this purchase information) (Section [0073] and [0083]).
Claims 4, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ejlersen/Pattanaik/Abrams, as applied to claims 1 and 16 above, in further view of US 2014024462 A1 (“Maenpaa”).
Per claims 4 and 17, Although Ejlersen/Pattanaik/Abrams discloses an identifier that is used to determine where to send the digital purchase receipt, Ejlersen/Pattanaik/Abrams do not specifically disclose:
wherein the account identifier identifies a digital wallet to which each individual item-specific digital purchase receipt data structure is to be transmitted.
However Maenpaa, in analogous art of transaction receipts, discloses:
wherein the account identifier identifies a digital wallet to which each individual item-specific digital purchase receipt data structure is to be transmitted (e.g. The user's loyalty card or customer account at the merchant could include the link to the user's digital receipt repository, in some cases associated with the user's digital wallet, where digital receipts can be sent so that when the loyalty card is scanned, the repository address becomes known) (Section [0042]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the identifier of Ejlersen/Pattanaik/Abrams to identify as user’s wallet instead of an address, as taught by Maenpaa, in order to achieve the predictable result of providing convenience to the user by allowing them easily view their payment receipts on their digital wallet application.
Per claim 18, Although Ejlersen/Pattanaik/Abrams/Maenpaa discloses all the limitations of claim 17 above. Pattanaik further discloses:
wherein each individual item-specific digital purchase receipt data structure is a block of a blockchain and the ledger is a blockchain ledger (e.g. The block generation module 320 maintains a blockchain network for the central service provider 150 and generates new blocks of transaction records 525 that can be appended to the blockchain network) (Section [0085]-[0087]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction receipt record storage of Ejlersen/Abrams/Maenpaa to include the use of the blockchain to store the transaction receipts by linking the receipts using hash values which inherently makes the digital receipts self-proving data structures, as taught by Pattanaik, in order to achieve the predictable result of easily verifying transactions and making the transactions more reliable because of a traceable lineage (See Pattanaik Paragraphs 5 and 6).
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US Publication Number 20200043045 A1 to Jurich teaches a system and method that stores transaction receipts in a user’s mobile wallet and allows them to choose whether or not they want to share their receipt information with third-parties to receive rewards. US Publication Number 20120290449 to Mullen teaches a system and method that provides payment receipts to a user’s mobile wallet in the form of a barcode which can be scanned to provide proof-of-purchase confirmation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY P SAX whose telephone number is (571) 272-2935. The examiner can normally be reached on M-F 8-4:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TIMOTHY PAUL SAX/Examiner, Art Unit 3698
Prosecution Insights