DETAILED ACTION
Status of Claims
1. This is a Final office action in response to communication received on 01/07/2026. Claims 1-20 are pending and examined herein.
Drawing
2. Fig. 8 is objected to as it is illegible. The Applicant is requested to follow Patent rules 1.84 Standards for drawings; and 1.85 Corrections to drawings. Appropriate correction is required.
Priority
3. The examiner acknowledges priority benefits being claimed by the Applicant to prior applications based on CIP relationship, the Examiner notes that priority benefits is granted to claims as supported by Figs. 1-5 and their disclosure, however claims supported by Figs. 6-8 and their associated disclosure is granted date of the instant application.
Claim Rejections - 35 USC § 101
4. 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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Next using the 2019 Revised Patent Subject Matter Eligibility Guidances (hereinafter 2019 PEG) the rejection as follows has been applied.
Under step 1, analysis is based on MPEP 2106.03, claims 1-5 and 7-20 are being interpreted as a software per se claims which is not directed to one of the statutory categories because per claim 1 it’s to an adjudication module for omni-channel item-level promotional offer adjudication, the adjudication module comprising at least one of: an integrated container comprising application code which interfaces with other modules and systems; per claims 12 and 20 they are a system for omni-channel item-level promotional offer adjudication, the system comprising. However, the Applicant has failed to properly define the physical components (i.e. a computer processor, hardware, etc.) of such a system in the claim recitation and none of the modules appear to be stored on a memory with the exception of claim 6. Accordingly, the Examiner is interpreting such recitations as computer code, per se. (see at least as-filed spec. para. [0121]). Indeed, computer code, per se, is not eligible for patent protection. If Applicant were to amended the claim 1 to positively recite a physical component, such as see at least as-filed spec. [0132] " adjudication module 108 causes the retail system 102 to itself 5 become a node 116 of the distributed ledger 114. The node can be a read-only node, a write-only node, a node with both read and write access, a storage node (with no read or write access), or another type of node. Thus, the adjudication module 108 can transform the retail system 102 into a part of the distributed ledger 114 (without interfering with the native functionality of the retail system 102). In some cases, this not only gives the retail system 102 expanded functionality, but 10 it can also further increase the security and power of the distributed ledger 114 itself (by increasing the number of participating nodes). In some cases, this is done by utilizing a memory storage of the retail system 102 ( or of the container 110 of the container 110 of the adjudication module 108) to cause the retail system to operate as a node for the distributed ledger" (also claim 6) and/or other physical components associated with containers and modules.
In anticipation of the Applicant resolving the issue using the suggestion as provided by the Examiner, the full analysis under remaining steps, namely Step 2A and Step 2B for all claims has been performed in view of compact prosecution.
Under Step 2A Prong One, per MPEP 2106.04, prong one asks does the claim recite an abstract idea, law of nature, or natural phenomenon? In Prong One examiners evaluate whether the claim recites a judicial exception, i.e. whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. While the terms "set forth" and "described" are thus both equated with "recite", their different language is intended to indicate that there are two ways in which an exception can be recited in a claim. For instance, the claims in Diehr, 450 U.S. at 178 n. 2, 179 n.5, 191-92, 209 USPQ at 4-5 (1981), clearly stated a mathematical equation in the repetitively calculating step, and the claims in Mayo, 566 U.S. 66, 75-77, 101 USPQ2d 1961, 1967-68 (2012), clearly stated laws of nature in the wherein clause, such that the claims "set forth" an identifiable judicial exception. Alternatively, the claims in Alice Corp., 573 U.S. at 218, 110 USPQ2d at 1982, described the concept of intermediated settlement without ever explicitly using the words "intermediated" or "settlement."
Next, per 2019 PEG, to determine whether a claim recites an abstract idea in Prong One, examiners are now to: (I) Identify the specific limitation(s) in the claim under examination (individually or in combination) that the examiner believes recites an abstract idea; and (II) determine whether the identified limitation(s) falls within the subject matter groupings of abstract ideas enumerated in Section I of the 2019 PEG. If the identified limitation(s) falls within the subject matter groupings of abstract ideas enumerated in Section I, analysis should proceed to Prong Two in order to evaluate whether the claim integrates the abstract idea into a practical application.
(I) An abstract idea as recited per abstract recitation of claims 1-20 [i.e. recitation with the exception of additional elements, which are first considered under step 2A prong two when claim(s) is/are reconsidered as a whole and exclusively under step 2B inquiries below, i.e. under step 2A prong one the Examiner considered claim recitation other than the additional elements (which once again are expressly noted below) to be the abstract recitation] (II) is that of applying or redeeming one-time use coupon code if it passes adjudication process and if the coupon is successfully applied updating a log that it has been redeemed in a ledger which is certain methods of organizing human activity (but for its implementation in a technical environment - which is considered further under prong two and step 2B analysis as set forth below).
The phrase "Certain methods of organizing human activity" applies to fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). Further, see MPEP 2106.04(a)(2) II. A-C.
Therefore, the identified limitations fall within the subject matter groupings of abstract ideas enumerated in Section I of 2019 PEG, thus analysis now proceeds to Prong Two in order to evaluate whether the claim integrates the abstract idea into a practical application.
Under Step 2A Prong Two, per MPEP 2106.04, prong two asks does the claim recite additional elements that integrate the judicial exception into a practical application? In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. If the additional elements in the claim integrate the recited exception into a practical application of the exception, then the claim is not directed to the judicial exception (Step 2A: NO) and thus is eligible at Pathway B. This concludes the eligibility analysis. If, however, the additional elements do not integrate the exception into a practical application, then the claim is directed to the recited judicial exception (Step 2A: YES), and requires further analysis under Step 2B (where it may still be eligible if it amounts to an ‘‘inventive concept’’).
Next, per 2019 PEG, Prong Two represents a change from prior guidance. The analysis under Prong Two is the same for all claims reciting a judicial exception, whether the exception is an abstract idea, a law of nature, or a natural phenomenon. Examiners evaluate integration into a practical application by: (I) Identifying whether there are any additional elements recited in the claim beyond the judicial exception(s); and (II) evaluating those additional elements individually and in combination to determine whether they integrate the exception into a practical application, using one or more of the considerations laid out by the Supreme Court and the Federal Circuit.
Accordingly, the examiner will evaluate whether the claims recite one or more additional element(s) that integrate the exception into a practical application of that exception by considering them both individually and as a whole.
The claim elements in addition to the abstract idea, i.e. additional elements, as recited in claims 1-20 at least are an adjudication module comprising an integrated container comprising application code and an API, and configured to interface with a retail system comprising
a payment module and at least one of: a POS system; and a cloud-computing system and receive/transmit data including accessing a distributed ledger, adjudication module utilizes memory storage of the retail system and causes it to operate as distributed ledger node (per claims 1 and 12); and a security protocol (additionally per claim 20); communication with a bank card processor (per claim 3), POS system (per claim 4), adjudication module operates as a distributed ledger node such as blockchain (per claims 6 and 9), plurality of retail systems (additionally per claim 12), and ability to read data (per claim 19). Remaining claims either recite the same additional element(s) as already noted above or simply lack recitation of an additional element, in which case note prong one as set forth above.
As would be readily apparent to a person having ordinary skill in the art (hereinafter PHOSITA), the additional elements are generic computer components. The additional elements are simply utilized as generic tools to implement the abstract idea or plan as "apply it" instructions (see MPEP 2106.05(f)). The additional elements are generic as they are described at a high level of generality, see at least as-filed spec. Figs. 1-6 and their associated disclosure.
The processor executing the "apply it" instruction on which adjudication module resides is further connected to one or more device(s) merely sending/receiving data over a network, note receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014). Gathering data is considered insignificant extra solution activity (see MPEP 2106.05(g)).
Further, the processor analyzes gathered data to ascertain that user and/or coupon or incentive can be redeemed per business rules. Thus, the process is similar to collecting information, analyzing it, and displaying certain results of the collection and analysis (Electric Power Group). The abstract idea is intended to be merely carried out in a technical environment and as a distributed ledger for collecting data via a network and maintain ledger state where the data is analyzed via a generic processor at one or more retailer POS(s) that operate as one or more nodes of a distributed ledger to adjudicate on validity of one-time-use-coupon which is associated with a particular retail system and prevent redemption of said one-time-use-coupon at a ineligible retailer, however fail to contain meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment (see MPEP 2106.05(h)).
Accordingly, viewed as a whole, these additional claim element(s) do not provide any additional element that integrates the abstract idea (prong one), into a practical application (prong two) upon considering the additional elements both individually and as a combination or as a whole as they fail to provide: an additional element that reflects an improvement in the functioning of a computer, or an improvement to other technology or technical field; or an additional element that implements a judicial exception with, or uses a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim; or an additional element that effects a transformation or reduction of a particular article to a different state or thing; or an additional element that applies or uses the judicial exception, again, in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception as explained above.
Thus, the abstract idea of applying or redeeming one-time use coupon code if it passes adjudication process and if the coupon is successfully applied updating a log that it has been redeemed in a ledger which is certain methods of organizing human activity (prong one) is not integrated into a practical application upon consideration of the additional element(s) both individually and as a combination (prong two).
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B, per MPEP 2106.05, as it applies to claims 1-20, the Examiner will evaluate whether the foregoing additional elements analyzed under prong two, when considered both individually and as a whole provide an inventive concept (i.e., whether the additional elements amount to significantly more than the exception itself). The abstract idea of applying or redeeming one-time use coupon code if it passes adjudication process and if the coupon is successfully applied updating a log that it has been redeemed in a ledger which is certain methods of organizing human activity - has not been applied in an eligible manner. The claim elements in addition to the abstract idea are simply being utilized as generic tools to execute "apply it" instructions as they are described at a high level of generality. Additionally, the abstract idea is intended to be merely carried out in a technical environment, however fail to contain meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment (Id. or note step 2A prong two).
Regarding, insignificant solution activity such as data gathering or post solution activity such as displaying on interface, the Examiner relies on court cases and publications that demonstrate that such a way to gather data and display information is indeed well-understood, routine, or conventional in the industry or art, at least note as follows:
(i) receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network) [similarly here user and/or the coupon or incentive data is received and based on analysis targeted promotions are to be transmitted over a network]; and
(ii) Affinity v DirecTV - "The court rejected the argument that the computer components recited in the claims constituted an “inventive concept.” It held that the claims added “only generic computer components such as an ‘interface,’ ‘network,’ and ‘database,’” and that “recitation of generic computer limitations does not make an otherwise ineligible claim patent-eligible.” Id. at 1324-25 (citations omitted). The court noted that nothing in the asserted claims purported to improve the functioning of the computer itself or “effect an improvement in any other technology or technical field.” Mortgage Grader, 811 F.3d at 1325 (quoting Alice, 134 S. Ct. at 2359)." [similarly here as a post solution promotions are redeemed or not].
Next, in view of compact prosecution only further analysis per the Berkheimer Memo dated April 19, 2018 is being conducted as the following additional elements would be readily apparent as generic to a person having ordinary skill in the art (hereinafter PHOSITA), in other words analysis is similar to Berkheimer claim 1 and not claims 4-7 where there was "a genuine issue of material fact in light of the specification," nevertheless the Examiner finds the additional elements of distributed ledger and/or blockchain based recording of POS data when considered both individually and as a combination to be well-understood, routine or conventional and expressly supports in writing as follows:
(i) Pub. No.: 2023/0230065 see [0002] “This disclosure relates to blockchain supported transaction environments, and more specifically some embodiments disclosed herein relate to systems and methods for providing blockchain-based payment cards (e.g., blockchain-based credit card (a digital wallet based card that draws against a credit line for blockchain based transactions), blockchain-based debit card (a digital wallet based card that draws against a deposit account for blockchain based transactions), blockchain-based check card (a digital wallet based card that draws against a checking account for blockchain based transactions), blockchain-based prepaid card (a digital wallet based card that can be used like a blockchain based debit card for blockchain based transactions, but is not associated with replenishable bank account of the cardholder), a blockchain-based multi-use card (a digital wallet based card with tokens that can be used for blockchain based transactions multiple times), blockchain-based single-use card (a digital wallet based card with tokens that can be used for a blockchain based transaction only once), blockchain-based limited card (a digital wallet based card with tokens that can be used only for a limited time before expiring and becoming unusable for blockchain based transactions), blockchain-based gift card (a digital wallet based card with tokens that can be used for blockchain based transactions only at a particular merchant or particular set of merchants), blockchain-based coupon card (a digital wallet based card with tokens that can be used for blockchain based transactions in exchange for a discount to be applied at a particular merchant or particular set of merchants), etc.) and corresponding technological solutions utilizing traceable and programmable tokens (such as credit tokens, debit tokens, check tokens, prepaid tokens, multi-use tokens, single use tokens, gift tokens, coupon tokens, etc. associated with one or more of the blockchain-based credit card, blockchain-based debit card, blockchain-based check card, blockchain-based prepaid card, blockchain-based multi-use card, blockchain-based single-use card, blockchain-based gift card, blockchain-based coupon card, etc., respectively) to complete trusted and verifiable transactions within a blockchain supported network, and leveraging features of such traceable and programmable tokens together with unique network architecture and processes to achieve intelligent enhancements over conventional systems and methods.”; [0155]; [0168] “Similarly, just as in FIG. 4A, Merchant 31 is a network participant on the blockchain network who possesses one or more computing devices operating as a node of the blockchain network, and which may further have access to, or even embody, merchant 31's point-of-sale device 41. Indeed, in some embodiments, POS device 41 may be embodied, in whole or in part, within merchant 31's node. In some embodiments, the POS device may comprise a scanner (e.g., a handheld scanner) capable of reading a QR code, a bar code, a serial number, or other electronic or physical object (such as a Bluetooth component/module and/or an IOT component/module that can sync with payer's digital wallet) that can be linked or built in to the merchant 31's digital wallet, which is further linked to the merchant 31's bank account with acquiring bank 51.”
- Pub. No.: US2018/0150865 see [0036] note “In other embodiments, the payment instrument 108 may use a single private key for all coupons issued thereto. For example, a plurality of different merchants may each issue coupons to the individual 104, which may be tracked on the blockchain using the private key and corresponding blockchain addresses of the payment instrument 108. In such embodiments, the payment instrument 108 may operate as a universal loyalty card, where each point of sale device 102 (e.g., and associated merchant) may be able to issue rewards and coupons to the individual 104 that are redeemable using the same payment instrument 108.”; [0061] note “the method 400 may further include electronically transmitting, by a transmitting device of the point of sale device, a new transaction value to a blockchain node associated with the blockchain, wherein the new transaction value includes at least a reference to the coupon identifier included in the identified specific transaction value and is configured to invalidate the coupon data included in the identified specific transaction value. In a further embodiment, the new transaction value may further include a digital signature, and the digital signature may be received by the receiving device of the point of sale device from a payment instrument used to convey the identification value. In another further embodiment, the new transaction value may further include a blockchain address, and the blockchain address may be one of: a null address and an address associated with invalidated coupons. In yet another further embodiment, the method 400 may even further include receiving, by the receiving device of the processing server, a transaction notification, wherein the transaction notification indicates approval of the payment transaction, and the transaction notification is received prior to electronic transmission of the new transaction value.”
- Pub. No.: US2021/0366586 see Figs. 23, 25, and their associated disclosure; [0209]; [0851] note “a product 118 is purchased by a customer 200, data 062a for the transaction may be electronically transmitted to a node in the blockchain network 017 c for addition to the blockchain. The transaction data 062a may be accompanied by an identification value ( or values) 117 associated with the customer 200 identification value ( or values) 181 associated with the product 118. In one embodiment, the identification value may be a blockchain address associated with the customer 200 or an address associated with a brand 107. In another embodiment, the identification value may be a digital signature generated by the customer 200 and supplied to the POS device 101. The blockchain node 112 may add select transaction data 062a to a new block to be added as one of the plurality of transaction values. The block may be verified by other nodes 112 in the blockchain network 017 c using traditional methods and systems and then added to the blockchain”; [0991] note “a system for writing data from a point of sale to a blockchain repository comprises a point of sale device configured to receive product data and customer data to generate a transaction log; a data transfer adapter configured to facilitate the transfer of transaction logs; a server configured to apply the appropriate data transfer adapter for transferring transaction logs based on the point of sale type; an order adapter configured to automate complex data normalization so that multiple sources of data are converted into a standard system language format; a data processing adapter configured translate standard system language format into a repository native language; a processing engine configured to apply the appropriate data processing adapter to write to the selected blockchain; and a blockchain repository configured to receive data from the system.”; [0992]-[0995].
- Pub. No.: US2020/0302468 see [0005]; [0032] “Utilization of blockchain (versus centralized storage, for example) can help protect the system 50 against system failure, fraud, and other security risks. These decentralized and distributed systems can store and relay large volumes of information, without the potential downfalls of large, centralized servers. With the blockchain's smart contracts and immutable ledger powering authentication, redemption and payment of the coupons, embodiments of the current disclosure can minimize friction and costs typically associated with the prior art systems. With blockchain, the coupon redemptions and associated transactions are permanently recorded.”; [0033] “FIG. 4 provides another exemplary embodiment of the current disclosure. In this embodiment, a central platform 170 may reside over the blockchain distributed ledger data structure 152. The central platform 170 may contain the coupon authentication table(s) 160 in database 161 maintained and updated by the manufacturers 10 respectively for each of the retailers 16. The central platform 170 also contains the coupon transaction ledger(s) 162 in database 163. The embodiment of FIG. 4 may use the blockchain distributed ledger 152 as an immutable ledger for authenticating and tracking any and all access and revisions to the coupon authentication table(s) 160 and coupon transaction ledger(s) 162. The records are immutable and can be used by the manufacturers 10 and/or retailers 16 to audit for any tampering of data.”
Therefore the claims here fail to contain any additional element(s) or combination of additional elements that can be considered as significantly more and the claims are rejected under 35 U.S.C. 101 for lacking eligible subject matter.
Claim Rejections - 35 USC § 103
5. 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-19 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ryan et al. (Pub. No.: US 2021/0366586) referred to hereinafter as Ryan, in view of Spector et al. (Pub. No.: US 2025/0045754) referred to hereinafter as Spector.
As per claim 1, Ryan discloses an adjudication module for omni-channel item-level promotional offer adjudication (see [0100]-[0104]; [0683]),
(a) the adjudication module comprising at least one of: […]; and an API (see [0324]; the Examiner has interpreted at least one of A and B in conjunctive),
(b) wherein the adjudication module is configured to interface with a retail system comprising a payment module and at least one of: a POS system (see Fig. 19 and its associated disclosure; [0021]; [0632]; [0674]-[0675]; [0683] note "The POS device 101 may also include a verification module 142. The verification module 142 may be configured to verify data as part of the functions of the POS device 101 as discussed herein. The verification module142 may receive data to be verified as input, may attempt to verify the data, and may output a result of the attempted verification to another module or engine of the POS device 101. The verification module 142 may, for example, verify digital signatures that are included in transaction values identified in the blockchain using public keys received (e.g., by the receiving device 140) from payment instruments 209. The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation."); and a cloud-computing system (see Fig. 23 and its associated disclosure; [0021]; [0340]; [0701]),
(c) wherein the adjudication module is configured to: receive and store item-level information relating to one or more inventory items for which use of a one-time-use coupon code is authorized (see Fig. 21 and its associated disclosure; [0684]; [0100]-[0104]; [0684]; [0712]); receive a purchase request comprising a payment amount and information concerning an item for purchase; and receive the one-time-use coupon code (see [0100]; [0155]-[0156]; [1000]-[1008]);
(d) wherein if the information concerning the item for purchase matches the item-level information for which use of the one-time-use coupon code is authorized, the adjudication module applies the one-time-use coupon code to the purchase request to apply a discount to the payment amount, but if the information concerning the item for purchase does not match the item-level information for which use of the one-time-use coupon code is authorized, the adjudication module does not apply the one-time-use coupon code to the purchase request (see [0156]; [0683] note "The POS device 101 may also include a verification module 142. The verification module 142 may be configured to verify data as part of the functions of the POS device 101 as discussed herein. The verification module142 may receive data to be verified as input, may attempt to verify the data, and may output a result of the attempted verification to another module or engine of the POS device 101. The verification module 142 may, for example, verify digital signatures that are included in transaction values identified in the blockchain using public keys received (e.g., by the receiving device 140) from payment instruments 209. The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation."); and a cloud-computing system (see Fig. 3, 23, and their associated disclosure; [0021]; [0340]; [0701]; [0797]),
(e) wherein the adjudication module is configured to utilize memory storage of the retail system to cause the retail system to operate as a node of a distributed ledger (see Figs. 19 note “101” “142”, 25, 40, and their associated disclosure; [0074]; [0516]; [0650]-[0654]; [0680]-[0682]; [0683] note “The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation”).
(f) wherein the adjudication module causes the retail system to enforce, at the retail system, ledger-validated state to determine whether the one-time-use-coupon code may be applied (see Figs. 19 note “101” “142”, 25, 40, and their associated disclosure; [0074]; [0344]; [0516]; [0650]-[0654]; [0682]; [0683] note “The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation”)
(a*) Ryan suggests application code, see Fig. 33 and its associated disclosure; [0320]; [0325]; [0380]-[0381]; [0683], nevertheless in view of compact prosecution, the Examiner relies on a secondary reference to more expressly teach, i.e. Ryan expressly does not teach […] an integrated container comprising application code […]. Spector teaches […] an integrated container comprising application code […] (see [0051] “Embodiments may provide a distributed payment network. For example, the payment network may be provided on the merchant premises. A device or application (in a container) may be provided, or a Software as a Service (SaaS) model may be used where the merchant may host the payment network locally within its system. The issuer, payment network, and/or the point of sale device may publish real-time encrypted data into the device or containerized application to support localized network processing. This may reduce latency and provide greater flexibility to larger merchants.”).
Therefore it would be obvious to a PHOSITA before the effective filling date of the invention to modify foregoing suggestions of Ryan in view of the foregoing teachings of Spector with motivation to incorporate a container to allow merchants to host one or more modules locally within its system to carry out a function locally which reduces latency and grants greater flexibility to merchants, see at least Spector [0051].
As per claim 2, Ryan in view of Spector teaches the claim limitations of claim 1. Ryan teaches wherein the item level information comprises an identifier selected from the group consisting of a stock keeping unit (SKU), a global trade item number (GTIN), a universal product code (UPC), an international article number (ARN), an Australian product number (APN), or a price look-up code (PLU).
As per claim 3, Ryan in view of Spector teaches the claim limitations of claim 1. Ryan teaches wherein the retail system is configured to establish a retailer communicative connection with a bank card processor system, and wherein the adjudication module is configured to operate without error even if the retailer communicative connection is disrupted (see Fig. 23 and its associated disclosure; [0700]-[0701]; [0770]; [0798]; [0920]).
As per claim 4, Ryan in view of Spector teaches the claim limitations of claim 1. Ryan teaches wherein the adjudication module is configured to operate on the POS system without error whether or not the POS system has internet connectivity (see [0144]-[0145]; [0156]; [0683]; [0700]-[0701]; [0798]).
As per claim 5, Ryan in view of Spector teaches the claim limitations of claim 1. Ryan expressly does not teach wherein the container further comprises a runtime library, a system library, and a settings configuration. Spector teaches wherein the container further comprises a runtime library, a system library, and a settings configuration (see the rejection as set forth above for claim 1 limitation (a*)).
As per claim 6, Ryan in view of Spector teaches the claim limitations of claim 1. Ryan discloses wherein the adjudication module is configured to operate while maintaining native POS transaction processing, wherein the distributed ledger is a decentralized distributed ledger comprising a plurality of nodes (see Fig. 19, 25, 40, and their associated disclosure; [0074]; [0344]; [0516]-[0517]; [0652]-[0653]; [0676]; [0680]-[0683]; [0849]-[0851]; [1023]).
As per claim 7, Ryan in view of Spector teaches the claim limitations of claim 6. Ryan teaches wherein the distributed ledger comprises an immutable or selectively mutable transaction log, and wherein the transaction log comprises a list of coupon codes comprising the one-time-use coupon code, and wherein each coupon code in the list of coupon codes is accompanied by an indication of whether or not such coupon code has been redeemed, and wherein when the adjudication module applies the one-time-use coupon code to a purchase request, the retail system updates the transaction log to indicate that the one-time-use coupon code has been redeemed (see Fig. 19 and its associated disclosure; [0074]; [0676]; [0680]-[0683]; [0797]).
As per claim 8, Ryan in view of Spector teaches the claim limitations of claim 7. Ryan teaches wherein prior to applying the one-time-use coupon code to a purchase request, the adjudication module reads the transaction log of the distributed ledger to determine whether the one-time-use coupon code has already been redeemed, and wherein if the coupon code has already been redeemed, the adjudication module does not apply the one-time-use coupon code to the purchase request (see Fig. 19 and its associated disclosure; [0074]; [0156]; [0676]; [0680]-[0683]).
As per claim 9, Ryan in view of Spector teaches the claim limitations of claim 6. Ryan teaches wherein the distributed ledger comprises a blockchain (see [0378]; [0657]).
As per claim 10, Ryan in view of Spector teaches the claim limitations of claim 6. Ryan teaches wherein the distributed ledger comprises a plurality of nodes and a consensus algorithm configured to ensure that the distributed ledger is identical across the plurality of nodes (see Fig. 19, 25, and their associated disclosure; [0074]; [0344]; [0516]-[0517]; [0652]-[0653]; [0676]; [0680]-[0683]; [0849]-[0851]; [1023]).
As per claim 11, Ryan in view of Spector teaches the claim limitations of claim 6. Ryan teaches wherein the adjudication module is configured to issue additional coupon codes (see [0104]; [0796]-[0797]).
As per claim 12, it recites substantially similar subject matter as independent claim 1. AS such, note the teachings of Ryan in view of Spector as set forth above for claim 1.
Additionally Ryan teaches a distributed ledger comprising: a plurality of nodes (see Fig. 19, 25, and their associated disclosure; [0074]; [0344]; [0516]-[0517]; [0652]-[0653]; [0676]; [0680]-[0683]; [0849]-[0851]; [1023]); a transaction log comprising a list of coupon codes and an indication of whether each of the coupon codes has already been redeemed (see [0682]-[0683]; [0796]-[0797]); and a consensus algorithm configured to synchronize the transaction log to ensure that all copies of the transaction log are identical across the plurality of nodes (see Fig. 19, 25, and their associated disclosure; [0074]; [0344]; [0516]-[0517]; [0652]-[0653]; [0676]; [0680]-[0683]; [0849]-[0851]; [1023]); a first retail system comprising a first payment module and at least one of: a first POS system (see Figs. 19, 23 and their associated disclosure; [0021]; [0632]; [0674]-[0675]; [0683] note "The POS device 101 may also include a verification module 142. The verification module 142 may be configured to verify data as part of the functions of the POS device 101 as discussed herein. The verification module142 may receive data to be verified as input, may attempt to verify the data, and may output a result of the attempted verification to another module or engine of the POS device 101. The verification module 142 may, for example, verify digital signatures that are included in transaction values identified in the blockchain using public keys received (e.g., by the receiving device 140) from payment instruments 209. The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation."); and a first cloud-computing system (see Fig. 23, and their associated disclosure; [0021]; [0340]; [0701]; [0797]); a second retail system comprising a second payment module and at least one of: a second POS system (see Figs. 19, 23 and their associated disclosure; [0021]; [0632]; [0674]-[0675]; [0683] note "The POS device 101 may also include a verification module 142. The verification module 142 may be configured to verify data as part of the functions of the POS device 101 as discussed herein. The verification module142 may receive data to be verified as input, may attempt to verify the data, and may output a result of the attempted verification to another module or engine of the POS device 101. The verification module 142 may, for example, verify digital signatures that are included in transaction values identified in the blockchain using public keys received (e.g., by the receiving device 140) from payment instruments 209. The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation."); and a second cloud-computing system (see Fig. 23, and their associated disclosure; [0021]; [0340]; [0701]; [0797]); and an adjudication module that interfaces with each of the first retail system and the second retail system (see Figs. see Figs. 19 note “101” “142”, 23, 25, 40, and their associated disclosure; [0021]; [0027]; [0632]; [0674]-[0675]; [0683] note "The POS device 101 may also include a verification module 142. The verification module 142 may be configured to verify data as part of the functions of the POS device 101 as discussed herein. The verification module142 may receive data to be verified as input, may attempt to verify the data, and may output a result of the attempted verification to another module or engine of the POS device 101. The verification module 142 may, for example, verify digital signatures that are included in transaction values identified in the blockchain using public keys received (e.g., by the receiving device 140) from payment instruments 209. The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation."; [0815]-[0818]; [0953]),
As per claim 13, Ryan in view of Spector teaches the claim limitations of claim 12. Ryan teaches wherein the first retail system comprises the first POS system, and wherein the second retail system comprises the second POS system (see Figs. 19, 23 and their associated disclosure; [0021]; [0632]; [0674]-[0675]; [0683] note "The POS device 101 may also include a verification module 142. The verification module 142 may be configured to verify data as part of the functions of the POS device 101 as discussed herein. The verification module142 may receive data to be verified as input, may attempt to verify the data, and may output a result of the attempted verification to another module or engine of the POS device 101. The verification module 142 may, for example, verify digital signatures that are included in transaction values identified in the blockchain using public keys received (e.g., by the receiving device 140) from payment instruments 209. The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation.").
As per claim 14, Ryan in view of Spector teaches the claim limitations of claim 12. Ryan teaches wherein the first retail system comprises the first POS system, and wherein the second retail system comprises the second cloud-computing system (see Figs. 19, 23 and their associated disclosure; [0021]; [0632]; [0674]-[0675]; [0683] note "The POS device 101 may also include a verification module 142. The verification module 142 may be configured to verify data as part of the functions of the POS device 101 as discussed herein. The verification module142 may receive data to be verified as input, may attempt to verify the data, and may output a result of the attempted verification to another module or engine of the POS device 101. The verification module 142 may, for example, verify digital signatures that are included in transaction values identified in the blockchain using public keys received (e.g., by the receiving device 140) from payment instruments 209. The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation.").
As per claim 15, Ryan in view of Spector teaches the claim limitations of claim 12. Ryan teaches wherein the distributed ledger is a public permissionless ledger (see [0414]; [0516]; [0652]).
As per claim 16, Ryan in view of Spector teaches the claim limitations of claim 12. Ryan teaches wherein the plurality of nodes comprises the first retail system and the second retail system (see Figs. 19, 23 and their associated disclosure; [0021]; [0632]; [0674]-[0675]; [0683] note "The POS device 101 may also include a verification module 142. The verification module 142 may be configured to verify data as part of the functions of the POS device 101 as discussed herein. The verification module142 may receive data to be verified as input, may attempt to verify the data, and may output a result of the attempted verification to another module or engine of the POS device 101. The verification module 142 may, for example, verify digital signatures that are included in transaction values identified in the blockchain using public keys received (e.g., by the receiving device 140) from payment instruments 209. The verification module 142 may also be configured to verify eligibility of a promotion or incentives for redemption based on blockchain data, such as to verify that a promotion or incentive was not previously redeemed and has not been transferred to a null address or an address associated with invalidation."; [0824]-[0825]).
As per claim 17, Ryan in view of Spector teaches the claim limitations of claim 12. Ryan teaches wherein each of the first retail system and the second retail system is configured to establish a retailer communicative connection with a bank card processor system, and wherein the adjudication module is configured to operate without error even if the retailer communicative connection is disrupted (see Fig. 23 and its associated disclosure; [0700]-[0701]; [0770]; [0798]; [0920]).
As per claim 18, Ryan in view of Spector teaches the claim limitations of claim 12. Ryan teaches wherein the item-level information comprises a first set of item-level information from a first source and a second set of item-level information from a second source (see [0677]-[0678]).
As per claim 19, Ryan in view of Spector teaches the claim limitations of claim 12. Ryan teaches wherein the system is configured to read, and deliver to the adjudication module, information obtained from a manual entry, information obtained from a scanning of a QR code, and information obtained from reading a card (see [0675]).
6. Claim 20 is are rejected under 35 U.S.C. 103(a) as being unpatentable over Ryan et al. (Pub. No.: US 2021/0366586) referred to hereinafter as Ryan, in view of Wright et al. et al. (Pub. No.: TW I810411 B) referred to hereinafter as Wright.
As per claim 20, Ryan discloses a system for omni-channel item-level promotional offer adjudication, the system comprising: a distributed ledger comprising: a plurality of nodes; a transaction log; and a consensus algorithm configured to synchronize the transaction log across the plurality of nodes a retail system comprising a payment module; and an adjudication module that enables the retail system to access the distributed ledger, wherein the adjudication module is configured to execute (see the rejection as set forth above for claims 1 and 12) […]
Ryan teaches […] a security protocol comprising: […] generating an asymmetric key pair [… ] encrypting a payment using […] signing a code [… ] distributing […] to the retail system; and distributing the code to the retail system (see [0213]; [0679]-[0680]; [0683] note “digital signatures that are included in transaction values identified in the blockchain using public keys received ( e.g., by the receiving device 140) from payment instruments 209”; [0684]-[0687]; [0705]-[0707]; [0854] note “where the identification value may be a digital signature, the digital signature may be generated by the payment instrument 209, such as using a private key of a key pair, where the corresponding public key may be used for verification of the digital signature. In some cases, the digital signature may be generated by the POS device 101 (or issuing entity) via a private key, where the corresponding public key may be electronically transmitted to the payment instrument 209 using a suitable communication method for storage therein”).
Ryan suggests see [0213], however Ryan expressly does not teach […] comprising a skECC and a pkECC […]; the KAES […]; using the skECC; […] the pkECC […].
Wright teaches […] comprising a skECC and a pkECC […]; the KAES […]; using the skECC; […] the pkECC […] (see (see page 10 of 32 note “Elliptic Curve Cryptography (ECC) is asymmetric in that it relies on public-private key pairs. It is one of the most secure cryptosystems and is commonly used for cryptocurrencies such as Bitcoin. For ECC cryptography, the Koblitz algorithm can be used to encrypt data”; page 11 of 32 note “ Koblitz Algorithm Given ECC key pair P.sub.1 = S .sub.1 . G , .sub.the Koblitz algorithm allows anyone to use .sub.thepublic key P1 to encrypt a message so that only someone who knows the corresponding private keyS1 can decrypt the message.”). ).
Therefore it would be obvious to a PHOSITA before the effective filling date of the invention to modify foregoing suggestions of Ryan in view of the foregoing teachings of Wright with motivation to encrypt data using asymmetric public-prive key pairs ensuring that the data can be accessed by entity having the private key to provide most secure cryptosystems, see at least Wright pages 10- of 32.
Response to Applicant’s Remarks
7. The Examiner has considered the Applicant’s response filed 01/07/2026 (hereinafter the response) as a bona fide attempt to advance prosecution in view of filed claim amendments even though the response includes what appears to be an error in the response on page 8.
As per Claim Rejections - 35 U.S.C. § 112, the Examiner notes there was no such rejection in the Non-Final Rejection of record 10/07/2025.
As per Claim Rejections - 35 U.S.C. § 101, the Examiner has considered the Applicant’s arguments, however respectfully finds them unpersuasive. The Applicant has failed to address step 1 and the amendments merely recite per claim 1 “utilize memory storage” which fails to positively store and per claim 12, it recites “operate as a node of distributed ledger” which also fails to positively store the adjudication module on a structure.
Under step 2A prong one, the Applicant is reminded that the evaluation is based on abstract recitation not additional elements, yet, the Applicant has argued in view of “claim 1 requires that the adjudication module causes the retail system to operate as a node of a distributed ledger and that the retail system enforces ledger-validated state at the retail system itself to determine whether a one-time-use coupon code may be applied.” Therefore, based on the abstract recitation, the claims recite an abstract idea and invoke certain methods of organizing human activity.
Next, per step 2A prong two, upon considering the claim as a whole, merely executing “apply it” instruction as it pertains to verifying the validity of a coupon which is further generally linked to a technical environment distributed ledger fails to when “viewed as a whole, these additional claim element(s) do not provide any additional element that integrates the abstract idea (prong one), into a practical application (prong two) upon considering the additional elements both individually and as a combination or as a whole as they fail to provide: an additional element that reflects an improvement in the functioning of a computer, or an improvement to other technology or technical field; or an additional element that implements a judicial exception with, or uses a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim; or an additional element that effects a transformation or reduction of a particular article to a different state or thing; or an additional element that applies or uses the judicial exception, again, in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception as explained above” because as explained “As would be readily apparent to a person having ordinary skill in the art (hereinafter PHOSITA), the additional elements are generic computer components. The additional elements are simply utilized as generic tools to implement the abstract idea or plan as "apply it" instructions (see MPEP 2106.05(f)). The additional elements are generic as they are described at a high level of generality, see at least as-filed spec. Figs. 1-6 and their associated disclosure. The processor executing the "apply it" instruction on which adjudication module resides is further connected to one or more device(s) merely sending/receiving data over a network, note receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014). Gathering data is considered insignificant extra solution activity (see MPEP 2106.05(g)). Further, the processor analyzes gathered data to ascertain that user and/or coupon or incentive can be redeemed per business rules. Thus, the process is similar to collecting information, analyzing it, and displaying certain results of the collection and analysis (Electric Power Group). The abstract idea is intended to be merely carried out in a technical environment and as a distributed ledger for collecting data via a network and maintain ledger state where the data is analyzed via a generic processor at one or more retailer POS(s) that operate as one or more nodes of a distributed ledger to adjudicate on validity of one-time-use-coupon which is associated with a particular retail system and prevent redemption of said one-time-use-coupon at a ineligible retailer, however fail to contain meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment (see MPEP 2106.05(h))” in updated rejection in view of filed claim amendments.
Lastly, per step 2B, merely providing access to merchant POSs to immutable data such that adjudication can be made about validity of a coupon whose use is limited to once at a particular merchant fails to set forth any additional element(s) that can be considered significantly more as decision making based on such immutable data by a POS was indeed well-understood, routine, or conventional, and the Examiner has provided evidence in view of the filed claim amendments.
Therefore the Examiner respectfully maintains the rejection.
As per Claim Rejections - 35 U.S.C. § 103, the Examiner respectfully finds the Applicant’s argument unpersuasive and has updated the rejection in view of filed claim amendments. The Applicant has generally argued without any discussion of citations within Ryan with any particularity and the Applicant has provided no discussion of claim 20 which may be restrict-able if the scope diverged significantly, yet, in view of filed claim amendments the Examiner has considered it as a bona fide attempt to advance prosecution. Further, Spector has been relied upon for a particular feature and indeed Ryan teaches what the Applicant alleges as not taught by Ryan and/or Spector in view filed claim amendments.
Accordingly, the rejection has been updated in view of filed claim amendments, particularly at least note Ryan see Fig. 19 note “101” “142”, 25, 40, and their associated disclosure; [0074]; [0344]; [0516]-[0517]; [0652]-[0653]; [0676]; [0680]-[0683]; [0849]-[0851]; [1023]. Thus, full scope and teachings of Ryan are being under appreciated by the Applicant. Therefore the Examiner respectfully maintains the rejection.
Conclusion
8. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and all the references on PTO-892 Notice of Reference Cited should be duly noted by the Applicant as they can be subsequently used during prosecution, at least note the following:
*Being noted initially
- (i) Pub. No.: 2023/0230065 see [0002] “This disclosure relates to blockchain supported transaction environments, and more specifically some embodiments disclosed herein relate to systems and methods for providing blockchain-based payment cards (e.g., blockchain-based credit card (a digital wallet based card that draws against a credit line for blockchain based transactions), blockchain-based debit card (a digital wallet based card that draws against a deposit account for blockchain based transactions), blockchain-based check card (a digital wallet based card that draws against a checking account for blockchain based transactions), blockchain-based prepaid card (a digital wallet based card that can be used like a blockchain based debit card for blockchain based transactions, but is not associated with replenishable bank account of the cardholder), a blockchain-based multi-use card (a digital wallet based card with tokens that can be used for blockchain based transactions multiple times), blockchain-based single-use card (a digital wallet based card with tokens that can be used for a blockchain based transaction only once), blockchain-based limited card (a digital wallet based card with tokens that can be used only for a limited time before expiring and becoming unusable for blockchain based transactions), blockchain-based gift card (a digital wallet based card with tokens that can be used for blockchain based transactions only at a particular merchant or particular set of merchants), blockchain-based coupon card (a digital wallet based card with tokens that can be used for blockchain based transactions in exchange for a discount to be applied at a particular merchant or particular set of merchants), etc.) and corresponding technological solutions utilizing traceable and programmable tokens (such as credit tokens, debit tokens, check tokens, prepaid tokens, multi-use tokens, single use tokens, gift tokens, coupon tokens, etc. associated with one or more of the blockchain-based credit card, blockchain-based debit card, blockchain-based check card, blockchain-based prepaid card, blockchain-based multi-use card, blockchain-based single-use card, blockchain-based gift card, blockchain-based coupon card, etc., respectively) to complete trusted and verifiable transactions within a blockchain supported network, and leveraging features of such traceable and programmable tokens together with unique network architecture and processes to achieve intelligent enhancements over conventional systems and methods.”; [0155]; [0168] “Similarly, just as in FIG. 4A, Merchant 31 is a network participant on the blockchain network who possesses one or more computing devices operating as a node of the blockchain network, and which may further have access to, or even embody, merchant 31's point-of-sale device 41. Indeed, in some embodiments, POS device 41 may be embodied, in whole or in part, within merchant 31's node. In some embodiments, the POS device may comprise a scanner (e.g., a handheld scanner) capable of reading a QR code, a bar code, a serial number, or other electronic or physical object (such as a Bluetooth component/module and/or an IOT component/module that can sync with payer's digital wallet) that can be linked or built in to the merchant 31's digital wallet, which is further linked to the merchant 31's bank account with acquiring bank 51.”
- US10664877B1see Abstract “Disclosed herein are methods, systems, and apparatus, including computer programs encoded on computer storage media, for product promotion using a smart contract in a blockchain network. The method includes: receiving, by a node of a blockchain network, a creation request to create a promotion event, wherein: the promotion event is associated with multiple promotion codes and a pair of a private key and a public key, and the creation request includes the public key and a digital signature generated using the private key; determining, by the node and based on the public key and the digital signature, validity of the creation request; and in response to determining that the creation request is valid, registering, by the node, the promotion event in the blockchain network using a smart contract without storing the multiple promotion codes in the blockchain network.”
- Pub. No.: US2021/0366586 see Figs. 23, 25, and their associated disclosure; [0209]; [0851] note “a product 118 is purchased by a customer 200, data 062a for the transaction may be electronically transmitted to a node in the blockchain network 017 c for addition to the blockchain. The transaction data 062a may be accompanied by an identification value ( or values) 117 associated with the customer 200 identification value ( or values) 181 associated with the product 118. In one embodiment, the identification value may be a blockchain address associated with the customer 200 or an address associated with a brand 107. In another embodiment, the identification value may be a digital signature generated by the customer 200 and supplied to the POS device 101. The blockchain node 112 may add select transaction data 062a to a new block to be added as one of the plurality of transaction values. The block may be verified by other nodes 112 in the blockchain network 017 c using traditional methods and systems and then added to the blockchain”; [0991] note “a system for writing data from a point of sale to a blockchain repository comprises a point of sale device configured to receive product data and customer data to generate a transaction log; a data transfer adapter configured to facilitate the transfer of transaction logs; a server configured to apply the appropriate data transfer adapter for transferring transaction logs based on the point of sale type; an order adapter configured to automate complex data normalization so that multiple sources of data are converted into a standard system language format; a data processing adapter configured translate standard system language format into a repository native language; a processing engine configured to apply the appropriate data processing adapter to write to the selected blockchain; and a blockchain repository configured to receive data from the system.”; [0992]-[0995].
- Pub. No.: US2020/0302468 see Figs. 3-4 and their associated disclosure; [0005]; [0032] “Utilization of blockchain (versus centralized storage, for example) can help protect the system 50 against system failure, fraud, and other security risks. These decentralized and distributed systems can store and relay large volumes of information, without the potential downfalls of large, centralized servers. With the blockchain's smart contracts and immutable ledger powering authentication, redemption and payment of the coupons, embodiments of the current disclosure can minimize friction and costs typically associated with the prior art systems. With blockchain, the coupon redemptions and associated transactions are permanently recorded.”; [0033] “FIG. 4 provides another exemplary embodiment of the current disclosure. In this embodiment, a central platform 170 may reside over the blockchain distributed ledger data structure 152. The central platform 170 may contain the coupon authentication table(s) 160 in database 161 maintained and updated by the manufacturers 10 respectively for each of the retailers 16. The central platform 170 also contains the coupon transaction ledger(s) 162 in database 163. The embodiment of FIG. 4 may use the blockchain distributed ledger 152 as an immutable ledger for authenticating and tracking any and all access and revisions to the coupon authentication table(s) 160 and coupon transaction ledger(s) 162. The records are immutable and can be used by the manufacturers 10 and/or retailers 16 to audit for any tampering of data.”
*Noted previously
- Pub. No.: US2017/0364936 see Abstract note “computer implemented electronic computer system using a blockchain method for creating , distributing , validating , and redeeming a secure electronic smartcoupon . A smart coupon transaction record is highly secure and may comprise embedded business rules that define the requirements that consumers and retailers must meet for the smartcoupon to redeemed . Consumers may save or hold smartcoupons in a variety of different digital wallets . Retailers may redeem through their POS system by evaluating the embedded business rules in the smartcoupon against the consumer ' s purchase basket and if valid , completing the redemption process by publishing a redemption token to smartcoupon transaction record on the Blockchain database”; [0097] “A block diagram of an example of a method for adding a block of smartcoupons to a blockchain database (“the method”) 800 according to various embodiments described herein is shown as an overview in FIG. 8. The method 800 may be used to create a smartcoupon 102 and add it to the blockchain database 109 in digital format. In some embodiments, the method 800 may start 801 and a smart coupon transaction record 120 may be created having a smartcoupon token 123 in step 802. The issuing engine 191 may create multiple smartcoupon transaction records 120 with information provided by the issuer 101C through an input interface 404 of their client device 400. The issuer application 191 may initiates a request to create a block of smartcoupon transactions based on defined business rules and the quantity required. The request may be signed with the public key 124 of the issuer 101C. The smartcoupon token 123 may contain one or more data fields such as: issuer_ID 130; campaign_ID 131; offer name 132; max units issued 133; unit value 134; currency 135; issue date 136; expiry date 137; restrictions 138; rule type 139; product 140 (upc); min units purchased 141, min value purchased 142, max per user 143; geography restrictions 144; retailers restrictions 145; and other restrictions 146. The data in the fields of the smartcoupon token 123 may be or form the business rules of the smartcoupon 102 which must be satisfied in order for the smart coupon 102 to be redeemed and validated. For example, business rules of a smartcoupon token 123 may be: for use with product UPC 12345 67890; not to be used after expiry date of Jun. 30, 2016; and only to be used by retailer 101B Grocery Chain X”
- Pub. No.: US2018/0150865 note “method for authentication of coupons using a blockchain includes: storing transaction data for a payment transaction, wherein the transaction data includes at least a transaction amount; receiving an identification value; receiving a block included in a blockchain, wherein the block includes at least a block header and a plurality of transaction values, each transaction value including at least a coupon identifier and coupon data; executing a query on the received block to identify a specific transaction value of the plurality of transaction values where the included coupon identifier corresponds to the received identification value; and executing a query on the memory to update at least the transaction amount included in the stored transaction data based on the coupon data included in the identified specific transaction value.”; see [0036] note “In other embodiments, the payment instrument 108 may use a single private key for all coupons issued thereto. For example, a plurality of different merchants may each issue coupons to the individual 104, which may be tracked on the blockchain using the private key and corresponding blockchain addresses of the payment instrument 108. In such embodiments, the payment instrument 108 may operate as a universal loyalty card, where each point of sale device 102 (e.g., and associated merchant) may be able to issue rewards and coupons to the individual 104 that are redeemable using the same payment instrument 108.”; [0061] note “the method 400 may further include electronically transmitting, by a transmitting device of the point of sale device, a new transaction value to a blockchain node associated with the blockchain, wherein the new transaction value includes at least a reference to the coupon identifier included in the identified specific transaction value and is configured to invalidate the coupon data included in the identified specific transaction value. In a further embodiment, the new transaction value may further include a digital signature, and the digital signature may be received by the receiving device of the point of sale device from a payment instrument used to convey the identification value. In another further embodiment, the new transaction value may further include a blockchain address, and the blockchain address may be one of: a null address and an address associated with invalidated coupons. In yet another further embodiment, the method 400 may even further include receiving, by the receiving device of the processing server, a transaction notification, wherein the transaction notification indicates approval of the payment transaction, and the transaction notification is received prior to electronic transmission of the new transaction value.”
- Pub. No.: US2022/0294608 note “invention provides improved methods and systems for storing, sharing retrieving, writing and accessing data (content) on a blockchain. The invention may form part of a protocol for storing, searching and accessing the data. An embodiment of the invention comprises the step of processing at least one blockchain transaction (Tx) comprising: a protocol flag; a discretionary public key (DPK); and a discretionary transaction ID (DTx ID). These are discretionary in the sense that they are not required as part of the underlying blockchain protocol but in accordance with the present invention. This combination of features enables portions of data to be identified, retrieved and shared on a blockchain, and also to be linked/associated with one another when provided in a plurality of transactions. It enables a graph or tree-like structure to be constructed, which reflects the hierarchical relationships between portions of data, facilitating their processing, searching and sharing.”
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIPEN M PATEL whose telephone number is (571)272-6519. The examiner can normally be reached Monday-Friday, 08:30-17:00 EST.
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 Ashraf can be reached on (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.
/DIPEN M PATEL/Primary Examiner, Art Unit 3621