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 .
Response to Arguments
Applicant’s arguments with respect to claims 1-25 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Objections
Claim 21 is objected to because of the following informalities: There word “the” is duplicated. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 16 recites the limitation "the abstraction layer" in line 2. There is insufficient antecedent basis for this limitation in the claim and parent claim.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 6, 7-11, 13, 14, 17-19, 21-24 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Lukin et al (US 20150271138 A1; hereinafter “ Lukin”).
Regarding claim 1, a computer-implemented method for defending, preventing, and/or mitigating short message service (SMS) based activities (see Lukin, at least fig. 8-15), comprising:
monitoring, by a security software component on an application processor of a computing device configured to access a radio network, data related to SMS interactions over the radio network (see Lukin, ¶[0039] In yet another more specific embodiment, the firewall is an application instantiated on the wireless mobile communications device……….[0075] In other exemplary implementations where covert or involuntary deployment and operation are not factors, or where the device user is given at least some control over the SMS Firewall functionality, the SMS Firewall provides a user interface that can be used to alert the device user to SMS message traffic.),
wherein the monitoring of the data comprises monitoring communications across an inter-processor interface connecting a cellular processor of a radio hardware and the application processor configured to execute user-space applications in the application layer (see Lukin, fig. 4 SMS Firewall is placed such that it connects phone radio hardware (shown as connection to other devices) and applications 4140, further “[0052] FIGS. 7a, 7b, 7c and 7d depict four schematic diagrams showing the components involved in reception and processing of SMS messages, and how an SMS Firewall can be inserted at various points in this processing in accordance with one embodiment of the invention.”);
based on the monitoring, detecting a potential activity associated with an SMS interaction (see Lukin, fig. 8-15);
and providing an indication of the potential activity (see Lukin, ¶[0196] In alternative embodiments, a Threat Level comprises a more complex object, such as an XML file, and/or an executable software object that specifies or implements a plurality of changes to be undertaken by the SMS Firewall as a result of the particular Threat Level being made active. Such changes can comprise activation or deactivation of one or more behavior profiles, download or definition of additional or replacement behavior profiles, deletion of existing behavior profiles, or alterations to device configuration or functioning outside of those specified by behavior profiles, such as by altering the configuration of device applications, installation of additional software, or removal of existing software as well as such actions as alerting of the device user or the monitoring console. For example, in response to a threat of device tracking by hostile entities, an application that is used to report device location, such as a GPS logger application, can be shut down or deleted, or can be reconfigured to report incorrect location data.)
Regarding claims 13 and 20, the limitations have been addressed in the cited sections of the rejection of claim 1.
Regarding claim 2, the computer-implemented method of claim 1, further comprising:mitigating a potential malicious activity (see Lukin, ¶[0165, 0208-0209])
Regarding claim 3, the computer-implemented method of claim 2, wherein the mitigating of the potential malicious activity further comprises one of blocking, allowing, rewriting, or forwarding of the SMS interaction (see Lukin, ¶[0165, 0208-0209]).
Regarding claim 4, the computer-implemented method of claim 1, wherein the providing of the indication of the potential activity further comprising: generating an alert associated with a potential malicious activity (see Lukin, ¶[0165, 0208-0209]).
Regarding claim 6, the computer-implemented method of claim 1, further comprising: identifying a source of an outbound SMS based on inter-process communication calls to a user-space application (see Lukin, ¶[0067], the SMS Firewall (4110) functionally adds itself into the wireless device's (4100) SMS message processing scheme and becomes a part of it. In some exemplary systems, the SMS Firewall (4100) also mediates messages sent between processes running on the mobile device (4140), whether they are running on the mobile device handset (4150), or communicating between the SIM card (4130) and mobile device handset (4150) components).
Regarding claim 7, the computer-implemented method of claim 1, further comprising: monitoring baseband traffic based on a diagnostic interface (see Lukin, ¶0211 and tables afterwards, discloses analyzing bit pattern and body of SMS message, therefore baseband, and ¶0197 discloses through a user interface).
Regarding claim 8, the computer-implemented method of claim 1, further comprising: interacting with one or more user-space applications to track a context associated with the SMS interaction (see Lukin, table 2).
Regarding claim 9, the computer-implemented method of claim 1, wherein the detecting of the potential activity comprises detecting a baseband-only malicious attack (see Lukin, ¶0211 and tables afterwards, discloses analyzing bit pattern and body of SMS message, therefore baseband, and ¶0197 discloses through a user interface).
Regarding claim 10, the computer-implemented method of claim 1, wherein the data related to the SMS interactions comprises context data (see Lukin, table 2).
Regarding claim 11, the computer-implemented method of claim 10, further comprising: retrieving the context data from a system layer, wherein the context data is associated with a broadcast station, and wherein the context data relates to one or more of a signal strength or a broadcast parameter (see Lukin, ¶ [0055] FIG. 10 depicts a flowchart that describes the Process by SMS Message Type step of FIG. 8 in accordance with one embodiment of the invention.).
Regarding claim 14, the computing device of claim 13,wherein the application processor is configured to execute an operating system (see Lukin, fig. 4 4140, 4120).
Regarding claim 17, the computing device of claim 13, the operations further comprising: mitigating a potential malicious activity (see Lukin, ¶[0062] The current exemplary illustrative non-limiting implementation of the technology herein provides systems, methods, procedures, processes, apparatus, and techniques that enable monitoring, identification, limiting, and, in some cases, blocking of SMS message traffic to and from wireless mobile devices. Typically, SMS messages are detected and monitored, and most forms can be limited or blocked at the SMSC;)
Regarding claim 18, the computing device of claim 13, wherein the operations providing the indication of the potential activity further comprising: generating an alert associated with a potential malicious activity (see Lukin, ¶[0196] In alternative embodiments, a Threat Level comprises a more complex object, such as an XML file, and/or an executable software object that specifies or implements a plurality of changes to be undertaken by the SMS Firewall as a result of the particular Threat Level being made active. Such changes can comprise activation or deactivation of one or more behavior profiles, download or definition of additional or replacement behavior profiles, deletion of existing behavior profiles, or alterations to device configuration or functioning outside of those specified by behavior profiles, such as by altering the configuration of device applications, installation of additional software, or removal of existing software as well as such actions as alerting of the device user or the monitoring console. For example, in response to a threat of device tracking by hostile entities, an application that is used to report device location, such as a GPS logger application, can be shut down or deleted, or can be reconfigured to report incorrect location data.).
Regarding claim 19, the limitations have been addressed in the rejection of claim 10.
Regarding claim 21, the non-transitory computer-readable medium of claim 20, wherein the the application processor configured to execute an operating system (OS) of the computing device (see Lukin, fig. 4 4140 4120 ).
Regarding claim 22, the computer-implemented method of claim 1, Lukin discloses wherein the security software component further comprises an inline mediator (see Lukin, ¶[0172], discloses a part of the firewall can stop functioning of the RIL), and wherein the method further comprises: instrumenting, by the inline mediator, logic of the radio interface layer (RIL) to provide inline control (see Lukin, ¶[0172], discloses a part of the firewall can stop functioning of the RIL); and automatically mitigating the potential activity by manipulating the instrumented logic of the RIL (see Lukin, ¶[0172] As described above, incoming and outgoing SMS message traffic can be blocked by deleting messages in the SMS Firewall processing. This method is necessary when a subset of messages must be blocked, but when all messages are to be blocked, an alternative method involves the SMS Firewall turning off the wireless mobile device's radio).
Regarding claim 23, the computer-implemented method of claim 22, wherein the automatically mitigating comprises intercepting or blocking SMS traffic associated with the SMS interaction that is handled without involvement from user-space applications such that a user of the computing device is unaware of the SMS traffic (see Lukin, ¶[0188] .. In some exemplary embodiments, the modules to be provided to the SMS Firewall can be determined automatically, either by the SMS Firewall or by the Monitoring and Control System. Automatic determination can be based on a plurality of factors, such as the types of messages being detected by the SMS Firewall, …)
Regarding claim 24, the computer-implemented method of claim 1, wherein detecting the potential activity comprises: parsing the SMS interaction from baseband monitor traffic (see Lukin, ¶0211-212 discloses a text pattern and binary pattern, therefore parsed and based on baseband traffic); and synthesizing structural information of an SMS payload of the parsed SMS interaction to detect the potential activity (see Lukin, ¶0211-212, applying rules for based on different sections of SMS message (body, message type etc, to determine threat).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Lukin in view of McKay (Previously cited in Final Action mailed on 4/28/2026).
Regarding claim 5, the computer-implemented method of claim 1, Lukin fails to disclose wherein the providing of the indication of the potential activity further comprising: identifying that the SMS interaction is a malicious activity initiated by a particular computing device
In the same field of endeavor, McKay discloses wherein the providing of the indication of the potential activity further comprising: identifying that the SMS interaction is a malicious activity initiated by a particular computing device (see McKay, ¶0023 Originator Address (OA) (1150) specifies the address of the originator of the message.); and triggering an action to mitigate the malicious activity (see McKay, fig. 10, 11, 14).
Given that Lukin is disclosing monitoring SMS messages from devices, further given that SMS messages originate from other devices, and given that McKay discloses monitoring SMS messages for malicious intent, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify Lukin with the SMS source identification of Mckay, thereby providing a more secure system.
Claim 12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lukin in view of Zhukov (Previously cited in Final Action mailed on 4/28/2026).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Lukin in view of Zhokov.
Regarding claim 12, the computer-implemented method of claim 1, Lukin fails to specifically disclose a specific operating system, however, Zhukov discloses wherein an operating system (OS) of the computing device comprises an Android-based OS or an Apple-based OS (see Zhukov, Col 2 lines 60-65).
It would have been obvious to someone with ordinary skill in the art prior to the effective filing date of the claimed invention to modify Lukin with the specification of an Android operating system as disclosed by Zhukov thereby conforming to Android standards.
Regarding claim 15, the limitations have been addressed in the rejection of claim 12.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over Lukin in view of Wang et al WO 2016126668 A1; hereinafter “ Wang”)
Regarding claim 25, Lukin discloses performing intent tracking determining whether the source is on a trusted list; and in an event the source is not on the trusted list, preventing an intent associated with the cellular operation from being passed to a baseband, or suspending the cellular operation, wherein the cellular operation comprises an SMS transmission or a voice call (see Lukin, ¶[0076] In some embodiments, for both covert and non-covert deployments the configuration of the SMS Firewall specifies the behavior of the SMS Firewall. For example, the configuration settings can specify that WAP Push SL messages are to be blocked, WAP Push SI messages are allowed only when they specify URLs in a particular set of domains (an "allow list", also sometimes referred to as a "whitelist") and otherwise blocked, or allowed unless they specify a URL in a particular set of domains (a "deny list", also sometimes referred to as a "blacklist"), and that the device user is not permitted to alter the allow list or deny list, or turn off WAP Push SL blocking based on either list..
Lukin fails to specifically disclose invoking a system application programming interface (API) to locate a source of an inter-process communication (IPC) call associated with a cellular operation; acquiring a process initiating the IPC call based on the located source.
In the same field of endeavor, Wang discloses invoking a system application programming interface (API) to locate a source of an inter-process communication (IPC) call associated with a cellular operation; acquiring a process initiating the IPC call based on the located source (see Wang, ¶0067 …The system cannot use the PID of the party that directly invokes the function, which is actually the Bluetooth service. Instead, the system turns to DABinder block 304, which proxies the inter-process call (IPC) from the real caller app. Specifically, the present hook calls getCallingPid (provided by Binder) to find out the app's PID and then its security context, and passes the information to the Bluetooth stack at block 310.)
Given that Lukin discloses detecting potentially malicious URL, however fails to specifically disclose how it is done, in the same field of endeavor, Wang discloses a typical process of using getCallingPid to determine a source of a call (it is also noted the instant specification discloses using getCallingPid), it would have been obvious prior to the effective filing date of the claimed invention to modify Lukin by getCallingPid process disclosed by Wang, thereby creating a more secure process.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VLADIMIR MAGLOIRE whose telephone number is (571)270-5144. The examiner can normally be reached 9-5 PM M-F.
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, Joseph Thomas can be reached at (571) 272-8004. 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.
/VLADIMIR MAGLOIRE/Supervisory Patent Examiner, Art Unit 3648
Prosecution Insights