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 is the first office action on the merits in response to the application filed on 03/28/2025.
Claims 1-20 are currently pending and have been examined.
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 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.
Subject Matter Eligibility Criteria – Step 1:
Claims 1-10 are directed to a system. Claims 11-20 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
Subject Matter Eligibility Criteria – Step 2A – Prong One:
Regarding Prong One of Step 2A of the Alice/Mayo test, the claim limitations are to be analyzed to determine whether, under their broadest reasonable interpretation, they “recite” a judicial exception or in other words whether a judicial exception is “set forth” or “described” in the claims. MPEP 2106.04(II)(A)(1). An “abstract idea” judicial exception is subject matter that falls within at least one of the following groups: a) certain methods of organizing human activity, b) mental processes, and/or c) mathematical concepts. MPEP 2106.04(a).
Representative independent claims 1 and 11 include limitations that recite at least one abstract idea.
Claim 1 is directed to the abstract idea of “a first consumer device; a data network; a second supplier device in operable communication with the first consumer device over the data network, wherein the first consumer device provides contracts to the second supplier device in a serialized format, the second supplier device deserializes the contract into machine-readable representations, the provided contract being signed against a private key corresponding to a public- key exchanged between the first consumer device and second supplier device and automates the exchange and verification of payments related to the contract.” Under its broadest reasonable interpretation, this claim is automating contract settlements between counterparties, and hence falls under organizing human activity (i.e., as fundamental economic practices).
Dependent Claims:
Claims 2 and 12 recites: wherein the first consumer device and the second supplier device are in direct peer-to-peer communication without a central server; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 3 and 13 recites: wherein the first consumer device and the second supplier device exchange at least a node identifier and a public key to establish the direct peer-to-peer communication; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 4 and 14 recites: wherein each device generates an independent invoice based on the serialized format of the contract and compares settlement outputs for each independent invoice for collaborative output verification; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 5 and 15 recites: wherein said comparison of settlement outputs for each independent invoice comprises comparing at least one of an invoice amount, calculation subtotals, payment amount, and informational reports of the contract; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 6 and 16 recites: wherein said first consumer device and said second supplier device automates the exchange and verification of payments related to the contract upon a determination that the compared settlement outputs differ within a predetermined tolerance window; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 7 and 17 recites: wherein said first consumer device gathers inputs of the serialized contracts a second time for automatic verification by the second supplier device upon the determination that the compared settlement outputs differ outside the predetermined tolerance window; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 8 and 18 recites: wherein said first consumer device provides contracts to the second supplier device in a serialized format using JavaScript Object Notation; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 9 and 19 recites: wherein said provided contract being signed against a private key corresponding to a public-key exchanged between the first consumer device and second supplier device comprises the first consumer device signing using at least one of Elliptic Curve Digital Signature Algorithm and Schnorr; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 10 and 20 recites: wherein each of the first consumer device and the second supplier device maintains a digital contract table, an invoice table, and a payment table stored on local hardware for each device, wherein the provided contracts are each identified by a universally unique identifier maintained in each digital contract table, the universally unique identifier for each contract being identical across the first consumer device and the second consumer device; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Subject Matter Eligibility Criteria – Step 2A – Prong Two:
Claims 1 and 11 recites to a generic computer as an additional element to the judicial exception in the preamble. Viewed individually and in combination, this additional element to the identified judicial exception of Step 2A.1, amounts to no more than mere instructions for automating contract settlements between counterparties on a generic computer. Therefore, at Step 2A.2, these additional elements do not act in combination to integrate the abstract idea into a practical application. The additional elements of claims 1 and 11considered both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the additional element of a generic computer does no more than “[s]imply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry.” See MPEP 2106.05 (citing to Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225 (2014)).
Therefore claims 1 and 11 is found ineligible under 35 U.S.C. 101.
Step 2B:
Viewed as a whole, instructions/method claims recite the concept of “organizing human activity” (i.e., as fundamental economic practices) in automating contract settlements between counterparties are performed by a generic computer. The method claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Instead, the claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer server is to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
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.
6. Claims 1-7, 10-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ben-ari et al. (WO 2017098519 A1) in view of Wilczek et al. (US 10664802 B1).
7. Regarding claims 1 and 11, Ben-ari discloses a collaborative consensus protocol system for automated, verifiable agreement between counterparties (a method for automating contract settlement and enforcement through a collaborative consensus protocol between counterparties), (The Invention Section, The present invention utilizes blockchain smart contracts technology to manage cross- organization workflow in a novel way. For example, a smart contract invoice, as well as associated payments, may be tracked on a private blockchain, and those smart contracts may be automatically settled with corresponding payments. The smart contract reflects the payment required from the buyer for settlement with the seller. If the buyer wishes to defer payment, he may approve future settlement for such smart contract, as a result allowing the seller of the (approved) smart contract invoice to offer it for financing. If offered for financing, a financier may offer to purchase the smart contract invoice immediately from the seller with the understanding that the buyer may settle the smart contract with the financier instead of the seller at a later date. A reliable, immutable, shared record of transaction activity may be recorded on the distributed ledger so that an accurate view of the smart contract's transaction activity may be tracked. In such embodiment, the smart contract's transaction activity is recorded on the blockchain and distributed to all blockchain nodes. Any participant in the blockchain network may create their own instance of a smart contract invoice. Select data items in the smart contract may be encrypted and only visible to intended recipients through a read and write key permissions process. The blockchain event system is used to notify relevant parties of new blockchain transactions which may be of interest. The invention also supports a multi-sig feature on the blockchain which requires multiple signatures associated with an individual or signatures from multiple signatories within an organization in order to interact with the blockchain. Trading of financial securities such as stocks, bonds, futures, derivatives, etc. can also be transacted using the present invention.)
the provided contract being signed against a private key corresponding to a public-key exchanged between the first consumer device and second supplier device, (Settlement/ Reconciliation Section, The present invention represents a shared workflow for creating, selling/buying and settling a payment request using a blockchain smart contract. Each organization participating in the transaction workflow of a particular smart contract, uses its blockchain account (public/private key pair) to sign the creation, approval, sale/purchase and settlement of the smart contract, as appropriate. Sharing these signed activities on a distributed ledger enables automatic settlement of a smart contract payment request. In the case of invoices, the invoice is issued, approved, sold/bought, financed and/or eventually auto-reconciled or settled automatically, with each step recorded and shared.)
automates the exchange and verification of payments related to the contract, (Tagging of Payment Destination Account Section, Depending on customer, as well as payment executing party, system design, submission of payment instructions may, alternatively, be sent via the blockchain to the relevant payment executing party. Tagging smart contracts eliminates the need for the payer to enter the receiving party's bank details, when paying an invoice. Not only does this automation make the transaction process more seamless/efficient, but it is very useful for preventing loss of revenues due to erroneous and fraudulent payment details entered by employees.; and Netted Batch Settlement Section, A buyer may mark an invoice as 'Agreed' if all details are correct, 'Pay Immediately' or mark as 'Ready for Batch Payment'. Invoices can be paid either individually, or as a batch. If they are paid as a batch, the total amount outstanding between two parties based on outstanding invoices (sent/received by either party) for each currency/account pair is calculated off chain (by both parties) using on chain data, stored on chain, paid off chain, and recorded against the individual invoices on-chain. UNIVERSAL BATCH WINDOW A batch settlement point is configured in the private blockchain network. This is a universally agreed point in time (e.g. midnight every night) when each 24 hour batch window starts/ends. A timer triggers each blockchain node to initiate a batch settlement process. At that point, all of the receivable and payable invoices that were previously marked 'Ready for Batch Payment' are retrieved from the blockchain. The invoices, already grouped by counterparties in a mapping smart contract, are totalled and netted by the application off chain (e.g. if two companies exchange invoices, and sell and buy from each other, then the total net outstanding amount is calculated). The result of the calculation is stored in a new entry in a settlement smart contract. The settlement smart contract holds the batch net settlement amount between every two counterparties, based on the off chain calculations.)
Ben-ari as modified does not explicitly disclose comprising: a first consumer device; a data network; a second supplier device in operable communication with the first consumer device over the data network, wherein the first consumer device provides contracts to the second supplier device in a serialized format, the second supplier device deserializes the contract into machine-readable representations.
However, Wilczek teaches comprising: a first consumer device; a data network; a second supplier device in operable communication with the first consumer device over the data network, wherein the first consumer device provides contracts to the second supplier device in a serialized format, the second supplier device deserializes the contract into machine-readable representations, (Column 3/line 29, The computer networking environment 100 comprises a purchaser computer 102, a supplier computer 108, and a contract manager computer 114, which are communicatively coupled to one another via a network 112. The computer networking environment may comprise additional instances of the purchaser computer 102 and/or the supplier computer 108. The network 112 broadly represents any combination of one or more of a local area network (LAN), Wide Area Network (WAN), an internetwork such as the public internet, or other communications network.; and Column 2/line 45, A contract management computer, having access to stored contracts associated with the purchaser computer via a network such as the internet, is programmed to generate a Contract Order Document from terms included in the contract. The Contract Order Document is an electronic form or stored digital data that allows a supplier computer, which is associated with the supplier entity, to create one or more supplier documents using the procurement system and without logging into an account at the contract management computer. The Contract Order Document may be sent to the supplier via email and have one or more buttons that, when selected by the supplier computer, instruct the contract management computer to generate a supplier document.; and Column 2/line 33, The contract management computer is programmed to identify contract data from the contract terms. The contract data includes terms associated to the goods or services exchanged and one or more terms of payment for the goods and services. The contract data may include, but is not limited to, correspondence information of the entities, delivery information, unit price, hourly rates, retainer amounts, per diem amounts, number of units, number of hours, payment terms, penalties, time frames, due dates, milestones, and milestone payments. The contract data is stored in association with an account of the purchaser computer at the contract management computer.)
One of ordinary skill in the art would have recognized that applying the known technique of Wilczek to the known invention of Ben-ari would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate smart contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include a first consumer device; a data network; a second supplier device in operable communication with the first consumer device over the data network, wherein the first consumer device provides contracts to the second supplier device in a serialized format, the second supplier device deserializes the contract into machine-readable representations results in an improved invention because applying said technique ensures that the system automatically allow two parties to exchange contracts, thus improving the overall efficiency of the invention.
8. Regarding claims 2 and 12, Ben-ari discloses wherein the first consumer device and the second supplier device are in direct peer-to-peer communication without a central server, (The Invention Section, In such embodiment, the smart contract's transaction activity is recorded on the blockchain and distributed to all blockchain nodes. Any participant in the blockchain network may create their own instance of a smart contract invoice. Select data items in the smart contract may be encrypted and only visible to intended recipients through a read and write key permissions process. The blockchain event system is used to notify relevant parties of new blockchain transactions which may be of interest. The invention also supports a multi-sig feature on the blockchain which requires multiple signatures associated with an individual or signatures from multiple signatories within an organization in order to interact with the blockchain. Trading of financial securities such as stocks, bonds, futures, derivatives, etc. can also be transacted using the present invention.; and Definitions Section, The term "device", "terminal", "computer terminal", a "server", interchangeably refers to, but is not limited to hardware such as: a mobile phone, laptop, tablet, wearable computing device, cellular communicating device, PDA, communication device, personal computer, and etc.; and Brief Description of the Drawings Section, FIG. 3 shows a flowchart of an aspect of the invention of the invented method describing the role of the device of the supplier party in a transaction. FIG. 4 shows a flowchart of an aspect of the invention of the invented method describing the role of the device of the buyer party in a transaction.)
9. Regarding claims 3 and 13, Ben-ari discloses wherein the first consumer device and the second supplier device exchange at least a node identifier and a public key to establish the direct peer-to-peer communication, (Figures Section, FIG.2 shows an example of the process flow using an additional embodiment of the invention. The buyer wishes to defer settlement for the smart contract invoice and so the smart contract is offered for financing. The use case is related to invoice settlement, financing and payment flow between Supplier A, Buyer B and Financier C (in this embodiment, a financier (or financial entity) is involved). The following steps are performed…Application A creates a smart contract invoice on the blockchain assigning Buyer B's account/ public key as the invoice recipient. 2. Buyer B: Approving a Smart Contract Invoice, 2.1 As a result of the blockchain synchronization mechanism, the blockchain distributes the new representative smart contract (in this case, the new smart contract invoice) among all the blockchain nodes. In turn, the blockchain event mechanism, application B receives smart contract event and retrieves smart contract containing the invoice and updates Buyer B's ERP system with invoice details (2.4). 2.3 Buyer B decides to defer settlement and so, approves the smart contract invoice. Buyer B's action is sent by application B as a transaction to the smart contract invoice (2.6). As a result of the blockchain synchronization mechanism, the blockchain distributes the new transaction among all the blockchain nodes. Supplier A: Offering a Smart Contract Invoice (2.8); and The Invention Section, The present invention utilizes blockchain smart contracts technology to manage cross- organization workflow in a novel way. For example, a smart contract invoice, as well as associated payments, may be tracked on a private blockchain, and those smart contracts may be automatically settled with corresponding payments. The smart contract reflects the payment required from the buyer for settlement with the seller. If the buyer wishes to defer payment, he may approve future settlement for such smart contract, as a result allowing the seller of the (approved) smart contract invoice to offer it for financing.)
10. Regarding claims 4 and 14, Ben-ari discloses wherein each device generates an independent invoice based on the serialized format of the contract and compares settlement outputs for each independent invoice for collaborative output verification, (Figures Section, Buyer B: Paying and Reconciling a Smart Contract Invoice (1.10) 2.1 As a result of the blockchain event mechanism application B receives a smart contract event and retrieves smart contract invoice data (1.8). 2.2 Buyer B pays the invoice to Supplier A using application B. Two design options are available for payment, depending those offered by Buyer B's PSP or Bank. Either Application B sends payment instructions to Buyer's B payment gateway or bank, or Application B writes payment instructions on the blockchain for Buyer B's payment gateway or bank to collect, execute (outside of the blockchain), confirm and sign using its blockchain account. 2.3 After application B receives payment confirmation from the payment gateway or bank, it reconciles the payment against the smart contract invoice and updates Buyer B's ERP system indicating the invoice as paid (1.12). 2.4 Application B records the invoice payment confirmation details, including a certificate and signed transaction if required (proof that the payment was made by said payment facility), to the blockchain smart contract (1.14). The blockchain distributes the new transaction among all the blockchain nodes. 3. Supplier A: Receiving a Smart Contract Invoice Settlement Confirmation 3.1 As a result of the blockchain event mechanism (1.16), Supplier A's blockchain node receives the new transaction and generates an event. 3.2 Application A receives the event and updates Supplier A's ERP systems.; and Figures Section, 2.1 As a result of the blockchain synchronization mechanism, the blockchain distributes the new representative smart contract (in this case, the new smart contract invoice) among all the blockchain nodes. In turn, the blockchain event mechanism, application B receives smart contract event and retrieves smart contract containing the invoice and updates Buyer B's ERP system with invoice details (2.4).)
11. Regarding claims 5 and 15, Ben-ari discloses wherein said comparison of settlement outputs for each independent invoice comprises comparing at least one of an invoice amount, calculation subtotals, payment amount, and informational reports of the contract, (Settlement/Reconciliation Section, The present invention represents a shared workflow for creating, selling/buying and settling a payment request using a blockchain smart contract. Each organization participating in the transaction workflow of a particular smart contract, uses its blockchain account (public/private key pair) to sign the creation, approval, sale/purchase and settlement of the smart contract, as appropriate. Sharing these signed activities on a distributed ledger enables automatic settlement of a smart contract payment request. In the case of invoices, the invoice is issued, approved, sold/bought, financed and/or eventually auto-reconciled or settled automatically, with each step recorded and shared.; and Definitions Section, The term "public key" refers to a cryptographic key used with a public key cryptographic algorithm that is uniquely associated with an entity and that may be made public. The term "private key" refers to a cryptographic key, used with a public key cryptographic algorithm that is uniquely associated with an entity and is not made public. The term "multisignature" (multisig) refers to a digital signature scheme that allows a group of users to sign a single document.; and The Invention Section, A reliable, immutable, shared record of transaction activity may be recorded on the distributed ledger so that an accurate view of the smart contract's transaction activity may be tracked. In such embodiment, the smart contract's transaction activity is recorded on the blockchain and distributed to all blockchain nodes. Any participant in the blockchain network may create their own instance of a smart contract invoice. Select data items in the smart contract may be encrypted and only visible to intended recipients through a read and write key permissions process. The blockchain event system is used to notify relevant parties of new blockchain transactions which may be of interest. The invention also supports a multi-sig feature on the blockchain which requires multiple signatures associated with an individual or signatures from multiple signatories within an organization in order to interact with the blockchain. Trading of financial securities such as stocks, bonds, futures, derivatives, etc. can also be transacted using the present invention.)
12. Regarding claims 6 and 16, Ben-ari discloses wherein said first consumer device and said second supplier device automates the exchange and verification of payments related to the contract upon a determination that the compared settlement outputs differ within a predetermined tolerance window, (Netted Batch Settlement Section, The invoices, already grouped by counterparties in a mapping smart contract, are totalled and netted by the application off chain (e.g. if two companies exchange invoices, and sell and buy from each other, then the total net outstanding amount is calculated). The result of the calculation is stored in a new entry in a settlement smart contract. The settlement smart contract holds the batch net settlement amount between every two counterparties, based on the off chain calculations.; and Bi-Lateral Machine-to-Machine Calculation Validation Section, Off-chain calculations must be validated bi-laterally. These calculations are not performed inside the smart contract, due to that fact that the data stored inside the smart contract is encrypted for privacy reasons. The blockchain therefore has no access to this data, and the smart contract can therefore not perform the batch/netting calculations on chain. The numerical data must therefore be extracted and calculation must take place off chain. Because the calculation occurs off chain, and is not visible within the blockchain, it could be open to abuse/fraud. For this reason, this invention proposes a bi-lateral machine to machine validation process, whereby: 1. The calculation is performed by one of the two parties involved in the transaction. 2. The result of the calculation is stored in the smart contract using a blockchain transaction. 3. The blockchain instance/node held by the counterparty receives notification of the calculation (in the form of a blockchain event) and automatically performs it's own calculation and verifies that the result matches the one provided by the first (this can be automated machine-to-machine validation - no manual intervention required). 4. If there is a match, then the match is recorded in the smart contract. 5. At this point, the result has been calculated separately by both parties and matched, and can therefore be used for further activity (e.g. trigger a payment).)
13. Regarding claims 7 and 17, Ben-ari does not explicitly disclose wherein said first consumer device gathers inputs of the serialized contracts a second time for automatic verification by the second supplier device upon the determination that the compared settlement outputs differ outside the predetermined tolerance window.
However, Wilczek teaches wherein said first consumer device gathers inputs of the serialized contracts a second time for automatic verification by the second supplier device upon the determination that the compared settlement outputs differ outside the predetermined tolerance window, (Column 5/line 49, The Contract Order Document component 118 is programmed, in response, to access the contract data associated with the contract between the purchaser entity and the supplier entity using the account associated with the purchaser computer 102. The Contract Order Document component 118 may determine one or more types of supplier documents to be generated. For example, a contract for services may be invoiced using a timesheet while a contract for goods may be invoiced using a receipt showing an amount due. The determination may be made from contract data that explicitly states the types of supplier documents to send and, in some instances, a timeline for sending the supplier documents. In some instances, a heuristic model may be used to determine, from the contract data, the types of supplier documents. The Contract Order Document component is programmed to generate the Contract Order Document with one or more options to generate supplier documents and may include, for example, correspondence information of the purchaser computer 102 or the purchaser entity, a copy of the contract, a portion of the contract data, or the like. The Contract Order Document may be sent via email to the supplier computer 108. The supplier document component 120 is programmed to generate supplier documents in response to receiving a request or instruction to do so from the supplier computer 108. For example, an API call or parameterized URL query string may be used. The instruction may include a type of supplier document to be generated. In some embodiments, the instruction may include information to be included in one or more fillable fields within a form used to generate a supplier document. The form used to generate a particular supplier document may be a template, selected by the contract management computer 114 or purchaser computer 102, having one or more fillable fields. The fillable fields in the supplier document may include information such as correspondence information, date, date due, amount due, goods or service provided, and the like. The information included in the fillable fields may be accessed from the contract data 122 associated with the purchaser computer 102. The supplier document component 120 sends the supplier documents to the supplier computer 108 via, for example, email. The supplier document may be editable by the supplier computer 108. In some instances, the supplier document may be generated such that a portion of the document may not be modified. For example, if the contract includes a per diem amount, the per diem amount may not be changed by the supplier computer 108. The supplier computer 108 may be further restricted from entering a value higher than a threshold based on the contract data. For example, if the contract includes a per diem for no more than ten days, the supplier computer 108 is restricted from entering a number greater than ten into a field for number of days. The supplier computer 108, upon finalizing the supplier document, may send the supplier document to the purchaser computer 102. In some instances, the finalized supplier document may be sent to the contract management computer 114 which then communicates the supplier document to the purchaser computer 102 via, for example, the CM client 104.)
One of ordinary skill in the art would have recognized that applying the known technique of Wilczek to the known invention of Ben-ari would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate automatic verification features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include wherein said first consumer device gathers inputs of the serialized contracts a second time for automatic verification by the second supplier device upon the determination that the compared settlement outputs differ outside the predetermined tolerance window results in an improved invention because applying said technique ensures that the system automatically detects and fixes any errors within the contract, thus improving the overall efficiency of the invention.
14. Regarding claims 10 and 20, Ben-ari discloses wherein each of the first consumer device and the second supplier device maintains a digital contract table, an invoice table, and a payment table stored on local hardware for each device, wherein the provided contracts are each identified by a universally unique identifier maintained in each digital contract table, the universally unique identifier for each contract being identical across the first consumer device and the second consumer device, (Settlement/Reconciliation Section, A batch settlement point is configured in the private blockchain network. This is a universally agreed point in time (e.g. midnight every night) when each 24 hour batch window starts/ends. A timer triggers each blockchain node to initiate a batch settlement process. At that point, all of the receivable and payable invoices that were previously marked 'Ready for Batch Payment' are retrieved from the blockchain. The invoices, already grouped by counterparties in a mapping smart contract, are totalled and netted by the application off chain (e.g. if two companies exchange invoices, and sell and buy from each other, then the total net outstanding amount is calculated). The result of the calculation is stored in a new entry in a settlement smart contract. The settlement smart contract holds the batch net settlement amount between every two counterparties, based on the off chain calculations.; and Figures Section, 1.4 As a result of the blockchain synchronization mechanism (1.6), the blockchain distributes the new representative smart contract (in this case, the new smart contract invoice) among all the blockchain nodes… 2.4 Application B records the invoice payment confirmation details, including a certificate and signed transaction if required (proof that the payment was made by said payment facility), to the blockchain smart contract (1.14). The blockchain distributes the new transaction among all the blockchain nodes.)
15. Claims 8-9, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Ben-ari et al. (WO 2017098519 A1) in view of Wilczek et al. (US 10664802 B1), and further in view of Biggs et al. (US 12423679 B2).
16. Regarding claims 8 and 18, Ben-ari as modified does not explicitly disclose wherein said first consumer device provides contracts to the second supplier device in a serialized format using JavaScript Object Notation.
However, Biggs teaches wherein said first consumer device provides contracts to the second supplier device in a serialized format using JavaScript Object Notation, (Column 7/line 4, Javascript Object Notation (“JSON”) uses data strings, a sequence of zero or more Unicode characters, which are represented in one of three encoding forms: 32-bit form (UTF-32), 16-bit form (UTF-16), and 8-bit form (UTF-8) reuses existing ASCII-based systems. JSON-based data structures encode all data strings using Base64URL, which is slightly different than Base64 (the plus “+” and underline “_” characters are replaced with the minus “−” and virgule “/” characters). JSON-based data structures consist of one or more Headers and JSON Web-specific objects. JWS provides rules for cryptographic signatures (digital signatures or HMAC). JWE provides rules for content encryption. JWK provides rules for symmetric and asymmetric cryptographic keys. JWA provides rules for cryptographic algorithms. JWT provides rules for Web Tokens. When public keys or public-key certificates are URI-based resources, these must be encoded as a JWK Set and transmitted over a TLS connection. Further note that Quantum TLS using post-quantum cryptography is not yet available.)
One of ordinary skill in the art would have recognized that applying the known technique of Biggs to the known invention of Ben-ari as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate JSON features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include wherein said first consumer device provides contracts to the second supplier device in a serialized format using JavaScript Object Notation results in an improved invention because applying said technique ensures that the system can exchange contracts using JSON format, thus improving the overall efficiency of the invention.
17. Regarding claims 9 and 19, Ben-ari as modified does not explicitly disclose wherein said provided contract being signed against a private key corresponding to a public-key exchanged between the first consumer device and second supplier device comprises the first consumer device signing using at least one of Elliptic Curve Digital Signature Algorithm and Schnorr.
However, Biggs teaches wherein said provided contract being signed against a private key corresponding to a public-key exchanged between the first consumer device and second supplier device comprises the first consumer device signing using at least one of Elliptic Curve Digital Signature Algorithm and Schnorr, (Column 3/line 62, The key generation module 302 establishes encryption keys based on several different schemes, including but not limited to Elliptic Curve Diffie Hellman Ephemeral (ECDHE), RSA-OAEP, and Post-Quantum Cryptography (“PQC”). The key generation module 302 allows for communications to and from the digital asset vault module 204 to be protected through one or more layers of encryption.; and Column 7/line 25, JSON Web Signature (“JWS”) represents content secured with digital signatures or key-hashed message authentication codes (HMAC) using JSON-based data structures. The JWS Cryptographic Algorithms for Digital Signatures and MAC are defined in the JSON Web Algorithms (JWA) listed below. JWS supports two data structures: (a) JWS JSON Serialization and (b) JWS Compact Serialization.); and Column 9/line 40, JWT support for JWS of the signature and MAC algorithms specified in JSON Web Algorithms [JWA], only HMAC SHA-256 (“HS256”) and “none” must be implemented by conforming JWT implementations. It is recommended that implementations also support RSASSA-PKCS1-v1_5 with the SHA-256 hash algorithm (“RS256”) and ECDSA using the P-256 curve and the SHA-256 hash algorithm (“ES256”). TABLE-US-00008 “alg” Description Implementation HS256 HMAC using SHA-256 Required RS256 RSASSA-PKCS1-v1_5 using SHA-256 Recommended ES256 ECDSA using P-256 and SHA-256).
One of ordinary skill in the art would have recognized that applying the known technique of Biggs to the known invention of Ben-ari as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate ECDSA features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include wherein said provided contract being signed against a private key corresponding to a public-key exchanged between the first consumer device and second supplier device comprises the first consumer device signing using at least one of Elliptic Curve Digital Signature Algorithm and Schnorr results in an improved invention because applying said technique ensures that the system can securely exchange contracts using cryptographic signing, thus improving the overall security of the invention.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
System, Method, And Computer Program Product For Secured, Encrypted Transaction Processing (US 20220084014 A1) teaches a system, method, and computer program product is provided for secured, encrypted transaction processing. The method includes receiving a transaction request initiated by a first computing device associated with a first user and/or a second computing device associated with a second user. The transaction request includes a first user token including a first token identifier and a first account balance encrypted with a public key of the first user. The transaction request also includes a transaction value and a second user token including a second token identifier and a second account balance encrypted with a public key of the second user. The method includes generating a new first user token including a new first account balance encrypted with the public key of the first user and a new second user token including a new second account balance encrypted with the public key of the second user.
In addition to the foregoing, other aspects are described in the claims, drawings, and text. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Davida L. King whose telephone number is (571) 272-4724. The examiner can normally be reached M-F 8am-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, Neha Patel can be reached on (571) 270-1492. 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.
/D.L.K./Examiner, Art Unit 3699
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699