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 .
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.
This action is in response to the correspondence filed 10/14/2024.
Claims 1-15, 27, 29 and 31-33 are presented for examination.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-15, 27, 29 and 31-33 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As to claims 1, 27 and 29, the claims recite the limitation "storing the off-network data and cryptographic verification on the decentralized network" in the last element of the claims. It is unclear as to whether “cryptographic verification” refers to the generated cryptographic verification of the previous element or whether this is a second or different cryptographic verification. The Examiner suggests amending the claim to read “the cryptographic verification” or “a second cryptographic verification,” respectively.
As to claims 2-15 and 31-33, the claims do not cure the deficiency of claim 1 and are rejected under 35 USC § 112 for their dependency upon claim 1.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-7, 12-15, 27, 29, 31 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over US 20210256009 A1 to Zhang et al. (hereinafter Zhang) (Applicant’s IDS) in view of US 20200313903 A1 to Yu.
As to claims 1, 27 and 29, Zhang teaches a method carried out by a computing system configured for operating as a validator node of a network of nodes operating a decentralized network (paragraph 30, methods, systems, components, non-transitory computer readable media, devices, and/or networks, which validate a blockchain transaction submission based on independently submitted instances of the blockchain transaction from multiple clients), the method comprising: responsive to successfully writing a data block of the decentralized network, being eligible to perform a secure data retrieval task for the decentralized network (FIG. 1, paragraphs 31, 32 and 50, the peers participate in a number of activities including blockchain transaction addition and validation process, after adding to the blockchain or executing the consensus protocol to validate blockchain storage transactions which are stored on the blockchain, the completion of the activity is read as being eligible as the node is prepared and/or waiting for the next task based on the broadest reasonable interpretation taken by the examiner in view of the specification); retrieving the off-network data from the data source (paragraphs 46 and 66, peer(s) retrieve user's enrollment and transaction certificates from the certificate authority and receive data from clients which are located off-network); storing the off-network data on the decentralized network (paragraphs 50 and 62, peers perform blockchain transaction addition and peers append data to blockchain).
Zhang does not explicitly teach responsive to being eligible to perform the secure data retrieval task, retrieving, from a queue, a queue entry; determining, from the queue entry, a data source of off-network data; generating a cryptographic verification that the validator node carried out the retrieval of the off- network data; and storing the off-network data and cryptographic verification on the decentralized network.
However, Yu teaches responsive to being eligible to perform the secure data retrieval task, retrieving, from a queue, a queue entry (paragraph 51, received requests; paragraphs 72-74, requests received by the relay system via the blockchain, the blockchain comprising the client smart contract and the relay system smart contract through which the requests are passed read as the queue); determining, from the queue entry, a data source of off-network data (paragraph 102, determined web address where the user device wanted to access an account); generating a cryptographic verification that the validator node carried out the retrieval of the off- network data (paragraph 103, relay system node generates a signature that includes the request result using its private key which is combined with the request result); and storing the off-network data and cryptographic verification on the decentralized network (paragraph 103 and 104, wherein the signature and request result are combined to together and in view of Zhang are stored on the decentralized network).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Zhang to include the method of performing communications between blockchain networks and external data sources as taught by Yu in order to ensure the integrity of requests and responses between the blockchain and the external sources, optimizing the security of the system (paragraph 21).
As to claim 2, Yu teaches receiving conveyance data indicating assignment of a conveyance to the validator node for having retrieved, verified, and stored the off-network data (paragraphs 96, 97 and 104, received signature combined with the request result).
As to claim 3, Yu teaches wherein assignment of the conveyance to the validator node is contingent upon the validator node having retrieved, verified, and stored the off-network data (paragraphs 96, 97 and 104, wherein the relay system node had to possess the data in order to generate the signature).
As to claim 4, Yu teaches wherein the queue is at least one of: (i) a data-entry pool in the network of nodes that comprises pending data entries awaiting inclusion in data blocks of the decentralized network (paragraphs 72-74, requests received by the relay system via the blockchain, the blockchain comprising the client smart contract and the relay system smart contract through which the requests are passed read as the queue, thus when multiple request are received one request may be in each component), or (ii) a data queue implemented externally to the network of nodes.
As to claim 5, Yu teaches wherein the queue entry includes an indication that the off-network data comprises target content to be retrieved from the data source (paragraph 102, request includes a plaintext data element including a web address where the user device 502 wants to access an account, and a confidential data element including credentials (e.g., user name and password) of the user device 502 to log into the account), wherein retrieving the off-network data from the data source comprises retrieving the target content from the data source (paragraph 103, received result), and wherein generating the cryptographic verification comprises verifying that the validator node retrieved the target content from the data source (paragraph 103, generated signature combined with the result).
As to claim 6, Yu teaches storing the target content in a data-entry pool of pending data entries awaiting inclusion in data blocks of the decentralized network (paragraphs 96 and 97, result sent to user via the relay system smart contract and the client smart contract).
As to claim 7, Yu teaches wherein the network of nodes includes a data-entry pool of pending data entries awaiting inclusion in data blocks of the decentralized network (paragraphs 72-74, requests received by the relay system via the blockchain, the blockchain comprising the client smart contract and the relay system smart contract through which the requests are passed read as the queue, thus when multiple request are received one request may be in each component), wherein the data source is external to the network of nodes (Fig. 5, source is in Internet 512), and wherein the queue entry includes an indication that the off-network data comprises target content that has already been delivered to the data-entry pool from the data source (paragraphs 96, 97 and 104, wherein the signature indicates the target data has been delivered).
As to claim 12, Zhang teaches each of one or more additional validator nodes of the network of nodes, responsive to successfully writing the new data block of the decentralized network, being eligible to perform a respective secure data retrieval task for the network; each of one or more additional validator nodes, responsive to being respectively eligible to perform the secure data retrieval task, retrieving, from the queue, the queue entry; each of the one or more additional validator nodes determining, from the queue entry, the data source of the off-network data; each of the one or more additional validator nodes respectively retrieving the off-network data from the data source; each respective validator node of the one or more additional validator nodes generating a respective cryptographic verification that the respective validator node carried out the retrieval of the off-network data; and each of the one or more additional validator nodes respectively storing the off-network data and the cryptographic verification on the decentralized network (paragraphs 31 and 50, each of the peers may perform the operations).
As to claim 13, Zhang teaches making a determination that a threshold number of the validator node and the one or more additional validator nodes have stored the same data; and responsive to the determination, causing one copy of the off-network data to be included in a subsequent new data block of the decentralized network (paragraphs 86 and 87, verifying that the instances match before storing in the blockchain).
As to claim 14, Zhang teaches wherein the data source is a status database comprising status records written to the status database by one or more nodes of the decentralized network, wherein each status record includes information indicative of activity of the node on the network (paragraph 66, user's enrollment and transaction certificates), and wherein retrieving the off-network data from the data source comprises: retrieving one or more of the status records from the status database (paragraph 66, peer(s) retrieve user's enrollment and transaction certificates from the certificate authority); and delivering the one or more of the status records as retrieved directly or indirectly to at least one of the nodes of the network (paragraph 66, peer(s) are what retrieved the data).
As to claim 15, Zhang teaches wherein the decentralized network comprises a blockchain (paragraph 30, blockchain), wherein data blocks of the of the decentralized network comprise blocks of the blockchain (paragraph 31, a decentralized database (such as a blockchain) that is a distributed storage system), wherein the validator node is a miner node (paragraph 69, mining nodes), and wherein the off-network data comprises off-chain data (paragraph 66, the user's enrollment and transaction certificates from the certificate authority are located off-chain).
As to claim 31, Zhang teaches wherein the data source and the off-network data at the data source are both external to the decentralized network (paragraph 66, the user's enrollment and transaction certificates from the certificate authority are located off-chain).
As to claim 32, Zhang teaches wherein storing the off-network data and cryptographic verification on the decentralized network comprises storing the off-network data and cryptographic verification in a verification data structure configured for providing authorization for data entries to be included in future data blocks of the decentralized network (paragraphs 42 and 79, stored in queue until verified with future blocks and included in blockchain if valid).
Claim 33 is rejected under 35 U.S.C. 103 as being unpatentable over Zhang in view of Yu in further view of US 11860819 B1 to Chud et al. (hereinafter Chud).
As to claim 33, Yu does not explicitly teach wherein being eligible to perform the secure data retrieval task comprises receiving an indication of being selected to perform the secure data retrieval task.
However, Chud teaches wherein being eligible to perform the secure data retrieval task comprises receiving an indication of being selected to perform the secure data retrieval task (Col 2, lines 7-24, selected node receives the key and also information indicative of the selected node).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Zhang and Yu to include the method of providing an indication of being selected as taught by Chud in order to ensure the selected node is capable and to optimize speed and efficiency of retrieving the data.
Allowable Subject Matter
Claims 8, 9, 10, 11 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Dependent claim 8 is allowable over the prior art of record, including Zhang, Yu and the remaining references cited by the Examiner and the Applicant’s IDS, taken individually or in combination, because the prior art of record fails to particularly disclose, fairly suggest or render obvious wherein retrieving the off-network data from the data source comprises determining that a destination hash value associated with the target content in the data-entry pool agrees with a source hash value associated with the target content at the data source, and wherein generating the cryptographic verification comprises verifying that the validator node confirmed that the source hash value and destination hash value are the same, in view of the other limitations of independent claim 1 and intervening claim 7, as to claim 8; and
Dependent claim 10 is allowable over the prior art of record, including Zhang, Yu and the remaining references cited by the Examiner and the Applicant’s IDS, taken individually or in combination, because the prior art of record fails to particularly disclose, fairly suggest or render obvious wherein generating the cryptographic verification comprises applying a first hash function to the target content in the data-entry pool to derive a second hash value, and wherein storing the cryptographic verification in the verification data structure comprises storing the first hash value together with the second hash value in the verification data structure, in view of the other limitations of independent claim 1 and intervening claim 7, as to claim 10.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MALCOLM CRIBBS whose telephone number is (571)270-1566. The examiner can normally be reached Monday-Friday 930a-330p; 430p-630p.
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, Eleni Shiferaw can be reached at (571)272-3867. 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.
MALCOLM . CRIBBS
Examiner
Art Unit 2497
/MALCOLM CRIBBS/Primary Examiner, Art Unit 2497