DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Allowable Subject Matter
Claims 1-9, 13 and 15-24 are allowable over the prior art. However, the claims remain rejected under non-statutory double patenting.
Reasons For Allowance
The cited references do not disclose generating, at the client device, a unique first data layer key based on values stored in the first data segment, wherein the first data layer key uniquely identifies the first data segment, generating, at the client device, a first reference layer data segment based on components of the first data layer key, and sending, to the data store over a network, for storing in the data store: a first data layer key-value pair comprising the first data layer key and the first data segment; and a first reference layer key-value pair comprising a reference layer key and the first reference layer data segment..
Specification
The disclosure is objected to because of the following: When discussing the purpose of the Summary, page 2 lines 26-27 of the as-filed of the Specification (i.e., paragraph [0008] of the published application) states that …
It should not be used to identify essential features of the claimed subject matter, nor to limit the scope of the claimed subject matter.
This contradicts 37 CFR §1.73 which states that the summary should “be commensurate with the invention as claimed”. MPEP §608.01(d) further adds that “the summary should be directed to the specific invention being claimed”. And, anything in the disclosure can/will be used to help determine the scope of the claimed subject matter (e.g., for interpreting a claim’s meaning). And, the claims are required to be supported by the disclosure, especially concerning enablement and clarity. 35 USC §§112 (a) and 112(b). The Office recommends deleting these sentences. Applicant is respectfully reminded to review the specification/abstract/claims/drawings for all informalities.
Claim Rejections – 35 U.S.C. § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-9, 13 and 15-24 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
These claims are rejected under 35 USC §101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites at a very level, organizing and storing data. Thus, the claims encompass the performance of the limitations in the mind, or alternatively the solving of a math problem (i.e., a series of mathematical steps) that are not tied to a practical application.
Regarding the independent claims:
Step 1: Yes, claim 1 recites a method (therefore a process), claim 13 is also directed to a method (therefore a process), and claim 15 is directed to a storage medium (therefore a product/machine). Thus, each of these claims is directed to a statutory category.
Step 2A, Prong 1 (Judicial Exception Recited?): Yes. Claims 1 and 15 recite limitations directed to an abstract idea: “generating, at the client device, a unique first data layer key based on values stored in the first data segment, wherein the first data layer key uniquely identifies the first data segment; generating, at the client device, a first reference layer data segment based on components of the first data layer key”. Claim 13 also recites limitations directed to an abstract idea: “… generated based on values stored in the first data segment; …”. As drafted, each of these limitations recites a mentally performable process as one can generate / create data (or a data structure / collection) via a mental process or using paper and pencil.
Step 2A, Prong 2 (Integrated into a Practical Application?): No. Claim 1 recites the following additional elements: a “computer”, a “client device”, a “data store” and a “network”. Claim 13 recites the following additional elements: a “computer”, a “client device”, a “network” and a “data store”. And, claim 15 recites the following additional elements: a “non-transitory computer-readable medium”, “one or more processors”, a “device”, a “client device”, a “data store” and a “network”. Each of these are merely high-level recitations of generic computer components and represent mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Additionally, claims 1, 13 and 15 each recites “ receiving …” and “sending … for storing …” or storing …”. These elements represent insignificant extra-solution activity as receiving/transmitting of data (i.e. mere data gathering) such as 'obtaining information' as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. Viewing the additional limitations together and the claims as a whole, nothing provides integration into a practical application. Therefore, each claim is directed to an abstract idea.
Step 2B (Inventive Concept Provided?): No. As discussed with respect to Step 2A, the elements (i.e., steps of receiving, storing or sending for storing) in the claim amount to no more than mere instructions to apply the exception. Mere instructions to apply an exception using generic computer components (e.g., storage and processors) cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
With respect to the receiving, storing or sending for storing limitations discussed above, and when re-evaluated these elements are well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); … iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; ", and thus remain insignificant extra-solution activity that does not provide significantly more.
Therefore, each of the independent claims, taken as a whole, does not change this conclusion and each claim (i.e., 1, 13 and 15) is ineligible.
Claims 2-9 and 16-17 depend upon claim 1, and do not correct the issues set forth above. These claims essentially further recite previously discussed elements such as generation, storage and receiving/sending. Additional elements such as splitting, compressing or identifying are further actions that may be characterized, at least, as abstract mental or mathematical concepts. Therefore, these claims are likewise rejected.
Claims 18-24 depend upon claim 13, and do not correct the issues set forth above. These claims essentially further recite previously discussed elements such as receiving, generating and storing and the use of certain data types. Therefore, these claims are likewise rejected.
Therefore, each claim is not patent eligible, and is reasonably rejected under 35 USC §101.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Relevance is provided in at least the Abstract of each cited document.
Non-Patent Literature
Gao, Xiaofei, et al., “B-store, a General Block Storage and Retrieval System for Blockchain”, WISA 2022, LNCS 13579, SpringerNature Link, © 2022, pp. 674-686.
The emergence of Hyperledger provides a variety of feasible and feature-rich solutions for smart contracts on the blockchain, promoting the popularity and spread of blockchain systems. Similar with Bitcoin and Ethereum, Hyperledger has accelerated the dramatic increasement in the scale of blockchain data. Applications based on blockchain systems need to quickly retrieve transaction data in blocks while processing and analyzing data. Currently, Hyperledger Fabric only provides limited retrieval functions, such as searching for blocks based on single fields like block height, block hash, and transaction hash. Such retrieval functions cannot meet the needs of current blockchain applications. In this paper, we propose a general blockchain data storage and retrieval system B-Store for the blockchain platform. B-Store divides the blockchain data into data segment and index segment. The index segment uses B+ tree as the underlying data structure, and provides two retrieval options: block retrieval and transaction retrieval. B Store supports single-field or multi-field equivalent retrieval, range retrieval and top-k retrieval on block data and transaction records. We compare two blockchain storage solutions, Hyperledger Fabric and B-Store. The final experimental results show that B-Store achieves low additional storage and performance overhead when adding new blocks, but provides rich and efficient retrieval functions for blocks and transactions. (page 674, Abstract).
Lu, Siyuan, et al., “Chapter 1 - IBM PAIRS: Scalable Big Geospatial-Temporal Data and Analytics As-a-Service”, Handbook of Big Geospatial Data, © Springer Nature Switzerland AG, May 8, 2021, pp. 3-34.
distinguishing feature of PAIRS is that all data are ready for use
without a data staging or preparation step. Unlike many other technologies, PAIRS uses object and cold store only for archiving data which have already been ingested into the key-value store. All PAIRS data are organized in layers, where each layer is
linked in space and time. Layers can be access controlled (visualization only, read, write, admin) according to the privileges of user groups. In addition to PetaBytes of raster data stored, vector data (discrete points, polygons, typically much smaller in volume) are stored in PAIRS in Postgres or a key-value store which can be queried using SPARK SQL. (page 7 – line 2 of page 8).
US Patent Application Publications
Nelson 2023/0032841
A technique for using a caching layer for key-value storage in a database is described. In one example of the present disclosure, a system can receive, at an unsorted data structure of a caching layer, a key-value pair associated with a data object. The unsorted data structure can store a first plurality of key-value pairs. The system can receive one or more operations for updating the key-value pair in the caching layer. The system can determine the key-value pair is to be migrated to a sorted memory table based on a caching algorithm. The system can migrate the key-value pair to a sorted memory table configured to store a second plurality of key-value pairs that is larger than the first plurality of key-value pairs and sort the key-value pair with the second plurality of key-value pairs prior to storing the key-value pair in the sorted memory table. (Abstract). Example 1 is a system comprising: a processor; and a memory device including instructions that are executable by the processor for causing the processor to: receive, at an unsorted data structure of a caching layer, a key-value pair associated with a data object, the unsorted data structure storing a first plurality of key-value pairs; receive one or more operations for updating the key-value pair in the caching layer; determine, with the caching layer being full and an additional key-value pair being received to be stored in the caching layer, the key-value pair is to be migrated to a sorted memory table based on a caching algorithm; migrate the key-value pair to the sorted memory table configured to store a second plurality of key-value pairs that is larger than the first plurality of key-value pairs; and sort the key-value pair with the second plurality of key-value pairs prior to storing the key-value pair in the sorted memory table. (para 0042).
Travis 2013/0103658
A method for storing time series data in a key-value database includes receiving time series data relating to the occurrence of an event. An addressing scheme that defines attributes for inclusion in keys for the event is analyzed. The attributes include time granularity attributes of different sizes. The method generates a key corresponding to the time series data based on the analyzing of the addressing scheme including attributes specified in the addressing scheme that are related to the event and one of the attributes represents one of the plurality of time granularity attributes. The method further issues a command to the key-value database to store a record of the occurrence of the event as a value in the key-value database where stored values in the key-value database corresponding keys may be used to satisfy queries relating to the event over a range of time. (Abstract). FIG. 7 shows an example of selecting time windows in a time dimension hierarchy according to one embodiment. (para 0013). Furthermore, the value of attributes in an N-tuple key may be dependent upon a "hierarchy" specified in the addressing scheme for the dimension to which the attribute belongs. For example, as will be discussed in further detail below, a hierarchy for the time dimension may be represented by different granularity layers of time windows (e.g., a 1 day granularity, a 2 day granularity, etc.). (para 0021, see FIG. 7). As further depicted in the embodiment of FIG. 2, the color, shape, and time dimension are hierarchical, with a hierarchy 206-1 for the color dimension, a hierarchy 206-2 for the shape dimension, and a hierarchy 206-3 for the time dimension. Color dimension hierarchy 206-1 and shape dimension hierarchy 206-2 are arranged in a hierarchical directed graph. For example, a "Red" node is a child of a "Primary" node under a root node of "All". Also, a "Cube" node is a child of a root node "All". Time dimension hierarchy 206-3 of FIG. 2 is represented by different time granularity layers. Each granularity layer includes time windows of a different size. For example, each granularity layer contains time windows that are a multiple of the size (i.e., time period) of the previous layer. In this example, the granularities are 1 day, 2 day, 4 day, and 8 day, but other time windows may be used. The time window may be based on a start time and a duration. (paras 0023-0024). If service node 104 has been configured to perform "eager roll ups," then at 408, service node 104 uses a roll up algorithm to determine whether higher levels of hierarchies for various dimensions may be utilized to generate additional key-value pairs. For example, the addressing scheme may indicate to service node 104 that "eager roll-up" should be performed and that multiple granularity levels along the time dimension should be "rolled up." (para 0032). FIG. 5 shows an example of eagerly rolling up time series data according to one embodiment. For each time granularity layer, key-value database 106 includes a number of keys. A single key is associated with a time window. Thus, for an eight day period starting on January 1st, eight 1-day keys, four 2-day keys, two 4-day keys, and one 8-day key may exist. An example is shown for the first two keys of four different granularity layers. At 502, key-value database 106 includes key-value pairs for keys 202-1-202-4 that are each associated with a different granularity layer for the time dimension. For example, the time dimension is shown at 504 where the time windows start at January 1.sup.st and cover 1, 2, 4, and 8 day periods. (para 0034).
US Patents
Biswas 11,507,555
Systems and methods for multi-layered key-value storage are described. For example, methods may include receiving two or more put requests that each include a respective primary key and a corresponding respective value; storing the two or more put requests in a buffer in a first datastore; determining whether the buffer is storing put requests that collectively exceed a threshold; responsive to the determination that the threshold has been exceeded, transmitting a write request to a second datastore, including a subsidiary key and a corresponding data file that includes the respective values of the two or more put requests at respective offsets in the data file; for the two or more put requests, storing respective entries in an index in the first datastore that associate the respective primary keys with the subsidiary key and the respective offsets; and deleting the two or more put requests from the buffer. (Abstract). The key-value server 4100 is configured to maintain an index 4440 in the first datastore 4400 that indicates the location of values associated with keys of a top layer key-value store in the lower layer key-value store on the second datastore 4500. For example, a first key (K1) of the top layer key-value store may be mapped to a first subsidiary key (SK1) of the lower layer key-value store and an offset (O1A), while a second key (K2) of the top layer key-value store may also be mapped to the first subsidiary key (SK1) of the lower layer key-value store but mapped to a different offset (O1B). For example, a third key (K3) of the top layer key-value store may be mapped to a second subsidiary key (SK2) of the lower layer key-value store and an offset (O2A), while a fourth key (K4) of the top layer key-value store may also be mapped to the second subsidiary key (SK2) of the lower layer key-value store but mapped to a different offset (O2B), and a fifth key (K5) of the top layer key-value store may also be mapped to the second subsidiary key (SK2) of the lower layer key-value store but mapped to a different offset (O3B). For example, a sixth key (K6) of the top layer key-value store may be mapped to a third subsidiary key (SK3) of the lower layer key-value store and an offset (O3A), while a seventh key (K7) of the top layer key-value store may also be mapped to the third subsidiary key (SK3) of the lower layer key-value store but mapped to a different offset (O3B). Thus, the index 4440 may be used to map from a key of the top layer key-value store to value data that is stored in the lower layer key-value store on the second datastore 4500. (col. 37 line 64 – col. 38 line 25).
Hoffman 11,256,720
A hierarchical data structure includes data blocks separated into a plurality of data segments partitioned into a plurality of supersegments. Each data segment includes a predetermined number of data blocks. Each supersegment includes a predetermined number of data segments. Responsive to receiving data to store in the hierarchical data structure, a first subset of data segments are grouped into a first supersegment to allow a first portion of the data to be sequentially stored to a first set of data blocks in a first data segment of the first supersegment. Also, a second portion of the data is sequentially stored to a second set of data blocks in a second data segment of the first supersegment. Probabilistic membership query filters are generated at each different level for each data segment and the first supersegment of the hierarchical data structure to allow for efficient search and data retrieval. (Abstract). The disclosure generally relates to key-value database systems, and more particularly to a hierarchical database system having a fixed-number of data key-values with probabilistic membership query filters for each tier with an unlimited number of top-level nodes, allowing storage for an open-ended number of key-value pairs in the database. (col. 1 lines 7-12).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner ROBERT STEVENS whose telephone number is (571) 272-4102. The examiner can normally be reached Mon - Fri 6:00 - 2:30.
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, Amy Ng can be reached on (571) 270-1698. 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.
/ROBERT STEVENS/Primary Examiner, Art Unit 2164
May 15, 2026
Prosecution Insights