Acknowledgements
This communication is in response to applicant’s response filed on 12/19/2025.
Claims 1-10 are pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Regarding the applicant’s arguments:
Regarding applicant’s arguments, see pgs. 1-6, filed 04/08/2026, with respect to the rejections of claims 1 and 8 under Claim Rejections - 35 USC § 102 that Yu does not teach “a data logging module…configured to store the received transaction details in an off-chain database associated with the source participating node,” “an encryptor module…configured to encrypt the received transaction details,” “data sharing module…configured to receive a private call from the destination participating node,” and “data sharing module…configured to validate the identity of the destination participating node” have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Pan (US 20210150521) in view of Arora (US 20210117938).
Priority
Applicant's claim for the benefit of PCT Application No. PCT/IB2022/062196 filed on 12/14/2022 is acknowledged. Applicant's claim for the benefit of Republic of India Application No. IN202121059064 filed on 12/17/2021 is acknowledged.
Claim Objections
Claim 7 is 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.
Claim Rejections - 35 USC § 103
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.
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-4, and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Pan (US 20210150521) in view of Arora (US 20210117938).
Regarding Claims 1 and 8, Pan teaches a data logging module (102), of an operative source participating node, configured to receive a request to conduct a transaction with an operative destination participating node, the transaction request comprising transaction details (Paragraphs 0082 and 0026-0027 teach a receiving unit, configured to receive a first message sent by the blockchain user, where the first message includes privacy-unprotected first data information; Step 102: receive a first message sent by the blockchain user, where the first message includes privacy-unprotected first data information; the first message is received by the node device of the trusted user that communicates with the blockchain user through an off-chain channel; the off-chain channel means that a transaction is not sent to the distributed database of the blockchain, but a network communication method such as private point-to-point communication or a method using other relay nodes; it is worthwhile to note that the first message can have a same data content format as that of the transaction published to the blockchain, and is referred to here as “message” instead of “transaction” because the first message is not sent to the distributed database of the blockchain, but sent through the off-chain channel; the privacy-unprotected first data information means that the first data information is the original whose privacy is not protected or encrypted), said data logging module (102) further configured to store the received transaction details in an off-chain database (30) associated with the source participating node (Paragraphs 0084 and 0030-0031 teach a storage unit, configured to store the first data information in a local database of the node device of the trusted user; Step 106: store the first data information in a local database of the node device of the trusted user; the local database of the node device of the trusted user is different from the distributed database of the node device of the trusted user on the blockchain; the first data information stored in the local database of the node device cannot be obtained by another node device on the blockchain, thereby ensuring privacy of the first data information); an encryptor module (104), of the source participating node, configured to receive the transaction details from said data logging module (102) and further configured to encrypt the received transaction details and generate a unique identifier corresponding to the transaction details (Paragraphs 0083 and 0028-0029 teach a conversion unit, configured to convert the privacy-unprotected first data information into privacy-protected second data information; Step 104: convert the privacy-unprotected first data information into privacy-protected second data information; the privacy-protected second data information is converted from the privacy-unprotected first data information; the conversion process can be encrypting the first data information to obtain the second data information; in some illustrated implementations, the second data information can be a hash digest of the first data information to ensure that the second data information can uniquely correspond to the first data information); a broadcasting module (106), of the source participating node, configured to maintain a ledger, said broadcasting module (106) configured to cooperate with said encryptor module (104) to store the unique identifier in said ledger (58), and broadcast the unique identifier to all the participating nodes in the network (100) (Paragraphs 0084 and 0033 teach a sending unit, configured to send a second transaction to the blockchain, where the second transaction includes the second data information, so that the second transaction is recorded in the distributed database of the blockchain after being verified; Step 108: send a second transaction to the blockchain, where the second transaction includes the second data information, so that the second transaction is recorded in the distributed database of the blockchain after being verified by a node device having consensus authority on the blockchain); and a data sharing module (108), of the source participating node, configured to transmit transaction details to a trusted node, said data sharing module (108) configured to validate the identity of the trusted node and share the transaction details with the trusted node upon successful validation (Paragraphs 0090-0092, 0034, 0041, 0043 teach the apparatus further includes: an obtaining unit, configured to obtain the trust setting transaction from the distributed database of the blockchain; a determining unit, configured to determine other trusted users trusted by the blockchain user based on the trust setting transaction; and a transmission unit, configured to transmit, in an off-chain method, the privacy-unprotected first data information and the privacy-protected second data information to node devices of the other trusted users trusted by the blockchain user, so that the first data information is stored in the local databases of the node devices of the other trusted users after it is verified that the first data information is converted from the second data information; any node device on the blockchain can obtain the second data information in the second transaction by accessing the distributed database of the blockchain; because the second data information is in a privacy protection state, except the blockchain user sending the first message and the trusted user trusted by the blockchain user, no other user on the blockchain can obtain the first data information corresponding to the second data information, thereby effectively protecting privacy of the first data information; verification of the second transaction can usually include verification of a data content format of the second transaction, verification of all or a part of content of the second transaction, or verification of a digital signature included in the second transaction, etc.; to ensure that the node device of the trusted user sending the second transaction belongs to the trusted user set by the blockchain user, the node device on the blockchain should verify whether an identifier of the trusted user is included in the trust setting transaction initiated by the blockchain user; if yes, it indicates that an initiating user of the second transaction is a valid initiating user; the blockchain user can set a plurality of trusted users when setting the trusted user; the blockchain user can select a trusted user from the plurality of trusted users and send the first message to the trusted user; correspondingly, in addition to completing the blockchain-based privacy transaction method described in steps 102 to 108 in the previous embodiments, the trusted user should further transmit the first message sent by the blockchain user to node devices of other trusted users, so that the other trusted users store the privacy-unprotected first data information included in the first message in local databases of the node devices of the other trusted users).
However, Pan does not explicitly teach and a data sharing module (108) configured to receive a private call from the destination participating node, wherein the private call is a request to access the complete transaction details, said data sharing module (108) configured to validate the identity of the destination participating node and share the transaction details with the destination participating node upon successful validation.
Arora from same or similar field of endeavor teaches a data sharing module (108), of the source participating node, configured to receive a private call from the destination participating node, wherein the private call is a request to access the complete transaction details, said data sharing module (108) configured to validate the identity of the destination participating node and share the transaction details with the destination participating node upon successful validation (Paragraphs 0041 and 0043 teach the entity computing device may provide its recipient public key to the sender computing device using a suitable communication network and method; the sender computing device may receive the recipient public key; the sender computing device may generate a blockchain data value submission for the transfer of encrypted data to the entity computing device; the encrypted data may be encrypted using the recipient public key received from the entity computing device; the blockchain data value may be included in a new block that is generated by the generation module; the block may be thereby included in the blockchain and available for reading by entities; the entity computing device may access the blockchain and identify its blockchain wallet as the recipient of the new blockchain data value, based on the recipient address included therein; the entity computing device may decrypt the encrypted data included in the new blockchain data value using its private key).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Pan to incorporate the teachings of Arora for a data sharing module (108), of the source participating node, to be configured to receive a private call from the destination participating node, wherein the private call is a request to access the complete transaction details, said data sharing module (108) configured to validate the identity of the destination participating node and share the transaction details with the destination participating node upon successful validation.
There is motivation to combine Arora into Pan because this effectively limits the spread of the information at the behest of the user, with use of a blockchain, which is a decentralized, and automated system, ensuring that the user retains complete control over how and when their information is spread. Because of this limitation on sharing and the use of encryption, an entity that receives PII cannot continue to share the information without revealing their sharing of the information to the user or potentially sharing their own private key. As such, not only do users have more control, there is also more incentive for recipients to honor their commitment to keeping the personal information secure (Arora Paragraph 0004). The methods and systems discussed herein enable the sender to have greater control and security on the transfer of information, which may include any personal information or other sensitive data. The use of the blockchain and transfer tokens ensures that only transfers that are properly authorized may be honored, and provides the sender with the ability to control where the data is being transferred and how many times new transfers can occur. As a result, there is greater control and convenience for senders without the need for improvements or modifications to sender computing devices or recipient computing devices beyond the use of cryptographic public keys and communications with blockchain nodes (Arora Paragraph 0029).
Regarding Claim 1, Pan teaches a system (100) for providing data privacy in a blockchain network (20), the blockchain network (20) comprising a plurality of participating nodes and a clearing house node (Paragraphs 0081, 0036, and 0040 teach FIG. 5 is a blockchain-based privacy transaction apparatus, applied to a node device of a trusted user; the trusted user is determined by a trust setting transaction stored in a distributed database of the blockchain, and the trust setting transaction includes identifiers of all trusted users corresponding to a blockchain user; a node device having bookkeeping authority on the blockchain adds the second transaction to a candidate block; the node device having bookkeeping authority is a node device having authority to generate the candidate block, and can include a node device having users with a relatively high credit and other node devices on the blockchain; the consensus node device having bookkeeping authority can be determined from the node devices having bookkeeping authority on the candidate block based on the consensus protocol of the blockchain).
Regarding Claim 8, Pan teaches a method for providing data privacy in a blockchain network (20), the blockchain network (20) comprising a plurality of participating nodes and a clearing house destination participating node (Paragraph 0022 teaches as shown in FIG. 1, an example embodiment of the present specification provides a blockchain-based privacy transaction method).
Regarding Claim 3, the combination of Pan and Arora teaches all the limitations of claim 1 above; and Pan further teaches wherein the transaction details include a plurality of data fields, the data fields comprise at least one of a transaction identifier, a transaction amount, payment details of a payer of the transaction, and payment details of a payee of the transaction (Paragraph 0072 teaches the node device of user A sends, to the node device of trusted user SA trusted by both user A and user B, a transaction message Txab indicating a transfer from user A to user B; the transaction message Txab includes account identifiers (account addresses or public keys) of user A and user B, a transfer amount 10, and a digital signature Sign (10) made by user A for the transfer amount 10).
Regarding Claim 4, the combination of Pan and Arora teaches all the limitations of claim 3 above; and Pan further teaches wherein the payment details of the payer include a payment address containing an indicator of a financial entity associated with the payer and the payment details of the payee include a payment address containing an indicator of the financial entity associated with the payee (Paragraph 0072 teaches the transaction message Txab includes account identifiers (account addresses or public keys) of user A and user B, a transfer amount 10, and a digital signature Sign (10) made by user A for the transfer amount 10).
Claims 2, 5, and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Pan (US 20210150521) in view of Arora (US 20210117938) in further view of Grendon (US 20190188704).
Regarding Claims 2 and 9, the combination of Pan and Arora teaches all the limitations of claims 1 and 8 above; however, the combination does not explicitly teach wherein said unique identifier comprises a first HASH of the transaction details encrypted using a pre-stored public key of destination participating node.
Grendon from same or similar field of endeavor teaches wherein said unique identifier comprises a first HASH of the transaction details encrypted using a pre-stored public key of destination participating node (Paragraphs 0023, 0025, and 0051 teach a digital token may be a data value that is unique to the trust-based transaction being conducted between the sender and recipient; the digital token may be a hash value generated via hashing data with a suitable hashing algorithm; the sender's computing device may encrypt the digital token with the recipient's public key before providing the encrypted token to the recipient; the generation module may generate a secure token, also referred to herein as a digital token; the generation module may use any suitable method for the generation of the secure token; in cases where the transaction request includes a password or other security value, the secure token may use such a value in the generation thereof; the secure token may be encrypted prior to transmission to the recipient).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Pan and Arora to incorporate the teachings of Grendon for said unique identifier to comprise a first HASH of the transaction details encrypted using a pre-stored public key of destination participating node.
There is motivation to combine Grendon into the combination of Pan and Arora because the system provides a description of systems and methods for processing trust-based transactions using a blockchain. When a new trust-based transaction is started, a digital token is generated where the token or data used to generate the token is stored in the blockchain. The digital token, or data used to generate the token, is encrypted and exchanged between customers and brokers, where only the second customer and second broker, as authorized parties, are able to decrypt and generate the correct digital token. The digital token is delivered to the second broker by the second party, which compares the delivered token with its own digital token, as well as comparing it with the token on or based on the blockchain, to ensure that the intended recipient is the only one able to receive the transferred money from the second broker. Thus, the trust-based system is maintained where the use of a digital token and the blockchain provides for significantly greater security (Grendon Paragraph 0005). The use of a blockchain and digital tokens may ensure that only an authorized recipient may be able to receive funds from a recipient broker. The blockchain provides for immutable data storage to ensure that a digital token cannot be tampered with or adjusted, or to falsify a transaction amount or other data, while at the same time providing for an immutable and accurate record of all transfers being done between brokers. This can enable brokers to retain the honor system that has served trust-based transaction systems for centuries, while providing for more accurate accounting to ensure greater accuracy and convenience. Thus, the systems and methods discussed herein provide for greater security and convenience in trust-based transactions while retaining all of the benefits of trust-based systems through the inclusion of a blockchain and specifically configured systems configured to perform the functions discussed herein (Grendon Paragraph 0034).
Regarding Claim 5, the combination of Pan and Arora teaches all the limitations of claim 1 above; however, the combination does not explicitly teach wherein said data sharing module (108) validates the identity of the participating destination node by checking if the participating destination node was a part of the conducted transaction.
Grendon from same or similar field of endeavor teaches wherein said data sharing module (108) validates the identity of the participating destination node by checking if the participating destination node was a part of the conducted transaction (Paragraphs 0032 and 0043 teach the computing device of the recipient may be associated with a device identifier, which may be supplied to the sender (e.g., or the computing device thereof) and supplied to the processing server and included in the transaction data value, where the recipient's computing device may provide such data to the recipient broker system for verification; the data identification module may be configured to, for instance, identify blockchain addresses for recipient broker systems, such as may be identified based on a supplied public key or other data).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Pan and Arora to incorporate the teachings of Grendon for said data sharing module (108) to validate the identity of the participating destination node by checking if the participating destination node was a part of the conducted transaction.
There is motivation to combine Grendon into the combination of Pan and Arora because of the same reasons listed above for claim 2.
Claims 6 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Pan (US 20210150521) in view of Arora (US 20210117938) in further view of Grendon (US 20190188704) in further view of Desmarais (US 20210083872).
Regarding Claims 6 and 10, the combination of Pan and Arora teaches all the limitations of claims 2 and 8 above; however, the combination does not explicitly teach wherein the destination participating node comprises: i. a decrypting module configured to decrypt the unique identifier using a private key corresponding to said public key to obtain the first HASH.
Grendon from same or similar field of endeavor teaches wherein the destination participating node comprises: i. a decrypting module configured to decrypt the unique identifier using a private key corresponding to said public key to obtain the first HASH (Paragraph 0025 teaches the recipient's computing device may possess data necessary for use in decrypting the digital token, to prohibit use of the digital token without having the proper data; for example, the recipient's computing device may generate a cryptographic key pair consisting of a private key and public key, and may provide the public key to the sender's computing device; the sender's computing device may encrypt the digital token with the recipient's public key before providing the encrypted token to the recipient; the recipient's computing device may decrypt the token using the private key, ensuring that only the recipient's computing device is capable of obtaining the decrypted digital token (e.g., or data used for the generation of the digital token)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Pan and Arora to incorporate the teachings of Grendon for the destination participating node to comprise: i. a decrypting module configured to decrypt the unique identifier using a private key corresponding to said public key to obtain the first HASH.
There is motivation to combine Grendon into the combination of Pan and Arora because of the same reasons listed above for claim 2.
However, the combination of Pan, Arora, and Grendon does not explicitly teach ii. a HASH generator configured to generate a second HASH corresponding to the complete transaction details received from the source participating node; and iii. a comparator configured to compare the first HASH with the second HASH to verify the authenticity of the transaction details received from the source participating node.
Desmarais from same or similar field of endeavor teaches ii. a HASH generator configured to generate a second HASH corresponding to the complete transaction details received from the source participating node (Paragraph 0225 teaches a hashing module of the verification module applies the same hashing function/algorithm as the content signing module to the transaction data to generate a second hash value); and iii. a comparator configured to compare the first HASH with the second HASH to verify the authenticity of the transaction details received from the source participating node (Paragraph 0226 teaches the verification module compares the first hash value (from the decryption module) to the second hash value (from the hashing module); if the hash values are the same, the verification module verifies the transaction; if the hash values differ, the verification module does not verify the transaction).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Pan, Arora, and Grendon to incorporate the teachings of Desmarais for ii. a HASH generator to be configured to generate a second HASH corresponding to the complete transaction details received from the source participating node; and iii. a comparator to be configured to compare the first HASH with the second HASH to verify the authenticity of the transaction details received from the source participating node.
There is motivation to combine Desmarais into the combination of Pan, Arora, and Grendon because failure to verify the transaction may result in the verification module (or other module) generating a message that is sent to other entities in the system parties, alerting them that there was an unsuccessful validation of the transaction. In an embodiment, each device in the system includes a verification module (Desmarais Paragraph 0226).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shockley et al. (US 20200228506) teaches a “zero-knowledge” data management network. Users are able to share verifiable proof of data and/or identity information, and businesses are able to request, consume, and act on the data—all without a data storage server or those businesses ever seeing or having access to the raw sensitive information (where server-stored data is viewable only by the intended recipients, which may even be selected after storage). In one embodiment, source data is encrypted with a source encryption key (e.g., source public key), with a rekeying key being an encrypting combination of a source decryption key (e.g., source private key) and a recipient's public key. Without being able to decrypt the data, the storage server can use the rekeying key to re-encrypt the source data with the recipient's public key, to then be decrypted only by the corresponding recipient using its private key, accordingly.
Hernandez Acosta et al. (US 20210166222) teaches a blockchain arrangement configured to simultaneously distribute at least one public transaction and/or a restricted transaction, wherein the disposition includes a plurality of participating nodes and a plurality of validator nodes connected by a telecommunications network; wherein a proponent participant node is configured to send to all the validator nodes the contents of a tx information transaction record, together with the identifier of a particular preconfigured privacy group; to provide the capabilities of anonymity and privacy to the blockchain system that distributes blocks of information transaction records; such that at least one recipient participating node, connected to a blockchain network, is able to decrypt, read, and execute the information transaction record blocks encrypted by the validator or mining nodes of the blockchain network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of 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.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699
Prosecution Insights