DETAILED ACTION
This Office Action is in response to claims filed on 01/28/2026
Claims 1-19 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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 6, 12, and 16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4-6, 8, 10-12, 14-16, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Restuccia et al. "Aker A Design and Verification Framework for Safe and Secure SoC Access Control" (hereinafter Restuccia) in view of Basak et al. “A Flexible Architecture for Systematic Implementation of SoC Security Policies” (hereinafter Basak).
With regard to claim 1, Restuccia teaches a multi-processor system-on-chip, comprising (Pg. 2, An SoC architecture consists of a set of control devices accessing a set of peripheral devices):
an execution domain processor (Pg. 2, Figure 1 shows an SoC interconnect architecture with N controllers C (C.sub.1, …, C.sub.n) each with a manager interface) that is configured to run a first execution domain by accessing one or more system-on-chip resources (Pg. 2, A controller C.sub.i can initiate a transaction to a shared peripheral P.sub.j issuing an address request through its AXI M interface. The address request is routed to the peripheral P.sub.j by the AXI interconnect. P.sub.j is accessible by C.sub.i through a unique set of contiguous addresses, also called peripheral address region. P.sub.j serves the received requests providing the required data (read request) or accepting the write data and replying with a write response (write request);
a first control point processor that is physically and programmatically independent from the execution domain processor (Pg. 1, AKER access control system easily integrate with a Hardware Root of Trust (HRoT) for runtime monitoring and management of the controllers; Fig. 2, Examiner notes: The trusted entity (TE), as used herein is synonymous with the HRoT, is physically and programmatically independent from the SoC controllers C.sub.1 to C.sub.n) and configured to generate a first runtime isolation control data stream for controlling access (Pg. 5, One of the key features of Aker access control system is the simple and fast setup of the local access control policy of the ACWs. This can be setup once in static configuration (e.g., at boot time) or managed at runtime by a TE … Unlike the IP-level verification, the ACW’s local access control policy LACP can be configured dynamically and at runtime by the TE … we develop security requirements addressing the existence and the content of information flows between the TE and the ACW’s configuration and anomaly registers) to the one or more system-on-chip resources by the first execution domain by identifying at least a first system-on-chip resource that the first execution domain is allowed to access (Pg. 2-3, Each memory request issued by C.sub.i is checked against the configuration of the LACP.sub.i; if the request is fully contained in at least one of the LACP.sub.i’s address regions, the request is considered legal by ACW.sub.i and allowed to propagate the AXI interconnect);
an access control circuit connected between the execution domain and the one or more system-on-chip resources (Pg. 3, Fig. 3; Fig. 3: ACW.sub.i architecture: C.sub.i is the controller module using an AXI M interface (Examiner notes: The AXI M interface is a programmable access control circuit coupling the controller and the peripheral interconnect). Regs are the configuration registers holding LACP.sub.i. The AXI S interface is connected to the HRoT) and configured to provide a dynamic runtime isolation barrier in response to the first runtime isolation control data stream (Pg. 2, The Access Control Wrapper (ACW) is a configurable access control module designed to monitor an AXI-compliant controller … each untrusted controller Ci is wrapped by an ACW module ACW.sub.i; Pg. 3, Reset mode: the initial state of ACW.sub.i. It is awaiting configuration with a valid LACP.sub.i. Any request issued by Ci is blocked and does not propagate to the interconnect. Once LACP.sub.i is configured, ACW.sub.i moves to supervising mode), thereby controlling access to the one or more system-on-chip resources by the first execution domain (Pg. 3, Supervising mode: the normal operating mode of the ACW.sub.i. Each address request issued by C.sub.i is compared against the store LACP.sub.i. Legal requests are propagated to the AXI interconnect; illegal requests are denied and never reach the AXI interconnect)
where the access control circuit is configured to generate feedback data in response to any blocked access by the first execution domain (Pg. 3, Decouple mode: An illegal request has occurred. ACW.sub.i saves diagnostic information about the illegal request into its internal anomalies register. ACW.sub.i raises an interrupt to notify the TE of the illegal access attempt), and wherein the first control point processor is configured to generate updated runtime isolation control data stream for controlling access to the one or more system-on-chip resources by the first execution domain in response to the feedback (Pg. 3, Readmission policy: The TE can analyze the diagnostic information internal to ACW.sub.i and perform recovery operations on C.sub.i before switching back to supervising mode and thereby readmitting C.sub.i to communicate to the SoC. Examples of recovery operations are resetting, reconfiguring, or even reprogramming C.sub.i), and
wherein the first control point processor is connected to configure the access control circuit with the first runtime isolation control data stream to specify (Pg. 5, 1) Create threat model: In this scenario, out threat model assumes that the ACW, the TE, and P are trusted, C is untrusted, and therefore, C’s ability to communicate with P via the ACW in a manner which does not adhere to the dynamically configured LACP is a threat)
Restuccia reasonably teaches a first control point process connected to an access control circuit to configure a runtime isolation control data stream. However, Restuccia does not explicitly teach the first control point processor configuring access of interrupt requests entering an execution domain to be processed by the domain.
In a similar field of endeavor, Basak additionally teaches wherein the first control point processor (Pg. 538, Security wrappers extract security-critical events from the operating states of the underlying IP for communication with the E-IIPS (Examiner notes: E-IIPS interpreted as the Trusted Entity of Restuccia); Table I, Representative Set of Security Critical Events According to IP Type … Memory IP, Processor Core, Communication Core, Hard Logic Custom IP (Examiner notes: Such that different SoC resources may be associated with “Intellectual Property” execution domains. See Pg. 536)) is connected to configure the access control circuit (Pg. 538, We develop security wrappers on IPs that incorporate “smartness” to detect security-critical events of interest in the IP while providing both a standard communication between the IP and the E-IIPS and a standard template-based design that can be easily integrated on top of the IP implementation.) with the first runtime isolation control data stream (Pg. 539, Our security wrapper design is frame-based, with a standard format for security-critical event definitions, which can be instantiated into corresponding events for specific IPs) to specify one or more interrupt requests the execution domain processor (Table II, Policies for Usage Case Analysis … Access Control, Prevent DMA Access to system level addresses; FIG. 6, Flow/message diagram representation of implementation of case II, Wherein an address sent through Request.sub.mem_cnt interface of a memory controller is analyzed; Pg. 542, As illustrated in FIG. 6, E-IIPS configures the IP-specific system-level address ranges at boot time in memory controller through its security wrapper (MCW). When an access from the DMA controller is detected by MCW, the request address is checked with the system specific ranges inside the wrapper logic) that are allowed to enter the first execution domain to be processed by the first execution domain (FIG. 6, If the DMA access request specifies an address that is not in system range, Memory controller wrapper allows access to memory bus; Pg. 542, In case of no violation, the system memory bus is granted for DMA).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Basak with the teachings of Restuccia in order to provide a system that teaches configuration of the access control circuit for the first execution domain specifying interrupt requests that are allowed to be processed. The motivation for applying Basak teaching with Restuccia teaching is to provide a system that allows for a plurality of custom security policies to be defined for a particular system-on-chip resource, thereby protecting the system-on-chip resource such that improves the general functionality of the system-on-chip while maintaining the security of the system through policy restrictions (Basak, Pg. 542). Restuccia and Basak are analogous art directed towards system-on-chip access control arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Basak with Restuccia to teach the claimed invention in order to provide support for interrupt handling on an execution domain processor configured by a control point processor.
With regard to claim 2, Restuccia teaches where the one or more system-on-chip resources comprise an addressable memory and one or more peripherals (Fig. 1, An SoC on-chip interconnect architecture composed of … L peripheral modules (P); Pg. 2, This allows them to autonomously and concurrently communicate with shared peripheral resources available on the SoC, e.g., a DRAM memory controller, on-chip memories (Examiner notes: addressable memory), ROM, IP core control and status register (CSRs), and GPIOs (Examiner notes: peripheral modules of Fig. 1)
With regard to claim 4, Restuccia teaches where the first control point processor is connected to configured the access control circuit with the first runtime isolation control data stream to specify an approved memory address range where the first execution domain is allowed to access a system-on-chip memory resource (Pg. 3, Figure 3 shows a representation of the internals of the ACW.sub.i. The following discusses how ACW.sub.i behaves on read and write transactions. ACW is compatible with any AXI-compliant request. When C.sub.i issues a read request AR through its M interface, ACW.sub.i has the following behaviors: Address Check: Check AR against LACP.sub.i by comparing the address of AR against each of the allowable read regions … When C.sub.i issues a write request AW, ACW.sub.i behaves in a similar manner as the read request using AW instead of AR).
With regard to claim 5, Restuccia teaches where the first control point processor is connected to configured the access control circuit with the first runtime isolation control data stream to specify a system-on-chip peripheral device that the first execution domain is allowed to access (Pg. 6, Having verified the security of ACW’s interactions at the IP level and firmware level, we now use our six-step process to validate the security of the interactions between multiple ACW-wrapped controllers and several shared SoC resources … This scenario corresponds to an architecture from Figure 2 when N = 2 and L = 3. The LACP.sub.1 of ACW.sub.1 states that C.sub.1 can read from all regions of R.sub.1 = {P.sub.1, and P.sub.2} and write to all regions of W.sub.1 = {P.sub.1}. The LACP.sub.2 of ACW.sub.2 states that C.sub.2 can read from all regions of R.sub.2 = {P.sub.3} and write to all regions of W.sub.2 = {P.sub.2, P.sub.3}).
With regard to claim 6, Basak teaches where the access control circuit (FIG. 6, Memory Controller Wrapper) is configured to forward to the execution domain processor (FIG. 1, Schematic of Proposed Architecture in a representative SoC (Examiner notes: Wherein each SoC module maintains an Access Control Wrapper, see Memory Controller)) received interrupts which are indicated as allowed interrupts (FIG. 6, Flow/message diagram representation of implementation of case II. (Examiner notes: Wherein the Memory Controller Wrapper allows DMA access requests to be forwarded to memory bus upon confirmation that an address is not within system range in accordance with access control policy)) by the first runtime isolation control data stream (Pg. 539, E-IIPS acts as the “security brain” of the SoC, providing programmable interface to different security policies. Its key functionality is to analyze events communicated by the security wrappers, determine the security state of the system and communicate IP-specific request and disable signals) and prevents received interrupts which are not indicated as allowed interrupts by the first runtime isolation control data from reaching the execution domain processor (FIG. 6, Flow/message diagram representation of implementation of case II. (Examiner notes: Wherein the Memory Controller Wrapper blocks DMA access requests to be forwarded to memory bus upon violation of memory address within system range in accordance with access control policy); Pg. 542, As illustrated in Fig. 6, E-IIPS configures the Ip-specific system-level address ranges at boot time in the memory controller through its security wrapper (MCW). When an access from the DMA controller is detected by MCW, the requested address is checked with the system specific ranges inside the wrapper logic. In case of no violation, the system memory bus is granted for DMA. In case of system address overlap, the request is blocked, the violation is logged as an event, and is communicated to E-IIPS through frames by MCW).
Rationale to claim 1 applied here.
Examiner notes: It would have been obvious for one of ordinary skill in the art to recognize that the access control circuit can be configured to allow and deny received interrupts in accordance with a particular resource policy from executing on the particular resource’s execution domain of claim 1 which would have yielded predictable results.
With regard to claim 8, Restuccia teaches where the first control point processor is configured to generate updated runtime isolation control data stream for controlling access to the one or more system-on-chip resources by the first execution domain (Pg. 3, ACW.sub.i holds a local access control policy LACP.sub.i, configured and maintained by TE … 3) Decouple Mode: an illegal request has occurred. ACW.sub.i saves diagnostic information about the illegal request into its internal anomalies registers. ACW.sub.i raises an interrupt to notify the TE of the illegal access attempt. Any further request from C.sub.i is blocked and the ACW.sub.i waits on the TE for readmission. Decoupling C.sub.i after an illegal attempt ensures TE can take appropriate actions on C.sub.i before the safe readmission of the module in the system. Readmission Policy: … recovery operations are resetting, reconfiguring, or even reprogramming C.sub.i (Examiner notes: such as the TE providing a new LACP).
With regard to claim 10, Restuccia teaches where the first runtime isolation control data stream generated by the first control point processor does not include a device identifier for the first control point processor (Pg. 3, ACW.sub.i holds a local access control policy LACP.sub.i configured and maintained by TE. LACP.sub.i describes the address regions legally accessible by C.sub.i, defining n.sub.r regions for read and n.sub.w regions for write operations. Each memory request issued by C.sub.i is checked against the configuration of LACP.sub.i (Examiner notes: such that the LACP configuration generated by the TE does not contain the device identifier for the TE).
With regard to claim 11, Restuccia teaches where the first control point processor is configured to generate the first runtime isolation control data stream before the execution domain processor is released from reset to run the first execution domain (Pg. 4, Requirement 1: C cannot receive/send data from/to P which originates while the ACW is in reset mode; Requirement 2: The configuration/anomaly resets are cleared and set to their default values while the ACW is actively being reset; Pg. 5, Requirement 3: The configuration/anomaly registers contain the default values until they are modified by the TE (config.) and/or ACW (illegal req. metadata tracking); Pg. 3, Reset Mode: the initial state of the ACW.sub.i. It is awaiting configuration with a valid LACP.sub.i. Any request issued by C.sub.i is blocked and does not propagate to the interconnect. Once LACP.sub.i is configured ACW.sub.i moves to Supervising Mode).
With regard to claim 12, Restuccia teaches a method for controlling operations of an execution domain on a multi-processor system-on-chip comprising (The access control system plays a critical role for ensuring safe and secure operation. Thus, it is important that any access control system undergo a rigorous verification process. Verification includes functional correctness. Additionally, and equally as important, it must undergo a security verification process that addresses potential security weaknesses or vulnerabilities. An exploit in the access control system endangers the confidentiality, integrity, and availability of the SoC.):
generating a runtime isolation control data stream by a control point processor for controlling access to one or more system-on-chip resources by an execution domain processor (Pg. 5, One of the key features of Aker access control system is the simple and fast setup of the local access control policy of the ACWs. This can be setup once in static configuration (e.g., at boot time) or managed at runtime by a TE … Unlike the IP-level verification, the ACW’s local access control policy LACP can be configured dynamically and at runtime by the TE … we develop security requirements addressing the existence and the content of information flows between the TE and the ACW’s configuration and anomaly registers), where the runtime isolation control data stream identifies at least a first system-on-chip resource that the execution domain processor is allowed to access and a second system-on-chip resource that the execution domain processor is not allowed to access (Pg. 3, Each address request issued by C.sub.i is compared against the stored LACP.sub.i. Legal requests are propagated to the AXI interconnect; illegal requests are denied and never reach the AXI interconnect; Pg. 6, This scenario corresponds to an architecture from Figure 2 when N = 2 and L = 3. The LACP.sub.1 of ACW.sub.1 states that C.sub.1 can read from all regions of R.sub.1 = {P.sub.1, P.sub.2} and write to all regions of W.sub.1 = {P.sub.1} (Examiner notes: where all requests to P.sub.3 are illegal and denied, as an example);
generating a dynamic runtime isolation barrier with an access control circuit connected between the execution domain processor and the one or more system-on-chip resources in response to the runtime isolation control data stream (Pg. 2, The Access Control Wrapper (ACW) is a configurable access control module designed to monitor an AXI-compliant controller … each untrusted controller Ci is wrapped by an ACW module ACW.sub.i; Pg. 3, Reset mode: the initial state of ACW.sub.i. It is awaiting configuration with a valid LACP.sub.i. Any request issued by Ci is blocked and does not propagate to the interconnect. Once LACP.sub.i is configured, ACW.sub.i moves to supervising mode), where the access control circuit is configured with the dynamic runtime isolation barrier to control access to the one or more system-on-chip resources by the execution domain processor that is physical and programmatically independent from the control point processor (Pg. 1, AKER access control system easily integrate with a Hardware Root of Trust (HRoT) for runtime monitoring and management of the controllers; Fig. 2, Examiner notes: The trusted entity (TE), as used herein is synonymous with the HRoT, is physically and programmatically independent from the SoC controllers C.sub.1 to C.sub.n);
running a first execution domain processor to access the one or more system-on-chip resources in compliance with the dynamic runtime isolation barrier (Pg. 3, Figure 3 shows a representation of the internal of the ACW.sub.i. The following discusses how ACW.sub.i behaves on read and write transactions. ACW is compatible with any AXI-compliant requests);
generating, by the access control circuit, feedback data in response to any blocked access by the execution domain processor (Pg. 3, Decouple mode: An illegal request has occurred. ACW.sub.i saves diagnostic information about the illegal request into its internal anomalies register. ACW.sub.i raises an interrupt to notify the TE of the illegal access attempt); and
generating, by the control point processor, updated runtime isolation control data stream for controlling access to the one or more system-on-chip resources by the execution domain processor in response to the feedback data (Pg. 3, Readmission policy: The TE can analyze the diagnostic information internal to ACW.sub.i and perform recovery operations on C.sub.i before switching back to supervising mode and thereby readmitting C.sub.i to communicate to the SoC. Examples of recovery operations are resetting, reconfiguring, or even reprogramming C.sub.i).
Restuccia reasonably teaches a first control point process connected to an access control circuit to configure a runtime isolation control data stream. However, Restuccia does not explicitly teach the first control point processor configuring access of interrupt requests entering an execution domain to be processed by the domain.
wherein generating the dynamic runtime isolation barrier comprises configuring the access control circuit (Pg. 538, We develop security wrappers on IPs that incorporate “smartness” to detect security-critical events of interest in the IP while providing both a standard communication between the IP and the E-IIPS and a standard template-based design that can be easily integrated on top of the IP implementation.) with the runtime isolation control data stream (Pg. 539, Our security wrapper design is frame-based, with a standard format for security-critical event definitions, which can be instantiated into corresponding events for specific IPs ) to specify one or more interrupt requests to the execution domain processor (Table II, Policies for Usage Case Analysis … Access Control, Prevent DMA Access to system level addresses; FIG. 6, Flow/message diagram representation of implementation of case II, Wherein an address sent through Request.sub.mem_cnt interface of a memory controller is analyzed; Pg. 542, As illustrated in FIG. 6, E-IIPS configures the IP-specific system-level address ranges at boot time in memory controller through its security wrapper (MCW). When an access from the DMA controller is detected by MCW, the request address is checked with the system specific ranges inside the wrapper logic) that are allowed to enter the first execution domain to be processed by the first execution domain (FIG. 6, If the DMA access request specifies an address that is not in system range, Memory controller wrapper allows access to memory bus; Pg. 542, In case of no violation, the system memory bus is granted for DMA). Claim 12 is a computer implemented method having similar limitations as claim 1. Thus, claim 12 is rejected for the same rationale as applied to claim 1.
With regard to claim 14, it is a method claim having similar limitations as claim 4. Thus, claim 14 is rejected for the same rationale as applied to claim 4.
With regard to claim 15, it is a method claim having similar limitations as claim 5. Thus, claim 15 is rejected for the same rationale as applied to claim 5.
With regard to claim 16, it is a method claim having similar limitations as claim 6. Thus, claim 16 is rejected for the same rationale as applied to claim 6.
With regard to claim 18, it is a method claim having similar limitations as claim 8. Thus, claim 18 is rejected for the same rationale as applied to claim 8.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Restuccia in view of Basak as applied to claims 1 and 12 respectively above, and further in view of Soundararajan et al. Pub. No. US 2022/0006651 A1 (hereinafter Soundararajan).
With regard to claim 3, Restuccia reasonably teaches a trusted entity, independent from SoC execution domain and peripheral resources, managing runtime security configurations of such domains. However, Restuccia does not explicitly teach that the runtime control point processor is executing an isolated control program.
Soundararajan teaches where the first control point processor is configured to run an isolation control program that is independent from any privileged software running on the execution domain processor ([0013], RoT (Examiner notes: Root of Trust) 103 can have a secure central processing unit (CPU) that runs secure software/firmware. Security features supported in the RoT 103 are defined by software running on that secure CPU … The RoT 103 can serve as a separate compute engine, for instance controlling a trusted computing platform)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Soundararajan with the teachings of Restuccia and Basak in order to provide a system that teaches a trusted entity executing privileged software to manage policies on the distributed execution environment. The motivation for applying Soundararajan teaching with Restuccia and Basak teaching is to provide a system that allows for a secure root of trust to be programmed with an independent, secure application that dictates policy decisions outside the scope of execution domains, allowing the root of trust can be relied upon to provide and maintain security functions used by the execution domains (Soundararajan, [0013]). Restuccia, Basak, and Soundararajan are analogous art directed towards access control arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Soundararajan with Restuccia and Basak to teach the claimed invention in order to provide a hardware root of trust as an anchor executing isolated control software.
With regard to claim 13, it is a method claim having similar limitations as claim 3. Thus, claim 13 is rejected for the same rationale as applied to claim 3.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Restuccia in view of Basak as applied to claims 1 and 12 respectively above, and further in view of Elboim et al. Pub. No. US 2005/0086456 A1 (hereinafter Elboim).
With regard to claim 7, Restuccia teaches where the first control point processor is connected to configured the access control circuit with the first runtime isolation control data stream (Page. 3, Fig. 3, ACW.sub.i architecture: C.sub.i is the controller module using an AXI M interface. Regs are the configuration registers holding LACP.sub.i. The AXI S interface is connected to the HRoT) to specify a reset request that the first execution is allowed to respond (Pg. 4, Requirement 2: The configuration/anomaly registers are cleared and set their default values while the ACW is actively being reset; Pg. 5, For the security requirements relevant to the config/control group (Requirement 2), the security property templates are primary trace properties which specify what the value of a specific signal/register should be under various conditions) to by latching a reset vector (Pg. 5, For example, the security requirement is formalized using the following template which fails if the configuration/anomaly reigsters do not contain their default values after being reset. ‘reg’ == ‘dflt_val’ unless (ARESETN != 0 && ‘acw_w/r_state != 2’b00) (Examiner notes: wherein the instruction specifies that the registers are set to a default value unless the system is not being reset and the access control wrapper indicates valid write/read permissions)
However, Restuccia does not explicitly recite that the reset vector instruction is an address from memory.
Elboim teaches address from memory corresponding to the reset request ([0016], According to embodiments, configuration registers are circuits that can hold value while they are not written with a new value and while there is power in the circuit … after power is stable, a global reset signal that is connected to all the registers in the design may change state … into known initial states (usually 0s). For instance, a designer may assign a default value to a register in the design phase and that value will be “inserted” into the register by the reset signal; [0018], Conversely, according to embodiments, configuration registers having critical communication parameters that reset to undesired default values may be loaded from memory)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Elboim with the teachings of Restuccia and Basak in order to provide a system that teaches access control configuration through a specified default reset address corresponding in memory. The motivation for applying Elboim teaching with Restuccia and Basak teaching is to provide a system that allows for a system designer to specify a default reset value while preserving critical configuration information about the system when applying a reset configuration (Elboim, [0018]). Restuccia, Basak, and Elboim are analogous art directed towards memory management and configuration. Therefore, it would have been obvious for one of ordinary skill in the art to combine Elboim with Restuccia and Basak to teach the claimed invention in order to provide an operator specified default reset value that can be addressed in memory and provide access control configurations.
With regard to claim 17, it is a method claim having similar limitations as claim 7. Thus, claim 17 is rejected for the same rationale as applied to claim 7.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Restuccia in view of Basak as applied to claims 1 and 12 respectively above, and further in view of Sastry et al. Pub. No. US 2014/0137231 A1 (hereinafter Sastry).
With regard to claim 9, Restuccia does not explicitly describe the reconfiguration of an updated dynamic runtime barrier in response from updating the isolation control data stream.
Sastry teaches where the access control circuit is configured to provide an updated dynamic runtime isolation barrier is response to the updated isolation control data stream ([0020], the SAI specified in the control policy register is allowed to modify the read and write policy register policies as well as overwrite the contents of the control policy register … the trusted entity may write 0s into the control policy register, thus locking it until the next system reset/power-on. This provides flexibility for the SoC architect to implement locking down the policy registers until the next reset or allow the policy to be updated by a trusted entity during runtime (Examiner notes: an updated SAI is provided), thereby by updating how access to the one or more system-on-chip resources is controlled by the first execution domain ([0045], IP interface circuitry 440 (Examiner notes: execution domain) can be in communication with a functional unit 450 (Examiner notes: access control circuit) which may perform various access control operations … Functional unit 450 may also be configured to perform sophisticated access control mechanisms such as dynamic policy configuration to enable on-the-fly revision of policy values linked to an asset).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Sastry with the teachings of Restuccia and Basak in order to provide a system that teaches access control updates corresponding to access control configuration updates made to an access control circuit. The motivation for applying Sastry teaching with Restuccia and Basak teaching is to provide a system that allows for access control configurations to propagate from software onto hardware, such that the software configurations enable access control mechanism to be reconfigured on-the-fly and during runtime (Sastry, [0045]). Restuccia, Basak, and Sastry are analogous art directed towards security arrangements made to peripheral components. Therefore, it would have been obvious for one of ordinary skill in the art to combine Sastry with Restuccia to teach the claimed invention in order to provide a mechanism for updating the access control circuitry using updated access control configuration during runtime.
With regard to claim 19, it is a method claim having similar limitations as claim 9. Thus, claim 19 is rejected for the same rationale as applied to claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2012/0079590 A1
teaches
Abstract, A method and system for enforcing access control to system resources and assets. Security attributes associated with devices that initiate transactions in the system are automatically generated and forwarded with transactions messages. The security attributes convey access privileges assigned to each initiator. One or more security enforcement mechanisms are implemented in the system to evaluate security attributes against access policy requirements to access various system assets and resources, such as memory, registers, address ranges, etc. If the privileges identified by the security attributes indicate the access request is permitted, the transaction is allowed to proceed.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM EST.
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, Aimee Li can be reached at (571) 272-4169. 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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights