DETAILED ACTION
This communication is in responsive to amendment for Application 18/469680 filed on 3/9/2026. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims:
Claims 1-19 and 21 are presented for examination.
Response to Arguments
3. Examiner statements in the mailed non-final with respect to obvious limitations including common knowledge or well-known in the art are taken to be admitted prior art because applicant failed to traverse the Examiner’s assertion, see MPEP 2144.03 C.
4. Applicant’s arguments in the amendment filed on 3/9/2026 regarding claim rejection under 35 USC § 103 with respect to current claims have been considered and found unpersuasive. Some arguments are moot in view of the updated rejection.
a. Applicant argues that the new amendments for claims 1-12 are not taught in the cited art. Examiner disagrees because Ravichandran still teaches the limitation.
Ravichandran still teaches that one a user have one or more applications to conduct a video call, the system will select the one that suits the call based on the other device. Thus, the amendment is obvious to one skilled in the art. Device 1 has to use facetime to contact a second device if facetime is installed there to otherwise, the system will not enable the call. This is common sense from Ravichandran. Also, in a case where more than one application can conduct a call and the more than one application installed on both devices, then the system default to user’s settings. Thus, the comparison part of the amendment is implied. See the updated rejection.
b. applicant argues that TAS 116 provide services according to a user preference which is distinct from providing identifications. Examiner disagrees because Ravichandran still teaches different applications. For example, device 1 has a native application FACETIME on an iPhone and Google Hangouts as OTT application. The system will select either FACETIME or Google Hangouts based on user’s preferences. User’s preference for application is a selection by the user to use a specific application.
c. applicant argues that TAS selection of an OTT application is different than prioritized list or comparison between applications. Examiner disagrees because the prioritized list is similar to user’s preference and the comparison is implied to determine the application to make the call when for example iphone using FACETIME calls another iphone using FACETIME.
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 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.
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-11 are rejected under 35 U.S.C. 103 as being unpatentable over Ravichandran US 2020/0389775 A1 in view of Pande US 2018/0034972 A1.
Regarding Claim 1, Ravichandran teaches a device (Fig. 2 & ¶0021-¶0025; TAS 116 is one or more servers for calls and communications…built on the session initiation protocol (SIP) and is the base to further support packaging of voice, video, data, and fixed and mobile services on a single platform to end users), comprising:
a processing system including a processor (¶0128; transceiver 916);
and a memory that stores executable instructions that, when executed by the processing system, facilitate performance of operations (¶0128-¶0130; memory and transceivers), the operations comprising:
receiving, from a first end user device, identifications for a first group of Over-The-Top (OTT) applications that are executable by the first end user device (¶0022-¶0026; UEs 102 registers different applications like facetime or other native applications with TAS 116…TAS 116 may also register with one or more TASs 116 to enable the UE 102 to make the aforementioned “cross-platform” video calls, among other things. Also, see Fig. 10 & ¶0108-¶0133; the OTT settings GUI 810 can include an applications list 1002 comprising one or more applications that are included in the OTT application 104 and/or the standard applications 806);
providing, to a second end user device, the identifications for the first group of OTT applications (¶0022-¶0026; this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. When there is a match between user’s preferences for a specific call or particular service, then TAS will use the OTT according to the users’ preferences set in Fig. 10.
For example, the TAS 116 can terminate calls (whether audio or video), and the OTT application 104 can receive calls, via the dialer inside the OTT application 104 instead of the native dialer of the UE 102, see ¶0056.
See below at least two scenarios:
generally, native applications will enable users to make video calls once the first or second device connect with the server. For example, if the first user has facetime and WhatsApp applications on an iPhone, the second user will be provided with the identification of the facetime and WhatsApp applications once connected to the server because the second user’s iPhone will show that the second user may make a call using facetime or WhatsApp. Otherwise, the second user will not be able to make any calls. Thus, in this scenario, the second user is provided with the identification of OTT applications (facetime and WhatsApp) installed on the second user. Here, see ¶0107-¶0111 & Fig. 10; UE 102 can one or more standard applications 806 and OTT application 104. The standard applications 806 can include many features common to UEs such as, for example, calendars, call logs, voicemail, etc. In this case, the standard applications 806 can also comprise a video call application (e.g., Facetime), an audio call application, and a messaging application to enable users to engage in audio calls, video calls, and messaging, among other things. The standard applications 806 can also include contacts to enable the user to select a contact to initiate, for example, a video call, audio call, text message, etc.
additionally, Ravichandran teaches TAS 116 that enables the UEs 102 to make the aforementioned “cross-platform” video calls, among other things. TAS 116 enable plurality of UEs to connect with each other. TAS 116 also can include one or more software products to provide the same user interface (UI) and user experience across multiple devices and media types which enables a video application like Facetime on an iPhone to place a video call to a different device like Android phone that has a different video calling application. This implies that the identifications of OTT applications on the first device is provided to the second device (since the first device registered with TAS) and TAS determined that the identifications of OTT applications on the first device are not match with the OTT applications on the second device (second device also registered with TAS), thus TAS 116 provides one or more software products to provide US and user experience across multiple devices where the OTT application 104 can enable the user to place a video call within the application using the specific video calling application needed or a video calling application that is agnostic to OS, type of UE, network, etc. Also see Fig. 10 provides prioritized list of preferred OTT applications for delivering particular services. Fig. 10 applies to both first and second end user devices)
wherein the providing of the identifications to the second end user device causes the second end user device to select a first OTT application, resulting in a selected first OTT application, based on a comparison of the first group of OTT applications and a second group of OTT applications that are executable by the second end user device (this limitation is obvious because if the first user has facetime and WhatsApp applications on an iPhone, the second user will be provided with the identification of the facetime and WhatsApp applications once connected to the server because the second user’s iPhone will show that the second user may make a call using facetime or WhatsApp which implies the comparison part of the claim. Otherwise, the second user will not be able to make any calls. Thus, in this scenario, the second user is provided with the identification of OTT applications (facetime and WhatsApp) installed on the second user. Here, see ¶0107-¶0111 & Fig. 10; UE 102 can one or more standard applications 806 and OTT application 104. The standard applications 806 can include many features common to UEs such as, for example, calendars, call logs, voicemail, etc. In this case, the standard applications 806 can also comprise a video call application (e.g., Facetime), an audio call application, and a messaging application to enable users to engage in audio calls, video calls, and messaging, among other things. The standard applications 806 can also include contacts to enable the user to select a contact to initiate, for example, a video call, audio call, text message, etc.);
and facilitating establishing a communication session between the first and second end user devices utilizing the first OTT application (¶0023; the OTT application 104 can enable the user to place a video call within the application using the specific video calling application needed or a video calling application that is agnostic to OS, type of UE, network, etc. also see Fig. 10 provides prioritized list of preferred OTT applications for delivering particular services. Fig. 10 applies to both first and second end user devices. So, it would have been obvious that the preferred/selected OTT in both lists will handle a video call using the specific video calling application needed or a video calling application that is agnostic to OS, type of UE, network, etc.)
Ravichandran does not expressly teach “to the first end user device” in the limitation “providing, to the first end user device, a first identification of a first OTT application of the first group of OTT applications” (same citation and explanation as above in the providing step. This limitation is suggested because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. For example, the TAS 116 can terminate calls (whether audio or video), and the OTT application 104 can receive calls, via the dialer inside the OTT application 104 instead of the native dialer of the UE 102, see ¶0056);
Pande on the other hand is analogous art because Pande is directed to OTT call service. See abstract.
Pande also teaches “providing, to the first end user device, a first identification of a first OTT application of the first group of OTT applications” (¶0068-¶0075 & ¶0149; in response to receiving message 406, retrieves information in its database about the OTT subscriber being called by the calling party of endpoint 104-3. It provides the retrieved information to computer system 221 via message 408. Also see Figs. 7-8 & ¶0112-¶0115; Pande teaches that at task 820, computer system 221 determines whether the called party subscriber of OTT service i has consented to receive calls on the app (i.e., has “opted in”). If the subscriber has so consented, then control of execution proceeds to task 825. If not, then control of execution proceeds to task 835.
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Pande into the system of Ravichandran in order to determine the effect that the originating OTT service has on the quality of using an OTT service to deliver the call to the terminating endpoint. ¶0146. Utilizing such teachings enable the system to assess the call quality being experienced by the originating endpoint already using the OTT call service (e.g., via a real-time performance test, etc.). Id.
Regarding Claim 2, Ravichandran in view of Pande teaches the device of claim 1, Ravichandran further teaches wherein the operations comprise: receiving, from the second end user device, the first identification of the first OTT application, wherein the first identification of the first OTT application is selected by the second end user device according to a match in the first group of OTT applications executable by the first end user device and a second group of OTT applications executable by the second end user device (this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. When there is a match between user’s preferences for a specific call or particular service, then TAS will use the OTT according to the users’ preferences set in Fig. 10. See ¶0022-¶0026. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to reach the above limitation from Ravichandran’s teachings in order to provide applications and capabilities that are not otherwise available on the UE (abstract). Utilizing such teachings enable the user to dynamically configure how communications are sent and received in response to changing conditions or preferences via GUI (abstract)).
Regarding Claim 3, Ravichandran in view of Pande teaches the device of claim 2, Ravichandran further teaches wherein the communication session is one of a voice call, a video call or messaging (¶0060; FIGS. 4A and 4B, examples of the present disclosure can include a system 400 for enabling the UE 102 to register with the TAS 116 using the SIM ID 118 to receive communications (e.g., an audio or video call) via the OTT application 104. The communications can be received over a Wi-Fi 108 (or other) connection in addition to, or instead of, a cellular or other connection. This may be useful, for example, when cellular reception is poor, but the UE 102 has a strong Wi-Fi 108 signal),
and wherein the first and second groups of OTT applications are prioritized lists stored by the first and second end user devices, respectively (see Fig. 10 & ¶0133; the OTT settings GUI 810 can include an applications list 1002 comprising one or more applications that are included in the OTT application 104 and/or the standard applications 806. For applications that include bidirectional communications (e.g., calls and messaging), the OTT settings GUI 810 can also include separate send 1004 and receive 1006 subentries to enable the user to fully configure the OTT application 104
¶0110 & ¶0113; the OS 804 can enable the OTT application 104 and native applications to conduct voice and video calls, send and receive messages, and provide other functions, as described above, via the transceiver(s) 818. The OS 804 can send information to the GUI 810, for example, to cause the GUI 810 to display a list of applications and provide various settings. The OS 804 can also receive inputs from the GUI 810 to cause the UE 102 to use the standard applications 806 for some functions, while other functions are handled in the OTT application 104, among other things. The OS 804 can also enable the UE 102 to send and retrieve other data via a cellular connection 110 or IP connection 112 and perform other functions.
Also see ¶0059; the OTT application 104 can include a graphical user interface (GUI, discussed below with reference to FIG. 10) to enable users to choose their preferences, which can then be configured with the TAS 116 via a SIP REGISTER (which may actually be a re-registration) and/or REST request messages, as discussed above. Thus, in some circumstances, the user may prefer the native phone dialer, for example, if they are concerned about call drops or audio quality. The user may wish to the use the dialer and/or messaging application in the OTT application 104, on the other hand, if they want to use advanced functionalities such as, for example, video calling, call transfers, rich content services (RCS) messaging, etc., that the UE 102 may not support with native applications/components. See also ¶0066-¶0070; UE 102 preference and other settings).
Regarding Claim 4, Ravichandran in view of Pande teaches the device of claim 2, Ravichandran further teaches wherein the receiving the identifications for the first group of OTT applications, the providing the identifications for the first group of OTT applications, the providing the first identification of the first OTT application, and the receiving the first identification of the first OTT application are based at least in part on Session Initiation Protocol (SIP) messaging (¶0022-¶0025; TAS 116. Fig. 2 & ¶0025; IMS 200 is built on the session initiation protocol (SIP) and is the base to further support packaging of voice, video, data, and fixed and mobile services on a single platform to end users).
Regarding Claim 5, Ravichandran in view of Pande teaches the device of claim 4, Ravichandran further teaches wherein the SIP messaging establishes a first channel for the first OTT application and establishes a second channel for control signaling (Figs. 4-5 & ¶0069-¶0072; register the UE 102 with the TAS 116. In some examples, this can comprise a SIP REGISTER. The SIP REGISTER can include various information including, for example, the SIM ID 118 and any additional IDs (e.g., e-mail addresses or IP addresses) associated with the UE 102. The SIP REGISTER can also include application settings such as, for example, which application to use for each type of communication (e.g., the OTT application 104 or native application), routing information, and other relevant information. At 424, if all is correct in the SIP REGISTER, the TAS 116 can send a SIP 200 OK registering the SIM ID 118 with the TAS 116…UE 102 has established a secure session with the WRG 108).
Regarding Claim 6, Ravichandran in view of Pande teaches the device of claim 4, Ravichandran further teaches wherein the SIP messaging includes a field to negotiate application capability and preference between devices (Figs. 4-5 & ¶0069-¶0072; register the UE 102 with the TAS 116. In some examples, this can comprise a SIP REGISTER. The SIP REGISTER can include various information including, for example, the SIM ID 118 and any additional IDs (e.g., e-mail addresses or IP addresses) associated with the UE 102. The SIP REGISTER can also include application settings such as, for example, which application to use for each type of communication (e.g., the OTT application 104 or native application), routing information, and other relevant information. At 424, if all is correct in the SIP REGISTER, the TAS 116 can send a SIP 200 OK registering the SIM ID 118 with the TAS 116).
Regarding Claim 7, Ravichandran in view of Pande teaches the device of claim 1, Ravichandran further teaches wherein the facilitating the establishing the communication session includes establishing a first channel for the first OTT application, and wherein a second channel is established for a second OTT application for facilitating establishing a second communication session between the first and second end user devices at a same time as the communication session (¶0021-¶0026; TAS 116 can include the integration of real-time communication services such as instant messaging, presence information, voice and VOIP, audio, conferencing, and speech recognition with non-real-time communication services such as messaging (e.g., short messaging service (SMS), e-mail, and voicemail). Thus, the TAS 116 can include one or more software products to provide the same user interface (UI) and user experience across multiple devices and media types).
Regarding Claim 8, Ravichandran in view of Pande teaches the device of claim 1, Ravichandran further teaches wherein the operations comprise: receiving, from the second end user device, the first identification of the first OTT application, wherein the first identification of the first OTT application is selected by the second end user device according to a match in the first group of OTT applications executable by the first end user device and a second group of OTT applications executable by the second end user device (this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. When there is a match between user’s preferences for a specific call or particular service, then TAS will use the OTT according to the users’ preferences set in Fig. 10. See ¶0022-¶0026. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to reach the above limitation from Ravichandran’s teachings in order to provide applications and capabilities that are not otherwise available on the UE (abstract). Utilizing such teachings enable the user to dynamically configure how communications are sent and received in response to changing conditions or preferences via GUI (abstract)), and wherein at least one of the first and second groups of OTT applications are prioritized lists that are generated by the first and second end user devices, respectively (Fig. 10 provides a preferred list of OTT applications).
Regarding Claim 9, Ravichandran in view of Pande teaches the device of claim 8, Ravichandran further teaches wherein the prioritized lists are generated based on queries performed by the first and second end user devices of the first and second groups of OTT applications, respectively (obvious from Fig. 10 because each time a user updates the preferences, the update is sent to TAS 116).
Regarding Claim 10, Ravichandran in view of Pande teaches the device of claim 1, Ravichandran further teaches wherein the operations comprise: obtaining the first identification of the selected first OTT application, wherein the first identification of the first OTT application is selected by the second end user device according to device capabilities (obvious because if a device has a facetime, then this implies facetime will be used according to the capabilities of the device. Also see Fig. 10 provides a user’s selection. Also note that once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. When there is a match between user’s preferences for a specific call or particular service, then TAS will use the OTT according to the users’ preferences set in Fig. 10. See ¶0022-¶0026. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to reach the above limitation from Ravichandran’s teachings in order to provide applications and capabilities that are not otherwise available on the UE (abstract). Utilizing such teachings enable the user to dynamically configure how communications are sent and received in response to changing conditions or preferences via GUI (abstract)), and wherein at least one of the first and second groups of OTT applications are prioritized lists that are generated by the first and second end user devices, respectively (Fig. 10 provides a preferred list of OTT applications).
Regarding Claim 11, Ravichandran in view of Pande teaches the device of claim 1, Ravichandran further teaches wherein the first identification of the first OTT application, wherein the first identification of the selected first OTT application (¶0022-¶0026; this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. For example, the TAS 116 can terminate calls (whether audio or video), and the OTT application 104 can receive calls, via the dialer inside the OTT application 104 instead of the native dialer of the UE 102, see ¶0056) is selected by the second end user device based in part on (this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. When there is a match between user’s preferences for a specific call or particular service, then TAS will use the OTT according to the users’ preferences set in Fig. 10. See ¶0022-¶0026.
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to reach the above limitation from Ravichandran’s teachings in order to provide applications and capabilities that are not otherwise available on the UE (abstract). Utilizing such teachings enable the user to dynamically configure how communications are sent and received in response to changing conditions or preferences via GUI (abstract).
Ravichandran does not expressly teach and based in part on a recommendation of OTT applications generated by the processing system
Pande teaches and based in part on a recommendation of OTT applications generated by the processing system (see Pande at ¶0115-¶0125 & ¶0147-¶0149; At task 830, computer system 221 assesses and stores the quality that is based on at least one characteristic of the access network through which service would be delivered to the called party via OTT service i. In accordance with the illustrative embodiment of the present invention, computer system 221 assesses access network quality in the following manner. System 221 queries, at task 810, OTT system 241 if querying the OTT B call service, in order to determine the type of wireless network that the candidate terminating endpoint (e.g., endpoint 104-4, etc.) is on. OTT system 241 returns the queried-for information, and based on the information returned to it, system 221 determines a quality scoring of the OTT call service. The following is a listing of such scores, for example and without limitation: [0116] i. score of 0 if subscriber is offline or has opted out of receiving calls, [0117] ii. score 1 if subscriber's network is 2G, [0118] iii. score 2 if subscriber's network is 2.5G, [0119] iv. score 3 if subscriber's network is 3G and is in a developing visited country, [0120] v. score 4 if subscriber's network is 3G and is in a developed visited country, [0121] vi. score 5 if subscriber's network is 4G, [0122] vii. score 6 if subscriber's network is WiFi (i.e., a local area network), [0123] viii. score 7 if subscriber's network is LTE, and [0124] ix. score 8 if subscriber's network is LTE-A).
See reasons above for combining the art.
Claims 12-19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Ravichandran.
Regarding Claim 12, Ravichandran teaches a non-transitory, machine-readable medium, comprising executable instructions that, when executed by a processing system including a processor of a first end user device, facilitate performance of operations (Fig. 10 for a first user), the operations comprising:
generating a first prioritized list of Over-The-Top (OTT) applications that are executable by the first end user device (¶0022-¶0026 & Fig. 10; TAS 116 receives user’s preferences for different OTT applications [prioritized list] to handle a particular service. Each time the user updates the preferences, the system regenerates the list and updates the TAS 116. Also see ¶0059, ¶0110, ¶0113 & ¶0133);
providing, to a network server, identifications for a first group of OTT applications from the first prioritized list (¶0022-¶0026 & Fig. 10; TAS 116 [network server] receives user’s preferences for different OTT applications [prioritized list] to handle a particular service);
obtaining a first identification of a first OTT application of the first group of OTT applications, wherein the obtaining is based at least in part on a match with a second prioritized list of OTT applications that are executable by a second end user device (¶0022-¶0026; this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. For example, the TAS 116 can terminate calls (whether audio or video), and the OTT application 104 can receive calls, via the dialer inside the OTT application 104 instead of the native dialer of the UE 102, see ¶0056);
and participating in a communication session with the second end user device utilizing the first OTT application (¶0023; the OTT application 104 can enable the user to place a video call within the application using the specific video calling application needed or a video calling application that is agnostic to OS, type of UE, network, etc. also see Fig. 10 provides prioritized list of preferred OTT applications for delivering particular services. Fig. 10 applies to both first and second end user devices. So, it would have been obvious that the preferred/selected OTT in both lists will handle a video call using the specific video calling application needed or a video calling application that is agnostic to OS, type of UE, network, etc.).
Ravichandran does not expressly teach the bolded limitation “obtaining a first identification of a first OTT application of the first group of OTT applications, wherein the obtaining is based at least in part on a match with a second prioritized list of OTT applications that are executable by a second end user device” “wherein the match is determined by the second end user device based on a comparison of the first and second prioritized lists,” however, this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. When there is a match between user’s preferences for a specific call or particular service, then TAS will use the OTT according to the users’ preferences set in Fig. 10. Additionally, the comparisoin part is implied because once a device has a facetime, then the second device will recommend a facetime based on the device using facetime which is similar to comparison between both devices to determine common applications to make a video call. See ¶0022-¶0026.
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to reach the above limitation from Ravichandran’s teachings in order to provide applications and capabilities that are not otherwise available on the UE (abstract). Utilizing such teachings enable the user to dynamically configure how communications are sent and received in response to changing conditions or preferences via GUI (abstract).
Regarding Claim 13, Ravichandran teaches non-transitory, machine-readable medium of claim 12, wherein the obtaining the first identification of the first OTT application is based on a communication from the second end user device to the network server according to the match determined by the second end user device (Fig. 10 and related paragraphs, each time a user updated the user’s preference, the system regenerates and sends an update to TAS 116. Again, when the device uses a facetime, the second device will use facetime which implies the comparison. Claim 1 details the different scenarios).
Regarding Claim 14, Ravichandran teaches non-transitory, machine-readable medium of claim 12, wherein the providing the identifications for the first group of OTT applications and the obtaining the first identification of the first OTT application are based at least in part on Session Initiation Protocol (SIP) messaging (¶0022-¶0025; TAS 116. Fig. 2 & ¶0025; IMS 200 is built on the session initiation protocol (SIP) and is the base to further support packaging of voice, video, data, and fixed and mobile services on a single platform to end users).
Regarding Claim 15, Ravichandran teaches non-transitory, machine-readable medium of claim 14, wherein the SIP messaging establishes a first channel for the first OTT application and establishes a second channel for control signaling (Figs. 4-5 & ¶0069-¶0072; register the UE 102 with the TAS 116. In some examples, this can comprise a SIP REGISTER. The SIP REGISTER can include various information including, for example, the SIM ID 118 and any additional IDs (e.g., e-mail addresses or IP addresses) associated with the UE 102. The SIP REGISTER can also include application settings such as, for example, which application to use for each type of communication (e.g., the OTT application 104 or native application), routing information, and other relevant information. At 424, if all is correct in the SIP REGISTER, the TAS 116 can send a SIP 200 OK registering the SIM ID 118 with the TAS 116…UE 102 has established a secure session with the WRG 108).
Regarding Claim 16, Ravichandran teaches non-transitory, machine-readable medium of claim 14, wherein the SIP messaging includes a field to negotiate application capability and preference between devices (Figs. 4-5 & ¶0069-¶0072; register the UE 102 with the TAS 116. In some examples, this can comprise a SIP REGISTER. The SIP REGISTER can include various information including, for example, the SIM ID 118 and any additional IDs (e.g., e-mail addresses or IP addresses) associated with the UE 102. The SIP REGISTER can also include application settings such as, for example, which application to use for each type of communication (e.g., the OTT application 104 or native application), routing information, and other relevant information. At 424, if all is correct in the SIP REGISTER, the TAS 116 can send a SIP 200 OK registering the SIM ID 118 with the TAS 116).
Regarding Claim 17, Ravichandran teaches non-transitory, machine-readable medium of claim 12, wherein the communication session includes a first channel for the first OTT application and a second channel associated with at least one of audio, video, messaging or data (¶0060; FIGS. 4A and 4B, examples of the present disclosure can include a system 400 for enabling the UE 102 to register with the TAS 116 using the SIM ID 118 to receive communications (e.g., an audio or video call) via the OTT application 104. The communications can be received over a Wi-Fi 108 (or other) connection in addition to, or instead of, a cellular or other connection. This may be useful, for example, when cellular reception is poor, but the UE 102 has a strong Wi-Fi 108 signal).
Regarding Claim 18, Ravichandran teaches a method, comprising: receiving, by a processing system including a processor, a first prioritized list of a first group of Over-The-Top (OTT) applications that are executable by a first end user device (¶0022-¶0026 & Fig. 10; TAS 116 receives user’s preferences for different OTT applications [prioritized list] to handle a particular service. Also see ¶0059, ¶0110, ¶0113 & ¶0133);
providing, to a second end user device, identifications for the first group of OTT applications (¶0022-¶0026; this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. For example, the TAS 116 can terminate calls (whether audio or video), and the OTT application 104 can receive calls, via the dialer inside the OTT application 104 instead of the native dialer of the UE 102, see ¶0056);
and facilitating establishing a communication session between the first and second end user devices utilizing a first OTT application that is selected based at least in part on a match with a second prioritized list of OTT applications that are executable by the second end user device (¶0023; the OTT application 104 can enable the user to place a video call within the application using the specific video calling application needed or a video calling application that is agnostic to OS, type of UE, network, etc. also see Fig. 10 provides prioritized list of preferred OTT applications for delivering particular services. Fig. 10 applies to both first and second end user devices. So, it would have been obvious that the preferred/selected OTT in both lists will handle a video call using the specific video calling application needed or a video calling application that is agnostic to OS, type of UE, network, etc.).
Ravichandran does not expressly teach the bolded limitation in “and facilitating establishing a communication session between the first and second end user devices utilizing a first OTT application that is selected based at least in part on a match with a second prioritized list of OTT applications that are executable by the second end user device,” “wherein the first OTT application is selected by the second end user device, based on a comparison of the first and second prioritizes list and determining the match,” however, this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. When there is a match between user’s preferences for a specific call or particular service, then TAS will use the OTT according to the users’ preferences set in Fig. 10. Again, when the device uses a facetime, the second device will use facetime which implies the comparison. Claim 1 details the different scenarios. See ¶0022-¶0026. Also note that this limitation is obvious because once both devices register with TAS 116, either OTT applications or native applications will be used to place a call. Fig. 10 provides user’s preferences/list. This means that the first user device receives via TAS 116 the preferred application to be used for this specific call based on preferences in Fig. 10 of the second device. When there is a match between user’s preferences for a specific call or particular service, then TAS will use the OTT according to the users’ preferences set in Fig. 10.
For example, the TAS 116 can terminate calls (whether audio or video), and the OTT application 104 can receive calls, via the dialer inside the OTT application 104 instead of the native dialer of the UE 102, see ¶0056
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to reach the above limitation from Ravichandran’s teachings in order to provide applications and capabilities that are not otherwise available on the UE (abstract). Utilizing such teachings enable the user to dynamically configure how communications are sent and received in response to changing conditions or preferences via GUI (abstract).
Regarding Claim 19, Ravichandran teaches method of claim 18, wherein the receiving the first prioritized list of the first group of OTT applications and the providing the identifications for the first group of OTT applications are based at least in part on Session Initiation Protocol (SIP) messaging, and wherein the receiving the first prioritized list includes receiving device capabilities of the first end user device (¶0022-¶0025; TAS 116. Fig. 2 & ¶0025; IMS 200 is built on the session initiation protocol (SIP) and is the base to further support packaging of voice, video, data, and fixed and mobile services on a single platform to end users).
Regarding Claim 21, Ravichandran teaches the method of claim 19, wherein the SIP messaging includes a field to negotiate device capabilities and preference between devices (Figs. 4-5 & ¶0069-¶0072; register the UE 102 with the TAS 116. In some examples, this can comprise a SIP REGISTER. The SIP REGISTER can include various information including, for example, the SIM ID 118 and any additional IDs (e.g., e-mail addresses or IP addresses) associated with the UE 102. The SIP REGISTER can also include application settings such as, for example, which application to use for each type of communication (e.g., the OTT application 104 or native application), routing information, and other relevant information. At 424, if all is correct in the SIP REGISTER, the TAS 116 can send a SIP 200 OK registering the SIM ID 118 with the TAS 116), wherein the SIP messaging includes at least one of costs associated with use of particular OTT services, SLA agreement requirements and provisions, user relationships, context of the communication session or a combination thereof (¶0069; The SIP REGISTER can also include application settings such as, for example, which application to use for each type of communication (e.g., the OTT application 104 or native application), routing information, and other relevant information. At 424, if all is correct in the SIP REGISTER, the TAS 116 can send a SIP 200 OK registering the SIM ID 118 with the TAS 116), and wherein the first OTT application is selected by the second end user device, based on the SIP messaging in combination with the match (¶0069; obvious because The SIP REGISTER can also include application settings such as, for example, which application to use for each type of communication (e.g., the OTT application 104 or native application), routing information, and other relevant information. At 424, if all is correct in the SIP REGISTER, the TAS 116 can send a SIP 200 OK registering the SIM ID 118 with the TAS 116).
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 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 MAHRAN ABU ROUMI whose telephone number is (469)295-9170. The examiner can normally be reached Monday-Thursday 6AM-5PM.
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, Emmanuel Moise can be reached at 571-272-3865. 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.
MAHRAN ABU ROUMI
Primary Examiner
Art Unit 2455
/MAHRAN Y ABU ROUMI/Primary Examiner, Art Unit 2455
Prosecution Insights