DETAILED ACTION
This Action is responsive to the Amendments filed on 03/09/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 .
Claim Status
Claims 1-25 are amended. Claims 1-25 are pending and have been examined.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 6-7, 17, and 22-23 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Gold et al. (US 20230126789 A1)(hereafter referred to as Gold).
Regarding Claim 1,
Gold anticipates the following limitations:
A memory system (Fig. 5), comprising:
one or more components (Processing Resources 416-420 + Storage Devices 430-434, Fig. 5 // Fig. 3B // ¶0159) configured to:
store (Fig. 5, step 410) a dataset (Dataset 404, Fig. 5) in a portion of a fabric-attached memory (Storage Devices 430-434, Fig. 5 // “NVMe over fabrics” [0125] // “storing (410) the dataset (404) within the storage system (406)” [0167]) -- As shown in Fig. 5, a dataset 404, is written to shared storage resources 430-434 for examination by analytics applications 422 and 506 (see ¶0168)--,
wherein the dataset is stored in a format (“unstructured” [0168]) that enables analysis of the dataset by multiple host devices (Processing Resources 416-420, Fig. 5) associated with a distributed workflow (“a big data analytics pipeline” [0159] // Fig. 5) without requiring the multiple host devices to copy the dataset to local memory(Fig. 5 // “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] // ¶0168) – As disclosed in ¶0168, analytics applications executing on processing resources 416-420 examine the dataset 404 in order to make conclusions about a data producer. As taught in ¶0166, dataset 404 is stored in shared storage (i.e., having an “unstructured” [0168] type of “format”) 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. 5, 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 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. 5, step 504 // ¶0170) a batch of data objects (¶0123) from the dataset for performing a computation (“examines datasets” [0168]) associated with the distributed workflow (“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 … 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. 5 and detailed in ¶0170, respective analytics applications 422 and 506 consume (i.e., “extract”) respective portions of dataset 404 (stored as “objects” [0123]; i.e., “a batch of data objects”) without needing to first copy the entire dataset 404 into a local memory (see ¶0166). As clarified in ¶0168, analytics applications examine and transform data in order to make a conclusion about the data.
Regarding Claim 6,
Gold anticipates the following limitations:
The memory system of claim 1, wherein the distributed workflow is associated with machine learning operations (“Generating a transformed dataset for use by a machine learning model” [Abstract])
Regarding Claim 7,
Gold anticipates 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 (“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 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 anticipates the following limitations:
A method, comprising:
storing (Fig. 5, step 410), by a memory system (Fig. 5), a dataset (Dataset 404, Fig. 5) in a portion of a fabric-attached memory (Storage Devices 430-434, Fig. 5 // “NVMe over fabrics” [0125] // “storing (410) the dataset (404) within the storage system (406)” [0167]) -- As shown in Fig. 5, a dataset 404, is written to shared storage resources 430-434 for examination by analytics applications 422 and 506 (see ¶0168)-,
wherein the dataset is stored in a format (“unstructured” [0168]) that enables analysis of the dataset by multiple host devices (Processing Resources 416-420, Fig. 5) associated with a distributed workflow (“a big data analytics pipeline” [0159] // Fig. 5) without requiring the multiple host devices to copy the dataset to local memory(Fig. 5 // “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] // ¶0168) – As disclosed in ¶0168, analytics applications executing on processing resources 416-420 examine the dataset 404 in order to make conclusions about a data producer. As taught in ¶0166, dataset 404 is stored in shared storage (i.e., having an “unstructured” [0168] type of “format”) 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. 5, 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 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. 5, step 504 // ¶0170) a batch of data objects (¶0123) from the dataset for performing a computation (“examines datasets” [0168]) associated with the distributed workflow (“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 … 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. 5 and detailed in ¶0170, respective analytics applications 422 and 506 consume (i.e., “extract”) respective portions of dataset 404 (stored as “objects” [0123]; i.e., “a batch of data objects”) without needing to first copy the entire dataset 404 into a local memory (see ¶0166). As clarified in ¶0168, analytics applications examine and transform data in order to make a conclusion about the data.
Regarding Claim 22,
Gold anticipates the following limitations:
The method of claim 17, wherein the distributed workflow is associated with machine learning operations (“Generating a transformed dataset for use by a machine learning model” [Abstract])
Regarding Claim 23,
Gold anticipates 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 (“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 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).
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 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 Eun et al. (US 20240220150 A1)(hereafter referred to as Eun).
Regarding Claim 2,
Gold discloses the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above),
Gold is 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. 5 whereby a real-time analytics application 506 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 discloses a storage environment whereby an application program (Application Program 506, Fig. 5) performs analysis on a dataset stored in shared memory (Storage Devices 430-434, Fig. 5), 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. 5), comprising:
one or more components (Processing Resources 416-420 + Storage Devices 430-434, Fig. 5 // Fig. 3B // ¶0159) 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. 5 // “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. 5, using the aforementioned NVMeoF resources and RDMA protocols as “establish[ing] a direct access connection” to fabric-attached storage resources--
that stores (Fig. 5, step 410) a dataset (Dataset 404, Fig. 5) associated with a distributed workflow (“a big data analytics pipeline” [0159] // Fig. 5)(“storing (410), within the storage system (406), the dataset (404)” [0163] // ¶¶0168-0170) – As shown in Fig. 5, 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 applications 422 and 506 (see ¶0168)--,
wherein the dataset is stored in a format (“unstructured” [0168]) that enables zero-copy analysis (¶0166) of the dataset of the fabric-attached memory by multiple distributed workflow systems (Processing Resources 416 + 418, Fig. 5) associated with the distributed workflow (Fig. 5 // “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] // ¶0168) – As taught in ¶0166, dataset 404 is stored in shared storage (i.e., having an “unstructured” [0168] type of “format”) which enables analytics application 422 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, the analytics application 422 and the real-time analytics application 506 both read from the same copy of dataset 404. 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. 5, step 504 // ¶0170) a batch of data objects from the dataset (“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 taught in ¶0170, real-time analytics application 506 “consumes” (i.e., “extract[s]”) portions of data (stored as “objects” [0123]; i.e., “a batch of objects”) from dataset 404 which satisfy a given time threshold-- …; and
perform a computation (“examines datasets” [0168]) associated with the distributed workflow using the batch of data objects (“The real-time 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” [0168]) – As taught in ¶0168, real-time analytics application 506 examines and transforms data in order to make a conclusion about the data.
Although Gold ¶0170 discloses that analytics application 422 and real-time analytics application 506 each “consume” respective portions of the same dataset 404 in order to examine data, Gold is silent regarding an analytics application copying data consumed from the shared memory resources into a local memory. Specifically, Gold is silent regarding 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 real-time analytics application 506 of Gold Fig. 5 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 real-time analytics application 506 and the environment depicted in Gold Fig. 5, 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 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 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 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 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 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 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., Real-Time Analytics Application 506 filters “portions of the dataset” which have been produced in the last 30 minutes from “all other portions of the dataset” which are instead read by Analytics Application 422).
Regarding Claim 18,
Gold discloses the following limitations:
The method of claim 17 (see Claim 17 limitation mappings above),
Gold is 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. 5 whereby a real-time analytics application 506 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 discloses a storage environment whereby an application program (Application Program 506, Fig. 5) performs analysis on a dataset stored in shared memory (Storage Devices 430-434, Fig. 5), 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. 5), 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. 5 // “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. 5, using the aforementioned NVMeoF resources and RDMA protocols as “establish[ing] a direct access connection” to fabric-attached storage resources--
that stores (Fig. 5, step 410) a dataset (Dataset 404, Fig. 5) associated with a distributed workflow (“a big data analytics pipeline” [0159] // Fig. 5)(“storing (410), within the storage system (406), the dataset (404)” [0163] // ¶¶0168-0170) – As shown in Fig. 5, 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 applications 422 and 506 (see ¶0168)--,
wherein the dataset is stored in a format (“unstructured” [0168]) that enables zero-copy analysis (¶0166) of the dataset of the fabric-attached memory by multiple distributed workflow systems (Processing Resources 416 + 418, Fig. 5) associated with the distributed workflow (Fig. 5 // “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] // ¶0168) – As taught in ¶0166, dataset 404 is stored in shared storage (i.e., having an “unstructured” [0168] type of “format”) which enables analytics application 422 to examine the dataset 404 without first requiring local storage of the dataset (i.e., “zero-copy analysis”)--;
accessing, by the distributed workflow system, 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, the analytics application 422 and the real-time analytics application 506 both read from the same copy of dataset 404. 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)--;
extracting (Fig. 5, step 504 // ¶0170), by the distributed workflow system, a batch of data objects from the dataset (“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 taught in ¶0170, real-time analytics application 506 “consumes” (i.e., “extract[s]”) portions of data (stored as “objects” [0123]; i.e., “a batch of objects”) from dataset 404 which satisfy a given time threshold-- …
and
performing, by the distributed workflow system, a computation (“examines datasets” [0168]) associated with the distributed workflow using the batch of data objects (“The real-time 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” [0168]) – As taught in ¶0168, real-time analytics application 506 examines and transforms data in order to make a conclusion about the data.
Although Gold ¶0170 discloses that analytics application 422 and real-time analytics application 506 each “consume” respective portions of the same dataset 404 in order to examine data, Gold is silent regarding an analytics application copying data consumed from the shared memory resources into a local memory. Specifically, Gold is silent regarding 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 real-time analytics application 506 of Gold Fig. 5 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 real-time analytics application 506 and the environment depicted in Gold Fig. 5, 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 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 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 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 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)(hereafter referred to as Ruan).
Regarding Claim 3,
Gold discloses the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above), wherein the distributed workflow is associated with a … framework (“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 is 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 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 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,
Gold discloses the following limitations:
The method of claim 17 (see Claim 17 limitation mappings above), wherein the distributed workflow is associated with a … framework (“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 is 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 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 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 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)(hereafter referred to as APACHE ‘23).
Regarding Claim 4,
Gold discloses 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. (“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 is 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 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 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,
Gold discloses 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 (“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 is 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 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 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,
Gold discloses 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. (“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 is 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 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 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,
Gold discloses 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 (“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 “Apache Arrow” type of memory format for data storage. Specifically, Gold is 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 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 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 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 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 (“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 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, 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 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 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 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 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, 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 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 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 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, 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 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, 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
The previous objection to the Specification is withdrawn in view of the replacement specification.
The previous 35 U.S.C. 112(b) rejections of Claims 3,5,10, 12-13, 19, and 21 are withdrawn in view of the instant claim amendments.
Applicant's arguments filed 03/09/2026 have been fully considered but they are not persuasive.
With respect to applicant’s argument located within the 2nd paragraph of the 2nd page of remarks (numbered as page 12), which recites:
“Examiner's rejection, the cited sections of the applied reference, whether taken alone or in any reasonable combination, does not disclose at least "wherein the direct access connections enable each host device, of the multiple host devices, to access the dataset via the respective direct access connection and by using a zero-copy access technique that does not require the host device copy the dataset to a local memory to extract a batch of data objects from the dataset for performing a computation associated with the distributed workflow," as recited in claim 1, as amended (emphasis added). The Office Action relies on paragraphs 0166, 0168, and 0170 of GOLD for allegedly disclosing "wherein the direct access connections enable each host device, of the multiple host devices, to access the dataset via the respective direct access connection and by using an access technique that does not require the host device copy the dataset to a local memory to extract a batch of data objects from the dataset for performing a computation associated with the distributed workflow," as recited in previously presented claim 1. See Office Action, page 6. Even assuming that the Examiner's interpretation of GOLD is reasonable, which Applicant does not concede, Applicant respectfully submits that the cited portions of GOLD does not disclose the features recited in amended claim 1.”
Examiner has fully considered the aforementioned argument but does not find it persuasive. Applicant argues that Gold fails to disclose the claimed concept of “wherein the direct access connections enable each host device, of the multiple host devices, to access the dataset via the respective direct access connection and by using a zero-copy access technique that does not require the host device copy the dataset to a local memory to extract a batch of data objects from the dataset for performing a computation associated with the distributed workflow” at least because Gold at least fails to disclose the “zero-copy access technique” as currently claimed. Examiner respectfully disagrees with applicant’s characterization of the teachings of Gold, and therefore maintains the 35 U.S.C. 102 rejection of independent claims as amended over Gold. See 35 U.S.C. 102 rejections above and discussion of Gold below for further details.
In addition, applicant appears to concede that the outstanding rejection relies on sections of Gold other than ¶0166 (e.g., ¶¶0168, 0170), but applicant’s remarks fail to address any section of Gold other than ¶0166. Examiner notes that the outstanding rejection does not solely rely on Gold ¶0166 for the aforementioned teaching, but provides additional mappings to other sections of Gold (e.g., Fig. 5 step 504 and ¶0170; see 12/10/2025 Non-Final pg. 6). Applicant’s focus only on ¶0166 of Gold suggests that examiner’s rejection relies only on the aforementioned teaching of Gold for the aforementioned claimed limitation, which is a mischaracterization of the outstanding rejection. Therefore, applicant’s arguments with respect to Gold are not persuasive when considering the rejection as a whole. See discussion of Gold below for additional details.
With respect to applicant’s argument located within the final paragraph of the 3rd page of remarks, which recites:
“As such, GOLD discusses that the dataset may be "ingested" into the storage system of the analytics application, where portions of the dataset are stored in different slices. However, GOLD does not disclose at least "wherein the direct access connections enable each host device, of the multiple host devices, to access the dataset via the respective direct access connection and by using a zero-copy access technique that does not require the host device copy the dataset to a local memory to extract a batch of data objects from the dataset for performing a computation associated with the distributed workflow," as recited in claim 1, as amended (emphasis added). According to the cited sections of GOLD, the storage system of the analytics application stores the dataset in slices within the same storage system.”
Examiner has fully considered the aforementioned argument but does not find it persuasive. Applicant argues that the disclosure of Gold ¶0166 (i.e., the embodiment of Gold Fig. 4) fails to disclose the claimed concept of “wherein the direct access connections enable each host device, of the multiple host devices, to access the dataset via the respective direct access connection and by using a zero-copy access technique that does not require the host device copy the dataset to a local memory to extract a batch of data objects from the dataset for performing a computation associated with the distributed workflow” as recited in the claims as currently presented at least because the storage system of the cited section of Gold stores a dataset in slices within a same storage system. Examiner respectfully disagrees, and first notes that the outstanding rejection relies on the embodiment of Gold Fig. 5 (e.g., ¶0170), as opposed to the embodiment of Gold Fig. 4. Therefore, applicant’s arguments are not persuasive.
As taught in Gold ¶0170 and shown in Fig. 5, in order to perform computations on dataset 404 (e.g., during step 414 of Fig. 5; see ¶0166 for explanation of step 414 of Fig. 5), respective hosts (e.g., Processing Resources 416, 418, and 420, respectively) do not need access to the entire dataset 404 in order to execute respective analytics applications; but instead need “only consume portions of the dataset (404)”. As further clarified in ¶0170, analytics applications “do not need to retain copies of the dataset in storage … that is only accessible to by the processing resources that are being used to execute the analytics application” (Emphasis Added). Examiner considers an action of retaining at least a portion of a dataset in a memory which is only accessible by a particular processing resources as an example of “copy[ing] the dataset to a local memory” (i.e., a local memory of a processing resource executing an analytics application). Therefore, examiner considers step 414 of Gold Fig. 5 as reading on the claimed concept of “a zero-copy access technique that does not require the device copy the dataset to a local memory extract a batch of data objects from the dataset for performing a computation associated with the distributed workflow” because as taught in Gold ¶0170, hosts instead access dataset 404 from “a single copy of the dataset (404) that is stored within the storage system (406)”. Nothing in the claims as currently presented precludes such an interpretation of Claim 1.
With respect to applicant’s argument located within the 1st paragraph of the 5th page of remarks (numbered as page 15), which recites:
The Office Action relies on paragraphs 0166 and 0168 of GOLD for allegedly disclosing "access the dataset via the direct access connection and by using a zero-copy access technique," as recited in previously presented claim 8. See Office Action, page 14. The Office Action does not rely on EUM as allegedly disclosing these features. See Office Action, pages 13-16. Even assuming that the Examiner's interpretation of GOLD and EUN is reasonable, which Applicant does not concede, Applicant respectfully submits that the cited portions of GOLD and EUN do not disclose the features recited in amended claim 8.
As further discussed above with reference to independent claim 1, and as discussed during the interview, the cited portion of GOLD discloses that the analytics application (executing on the processing resources in the storage system) ingests a dataset, which is stored in the storage system in multiple slices that each represent a portion of the dataset. As such, GOLD discusses that the dataset may be "ingested" into the storage system of the analytics application, and stored in different slices. However, GOLD does not disclose at least "access the dataset via the direct access connection and by using a zero-copy access technique," as recited in claim 8, as amended (emphasis added). EUN does not cure these deficiencies of GOLD.
Examiner has fully considered the aforementioned argument but does no find it persuasive. Applicant argues that the combined teachings of Gold and Eun do not disclose the concept of “access the dataset via the direct access connection and by using a zero-copy access technique” as recited in Claim 8 at least because Gold does not disclose the claimed concept of “a zero-copy access technique” as discussed with respect to Claim 1 above. Examiner respectfully disagrees for the same reasoning presented above with respect to Claim 1.
With respect to applicant’s argument located within the 1st paragraph of the 6th page of remarks (numbered as page ) which recites:
“Claims 2-5 depend from independent claim 1, claims 10-13 depend from independent claim 8, and claims 18-21 depend from independent claim 17. Therefore, these claims are patentable for at least the reasons set forth above with respect to their parent claims and for their additional distinguishing features recited therein.”
Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sahin et al. (US 20220100687 A1) – Discloses a zero-copy technique for communication with storage resources via RDMA in a fabric environment (see Abstract)
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