DETAILED ACTION
This Action is responsive to the RCE filed on 07/28/2026.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/28/2026 has been entered.
Claim Status
Claims 1-25 are amended. Claims 1-25 are pending and have been examined.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 6-7, 17, and 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over Gold et al. (US 20230126789 A1)(cited by examiner in previous action)(hereafter referred to as Gold) further in view of Shah et al. (US 20210055869 A1)(hereafter referred to as Shah).
Regarding Claim 1,
Gold discloses the following limitations:
A memory system (Figs. 3B + 7), comprising:
one or more components (Processing Resources 416-420 + Storage Devices 430-434, Fig. 7 // Fig. 3B // ¶¶0159; 0175) configured to:
store (Fig. 7, step 410) a dataset (Dataset 404, Fig. 5) in a portion of a fabric-attached memory (Storage Devices 430-434, Fig. 7 // “NVMe over fabrics” [0125] // “storing (410) the dataset (404) within the storage system (406)” [0179]) -- As shown in Fig. 7, a dataset 404, is written to shared storage resources 430-434 for examination by analytics application 422--,
wherein the dataset is stored in a format (“an indexed directory structure” [0176] // ¶0123) that enables analysis of the dataset by multiple host devices (Processing Resources 416-420, Fig. 7) associated with a distributed workflow (“a big data analytics pipeline” [0175] // Fig. 7) without requiring the multiple host devices to copy the dataset to local memory(Fig. 7 // “storing (410) the dataset (404) within the storage system (406) can include organizing (708) the data into an indexed directory structure” [0176] // “Readers will appreciate that, because the dataset (404) is stored within shared storage, the analytics application (422) does not need to retain a copy of the dataset in storage … that is only accessible by the processing resources which are being used to execute the analytics application (422).” [0166] // ¶0175) – As disclosed in ¶0175, analytics applications executing on processing resources 416-420 “ingest” and examine the dataset 404 in order to make conclusions about a data producer. As taught in ¶0166, dataset 404 is stored in shared storage (in an “indexed directory structure” type of “format”; see ¶0176) which enables analytics applications to examine the dataset 404 without first requiring local storage of the dataset --; and
establish a respective direct access connection (“implement a remote direct memory access (RDMA) protocol over converged ethernet (RoCE) fabric” [0209]) to the portion of the fabric-attached memory with each host device of the multiple host devices associated with the distributed workflow(“The storage system 306 … includes communication resources 310 that may be useful in facilitating data communications between components within the storage system 306 … The communication resources 310 can also include … NVMe over fabrics (‘NVMeoF’) technologies through which non-volatile storage media attached via a PCI express (‘PCIe’) bus may be accessed” [0125] // ¶¶0159; 0204; 0209) – As disclosed in ¶0125, components within storage system 406 communicate using NVMeoF technology which enables access to non-volatile storage via a PCIe bus. As clarified in ¶0209, such communication can be implemented using an established RDMA protocol over a fabric. Examiner accordingly considers configuring a storage system, such as storage system 406 of Fig. 7, using the aforementioned NVMeoF resources and RDMA protocols as “establish[ing] a respective direct access connection” between each application executing on a processing resource and each storage device storing the dataset--,
wherein the fabric-attached memory is exposed as … files to support the multiple host devices to mount a same file system from the fabric-attached memory, (“The storage system 306 depicted in FIG. 3B may implement a variety of storage architectures … Storage systems in accordance with some embodiments of the present disclosure utilize file storage in which data is stored in a hierarchical structure. Such data may be saved in files and folders, and presented to both the system storing it and the system accessing retrieving it in the same format” [0123] // “the indexed file system may essentially be used as a database that can be quickly searched” [0176]) – Data is organized within an indexed file system (i.e., is “exposed as” “files”) presented to each accessing system (e.g., processing resources 416-420) “in the same format”. Accordingly, each processing resource in the system is presented a same file system format for accessing the dataset 404 (i.e., “mount[s] a same file system” from storage devices 430-434--, and
wherein the direct access connections enable each host device, of the multiple host devices, to access the dataset (“reading their respective portions of the dataset” [0170]) via the respective direct access connection (¶0125) and by using a zero-copy access technique that does not require the host device copy the dataset to a local memory (¶0166) to extract (Fig. 7, step 414) a batch of data objects (¶0123) from the dataset for performing a computation (“examines datasets” [0168]) associated with the distributed workflow (“executing (414) the analytics application (422) on the processing resources (416), including ingesting the dataset (404) from the storage system” [0175] // “In fact, the analytics application (422) and the real-time analytics application (506) may be reading their respective portions of the dataset (404) from a single copy of the dataset (404) that is stored within the storage system (406)” [0170]) – As shown in Fig. 7, analytics application 422 ingests (i.e., “extract[s]”) respective portions of dataset 404 (i.e., “a batch of data objects”; see ¶0170) without needing to first copy the entire dataset 404 into a local memory (see ¶0166). As disclosed in ¶0170, an analytics application operating on a processing resource 416 accesses the same dataset 404 stored within storage devices 430-434 as compared to other applications operating on other processing resources (e.g., a processing resource 418). As clarified in ¶0168, analytics applications examine and transform data in order to make a conclusion about the data.
Gold does not explicitly disclose a “memory-mappable” type of file into which dataset 404 is organized and thus does not explicitly disclose the following limitations:
the fabric-attached memory is exposed as memory-mappable files
However, Shah discloses the following limitations:
the fabric-attached memory (NVM 130, Fig. 1) is exposed as memory-mappable files (“a memory mapped file” [0046])(“Memory mapping a file (e.g., file 132) for access by an application (e.g., transaction processor 140) may involve file manager 132 … mapping a file e.g., using … mmap() … from address space in storage device 180 or NVM 130 to address space exposed to an application’s virtual address space. Server computer 102 may use memory mapping and direct access (DAX) to access data stored in NVM 130. A memory mapped file in NVM 130 may be treated as byte addressable storage. DAX may eliminate copying file 132 to page cache (e.g., local memory 115) by enabling direct read and write access to files (e.g., file 132) stored in NVM 130.” [0046] // “Transaction processor 140 may be responsive to requests (e.g., from applications (not shown) on client computer(s) 150)” [0037] // Fig. 1) – Examiner considers Client Computer 150 and NVM 130 depicted in the system of Shah Fig. 1 as analogous to Processing Resources 416 and Storage Devices 430-434, respectively, depicted in the system of Gold Fig. 7, because both systems enable an application with direct access to a dataset stored in non-volatile memory without first requiring copying of data to a local memory (see Shah ¶0046). As taught in Shah, a file system exposes “memory mapped” types of files to applications, which in turn enables mapping of files stored in NVM 130 into the application’s virtual address space.
Gold and Shah are considered analogous to the claimed invention because they all relate to the same field of providing applications with direct access to data stored within non-volatile memory . Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold with the teachings of Shah and realize a memory system whereby data is exposed to an application as memory-mapped files. Such a format of exposing data to an application enables the application to access data directly from non-volatile memory without first copying the data to local memory, thereby saving processing and memory resources, as taught in Shah ¶0046: “Server computer 102 may use memory mapping and direct access (DAX) to access data stored in NVM 130. A memory mapped file in NVM 130 may be treated as byte addressable storage. DAX may eliminate copying file 132 to page cache (e.g., local memory 115) by enabling direct read and write access to files (e.g., file 132) stored in NVM 130.” [0046]
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Gold and Shah disclose the following limitations:
The memory system of claim 1, wherein the distributed workflow is associated with machine learning operations (Gold, “Generating a transformed dataset for use by a machine learning model” [Abstract])
Regarding Claim 7,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teachings of Gold and Shah disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above), wherein the one or more components, to establish the respective direct access connection to the portion of the fabric-attached memory with each host device of the multiple host devices, are configured to enable each host device, of the multiple host devices, to memory map the portion of the fabric-attached memory (Gold, “a storage system for use with Dual PCI direct mapped storage devices … the storage controllers may first write data into the separately addressable fast write storage on one or more storage devices” [0074] // ¶¶0086-90) – As taught in Gold ¶¶0074 and 0086-92, storage devices within storage system are “separately addressable” using “an explicit mapping of authorities to storage nodes” (¶0092) to identify and access data. One of ordinary skill in the art would accordingly understand that access by processing resources 416-420 to dataset 404 stored in storage devices 430-434 (e.g., via RDMA protocols; see Claim 1 limitation mappings above) would at least use some form of mapping to identify and/or to access respective portions of the dataset (i.e., are “memory map[ped]” to the storage devices in order to access data).
Regarding Claim 17,
Gold discloses the following limitations:
A method, comprising:
storing (Fig. 7, step 410), by a memory system (Figs. 3B + 7), a dataset (Dataset 404, Fig. 7) in a portion of a fabric-attached memory (Storage Devices 430-434, Fig. 7 // “NVMe over fabrics” [0125] // “storing (410) the dataset (404) within the storage system (406)” [0175]) -- As shown in Fig. 7, a dataset 404, is written to shared storage resources 430-434 for examination by analytics application 422)-,
wherein the dataset is stored in a format (“an indexed directory structure” [0176] // ¶0123) that enables analysis of the dataset by multiple host devices (Processing Resources 416-420, Fig. 7) associated with a distributed workflow (“a big data analytics pipeline” [0175] // Fig. 7) without requiring the multiple host devices to copy the dataset to local memory (Fig. 7 // “storing (410) the dataset (404) within the storage system (406) can include organizing (708) the data into an indexed directory structure” [0176] // “Readers will appreciate that, because the dataset (404) is stored within shared storage, the analytics application (422) does not need to retain a copy of the dataset in storage … that is only accessible by the processing resources which are being used to execute the analytics application (422).” [0166] // ¶0175) – As disclosed in ¶0175, analytics applications executing on processing resources 416-420 “ingest” and examine the dataset 404 in order to make conclusions about a data producer. As taught in ¶0166, dataset 404 is stored in shared storage (in an “indexed directory structure” type of “format”; see ¶0176) which enables analytics applications to examine the dataset 404 without first requiring local storage of the dataset --; and
establishing, by the memory system, a respective direct access connection (“implement a remote direct memory access (RDMA) protocol over converged ethernet (RoCE) fabric” [0209]) to the portion of the fabric-attached memory with each host device of the multiple host devices associated with the distributed workflow (“The storage system 306 … includes communication resources 310 that may be useful in facilitating data communications between components within the storage system 306 … The communication resources 310 can also include … NVMe over fabrics (‘NVMeoF’) technologies through which non-volatile storage media attached via a PCI express (‘PCIe’) bus may be accessed” [0125] // ¶¶0159; 0204; 0209) – As disclosed in ¶0125, components within storage system 406 communicate using NVMeoF technology which enables access to non-volatile storage via a PCIe bus. As clarified in ¶0209, such communication can be implemented using an established RDMA protocol over a fabric. Examiner accordingly considers configuring a storage system, such as storage system 406 of Fig. 7, using the aforementioned NVMeoF resources and RDMA protocols as “establish[ing] a respective direct access connection” between each application executing on a processing resource and each storage device storing the dataset--,
wherein the fabric-attached memory is exposed as … files to support the multiple host devices to mount a same file system from the fabric-attached memory, (“The storage system 306 depicted in FIG. 3B may implement a variety of storage architectures … Storage systems in accordance with some embodiments of the present disclosure utilize file storage in which data is stored in a hierarchical structure. Such data may be saved in files and folders, and presented to both the system storing it and the system accessing retrieving it in the same format” [0123] // “the indexed file system may essentially be used as a database that can be quickly searched” [0176]) – Data is organized within an indexed file system (i.e., is “exposed as” “files”) presented to each accessing system (e.g., processing resources 416-420) “in the same format”. Accordingly, each processing resource in the system is presented a same file system format for accessing the dataset 404 (i.e., “mount[s] a same file system” from storage devices 430-434--, and
wherein the direct access connections enable each host device, of the multiple host devices, to access the dataset (“reading their respective portions of the dataset” [0170]) via the respective direct access connection (¶0125) and by using a zero-copy access technique that does not require the host device copy the dataset to a local memory (¶0166) to extract (Fig. 7, step 414) a batch of data objects (¶0123) from the dataset for performing a computation (“examines datasets” [0168]) associated with the distributed workflow (“executing (414) the analytics application (422) on the processing resources (416), including ingesting the dataset (404) from the storage system” [0175] // “In fact, the analytics application (422) and the real-time analytics application (506) may be reading their respective portions of the dataset (404) from a single copy of the dataset (404) that is stored within the storage system (406)” [0170]) – As shown in Fig. 7, analytics application 422 ingests (i.e., “extract[s]”) respective portions of dataset 404 (i.e., “a batch of data objects”; see ¶0170) without needing to first copy the entire dataset 404 into a local memory (see ¶0166). As disclosed in ¶0170, an analytics application operating on a processing resource 416 accesses the same dataset 404 stored within storage devices 430-434 as compared to other applications operating on other processing resources (e.g., a processing resource 418). As clarified in ¶0168, analytics applications examine and transform data in order to make a conclusion about the data.
Gold does not explicitly disclose a “memory-mappable” type of file into which dataset 404 is organized and thus does not explicitly disclose the following limitations:
the fabric-attached memory is exposed as memory-mappable files
However, Shah discloses the following limitations:
the fabric-attached memory (NVM 130, Fig. 1) is exposed as memory-mappable files (“a memory mapped file” [0046])(“Memory mapping a file (e.g., file 132) for access by an application (e.g., transaction processor 140) may involve file manager 132 … mapping a file e.g., using … mmap() … from address space in storage device 180 or NVM 130 to address space exposed to an application’s virtual address space. Server computer 102 may use memory mapping and direct access (DAX) to access data stored in NVM 130. A memory mapped file in NVM 130 may be treated as byte addressable storage. DAX may eliminate copying file 132 to page cache (e.g., local memory 115) by enabling direct read and write access to files (e.g., file 132) stored in NVM 130.” [0046] // “Transaction processor 140 may be responsive to requests (e.g., from applications (not shown) on client computer(s) 150)” [0037] // Fig. 1) – Examiner considers Client Computer 150 and NVM 130 depicted in the system of Shah Fig. 1 as analogous to Processing Resources 416 and Storage Devices 430-434, respectively, depicted in the system of Gold Fig. 7, because both systems enable an application with direct access to a dataset stored in non-volatile memory without first requiring copying of data to a local memory (see Shah ¶0046). As taught in Shah, a file system exposes “memory mapped” types of files to applications, which in turn enables mapping of files stored in NVM 130 into the application’s virtual address space.
Gold and Shah are considered analogous to the claimed invention because they all relate to the same field of providing applications with direct access to data stored within non-volatile memory . Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold with the teachings of Shah and realize a memory system whereby data is exposed to an application as memory-mapped files. Such a format of exposing data to an application enables the application to access data directly from non-volatile memory without first copying the data to local memory, thereby saving processing and memory resources, as taught in Shah ¶0046: “Server computer 102 may use memory mapping and direct access (DAX) to access data stored in NVM 130. A memory mapped file in NVM 130 may be treated as byte addressable storage. DAX may eliminate copying file 132 to page cache (e.g., local memory 115) by enabling direct read and write access to files (e.g., file 132) stored in NVM 130.” [0046]
Regarding Claim 22,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 22. The combined teachings of Gold and Shah disclose the following limitations:
The method of claim 17, wherein the distributed workflow is associated with machine learning operations (Gold, “Generating a transformed dataset for use by a machine learning model” [Abstract])
Regarding Claim 23,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 23. The combined teachings of Gold and Shah disclose the following limitations:
The method of claim 17, wherein establishing the respective direct access connection to the portion of the fabric-attached memory with each host device of multiple host devices comprises enabling each host device, of the multiple host devices, to memory map the portion of the fabric-attached memory (Gold, “a storage system for use with Dual PCI direct mapped storage devices … the storage controllers may first write data into the separately addressable fast write storage on one or more storage devices” [0074] // ¶¶0086-90) – As taught in Gold ¶¶0074 and 0086-92, storage devices within storage system are “separately addressable” using “an explicit mapping of authorities to storage nodes” (¶0092) to identify and access data. One of ordinary skill in the art would accordingly understand that access by processing resources 416-420 to dataset 404 stored in storage devices 430-434 (e.g., via RDMA protocols; see Claim 17 limitation mappings above) would at least use some form of mapping to identify and/or to access respective portions of the dataset (i.e., are “memory map[ped]” to the storage devices in order to access data).
Claims 2, 8-9. 15-16, 18, and 24-25 are rejected under 35 U.S.C. 103 as being unpatentable over Gold further in view of Shah and Eun et al. (US 20240220150 A1)(cited by examiner in previous Action)(hereafter referred to as Eun).
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Gold and Shah disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above),
Gold and Shah silent regarding the following limitations:
wherein the memory system is associated with a compute express link compliant memory system
However, Eun discloses a storage system environment (Fig. 5) including an image recognition program 522a performing analysis on DATA 1 stored in a shared memory space 536, which examiner considers analogous to the storage system environment of Gold Fig. 7 whereby a analytics application 422 performs analysis on a dataset stored in shared memory resources.
Eun discloses the following limitations:
wherein the memory system (Fig. 5) is associated with a compute express link compliant memory system (“the host device 110 may control operations of the computational storage devices 1201 to 120n via a computer express link (CXL) interface” [0023])
Gold and Shah disclose a storage environment whereby an application program (Gold, Analytics Application 422, Fig. 7) performs analysis on a dataset stored in shared memory (Gold, Storage Devices 430-434, Fig. 7), which is considered analogous to the Eun storage environment whereby an application program (Program 522a, Fig. 5) performs analysis on a dataset stored in shared memory (Shared Memory Space 536, Fig. 536). Eun discloses a known method of communicating with computational storage devices using a CXL-type of interface (see limitation mappings above). It would have been obvious to one of ordinary skill in the art, as taught by Eun, to implement the known method of communicating with computational storage devices using a CXL-type of interface in the storage environment of Gold. A person of ordinary skill in the art would have recognized that applying the known technique of communicating with computational storage devices using a CXL-type of interface as taught by Eun to a storage environment containing an application program performing analysis on a dataset stored in shared memory would have yielded the predictable result of associating the storage environment with a CXL-compliant memory system. Using a CXL-compliant memory system would have been expected to enable direct peer-to-peer access of data between storage devices within the storage environment. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to apply the known technique of communicating with computational storage devices with a CXL-type of interface, as taught by Eun, to the storage environment containing an application program performing analysis on a dataset in shared memory disclosed in Gold. Doing so would predictably result in a CXL-compliant memory system. See MPEP 2143, Rationale D.
Regarding Claim 8,
Gold discloses the following limitations:
A distributed workflow system (Fig. 7), comprising:
one or more components (Processing Resources 416-420 + Storage Devices 430-434, Fig. 7 // Fig. 3B // ¶¶0159; 0175) configured to:
establish a direct access connection (“implement a remote direct memory access (RDMA) protocol over converged ethernet (RoCE) fabric” [0209]) to a portion of a fabric-attached memory (Storage Devices 430-434, Fig. 7 // “NVMe over fabrics” [0125] // Fig. 3B)(“The storage system 306 … includes communication resources 310 that may be useful in facilitating data communications between components within the storage system 306 … The communication resources 310 can also include … NVMe over fabrics (‘NVMeoF’) technologies through which non-volatile storage media attached via a PCI express (‘PCIe’) bus may be accessed” [0125] // ¶¶0159; 0204; 0209) – As disclosed in ¶0125, components within storage system 406 communicate using NVMeoF technology which enables access to non-volatile storage via a PCIe bus. As clarified in ¶0209, such communication can be implemented using an established RDMA protocol over a fabric. Examiner accordingly considers configuring a storage system, such as storage system 406 of Fig. 7, using the aforementioned NVMeoF resources and RDMA protocols as “establish[ing] a direct access connection” to fabric-attached storage resources--
that stores (Fig. 7, step 410) a dataset (Dataset 404, Fig. 7) associated with a distributed workflow (“a big data analytics pipeline” [0175] // Fig. 5)(“storing (410), within the storage system (406), the dataset (404)” [0163] // ¶¶0168-0170) – As shown in Fig. 7, a dataset 404 associated with “a big data analytics pipeline” (i.e., “associated with a distributed workflow”) is written to shared storage resources 430-434 for examination by analytics application 422,
wherein the fabric-attached memory is exposed as … files to support the multiple host devices to mount a same file system from the fabric-attached memory, (“The storage system 306 depicted in FIG. 3B may implement a variety of storage architectures … Storage systems in accordance with some embodiments of the present disclosure utilize file storage in which data is stored in a hierarchical structure. Such data may be saved in files and folders, and presented to both the system storing it and the system accessing retrieving it in the same format” [0123] // “the indexed file system may essentially be used as a database that can be quickly searched” [0176]) – Data is organized within an indexed file system (i.e., is “exposed as” “files”) presented to each accessing system (e.g., processing resources 416-420) “in the same format”. Accordingly, each processing resource in the system is presented a same file system format for accessing the dataset 404 (i.e., “mount[s] a same file system” from storage devices 430-434--,
wherein the dataset is stored in a format (“an indexed directory structure” [0176] // ¶0123) that enables zero-copy analysis (¶0166) of the dataset of the fabric-attached memory by multiple distributed workflow systems (Processing Resources 416 + 418, Fig. 7) associated with the distributed workflow (Fig. 7 // “Readers will appreciate that, because the dataset (404) is stored within shared storage, the analytics application (422) does not need to retain a copy of the dataset in storage … that is only accessible by the processing resources which are being used to execute the analytics application (422).” [0166] // “storing (410) the dataset (404) within the storage system (406) can include organizing (708) the data into an indexed directory structure” [0176] // ¶0168) – As taught in ¶0166, dataset 404 is stored in shared storage (in an “indexed directory structure” type of “format”; see ¶0176) which enables analytics applications to examine the dataset 404 without first requiring local storage of the dataset (i.e., “zero-copy analysis”)--;
access the dataset via the direct access connection and by using a zero-copy access technique (“In fact, the analytics application (422) and the real-time analytics application (506) may be reading their respective portions of the dataset (404) from a single copy of the dataset (404) that is stored within the storage system (406)” [0170]) – As disclosed in ¶0170, an analytics application operating on a processing resource 416 accesses the same dataset 404 stored within storage devices 430-434 as compared to other applications operating on other processing resources (e.g., a processing resource 418). In this case, examiner considers an application (such as analytics application 422) reading a portion of a dataset from a shared memory location as “a zero-copy access technique” (i.e., accessing data without first storing a local copy of the data)--;
extract (Fig. 7, step 414 // ¶0170) a batch of data objects (¶0123) from the dataset (“executing (414) the analytics application (422) on the processing resources (416), including ingesting the dataset (404) from the storage system” [0175] // “Readers will appreciate that in other embodiments, the real-time nature of the real-time analytics application (506) may be enforced in other ways. For example, the real-time analytics application (506) may only consume portions of the dataset (404) that have been produced within some threshold … while the analytics application (422) consumes all other portions of the dataset” [0170] // ¶0123) – As shown in Fig. 7, analytics application 422 ingests (i.e., “extract[s]”) respective portions of dataset 404 (i.e., “a batch of data objects”; see ¶0170) …; and
perform a computation (“examines datasets” [0164]) associated with the distributed workflow using the batch of data objects (“The analytics application … examines datasets in order to draw conclusions about the information contained in the datasets … transform unstructured data into structured or semi-structured data” [0164]) – As taught in ¶0164, real- analytics application 422 examines and transforms data in order to make a conclusion about the data.
Gold does not explicitly disclose a “memory-mappable” type of file into which dataset 404 is organized and thus does not explicitly disclose the following limitations:
the fabric-attached memory is exposed as memory-mappable files
However, Shah discloses the following limitations:
the fabric-attached memory (NVM 130, Fig. 1) is exposed as memory-mappable files (“a memory mapped file” [0046])(“Memory mapping a file (e.g., file 132) for access by an application (e.g., transaction processor 140) may involve file manager 132 … mapping a file e.g., using … mmap() … from address space in storage device 180 or NVM 130 to address space exposed to an application’s virtual address space. Server computer 102 may use memory mapping and direct access (DAX) to access data stored in NVM 130. A memory mapped file in NVM 130 may be treated as byte addressable storage. DAX may eliminate copying file 132 to page cache (e.g., local memory 115) by enabling direct read and write access to files (e.g., file 132) stored in NVM 130.” [0046] // “Transaction processor 140 may be responsive to requests (e.g., from applications (not shown) on client computer(s) 150)” [0037] // Fig. 1) – Examiner considers Client Computer 150 and NVM 130 depicted in the system of Shah Fig. 1 as analogous to Processing Resources 416 and Storage Devices 430-434, respectively, depicted in the system of Gold Fig. 7, because both systems enable an application with direct access to a dataset stored in non-volatile memory without first requiring copying of data to a local memory (see Shah ¶0046). As taught in Shah, a file system exposes “memory mapped” types of files to applications, which in turn enables mapping of files stored in NVM 130 into the application’s virtual address space.
Gold and Shah are considered analogous to the claimed invention because they all relate to the same field of providing applications with direct access to data stored within non-volatile memory . Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold with the teachings of Shah and realize a memory system whereby data is exposed to an application as memory-mapped files. Such a format of exposing data to an application enables the application to access data directly from non-volatile memory without first copying the data to local memory, thereby saving processing and memory resources, as taught in Shah ¶0046: “Server computer 102 may use memory mapping and direct access (DAX) to access data stored in NVM 130. A memory mapped file in NVM 130 may be treated as byte addressable storage. DAX may eliminate copying file 132 to page cache (e.g., local memory 115) by enabling direct read and write access to files (e.g., file 132) stored in NVM 130.” [0046]
Although Gold ¶0170 discloses that analytics application 422 “consumes” a respective portion of a same dataset 404 in order to examine data, Gold does not explicitly disclose an analytics application copying data consumed from the shared memory resources into a local memory. Specifically, Gold and Shah do not explicitly disclose the following limitations:
copying the batch of data objects to a local memory associated with the distributed workflow system
However, Eun discloses the following limitations:
copying (operation S670, Fig. 5) the batch of data objects (DATA 1, Fig. 5) to a local memory (Local Memory 523, Fig. 5) associated with the distributed workflow system (“the computational storage device 520 may access the shared memory space 536 of the computational storage device 530 to bring the DATA1 from the shared memory space 536 of the computational storage device 530 into the local memory 523 of the computational storage device 520 in operation S670” [0056] // ¶¶0046-48) – As shown in Eun Fig. 5 and discussed in ¶0046-48, an image recognition program 522a operating on a computational storage device 520 performs analysis of a dataset portion DATA1 received from a shared memory space 536, similar to how the analytics application 422 of Gold Fig. 7 consumes a portion of a dataset from shared storage resources. Examiner accordingly considers image recognition program 522a and the environment depicted in Eun Fig. 5 as analogous to the analytics application 422 and the environment depicted in Gold Fig. 7, respectively. As shown in Eun Fig. 5 and detailed in ¶0056, image recognition program 522a first copies DATA1 to local memory 523 on which the image recognition program 522a is operating before generating a result based on the data.
Gold, Shah, and Eun are considered analogous to the claimed invention because they all relate to the same field of using computational storage devices accessing the same dataset in the same shared memory to perform distributed workflows related to artificial intelligence methods. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold and Shah with the teachings of Eun and realize a distributed system whereby a batch of objects extracted from shared memory is copied to a local memory. Doing so would enable a computational storage device to perform an application program which analyzes both local data and data stored in a remote shared memory to generate a correct result, enabling the improved efficiency realized by a host device offloading programs to computational devices, as disclosed in Eun ¶¶ 0048 // 0081: “the data that are a subject of image recognition may be distributedly stored in the computational storage devices 520 and 530. In this case, if the computational storage device 520 executes the image recognition program 522a using only its own stored data DATA0, an incomplete image recognition result may be obtained. Accordingly, the storage system according to some embodiments may transfer the data stored in the computational storage device 530 to the computational storage device 520.” [0048] // “As described above, by offloading the program to the computational storage device including the accelerator with the lowest utilization, the program may be executed efficiently.” [0081]
Regarding Claim 9,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 9. The combined teachings of Gold, Shah, and Eun disclose the following limitations:
The distributed workflow system of claim 8, wherein the fabric-attached memory is associated with a compute express link compliant memory (Eun, “the host device 110 may control operations of the computational storage devices 1201 to 120n via a computer express link (CXL) interface” [0023])
Regarding Claim 14,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 14. The combined teachings of Gold, Shah, and Eun disclose the following limitations:
The distributed workflow system of claim 8, wherein the distributed workflow is associated with machine learning operations (Gold, “Generating a transformed dataset for use by a machine learning model” [Abstract])
Regarding Claim 15,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 15. The combined teachings of Gold, Shah, and Eun disclose the following limitations:
The distributed workflow system of claim 8, wherein the one or more components, to establish the direct access connection to the portion of the fabric-attached memory, are configured to memory map the portion of the fabric-attached memory (Gold, “a storage system for use with Dual PCI direct mapped storage devices … the storage controllers may first write data into the separately addressable fast write storage on one or more storage devices” [0074] // ¶¶0086-90) – As taught in ¶¶0074 and 0086-92, storage devices within storage system are “separately addressable” using “an explicit mapping of authorities to storage nodes” (¶0092) to identify and access data. One of ordinary skill in the art would accordingly understand that access by processing resources 416-420 to dataset 404 stored in storage devices 430-434 (e.g., via RDMA protocols; see Claim 8 limitation mappings above) would at least use some form of mapping to identify and/or to access respective portions of the dataset (i.e., are “memory map[ped]” to the storage devices in order to access data).
Regarding Claim 16,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 16. The combined teachings of Gold, Shah, and Eun disclose the following limitations:
The distributed workflow system of claim 8, wherein the one or more components, to extract the batch of data objects from the dataset, are configured to filter the dataset on the fabric-attached memory prior to extraction of the batch of data objects (Gold, “In fact, the analytics application (422) and the real-time analytics application (506) may be reading their respective portions of the dataset (404) from a single copy of the dataset (404) that is stored within the storage system” [0170]) – As previously discussed (see Claim 8 limitation mappings above) and as disclosed in Gold ¶0170, respective analytics applications read respective portions of dataset 404 from the same, single copy of the dataset. In this context, an analytics application effectively “filter[s] the dataset” stored in storage system 406 in order to read only the respective portion of the dataset (e.g., Analytics Application 422 filters all data except “portions of the dataset” which have been produced in the last 30 minutes, which is instead analyzed by a separate application).
Regarding Claim 18,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 18. The combined teachings of Gold and Shah disclose the following limitations:
The method of claim 17 (see Claim 17 limitation mappings above),
Gold and Shah are silent regarding the following limitations:
wherein the memory system is associated with a compute express link compliant memory system
However, Eun discloses a storage system environment (Fig. 5) including an image recognition program 522a performing analysis on DATA 1 stored in a shared memory space 536, which examiner considers analogous to the storage system environment of Gold Fig. 7 whereby a analytics application 422 performs analysis on a dataset stored in shared memory resources.
Eun discloses the following limitations:
wherein the memory system (Fig. 5) is associated with a compute express link compliant memory system (“the host device 110 may control operations of the computational storage devices 1201 to 120n via a computer express link (CXL) interface” [0023])
Gold and Shah disclose a storage environment whereby an application program (Gold, Analytics Application 422, Fig. 7) performs analysis on a dataset stored in shared memory (Gold, Storage Devices 430-434, Fig. 7), which is considered analogous to the Eun storage environment whereby an application program (Program 522a, Fig. 5) performs analysis on a dataset stored in shared memory (Shared Memory Space 536, Fig. 536). Eun discloses a known method of communicating with computational storage devices using a CXL-type of interface (see limitation mappings above). It would have been obvious to one of ordinary skill in the art, as taught by Eun, to implement the known method of communicating with computational storage devices using a CXL-type of interface in the storage environment of Gold. A person of ordinary skill in the art would have recognized that applying the known technique of communicating with computational storage devices using a CXL-type of interface as taught by Eun to a storage environment containing an application program performing analysis on a dataset stored in shared memory would have yielded the predictable result of associating the storage environment with a CXL-compliant memory system. Using a CXL-compliant memory system would have been expected to enable direct peer-to-peer access of data between storage devices within the storage environment. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to apply the known technique of communicating with computational storage devices with a CXL-type of interface, as taught by Eun, to the storage environment containing an application program performing analysis on a dataset in shared memory disclosed in Gold. Doing so would predictably result in a CXL-compliant memory system. See MPEP 2143, Rationale D.
Regarding Claim 24,
Gold discloses the following limitations:
A method, comprising:
establishing, by a distributed workflow system (Fig. 7), a direct access connection (“implement a remote direct memory access (RDMA) protocol over converged ethernet (RoCE) fabric” [0209]) to a portion of a fabric-attached memory (Storage Devices 430-434, Fig. 7 // “NVMe over fabrics” [0125] // Fig. 3B)(“The storage system 306 … includes communication resources 310 that may be useful in facilitating data communications between components within the storage system 306 … The communication resources 310 can also include … NVMe over fabrics (‘NVMeoF’) technologies through which non-volatile storage media attached via a PCI express (‘PCIe’) bus may be accessed” [0125] // ¶¶0159; 0204; 0209) – As disclosed in ¶0125, components within storage system 406 communicate using NVMeoF technology which enables access to non-volatile storage via a PCIe bus. As clarified in ¶0209, such communication can be implemented using an established RDMA protocol over a fabric. Examiner accordingly considers configuring a storage system, such as storage system 406 of Fig. 7, using the aforementioned NVMeoF resources and RDMA protocols as “establish[ing] a direct access connection” to fabric-attached storage resources--
that stores (Fig. 7, step 410) a dataset (Dataset 404, Fig. 7) associated with a distributed workflow (“a big data analytics pipeline” [0175] // Fig. 5)(“storing (410), within the storage system (406), the dataset (404)” [0163] // ¶¶0168-0170) – As shown in Fig. 7, a dataset 404 associated with “a big data analytics pipeline” (i.e., “associated with a distributed workflow”) is written to shared storage resources 430-434 for examination by analytics application 422,
wherein the fabric-attached memory is exposed as … files to support the multiple host devices to mount a same file system from the fabric-attached memory, (“The storage system 306 depicted in FIG. 3B may implement a variety of storage architectures … Storage systems in accordance with some embodiments of the present disclosure utilize file storage in which data is stored in a hierarchical structure. Such data may be saved in files and folders, and presented to both the system storing it and the system accessing retrieving it in the same format” [0123] // “the indexed file system may essentially be used as a database that can be quickly searched” [0176]) – Data is organized within an indexed file system (i.e., is “exposed as” “files”) presented to each accessing system (e.g., processing resources 416-420) “in the same format”. Accordingly, each processing resource in the system is presented a same file system format for accessing the dataset 404 (i.e., “mount[s] a same file system” from storage devices 430-434--,
wherein the dataset is stored in a format (“an indexed directory structure” [0176] // ¶0123) that enables zero-copy analysis (¶0166) of the dataset of the fabric-attached memory by multiple distributed workflow systems (Processing Resources 416 + 418, Fig. 7) associated with the distributed workflow (Fig. 7 // “Readers will appreciate that, because the dataset (404) is stored within shared storage, the analytics application (422) does not need to retain a copy of the dataset in storage … that is only accessible by the processing resources which are being used to execute the analytics application (422).” [0166] // “storing (410) the dataset (404) within the storage system (406) can include organizing (708) the data into an indexed directory structure” [0176] // ¶0168) – As taught in ¶0166, dataset 404 is stored in shared storage (in an “indexed directory structure” type of “format”; see ¶0176) which enables analytics applications to examine the dataset 404 without first requiring local storage of the dataset (i.e., “zero-copy analysis”)--;
access the dataset via the direct access connection and by using a zero-copy access technique (“In fact, the analytics application (422) and the real-time analytics application (506) may be reading their respective portions of the dataset (404) from a single copy of the dataset (404) that is stored within the storage system (406)” [0170]) – As disclosed in ¶0170, an analytics application operating on a processing resource 416 accesses the same dataset 404 stored within storage devices 430-434 as compared to other applications operating on other processing resources (e.g., a processing resource 418). In this case, examiner considers an application (such as analytics application 422) reading a portion of a dataset from a shared memory location as “a zero-copy access technique” (i.e., accessing data without first storing a local copy of the data)--;
extract (Fig. 7, step 414 // ¶0170) a batch of data objects (¶0123) from the dataset (“executing (414) the analytics application (422) on the processing resources (416), including ingesting the dataset (404) from the storage system” [0175] // “Readers will appreciate that in other embodiments, the real-time nature of the real-time analytics application (506) may be enforced in other ways. For example, the real-time analytics application (506) may only consume portions of the dataset (404) that have been produced within some threshold … while the analytics application (422) consumes all other portions of the dataset” [0170] // ¶0123) – As shown in Fig. 7, analytics application 422 ingests (i.e., “extract[s]”) respective portions of dataset 404 (i.e., “a batch of data objects”; see ¶0170) …; and
perform a computation (“examines datasets” [0164]) associated with the distributed workflow using the batch of data objects (“The analytics application … examines datasets in order to draw conclusions about the information contained in the datasets … transform unstructured data into structured or semi-structured data” [0164]) – As taught in ¶0164, real- analytics application 422 examines and transforms data in order to make a conclusion about the data.
Gold does not explicitly disclose a “memory-mappable” type of file into which dataset 404 is organized and thus does not explicitly disclose the following limitations:
the fabric-attached memory is exposed as memory-mappable files
However, Shah discloses the following limitations:
the fabric-attached memory (NVM 130, Fig. 1) is exposed as memory-mappable files (“a memory mapped file” [0046])(“Memory mapping a file (e.g., file 132) for access by an application (e.g., transaction processor 140) may involve file manager 132 … mapping a file e.g., using … mmap() … from address space in storage device 180 or NVM 130 to address space exposed to an application’s virtual address space. Server computer 102 may use memory mapping and direct access (DAX) to access data stored in NVM 130. A memory mapped file in NVM 130 may be treated as byte addressable storage. DAX may eliminate copying file 132 to page cache (e.g., local memory 115) by enabling direct read and write access to files (e.g., file 132) stored in NVM 130.” [0046] // “Transaction processor 140 may be responsive to requests (e.g., from applications (not shown) on client computer(s) 150)” [0037] // Fig. 1) – Examiner considers Client Computer 150 and NVM 130 depicted in the system of Shah Fig. 1 as analogous to Processing Resources 416 and Storage Devices 430-434, respectively, depicted in the system of Gold Fig. 7, because both systems enable an application with direct access to a dataset stored in non-volatile memory without first requiring copying of data to a local memory (see Shah ¶0046). As taught in Shah, a file system exposes “memory mapped” types of files to applications, which in turn enables mapping of files stored in NVM 130 into the application’s virtual address space.
Gold and Shah are considered analogous to the claimed invention because they all relate to the same field of providing applications with direct access to data stored within non-volatile memory . Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold with the teachings of Shah and realize a memory system whereby data is exposed to an application as memory-mapped files. Such a format of exposing data to an application enables the application to access data directly from non-volatile memory without first copying the data to local memory, thereby saving processing and memory resources, as taught in Shah ¶0046: “Server computer 102 may use memory mapping and direct access (DAX) to access data stored in NVM 130. A memory mapped file in NVM 130 may be treated as byte addressable storage. DAX may eliminate copying file 132 to page cache (e.g., local memory 115) by enabling direct read and write access to files (e.g., file 132) stored in NVM 130.” [0046]
Although Gold ¶0170 discloses that analytics application 422 “consumes” a respective portion of a same dataset 404 in order to examine data, Gold does not explicitly disclose an analytics application copying data consumed from the shared memory resources into a local memory. Specifically, Gold and Shah do not explicitly disclose the following limitations:
copying the batch of data objects to a local memory associated with the distributed workflow system
However, Eun discloses the following limitations:
copying (operation S670, Fig. 5) the batch of data objects (DATA 1, Fig. 5) to a local memory (Local Memory 523, Fig. 5) associated with the distributed workflow system (“the computational storage device 520 may access the shared memory space 536 of the computational storage device 530 to bring the DATA1 from the shared memory space 536 of the computational storage device 530 into the local memory 523 of the computational storage device 520 in operation S670” [0056] // ¶¶0046-48) – As shown in Eun Fig. 5 and discussed in ¶0046-48, an image recognition program 522a operating on a computational storage device 520 performs analysis of a dataset portion DATA1 received from a shared memory space 536, similar to how the analytics application 422 of Gold Fig. 7 consumes a portion of a dataset from shared storage resources. Examiner accordingly considers image recognition program 522a and the environment depicted in Eun Fig. 5 as analogous to the analytics application 422 and the environment depicted in Gold Fig. 7, respectively. As shown in Eun Fig. 5 and detailed in ¶0056, image recognition program 522a first copies DATA1 to local memory 523 on which the image recognition program 522a is operating before generating a result based on the data.
Gold, Shah, and Eun are considered analogous to the claimed invention because they all relate to the same field of using computational storage devices accessing the same dataset in the same shared memory to perform distributed workflows related to artificial intelligence methods. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold and Shah with the teachings of Eun and realize a distributed system whereby a batch of objects extracted from shared memory is copied to a local memory. Doing so would enable a computational storage device to perform an application program which analyzes both local data and data stored in a remote shared memory to generate a correct result, enabling the improved efficiency realized by a host device offloading programs to computational devices, as disclosed in Eun ¶¶ 0048 // 0081: “the data that are a subject of image recognition may be distributedly stored in the computational storage devices 520 and 530. In this case, if the computational storage device 520 executes the image recognition program 522a using only its own stored data DATA0, an incomplete image recognition result may be obtained. Accordingly, the storage system according to some embodiments may transfer the data stored in the computational storage device 530 to the computational storage device 520.” [0048] // “As described above, by offloading the program to the computational storage device including the accelerator with the lowest utilization, the program may be executed efficiently.” [0081]
Regarding Claim 25,
The same motivation to combine provided in Claim 24 is equally applicable to Claim 25. The combined teachings of Gold, Shah, and Eun disclose the following limitations:
The method of claim 24, wherein the fabric-attached memory is associated with a compute express link compliant memory (Eun, “the host device 110 may control operations of the computational storage devices 1201 to 120n via a computer express link (CXL) interface” [0023])
Claims 3 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Gold further in view of Shah and a 2022 IEEE publication authored by Ruan et al. (entitled “Boost the Performance of Model Training with the Ray Framework for Emerging AI Applications”)(published 12/08/2022)(cited by examiner in previous Action)(hereafter referred to as Ruan).
Regarding Claim 3,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teachings of Gold and Shah disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above), wherein the distributed workflow is associated with a … framework (Gold, “The deep learning framework (1107B) layer may implement deep learning frameworks such as … among other deep learning frameworks” [0216] // ¶¶0203; 0214) – As disclosed in ¶0216, storage systems are used in order to implement various types of deep learning frameworks.
Gold is silent regarding a “RayTM” type of framework implemented by storage system 406. Specifically, Gold and Shah are silent regarding the following limitations:
a RayTM unified compute framework
However, Ruan discloses the following limitations:
a RayTM unified compute framework (“Ray is a high-performance distributed execution framework aimed at large-scale machine learning and reinforcement learning applications.” [Abstract])
Gold, Shah, and Ruan are considered analogous to the claimed invention because they all relate to the same field of implementing machine learning frameworks in distributed computing environments having shared memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold and Shah with the teachings of Ruan and realize a memory system associated with a “Ray unified computing” type of framework. Doing so enables a storage architecture to easily scale any computationally intensive Python workload to executed in a distributed CPU + GPU architecture, as disclosed in Ruan pg. 1: “Ray is an open source project led by U.C. Berkeley that can easily scale any computationally intensive Python workload to execute in a distributed CPU + GPU heterogeneous architecture” [pg. 1].
Regarding Claim 19,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 19. The combined teachings of Gold and Shah disclose the following limitations:
The method of claim 17 (see Claim 17 limitation mappings above), wherein the distributed workflow is associated with a … framework (Gold, “The deep learning framework (1107B) layer may implement deep learning frameworks such as … among other deep learning frameworks” [0216] // ¶¶0203; 0214) – As disclosed in ¶0216, storage systems are used in order to implement various types of deep learning frameworks.
Gold is silent regarding a “RayTM” type of framework implemented by storage system 406. Specifically, Gold and Shah are silent regarding the following limitations:
a RayTM unified compute framework
However, Ruan discloses the following limitations:
a Ray unified compute framework (“Ray is a high-performance distributed execution framework aimed at large-scale machine learning and reinforcement learning applications.” [Abstract])
Gold, Shah, and Ruan are considered analogous to the claimed invention because they all relate to the same field of implementing machine learning frameworks in distributed computing environments having shared memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold and Shah with the teachings of Ruan and realize a memory system associated with a “Ray unified computing” type of framework. Doing so enables a storage architecture to easily scale any computationally intensive Python workload to executed in a distributed CPU + GPU architecture, as disclosed in Ruan pg. 1: “Ray is an open source project led by U.C. Berkeley that can easily scale any computationally intensive Python workload to execute in a distributed CPU + GPU heterogeneous architecture” [pg. 1].
Claims 4-5 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Gold further in view of Shah and a 2023 APACHE online public disclosure (entitled “Arrow Columnar Format”; published at least May 17, 2023; accessed by examiner via WAYBACK MAHCINE; see Notice of References Cited)(cited by examiner in previous Action)(hereafter referred to as APACHE ‘23).
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Gold and Shah disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above) , wherein the format that enables analysis of the dataset by multiple host devices associated with a distributed workflow without requiring the multiple host devices to copy the dataset to local memory is a … memory format. (Gold, “Data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices” [0091]) – As taught in Gold ¶0091, various “storage layouts” (i.e., “memory format[s]”) are employed across storage devices for storing data.
Gold is silent regarding a “language-independent columnar” type of memory format for data storage. Specifically, Gold and Shah are silent regarding the following limitations:
a language-independent columnar memory format
However, APACHE ’23 discloses the following limitations:
a language-independent columnar memory format (“The ‘Arrow Columnar Format’ includes a language-agnostic in-memory data structure specification” [pg. 1]) – As taught in APACHE ’23, memory formats for data include an “Arrow Columnar Format” agnostic to language.
Gold, Shah, and APACHE ‘23 are considered analogous to the claimed invention because they all relate to the same field of formatting data for storage in a distributed storage environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold and Shah with the teachings of APACHE ‘23 and realize a language-independent columnar memory format for storing data in a memory fabric. Doing so provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations, as disclosed in APACHE ’23 pg. 1: “The Arrow columnar format provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations.” [pg. 1]
Regarding Claim 5,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 5. The combined teachings of Gold and Shah disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above), wherein the format that enables analysis of the dataset by multiple host devices associated with a distributed workflow without requiring the multiple host devices to copy the dataset to local memory is an … format (Gold, “Data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices” [0091]) – As taught in ¶0091, various “storage layouts” (i.e., “memory format[s]”) are employed across storage devices for storing data.
Gold is silent regarding an “ApacheTM Arrow” type of memory format for data storage. Specifically, Gold and Shah are silent regarding the following limitations:
an ApacheTM Arrow format
However, APACHE ’23 discloses the following limitations:
an ApacheTM Arrow format (“The ‘Arrow Columnar Format’ includes a language-agnostic in-memory data structure specification” [pg. 1]) – As taught in APACHE ’23, memory formats for data include an “Arrow Columnar Format” agnostic to language.
Gold, Shah, and APACHE ‘23 are considered analogous to the claimed invention because they all relate to the same field of formatting data for storage in a distributed storage environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold and Shah with the teachings of APACHE ‘23 and realize a language-independent columnar memory format for storing data in a memory fabric. Doing so provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations, as disclosed in APACHE ’23 pg. 1: “The Arrow columnar format provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations.” [pg. 1]
Regarding Claim 20,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 20. The combined teachings of Gold and Shah disclose the following limitations:
The method of claim 17 (see Claim 17 limitation mappings above) , wherein the format that enables analysis of the dataset by multiple host devices associated with a distributed workflow without requiring the multiple host devices to copy the dataset to local memory is a … memory format. (Gold, “Data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices” [0091]) – As taught in ¶0091, various “storage layouts” (i.e., “memory format[s]”) are employed across storage devices for storing data.
Gold is silent regarding a “language-independent columnar” type of memory format for data storage. Specifically, Gold and Shah are silent regarding the following limitations:
a language-independent columnar memory format
However, APACHE ’23 discloses the following limitations:
a language-independent columnar memory format (“The ‘Arrow Columnar Format’ includes a language-agnostic in-memory data structure specification” [pg. 1]) – As taught in APACHE ’23, memory formats for data include an “Arrow Columnar Format” agnostic to language.
Gold, Shah, and APACHE ‘23 are considered analogous to the claimed invention because they all relate to the same field of formatting data for storage in a distributed storage environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold and Shah with the teachings of APACHE ‘23 and realize a language-independent columnar memory format for storing data in a memory fabric. Doing so provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations, as disclosed in APACHE ’23 pg. 1: “The Arrow columnar format provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations.” [pg. 1]
Regarding Claim 21,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 21. The combined teachings of Gold and Shah disclose the following limitations:
The method of claim 17 (see Claim 17 limitation mappings above), wherein the format that enables analysis of the dataset by multiple host devices associated with a distributed workflow without requiring the multiple host devices to copy the dataset to local memory is an … format (Gold, “Data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices” [0091]) – As taught in Gold ¶0091, various “storage layouts” (i.e., “memory format[s]”) are employed across storage devices for storing data.
Gold is silent regarding an “Apache Arrow” type of memory format for data storage. Specifically, Gold and Shah are silent regarding the following limitations:
an Apache Arrow format
However, APACHE ’23 discloses the following limitations:
an Apache Arrow format (“The ‘Arrow Columnar Format’ includes a language-agnostic in-memory data structure specification” [pg. 1]) – As taught in APACHE ’23, memory formats for data include an “Arrow Columnar Format” agnostic to language.
Gold, Shah, and APACHE ‘23 are considered analogous to the claimed invention because they all relate to the same field of formatting data for storage in a distributed storage environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold and Shah with the teachings of APACHE ‘23 and realize a language-independent columnar memory format for storing data in a memory fabric. Doing so provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations, as disclosed in APACHE ’23 pg. 1: “The Arrow columnar format provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations.” [pg. 1]
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Gold further in view of Shah, Eun and Ruan.
Regarding Claim 10,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 10. The combined teachings of Gold, Shah, and Eun disclose the following limitations:
The distributed workflow system of claim 8 (see Claim 8 limitation mappings above), wherein the distributed workflow is associated with a … framework (Gold, “The deep learning framework (1107B) layer may implement deep learning frameworks such as … among other deep learning frameworks” [0216] // ¶¶0203; 0214) – As disclosed in Gold ¶0216, storage systems are used in order to implement various types of deep learning frameworks.
Gold is silent regarding a “RayTM” type of framework implemented by storage system 406. Specifically, Gold, Shah, and Eun are silent regarding the following limitations:
a RayTM unified compute framework
However, Ruan discloses the following limitations:
a RayTM unified compute framework (“Ray is a high-performance distributed execution framework aimed at large-scale machine learning and reinforcement learning applications.” [Abstract])
Gold, Shah, Eun, and Ruan are considered analogous to the claimed invention because they all relate to the same field of implementing machine learning frameworks in distributed computing environments having shared memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold, Shah, and Eun with the teachings of Ruan and realize a memory system associated with a “Ray unified computing” type of framework. Doing so enables a storage architecture to easily scale any computationally intensive Python workload to executed in a distributed CPU + GPU architecture, as disclosed in Ruan pg. 1: “Ray is an open source project led by U.C. Berkeley that can easily scale any computationally intensive Python workload to execute in a distributed CPU + GPU heterogeneous architecture” [pg. 1].
Claims 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Gold further in view of Shah, Eun and APACHE ‘23.
Regarding Claim 11,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 11. The combined teachings of Gold, Shah, and Eun disclose the following limitations:
The distributed workflow system of claim 8 (see Claim 8 limitation mappings above), wherein the format that enables zero-copy analysis of the dataset is a … memory format (Gold, “Data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices” [0091]) – As taught in Gold ¶0091, various “storage layouts” (i.e., “memory format[s]”) are employed across storage devices for storing data.
Gold is silent regarding a “language-independent columnar” type of memory format for data storage. Specifically, Gold, Shah, and Eun are silent regarding the following limitations:
a language-independent columnar memory format
However, APACHE ’23 discloses the following limitations:
a language-independent columnar memory format (“The ‘Arrow Columnar Format’ includes a language-agnostic in-memory data structure specification” [pg. 1]) – As taught in APACHE ’23, memory formats for data include an “Arrow Columnar Format” agnostic to language.
Gold, Shah, Eun, and APACHE ‘23 are considered analogous to the claimed invention because they all relate to the same field of formatting data for storage in a distributed storage environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold, Shah, and Eun with the teachings of APACHE ‘23 and realize a language-independent columnar memory format for storing data in a memory fabric. Doing so provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations, as disclosed in APACHE ’23 pg. 1: “The Arrow columnar format provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations.” [pg. 1]
Regarding Claim 12,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 12. The combined teachings of Gold, Shah, and Eun disclose the following limitations:
The distributed workflow system of claim 8 (see Claim 8 limitation mappings above), wherein the format that enables zero-copy analysis of the dataset is an … format (Gold, “Data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices” [0091]) – As taught in Gold ¶0091, various “storage layouts” (i.e., “memory format[s]”) are employed across storage devices for storing data.
Gold is silent regarding an “ApacheTM Arrow” type of memory format for data storage. Specifically, Gold, Shah, and Eun are silent regarding the following limitations:
an ApacheTM Arrow memory format
However, APACHE ’23 discloses the following limitations:
an ApacheTM Arrow format (“The ‘Arrow Columnar Format’ includes a language-agnostic in-memory data structure specification” [pg. 1]) – As taught in APACHE ’23, memory formats for data include an “Arrow Columnar Format” agnostic to language.
Gold, Shah, Eun, and APACHE ‘23 are considered analogous to the claimed invention because they all relate to the same field of formatting data for storage in a distributed storage environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gold, Shah, and Eun with the teachings of APACHE ‘23 and realize a language-independent columnar memory format for storing data in a memory fabric. Doing so provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations, as disclosed in APACHE ’23 pg. 1: “The Arrow columnar format provides analytical performance and data locality guarantees in exchange for comparatively more expensive mutation operations.” [pg. 1]
Regarding Claim 13,
The same motivation to combine provided in Claim 12 is equally applicable to Claim 13. The combined teachings of Gold, Shah, Eun, and APACHE ’23 disclose the following limitations:
The distributed workflow system of claim 12, wherein the one or more components, to extract the batch of data objects from the dataset, are configured to use an ApacheTM Arrow record batch stream reader interface with a filter input (APACHE ’23, “A RecordBatch message contains the actual data buffers corresponding to the physical memory layout determined by a schema. The metadata for this message provides the location and size of each buffer, permitting Array data structures to be reconstructed using pointer arithmetic and thus no memory copying.” [pg. 13]) – As taught in APACHE ’23, “RecordBatch” type messages identifying locations of data are employed by a memory system using the Arrow-type format. Examiner accordingly considers a storage system using “RecordBatch” messages to identify data as “an Apache Arrow record batch stream reader interface with a filter input”.
Response to Arguments
Applicant’s arguments with respect to claims 1-25 have been considered but are moot in view of the newly-identified Shah reference because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rocío del Mar Pérez-Vélez can be reached at 571-270-5935. 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.
/J.S.M./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights