DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 12/19/2025.
Claims 1, 3, 8-10 and 13-15 are amended.
Claims 2 and 17-20 are cancelled.
Claims 21-24 are new.
Claims 1, 3-16 and 21-24 are pending.
Claims 1, 3-16 and 21-24 have been examined.
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 .
Response to Arguments
Applicant's arguments filed 12/19/2025 have been fully considered but they are not persuasive.
101
Applicant argues “it recites a series of operations that are inherently technical and tied to computer technology, including: (i) the deployment and execution of computer code in a promise smart contract, the code incorporating conditional rules influencing the provision of funds; (ii) the creation and mapping of linked "promises" between multiple parties via a hub computer; and (iii) cryptographic verification of digital signatures and promise parameters…. The claimed method is not merely the automation of a known manual process on a generic computer. Rather, the claim recites a particular, non-conventional, and non-routine combination of elements, including: (i) the receipt of a message containing not just transaction data, but computer code incorporating programmable conditional rules; (ii) the deployment and execution of that code in a promise smart contract, in response to cryptographic verification; (iii) the creation and mapping of a second promise for a separate party, enabling secure, atomic, programmable, and traceable linked transactions; and (iv) verification using digital signatures and cryptographic keys. The deployment of programmable, conditionally executed smart contracts, linked and mapped across parties, using cryptographic verifications, solves a technical problem in the field of distributed payment channels and blockchain interoperability. This is precisely the type of improvement to computer technology recognized as "significantly more" than an abstract idea.” Examiner disagrees.
Applicant’s claims recite the automation of a real world contracting. The recitation of “computer code” does not automatically negate an abstract idea as automating receiving or sending information on a computer requires “computer code”. Here, Applicant’s amendment now include deploying a contract and creating further “promise” linked to the initial “promise” of the contract. The verification of signatures or the conditions of a contract are abstract and standard to the business practice of contracting.
Secondly, Applicant concludes the application “solves a technical problem in the field of distributed payment channels and blockchain interoperability”, Applicant does not state what technical problem is solved, nor how the current claims solve them. The claims are abstract and recite the automation of a business practice in signed contracts with conditions without any solved technical solution or improvement. The rejection is maintained.
103
Khalil discloses the computer code incorporating conditional rules associated with the promise, the conditional rules influencing how funds are provided in the transaction (¶ 5, 14, 73-79, 91, 92, 114-116; claim 6, 25);
Khalil - Creating a smart contract means that this contract and its conditions are converted to computer code, and upon the system seeing a cryptocurrency payment of $1000 or other type of payment, then the product X is ordered shipped as contracted. (¶ 5, 14, 75)
Trevethan teaches a promise type, a second verification key sending, by the hub computer, the second promise to the second computer, wherein the second computer verifies the second promise, wherein the hub computer maps the first promise to the second promise (¶ 30-50, 77-85, 92-97, 158-170);
Trevethan - A first public key associated with the first possible outcome and a second public key associated with the second possible outcome may be generated. Additionally or alternatively, the first public key and the second public key may be provided to the set of counterparties…. OP_CHECKMULTISIG, which compares the first signature with each public key until it finds a match. Then with the subsequent public key, it compares the second signature against each remaining public key until it finds a match. (¶ 46, 77-85)
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, 3-16 and 21-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, and claim 14 is directed to an article of manufacture.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “receiving,… promise… verifying,… promise… amount… computer is able to process the promise type… deploying… contract… executing the computer code to perform the transaction … creating… promise and sending… promise….” The recited limitations fall within the certain methods of organizing human activity grouping of abstract ideas, specifically, business behaviors in contracting, receiving transaction condition, verify that the transaction condition can be performed, perform the transaction, creating another condition and sending it. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application.
Accordingly, even in combination, these elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite “receiving,… promise… verifying,… promise… amount… computer is able to process the promise type… deploying… contract… executing the computer code to perform the transaction … creating… promise and sending… promise….” are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of a fundamental economic practice as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Claims 5, 7-13, 15 and 16 provide descriptive language surrounding the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
Dependent claims 3, 4, 6 discuss functions in more descriptive detail of the steps geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
The 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. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
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 or processor 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.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 3-13, 15, 16 and 21-24 are also rejected.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-9, 12-15 and 21-24 are rejected under 35 U.S.C. 103 as being unpatentable over Khalil et al. (US 2019/0139037) (“Khalil”), and further in view of Trevethan (US 20200313884) (“Trevethan”).
Regarding claims 1 and 14, Khalil discloses receiving, by a hub computer from a first computer, a sender message comprising a promise corresponding to a transaction comprising a promise type, an amount, a first verification key associated with the first computer, computer code, and a digital signature, the computer code incorporating conditional rules associated with the promise, the conditional rules influencing how funds are provided in the transaction (¶ 5, 14, 73-79, 91, 92, 114-116; claim 6, 25);
Khalil - Bitcoin transactions are sent from an address to another address. An address is a unique identifier (hash) of a public key, and, only the owner of the corresponding private key is eligible to sign a transaction involving transfer of monetary funds…Entity-A then signs the IOU and submits the signature to that second smart contract, effectively broadcasting both IOU signatures … The IOU is a signed message authorizing the update of a client's off-chain ledger during one of the rounds to include one or more additional transfers. This message is structure to contain the round number, the total sum received, the total sum sent, and a commitment to the set of transfers performed during that round. The transfers committed to include a unique randomly generated identifier, the amount, and the intended recipient information… Creating a smart contract means that this contract and its conditions are converted to computer code, and upon the system seeing a cryptocurrency payment of $1000 or other type of payment, then the product X is ordered shipped as contracted. (¶ 5, 14, 75)
verifying, by the hub computer, the promise by at least verifying the digital signature using the first verification key, verifying that the amount is less than a first computer amount, and verifying that the hub computer is able to process the promise; and (¶ 25-29, 47, 70-76, 86-100, 112-116; claim 4);
Khalil - the blockchain payment address is obtained and info submitted to the smart contract to commence a withdrawal, wherein info is proof of sufficient balance to cover the amount indicated in the transaction…. Before being able to send funds in the Liquidity.Network™ brand system, a user is required to provide funds as a deposit to the smart contract SCH of a Liquidity.Network™ brand payment hub H, or receive funds from another user already in possession of funds within the network, to attain a spendable balance… The contract is assumed to only allow peers to withdraw balances that they have bother agreed on using their signatures. The sum of the two off-chain balances may not exceed the total deposit in the o-chain contract at any given time. (¶ 29, 47, 95)
in response to verifying, deploying a promise contract with the computer code and executing the computer code in deployed promise smart contract to perform the transaction, wherein the promise is a first promise, wherein the sender message further comprises a second verification signature associated with a second computer, and wherein the method further comprises: (¶ 13, 24-26, 75, 90-100, 106-110; claim 7);
Khalil - The user can withdraw funds from the payment hub (see, e.g., FIG. 11) by calling the withdraw function of the smart contract. With the withdrawal call, the user is required to provide the latest proof of stake. In an embodiment, with the withdrawal call, the user is required to provide the latest proof of stake and the highest spendings of the previous eon. In an embodiment, the amount requested for withdrawal must not exceed the current user balance….Then the funds are released to Entity-A by the second smart contract. Note, the smart contract effects the transfer of ownership once the conditions for the IOU are satisfied. (¶ 75, 114)
creating, by the hub computer, a second promise based on the first promise, wherein the second promise comprises the second verification signature: and (¶ 13, 24-26, 75, 90-100, 106-110; claim 7);
Khalil - First, Entity-A creates an IOU, without signatures, and requests the current payment hub SH's signature on the IOU. Next, Entity-A submits the IOU, with only online server SH's signature on the IOU, to a second smart contract with a separate collateral pool, which reserves the funds for withdrawal until a certain timeout period. Entity-A then signs the IOU and submits the signature to that second smart contract, effectively broadcasting both IOU signatures (i.e., the Entity-A signature and the SH's signature)… The IOU is a signed message authorizing the update of a client's off-chain ledger during one of the rounds to include one or more additional transfers. (¶ 75)
Khalil does not disclose a promise type, a second verification key sending, by the hub computer, the second promise to the second computer, wherein the second computer verifies the second promise, wherein the hub computer maps the first promise to the second promise.
Trevethan teaches a promise type, a second verification key sending, by the hub computer, the second promise to the second computer, wherein the second computer verifies the second promise, wherein the hub computer maps the first promise to the second promise (¶ 30-50, 77-85, 92-97, 158-170);
Trevethan - A first public key associated with the first possible outcome and a second public key associated with the second possible outcome may be generated. Additionally or alternatively, the first public key and the second public key may be provided to the set of counterparties…. OP_CHECKMULTISIG, which compares the first signature with each public key until it finds a match. Then with the subsequent public key, it compares the second signature against each remaining public key until it finds a match. (¶ 46, 77-85)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Khalil and Trevethan in order to provide security in blockchain data transfers in the use of smart contracts (Trevethan; ¶ 1-3).
Regarding claim 3, Khalil discloses obtaining, by the hub computer, a first channel contract for a first interaction channel between the hub computer and the first computer; and obtaining, by the hub computer, a second channel contract for a second interaction channel between the hub computer and the second computer (¶ 17-20, 27, 48, 86).
Regarding claim 4, Khalil discloses determining, by the hub computer, whether or not the first channel contract is expired; and determining, by the hub computer, whether or not the second channel contract is expired (¶ 20-28, 87-89).
Regarding claim 5, Khalil discloses wherein verifying the promise further comprises: validating, by the hub computer, that the first computer has sufficient funds in the first channel contract for the amount in the promise (¶ 25-29, 47, 70-76, 86-100, 112-116; claim 4).
Regarding claim 6, Khalil discloses adding, by the hub computer, the promise to a list of ingoing hub promises in the first channel contract; and increasing, by the hub computer, a net ingoing hub promise value in the first channel contract by the amount (¶ 25-29, 47, 70-76, 86-100, 112-116; claim 4).
Regarding claim 7, Khalil discloses wherein creating the second promise further comprises: creating, by the hub computer, the second promise based on the second channel contract, a second promise type, a set of parameters, a hub computer private key, a hub computer verification key, and the second verification key, wherein the set of parameters includes the amount, a hash value, and an expiry time (¶ 8, 11-14, 20-28, 68-71, 75, 84, 90-100).
Regarding claim 8, Khalil discloses wherein prior to receiving the sender message, the method further comprises: receiving, by the hub computer from the first computer, an enrollment request message comprising the first verification key (¶ 91, 119). Trevethan teaches determining, by the hub computer, whether or not the first computer is enrolled by verifying whether or not the first verification key is included in a list of enrolled verification keys; enrolling, by the hub computer, the first computer by adding the first verification key to the list of enrolled verification keys; generating, by the hub computer, an enrollment response message indicating an enrollment status; and providing, by the hub computer, the enrollment response message to the first computer (¶ 31, 103-104, 120-125, 146, 167, 168).
Regarding claim 9, Khalil discloses wherein the sender message is received in a state channel formed between the hub computer and the first computer (¶ 20-28, 87-89).
Regarding claim 12, Khalil discloses wherein generating the second receipt further comprises: updating, by the hub computer, an outgoing hub credit value in a second channel contract based on the amount included in the second promise; removing, by the hub computer, the second promise from a list of promises in the second channel contract; and creating, by the hub computer, a second receipt digital signature based on the second promise using a hub computer private key, wherein the second receipt includes the second receipt digital signature (¶ 14, 73-88, 91, 92, 114-116; claim 6, 13, 25, 29).
Regarding claim 13, Khalil discloses wherein the computer code is bytecode, and wherein the method further comprises: executing, by the hub computer, a resolve function in the bytecode of the promise contract when an interaction channel is closing between the first computer and the hub computer (¶ 14, 73-79, 91, 92, 114-116; claim 6, 25).
Regarding claim 15, Khalil discloses wherein the computer code is bytecode, and wherein the method further comprises: obtaining, by the hub computer, a first channel contract for a first interaction channel between the hub computer and the first computer; determining, by the hub computer, whether or not the first channel contract is expired; obtaining, by the hub computer, a second channel contract for a second interaction channel between the hub computer and the second computer; and determining, by the hub computer, whether or not the second channel contract is expired (¶ 25-29, 47, 48, 70-76, 86-100, 112-116; claim 4).
Regarding claim 21, Trevethan teaches wherein verifying the promise further comprises: determining, by the hub computer, whether the promise type corresponds to a programmable contract type supported by the hub computer, and, wherein the hub computer is programmed to, in response to determining that the promise type is unsupported, reject the promise and providing an error notification to the first computer (¶ 77-85, 91-95)
Regarding claim 22, Trevethan teaches wherein the conditional rules incorporated in the computer code specify at least one of:(i) a timewindow for claim or fulfillment of the transaction, or (ii) a penalty or refund condition triggered by non-fulfillment within the time window (¶ 77-85, 91-95, 101-106, 127-131) .
Regarding claim 23, Khalil discloses wherein deploying the promise contract comprises storing, by the hub computer, the computer code and associated promise data on a distributed ledger (¶ 5, 14, 73-79, 91, 92, 114-116; claim 6, 25)
Regarding claim 24, Trevethan teaches after the second computer verifies the second promise: receiving, by the hub computer, a confirmation message from the second computer, the confirmation message including a digital signature of the second computer, wherein the hub computer, in response to receiving the confirmation message, updates a status record for the mapped promises (¶ 30-50, 77-85, 92-97, 158-170).
Claims 10, 11 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Khalil et al. (US 2019/0139037) (“Khalil”), in view of Trevethan (US 20200313884) (“Trevethan”) and further in view of Coa et al. (US 20210226800) (“Coa”).
Regarding claim 10, Khalil discloses wherein after sending the second promise to the second computer, the method further comprises: receiving, by the hub computer, the second promise; generating, by the hub computer, a second receipt for the second promise; providing, by the hub computer, the second receipt and the second promise to the second computer; providing, by the hub computer, and the first promise to the first computer, wherein the first computer generates a first receipt and provides the first receipt to the hub computer, wherein the first receipt includes a first receipt digital signature created using a first computer private key; receiving, by the hub computer, the first receipt from the first computer; and verifying, by the hub computer, the first receipt by verifying the first receipt digital signature using the first verification key (¶ 76-80, 88; claim 13, 29, 30). Khalil does not disclose and a secret from the second computer; the secret. Coa teaches and a secret from the second computer (Abstract; ¶ 40-44, 74-79). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Khalil, Trevethan and Coa in order to protect the privacy of users of a distributed ledger transaction (Coa; ¶ 1-3).
Regarding claim 11, Coa teaches wherein the first promise and the second promise include an interaction hash value, wherein the method further comprises: hashing, by the hub computer, the secret to form a derived hash value; and comparing, by the hub computer, the derived hash value to the interaction hash value (Abstract; ¶ 40-44, 53-59, 70-86, 94, 102, 106-134).
Regarding claim 16, Coa teaches wherein the first promise includes an interaction hash value, the method further comprises: receiving, by the hub computer, the second promise and a secret from the second computer; hashing, by the hub computer, the secret to form a derived hash value; comparing, by the hub computer, the derived hash value to the interaction hash value; generating, by the hub computer, a second receipt for the second promise, wherein the second promise includes the interaction hash value; providing, by the hub computer, the second receipt and the second promise to the second computer; providing, by the hub computer, the secret and the first promise to the first computer, wherein the first computer generates a first receipt comprising a first receipt digital signature and provides the first receipt to the hub computer; receiving, by the hub computer, the first receipt from the first computer; and verifying, by the hub computer, the first receipt by verifying the first receipt digital signature using the first verification key (Abstract; ¶ 40-44, 53-59, 70-86, 94, 102, 106-134).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sheng et al., (US 20170109735) teaches blockchain transaction and registration.
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 ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
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 H 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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699
Prosecution Insights