System and method for processing telephony sessions

System and method for processing telephone conversation

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application requires the benefits of the following patent applications: a U.S. provisional application filed on April 2, 2008 under the title "System and Method for Processing Telephony Sessions, No. 61/041, 829; May 2008 The U.S. provisional application filed on the 22nd under the name System and Method for Processing SMS Messages with the application number 61/055,417, and the application number filed on September 26, 2008 under the name System and Method for Processing Telephony Sessions is 61/100 , 578 U.S. provisional application, filed on March 2, 2009, application number 61/156, 746 , U.S. provisional application named "System and Method for Processing Telephony Sessions, and filed on March 2, 2009 The application number is 61/156, 751 The United States provisional application named System and Method for Processing Telephony Sessions, the entire contents of all the above applications are incorporated herein by reference.

Technical field

[0003] The present invention relates generally to the telephony field, and more specifically to a new and useful system and method for handling telephone conversations in the telephony field.

[0004] Background

[0005] In the last ten years, the emergence and legislation of Voice over Internet (VOIP) has revolutionized the communications industry with new technologies, business models, and service providers. Software and commercial hardware now provide an alternative to expensive carrier equipment. People can implement scalable call conversion and voice application logic in open source software applications (such as Asterisk and FreeSwitch). However, the accumulation of these new applications has caused new complexity and challenges, requiring new technical teams to deploy, develop, and maintain. The deployment of telephony services requires knowledge of voice networks and codecs, hardware or services to connect servers and shared telephony infrastructure, and capital investment in hardware and the continuous configuration of this hardware. These burdens are only prerequisites for the development of practical applications, which require developers to train in new voices, tools and development environments. Even if the current attempt to adjust the model to a phone application that is more similar to network development such as Voice Extensible Markup Language (VoiceXML), it is necessary to devote efforts to learning new languages and understanding phone interactions. The continuous operation and maintenance of these services requires the team to adopt new analysis tools, performance standards, and debugging methods. Even the development of the simplest voice services (such as the so-called "phone tree") requires a large amount of upfront and continuous investment in specialized infrastructure, technology, and operations. Therefore, a new and useful system for handling telephone conversations is needed in the telephony field. The present invention provides such new and useful systems and methods.

[0006] Overview

[0007] The method for processing a preferred embodiment of a telephone conversation includes the steps of using an application layer protocol to communicate with an application server, using a call router to process telephone commands, and creating a call router resource that can be accessed through an application program interface (API). The method and system of the preferred embodiment enable network developers to use their existing technologies and tools in the mysterious world of telephones to develop telephone applications as easily as network programming. The method and system use the familiar website visitor model to interact with the web developer's application, where each step of a telephone call is similar to traditional page browsing. In this model, developers reuse their existing tools and technologies, including familiar concepts such as HTTP redirection, access to resources through API, cookie, and mime type responses to build complex phone applications. The methods of processing telephone commands and creating call router resources accessible through API (Call Router API) work together to take advantage of

CN 102027721 Β

Multiple call router resources and information provided by the call router (preferably a REST API familiar to many web developers) enable stateless and simple phone language. In one embodiment, the telephone command group may have less than ten verbs to simplify the language, so that developers can quickly learn and implement telephone applications, and at the same time call the router API to complete simple telephone commands to enable complex Phone application.

[0008] Brief description of the drawings

[0009] FIG. 1 is a flowchart representation of a preferred method of the present invention.

[0010] FIGS. 2A, 2B, 3A and 3B are schematic diagrams of preferred embodiments of the present invention.

[0011] FIGS. 4A-4C are examples of HTTP GET requests, HTTP POST requests, and HTTP GET requests, respectively.

[0012] FIGS. 4D-4F are examples of HTTP requests.

[0013] Figures 5A and 5B are examples of XML responses.

[0014] FIG. 6 is an example of a call router request and response.

[0015] FIGS. 7-15 are schematic diagrams of various applications including the principles of the preferred method of the present invention.

[0016] FIG. 16 is a flowchart representation of the sub-steps related to the digital marking portion of the preferred method of the present invention.

[0017] Description of the preferred embodiment

[0018] The following description of the preferred embodiments of the present invention is not meant to limit the present invention to these preferred embodiments, but is intended to enable any person skilled in the art to implement and use the present invention.

[0019] 1. Method for processing telephone conversation

[0020] As shown in FIGS. 1, 2A, 2B, 3A, and 3B, the method 10 of the preferred embodiment for processing a telephone conversation includes a step S110 of communicating with an application server using an application layer protocol, and processing a telephone call with a call router. Step S120 of the instruction and step S130 of creating a call router resource accessible through an application program interface (API). The preferred method may also include other steps and/or sub-steps explained below.

[0021] 1A. Communicate with the application server

[0022] As shown in FIG. 1, the step S110 of communicating with the application server using the application layer protocol preferably includes the following sub-steps: initiating a telephone session S1, mapping the call to a uniform resource identifier (URI) S3, sending a request to and The server S5 associated with the URI processes the request S7 corresponding to the state of the telephone conversation, and receives the response S9 from the server. One challenge of using the familiar website visitor pattern is that third-party web applications may expose URIs that contain sensitive data or URIs that imply actions that can maliciously manipulate the application database. In a preferred embodiment, the call router uses an account-designated key to cryptographically sign the request sent to the client's network application. More specifically, the step of communicating with the application server includes an additional step S4 of digitally signing the request parameter and an additional step S6 of verifying the digital signature of the request parameter S6. Only the call router and the application server know the key, so requests that include parameters (URL, POST data, headers, etc.) signed with the key can be checked for authenticity before allowing such operations. This method also provides authenticity verification for secure links (HTTP) with low CPU overhead.

[0023] It is stated that the step S1 of initiating a telephone conversation works to receive incoming messages. The message is preferably a call from a PSTN (Public Switched Telephone Network) connected device or Internet addressable device, such as a landline phone, cellular phone, satellite phone, Voice over Internet (VOIP), SIP device, Skype, Gtalk or any Other appropriate PSTN connected or Internet addressable voice devices. The message may optionally be a short message service (SMS) message. The SMS gateway server can optionally be connected to the SMS network through the Short Message Service Center ("SMS-C"), directly connected to the Signaling System 7 (SS7) telephone network, or by any other appropriate SMS gateway provider , And the message is preferably received from the gateway by the call router and converted into a format (such as URI) that can be sent via the public Internet, such as HTTP, based on

CN 102027721 Β

The receiving address of the SMS is, for example, a short code, or direct inward dialing (DID), or other appropriate unique receiving identifier. The message can optionally be a multimedia message, facsimile transmission, email, or any other suitable messaging medium. The initial phone number of the PSTN device is preferably captured using the caller ID, but any other appropriate ID can be captured, such as V0IP provider ID, SMS device number, email address, or short code. The dialed phone number, EIN and/or billing identifier, and/or the date and time of the call may also preferably be included in the session information. The authentication ID may be additionally or alternatively included in the session information.

[0024] In a variant form, step S1 also functions to initiate a telephone session (such as a telephone call) via HTTP or other requests sent from an application running on a third-party server to the call router. In this variation form, the application running on the server preferably specifies the initial URI for the call router to be used for the phone conversation in step S3, as well as the phone number (or other addressable destination) to be dialed and the source phone. Number (caller identity (id)). In this variation, the call router API is preferably used by the application server to request outgoing calls from the call router.

[0025] It is stated that step S3 of mapping a call to a uniform resource identifier (URI) works so that the telephone conversation can be converted into a format that can be processed by standard web servers and web applications. This mapping is preferably performed using a call router. The initial URI is preferably pre-specified by the network application (that can run on a third-party server) at the calling router or the calling router account owner. More preferably, the initial URI is assigned to the call through a unique identifier of the call target, such as a DID (Direct Inward Dialing) phone number or a VOIP SIP address. The URI can optionally be specified by a remote server or other appropriate device or method. In a variant form, the URI can be used to encapsulate the state information or part of the state information from the initiated phone session, such as the originating phone number, the phone number dialed, the date and time of the call, and the geographic location of the caller ( For example, the country, city, state, and/or zip code), and/or the unique call ID. The information included in the URI may be included in the form of a URI template. For example, the default URI template can be: http:// demo, twOrderIO. com/myaun/ {the dialed phone number} / {originating phone number} or httu://demo. twilio.com/myauD/foo.uhu? dialed number= {phone number dialed} &originating- number = {originating phone number}.

[0026] Step S4 functions to digitally sign the request parameters. As shown in FIG. 16, step S4 preferably determines the calling router account owner, and more preferably, searches for the unique ID or key of the account owner and signs a set of request parameters. Step S4 is preferably implemented by generating an encrypted hash of the request parameters, preferably including the URI and any request body parameters with a unique key associated with the call router account owner (for example, in the case of HTTP POST) under). The cryptographic hash is preferably generated by appending the request parameters to the initial set of request parameters. The hash is preferably appended to the URI, but if the hash is particularly long (ie, has a large number of parameters), the hash can be included in an HTTP header that has no limit on the size. In the variant form of step S4, at least one sensitive parameter can be individually encrypted using the key of the account owner before the hash is processed. In another variation, an encrypted credential authorization system such as Oauth (oauth.net) can optionally be used to electronically sign the request.

[0027] Step S5 functions to send a request to the server. Preferably, the request is sent to the URI, and more preferably, the request is sent to the URI mapped in step S3. The request preferably includes an encrypted hash calculated from the set of request parameters (acting as a digital signature), but if the parameters are determined to contain sensitive data, the request may optionally include a single encrypted request parameter. The server is preferably a third-party server, and more preferably, the server runs a network application. The request is preferably sent to the server via the network. In a variant, the request is sent to a local server on the local area network. In another variation, the request is sent to run locally on the device that originated the call

CN 102027721 Β

Server. In yet another variation, the request can be sent to multiple servers. The request is preferably encapsulated with at least a part of the status information from the initiated phone session, such as the originating phone number, the phone number dialed, the date and time of the call, the geographic location of the caller (e.g., country, city, and/or Or state, zip code), and/or unique call ID. More preferably, the request encapsulates all the status information of the call, but it may preferably not include the status information or include part of the status information. The state information from the initiated phone session preferably passes through HTTP POST in the request body, HTTP GET in the request URI. The HTTP header parameters are sent to simulate the data flow of a web browser, or sent by any combination or suitable optional methods. If new status information is generated during the operation of the call router, it is preferable to make a request to the application server to transfer the new status and request a new telephone command. Preferably, the new state information is not maintained by the call router or has an internal effect on it, but is transmitted to the application server for processing. Optionally, part of the state information is preferably stored on the call router until a comprehensive updated state is obtained, and then transmitted to the application server. For example, before the new call status is obtained and transmitted to the application server, the application server can specify multiple digits that should be pressed on the keyboard instead of just one. In a variation, the information from the initiated telephone session may be a web form submission included in the HTTP POST request. The request can include any status information from the phone conversation, such as the originating phone number, the phone number dialed, the date and time of the call, and/or the unique call ID, the current status of the phone call (waiting, in progress, already Completion, etc.), or the result of telephone behavior (including dual-tone multi-frequency (DTMF) digital processing), or recording representation or recording link, or the status of the previous command, or other call status. HTTP GET request, HTTP POST request and HTTP Examples of GET requests are shown in Figures 4A, 4B, and 4C, respectively. Further examples of HTTP communication for SMS message transmission are shown in Figures 4D, 4E and 4F. The HTTP request (or any appropriate request communication) to the server preferably follows the principles of RESTful design. In this document, RESTful is understood to describe the representational state transition structure as known in the art. The RESTful HTTP request is preferably stateless, so each message sent from the call router to the application server preferably contains all the information required for the operation of the application server and the response generation of the application server. The call router and/or the application server preferably do not need to remember or store previous communications to learn the status. Documents, media, and application status are preferably browsed as addressable resources, combined with data provided to the resource through request parameters such as HTTP GET or HTTP POST parameters or the content of the request body. Such request data may include an updated representation of the call resource, or other call status data generated as a result of the operation of the call router, such as a number pressed on a keyboard or a generated recording. The status information included in each request may include a unique call identifier, call status data such as whether the call is in progress or completed, the caller ID of the caller, the phone number being called, geographic data about the caller, and /Or any appropriate data. However, varying levels of RESTful communication (stateless) can be used, such as through the use of cookies, session tracking, or any appropriate device to mimic the normal website visitor model. Preferably, the data sent with each request completely enables the application server to determine the next state of the call to be executed. RESTfulness preferably does not exclude the use of external data sources, such as databases, to query additional data to record call metadata, or to determine application logic.

[0028] Step S6 functions to verify the digital signature of the request parameter. As shown in Figure 13, after the service receives the request, the request parameters are preferably checked and/or parsed for hashing. The encrypted hash is preferably included in the URI of the HTTP request, but can optionally be included in the HTTP header of the request. If the request does not include a hash, and the web application server uses the hash function check to be enabled as a security measure, the request is preferably determined to be false, which may include a malicious request, an incorrect routing request, and a corrupted request. Request and any other requests not needed by the application server. If the set of request parameters includes a hash, the hash is preferably extracted from the request, and the key of the customer network application (ie, the key stored on the call router that is the same as the customer account key) is preferably used Generate the service of the received parameters

CN 102027721 Β

Encrypted hash on the server side. The server-side encrypted hash is preferably compared with the hash included in the request, and if the hash does not match, the request is preferably determined to be false. However, if the server-side encrypted hash matches the request hash, the request is preferably determined to be genuine and ready for further processing on the application server. In the modified form of step S4 mentioned above, where the sensitive parameters can be encrypted using a key, step S6 preferably includes decrypting the sensitive parameters. The application server and the third party operating the application are preferably responsible for completing this verification step, but the verification can optionally be done by a single party, for example, when a single party operates the application server and the call router. If the request for authentication is not important to the application, the application server can optionally be set to ignore the hash included in the request parameter.

[0029] It is stated that step S7 of processing the request corresponding to the telephone conversation functions to perform processing of at least a part of the data included in the request. The processing function is preferably performed on a third-party server. Processing functions may include recording the data included in the request and/or metadata related to the call session, routing to another URI, performing a database query of at least part of the data included in the request, voice recognition processing, or any other Appropriate processing functions. The processing function can reuse logic and data from other business applications, such as customer databases and/or shopping cart applications, which can be linked using caller id or information provided by the caller. The status information is preferably communicated with every request from the call router, and preferably, the application server does not require application status. Optionally, the application server can store the state between each request related to the call by using HTTP cookies, session and/or database records. In some cases, such as static HTML pages running on the server or stored media files such as mp3 or wav files stored on the server, step S7 can be simplified, and the file mapped to the disk through the URI can be Simply return.

[0030] Step S9 states the response from the server. This response is preferably an HTTP response. The response is preferably sent as XML, audio binary, or raw text, but can optionally be in any kind of messaging format, including HTML, bounded text, key/value text, or binary encoding format. The HTTP response preferably includes an instruction to perform a phone operation. The response may optionally or additionally include a new URI and a new URI template for use with the phone operation in step S3. Additional exemplary XML responses are shown in Figures 5A and 5B.

[0031] 1B. Handling phone instructions

[0032] The step S120 of processing the phone instruction with the call router preferably functions to convert the server response into a phone operation or an operation that can be performed during a phone conversation. Phone operations can include, for example, playing a pre-recorded sound file and using text-to-speech technology to play a pre-recorded sound file at the URI specified by the server (for example, the static mu3 file at httu: //demo. tw subscription io. com/myauu/1234. mu3) The caller reads text, calls another number (for example, creates a new voice connection through PSTN, SIP, /VOIP or other IP technology systems), collects numbers through DTMF input, records voice response audio, TTY or other data, and sends SMS Messages, or any suitable combination or sequence of these or other suitable operations. This conversion of the server response is preferably performed on the call router. Preferably, step S120 includes processing the response mime-type associated with the server response. For example, if the response mime-type is XML, it is regarded as a set of call router instructions. If the response mime-type is MP3, it is considered to be a sound file played for the caller. If the response type is plain text, it is considered to be the text read to the caller through text-to-speech technology.

[0033] The content of the server response, such as an XML document, is preferably converted into a telephone operation by processing the document sequentially (for example, line by line). The telephone instructions are preferably included in the document in the form of a markup language such as XML as shown in FIGS. 5A and 5B. This continuous way of processing the document of telephone commands is effective when the communication is stateless and all necessary information is contained in the URI. This stateless communication preferably allows telephony instructions (verbs or commands) to be used as a programming interface for the server application to perform telephony services. Algorithm conversion (based on communication status) of telephone verbs or documents is preferably unnecessary. Preferably, it is executed in the order of the phone instructions contained in the content of the server response

CN 102027721 Β

Telephone operation. For example, the XML document may include the necessary verbs to read the text for the caller, monitor the keys pressed by the caller, and use the pressed keys as part of the data of the new URI to redirect the caller to the new URI phone operation. Preferably, telephone operations (for example, pressed numbers) generate new status information, which may lead to repetition of some steps of the method, preferably starting from step S3. The next URI is preferably provided by the server as part of the processing instruction. In another variation, if the server fails to specify the next URI, the previous URI is reused. In yet another variation, if the server fails to specify the next URI, no repetition occurs, and the process proceeds to the next call text router instruction. The behavior can be determined by the nature of the call router command; for example, commands that do not generate new status information may not need a next URI because they do not trigger communication with the remote server. More preferably, the telephone operation causes step S3 to be repeated with the new URI obtained from step S11, but the repetition of one or more steps (steps S5, S7, S9 or S11) of the method can optionally be initiated. Step S3 preferably uses all new telephone conversation state information generated by the execution of the telephone operation, such as pressed numbers, recorded audio files, or any telephones requested. The success or failure information of the operation is repeated. Repetition also includes maintaining all relevant state information during the session, such as caller, callee, unique call ID, and call status. The status information can also be expressed in the form of a URI template. For example, if the server responds to the designated calling router to collect DTMF data, and designates that the next URL is the URI template http://demo, twsubscribe io. com/foo. uhu? Dixits= {Digits}, and the caller presses 1234, get The URI is httu:// demo, twilio. com/foo. uhu? Dibits = 1234. Similarly, if the server responds to the specified URI template: httu://demo, twsetio. com/myauu/ {Dixits}. mp3, the HTTP request obtained to [| may be located at: http:// demo, twsetio . com/myanu/1234. The static mp3 file of mu3. Therefore, the call can be controlled by the server issuing the telephone command and the second server processing the response, as shown in Figures 13 and 14. Such call control transfer constitutes the conversion of state information between servers in the form of URI and accompanying request data such as GET, POST and/or request body. Optionally, all state communications follow the syntax established by the call router to facilitate integration between multiple servers. For example, the numbers pressed on the keyboard are preferably transmitted to the application server in the same form, thus minimizing the need for collaboration between multiple application servers on how to transition the state. Optionally, the call router instruction may specify a method of delivering new state information, such as the name and type of the variable, to send a representative new state.

[0034] 1C. Create a resource accessible by the call router API

[0035] The step S130 of creating a call router resource accessible through an application program interface (API) preferably works to expose information and/or functions of the call router. Interactions from external parties are preferably performed through API (Call Router API). The call router API may additionally cooperate with the use of telephone commands to function as a storage and retrieval format for data generated or required by the operation of the call router. The call router API is preferably an application program interface (API), such as a REST API (representational state transfer) known in the art, but the call router API may alternatively be a SOAP (Simple Object Access Protocol) API or any suitable Programmatic communication interface. The call router API can preferably be used asynchronously by the application to perform calls (in order to query call records or retrieve records later). Optionally, the call router API can be used synchronously during the call (for example, change the call state, hang up the call, start the call record, etc.). The call router API preferably stores the state information in the persistent URI of the resource. The persistent URI preferably contains all necessary state information, and this preferably makes the data stable, queryable and recoverable. The call router API is preferably used to modify resources to change the state of the call router and for media interaction with the call router. Application server can Use the call router API to preferably query call records metadata, caller identity, call media (such as records, text copies, etc.), account information, transfers in the call router or interaction with ongoing communications, and/or Operate any appropriate data generated or required by the calling router. Call router API preferably involves application server and call

CN 102027721 Β

Communication between routers, but can optionally be communication from any suitable device to the calling router. The call router API preferably exists on the same hardware as the call router, but can also optionally exist in remote hardware or any suitable hardware environment. The communication is preferably HTTP, but optionally HTTPS or any suitable communication protocol may be used. In addition, the call router API is also compatible with any HTTP client. The telephone system of the preferred embodiment preferably implements a call router API including a call router API request format, a call router API response format, and a plurality of API resources representing the types of data generated or used by the call router.

[0036] The call router API request of the preferred embodiment functions as a communication message of the API resource sent from the application server to the call router. The call router API request is preferably sent from the application server to the call router, but can also be sent to the call router from any suitable device. The call router API request is preferably similar to the REST API request, but the call router API request can optionally follow any appropriate programming, such as SOAP. The call router API request preferably uses HTTP to interact with resources, but HTTP or any Appropriate communication protocol. Preferably, the HTTP or HTTPS method of GET is used to retrieve resources or resource information, and the HTTP or HTTPS method of PUT or POST is used to create or update resources. In some cases, PUT or POST can be used to affect the function of the call router by modifying the state of the resource. Optionally, method parameters may be included in the URI of the resource to identify the requested operation on the resource, or any appropriate command or method may also be used to interact with the API resource. Preferably, the call router API request includes authentication such as basic HTTP or HTTPS authentication by including message authentication information in the URI, such as an encrypted hash of the request content using a common key, or by any appropriate method.

[0037] The call router API response of the preferred embodiment functions as communication information sent in response to a method executed on the API resource. The call router API response is preferably sent from the call router to the application server or any suitable device. The call router API response is preferably sent in response to the call router API request, and the response is preferably sent to the originating device. The call router API response is preferably similar to the REST API response, the response representing the requested resource. The call router API response can optionally follow any suitable programming such as SOAP. The call router API response is preferably returned as formatted XML with information corresponding to the HTTP status code, message, error code, and/or any appropriate information related to the resource. The call router API response can optionally be expressed as a comma-separated list of values (CSV), HTML, JSON, or any suitable form. In a variant, the response format is determined by a part of the requested URI, such as a file extension. In a variant, the API resource may be a binary data resource, and the call router API response is preferably formatted in native binary format (for example, wav or mp3 audio file), XML metadata description and/or any suitable format .

[0038] The API resource of the preferred embodiment functions as an addressable representation of call router metadata, internal call router status, or the status of a given resource used by the call router. Preferably, API resources are addressed by persistent URIs. Preferably, the API resource responds to at least one HTTP operation of POST, PUT, GET, or DELETE. API resources can optionally respond to multiple HTTP operations. The API resource may optionally respond to any suitable method that is preferably included in the call router API request. Consistent with RESTful conventions, a GET request for a resource can return the current state of the resource, while PUT can update the state, PUT or POST can be used to create a new resource, and DELETE can be used to destroy a resource. In addition to modifying data, the call router API can optionally be used to affect the function of an ongoing call. The API resources of the preferred embodiment include account resources, caller ID resources, incoming address resources, call resources, media resources, and/or any appropriate resources of the call router. The API resource can optionally be any suitable combination of the listed resources or other suitable resources. The API resource is preferably a pre-configured (or "static") resource, such as account information, or an active resource used by the call router, such as a phone call. Modifying the resource status through the API can also affect the call in real time.

CN 102027721 Β

The operation of the calling router affects the future call status or capabilities of the calling router, and/or has any appropriate influence. [0039] The account resource of the preferred embodiment functions to allow the application to retrieve and/or modify the account information. The account is preferably created by the telephony server provider, such as the operator of the call router. For example, the account name, usage information, contact information, initial URI, setting parameter information, or any appropriate account information can be retrieved or edited by the application using account resources.

[0040] The caller ID resource of the preferred embodiment functions to allow the application to retrieve, modify, and register a new caller ID (telephone number), and/or delete caller identity information. Preferably, the caller identity information is for a phone number related to an outgoing call made by the application and/or user (ie, displayed as the application making the call). The number for outgoing calls is preferably assigned and verified before being used as the caller ID. As an optional way, in order to prevent the caller ID phone number in the application from being fraudulently used, the API can use the verification step before adding a new caller ID resource. The request to increase the caller ID can be initiated to the API through the request, where a random check code is generated and returned in the API response. The check code is preferably provided to the end user. Make a phone call to the given phone number (caller ID) to request the keypad number or verbal input of the check code. Upon request, the entry of the verification code verifies the ownership of the phone number or the device associated with the phone number. The use of the caller ID resource can also be presented on a user interface such as a web browser by displaying a check code. The user interface can be provided by the operator of the call router, or can be provided by any appropriate application using the API. Any appropriate method can be used for the verification of the caller ID. In another alternative where the call involves multiple parties, another outgoing call can be assigned to a call from an existing party member during that call session IDo

[0041] The incoming address resource of the preferred embodiment functions to allow the application to obtain, modify or provide a new inbound DID phone number, SMS short code, SIP address, etc. for use in the application. PUT or POST can be used to set the initial URI associated with the inbound address. DELETE can be used to release resources. The incoming address resource can be used for real-time provision of telephone numbers or other addressable inbound identifiers.

[0042] The call resource of the preferred embodiment functions to allow the application to obtain or modify the state of the telephone session in the call router. The telephone conversation or call may be in progress, completed, failed, not started, and/or in any suitable call state. The call resource preferably can change the status or connection of an ongoing call. The status change preferably includes: hanging up or terminating an existing telephone conversation, transferring one or more existing telephone conversations from one environment group of the conversation to another, merging or splitting existing group telephone conversations, and transferring one or more existing telephone conversations. Transfer of multiple telephone conversations from one communication medium to another (for example, transfer from one URI to a second URI), introduce events or notifications into an existing conversation or group of conversations, record or stop recording from one or more parties to the call Audio, and/or any appropriate call operation. The call information or call log data can preferably be retrieved by sending a GET to the call resource or alternatively by sending any appropriate method. Outgoing calls can also be initiated by using POST or any suitable method that preferably indicates that a new call resource is created. When calling resources are used to initiate a call, information can be provided as needed to make a phone call, such as the caller ID to be presented, the phone number to be called, and/or the URI used to process the call, but optionally Any appropriate information can be provided. Alternatively, the call instruction XML document may be provided to the API instead of the URI, which is used for the call instruction. For example when When the call is answered, when the machine answers the phone, busy signal, no answer, call failed, and/or in any appropriate call state, the call router API can also respond with the call state in addition. Optionally, the response may indicate that the new call request has been accepted but has not yet been initiated. In the example shown in FIG. 6, caller information and caller ID are included in the POST request to the call resource. This step may initiate an outbound call to the phone number specified in the call information. The call router API response includes valid status information related to the call, such as whether the call has started, the call start time, and the end

CN 102027721 Β

Bundle time, price, caller information, and optionally, the call router API response may include any appropriate information. In addition, the call-related information returned by the API at any point in time may depend on the status of the call. For example, if the call has not yet started, the call start time may not be given, and if the call has not ended, the call end time, duration, or price may not be given.

[0043] Additionally or alternatively, the call resource of the preferred embodiment can be used to receive POST, PUT and/or any appropriate method through a single call resource to transfer the call to a new URI. In this optional way, The call is optionally transferred to a new URI for the new call instruction. Preferably, the API can be used to cause an asynchronous change of the call state, which is different from the synchronous communication between the call router and the application server for synchronizing URI requests and responses. In this alternative, the call resource functions to allow calls to be directed to multiple URIs asynchronously. Examples of various applications of call resources include starting a new telephone session, terminating an existing telephone session, call waiting, call holding, call queuing, call park, dedicated call sessions within a conference, the progress of multiple call sessions, And/or any appropriate application. Any situation in which an asynchronous event affects the state of a call, such as the call agent becomes active, or someone answers the call after placing the caller on hold. Before requesting the provided URI, the currently executing call router command can be allowed to complete or can be terminated immediately. The new call status obtained from the last call command executed by the call router, such as the number pressed on the keyboard or the recorded audio from the caller, can be provided to the new URI in the form of POST or GET parameters, or It can optionally be discarded by the calling router and not provided. As shown in Figure 15, call waiting can be routed through the call sent by the application The API request is implemented by POSTing a new URI to the call resource for the call. The caller is then directed to the new URI of the instruction. The second call router API request is sent to the call resource that originated the URI for the call POST, and thus returns the caller to the first call session. Call resources can optionally be used in any suitable application.

[0044] As an optional implementation of the call resource, the call resource can implement multiple independent calls as different sub-resources. For example, a URI ending in "/Calls" can be a series of multiple calls performed by an account, and a URI ending in "/Calls/12345" can represent a specific call uniquely identified by the key "12345". Call resources preferably allow to retrieve many call records and/or create new calls, while a single call resource represents a single call. The call resource preferably accepts a request to create a new call resource, as is common in a RESTful structure, which is in the call router API and is preferably used to initiate one or more new calls. Call resources can be used to list current and previous calls using the GET method, and to initiate new outgoing calls using the POST method. Using RESTful principles such as POST or PUT to change the status of an independent call resource can optionally be changed, such as by hanging up, transferring control to a new URI, joining the call with another call, or in any appropriate way of telephone operations. The status of the call in progress and the real-time operation that affects the call.

[0045] The media resource of the preferred embodiment functions to allow the application to retrieve and/or access the information of the media stored, retrieved, created, and/or used during the call. In a variant, the media resource is preferably a recording resource to access information and records made during a call by recording call instructions or asynchronously by calling the router API. In another variation, the media resources may optionally include call copies, text messages, keypress logs, faxes, binary code resources, and/or any appropriate media. The media resource may optionally include the URI of a binary code file (for example, wav, mp3 audio file or PDF document file). In a variant form, the media resource can also be combined with the telephone command (or markup language), so that the telephone command can instruct the calling router to perform the operation of creating the media resource. The call router preferably sends a response to the application server with the URI of the created media resource. For example, when the call router is instructed to record a message, the call router preferably sends a response to the application server with the unique URI of the message recorded in the API. The media URI preferably responds to a GET request to return media in multiple formats, such as binary or XML metadata representation. The media resource can accept a request to delete the media resource. In a form of change, media resources preferably require access to resources

CN 102027721 Β

Certification. In another variation, the media resource does not need to enable the URI to be embedded in the authentication of multiple applications, so the authentication credentials are not exposed. In yet another variation, authentication is preferably performed through encrypted hashing so that the credentials are not exposed to client applications that consume media resources. In another variation, media resources allow the use of transcription technology to initiate the transcription of audio resources into text. The audio resources used for transcription are preferably generated during the telephone conversation (for example, by recording instructions) and host the call router API. The media resource preferably allows retrieval or deletion of audio transcriptions generated by the recorded media. Media resources can also allow centralized control of media files, and resource URIs are preferably exchanged between the call router and the application server rather than between the large media files themselves. Media resources can optionally be used for any suitable media.

[0046] Additionally or alternatively, the splicing resource of the preferred embodiment can be used to splice one or more calls into a shared session, which allows multiple parties to receive POST.PUT through a single call resource and/or by any suitable method. Method to communicate (ie, conduct a meeting). In this alternative, preferably, one or more calls are joined together so that they are in one conference. The splicing resource can optionally be a part of a sub-resource or a call resource.

[0047] Additionally or alternatively, the split resource of the preferred embodiment can be used to receive POST, PUT through a single call resource and/or split a shared session (for example, conference) into Independent call session. In this alternative, one or more shared sessions involving two or more calls are preferably split so that one or more calls are split into multiple separate calls or into one or more separate calls. Separate meetings. Split resources can optionally be part of sub-resources or call resources.

[0048] 2. System for processing telephone conversation

[0049] As shown in FIGS. 2A, 2B, 3A, and 3B, the preferred embodiment systems 20 and 30 for processing telephone conversations include a call router 22, a URI 23 of an application server, a telephone command 27, and a call router resource 29. As shown in Figures 2A and 2B, the first setting 20 is initiated by a telephone device (such as a telephone call, fax, or SMS message). As shown in FIGS. 3A and 3B, the second setting 30 is initiated by the application developer side (ie, the server 26 calling out). The telephone system of the preferred embodiment preferably also implements the call router API 28, which includes a call router API request format, a call router API response format, and a plurality of resources substantially similar to those described above.

[0050] The call router 22 functions to initiate a call or receive a call from a telephone device and connect to a network application server. The call router 22 is preferably connected to PSTN equipment through the PSTN network, so that it can receive calls and make calls from PSTN-connected equipment 21 and non-PSTN equipment, such as fixed telephones, cellular phones, satellite phones, or any other Appropriate PSTN connected devices, non-PSTN devices such as Voice over Internet (VOIP) phones, SIP devices, Skype, Gtalk, or other Internet addressable voice devices. The call router 22 may alternatively or additionally function as a message router for SMS messages or include a message router for SMS messages. The call router 22 may preferably be connected to the SMS network so that it can receive and send messages from the SMS network device 21, a cellular phone, a computer, a smart phone, or any suitable SMS network device. The call router 22 can also send or receive text messages, multimedia messages, e-mails, faxes, and other appropriate PSTN-compatible communication messages. The call router 22 preferably uses an application layer protocol to communicate with the application server 26, and more preferably uses an HTTP protocol or a secure HTTPS protocol to communicate with the application server 26. The communication between the application server 26 and the call router 22 is preferably a stateless communication, and Any status information (such as call status) or data is preferably located in the URI or request parameters, such as HTTP headers, GET URI parameters, POST request body parameters, or HTTP cookies. Valid state information is preferably sent by the call router request to the application server for stateless processing, and the application server preferably does not store the state. Optionally, the application server preferably stores local state information common in network development, such as a database or a session. Call router 22 preferably

CN 102027721 Β

The Π/14 page stores state information in the call router resource 29. The call router resource 29 is preferably accessed by the application server 26 and other devices through the call router API 28. The call router resources 29 are preferably similar to those described above. The call router 22 preferably associates each incoming phone number with the start URI 23, more preferably, the URI 23 is provided by the application server 26, and more preferably, before the call router 22 receives the call, the URI 23 is provided by the application The developer provides it by associating the initial URI with the incoming call address (such as DID, SIP address, etc.), or it is provided by the application when an outgoing call is initiated. The call router 22 preferably sends call data such as caller number (obtained through caller ID), caller geographic data (country, city and/or state, zip code), dialed number, time of the call, or any other Appropriate information or parameters. The call data is preferably digitally signed with a key 25 stored on the call router 22. The cryptographic hash of the information is preferably included as a digital signature along with the information. The call router 22 can also use the key to encrypt sensitive information (before or after the encrypted hash is calculated) to allow the sensitive information to be sent over the network. The call data is preferably sent to the application server 26 as an HTTP POST request. Call data also It can be sent in the URL (GET) variable or encapsulated in the HTTP header. An exemplary HTTP request containing the information in the header is shown in FIGS. 4A and 4D. As shown in FIG. 4B, further input from the PSTN device (such as voice recording or pressing a DTMF button) may be successively submitted to the application server 26 as an HTTP request (GET or POST). As shown in Figure 4C, input from the phone keypad can be included in the HTTP GET request. As shown in FIG. 4E, the content of the SMS message received by the call router may be sent to the application server 26 as an HTTP request. As shown in Figure 4F, the input from the next message is included in the HTTP GET request. The request data can optionally be sent simultaneously in URL (query string), message body (POST) and message header or any combination of the above.

[0051] The application server 26 functions to provide data processing logic for requests received from the call router 22. The application server 26 is preferably connected to the call router 22 through the network 24, more preferably through the Internet. The application server 26 is preferably a third-party server operating outside the system, but the system may optionally include an application server 26. The URI 23 is preferably associated with the application server 26 or an application on the application server 26. The application server 26 preferably Use application layer protocol, more preferably HTTP protocol or more secure HTTP protocol to communicate with call router 22. Application server 26 preferably receives HTTP requests from call router 22 or sends HTTP requests to call router 22. Application server 26 is preferably at The programming language, master control provider, operating system, and database run on a standard stack to process HTTP requests as if the caller is a website visitor in a web browser. The application server 26 may preferably use a key to verify that the request is In the digital signature of the received call data, the encrypted hash is calculated from the received information and the received hash. If the calculated hash does not match the received hash, or the request is not received In the hash, the application server 26 preferably determines that the request is false, and preferably the request is discarded. If counted If the calculated hash matches the received hash, the application server 26 preferably determines that the request is genuine, and further processes the request. If security is not important, the application server can optionally choose to ignore the hash. The application server preferably uses the call status data requested by the call router to determine the next call router command, without the call status stored on the application server. The application server can optionally use the call status data sent by the call router, such as the caller ID of the caller or the unique ID of the call, to refer to additional or external status data, such as rows in the database or stored on the application server Session data. The application server 26 preferably responds to the HTTP request received from the call router 22 by generating a telephone command 27 for the call router 22. The application server preferably replies to the call router in XML, but any suitable machine-readable message format may also be used, including HTML, key/value pair text, delimited text, or binary encoding. The XML preferably includes telephone instructions 27 for the call router 22, such as connecting to another number, playing a recorded greeting, reading text, and/or requesting the caller's DTMF digital input. Electricity

CN 102027721 Β

The voice command 27 may optionally be related to SMS messaging, Multimedia Messaging Service (MMS) messaging, email, or any appropriate messaging task. Phone instructions 27 can also be used to send out SMS messages, arrange phone calls from specific phone numbers, schedule callbacks, establish conference calls (connect multiple numbers), send emails, interact with calendars or scheduling systems, shopping, Or services, or any other appropriate instructions. The XML instructions are preferably a set of commands that are executed one at a time in sequence (ie, executed sequentially). An exemplary XML response is shown in Figures 5A and 5B. In a single phone conversation (for example, a phone conversation initiated by a PSTN device or an SMS device), the response from the application server may initiate an outgoing phone call and/or SMS message. That is to say, a single XML response preferably provides the ability to interact with the SMS network and the voice telephone network (PSTN, SIP, VoIP, etc.) sequentially or simultaneously. In addition, the audio or video file sent to the call router 22 can be converted into text by an automatic speech-to-text engine, manual or other technology, and sent back as an SMS message or MMS attachment in the form of text. In a variant form, the application running on the server can be a simple static XML deployed on a static web server in an environment where there is no development or scripting available. Pages and static sound files. This change form preferably uses a URI template (HTML5 currently launched by IETF), which basically includes a URL with variable data placeholders, such as: httu://www. twilio. com/audio/{Dixit}, mp3 , The call router 22 will replace the {Digit} placeholder in the URI template with the pressed number, GET the file at the obtained URI, and play a static sound file as a response. This allows the entire application to be written offline in a WYSIWYG html editor. For example, if the server responds to the specified URI template: httu: //demo. twilio. com/myaun/{Digits}. mp3, the caller presses the number 1234, and the router 22 calls the GET at http://demo, twilio. com/ myag /1234. Jingjie mp3 of mp3 and plays it to the caller. The variable used as a substitute in the URI target preferably corresponds to the name of the variable defined for the HTTP GET.POST from the call router and/or the status submission in the header request. As can be seen from the previous example, {Digits} can be associated with a parameter named "Digits" that is preferably generated as a result of "aggregate" telephone commands (a collection of DTMF digits). In a preferred embodiment for the second setting, the call is initiated by the application server 26 (via the call router 22), and the second setting 30 is substantially similar to the first setting 20, so that the call routing is preferably the same The incoming call is processed, that is, when the call status changes, it is processed through the URI request from the call router 22 to the server 26. The application server is also preferably able to make calls to the call router API, as described above.

[0052] 3. Exemplary applications

[0053] The call router application is preferably a network application to implement the most common phone system features with a full API for management. Each call router application object has a unique URI. The call can be transferred to that object instance by specifying its URI as the call target. Call router applications preferably include: AutoAttendant application (in Figure 7)>Follow Me application (in Figure 8)>Conference application (in Figure 9)>Autoconference application (in Figure 9-11), Device application, Person Applications> Voicema Subscription Box application, Group application and Queuing application (in Figure 12).

[0054] The AutoAttendant application as exemplified in FIG. 7 plays the recorded greeting and waits for the caller to press one or more numbers on the keyboard. Based on the input, AutoAttendant preferably directs the call to another AutoAttendant, one or more of the people's phones, voice mailbox, or any other valid call destination.

[0055] The Follow Me application as exemplified in FIG. 8 enables people to be contacted with multiple devices such as work numbers, cellular phone numbers, landline telephones, and/or VoIP phone devices. The Follow Me application is preferably sequentially or simultaneously Call these devices to try to reach people.

[0056] The Stay With Me application enables people to communicate between multiple phone devices such as cellular phones and home phones

CN 102027721 Β

Transfer an ongoing call. For example, the user may wish to transfer a call from a more expensive cell phone to a less expensive fixed phone, or may wish to transfer the call to a fixed phone when the cell phone battery is about to run out.

[0057] The Conference application exemplified in FIG. 9 preferably allows three or more callers to participate in a call at the same time, while providing a mechanism to control who can join and speak during the call. The Conference application can optionally or additionally incorporate SMS messaging control. When receiving an SMS message that includes multiple phone numbers, the Conference application can use a single SMS to initiate a conference call to one or more parties.

[0058] The AutoConference application preferably allows the conference manager to initiate a conference call with two or more parties by performing an operation, such as selecting a button on a website, selecting a button on a telephone device, dialing a phone number, or Schedule the call before starting. Examples of AutoConference applications implemented using the preferred embodiment of the present invention are shown in Figure 9 (viewed from the PSTN device side), Figure 10 (viewed from the application server side), and Figure 11 (started by the application server using the call router API) Out.

[0059] The Device application represents a phone used in the phone system, and can be a hard phone (hardware) or a soft phone (software), a VOIP phone, or a traditional PSTN phone. The Device application handles setting details and device status (do not disturb, busy, etc.).

[0060] The Person application represents a real user of the telephone system. Persons may have one or more extensions, devices, and/or voice mailboxes, and may have a preferred order for dialing their phones or voice mailboxes. People can have usernames and passwords to log in and update these settings.

[0061] The Voicema Subscription Box application preferably plays a greeting and allows the caller to record the message. When finished, the recorded message can be stored for later listening, can be e-mailed as a voice connection or attachment or both. A series of current messages to the voice mailbox can be retrieved through API, through RSS feeds and/or any other appropriate method or device dialing. In a variant form, audio recordings can be automatically transcribed, converting speech into text. The text is preferably included in an email or text message along with audio links, attachments, and/or can be retrieved later by any suitable API tool.

[0062] The Group application preferably represents a logical group of other call router application objects, including other groups. The group preferably defines the behavior of calls directed to the group, including queuing, searching for the first available called party, and dialing multiple called parties at the same time.

[0063] When a phone call or SMS message is received, the Queuing application preferably enters the message sender to the phone call queue, and the message sender calls back through the PSTN, SIP/VoIP network or other telephone network, as shown in FIG. 12 Exemplified. When any one of the person/operator/service (customer service application) is available at the pre-arranged time, you can make a call to the originating number of the message or another pre-determined number, such as wake-up call, anniversary reminder , Birthday reminder.

[0064] The call router application may additionally or alternatively include:

[0065] The Busy Signal Buster service, when receiving an SMS message or a phone call, sends the currently busy number to be called, and uses the originating number of the message or another predetermined number when the number is no longer busy The number calls back the SMS message sender;

[0066] SMS Reader/TTY application, which uses a text-to-speech engine to convert text to audio for callers or members of an audio conference when an SMS is received (for example, tell them that you will join the call in a few minutes), or Used by the hearing impaired to replace TTY services;

[0067] The Translation application, which when receiving a phrase containing a certain language, converts the language of the SMS message (either manually or automatically by a program) into another language and sends a response message via SMS or email; and

CN 102027721 Β

[0068] Programming application, when receiving an SMS message containing programming code, it can compile the code and execute the code, update the website, update the programming project, return data from the database, return the generated computer graphics object as an MMS message, or any other The appropriate program is compiled or calculated.

[0069] The call router application may additionally or alternatively include the Status/Notification application, which allows users to obtain or send objects, tasks, or The status of the process. This service can be used by operators who send SMS messages with the name of a particular server, and then get a callback on their mobile phone and hear the status of that server be read aloud. This service can also be used for notification, that is, for calling other called parties. For example, the storage manager may need to let employees know when the storage is open the next day. The manager can send an SMS message, which will then call each employee and tell him or her over the phone when the memory is open the next day and/or when they need to go to work.

[0070] However, the call router application may include any collection and/or arrangement of these or other suitable pre-established telephony functions and features.

[0071] The application of the preferred method may include simple PBX functions, such as self-service voice menu, employee expansion, and voice mail features. Applications may also include other, unconventional applications such as Interactive Hold application>Conference Calling application, Independent Music Hold Channel, Voting/Fundraising application, Sales application, Blog by phone service, and Call Annotaion application.

[0072] The Interactive Hold application preferably includes interactive activities, such as a question-and-answer contest (with or without the ability to compete with other callers) while waiting to be answered, listening to news headlines or voice podcasts of the listener's choice, and using the phone The keyboard acts as a synthesizer to create music in real time. As an example, the Conference Calling application may include selecting a specific (or random) user from the phone book and confirming the conference call to the group, with the ability to reserve the group for future calls. The Independent Music Hold Channel is preferably in the call While waiting to be answered, independent artists are allowed to upload, categorize their work and allow their work to be played. The Voting/Fundraising application preferably connects willing callers (callers who call to encourage voting or raise funds for the cause) to potential voters and/or donors, preferably including callers for displaying and voting /Interface for information about the donor, and records about the voters response to the call. The Sales application preferably allows sales organizations to quickly integrate inbound and outbound calls with customer relationship management (CRM) applications, or read order details from the shopping cart application. Finally, the Call Annotation application allows call participants to attach metadata, such as reference URIs used in telephone conversations, to specify calls and in-call Timestamp. Participants of the call with the appropriate user agent can view the annotations during the call, and those who listen to later replays of the call audio can also receive such annotations with the same time stamp during playback. Call Annotation can be used, for example, to facilitate conference call recording, employee training, sales team cooperation, and/or customer support cooperation.

[0073] The application may optionally include a hold or park function, where the caller is in a waiting state until an external event resumes the call, for example, the other party becomes active. A variation of this application is the call queue, where the caller waits for a valid agent to answer the call. The application of the preferred method may optionally include other traditional or non-traditional PBX functions.

[0074] Those skilled in the art will recognize from the foregoing detailed description and from the accompanying drawings and claims that modifications and changes can be made to the preferred embodiments of the present invention without departing from the present invention defined by the following claims Range. It is possible and indeed hopeful to design and build additional applications based on the technology platform (the preferred method and/or system of the present invention) that may not use the traditional phone platform in other ways.

CN 102027721 Β