U.S. patent application number 10/122981 was filed with the patent office on 2002-08-15 for signaling system and method for network-based pre-paid wireless telephone service.
Invention is credited to Hartmaier, Peter, Wilhoite, Michael T..
Application Number | 20020111153 10/122981 |
Document ID | / |
Family ID | 22629819 |
Filed Date | 2002-08-15 |
United States Patent
Application |
20020111153 |
Kind Code |
A1 |
Hartmaier, Peter ; et
al. |
August 15, 2002 |
Signaling system and method for network-based pre-paid wireless
telephone service
Abstract
A pre-paid subscriber account system for use with wireless
telephone systems is disclosed. The system, which monitors a
subscriber's call, deducts the cost of the call from the
subscriber's pre-paid account in real-time, warns the subscriber
during a call when the account is nearing depletion, and terminates
the call when the account is depleted. The system can also prevent
the initiation of a new call when the account is depleted. The
system and method uses signaling techniques that will allow the
metering or billing of the call, along with any authorization or
restrictions, to be done remotely from the actual switching of the
call. Call events or chargeable events are transmitted to the
pre-paid control system while the communications path of the call
is held at the switching system awaiting control information.
Inventors: |
Hartmaier, Peter;
(Woodinville, WA) ; Wilhoite, Michael T.;
(Redmond, WA) |
Correspondence
Address: |
FULBRIGHT & JAWORSKI L.L.P.
2200 ROSS AVENUE
SUITE 2800
DALLAS
TX
75201
US
|
Family ID: |
22629819 |
Appl. No.: |
10/122981 |
Filed: |
April 15, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10122981 |
Apr 15, 2002 |
|
|
|
09172934 |
Oct 14, 1998 |
|
|
|
6393269 |
|
|
|
|
Current U.S.
Class: |
455/406 ;
455/405; 455/407 |
Current CPC
Class: |
H04M 2215/8166 20130101;
H04Q 2213/13103 20130101; H04Q 2213/13092 20130101; H04W 12/082
20210101; H04M 17/00 20130101; H04M 15/90 20130101; H04Q 2213/13098
20130101; H04Q 2213/13345 20130101; H04Q 2213/1313 20130101; H04M
2215/016 20130101; H04W 4/24 20130101; H04M 2215/32 20130101; H04Q
2213/1305 20130101; H04M 15/854 20130101; H04Q 2213/13213 20130101;
H04Q 2213/13176 20130101; H04Q 2213/13377 20130101 |
Class at
Publication: |
455/406 ;
455/405; 455/407 |
International
Class: |
H04M 011/00 |
Claims
What is claimed is:
1. A method for providing prepaid wireless communications services
using a prepaid account monitoring application at a Service Control
Point (SCP) comprising: receiving an origination request message
from a Mobile Switching Center (MSC), the origination request
message indicating that the MSC received a call origination
indication from a wireless device; sending a origination request
response message to the MSC, wherein the origination request
response message indicates that the MSC can establish a call using
the digits provided by the wireless device; monitoring a prepaid
account balance associated with the wireless device; detecting when
the prepaid account balance reaches a predetermined threshold
amount; sending a balance warning message to indicate that a
warning message should be played for the wireless device; and
receiving a notification that the warning message was played for
the wireless device.
2. The method of claim 1 further comprising: determining when a
call in progress should be disconnected; sending a message
directing the MSC to disconnect the call; and receiving a response
from the MSC indicating that the call has been disconnected.
3. The method of claim 1 further comprising: sending a message to
the MSC regarding a particular call connection; and receiving a
response message from the MSC indicating said call connection is
still in progress.
4. The method of claim 1 further comprising: sending a message to
the MSC regarding a particular call connection; and receiving a
response message from the MSC indicating said call connection is
disconnected.
5. A method for providing prepaid wireless communications services
using a prepaid account monitoring application that is provided by
a device remote from a Mobile Switching Center (MSC), comprising:
sending an origination request message from the MSC, the
origination request message indicating that the MSC received a call
origination indication from a wireless device; receiving a
origination request response message at the MSC, wherein the
origination request response message indicates that the MSC can
establish a call using the digits provided by the wireless device;
connecting the wireless device to a called number; receiving a
balance warning message to indicate that a warning message should
be played for the wireless device; playing a warning message to the
wireless device; and sending a notification that the warning
message was played for the wireless device.
6. The method of claim 5 further comprising: receiving a message
directing the MSC to disconnect a call connection for the wireless
device; disconnecting the call connection; and sending a response
from the MSC indicating that the call has been disconnected.
7. The method of claim 5 further comprising: receiving a message at
the MSC regarding a particular call connection; and sending a
response message from the MSC indicating that said call connection
is still in progress.
8. The method of claim 5 further comprising: receiving a message at
the MSC regarding a particular call connection; and sending a
response message from the MSC indicating said call connection is
disconnected.
9. A Service Control Point (SCP) for providing prepaid wireless
communications services using a prepaid account monitoring
application at the SCP, comprising: means for receiving an
origination request message from a Mobile Switching Center (MSC),
the origination request message indicating that the MSC received a
call origination indication from a wireless device; means for
sending a origination request response message to the MSC, wherein
the origination request response message indicates that the MSC can
establish a call using the digits provided by the wireless device;
means for monitoring a prepaid account balance associated with the
wireless device; means for detecting when the prepaid account
balance reaches a predetermined threshold amount; means for sending
a balance warning message to indicate that a warning message should
be played for the wireless device; and means for receiving a
notification that the warning message was played for the wireless
device.
10. The SCP of claim 9 further comprising: means for determining
when a call in progress should be disconnected; means for sending a
message directing the MSC to disconnect the call; and means for
receiving a response from the MSC indicating that the call has been
disconnected.
11. The SCP of claim 9 further comprising: means for sending a
message to the MSC regarding a particular call connection; and
means for receiving a response message from the MSC indicating said
call connection is still in progress.
12. The SCP of claim 9 further comprising: means for sending a
message to the MSC regarding a particular call connection; and
means for receiving a response message from the MSC indicating said
call connection is disconnected.
13. A Mobile Switching Center (MSC) for providing prepaid wireless
communications services using a prepaid account monitoring
application that is provided by a device remote from the MSC,
comprising: means for sending an origination request message from
the MSC, the origination request message indicating that the MSC
received a call origination indication from a wireless device;
means for receiving a origination request response message at the
MSC, wherein the origination request response message indicates
that the MSC can establish a call using the digits provided by the
wireless device; means for connecting the wireless device to a
called number; means for receiving a balance warning message to
indicate that a warning message should be played for the wireless
device; means for playing a warning message to the wireless device;
and means for sending a notification that the warning message was
played for the wireless device.
14. The MSC of claim 13 further comprising: means for receiving a
message directing the MSC to disconnect a call connection for the
wireless device; means for disconnecting the call connection; and
means for sending a response from the MSC indicating that the call
has been disconnected.
15. The MSC of claim 13 further comprising: means for receiving a
message at the MSC regarding a particular call connection; and
means for sending a response message from the MSC indicating that
said call connection is still in progress.
16. The MSC of claim 13 further comprising: means for receiving a
message at the MSC regarding a particular call connection; and
means for sending a response message from the MSC indicating said
call connection is disconnected.
17. A computer program product having a memory with computer code
stored thereon, the computer code for providing prepaid wireless
communications services, the computer program product comprising:
code for receiving an origination request message from a Mobile
Switching Center (MSC), the origination request message indicating
that the MSC received a call origination indication from a wireless
device; code for sending a origination request response message to
the MSC, wherein the origination request response message indicates
that the MSC can establish a call using the digits provided by the
wireless device; code for monitoring a prepaid account balance
associated with the wireless device; code for detecting when the
prepaid account balance reaches a predetermined threshold amount;
code for sending a balance warning message to indicate that a
warning message should be played for the wireless device; and code
for receiving a notification that the warning message was played
for the wireless device.
18. The computer program product of claim 17 further comprising:
code for determining when a call in progress should be
disconnected; code for sending a message directing the MSC to
disconnect the call; and code for receiving a response from the MSC
indicating that the call has been disconnected.
19. The computer program product of claim 17 further comprising:
code for sending a message to the MSC regarding a particular call
connection; and code for receiving a response message from the MSC
indicating said call connection is still in progress.
20. The computer program product of claim 17 further comprising:
code for sending a message to the MSC regarding a particular call
connection; and code for receiving a response message from the MSC
indicating said call connection is disconnected.
Description
RELATED APPLICATIONS
[0001] This application is a continuation of application Ser. No.
09/173,934, entitled SIGNALING SYSTEM AND METHOD FOR NETWORK-BASED
PRE-PAID WIRELESS TELEPHONE SERVICE, filed Oct. 14, 1998.
TECHNICAL FIELD OF THE INVENTION
[0002] The invention relates to telephone systems and, more
particularly, to a system and method for monitoring call
connections for prepaid wireless telephone subscribers using a
prepaid application that is remote from a Mobile Switching
Center.
BACKGROUND OF THE INVENTION
[0003] Long distance service companies and wireless telephone
companies typically bill their subscribers based on actual calls
placed and the duration of those calls. Since unpredictable calling
patterns make the total charge for these services unpredictable,
they are typically billed to the subscribers at regular intervals
after such calls have been made. However, some subscribers are
denied this privilege due to their inadequate credit rating.
Alternately, some subscribers prefer to control telephone usage by
members of their families or others, by limiting calls to a
predetermined total cost. It is desirable to be able to provide
wireless telephone services for these situations, while reducing
exposure to bad debt for the wireless telephone service providers,
and reducing exposure to excessive charges for the subscribers. One
solution to this problem is to provide pre-paid accounts for
wireless telephone service. As telephone charges accrue, they are
simply deducted from these accounts. If the subscriber does not
maintain an adequate balance, then the wireless telephone services
can be wholly or partially disabled or cut off, thereby reducing
the financial risk inherent in unrestricted telephone usage.
[0004] Two basic strategies are used to provide such pre-paid
accounts. The first approach monitors billing records and compares
the records with an account balance to determine when the account
balance has been depleted, referred to as "Hotbilling".
[0005] However, these comparisons are usually made after each phone
calls has been completed. The delay between accrual of the
telephone service charges and the reduction of the account balance
allows subscribers to significantly overrun their account balance
during a call. As a result, prepaid subscribers in this type of
system may create negative account balances before the service
provider detects the overrun and phone service is terminated or
blocked. The financial risk for this type of billing system
increases as the interval between charge accrual and account
reconciliation increases.
[0006] An alternative approach provides for trunk-looping the voice
channel for prepaid calls through a device that monitors individual
calls and calculates costs in real-time. However, this type of
system requires the voice channel to be rerouted through the
monitoring device, which may be located a great distance away. This
rerouting may require a great deal of additional network capacity,
and is therefore very expensive for the telephone companies to
implement.
[0007] An additional limitation of prior art trunk-looping systems
is the inability to use such systems when roaming. In the prior
art, prepaid calls are routed through a monitoring device that is
connected to the calling device's home switch. When the calling
device is roaming, the roaming area switch is not connected to the
prepaid monitoring device, and, therefore, is unable to provide
prepaid service to the caller.
[0008] The prior art systems and methods for providing prepaid
wireless telephone service have obvious disadvantages. Service
providers resist implementing either one due to perceived high
costs and/or financial risk due to delayed processing.
SUMMARY OF THE INVENTION
[0009] The instant invention solves the aforementioned problems by
monitoring the presence of a subscriber's wireless telephone call,
determining the accrued cost of the call, and appropriately
reducing the account balance, all as the call is taking place. It
does so without rerouting voice traffic and can be implemented in
an existing mobile switching center (MSC). The invention takes
advantage of the MSC's capability to process call handling
instructions from an Signaling Control Point (SCP) and to connect
an Interactive Voice Response (IVR) unit to a call in progress.
Based on a predetermined minimum account threshold, the system has
the capability of making a warning announcement to the subscriber
whenever the threshold is being approached, disconnecting the call
when the threshold is reached, and preventing further calls until
the account balance has been replenished. Other options are also
available, such as restricting telephone calls to/from certain
telephone numbers, certain calling zones, or certain geographical
boundaries.
[0010] Replenishment of the account can be accomplished by the
subscriber through the use of standard cash, check, or money order
payments, through pre-authorized credit card payments, or through
the purchase of debit cards from authorized distributors.
[0011] A preferred embodiment of the invention is implemented in
software in a computer system which can be integrated into existing
telephone communications systems for wireless telephones, including
cellular and PCS telephones. The present invention is directed to a
system and method for communicating the status of a call between
the switching system and pre-paid control system. Protocols between
the switch and the pre-paid system define specific command and
response codes, which are communicated between the various
components to permit specific activities to occur across a
distributed network. Each of the command and response codes can
include various parameters. The instant invention uses additional
commands, responses, and parameters within an existing protocol to
signal between the switching system and the pre-paid control system
to effect network based prepaid service.
[0012] One technical advantage of the invention is a system that
can monitor the status of calls and adjust the associated account
balance in real time so that service can be modified or terminated
immediately whenever the funds in the pre-paid account are
depleted.
[0013] Another advantage is that this monitoring is provided
without causing the voice channel to be rerouted from its normal
path.
[0014] The foregoing has outlined rather broadly the features and
technical advantages of the present invention in order that the
detailed description of the invention that follows may be better
understood. Additional features and advantages of the invention
will be described hereinafter which form the subject of the claims
of the invention. It should be appreciated by those skilled in the
art that the conception and specific embodiment disclosed may be
readily utilized as a basis for modifying or designing other
structures for carrying out the same purposes of the present
invention. It should also be realized by those skilled in the art
that such equivalent constructions do not depart from the spirit
and scope of the invention as set forth in the appended claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] For a more complete understanding of the present invention,
and the advantages thereof, reference is now made to the following
descriptions taken in conjunction with the accompanying drawings,
in which:
[0016] FIG. 1 is a block diagram of a wireless prepaid system
employing the present invention;
[0017] FIG. 2 is a flowchart illustrating subscriber registration
in an illustrative example of the present invention;
[0018] FIG. 3 is a flowchart illustrating call origination in an
illustrative example of the present invention;
[0019] FIG. 4 is a flowchart illustrating how warning announcements
are played in an illustrative example of the present invention;
[0020] FIG. 5 is a flowchart illustrating how the illustrative
example of the present invention operates when the subscriber
exhaust the prepaid account balance;
[0021] FIG. 6 is a flowchart illustrating call delivery in an
illustrative example of the present invention;
[0022] FIG. 7 is a flowchart illustrating error handling in an
illustrative example of the present invention;
[0023] FIG. 8 is a flowchart illustrating fraud prevention in an
illustrative example of the present invention; and
[0024] FIG. 9 is a block diagram of a prior art prepaid wireless
system.
DESCRIPTION OF THE INVENTION
[0025] Before describing the operation of the present invention, it
would be instructive to describe the operation of a prior art
wireless prepaid monitoring device as shown in FIG. 9. MSC 901 is
in communication with wireless device 902, which may be assigned to
a prepaid wireless service account. When device 902 initiates
outgoing calls to a called number, such as a number in the Public
Switched Telephone Network (PSTN) 903, MSC 901 determines that
device 902 is assigned to a prepaid account and, therefore, the
cost for the call must be compared to the current prepaid account
balance. Prepaid monitoring device 904 is used to monitor the cost
of the call.
[0026] In order to monitor the cost of the call, MSC 901
trunk-loops the call by routing the voice channel for wireless
device 902 through monitoring device 904. As a result, the voice
channel between device 902 and the called party is increased by
links 905 and 906. This trunk-looping may cause delay and noise in
the signal path. Additionally, it creates extra equipment and
maintenance expense for the service provider.
[0027] FIG. 1 is an illustrative example of a communications system
embodying the present invention. SCPs 101 and 102 are configured as
a redundant pair of processors that perform the prepaid
application. SCPs 101, 102 are connected to communications network
103, which may be a Signaling System Seven (SS7) network. MSC 104
is also connected to network 103, which allows MSC 104 to exchange
data with SCPs 101 and 102. IVR 105 is also connected to network
103 in such a way as to allow messages and data to be exchanged
with SCPs 101 and 102 and MSC 104.
[0028] Subscriber unit 106 is in radio communication with MSC 104.
Home Location Register (HLR) 107 is a database comprising
information associated with the subscriber units that are assigned
to MSC 104 as their home switch. When subscriber unit 106 attempts
to check-in with MSC 104, the switch will get current configuration
data for unit 106 from HLR 107 is unit 106 is homed on MSC 104. If
unit 106 is roaming and it is homed on another MSC (not shown),
then MSC 104 will obtain unit 106's configuration data from the
home HLR (not shown) for subscriber unit 106. Configuration data
for roaming subscriber units is stored in Visitor Location Register
(VLR) 108.
[0029] Once MSC 104 has the configuration data for subscriber unit
106, then MSC 104 can connect unit 106 to called parties through
PSTN 109. Alternatively, MSC 104 can route incoming calls from PSTN
109 to subscriber unit 106.
[0030] In one embodiment of the present invention, SCPs 101 and 102
include software with appropriate capabilities to provide prepaid
calling services. The prepaid calling functionality in SCPs 101 and
102 is referred to herein as a call monitoring module. This
functionality can be installed in existing wireless telephone
service equipment or can include stand-alone computers especially
prepared for this purpose. The call monitoring module can operate
in conjunction with existing telephone switching systems, including
multiple MSC's, HLR's, and IVR's existing at various geographical
locations, to provide the relevant functionality across a wide area
in a cost-efficient manner. MSC 104 communicates with wireless
devices, such as unit 106, that are within MSC 104's geographical
range at the time a call is made. HLRs, such as 107, contains a
database for each subscriber, with each subscriber being
pre-assigned to a particular HLR.
[0031] IVR 105 is capable of playing pre-programmed voice messages
and can be connected to subscriber unit 106 by MSC 104 to play a
specified voice message. The MSC, HLR, and IVR involved in a
particular call typically communicate with each other over a
digital network, such as network 103, where each device has a
network address. Communications between these various systems can
take place through a communications protocol defined in American
National Standards Institute section 41 (IS-41).
[0032] IS-41 defines a series of commands, responses, and related
data that are exchanged between telecommunications devices, in
which both the commands and the responses can include the related
data. The form of this information can be roughly divided into
commands (interdevice requests to perform a function), responses
(replies to the command, signaling that the requested function is
complete), and parameters (data that can be conveyed within a
command or a response, and which denotes specific operations or
triggers). Operations are functions that can be performed, while
triggers represent status flags that initiate operations. MSC's,
HLR's, IVR's and standard IS-41 are well known to those of ordinary
skill in the telecommunications industry, and their overall
characteristics are not further described here. However, the
following detailed descriptions will define how the illustrative
example of the present invention interacts with these existing
systems in novel and non-obvious ways to provide the desired
results, by using specific IS-41 commands, responses, parameters,
operations and triggers to communicate with the MSC and IVR.
[0033] In the preferred embodiments described, speech paths are not
connected to SCPs 101 or 102, thus eliminating the inefficiencies
of looping trunks required with other pre-paid applications.
Existing MSC's, HLR's, and IVR's perform their normal functions,
thus allowing the invention to be integrated into existing systems
without a large investment in new resources or the expensive
obsolescence of old resources.
[0034] When a call is initiated between wireless device 106 and a
called party, such as a number in PSTN 109, MSC 104 creates a
direct connection between device 106 and PSTN 109, without
trunk-looping the voice signal. As part of the call setup, MSC 104
determines that device 106 is associated with a prepaid account.
Accordingly, MSC 104 notifies the appropriate SCP, 101 or 102, to
begin monitoring the cost of the call. SCP 101 or 102 then begins
monitoring the call using a call monitoring module (CMM) 110. MSC
104 provides CMM 110 in SCP 101 or 102 with certain parameters for
the call and CMM 110 calculates the running cost of the call. This
running cost is deducted from the prepaid account balance. When the
call is completed, MSC 104 instructs the appropriate SCP to stop
monitoring the call.
[0035] If the costs for the call approach or exceed a threshold,
then CMM 110 causes MSC 104 to conference IVR 105 into the call
path, so that IVR 105 can play an appropriate warning message. CMM
110 can also instruct MSC 104 to terminate the call when the
prepaid account balance drops below a preselected amount.
[0036] It will be understood in the example illustrated herein that
although many of the triggers, detection points, operations and
messages described herein are currently part of the IS-41 standard,
other triggers, detection points, operations or messages may be
added to the IS-41 standard at a later time. Additionally, various
ones of the triggers and detection points described herein may be
optional features that may be used in a system complying with the
IS-41 standard.
[0037] To interact correctly with the illustrative call monitoring
module in the example system described herein, MSC 104 requires
four basic capabilities:
[0038] 1. The MSC should support the following events: origination
triggers, "O_Answer" and "O_Disconnect," and termination triggers,
"T_Answer" and "T_Disconnect."
[0039] 2. Support of a trigger address list parameter to send
Origination Request (ORREQ) messages to the call monitoring
module.
[0040] 3. Allow call bridge and call shut-down capability during a
two-way call using Connect Resource and SRFDirective messages
(specialized IS-41 messages).
[0041] 4. Provide the geographic location of a subscriber.
[0042] The following descriptions pertain to preferred embodiments
using specific parameters that are currently available in known
telephone network systems. These parameters and their identifying
names are known to those of ordinary skill in the art and are
therefore not provided herein with detailed descriptions.
[0043] Subscriber Registration
[0044] Registration occurs when a subscriber turns on his or her
wireless telephone and establishes a communications link to the
nearest MSC. The MSC identifies the specific wireless telephone
from its unique address and sets up the appropriate operational
data for it that can be used for the duration of the connection. As
can be seen in FIG. 2, subscriber registration 201 begins when the
wireless telephone is turned on at step 203 and sends its unique
identification address to the nearest MSC at step 203. Based on the
unique address, the MSC determines which HLR is associated with
that particular telephone at step 204 and sends the registration
notification command RegNot to that HLR at step 205. The RegNot
command specifies the optional triggers that this particular MSC
supports. The parameter transcap is included in the command and is
set to indicate that the MSC can process a trigger address list.
The parameter wincap is also included to indicate which trigger
types the MSC supports (like `Busy` and `No Answer`), and which
operations it supports (like `Reset Timer`, `Connect Resource`, and
`Conference Operations`).
[0045] The HLR retrieves the subscriber profile database for the
identified wireless telephone at step 206, containing information
on the capabilities and permitted activities of the subscriber.
Given the capabilities of the serving MSC and the features set in
the subscriber's profile, the HLR responds to the RegNot command at
step 207 with the parameter trigaddrlist, which defines specific
trigger types available for this subscriber and the network address
of the device associated with each trigger. This information
includes data on the call monitoring module of the present
invention. In step 208, the MSC stores this information in it's
Visitor Location Register (VLR), which is a temporary subscriber
database created just for the duration of this call. Registration
is complete at step 209, and no other related activities occur
until a call to or from the subscriber is attempted.
[0046] The call monitoring module does not participate in the
subscriber registration sequence. However, this step establishes
the existence of the call monitoring module to the MSC, and
provides the associated parameters that will permit the MSC to
communicate with it.
[0047] Call Origination
[0048] Typically, monitoring a call originated by a pre-paid
subscriber assumes the following conditions:
[0049] 1. The `Answer`, `Disconnect` and `All Calls` triggers were
enabled in the VLR during registration,
[0050] 2. The serving MSC received the network address of the call
monitoring module during registration, and
[0051] 3. The serving MSC supports the Connect Resource
operation.
[0052] FIG. 3 shows that the CALL ORIGINATION sequence 301 involves
a series of communications between the MSC, the HLR, the call
monitoring module (CMM), and the IVR. In one embodiment, the CMM
may be embodied as software residing on a SCP, such as SCPs 101 or
102 in FIG. 1. Alternatively, the CMM may be a function that is
performed in the MSC. The process begins when the serving MSC 104
receives a normal call origination signal, with the dialed digits,
from subscriber 106. MSC 104 determines that the subscriber has an
origination trigger enabled and sends an origination request
command (ORREQ) to the call monitoring module (CMM) at step 302.
The trigtype parameter indicates why the message was sent by
identifying the type of trigger that initiated the message. The
wincap parameter indicates that the serving MSC supports the
Connect Resource operation. The dgtsdial parameter indicates the
telephone number dialed by the subscriber.
[0053] If the call monitoring module determines that an
announcement must be played to the subscriber before placing the
call, the call monitoring module initiates the PLAY ANNOUNCEMENT
communications sequence at step 303. The sequence for making an
announcement is described in FIG. 4.
[0054] As shown in FIG. 4, the PLAY ANNOUNCEMENT sequence begins
401 when the call monitoring module sends a Seize Resource command
(SEIZERES) to the associated IVR at step 402. This command includes
the parameter plind (preferred language indicator) to specify the
language (English, Spanish, French, etc.) of any announcement to be
made to the subscriber. When the IVR receives this command, it's
response to the call monitoring module at step 403 includes the
parameter tldn (temporary local directory number), which specifies
a dial-up telephone number by which the IVR can be connected for
voice communications. The call monitoring module then sends a
Connect Resource command to the MSC with the tldn parameter at step
404. The MSC uses this information to call the IVR and establish a
voice connection with it at step 405. Once this call is placed, the
IVR sends an instruction request (INSTREQ) at step 406 to the call
monitoring module requesting call processing instructions. The call
monitoring module sends an RUIDIR command to the IVR at step 407,
with the announcement parameter annlist indicating which
announcement to play.
[0055] The IVR plays the indicated announcement at step 408 over
the dialed-up connection to the MSC, which passes the announcement
through to the subscriber's telephone. Once the announcement is
complete, the IVR and call monitoring module bring the INSTREQ and
RUIDIR command sequences to a close by sending the proper responses
to each other at steps 409 and 410. The interaction with the IVR
before and after the call is prior art known to those in the
wireless industry. The interaction with an IVR while a call is in
progress is novel with this invention.
[0056] Returning to FIG. 3, once the announcement of step 303 is
complete, the call monitoring module then responds to the ORREQ
command from the serving MSC at step 304, providing an action code
parameter actcode, which tells the MSC to drop the dialup
connection to the IVR at step 305, and establish a new call using
the routing digits previously provided by the subscriber. The MSC
places the subscriber's requested call at step 306, using known
procedures which are not described here. When the MSC detects an
answer, it determines that the subscriber has the answer trigger
enabled and sends an ORREQ command to the call monitoring module at
step 307. The trigtype parameter is set to indicate "Answer". At
step 308, the call monitoring module then starts a call timer,
begins monitoring the subscriber's account, and responds to the
ORREQ command from the MSC. At this point, the call is connected
and no further communication with the call monitoring module is
necessary until the call ends or the call monitoring module
initiates a new action.
[0057] When the call is complete, the serving MSC detects a
disconnect at step 309, determines that the subscriber has the
disconnect trigger enabled and sends another ORREQ to the call
monitoring module at step 310. The trigtype parameter is now set to
indicate "Disconnect". At step 311, the call monitoring module
stops the call timer, stops monitoring the subscriber account, and
responds to the ORREQ command at step 312, using an actcode
parameter that tells the MSC to disconnect all parties.
[0058] During the call setup, if the serving MSC detects "busy" or
"no answer" (not shown), it can send an ORREQ command to the call
monitoring module with a trigtype parameter indicating that
condition. The call monitoring module may respond with an action
code parameter and a termination list parameter to redirect the
call, possibly to the IVR to play an appropriate announcement to
the subscriber.
[0059] Subscriber Exhausts Account During Call
[0060] FIG. 5 shows the communications sequence followed when a
subscriber depletes his or her account balance during a call. This
sequence assumes that the serving MSC supports the conference
capability, that the subscriber has originated a call, and that the
call is currently active when the call monitoring module account is
completely depleted, or exhausted step 501.
[0061] The call monitoring module can provide advance warning to
the subscriber that the account balance is nearing exhaustion by
playing a message that a predetermined number of minutes (for
example, three minutes) are available before the call will be
disconnected. This determination is typically based on the charging
rate and various other relevant data. During a call, the call
monitoring module monitors the account balance at step 502 by
periodically subtracting the correct amount and examining the
resulting balance. When the warning threshold is detected by the
call monitoring module at step 503, the call monitoring module
initiates a warning announcement to the subscriber at step 504.
This follows the procedure previously described for FIG. 4, except
that the annlist parameter of step 407 specifies a `warning`
announcement. When the announcement sequence is complete, the call
monitoring module then sends a DISCONNECT RESOURCE command to the
MSC at step 505, with an actcode parameter telling the MSC to
disconnect the conference call connection to the IVR at step 506,
while leaving the connection between the parties intact. This
completes the warning message to the subscriber, and processing
returns to normal account balance monitoring at step 507.
[0062] Once the call monitoring module determines that the account
balance has been exhausted at step 508, it initiates a termination
message at step 509 to tell the subscriber the call is being
terminated. This follows the sequence previously described for FIG.
4, except that the annlist parameter of step 407 specifies the
`termination` message be played to the subscriber. Once the
announcement has been made, the call monitoring module sends the
MSC an SRF DIRECTIVE command at step 510, with an actcode parameter
telling the MSC to disconnect all parties. The MSC does this at
step 511 and responds to the SRF DIRECTIVE command at step 512 to
end the sequence. Once the subscriber is disconnected, any relevant
timers in the call monitoring module are stopped and account
balance monitoring is terminated. The subscriber must now replenish
the account balance before he or she will be allowed to place or
receive any more restricted calls associated with this account.
[0063] Call Delivery
[0064] Wireless telephone users are also billed for incoming calls.
FIG. 6 shows the sequence followed to process incoming calls. This
process assumes that:
[0065] 1. The serving MSC supports the conference capability,
[0066] 2. The `answer`, `disconnect` and `favail` triggers were set
in the VLR during registration,
[0067] 3. The serving MSC received the network address of the call
monitoring module during registration,
[0068] 4. The serving MSC supports the Connect and Disconnect
Resource operations,
[0069] 5. The serving MSC supports the Facility Selected and
Available (FAVAIL) trigger.
[0070] The first step in this process is for the home MSC, which
serves the originator's wireless telephone, to establish a
connection to the serving MSC, which serves the subscriber's
wireless telephone. This step follows procedures which are known to
those of ordinary skill in the art, and a detailed description is
therefore not included here. These procedures establish that the
subscriber's telephone is turned on and has registered with the
serving MSC. Once this has been established, CALL DELIVERY process
601 starts when the serving MSC sends a Facility Selected and
Available (FAVAIL) command to the call monitoring module at step
602, with a trigtype parameter indicating an incoming call, and a
plind parameter indicating the preferred language of any potential
voice messages.
[0071] If the call monitoring module determines the subscriber has
a sufficient account balance to accept the call, it responds to the
FAVAIL command at step 603 by returning an actcode parameter that
indicates `continue processing`. The serving MSC then sets up the
call at step 604. If the serving MSC detects an answer by the
subscriber's telephone at step 605, it sends an ORREQ command to
the call monitoring module at step 606, with a trigtype parameter
indicating `Answer`. At step 607, the call monitoring module then
starts the timer, begins monitoring the subscriber account balance,
and responds to the ORREQ command. At this point, processing
continues in a normal manner for a connected call, with no further
communications between the MSC and call monitoring module until the
call is ended by the parties. When the parties hang up, the MSC
detects this at step 608, and send an ORREQ command to the call
monitoring module at step 609 with a trigtype parameter indicating
`disconnect`. The call monitoring module then stops the call timer
and the account balance monitoring at step 610, and responds to the
ORREQ command at step 611 to end the processing for this
sequence.
[0072] After receiving the FAVAIL command described above, if the
call monitoring module determines that the subscriber does not have
a sufficient account balance to accept the incoming call, the call
monitoring module can respond to the FAVAIL command at step 603
with an actcode parameter that indicates `block the call`, which
the serving MSC can do using standard procedures to indicate to the
caller that the dialed party is unavailable. The call monitoring
module will normally terminate processing at this point, without
any further communication to the serving MSC or IVR.
[0073] Error Handling and Fraud Prevention
[0074] The call monitoring module can also provide options for
unusual situations, such as periodically checking to make sure that
both parties are still connected. If the other party has hung up
but the subscriber has inadvertently left his wireless telephone
connected, he might unknowingly be charged for a continuing
telephone call that could deplete the entire account.
[0075] As shown in FIG. 7, ERROR HANDLING 701 establishes a call as
usual at steps 702 and 703, but at periodic intervals detected at
step 704, the call monitoring module can send a service request
command (SERVICEREQ) to the MSC at step 705. The command can
contain the information request parameter leginfo, requesting the
current state of the call. If the call is still connected at both
ends, the serving MSC can so indicate by responding at step 706
with an actcode parameter indicating `continue processing`. If the
other party has disconnected, the serving MSC can so indicate by
returning an actcode parameter indicating `disconnect call`. In
either case, the MSC will then follow the prescribed action at step
707.
[0076] FIG. 8 shows how the system can be used to detect and
prevent some types of fraud, as described for FRAUD PREVENTION 801.
The call monitoring module can provide an optional service that
automatically detects attempts to use the subscriber's account if a
call is already in progress. When the MSC sends an ORREQ command at
step 802 to initiate a call using the subscriber's account, the
call monitoring module may detect the account is already in use at
step 803. If this is detected, the call monitoring module can
respond to the ORREQ command at step 804 with an actcode parameter
that tells the MSC to block the new call (and possibly to terminate
the current call) at step 805. At step 806, the MSC can then flag
the account to call customer service or security personnel. In a
similar manner, the call monitoring module can be programmed to
compare current usage patterns to previous usage patterns. If a
significant variation in previous calling patterns is detected, the
account can be disabled, and the account flagged to customer
service to notify the subscriber.
[0077] Telephone service providers may define administration level
security that allows authorized personnel to view or modify
subscriber attributes. For example, one log-in password might
provide view-only capability, while a second log-in password could
provide the ability to modify the account balance.
[0078] Call Rating
[0079] The call monitoring module can contain easily maintained
rating engines which determine the access fee (either by month,
week or day), the per minute charges for air time usage, toll
charges, and the definition of the "local calling area." The local
calling area may be defined by area code, area code+local exchange,
or mileage from the home area. All rating can be real-time based on
MSC triggers and pre-defined rating tables.
[0080] The call monitoring module's ability to handle different
rate tables is limited only by the serving MSC's ability to
identify the current location of the subscriber and the dialed
digits. Each subscriber has a class of service that indexes the
rate tables, and these tables can be used in many ways to customize
the charging profile for each subscriber. The same rating tables
can be used when originating or terminating a call. The call
monitoring module can be instructed not to charge for incoming
calls that last less than a predetermined time or for calls from
specified numbers. Tolls for call origination to numbers like
voicemail or customer service can be configured as toll-free.
[0081] The call monitoring module can also establish separate
weekend and holiday rates and provide free minutes and free
numbers. Both the number of free minutes and the time frame in
which they are offered are variables within the rate plan
schedules. Different rates may be applied to the same call, for
example, first minute free, or reduced rate after 15 minutes of
connect time.
[0082] Long distance rates can be based on day, evening, night,
mileage, interstate, intrastate, local access transport area
(LATA), and/or international tables. Long distance charges can be
automatically deducted from subscriber accounts. Federal, state,
local, city, county and special taxes may be applied to connection
fees, calls, and service, and may be automatically deducted from
the account.
[0083] Monthly Access and Reactivation Fees
[0084] A class of service attribute in the subscriber profile can
define access fees. The call monitoring module can automatically
deduct periodic charges from the account at programmable intervals
(i.e., daily, weekly, monthly).
[0085] One-time `event`charges, such as reactivation fees, may be
automatically invoked by customer service by changing a flag in the
subscriber profile. If the selected event flag is set, the call
monitoring module can immediately deduct a predefined fee from the
account.
[0086] Calling Restrictions
[0087] The call monitoring module can provide the capability to
limit the outbound dialing capabilities of accounts at the
subscriber level. Outbound calling restrictions can be set for
international, interstate, and/or intrastate long distance, or a
combination of these in specified area code and area code+local
exchange combinations. If a subscriber has only a few numbers they
want to be able to call, the numbers can be placed in a closed user
group, and only calls to those numbers will be allowed.
Alternatively, the call monitoring module can provide the
capability to debit accounts only when subscribers call outside of
the closed user group.
[0088] If a subscriber has only a few numbers they want to receive
calls from, the numbers can be placed in an in-bound closed user
group, and only calls from those numbers will be connected.
[0089] The aforementioned descriptions are intended to be
illustrative and not restrictive. Obvious variations will occur to
those of skill in the art and are intended to be encompassed by the
disclosed invention, which is limited only by the scope and spirit
of the appended claims.
[0090] Although the present invention and its advantages have been
described in detail, it should be understood that various changes,
substitutions and alterations can be made herein without departing
from the spirit and scope of the invention as defined by the
appended claims.
* * * * *