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 .
Claims 1-20 are pending.
This is in response to communications filed on 9/10/24.
Claim Interpretation
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent is not met. If the condition for performing a contingent step is not satisfied, the performance recited by the step need not be carried out in order for the claimed method to be performed. See Ex Parte Schulhauser. For example, assume a method claim requires step A if a first condition happens and step Bif a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B (MPEP 2111.04).
Claims 2-4 recite the limitations “when a security level is a first level/second level/third level”, which are not required conditions to be occurred. The BRI does not include the conditions and associated functions based on the conditions when method can be practiced without conditions being met. BRI does not include “providing to the first ECU …”, “comparing by the storage controller, a second boot code …”, “comparing by the storage controller, a fourth boot code …” because method can be practiced without security level being first to third level. For compact prosecution, Examiner addressed the conditional limitations as described below.
The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. The system claim interpretation differs from a method claim interpretation because the claimed structure must be present in the system regardless of whether the condition is met and the function is actually performed. Claims 8-20 recite the system claim and the BRI includes structures corresponding to conditions “when a security level is a first level/second level/third level.”
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.
Claim(s) 15, 16, 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Neill et al (US Patent 20180004979).
For claim 15, Neill et al teach the following limitations: A storage device (Fig 18 shows various storage devices, which collectively constitute the storage device) comprising: a first non-volatile memory storing boot codes (1860 stores 1862; Fig 20 mentions boot ROM) of a plurality of electronic control units (ECUs) (cores 1815 in Fig 18 are the ECUs; Fig 20 shows the booting of the plurality of cores by the boot codes; boot codes retrieved from the boot ROM); and a storage controller (1820, 1840, 1845 and 1850 in Fig 18) configured to identify security levels respectively corresponding to respective ECUs of the plurality of ECUs ([0148] – CPU fabric can determine if security attributes associated with processor cores of the host CPU is configured; each core has corresponding security attribute; [0151][0153] – security ID for each processor core may represent a security level for assigned to the processor core; Fig 20 step 2005), and provide, based on the security levels , respective boot codes ([0179]-[0180]), of the boot codes (Fig 20 shows the booting of each processor core including setting security ID; [0153] security ID represents an identifier of a security mode in which processor core is placed; [0158] mentions that processor core may be operating at the highest level of security in boot mode; [0167] early boot code … configuration of firewall … on which configuration code is executing is at the possible security level; thus the cores are executing the boot codes that are based on the identified security levels of the cores) which are stored in the first non-volatile memory, to respective ECUs (Fig 20 shows the booting of the plurality of cores by the boot codes; boot ROM stores the boot software/code [0156][0178]) based on the identified security levels (Fig 20 shows the booting of each processor core including setting security ID; [0153] security ID represents an identifier of a security mode in which processor core is placed; [0153] further mentions security of the core represent the ID of the VM; thus each core is separately configured to be in the respective security mode, which requires cores to have respective boot codes that are based on the identified security levels of the cores).
For claim 16, Neill teaches wherein the storage controller is configured to, when a security level of a first ECU, of the plurality of ECUs, is a first level (Fig 20, step 2005 sets the security level for the core, provide boot codes to the CPU (i.e., cores) in step 2010), provide a first boot code, of the boot codes stored in the first non-volatile memory ([0158] – cores are operating at the highest level of security; step 2030 sets the security ID value of each core; [0153] mentions that security ID represents a mode into which the core is placed; thus, core receives the boot code to set the security mode to operate) and which corresponds to the first ECU ([0158] [0153] mentions that security ID represents a mode into which the core is placed; thus, core receives the corresponding boot code to set the security mode to operate), to the first ECU as the respective boot code (Fig 20; boot software from boot ROM configures the CPU and the cores; the boot code corresponds to first core and other core to configure the cores according to the security ID).
For claim 20, Neill et al teach the following limitations: wherein the storage controller configured to receive a boot code corresponding to an ECU, of the plurality of ECUs (Fig 20 shows the receiving of the boot code by host CPU to configure the cores of the host CPU; setting security value; [0153] mentions that security ID represents the ID of the security mode into which the core is placed or is to operate; thus core is configured to the security mode before ID is set), and identify a security level of the ECU included in the received boot code based on the boot codes stored in the first non-volatile memory (step 2030 of Fig 20 boot software sets the security ID of each core; thus the boot code that configures the core includes the security level of the core).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 5-9, 12-14, 19 in is/are rejected under 35 U.S.C. 103 as being unpatentable over Neill et al (US Patent Application Publication 20180004979) and further in view of Kito et al (US Patent Application Publication 2018/0074929)
For claim 1, Neill et al teach the following limitations: A method of operating an electronic device (Fig 18; Fig 19-Fig 21) (cores 1815 in Fig 18), the method comprising: identifying, by a storage controller (1820, 1840, 1845 and 1850 in Fig 18), a security level corresponding to each of the plurality of ECUs ([0148] – CPU fabric can determine if security attributes associated with processor cores of the host CPU is configured; each core has corresponding security attribute; [0151][0153] – security ID for each processor core may represent a security level for assigned to the processor core; Fig 20 step 2005) and providing to the plurality of ECUs, by the storage controller, boot codes ([0179]-[0180]) based on the identified security levels (Fig 20 shows the booting of each processor core including setting security ID; [0153] security ID represents an identifier of a security mode in which processor core is placed; [0158] mentions that processor core may be operating at the highest level of security in boot mode; [0167] early boot code … configuration of firewall … on which configuration code is executing is at the possible security level; thus the cores are executing the boot codes that are based on the identified security levels of the cores), the boot codes respectively corresponding to the plurality of ECUs (Fig 20 shows the booting of the plurality of cores by the boot codes) and being stored in a first non-volatile memory (boot ROM stores the boot software/code [0156][0178]).
Neill et al do not explicitly mention that the device is a car mounted device. Kito teaches a system where a plurality of electronic unit with corresponding security level is booted (secure boot [0017]-[0019] security level for each ECU [0046]-[0048] Fig 4).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to combine the teachings of Neill and Kito so that the car mounted device can be securely booted using security levels of the electronic units. The car mounted device can implement the secure booting as disclosed in Neill so that security levels of each of the ECU can be ensured. This ensures appropriate security in the car mounted device.
For claim 2, Neill teaches wherein the providing of the boot codes to the plurality of ECUs comprises, when a security level of a first ECU, of the plurality of ECUs, is a first level (Fig 20, step 2005 sets the security level for the core, provide boot codes to the CPU (i.e., cores) in step 2010), providing to the first ECU, by the storage controller, a first boot code ([0158] – cores are operating at the highest level of security; step 2030 sets the security ID value of each core; [0153] mentions that security ID represents a mode into which the core is placed; thus, core receives the boot code to set the security mode to operate), wherein the first boot code is stored in the first non-volatile memory and corresponds to the first ECU (Fig 20; boot software from boot ROM configures the CPU and the cores; thus the boot code corresponds to first core and other core).
For claim 5, Neill does not explicitly mention that the security level corresponding to each of the plurality of ECUs is determined in advance based on automotive safety integrity levels (ASILs). Kito teaches each ECU’s security level is determined based on ASIL ([0048]). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide the security level in accordance to ASIL, since that way the security setting would be standardized and comparable with other secured system.
For claim 6, Neill teaches wherein the identifying, by the storage controller, the security level comprises receiving, by the storage controller, a boot request for an ECU, of the plurality of ECUs, and identifying, by the storage controller, a security level of the ECU included in the boot request ([0178] mentions the boot event step 2005 sets the security ID; thus the boot request includes the security level, which is highest security level of each core).
For claim 7, Neill et al teach the following limitations: wherein the identifying, by the storage controller, the security level comprises receiving, by the storage controller, a boot code of an ECU, of the plurality of ECUs (Fig 20 shows the receiving of the boot code by host CPU to configure the cores of the host CPU; setting security value; [0153] mentions that security ID represents the ID of the security mode into which the core is placed or is to operate; thus core is configured to the security mode before ID is set), and identifying, by the storage controller, a security level of the ECU included in the received boot code based on the boot codes stored in the first non-volatile memory (step 2030 of Fig 20 boot software sets the security ID of each core; thus the boot code that configures the core includes the security level of the core).
For claim 8, Neill teaches the following limitations: An electronic device (Fig 18; Fig 19-Fig 21) (cores 1815 in Fig 18); and a storage device (Fig 18 shows various storage devices, which collectively constitute the storage device) shared by the plurality of ECUs (1860 is the memory device shared by the cores; Fig 20 host CPU boots from boot ROM; Fig 18 shows that host CPU with cores shares 1820), wherein the storage device comprises a first non-volatile memory storing boot codes for the plurality of ECUs (1860 stores 1862; Fig 20 mentions boot ROM), and a storage controller (1820, 1840, 1845 and 1850 in Fig 18) configured to identify security levels corresponding to respective ECUs of the plurality of ECUs ([0148] – CPU fabric can determine if security attributes associated with processor cores of the host CPU is configured; each core has corresponding security attribute; [0151][0153] – security ID for each processor core may represent a security level for assigned to the processor core; Fig 20 step 2005), and provide respective boot codes ([0179]-[0180]), of the boot codes which are stored in the first non-volatile memory (Fig 20 shows the booting of the plurality of cores by the boot codes; boot codes retrieved from the boot ROM) to the respective ECUs based on the identified security levels (Fig 20 shows the booting of each processor core including setting security ID; [0153] security ID represents an identifier of a security mode in which processor core is placed; [0158] mentions that processor core may be operating at the highest level of security in boot mode; [0167] early boot code … configuration of firewall … on which configuration code is executing is at the possible security level; thus the cores are executing the boot codes that are based on the identified security levels of the cores).
Neill et al do not explicitly mention that the device is a car mounted device. Kito teaches a system where a plurality of electronic unit with corresponding security level is booted (secure boot [0017]-[0019] security level for each ECU [0046]-[0048] Fig 4).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to combine the teachings of Neill and Kito so that the car mounted device can be securely booted using security levels of the electronic units. The car mounted device can implement the secure booting as disclosed in Neill so that security levels of each of the ECU can be ensured. This ensures appropriate security in the car mounted device.
For claim 9, Neill teaches wherein the providing of the boot codes to the plurality of ECUs comprises, when a security level of a first ECU, of the plurality of ECUs, is a first level (Fig 20, step 2005 sets the security level for the core, provide boot codes to the CPU (i.e., cores) in step 2010), providing to the first ECU, by the storage controller, a first boot code ([0158] – cores are operating at the highest level of security; step 2030 sets the security ID value of each core; [0153] mentions that security ID represents a mode into which the core is placed; thus, core receives the boot code to set the security mode to operate), wherein the first boot code is stored in the first non-volatile memory and corresponds to the first ECU (Fig 20; boot software from boot ROM configures the CPU and the cores; thus the boot code corresponds to first core and other core).
For claim 12, Neill does not explicitly mention that the security level corresponding to each of the plurality of ECUs is determined in advance based on automotive safety integrity levels (ASILs). Kito teaches each ECU’s security level is determined based on ASIL ([0048]). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide the security level in accordance to ASIL, since that way the security setting would be standardized and comparable with other secured system.
For claim 13, Neill teaches wherein the identifying, by the storage controller, the security level comprises receiving, by the storage controller, a boot request for an ECU, of the plurality of ECUs, and identifying, by the storage controller, a security level of the ECU included in the boot request ([0178] mentions the boot event step 2005 sets the security ID; thus the boot request includes the security level, which is highest security level of each core).
For claim 14, Neill et al teach the following limitations: wherein the identifying, by the storage controller, the security level comprises receiving, by the storage controller, a boot code of an ECU, of the plurality of ECUs (Fig 20 shows the receiving of the boot code by host CPU to configure the cores of the host CPU; setting security value; [0153] mentions that security ID represents the ID of the security mode into which the core is placed or is to operate; thus core is configured to the security mode before ID is set), and identifying, by the storage controller, a security level of the ECU included in the received boot code based on the boot codes stored in the first non-volatile memory (step 2030 of Fig 20 boot software sets the security ID of each core; thus the boot code that configures the core includes the security level of the core).
For claim 19, Neill does not explicitly mention that the security level corresponding to each of the plurality of ECUs is determined in advance based on automotive safety integrity levels (ASILs). Kito teaches each ECU’s security level is determined based on ASIL ([0048]). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide the security level in accordance to ASIL, since that way the security setting would be standardized and comparable with other secured system.
Claim(s) 3, 4, 10, 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Neill et al (US Patent Application Publication 20180004979) and further in view of Kito et al (US Patent Application Publication 2018/0074929), further in view of Mai et al (US Patent Application Publication 20080040596)
For claims 3, 10, Neill teaches wherein the providing of the boot codes to the plurality of ECUs comprises, when a security level of a second ECU, of the plurality of ECUs, is a second level (security level can be multiple numerically ordered [0153]; [0164] maximum allowable security ID, minimum allowable security ID; thus the ECUs can have any security ID with security level). Neill further teaches boot code corresponding to ECU ([0153] each core its own security mode for operation which determines the security ID; thus each core is configured by corresponding boot code). Neill in view of Kito does not teach comparing, by the storage controller, a second boot code, stored in the first non-volatile memory, with a third boot code stored in a second non-volatile memory; and providing, by the storage controller, the second boot code to the second ECU, based on a result of the comparing the third boot code with the second boot code. Mai et al teach a system where two boot codes are compared and providing a boot code based on the comparison (step 306 of Fig 3; Fig 3 [0036][0037]; boot code is provided when boot code are different [0037][0041]).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide copies of boot code and compare them to accept the more secured/updated copy since that way system is ensured to have a clean boot code. This ensures security.
For claims 4, 11, Neill teaches wherein the providing of the boot codes to the plurality of ECUs comprises, when a security level of a third ECU, of the plurality of ECUs, is a third level (security level can be multiple numerically ordered [0153]; [0164] maximum allowable security ID, minimum allowable security ID; thus, the ECUs can have any security ID with security level). Neill further teaches boot code corresponding to ECU ([0153] each core its own security mode for operation which determines the security ID; thus, each core is configured by corresponding boot code). Neill in view of Kito does not teach, comparing, by the storage controller, a fourth boot code, stored in the first non-volatile memory with a fifth boot code stored in an external storage device; and providing, by the storage controller, the fourth boot code to the third ECU, based on a result of the comparing the fifth boot code with the fourth boot code. Mai et al teach a system where two boot codes are compared and providing a boot code based on the comparison (step 306 of Fig 3; Fig 3 [0036][0037]; boot code is provided when boot code are different [0037][0041]).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide copies of boot code and compare them to accept the more secured/updated copy since that way system is ensured to have a clean boot code. This ensures security.
Claim(s) 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Neill et al (US Patent Application Publication 20180004979), further in view of Mai et al (US Patent Application Publication 20080040596)
For claim 17, Neill teaches a security level of a second ECU, of the plurality of ECUs, is a second level (security level can be multiple numerically ordered [0153]; [0164] maximum allowable security ID, minimum allowable security ID; thus the ECUs can have any security ID with security level). Neill further teaches boot code corresponding to ECU ([0153] each core its own security mode for operation which determines the security ID; thus each core is configured by corresponding boot code). Neill does not teach comparing, by the storage controller, a second boot code, stored in the first non-volatile memory, with a third boot code stored in a second non-volatile memory; and providing, by the storage controller, the second boot code to the second ECU, based on a result of the comparing the third boot code with the second boot code. Mai et al teach a system where two boot codes are compared and providing a boot code based on the comparison (step 306 of Fig 3; Fig 3 [0036][0037]; boot code is provided when boot code are different [0037][0041]). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide copies of boot code and compare them to accept the more secured/updated copy since that way system is ensured to have a clean boot code. This ensures security.
For claim 18, Neill teaches, when a security level of a third ECU, of the plurality of ECUs, is a third level (security level can be multiple numerically ordered [0153]; [0164] maximum allowable security ID, minimum allowable security ID; thus, the ECUs can have any security ID with security level). Neill further teaches boot code corresponding to ECU ([0153] each core its own security mode for operation which determines the security ID; thus, each core is configured by corresponding boot code). Neill does not teach, comparing, by the storage controller, a fourth boot code, stored in the first non-volatile memory with a fifth boot code stored in an external storage device; and providing, by the storage controller, the fourth boot code to the third ECU, based on a result of the comparing the fifth boot code with the fourth boot code. Mai et al teach a system where two boot codes are compared and providing a boot code based on the comparison (step 306 of Fig 3; Fig 3 [0036][0037]; boot code is provided when boot code are different [0037][0041]). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide copies of boot code and compare them to accept the more secured/updated copy since that way system is ensured to have a clean boot code. This ensures security.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAHMIDA RAHMAN whose telephone number is (571)272-8159. The examiner can normally be reached Monday - Friday 10 AM - 7 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, Andrew Jung can be reached at 571-270-3779. 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.
/FAHMIDA RAHMAN/Primary Examiner, Art Unit 2175