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 .
Summary
This action is a responsive to the amendment filed on 7/1/2026.
Claims 1-20 are pending and have been examined.
Claims 1-20 are rejected.
Response to Arguments
Claim Objection
Applicant’s Response:
The Office Action objected to claim 6 for an informality. See Office Action, p. 27. Specifically, the Office Action noted that "form" should be "from" in claim 6.
In response, Applicant has amended claim 6 to correct the typographical error. Accordingly, Applicant requests that the objection to claim 6 be withdrawn.
Examiner’s Response:
Applicant’s arguments, see remarks, filed 7/1/26, with respect to claim 6 have been fully considered and are persuasive. The objection of 4/1/26 has been withdrawn.
Rejection of Claims under 35 USC 101
Applicant’s Response:
The Applicant argues that the claims 1) the features of "perform a security operation corresponding to the security event" cannot practically be performed in the human mind; 2) As claim 11 is not rejected under 35 U.S.C. § 101, it appears that the Office Action recognizes that performance of a security operation corresponding to the security event is eligible subject matter and 3) Applicant submits the elements of amended independent claim 1, including "perform a security operation corresponding to the security event[,]" recites a practical integration of features into a practical application, at least because the subject matter of amended independent claim is analogous to Example 47: Anomaly Detection.
Examiner’s Response:
Applicant's arguments filed 7/1/26 have been fully considered but they are not persuasive. The Applicant argues that the claims 1) the features of "perform a security operation corresponding to the security event" cannot practically be performed in the human mind; 2) As claim 11 is not rejected under 35 U.S.C. § 101, it appears that the Office Action recognizes that performance of a security operation corresponding to the security event is eligible subject matter and 3) Applicant submits the elements of amended independent claim 1, including "perform a security operation corresponding to the security event[,]" recites a practical integration of features into a practical application, at least because the subject matter of amended independent claim is analogous to Example 47: Anomaly Detection. The Examiner disagrees and will present the analysis of the independent claims below. The claims are examined under the broadest reasonable interpretation.
The 2019 Revised Patent Subject Matter Eligibility Guidance lays out the steps for analysis of claims for an abstract idea. Step 1 is “Do the claims fall within the statutory categories?” Yes. Claims 1-9 are an apparatus (UE) and claims 17-20 are a method. Claims 11-16 are an apparatus.
The next step is Step 2A Prong 1, “Does the claim recite a judicial exception (an abstract idea)?” Yes. The Applicant argues that the claims 1) the features of "perform a security operation corresponding to the security event" cannot practically be performed in the human mind; 2) As claim 11 is not rejected under 35 U.S.C. § 101, it appears that the Office Action recognizes that performance of a security operation corresponding to the security event is eligible subject matter. The limitation of “detect occurrence of a security event that is indicative of an attack against a security vulnerability associated with the UE, wherein detection of the occurrence of the security event is based at least in part on data collected by the UE” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind (mental process). That is, nothing in the claim element precludes the step from practically being performed in the mind. For example, “detect” in the context of this claim encompasses the user manually looking at the data and deciding if there’s a threat. Then sending a message. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Addressing the Applicant argument 1, the Applicant is correct that “perform a security operation corresponding to the security event" is not an abstract idea. It is not the limitation that contains the judicial exception (an abstract idea) and has no barring on this step. Addressing the Applicant argument 2, the cited limitation containing the judicial exception (an abstract idea) is not present in claim 11. Therefore, claim 11 fails Step 2A Prong 1.
The next step is Step 2A Prong 2, “Evaluating additional elements in the claim to determine whether they integrate the exception into a practical application of the exception” No. The Applicant argues 3) Applicant submits the elements of amended independent claim 1, including "perform a security operation corresponding to the security event[,]" recites a practical integration of features into a practical application, at least because the subject matter of amended independent claim is analogous to Example 47: Anomaly Detection. The Applicant did not cite a claim that closely aliens with the instant application. Example 47: Anomaly Detection illustrates the application of the eligibility analysis to claims that recite limitations specific to artificial intelligence, particularly the use of an artificial neural network to identify or detect anomalies. The closest claim to the instant application is Example 47 claim 2 with the “detecting” and “outputting” steps. Example 47 claim 2 was found to be ineligible aliening with the Examiner’s analysis. This judicial exception is not integrated into a practical application because the technical improvement is the improved security related to security event detection and reporting in ¶ [0117] of the spec. There is no meaningful use of the outputted data beyond a broad statement. Accordingly, the claim is not integrated into a practical application.
The next step is Step 2B, “evaluate whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception”. No. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because: “transmit, to a wireless entity and based at least in part on detection of the security event, information indicative of the occurrence of the security event, the information representative of at least the data collected by the UE that triggered detection of the security event and further representative of a source of the security event” and “perform a security operation corresponding to the security event” are insignificant extra-solution activity to the judicial exception. Accordingly, the claim does not recite additional elements that amount significantly more. Thus, the claims are not patent eligible.
Rejection of Claims under 35 USC 103
Applicant’s Response:
Applicant submits that the cited references fail to teach the newly added limitations of:
and further representative of a source of the security event; and perform a security operation corresponding to the security event.
Examiner’s Response:
Applicant’s arguments with respect to claims 1, 11, 17 have been considered but are moot because the arguments are directed to amended subject matter properly addressed with the newly cited reference of Diehl et al. (US 20210326453 A1).
The combination of Mahaffey et al. (US 20140373162 A1) and Diehl et al. (US 20210326453 A1) teaches the language of the independent claims.
All remaining arguments are now moot in regards to the new rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 1-10, 17-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
Claim 1, 17 rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more. The claim(s) recite(s) “one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to cause the UE to: detect occurrence of a security event that is indicative of an attack against a security vulnerability associated with the UE, wherein detection of the occurrence of the security event is based at least in part on data collected by the UE; transmit, to a wireless entity and based at least in part on detection of the security event, information indicative of the occurrence of the security event, the information representative of at least the data collected by the UE that triggered detection of the security event and further representative of a source of the security event; and perform a security operation corresponding to the security event.”
The limitation of “detect occurrence of a security event that is indicative of an attack against a security vulnerability associated with the UE, wherein detection of the occurrence of the security event is based at least in part on data collected by the UE” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind (mental process). That is, nothing in the claim element precludes the step from practically being performed in the mind. For example, “detect” in the context of this claim encompasses the user manually looking at the data and deciding if there’s a threat. Then sending a message. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the technical improvement is the improved security related to security event detection and reporting in ¶ [0117] of the spec. There is no meaningful use of the outputted data beyond a broad statement. Accordingly, the claim is not integrated into a practical application. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because: “transmit, to a wireless entity and based at least in part on detection of the security event, information indicative of the occurrence of the security event, the information representative of at least the data collected by the UE that triggered detection of the security event and further representative of a source of the security event” and “perform a security operation corresponding to the security event” are insignificant extra-solution activity to the judicial exception.
Claims 2-10 and 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more. These claims are all directed towards an abstract idea (mental process) and/or insignificant extra-solution activity to the judicial exception. The claims are not patent eligible.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5, 8, 11-14, 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 20140373162 A1) and further in view of Diehl et al. (US 20210326453 A1).
As to claim 1, Mahaffey et al. teaches a user equipment (UE), comprising: one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code (See ¶ [0020], Teaches that The mobile device 101 can include: an operating system 113, an input device 115, a radio frequency transceiver(s) 117, a visual display 121, database of security event information 123, and a battery or power supply 119. Each of these components can be coupled to a central processing unit (CPU) 103. The operating system 113 runs on the CPU 103 and provides an interface between security system application programs and the mobile device hardware.)
to cause the UE to: detect occurrence of a security event that is indicative of an attack against a security vulnerability associated with the UE, wherein detection of the occurrence of the security event is based at least in part on data collected by the UE (See ¶¶ [0030], [0031], Figure 2, Teaches that The local security component analyzes aspects of the data to determine if a security event is detected 213. If the local security component onboard the mobile device detects a security problem with the data, one or more security events may be triggered. The local security component automatically performs defensive actions to protect the mobile device 101 from the immediate threat. The event or events generated will be processed 217 in order to determine if further actions need to be taken. The type of defensive processing performed by the local security component depends upon the context and type of data being analyzed. For example, the system can drop network data considered to be harmful or may disconnect one or more protocol connections associated with the data. The security component produces an event log that is stored and updated as new events are detected. Although monitoring of the security events is primarily directed towards data, hardware defects may also create security events. For example, physical damage, dead batteries or other defective hardware in the mobile device can cause the security component to detect a security event.);
and transmit, to a wireless entity and based at least in part on detection of the security event, information indicative of the occurrence of the security event, the information representative of at least the data collected by the UE that triggered detection of the security event (See ¶¶ [0033], [0020], Figure 2, Teaches that In addition to displaying the security status on the mobile device, the security status as well as events and event data can be forwarded to a server 111. The server may further process the events, event data, and security status information and/or output the status information to other electronic devices. A security status signal can be transmitted to a client computer 233 associated with the mobile device 101 through a security widget.);
and perform a security operation corresponding to the security event (See ¶ [0039], Teaches that The remote security component may receive information about both security event and non-security-event data received by the mobile device. Based upon this cumulative data, the remote security component can determine an overall security status or assessment for the mobile device 327. If the server 111 were to determine that the security component on the mobile device 101 was unable to stop any sort of security attack or virus/malware infection, the server 111 would update the device's security status accordingly. If needed, the server 111 may transmit commands to the device to remediate one or more security problems associated with events 317. These commands may be specialized for the particular virus or other security threat identified by the processing of one or more security events. The information gathering component can process the event information to produce charts, graphs, text outputs and graphical representations for the security state for the mobile device 101. The information gathering component at the server may also produce a log of security events for the mobile device).
However, it does not expressly teach the details of further representative of a source of the security event.
Diehl et al., from analogous art, teaches further representative of a source of the security event (See ¶¶ [0033]-[0034], [0037], Teaches that Events can include any observable and/or detectable type of computing operation, behavior, or other action that may occur on one or more client devices 104. Events can include events and behaviors associated with Internet Protocol (IP) connections, other network connections, Domain Name System (DNS) requests, operating system functions, file operations, registry changes, process executions, hardware operations, such as virtual or physical hardware configuration changes, and/or any other type of event. By way of non-limiting examples, an event may be that a process opened a file, that a process initiated a DNS request, that a process opened an outbound connection to a certain IP address, that there was an inbound IP connection, that values in an operating system registry were changed, or be any other observable or detectable occurrence on a client device 104. In some examples, events based on other such observable or detectable occurrences can be physical and/or hardware events, for instance that a Universal Serial Bus (USB) memory stick or other USB device was inserted or removed, that a network cable was plugged in or unplugged, that a cabinet door or other component of a client device 104 was opened or closed, or any other physical or hardware-related event. Events that occur on client devices 104 can be detected or observed by event detectors 124 of security agents 108 on those client devices 104. Event data 122 about locally-occurring events can also, or alternately, be sent by a security agent 108 on a client device 104 to the security network 106, such that the event data 122 can be processed by a cloud instance of the compute engine 102 and/or other cloud elements of the distributed security system 100.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Diehl et al. into Mahaffey et al. in order to detect and/or analyze security threats (See Diehl et al. ¶ [0021]).
As to claim 2, the combination of Mahaffey et al. and Diehl et al. teaches the user equipment (UE) according to claim 1 above. Mahaffey et al. further teaches wherein the one or more processors are individually or collectively further operable to execute the code to cause the UE to: receive one or more first signals that are indicative of one or more security events to be reported by the UE, wherein the data is collected by the UE based at least in part on the one or more first signals (See ¶¶ [0030], [0031], Figure 2, Teaches that The local security component analyzes aspects of the data to determine if a security event is detected 213. If the local security component onboard the mobile device detects a security problem with the data, one or more security events may be triggered. The local security component automatically performs defensive actions to protect the mobile device 101 from the immediate threat. The event or events generated will be processed 217 in order to determine if further actions need to be taken. The type of defensive processing performed by the local security component depends upon the context and type of data being analyzed. For example, the system can drop network data considered to be harmful or may disconnect one or more protocol connections associated with the data. The security component produces an event log that is stored and updated as new events are detected. Although monitoring of the security events is primarily directed towards data, hardware defects may also create security events. For example, physical damage, dead batteries or other defective hardware in the mobile device can cause the security component to detect a security event.).
As to claim 3, the combination of Mahaffey et al. and Diehl et al. teaches the user equipment (UE) according to claim 2 above. Mahaffey et al. further teaches wherein, to transmit the information indicative of the occurrence of the security event, the one or more processors are individually or collectively further operable to execute the code to cause the UE to transmit, to a network entity and based at least in part on receiving the one or more first signals, the data collected by the UE (See ¶¶ [0030], [0031], Figure 2, Teaches that The local security component analyzes aspects of the data to determine if a security event is detected 213. If the local security component onboard the mobile device detects a security problem with the data, one or more security events may be triggered. The local security component automatically performs defensive actions to protect the mobile device 101 from the immediate threat. The event or events generated will be processed 217 in order to determine if further actions need to be taken. The type of defensive processing performed by the local security component depends upon the context and type of data being analyzed. For example, the system can drop network data considered to be harmful or may disconnect one or more protocol connections associated with the data. The security component produces an event log that is stored and updated as new events are detected. Although monitoring of the security events is primarily directed towards data, hardware defects may also create security events. For example, physical damage, dead batteries or other defective hardware in the mobile device can cause the security component to detect a security event.),
and the one or more processors are individually or collectively further operable to execute the code to cause the UE to: receive one or more control signals from the network entity indicative of occurrence of a security threat based at least in part on transmitting the data collected by the UE (See ¶ [0039], Teaches that The remote security component may receive information about both security event and non-security-event data received by the mobile device. Based upon this cumulative data, the remote security component can determine an overall security status or assessment for the mobile device 327. If the server 111 were to determine that the security component on the mobile device 101 was unable to stop any sort of security attack or virus/malware infection, the server 111 would update the device's security status accordingly. If needed, the server 111 may transmit commands to the device to remediate one or more security problems associated with events 317. These commands may be specialized for the particular virus or other security threat identified by the processing of one or more security events. The information gathering component can process the event information to produce charts, graphs, text outputs and graphical representations for the security state for the mobile device 101. The information gathering component at the server may also produce a log of security events for the mobile device).
As to claim 5, the combination of Mahaffey et al. and Diehl et al. teaches the user equipment (UE) according to claim 1 above. Mahaffey et al. further teaches wherein, to detect occurrence of the security event, the one or more processors are individually or collectively operable to execute the code to cause the UE to: detect a message, a header content, a message sequence, or a delay in accordance with an attack signature database at the UE; or detect a difference in a signal strength, a power level, or both between contiguous signals from a network entity that satisfies a threshold difference, wherein at least one of the message, the header content, the message sequence, the delay, or the difference in the signal strength, the power level, or both is associated with the security event (See ¶¶ [0024], Teaches that the local security component on the mobile device can identify security events by analyzing files or data stored on the device, messages such as function or system calls between components on the device, or network data flowing into or out of the device for security events.).
As to claim 8, the combination of Mahaffey et al. and Diehl et al. teaches the user equipment (UE) according to claim 1 above. Mahaffey et al. further teaches wherein, to transmit, to the wireless entity, the information indicative of the occurrence of the security event, the one or more processors are individually or collectively operable to execute the code to cause the UE to: transmit the information indirectly to a network entity via a sidelink communications link or via a Wi-Fi communications link, wherein the wireless entity comprises a second UE or a Wi-Fi device; or transmit the information directly to the network entity via an uplink communications link, wherein the wireless entity comprises the network entity (See ¶¶ [0033], [0020], Figure 2, Teaches that In addition to displaying the security status on the mobile device, the security status as well as events and event data can be forwarded to a server 111. The server may further process the events, event data, and security status information and/or output the status information to other electronic devices. A security status signal can be transmitted to a client computer 233 associated with the mobile device 101 through a security widget).
As to claim 11, Mahaffey et al. teaches a network entity, comprising: one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to cause the network entity to: receive information indicative of occurrence of a security event by a user equipment (UE), the security event indicative of an attack against a security vulnerability associated with the UE, and the information representative of at least data collected by the UE that triggered detection of the security event (See ¶¶ [0030], [0031], Figure 2, Teaches that The local security component analyzes aspects of the data to determine if a security event is detected 213. If the local security component onboard the mobile device detects a security problem with the data, one or more security events may be triggered. The local security component automatically performs defensive actions to protect the mobile device 101 from the immediate threat. The event or events generated will be processed 217 in order to determine if further actions need to be taken. The type of defensive processing performed by the local security component depends upon the context and type of data being analyzed. For example, the system can drop network data considered to be harmful or may disconnect one or more protocol connections associated with the data. The security component produces an event log that is stored and updated as new events are detected. Although monitoring of the security events is primarily directed towards data, hardware defects may also create security events. For example, physical damage, dead batteries or other defective hardware in the mobile device can cause the security component to detect a security event);
and perform, based at least in part on receiving the information, a security operation corresponding to the security event (See ¶ [0039], Teaches that The remote security component may receive information about both security event and non-security-event data received by the mobile device. Based upon this cumulative data, the remote security component can determine an overall security status or assessment for the mobile device 327. If the server 111 were to determine that the security component on the mobile device 101 was unable to stop any sort of security attack or virus/malware infection, the server 111 would update the device's security status accordingly. If needed, the server 111 may transmit commands to the device to remediate one or more security problems associated with events 317. These commands may be specialized for the particular virus or other security threat identified by the processing of one or more security events. The information gathering component can process the event information to produce charts, graphs, text outputs and graphical representations for the security state for the mobile device 101. The information gathering component at the server may also produce a log of security events for the mobile device).
However, it does not expressly teach the details of further representative of a source of the security event.
Diehl et al., from analogous art, teaches further representative of a source of the security event (See ¶¶ [0033]-[0034], [0037], Teaches that Events can include any observable and/or detectable type of computing operation, behavior, or other action that may occur on one or more client devices 104. Events can include events and behaviors associated with Internet Protocol (IP) connections, other network connections, Domain Name System (DNS) requests, operating system functions, file operations, registry changes, process executions, hardware operations, such as virtual or physical hardware configuration changes, and/or any other type of event. By way of non-limiting examples, an event may be that a process opened a file, that a process initiated a DNS request, that a process opened an outbound connection to a certain IP address, that there was an inbound IP connection, that values in an operating system registry were changed, or be any other observable or detectable occurrence on a client device 104. In some examples, events based on other such observable or detectable occurrences can be physical and/or hardware events, for instance that a Universal Serial Bus (USB) memory stick or other USB device was inserted or removed, that a network cable was plugged in or unplugged, that a cabinet door or other component of a client device 104 was opened or closed, or any other physical or hardware-related event. Events that occur on client devices 104 can be detected or observed by event detectors 124 of security agents 108 on those client devices 104. Event data 122 about locally-occurring events can also, or alternately, be sent by a security agent 108 on a client device 104 to the security network 106, such that the event data 122 can be processed by a cloud instance of the compute engine 102 and/or other cloud elements of the distributed security system 100.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Diehl et al. into Mahaffey et al. in order to detect and/or analyze security threats (See Diehl et al. ¶ [0021]).
As to claim 12, the combination of Mahaffey et al. and Diehl et al. teaches the network entity according to claim 11 above. Mahaffey et al. further teaches wherein the one or more processors are individually or collectively further operable to execute the code to cause the network entity to: transmit one or more signals that are indicative of one or more security events to be reported by the UE, wherein receiving the information indicative of the detection of the security event is based at least in part on transmitting the one or more signals (See ¶ [0039], Teaches that The remote security component may receive information about both security event and non-security-event data received by the mobile device. Based upon this cumulative data, the remote security component can determine an overall security status or assessment for the mobile device 327. If the server 111 were to determine that the security component on the mobile device 101 was unable to stop any sort of security attack or virus/malware infection, the server 111 would update the device's security status accordingly. If needed, the server 111 may transmit commands to the device to remediate one or more security problems associated with events 317. These commands may be specialized for the particular virus or other security threat identified by the processing of one or more security events. The information gathering component can process the event information to produce charts, graphs, text outputs and graphical representations for the security state for the mobile device 101. The information gathering component at the server may also produce a log of security events for the mobile device).
As to claim 13, the combination of Mahaffey et al. and Diehl et al. teaches the network entity according to claim 12 above. Mahaffey et al. further teaches wherein, to receive the information indicative of the occurrence of the security event, the one or more processors are individually or collectively further operable to execute the code to cause the network entity to receive, from the UE and based at least in part on transmitting the one or more signals, the data collected by the UE, and the one or more processors are individually or collectively further operable to execute the code to cause the network entity to: detect occurrence of a security threat that is indicative of the attack against the security vulnerability associated with the UE, wherein detection of the occurrence of the security threat is based at least in part on receiving the data collected by the UE; and transmit one or more control signals to the UE indicative of the occurrence of the security threat based at least in part on detecting the occurrence of the security threat (See ¶ [0039], Teaches that The remote security component may receive information about both security event and non-security-event data received by the mobile device. Based upon this cumulative data, the remote security component can determine an overall security status or assessment for the mobile device 327. If the server 111 were to determine that the security component on the mobile device 101 was unable to stop any sort of security attack or virus/malware infection, the server 111 would update the device's security status accordingly. If needed, the server 111 may transmit commands to the device to remediate one or more security problems associated with events 317. These commands may be specialized for the particular virus or other security threat identified by the processing of one or more security events. The information gathering component can process the event information to produce charts, graphs, text outputs and graphical representations for the security state for the mobile device 101. The information gathering component at the server may also produce a log of security events for the mobile device).
As to claim 14, the combination of Mahaffey et al. and Diehl et al. teaches the network entity according to claim 11 above. Mahaffey et al. further teaches wherein, to receive, from the UE, the information indicative of the security event, the one or more processors are individually or collectively operable to execute the code to cause the network entity to: receive the information indirectly from the UE via a sidelink communications link from a second UE or via a Wi-Fi communications link from a Wi-Fi device; or receive the information directly from the UE via an uplink communications link (See ¶¶ [0033], [0020], Figure 2, Teaches that In addition to displaying the security status on the mobile device, the security status as well as events and event data can be forwarded to a server 111. The server may further process the events, event data, and security status information and/or output the status information to other electronic devices. A security status signal can be transmitted to a client computer 233 associated with the mobile device 101 through a security widget).
As to claim 17, Mahaffey et al. teaches a method for wireless communications by a user equipment (UE), comprising: detecting occurrence of a security event that is indicative of an attack against a security vulnerability associated with the UE, wherein detection of the occurrence of the security event is based at least in part on data collected by the UE (See ¶¶ [0030], [0031], Figure 2, Teaches that The local security component analyzes aspects of the data to determine if a security event is detected 213. If the local security component onboard the mobile device detects a security problem with the data, one or more security events may be triggered. The local security component automatically performs defensive actions to protect the mobile device 101 from the immediate threat. The event or events generated will be processed 217 in order to determine if further actions need to be taken. The type of defensive processing performed by the local security component depends upon the context and type of data being analyzed. For example, the system can drop network data considered to be harmful or may disconnect one or more protocol connections associated with the data. The security component produces an event log that is stored and updated as new events are detected. Although monitoring of the security events is primarily directed towards data, hardware defects may also create security events. For example, physical damage, dead batteries or other defective hardware in the mobile device can cause the security component to detect a security event.);
transmitting, to a wireless entity and based at least in part on detection of the security event, information indicative of the occurrence of the security event, the information representative of at least the data collected by the UE that triggered detection of the security event (See ¶¶ [0033], [0020], Figure 2, Teaches that In addition to displaying the security status on the mobile device, the security status as well as events and event data can be forwarded to a server 111. The server may further process the events, event data, and security status information and/or output the status information to other electronic devices. A security status signal can be transmitted to a client computer 233 associated with the mobile device 101 through a security widget.)
and performing a security operation corresponding to the security event (See ¶ [0039], Teaches that The remote security component may receive information about both security event and non-security-event data received by the mobile device. Based upon this cumulative data, the remote security component can determine an overall security status or assessment for the mobile device 327. If the server 111 were to determine that the security component on the mobile device 101 was unable to stop any sort of security attack or virus/malware infection, the server 111 would update the device's security status accordingly. If needed, the server 111 may transmit commands to the device to remediate one or more security problems associated with events 317. These commands may be specialized for the particular virus or other security threat identified by the processing of one or more security events. The information gathering component can process the event information to produce charts, graphs, text outputs and graphical representations for the security state for the mobile device 101. The information gathering component at the server may also produce a log of security events for the mobile device).
However, it does not expressly teach the details of further representative of a source of the security event.
Diehl et al., from analogous art, teaches further representative of a source of the security event (See ¶¶ [0033]-[0034], [0037], Teaches that Events can include any observable and/or detectable type of computing operation, behavior, or other action that may occur on one or more client devices 104. Events can include events and behaviors associated with Internet Protocol (IP) connections, other network connections, Domain Name System (DNS) requests, operating system functions, file operations, registry changes, process executions, hardware operations, such as virtual or physical hardware configuration changes, and/or any other type of event. By way of non-limiting examples, an event may be that a process opened a file, that a process initiated a DNS request, that a process opened an outbound connection to a certain IP address, that there was an inbound IP connection, that values in an operating system registry were changed, or be any other observable or detectable occurrence on a client device 104. In some examples, events based on other such observable or detectable occurrences can be physical and/or hardware events, for instance that a Universal Serial Bus (USB) memory stick or other USB device was inserted or removed, that a network cable was plugged in or unplugged, that a cabinet door or other component of a client device 104 was opened or closed, or any other physical or hardware-related event. Events that occur on client devices 104 can be detected or observed by event detectors 124 of security agents 108 on those client devices 104. Event data 122 about locally-occurring events can also, or alternately, be sent by a security agent 108 on a client device 104 to the security network 106, such that the event data 122 can be processed by a cloud instance of the compute engine 102 and/or other cloud elements of the distributed security system 100.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Diehl et al. into Mahaffey et al. in order to detect and/or analyze security threats (See Diehl et al. ¶ [0021]).
As to claim 18, the combination of Mahaffey et al. and Diehl et al. teaches the method according to claim 17 above. Mahaffey et al. further teaches further comprising: receiving one or more first signals that are indicative of one or more security events to be reported by the UE, wherein the data is collected by the UE based at least in part on the one or more first signals (See ¶¶ [0030], [0031], Figure 2, Teaches that The local security component analyzes aspects of the data to determine if a security event is detected 213. If the local security component onboard the mobile device detects a security problem with the data, one or more security events may be triggered. The local security component automatically performs defensive actions to protect the mobile device 101 from the immediate threat. The event or events generated will be processed 217 in order to determine if further actions need to be taken. The type of defensive processing performed by the local security component depends upon the context and type of data being analyzed. For example, the system can drop network data considered to be harmful or may disconnect one or more protocol connections associated with the data. The security component produces an event log that is stored and updated as new events are detected. Although monitoring of the security events is primarily directed towards data, hardware defects may also create security events. For example, physical damage, dead batteries or other defective hardware in the mobile device can cause the security component to detect a security event.).
As to claim 19, the combination of Mahaffey et al. and Diehl et al. teaches the method according to claim 18 above. Mahaffey et al. further teaches wherein transmitting the information indicative of the occurrence of the security event comprises transmitting, to a network entity and based at least in part on receiving the one or more first signals, the data collected by the UE (See ¶¶ [0030], [0031], Figure 2, Teaches that The local security component analyzes aspects of the data to determine if a security event is detected 213. If the local security component onboard the mobile device detects a security problem with the data, one or more security events may be triggered. The local security component automatically performs defensive actions to protect the mobile device 101 from the immediate threat. The event or events generated will be processed 217 in order to determine if further actions need to be taken. The type of defensive processing performed by the local security component depends upon the context and type of data being analyzed. For example, the system can drop network data considered to be harmful or may disconnect one or more protocol connections associated with the data. The security component produces an event log that is stored and updated as new events are detected. Although monitoring of the security events is primarily directed towards data, hardware defects may also create security events. For example, physical damage, dead batteries or other defective hardware in the mobile device can cause the security component to detect a security event.),
and wherein the method further comprises: receiving one or more control signals from the network entity indicative of occurrence of a security threat based at least in part on transmitting the data collected by the UE (See ¶ [0039], Teaches that The remote security component may receive information about both security event and non-security-event data received by the mobile device. Based upon this cumulative data, the remote security component can determine an overall security status or assessment for the mobile device 327. If the server 111 were to determine that the security component on the mobile device 101 was unable to stop any sort of security attack or virus/malware infection, the server 111 would update the device's security status accordingly. If needed, the server 111 may transmit commands to the device to remediate one or more security problems associated with events 317. These commands may be specialized for the particular virus or other security threat identified by the processing of one or more security events. The information gathering component can process the event information to produce charts, graphs, text outputs and graphical representations for the security state for the mobile device 101. The information gathering component at the server may also produce a log of security events for the mobile device).
Claims 4, 7, 9, 15, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 20140373162 A1) and Diehl et al. (US 20210326453 A1) and further in view of DAS et al. (US 20220377559 A1).
As to claim 4, the combination of Mahaffey et al. and Diehl et al. teaches the user equipment (UE) according to claim 2 above. However, it does not expressly teach the details of wherein the one or more processors are individually or collectively further operable to execute the code to cause the UE to: measure, based at least in part on receiving the one or more first signals, one or more second signals, wherein the data collected by the UE is based at least in part on measuring the one or more second signals.
DAS et al., from analogous art, teaches wherein the one or more processors are individually or collectively further operable to execute the code to cause the UE to: measure, based at least in part on receiving the one or more first signals, one or more second signals, wherein the data collected by the UE is based at least in part on measuring the one or more second signals (See ¶ [0081], Teaches that the classification of the threat entity 804 may be based on a measured RSSI of the threat entity 804, such as over the entire bandwidth (e.g., wideband) of the VV 802 or over each subchannel (e.g., narrowband)).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of DAS et al. into the combination of Mahaffey et al. and Diehl et al. in order to initiate a mitigation action in response to receiving the message to avoid or mitigate contact with the one or more object data signals that interferes with wireless resources (See DAS et al. ¶ [0010]).
As to claim 7, the combination of Mahaffey et al. and Diehl et al. teaches the user equipment (UE) according to claim 1 above. However, it does not expressly teach the details of wherein, to detect occurrence of the security event, the one or more processors are individually or collectively operable to execute the code to cause the UE to: detect a measured state of a network entity that is inconsistent with a measured state of the UE, wherein the measured state comprises a location, a movement, a mobility, or any combination thereof.
DAS et al., from analogous art, teaches wherein, to detect occurrence of the security event, the one or more processors are individually or collectively operable to execute the code to cause the UE to: detect a measured state of a network entity that is inconsistent with a measured state of the UE, wherein the measured state comprises a location, a movement, a mobility, or any combination thereof (See ¶¶ [0081]-[0082], Teaches that After detection of the threat entity 804, the VV 802 may be configured to classify the type of threat entity 804, as being at least one of a DoS attacker, a misbehaving vehicle, a jammer, an OOB interferer, a WAN jammer, or a GNSS jammer. The VV 802 may classify the type of threat entity 804 based on the data received from the threat entity 804. The data received from the threat entity 804 may include data that is inconsistent with projected data for wireless devices. For example, the data may include erroneous or implausible location data or may include values for a speed or heading of the threat entity 804 that are well beyond the actual speed or head. The VV 802 may include a confidence value associated with the classification of the threat entity 804. In some aspects, the classification of the threat entity 804 may be based on a measured RSSI of the threat entity 804, such as over the entire bandwidth (e.g., wideband) of the VV 802 or over each subchannel (e.g., narrowband). In some aspects, to report the characteristics of the threat entity 804, a hierarchical data structure may be used that comprises the report of the characteristics of the threat entity 804. In some instances, the report may include information related to the location, speed, heading, or timestamp of the VV 802. Information related to the measured RSSI of the threat entity 804 at the VV 802 may be included in the report.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of DAS et al. into the combination of Mahaffey et al. and Diehl et al. in order to initiate a mitigation action in response to receiving the message to avoid or mitigate contact with the one or more object data signals that interferes with wireless resources (See DAS et al. ¶ [0010]).
As to claim 9, the combination of Mahaffey et al. and Diehl et al. teaches the user equipment (UE) according to claim 1 above. However, it does not expressly teach the details of wherein the information indicative of the occurrence of the security event comprises a non-access stratum (NAS) or access stratum (AS) security mode control (SMC) failure, a NAS transmission failure, a count value leap, a quantity of NAS retransmissions, a quantity of tracking area code (TAC) changes satisfying a threshold, an integrity check failure log associated with a radio resource control (RRC) layer or a user plane, one or more broadcast messages received at the UE, or any combination thereof.
DAS et al., from analogous art, teaches wherein the information indicative of the occurrence of the security event comprises a non-access stratum (NAS) or access stratum (AS) security mode control (SMC) failure, a NAS transmission failure, a count value leap, a quantity of NAS retransmissions, a quantity of tracking area code (TAC) changes satisfying a threshold, an integrity check failure log associated with a radio resource control (RRC) layer or a user plane, one or more broadcast messages received at the UE, or any combination thereof (See ¶¶ [0090], [0087], Teaches that the first wireless device 1502 may detect a threat entity transmitting data that interferes with transmission of BSMs. The first wireless device may detect the presence of the threat entity and extract relevant information related to the threat entity. The relevant information may vary based on the threat entity. In some aspects, the threat entity may comprise a DoS attacker, a jammer, a misbehaving vehicle, an OOB interferer, a WAN jammer, or a GNSS jammer. The relevant information may be shared, by the first wireless device, with other wireless devices beyond a threat zone of the threat entity.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of DAS et al. into the combination of Mahaffey et al. and Diehl et al. in order to initiate a mitigation action in response to receiving the message to avoid or mitigate contact with the one or more object data signals that interferes with wireless resources (See DAS et al. ¶ [0010]).
As to claim 15, the combination of Mahaffey et al. and Diehl et al. teaches the network entity according to claim 11 above. However, it does not expressly teach the details of wherein the information indicative of the occurrence of the security event comprises a non-access stratum (NAS) or access stratum (AS) security mode control (SMC) failure, a NAS transmission failure, a count value leap, a quantity of NAS retransmissions, a quantity of tracking area code (TAC) changes satisfying a threshold, an integrity check failure log associated with a radio resource control (RRC) layer or a user plane, one or more broadcast messages received at the UE, or any combination thereof.
DAS et al., from analogous art, teaches wherein the information indicative of the occurrence of the security event comprises a non-access stratum (NAS) or access stratum (AS) security mode control (SMC) failure, a NAS transmission failure, a count value leap, a quantity of NAS retransmissions, a quantity of tracking area code (TAC) changes satisfying a threshold, an integrity check failure log associated with a radio resource control (RRC) layer or a user plane, one or more broadcast messages received at the UE, or any combination thereof (See ¶¶ [0090], [0087], Teaches that the first wireless device 1502 may detect a threat entity transmitting data that interferes with transmission of BSMs. The first wireless device may detect the presence of the threat entity and extract relevant information related to the threat entity. The relevant information may vary based on the threat entity. In some aspects, the threat entity may comprise a DoS attacker, a jammer, a misbehaving vehicle, an OOB interferer, a WAN jammer, or a GNSS jammer. The relevant information may be shared, by the first wireless device, with other wireless devices beyond a threat zone of the threat entity.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of DAS et al. into the combination of Mahaffey et al. and Diehl et al. in order to initiate a mitigation action in response to receiving the message to avoid or mitigate contact with the one or more object data signals that interferes with wireless resources (See DAS et al. ¶ [0010]).
As to claim 20, the combination of Mahaffey et al. and Diehl et al. teaches the method according to claim 18 above. However, it does not expressly teach the details of further comprising: measuring, based at least in part on receiving the one or more first signals, one or more second signals, wherein the data collected by the UE is based at least in part on measuring the one or more second signals.
DAS et al., from analogous art, teaches further comprising: measuring, based at least in part on receiving the one or more first signals, one or more second signals, wherein the data collected by the UE is based at least in part on measuring the one or more second signals (See ¶ [0081], Teaches that the classification of the threat entity 804 may be based on a measured RSSI of the threat entity 804, such as over the entire bandwidth (e.g., wideband) of the VV 802 or over each subchannel (e.g., narrowband)).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of DAS et al. into the combination of Mahaffey et al. and Diehl et al. in order to initiate a mitigation action in response to receiving the message to avoid or mitigate contact with the one or more object data signals that interferes with wireless resources (See DAS et al. ¶ [0010]).
Claims 6, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 20140373162 A1) and Diehl et al. (US 20210326453 A1) and further in view of Tyagi et al. (US 20220277078 A1).
As to claim 6, the combination of Mahaffey et al. and Diehl et al. teaches the user equipment (UE) according to claim 1 above. However, it does not expressly teach the details of wherein, to detect occurrence of the security event, the one or more processors are individually or collectively operable to execute the code to cause the UE to: detect a message pattern from a second wireless entity that is different than a previous message pattern from the second wireless entity, wherein the message pattern comprises a message, header content, a message sequence, or a delay.
Tyagi et al., from analogous art, teaches wherein, to detect occurrence of the security event, the one or more processors are individually or collectively operable to execute the code to cause the UE to: detect a message pattern from a second wireless entity that is different than a previous message pattern from the second wireless entity, wherein the message pattern comprises a message, header content, a message sequence, or a delay (See ¶¶ [0076], [0081], [0008], [0082] Teaches that one or more computing device processors (e.g., processing unit 202) may receive a first security event captured by a first security operation associated with a computing device, and a second security event captured by a second security operation associated with the computing device. For example, the first security event and/or the second security event may be received using one or more computing device processors associated with the end point device 125 and/or other computing device processors coupled to the network 110 of FIG. 1. In one embodiment, the one or more computing device processors may execute instructions associated with/or in cooperation with security infrastructure 140 to capture the first security event and/or the second security event using one or more of the security infrastructure's security products or some other security software or application running on a computing system. The captured first security event and second security event may be logged into a database (e.g., local record repository 103, public record repository 113, etc.) by the one or more computing device processors. For instance, the security infrastructure 140 may capture the first security event and/or the second security event following which the first security event and the second security event are logged/recorded into a log such as an antivirus log, a web application firewall log, an intrusion prevention system log, an intrusion detection system log, a web server log, an operating system log, etc. In some implementations, other data, other than the security event can be recorded in association with each security event. This data could include, among other things, a time stamp for each recorded security event, one or more identifiers for each security event, specific assets (i.e., hardware and/or software resources) of the computing device associated with the security event, etc. Turning back to block 404 of flowchart 400, one or more computing device processors may map the first security event to first security data in an attack repository, and the second security event to second security data in the attack repository. In some implementations, the attack repository may comprise attack data captured from multiple computing devices associated with different entities. For example, the attack repository may comprise the public record repository 113 shown in FIG. 1. The mapping performed may, for example be facilitated by data imbedded in the log of each first security event and each second security event. For instance, the one or more computing device processors may leverage one or more identifiers stored in association with each first security event and each second security event in executing the mapping. The one or more identifiers for each first security event and/or each second security event may be generated based on a security event assessment tool such as a machine learning feature of the security infrastructure 140 that assesses contextual information and/or other data associated with how the first security event and/or the second security event occurred in the first place. Determine based on the mapping, one or more attack execution operations for executing the attack campaign associated with the first security event and the second security event.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tyagi et al. into the combination of Mahaffey et al. and Diehl et al. in order to map the security events, from multiple computing devices, to security data in an attack repository (See Tyagi et al. ¶ [0008]).
As to claim 16, the combination of Mahaffey et al. and Diehl et al. teaches the network entity according to claim 11 above. However, it does not expressly teach the details of wherein the one or more processors are individually or collectively further operable to execute the code to cause the network entity to: identify a security attack based at least in part on receiving the information indicative of occurrence of a security event by the UE and second information indicative of occurrences of the security event by one or more second UEs, wherein performing the security operation is based at least in part on identifying the security attack, and wherein the security operation is associated with the UE and the one or more second UEs.
Tyagi et al., from analogous art, teaches wherein the one or more processors are individually or collectively further operable to execute the code to cause the network entity to: identify a security attack based at least in part on receiving the information indicative of occurrence of a security event by the UE and second information indicative of occurrences of the security event by one or more second UEs, wherein performing the security operation is based at least in part on identifying the security attack, and wherein the security operation is associated with the UE and the one or more second UEs (See ¶¶ [0076], [0081], [0008], [0082] Teaches that one or more computing device processors (e.g., processing unit 202) may receive a first security event captured by a first security operation associated with a computing device, and a second security event captured by a second security operation associated with the computing device. For example, the first security event and/or the second security event may be received using one or more computing device processors associated with the end point device 125 and/or other computing device processors coupled to the network 110 of FIG. 1. In one embodiment, the one or more computing device processors may execute instructions associated with/or in cooperation with security infrastructure 140 to capture the first security event and/or the second security event using one or more of the security infrastructure's security products or some other security software or application running on a computing system. The captured first security event and second security event may be logged into a database (e.g., local record repository 103, public record repository 113, etc.) by the one or more computing device processors. For instance, the security infrastructure 140 may capture the first security event and/or the second security event following which the first security event and the second security event are logged/recorded into a log such as an antivirus log, a web application firewall log, an intrusion prevention system log, an intrusion detection system log, a web server log, an operating system log, etc. In some implementations, other data, other than the security event can be recorded in association with each security event. This data could include, among other things, a time stamp for each recorded security event, one or more identifiers for each security event, specific assets (i.e., hardware and/or software resources) of the computing device associated with the security event, etc. Turning back to block 404 of flowchart 400, one or more computing device processors may map the first security event to first security data in an attack repository, and the second security event to second security data in the attack repository. In some implementations, the attack repository may comprise attack data captured from multiple computing devices associated with different entities. For example, the attack repository may comprise the public record repository 113 shown in FIG. 1. The mapping performed may, for example be facilitated by data imbedded in the log of each first security event and each second security event. For instance, the one or more computing device processors may leverage one or more identifiers stored in association with each first security event and each second security event in executing the mapping. The one or more identifiers for each first security event and/or each second security event may be generated based on a security event assessment tool such as a machine learning feature of the security infrastructure 140 that assesses contextual information and/or other data associated with how the first security event and/or the second security event occurred in the first place. Determine based on the mapping, one or more attack execution operations for executing the attack campaign associated with the first security event and the second security event.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tyagi et al. into the combination of Mahaffey et al. and Diehl et al. in order to map the security events, from multiple computing devices, to security data in an attack repository (See Tyagi et al. ¶ [0008]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 20140373162 A1) and Diehl et al. (US 20210326453 A1) and further in view of Glatfelter et al. (US 20190020669 A1).
As to claim 10, the combination of Mahaffey et al. and Diehl et al. teaches the user equipment (UE) according to claim 1 above. However, it does not expressly teach the details of wherein the security event is detected via an artificial intelligence (AI) model at the UE.
Glatfelter et al., from analogous art, teaches wherein the security event is detected via an artificial intelligence (AI) model at the UE (See ¶¶ [0026], Teaches that the UE 150 is enhanced with the adaptive security system 170 that includes the MLF 210 coupled with modules 360-365. More particularly, the adaptive security system 170 includes an activity monitoring module 360, an anomaly detection module 361, a threat response module 362, an initialization module 363, a honeypot module 364, and a report module 365. Each of the modules 360-365 may be implemented in any combination of hardware, firmware, and software and may interface with, or be implemented in, the MLF 210 to perform machine learning techniques for detecting and responding to security threats. Components of the adaptive security system 170 and/or MLF 210 may be implemented within parts of the operating system (OS) 310, the kernel 312 of the OS 310 (e.g., in protected area of memory 306 on top of kernel 312 of the OS 310, a hardware abstraction layer (HAL) 318, within separate programs or applications, in specialized hardware buffers or processors, or any combination thereof. Additionally, it is contemplated that the components of the adaptive security system 170 and/or MLF 210 may be stored in memory 306 for use by the processor 302 or temporarily loaded in RAM 338 for use by the processor 302.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Glatfelter et al. into the combination of Mahaffey et al. and Diehl et al. in order to determine whether the anomalous use is representative of a security threat, and to instruct the user device to perform one or more automatic actions to respond to the security threat. (See Glatfelter et al. ¶ [0004]).
Conclusion
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 James R Hollister whose telephone number is (571)270-3152. The examiner can normally be reached Mon - Fri 7:30 am - 4: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, Philip Chea can be reached at (571) 272-3951. 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.
James Hollister
/J.R.H./Examiner, Art Unit 2499 9/8/26
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights