DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to Applicant’s communication filed on 04/06/2026. Claims 1-20 have been examined.
Response to Arguments
Applicant’s arguments, see Remarks – Pages 7-8, filed on 04/06/2026, with respect to the rejections of claims 1,16 under 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Samuel.
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.
Claims 1-9,11-12,14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. Publication No. US 2019/0278886 A1 ( Li hereinafter) in view of Samuel et al. Publication No. US 2021/0048997 A1 ( Samuel hereinafter)
Regarding claim 1,
Li teaches an apparatus for payload processing, the apparatus comprising:
at least one memory; and at least one processor coupled to the at least one memory and configured to: receive a license payload for configuring a plurality of hardware components of the apparatus operating in a first configuration to operate in a second configuration, wherein the license payload includes an indicator of a history binding that binds the license payload to follow the first configuration (¶0024; Accordingly, upon receiving the response signal, the license management server generates an IP license contract file, and forwards the license contract file to the production side of the environment and the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid. The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to b provisioned, as well as operation configurations that identify the allowed operation modes – ¶ 0022 - These features are constructed on the chip through hardware, software, or firmware, but are identified in the chip memory as a list. This list, otherwise referred to as a feature bank, includes the enabled or disabled states of those features. As a default, all optional features are disabled, but are capable of being later enabled by an authorized OEM during device production ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload See Also ¶ 0052, ¶ 0067 - After the provisioning process is complete, the device saves the multi-dimensional binding information from the licensing contract in its non-volatile memory.. This information, includes the time codes, production site codes, and operation configurations, among other information).
determine the received license payload is valid for application of the second configuration to the apparatus based on the history binding (¶ 0028 - The trusted application running within the TEE of the device 112 processes the configuration data and performs validation (discussed in detail below) on all the received configuration data blocks included within the provisioning message. The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload – ¶ 0039 - the production software implements two primary functions: enforcing license policies during
production via license verification (discussed in detail below); and provisioning the IP enablement during the device production via a secure provisioning procedure – ¶ 0041 - The CCF generator 320 creates a configuration container file (CCF) that includes a listing of features to be enabled and certain authorization information – See ¶ 0024, the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). See Also ¶ 0067).
Li teaches the license payload (¶ 0052, ¶ 0024). However, Li does not explicitly teach
wherein the indicator of the history binding includes an identifier associated with the first configuration; and determine, based on a determination that the identifier associated with the first configuration is included in the license payload, the received license payload is valid for application of the second configuration to the apparatus based on the history binding.
Samuel teaches
wherein the indicator of the history binding includes an identifier associated with the first configuration (Abstract - An information handling system may include at least one processor, an information handling resource including a firmware, and a memory having an initial identifier stored therein. The information handling system may receive a first firmware update package specifying the initial identifier, wherein the first firmware update package includes therein an intermediate identifier different from the initial identifier; based on the first firmware update package specifying the initial identifier, update the firmware with contents of the first firmware update package ¶ 0035 -The update mechanism for an information handling system may provide for the system to uniquely identify itself in order to bind to particular firmware driver packages that are applicable to such system. This may be accomplished in some embodiments by using an Extensible Firmware Interface (EFI) System Resource Table (ESRT) Globally Unique Identifier (GUID). Each information handling system (for example, all instances of a particular model number or specific configuration) may be identified by the same unique GUID – ¶ 0043 - firmware update packages for BIOS versions 1.0 to 1.2 may be built including an ESRT GUID equal to GUID-esrtint. The firmware update package INF file of the updated packages for version 1.0 to 1.2 may also be built with the same GUID, GUID-Inflnt, and thus they may match any system with that value stored in its ESRT. This is illustrated at state 202); and
determine, based on a determination that the identifier associated with the first configuration is included in the [..] payload, the received [..] payload is valid for application of the second configuration to the apparatus based on the history binding (¶ 0041 - Various firmware update packages may be distributed by firmware update service 210. For example, a firmware update package ( e.g., including both the firmware payload and an INF file) may first be transmitted by a hardware manufacturer to firmware update service 210 for distribution. The INF file may specify an identifier referred to as GUID-Inflnt (e.g., the initial GUID stored in the INF file), which matches the GUID-esrtint value stored in the target system's ESRT. This allows the update mechanism to push newer firmware packages when available, because of the matching values GUID-esrtint and GUID-Inflnt).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the license payload taught by Li to include the teachings of Samuel. The motivation for doing so is to allow the system to update firmware in information handling systems and information handling resources (¶0001 – Samuel).
Regarding claim 2,
Li further teaches
wherein the second configuration configures at least one hardware component of the plurality of hardware components of the apparatus to operate differently as compared to operation of the at least one hardware component in the first configuration (¶ 0022 - As a default, all optional features are disabled, but are capable of being later enabled by an authorized OEM during device production - ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload).
Regarding claim 3,
Li further teaches
wherein each license payload is associated with a unique configuration of the plurality of hardware components of the apparatus and values associated with operation of the plurality of hardware components (¶ 0024 - the license management server 132 generates an IP license contract file, and forwards the license contract file to the production side 110 of the environment 100. In an embodiment, the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to be provisioned, as well as operation configurations that identify the allowed operation modes - ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload – ¶ 0052 – The license contract includes the licensing information necessary to carry out provisioning at the OEM production side 110, as well as logging, etc. Such information includes the configuration payload, the valid date range, the OEM and IP Owner identifications, a production server ID and a digital digest of the information contained in the license contract. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps).
Regarding claim 4,
Li further teaches
wherein the license payload includes an identity of at least one hardware component of the apparatus and a value associated of operation of the at least one hardware component (¶ 0052 – The license contract includes the licensing information necessary to carry out provisioning at the OEM production side 110, as well as logging, etc. Such information includes the configuration payload, the valid date range, the OEM and IP Owner identifications, a production server ID and a digital digest of the information contained in the license contract. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps – ¶ 0024 - the license management server 132 generates an IP license contract file, and forwards the license contract file to the production side 110 of the environment 100. In an embodiment, the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to be provisioned, as well as operation configurations that identify the allowed operation modes -Se e Also ¶ 0067 & ¶ 0028).
Regarding claim 5,
Li further teaches
an identifier associated with the first configuration comprises unique identifier associated with the first configuration, and wherein, to validate the second configuration ( ¶ 0052 – The license contract includes the licensing information necessary to carry out provisioning at the OEM production side 110, as well as logging, etc. Such information includes the configuration payload, the valid date range, the OEM and IP Owner identifications, a production server ID and a digital digest of the information contained in the license contract. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps. ¶ 0024 - the license management server 132 generates an IP license contract file, and forwards the license contract file to the production side 110 of the environment 100. In an embodiment, the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to be provisioned, as well as operation configurations that identify the allowed operation modes – ¶ 0028 - The trusted application running within the TEE of the device 112 processes the configuration data and performs validation (discussed in detail below) on all the received configuration data blocks included within the provisioning message. The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload).
Li teaches the license payload (¶ 0052, ¶ 0024). However, Li does not explicitly teach
determine that the unique identifier associated with the first configuration is included in the license payload
Samuel teaches
identifier associated with the first configuration comprises unique identifier associated with the first configuration, and wherein, to validate the second configuration, the at least one processor is configured to determine that the unique identifier associated with the first configuration is included in a [..] payload (¶ 0041 - Various firmware update packages may be distributed by firmware update service 210. For example, a firmware update package ( e.g., including both the firmware payload and an INF file) may first be transmitted by a hardware manufacturer to firmware update service 210 for distribution. The INF file may specify an identifier referred to as GUID-Inflnt (e.g., the initial GUID stored in the INF file), which matches the GUID-esrtint value stored in the target system's ESRT. This allows the update mechanism to push newer firmware packages when available, because of the matching values GUID-esrtint and GUID-Inflnt).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the license payload taught by Li to include the teachings of Samuel. The motivation for doing so is to allow the system to update firmware in information handling systems and information handling resources (¶0001 – Samuel).
Regarding claim 6,
Li further teaches
wherein, when the license payload is received, the at least one processor is configured with the first configuration based on a prior license payload or an initial configuration (¶ 0022 - These features are constructed on the chip through hardware, software, or firmware, but are identified in the chip memory as a list. This list, otherwise referred to as a feature bank, includes the enabled or disabled states of those features. As a default, all optional features are disabled, but are capable of being later enabled by an authorized OEM during device production – ¶ 0024 - ¶ 0024 - the license management server 132 generates an IP license contract file, and forwards the license contract file to the production side 110 of the environment 100. In an embodiment, the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to be provisioned, as well as operation configurations that identify the allowed operation modes – ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload).
Regarding claim 7,
Li further teaches
wherein, to validate the second configuration, the at least one processor is configured to: determine that the apparatus is configured with the first configuration, wherein the apparatus in the first configuration validates the second configuration (¶ 0025 - A Trusted Application (TA) running within a Trusted Execution Environment (TEE) carries out the provisioning within the device 112 – ¶ 0046 - During provisioning, the TEE 424 handles all security-related tasks as well as the feature enablement based on the CCF. These, and other features are discussed in further detail below – ¶ 0062 - The device 400 receives the CCF via the communication interface 410, and forwards the CCF to the TEE 424 for processing. The trusted application operating on the TEE 424 is pre-programmed with the decryption key for the configuration payloads included in the CCF – ¶ 0028 - The trusted application running within the TEE of the device 112 processes the configuration data and performs validation (discussed in detail below) on all the received configuration data blocks included within the provisioning message. The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload).
Regarding claim 8,
Li further teaches
wherein the first configuration is different from a previous configuration and constrains an order of license payloads applied to the apparatus ¶ 0022 - As a default, all optional features are disabled, but are capable of being later enabled by an authorized OEM during device production - ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload – ¶ 0027 - The OEM server 114 encrypts and packages the configuration data block within a provisioning message, and sends the provisioning message to the trusted application running on the device 112. The provisioning message may include provisioning information for a plurality of IP owners. In that scenario, a separate configuration data block is included within the provisioning message for each IP owner -See Also ¶ 0062, ¶ 0028).
Regarding claim 9,
Li further teaches
wherein the at least one processor is configured to: perform one or more tests on the apparatus to validate performance of the apparatus based on the second configuration (¶0018,¶ 0028 - The trusted application then produces a log on the enabled IP license and encrypts the log to be cryptographically binding, and sends the log back to OEM server 114 for forwarding to the license management server 132 for compliance check -¶ 0034 - A log importer 214 receives log data from the OEM server 114 detailing provisions that have taken place. Such logs may include number of units provisioned, dates of provisioning, features enabled, etc. A log manager 222 compiles and updates the logs based on the received log information. The license manager 220 reviews the logs against corresponding license data to ensure compliance and continued validity. For example, the license manager 220 accesses the license in order to determine the parameters and restricted associated therewith. Then, the license manager 220 retrieves the logs associated with the license. The logs include a variety of information related to the provisioning that occurred, such as date of provisioning, features enabled, etc. By comparing the details in the logs to the parameters/restrictions in the license, the license manager 220 can assess whether the provisioning has been carried out within the bounds of the license, or whether the license has been violated).
Regarding claim 11,
Li further teaches
wherein the history binding precludes the apparatus from entering an invalid state or an untested state (¶ 0022 - These features are constructed on the chip through hardware, software, or firmware, but are identified in the chip memory as a list. This list, otherwise referred to as a feature bank, includes the enabled or disabled states of those features. As a default, all optional features are disabled – ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload - See Also ¶ 0067, ¶ 0055 - the license manager 324 verifies the license file (530). This verification process may involve a number of different checks. For example, the license manager 324 checks that the parameters in the license file are still applicable. These checks include determining that the current date is within the specified valid date range, determining that the number of units has not been met, etc.).
Regarding claim 12,
Li further teaches
.
wherein the apparatus is a system on chip (SoC) (Abstract - A system and method are disclosed for provisioning IP features in a system-on-chip - See Also Fig.4, ¶ 0044, ¶ 0046).
Regarding claim 14,
Li further teaches
wherein the at least one processor is configured to: in response to determining the received license payload is valid for application, apply the received license payload to the apparatus (¶ 0052 - After the license has been approved, the license generator 216 generates the license contract (520). The license contract includes the licensing information necessary to carry out provisioning at the OEM production side 110, as well as logging, etc. Such information includes the configuration payload, the valid date range, the OEM and IP Owner identifications, a production server ID and a digital digest of the information contained in the license contract – ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the
configuration payload – ¶ 0063 - The HPA installs the encrypted CCF file into the flash memory 430, which causes the provisioned features to be enabled (545). Specifically, as discussed above, the chip is already outfitted with all available features. However, those features remain in a default disabled state until the provisioning occurs. The installation of the CCF file into the flash memory 430 causes registers relating to the provisioned features to be flipped, thereby identifying the provisioned features as enabled).
Regarding claim 15,
Li further teaches
wherein the at least one processor is configured to: identifying a first policy of a plurality of policies, wherein each policy in the plurality of policies identifies application of the history binding to the first configuration (¶ 0024 - the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to be provisioned, as well as operation configurations that identify the allowed operation modes – ¶ 0027 - The provisioning message may include provisioning information for a plurality of IP owners. In that scenario, a separate configuration data block is included within the provisioning message for each IP owner – ¶ 0039 - the production software implements two primary functions: enforcing license policies during production via license verification ; and provisioning the IP enablement during the device production via a secure provisioning procedure -See Also ¶ 0052, ¶ 00551).
Regarding claim 16,
Li teaches a method for payload processing, the method comprising:
receiving a license payload for configuring a plurality of hardware components of the apparatus operating in a first configuration to operate in a second configuration, wherein the license payload includes an indicator of a history binding that binds the license payload to follow the first configuration (¶ 0024; Accordingly, upon receiving the response signal, the license management server generates an IP license contract file, and forwards the license contract file to the production side of the environment 100 and the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to b provisioned, as well as operation configurations that identify the allowed operation modes – ¶ 0022 - These features are constructed on the chip through hardware, software, or firmware, but are identified in the chip memory as a list. This list, otherwise referred to as a feature bank, includes the enabled or disabled states of those features. As a default, all optional features are disabled, but are capable of being later enabled by an authorized OEM during device production ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload See Also ¶ 0052, ¶ 0067 - After the provisioning process is complete, the device saves the multi-dimensional binding information from the licensing contract in its non-volatile memory (e.g., flash). This information, includes the time codes, production site codes, and operation configurations, among other information).
determining the received license payload is valid for application of the second configuration to the apparatus based on the history binding (¶ 0028 - The trusted application running within the TEE of the device 112 processes the configuration data and performs validation (discussed in detail below) on all the received configuration data blocks included within the provisioning message. The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload – ¶ 0039 - the production software implements two primary functions: enforcing license policies during
production via license verification (discussed in detail below); and provisioning the IP enablement during the device production via a secure provisioning procedure – ¶ 0041 - The CCF generator 320 creates a configuration container file (CCF) that includes a listing of features to be enabled and certain authorization information – See ¶ 0024, the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). See Also ¶ 0067).
Li teaches the license payload (¶ 0052, ¶ 0024). However, Li does not explicitly teach
wherein the indicator of the history binding includes an identifier associated with the first configuration; and determine, based on a determination that the identifier associated with the first configuration is included in the license payload, the received license payload is valid for application of the second configuration to the apparatus based on the history binding.
Samuel teaches
wherein the indicator of the history binding includes an identifier associated with the first configuration (Abstract - An information handling system may include at least one processor, an information handling resource including a firmware, and a memory having an initial identifier stored therein. The information handling system may receive a first firmware update package specifying the initial identifier, wherein the first firmware update package includes therein an intermediate identifier different from the initial identifier; based on the first firmware update package specifying the initial identifier, update the firmware with contents of the first firmware update package ¶ 0035 -The update mechanism for an information handling system may provide for the system to uniquely identify itself in order to bind to particular firmware driver packages that are applicable to such system. This may be accomplished in some embodiments by using an Extensible Firmware Interface (EFI) System Resource Table (ESRT) Globally Unique Identifier (GUID). Each information handling system (for example, all instances of a particular model number or specific configuration) may be identified by the same unique GUID – ¶ 0043 - firmware update packages for BIOS versions 1.0 to 1.2 may be built including an ESRT GUID equal to GUID-esrtint. The firmware update package INF file of the updated packages for version 1.0 to 1.2 may also be built with the same GUID, GUID-Inflnt, and thus they may match any system with that value stored in its ESRT. This is illustrated at state 202); and
determine, based on a determination that the identifier associated with the first configuration is included in the [..] payload, the received [..] payload is valid for application of the second configuration to the apparatus based on the history binding (¶ 0041 - Various firmware update packages may be distributed by firmware update service 210. For example, a firmware update package ( e.g., including both the firmware payload and an INF file) may first be transmitted by a hardware manufacturer to firmware update service 210 for distribution. The INF file may specify an identifier referred to as GUID-Inflnt (e.g., the initial GUID stored in the INF file), which matches the GUID-esrtint value stored in the target system's ESRT. This allows the update mechanism to push newer firmware packages when available, because of the matching values GUID-esrtint and GUID-Inflnt).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the license payload taught by Li to include the teachings of Samuel. The motivation for doing so is to allow the system to update firmware in information handling systems and information handling resources (¶0001 – Samuel).
Regarding claim 17,
Li further teaches
wherein the second configuration configures at least one hardware component of the plurality of hardware components of the apparatus to operate differently as compared to operation of the at least one hardware component in the first configuration (¶ 0022 - As a default, all optional features are disabled, but are capable of being later enabled by an authorized OEM during device production - ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload).
Regarding claim 18,
Li further teaches
wherein each license payload is associated with a unique configuration of the plurality of hardware components of the apparatus and values associated with operation of the plurality of hardware components (¶ 0024 - the license management server 132 generates an IP license contract file, and forwards the license contract file to the production side 110 of the environment 100. In an embodiment, the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to be provisioned, as well as operation configurations that identify the allowed operation modes - ¶ 0028 - The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload – ¶ 0052 – The license contract includes the licensing information necessary to carry out provisioning at the OEM production side 110, as well as logging, etc. Such information includes the configuration payload, the valid date range, the OEM and IP Owner identifications, a production server ID and a digital digest of the information contained in the license contract. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps).
Regarding claim 19.
Li further teaches
wherein the license payload includes an identity of at least one hardware component of the apparatus and a value associated of operation of the at least one hardware component (¶ 0052 – The license contract includes the licensing information necessary to carry out provisioning at the OEM production side 110, as well as logging, etc. Such information includes the configuration payload, the valid date range, the OEM and IP Owner identifications, a production server ID and a digital digest of the information contained in the license contract. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps – ¶ 0024 - the license management server 132 generates an IP license contract file, and forwards the license contract file to the production side 110 of the environment 100. In an embodiment, the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to be provisioned, as well as operation configurations that identify the allowed operation modes -Se e Also ¶ 0067 & ¶ 0028)..
Regarding claim 20,
Li further teaches
an identifier associated with the first configuration comprises unique identifier associated with the first configuration, and wherein, to validate the second configuration ( ¶ 0052 – The license contract includes the licensing information necessary to carry out provisioning at the OEM production side 110, as well as logging, etc. Such information includes the configuration payload, the valid date range, the OEM and IP Owner identifications, a production server ID and a digital digest of the information contained in the license contract. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps. ¶ 0024 - the license management server 132 generates an IP license contract file, and forwards the license contract file to the production side 110 of the environment 100. In an embodiment, the license contract file is a cryptographically-binding IP license contract file that includes, among other information, an encrypted configuration payload that encodes the IP enablement information (e.g., the information used by the production side to carry out device production), a date code range that specifies a period of validity of the license, and a number of licenses granted. Within the license contract file, the validity dates may be identified in terms of time codes, which specify the permitted production period and the period that the license features are valid (e.g., feature subscription period). The license contract file may also include additional information, such as a production site code, which identifies the authorization location that the device is permitted to be provisioned, as well as operation configurations that identify the allowed operation modes – ¶ 0028 - The trusted application running within the TEE of the device 112 processes the configuration data and performs validation (discussed in detail below) on all the received configuration data blocks included within the provisioning message. The TEE then securely activates or deactivates IP features according to the provisioned information in the configuration payload).
Li teaches the license payload (¶ 0052, ¶ 0024). However, Li does not explicitly teach
determine that the unique identifier associated with the first configuration is included in the license payload
Samuel teaches
an identifier associated with the first configuration comprises unique identifier associated with the first configuration, and wherein validating the second configuration comprises determine that the unique identifier associated with the first configuration is included in a[..] payload (¶ 0041 - Various firmware update packages may be distributed by firmware update service 210. For example, a firmware update package ( e.g., including both the firmware payload and an INF file) may first be transmitted by a hardware manufacturer to firmware update service 210 for distribution. The INF file may specify an identifier referred to as GUID-Inflnt (e.g., the initial GUID stored in the INF file), which matches the GUID-esrtint value stored in the target system's ESRT. This allows the update mechanism to push newer firmware packages when available, because of the matching values GUID-esrtint and GUID-Inflnt).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the license payload taught by Li to include the teachings of Samuel. The motivation for doing so is to allow the system to update firmware in information handling systems and information handling resources (¶0001 – Samuel).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Li in view of Samuel further in view of Allfrey et al. Publication No. US 2016/0292397 A1 ( Allfrey hereinafter)
Regarding claim 10,
Li does not explicitly teach
wherein a number of qualification cases of each test per stock keeping unit (SKU) of the apparatus for testing the license payload prior to distribution is linearly related to a number of prior license payloads.
However, Allfrey teaches
wherein a number of qualification cases of each test per stock keeping unit (SKU) of the apparatus for testing the license payload prior to distribution is linearly related to a number of prior license payloads (Abstract – ¶0005 – the license update engine is minimally executed daily and identifies, for example, content updates to be applied and licenses that have drifted from their original definition. The license update engine then generates proposals for operators to consider. Accepted proposals update the license configuration. Thus, the license update engine identifies licenses and the definitions that are connected to them, including definitions for the licenses from which they were created and definitions
that are linked to SKUs of entitlement purchases. Analyses relate three categories of proposal, including license types, applications linked to licenses, and usage rights on licenses. Proposals are stored in a database and operators can accept or ignore them. The database then maintains a history of the license changes -See Also ¶0006).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Li to include the teachings of Allfrey. The motivation for doing so is to allow the system to provide automatic license configuration updates (¶0001 – Allfrey).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Li in view of Samuel further in view of Aigner et al. Publication No. US 2023/0334127 A1 ( Aigner hereinafter)
Regarding claim 13,
Li further teaches wherein the license payload is issued (¶ 0052, ¶ 0023 – ¶ 0024) . However, Li does not explicitly teach
license payload is issued by a license issuer based on validation of a previous license payload.
Aigner teaches
license payload is issued by a license issuer based on validation of a previous license payload (Claim 36 - receiving, at a license manager of a computing device, a request to generate a license for a software component of the computing device, wherein the request is based on a license verification request from the software component and includes a license information file specific to the software component; receiving the license from the trusted security mechanism – Claim 37 - wherein the request to generate the license is based on determining one of: a previous license for the software component is no longer valid; or a license was not previously issued for the software component -See Also ¶ 0064).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Li to include the teachings of Aigner. The motivation for doing so is to allow the system to generate new license based on determining that the prior license is no longer valid ( Aigner – ¶ 0064).
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 YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached on Monday - Friday 8:30 AM -5:30 PM.
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, Oscar A Louie can be reached on (571) 270-1684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/YOUNES NAJI/Primary Examiner, Art Unit 2445
Prosecution Insights