Acknowledgements
This communication is in response to applicant’s response filed on 12/19/2025.
Claim 9 has been amended.
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. 6-10, filed 12/19/2025, with respect to Claim Interpretation - 35 USC § 112(f) of claims 1-10 that the term “module” does not automatically invoke 112(f) because it denotes sufficient structure, examiner respectfully agrees the term “module” does not invoke the 112(f) interpretation because it denotes sufficient structure to one of ordinary skill in the art. In the present case, each "module" is structurally tied to hardware and software elements disclosed in the specification. Thus, the Claim Interpretation - 35 USC § 112(f) has been withdrawn. In addition the Claim Rejections - 35 USC § 112 have been withdrawn due to the withdrawal of the Claim Interpretation - 35 USC § 112(f).
Regarding applicant’s arguments, see pgs. 10-17, filed 12/19/2025, with respect to the rejections of claims 1-10 under Claim Rejections - 35 USC § 103 that the combination of Blumberg in view of Kilgore does not teach a source participating node that (i) locally stores full transaction details in an off-chain database associated with the source node, (ii) periodically compresses the off-chain records, (iii) generates a first HASH of the transaction details and encrypts that HASH using the destination node's public key, (iv) publishes only the encrypted HASH or unique identifier on-chain via a broadcasting module co-operating with an encryptor module, and (v) responds to private calls by authenticated destination nodes to selectively share and authenticate the off-chain transaction details using the decrypting/HASH generator/comparator flow claimed 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 Yu (WO 2021154157).
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 Rejections - 35 USC § 102(a)(1)
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 5-6, 8-10 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Yu (WO 2021154157).
Regarding Claims 1 and 8, Yu 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, 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 0057, 0061, and 0083 teach each data transfer event between a pair of client devices (e.g. 104A and 104B) in the system is intermediated by the client devices and the off-chain storage causing one or more data transaction messages to be published to the blockchain via the respective BMNs with which they are in communication; such data transaction messages do not include the actual data that is to be shared between the client devices; instead, the actual data is uploaded by one client device, for example 104A, to off-chain storage; the off-chain storage is also connected to a BMN; all the shared data are encrypted and stored in the cloud; the sender may initiate the transaction, and this may comprise performing one or more off-chain operations; for example, in a data upload transaction, the sender is client device 104A wishing to upload a data object, and the recipient is the off-chain storage to which the data object is to be uploaded; the client device 104A encrypts the data object (for example, according to an attribute-based encryption algorithm) and uploading the encrypted data object to the off-chain storage); 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 0070 and 0083 teach a transaction ID is the first field; the transaction ID could be a transaction hash ID which is generated by hashing transaction information; the data identifier for the data object is also generated by the sender at this point so that it can be inserted in the transaction sent to the blockchain (and subsequently used by the cloud service to match against what is uploaded by the sender, and against requests made by other parties)); 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 0056-0057 and 0084 teach the blockchain nodes comprise a plurality of Broadcast and Monitor Nodes; a BMN is able to generate and broadcast transactions on the blockchain; all parties that wish to share data with others (e.g., Company A and Company B in Figure 1), as well as the off-chain storage, are connected to one of the BMNs; each BMN 106A-D may store a list of identifiers of users that are permitted to access the blockchain via BMN 106A-D, such that any transaction in the blockchain that is associated with an identifier of one of the client devices 104A may be detected and forwarded to the corresponding client device 104A for processing and a data upload transaction is published to the blockchain; the data upload transaction contains (among other things) only a hash of the actual data such that a downloader of the actual data from the off-chain storage can verify that the data have not been tampered with; the sender may sign the transaction; the data upload transaction comprises the fields shown in Figure 3, including a transaction ID, and a previous transaction ID of the data owner (if any); the transaction type is "data upload transaction", and the action info comprises a hash of the (unencrypted) data object; note that the transaction does not include the data object (either in encrypted or plaintext form) itself, but only the hash of the data object. The hash of the plaintext data ensures the integrity and authenticity of the data kept in the cloud); 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 0058 teaches once data has been uploaded to the off-chain storage, other client devices in the system may request access to it; for example, a data access request transaction may be published to the blockchain by another client device 104B, via the BMN 106B to which client device 104B is connected; this is detected by the BMN 106A connected to client device 104A (which is the data owner and the entity that uploaded the data to off-chain storage 102) and passed to an access controller 120A in communication with client device 104A; if access is approved, for example based on an access control policy, then a data access authorization transaction is published to the blockchain; this is detected by the BMN 106D connected to off-chain storage; off-chain storage then generates and publishes a data access confirmation transaction to the blockchain, via the BMN 106D; this is detected by the BMN 106B connected to client device 104B; client device 104B may then access the data stored at off-chain storage, and send the completed transaction to its BMN 106B for recording in the blockchain).
Regarding Claim 1, Yu 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 (Paragraph 0052 teaches Figure 1 shows an example architecture of a system 100 for data exchange via a blockchain network 101; the blockchain network 101 comprises a plurality of nodes 106A, 106B, 106C, 106D, 108, and 110, the functions of which will be described in further detail below).
Regarding Claim 8, Yu 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 0068 teaches the general flow of an operation occurring as part of a data transfer event in the system 100 is shown in Figure 2; each operation comprises a blockchain transaction involving a sender that initiates the operation, and a recipient that is the target of the operation).
Regarding Claims 2 and 9, Yu teaches all the limitations of claims 1 and 8 above; and Yu further 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 0057 and 0070 teach the data upload transaction contains (among other things) only a hash of the actual data such that a downloader of the actual data from the off-chain storage can verify that the data have not been tampered with; transaction ID: the first field is an identifier for the transaction; the transaction ID could be a transaction hash ID which is generated by hashing transaction information; for example, a standard hash function such as SHA3 could be applied to certain sub-fields).
Regarding Claim 5, Yu teaches all the limitations of claim 1 above; and Yu further 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 0085 and 0111 teach the BMN 106A broadcasts the transaction to the network; since each node of the blockchain network has a copy of the user IDs, the BMN of the recipient can detect that there is a transaction intended for the recipient, based on the user ID of the recipient in the metadata of the transaction; for a data upload transaction, BMN 106D connected to the cloud service provider (off-chain storage) detects the user ID of the cloud service provider, and forwards the transaction to the cloud service provider; since each node of the blockchain network has a copy of the user IDs, the BMN 106D of the cloud service provider can detect that there is a transaction intended for the cloud service provider, based on the user ID of the cloud service provider in the metadata of the transaction. BMN 106D then forwards the transaction to the cloud service provider).
Regarding Claims 6 and 10, Yu teaches all the limitations of claims 2 and 8 above; and Yu further 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; 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 (Paragraphs 0122-0123 teach the data requestor 104B takes action based on the content of the transaction by using its ABE private key to decrypt the intermediate data to obtain the plaintext data; the data requestor 104B may also perform other operations, such as computing a hash of the received intermediate data (received out-of-band from the cloud service provider) and comparing it to the hash in the action info field of the transaction for verification purposes; after decrypting the intermediate data, the data requestor 104B populates the output field of the transaction; the Output of a data access confirmation transaction contains a Hash Value and a Timestamp; Hash Value is the hash of the plaintext shared data; the data requestor 104B calculates the hash of the plaintext shared data after decrypting the intermediate data with its private key; the hash recorded in this field could be used as the evidence of the data owner's 104A behavior; if the hash value is identical with the hash value recorded in the data upload transaction, it proves that the data owner 104A has not tampered with the data kept in the cloud; timestamp is used to store the time when the data requestor 104B signs on the transaction).
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 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Yu (WO 2021154157) in view of Kilgore (US 20210158443).
Regarding Claim 3, Yu teaches all the limitations of claim 1 above; however, Yu does not explicitly teach 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.
Kilgore from same or similar field of endeavor 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 0061 teaches the transaction information includes the payment amount, the sender cryptocurrency address (the payor computing device), and the recipient cryptocurrency address (the cryptocurrency acceptance network computing device)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Yu to incorporate the teachings of Kilgore for the transaction details to 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.
There is motivation to combine Kilgore into Yu because by using the secure & trusted cryptocurrency acceptance system, confidential payee related information (e.g., revenue, consumer spending behavior, etc.) and confidential payor related information (e.g., consumer identity of purchases, amount spent at a particular merchant, payees/merchants frequented, etc.) is private (i.e., not published on the blockchain for anyone to see) (Kilgore Paragraph 0061).
Regarding Claim 4, the combination of Yu and Kilgore teaches all the limitations of claim 3 above; however, the combination does not explicitly teach 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.
Kilgore 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 0061 teaches the transaction information includes the payment amount, the sender cryptocurrency address (the payor computing device), and the recipient cryptocurrency address (the cryptocurrency acceptance network computing device); the transaction is then included within a block that is published on the blockchain).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Yu and Kilgore to further incorporate the teachings of Kilgore for the payment details of the payer to 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.
There is motivation to further combine Kilgore into the combination of Yu and Kilgore because of the same reasons listed above for claim 3.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Yu (WO 2021154157) in view of Mutha (US 20220253360)
Regarding Claim 7, Yu teaches all the limitations of claim 1 above; however, Yu does not explicitly teach wherein said data logging module (102) is configured to periodically compress the transaction details stored in said off-chain database (30), wherein upon receiving the private call from the destination participating node, said data sharing module (108) is configured to query the off-chain database, extract the compressed transaction details requested by the destination participating node, and decompress the extracted transaction details.
Mutha from same or similar field of endeavor teaches wherein said data logging module (102) is configured to periodically compress the transaction details stored in said off-chain database (30), wherein upon receiving the private call from the destination participating node, said data sharing module (108) is configured to query the off-chain database, extract the compressed transaction details requested by the destination participating node, and decompress the extracted transaction details (Paragraphs 0287-0288 teach should the user wish to restore the first incremental backup, the data used by the system to recover the first incremental backup includes both data from the full backup copy and the transaction log; for instance, if the user were to request a restore or recovery of the first incremental backup, the media agent would replay the transaction log as it existed on day 2, which for example may include performing write operations included in the transaction log to generate the modified version (2A) of the second data block; depending on the implementation, the modified version (2A) of the second data block may either be stored on the secondary storage device or temporarily held in buffer storage during the restore operation and discarded following the restore; the media agent would create the restored data set by obtaining the data blocks 401, 403, 404 (1, 2, 3) from the secondary storage device and obtaining the newly created modified version of the second data block, e.g., either from the secondary storage device or buffer storage; the media agent processes and compiles the four data blocks as appropriate to create the restored data set (e.g., decrypts, decompresses, deduplicates, and/or reverses backup formatting) and serves the restored copy to the data agent of the requesting client computing device).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Yu to incorporate the teachings of Mutha for said data logging module (102) to be configured to periodically compress the transaction details stored in said off-chain database (30), wherein upon receiving the private call from the destination participating node, said data sharing module (108) is configured to query the off-chain database, extract the compressed transaction details requested by the destination participating node, and decompress the extracted transaction details.
There is motivation to combine Mutha into Yu because off-loading certain responsibilities from client computing devices to intermediate components such as secondary storage computing device(s) and corresponding media agent(s) can provide a number of benefits including faster and more reliable information management operations and enhanced scalability. In one example which will be discussed further below, media agent can act as a local cache of recently-copied data and/or metadata stored to secondary storage device(s), thus improving restore capabilities and performance for the cached data (Mutha Paragraph 0122).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Xingqi et al. (US 20220004647) teaches a processor may define a datastore connection object. The datastore connection object may include information regarding an off-chain datastore. The processor may associate the identifier to the datastore connection object. The processor may store the datastore connection object with the identifier in the blockchain network. The processor may identify that a request is being sent within the blockchain network. The request may include private information. The processor may determine whether to allow the request access to the off-chain datastore.
Takada (US 20200028688) teaches a first computing device associated with a first blockchain node receives a transaction request along with related data for storage in an off-chain storage. The first blockchain node may send a communication to a second blockchain node to propose recording the transaction on the blockchain, which may result in the transaction being recorded in a new block on the blockchain as conditionally accepted pending validation of the related data. The first computing device may send the related data to a second computing device associated with the second blockchain node that performs validation. The first blockchain node receives, from the second blockchain node, a communication that proposes recording of the transaction on the blockchain as being validated. The first and second blockchain nodes may send one or more communications to cause addition of another new block to the blockchain indicating validity of the transaction.
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