DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 01/02/2026. Claims 1-20 are pending in this application.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 02/02/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS(s) is/are being considered by the examiner.
Response to Amendment
The double patenting rejection to claims 1-20 remains.
The claim objection to claim 11 is now withdrawn in view of the claim amendments.
Applicant’s arguments with respect to claims 1-20 have been considered but are moot based on the new grounds of rejection necessitated by Applicant’s amendments. Specifically, the arguments present that Yang fails to provide for the amended language, where the rejection below now relies on Lawson3 (US 20130072160 A1) to teach this subject matter.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory anticipatory-type double patenting as being unpatentable over the claims 1-20 of U.S. Application 16/985,624 (hereinafter ’624).
Although the claims at issue are not identical, they are not patentably distinct from each other because all the claimed limitations recited in the present application are transparently found in the listed patent(s) with obvious wording variations.
The table presented below exemplifies a mapping of independent claim 1 of the instant application to the claim 1 of ’624. Likewise, claims 2-20 contain subject matter found in claims 1-20 of patent ’624 (from amendments dated 12/18/2025).
Claim 1 of present application 19/000,360
Claim 1 of application 16/985,624
Claim 1: A method comprising:
providing, by a cloud-based communication platform, an Application Programming Interface (API) for developing a voice extension, the API defining one or more API commands to perform functions of an extended set of features provided by the voice extension rather than functions of a base set of features provided by the cloud-based communication platform;
receiving, by the cloud-based communication platform, the voice extension developed via the API; and
executing the voice extension to provide the functions of the extended set of features using the one or more API commands.
Claim 1: A method comprising:
receiving, by a cloud-based communication platform, an incoming communication request to initiate a communication session and a voice extension session, the communication session being initiated to provide, a base set of communication features by the cloud-based communication platform, the voice extension session operating concurrently with the communication session and being initiated based on an extension identifier included in the incoming communication request, the voice extension session providing a first communication feature not provided by the cloud-based communication platform;
accessing a set of communication instructions associated with the incoming communication request;
processing the incoming communication request based on the set of communication instructions, the processing of the incoming communication request comprises:
establishing the communication session associated with the base set of communication features;
determining that the set of communication instructions includes the extension identifier that corresponds to the voice extension, the voice extension being implemented as an individual software application developed via an Application Programming Interface (API) provided by the cloud-based communication platform, the API defining one or more API commands to perform one or more functions of the first communication feature provided by the voice extension rather than functions of the base set of communication features; and
initiating, the voice extension session based on the extension identifier included in the incoming communication request, functionality of the communication session being kept active during the voice extension session and being managed by the voice extension.
This is a nonstatutory anticipatory-type double patenting rejection.
Claim Rejections - 35 USC § 103
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.
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-2, 7-12 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lawson et al. (US 20140064467 A1, published 03/06/2014; hereinafter Lawson), in view of Lawson et al. (US 20130072160 A1, published 03/21/2013; hereinafter Lawson3).
For Claim 1, Lawson teaches a method comprising: …
executing the voice extension to provide the functions of the extended set of features using the one or more API commands (Lawson teaches a telephony/communication platform providing different levels of communication functionalities including basic functionality based on customization of modules, the functionality provided by the second module may not be included in the platform, and executing the application logic of the second module to provide different specified communication functionality via API calls; FIG. 1; para. [0024] “… modules can be different types of classifications of modules. A low-level module can provide basic functionality such as routing or bridging of endpoints and sessions. A platform mid-level module can provide instruction processing capabilities according to a set of platform primitives (i.e., application instructions and/or API calls). Additional resources of the mid-level module can provide TTS, DTMF input detection, media playback, and other suitable functionality …”; para. [0025] “… These modules are preferably stored outside of the telephony platform (e.g., on a server determined by the respective developers/ owners), but the modules may alternatively be stored within the telephony platform …”; para. [0027] “… Step S130 … The module identity code can direct communication control of the communication session/application to a different specified module … The operational state can include executing a particular type of command such as a type of application instruction or a redirection to a module identifier … As an example, a phone tree module may have the actions of various dual-tone multi-frequency (DTMF) (or alternatively speech recognition phrases) assigned to different modules that will be passed control if that action is taken …”).
Lawson does not explicitly teach, but Lawson3 teaches providing, by a cloud-based communication platform, an Application Programming Interface (API) for developing a voice extension, the API defining one or more API commands to perform functions of an extended set of features provided by the voice extension rather than functions of a base set of features provided by the cloud-based communication platform (Lawson3 teaches an application platform with an API to facilitate developing telecommunications software applications, wherein the developed telecommunications software applications are other than the established telecommunications applications; FIG.1; para. [0003] “… In effect, the complexities of telephonic billing act as an artificial barrier to entry against application developers, who lack the resources and desire to compete with established telecommunications players in the commercial domain of the latter. Given the importance of communications, however, there is a great need for attracting more developers and applications into the telephony marketplace …”; para. [0014] “… FIG. 1 also illustrates an operating environment of the system 10 of the preferred embodiment, which can include for example an Application Programming Interface (API) of the type generally available from the assignee of the present application … The system is preferably used in combination with an application platform with an API. The application platform preferably enables developer creation of applications utilizing at least some features of the platform. In one variation the application platform is a communication platform used for voice, video, or messaging. An example API can be configured as a telephony platform …”; para. [0015] “… As shown in FIG. 1, the API 12 of the preferred embodiment functions to permit one or more developers 14 (DEV A, DEV B, DEV C) to independently and efficiently create software programs for telephonic applications 16, including, but not limited to telephony-based voice calls, internet based voice calls, video calls, video streams, video sessions, screen sharing, screen sharing streams, screen sharing sessions, SMS messaging, MMS messaging, IP-based messaging, proprietary messaging, alternative messaging, or any suitable form of communication …”);
receiving, by the cloud-based communication platform, the voice extension developed via the API (Lawson3, FIG. 1; para. [0015] “… The applications 16 can be stored and retrievable in a database or databases (not shown) and made accessible to one or more users or purchasers. Applications may be stored in the database as a URI reference to an application hosted by the developer or alternative. The URI will preferably reference the application located on a server maintained by the developer …”); and …
Lawson3 and Lawson are analogous art because they are both related to communications functionalities.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the API facilitated software application development techniques of Lawson3 with the system of Lawson to facilitate the application developers providing desired functionalities in the developed applications (Lawson3, para. [0003]).
For Claim 2, Lawson-Lawson3 teaches the method of claim 1, wherein the command comprises a voice extension identifier (Lawson teaches receiving a module identify code in the request; para. [0027] “… Passing application control from the first module to a second module can include receiving a module identity code of the second module, wherein the module identity code is received during communication control of the first module …”).
For Claim 7, Lawson-Lawson3 teaches the method of claim 1, wherein the voice extension comprises one of a call processing and media session extension, a media stream extension, a media filter extension, a Dual-Tone Multi-Frequency (DTMF) extension (Lawson, para. [0024] “… As discussed more below, modules can be different types of classifications of modules. A low-level module can provide basic functionality such as routing or bridging of endpoints and sessions. A platform mid-level module can provide instruction processing capabilities according to a set of platform primitives (i.e., application instructions and/or API calls). Additional resources of the mid-level module can provide TTS, DTMF input detection, media playback, and other suitable functionality …”), and a fire and forget extension.
For Claim 8, Lawson-Lawson3 teaches the method of claim 1, wherein the functionality associated with the voice extension is provided without affecting operations of a previously established communication session (Lawson teaches a (second) module being invoked during the previously established communication session (i.e. the session associated the second module operating with the previously established communication session); FIG. 1; para. [0021] “… As shown in FIG. 1, a method S100 for running a multi-module telephony application of a preferred embodiment includes receiving an application request to a number associated with an account of a telephony platform S110; directing application control to a first module of an application of the account S120 … The modules or overall flow can alternatively be dynamically activated/invoked during a communication session … The customization or use of the modules can additionally be automatically invoked by a communication platform …”).
For Claim 9, Lawson-Lawson3 teaches the method of claim 1, comprising: establishing a voice extension session during which operations of a previously established communication session are transferred from a first state to a second state that is controlled by a voice extension instance of the voice extension, the previously established communication session providing the base set of features (Lawson teaches the control of a SIP communication session being transferred to a different level of communication module; FIG. 18; FIG. 19; FIG. 20A; FIG. 20B; para. [0061] “… An application can preferably modify state of the SIP session and perform actions such as redirect the call, hang-up, record a conversation, transcribe a conversation, send an message (e.g., SMS, MMS, application message), merge the call, and/or to perform any suitable action …”; para. [0062] “… Step S410, which includes establishing SIP communication session in a first mode, functions to establish either a communication session in a basic, application, or another alternative communication mode. The method may be used to promote or demote the SIP communication mode … As shown in FIG. 20A, a basic SIP communication mode maybe promoted to use the capabilities of an application communication mode. As shown in FIG. 20B, a SIP session in an application communication module may be demoted to forgo the application capabilities and operate in a mode controlled by the basic SIP communication module …”).
For Claim 10, Lawson-Lawson3 teaches the method of claim 9, comprising: receiving a communication indicating a completion of the voice extension session (Lawson teaches receiving a trigger signal to indicate ending control of the SIP communication session by the communication module; FIG. 18; FIG. 19; para. [0063] “… Step S420, which includes receiving a transition signal, functions to obtain identify a trigger to change modes of SIP communication. The transition signal may be received at any suitable point … In yet another variation, a callback URI may be registered for a communication session and/or an endpoint so that the action may be triggered based on the SIP messages. For example, a callback may be registered for a basic SIP communication session so upon one of the endpoints hanging up the other endpoint is changed to an application communication module which may be pre-specified …”); and
transferring the operations of the previously established communication session from the second state back to the first state (Lawson teaches the control of the SIP communication session being transferred back to the previous level of communication module; FIG. 18; FIG. 19; FIG. 20C; FIG. 20D; para. [0062] “… FIGS. 20C and 20D, the communication mode may switch multiple times …”).
For Claim 11, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above. Additionally, Lawson-Lawson3 teaches a system comprising: one or more processors; and one or more non-transitory computer-readable mediums storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations (Lawson, para. [0067] “… An alternative embodiment preferably implements the above methods in a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components preferably integrated with a multi-layered communication application platform … The computer-executable component is preferably a processor but the instructions may alternatively or additionally be executed by any suitable dedicated hardware device …”).
For Claim 12, the claim is substantially similar to claim 2 and therefore is rejected for the same reasoning set forth above.
For Claim 17, the claim is substantially similar to claim 7 and therefore is rejected for the same reasoning set forth above.
For Claim 18, the claim is substantially similar to claim 8 and therefore is rejected for the same reasoning set forth above.
For Claim 19, Lawson-Lawson3 teaches the system of claim 11, wherein the operations comprise: establishing a voice extension session during which operations of a previously established communication session are transferred from a first state to a second state that is controlled by a voice extension instance of the voice extension, the previously established communication session providing the base set of features (Lawson teaches the control of a SIP communication session being transferred to a different level of communication module; FIG. 18; FIG. 19; FIG. 20A; FIG. 20B; para. [0061] “… An application can preferably modify state of the SIP session and perform actions such as redirect the call, hang-up, record a conversation, transcribe a conversation, send an message (e.g., SMS, MMS, application message), merge the call, and/or to perform any suitable action …”; para. [0062] “… Step S410, which includes establishing SIP communication session in a first mode, functions to establish either a communication session in a basic, application, or another alternative communication mode. The method may be used to promote or demote the SIP communication mode … As shown in FIG. 20A, a basic SIP communication mode maybe promoted to use the capabilities of an application communication mode. As shown in FIG. 20B, a SIP session in an application communication module may be demoted to forgo the application capabilities and operate in a mode controlled by the basic SIP communication module …”);
receiving a communication indicating a completion of the voice extension session (Lawson teaches receiving a trigger signal to indicate ending control of the SIP communication session by the communication module; FIG. 18; FIG. 19; para. [0063] “… Step S420, which includes receiving a transition signal, functions to obtain identify a trigger to change modes of SIP communication. The transition signal may be received at any suitable point … In yet another variation, a callback URI may be registered for a communication session and/or an endpoint so that the action may be triggered based on the SIP messages. For example, a callback may be registered for a basic SIP communication session so upon one of the endpoints hanging up the other endpoint is changed to an application communication module which may be pre-specified …”); and
transferring the operations of the previously established communication session from the second state back to the first state (Lawson teaches the control of the SIP communication session being transferred back to the previous level of communication module; FIG. 18; FIG. 19; FIG. 20C; FIG. 20D; para. [0062] “… FIGS. 20C and 20D, the communication mode may switch multiple times …”).
For Claim 20, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above. Additionally, Lawson-Lawson3 teaches a non-transitory computer-readable medium storing instructions that, when executed by one or more computer processors of a cloud-based communication platform, cause the cloud-based communication platform to perform operations (Lawson, para. [0067] “… An alternative embodiment preferably implements the above methods in a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components preferably integrated with a multi-layered communication application platform … The computer-executable component is preferably a processor but the instructions may alternatively or additionally be executed by any suitable dedicated hardware device …”).
Claim Rejections - 35 USC § 103
Claims 3-6 and 13-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lawson et al. (US 20140064467 A1, published 03/06/2014; hereinafter Lawson), in view of Lawson et al. (US 20130072160 A1, published 03/21/2013; hereinafter Lawson3), and in further view of Nakai (US 20160183229 A1, published 06/23/2016; hereinafter Nakai).
For Claim 3, Lawson-Lawson3 teaches the method of claim 2. Lawson-Lawson3 does not explicitly teach, but Nakai teaches comprising: accessing a set of code corresponding to the voice extension identifier from an extension repository (Nakai teaches accessing call-control-data management table for communication details; FIGS 2, 3A-B, 6 and 9; para. [0022] " ... Upon receiving a voicemail connection request message from IP phone 4-1-j through IP phone controller 1-1-4, call controller 1-1-1 determines, from a voicemail extension number and VMID (voicemail ID) set in the message, that a corresponding voicemail port and mailbox both exist in the cloud, thereby setting, as the voicemail connection request message, virtual machine data acquired from call-control-data management table 1-1-6, and transmitting the message to cloud communication module 1-1-3 …”; para. [0027] “… ROM 13 stores control programs for call controller 1-1-1. The CPU 12 loads a resource extension program from the ROM 13, and executes resource extension processing in cooperation of the data center 3. Thus resource extension utilizing a cloud can be easily realized by storing the above-mentioned resource extension program in the ROM 13 …”); and …
Nakai and Lawson-Lawson3 are analogous art because they are both related to communications functionalities.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the voice extension communications techniques of Nakai with the system of Lawson-Lawson3 to easily realize resource extension utilizing a cloud (Nakai, para. [0027]).
Lawson-Lawson3-Nakai further teaches executing the set of code to generate a voice extension instance, the voice extension instance communicating with the cloud-based communication platform and an external computing system to provide the functionality that extends the base set of features (Lawson teaches executing the application logic of the second module to provide different specified communication functionality; FIG. 1; para. [0021] “… The modules or overall flow can alternatively be dynamically activated/invoked during a communication session …”; para. [0025] “… The modules can be independent application modules but can alternatively be different operational modes of one or more application modules that can use different resources and/or services …”; para. [0027] “… Step S130, which includes passing application control from the first module to a second module of the account through a linking system, functions to transfer the application control as viewed by the telephony platform to a second module. Passing application control from the first module to a second module can include receiving a module identity code of the second module, wherein the module identity code is received during communication control of the first module … The module identity code can direct communication control of the communication session/application to a different specified module … The operational state can include executing a particular type of command such as a type of application instruction or a redirection to a module identifier … As an example, a phone tree module may have the actions of various dual-tone multi-frequency (DTMF) (or alternatively speech recognition phrases) assigned to different modules that will be passed control if that action is taken …”).
For Claim 4, Lawson-Lawson3-Nakai teaches the method of claim 3, comprising: establishing a voice extension session by the voice extension instance (Lawson teaches executing the application logic of the second module to provide different specified communication functionality; FIG. 1; para. [0021] “… The modules or overall flow can alternatively be dynamically activated/invoked during a communication session …”; para. [0025] “… The modules can be independent application modules but can alternatively be different operational modes of one or more application modules that can use different resources and/or services …”; para. [0027] “… Step S130, which includes passing application control from the first module to a second module of the account through a linking system, functions to transfer the application control as viewed by the telephony platform to a second module. Passing application control from the first module to a second module can include receiving a module identity code of the second module, wherein the module identity code is received during communication control of the first module … The module identity code can direct communication control of the communication session/application to a different specified module … The operational state can include executing a particular type of command such as a type of application instruction or a redirection to a module identifier … As an example, a phone tree module may have the actions of various dual-tone multi-frequency (DTMF) (or alternatively speech recognition phrases) assigned to different modules that will be passed control if that action is taken …”); and
transferring communication functionalities of a previously established communication session to the voice extension session, the previously established communication session providing the base set of features (Lawson teaches passing application control from the first module to the second module, different modules providing different communication functionalities; FIG. 1; para. [0024] “… modules can be different types of classifications of modules. A low-level module can provide basic functionality such as routing or bridging of endpoints and sessions. A platform mid-level module can provide instruction processing capabilities according to a set of platform primitives (i.e., application instructions and/or API calls). Additional resources of the mid-level module can provide TTS, DTMF input detection, media playback, and other suitable functionality …”; para. [0027] “… Step S130, which includes passing application control from the first module to a second module of the account through a linking system, functions to transfer the application control as viewed by the telephony platform to a second module. Passing application control from the first module to a second module can include receiving a module identity code of the second module, wherein the module identity code is received during communication control of the first module …”).
For Claim 5, Lawson-Lawson3-Nakai teaches the method of claim 4, comprising: pausing the previously established communication session until a completion of the voice extension session (Lawson teaches transferring the control of a SIP communication session to a different level of communication module until receiving a trigger signal to indicate ending control of the SIP communication session by the communication module; FIG. 18; FIG. 19; FIG. 20A; FIG. 20B; para. [0061] “… An application can preferably modify state of the SIP session and perform actions such as redirect the call, hang-up, record a conversation, transcribe a conversation, send an message (e.g., SMS, MMS, application message), merge the call, and/or to perform any suitable action …”; para. [0062] “… Step S410, which includes establishing SIP communication session in a first mode, functions to establish either a communication session in a basic, application, or another alternative communication mode. The method may be used to promote or demote the SIP communication mode … As shown in FIG. 20A, a basic SIP communication mode maybe promoted to use the capabilities of an application communication mode. As shown in FIG. 20B, a SIP session in an application communication module may be demoted to forgo the application capabilities and operate in a mode controlled by the basic SIP communication module …”; para. [0063] “… Step S420, which includes receiving a transition signal, functions to obtain identify a trigger to change modes of SIP communication. The transition signal may be received at any suitable point … In yet another variation, a callback URI may be registered for a communication session and/or an endpoint so that the action may be triggered based on the SIP messages. For example, a callback may be registered for a basic SIP communication session so upon one of the endpoints hanging up the other endpoint is changed to an application communication module which may be pre-specified …”).
For Claim 6, Lawson-Lawson3-Nakai teaches the method of claim 4, comprising: terminating the previously established communication session upon a completion of the voice extension session (Lawson teaches transferring the control of a SIP communication session to a different level of communication module until receiving a trigger signal to indicate ending control of the SIP communication session by the communication module, the SIP communication session may be terminated by the application (e.g. hang-up); FIG. 18; FIG. 19; FIG. 20A; FIG. 20B; para. [0061] “… An application can preferably modify state of the SIP session and perform actions such as redirect the call, hang-up, record a conversation, transcribe a conversation, send an message (e.g., SMS, MMS, application message), merge the call, and/or to perform any suitable action …”; para. [0062] “… Step S410, which includes establishing SIP communication session in a first mode, functions to establish either a communication session in a basic, application, or another alternative communication mode. The method may be used to promote or demote the SIP communication mode … As shown in FIG. 20A, a basic SIP communication mode maybe promoted to use the capabilities of an application communication mode. As shown in FIG. 20B, a SIP session in an application communication module may be demoted to forgo the application capabilities and operate in a mode controlled by the basic SIP communication module …”; para. [0063] “… Step S420, which includes receiving a transition signal, functions to obtain identify a trigger to change modes of SIP communication. The transition signal may be received at any suitable point … In yet another variation, a callback URI may be registered for a communication session and/or an endpoint so that the action may be triggered based on the SIP messages. For example, a callback may be registered for a basic SIP communication session so upon one of the endpoints hanging up the other endpoint is changed to an application communication module which may be pre-specified …”).
For Claim 13, the claim is substantially similar to claim 3 and therefore is rejected for the same reasoning set forth above.
For Claim 14, the claim is substantially similar to claim 4 and therefore is rejected for the same reasoning set forth above.
For Claim 15, the claim is substantially similar to claim 5 and therefore is rejected for the same reasoning set forth above.
For Claim 16, the claim is substantially similar to claim 6 and therefore is rejected for the same reasoning set forth above.
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. ILYAYEV (US 20110126168 A1) teaches a cloud platform for managing Software as a Service (SaaS) resources. The platform includes: a mediator server connected to computing resources, arranged to provide software developers a platform to develop SaaS applications, operable on the computing resources, wherein the SaaS applications and customer data are stored logically and physically independent of the computing resources, and data of SaaS application and the customer data are logically and physically separated. SaaS platform allows developers to provide software solutions via the mediator server directly to customers, and ensures data availability and data security. Access policy of users and developers to SaaS applications is centrally supervised and capable of integrating with other applications on the site of the customer. Upgrades to SaaS applications are performed in a predefined order of customers. Further, the SaaS platform facilitates selection and replacement of data storage provider (Abstract).
ii. Webster et al. (US 20200150934 A1) teaches a voice interaction development tool. Initially, user input associating voice interaction data with a visual object is received via a user interface. The voice interaction data, for example, may include voice commands and corresponding output content. Subsequently, a request is received from a voice assistant platform, due to initiation via a voice command to the voice assistant platform. In real-time (e.g., as the user speaks the voice command) a visual object corresponding to the spoken voice command is graphically indicated, e.g., a flow diagram element corresponding to the voice command is emphasized. In real-time as output content corresponding to the voice command is output by a voice assistant device, the user interface provides a graphical indication of the visual object associated with the output content. In this way, the described system provides graphical feedback for testing voice interactions being developed (Abstract).
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 ZONGHUA DU whose telephone number is (408)918-7596. The examiner can normally be reached Monday - Friday 8 AM - 5 PM PST.
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, John Follansbee can be reached on (571) 272-3964. 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.
/Z.D./Examiner, Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444
Prosecution Insights