Detailed Action
This office action is in response to applicant’s submission filed on February 5, 2026. Claims 1-21 are pending and are rejected.
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 .
Response to Amendment
This communication is in response to the amendment filed on February 5, 2026. The Examiner has acknowledged the amended claims 1-3 and 11-14. Claims 1-21 are pending and are rejected.
Response to Arguments
Applicant’s Arguments (Remarks) filed February 5, 2026 have been fully considered, but are moot. Note that this action is made FINAL. See MPEP § 706.07(a).
Applicant’s arguments with respect to claim(s) 1-2, 4-13, and 15-21 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.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4-13, and 15-21 are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0278886 A1 to Li et al. (hereinafter, “Li”) in view of US 20140044265 A1 to Kocher et al. (hereinafter, “Kocher”).
Regarding claim 1, Li discloses: A method for life cycle management of a system-on-chip having functions, the method comprising:
managing, multi-user ownership, including listing owners of the functions in a directory (“Initially, the OEM 138 sends a request (510) for an IP license to the license management server 132. The request includes all information necessary to identify the OEM and the parameters requested. For example, the request may include an identifier associated with the OEM 138, the IP features requested, a volume of units to be authorized, an identifier of the IP owner 136, etc.” [0050] [Examiner notes that this text shows multi-owner ownership in action as there are 2 main users/entities, the IP owner (who owns the chips functions of IP block) and the OEM (who wants to use it). The license management system is tracking ownership and permissions between multiple users (just like a directory of who owns and controls what, the system creates, maintains, and updates in the directory)]); and
allocating, rights of a function over a life cycle of the system-on-chip (“Upon receipt of the request, the license management system 132 sends a notification signal to the IP owner 136 identified in the request, or associated with the IP features, as to the request, seeking approval thereof (515). This notification may be via secure mail or other secure messaging format. In response, the IP owner 136 logs into the license management system 132/200 via the user interface 212. There, the IP owner 136 is able to review and approve, deny, or modify the request. In embodiments, the IP owner 136 can also add comments, such as a valid date range that defines a validity period of time for the approved license. The license manager 220 of the license management server 200 stores the license, updated or not, and the IP Owner responses in its database 240. In the license, the validity dates identified by the IP owner can be included as time codes or date codes, which specify the permitted production period and the period that the licensed features are valid (e.g., feature subscription period)” [0051] [Examiner notes that the IP owner decides who can use their IP and for how long (validity period). This shows the allocating of rights since ownership or access is managed over time]),
according to a configuration command identifying the function, identifying a right of ownership of or access to the function (“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. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps. Once generated, the secure server 230 encrypts at least the configuration payload, and then forwards the license contract to the OEM server 114 via the network 130. In an embodiment, the OEM 138 is responsible for accessing the license management server 132 and downloading the license contract (523). This may be in response to a notification received from the license management server 132” [0052] [Examiner notes that the license contract here is the configuration command, it tells the system which IP function is being licensed, to whom, and for how long, and with what rights]), and
including a signature of an owner of the function (“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. Once generated, the secure server 230 encrypts at least the configuration payload, and then forwards the license contract to the OEM server 114 via the network 130. In an embodiment, the OEM 138 is responsible for accessing the license management server 132 and downloading the license contract (523). This may be in response to a notification received from the license management server 132” [0052] [Examiner notes that this text represents the digital signature/authentication of the owner as it ensures that the license contract is authentic, secure, and approved by the IP owner, which is how the system verifies the command came from the legitimate owner]).
Li does not disclose: managing, by the system-on-chip, multi-user ownership, including listing owners of the functions in a directory stored in a memory of the system-on-chip; and allocating, by the system-on-chip, rights of a function over a life cycle of the system-on-chip,
However, Kocher discloses: managing, by the system-on-chip, multi-user ownership, including listing owners of the functions in a directory stored in a memory of the system-on-chip (“Data storage module 440 may be configured to store one or more security keys (e.g., device keys or group of device keys), product chip ID, one or more SM commands, boot instructions, feature data, configuration data, persistent feature information, etc.” [0123]; “SM commands, when executed, may (among other things) update the Feature state managed by the SM core in the SM-enabled IC. The root-authority system encodes the SM commands in a binary format recognized by the SM core and includes a digital signature to the commands. The combination of commands and signature is known as a signed block. Signed blocks from the root-authority system are referred to as root-signed blocks (“RSBs”) and signed blocks from a delegate-authority system are referred to as delegate-signed blocks (“DSBs”)” [0124] [Examiner notes that it would have been obvious to a POSITA to store the feature ownership/licensing information of the OEM licensing system in the persistent secure memory structure of the SM-enables IC in order to securely maintain and manage authorized feature rights throughout the lifecycle of the system-on-chip. Also, these texts show a stored feature-entitlement registry/table in system-on-chip memory and an SM core being able to manage feature state, execute signed commands, and support multiple authorities (root/delegate) as this corresponds to system-on-chip side management of feature rights across multiple entities/users]); and
allocating, by the system-on-chip, rights of a function over a life cycle of the system-on-chip (“SM commands, when executed, may (among other things) update the Feature state managed by the SM core in the SM-enabled IC” [0124] [Examiner notes that this text shows SM core executing SM commands and the feature state being update in the IC showing a direct system-on-chip side allocation/enforcement. It would have been obvious to a POSITA to combine the external license approval system with the SM-core secure command execution system to implement secure, enforceable, and machine-executable feature right allocation within the system-on-chip. This combination bridges the gap between an external licensing approval system and an internal secure hardware enforcement system such that license decision s are implemented as signed SM commands that are executed by the SOC to allocate and enforce feature rights during device operation]),
Thus, it 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, to combine the
method of Li with the added structure of Kocher in order to securely maintain and manage authorized feature rights throughout the lifecycle of the system-on-chip and implement secure, enforceable, and machine-executable feature right allocation within the system-on-chip.
Regarding claim 12, Li discloses: A system-on-chip, comprising:
a memory (“For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM)” [0014];
functions (the IP features” [0050]); and
a life cycle management system, incorporating a multi-user ownership management circuit configured to (“Embodiments may be implemented in hardware (e.g., circuits), firmware, software, or any combination thereof. Embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, and the like), and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, and the like. Further, any of the implementation variations may be carried out by a general purpose computer, as described below” [0014]):
list owners of the functions in a directory (“Initially, the OEM 138 sends a request (510) for an IP license to the license management server 132. The request includes all information necessary to identify the OEM and the parameters requested. For example, the request may include an identifier associated with the OEM 138, the IP features requested, a volume of units to be authorized, an identifier of the IP owner 136, etc.” [0050] [Examiner notes that this text shows multi-owner ownership in action as there are 2 main users/entities, the IP owner (who owns the chips functions of IP block) and the OEM (who wants to use it). The license management system is tracking ownership and permissions between multiple users (just like a directory of who owns and controls what, the system creates, maintains, and updates in the directory)]); and
allocate rights of a function over a life cycle of the system-on-chip (“Upon receipt of the request, the license management system 132 sends a notification signal to the IP owner 136 identified in the request, or associated with the IP features, as to the request, seeking approval thereof (515). This notification may be via secure mail or other secure messaging format. In response, the IP owner 136 logs into the license management system 132/200 via the user interface 212. There, the IP owner 136 is able to review and approve, deny, or modify the request. In embodiments, the IP owner 136 can also add comments, such as a valid date range that defines a validity period of time for the approved license. The license manager 220 of the license management server 200 stores the license, updated or not, and the IP Owner responses in its database 240. In the license, the validity dates identified by the IP owner can be included as time codes or date codes, which specify the permitted production period and the period that the licensed features are valid (e.g., feature subscription period)” [0051] [Examiner notes that the IP owner decides who can use their IP and for how long (validity period). This shows the allocating of rights since ownership or access is managed over time]),
according to a configuration command identifying the function, identifying a right of ownership of or access to the function (“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. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps. Once generated, the secure server 230 encrypts at least the configuration payload, and then forwards the license contract to the OEM server 114 via the network 130. In an embodiment, the OEM 138 is responsible for accessing the license management server 132 and downloading the license contract (523). This may be in response to a notification received from the license management server 132” [0052] [Examiner notes that the license contract here is the configuration command, it tells the system which IP function is being licensed, to whom, and for how long, and with what rights]), and
including a signature of an owner of the function (“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. Once generated, the secure server 230 encrypts at least the configuration payload, and then forwards the license contract to the OEM server 114 via the network 130. In an embodiment, the OEM 138 is responsible for accessing the license management server 132 and downloading the license contract (523). This may be in response to a notification received from the license management server 132” [0052] [Examiner notes that this text represents the digital signature/authentication of the owner as it ensures that the license contract is authentic, secure, and approved by the IP owner, which is how the system verifies the command came from the legitimate owner]).
Li does not disclose: a life cycle management system, of the system-on-chip, incorporating a multi-user ownership management circuit configured to: list owners of the functions in a directory stored in the memory of the system-on-chip; and
However, Kocher discloses: a life cycle management system, of the system-on-chip, incorporating a multi-user ownership management circuit configured to: list owners of the functions in a directory stored in the memory of the system-on-chip (“Data storage module 440 may be configured to store one or more security keys (e.g., device keys or group of device keys), product chip ID, one or more SM commands, boot instructions, feature data, configuration data, persistent feature information, etc.” [0123]; “SM commands, when executed, may (among other things) update the Feature state managed by the SM core in the SM-enabled IC. The root-authority system encodes the SM commands in a binary format recognized by the SM core and includes a digital signature to the commands. The combination of commands and signature is known as a signed block. Signed blocks from the root-authority system are referred to as root-signed blocks (“RSBs”) and signed blocks from a delegate-authority system are referred to as delegate-signed blocks (“DSBs”)” [0124] [Examiner notes that it would have been obvious to a POSITA to store the feature ownership/licensing information of the OEM licensing system in the persistent secure memory structure of the SM-enables IC in order to securely maintain and manage authorized feature rights throughout the lifecycle of the system-on-chip. Also, these texts show a stored feature-entitlement registry/table in system-on-chip memory and an SM core being able to manage feature state, execute signed commands, and support multiple authorities (root/delegate) as this corresponds to system-on-chip side management of feature rights across multiple entities/users]); and
Thus, it 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, to combine the
method of Li with the added structure of Kocher in order to securely maintain and manage authorized feature rights throughout the lifecycle of the system-on-chip.
Regarding claims 2 and 13, a combination of Li-Kocher discloses all limitations of claims 1/12.
Li further discloses: wherein the memory is a secure memory, the directory is contained in a programming script stored in the secure memory, the configuration command is communicated in a modified version of the programming script, and the method comprises executing the programming script to carry out the allocating the rights of the identified function (“The system-on-chip 420 includes a CPU 422, a trusted execution environment (TEE) 424 and non-volatile memory (NVM) 426, and is connected with flash memory 430. A host provisioning application (HPA) runs on the CPU 422. The HPA receives the initial provisioning request from the OEM server 300 and sends a request to the trusted application operating on the TEE to start the provisioning process. The CPU 422 is the host CPU of the device and is involved not only in the provisioning process, but also in the general chip functioning. The configuration control file received from the OEM server 300 is stored in the flash memory 430. 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. The TEE 424 is used for security purposes. For example, the TEE is a secure virtual computing environment running on the SoC 420 that protects sensitive code and data. Typically, the TEE runs alongside a rich (untrusted) execution environment (REE). A TEE can be created in a variety of different ways. For example, there can be dedicated secure processing in which the TEE is running on a separate secure processor. Alternatively, a TrustZone can be provided, which is a CPU specific hardware and software implementation that virtualizes two CPU contexts: a “normal” world, and a “secure” world. Additionally, the TEE can be virtualized by using a hypervisor to segment a system into TEE and REE virtualized contexts. Within the TEE, the trusted application (TA) 425 operates to carry out the provisioning instructions authorized by the OEM server 300 as discussed above. As their names imply, the trusted execution environment and the trusted application are secure” [0047] [Examiner notes that the CCF is stored in secure memory and having the secure environment (TEE) execute it to enable or control chip functions. The CCF (script) contains ownership/configuration data. The SOC executes that CCF via the TEE to enable the IP features (allocate rights)]; “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. Thus, upon receipt of the CCF, the trusted application decrypts each of the configuration payloads (545). After each of the configuration payloads have been decrypted, the trusted application re-encrypts the CCF along with the unique chip ID and the TEE-specific key, and also generates a log file that is encrypted with the session encryption key. The log file includes information about the licenses provisioned for each IP Owner 136 and their features which are enabled in the device 112. Each IP Owner section in the log is separately encrypted using the IP Owner secret key that can only be processed by the license management system 132. Information contained in the log file includes unique chip ID, license contract, license sequence number, etc. This information is directly copied from the configuration data block received from the OEM server 300 during provisioning. The trusted application in the TEE 424 also generates a digital signal of the log data. The trusted application then forwards both the re-encrypted CCF and the encrypted log file to the HPA operating on the CPU 422” [0062] [Examiner notes that the CCF carries the configuration payload that comes from the license contract (configuration command). When the OEM sends an updates license contract, it is packaged into the CCF therefore the CCF is the modified programming script containing the configuration command]).
Regarding claims 4 and 15, a combination of Li-Kocher discloses all limitations of claims 1/12.
Li further discloses: wherein the allocating the rights of the function comprises, in response to the configuration command including the identifying the right of access to the function, allocating access authorizations to the identified function (“Accordingly, upon receiving the response signal, 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” [0024] [Examiner notes that the IP enablement information is the instruction that tells the production side what the IP functions can do. The production side will then enable or configure the IP feature according to these instructions, which is allocating the access right to the function]).
Regarding claims 5 and 16, a combination of Li-Kocher discloses all limitations of claims 1/12.
Li further discloses: wherein the allocating the rights of the function comprises, in response to the configuration command including the identifying the right of ownership to the function to an identified user, allocating the right of ownership of the identified function to the identified user (“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. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps. Once generated, the secure server 230 encrypts at least the configuration payload, and then forwards the license contract to the OEM server 114 via the network 130. In an embodiment, the OEM 138 is responsible for accessing the license management server 132 and downloading the license contract (523). This may be in response to a notification received from the license management server 132” [0052] [Examiner notes that the license contract explicitly identifies who owns which IP function (the "identified user") and what functions/features are involved. Provisioning enables the IP features and enforces the rights as specified in the contract, effectively allocating the ownership of each function to the identified IP user]).
Regarding claims 6 and 17, a combination of Li-Kocher discloses all limitations of claims 1/12.
Li further discloses: wherein the allocating the rights of the function comprises verifying that the signature of the configuration command authenticates a last known owner for the identified function in the directory (“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” [0024]; “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. Once generated, the secure server 230 encrypts at least the configuration payload, and then forwards the license contract to the OEM server 114 via the network 130. In an embodiment, the OEM 138 is responsible for accessing the license management server 132 and downloading the license contract (523). This may be in response to a notification received from the license management server 132” [0052] [Examiner notes that the license contract includes the IP owner identifications. The digital digest and encryption of the payload protect integrity and authenticity, which allows verification of the owner before provisioning. The configuration payload specifies the IP feature list, this ties the verification to the specific function(s) in question. The OEM or license management system knows the list of authorized IP owner for each function (the directory). By checking the license contract, it ensure that the sender (last known owner) is the one recorded in the directory]).
Regarding claims 7 and 18, a combination of Li-Kocher discloses all limitations of claims 1/12.
Li further discloses: wherein the system-on-chip further includes a system authorizing and prohibiting access to the functions according to a content of a configuration register, and the allocating the rights of the function comprises programming the configuration register to allocate the rights of the function (“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. In an embodiment, the flash 430 is a hard-disk drive or other suitable non-flash memory. Once the features have been enabled, final device production can conclude (555). After the HPA programs the flash 430 with the CCF, the HPA forwards the encrypted log (560) file to the production system 116 at the OEM server 300” [0063] [Examiner notes that the configuration register controls which features are enabled. Flipping the registers is programming them to give access to certain functions. The features are disabled by default and only become authorized when the register is programmed, which align with the claim's description of access control]).
Regarding claims 8 and 19, a combination of Li-Kocher discloses all limitations of claims 7/18.
Li further discloses: irreversibly storing the content of the configuration register, in response to the configuration command defining an irreversible nature of the allocating the rights (“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. In an embodiment, the flash 430 is a hard-disk drive or other suitable non-flash memory. Once the features have been enabled, final device production can conclude (555). After the HPA programs the flash 430 with the CCF, the HPA forwards the encrypted log (560) file to the production system 116 at the OEM server 300” [0063] [Examiner notes that after programming, the features (and the register contents) are fixed for the device (permanent for that production unit)]).
Regarding claims 9 and 20, a combination of Li-Kocher discloses all limitations of claims 7/18.
Li further discloses: wherein the allocating the rights of function is performed when the system-on-chip is started up, in cooperation with the system authorizing and prohibiting the access to the functions, such that all access is prohibited prior to the allocating the rights of the function (“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. In an embodiment, the flash 430 is a hard-disk drive or other suitable non-flash memory. Once the features have been enabled, final device production can conclude (555). After the HPA programs the flash 430 with the CCF, the HPA forwards the encrypted log (560) file to the production system 116 at the OEM server 300” [0063] [Examiner notes that the SOC is started up when provisioning starts since the SOC then begins the process of allocating rights via provision. Allocation happens in cooperation with the access-control system (the registers). The text also shows that before allocation, no features are accessible. Examiner seed this as full blocked (all access is prohibited)]).
Regarding claims 10 and 21, a combination of Li-Kocher discloses all limitations of claims 1/12.
Li further discloses: continuously generating a timestamp, the allocating the rights of the function comprising programming, at a future time determined by the timestamp, the allocating the rights of the function (“Accordingly, upon receiving the response signal, 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” [0024] [Examiner notes that this text explicitly states that the license contract includes a date code range and validity period for the license. It mentions that the validity dates specify when the licensed features are active, which is exactly time-based allocation]).
Regarding claim 11, a combination of Li-Kocher discloses all limitations of claim 1.
Li further discloses: wherein the configuration command comprises a transfer of ownership of the function from the owner of the function to an identified user (“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. The configuration payload specifies the license terms, including the IP feature list and the request/approval timestamps. Once generated, the secure server 230 encrypts at least the configuration payload, and then forwards the license contract to the OEM server 114 via the network 130. In an embodiment, the OEM 138 is responsible for accessing the license management server 132 and downloading the license contract (523). This may be in response to a notification received from the license management server 132” [0052] [Examiner notes that the license contract (configuration command) identifies the current owner (IP owner) and the recipient/user (OEM), which shows a transferring of ownership from the owner to the identified user. The configuration payload contains the IP feature list (these are the functions whose ownership is being allocated)]).
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0278886 A1 to Li et al. (hereinafter, “Li”) in view of US 20140044265 A1 to Kocher et al. (hereinafter, “Kocher”) and in further view of US 2010/0228802 A1 to Bryant-Rich et al. (hereinafter, “Bryant-Rich”).
Regarding claims 3 and 14, a combination of Li-Kocher discloses all limitations of claims 1/12.
Li further discloses: the configuration command is communicated in a certificate including a data string and is stored in a secure memory , and the method comprises interpreting the certificate to carry out the allocating the rights of the identified function (“After OEM server 300 receives the license contract, the license manager 324 constructs a license file (525) from the license contract. The license file is used to enforce the IP Owner 136 licenses during production. The license file contains much of the same data as provided in the license contract, except stripped down to that data necessary for overseeing provisioning, such as enabled features, units authorized, valid date range, etc. The license file also includes a field to track the number of units already produced and/or a number of units remaining to be produced. In embodiments, in order to protect against tampering, replay, cloning or other security breaches, the license file is encrypted. Prior to beginning the provisioning procedure with the device, 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. The verification of the license file may also include a check with the license management server 200 in order to confirm that the license is valid. For example, duplicated use of the license (e.g., cloning) can be evidenced from repeated provisioning requests. In order to prevent cloning, the OEM server 300 institutes a beaconing mechanism with the license management server 200. Specifically, the OEM server 300 periodically sends a beacon message to the license management server 200 and waits for an acknowledgement. If the beaconing fails (e.g., response timed out) for a predetermined number of times, then the OEM server 300 halts provisioning until beaconing succeeds. In an embodiment, the beaconing signal includes the OEM server identification, the current license usage (including the original license file and the number of used licensed instances [e.g., number of production units having the licensed IP feature(s)]), and the production line identification. Notably, in addition to being carried out prior to production, verification with the license management server 200 may also occur at any point thereafter during production” [0054-0056] [Examiner notes that the certificate is seen as the license file. The license file is used to enforce IP owner rights which is showing the allocation of rights of the identified function. The file contains instructions to control which IP features the device is allowed to enable. The verification then shows the interpreting of the license file as its data is being read and ensured that it is valid before allocating rights]).
Li does not disclose: the configuration command is communicated in a certificate including a data string and is stored in a secure memory of the system-on-chip, and the method comprises interpreting the certificate to carry out the allocating the rights of the identified function.
However, Kocher discloses: the configuration command is communicated in a certificate including a data string and is stored in a secure memory of the system-on-chip, and the method comprises interpreting the certificate to carry out the allocating the rights of the identified function (“Data storage module 440 may include one or more SM private memories. Data storage module 440 may be configured to store one or more security keys (e.g., device keys or group of device keys), product chip ID, one or more SM commands, boot instructions, feature data, configuration data, persistent feature information, etc.” [0123 [Examiner notes that this text explicitly says the memory is inside the SM code/SOC, it stores feature data and configuration data, and stores persistent feature information]).
Thus, it 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, to combine the
method of Li with the added structure of Kocher in order to enable secure enforcement of feature authorization and configuration decisions within the system-on-chip
A combination of Li-Kocher do not explicitly disclose: wherein the memory is a one-time programmable memory, the directory is contained in the one-time programmable memory
However, Bryant-Rich discloses: wherein the memory is a one-time programmable memory, the directory is contained in the one-time programmable memory (“In a particular embodiment, a representative first data file 170 is stored at a first plurality of persistent memory cells, such as the first set of memory cells with persistent storage 122. A directory entry 156 that corresponds to the first data file 170 may be stored at a second plurality of persistent memory cells, such as the second set of memory cells with persistent storage 124. The first and second sets of memory cells with persistent storage 122 and 124 may be configured such that data values may be written to, but not erased from, the memory cells. Examples of persistent memory cells include write-once or one-time-programmable (OTP) memory cells or re-writable memory cells, such as flash memory cells that are controlled to prevent changing a stored value” [0012])
Thus, it 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, to combine the
method of Li-Kocher with the added structure of Bryant-Rich in order to have the ownership information (directory) to be permanently stored in the chip’s memory.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should
be directed to SARON MATTHEWOS WORKU whose telephone number is (703)756-1761. The
examiner can normally be reached Monday - Friday, 9:30am - 6:30pm.
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, Linglan Edwards can be reached on 571-270-5440. 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.
/SARON MATTHEWOS WORKU/Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights