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 .
Continued Examination Under 37 CFR 1.114
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 02/03/2026 has been entered.
Information Disclosure Statement
The information disclosure statement provided filed on 02/03/2026 has been considered.
Status of Claims
The present application is being examined under the claims filed 02/03/2026. Claims 1-21 are pending. Claims 1-21 are rejected.
Response to Arguments
I. Applicant's arguments filed on 02/03/2026 have been fully considered but they are not persuasive.
II. Applicant alleges that Ditty does not teach "identifying, ... during the boot process for the first SoC, a node configuration based on the node configuration indicating the first SoC, the node configuration defining a node, wherein the node configuration indicates a dynamic mapping of the first SoC and at least one second SoC of the set of SoCs to the node to share access to the compute resource of the first SoC, wherein the dynamic mapping of the first SoC and the at least one second SoC to the node to share access to the compute resource of the first SoC is configurable based on input received via a user computing device" Rem 6, as recited in amended claim 1. Specifically, applicant states that Office Action fails to provide such a basis in fact and/or technical reasoning to reasonably support the determination that 1) "it would be apparent to map hardware relations to the boot configuration table, which would be read to identify resources available to each SoC, including SoCs with shared resources (i.e., nodes) at the time of startup," Rem 7.
However, Ditty teaches a component of each SoC used during boot to handle boot functions for resources on the SoC [e.g., system states] (Ditty par. 235). Furthermore, Ditty states that the boot process for the SoCs include a boot configuration table (Ditty par. 450), and that the mapping for virtual CPU operations to actual CPUs on the SoCs may be stored in a partition configuration table and controlled dynamically (Ditty par. 368). Therefore, the node configurations involving shared resources (i.e., the configurations of SoCs working together or independently, see Ditty par. 292, any number of SoCs may be combined [i.e., node configuration], and Ditty par. 294, memory is shared between SOCs due to hardware configuration, “all of the memory systems could be shared between the SOCs 2002”; and Ditty FIG. 20, depicting shared resources between SoCs (e.g., memory 2008, GPU 2006)) are identified during the boot process. While Ditty does not explicitly teach “identifying, during the boot process for the first SoC” and “the dynamic mapping of the first SoC and the at least one second SoC to the node to share access to the compute resource of the first SoC is configurable based on input received via a user computing device,” Hira and Javre are used to address these limitations respectively.
III. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Applicant argues that Hira, nor Javre teach the limitation “the node configuration indicates a dynamic mapping of the first SoC and at least one second SoC of the set of SoCs to the node to share access to the compute resource of the first SoC, wherein the dynamic mapping of the first SoC and the at least one second SoC to the node to share access to the compute resource of the first SoC is configurable based on input received via a user computing device.” However, Hira and Javre are used in combination with Ditty to teach the above limitation.
Hira is relied upon for the explicit teaching that finding “a dynamic mapping of the SoC and at least one additional SoC of the set of SoCs to the node” occurs during a boot process (Hira FIG. 4 and par. 28-29, powering up [i.e., booting] auxiliary SOCs in response to a large workload [i.e., dynamically configuring, also see par. 31], and share resources to process the workload [i.e., function as a node]), while Javre is relied upon to teach “wherein the node configuration is configurable based on input received via a user computing device” (Javre FIG. 5 and par. 58, based upon user inputs 520 specifies domains [i.e., nodes], e.g., which processors are included in each respective domains, the operating system to be executed by each processor, peripherals and/or memory to be available to each processor in each domain [i.e., node configuration]; also see par. 21, a software developer [i.e., user] may utilize the domain creation tool to modify one or more of the different domains). Therefore, the combination of Ditty, Hira, and Javre teach the limitation.
IV. Applicant’s remaining arguments filed 02/03/2026 have been considered but are moot due to the new grounds of rejection, as well as the newly cited portions of the references previously presented.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-21 are rejected under 35 U.S.C. 103 as being unpatentable over Ditty et. al. (US 2019/0258251 A1) [previously cited] in view of Hira (US 2016/0306677 A1) [previously cited], further in view of Javre et. al. (US 2019/0324806 A1).
Regarding Claim 1, Ditty teaches a method (Ditty describes a method comprising a system using a set of SoCs [see fig. 20 and par. 292] operating to facilitate autonomous driving functionality) comprising:
initializing, with at least one processor, a boot process for a first system-on-chip (SoC) of a set of SoCs (Ditty par. 449-450, security supervisor 5014(2) can command the boot processor 5060 to perform a secure trusted boot of the SOC; and par. 279, system has multiple SoCs);
initializing, with the at least one processor, during the boot process for the first SoC, a compute resource of the first SoC (Ditty par. 235, BPMP (703) is part of SoC boot sequence (see FIG. 17, with two advanced SoC [i.e., one of them may be the first SoC]), and used to handle boot functions for resources on the SoC [ex. system states, clock and voltage management]; and par. 235, BPMP is a dedicated processor and subsystem to handle boot and power management functions and related security enforcement (of the SoC, see par. 191)), the compute resource of the first SoC comprising at least one of an input/output functionality (Ditty FIG. 9, peripheral bus 710 and connected peripherals), a processing unit (Ditty FIG. 9, CPUs in CPU Complex 200), or memory (Ditty FIG. 9, L3 cache 500 and SysRAM) [Note: FIG. 9 Is a component diagram of an example advanced SoC, see par. 191];
identifying, with the at least one processor, […], a node configuration based on the node configuration indicating the first SoC, the node configuration defining a node, wherein the node configuration indicates a dynamic mapping of the first SoC and at least one second SoC of the set of SoCs to the node to share access to the compute resource of the first SoC (Ditty par. 292, any number of SoCs may be combined [i.e., node configuration is SoCs being combined]; and Ditty par. 293, stating multiple sets of plural SoCs are in the system [i.e., a first SoC and a second SoC], and par. 282, advanced SoCs 100 when configured for C2C communication function together as if they were a single unified system [or separately, see par. 283 and 285]; and Ditty par. 449-450, boot configuration table used in a trusted boot of the SOC; and Ditty par. 368, the mapping for virtual CPU operations to actual CPUs on the SoCs may be stored in a partition configuration table and controlled dynamically), […];
[Note: The operation is dynamic because Ditty discloses that a preferred embodiment of the system contains a plurality of the Advanced SoCs (par. 279), which are connected to a microcontroller (MCU) that operates as a master controller for the system (par. 281) and control operations (e.g., fault monitoring, communications) for the SoCs (par. 298). The SoCs may operate as a node receiving the same inputs and performing the same operations, but they may also operate as separate nodes using different inputs to perform independent calculations (par. 283 and 285) (i.e., dynamic mapping, as node mapping can change based on needs of the system).]
sharing, during the boot process for the first SoC, access to the compute resource of the first SoC with the at least one second SoC of the set of SoCs in response to identifying the node configuration (Ditty par. 294, memory is shared between SOCs due to hardware “all of the memory systems could be shared between the SOCs 2002” [i.e., during boot]; Ditty FIG. 20, depicting shared resources between SoCs (e.g., memory 2008, GPU 2006), […];
Ditty does not explicitly disclose:
identifying, with the at least one processor, during the boot process for the first SoC, a node configuration based on the node configuration indicating the first SoC, the node configuration defining a node, wherein the node configuration indicates a dynamic mapping of the first SoC and at least one second SoC of the set of SoCs to the node to share access to the compute resource of the first SoC, wherein the dynamic mapping of the first SoC and the at least one second SoC to the node to share access to the compute resource of the first SoC is configurable based on input received via a user computing device; and
wherein access to the compute resource of the first SoC is not shared with a third SoC of the set of SoCs based on the node configuration.
In the analogous art of provisioning a pool of SOCs for processing a workload (Hira par. 4), Hira teaches during the boot process:
identifying, with the at least one processor, during the boot process for the first SoC, a node configuration based on the node configuration indicating the first SoC, the node configuration defining a node, wherein the node configuration indicates a dynamic mapping of the first SoC and at least one second SoC of the set of SoCs to the node to share access to the compute resource of the first SoC (Hira par. 28, a plurality of SOCs residing in a pooled hardware “sub-cloud” of the platform [i.e., a node]; Hira FIG. 4 and par. 28-29, powering up [i.e., booting] SOCs in response to a large workload [i.e., dynamically configuring a node, also see par. 31], and share resources to process the workload);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Ditty and Hira before them, before the effective filing date of the claimed invention, to combine Ditty’s method of initializing SoC computing nodes during boot with Hira’s dynamic node mapping during SoC boot, the motivation being to adjust the capabilities of each SoC as needed for the current workload to improve efficiency (Hira par. 29 and 94).
Ditty in view of Hira does not explicitly teach:
wherein the dynamic mapping of the first SoC and the at least one second SoC to the node to share access to the compute resource of the first SoC is configurable based on input received via a user computing device;
wherein access to the compute resource of the first SoC is not shared with a third SoC of the set of SoCs based on the node configuration;
In the analogous art of provisioning computing resources of SOCs for processing a workload (Javre par. 3), Javre teaches:
wherein the dynamic mapping of the first [processor] and the at least one second [processor] to the node to share access to the compute resource of the first [processor] is configurable based on input received via a user computing device (Javre FIG. 5 and par. 58, based upon user inputs 520 specifies domains [i.e., nodes], e.g., which processors are included in each respective domains, the operating system to be executed by each processor, peripherals and/or memory to be available to each processor in each domain [i.e., node configuration]; and par. 21, a software developer [i.e., user] may utilize the domain creation tool to modify one or more of the different domains);
wherein access to the compute resource of the first [processor] is not shared with a third [processor] of the set of [processors] based on the node configuration (Javre par. 58, hardware description file specifies which peripherals and/or memory to be available to each processor in each domain [i.e., each domain may specify access or inaccessibility of compute resources, node configuration in file states whether resources are shared]);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Ditty, Hira, and Javre before them, before the effective filing date of the claimed invention, to combine Ditty and Hira’s method of using configuration files for allocating resources to a group of SoCs, with providing the configuration files by a user as taught by Javre, the motivation being to provide improved control over the allocation of resources (Javre par. 58 and 2).
Regarding Claim 2, Ditty in view of Hira and Javre disclose the method of claim 1, further comprising accessing startup code from a memory of the first SoC, wherein initializing the boot process for the first SoC is based on the startup code (Ditty par. 449, BootROM stage in table states to authenticate and execute Boot Loader [Boot Loader is startup code, code is accessed in ROM i.e., from a read-only memory]).
Regarding Claim 3, Ditty in view of Hira and Javre disclose the method of claim 2, wherein the memory of the first SoC comprises read-only memory (Ditty par. 235, DPMP runs after the boot ROM and boot-loader have finished [therefore SoC contains read-only memory]).
Regarding Claim 4, Ditty in view of Hira and Javre disclose the method of claim 1, further comprising:
identifying, during the boot process for the first SoC, using the node configuration, the at least one additional second SoC of the set of SoCs (Hira par. 79, SoCs 422-428 may be allocated/deallocated by the primary SoC 440 for executing workloads in response to detected events/data/signals, which would require identifying the SoC to boot); and
determining, during the boot process for the first SoC, that the first SoC and the at least one second additional SoC of the set of SoCs correspond to the node based on the node configuration (Hira par. 89, SoCs 422-428 power up based on workload and to offload work from primary SoC 440 [i.e. overload/underload criteria], therefore function as a compute node; [adding a SoC to the node requires determining the SoC is needed by analytics monitor 450 (see par. 88)]), wherein sharing access to the compute resource of the first SoC with the at least one second SoC of the set of SoCs is based on determining that the first SoC and the at least one second SoC of the set of SoCs correspond to the node (Hira par. 28, a plurality of SOCs residing in a pooled hardware “sub-cloud” of the platform [i.e., a node]; and Hira par. 83, shared memory 470 [i.e., shared resource] provides a central data store to ensure data coherency in the event that a workload is distributed across multiple SOCs).
Regarding Claim 5, Ditty in view of Hira and Javre disclose the method of claim 1, wherein the boot process for the first SoC is based on a boot image (Ditty par. 449, boot comprises Boot Configuration Table and Boot Loader [which would allow the system to boot and is therefore a boot image]), the method further comprising loading and authenticating, during the boot process for the first SoC, the boot image (Ditty par. 449, BCT and boot loader are authenticated and loaded [bootloader is for the SoC, see par. 448]).
Regarding Claim 6, Ditty in view of Hira and Javre disclose the method of claim 1, wherein the compute resource of the first SoC further comprises at least one of a central processing unit (Ditty Figure 9, CPUs in CPU Complex 200), a cache (Ditty Figure 9, L3 cache 500), random-access memory (Ditty Figure 9, SysRAM; or Hira FIG. 4, shared memory 470), or an input/output device (Ditty Figure 9, peripheral bus 710 and connected peripherals).
Regarding Claim 7, Ditty in view of Hira and Javre disclose the method of claim 1, wherein the compute resource of the first SoC is a physical compute resource (Ditty Figure 8, showing processing architecture of system in figure 9).
Regarding Claim 8, Ditty in view of Hira and Javre disclose the method of claim 1, further comprising training, during the boot process for the first SoC, the at least one of the input/output functionality, the processing unit, or the memory to perform an operation (Hira par. 95, shared memory 470 allows the primary SOC 440 and powered-up SOCs 422-428 to share the state of the workload; and par. 93, shared memory 470 stores details of the program stack for each SoC’s portion of the workload; also see par. 93, when the SOCs 422-428 power-up they have a boot vector for the program stack [i.e. during boot the memory is trained to perform the operation]).
Regarding Claim 9, Ditty in view of Hira and Javre disclose the method of claim 1, further comprising initializing, during the boot process for the first SoC, an isolated execution environment manager (Hira FIG. 4 and par. 82, analytics module 450 [i.e., isolated execution environment manager] monitors events, signals, patterns of events/signals for platform 410 [i.e., isolated execution environment]), wherein the isolated execution environment manager instantiates an isolated execution environment using the first SoC (Hira par. 82, analytics module 450 manages power states for SoCs in the environment [i.e., instantiates the execution environment]).
Regarding Claim 10, Ditty in view of Hira and Javre disclose the method of claim 1, further comprising, subsequent to sharing access to the compute resource of the first SoC with the at least one second SoC of the set of SoCs, booting, during the boot process for the first SoC, a kernel (Ditty par. 383, states hypervisor is held to a higher standard than operating system kernels, implying the OS starts kernels during boot; [In the secure boot process for the SoC (par. 449), the first step is loading boot configuration tables that would contain node configuration, and the SoCs share resources based on the node configuration (see fig. 20), therefore booting a kernel would be subsequent to sharing access to compute resource]).
Regarding Claim 11, Ditty in view of Hira and Javre disclose the method of claim 1, wherein the node configuration indicates a multi-SoC architecture (Ditty par. 298, SOCs 2002 communicate and interact with one or more microcontroller units (MCUs) 2003 [also see FIG. 20]), and wherein the node configuration is associated with an author of the multi-SoC architecture (Javre FIG. 5 and par. 58, based upon user inputs 520 [i.e., author] specifies domains [i.e., nodes], e.g., which processors are included in each respective domains, the operating system to be executed by each processor, peripherals and/or memory to be available to each processor in each domain).
Regarding Claim 12, Ditty in view of Hira and Javre disclose the method of claim 1, further comprising obtaining, during the boot process for the first SoC, the node configuration from a memory of the first SoC (Javre FIG. 1 and par. 26, hardware description file [i.e., node configuration] is located in memory 110 for a SoC; and par. 77, first stage boot loader [i.e., during boot] includes the configuration data generated for each of the domains created [i.e., node configuration]), wherein the dynamic mapping of the first SoC and the at least one second SoC to the node to share access to the compute resource of the first SoC is defined by the user computing device and stored in the memory of the first SoC (Javre par. 21 and 140, the system is capable of modifying properties of the domain [i.e., dynamic mapping] using the hardware description file [which is stored in memory 110, see par. 26]; and Javre FIG. 5 and par. 58, hardware description file based upon user inputs 520 specifies domains [i.e., nodes], e.g., which processors are included in each respective domains, the operating system to be executed by each processor, peripherals and/or memory to be available to each processor in each domain).
Regarding Claim 13, Ditty in view of Hira and Javre disclose the method of claim 1, further comprising obtaining, during the boot process for the first SoC, the node configuration from a memory of the set of SoCs (Hira Figure 4 and par. 93, when the SOCs 422-428 power-up they have a boot vector for the program stack, which contains details of what workload the powered-up SOC should operate on [the node configuration, which includes the SoCs working together on the compute task as per instant app. par. 39], which is a predetermined section of the program stack stored in the shared memory 470), wherein the memory of the set of SoCs is coupled to and in communication with the set of SoCs (Hira Figure 4, shared memory 470 with buses to each SoC 422-428 and 440).
Regarding Claim 14, Ditty in view of Hira and Javre disclose the method of claim 1, wherein the first SoC and the at least one second SoC of the set of SoCs operate in a multiprocessing mode based on sharing access to the compute resource of the first SoC (Ditty Fig 20 and par. 292 and 294, SoCs are operating in multi-processor mode, and some or all of the memory systems are shared between the SOCs 2002), wherein sharing access to the compute resource of the first SoC is based on the input received via the user computing device (Javre FIG. 5 and par. 58, based upon user inputs 520 specifies domains [i.e., nodes], e.g., which processors are included in each respective domains, the operating system to be executed by each processor, peripherals and/or memory to be available to each processor in each domain; also see par. 21, a software developer [i.e., user] may utilize the domain creation tool to modify one or more of the different domains).
Regarding Claim 15, Ditty in view of Hira and Javre disclose the method of claim 1, wherein further comprising assigning a function to the first SoC based on execution of the boot process for the first SoC (Hira par. 85, the primary SOC 440 is configured by the host system 405 by installing an operating system image and application for use in processing the particular workload [the function is assigned during boot based on the OS image provisioned]; and Hira par. 94, SOCs 422-428 can be configured upon with a system image upon boot depending on the functionality needed).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Ditty and Hira before them, before the effective filing date of the claimed invention, to combine Ditty’s method of combining SoCs into compute nodes with specific functions with Hira’s system image provisioning, the motivation being to adjust the capabilities of each SoC as needed for the current workload (Hira par. 94).
Regarding Claim 16, Ditty in view of Hira and Javre disclose the method of claim 1, further comprising:
assigning a first function to the first SoC based on execution of the boot process for the first SoC (Hira par. 85, the primary SoC receives a workload and is provisioned with a system image for preforming the task); and
assigning a second function to the at least one second SoC of the set of SoCs (Hira par. 94, SOCs 422-428 can be configured with a system image upon boot depending on the functionality needed), wherein the first SoC utilizes the compute resource of the first SoC for execution of the first function and the at least one second SoC of the set of SoCs utilizes the compute resource of the first SoC for execution of the second function (Hira par. 83 and par. 95, sharing compute resources among each of the SoCs working on a task).
Regarding Claim 17, Ditty in view of Hira and Javre disclose the method of claim 1, wherein a third SoC of the set of SoCs does not correspond to the node, wherein access to the compute resource of the first SoC is not shared with the third SoC of the set of SoCs based on the third SoC of the set of SoCs not corresponding to the node (Ditty par. 282, the Advanced SoCs 100 are capable of Chip-to-Chip (“C2C”) communication and may operate as if it were a single unified system [the alternative being each SoC operating independently]; or Hira FIG. 4 and par. 99, SOCs in platform 410 share compute resources via shared memory to perform the processing of the workload [i.e., SoCs not operating as part of the node do not share the resource]; or Javre par. 58, hardware description file specifies which peripherals and/or memory to be available to each processor in each domain [i.e., each domain may specify access or inaccessibility of compute resources, node configuration in file states whether resources are shared]).
Regarding Claim 18, Ditty in view of Hira and Javre disclose the method of claim 1, further comprising booting the first SoC based on initializing the boot process for the first SoC (Ditty par. 235, boot process for the SoC requires initializing the boot ROM and boot-loader).
Regarding Claim 19, Ditty discloses a system (Ditty FIG. 19, platform architecture (900)), comprising:
at least one processor (Ditty FIG. 9, component diagram of an example advanced SoC showing CPU Complex 200), and
at least one non-transitory storage media storing instructions (Ditty par. 295, memory systems 2004 at least in part constitute non-transitory memory that store program instructions the associated SOC 2002 executes to perform tasks);
The remaining limitations of claim 19 are similar in scope to claim 1 as addressed above and are thus rejected under the same rationale.
Regarding Claim 20, the claim is similar in scope to claim 19 as addressed above and is thus rejected under the same rationale.
Regarding Claim 21, Ditty in view of Hira and Javre disclose the method of claim 1, wherein the node configuration is configurable from a first node configuration to a second node configuration without physical reconfiguration of the set of SoCs (Hira par. 79, SoCs 422-428 may be allocated/deallocated by the primary SoC 440 for executing workloads in response to detected events/data/signals [i.e., change node configuration]; or Javre par. 21, a software developer [i.e., user] may utilize the domain creation tool to modify one or more of the different domains [i.e., nodes]; or Javre par. 58, hardware description file specifies which peripherals and/or memory to be available to each processor in each domain).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COLE JIAWEI WENTZEL whose telephone number is (703) 756-4762. The examiner can normally be reached 9:30am-5:30pm ET (Mon-Fri).
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, Andrew Jung can be reached on (571) 270-3779. 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.
/C.J.W./Examiner, Art Unit 2175
/ANDREW J JUNG/Supervisory Patent Examiner, Art Unit 2175