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 .
DETAILED ACTION
1. This Office Action is in response to the application filed on 03/27/2024. Claims 1-20 are pending in this application. Claims 1, 17 and 19 are independent claims.
Claim Rejections - 35 USC § 103
2. 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.
3. 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.
4. Claims 1-4, 6-8 and 12-18 are rejected under 35 U.S.C. 103 as being unpatentable over Mueller (US PGPub 20230132095), in view of Borzycki (US Patent 9189645), and further in view of Kisley (US Patent 7610348).
As per Claim 1, Mueller teaches of an Information Handling System (IHS), comprising: a controller, wherein the controller comprises firmware that, upon execution by a processing core, causes the processing core to instantiate an orchestrator; and (Fig. 2, par 14, Information handling systems (IHSS) such as, for example, laptop/notebook computing devices, desktop computing devices, tablet computing devices, mobile phones, or other endpoint computing devices known in the art as user equipment devices (UEs) [nodes], often utilize wireless networks in order to exchange data via a plurality of remote cloud networks forming the internet. Par 29, More specifically, the information handling system 100 may orchestrate execution of a plurality of computing nodes, pods, clusters, or containers capable of performing computing tasks individually, or in combination with one another. Par 36, The information handling system 100 may include a processor 102 such as a central processing unit (CPU), control logic or some combination of the same. Par 47, the methods described herein may be implemented by firmware or software programs executable by a controller or a processor system.)
Mueller does not specifically teach, however Borzycki teaches of an Information Handling System (IHS), comprising: a controller, wherein the controller comprises firmware that, upon execution by a processing core, causes the processing core to instantiate an orchestrator; and (Col 22, lines 19-22, An application that has been wrapped using the software development kit 584 may then be made available to the mobile device 502 by populating it in the application store 578 using the application controller 574. Col 35, lines 23-29, Other aspects described herein provide the ability for users to customize orchestration by providing a learning facility, a question and answer style interface and a traditional scripting approach. The orchestration software may adapt to how users interact with the system, and adjust rules based on user behavior. Thus, the system may learn new interactions and rules, based upon the observed behavior of a user of the system. Col 99, lines 57-66, In general, an orchestration framework may be configured to connect computing devices and manage the interaction between those computing devices such that computing activities are coordinated across the interconnected computing devices. The orchestration framework may maintain and apply a management policy that governs the interaction between the computing devices. The management policy may indicate the contexts in which various interactions are permitted and the contexts in which various interactions are not permitted.)
a plurality of devices coupled to the controller, wherein each device comprises firmware that, upon execution by a corresponding processing core, causes the corresponding processing core to instantiate a node as part of a firmware framework, and (Col 3, lines 40-47, Computing devices may be interconnected through an orchestration framework that coordinates operation of a computing activity across multiple computing devices of the plurality of computing devices. A request to transfer content from a first application at a first computing device to a second application at a second computing device may be received, and a determination may be made of whether to initiate transfer of the content. Fig. 51, Col 111, lines 37-61, The enterprise application store may deliver applications to the computing devices interconnected via the orchestration framework as noted above. The orchestration framework (Information Handling System) may also automatically identify and provide applications [firmware] to computing devices [nodes] in order to enable those computing devices to perform at least a portion of a coordinated computing activity.)
wherein the orchestrator is configured to distribute a firmware module to a given node in response to a determination that the given node requires the firmware module to provide a capability (Col 111, line 65-Col 112, line 12, When a computing device (an originating computing device) submits a request to perform at least a portion of a computing activity at another computing device (a destination computing device), the orchestration framework may determine whether the destination computing device includes an application that is capable of performing the computing activity. If the destination computing device does not include an application that is capable of performing the computing activity, then the application store may identify an application available from the application store that is capable of performing the computing activity and initiate download of the application to the destination computing device. The destination computing device may thus utilize the received application to perform at least a portion of the computing activity.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add an Information Handling System (IHS), comprising: a controller, wherein the controller comprises firmware that, upon execution by a processing core, causes the processing core to instantiate an orchestrator; and a plurality of devices coupled to the controller, wherein each device comprises firmware that, upon execution by a corresponding processing core, causes the corresponding processing core to instantiate a node as part of a firmware framework, and wherein the orchestrator is configured to distribute a firmware module to a given node in response to a determination that the given node requires the firmware module to provide a capability, as conceptually seen from the teaching of Borzycki, into that of Mueller because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
Neither Mueller nor Borzycki specifically teaches, however Kisley teaches of wherein the orchestrator is configured to distribute a firmware module to a given node … without any involvement by any Operating System (OS) of the IHS. (Col 9, line 64-Col 10, line 2, The second capability is direct application access, wherein application processes can queue data transfer operations directly to RDMA compliant network interfaces without operating system involvement. DAFS, thus, allows clusters of application servers to efficiently share data while avoiding the overhead imposed by general-purpose operating systems. Col 13, lines 48-51, This achieves storage virtualization at the metadata server 310 while allowing the client 314 data access at data server 320 connection speed, and avoiding the problems inherent with giving data control to the client OS. Claim 7, providing direct memory-to-memory transfer and direct application access for queuing data transfer operations directly to the host without involvement of the host operating system.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein the orchestrator is configured to distribute a firmware module to a given node … without any involvement by any Operating System (OS) of the IHS, as conceptually seen from the teaching of Kisley, into that of Mueller and Borzycki because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 2, Mueller further teaches of the IHS of claim 1, wherein the controller comprises an Embedded Controller (EC) or Baseband Management Controller (BMC). (Par 44, The information handling system 100 may further include a power management unit (PMU) 114 (a.k.a. a power supply unit (PSU)). The PMU 114 may manage the power provided to the components of the information handling system 100 such as the processor 102 such as a CPU or embedded controller, a cooling system, one or more drive units 116, a graphical processing unit (GPU), a video/graphic display device or other input/output devices 112, and other components that may require power when a power button has been actuated by a user. In an embodiment, the PMU 114 may monitor power levels and be electrically coupled to the information handling system 100 to provide this power and coupled to bus 108 to provide or receive data or instructions.)
As per Claim 3, Mueller further teaches of the IHS of claim 1, wherein the plurality of devices comprises at least one of: a sensor, a sensor hub, a Central Processing Unit (CPU), a Graphical Processing Unit (GPU), an audio Digital Signal Processor (aDSP), a Neural Processing Unit (NPU), a Tensor Processing Unit (TSU), a Neural Network Processor (NNP), an Intelligence Processing Unit (IPU), an Image Signal Processor (ISP), or a Video Processing Unit (VPU), a camera controller, an audio controller, a memory, a Universal Serial Bus (USB) device, a Peripheral Component Interconnect express (PCIe) device, or a Trusted Platform Module (TPM). (Par 28, The information handling system can include memory (volatile (e.g., random-access memory, etc.), nonvolatile (read-only memory, flash memory etc.) or any combination thereof), one or more processing resources, such as a central processing unit (CPU), a graphics processing unit (GPU), hardware or software control logic, or any combination thereof.)
As per Claim 4. Mueller further teaches of the IHS of claim 1, wherein at least one of the plurality of devices is coupled to the controller via at least one of: a Systems-on-Chip (SoC) interconnect, a Peripheral Component Interconnect Express (PCIe) bus, or a Universal Serial Bus (USB) port. (Par 53, When referred to as a “system”, a “device,” a “module,” a “controller,” or the like, the embodiments described herein can be configured as hardware. For example, a portion of an information handling system device may be hardware such as, for example, an integrated circuit (such as an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a structured ASIC, or a device embedded on a larger chip), a card (such as a Peripheral Component Interface (PCI) card, a PCI-express card, a Personal Computer Memory Card International Association (PCMCIA) card, or other such expansion card), or a system (such as a motherboard, a system-on-a-chip (SoC), or a stand-alone device).)
As per Claim 6, neither Mueller nor Kisley specifically teaches, however Borzycki teaches of the IHS of claim 1, wherein the orchestrator is configured to distribute the firmware module, at least in part, in response to a request or command from another node to use the capability. (Col 3, lines 40-50, Computing devices may be interconnected through an orchestration framework that coordinates operation of a computing activity across multiple computing devices of the plurality of computing devices. A request to transfer content from a first application at a first computing device to a second application at a second computing device may be received, and a determination may be made of whether to initiate transfer of the content. The determination may be based on the operation modes of the applications, which may include a managed operation mode and an unmanaged operation mode. Col 93, lines 15-26, A request for an application may be received. For example, the enterprise application store may receive a request for a software application. For instance, the enterprise application store may receive a request from a computing device to download and/or otherwise provide a particular application that is available in the enterprise application store to the computing device. Such a request may, for instance, be received based on a user of the computing device (which may, e.g., be a mobile device, such as a smart phone, tablet computer, or other mobile computing device) selecting and/or requesting to download a particular application from the enterprise application store using the enterprise application store interface.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add distributing the firmware module, at least in part, in response to a request or command from another node to use the capability, as conceptually seen from the teaching of Borzycki, into that of Mueller and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 7, neither Mueller nor Kisley specifically teaches, however Borzycki teaches of the IHS of claim 1, wherein the firmware module, upon execution by the processing core, enables the given node to expose the capability to the firmware framework. (Col 112, lines 45-48, The enterprise application store may also be configured to recommend applications for delivery to computing devices based on the type of computing device or, additionally or alternatively, the capabilities of the computing device. Col 113, lines 17-25, The orchestration framework may also dynamically determine a set of computing devices to present as a list of available for selection as a destination computing device. The orchestration framework may configure the list based on the capabilities of potential destination computing device or, additionally or alternatively, based on the management policies indicating whether the potential destination computing devices are permitted to perform at least a portion of the computing activity.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the firmware module, upon execution by the processing core, enables the given node to expose the capability to the firmware framework, as conceptually seen from the teaching of Borzycki, into that of Mueller and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 8, neither Mueller nor Kisley specifically teaches, however Borzycki teaches of the IHS of claim 7, wherein the firmware module, upon execution by the processing core, enables the given node to expose an interface corresponding to the exposed capability to the firmware framework.
(Col 16, line 52-Col 17, line 4, For example, the management server 410 may provide a set of APIs and/or one or more cloud operator console applications (e.g., web-based or standalone applications) with user interfaces to allow cloud operators to manage the cloud resources, configure the virtualization layer, manage customer accounts, and perform other cloud administration tasks. The management server 410 also may include a set of APIs and/or one or more customer console applications with user interfaces configured to receive cloud computing requests from end users via client computers 411-414, for example, requests to create, modify, or destroy virtual machines within the cloud. Client computers 411-414 may connect to management server 410 via the Internet or other communication network, and may request access to one or more of the computing resources managed by management server 410. In response to client requests, the management server 410 may include a resource manager configured to select and provision physical resources in the hardware layer of the cloud system based on the client requests. Col 37, lines 27-33, Moreover, the list of destinations may be context-sensitive such that the destinations included in the list depend on various factors. In one example implementation, the multi-device client may dynamically filter the list of destinations based on the capabilities of the potential device destinations. In this regard, the multi-device client may be aware of the capabilities of the various devices.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the firmware module, upon execution by the processing core, enables the given node to expose an interface corresponding to the exposed capability to the firmware framework, as conceptually seen from the teaching of Borzycki, into that of Mueller and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 12, neither Mueller nor Kisley specifically teaches, however Borzycki teaches of the IHS of claim 1, wherein the orchestrator is configured to distribute the firmware module, at least in part, in response to contextual information. (Col 112, line 62- Col 113, line 16, Before providing an application to a destination computing device, the orchestration framework may determine whether the destination computing device is permitted to perform the computing activity or receive the application capable of performing the computing activity. The orchestration framework may make the determination based on one or more management policies maintained by the application store. The management policy may indicate whether the computing device is permitted to perform the computing activity or receive the application based on the type of the computing device or a user associated with the computing device (e.g., a user role associated with the user). If the management policy indicates that the computing device is permitted to receive the application and is permitted to perform at least a portion of the computing activity, then the orchestration framework may initiate download of the application to the destination computing device. If, however, the destination computing device is not permitted to receive the application or not permitted to perform at least a portion of the computing activity, then the orchestration framework may not initiate (block or otherwise prevent) the download of the application to the destination computing device.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add distributing the firmware module, at least in part, in response to contextual information, as conceptually seen from the teaching of Borzycki, into that of Mueller and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 13, neither Mueller nor Kisley specifically teaches, however Borzycki teaches of the IHS of claim 12, wherein the contextual information comprises an indication of at least one of: a location of the IHS, a network bandwidth, the given node’s utilization, or the given node’s power state. (Col 102, line56-Col 103, lines 8, In this example context, the management policy may include rules indicating that computing devices determined to be at a common physical location are permitted to interact while computing devices that are not located at the common physical location are not permitted to interact. The management criteria may utilize the location of a computing device in combination with other criteria described above. For example, the management policy may indicate that even though a device is not located at the same location as the other devices connected to the orchestration framework, the computing device is permitted to interact with the other devices if the computing device is associated with a specific user or a user have a specific user role. Col 37, lines 17-33, The cloud service may also employ one or more rule sets to determine which device should receive the selected file. Users may modify the rule sets according to their preferences, and the rules may consider various characteristics associated with the users (e.g., user role, location, etc.), the devices (e.g., device type, etc.) [the given node’s utilization], the selected file, and combinations of such. In one example implementation, the multi-device client may dynamically filter the list of destinations based on the capabilities of the potential device destinations. In this regard, the multi-device client may be aware of the capabilities of the various devices. Col 45, lines 34-43, The method of FIG. 16 may proceed from step 1604 to step 1606, where a context for the selected applications is determined based on one or more operational parameters of the device executing the selected application. For example, a context may be based on an account to be accessed by the application, a location of the mobile device or a network connectivity status of the mobile device executing the application, or based on any other operational parameter. The methods of FIGS. 17-21, further described below, illustrate various embodiments where example contexts are described.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add a location of the IHS, a network bandwidth, the given node’s utilization, or the given node’s power state, as conceptually seen from the teaching of Borzycki, into that of Mueller and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 14, neither Mueller nor Kisley specifically teaches, however Borzycki teaches of the IHS of claim 1, wherein the orchestrator is configured to distribute the firmware module, at least in part, in response to a determination that the given node cannot provide the capability without the firmware module. (Col 113, lines 1-25, The management policy may indicate whether the computing device is permitted to perform the computing activity or receive the application based on the type of the computing device or a user associated with the computing device (e.g., a user role associated with the user). If the management policy indicates that the computing device is permitted to receive the application and is permitted to perform at least a portion of the computing activity, then the orchestration framework may initiate download of the application to the destination computing device. If, however, the destination computing device is not permitted to receive the application or not permitted to perform at least a portion of the computing activity, then the orchestration framework may not initiate (block or otherwise prevent) the download of the application to the destination computing device. The orchestration framework may configure the list based on the capabilities of potential destination computing device or, additionally or alternatively, based on the management policies indicating whether the potential destination computing devices are permitted to perform at least a portion of the computing activity.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add distributing the firmware module, at least in part, in response to a determination that the given node cannot provide the capability without the firmware module, as conceptually seen from the teaching of Borzycki, into that of Mueller and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 15, neither Mueller nor Kisley specifically teaches, however Borzycki teaches of the IHS of claim 1, wherein to determine that the given node cannot provide the capability, the orchestrator is configured to at least one of: (i) compare a current firmware version of the given node with a latest firmware version of the given node; or (ii) evaluate one or more error messages in response to a request for the capability by another node. (Col 94, lines 43-49, In some embodiments, the enterprise application store may also automatically provide applications to a device. For example, in instances in which the enterprise application store determines that certain devices and/or users are in need of certain applications (e.g., based on download history information for various applications and users, based on update and/or version history information for various applications and/or users, based on information provided by on-device monitoring agents for various devices and/or users, etc.), the enterprise application store may automatically provide the one or more needed applications to a particular device and/or user responsive to a determination that the user or device needs the application (e.g., without the user of such a device manually selecting to download the particular needed applications). Additional aspects regarding the enterprise application store will be appreciated with the benefit of this disclosure. Col 68, lines 36-40, The client device 2805 may react with the appropriate error handling behavior, such as displaying a message to the user that an operation could not be completed because the client device 2805 does not support secured exchange of client private certificates. Col 20, lines 6-10, The device manager 524 may monitor the stabilized applications and utilize techniques for detecting and remedying problems that would result in a destabilized application if such techniques were not utilized to detect and remedy the problems. Col 93, lines 15-26, A request for an application may be received. For example, the enterprise application store may receive a request for a software application. For instance, the enterprise application store may receive a request from a computing device to download and/or otherwise provide a particular application that is available in the enterprise application store to the computing device. Such a request may, for instance, be received based on a user of the computing device (which may, e.g., be a mobile device, such as a smart phone, tablet computer, or other mobile computing device) selecting and/or requesting to download a particular application from the enterprise application store using the enterprise application store interface.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add (i) compare a current firmware version of the given node with a latest firmware version of the given node; or (ii) evaluate one or more error messages in response to a request for the capability by another node, as conceptually seen from the teaching of Borzycki, into that of Mueller and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 16, neither Mueller nor Kisley specifically teaches, however Borzycki teaches of the IHS of claim 1, wherein the orchestrator is configured to distribute a policy to the given node, and wherein the policy comprises a rule usable by the given node to expose the capability based on contextual information. (Col 112, line 62- Col 113, line 16, Before providing an application to a destination computing device, the orchestration framework may determine whether the destination computing device is permitted to perform the computing activity or receive the application capable of performing the computing activity. The orchestration framework may make the determination based on one or more management policies maintained by the application store. The management policy may indicate whether the computing device is permitted to perform the computing activity or receive the application based on the type of the computing device or a user associated with the computing device (e.g., a user role associated with the user). If the management policy indicates that the computing device is permitted to receive the application and is permitted to perform at least a portion of the computing activity, then the orchestration framework may initiate download of the application to the destination computing device. If, however, the destination computing device is not permitted to receive the application or not permitted to perform at least a portion of the computing activity, then the orchestration framework may not initiate (block or otherwise prevent) the download of the application to the destination computing device.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the policy comprises a rule usable by the given node to expose the capability based on contextual information, as conceptually seen from the teaching of Borzycki, into that of Mueller and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 17, Mueller teaches of a method, comprising: producing, via a controller within an Information Handling System (IHS), an orchestrator of a firmware framework; and (Par 24, FIG. 1 illustrates an information handling system 100 of a Management and Orchestration Module (MANO) 130 operating within an enterprise mobile network, or at edge computing for local management and orchestration or at a remote server for global management orchestration and testing according to embodiments described herein. Par 35, Information handling system 100 can include devices or modules [firmware] that embody one or more of the devices or execute instructions for the one or more systems and modules described above, and operates to perform one or more of the methods described above. Par 158, the methods described herein may be implemented by firmware or software programs executable by a controller such as embedded controller (EC) 636 or a processor 602 system.)
producing, via a plurality of devices coupled to the controller, a plurality of nodes, (Par 29, More specifically, the information handling system 100 may orchestrate execution of a plurality of computing nodes, pods, clusters, or containers capable of performing computing tasks individually, or in combination with one another. Par 33, As software containerization has gained popularity, containerized application deployment tools, such as container-orchestration systems for automating computing application deployment, scaling, and management across several nodes or several clusters have emerged.)
Mueller does not specifically teach, however Borzycki teaches of wherein the orchestrator is configured to distribute a firmware package to a given node in response to a determination that the given node requires the firmware package to provide a capability in the firmware framework, (Col 111, line 65-Col 112, line 12, When a computing device (an originating computing device) submits a request to perform at least a portion of a computing activity at another computing device (a destination computing device), the orchestration framework may determine whether the destination computing device includes an application that is capable of performing the computing activity. If the destination computing device does not include an application that is capable of performing the computing activity, then the application store may identify an application available from the application store that is capable of performing the computing activity and initiate download of the application to the destination computing device. The destination computing device may thus utilize the received application to perform at least a portion of the computing activity.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein the orchestrator is configured to distribute a firmware package to a given node in response to a determination that the given node requires the firmware package to provide a capability in the firmware framework, as conceptually seen from the teaching of Borzycki, into that of Mueller because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
Neither Mueller nor Borzycki specifically teaches, however Kisley teaches of wherein the orchestrator is configured to distribute a firmware package to a given node … without any involvement by any Operating System (OS) of the IHS. (Col 9, line 64-Col 10, line 2, The second capability is direct application access, wherein application processes can queue data transfer operations directly to RDMA compliant network interfaces without operating system involvement. DAFS, thus, allows clusters of application servers to efficiently share data while avoiding the overhead imposed by general-purpose operating systems. Col 13, lines 48-51, This achieves storage virtualization at the metadata server 310 while allowing the client 314 data access at data server 320 connection speed, and avoiding the problems inherent with giving data control to the client OS. Claim 7, providing direct memory-to-memory transfer and direct application access for queuing data transfer operations directly to the host without involvement of the host operating system.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein the orchestrator is configured to distribute a firmware package to a given node … without any involvement by any Operating System (OS) of the IHS, as conceptually seen from the teaching of Kisley, into that of Mueller and Borzycki because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 18, neither Mueller nor Kisley specifically teaches, however Borzycki teaches of the method of claim 17, further comprising distributing the firmware package, by the orchestrator, at least in part in response to a request or command from another node to use the capability. (Col 99, lines 57-66, In general, an orchestration framework may be configured to connect computing devices and manage the interaction between those computing devices such that computing activities are coordinated across the interconnected computing devices. The orchestration framework may maintain and apply a management policy that governs the interaction between the computing devices. The management policy may indicate the contexts in which various interactions are permitted and the contexts in which various interactions are not permitted. Col 93, lines 15-26, A request for an application may be received. For example, the enterprise application store may receive a request for a software application. For instance, the enterprise application store may receive a request from a computing device to download and/or otherwise provide a particular application that is available in the enterprise application store to the computing device. Such a request may, for instance, be received based on a user of the computing device (which may, e.g., be a mobile device, such as a smart phone, tablet computer, or other mobile computing device) selecting and/or requesting to download a particular application from the enterprise application store using the enterprise application store interface.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add distributing the firmware package, by the orchestrator, at least in part in response to a request or command from another node to use the capability, as conceptually seen from the teaching of Borzycki, into that of Mueller and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
5. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Mueller (US PGPub 20230132095), in view of Borzycki (US Patent 9189645), in view of Kisley (US Patent 7610348), and further in view of Biederman (US PGPub 20230109533).
As per Claim 5, none of Mueller, Borzycki and Kisley specifically teaches, however Biederman teaches of the IHS of claim 4, wherein the SoC interconnect comprises at least one of: an Advanced Microcontroller Bus Architecture (AMBA) bus, a QuickPath Interconnect (QPI) bus, or a HyperTransport (HT) bus. (Par 31, For example, as used herein the term “producer” and/or “producer device” refers to a network interface, a system-on-a-chip (SoC) interconnect for the connection and management of functional blocks on-chip (e.g., Advanced Microcontroller Bus Architecture (AMBA) network Interconnect or the like), a direct GPU-to-GPU interconnect (e.g., NVLink), the like, and/or combinations thereof. Similarly, as used herein the term “consumer” and/or “consumer device” refers to a device that performs operations on information transferred from the producer, such as a processor, the like, and/or combinations thereof.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add an Advanced Microcontroller Bus Architecture (AMBA) bus, a QuickPath Interconnect (QPI) bus, or a HyperTransport (HT) bus, as conceptually seen from the teaching of Biederman, into that of Mueller, Borzycki and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
6. Claims 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Mueller (US PGPub 20230132095), in view of Borzycki (US Patent 9189645), and further in view of Kisley (US Patent 7610348), and further in view of Luciani (US PGPub 20230246827)
As per Claim 9, none of Mueller, Borzycki and Kisley specifically teaches, however Luciani teaches of the IHS of claim 1, wherein the given node is configured to perform a verification of the firmware module prior to installing or executing the firmware module. (Par 29, Responsive to the power on or reset, the SRoT engine 151 validates and then loads an initial portion of the firmware 1 into the memory 143 of the secure enclave 140 so that this firmware portion is now trusted. The BMC 129 then releases the hold on the security processor 142 to allow the security processor 142 to boot and execute the loaded firmware instructions. By executing the firmware instructions, the security processor 142 may then validate the firmware image 179 corresponding to the BMC's management firmware stack and after validation, load the firmware image 179 into a memory 155 of the BMC 129.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add performing a verification of the firmware module prior to installing or executing the firmware module, as conceptually seen from the teaching of Luciani, into that of Mueller, Borzycki and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 10, none of Mueller, Borzycki and Kisley specifically teaches, however Luciani teaches of the IHS of claim 9, wherein the verification is based, at least in part, upon a digital certificate provided to the given node in connection with a discovery operation. (Par 9, The signature for a firmware image allows the BMC to validate the firmware image, i.e., determine that the owner of the asymmetric key provided the firmware image and determine that the firmware image has not been altered. Par 43, Responsive to this command, the BMC 129 validates the new firmware image. For example, as part of the validation, the BMC 129 may determine a hash value for the new firmware image, decrypt a signature provided with the new firmware image using the new owner firmware key, and compare the decrypted signature with the hash value to determine whether these two values match. In this way, the BMC 129 may determine that the new firmware image is owned by the purported new owner and has not been modified. Pursuant to decision block 216, the BMC 129 determines whether the new firmware image passes the validation. For example, passing the validation may refer to the decrypted signature and the hash value matching.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add that the verification is based, at least in part, upon a digital certificate provided to the given node in connection with a discovery operation, as conceptually seen from the teaching of Luciani, into that of Mueller, Borzycki and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 11, none of Mueller, Borzycki and Kisley specifically teaches, however Luciani teaches of the IHS of claim 1, wherein to install or execute the firmware module, the given node is configured to extract and initiate a secure boot loader from the firmware module. (Par 29, Responsive to the power on or reset, the SRoT engine 151 validates and then loads an initial portion of the firmware 1 into the memory 143 of the secure enclave 140 so that this firmware portion is now trusted. The BMC 129 then releases the hold on the security processor 142 to allow the security processor 142 to boot and execute the loaded firmware instructions. By executing the firmware instructions, the security processor 142 may then validate the firmware image 179 corresponding to the BMC's management firmware stack and after validation, load the firmware image 179 into a memory 155 of the BMC 129. The instructions of the management firmware stack may then be executed by the main processing core(s) 154 (when released from reset), which causes the main processing core(s) 154 to load additional portions of the firmware 170 and place the loaded portions into a memory 164. Access to the memory 164 may involve additional training and initialization steps (e.g., training and initialization steps set forth by the DDR specification). Those instructions may be executed from the validated portion of the BMC's firmware management stack in the memory 155. In accordance with example implementations, the secure enclave 140 may lock the memory 155 to prevent modification or tampering with the validated portion(s) stored in the memory 155. Therefore, in accordance with example implementations, the chain of trust may be extended from the BMC's SRoT to the firmware management stack that is executed by the BMC's main processing cores 154.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add extracting and initiating a secure boot loader from the firmware module, as conceptually seen from the teaching of Luciani, into that of Mueller, Borzycki and Kisley because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
7. Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mueller (US PGPub 20230132095), in view of Borzycki (US Patent 9189645),
As per Claim 19, Mueller teaches of an Embedded Controller (EC) integrated into or coupled to a heterogeneous computing platform of an Information Handling System (IHS), the EC comprising: a processing core distinct from any host processor of the heterogeneous computing platform; and
(Par 56, The UE pool 210 may include several different types of mobile devices, each with different networking capabilities. Par 55, Each of these enterprise mobile network infrastructure components (e.g., 231, 232, 233, 234, or 235) may utilize processors and memory of a Multi-Access Edge Computing Platform (MEC) 238, or other processing resources [distinct from a host processor] co-located at the enterprise RAN and core infrastructure 230 in order to execute their required processing of data frames or packets.)
a memory coupled to the processing core, the memory having firmware instructions stored thereon that, (Par 28, The information handling system can include memory (volatile (e.g., random-access memory, etc.), nonvolatile (read-only memory, flash memory etc.) or any combination thereof), one or more processing resources, such as a central processing unit (CPU), a graphics processing unit (GPU), hardware or software control logic, or any combination thereof.)
upon execution by the processing core, cause the EC to: (Par 158, In accordance with various embodiments of the present disclosure, the methods described herein may be implemented by firmware or software programs executable by a controller such as embedded controller (EC) 636 or a processor 602 system.)
Mueller does not specifically teach, however Borzycki teaches to produce an orchestrator as part of a firmware framework; and (Col 99, lines 57-66, In general, an orchestration framework may be configured to connect computing devices and manage the interaction between those computing devices such that computing activities are coordinated across the interconnected computing devices. The orchestration framework may maintain and apply a management policy that governs the interaction between the computing devices. The management policy may indicate the contexts in which various interactions are permitted and the contexts in which various interactions are not permitted.)
distribute a firmware package to a node of the firmware framework in response to a determination that the node requires the firmware package to provide a capability requested by another node. (Col 111, line 65-Col 112, line 12, When a computing device (an originating computing device) submits a request to perform at least a portion of a computing activity at another computing device (a destination computing device), the orchestration framework may determine whether the destination computing device includes an application that is capable of performing the computing activity. If the destination computing device does not include an application that is capable of performing the computing activity, then the application store may identify an application available from the application store that is capable of performing the computing activity and initiate download of the application to the destination computing device. Col 3, lines 40-50, A request to transfer content from a first application at a first computing device to a second application at a second computing device may be received, and a determination may be made of whether to initiate transfer of the content. The determination may be based on the operation modes of the applications, which may include a managed operation mode and an unmanaged operation mode. Col 93, lines 15-26, A request for an application may be received. For example, the enterprise application store may receive a request for a software application. For instance, the enterprise application store may receive a request from a computing device to download and/or otherwise provide a particular application that is available in the enterprise application store to the computing device. Such a request may, for instance, be received based on a user of the computing device (which may, e.g., be a mobile device, such as a smart phone, tablet computer, or other mobile computing device) selecting and/or requesting to download a particular application from the enterprise application store using the enterprise application store interface.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add producing an orchestrator as part of a firmware framework; and distribute a firmware package to a node of the firmware framework in response to a determination that the node requires the firmware package to provide a capability requested by another node, as conceptually seen from the teaching of Borzycki, into that of Mueller because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
As per Claim 20, Mueller does not specifically teach, however Borzycki teaches of the EC of claim 19, wherein the orchestrator is configured to distribute the firmware package, at least in part, in response to at least one of: a location of the IHS, a network bandwidth, the node’s utilization, the other node’s utilization, the node’s power state, or the other node’s power state. (Col 102, line56-Col 103, lines 8, In this example context, the management policy may include rules indicating that computing devices determined to be at a common physical location are permitted to interact while computing devices that are not located at the common physical location are not permitted to interact. The management criteria may utilize the location of a computing device in combination with other criteria described above. For example, the management policy may indicate that even though a device is not located at the same location as the other devices connected to the orchestration framework, the computing device is permitted to interact with the other devices if the computing device is associated with a specific user or a user have a specific user role. Col 37, lines 17-33, The cloud service may also employ one or more rule sets to determine which device should receive the selected file. Users may modify the rule sets according to their preferences, and the rules may consider various characteristics associated with the users (e.g., user role, location, etc.), the devices (e.g., device type, etc.) [the given node’s utilization], the selected file, and combinations of such. In one example implementation, the multi-device client may dynamically filter the list of destinations based on the capabilities of the potential device destinations. In this regard, the multi-device client may be aware of the capabilities of the various devices. Col 45, lines 34-43, The method of FIG. 16 may proceed from step 1604 to step 1606, where a context for the selected applications is determined based on one or more operational parameters of the device executing the selected application. For example, a context may be based on an account to be accessed by the application, a location of the mobile device or a network connectivity status of the mobile device executing the application, or based on any other operational parameter. The methods of FIGS. 17-21, further described below, illustrate various embodiments where example contexts are described.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add a location of the IHS, a network bandwidth, the node’s utilization, the other node’s utilization, the node’s power state, or the other node’s power state, as conceptually seen from the teaching of Borzycki, into that of Mueller because this modification can help offload tasks and manage resources and tasks performed by various devices using the orchestration framework based on their capabilities and device types.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAE UK JEON whose telephone number is (571)270-3649. The examiner can normally be reached 10am-6pm. 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, Chat Do can be reached at 571-272-3721. 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.
/JAE U JEON/Primary Examiner, Art Unit 2193
Prosecution Insights