DETAILED ACTION
Notice of Pre-AIA or AIA Status
1.The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/05/2026 has been entered.
Response to Arguments
3. According to applicant’s arguments filed on 02/05/2026, claims 1,7 and 10 have been amended, hereby acknowledged.
4. Applicant argues that the secondary reference Housholder does not discloses "a location table showing a data location of each confidential data on the blockchain in which each of the plurality of servers stores the confidential data that is different from the other servers", as recited in claim 1.
5. Examiner would like to point out that, Housholder discloses this limitation in Para :0057-0058, which teaches information files 100 are transmitted from one or more user systems to an encryption server 104. The encryption server 104 is configured to segment and encrypt the information files 100 received from the one or more user systems. The encryption server 104 utilizes a blockchain enabled operational module to segment and encrypt the received information files 100 and transmits the encrypted information file segments to digital storage in the cloud 108. The segmented, encrypted information files may be distributed within a plurality of cloud-based servers (110, 112, 114).
[As such, the segmented encrypted information files, which are the confidential data herein are distributed and stored in plurality of cloud-based servers (110, 112, 114). So, each cloud servers 110, 112 and 114 stores different confidential data even though the confidential data is segmented and encrypted from the same information file. For example, the encrypted information file are segmented into three parts A,B and C, wherein A is stored in 110, B in 112 and C in 114].
Information file segment locations are tracked by the encryption server. When requested by the user, information files may be retrieved from each of the storage servers (110, 112, 114), through the cloud storage management 108 and returned to the encryption server 104.
Fig.2 and Para:0058-0062 teaches the encryption server receives the information files at 206 and creates a hash (tamper proof of the confidential data) for each received file, storing the created hash as the unique ID for each received file. The file hash of the encrypted file, created, is gathered and utilized as the file name of the grid table portion of an echo key table to be created for each information file. The grid table portion may then be created with the file name hash from the originally submitted information file. As a portion of this step, the system also gathers the original information file name and file size. After the creation of the grid table portion, the information file is sliced into segments of about the same size at 208. The segments are cataloged in the grid table portion with each segment having a segment number, segment hash ID, and information file name at 210. In this fashion each segment is identified with a particular information file. The grid table portion records the segment as coordinates of a table via both the information file hash and the segment hash as coordinates of the segment. The file segments are encrypted into separate blocks within a blockchain construct at 211. The blockchain created from each group of segments that are sliced from each information file is referenced utilizing a unique set of IDs from the original file name, the segment hash, and the segment number and storing this information into a grid table associated with that particular information file. This information is also encrypted and stored within a block on the blockchain, providing identification and information security for the segments and information file as a whole. At 212 each hashed and encrypted segment may be transmitted to digital storage within a cloud storage system. The cloud system may then transmit the hashed and encrypted segments at 214 in a torrent to a plurality of servers.
6. Applicant further argues that the prior art of record fails to teach the new amended feature of independent claims which recites: " the node is further configured to update the location table upon receiving new data from the data source".
7. Examiner would like to point out that the new secondary reference Todd (US Pub.No.2022/0100879) teaches the above claimed limitation in Para:0074 (see, the rejection below).
Claim Rejections - 35 USC § 103
8.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.
9. Claim(s) 1,6-7,10-11 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Maher (US Pub.No.2020/0326679) in view of Housholder (US Pub.No.2019/0342074) and further in view of Todd (US Pub.No.2022/0100879).
10. Regarding claims 1 , 7 and 10 Maher teaches a data storage system/ method/ computer-readable non-transitory storage medium, comprising: a node configured to store a blockchain; and data storage server, wherein the node is further configured to, upon receiving data from a data source: separate the data into confidential data and public data; obtain a tamper proof of the confidential data; send the confidential data to the data storage server; and
store the public data and the tamper proof on the blockchain, and the data storage server is configured to store the confidential data upon receiving the confidential data from the node (Fig.2 and Para:00098-0099 teaches a data record R may comprise a public component N and a confidential component C. The record R may be denoted as R=(N:C). A data record bifurcation process 202 will generate a cryptographic hash [ which is the tamper proof of the confidential data herein] of the entire data record h(R). The hash of the entire data record along with the public component of the data record (h(R):N) will be transmitted to the public ledger 114 for storage. A hash function such as SHA-256 may be used to generate the hash of the data record, although other suitable hashing and/or other cryptographic functions could also be used. Para:0104 teaches the public ledger 114 may comprise a blockchain and/or another cryptographic ledger. For example, public ledger 114 may be anchored in a blockchain using a schema where hashes are entered into Merkle trees and the root of each tree may be recorded in the blockchain ledger.
Fig.1 and Para:0091-0094 teaches the public ledger 114, and the private database 116 may be employed in connection with a method of bifurcating record information in a consistent way for storage that preserves desired privacy properties and requirements of various stakeholders, while also providing a measure of determining provenance. The public ledger 114 may comprise a database and/or ledger where authenticated pricing and/or non-confidential and/or otherwise less secure consumption data and/or other statistics and information may be stored and/or accessed. The private database 116 may be configured to store more private and/or confidential data. For example, data stored by the private database 116 may comprise more private, confidential, and/or otherwise secure customer and/or retailer specific data including, for example and without limitation, private device and/or pricing data, transaction information (e.g., actions engaged by devices 100 and/or gateways 104 in response to received pricing information in accordance with customer specified policies and/or configurations), state data, configuration data, and/or the like),
wherein the node is further configured to, upon receiving a data request from a data user: obtain the tamper proof of the confidential data corresponding to the data request from the blockchain; obtain the public data corresponding to the data request from the blockchain;
and send the tamper proof and the public data to the data user, and the data storage server is further configured to send the confidential data corresponding to the data request to the data user upon receiving the data request from the data user, wherein the node includes an access gateway node through which the data request is received by the node, and the access gateway node is configured to send, to the data user, the public data and the tamper proof that are obtained from the blockchain upon receiving the data request from the data user , wherein the node further includes a plurality of nodes (Para:0099-0100 teaches partition schema for the data record R may be known to the private database 116. This may allow a system with permissions to access the private database 116 (e.g., an energy retailer, partners, auditors, regulators, and/or other trusted third parties) to compute the hash and use it for an efficient index in the private database 116 as well as to find records in the public ledger 114.
Fig.4 and Para:0137-0318 teaches the method 400 will be performed by, for example, a trusted partner, an authorized regulator, and/or a customer interested in accessing information included in a data management decision record. At 402, a public component of a data record and a cryptographic hash of the complete data record may be accessed by a system from a public ledger. The system, at 404, authenticate access with a private database (e.g., by presenting valid authentication credentials and/or the like). Once authenticated, at 406, the hash of the complete data record may be used to identify the complete data record in the private database using an index associating the hash with the complete data record).
Maher teaches all the above claimed limitation but fails to teach upon receiving the data request from the data user: obtain the data location of the confidential data corresponding to the data request by referring to the location table, and send the data request to one of the plurality of servers that stores the requested confidential data based on the obtained data location.
Housholder teaches the data storage server includes a plurality of servers each corresponding to a respective one of the plurality of nodes, each of the plurality of servers stores the confidential data that is different from that of other servers, the node is further configured to store a location table showing a data location of each confidential data on the blockchain, and the access gateway node is further configured to, upon receiving the data request from the data user: obtain the data location of the confidential data corresponding to the data request by referring to the location table, and send the data request to one of the plurality of servers that stores the requested confidential data based on the obtained data location (Fig.1 and Para:0057-0058 teaches information files 100 are transmitted from one or more user systems to an encryption server 104. The encryption server 104 is configured to segment and encrypt the information files 100 received from the one or more user systems. The encryption server 104 utilizes a blockchain enabled operational module to segment and encrypt the received information files 100 and transmits the encrypted information file segments to digital storage in the cloud 108. The segmented, encrypted information files may be distributed within a plurality of cloud-based servers (110, 112, 114). Information file segment locations are tracked by the encryption server. When requested by the user, information files may be retrieved from each of the storage servers (110, 112, 114), through the cloud storage management 108 and returned to the encryption server 104. The encryption server 104 provides both the decryption and reassembly of the retrieved information file segments back into the information files 100 that were originally transmitted to the encryption server 104. [As such, the segmented encrypted information files, which are the confidential data herein are distributed and stored in plurality of cloud-based servers (110, 112, 114). So, each cloud servers 110, 112 and 114 stores different confidential data even though the confidential data is segmented and encrypted from the same information file. For example, the encrypted information file are segmented into three parts A,B and C, wherein A is stored in 110, B in 112 and C in 114].
Fig.2 and Para:0058-0062 teaches transmission of one or more information files 200 from a user. The information files 200 may be transmitted to the encryption server 204 to begin the process of secure encryption. The encryption server receives the information files at 206 and creates a hash (tamper proof of the confidential data) for each received file, storing the created hash as the unique ID for each received file. The file hash of the encrypted file, created, is gathered and utilized as the file name of the grid table portion of an echo key table to be created for each information file. The grid table portion may then be created with the file name hash from the originally submitted information file. As a portion of this step, the system also gathers the original information file name and file size. After the creation of the grid table portion, the information file is sliced into segments of about the same size at 208.The segments are catalogued in the grid table portion with each segment having a segment number, segment hash ID, and information file name at 210. In this fashion each segment is identified with a particular information file. The grid table portion records the segment as coordinates of a table via both the information file hash and the segment hash as coordinates of the segment.
The file segments are encrypted into separate blocks within a blockchain construct at 211. The blockchain created from each group of segments that are sliced from each information file is referenced utilizing a unique set of IDs from the original file name, the segment hash, and the segment number and storing this information into a grid table associated with that particular information file. This information is also encrypted and stored within a block on the blockchain, providing identification and information security for the segments and information file as a whole. At 212 each hashed and encrypted segment may be transmitted to digital storage within a cloud storage system. The cloud system may then transmit the hashed and encrypted segments at 214 in a torrent to a plurality of servers).
Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Maher to include obtain the data location of the confidential data corresponding to the data request by referring to the location table, and send the data request to one of the plurality of servers that stores the requested confidential data based on the obtained data location as taught by Housholder, in such a setup
the tracking and management of the information and data file segments is accomplished through the use of an echo key portion of a grid table. The echo key table portion is used to place information and data file segments inside the blockchains in such a way that the tracking and reconstruction may be performed without having to first decrypt each information and data file segment (para:0068).
Both Maher in view Housholder teaches all the above claimed limitations but fails to tech wherein the node is further configured to update the location table upon receiving new data from the data source.
Todd teaches the node is further configured to update the location table upon receiving new data from the data source (Para:0074 teaches the new/modified data to the ledger may cause a ledger content index to be updated 424 to reflect the addition of that data to the ledger).
Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Maher in view of Housholder, to include the node is further configured to update the location table upon receiving new data from the data source as taught by Todd, such a setup will update the ledger content index to reflect the data that was appended to the ledger, and annotating the data generated by the asset with trust metadata. (abstract).
11. Regarding claim 6 Maher teaches the data storage system, wherein the tamper proof is obtained by calculating a hash value of the confidential data (Para:0099 teaches obtain tamper proof by calculating the hash of the confidential data).
12. Regarding claim 11 Maher in view of Housholder teaches the data storage system, the method and the computer-readable non-transitory storage medium, wherein the node is further configured to, obtain the tamper proof of the confidential data and public data from the blockchain; and send the tamper proof and the public data to the data user (Maher: Figs.1-2, Para:0091-0094 and Para:0099);
upon receiving a data request from a data user, sending the tamper proof and the public data to the data user (Housholder: Fig.2 and Para:0057-0062 teaches receiving data request and sending the tamper proof data (hash data) to the user); and the data storage server is further configured to send the confidential data corresponding to the data request to the data user upon receiving the data request from the data user (Housholder: Figs.1-2 and Para:0057-0062 teaches send the confidential data corresponding to the data request to the data user).
13. Regarding claims 13 , 14 and 15 Housholder teaches the data storage system, the method and the computer-readable non-transitory storage medium, wherein the location table shows a correspondence between each confidential data and its data location (Fig.2 and Para:0057-0062 teaches transmission of one or more information files 200 from a user. The information files 200 may be transmitted to the encryption server 204 to begin the process of secure encryption. The encryption server receives the information files at 206 and creates a hash (tamper proof of the confidential data) for each received file, storing the created hash as the unique ID for each received file. The file hash of the encrypted file, created, is gathered and utilized as the file name of the grid table portion of an echo key table to be created for each information file. The grid table portion may then be created with the file name hash from the originally submitted information file. As a portion of this step, the system also gathers the original information file name and file size. After the creation of the grid table portion, the information file is sliced into segments of about the same size at 208.The segments are catalogued in the grid table portion with each segment having a segment number, segment hash ID, and information file name at 210. In this fashion each segment is identified with a particular information file. The grid table portion records the segment as coordinates of a table via both the information file hash and the segment hash as coordinates of the segment.
The file segments are encrypted into separate blocks within a blockchain construct at 211. The blockchain created from each group of segments that are sliced from each information file is referenced utilizing a unique set of IDs from the original file name, the segment hash, and the segment number and storing this information into a grid table associated with that particular information file. This information is also encrypted and stored within a block on the blockchain, providing identification and information security for the segments and information file as a whole. At 212 each hashed and encrypted segment may be transmitted to digital storage within a cloud storage system. The cloud system may then transmit the hashed and encrypted segments at 214 in a torrent to a plurality of servers).
14.Claim(s) 3, 9 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Maher (US Pub.No.2020/0326679) in view of Housholder (US Pub.No.2019/0342074) and in view of Todd (US Pub.No.2022/0100879) as applied to claims 1,7 and 11 above and further in view of Yang (US Pub.No.2018/0285839)
15. Regarding claims 3 , 9 and 12 Maher teaches all the above claimed limitations but does not expressly teach determine whether the confidential data is tampered using the tamper proof; and send the confidential data to the data user upon determining that the confidential data is not tampered .
Yang teaches the data storage system, the method and the computer-readable non-transitory storage medium, wherein the node is further configured to send the tamper proof to the data storage server upon receiving the data request from the data user, and the data storage server is further configured to: determine whether the confidential data is tampered using the tamper proof; and send the confidential data to the data user upon determining that the confidential data is not tampered (Para:0020-0023 and Para:0030 teaches determine whether the confidential data is tampered using the tamper proof, and sending the data to the user).
Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Maher in view of Housholder and in view of Todd to include determine whether the confidential data is tampered using the tamper proof; and send the confidential data to the data user upon determining that the confidential data is not tampered as taught by Yang, such a setup would create a secure and completely auditable system of document tracking that can be shared among multiple parties over a computer network (abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEREENA T CATTUNGAL whose telephone number is (571)270-0506. The examiner can normally be reached Mon-Fri : 7:30 AM-5 PM EST.
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, Lynn Feild can be reached at 571-272-2092. 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.
/DEREENA T CATTUNGAL/Primary Examiner, Art Unit 2431