DETAILED ACTION
This office action is in response to the application filed on 04/26/2026. Claim(s) 1-20 is/are pending and are examined.
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 amended claim(s) 1, 13, and 20 have been fully considered but are moot in view of the new ground(s) of rejection.
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, 11, 13-14, 16, 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable by Venkataramani (US 11,861,049 B2) hereinafter Venka in view of Sakalis (US 2021/0365554 A1), hereinafter Sakalis.
Regarding Claim(s) 1 Venka teaches:
A processor comprising: (Venka Col. 1-2 Ln. 65-67 and 1-15 teaches, Embodiments disclosed herein leverage cache monitoring (e.g., Intel's Cache Monitoring Technology (CMT), available in recent server-class processors))
a cache controller associated with a shared cache level of a hierarchy of one or more cache levels, (Venka Col. 1-2 Ln. 65-67 and 1-15 teaches, to perform fine-grained monitoring of cache (e.g., last level cache (LLC)) occupancy for individual application domains.) the cache controller configured to penalize access requests from a first application to the shared cache level in response to detecting a suspicious access pattern of the access requests, (Venka Col. 1-2 Ln. 65-67 and 1-15 teaches Suspicious application domains are identified, such as by applying signal processing techniques that characterize the communication strength of spy processes in cache timing channels. In some examples, cache way allocation (e.g., Intel's Cache Allocation Technology) is repurposed as a secure cache manager (i.e., cache controller) to dynamically partition the cache for suspicious application domains and disband any timing channel activity. (i.e., penalize the requests)) the shared cache level accessible by multiple applications of the processor, including the first application and a second application. (Venka Col. 1-2 Ln. 65-67 and 1-15 teaches, Embodiments disclosed herein leverage cache monitoring (e.g., Intel's Cache Monitoring Technology (CMT), available in recent server-class processors). Suspicious application domains are identified, such as by applying signal processing techniques that characterize the communication strength of spy processes in cache timing channels. In some examples, cache way allocation (e.g., Intel's Cache Allocation Technology) is repurposed as a secure cache manager to dynamically partition the cache for suspicious application domains)
Venka does not appear to explicitly teach but in related art:
by introducing a different delay for each response to subsequent access requests of the first application to the shared cache level (Sakalis ¶ 16 teaches, which is a much stricter speculative delay mechanism, all speculative execution or the speculative execution of all side channel instructions is delayed. This stricter speculative delay mechanism can be referred to as a Delay-All mechanism. (i.e., adding delay) Other levels of delay, include delaying the speculative execution of instructions whose operands are speculatively accessed values or values that were generated from speculatively accessed values from the memory hierarchy and delaying the speculative execution of instructions with memory fence or memory barrier instructions.)
for the access requests and the subsequent access requests (Sakalis ¶ 16 teaches, which is a much stricter speculative delay mechanism, all speculative execution or the speculative execution of all side channel instructions is delayed. This stricter speculative delay mechanism can be referred to as a Delay-All mechanism. Other levels of delay, include delaying the speculative execution of instructions whose operands are speculatively accessed values or values that were generated from speculatively accessed values from the memory hierarchy and delaying the speculative execution of instructions with memory fence or memory barrier instructions. (i.e., subsequent access requests))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka with Sakalis, to modify the method for defense against cache timing channel attacks of Venka with the timing delays of Sakalis to prevent side channel attacks. The motivation to do so, Sakalis ¶ 140, the effects on system performance are minimized while security against a wide range of side channel attacks is increased.
Regarding Claim(s) 13 Venka teaches:
A system comprising: (Venka Col. 1 Ln. 48-52 teaches, A system and method for defense against cache timing channel attacks using cache management hardware is provided.)
multiple processor cores, including a first application executing on a first processor core and a second application executing on a second processor core; (Venka Col. 8 Ln. 18-25 teaches, COTSknight 10 is discussed herein with particular reference to implementation on an LLC of a processor. This is due to the shared nature of the LLC in multi-core processors, as well as the larger area of attack such that the LLC is a more likely target of timing channel attacks. It should be understood that other embodiments may implement COTSknight 10 on other cache levels (e.g., L1 cache, L2 cache, L3 cache, etc.) per design and security needs. (i.e., shared cache) Col. 14 Ln. 12-21 teaches, The LLC occupancy monitor can export interface to a system administrator (e.g., resident in the user space) to override domain configurations. For instance, multiple application domains belonging to the same user can be grouped together. (i.e., multiple applications))
a shared cache level of a hierarchy of one or more cache levels accessible by the multiple processor cores; and (Venka Col. 8 Ln. 18-25 teaches, COTSknight 10 is discussed herein with particular reference to implementation on an LLC of a processor. This is due to the shared nature of the LLC in multi-core processors, as well as the larger area of attack such that the LLC is a more likely target of timing channel attacks. It should be understood that other embodiments may implement COTSknight 10 on other cache levels (e.g., L1 cache, L2 cache, L3 cache, etc.) per design and security needs. (i.e., shared cache))
a cache controller associated with the shared cache level (Venka Col. 1-2 Ln. 65-67 and 1-15 teaches, Embodiments disclosed herein leverage cache monitoring (e.g., Intel's Cache Monitoring Technology (CMT), available in recent server-class processors)) configured to penalize first access requests from the first application to the shared cache level in response to detecting a suspicious access pattern of the first access requests in relation to second access requests of the second application. (Venka Col. 8 Ln. 1-10, The occupancy pattern analyzer 14 identifies suspicious pairs of the application domains 18 that are very likely to be involved in timing channel-based communication. (i.e., time channel attack is a type of side-channel attack) Venka Col. 1-2 Ln. 65-67 and 1-15 teaches Suspicious application domains are identified, such as by applying signal processing techniques that characterize the communication strength of spy processes in cache timing channels. In some examples, cache way allocation (e.g., Intel's Cache Allocation Technology) is repurposed as a secure cache manager (i.e., cache controller) to dynamically partition the cache for suspicious application domains and disband any timing channel activity. (i.e., penalize the requests))
Venka does not appear to explicitly teach but in related art:
by introducing a different delay for each response to subsequent access requests of the first application to the shared cache level (Sakalis ¶ 16 teaches, which is a much stricter speculative delay mechanism, all speculative execution or the speculative execution of all side channel instructions is delayed. This stricter speculative delay mechanism can be referred to as a Delay-All mechanism. (i.e., adding delay) Other levels of delay, include delaying the speculative execution of instructions whose operands are speculatively accessed values or values that were generated from speculatively accessed values from the memory hierarchy and delaying the speculative execution of instructions with memory fence or memory barrier instructions.)
for the access requests and the subsequent access requests (Sakalis ¶ 16 teaches, which is a much stricter speculative delay mechanism, all speculative execution or the speculative execution of all side channel instructions is delayed. This stricter speculative delay mechanism can be referred to as a Delay-All mechanism. Other levels of delay, include delaying the speculative execution of instructions whose operands are speculatively accessed values or values that were generated from speculatively accessed values from the memory hierarchy and delaying the speculative execution of instructions with memory fence or memory barrier instructions. (i.e., subsequent access requests))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka with Sakalis, to modify the method for defense against cache timing channel attacks of Venka with the timing delays of Sakalis to prevent side channel attacks. The motivation to do so, Sakalis ¶ 140, the effects on system performance are minimized while security against a wide range of side channel attacks is increased.
Regarding Claim(s) 20 Venka teaches:
A method comprising: (Venka Col. 1 Ln. 48-52 teaches, A system and method for defense against cache timing channel attacks using cache management hardware is provided.)
monitoring, by a cache controller, access requests of an application of multiple applications to a shared cache level of a hierarchy of one or more cache levels; and (Venka Col. 1-2 Ln. 65-67 and 1-15 teaches, Embodiments disclosed herein leverage cache monitoring (e.g., Intel's Cache Monitoring Technology (CMT), available in recent server-class processors) to perform fine-grained monitoring of cache (e.g., last level cache (LLC)) occupancy for individual application domains. Suspicious application domains are identified, such as by applying signal processing techniques that characterize the communication strength of spy processes in cache timing channels. In some examples, cache way allocation (e.g., Intel's Cache Allocation Technology) is repurposed as a secure cache manager (i.e., cache controller) to dynamically partition the cache for suspicious application domains and disband any timing channel activity. (i.e., penalize the requests))
in response to detecting a suspicious access pattern of the access requests, penalizing, by the cache controller, subsequent access requests from the application to the shared cache level. (Suspicious application domains are identified, such as by applying signal processing techniques that characterize the communication strength of spy processes in cache timing channels. In some examples, cache way allocation (e.g., Intel's Cache Allocation Technology) is repurposed as a secure cache manager (i.e., cache controller) to dynamically partition the cache for suspicious application domains and disband any timing channel activity. (i.e., penalize the requests))
the shared cache level accessible by the multiple application including the application for (Venka Col. 12 Ln. 17-21 teaches the concept, Note that all of the newly created application domains (e.g., newly spawned processes) may be initially set to a default CLOS (e.g., CLOS0) with access to all LLC ways. (i.e., multiple applications use the cache level))
Venka does not appear to explicitly teach but in related art:
by introducing a different delay for each response to subsequent access requests of the first application to the shared cache level (Sakalis ¶ 16 teaches, which is a much stricter speculative delay mechanism, all speculative execution or the speculative execution of all side channel instructions is delayed. This stricter speculative delay mechanism can be referred to as a Delay-All mechanism. (i.e., adding delay) Other levels of delay, include delaying the speculative execution of instructions whose operands are speculatively accessed values or values that were generated from speculatively accessed values from the memory hierarchy and delaying the speculative execution of instructions with memory fence or memory barrier instructions.)
for the access requests and the subsequent access requests (Sakalis ¶ 16 teaches, which is a much stricter speculative delay mechanism, all speculative execution or the speculative execution of all side channel instructions is delayed. This stricter speculative delay mechanism can be referred to as a Delay-All mechanism. Other levels of delay, include delaying the speculative execution of instructions whose operands are speculatively accessed values or values that were generated from speculatively accessed values from the memory hierarchy and delaying the speculative execution of instructions with memory fence or memory barrier instructions. (i.e., subsequent access requests))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka with Sakalis, to modify the method for defense against cache timing channel attacks of Venka with the timing delays of Sakalis to prevent side channel attacks. The motivation to do so, Sakalis ¶ 140, the effects on system performance are minimized while security against a wide range of side channel attacks is increased.
Regarding Claim(s) 2 Venka in view of Sakalis teaches:
The processor of claim 1, (Venka teaches the parent claim above.) wherein the suspicious access pattern indicates a cache side-channel attack by the first application against the second application. (Venka Col. 8 Ln. 1-10, The occupancy pattern analyzer 14 identifies suspicious pairs of the application domains 18 that are very likely to be involved in timing channel-based communication. (i.e., time channel attack is a type of side-channel attack))
Regarding Claim(s) 5 Venka in view of Sakalis teaches:
The processor of claim 1, (Venka in view of Sakalis teaches the parent claim above.) wherein the cache controller is further configured to obtain statistics on the access requests of each application having access to the shared cache level (Venka Col. 2 Ln. 15-21 teaches, the method includes monitoring cache occupancy for a set of application processes operating in a processor to produce cache occupancy data over a period of time. (i.e., statistics) The method further includes analyzing the cache occupancy data to identify a potential cache timing channel attack.)
Regarding Claim(s) 11 Venka in view of Sakalis teaches:
The processor of claim 1, (Venka in view of Sakalis teaches the parent claim above.) wherein the cache controller is configured to penalize the access requests by temporarily partitioning a cache line of the shared cache level targeted by the access requests from other cache lines accessed by the second application. (Venka Col. 1-2 Ln. 65-67 and 1-15 teaches In some examples, cache way allocation (e.g., Intel's Cache Allocation Technology) is repurposed as a secure cache manager to dynamically partition the cache for suspicious application domains and disband any timing channel activity.)
Regarding Claim(s) 14 Venka in view of Sakalis teaches:
The system of claim 13, (Venka in view of Sakalis teaches the parent claim above.) wherein the first application and the second application have access to the shared cache level for a first amount of time. (Venka Col. 15 Ln. 8-36 and Table 1, Each attack variant shown in Table I is set up to run for 90 seconds (s) on the Intel Xeon v4 server. To emulate real system environment, two SPEC2006 benchmarks are co-scheduled alongside the trojan and spy. Each attack variant is run multiple times with different co-scheduled process pairs and numbers of target sets. (i.e., first and second application) The occupancy pattern analyzer 14 performs pair-wise normalized autocorrelation on time-differentiated LLC occupancy traces for six combination pairs of application domains 18.)
Regarding Claim(s) 16 Venka in view of Sakalis teaches:
The system of claim 13, (Venka teaches the parent claim above.) wherein the cache controller is further configured to maintain a record of suspicious access patterns by the first application. (Venka Col. 2 Ln. 15-21 teaches, the method includes monitoring cache occupancy for a set of application processes operating in a processor to produce cache occupancy data over a period of time. (i.e., statistics) The method further includes analyzing the cache occupancy data to identify a potential cache timing channel attack.)
Regarding Claim(s) 18 Venka in view of Sakalis teaches:
The system of claim 13, (Venka teaches the parent claim above.) wherein the shared cache level is a level three cache. (Venka Col. 1-2 Ln. 65-67 and 1-15 teaches to perform fine-grained monitoring of cache (e.g., last level cache (LLC)) occupancy for individual application domains. (i.e., level 3 cache.))
Claim(s) 3, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venka in view of Sakalis in view of Basak(US 2019/0042479 A1), hereinafter Basak.
Regarding Claim(s) 3 Venka in view of Sakalis teaches:
The processor of claim 2, (Venka in view of Sakalis teaches the parent limitation above.)
Venka in view of Sakalis does not appear to explicitly teach but in related art:
wherein the suspicious access pattern includes a number of access requests by the first application to a cache index of multiple cache indices in the shared cache level within a time window, the number being greater than or equal to an access threshold. (Basak ¶ 26 teaches, logic 106 may be configured to compare a number or frequency of attempts to flush a line that is not currently in the cache hierarchy to a threshold. The threshold may be preset, or may be determined and updated based on historical data. Example thresholds include 10 requests within 100 clock cycles, 20 requests from the same process within 30 operations, etc. (i.e., requests in time window))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka in view of Sakalis with Basak, to modify the method for defense against cache timing channel attacks of Venka with the delays to prevent side channel attacks of Sakalis with the security policies, thresholds for side-channel attacks, and SoC chip of Basak. The motivation to do so, Basak ¶ 13, to prevent attackers utilizing such attacks from gleaning meaningful information.
Regarding Claim(s) 12 Venka-Sakalis- teaches:
The processor of claim 1, (Venka in view of Sakalis teaches the parent claim above.) wherein the processor comprises a system on chip (SoC) with multiple processing cores. (Basak ¶ 53 teaches, the circuitry may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), system on-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smartphones, etc. programmable circuitry such as computer processors comprising one or more individual instruction processing cores, state machine circuitry)
The motive given in Claim 3 is equally applicable to the above claim.
Regarding Claim(s) 19 Venka in view of Sakalis teaches:
The system of claim 13, (Venka in view of Sakalis teaches the parent limitation above.) wherein the suspicious access pattern includes a number of first access requests by the first application to a cache index of multiple cache indices in the shared cache level within a time window, the number being greater than or equal to an access threshold. (Basak ¶ 26 teaches, logic 106 may be configured to compare a number or frequency of attempts to flush a line that is not currently in the cache hierarchy to a threshold. The threshold may be preset, or may be determined and updated based on historical data. Example thresholds include 10 requests within 100 clock cycles, 20 requests from the same process within 30 operations, etc. (i.e., requests in time window))
The motive given in Claim 3 is equally applicable to the above claim.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venka-Sakalis-Basak as applied to claim 3 above, and further in view of Moyer (US 11,210,234 B2), hereinafter Moyer.
Regarding Claim(s) 4 Venka-Sakalis-Basak teaches:
The processor of claim 3, (Venka-Sakalis-Basak teaches the parent limitation above.)
Venka-Sakalis-Basak does not appear to explicitly teach but in related art:
wherein the time window is a sliding time window. (Moyer Col. 2 Ln. 44-50 teaches, cache controller compares the number of accesses to each of two test regions over a sliding time window.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka-Sakalis-Basak with Moyer, to modify the method for defense against cache timing channel attacks of Venka with the security policies and thresholds for side-channel attacks of Basak with the sliding time window of Moyer. The motivation to do so, Moyer Col. 6 Ln. 45-47, to ameliorate the impact of non-representative memory access patterns.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venka in view of Sakalis as applied to claim 1 above, and in view of Basak further in view of Halperin (US 2002/0194490 A1), hereinafter Halperin.
Regarding Claim(s) 7 Venka in view of Sakalis teaches:
The processor of claim 1, (Venka in view of Sakalis teaches the parent claim above.)
Venka in view of Sakalis does not appear to explicitly teach but in related art:
wherein the cache controller is configured to penalize the access requests (Basak ¶ 41 teaches, this cache security policy may result in processor 102 performing various hardware or software security operations such as flushing cache lines, etc. )
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka with Basak, to modify the method for defense against cache timing channel attacks of Venka with the security policies, thresholds for side-channel attacks, and SoC chip of Basak. The motivation to do so, Basak ¶ 13, to prevent attackers utilizing such attacks from gleaning meaningful information.
Venka-Sakalis-Basak does not appear to explicitly teach but in related art:
for a period of time based on a length or a degree of the suspicious access pattern (Halperin ¶ 30 teaches, the delay period is adjustable according to a level of suspicious behavior in any of the groups. )
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka-Sakalis-Basak with Halperin, to modify the method for defense against cache timing channel attacks of Venka with the security policies and thresholds for side-channel attacks of Basak with the delay in a response depending on a level of suspiciousness of Halperin. The motivation to do so constitutes applying a known technique of adding variable delay based on a condition suspiciousness to known devices and/or methods for preventing timing channel attacks ready for improvement to yield predictable results to increase difficulty for an attacker to access information in the system.
Claim(s) 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venka in view of Sakalis as applied to claim 1 above, and in view of Jagtap (US 2019/0384501 A1), hereinafter Jagtap.
Regarding Claim(s) 9 Venka-Sakalis-Jagtap teaches:
The processor of claim 1, (Venka in view of Sakalis teaches the parent claim above.)
Venka in view of Sakalis does not appear to explicitly teach but in related art:
wherein the cache controller is configured to penalize the access requests for a set amount of time. (Jagtap ¶ 21 teaches, in some cases to improve security the constant response delay may be imposed for a certain period after the context switch with the length of the period set depending on the level of security required for a given implementation.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka-Sakalis, to modify the method for defense against cache timing channel attacks of Venka with the delay in a response of Jagtap. The motivation to do so, Jagtap ¶ 3, to control subsequent memory access requests associated with the second execution context.
Regarding Claim(s) 10 Venka-Sakalis-Jagtap teaches:
The processor of claim 9, (Venka-Jagtap teaches the parent limitation above.) wherein the set amount of time: depends on a degree, a length, or a repetition of the suspicious access pattern by the first application; or is longer than a colocation window for the first application and the second application in the shared cache level. (Jagtap ¶ 21 teaches, in some cases to improve security the constant response delay may be imposed for a certain period after the context switch with the length of the period set depending on the level of security required for a given implementation. (i.e., degree of suspicion))
The motive given in Claim 9 is equally applicable to the above claim.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venka-Sakalis as applied to claim 1 above, in view of Japtap and further in view of Kailas (US 2012/0323982 A1), hereinafter Kailas.
Regarding Claim(s) 8 Venka-Sakalis teaches:
The processor of claim 1, (Venka-Sakalis teaches the parent limitation above.)
Venka-Sakalis does not appear to explicitly teach but in related art:
wherein the different delay is (Jagtap ¶ 23 teaches, with a variable response delay depending on the variable access latency provided by the memory.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka-Sakalis, to modify the method for defense against cache timing channel attacks of Venka with the delay in a response of Jagtap. The motivation to do so, Jagtap ¶ 3, to control subsequent memory access requests associated with the second execution context.
Venka-Sakalis-Jagtap does not appear to explicitly teach but in related art:
a variable and random amount for each response to the subsequent access requests of the first application. (Kailas ¶ 48 teaches, a freely random number generator may take a variable number of (2N+L) cycles, where L can be any integer, from 0 to infinity, to generate a “complete random sequence” that has all the unique random numbers at least once.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka-Sakalis-Jagtap with Kalias, to modify the method for defense against cache timing channel attacks of Venka with the security policies and thresholds for side-channel attacks of Basak with the delay in a response of Jagtap with the random and variable delay of Kalias. The motivation to do so, Kalias ¶ 25, to provide a method for a provably fair random number generator.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venka in view of Sakalis as applied to claim 14 above, and further in view of Drerup (US 2019/0042439 A1), hereinafter Drerup.
Regarding Claim(s) 15 Venka in view of Sakalis teaches:
The system of claim 14 (Venka in view of Sakalis teaches the parent claim above.) wherein the cache controller is configured to penalize (Venka Col. 1-2 Ln. 65-67 and 1-15 teaches, to perform fine-grained monitoring of cache (e.g., last level cache (LLC)) occupancy for individual application domains.)
Venka in view of Sakalis does not appear to explicitly teach but in related art:
the first access requests for a second amount of time, the second amount of time being equal to or greater than the first amount of time. (Drerup ¶ 3 teaches, a victim cache line is selected for removal from the congruence class and the contents of the cache line are evicted to make room for a new cache line. The evicted cache line may then be discarded or written to a lower-level cache or system memory. (i.e., it is kicked out of the cache)).
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka in view of Sakalis with Drerup, to modify the method for defense against cache timing channel attacks of Venka with the eviction of victim cache line of Drerup. The motivation to do so, Drerup ¶ 5, to prevent multiple requests to the same array in close temporal proximity.
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venka in view of Sakalis as applied to claim 13 above, and further in view of Halperin.
Regarding Claim(s) 17 Venka in view of Sakalis teaches:
The system of claim 13, wherein the cache controller is configured to penalize the first access requests (Venka in view of Sakalis teaches the parent claim above.)
Venka in view of Sakalis does not appear to explicitly teach but in related art:
for a period of time based on a degree, a length, or a repetition of the suspicious access pattern by the first application (Halperin ¶ 30 teaches, the delay period is adjustable according to a level of suspicious behavior in any of the groups.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Venka-Sakalis with Halperin, to modify the method for defense against cache timing channel attacks of Venka with the with the timing delay to prevent side channel attacks of Sakalis with the delay in a response depending on a level of suspiciousness of Halperin. The motivation to do so constitutes applying a known technique of adding variable delay based on a condition suspiciousness to known devices and/or methods for preventing timing channel attacks ready for improvement to yield predictable results to increase difficulty for an attacker to access information in the system.
Allowable Subject Matter
Claim 6 is 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 9,436,603 B1 - Detection And Mitigation Of Timing Side-channel Attacks via during execution of an application that accesses a shared memory, a security component may, based on an indication from a performance monitor, determine that the application is carrying out a timing side-channel attack.
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 JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8:00 am - 5:00 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, Linglan Edwards can be reached on (571) 270-5440. 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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights