Method and system for a multitenancy telephone network

Method and system for multi-tenant telephone network

[0001] Cross reference to related applications

[0002] This application claims the benefit of the following U.S. Provisional Patent Application: U.S. Provisional Patent No. 61/156,758, filed on March 2, 2009, entitled "A method of Providing a Telephony Network for a Plurality of Users" Application; Filed on October 7, 2009, United States Provisional Patent Application No. 61/249,493 entitled Method and System for a Multitenancy Telephone Network; filed on January 19, 2010, entitled Method and System For a Multitenancy Telephone Network, US Provisional Patent Application No. 61/296, 270, which is incorporated herein by reference in its entirety.

[0003] This application relates to an earlier application No. 12/417,630, which was filed on April 02, 2009, entitled System and Method for Processing Telephony Sessions, which is incorporated herein by reference in its entirety.

Technical field

[0004] The present invention generally relates to the telephony field, and more specifically to a novel and practical multi-tenant (Multitenancy) telephone network in the telephony field.

Background technique

[0005] For telephone conversations or connections, telephone networks have historically adopted a channel architecture. The channel architecture has a foundation in telephone history. The physical wire connection or channel needs to be physically connected to make a phone call. The concept of channel is still in use today. Traditionally, users of the telephone network are required to pay on a per-channel basis. Users who wish to have a public exchange (PBX), call center, or similar telephony applications usually subscribe to services or have a fixed number of channels available to them only. Since the number of channels is part of their contract, they cannot exceed the number of channels (otherwise the call or telephone conversation will be invalidated). Since most applications occasionally experience full capacity usage, users often pay for more channels than normally used.

[0006] In contrast to the channel-based architecture of telephone networks, packet-based network innovation has increased significantly in recent years, such as VOIP, Internet-based applications, and Internet-based phone applications. As newer technologies enter the telephony field, processing hardware and software capacity needs are facing rare challenges. Dedicated hardware and software often perform tasks during a telephone call session or even act as an intermediary system that connects the caller to Internet-based applications. Telephone systems generally have higher performance expectations than web-based applications. When website users expect the website and software to take time to load and process information, callers who are on a call experience delays or responsive interactions. In addition, telephony applications still rely on channel-based telephony systems, which adds another barrier to scalability. The telephone network and the existing telephone application software and hardware architecture limit the growth capacity of the telephone application field. Therefore, it is necessary to establish a new and practical multi-tenant telephone network in the telephony field. The present invention provides this new and practical system and method.

[0007] Purpose of the invention

[0008] The present invention provides a system and method for providing a multi-tenant telephone network for telephone applications. An object of the present invention is to manage the use of shared resources in a multi-user environment and dynamically expand and contract resources to meet capacity requirements. The related effect of this goal is that the sum of the apparent number of resources available to each user is greater than the actual number of resources used to implement a multi-tenant telephone network. Another object of the present invention is to effectively utilize the resources of the telephone platform by providing processing and storage resources.

Satisfy the capacity requirement, thereby effectively leaving other unused resources for other applications, turning them off to save power, or any suitable function. Another object of the present invention is to make the use of the telephone resource cluster transparent to the user's application. This transparency is preferably preserved even if the operation of the application is distributed among multiple telephone service resources and may involve multiple telephone conversations on different channels. These and other objects of the present invention are achieved by preferred embodiments of the present invention, including a system for a multi-tenant telephone network, a method of operating a multi-tenant telephone network, a method of operating a dynamic telephone network, and a method of distributing calls among telephone hardware , Described one by one in the following sections.

[0009] Brief Description of the Drawings

[0010] FIG. 1 is a flow diagram of a preferred embodiment of a method for operating a multi-tenant telephone network;

[0011] FIGS. 2-4 are schematic illustrations of a preferred embodiment of a system of a multi-tenant telephone network;

[0012] FIG. 5 is a schematic illustration of a preferred embodiment of the present invention using a call transcriber cluster;

[0013] FIG. 6 is a flowchart of a preferred embodiment of a method of operating a dynamic telephone network;

[0014] FIG. 7 is a flowchart of a preferred embodiment of the present invention implementing a conference call; and

[0015] FIG. 8 is a flowchart of a preferred embodiment of the present invention for receiving an incoming call.

[0016] Description of the preferred embodiment

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

[0018] 1. System for multi-tenant telephone network

[0019] As shown in FIGS. 2-4, the system 100 of the preferred embodiment includes a telephone resource cluster 110, a call queue 120, an analysis system 130, a resource allocator 140, and a plurality of telephone network channels 150. The telephone resource 110 cluster preferably includes a plurality of allocated telephone network channels 152 and/or a plurality of telephone resources 112 such as a plurality of call routers, load balancers, and may additionally include business applications. The system plays a role in allocating the use of network and system resources and dynamically adjusting the system based on capacity requirements.

[0020] The telephone resource cluster 110 (or "cluster") functions as a scalable (scalable and/or contractible) resource collection, in which at least one resource is used to create a telephone call session required by the user. The cluster 110 is preferably a collection of hardware and/or software components that can be dynamically adjusted to meet processing and/or storage requirements. The cluster 110 is preferably presented as a hardware and/or software cloud with respect to external devices, so that the management of hardware allocation and use is handled internally by the system. In a variant shown in FIG. 2, the telephone resource cluster 110 is preferably a plurality of telephone resources 112, and the telephone resource 112 functions as a call request or a call session, such as establishing a call session, and converting a telephone command into a call action. , Transcribe a call, or connect a call, etc. to provide intermediate processing tasks. In another variant shown in FIG. 3, the telephone resource cluster 110 is preferably a plurality of connections to the assigned telephone network channel 152, where the assigned telephone network channel 152 is a channel that has been activated or designated as available for a call session The channel of the allocated telephone network channel 152.

[0021] The phone resource 112 is preferably a software or hardware resource provided for a specific phone processing task. Preferably, there are multiple phone resources 112, and there may be multiple phone resource types that perform different specialized tasks. The telephone resource 112 preferably includes a computer processor and/or a computer storage device. The phone resource 112 may be any suitable combination of physical hardware devices, virtual machines, software programs/routines, and/or provide the processing and storage operations of the phone resource 112. In some cases, the telephony resource 112 may include dedicated hardware or software. Since the phone resource 112 shares basic functions in terms of processing capabilities or data storage, the core functions of the phone resource 112 can be additionally configured to enable the phone resource 112 to perform different specialized tasks. The resource allocator 140 (more specifically, the load balancer 142) preferably allocates a phone resource 112 as a different part of the resource cluster 110. For example, the cluster can include many text-to-speech servers and many call routers,

However, at a certain point in time, only a small number of text-to-speech operations can be performed and an increased number of phone applications, so the text-to-speech server is preferably configured as a call router. In a variant, the plurality of telephony resources 112 (ie, the cluster 110) preferably includes a plurality of call routers 114. Additionally or alternatively, the cluster may include other hardware devices or software routines, such as media processing systems, transcription systems, text-to-speech systems, call recorders, call data storage, or any suitable hardware (physical devices or virtual machines) Or software. The resource allocator 140 of the cluster preferably includes a load balancer 142, which manages the distribution of processing tasks and the operation of multiple phone resources 112. In addition, the cluster may include business applications and/or call router networks that can jointly solve problems caused by the use of multiple resources.

[0022] A plurality of call routers 114 play a role in initiating or receiving calls from telephone devices and providing processing related to telephone applications. Preferably, the call router is connected to an application server, which is preferably the source of the call request. The plurality of call routers 114 are preferably a dynamic number of call routers 114 that can be adjusted according to capacity requirements. As mentioned above, in alternative embodiments, the multiple call routers 114 may be replaced by or combined with other appropriate telephone hardware or software resources, such as media processing systems, transcription systems, text To the voice system, or other dedicated hardware or software resources used in telephony applications. In one example, multiple transcription hardware resources or virtual resources can be used instead of the call router to transcribe telephone calls, as shown in FIG. 5. In addition, the call router 114 can be additionally configured as a media processing system, transcription system, text-to-speech system, or used in any appropriate process, And similarly any processor can be additionally equipped to be used as a call router. The number of hardware or software resources can be additionally or alternatively allocated or deallocated, so that any desired number of resources in any suitable combination can be operated at any time. When a hardware instance is deallocated, it can be powered off, put into an energy-saving mode, or placed in any appropriate state. The phone resource 112 may additionally or alternatively operate as a virtual resource on a cloud computing platform (which may be operated by an external party such as Elastic Compute Cloud operated by Amazon). When the phone resource 112 such as the call router 114 is deallocated, the virtual resource can be returned to the provider and provided to other users of the cloud computing platform, ending the virtualization of the resource or any appropriate process. When deallocating, you can exit or delete the software instance. The resource ratio such as the ratio of the call router to the media processing system can be adjusted or maintained.

[0023] The call router 114 is preferably connected to a public switched telephone network (PSTN) device via a PSTN network so that it can receive and generate calls from PSTN connected devices, such as land communication lines, cellular phones, satellite phones, or any other suitable PSTN connected devices, and non-PSTN devices such as Internet (VOIP) phones, SIP devices, Skype, Gtalk, or other Internet-addressable voice devices. Therefore, the call router 112 can preferably create a connection to the telephone network of the distributed telephone controller. The call router 112 may alternatively or additionally serve as or include an information router for telephone information such as SMS (Short Message Service) information or MMS (Multimedia Information). The call router 112 may preferably be connected to an information network so that it can receive and send information from SMS/MMS network devices, cellular phones, computers, smart phones, or any appropriate SMS/MMS network devices. The call router 112 can also send or receive text messages, multimedia messages, e-mails, faxes, or other appropriate PSTN-compatible communication messages. The call router 112 preferably uses an application layer protocol, and more preferably uses an HTTP (Hypertext Transfer Protocol) protocol, or a secure HTTPS (Hypertext Transfer Protocol Secure) protocol to communicate with the application server. The application server preferably hosts the phone application, voice Files, text files, databases, and/or any appropriate media, resources, or files that can be used by the call router in telephone interaction. The call router 112 may additionally generate call router resources. Call router resources are preferably accessible by application servers and other devices (such as other call routers) through the call router API. The call router resource functions as an addressable representation of the call router metadata, the state of the internal call router, or the state of a given resource used by the call router. For example, the call router 114 can record the call and save the record as a call route

Device resources.

[0024] In addition, the telephone resource cluster 110 of the preferred embodiment may include a service application 116, which acts as an information component to coordinate functions of applications distributed among various call routers 114, hardware resources, and/or software resources. The service application 116 is preferably an internal resource, and the internal resource is used when the normal operation of the application is blocked because the operation of the application is distributed among various hardware and software resources of the cluster 110. The service application 116 is preferably an information service that provides reliable information when the information is delivered to a specific destination, such as to another call router 114. The service application 116 may alternatively provide broadcast information, which publishes the information without knowing who received the information if it was received. As a first example, the hang-up call service application 116 can be used to coordinate hang-up call sessions on different call routers 114. The hang up service is preferably used to communicate to the appropriate call router 114 to cancel outgoing calls, for example when an application wants to dial multiple numbers but once one of the calls is answered, then hang up all unanswered calls. As a second example, a multi-input service can aggregate and input commands from multiple telephone devices. Therefore, dual-tone multi-frequency (DTMF) input or voice commands can be issued and sent to the application by any caller, even if the call is distributed on multiple call routers 114 in the cluster. This can be used in voting applications in conference phones. In this way, the phone should The user does not need to actively deal with the processing and call processing distributed in the cluster, and the hardware and software resources of the cluster are preferably presented as a single entity to the external application due to the internal service application 116.

[0025] In addition, the telephone resource cluster 110 of the preferred embodiment may include a call router network 118, which functions to allow a certain level of communication and synchronization between the various call routers 114. The call router network 118 may additionally or alternatively be applied to other hardware or software resources. The call router network 118 is preferably used to access shared resources or as a communication channel. In an exemplary application, a voice over Internet (V0IP) connection is established on the call router network 118 to mix audio from various call routers. VOIP connections are preferably used to implement conference calls distributed on multiple call routers 114. As another example, the call router network 118 may additionally be used to offload audio from the call router to a real-time Internet audio stream. As another example, the call router network 118 may be used to access data on another phone resource 112, such as by using a call router API to access the call router resource. The service application 116 and the call router network 118 may additionally coordinate with each other in applications that are synchronously distributed within the cluster.

[0026] The call queue 120 of the preferred embodiment functions to manage the call request stack. The call queue 120 is preferably a list of outgoing call requests that have not been served or the necessary resources have not been allocated. The request is preferably serviced at a rate suitable for the current capacity of the network 150 and telephony resource cluster 110. The service rate may alternatively be adjusted according to the capacity of the distributed telephone controller 114, the telephone resource cluster 110, and/or the number of requests in the queue 120. When the capacity is exceeded, it is preferable to place a call request (such as a request initiated by a phone application) in the call queue 120, or alternatively place the call request in the call queue 120 for each request or based on any appropriate rules. in.

[0027] In a variant, the application preferably has related user restrictions, in particular: inter-call rate limit (throttling) and total limit (maximum limit). Throttling and ceiling are preferably used to determine the location of requests in the call queue. The restriction can alternatively be assigned to an account, phone number, or any appropriate entity. Phone information (for example, SMS and MMS) is a variant of call requests that can be placed in the call queue. It is preferable to queue up and out of the phone information of the stack, since the information of the stack is not like a call to the stack, it does not require immediate action. SMS messages are preferably sent after the requests in the queue are serviced. The SMS message and/or MMS message can alternatively be queued in a dedicated message queue. SMS messages can have a rate limit (throttling) and a total limit (maximum limit) that vary with the request. The requests received from users at any rate are preferably arranged in the call queue at certain time intervals according to the throttle. There is preferably a mandatory waiting time between call requests from the application. Preferably as shown in

The staggered or alternating pattern shown in 6 sorts the requests of different users in the queue, but alternatively, users can have priority based on service plan, first-come first-served strategy, call request type, and/or any appropriate strategy . The maximum limit is preferably a limit on the total number of requests that a user can make in a given time. The user restrictions, processing, spacing, and/or sequencing of the call queue 120 serve to prevent an application from unfairly occupying the use of the telephone network or telephone resource cluster at any time. In addition, the application may require access to the phone resource 112 as soon as possible or at some time in the future (for example, the user schedules a call or a call at a later time). Additionally or alternatively, user restrictions can be adjusted or set according to the needs of the application. Applications can have specific requirements based on the type or characteristics of user applications. The user limit is preferably set according to the contract and/or pricing model selected by the user or by other appropriate methods.

[0028] In another variant, the call queue 120 is dedicated to requests from a single user entity. In this variant, there is preferably a plurality of individually assigned call queues 120. The call request is preferably programmed into the call queue 120 of each user. The phone information request may alternatively have a queue for each phone number. Preferably, user requests can be added to the separately allocated queue 120 at any time. Each queue is preferably served (ie, dequeued) according to a plan that takes into account each user's constraints (such as resource constraints, system-wide constraints, etc.). In other words, dequeue occurs among the multiple call queues 120 in an alternating manner. Separately allocated call queues can be additionally used for specific resources, and dequeue preferably occurs according to the dequeue rate of the specific resource. The dequeue rate is preferably related to the capacity of the resource, but may alternatively be based on any suitable criteria. Like other queuing variants, queuing can alternatively occur according to any suitable queuing method, such as random, round-robin, fair queuing, weighted fair queuing, based on actual resource usage, and/or any suitable queuing method. method. As an alternative to queuing based on account/phone number, calls or information requests can be queued based on time, priority, usage history, or any appropriate aspect. There may additionally be a control queue for coordinating the dequeuing of the individually allocated call queue (or information queue) 120.

[0029] As described above, the call queue 120 may include additional or alternative systems for processing telephone information (for example, SMS or MMS information). SMS information preferably has additional restrictions and restrictions on its service rate. It is preferable not only to queue SMS messages for sharing telephone network access with various users, but also to preferably implement a rate to prevent SMS messages from a single user from being rate limited and being identified as spam emails. The call queue 120 for telephone information may include at least two types of queues: a control queue and a phone number queue. The phone number queue preferably functions as a single user's personal queue for the phone information that the user wishes to send, and the control queue is substantially similar to the multi-user queue described above for the call queue 120. The individually allocated call queue 120 may alternatively be used instead of the control queue, and the individually allocated call queue 120 may be based on the account phone number or any appropriate allocation. The control queue and the telephone number queue preferably function to separate the information queue of a specific application and the information queue of a plurality of messages. Preferably, the content of the SMS message (text) or the content of the MMS message (multimedia) is not directly stored in the call queue, and the number of the content of the SMS message is preferably stored. This has the effect of reducing queue load. It is preferable to store and access SMS/MMS content when serving the queued number.

[0030] A popper 122 (ie, a dequeuer) is preferably a software or hardware mechanism, which plays a role in selecting the call request to be served from the call queue. The queue pop-up 122 preferably selects call requests at a preferred rate, but the queue pop-up may alternatively select call requests based on capacity or available resources, or a combination thereof. There may additionally be a plurality of queue poppers 122 that function to select call requests from the call queue 120 at the same time. The number of call poppers 122 is variable. Additional or dedicated queue poppers 122 can be used for additional SMS call queues. The call queue 120, the queue pop-up 122, or any suitable combination may preferably be used to control the throttling (or service rate) of call requests. Can be on every phone number, every account (as in a multi-user application), and/or according to any call/message

Features implement throttling.

[0031] The analysis system 130 of the preferred embodiment functions as an analysis system to predict resource demand. The analysis system 130 preferably monitors various aspects of the system. The analysis system 130 can monitor the current capacity or trend (increase or decrease) such as the network or hardware operation level; such as to find out the usage history of the stored data (for example, detection mode) related to capacity; queue length and queue entry waiting time; From the past use of the application to analyze the application such as historical patterns; and/or any appropriate aspects. It is preferable to find out related to the time of day, the days of the week, annual patterns, usage patterns (such as if an increase in demand capacity of one user indicates an increase in demand capacity of other users), call location, call duration of the call, and /Or any appropriate indicator. The analysis system 130 preferably distinguishes between the incoming and outgoing capacity of the telephone network channel. The analysis system preferably generates data for the resource allocator 140, the distributed telephone controller 144, the load balancer 142, and/or additionally, the call queue 120. Forecasts or data from the analysis system can additionally be used to provide the capacity of the distributed call controller, the capacity requirements for planning the static capacity of the telephone network, the number of call routers, the hardware or software resources in the cluster, and/or the queue Managed parameters. The analysis system 130 preferably compares expected and actual loads and provides data to compensate for variability in the system's resource usage.

[0032] The resource allocator 140 of the preferred embodiment plays a role of scaling and managing the operation of the telephone cluster 110. The resource allocator 140 additionally preferably allocates the phone resources 112 of the cluster 110, allocates a new phone resource 112, de-allocates the phone resources, and/or any other appropriate allocation process. The resource allocator 140 may additionally control the supply of call queues and other equipment of the system. The resource allocator 140 preferably uses the data of the analysis system 130 in determining the supply and operation of the resource. The resource allocator 140 preferably uses information from the analysis system 130 to predict the required capacity of the phone resource 112. The resource allocator 140 preferably uses the predicted capacity requirements to determine how much hardware (physical or virtual) or software resources need to be run, and the resource allocator preferably allocates, de-allocates, or allocates phone resources 112 as needed (eg , Call router and/or other hardware or software resources). When determining the number and ratio of resources that have been allocated at a certain time, the resource allocator 140 may additionally use parameters such as startup time, running cost, or other hardware and software resources. The resource allocator 140 also preferably keeps track of the number of resources currently available, and allows other system components (including a dequeueer, a load balancer, etc.) to obtain resource availability information. Letter of availability of this resource The information is preferably used by other system components to adjust the operation of the system components. The resource allocator 150 preferably monitors resources in real time and allocates resources separately.

[0033] The resource allocator 140 of the preferred embodiment preferably includes a load balancer 142, which functions to distribute processing tasks between the call router and other hardware. The load balancer 140 of the preferred embodiment preferably optimizes the distribution of processing tasks so that the multiple call routers 114 operate at an optimal or near optimal level. The operation of the call router 114 may be optimized for performance, energy, cost, and/or any suitable conditions. The load balancer 142 preferably instructs the task (eg, call request/session service) to the appropriate call router 142 (or phone resource 112) when the task is created. The task is preferably the execution of a phone application, but may alternatively be a call request or a call session. In one example, one hundred call routers 114 can provide call router tasks for one hundred phone applications. In the second example, one hundred call routers 114 may each handle a single call session related to one telephony application, such as a teleconference application with one hundred participants. The resource allocator 140 preferably sends a notification about the current state of the system resources (resource load, resource amount, etc.) to the load balancer 142. The load balancer 142 distributes the request to the currently available and running resources based on the data provided by the resource allocator 140 to meet the needs of the load-balanced application.

[0034] The resource allocator 140 of the preferred embodiment may include a distributed call controller 144, which controls the

The role of the telephone network 150 used and operated by the system. The distributed call controller preferably manages the shared use of the telephone network channel 150 by multiple telephone resources. If multiple network providers or carriers are used, distributed call controller 144 may alternatively be a subset of multiple telephone networks. The operation of the distributed call controller 144 preferably functions to control the number of channels allocated for the current capacity requirements of the telephone network 150. The allocated channel is preferably a channel in use or ready for use in the available static channel capacity. The capacity of the distributed call controller is preferably less than or equal to the static channel capacity at any given time. The capacity of the distributed call controller 150 may preferably be increased by allocating more telephone network resources to the call controller, and the capacity of the distributed call controller 144 may preferably be reduced by de-allocating telephone network resources. As an example, commercial hardware nodes can be added to the telephone network to run the telephone software stack during periods of high capacity demand. The distributed call controller 144 preferably uses the analysis system 130 to predict or respond to desired capacity requirements. The telephone network 150 can be additionally divided into an inbound channel, an outbound channel, and two-way channels that can be used for receiving calls, making calls, and receiving and making calls, respectively. The telephone network 150 may also include SMS or MMS in-stack and out-stack channels. The distributed call controller 144 preferably manages the use of channel types based on the predicted use. Two-way channels can be preferably used for flexibility in capacity requirements. As an example, if the incoming call load is expected to be high, then it is preferable to direct the outgoing call to the out-of-stack channel to reserve more capacity for the incoming call. The distributed call controller 144 may additionally manage the number and usage of allocated channels according to an order or contract from a network provider. Channels can be allocated or deallocated to ensure that batch pricing thresholds or other network conditions are met.

[0035] A telephone network with a static number of channels 150 is preferably a basic infrastructure that provides users with telephone network access. The telephone conversation preferably communicates through a telephone network, and the telephone conversation preferably includes a telephone voice conversation and/or text/media information (telephone message transmission). The static number of channels is preferably the total number of simultaneous phone sessions or calls that can be supported at one time. The number of channels is usually limited by the number of interconnections available for a particular carrier or network. The telephone network 150 may alternatively be composed of multiple carriers or network providers or a public switched telephone network, but it is preferable to manage or handle multiple carriers or networks as one telephone network. The static number of channels is preferably a set number for a period of time (usually based on a contract with the telephone company), and the number is preferably large enough to provide sufficient capacity. The static number of channels preferably determines the network capacity and the capabilities of the telephone network connected to other networks. The operation of the telephone network is preferably handled by an application that provides a channel to access the telephone network. The telephone network can have a given number of channels that are not used at any given time. In a variant, the telephone network can alternatively operate unused channels in an unused mode. The unused mode can be a full or partial hardware power-down mode, a hardware sleep mode, auxiliary use (such as for non-critical use that can be preferably interrupted with minimal negative impact), and/or any appropriate method formula. The unused mode can play a role in reducing operating costs and/or maximizing utilization of unused capacity. The telephone network channel 150 is preferably a public switched telephone network (PSTN) connection, but may alternatively be a Session Initiation Protocol (SIP) information path or any suitable device that creates a telephone network connection to the telephone device.

[0036] 2. Method of operating a multi-user telephone network

[0037] As shown in FIG. 1, the method 100 for operating a multi-user telephone network of the preferred embodiment includes a step S110 of multiplexing call requests of multiple users to a telephone resource, and a first call is created from the call request through the telephone resource. Step S130 of the conversation, and step S140 of multiplexing the call session and multiple other call sessions to the telephone channel. The method 100 serves to create an effective and scalable network system for resource-intensive telephony applications. The telephone resource is preferably part of a telephone resource cluster. Due to the ability to handle a wide spectrum of network loads, the phone resource cluster is preferably scaled to meet current capacity requirements, which plays a role in reducing operating costs and allowing multiple applications to use the multi-user phone network. In addition, the method 100 serves to allow the operation of the phone application to be distributed among a variety of multi-user,

Shared resources (for example, phone resources), so that the specific target of the phone application is not restricted by the multi-user phone network. The method 100 of the preferred embodiment is preferably implemented by the system described above, but may alternatively be implemented by any suitable system.

[0038] Step S110, which includes multiplexing the call requests of multiple users to the phone resources, and plays a role of sharing the use of the phone resources among the multiple users. A single phone resource is preferably shared among multiple users/applications. The multiplexing preferably occurs in the form of time division multiplexing, where call requests are sent to the phone resource in an alternating manner. Time division multiplexing is preferably based on the end of a complete call session or process. In other words, users take turns to use phone resources to create call sessions and run applications. For example, the first client preferably makes the call request served by the phone resource, and when the call session of the call request ends, the second user can make the call request served by the same phone resource. The call request is preferably received from the user or more specifically from a phone application residing on an external server, but the call request may alternatively be sent from any suitable source. The call request is preferably received on a packet-based communication channel, in other words an indirect communication channel. In a variant, the call request is preferably received with HTTP or HTTPS information, but may alternatively be received via any suitable application communication protocol. Step S110 may additionally include step S112 of queuing the user's call request, which serves as gate control or prioritizes the incoming call request. The call queue is preferably used for pop-out requests, and incoming call requests are preferably processed immediately (otherwise the call session will likely fail). Alternatively, incoming Calls can be queued for all services, and when the call is waiting in the queue to be fully serviced, the "ringing" audio is playing back. However, the queue can be used for incoming phone messages because phone messages such as SMS messages and MMS messages are in It will be sent repeatedly if it is not received on the first attempt. The call queue is preferably a list of pending call requests from multiple users. Another queue may be used for phone information in addition or alternatively. Preferably in the queue to balance The way to access resources to sort call requests. Preferably, each user (for example, account, application, or phone number) is assigned an internal call request limit (throttling) and a limit on the maximum number of call requests that can be made within a specified time (Maximum limit). The call request is preferably selected for service at a prescribed rate or by a device (ie, a queue popper) that can select a call based on the current load on the phone resource cluster. It may alternatively be used in any suitable Run the queue in variants such as those described above. The queue can be assigned to each user or phone number. The queuing can alternatively occur according to any suitable queuing method, such as random, round-robin, fair queuing, weighting Fair queuing based on actual resource usage, and/or any appropriate method. The load balancer preferably distributes call requests to the phone resources with the least capacity. As described above, the load balancer and the call request queue preferably cooperate To distribute the load.

[0039] As an additional step, the method 100 preferably includes the step S120 of supplying resources of the telephone resource cluster, which functions to expand and contract the capacity of the telephone resource cluster to sufficiently multiplex the call request to the telephone resource. Step S120 may include separately allocating existing phone resources of the phone resource cluster, allocating additional resources to the phone resource cluster, and/or deallocating the resources of the phone resource cluster, and/or real-time reallocation of one type of resource to another A type of resource. The telephony resource cluster preferably includes a plurality of telephony resources that perform various functions or operations as described above. For example, a telephony resource cluster can include multiple call routers, transcription systems, media processing systems, and text-to-speech systems. The phone resources are preferably composed of computer processors and/or storage resources for the first purpose. As part of S120, the resources of the telephone resource cluster: the resources of the telephone resource of the processor and/or storage device are preferably allocated a new second purpose. For example, when more calls need to be serviced, text-to-speech can be added to act as a call router. In addition, more resources can be allocated or deallocated, which can include adding new resources to the system and/or activating resources, or reallocating resources from another client of the shared resource environment. The resource may preferably be a virtual computing environment shared by multiple tenants, such as a cloud hosting provider (that is, providing a variable-size computing capacity that allows the user to start the machine

Image to create virtual machine resources (Internet services) provided by those resources, but can alternatively be co-located or distributed physical machines. For example, many resources can be running in a power-down state. When more capacity is required, resources can be turned on/started (that is, allocated) to serve as new resources of the phone resource cluster. Similarly, when the capacity of the phone resource cluster exceeds the currently required capacity, the resource can be powered down and returned to the resource pool for use by other companies (ie, deallocate), or take any appropriate action to end the current use of the resource .

[0040] In addition, step S120 may include step S122 of analyzing resource capacity requirements, which functions to collect data about real-time or upcoming capacity requirements. Data can be collected from call request queues, from storage history regarding capacity requirements, current load of telephone resource clusters, data from application analysis, or any suitable information source that predicts capacity requirements. The data from the call request queue may provide information such as the number of pending call requests, the type or details of the call request, or any appropriate queue-related information. The stored capacity history preferably provides insight into capacity patterns, such as time patterns throughout a day, week, or year. The current load of the telephone resource cluster preferably provides information such as the current number of resources of the telephone resource, the number of available resources of the telephone resource, the division of resource types, the number of de-allocated resources, the number of telephone network channels, and so on. The application analysis data is preferably data from the user's phone application for expected or predicted capacity requirements. It is preferable to perform analysis on the operation of the application, and/or collect from the user the expected capacity requirements of the application such as the number of calls, peak call time, call type (for example, conference call, SMS information, etc.). The analysis information is preferably used to control the supply, allocation, and deallocation of resources in step S120. In addition, after analyzing the capacity requirements, it is preferable to notify other components of the system, such as telephone resource clusters, telephone resources, call queues, dequeues, and resource allocators. Analysis information. Specific analysis information can be sent specifically to the component. For example, load balancers and dequeues are preferably notified of available resources and adjust operations according to the capacity information.

[0041] Step S130, which includes creating a first call session from the call request through the phone resource, and plays the role of using the phone resource to convert the call request into a call session. Step S130 preferably additionally includes additional processing and steps specifically for a specific application. In a preferred variant, as part of step S140, the call router preferably processes the call instruction of the call request to identify the target phone number, and then establish a connection to the target phone number. The transcription server can start recording or prepare to record the conversation of the call session

[0042] Step S140, which includes multiplexing the call session and a plurality of other call sessions to the telephone channel, which plays a role of establishing a telephone network connection to the telephone device. The telephone channel is preferably a PSTN (Public Switched Telephone Network) connection. This can be a physical line connected to the PSTN or some docking infrastructure. In some cases, the concept of channels is preferably used in or borrowed from the telephone network. In an alternative, the SIP (Session Initiation Protocol) information path can be used as an Internet-based gateway to the telephone network. The multiplexing preferably occurs in the form of time division multiplexing, where call sessions are connected to telephone channels in an alternating manner. Time division multiplexing is preferably based on the completion of a complete call session. For example, a specific network channel may be first used for the call session of the first user, and when the call is completed, the specific network channel may be used to establish a second call session for the second user. As part of step S140, the telephone channel may additionally include a step S142 of supplying a telephone channel. This serves to adjust the amount of telephone network capacity available to the system. By supplying a gateway (for example, a call router or SIP message path) to the telephone network, it is possible to allocate or deallocate a channel or a gateway to a channel. This expansion and contraction of telephone network channels allows operation near current telephone network capacity requirements. If this scalability is not used, there will be a trust that can be used at the same time. Set limit on the number of channels.

[0043] 3. Method of operating a dynamic telephone network

[0044] As shown in FIG. 6, the method 200 for providing a telephone network of the preferred embodiment includes running a method with a static number of

The step S210 of the telephone network of the channel, the step S220 of providing access to the telephone network channels of multiple users, and the step S230 of managing the use of the channels to allow the users to access more than the number of channels in normal operation. This method serves to allow the operator of the telephone network to provide high capacity to multiple users without degrading the quality or reliability of the service based on usage. The method is preferably implemented on a system substantially similar to the one described above, but any suitable system may alternatively be used. This method can additionally be used in combination with the methods described herein. The method 200 also serves to allow users to use the telephone network without having to be particularly concerned with the number of channels required for operation. Telephone network users preferably run telephone applications, such as call centers, internal branch exchanges (PBX), phone trees, telephone handset applications, VOIP services, SMS or MMS services, and/or any appropriate telephone applications. The operator of the telephone network is preferably a telephone service provider, such as a telephone platform provider (for example, an Internet telephone platform provider), a telephone company (for example, a telephone network owner such as AT&T), and/or any appropriate party. In a variation of this preferred embodiment, the method 200 may additionally include the steps of a distributed call controller, a call queue, and/or an assessment of capacity requirements.

[0045] Step S210, which includes operating a telephone network with a static number of channels, plays a role in providing users with basic infrastructure for telephone network access. The static number of channels is preferably the total number of simultaneous telephone sessions or calls that can be supported at one time. The number of channels is traditionally limited by the number of interconnections available for a particular carrier or network. However, the telephone network may be composed of multiple carriers or network providers or a public switched telephone network, and multiple carriers or networks are preferably managed or processed as one telephone network. The static number of channels is preferably a set number for a period of time (usually based on a contract with the telephone company), and the number is preferably large enough to provide sufficient capacity. The static number of channels is preferably an indication of the network capacity and the ability of the telephone network to connect to other networks. The operation of the telephone network is preferably handled by providing users with access to the telephone network's channels. The telephone network can have a given number of unused channels at any given time. In a variant, the telephone network can alternatively operate unused channels in an unused mode. The unused mode may be a full or partial hardware power-down mode, a hardware sleep mode, auxiliary use (such as for non-critical use that can be interrupted preferably with minimal negative impact), and/or any suitable method. The unused mode can play a role in reducing operating costs and/or maximizing utilization of unused capacity.

[0046] As another alternative to the preferred embodiment, the method may include a step S212 of operating a distributed call controller as a subset of the telephone network. If multiple network providers or carriers are used, the distributed call controller can alternatively be a subset of multiple telephone networks. The operation of the distributed call controller preferably functions to operate the number of channels allocated for the current capacity requirements of the telephone network. The capacity of the distributed call controller is less than or equal to the static channel capacity at any given moment. The capacity of the distributed call controller can preferably be increased by allocating more telephone network resources to the call controller, and the capacity of the distributed call controller can preferably be reduced by de-allocating the telephone network resources. It is preferable to facilitate access to the telephone network through virtual hardware or software (such as a call router or SIP information channel). The allocation of more resources of the telephone network may additionally include the virtualization of devices connected to the telephone network. For example, the virtualization of the network access channel can be increased to further increase the access capacity of the telephone network. As another example, during periods of high capacity demand, commercial hardware nodes can be added to the phone network to run the phone software stack.

[0047] Step S220, which includes providing telephone network channel access for multiple users, plays a role in allowing multiple different parties to access the telephone network channel. The user prefers to subscribe to the service of the telephone network operator. Users of the telephone network preferably run telephone applications, such as call centers, internal branch exchanges (PBX), telephone trees, interactive voice response (IVR) applications, Internet telephony applications, VOIP services, and/or any suitable telephone applications. The user preferably does not subscribe to the service based on any specific number of channels. From the user's point of view, the number of channels is preferably unlimited or an issue not related to the user's application operation. When operating the telephone network on a per-channel basis, it is preferable to present each use or time situation to the user

Π/14 pages (for example, pricing and/or application usage). The operator of the telephone network preferably converts the costs associated with the operation of the telephone network (for example, the cost of fixed assets or operating costs leased from the telephone company) into variable costs for users. It is preferably operated on a per-channel basis, leased access to the telephone network, and/or in accordance with a contract with a telephone company (such as AT&T) regarding access to the telephone network. A lease agreement or contract can alternatively be negotiated to minimize the cost of each channel (capacity), with an emphasis on usage or time-based costs, or alternatively any suitable lease agreement or contract can be used. The user preferably pays for use, a flat rate for a period of time, a combination of minutes, use and time fees, and/or any appropriate pricing model.

[0048] Step S230, which includes the step S130 of managing the use of channels to allow users to access more than the number of channels in normal operation, to provide users with high-capacity capabilities and ensure that the quality and reliability of the telephone network are not affected by other users. Negative effects of use. It is preferable to allow a single user among the plurality of users to use several channels evenly allocated among the plurality of users by a static number larger than the channel. The total number of the maximum number of channels used by a single user at a given time may preferably be greater than the static number of channels. A given moment when a single user can access the maximum number of channels is preferably when other users have low demand on the telephone network. The use of telephone networks and telephone resource clusters is preferably time-based multiplexing based on the completion of telephone conversations (ie, users share resources and use of the network). In a simplified example, the telephone network has 10 channels available and 5 users. When evenly distributed, users will each have 2 usable channels, but in a preferred embodiment, assuming that no other users are using these channels, all 5 users can each access up to 10 channels. During the normal use of the telephone network, the user still has the ability to access the maximum number of telephone network channels, but it is preferable to gate call requests through user restrictions imposed by the call queue. In another example extended on the above example, the analysis can point out that 4 users can use 2 channels at a given moment, then the fifth Users can use 8 channels while maintaining available capacity for the first 4 users. The use of the management channel preferably includes the use of management resources, such as by: managing call queues, performing user restrictions, predicting and/or analyzing usage and capacity requirements, adjusting capacity based on the capacity of the distributed call controller, and/or any appropriate The steps of managing telephone network resources. The capacity of the distributed call controller can be controlled or changed in addition through prediction and analysis, and the user limit can be changed in addition.

[0049] The method of the preferred embodiment may additionally include a step S232 of managing a call queue of requests from multiple users_OStep S232 plays a role of arranging the priority order of the processing of the call request from the user. The call queue is preferably a program or hardware managed stack that runs as part of the control architecture of the telephone network. The control architecture preferably manages the use of the telephone network and multiple users. The call queue is preferably a list of call requests waiting for telephone network services, including telephone voice session requests and/or SMS/MMS information requests. The request is preferably served at a rate suitable for the current capacity of the network and each user. The service rate can alternatively be adjusted according to the capacity of the distributed call center or the number of requests in the queue. When the capacity is exceeded, the user request is preferably placed in the call queue, or alternatively for each request or based on any appropriate rules. The user preferably has related user restrictions, in particular: call rate limit (throttle) and total limit (maximum limit). Throttling and ceiling are preferably used to determine the position of the request in the call queue. Preferably, the requests from the users are arranged in the call queue at a certain time interval according to the throttle amount. The requests of different users are preferably ordered in a staggered or alternating manner as shown in FIG. 6 in the queue, but alternatively, users may have priority based on a service plan, a first-come first-served strategy, and/or any appropriate strategy. The maximum limit is preferably a limit on the total number of requests that a user can make in a given time. Preferred According to the maximum limit, subsequent requests are scheduled at a later time, but requests that exceed the maximum limit can be processed in any appropriate manner. For example, if the user makes one call every second, and the user requests 100 calls,

They will be evenly scheduled for the next 100 seconds. Note that this maximum limit can be described as the number of calls/time frame (1/second), or the waiting time (1 second) required between calls in the queue. User restriction, processing, arranging at certain intervals, and/or ordering of call queues serve to prevent a user from unfairly occupying the use of the telephone network at any time. In the modification of SMS/MMS information request, the rate of a single user is considered to prevent information filtering by the network. For SMS/MMS variants, requests can be queued in the control queue and phone number queue in addition. The content of SMS/MMS information is preferably stored, and the number of the information content is queued, which plays a role in reducing the load on the queue. Preferably multiple cache service ports or pointers are used. The service port is preferably a software and/or hardware control mechanism for running call requests from the call queue. The service port preferably takes the request from the call queue and connects the corresponding user application or user to the telephone network channel. The service port may be a direct connection, but may alternatively be a hardware or software resource such as the call router in the cluster described above. The service port is preferably less than the static number of channels to allow capacity for incoming calls, but the service port may alternatively be equal to the static number of channels. There are 1000 telephone networks in one In the example of the network channel, there can be 500 service ports. This will reserve 500 channels for incoming calls. In addition, the user can request access to phone resources as soon as possible or at some time in the future (for example, the user schedules a call or makes a call at a later time). The queue popper is preferably a software or hardware mechanism responsible for selecting calls from the call queue for service. In addition, there can be multiple queue poppers that select calls from the queue. Additionally or alternatively, user restrictions can be adjusted or set according to user needs. Users can have special requirements based on the type or characteristics of user applications. The user limit is preferably set according to the contract and/or pricing model selected by the user or any suitable way.

[0050] The method of the preferred embodiment may additionally include a step S234 of predicting the capacity demand of the distributed call controller. Step S234 functions as an evaluation indicator related to the number of telephone network channels required at a later time. The current and past information are preferably analyzed (through pattern detection or any appropriate algorithm) through programs or mathematical methods to complete the prediction of the capacity, but any appropriate method may alternatively be used. It is preferable to find out related to time of day, day of the week, annual pattern, usage pattern (such as if an increase in capacity required by one user indicates an increase in capacity required by other users), call location, call time of the call, and/or Any appropriate indicator of the capacity demand pattern. The prediction of step S234 may be additionally used for real-time provisioning, de-provisioning, and/or additionally configuring the capacity of the distributed call controller or planning the capacity demand of the static capacity of the telephone network.

[0051] The method of the preferred embodiment may additionally include the step S236 of responding to the capacity demand of the call queue. Step S236 functions to use the call queue and other current capacity indicators to adjust the current capacity demand or the expected near-term demand for distributed call control The role of the device. The call queue is preferably evaluated by software or alternatively by any suitable monitoring of the call queue. The current number of calls in the queue, the total number of users currently using the telephone network, incoming calls (which may not be queued), the frequency of user requests, and/or any suitable characteristics of the telephone network or call queue preferably cause a demand for capacity reaction. The response is preferably directed to the current full capacity demand, but may alternatively be directed to the current capacity demand of a single user or any appropriate party. The response may include adjusting the settings of the call queue (such as call queue service rate or ranking), changing user limits, adjusting the capacity of the distributed telephone controller, and/or any appropriate action. In one example, the call queue may have many calls scheduled 100 seconds after the current time, and the distributed call controller may increase the capacity to accommodate the predicted capacity demand.

[0052] The method of the preferred embodiment may additionally include the step S238 of analyzing the capacity demand of the user and predicting the capacity demand of the telephone network. Step S238 functions to detect a single capacity requirement to determine the total capacity requirement of the telephone network. The user's capacity requirement is preferably obtained by analyzing the user's phone application. Part of the analysis preferably includes detecting periodic events that indicate the capacity needs of individual applications. An example of such an event could be an application related to the weekly TV show

Use, where the calling party makes a call before and after the start time of the program. The analysis may alternatively or additionally include detecting the typical call duration of a single application. Some applications may only use a short time (such as when a short message is playing), while other applications may require a longer duration of use (such as when the user has to navigate a long phone tree). In addition, the application history can be used to determine usage patterns, such as by monitoring the maximum, minimum, and/or average capacity requirements, the frequency of requests, the duration of the requests, the number of SMS messages sent during a specific time period, and/or any Appropriate call characteristics. It is preferable to combine the usage characteristics of a user's single application with the usage characteristics of other users to determine the total usage characteristics and capacity requirements of the telephone network. Preferably, the application code is preferably analyzed to evaluate the functionality and usage patterns of the application. The application code or operation is preferably programmed to analyze, but any suitable method can be used. Alternatively, the user and/or the second party may characterize the user's application and/or telephone service. This feature description is preferably performed by the user when signing up, and preferably includes user expectations for frequency of use, number of uses, call duration, and/or any suitable characteristics of the application. When the capacity used for its application will be the highest, users can additionally prioritize. Any appropriate steps can be used to analyze a single application.

[0053] As another alternative to the preferred embodiment, the method may include a step S240 of adjusting the capacity of the distributed call controller. Step S240 functions to change the number of active channels of the telephone network to appropriately handle the capacity demand. Step S240 is preferably used in combination with step S212, which includes controlling the distributed call controller. The adjustment of the distributed call controller adjusts the capacity provided by the operator. The capacity is preferably adjusted based on the usage management of the channel of the telephone network. It is more preferable to adjust the capacity based on the prediction and analysis of step S234 and/or S236, but may alternatively cooperate with step S232 and step S238 to adjust the capacity, and/or adjust the capacity for any appropriate reason. When more capacity is required, more resources such as CPU, RAM, DISK, etc., which can handle synchronous channels or provide more channels, are preferably allocated to the distributed telephone controller, and conversely when less capacity is required, The resources are preferably deallocated from the distributed telephone controller. The capacity adjustment is preferably made to handle the expected or predicted capacity. The static capacity of the telephone network can be adjusted alternatively or additionally. Because the capacity of the telephone network is generally not very flexible. The telephone network capacity is preferably adjusted for long-term capacity requirements (for example, on a monthly basis). Any appropriate adjustments to more or less capacity of the system can be used alternatively.

[0054] 4. Method of distributing calls among telephone hardware

[0055] As shown in FIGS. 7-8, the method 300 for distributing calls among telephone hardware of the preferred embodiment includes a step S310 of queuing call requests, a step S320 of selecting a load-balanced call router, and connecting the call with the selected Step S330 where the call router is connected. This method serves to balance the use of resources used in phone applications. The method is preferably implemented on a system substantially similar to that described above, but any suitable system may alternatively be used.

[0056] Step S310, which includes queuing the call request, manages the call request until the necessary resources are available to service the call. The call request is preferably an example of a phone application, a call router, a phone device, and/or any appropriate call request source. The call request may additionally be an SMS or MMS information request. The call request is preferably outgoing. Incoming calls are preferably regarded as more urgent call requests than outgoing calls, and the incoming calls may not be queued, but may alternatively be passed directly to the available resources. Alternatively, incoming call requests (call session initiation) can be queued, but because incoming calls have more urgency, they are preferably given priority or the system must have a shorter waiting time in line, where the shorter waiting time is less than The time it takes for an incoming call to fail. The incoming call can alternatively be placed near the front of the queue, or placed in the queue according to a unique rule suitable for higher priority of the call request. Similarly, high priority queuing can be used to synchronize outgoing call requests. A synchronous call is another caller is relying on to continue

The call being made is as opposed to a new call initiated by an application that the user will be unaware of the delay. The call requests may preferably be sorted in the queue according to rules based on throttling, ceiling, real-time urgency (priority) and/or any suitable factors.

[0057] Step S320, which includes selecting a load balancing call router, plays a role in identifying a call router that can handle calls to preferably optimize the operation of the telephone resource cluster. The selected call router is usually the one with the smallest load, but can alternatively be selected to optimize cost, energy usage, processing power, and/or any appropriate variables. Step S320 may be additionally applied to other hardware or software resources in addition to or alternatively in addition to the call router. The call router of the telephone resource cluster may have variable capacity and performance depending on the hardware and/or software specifications. It is preferable to consider the difference between a plurality of call routers when selecting a call router. A load balancer similar to that described above is preferably a component that implements step S320, although step S320 can be implemented by any suitable device. The load balancer is preferably able to allocate and deallocate resources of the cluster, and therefore can allocate and/or deallocate resources as a substep of S320. The resource allocator can preferably allocate and deallocate call routers, hardware resources, and/or software resources. It is preferable to allocate or deallocate resources based on current or predicted usage, but can alternatively allocate or deallocate resources as a function of other resources. For example, one media processing resource can be allocated (for example, run) to every five call routers. The selection of the load balancing call router preferably utilizes data from the analysis system. Therefore, choose The step of selecting a load balancing call router may include selecting a call router that will balance the load in the future.

[0058] Step S330, which includes connecting the call to the selected call router, and plays the role of transferring control of the call to a specific resource. For outgoing calls, the calling router is preferably connected to the designated telephone number through the telephone network. For incoming calls, the call router is preferably connected to a specific telephone application; PSTN connected devices, such as land lines, cellular phones, satellite phones, or any other suitable PSTN connected devices; non-PSTN devices, such as network ( V0IP) telephone, SIP device, Skype, Gtalk, or other Internet addressable voice device; and/or any suitable device associated with the number of the incoming call.

[0059] The method of the preferred embodiment may additionally include the step S340 of networking a call router with a shared application. Step S340 functions to allow communication between multiple call routers. This is preferably useful when the functions of the application are distributed to multiple resources (eg, multiple call routers). The network preferably allows sharing of resources between call routers. It is possible to additionally mix and share the audio channels of the call routers between the call routers. The VOIP channel is preferably formed on a network that bridges the audio of different call routers. For example, a conference phone can use the network to bridge multiple call session audio from different call routers.

[0060] The method of the preferred embodiment may additionally include a step S350 of synchronizing the application with the service application. The service application plays a role in monitoring the applications distributed on the call router cluster and coordinating the operation of the applications. Service applications can additionally be used to share state information between call routers. The service application preferably provides specific functions such as the on-hook service or the multi-input service described above. Any suitable application can be implemented through service applications such as input aggregation, multiple dialing, call splitting, call merging, and any suitable features. Any number of service applications can be used.

[0061] As a person skilled in the art, it can be understood from the foregoing detailed description and from the drawings and claims that the preferred embodiments of the present invention can be modified and changed without departing from the present invention defined in the following claims range.