Detailed Action
The office action is in response to the communication and preliminary amendment dated on 02/28/2025.
In the preliminary amendment dated on 02/28/2025, claims 1-13 are canceled and claims 14-25 are newly added.
Claims 14-25 have been examined.
Claims 14-25 are pending.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Oath/Declaration
The submitted oath/declaration, filed on 06/06/2025, for the instant application has been reviewed by the examiner and is found to conform to the requirements prescribed in 37 C.F.R. 1.63.
Priority
The present application is a 371 application having National Stage entry of PCT/EP2023/074234, filed on 09/05/2023, and claims foreign priority to Germany DE 10 2022 209 628.2, filed 09/14/2022.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 02/28/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Drawings
The preliminary amended drawings, filed on 02/28/2025, for the instant application are acceptable for examination purposes.
Specification
The preliminary amended specification, filed on 02/28/2025, for the instant application is acceptable for examination purposes.
Claim Objection
Claim 18 is objected for the term, “the stored data”. The correction should be “the data stored in the specified memory area” in order to be consistent with the recitation from the independent claim 14.
Claim 20 is objected for the terms, “the stored data” and “the stored result”. The correction should be “the data stored in the specified memory area” and “the result of the check stored in the further memory area of the memory unit …” in order to be consistent with the prior recitations
Claim 22 is objected for the term, “the stored instruction”. The correction should be “the corresponding instruction stored in the further memory area …” in order to be consistent with the prior recitation.
Claim 23 is objected for the term, “the stored data”. The correction should be “the data stored in the specified memory area” in order to be consistent with the recitation from the independent claim 14.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 14-21, 24 and 25 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Schultz (US Pub. 2018/0157603, from the Applicant’s IDS).
Regarding Claims 14, 24 and 25:
As per claim 14, Schulz discloses a method for checking data in a computing unit, wherein the computing unit has a memory unit, a security unit, and a memory protection unit (Schulz, Fig. 1 and Parag. [0021]: “FIG. 1 shows one example of a system 100 configured to support execution of trusted tasks. In this implementation, system 100 includes a processor 110 coupled to an execution-aware memory protection unit (MPU) 120. MPU 120 enforces access control on all memory accesses, including regular memory as well as memory-mapped device I/O (MMIO). MPU 120 includes, in this example, internal region protection registers (RPRs) 122 that may be used to store permissions or rules for regulating access to resources such as regions of memory or MMIO-mapped hardware components. MPU 120 is execution-aware in the sense that it can regulate memory accesses based on the identity of the executable that requests a memory access (the subject of an access request), as well as on the memory address(es) that are to be accessed (the object of the access request”. Parag. [0023]: “In various configurations, secure loader 105 may be a combination of software and hardware, with instructions dependent on a secure hardware component (such as cryptography module 136) in SoC 105 …”. Parag. [0024] :In various implementations of system 100, secure loader 150 may be configured to allow or deny the loading of software components into RAM 138 ….”), comprising the following steps:
storing data to be checked in a specified memory area in the memory unit (Schulz, Parag. [0035]: “Permission table 200 is also depicted with nine rows 211, 212, 213, 221, 222, 223, 231, 232, 233, each corresponding to object addresses of a protected section of memory or to an MMIO device port. At each intersection of a row and a column, the table stores the type of access permission that is available to the object addresses (row) when requested by the subject software elements (column) ….“. Parag. [0037]: “… when (1) an instruction from trusted task A is being executed by a processor (so that trusted task A is the subject) and causes the processor to request access to memory that holds code for trusted task A (so that the code for trusted task A is the object) .…”. Parag. [0038]: “Similarly, trusted task B is allowed to enter and load the memory locations that store the instructions that make up trusted task B (intersection of column 202 and row 212). And the OS is allowed to enter and load the memory locations that store the instructions that make up the OS“. Parag. [0041]: “Rows 221, 222, 223 make up a section 220 that specifies permissions for access to addresses in a SRAM or DRAM module (e.g., RAM 138). This section includes three rows, which hold permissions for accessing memory locations that hold data and stack information for the three software elements”. Parag. [0087]: “… Those other memory spaces are memory regions that hold code for two other software elements, trusted task B (920) and trusted task C (930), along with the working spaces 922, 932 for those two trusted tasks”. Parag. [0088]: “… The measured launch confirms that trusted tasks B and C conform to expected descriptions, such as hashes of their code and/or their configuration parameters, and/or other signatures and/or other descriptive information….”);
configuring, by the security unit, the memory protection unit, in order to protect the specified memory area according to a specified access restriction (Schulz, Parag. [0026]: “In various implementations, secure loader 150 is configured to program MPU 120 during an initialization procedure to protect various memory regions against unauthorized access. These regions may include (a) memory regions that MPU 120 relies upon and (b) memory regions that trusted tasks 170 rely upon”. Parag. [0033]: “… In various implementations, execution-aware memory protection unit MPU can use the permissions in permission table 200 so that access to on-chip elements (e.g., elements 132, 134, 136, and/or 138) and/or external peripherals (e.g. peripherals 144 and/or 145) is securely restricted to various isolated software modules, such as trusted tasks 170.“);
performing, by the memory protection unit, a memory protection of the specified memory area according to the specified access restriction (Schulz, Parag. [0021]: “MPU 120 includes, in this example, internal region protection registers (RPRs) 122 that may be used to store permissions or rules for regulating access to resources such as regions of memory or MMIO-mapped hardware components ….”. Parag. [0029]: “In various implementations, the information in permission table 200 is stored in region protection registers (e.g., RPRs 122) in the MPU”. Parag. [0035]: “Permission Table 200 is also depicted with nine rows 211, 212, 213, 221, 222, 223, 231, 232, 233, each corresponding to object addresses of a protected section of memory or to an MMIO device port. At each intersection of a row and a column, the table stores the type of access permission that is available to the object addresses (row) when requested by the subject software elements (column) ….”); and
checking, by the security unit, the data stored in the specified memory area (Parag. [0026]: “In various implementations, this interaction between secure loader 150 and MPU 120 can support measured launch procedures without additional dedicated hardware support, or with support from hardware accelerators such as a signature verification engine (e.g. in cryptography module 136)”. Parag. [0087]: “… Those other memory spaces are memory regions that hold code for two other software elements, trusted task B (920) and trusted task C (930), along with the working spaces 922, 932 for those two trusted tasks”. Parag. [0088]: “… The measured launch confirms that trusted tasks B and C conform to expected descriptions, such as hashes of their code and/or their configuration parameters, and/or other signatures and/or other descriptive information. The confirmation may be supported by root information obtained from secure memory region ...”).
As per claim 24, it is a computing unit claim that corresponds to the method claim 14. Therefore, claim 24 is rejected with the same rationale and motivation as applied against claim 1 above. In addition, Schulz discloses a computer unit comprising: a memory unit; a security unit; and a memory protection unit (Schulz, Fig. 1 and Parag. [0021]: “FIG. 1 shows one example of a system 100 configured to support execution of trusted tasks. In this implementation, system 100 includes a processor 110 coupled to an execution-aware memory protection unit (MPU) 120. MPU 120 enforces access control on all memory accesses, including regular memory as well as memory-mapped device I/O (MMIO)…. MPU 120 includes, in this example, internal region protection registers (RPRs) 122 that may be used to store permissions or rules for regulating access to resources such as regions of memory or MMIO-mapped hardware components. MPU 120 is execution-aware in the sense that it can regulate memory accesses based on the identity of the executable that requests a memory access (the subject of an access request), as well as on the memory address(es) that are to be accessed (the object of the access request”. Parag. [0023]: “In various configurations, secure loader 105 may be a combination of software and hardware, with instructions dependent on a secure hardware component (such as cryptography module 136) in SoC 105 …”).
As per claim 25, it is a non-transitory machine-readable storage medium that corresponds to the method claim 14. Therefore, claim 25 is rejected with the same rationale and motivation as applied against claim 1 above. In addition, Schulz discloses a non-transitory machine-readable storage medium on which is stored a computer program for checking data in a computing unit and causing the computing unit to perform the steps (Schulz, Parag. [0168] Example 40 includes at least one non-transitory, machine-accessible storage medium. Instructions are stored on the medium. The instructions are configured so that when they are executed on a machine.…”).
Regarding Claim 15:
As per claim 15, Schultz discloses the method according to claim 14, wherein the computing unit is configured such that only the security unit can configure the memory protection unit (Schulz, Parag. [0026]: “In various implementations, secure loader 150 is configured to program MPU 120 during an initialization procedure to protect various memory regions against unauthorized access. These regions may include (a) memory regions that MPU 120 relies upon and (b) memory regions that trusted tasks 170 rely upon. In various implementations, this interaction between secure loader 150 and MPU 120 can support measured launch procedures without additional dedicated hardware support, or with support from hardware accelerators such as a signature verification engine (e.g. in cryptography module 136).”).
Regarding Claim 16:
As per claim 16, Schultz discloses the method according to claim 14, wherein the specified access restriction includes that only the security unit can access the specified memory area for reading and writing (Schulz, Parag. [0024]: “In various implementations of system 100, secure loader 150 may be configured to allow or deny the loading of software components into RAM 138, and/or allow or deny access by software components to various hardware or software resources. …”. Parag. [0026]: “In various implementations, secure loader 150 is configured to program MPU 120 during an initialization procedure to protect various memory regions against unauthorized access. These regions may include (a) memory regions that MPU 120 relies upon and (b) memory regions that trusted tasks 170 rely upon”. Parag. [0041]: “In this example, section 220 has a diagonal relationship between the subject software elements and the access that is permitted to the object addresses used by those software elements: each software element is permitted to read and write to the data and stack locations assigned to that software element, and is denied any access to the data or stack locations assigned to the other software elements.”).
Regarding Claim 17:
As per claim 17, Schultz discloses the method according to claim 14, further comprising: upon receipt of an access request to the specified memory area for an access which is not permitted according to the specified access restriction (Schultz, Parag. [0041]: “… In this example, section 220 has a diagonal relationship between the subject software elements and the access that is permitted to the object addresses used by those software elements: each software element is permitted to read and write to the data and stack locations assigned to that software element, and is denied any access to the data or stack locations assigned to the other software elements”. Parag. [0043]: “… to perform a read on a memory location, say 0x1A30 (the object address). The MPU will first look up the row in permission table 200 that corresponds to that memory location. In the example of FIG. 2, column 250 indicates that row 222 holds the permission information that protects this address. As discussed above, row 222 includes permissions for accessing the memory used by trusted task B. Column 201 of that row indicates that access to this memory should be denied if requested by the processor while the processor is executing trusted task A. Accordingly, in this example situation, the processor would be denied access to read the memory location”):
deciding: (i) whether the security unit initiates a removal or change of the memory protection of the specified memory area and/or (ii) whether the access according to the access request is redirected to another memory area (Schultz, Parag. [0043]: “… to perform a read on a memory location, say 0x1A30 (the object address). The MPU will first look up the row in permission table 200 that corresponds to that memory location. In the example of FIG. 2, column 250 indicates that row 222 holds the permission information that protects this address. As discussed above, row 222 includes permissions for accessing the memory used by trusted task B. Column 201 of that row indicates that access to this memory should be denied if requested by the processor while the processor is executing trusted task A. Accordingly, in this example situation, the processor would be denied access to read the memory location”. Parag. [0026]: “In various implementations, secure loader 150 is configured to program MPU 120 during an initialization procedure to protect various memory regions against unauthorized access. These regions may include (a) memory regions that MPU 120 relies upon and (b) memory regions that trusted tasks 170 rely upon”. Parag. [0033]: “… In various implementations, execution-aware memory protection unit MPU can use the permissions in permission table 200 so that access to on-chip elements (e.g., elements 132, 134, 136, and/or 138)”. Parag. [0072]: “…. an execution-aware MPU is provided with some flexibility to modify access permissions …”. Parag. [0073]: “… the example of FIG. 7 also illustrates a condition in which section 710 has been modified so that trusted task A can write or revise code).
Regarding Claim 18:
As per claim 18, Schultz discloses the method according to claim 14, further comprising:
after the security unit has checked the stored data (Schulz, Parag. [0023]: “… A secure loader 150 is configured to verify and load software into RAM 138”. Parag. [0026]: “In various implementations, this interaction between secure loader 150 and MPU 120 can support measured launch procedures without additional dedicated hardware support, or with support from hardware accelerators such as a signature verification engine (e.g. in cryptography module 136)”. Parag. [0087]: “…. Those other memory spaces are memory regions that hold code for two other software elements, trusted task B (920) and trusted task C (930), along with the working spaces 922, 932 for those two trusted tasks”. Parag. [0088]: “… The measured launch confirms that trusted tasks B and C conform to expected descriptions, such as hashes of their code and/or their configuration parameters, and/or other signatures and/or other descriptive information. The confirmation may be supported by root information obtained from secure memory region ….”):
(i) configuring, by the security unit, the memory protection unit, in order to remove the memory protection of the specified memory area, and removing, by the memory protection unit, the memory protection of the specified memory area; or
(ii) configuring, by the security unit, the memory protection unit, in order to protect the specified memory area according to a second specified access restriction, and performing, by the memory protection unit, a second memory protection of the specified memory area according to the specified second access restriction (Schulz, Parag. [0026]: “In various implementations, secure loader 150 is configured to program MPU 120 during an initialization procedure to protect various memory regions against unauthorized access. These regions may include (a) memory regions that MPU 120 relies upon and (b) memory regions that trusted tasks 170 rely upon”. Parag. [0033]: “… In various implementations, execution-aware memory protection unit MPU can use the permissions in permission table 200 so that access to on-chip elements (e.g., elements 132, 134, 136, and/or 138)”. Figs. 3 and 7 and Parag. [0072]: “…. an execution-aware MPU is provided with some flexibility to modify access permissions during the runtime”. Parag. [0073]: “ … A first section 710 of the table specifies permissions for access to addresses in a PROM or flash memory (e.g., PROM 115) that holds the executable code for the six software elements. This section of FIG. 7 indicates which subject software elements are permitted to access the object addresses that hold the code for those software elements. … In contrast to the example of FIG. 3, the example of FIG. 7 also illustrates a condition in which section 710 has been modified so that trusted task A can write or revise code for two other software elements: trusted tasks B and C.” Examiner Notes: Fig. 3 and Fig. 7 show that the access permissions are modified such that another/second specified access restriction is to enforced by the execution-aware MPU).
Regarding Claim 19:
As per claim 19, Schultz discloses the method according to claim 18, wherein configuring the memory protection unit for removing the memory protection or for performing the second memory protection, is carried out after a start cycle (Schulz, Parag. [0023]: “… In various implementations, secure loader 150 is active only during an initialization following a power-on or reset operation”. Parag. [0026]: “In various implementations, secure loader 150 is configured to program MPU 120 during an initialization procedure to protect various memory regions against unauthorized access. These regions may include (a) memory regions that MPU 120 relies upon and (b) memory regions that trusted tasks 170 rely upon”. Parag. [0033]: “… In various implementations, execution-aware memory protection unit MPU can use the permissions in permission table 200 so that access to on-chip elements (e.g., elements 132, 134, 136, and/or 138)”. Parag. [0072]: “…. an execution-aware MPU is provided with some flexibility to modify access permissions during the runtime …”).
Regarding Claim 20:
As per claim 20, Schultz discloses the method according to claim 14, further comprising:
after the security unit has checked the stored data (Schulz, Parag. [0023]: “… A secure loader 150 is configured to verify and load software into RAM 138”. Parag. [0026]: “In various implementations, this interaction between secure loader 150 and MPU 120 can support measured launch procedures without additional dedicated hardware support, or with support from hardware accelerators such as a signature verification engine (e.g. in cryptography module 136)”. Parag. [0088]: “… The measured launch confirms that trusted tasks B and C conform to expected descriptions, such as hashes of their code and/or their configuration parameters, and/or other signatures and/or other descriptive information. The confirmation may be supported by root information obtained from secure memory region ….”):
storing, by the security unit, a result of the check in a further memory area of the memory unit or in a further memory unit of the computing unit (Schulz, Parag. [0024]: “… The decision to allow or deny loading or access may be based on factors such as source (for example, in various implementations, any module loaded from PROM 115 can be executed), fingerprint (for example, in various implementations, any program whose hash is listed in an access list in PROM 115 can be executed), or a certificate (e.g., any program that is digitally signed with an acceptable certificate in PROM 115 can be executed)”. Parag. [0087]: “…. Those other memory spaces are memory regions that hold code for two other software elements, trusted task B (920) and trusted task C (930), along with the working spaces 922, 932 for those two trusted tasks. Parag. [0088]: “… The measured launch confirms that trusted tasks B and C conform to expected descriptions, such as hashes of their code and/or their configuration parameters, and/or other signatures and/or other descriptive information. The confirmation may be supported by root information obtained from secure memory region 912 ….”),
removing or changing, by the security unit, the memory protection, so that a processing unit is allowed to access the specified memory area at least for reading (Schulz, Parag. [0026]: “In various implementations, secure loader 150 is configured to program MPU 120 during an initialization procedure to protect various memory regions against unauthorized access. These regions may include (a) memory regions that MPU 120 relies upon and (b) memory regions that trusted tasks 170 rely upon. In various implementations, this interaction between secure loader 150 and MPU 120 can support measured launch procedures without additional dedicated hardware support, or with support from hardware accelerators such as a signature verification engine (e.g. in cryptography module 136)”. Parag. [0043]: “… to perform a read on a memory location, say 0x1A30 (the object address). The MPU will first look up the row in permission table 200 that corresponds to that memory location. In the example of FIG. 2, column 250 indicates that row 222 holds the permission information that protects this address. As discussed above, row 222 includes permissions for accessing the memory used by trusted task B. Column 201 of that row indicates that access to this memory should be denied if requested by the processor while the processor is executing trusted task A. Accordingly, in this example situation, the processor would be denied access to read the memory location”. Parag. [0072]: “…. an execution-aware MPU is provided with some flexibility to modify access permissions during the runtime”. Parag. [0073]: “ … A first section 710 of the table specifies permissions for access to addresses in a PROM or flash memory (e.g., PROM 115) that holds the executable code for the six software elements. This section of FIG. 7 indicates which subject software elements are permitted to access the object addresses that hold the code for those software elements. … In contrast to the example of FIG. 3, the example of FIG. 7 also illustrates a condition in which section 710 has been modified….”. Parag. [0074]: “… the example of FIG. 7 also illustrates a condition in which section 720 has been modified so that trusted task A can read and write the data locations….”);
reading, by the processing unit, the stored result of the check, and processing, by the processing unit, the data (Schulz, Parag. [0024]: “… The decision to allow or deny loading or access may be based on factors such as source (for example, in various implementations, any module loaded from PROM 115 can be executed), fingerprint (for example, in various implementations, any program whose hash is listed in an access list in PROM 115 can be executed), or a certificate (e.g., any program that is digitally signed with an acceptable certificate in PROM 115 can be executed)”. Parag. [0039]: “… causes the processor to request access to memory that holds code for trusted task B (so that the code for trusted task B is the object). In this situation, the intersection of column 201 and row 212 indicates that the processor would be allowed to access the requested memory”. Parag. [0087]: “…. Those other memory spaces are memory regions that hold code for two other software elements, trusted task B (920) and trusted task C (930), along with the working spaces 922, 932 for those two trusted tasks. Parag. [0088]: “… The measured launch confirms that trusted tasks B and C conform to expected descriptions, such as hashes of their code and/or their configuration parameters, and/or other signatures and/or other descriptive information. The confirmation may be supported by root information obtained from secure memory region 912 ….”).
Regarding Claim 21:
As per claim 21, Schultz discloses the method according to claim 14, further comprising:
after the data to be checked have been stored in the specified memory area: instructing the security unit in order to check the data stored in the specified memory area (Schulz, Parag. [0035]: “Permission table 200 is also depicted with nine rows 211, 212, 213, 221, 222, 223, 231, 232, 233, each corresponding to object addresses of a protected section of memory or to an MMIO device port. At each intersection of a row and a column, the table stores the type of access permission that is available to the object addresses (row) when requested by the subject software elements (column) ….“. Parag. [0037]: “… when (1) an instruction from trusted task A is being executed by a processor (so that trusted task A is the subject) and causes the processor to request access to memory that holds code for trusted task A (so that the code for trusted task A is the object) .…”. Parag. [0038]: “Similarly, trusted task B is allowed to enter and load the memory locations that store the instructions that make up trusted task B (intersection of column 202 and row 212). And the OS is allowed to enter and load the memory locations that store the instructions that make up the OS“. Parag. [0041]: “Rows 221, 222, 223 make up a section 220 that specifies permissions for access to addresses in a SRAM or DRAM module (e.g., RAM 138). This section includes three rows, which hold permissions for accessing memory locations that hold data and stack information for the three software elements”. Parag. [0087]: “… Those other memory spaces are memory regions that hold code for two other software elements, trusted task B (920) and trusted task C (930), along with the working spaces 922, 932 for those two trusted tasks”. Parag. [0026]: “In various implementations, this interaction between secure loader 150 and MPU 120 can support measured launch procedures without additional dedicated hardware support, or with support from hardware accelerators such as a signature verification engine (e.g. in cryptography module 136)”. Parag. [0088]: “… The measured launch confirms that trusted tasks B and C conform to expected descriptions, such as hashes of their code and/or their configuration parameters, and/or other signatures and/or other descriptive information. The confirmation may be supported by root information obtained from secure memory region ...”).
Claim Rejections - 35 USC § 103
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Schultz (US Pub. 2018/0157603, from the Applicant’s IDS) in view of Pan (EP 3547195).
Regarding Claim 22:
As per claim 22, Schultz discloses the method according to claim 21, wherein instructing the security unit includes:
storing a corresponding instruction in a further memory area of the memory unit or in a further memory unit of the computing unit (Schulz, Parag. [0035]: “Permission table 200 is also depicted with nine rows 211, 212, 213, 221, 222, 223, 231, 232, 233, each corresponding to object addresses of a protected section of memory or to an MMIO device port. At each intersection of a row and a column, the table stores the type of access permission that is available to the object addresses (row) when requested by the subject software elements (column) ….“. Parag. [0037]: “… when (1) an instruction from trusted task A is being executed by a processor (so that trusted task A is the subject) and causes the processor to request access to memory that holds code for trusted task A (so that the code for trusted task A is the object) .…”. Parag. [0038]: “Similarly, trusted task B is allowed to enter and load the memory locations that store the instructions that make up trusted task B (intersection of column 202 and row 212). And the OS is allowed to enter and load the memory locations that store the instructions that make up the OS“).
Schultz does not expressly teach the following limitations:
sending a notification, including an interrupt, to the security unit; and
reading, by the security unit, the stored instruction following the notification.
However, Pan teaches:
sending a notification, including an interrupt, to the security unit (Pan, Parag. [0219]: “In S704, the secure processor 31 may receive an interrupt. The interrupt may be indication information transmitted to the secure processor 31 by a central processing unit 211 by using a dedicated transmission channel.”); and
reading, by the security unit, the stored instruction following the notification (Pan, Parag. [0128]: “In S705, the secure processor 31 determines whether the interrupt indicates the switching. If the interrupt indicates the switching, S706 is performed; otherwise, S703 is performed. In S703, the secure processor 31 processes the interrupt from the central processing unit 211, for example, performs a corresponding operation under instruction of the central processing unit 211…”. Parag [0140]: “the secure processor 31 may begin with reading an on-chip instruction in a read-only memory 33 inside a secure element 23. Specifically, the secure processor 31 may read a boot program instruction in the on-chip instruction to perform initialization of the secure processor 31….”).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Schultz by further incorporating Pan to arrive at the claimed invention. One would be motivated to incorporate the teaching of Pan’s switching mechanism based on the interrupt notification from the central processing unit so that the SoC may be provided with switching support between multiple secure operating system while ensuring security (See Pan, Parag. [0006]).
Claim(s) 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Schultz (US Pub. 2018/0157603, from the Applicant’s IDS) in view of Hanel et al. (US Pub. 2020/0252207), hereinafter Hanel.
Regarding Claim 23:
As per claim 23, Schultz discloses the method according to claim 14.
Schultz further teaches wherein the method further comprises:
before the data are stored in the specified memory area, receiving the data via an interface of the computing unit (Schultz, Fig. 1 and Parag. [0021]:”FIG. 1 shows one example of a system 100 configured to support execution of trusted tasks. In this implementation, system 100 includes a processor 110 coupled to an execution-aware memory protection unit (MPU) 120. MPU 120 enforces access control on all memory accesses, including regular memory as well as memory-mapped device I/O (MMIO). MPU 120 includes, in this example, internal region protection registers (RPRs) 122 that may be used to store permissions or rules for regulating access to resources such as regions of memory or MMIO-mapped hardware components. MPU 120 is execution-aware in the sense that it can regulate memory accesses based on the identity of the executable that requests a memory access (the subject of an access request), as well as on the memory address(es) that are to be accessed (the object of the access request). In various implementations, MPU considers the address of the currently executing instruction when validating a particular data or code access. In this example, system 100 also includes a physical unclonable function unit (PUF) 131, a programmable read-only memory (PROM) 115, a random access memory (RAM) 138, a cryptography module 136 such as a cryptographic accelerator, a timer 134, and an input/output (I/O) interface 132. In this example, these elements 110, 115, 120, 131, 132, 134, 13, and 138 are packaged in a system-on-a-chip (SoC) 105. The SoC architecture may be configured so that communication among the internal elements is secure or resistant to eavesdropping, tampering, or other attack. System 100 is also shown as having peripheral elements 144 and 145 and an external dynamic RAM (DRAM) memory 142, which are external to SoC 105. Peripherals 144, 145 and external DRAM 142 communicate with the SoC elements through I/O interface 132”. Parag. [0024]: “In various implementations of system 100, secure loader 150 may be configured to allow or deny the loading of software components into RAM 138, and/or allow or deny access by software components to various hardware or software resources during an initialization procedure.). Parag. [0087]: “… Those other memory spaces are memory regions that hold code for two other software elements, trusted task B (920) and trusted task C (930), along with the working spaces 922, 932 for those two trusted tasks”. Parag. [0088]: “… The measured launch confirms that trusted tasks B and C conform to expected descriptions, such as hashes of their code and/or their configuration parameters, and/or other signatures and/or other descriptive information. ...”).
Schultz does not expressly teach the following limitations:
wherein the data to be checked are part of an update; and
after the security unit has checked the stored data, activating the data in the specified memory area or installing the data in another memory area.
However, Hanel discloses wherein the data to be checked are part of an update (Hanel, Parag. [0056]: “The software update package may also include a signature attesting to a source of the software update package. … such that the signature can then be verified as coming from the attested source by verifying the signature and the software update package based on a public key associated with that attested identity”); and
after the security unit has checked the stored data, activating the data in the specified memory area or installing the data in another memory area (Hanel, Parag. [0081]: “At step 150 a request is made by code executing in the less secure environment to install the software updates received in the update package, or to boot or execute software codes stored in encrypted form, and the software package 60 is then obtained from less secure memory by the RTM 26…. the RTM verifies the signature associated with the code and data and if signature verification is determined to be successful at step 156 then the installation, booting or running of the updated software is allowed”).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Schultz by further incorporating Hanel to arrive at the claimed invention. One would be motivated to incorporate the teaching of Hanel’s encryption and signature verification scheme on the software update for installation so as to prevent reverse engineering of software on a device as well as being distributed in an encrypted form during over the air updates to reduce the opportunity for the attacker to be able to identify code vulnerabilities (See Hanel, Parag. [0002]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Atzmon (US Pub. 20160147672) teaches a device having a protection unit for controlling access to a memory. Indirect memory access requests have control data indicative of a memory access control register to be written to provide indirect access to a target memory and requested address data indicative of at least one memory address of the target memory to be accessed. The protection unit contains protection data defining access rights of source units to access specified address ranges of the target memory, and a system bus interface interfacing to a source unit and a memory bus interface interfacing to the target memory via a controller. The protection unit has a control monitor for detecting an indirect memory access request, and an indirect address monitor for comparing requested address data to specified address ranges and subsequently grant the indirect memory access in accordance with access rights of the respective source unit.
Aramaki et al. (US Pub. 20160274817) teaches a processor of a storage device is configured: to receive an instruction of setting a portion of an area of a storage medium from a first state to a second state and receive first information defining a condition of setting the portion of the area from the second state to the first state again from a first host device among a plurality of host devices; to set the portion of the area to the second state in response to the instruction; and to set, after the portion of the area is set to the second state in response to the instruction, the portion of the area from the second state to first state again based on the first information.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN CHEN SHAW whose telephone number is (571)272-8878. The examiner can normally be reached Monday - Friday, 10:00AM - 6:00PM.
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, Amy C. Johnson can be reached at (571)272-2238. 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.
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights