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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/05/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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, 2, 4-8, 10, 14, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US Publication No. 2020/0045168 (“Sinha”) in view of US Publication No. 2023/0164198 (“Bhattacharjee et al.”) and further in view of US Publication No. 2009/0094666 (“Cao et al.”).
Regarding claim 1, Sinha discloses a method comprising:
receiving, at a User Equipment (UE), a telephone call from a calling party number (terminating computing device 104 or UE A receives in incoming call);
displaying, in response to the UE detecting that the calling party number is a spam candidate, an option within a native dialer application of the UE that reports the calling party number as spam (the call type is used by the UE to determine a spam candidate- fig. 5, [0059] The terminating computing device 104 may notify a user 106 of the SIP invite message by presenting caller information, including a call type value if a call info header is included in the SIP invite message, in operation 518); and
transmitting, in response to receiving user input selecting the option within the native dialer application of the UE that reports the calling party number as spam ([0017] upon establishment of a call corresponding to the call notification, presenting an option via the graphical user interface to identify the call corresponding to the call notification as an unwanted call),
a Session Initiation Protocol (SIP) update message from the native dialer application to an IP Multimedia Subsystem (IMS) ([0019] the call notification may include a SIP invite message and the call termination indication may include a SIP bye message) that includes information identifying the calling party number as spam such that the IMS updates a spam database with the information identifying the calling party number ([0051] The terminating computing device 104 may send an unwanted call notice to the P-CSCF 110b by generating a SIP BYE message that includes the indicated call type in a call info header in operation 318, Fig. 3 phone number and call type in 322).
Sinha discloses the user selected spam reporting through a SIP BYE message when terminating the unwanted call but does not specify the calling number/spam classification carried in a SIP UPDATE message.
In the same field of endeavor, Bhattacharjee et al. discloses to generate and attempt to send a request message (e.g., SIP OPTIONS/UPDATE request message) from the called wireless device to the wireless device identified by the caller information ([0030]). The request message may include the “whole” original dialog-ID (i.e., three tuples: FROM tag, TO tag, Call-ID identifier) ([0084]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the user generated SIP BYE reporting mechanism of Sinha to utilize a SIP UPDATE messages as taught by Bhattacharjee et al. because the SIP UPDATE provides an established mechanism for transmitting information associated with an existing SIP dialog without terminating the communication session. The modification is further supported by US Publication No. 2009/0094666 to Cao et al. which expressly discloses the endpoint-generated communication is a SIP response, SIP update message or SIP bye message may be used alternatively for conveying information associated with an unwanted call ([0031-0032]). The resulting combination would permit the user to identify the call as spam, generate a SIP UPDATE message containing the calling party information and spam classification to update the spam database without having to immediately terminate the call.
Claim 17 recites a non-transitory computer-readable medium that has instructions stored thereon that, when executed by at least one physical computing processor, cause a computing device to perform operations of claim 1. Thus claim 17 is rejected in view of the above combination for the same reasons as claim 1, with Sinha teaching a non-transitory processor-readable storage medium ([0020]).
Claim 19 recites a system comprising: at least one physical computing processor of a computing device; and a non-transitory computer-readable medium that has instructions stored thereon that, when executed by the at least one physical computing processor, cause the computing device to perform operations of claim 1. Thus claim 17 is rejected in view of the above combination for the same reasons as claim 1, with Sinha teaching a system comprising: at least one physical computing processor of a computing device (fig. 1) and a non-transitory processor-readable storage medium ([0020]).
Regarding claim 2, Sinha discloses the method of claim 1, further comprising: receiving, at the UE, a subsequent telephone call from the calling party number; and displaying, based on the updated spam database, an indication that the calling party number is associated with spam ([0070] In response to determining that the call termination indication does include a call type value (i.e., determination block 704=“Yes”), the server may update a call type database based on the call type value in block 708, [0077] a call type database may be updated to include an indication that subsequent calls corresponding to the caller info may be identified as potentially unwanted).
Regarding claim 4, Sinha discloses the method of claim 1, wherein the SIP update message comprises a payload that includes the calling party number or a unique identifier associated with the calling party [0059] the terminating computing device 104 may notify a user 106 of the SIP invite message by presenting caller information, including a call type value if a call info header is included in the SIP invite message).
Regarding claim 5, Sinha discloses the method of claim 1, wherein the IMS comprises a Proxy-Call Session Control Function (P-CSCF), a Serving-Call Session Control Function (S-CSCF), or an Interrogating-Call Session Control Function (I-CSCF) (fig. 3, [0058] P-CSCF 110).
Regarding claim 6, Sinha discloses the method of claim 1, further comprising: receiving, at the UE, a SIP INVITE message for an incoming call; and extracting spam status information from a header of the SIP INVITE message ([0058] The P-CSCF 110b may then forward the SIP invite message to the terminating computing device 104 in operation 516, [0059] the terminating computing device 104 may notify a user 106 of the SIP invite message by presenting caller information, including a call type value if a call info header is included in the SIP invite message).
Regarding claim 7, Sinha discloses the method of claim 1, wherein the spam database comprises a local database associated with a service provider or a national database associated with a regulatory agency.
9. The method of claim 1, further comprising: receiving, at the UE, a notification from the IMS indicating that the calling party number has been confirmed as spam based on reports from multiple UEs; and updating a local spam list stored on the UE to include the confirmed spam number (Fig. 4B a call info entry in a call type database).
Regarding claim 8, Sinha discloses the method of claim 1, further comprising: displaying, within the native dialer application of the UE, a user interface element that enables selection of a reason for reporting the calling party number as spam; and including the selected reason in the SIP update message transmitted to the IMS ([0051] A user 106 may interact with terminating computing device 104 to answer the call and, after identifying the call as unwanted, to terminate the call while indicating a call type in operation 316).
Regarding claim 10, Sinha discloses the method of claim 1, wherein the native dialer application comprises a user interface element for reporting spam that is integrated into a call screen or a call log ([0059] The terminating computing device 104 may notify a user 106 of the SIP invite message by presenting caller information, including a call type value if a call info header is included in the SIP invite message, in operation 518).
Regarding claim 14, Sinha discloses the method of claim 1, wherein the option to report the calling party number as spam is displayed within the native dialer application during the telephone call ([0059] The terminating computing device 104 may notify a user 106 of the SIP invite message by presenting caller information, including a call type value if a call info header is included in the SIP invite message, in operation 518).
Claims 3, 9, 13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Publication No. 2020/0045168 (“Sinha”) in view of US Publication No. 2023/0164198 (“Bhattacharjee et al.”) in view of US Publication No. 2009/0094666 (“Cao et al.”) and further in view of US Publication No. 2017/0134574 (“Winkler”).
Regarding claims 3, 18 and 20, the above combination discloses network side call type determination but does not specify wherein detecting that the calling party number is a spam candidate comprises comparing the calling party number to a local spam database stored on the UE.
In the same field of endeavor, Winkler discloses a method for filtering undesirable incoming telephone calls. Incoming caller information may be compared to information on the UE. The comparison can be made with white and/or blacklists individual to the called party, which may be stored locally in his device 1 or in a dedicated memory space of the server 5 ([0087])
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to additionally provide a local spam database as disclosed by Winkler because local lists contain numbers that are unwanted (or acceptable) for a given called party but that are not necessarily so for another called party. A called party would benefit from multiple layers of spam identification.
Regarding claim 9, the above combination discloses network side call type determination but does not specify receiving, at the UE, a notification from the IMS indicating that the calling party number has been confirmed as spam based on reports from multiple UEs; and updating a local spam list stored on the UE to include the confirmed spam number.
In the same field of endeavor, Winkler discloses a method for filtering undesirable incoming telephone calls. Incoming caller information may be compared to information on the UE. The comparison can be made with white and/or blacklists individual to the called party, which may be stored locally in his device 1 or in a dedicated memory space of the server 5 ([0087]). The system moreover affords the advantage of saving the biometric data of the calling party, for example his voice and/or face print. The perpetrators of criminal or unwanted calls leave their biometric trace behind them, and these data can be shared with the other members of the community of users of the system, or with the police. The biometric system can thus benefit and model these persons ([0122]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to additionally provide a local spam database as disclosed by Winkler because local lists contain numbers that are unwanted (or acceptable) for a multiple party they may also be unwanted for the called party. A called party would benefit from multiple layers of spam identification.
Regarding claim 13, the above combination discloses network side call type determination but does not specify receiving, at the UE, a list of known spam numbers from the IMS; and storing the list in a local cache on the UE.
In the same field of endeavor, Winkler discloses a method for filtering undesirable incoming telephone calls. Incoming caller information may be compared to information on the UE. The comparison can be made with white and/or blacklists individual to the called party, which may be stored locally in his device 1 or in a dedicated memory space of the server 5 ([0087]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to additionally provide a local spam database the same information as stored on the server as disclosed by Winkler because call type identification performed locally at the UE or in the network would provide the same benefit of alerting the called party to a spam candidate.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over US Publication No. 2020/0045168 (“Sinha”) in view of US Publication No. 2023/0164198 (“Bhattacharjee et al.”) in view of US Publication No. 2009/0094666 (“Cao et al.”) and further in view of US Publication No. 2021/0297529 (“Weiser”).
Regarding claim 11, Sinha in view of Bhattacharjee et al. discloses in para. [0037] telecommunications providers have adopted a STIR/SHAKEN protocol (i.e., Secure Telephone Identity Revisited (STIR) and Signature-based Handling of Asserted Information Using toKENs (SHAKEN) standards) in the context of IMS/SIP based telephone calls. STIR/SHAKEN uses attestation information to identify the authenticity of a caller. The combination does not specify including authentication information in the SIP update message to enable verification using a Secure Telephone Identity Revisited (STIR) protocol or a Signature-based Handling of Asserted information using toKENs (SHAKEN) framework.
In the same field of endeavor, Weiser also discusses processing call requests to determine spoofing or spam. The method also includes determining whether the request contains an acceptable STIR/SHAKEN attestation. If the request contains an acceptable STIR/SHAKEN attestation (e.g., Full Attestation and/or Partial Attestation), the request is filtered based on at least one characteristic of the request, such as a caller ID. A SIP INVITE message is a request to initiate an audio/video call, which may lead to exchange of additional messages setting up the call. Within the STIR/SHAKEN framework, the request may include (but is not required to have) an attestation parameter that indicates the known identity of the SIP INVITE originator. The SIP INVITE may carry the attestation parameter, for example, in the P-Asserted-Identity field of its header ([0064]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further authenticate the spam reporting message using the STIR protocol so that the IMS could verify the report and reduce fraudulent spam reports.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over US Publication No. 2020/0045168 (“Sinha”) in view of US Publication No. 2023/0164198 (“Bhattacharjee et al.”) in view of US Publication No. 2009/0094666 (“Cao et al.”) and further in view of US Publication No. 2008/0075258 (“Liu et al.”).
Regarding claim 12, Sinha discloses ([0052]) the S/FCDB 116b may indicate successful entry creation or updating via a spam caller HTTP POST response to the P-CSCF 110b in operation 326 but does not specify receiving, at the UE, a confirmation from the IMS that the spam database has been updated based on the SIP update message.
In the same field of endeavor, Liu et al. also discloses the terminal includes a SPIT reporting module, and the server includes a SPIT processing module. The terminal detects a received call request, and sends a SPIT reporting request to the server ([0014]). Additionally, the man-machine interactive unit is further configured to provide related alert messages for the user via the terminal man-machine interface when the reporting process finishes or is determined to be unsuccessful ([0057]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Sinha, Bhattacharjee et al. and Cao et al. to incorporate the network to UE confirmation path as taught by Liu et al. in order to inform the called party of completion of the reporting operation.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over US Publication No. 2020/0045168 (“Sinha”) in view of US Publication No. 2023/0164198 (“Bhattacharjee et al.”) in view of US Publication No. 2009/0094666 (“Cao et al.”) and further in view of US Patent No. 8,325,900 (“Trivi et al.”).
Regarding claim 15, the above combination discloses a called party at a UE selected a SPAM call type and transmitting the information using a SIP UPDATE message to update information in a SPAM database but does not specify receiving, at the UE, a user input to unmark a previously reported spam number; and transmitting a second SIP update message to the IMS that includes information requesting removal of the calling party number from the spam database.
In a similar field of endeavor, Trivi et al. discloses with respect to fig. 4, the interface 400 includes an "Undo" selectable interface element 402 that enables a user of the mobile telephone to undo or retract selection of "Report as Spam" interface elements 210 or 302. In response to a user selection of the "Undo" button 402, the mobile telephone may either not transmit a message to the spam identification server system or may transmit a message to the server system that indicates that the earlier message was transmitted in error.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the interface of Sinha to allow a called party to remove a SPAM tag as disclosed by Trivi et al. in order to allow a user to undo a previous designation, for example when a mistake was made with respect to categorizing a call.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over US Publication No. 2020/0045168 (“Sinha”) in view of US Publication No. 2023/0164198 (“Bhattacharjee et al.”) in view of US Publication No. 2009/0094666 (“Cao et al.”) and further in view of US Publication No. 2010/0278325 (“Singh et al.”).
Regarding claim 16, the above combination discloses network side call type determination but does not specify wherein detecting that the calling party number is a spam candidate comprises analyzing call frequency, call duration, or time of day of previous calls from the calling party number.
In the same field of endeavor, Singh et al. discloses annoying call prevention. When many calls are made from the same caller within a given time interval, it is reasonable to assume that the caller is using an auto-dialer or working off of a call list. In this case, it is reasonable to predict that future calls from this caller will be considered annoying ([0008]). At task 201 of the method in Fig. 2, telecommunications network 102 monitors all telephone calls from telecommunications terminal 101-1 and generates indicia of the temporal characteristics of those calls ([0022]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to additionally provide a local spam determination as disclosed by Singh et al. in order to alert a given called party to a spam candidate. A called party would benefit from multiple layers of spam identification.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIRAPON TULOP whose telephone number is (571)270-7491. The examiner can normally be reached Monday to Friday, 10:00AM-6:00PM.
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, Ahmad Matar can be reached at 571-272-7488. 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.
/JIRAPON TULOP/Examiner, Art Unit 2693
Prosecution Insights