Prosecution Insights
Last updated: October 25, 2026
Application No. 18/825,669

METHOD OF IMPROVING SECURITY OF ON-CHIP SYSTEMS AND CORRESPONDING SYSTEM

Non-Final OA §102
Filed
Sep 05, 2024
Priority
Oct 20, 2023 — IT 102023000021996
Examiner
MERCADO VARGAS, ARIEL
Art Unit
2118
Tech Center
2100 — Computer Architecture & Software
Assignee
STMicroelectronics N.V.
OA Round
1 (Non-Final)
72%
Grant Probability
Favorable
1-2
OA Rounds
1y 1m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 72% — above average
72%
Career Allowance Rate
341 granted / 477 resolved
+16.5% vs TC avg
Strong +28% interview lift
Without
With
+28.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 3m
Avg Prosecution
20 currently pending
Career history
504
Total Applications
across all art units

Statute-Specific Performance

§101
13.8%
-26.2% vs TC avg
§103
47.9%
+7.9% vs TC avg
§102
13.2%
-26.8% vs TC avg
§112
16.6%
-23.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 477 resolved cases

Office Action

§102
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This is a response to U.S. Patent application No. 18/825,669 filed on 09/05/2024 in which Claims 1 – 20 were filed for examination. Examiner Note The Examiner cites particular columns, line numbers and/or paragraph numbers in the references as applied to the claims below for the convenience of the Applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. Information Disclosure Statement The information disclosure statement (IDS) submitted on 09/05/2024 have been entered and considered by the examiner. Claim Rejections - 35 USC § 102 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 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. (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claims 1 – 20 are rejected under 35 U.S.C. 102(a)(1)/102(a)(2) as being anticipated by O’Loughlin et al. (US 2012/0102334) (hereinafter, O’Loughlin) cited in IDS dated 01/08/2024. Regarding Claim 1, O’Loughlin teaches a method (See O’Loughlin’s par 0466), comprising: manufacturing a system-on-chip (SoC) including a memory with a security feature (O’Loughlin in par 0004, teaches that a wide variety of consumer and commercial products today is a System-on-Chip (SoC) where many features are integrated on a single silicon die. Manufacturers may use the same SoC in different platforms with various features enabled/disabled in order to differentiate the final products in the market) configured to be enabled either in response to a set of SoC pads being asserted to respective security enablement values or, in response to a security key location in the memory having stored therein a key different from a security disablement key (O’Loughlin in par 0110 – 0111, further teaches that the ACC 12 is typically embedded in a SOC die, which is then packaged into a chip which is mounted on a printed circuit board (PCB) and eventually assembled into an electronic device 14. The ACC 12 has a set of output ports, and evaluating the aggregate of these outputs indicates which features are to be enabled and which are to be disabled. The ACC 12 is designed to manage access to non-volatile memory (NVM) and to protect certain regions of the NVM from being accessed by unauthorized agents 20. O’Loughlin in par 0220, further teaches that the ACC 12 should utilize a very small total silicon area, and should support on-chip (self contained in ACC 12) generation of a UID, and on-chip generation and storage of ECC public-private key pairs. Enablement/disablement of scan chain testing of the ACC 12 should be available prior to ACC ECC key pair generation to prevent the private key from being revealed); performing electrical wafer sorting (EWS) of the SoC, during which the security feature is disabled in response to a configuration of respective disablement values being applied to the set of SoC pads while, with the security feature disabled, the security key location in the memory being configured to have written therein a candidate disablement key (O’Loughlin in par 0095, teaches that the controller 22 enables and disables service modules to enable different service products to be defined, e.g. for serialization, key injection, feature activation, etc. O’Loughlin in par 0239, teaches that when the ACC 12 receives a cmd[EXITTEST], software then causes a transition from the Test State to the Initialization State. As a result of this transition, the hardware can determine that it is no longer in the Test State and disables DFT features until it is enabled again. O’Loughlin in par 0245, further teaches The cmd[EXITTEST] causes the ACC 12 to disable all DFT features, and transition to the Initialization State 80, before issuing a soft reset. Disabling DFT features prevents an adversary from using those features to tamper with the SoC without authorization. The DFT features are left disabled until they are explicitly enabled with a FCT 50 issued by an authenticated appliance 18 later on in the Functional State 84. O’Loughlin in par 0382, further teaches At some point, APPj issues a cmd [EXITTEST] at 1) to signal that a basic set of tests has finished successfully and now ACC, should start to disable some DFT features. When ACC, sees [EXITTEST], it a) writes 0's to the FEAT register to disable DFT features, b) changes the Life Cycle State in NVM 62 to the Initialization State 82, and issues a soft reset at 2); and in response to performing the EWS, forcing the set of SoC pads to respective non-transitory security enablement values that enable the security feature, subsequent disablement of the security feature remaining facilitated in response to the candidate disablement key being found to match the security disablement key (O’Loughlin in par 0210 – 0211, further teaches that the shared secret generated (e.g. kij) is the basis and prerequisite for symmetric key cryptography, that is, it is used to establish a highly tamper resistant encrypted and authenticated communication channel 29 between the two parties. O’Loughlin in par 0220, further teaches that enablement/disablement of scan chain testing of the ACC 12 should be available prior to ACC ECC key pair generation to prevent the private key from being revealed. Authentication/integrity protection of commands from the appliance 18 to the ACC 12 should be provided, and security-critical commands should be unique to a specific ACC 12. O’Loughlin in par 0239, teaches that when the ACC 12 receives a cmd, software then causes a transition from the Test State to the Initialization State. As a result of this transition, the hardware can determine that it is no longer in the Test State and disables DFT features until it is enabled again. O’Loughlin in par 0245, further teaches that the cmd causes the ACC 12 to disable all DFT features, and transition to the Initialization State 80, before issuing a soft reset. Disabling DFT features prevents an adversary from using those features to tamper with the SoC without authorization. The DFT features are left disabled until they are explicitly enabled with a FCT 50 issued by an authenticated appliance 18 later on in the Functional State 84. O’Loughlin in par 0246, further teaches the initialization State 82--In this state the ACC 12 generates its static key pair. The x-coordinate of the public static key may then be used as the ACC's UID. When this has been done, the ACC 12 can update the non-volatile life cycle state so that the next boot will proceed to the Functional State 84). Regarding Claim 2, O’Loughlin teaches the limitations contained in parent Claim 1. O’Loughlin further teaches: further comprising: copying, by an SoC boot feature, the candidate disablement key into a register (O’Loughlin in par 0085, further teaches that the controller 22 and appliances 18 comprises hardware security modules (HSMs) 19 to perform sensitive and high trust computations, store sensitive information such as private keys, perform other cryptographic operations, and establish secure connections between components. O’Loughlin in par 0252, further teaches that Boot/Start up--As shown in FIG. 55, at every ACC 12 restart, the microcontroller 54 embedded in the ACC 12 automatically starts executing firmware boot code upon power up or coming out of reset. The firmware program should always begin executing the boot sequence in the following order: 1) Perform some necessary low level register initializations and configurations; 2) Read the feature enablement list stored in NVM 62 and determine which features needs to be enabled or disabled, then drive the appropriate feature enable signals); and comparing the candidate disablement key copied into the register with the security disablement key (O’Loughlin in par 0111, teaches that the ACC 12 can also provide self-contained generation of keys used to open up a secure communication channel with a trusted server. The ACC 12 should ensure that the enabling and disabling of features are done using trusted equipment by trusted sources and the ACC 12 should be able to initiate or disable device self tests and heath checks to make sure the device 14 has not been tampered with. O’Loughlin in par 0144, further teaches that during importation of the particular key type 138, if the key identifier is used, then the key identifier of the key will be compared to all previously imported key identifiers for that key type 138. It may be noted that this mechanism does not protect against a key file being used again for another key type and thus should be prevented using operational rules). Regarding Claim 3, O’Loughlin teaches the limitations contained in parent claim 2. O’Loughlin further teaches: wherein the subsequent disablement of the security feature is facilitated in response to the comparing indicating that the candidate disablement key copied into the register matches the security disablement key (O’Loughlin in par 0210, further teaches that the appliance 18 and ACC 12 can also participate in an ECMQV key agreement scheme, which generates a secret key that is known only to the two parties involved. The shared secret generated (e.g. kij) is the basis and prerequisite for symmetric key cryptography, that is, it is used to establish a highly tamper resistant encrypted and authenticated communication channel 29 between the two parties. O’Loughlin in par 0212, further teaches that the lack of privileges can be used negatively to disable non-authorized features in a suspect device, whether it being a clone, a counterfeit or otherwise stolen device). Regarding Claim 4, O’Loughlin teaches the limitations contained in parent claim 2. O’Loughlin further teaches: wherein the subsequent disablement of the security feature is countered in response to the comparing indicating that the candidate disablement key copied into the register fails to match the security disablement key (O’Loughlin in par 0111, teaches that the ACC 12 is designed to manage access to non-volatile memory (NVM) and to protect certain regions of the NVM from being accessed by unauthorized agents 20. O’Loughlin in par 0212, further teaches that the lack of privileges can be used negatively to disable non-authorized features in a suspect device, whether it being a clone, a counterfeit or otherwise stolen device). Regarding Claim 5, O’Loughlin teaches the limitations contained in parent claim 2. O’Loughlin further teaches: wherein comparing the candidate disablement key copied into the register with the security disablement key comprises comparing the candidate disablement key copied into the register with a hard-wired version of the security disablement key (O’Loughlin in par 0332, teaches that the ROM 60 code health check involves running a CRC-32 on the entire ROM 60 content and comparing that against a hardwired check sum. This is a simple check to make sure the ROM 60 is accessible and fault-free; it is not meant to secure the ROM 60 code from being tampered with). Regarding Claim 6, O’Loughlin teaches the limitations contained in parent claim 1. O’Loughlin further teaches: further comprising manufacturing the SoC with the security feature configured to be enabled in response to the set of SoC pads being coupled to respective pull-up and pull-down drivers (O’Loughlin in par 0236 – 0239, further teaches that the software MBIST of the RAM 60 and NVM 62 can be initiated by a command issued by the tester 16. Partial scan chain testing inserted for the registers inside the ACC 12, initiated and controlled by the tester 16. JTAG Boundary scan is used to test the primary I/O of the IC 40. This is added security to make sure the ACC 12 was not disconnected, which might be an indication of an attack. All ACC 12 DFT features are controlled by the ACC's own TAP controller 72 and, as such, the hardware should be designed so that the DFT features can be enabled and disabled based on the state of the ACC 12. An uninitialized ACC 12 powers up into a Test State and has DFT features enabled by default. When the ACC 12 receives a cmd, software then causes a transition from the Test State to the Initialization State. As a result of this transition, the hardware can determine that it is no longer in the Test State and disables DFT features until it is enabled again). Regarding Claim 7, O’Loughlin teaches the limitations contained in parent claim 1. O’Loughlin further teaches: wherein the security key location in the memory is locked against writing therein in response to the security feature being enabled (O’Loughlin in par 0221, further teaches that the ACC 12 may function as a protocol enforcer--if the received commands are invalid, the ACC 12 can reject them and optionally shut down if a threshold of invalid commands were attempted. There should also be the ability to ensure that once the ACC 12 is locked out, (as in the case when the device is to be retired permanently, or if the system 12 detects the device has been tampered with,) the ACC 12 cannot be re-enabled. When not in use, the ACC 12 should be capable of powering down to very low current drain, and the ACC 12 operation should not rely on external (off-core) firmware or an external CPU to perform its basic functions). Regarding Claim 8, O’Loughlin teaches the limitations contained in parent claim 1. O’Loughlin further teaches: wherein external host access to the SoC is countered in response to the security feature being enabled (O’Loughlin in par 0121, teaches that privileges can be used to positively enable features at test and manufacture time, or enable features upon reconnecting to a server or device programmer 26 in the after-market. The lack of privileges can be used negatively to disable non-authorized features in a suspect device, whether it being a clone, a counterfeit or otherwise stolen device. O’Loughlin in par 0248, further teaches Lock-Out State 86--This state may be reached if the ACC 12 has encountered one of the following conditions: i) been issued the cmd [LOCKOUT], ii) detected and exceeded a maximum number of allowed errors, iii) detected an unrecoverable error. The lock-out mechanism is intended to be a deterrent against repeated attempts to attack the ACC 12 and the entire system 10 as a whole. Once the ACC 12 is in the Lock-Out state 86, the ACC 12 ceases to process additional commands). Regarding Claim 9, O’Loughlin teaches the limitations contained in parent claim 1. O’Loughlin further teaches: wherein forcing the set of SoC pads to the respective non-transitory security enablement values comprises forcing the set of SoC pads to a fixed voltage value or ground (O’Loughlin in par 0095, teaches that the controller 22 in this example runs on server hardware, e.g. a Dell 2950 PowerEdge 2U rack mount server using a 2 x Intel Xeon quad core 5300 processor @ 3 GHz. The controller 22 can also use a 110/220 V 750 W redundant power module. O’Loughlin in par 0221, further teaches that when not in use, the ACC 12 should be capable of powering down to very low current drain, and the ACC 12 operation should not rely on external (off-core) firmware or an external CPU to perform its basic functions). Regarding Claim 10, O’Loughlin teaches the limitations contained in parent claim 1. O’Loughlin further teaches: wherein forcing the set of SoC pads to the respective non-transitory security enablement values comprises coupling the set of SoC pads to a redistribution layer on the SoC (O’Loughlin in par 0100, teaches that controller-to-appliance communications should be secure, e.g. using an SSL connection, protected and mutually authenticated. O’Loughlin in par 0201, further teaches that the agent 20 comprises a transport layer API with which the appliance 18 may be used to issue commands and receive responses to/from the ACC 12). Regarding Claim 11, O’Loughlin teaches the limitations contained in parent claim 1. O’Loughlin further teaches: further comprising erasing the security key location in the memory prior to writing therein the candidate disablement key (O’Loughlin in par 0230, teaches that the NVM interface 70 provides abstraction and should have the capability of writing, rewriting and erasing the UID in a secure manner that is easily adapted to a proprietary NVM interface protocol. O’Loughlin in par 0161, further teaches that a feature activation product may be modified/deleted on the controller 22 if it is not bound to any appliance 18 and features may be modified/deleted on the controller 22 if it is not assigned to any feature activation product). Regarding Claim 12, this Claim merely recites a wafer-sorted system-on-chip (SoC) comprising instructions as similarly recited in Claim 1. Accordingly, O’Loughlin discloses/teaches every limitations of Claim 12 as indicated in the above rejection of Claim 1. Regarding Claim 13, this Claim merely recites a wafer-sorted system-on-chip (SoC) comprising instructions as similarly recited in Claims 2 – 4 . Accordingly, O’Loughlin discloses/teaches every limitations of Claim 13 as indicated in the above rejection of Claims 2 – 4. Regarding Claim 14, this Claim merely recites a wafer-sorted system-on-chip (SoC) comprising instructions as similarly recited in Claim 5. Accordingly, O’Loughlin discloses/teaches every limitations of Claim 14 as indicated in the above rejection of Claim 5. Regarding Claim 15, this Claim merely recites a wafer-sorted system-on-chip (SoC) comprising instructions as similarly recited in Claim 6. Accordingly, O’Loughlin discloses/teaches every limitations of Claim 15 as indicated in the above rejection of Claim 6. Regarding Claim 16, this Claim merely recites a wafer-sorted system-on-chip (SoC) comprising instructions as similarly recited in Claim 7. Accordingly, O’Loughlin discloses/teaches every limitations of Claim 16 as indicated in the above rejection of Claim 7. Regarding Claim 17, this Claim merely recites a wafer-sorted system-on-chip (SoC) comprising instructions as similarly recited in Claim 8. Accordingly, O’Loughlin discloses/teaches every limitations of Claim 17 as indicated in the above rejection of Claim 8. Regarding Claim 18, this Claim merely recites a wafer-sorted system-on-chip (SoC) comprising instructions as similarly recited in Claim 9. Accordingly, O’Loughlin discloses/teaches every limitations of Claim 18 as indicated in the above rejection of Claim 9. Regarding Claim 19, this Claim merely recites a wafer-sorted system-on-chip (SoC) comprising instructions as similarly recited in Claim 10. Accordingly, O’Loughlin discloses/teaches every limitations of Claim 19 as indicated in the above rejection of Claim 10. Regarding Claim 20, this Claim merely recites a wafer-sorted system-on-chip (SoC) comprising instructions as similarly recited in Claim 11. Accordingly, O’Loughlin discloses/teaches every limitations of Claim 20 as indicated in the above rejection of Claim 11. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIEL MERCADO VARGAS whose telephone number is (571)270-1701. The examiner can normally be reached M-F 8:00am - 4: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, Scott Baderman can be reached at 571-272-3644. 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. /ARIEL MERCADO-VARGAS/Primary Examiner, Art Unit 2118
Read full office action

Prosecution Timeline

Sep 05, 2024
Application Filed
Oct 13, 2026
Non-Final Rejection mailed — §102 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12769929
INFORMATION PROCESSING APPARATUS, NON-TRANSITORY COMPUTER READABLE MEDIUM, AND METHOD FOR DEFINING AN ARITHMETIC EXPRESSION USING FEATURE AND ARRANGEMENT INFORMATION
4y 2m to grant Granted Oct 20, 2026
Patent 12767062
INPUT DEVICE
2y 5m to grant Granted Oct 20, 2026
Patent 12759237
A PRINTER FOR PRINTING A 3D OBJECT BASED ON A COMPUTER MODEL
2y 11m to grant Granted Oct 13, 2026
Patent 12752442
METHODS AND APPARATUSES FOR ACQUIRING LEARNING DATA
5y 0m to grant Granted Oct 06, 2026
Patent 12753927
METHOD, COMPUTER PROGRAM AND CONTROL DEVICE FOR CONTROLLING A COOKING APPLIANCE AND COOKING APPLIANCE SYSTEM
3y 5m to grant Granted Oct 06, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
72%
Grant Probability
99%
With Interview (+28.3%)
3y 3m (~1y 1m remaining)
Median Time to Grant
Low
PTA Risk
Based on 477 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month