Prosecution Insights
Last updated: October 04, 2026
Application No. 17/867,347

QUEUE OPTIMIZATION VIA PREDICITIVE CACHING IN CLOUD COMPUTING

Final Rejection §103
Filed
Jul 18, 2022
Priority
Dec 13, 2021 — provisional 63/289,127 +2 more
Examiner
TSAI, SHENG JEN
Art Unit
2139
Tech Center
2100 — Computer Architecture & Software
Assignee
Relativity Oda LLC
OA Round
8 (Final)
70%
Grant Probability
Favorable
9-10
OA Rounds
0m
Est. Remaining
84%
With Interview

Examiner Intelligence

Grants 70% — above average
70%
Career Allowance Rate
567 granted / 805 resolved
+15.4% vs TC avg
Moderate +14% lift
Without
With
+13.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 4m
Avg Prosecution
21 currently pending
Career history
829
Total Applications
across all art units

Statute-Specific Performance

§101
2.7%
-37.3% vs TC avg
§103
54.2%
+14.2% vs TC avg
§102
26.6%
-13.4% vs TC avg
§112
13.4%
-26.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 805 resolved cases

Office Action

§103
DETAILED ACTION 1. This Office Action is taken in response to Applicants’ Amendments and Remarks filed on 7/8/2026 regarding application 17/867,347 filed on 7/18/2022. Claims 1, 3-9, 11-17, 19-23 are pending for consideration. 2. Response to Amendments and Remarks Applicants’ amendments and remarks have been fully and carefully considered, with the Examiner’s response set forth below. Applicant contends that, regarding claim 1, Anderson in view of Bi fails to teach the limitation “wherein the file path comprises a folder path,” because “Bi's "same file path" refers to multiple data blocks within a single file- not separate documents residing in the same folder. Bi does not teach identifying an additional document based on shared folder location” (see page 8 of Applicant’s Remarks). The Examiner disagrees. First, the Specification of the current Application merely recites “file path,” and never recites “folder path.” Indeed, throughout the entire Specification, only the term “file path” is repeatedly recited, and the term “folder path” is never used. The closest passage that associates “folder” with “file path” occurs at paragraph [0003] of the Specification, which recites “Many current document storage systems are file-based storage systems. As is known, broadly speaking, in file-based storage systems, documents (or data) are placed in folders. The folders are nested under other folders, thereby creating a file path for the document.” In addition, paragraphs [0032-0033] of the Specification recite “In addition, the file system protocol service 110 may maintain a directory of any or all documents in the example system 100. The directory may include a file path for each document. Thus, a file path may exist for each document in the system 100 even though the documents are stored in the object-based storage 190 according to an ID rather than a file path … The directories 225 include the file paths of the documents, and the documents are stored in the disks 235 according to the file paths (and not according to an ID as in the object-based storage 190 in the example of FIG. 1) …” Thus, a file path may be associated with a directory instead of a folder. Even if Applicant may equate a directory to be a folder, the fact remains that a single directory/folder typically includes a plurality of files organized in a multiple-level tree-like structure, and the connection that link all these files together is known as the “file path,” while the single directory/folder merely serves as the “root” of the file structure. Hence, there is a “file path,” and it does not make sense to refer the file structure as a “folder path.” Second, Anderson specifically teaches the file structure associated with a directory [… However, because the node 34 is dedicated to network and file access functions, most of the memory is used for temporary storage of data being transferred: buffers for incoming and outgoing network packets, caches of file data for both the client and server sides, and caches of file system index structures (disk allocation maps, directories, etc.) … A node (such as node 34) may have several storage devices (such as disks 32 or disks arrays) attached to it. Each storage device contains one or more "file systems" (a set of data structures on the disk that describe a set of directories and files) … (c10 L48-67)]. Third, Bi more expressively teaches prefetching files belong to the same file path [a prefetch information acquisition module configured to acquire prefetch information corresponding to at least one process to be accelerated in the procedure of operating system startup, wherein the prefetch information comprises a file path, a shift value and a length value of a data block required by the process to be accelerated … (¶ 0013-0015); Generally, a data block or a piece of data content on a low speed storage device such as a hard disk is described by the format of < file path, shift value, length value>. Taking a hard disk for example, the file path represents a file where the data block locates in the hard disk, the shift value represents the byte offset in the file where the data block locates in the hard disk and the length value represents the byte size of the data block (¶ 0041); In Table 1, since both the first data block and the second data block belong to the B.DLL file, they have the same file path. At the same time, the last byte (i.e. shift value+length value) of the first data block is followed by the first byte (i.e. shift value) of the second data block, thus the first data block and the second data block are contiguous data blocks. Length values and shift values of contiguous data blocks may be combined to obtain a new data block (¶ 0046)]. Therefore, Anderson in view of Bi teaches the limitation “wherein the file path comprises a folder path” as recited in claim 1. (2) Applicant adds a new claim 23 as an amendment. In response, a newly identified reference Kleinpeter is relined on the teach the limitations recited in claim 23. Specifically, regarding claim 23, Kleinpeter teaches the file path is maintained in a directory of file paths for documents stored in the object-based data storage [A feature of content management system 110 is the storage of content items, which can be stored in content storage 142. Content items can be any digital data such as documents, collaboration content items, text files, audio files, image files, video files, webpages, executable files, binary files, etc. A content item can also include collections or other mechanisms for grouping content items together with different behaviors, such as folders, zip files, playlists, albums, etc. A collection can refer to a folder, or a plurality of content items that are related or grouped by a common attribute … Likewise, data regarding where a content item is stored in content storage 142 can be stored in content directory 144. Additionally, data regarding changes, access, etc. can be stored in server file journal 148. Each of the various storages/databases such as content storage 142, content directory 144, server file journal 148, and metadata database 146 can be comprised of more than one such storage or database and can be distributed over many devices and locations … The location of each chunk making up a content item can be recorded in content directory 144. Content directory 144 can include a content entry for each content item stored in content storage 142. The content entry can be associated with a unique ID, which identifies a content item … Content storage service 116 can also designate or record a content path for a content item in metadata database 146. The content path can include the name of the content item and/or folder hierarchy associated with the content item. For example, the content path can include a folder or path of folders in which the content item is stored in a local file system on a client device. While content items are stored in content storage 142 in blocks and may not be stored under a tree like directory structure, such directory structure is a comfortable navigation structure for users. Content storage service 116 can define or record a content path for a content item wherein the “root” node of a directory structure can be a namespace for each account. Within the namespace can be a directory structure defined by a user of an account and/or content storage service 116. Metadata database 146 can store the content path for each content item as part of a content entry (c5 L8 to c6 L11)], and wherein the documents are stored in the object-based data storage according to an identifier rather than the file path [In some embodiments, content storage 142 is associated with at least one content storage service 116, which includes software or other processor executable instructions for managing the storage of content items including, but not limited to, receiving content items for storage, preparing content items for storage, selecting a storage location for the content item, retrieving content items from storage, etc. In some embodiments, content storage service 116 can divide a content item into smaller chunks for storage at content storage 142. The location of each chunk making up a content item can be recorded in content directory 144. Content directory 144 can include a content entry for each content item stored in conc4 L22-39)tent storage 142. The content entry can be associated with a unique ID, which identifies a content item. In some embodiments, the unique ID, which identifies a content item in content directory 144, can be derived from a deterministic hash function. This method of deriving a unique ID for a content item can ensure that content item duplicates are recognized as such since the deterministic hash function will output the same identifier for every copy of the same content item, but will output a different identifier for a different content item. Using this methodology, content storage service 116 can output a unique ID for each content item (c5 L38-61)]. In addition, Kleinpeter also teaches many limitations recited in claim 1, including files/documents on the same file path [The present technology pertains to a organization directory hosted by a synchronized content management system. The corporate directory can provide access to user accounts for all members of the organization to all content items in the organization directory on the respective file systems of the members' client devices. Members can reach any content item at the same path as other members relative to the organization directory root on their respective client device. In some embodiments novel access permissions are granted to maintain path consistency (abstract); When it is determined (812) that the first user account has access to the content item's location, content management system 110 can give the first user account access (814) to the content item at its current path. This outcome is illustrated in FIG. 30B, where the first user account is a member of the same organization as a second user account so they both have access to the organization directory. This is illustrated in FIG. 30B where the second user has added shared content item 825 in their account's directory in a folder that is not confidential. Content item 825 has been explicitly shared with the first user account by including the first user account in an access control list to perhaps designate content item 825 as confidential or perhaps read only. Since the first user account already had access to folder 356, shared content item 825 can be placed within, the first user account's directory 832 at the same path to which it is located in the second user account's directory 830 … If so, then content management system 110 can locate the shared content item 825 in the first user account's directory 832 at the same path to which it is located in the second user account's directory 830 and content management system 110 must also provide (820) traversal rights to be able to access shared content item 825 at its current path … This also maintains the condition that every user account having access to an organization directory should access the same content item at the same path (c58 L66 to c59 L45)]; the file path comprises a folder path [A feature of content management system 110 is the storage of content items, which can be stored in content storage 142. Content items can be any digital data such as documents, collaboration content items, text files, audio files, image files, video files, webpages, executable files, binary files, etc. A content item can also include collections or other mechanisms for grouping content items together with different behaviors, such as folders, zip files, playlists, albums, etc. A collection can refer to a folder, or a plurality of content items that are related or grouped by a common attribute … (c5 L8 to c6 L11)]. Therefore, Anderson in view of Bi & Kleinpeter teaches claim 23. (3) In response to the amendments and remarks, an updated claim analysis has been made with newly identified reference(s). Refer to the corresponding sections of the following Office Action for details. 3. Examiner’s Note (1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient. (2) Examiner has cited particular columns/paragraph and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. 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. 4. Claims 1, 6-9, and 14-17, and 19-21 are rejected under 35 U.S.C. 103 as being anticipated by Anderson et al. (US Patent 6,047,356, hereinafter Anderson), and in view of Bi et al. (US Patent Application Publication 2014/0129814, hereinafter Bi) As to claim 1, Anderson teaches A computer-implemented method for object-based data storage [the corresponding “object” may be “data” and/or “file” -- data storage system as shown in figure 1; A distributed file system with dedicated nodes capable of being connected to workstations at their bus. The system uses a complementary client-side and server-side file caching method that increases parallelism by issuing multiple server requests to keep the hardware devices busy simultaneously. Most of the node memory is used for file caching and input/output (I/O) device buffering using dynamic memory organization, reservation and allocation methods for competing memory-intensive activities (abstract); Bi also teaches this limitation – Described are an operating system startup acceleration method and device, a terminal and a computer readable medium. The method comprises: acquiring prefetch information corresponding to at least one process to be accelerated in a procedure of operating system startup, wherein the prefetch information comprises a file path, a shift value and a length value of a data block required by the process to be accelerated; and reading a corresponding data block into a system cache according to the acquired prefetch information, and completing a startup procedure of the process to be accelerated using the data block in the system cache (abstract)], comprising: maintaining, with one or more processors, a queue of operations relating to a plurality of documents maintained at an object-based data storage [the corresponding “documents” may be “files;” – … The present invention uses read-ahead and write-behind caching techniques for sequential rather than repetitive file access, which attempt to separate the disk or network access from the read or write steps of application programs in order to lessen the need for waiting by the application program. In read ahead, future file read access by an application is predicted and the data is read into the cache before being requested by the application. In write behind, data to be written is placed into a cache and, after the application program resumes execution, written to the disk (c1 L35-45); Write requests for the server are placed in the request queue for the appropriate device (box 216) and then an event is issued to the server task at the head of the server task queue (box 218). Read requests for the server are placed in the request queue for the appropriate device (box 220) but an event is issued (box 224) only if there is no read pending on the device (box 222) as explained below (c9 L35-42)]; identifying, with the one or more processors, a read operation in the queue to read a document from the object-based data storage [read operations as shown in figures 8, 9, and 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); A method of the present invention for caching file reads by a client from a network file server includes providing caches on both the server and the client, the server cache reading the data in mass storage device allocation units, remainders of files, or whole caches, whichever is less, and the client cache storing the data in multiples of cache blocks. Sufficient cache blocks are read ahead into the client cache to keep the server cache one mass storage device access ahead of the data currently read by the client application (c3 L18-26); A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); … Read requests for the server are placed in the request queue for the appropriate device (box 220) but an event is issued (box 224) only if there is no read pending on the device (box 222) as explained below (c9 L35-42); Bi also teaches read operation -- Described are an operating system startup acceleration method and device, a terminal and a computer readable medium. The method comprises: acquiring prefetch information corresponding to at least one process to be accelerated in a procedure of operating system startup, wherein the prefetch information comprises a file path, a shift value and a length value of a data block required by the process to be accelerated; and reading a corresponding data block into a system cache according to the acquired prefetch information, and completing a startup procedure of the process to be accelerated using the data block in the system cache (abstract)]; analyzing, with the one or more processors, the identified read operation to identify an additional document to read from the object-based data storage by identifying that the document and the additional document are included in a same file path [read operations as shown in figures 8, 9, and 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); … The present invention uses read-ahead and write-behind caching techniques for sequential rather than repetitive file access, which attempt to separate the disk or network access from the read or write steps of application programs in order to lessen the need for waiting by the application program. In read ahead, future file read access by an application is predicted and the data is read into the cache before being requested by the application. In write behind, data to be written is placed into a cache and, after the application program resumes execution, written to the disk (c1 L35-45); When the last operation was a read and a sequential read pattern has been detected, the client cache is in the read-ahead state. The cache contains a contiguous range of file data. Asynchronous "read-ahead" requests are issued for all blocks in the client cache not yet retrieved from the server to maximize performance by increasing parallelism … (c7 L67 to c8 L17); Thus, the “future file” that is predicted to be needed by the application is the corresponding “additional file” that is not associated with the read operation currently in the queue, because the “future file” is not requested by the application, and not in the queue of read requests. Therefore, Anderson clearly teaches the limitation of “additional document;” Bi more expressively teaches this limitation – a prefetch information acquisition module configured to acquire prefetch information corresponding to at least one process to be accelerated in the procedure of operating system startup, wherein the prefetch information comprises a file path, a shift value and a length value of a data block required by the process to be accelerated … (¶ 0013-0015); Generally, a data block or a piece of data content on a low speed storage device such as a hard disk is described by the format of < file path, shift value, length value>. Taking a hard disk for example, the file path represents a file where the data block locates in the hard disk, the shift value represents the byte offset in the file where the data block locates in the hard disk and the length value represents the byte size of the data block (¶ 0041); In Table 1, since both the first data block and the second data block belong to the B.DLL file, they have the same file path. At the same time, the last byte (i.e. shift value+length value) of the first data block is followed by the first byte (i.e. shift value) of the second data block, thus the first data block and the second data block are contiguous data blocks. Length values and shift values of contiguous data blocks may be combined to obtain a new data block (¶ 0046)], wherein the additional document is not associated with a read operation in the queue of operations [read operations as shown in figures 8, 9, and 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); … The present invention uses read-ahead and write-behind caching techniques for sequential rather than repetitive file access, which attempt to separate the disk or network access from the read or write steps of application programs in order to lessen the need for waiting by the application program. In read ahead, future file read access by an application is predicted and the data is read into the cache before being requested by the application. In write behind, data to be written is placed into a cache and, after the application program resumes execution, written to the disk (c1 L35-45); Bi also teaches this limitation by way of “prefetch” – Described are an operating system startup acceleration method and device, a terminal and a computer readable medium. The method comprises: acquiring prefetch information corresponding to at least one process to be accelerated in a procedure of operating system startup, wherein the prefetch information comprises a file path, a shift value and a length value of a data block required by the process to be accelerated; and reading a corresponding data block into a system cache according to the acquired prefetch information, and completing a startup procedure of the process to be accelerated using the data block in the system cache (abstract)], and wherein the file path comprises a folder path [Anderson teaches files organized in a directories/folders -- … However, because the node 34 is dedicated to network and file access functions, most of the memory is used for temporary storage of data being transferred: buffers for incoming and outgoing network packets, caches of file data for both the client and server sides, and caches of file system index structures (disk allocation maps, directories, etc.) … A node (such as node 34) may have several storage devices (such as disks 32 or disks arrays) attached to it. Each storage device contains one or more "file systems" (a set of data structures on the disk that describe a set of directories and files) … (c10 L48-67); Bi teaches that the files are DLL files, and it is a fact that DLL files are organize in a folder – Taking a Windows operating system for example, when system services and third party applications are started, each of the system services and third party applications generally correspond to a process. Basically, each process needs to load an executable file (executable file) and a Dynamic Link Library (DLL) file. When a process loads an executable file and a DLL file, it uses a memory mapping file to access the executable file and the DLL file (¶ 0032); To facilitate explanation, shift values and length values of three data blocks in a B.DLL file required by a process A are illustrated in Table 1: … In Table 1, since both the first data block and the second data block belong to the B.DLL file, they have the same file path. At the same time, the last byte (i.e. shift value+length value) of the first data block is followed by the first byte (i.e. shift value) of the second data block, thus the first data block and the second data block are contiguous data blocks. Length values and shift values of contiguous data blocks may be combined to obtain a new data block (¶ 0043-0046); Ono explicitly teaches that DLL files are organized in a folder -- A folder list box 213 is displayed when one of the change buttons 196 (discussed above with reference to FIG. 7) is clicked on. The folder list box 213 shows a list of folders such as dll files constituting effect plug-ins in the corresponding text box that indicates a list of available effect plug-ins. The user may click on an add button 214 to add a new folder to the folder list box 213; the user may also click on a delete button 215 to delete a desired folder from the folder list box 213. Any of the folders such as dll files constituting the effect plug-ins in the folder list box 213, when set as described, is not copied illustratively to a program execution area in the RAM 36 but merely assigned a file path (¶ 0097)]; in response to the identification of the additional document to read from the object-based data storage by identifying that the document and the additional document are included in a same file path [read operations as shown in figures 8, 9, and 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); … The present invention uses read-ahead and write-behind caching techniques for sequential rather than repetitive file access, which attempt to separate the disk or network access from the read or write steps of application programs in order to lessen the need for waiting by the application program. In read ahead, future file read access by an application is predicted and the data is read into the cache before being requested by the application. In write behind, data to be written is placed into a cache and, after the application program resumes execution, written to the disk (c1 L35-45); When the last operation was a read and a sequential read pattern has been detected, the client cache is in the read-ahead state. The cache contains a contiguous range of file data. Asynchronous "read-ahead" requests are issued for all blocks in the client cache not yet retrieved from the server to maximize performance by increasing parallelism … (c7 L67 to c8 L17); Thus, the “future file” that is predicted to be needed by the application is the corresponding “additional file” that is not associated with the read operation currently in the queue, because the “future file” is not requested by the application, and not in the queue of read requests. Therefore, Anderson clearly teaches the cited limitation; Bi more expressively teaches this limitation – a prefetch information acquisition module configured to acquire prefetch information corresponding to at least one process to be accelerated in the procedure of operating system startup, wherein the prefetch information comprises a file path, a shift value and a length value of a data block required by the process to be accelerated … (¶ 0013-0015); Generally, a data block or a piece of data content on a low speed storage device such as a hard disk is described by the format of < file path, shift value, length value>. Taking a hard disk for example, the file path represents a file where the data block locates in the hard disk, the shift value represents the byte offset in the file where the data block locates in the hard disk and the length value represents the byte size of the data block (¶ 0041); In Table 1, since both the first data block and the second data block belong to the B.DLL file, they have the same file path. At the same time, the last byte (i.e. shift value+length value) of the first data block is followed by the first byte (i.e. shift value) of the second data block, thus the first data block and the second data block are contiguous data blocks. Length values and shift values of contiguous data blocks may be combined to obtain a new data block (¶ 0046)]; creating, with the one or more processors, a read operation for the additional document [as shown in figure 8, steps 126, 128, 132, 136, 142, 130, 144, 146, and 152; When the last operation was a read and a sequential read pattern has been detected, the client cache is in the read-ahead state. The cache contains a contiguous range of file data. Asynchronous "read-ahead" requests are issued for all blocks in the client cache not yet retrieved from the server to maximize performance by increasing parallelism … (c7 L67 to c8 L17); The host read request is handled as shown in the flow chart of FIG. 8 using the network protocol diagram of FIG. 10A … If a sequential read is detected, the cache is set to sequential read status (box 128). The first block (if not already in the cache) and the appropriate number (as discussed above) of subsequent blocks are requested (box 132) … Otherwise, the block is deleted and the next block not yet in the cache is requested (box 144) … (c10 L23-47); … determining whether said first read request is part of a sequential pattern of read requests; if said first read request is part of a sequential pattern of read requests and said first block of file data is not in said first cache area of said general purpose cache memory, reading a range of blocks beginning with said first block of file data into said first cache area from said local mass storage device … (claim 5); Bi also teaches read operation -- Described are an operating system startup acceleration method and device, a terminal and a computer readable medium. The method comprises: acquiring prefetch information corresponding to at least one process to be accelerated in a procedure of operating system startup, wherein the prefetch information comprises a file path, a shift value and a length value of a data block required by the process to be accelerated; and reading a corresponding data block into a system cache according to the acquired prefetch information, and completing a startup procedure of the process to be accelerated using the data block in the system cache (abstract)]; retrieving, with the one or more processors, both the document and the additional document from the object-based data storage [read operations as shown in figures 8, 9, and 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); … The present invention uses read-ahead and write-behind caching techniques for sequential rather than repetitive file access, which attempt to separate the disk or network access from the read or write steps of application programs in order to lessen the need for waiting by the application program. In read ahead, future file read access by an application is predicted and the data is read into the cache before being requested by the application. In write behind, data to be written is placed into a cache and, after the application program resumes execution, written to the disk (c1 L35-45); Bi more also teaches this limitation – a prefetch information acquisition module configured to acquire prefetch information corresponding to at least one process to be accelerated in the procedure of operating system startup, wherein the prefetch information comprises a file path, a shift value and a length value of a data block required by the process to be accelerated … (¶ 0013-0015); Generally, a data block or a piece of data content on a low speed storage device such as a hard disk is described by the format of < file path, shift value, length value>. Taking a hard disk for example, the file path represents a file where the data block locates in the hard disk, the shift value represents the byte offset in the file where the data block locates in the hard disk and the length value represents the byte size of the data block (¶ 0041); In Table 1, since both the first data block and the second data block belong to the B.DLL file, they have the same file path. At the same time, the last byte (i.e. shift value+length value) of the first data block is followed by the first byte (i.e. shift value) of the second data block, thus the first data block and the second data block are contiguous data blocks. Length values and shift values of contiguous data blocks may be combined to obtain a new data block (¶ 0046)]; and storing, with the one or more processors, the document and the additional document in a cache memory [read operations as shown in figures 8, 9, and 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); … The present invention uses read-ahead and write-behind caching techniques for sequential rather than repetitive file access, which attempt to separate the disk or network access from the read or write steps of application programs in order to lessen the need for waiting by the application program. In read ahead, future file read access by an application is predicted and the data is read into the cache before being requested by the application. In write behind, data to be written is placed into a cache and, after the application program resumes execution, written to the disk (c1 L35-45); Bi also teaches read operation -- Described are an operating system startup acceleration method and device, a terminal and a computer readable medium. The method comprises: acquiring prefetch information corresponding to at least one process to be accelerated in a procedure of operating system startup, wherein the prefetch information comprises a file path, a shift value and a length value of a data block required by the process to be accelerated; and reading a corresponding data block into a system cache according to the acquired prefetch information, and completing a startup procedure of the process to be accelerated using the data block in the system cache (abstract)]. Regarding claim 1, Anderson does not expressively teach the document and the additional document are included in a same file path However, files that are related and associated with each other are typically stored in the same file path under a folder/directory to facilitate efficient retrieval and accessing. For example, Bi specifically teaches DLL files to be prefetched are organized in the same file path [Generally, a data block or a piece of data content on a low speed storage device such as a hard disk is described by the format of < file path, shift value, length value>. Taking a hard disk for example, the file path represents a file where the data block locates in the hard disk, the shift value represents the byte offset in the file where the data block locates in the hard disk and the length value represents the byte size of the data block (¶ 0041); In Table 1, since both the first data block and the second data block belong to the B.DLL file, they have the same file path. At the same time, the last byte (i.e. shift value+length value) of the first data block is followed by the first byte (i.e. shift value) of the second data block, thus the first data block and the second data block are contiguous data blocks. Length values and shift values of contiguous data blocks may be combined to obtain a new data block (¶ 0046)]. Therefore, it would have been obvious for one of ordinary skills in the art before the effective filing date of the claimed invention to store files that are related and associated with each other in the same file path under a folder/directory, as demonstrated by Bi, and to incorporate it into the existing scheme disclosed by Anderson, in order to facilitate efficient retrieval and accessing. It is also noted that, although Bi does not explicitly mention that the DLL files are organized in a folder/directory structure, it is a fact that DLL files are organized in a folder/directory structure, as demonstrated by the Ono reference. As to claim 6, Anderson in view of Bi teaches The computer-implemented method of claim 1, wherein: the read operation is comprised in a plurality of read operations in the queue; and the identifying the additional document to read from the object-based data storage to the cache memory comprises analyzing the plurality of read operations to identify the additional document [Anderson -- read operations as shown in figures 8, 9, and 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); … The present invention uses read-ahead and write-behind caching techniques for sequential rather than repetitive file access, which attempt to separate the disk or network access from the read or write steps of application programs in order to lessen the need for waiting by the application program. In read ahead, future file read access by an application is predicted and the data is read into the cache before being requested by the application. In write behind, data to be written is placed into a cache and, after the application program resumes execution, written to the disk (c1 L35-45)]. As to claim 7, Anderson in view of Bi teaches The computer-implemented method of claim 1, further comprising: subsequent to the storing of the additional document in the cache memory, detecting, with the one or more processors, a read operation in the queue of operations associated with the additional document; and providing, with the one or more processors, the additional document from the cache memory and without sending an additional retrieve transaction to the object- based data storage [Anderson -- read operations as shown in figures 8, 9, and 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); … The present invention uses read-ahead and write-behind caching techniques for sequential rather than repetitive file access, which attempt to separate the disk or network access from the read or write steps of application programs in order to lessen the need for waiting by the application program. In read ahead, future file read access by an application is predicted and the data is read into the cache before being requested by the application. In write behind, data to be written is placed into a cache and, after the application program resumes execution, written to the disk (c1 L35-45)]. As to claim 8, Anderson in view of Bi teaches The computer-implemented method of claim 1, further comprising slicing the documents maintained at the object-based storage into individual slices, and wherein each individual slice of the individual slices has a memory size of less than a predetermined individual slice memory size [Anderson -- the corresponding “slices” may be the “blocks” of the file -- read operations as shown in figures 8, 9, and 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); Client cache sizes are determined as follows. One soft reservation is made, equal to the sum of the ideal size is of all client caches. When the soft reservation is fully granted, the actual size of each client cache is its ideal size. If, however, the soft reservation request is not fully granted, the memory is divided among client caches in proportion to the predicted data rate of client access to each open file. This rate may be calculated periodically by the custodian task running on the node and described in greater detail below. In the preferred embodiment, this rate is computed as an exponentially weighted average of the number of bytes transferred in fixed periods of time. This average is calculated by adding one-half the previous average and one-half the number of bytes transferred during the latest time period. Other prediction techniques are possible without departing from the scope of the present invention … (c8 L24-57)]. As to claim 9, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to “As to claim 1” presented earlier in this Office Action for details. As to claim 14, it recites substantially the same limitations as in claim 6, and is rejected for the same reasons set forth in the analysis of claim 6. Refer to “As to claim 6” presented earlier in this Office Action for details. As to claim 15, it recites substantially the same limitations as in claim 7, and is rejected for the same reasons set forth in the analysis of claim 7. Refer to “As to claim 7” presented earlier in this Office Action for details. As to claim 16, it recites substantially the same limitations as in claim 8, and is rejected for the same reasons set forth in the analysis of claim 8. Refer to “As to claim 8” presented earlier in this Office Action for details. As to claim 17, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to “As to claim 1” presented earlier in this Office Action for details. As to claim 19, it recites substantially the same limitations as in claim 6, and is rejected for the same reasons set forth in the analysis of claim 6. Refer to “As to claim 6” presented earlier in this Office Action for details. As to claim 20, Anderson in view of Bi teaches The one or more non-transitory computer readable media of claim 19, wherein: the retrieval of the document from the object-based storage comprises retrieving an initial document fragment for the document; and the storing of the document in the cache memory comprises storing the initial document fragment for the document in the cache memory without storing a subsequent document fragment in the cache memory [Anderson -- A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); In the empty state, a client cache contains no data. Its ideal, maximum and actual sizes are zero. A client cache is in this state initially, and whenever memory allocation has reduced its allocated size to zero (c7 L54-57)]. As to claim 21, Anderson in view of Bi teaches The one or more non-transitory computer readable media of claim 17, wherein: the read operation is comprised in a plurality of read operations in the queue [Anderson -- A distributed file system with dedicated nodes capable of being connected to workstations at their bus. The system uses a complementary client-side and server-side file caching method that increases parallelism by issuing multiple server requests to keep the hardware devices busy simultaneously. Most of the node memory is used for file caching and input/output (I/O) device buffering using dynamic memory organization, reservation and allocation methods for competing memory-intensive activities (abstract); Distributed file systems include network nodes, which are computer systems attached directly to a network. Each network node has a processor, random-access memory (RAM), and an interface to a communication network. Nodes that are able to act as "servers" are interfaced to mass storage devices such as disk drives. The mass storage devices are usually partitioned in allocation units and data is read from or written to the device in multiples of sectors up to one allocation unit. In an access to a file on a given disk, the network node where the disk is located is called the "server" and the node from which the request was issued is called the "client." In a read access, data flows from the server to the client; in a write access, data flows from the client to the server … (c1 L10-25); … Read requests for the server are placed in the request queue for the appropriate device (box 220) but an event is issued (box 224) only if there is no read pending on the device (box 222) as explained below (c9 L35-42)]; and the instructions, when executed by one or more processors, further cause the one or more processors to limit a quantity of additional documents that may be loaded into the cache memory to a predetermined number across the plurality of read operations [Anderson -- A memory reservation method of the present invention includes specifying a minimum and a maximum amount of memory to be reserved for an activity. If enough memory is available, an amount of memory between the minimum and the maximum is reserved for the activity. For each activity for which memory has been reserved, the amount of memory reserved is dynamically adjusted between the minimum and the maximum such that the sum of all reservations is less than or equal to the memory available (c2 L48-57); Node 34 receives a sequence of client file access requests from host 24. The requests could also originate from the node itself without departing from the scope of the present invention. The types of requests include: 1) open a particular local or remote file; 2) read a range of bytes from an open local or remote file into a memory cache in the node … (c4 L44-55); The DMS 54 has separate notions of "reservation" and "allocation." An activity can reserve some number of buffers; this does not allocate specific buffers, but ensures that a subsequent allocation request will succeed. In FIG. 2, the DMS 54 arbitrates conflicting memory reservations by activities 50, 52 and 53. The DMS 54 provides two types of memory reservation. An activity makes a "hard" reservation for its minimal memory requirement. A hard reservation request specifies a number of buffers, and either succeeds or fails … In addition, an activity can make a "soft" reservation request, in which it specifies the maximum number of buffers it can use … (c5 L35-67 and c6 L1-44); When the last operation was a read and a sequential read pattern has been detected, the client cache is in the read-ahead state … For a given open file, the optimal number N of parallel requests depends on the client cache block size X, the disk allocation unit size Y, the average network latency Z, and the network bandwidth B … Thus the ideal size of a read-ahead cache is N as defined above. The maximum arid actual sizes depend on memory allocation (c7 L66 to c8 L17)]. 5. Claims 3-5, and 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson in view of Bi, and further in view of Ivonkovic et al. (US Patent Application Publication 2021/0132915, hereinafter Ivonkovic). As to claim 3, Anderson in view of Bi teaches The computer-implemented method of claim 1, wherein the analyzing the read operation identified in the queue comprises analyzing the read operation relating to the document with a machine learning algorithm trained by a plurality of documents maintained at the object-based data storage [Anderson -- Client cache sizes are determined as follows. One soft reservation is made, equal to the sum of the ideal size is of all client caches. When the soft reservation is fully granted, the actual size of each client cache is its ideal size. If, however, the soft reservation request is not fully granted, the memory is divided among client caches in proportion to the predicted data rate of client access to each open file. This rate may be calculated periodically by the custodian task running on the node and described in greater detail below. In the preferred embodiment, this rate is computed as an exponentially weighted average of the number of bytes transferred in fixed periods of time. This average is calculated by adding one-half the previous average and one-half the number of bytes transferred during the latest time period. Other prediction techniques are possible without departing from the scope of the present invention … (c8 L24-57)]. Regarding claim 3, Anderson in view of Bi does not expressively mention the term “machine learning algorithms.” However, Anderson does teach a computer mode updating the weighted time-average to predict data rate of client access to each open file [… the memory is divided among client caches in proportion to the predicted data rate of client access to each open file. This rate may be calculated periodically by the custodian task running on the node and described in greater detail below. In the preferred embodiment, this rate is computed as an exponentially weighted average of the number of bytes transferred in fixed periods of time. This average is calculated by adding one-half the previous average and one-half the number of bytes transferred during the latest time period. Other prediction techniques are possible without departing from the scope of the present invention … (c8 L24-57)]. This represents one type of machine learning algorithm because the parameters are updated by the computer as time goes by. Further, machine learning algorithms are well known and commonly used in the art. For example, Ivonkovic specifically teaches using machine learning algorithms to select a target in a vector space [The target source code may include a pair of target source code snippets from a target codebase and generating the code insight for the target source code using the machine learning model may include, for each target source code snippet in the pair of target source code snippets, generating a vector representation for the corresponding target source code snippet using the machine learning model configured to receive a set of target features extracted from the corresponding target source code snippet as feature inputs, determining a vector-space distance between the pair of target source code snippets based on the vector representation, and determining the pair of target source code snippets are duplicates of one another when the vector-space distance satisfies a distance threshold. The predicted label for the training source code may include at least one of a predicted level of complexity of the target source code, a predicted quality of the target source code, a predicted testing requirement for the target source code, or a predicted difficulty rating of the target source code. The predicted code transformation for the target source code may include at least one of updated target source code fixing a build error in the target source code, executable code for the target source code, a revision to the target source code, or suggested replacement source code for replacing the target source code (¶ 0008)]. Therefore, it would have been obvious for one of ordinary skills in the art before the effective filing date of the claimed invention to use a machine learning algorithm to select a desired target, as demonstrated by Ivonkovic, and to incorporate it into the existing scheme disclosed by Anderson in view of Bi, because Anderson’s weighted time-average updating and prediction model by itself is already a preliminary form of machine learning algorithm, which may be further extended and enhanced for better performance. As to claim 4, Anderson in view of Bi & Ivonkovic teaches The computer-implemented method of claim 3, wherein the additional document is identified based upon a distance to the document in a vector space defined by the machine learning algorithm [Ivonkovic -- The target source code may include a pair of target source code snippets from a target codebase and generating the code insight for the target source code using the machine learning model may include, for each target source code snippet in the pair of target source code snippets, generating a vector representation for the corresponding target source code snippet using the machine learning model configured to receive a set of target features extracted from the corresponding target source code snippet as feature inputs, determining a vector-space distance between the pair of target source code snippets based on the vector representation, and determining the pair of target source code snippets are duplicates of one another when the vector-space distance satisfies a distance threshold. The predicted label for the training source code may include at least one of a predicted level of complexity of the target source code, a predicted quality of the target source code, a predicted testing requirement for the target source code, or a predicted difficulty rating of the target source code. The predicted code transformation for the target source code may include at least one of updated target source code fixing a build error in the target source code, executable code for the target source code, a revision to the target source code, or suggested replacement source code for replacing the target source code (¶ 0008)]. As to claim 5, Anderson in view of Bi & Ivonkovic teaches The computer-implemented method of claim 1, wherein the document is associated with a la bel and the additional document is associated with the same label [Anderson – as shown in figure 10A; A method for file read caching of the present invention on the client or server side includes verifying that the cache blocks are a range of blocks contiguous in the file and beginning with the required cache block, and, if the full range of blocks are not in the cache, reading the missing blocks into the cache. The read request may be served before or after any missing blocks are read into the cache depending on whether the requested data is initially available in cache (c2 L58-65); The client handler task maintains a "client cache" in RAM 40 for each open file. Each client cache stores a contiguous range of data from that file. Each cache is divided into non-overlapping "client cache" blocks. These blocks are typically of a constant size, but need not be. Each client cache is in one of the following four states: empty, read, read-ahead, and write. Each client cache has an "ideal size" (depending only on its state), a "maximum size" (depending on the memory management decisions) and an "actual size" (the number of cache blocks in memory) (c7 L26-35); In a distributed file system including high speed random access general purpose memory within a network node coupled to a host computer and a plurality of mass storage devices interconnected via a network for storing data files in disparate locations … allocating, by means of a processor within said network node, a portion of said general purpose memory to said at least one cache area in an amount proportional to said associated file data flow rate (claim 1)]. As to claim 11, it recites substantially the same limitations as in claim 3, and is rejected for the same reasons set forth in the analysis of claim 3. Refer to “As to claim 3” presented earlier in this Office Action for details. As to claim 12, it recites substantially the same limitations as in claim 4, and is rejected for the same reasons set forth in the analysis of claim 4. Refer to “As to claim 4” presented earlier in this Office Action for details. As to claim 13, it recites substantially the same limitations as in claim 5, and is rejected for the same reasons set forth in the analysis of claim 5. Refer to “As to claim 5” presented earlier in this Office Action for details. 6. Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Anderson in view of Bi, and further in view of Esser et al. (US Patent Application Publication 2018/0060238, hereinafter Esser). Regarding claim 22, Anderson in view of Bi does not teach a threshold controls a number of additional documents identified by the one or more processors, and wherein the threshold varies based on an age of a document previously predictively loaded into the cache memory. However, Esser specifically teaches the cited limitation [Referring to FIG. 1, dynamic cache sizing operation 100 in accordance with one embodiment may obtain or determine one or more cache operating parameters (block 105). Illustrative cache operating parameters include, but are not limited by, cache line eviction rate (i.e., the rate at which cache lines are being removed from the cache in accordance with a specified cache line replacement algorithm) and cache line age (i.e., how long a cache line has been in the cache) … One illustrative resizing test could be whether a first threshold number of cache lines are older than a first specified age (suggesting the cache may be larger than it needs to be). Another illustrative resizing test could be whether a second threshold number of cache lines are younger than a second specified age (suggesting the cache may be smaller than it needs to be). Yet another illustrative resizing test could be whether a third threshold percent of cache lines are older than a third specified age. Still another illustrative resizing test could be whether a fourth threshold percent of cache lines are younger than a fourth specified age … (¶ 0014); First, as Applicant admits, Esser specifically teaches “dynamically resizing cache memory,” and it is a matter of fact that the more additional documents to be stored in the cache memory, the more space would be needed for the cache memory. Thus, the number of additional documents that can be stored in the cache memory is directly proportional to the size of the cache memory, which is the essence of Esser’s “dynamically resizing cache memory.” Second, claim 22 recites “the threshold varies based on an age of a document previously predictively loaded into the cache memory,” and Applicant readily admits that “Esser is directed to dynamically resizing cache memory based on cache line age,” Thus Esser indeed teaches the aspect “the threshold varies based on an age of a document previously predictively loaded into the cache memory,” because the cache lines to be evicted from the cache memory depends on the age limit of the cache lines, which in turn determines how much space may be reclaimed for reuse by evicting those cache lines older than a certain age limit. Therefore, Esser clearly teaches the limitations recited in claim 22]. Therefore, it would have been obvious for one of ordinary skills in the art before the effective filing date of the claimed invention to have a threshold controls a number of additional documents identified by the one or more processors, and wherein the threshold varies based on an age of a document previously predictively loaded into the cache memory, as specifically demonstrated by Esser, and to incorporate it into the existing scheme disclosed by Anderson in view of Bi, in order to properly adjust the size of the cache memory. 7. Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Anderson in view of Bi, and further in view of Kleinpeter et al. (US Patent 10,037,339, hereinafter Kleinpeter). Regarding claim 23, Anderson in view of Bi does not teach the file path is maintained in a directory of file paths for documents stored in the object-based data storage, and wherein the documents are stored in the object-based data storage according to an identifier rather than the file path. However, Kleinpeter specifically teaches the file path is maintained in a directory of file paths for documents stored in the object-based data storage [A feature of content management system 110 is the storage of content items, which can be stored in content storage 142. Content items can be any digital data such as documents, collaboration content items, text files, audio files, image files, video files, webpages, executable files, binary files, etc. A content item can also include collections or other mechanisms for grouping content items together with different behaviors, such as folders, zip files, playlists, albums, etc. A collection can refer to a folder, or a plurality of content items that are related or grouped by a common attribute … Likewise, data regarding where a content item is stored in content storage 142 can be stored in content directory 144. Additionally, data regarding changes, access, etc. can be stored in server file journal 148. Each of the various storages/databases such as content storage 142, content directory 144, server file journal 148, and metadata database 146 can be comprised of more than one such storage or database and can be distributed over many devices and locations … The location of each chunk making up a content item can be recorded in content directory 144. Content directory 144 can include a content entry for each content item stored in content storage 142. The content entry can be associated with a unique ID, which identifies a content item … Content storage service 116 can also designate or record a content path for a content item in metadata database 146. The content path can include the name of the content item and/or folder hierarchy associated with the content item. For example, the content path can include a folder or path of folders in which the content item is stored in a local file system on a client device. While content items are stored in content storage 142 in blocks and may not be stored under a tree like directory structure, such directory structure is a comfortable navigation structure for users. Content storage service 116 can define or record a content path for a content item wherein the “root” node of a directory structure can be a namespace for each account. Within the namespace can be a directory structure defined by a user of an account and/or content storage service 116. Metadata database 146 can store the content path for each content item as part of a content entry (c5 L8 to c6 L11)], and wherein the documents are stored in the object-based data storage according to an identifier rather than the file path [In some embodiments, content storage 142 is associated with at least one content storage service 116, which includes software or other processor executable instructions for managing the storage of content items including, but not limited to, receiving content items for storage, preparing content items for storage, selecting a storage location for the content item, retrieving content items from storage, etc. In some embodiments, content storage service 116 can divide a content item into smaller chunks for storage at content storage 142. The location of each chunk making up a content item can be recorded in content directory 144. Content directory 144 can include a content entry for each content item stored in conc4 L22-39)tent storage 142. The content entry can be associated with a unique ID, which identifies a content item. In some embodiments, the unique ID, which identifies a content item in content directory 144, can be derived from a deterministic hash function. This method of deriving a unique ID for a content item can ensure that content item duplicates are recognized as such since the deterministic hash function will output the same identifier for every copy of the same content item, but will output a different identifier for a different content item. Using this methodology, content storage service 116 can output a unique ID for each content item (c5 L38-61)]. In addition, Kleinpeter also teaches many limitations recited in claim 1, including files/documents on the same file path [The present technology pertains to a organization directory hosted by a synchronized content management system. The corporate directory can provide access to user accounts for all members of the organization to all content items in the organization directory on the respective file systems of the members' client devices. Members can reach any content item at the same path as other members relative to the organization directory root on their respective client device. In some embodiments novel access permissions are granted to maintain path consistency (abstract); When it is determined (812) that the first user account has access to the content item's location, content management system 110 can give the first user account access (814) to the content item at its current path. This outcome is illustrated in FIG. 30B, where the first user account is a member of the same organization as a second user account so they both have access to the organization directory. This is illustrated in FIG. 30B where the second user has added shared content item 825 in their account's directory in a folder that is not confidential. Content item 825 has been explicitly shared with the first user account by including the first user account in an access control list to perhaps designate content item 825 as confidential or perhaps read only. Since the first user account already had access to folder 356, shared content item 825 can be placed within, the first user account's directory 832 at the same path to which it is located in the second user account's directory 830 … If so, then content management system 110 can locate the shared content item 825 in the first user account's directory 832 at the same path to which it is located in the second user account's directory 830 and content management system 110 must also provide (820) traversal rights to be able to access shared content item 825 at its current path … This also maintains the condition that every user account having access to an organization directory should access the same content item at the same path (c58 L66 to c59 L45)]; the file path comprises a folder path [A feature of content management system 110 is the storage of content items, which can be stored in content storage 142. Content items can be any digital data such as documents, collaboration content items, text files, audio files, image files, video files, webpages, executable files, binary files, etc. A content item can also include collections or other mechanisms for grouping content items together with different behaviors, such as folders, zip files, playlists, albums, etc. A collection can refer to a folder, or a plurality of content items that are related or grouped by a common attribute … (c5 L8 to c6 L11)]. Therefore, it would have been obvious for one of ordinary skills in the art before the effective filing date of the claimed invention to have a file path is maintained in a directory of file paths for documents stored in the object-based data storage, and wherein the documents are stored in the object-based data storage according to an identifier rather than the file path, as specifically demonstrated by Kleinpeter, and to incorporate it into the existing scheme disclosed by Anderson in view of Bi, because Kleinpeter teaches doing so allows files/folders/directories be synchronized between cloud storage management and users [One modern storage paradigm utilizes a synchronized content management system that offers services such as synchronizing copies of content items locally onto a client computer, sharing outside of an organization, and more. However, the additional features offered by the synchronized content management system create a great number of technical challenges to safely store all of an organization's content items while maintaining appropriate rights management (c1 L30-38)].. Conclusion 8. Claims 1, 3-9, 11-17, 19-23 are rejected as explained above. 9. 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. 10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHENG JEN TSAI whose telephone number is 571-272-4244. The examiner can normally be reached on Monday-Friday, 9-6. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Reginald Bragdon can be reached on 571-272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). /SHENG JEN TSAI/Primary Examiner, Art Unit 2136
Read full office action

Prosecution Timeline

Show 16 earlier events
Mar 04, 2026
Examiner Interview Summary
Mar 04, 2026
Applicant Interview (Telephonic)
Mar 09, 2026
Request for Continued Examination
Mar 14, 2026
Response after Non-Final Action
Apr 08, 2026
Non-Final Rejection mailed — §103
Jun 25, 2026
Interview Requested
Jul 08, 2026
Response Filed
Sep 16, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12730723
SELECTIVE PROCESSING OF FILE SYSTEM OBJECTS FOR IMAGE LEVEL BACKUPS
3y 0m to grant Granted Sep 08, 2026
Patent 12730578
DATA MIGRATION AND ASYNCHRONOUS REPLICATION WITH TRUSTWORTHY ENERGY AWARENESS
2y 7m to grant Granted Sep 08, 2026
Patent 12705184
USING RETIRED PAGES HISTORY FOR INSTRUCTION TRANSLATION LOOKASIDE BUFFER (TLB) PREFETCHING IN PROCESSOR-BASED DEVICES
2y 4m to grant Granted Aug 11, 2026
Patent 12670072
LOW IMPACT MIGRATION OF LARGE DATA TO CLOUD AND VIRTUALIZED ENVIRONMENTS
3y 0m to grant Granted Jun 30, 2026
Patent 12656954
COMPUTE EXPRESS LINK DRAM + NAND SYSTEM SOLUTION
2y 3m to grant Granted Jun 16, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

9-10
Expected OA Rounds
70%
Grant Probability
84%
With Interview (+13.8%)
3y 4m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 805 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month