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 application filed on 8/19/2024.
Claims 1-20 are pending and have been examined.
Claims 1-20 are rejected.
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; 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.”
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. 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” is insignificant extra-solution activity to the judicial exception. The claims are not patent eligible.
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 Objections
The Examiner recommends double checking the spelling of the claim language. For example, claim 6 “…previous message pattern form the second wireless…” should be “…previous message pattern from the second wireless…”
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
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. 102(a)(1) as being anticipated by Mahaffey et al. (US 20140373162 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.).
As to claim 2, Mahaffey 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, Mahaffey 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 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, Mahaffey 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, Mahaffey 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).
As to claim 12, Mahaffey 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, Mahaffey 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, Mahaffey 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.);
and 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.).
As to claim 18, Mahaffey 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, Mahaffey 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 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).
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 4, 7, 9, 15, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 20140373162 A1) and further in view of DAS et al. (US 20220377559 A1).
As to claim 4, Mahaffey 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 Mahaffey 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, Mahaffey 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 Mahaffey 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, Mahaffey 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 Mahaffey 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, Mahaffey 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 Mahaffey 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, Mahaffey 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 Mahaffey 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 further in view of Tyagi et al. (US 20220277078 A1).
As to claim 6, Mahaffey 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 form 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 form 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 Mahaffey 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, Mahaffey 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 Mahaffey 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 further in view of Glatfelter et al. (US 20190020669 A1).
As to claim 10, Mahaffey 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 Mahaffey 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Annapureddy (US 20240250987 A1) teaches Disclosed herein is a method, system and non-transitory computer-readable medium of detecting phishing attacks in Short Message Service (SMS) communications. The method comprises determining a sender reputation score of a sender of an SMS message and Call To Action (CTA) information embedded in the SMS message. Further, the method comprises classifying each of a message pattern, the sender, and the CTA information as one of ‘good’, ‘bad’ and ‘unknown’ based on a comparison with predetermined message pattern data, predetermined sender reputation data, and predetermined CTA information. Subsequently, the method comprises detecting that the SMS message is a ‘phishing’ message based on the classifications of the message pattern, the sender, and the CTA information. Finally, the method comprises transmitting an alert notification to a telecommunication server, upon detecting SMS message the ‘phishing’ message and automatically blocking the ‘phishing’ message from being routed to a recipient.
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 3/28/26
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499