Prosecution Insights
Last updated: April 19, 2026
Application No. 16/953,610

PHONE CALL ENDPOINT SECURITY

Final Rejection §103
Filed
Nov 20, 2020
Examiner
ZARRINEH, SHAHRIAR
Art Unit
2496
Tech Center
2400 — Computer Networks
Assignee
Charter Communications Operating LLC
OA Round
8 (Final)
79%
Grant Probability
Favorable
9-10
OA Rounds
2y 8m
To Grant
87%
With Interview

Examiner Intelligence

Grants 79% — above average
79%
Career Allow Rate
341 granted / 433 resolved
+20.8% vs TC avg
Moderate +8% lift
Without
With
+7.8%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
59 currently pending
Career history
492
Total Applications
across all art units

Statute-Specific Performance

§101
7.4%
-32.6% vs TC avg
§103
52.2%
+12.2% vs TC avg
§102
11.9%
-28.1% vs TC avg
§112
16.2%
-23.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 433 resolved cases

Office Action

§103
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 . In communications filed on 012/23/2025. Claim 1 is amended. Claims 3, 7, and 10 are cancelled. Claims 1-2, 4-6, 8-9, and 11-21 are pending in this examination. 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 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. This examination is in response to US Patent Application No. 16/953,610. Claim Objections Claim 8 is objected to because of the following informalities: the claim set filed on 12/23/2025 indicates that the claim 8 is “currently amended”. However, no amendment has been applied to claim 8. Appropriate correction is required. Response to Arguments Applicant's arguments filed 12/23/2025 have been fully considered but they are not persuasive: Applicant submits on pages 7-8 of remarks filed on 12/23/2025 regarding claim 1 recited “receive a session initiation protocol (SIP) invite message associated with a calling device and destined for a called device, the SIP invite message including a header field comprising a phone number associated with the calling device and an identifier that uniquely identifies the calling device, wherein the identifier comprises a media access control address of the calling device or a serial number of the calling device”. Thus, Filart discloses that a SIP invite message may include an identifier that is one of several possible different pieces of information. In contrast, claim 1 recites those two pieces of information are included in the SIP invite message header: 1) a phone number associated with the calling device, and 2) an identifier that uniquely identifies the calling device. These two pieces of information are subsequently used to determine if they are correlated together in a database. Nowhere does Filart disclose two such pieces of information. Rather, Filart discloses that a single identifier that could be one of several possible different pieces of information is included in the SIP invite message. Examiner respectfully disagrees with applicant argument for claim 1 filed on 12/23/2025 on pages 7-8 of remarks. Examiner maintain the rejection. receive a session initiation protocol (SIP) invite message associated with a calling device and destined for a call device (Filart, Para. 0047, At 302, the SIP server of an HPLMN may receive a SIP INVITE message from an originating device to initiate a VoIP communication session with a recipient device), the SIP invite message including a header field comprising a phone number associated with a calling device and an identifier that uniquely identifies the calling device (Filart, Para. 0048, at 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number), wherein the identifier comprises a media access control address of the calling device or a serial number of the calling device (Filart, Para. 0048, at 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number, an International Mobile Subscriber Identity (IMSI), a Mobile Station International Subscriber Directory Number (MSISDN), or an International Mobile Equipment Identity (IMEI)) (equated to the calling device phone number and serial number). Examiner note as underlined in last office action, the two pieces of information are included in the SIP invite message in filart applications is phone number and IMSI or MSISDN or IMEI which are identifier of the calling device or the serial number of the calling device. Applicant submits on pages 8-9 of remarks filed on 12/23/2025 that the referenced paragraph (0010) of Filart fails to utilize "a phone number associated with the calling device and an identifier that uniquely identifies the calling device" that were received in "a session initiation protocol (SIP) invite message associated with a calling device" for any purpose, and thus fail to teach or suggest the referenced limitations. Examiner respectfully disagrees with applicant argument for claim 1 filed on 12/23/2025 on pages 8-9 of remarks. Examiner maintains the rejection. Filart discloses these limitation as: [ 0048, at 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number, an International Mobile Subscriber Identity (IMSI), a Mobile Station International Subscriber Directory Number (MSISDN), or an International Mobile Equipment Identity (IMEI)) (equated to the calling device phone number and serial number)]. Examiner note as underlined in last office action, the two pieces of information are included in the SIP invite message in filart applications is phone number and IMSI or MSISDN or IMEI which are identifier of the calling device or the serial number of the calling device. Applicant submits on pages 9-10 of remarks filed on 12/23/2025 that such disclosure of Li application has nothing to do with receiving "from the database, a response to the query that indicates that the identifier that uniquely identifies the calling device is correlated to the phone number associated with the calling device in the database;" and thus fails to disclose the referenced limitation. Examiner respectfully disagrees with applicant argument for claim 1 filed on 12/23/2025 on pages 9-10 of remarks. Examiner maintains the rejection. While Filart discloses these limitations as: [0010] More specifically, a server is described that includes a spoof mitigation module that is configured to detect receipt of a call request message and further determine whether the PLMN identified within the most recent instance of registration data of an originating device corresponds with the origin network from which the call request message was sent (equated to query the database for correlation). A match would indicate that the identity of the originating device is likely reliable (equated to the response to the query). In contrast, a mismatch may indicate that the identity of the originating device may be spoofed and is likely unreliable], and [0020] In the illustrated example, the SIP server 126 may include a spoof mitigation module 102. The spoof mitigation module 102 may be configured to detect receipt of a SIP INVITE message at the SIP server 126 and may be further configured to determine whether the PLMN identified within the most recent instance of registration data of an originating device (i.e. client device(s) 110(1)-110(N)) corresponds with the origin network. The origin network may be identified within the SIP INVITE message or may correspond to the network from which the SIP INVITE message was sent. A match would indicate that the originating device is located within the same PLMN (i.e. HPLMN or VPLMN) from which the SIP INVITE message was sent, thus indicating that the identity of the originating device is likely reliable(equated to the response for the query)], and [0034] The registration data component 216 is configured to interrogate an HSS, HLR, or USD of the HPLMN to identify the most recent instance of registration data that the originating device registered with the HPLMN. The HSS is configured to include data records of network registration associated with subscriber devices of the HPLMN. The network registrations may relate to registrations of the originating device within the HPLMN or registrations of the originating device within one or more VPLMN within which the subscriber device is roaming. Additionally, or alternatively, the registration data component 216 may interrogate a Universal Subscriber Database (USD) or a Home Location Register (HLR) associated with the HPLMN], and [0048] At 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number, an International Mobile Subscriber Identity (IMSI), a Mobile Station International Subscriber Directory Number (MSISDN), or an International Mobile Equipment Identity (IMEI)], and [¶¶9, 12 claim 1]. Examiner note: as indicated in Filart application , AT SIP server, the registration of the originating device( calling device) the identity of the calling device gets matched( is response to query) against with the registration data at the SIP server the originating device , The registration data interrogate; HSS, HLR, USD(Universal Subscriber Database) of the HPLMN, and identifier of the calling device : the phone number and IMSI or MSISDN or IMEI which are identifier of the calling device or the serial number of the calling device , to determine if the originating device is a reliable device, Furthermore, LI discloses: (Li, Para. 0099, the border service 802 may be configured to communicate with a screening service 804. The screening service 804 may be configured to perform an initial screening of the message. The initial screening may comprise determining whether a sender identifier (e.g., calling number, sending number) is an assigned or unassigned number. A database of assigned and/or unassigned numbers (e.g., pooled from all service providers) (equates to correlation) may be queried to determine whether the sender identifier is assigned), and (Li, Para. 0098, an inbound call may be received as data indicative of the inbound call. The data indicative of the inbound call may comprise a message, such as a SIP message, a SIP invite message, and/or the like. The example environment may comprise the second network device 120 and the destination device 122 of FIG. 1) and (Li, Para. 0099, the border service 802 may be configured to communicate with a screening service 804. The screening service 804 may be configured to perform an initial screening of the message. The initial screening may comprise determining whether a sender identifier (e.g., calling number, sending number) is an assigned or unassigned number. A database of assigned and/or unassigned numbers (e.g., pooled from all service providers) may be queried to determine whether the sender identifier is assigned) , and (Li, Para. 0055, if an originator associated with the message is located in the SIP wholesaler network 252, then the originator may forward the message to the wholesaler SBC 250. The wholesaler SBC 250 may forward the message to the STI-VS 248. In response to receiving the message, the wholesaler SBC 250 may initiate a CNAM dip 256. The CNAM dip 256 may comprise looking up a name associated with a caller id associated with the message) and (Li, Para. 0099, the initial screening may comprise determining whether a sender identifier (e.g., calling number, sending number) is an assigned or unassigned number. A database of assigned and/or unassigned numbers (e.g., pooled from all service providers) may be queried to determine whether the sender identifier is assigned). If the sender identifier is not assigned, the message may be discarded. The border service 802 may be configured to communicate with an identity service 806. … The identity service 806 may be configured to determine (e.g., query from an identity server) a name (e.g., personal name, such as John Doe, company name), caller identifier, and/or the like associated with the message. Examiner Note: as indicated in Li application , The border service with corporation with screening service determine ( in response to the query) whether a sender identifier (e.g., calling number, sending number) is an assigned or unassigned number. A database of assigned and/or unassigned numbers (e.g., pooled from all service providers) may be queried to determine whether the sender identifier is assigned). If the sender identifier is not assigned, the message may be discarded. The border service 802 may be configured to communicate with an identity service 806. … The identity service 806 may be configured to determine (e.g., query from an identity server) a name (e.g., personal name, such as John Doe, company name), caller identifier, and/or the like associated with the message. Applicant submits on pages 10 of remarks filed on 12/23/2025 that it appears that the Patent Office is suggesting that one skilled in the art would combine the database that maintains assigned and unassigned numbers with a wholesaler data structure that associates a name with a caller ID. However, the Patent Office has provided no reasoning as to why one skilled in the art would combine the two very different data structures operated by two different entities. Moreover, Applicant submits that one skilled in the art would not have any reason to combine such data structures. Examiner respectfully disagrees with applicant argument on 12/23/2025 on page 10 of remarks. Examiner maintains the rejection. Filart and Li are both considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart to incorporate the teachings of Li to include send a query to a database that correlates each of a plurality of phone numbers to a respective one of a plurality of identifiers (Li, Para. 0099), each identifier of the plurality of identifiers uniquely identifying a calling device of a plurality of calling devices and each identifier differing from each other identifier, wherein the query includes the phone number associated with the calling device (Li, Para. 0098, ) and (Li, Para. 0099); receive, from the database, a response to the query that indicates that the identifier that uniquely identifies the calling device is correlated to the phone number associated with the calling device in the database (Li, Para. 0055) and (Li, Para. 0099); in response to the response, determine not to reject the SIP invite message and to forward the SIP invite message (Li, Para. 0056). Doing so would aid the communication session to be implemented by routing data associated with the communication session across one or more networks. The first device may send the data with false identification information. One or more computing devices in the network may use the presently disclosed techniques to determine a level of trustworthiness for identification information. The level of trustworthiness may be inserted into a message of the communication session by applying a signature (Li, Para. 0019). Applicant submits on pages 10 of remarks filed on 12/23/2025 that regarding claim 15, neither Filart nor Li disclose a SIP invite message having a header that includes "phone number of the calling device" and "an identifier that uniquely identifies the calling device." Examiner respectfully disagrees with applicant argument for claim 15 filed on 12/23/2025 on page 10 of remarks. Examiner maintains the rejection. The same response for claim 1 also applies to claim 15. Examiner maintain the rejection. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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. Claims 1, 4, 8, 12-13, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Filart (US 2020/0053568 A1), hereinafter Filart, in view of Li (US 2020/0252503 A1), hereinafter Li. In regard to claim 1, Filart discloses a network computing device, comprising (Filart, Para. 0017): a memory: and a processor device coupled to the memory and configured to (Filart, Para. 0027): receive a session initiation protocol (SIP) invite message associated with a calling device and destined for a call device (Filart, Para. 0047, At 302, the SIP server of an HPLMN may receive a SIP INVITE message from an originating device to initiate a VoIP communication session with a recipient device), the SIP invite message including a header field comprising a phone number associated with a calling device and an identifier that uniquely identifies the calling device (Filart, Para. 0048, at 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number), wherein the identifier comprises a media access control address of the calling device or a serial number of the calling device (Filart, Para. 0048, at 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number, an International Mobile Subscriber Identity (IMSI), a Mobile Station International Subscriber Directory Number (MSISDN), or an International Mobile Equipment Identity (IMEI)) (equated to the calling device phone number and serial number) send a query to a database that correlates each of a plurality of phone numbers to a respective one of a plurality of identifiers, each identifier of the plurality of identifiers uniquely identifying a calling device of a plurality of calling devices and each identifier differing from each other identifier, wherein the query includes the phone number associated with the calling device; receive, from the database, a response to the query that indicates that the identifier that uniquely identifies the calling device is correlated to the phone number associated with the calling device in the database While Filart discloses these limitations as: [0010] More specifically, a server is described that includes a spoof mitigation module that is configured to detect receipt of a call request message and further determine whether the PLMN identified within the most recent instance of registration data of an originating device corresponds with the origin network from which the call request message was sent (equated to query the database for correlation). A match would indicate that the identity of the originating device is likely reliable (equated to the response to the query). In contrast, a mismatch may indicate that the identity of the originating device may be spoofed and is likely unreliable], and [0020] In the illustrated example, the SIP server 126 may include a spoof mitigation module 102. The spoof mitigation module 102 may be configured to detect receipt of a SIP INVITE message at the SIP server 126 and may be further configured to determine whether the PLMN identified within the most recent instance of registration data of an originating device (i.e. client device(s) 110(1)-110(N)) corresponds with the origin network. The origin network may be identified within the SIP INVITE message or may correspond to the network from which the SIP INVITE message was sent. A match would indicate that the originating device is located within the same PLMN (i.e. HPLMN or VPLMN) from which the SIP INVITE message was sent, thus indicating that the identity of the originating device is likely reliable(equated to the response for the query)], and [0034] The registration data component 216 is configured to interrogate an HSS, HLR, or USD of the HPLMN to identify the most recent instance of registration data that the originating device registered with the HPLMN. The HSS is configured to include data records of network registration associated with subscriber devices of the HPLMN. The network registrations may relate to registrations of the originating device within the HPLMN or registrations of the originating device within one or more VPLMN within which the subscriber device is roaming. Additionally, or alternatively, the registration data component 216 may interrogate a Universal Subscriber Database (USD) or a Home Location Register (HLR) associated with the HPLMN], and [0048] At 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number, an International Mobile Subscriber Identity (IMSI), a Mobile Station International Subscriber Directory Number (MSISDN), or an International Mobile Equipment Identity (IMEI)], and [¶¶9, 12 claim 1]. Furthermore, LI discloses send a query to a database that correlates each of a plurality of phone numbers to a respective one of a plurality of identifiers (Li, Para. 0099, the border service 802 may be configured to communicate with a screening service 804. The screening service 804 may be configured to perform an initial screening of the message. The initial screening may comprise determining whether a sender identifier (e.g., calling number, sending number) is an assigned or unassigned number. A database of assigned and/or unassigned numbers (e.g., pooled from all service providers) (equates to correlation) may be queried to determine whether the sender identifier is assigned), each identifier of the plurality of identifiers uniquely identifying a calling device of a plurality of calling devices and each identifier differing from each other identifier (Li, Para. 0098, an inbound call may be received as data indicative of the inbound call. The data indicative of the inbound call may comprise a message, such as a SIP message, a SIP invite message, and/or the like. The example environment may comprise the second network device 120 and the destination device 122 of FIG. 1) and (Li, Para. 0099, the border service 802 may be configured to communicate with a screening service 804. The screening service 804 may be configured to perform an initial screening of the message. The initial screening may comprise determining whether a sender identifier (e.g., calling number, sending number) is an assigned or unassigned number. A database of assigned and/or unassigned numbers (e.g., pooled from all service providers) may be queried to determine whether the sender identifier is assigned); receive, from the database, a response to the query that indicates that the identifier that uniquely identifies the calling device is correlated to the phone number associated with the calling device in the database (Li, Para. 0055, if an originator associated with the message is located in the SIP wholesaler network 252, then the originator may forward the message to the wholesaler SBC 250. The wholesaler SBC 250 may forward the message to the STI-VS 248. In response to receiving the message, the wholesaler SBC 250 may initiate a CNAM dip 256. The CNAM dip 256 may comprise looking up a name associated with a caller id associated with the message) and (Li, Para. 0099, the initial screening may comprise determining whether a sender identifier (e.g., calling number, sending number) is an assigned or unassigned number. A database of assigned and/or unassigned numbers (e.g., pooled from all service providers) may be queried to determine whether the sender identifier is assigned); and in response to the response, determine not to reject the SIP invite message and to forward the SIP invite message While Filart discloses [ Abstract, the present disclosure describes techniques for detecting and mitigating a spoof communication within a network, such as a Session Internet Protocol (SIP) network. Determination and mitigation of spoof communication may be performed by a spoof mitigation module associated with a Home Public Land Mobile Network (HPLMN). A server, such as a SIP server, may receive a call request (i.e. SIP INVITE message) from an originating device to initiate a Voice over Internet Protocol (VoIP) communication with a recipient device. In response to the originating device being associated with a HPLMN subscriber account, the server may determine an origin network of the SIP INVITE message and compare the origin network with a most recent instance of registration data associated with the originating device and recorded within the HPLMN. A match indicates that the call request is likely reliable (equated to forward the SIP invite message). A mismatch may indicate that the call request is likely a spoof communication]. Furthermore, LI discloses (Li, Para. 0056, the AV-AS 226 may forward the message to the P-CSCF 224. The P-CSCF 224 may forward the message to the destination). Filart and Li are both considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart to incorporate the teachings of Li to include send a query to a database that correlates each of a plurality of phone numbers to a respective one of a plurality of identifiers (Li, Para. 0099), each identifier of the plurality of identifiers uniquely identifying a calling device of a plurality of calling devices and each identifier differing from each other identifier (Li, Para. 0098) and (Li, Para. 0099); receive, from the database, a response to the query that indicates that the identifier that uniquely identifies the calling device is correlated to the phone number associated with the calling device in the database (Li, Para. 0055) and (Li, Para. 0099); in response to the response, determine not to reject the SIP invite message and to forward the SIP invite message (Li, Para. 0056). Doing so would aid the communication session to be implemented by routing data associated with the communication session across one or more networks. The first device may send the data with false identification information. One or more computing devices in the network may use the presently disclosed techniques to determine a level of trustworthiness for identification information. The level of trustworthiness may be inserted into a message of the communication session by applying a signature (Li, Para. 0019). In regard to claim 4, the combination of Filart in view of Li teaches the network computing device of claim 1, wherein the network computing device comprises one or more of a proxy-call session control function (P-CSCF) or a serving-call session control function (S-CSCF) (Filart, Para. 0017, In various examples, an IP Multimedia Subsystem (IMS) core 112 may reside within the telecommunications network 106.The IMS core 112 may include application function(s) (AF) 114, such as a Proxy Call Session Control Function (P-CSCF) 116, an Interrogating Call Session Control Function (I- CSCF) 118, and a Serving Call Session Control Function (S-CSCF) 120, a Telephony Application Server (TAS) 122, an Interconnection Border Control Function (IBCF) 124, and a SIP server 126). In regard to claim 8, the method of claim 8 relates to the method using the apparatus as claimed in a network computing device of claim 1. Therefore, method claim 8 is rejected for the same reason of obviousness as claim 1 above. In regard to claim 12, the combination of Filart in view of Li teaches the method of claim 8, wherein the SIP invite message is received from an endpoint computing device comprising one or more of an embedded Multimedia Terminal Adapter (CMTA) or a mobile device (Filart, Par. 0016, the client device(s) 110(1)-110(N) Ge. endpoint computing device) may include any sort of electronic device, such as a cellular phone, a smartphone, a tablet computer, an electronic reader, a media player, a gaming device, a personal computer (PC), a laptop computer, etc.). In regard to claim 13, the combination of Filart in view of Li teaches the method of claim 8, wherein the database is one or more of a home subscriber server (HSS), an equipment identity register (EIR), or a device management system (Filart, Para. 0034, The registration data component 216 is configured to interrogate an HSS, HLR, or USD of the HPLMN to identify the most recent instance of registration data that the originating device registered with the HPLMN). In regard to claim 21, the combination of Filart in view of Li teaches the method of claim 1, wherein the phone number associated with the calling device and the identifier that uniquely identifies the calling device are stored in a SIP identity header field compliant with a Secure Telephony Identity Revisited/Signature-based Handling of Asserted information using toKENs (STIR/SHAKEN) protocol (Li, Para. 0079, Generating the signature may comprise encrypting the attestation value (e.g., along with other values). The signature may be generated based on one or more of a secure telephone identity revisited (STIR) protocol or a secure handling of asserted information using tokens (SHAKEN) protocol). Claims 2, and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Filart (US 20200053568 A1), hereinafter Filart, in view of Li (US 2020/0252503 A1), hereinafter Li, and further in view of Carames et. al. (U.S. Patent No. 9654964 B1), hereinafter Carames. In regard to claim 2, the combination of Filart in view of Li does not explicitly teach However, Carames teaches modify the SIP invite message by removing the identifier and the phone number to generate a modified SIP invite message (Carames, Col. 5, lines 39-49, At 340, CSCF 160 sends a second SIP INVITE message, based on the first SIP INVITE message, to AS 190 (subsequent to S- CSCF 180 having determined that AS 190 is the appropriate AS to handle the service request from roaming mobile station 115). This may be performed by simply forwarding the first SIP INVITE message to AS 190. However, in some examples the first SIP INVITE message may be modified, such as by adding, removing, and/or modifying SIP headers in the first SIP INVITE message, or modifying other portions of the first SIP INVITE message, to produce the second SIP INVITE message for AS 190.); and transmit the modified SIP invite message (Carames, Col. 5, lines 49-50, At 345, AS 190 receives the second SIP INVITE message from CSCF 160.). Filart, Li and Carames are all considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart, and Li to incorporate the teachings of Carames to include modify the SIP invite message by removing the identifier and the phone number to generate a modified SIP invite message (Carames, Col. 5, lines 39-49); and transmit the modified SIP invite message (Carames, Col. 5, lines 49-50). Doing so would determine that the SIP INVITE message (and roaming mobile station 510's associated request for service) is acceptable. Based on this determination, at 690, AS 190 and CSCF 160 proceed with the ViLTE session requested by roaming mobile station 610 (Carames, Col. 8, lines 50-55). In regard to claim 9, the method of claim 9 relates to the method using the apparatus as claimed in a network computing device of claim 2. Therefore, method claim 9 is rejected for the same reason of obviousness as claim 2 above. Claims 5 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Filart (US 20200053568 A1), hereinafter Filart, in view of Li (US 2020/0252503 A1), hereinafter Li, and further in view of Stewart et. al. (US 2019/0158543 A1), hereinafter Stewart. In regard to claim 5, the combination of Filart in view of Li does not explicitly teach the network computing device of claim 1, wherein the header field of the SIP invite message includes a firmware version. However, Stewart teaches wherein the header field of the SIP invite message includes a firmware version (Stewart, Para. 0073, the SBC 320 can encode data identifying the endpoint characteristic of the endpoint 310 within the Contact header field. When the SBC 320 receives a subsequent SIP request message for the endpoint 310, the SIP request message may comprise the encoded data identifying the endpoint characteristic of the endpoint 310 (and/or data derived therefrom), which the SBC 320 can then decode to identify the endpoint characteristic of the endpoint 310... Par. 0068, a User-Agent header field is an example of an endpoint type header. The User-Agent header field contains endpoint characteristic information. The User-Agent header field value may, for example, indicate the vendor, model, firmware version etc. of the endpoint 310). Filart, Li and Stewart are all considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart, and Li to incorporate the teachings of Stewart to include wherein the header field of the SIP invite message includes a firmware version (Stewart, Para. 0073). Doing so would aid to use different SIP INVITE messages to support interoperability between endpoints from the different vendors (Stewart, Para. 0004). In regard to claim 11, the combination of Filart in view of Li does not explicitly teach, However, Stewart teaches wherein the header field of the SIP invite message includes a firmware version (Stewart, Para. 0073, the SBC 320 can encode data identifying the endpoint characteristic of the endpoint 310 within the Contact header field. When the SBC 320 receives a subsequent SIP request message for the endpoint 310, the SIP request message may comprise the encoded data identifying the endpoint characteristic of the endpoint 310 (and/or data derived therefrom), which the SBC 320 can then decode to identify the endpoint characteristic of the endpoint 310... Par. [0068], A User-Agent header field is an example of an endpoint type header. The User-Agent header field contains endpoint characteristic information. The User-Agent header field value may, for example, indicate the vendor, model, firmware version etc. of the endpoint 310); and wherein the SIP invite message is received at a proxy-call session control function (P- CSCP) or a serving-call session control function (S-CSCF) of the network computing device (Stewart, Para. 0010, wherein the network entity is located at an edge of an IP Multimedia Subsystem (IMS) network and provides Session Border Controller (SBC) functionality and/or Proxy-Call Session Control Function (P- CSCF) functionality). Filart, Li and Stewart are all considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart and Li to incorporate the teachings of Stewart to include wherein the header field of the SIP invite message includes a firmware version (Stewart, Para. 0073); wherein the SIP invite message is received at a proxy- call session control function (P- CSCF) or a serving-call session control function (S-CSCF) of the network computing device (Stewart, Para. 0010). Doing so would aid to use different SIP INVITE messages to support interoperability between endpoints from the different vendors (Stewart, Para. [0004]). Claims 6, 14-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Filart (US 20200053568 A1), hereinafter Filart, in view of Li (US 2020/0252503 A1), hereinafter Li, and further in view of Kim (US 2017/0201383 A1), hereinafter Kim. In regard to claims 6, and 14, Filart does not explicitly disclose, while Li teaches wherein the identifier that uniquely identifies the calling device comprises an encrypted identifier that is encrypted by a public encryption key of the network computing device ; wherein the processor device is further configured to: access a private encryption key of the network computing device (0039, the first network device 110 may generate the identity header by determining values for the data fields. The first network device 110 may encrypt the values using a private key associated with the first network device 110. The resulting encrypted signature (e.g., an encrypted string comprising all the data fields) may be inserted in a header area of the message (e.g., indicated as “identity: [encrypted signature]” where brackets indicate inserted information). Other information may also be inserted into the message, such as an identifier of an encryption protocol used to generate the signature), and (Li, Para. 0040, the second network device 120 may comprise a Secure Telephone Identity Verification Service (STI-VS). The second network device 120 may receive a public key associated with the private key associated with the first service provider (e.g., or owner of the first network device) from the authentication device 102 via the first network 104. The public key may be requested from the authentication device 102 based on (e.g., in response to) receiving a message, such as a call request. The public key may be requested from the authentication device 102 based on a field in the message indicating information associated with requesting the public key); and decrypt the encrypted identifier using a private encryption Key (Li, Para. 0029, a message or a portion of a message signed (e.g., encrypted, etc.) by a private key may be verified (e.g., decrypted, etc.) using a public key associated with the private key). while Li teaches using private key to encrypt the identifiers, Li does not explicitly disclose, encrypting with public key and Kim discloses: (Kim, Para. 0024, identifiers associated with the end entity are included in the Subject, Subject Alternative Name, and/or other fields of a certificate, and these fields may be cryptographically obscured. For example, the identifiers may be encrypted using a public key associated with the service node,) and (Kim, Para. 0029, The subject alternative name associated with the entity may include an identifier associated with the end entity, such as a MAC address (Wi-Fi MAC address), IMEI of a mobile device, an application UUID, and/or other identifiers), and (0030, 0039, 0053-0054) Filart, Li and Kim are all considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart, and Li to incorporate the teachings of Kim to include: wherein the identifier that uniquely identifies the calling device comprises an encrypted identifier that is encrypted by a public encryption key of the network computing device; wherein the processor device is further configured to: access a private encryption key of the network computing device (Kim, Para. 0024, 0029, 0030, 0039, 0053-0054). Doing so would help a service to use a certificate to verify the identity of end entity such as a mobile device, application, laptop, computing device, and/or other entity. A certificate may be used to generate an authenticated and secure communication channel between an end entity and a service via a service node without the use of shared keys or user ID/password entry (Kim, Para. 0002). In regard to claim 15, Filart discloses an endpoint computing device, comprising: a memory: and a processor device coupled to the memory and configured to (Filart, Para. 0027, Further, the SIP server 126 may include one or more processor(s) 206 that are operably connected to memory 208); and wherein the identifier comprises a media access control address of the calling device or a serial number of the calling device (Filart, Para. 0048, at 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number, an International Mobile Subscriber Identity (IMSI), a Mobile Station International Subscriber Directory Number (MSISDN), or an International Mobile Equipment Identity (IMEI)) (equated to the calling device phone number and serial number); and receive, from a calling device, a Session Initiation Protocol (SIP) invite message that includes a phone number of the calling device and is destined for a called device. (Filart, Para. 0047, At 302, the SIP server of an HPLMN may receive a SIP INVITE message from an originating device to initiate a VoIP communication session with a recipient device), and (Filart, Para. 0048, at 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number, an International Mobile Subscriber Identity (IMSI), a Mobile Station International Subscriber Directory Number (MSISDN), or an International Mobile Equipment Identity (IMEI)) (equated to the calling device phone number and serial number); and transmit the SIP invite message toward the network computing device (Filart, Para. 0047, At 302, the SIP server (i.e., network computing device) of an HPLMN may receive a SIP INVITE message from (i.e., transmit) an originating device to initiate a VoIP communication session with a recipient device). Filart does not explicitly disclose, while Li teaches modify the SIP invite message that to include the encrypted identifier in a header field of the SIP invite message (Li, Para. 0039, the first network device 110 may generate the identity header by determining values for the data fields. The first network device 110 may encrypt the values using a private key associated with the first network device 110. The resulting encrypted signature (e.g., an encrypted string comprising all the data fields) may be inserted in a header area of the message (e.g., indicated as “identity: [encrypted signature]” where brackets indicate inserted information). Other information may also be inserted into the message, such as an identifier of an encryption protocol used to generate the signature) Filart and Li are both considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart to incorporate the teachings of Li to include modify the SIP invite message that to include the encrypted identifier in a header field of the SIP invite message (Li, Para. 0039). Doing so would aid the communication session to be implemented by routing data associated with the communication session across one or more networks. The first device may send the data with false identification information. One or more computing devices in the network may use the presently disclosed techniques to determine a level of trustworthiness for identification information. The level of trustworthiness may be inserted into a message of the communication session by applying a signature (Li, Para. 0019). Filart does not explicitly disclose, and while Li teaches using private key to encrypt the identifiers, they do not explicitly disclose, and Kim discloses: receive, from a public certificate repository, a public certificate of a network computing device (Kim, Para. 0063, a certificate (e.g., X.509 certificate) is received from the certificate authority); and cache the public certificate (Kim, Para. 0034, the device management system 140 may cache the certificate, end entity private and public keys, and/or other information before transmission to the end entity 110); and encrypt, using a public encryption key of the public certificate of the network computing device, an identifier that uniquely identifies the calling to generate an encrypted identifier (Kim, Para. 0024, identifiers associated with the end entity are included in the Subject, Subject Alternative Name, and/or other fields of a certificate, and these fields may be cryptographically obscured. For example, the identifiers may be encrypted using a public key associated with the service node,) and (Kim, Para. 0029, The subject alternative name associated with the entity may include an identifier associated with the end entity, such as a MAC address (Wi-Fi MAC address), IMEI of a mobile device, an application UUID, and/or other identifiers), and 0030, 0039, 0053-0054) Filart, Li and Kim are all considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart, and Li to incorporate the teachings of Kim to include receive, from a public certificate repository, a public certificate of a network computing device (Kim, Para. 0063); cache the public certificate (Kim, Para. 0034); and encrypt, using a public encryption key of the public certificate of the network computing device, an identifier that uniquely identifies the calling to generate an encrypted identifier (Kim, Para. 0024). Doing so would help a service to use a certificate to verify the identity of end entity such as a mobile device, application, laptop, computing device, and/or other entity. A certificate may be used to generate an authenticated and secure communication channel between an end entity and a service via a service node without the use of shared keys or user ID/password entry (Kim, Para. 0002). In regard to claim 17, the combination of Filart, Li and Kim teach the endpoint computing device of claim 15, wherein the endpoint computing device comprises an embedded Multimedia Terminal Adapter (eMTA) or a mobile device (Filart, Par. 0016, the client device(s) 110(1)- 110(N) Ge. endpoint computing device) may include any sort of electronic device, such as a cellular phone, a smartphone, a tablet computer, an electronic reader, a media player, a gaming device, a personal computer (PC), a laptop computer, etc.). In regard to claim 18, wherein the processor device is further configured to request a public certificate associated with the network computing device from a certificate repository the combination of Filart, Li do not explicitly disclose, however, Kim teaches (Kim, Para. 0063, a certificate (e.g., X.509 certificate) is received from the certificate authority); and (Kim, Para. 0034, the device management system 140 may cache the certificate, end entity private and public keys, and/or other information before transmission to the end entity 110). In regard to claim 19, the endpoint computing device of claim 15, wherein the processor device is further configured to receive the phone number and the encrypted identifier from the calling device. Filart discloses Li does not explicitly disclose, however, the combination of Filart, and Kim disclose: Filart discloses: (Filart, Para. 0048, at 304, the SIP server may determine that an identifier of the originating device that is presented within the SIP INVITE message is associated with a subscriber account of the HPLMN. The identifier may correspond to a phone number, an International Mobile Subscriber Identity (IMSI), a Mobile Station International Subscriber Directory Number (MSISDN), or an International Mobile Equipment Identity (IMEI)) (equated to the calling device phone number and serial number). Kim discloses: (Kim, Para. 0024, identifiers associated with the end entity are included in the Subject, Subject Alternative Name, and/or other fields of a certificate, and these fields may be cryptographically obscured. For example, the identifiers may be encrypted using a public key associated with the service node,) and (Kim, Para. 0029, The subject alternative name associated with the entity may include an identifier associated with the end entity, such as a MAC address (Wi-Fi MAC address), IMEI of a mobile device, an application UUID, and/or other identifiers), and 0030, 0039, 0053-0054). In regard to claim 20, the combination of Filart, Li and Kim teach the endpoint computing device of claim 15, wherein the processor device is further configured to establish a call session or receive a rejection based on whether the encrypted identifier and the phone number of the SIP invite message are correlated in a database in electronic communication with the network computing device Filart teaches (Filart, Para. 0041, The computer-executable instructions may be further configured to establish the VoIP communication session between the originating device and the recipient device and present the likely-spoof tag on a display of the recipient device at the same point-in-time as establishing the VoIP communication session), and ( Abstract, the present disclosure describes techniques for detecting and mitigating a spoof communication within a network, such as a Session Internet Protocol (SIP) network. Determination and mitigation of spoof communication may be performed by a spoof mitigation module associated with a Home Public Land Mobile Network (HPLMN). A server, such as a SIP server, may receive a call request (i.e. SIP INVITE message) from an originating device to initiate a Voice over Internet Protocol (VoIP) communication with a recipient device. In response to the originating device being associated with a HPLMN subscriber account, the server may determine an origin network of the SIP INVITE message and compare the origin network with a most recent instance of registration data associated with the originating device and recorded within the HPLMN. A match indicates that the call request is likely reliable (equated to forward the SIP invite message). A mismatch may indicate that the call request is likely a spoof communication]). Furthermore, LI discloses (Li, Para. 0056, the AV-AS 226 may forward the message to the P-CSCF 224. The P-CSCF 224 may forward the message to the destination). Filart and Li are both considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart to incorporate the teachings of Li to include send a query to a database that correlates each of a plurality of phone numbers to a respective one of a plurality of identifiers (Li, Para. 0099), each identifier of the plurality of identifiers uniquely identifying a calling device of a plurality of calling devices and each identifier differing from each other identifier (Li, Para. 0098) and (Li, Para. 0099); receive, from the database, a response to the query that indicates that the identifier that uniquely identifies the calling device is correlated to the phone number associated with the calling device in the database (Li, Para. 0055) and (Li, Para. 0099); in response to the response, determine not to reject the SIP invite message and to forward the SIP invite message (Li, Para. 0056). Doing so would aid the communication session to be implemented by routing data associated with the communication session across one or more networks. The first device may send the data with false identification information. One or more computing devices in the network may use the presently disclosed techniques to determine a level of trustworthiness for identification information. The level of trustworthiness may be inserted into a message of the communication session by applying a signature (Li, Para. 0019). Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Filart (US 20200053568 AJ), hereinafter Filart in view of Li (US 2020/0252503 A1), hereinafter Li in view of Kim (US 2017/0201383 A1), hereinafter Kim and further in view of Stewart et. al. (US 20190158543 Al), hereinafter Stewart. In regard to claim 16, the combination of Filart and Li in view of Kim does not explicitly teach the endpoint computing device of claim 15, However, Stewart teaches the endpoint computing device of claim 15, wherein the SIP invite message includes a firmware version (Stewart, Para. 0073, the SBC 320 can encode data identifying the endpoint characteristic of the endpoint 310 within the Contact header field. When the SBC 320 receives a subsequent SIP request message for the endpoint 310, the SIP request message may comprise the encoded data identifying the endpoint characteristic of the endpoint 310 (and/or data derived therefrom), which the SBC 320 can then decode to identify the endpoint characteristic of the endpoint 310... Par. [0068], A User-Agent header field is an example of an endpoint type header. The User-Agent header field contains endpoint characteristic information. The User-Agent header field value may, for example, indicate the vendor, model, firmware version etc. of the endpoint 310); Filart, Li, Kim and Stewart are all considered to be analogous to the claim invention because they are in the same field as they both pertain to an apparatus for receiving a SIP invite message and determining whether to forward or reject the invite. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Filart, Li, Kim and Narayanan to incorporate the teachings of Stewart to include the endpoint computing device of claim 15, wherein the SIP invite message includes a firmware version (Stewart, Para. 0073). Doing so would aid to use different SIP INVITE messages to support interoperability between endpoints from the different vendors (Stewart, Para. 0004). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Danis (US 9,332,119 B1) teaches Caller ID authentication methodology is used to authenticate call destination and detect call forwarding in a telecommunication system. Call forwarding detection is performed by the called party authentication device transmitting an authentication request message to the authentication server. The authentication request containing the source telephone number of the call and the called party telephone number. The authentication server matches the authentication request message to a calling status message transmitted by the caller party authentication device. The calling status message containing the caller telephone number and the destination telephone number. If the two messages match, the server informs the caller authentication device that the call has reached the intended party and the call destination is authentic. If the two messages do not match or a valid authentication request message has not been received, the authentication server determines the call has not reached the intended destination and the call has been forwarded. Authentication device reputation scores are used to mitigate certain attacks against caller ID and call destination authentication. ZHU (US 2018/0332471 A1) teaches A wireless network connection method is provided. The method includes: receiving, from a user terminal, an access request to a wireless access point, the access request including a media access control MAC address of the user terminal; sending, by the wireless access point, a key query request to an authentication server, the key query request including the MAC address; and receiving a key query result corresponding to the MAC address of the user terminal if the wireless access point is a trusted wireless access point. The method further includes obtaining a first authentication key corresponding to the MAC address of the user terminal according to the key query result; and negotiating with the user terminal, according to the first authentication key and a second authentication key, to establish an encrypted wireless network connection. The second authentication key is generated by the user terminal corresponding to the MAC address. Edge (US10567943B2) A method is provided to enable handoff of an emergency services call between different network operators. A UE may establish a first call with a first network for a first network operator based on a first wireless access type, where the first call is an emergency services call to a PSAP. The UE may then determine impaired wireless coverage for the first wireless access type and unimpaired wireless coverage for a second wireless access type for a second network, where the second network is for a second network operator different to the first network operator. The UE may then establish a second call with the second network based on the second wireless access type, where the second call is a continuation of the first call to the PSAP. In embodiments, the first wireless access type is WiFi and the second wireless access type is cellular. Barakat (US11824994B2) A device receives call information associated with a call from a first user device to a second user device, where the first user device is associated with a first network, and the second user device is associated with a second network separate from the first network. The call information includes a caller identification and is received via an originating network device of the first network. The device determines whether the caller identification is verified, and adds authentication information to the call information when the caller identification is verified. The device receives the call information and the authentication information from a terminating network device of the first network, and removes the authentication information from the call information. The device adds a cryptographic signature to the call information, and causes the call information and the cryptographic signature to be provided to the second network for routing to the second user device. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm. 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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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. /SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Read full office action

Prosecution Timeline

Nov 20, 2020
Application Filed
Aug 12, 2022
Non-Final Rejection — §103
Nov 17, 2022
Response Filed
Jan 27, 2023
Final Rejection — §103
Apr 03, 2023
Response after Non-Final Action
Apr 12, 2023
Response after Non-Final Action
May 01, 2023
Request for Continued Examination
May 22, 2023
Response after Non-Final Action
Jul 27, 2023
Non-Final Rejection — §103
Oct 19, 2023
Interview Requested
Oct 30, 2023
Applicant Interview (Telephonic)
Oct 31, 2023
Response Filed
Nov 03, 2023
Examiner Interview Summary
Nov 15, 2023
Final Rejection — §103
Jan 22, 2024
Response after Non-Final Action
Feb 07, 2024
Response after Non-Final Action
Mar 21, 2024
Request for Continued Examination
Mar 23, 2024
Response after Non-Final Action
May 31, 2024
Non-Final Rejection — §103
Sep 05, 2024
Response Filed
Dec 05, 2024
Final Rejection — §103
Feb 18, 2025
Response after Non-Final Action
May 27, 2025
Notice of Allowance
May 27, 2025
Response after Non-Final Action
Jul 07, 2025
Response after Non-Final Action
Sep 22, 2025
Non-Final Rejection — §103
Dec 23, 2025
Response Filed
Mar 23, 2026
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12587392
SECURE COMMUNICATION METHOD AND APPARATUS IN PASSIVE OPTICAL NETWORK
2y 5m to grant Granted Mar 24, 2026
Patent 12549527
MULTI-FACTOR AUTHENTICATION OF CLOUD-MANAGED SERVICES
2y 5m to grant Granted Feb 10, 2026
Patent 12547755
TECHNIQUES FOR SECURELY EXECUTING ATTESTED CODE IN A COLLABORATIVE ENVIRONMENT
2y 5m to grant Granted Feb 10, 2026
Patent 12543044
SYSTEMS AND METHODS OF AUTOMATIC OUT-OF-BAND (OOB) RESTRICTED CELLULAR CONNECTIVITY FOR SET UP PROVISIONING OF MANAGED CLIENT INFORMATION HANDLING SYSTEMS
2y 5m to grant Granted Feb 03, 2026
Patent 12511435
DEVICE AND METHOD FOR ENFORCING A DATA POLICY
2y 5m to grant Granted Dec 30, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

9-10
Expected OA Rounds
79%
Grant Probability
87%
With Interview (+7.8%)
2y 8m
Median Time to Grant
High
PTA Risk
Based on 433 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month