Technological advances in computer networks not only improve textual information exchange but also open a new avenue for voice communication. Traditional telephone communication networks are no longer sole providers of quality voice data services. As networking technologies improve, an emerging Voice over Internet Protocol (VoIP) becomes a cost-effective alternative to make a phone call, compared to landline and mobile phone call. A VoIP call is typically initiated by or terminated to a VoIP device, such as a persona computer (PC), Wi-Fi phone, or session initiation protocol (SIP) Phone.
Currently, a VoIP call directed to or terminated at a regular landline or mobile phone is normally paid by a caller (i.e., a calling party). If the callee (i.e., called party) is a merchant who is willing to pay for the VoIP call, the so-called Merchant Powered Click-to-Call (MPC) allows a caller to call a merchant for free. This normally happens at search web sites. A significant usability disadvantage in this mechanism is that it requires a special mapping from a code name to a real phone number in the backend server; as a result, the user won't directly know the real phone number. Moreover, the user must always make a call from the same web site to enjoy a free call (or receive pre-authorized credit for the call).
Embodiments of the invention overcome the shortfalls of prior practices by selectively issuing from a user or a callee to a caller a pre-authorized credit for an incoming call based on VoIP. Aspects of the invention enable evaluation of a source identification (ID) for identifying the caller and determine whether the source ID should receive the pre-authorized credit from the user based on a set of rules. If a call destination intended by the VoIP call is determined not to receive the pre-authorized credit, alternative embodiments of the invention may recursively search for another destination, based on the rules, for the VoIP call to receive the pre-authorized credit. A further alternative embodiment notifies the caller whether the caller wishes to proceed with the call if it is determined that the caller will not receive the pre-authorized credit.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Other features will be in part apparent and in part pointed out hereinafter.
Corresponding reference characters indicate corresponding parts throughout the drawings.
Aspects of the invention provide automatic issuance of pre-authorized credit to calls, especially VoIP calls, to a user. In one example, the user may be a merchant, a business, an individual or the like. Aspects of the invention provide convenience to callers who would not have otherwise received free calls paid by the user under the current implementations.
Referring now to
As previously described, aspects of the invention may be useful in situations the user 110 wishes to pay for the incoming calls. It is known that the user 110 may purchase a so-called toll free numbers (e.g., area code 800, 866, or 877) for potential customers. However, these toll free numbers are only free to calls originated from landline phones. Cellular phone calls or VoIP calls continue to pay for calls to these numbers by the caller 112.
As a further example, a family member may wish to enable free calls from other members in the family. For example, a father may wish to establish a way so that everyone in the family can call him at his work or his cell phone for free from any originating device. As such, embodiments of the invention provide this convenience by evaluating source identifications (IDs) of an incoming call against a set of defined rules to determine whether a given incoming call should receive a pre-authorized credit for the call.
To further illustrating embodiments of the invention, suppose the caller 112 wishes to place an incoming call 114 to the user 110. In one example, the caller 112 initiates the call 114 from one of the source IDs 116. For example, the source ID 116 may be a cell phone 116-1, a work phone 116-2, or an online ID 116-3. For example, the online ID 116-3 may be an e-mail address.
Before the call 114 of the caller 112 reaches the user 110, the user 110 may employ the system 100 to identify one of the source IDs the user 110 wishes to be covered by the pre-authorized credit 120. In this illustration, the user 110 may identify the source IDs 116 as one of the sources of the call. Furthermore, the user 110 may also wish to specify one or more destinations to which the call is directed. For example, the user 110 may specify destinations 118, such as a work phone 118-1, a cell phone 118-2, and a home phone 118-3 to receive the pre-authorized credit 120.
Next, the user 110 may define a rule 122 or a set of rules to selectively issue the pre-authorized credit 120 to incoming calls. In one example, the user 110 may establish or define one or more parameters in the rule 122, such as whether an incoming call is allowed, what type of call (domestic or international call) is allowed, and the maximum duration of a collect call is allowed, and/or the maximum cost of a collect call is allowed.
For example, an exemplary set of rules may include at least the following:
For example, the defined rule 122 may be an authorization rule set (ARS), which is a set of authorization rules or an authorization rule (AR), which includes Name (N), Membership (M), and Call Scenario Set (CSS).
A Call Scenario Set (CSS) includes Date (D), Time (T), Caller's Endpoints (Caller), Callee's Endpoints (Callee), Call Initiation Type (CIT), Dial Type (DT), Maximum Duration (MD), and Maximum Cost (MC).
For instance, the following is an example of an authorization rule.
The output of executing an authorization rule is an authorization result triplet:
The final authorization result is created by merging all of the authorization result triplets. The merge is to allow the maximum benefit of collect call to the caller because the spirit of collect call benefits the caller.
When there are N rules, it requires N-1 merges. For instance, if there are 8 rules, the merges can happen in the following way.
<R1, R2>, <R3, R4>, <R5, R6>, <R7, R8>
<R12, R34>, <R56, R78>
<R1234, R5678>
There are totally 7 merges.
Another possible way of merging is
<R1, R2>
<R12, R3>
<R123, R4>
<R1234, R5>
<R12345, R6>
<R123456, R7>
<R1234567, R8>
This also requires 7 merges.
It can be proved that it requires N-1 merges for N rules.
In one embodiment, the processor 102 executes computer-executable instructions embodied in computer executable components, applications, or engines. When a call is coming in, in one example, a rules engine starts to execute all authorization rules for each possible destination 118 of the user 110. For each pair of this incoming call and a possible destination 118 of the user 110, the execution of an authorization rule produces an authorization result triplet. All these produced authorization result triplets will be merged into the final authorization result.
For each approved endpoint, there is a final authorization result that determines acceptance of collect call, maximum duration of collect call, and maximum cost of collect call for this destination.
The final output of the rules engine may be a set of duplets, consisting of an approved destination 118 of the user 110 and the final authorization result for this endpoint.
The call router will then try to reach the user 110 through approved destinations 118 of the user 110 simultaneously or one by one, depending on the calling plan the callee has.
Table 1 illustrates an exemplary list of destinations:
Referring now to
In one embodiment, a SIP Proxy (SP) 206 is the proxy server that routes all VoIP calls to terminal endpoints.
Account Database (AD) 208 is the database that stores the information of all user accounts.
Rules Database (RD) 210 is the database that stores all the authorization rules.
Rules Engine (RE) 212 is the inference engine that takes the call parameters from SIP Proxy A 206 and the account information from Account Database to infer on the callee's auto-authorized rules. These servers or databases are interacted via a network 220.
In one embodiment, aspects of the invention may be illustrated according to
At 310, it is determined whether the incoming call and the caller satisfy the defined rule as a function of the one of the destinations, one or more identified source IDs and the defined rule. If it is determined that the incoming call satisfies the rule, the pre-authorized credit is issued for the incoming call from the caller at 312. That is, the caller 112 will receive a credit for calling the user 110 so that the incoming call 114 is a free phone call. At 314, the incoming call from the caller is routed to the user 110, and the caller 112 establishes a connection with the user without being charged for the incoming call 114. On the other hand, if the determination at 310 is negative, aspects of the invention may recursively identify another destination ID at 316. In other words, aspects of the invention may identify another destination of the user 110 that may satisfy the defined rule.
In one alternative embodiment, the system 100 may provide a notification to the caller if it is determined that the incoming call does not satisfy the defined rule to receive the issued pre-authorized credit for the incoming call. The notification may further prompt the caller for further instructions to proceed to complete or connect the call to the user 110. In another embodiment, where the source ID is not readily identifiable, the system 100 may prompt the caller 112 to enter authentication credentials that were given to the caller 112 by the user 110 for the purpose of receive the issued pre-authorized credit.
In operation, an exemplary implementation of aspects of the invention may be further explained below using
The order of execution or performance of the operations in embodiments of the invention illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and embodiments of the invention may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the invention.
Embodiments of the invention may be implemented with computer-executable instructions. The computer-executable instructions may be organized into one or more computer-executable components or modules. Aspects of the invention may be implemented with any number and organization of such components or modules. For example, aspects of the invention are not limited to the specific computer-executable instructions or the specific components or modules illustrated in the figures and described herein. Other embodiments of the invention may include different computer-executable instructions or components having more or less functionality than illustrated and described herein.
When introducing elements of aspects of the invention or the embodiments thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
Having described aspects of the invention in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the invention as defined in the appended claims. As various changes could be made in the above constructions, products, and methods without departing from the scope of aspects of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.