DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This office action is in response to the RCE filed on 1/28/2026.
Claims 2, 13, and 20 have been amended.
Claims 2-21 are pending and have been examined.
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 1/28/2026 has been entered.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 2-21 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 9-12, 14, and 17-20 of US Patent No. 12175490. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims are directed to the same subject matter, perform the equivalent functions and a person of ordinary skill in the art would not be free to practice one of the claimed inventions without infringing upon the other. The claimed invention is merely broader than the patented invention above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 2-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 2-19 are directed to methods. Claims 20 and 21 are directed to a system. Thus, on their face they fall within the four statutory categories of patentable subject matter.
Step 2A prong 1:
The following limitations, when considered individually and as an ordered combination, are merely descriptive of abstract concepts:
Claim 2:
receiving, by an entity, a unique account identifier within a transaction involving an account of the unique account identifier;
calculating by the entity a value based on the transaction for transfer to an account of the unique account identifier;
generating by the entity a data structure to transfer the calculated value to the account of the account identifier, wherein the data structure includes a hash value generated from data of the data structure and from sequencing data comprising a pointer to a previous data structure;
cryptographically signing by the entity the data structure with a private key, wherein the data structure is transmitted to a plurality of entities maintaining copies of a replicated trusted ledger, and wherein the data structure is written to each copy of the replicated trusted ledger when there are no objections by the plurality of entities after receipt of the data structure, wherein the replicated trusted ledger maintains point values redeemable at multiple entities without regard to which entity credited the points; and
transmitting the data structure to the entity where a replicated trusted ledger used to maintain value balances is maintained, wherein the hash value and the sequencing data enable detection of of tempering with the replicated trusted ledger.
Claim 13:
receiving transaction data at a point of sale (POS) entity including a unique ledger account identifier for a purchase transaction;
executing, by the POS entity, a purchase transaction successfully;
calculating, by the POS entity, a non-monetary point value for awarding to an account of the unique ledger account identifier based on transaction factors;
writing, by the POS entity, to a replicated trusted ledger data including: the unique ledger account identifier, the non-monetary point value as calculated, a pointer to a previous data entry, and a hash value generated from a data payload comprising point granting data or redemption data; and
wherein writing comprises transmitting the replicated trusted ledger data to a plurality of entities where copies of a replicated trusted ledger are maintained, and wherein the replicated trusted ledger data is written to each copy of the replicated trusted ledger when there are no objections by the plurality of entities after receipt of the replicated trusted ledger data;
wherein the replicated trusted ledger is used to maintain account point values of customers for the plurality of entities, the point values redeemable at each of the plurality of entities without regard to which entity credited any or all of the point values; and
securing access to the replicated trusted ledger through private/public key pairs, wherein the pointer to the previous data entry and the hash value enable detection of tampering based on sequencing of corresponding data entires.
Claim 20:
Receiving a unique ledger account identifier for a purchase transaction;
executing the purchase transaction successfully;
calculating a non-monetary point value for awarding to an account of the unique account identifier based on transaction factors;
writing a data structure to a replicated trusted ledger: the data structure comprises the unique ledger account identifier, the non-monetary point value as calculated, a pointer to a previous data entry, and a hash value from a data payload comprising point granting data or redemption data;
wherein writing comprises transmitting the data structure to a plurality of entities where copies of the replicated trusted ledger are maintained, and wherein the data structure is written to each copy of the replicated trusted ledger when there are no objections by the plurality of entities after receipt of the data structure;
wherein the replicated trusted ledger is used to maintain account point values of customers for the plurality of entities, the account point values redeemable at each of the plurality of entities without regard to which entity credited any or all of the account point values; and
securing access to the replicated trusted ledger through private/public key pairs, wherein the pointer to the previous data entry and the hash value enable detection of tampering based on sequencing data..
The following dependent claim limitations, when considered individually and as an ordered combination, are merely further descriptive of abstract concepts:
Claim 4:
wherein calculating the value comprises determining a point value based on at least one of: a monetary value of the transaction, a fixed point value per transaction, a fixed point value per item in the transaction, and a loyalty status.
Claim 6:
wherein signing the data structure comprises cryptographically signing with a private key of a private/public key pair.
Claim 7:
wherein transmitting comprises transmitting to multiple entities maintaining copies of the replicated trusted ledger.
Claim 8:
wherein the data structure is written to each copy of the replicated trusted ledger when there are no objections after receipt.
Claim 9:
wherein the unique account identifier is a identifier (DID) known within a ledger.
Claim 10:
wherein the replicated trusted ledger maintains point values redeemable at multiple entities without regard to which entity credited points.
Claim 11:
further comprising: transmitting a message communicating a value transfer using the unique account identifier as an address.
Claim 12:
further comprising: securing access to the replicated trusted ledger through key-based encryption.
Claim 15:
wherein calculating comprises determining the non- monetary point value based on a combination of: a monetary value, a fixed point value, and a loyalty status.
Claim 17:
wherein securing comprises restricting access through key-based encryption.
Claim 18:
further comprising: maintaining the replicated trusted ledger on distributed nodes to ensure data integrity.
Claim 19:
further comprising: detecting tampering based on sequencing data of corresponding data entries.
The claims provide a manner of monitoring transaction and provider a user with a reward amount and storing the reward in a user account. Thus, when considered individually and as an ordered combination, the claims embody certain methods of organizing human activity. Specifically, such activity is in the form of commercial interactions (in the form of advertising, marketing or sales activities or behaviors).
Step 2A prong 2: This judicial exception is not integrated into a practical application. The claims recite the following additional elements: computing system of an entity with memory(claim 2); wherein receiving the unique account identifier comprises receiving the unique account identifier in a radio signal via a near field communication (NFC) device (claim 3); wherein generating the data structure comprises generating a block of a blockchain (claim 5); multiple/plurality of computing systems (claim 1, 7, 13, 20); digital identifier (claim 9); blockchain (claim 9, 13, 20); point of sale device (claim 13); blockchain account identifier (claim 13, 20); blockchain ledger (claim 13, 18, 20); block (claim 13, 19, 20); network (claim 13, 20); wherein receiving comprises obtaining the unique blockchain account identifier via a near field communication device integrated with the POS device (claim 14); wherein writing comprises utilizing blockchain protocols (claim 16); POS device including a network interface device, a computer processor, and memory storing instructions (claim 20); wherein the POS device includes a near field communication (NFC) device configured to receive the unique blockchain account identifier in a radio signal. (claim 21);
The computing system of an entity with memory, multiple/plurality of computing systems, point of sale device, network, POS device including a network interface device, a computer processor, and memory storing instructions are recited at a high level of generality and amount to mere instructions to “apply it” (the abstract idea) using generic computing components. The computing devices are merely used to send and receive data (receiving, transmitting) and process data (calculating, generating, determining, signing, securing, executing, writing, maintaining). Nothing in the claims improves upon computers themselves, technology, or a technical field (See MPEP 2106.05(f)).
The limitations including wherein receiving the unique account identifier comprises receiving the unique account identifier in a radio signal via a near field communication (NFC) device, wherein receiving comprises obtaining the unique blockchain account identifier via a near field communication device integrated with the POS device, and wherein the POS device includes a near field communication (NFC) device configured to receive the unique blockchain account identifier in a radio signal are recited at a high level of generality. The use of NFC is merely provided as the mechanism to send the data between devices. Nothing in the claims improves upon NFC technology or a technical field. Thus, the high level use of NFC as the means to send data does not go beyond the “apply it” level (See MPEP 2106.05(f)).
The blockchain and blockchain ledger are recited at a high level generality. Nothing in the claims improves upon blockchain technology or the technical field. The claims merely implement blockchain at a high level using the applicant’s data of choice. Thus, the high level use of blockchain does not go beyond the “apply it” level of implementation (See MPEP 2106.05(f)).
The limitations including a digital identifier, wherein generating the data structure comprises generating a block of a blockchain, blockchain account identifier, a block, and wherein writing comprises utilizing blockchain protocols merely provide a general link to a particular technological environment. The identifier is merely in a computing environment and thus is digital. Further, the use of a “block” is merely provides that the data recorded is used in a blockchain. Nothing in the claims improves upon blocks or blockchain technology (See MPEP 2106.05(h)).
Accordingly, when considered both individually and as an ordered combination, the additional elements do not impose any meaningful limits on practicing the abstract idea.
Step 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Similarly, as above with regard to practical application, the additional elements when considered both individually and as an ordered combination, do not provide an inventive concept as they merely provide generic computing components used as a tool to implement the abstract idea and provide a general link to a particular technological environment or field of use.
As a result, the claims are not patent eligible.
Claim Rejections - 35 USC § 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, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 2, 4-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Postrel (US 2019/0156363) in view of Davis (US 2018/0082294) in view of Polcha et al (US 20190058593)
As per Claim 2:
Postrel teaches:
A method comprising:
calculating on the computing system of the entity a value based on the transaction for transfer to an account of the unique account identifier; (paragraph [0046] Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). [0047] FIG. 3 is a flowchart of a general process for executing a transaction with a blockchain reward ledger in accordance with the preferred embodiment of the invention. In step 302, the consumer 102 executes a reward-related transaction with a party as shown in FIG. 1. For example, the consumer 102 purchases a product from a merchant 112, for which he will receive reward points that will be added to his blockchain reward ledger 100. In step 304, as part of the purchase transaction, the consumer presents to the merchant a digital wallet that contains the blockchain reward ledger 100.)
generating on the computing system of the entity a data structure in memory to transfer the calculated value to the account of the account identifier, wherein the data structure includes a hash value generated from data of the data structure and from sequencing data comprising a pointer to a previous data structure; (Fig. 2; paragraph [0046] Block ID 202 acts as a unique identifier for each block in the ledger 100. Hash 204 is a hash pointer as a link to a previous block so that a sequence of block events may be provided. Timestamp 206 provides date and time information for the entry of the bock into the ledger 100. The remaining fields comprise the transaction data as follows. Transaction type 208 sets forth the type of reward transaction occurring in the block (e.g. award of rewards, redemption of rewards, exchange of rewards, etc.). Rewards issuer 210 identifies the issuer of the rewards that are either being awarded or redeemed in the block (e.g. the merchant). Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). Rewards aggregated 216 is a field or series of fields that may be used to identify rewards that are being aggregated together, if the block is for a reward aggregation transaction (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio). [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
PNG
media_image1.png
130
814
media_image1.png
Greyscale
wherein the data structure is transmitted to a plurality of computing systems maintaining copies of a replicated trusted ledger, and wherein the data structure is written to each copy of the replicated trusted ledger when there are no objections by the plurality of computing systems after receipt of the data structure, wherein the replicated trusted ledger maintains point values redeemable at multiple entities without regard to which entity credited the points (paragraph [0030] The permission routine requests permission to add a reward transaction block to the blockchain ledger by ascertaining the identity of all parties with an interest in the reward transaction; requesting permission from all identified parties to add the reward transaction block to the blockchain ledger; if any of the identified parties denies permission, then requesting an override from a system administrator; if all of the identified parties grants permission, or if all permission denials are overridden by the system administrator, then granting permission to add a reward transaction block to the blockchain ledger. [0046] Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). Rewards redeemed 214 identifies, both quantitatively and qualitatively, the rewards that have been redeemed by the consumer 102 in the block, if the block is for a reward-redeeming transaction (e.g. a purchase of a product from the merchant for which the consumer 102 uses 10,000 reward points to pay for the product from the merchant). Rewards aggregated 216 is a field or series of fields that may be used to identify rewards that are being aggregated together, if the block is for a reward aggregation transaction (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio). [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
and transmitting the data structure to the computing system of the entity where a replicated trusted ledger used to maintain value balances is maintained, (paragraph [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
Postrel does not expressly teach a unique blockchain identifier and securing access to the ledger using private/public key pairs.
Davis teaches:
receiving, by a computing system of an entity, a unique account identifier within a transaction involving an account of the unique account identifier; (paragraph [0027] In some configurations, transactions recorded in the blockchain may include a destination address and a currency amount, such that the blockchain records how much currency is attributable to a specific address. In some instances, additional information may be captured, such as a source address, timestamp, etc. [0030] The computing device of the payer 102 may digitally sign the transaction request using an encryption key stored in the computing device, such as stored in an electronic wallet. The digital signature may be, include, or otherwise be associated with an address that is generated using the encryption key, which may be associated with blockchain currency in the blockchain, and may be used to transfer blockchain currency to an address associated with the payee 104 and/or their computing device. (See also [0029], [0034], [0038], [0044], [0059]))
cryptographically signing on the computing system of the entity the data structure with a private key; (paragraph [0039] In some embodiments, the data element reserved for private use, or an alternative data element reserved for private use in the transaction message, may include input information associated with the payer 102. The input information may include a transaction identifier associated with a prior blockchain transaction as well as a public key associated with the payer 102 and a digital signature. The digital signature may be generated using a private key corresponding to the public key and may be used for verification of ownership of a blockchain currency amount associated with the transaction identifier by the payer 102, such that the payer 102 is authorized to transfer the blockchain currency in the requested transaction. See also [0030], [0043], [0068], [0069])
It would have been obvious to one of ordinary skill in the art to include a unique blockchain identifier and securing access to the ledger using private/public key pairs as taught by Davis with the blockchain reward ledger of Postrel in order to maintain their privacy and help reduce the likelihood of fraud due to theft of their information (paragraph [0002]).
Postrel in view of Davis does not expressly teach wherein the hash value and the sequencing data enable detection of tampering with the replicated ledger.
Polcha teaches:
wherein the hash value and the sequencing data enable detection of tampering with the replicated ledger ([0070] Each block, such as first block 210 and second block 220 in FIG. 2B, may include data regarding recent transactions and/or contents relating to computer readable information, linking data that links one block 220 to a previous block 210 in the blockchain, proof-of-work data that ensures that the state of the block chain 305 is valid, and is endorsed/verified by the system. The confirmed transactions of the blockchain can be performed using cryptography to ensure the integrity and the chronological order of the blockchain are enforced and can be independently verified by each node of the blockchain.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein the hash value and the sequencing data enable detection of tampering with the replicated ledger as taught by Polcha with the transaction blockchain of Postrel in view of Davis in order tor ensure that the state of the block chain is valid, and is endorsed/verified by the system ([0070]).
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 4:
Postrel further teaches:
wherein calculating the value comprises determining a point value based on at least one of: a monetary value of the transaction, a fixed point value per transaction, a fixed point value per item in the transaction, and a loyalty status (paragraph [0046] Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant (see also [0049])).
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 5:
Postrel further teaches:
wherein generating the data structure comprises generating a block of a blockchain. (Fig. 2; paragraph [0046] Block ID 202 acts as a unique identifier for each block in the ledger 100. Hash 204 is a hash pointer as a link to a previous block so that a sequence of block events may be provided. Timestamp 206 provides date and time information for the entry of the bock into the ledger 100. The remaining fields comprise the transaction data as follows. Transaction type 208 sets forth the type of reward transaction occurring in the block (e.g. award of rewards, redemption of rewards, exchange of rewards, etc.). Rewards issuer 210 identifies the issuer of the rewards that are either being awarded or redeemed in the block (e.g. the merchant). Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). Rewards aggregated 216 is a field or series of fields that may be used to identify rewards that are being aggregated together, if the block is for a reward aggregation transaction (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio). [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
PNG
media_image1.png
130
814
media_image1.png
Greyscale
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 6:
Postrel in view of Polcha does not expressly teach wherein signing the data structure comprises cryptographically signing with a private key of a private/public key pair.
Davis further teaches:
wherein signing the data structure comprises cryptographically signing with a private key of a private/public key pair. (paragraph [0039] In some embodiments, the data element reserved for private use, or an alternative data element reserved for private use in the transaction message, may include input information associated with the payer 102. The input information may include a transaction identifier associated with a prior blockchain transaction as well as a public key associated with the payer 102 and a digital signature. The digital signature may be generated using a private key corresponding to the public key and may be used for verification of ownership of a blockchain currency amount associated with the transaction identifier by the payer 102, such that the payer 102 is authorized to transfer the blockchain currency in the requested transaction. See also [0030], [0043], [0068], [0069])
It would have been obvious to one of ordinary skill in the art to include wherein signing the data structure comprises cryptographically signing with a private key of a private/public key pair as taught by Davis with the blockchain reward ledger of Postrel in view of Polcha in order to maintain their privacy and help reduce the likelihood of fraud due to theft of their information (paragraph [0002]).
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 7:
Postrel further teaches:
wherein transmitting comprises transmitting to multiple computing systems maintaining copies of the replicated trusted ledger (paragraph [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 8:
Postrel further teaches:
wherein the data structure is written to each copy of the replicated trusted ledger when there are no objections after receipt. (paragraph [0050] Thus, at step 404, the details of the purchase transaction, and/or the reward points sought to be awarded as a result of the transaction, will be communicated by means known in the art to each interested party. At step 406, if none of the parties denies the proposed transaction, then permission is granted for the transaction to proceed at step 408, and the process returns at step 416 to the main process step 310. [0052] FIG. 4 as described above is that permission is not granted, then permission is denied for access to the blockchain ledger at step 314, and (optionally) the denial of permission is recorded in the ledger 100. If, however, the result of the permission process is that permission is granted, then a new transaction block is added at step 312 to the blockchain reward ledger 100 as shown in the sub-process of FIG. 5. [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 9:
Postrel in view of Polcha does not expressly teach wherein the unique account identifier is a digital identifier (DID) known within a blockchain.
Davis further teaches:
wherein the unique account identifier is a digital identifier (DID) known within a blockchain. (paragraph [0004] The nature of blockchain currencies is that the access to any given address to which currency is associated is controlled based on possession of electronic credentials, often referred to as an electronic wallet, e-wallet, or simply “wallet. [0027] In some configurations, transactions recorded in the blockchain may include a destination address and a currency amount, such that the blockchain records how much currency is attributable to a specific address. In some instances, additional information may be captured, such as a source address, timestamp, etc.)
It would have been obvious to one of ordinary skill in the art to include wherein the unique account identifier is a digital identifier (DID) known within a blockchain as taught by Davis with the blockchain reward ledger of Postrel in view of Polcha in order to maintain their privacy and help reduce the likelihood of fraud due to theft of their information (paragraph [0002]).
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 10:
Postrel further teaches:
wherein the replicated trusted ledger maintains point values redeemable at multiple entities without regard to which entity credited points (paragraph [0023] In one embodiment, this rewards exchange methodology, in which reward points are exchanged from one issuer's points into another issuer's points, may be extended so that reward points are aggregated from various issuers into one reward exchange account. This would operate in a similar manner to the reward exchange and aggregation methodology described in my '640 patent mentioned above, except that the reward accounts are not stored in various server computers on the internet, but rather those accounts are located in a single blockchain ledger that would be part of the user's digital wallet. [0046] Rewards aggregated 216 is a field or series of fields that may be used to identify rewards that are being aggregated together, if the block is for a reward aggregation transaction (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio).
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 11:
Postrel in view of Polcha does not expressly teach transmitting a message communicating a value transfer using the unique account identifier as an address.
Davis further teaches:
transmitting a message communicating a value transfer using the unique account identifier as an address. (paragraph [0070] The processing unit 304 may then generate a transaction message. The transaction message may include a data element reserved for private use that may include the destination address, the network identifier, and the blockchain currency amount. [0071] The issuer 112 may include a transmitting unit 306 configured to transmit data over one or more networks via one or more network protocols. The transmitting unit 206 may submit the generated transaction message to the processing server 110 for processing the blockchain transaction using the methods and systems discussed herein.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include transmitting a message communicating a value transfer using the unique account identifier as an address as taught by Davis with the blockchain reward ledger of Postrel in view of Polcha in order to maintain their privacy and help reduce the likelihood of fraud due to theft of their information (paragraph [0002]).
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 12:
Postrel in view of Polcha does not expressly teach further comprising: securing access to the replicated trusted ledger through key-based encryption.
Davis further teaches:
further comprising: securing access to the replicated trusted ledger through key-based encryption (paragraph [0039] In some embodiments, the data element reserved for private use, or an alternative data element reserved for private use in the transaction message, may include input information associated with the payer 102. The input information may include a transaction identifier associated with a prior blockchain transaction as well as a public key associated with the payer 102 and a digital signature. The digital signature may be generated using a private key corresponding to the public key and may be used for verification of ownership of a blockchain currency amount associated with the transaction identifier by the payer 102, such that the payer 102 is authorized to transfer the blockchain currency in the requested transaction. See also [0030], [0043], [0068], [0069], [0079])
It would have been obvious to one of ordinary skill in the art to include further comprising: securing access to the replicated trusted ledger through key-based encryption as taught by Davis with the blockchain reward ledger of Postrel in view of Polcha in order to maintain their privacy and help reduce the likelihood of fraud due to theft of their information (paragraph [0002]).
Claim(s) 13, 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Postrel (US 2019/0156363) in view of Davis (US 2018/0082294) in view of Polcha et al (US 20190058593) in view of Cantrell et al (US 2019/0311343)
As per Claim 13:
Postrel teaches:
A method comprising:
receiving transaction data {…} for a purchase transaction;(paragraph [0047] In step 302, the consumer 102 executes a reward-related transaction with a party as shown in FIG. 1. For example, the consumer 102 purchases a product from a merchant 112, for which he will receive reward points that will be added to his blockchain reward ledger 100. In step 304, as part of the purchase transaction, the consumer presents to the merchant a digital wallet that contains the blockchain reward ledger 100. The {…} indicate a modification to the claim language to show what is expressly taught by Postrel. Limitations regarding the unique identifying the unique blockchain identifier and the POS device will be addressed below.)
executing {…} a purchase transaction successfully; (paragraph [0047] In step 302, the consumer 102 executes a reward-related transaction with a party as shown in FIG. 1. For example, the consumer 102 purchases a product from a merchant 112, for which he will receive reward points that will be added to his blockchain reward ledger 100. In step 304, as part of the purchase transaction, the consumer presents to the merchant a digital wallet that contains the blockchain reward ledger 100.
calculating {…} a non-monetary point value for awarding to an account of the unique blockchain account identifier based on transaction factors; (paragraph [0046] Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). [0047] FIG. 3 is a flowchart of a general process for executing a transaction with a blockchain reward ledger in accordance with the preferred embodiment of the invention. In step 302, the consumer 102 executes a reward-related transaction with a party as shown in FIG. 1. For example, the consumer 102 purchases a product from a merchant 112, for which he will receive reward points that will be added to his blockchain reward ledger 100. In step 304, as part of the purchase transaction, the consumer presents to the merchant a digital wallet that contains the blockchain reward ledger 100.)
writing, {…} to a replicated trusted blockchain ledger data including: {…} the non-monetary point value as calculated, a pointer to a previous block, and a hash value generated from a data payload comprising point granting data or redemption data; and (Fig. 2; paragraph [0046] Block ID 202 acts as a unique identifier for each block in the ledger 100. Hash 204 is a hash pointer as a link to a previous block so that a sequence of block events may be provided. Timestamp 206 provides date and time information for the entry of the bock into the ledger 100. The remaining fields comprise the transaction data as follows. Transaction type 208 sets forth the type of reward transaction occurring in the block (e.g. award of rewards, redemption of rewards, exchange of rewards, etc.). Rewards issuer 210 identifies the issuer of the rewards that are either being awarded or redeemed in the block (e.g. the merchant). Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). Rewards aggregated 216 is a field or series of fields that may be used to identify rewards that are being aggregated together, if the block is for a reward aggregation transaction (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio). [0052] At step 502, the timestamp of the transaction (date, time) is logged, and at step 504, a hash of all data in the transaction block is calculated. [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates. Claim 3 - calculating a hash of reward transaction data,)
PNG
media_image1.png
130
814
media_image1.png
Greyscale
wherein writing comprises transmitting the replicated trusted blockchain ledger data to a plurality of computing systems where copies of a replicated trusted blockchain ledger are maintained, and wherein the replicated trusted blockchain ledger data is written to each copy of the replicated trusted blockchain ledger when there are no objections by the plurality of computing systems after receipt of the replicated trusted blockchain ledger data; (paragraph [0030] The permission routine requests permission to add a reward transaction block to the blockchain ledger by ascertaining the identity of all parties with an interest in the reward transaction; requesting permission from all identified parties to add the reward transaction block to the blockchain ledger; if any of the identified parties denies permission, then requesting an override from a system administrator; if all of the identified parties grants permission, or if all permission denials are overridden by the system administrator, then granting permission to add a reward transaction block to the blockchain ledger. [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
wherein the replicated trusted blockchain ledger is used to maintain account point values of customers for the plurality of computing systems, the point values redeemable at each of the plurality of computing systems without regard to which computing system credited any or all of the point values (paragraph [0030] The permission routine requests permission to add a reward transaction block to the blockchain ledger by ascertaining the identity of all parties with an interest in the reward transaction; requesting permission from all identified parties to add the reward transaction block to the blockchain ledger; if any of the identified parties denies permission, then requesting an override from a system administrator; if all of the identified parties grants permission, or if all permission denials are overridden by the system administrator, then granting permission to add a reward transaction block to the blockchain ledger. [0046] Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). Rewards redeemed 214 identifies, both quantitatively and qualitatively, the rewards that have been redeemed by the consumer 102 in the block, if the block is for a reward-redeeming transaction (e.g. a purchase of a product from the merchant for which the consumer 102 uses 10,000 reward points to pay for the product from the merchant). Rewards aggregated 216 is a field or series of fields that may be used to identify rewards that are being aggregated together, if the block is for a reward aggregation transaction (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio). [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
Postrel does not expressly teach a unique blockchain identifier and securing access to the ledger using private/public key pairs.
Davis teaches:
{receiving transaction data} including a unique blockchain account identifier; (paragraph [0027] In some configurations, transactions recorded in the blockchain may include a destination address and a currency amount, such that the blockchain records how much currency is attributable to a specific address. In some instances, additional information may be captured, such as a source address, timestamp, etc. [0030] The computing device of the payer 102 may digitally sign the transaction request using an encryption key stored in the computing device, such as stored in an electronic wallet. The digital signature may be, include, or otherwise be associated with an address that is generated using the encryption key, which may be associated with blockchain currency in the blockchain, and may be used to transfer blockchain currency to an address associated with the payee 104 and/or their computing device. (See also [0029], [0034], [0038], [0044], [0059]))
{writing to the blockchain} the unique blockchain account identifier (paragraph [0027] In some configurations, transactions recorded in the blockchain may include a destination address and a currency amount, such that the blockchain records how much currency is attributable to a specific address. In some instances, additional information may be captured, such as a source address, timestamp, etc. [0029] In the system 100, a blockchain transaction may occur between the computing device of a payer 102 and the computing device of a payee 104. As used herein, “payer” may refer to a computing device and/or a consumer that is funding a payment transaction, and “payee” may refer to a computing device and/or a consumer that is receiving payment in a payment transaction. The blockchain transaction may be processed by one or more computing devices that comprise a blockchain network 106. The blockchain network may receive at least a destination address (e.g., associated with the payer 104) and an amount of blockchain currency and may process the transaction by generating a block that is added to a blockchain that includes a record for the transaction. [0060] Each transaction data entry 214 may include a transaction message, transaction notification, and/or data included therein, such as transaction times and/or dates, transaction identifiers, source addresses, destination addresses, transaction amounts, merchant data, consumer data, product data, loyalty data, reward data, etc.)
securing access to the replicated trusted blockchain ledger through private/public key pairs. (paragraph [0039] In some embodiments, the data element reserved for private use, or an alternative data element reserved for private use in the transaction message, may include input information associated with the payer 102. The input information may include a transaction identifier associated with a prior blockchain transaction as well as a public key associated with the payer 102 and a digital signature. The digital signature may be generated using a private key corresponding to the public key and may be used for verification of ownership of a blockchain currency amount associated with the transaction identifier by the payer 102, such that the payer 102 is authorized to transfer the blockchain currency in the requested transaction. See also [0030], [0043], [0068], [0069])
It would have been obvious to one of ordinary skill in the art to include a unique blockchain identifier and securing access to the ledger using private/public key pairs as taught by Davis with the blockchain reward ledger of Postrel in order to maintain their privacy and help reduce the likelihood of fraud due to theft of their information (paragraph [0002]).
Postrel in view of Davis does not expressly teach wherein the pointer to the previous block and the hash value enable detection of tampering based on sequencing of corresponding blocks.
Polcha teaches:
wherein the pointer to the previous block and the hash value enable detection of tampering based on sequencing of corresponding blocks. ([0070] Each block, such as first block 210 and second block 220 in FIG. 2B, may include data regarding recent transactions and/or contents relating to computer readable information, linking data that links one block 220 to a previous block 210 in the blockchain, proof-of-work data that ensures that the state of the block chain 305 is valid, and is endorsed/verified by the system. The confirmed transactions of the blockchain can be performed using cryptography to ensure the integrity and the chronological order of the blockchain are enforced and can be independently verified by each node of the blockchain.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein the pointer to the previous block and the hash value enable detection of tampering based on sequencing of corresponding blocks as taught by Polcha with the transaction blockchain of Postrel in view of Davis in order tor ensure that the state of the block chain is valid, and is endorsed/verified by the system ([0070]).
Postrel in view of Davis in view of Polcha does not expressly teach using a POS device.
Cantrell teaches:
{implementing transactions and blockchain activities} by the POS device over a network ([0017] The system comprises a plurality of point of sale (POS) systems comprising nodes of a distributed digital ledger, wherein the distributed digital ledger comprises ownership records associated with a plurality of user accounts that are updated and verified collectively by the plurality of POS systems, and wherein the distributed digital ledger is configured to be used by one or more of the plurality of POS systems to authorize transfer of items specified in the ownership records to customers. [0018] The system 100 includes a plurality of POS systems 120 communicating over a network via a distributed digital ledger 110. The distributed digital ledger 110 is further accessed by one or more user device 130. [0019] The distributed ledger may be stored on a plurality of POS systems 120, user devices 130, and/or other processor-based devices. In some embodiments, the nodes of the distributed digital ledger comprise systems associated with retailers, manufacturers, suppliers, and/or customers. In some embodiments, the distributed digital ledger 110 comprises one or more of a shared ledger, a distributed database, a hash chain database, a blockchain database, and a blockchain-based database. [0020] In some embodiments, the distributed digital ledger 110 comprises digital records of purchases and ownership transfers associated with customer accounts and/or customer entity identifiers.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include a POS device as taught by Cantrell with the distributed ledger reward point system of Postrel in view of Davis in view of Polcha in order to implement an electronic checkout system using a distributed digital ledger ([0018]).
Postrel in view of Davis in view of Polcha in view of Cantrell teaches the limitations of claim 13. As per claim 16:
Postrel further teaches:
wherein writing comprises utilizing blockchain protocols Fig. 2; paragraph [0046] Block ID 202 acts as a unique identifier for each block in the ledger 100. Hash 204 is a hash pointer as a link to a previous block so that a sequence of block events may be provided. Timestamp 206 provides date and time information for the entry of the bock into the ledger 100. The remaining fields comprise the transaction data as follows. Transaction type 208 sets forth the type of reward transaction occurring in the block (e.g. award of rewards, redemption of rewards, exchange of rewards, etc.). Rewards issuer 210 identifies the issuer of the rewards that are either being awarded or redeemed in the block (e.g. the merchant). Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). Rewards aggregated 216 is a field or series of fields that may be used to identify rewards that are being aggregated together, if the block is for a reward aggregation transaction (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio). [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
Postrel in view of Davis in view of Polcha in view of Cantrell teaches the limitations of claim 13. As per claim 17:
Postrel in view of Polcha in view of Cantrell does not expressly teach wherein securing comprises restricting access through key-based encryption.
Davis further teaches:
wherein securing comprises restricting access through key-based encryption. (paragraph [0039] In some embodiments, the data element reserved for private use, or an alternative data element reserved for private use in the transaction message, may include input information associated with the payer 102. The input information may include a transaction identifier associated with a prior blockchain transaction as well as a public key associated with the payer 102 and a digital signature. The digital signature may be generated using a private key corresponding to the public key and may be used for verification of ownership of a blockchain currency amount associated with the transaction identifier by the payer 102, such that the payer 102 is authorized to transfer the blockchain currency in the requested transaction. See also [0030], [0043], [0068], [0069])
It would have been obvious to one of ordinary skill in the art to include wherein securing comprises restricting access through key-based encryption as taught by Davis with the blockchain reward ledger of Postrel in view of Polcha in view of Cantrell in order to maintain their privacy and help reduce the likelihood of fraud due to theft of their information (paragraph [0002]).
Postrel in view of Davis in view of Polcha in view of Cantrell teaches the limitations of claim 13. As per claim 18:
Postrel further teaches:
further comprising: maintaining the replicated trusted blockchain ledger on distributed nodes to ensure data integrity. [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
Postrel in view of Davis in view of Polcha in view of Cantrell teaches the limitations of claim 13. As per claim 19:
Postrel in view of Davis in view of Cantrell does not expressly teach further comprising: detecting tampering based on sequencing data of corresponding blocks.
Polcha teaches:
further comprising: detecting tampering based on sequencing data of corresponding blocks. (paragraph [0070] Each block, such as first block 210 and second block 220 in FIG. 2B, may include data regarding recent transactions and/or contents relating to computer readable information, linking data that links one block 220 to a previous block 210 in the blockchain, proof-of-work data that ensures that the state of the block chain 305 is valid, and is endorsed/verified by the system. The confirmed transactions of the blockchain can be performed using cryptography to ensure the integrity and the chronological order of the blockchain are enforced and can be independently verified by each node of the blockchain.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include independently verifying the chronological order of the blockchain as taught by Polcha with the transaction blockchain of Postrel in view of Davis in view of Cantrell in order to ensure that the state of the block chain is valid, and is endorsed/verified by the system (paragraph [0070)).
As per Claim 20:
Postrel teaches:
A system comprising:
executing the purchase transaction successfully (paragraph [0047] In step 302, the consumer 102 executes a reward-related transaction with a party as shown in FIG. 1. For example, the consumer 102 purchases a product from a merchant 112, for which he will receive reward points that will be added to his blockchain reward ledger 100. In step 304, as part of the purchase transaction, the consumer presents to the merchant a digital wallet that contains the blockchain reward ledger 100.
calculating a non-monetary point value for awarding to an account of the unique blockchain account identifier based on transaction factors; (paragraph [0046] Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). [0047] FIG. 3 is a flowchart of a general process for executing a transaction with a blockchain reward ledger in accordance with the preferred embodiment of the invention. In step 302, the consumer 102 executes a reward-related transaction with a party as shown in FIG. 1. For example, the consumer 102 purchases a product from a merchant 112, for which he will receive reward points that will be added to his blockchain reward ledger 100. In step 304, as part of the purchase transaction, the consumer presents to the merchant a digital wallet that contains the blockchain reward ledger 100.)
writing, via a network interface device over a network, a data structure to a replicated trusted blockchain ledger, the data structure comprises: {…} the non-monetary point value as calculated, a pointer to a previous block, and a hash value from a data payload comprising point granting or redemption data; and (Fig. 2; paragraph [0046] Block ID 202 acts as a unique identifier for each block in the ledger 100. Hash 204 is a hash pointer as a link to a previous block so that a sequence of block events may be provided. Timestamp 206 provides date and time information for the entry of the bock into the ledger 100. The remaining fields comprise the transaction data as follows. Transaction type 208 sets forth the type of reward transaction occurring in the block (e.g. award of rewards, redemption of rewards, exchange of rewards, etc.). Rewards issuer 210 identifies the issuer of the rewards that are either being awarded or redeemed in the block (e.g. the merchant). Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). Rewards aggregated 216 is a field or series of fields that may be used to identify rewards that are being aggregated together, if the block is for a reward aggregation transaction (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio). [0052] At step 502, the timestamp of the transaction (date, time) is logged, and at step 504, a hash of all data in the transaction block is calculated. [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates. Claim 3 - calculating a hash of reward transaction data).
PNG
media_image1.png
130
814
media_image1.png
Greyscale
wherein writing comprises transmitting the data structure to a plurality of computing systems where copies of the replicated trusted blockchain ledger are maintained, and wherein the data structure is written to each copy of the replicated trusted blockchain ledger when there are no objections by the plurality of computing systems after receipt of the data structure; (paragraph [0030] The permission routine requests permission to add a reward transaction block to the blockchain ledger by ascertaining the identity of all parties with an interest in the reward transaction; requesting permission from all identified parties to add the reward transaction block to the blockchain ledger; if any of the identified parties denies permission, then requesting an override from a system administrator; if all of the identified parties grants permission, or if all permission denials are overridden by the system administrator, then granting permission to add a reward transaction block to the blockchain ledger. [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
wherein the replicated trusted blockchain ledger is used to maintain account point values of customers for the plurality of computing systems, the account point values redeemable at each of the plurality of computing systems without regard to which computing system credited any or all of the account point values (paragraph [0030] The permission routine requests permission to add a reward transaction block to the blockchain ledger by ascertaining the identity of all parties with an interest in the reward transaction; requesting permission from all identified parties to add the reward transaction block to the blockchain ledger; if any of the identified parties denies permission, then requesting an override from a system administrator; if all of the identified parties grants permission, or if all permission denials are overridden by the system administrator, then granting permission to add a reward transaction block to the blockchain ledger. [0046] Rewards awarded 212 identifies, both quantitatively and qualitatively, the rewards that have been awarded to the consumer 102 in the block, if the block is for a reward-awarding transaction (e.g. a purchase of a product from the merchant for which the consumer 102 is granted 15,000 reward points from the merchant). Rewards redeemed 214 identifies, both quantitatively and qualitatively, the rewards that have been redeemed by the consumer 102 in the block, if the block is for a reward-redeeming transaction (e.g. a purchase of a product from the merchant for which the consumer 102 uses 10,000 reward points to pay for the product from the merchant). Rewards aggregated 216 is a field or series of fields that may be used to identify rewards that are being aggregated together, if the block is for a reward aggregation transaction (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio). [0053] After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.)
Postrel does not expressly teach a unique blockchain identifier and securing access to the ledger using private/public key pairs.
Davis teaches:
receiving a unique blockchain account identifier for a purchase transaction; (paragraph [0027] In some configurations, transactions recorded in the blockchain may include a destination address and a currency amount, such that the blockchain records how much currency is attributable to a specific address. In some instances, additional information may be captured, such as a source address, timestamp, etc. [0030] The computing device of the payer 102 may digitally sign the transaction request using an encryption key stored in the computing device, such as stored in an electronic wallet. The digital signature may be, include, or otherwise be associated with an address that is generated using the encryption key, which may be associated with blockchain currency in the blockchain, and may be used to transfer blockchain currency to an address associated with the payee 104 and/or their computing device. (See also [0029], [0034], [0038], [0044], [0059]))
{writing to the blockchain} the unique blockchain account identifier (paragraph [0027] In some configurations, transactions recorded in the blockchain may include a destination address and a currency amount, such that the blockchain records how much currency is attributable to a specific address. In some instances, additional information may be captured, such as a source address, timestamp, etc. [0029] In the system 100, a blockchain transaction may occur between the computing device of a payer 102 and the computing device of a payee 104. As used herein, “payer” may refer to a computing device and/or a consumer that is funding a payment transaction, and “payee” may refer to a computing device and/or a consumer that is receiving payment in a payment transaction. The blockchain transaction may be processed by one or more computing devices that comprise a blockchain network 106. The blockchain network may receive at least a destination address (e.g., associated with the payer 104) and an amount of blockchain currency and may process the transaction by generating a block that is added to a blockchain that includes a record for the transaction. [0060] Each transaction data entry 214 may include a transaction message, transaction notification, and/or data included therein, such as transaction times and/or dates, transaction identifiers, source addresses, destination addresses, transaction amounts, merchant data, consumer data, product data, loyalty data, reward data, etc.)
securing access to the replicated trusted blockchain ledger through private/public key pairs (paragraph [0039] In some embodiments, the data element reserved for private use, or an alternative data element reserved for private use in the transaction message, may include input information associated with the payer 102. The input information may include a transaction identifier associated with a prior blockchain transaction as well as a public key associated with the payer 102 and a digital signature. The digital signature may be generated using a private key corresponding to the public key and may be used for verification of ownership of a blockchain currency amount associated with the transaction identifier by the payer 102, such that the payer 102 is authorized to transfer the blockchain currency in the requested transaction. See also [0030], [0043], [0068], [0069])
It would have been obvious to one of ordinary skill in the art to include a unique blockchain identifier and securing access to the ledger using private/public key pairs as taught by Davis with the blockchain reward ledger of Postrel in order to maintain their privacy and help reduce the likelihood of fraud due to theft of their information (paragraph [0002]).
Postrel in view of Davis does not expressly teach wherein the pointer to the previous block and the hash value enable detection of tampering based on sequencing data.
Polcha teaches:
wherein the pointer to the previous block and the hash value enable detection of tampering based on sequencing data. ([0070] Each block, such as first block 210 and second block 220 in FIG. 2B, may include data regarding recent transactions and/or contents relating to computer readable information, linking data that links one block 220 to a previous block 210 in the blockchain, proof-of-work data that ensures that the state of the block chain 305 is valid, and is endorsed/verified by the system. The confirmed transactions of the blockchain can be performed using cryptography to ensure the integrity and the chronological order of the blockchain are enforced and can be independently verified by each node of the blockchain.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein the pointer to the previous block and the hash value enable detection of tampering based on sequencing data as taught by Polcha with the transaction blockchain of Postrel in view of Davis in order tor ensure that the state of the block chain is valid, and is endorsed/verified by the system ([0070]).
Postrel in view of Davis in view of Polcha does not expressly teach using a POS device.
Cantrell teaches:
{implementing transactions and blockchain activities by} a point of sale (POS) device including: a network interface device; a computer processor; and a memory storing instructions executable by the computer processor to perform data processing activities comprising ([0017] The system comprises a plurality of point of sale (POS) systems comprising nodes of a distributed digital ledger, wherein the distributed digital ledger comprises ownership records associated with a plurality of user accounts that are updated and verified collectively by the plurality of POS systems, and wherein the distributed digital ledger is configured to be used by one or more of the plurality of POS systems to authorize transfer of items specified in the ownership records to customers. [0018] The system 100 includes a plurality of POS systems 120 communicating over a network via a distributed digital ledger 110. The distributed digital ledger 110 is further accessed by one or more user device 130. [0019] The distributed ledger may be stored on a plurality of POS systems 120, user devices 130, and/or other processor-based devices. In some embodiments, the nodes of the distributed digital ledger comprise systems associated with retailers, manufacturers, suppliers, and/or customers. In some embodiments, the distributed digital ledger 110 comprises one or more of a shared ledger, a distributed database, a hash chain database, a blockchain database, and a blockchain-based database. [0020] In some embodiments, the distributed digital ledger 110 comprises digital records of purchases and ownership transfers associated with customer accounts and/or customer entity identifiers.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include a POS device as taught by Cantrell with the distributed ledger reward point system of Postrel in view of Davis in view of Polcha in order to implement an electronic checkout system using a distributed digital ledger ([0018]).
Claim(s) 3is/are rejected under 35 U.S.C. 103 as being unpatentable over Postrel (US 2019/0156363) in view of Davis (US 2018/0082294) in view of Polcha et al (US 20190058593) in view of Mottur et al (US 2019/0228429)
Postrel in view of Davis in view of Polcha teaches the limitations of claim 2. As per claim 3:
Postrel in view of Davis in view of Polcha does not expressly teach receiving the identifier by NFC.
Mottur teaches:
wherein receiving the unique account identifier comprises receiving the unique account identifier in a radio signal via a near field communication (NFC) device. (paragraph [0010] The present invention is directed to a method and system that provides users with the ability to redeem those rewards, issued by requesters, for goods and services from vendors proximate to the user's location. For example, the method and system facilitates this transaction of value transfer between parties in three possible ways: 1) means enacted by a single user within the application, 2) means through recognition and acceptance of a physical code, or 3) means through recognition and acceptance of electronic code. Such a code may reference a public wallet address (i.e., a hashed public key or cryptographic code recorded on a blockchain network) that allows digital value to be transferred from one wallet address to another wallet address. The codes can be manually entered or scanned using a camera with a reader (such as a bar code or QR code reader), automatically added using near-field communications (NFC) or other forms of wireless data transfer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein receiving the unique account identifier comprises receiving the unique account identifier in a radio signal via a near field communication (NFC) device as taught by Mottur with the reward blockchain of Postrel in view of Davis in view of Polcha in order to provide users with the ability to redeem rewards, issued by requesters, for goods and services from vendors proximate to the user's location (paragraph [0010]).
Claim(s) 14, and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Postrel (US 2019/0156363) in view of Davis (US 2018/0082294) in view of Polcha et al (US 20190058593) in view of Cantrell et al (US 2019/0311343) in view of Mottur et al (US 2019/0228429)
Postrel in view of Davis in view of Polcha n view of Cantrell teaches the limitations of claim 13. As per claim 14:
Postrel in view of Davis in view of Polcha in view of Cantrell does not expressly teach wherein receiving comprises obtaining the unique blockchain account identifier via a near field communication device integrated with the POS device.
Mottur teaches:
wherein receiving comprises obtaining the unique blockchain account identifier via a near field communication device integrated with the POS device. (paragraph [0010] The present invention is directed to a method and system that provides users with the ability to redeem those rewards, issued by requesters, for goods and services from vendors proximate to the user's location. For example, the method and system facilitates this transaction of value transfer between parties in three possible ways: 1) means enacted by a single user within the application, 2) means through recognition and acceptance of a physical code, or 3) means through recognition and acceptance of electronic code. Such a code may reference a public wallet address (i.e., a hashed public key or cryptographic code recorded on a blockchain network) that allows digital value to be transferred from one wallet address to another wallet address. The codes can be manually entered or scanned using a camera with a reader (such as a bar code or QR code reader), automatically added using near-field communications (NFC) or other forms of wireless data transfer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein receiving the unique account identifier comprises receiving the unique account identifier in a radio signal via a near field communication (NFC) device as taught by Mottur with the reward blockchain of Postrel in view of Davis in view of Polcha in view of Cantrell in order to provide users with the ability to redeem rewards, issued by requesters, for goods and services from vendors proximate to the user's location (paragraph [0010]).
Postrel in view of Davis in view of Polcha in view of Cantrell teaches the limitations of claim 20. As per claim 21:
Postrel in view of Davis in view of Polcha in view of Cantrell does not expressly teach wherein the POS device includes a near field communication (NFC) device configured to receive the unique blockchain account identifier in a radio signal.
Mottur teaches:
wherein the POS device includes a near field communication (NFC) device configured to receive the unique blockchain account identifier in a radio signal. (paragraph [0010] The present invention is directed to a method and system that provides users with the ability to redeem those rewards, issued by requesters, for goods and services from vendors proximate to the user's location. For example, the method and system facilitates this transaction of value transfer between parties in three possible ways: 1) means enacted by a single user within the application, 2) means through recognition and acceptance of a physical code, or 3) means through recognition and acceptance of electronic code. Such a code may reference a public wallet address (i.e., a hashed public key or cryptographic code recorded on a blockchain network) that allows digital value to be transferred from one wallet address to another wallet address. The codes can be manually entered or scanned using a camera with a reader (such as a bar code or QR code reader), automatically added using near-field communications (NFC) or other forms of wireless data transfer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein wherein the POS device includes a near field communication (NFC) device configured to receive the unique blockchain account identifier in a radio signal as taught by Mottur with the reward blockchain of Postrel in view of Davis in view of Polcha in view of Cantrell in order to provide users with the ability to redeem rewards, issued by requesters, for goods and services from vendors proximate to the user's location (paragraph [0010]).
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Postrel (US 2019/0156363) in view of Davis (US 2018/0082294) in view of Polcha et al (US 20190058593) in view of Cantrell et al (US 2019/0311343) in view of Joshi et al (US 2016/0042383)
Postrel in view of Davis in view of Polcha in view of Cantrell teaches the limitations of claim 13. As per claim 15:
Postrel in view of Davis in view of Polcha in view of Cantrell does not expressly teach wherein calculating comprises determining the non- monetary point value based on a combination of: a monetary value, a fixed point value, and a loyalty status.
Joshi teaches:
wherein calculating comprises determining the non- monetary point value based on a combination of: a monetary value, a fixed point value, and a loyalty status. (paragraph [0052] FIG. 9 depicts another embodiment of a user interface 902 on a merchant device. Once a user has been successfully validated by the merchant as discussed in FIG. 8, the merchant is presented with user interface 902 on the merchant device, which allows a user to enter a transaction amount and issue a reward to the customer. This user interface corresponds to the tab 912 to validate the customer, as discussed in the description of FIG. 8. In some embodiments, the merchant is presented with customer information, 904. In some embodiments, the customer reward program can categorize customers in different levels based on, for example, customer shopping history. For example, different customer tier ratings, such as gold, silver and bronze, can be implemented by the customer reward program. This information may be displayed to the merchant on the merchant device via user interface 902. Some embodiments present the merchant with text box 906, in which the merchant enters the transaction amount. In some embodiments, user interface 902 also presents the merchant with multiple reward options. For example, the merchant may be given an option to offer the customer a standard 5% reward 912 selected, for example, via radio button 908. The merchant may also be given an option to offer the customer a premium 10% reward 914 selected, for example, via radio button 910. Alternate embodiments of user interface 902 may allow the merchant to enter any value of the percentage reward they wish to offer to a customer as a part of the customer rewards program. In other embodiments, the rewards to the customer can be directly entered rather than being computed as a percentage of the transaction amount. For example, a merchant might want to reward a regular customer with 100 reward points regardless of the dollar amount of the purchase transaction. In another embodiment that implements a cash back customer reward program, a merchant might want to reward a regular customer with a $10 cash back reward regardless of the dollar amount of the purchase transaction. In still other embodiments, different ranges of transaction values can be associated with different reward values. For example, a dollar amount for a purchase transaction between $10 and $25 can be rewarded with 5 reward points, a dollar amount for a purchase transaction between $25 and $50 can be rewarded with 10 reward points, and so on. In other embodiments, customer rewards can be awarded based on specific items purchased. For example, a merchant may offer greater reward points on clearance items in an attempt to move old merchandise off the shelves.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include calculating comprises determining the non- monetary point value based on a combination of: a monetary value, a fixed point value, and a loyalty status as taught by Joshi with the reward blockchain of Postrel in view of Davis in view of Polcha in view of Cantrell in order to provide merchants with flexibility with regard to customizing customer reward programs (paragraph [0003]).
Response to Arguments
Applicant’s arguments regarding double patenting rejections are not found persuasive. As a result, such rejection remains.
The examiner has considered but does not find persuasive applicant’s arguments regarding rejections under 35 USC 101. The examiner respectfully disagrees with applicant’s accusation that the examiner has over simplified the invention. The examiner has specifically recited each and every limitation that makes up the abstract idea. Further, it is quite clear that the claims are directed certain methods of organizing human activity as they clearly focus on storing reward points of users for completing transactions.
Centralized versus decentralized is not in an of itself a technical problem. It is merely an abstract idea. Any technical details regarding its specific implementation may possible allow it to provide a technical solution. However, applicant’s claims do not provide a technical solution. The claims merely highlight high level use of blockchain. Applicant has not invented blockchain or improved blockchain technology or the technical field. It is merely used at a high level with applicant’s choice of data.
The claims provide no improvement to cryptography technology or a technical field. Hashing data is merely part of an abstract idea. Similarly, tamper detection technology is not improved nor is the technical field. Merely having sequential blocks and being able to identify the sequence is merely part of the abstract idea and also high-level use of block chain. The same is true with regard to distributed consensus mechanisms. The claims provide no technical improvement or improvement to a technical field. This amounts to no more than high level block chain use. Cross entity fungibility is also merely part of the abstract idea that provides no improvement to technology or a technical field.
The same is true for the arguments presented with regard to claim 13 and 20. No technical improvement is provided with regard to performing transactions over a network, hashing, temper detection, or multisystem cross redemption. These are merely abstract ideas and the claims provide little more than doing it with block chain. Nothing improves blockchain itself or blockchain technology.
With regard to Desjardins and Enfish, the examiner finds no similarities what so ever. Applicant’s arguments with regard to Desjardins are out of context and irrelevant. Desjardins was found eligible as it was determined to improve AI/ machine learning technology. The present claims provide no such improvements and do not even involve machine learning or AI. With regard to Enfish, again the examiner finds no such similarities. Enfish involved an improvement in the way a computer stored and recalled information by using self referential tables. As discussed above, the present claims provide no improvement to technology or a technical field. The claims merely use of a blockchain using applicant’s desired data. Applicant should point out what features of the invention improve blockchain technology.
Further, the examiner is in no way ignoring technical language. Much of the language provided by the applicant is simply not technical and is merely part of an abstract idea. The examiner has clearly pointed out which elements are technical and thus make up the additional elements. Hashing data is not technical, it is merely part of the abstract idea. Applicant provides no meaningful details regarding hashing other than to say that some of the data is hashed. Hashing is essentially a mathematical algorithm to encode data which is an abstract idea. The same holds true for using generic pointers, cryptographic signing, distributed consensus, objection based verification, and tamper detection. With regard to network based distribution the claims do no more than send and receive data over a network. This in no way what so ever improve network distribution operations.
Again, with regard to Enfish the examine respectfully disagrees. Applicant’s high level use of blockchain in no way constitutes and improvement to technology or a technical field of any kind, let alone to computers themselves. Applicant’s high level use of hashing in no way is an improvement to data integrity. Hashing is merely an abstract concept. Even if it were to be considered an additional elements, its high level use would not go beyond the “apply it” level of implementation. Applicant provides nothing in the claims or specification that improves hashing itself, hashing technology, or the technical field. The same is true of using a pointer and having no objections.
Applicant has not invented block chain. They are merely using it a high level to implement a rewards program. Therefore, applicant’s high level use of blockchain does not improve security, scalability, or remove the need for centralized infrastructure. This is merely the result of using the blockchain. As previously stated, applicant is in no way improving blockchain.
The courts held that merely transforming data does not qualify under the particular transformation test. ( See RECOGNICORP, LLC v. NINTENDO CO., LTD. , No. 16-1499 (Fed. Cir. 2017) “The addition of a mathematical equation that simply changes the data into other forms of data cannot save it.” )
The examiner has considered the claim limitations both individually and as an ordered combination. Again, applicant conflates abstract ideas form additional elements. None of the alleged improvements are because of applicant’s invention. Applicant merely uses blockchain at a high level. This is akin to saying doing long math equations on a computer is an improvement to doing it by hand because its faster to use a computer. The simple inclusion of doing a task with a computer does not constitute an improvement to the computer. Everyone knows that having the computer perform the calculations is faster, however, that does not improve technology or a technical field. The same is true here with regard to blockchain. Everyone knows that blockchain is designed to not require a centralized device. However, applicant is not improving technology by merely using blockchain. Had applicant novelly invented these features of a blockchain then such arguments may be persuasive. However, this is not the case. Applicant is simply using blockchain in the way it is typically used and getting whatever benefits come from the use of blockchain. None of these benefits are actual improvements to technology or a technical field.
The examiner is not misconstruing the technical mechanisms. Applicant has not in any way improved blockchain technology or a technical field. Enfish is irrelevant because applicant’s high level use of blockchain has not improved any aspect of blockchain technology.
Similarly, as described above, the alleged improvements are not to technology or a technical field but to the business practice itself.
The findings of Desjardins are irrelevant to the claims as discussed above.
The claims are not rejected as being insignificant extra solution activity. Thus the findings as to whether the claim limitations are well-understood, routine, and conventional is moot.
As discussed above, the examiner respectfully disagrees. As noted, the additional elements, both individually, and as an ordered combination, do not provide an inventive concept because they do not go beyond the apply it level of implements or merely provide a general link to a particular technological environment or field of use.
The examiner respectfully disagrees that the claims solve technical problems in computing systems. Again, applicant is merely using block chain, not improving it or the technical field. Its use does not go beyond the apply it level of implementation. Maintaining data integrity without centralized authority, achieving consensus, detecting tampering, and cross system transactions are not necessarily rooted in computers. Each of these abstract concepts can be addressed without computing technology.
The alleged network operations, data processing, and integrated systems merely apply it using generic computing devices as discussed above.
With regard to NFC, the examiner must evaluate all the claims and that is why it is mentioned in the thorough 101 analysis.
As stated repeatedly, the applicant has not invented blockchain or improvement blockchain technology or a technical field. Enfish is irrelevant as the claims do not improve the way computers store and retrieve information. The alleged specific features are merely part of the blockchain implementation. The applicant has not novelly invented any of these features. These features of blockchains are merely being implemented with applicant choice of data, i.e. reward points. Thus they do not provide any improvement to blockchain technology or a technical field.
The examiner further finds no similarities to the findings of McRO. None of the rules provided in the claims only exist because the process is being done on a computer. Simialrly with regard to DDR, the issues at hand are not necessarily rooted in computers. The claims at hand further provide a conventional blockchain arrangement and thus Bascom is also irrelevant. As a result, such rejections have been maintained.
Applicant’s arguments regarding rejections under 35 USC 103 that correspond to newly added limitations are moot in light of new grounds of rejection which have been necessitated by amendment.
With regard to the hash value, the examiner respectfully disagrees. The hash in Postrel includes “a hash of all data in the transaction block is calculated.” ([0052]). Since both the pointer and the data are included in the block, both piece of information are included in the hash.
Further, Postrel includes aggregating the points across multiple merchants (e.g. 10,000 reward points from one merchant are aggregated with 12,000 reward points from another merchant to provide an aggregate total of 22,000 reward points, assuming a 1:1 conversion ratio). Thus, the reward points can be combined and used across multiple merchants.
Whether Postrel’s permission system operates differently is not relevant to what is claimed. The Limitations are presently claimed are read on and it is up to the applicant to amend the claims to differentiate this feature if such a difference exists. Postrel clearly teaches the claimed consensus mechanism. Paragraph [0030] recites “The permission routine requests permission to add a reward transaction block to the blockchain ledger by ascertaining the identity of all parties with an interest in the reward transaction; requesting permission from all identified parties to add the reward transaction block to the blockchain ledger; if any of the identified parties denies permission, then requesting an override from a system administrator; if all of the identified parties grants permission, or if all permission denials are overridden by the system administrator, then granting permission to add a reward transaction block to the blockchain ledger.” Paragraph [0053] recites “After the blockchain reward ledger 100 has been modified, then it is synchronized across multiple parties at step 316. Synchronization is a process in which a duplicate of the transaction block generated and entered as a result of the transaction is transmitted to all interested parties, i.e. those whose permission was sought in the prior steps. This block is thereby maintained independently by all interested parties, and the process terminates.” Thus, Postrel clearly teaches the limitations as claimed. As a result, such rejection has been maintained.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, it would have been obvious to one of ordinary skill in the art to include a unique blockchain identifier and securing access to the ledger using private/public key pairs as taught by Davis with the blockchain reward ledger of Postrel in order to maintain their privacy and help reduce the likelihood of fraud due to theft of their information (paragraph [0002]).
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
The majority of the remaining arguments are referring to things not in the claims, are irrelevant to whether the prior art teaches the limitations of the claimed invention, are repeats that have already been addressed, or are directed to the amended claim language which has been addressed with new art necessitated by amendment.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER STROUD whose telephone number is (571)272-7930. The examiner can normally be reached Mon. - Fri. 9AM-5PM.
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, Waseem Ashraff can be reached at (571) 270-3948. 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.
CHRISTOPHER STROUD
Primary Examiner
Art Unit 3621B
/CHRISTOPHER STROUD/ Primary Examiner, Art Unit 3621