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 12/29/2025.
Claims
Claims 1 and 15 have been amended.
Claims 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 the combination of Ejlersen/Pattanaik/Balaraman fails to disclose that 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 (see applicant’s arguments/remarks pages 12 and 13).
The examiner respectfully disagrees. The newly added 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. The limitation is not positively recited as a step/function of the claim and does not affect the positively recited steps/functions in manipulative sense. Even assuming that the limitation holds patentable weight, Ejlersen discloses in sections [0054, [0077], and [0089] that when a user purchases an item from a merchant, receipt and warranty information are sent and stored in a receipt storage module and warranty storage module of an accounting system. Further in section [0039] and [0040] Ejlersen discloses that when a purchase includes a plurality of items, a separate electronic receipt is stored in an electronic record for each individual item. Furthermore, in section [0039], and [0081], Ejlersen discloses that the information bout the purchased item may comprise purchase data, purchase time, name of the point-of-sale computing device, location, price, product name, manufacturer name, product type, and the like. Therefore Ejlersen discloses “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”.
The applicant further argues that the combination of Ejlersen/Pattanaik/Balaraman fails to disclose (a) individual item-specific structures, (b) cryptographic signing, (c) self-proving capability, (d) traditional receipt data, and (e) distinction from transaction-level smart contracts (see applicant’s arguments/remarks pages 12 and 13).
However the examiner respectfully disagrees. As disclosed above, Ejlersen discloses (a) individual item-specific structures, (c) self-proving capability, (d) traditional receipt data and (e) distinction from transaction-level smart contracts. As disclosed above, Ejlersen discloses that individual receipt records are generated from each item purchased during a transaction and the individual receipt records and associated warranty information are stored in associated with the user’s profile. The receipt information can include traditional receipt information. Pattanaik discloses (b) cryptographic signing. Pattanaik in sections [0097] and [0098] discloses a transaction receipt module that stores transaction records on the blockchain and that the transaction receipt module includes hash values that represent prior transaction records on the blockchain. Further Pattanaik in sections [0089] and [0129] discloses that the transaction data can be stored in envelopes on the blockchain and that the envelopes can include digital signatures that are generated using a private key. Therefore the combination of Ejlersen and Pattanaik disclose (a) individual item-specific structures, (b) cryptographic signing, (c) self-proving capability, (d) traditional receipt data, and (e) distinction from transaction-level smart contracts.
The examiner has considered all of the applicant’s arguments but maintains the 103 rejection.
112
The examiner withdraws the previous 112 rejections due to the claim amendments.
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-9 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20160110821 A1 (“Ejlersen”) and US 20190164157 A1 (“Balaraman”) and US 20170366516 A1 (“Pattanaik”).
Per claims 1 and 15, Ejlersen teaches:
…for each item of a plurality of items in the purchase transaction, an item identifier and price data (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]);
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 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 (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.
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. Thereby, the invention provides a computer based system, where purchased items may automatically be entered into accounts, and where balancing of bookkeeping records is automatically carried out upon a purchase of such items. Further, the receipts are automatically electronically stored in a database, whereby a user at any time can check the receipts for possible errors with a local computing device such as a smart phone) (Section [0047]-[0054] and [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. Alternatively, validation can be by way of the service provider, such that approval of the purchase by the service provider additionally is a validation of the identity of the purchaser so that the transmission of the electronic receipt, information and/or warranty can proceed) (Section [0078]).
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 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 form transaction-level smart contracts.
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. For example, referring to FIG. 5B, the hash value included in the transaction receipt can be the root hash (e.g., hash.sub.0,1,2,3 555) of the Merkle tree that encompasses all transactions in the block. In various embodiments, the transaction receipt module 325 further includes hash values representing previous transactions in the block. For example, referring to FIG. 5A, the block of transaction records 525 may solely include transaction records 540 corresponding to transactions included in transaction requests placed by the client device 110. If transaction record 3 (540C) corresponds to the most recently received transaction request sent by client device 110, then the transaction receipt module 325 includes the hash values of hash.sub.0 (502), hash.sub.1 (505A), and hash.sub.2 (505B) that each represent a prior transaction record 540 in the block) (Section [0097]-[0098]);
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 form transaction-level smart contracts (e.g. Each envelope 515 includes various details associated with the corresponding payload 520. 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) (Section [0084] and [0129]).
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 transaction receipt storage of Ejlersen to include the use of the blockchain to store the transaction receipts and linking the receipts using hash values, 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:
electronically receiving an account identifier associated with a purchase transaction…;
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 that the verifiable claim is original, has not been tampered with, and came from a specific merchant.
However Balaraman, in analogous art of payment transactions, discloses:
electronically receiving an account identifier associated with a purchase transaction… (e.g. Each smart contract may be an executable that writes data to the blockchain in a predetermined format based on predetermined function parameters passed by an API call. The smart contracts may take as an input the fields included for writing during the transaction authorization process, such as, for example, a user ID, a merchant ID, transaction data (e.g., payment amount, etc.), public keys, or the like) (Section [0025], [0028], [0035], and [0040]);
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 that the verifiable claim is original, has not been tampered with, and came from a specific merchant (e.g. Blockchain network 150 may be a distributed database that maintains records in a readable manner and that is resistant to tampering. The blockchain may comprise a system of blocks containing data that are interconnected by reference to the previous block. The blocks can hold file transfer data, smart contract data, and/or other information as desired. Each block may link to the previous block and may include a timestamp. When implemented in support of system 100, the blockchain may serve as an immutable log for transactions and related contracts and processes) (Section [0020]-[0021]).
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 transaction receipt generation and storing of Ejlersen/Pattanaik to include the use of a blockchain to ensure tamper proof verification that a transaction occurred between a user and merchant, as taught by Balaraman, in order to achieve the predictable result of providing enhanced security, data integrity, traceability, and immutability that are provided by blockchain technology.
Per claim 2, Ejlersen/Pattanaik/Balaraman 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. The payload 520 of a transaction record 540 includes details of an executed transaction. For example, details of a transaction can include the attributes of a transaction, which was described above as including an identification of a first party, an identification of a second party, the asset type, the quantity of asset to be transferred, the conditions of the transaction, and a timestamp of the transaction) (Section [0059], [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/Balaraman to include a user account identifier, as taught by Pattanaik, in order to achieve the predictable result of making it easier to trace all the transactions of a user (See Pattanaik paragraph 59).
Per claim 3, Ejlersen/Pattanaik/Balaraman discloses all the limitations of claim 1 above. Balaraman further discloses:
Balaraman et al. continues to teach wherein the account identifier is an address of the location associated with the account identifier to which each data structure is transmitted [0028; 0037; 0044].
The Examiner notes, “wherein…is an address of the location associated with the account identifier…”, recites non-functional descriptive material and is not functionally related to the memory in which it is stored, nor does it distinguish the claimed invention from the prior art (In re Gulack, 217 USPQ 401 (Fed. Cir. 1983), In re Ngai, 70 USPQ2d (Fed. Cir. 2004), In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994), Ex parte Nehls 88 USPQ2d 1883 (BAPI 2008)).
The motivation to combine Balaraman with Ejlersen/Pattanaik is disclosed above with reference to claims 1 and 15.
Per claims 4 and 17, Ejlersen/Pattanaik/Balaraman discloses all the limitations of claims 1 and 15 above. Balaraman et al. continues to teach wherein the account identifier identifies a digital wallet to which each data structure is to be transmitted [0037; 0040; 0044].
The motivation to combine Balaraman with Ejlersen/Pattanaik is disclosed above with reference to claims 1 and 15.
Per claims 5 and 16, Ejlersen/Pattanaik/Balaraman discloses all the limitations of claims 1 and 15 above. Balaraman et al. continues to teach further comprising: storing each data structure over a network location to a ledger [Abstract; 0021; 0022; 0045].
The motivation to combine Balaraman with Ejlersen/Pattanaik is disclosed above with reference to claims 1 and 15.
Per claims 6 and 18, Ejlersen/Pattanaik/Balaraman discloses all the limitations of claims 5 and 17 above. Balaraman et al. continues to teach wherein each data structure is a block of a blockchain and the ledger is a blockchain ledger [Abstract; Abstract; 0021; 0022; 0045].
The Examiner notes, “wherein…is a block…”, recites non-functional descriptive material and is not functionally related to the memory in which it is stored, nor does it distinguish the claimed invention from the prior art (In re Gulack, 217 USPQ 401 (Fed. Cir. 1983), In re Ngai, 70 USPQ2d (Fed. Cir. 2004), In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994), Ex parte Nehls 88 USPQ2d 1883 (BAPI 2008)).Also, the language, “wherein…the ledger is a blockchain ledger”, recites a structural limitation and does not gain patentable weight in a method claim. It has been held that to be entitled to such weight in method claims, the recited structural limitations therein must affect the method in a manipulative sense and not amount to the mere claiming of a use of a particular structure (Ex parte Pfeiffer, 135 USPQ 31 ([Bd. App.] 1961)).
The motivation to combine Balaraman with Ejlersen/Pattanaik is disclosed above with reference to claims 1 and 15.
Per claims 7 and 19, Ejlersen/Pattanaik/Balaraman discloses all the limitations of claims 1 and 15 above. Balaraman et al. continues to teach wherein the data structure of an item is an electronic proof of purchase of the respective item [0023; 0041; 0040; 0044; 0045].
The Examiner notes, “wherein…is an electronic proof of purchase of the respective item”, recites non-functional descriptive material and is not functionally related to the memory in which it is stored, nor does it distinguish the claimed invention from the prior art (In re Gulack, 217 USPQ 401 (Fed. Cir. 1983), In re Ngai, 70 USPQ2d (Fed. Cir. 2004), In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994), Ex parte Nehls 88 USPQ2d 1883 (BAPI 2008)). The motivation to combine Balaraman with Ejlersen/Pattanaik is disclosed above with reference to claims 1 and 15.
The motivation to combine Balaraman with Ejlersen/Pattanaik is disclosed above with reference to claims 1 and 15.
Per claim 8, Ejlersen/Pattanaik/Balaraman discloses all the limitations of claim 1 above. Balaraman et al. continues to teach wherein the data structure includes further data of the transaction including data identifying the merchant and a date of the purchase transaction [Abstract; 0028].
The Examiner notes, “wherein…data identifying the merchant and a date of the purchase transaction”, recites non-functional descriptive material and is not functionally related to the memory in which it is stored, nor does it distinguish the claimed invention from the prior art (In re Gulack, 217 USPQ 401 (Fed. Cir. 1983), In re Ngai, 70 USPQ2d (Fed. Cir. 2004), In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994), Ex parte Nehls 88 USPQ2d 1883 (BAPI 2008)).
The motivation to combine Balaraman with Ejlersen/Pattanaik is disclosed above with reference to claims 1 and 15.
Per claims 9 and 20, Ejlersen/Pattanaik/Balaraman discloses all the limitations of claims 1 and 15 above. Balaraman et al. continues to teach further comprising: receiving a payment with regard to at least one of the transmitted data structures subsequent to the respective data structure having been forwarded to an entity as authorized by a holder of the account [0043].
The motivation to combine Balaraman with Ejlersen/Pattanaik is disclosed above with reference to claims 1 and 15.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to TIMOTHY SAX whose telephone number is 571-272-2935. The Examiner can normally be reached on M-F 8-4:30. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575.
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.
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.
/TPS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698