CN103155606A - Dynamic call routing for real-time handling of inbound voice calls on mobile phones - Google Patents

Abstract

A method for processing each received inbound call by a mobile telephone, the method comprising: causing an option to accept the inbound call at the mobile phone and one or more other options to determine how to handle the call to be selectable by a user of the mobile phone when the inbound call is received by the mobile phone; and processing the inbound call as determined by the user selected option. The one or more other options may include: sending the caller to a voice mailbox; providing a fax receiving service; routing the call to a conference bridge; routing the call to another phone number; routing the call to an operator; and/or route the call to a VoIP or instant messaging address. The user may utilize the application to provide different ones of the one or more options.

Description

Dynamic call routing for real-time handling of inbound voice calls on mobile phones

Contents of the invention

A method, computer system, computer program product, telephony application, and user interface for managing inbound calls for a mobile phone user when a phone call is received. It provides mobile phone users with features only available to landline phone users, such as "caller ID with name". It also provides features not currently available on mobile phones, such as receiving faxes, conference calling for large groups, making office, home or other calls if the mobile phone user wants to answer a call on another phone, or VoIP (Voice over IP) client for mobile phone calls. It also enables the recipient of a phone call to decide in real time how to handle the incoming call—going to an office or home phone, an assistant, an answering system, a fax machine, a call blocking message, a VoIP client, an instant messenger client, a conference calling system, or a telephone Any other options available to the recipient of the call. This not only provides the call recipient with the ability to set up call routing and filters before accepting the call, but also the ability to decide what to do or where to route incoming mobile phone calls when the call is accepted based on: Call recipient location, time of day, access to other phone systems, availability, access to options for how incoming calls are handled, and types of calls accepted. Methods of choosing how to accept calls include, but are not limited to, SMS text messages, WAP (Wireless Access Protocol), any IP (Internet Protocol) connection, and voice commands.

The list of options available to the user is outlined elsewhere in this document and may include answering the call, rejecting the call, sending the call to voicemail, blocking the call, routing to any number of other phone numbers or phone endpoints , such as IP phones, IP clients (e.g., Skype, MSM Messenger, Office Communicator, SIP clients, etc.), playing custom or predefined messages, ringtones or ringback tones, songs, Interactive Voice Response (IVP) systems, or Any other voice, messaging, or data application to which the user wants to route inbound calls. A unique aspect of this approach is that the user is able to choose in real time how to route the call when the call is received and is not limited to the traditional answer and reject (send to voicemail) options available on mobile phones today. Thus, the number of applications, features and functions that can be created and utilized by users is virtually limitless.

Additionally, this enables an "app store" to aggregate and sell private and third-party applications that users can browse, select, purchase, and use to handle their inbound phone calls. These options and features can be used by any user of any handset and using any carrier, as the service can be used to handle any inbound call regardless of the provider of the telephony service.

overview

Particular embodiments relate generally to wireless communication systems, and more particularly to systems that enable a recipient of a voice call, upon receipt of an inbound call, to choose in real time how to handle the call. Particular embodiments may use cloud telephony services, which are communication services residing in hosting devices of service providers offering such cloud telephony services. Cloud telephony services can provide call forwarding, simultaneous and sequential making of multiple calls, bridging to traditional public switched telephone network (PSTN) endpoints and VoIP or instant messenger voice clients, two-way SMS relay, group messaging, faxing, Conference calling and other telephony-related services.

Cellular telephone communication services provide users with the convenience of being able to receive telephone calls on wireless devices at any time regardless of their location. However, inbound calls must be answered or sent to voicemail. Additionally, if the call recipient's wireless device does not have the caller's phone number and name stored in the wireless device's address book, the call recipient's wireless device cannot determine caller information, such as name or address, because mobile The telephone network sends the wireless device only the caller's phone number and not the caller's name. The call recipient thus only has the option of answering the call to find out who the caller is or sending the caller to voicemail and expecting the caller to leave a message with the name and reason for the call. These limited options result in the call recipient having to answer the phone, only to find out that the caller is a telemarketer, bill collector, or other caller that the recipient does not want to speak to or waste minutes of their limited voice plan on. Other unsatisfactory options are placing calls to voicemail, only to be discovered later by the called party that the caller should have been answered, for example, by a courier company wanting to locate the called party or from Important customer for the phone number in the address book of the called party's wireless device. If the calling party does not leave a message, the called party cannot easily determine the calling party's identity without calling back the number. Even worse, in situations where the calling party's phone number requires an extension to reach the individual making the call (for example, when the calling party's phone number is a large corporation's 1-800 toll-free number or if the calling party is from a extension number to reach a specific individual's company with a private branch exchange (Private Branch Exchange) or virtual PBX), the called party cannot easily return the calling party's phone call.

Therefore, the solution requires the called party to know the name of the calling party and the called party to be able to decide whether to connect to the calling party before the calling party hangs up. Depending on the calling party and the nature of the call, the called party may also choose to have the calling party sent to voice mail, a fax receiving service, a conference bridge, or another telephone number such as a land line or an administrative assistant or corporate operator. This enables the called party to use the called number not only for calling features outside of normal telephone calls, but also for other services of the called party's choice. Particular embodiments allow a called party to choose how an inbound call is handled and routed when the inbound call is received.

Functional description

Specific embodiments may use Conditional Call Forwarding (CCF), which enables the called party to receive an inbound call and the called party does not recognize the calling party's phone number displayed on the phone or if the called party To choose to route that inbound phone call to a different phone or service, tap the End or Decline button on the phone or the equivalent icon on the phone screen. Clicking "End" or "Reject" will stop the called party's phone from ringing and instead route the call to a CCF phone number, address or service.

Particular embodiments set the CCF number to a phone number or an IP-accessible address (such as a Session Initiation Protocol (SIP) address such as voicemailmobilecarrier.com) provided to the called party through a service or product. The CCF number may be a single phone number or address provided to multiple customers of the service, or a phone number or address unique to each customer again provided by the provider of the service or product. When an inbound call is routed to the CCF number provided by the service, the inbound call is routed to the server of the present embodiment to handle the call. The call may ^be made with the caller including the caller's The call information of the phone number, the called party's phone number or dialed number, and the CCF phone number are received together as Time Division Multiplexing (TDM) VoIP. For example, this embodiment may be an Asterisk, SER, Kamailio, OpenSER, FreeSwitch, or other VoIP routing, signaling, and application server with an associated Direct Inward Dial (DID) number associated therewith (for the purposes of this document, collectively referred to as the servers or services of the embodiments). This CCF number can be programmed on the called party's phone to divert all busy and unanswered calls to the DID which routes the call to the VoIP server. The CCF can be set on each mobile phone by calling the customer support of the operator providing service to the called party. Some mobile phone operators also enable customers to set CCF by setting calling or forwarding preferences themselves on the called party's phone. With some carriers, the called party also has the option of dialing a special dial code to set up the CCF on their own phone. Some examples of CCF setup dial codes for some US carriers are given here. They may change over time, but can be obtained by calling the respective carrier's customer service.

Alltel *7<CCF number> [then click send/call]

AT&T *004*<CCF number># [then click send/call]

Cellular South *76<CCF number> [then click send/call]

Cincinnati Bell *004*<CCF number># [then click send/call]

Cox Digital Phone *92<CCF number> [then click send/call]

Cricket *74<CCF number> [then click send/call]

MetroPCS *74<CCF number> [then click send/call]

Sprint *28<CCF number> [then click send/call]

T-Mobile *004*<CCF number># [then click send/call]

Alternate T-Mobile *004*<CCF number>*ll# [then click send/call]

US Cellular *74<CCF number> [then click send/call]

Verizon *7<CCF number> [then click send/call]

Note that the above is the CCF forwarding to the phone number CCF service via the phone number associated with the CCF server. Alternatives to this include forwarding to the CCF service via VoIP by using the VoIP address of the CCF service, eg ccfsip.3jam.com or other VoIP identifier that routes the call to the corresponding CCF service.

When the server receives an inbound telephone call, the server determines whether the called party's telephone number is a qualified telephone number for the service offered by looking up the customer configuration information in the server's information database along with a business logic algorithm. Causes the called party to play a message if the called party's phone number is not a service-qualified or specified phone number. The message may advertise the service, inform the caller that the called party cannot receive voicemail, or any other message that the provider of the service deems appropriate. Optionally, the service provider may allow callers to leave voice messages. Called parties may also be notified via manual or automated telephone calls or text messages initiated by the service provider to notify the called party that the caller has called and to provide information on how to obtain service or to listen to voicemails left by the caller Information about the message, if such a voice message exists.

If it is determined by looking up the customer configuration information in the server's information database and business logic algorithms that the called party's phone number is a qualified phone number provided by the service, the service can play a ring tone to the calling party in order to simulate dialing the called party's phone number phone call. Optionally, the service may play a message to the calling party informing the calling party that the called party is being located. The message may also instruct the caller to press a number on the caller's phone to leave a message immediately, to press a different number to join a conference call, or to press another number to send a fax, and then to begin a ring tone to indicate The system is dialing the called party's phone. There are many different options that may be presented to the calling party based on a configurable set of options determined by the called party before the calling party places the call to the called party. This service embodiment can also be implemented so that a calling party can select an option based on speaking the option, and the service can perform speech recognition to explain the caller's selection. While the calling party is waiting for the called party to pick up the call or specify an action, the call's inbound call leg on the server will wait to be notified of the next action to be taken on the inbound call. During this time, while the calling party listens for messages, ring back tones or advertisements, the server may also listen to detect fax tones or other digital requests from the calling party. For example, if an Asterisk 1.6 server is used as part of the service implementation then NVFaxDetect, NVBackgroundDetect, the yes option in Asterisk' faxdetect=sip.conf, or another fax service can be used to detect faxes in the background. A server invoked by an inbound call leg may set a database row or memory location unique to that caller, called party, or inbound call, and poll for that action (eg, query that database row or memory location). The called party's response will include information to update the database or memory location with the user's actions for that particular calling party, called party or call. The server can also wait for notifications via a SUBSCRIBE-NOTIFY type service or an exception-based notification system, such as an administrator interface or a Command Line Interface (CLI). In the case of an Asterisk server, the server can poll the database using an Asterisk Gateway Interface (AGI) script to invoke the DATABASE GET command to check whether the called party has responded with the desired action, or an incoming call received by the server. A station action can call the Asterisk Administrator Interface (AMI) or a CLI command to the Asterisk server to perform that desired action on a phone call that is currently awaiting an action from the called party.

When the calling party's options menu and ringtones are presented to the calling party, the calling party is searched through public or private lookup services and databases such as the Calling NAME (CNAM) service (for example, from http://www.asteriskcnam.com, http://www.asteriskcnam.com, http:// www.cnam.info, http://www.voipcnam.com or http://wholesale.metrostat.net), Local Exchange Routing Guide (LERG) (for example, from http://telcodata.us ), white pages (for example, http://www.whitepages.com ), country, region or other reverse lookup databases or online address books of called parties or customers who opt-in to share their data with other users Customers of the collective service search in the online address book, and the server of the service performs both a caller ID name and an address or location lookup on the calling party's phone number. After this lookup is done, the server of the service is requested for the caller's ID via a pull or push mechanism, such as SMS text messages, push notifications, HTTP long polling, HTML5 notifications, or via the called party's phone. information, and then return the caller's information to the called party.

Information about the caller, such as the name, location of the calling party's phone number, or the actual geographic location of the caller, retrieved based on location databases, photos, social media profiles, etc., is then displayed to the called party on the called party's phone square. This information is also accompanied by options that the caller can use to choose how to handle the caller's phone call that is currently on hold on the service's server. These options may include answering the phone call, requesting the caller to leave a voicemail message, playing fax tones to the caller, blocking the caller's phone number and playing a call blocking message to the caller, routing the call to an One of several telephone numbers programmed, the call routed to a corporate operator, or any other service or telephone number determined by the called party prior to the call. Where the called party may enter a phone number not previously set up as an option for routing the call, the above options may also include requesting the called party to provide input as a response to the service.

Then, in order to send the selected option to the service, the called party may click on a Uniform Resource Locator (URL) or Uniform Resource Identifier (URI) link provided in the list of options displayed to the called party. The web server receiving the URL or URI matches the unique ID, caller, called number, or combination of data parameters of the URL or URI with the inbound phone call and updates the requested action for the inbound call. An example is where the server sends a URL action to the caller's phone based on a base62 encoded (a-z A-Z 0-9), 62*62 (0-9 a-z A-Z) combination of 2-character random hashes of the calling number to prevent attempts to guess Random malicious misuse of parties from the URL/URI, and a character representing the action (62 possible actions 0-9 a-z A-Z). The called party may also respond to the SMS or MMS message, push notification, or other action request using a native application on the phone or an application installed on the phone with a selected option. The response can include a number or character representing the option, the first letter of the option, a phone number not previously in the option list, a unique ID for an inbound call waiting on the server, or the user's desired Actions are combined with data matching inbound calls waiting on that server. The SMS text message response or Internet Protocol (IP) based click on the URL or URI can also be updated based on the most recent call waiting on the server to dial the called party number or based on the calling party number instead of the unique ID of the call The call action for an inbound call. This could result in a potential match of the desired action on more than one call, but the low probability of collisions, coupled with detecting and blocking brute force requests, may be enough to make this scheme feasible. The server receives the action notification and notifies the caller's inbound leg on the server by updating the memory or database location, which is polled once per second (either with the service or previously other periods that may be specified by the called party in the calling party's service preferences), or by writing to the server via the administrator port, the command line, or some other method of invoking the inbound call leg to notify an inbound call Leg to take subsequent actions based on the called party's response.

If the called party's response is to answer the call, when it is routed to the service's server, the caller's call is routed back to the called party's phone number based on the dialed number information accompanying the inbound call . If the called party responds by sending the calling party to voicemail, a voicemail greeting is played to the calling party, followed by the ability to leave a voicemail message. The voicemail greeting or system can also detect fax CalliNG (CNG) tones. CNG tones are the tones sent by a fax machine when it calls another fax machine. The half-second tone repeats every 3.5 seconds for approximately 45 seconds. If the server detects a CNG tone, the server will initiate a fax receive session with the calling party. If the called party responds by playing a fax tone to the caller, the server will play an inbound fax initiation tone to the called party to prompt the caller to begin fax transmission. This is necessary for some older fax machines that do not play CNG tones automatically but instead wait for the receiving side to initiate a fax session before starting the fax transmission.

If the called party responds by blocking the caller's phone number and a call blocking message is played to the caller, the caller will hear a message such as "The person you called is blocking you. Please hang up and do not call back." The blocked caller message may be predetermined by the called party prior to the call, or may be determined by the called party as part of the response to the server. The blocked call action can also direct the called party directly to voicemail, answer and immediately hang up the call, play a busy signal, play a phone number disconnect signal or other message, and a busy or disconnected tone in an attempt to make the blocked call Fang did not call back. The calling party's phone number will then be stored in the service's database such that subsequent calls to the called party's phone sent by the called party to the server via the end or reject key will immediately place the blocked call to the blocked party Instead of sending an SMS text message or push notification to the called party prompting the called party to choose an action.

Use Appropriate gateways and connection protocols route that caller's call to the appropriate phone number or service (such as a VoIP phone service or an IM address like Skype or Google Talk).

Some options, such as Block, when selected will trigger a secondary menu, pop-up menu, or set of options displayed on Called Party B's phone. The secondary menu may display another set of options detailing the selection. For example, for the blocking option, the user may be asked what message to play to the blocked party when the call is blocked. For the voicemail option, called party B may be asked what message to play to the calling party. Depending on whether the caller is a personal contact, a business contact, an anonymous party, or a nuisance caller, the called party B can select the message to be played to the caller. The decision is communicated back to the CCF server via data connection (HTTP or proprietary API call, etc.), SMS message, network call (SS7/PSTN/GSM/CDMA, etc.).

Other options may be to forward the call to another phone, computer or device. This can optionally trigger a secondary menu asking the caller which destination to forward the call to, it could be another phone number, long distance (international) number, voicemail, auto attendant, Interactive Voice Response (IVR) system , VOIP clients (for example, a SIP address like jonsip.msn.com or a client for Skype users), etc. This secondary option can be predefined by the user as a list of numbers from which to choose from the address book of called party B, or from an online address book such as Facebook's contact list, Google or Gmail's address book, Plaxo or other sources. options obtained. The application can download the online contact list before the phone call comes, when the call comes, or when the call is forwarded to the CCF service before routing the option back to the called party.

In an optional implementation manner of this embodiment, the above server function is performed by a telephone exchange connected to the PSTN. The telephone switch may or may not require conversion of inbound calls from TDM to IP to perform the functions described above. The telephone exchange may or may not perform this function by converting the outbound call to the called party's telephone from TDM to IP. The implementation of this embodiment using a telephone switch can provide higher performance and lower delay, because the service function can be more closely integrated within the telephone function of the telephone switch without relying on the telephone switch and external External servers for additional communication overhead between servers. This alternative embodiment could also be implemented with some functions handled by the telephone exchange and some functions performed by external servers.

Alternative implementations using call-in or pre-hangup mechanisms

On 2G or 2.5G wireless phones or wireless phone networks such as EDGE, the data connection on the mobile device is not available while an incoming call is being received (while the called party's mobile phone is ringing or while the call is in progress) Take advantage of. Where an access IP connection is available on the called party's mobile phone when a call is received (such as on a 3G network or when the phone has an alternative wired or wireless connection, such as 802.11 WiFi), the phone can use the IP connection to extract or retrieve information about the caller from the service, including but not limited to the caller's name, location, picture, etc. from the aforementioned private or public data resources.

In this case, this embodiment will enable the called party to keep the inbound phone call ringing on the phone if the called party does not answer the call. While the caller is still waiting for the called party to answer, the called party's phone uses IP-based requests, SMS messages, MMS messages, other forms of data lookup and retrieval, or a combination thereof, through a built-in feature or application on that phone, Retrieves information about the caller.

When the calling party's information is retrieved by this embodiment, that information is presented to the called party. The called party can then decide to take the call or route the call to the CCF number by clicking on a list of options presented by the phone's native function or application, or by replying to a text message or clicking on a URI or URL link or selector and service. If the called party decides to route the call to the CCF service, the inbound call will arrive at the service's server or switch at approximately the same time as the action notification from the called party. If the service receives an inbound phone call prior to notification of the user's action, the service may play a ring tone, some other custom or recorded message, or audio to the caller while the service waits for the inbound message for a predetermined amount of time to reach the service. If the service subsequently receives a message from the called party's phone informing the service of the called party's desired action, the service then uses the caller's phone number, the called party's phone number, the CCF phone number, and the A combination of the caller's action message or the clicked URL or URI's data matches the inbound call with the called party's action. If the service receives the desired action from the called party before the inbound call reaches the service's server, the service may hold the desired action from the called party for a predetermined amount of time (for example, 10 seconds), and when the inbound When the call arrives at the service's server, the called party's actions are matched against the inbound call.

The incoming call is then processed according to the desired action of the called party: routing back to the caller's phone, alternative phone(s), computer, voice mail, fax, conference call, or other service; The party is determined in the called party's preferences stored by the service, or in an action specified by the called party in the called party's message data, URL or URI received by the service.

If the service does not receive an action request from the called party within a predefined timeout, the inbound telephone call is directed to voicemail, fax, conference call, or a combination of services depending on the nature of the inbound call. While the service is waiting for the called party's request for action, the calling party may be presented with options to press a key on the calling party's phone or leave a voicemail via voice command, initiate a fax session, join a conference call, or Other possible options for configuration.

Alternative Implementation Using Cloud Phone Number Service

Where the user has a cloud phone number as the primary number (not a phone number traditionally associated with a dedicated physical device such as a single cell phone or a single mobile phone, but one that can be configured by the owner to dial when an incoming call is received When the caller calls the cloud phone number of the called party, the cloud phone number service can first use the cloud phone number to dial the called party's phone. The cloud phone number appearing on the called party's mobile phone will indicate to the called party that the calling party has dialed the cloud phone number instead of directly dialing the called party's mobile phone.

If the called party answers the call when the cloud phone number calls the called party's phone, the cloud phone number can be looked up first (LERG, CNAM, online address book, etc. as above) and the called party's name is told , location information, etc. The called party can then use voice commands or number keys on the phone to select options such as routing the inbound call back to the called party's mobile phone or other phone, fax, conference bridge, voicemail, etc.

If the called party does not answer the call when the cloud phone number calls the called party's phone, or if the called party uses the end or reject feature on the phone to send the inbound call to the CCF number, the call will be blocked Route to the CCF number. The inbound call will reach the service's server or switch via the CCF number and can be routed back to the called party's phone using the caller's caller ID number instead of the cloud phone number. The called party can then see the caller's phone number and can answer the call or use the end or reject function on the phone to resend it to the service via the CCF number. The service can detect if the same call is coming into the service's servers twice by keeping a real-time record of the calls in progress. If the same call is sent to the service twice, the service will know not to route the call back to the caller's phone but to route it to voicemail, fax, conference call bridge, or other service configured by the called party .

Optionally, the service may repeat the function of sending a message about the calling party to the called party's phone while putting the calling party on hold and playing a ring tone to the calling party (first with an optional instruction message). The called party can then route the inbound call waiting on the service to voice mail, fax, conference bridge, or other service configured by the called party. If the called party responds with an action and the calling party is still on hold, the service performs the called party's desired action on the inbound call. If the timeout period is exceeded while the calling party is on hold, the server can route the inbound call waiting on the service to voice mail, fax, conference bridge, or other service configured by the called party.

As an option for Called Party B's phone to ring when that cloud number is called, the Caller ID name and optionally a callee ID name that Called Party B can choose from can be sent before the call is routed to the Called Party's phone. Action options are sent to the called party's phone. When the call is sent to the handset, the caller information may be sent along with the caller ID name in the data header or data envelope of the phone call. This information sent to the handset may also include the called party B based on the mobile operator's stored preferences or a separate preference management server or portal (such as the one associated with the service provided by the service provider of the CCF server) being called Action options available to Party B.

When the call is sent to the phone of called party B, the cloud number operator of called party B can either in its own database, on the server of the CCF service provider, or in the server and database of the third party service provider An internal lookup is done to determine the caller ID name and other information (such as social network profile information, carrier information, photo, etc.) as well as preferences and forwarding options, and then sends this information to called party B's phone. This action option can be presented to the called party B's handset by the methods shown above and below (SMS, push notification, HTTP data connection, phone response, etc.) SMS, push notification, HTTP data connection, phone response, etc.) to receive a response from the called party.

When triggered by a push notification, SMS message, or application-generated pop-up menu that can display options and caller information in a more aesthetically pleasing and functional GUI that is triggered by the inbound call notification, action options and call When the caller's information (which may include caller ID name, social network profile information, carrier information, photo, etc.) , so that called party B selects the option in Quiet.

If called party B decides to respond with an action selected on the application's selection menu, the phone and application receive the user's selection and route the call accordingly. For example, if called party B selects the answer option, the phone simply routes the call to the called party's handset. If called party B selects the block option, the cloud service can bridge the call to an automated message that plays an audio message to the caller, such as "You are no longer calling this number" or "This line has been disconnected" or by Any other message as determined by called party B. The blocking option can also simply hang up the calling party, giving the caller the impression that called party B is unwilling to answer the call. The blocking option can also send a command to the cloud provider or carrier network to route the call to voicemail.

Some options, such as Block, when selected may trigger a secondary menu, pop-up menu or set of options displayed on the called party B's phone. The secondary menu may show another set of options detailing the selection. For example, for a blocking option, the user may be asked what message to play to the blocked party when the call is blocked. For the voicemail option, the called party B may be asked what message to play to the calling party. Depending on whether the calling party is a personal contact, a business contact, an anonymous party or a nuisance caller, the called party B can select the message to be played to the calling party. The decision is relayed back to the cloud number provider via data connection (HTTP or dedicated API call, etc.), SMS message, network call (SS7/PSTN/GSM/CDMA, etc.).

Other options may be to forward the call to another phone, computer or device. This can optionally trigger a secondary menu asking the caller which destination to forward the call to, which could be another phone number, long distance (international) number, voicemail, auto attendant, Interactive Voice Response (IVR) system , VOIP clients (for example, SIP addresses like jonsip.msn.com or Skype user clients), etc. This secondary option can be predefined by the user as a list of numbers from which to choose from the address book of called party B, or from an online address book such as Facebook's contact list, Google or Gmail's address book, Plaxo or other sources. options obtained. The online contact list may be downloaded by the application before the phone call comes, when the call comes, or when the call is forwarded to the CCF service before routing the option back to the called party.

Alternative implementation using a call-in number

When an inbound call from a calling party is received by the called party's cell phone and the called party sends the call to the CCF service's server, the server can send a text message or push notification back to the called party's cell phone . The message from the server may include a phone number that the called party can dial in using the called party's cellular phone. The phone number is the phone number that connects (also known as bridging) the called party to the calling party that is waiting for the called party to answer the call. The called party can also dial in to the service by calling the phone number from which the text message originates from the server of the CCF service.

The CCF server uses the caller's phone number (the caller's caller ID) and the dial-in number (the number dialed by the caller) to determine which waiting caller is connected to the caller. The following are examples of possible implementations.

1. When the calling party A calls the mobile phone of the called party B, the called party B sends the call to the CCF server by pressing the end, reject or similar function option or button on the cellular phone.

2. When the CCF server receives a phone call forwarded from caller A, when party B arrives, the CCF server plays a pre-recorded message asking party A to wait. The CCF server then plays ringback tone, hold music or other audio media to Party A's phone.

3. The CCF server uses the caller ID information for the call to the CCF server to store party A's phone number and uses information such as the diversion header (Diversion header) in the call protocol message (for example, a SIP message) sent to the CCF server. The phone number dialed (Party B's phone number). The CCF server may also store the phone number of the CCF server to which Caller A's call is redirected. A combination of one or more of these three pieces of information will be used to determine how called party B Connect (also known as bridge) to caller A.

4. The CCF server determines the phone number X that called party B must use to dial in to connect to calling party A. The phone number X may be one of one or more phone numbers used to enable callers to dial in to the CCF server. In the event that more than one call to called party B is sent to the CCF server at about the same time, having multiple dial-in numbers for selection may help the CCF server determine which calling party called party B is trying to connect to. The server may determine a different telephone number X for each calling party, such that for each calling party waiting to be connected to called party A, a different dial-in number X is associated with each calling party's call leg. This also makes it so that if called party B calls the dial-in number X1, called party B will be connected to calling party A1. If called party B calls the incoming number X2, called party B will be connected to calling party A2 and so on.

5. The CCF server can store phone number X together with calling party A's phone number, called party B's phone number, and calling party A's "call leg" information. The "call leg" information may include the CCF server instance where Caller A's call has been placed on hold and a unique identifier for the call that may be used to connect or bridge another call leg to the caller A's call leg so that the two parties can talk on the bridged call.

6. The CCF server sends a notification to Party B's cell phone via text message or push notification. After the call is sent to the CCF server, called party B's phone can also use the phone number used to identify calling party A, called party B's phone number, and, optionally, the A data connection requesting the login credentials of called party B to retrieve the information retrieves the information from the server. The message or information may contain Party A's phone number, caller ID name information, location, photo, and/or other identification related to calling Party A. In addition to the unique URL and text message response options described elsewhere herein, the message may also contain the phone number X dialed in by Calling Party B.

7. When called party B receives a message including dial-in number X, called party B has the option to dial that number from the phone. This dial-in step can be accomplished by called party B clicking on phone number X in a text message, manually entering phone number X into the phone, or clicking on an application on the phone that automatically dials phone number X. The application on the phone can analyze the message from the CCF server to determine the dial-in phone number, and can present the option to dial that number as a clickable pop-up menu option.

8. When the called party B's phone dials in to the CCF server using phone number X, the CCF server uses called party B's phone number (caller ID number) and phone number X to determine which calling party A to connect with. If the CCF determines that calling party A is still on hold, waiting to be connected to called party B, the CCF server uses the information stored by the server about party A's call leg ID to connect or bridge party B to party A's call leg. path and server. On an Asterisk system, for example, the bridge() command can be used to bridge an inbound call from party A to a waiting call leg from party B.

9. The two parties are now connected and can have a voice conversation normally. The benefit of party B calling in to connect to calling party A is that the method is more efficient than if called party B sends a request to the CCF server to dial out to called party B's phone to connect waiting party A to party B. faster and causes caller A to wait for a shorter period of time.

Alternative implementation using options stored locally on the mobile device

The alternative is to have the option to store locally on the app (this information could also be replicated on the server) so that the app doesn't need to receive all possible actions in push notifications or text messages sent from the server , but instead have options already stored on that phone. This way, when an inbound call is sent to the CCF server, the app on that phone can display to called party B the options for action that the CCF server can take on caller A's call based on settings and options configured locally in the app. The application does not need to wait for a message from the CCF server to display the option to called party B. The application can detect that called party B has declined the call or missed the call and use this to trigger the popup of the options menu. The application can also immediately query the CCF server or other third-party application for the caller ID name of the caller so that the caller's information, social network profile or picture can be retrieved for display to the called party. The phone may also display the information if the application has previously retrieved the information from the phone's contact list database or cached the information locally in the phone.

When the called party selects the desired action, the app can communicate the selection of called party B via a text message or with a pre-configured generic URL of the CCF service (or the URL can be part of the push notification and be specific to the call custom) data connection sent to the server, this option only includes parameters for this option. One embodiment of the URL and parameters may include 1) a desired action and 2) parameters for that action based on user configuration of options for using the application.

For example

http://r.3jam.com?callld=2aAGsll&action=voicemail

or

For example

http://r.3jam.com/?callld=2aAGsll&action=forward&device[1]=phone&parameter[1]=14158889900&device[2]=phone&parameter[2]=15109822211

or

For example

http://r.3jam.com/?callld=2aAGsll&action=forward&device[l]=skype&parameter[l]=my_skype_username

or

For example

http://r.3jam.com/?callld=2aAGsll&action=forward&device[1]=sip&parameter[1]=mysip.phone.com

This would also have the advantage of giving a virtually unlimited list of options based on supported CCF server actions.

For example

http://r.3jam.com/?callld=2aAGsll&action=block&parameter[1]=play_busy_tone

or

For example

http://r.3jam.com/?callld=2aAGsll&action=join conference call

The advantage of this embodiment is that the called party B does not need to wait for the server to send a message to the called party B's phone with the dialed number X or options available. Instead, called party B may send an action command to the CCF server immediately after the incoming call from calling party A is sent to the CCF server. The command can also be sent with a text message from the called party B's phone using SMS. The body of the SMS message will contain the action command which will enable the server to perform the desired action on caller A.

When the server receives an action command from called party B, the server will interpret the command and perform the action on calling party A.

In addition to the ways in which called party B can notify the server as described above, called party B can also select a desired action, and called party B's phone can reroute the call to the appropriate destination. In this case, the called party B's phone will send the desired action via SS7 and/or mobile (CDMA/GSM etc.) commands to the mobile operator's network equipment to reroute the call to that destination. In this case, the called party's mobile operator's network equipment and routing protocols will take the place of the CCF server to perform this action.

It has the advantage of a faster response time than routing the call to the CCF server which then routes the call to the destination. This also makes better cost sense, as larger operators, such as mobile operators, are able to achieve more economical voice termination rates compared to smaller entities and individuals. In addition, the mobile operator may choose to include rerouting as part of Called Party B's telephony plan instead of charging additional rerouting charges, thereby providing higher value compared to other mobile operator competitors. The advantage for this mobile operator is its ability to offload voice calls from the mobile network to landlines or VoIP clients, thus saving valuable wireless capacity on its existing spectrum, which is a limited resource and expensive to acquire .

Some options, such as Block, when selected may trigger a secondary menu, pop-up menu, or set of options displayed on Called Party B's phone. The secondary menu may show another set of options detailing the selection. For example, for the blocking option, when a call is blocked, the user can be asked what message to play to the blocked party. For the voicemail option, the called party B may be asked what message to play to the calling party. Depending on whether the caller is a personal contact, a business contact, an anonymous party, or a nuisance caller, the called party B can choose the message to be played to the caller. The decision is relayed back to the CCF server via data connection (HTTP or dedicated API call, etc.), SMS message, network call (SS7/PSTN/GSM/CDMA, etc.).

Other options may be to forward the call to another phone, computer or device. This optionally triggers a secondary menu that asks the caller which destination to forward the call to, which could be another phone number, long distance (international) number, voicemail, auto attendant, interactive voice Response (IVR) systems, VOIP clients (for example, SIP addresses like jonsip.msn.com or clients for Skype users), etc. This secondary option can be predefined by the user as a list of numbers from which to choose from the address book of called party B, or from an online address book such as Facebook's contact list, Google or Gmail's address book, Plaxo or other sources. options obtained. The online contact list is downloaded by the application before the phone call comes, when the call comes, or when the call is forwarded to the CCF service before routing the option back to the called party.

Alternative Implementation Using Caller ID Name Retrieval Before CCF Routing

This alternative embodiment presents the Caller ID name and, optionally, action options that Called Party B can choose from before the call is routed to the CCF server. When the call is sent to the handset, the caller ID name can be sent with the caller information in the data header or envelope of the phone call. This information sent to the handset may also include information based on called party B's stored preferences using the mobile operator or a separate preference management server or portal (such as the one associated with the CCF server's service provider provided service). Action options available to caller B.

When a call is to be sent to called party B's phone, called party B's mobile operator can either in its own database, on the CCF service provider's server, or in a third-party service provider's server and database An internal lookup is done to determine the caller ID name and other information (such as social network profile information, carrier information, photo, etc.) as well as preferences and forwarding options, and then sends this information to called party B's phone. This action option can be presented to the called party B's handset by the methods shown above and below (SMS, push notification, HTTP data connection, phone response, etc.) SMS, push notification, HTTP data connection, phone response, etc.) to receive a response from the called party.

Action options and caller information can be displayed in a more aesthetically pleasing and functional GUI via a push notification, SMS message, or pop-up menu generated by an application that is triggered by the inbound call notification. When the caller's information (which may include caller ID name, social network profile information, carrier information, photo, etc.) is presented to called party B's phone, the phone may ring automatically either by called party B or by the phone Quiet to have called party B select the option in Quiet.

If the called party B decides to respond with the selected action, the phone and application will act accordingly. For example, if called party B selects the answer option, the phone will simply answer the phone call normally. If called party B selects the blocking option, the phone can answer the call and an app on the phone can play an audio message to the caller, such as "This number you are no longer calling" or "This line has been disconnected." ” or any other message as determined by called party B. The blocking option can also simply answer and hang up on the call again, giving the caller the impression that called party B is unwilling to answer the call. The blocking option can also send a command to the CCF server or carrier network to route the call to voicemail.

Some options, such as Block, when selected may trigger a secondary menu, pop-up menu or set of options displayed on the called party B's phone. The secondary menu may show another set of options detailing the selection. For example, for a blocking option, the user may be asked what message to play to the blocked party when the call is blocked. For the voicemail option, the called party B may be asked what message to play to the calling party. Depending on whether the calling party is a personal contact, a business contact, an anonymous party or a nuisance caller, the called party B can select the message to be played to the calling party. The decision is relayed back to the CCF server via data connection (HTTP or dedicated API call, etc.), SMS message, network call (SS7/PSTN/GSM/CDMA, etc.).

Other options may be to forward the call to another phone, computer or device. This can optionally trigger a secondary menu asking the caller which destination to forward the call to, it could be another phone number, long distance (international) number, voicemail, auto attendant, Interactive Voice Response (IVR) system , VOIP clients (for example, SIP addresses like jonsip.msn,.com or clients for Skype users), etc. This secondary option can be predefined by the user as a list of numbers from which to choose from the address book of called party B, or from an online address book such as Facebook's contact list, Google or Gmail's address book, Plaxo or other sources. options obtained. The online contact list is downloaded by the application before the phone call comes, when the call comes, or when the call is forwarded to the CCF service before routing the option back to the called party.

Routing back to the phone through the VoIP client on the phone

Where the called party has a VoIP client on his or her mobile phone, one of the options presented to the called party may be to route regular mobile incoming calls to the VoIP client on the mobile phone. This enables the called party to save on incoming mobile phone charges by answering the call on the VoIP client rather than on the mobile phone's cellular network phone plan. VoIP calls are often free on certain networks and services, such as Skype or using a SIP VoIP client when using a WiFi or Internet connection. Another advantage of accepting calls on the VoIP client of the phone is to enable the called party to take the call when cellular coverage at the called party's location is spotty or non-existent. The called party can then connect to a local WiFi network or hotspot to accept the inbound phone call via the VoIP client.

In order to route an incoming regular cellular phone call to a called party's mobile phone to a VoIP client on that phone, 1) when the inbound call is received on the phone through an application on the phone, a call can be made to the called party The party presents this forwarding option, or 2) the called party can unconditionally forward the call to the VoIP client using settings on the inbound virtual number, CCF server, or the operator's mobile network. In both cases, a SIP PSTN gateway that interfaces with the Public Switched Telephone Network (PSTN) is used on one side to convert an inbound call from the cellular network to a VoIP call, and on the other side to convert a voice call to VoIP call. The VoIP call is then routed directly to the VoIP client on the handset if the handset client is a VoIP client capable of handling inbound calls directly from the PSTN gateway service provider or carrier network. Otherwise, the call can be routed to a server of the CCF service that can convert the call to a VoIP protocol that the handset's VoIP client can understand. This can be done with a translator and transcoder, such as a Back to Back User Agent (B2BUA) like Asterisk or FreeSwitch, to do the translation, or be routed to a network, such as Skype, if the phone is on The VoIP client is a Skype client. Other VoIP protocols, clients and services can also be used as long as VoIP calls routed to the phone can be sent in the correct format and protocol that the application on the phone can understand.

In order for the application on the phone to accept the inbound VoIP phone call, the caller's call can be routed to the CCF number and server by the operator and handset. There are several ways the call can be routed from there to the VoIP application on the called party's handset:

1) When the CCF server, mobile operator or cloud number service receives a notification from the called party's phone via HTTP, push or SMS response that he/she wants to accept the call through the phone's VoIP client, the CCF The server, mobile operator, or cloud number service can send a push notification or SMS message to the called party's phone, informing the VoIP application that an inbound VoIP call is about to arrive at the application.

2) If the app can be called by the inbound SMS or push notification, the app can be automatically woken up by the inbound notification and automatically answer the call. Otherwise, the inbound SMS or push notification can pop up on the screen of the called party's phone with the option to answer the call or cancel (or ignore) the call. Answering the call will cause the VoIP application associated with the push notification to be invoked when the user selects that option. The invoked VoIP application may immediately answer the inbound VoIP call or allow the user to choose to answer the inbound VoIP call after clicking a confirmation button in the VoIP application. In order for the VoIP server on the CCF server to be able to send a VoIP call to the called party's phone, the called party's phone will have to register with the CCF's VoIP registrar, providing the registrar with the phone's IP address and port number to register in its Send VoIP incoming signaling. This can be done through a Session Initiation Protocol (SIP) register command from the handset to the SIP server served by the CCF. Other VoIP protocols, proprietary or standards based, can also be used to inform the server how to send the VoIP call to the called party's handset. The VoIP application on the called party's handset can run in the background such that it routinely sends a registration message to the CCF server informing the server of the appropriate IP address and port number to which to send the VoIP call.

3) Alternatively, the VoIP application on the phone accepting the inbound VoIP phone call can instead connect to the VoIP server to be connected to the called party. This method eliminates network address translation (NAT) problems because the VoIP client of the phone will dial in and not be dialed. In this case, the calling party is routed from the operator and handset to the CCF server. The calling party is then put on hold or awaits an action by the called party. Push messages can make a bell ring like a phone, mimicking an inbound phone call. The push message will contain the routing address, which can be a SIP address or a phone number linking the call. This push notification or SMS is sent to the called party's handset, and when it is opened by the called party, the VoIP application is invoked. The VoIP application then dials in to the VoIP address contained in the push notification or SMS message (eg, SIP:119281717axl-Ahak2lsip.msn.com, if using SIP). The server dialed by the called party's VoIP application can determine which telephone call to connect or bridge the inbound VoIP call to so that the calling party's call is no longer on hold and is connected to the dial-in party. The address of a SIP INVITE may contain caller and calling party information, call ID, parking space and access, and a verification code to authenticate the request to connect to the called party that is currently on hold.

4) The VoIP application on the called party's phone can be a third party application such as Skype. In this case, acceptance of an inbound call request by the called party through an SMS, push notification, or HTTP request sent from the called party's phone to the CCF server can cause the CCF server to place the caller's call (currently on hold on the CCF server) Bridge to the server of a third-party application (for example, Skype). The call is then routed by the server of the third-party application (eg, Skype) to the client (eg, Skype) application on the called party's handheld device.

Route back to phone via IP connected device and VoIP client on computer

A situation where the called party has a VoIP client on a device other than a phone (eg, a computer or other IP-connected device, such as an iPad or other tablet computing device, referred to herein simply as a computer).

Where the called party has a VoIP client on his or her mobile phone, one of the options presented to the called party above may be to route regular mobile incoming calls to the VoIP client on that computer. This enables the called party to save on incoming mobile phone charges by answering the call on the VoIP client rather than on the mobile phone's cellular network phone plan. VoIP calls are often free on certain networks and services, such as Skype or using a SIP VoIP client when using a WiFi or Internet connection. Another advantage of accepting calls on a computer's VoIP client is that it enables the called party to take the call when cellular coverage at the called party's location is spotty or non-existent. The called party can then connect to a local WiFi network or hotspot to accept the inbound phone call via the VoIP client.

In order to route regular incoming cellular phone calls to the called party's mobile phone to the VoIP client on the computer, 1) the inbound call can be sent to the called party when the inbound call is received on the phone through an application on the phone party presents this forwarding option, or 2) the called party can unconditionally forward the call to the VoIP client using settings for an inbound virtual number, CCF server, or the operator's mobile network, or 3) the called party has An application (e.g., a desktop-based application or a browser-based application) that presents options to the user and when received on the phone or CCF server via push notification or HTTP long polling (COMET) The application is invoked when an inbound call is made.

In these cases, a SIP PSTN gateway that interfaces with the Public Switched Telephone Network (PSTN) is used on one side to convert an inbound call from the cellular network to a VoIP call, and on the other side to convert a voice call to a VoIP call. The VoIP call is then routed directly to the VoIP client on the computer if the computer client is a VoIP client capable of handling inbound calls directly from the PSTN gateway service provider or carrier network. Otherwise, the call can be routed to a server of the CCF service that can convert the call to a VoIP protocol that the handset's VoIP client can understand. This can be done with a translator and transcoder, such as a Back to Back User Agent (B2BUA) like Asterisk or FreeSwitch, to do the translation, or be routed to a network, such as Skype, if the phone is on The VoIP client is a Skype client. Other VoIP protocols, clients and services can also be used as long as VoIP calls routed to the phone can be sent in the correct format and protocol that the application on the phone can understand.

In order for the application on the phone to accept the inbound VoIP phone call, the calling party's call can be routed to the CCF number and server by the operator and handset. There are several ways the call can be routed from there to a VoIP application on the called party's computer:

1) When the CCF server, mobile operator or cloud number service receives a notification from the called party's phone or computer via HTTP, push or SMS response that he/she wants to accept the call through the phone's VoIP client, The CCF server, mobile operator, or cloud number service can send a push notification or IP-based message (using a program such as Growl) to the called party's computer, informing the VoIP application that an inbound VoIP call is arriving at the application .

2) If the application can be invoked by the inbound IP-based notification, the application can be automatically woken up by the inbound notification and automatically answer the call. Otherwise, the inbound notification may wake up or invoke the application to pop up on the screen of the called party's computer the option to answer the call or cancel (or ignore) the call. Answering the call will cause the VoIP application associated with the push notification to be invoked when the user selects that option. The invoked VoIP application may immediately answer the inbound VoIP call or allow the user to choose to answer the inbound VoIP call after clicking a confirmation button in the VoIP application. In order for the VoIP server on the CCF server to be able to send a VoIP call to the called party's phone, the called party's phone will have to register with the CCF's VoIP registrar, providing the registrar with the phone's IP address and port number to register in its Send VoIP incoming signaling. This can be done through a Session Initiation Protocol (SIP) register command from the handset to the SIP server served by the CCF. Other VoIP protocols, proprietary or standards based, can also be used to inform the server how to send the VoIP call to the called party's computer. The VoIP application on the called party's computer can run in the background such that it routinely sends a registration message to the CCF server informing the server of the appropriate IP address and port number to send the VoIP call to.

3) Alternatively, the VoIP application on the computer that accepts the inbound VoIP phone call can instead connect to the VoIP server to be bridged to the called party. This method eliminates network address translation (NAT) problems because the computer's VoIP client will dial in and not be dialed in. In this case, the calling party is routed from the operator and handset to the CCF server. The calling party is then put on hold or awaits an action by the called party. Push messages can make a bell ring like a phone, mimicking an inbound phone call. The push message will contain the routing address, which can be a SIP address or a phone number linking the call. This push notification or SMS is sent to the called party's handset, and when it is opened by the called party, the VoIP application is invoked. The VoIP application then dials in to the VoIP address contained in the push notification or SMS message (eg, SIP:119281717axl-Ahak2lsip.msn.com, if using SIP). The server dialed by the called party's VoIP application can determine which telephone call to connect or bridge the inbound VoIP call to so that the calling party's call is no longer on hold and connected to the dial-in party. The address of a SIP INVITE may contain caller and calling party information, call ID and lane or parking space, and a verification code to authenticate the request to connect to the called party that is currently on hold.

4) The VoIP application on the called party's computer can be a third-party application such as Skype. In this case, acceptance of an inbound call request by the called party through an IP, push notification, or HTTP request sent from the called party's phone to the CCF server can cause the CCF server to place the caller's call (currently on hold on the CCF server) Bridge to the server of a third-party application (for example, Skype). The call is then routed by the server of the third-party application (eg, Skype) to the client (eg, Skype) application on the called party's computer.

Alternative Implementations Using Missed Call and Rejected Call Detection

In cases where the handset has the ability to be aware of an inbound call (via an operating system or application exception, callback, notification, or other mechanism), the handset operating system or application on the handset may notify the user via a graphical or textual menu option Renders a list of call handling options.

The list of options that the user can select can be generated locally by the handheld without requiring a server to generate the set of options, or the handheld OS or application can retrieve the list of options from a server.

The list of options from which the user may choose is outlined elsewhere in this document and may include accepting the call, rejecting the call, sending the call to voicemail, blocking the call, routing to any number of other phone numbers, or Telephony endpoints, such as IP phones, IP clients (e.g., Skype, MSN Messenger, Office Communicator, SIP clients, etc.), playing custom or predefined messages, ring or ringback tones, songs, interactive voice responses ( IVR) system or any other voice, messaging, or data application to which the user wants to route inbound calls. A unique aspect of this approach is that when a call is received, the user is able to choose how the call is routed in real-time, rather than being limited to the traditional answer and reject (send to voicemail) options available on mobile phones today. As a result, there can be a virtually unlimited number of applications, features and functions that can be created and accessed by users.

When a call is received, the phone OS or application detects the inbound call and retrieves from the handset a list of available and pre-set preferences that the user has configured. Alternatively, the phone or application may request the user's list of options by sending the phone number, user identifier (email, username, etc.) and/or service password configured by the user on the phone's local interface or application. When the server receives this information, it can uniquely identify the user and retrieve the appropriate set of settings and options for that user. The server then sends the list of options and settings back to the requesting application. The phone and/or application then presents a list of options from which the user can choose based on the caller's phone number and contact information and the options and preference information sent back from the server.

The handheld application has the option to silence the inbound ringtone on the recipient's phone and keep the ringtone playing for the caller as if the recipient's phone was still ringing. In this case, the call is "held" on the handset until the called party makes a selection. The caller can also be sent to the CCF server while the called party (receiver) decides how to handle the call through the list of options.

If the call is "on hold" on the handset and the user chooses to answer the call, the user's choice to answer the call will simply cause the handset to answer the phone call as if a normal call were answered, i.e. no CCF required Or the server is involved in answering the call. If the call is sent to the CCF server while the user selects this option, answering the call will require the user to call the CCF service or the service to call back the called party's phone, as described in other methods herein.

If the call is "on hold" on the called party's handset and the user selects an option that requires the CCF server to connect the call with a service (e.g. call to another phone number or VoIP or IM client, playback server side rings back tone or sound, or to voicemail on the server, etc.), the user's command or choice can be sent before or after the "held" call is sent to the CCF server by the handset (via reject option, etc.). Back to the server.

The user's options may be sent to the server via a data connection (eg, HTTP, TCP socket, etc.), SMS, push notification, or some other mechanism available on the handheld device to communicate with the CCF service. This information can be sent to the server before or after the call itself is sent to the CCF service.

If the inbound user elects to be accepted by the server before a CCF-routed telephone call identified by the caller's telephone number and the called party's telephone number (for example, via a forwarding header or similar signaling information) is received at the server, The process or processor handling the inbound user selection can then wait and periodically poll in a queue (in a database, memory, etc.) to check if the inbound call has already been received at the CCF server.

If an inbound call identified by the caller's phone number and the called party's phone number (e.g. via a divert header or similar signaling information) is received at the CCF server prior to the user's option, process the inbound call The server process of can periodically poll a queue of inbound requests (in a database, memory, etc.) that will contain the user's selections when they are received.

When a CCF-routed inbound call is received at a CCF server and a user's selection is received through the user's selection handler process, the CCF service will be instructed to handle the inbound call appropriately. For example, the inbound call can be routed to the user's choice (eg, voicemail, a combination of making more than one phone call, Skype or other IM client, VoIP client, ring tone or ringback tone, etc.).

The inbound user option may also look up the inbound leg of the call (parked call or ringing/on hold call) on the CCF server and send a command to the call leg to route itself or Bridge to the appropriate service (for example, voicemail, a combination of making more than one phone call, Skype or other IM client, VoIP client, ring or ringback tone, etc.).

In the event that the data connection to the server is not available when the inbound call is received, the called party can send the call to the CCF server by clicking reject or similar functionality on the phone. If the called party does not answer the call, the call is also sent to the CCF server because the call was not answered. When the call is sent to the CCF server, the phone's OS or application can detect the rejected or unanswered call and report the call to the CCF server via IP connection (HTTP, TCP socket, etc.), push notification or SMS Notify of missed or rejected calls. The CCF server may respond with options available to the called party based on the calling party's phone number, the called party's preferences, and server options. This response can be in the form of a response to a data connection (e.g. a response to an HTTP request, a push notification to the phone, a response to a polling request from the phone, etc.) or a response received from the phone at the CCF server Then send to that phone. The phone can send the missed call type (rejected, missed, call ended) to the CCF server so that the server can send the appropriate response or list of options to the handset.

If the CCF server receives a reject call type from the handset, the list of options may reflect that it includes forwarding to other phone, VoIP or IM client, etc. as described above. If a missed call type is received, the server can send a similar list of options or simply automatically send the call to voicemail, since the call recipient has not yet been able to explicitly send the call to the CCF with a reject or similar option server, thereby indicating that the user is also unable to respond to the options sent by the CCF server. If the call type is a completed call, the CCF may simply send back a call summary and a list of options appropriate to the call type if the caller is no longer on the phone (ie, the call has ended). These options and preferences can be set by the called party before the call is received and used by matching the called party (ie, by transferring headers, etc.) with the called party's preferences when an inbound call is received.

The following steps of routing the inbound call based on the user's preferences and selections may be performed according to the steps described elsewhere herein.

According to one aspect of the present invention, there is provided a method for processing each incoming call received by a mobile telephone, the method comprising: enabling the option of accepting said incoming call at said mobile telephone and placing said call An option to forward from the mobile phone to a service comprising at least one of a server and a telephone switch may be selected by a user of the mobile phone when the mobile phone receives the inbound call, while the user selects from a or a plurality of further options to determine how to handle the call; and handle the inbound call as determined by the user-selected option.

In an embodiment, said one or more further options may determine where to route said call, and said method may comprise routing said call as determined by said user selected option.

The one or more further options may determine a protocol used to receive the call, and the method may include processing the call using the determined protocol.

The service may process the inbound call as determined by the selected one of the one or more further options.

When the user selects one of the one or more further options, the calling party of the call may be placed on hold such that the calling party may be provided with a ring tone or message from the service while on hold.

While on hold, the service may provide options to the calling party.

The service may provide the one or more further options to the mobile phone.

The service may check whether the user has responded with the desired action to select one of the one or more further options.

The one or more further options may include at least one of: sending the caller to voicemail if a message is played to the caller requesting the caller to leave a voicemail message; playing fax tones for the calling party to provide fax receiving service; routing the call to a conference bridge; routing the call to another telephone number other than that of the mobile phone; routing the call to an operator; and routing the call to a VoIP or instant messaging address.

The method may include making available to the user an option to block the call.

The method may include adding the calling party of the call to a database of blocked parties.

The method may include looking up an identification of the calling party of the call in a database and providing the identification to a user of the mobile phone so that the user can determine how to handle the call based on the identification.

The method may include forwarding the call to a service comprising at least one of a server and a telephone switch, wherein the service may look up the identification and send the identification back to the mobile phone.

Alternatively, the mobile phone may look up the identification information.

The method may include forwarding the call to a service comprising at least one of a server and a telephony switch, and sending a message from the service back to the mobile phone, the message providing instructions for the user to call back the The number or address of the service to connect the user to the calling party of the call.

The mobile phone may run an application on the mobile phone that provides the one or more further options.

The method may include forwarding the call to a service comprising at least one of a server and a telephone switch for handling the inbound call as determined by one of the one or more further options, wherein the The application may send the selected one of the one or more further options to the service.

The method may include offering an application for sale from an online store, enabling different application providers to use different options for handling calls.

One of said one or more further options may include forwarding said call from said mobile phone to a service comprising at least one of a server and a telephone switch, and routing said call from said service to an IP accessible the address of.

Routing the call to an IP-accessible address may include routing the call back to the mobile phone using VoIP.

According to another aspect of the present invention, there is provided a method for processing each incoming call received by a mobile phone, the method comprising: enabling the option of accepting said incoming call at said mobile phone and determining how to handle it One or more other options for the call may be selected by a user of the mobile phone when the inbound call is received at the mobile phone; an inbound call; wherein the one or more other options include at least one of: forwarding the call to another phone number or address; a service that blocks the call, the service playing a call blocking message to the calling party of the call; and storing the calling party's phone number in a database to block subsequent calls from the calling party; playing fax tones to providing a fax reception service; and forwarding the call to voicemail with an option of what message to play to the calling party.

In an embodiment, the one or more other options may determine a protocol used to receive the call, and the method may include processing the call using the determined protocol.

The method may include forwarding the call from the mobile phone to a system including one of a server and a telephone switch for processing the call as determined by a selected one of the one or more other options. Called service.

The call may be placed on hold on the service while the user selects one of the one or more other options.

A ring tone or message from the service may be provided to the calling party of the call while on hold.

The service may provide options to the calling party while on hold.

The service may provide the one or more other options to the mobile phone.

The service may check whether the user has responded with a desired action to select one of the one or more other options.

The method may include looking up an identification of the calling party of the call in a database, and providing the identification to a user of the mobile phone so that the user can determine how to handle the call based on the identification.

The method may include forwarding the call to a service comprising at least one of a server and a telephone switch, wherein the service may look up the identification and send the identification back to the mobile phone.

Alternatively, the mobile phone may look up the identification information.

The method may include forwarding the call to a service comprising at least one of a server and a telephone switch, and sending a message from the service back to the mobile phone, the message providing the user to call the service back The number or address used to connect the user to the calling party of the call.

The mobile phone may run an application on the mobile phone that provides the options.

The method may include forwarding the call to a service comprising at least one of a server and a telephony switch for handling the inbound call as determined by one of the one or more other options, wherein the The application may send a selected one of the one or more options to the service.

The method may include offering an application for sale from an online store, enabling different application providers to use different options for handling calls.

The option to forward the call to another address may include forwarding the call to a service comprising at least one of a server and a telephony switch and routing the call from the service to an IP-accessible address.

Routing the call to an IP-accessible address may include routing the call back to the mobile phone using VoIP.

According to another aspect of the present invention, there is provided a method for processing an inbound call received by a mobile phone, the method comprising: forwarding the call from the mobile phone to a system comprising at least one of a server and a telephone exchange service, and routing the call from the service to an address accessible by the user's IP.

In an embodiment, routing the call to the IP-accessible address may include routing the call back to the mobile phone using VoIP.

According to another aspect of the present invention, there is provided a method for processing each incoming call received by a mobile phone, the method comprising: enabling the option of accepting said incoming call at said mobile phone and determining how to handle it One or more other options for the call may be selected by a user of the mobile phone when the inbound call is received by the mobile phone; the inbound call is processed as determined by the user selected option calling; and enabling the user to access a different application that provides different options for handling the one or more other options of the call.

According to another aspect of the present invention there is provided a computer program product embodied on a computer readable medium and configured to, when executed on a processor, operate according to any of the above method features. The computer program can be embodied on a non-transitory computer readable medium.

According to another aspect of the invention there is provided a service comprising one of a server and a telephone exchange, wherein the service is configured to operate according to any one of the above method features.

According to another aspect of the invention there is provided a mobile telephone configured to operate according to any of the above method features.

Claims (43)

1. the method for an inbound calling that at every turn receives for the treatment of mobile phone, the method comprises:

Make the option of accepting described inbound calling at described mobile phone place and described calling is forwarded to from described mobile phone the option that comprises the service one of at least of server and telephone exchange and can be selected by the user of described mobile phone when described mobile phone receives described inbound callings, described user selects how to process described calling with definite from one or more further options simultaneously; And

The determined such described inbound calling of processing of option according to described user's selection.

2. method according to claim 1, where wherein said one or more further options are determined to route the call to, and described method comprises the described calling of the determined such route of option of selecting according to described user.

3. method according to claim 1, wherein said one or more further options determine to receive the agreement of described calling, and described method comprises and uses the described calling of determined protocol processes.

4. according to claim 1,2 or 3 described methods, wherein said service is according to the determined such described inbound calling of processing of a selecteed option in described one or more further options.

5. method according to claim 4, wherein when described user selected one of described one or more further options, the calling party of described calling lay on the table, and makes when shelving to described calling party bell sound or message from described service are provided.

6. method according to claim 5, wherein when shelving, described service provides option to described calling party.

7. according to the described method of above-mentioned any one claim, wherein said service offers described mobile phone with described one or more further options.

8. method according to claim 7, whether the described user of wherein said service inspection responds to select an option in described one or more further option with the action of expectation.

9. according to the described method of above-mentioned any one claim, wherein said one or more further option comprises at least one in following: in the situation that stay the message of voice mail message to the described calling party of calling party playing request, described calling party is sent to voice mail; Play fax tone to provide fax to receive service to described calling party; Route the call to the meeting bridge; Route the call to telephone number another telephone number in addition of described mobile phone; Route the call to operator; And route the call to VoIP or instant message transrecieving address.

10. according to the described method of above-mentioned any one claim, comprise the option that makes described user can obtain to stop described calling.

11. method according to claim 10 comprises the database that the calling party of described calling is added to the side of being blocked.

12. according to the described method of above-mentioned any one claim, be included in the sign of the calling party of searching described calling in database, and described sign is offered the user of described mobile phone, make described user to determine how to process described calling based on described sign.

13. method according to claim 12 comprises described Call Forwarding to comprising the service one of at least of server and telephone exchange, the described sign of wherein said service search and described sign is sent back to described mobile phone.

14. method according to claim 12, wherein said mobile phone is searched described identification information.

15. according to the described method of above-mentioned any one claim, comprise described Call Forwarding to comprising the service one of at least of server and telephone exchange, and send it back message from described service to described mobile phone, described message is provided for number or the address of the described service of described user's callback, described user is connected to the calling party of described calling.

16. according to the described method of above-mentioned any one claim, wherein said mobile phone operates in the application program that described one or more further options are provided on described mobile phone.

17. method according to claim 16, comprise described Call Forwarding to comprising the service one of at least of server and telephone exchange, be used for according to the determined such described inbound calling of processing of one of described one or more further options, wherein said application program sends to described service with a selecteed option in described one or more further options.

18. according to claim 16 or 17 described methods comprise the application program that sale is provided from online shop, make the different application program providers can be with different options for the treatment of calling.

19. according to the described method of above-mentioned any one claim, one of wherein said one or more further options comprise described calling is forwarded to from described mobile phone and comprise the service one of at least of server and telephone exchange, and with described calling from described service routing to IP addressable address.

20. method according to claim 19 wherein routes the call to IP addressable address and comprises and use VoIP that described call routing is got back to described mobile phone.

21. the method for an inbound calling that receives for the treatment of mobile phone at every turn, the method comprises: make and accept the option of described inbound calling at described mobile phone place and determine that one or more other options of how processing described calling can be selected by the user of described mobile phone when described mobile phone receives described inbound calling; And

The determined such described inbound calling of processing of option according to described user's selection;

Wherein said one or more other option comprises at least one in following:

Another telephone number or address are arrived in described Call Forwarding;

By described Call Forwarding is stopped described calling to the service that comprises one of server and telephone exchange, described service is play to call out to the calling party of described calling and is stopped message, and the telephone number of described calling party is stored in database to stop the subsequent voice calls from described calling party;

Play fax tone to provide fax to receive service; And

The option of playing what message with described in the same way calling party arrives voice mail with described Call Forwarding.

22. method according to claim 21, wherein said one or more other options determine to receive the agreement of described calling, and described method comprises the described calling of the determined protocol processes of use.

23. according to claim 21 or 22 described methods, comprising determined like that according to an option of selecting, described calling is forwarded to the service for the treatment of described calling that comprises one of server and telephone exchange from described mobile phone in described one or more other options.

24. method according to claim 23, wherein when described user selected one of described one or more other options, described calling was shelved in described service.

25. method according to claim 24 wherein provides bell sound or message from this service to the calling party of described calling when shelving.

26. method according to claim 25, wherein described service provides option to described calling party when shelving.

27. the described method of any one according to claim 23 to 26, wherein said service provides described one or more other option to described mobile phone.

28. method according to claim 27, whether the described user of wherein said service inspection responds to select one of described one or more other options with the action of expecting.

29. one of according to claim 23 to 28 described method, be included in the sign of the calling party of searching described calling in database, and the user to described mobile phone provides described sign, makes described user to determine how to process described calling based on described sign.

30. method according to claim 29 comprises that with described Call Forwarding to comprising the service one of at least of server and telephone exchange, wherein said service can be searched described sign, and described sign is sent back to described mobile phone.

31. method according to claim 29, wherein said mobile phone is searched described identification information.

32. according to the described method of above-mentioned any one claim, comprise with described Call Forwarding to comprise server and telephone exchange one of at least service, and beam back message from described service to described mobile phone, described message provides number or the address of the described service use of described user's callback, described user is connected to the calling party of described calling.

33. the described method of any one according to claim 23 to 32, wherein said mobile phone operates in the application program that option is provided on described mobile phone.

34. method according to claim 33, comprise described Call Forwarding to comprising the service one of at least of server and telephone exchange, be used for according to the determined such described inbound calling of processing of one of described one or more other options, the option that wherein said application program will be selected in described one or more options sends to described service.

35. according to claim 33 or 34 described methods comprise the application program that sale is provided from online shop, make the different application program providers can be with different options for the treatment of calling.

36. according to the described method of above-mentioned any one claim, wherein with described Call Forwarding to the option of another address comprise with described Call Forwarding to comprise server and telephone exchange one of at least service and with the option of described calling from described service routing to the addressable address of IP.

37. method according to claim 36 wherein routes the call to IP addressable address and comprises and use VoIP that described call routing is got back to described mobile phone.

38. the method for an inbound calling that receives for the treatment of mobile phone, the method comprises:

Described calling be forwarded to from described mobile phone comprise the service one of at least of server and telephone exchange, and with described calling the IP accessible address from described service routing to described user.

39. described method, wherein route the call to described IP accessible address and comprise that use VoIP gets back to described mobile phone with described call routing according to claim 38.

40. the method for an inbound calling that receives for the treatment of mobile phone at every turn, the method comprises: make and accept the option of described inbound calling at described mobile phone place and determine that one or more other options of how processing described calling can be selected by the user of described mobile phone when described mobile phone receives described inbound calling;

The determined such described inbound calling of processing of option according to described user's selection; And

Make described user can access different application programs, described different application program is provided for processing the different options of described one or more other options of calling.

41. a computer program, this computer program are embodied on computer-readable medium and are configured to when carrying out on processor, any one according to claim 1-40 operates.

42. a service that comprises one of server and telephone exchange, any one that wherein said service is configured according to claim 1-40 operates.

43. a mobile phone, its any one that is configured according to claim 1 to 40 operates.

Images