DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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) 1-3, 5, 7, 8, 10-13, 15, 17-19 and 23-25 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by “Investigating TrustZone: A Comprehensive Analysis” henceforth referred to as Zhu et al.
Consider claim 1, Zhu et al. discloses a security partitioned microcontroller, comprising: a primary processor; one or more peripherals, a memory coupled to the primary processor, wherein the memory is segmented into a trusted portion and a non-trusted portion, the memory having stored thereon a first set of instructions in the trusted portion and a second set of instructions in the non-trusted portion, the first set of instructions comprising driver code and an application programming interface (API) for accessing the one or more peripherals; and a co-processor configured to: in response to booting the security partitioned microcontroller, scan the trusted portion of the memory for the first set of instructions, and allow the primary processor to boot in response to determining that the first set of instructions is present in the trusted portion of the memory, wherein the driver code, when executed by the primary processor, causes the primary processor to monitor usage of the one or more peripherals, generate usage metrics representing the usage of the one or more peripherals, and communicate the usage metrics to a provider of the microcontroller (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, section 4.1 first three paragraphs, Zhu et al. discloses a hardware based security architecture where the hardware is divided into a trusted and non-trusted worlds including processing, memory, interrupt control and peripherals. Trusted applications are in the trusted memory and client application are in the non-trusted memory. Booting is based on trusted applications using a trusted CPU. Zhu et al. discloses trusted peripherals with a trusted API and device driver. Zhu et al. discloses monitoring kernel integrity, which includes trusted peripherals, and announce problems. Peripherals have their usage monitored as being trusted or not. Trusted peripherals are isolated. Trusted peripherals are ensured to prevent unauthorized accesses, manifest files are used to log misbehavior with respect to a trusted peripheral.).
Consider claim 2, Zhu et al. discloses the microcontroller of Claim 1, wherein the first set of instructions and the second set of instructions, when executed by the primary processor, cause the primary processor to: create a trusted execution environment and execute the first set of instructions within the trusted execution environment, and create a non-trusted execution environment and execute the second set of instructions within the non-trusted execution environment (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, Zhu et al. discloses a hardware based security architecture where the hardware is divided into a trusted and non-trusted worlds including processing, memory, interrupt control and peripherals.).
Consider claim 3, Zhu et al. discloses the microcontroller of Claim 2, wherein the first set of instructions are pre-flashed into the trusted portion of the memory (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, Zhu et al. discloses a trusted memory space including a ROM for security boot program code and memory space containing trusted application.).
Consider claim 5, Zhu et al. discloses the microcontroller of Claim 2, further comprising a hardware-based access controller that segments the memory into the trusted portion and the non-trusted portion wherein the hardware-based access controller is configured to prevent access to the one or more peripherals from the non-trusted execution environment (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, Zhu et al. discloses trusted peripherals with a trusted API and device driver.).
Consider claim 7, Zhu et al. discloses the microcontroller of Claim 2, wherein the first set of instructions comprise a first sub-set of instructions provided by a provider of the microcontroller and a second sub-set of instructions provided by a user (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, section 7.2 first paragraph: Zhu et al. discloses storing trusted applications, security boot program and the downloading of new security applications.).
Consider claim 8, Zhu et al. discloses the microcontroller of Claim 2, wherein the second set of instructions, when executed by the primary processor, cause the primary processor to: call functionality from the non-trusted execution environment to instruct the co-processor to load a third set of instructions into the trusted execution environment of the primary processor (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, section 7.2 first paragraph: Zhu et al. discloses transferring data between TEE and REE to have TEE perform some function.).
Consider claim 10, Zhu et al. discloses the microcontroller of Claim 2, wherein the trusted execution environment comprises: a memory-protection unit (MPU) configured to run the first set of instructions in a higher-privileged operating mode (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, section 4.1 first three paragraphs, section 4.1 first three paragraphs).
Consider claim 11, Zhu et al. discloses a method of using a security partitioned microcontroller, comprising: scanning, using a co-processor, a trusted portion of a memory of the security partitioned microcontroller for a first set of instructions in response to booting the security partitioned microcontroller, the microcontroller comprising one or more peripherals, the first set of instructions comprising driver code and an application programming interface (API) for accessing the one or more peripherals; allowing, using the co-processor, a primary processor of the security partitioned microcontroller to boot in response to determining that the first set of instructions is present in the trusted portion of the memory; monitoring, using the driver code executed by the primary processor, usage of the one or more peripherals; generating usage metrics representing the usage of the one or more peripherals, and communicating the usage metrics to a provider of the microcontroller (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, section 4.1 first three paragraphs, Zhu et al. discloses a hardware based security architecture where the hardware is divided into a trusted and non-trusted worlds including processing, memory, interrupt control and peripherals. Trusted applications are in the trusted memory and client application are in the non-trusted memory. Booting is based on trusted applications using a trusted CPU. Zhu et al. discloses trusted peripherals with a trusted API and device driver. Zhu et al. discloses monitoring kernel integrity, which includes trusted peripherals, and announce problems. Peripherals have their usage monitored as being trusted or not. Trusted peripherals are isolated. Trusted peripherals are ensured to prevent unauthorized accesses, manifest files are used to log misbehavior with respect to a trusted peripheral.).
Consider claim 12, Zhu et al. discloses the method of Claim 11, further comprising: creating, using the primary processor, a trusted execution environment and execute the first set of instructions within the trusted execution environment; and creating, using the primary processor, a non-trusted execution environment and execute a second set of instructions within the non-trusted execution environment, the second set of instructions being stored in a non-trusted portion of the memory (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, Zhu et al. discloses a hardware based security architecture where the hardware is divided into a trusted and non-trusted worlds including processing, memory, interrupt control and peripherals.).
Consider claim 13, Zhu et al. discloses the method of Claim 11, wherein the first set of instructions are pre-flashed into the trusted portion of the memory (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, Zhu et al. discloses a trusted memory space including a ROM for security boot program code and memory space containing trusted application.).
Consider claim 15, Zhu et al. discloses the method of Claim 12, further comprising: preventing access, using a hardware-based access controller of the microcontroller that segments the memory into the trusted portion and the non-trusted portion, to the one or more peripherals from the non-trusted execution environment (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, Zhu et al. discloses trusted peripherals with a trusted API and device driver.).
Consider claim 17, Zhu et al. discloses a non-transitory computer-readable memory having stored thereon instructions that, when executed by a microcontroller, cause the microcontroller to: scan, using a co-processor of the microcontroller, a trusted portion of a memory of the microcontroller for a first set of instructions in response to booting the microcontroller, the microcontroller comprising one or more peripherals, the first set of instructions comprising driver code and an application programming interface (API) for accessing the one or more peripherals; allow, using the co-processor, a primary processor of the microcontroller to boot in response to determining that the first set of instructions is present in the trusted portion of the memory; monitor, using the driver code executed by the primary processor, usage of the one or more peripherals; generate usage metrics representing the usage of the one or more peripherals; and communicate the usage metrics to a provider of the microcontroller (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, section 4.1 first three paragraphs, Zhu et al. discloses a hardware based security architecture where the hardware is divided into a trusted and non-trusted worlds including processing, memory, interrupt control and peripherals. Trusted applications are in the trusted memory and client application are in the non-trusted memory. Booting is based on trusted applications using a trusted CPU. Zhu et al. discloses trusted peripherals with a trusted API and device driver. Zhu et al. discloses monitoring kernel integrity, which includes trusted peripherals, and announce problems. Peripherals have their usage monitored as being trusted or not. Trusted peripherals are isolated. Trusted peripherals are ensured to prevent unauthorized accesses, manifest files are used to log misbehavior with respect to a trusted peripheral.).
Consider claim 18, Zhu et al. discloses the non-transitory computer readable memory of Claim 17, wherein the instructions, when executed by the microcontroller, cause the microcontroller to: create, using the primary processor, a trusted execution environment and execute the first set of instructions within the trusted execution environment; and create, using the primary processor, a non-trusted execution environment and execute a second set of instructions within the non-trusted execution environment, the second set of instructions being stored in the non-trusted portion of the memory (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, Zhu et al. discloses a hardware based security architecture where the hardware is divided into a trusted and non-trusted worlds including processing, memory, interrupt control and peripherals.).
Consider claim 19, Zhu et al. discloses the non-transitory computer readable memory of Claim 17, wherein the first set of instructions are pre-flashed into the trusted portion of the memory (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, Zhu et al. discloses a trusted memory space including a ROM for security boot program code and memory space containing trusted application.).
Consider claim 23, Zhu et al. discloses the method of Claim 12, wherein the first set of instructions comprise a first sub-set of instructions provided by a provider of the microcontroller and a second sub-set of instructions provided by a user (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, section 7.2 first paragraph: Zhu et al. discloses storing trusted applications, security boot program and the downloading of new security applications.).
Consider claim 24, Zhu et al. discloses the method of Claim 12, further comprising: calling functionality from the non-trusted execution environment to instruct the co-processor to load a third set of instructions into the trusted execution environment of the primary processor (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, section 7.2 first paragraph: Zhu et al. discloses transferring data between TEE and REE to have TEE perform some function.).
Consider claim 25, Zhu et al. discloses the non-transitory computer readable memory of Claim 18, wherein the first set of instructions comprise a first sub-set of instructions provided by a provider of the microcontroller and a second sub-set of instructions provided by a user (Page 2 col. 1 last 10 lines of the first big paragraph and following small paragraph, section 2.1-2.3, Fig. 1-3, section 3, section 7.2 first paragraph: Zhu et al. discloses storing trusted applications, security boot program and the downloading of new security applications.).
Allowable Subject Matter
Claims 9, 21 and 22 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed 5/15/2026 have been fully considered but they are not persuasive. The arguments pertain to the claim amendments that now include moved up claim limitations from dependent claims. The examiner has addressed these limitations in the appropriate claim rejections above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL ALSIP whose telephone number is (571)270-1182. The examiner can normally be reached M-F 9-5.
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, Reginald G. Bragdon can be reached at (571)272-4204. 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.
/MICHAEL ALSIP/Primary Examiner, Art Unit 2139
Prosecution Insights