DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 03/02/2026.
Claims 1, 5, 7, 8, 12, 14, 15, 19 and 20 are amended.
Claims 2, 3, 9, 10, 16 and 17 are cancelled.
Claims 1, 4-8, 11-15 and 18-26 are pending.
Claims 1, 4-8, 11-15 and 18-26 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 03/02/2026 have been fully considered but they are not persuasive.
112
The 112 rejections are maintained.
Applicant’s statements fail to show where in the specification there is sufficient structure, material, or acts to entirely perform the recited function. Applicant’s arguments do not show the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, nor written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim. A “software process” is not structural and the claims do not recite sufficient structure to perform the recited functions. The rejections are maintained.
103
Applicant argues “Thus, the hashlock value is published to the destination ledger and, in response, a software process that is also executing on the destination ledger generates settlement instructions and locks the destination asset in a HTLC. Significantly, this is all done automatically on the destination ledger by a software process executing on the destination ledger. Contrary to the assertion in the Office Action, Fang does not disclose this combination of elements.” Examiner disagrees.
First, it does not appear that Applicant’s own specification actually discloses this combination of elements, the combination of Fang and Shu do.
Secondly, Fang(¶ 127, 134, 135, 137) discloses “A participant system (e.g., associated with Alice) of the ETH blockchain network 310 can invoke an HTLC transaction to call any function defined in the first HTLC smart contract by initiating a transaction with an address of the first HTLC smart contract in the ETH blockchain network 310. Similarly, a participant system (e.g., associated with Bob) of the BTC blockchain network 320 can invoke another HTLC transaction to call any function defined in the second HTLC smart contract by initiating a transaction with an address of the second HTLC smart contract in the BTC blockchain network 320…ob can initiate a transaction TX2 according to the second HTLC. In some embodiments, Bob can set the received secret hash H as the hash lock of the second HTLC, set another expiration time t2 as the time lock, and store a corresponding number of BTCs, e.g., 3 BTCs, in the corresponding account address of the second HTLC smart contract in the BTC blockchain network 320. In some embodiments, the second HTLC can be also encrypted such that the second HTLC can be opened only with Alice's signature… – In some embodiments, the expiration time t2 can correspond to a number of blocks to be generated by the BTC blockchain network 320, or based on another event or time unit. The expiration time t2 can be shorter than the expiration time t1 such that Alice can retrieve the number of BTCs from the second HTLC address in the BTC blockchain network 320…After Bob executes the HTLC lock transaction TX2 in the BTC blockchain network 320, the transaction TX2 is published in the BTC blockchain network 320 and the second HTLC is waiting for a proof”
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: claims 1, 4-8, 11-15 and 18-20 recite functions performed “… by the … software process,…” .
According to the disclosure (¶ 18, 26), “The settlement bot 210A and second settlement bot 210B are processes executing on the ledgers to automate portions of the techniques described, as described in further detail below. Similarly, the source entity delegate bot 215 and the destination entity delegate bot 220 act on behalf of users on the ledgers. Each delegate bot may be provided by the management device 110 or by a different financial institution.” The “software process” are not structural elements but appear to be programs executed or provided by devices. The claims recite these “software process” as the entities performing functions, but the “software process” are not structural and it is further unclear from the disclosure what entities they are to be performing these functions.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims1, 4-8, 11-15 and 18-26 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 4-8, 11-15 and 18-20 recite functions performed “… by the … software process,…” . According to the disclosure (¶ 18, 26), “The settlement bot 210A and second settlement bot 210B are processes executing on the ledgers to automate portions of the techniques described, as described in further detail below. Similarly, the source entity delegate bot 215 and the destination entity delegate bot 220 act on behalf of users on the ledgers. Each delegate bot may be provided by the management device 110 or by a different financial institution.” The limitations are not supported by the disclosure. The entire disclosure does not recite the word “software” and does it provide written description of a “software process” that performs any functions, nor any software, process or “software process” capable of performing any functions. The disclosure does not provide written description for the claim limitations. Dependent claims 4-7, 11-14 and 18-26 are rejected.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 4-8, 11-15 and 18-26 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 1, 4-8, 11-15 and 18-20 recite functions performed “… by the … software process,…” . The claims are unclear and indefinite. It is unclear how a “software process” is capable of performing simple computing functions such as receiving and sending information. Here, the claims recite the “software process” “locking… generating… publishing… unlocking… executing instructions”. A “software process” is unable to enact any of the claimed steps. The claims are unclear and indefinite. Dependent claims 4-7, 11-14 and 18-26 are rejected.
Claim limitations performed by the “… software process” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Claims 1, 4-8, 11-15 and 18-20 recite functions performed “… by the … software process,…” .
According to the disclosure (¶ 18, 26), “The settlement bot 210A and second settlement bot 210B are processes executing on the ledgers to automate portions of the techniques described, as described in further detail below. Similarly, the source entity delegate bot 215 and the destination entity delegate bot 220 act on behalf of users on the ledgers. Each delegate bot may be provided by the management device 110 or by a different financial institution.” The “software process” are not structural elements but appear to be programs executed or provided by devices. The claims recite these “software process” as the entities performing functions, but the “software process” are not structural and it is further unclear from the disclosure what entities they are to be performing these functions.
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Dependent claims 4-7, 11-14 and 18-26 are 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, 4-8, 11-15, 18-21, 23 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Fang et al. (US 20210326869) (“Fang”), and further in view of Shu et al (US 2022/0067831) (“Shu”).
Regarding claims 1, 8 and 15, Fang discloses receiving, by a first node executing on a source ledger, from a second node executing on the source ledger, a hashlock value based on a secret value generated by the second node, and transaction information comprising a cross-ledger transaction identifier, an identifier of a source asset associated a source entity on the source ledger, and an identifier of a destination entity (Figure 3, 4; ¶ 86, 91, 94, 96, 100, 102-114, 120, 127-135, 139-141, 145-152, 161-173);
Fang – the transaction information can include, for example, a sender address (e.g., Alice's ETH account address), a receiver address (e.g., the first HTLC address in the ETH blockchain network 310), a transferred value (e.g., 30 ETHs), a transaction commit time (e.g., when TX1 is executed), a secret hash (e.g., H), and/or an expiration time. .. The secret and the hash of the secret can be used to create a hash lock of an HTLC… Alice can invoke the first HTLC smart contract using the address of the first HTLC smart contract in the ETH blockchain network 310 to initialize parameters of the first HTLC smart contract. For example, the secret hash H can be set as a hash lock to be an output of the first HTLC. A condition can be configured for the first HTLC where one knowing the secret can use the secret as a proof to obtain the H value in the first HTLC to obtain the to-be-transferred value from Alice. For example, Alice sets the to-be-transferred value is 30 ETHs, and sends 30 ETHs to the account address of the first HTLC smart contract. Alice can also set an expiration time t1 as a time lock for the hash lock in the first HTLC. That is, within the expiration time, anyone who provides the secret as the proof can get the to-be-transferred value in the TX1, e.g., 30 ETHs stored at the first HTLC smart contract address… In some embodiments, to enable that only an authorized or designated entity, e.g., Bob, can retrieve the transferred value using the secret, Alice can create an encrypted digital lockbox that can be opened only by the secret and the designated entity's unique key (e.g., a signature or other unique identifier). That is, Alice can set the first HTLC such that only Bob can open Alice's lockbox … the consensus process is controlled by an authorized set of nodes, which can be referred to as consensus nodes, one or more consensus nodes being operated by a respective entity (e.g., a financial institution, insurance company). (¶ 96, 128-130, 133)
generating, by the first node, a first set of settlement instructions based on the transaction information, wherein the first set of settlement instructions comprises one or more smart contracts governing one or more transactions on the source ledger, including a first particular transaction to transfer the source asset from the source entity to the destination entity on the source ledger(¶ Figure 3, 4; ¶ 86, 91, 94, 100, 102-105, 112-116, 120-135, 139-141, 145-152, 161-163);
Fang – After an agreement is reached among nodes through a consensus mechanism, the smart contract can be successfully created… transactions pursuant to or otherwise based on HTLC protocol (also referred to as HTLC transactions) can be implemented by pre-deployed smart contracts in the blockchain networks to allow parties to perform their respective operations for the redeemable secret within the expiration time… In some embodiments, a smart contract for generating and managing transactions according to an HTLC (also referred to as HTLC transactions) can be created and delayed in each of the ETH blockchain network 310 and BTC blockchain network 320. The smart contract can also be referred to as an HTLC smart contract. In some embodiments, the HTLC smart contract can be created and initiated by an administrator of blockchain network, one or more parties of a transaction, or another appropriate entity. (¶ 116, 124, 126)
locking, by the first node, the source asset in a first hash time locked contract (HTLC) using the hashlock value, wherein the first HTLC is associated with the first set of settlement instructions based on the cross-ledger transaction identifier (¶ 116, 124-140, 163, 164);
Fang – The HTLC protocol can be configured to lock a given transaction with a hash and time and to only execute the transaction if specified conditions are met… For example, the secret hash H1 can be set as a hash lock to be an output of the first HTLC. A condition can be configured for the first HTLC where one knowing the secret can use the secret as a proof to obtain the H1 value in the first HTLC to obtain the to-be-transferred value from Alice. (¶ 116, 163)
responsive to a third node executing on a destination ledger determining that the first HTLC is locked, publishing, by the third node, the hashlock value to the destination ledger (¶ 116, 124-140, 163, 164);
Fang – At 333, Alice transmits the secret hash H to Bob. At 334, Bob uses the received secret hash H to create a second HTLC in the BTC blockchain network 320 corresponding to the first HTLC created by Alice, for example, by invoking the second HTLC smart contract deployed in the BTC blockchain network 320. Bob can initiate a transaction TX2 according to the second HTLC. (¶ 134)
responsive to the publishing of the hashlock value on the destination ledger: generating, by a fourth node executing on the destination ledger, a second set of settlement instructions, wherein the second set of settlement instructions comprises one or more smart contracts governing one or more transactions on the destination ledger, including a second particular transaction to transfer a destination asset to the source entity on the destination ledger; and (¶ Figure 3, 4; ¶ 86, 91, 94, 100, 102-105, 112-116, 120-135, 139-141, 145-152, 161-173)
Fang – A participant system (e.g., associated with Alice) of the ETH blockchain network 310 can invoke an HTLC transaction to call any function defined in the first HTLC smart contract by initiating a transaction with an address of the first HTLC smart contract in the ETH blockchain network 310. Similarly, a participant system (e.g., associated with Bob) of the BTC blockchain network 320 can invoke another HTLC transaction to call any function defined in the second HTLC smart contract by initiating a transaction with an address of the second HTLC smart contract in the BTC blockchain network 320…ob can initiate a transaction TX2 according to the second HTLC. In some embodiments, Bob can set the received secret hash H as the hash lock of the second HTLC, set another expiration time t2 as the time lock, and store a corresponding number of BTCs, e.g., 3 BTCs, in the corresponding account address of the second HTLC smart contract in the BTC blockchain network 320. In some embodiments, the second HTLC can be also encrypted such that the second HTLC can be opened only with Alice's signature. (¶ 127, 134)
locking, by the fourth node, the destination asset in a second HTLC, the second HTLC being associated with the second set of settlement instructions based on the cross-ledger transaction identifier (¶ Figure 3, 4; ¶ 86, 91, 94, 100, 102-105, 112-116, 120-135, 139-141, 145-152, 161-163)
Fang – Similarly, a participant system (e.g., associated with Bob) of the BTC blockchain network 320 can invoke another HTLC transaction to call any function defined in the second HTLC smart contract by initiating a transaction with an address of the second HTLC smart contract in the BTC blockchain network 320…Bob can initiate a transaction TX2 according to the second HTLC. In some embodiments, Bob can set the received secret hash H as the hash lock of the second HTLC, set another expiration time t2 as the time lock, and store a corresponding number of BTCs, e.g., 3 BTCs, in the corresponding account address of the second HTLC smart contract in the BTC blockchain network 320. In some embodiments, the second HTLC can be also encrypted such that the second HTLC can be opened only with Alice's signature. (¶ 127, 134)
responsive to the second HTLC being locked, publishing, by the second node, the secret value to the destination ledger (¶ Figure 3, 4; ¶ 86, 91, 94, 100, 102-105, 112-116, 120-141, 145-152, 161-163);
Fang – In some embodiments, the expiration time t2 can correspond to a number of blocks to be generated by the BTC blockchain network 320, or based on another event or time unit. The expiration time t2 can be shorter than the expiration time t1 such that Alice can retrieve the number of BTCs from the second HTLC address in the BTC blockchain network 320…After Bob executes the HTLC lock transaction TX2 in the BTC blockchain network 320, the transaction TX2 is published in the BTC blockchain network 320 and the second HTLC is waiting for a proof. (¶ 135, 137)
responsive to the secret value being published to the destination ledger, the fourth node: unlocking the destination asset in the second HTLC using the secret value; executing the second set of settlement instructions, the executing of the second set of settlement instructions comprising transferring the destination asset to a source account on the destination ledger associated with the source entity; and (¶ Figure 3, 4; ¶ 86, 91, 94, 100, 102-105, 112-116, 120-141, 145-152, 161-163);
Fang – once the condition of the second HTLC is satisfied (e.g., the hash lock is unlocked by the secret), the second HTLC is executed and Alice receives the transferred value in TX2, e.g., 3 BTCs, stored in the second HTLC at step 336. (¶ 138)
publishing the secret value on the source ledger; and responsive to the secret value being published to the source ledger, the first node: unlocking the source asset in the first HTLC using the secret value; and executing the first set of settlement instructions, the executing of the first set of settlement instructions comprising transferring the source asset to a destination account on the source ledger associated with the destination entity (¶ Figure 3, 4; ¶ 86, 91, 94, 100, 102-105, 112-116, 120-141, 145-152, 161-163);
Fang – As the secret is revealed in the BTC blockchain network 320, Bob knows the secret and initiates a transaction TX4 by providing the secret as the proof to execute the first HTLC in the ETH blockchain network 310 at step 337. Once the condition of the first HTLC is satisfied (e.g., the hash lock is unlocked by the secret), the first HTLC is executed and Bob receives the transferred value in TX1, e.g., 30 ETHs, stored in the first HTLC at step 338. (¶ 140)
Fang does not teach the term “software process”.
Shu teaches software process (Abstract; Figure 3; ¶ 151-166);
Claim Interpretation – According to the disclosure(¶ 18), “The management device 110 is a computing device (e.g., of a financial institution or an organization administrating a distributed ledger) that provides bots for atomic cross-chain transactions, as further described below. ” From the claims and disclosure, it is unclear what a “bot” represents.
Shu – When the technical solutions provided in the embodiments of this specification are implemented by means of software or firmware, related program code can be stored in the memory and can be executed by the processor. (¶ 154)
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 Fang(¶ 116), which teaches “to ensure that decentralized peer-to-peer transactions can be successfully completed, e.g., in atomic swaps, a mechanism or protocol, e.g., Hash Time Lock Contract (HTLC) protocol, can be developed to ensure that no fraud occurs on either party” and Shu in order to reduce the delivery time in cross currency transactions (Shu; ¶ 7).
Regarding claims 4, 11 and 18, Fang discloses wherein publishing the secret value is further responsive to: verifying the second set of settlement instructions are congruent with the transaction information (Abstract; ¶ 124-127, 153-158).
Regarding claims 5, 12 and 19, Fang discloses wherein the blockchain node locks the first HTLC responsive to: receiving, first software process, from a source entity associated with the second software process, approval of the set of settlement instructions, comprising a first cryptographic signature; and receiving, by the first software process, from a custodian entity associated with the source entity, approval of the set of settlement instructions, comprising a second cryptographic signature (¶ 163-171). Shu teaches software process (Abstract; Figure 3; ¶ 151-166).
Regarding claims 6, and 13, Fang discloses wherein the transaction information comprises an identifier of the source entity, and the identifier of the source entity is not a blockchain wallet identifier (¶ 133, 137, 139, 145, 174, 175, 200, 224).
Regarding claims 7, 14 and 20, Fang discloses the method further comprising: storing, by the second software process, the secret value in association with the cross-ledger transaction identifier at a remote database (¶ 134, 164, 187, 197, 203, 217); and responsive to determining the second HTLC is locked: extracting the cross-ledger transaction identifier from the second HTLC; and retrieving the secret value from the remote database using the extracted cross-ledger transaction identifier (¶ 134, 139, 140, 164, 165, 193, 205, 214). Shu teaches software process (Abstract; Figure 3; ¶ 151-166).
Regarding claims 21, and 23, Fang discloses wherein the identifier of the source entity is a global identifier (¶ 96, 128-131, 159-177).
Regarding claim 25, Fang discloses wherein the transaction information comprises an identifier of the source entity, and the identifier of the source entity is not a blockchain wallet identifier ( ¶ 96, 128-131, 159-177).
Claims 22, 24 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Fang et al. (US 20210326869) (“Fang”), in view of Shu et al (US 2022/0067831) (“Shu”) and further in view of Blount (US 20200250753) (“Blount”).
Regarding claims 22, and 24, Neither Fang nor Shu discloses wherein the global identifier is a legal entity identifier. Blount teaches wherein the global identifier is a legal entity identifier ( ¶ 15, 39-42, 62; claim 11). 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 Fang, Shu and Blount in order to accurately identify, label and track a unique transaction using LEIs (Blount; ¶ 16-25).
Regarding claim 26, Blount teaches wherein the identifier of the source entity is a legal entity identifier ( ¶ 15, 39-42, 62; claim 11).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cao et al., (US 20210226800) teaches cross chain transactions and hash time locks.
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