DETAILED ACTION
This action is in response to the Request for Continued Examination (RCE) filed on 01/22/2026. Claims 1,3,9,11 have been amended. Claims 1-16 are pending examination.
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.
Response to Arguments
Rejection under 35 U.S.C. 112(b):
Applicant’s arguments with respect to claim(s) 1-16 have been considered and are persuasive. Hence, the rejection under 35 U.S.C. 112(b) has been withdrawn.
Rejection under 35 U.S.C. 103:
Applicant’s arguments with respect to claim(s) 1-16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
A new reference Zimmer et al. (US 20040268141 A1), discloses a pre-boot security layer that intercepts requests by drivers/ applications to load code or use EFI services/protocols, then authenticates the requesting code/entity and checks its permissions before allowing the request. Zimmer describes instrumenting LoadImage (), OpenProtocol (), HandleProtocol () to consult a platform security unit, which determines identity/authentication and authorizes access using pre-boot/runtime masks and permitted protocol/service lists. If the code object is unknown or lacks a matching authorization entry, it is not loaded or run and its requested service can be denied which is analogous to pre-boot authentication and access control theory.
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 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.
Claims 1 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Downum et al. (US 20210240491 A1), hereinafter referred to as Downum, in view of Zimmer et al. (US 20040268141 A1), hereinafter referred to as Zimmer.
As per claim 1, Downum discloses a method comprising:
provisioning an information handling system with one or more secure platform services (SPSs), wherein the one or more SPSs include:
a first SPS comprising an indicator of attack (IOA) driver configured to perform operations including: (Security module 325 may perform the authentication of each of device drivers 372a-372b to rescue and recover the OS from an attack, Downum, para [0048])
responsive to successfully authenticating the preboot module as a trusted driver, (Pre- boot driver docking engine 310 may be configured to verify and/or authenticate the device drivers prior to providing them to the service OS, Downum, para [0048]) granting access to OEM meta data and a file system handle; and (Once the device drivers are from a verified source, the driver management module may read the driver information files 374a-374n, Downum, para [0048]).
However, Downum does not explicitly disclose the limitation:
responsive to detecting preboot module;
responsive to determining that the preboot module is a runtime application or a UEFI shell application, denying access to the OEM meta data and file system handle
Zimmer discloses:
responsive to detecting preboot module; (A LoadImage( ) service of EF11.02 is instrumented to reference the platform security unit 104 when a driver or application (i.e., more generally code) is discovered in flash memory, on a local disk partition or on a network boot server. Additionally, if a known entity attempts to locate a service though the EF10.10 service OpenProtocol ( ) or the EF11.02 service HandleProtocol( ), the security platform unit 104 will determine if the referenced protocol is authorized to be carried out. The platform security unit 104 determines the identity of an entity requesting service and/or the identity of code that has been requested to be loaded (authentication) and determines the rights the requester or the code to be loaded has been granted (authorization). In general, the platform security process 600 requests for service, such as, for example, requests to load or execute code, requests to perform services in the pre-boot or in runtime, etc. and determines if specified security rules are being obeyed if such a request is fulfilled. In particular, the platform security process 600 performs authentication (i.e., determining the identity of the requesting entity) and authorization (i.e., determining the rights of the authenticated requesting entity). Based on the authentication and authorization, the platform security process will selectively allow the fulfillment of a request, Zimmer, para [0013]- [0014], [0039]. This collectively discloses a pre-boot, a driver or application being discovered/loaded, an attempt to use EFI services/protocols such as OpenProtocol () and authorization before the request is fulfilled)
responsive to determining that the preboot module is a runtime application or a UEFI shell application, denying access to the OEM meta data and file system handle (A system administrator, referred to herein as Kowner, provisions the platform regarding what code objects (Kobj's) can be executed and what the permissions of each Kobj will have after execution, which is defined by pre-boot or runtime masks. For example, if a Kobj is authenticated and run, the Kobj will only be able to carry out tasks consistent with that Kobj's permissions. In the alternative, if the Kobj is unknown (i.e., is not listed in a database of Kobj's and, therefore, does not authenticate), the Kobj will not be loaded or run and the Kobj's request for execution resources, which was denied, will be logged. As shown in FIG. 2, in one example, the platform security unit 104 may be implemented by an authentication unit 202 that is coupled to an access control list 204 that may include identification information 206 and permissible behaviors 208 corresponding to the entities listed in the identification information 206, Zimmer, para [0014]- [0015]. A denying service to code that is unknown or lacks authorization, including by pre-boot/runtime masks and protocol/service permissions, is disclosed)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum and Zimmer by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum and Zimmer in order to effectively authenticate preboot code and gating EFI protocol/service access by authorization (See Zimmer, para [0014]).
As per claim 9, Downum discloses an information handling system, comprising:
a central processing unit (CPU); (Processors 102 and 104, Downum, para [0011])
a system memory accessible to the (CPU), including processor executable instructions, wherein the processor executable instructions include one or more secure platform service (SPSs), wherein the one or more SPSs include:
a first SPS comprising an indicator of attack (IOA) driver configured to perform operations including: (a memory, Downum, para [0011])
responsive to successfully authenticating the preboot module as a trusted driver, (Pre- boot driver docking engine 310 may be configured to verify and/or authenticate the device drivers prior to providing them to the service OS, Downum, para [0048]) granting access to OEM meta data and a file system handle; and (Once the device drivers are from a verified source, the driver management module may read the driver information files 374a-374n, Downum, para [0048]).
However, Downum does not explicitly disclose the limitations:
responsive to detecting preboot module; (A LoadImage( ) service of EF11.02 is instrumented to reference the platform security unit 104 when a driver or application (i.e., more generally code) is discovered in flash memory, on a local disk partition or on a network boot server. Additionally, if a known entity attempts to locate a service though the EF10.10 service OpenProtocol ( ) or the EF11.02 service HandleProtocol( ), the security platform unit 104 will determine if the referenced protocol is authorized to be carried out. The platform security unit 104 determines the identity of an entity requesting service and/or the identity of code that has been requested to be loaded (authentication) and determines the rights the requester or the code to be loaded has been granted (authorization). In general, the platform security process 600 requests for service, such as, for example, requests to load or execute code, requests to perform services in the pre-boot or in runtime, etc. and determines if specified security rules are being obeyed if such a request is fulfilled. In particular, the platform security process 600 performs authentication (i.e., determining the identity of the requesting entity) and authorization (i.e., determining the rights of the authenticated requesting entity). Based on the authentication and authorization, the platform security process will selectively allow the fulfillment of a request, Zimmer, para [0013]- [0014], [0039]. This collectively discloses a pre-boot, a driver or application being discovered/loaded, an attempt to use EFI services/protocols such as OpenProtocol () and authorization before the request is fulfilled)
responsive to determining that the preboot module is a runtime application or a UEFI shell application, denying access to the OEM meta data and file system handle (A system administrator, referred to herein as Kowner, provisions the platform regarding what code objects (Kobj's) can be executed and what the permissions of each Kobj will have after execution, which is defined by pre-boot or runtime masks. For example, if a Kobj is authenticated and run, the Kobj will only be able to carry out tasks consistent with that Kobj's permissions. In the alternative, if the Kobj is unknown (i.e., is not listed in a database of Kobj's and, therefore, does not authenticate), the Kobj will not be loaded or run and the Kobj's request for execution resources, which was denied, will be logged. As shown in FIG. 2, in one example, the platform security unit 104 may be implemented by an authentication unit 202 that is coupled to an access control list 204 that may include identification information 206 and permissible behaviors 208 corresponding to the entities listed in the identification information 206, Zimmer, para [0014]- [0015]. A denying service to code that is unknown or lacks authorization, including by pre-boot/runtime masks and protocol/service permissions, is disclosed).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum and Zimmer by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum and Zimmer in order to effectively authenticate preboot code and gating EFI protocol/service access by authorization (See Zimmer, para [0014]).
Claims 2,3, 10 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Downum et al. (US 20210240491 A1), hereinafter referred to as Downum, in view of Zimmer et al. (US 20040268141 A1), hereinafter referred to as Zimmer in further view of Tashima et al. (US 20110302444 A1), hereinafter referred to as Tashima.
As per claim 2, Downum, Zimmer discloses the method of claim 1, wherein
Furthermore, Downum discloses:
the one or more (Information handling system 100a initiates a connection which may be an out- of-band (OOB) network connection or an in-band network connection, Downum, para [0052]).
However, Downum in view of Zimmer does not disclose:
validating and authenticating UEFI core registration for PHY Protocol Interface (PPI) or protocol interface callback services; and
validating a device path of a data access call using UEFI device path protocol
Tashima discloses:
validating and authenticating UEFI core registration for PHY Protocol Interface (PPI) or protocol interface callback services; and (Monitored UEFI drivers are loaded into the RAM and information about the UEFI driver is registered. The driver setter 121 registers, in the public protocol database 220, Tashima, para [0138]- [0139])
validating a device path of a data access call using UEFI device path protocol (The driver execution controller 122 acquires, from the device list 240, the pointer of the member function corresponding to the device path and function name specified by the boot manager 131, and calls the member function which the pointer points to. The protocol GUID of the protocol includes the device path of the device corresponding to the UEFI driver 140 and interrupt processor 140 detects an invalid UEFI driver, Tashima, para [0155] and [0159]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum and Zimmer with Tashima by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) with driver execution control (Tashima). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum and Zimmer with Tashima in order to ensure security of accessing the data by using a UEFI driver (See Tashima, para [0155])
As per claim 3, Downum, Zimmer discloses the method of claim 2, wherein said validating of the device path includes:
determining whether the caller is from preboot, PEI, DXE, or SMM drivers. de BIOS modules (Service OS is provided by pre-boot device drivers for runtime synchronization at method 400, Downum, para [0068]).
However, Downum in view of Zimmer does not disclose:
parsing a device path of the caller; and
Tashima discloses:
parsing a device path of the caller; and (When reading out the OS boot loader, the boot manager 131 specifies, with respect to the driver execution controller 122, the function name "Read ()" and a file path indicating the directory where the file of the OS boot loader is located, for example. The file path of the OS boot loader includes the device path of the device storing the OS boot loader, Tashima, para [0154]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum and Zimmer with Tashima by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) with driver execution control (Tashima). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum and Zimmer with Tashima in order to ensure security of accessing the data by using a UEFI driver (See Tashima, para [0155])
As per claim 10, Downum and Zimmer disclose the information handling system of claim 9, wherein the one or more SPSs include:
a second SPS configured to perform secured transition band operations, wherein the secured transition band operations include: (Information handling system 100a initiates a connection which may be an out-of-band (OOB) network connection or an in-band network connection, Downum, para [0052]).
However, Downum in view of Zimmer does not disclose:
validating and authenticating UEFI core registration for PHY Protocol Interface (PPI) or protocol interface callback services; and
validating a device path of a data access call using UEFI device path protocol
Tashima discloses:
validating and authenticating UEFI core registration for PHY Protocol Interface (PPI) or protocol interface callback services; and (Monitored UEFI drivers are loaded into the RAM and information about the UEFI driver is registered. The driver setter 121 registers, in the public protocol database 220, Tashima, para [0138]- [0139])
validating a device path of a data access call using UEFI device path protocol (The driver execution controller 122 acquires, from the device list 240, the pointer of the member function corresponding to the device path and function name specified by the boot manager 131, and calls the member function which the pointer points to. The protocol GUID of the protocol includes the device path of the device corresponding to the UEFI driver 140 and interrupt processor 140 detects an invalid UEFI driver, Tashima, para [0155] and [0159]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum and Zimmer with Tashima by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) with driver execution control (Tashima). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum and Zimmer with Tashima in order to ensure security of accessing the data by using a UEFI driver (See Tashima, para [0155])
As per claim 11, Downum and Zimmer disclose the information handling system of claim 10, wherein said validating of the device path includes:
determining whether the preboot module is from preboot, PEI, DXE, or SMM drivers (Service OS is provided by pre-boot device drivers for runtime synchronization at method 400, Downum, para [0068]).
However, Downum in view of Zimmer does not explicitly disclose:
parsing a device path of the-preboot module; and
Tashima discloses:
parsing a device path of the-preboot module; and (When reading out the OS boot loader, the boot manager 131 specifies, with respect to the driver execution controller 122, the function name "Read ()" and a file path indicating the directory where the file of the OS boot loader is located, for example. The file path of the OS boot loader includes the device path of the device storing the OS boot loader, Tashima, para [0154]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum and Zimmer with Tashima by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) with driver execution control (Tashima). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum and Zimmer with Tashima in order to ensure security of accessing the data by using a UEFI driver (See Tashima, para [0155])
Claims 4-8 and 12-16 are rejected under 35 U.S.C. 103 as being unpatentable over Downum et al. (US 20210240491 A1), Zimmer et al. (US 20040268141 A1) in view of Tashima et al. (US 20110302444 A1), hereinafter referred to as Tashima in further view of Brossard et al. (US 20210374235 A1), hereinafter referred to as Brossard.
As per claim 4, Downum, Zimmer, Tashima disclose the method of claim 2, wherein the
Furthermore, Downum, Tashima discloses:
responsive to any other PEI or runtime drivers attempting to access core interfaces, passing through OEM authentication layer and providing vulnerable free and protected data access (NV-RAM 140 includes BIOS/EFI module 142 that operates to detect the resources of information handling system 100, to provide drivers for the resources, to initialize the resources, and to provide common access mechanisms for the resources, Downum, para [0014]- [0015]).
create a GUID based mapping table for unique identifier for PPI or protocol services in pre boot; (Monitored objected list 310 consists of file GUIDs by which the files of the UEFI drivers 140 to be monitored can be uniquely identified are registered, Tashima, para [0132]).
store the identifiers to OEM specific declaration files; (The monitored object list 310 is registered in a nonvolatile storage medium, Tashima, para [0133]).
However, Downum, Zimmer, Tashima does not explicitly disclose:
remap UEFI identifiers for different PPI or protocol to OEM-unique identifiers, which are exposed to OEM drivers;
Brossard discloses:
remap UEFI identifiers for different PPI or protocol to OEM-unique identifiers, which are exposed to OEM drivers; (The sandbox policy 440 can be a file with information related to a configuration of the sandbox process 420 and details regarding restrictions, if any, and permissions for accessing and utilizing system resources. Example restrictions can include restrictions to network access, or file system access e.g., remapping file system to place files in different locations that may not be accessible, other files can be mounted in different locations, and the like. The sandbox process 420 restricts the memory and processor, e.g., CPU usage of the user code runtime 424, ensuring that other operations on the same execution node can execute without running out of resources, Brossard, para [0061]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum, Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
As per claim 5, Downum, Zimmer, Tashima disclose the method of claim 4, wherein the
Furthermore, Downum and Tashima discloses:
create runtime meta data for file system logical blocks for a nested file system partition; (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048])
locate core system protocol services; (BMC 190 utilizes various protocols and application programming interfaces, APIs to direct and control the processes for monitoring and maintaining the system firmware, Downum, para [0022])
create meta data with offset and file read or write interface services (Member function is created for reading out data from a device is done using "Read 0" and when data is to be written into a device, for example, a common function name "Write ()" indicating the member function for implementing the control of writing data, Tashima, para [0147]- [0149]).
However, Downum, Zimmer, Tashima does not disclose:
remap the core system protocol services to OEM-provided drivers; and
Brossard discloses:
remap the core system protocol services to OEM-provided drivers; and (The sandbox process 420 is a sub-process (or separate process) from the execution node process 410, which in practice means that the sandbox process 420 resides in a separate memory space than the execution node process 410. In an occurrence of a security breach in connection with the sandbox process 420, if arbitrary memory is accessed by a malicious actor, the data or information stored by the execution node process is protected, Brossard, para [0062]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum, Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
As per claim 6, Downum, Zimmer, Tashima discloses the method of claim 1, wherein the SPSs include a third a secured GUID data method configured to:
Furthermore, Downum and Tashima discloses:
responsive to any other PEI or runtime drivers attempting to access core interfaces, passing through OEM authentication layer and providing vulnerable free and protected data access (NV-RAM 140 includes BIOS/EFI module 142 that operates to detect the resources of information handling system 100, to provide drivers for the resources, to initialize the resources, and to provide common access mechanisms for the resources, Downum, para [0014]- [0015]).
create a GUID based mapping table for unique identifier for PPI or protocol services in pre boot; (Monitored objected list 310 consists of file GUIDs by which the files of the UEFI drivers 140 to be monitored can be uniquely identified are registered, Tashima, para [0132]).
store the identifiers to OEM specific declaration files; (The monitored object list 310 is registered in a nonvolatile storage medium, Tashima, para [0133]).
However, Downum, Zimmer, Tashima does not disclose:
remap UEFI identifiers for different PPI or protocol to OEM-unique identifiers, which are exposed to OEM drivers;
Brossard discloses:
remap UEFI identifiers for different PPI or protocol to OEM-unique identifiers, which are exposed to OEM drivers; (The sandbox policy 440 can be a file with information related to a configuration of the sandbox process 420 and details regarding restrictions, if any, and permissions for accessing and utilizing system resources. Example restrictions can include restrictions to network access, or file system access, e.g., remapping file system to place files in different locations that may not be accessible, other files can be mounted in different locations, and the like. The sandbox process 420 restricts the memory and processor, e.g., CPU usage of the user code runtime 424, ensuring that other operations on the same execution node can execute without running out of resources, Brossard, para [0061]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum, Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
As per claim 7, Downum, Zimmer, Tashima discloses the method of claim 6, wherein the
Furthermore, Downum discloses:
create runtime meta data for file system logical blocks for a nested file system partition; (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048]).
locate core system protocol services; (BMC 190 utilizes various protocols and application programming interfaces, APIs to direct and control the processes for monitoring and maintaining the system firmware, Downum, para [0022]).
create meta data with offset and file read or write interface services (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048]).
However, Downum, Zimmer, Tashima does not disclose:
remap the core system protocol services to OEM-provided drivers; and
Brossard discloses:
remap the core system protocol services to OEM-provided drivers; and (The sandbox process 420 is a sub-process (or separate process) from the execution node process 410, which in practice means that the sandbox process 420 resides in a separate memory space than the execution node process 410. In an occurrence of a security breach in connection with the sandbox process 420, if arbitrary memory is accessed by a malicious actor, the data or information stored by the execution node process is protected, Brossard, para [0062]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum, Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
As per claim 8, Downum, Zimmer, Tashima disclose the method of claim 1, wherein the
Furthermore, Downum discloses:
create runtime meta data for file system logical blocks for a nested file system partition; (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048]).
locate core system protocol services; (BMC 190 utilizes various protocols and application programming interfaces, APIs to direct and control the processes for monitoring and maintaining the system firmware, Downum, para [0022]).
create meta data with offset and file read or write interface services (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048]).
However, Downum, Zimmer, Tashima does not disclose:
remap the core system protocol services to OEM-provided drivers; and
Brossard discloses:
remap the core system protocol services to OEM-provided drivers; and (The sandbox process 420 is a sub-process (or separate process) from the execution node process 410, which in practice means that the sandbox process 420 resides in a separate memory space than the execution node process 410. In an occurrence of a security breach in connection with the sandbox process 420, if arbitrary memory is accessed by a malicious actor, the data or information stored by the execution node process is protected, Brossard, para [0062]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum, Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
As per claim 12, Downum, Zimmer, Tashima disclose the information handling system of claim 10, wherein the
Furthermore, Downum, Tashima discloses:
responsive to any other PEI or runtime drivers attempting to access core interfaces, passing through OEM authentication layer and providing vulnerable free and protected data access (NV-RAM 140 includes BIOS/EFI module 142 that operates to detect the resources of information handling system 100, to provide drivers for the resources, to initialize the resources, and to provide common access mechanisms for the resources, Downum, para [0014]- [0015]).
create a GUID based mapping table for unique identifier for PPI or protocol services in pre boot; (Monitored objected list 310 consists of file GUIDs by which the files of the UEFI drivers 140 to be monitored can be uniquely identified are registered, Tashima, para [0132]).
store the identifiers to OEM specific declaration files; (The monitored object list 310 is registered in a nonvolatile storage medium, Tashima, para [0133]).
However, Downum, Zimmer, Tashima does not disclose:
remap UEFI identifiers for different PPI or protocol to OEM-unique identifiers, which are exposed to OEM drivers;
Brossard discloses:
remap UEFI identifiers for different PPI or protocol to OEM-unique identifiers, which are exposed to OEM drivers; (The sandbox policy 440 can be a file with information related to a configuration of the sandbox process 420 and details regarding restrictions, if any, and permissions for accessing and utilizing system resources. Example restrictions can include restrictions to network access, or file system access e.g., remapping file system to place files in different locations that may not be accessible, other files can be mounted in different locations, and the like. The sandbox process 420 restricts the memory and processor, e.g., CPU usage of the user code runtime 424, ensuring that other operations on the same execution node can execute without running out of resources, Brossard, para [0061])
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum, Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
As per claim 13, Downum, Zimmer, Tashima disclose the information handling system of claim 12, wherein the
Furthermore, Downum discloses:
create runtime meta data for file system logical blocks for a nested file system partition; (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048]).
locate core system protocol services; (BMC 190 utilizes various protocols and application programming interfaces, APIs to direct and control the processes for monitoring and maintaining the system firmware, Downum, para [0022])
create meta data with offset and file read or write interface services (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048])
However, Downum, Zimmer, Tashima does not disclose:
remap the core system protocol services to OEM-provided drivers; and
Brossard discloses:
remap the core system protocol services to OEM-provided drivers; and (The sandbox process 420 is a sub-process (or separate process) from the execution node process 410, which in practice means that the sandbox process 420 resides in a separate memory space than the execution node process 410. In an occurrence of a security breach in connection with the sandbox process 420, if arbitrary memory is accessed by a malicious actor, the data or information stored by the execution node process is protected, Brossard, para [0062]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum, Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
As per claim 14, Downum, Zimmer, Tashima disclose the information handling system of claim 9, wherein the
Furthermore, Downum, Tashima discloses:
responsive to any other PEI or runtime drivers attempting to access core interfaces, passing through OEM authentication layer and providing vulnerable free and protected data access (NV-RAM 140 includes BIOS/EFI module 142 that operates to detect the resources of information handling system 100, to provide drivers for the resources, to initialize the resources, and to provide common access mechanisms for the resources, Downum, para [0014]- [0015]).
create a GUID based mapping table for unique identifier for PPI or protocol services in pre boot; (Monitored objected list 310 consists of file GUIDs by which the files of the UEFI drivers 140 to be monitored can be uniquely identified are registered, Tashima, para [0132]).
store the identifiers to OEM specific declaration files; (The monitored object list 310 is registered in a nonvolatile storage medium, Tashima, para [0133]).
However, Downum, Zimmer, Tashima does not disclose:
remap UEFI identifiers for different PPI or protocol to OEM-unique identifiers, which are exposed to OEM drivers;
Brossard discloses:
remap UEFI identifiers for different PPI or protocol to OEM-unique identifiers, which are exposed to OEM drivers; (The sandbox policy 440 can be a file with information related to a configuration of the sandbox process 420 and details regarding restrictions, if any, and permissions for accessing and utilizing system resources. Example restrictions can include restrictions to network access, or file system access e.g., remapping file system to place files in different locations that may not be accessible, other files can be mounted in different locations, and the like. The sandbox process 420 restricts the memory and processor, e.g., CPU usage of the user code runtime 424, ensuring that other operations on the same execution node can execute without running out of resources, Brossard, para [0061]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum, Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
As per claim 15, Downum, Zimmer, Tashima discloses the information handling system of claim 14, wherein the
create runtime meta data for file system logical blocks for a nested file system partition; (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048]).
locate core system protocol services; (BMC 190 utilizes various protocols and application programming interfaces, APIs to direct and control the processes for monitoring and maintaining the system firmware, Downum, para [0022])
create meta data with offset and file read or write interface services (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048])
However, Downum, Zimmer, Tashima does not disclose:
remap the core system protocol services to OEM-provided drivers; and
Brossard discloses:
remap the core system protocol services to OEM-provided drivers; and (The sandbox process 420 is a sub-process (or separate process) from the execution node process 410, which in practice means that the sandbox process 420 resides in a separate memory space than the execution node process 410. In an occurrence of a security breach in connection with the sandbox process 420, if arbitrary memory is accessed by a malicious actor, the data or information stored by the execution node process is protected, Brossard, para [0062]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum, Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
As per claim 16, Downum, Zimmer, Tashima the information handling system of claim 9, wherein the
create runtime meta data for file system logical blocks for a nested file system partition; (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048]).
locate core system protocol services; (BMC 190 utilizes various protocols and application programming interfaces, APIs to direct and control the processes for monitoring and maintaining the system firmware, Downum, para [0022]) create meta data with offset and file read or write interface services (Catalog file 378 consists of files 374a- 374n and the driver management module may read the device driver identifier and vendor identifier from these files, Downum, para [0048])
However, Downum, Zimmer, Tashima does not disclose:
remap the core system protocol services to OEM-provided drivers; and
Brossard discloses:
remap the core system protocol services to OEM-provided drivers; and (The sandbox process 420 is a sub-process (or separate process) from the execution node process 410, which in practice means that the sandbox process 420 resides in a separate memory space than the execution node process 410. In an occurrence of a security breach in connection with the sandbox process 420, if arbitrary memory is accessed by a malicious actor, the data or information stored by the execution node process is protected, Brossard, para [0062]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Downum. Zimmer, Tashima with Brossard by runtime synchronization and authentication of pre-boot (Downum) and secure firmware storage (Zimmer) and driver execution control (Tashima) with sandboxing identifiers with different identifiers (Brossard). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Downum, Zimmer and Tashima in order to ensure access is restricted and utilize permissions of system resources (See Brossard, para [0061])
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAGHAVENDER CHOLLETI whose telephone number is (703) 756-1065. The examiner can normally be reached M-F 9am-5pm ET.
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, RUPAL DHARIA can be reached on (571) 272-3880. 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.
Respectfully Submitted,
/RAGHAVENDER NMN CHOLLETI/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights