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 .
This application is a 371 of PCT/CN2023/138886 filed on 12/14/2023
This application also claims benefit of foreign application CHINA 202211720692.8 filed on 12/30/2022.
Claim Status
Claims 1-12 and 14-21 are currently pending and rejected.
Claim 13 is canceled.
Claim Objection
Claim 3 is objected for the following informality – “creating an payment request block” should be “creating a payment request block”.
Claim Rejection – 35 U.S.C. 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-12 and 14-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The rationale for this finding is explained below. In the instant case, the claims are directed towards cross-border payments and currency exchange. The concept is related to a fundamental economic activity, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. The claims do not include limitations that are “significantly more” than the abstract idea because the claims do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Note that the limitations, in the instant claims, are done by the generically recited computer device. The limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry. Therefore, claims 1-12 and 14-21 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Step 1: The claims 1-12 and 14-21 are directed to a process, machine, manufacture, or composition matter.
In Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014), the Supreme Court applied a two-step test for determining whether a claim recites patentable subject matter. First, we determine whether the claims at issue are directed to one or more patent-ineligible concepts, i.e., laws of nature, natural phenomenon, and abstract ideas. Id. at 2355 (citing Mayo Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1296–96 (2012)). If so, we then consider whether the elements of each claim, both individually and as an ordered combination, transform the nature of the claim into a patent-eligible application to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself.
Claims 1-12 are directed to a process (i.e., method claims).
Claims 14 and 16-21 are directed to a machine (i.e., device/system claims).
Claims 15 are directed to a manufacture (i.e., machine-readable medium claims).
Step 2A: The claims are directed to an abstract idea.
Prong One
The present claims are directed towards cross-border payments and currency exchange. The concept comprises generating a payment request, creating a payment request block to a blockchain, signing the payment request block based on a private key of a transaction initiation device, and determining that the payment request is completed. The concept of cross-border payment and currency exchange is related to a fundamental economic activity, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. The performance of the claim limitations using generic computer components (i.e., a blockchain payment system and a transaction initiation device) does not preclude the claim limitation from being in the certain methods of organizing human activity grouping. Accordingly, the present claims recite an abstract idea.
Prong Two
Claims 1-12 recite a blockchain payment system and a transaction initiation device as additional elements. Claim 14 and 16-21 recite a transaction device comprising a processor and a communication interface as additional elements. Claim 16 recites a non-transitory computer-readable storage medium and a process as additional elements. The additional elements are claimed to perform basic computer functions, such as generating a payment request, creating a payment request block on a blockchain, and determining that the payment request is completed. The recitation of the computer elements amounts to mere instruction to implement an abstract concept on computers. Although the claims recite blockchain and smart contract, these are existing technologies performing their default functions (i.e., recording data and implementing conditional contract). The present claims do not recite limitation that improve the functioning of computer/blockchain, effect a physical transformation, or apply the abstract concept in some other meaningful way beyond generally linking the use of the abstract concept to a particular technological environment. As such, the present claims fail to integrate into a practical application.
Step 2B: The claims do not recite additional elements that amount to significantly more than the abstract idea.
As discussed earlier, claims 1-12 recite a blockchain payment system and a transaction initiation device as additional elements. Claim 14 and 16-21 recite a transaction device comprising a processor and a communication interface as additional elements. Claim 16 recites a non-transitory computer-readable storage medium and a process as additional elements. The additional elements are claimed to perform basic computer functions, such as generating a payment request, creating a payment request block on a blockchain, and determining that the payment request is completed. According to MPEP 2106.05(d), “performing repetitive calculations”, “receiving, processing, and storing data”, “electronically scanning or extracting data from a physical document”, “electronic recordkeeping”, “storing and retrieving information in memory”, and “receiving or transmitting data over a network, e.g., using the Internet to gather data” are considered well-understood, routine, and conventional functions of computer. The present claims do not improve the functioning of computer. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Claim Rejection – 35 U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claim(s) 1, 2, 7, 9-11, 14-16, and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yan (Pub. No.: US 2022/0292488), in view of Boemi (Pub. No.: US 2020/0074438).
As per claim 1, Yan teaches a digital-currency cross-border transaction method based on a blockchain, applied to a transaction initiation device in a blockchain payment system, comprising:
generating a digital-currency payment request which comprises a payment
account address, a beneficiary account address of a beneficiary bank, a payment amount, and currency-type information (see paragraph 0046, “The subchain hosted by the PCB may be configured to execute transactions in any amount, even fractional amounts”; see paragraph 0048, “the payer signs and sends a command to cause the payer’s PCB’s subchain blockchain to transfer a designated amount of CBDC from the payer’s digital wallet to the payee’s digital wallet”; see paragraph 0081, “FIG. 4A illustrates a transaction wherein a payer transfers CBDC from its own digital wallet into the digital wallet of a payee’s digital wallet. Though such transactions may be either initiated by the payer or requested by the payee” and “Upon approval, subchain 112a may determine (based on the received wallet address) if payee B (the owner of the digital wallet that is supposed to receive funds) is a member or otherwise belongs to subchain 112a” and “If subchain 112a determines that Payer A has a sufficient balance to support the requested payment to Payee B, subchain 112a will debit Payer A’s wallet the amount of the CBDC request”; see paragraph 0084-0085, “if a customer A is simply making a direct CBDC deposit or payment from their digital wallet into their or another payee’s account at the same PCB ,they can simply submit a request (through their wallet) to subchain 112a, which will couple with consortium chain 110 to process the transaction”);
creating a payment request block based on the digital-currency payment request
and sending the payment request block to the blockchain, the blockchain is configured with a digital-currency smart contract comprising a payment function, the payment function is used for performing payment based on the payment request block, and the digital-currency smart contract is used for managing digital currency corresponding to the currency-type information (see paragraph 0030, “PCB may be configured with the intelligence to selectively process transactions (or portions of transactions) on different blockchains with flexibility and agility, which in some embodiments may be based on…the types of fiat and/or CBDC currency involved in the transaction”; see paragraph 0049-0052, “Smart contracts may be utilized to execute and/or otherwise govern the execution of transactions submitted for processing on the domestic or cross-border blockchain transaction networks of the present disclosure”
also see paragraph 0072, 0075, 0087, and 0125-0127); and
determining, in response to a success result of the payment by the payment
function for the payment request block, that the digital-currency payment request is completed (see paragraph 0081, “Once settled, PCB 100b will confirm the transaction and thereafter the temporary credit becomes permanent in Payee B’s digital wallet and is useable”; see paragraph 0084-0086, “Upon validation, the transaction will be processed using the cross-subchain settlement process”).
Examiner notes however, Yan does not explicitly teach wherein the payment request block is obtained by signing based on a private key of the transaction initiation device.
Boemi teaches the payment request block is obtained by signing based on a private key of the transaction initiation device (see paragraph 0009, “receiving a cryptocurrency request from the mobile device user at the payment system operator, the cryptocurrency request being digitally signed with the device private key, the cryptocurrency request including a requested credit amount and the device public key”; also see paragraph 0059).
It would have been obvious to one of ordinary skill in the art on the effective filing date of the present application to modify Yan with teaching from Boemi to include the payment request block is obtained by signing based on a private key of the transaction initiation device. The modification would have been obvious, because it is merely applying a known technique (i.e., signing a block in a blockchain with user’s private key) to a known method (i.e., cross-border transaction using blockchain) ready to provide predictable result (i.e., enhance security).
As per claim 2, Yan teaches generating a digital-currency exchange request; wherein the digital-currency exchange request comprises an exchange account address, an exchange amount, and exchange currency-type information (see paragraph 0067-0073, “engage in transactions involving foreign currency exchanges over the consortium blockchain”; see paragraph 0076-0078, “for an account holding member, A, of PCB 100a to exchange an amount of US-CBDC currency into EURO-CBDC currency with another account holding member, B, of PCB 100a, customer A may submit a request to PCB 100a”);
creating an exchange request block based on the digital-currency exchange
request and sending the exchange request block to the blockchain, for requesting to invoke at least one exchange smart contract configured in the blockchain by the digital-currency smart contract, and each exchange smart contract is used for exchanging a local currency for a foreign currency (see paragraph 0073, “PCBs 100a and 100f themselves initiating a request for such a foreign currency exchange”; see paragraph 0077-0078, “For an account holding member A, of PCB 100a to exchange an amount of USD-CBDC currency into Euro-CBDC currency, it may submit a request to PCB100a”); and
determining, in response to a success result of exchanging by the exchange smart contract for the exchange request block, that the digital-currency exchange request is completed (see paragraph 0081, “Once settled, PCB 100b will confirm the transaction and thereafter the temporary credit becomes permanent in Payee B’s digital wallet and is useable”; see paragraph 0084-0086, “Upon validation, the transaction will be processed using the cross-subchain settlement process”).
Examiner notes however, Yan does not teach wherein the exchange request block is obtained by signing based on the private key of the transaction initiation device.
Boemi teaches the exchange request block is obtained by signing based on the private key of the transaction initiation device (see paragraph 0009, “receiving a cryptocurrency request from the mobile device user at the payment system operator, the cryptocurrency request being digitally signed with the device private key, the cryptocurrency request including a requested credit amount and the device public key”; also see paragraph 0059).
It would have been obvious to one of ordinary skill in the art on the effective filing date of the present application to modify Yan with teaching from Boemi to include the exchange request block is obtained by signing based on the private key of the transaction initiation device The modification would have been obvious, because it is merely applying a known technique (i.e., signing a block in a blockchain with user’s private key) to a known method (i.e., cross-border transaction using blockchain) ready to provide predictable result (i.e., enhance security).
As per claim 7, Yan teaches generating a digital-currency issuance request, wherein the digital-currency issuance request comprises an issuance amount and an issuance account address (see paragraph 0046, “The subchain hosted by the PCB may be configured to execute transactions in any amount, even fractional amounts”; see paragraph 0048, “the payer signs and sends a command to cause the payer’s PCB’s subchain blockchain to transfer a designated amount of CBDC from the payer’s digital wallet to the payee’s digital wallet”; see paragraph 0081, “FIG. 4A illustrates a transaction wherein a payer transfers CBDC from its own digital wallet into the digital wallet of a payee’s digital wallet. Though such transactions may be either initiated by the payer or requested by the payee” and “Upon approval, subchain 112a may determine (based on the received wallet address) if payee B (the owner of the digital wallet that is supposed to receive funds) is a member or otherwise belongs to subchain 112a” and “If subchain 112a determines that Payer A has a sufficient balance to support the requested payment to Payee B, subchain 112a will debit Payer A’s wallet the amount of the CBDC request”; see paragraph 0084-0085, “if a customer A is simply making a direct CBDC deposit or payment from their digital wallet into their or another payee’s account at the same PCB ,they can simply submit a request (through their wallet) to subchain 112a, which will couple with consortium chain 110 to process the transaction”);
creating an issuance request block based on the digital-currency issuance request and sending the issuance request block to the blockchain, for requesting to invoke an issuance smart contract configured in the blockchain by the digital-currency smart contract; and the issuance smart contract is used for exchanging a local currency for a local digital currency (see paragraph 0030, “PCB may be configured with the intelligence to selectively process transactions (or portions of transactions) on different blockchains with flexibility and agility, which in some embodiments may be based on…the types of fiat and/or CBDC currency involved in the transaction”; see paragraph 0049-0052, “Smart contracts may be utilized to execute and/or otherwise govern the execution of transactions submitted for processing on the domestic or cross-border blockchain transaction networks of the present disclosure”
also see paragraph 0072, 0075, 0087, and 0125-0127); and
determining, in response to a success result of issuance by the issuance smart contract for the issuance request block, that the digital-currency issuance request is completed (see paragraph 0081, “Once settled, PCB 100b will confirm the transaction and thereafter the temporary credit becomes permanent in Payee B’s digital wallet and is useable”; see paragraph 0084-0086, “Upon validation, the transaction will be processed using the cross-subchain settlement process”).
Examiner notes however, Yan does not explicitly teach wherein the issuance request block is obtained by signing based on the private key of the transaction initiation device.
Boemi teaches the issuance request block is obtained by signing based on the private key of the transaction initiation device (see paragraph 0009, “receiving a cryptocurrency request from the mobile device user at the payment system operator, the cryptocurrency request being digitally signed with the device private key, the cryptocurrency request including a requested credit amount and the device public key”; also see paragraph 0059).
It would have been obvious to one of ordinary skill in the art on the effective filing date of the present application to modify Yan with teaching from Boemi to include the issuance request block is obtained by signing based on the private key of the transaction initiation device. The modification would have been obvious, because it is merely applying a known technique (i.e., signing a block in a blockchain with user’s private key) to a known method (i.e., cross-border transaction using blockchain) ready to provide predictable result (i.e., enhance security).
As per claim 9, Yan teaches generating a digital-currency transaction inquiry request; wherein the digital-currency transaction inquiry request comprises the payment account address and a transaction time period (see paragraph 0046, “The subchain hosted by the PCB may be configured to execute transactions in any amount, even fractional amounts”; see paragraph 0048, “the payer signs and sends a command to cause the payer’s PCB’s subchain blockchain to transfer a designated amount of CBDC from the payer’s digital wallet to the payee’s digital wallet”; see paragraph 0081, “FIG. 4A illustrates a transaction wherein a payer transfers CBDC from its own digital wallet into the digital wallet of a payee’s digital wallet. Though such transactions may be either initiated by the payer or requested by the payee” and “Upon approval, subchain 112a may determine (based on the received wallet address) if payee B (the owner of the digital wallet that is supposed to receive funds) is a member or otherwise belongs to subchain 112a” and “If subchain 112a determines that Payer A has a sufficient balance to support the requested payment to Payee B, subchain 112a will debit Payer A’s wallet the amount of the CBDC request”; see paragraph 0084-0085, “if a customer A is simply making a direct CBDC deposit or payment from their digital wallet into their or another payee’s account at the same PCB ,they can simply submit a request (through their wallet) to subchain 112a, which will couple with consortium chain 110 to process the transaction”);
sending the digital-currency transaction inquiry request to the blockchain;
wherein the blockchain is configured with a transaction-record inquiry contract, and the
transaction-record inquiry contract is used for inquiring a transaction record based on the digital-currency transaction inquiry request (see paragraph 0030, “PCB may be configured with the intelligence to selectively process transactions (or portions of transactions) on different blockchains with flexibility and agility, which in some embodiments may be based on…the types of fiat and/or CBDC currency involved in the transaction”; see paragraph 0049-0052, “Smart contracts may be utilized to execute and/or otherwise govern the execution of transactions submitted for processing on the domestic or cross-border blockchain transaction networks of the present disclosure”
also see paragraph 0072, 0075, 0087, and 0125-0127); and
acquiring a transaction-record inquiry result sent by the blockchain, to obtain a
transaction record during the transaction time period (see paragraph 0081, “Once settled, PCB 100b will confirm the transaction and thereafter the temporary credit becomes permanent in Payee B’s digital wallet and is useable”; see paragraph 0084-0086, “Upon validation, the transaction will be processed using the cross-subchain settlement process”).
As per claim 10, Yan teaches the digital-currency smart contract configured in the blockchain comprises a limit function, and the limit function is used for performing a limit verification on the payment amount based on the payment request block (see paragraph 0036, “PCBs or central banks can set upper amount limits, frequency of transactions per period limits, or otherwise invalidate, restrict or block for withdrawals and/or deposits of CBDC”; see paragraph 0057, “a central bank may limit the amount of CBDC it will permit to be transferred in a single transaction, in a single day, from a single account”).
As per claim 11, Yan teaches the blockchain is configured with an institution status audition function, and the institution status audition function is used to detect whether a payment account address is frozen (see paragraph 0081-0082, “subchain 112a will determine if payer A’s digital wallet has a sufficient balance to satisfy the request from payee B”; see paragraph 0084-0085, “PCB 100a may validate customer A and verify the balance held in customer A’s digital wallet to ensure it is sufficient to support the proposed CBDC transfer”; one skilled in the art would know that when checking for fund sufficiency, account status is verified as well).
Claim 13. (Canceled).
Claim 14 is rejected for the same reason as claim 1.
Claim 15 is rejected for the same reason as claim 1.
Claim 16 is rejected for the same reason as claim 2.
Claim 21 is rejected for the same reason as claim 7.
Claim(s) 3-6 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yan (Pub. No.: US 2022/0292488), in view of Boemi (Pub. No.: US 2020/0074438), and further in view of Zhang et al. (Pub. No.: US 2019/0220615).
As per claim 3, Yan does not teach wherein the blockchain payment system further comprises a transaction supervision device, and before the creating an payment request block based on the digital-currency payment request, the method further comprises: receiving an instruction message sent by the transaction supervision device; wherein the instruction message is used to instruct the transaction initiation device to create the payment request block based on the digital-currency payment request; and the instruction message is generated in a case that a compliance audit is passed, the compliance audit being performed by the transaction supervision device on the digital-currency payment request based on a predetermined compliance rule upon monitoring the digital-currency payment request.
Zhang teaches receiving an instruction message sent by the transaction supervision device; wherein the instruction message is used to instruct the transaction initiation device to create the payment request block based on the digital-currency payment request; and the instruction message is generated in a case that a compliance audit is passed, the compliance audit being performed by the transaction supervision device on the digital-currency payment request based on a predetermined compliance rule upon monitoring the digital-currency payment request (see paragraph 0007).
It would have been obvious to one of ordinary skill in the art on the effective filing date of the present application to modify Yan with teaching from Zhang to include receiving an instruction message sent by the transaction supervision device; wherein the instruction message is used to instruct the transaction initiation device to create the payment request block based on the digital-currency payment request; and the instruction message is generated in a case that a compliance audit is passed, the compliance audit being performed by the transaction supervision device on the digital-currency payment request based on a predetermined compliance rule upon monitoring the digital-currency payment request. The modification would have been obvious, because it is merely applying a known technique (i.e., using a supervision node to audit request file prior to generating block) to a known method (i.e., cross-border transaction using blockchain) ready to provide predictable result (i.e., enhance security).
As per claim 4, Yan teaches wherein before the creating a payment request block based on the digital-currency payment request, the method further comprises: performing authentication on the digital-currency payment request based on a
predetermined authentication rule; and creating the payment request block based on the digital-currency payment request in a case that the authentication is passed (see paragraph 0042 and 0084-0085, “Customer A may be required to authenticate him/herself to PCB 100a (e.g., with a signature, biometrics, 2FA or otherwise). Upon validation, the transaction will be processed using the cross-subchain settlement process”; one skilled in the art would know that when a transaction is approved after the user and payment request are authenticated, a new block is created and added to a blockchain).
As per claim 5, Yan teaches a payment smart contract and the at least one exchange smart contract are created by the transaction supervision device (see paragraph 0049-0056, 0125-0127, and 0149).
As per claim 6, Yan teaches wherein before the creating a payment request block based on the digital-currency payment request, the method further comprises: sending an institution join request to the transaction supervision device, wherein
the institution join request comprises the payment account address and an institution identifier; and joining, in response to a join completion message, the blockchain payment system (see paragraph 0036 and 0075).
Claim 17 is rejected for the same reason as claim 3.
Claim 18 is rejected for the same reason as claim 4.
Claim 19 is rejected for the same reason as claim 5.
Claim 20 is rejected for the same reason as claim 6.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yan (Pub. No.: US 2022/0292488), in view of Boemi (Pub. No.: US 2020/0074438), and further in view of Morais (Pub. No.: US 2023/0136805).
As per claim 8, Yan teaches generating a digital-currency request; wherein the digital-currency request comprises a amount and an account address (see paragraph 0046, “The subchain hosted by the PCB may be configured to execute transactions in any amount, even fractional amounts”; see paragraph 0048, “the payer signs and sends a command to cause the payer’s PCB’s subchain blockchain to transfer a designated amount of CBDC from the payer’s digital wallet to the payee’s digital wallet”; see paragraph 0081, “FIG. 4A illustrates a transaction wherein a payer transfers CBDC from its own digital wallet into the digital wallet of a payee’s digital wallet. Though such transactions may be either initiated by the payer or requested by the payee” and “Upon approval, subchain 112a may determine (based on the received wallet address) if payee B (the owner of the digital wallet that is supposed to receive funds) is a member or otherwise belongs to subchain 112a” and “If subchain 112a determines that Payer A has a sufficient balance to support the requested payment to Payee B, subchain 112a will debit Payer A’s wallet the amount of the CBDC request”; see paragraph 0084-0085, “if a customer A is simply making a direct CBDC deposit or payment from their digital wallet into their or another payee’s account at the same PCB ,they can simply submit a request (through their wallet) to subchain 112a, which will couple with consortium chain 110 to process the transaction”);
creating a request block based on the digital-currency request and sending the cancellation request block to the blockchain, for requesting to invoke a smart contract configured in the blockchain by the digital-currency smart contract; wherein the cancellation request block is obtained by signing based on the private key of the transaction initiation device, and the smart contract is used for exchanging a local digital currency for a local currency (see paragraph 0030, “PCB may be configured with the intelligence to selectively process transactions (or portions of transactions) on different blockchains with flexibility and agility, which in some embodiments may be based on…the types of fiat and/or CBDC currency involved in the transaction”; see paragraph 0049-0052, “Smart contracts may be utilized to execute and/or otherwise govern the execution of transactions submitted for processing on the domestic or cross-border blockchain transaction networks of the present disclosure”
also see paragraph 0072, 0075, 0087, and 0125-0127); and
determining, in response to a success result of by the cancellation
smart contract for the request block, that the digital-currency request is completed (see paragraph 0081, “Once settled, PCB 100b will confirm the transaction and thereafter the temporary credit becomes permanent in Payee B’s digital wallet and is useable”; see paragraph 0084-0086, “Upon validation, the transaction will be processed using the cross-subchain settlement process”).
Examiner notes however, Yan does not explicitly teach wherein the payment request block is obtained by signing based on a private key of the transaction initiation device.
Boemi teaches the payment request block is obtained by signing based on a private key of the transaction initiation device (see paragraph 0009, “receiving a cryptocurrency request from the mobile device user at the payment system operator, the cryptocurrency request being digitally signed with the device private key, the cryptocurrency request including a requested credit amount and the device public key”; also see paragraph 0059).
It would have been obvious to one of ordinary skill in the art on the effective filing date of the present application to modify Yan with teaching from Boemi to include the payment request block is obtained by signing based on a private key of the transaction initiation device. The modification would have been obvious, because it is merely applying a known technique (i.e., signing a block in a blockchain with user’s private key) to a known method (i.e., cross-border transaction using blockchain) ready to provide predictable result (i.e., enhance security).
Examiner further notes, the combination of Yan and Boemi does not teach the transaction request is cancellation request.
Morais teaches canceling cross-border transaction using smart contract (see paragraph 0025, “With a checkout and/or payment smart contract for a transaction processed between two users (e.g., a buyer and seller, such as in a cross-border transaction), the smart contract may be canceled, and the transaction may not be processed between the two users”).
It would have been obvious to one of ordinary skill in the art on the effective filing date of the present application to modify the combination of Yan and Boemi with teaching from Morais to include the transaction request is cancellation request. The modification would have been obvious, because it is merely applying a known technique (i.e., canceling cross-border transaction using smart contract) to a known method (i.e., cross-border transaction using blockchain) ready to provide predictable result (i.e., allow user to cancel a transaction governed by a smart contract).
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yan (Pub. No.: US 2022/0292488), in view of Boemi (Pub. No.: US 2020/0074438), and further in view of Wu et al. (Pub. No.: US 2020/0394176).
As per claim 12, Yan does not teach wherein a consensus algorithm configured in the blockchain is a HotStuff-like consensus algorithm.
Wu teaches a consensus algorithm configured in the blockchain is a HotStuff-like consensus algorithm (see paragraph 0101, “consensus can be determined using a HotStuff consensus protocol”; see paragraph 0145 and 0533).
It would have been obvious to one of ordinary skill in the art on the effective filing date of the present application to modify Yan with teaching from Wu to include the a consensus algorithm configured in the blockchain is a HotStuff-like consensus algorithm. The modification would have been obvious, because it is merely applying a known technique (i.e., using HotStuff consensus algorithm) to a known method (i.e., cross-border transaction using blockchain) ready to provide predictable result (i.e., enhance security).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO FU whose telephone number is (571)270-3441. The examiner can normally be reached 9:00 AM - 6:00 PM PST.
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, Christine M Behncke can be reached at (571) 272-8103. 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.
/HAO FU/Primary Examiner, Art Unit 3695
SEPT-2026
