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 05/12/2026. Claims 1-20 are pending in this application.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 01/06/2026 and 06/17/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 Arguments
Applicant’s arguments filed 05/12/2026 have been fully considered but they are not persuasive. Applicant argues:
a.
Applicant states that “Lawson discusses providing different levels of communication functionalities based on the customization of modules … 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. (See paragraphs 0021- 0027) … Lawson … nor does it describe the platform executing retrieved code to generate a voice extension instance (Reply, pp. 12-13).”
a.
In the 01/12/2016 Office Action, the communication functionality provided by the second module in Lawson was mapped to “a voice extension session/instance” based on the instant specification’s disclosure “A voice extension is a piece of software that may be implemented into the communication services provided by the cloud-based communication platform (para. 0005]).” When the application control was passed from the first module to the second module, the second module could be dynamically activated/invoked to provide the desired communication functionality (Lawson, para. [0021] – para. [0027]). Therefore, Lawson teaches executing the application logic of the second module to provide the communication functionality of the voice extension.
b.
Applicant also states that “Lawson3 's platform does not receive a set of code from an external computing device and store that code in a platform-maintained extension repository (Reply, pp. 11-12).”
b.
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 Lawson3 fails to provide for the amended language, where the rejection below now relies on Srivastava to teach this subject matter. See the 35 USC 103 section for details.
Response to Amendment
The claim objections to claims 1, 11 and 20 are now withdrawn in view of the claim amendments
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-5, 7-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20140064467 A1 (hereinafter Lawson), in view of US 20160225044 A1 (hereinafter Lawson2), and in further view of US 20190325058 A1 (hereinafter Srivastava).
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 teaches communication functionalities provided by a first module – para. [0021]) and a voice extension session (Lawson teaches 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 teaches 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 teaches “… 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 teaches 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 teaches 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 teaches 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, …, the determining comprising identifying the extension identifier from a command in the set of communication instructions (Lawson teaches 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, functionality of the communication session being kept active during the voice extension session (Lawson teaches 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]), the initiating comprising: …; and
executing the set of code by the cloud-based communication platform to generate a voice extension instance that provides the first communication feature (Lawson teaches executing the application logic of the second module to provide different specified communication functionality; 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]; “… a communication application is preferably defined by a communication session with a unique communication session identifier. A communication session or instance of application control is preferably defined for a voice call, a video chat session, a text a screen sharing session, a bidirectional text or media messaging session, synchronous communication, and/or any suitable session of bidirectional communication between at least one endpoint and the telephony platform …” - para. [0026]; “… 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 teaches 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 Srivastava teaches the voice extension comprising a set of code that was received from a computing device (e.g. a computing device of a developer in Srivastava which is external to the cloud-based software platform) external to the cloud-based communication platform and stored in an extension repository maintained by the cloud-based communication platform (Srivastava teaches the developer adding extensions in an extension repository maintained by the cloud-based software platform; FIGS 1-3; “… For example, as shown in FIG. 1, a computing environment 100 can include base software 110. The base software 110 can be a platform or suite of software applications …” – para. [0024]; “… FIG. 2 illustrates a multitenant environment 200, such a cloud environment, having a shared container 208, a first tenant container 212, and a second tenant container 216. The shared container 208 can include a base software application 222 …” – para. [0027]; “… The shared container 308 can include a base application repository 318 and an extension repository 326 … Typically, the base application repository 318 includes applications 320 having more general functionality that is useable by multiple tenants …” – para. [0038]; “… The extension repository 326 can include code for one or more extensions 328 to one or more applications 320 in the base application repository 318. Typically, extensions 328 provided enhanced functionality for an application 320, such as providing additional methods that can be called by an application, but can optionally provide more extensive functionality …” – para. [0039]; “… the shared container 308 can incorporate access and permission features such that only a developer or other authorized entity can add, delete, or modify extensions 328 in the extension repository 326. For example, each developer may be provided with access credentials, and optionally access permissions or a particular namespace in the extension repository 326 or other components of the shared container 308, such that their extensions 328 are protected from access by developers of other extensions stored in the extension repository …” – para. [0041]) and
accessing the set of code from the extension repository using the extension identifier (Srivastava teaches accessing software object/code corresponding to the extension from the extension repository using the extension identifier and accessing information; FIG. 3; para. [0052] “… a particular function of a base application 320 may be registered with an extension 328. For such a function, the configuration settings 362 can include an extension identifier 366, such as a name or numeric or alphanumeric identifier, corresponding to an extension 328 and access information 370 for accessing the extension. The access information 370 can be a file path or URI for the shared container 308, such as to access an object (or package, or other component associated with an extension 328) in the extension repository 326 …”).
Srivastava and Lawson-Lawson2 are analogous art because they are both related to computing systems.
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 saving developer provided software extensions in an extension repository techniques of Srivastava with the system of Lawson-Lawson2 to provide customized functionalities to the tenants and save the cost of recreating the same functionalities in different environments (Srivastava, para. [0032]).
For Claim 2, Lawson-Lawson2-Srivastava teaches the method of claim 1, further comprising: accessing, from the extension repository, the set of code that corresponds to the extension identifier (Srivastava teaches accessing software object/code corresponding to the extension from the extension repository using the extension identifier and accessing information; FIG. 3; para. [0052] “… a particular function of a base application 320 may be registered with an extension 328. For such a function, the configuration settings 362 can include an extension identifier 366, such as a name or numeric or alphanumeric identifier, corresponding to an extension 328 and access information 370 for accessing the extension. The access information 370 can be a file path or URI for the shared container 308, such as to access an object (or package, or other component associated with an extension 328) in the extension repository 326 …”),
the extension repository being used to store the set of code received from the computing device (e.g. a computing device of a developer in Srivastava which is external to the cloud-based software platform) that is external to the cloud-based communication platform (Srivastava teaches the developer adding extensions in the extension repository maintained by the cloud-based software platform; FIGS 1-3; “… For example, as shown in FIG. 1, a computing environment 100 can include base software 110. The base software 110 can be a platform or suite of software applications …” – para. [0024]; “… FIG. 2 illustrates a multitenant environment 200, such a cloud environment, having a shared container 208, a first tenant container 212, and a second tenant container 216. The shared container 208 can include a base software application 222 …” – para. [0027]; “… The shared container 308 can include a base application repository 318 and an extension repository 326 … Typically, the base application repository 318 includes applications 320 having more general functionality that is useable by multiple tenants …” – para. [0038]; “… The extension repository 326 can include code for one or more extensions 328 to one or more applications 320 in the base application repository 318. Typically, extensions 328 provided enhanced functionality for an application 320, such as providing additional methods that can be called by an application, but can optionally provide more extensive functionality …” – para. [0039]; “… the shared container 308 can incorporate access and permission features such that only a developer or other authorized entity can add, delete, or modify extensions 328 in the extension repository 326. For example, each developer may be provided with access credentials, and optionally access permissions or a particular namespace in the extension repository 326 or other components of the shared container 308, such that their extensions 328 are protected from access by developers of other extensions stored in the extension repository …” – para. [0041]).
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 saving developer provided software extensions in an extension repository techniques of Srivastava with the system of Lawson-Lawson2 to provide customized functionalities to the tenants and save the cost of recreating the same functionalities in different environments (Srivastava, para. [0032]).
For Claim 3, Lawson-Lawson2-Srivastava teaches the method of claim 2, further comprising: generating a request based on a resource identifier included in the set of code (Lawson teaches 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 teaches that the second module may be externally hosted – para. [0023]), the request being embedded with state data associated with the communication session (Lawson teaches passing application control with a communication session data – para. [0027]); and transmitting the request to the network location (Lawson teaches 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 4, Lawson-Lawson2-Srivastava 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 the voice extension instance of the voice extension (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; “… 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 teaches 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 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; “… FIGS. 20C and 20D, the communication mode may switch multiple times …” – para. [0062]).
For Claim 5, Lawson-Lawson2-Srivastava teaches the method of claim 4, wherein the voice extension instance communicates with an external network location to provide the first communication feature (Lawson teaches 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-Srivastava 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-Srivastava 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 teaches 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-Srivastava 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-Srivastava 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-Srivastava 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 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.
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-Srivastava 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 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over US 20140064467 A1 (hereinafter Lawson), in view of US 20160225044 A1 (hereinafter Lawson2), in view of US 20190325058 A1 (hereinafter Srivastava), and in further view of US 20170064075 A1 (hereinafter Chatterjee).
For Claim 6, Lawson-Lawson2-Srivastava teaches the method of claim 1. Lawson-Lawson2-Srivastava does not explicitly teach, but Chatterjee teaches further comprising: initiating a media stream (Chatterjee teaches a communication session with the media recorder – para. [0025]) in relation to the communication session (Chatterjee teaches 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 teaches 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-Srivastava 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-Srivastava 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. US 20110126168 A1 (hereinafter Ilyayev) teaches that a cloud platform for managing Software as a Service (SaaS) resources is provided herein. 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. US 20070106934 A1 (hereinafter Muschett) teaches a method for extending supported voice markup. The method can include a step of identifying a reference implementation (RI) for a software component that interprets voice-based markup. The RI can define a manner that the software component interprets voice-based markup. At least one plug-in can be identified that contains an extension to the RI. At runtime. the RI can he dynamically modified in accordance with the at least one plug-in. The software component can interpret voice-based markup documents based upon the modified reference implementation (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