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 12/18/2025. Claims 1-20 are pending in this application.
Priority
This application claims priority of 62/882873 dated 08/05/2019, filed on 08/05/2020. The assignee of record is Twilio INC. The listed inventor(s) is/are: Fahlgren, Christer Jan Erik; Dominique, Torkel; Ren, Huipeng.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/18/2025 has been entered.
Response to Amendment
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.
Claim Objections
Claims 1, 11 and 20 are objected to because of the following informalities:
In Claims 1, 11 and 20, the limitation “provide, a base set of communication features” in line 4, line 8 and line 6 respectively will read as “provide a base set of communication features.”
In Claims 1, 11 and 20, the limitation “initiating, the voice extension session” in line 22, line 26 and line 24 respectively will read as “initiating the voice extension session.”
Appropriate correction is required.
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, 4-5, 7-11, 14-15 and 17-20 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 20160225044 A1, published 08/04/2016; hereinafter Lawson2), and in further view of Lawson et al. (US 20130072160 A1, published 03/21/2013; hereinafter Lawson3).
For Claim 1, Lawson teaches a method comprising:
receiving, by a cloud-based communication platform, an incoming communication request to initiate a communication session (Lawson discloses communication functionalities provided by a first module – para. [0021]) and a voice extension session (Lawson discloses communication functionalities provided by a second module – para. [0027]), the communication session being initiated to provide a base set of communication features by the cloud-based communication platform (Lawson discloses a telephony/communication platform providing different levels of communication functionalities including basic functionality based on customization of modules; FIG. 1; “… 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 customization or use of the modules can additionally be automatically invoked by a communication platform …” – para. [0021]; “… 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. [0024]; “… 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 …” – para. [0027]), the voice extension session operating concurrently with the communication session (Lawson discloses “… The modules or overall flow can alternatively be dynamically activated/invoked during a communication session …” – para. [0021]) and being initiated based on an extension identifier (Lawson discloses a module identity code) included in the incoming communication request (Lawson, “… 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 …” – para. [0027]), the voice extension session providing a first communication feature not provided by the cloud-based communication platform (Lawson discloses that the functionality provided by the second module may not be included in the platform; FIG. 1; “… 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. [0025]);
accessing a set of communication instructions associated with the incoming communication request (Lawson discloses accessing a plurality of modules configured in a flow for processing the communication request; FIG. 1; FIG. 2; “… Step S110 … The application request is preferably a communication session request, that initiates, establishes, or connects at least one endpoint in a communication session … A communication session is controlled by at least one application module … The application is preferably composed of at least one module. The at least one module is preferably configured to direct application control to at least one other module. The second module that the first module directs application control to may be determined through the application logic of the module … More preferably, the application is preconfigured to include a plurality of modules that have a configured flow as shown in FIG. 2 … 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. [0025]);
processing the incoming communication request based on the set of communication instructions (Lawson, FIG. 1; FIG. 2; “… the modules include different operational modes of the communication platform that utilize different application logic and/or resources of the communication platform …” – para. [0025]), the processing of the incoming communication request comprises:
establishing the communication session associated with the base set of communication features (Lawson, FIG. 1; FIG. 2; “… A low-level module can provide basic functionality such as routing or bridging of endpoints and sessions …” – para. [0024]; “… The application request can be directed at a phone number, a SIP address, or any suitable endpoint address. The application request is preferably a communication session request, that initiates, establishes, or connects at least one endpoint in a communication session …” – para. [0025]);
determining that the set of communication instructions includes the extension identifier that corresponds to the voice extension (Lawson discloses determining the module identity code for a second module from the application logic of the first module; FIG. 1; “… 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. [0025]; “… Step S120, which includes directing application control to a first module of an application of the account, functions to direct the telephony platform to communicate with the first module to determine application logic …” – para. [0026]; “… 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 …” – para. [0027]), …; 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 (Lawson discloses executing the application logic of the second module to provide different specified communication functionality while the communication session being active; FIG. 1; “… The modules or overall flow can alternatively be dynamically activated/invoked during a communication session …” – para. [0021]; “… 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. [0025]; “… 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 …” – para. [0027]).
Lawson does not explicitly teach, but Lawson2 teaches functionality of the communication session being managed by the voice extension (Lawson2 discloses a media analysis functionality providing services and management to the communication session; FIG. 2, “… Activating media analysis in accordance with platform configuration, functions to trigger media analysis automatically. In one variation, media analysis can be pre-configured for communications (e.g., calls or messages). Media analysis can be configured to automatically activate for communications to or from a particular endpoint, communications associated with an account or sub-account, …” – para. [0032]; “… Block S120, which includes collecting media for analysis, functions to obtain the media for analysis. In a preferred variation, the media intelligence platform is part of a platform that participates in routing of a media path for a communication. In synchronous communications (e.g., voice calls, video calls, multi-media streams, etc.), at least one media intelligence resource is preferably in the media path. In one variation, the platform of media intelligence may provide additional services, such as communication flow control. Such services may be used in combination with the media analysis. In another variation, a media stream may be streamed to and terminated at the media intelligence platform. For example, a third party communication system may stream a communication to the media intelligence platform, wherein the associated communication is handled through the third party communication system …” – para. [0035]).
Lawson and Lawson2 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 media analysis service techniques of Lawson2 with the system of Lawson to activate the media analysis services for communication sessions of selected entities (Lawson2, para. [0030]).
Lawson-Lawson2 does not explicitly teach, but Lawson3 teaches 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 provided by the cloud-based communication platform (Lawson3 discloses 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; “… 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. [0003]; “… 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. [0014]; “… 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 …” – para. [0015]).
Lawson3 and Lawson-Lawson2 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-Lawson2 to facilitate the application developers providing desired functionalities in the developed applications (Lawson3, para. [0003]).
For Claim 4, Lawson-Lawson2-Lawson3 teaches the method of claim 1, further comprising: initiating the voice extension session during which operation of the communication session is transferred from a first state to a second state controlled by a voice extension instance of the voice extension (Lawson discloses the control of a SIP communication session being transferred to a different level of communication module; FIG. 18; FIG. 19; FIG. 20A; FIG. 20B; “… 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. [0061]; “… 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. [0062]);
receiving a communication indicating a completion of the voice extension session (Lawson discloses receiving a trigger signal to indicate ending control of the SIP communication session by the communication module; FIG. 18; FIG. 19; “… 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 …” – para. [0063]); and
transferring operation of the communication session from the second state back to the first state (Lawson discloses 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; “… FIGS. 20C and 20D, the communication mode may switch multiple times …” – para. [0062])
For Claim 5, Lawson-Lawson2-Lawson3 teaches the method of claim 4, wherein the voice extension instance communicates with an external network location to provide the first communication feature (Lawson discloses communicating with externally hosted application server to provide the application logic of the communication module; FIG. 1; “… A communication session starts by invoking an application module. A module preferably represents an operational mode. The module preferably includes at least one routine of application logic that dictates how one resource manages or controls the communication session. The application logic can be internally configured in one or more resources, but may alternatively be externally hosted (such as at a URI of an application server) …” – para. [0023]).
For Claim 7, Lawson-Lawson2-Lawson3 teaches the method of claim 1, wherein the incoming communication request is a request to initiate the communication session (Lawson, FIG. 1; “… Step S110, which includes receiving an application request to a number associated with an account of a telephony platform, functions to handle an incoming request to the telephony platform … The application request is preferably a communication session request, that initiates, establishes, or connects at least one endpoint in a communication session …” – para. [0025]).
For Claim 8, Lawson-Lawson2-Lawson3 teaches the method of claim 7, wherein accessing the set of communication instructions associated with the incoming communication request comprises: identifying a resource identifier associated with the incoming communication request, the resource identifier (Lawson, e.g. a URI – para. [0023]) identifying a network destination (Lawson, e.g. an application server hosting application logic) for accessing the set of communication instructions (Lawson discloses using a URI of an application server for accessing the application logic of an application that may include a plurality of modules configured in a flow; FIG. 1; “… A communication session starts by invoking an application module. A module preferably represents an operational mode. The module preferably includes at least one routine of application logic that dictates how one resource manages or controls the communication session. The application logic can be internally configured in one or more resources, but may alternatively be externally hosted (such as at a URI of an application server) …” – para. [0023]; “… Step S110 … A communication session is controlled by at least one application module … The incoming application request is preferably directed to an application assigned to a phone number … The application is preferably composed of at least one module. The at least one module is preferably configured to direct application control to at least one other module. The second module that the first module directs application control to may be determined through the application logic of the module … More preferably, the application is preconfigured to include a plurality of modules that have a configured flow as shown in FIG. 2 …” – para. [0025]); and
accessing the set of communication instructions based on the resource identifier associated with the incoming communication request (Lawson, FIG. 1; “… A communication session starts by invoking an application module. A module preferably represents an operational mode. The module preferably includes at least one routine of application logic that dictates how one resource manages or controls the communication session. The application logic can be internally configured in one or more resources, but may alternatively be externally hosted (such as at a URI of an application server) …” – para. [0023]).
For Claim 9, Lawson-Lawson2-Lawson3 teaches the method of claim 8, wherein identifying the resource identifier associated with the incoming communication request comprises: identifying the resource identifier assigned to an endpoint identifier used to initiate the incoming communication request (Lawson discloses using a URI of an application server for accessing the application logic of an application assigned to a communication endpoint address; FIG. 1; “… A communication session starts by invoking an application module. A module preferably represents an operational mode. The module preferably includes at least one routine of application logic that dictates how one resource manages or controls the communication session. The application logic can be internally configured in one or more resources, but may alternatively be externally hosted (such as at a URI of an application server) …” – para. [0023]; “…The application request is preferably a communication session request, that initiates, establishes, or connects at least one endpoint in a communication session … The incoming application request is preferably directed to an application assigned to a phone number. The communication request (e.g., an incoming call or API call request) can alternatively be addressed to any suitable communication endpoint or destination address such as a SIP address, an account name address, or any suitable communication addressable endpoint …” – para. [0025]).
For Claim 10, Lawson-Lawson2-Lawson3 teaches the method of claim 1, wherein accessing the set of communication instructions associated with the incoming communication request comprises: identifying a resource identifier included in the incoming communication request, the resource identifier (Lawson, e.g. a URI – para. [0023]) identifying a location (Lawson, e.g. an application server hosting application logic) of the set of communication instructions (Lawson discloses using a URI of an application server for accessing the application logic of an application that may include a plurality of modules configured in a flow; FIG. 1; “… A communication session starts by invoking an application module. A module preferably represents an operational mode. The module preferably includes at least one routine of application logic that dictates how one resource manages or controls the communication session. The application logic can be internally configured in one or more resources, but may alternatively be externally hosted (such as at a URI of an application server) …” – para. [0023]; “… Step S110 … A communication session is controlled by at least one application module … The incoming application request is preferably directed to an application assigned to a phone number … The application is preferably composed of at least one module. The at least one module is preferably configured to direct application control to at least one other module. The second module that the first module directs application control to may be determined through the application logic of the module … More preferably, the application is preconfigured to include a plurality of modules that have a configured flow as shown in FIG. 2 …” – para. [0025]); and
accessing the set of communication instructions based on the resource identifier associated with the incoming communication request (Lawson, FIG. 1; “… A communication session starts by invoking an application module. A module preferably represents an operational mode. The module preferably includes at least one routine of application logic that dictates how one resource manages or controls the communication session. The application logic can be internally configured in one or more resources, but may alternatively be externally hosted (such as at a URI of an application server) …” – para. [0023]).
For Claim 11, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above. Additionally, Lawson-Lawson2-Lawson3 teaches a cloud-based communication platform comprising: one or more computer processors; and one or more non-transitory computer-readable mediums storing instructions that, when executed by the one or more computer processors, cause the cloud-based communication platform to perform operations (Lawson, “… 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 …” – para. [0067]).
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 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, the claim is substantially similar to claim 9 and therefore is rejected for the same reasoning set forth above.
For Claim 20, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above. Additionally, Lawson-Lawson2-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, “… 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 …” – para. [0067]).
Claim Rejections - 35 USC § 103
Claims 2-3 and 12-13 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 20160225044 A1, published 08/04/2016; hereinafter Lawson2), 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 2, Lawson-Lawson2-Lawson3 teaches the method of claim 1. Lawson-Lawson2-Lawson3 does not explicitly teach, but Nakai teaches further comprising: accessing, from an extension repository (Nakai, FIG. 6, para. [0022] call-control-data management table), a set of code that corresponds to the extension identifier, the extension repository being used to store the set of code received from a computing device that is external to the cloud-based communication platform (Nakai, FIGS 2, 3A-B, 6 and 9; " ... 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. [0022]; “… 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 …” – para. [0027]).
Nakai and Lawson-Lawson2-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-Lawson2-Lawson3 to easily realize resource extension utilizing a cloud (Nakai, para. [0027]).
For Claim 3, Lawson-Lawson2-Lawson3-Nakai teaches the method of claim 2, further comprising: generating a request based on a resource identifier included in the set of code (Lawson disclose passing application control to the second module based on its specified URI – para. [0026], [0027]), the resource identifier identifying a network location that is external to the cloud-based communication platform (Lawson discloses that the second module may be externally hosted – para. [0023]), the request being embedded with state data associated with the communication session (Lawson discloses passing application control with a communication session data – para. [0027]); and transmitting the request to the network location (Lawson discloses passing application control to the second module; FIG. 1; “… A communication session starts by invoking an application module. A module preferably represents an operational mode. The module preferably includes at least one routine of application logic that dictates how one resource manages or controls the communication session. The application logic can be internally configured in one or more resources, but may alternatively be externally hosted ( such as at a URI of an application server) …” – para. [0023]; “… Step S120 … Modules preferably have a specified initial URI (i.e., a module inlet). The URI may be a resource indicator for Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP) or any suitable communication protocol …” – para. [0026]; “… Step S130, which includes passing application control from the first module to a second module of the account through a linking system … Passing application control from the first module to a second module can include receiving a module identity code of the second module … The module identity code can direct communication control of the communication session/application to a different specified module. The passing of application control is preferably initiated through programmatic logic of the first module such as entering an operational state or some action. 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. For example, executing a dial command can trigger transitioning to a routing application module. Similarly, an action can be triggered by an API call directed at the communication session/application (as can be specified by a session identifier) … ” – para. [0027]).
For Claim 12, the claim is substantially similar to claim 2 and therefore is rejected for the same reasoning set forth above.
For Claim 13, the claim is substantially similar to claim 3 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 6 and 16 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 20160225044 A1, published 08/04/2016; hereinafter Lawson2), in view of Lawson et al. (US 20130072160 A1, published 03/21/2013; hereinafter Lawson3), and in further view of Chatterjee (US 20170064075 A1, published 03/02/2017; hereinafter Chatterjee).
For Claim 6, Lawson-Lawson2-Lawson3 teaches the method of claim 1. Lawson-Lawson2-Lawson3 does not explicitly teach, but Chatterjee teaches further comprising: initiating a media stream (Chatterjee discloses a communication session with the media recorder – para. [0025]) in relation to the communication session (Chatterjee discloses a communication session between the communication devices – para. [0019]), the media stream providing at least a portion of media transmitted during the communication session to a network location (Chatterjee disclose the location of the media recorder – para. [0013]) that is external to the cloud-based communication platform (Chatterjee, FIG. 1; FIG. 2; “… The media recorders 121A-121N may be located at different locations on the network 110B or in a common media server …” – para. [0013]; “… The processes of FIGS. 2-3 are described based on the establishment of a communication session between the communication devices 101A and 101N …” – para. [0019]; “… The SBC 120 establishes a communication session with the media recorder 121A in steps 209A-209B … The SBC 120 forks the media stream and sends the media steam to the media recorder 121A in step 210 …” – para. [0025]).
Chatterjee and Lawson-Lawson2-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 media stream forking techniques of Chatterjee with the system of Lawson-Lawson2-Lawson3 to enable a contact center or a corporation to record the communication with users (Chatterjee, para. [0020]).
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. Castro et al. (US 20160191675 A1) discloses that a communication application server is provided with a unified framework for call control and media control. The framework supports a unified API having class objects and functions conforming to a telephony object model. The class objects are invoked and manipulated by a finite set of commands and an application program essentially issues a series of such commands to operate the communication application server. More particularly, an API server on the communication application server defining a messaging API protocol enables an application script to pass commands remotely to the communication application server to operate it. This allows application scripts to be processed remotely by appropriate scripting engines. In this way, application scripting is decoupled from the operation of the communication application server, which only needs to focus on providing basic communication services (Castro, Abstract).
ii. Drose et al. (US 9083770 B1) discloses integrating real time communication (RTC) features into software applications ("the technology"). Various embodiments of the technology provide an 20 RTC tool that allows users, e.g., application developers to integrate RTC features into software applications. The RTC features support streaming of content including audio, video, and screen sharing. In some embodiments, the RTC tool is generated using Web Real-Time Communication (WebRTC) application programming interfaces (APIs) (Drose, col. 2, ll. 17-34).
Conclusion
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