DETAILED ACTION
This office action is in response claims filed 26 June 2023.
Claims 1-20 are pending.
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
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.
Claim(s) 1, 5-8. 11, 15-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over MA et al. Pub. No.: US 2016/0170886 A1 (hereafter MA), in view of LIM et al. Pub. No.: US 2020/0192831 A1 (hereafter LIM), in view of ROBINSON Patent No.: US 10,657,060 B1 (hereafter ROBINSON).
Regarding claim 1, MA teaches the invention substantially as claimed, including:
A method comprising:
receiving a first request to execute a first operation using a distributed architecture and in a uniform memory access (UMA) mode, wherein the distributed architecture comprises a first processor, a first memory that is local to the first processor, and a second memory that is remote to the first processor ([0083] The method 300 starts in decision block 301, where, a core, which is to perform a data read operation, based upon a memory address of data to be read, determines whether the core is responsible for caching the data (i.e., data read operation represents a “first request” to execute a read “operation” by a core, representing a “processor” of a distributed architecture illustrated at least in Fig. 2 having caches that are both “local” to a given core, and “remote” to a given core. Further, since any core can uniformly access the cache of any other remote core, thereby sharing the collective cache memories between the respective cores, this system describes a type of “uniform memory access mode”));
subsequent to receiving the first request…transmitting first data associated with the first operation to the first processor, wherein the first data is stored in the first memory([0068] If the core is responsible for caching the data, then the method 300 follows the YES branch and proceeds to step 302. [0076] if the method 300 proceeds to step 302, it is determined that the data to be read is cached by the requesting core' local cache. According to the theory of program locality and predictability mechanisms utilized by the hardware of a processor, the data to be read usually is a cache hit from the local cache of the requesting core (i.e., data for the data read operation is transmitted from cache that is local to the requesting core to the requesting core)); and
…transmitting second data associated with the first operation to the first processor, wherein the second data is stored in the second memory ([0068] If the core is responsible for caching the data, then the method 300 follows the YES branch and proceeds to step 302; otherwise, the method 300 follows the NO branch and proceeds to step 303. [0081] When the method 300 proceeds to step 303, it means that the data to be read is cached by a core other than the instant requesting core. In order to distinguish from the requesting core, a core responsible for caching such data is referenced herein as a remote core. Therefore, the requesting core does not search for the data in its local caches, instead, after step 301, it sends a data read request to the remote core having a labeling number matching the computed core labeling number, and receives from such remote core the returned data (i.e., data for the data read operation is transmitted from cache that is remote to the requesting core to the requesting core)).
While MA discusses transmitting data to a processor subsequent to receiving a request, MA does not explicitly teach:
subsequent to receiving the first request and a first delay period, transmitting first data associated with the first operation to the first processor
However, in analogous art that similarly teaches transmission of data to a processor, LIM teaches
subsequent to receiving the first request and a first delay period, transmitting first data associated with the first operation to the first processor ([0047] When the first, second and third processors 100, 200 and 300 read data from the main memory 400 for operation…The third processor 300 may read data from the main memory 400 at a predetermined delay time after receiving a command for operation (S310) (i.e., command for operation represents a “first request” and data is read by the third processor subsequent to the request and a predetermined delay time, representing the “first delay period”)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LIM’s teaching of transmitting data to a processor after a request and a delay time period, with MA’s teaching of transmitting data to a processor after a request, to realize, with a reasonable expectation of success, a system that transmits data to a processor after a request, as in MA, and after a delay, as in LIM. A person having ordinary skill would have been motivated to make this combination to ensure safety for data processing through data reading timing isolation (LIM [0044]).
While MA and LIM discuss transmitting data from local memory and external memory to a processor responsive to different requests, MA and LIM do not explicitly teach:
subsequent to receiving the first request, transmitting second data…wherein the second data is stored in the second memory
However, in analogous art that similarly teaches transmitting data from local memory and external memory, ROBINSON teaches”
subsequent to receiving the first request, transmitting second data…wherein the second data is stored in the second memory ([Column 6, Lines 55-59] FIG. 3 is a flowchart of an example process for performing a partial reconfiguration using prefetched data. The example process can be performed in response to the occurrence of an event that triggers the partial reconfiguration process. [Column 7, Lines 1-6] The device loads the initial portion of prefetched data from local buffer memory (320). This step typically occurs before a response from the external memory has been received. In other words, the device loads the prefetched data while waiting for the external memory to respond to the first memory request. [Column 7, Lines 11-14] The device receives and loads data at the first modified buffer offset (330). In other words, the device eventually receives a first response from the external memory and loads the received data for the partial reconfiguration (i.e., a single “first” request causes data to be transmitted from local memory, as “first data”, and from external memory, as “second data”)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined ROBINSON’s teaching of having a single request that triggers data to be transmitted from local memory and external memory, with the combination of MA and LIM’s teaching of transmitting data from local memory and external memory to a processor, to realize, with a reasonable expectation of success, a system that transmits data from local and external memory to a processor, as in MA and LIM, subsequent to receiving a single request for the data, as in ROBINSON. A person having ordinary skill would have been motivated to make this combination to decrease the amount of requests needed to receive all the data required for a task, thereby improving performance.
Regarding claim 5, MA further teaches:
the distributed architecture further comprises a first memory buffer ([0003] In order to buffer the ill-matched processing speeds of a CPU and a main memory, a high speed cache (i.e., cache as generally referred to) can be introduced therebetween (i.e., cache memory represents a type of “memory buffer”)).
Regarding claim 6, ROBINSON further teaches:
subsequent to receiving the first request, transmitting seventh data (([Column 6, Lines 55-59] FIG. 3 is a flowchart of an example process for performing a partial reconfiguration using prefetched data. The example process can be performed in response to the occurrence of an event that triggers the partial reconfiguration process. [Column 7, Lines 1-6] The device loads the initial portion of prefetched data from local buffer memory (320). This step typically occurs before a response from the external memory has been received. In other words, the device loads the prefetched data while waiting for the external memory to respond to the first memory request. [Column 7, Lines 11-14] The device receives and loads data at the first modified buffer offset (330). In other words, the device eventually receives a first response from the external memory and loads the received data for the partial reconfiguration (i.e., a single “first” request causes data to be transmitted from local memory, as “first data”, and from external memory, as second, or “seventh data”)).
MA further teaches:
…transmitting seventh data associated with the first operation to the first processor, wherein the seventh data is stored in the second memory ([0068] If the core is responsible for caching the data, then the method 300 follows the YES branch and proceeds to step 302; otherwise, the method 300 follows the NO branch and proceeds to step 303. [0081] When the method 300 proceeds to step 303, it means that the data to be read is cached by a core other than the instant requesting core. In order to distinguish from the requesting core, a core responsible for caching such data is referenced herein as a remote core. Therefore, the requesting core does not search for the data in its local caches, instead, after step 301, it sends a data read request to the remote core having a labeling number matching the computed core labeling number, and receives from such remote core the returned data (i.e., data, including “seventh data” for the data read operation is transmitted from cache that is remote to the requesting core to the requesting core)).
Regarding claim 7, MA further teaches:
the distributed architecture further comprises a first memory buffer, a second memory buffer, and a second processor ([0055] The cache consistency supporting multi-core processor 200 includes a plurality of cores 201-1, 201-2, 201-3, . . . , 201-n, where n is a natural number. Each of the plurality of cores has a two leveled local cache that includes a respective L1 cache 260_1, 260_2, 260_3, . . . , 260_n and a respective L2 cache 280_1, 280_2, 280_3, . . . , 280_n in addition to a respective CPU 240_1, 240_2, 240_3, . . . , 240_n. [0003] In order to buffer the ill-matched processing speeds of a CPU and a main memory, a high speed cache (i.e., cache as generally referred to) can be introduced therebetween (i.e., cache memory for each of the plural processors represents a type of “memory buffer”)),
the first processor is configured to retrieve data from the first memory buffer using a first memory access bus associated with the first processor and the first memory buffer ([0013] In response to a determination that the core is responsible for caching the data, reading the data from a local cache of the core . [0065] multiple processors couple with a memory block via a memory bus to form a node (i.e., in a first node, a first core retrieves data by reading it from a connected first local cache via a memory bus)), and
the second processor is configured to retrieve data from the second memory buffer using a second memory access bus associated with the first processor and the second processor and a third memory access bus associated with the second processor and the second memory buffer ([0055] The multi-core processor 200 can also include a memory controller 202 for the plurality of cores to access data in a memory space. A local cache of a different core of the plurality of cores is responsible for caching data in a different range of addresses in the memory space. A core of the plurality of cores accesses data in a local cache of another core of the plurality of cores via a interconnect bus or a main bus (not shown) (i.e., first core accesses data on a second cache associated with a second core using an interconnect bus representing a “second memory access bus” between first core and second core and the memory bus between second core and second cache, representing “third memory access bus”)).
Regarding claim 8, MA further teaches:
subsequent to receiving the first request…transmitting eighth data associated with the first operation to the first processor, wherein the eighth data is stored in the first memory buffer ([0068] If the core is responsible for caching the data, then the method 300 follows the YES branch and proceeds to step 302. [0076] if the method 300 proceeds to step 302, it is determined that the data to be read is cached by the requesting core' local cache. According to the theory of program locality and predictability mechanisms utilized by the hardware of a processor, the data to be read usually is a cache hit from the local cache of the requesting core (i.e., eighth data for the data read operation is transmitted from cache buffer that is local to the requesting core to the requesting core))…
transmitting ninth data associated with the first operation to the first processor, wherein the ninth data is stored in a memory attached to the second memory buffer ([0068] If the core is responsible for caching the data, then the method 300 follows the YES branch and proceeds to step 302; otherwise, the method 300 follows the NO branch and proceeds to step 303. [0081] When the method 300 proceeds to step 303, it means that the data to be read is cached by a core other than the instant requesting core. In order to distinguish from the requesting core, a core responsible for caching such data is referenced herein as a remote core. Therefore, the requesting core does not search for the data in its local caches, instead, after step 301, it sends a data read request to the remote core having a labeling number matching the computed core labeling number, and receives from such remote core the returned data (i.e., ninth data for the data read operation is transmitted from cache that is remote to the requesting core to the requesting core)).
LIM further teaches:
subsequent to receiving the first request and a second delay period, transmitting eighth data associated with the first operation to the first processor ([0047] When the first, second and third processors 100, 200 and 300 read data from the main memory 400 for operation…The third processor 300 may read data from the main memory 400 at a predetermined delay time after receiving a command for operation (S310). [0016] In some embodiments, different delay times may be applied to the second and third processors (i.e., command for operation represents a “first request” and data is read by the other processors subsequent to the request and different predetermined delay times, representing at least the “first delay period” and the “second delay period”)).
ROBINSON further teaches:
subsequent to receiving the first request, transmitting ninth data…wherein the ninth data is stored in a memory attached to the second memory buffer ([Column 6, Lines 55-59] FIG. 3 is a flowchart of an example process for performing a partial reconfiguration using prefetched data. The example process can be performed in response to the occurrence of an event that triggers the partial reconfiguration process. [Column 7, Lines 1-6] The device loads the initial portion of prefetched data from local buffer memory (320). This step typically occurs before a response from the external memory has been received. In other words, the device loads the prefetched data while waiting for the external memory to respond to the first memory request. [Column 7, Lines 11-14] The device receives and loads data at the first modified buffer offset (330). In other words, the device eventually receives a first response from the external memory and loads the received data for the partial reconfiguration (i.e., a single “second” request causes data to be transmitted from local memory, as “third data”, and from external memory, as “fourth data”))
Regarding claims 11, 15-17, and 20, they comprise limitations similar to claims 1, 7-8, 1, and 7 respectively, and are therefore rejected for similar rationale.
Claims 2-3, 12-13, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over MA, in view of LIM, in view of ROBINSON, as applied to claims 1, 11, and 17 above, and in further view of ABRAHAM et al. Pub. No.: US 2022/0004439 A1 (hereafter ABRAHAM)
Regarding claim 2, MA further teaches:
receiving a second request to execute a second operation using the distributed architecture ([0083] The method 300 starts in decision block 301, where, a core, which is to perform a data read operation (i.e., a request to execute a “second operation”), based upon a memory address of data to be read, determines whether the core is responsible for caching the data)…
subsequent to receiving the second request, transmitting third data associated with the second operation to the first processor, wherein the third data is stored in the first memory ([0068] If the core is responsible for caching the data, then the method 300 follows the YES branch and proceeds to step 302. [0076] if the method 300 proceeds to step 302, it is determined that the data to be read is cached by the requesting core' local cache. According to the theory of program locality and predictability mechanisms utilized by the hardware of a processor, the data to be read usually is a cache hit from the local cache of the requesting core (i.e., data for the data read operation is transmitted from cache that is local to the requesting core to the requesting core))…
transmitting fourth data associated with the second operation to the first processor, wherein the fourth data is stored in the second memory ([0068] If the core is responsible for caching the data, then the method 300 follows the YES branch and proceeds to step 302; otherwise, the method 300 follows the NO branch and proceeds to step 303. [0081] When the method 300 proceeds to step 303, it means that the data to be read is cached by a core other than the instant requesting core. In order to distinguish from the requesting core, a core responsible for caching such data is referenced herein as a remote core. Therefore, the requesting core does not search for the data in its local caches, instead, after step 301, it sends a data read request to the remote core having a labeling number matching the computed core labeling number, and receives from such remote core the returned data (i.e., data for the data read operation is transmitted from cache that is remote to the requesting core to the requesting core))..
ROBINSON further teaches:
subsequent to receiving the second request, transmitting fourth data…wherein the fourth data is stored in the second memory ([Column 6, Lines 55-59] FIG. 3 is a flowchart of an example process for performing a partial reconfiguration using prefetched data. The example process can be performed in response to the occurrence of an event that triggers the partial reconfiguration process. [Column 7, Lines 1-6] The device loads the initial portion of prefetched data from local buffer memory (320). This step typically occurs before a response from the external memory has been received. In other words, the device loads the prefetched data while waiting for the external memory to respond to the first memory request. [Column 7, Lines 11-14] The device receives and loads data at the first modified buffer offset (330). In other words, the device eventually receives a first response from the external memory and loads the received data for the partial reconfiguration (i.e., a single “second” request causes data to be transmitted from local memory, as “third data”, and from external memory, as “fourth data”))
While MA, LIM, and ROBINSON discuss executing operations in a UMA mode, MA, LIM, and ROBINSON do not explicitly teach:
receiving a second request to execute a second operation using the distributed architecture and in a non-uniform memory access (NUMA) mode
However, in analogous art, ABRAHAM teaches:
receiving a second request to execute a second operation using the distributed architecture and in a non-uniform memory access (NUMA) mode ([0097] In some platforms, multiple different clustering protocols may be utilized. For instance, in the example of FIG. 11, both a sub-NUMA clustering (SNC) and uniform memory access (UMA) cluster identifier protocols may be supported and corresponding cluster identifier generation logic (for each protocol) 1110, 1115 may be provided (i.e., incoming physical addresses 1105, representing first and second “requests” are processed according to both UMA and NUMA protocols)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined ABRAHAM’s teaching of processing requests in both UMA and NUMA modes, with the combination of MA, LIM, and ROBINSON’s teaching of processing requests in an UMA mode, to realize, with a reasonable expectation of success, a system that processes requests in an UMA mode, as in MA, LIM, and ROBINSON, as well as a NUMA mode, as in ABRAHAM. A person of ordinary skill would have been motivated to make this combination to take of the performance and scalability advantages of NUMA.
Regarding claim 3, MA further teaches:
at a second time that is distinct from a first time associated with the first request, receiving a third request to execute the first operation using the distributed architecture ([0083] The method 300 starts in decision block 301, where, a core, which is to perform a data read operation (i.e., each data read operation represents a distinct request that is received at different times), based upon a memory address of data to be read, determines whether the core is responsible for caching the data)…
subsequent to receiving the third request, transmitting fifth data associated with the second operation to the first processor, wherein the fifth data is stored in the first memory ([0068] If the core is responsible for caching the data, then the method 300 follows the YES branch and proceeds to step 302. [0076] if the method 300 proceeds to step 302, it is determined that the data to be read is cached by the requesting core' local cache. According to the theory of program locality and predictability mechanisms utilized by the hardware of a processor, the data to be read usually is a cache hit from the local cache of the requesting core (i.e., data for the data read operation is transmitted from cache that is local to the requesting core to the requesting core))…
transmitting sixth data associated with the first operation to the first processor, wherein the sixth data is stored in the second memory ([0068] If the core is responsible for caching the data, then the method 300 follows the YES branch and proceeds to step 302; otherwise, the method 300 follows the NO branch and proceeds to step 303. [0081] When the method 300 proceeds to step 303, it means that the data to be read is cached by a core other than the instant requesting core. In order to distinguish from the requesting core, a core responsible for caching such data is referenced herein as a remote core. Therefore, the requesting core does not search for the data in its local caches, instead, after step 301, it sends a data read request to the remote core having a labeling number matching the computed core labeling number, and receives from such remote core the returned data (i.e., data for the data read operation is transmitted from cache that is remote to the requesting core to the requesting core))..
ROBINSON further teaches:
subsequent to receiving the third request, transmitting sixth data…wherein the sixth data is stored in the second memory ([Column 6, Lines 55-59] FIG. 3 is a flowchart of an example process for performing a partial reconfiguration using prefetched data. The example process can be performed in response to the occurrence of an event that triggers the partial reconfiguration process. [Column 7, Lines 1-6] The device loads the initial portion of prefetched data from local buffer memory (320). This step typically occurs before a response from the external memory has been received. In other words, the device loads the prefetched data while waiting for the external memory to respond to the first memory request. [Column 7, Lines 11-14] The device receives and loads data at the first modified buffer offset (330). In other words, the device eventually receives a first response from the external memory and loads the received data for the partial reconfiguration (i.e., a single “second” request causes data to be transmitted from local memory, as “third data”, and from external memory, as “fourth data”))
While MA, LIM, and ROBINSON discuss executing operations in a UMA mode, MA, LIM, and ROBINSON do not explicitly teach:
receiving a third request to execute the first operation using the distributed architecture and in a non-uniform memory access (NUMA) mode
However, in analogous art, ABRAHAM teaches:
receiving a second request to execute a second operation using the distributed architecture and in a non-uniform memory access (NUMA) mode ([0097] In some platforms, multiple different clustering protocols may be utilized. For instance, in the example of FIG. 11, both a sub-NUMA clustering (SNC) and uniform memory access (UMA) cluster identifier protocols may be supported and corresponding cluster identifier generation logic (for each protocol) 1110, 1115 may be provided (i.e., incoming physical addresses 1105, representing first and second “requests” are processed according to both UMA and NUMA protocols)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined ABRAHAM’s teaching of processing requests in both UMA and NUMA modes, with the combination of MA, LIM, and ROBINSON’s teaching of processing requests in an UMA mode, to realize, with a reasonable expectation of success, a system that processes requests in an UMA mode, as in MA, LIM, and ROBINSON, as well as a NUMA mode, as in ABRAHAM. A person of ordinary skill would have been motivated to make this combination to take of the performance and scalability advantages of NUMA.
Regarding claims 12-13, and 18-19, they comprise limitations similar to claims 2-3, and are therefore rejected for similar rationale.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over MA, in view of LIM, in view of ROBINSON, as applied to claims 1, and 11 above, and in further view of KIM et al. Pub. No.: US 2009/0157986 A1 (hereafter KIM).
Regarding claim 4, while MA, LIM, and ROBINSON discuss memory accesses, they do not explicitly teach:
the first delay period is determined based on:
(i) a first latency associated with transmission of data stored in the first memory to the first processor, and
(ii) a second latency associated with transmission of data stored in the second memory to the first processor.
However, in analogous art that similarly discusses memory access, KIM teaches:
the first delay period is determined based on:
(i) a first latency associated with transmission of data stored in the first memory to the first processor, and (ii) a second latency associated with transmission of data stored in the second memory to the first processor ([0005] Some memory controllers has a buffer (e.g., FIFO memory) that temporarily stores data to make data writing in a flash memory and data reading therefrom smoother. To perform a data output (read) operation synchronized with the operational clock (external clock) of a host system, the memory controller may need to compensate for memory access latency…Read data may not be instantaneously available (output) from some memory devices at the same time that the read-enable signal is activated. The access time T.sub.REA of a memory depends upon the characteristics of the individual memory device. Some memory devices may have different memory access latencies T.sub.REA, such that read data may be output (available) later from some memory devices than from others. Thus, there is a need for a memory controller capable of variably delaying the propagation of a read-enable signal and read data in the memory controller. [0008] A memory controller comprises: an digitally programmable delay unit receiving a read-enable signal and outputting a delayed read-enable signal having a variable delay time that varies in response to an externally applied delay-control signal (e.g., a digital delay selection signal) (i.e., delay unit synchronizes memory accesses by introducing delay time, or “period” into memory accesses based on access/transmission latencies of individual memory devices including at least a first and second memory having different access latencies)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined KIM’s teaching of synchronizing memory accesses based on delay determined from memory access latencies of multiple memory devices, with the combination of MA, LIM, and ROBINSON’s teaching of accessing multiple different memories, to realize, with a reasonable expectation of success, a system that accesses multiple different memories, as in MA, LIM, and ROBINSON, by introducing delay based on memory access latency of the memories, as in KIM. A person having ordinary skill would have been motivated to make this combination to make data reading smoother (Kim [0005]).
Regarding claim 14, it comprises limitations similar to those of claim 4, and is rejected for similar rationale.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over MA, in view of LIM, in view of ROBINSON, as applied to claim 1 above, and in further view of LEE et al. Pub. No.: US 2022/0179789 A1 (hereafter LEE).
Regarding claim 9, while MA, LIM, and ROBINSON discuss managing access to memory, they do not explicitly teach:
a first application comprises the first operation and one or more second operations; and each operation of the first application is executed using the UMA mode.
However, in analogous art that similarly manages access to memory, LEE teaches:
a first application comprises the first operation and one or more second operations; and each operation of the first application is executed using the UMA mode ([0038] Applications running on the local server have access to a local memory address space corresponding to the memories associated with the local server and a local UMA address space corresponding the UMA storage space provided by the UMA cluster. The UMA node control monitors memory access requests from the local server via the control signal paths 671 and determines, for each memory access request, whether it is directed at the local memory space provided by, for example, the main memory, or the local UMA address space corresponding to memory units in the cluster of UMA nodes…upon determination that the local server has requested access (a-1) to the local UMA address space, the cluster-wide UMA address management logic 730 is configured to translate (a-2) between the local UMA address space and a global UMA address space. The global UMA address space is then mapped (a-3) to a physical UMA address space. In certain embodiments, the physical UMA address space includes separate physical address spaces associated with respective UMA nodes (e.g., Node 1, Node 2, . . . , Node n) in the cluster of UMA nodes. Thus, the UMA node control device provides access of the physical address spaces associated with the other UMA nodes for the applications running on the local server (i.e., memory access requests to UMA address space, representing plural “operations” of an application are performed according to a UMA “mode”))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LEE’s teaching of performing plural memory access operations of an application in a UMA mode, with MA, LIM, and ROBINSON’s teaching of performing memory accesses in an UMA mode, to realize, with a reasonable expectation of success, a system that performs memory accesses in a UMA mode, as in MA, LIM, and ROBINSON, where the memory accesses are part of an application, as in LEE. A person having ordinary skill would have been motivated to utilize UMA mode, which preserves memory bandwidth and improve performance (LEE [0004]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over MA, in view of LIM, in view of ROBINSON, as applied to claim 1 above, and in further view of HOU et al.: Pub. No.: US 2021/0208819 A1 (hereafter HOU).
Regarding claim 1, while MA, LIM, and ROBINSON discuss performing memory accesses, they do not explicitly teach:
a first application comprises the first operation and a second operation; and the second operation is executed using a non-uniform memory access (NUMA) mode.
However, in analogous art that similarly teaches performing memory accesses, HOU teaches:
a first application comprises the first operation and a second operation; and the second operation is executed using a non-uniform memory access (NUMA) mode ([0038] With further reference to FIG. 3, illustrating a schematic diagram of an application scenario of the method for scheduling a memory access request according to an embodiment of the present disclosure. In the application scenario of FIG. 3, a server includes a plurality of service modules, which are service modules 301, 302, and 303, and at the same time includes a plurality of NUMA nodes, which are NUMA nodes 311, 312, and 313, respectively…the service module 301 is bound with the NUMA node 312, and memory access requests of the service module 301 are all sent to the NUMA node 312 (i.e., an application comprises plural memory access requests which are send to a NUMA node to be executed)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined HOU’s teaching of performing plural memory access operations of an application in a NUMA mode, with MA, LIM, and ROBINSON’s teaching of performing memory accesses, to realize, with a reasonable expectation of success, a system that performs memory accesses, as in MA, LIM, and ROBINSON, where the memory accesses are part of an application and are executed in a NUMA mode, as in HOU. A person having ordinary skill would have been motivated to utilize NUMA mode, which allows for small access delay and high performance (HOU [0003]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195