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
This action is in response to the application filed on 2/20/2026.
Claims 1, 3-17, and 19-20 are pending. Claims 2 and 18 are cancelled.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-5, 7, 13, 15-17, 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ladkani et al. (US 20210141626 A1) hereinafter Ladkani in view of Rajagopalan et al. (US 20230153093 A1) hereinafter Rajagopalan in further view of Khatri (US 20190042755 A1).
Regarding claim 1, Ladkani discloses
Receiving, via an application programming interface (API) at the BMC (Ladkani Paragraph [0053] discloses BMC receiving an update command via the redfish protocol for out-of-band communication, where redfish an API).
by package management service of the BMC (Ladkani Paragraph [0035] and [0037] discloses an update agent of the BMC instructing the BMC to enter firmware update mode).
Wherein a storage of the BMC comprises a read-only partition storing base packages of a firmware image as a monolithic component that is not individually updatable, and a read-write partition storing update packages of the firmware image that are individually updatable at runtime without requiring a full firmware upgrade or a reboot of the BMC (Ladkani [0016] and [0018] discloses the BMC including a root file system stored in read-only partition, where the BMC’s firmware is treated as a monolithic binary blob, where an update needed for a particular service provided by the firmware requires updating the entire firmware. Further, Ladkani discloses the read-write partition that include independently updatable service modules that allows independent updates to the services that the BMC provides, thus an entire restart of the BMC is not necessary).
Determining, by a package management service of the BMC, whether a software package for the software component is one of the updatable packages allocated to the read-write partition or one of the base packages stored in the read-only partition (Ladkani [0006], [0016]-[0018] discloses storing the update firmware package into a plurality of read-write partitions, while root file systems are stored in the read-only partition)
When the software package is one of the base packages, relocating the software package to the read-only partition (Ladkani [0016] discloses root file systems is stored in the read-only partition consisting of the plurality of executable applications and their libraries).
Verifying, by a package security service of the BMC, authenticity and integrity of the software package (Ladkani [0039] discloses the update deployment agent may authenticate the update package written to the update partition prior to replacing the corresponding existing service module).
upon successful verification, unpacking the software package into a temporary path within the BMC to generate temporary files, creating folder paths within the read-write partition, stopping a service of the BMC associated with the software component, copying the temporary files from the temporary path to the folder paths within the read-write partition, deleting the temporary files from the temporary path, and restarting the service, without requiring the full firmware upgrade or the reboot of the BMC. (Ladkani [0036]-[0038] and [0066] discloses the BMC is set to a special firmware update mode, where the BMC enumerates a temporary update partition onto the host computing device, where the update partition is mounted and the update is unpacked onto the partition. Then the update partition is stored in the volatile memory via the write operation performed by the update deployment agent. After completion, the update agent unmounts the update partition from the computing device and may replace any existing service module in the corresponding RW partition, thus showing the temporary file being deleted every time a new update is added. Finally, the BMC restart the service associated with the updated service module, there by executing the new application and/or libraries or drivers included in the updated service module, where only the updated service is restarted and all other service remain unaffected).
Ladkani lacks explicitly
A package management request for managing a software component of the BMC;
When the software package is the updatable package, managing the software component according to the package
Rajagopalan teaches
A package management request for managing a software component of the BMC; (Rajagopalan [0049] discloses receiving a request from the update agent)
When the software package is the updatable package, managing the software component according to the package (Rajagopalan [0065] discloses after the user has either approved or disapproved deployment of the updates included in the catalog, the management console issues a request to deploy approved updates).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani to incorporate the teachings of Rajagopalan to “A package management request for managing a software component of the BMC;” and “When the software package is the updatable package, managing the software component according to the package” in order to have a dedicated system/component to manage incoming updates, thus making the BMC act more efficiently when handling update packages.
Ladkani in view of Rajagopalan lacks
Managing comprising: Obtaining the software package from a cloud storage
Khatri teaches
Managing comprising: Obtaining the software package from a cloud storage (Khatri paragraph [0016] discloses downloading the code from the host over the network, and the host may be part of a cloud-computing facility. Code is further described as being updates for installation).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan to incorporate the teachings of Khatri to “obtaining the software package for the software component from a cloud” in order to fetch needed software packages when available quickly and allowing for resources to be on demand.
Regarding claim 3, Rajagopalan further teaches
wherein managing the software component is updating or installing the software component (Rajagopalan Paragraph [0039] discloses add/remove applications and install software updates to the workspace).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani to incorporate the teachings of Rajagopalan to “wherein managing the software component is updating or installing the software component” in order allow the BMC to have the most update-to-date software version, thus improving the BMC’s overall effectiveness.
Regarding claim 4, it’s directed to a method having similar limitations cited in claim 1. Thus claim 4 is also rejected under the same rationale as cited in the rejection of claim 1 above.
Regarding claim 5, Ladkani teaches
The method of claim 4, further comprising verifying the authenticity and integrity of the software package using a package security service before performing the managing step (Ladkani paragraph [0039] discloses after receiving an update package, the update deployment agent may implement authentication techniques to determine a valid update package before replacing the corresponding existing service module).
Regarding claim 7, Rajagopalan further teaches
further comprising ascertaining dependencies for the software package, and managing the dependencies via the package management service during the managing step (Rajagopalan Paragraph [0046] discloses dependency checking features that will be encapsulated along with the software update to be downloaded and installed to a target).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani to incorporate the teachings of Rajagopalan to “further comprising ascertaining dependencies for the software package, and managing the dependencies via the package management service during the managing step” in order to ensure that the newly update software also has the necessary dependencies in order to run the software properly, avoiding potential malfunctions/errors of the BMC.
Regarding claim 13, Ladkani discloses
The method of claim 1, wherein the API is REDFISH compliant (Ladkani Paragraph [0046] discloses a BMC using protocols such as Redfish for out-of-band communication. Redfish protocol is inherently redfish compliant)
Regarding claim 15, Ladkani in view of Rajagopalan teach
The method of claim 1,
Ladkani in view of Rajagopalan fail to teach
wherein the software package is stored on a cloud storage, wherein the managing the software component includes checking if an update of the software package is available from the cloud storage
Khatri teaches
wherein the software package is stored on a cloud storage, wherein the managing the software component includes checking if an update of the software package is available from the cloud storage (Khatri paragraph [0019], discloses an update manager constantly scanning hardware and sending a message to the service processor. Similarly, the update manager receives messages from the service provider of the availability of code).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan to incorporate the teachings of Khatri to “wherein the software package is stored on a cloud storage, wherein the managing the software component includes checking if an update of the software package is available from the cloud storage” in order to remain up-to-date on new software/firmware needed on the BMC, ensuring a secure and efficient environment.
Regarding claim 16, Ladkani in view of Rajagopalan teach
The method of claim 15,
Ladkani in view of Rajagopalan fail to teach
further comprising:
when the update of the software package is available, automatically updating the software component on the BMC based on the update of the software package
Khatri teaches
when the update of the software package is available, automatically updating the software component on the BMC based on the update of the software package (Khatri paragraph [0016] discloses the update module having an advanced embedded system management tool for automated updates of system code. Khatri paragraph [0019] also discloses the update manager for checking code availability as state previously)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan to incorporate the teachings of Khatri to “when the update of the software package is available, automatically updating the software component on the BMC based on the update of the software package” in order to enhance management efficiency.
Regarding claim 17, it’s directed to an apparatus having similar limitations cited in claim 1. Thus claim 17 is also rejected under the same rationale as cited in the rejection of claim 1 above.
Regarding claim 19, it’s directed to an apparatus having similar limitations cited in claim 3. Thus claim 19 is also rejected under the same rationale as cited in the rejection of claim 3 above.
Regarding claim 20, it’s directed to an apparatus having similar limitations cited in claim 4. Thus claim 20 is also rejected under the same rationale as cited in the rejection of claim 4 above.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ladkani et al. (US 20210141626 A1) hereinafter Ladkani in view of Rajagopalan et al. (US 20230153093 A1) hereinafter Rajagopalan in further view of Khatri (US 20190042755 A1) in further view of Babayan (US 20240403018 A1).
Regarding claim 6, Ladkani in view of Rajagopalan in further view of Khatri teaches
The method of claim 5,
The combination lacks explicitly
wherein the verifying the step comprises checking digital signatures and hashes associated with the software packages
Babayan teaches
wherein the verifying the step comprises checking digital signatures and hashes associated with the software packages (Babayan paragraph [0095] discloses task staging going through various checks before performing the update. This Includes validating the downloaded update package to ensure authenticity and integrity by checking digital signatures, hash values, or other checksum mechanisms).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan in further view of Khatri to incorporate the teachings of Babayan to “wherein the verifying the step comprises checking digital signatures and hashes associated with the software packages” in order to ensure the package has not been tampered and is the intended software package for the BMC, thus preventing unauthorized or malicious code from being introduced.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ladkani et al. (US 20210141626 A1) hereinafter Ladkani in view of Rajagopalan et al. (US 20230153093 A1) hereinafter Rajagopalan in further view of Khatri (US 20190042755 A1) in further view of Fender (US 20210173621 A1).
Regarding claim 8, Ladkani in view of Rajagopalan in further view of Khatri teaches
The method of claim 7,
The combination lacks explicitly
wherein the managing the dependencies includes fetching any missing dependencies from a URL specified by the software package.
Fender teaches
wherein the managing the dependencies includes fetching any missing dependencies from a URL specified by the software package. (Fender paragraph [0091] discloses using a database management system (DBMS) resolves missing dependencies by dynamic linking. The DBMS may use a locator, such as an URL to retrieve the missing dependency from a codebase repository, where codebase is analogous with software package).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan in further view of Khatri to incorporate the teachings of Fender to “wherein the managing the dependencies includes fetching any missing dependencies from a URL specified by the software package” in order to automatically retrieve the necessary information (Fender [0089]).
Claim(s) 9 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ladkani et al. (US 20210141626 A1) hereinafter Ladkani in view of Rajagopalan et al. (US 20230153093 A1) hereinafter Rajagopalan in further view of Khatri (US 20190042755 A1) in further view of Offer (8347263 B1)
Regarding claim 9, Ladkani in view of Rajagopalan in further view of Khatri teaches
The method of claim 4,
The combination lacks explicitly
further comprising:
parsing metadata of the software package to determine dependency and license requirements.
Offer teaches
further comprising:
parsing metadata of the software package to determine dependency and license requirements. (Offer Col. 50, lines 50-66 discloses an installation parser to derive metadata from an installation package, where the package includes information such as the names of installation files, names and destinations of files to be installed, file path information, configuration option logic, feature logic, version information, operating system requirements/dependencies, hardware requirements/dependencies, registry keys, installation package dependencies, license information, etc.).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan in further view of Khatri to incorporate the teachings of Offer to “parsing metadata of the software package to determine dependency and license requirements” in order to ensure that no conflicts arise with the BMC during the package deployment and allowing for flexibility at the time of application is installed.
Regarding claim 10, Ladkani in view of Rajagopalan in further view of Khatri teaches
The method of claim 9,
The combination lacks explicitly
wherein the parsing the metadata includes determining installation paths and system resources required for the software component according to information encapsulated in the software package
Offer teaches
wherein the parsing the metadata includes determining installation paths and system resources required for the software component according to information encapsulated in the software package Offer Col. 50, lines 50-66 discloses parsing the metadata to determine name and destinations of files and file path information. Offer Col. 6 lines 29-51 discloses the parser is configured to parse received executable application and determine those resources required by the executable application).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan in further view of Khatri to incorporate the teachings of Offer to “wherein the parsing the metadata includes determining installation paths and system resources required for the software component according to information encapsulated in the software package” in order to aid runtime by not using components not required by the application that are being executed. This modification will allow for memory, storage, and other resources that would be consumed to be used in more efficient ways.
Claim(s) 11 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ladkani et al. (US 20210141626 A1) hereinafter Ladkani in view of Rajagopalan et al. (US 20230153093 A1) hereinafter Rajagopalan in further view of Khatri (US 20190042755 A1) in further view of Shivanna (US 20170315798 A1).
Regarding claim 11, Ladkani in view of Rajagopalan in further view of Khatri discloses
The method of claim 1,
The combination lacks explicitly
wherein the software component is third-party application, and the managing step includes deploying the third-party application in a segregated containerized environment within the BMC
Shivanna teaches
wherein the software component is third-party application, and the managing step includes deploying the third-party application in a segregated containerized environment within the BMC (Shivanna Paragraph [0017] discloses after receiving an update request, storing the update request along with the update parameters in a pre-defined memory location. Paragraph [0019] discloses the update manager may be provided with predefined access rights and privileges such that they utilize secure OS containers like Linux OS containers to run the OS service and isolate any firmware or software update invocations).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan in further view of Khatri to incorporate the teachings of Shivanna to “wherein the software component is third-party application, and the managing step includes deploying the third-party application in a segregated containerized environment within the BMC” in order to secure any outside/third-party software first before allowing the full deployment on the BMC. This prevents potential security threats and malicious attacks to the BMC.
Regarding claim 12, Ladkani in view of Rajagopalan in further view of Shivanna
The method of claim 11,
Ladkani in view of Rajagopalan lacks explicitly
wherein the segregated containerized environment is managed via one of a Linux container (LXC) or a systemd-nspawn container runtime
Shivanna teaches
wherein the segregated containerized environment is managed via one of a Linux container (LXC) or a systemd-nspawn container runtime (Ladkani Paragraph [0019] discloses the update manager may be provided with predefined access rights and privileges such that they utilize secure OS containers like Linux OS containers to run the OS service and isolate any firmware or software update invocation).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan in further view of Khatri to incorporate the teachings of Shivanna to “wherein the segregated containerized environment is managed via one of a Linux container (LXC) or a systemd-nspawn container runtime” in order to use a well-known and flexible container service for the purpose of securing the BMC.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ladkani et al. (US 20210141626 A1) hereinafter Ladkani in view of Rajagopalan et al. (US 20230153093 A1) hereinafter Rajagopalan in further view of Khatri (US 20190042755 A1) in further view of Sahu (US 20190050351 A1).
Regarding claim 14, Ladkani in view of Rajagopalan in further view of Khatri discloses
The method of claim 1,
The combination lacks explicitly
wherein the API provides OEM-specific extensions for additional functionalities beyond a standard model
Sahu teaches
wherein the API provides OEM-specific extensions for additional functionalities beyond a standard model (Sahu Paragraph [0038] discloses Redfish plugins are extended to have BIOS service that performs such read/write operations. This provides the ability to change BIOS settings over out-of-band mediums like from the network interface of the host in the server platform as some of the original equipment manufacturer (OEM) vendors are known to keep the management Ethernet port disabled on their systems).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Ladkani in view of Rajagopalan in further view of Khatri to incorporate the teachings of Sahu to “wherein the API provides OEM-specific extensions for additional functionalities beyond a standard model” in order to allow the BMC more flexibility through the API such as changing BIOS settings.
Response to Arguments
Response to 103 remarks:
Applicant’s arguments with respect to claim(s) 1, 3-17, and 19-20, have been considered but are moot because the new ground of rejection does not rely on any reference applied or has been combined with an additional reference in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER J SALLEY whose telephone number is (571)272-6355. The examiner can normally be reached Mon-Fri, 7:30am-5pm.
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.
/CHRISTOPHER J SALLEY/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights