WO2013059480A1

WO2013059480A1 - Conversion dialing system and method

Info

Publication number: WO2013059480A1
Application number: PCT/US2012/060841
Authority: WO
Inventors: Daniel Currie
Original assignee: Smartroam Pte Ltd.
Priority date: 2011-10-18
Filing date: 2012-10-18
Publication date: 2013-04-25

Abstract

Systems and methods for identifying and addressing telecommunication endpoints are provided. The system provides an initiating caller with the ability to dial a telephonic number, while the system converts that telephonic number into an internationally recognized format. The system further connects the initiating party with the receiving party using local access numbers such that the receiving party is connected to a conference room via a local access number and the initiating party is connected to the same conference room via a local access number.

Description

CONVERSION DIALING SYSTEM AND METHOD

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims priority to and incorporates by reference in its entirety U.S. Provisional Patent Application No. 61/548,481, filed October 18, 2011.

FIELD OF THE DISCLOSURE

[0002] The present disclosure relates to identifying and addressing telecommunication endpoints. More particularly, the invention relates to identifying the origin and the designation in a reliable manner using an address.

BACKGROUND OF THE DISCLOSURE

[0003] With the world becoming ever so networked, communication between individuals has grown by leaps and bounds. Such growth has been witnessed both in the quality of the communication and more importantly, the quantity. With any communication, the biggest challenge is to identify the origin and the destination reliably using an address. While the communication between computers has grown in parallel, there has not been as much of a challenge of lack of standards in identifying an origin or a destination computer. A computer understands an IP address, whether it be an IPv4 or an IPv6 or any other standard in the future, and makes no qualms about using this single standard of identifying and

corresponding with fellow computers.

[0004] In case of individuals however, this is not all that straightforward, especially in the case of telephonic communications. While standards such as E.164, are prevalent in telecommunications, there are many problems faced in the end-to-end practical

implementation of these standards. [0005] One problem is the constant endeavor of humans to lower the resources required in performing any task, whether the resource be the effort, time or monetary cost of a task. Thus, users tend to abbreviate telephone numbers or addresses. For instance, individuals prefer to forego dialing the international country code of their country, in exchange for a local prefix like '0' - for a saving of effort time of punching in merely one or two additional digits. These abbreviations do not adhere to the industry standards in identifying addresses of the parties involved in telephonic communications. Thus, an end-to-end implementation of a communication system recognizing these abbreviations is problematic. On the other end of the spectrum, some individuals may prefer to dial lengthy 6-7 digit number-prefixes to route the call via cheaper routes.

[00O6] This problem is largely ignored by the communication-backend of such telephonic services. Often, these services define rigid rules on how an individual must be addressed. If the user behavior does not comply, the communication is simply rejected. Such handling of the problem comes at the expense of the user experience within the system.

[0007] Other present-day solutions to this problem are sparse and limited in functionality. Two particular problems with other solutions are that the solutions are not comprehensive in handling all the different ways of addressing point B from point A, and/or the solutions are limited to the scope of where point A or B can be. Any telephony service that aims to function independent of the individual's standard-less addressing system, needs to be aware of not just all possible ways of addressing point B from point A, but also a way of representing, maintaining and building on such routes.

[0008] Any telephony service that aims to function independent of the individual's standard- less addressing system, needs to be aware of not just all possible ways of addressing point B from point A, but also a way of representing, maintaining and building on such routes. [0009] These and other drawbacks exist. SUMMARY OF THE DISCLOSURE

[0010] The disclosed configurations aims to provide a telephony service and system that functions independent of an individual's standard-less addressing system. A telephony service in one embodiment may be able to convert any telephonic number (of a destination) entered by an individual, into an industry standard full -normalized international phone number format.

[0011] In order to achieve this service, a system may maintain a list of Dialing Rules. The Dialing Rules specify how a telephonic number, entered in any format by an individual, can be converted into the industry-standard representation of the entered number. The Dialing Rules are based not just on the destination number, but also the origin number. The use of the origin number and destination number allows the Dialing Rules to fully define the context of when the individual is entering the destination number. The Dialing Rules list is designed to be easily expandable and maintainable, to keep up with the ever changing new methods of addressing a telephonic destination.

[0012] The system may include an initiating party device that may connect to an APP server and a DID iocal gateway, which may then in turn be connected to a PBX system. The system further includes a receiving party device that may also be connected to the APP server and a

DID local gateway, which may then in turn be connected to the PBX system. The APP server may also be connected to a DB server. Once the initiating party inputs a destination number on the initiating party device (usually via a client application) the APP server may receive the destination number, which is associated with a receiving party device. The

Dialing Rules help to route the call to the receiving party device such that a call prompt is received at the receiving party device. Both the initiating party device and the receiving party device dial a respective local access number (preferably in an automatic fashion) whereby both parties are placed in a conference room of the PBX system where they may then maintain a call.

[0013] BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 depicts a system for providing conversion dialing;

[0015] Figure 2 depicts an exemplary method of conversion dialing;

[0016] Figure 3 depicts an exemplary method for initiating a call using a conversion dialing system;

[0017] Figure 4 depicts an exemplary method for connecting a recipient a call using a conversion dialing system;

[0018] Figure 5 depicts an exemplary sequence diagram for initiating a call when an Internet connection is available using a conversion dialing system;

[0019] Figure 6 depicts an exemplary sequence diagram for initiating a call when an Internet connection is not available using a conversion dialing system;

[0020] Figure 7 depicts an exemplary sequence diagram for patching a call using a conversion dialing system; and

[0021] Figure 8 depicts an exemplary method for interpreting and processing a telephone number associated with a receiving party.

[0022] DETAILED DESCRIPTION OF THE DISCLOSURE

[0023] The following description is intended to convey a thorough understanding of the embodiments described by providing a number of specific exemplary embodiments and details involving systems and methods for conversion dialing. It should be appreciated, however, that the present disclosure is not limited to these specific embodiments and details, which are exemplary only. It is further understood that one possessing ordinary skill in the art, in light of known systems and methods, would appreciate the use of the invention for its intended purpose and benefits in any number of alternative embodiments, depending on specific design and other needs.

[0024] The disclosed configurations aim to provide a telephony system for ideal voice communications satisfying the deficiency criteria noted above. The disclosed configurations aim to provide, on the user-side, an application that allows for user-friendly calling experience, allowing a user to utilize a contact listing or dial directly. Receiving a call should be equally user-friendly, such as responding to a call prompt. And finally, in using the disclosed configuration, the quality of the call should be of a high quality, given the system infrastructure, and a low cost, given the capability for the users to be connected using a local call.

[0025] In order to achieve this service, the system ensures that: a) it does not require the initiating user to punch in any prefixes or dual-tone multi- frequency (DTMF) touch tones to initiate a call, which makes it complicated to initiate a call; b) it does not require the recipient of the call to do any more than pressing a button or acting on an incoming call prompt; c) it does not send any portion of the voice communication or voice data over the mobile internet connection, which has low bandwidths and high drop rate, and hence bad quality; and d) it does not use the mobile carrier's telephone network for any distance longer than two local calls: one local call from the caller to the system's access number available in the caller's country and one local call from the recipient to the system's access number available in the recipient's country. Hence, the cost of the communication does not exceed that of two local calls.

[0026] The system and methods described herein may provide a client application which callers may download to a mobile device, such as a smartphone. The application makes it easy for the user to place calls, by imitating the user experience of the phone's original wireless call interface. Callers can easily make a phone call by either selecting a phone number in the contact list, or directly punching in the calling number.

[0027] As depicted in Figure 1, system 100 may include an initiating party device 120 and a receiving party device 130. The initiation party device 120 and the receiving party device 130 may be any mobile or computer-related device capable of executing a software-based solution for conversion dialing. For example, the initiation party device 120 or the receiving party device 130 could be an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS operating system, any device running Google's Android® operating system, any device running Microsoft's Windows® Mobile operating system, and/or any other smartphone, wireless phones, Personal Digital Assistants (PDA), desktop computers, laptop computers, servers, other computers or any combination thereof. Initialing party device 120 and/or receiving parry device 130 may include an external or internal camera.

[0028] The initiating party device 120 or receiving party device 130 may include for example, a Subscriber Identity Module (SIM) card and an App Processor. The SIM card may be an integrated circuit that securely stores the service-subscriber key (IMSI) used to identify a subscriber on mobile telephony devices (such as mobile phones and computers). The App Processor may enable execution of software applications on the initiating party device 120 or the receiving party device 130. [0029] The initiating party device 120 or receiving party device 130 may also include various software components to facilitate the performance of conversion dialing. For example, the devices 120, 130 may include an operating system such as, for example, the iOS operating system from Apple, the Google Android operating system, and the Windows Mobile operating system from Microsoft. The initiating party device 120 or receiving party device 130 may also include, without limitation, software applications such as a conversion dialing application to facilitate the performance of conversion dialing and software to enable touch sensitive displays. Mobile device manufacturers may provide software stacks (APIs) which allow software applications to be written on top of the software stacks.

[0030] The initiating party device 120 or receiving party device 130 may include a display, which may display software, including software applications, executing on the device 120, 130 By way of a non-limiting example, one of the software applications executing on devices 120, 130 may include a dialing application. In various exemplary embodiments, a dialing application may enable a software-based solution to perform conversion dialing. A user may select a calling application, by for example, via a touch display, which may then launch or otherwise cause the execution of a conversion dialing application.

[0031] Figure 1 further depicts various systems, servers and gateways that may be used in the conversion dialing system and method. The various systems, servers, and gateways may be connected over one or more of a wireless network, a wired network, or any combination of wireless and wired networks. For example, the one or more networks may include one or more of a fiber optics network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless LAN, a Global System for Mobile Communication ("GSM"), a Personal Communication Service ("PCS"), a Personal Area Network ("PAN"), D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE 802.11b, 802.15.1 , 802.1 In and 802.1 lg or any other wired or wireless network for transmitting and receiving a data signal,

[0032] In addition, the one or more networks may include, without limitation, telephone lines, Fiber optics, IEEE Ethernet 902.3, a wide area network ("WAN"), a local area network ("LAN"), or a global network such as the Internet. Also, the one or more networks may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. The one or more networks may further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. The one or more networks may utilize one or more protocols of one or more network elements to which they are communicatively coupled. The one or more networks may translate to or from other protocols to one or more protocols of network devices.

[0033] Figure 2 illustrates an exemplary method of performing call conversion 200 using a call conversion system 100. In order to make a call, a client application may be downloaded and installed on an initiating party device 120. The client application may receive a user request to place a call from the initiating party device 120. The user may initiate the call by either selecting a phone number from art address book on the initiating party device 120, or simply punching a number into a keypad or the like on the user interface of the client application (step 210) on the initiating device 120.

[0034] Once a call is placed, the client application on the initiating party device 120 may contact a server and informs the server 140 of the call that the caller has placed (step 220). The server 140 routes an incoming call prompt (step 230) to the receiving party device 130. The client application on the receiving party device 130 may then automatically dial a local access number preconfigured into the client application or may provide details about the call if the receiving party device 130 does not have the client application (step 240). The user of the initiating party device 120 may automatically be placed in a "conference room," or a similar virtual environment, where he or she is listening to a ringtone as if the call has been forwarded to the receiving party device 130.

[0035] A conference room may be a virtual environment where the caller of the initiating party device 120 and the caller of the receiving party device 130 are placed such that the parties may converse. The conference room may also be a designated waiting area where the parties are placed while waiting to be connected to the other party or parties. The conference room may be housed in the PBX system 170 which may comprise one or more servers.

[0036] The receiving party device 130 may act on the call prompt sent to the receiving party device 130 (step 250). If receiving party device 130 acts on the call prompt before a timeout is reached, the receiving party device 130 may automatically call a local access number (step 250) in the country or the receiving party device 130. The result of that call may be that the receiving party device 130 is added to the conference room, where the voices of both the initiating party associated with the initiating party device 120 and the receiving party associated with the receiving party device 130 may be exchanged, resulting in an experience identical to placing a voice call over a mobile carrier's telephone network (step 250).

[0037] In order to provide clear voice communication, so that the three exemplary criteria, the ease of use, the high voice quality, and the low cost, can be satisfied, the proposed system 100 may include the following key components as depicted in Figure 1 : a) a client application installed on at least an initiating party device 120, b) local access numbers obtained from direct inward dialing (DID) service providers in each country 160, where the system 100 is to be deployed to support the call conversion, c) a class 5 PBX system 170 with conference room capabilities, and d) an application (APP) server 140 and a database (DB) server 150 which interface with other key components.

[0038] Figure 3 further illustrates an exemplary process of initiating a call using a call conversion system, After receiving the user's request to place the call 210, the client application may forward the call request to the call conversion system 100, instead of handing the call directly over the carrier's mobile network. The call conversion system 100 may handle the incoming call request differing depending on whether the initiating party device 120 has access to any mobile Internet connections (step 214).

[0039] When an Internet connection is available, the client application on the initiating party deice 120 may send a secure hypertext transfer protocol (HTTPS) POST request to the APP server 140 of the call conversion system to authenticate itself (step 220). The POST request may provide details on the phone number associated with the initiating party device 120 and the phone number of the receiving party device 130. The APP server 140 may then acknowledge the request and check whether the receiving party device 130 is associated with another call (step 222) to the system 100. If the receiving party device 130 is indeed associated with another call, the calling client application associated with the initiating party device 120 is informed that the called party is busy. Otherwise, the APP server 140 may proceed to the next step to setup the call. In one embodiment, the call conversion s stem may deploy a Resin® J2EE Application server as the APP server 140, which may be coupled to a MSSQL® DB server 150.

[0040] The APP server 140 may setup the call through a class 5 PBX system 170 with conferencing capabilities. In an embodiment, an Asterisk® PBX system 170 may be coupled to the Resin® J2EE application server 140 using an Asterix® management interface. The Asterisk® PBX system 170 may fetch configurations from the MSSQL DB server 150 in real time through an Asterisk® RealTime interface, which is an API that connects the PBX system 170 to the DB server 1 0 using a plain text protocol over the transmission control protocol (TCP) sockets.

[0041] Next, the client application on the initiating party device 120 may automatically dial a local access number preconfigured by the system (step 224). The local access number may be assigned by a DID service provider at DID gateway 160. For example, in one embodiment, and without limitation, Voxbone may be the DID service provider 160 used for the call conversion system 100. The call from the to the local access number is then relayed to the PBX conference system 170 over the real-time transportation protocol (RTP) (step 226). The conference system, which may be preconfigured by the APP server 140 to expect a call from a number associated with the initiating party device 120, identifies the caller and places him/her in a newly created conference room (step 240).

[0042] The conference system 170 may be configured such that the default hold prompt is replaced with a ringback when a caller is waiting in the conference room, to sound like ring tones associated with (he receiving party device 130. This arrangement mimics the experience of regular phone calls over the carrier's network, and creates an illusion for the initiating party that the receiving party device 130 is currently ringing and waiting to be answered.

[0043] In the event that the user's mobile device doesn't have access to Internet, the client application may automatically fall back to a DTMF based call initiation process.

[0044] In this approach, the client application on the initiating party device 120 may dial di local access number of the call conversion system which, with the number of the receiving party device 130 suffixed to the local access number as DTMF touch tones (step

216). Similarly, the local access number can be acquired from a DID service provider at DID gateway 160, such as Voxbone®. The call from the initiating party device Ϊ20 to the system's local access number may then relayed to the PBX conference system 170 over the RTP protocol (step 218). When the PBX conference system 170 receives the call, the conference system 100 automatically creates a new conference room and places the user of the initiating party device 120 in it (step 240).

[0045] In the meantime, the PBX system 170 may inform the APP server 140 of the recipient number received as DTMF tones (step 220). If the receiving party device 130 is found out to be associated with another call with the system 100 (step 228), an appropriate interactive voice response (IVR) message is played to the initiating party device 120 in the conference room and the call is disconnected. Otherwise, the call setup may be carried on by the APP server 140 (step 240). Similarly, the conference system may be configured to replace the default hold prompts with a ringback when the user of the initiating party device 120 is waiting in the conference room.

[0046] After the caller initiates t!ie call and is placed in a conference room of the PBX system 170 where a ringback is played, the APP server 140 continues to setup the call by prompting the recipient. The incoming call prompt sent to the recipient can be in different formats, depending on whether or not the recipient is a user of the system witli the client application installed on his device 130.

[0047] Once a call is placed from the initiating party device 120 and the APP server 140 sets up the call (step 210), the receiving party device 130 may be notified of the call. If the receiving party device 130 has installed the same client application (step 252), the APP server 140 may send a PUSH notification to the recipient through the PUSH notification service of the a receiving party's service provider (step 254). For example, in one embodiment, a PUSH notification can be delivered via Apple's PUSH notification service if the reci ient uses an iPhone®. The PUSH notification used for this purpose can be a custom format only recognized by the client application residing on the receiving party device 1 0.

[0048] The PUSH notification may contain information on the caller associated with the initiating party device 120 who is attempting to call the receiving party device 130, the local access number that the receiving party device application needs to dial to answer the call, the time of the call placed, and a security signature to ensure the PUSH notification is authorized by the call conversion system 100. The PUSH configuration may also be configured to ring on the receiving party device 130, thus mimicking the behavior of a regular incoming call. A user of the receiving party device 130 may have the option to answer or reject the call.

[0049] If the receiving party device 130 ignores the PUSH notification or the PUSH notification is delayed due to service hiccup, the receiving party device 130 may see a missed call notification on a display of the receiving party device 130 including the initiating party device 120 information (e.g., phone number, name, etc.) and the time the call was placed, similar to a missed regular voice call. The missed call notification may also offer a convenient option to call back, in which case the call setup process is restarted with the recipient as the initiating party.

[0050] If the recipient is not a user of the system (step 252), the call conversion system 100 may then send a Short Message Service (SMS) message as the incoming call prompt to the receiving party device 130 (step 256). The SMS may carry details of the initiating party device 120 information (e.g., phone number, name, etc.) and the local number that the receiving party device 130 needs to dial, if the recipient chooses to answer the call. For example, the SMS sent by the system may look like "John Doe is calling you. If you would like to answer his call, kindly click on 0911111111." An SMS often rings on a mobile device (such as the receiving party device 130) and thus alerts the recipient of the incoming call.

[0051] As described above, after the caller initiates the call and is placed in a conference room, a ringback is played to give the caller an impression that the recipient's phone is ringing and waiting to be answered. The system 100 next informs the recipient of the incoming call, Once the recipient is connected, the system patches the call between the caller and recipient to allow them to converse (step 260).

[0052] The incoming call prompt, such as a PUSH notification or a SMS message, carries a local access number selected by the APP server 140. When the recipient acts on the incoming call prompt and answers the call, a local call is actually placed from the recipient' s phone to the local access number (step 260). In one embodiment, the access number is obtained from a DID service provider at DID gateway 160, such as Voxbone®. The call from the recipient's mobile device to the system is relayed to the Asterisk PBX conference system 170 over RTF protocol.

[0053] The PBX conference system 170, which was previously configured by the APP server 140 to expect a call from the recipient's number, identifies the recipient and adds htm into the conference room where the initiating caller may be kept waiting. As soon as the initiating caller and recipient are both in the conference room, they can start talking the same way as in a regular voice call over the mobile network.

[0054] In more detail, various embodiments of the system 100 provide the ability to convert any telephone number associated with a receiving party device 130 entered at a initiating party device 120, into an industry standard, fully-normalized international phone number format. In order to achieve this service, the system 100 may maintain a listing of Dialing Rules. The Dialing Rules may specify how a telephonic number, entered in any format by an individual on an initiating party device 120, can be converted into the industry-standard representation of the entered number. The Dialing Rules are based not just on the number associated with the receiving party device 130, but also the number associated with the initiating party device 120. The use of the origin number at the initiating party device 120 and destination number at the receiving party device 130 allows the Dialing Rules to fully define the context of when an individual is entering the destination number. The Dialing Rules list is designed to be easily expandable and maintainable, to keep up with the ever changing new methods of addressing a telephonic destination.

[0055] A Dialing Rule may be defined as illustrated in Table 1 below. A Dialing Rule may carry a set of constraints to determine whether that Rule is applicable for a user of an initiating party device 120. This determination may be based on the present location of the initiating party device 120, and based on the number entered at the initiating party device 120 and associated with the receiving party device 130.

Dialing Rule Attribute Attribute Description

Target Audience This attribute reflects the origin country codes (in ISO 3166-1 alpha-2 format) that an individual must originate from or not originate from, for a rule to apply

Destination Length This attribute reflects the length constraint for a rule to appl to the number entered by the individual

Destination Prefix This attribute reflects the possible or prohibited prefixes of the number entered by the individual for a rule to apply

Destination Substitute This attribute reflects the replacement string to be used in place of the Destination Prefix to make it of international standard.

Remark This attribute reflects the sanctity of the processed number via a rule

Table 1

[0056] The semantics used in the attributes of each Dialing Rule should be adequate to accurately define the constraint and the computation involved in interpretation and processing of a destination telephonic number. Table 2 below defines exemplary semantics of the Dialing Rule attributes. Table 3 below provides examples of which of the Dialing Rule attributes are needed to support the various semantics.

Semantics Description

* Wild card, to represent "any"

? Wild card, to represent "any single digit"

! Negation, to represent "NOT"

Conjunction, to represent "OR" in case of non-negated constituents; and to represent "AND" in case of negated constituents

> Comparator, to represent the numeric "Greater Than" constraint

< Comparator, to represent the numeric "Less Than" constraint

MYNUMBER Placeholder, to represent the initiating party's fully qualified

international number, without the '+^* and the country code

DESTINATION Placeholder, to represent the receiving parry's telephonic number as entered

COUNTRYCODE Placeholder, to represent the numeric country code of the initiating party, without th '+'

TARGETCOUNTRY Placeholder, to represent the probable numeric country code of the receiving party entered by the initiating party, without the V

LENGTH(X) Function, to return the length of string X

SUBSTRINGS, Y) Function, to return the first Y characters of string X

INVALID Remark response, to mention that the processed number is not a valid internationally formatted phone number

WARN Remark response, to mention that it is possible t at the receiving party telephonic number entered by the initiating party is typed incorrectly and hence it is best to warn to re-check the number entered

TOIXFREE Remark response, to mention that the processed number is a toll free destination and is hence not an internationally formatted phone number

NATIVE Remark response, to mention that the processed number is only

accessible to a party's country, and that it is not an internationally formatted phone number (e.g., a telecom operator shortcode)

Table 2

Dialing Rule Attribute Semantics To Support

Target Audience *

!

Destination Length *

>

<

MYNUMBER LENGTHCX)

Destination Prefix ?

t

TARGETCOUNTRY

Destination Substitute MYNUMBER

DESTINATION

COUNTRYCODE

TARGETCOUNTRY

SUBSTRTNG(X,Y)

Remark INVALID

WARN TOLLFREE NATIVE

Table 3

[0057] Assuming a list of Dialing Rules are available and the ability to interpret the Dialing Rules is in place, the call may be placed to the server (e.g., APP server 140) (step 220) such that the call may then prompt the destination (i.e., the receiving party device 130) (step 230). The Dialing Rules and dialing application may be stored on the DB Server 150 and/or the APP server 140, as well as on an initiating party device 120 or receiving party device 130.

[0058] Figure 8 illustrates an exemplary process associated with interpreting and processing a telephone number associated with a receiving party device 130, which was entered into an initiating party device 120. A dialing rules processor associated with the dialing application may receive MYNUMBER, COUNTRYCODE, and DESTINATION (step 802). MYNUMBER and COUNTRYCODE may be received from data stored on the initiating party device 120, or may be received from information stored elsewhere, such as DB Server 150. DESTINATION may be received from information input into the initiating party device 120 by the initiating party.

[0059] The process continues such that a pre-output is determined (step 804) using a pre- dialing rules processor which may receive DESTINATION as an input. If DESTI ATION is empty, die pre-dialing rules processor will return empty as (he pre-output. If

DESTINATION has more than one PLUS, the pre-dialing rules processor may return empty as the pre-output. When the pre-output is empty, the dialing rules engine will return INVALID (step 808), The pre-dialing rules processor may strip any character in the DESTINATION that is not a PLUS, COMMA, 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9; a!l characters in the DESTINATION preceding a PLUS; and all characters in the DESTINATION following a COMMA; or a PLUS where the DESTINATION starts with a "+0". Once all necessary characters have been stripped, the pre-dialing rules engine will return the remaining DESTINATION as the pre-output (step 804).

[0060] The pre-output may then be used as an input for a core dialing rules processor. A core-dialing rules processor may apply Dialing Rules to the pre-output in order to return a first core output (step 810). The first core output may then be used as an input for the core dialing rules processor again in order to verify the number and produce a second core output (step 816). This second iteration may verify that the DESTINATION was correctly converted into an internationally formatted phone number (i.e., the first core output should run through the core dialing rules processor unscathed). If this second iteration produces a second core output that is different from the first core out ut, the first core output may be determined INVALID (step 818) and the first core output may be returned with a NATIVE remark (step 820), [0061] If the first core output and the second core output match, a post-dialing rule processor may then receive the first or second core output as well as Dialing Rules in order to produce a final-output and any associated remarks (step 822).

[0062] Both the core dialing rules processor and the post-dialing rules processor may invoke Dialing Rules. However, the Dialing Rules used by the core dialing rules processor and the Dialing Rules used by the post-dialing rules processor may be different.

[0063] In applying the Dialing Rules in either the core dialing rules processor or the post- dialing rules processor, either processor may iterate through each Dialing Rule. As illustrated in Table 1, the Dialing Rules may contain a target audience, a destination length, a destination prefix, a destination substitute and a remark,

[0064] The target audience for each rule may determine whether or not the particular rule is applicable for the input (e.g., the pre-output or the first/second core output). Where the target audience is "*" the Dialing Rule may be applicable to all. Where the target audience is a comma separated value (CSV) or a single entry of positive constraints (e.g., XX, YY, ZZ) then the Dialing Rule may be applicable to the input at hand only if the origin country (i.e., the country where the initiating party device 120 is located) ISO code matches the CSV or positive constraints (e.g., XX, YY, ZZ), Where the target audience is a CSV or a single entry of negative constraints ( e.g., !XX, !YY, !ZZ), then the rule is applicable to the input at hand only if the origin country (i.e., the country where the initiating party device 120 is located) is neither the CSV(s) or entries (e.g., not XX, YY, ZZ).

[0065] The destination length may determine whether or not a particular Dialing Rule is applicable for the input (e.g., the pre-output or first/second core output). A destination length may contain an expected length of the input for a particular Dialing Rule to apply.

Where the destination length is "*" the Dialing Rule may be applicable to all lengths. Where the destination length contains "LENGTH( YNUMBER)", the Dialing Rule may be applicable to lengths of the length of MYNU BER. Where the destination length is "=X", "=>X", or "=<X", the Dialing Rule may be applicable where the length is equal to X, greater than X, or less than X, respectively,

[0066] The destination prefix may determine whether or not a particular Dialing Rule is applicable for the input (e.g., the pre-output or first second core output). Destination prefixes may contain the expected prefix of the input for a particular Dialing Rule to apple. Where the destination prefix is "*", the Dialing Rule may be applicable to all destination prefixes. Where the destination prefix begins with !, the Dialing Rule may not be applicable if the input starts with the same characters which follow the ! in the destination prefix. If the destination prefix contains "TARGETCOUNTRY" , then the destination prefix should equal the country code based on the prefix that best matches the input. If not country code is found, the next Dialing Rule may be examined. If the destination prefix length is greater than the input, then the Dialing Rule may not apply. Finally, where a destination prefix contains a CSV or a single entry of prefixes (e.g., XX, YY, ZZ), then the rule is applicable to the input starting with the CSV or entry (e.g., XX, YY, ZZ). Any "?"s in the destination prefix may be treated as number wild cards (e.g., X? will match X0, XI , X2, etc.).

[0067] The destination substitute may determine what the destination prefix in the input needs to be replaced with, If a destination substitute contains "COU TRYCODE", the field should be replaced with the country code of the initiating party device 120. If a destination substitute contains "SUBSTRING(MYNUMBER,X)", where X is a number, the field should be replaced with the first X characters of the number associated with the initiating party device 120. If a destination substitute contains "SUBSTRING(DESTINATION, X), where X is a number, then the field should be replaced with the first X characters of the number associated with the receiving party device 130 that was input into the initiating party device 120, If a destination substitute contains "TARGETCOUNTRY", then the field should be replaced with the country code based on the prefix that best matches the input. If no country code is found, then the next Dialing Rule may be examined. Once the destination substitute is determined, the core dialing rules engine may remove the destination prefix from the input and add the destination substitute as a new prefix to the input to generate the output (steps 810, 816, and 822).

[0068] Once any rule is applied such that the target audience, destination length, and destination prefix matches the input resulting in the destination substitute replacing the destination prefix, the core dialing rules processor or post-dialing rules processor may stop and return the result and/or any remark associated with the selected Dialing Rule (steps 812-814 and 822).

[0069] The above descriptions present the process of making a call using the call conversion system including initiating a call, prompting the recipient, and patching (lie call. However, in some instances, special scenarios and error handling may happen during the calling process.

[0070] If the recipient does not answer the call because the recipient does not hear the call, does not want to answer the call, rejects the call, receives a delayed incoming call prompt, or for any other reasons, there is a risk that the caller associated with the initiating party device 120 is been held indefinitely or waiting in the conference room of the PBX system 170, To mitigate such a scenario, the waiting in the conference rooms may automatically timed o t after a short period, for example, 30 seconds. When the caller in the conference room starts hearing a ringtone that gives the illusion of the receiving party device 130 ringing and waiting to be answered, a timer also starts ticking. If the reci ient associated with the receiving party device 130 does not join the conference room before timeout, a corresponding IVR message is played to inform the caller associated with the initiating party device 120 that the recipient is busy. The call is then automatically disconnected. This process again resembles how a normal call behaves over the mobile voice network when the receiving party does not answer within a stipulated time, thus further re-enforcing the illusion that the caller is placing a call not differently from any normal calls made over the carrier's mobile voice network.

[0071] The timeout may be handled by a separate service running on the APP server 140. In one embodiment, the APP server 140 is a Resin J2EE APP server. For the purpose of tliis timeout, a service is running on Quartz task scheduler over Resin, to monitor each conference room on the Asterix PBX system 170.

[0072] If the recipient answers the call late because he or she does not hear the call, was busy, receives a delayed incoming call prompt, or for any other reasons, it is possible that the receiving party device 130 is calling into the conference room after the caller associated with the initiating party device 120 has timed out and has already disconnected. This may keep the recipient indefinitely waiting for the caller who is no longer available. To avoid such scenarios, an automatic IVR message is played back to inform the recipient that the caller associated with the initiating party device 120 has disconnected as soon as his call is received.

[0073] In normal cases, the expected sequence of events involves that the caller dials in first and is placed in a conference room, followed by the recipient's dial in, and the caller and the recipient being patched into the conference room. However, there can be scenarios where the caller's call to his access number takes slightly longer to connect, while the recipient dials in and is connected before the caller. To cater for such scenarios, the conference room is created no matter which of the two parties dials in first. Therefore, the first party connected always has a conference room created for the call, while the party dialing in second is patched into the conference room.

[0074] In addition to the features described above, additional features may be available as well. For example, having calling line identification (CLE)) turned off is a feature some users like to have to ensure that their numbers is not visible to others for privacy concerns. The proposed system fully supports this feature, which is a natural extension to the system. When the user chooses to turn his CLID off, he only needs to configure this setting on the client application residing on the initiating party device 120. With this setting off, the incoming call prompt sent to the receiving party device 130 or the missed call prompt displayed on the receiving party device 130 automatically blocks the CLID of the caller and instead displays the tag of an "unknown caller" to the recipient.

[0075] Another feature that may be provided by the embodiments disclosed includes providing the call history, such as whom a user has called, when the user called, how long the user spoke. To provide this feature in the proposed system, a call data record (CDR) system (which may be housed in the DB Server 150 or externally (not shown)) connected to the Asterix PBX 170. This allows the call information generated on the Asterix PBX 170 to be exported into the CDR system, thus providing users the access to their call history.

[0076] The embodiments of the disclosure provide a telephony system that offers an ideal telephonic voice communication matching all of the criteria established in the earlier sections. That is, the system and method may initiate picking a contact from the initiating party device 120 address book or dialing a number and may receive the call on the receiving party device 160 just as acting on an incoming call prompt. The system and method further has a quality as great as a mobile carrier's telephone network, and costs either nothing or as low as a local call.

[0077] In the preceding specification, various preferred embodiments have been described with references to the accompanying drawings. Although the above description references separate processors and servers, it may be understood that the processors and servers may a single processor or server, or separate processors or servers. It will also be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded as an illustrative rather than restrictive sense,

Claims

CLAIMS:

1. A system for converting a telephonic address to an industry standard representation of the telephonic address comprising:

a dialing rules processor that receives at least the telephonic address;

a pre-dialing rules sub-processor that removes at least one character of the telephonic address to produce a pre-output telephonic address;

a core dialing rules sub-processor that applies a first set of dialing rules to the pre- output telephonic address to produce a core output telephonic address; and

a post-dialing rules sub-processor that applies a second set of dialing rules to the core out ut telephonic address to produce the industry standard representation of the telephonic address.

2. The system of claim 1 wherein at least one removed character is selected from the group comprising: more than one PLUS sign; a non-numeric character that is also not a PLUS sign or a COMMA; a character preceding a PLUS sign; a character following a COMMA; and a COMMA.

3. The system of claim 1 wherein each of the dialing rules in the first set of dialing rules includes: a target audience, a destination length, a destination prefix, and a destination substitute.

4. The system of claim 3 wherein each of the dialing rules in the first set of dialing rules further includes a remark.

5. The system of claim 1 wherein each of the dialing rules in the second set of dialing rules includes: a target audience, a destination length, a destination prefix, and a destination substitute.

6. The system of claim 5 wherein each of the dialing rules in the second set of dialing rules further comprises a remark.

7. A method for converting a telephonic address to an industry standard representation of the telephonic address comprising:

receiving at least the telephonic address at a server;

applying a first set of dialing rules to the telephonic address to produce a core output telephonic address; and

applying a second set of dialing rules to the core output telephonic address to produce the industry standard representation of the telephonic address.

8. The method of claim 7 further comprising removing at least one character of the telephonic address before applying the first set of dialing rules.

9. The method of claim 8 wherein the at least one character is selected from the group comprising: more than one PLUS sign; a non-numeric character that is also not a PLUS sign or a COMMA; a character preceding a PLUS sign; a character following a COMMA; and a COMMA.

10. The method of claim 7 wherein each of the dialing rules in the first set of dialing rules comprises: a target audience, a destination length, a destination prefix, and a destination substitute.

1 1. The method of claim 10 wherein each of the dialing rules in the first set of dialing rules further comprises a remark.

12. The method of claim 7 wherein each of the dialing rules in the second set of dialing rules comprises: a target audience, a destination length, a destination prefix, and a destination substitute.

13. The method of claim 12 wherein each of the dialing rules in the second set of dialing rules further comprises a remark.

14. A method of placing a call comprising:

converting a call from an initiating party device addressed to a receiving party device into a call to a first access number of a conference call local to the initiating party device; transmitting an incoming call prompt to the receiving party device; and

providing, to the receiving party device, a second access number of the conference call local to the receiving party device.

15. The method of claim 14 further comprising patching the receiving party device into the conference call with the initiating party device.

16. The method of claim 1 further comprising receiving a request for a call prior to converting the call.

17. The method of claim 16 wherein the request is an HTTPS POST request sent over an Internet connection.

18. The method of claim 16 wherein the request includes DTMF touch tones.

19. The method of claim 14 further comprising checking the availability of the receiving party device prior to transmitting the prompt.

20. The method of claim 14 wherein the call prompt comprises at least one of: a PUSH notification and an SMS notification.