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 .
DETAILED ACTION
This communication is in response to applicant’s 01/07/2026 amendments/responses in the application of ZHANG et al. for “CALL SWITCHING METHOD AND APPARATUS, STORAGE MEDIUM AND MOBILE TERMINAL” filed 06/29/2022. The amendments/response to the claims have been entered. No claims have been canceled. No claims have been added. Claims 1-19 are now pending.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by FRAZIER et al. (US 2018/0288228 A1), hereinafter FRAZIER.
Regarding claim 1, FRAZIER discloses a call switching method, comprising:
triggering a second call module (OTT calling app 155 in mobile device 120, see figures 1 and 10) to query whether a call of which call type is a second call type (in OTT calls active, see figure 10 and ¶ 0057) is currently executed when it is detected that a first call module receives a call request of which call type is a first call type (detecting incoming MDN call while one or n total OTT call(s) is/are active or a user of called mobile device 120 may be engaged in an OTT call, and have at least one other OTT call on-hold, when an incoming MDN call occurs, see figures 10 and ¶ 0057; the OS call manager 150 determining if the user of the mobile device 120 has accepted in incoming MDN calls… then OS call manager 150 notifies OTT calling app 155 of the new MDN call (block 1005). FIG. 11 depicts a user accepting 1100 an incoming MDN call, and OSS call manager 150, based on acceptance of the MDN call, sending a notification 1110 to OTT calling app 155 indicating the new incoming MDN call, see ¶ 0058);
controlling the first call module (OS call manager 150, see figure 6) to generate prompt information if a call of which call type is the second call type (VOIP call) is currently executed (the user at mobile device 120 to accept the incoming MDN call including, for example, pressing an “answer” button upon a touch screen of the OS user interface of mobile device 120, shaking mobile device 120 to cause the MDN call to be answered, or performing a sliding motion upon a button of the touch screen of the OS user interface of mobile device 120 to cause the MDN call to be answered… then OS call manager 150 notifies OTT calling app 155 of the new MDN call (block 1005). FIG. 11 depicts a user accepting 1100 an incoming MDN call, and OSS call manager 150, based on acceptance of the MDN call, sending a notification 1110 to OTT calling app 155 indicating the new incoming MDN call, see ¶ 0058);
switching from a call of the second call type (one of the active OTT calls) to a call of the first call type (MDN call, see figures 10-11) when a first user instruction fed back by a user according to the prompt information is detected (making the incoming MDN call to active if the user accept the call 1100, steps 1000-1030, see figures 10-11, ¶ 0058).
Regarding claim 2, FRAZIER discloses the triggering the second call module to query a call state of the current call of the second call type; controlling the first call module to generate prompt information if the call state of the current call of the second call type is a first call state (the OTT calling App 55 keep tracks of OTT calls: active/inactive, see 5A-7C, and the OS call manager 150 display status of MDN call and OTT call in OS UI, see figure 9 and ¶ 0058).
Regarding claim 3, FRAZIER discloses marking a call state of the call of the second call type as a second call state and marking a call state of the call of the first call type as the first call state (the OS Call Manager 150 display the status of OTT calls and MDS call as either active or inactive: see figures 9, 11).
Regarding claim 4, FRAZIER discloses executing a call of which call type is the first call type if the call state of the current call of the second call type is the second call state (the OS call manager 150 accept MDN call based on the user input 1100 and make the OTT call as inactive, see figure 11).
Regarding claim 5, FRAZIER discloses a marking unit configured to mark a call state of the call of the second call type as a second call state and mark a call state of the call of the first call type as the first call state (the OS call manager 150 accept MDN call based on the user input 1100 and make the OTT calls as inactive and MDN call as active, see steps 1005-1010 figures 10, 11).
Regarding claim 14, FRAZIER discloses the first call type is one of a circuit switched (CS) voice call, Internet Protocol (IP) multimedia subsystem (IMS) voice call, or over the top (OTT) voice call, and the second call type is another one of CS voice call, IMS voice call, or OTT voice call; and the IMS voice call comprises voice over long term evolution (VoLTE) or voice over WIFI (VoWiFi) (the calls are OTT calls MDN calls, see ¶ 0019-0022).
Regarding clam 15, FRAZIER discloses the call state of the current call shows whether the current call is in call or not (the UE show the call states (either active or inactive) for OTT calls or MDN calls, see figure 9-11).
Regarding claim 6, FRAZIER discloses a call switching apparatus (mobile device 120, see figure 1), comprising:
a query unit configured to trigger a second call module ((the OS call manager 150 in mobile device 120, see figures 1 and 10) to query whether a call of which call type is a second call type is currently executed when it is detected that a first call module receives a call request of which call type is a first call type (detecting incoming MDN call while one or n total OTT call(s) is/are active, see figures 10-1);
a generating unit configured to control the first call module to generate prompt information if a call of which call type is the second call type (VOIP call) is currently executed (the user at mobile device 120 to accept the incoming MDN call including, for example, pressing an “answer” button upon a touch screen of the OS user interface of mobile device 120, shaking mobile device 120 to cause the MDN call to be answered, or performing a sliding motion upon a button of the touch screen of the OS user interface of mobile device 120 to cause the MDN call to be answered… then OS call manager 150 notifies OTT calling app 155 of the new MDN call (block 1005). FIG. 11 depicts a user accepting 1100 an incoming MDN call, and OSS call manager 150, based on acceptance of the MDN call, sending a notification 1110 to OTT calling app 155 indicating the new incoming MDN call, see ¶ 0058);
a switching unit to switch from a call of the second call type (one of the active OTT calls) to a call of the first call type (MDN call, see figures 10-11) when a first user instruction fed back by a user according to the prompt information is detected (making the incoming MDN call to active if the user accept the call 1100, steps 1000-1030, see figures 10-11, ¶ 0058).
Regarding claim 7, FRAZIER discloses the query unit is specifically configured to trigger the second call module to query a call state of the current call of the second call type; the generating unit is specifically configured to control the first call module to generate prompt information if the call state of the current call of the second call type is a first call state (the OTT calling App 55 keep tracks of all OTT calls: active/inactive, see 5A-7C, and the OS call manager 150 displays status of MDN calls and OTT calls in OS UI, see figure 9 and ¶ 0058).
Regarding claim 8, FRAZIER discloses a marking unit configured to mark a call state of the call of the second call type as a second call state and mark a call state of the call of the first call type as the first call state (the OS Call Manager 150 display the status of OTT calls and MDS call as either active or inactive: see figures 9, 11).
Regarding clam 16, FRAZIER discloses the call state of the current call shows whether the current call is in call or not (the UE 120 display the status of the current call as active, see figure 9).
Regarding claim 17, FRAZIER discloses the first call type is one of a circuit switched (CS) voice call, Internet Protocol (IP) multimedia subsystem (IMS) voice call, or over the top (OTT) voice call, and the second call type is another one of CS voice call, IMS voice call, or OTT voice call; and the IMS voice call comprises voice over long term evolution (VoLTE) or voice over WIFI (VoWiFi) (the calls are OTT calls MDN calls, see ¶ 0019-0022).
Regarding claim 9, FRAZIER discloses mobile terminal (a mobile device 120, see figure 1), wherein the mobile terminal comprises a processor and a memory, the memory stores a computer program, the processor calls the computer program stored in the memory to perform a call switching method, the call switching method comprises:
triggering a second call module (the OS call manager 150 in mobile device 120, see figures 1 and 10) to query whether a call of which call type is a second call type is currently executed when it is detected that a first call module receives a call request of which call type is a first call type (detecting incoming MDN call while one or n total OTT call(s) is/are active, see figures 10-1);
controlling the first call module to generate prompt information if a call of which call type is the second call type (VOIP call) is currently executed (the user at mobile device 120 to accept the incoming MDN call including, for example, pressing an “answer” button upon a touch screen of the OS user interface of mobile device 120, shaking mobile device 120 to cause the MDN call to be answered, or performing a sliding motion upon a button of the touch screen of the OS user interface of mobile device 120 to cause the MDN call to be answered… then OS call manager 150 notifies OTT calling app 155 of the new MDN call (block 1005). FIG. 11 depicts a user accepting 1100 an incoming MDN call, and OSS call manager 150, based on acceptance of the MDN call, sending a notification 1110 to OTT calling app 155 indicating the new incoming MDN call, see ¶ 0058);
switching from a call of the second call type (one of the active OTT calls) to a call of the first call type (MDN call, see figures 10-11) when a first user instruction fed back by a user according to the prompt information is detected (making the incoming MDN call to active if the user accept the call 1100, steps 1000-1030, see figures 10-11, ¶ 0058).
Regarding claim 10, FRAZIER discloses the triggering the second call module to query a call state of the current call of the second call type; controlling the first call module to generate prompt information if the call state of the current call of the second call type is a first call state (the OTT calling App 55 keep tracks of OTT calls: active/inactive, see 5A-7C, and the OS call manager 150 display status of MDN call and OTT call in OS UI, see figure 9 and ¶ 0058).
Regarding claim 11, FRAZIER discloses marking a call state of the call of the second call type as a second call state and marking a call state of the call of the first call type as the first call state (the OS Call Manager 150 display the status of OTT calls and MDS call as either active or inactive: see figures 9, 11).
Regarding claim 12, FRAZIER discloses executing a call of which call type is the first call type if the call state of the current call of the second call type is the second call state (the OS call manager 150 accept MDN call based on the user input 1100 and make the OTT calls as inactive, see figure 11).
Regarding claim 13, FRAZIER discloses a marking unit configured to mark a call state of the call of the second call type as a second call state and mark a call state of the call of the first call type as the first call state (the OS call manager 150 accept MDN call based on the user input 1100 and make the OTT calls as inactive and MDN call as active, see steps 1005-1010 figures 10, 11).
Regarding claim 18, FRAZIER discloses the first call type is one of a circuit switched (CS) voice call, Internet Protocol (IP) multimedia subsystem (IMS) voice call, or over the top (OTT) voice call, and the second call type is another one of CS voice call, IMS voice call, or OTT voice call; and the IMS voice call comprises voice over long term evolution (VoLTE) or voice over WIFI (VoWiFi) (the calls are OTT calls MDN calls, see ¶ 0019-0022).
Regarding clam 19, FRAZIER discloses the call state of the current call shows whether the current call is in call or not (the UE show the call states (either active or inactive) for OTT calls or MDN calls, see figure 9-11).
Response to Arguments
Applicant's arguments filed 11/19/2025 have been fully considered but they are not persuasive. FRAZIER discloses the following in ¶ 0022:
Called mobile device 120 further has an Operating System (OS) call manager 150 and an OTT calling app 155. OS call manager 150 includes executable OS software that may manage MDN calls and an OTT call received at called mobile device 120. OTT calling app 155 may include executable app software that manages multiple OTT calls received at called mobile device 120 in a manner that is transparent to OS call manager 150. In one exemplary implementation, OS call manager 150 may include Apple's “Call Kit,” or a similar OS application. In another exemplary implementation, OTT calling app 155 may include Verizon's “OneTalk” OTT calling app, or a similar OTT calling app.
In ¶ 0040:
… OTT calling app 155 at called mobile device 120, upon receipt of the push notification, notifies OS call manager 150 of the OTT call (block 403). As shown in FIG. 5A, OTT calling app 155 sends an internal notification 503 to OS call manager 150 to notify OS call manager 150 of the incoming OTT call. OS call manager 150 registers the first OTT call (block 405) and displays the first OTT call via the OS user interface (block 407). OS call manager 150, within its call status management functionality, registers the new OTT call, and designates it as an active call. Additionally, OS call manager 150 inactivates (e.g., places on hold) any currently active MDN call when the user accepts the incoming OTT call. To inactivate a MDN call, OS call manager 150 may send a message to MN TAS 140 requesting the MDN call to be inactivated. FIG. 5A depicts OS call manager 150 registering 505 the OTT call, and displaying 508 the OTT call via the OS user interface.
In ¶ 0041:
…FIG. 6 depicts an example of the OS user interface 600 of mobile device 120 where a touch screen is a component of OS user interface 600. As shown, the OTT call is represented by a highlighted icon 605 that includes a descriptor (e.g., phone number) for the OTT call and a visual indication that the call is active (e.g., a bright color), and the MDN call is represented by an icon 610 that includes a descriptor for the MDN call and a visual indication that the call is inactive (e.g., darkened color)…
Also, in ¶ 0058:
The exemplary process may include OS call manager 150 determining if the user of called mobile device 120 has accepted an incoming MDN call (block 1000). Various techniques may be used by the user at mobile device 120 to accept the incoming MDN call including, for example, pressing an “answer” button upon a touch screen of the OS user interface of mobile device 120, shaking mobile device 120 to cause the MDN call to be answered, or performing a sliding motion upon a button of the touch screen of the OS user interface of mobile device 120 to cause the MDN call to be answered. Other techniques or inputs may be used for determining if the user of mobile device 120 accepts the incoming MDN call. If the user has accepted an incoming MDN call (YES—block 1000), then OS call manager 150 notifies OTT calling app 155 of the new MDN call (block 1005). FIG. 11 depicts a user accepting 1100 an incoming MDN call, and OSS call manager 150, based on acceptance of the MDN call, sending a notification 1110 to OTT calling app 155 indicating the new incoming MDN call.
As cited above, the mobile device 120 comprises of at least OS manager 150 and OTT calling app 155. The OS call manager 150 is to keep track the status of current calls, whether active or inactive or new request, for OTT calls and MDN calls. In ¶ 0040, the OTT calling app 155 send internal notification to the OS call manager 150 about ongoing OTT call(s) and displays the OTT call to the user vs OS user interface as example for OTT calls (see figures 6, 7A-7C). In ¶ 0057-0058, another example, OS manager receiving a new MDN call request while ongoing active OTT call(s) and the user is presented with option to accept the new MDN call (see figure 6). In both cases, the OS call manager 150 displays the MDN call(s) and OTT call(s) to the user and keep track of the active and inactive calls (see figures 6, 7A-7C). The user is always present with option to switch/toggle between MDN calls and OTT call(s) (see figures 6, 7A-7C). Therefore, FRAZIER discloses the claimed subject matter “triggering a second call module to query whether a call of which call type is a second call type is currently executed when it is detected that a first call module receives a call request of which call type is a first call type… and controlling the first call module to generate prompt information if a call of which call type is the second call type is currently executed.”
Conclusion
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 response to this action should be mailed to:
The following address mail to be delivered by the United States Postal Service (USPS) only:
Mail Stop _____________
Commissioner for Patents
P. O. Box 1450
Alexandria, VA 22313-1450
or faxed to:
(571) 273-8300, (for formal communications intended for entry)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Bob A. Phunkulh whose telephone number is (571) 272-3083. The examiner can normally be reached on Monday-Thursday from 8:00 A.M. to 5:00 P.M. (first week of the bi-week) and Monday-Friday (for second week of the bi-week).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor CHARLES C. JIANG can be reach on (571) 270-7191.
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).
/BOB A PHUNKULH/Primary Examiner, Art Unit 2412