System and method for processing telephony sessions

System and method for processing telephone conversation

[0001] This application is a divisional application of the application whose application date is April 02, 2009, and the application number is 200980116961. 6, the invention title is "System and Method for Processing Telephone Conversation".

[0002] Cross-references to related applications

[0003] This application requires the benefit 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, the application number 61/156, 746 filed on March 2, 2009, the U.S. provisional application titled "System and Method for Processing Telephone Sessions, and the U.S. provisional application 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

[0004] 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.

Background technique

[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. Deploying 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 "telephone 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 required in the telephony field. The present invention provides such new and useful systems and methods.

Summary of the invention

[0006] 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 accessible 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. Familiar with method and system use

The visitor model of the website interacts with the web developers 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 phone commands and creating call router resources accessible through API (Call Router API) work together to utilize multiple call router resources and the call router (preferably REST API familiar to many network developers) Information to enable stateless and simple telephone 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.

[0007] The present invention provides a method for processing a telephone conversation in a network, the network including an application server and a call router, and the method includes the following steps:

[0008] Use an application layer protocol to communicate with the application server;

[0009] Use the call router to process telephone commands; and

[0010] Create calling router resources accessible through the calling router application program interface (API).

[0011] The method may further include a step of mapping the telephony session to a uniform resource identifier (URI), wherein the

The URI may be associated with the application server.

[0012] The method may further include the step of embedding the state information of the telephone conversation into the URI.

[0013] All state information required by the application server may be embedded in the URI.

[0014] The method may further include the steps of: sending a request to the application server; embedding the state information of the telephone session into the request; and receiving a response from the application server; wherein the response includes all The phone instructions.

[0015] The sending step and the receiving step can be performed using Hypertext Transfer Protocol (HTTP).

[0016] The phone instructions may be encoded in Extensible Markup Language (XML).

[0011] The method may further include the step of using the request to send a digital signature, wherein the digital signature may be suitable for use by the application server for account verification.

[0018] The digital signature may be a cryptographic hash generated by a key, wherein the key may be shared by the call router and the server, and wherein the cryptographic hash may be included in the URI.

[0019] The method may further include the step of sequentially processing telephone instructions.

[0020] The method may further include the step of initiating the telephone conversation from a telephone number through a public switched telephone network (PSTN).

[0021] The method may further include the step of initiating the telephone conversation by a message received from a short message service (SMS) system.

[0022] The method may further include the step of initiating the telephone session by the application server through the call router API; wherein the initial URI mapped to the telephone session may be provided by the application server.

[0023] The call router resource can be accessed by an external device at an addressable URI.

[0024] The call router API may essentially be a representational state transfer (REST) API.

[0025] The method may include the following steps: storing state information in the URI of the call router resource; modifying the call router resource to change the state of the call router; and interacting with the call router according to the call router API Media interaction.

[0026] The method may include the following steps: receiving an API request from the application server to interact with resources; and

Respond to the API request based on the interaction with the resource.

[0027] The method may include creating a resource selected from the group consisting of call resources, media resources, incoming address resources, account resources, and caller identity (ID) resources.

[0028] The method may include: using the call resource to change the state of the telephone conversation; using the media resource to access media; using the incoming address resource to modify the incoming address; using the account resource to modify account information; and Use the caller ID resource to modify the caller ID information.

[0029] The phone instruction can be selected from the group consisting of: connect to a phone device, play a media file, convert text to voice, detect input from the phone device, and connect to a new URL.

[0030] The method may include creating a call resource; wherein the call resource may be used to change the connection of the telephone session.

[0031] Changing the connection of a call session may include: joining a phone session, splitting a phone session, and transferring a phone session.

[0032] The present invention also provides a system for processing telephone conversations, including:

[0033] A call router, which is connected to a telephone device and communicates with an application server using an application layer protocol;

[0034] A URI for the application server, which is associated with a telephone address;

[0035] telephone instructions, which are sequentially executed by the call router; and

[0036] Call router API resources, which are created by the call router and can be accessed by the application server through the call router API.

[0037] The application layer protocol may be an HTTP protocol, and the telephone command may be encoded in XML.

[0038] The request may encapsulate the status of the call.

[0039] The call router API may be REST APL.

[0040] The resources may be selected from the group consisting of call resources, media resources, account resources, incoming address resources, and caller ID resources.

Description of the drawings

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

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

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

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

[0045] FIGS. 5A and 5B are examples of XML responses.

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

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

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

Detailed ways

[0049] 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.

[0050] 1. Method for processing telephone conversation

[0051] As shown in FIGS. 1, 2A, 2B, 3A, and 3B, a preferred embodiment method 10 for processing a telephone conversation

It includes the step S110 of communicating with the application server using the application layer protocol, the step S120 of processing the phone instruction with the call router, and the step S130 of creating a call router resource that can be accessed through an application program interface (API). The preferred method may also include other steps and/or sub-steps explained below.

[0052] 1A. Communicate with the application server

[0053] 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.

[0054] It is stated that 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. The sending is based on the receiving address of SMS such as short code, or direct inward dialing (DID), or Other appropriate unique receiving identifiers. The message may optionally be a multimedia message, fax transmission, e-mail, 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 VOIP provider ID, SMS device number, email address, or short code. The phone number, EIN, and/or count dialed The fee 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.

[0055] 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.

[0056] 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) or the account owner of the calling router at the calling router. 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 equipment or method. In a variant form, the URI can be used to encapsulate the call from being activated

The status information or part of the status information of the conversation, such as the originating phone number, the phone number dialed, the date and time of the call, the geographic location of the caller (for example, country, city, state, and/or postal code), and/ Or the unique call IDo information included in the URI can be included in the form of a URI template. For example, the default URI template can be: http://demo, twilio. com/myapp/{the dialed phone number}/{originating phone number} or http://demo, twilio. com/myapp,/foo . php? dialed_number = {Dialed phone number}&originating_ number = {Originating phone number}.

[0057] 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.

[0058] 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 a server running locally on the device that originated the call. 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 is preferably 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 variant, 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. HTTP to the server

The request (or any appropriate request communication) 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 arbitrary What appropriate equipment to imitate 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.

[0059] 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, for example, a malicious request, an incorrect routing request, and a corrupted request. Requests 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 a server-side encrypted hash of the received parameters. 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 an application server and a 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.

[0060] 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 files mapped to the disk through the URI can be Simply return.

[0061] Step S9 states the response from the server. This response is preferably an HTTP response. The response is preferably as

It is sent as XML, audio binary, or raw text, but can also optionally be in any kind of messaging format, including HTML, delimited 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.

[0062] 1B. Handling phone instructions

[0063] 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 executable 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) on the server 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.

[0064] 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 phone 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 server applications to perform telephony services. Algorithm conversion (based on communication status) of telephone verbs or documents is preferably unnecessary. Preferably, the phone operations are performed in the order of the phone instructions contained in the content of the server response. 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 form, if the server fails to specify the next URI, no repetition occurs, and the process continues to the next Call text router instructions. 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 is preferably repeated using all new telephone conversation state information generated by the execution of the telephone operation, such as pressed numbers, recorded audio files, or success or failure information of any telephone operation requested. 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, twilio. com/foo. php? Digits = {Digits}, and the caller presses 1234, the resulting URI is Is http:// demo, twilio. com/foo. php? Digits = 1234_OSimilarly, if the server responds to the specified URI template: http://demo, twilio. com/myapp/ {Digits}. mp3, the resulting HTTP request may be located at: http:// demo, twilio. com/myapp/1234 . mp3 static mp3 file. Therefore, the call can be made by the service that issues phone instructions

The second server control that handles the response is shown in Figure 13 and Figure 14. Such call control transfer constitutes the conversion of status 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.

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

[0066] 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 status, 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. The application server can use the call router API to preferably query the metadata of the call record, the identity of the caller, the call media (such as records, text copies, etc.), account information, the transfer in the call router or the interaction with the ongoing communication, And/or manipulate any appropriate data generated or required by the calling router. The call router API preferably relates to the communication between the application server and the call router, but can optionally be communication from any suitable device to the call 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 alternatively 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 It now includes the calling router API request format, the calling router API response format, and the calling router API of multiple API resources representing the types of data generated or used by the calling router.

[0067] 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 a REST API request, but the Call Router API request may alternatively conform to any suitable programming manner, such as SOAP ο Call Router API request preferably uses HTTP to interact with resources, but may also be used or any HTTP 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.

[0068] The call router API response of the preferred embodiment is sent in response to a method executed on the API resource.

The communication information sent to work. 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, messages, error codes, 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 .

[0069] 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. The operation of the calling router affects the future call status or capabilities of the calling router, and/or has any appropriate influence. [0070] 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.

[0071] 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 alternative, 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

[0072] 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.

[0073] 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 changing 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, call start time, end 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.

[0074] 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 phone session, terminating an existing phone 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 a call agent becoming active, or someone responding to 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 therefore

The caller returns to the first call session. Call resources can optionally be used in any suitable application.

[0075] 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.

[0076] 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 phone instructions (or markup language) so that the phone instructions can instruct the calling router to perform the operation of creating media resources. 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 GET requests to return media in multiple formats, such as binary or XML metadata representations. The media resource can accept a request to delete the media resource. In a form of change, media resources preferably require access to resources 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 are hosted by the call router API. The media resource preferably allows the 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.

[0077] 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 (that is, to 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.

[0078] 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.

[0079] 2. System for processing telephone conversation

[0080] 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.

[0081] 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 to the application server by the call router request 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. The call router 22 preferably 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, postal code), dialed number, and time of call. Time, 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 can also be sent in URL (GET) variables, or encapsulated in HTTP headers. 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 (for example, 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.

[0082] 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 via the network 24, more preferably via 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 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. The telephone command 27 can optionally be associated with SMS messaging, Multimedia Messaging Service (MMS) messaging, email, or any Appropriate messaging tasks are related. 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 page and static sound file deployed on a static web server where there is no available development or scripting environment. This change form preferably uses URI template (HTML5 currently launched by IETF), which is based on This book includes the URL with placeholders with variable data, such as: http://www.twilio. com/audio/{Digit}.mp3, where the call router 22 will replace the URI template with the pressed number (Digit }Placeholder, 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: http://demo, twilio. com/myapp/ {Digits}. mp3, the caller presses the number 1234, and the call router 22 will GET at http://demo, twilio. com/ myapp /1234. Static mp3 of mp3 and play it to the caller. The variable used as a substitute in the URI target is preferably the same as

The HTTP GET.POST from the calling router and/or the state submission in the header request corresponds to the name of the variable defined. 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.

[0083] 3. Exemplary applications

[0084] 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).

[0085] 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.

[0086] 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 phones, and/or VoIP phone devices. The Follow Me application is preferably sequentially or simultaneously Call these devices to try to reach people.

[0087] The Stay With Me application enables people to transfer ongoing calls between multiple telephone devices such as cellular phones and home phones. 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.

[0088] 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 an SMS message including multiple phone numbers is received, the Conference application can use a single SMS to initiate a conference call to one or more parties.

[0089] 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.

[0090] 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.).

[0091] 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.

[0092] The Voicema Subscription Box application preferably plays a greeting and allows the caller to record the message. When finished, it has been recorded

Recorded messages can be stored for later listening, can be e-mailed as a voice link 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.

[0093] 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.

[0094] 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 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.

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

[0096] 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;

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

[0098] 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 [ 0099] 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 Appropriate program compilation or calculation.

[0100] The call router application may additionally or alternatively include the Status/Notification application, which allows users to obtain or send objects and tasks by sending SMS messages and receiving callbacks via PSTN, SIP/VoIP networks or other telephone networks. Or the state 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.

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

[0102] 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 Annotation application.

[0103] 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

Use the phone keyboard 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 the call and the timestamp in the call. 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 Promote conference call recording, employee training, sales team cooperation and/or customer support cooperation.

[0104] 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, in which 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.

[0105] 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.