DETAILED ACTION
This office action is in response to applicant's communication filed on 04/10/2026.
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 Amendment
The Applicant's remarks and amendments, in response to the last Office Action, have been considered with the results that follow:
Claims 1, 6, 8-11, 13, 15, and 19 are amended.
Claims 1-20 are now pending in this application.
The previously raised objections to claims are withdrawn in view of Applicant's amendments to the claims.
The previously raised 35 U.S.C. §101 rejections of claims are withdrawn in view of Applicant's amendments to the claims.
Response to Arguments
Applicant's arguments filed 04/10/2026 have been fully considered but they are moot, because a new ground(s) of rejection has been issued, in view of Applicant's amendments to the claims, and the arguments do not apply to the new combination of references being used in the current rejection.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ricotta (US 2019/0012466 A1) in view of Kumar (US 2025/0086215 A1) and Vasylyev (US 2024/0412720 A1).
Regarding claim 1,
Ricotta teaches A method comprising: receiving a data object at a node of a datagrid system …; storing a first association in a first cache of the node, the first association including the data object; *see paras42-45(“Platform 100 is formed of a plurality of nodes 102 that communication with each other via the computer network. Each node 102 is a computer that includes at least one processor, a memory…node 102 operates to provide a service 198 to an actor 150, and thereby services 198 of platform 100 operate to store data received from one or more of the actors 150 [receiving data object at node of datagrid/platform’], and to make the stored data available to one or more of the actors…”), FIGS.1-4, paras49-56(“...As data 302 is received, and prior to storing and/or transmission within platform 100, data cloaking module 106(2) ciphers data 302 using cipher stream 304 to generate cipher data 306…Data cloaking module 106 may implement vertical cloaking using immutable journal 108 and one or more keys…Shards 350 that form one particular data set (e.g., cipher data 306, and thus data 302) may be referred to as an “information set”. The sharding approach is independent of where shards are stored. Shards 350 may be stored within a traditional RDBMS or NoSQL data store, a global content addressable key space as implemented in DHT, or directly in a block chain. For each shard 350 created from data 302, a storage manager 404 of data cloaking module 106 determines at least one data store 120 for storing the shard, sends that shard to the corresponding node 102, keeping shards 350 that are to be stored locally. For each shard 350, data cloaking module 106 (either the local module 106 or a receiving module 106) adds a block 304 defining the shard and its storage location to immutable journal 108. Each block 304 may also identify the source (e.g., actor 150) and structure (e.g., type of data) of the portion of data 302 within the associated shard 350. As shown in FIG. 3: data cloaking module 106(2) stores shard 350(1) in local data store 120(2) and creates block 304(2) within immutable journal 108(2) [storing first association in first cache of node; Examiner notes that current claim language doesn’t specify characteristics of cache, or how it is created, so it is broadly interpreted to include any kind of structure/memory space used to store data],…and data cloaking module 106(3) receives shard 350(2) from node 102(2), stores shard 350(2) in data store 120(3), and creates block 304(3) within immutable journal 108(3)… immutable journal 108 contains immutable information as to the location of each shard 350…”)
Ricotta does not expressly teach ‘…receiving a data object …to train an artificial intelligence (AI) application …storing the second association in a second cache of the node, the second association including an embedding object based on the data object; and adjusting at least one of a size of the first cache or a size of the second cache during execution of the AI application.
However, Kumar teaches …receiving a data object …to train an artificial intelligence (AI) application; storing a first association in a first cache of the node, the first association including the data object; …storing the second association in a second cache of the node, the second association including an embedding object based on the data object; and … *see FIGS.1-5, paras26-34, paras35-40(“…System 100 is prompted to generate textual output 118 based on receiving a plurality of input text files 110 [data object] and a query 112…input text files 110 received by LLM 102 may include multiple text files containing information about projected financial data for an organization in the year 2024 [receiving data object…]. In other words, input text files 110 are generated specifically for the organization and may contain information that is not publicly available (for training off-the-shelf LLMs […to train artificial intelligence (AI) application]). Query 112 (e.g., received by LLM 102 in addition to input text files 110) may include a question of “what is the budget for 2024?”…Index retrieval component 120 of LLM 102 obtains an index 106…associated with the plurality of input text files 110 to process query 112. Specifically, a plurality of indices 106 may have been previously created for vector embeddings 116 of a plurality of text files 114. These pre-created indices 106, text files 114, and their corresponding vector embeddings 116 (e.g., low-dimensional representations) may be stored in memory 104 as shown in FIG. 1, or local storage(s) housed in, or directly attached to [memory/local storage teach first, second cache, under broadest reasonable interpretation of elements] LLM 102 [teaches …storing text files/first association including data object; and embeddings/second association including embedding object based on data object, under broadest reasonable interpretation of elements in amended claim]. Storing pre-created indices 106, text files 114, and their corresponding vector embeddings 116 in memory 104 helps to reduce the amount of time to access pre-created indices 106, text files 114, and their corresponding vector embeddings 116 when a query 112 is received, than when pre-created indices 106, text files 114, and their corresponding vector embeddings 116 are maintained in storage…index 106 obtained by index retrieval component 120 is a special data structure built on top of vector embeddings 116 generated for text files 114 (e.g., including at least input text files 110) associated with the index 106. In certain aspects, index 106 is an inverted index structure, which is a data structure storing a mapping from content, such as words, numbers, vector embeddings 116, etc., to its locations. For example, index 106 obtained by index retrieval component 120 includes a plurality of key-value mappings, where each key-value mapping includes a key and a corresponding value. Each key of a respective key-value mapping may identify a voronoi cell created for index 106, and each value of a respective key-value mapping may identify vector embeddings 116 of text files 114 associated with the particular voronoi cell associated with the corresponding key...”), paras74-87
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Ricotta to incorporate the teachings of Kumar and enable Ricotta to receive data to train AI application, and store first/second associations corresponding to received data and embedding object based on received object in first and second caches, as doing so would enable reduced search latency, thereby dramatically accelerating query response times, particularly for large datasets (Kumar, paras34-38).
Further, Vasylyev teaches …adjusting at least one of a size of the first cache or a size of the second cache during execution of the AI application. *see para37, paras112-120(“…In step 4, assistant system 2 may determine the optimal window size [teaches size of first/second cache…during execution of AI application, under broadest reasonable interpretation of elements] based on the utility score using a piecewise function, e.g., according to the following example: if utility_score <0.2 then optimal_window_size=30 seconds, else if utility_score <0.5 then optimal_window_size=60 seconds, else if utility_score <0.8 then optimal_window_size=90 seconds, else: optimal_window_size=120 seconds. This function may be used to map the utility score to predefined window sizes, ensuring a minimum of 30 seconds and a maximum of 120 seconds. [0115] In step 5, assistant system 2 may adjust the computed window size if any warning flags are active, for example: if low_memory_warning or processor_overload_warning then optimal_window_size=max (optimal_window_size-30, 30) else if high_latency_warning then optimal_window_size=max (optimal_window_size-15, 30), and so on. This step may be configured to reduce the window size by a predefined time interval (e.g., by 30 seconds) if there is a memory or processor warning, and by a predefined smaller time interval (e.g., 15 seconds) for a latency warning, while maintaining the pre-defined minimum (e.g., 30 seconds). The computed optimal_window_size may then be used to truncate the conversation history and is updated dynamically as conditions change...” teaches adjusting size of first/second cache…during execution of AI application, under broadest reasonable interpretation of elements)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Ricotta to incorporate the teachings of Vasylyev and enable Ricotta to adjust size of first, second cache during execution of AI application, as doing so would enable adaptive window shrinking during resource-intensive queries and longer context window to facilitate user’s focused work (Vasylyev, paras116-120).
Regarding claim 2,
Ricotta as modified by Kumar and Vasylyev teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Ricotta as modified by Kumar further teaches The method of claim 1, further comprising: allocating the first cache and the second cache in the node. *see Ricotta:para03(“...adaptive data storage platform includes a plurality of nodes communicatively coupled together, a plurality of data stores, each data store associated with a different one of the nodes, and an immutable journal distributed between the plurality of nodes. Each node includes a processor and a memory storing machine readable instructions executable by the processor to implement a consensus trust module capable of: generating a majority voted and one-way hashed value for a request from an actor to access the database, wherein the hashed value is indicative of trust of the data; storing the hashed value in the immutable journal; and determining a consensus trust of the actor and data based upon the hashed value stored in the immutable journal by a majority of the plurality of nodes”), paras50-56(“...Data cloaking module 106 also implements “horizontal data cloaking” that subdivides the cipher data 306 into a plurality of subsets that are then shared across multiple nodes 102. As shown in FIG. 4, data cloaking module 106 includes a sharder 402 that divides cipher data 306 into a plurality of shards 350. In certain embodiments, shards 350 are of equal size, where a final shard 350 may be null filled (padded) when not filled by cipher data 306...The sharding approach is independent of where shards are stored. Shards 350 may be stored within a traditional RDBMS or NoSQL data store, a global content addressable key space as implemented in DHT, or directly in a block chain…”; It is understood that the steps described in these paragraphs involve allocating memory for shards, which teach first cache); Kumar: para38(“...Index retrieval component 120 of LLM 102 obtains an index 106 (or multiple indices 106) associated with the plurality of input text files 110 to process query 112. Specifically, a plurality of indices 106 may have been previously created for vector embeddings 116 of a plurality of text files 114. These pre-created indices 106, text files 114, and their corresponding vector embeddings 116 (e.g., low-dimensional representations) may be stored in memory 104 as shown in FIG. 1, or local storage(s) housed in, or directly attached to LLM 102. Storing pre-created indices 106, text files 114, and their corresponding vector embeddings 116 in memory 104 helps to reduce the amount of time to access pre-created indices 106, text files 114, and their corresponding vector embeddings 116 when a query 112 is received, than when pre-created indices 106, text files 114, and their corresponding vector embeddings 116 are maintained in storage.”; It is understood that steps involved to pre-creating indices (for storing vector embeddings), which teaches second cache, involve allocating memory)
Regarding claim 3,
Ricotta as modified by Kumar and Vasylyev teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Kumar further teaches The method of claim 1, further comprising: performing a proximity search based on user content in a query message; identifying the second association based on the proximity search; and returning the embedding object in response to the query message. *see paras53-59(“...a received query stating “What is the capital of France?” may be (1) pre-processed to remove stop words (e.g., having “capital France” remaining) and (2) used to create a low-dimensional embedding for the query [user content in a query message]. A distance metric, such as a Euclidean distance, cosine similarity, and/or the like, may be calculated between the query embedding and the centroid of each voronoi cell in index 106 [performing a proximity search]. A smaller distance metric calculated between the query embedding and a centroid of a voronoi cell may indicate a greater similarity/relatedness between the query embedding and the voronoi cell. A voronoi cell (e.g., such as Voronoi cell 1 in FIG. 2B) having a greatest similarity (or increased similarity) to the query embedding may be identified as the voronoi cell of the index corresponding to the query embedding (e.g., identified by voronoi cell determination component 126) [identifying second association…]. For the above example, the voronoi cell determination component 126 may determine that the query embedding for the pre-processed query “budget 2024” corresponds to a first voronoi cell associated with a first key-value mapping…Vector embeddings retrieval component 128 uses the value of the key-value mapping associated with the identified voronoi cell (e.g., corresponding to the query embedding) to determine which vector embeddings 116 and text files 114 are to be used for a similarity search. Vector embeddings retrieval component 128 obtains these vector embeddings 116 and provide them to LLM…Similarity search component 130 then uses the obtained vector embeddings 116 when performing a similarity search. For example, similarity search component 130 computes the similarity of each of the retrieved vector embeddings 116 to the query embedding (e.g., created by query embedding component 124). Comparing the query embedding to the obtained vector embeddings 116 is performed to determine one or more closest vector embeddings 116 (e.g., to the query embedding)…similarity search component 130 may (1) compare the first vector embedding 116(1) associated with first text file 114(1) to the query embedding, (2) compare the second vector embedding 116(2) associated with second text file 114(2) with the query embedding, and (3) compare the third vector embedding 116(3) associated with third text file 114(3) to the query embedding. Based on this comparison, similarity search component 130 determines the closest vector embedding(s) 116 to the query embedding [it is understood embeddings determined at this step is intermediate response]. Candidate answer generation and scoring component 132 then generates one or more candidate answers to query 112 based on the closest vector embedding(s) 116 and score each of the candidate answers generated by component… top-ranked answer may be retrieved and provided as textual output 118 to user 108…” teaches returning answers/including embedding object in response to query message)
Regarding claim 4,
Ricotta as modified by Kumar and Vasylyev teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Ricotta further teaches The method of claim 1, wherein the datagrid system comprises a plurality of nodes, the method further comprising: receiving training data; dividing the training data into a plurality of data objects; and distributing the plurality of data objects to the plurality of nodes. *see paras04-09(“...ciphering received data; sharding the ciphered data into equally sized shards and storing each of the shards on at least one of the data stores; and sending each of the shards to another of the plurality of nodes for storing on a corresponding one of the data stores, wherein the node storing the shard creates an entry in the immutable journal to indicate the location of the shard. The data is thereby ciphered and distributed across the plurality of data stores… each node further includes machine readable instructions stored in the memory and executable by the processor to implement the data cloaking module further capable of periodically sending at least one shard stored on the local data store to a different one of the nodes for storing on the corresponding data store, wherein the different one of the nodes creates an entry in the immutable journal indication the location of the shard. The data is thereby ciphered and distributed across the plurality of data stores and is not stationary...” teaches dividing received data into plurality of objects and distributing them to plurality of nodes/stores; Examiner notes that claim doesn’t specify structure or format for ‘training data’, so it is broadly interpreted as any data), paras44-45(“...Data cloaking modules 106 increase security of stored data by breaking received data into shards [dividing training data into plurality of objects], where each shard is placed into a secure ciphered (e.g., encrypted) container, randomly distributed across data stores 120 [distributing plurality of objects to nodes], and periodically moved between data stores 120. Nodes 102 thereby cooperate to enable a high protective state on sensitive data sets, while providing on-the-fly access to the data…”), paras50-56(“Data cloaking module 106 also implements “horizontal data cloaking” that subdivides the cipher data 306 into a plurality of subsets that are then shared across multiple nodes 102. As shown in FIG. 4, data cloaking module 106 includes a sharder 402 that divides cipher data 306 into a plurality of shards…The sharding approach is independent of where shards are stored. Shards 350 may be stored within a traditional RDBMS or NoSQL data store, a global content addressable key space as implemented in DHT, or directly in a block chain. For each shard 350 created from data 302, a storage manager 404 of data cloaking module 106 determines at least one data store 120 for storing the shard, sends that shard to the corresponding node 102, keeping shards 350 that are to be stored locally. For each shard 350, data cloaking module 106 (either the local module 106 or a receiving module 106) adds a block 304 defining the shard and its storage location to immutable journal 108…”)
Regarding claim 5,
Ricotta as modified by Kumar and Vasylyev teaches all the claimed limitations as set forth in the rejection of claim 4 above.
Ricotta further teaches The method of claim 4, wherein the plurality of nodes are communicatively coupled to a network. *see paras42-43(“FIG. 1 shows one exemplary secure adaptive data storage platform 100. Platform 100 is formed of a plurality of nodes 102 that communication with each other via the computer network. Each node 102 is a computer that includes at least one processor, a memory…The nodes 102 of platform 100 are connected P2P using a leaderless gossip-based protocol. All communication for the P2P consensus algorithm occur over this protocol via a TCP/IP transport.”)
Regarding claim 6,
Ricotta as modified by Kumar and Vasylyev teaches all the claimed limitations as set forth in the rejection of claim 4 above.
Ricotta further teaches The method of claim 4, wherein a topology of the datagrid system corresponds to a distributed hash table. *see paras49-51 (“...Data cloaking module 106(2) within node 102(2) creates a cipher stream 304 (a type of one-time pad) prior to receiving data 302…allows platform 100 to handle very large data sets without the typical time/compute resource expenditures normally associated with cryptographic functions…keys used for cloaking data 302 may be a composite of a hash of previous, current, and subsequent blocks of data in the original clear text stream. These keys may be stored within a data rights management layer of platform…sharding approach is independent of where shards are stored. Shards 350 may be stored within a traditional RDBMS or NoSQL data store, a global content addressable key space as implemented in DHT [topology…distributed hash table], or directly in a block chain”), para03(“...Each node includes a processor and a memory storing machine readable instructions executable by the processor to implement a consensus trust module capable of: generating a majority voted and one-way hashed value for a request from an actor to access the database, wherein the hashed value is indicative of trust of the data; storing the hashed value in the immutable journal; and determining a consensus trust of the actor and data based upon the hashed value stored in the immutable journal by a majority of the plurality of nodes…” teaches distributed hash table), paras46,111,114
Regarding claim 7,
Ricotta as modified by Kumar and Vasylyev teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Kumar further teaches The method of claim 1, wherein the embedding object comprises a vector. *see paras26-34(“...LLM-based system described herein is configured to obtain an index associated with a plurality of input text files (e.g., a special data structure built on top of vector embeddings of at least the input text files) to process a query related to at least one of the input text files. The index is partitioned into a plurality of voronoi cells, where each voronoi cell contains similar vector embeddings representing text of the input text files. The LLM-based system identifies a voronoi cell of the index with a greatest similarity to an embedding created for the query, and uses vector embeddings belonging to this voronoi cell to perform a similarity search and thus generate textual output in response to the received query. In other words, less than all vector embeddings associated with the input text files are searched to produce a query response… For example, prior to receiving the query request, each of the input text files (and, in some cases, one or more other text files) may have been (1) pre-processed, (2) converted to numerical representations, for example, vector embeddings, using embedding techniques, models, and/or encoders (e.g., a trained neural network encoder model), (3) compared against vector embeddings of the other input text files, and (4) organized in a low-dimensional space of an index based on the comparison. The comparison is used to determine a relatedness and/or similarity of each vector embedding to other vector embeddings which make up the input text files. In certain aspects, the comparison is performed by determining a distance metric between two vector embeddings… a large distance metric calculated between two vector embeddings may indicate that the embeddings are likely not related, and thus these vector embeddings may be placed further apart in the index...”)
Regarding claim 8,
Claim 8 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 9,
Claim 9 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 10,
Claim 10 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 11,
Claim 11 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 12,
Claim 12 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 13,
Claim 13 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Regarding claim 14,
Claim 14 recites substantially the same claim limitations as claim 7 and is rejected for the same reasons.
Regarding claim 15,
Claim 15 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 16,
Claim 16 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 17,
Claim 17 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 18,
Claim 18 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 19,
Claim 19 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 20,
Claim 20 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Conclusion
The prior art made of record in PTO-892 and not relied upon is considered pertinent to applicant's disclosure.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANUGEETHA KUNJITHAPATHAM whose telephone number is (408)918-7510. The examiner can normally be reached M-F 9-5 PT.
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, Aleksandr Kerzhner can be reached at (571) 270-1760. 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.
/A.K./Examiner, Art Unit 2165
/ALEKSANDR KERZHNER/Supervisory Patent Examiner, Art Unit 2165
Prosecution Insights