DETAILED ACTION
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 Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 8 and 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over David et al. (US PGPUB 2021/0216569) in view of Bhatia (US PGPUB 2023/0214249).
With regard to Claim 1, David teaches a system, comprising:
a processor executing an application ([0030] “the data storage system management software may execute on a processor of the data storage system 12.” [0021] “For example, an application executing on one of the host computers 14a-14n may perform a read or write operation resulting in one or more data requests to the data storage system 12.”);
a first memory connected to the processor (Fig. 1: Physical Storage Device 16a within Data Storage System 12.);
a second memory connected to the processor (Fig. 1: Physical Storage Device 16b within Data Storage System 12.); and
a data structure, the data structure including at least an entry, the entry identifying that a data is stored in a location, the location including one of the first memory or the second memory ([0043] “Referring to FIG. 2, shown is an example illustrating logical to physical mapping in a data storage system. The example 100 illustrates how the logical address space or range of a LUN 102 is mapped via mapping layer 104 to different slices, segments or more generally, portions of physical memory of non-volatile physical storage devices (110) providing back-end data storage, such as denoted by PDs 16a-n in FIG. 1... Element 102 may denote the LUN's logical address space, having a starting logical address, block or offset of 0, and an ending maximum logical address, MAX.” [0087] “In at least one embodiment, each destination interval represented by a node in the destination interval tree may include the information of each node as illustrated in the FIG. 4 as well as one or more additional fields... the destination node may include the source LUN identifier and the start LBA that may be used to uniquely identify the corresponding source node serving as the Xcopy source for the destination node,” wherein the “destination interval tree” is the “data structure” and further wherein the “start LBA” indicates a location which includes one of the “Physical Storage Devices” 16a or 16b, i.e. in an embodiment consisting of only two “Physical Storage Devices”.).
With further regard to claim 1, David does not teach the processor accessing the data as described in claim 1. Bhatia teaches
wherein the processor is configured to access the data from the location based at least in part on the data structure and a data access request from the application ([0021] “VMX 120 on host-A 110A may run/support containers... The containers in turn share the guest OS 122... with each of these containers running as isolated processes (e.g., executing a respective application 124).” [0051] “the method 500 of FIG. 5 may be performed by the container volume driver 140 at a host to detect, grant/deny, or otherwise manage multiple read/write requests (I/O requests).” [0053] “At a block 502 (‘DETECT ACCESS REQUEST FROM A CONTAINER’), the container volume driver 140 detects an access request (e.g., an I/O request such as a read request or a write request) issued by an application.” [0055] “the container volume driver 140 fetches the start and end offset addresses of the PV from the incoming access request... the container volume driver 140 checks the interval tree data structure 400 to determine if there are any active owners currently working on the entire or partial address range requested by the access request.” [0057] “If the container volume driver 140 determines that the requesting container is allowed simultaneous/concurrent access to the shared PV along with the current owner (‘YES’ at the block 510), then...updates the existing node of the interval tree data structure 400, by appending the new owner details... at a block 514 (‘ALLOW ACCESS AND UPDATE INTERVAL TREE DATA STRUCTURE’),” wherein Bhatia discloses that the host processor, as taught above in David, is also able to execute an application and access data based on the data structure and an access request form the application.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the system as disclosed by David with the processor accessing the data based on the data structure and access request as taught by Bhatia in order “to manage multiple concurrent read/write requests directed towards a shared storage location” (Bhatia [0082]).
With regard to claim 3, David in view of Bhatia teaches all the limitations of claim 1 as described above. Bhatia further teaches wherein:
the data structure includes a scalable interval tree; and the entry includes a node in the scalable interval tree ([0059] “the container volume driver 140 updates the lower offset address of the node of the interval tree data structure 400 to lowVal2.” [0061] “the container volume driver 140 updates the higher offset address of the node of the interval tree data structure 400 to high Val2.” [0070] “The interval tree data structure 400 is updated as described above by the container volume driver 140, which also updates the maximum range of addresses accessible by all readers,” wherein since the address range of the “interval tree” in Bhatia is able to modified, i.e. by adjusting the “lower offset address” and the “higher offset address”, the “interval tree” in Bhatia is equivalent to the “scalable interval tree” as claimed.).
With regard to Claim 8, David teaches a method, comprising:
receiving a data access request for a data from an application executing on a processor ([0030] “the data storage system management software may execute on a processor of the data storage system 12.” [0019] “The processors included in the host systems 14a-14n and data storage system 12 may be any one of a variety of proprietary or commercially available single or multi-processor system.” [0021] “any one of the host computers 14a-14n may issue a data request to the data storage system 12 to perform a data operation. For example, an application executing on one of the host computers 14a-14n may perform a read or write operation resulting in one or more data requests to the data storage system 12.” [0138] “At the step 1002, a read I/O operation is received from the host.”);
identifying, by the processor, a data structure based on the data access request ([0009] “processing may include: receiving, from a client, a read I/O operation that reads from a first target location; determining that the first target location overlaps with a second destination interval of a second destination node of the destination interval tree.” [0111] “Processing of the read I/O operation as part of the I/O path may include searching the destination interval tree to determine whether the target location intersects or overlaps any existing destination interval for the target LUN stored in the destination interval tree.” [0115] “In connection with servicing the write I/O operation as part of the I/O path, processing may include searching the source interval tree to determine whether the write target location intersects or overlaps a source interval of a source node of the source interval tree,” wherein either the “destination interval tree” or “source interval tree” in David is identified to be used based on the data access request, i.e. whether the request is a read or write request.);
identifying, by the processor, an entry in the data structure based on the data access request; identifying, by the processor, a location storing the data based on the entry in the data structure ([0043] “Referring to FIG. 2, shown is an example illustrating logical to physical mapping in a data storage system. The example 100 illustrates how the logical address space or range of a LUN 102 is mapped via mapping layer 104 to different slices, segments or more generally, portions of physical memory of non-volatile physical storage devices (110) providing back-end data storage, such as denoted by PDs 16a-n in FIG. 1... Element 102 may denote the LUN's logical address space, having a starting logical address, block or offset of 0, and an ending maximum logical address, MAX.” [0044] “Consistent with discussion herein, the data storage system may receive a host I/O that reads or writes data to a target location expressed as a LUN and offset, logical address, track, etc. on the LUN. The target location is a logical LUN address that may map to a physical storage location where data stored at the logical LUN address is stored.”); and
wherein the location includes a first memory or a second memory (Fig. 1: Physical Storage Device 16a/16b within Data Storage System 12. [0042] “the data storage system may include multiple SSD tiers of non-volatile storage where each of the SSD tiers has different characteristics that affect latency when accessing the physical storage media to read or write data.” See Figs. 9a-9b, for example, [0143] “At the step 1018, processing is performed to read data for the target location from a physical storage location based on the location MD for the target location. The data read from the physical storage location is returned as the content of the target location.”).
With further regard to claim 8, David does not teach the processor accessing the data as described in claim 8. Bhatia teaches
accessing, by the processor, the data from the location, and wherein the processor is configured to access the data from the location based at least in part on the data structure and a data access request from the application ([0021] “VMX 120 on host-A 110A may run/support containers... The containers in turn share the guest OS 122... with each of these containers running as isolated processes (e.g., executing a respective application 124).” [0051] “the method 500 of FIG. 5 may be performed by the container volume driver 140 at a host to detect, grant/deny, or otherwise manage multiple read/write requests (I/O requests).” [0053] “At a block 502 (‘DETECT ACCESS REQUEST FROM A CONTAINER’), the container volume driver 140 detects an access request (e.g., an I/O request such as a read request or a write request) issued by an application.” [0055] “the container volume driver 140 fetches the start and end offset addresses of the PV from the incoming access request... the container volume driver 140 checks the interval tree data structure 400 to determine if there are any active owners currently working on the entire or partial address range requested by the access request.” [0057] “If the container volume driver 140 determines that the requesting container is allowed simultaneous/concurrent access to the shared PV along with the current owner (‘YES’ at the block 510), then...updates the existing node of the interval tree data structure 400, by appending the new owner details... at a block 514 (‘ALLOW ACCESS AND UPDATE INTERVAL TREE DATA STRUCTURE’),” wherein Bhatia discloses that the host processor, as taught above in David, is also able to execute an application and access data based on the data structure and an access request form the application.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by David with the processor accessing the data based on the data structure and access request as taught by Bhatia in order “to manage multiple concurrent read/write requests directed towards a shared storage location” (Bhatia [0082]).
With regard to Claim 11, this claim is equivalent in scope to Claim 8 rejected above, and as such Claim 11 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 8.
With further regard to Claim 11, the claim recites additional elements not specifically addressed in the rejection of Claim 8. The David reference also anticipates these additional elements of Claim 11, for example, David teaches:
receiving the data access request for the data from the application executing on the processor includes receiving a second data access request for a second data from the application executing on the processor ([0021] “For example, an application executing on one of the host computers 14a-14n may perform a read or write operation resulting in one or more data requests to the data storage system 12,” wherein the “second data access request” is a second of the “one or more data requests to the data storage system”.).
With regard to claim 12, David in view of Bhatia teaches all the limitations of claim 8 as described above. Bhatia further teaches:
wherein accessing, by the processor, the data from the location includes accessing, by the processor, the data from the location by the processor ([0021] “VMX 120 on host-A 110A may run/support containers... The containers in turn share the guest OS 122... with each of these containers running as isolated processes (e.g., executing a respective application 124).” [0051] “the method 500 of FIG. 5 may be performed by the container volume driver 140 at a host to detect, grant/deny, or otherwise manage multiple read/write requests (I/O requests).” [0053] “At a block 502 (‘DETECT ACCESS REQUEST FROM A CONTAINER’), the container volume driver 140 detects an access request (e.g., an I/O request such as a read request or a write request) issued by an application.” [0057] “If the container volume driver 140 determines that the requesting container is allowed simultaneous/concurrent access to the shared PV along with the current owner (‘YES’ at the block 510), then...updates the existing node of the interval tree data structure 400, by appending the new owner details... at a block 514 (‘ALLOW ACCESS AND UPDATE INTERVAL TREE DATA STRUCTURE’).”).
With regard to claim 13, David in view of Bhatia teaches all the limitations of claim 8 as described above. Bhatia further teaches:
wherein accessing, by the processor, the data from the location includes issuing, by the processor, an input/output (I/O) request to a device, the device including the first memory ([0021] “VMX 120 on host-A 110A may run/support containers... The containers in turn share the guest OS 122... with each of these containers running as isolated processes (e.g., executing a respective application 124).” [0051] “the method 500 of FIG. 5 may be performed by the container volume driver 140 at a host to detect, grant/deny, or otherwise manage multiple read/write requests (I/O requests).” [0053] “At a block 502 (‘DETECT ACCESS REQUEST FROM A CONTAINER’), the container volume driver 140 detects an access request (e.g., an I/O request such as a read request or a write request) issued by an application.” [0057] “If the container volume driver 140 determines that the requesting container is allowed simultaneous/concurrent access to the shared PV along with the current owner (‘YES’ at the block 510), then...updates the existing node of the interval tree data structure 400, by appending the new owner details... at a block 514 (‘ALLOW ACCESS AND UPDATE INTERVAL TREE DATA STRUCTURE’).”).
Claims 2 and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over David in view of Bhatia as applied to Claims 1 and 8 above, and further in view of Wang et al. (US PGPUB 2024/0045804).
With regard to claim 2, David in view of Bhatia teaches all the limitations of claim 1 as described above. David in view of Bhatia does not teach the access request intercepting as described in claim 2. Wang teaches
further comprising a library to intercept a data access request from the application executing on the processor to access the data ([0074] “the SM libraries 521-523 may intercept requests by the host devices 501-503, respectively, to access pages of the shared memory 530 and communicate with the SM manager 510 to determine whether to grant the access request. More specifically, an SM library may determine whether to grant access to a particular page of the shared memory 530 based on the owner state of the requested page, the host state of the requestor, and the requested access type (such as read or write access).” [0089] “when an application executing on a particular host device requires access to the shared memory 530, the SM library residing on that host device may negotiate with the SM manager 510 to acquire the necessary lock associated with the requested access type (such as read or write access) and map the shared memory 530 with the granted access type.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the system as disclosed by David in view of Bhatia with the access request intercepting as taught by Wang in order “to maintain cache coherency and access synchronization” (Wang [0089]).
With regard to Claims 9-10, these claims are equivalent in scope to Claim 2 rejected above, merely having a different independent claim type, and as such Claims 9-10 are respectively rejected under the same grounds and for the same reasons as discussed above with regard to Claim 2.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over David in view of Bhatia as applied to Claims 1 and 8 above, and further in view of Raju et al. (US PGPUB 2020/0192864).
With regard to claim 4, David in view of Bhatia teaches all the limitations of claim 1 as described above. David in view of Bhatia does not teach the lock management functionality as described in claim 4. Raju teaches wherein
the entry includes a lock ([0022] “In an aspect, when a lock request for a given resource and range is submitted to a node of the platform, a lock manager associated with that node can determine whether the lock request can be satisfied. For instance, the lock manager can consult an interval tree or other suitable data structure that tracks ranges within the resource in order to determine any existing lock owners with ranges that intersect the requested range, any lock waiters with ranges that intersect the requested range, or the like.”); and
the lock is associated with a thread of an application executing on the processor, the thread requesting access to the data ([0034] “the lock initiator component 210 can manage locks for multiple resources, as well as multiple threads of execution that can have locks on different resources,” wherein the “thread of execution” is necessarily associated with “an application running on the processor”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the system as disclosed by David in view of Bhatia with the lock management functionality as taught by Raju so that “Power consumption, processing cycles, and/or other computing resources associated with traversing a data structure, such as a data structure for lock management, can be reduced” (Raju [0024]).
With regard to claim 14, David in view of Bhatia teaches all the limitations of claim 8 as described above. David in view of Bhatia does not teach the lock management functionality as described in claim 14. Raju teaches wherein:
receiving the data access request for the data from the application executing on the processor includes receiving the data access request for the data from a thread of the application executing on the processor ([0034] “the lock initiator component 210 can manage locks for multiple resources, as well as multiple threads of execution that can have locks on different resources,” wherein the “thread of execution” is necessarily associated with “the application running on the processor”.); and
accessing, by the processor, the data from the location includes applying, by the processor, a lock to the entry in the data structure for use by the thread ([0022] “In an aspect, when a lock request for a given resource and range is submitted to a node of the platform, a lock manager associated with that node can determine whether the lock request can be satisfied. For instance, the lock manager can consult an interval tree or other suitable data structure that tracks ranges within the resource in order to determine any existing lock owners with ranges that intersect the requested range, any lock waiters with ranges that intersect the requested range, or the like.” [0033] “If the satisfiability component 220 determines that the requested lock can be granted, e.g., by way of absence of contending locks or lock requests, the satisfiability component 220 can grant the requested lock and add the requester as a lock owner for the requested resource.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by David in view of Bhatia with the lock management functionality as taught by Raju so that “Power consumption, processing cycles, and/or other computing resources associated with traversing a data structure, such as a data structure for lock management, can be reduced” (Raju [0024]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over David in view of Bhatia as applied to Claim 1 above, and further in view of Lo et al. (US PGPUB 2018/0321980).
With regard to claim 5, David in view of Bhatia teaches all the limitations of claim 1 as described above. David in view of Bhatia does not teach the estimating of processing times as described in claim 5. Lo teaches further comprising
an analysis engine to calculate a first estimated time for a processing request, from an application executing on the processor, on a target data on the processor and a second estimated time for the processing request, from the application executing on the processor, on a second processor ([0048] “the applicability of the disclosed technology and the term ‘computing core’ encompasses, and is not limited to, ... a central processor unit.” [0161] “At 104, execution time of the plurality of program tasks on one or more computing cores is estimated. Each program feature is mapped to an execution time estimate on a selected computing core.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the system as disclosed by David in view of Bhatia with the estimating of processing times as taught by Lo in order to “intelligently select a computing core in a heterogeneous system to optimize task execution” (Lo [0048]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over David in view of Bhatia and Lo as applied to Claim 5 above, and further in view of Wang.
With regard to claim 6, David in view of Bhatia and Lo teaches all the limitations of claim 5 as described above. David in view of Bhatia and Lo does not teach the processing request intercepting as described in claim 6. Wang teaches
further comprising a library to intercept the processing request from the application executing on the processor ([0074] “the SM libraries 521-523 may intercept requests by the host devices 501-503, respectively, to access pages of the shared memory 530 and communicate with the SM manager 510 to determine whether to grant the access request. More specifically, an SM library may determine whether to grant access to a particular page of the shared memory 530 based on the owner state of the requested page, the host state of the requestor, and the requested access type (such as read or write access),” wherein the “processing request” is a “data access request”. [0089] “when an application executing on a particular host device requires access to the shared memory 530, the SM library residing on that host device may negotiate with the SM manager 510 to acquire the necessary lock associated with the requested access type (such as read or write access) and map the shared memory 530 with the granted access type.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the system as disclosed by David in view of Bhatia and Lo with the processing request intercepting as taught by Wang in order “to maintain cache coherency and access synchronization” (Wang [0089]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over David in view of Bhatia and Lo as applied to Claim 5 above, and further in view of Suarez Garcia et al. (US PGPUB 2017/0060633; hereinafter “Suarez”).
With regard to claim 7, David in view of Bhatia and Lo teaches all the limitations of claim 5 as described above. David in view of Bhatia and Lo does not teach the data location determining as described in claim 7. Suarez teaches wherein the analysis engine is configured to:
determine that a first part of the target data is stored in the first memory and a second part of the target data is stored in the second memory ([0048] “In order to efficiently estimate data transfer costs for transferring data needed for performing the tasks, some embodiment techniques may identify data dependencies of tasks with regard to processing units and/or the locations of data. For example, a scheduler or runtime functionality may identify that a first and second task may both require data of a first buffer stored within a first data storage unit.” [0051] “FIG. 2B is a component diagram 250 illustrating exemplary accesses of buffer data (i.e., buffers 254a, 254b, 254c-254n) by a plurality of processing units 252a-252n in order to execute the plurality of exemplary tasks 201-206 as described with reference to FIG. 2A. In particular, FIG. 2B illustrates that a first task 201, fourth task 204, and sixth task 206 may be assigned to execute on a CPU 252a, requiring data of a first buffer 254a and a fourth buffer 254n...,” wherein Fig. 2B shows the type of information resulting from the data location determining process described in Suarez [0048].).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the system as disclosed by David in view of Bhatia and Lo with the data location determining as taught by Suarez in order “to improve efficiency of task executions with regard to data transfers and thus reduce unnecessary flushing and other drawbacks that may be present in systems lacking coherency” (Suarez [0030]).
With further regard to Claim 7, Lo further teaches wherein the analysis engine is configured to:
calculate a first estimated time for the processor to execute the processing request from the application executing on the processor; and calculate a second estimated time for the second processor to execute the processing request from the application executing on the processor ([0048] “the applicability of the disclosed technology and the term ‘computing core’ encompasses, and is not limited to, ... a central processor unit.” [0161] “At 104, execution time of the plurality of program tasks on one or more computing cores is estimated. Each program feature is mapped to an execution time estimate on a selected computing core.”).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over David in view of Lo.
With regard to Claim 15, David teaches a method, comprising:
receiving a processing request from an application executing on a first processor, the processing request to be applied to a data ([0019] “The processors included in the host systems 14a-14n and data storage system 12 may be any one of a variety of proprietary or commercially available single or multi-processor system.” [0021] “any one of the host computers 14a-14n may issue a data request to the data storage system 12 to perform a data operation. For example, an application executing on one of the host computers 14a-14n may perform a read or write operation resulting in one or more data requests to the data storage system 12,” wherein the “data request... to perform a data operation” is the “processing request”. [0138] “At the step 1002, a read I/O operation is received from the host.”).
With further regard to claim 15, David does not teach the analyzing of a processing request as described in claim 15. Lo teaches further comprising
performing an analysis of the processing request to determine a target to execute the processing request, the target including the first processor or a second processor associated with a device ([0048] “the applicability of the disclosed technology and the term ‘computing core’ encompasses, and is not limited to, ... a central processor unit.” [0161] “At 104, execution time of the plurality of program tasks on one or more computing cores is estimated. Each program feature is mapped to an execution time estimate on a selected computing core.”); and
dispatching the processing request to the target, wherein the analysis is used to expedite processing of the processing request ([0164] “The controller migrates a job that cannot meet its deadline on the little core to a big core based on the predicted execution time.”)
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the system as disclosed by David with the analyzing of a processing request as taught by Lo in order to “intelligently select a computing core in a heterogeneous system to optimize task execution” (Lo [0048]).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over David in view of Lo as applied to Claim 15 above, and further in view of Wang.
With regard to claim 6, David in view of Lo teaches all the limitations of claim 5 as described above. David in view of Lo does not teach the processing request intercepting as described in claim 6. Wang teaches
wherein receiving the processing request from the application executing on the first processor includes intercepting the processing request for the data from the application executing on the first processor ([0074] “the SM libraries 521-523 may intercept requests by the host devices 501-503, respectively, to access pages of the shared memory 530 and communicate with the SM manager 510 to determine whether to grant the access request. More specifically, an SM library may determine whether to grant access to a particular page of the shared memory 530 based on the owner state of the requested page, the host state of the requestor, and the requested access type (such as read or write access),” wherein the “processing request” is a “data access request”. [0089] “when an application executing on a particular host device requires access to the shared memory 530, the SM library residing on that host device may negotiate with the SM manager 510 to acquire the necessary lock associated with the requested access type (such as read or write access) and map the shared memory 530 with the granted access type.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by David in view of Lo with the processing request intercepting as taught by Wang in order “to maintain cache coherency and access synchronization” (Wang [0089]).
Claims 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over David in view of Lo as applied to Claim 15 above, and further in view of Suarez.
With regard to claim 17, David in view of Lo teaches all the limitations of claim 15 as described above. David in view of Lo does not teach the data location determining as described in claim 17. Suarez teaches wherein:
performing the analysis of the processing request to determine the target to execute the processing request includes determining that the data is stored in a memory associated with of the first processor; and dispatching the processing request to the target includes dispatching the processing request to the first processor ([0048] “In order to efficiently estimate data transfer costs for transferring data needed for performing the tasks, some embodiment techniques may identify data dependencies of tasks with regard to processing units and/or the locations of data. For example, a scheduler or runtime functionality may identify that a first and second task may both require data of a first buffer stored within a first data storage unit.” [0051] “FIG. 2B is a component diagram 250 illustrating exemplary accesses of buffer data (i.e., buffers 254a, 254b, 254c-254n) by a plurality of processing units 252a-252n in order to execute the plurality of exemplary tasks 201-206 as described with reference to FIG. 2A. In particular, FIG. 2B illustrates that a first task 201, fourth task 204, and sixth task 206 may be assigned to execute on a CPU 252a, requiring data of a first buffer 254a and a fourth buffer 254n...,” wherein Fig. 2B shows the type of information resulting from the data location determining process described in Suarez [0048].).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by David in view of Lo with the data location determining as taught by Suarez in order “to improve efficiency of task executions with regard to data transfers and thus reduce unnecessary flushing and other drawbacks that may be present in systems lacking coherency” (Suarez [0030]).
With regard to claim 18, David in view of Lo teaches all the limitations of claim 15 as described above. David in view of Lo does not teach the data location determining as described in claim 18. Suarez teaches wherein performing the analysis of the processing request to determine the target to execute the processing request includes:
determining that a first part of the data is stored in a first memory associated with the first processor and a second part of the data is stored in a second memory associated with the second processor ([0048] “In order to efficiently estimate data transfer costs for transferring data needed for performing the tasks, some embodiment techniques may identify data dependencies of tasks with regard to processing units and/or the locations of data. For example, a scheduler or runtime functionality may identify that a first and second task may both require data of a first buffer stored within a first data storage unit.” [0051] “FIG. 2B is a component diagram 250 illustrating exemplary accesses of buffer data (i.e., buffers 254a, 254b, 254c-254n) by a plurality of processing units 252a-252n in order to execute the plurality of exemplary tasks 201-206 as described with reference to FIG. 2A. In particular, FIG. 2B illustrates that a first task 201, fourth task 204, and sixth task 206 may be assigned to execute on a CPU 252a, requiring data of a first buffer 254a and a fourth buffer 254n...,” wherein Fig. 2B shows the type of information resulting from the data location determining process described in Suarez [0048].).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by David in view of Lo with the data location determining as taught by Suarez in order “to improve efficiency of task executions with regard to data transfers and thus reduce unnecessary flushing and other drawbacks that may be present in systems lacking coherency” (Suarez [0030]).
With further regard to Claim 18, Lo further teaches wherein performing the analysis of the processing request to determine the target to execute the processing request includes:
calculating a first estimated time for the first processor to execute the processing request; and calculating a second estimated time for the second processor to execute the processing request ([0048] “the applicability of the disclosed technology and the term ‘computing core’ encompasses, and is not limited to, ... a central processor unit.” [0161] “At 104, execution time of the plurality of program tasks on one or more computing cores is estimated. Each program feature is mapped to an execution time estimate on a selected computing core.”).
With regard to claim 19, David in view of Lo and Suarez teaches all the limitations of claim 18 as described above. Lo further teaches
wherein dispatching the processing request to the target includes dispatching the processing request to the first processor, the second processor, or to both the first processor and the second processor based at least in part on the first estimated time and the second estimated time ([0052] “A job is defined as a dynamic instance of a task. As an illustrative example, FIG. 2 shows the concept of tasks, jobs, and deadlines in the software domain, wherein each job has a deadline, or a time budget, which is the time by which it must finish execution.” [0075] “This model is used at the beginning of each job's time budget to estimate the DVFS levels and core types that can meet the deadline for the job. Then, the controller migrate a job and/or adjust the DVFS level in order to meet the deadline with minimal energy consumption. In this embodiment, the controller adjusts a DVFS level on the little core before running Job 1 and Job 2 based on the execution time prediction. For Job 3, the predictor determines that the deadline cannot be met on the little core and migrates the job to the big core.” [0164] “The predicted execution times can also be used in a heterogeneous system to enable task migration from one computing core to another. The controller migrates a job that cannot meet its deadline on the little core to a big core based on the predicted execution time.”).
With regard to claim 20, David in view Lo and Suarez Lo teaches all the limitations of claim 18 as described above. Suarez further teaches wherein:
calculating the first estimated time for the first processor to execute the processing request includes calculating a first transfer time to transfer the second part of the data to the first memory associated with the first processor; and calculating a second estimated time for the second processor to execute the processing request includes calculating a second transfer time to transfer the first part of the data to the second memory associated with the second processor ([0042] “the time required for moving data needed by a task may be determined with an API query that includes only a size of data to transfer, a source identity of a source data storage unit, and a destination identity of a destination data storage unit.” [0048] “data transfer costs (e.g., times, etc.) may indicate costs associated with maintaining cache coherency when multiple tasks are performed in sequence. For example, the cost to transfer data for use by a second task may include not only a data transfer time, but also a time estimate based on the time to complete the use of the data by a first task. [0064] “the multi-processor computing device may estimate or otherwise calculate transfer times and power (energy) consumption for each of the tasks.”).
Response to Arguments
Applicant’s arguments, see 9-15 of the Remarks filed 4/15/2026, with respect to the rejections of Claims 1-20 under 35 U.S.C. 101 have been fully considered and are persuasive. The 35 U.S.C. 101 rejections of Claims 1-20 have been withdrawn.
Applicant’s arguments, see Pages 15-18 of the Remarks, with respect to the rejections under 35 U.S.C. 102 have been fully considered but they are not persuasive.
With respect to the Applicant’s first argument regarding Claim 1, Page 16 Paragraph 1 of the Remarks, that David does not teach the “data structure” since “the destination interval tree of David does not appear to support data movement,” the Office respectfully disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the data structure enables the data to be moved between the two memories”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
With respect to the Applicant’s next argument regarding Claim 1, Page 16 Paragraphs 2-3 of the Remarks, that the newly amended language of Claim 1 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Bhatia (US PGPUB 2023/0214249) reference as discussed above in the respective rejection.
With respect to the Applicant’s argument regarding Claim 3, Page 16 Paragraphs 5-7 of the Remarks, that David does not teach the “scalable interval tree”, this argument has been fully considered but is moot in view of the newly cited Bhatia (US PGPUB 2023/0214249) reference as discussed above in the respective rejection.
With respect to the Applicant’s first argument regarding Claim 8, Page 17 Paragraphs 2-3 of the Remarks, that David does not teach “identifying, by the processor, a data structure based on the data access request” since David does not appear to identify and then use a particular data structure, the Office respectfully disagrees. The rejection of Claim 8 now cites additional supporting disclosure to more clearly demonstrate that David does teach and make obvious this claim limitation, as David discloses the following:
[0009] “processing may include: receiving, from a client, a read I/O operation that reads from a first target location; determining that the first target location overlaps with a second destination interval of a second destination node of the destination interval tree.”
[0111] “Processing of the read I/O operation as part of the I/O path may include searching the destination interval tree to determine whether the target location intersects or overlaps any existing destination interval for the target LUN stored in the destination interval tree.”
[0115] “In connection with servicing the write I/O operation as part of the I/O path, processing may include searching the source interval tree to determine whether the write target location intersects or overlaps a source interval of a source node of the source interval tree.”
As such it has been shown that David does teach the identifying and use of a particular data structure based on a data access request, i.e. a “destination interval tree” for read operations and a “source interval tree” for write operations. Therefore, in view of at least the above citations and discussion, the Office maintains that David does teach and make obvious the limitation of Claim 8 which recites, “identifying, by the processor, a data structure based on the data access request.”
With respect to the Applicant’s next argument regarding Claim 8, Page 17 Paragraph 4 of the Remarks, that the newly amended language of Claim 8 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Bhatia (US PGPUB 2023/0214249) reference as discussed above in the respective rejection.
With respect to the Applicant’s argument regarding Claim 11, Page 18 Paragraph 1 of the Remarks, that David does not teach the limitations of Claim 11 since “The Office Action does not appear to have demonstrated that David teaches two different data access requests simply by asserting that David teaches one data access request,” the Office respectfully disagrees. The Office contends that a citation was provided in the rejection of Claim 11 to demonstrate that David does teach two different access requests being received and processed. For example, David discloses:
[0021] “For example, an application executing on one of the host computers 14a-14n may perform a read or write operation resulting in one or more data requests to the data storage system 12.”
The Office contends that the above citation provides a teaching for the “receiving” limitation of Claim 11, wherein the remaining additional “identifying” limitations are substantial duplicates of those found in Claim 8, discussed above as being taught by David in view of Bhatia. As such, the Office maintains that David in view of Bhatia does teach and make obvious the limitations of Claim 11.
With respect to the Applicant’s argument regarding Claim 12, Page 18 Paragraphs 3-5 of the Remarks, that the newly amended language is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Bhatia (US PGPUB 2023/0214249) reference as discussed above in the respective rejection.
With respect to the Applicant’s argument regarding Claim 4, Page 19 Paragraph 3 of the Remarks, that David does not teach the limitations of Claim 4 since “nowhere does Rajo appear to teach or suggest that this interval tree would also be an interval tree that tracks which memory stores a particular data,” the Office respectfully disagrees. The Office contends that the interval tree as taught by David has already been shown to disclose the claim limitations regarding “an interval tree that tracks which memory stores a particular data,” and it is the interval tree in David that is being modified to provide the additional lock functionality as taught by Raju. Furthermore, the Office notes that the interval tree in David is disclosed as having the capacity for additional added functionality, i.e. the lock functionality as taught by Raju, as David discloses the following:
[0087] “each destination interval represented by a node in the destination interval tree may include the information of each node as illustrated in the FIG. 4 as well as one or more additional fields.”
The Office contends that it would have been obvious to one of ordinary skill in the art that the interval tree in David, used for tracking data storage locations, could be modified to use the additional fields in each entry to store the lock information for implementing the locking functionality disclosed in Raju. As such, the Office maintains that David in view of Bhatia and Raju does teach and make obvious the limitations of Claim 4.
With respect to the Applicant’s arguments, Page 19 Paragraph 5 – Page 20 Paragraph 2 of the Remarks, that the features of Claim 14 are not taught by the cited prior art, the Office respectfully disagrees. This argument raises issues substantially similar to those presented in relation to Claim 4, and as such the Office directs the Applicant to the response above regarding these arguments.
With respect to the Applicant’s first argument regarding Claim 5, Page 20 Paragraphs 3-4 of the Remarks, that Lo does not teach the limitations of Claim 5 since “Lo does not appear to teach estimating the time required to complete a processing request: that response-time appears to be assumed as a target... Lo does not appear to be attempting to determine how long a particular task will take to execute on different processors,” the Office respectfully disagrees. The Office contends that the following citation provided in the rejection of Claim 5 demonstrates that Lo does teach calculating an estimated time for executing a processing request on different processors:
[0161] “At 104, execution time of the plurality of program tasks on one or more computing cores is estimated. Each program feature is mapped to an execution time estimate on a selected computing core.”
The Office would like to draw attention to the following additional disclosure in Lo:
[0005] “The method comprises... predicting execution time of the plurality of program tasks on one or more computing cores.”
[0075] “In the prediction-guided approach, the framework builds a model that can predict the execution time of each job. This model is used at the beginning of each job's time budget to estimate the DVFS levels and core types that can meet the deadline for the job. Then, the controller migrate a job and/or adjust the DVFS level in order to meet the deadline with minimal energy consumption.”
[0128] “With these two prediction models, the execution time and the new frequency for both cores can be predicted before running a job.”
The Office contends that the above citations in Lo provide further evidence that the disclosure originally cited in the rejection of Claim 5 does teach and make obvious the limitation which recites, “an analysis engine to calculate a first estimated time for a processing request, from an application executing on the processor, on a target data on the processor and a second estimated time for the processing request, from the application executing on the processor, on a second process”. Therefore, in view of the above discussion, the Office maintains that David in view of Bhatia and Lo does teach and make obvious the limitations of Claim 5.
With respect to the Applicant’s next argument regarding Claim 5, Page 21 Paragraph 1 of the Remarks, that Lo does not teach the limitations of Claim 5 since “First, the claim recites assigning the processing task to a processor, not a computing core. Second, ... Lo does not appear to teach, or even suggest, that a processing request might be assigned to a particular processor based on the estimated time to execute the processing request,” the Office respectfully disagrees.
With regard to the Applicant’s first argument, regarding the use of the phrase “computing core” in Lo versus the claimed “processor”, the Office would like to draw the Applicant’s attention to the following citation in Lo:
[0048] “the method can intelligently select a computing core in a heterogeneous system to optimize task execution. It is notable that, while the term ‘computing core’ is used to explain the disclosed technology, the applicability of the disclosed technology and the term ‘computing core’ encompasses, and is not limited to, a computing unit, a central processor unit, a hardware accelerator, a microprocessor, and a logic circuit that is programmed to execute instructions.”
Therefore, since Lo discloses that the use of the term “computing core” also encompasses terms such as “central processor unit”, i.e. the claimed “processor”, the Office maintains that that David in view of Bhatia and Lo does teach and make obvious the limitations of Claim 5.
In response to applicant's second argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “a processing request might be assigned to a particular processor based on the estimated time to execute the processing request”) are not recited in rejected claim 5. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
With respect to the Applicant’s arguments, Page 21 Paragraph 4 – Page 22 Paragraph 2 of the Remarks, that the features of Claim 15 are not taught by the cited prior art, the Office respectfully disagrees. This argument raises issues substantially similar to those presented in relation to Claim 5, and as such the Office directs the Applicant to the response above regarding these arguments.
Further, with regard to the fourth argument regarding Claim 15, Page 22 Paragraph 3, that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “Dispatching implies that the processing request is being assigned in the first instance to the target, and therefore is not being migrated from one core to another”) are not recited in rejected claim 15. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
With respect to the Applicant’s first argument regarding Claim 7, Page 23 Paragraph 1 of the Remarks, that Suarez Garcia does not teach the limitations of Claim 7 since “none of [the disclosure in Suarez Garcia] has anything to do with estimating how long it will take for a particular processing request to execute on two different processors (so that the processor that may complete execution of the processing request faster may be used),” the Office respectfully disagrees. The Office contends that Suarez Garcia was not relied on to teach those claim limitations, but rather it was Lo that was relied on to teach those claim limitations.
With respect to the Applicant’s second argument regarding Claim 7, Page 23 Paragraph 1 of the Remarks, that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, both the Suarez Garcia and Lo references are concerned with improving the efficiency of computer operations, as Suarez Garcia discloses in [0048] that it would be advantageous, “to efficiently estimate data transfer costs for transferring data needed for performing the tasks,” and Lo discloses in [0048] that it would be advantageous to, “intelligently select a computing core in a heterogeneous system to optimize task execution”.
As such, in view of the above discussion, the Office maintains that David in view of Bhatia and Lo does teach and make obvious the limitations of Claim 7.
With respect to the Applicant’s arguments, Page 23 Paragraphs 3-5 of the Remarks, that the features of Claim 17 are not taught by the cited prior art, the Office respectfully disagrees. This argument raises issues substantially similar to those presented in relation to Claim 7, and as such the Office directs the Applicant to the response above regarding these arguments.
With respect to the Applicant’s arguments, Page 24 Paragraphs 1-3 of the Remarks, that the features of Claim 18 are not taught by the cited prior art, the Office respectfully disagrees. This argument raises issues substantially similar to those presented in relation to Claim 5, and as such the Office directs the Applicant to the response above regarding these arguments.
Further, with regard to the third argument regarding Claim 18, Page 25 Paragraph 1, that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “Dispatching implies that the processing request is being assigned in the first instance to the target, and therefore is not being migrated from one core to another”) are not recited in rejected claim 18. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
With respect to the Applicant’s arguments, Page 25 Paragraph 5 - Page 26 Paragraph 3 of the Remarks, that the features of Claim 19 are not taught by the cited prior art, the Office respectfully disagrees. This argument raises issues substantially similar to those presented in relation to Claim 5, and as such the Office directs the Applicant to the response above regarding these arguments.
With respect to the Applicant’s first arguments regarding Claim 20, Page 26 Paragraph 7 of the Remarks, that the features of the claim are not taught by the cited prior art, the Office respectfully disagrees. This argument raises issues substantially similar to those presented in relation to Claim 7, and as such the Office directs the Applicant to the responses above regarding these arguments.
With respect to the Applicant’s second argument regarding Claim 20, Page 27 Paragraph 2 of the Remarks, that Suarez Garcia does not teach the limitations of Claim 20 since “Suarez Garcia describes ‘a time estimate based on the time to complete the use of the data by a first task’ (see Suarez Garcia, 48). But this time estimate is not the time estimated for a processing task to be performed using a particular processor,” the Office respectfully disagrees. The Office contends that Suarez Garcia was not relied on to teach those claim limitations, but rather it was Lo that was relied on to teach limitations regarding “calculating a first estimated time for the first processor to execute the processing request; and calculating a second estimated time for the second processor to execute the processing request,” as originally recited in Claim 18, which Claim 20 depends from. As such, the Office directs the Applicant to the rejection of Claim 18 above and the response above regarding the arguments associated with Claim 18.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Barrell et al. (US PGPUB 2019/0369874) discloses a methods and apparatuses for efficiently destaging sequential write data from a storage controller cache memory to storage devices of a striped volume, including use of an interval tree.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS J SIMONETTI whose telephone number is (571)270-7702. The examiner can normally be reached Monday-Thursday 10AM-6PM 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, Arpan Savla can be reached at (571) 272-1077. 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.
/NICHOLAS J SIMONETTI/Primary Examiner, Art Unit 2137 June 16, 2026
Prosecution Insights