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 .
Status of Claims
Claims 1-20 are pending. Claims 1, 10, 11, 13, 15-17, 19, and 20 have been amended as per Applicants' request.
Papers Submitted
It is hereby acknowledged that the following papers have been received and placed of record in the file:
Amended Claims as filed on July 29, 2026
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on August 14, 2026 has been entered.
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 1, 5, 6, 9-11, 13, 15-17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over KOJIMA (US 2009/0271796) (hereinafter Kojima) (October 29, 2009) in view of VISWANATHAN (US 2008/0294823) (hereinafter Vis) (published November 27, 2008) and Nguyen et al. (US 2022/0244966) (hereinafter Nguyen) (published August 04, 2022).
Regarding Claim 1, Kojima discloses a computing system, comprising: a first memory controller configured to connect to a shared upstream resource via a first channel and to connect to a first memory via a first memory channel;
“The master processor 11 and the slave processor 21 are capable of accessing a shared memory 30. The shared memory 30 is used as a data storage area for tasks to be executed in the master processor 11 and the slave processor 21” (Kojima [0027] see fig. 1)
“A dedicated memory 12 is used as a storage area for an OS 120 and an application program (AP) 121 to be read and executed by the master processor 11 and as a storage area for data to be used by those programs” (Kojima [0029] see fig. 1)
a second memory controller configured to connect to the shared upstream resource via a second channel and to connect to a second memory via a second memory channel,
“The master processor 11 and the slave processor 21 are capable of accessing a shared memory 30. The shared memory 30 is used as a data storage area for tasks to be executed in the master processor 11 and the slave processor 21” (Kojima [0027] see fig. 1)
“On the other hand, a dedicated memory 22 is used as a storage area for an OS 220 and an AP 221 to be read and executed by the slave processor 21 and as a storage area for data to be used by those programs” (Kojima [0031] see fig. 1)
wherein the second memory controller is configured to identify that the second memory controller is not performing a process for the second memory
“Then, when a processing request is made from the task D, which is one of the request source tasks, at T3 during the running of the child task c, the communication processing task is activated and creates a child task d. The execution priority of the child task d in the slave processor 21 is set lower than the execution priority of the child task c, which is currently running. This is because the relative relationship of the execution priorities of the request source tasks C and D in the master processor 11 is reflected on the execution priorities of the child tasks c and d. Thus, the child task d does not start running until the other tasks with the higher execution priority than the child task d end or those tasks release the rights to use the slave processor 21 for some reason” (Kojima [0054] see fig. 7, task d is identified as lower priority and is stalled/not performed until T6)
But does not explicitly state identify by interpreting memory controller information, wherein the process for the second memory is causing congestion at the shared upstream resource; and a first sideband bus configured to connect the first memory controller with the second memory controller and transmit sideband connected memory controller signals between the first memory controller and the second memory controller.
Kojima and Vis discloses identify by interpreting memory controller information, wherein the process for the second memory is causing congestion at the shared upstream resource; and
“Then, when a processing request is made from the task D, which is one of the request source tasks, at T3 during the running of the child task c, the communication processing task is activated and creates a child task d. The execution priority of the child task d in the slave processor 21 is set lower than the execution priority of the child task c, which is currently running. This is because the relative relationship of the execution priorities of the request source tasks C and D in the master processor 11 is reflected on the execution priorities of the child tasks c and d. Thus, the child task d does not start running until the other tasks with the higher execution priority than the child task d end or those tasks release the rights to use the slave processor 21 for some reason” (Kojima [0054] see fig. 7, task d is identified as lower priority and is stalled/not performed until T6)
“Further, the request source task may detect the completion of processing of the slave processor 21 by performing polling which periodically checks the communication management flag that is written to the shared memory 30 upon completion of processing of the slave processor 21” (Kojima [0043] due to task d not being executed “congestion” is caused at time T2 to T6 to the process polling for the completion of task d in the shared memory)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047])
“In queue 412, status 502 is added to request 406, status 504 is added to request 408, and status 506 is added to request 410. As each request is added to queue 412, the status field of each request is initially set to "queued". In this example, when request 406 is added to queue 412, status 502 is set to "queued". Similarly, when request 408 is added to queue 412, status 504 is set to "queued", and when request 410 is added to queue 412, status 506 is set to "queued"” (Vis [0048] the request corresponding to task d of Kojima would be queue and not executing due to its lower priority)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to modify Kojima’s shared-memory processing system in view of Vis to identify, based on memory controller information, when processing associated with the second memory is not being performed and is contributing to congestion at the shared upstream resource. Kojima already monitors the processing state of tasks associated with the slave processor and permits a requesting task to poll the shared memory for completion of the requested processing. Kojima further teaches that a lower-priority child task may remain unexecuted while a higher-priority task is running, such that the processing request corresponding to task D remains pending during the interval shown in Figure 7. Vis provides a complementary technique for explicitly representing and interpreting the processing state of queued requests, including distinguishing requests that are “queued,” “executing,” and “suspended.” Thus, applying Vis’s status-based request identification to Kojima would have provided a predictable way for the system to determine, from available processing/request information, whether the processing associated with the second memory was queued or otherwise not executing and thereby determine that the pending processing was contributing to contention or congestion associated with the shared resource. The motivation for doing so would have been to improve the ability of Kojima’s system to monitor, manage, and diagnose pending processing requests competing for shared resources. Vis expressly provides status information that allows the system to distinguish requests that are waiting to execute from requests that are actively being processed, which would allow Kojima’s system to more readily identify a stalled or pending request rather than merely detecting its eventual completion through polling.
Kojima further disclose communications between the master processor and the slave processor (see fig. 1 of Kojima) and Nguyen discloses a first sideband bus configured to connect the first memory controller with the second memory controller and transmit sideband connected memory controller signals between the first memory controller and the second memory controller.
“To parallelize the boot operation of the second, slave CPU 106(1), the execution of the boot program code 118(0) by the first, master CPU 106(0) also involves setting up a side band communication channel 126 on a side band communication link 128 between the master CPU socket 102(0) and the slave CPU socket 102(1). The first, master CPU 106(0) is configured to communicate a slave boot-up synchronization signal 130 indicating the boot-up state on the sideband communication channel 126 based on the CPUs 106(0) execution of the boot program code 118(0)” (Nguyen [0021])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to modify the communication between the master processor and slave processor of the system in the combination of Kojima and Vis, to use the sideband communication channel disclosed by Nguyen. By applying Nguyen's sideband communication technique to Kojima and Vis would provide a predictable communication path for transmitting the processing-status and synchronization signals between the processors. The motivation for doing so would have been to provide a dedicated communication path for the control, status, and synchronization information exchanged between the processors without relying exclusively on the primary communication path used for processing-related data. Nguyen expressly uses its sideband channel to communicate boot-up synchronization information between the master and slave CPUs, demonstrating that sideband communication is suitable for transmitting processor state and coordination signals. Using such a dedicated channel in Kojima and Vis would reduce the likelihood that these relatively small but time-sensitive control and status signals would be delayed by other traffic on the primary communication path, thereby improving coordination between the master and slave processors and facilitating timely identification and management of pending processing.
Regarding Claim 5, the combination of Kojima and Nguyen further discloses wherein: the first channel is a first subchannel of a third channel and the second channel is a second subchannel of the third channel; and the first memory channel is a first memory subchannel of a third memory channel and the second memory channel is a second memory subchannel of the third memory channel.
The combination of Kojima and Nguyen teach a first channel, a second channel, a first memory channel, and a second memory channel (see rejection above, Fig.1 of Kojima, and Fig. 1 of Nguyen). While Kojima and Nguyen does not explicitly recite that these channels are "subchannels of a third channel" or "subchannels of a third memory channel" this limitation is a mere subdivision or duplication of structural units with no change in function. Under MPEP 2144.04(VI), the "mere duplication of parts has no patentable significance unless a new and unexpected result is produced". Here, the "third channel" or “third memory channel” acts as a mere container or logical grouping for the existing first and second channels or first and second memory channels, and the applicant has not shown that this hierarchical naming produces any result beyond the separate, sequential operation of the channels already known in the art. Furthermore, the configuration of the first and second channels as subchannels of a larger channel or the configuration of the first and second memory channels as subchannels of a larger memory channel is a matter of design choice regarding the logical layout of the computing system. As noted in MPEP 2144.04(VI), the particular placement or grouping of components is generally obvious where the components perform the same function regardless of their label. A person of ordinary skill in the art, seeking to organize data paths in a multi-channel memory system, would have found it obvious to treat individual channels as sub-units of a common bus, “third channel”, or "third memory channel" to simplify addressing or routing logic. The modification is a routine application of well-known architectural principles and provides no unexpected technical advantage.
Regarding Claim 6, the combination of Kojima and Nguyen further discloses wherein the first channel is a first subchannel of a third channel and the second channel is a second subchannel of a fourth channel; and the first memory channel is a first memory subchannel of a third memory channel and the second memory channel is a second memory subchannel of a fourth memory channel.
While the combination of Kojima and Nguyen does not explicitly label the first channel as a subchannel of a "third channel", the second channel as a subchannel of a "fourth channel", the first memory channel as a subchannel of a "third memory channel", and the second memory channel as a subchannel of a "fourth memory channel", this limitation is a mere subdivision or redundant duplication of structural units. Under MPEP 2144.04(VI), the "mere duplication of parts has no patentable significance unless a new and unexpected result is produced." In this instance, the "third" and "fourth" channels and the "third" and "fourth" memory channels function as mere logical containers or higher-level abstractions for the existing channels already taught by Kojima and Nguyen. The applicant has not demonstrated that nesting these channels within additional named hierarchies produces any functional shift beyond the data transfer operations already known in the art. Furthermore, the arrangement of the first and second channels as sub-units of separate "third" and "fourth" channels is a routine design choice regarding the hierarchical naming and logical layout of the computing system. As noted in MPEP 2144.04(VI), the particular grouping or labeling of components is generally obvious where the components perform the same function regardless of their hierarchical designation. A person of ordinary skill in the art, seeking to scale or categorize data paths in a multi-channel architecture, would have found it obvious to classify individual channels as "subchannels" of respective parent controllers or buses to facilitate organized system mapping. This modification is a routine application of well-known architectural principles and provides no unexpected technical advantage over the separate channels taught in the prior art.
Regarding Claim 9, Kojima and Vis further discloses wherein the first memory controller comprises a processor system configured to: poll the second memory controller for memory controller information;
“Further, the request source task may detect the completion of processing of the slave processor 21 by performing polling which periodically checks the communication management flag that is written to the shared memory 30 upon completion of processing of the slave processor 21” (Kojima [0043] checks for controller information on the status of the process)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047] status of the process/requests being checked on)
identify whether the second memory controller is not performing the process for the second memory, causing the congestion at the shared upstream resource from the memory controller information; and
“Then, when a processing request is made from the task D, which is one of the request source tasks, at T3 during the running of the child task c, the communication processing task is activated and creates a child task d. The execution priority of the child task d in the slave processor 21 is set lower than the execution priority of the child task c, which is currently running. This is because the relative relationship of the execution priorities of the request source tasks C and D in the master processor 11 is reflected on the execution priorities of the child tasks c and d. Thus, the child task d does not start running until the other tasks with the higher execution priority than the child task d end or those tasks release the rights to use the slave processor 21 for some reason” (Kojima [0054] see fig. 7, task d is identified as lower priority and is stalled/not performed until T6)
“In queue 412, status 502 is added to request 406, status 504 is added to request 408, and status 506 is added to request 410. As each request is added to queue 412, the status field of each request is initially set to "queued". In this example, when request 406 is added to queue 412, status 502 is set to "queued". Similarly, when request 408 is added to queue 412, status 504 is set to "queued", and when request 410 is added to queue 412, status 506 is set to "queued"” (Vis [0048] the request corresponding to task d of Kojima would be queue and not executing due to its lower priority)
provide a scheduler executed by the processor system with an indication to schedule a process for the first memory that uses the shared upstream resource in response to identifying that the second memory controller is not performing the process for the second memory causing the congestion at the shared upstream resource.
“Then, when a processing request is made from the task D, which is one of the request source tasks, at T3 during the running of the child task c, the communication processing task is activated and creates a child task d. The execution priority of the child task d in the slave processor 21 is set lower than the execution priority of the child task c, which is currently running. This is because the relative relationship of the execution priorities of the request source tasks C and D in the master processor 11 is reflected on the execution priorities of the child tasks c and d. Thus, the child task d does not start running until the other tasks with the higher execution priority than the child task d end or those tasks release the rights to use the slave processor 21 for some reason” (Kojima [0054])
“When a processing request is made from the task A, which is one of the request source tasks, at T4, the communication processing task is activated and creates a child task a. The execution priority of the child task a in the slave processor 21 is set higher than the execution priority of the child task c, which is currently running. Thus, the child task a is dispatched in place of the child task c by the task scheduling after the end of the communication processing task (OP-A)” (Kojima [0055] task a is scheduled even after the queuing of task d when it is not being executed)
Regarding Claim 10, Kojima further discloses wherein the processor system is further configured to: identify whether the second memory controller is not scheduled to perform the process for the second memory causing the congestion at the shared upstream resource from the memory controller information in response to identifying that the second memory controller is not performing the process for the second memory causing the congestion at the shared upstream resource; and
“If it is determined that a processing request to the slave processor 21 is acceptable (YES in Step S11), a memory area for interprocessor communication is reserved in Step S12. Specifically, a communication management flag is set in the memory space reserved in advance for interprocessor communication. The communication management flag is flag information indicating whether the area for storing communication data exchanged by interprocessor communication is in use or not” (Kojima [0035] the flag would indicated if there is a process being performed or scheduled to be performed using the shared memory)
“Next, when a processing request is made from the task C, which is one of the request source tasks, at time T2, the communication processing task creates a child task c in the slave processor 21. The child task c starts running immediately after the end of the communication processing task because there is no other child task (OP-C1)” (Kojima [0053] at right before T2 there is no scheduled process to be performed)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047] if the process/request is not in the queue it is not scheduled to be performed and the status field of queued indicates that the process is scheduled and not currently being performed)
provide the scheduler executed by the processor system with the indication to schedule the process for the first memory that uses the shared upstream resource in response to identifying that the second memory controller is not performing the process for the second memory causing the congestion at the shared upstream resource and identifying that the second memory controller is not scheduled to perform the process for the second memory causing the congestion at the shared upstream resource.
“Specifically, the interrupt handler may notify the occurrence of a processing request to the communication processing task in "wait status", change the communication processing task to "ready status", and request task scheduling to the OS. It is preferred to give the highest execution priority in the slave processor 21 to the communication processing task in order that the communication processing task is executed preferentially” (Kojima [0044])
“Next, when a processing request is made from the task C, which is one of the request source tasks, at time T2, the communication processing task creates a child task c in the slave processor 21. The child task c starts running immediately after the end of the communication processing task because there is no other child task (OP-C1)” (Kojima [0053] when there is no tasks scheduled or in progress at T2, task C is scheduled and executed)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047] if the process/request is added to the queue when it is scheduled and the status field of queued indicates that the process is scheduled and not currently being performed)
Regarding Claim 11, Kojima and Vis further discloses wherein in response to identifying that the second memory controller is not performing the process for the second memory causing the congestion at the shared upstream resource the processor system is further configured to: identify whether the second memory controller is scheduled to perform the process for the second memory causing the congestion at the shared upstream resource from the memory controller information; identify whether the first memory controller has priority to perform the process for the first memory using the shared upstream resource over the second memory controller; and provide the scheduler executed by the processor system with the indication to schedule the process for the first memory that uses the shared upstream resource in response to identifying that the second memory controller is scheduled to perform the process for the second memory causing the congestion at the shared upstream resource, and identifying that the first memory controller has priority to perform the process for the first memory using the shared upstream resource over the second memory controller.
“When a processing request is made from the task A, which is one of the request source tasks, at T4, the communication processing task is activated and creates a child task a. The execution priority of the child task a in the slave processor 21 is set higher than the execution priority of the child task c, which is currently running. Thus, the child task a is dispatched in place of the child task c by the task scheduling after the end of the communication processing task (OP-A)” (Kojima [0055] child tasks c and d are created from the master processor, child task A also from the master processor has priority and is scheduled to be performed first)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047] when the process/request is in the queue it is scheduled to be performed and the status field of queued indicates that the process is scheduled and not currently being performed)
Regarding Claim 13, Kojima and Vis further discloses wherein the first memory controller comprises a processor system configured to: poll the second memory controller for memory controller information;
“Further, the request source task may detect the completion of processing of the slave processor 21 by performing polling which periodically checks the communication management flag that is written to the shared memory 30 upon completion of processing of the slave processor 21” (Kojima [0043] checks for controller information on the status of the process)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047] status of the process/requests being checked on)
identify whether the second memory controller is performing the process for the second memory causing the congestion at the shared upstream resource from the memory controller information; and
“When a processing request is made from the task A, which is one of the request source tasks, at T4, the communication processing task is activated and creates a child task a. The execution priority of the child task a in the slave processor 21 is set higher than the execution priority of the child task c, which is currently running. Thus, the child task a is dispatched in place of the child task c by the task scheduling after the end of the communication processing task (OP-A)” (Kojima [0055] see fig. 7, task c is identified as lower priority and is stalled/not being performed at T4, also task b is not being performing at T2 since it has been completed)
provide a scheduler executed by the processor system with an indication to postpone the process for the first memory using the shared upstream resource in response to identifying that the second memory controller is performing the process for the second memory causing the congestion at the shared upstream resource.
“In Step S16, the request source task waits until processing of the slave processor 21 is completed. The request source task suspends execution and changes to "wait status", and then sequentially changes to "ready status" and to "run status" in response to reception of an interrupt signal from the slave processor 21, which is described later, and finally confirms communication data indicating a processing completion result. The processing to change the operating status of the request source task to "ready status" in response to the occurrence of an interrupt from the slave processor 21 can be easily implemented by an interrupt handler that is activated upon occurrence of an interrupt” (Kojima [0043])
“Specifically, the interrupt handler may notify the occurrence of a processing request to the communication processing task in "wait status", change the communication processing task to "ready status", and request task scheduling to the OS. It is preferred to give the highest execution priority in the slave processor 21 to the communication processing task in order that the communication processing task is executed preferentially” (Kojima [0044])
“This is because the relative relationship of the execution priorities of the request source tasks C and D in the master processor 11 is reflected on the execution priorities of the child tasks c and d. Thus, the child task d does not start running until the other tasks with the higher execution priority than the child task d end or those tasks release the rights to use the slave processor 21 for some reason” (Kojima [0054] task D is postponed due to a running child task C that has a higher priority)
“When a processing request is made from the task A, which is one of the request source tasks, at T4, the communication processing task is activated and creates a child task a. The execution priority of the child task a in the slave processor 21 is set higher than the execution priority of the child task c, which is currently running. Thus, the child task a is dispatched in place of the child task c by the task scheduling after the end of the communication processing task (OP-A)” (Kojima [0055] task c is postponed due to task a)
Regarding Claim 15, Kojima discloses a method of memory controller scheduling implemented by at least one processor system of a first memory controller of a first memory, comprising: polling a second memory controller for memory controller information;
“Further, the request source task may detect the completion of processing of the slave processor 21 by performing polling which periodically checks the communication management flag that is written to the shared memory 30 upon completion of processing of the slave processor 21” (Kojima [0043] checks for controller information on the status of the process)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047] status of the process/requests being checked on)
identifying whether the second memory controller is not performing a process for a second memory,
“Then, when a processing request is made from the task D, which is one of the request source tasks, at T3 during the running of the child task c, the communication processing task is activated and creates a child task d. The execution priority of the child task d in the slave processor 21 is set lower than the execution priority of the child task c, which is currently running. This is because the relative relationship of the execution priorities of the request source tasks C and D in the master processor 11 is reflected on the execution priorities of the child tasks c and d. Thus, the child task d does not start running until the other tasks with the higher execution priority than the child task d end or those tasks release the rights to use the slave processor 21 for some reason” (Kojima [0055] see fig. 7, task d is identified as lower priority and is stalled/not performed until T6)
providing a scheduler executed by the at least one processor system with an indication to schedule the process for the first memory that uses the shared upstream resource in response to identifying that the second memory controller is not performing the process for the second memory causing the congestion at the shared upstream resource.
“In Step S16, the request source task waits until processing of the slave processor 21 is completed. The request source task suspends execution and changes to "wait status", and then sequentially changes to "ready status" and to "run status" in response to reception of an interrupt signal from the slave processor 21, which is described later, and finally confirms communication data indicating a processing completion result. The processing to change the operating status of the request source task to "ready status" in response to the occurrence of an interrupt from the slave processor 21 can be easily implemented by an interrupt handler that is activated upon occurrence of an interrupt” (Kojima [0043])
“Specifically, the interrupt handler may notify the occurrence of a processing request to the communication processing task in "wait status", change the communication processing task to "ready status", and request task scheduling to the OS. It is preferred to give the highest execution priority in the slave processor 21 to the communication processing task in order that the communication processing task is executed preferentially” (Kojima [0044])
“When a processing request is made from the task A, which is one of the request source tasks, at T4, the communication processing task is activated and creates a child task a. The execution priority of the child task a in the slave processor 21 is set higher than the execution priority of the child task c, which is currently running. Thus, the child task a is dispatched in place of the child task c by the task scheduling after the end of the communication processing task (OP-A)” (Kojima [0055] the tasks are indicated to be scheduled by the scheduler based on the priority)
But does not explicitly state identifying, by interpreting the memory controller information, wherein the process for the second memory is causing congestion at the shared upstream resource; and via a sideband bus connecting the first memory controller and the second memory controller.
Kojima and Vis discloses identifying, by interpreting the memory controller information, wherein the process for the second memory is causing congestion at the shared upstream resource; and
“Then, when a processing request is made from the task D, which is one of the request source tasks, at T3 during the running of the child task c, the communication processing task is activated and creates a child task d. The execution priority of the child task d in the slave processor 21 is set lower than the execution priority of the child task c, which is currently running. This is because the relative relationship of the execution priorities of the request source tasks C and D in the master processor 11 is reflected on the execution priorities of the child tasks c and d. Thus, the child task d does not start running until the other tasks with the higher execution priority than the child task d end or those tasks release the rights to use the slave processor 21 for some reason” (Kojima [0055] see fig. 7, task d is identified as lower priority and is stalled/non-performing until T6)
“Further, the request source task may detect the completion of processing of the slave processor 21 by performing polling which periodically checks the communication management flag that is written to the shared memory 30 upon completion of processing of the slave processor 21” (Kojima [0043] due to task d not being executed “congestion” is caused at time T2 to T6 to the process polling for the completion of task d in the shared memory)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047])
“In queue 412, status 502 is added to request 406, status 504 is added to request 408, and status 506 is added to request 410. As each request is added to queue 412, the status field of each request is initially set to "queued". In this example, when request 406 is added to queue 412, status 502 is set to "queued". Similarly, when request 408 is added to queue 412, status 504 is set to "queued", and when request 410 is added to queue 412, status 506 is set to "queued"” (Vis [0048] the request corresponding to task d of Kojima would be queue and not executing due to its lower priority)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to modify Kojima’s shared-memory processing system in view of Vis to identify, based on memory controller information, when processing associated with the second memory is not being performed and is contributing to congestion at the shared upstream resource. Kojima already monitors the processing state of tasks associated with the slave processor and permits a requesting task to poll the shared memory for completion of the requested processing. Kojima further teaches that a lower-priority child task may remain unexecuted while a higher-priority task is running, such that the processing request corresponding to task D remains pending during the interval shown in Figure 7. Vis provides a complementary technique for explicitly representing and interpreting the processing state of queued requests, including distinguishing requests that are “queued,” “executing,” and “suspended.” Thus, applying Vis’s status-based request identification to Kojima would have provided a predictable way for the system to determine, from available processing/request information, whether the processing associated with the second memory was queued or otherwise not executing and thereby determine that the pending processing was contributing to contention or congestion associated with the shared resource. The motivation for doing so would have been to improve the ability of Kojima’s system to monitor, manage, and diagnose pending processing requests competing for shared resources. Vis expressly provides status information that allows the system to distinguish requests that are waiting to execute from requests that are actively being processed, which would allow Kojima’s system to more readily identify a stalled or pending request rather than merely detecting its eventual completion through polling.
Nguyen discloses via a sideband bus connecting the first memory controller and the second memory controller.
“To parallelize the boot operation of the second, slave CPU 106(1), the execution of the boot program code 118(0) by the first, master CPU 106(0) also involves setting up a side band communication channel 126 on a side band communication link 128 between the master CPU socket 102(0) and the slave CPU socket 102(1). The first, master CPU 106(0) is configured to communicate a slave boot-up synchronization signal 130 indicating the boot-up state on the sideband communication channel 126 based on the CPUs 106(0) execution of the boot program code 118(0)” (Nguyen [0021])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to modify the communication between the master processor and slave processor of the system in the combination of Kojima and Vis, to use the sideband communication channel disclosed by Nguyen. By applying Nguyen's sideband communication technique to Kojima and Vis would provide a predictable communication path for transmitting the processing-status and synchronization signals between the processors. The motivation for doing so would have been to provide a dedicated communication path for the control, status, and synchronization information exchanged between the processors without relying exclusively on the primary communication path used for processing-related data. Nguyen expressly uses its sideband channel to communicate boot-up synchronization information between the master and slave CPUs, demonstrating that sideband communication is suitable for transmitting processor state and coordination signals. Using such a dedicated channel in Kojima and Vis would reduce the likelihood that these relatively small but time-sensitive control and status signals would be delayed by other traffic on the primary communication path, thereby improving coordination between the master and slave processors and facilitating timely identification and management of pending processing.
Regarding Claim 16, Kojima and Vis further discloses further comprising, in response to identifying that the second memory controller is not performing the process for the second memory causing the congestion at the shared upstream resource: identifying whether the second memory controller is not scheduled to perform the process for the second memory causing the congestion at the shared upstream resource from the memory controller information,
“If it is determined that a processing request to the slave processor 21 is acceptable (YES in Step S11), a memory area for interprocessor communication is reserved in Step S12. Specifically, a communication management flag is set in the memory space reserved in advance for interprocessor communication. The communication management flag is flag information indicating whether the area for storing communication data exchanged by interprocessor communication is in use or not” (Kojima [0035] the flag would indicated if there is a process being performed or scheduled to be performed using the shared memory)
“Next, when a processing request is made from the task C, which is one of the request source tasks, at time T2, the communication processing task creates a child task c in the slave processor 21. The child task c starts running immediately after the end of the communication processing task because there is no other child task (OP-C1)” (Kojima [0053] at right before T2 there is no scheduled process to be performed)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047] if the process/request is not in the queue it is not scheduled to be performed and the status field of queued indicates that the process is scheduled and not currently being performed)
wherein providing the scheduler executed by the at least one processor system with the indication to schedule the process for the first memory that uses the shared upstream resource in response to identifying that the second memory controller is not performing the process for the second memory causing the congestion at the shared upstream resource comprises providing the scheduler executed by the at least one processor system with the indication to schedule the process for the first memory that uses the shared upstream resource in response to identifying that the second memory controller is not scheduled to perform the process for the second memory causing the congestion at the shared upstream resource.
“Specifically, the interrupt handler may notify the occurrence of a processing request to the communication processing task in "wait status", change the communication processing task to "ready status", and request task scheduling to the OS. It is preferred to give the highest execution priority in the slave processor 21 to the communication processing task in order that the communication processing task is executed preferentially” (Kojima [0044])
“Next, when a processing request is made from the task C, which is one of the request source tasks, at time T2, the communication processing task creates a child task c in the slave processor 21. The child task c starts running immediately after the end of the communication processing task because there is no other child task (OP-C1)” (Kojima [0053] when there is no tasks scheduled or in progress at T2, task C is scheduled and executed)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047] if the process/request is added to the queue when it is scheduled and the status field of queued indicates that the process is scheduled and not currently being performed)
Regarding Claim 17, Kojima and Vis further discloses further comprising, in response to identifying that the second memory controller is not performing the process for the second memory causing the congestion at the shared upstream resource: identifying whether the second memory controller is scheduled to perform the process for the second memory causing the congestion at the shared upstream resource from the memory controller information; and identifying whether the first memory controller has priority to perform a process for the first memory using the shared upstream resource over the second memory controller, wherein providing the scheduler executed by the at least one processor system with the indication to schedule the process for the first memory that uses the shared upstream resource in response to identifying that the second memory controller is not performing the process for the second memory causing the congestion at the shared upstream resource comprises providing the scheduler executed by the at least one processor system with the indication to schedule the process for the first memory that uses the shared upstream resource in response to identifying that the second memory controller is scheduled to perform the process for the second memory causing the congestion at the shared upstream resource and identifying that the first memory controller has priority to perform the process for the first memory using the shared upstream resource over the second memory controller.
“When a processing request is made from the task A, which is one of the request source tasks, at T4, the communication processing task is activated and creates a child task a. The execution priority of the child task a in the slave processor 21 is set higher than the execution priority of the child task c, which is currently running. Thus, the child task a is dispatched in place of the child task c by the task scheduling after the end of the communication processing task (OP-A)” (Kojima [0055] child tasks c and d are created from the master processor, child task A also from the master processor has priority and is scheduled to be performed first)
“A status field is added to each request in the queue. The status field identifies the status of each asynchronous input/output request in queue 412. The status field contains one of three possible values, "queued", "executing", and "suspended". When the status field of an input/output request has the value "queued", the status field identifies the input/output request as queued in asynchronous input/output queue 412. When the status field of an input/output request has the value "executing", the status field identifies the input/output request as being performed by a thread servicing the input/output queue” (Vis [0047] when the process/request is in the queue it is scheduled to be performed and the status field of queued indicates that the process is scheduled and not currently being performed)
Regarding Claim 19, Kojima further discloses further comprising providing the scheduler executed by the at least one processor system with an indication to postpone the process for the first memory using the shared upstream resource in response to identifying that the second memory controller is performing the process for the second memory causing the congestion at the shared upstream resource.
“In Step S16, the request source task waits until processing of the slave processor 21 is completed. The request source task suspends execution and changes to "wait status", and then sequentially changes to "ready status" and to "run status" in response to reception of an interrupt signal from the slave processor 21, which is described later, and finally confirms communication data indicating a processing completion result. The processing to change the operating status of the request source task to "ready status" in response to the occurrence of an interrupt from the slave processor 21 can be easily implemented by an interrupt handler that is activated upon occurrence of an interrupt” (Kojima [0043])
“Specifically, the interrupt handler may notify the occurrence of a processing request to the communication processing task in "wait status", change the communication processing task to "ready status", and request task scheduling to the OS. It is preferred to give the highest execution priority in the slave processor 21 to the communication processing task in order that the communication processing task is executed preferentially” (Kojima [0044])
“This is because the relative relationship of the execution priorities of the request source tasks C and D in the master processor 11 is reflected on the execution priorities of the child tasks c and d. Thus, the child task d does not start running until the other tasks with the higher execution priority than the child task d end or those tasks release the rights to use the slave processor 21 for some reason” (Kojima [0054] task D is postponed due to a running child task C that has a higher priority)
Claims 2-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kojima (October 29, 2009), Vis (published November 27, 2008), and Nguyen (published August 04, 2022) as applied to claim 1 above, and further in view of Zilavy (US 2002/0161975) (hereinafter Zilavy) (published October 31, 2002).
Regarding Claim 2, the combination of Kojima, Vis, and Nguyen disclosed the system of claim 1, but does not explicitly state further comprising a third memory controller configured to connect to the shared upstream resource via a third channel and to connect to a third memory via a third memory channel, wherein the first sideband bus is further configured to: connect the first memory controller with the third memory controller; connect the second memory controller with the third memory controller; and transmit sideband connected memory controller signals between the first memory controller and the third memory controller and between the second memory controller and the third memory controller.
Zilavy discloses further comprising a third memory controller configured to connect to the shared upstream resource via a third channel and to connect to a third memory via a third memory channel, wherein the first sideband bus is further configured to: connect the first memory controller with the third memory controller; connect the second memory controller with the third memory controller; and transmit sideband connected memory controller signals between the first memory controller and the third memory controller and between the second memory controller and the third memory controller.
“Unshared "clean data present" sideband signals, or HITC signals (on conductors 44, 46, 50, and 52 ) are added to the computer system 10 to enable cache to cache copying of clean data. (The term "sideband" refers to the fact that the signals are not a part of the standard bus architecture in the preferred exemplary embodiment.) Each of the sideband signal conductors 44-52 are connected to every processor 12-20 in the computer system 10” (Zilavy [0032])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to modify the system in the combination of Kojima, Vis, and Nguyen to incorporate Zilavy’s sideband connections among multiple memory controllers/processors. Zilavy teaches that sideband signal conductors can be connected to every processor in the system, thereby allowing the processors to communicate cache-related information independently of the standard bus architecture. Applying this teaching to the system in the combination of Kojima, Vis, and Nguyen would extend the existing sideband communication capability to the third memory controller and allow the first, second, and third memory controllers to exchange connected-memory-controller signals directly over the sideband bus. The motivation for this combination would be to provide a dedicated communication path for time-sensitive controller-to-controller signals without requiring those signals to traverse or compete for bandwidth on the shared upstream resource. Using Zilavy’s sideband connections would reduce contention on the primary bus and provide more direct, predictable, and low-latency transmission of signals between the memory controllers, including signals exchanged with the third memory controller. Thus, the modification would improve communication efficiency and responsiveness while using Zilavy’s sideband architecture for its known purpose of carrying signals separately from the standard bus.
Regarding Claim 3, the combination of Kojima, Nguyen, and Zilavy further discloses wherein: the first channel, the second channel, and the third channel are subchannels of a fourth channel; and the first memory channel, the second memory channel, and the third memory channel are memory subchannels of a fourth memory channel.
The combination of Kojima, Vis, Nguyen, and Zilavy teaches teach a first channel, a second channel, third channel, a first memory channel, second memory channel, and a third memory channel (see rejection above, Fig.1 of Kojima, Fig. 1 of Nguyen, and Fig. 1 of Zilavy). While Kojima, Vis, Nguyen, and Zilavy does not explicitly recite that these channels are "subchannels of a fourth channel" or “subchannels of a fourth memory channel”, this limitation is a mere subdivision or duplication of structural units with no change in function. Under MPEP 2144.04(VI), the "mere duplication of parts has no patentable significance unless a new and unexpected result is produced". Here, the "fourth channel" or “fourth memory channel” acts as a mere container or logical grouping for the existing first, second, and third channels, or first, second, and third memory channels, and the applicant has not shown that this hierarchical naming produces any result beyond the separate, sequential operation of the channels already known in the art. Furthermore, the configuration of the first, second, and third channels as subchannels of a larger channel or the configuration of the first, second, and third memory channels as subchannels of a larger memory channel is a matter of design choice regarding the logical layout of the computing system. As noted in MPEP 2144.04(VI), the particular placement or grouping of components is generally obvious where the components perform the same function regardless of their label. A person of ordinary skill in the art, seeking to organize data paths in a multi-channel memory system, would have found it obvious to treat individual channels as sub-units of a common bus, "fourth channel", or “fourth memory channel” to simplify addressing or routing logic. The modification is a routine application of well-known architectural principles and provides no unexpected technical advantage.
Regarding Claim 4, The combination of Kojima, Vis, and Nguyen disclosed the system of claim 1 but does not explicitly state further comprising: a third memory controller configured to connect to the shared upstream resource via a third channel and to connect to a third memory via a third memory channel; and a second sideband bus configured to connect the first memory controller and the third memory controller and configured to transmit sideband connected memory controller signals between the first memory controller and the third memory controller.
Zilavy discloses further comprising: a third memory controller configured to connect to the shared upstream resource via a third channel and to connect to a third memory via a third memory channel; and
“the address and data buses 36 and 38 and the HIT and HITM signals 42 and 40 allow processors to coordinate transfers of data throughout the computer system 10. A first example will now be given which describes the behavior of the computer system 10 having a shared "clean data present" signal 42 without the sideband signals which enable cache to cache copying of clean data, to be described hereinafter. In this first example, data is contained in the external memory 32 and in the caches 24 and 26 of processors 1 14 and 2 16 (both in clean form)” (Zilavy [0029])
a second sideband bus configured to connect the first memory controller and the third memory controller and configured to transmit sideband connected memory controller signals between the first memory controller and the third memory controller.
“Unshared "clean data present" sideband signals, or HITC signals (on conductors 44, 46, 50, and 52 ) are added to the computer system 10 to enable cache to cache copying of clean data. (The term "sideband" refers to the fact that the signals are not a part of the standard bus architecture in the preferred exemplary embodiment.) Each of the sideband signal conductors 44-52 are connected to every processor 12-20 in the computer system 10” (Zilavy [0032] see fig. 1 there are four buses/conductors for the HITC signals)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to modify the system in the combination of Kojima, Vis, and Nguyen to incorporate Zilavy’s sideband connections among multiple memory controllers/processors. Zilavy teaches that sideband signal conductors can be connected to every processor in the system, thereby allowing the processors to communicate cache-related information independently of the standard bus architecture. Applying this teaching to the system in the combination of Kojima, Vis, and Nguyen would extend the existing sideband communication capability to the third memory controller and allow the first, second, and third memory controllers to exchange connected-memory-controller signals directly over the sideband bus. The motivation for this combination would be to provide a dedicated communication path for time-sensitive controller-to-controller signals without requiring those signals to traverse or compete for bandwidth on the shared upstream resource. Using Zilavy’s sideband connections would reduce contention on the primary bus and provide more direct, predictable, and low-latency transmission of signals between the memory controllers, including signals exchanged with the third memory controller. Thus, the modification would improve communication efficiency and responsiveness while using Zilavy’s sideband architecture for its known purpose of carrying signals separately from the standard bus.
Claims 7 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kojima (October 29, 2009), Vis (published November 27, 2008), and Nguyen (published August 04, 2022) as applied to claim 1 above, and further in view of Stufflebeam (US 6,460,106) (hereinafter Stufflebeam) (published October 1, 2002).
Regarding Claim 7, the combination of Kojima, Vis, and Nguyen disclosed the system of claim 1, but does not explicitly state wherein the first sideband bus is a parallel bus.
Stufflebeam discloses wherein the first sideband bus is a parallel bus.
“These sideband signals typically connect to the I/O controller but may be connected to virtually any component within the computer. Examples of sideband signals include power and ground signals, interrupt signals, and I/O signals such as serial and parallel port signals, keyboard and mouse signals, and audio and video signals” (Stufflebeam col 3 lines 6-15)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to configure the side band bus as either a parallel bus or a serial bus because these represent a limited number of identified, predictable solutions for interconnecting components within a computing system. A designer seeking to establish a side band communication path between processors would be faces with the routine technical choice of selecting a bus width based on the specific trade-offs between pin count and data throughput and given that both serial and parallel interfaces are well-known standard options the selection of one over the other is the product of ordinary skill and common sense. Furthermore there is a high expectation of success in the implementation of either bus types to achieve the same results of data transmission.
Regarding Claim 8, the combination of Kojima, Vis, and Nguyen disclosed the system of claim 1, but does not explicitly state wherein the first sideband bus is a serial bus.
Stufflebeam discloses wherein the first sideband bus is a serial bus.
“These sideband signals typically connect to the I/O controller but may be connected to virtually any component within the computer. Examples of sideband signals include power and ground signals, interrupt signals, and I/O signals such as serial and parallel port signals, keyboard and mouse signals, and audio and video signals” (Stufflebeam col 3 lines 6-15)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to configure the side band bus as either a parallel bus or a serial bus because these represent a limited number of identified, predictable solutions for interconnecting components withing a computing system. A designer seeking to establish a side band communication path between processors would be faces with the routine technical choice of selecting a bus width based on the specific trade-offs between pin count and data throughput and given that both serial and parallel interfaces are well-known standard options the selection of one over the other is the product of ordinary skill and common sense. Furthermore there is a high expectation of success in the implementation of either bus types to achieve the same results of data transmission.
Claims 12 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kojima (October 29, 2009), Vis (published November 27, 2008), and Nguyen (published August 04, 2022) as applied to claims 1 and 15 above, and further in view of Wang et al. (US 2022/0028450) (hereinafter Wang) (published January 27, 2022).
Regarding Claim 12, the combination of Kojima, Vis, and Nguyen disclosed the system of claim 12 but does not explicitly state wherein the process for the first memory is at least one of an all-bank refresh, a per-bank refresh, transaction batching, DRAM memory calibration, or DRAM memory training.
Wang discloses wherein the process for the first memory is at least one of an all-bank refresh, a per-bank refresh, transaction batching, DRAM memory calibration, or DRAM memory training.
“Automatic refresh logic 220 enables the memory controller to periodically refresh the DRAMs with the auto-refresh commands. Automatic refresh logic 220 may be limited, such as by only allowing selecting a single rank, one bank, or multiple banks, at a time, for example. Fine granularity automatic refresh may be included with automatic refresh logic 220 and may be utilized for DDR4 memory products. Automatic refresh logic 220 may include logic that tracks when a refresh is needed and may send refresh command requests to arbiter 260 for subsequent transmission to the DRAM based on the tracking. Automatic refresh logic 220 may enable per bank refresh as supported in DRAM technologies where it is permitted, such as LPDDR4/HBM, for example” (Wang [0031])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to incorporate Wang’s per-bank refresh process into the system in the combination of Kojima, Vis, and Nguyen. Wang expressly teaches that a memory controller can perform automatic per-bank refresh of DRAM, including tracking when refresh is needed and issuing the appropriate refresh commands. Applying this known memory-management technique to the first memory would provide the claimed refresh process. The motivation would be to maintain DRAM data integrity and reliability while reducing unnecessary disruption to other banks. Per-bank refresh allows individual banks to be refreshed as needed rather than refreshing the entire memory, thereby improving memory availability and operational efficiency.
Regarding Claim 18, the combination of Kojima, Vis, and Nguyen disclosed the method of claim 15 but does not explicitly state wherein the process for the first memory is at least one of an all-bank refresh, a per-bank refresh, transaction batching, DRAM memory calibration, or DRAM memory training.
Wang discloses wherein the process for the first memory is at least one of an all-bank refresh, a per-bank refresh, transaction batching, DRAM memory calibration, or DRAM memory training.
“Automatic refresh logic 220 enables the memory controller to periodically refresh the DRAMs with the auto-refresh commands. Automatic refresh logic 220 may be limited, such as by only allowing selecting a single rank, one bank, or multiple banks, at a time, for example. Fine granularity automatic refresh may be included with automatic refresh logic 220 and may be utilized for DDR4 memory products. Automatic refresh logic 220 may include logic that tracks when a refresh is needed and may send refresh command requests to arbiter 260 for subsequent transmission to the DRAM based on the tracking. Automatic refresh logic 220 may enable per bank refresh as supported in DRAM technologies where it is permitted, such as LPDDR4/HBM, for example” (Wang [0031])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to incorporate Wang’s per-bank refresh process into the system in the combination of Kojima, Vis, and Nguyen. Wang expressly teaches that a memory controller can perform automatic per-bank refresh of DRAM, including tracking when refresh is needed and issuing the appropriate refresh commands. Applying this known memory-management technique to the first memory would provide the claimed refresh process. The motivation would be to maintain DRAM data integrity and reliability while reducing unnecessary disruption to other banks. Per-bank refresh allows individual banks to be refreshed as needed rather than refreshing the entire memory, thereby improving memory availability and operational efficiency.
Claims 14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kojima (October 29, 2009), Vis (published November 27, 2008), and Nguyen (published August 04, 2022) as applied to claims 1 and 15 above, and further in view of Nagarajan et al. (US 2016/0188469) (hereinafter Nagarajan) (published June 30, 2016).
Regarding Claim 14, the combination of Kojima, Vis, and Nguyen disclosed the system of claim 1, and Kojima further discloses wherein the first memory controller comprises a processor system configured to: poll the second memory controller for memory controller information;
“A task which is executed in the master processor 11 and makes a processing request to the slave processor 21 is referred to hereinafter as a "request source task". In Step S11, it is determined whether transmission of a processing request to the slave processor 21 is possible. Specifically, it may be determined whether an available free space of the shared memory 30 is large enough for interprocessor communication, that is, whether it is large enough to store communication data containing a processing request” (Kojima [0034] checks the slave processor information)
identify whether the second memory controller is performing a process for the second memory causing the congestion at the shared upstream resource from the memory controller information;
“FIG. 7 is a timing chart showing a transition process of execution tasks in the master processor 11 and the slave processor 21 in the information processing system 1 according to the embodiment. The information processing system 1 is capable of executing the tasks in the same sequence as in the single processor shown in FIG. 6, in spite of a multiprocessor configuration. This is described in detail hereinbelow” (Kojima [0055] see fig. 7, tasks being performed are identified whenever they are running)
But does not explicitly state identify whether a delay for implementing a process for the first memory using the shared upstream resource exceeds a delay threshold; and provide a scheduler executed by the processor system with an indication to schedule the process for the first memory using the shared upstream resource in response to identifying that the second memory controller is performing a process for the second memory causing the congestion at the shared upstream resource and identifying that the delay for implementing the process for the first memory using the shared upstream resource exceeds the delay threshold.
Nagarajan and Kojima discloses identify whether a delay for implementing a process for the first memory using the shared upstream resource exceeds a delay threshold; and
“Once the last read request is sent to the memory controller, if the number of entries in the flush pool is above the casual flush limit, a counter called the casual flush timer starts incrementing every′ clock cycle. If no new read requests to memory are received by the fabric and the casual flush timer reaches the value specified by the casual flush delay, which is a threshold stored in a configuration register, the memory scheduler begins sending write requests to the memory controller. This casual flush continues until the number of entries in the flush pool is less than the casual flush limit or until a new read request is received by the fabric” (Nagarajan [0107])
provide a scheduler executed by the processor system with an indication to schedule the process for the first memory using the shared upstream resource in response to identifying that the second memory controller is performing a process for the second memory causing the congestion at the shared upstream resource and identifying that the delay for implementing the process for the first memory using the shared upstream resource exceeds the delay threshold.
“Once the last read request is sent to the memory controller, if the number of entries in the flush pool is above the casual flush limit, a counter called the casual flush timer starts incrementing every′ clock cycle. If no new read requests to memory are received by the fabric and the casual flush timer reaches the value specified by the casual flush delay, which is a threshold stored in a configuration register, the memory scheduler begins sending write requests to the memory controller. This casual flush continues until the number of entries in the flush pool is less than the casual flush limit or until a new read request is received by the fabric” (Nagarajan [0107])
“Specifically, the interrupt handler may notify the occurrence of a processing request to the communication processing task in "wait status", change the communication processing task to "ready status", and request task scheduling to the OS. It is preferred to give the highest execution priority in the slave processor 21 to the communication processing task in order that the communication processing task is executed preferentially” (Kojima [0044])
“Then, when a processing request is made from the task D, which is one of the request source tasks, at T3 during the running of the child task c, the communication processing task is activated and creates a child task d. The execution priority of the child task d in the slave processor 21 is set lower than the execution priority of the child task c, which is currently running” (Kojima [0054] task D is scheduled during processing of child task C)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to incorporate Nagarajan’s threshold-based delay and memory scheduling techniques into the system in the combination of Kojima, Vis, and Nguyen. Nagarajan teaches using a configurable delay threshold to determine when the memory scheduler should begin transferring pending requests, while Kojima teaches task scheduling based on the status and priority of tasks being executed by the processors. Combining these teachings would allow the processor system to recognize when congestion or delay at the shared upstream resource exceeds a selected threshold and provide the scheduler with an indication to schedule the process for the first memory. The motivation for the combination would be to improve memory-system efficiency by preventing excessive accumulation of pending memory requests and prioritizing transfers when congestion or delay warrants action. As Nagarajan explains, “the memory scheduler uses configurable threshold values to specify when to start and stop transferring a burst of write requests to the memory controller. The memory scheduler may perform different types of transfers of write data to memory. e.g., a high priority transfer and a low priority transfer, also termed herein as a high priority flush of write requests and casual flush of write requests to memory, respectively. When the number of entries in the flush pool reaches or exceeds a threshold value (the flush high water mark), the memory scheduler begins scheduling a high priority write flush to memory and begins sending write requests to the memory controller” (Nagarajan [0106]).
Regarding Claim 20, the combination of Kojima, Vis, and Nguyen disclosed the method of claim 15, but does not explicitly state further comprising: identifying whether a delay for implementing the process for the first memory using the shared upstream resource exceeds a delay threshold; and providing a scheduler executed by the at least one processor system with an indication to schedule the process for the first memory using the shared upstream resource in response to identifying that the second memory controller is performing a process for the second memory causing the congestion at the shared upstream resource and identifying that the delay for implementing the process for the first memory using the shared upstream resource exceeds the delay threshold.
Nagarajan and Kojima discloses further comprising: identifying whether a delay for implementing the process for the first memory using the shared upstream resource exceeds a delay threshold; and
“Once the last read request is sent to the memory controller, if the number of entries in the flush pool is above the casual flush limit, a counter called the casual flush timer starts incrementing every′ clock cycle. If no new read requests to memory are received by the fabric and the casual flush timer reaches the value specified by the casual flush delay, which is a threshold stored in a configuration register, the memory scheduler begins sending write requests to the memory controller. This casual flush continues until the number of entries in the flush pool is less than the casual flush limit or until a new read request is received by the fabric” (Nagarajan [0107])
providing a scheduler executed by the at least one processor system with an indication to schedule the process for the first memory using the shared upstream resource in response to identifying that the second memory controller is performing a process for the second memory causing the congestion at the shared upstream resource and identifying that the delay for implementing the process for the first memory using the shared upstream resource exceeds the delay threshold.
“Once the last read request is sent to the memory controller, if the number of entries in the flush pool is above the casual flush limit, a counter called the casual flush timer starts incrementing every′ clock cycle. If no new read requests to memory are received by the fabric and the casual flush timer reaches the value specified by the casual flush delay, which is a threshold stored in a configuration register, the memory scheduler begins sending write requests to the memory controller. This casual flush continues until the number of entries in the flush pool is less than the casual flush limit or until a new read request is received by the fabric” (Nagarajan [0107])
“Specifically, the interrupt handler may notify the occurrence of a processing request to the communication processing task in "wait status", change the communication processing task to "ready status", and request task scheduling to the OS. It is preferred to give the highest execution priority in the slave processor 21 to the communication processing task in order that the communication processing task is executed preferentially” (Kojima [0044])
“Then, when a processing request is made from the task D, which is one of the request source tasks, at T3 during the running of the child task c, the communication processing task is activated and creates a child task d. The execution priority of the child task d in the slave processor 21 is set lower than the execution priority of the child task c, which is currently running” (Kojima [0054] task D is scheduled during processing of child task C)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to incorporate Nagarajan’s threshold-based delay and memory scheduling techniques into the system in the combination of Kojima, Vis, and Nguyen. Nagarajan teaches using a configurable delay threshold to determine when the memory scheduler should begin transferring pending requests, while Kojima teaches task scheduling based on the status and priority of tasks being executed by the processors. Combining these teachings would allow the processor system to recognize when congestion or delay at the shared upstream resource exceeds a selected threshold and provide the scheduler with an indication to schedule the process for the first memory. The motivation for the combination would be to improve memory-system efficiency by preventing excessive accumulation of pending memory requests and prioritizing transfers when congestion or delay warrants action. As Nagarajan explains, “the memory scheduler uses configurable threshold values to specify when to start and stop transferring a burst of write requests to the memory controller. The memory scheduler may perform different types of transfers of write data to memory. e.g., a high priority transfer and a low priority transfer, also termed herein as a high priority flush of write requests and casual flush of write requests to memory, respectively. When the number of entries in the flush pool reaches or exceeds a threshold value (the flush high water mark), the memory scheduler begins scheduling a high priority write flush to memory and begins sending write requests to the memory controller” (Nagarajan [0106]).
Response to Arguments
Claim Objections
Applicant’s arguments, see page 10 of remarks, filed July 29, 2026, with respect to claims 9-11, 13, 15-17, and 20 have been fully considered and are persuasive. The objections of claims 9-11, 13, 15-17, and 20 has been withdrawn.
Reply to Office’s Response to Arguments
Applicant’s arguments, see pages 11-12 of remarks, filed July 29, 2026, with respect to claims 1-20 have been fully considered and are persuasive. The 35 USC § 112 rejections of claims 1-20 has been withdrawn.
Applicant’s arguments, see pages 12-14, filed July 29, 2026, with respect to the rejection(s) of claim(s) 1-20 under 35 USC § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of KOJIMA (US 2009/0271796), VISWANATHAN (US 2008/0294823), and Nguyen et al. (US 2022/0244966) for claims 1, 5, 6, 9-11, 13, 15-17, and 19. And further in view of Zilavy (US 2002/0161975) for claims 2-4, Stufflebeam (US 6,460,106) for claims 7 and 8, Wang et al. (US 2022/0028450) for claims 12 and 18, and Nagarajan et al. (US 2016/0188469) for claims 14 and 20.
Kojima discloses when the processes/tasks are being performed and not performed and the combination with Viswanathan would discloses the interpretation of when the processes/tasks are being performed and not performed from the controller information indicating the status and one of ordinary skill in the art would further conclude and interpret from the disclosures of Kojima and Viswanathan that an process not actively being executed would be a cause of “congestion” due to the need to wait for the results of the execution.
Kojima’s child tasks are causing congestion at the shared memory resources as shown in paragraph [0043] of Kojima as it is polling for the completion of the task, as long as the task is not completed it is congested and is not able to continue. Furthermore the polling for completion when combined with Viswanathan would yield the polling for the status which includes queued, executing and suspended. These statuses of the process/requests would be controller information that is polled.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIDNEY LI whose telephone number is (571)270-5967. The examiner can normally be reached Monday to Friday 10:00 AM to 6:00 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, Arpan P 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.
/S.L./Examiner, Art Unit 2137
/PRASITH THAMMAVONG/Primary Examiner, Art Unit 2137
Prosecution Insights