WO2012001016A1

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

Info

Publication number: WO2012001016A1
Application number: PCT/EP2011/060859
Authority: WO
Inventors: Enlai Chu
Original assignee: Skype Ireland Technologies Holdings Limited
Priority date: 2010-06-28
Filing date: 2011-06-28
Publication date: 2012-01-05
Also published as: EP2572523A1; CN103155606B; CN103155606A

Abstract

A method for handling an inbound call being received at a time by a mobile phone, the method comprising: making available, to be chosen by a user of the mobile phone at the time the inbound call is received at the mobile phone, an option to accept the inbound call at the mobile phone, and one or more other options to determine how the call is handled; and handling the inbound call as determined by the option chosen by the user. The one or more other options may comprise: sending a calling party to voicemail, providing a fax receiving service, routing the call to a conference bridge, routing the call to another telephone number, routing the call to a switchboard operator, and/or routing the call to a VoIP or instant messaging address. Applications may be made available to the user 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

SUMMARY

A method, computer system, computer program product, phone application, and user interface for managing inbound calls for mobile telephony users when phone calls are received. This provides functionality to mobile phone users that is availa ble only to landline phone users, such as "Caller ID with name". It also provides functionality not currently available on mobile phones such as accepting faxes, conference calling for large groups, ringing an office, home or other phone if the mobile phone user wants to answer the call on another phone, or taking the mobile phone call on a Voice over IP (VoIP) client such as a computer. It also enables recipients of phone calls to decide, in real-time, how to handle the incoming calls - forward to an office or home phone, assistant, answering system, fax machine, call blocking message, VoIP client, instant messenger client, conference call system, or any other option made availa ble to the recipient of the phone call. This gives the call recipient the ability to not only set up call routing and filters before the call is received but decide what to do or where to route the incoming mobile phone call at the time the call is received based on the call recipient's location, time of day, access to other telephone systems, availability, access to methods of choosing how the received call is handled, and the type of call received. The methods of choosing how a call is received include, but are not exclusive to, SMS text messages, WAP (Wireless Access Protocol), a ny IP (Internet Protocol) connection, and voice commands.

The list of options the user can select from are outlined in the other descriptions in this document, and can consist of picking up the call, declining the call, sending the call to voicemail, blocking the call, choosing to route to any number of other phone number or telephony endpoints such as IP phones, IP clients (e.g. Skype, MSM Messenger, Office Communicator, SIP client etc.), play a custom or pre-defined message, a ringtone or ringback tone, a song, an Interactive Voice Response (IVR) system, or any other voice, messaging or data application that the user wants to route the inbound call to, The unique aspect of this method is that the user is able to choose how to route the call in real time, as the call is received, without being limited to the traditional Answer and Decline (send to voicemail) options available on mobile phones today. As a result, there can be a practically unlimited number of applications, features and functions that can be created and made accessible to the user.

In addition, this makes possible an "app store" that aggregates and sells private as well as third-party applications that users can browse, select, purchase and use to handle their inbound phone calls. These options and features can be made available to any user of any handset and using any carrier because the service can be used to handle any inbound call regardless of the provider of the phone service,

OVERVIEW

Particular embodiments generally relate to wireless communications systems and more specifically to a system that enables recipients of voice calls to choose, in real-time, how to handle an inbound call at the time the call is received. Particular embodiments may use cloud phone services, which are communications services that reside in a hosting facility of a service-provider providing such cloud phone services. Cloud phone services can provide call forwarding, simultaneous and sequential ringing of multiple phones, bridging to traditional public switched telephone network (PSTN) endpoints and VoIP or Instant Messenger voice clients, two-way SMS relaying, group messaging, fax, conference calling and other telephony-related services,

Cellular phone communications services offer users the convenience of being able to receive phone calls on a wireless device regardless of their location, at any time. However, inbound calls have to be either answered or sent to voicemail. Also, 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 is unable to determine the caller's information such as name or location because the mobile phone network only sends the caller's phone number and not the caller's name to the wireless device. The call recipient then only has the option to pick up the call to find out who the caller is, or to send the caller to voicemail and hope the caller leaves a message with a name and reason for calling. These limited options result in the call recipient having to pick up the phone, only to find that the caller is a telemarketer, bill collector, or other calling party that the recipient would rather not be speaking to or wasting their limited voice plan minutes on. The other unsatisfactory option is to let the call ring to voicemail, only for the called party to find out that the caller was indeed a call that should have been answered - for example, a delivery company trying to locate called party or an important client calling from a different phone number than was stored in a called party's wireless device address book. If the calling party does not leave a message, the called party is unable to easily determine the calling party's identity without calling the number back. Worse, in cases where the calling party's phone number requires an extension to reach the individual who made the call (for example, when the calling party's phone number is a large company's 1-800 toll-free number or if the calling party is calling from a company with a Private Branch Exchange or Virtual PBX that requires dialing an additional extension to reach specific individuals), the called party is unable to easily return the phone call of the calling party. The solution therefore requires the called party to know the name of the calling party and for the called party to be able to decide whether to be connected to the calling party before the calling party hangs up. Depending on the caller and nature of the call, the called party can also choose to send the caller to voicemail, a fax receiving service, a conference bridge, or another telephone number such as a landline or an administrative assistant or company switchboard operator. This enables the called party to not only use the called number for call features other than normal telephone calls but also for other services that the called party chooses. Particular embodiments allow the called party to choose, at the time that the inbound call is received, how to handle and route the inbound call.

FUNCTIONAL DESCRIPTION

Particular embodiments may use Conditional Call Forwarding (CCF), which enables the called party to click on the "End" button on the phone or "Decline" or equivalent icon on the phone's screen when an inbound call is received and the called party either does not recognize the caller's phone number that shows up on the phone or if the called party wants the option to route the inbound phone call to a different phone or service, Clicking "End" or "Decline" will stop the ringing on the called party's phone and instead route the call to the CCF phone number, address or service.

Particular em bodiments set the CCF number to the phone number or IP-accessible address (such as a session initiation protocol (SIP) address like voicemail@mobilecarrier.com) that is provided to the called party by a service or product. This CCF number can be a single phone num ber 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 implementation's servers to handle the call. The call can be received as Time Division Multiplex (TDM), VoIP using protocols such as Session Initiation Protocol (SIP), H.323, Media Gateway Control Protocol (MGCP), PacketCable™ or other proprietary or non-proprietary call method to the servers, along with call information that includes the caller's phone number, the called party's phone number or dialed number, and the CCF phone num ber. For example, the embodiment could be an Asterisk, SE , Kamailio, OpenSER, FreeSwitch or another VoIP routing, signaling and application server (for the purposes of this document, collectively referred to as the embodiment's servers or service) that has an associated Direct Inward Dial (DID) number associated with it. The CCF number could be programmed on the called party's phone to forward all busy and unanswered calls to the DID that routes calls to VoIP servers. The CCF can be set up on each mobile phone by calling customer support of the carrier providing service to the called party. Some mobile phone carriers also enable customers to set up CCF by setting up call or forwarding preferences on the called pa rty's phones themselves. Called parties also have the option, with some carriers, to dial a specific dialing code in order to set up CCF on their phones. Here are some examples of CCF setup dial codes for certain U.S. carriers. They may change over time but can be obtained by calling customer care of the individual carriers.

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 num ber> [ 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 are CCF forwarding to phone number CCF services via a phone number associated with the CCF server. Alternatives to this include forwarding to a CCF service via VoIP by using the CCF service's VoIP address, for example ccf@sip.3iam.com or other VoIP identifier that will route the call the to the corresponding CCF service.

When the servers receive an inbound phone call, the servers determine if the called party's phone number is an eligible phone number for the service provided by looking up the customer provisioning information in the server's information database and accompanying business logic algorithms, If the called party's phone number is not eligible or provisioned for the service, the called party is played a message, The message can advertise the service, inform the caller that the called party is unable to receive voicemails, or any other message the provider of the service deems appropriate, The service provider can, alternatively, allow the caller to leave a voice message, The called party can also be notified by a manual or automated phone call or text message initiated by the service provider to notify the called party that a caller called and to provide information about how to obtain service or listen to the voicemail message left by the caller, if such a voice message exists.

If the called party's phone number is an eligible phone number for the service provided by looking up the customer provisioning information in the server's information database and business logic algorithms, the service may play a ringing tone to the calling party in order to simulate the phone call ringing the called party's phone, Alternatively, the service can play a message to the calling party to inform the calling party that the called party is being located. The message can also instruct the calling party to press a digit on the calling party's phone in order to leave a message immediately, a different digit to be joined into a conference call, or yet another digit to send a fax, and then start playing the ringing tone to denote the system ringing the called party's phone. There can be many different options presented to the calling party based on a configurable set of options decided upon by the called party prior to the calling party making the call to the called party. The service embodiment can also be implemented so the calling party can choose an option based on speaking the option and the service can perform speech recognition to interpret the caller's choice. While the calling party is waiting for the called party to pick up the call or specify an action, the inbound call leg of the call on the server will be waiting to be informed of the next action to perform on the inbound call. During this time, while the calling party is listening to a message, ring-back tone or advertisement, the server could also be listening to detect a fax tone or other digit requests from the calling party. For example, if an Asterisk 1.6 server is being used as a part of the service implementation, NVFaxDetect, IWBackground Detect, Asterisk's faxdetect=yes option in sip.conf or another fax service can be used to detect faxes in the background. The server, invoked by an inbound call leg, can set up a row in a database or memory location unique to the caller, called party or inbound call, and be polling (e.g. querying the database row or memory location) for the action. The called party's response will include information to update this database or memory location with the user's action for this particular caller, called party or call. The server can also wait to be notified via a SUBSC IBE-NOTIFY type service or exception-based notification system such as a manager interface or Command Line Interface (CD). In the case of an Asterisk server, the server can poll a database using an Asterisk Gateway Interface (AGI) script to invoke a DATABASE GET command to check if the called party has responded with the desired action or the inbound action received by the server can call an Asterisk Manager Interface (AMI) or CLI command to the Asterisk server to perform the desired action on the phone call that is currently awaiting the called party's action.

While the calling party is presented with the calling party menu of options and the ringing tone, the service's servers simultaneously perform a caller ID name and address or location lookup of the calling party's phone number by searching in public and private lookup services and databases such as Calling NAMe (CNAM) services (e.g. from http://www.asteriskcnam.com, http://www.cnam, info,

http.7/www.voipcnam.com, or http://wholesale.metrostat.net ), Local Exchange Routing Guide (LERG ) (e.g. from http://telcodata.us ), White Pages (e.g. http://www.whitepafies.com ), national, regional or other reverse lookup database, or the called party's online address book or the collective service's customers' online address books, which may be made available by customers opting in to share their data with other users. After the lookups are performed, the caller's information is then sent back to the called party via a pull or push mechanism such as SMS text message, push notification, HTTP long poll, HTM L5 notification, or by the called party's phone requesting the caller's information from the service's servers.

The retrieved information on the caller such as name, location of the calling party's phone num ber or the actual geographical location of the caller, based on a location database, photograph, social media profile, etc. is then displayed for the called party on the called party's phone. This information is also accompanied by options available for the caller to choose what to do with the calling party's phone call, which is currently on hold at the service's servers. These options could include answering the phone call, asking the caller to leave a voicemail message, play a fax tone to the caller, block the caller's phone number and play a call block message to the caller, route the call to one of multiple phone num bers previously set up by the caller, route the call to a company operator, or any other service or phone num ber determined by the called party prior to the call. The options could also include soliciting input provided by the called party as a response to the service where the called party can enter a phone number not previously set up as an option to route the call,

Then, to send the chosen option to the service, the called party can click on the Uniform Resource Locator (URL) or Uniform Resource Identifier (URI) link provided in the list of options shown to the called party. The web server receiving the URI or URL matches the unique ID, caller, called number or a combination of the data parameters on the URI or URL to the inbound phone call and updates the action requested for that inbound call. An example is the server sending U RL actions to the caller's phone based on a base62 encoding (a-z A-Z 0-9) of the calling number, a 2 character random hash for 62*62 (0- 9 a-z A-Z) combinations to prevent random malicious abuse by parties trying to guess the URL/URI, and one character representing the action (for 62 possible actions - 0-9 a-z A-Z). The called party can also respond to the SMS or MMS message, push notification or other action request using a native application on the phone or an installed application on the phone with the option chosen. This response can include a digit or character that represents the option, the first letter of the option, a phone number that is not previously in the list of options, a unique ID of the inbound call waiting at the server, or a combination of data that will enable the server to match the user's desired action to the inbound call waiting at the server. The SMS text message response or Internet Protocol (IP)-based click on the URL or U I can also update the call action for the inbound call based on the most recent call waiting at the server that dialed the called party's number or the calling party's number instead of a unique ID for the call. This may result in potential matches for desired actions on more than one call but the low probability of this conflict happening, coupled with detection and blocking of brute force requests, may be sufficient to make this solution workable, The server receives the action notification and notifies the calling party's inbound leg on the server by updating the memory or database location that the inbound call leg is polling every second (or other period specifiable by the service or called party prior in the called party's service preferences), or by NOTIFYing the inbound call leg by writing to it via a manager port of the server, command line, or some other method of invoking the inbound call leg to perform a subsequent action based on the called party's response.

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

If the called party's response is to block the caller's phone number and play a call block message to the caller, the caller will hear a message such as, "The party you have called has blocked you, Please hang up and don't call back." The blocked caller message can be pre-determined by the called party prior to the call or can 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, pickup and hangup the call immediately, play a busy signal, play a phone number disconnected signal, or other messages and busy or disconnected tones in an attempt to get the blocked party to not call back. The calling party's phone number will then be stored in the service's database so that subsequent calls to the called party's phone that the called party sends to the servers via the End or Decline keypress will perform the blocked caller action on the blocked party immediately instead of sending the called party a SMS text message or push notification prompting the called party to choose an action.

If the called party's response is to route the call to one of multiple numbers previously set up by the caller or to a company operator or any other service or phone number determined by the called party prior to the call, the calling party's call is routed out to the appropriate phone number(s) or service (such as a VoIP phone service or IM address like a Skype or Google Talk) using the appropriate gateways and connection protocols. Some options, like Block, could trigger a secondary menu, popup, or set of options that shows up on the ca lled party B's phone when selected. The secondary menu could show another set of options that expand on the choice. For example, for the Block option, the user could be asked what message to play for the blocked party when the call is blocked. For the voicemail option, the called party B could be asked what message to play to the calling party. Depending on whether the caller is a personal contact, business contact, anonymous party or nuisance caller, called party B can select the message to be played to this caller. The decision is relayed back to the CCF server via a data connection (HTTP or proprietary API call, or otherwise), SMS message, network call (SS7/PSTN/GSM/CDMA etc).

Other options could be to forward the call to another phone, computer or device. This could optionally trigger a secondary menu asking the caller which destination to forward the call, be it another phone number, a long-distance (International) num ber, voicemail, an auto-attendant, an Interactive Voice Response (IVR) system, a Voice over IP client (for example, a SIP address like ]pn@s[p.msn,_.com or Skype user's client), etc. This secondary selection can be pre-defined by the user as a list of nu mbers to choose from, selected from the called party B's address book, or a selection obtained from an online address book such as Facebook's contact list, Google or Gmail's address book, Plaxo, or another source. The online contact list can be downloaded by the application prior to the phone call coming in, when the call comes in, or when the call is forwarded to the CCF service before routing the options back to the called party.

An alternative implementation of the embodiment is for the telephony switch connected to the PSTN to perform the server functions described above. The telephony switch may perform the functions described above with or without requiring the conversion of the inbound call from TDM to IP. The telephony switch may also perform the functions described above with or without conversion of the outbound call to the called party's phones from TDM to I P. The implementation of the embodiment using the telephony switch may provide higher performance and lower latency because the service functions can be more tightly coupled within the telephony functions of the telephony switch rather than relying on external servers which could add additional communications overhead between the telephony switch and the external servers. The alternative implementation can also be implemented with some functionality handled by the telephony switch and some functionality performed by external servers.

ALTERNATE IMPLEMENTATIONS USING IN-CALL OR PRE-HANGUP MECHANISM On a 2G or 2.5G wireless phone or wireless phone network such as EDGE, data connectivity on mobile devices is unavailable when an incoming call is being received (when the called party's mobile phone is ringing or when the call is in progress). In situations where access to an IP connection is available on the called party's mobile phone (such as on 3G networks or when the phone has an alternate wired or wireless connection such as 802,11 WiFi) when the call is received, the phone can use this IP connection to pull or retrieve information about the caller from the service - including but not limited to, the caller's name, location, picture, etc. from a private or public data sources mentioned above, In this scenario, the em bodiment will enable the called party to keep the inbound phone call ringing on the phone without the called party picking up the call. While the caller is still waiting for the called party to pick up, the called party's phone, via built-in functionality or an application on the phone, retrieves information about the caller using an IP-based request, SMS message, MMS message, other forms of data lookup and retrieval, or a combination of the above.

When the calling party's information is retrieved by the embodiment, the information is presented to the called party. The called party can then decide to pick up the call or route the call to the CCF number and service by clicking on a list of options presented by the phone's native functionality or an application, or by replying to a text message or clicking a URI or URL link or selector. If the called party decides to route the call to the CCF service, the inbound call will arrive at the service's servers or switch at around the same time as the action notification from the called party. If the service receives the inbound phone call before the user's action notification, the service can play a ringing tone, some other custom or canned message or audio to the calling party while the service waits for a pre-determined amount of time for an inbound message to arrive at the service. If the service then receives a message from the called party's phone notifying the service of the called party's desired action, the service will then match the inbound call with the called party's action using a combination of caller's phone number, called party's phone number, the CCF phone number and the data accompanying the called party's action message or URL or URI clicked. If the service receives the called party's desired action prior to the inbound call arriving at the service's servers, the service can hold on to the called party's desired action for a pre-determined amount of time (e.g. 10 seconds) and match the called party's action to the inbound call when the inbound call arrives at the service's servers.

The incoming call is then handled according to the called party's desired action: routed back to the caller's phone, alternate phone or phones, computer, voicemail, fax, conference call or other service determined by the called party in the called party's preference settings stored by the service or in the 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 prior to a pre-defined timeout, the inbound phone call is directed to voicemail, fax, conference call, or a combination of services depending on the nature of the inbound call. During the time when the service is waiting for the called party's action request, the calling party may be presented with options to press keys on the calling party's phone or via voice command to leave a voicemail, start a fax session, join a conference call, or other possible options pre-configured according to the called party's preferences,

ALTERNATE IMPLEMENTATIONS USING CLOUD PHONE NUMBER SERVICES

In situations where the user has a cloud phone number as a primary number (a phone number not traditionally associated with a dedicated physical device like a single cell phone or a single mobile phone but configurable by the owner to ring one or more phones or other communication devices when an incoming call is received), when a caller calls the called party's cloud phone number, the cloud phone num ber service can first ring the called party's phone with the cloud phone number, The cloud phone number appearing on the called party's mobile phone will indicate to the called party that the caller has dialed the cloud phone num ber instead of the called party's mobile phone directly,

If the called party answers the phone when the cloud phone number calls the called party's phone, the cloud phone number can first do a lookup (LE G, CNAM, online address book etc. as above) and announce the called party's name, location information, etc. The called party can then use voice commands or digit keys on the phone to pick options like routing the inbound call back to the called party's mobile phone or other phones, fax, conference bridge, voicemail etc.

If the called party does not answer the phone when the cloud phone number calls the called party's phone or if the called party sends the inbound call to the CCF number using the End or Decline functionality on the phone, the call will be routed to the CCF number. The inbound call will arrive to the service's server or switches via the CCF number and can be routed back out to the called party's phone using the caller ID number of the caller instead of the cloud phone number, The called party can then see the phone number of the caller and answer the call or again send it to the service via the CCF number by using the End or Decline functionality on the phone. The service can detect if the same call is coming in to the service's servers twice by maintaining real-time records of ongoing calls. 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.

Alternatively, the service can repeat the functionality of sending the information about the caller to the called party's phone while putting the calling party on hold and playing a ringing tone (with optional instructional message first) to the calling party. The called party can then route the inbound call holding on the service to voicemail, 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 will perform 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 then route the inbound call holding on the service to voicemail, fax, conference bridge or other service configured by the called party.

As an option to the called party B's phone ringing when the cloud number is called, the called party's phone can be sent the caller ID name and, optionally, the action options available for the called party B to choose from, before the call is routed to the called party's phone. The caller ID name can be sent with the caller information in the data header or envelope of the phone call when the call is sent to the handset. This information sent to the handset can also include the action options available to the called party B based on called party B's preferences stored with the mobile operator or a separate preference management server or portal (such as the one associated with the service offered by the CCF server's service provider).

When a call is to be sent to the called party B's phone, called party B's cloud number operator can do an internal lookup in its own databases, on the CCF service provider's servers, or a third party service provider's servers and databases in order to determine the caller ID name and other information (such as social network profile information, carrier information, photographs, etc.) and preference and forwarding options, and then send this information to called party B's phone. The action options can be presented to called party B's handset in the methods shown above and below (SMS, push notification, HTTP data connection, phone response, etc), and the response from the called party can be received via the methods shown above and below (SMS, push notification, HTTP data connection, phone response, etc.).

While the action options and the caller's information (which could consist of caller ID name, social network profile information, carrier information, photographs, etc.) are presented to the called party B's phone via a popup generated by the push notification, SMS message, or application triggered by the inbound call notification that can show the options and caller information in a more esthetically pleasing and functional graphical user interface, the phone's ringer can be silenced by the called party B or automatically by the phone in order to let the called party B choose an option in silence.

If the called party B decides to respond with a chosen action on the application's selection menu, the phone and application receives the user's choice and routes the call accordingly. For example, if called party B chooses the Answer option, the phone will simply route the call to the called party's handset. If the called party B chooses the Block option, the cloud service can bridge the calf to automated message that plays an audio message to the caller such as "the party you have called is no longer at this number" or "this line has been disconnected" or any other message determined by the called party B. The Block option could also simply hang up on the calling party, giving the caller the impression that the called party B is unwilling to answer the phone. The Block option could also send a command to the cloud provider or the operator network to route the call to voicemail.

Some options, like Block, could trigger a secondary menu, popup, or set of options that shows up on the called party B's phone when selected. The secondary menu could show another set of options that expand on the choice. For example, for the Block option, the user could be asked what message to play for the blocked party when the call is blocked. For the voicemail option, the called party B could be asked what message to play to the calling party. Depending on whether the caller is a personal contact, business contact, anonymous party or nuisance caller, called party B can select the message to be played to this caller. The decision is relayed back to the cloud number provider via a data connection (HTTP or proprietary API call, or otherwise), SMS message, network call (SS7/PSTN/GSM/CDMA etc). Other options could be to forward the call to another phone, computer or device. This could optionally trigger a secondary menu asking the caller which destination to forward the call, be it another phone number, a long-distance (International) number, voicemail, an auto-attendant, an Interactive Voice Response (IVR) system, a Voice over IP client (for example, a SIP address like ion@sip.msn, com or Skype user's client), etc. This secondary selection can be pre-defined by the user as a list of numbers to choose from, selected from the called party B's address book, or a selection obtained from an online address book such as Facebook's contact list, Google or Gmail's address book, Plaxo, or another source, The online contact list can be downloaded by the application prior to the phone call coming in, when the call comes in, or when the call is forwarded to the CCF service before routing the options back to the called party. ALTERNATE IMPLEMENTATION USING 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 servers, the server can send back a text message or push notification to the called party's cell phone. The message from the server can include a phone number that the called party can dial in to using the called party's cell phone. This phone num ber is one that will connect (also known as bridge) the called party to the calling party, who is waiting for the called party to answer the call, The called party may also dial in to the service by calling the phone number from which the text message from the CCF service's servers originated,

The CCF server uses the caller's phone number (caller ID of the caller) and the dial-in number (the number dialed by the caller) in order to determine which calling party on hold to connect the caller with. This is an example of a possible implementation:

1. When the calling party A calls called party B's mobile phone, called party B sends the call to the CCF server by pressing the End, Decline or similar functioning option or button on the cell phone.

2. When the CCF server receives the forwarded phone call from calling party A, the CCF server plays a prerecorded message asking party A to wait while party B is being reached. The CCF server can then play a ringback tone, music-on-hold music or other audio media to party A's phone.

3. The CCF server stores party A's phone number using the caller ID information of the call to the CCF server as well as the dialed phone number (party B's phone number) using information such as Diversion headers in the call protocol messages (e.g. SIP messages) sent to the CCF server. The CCF server may also store the phone number of the CCF server that the calling party A's call was redirected to. A com bination of one or more of these 3 pieces of information will be used to determine how to connect (also known as bridge) the called party B to calling party A when called party B dials in to the CCF server using one of the CCF server's dial-in phone numbers in order to connect with calling party A,

4. The CCF server determines the phone number X that the called party B must use to dial in to connect to calling party A. This phone number X may be one of one or more phone numbers used to enable callers to dial in to the CCF server. Having a plurality of dial in numbers to choose from can aid the CCF server in determining which calling party the called party B is trying to connect to, in the event more than one call to called party B is sent to the CCF server around the same time. The server can determine a different phone num ber X for each calling party so 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 is so that if called party B calls dial-in number XI, called party B will be connected to calling party Al. If called party B calls dial-in number X2, called party B will be connected to calling party A2, and so on. 5. The CCF server may store phone num ber X along with the 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 consist of the CCF server instance where the calling party A's call has been placed on hold and the unique identification of the call which can be used to connect or bridge another call leg to calling party A's call leg so that the two parties may converse in a bridged call

6. The CCF server sends a notification to party B's cell phone via text message or push notification, Called party B's phone may also retrieve this information from the server after the call is sent to the CCF server by using a data connection that identifies the calling party A's phone num ber, called party B's phone number and, optionally, called party B's login credentials authenticating called party B's request to retrieve this information. The message or information may contain party A's phone number, caller ID name information, location, photo, and/or other identification a bout the calling party A. The message may also contain the phone number X for called party B to dial in to, in addition to the unique URLs and text message response options described in other parts of this document.

7. When called party B receives the message including the dial-in number X, called party B may choose to dial the number from the phone. This dial-in step may be completed by the called party B clicking on the phone number X in the text message, manually entering the phone number X to the phone, or clicking on an application on the phone that automatically dials the phone number X. The application on the phone would be able to parse the message from the CCF server to determine the dial in phone number, and may present the option to dial the number as a clickable popup menu option,

8. When the called party B's phone dials in to the CCF server using phone number X, the CCF server uses the 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 the calling party A is still on hold waiting to be connected to called party B, the CCF server then connects or bridges party B to party A's call leg and server using the information stored by the server a bout party A's call leg ID. On an Asterisk system, for example, the bridgeQ command can be used to bridge party A's inbound call to waiting party B's call leg.

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

ALTERNATE IMPLEMENTATION USING OPTIONS STORED LOCALLY ON MOBILE DEVICE

The alternative implementation is to have the options stored locally on the app (the information may also be duplicated on the server) so that the app does not need to receive all the possible actions in the push notification or text message sent from the server but instead has the options already stored on the phone. This way, when a n inbound call is sent to the CCF server, an application on the phone can show called party B the options for actions that can be performed on calling party A's call by the CCF server, based on the locally configured settings and options in the app. The app need not wait for a message from the CCF server in order to display the options to called party B. The app can detect that the called party B has either declined the call or missed the call, and use that to trigger popping up of the menu of options. Immediately, the app can also 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 can also display this information from the phone's contact list database if the app has previously retrieved or cached this information locally on the phone. Once the called party selects the desired action, the app can send the called party B's choice via a text message or data connection to a preconfigured general URL for the CCF service (or this URL can be part of the push notification and be customized for the particular call) and simply include the parameters for the option to the server. One implementation of this URL and parameters can be including 1) the desired action and 2) the parameters for the action, based on the user's configuration the options using the app. e.g.

http://r.3iam.com?cailld=2aAGsll&action=voicemail

or

e.g.

http://r.3iam.com/?callld~2aAGsll&action-forward&devicerH=phone&parameter[n=1415888990Q&d evice[2]=phone&parameter[2]=15109822211

or

e.g.

http://r,3iam.com/?callid=2aAGsll&action=forward&device[l]=skvpe&parameter[l]=my_skype_usern ame

or

e.g.

http://r.3iamxom/?callld=2aAGsll&action=fqrward&devicefl1=sip&parameterfl1=mvigisip.phone.com This would also have the benefit of giving a virtually unlimited list of options based on what the CCF server actions that are supported. e.g.

http://r.3iam.com/?cailld=2aAGsll&action-block&parameterfn=play busy tone

or

e.g.

http://r,3jam.com/?callld=2aAGsll&action=ioin conference call The benefit of this implementation is that the called party B need not wait for the server to send called party B's phone a message with the dialed-in number X or the options available. Instead, called party B can send the action command to the CCF server immediately after the incoming call from calling party A is sent to the CCF server. The commands can also be sent using text message from the called party B's phone using SMS. The body of the SMS message will contain the action command that will enable the server to execute the desired action on the calling party A.

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

In addition to the ways called party B can notify the server above, called party B can also choose the desired action and called party's B phone can reroute the call to the appropriate destination. In this case, the called party B's phone will send the desired action to the mobile operator's network equipment via SS7 and/or mobile (CDMA / GSM etc) commands to reroute the call to the destination. In this case, the action will be performed by the called party's mobile operator's network equipment and routing protocols instead of the CCF servers,

The benefit of this is a faster response time than routing the call to the CCF servers and then the CCF servers routing the call to the destination. This could also have better cost implications as large carriers, such as the mobile operator, are able to procure more economical voice termination rates than smaller entities and individuals. In addition, the mobile operator could choose to include the re-routing as part of the called party B's phone plan instead of charging additional re-routing charges, thereby offering higher value than other mobile carrier competitors. The benefit to the mobile operator could be that it is able to offload the voice call from the mobile network to a landline or VoIP client, thereby saving on valuable wireless capacity on its existing spectrum, which is a finite resource and expensive to procure, Some options, like Block, could trigger a secondary menu, popup, or set of options that shows up on the called party B's phone when selected, The secondary menu could show another set of options that expand on the choice. For example, for the Block option, the user could be asked what message to play for the blocked party when the call is blocked. For the voicemail option, the called party B could be asked what message to play to the calling party. Depending on whether the caller is a personal contact, business contact, anonymous party or nuisance caller, called party B can select the message to be played to this caller. The decision is relayed back to the CCF server via a data connection (HTTP or proprietary API call, or otherwise), SMS message, network call (SS7/PSTN/GSM/CDMA etc).

Other options could be to forward the call to another phone, computer or device. This could optionally trigger a secondary menu asking the caller which destination to forward the call, be it another phone number, a long-distance (International) number, voicemail, an auto-attendant, an Interactive Voice Response (IVR) system, a Voice over IP client (for example, a SIP address like jonigsip.msn.com or Skype user's client), etc. This secondary selection can be pre-defined by the user as a list of numbers to choose from, selected from the called party B's address book, or a selection obtained from an online address book such as Facebook's contact list, Google or Gmail's address book, Plaxo, or another source. The online contact list can be downloaded by the application prior to the phone call coming in, when the call comes in, or when the call is forwarded to the CCF service before routing the options back to the called party. ALTERNATE IMPLEMENTATION USING CALLER ID NAME RETRIEVAL BEFORE CCF ROUTING

The alternate implementation presents the caller ID name and, optionally, the action options available for the called party B to choose from, before the call is routed to the CCF servers. The caller ID name can be sent with the caller information in the data header or envelope of the phone call when the call is sent to the handset. This information sent to the handset can also include the action options availa ble to the called party B based on called party B's preferences stored with the mobile operator or a separate preference management server or portal (such as the one associated with the service offered by the CCF server's service provider).

When a call is to be sent to the called party B's phone, called party B's mobile operator can do an internal lookup in its own databases, on the CCF service provider's servers, or a third party service provider's servers and databases in order to determine the caller ID name and other information (such as social network profile information, carrier information, photographs, etc.) and preference and forwarding options, and then send this information to called party B's phone. The action options can be presented to called party B's handset in the methods shown above and below (SMS, push notification, HTTP data connection, phone response, etc), and the response from the called party can be received via the methods shown above and below (SMS, push notification, HTTP data connection, phone response, etc.).

While the action options and the caller's information (which could consist of caller I D name, social network profile information, carrier information, photographs, etc.) are presented to the called party B's phone via a popup generated by the push notification, SMS message, or application triggered by the inbound call notification that can show the options and caller inforrnation in a more esthetically pleasing and functional graphical user interface, the phone's ringer can be silenced by the called party B or automatically by the phone in order to let the called party B choose an option in silence.

If the called party B decides to respond with a chosen action, the phone and application will perform the respective action. For example, if called party B chooses the Answer option, the phone will simply pick up the phone call normally. If the called party B chooses the Block option, the phone can pick up the call and the application on the phone can play an audio message to the caller such as "the party you have called is no longer at this number" or "this line has been disconnected" or any other message determined by the called party B. The Block option could also simply pick up the call and hang it up again, giving the caller the impression that the called party B is unwilling to answer the phone. The Block option could also send a command to the CCF server or the operator network to route the call to voicemail.

Some options, like Block, could trigger a secondary menu, popup, or set of options that shows up on the called party B's phone when selected. The secondary menu could show another set of options that expand on the choice. For example, for the Block option, the user could be asked what message to play for the blocked party when the call is blocked. For the voicemail option, the called party B could be asked what message to play to the calling party. Depending on whether the caller is a personal contact, business contact, anonymous party or nuisance caller, called party B can select the message to be played to this caller. The decision is relayed back to the CCF server via a data connection (HTTP or proprietary API call, or otherwise), SMS message, network call (SS7/PSTN/GSM/CDMA etc).

Other options could be to forward the call to another phone, computer or device. This could optionally trigger a secondary menu asking the caller which destination to forward the call, be it another phone num ber, a long-distance (International) number, voicemail, an auto-attendant, an Interactive Voice Response (IVR) system, a Voice over IP client (for example, a SIP address like ion@sip.msn, com or Skype user's client), etc. This secondary selection can be pre-defined by the user as a list of numbers to choose from, selected from the called party B's address book, or a selection obtained from an online address book such as Facebook's contact list, Google or Gmail's address book, Plaxo, or another source. The online contact list can be downloaded by the application prior to the phone call coming in, when the call comes in, or when the call is forwarded to the CCF service before routing the options back to the called party.

ROUTING BACK TO PHONE VIA VOIP CLIENT ON PHONE

In the event the called party has a VoIP client on his or her mobile phone, one of the options shown to the called party above could be to route the regular incoming mobile call to the VoIP client on the mobile phone. This enables the called party to save money on incoming mobile phone calls by picking up the calls on the VoIP client instead of on the mobile phone's cellular network phone plan. VoIP calls are typically free on certain networks and services such as Skype or using SIP VoIP clients when using WiFi or internet connections. Another benefit of accepting calls on the VoI P client of the phone is so that the called party can pick up calls when cellular coverage is spotty or non-existent at the called party's location. 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 for the regular incoming cellular phone call to the called party's mobile phone to be routed to the VoIP client on the phone, the called party could have 1) been presented with this forwarding choice when the inbound call is received on the phone via an application on the phone or 2) have

unconditionally forwarded the call to the VoIP client using settings for the inbound virtual number, the CCF server, or the carrier's mobile network. In both these cases the inbound call from the cellular network is transformed to a VoIP call using the SIP PSTN gateway that interfaces with the Public Switched Telephone Network (PSTN) on one side and transforms the voice call to a VoIP call on the other side. The VoIP call is then routed directly to the VoIP client on the handset if the handset client is a VoIP client that is able to handle inbound calls directly from the PSTN gateway service provider or carrier network. Otherwise, the call can be routed to the CCF service's servers which can transform the call to a VoIP protocol that the handset's VoIP client can understand. This could be done via translators and transcoders such as a Back to Back User Agent (B2BUA) like Asterisk or FreeSwitch to perform this transformation, or routed to a network such as Skype if the VoIP client on the phone is a Skype client, Other VoIP protocols, clients and services can be used as long as the VoI P call routed to the phone is sent in the correct format and protocol that the application on the phone can understand. In order for the application on the phone to be able to accept the inbound VoIP phone call, the calling part/s call can be routed by the operator and handset to the CCF number and server. From there, there are several ways the call could be routed to the VoIP application on the called party's handset:

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

2) If the application can be invoked by the inbound SMS or push notification, the application can be automatically woken up by the inbound notification and automatically answer the call. Otherwise, the inbound SMS or push notification can pop up onto the screen of the called party's phone with an option to pick up the call or to cancel (or ignore) the call. Picking up the call will cause the VoIP application associated with the push notification to be invoked when the user chooses the option. The VoIP application invoked can either pick up the inbound VoIP call immediately or allow the user to choose to pick up 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 on which to send the incoming VoIP call signaling. This can be performed via a Session Initiation Protocol (SIP) REGISTER command from the handset to the CCF service's SIP server. Other VoIP protocols, proprietary or standards-based, can 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 be running in the background so that it is regularly sending REGISTER messages to the CCF server to notify the server of the appropriate IP address and port number to send the VoIP call to. 3) As an alternative the VoIP application on the phone accepting the inbound VoIP phone call, the VoIP application can, instead, connect to the VoIP server in order to be connected to the called party. This method eliminates Network Address Translation (NAT) issues as phone's VoIP client will dial in and not be dialed to. In this case, the calling party is routed to the CCF server from the operator and handset. The calling party is then placed on hold or waiting for the called party's action. The Push message can cause a ringer like the phone's ringer to ring, emulating an inbound phone call. The Push message will contain a routing address, which could be a SIP address linking the call or a phone number. The 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 (for example, SIP:11928.L717axl-Ahak?.l(S⁾sip.msn.com if SIP is used) that is contained in the push notification or SMS message. The server that is dialed by the called party's VoIP application is able to determine which phone call to connect or bridge the inbound VoIP call to so that the calling party's call is removed from hold and connected to the party that dials in. The address of the SIP INVITE can contain the caller and calling party's information, the call ID, the parking spot and channel, as well as a verification code to authenticate the request to connect to the currently-holding called party.

4) The VoIP application on the called party's phone can be a 3^rd party application such as Skype. In this case, the called party's acceptance of the inbound call request via an SMS, push notification or HTTP request sent from the called party's phone to the CCF server can cause the CCF server to bridge the calling party's call (currently on hold on the CCF server) to the 3^rd party application's (e.g. Skype's) servers. The call when then be routed by the 3^rd party application's (e.g. Skype's) servers to the client (e,g. Skype) application on the called party's handset.

ROUTING BACK TO PHONE VIA VOIP CLIENT ON IP-CONNECTED DEVICES AND COMPUTERS In the event the called party has a VoIP client on a device other than a phone (such as a computer or other IP-connected device such as an iPad or other tablet computing device, referred to here as a computer for simplicity).

In the event the called party has a VoIP client on his or her mobile phone, one of the options shown to the called party above could be to route the regular incoming mobile call to the VoIP client on the computer. This enables the called party to save money on incoming mobile phone calls by picking up the calls on the VoIP client instead of on the mobile phone's cellular network phone plan. VoIP calls are typically free on certain networks and services such as Skype or using SIP VoIP clients when using WiFi or internet connections. Another benefit of accepting calls on the VoIP client of the computer is so that the called party can pick up calls when cellular coverage is spotty or non-existent at the called party's location. 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 for the regular incoming cellular phone call to the called party's mobile phone to be routed to the VoIP client on the computer, the called party could have 1) been presented with this forwarding choice when the inbound call is received on the phone via an application on the phone or 2) have unconditionally forwarded the call to the VoIP client using settings for the inbound virtual number, the CCF server, or the carrier's mobile network or 3) have an application (for example, desktop-based or browser-based) that shows the user options and is invoked when an inbound call is received on the phone or CCF server via push notification or HTTP long poll (COMET).

In these cases the inbound call from the cellular network is transformed to a VoIP call using the SIP PSTN gateway that interfaces with the Public Switched Telephone Network (PSTN) on one side and transforms the voice call to a VoIP call on the other side. The VoIP call is then routed directly to the VoIP client on the computer if the computer client is a VoIP client that is able to handle inbound calls directly from the PSTN gateway service provider or carrier network. Otherwise, the call can be routed to the CCF service's servers which can transform the call to a VoIP protocol that the handset's VoIP client can understand. This could be done via translators and transcoders such as a Back to Back User Agent (B2BUA) like Asterisk or FreeSwitch to perform this transformation, or routed to a network such as Skype if the VoIP client on the phone is a Skype client. Other VoIP protocols, clients and services can be used as long as the VoIP call routed to the phone is sent in the correct format and protocol that the application on the phone can understand.

In order for the application on the phone to be able to accept the inbound VoIP phone call, the calling part/s call can be routed by the operator and handset to the CCF number and server, From there, there are several ways the call could be routed to the VoIP application on the called part/s computer:

1) When the CCF server, mobile operator or cloud number service receives notification from the called part/s phone or computer via HTTP, push, or SMS response that he/she wants to accept the call via the phone's VoIP client, The CCF server, mobile operator or cloud number service can send the called party's computer a push notification or IP-based message (using programs such as Growl) that notifies the VoIP application that an inbound VoIP call is coming in for 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 can wake up or invoke the application to pop up onto the screen of the called party's computer with an option to pick up the call or to cancel (or ignore) the call. Picking up the call will cause the VoIP application associated with the push notification to be invoked when the user chooses the option. The VoIP application invoked can either pick up the inbound VoIP call immediately or allow the user to choose to pick up 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 part/s phone will have to be registered with the CCF's VoIP registrar, providing the registrar with the phone's IP address and port number on which to send the incoming VoIP call signaling. This can be performed via a Session Initiation Protocol (SIP) REGISTER command from the handset to the CCF service's SIP server. Other VoIP protocols, proprietary or standards-based, can be used to inform the server how to send the VoIP call to the called party's computer. The VoIP application on the called part/s computer can be running in the background so that it is regularly sending REGISTER messages to the CCF server to notify the server of the appropriate IP address and port number to send the VoIP call to.

3) As an alternative the VoIP application on the computer accepting the inbound VoIP phone call, the VoIP application can, instead, connect to the VoIP server in order to be bridged to the called party. This method eliminates Network Address Translation (NAT) issues as computer's VoIP client will dial in and not be dialed to. In this case, the calling party is routed to the CCF server from the operator and handset. The calling party is then placed on hold or waiting for the called part/s action. The Push message can cause a ringer like the phone's ringer to ring, emulating an inbound phone call, The Push message will contain a routing address, which could be a SIP address linking the call or a phone number, The 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 (for example, SIP:119281717axl-Ahak21gPsip.msn,com_. if SIP is used) that is contained in the push notification or SMS message. The server that is dialed by the called party's VoIP application is able to determine which phone call to connect or bridge the inbound VoIP call to so that the calling party's call is removed from hold and connected to the party that dials in. The address of the SIP INVITE can contain the caller and calling party's information, call ID and channel or parking spot, as well as a verification code to authenticate the request to connect to the currently-holding called party.

4) The VoIP application on the called party's computer can be a 3^rd party application such as Skype. In this case, the called party's acceptance of the inbound call request via an IP, push notification or HTTP request sent from the called party's phone to the CCF server can cause the CCF server to bridge the calling party's call (currently on hold on the CCF server) to the 3^rd party application's (e.g. Skype's) servers. The call will then be routed by the 3^rd party application's (e.g. Skype's) servers to the client (e.g. Skype) application on the called party's computer,

ALTERNATE IMPLEMENTATION USING MISSED CALL AND DECLINED CALL DETECTION

In situations where handsets have the ability to be made aware of inbound calls (via an operating system or application exception, callback, notification, or other mechanism), the handset operating system or application on the handset ca n present a list of call handling options to the user via a graphical or textual menu of options,

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

The list of options the user can select from are outlined in the other descriptions in this document, and can consist of picking up the call, declining the call, sending the call to voicemail, blocking the call, choosing to route to any number of other phone number or telephony endpoints such as I P phones, IP clients (e.g. Skype, MSM Messenger, Office Communicator, SIP client etc.), play a custom or pre-defined message, a ringtone or ringback tone, a song, an Interactive Voice Response ( IVR) system, or any other voice, messaging or data application that the user wants to route the inbound call to. The unique aspect of this method is that the user is able to choose how to route the call in real time, as the call is received, without being limited to the traditional Answer and Decline (send to voicemail) options available on mobile phones today. As a result, there can be a practically unlimited number of applications, features and functions that can be created and made accessible to the user.

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

The handset application has the option to silence the inbound ringing tone on the recipient's phone and keep the ringing tone playing for the caller as if the recipient's phone is still ringing. In this case, the call is being "held" on the handset before the called party makes a selection. The caller can also be sent to the CCF server while the called party (recipient) is deciding how to handle the call via the list of options, If the call is "held" on the handset and the user elects to pick up the phone, the user's selection to answer the call will simply cause the handset to answer the phone call as a normal call is answered, i.e. no CCF or server need be involved with the answering of the call. If the call is sent to the CCF server while the user is selecting the option, then answering the call would require that the user call in to the CCF service or that the service call back out to the called party's phone as described in the other methods in this document.

If the call is "held" on the called party's handset and the user selects an option that requires that the CCF server connects the call with the service (e.g. calling out to another phone number or VoIP or IM client, playing a server-side ringback tone or sound, or sending to voicemaii on the server etc.), then the user's command or selection can be sent back to the server either before or after the "held" call is sent to the CCF server by the handset (via the Decline option or otherwise),

The user's option can be sent to the server via data connection (e.g. HTTP, TCP socket, etc.), SMS, push notification or some other mechanism available on the handset 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 selection is received by the server prior to the CCF-routed phone call, identified by the caller's phone number and the called party's phone number (for example, via the Diversion header or similar signaling information, is received on the server, the process or handler handling the inbound user selection can wait and poll periodically in a queue (database, memory or otherwise) to check If the inbound call has been received at the CCF server,

If the inbound call, identified by the caller's phone number and the called party's phone number (for example, via the Diversion header or similar signaling information), is received on the CCF servers before the user's option, then the server processes handling the inbound call can periodically poll an inbound request queue (in database, memory or otherwise) that will contain the user's selection when it is received.

When both the CCF-routed inbound call is received at the CCF server and the user's selection is received by the user's selection handler process, the CCF service will then be instructed to handle the inbound call appropriately. For example, the inbound call can be routed to the user's selection (for example, voicemaii, ringing a combination of one or more phones, Skype or other IM client, VoIP client, ringtone or ringback tone, etc). The inbound user selection can also look up the inbound leg of the call on the CCF server (parked call, or ringing / held call) and send the call leg a command to route or bridge itself to the appropriate service (for example, voicemail, ringing a combination of one or more phones, Skype or other IM client, VoIP client, ringtone or ringback tone, etc).

In situations where data connections to the server are not available when the inbound call is being received, the call can be sent to the CCF server by the called party by clicking Decline or similar function on the phone. If the called party does not pick up the phone, the call is likewise sent to the CCF server because the phone is not picked up. Once the call is sent to the CCF server, the phone's OS or application can detect the declined or unanswered call and notify the CCF server of the missed or declined call via IP connection (HTTP, TCP socket or otherwise), push notification or SMS. The CCF server can respond with the options available for the called party based on the calling party's phone number, the called party's preferences and server options. This response can come in the form of a response to the data connection (e.g. the response of the HTTP request, a push notification to this phone, a response to a poll request from the phone, etc.) or sent to the phone after the response from the phone is received by the CCF server. The phone can send along the missed call type (declined, missed, call ended) to the CCF server so that the server can send the appropriate response or option list to the handset.

If a declined call type is received by the CCF server from the handset, the list of options can reflect that - including forwarding to other phones, VoIP or IM clients, etc as described above. If a missed call type is received, the server could send a similar list of options or simply send the call to voicemail automatically because the call recipient hadn't been able to send the call to the CCF server explicitly via the Decline or similar option, thereby indicating that the user would not be able to respond to the options sent by the CCF server as well. If the call type is completed call, the CCF may simply send back a call summary and list of options that are appropriate to the call type where the caller is no longer on the phone (i.e. the call ha ended). These options and preferences can be set up by the called party prior to the call being received and used when the inbound call is received by matching the called party (i.e. via the Diversion header or similar) to the called party's preferences.

The following steps to route inbound calls based on the user's preferences and selection can be performed according to the steps described in other parts of this document.

According to one aspect of the present invention there is provided a method for handling an inbound call being received at a time by a mobile phone, the method comprising: making available, to be chosen by a user of the mobile phone at the time the inbound call is received at the mobile phone, an option to accept the inbound call at the mobile phone, and an option to forward the call from the mobile phone to a service comprising at least one of a server and a telephony switch while the user chooses from one or more further options to determine how the call is handled; and handling the inbound call as determined by the option chosen by the user.

In embodiments the one or more further options may determine where to route the call, and the method may comprise routing the call as determined by the option chosen by the user.

The one or more further options may determine a protocol to use to receive the call, and the method may comprise handling the call using the determined protocol.

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

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

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

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

The service may check if the user has responded with the desired action to choose one of the one or more further options. The one or more further options may comprise at least one of: sending a calling party to voicemail where the calling part is played a message asking the calling party to leave a voicemail message, playing a fax tone to the calling party so as to provide a 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 a switchboard operator, and routing the call to a VoIP or instant messaging address.

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

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

The method may comprise looking up an identification of a calling party of the call in database and providing the identification to the user of the mobile phone, such that the user may determine what to do with the call based on the identification.

The method may comprise forwarding the call to a service comprising at least one of a server and a telephony switch, wherein the service may look up said identification and sends the identification back to the mobile phone.

Alternatively the mobile phone may look up said identification information.

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

The mobile phone may run an application which provides the one or more further options on the mobile phone. The method may comprise 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 further options, wherein the application may send a choice of one of the one or more further options to the service.

The method may comprise providing the application for sale from an online store, such that different application providers enable different options for handling calls.

One of the one or more further options may comprise forwarding the call from the mobile phone 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.

The routing of the call to an IP-accessible address may comprise routing the call back to the mobile phone using VoIP.

According to another aspect of the present invention there is provided a method for handling an inbound call being received at a time by a mobile phone, the method comprising: making available, to be chosen by a user of the mobile phone at the time the inbound call is received at the mobile phone, an option to accept the inbound call at the mobile phone, and one or more other options to determine how the call is handled; and handling the inbound call as determined by the option chosen by the user; wherein the one or more other options comprise at least one of: forwarding the call to another telephone number or address; blocking the call by forwarding the call to a service comprising one of a server and a telephony switch which plays a call block message to a calling party of the call, and storing the calling party's phone number in a database so as to block a subsequent call from the calling party; playing a fax tone to provide a fax receiving service; and forwarding the call to voicemail with an option of what message to play to the calling party. In embodiments the one or more other options may determine a protocol to use to receive th call, and the method may comprise handling the call using the determined protocol.

The method may comprise forwarding the call from the mobile phone to a service comprising one of a server and a telephony switch for handling the call as determined by the chosen one the one or more other options.

The call may be put on hold at the service while the user chooses one of the one or more othe options,

A calling party of the call may be provided with a ring tone or message from the service 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 if the user has responded with the desired action to choose one of the one or more other options.

Alternatively the mobile phone may look up said identification information. The method may comprise forwarding the call to a service comprising at least one of a server and a telephony switch, and sending a message back from the service to the mobile phone providing a number or address for the user to call back in to the service to connect the user to a calling party of the call.

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

The method may comprise 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 application may send a choice of one of the one or more options to the service.

The option of forwarding the call to another address may comprise the option of 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.

According to another aspect of the present invention, there is provided a method for handling an inbound call being received by a mobile phone, the method comprising: forwarding the call from the mobile phone 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 of the user. In embodiments the routing of the call to the IP-accessible address may comprise routing the call back to the mobile phone using VoIP.

According to another aspect of the present invention, there is provided a method for handling an inbound call being received at a time by a mobile phone, the method comprising: making available, to be chosen by a user of the mobile phone at the time the inbound call is received at the mobile phone, an option to accept the inbound call at the mobile phone, and one or more other options to determine how the call is handled; handling the inbound call as determined by the option chosen by the user; and making accessible to the user different applications which provide different ones of said one or more other options for handling calls.

According to another aspect of the present invention, there is provided a computer program product embodied on a computer-readable medium and configured so as when executed on a processor to perform operations in accordance with any of the above method features. The computer program may be embodied on a non-transitory computer-readable medium.

According to another aspect of the present invention there is provided a service comprising one of a server and a telephony switch, wherein the service is configured to perform operations in accordance with any of the above method features.

According to another aspect of the present invention, there is provided a mobile phone configured to perform operations in accordance with any of the above method fatures.

Claims

1. A method for handling an inbound call being received at a time by a mobile phone, the method comprising:

making available, to be chosen by a user of the mobile phone at the time the inbound call is received at the mobile phone, an option to accept the inbound call at the mobile phone, and an option to forward the call from the mobile phone to a service comprising at least one of a server and a telephony switch while the user chooses from one or more further options to determine how the call is handled; and

handling the inbound call as determined by the option chosen by the user.

2. The method of claim 1, wherein the one or more further options determine where to route the call, and the method comprises routing the call as determined by the option chosen by the user.

3. The method of claim 1, wherein the one or more further options determine a protocol to use to receive the call, and the method comprises handling the call using the determined protocol.

4. The method of claim 1, 2 or 3, wherein the service handles the inbound call as determined by the chosen one of the one or more further options.

5. The method of claim 4, wherein a calling party of the call is put on hold while the user chooses one of the one or more further options, such that the calling party is provided with a ring tone or message from the service while on hold.

6. The method of claim 5, wherein the service provides options to the calling party while on hold.

7. The method of any preceding claim, wherein the service provides the one or more further options to the mobile phone.

8. The method of claim 7, wherein the service checks if the user has responded with the desired action to choose one of the one or more further options.

9 The method of any preceding claim, wherein the one or more further options comprise at least one of: sending a calling party to voicemail where the calling part is played a message asking the calling party to leave a voicemail message, playing a fax tone to the calling party so as to provide a 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 a switchboard operator, and routing the call to a VoIP or instant messaging address.

10. The method of any preceding claim, comprising making available to the user an option to block the call.

11. The method of claim 10, comprising adding a calling party of the call to a database of blocked parties.

12. The method of any preceding claim, comprising looking up an identification of a calling party of the call in database and providing the identification to the user of the mobile phone, such that the user can determine what to do with the call based on the identification.

13. The method of claim 12, comprising forwarding the call to a service comprising at least one of a server and a telephony switch, wherein the service looks up said identification and sends the identification back to the mobile phone.

14. The method of claim 12, wherein the mobile phone looks up said identification information.

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

16. The method of any preceding claim, wherein the mobile phone runs an application which provides the one or more further options on the mobile phone.

17. The method of claim 16, comprising 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 further options, wherein the application sends a choice of one of the one or more further options to the service.

18. The method of claim 16 or 17, comprising providing the application for sale from an online store, such that different application providers enable different options for handling calls.

19 The method of any preceding claim, wherein one of the one or more further options comprises forwarding the call from the mobile phone 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.

20. The method of claim 19, wherein the routing of the call to an IP-accessible address comprises routing the call back to the mobile phone using VoIP.

21. A method for handling an inbound call being received at a time by a mobile phone, the method comprising: making available, to be chosen by a user of the mobile phone at the time the inbound call is received at the mobile phone, an option to accept the inbound call at the mobile phone, and one or more other options to determine how the call is handled; and

handling the inbound call as determined by the option chosen by the user;

wherein the one or more other options comprise at least one of:

forwarding the call to another telephone number or address;

blocking the call by forwarding the call to a service comprising one of a server and a telephony switch which plays a call block message to a calling party of the call, and storing the calling party's phone number in a database so as to block a subsequent call from the calling party;

playing a fax tone to provide a fax receiving service; and

forwarding the call to voicemail with an option of what message to play to the calling party.

22. The method of claim 21, wherein the one or more other options determines a protocol to use to receive the call, and the method comprises handling the call using the determined protocol.

23. The method of claim 21 or 22, wherein comprising forwarding the call from the mobile phone to a service comprising one of a server and a telephony switch for handling the call as determined by the chosen one of the one or more other options.

24. The method of claim 23, wherein the call is put on hold at the service while the user chooses one of the one or more other options,

25. The method of claim 24, wherein a calling party of the call is provided with a ring tone or message from the service while on hold.

26. The method of claim 25, wherein the service provides options to the calling party while on hold.

27. The method of any of claims 23 to 26, wherein the service provides the one or more other options to the mobile phone.

28. The method of claim 27, wherein the service checks if the user has responded with the desired action to choose one of the one or more other options.

29. The method of any of claims 23 to 28, comprising looking up an identification of a calling party of the call in database and providing the identification to the user of the mobile phone, such that the user can determine what to do with the call based on the identification.

30. The method of claim 29, comprising forwarding the call to a service comprising at least one of a server and a telephony switch, wherein the service looks up said identification and sends the identification back to the mobile phone.

31. The method of claim 29, wherein the mobile phone looks up said identification information.

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

33. The method of any of claims 23 to 32, wherein the mobile phone runs an application which provides the options on the mobile phone.

34. The method of claim 33, comprising 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 application sends a choice of one of the one or more options to the service.

35. The method of claim 33 or 34, comprising providing the application for sale from an online store, such that different application providers enable different options for handling calls.

36. The method of any preceding claim, wherein the option of forwarding the call to another address comprises the option of 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.

37. The method of claim 36, wherein the routing of the call to an IP-accessible address comprising routing the call back to the mobile phone using VoIP.

38. A method for handling an inbound call being received by a mobile phone, the method comprising:

forwarding the call from the mobile phone 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 of the user.

39. The method of claim 38, wherein the routing of the call to the IP-accessible address comprises routing the call back to the mobile phone using VoIP.

40. A method for handling an inbound call being received at a time by a mobile phone, the method comprising: making available, to be chosen by a user of the mobile phone at the time the inbound call is received at the mobile phone, an option to accept the inbound call at the mobile phone, and one or more other options to determine how the call is handled;

handling the inbound call as determined by the option chosen by the user; and making accessible to the user different applications which provide different ones of said one or more other options for handling calls.

41. A computer-program product embodied on a computer-readable medium and configured so as when executed on a processor to perform operations in accordance with any of claims l to 40.

42. A service comprising one of a server and a telephony switch, wherein the service is configured to perform operations in accordance with any of claims 1 to 40.

43. A mobile phone configured to perform operations in accordance with any of claims 1 to 40.