DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This written action is responding to the amendment dated on 12/26/2025.
Claims 1, 9 and 16 have been amended, Claims 21-25 are canceled.
Claims 1-20 are submitted for examination.
Claims 1-20 are pending.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner’s Note
Examiner suggest the Applicant’s representative to contact the Examiner to move forward the prosecution. Examiner contact details are provided in the conclusion section.
Priority
This 371 application filed on January 10, 2024 claims priority of PCT application PCT/EP2022/065940 filed on June 13, 2022 and Foreign application GB2110097.9 filed on July 13, 2021.
Information Disclosure Statement
The following Information Disclosure Statements in the instant application submitted in compliance with the provisions of 37 CFR 1.97, and thus, have been fully considered:
IDS filed on 01 February 2024.
Response to Arguments
Applicant’s amendment, filed on December 26, 2025 has claims 1, 9 and 16 amended, claims 21-25 canceled and all other claims previously presented. Among the amended claims, claims 1, 9 and 16 are independent ones, and thus, the amendment necessitates a new ground of rejection.
Applicant’s remark, filed on December 26, 2025 on bottom of page 8 regarding, “Ying Chan does not disclose "generating, by the first user, a second public key based on: the first public key, a first message sent from the second user to the first user, and a signature for the first message generated by the second user"”, has been considered and found persuasive, however Applicant’s amendment necessitates a new ground of rejection accordingly newly cited art by Joveski et al. (US # 2020/0286047) teaches, “the system performs at least a portion of the method. The method can include one or more of: storing payment unit information; receiving a withdrawal request; selecting payment representations; calculating estimated fees; consolidating multi-payment transactions; generating an unsigned transaction based on the selected payment representations; sending at least one unsigned transaction. performing verification on the unsigned transaction (S550); receiving at least one signed transaction(S600); and sending at least one signed transaction to a cryptocurrency network (S700)”. (Fig. 2A, ¶60). “S500 operates to send the unsigned withdrawal transaction(s) to the user device. S500 functions to send the withdrawal transactions to the user device for signature, and optional verification (e.g., S550). In a preferred embodiment, the unsigned withdrawal transactions are transmitted off-chain, e.g., the transactions are sent to the user device outside of the blockchain. Alternatively, the unsigned withdrawal transactions are transmitted on-chain”. (¶123). Ying Chan teaches, “The locking script may cause the validating node executing the locking script to verify the source of the data (provided in an unlocking script which purports to unlock the locking script) using elliptic curve finite field arithmetic. More particularly, the locking script may be configured to, when executed, cause a node to perform elliptic curve finite field arithmetic based on the data and a public key of the determined data source, which is included, by the locking node, in the locking script. That is, the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script and based on data defined in the unlocking script. The modified public key is determined by performing an elliptic curve finite field arithmetic operation based on the public key for the determined data source, which is embedded in the locking script, and based on data provided in an unlocking script. The modified public key may also be determined using multiple operations (e.g., data×data×public key, etc.)”. (¶59). “The locking node may prepare a transaction input for a further blockchain transaction (which may be referred to as a second transaction or a second blockchain transaction) which spends the digital assets included as an output in the first transaction. That is, the transaction may include the UTXO associated with the first transaction as an input to the second transaction. The locking node may generate a signature based on the locking node's private key and may include that signature in the unlocking script of the second transaction”. (¶90). “The locking node may generate a signature and add it to a transaction, configure the transaction to allow another party to add inputs and outputs, and add a branch trigger to the transaction to trigger operation of a particular conditional branch of the locking script”. (¶92). Thus Joveski teaches a platform that performs a verification of an unsigned transaction and provides the unsigned transaction for signing with a digital signature. Ying Chan teaches, generating a modified public key (second public key) bases on the public key and a digital signature for a transaction. Thus a person having an ordinary skill in the art would combine the teachings of Joveski, with the teachings of Ying Chan to teach the limiation, “generating, by the first user, a second public key based on: the first public key, a first message sent from the second user to the first user, and a signature for the first message generated by the second user”. The motivation/suggestion for doing so would be to provide a non-custodial payment platform that enables cryptocurrency transfers.
Applicant further recites similar remarks as listed above for dependent claims, 7-8 and 15. Please see response for remarks in above paragraph 9 that clearly shows how the cited prior arts Ying Chan, Song, Joveski and Shrinivasan clearly teaches the claimed limitations.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 8-11 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Ying Chan (US PGPPUB. # US 2020/0186360, hereinafter “Chan”), and further in view of Song et al. (US PGPUB. # US 2019/0236602, hereinafter “Song”), and further in view of Joveski et al. (US PGPUB. # US 2020/0286047, hereinafter “Joveski”).
Referring to Claims 1, 9 and 16:
Regarding Claim 1, Chan teaches,
A computer-implemented method performed in a system comprising a first user with a first public key and a second user, the method comprising:
generating, by the first user, a second public key based on: the first public key, a first message [sent from the second user to the first user], and a signature for the first message generated by the second user; (¶10, “a) generating a modified public key based on the public key for the determined data source and based on data defined in the unlocking script”, ¶59, “the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script”, ¶64-¶66, Fig. 3, ¶90, “the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script”, ¶92, i.e. a modified public key (a second public key) is generated based on first public key and a signature for the message is generated. Examiner submits that node that generates a locking script is interpreted as first user)
providing, by the first user, the second public key to the second user; (Fig. 3, ¶93, “provide the second transaction prepared at operation 306 to another node for another party, such as the party, B”, i.e. first user provides the second public key to the second user)
determining, by the second user, a third public key based on: the first public key, a second message, and the signature for the second message generated by the second user; (¶15, “the validating node executing the locking script to generate the modified public key by performing an elliptic curve finite field arithmetic operation based on the data and the public key”, ¶60, “The modified private key is used by the determined data source to generate a signature which may be included in an unlocking script”, Fig. 5, ¶107, “the node to determine a modified public key for the determined data source”)
verifying, by the second user, whether the third public key is equal to the second public key; and when the third public key is equal to the second public key, determining that the first message is equal to the second message (¶73, “the OP_CHECKSIG operation code may be used. OP_CHECKSIG pops a public key and a signature from the stack and validates the signature for the transaction's hashed data. OP_CHECKSIG returns TRUE if the values match”, ¶107, ¶108, “If the data is determined to satisfy the data constraints and if the data is determined to be valid”, i.e. second node (user) verifies that the third public key is equal to second public key based on generated modified public key and the signature) and
[submitting a blockchain transaction comprising] the second public key (¶10, “a) generating a modified public key based on the public key for the determined data source and based on data defined in the unlocking script”, ¶59, “the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script”, ¶64-¶66, Fig. 3, ¶90, “the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script”, ¶92, i.e. a modified public key is interpreted as second public key) [to a blockchain network].
Chan does not teach explicitly,
[generating, by the first user, a second public key based on: the first public key, a first message] sent from the second user to the first user, [and a signature for the first message generated by the second user];
submitting a blockchain transaction comprising [the second] public key to a blockchain network.
However, Song teaches,
submitting a blockchain transaction comprising [the second] public key to a blockchain network. (Fig. 2, ¶61, “another device to perform processes of registering in the public blockchain network 200“, i.e. a transaction is recorded (submitted) to a blockchain. The transaction comprises a public key).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Song with the invention of Chan.
Chan teaches, a second user verifies a second public key and a signature provided by a first user. Song teaches, recording a transaction comprising a public key into a blockchain after validation. Therefore, it would have been obvious to record a transaction comprising a public key into a blockchain after validation of Song with a second user verifies a second public key and a signature provided by a first user of Chan to stop illegal copying or forgery of recorded data caused by hacking of the payment system.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Combination of Chan and Song doesn’t teach explicitly,
[generating, by the first user, a second public key based on: the first public key, a first message] sent from the second user to the first user, [and a signature for the first message generated by the second user];
However, Joveski teaches,
[generating, by the first user, a second public key based on: the first public key, a first message] sent from the second user to the first user, [and a signature for the first message generated by the second user]; (Fig. 2A, ¶60, “sending at least one unsigned transaction (S500)”, ¶123, i.e. a first message is sent from the second user to the first user).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Joveski with the invention of Chan in view of Song.
Chan in view of Song teaches, a second user verifies a second public key and a signature provided by a first user and recording a transaction comprising a public key into a blockchain after validation. Joveski teaches, a second user sending a first message to a first user to sign the first message. Therefore, it would have been obvious to have a second user sending a first message to a first user to sign the first message of Joveski into the teachings of Chan in view of Song to provide a non-custodial payment platform that enables cryptocurrency transfers.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 9, it is a claim for second user perspective and therefore Claim 9 is rejected with the same rationale as applied against Claim 1 above.
Regarding Claim 16, it is also a method claim and is rejected with the same rationale as applied against Claim 1 above.
Referring to Claims 2, 10 and 17:
Regarding Claim 2, rejection of Claim 1 is included and for the same motivation Chan teaches,
The method of claim 1, wherein prior to providing, by the first user, the second public key to the second user, the method comprises:
determining, by the first user, to generate the second public key using the received message as the first message and the received signature for the message as the signature for the first message generated by the second user. (¶10, “ a) generating a modified public key based on the public key for the determined data source and based on data defined in the unlocking script”, ¶59, “the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script”, ¶64-¶66, Fig. 3, ¶90, “the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script”, ¶92, i.e. a modified public key (a second public key) is generated based on first public key and a signature for the message is generated. Examiner submits that node that generates a locking script is interpreted as first user).
Chan does not teach explicitly,
receiving, by the first user, a message and a signature for the message generated by the second user;
verifying, by the first user, the signature for the message generated by the second user;
sending, from the first user to the second user, a positive response to the message; and
However Song teaches,
receiving, by the first user, a message and a signature for the message generated by the second user; (Fig. 3(S312), ¶65, “SignPrivA(RN) of the random nonce generated by signing the random nonce RN for reference with the private key of the currency issuer A is acquired at a step of S312”, i.e. a message with a signature is received by a first user)
verifying, by the first user, the signature for the message generated by the second user; (¶65, “he server 100 may determine whether the signature value SignPrivA(RN) of the random nonce is valid by using the public key of the currency issuer A”, i.e. signature is verified)
sending, from the first user to the second user, a positive response to the message; (Fig. 3, ¶66, “notifying the currency issuer A of a fact that a registration including an issuer-registering private transaction ID PrivTxid which represents location information of the issuer-registering transaction on the private blockchain network was successful”, i.e. a positive response is sent by the first user).
Regarding Claim 10 rejection of Claim 9 is included and Claim 10 is rejected with the same rationale as applied against Claim 2 above.
Regarding Claim 17 rejection of Claim 16 is included and Claim 17 is rejected with the same rationale as applied against Claim 2 above.
Referring to Claims 3, 11 and 18:
Regarding Claim 3, rejection of Claim 1 is included and for the same motivation Chan teaches,
The method of claim 1, wherein prior to providing, by the first user, the second public key to the second user, the method comprises:
determining, by the first user, to generate the second public key using the received further message and the received signature for the further message. (¶10, “ a) generating a modified public key based on the public key for the determined data source and based on data defined in the unlocking script”, ¶59, “the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script”, ¶64-¶66, Fig. 3, ¶90, “the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script”, ¶92, i.e. a modified public key (a second public key) is generated based on first public key and a signature for the message is generated. Examiner submits that node that generates a locking script is interpreted as first user).
Chan does not teach explicitly,
receiving, by the first user, a message and a signature for the message generated by the second user;
sending, from the first user to the second user, a negative response to the message;
generating, by the second user, a further message based on the negative response;
generating, by the second user, a signature for the further message; receiving, by the first user, the further message and the signature of the second user for the further message;
verifying, by the first user, the signature for the further message generated by the second user; sending, from the first user to the second user, a positive response to the further message;
However Song teaches,
receiving, by the first user, a message and a signature for the message generated by the second user; (Fig. 3, ¶61)
sending, from the first user to the second user, a negative response to the message; (Fig. 3, ¶63, “the server 100 may notify or support another device to notify the currency issuer A of a fact that a confirmation of the currency issuer failed, at a step of S321”, i.e. a negative response is sent)
generating, by the second user, a further message based on the negative response; (Fig. 3, ¶64-¶65).
generating, by the second user, a signature for the further message; receiving, by the first user, the further message and the signature of the second user for the further message; (Fig. 3(S312), ¶65, “SignPrivA(RN) of the random nonce generated by signing the random nonce RN for reference with the private key of the currency issuer A is acquired at a step of S312”, i.e. a message with a signature is received by a first user)
verifying, by the first user, the signature for the further message generated by the second user; sending, from the first user to the second user, a positive response to the further message; (¶65, “he server 100 may determine whether the signature value SignPrivA(RN) of the random nonce is valid by using the public key of the currency issuer A”, i.e. signature is verified).
Regarding Claim 11 rejection of Claim 9 is included and Claim 11 is rejected with the same rationale as applied against Claim 3 above.
Regarding Claim 18 rejection of Claim 16 is included and Claim 18 is rejected with the same rationale as applied against Claim 3 above.
Referring to Claims 8 and 15:
Regarding Claim 8 rejection of Claim 1 is included and for the same motivation combination of Chan and Song does not teach explicitly,
The method of claim 1, wherein the message comprises at least one of: an invoice; a contract; an agreement.
However, Joveski teaches,
The method of claim 1, wherein the message comprises at least one of: an invoice; a contract; an agreement. (¶41).
Regarding Claim 15 rejection of Claim 9 is included and Claim 15 is rejected with the same rationale as applied against Claim 8 above.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Ying Chan (US PGPPUB. # US 2020/0186360, hereinafter “Chan”), and further in view of Song et al. (US PGPUB. # US 2019/0236602, hereinafter “Song”), and further in view of Joveski et al. (US PGPUB. # US 2020/0286047, hereinafter “Joveski”), and further in view of Shrinivasan et al. (US PGPUB. # US 2021/0158411, hereinafter “Shrinivasan”).
Regarding Claim 7 rejection of Claim 1 is included and combination of Chan, Song and Joveski does not teach explicitly,
The method of claim 1, comprising: monitoring the blockchain network by the first user to check whether the transaction has been submitted on the blockchain network.
However, Shrinivasan teaches,
The method of claim 1, comprising: monitoring the blockchain network by the first user to check whether the transaction has been submitted on the blockchain network. (Fig. 4A, ¶82, “the processor 104 may monitor a delivery of a service to a first node from a second node based on a service contract and an order retrieved from a blockchain”).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Shrinivasan with the invention of Chan in view of Song and Joveski.
Chan in view of Song and Joveski teaches, a second user verifies a second public key and a signature provided by a first user and recording a transaction comprising a public key into a blockchain after validation and a second user sending a first message to a first user to sign the first message. Shrinivasan teaches, monitoring a blockchain by a first user that a transaction is submitted to a blockchain network. Therefore, it would have been obvious to monitor a blockchain by a first user that a transaction is submitted to a blockchain network of Shrinivasan into the teachings of Chan in view of Song and Joveski to process an invoice in a timely manner from generation to a payment remittance.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Claims 4-6, 12-14 and 19-20: Objected
Claims 4-6, 12-14 and 19-20 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Chan teaches, a method in accordance with an embodiment of the invention may comprise: i) including, by a node in a blockchain network, a locking script in a transaction (i.e., a blockchain transaction) to encumber (i.e., lock) a digital asset associated with the transaction (i.e., the blockchain transaction), the locking script including a public key for a determined data source and including instructions to cause a validating node executing the locking script to verify the source of data provided in an unlocking script by: a) generating a modified public key based on the public key for the determined data source and based on data defined in the unlocking script; and b) evaluating a signature (i.e., a cryptographic signature) in the unlocking script based on the modified public key; and ii) sending, by the node, the transaction (i.e., the blockchain transaction) to the blockchain network. (¶10). The locking script may cause the validating node executing the locking script to verify the source of the data (provided in an unlocking script which purports to unlock the locking script) using elliptic curve finite field arithmetic. More particularly, the locking script may be configured to, when executed, cause a node to perform elliptic curve finite field arithmetic based on the data and a public key of the determined data source, which is included, by the locking node, in the locking script. That is, the locking script may be configured to cause a node executing the locking script to generate a modified public key for the determined data source based on the public key for the determined data source defined in the locking script and based on data defined in the unlocking script. The modified public key is determined by performing an elliptic curve finite field arithmetic operation based on the public key for the determined data source, which is embedded in the locking script, and based on data provided in an unlocking script. The modified public key may also be determined using multiple operations (e.g., data×data×public key, etc.). (¶59). The locking node may prepare a transaction input for a further blockchain transaction (which may be referred to as a second transaction or a second blockchain transaction) which spends the digital assets included as an output in the first transaction. That is, the transaction may include the UTXO associated with the first transaction as an input to the second transaction. The locking node may generate a signature based on the locking node's private key and may include that signature in the unlocking script of the second transaction. The locking node may also include, as an input to the transaction, a branch trigger which is used to trigger operation of a specific one of the conditional branches in the locking script. For example, the example locking script described above includes two conditional branches—a first conditional branch allows another party, B, to claim the digital assets involved in the first transaction and a second conditional branch allows the locking node to reclaim such digital assets if they are not otherwise claimed by B within a specified time period. In order to cause the unlocking script of the second transaction to trigger the first branch rather than the second, the locking node may include a “1” as an input to the transaction so that OP_IF evaluates to TRUE causing the first branch to be executed. (Fig. 3, ¶90). The locking node may (at operation 308) provide the second transaction prepared at operation 306 to another node for another party, such as the party, B, or to the determined data source, C. (¶93). In order to unlock the locking script, the determined data source must obtain a modified private key by performing a finite field arithmetic operation based on the data source's private key and the data. More specifically, the operation(s) that are performed on the private key corresponds to the operation(s) that the locking script is configured to perform on the public key. As with the public key, multiple operations may be performed on the private key to obtain the modified private key (e.g., data x data x private key, etc.). The modified private key is used by the determined data source to generate a signature which may be included in an unlocking script. This signature may be referred to herein as a signature from a modified private key. (¶60). Thus, the locking script that is prepared at operation 302 of the method 300 may be configured to cause a validating node executing the locking script to check whether data provided in a corresponding unlocking script has been provided by a determined data source by obtaining a modified public key for the data source using the techniques described above. The locking script may be configured to cause the validating node to then evaluate a signature from a modified private key (i.e., a signature that is generated from a private key that has been modified based on the data). More particularly, a signature checking operation code may be included in the locking script which checks whether the signature from the modified private key corresponds to the modified public key and is, therefore, a valid signature. By way of example, the OP_CHECKSIG operation code may be used. OP_CHECKSIG pops a public key and a signature from the stack and validates the signature for the transaction's hashed data. OP_CHECKSIG returns TRUE if the values match. Thus, the instructions in the locking script that configure the validating node to evaluate the signature in the unlocking script based on the modified public key may be configured to cause the validating node to invalidate a transaction that includes an unlocking script when the signature contained in that unlocking script has not been generated using a modified private key associated with the determined data source. That is, the transaction containing the purported unlocking script is invalidated by the validating node if the signature is not generated with a modified private key that was generated by the determined data source based on a private key for the determined data source and based on the data. (¶73). The validating node evaluates the source of the data. More particularly, the locking script executed by the validating node causes the node to determine a modified public key for the determined data source. The modified public key is determined by performing an elliptic curve finite field arithmetic operation on the public key for the determined data source which is embedded in the locking script and also based on data provided in an unlocking script. Then a signature checking function is called to determine whether the modified public key corresponds to a signature generated based on a modified private key. This operation is described in greater detail above in the description of the locking script. The signature is provided in the unlocking script. If the signature is determined to invalid, then the validating node determines, at operation 504, that the unlocking script is not a valid solution to the locking script. f the data is determined to satisfy the data constraints and if the data is determined to be valid (i.e. if it is determined that it has been generated by or provided by the determined data source without subsequent tampering), then the transaction may be determined to be valid at operation 508 (provided any other possible requirements of the locking script are also satisfied). The transaction may then be mined onto the blockchain. (¶107-¶108).
Song teaches, at least one of the currency-issuing transaction TrxA and the currency issuer A is determined as valid, the server 100 may perform or support another device to perform processes of registering in the public blockchain network 200 the currency-issuing transaction TrxA including (i) the information on the currency receiver, (ii) the issued amount of the currency, (iii) the public key of the currency issuer, and (iv) the signature value of the currency issuer, or the function value function(TrxA) of the currency-issuing transaction TrxA and acquiring the currency-issuing public transaction ID PubTxid representing location information of the currency-issuing transaction TrxA or its function value function(TrxA) on the public blockchain network 200. Then, the server 100 may provide or support another device to provide the currency-issuing public transaction ID PubTxid to at least part of the currency issuer A and the currency receiver B. (¶61). If a request for registration of the currency issuer using the public key PubA thereof is acquired at a step of S300, the server 100 may perform or support another device to perform processes of determining whether the currency issuer A is valid, and if the currency issuer A is determined as valid at a step of S310, transmitting a random nonce RN for reference to the currency issuer A at a step of S311. If the currency issuer A is determined as invalid at a step of S320, for example, if the currency issuer is an illegal issuer, the server 100 may notify or support another device to notify the currency issuer A of a fact that a confirmation of the currency issuer failed, at a step of S321. However, a way of determining whether the currency issuer A is valid is not limited thereto, for example, a time stamp may be used to determine whether the currency issuer A is valid. For reference, the random nonce is used to determine whether the currency issuer is valid and its detail is described as below with an example. On condition that the currency issuer A has created the private key PrivA and the public key PubA using a user device, if the public key PubA is transmitted to the server 100 for registering the currency issuer as an issuer of the currency, the server 100 may determine whether the currency issuer A of the acquired public key is valid. Herein, a Public Key Infrastructure based certificate, or identification information on the currency issuer A may be used to determine whether the currency issuer A is valid, but the scope of the present disclosure is not limited thereto. As one example, the currency issuer may be confirmed by a public key certificate based on the PKI, i.e., the Public Key Infrastructure, an OPSign certificate, or the identification information that can confirm an identity of a person, a bank, a group, or an organization, like an SSN, a passport, the Employer Identification Number, the Corporation Registration Number, the Business Registration Number, etc. Thereafter, if a signature value SignPrivA(RN) of the random nonce generated by signing the random nonce RN for reference with the private key of the currency issuer A is acquired at a step of S312, the server 100 may determine whether the signature value SignPrivA(RN) of the random nonce is valid by using the public key of the currency issuer A. That is, the server 100 may extract the random nonce RN for comparison from the signature value SignPrivA(RN) of the random nonce by using the public key of the currency issuer, and may compare the extracted random nonce for comparison and the random nonce for reference transmitted to the currency issuer, to thereby determine the signature value SignPrivA(RN) as valid if the random nonce for comparison and the random nonce for reference are identical. (¶63-¶65).
Shrinivasan teaches, with reference to FIG. 4A, at block 412, the processor 104 may monitor a delivery of a service to a first node from a second node based on a service contract and an order retrieved from a blockchain. At block 414, the processor 104 may determine an incremental charge for a partial delivery of the service based on the monitored delivery. At block 416, the processor 104 may execute a smart contract to: issue the incremental charge for the partial delivery of the service and, responsive to a resolution of a dispute raised for the incremental charge, add the incremental charge to an incremental invoice. (Fig. 4A, ¶82).
However, none of the art teaches recited claim limitations.
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 is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Li et al. (US # 2021/0304201) discloses, a transaction verification method is provided, including: obtaining transaction information, and generating verification identification information according to the transaction information; storing the verification identification information as a leaf node in a verification block having a tree structure; obtaining root node information of the verification block and a verification path of the verification identification information in the verification block; and sending the verification identification information, the root node information, and the verification path to a first transaction party involved in the transaction information, so that the first transaction party verifies the transaction information.
Yang (US # 2021/0049602) discloses, method includes: receiving, by a service logic execution module of a designated member node, a transaction request comprising a paying user identifier of a paying user, a designated resource amount, and a receiving user identifier of a receiving user, the paying user paying the designated resource amount, and the receiving user receiving the designated resource amount, wherein the designated member node is one of a plurality of member nodes of a blockchain network; prior to the blockchain network performing consensus verification on the transaction request, performing, by the service logic execution module, transaction feasibility verification off the blockchain network according to the transaction request; sending, by the service logic execution module, an account balance modification instruction to a database management module of the designated member node in response to the transaction feasibility verification being successful.
Wright et al. (WO # 2020/110025) discloses, improved methods and systems for processing, storing, sharing, retrieving, writing and accessing data (content) on a blockchain e.g. Bitcoin. The invention may form part of a protocol for storing, searching and accessing the data. In particular, improved efficiency and also enhanced access control permissions are provided. An embodiment of the disclosure comprises the step of processing at least one blockchain transaction (Tx) comprising: a protocol flag; a discretionary public key (DPK); and a discretionary transaction ID (DTxID). These are discretionary in the sense that they are not required as part of the underlying blockchain protocol but in accordance with the present invention. This combination of features enables portions of data to be identified, retrieved and shared on a blockchain, and also to be linked/associated with one another when provided in a plurality of transactions. It enables a graph or tree-like structure to be constructed, which reflects the hierarchical relationships between portions of data, facilitating their processing, searching and sharing.
Hoshizuki (US # 2020/0098042) discloses, a trading apparatus includes a storage unit and a processor. The processor generates a first electronic signature to be included in second trading information that is used for a trade of delivering second data to a trading partner after first trading information to be used for a trade of delivering first data to the user is published on a first network. The processor generates a second electronic signature to be included in fourth trading information that is used for a trade of receiving the first data from the trading partner using information included in the first trading information. The processor stores the second electronic signature in the storage unit. The processor creates the fourth trading information using the second electronic signature stored in the storage unit after third trading information that is used for a trade of receiving the second data from the user is published on a second network.
Wright, Craig Seven (WO # 2019/220271) discloses, a computer-implemented security method is provided. The method may be implemented on one or more blockchains, such as the Bitcoin Cash blockchain. The method comprises the steps of: converting a first secret value (S2) accessible to a first user into a first derived public key (P2), and transmitting the first derived public key to the second user; converting a second secret value (S1) accessible to a second user into a second derived public key (P1), and transmitting the second derived public key to the first user; calculating a third derived public key (P_AE) based at least in part on the first derived public key; calculating a fourth derived public key (P_BE) based at least in part on the second derived public key; applying a one-way function to each of the first secret value and the second secret value to create respective first and second veiled secret values (H(S2), H(S1)); communicating the first veiled secret value from a first user to a second user and the second veiled secret value from the second user to the first user; and constructing first and second blockchain transactions (tx1, tx2) each comprising the first veiled secret value and the second veiled secret value, the transactions arranged to be unlockable to transfer control of a respective first or second resource upon provision of both the first secret value and the second secret value to the respective transaction, wherein unlocking of the first blockchain transaction causes the first secret value to be revealed to the second user, and unlocking of the second blockchain transaction causes the second secret value to be revealed to the first user, and wherein revelation of the first secret value to the second user enables the second user to calculate a second private key (S2) corresponding to the third derived public key, and revelation of the second secret value to the first user enables the first user to calculate a first private key (S1) corresponding to the fourth derived public key.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARSHAN I DHRUV whose telephone number is (571)272-4316. The examiner can normally be reached M-F 9:00 AM-5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached at 571-272-8878. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DARSHAN I DHRUV/Primary Examiner, Art Unit 2498