DETAILED ACTION
Claims 1 and 8 are amended. Claims 1-14 are pending in the application.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e).
Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
Response to Amendment
Amendments to claim 8 are fully considered and are satisfactory to overcome the rejections under 35 U.S.C. §101 directed to claims 8-13 in the previous Office Action.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 6, 8-10, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Ravich et al. (US 2022/0229711 A1; hereinafter “Ravich”) in view of Smith (US 2018/0074835 A1).
With respect to claim 1, Ravich teaches: A method for communicating between software components (SWCs) (see e.g. Ravich, paragraph 3: “threads running on different cores”) in a multi-core system (see e.g. Ravich, paragraph 13: “implementing an asymmetric arrangement for remote procedure calls (RPCs) between multi-core devices”), the method comprising:
determining, by a linker script (see e.g. Ravich, paragraph 21: “Pairing relationships 102 are configured to synchronize changes between nodes a and b using RDMA”; and paragraph 1: “Software running on the storage processors manages incoming storage requests and performs various data processing tasks”), a memory operating as a data buffer (see e.g. Ravich, paragraph 18: “Memory 40 also stores a shared receive queue (SRQ) 42, a shared completion queue (Shared CQ) 44”; paragraph 21: “Pairing relationships 102 are configured to synchronize changes between nodes a and b using RDMA”; and Fig. 2), based on an execution cycle of each of the SWCs (see e.g. Ravich, paragraph 13: “cores of the target device poll the Shared CQ when they have free cycles”; and paragraph 31: “When core 35-b(S) has free processing cycles, Core S application thread 56-b(S) may perform step 401 to poll (e.g., by sending a polling request 80) the Shared CQ 44(b)”), when communicating between an SWC executed by a first core and at least one SWC executed by a second core (see e.g. Ravich, paragraph 13: “remote procedure calls (RPCs) between multi-core devices using Remote Direct Memory Access (RDMA)… a single shared receive queue that is shared between multiple cores on a target device. The shared receive queue is associated with a single shared completion queue (Shared CQ) of the target device, the Shared CQ being configured to report completed receipt of commands by the associated shared receive queue”; and paragraph 21: “whenever an application thread 56-a(x) on node a makes a change to its respective core x send queue 52-a(x), that change is automatically synchronized to the SRQ 42(b) of node b over pairing relationship 102-a(x)”);
writing, by the SWC executed by the first core (see e.g. Ravich, paragraph 28: “Core P application thread 56-a(P)”; and Fig. 3B: “Initiator Node”), data in the data buffer (see e.g. Ravich, paragraph 28: “Core P application thread 56-a(P) generates a work queue element (WQE) 72 (depicted as a Receive WQE in FIG. 3B) that describes the reply buffer 71 (e.g., it points to the memory address of reply buffer 71) and stores (step 304) the Receive WQE 72 in the shared receive queue 12(a)”); and
reading, by the at least one SWC executed by the second core (see e.g. Ravich, paragraph 31: “Core S application thread 56-b(S)”; and Fig. 3C: “Target Node”), the data from the data buffer (see e.g. Ravich, paragraph 31: “Core S application thread 56-b(S) may perform step 401 to poll (e.g., by sending a polling request 80) the Shared CQ 44(b) of computing device 32(b) for a newly-received request… Shared CQ 44(b) to respond (step 403) by sending a completion queue element (CQE) 81 back to Core S application thread 56-b(S) (or to the core-specific polling thread for core S, which then forwards the CQE 81 to the Core S application thread 56-b(S)). CQE 81 points to the Receive WQE 64 that was just received”; and paragraph 33: “Core S application thread 56-b(S) handles the RPC request encoded in the request buffer 62 pointed to by the Receive WQE 64 pointed to by the CQE 81”);
wherein the SWC executed by the first core and the at least one SWC executed by the second core communicate with each other using information about the memory set to the data buffer (see e.g. Ravich, paragraph 18: “Memory 40 also stores a shared receive queue (SRQ) 42, a shared completion queue (Shared CQ) 44”; paragraph 13: “a single shared receive queue that is shared between multiple cores on a target device. The shared receive queue is associated with a single shared completion queue (Shared CQ) of the target device, the Shared CQ being configured to report completed receipt of commands by the associated shared receive queue”; paragraph 21: “whenever an application thread 56-a(x) on node a makes a change to its respective core x send queue 52-a(x), that change is automatically synchronized to the SRQ 42(b) of node b over pairing relationship 102-a(x)”; and paragraphs 28, 31)
Ravich discloses pairing relationships between core-specific queues and shared receive/completion queues (i.e. memory operating as data buffers), the shared queues used for implementing communications between application threads (i.e. software components) running on different cores. A first thread running on a first core sends a remote procedure call (RPC) request to a second application thread running on a second core by writing the RPC request to the shared queues (as determined by the pairing relationship) which is then read by the second thread from the shared queue.
On the other hand, Ravich does not but Smith teaches:
using the linker script (see e.g. Smith, paragraph 85: “generate linker scripts 324 and 325 that cause the linker 306 to allocate shared memory addresses to symbols of the first and second programs, the programmer can simply identify the symbols which are placed in shared memory and which partition they are to be stored in and leave the linker driver 304 to identify the appropriate mappings between the symbols and addresses of the shared memory”; and Fig. 1).
Ravich and Smith are analogous art because they are in the same field of endeavor: managing inter-process communications between different cores by utilizing a shared memory. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Ravich with the teachings of Smith. The motivation/suggestion would be to improve the memory management and allocation process (see Smith, paragraphs 2-3).
With respect to claim 2, Ravich as modified teaches: The method of claim 1, wherein the data is runtime environment (RTE) data (see e.g. Ravich, paragraph 1: “Software running on the storage processors manages incoming storage requests and performs various data processing tasks”; and Fig. 3B-C).
With respect to claim 3, Ravich as modified teaches: The method of claim 1, wherein each of the first core and the second core includes at least one memory (see e.g. Ravich, paragraph 18: “a set of per-core memory spaces 50”; and Fig. 1: “Core P Memory Space 50-a(P)”, “Core S Memory Space 50-b(S)”).
With respect to claim 6, Ravich as modified teaches: The method of claim 3, wherein each of the at least one memory includes at least one of a program scratch-pad random-access memory (PSPR), a data scratch-pad random-access memory (DSPR), a direct-connected local memory unit (DLMU), a default application memory (DAM), a program flash memory (PFLASH) (see e.g. Ravich, paragraph 49: “flash memory, etc.) programmed with instructions”), a data flash memory (DFLASH) (see e.g. Ravich, paragraph 1: “Data storage systems… electronic flash drives”), or an extension memory (EMEM), or any combination thereof.
With respect to claims 8-10 and 13: Claims 8-10 and 13 are directed to a multi-core system comprising a processor and a memory to implement active functions corresponding to the method implemented in the multi-core system recited in claims 1-3 and 6, respectively; please see the rejections directed to claims 1-3 and 6 above which also cover the limitations recited in claims 8-10 and 13. Note that, Ravich also discloses computing devices 32 comprising processing circuitry 36 and memory 40 to implement the method disclosed in claims 1-3 and 6 (see e.g. Ravich, Fig. 1).
Claims 4, 5, 11, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Ravich in view of Smith as applied to claims 3 and 10 above, and further in view of McKown (US 9,942,327 B1).
With respect to claim 4, Ravich as modified teaches: The method of claim 3, wherein the determining of the memory operating as the data buffer includes:
setting, by the linker script, the data buffer in the memory included in the first core (see e.g. Ravich, paragraph 19: “Each core-specific send queue 52-a has a pairing relationship 102 (depicted as pairing relationships 102-a(1), 102-a(2), 102-a(3), . . . 102-a(M)) to a single shared receive queue SRQ 42(b)”; paragraph 21; and Fig. 1-2),
Ravich does not but McKown teaches:
when an execution cycle of the SWC executed by the first core is shorter than or equal to an execution cycle of the at least one SWC executed by the second core (see e.g. McKown, column 8, lines 47-54: “Shared Buffer Memory Manager 665 is only employed for memory sharing favorable cases of the buffer timing parameters. An example favorable case is when the native processing cycle time for Application 3 is faster than Application 2 is faster than Application 1 is faster than Input Device. The native processing cycle time refers here to the time it takes to completely process an input buffer to an output buffer”).
Ravich and McKown are analogous art because they are in the same field of endeavor: managing access and utilization of a shared memory based on execution cycles. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Ravich with the teachings of McKown. The motivation/suggestion would be to improve the shared memory access efficiency.
With respect to claim 5, Ravich as modified teaches: The method of claim 3, wherein the determining of the memory operating as the data buffer includes:
setting, by the linker script, the data buffer in the memory included in the second core (see e.g. Ravich, paragraph 20: “ Each core-specific send queue 52-b has a pairing relationship 102 (depicted as pairing relationships 102-b(1), 102-b(2), . . . 102-b(N)) to a single shared receive queue SRQ 42(a)”; paragraph 21; and Fig. 1-2),
Ravich does not but McKown teaches:
when an execution cycle of the SWC executed by the first core is longer than an execution cycle of the at least one SWC executed by the second core (see e.g. McKown, column 8, lines 47-54: “Shared Buffer Memory Manager 665 is only employed for memory sharing favorable cases of the buffer timing parameters. An example favorable case is when the native processing cycle time for Application 3 is faster than Application 2 is faster than Application 1 is faster than Input Device. The native processing cycle time refers here to the time it takes to completely process an input buffer to an output buffer”).
Ravich and McKown are analogous art because they are in the same field of endeavor: managing access and utilization of a shared memory based on execution cycles. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Ravich with the teachings of McKown. The motivation/suggestion would be to improve the shared memory access efficiency.
With respect to claims 11 and 12: Claims 11 and 12 are directed to a multi-core system implementing active functions corresponding to the method implemented in the multi-core system recited in claims 4 and 5, respectively; please see the rejections directed to claims 4 and 5 above which also cover the limitations recited in claims 11 and 12.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ravich in view of Smith as applied to claims 1 and 8 above, and further in view of Iida et al. (US 2021/0049057 A1; hereinafter Iida).
With respect to claim 7, Ravich as modified teaches: The method of claim 1,
Ravich does not but Iida teaches:
wherein the multi-core system is an autonomous driving electronic control unit (ECU) having a multi-core hardware architecture (see e.g. Iida, paragraph 33: “drive device 5 is an actuator or the like that drives mechanical and electric devices (for example, an engine, a transmission, wheels, a brake, a steering device, etc.) that control the vehicle motion under the control of the vehicle control system 2”; paragraph 47: “ECU 302 includes a plurality of cores 401 as a processing device, a plurality of local memories 402, a timer 403, a ROM 404, a shared memory 405”; and Fig. 3).
Ravich and Iida are analogous art because they are in the same field of endeavor: managing access and utilization of a shared memory within a multi-core processing environment. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Ravich with the teachings of Iida. The motivation/suggestion would be to increase the compatibility and applicability of the system with different platforms.
With respect to claim 14: Claims 8-10 and 13 are directed to a multi-core system implementing active functions corresponding to the method implemented in the multi-core system recited in claims 1-3 and 6, respectively; please see the rejections directed to claims 1-3 and 6 above which also cover the limitations recited in claims 8-10 and 13.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 and 8 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
More specifically, even though Ravich discloses utilizing shared queues for implementing communications between application threads (i.e. software components) running on different cores (see e.g. Ravich, paragraphs 21, 28, 31), Ravich does not disclose this communication between the threads being implemented by “using a linker script”.
However, Smith discloses utilizing linker scripts to implement communications between different cores using a shared memory space (see e.g. Smith, paragraph 85; Fig. 1). For more details, please see the Claim Rejections - 35 USC § 103 section above.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kim et al. (US 2005/0010911 A1) discloses a linker script for an application that provides a data section table showing a data section start address of libraries needed by the application (see paragraph 33; Fig. 6).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached at (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194
Prosecution Insights