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 is a Final Office action in response to the request for reconsideration filed on 11/11/2025.
DETAILED CORRESPONDENCE
Acknowledgements
The Amendment of claims 1, 4, 7-8, 10, 12-20 and 23, filed on 11/11/2025 is acknowledged.
Claims 1-24 were originally filed
Claims 2-3, 5-6, 21-22 and 24, are cancelled
Claim 25, is newly added, therefore
Claims 1, 4, 7-20, 23 and 25 are pending and hereby examined.
Examiner’s Response to Amendment/Remarks
35 USC § 101
Applicant’s amendment/remarks filed on 11/11/2025 is hereby acknowledged, and the independent claims as amendment, have overcome the 101 rejection. Therefore, the 101 rejection is hereby withdrawn.
35 USC § 112
Claim 6 is now cancelled, and no longer considered for prosecution, therefore the
112 rejection is hereby withdrawn.
35 USC § 102
Claim 2 is now cancelled, and no longer considered for prosecution, therefore the
102 rejection is hereby withdrawn, and it’s dependent claims, now amended to depend from claim 1, are now rejected under 35 USC § 103 rejection below.
35 USC § 103
Applicant’s amendment/remarks filed on 11/11/2025 is hereby acknowledged,
and have been found unpersuasive by the Examiner. On page 11, Applicant asserts that [The examiner's objection appears to be contradictory. On page 28 of the OA the
examiner acknowledges that Tartan does not disclose the first clause of claim 1, which recites the passing a verification of the identity of the first party with a token issuer, and receiving a token as evidence of that; but then on pages 25-28 of the OA, the examiner alleges that Tartan does disclose the subsequently-recited features of recording a transaction comprising "the token" (emphasis added), and causing the second party to verify that first party "is evidenced to have passed the verification by the token issuer".
Tartan does not disclose a token evidencing that the first party (Alice) has passed an identity verification with a token issuer, nor including such a token in the payload of a transaction].
Examiner respectfully disagrees, in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this instance, Specogna discloses passing a verification conducted by a token issuer, thereby invoking the token issuer to issue a token [e.g., response to verification] evidencing that the first party passed the verification by the token issuer, wherein the verification by the token issuer comprises a verification of an identity of the first party {see at least Fig.8B step 816-826, ¶¶ 0130, 0157-0158, 0161-0162} as disclosed below, therefore, Specogna establishes evidencing that the first party passed the verification of identity, and further discloses in Fig 8B step 816-826 the elements of the card account identifier and the authentication token (both in the transaction payload) are validated. Therefore, Tartan teachings in combination of Specogna teaches the subsequent claim steps as disclosed below, is sufficient in art.
Finally, Applicant further assert that “…Finally, the examiner relied on Jones for the feature of previous claim 6, now incorporated in claim 1, i.e. the use of a PUF (physically unclonable function) to generate the identity verification token…. The client 2, enters a Secret pass-phrase on the glasses keypad 58, and the authentication module 53 calculates a response 9 based upon the challenge 8 and the pass-phrase, which the client 2 then enters onto the keypad 10 of the kiosk 5 (step 120). A series of challenges 8 and responses 9 may follow, in steps 130 and 140 before authentication is complete (step 150)… However, this does not disclose a PUF. A PUF - physically unclonable function - is a term of art referring to a class of physical systems and devices which act as random (but repeatable) functions uniquely characterised by their inherent physical properties. I.e. a PUF is uniquely identified by probing its physical properties with a physical stimulus (the challenge) in order to receive back a unique response.”
Examiner respectfully disagrees with this argument, unless Applicant is claiming to invent a PUF “physically unclonable function”, which is not the case in the claims filed. The independent claims as amended now has the limitation
“wherein the verification of the identity of the first party comprises:
inputting a challenge of the first party into a PUF device comprising a physically unclonable function, PUF, and receiving back a response based on the PUF: and
supplying the response to the token issuer to enable the token issuer to check that the response matches a pre-registered version of the response from a preceding set-up phase”, the intended result here is to input a challenge into a system and receive a response from the system, this response is used to verify an entity. Therefore, with the prior art, Jones inputting a challenge to a system and receive a response that is used to verify the identity of an entity, {see at least ¶¶ 0003, 0020-0021, 0032} of Jones as disclosed below, is sufficient in art.
Therefore, the 103 rejection is hereby maintained.
. 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 difference 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 the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
i. Determining the scope and contents of the prior art.
ii. Ascertaining the differences between the prior art and the claims at issue.
iii. Resolving the level of ordinary skill in the pertinent art.
iv. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4, 7-20, 23 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Chloe Tartan et al., (GB 2592980 A) in view of Specogna et al., (US 20150095240 A1) and further in view of Mark A. Jones (US 20020101988 A1).
With respect to claims 1, 23 and 25, Tartan teaches computer equipment comprising memory and processing apparatus, the memory comprising one or more memory units and the processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when run on the processing apparatus, and a computer program embodied on a non-transitory computer readable medium or media, the computer program comprising code configured so as when run on one or more processors of computer equipment of a first party {Page 13 line 29-Page 14 line 15}, the one or more processors perform a method comprising:
causing to be recorded on a blockchain a first blockchain transaction comprising
an output that comprises a) funds of the first party for a commercial transaction to be conducted with a second party and b) a locking script defining at least a first condition for unlocking the funds, wherein the locking script further comprises a data payload comprising the token {see at least Fig. 2 203-202, Page 17 line 9-Page 18 line 6 “In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as the source for the input 202 of another new transaction…”,and also page 181-6 “The preceding transaction Tto may already have been validated and included in the blockchain 150 at the time when Alice creates her new transaction Tx', or at least by the time she sends it to the network 106. It may already have been included in one of the blocks 151 at that time, or ft may be still waiting in the pool 154 in which case it will soon be included in a new block 151”, and also Page 18 line 21-30 “One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTX00. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). I.e. the locking script defines an unlocking condition, typically comprising a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to whom the preceding transaction is locked”}.
sending an indication of the first blockchain transaction to the second party, thereby prompting the second party to verify that the first blockchain transaction has been validated for recordal on the blockchain and that said output remains unspent and thus in doing so to verify both that the first party has the funds for the commercial transaction and is evidenced to have passed the verification by the token issuer {see at least Fig. 2, Page 5 lines 17-29 “…wherein the first blockchain transaction comprises an input for unlocking an output of a blockchain transaction previously transmitted to one or more nodes of a blockchain network for inclusion in the blockchain; determining whether the first party has transmitted, to the second party, (a) a signature generated based on the first blockchain transaction and one or more first time indicators, each first time indicator indicating when the first blockchain transaction was generated and/or transmitted, and (h) the one or more time indicators; and accepting the first blockchain transaction based on one or more conditions, a first one of the one or more conditions being that the first party has transmitted the signature and the one or more first time indicators. The present invention mitigates against the risk of the double spend attempts caused by malicious actors. To build on the scenarios described above, the first and second parties may be nodes of an loT network, wherein the first blockchain transaction (a "control transaction") is used by the first party (first node) to instruct the second party (second node) to control an end device…”, and also Page 10 lines 10-18 “…The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will typically use one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing a quantity of a digital asset belonging to a user 103 to whom the output is cryptographically locked (requiring a signature of that user in order to be unlocked arid thereby redeemed or spent). Each input points back to the output of a preceding transaction 152, thereby linking the transactions”}, and
conducting the commercial transaction with the second party, the commercial transaction being dependent on said verifying of the first blockchain transaction and including a second blockchain transaction being recorded on the blockchain, wherein the second blockchain transaction comprises an input pointing to said output and comprising an unlocking script meeting said first condition in order to transfer the funds to the second party {see at least Fig 2, Page 29 lines 14-23 “Bob 103a may only act on the first transaction under one or more conditions. That is, Bob 103a may choose whether or not to accept the first transaction only if at least one condition is met. A first condition which has to be met in order for Bob 103a to accept the first transaction is that Alice 103a must have sent the signature (i.e. the signature based on the first transaction and the time indicator(s)) and the time indicator(s) to Bob 103b. The condition may be met if Alice 103a sends the signature and indicator(s) with (e.g. at the same time as) the first transaction…”, and also Page 30 lines 16-21 “…If one, some or all of the conditions for accepting the first transaction have been met, Bob 103b may add one or more inputs and/or outputs to the first transaction in order to complete the transaction. Bob 103b may then submit the completed transaction to the blockchain network 106.Additionally or alternatively, Bob may send the completed transaction back to Alice 103a. Alice 103a may then submit the completed transaction to the blockchain network 106”}.
Tartan does not explicitly disclose, passing a verification conducted by a token issuer, thereby invoking the token issuer to issue a token evidencing that the first party passed the verification by the token issuer, wherein the verification by the token issuer comprises a verification of an identity of the first party
However, Specogna discloses passing a verification conducted by a token issuer, thereby invoking the token issuer to issue a token [e.g., response to verification] evidencing that the first party passed the verification by the token issuer, wherein the verification by the token issuer comprises a verification of an identity of the first party {see at least Fig.8B step 816-826, ¶¶ 0130 “The instructions for generating authentication credentials may include, for example, instructions for contacting a CSR 106 or an automated system such as an IVR system in order to activate the temporary card account identifier for use and generate a PIN or other authentication token that must be provided to enable transactions involving the temporary card account identifier…”, and also ¶¶ 0157-0158, “…a computing device operated by a financial institution teller, etc.) may transmit a request to perform validation processing on the combination of the card account identifier and the authentication token. The request may be transmitted to one or more other systems of the architecture 100 such as, for example, the customer service system 110, the card issuer system 112, or the service provider system 118. In certain example embodiments, the request may be submitted to the card issuer system 112 (or more specifically a core account processing system, a fraud rules system, or the like forming part of the card issuer system 112) in order to determine whether the received authentication token is associated with the received card account identifier. The request may be submitted as a transaction to a payment network provider system 114 for transmission to the card issuer system 112”, and ¶ 0161-0162}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the blockchain transaction of Tartan to include the elements of Specogna. One would have been motivated to do so, in order to have a financial account holder authenticated. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction. Specogna is merely relied upon to illustrate the functionality of having a secured fund transfer transaction between two parties in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, as well as having a secured fund transfer transaction between two parties are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Tartan, as well as Specogna would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Tartan/Specogna.
The combination of Tartan in view of Specogna does not explicitly disclose
wherein the verification of the identity of the first party comprises: inputting a challenge of the first party into a PUF device comprising a physically unclonable function, PUF, and receiving back a response based on the PUF: and supplying the response to the token issuer to enable the token issuer to check that the response matches a pre-registered version of the response from a preceding set-up phase.
However, Jones discloses wherein the verification of the identity of the first party comprises: inputting a challenge of the first party into a PUF device comprising a physically unclonable function, PUF, and receiving back a response based on the PUF; and supplying the response to the token issuer to enable the token issuer to check that the response matches a pre-registered version of the response from a preceding set-up phase {see at least ¶¶ 0003, 0020 “… During authentication, the kiosk 5 displays on the screen 7 an alphanumeric challenge 8 issued by the authentication module 14. The client 2, upon viewing the challenge 8, inputs the challenge and a secret pass-phrase into a keypad on the dongle 4. The single challenge and pass-phrase code may be enough to generate an OTP, or alternatively a response 9 may be generated by a processor in the dongle 4. The response 9 is entered back through the keyboard 10 into the kiosk 5, which sends the information to the authentication module 14…”, and also ¶¶ 0021, 0032}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the blockchain transaction of Tartan in view of Specogna to include the elements of Jones. One would have been motivated to do so, in order to have a protected and secured client authentication input interface. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction and Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants. Jones is merely relied upon to illustrate the functionality of having a protected and secured client authentication input interface, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, and providing a commercial fund transfer transaction using a blockchain between participants as well as having a protected and secured client authentication input interface, are implemented through well-known computer technologies in the same or similar context, would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Tartan in view of Specogna as well as Jones would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Tartan/Specogna/Jones.
With respect to claim 4, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Tartan, teaches wherein the token is cryptographically signed by the token issuer, thereby enabling the second party to authenticate the token {see at least Page 4 lines 24-26, Page 5 lines 23-29, Page 8 lines 14-18, and Page 10 lines 15-23 “…The node protocol typically requires the node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in an ordered sequence of transactions 152. In an output-based case, this may comprise checking that the cryptographic signature of the user included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 1521 which the new transaction spends, wherein this condition typically comprises at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points…”}.
With respect to claim 7, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Jones discloses, wherein the challenge input to the PUF device is a secondary challenge, and the PUF device comprises a transform function which transforms the secondary challenge into a primary challenge which is input to the PUF to generate the response {see at least ¶¶ 0003, 0020 “… During authentication, the kiosk 5 displays on the screen 7 an alphanumeric challenge 8 issued by the authentication module 14. The client 2, upon viewing the challenge 8, inputs the challenge and a secret pass-phrase into a keypad on the dongle 4. The single challenge and pass-phrase code may be enough to generate an OTP, or alternatively a response 9 may be generated by a processor in the dongle 4. The response 9 is entered back through the keyboard 10 into the kiosk 5, which sends the information to the authentication module 14…”, ¶¶ 0021, 0032 “A transaction process is described with reference to FIG. 8. When a transaction at a kiosk 5 begins, in step 100, a challenge 8 that appears on the kiosk display is read and digitized by OCR 51, which sends the information to the authentication module 53. In step 110, the authentication module 53 sends a prompt signal to the glasses display 57 requesting the client 2 to enter a pass-phrase. The client 2, enters a secret pass-phrase on the glasses keypad 58, and the authentication module 53 calculates a response 9 based upon the challenge 8 and the pass-phrase, which the client 2 then enters onto the keypad 10 of the kiosk 5 (step 120). A series of challenges 8 and responses 9 may follow, in steps 130 and 140 before authentication is complete (step 150). Successful authentication confirms the sequence number stored in memory module 54 because the number of hash-function iterations matches between the kiosk system and the decryption glasses”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the blockchain transaction of Tartan in view of Specogna to include the elements of Jones. One would have been motivated to do so, in order to have a protected and secured client authentication input interface. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction and Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants. Jones is merely relied upon to illustrate the functionality of having a protected and secured client authentication input interface, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, and providing a commercial fund transfer transaction using a blockchain between participants as well as having a protected and secured client authentication input interface, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Tartan in view of Specogna as well as Jones would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Tartan/Specogna/Jones.
With respect to claim 8, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Specogna, discloses wherein the verification of the identity of the first party comprises: the first party presenting documentary evidence, or a copy thereof, to the token issuer {see at least ¶ 0097 “The identifying information may further include one or more authentication credentials that are unambiguously associated with the cardholder 102 and that may serve to authenticate the purported cardholder as the cardholder 102 or other authorized user, and to protect against fraudulent misuse of the cardholder's account. Such authentication credentials may include, without limitation, one or more of a password, certificate, or other security token; information that is unlikely to be widely known and that may be stored as part of the cardholder's account profile information such as, for example, a social security number or other government issued identifier (or a portion thereof), a mother's maiden name, a security word or phrase such as an answer to a security question (e.g., what is your best friend's last name?), or the like; information that may be used in conjunction with other authentication credentials to authenticate the purported cardholder such as, for example, a phone number, zip code, or the like; and so forth…”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the blockchain transaction of Tartan in view of Jones to include the elements of Specogna. One would have been motivated to do so, in order to have a financial account holder authenticated. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction and Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants. Jones is merely relied upon to illustrate the functionality of having a protected and secured client authentication input interface, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, and providing a commercial fund transfer transaction using a blockchain between participants as well as having a protected and secured client authentication input interface, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Tartan in view of Specogna as well as Jones would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Tartan/Specogna/Jones.
With respect to claim 9, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Specogna discloses wherein the documentary evidence comprises one or more of: a passport, driver's license, birth certificate, ID card, and/or utility bill of the first party {see at least ¶¶ 0097}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the blockchain transaction of Tartan in view of Jones to include the elements of Specogna. One would have been motivated to do so, in order to have a financial account holder authenticated. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction and Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants. Jones is merely relied upon to illustrate the functionality of having a protected and secured client authentication input interface, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, and providing a commercial fund transfer transaction using a blockchain between participants as well as having a protected and secured client authentication input interface, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Tartan in view of Specogna as well as Jones would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Tartan/Specogna/Jones.
With respect to claim 10, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Tartan, teaches wherein the verification of the identity of the first party comprises authenticating a digital certificate certifying the identity of the first party {see at least Page 30 lines 10-14 “…Bob 103b may already have Alice's public key, or he may access it from a public record. As an example, Alice's public key may be certified by a certificate authority and, for instance, recorded in an (OP_RETURN) output of a blockchain transaction 152. If the signature has not been generated using a private key corresponding to an expected public key, Bob 103b may reject the first transaction”}.
With respect to claim 11, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Specogna discloses wherein the verification comprises an eligibility
test to test that the first party is eligible to spend the funds {see at least ¶¶ 0097, 0129 “The instructional information may be transmitted for presentation to the cardholder 102 via any of the mechanisms described above. The instructional information may include, but is not limited to, an indication of the conditions that govern use of the temporary card account identifier, instructions for activating the temporary card account identifier in order to enable its use (which may include generating authentication credentials such as a PIN), information associated with the one or more funds dispensing locations at which the card account identifier may be used to obtain access to funds, and so forth“, and ¶ 0130}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the blockchain transaction of Tartan in view of Jones to include the elements of Specogna. One would have been motivated to do so, in order to have a financial account holder authenticated. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction and Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants. Jones is merely relied upon to illustrate the functionality of having a protected and secured client authentication input interface, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, and providing a commercial fund transfer transaction using a blockchain between participants as well as having a protected and secured client authentication input interface, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Tartan in view of Specogna as well as Jones would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Tartan/Specogna/Jones.
With respect to claim 12, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Tartan, teaches wherein said verifying that the first blockchain transaction has been validated for recordal on the blockchain comprises: verifying that the first blockchain transaction has been recorded on the blockchain {see at least Page 2 lines 10-17 “One of the fundamental principles of the blockchain is that parties are unable to double spend an unspent transaction output (UTXO). Each blockchain transaction submitted to the blockchain network must contain an input that references an output of a previously submitted transaction, e.g. a transaction that has been accepted onto the blockchain network. To be validated and accepted onto the blockchain network, the referenced output must be an unspent transaction output. If the referenced output has already been spent, the transaction will be rejected. This prevents double spending of outputs that have been recorded on the blockchain”, Page 1 line 31-Page 2 line 6, and Page 30 lines 10-14}.
With respect to claim 13, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Tartan, teaches, wherein said verifying that the first blockchain transaction has been validated for recordal on the blockchain comprises: verifying that a node of a blockchain network has accepted the first blockchain transaction into a pool of pending transactions for recordal on the blockchain {see at least Page 8 lines 14-27 “…Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a forwarding node 104, miner 104M, storage node 1045 or any combination of two or all of these… Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a forwarding node 104, miner 104M, storage node 1045 or any combination of two or all of these”}.
With respect to claim 14, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Tartan, teaches wherein said indication comprises a copy of the first blockchain transaction {see at least Page 16 lines 11-18 “On condition that the newly received transaction 152j passes the test for being deemed valid (i.e. on condition that it is "validated"), any storage node 1045 that receives the transaction 152] will add the new validated transaction 152 to the pool 154 in the copy of the blockchain 150 maintained at that node 1045. Further, any forwarding node 104F that receives the transaction 152] will propagate the validated transaction 152 onward to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, then assuming the transaction 152] is valid, this means it will soon be propagated throughout the whole P21' network 106”}.
With respect to claim 15, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 14 above.
Furthermore, Tartan, teaches wherein the second party checks that the token is included in the copy of the first blockchain transaction before attempting to complete the commercial transaction {see at least Page 20 lines 18-24 “…if the unlocking script in Tx/ meets the one or more conditions specified in the locking script of Txo (so in the example shown, if Alice's signature is provided in Tx/ and authenticated), then the node 104 deems T; a valid. If it is a mining node 104M, this means it will add it to the pool of transactions 154 awaiting proof-of-work. If it is a forwarding node 104F, it will forward the transaction Txt to one or more other nodes 104 in the network 106, so that it will be propagated throughout the network. Once Tx/ has been validated and included in the blockchain 150, this defines UTY00 from TX0 as spent”}.
With respect to claim 16, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Tartan, teaches wherein said indication comprises a transaction ID of the first blockchain transaction and an index of the output within the first blockchain transaction {see at least Fig. 2 203-202, Page 19 lines 10-22 “So in the example illustrated, LITX0oin the output 203 of Txo comprises a locking script [Checksig P4 which requires a signature Sig PA of Alice in order for LITX00 to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTX00 to be valid). [Checksig PA] contains the public key PA from a public-private key pair of Alice. The input 202 of Tx.1 comprises a pointer pointing back to TX1 (e.g. by means of its transaction ID, Tx/Do, which in embodiments is the hash of the whole transaction Txo). The input 202 of TX1 comprises an index identifying UTrOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Tx2 further comprises an unlocking script <Sig P,4> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). What data (or "message") needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these”}.
With respect to claim 17, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 16 above.
Furthermore, Tartan, teaches wherein the second party uses transaction ID to look up the output in a list of unspent outputs maintained by a node of a blockchain network or by an intermediary service, and checks that token is included in the payload of said output before attempting to complete commercial transaction {see at least Fig. 2 203-202, Page 19 lines 10-22}.
With respect to claim 18, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Tartan, teaches wherein said indication comprises a complete version of the second transaction, the second transaction comprising a pointer to the output of the first blockchain transaction which the second party uses to perform said verification that the first transaction has been validated and that the output remains unspent, and wherein the second party further checks contents of the second blockchain transaction as received from the first party before forwarding to be recorded on the blockchain as part of said commercial transaction conducted with the first party {see at least Fig. 2 203-202, Page 19 lines 10-22, Page 30 lines 16-21 “…If one, some or all of the conditions for accepting the first transaction have been met, Bob 103b may add one or more inputs and/or outputs to the first transaction in order to complete the transaction. Bob 103b may then submit the completed transaction to the blockchain network 106. Additionally, or alternatively, Bob may send the completed transaction back to Alice 103a.Alice 103a may then submit the completed transaction to the blockchain network 106”}.
With respect to claim 19, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Tartan, teaches wherein the payload is included in said output using an OP_RETURN or OP_DROP opcode in the locking script {see at least Page 22 lines 19-22 “…As another example, OP_RETURN is an opcode of the Script language for creating an unspendable output of a transaction that can store metadata within the transaction, and thereby record the metadata immutably in the blockchain 150. E.g., the metadata could comprise a document which it is desired to store in the blockchain”}.
With respect to claim 20, the combination of Tartan in view of Specogna and in view of Jones teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Tartan, teaches wherein said conditions in the locking script defines said first condition and one or more alternative conditions for unlocking the funds, thereby enabling at least one of the token issuer, first party or another party to revoke said token by spending the output based on meeting one said alternative conditions {see at least Page 22 line 31-Page 23 line 5 “The locking script is sometimes called "scriptPubKey" referring to the fact that it comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred”}.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
The prior art made of record and not relied upon:
(US Pat. 10250708 B1) – Carver, High Performance Distributed System of Record- relates generally to managing a distributed system of record
across a set of computing resources in a distributed network.
2) (US Pat. 11288736 B1) – Jette et al., Blockchain-based Shared Appreciation Note – relates generally to a blockchain-based platform using smart contracts and cryptographically secure token technology to facilitate and securely implement a pool of shared appreciation notes (SANs).
3) (US Pat. 11531985 B2) – Weight et al., Multi-approval System Using M Of N Keys to Generate a Sweeping Transaction at A Customer Device – relates to Keys, including cryptographic keys, can be used to encrypt data, decrypt data, and sign transactions. Keys can include (but are not limited to) private keys, public keys, encryption keys, signing keys, and other cryptographic keys as well as passwords and secrets. One difficulty with keys is keeping them both secure and accessible when needed. In some instances, it is not desirable to have access to a wallet limited to a single person/entity because this may leave the wallet vulnerable to malicious attacks. Instead, it may be desirable to require verification from more than
one person/entity to use a wallet.
4) (US 20230098747 A1) - Ramesh Mason Vijayaraghavan, Systems and Methods for Payment Transactions, Alerts, Dispute settlement, and Settlement Payments, Using Multiple Blockchains - relates generally to the field of payment transactions and, more particularly, to payment transactions, alerts, dispute settlement, and settlement payments, using multiple blockchains.
5) (US 20200322132 A1) – Covaci et al., System and Method for Authentication Off-Chain Data Based on Proof Verification - relates generally to blockchain technologies, and more particularly to the production of a proof of a conversation that can be verified in a Bitcoin script, offering also information that can be utilized further in case of recourse.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number (571)272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form
/V.I./Examiner, Art Unit 3698 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698