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 .
DETAILED CORRESPONDENCE
Acknowledgements
The Amendment of claims 1, 11, 17, 20, 23 and 25, filed on 05/20/2026 is acknowledged.
Claims 1, 4, 7-20, 23 and 25 are pending and hereby examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/20/2026 has been entered.
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), and in view of JO et al., (KR 20140191608 A).
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, the first party, second party and token issuers being three different parties {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, and further comprises an eligibility test.
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, and further comprises an eligibility test {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.
The combination of Tartan in view of Specogna in view of Jones does not
explicitly disclose wherein the eligibility test comprises a test that the first party has been granted a license or permission to conduct the transaction with the second party, wherein either i) the token issuer is a content owner and the commercial transaction comprises provision by the second party to the first party of content licensed from the token issuer, or ii) the token issuer is a regulator and the commercial transaction comprises provision by the second party to the first party of regulated content or a regulated product or service regulated by the token issuer, or iii) the token issuer is a guardian or parole officer of the first party and the funds spent by the commercial transaction are funds to be spent only under control of the token issuer.
However, JO discloses wherein the eligibility test comprises a test that the first party has been granted a license or permission to conduct the transaction with the second party, wherein either i) the token issuer is a content owner and the commercial transaction comprises provision by the second party to the first party of content licensed from the token issuer {see at least ¶ 0030 “The license verification module 110 is a module for processing a license verification request from the lv library 200, and is configured to include a license verifier 111, a license issuer 112, and an access token issuer 113”, ¶ 0031 “In order to process the license verification request of the lv library 200, the license verifier 111 verifies the license by checking whether there is license information on the resource corresponding to the license management database 130…requests the resource owner to authenticate the user and confirm the purchase details, and verifies the license through the result”, ¶¶ 0032-0034 “…in case authority is confirmed, the license identification number about the corresponding resources is given and the issuance of license or the access token is requested as the license issuer(112)
or the access token issuer(113)”, ¶¶ 0035, 0038, 0047 “ …As illustrated in fig. 4, the
License verification procedure of the web application includes a step of requesting
license verification from the lv server 100 in the web application installed in the user terminal, a step of checking purchase details in conjunction with the resource owner to verify the license, and a step of verifying the license through the purchase details by the lv server 100 and transmitting the result to the web application”},
or ii) the token issuer is a regulator and the commercial transaction comprises provision by the second party to the first party of regulated content or a regulated product or service regulated by the token issuer, or iii) the token issuer is a guardian or parole officer of the first party and the funds spent by the commercial transaction are funds to be spent only under control of the token issuer.
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 and in view of Jones to include the elements of JO. One would have been motivated to do so, in order to have a controlled license content distribution. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction, Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants and Jones discloses having a protected and secured client authentication input interface. JO is merely relied upon to illustrate the functionality of having a controlled license content distribution, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, providing a commercial fund transfer transaction using a blockchain between participants, and having a protected and secured client authentication input interface as well as having a controlled license content distribution, 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, and in view of Jones as well as JO, 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/JO.
With respect to claim 4, the combination of Tartan in view of Specogna, in view of Jones, and in view of JO 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, in view of Jones, and in view of JO 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 and in view of Jones to include the elements of JO. One would have been motivated to do so, in order to have a controlled license content distribution. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction, Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants and Jones discloses having a protected and secured client authentication input interface. JO is merely relied upon to illustrate the functionality of having a controlled license content distribution, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, providing a commercial fund transfer transaction using a blockchain between participants, and having a protected and secured client authentication input interface as well as having a controlled license content distribution, 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, and in view of Jones as well as JO, 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/JO.
With respect to claim 8, the combination of Tartan in view of Specogna, in view of Jones, and in view of JO 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 Specogna and in view of Jones to include the elements of JO. One would have been motivated to do so, in order to have a controlled license content distribution. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction, Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants and Jones discloses having a protected and secured client authentication input interface. JO is merely relied upon to illustrate the functionality of having a controlled license content distribution, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, providing a commercial fund transfer transaction using a blockchain between participants, and having a protected and secured client authentication input interface as well as having a controlled license content distribution, 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, and in view of Jones as well as JO, 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/JO.
With respect to claim 9, the combination of Tartan in view of Specogna, in view of Jones, and in view of JO teaches all the subject matter as disclosed in claim 8 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 Specogna and in view of Jones to include the elements of JO. One would have been motivated to do so, in order to have a controlled license content distribution. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction, Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants and Jones discloses having a protected and secured client authentication input interface. JO is merely relied upon to illustrate the functionality of having a controlled license content distribution, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, providing a commercial fund transfer transaction using a blockchain between participants, and having a protected and secured client authentication input interface as well as having a controlled license content distribution, 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, and in view of Jones as well as JO, 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/JO.
With respect to claim 10, the combination of Tartan in view of Specogna, in view of Jones, and in view of JO 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, in view of Jones, and in view of JO teaches all the subject matter as disclosed in claim 1 above.
Furthermore, JO discloses wherein a proof, used in the verification that the second party has passed the eligibility test has an expiry date {see at least ¶ 0035, “When the license verification control unit 114 requests the license verification control unit 114 to verify the validity of the license, the license validity verification unit 115 checks the validity of the license. in the case of the license issued by the license verification system, since the license may be issued by setting the validity period or the number of times of use, etc. to the license according to the license issuance policy, the license validity verification unit 115 checks the validity of the license, such as whether the use period of the license remains or whether the number of times of use has not been exceeded”, ¶ 0036}.
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 and in view of Jones to include the elements of JO. One would have been motivated to do so, in order to have a controlled license content distribution. Furthermore, Tartan discloses using a lock/unlock script in a blockchain transaction, Specogna discloses providing a commercial fund transfer transaction, using a blockchain between participants and Jones discloses having a protected and secured client authentication input interface. JO is merely relied upon to illustrate the functionality of having a controlled license content distribution, in the same or similar context of a commercial fund transfer. Because both using a lock/unlock script in a blockchain transaction, providing a commercial fund transfer transaction using a blockchain between participants, and having a protected and secured client authentication input interface as well as having a controlled license content distribution, 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, and in view of Jones as well as JO, 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/JO.
With respect to claim 12, the combination of Tartan in view of Specogna, in view of Jones, and in view of JO 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, in view of Jones, and in view of JO 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, in view of Jones, and in view of JO 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, in view of Jones, and in view of JO 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, in view of Jones, and in view of JO 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, in view of Jones, and in view of JO teaches all the subject matter as disclosed in claim 16 above.
Furthermore, Tartan, teaches wherein the second party uses the 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 the 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, in view of Jones, and in view of JO 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, in view of Jones, and in view of JO 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, in view of Jones, and in view of JO 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 the token issuer, 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”}.
Response to Arguments/Amendments
35 USC § 103
Applicant’s amendment/remarks filed on 05/20/2026 is hereby acknowledged,
and have been found persuasive by the Examiner. Examiner is introducing a new prior
art, JO et al., ((KR 20140191608 A) to teach the newly added conditional limitation “wherein the eligibility test comprises a test that the first party has been granted a license or permission to conduct the transaction with the second party, wherein either i) the token issuer is a content owner and the commercial transaction comprises provision by the second party to the first party of content licensed from the token issuer, or ii) the token issuer is a regulator and the commercial transaction comprises provision by the second party to the first party of regulated content or a regulated product or service regulated by the token issuer, or iii) the token issuer is a guardian or overseer of the first party and the funds spent by the commercial transaction are funds to be spent only under control of the token issuer” {see at least ¶¶ 0030-0035, 0038, 0047} as disclosed above.
Applicant further asserts that “In the Office Action, it appears that the examiner now acknowledges that Tartan does not disclose an authentication token indicating that a first party has passed an identity verification with a token issuer, nor including such a token in the output of a transaction, but instead relies on Specogna for these features (though this is different than argued in the first OA, and as the examiner still argues later on page 6, where the examiner has argued these features are disclosed by Tartan). The examiner has cited specifically on steps 816-826 of Fig. 8B; and paragraphs 130, 157-158 and 161-162 of Specogna. Paragraphs 130 &157 and Step 818 do mention something which Specogna calls an "authentication token". However, none of the cited steps or passages discloses placing an authentication token in the output of a transaction (whether a blockchain transaction or otherwise). In Secogna, the "authentication token" is something like a PIN which the user enters manually via a keypad (par 157). Tartan also does not disclose placing an12
authentication token in the output of a transaction. Therefore, there is a feature not taught in either of Tartan or Specogna.”
Examiner disagrees with this characterization, for example , the disclosure of Specogna in ¶¶ 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…” Emphasis added. The other authentication token is an authentication token that is not a PIN and functional for processing the commercial transaction, in combination with the outputs disclosed by Tartan’s transaction.
In addition, the newly added limitation of “wherein the eligibility test comprises a test that the first party has been granted a license or permission to conduct the transaction with the second party, wherein either i) the token issuer is a content owner and the commercial transaction comprises provision by the second party to the first party of content licensed from the token issuer, or ii) the token issuer is a regulator and the commercial transaction comprises provision by the second party to the first party of regulated content or a regulated product or service regulated by the token issuer, or iii) the token issuer is a guardian or overseer of the first party and the funds spent by the commercial transaction are funds to be spent only under control of the token issuer”. These limitations are optional limitations that are not allowed in a method claim, however, Examiner only need to teach one of these three options. And also, in this is not a method claim step in this wherein clause, so it doesn’t further the claimed method. Applicant is hereby advised to further amend these limitation to a proper method claim structure.
Therefore, the 103 rejection is hereby maintained.
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.
Conclusion
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 /EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
Prosecution Insights