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 .
Claim Rejections - 35 USC §103
2. 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.
Claims 1- 20 are rejected under 35 U.S.C. 103 as being unpatentable over Matias et al (Pub. No. US 2021/0314440 A1; hereinafter Matias) in view of Kirchhoff et al (Patent No.: US 8,369,311 B1; hereinafter Kirchhoff)
Consider claims 1, 8, and 15, Matias clearly shows and discloses a system, one or more computer storage devices, and a method comprising: receiving, by a first user equipment (UB) operating on a wireless network, a session initiation protocol (SIP) Invite for an incoming call from a remote telephone over a default bearer (call screening service (CSS) screens incoming telephone calls, by interrogating callers as to the purpose of their call, before or instead of enabling direct voice communication between the caller and the user. computing device 110 may be a mobile telephone; user interface 314A as an example CSS user interface. In response to an incoming call, flow manager 226 of CSS module 220 may cause UIC 212 to present user interface 314 from which a user of computing device 210 is provided with several options for handling the incoming call, response to selecting graphical element 318A, flow manager 226 of CSS module 220 may interpret the user selection of graphical element 318A as a command to interrogate the caller before passing the incoming call to telephone module) (paragraphs: 0002, 0018, 0021 and 0107; and figs. 3E, labels: 314E and 318B); without accepting the incoming call, transmitting, by the first UE, to the second UE, a real time text (RTT) request for call context via the default bearer over which the SIP Invite for the incoming call was received (In response to an incoming call, flow manager 226 of CSS module 220 may cause UIC 212 to present user interface 314E from which a user of computing device 210 is provided with several options for handling the incoming call, including answering the call, replying by message, and screening the call. Flow manager 226 of CSS module 220 may cause UIC 212 to include graphical element 316D which includes a transcription of the spoken audio that speech engine 228 of CSS module 220 is outputting over the telephone connection; the links coupling computing system 160, caller system 180, and computing device 110 to network 130 may be IP Multimedia Subsystem (IMS) links using Session Initiated Protocol (SIP) signaling) (paragraphs: 0018, 0112, 0113 and fig. 3F, label 316D) ; and receiving, by the first UE, from the second UE, via the default bearer over which the SIP Invite for the incoming call was received, an RTT response to the RTT request for call context (FIG. 3G includes user interface 314G. CSS module 220 may include graphical element 316E which shows a transcription of the spoken audio being captured by speech engine module 229 as the caller provides the additional information requested by the user (i.e., the purpose of the call); speech engine module 228 may be adapted to understand and transcribe spoken voice input received in a variety of human languages. For example, speech engine module 228 may receive a spoken input in a first language (e.g., Mandarin) and transcribe the spoken input into text written in a second language (e.g., English). In this way, speech engine module 228 may enable asynchronous communication between a user of computing device 210 and a caller) (paragraphs: 0095, 0114 and fig. 3G, label: 316E and fig. 4), wherein the RTT request and the RTT response are communicated according to a Third Generation Partnership Program (3GPP) RTT service that has different service requirements than short message service (SMS) (the links coupling computing system 160, caller system 180, and computing device 110 to network 130 may be IP Multimedia Subsystem (IMS) links using Session Initiated Protocol (SIP) signaling; it is known that 3GPP (3rd Generation Partnership Project) standardized implementation of SIP) (paragraph 0018); however, Matias does not disclose wherein the RTT request and the RTT response are communicated according to a Third Generation Partnership Program (3GPP) RTT service that has different service requirements than short message service (SMS).
In the same field of endeavor, Kirchhoff clearly specifically disclose wherein the RTT request and the RTT response are communicated according to a Third Generation Partnership Program (3GPP) RTT service that has different service requirements than short message service (SMS) (a BSP softswitch in fig. 17, uses SIP protocol, a personal mobile phone a voice message indicator is often provided in the form of a visual icon and/or text notification. For a shared fixed phone, a variety of notifications can be provided, which may be a function of the BSP softswitch to which the enhanced service provider softswitch communicates the message waiting status; At state 528A, the ESP softswitch plays a message to the caller (e.g., asking the caller to leave a message). At state 530A, the ESP softswitch records the message being left by the caller. The message is streamed by the ESP softswitch in substantially real time to the fixed phone. At state 532A, the fixed phone user provides an indication (e.g., by pressing a phone key, such as the 1 key) that the user wants to take the call (establish a two-way talk path with the caller) and end screening; a 3GPP (3rd Generation Partnership Project) standardized implementation of SIP (or other protocol)) (col. 41, lines 55- col. 42, lines 1-23, col. 46, lines 63-66; and fig. 17, labels: 404a, 528a, 530a, 532a)
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to incorporate the teaching of Kirchhoff into teaching of Matias for the purpose of providing more example for screening call using SIP protocol before answering the call.
Consider claims 2, 9, and 16, Matias and Kirchhoff clearly show the system, the one or more computer storage devices, and the method, programming instructions further cause the system to perform the following operations: displaying, on the first UE, the RTT response or reading, by the first UE, the RTT response aloud; receiving, by the first UE, an instruction to accept the incoming call or an instruction to reject the incoming call; based on at least receiving the instruction to accept the incoming call, transmitting, to the wireless network, an indication of accepting the incoming call; and based on at least receiving the instruction to reject the incoming call, transmitting, to the wireless network, an indication of rejecting the incoming call (Matias: paragraphs: 0002, 0007, and 0034, and fig. 3H, fig. 3C -3I).
Consider claims 3, 10, and 17, Matias and Kirchhoff clearly show the system, the one or more computer storage devices, and the method, wherein the programming instructions further cause the system to perform the following operations: based on at least receiving, by the wireless network, from the first UE, the indication of rejecting the incoming call, terminating the incoming call without connecting the incoming call to voicemail (Matias: paragraphs: 0002, 0007, and 0034, and fig. 3H, fig. 3C -3I).
Consider claims 4, 11, and 18, Matias and Kirchhoff clearly show the system, the one or more computer storage devices, and the method, further comprising: based on at least receiving, by the wireless network, from the first UE, the indication of accepting the incoming call: creating a dedicated bearer for the first UE; and connecting the incoming call to the first UE, using the dedicated bear (Matias: paragraphs: 0111 and fig. 4).
Consider claims 5, 12, and 19, Matias and Kirchhoff clearly show the system, the one or more computer storage devices, and the method, further comprising: receiving, by a first network node of the wireless network, from the second UE, the coming call (Matias: fig. 1, labels: 180, 130, 114); forwarding, by the first network node, to the first UE, the incoming call (Matias: fig. 3F, label: 314F); receiving, from the first UE, the RTT request for call context over the default bearer (Matias: paragraphs: 0112, 0113 and fig. 3F, label 316D); forwarding, to the second UE, the RTT request for call context (9); receiving, from the second UE, the RTT response; and forwarding, to the first UE, the RTT response over the default bearer (Matias: paragraphs: 0095, 0114 and fig. 3G, label: 316E).
Consider claims 6, 13, and 20, Matias and Kirchhoff clearly show the system, the one or more computer storage devices, and the method, further comprising: initiating, by the second UE, the incoming call to the first UE; receiving, by the second UE, the RTT request for call context; displaying, on the second UE, the RTT request for call context or reading, by the second UE, the RTT request for call context aloud; receiving, by the second UE, the RTT response by touch entry or audio command; and transmitting, by the second UE, the RTT response (the communication between the caller and the example CSS is two-way communication (as opposed to one-way); that is both the caller and the example CSS communicate in a back-and-forth manner) (Matias: paragraphs:0002, 0094-0095, 0114 and fig. 3G, label: 316E).
Consider claims 7, and 14, Matias and Kirchhoff clearly show the system, and the method, wherein the second UE receives the RTT request for call context and transmits the RTT response using a default bearer of the second UE (Matias: paragraphs: 0002, 0095, 0108 and fig. 3B, fig. 3C and fig. 4).
Response to Arguments
The present Office Action is in response to Applicant’s amendment filed on February 05, 2026. Applicant amended claims 1, 4, 6, 8-13, and 15-20. Claims 1-20 are now pending in the present application.
Applicant's arguments with respect to new claims have been considered but are moot in view of the new ground(s) of rejection.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Amal Zenati whose telephone number is 571-270-1947. The examiner can normally be reached on 8:00 -5:00 M-F.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ahmad Matar can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/AMAL S ZENATI/Primary Examiner, Art Unit 2693
Prosecution Insights