FIELD OF INVENTION
[0001] The present subject matter relates to systems and methods for management of
subscription account and, particularly but not exclusively, for management of subscription
account through communication devices in real-time.
BACKGROUND
[0002] With the advent of communication technology, communication devices, such as
mobile phones, smart phones, personal digital assistants (PDAs), and laptops have gained
popularity among users through which they can perform a variety of tasks. The tasks that are
commonly performed using such communication devices include making and receiving calls,
sending and receiving short message services (SMSs) and emails, accessing web-servers, etc.
Typically, users of the communication devices have to subscribe to a telecom operator or a
service provider that provides communication services to the users. The operator or the service
provider provides a unique subscription account to each of the users, which the users maintain
for utilizing the services provided to them.
[0003] In an example, a user may opt for a pre-paid type subscription account with the
service provider. The pre-paid type subscription account is a pay-and-use type of subscription
account, in which the user has to maintain an account balance with an amount of money which is
at least sufficient for utilizing one or more services provided by the service provider. Further, the
pre-paid type subscription account may have a validity term. The validity term is indicative of a
period for which the account balance, in the subscription account, is valid for usage. It may be
understood that in case the account balance is zero or insufficient, or the validity term of the
subscription account has expired, the user may not be able to avail any service, for example,
make a call, send an SMS or an email, and access the web. Thus, for the users with the pre-paid
type subscription accounts, it is important for them to have knowledge of the account balance,
validity term and such, of their subscription accounts, so that exhaustion of the account balance
and expiration of validity term may be avoided. Upon expiry of validity term or the exhaustion
of account balance, the users have to recharge their subscription account to have a sufficient
account balance or have a valid validity term.
3
[0004] In another example, a user may opt for a post-paid type subscription account with
the service provider. The post-paid type subscription account is a use-and-pay type of
subscription account, in which the user utilizes the services provided by the service provider and
is charged for the usage of services at periodic time intervals, for example, weekly, fortnightly or
monthly. With the post-paid subscription account, the user may have an upper limit or a cap in
regard with usage of a service for predefined time period. For example, a user with a post-paid
type subscription account may have a prescribed upper limit on the number of voice calls that
can be made in a month, an upper limit on the number of SMSs that can be sent in a fortnight, an
upper limit on the amount of data that can be downloaded in a month, and such. It may be
understood that in case the upper limit for a service is reached within the predefined time period,
for example, a month, a fortnight, as the case may be, the user may not be able to avail the
service for the duration left in the predefined time period. Thus, for the users with the post-paid
type subscription accounts, it important to monitor the usage balance for the services, from the
prescribed upper limits, so that the users are aware of whether the prescribed upper limits of
usage are reached or not.
SUMMARY
[0005] This summary is provided to introduce concepts related to management of
subscription account through communication devices. This summary is not intended to identify
essential features of the claimed subject matter nor is it intended for use in determining or
limiting the scope of the claimed subject matter.
[0006] In accordance with an embodiment of the present subject matter, a subscription
account monitoring and updating (SAMU) system is described. The SAMU system is configured
to send an account retrieval request message for obtaining at least one subscription account detail
during an on-going active service session. The account retrieval request message is based on
initiation of a service session by a user of a communication device. The at least one subscription
account detail includes one of an account balance and at least one service units balance. The
SAMU system is also configured to receive an account retrieval response message including the
at least one subscription account detail, during the on-going active service session on the
communication device based on the account retrieval request message, and provide the at least
4
one subscription account detail on the communication device during the on-going active service
session.
[0007] In accordance with another embodiment of the present subject matter, a
subscription account retrieval and reporting (SARR) system is described. The SARR system is
configured to receive an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session over a communication network. The at
least one subscription account detail includes one of an account balance and at least one service
units balance. The SARR system is also configured to retrieve the at least one subscription
account detail based on the account retrieval request message, during the on-going active service
session, and send an account retrieval response message in response to the account retrieval
request message during the on-going active service session, the account retrieval response
message including the at least one subscription account detail.
[0008] In accordance with another embodiment of the present subject matter, a method
includes sending an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session on a communication device over a
communication network. The account retrieval request message is based on initiation of a service
session by a user of the communication device. The at least one subscription account detail
includes one of an account balance and at least one service units balance. The method also
includes receiving an account retrieval response message including the at least one subscription
account detail, during the on-going active service session on the communication device based on
the account retrieval request message.
[0009] In accordance with another embodiment of the present subject matter, a method
includes receiving an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session over a communication network. The at
least one subscription account detail includes one of an account balance and at least one service
units balance. The method also includes retrieving the at least one subscription account detail
based on the account retrieval request message, during the on-going active service session, and
sending an account retrieval response message including the at least one subscription account
detail, The account retrieval response message is sent, during the on-going active service session,
at a predefined time interval, based on the account retrieval request message.
5
[0010] In accordance with another embodiment of the present subject matter, a computer
readable medium having a set of computer readable instructions is disclosed. The computer
readable instructions on the computer readable medium, when executed, perform acts including
sending an account retrieval request message for obtaining at least one subscription account
detail during an on-going active service session on a communication device over a
communication network, and receiving an account retrieval response message including the at
least one subscription account detail, during the on-going active service session on the
communication device based on the account retrieval request message. The account retrieval
request message is based on initiation of the on-going active service session by a user of the
communication device.
[0011] In accordance with yet another embodiment of the present subject matter, a
computer readable medium having a set of computer readable instructions is disclosed. The
computer readable instructions on the computer readable medium, when executed, perform acts
including receiving an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session over a communication network,
retrieving the at least one subscription account detail based on the account retrieval request
message, during the on-going active service session, and sending an account retrieval response
message including the at least one subscription account detail. The account retrieval response
message is sent, during the on-going active service session, at a predefined time interval, based
on the account retrieval request message. The at least one subscription account detail includes
one of an account balance and at least one service units balance.
BRIEF DESCRIPTION OF THE FIGURES
[0012] The detailed description is described with reference to the accompanying figures.
In the figures, the left-most digit(s) of a reference number identifies the figure in which the
reference number first appears. The same numbers are used throughout the figures to reference
like features and components. Some embodiments of systems and/or methods in accordance with
embodiments of the present subject matter are now described, by way of example only, and with
reference to the accompanying figures, in which:
[0013] Figure 1 schematically illustrates a subscription account management system, in
accordance with an embodiment of the present subject matter.
6
[0014] Figure 2 illustrates a subscription account monitoring and updating (SAMU)
system and a subscription account retrieval and reporting (SARR) system, in accordance with an
embodiment of the present subject matter.
[0015] Figure 3 shows a plurality of displays illustrating details of the subscription
account which may be provided at a predefined time interval during an on-going call, in
accordance with an embodiment of the present subject matter.
[0016] Figure 4 shows displays illustrating details which may be provided for charging
unit selection by the user for the call, in accordance with an embodiment of the present subject
matter.
[0017] Figure 5 shows displays illustrating details which may be provided for rate plan
selection by the user for the call, in accordance with an embodiment of the present subject
matter.
[0018] Figure 6 shows displays illustrating details which may be provided during
subscription account sync-up process, in accordance with an embodiment of the present subject
matter.
[0019] Figure 7 shows a plurality of displays illustrating details which may be provided
for balance translation, in accordance with an embodiment of the present subject matter.
[0020] Figure 8 illustrates a call flow diagram for communication between the SAMU
system and the SARR system for monitoring details of subscription account, in accordance with
an embodiment of the present subject matter.
[0021] Figure 9 illustrates a call flow diagram for communication between the SAMU
system and the SARR system for charging unit selection, in accordance with an embodiment of
the present subject matter.
[0022] Figure 10 illustrates a call flow diagram for communication between the SAMU
system and the SARR system for rate plan selection, in accordance with an embodiment of the
present subject matter.
[0023] Figure 11 illustrates a call flow diagram for communication between the SAMU
system and the SARR system for synching up with subscription account, in accordance with an
embodiment of the present subject matter.
7
[0024] Figure 12 illustrates a call flow diagram for communication between the SAMU
system and the SARR system for translation of a balance, in accordance with an embodiment of
the present subject matter.
[0025] Figure 13 illustrates a method for management of a subscription account, in
accordance with an embodiment of the present subject matter.
[0026] Figure 14 illustrates a method for management of a subscription account, in
accordance with an embodiment of the present subject matter.
[0027] Figure 15 illustrates a method for management of a subscription account, in
accordance with an embodiment of the present subject matter.
[0028] Figure 16 illustrates a method for management of a subscription account, in
accordance with an embodiment of the present subject matter.
[0029] Figure 17 illustrates a method for management of a subscription account, in
accordance with an embodiment of the present subject matter.
[0030] It should be appreciated by those skilled in the art that any block diagrams herein
represent conceptual views of illustrative systems embodying the principles of the present
subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state
transition diagrams, pseudo code, and the like represent various processes which may be
substantially represented in computer readable medium and so executed by a computer or
processor, whether or not such computer or processor is explicitly shown.
DESCRIPTION OF EMBODIMENTS
[0031] The present subject matter relates to systems and methods for management of
subscription account in communication devices.
[0032] A service provider typically provides various voice and/or data services to the
users having an authorized subscription account. The voice services and the data services are
typically referred to as voice calls and data calls, respectively. Examples of voice services
include, but are not restricted to, telephonic audio calls, audio chats, and such, and examples of
data services include, but are not restricted to, short message services (SMSs), multimedia
message services (MMSs), emails, web-access (Internet), gaming, and such.
[0033] In a pre-paid type subscription account, a user has to maintain a sufficient account
balance for utilizing one or more services provided to him and the subscription account should
8
have a valid validity term. The service provider deducts money from the account balance, in realtime,
each and every time the user utilizes one or more services, based on the amount of usage of
the service by the user. For example, for the voice calls the service provider deducts money, in
real-time, from the account balance based on the time duration of the voice call. For the data
calls the service provider deducts money, in real-time, from the account balance based on the
amount of data (number of data packets) transferred (download/upload) or based on the time
duration of the data call. Thus, the account balance reduces, in real-time, depending upon the
usage by the user.
[0034] In a post-paid type subscription account, which is pay-and-use type account, a
user may have an upper limit on usage of one or more services provided to him for a predefined
time period. For each subscription account, the service provider maintains details of service
usage or the usage balance for the predefined time period of each of the services based on the
respective upper limits. This usage balance based on the upper limit may be understood as an
account balance for the post-paid type subscription account.
[0035] Further, in some cases, a service provider may provide a predefined duration of
free talk-time, a predefined number of free SMSs, a predefined amount of free data transferring
(download/upload), and such, to a user, on his subscription account, for services provided by the
service provider. Such free offers are provided to the user in the form of free service units in the
subscription account, for which the subscription account is not charged. For example, a service
provider may provide free voice time units of a predefined time duration as the free service units
for the voice call service; a service provider may provide free SMS units with a predefined
number of free SMSs as the free service units for the SMS service; and a service provider may
provide free data download units of a predefined amount of data downloading as the free service
units for the data call service.
[0036] Further, in some cases, a user may pay and subscribe for a predefined duration of
talk-time, a predefined number of SMSs, a predefined amount of data transferring
(download/upload), and such, on his subscription account. Such paid subscriptions are provided
to the user in the form of service units which the user has to consume within a predefined time
period and for which the user is already charged.
9
[0037] Conventionally, for a subscription account, depending on a pre-paid type or a
post-paid type subscription account, any of the details of the subscription account, including the
account balance, the validity term, and the service units balance, is not provided to the user in
real-time. Conventionally, such details of the subscription account are displayed on user’s
communication device after the voice call or the data call. With this, the user may not have
knowledge of his account balance for pre-paid or post-paid subscription account, his free or paid
service units that are left, validity term of his subscription account, and such, at the time of
making a next voice or data call. Further, conventionally, the user may have to send a separate
request, from his end, to the service provider, for obtaining any of the above mentioned details of
his subscription account. Further, as the user would not have knowledge of the account balance
of the subscription account in real-time, he would not be able to estimate a possible time duration
for which the call can continue.
[0038] Further, with the user having paid or free service units in his subscription account
of a service, conventionally, depending on a variety of factor, such as type of call, type of
subscription plan, the service units balances are deducted initially during the voice or data calls,
till the available service units are exhausted. Thus, the user has substantially no control over
selection of which service units balance be charged for his calls. Further, the user also has
substantially no flexibility on whether the service provider should charge from one of the service
units balance, or from the account balance of the pre-paid or the post-paid type subscription
account for a particular type of call.
[0039] Embodiments of systems and methods for management of subscription accounts
in communication devices are described herein. The systems and the methods of the present
subject matter are configured to monitor, update, retrieve and report one or more details of a
subscription account to a user, dynamically or in real-time, while making a voice and/or data call
and during an on-going voice and/or data call. The details, which may be monitored, retrieved
and reported, include account balance, and service units balance, depending on whether the
subscription account is a pre-paid type or a post-paid type subscription account. The account
balance may be understood as a balance amount of money for a pre-paid type subscription
account, or may be understood as a usage balance based on the upper limit for a post-paid type
subscription account. Amongst other things, other details of the subscription account which may
10
be monitored, retrieved and reported, include validity term of the subscription account, rate plan
and charging rate based on which the account balance is charged, on-going active service
sessions of voice and data service, details of the type of ongoing voice or data call, roaming
status and such, in real-time, while making a voice and/or data call and during the on-going voice
and/or data call.
[0040] Further, in another implementation, the details which may be updated and
reported, may include a charging unit and a rate plan which a user may select, in real-time, for a
call. The charging unit is indicative of whether one of the service units balances, or the account
balance of the pre-paid or the post-paid type subscription account, is deducted for a voice call or
a data call. The rate plan may be a rate plan selected from a multiple rate plans offered by the
service provider to a user, which is indicative of rate at which a voice or data call be charged.
[0041] With the systems and the methods of the present subject matter, the user would
have a knowledge of the above mentioned details of his subscription account in real-time while
making a call and continuously during the call. Thus, with this, the user would not have to wait
for receiving such details at the end of the call or would not have to make a separate request to
the service provider for such details. The user would also be aware of the duration for which he
can continue the call based on the available account balance. Further, the user would be able to
have a control over whether the account balance or any of the service units balance be deducted,
and a control over the rate at which a call be charged.
[0042] The systems and methods described herein may be implemented in a variety of
network environments employing one or more communication devices communicatively coupled
to one or more communication network entities over a communication network. The
communication devices may include phones, smart phones, PDAs, and the like. The
communication network may include Global System for Communication (GSM) network,
Universal Telecommunications System (UMTS) network, Long Term Evolution (LTE) network,
Personal Communications Service (PCS) network, Time Division Multiple Access (TDMA)
network, Code Division Multiple Access (CDMA) network, Next Generation Network (NGN),
Public Switched Telephone Network (PSTN), and Integrated Services Digital Network (ISDN),
Internet Protocol (IP) Network. Although the description herein is with reference to certain
communication networks, the systems and methods may be implemented in other networks and
11
devices, albeit with a few variations, as will be understood by a person skilled in the art. Further,
depending on the type of communication network, the communication network entity may
include Online Charging System (OCS), which may be implemented in a computing device, such
as a computer, a mainframe computer, a server, and such, and the combination thereof.
[0043] In accordance with an implementation of the present subject matter, a system for
management of subscription accounts in the communication devices include one or more
subscription account monitoring and updating (SAMU) systems and at least one subscription
account retrieval and reporting (SARR) system communicatively coupled with each other over
the communication network. The SAMU system may be implemented as application in a
communication device, which can be configured by the user for the purpose of monitoring and
updating his subscription account on a real-time basis. The SARR system may be implemented
in a communication network entity, such as an application server or an OCS of the
communication network, for retrieval and reporting of subscription account details on a real-time
basis. An OCS is a communication network entity that keeps a track of a variety of details of
subscription accounts, including the account balance, the upper limits of services, the validity
term, the free and paid service units balance, the rate plan, the charging rates, the on-going active
service session details, the type of on-going call, the roaming details, and such, for all the users.
In a case where the SARR system is implemented in an application server, the SARR system
may communicate with the OCS for retrieving and reporting details of the subscription accounts
in accordance with the present subject matter. The SAMU system is configured to communicate
with the OCS through the SARR system for monitoring and updating of one or more details of
the subscription account, at a predefined time intervals. The details from the SARR system are
then provided on the user’s communication device by the SAMU system in real-time. The details
may be displayed or play as an audio on the communication device. In an implementation, the
SAMU system is configured to display all the details of the subscription account in a
consolidated manner on the user’s communication device in real-time.
[0044] In an implementation, for the purpose of monitoring the details of the subscription
account, a request is sent by the SAMU system to the SARR system for obtaining at least one
subscription account detail, depending on the type of subscription account. The request may be
sent by the SAMU system for obtaining the account balance during an on-going call made by the
12
user. An on-going call may be understood as an on-going active service session on the
communication device. Based on the request from the SAMU system, the account balance for the
subscription account is obtained by the SARR system from the OCS. The details obtained by the
SARR system are provided to the SAMU system, which are then provided by the SAMU system
to the user on his communication device. This facilitates the user to have knowledge of his
account balance, in real-time, during the call.
[0045] In an implementation, the request may be sent, at first, at the time a call is
initiated by the user. The call may be understood as a service session initiated by the user. With
this, the user would have a knowledge of his account balance while he is making the call. As the
call progresses, the account balance gets updated at the OCS. Further, during the on-going call, a
similar request for the account balance is sent periodically, at a predefined time interval, by the
SAMU system to the SARR system. Based on the periodic requests, the updated account balance
is obtained by the SARR system from the OCS and provided to the SAMU system. The updated
account balance is then provided by the SAMU system on the user’s communication device.
[0046] Further, in an implementation, a request may be sent by the SAMU system to the
SARR system for obtaining other details of the subscription account, during the on-going call.
The other details may include the service units balance, the validity term, the rate plan active for
the user, the charging rates based on the rate plan, on-going active service session details (data
call or voice call), the type of on-going call (SMS, email, audio call, web-access, etc.), roaming
details, and such. In an implementation, a separate request may be sent by the SAMU system to
the SARR system for obtaining the other details or a request for such details may be sent in the
request for the account balance as mentioned above. Based on the request from the SAMU
system, the other details of the subscription account are obtained by the SARR system from the
OCS and provided to the SAMU system. The obtained other details are then provided by the
SAMU system on the user’s communication device.
[0047] In an implementation, the SAMU system may be configured to allow the user to
select, in real-time, a charging unit for a voice or data call. The user may be able select one from
the account balance and any of the service units balances as the charging unit. The selected
charging unit is indicative of the balance, one from the service units balances or the account
balance of the pre-paid or the post-paid type subscription account, which is to be deducted for a
13
voice call or a data call. For this, as the user initiates a call, depending on the type of call (data or
voice call), a request is sent by the SAMU system to the SARR system for obtaining the account
balance, depending on the type of subscription account, along with the service units balance
associated with that type of call. In an example, the service units balance may include voice time
units balance for the voice calls, and SMS units balance and data download units balance for the
data calls.
[0048] Based on the request from the SAMU system, the account balance and the service
units balance for the subscription account are obtained by the SARR system from the OCS. The
details obtained by the SARR system are provided to the SAMU system, which are then
displayed by the SAMU system to the user on his communication device. Along with the details,
the SARR system may send a request to the SAMU system for the user to select one from the
account balance and one of the service units balance for charging for the call. The user may
select one of the above, and based on his selection, a response with details of the selection are
provided to the SARR system. The SARR system may then send the details of the selection by
the user, to the OCS, and the OCS may accordingly charge the subscription account. This
facilitates the user to selectively control of how his subscription account be charged for the calls.
[0049] Further, in an implementation, the SAMU system may be configured to allow the
user to select, in real-time, one from multiple rate plans, provided by the service provider to the
user, for charging for a voice call or a data call. A rate plan typically includes charging rates, for
example, per second, per minute, per SMS, per data packets, and such, at which the subscription
account is charged. The service provider may provide two or more rate plans to a user. The
multiple rate plans may be provided based on a variety of parameters, including the type of
subscription account, the type of call service from international call service and national call
service, roaming, the type of call from voice and data call, and such.
[0050] For this, as the user initiates a call, depending on the type of call (data or voice
call), a request is sent by the SAMU system to the SARR system for obtaining the multiple rate
plans that are provided to the user. Based on the request from the SAMU system, the multiple
rate plans are obtained by the SARR system from the OCS. In addition to the multiple rate plans,
the SARR system may obtain the details of account balance and the service units balance
associated with the subscription account. The details obtained by the SARR system are provided
14
to the SAMU system, which are then displayed by the SAMU system to the user on his
communication device. Along with the details, a request may be sent by the SARR system to the
SAMU system for the user to select one of the rate plans for charging for the call. The user may
then select one of the rate plans, and based on his selection, a response with details of the
selection are provided to the SARR system. The details of the selection by the user provided to
the SARR system may then be sent to the OCS, and the subscription account may be accordingly
charged by the OCS. Conventionally, the service providers provide a fixed rate plan to the user,
and user has substantially no flexibility to select the rate at which his account balance be
charged. However, with the SAMU system and the SARR system of the present subject matter,
the user is facilitated to selectively control of on which rate plans his subscription account is
charged for the calls.
[0051] Further, in an implementation, the SAMU system is configured to sync up, in
real-time, the details of the subscription account on the user’s communication device with
updated details of the subscription account on the OCS. The details of the subscription account
may get updated as the user may subscribe or recharge his subscription account depending on the
type of subscription account. The details of the subscription account, which may get updated,
and hence synched, include the account balance and any of the service units which may be
subscribed by the user.
[0052] In an implementation, for the purpose of synching up, after the user has availed a
new service or recharged for an existing service, a request is sent by the SAMU system to the
SARR system for synching the details of subscription account on the communication device with
the details on the OCS. Based on the request from the SAMU system, a further request is sent by
the SARR system to the OCS for obtaining the updated details of the subscription account from
the OCS. The updated details may be obtained by the SARR system from the OCS are sent to the
SAMU system, based on which the SAMU system may sync the detail on the communication
device with the updated details.
[0053] Further, in an implementation, the SAMU system is configured to allow the user
to translate or modify, in real-time, the details of his subscription account by transferring or
converting a part of the account balance available in the subscription account to at least one of
the service units balance, or a part of a service units balance to the account balance, or a part of
15
one service units balance to another service units balance. The part that is converted from one
balance to another may be selected by the user.
[0054] In an implementation, for the purpose of translation of a balance in the
subscription account, an update is sent by the SAMU system to the SARR system for updating or
altering the details of subscription account on the OCS. The update is configured to send details
of conversion of one balance, for example, the account balance, to another balance, for example,
the voice call units balance, SMS units balance, or such. Based on the update from the SAMU
system, a further update is sent by the SARR system to the OCS for updating or altering the
details of the balances in the subscription account. Subsequent to this, the updated or altered
balances obtained by the SARR system from the OCS, are sent to the SAMU system. The
updated balances obtained by the SAMU system may be provided or displayed to the user on the
communication device.
[0055] The described methodologies can be implemented in hardware, firmware,
software, or a combination thereof. For a hardware implementation, the processing units can be
implemented within one or more application specific integrated circuits (ASICs), digital signal
processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices
(PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers,
microprocessors, electronic devices, other electronic units designed to perform the functions
described herein, or a combination thereof. Herein, the term "system" encompasses logic
implemented by software, hardware, firmware, or a combination thereof.
[0056] For a firmware and/or software implementation, the methodologies can be
implemented with modules (e.g., procedures, functions, and so on) that perform the functions
described herein. Any machine readable medium tangibly embodying instructions can be used in
implementing the methodologies described herein. For example, software codes and programs
can be stored in a memory and executed by a processing unit. Memory can be implemented
within the processing unit or may be external to the processing unit. As used herein the term
"memory" refers to any type of long term, short term, volatile, nonvolatile, or other storage
devices and is not to be limited to any particular type of memory or number of memories, or type
of media upon which memory is stored.
16
[0057] In another firmware and/or software implementation, the functions may be stored
as one or more instructions or code on a non transitory computer-readable medium. Examples
include computer-readable media encoded with a data structure and computer-readable media
encoded with a computer program. Computer-readable media may take the form of an article of
manufacturer. Computer-readable media includes physical computer storage media. A storage
medium may be any available medium that can be accessed by a computer. By way of example,
and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CDROM
or other optical disk storage, magnetic disk storage or other magnetic storage devices, or
any other medium that can be used to store desired program code in the form of instructions or
data structures and that can be accessed by a computer; disk and disc, as used herein, includes
compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray
disc where disks usually reproduce data magnetically, while discs reproduce data optically with
lasers. Combinations of the above should also be included within the scope of computer-readable
media.
[0058] In addition to storage on computer readable medium, instructions and/or data may
be provided as signals on transmission media included in a communication apparatus. For
example, a communication apparatus may include a transceiver having signals indicative of
instructions and data. The instructions and data are configured to cause one or more processors to
implement the functions outlined in the claims. That is, the communication apparatus includes
transmission media with signals indicative of information to perform disclosed functions. At a
first time, the transmission media included in the communication apparatus may include a first
portion of the information to perform the disclosed functions, while at a second time the
transmission media included in the communication apparatus may include a second portion of
the information to perform the disclosed functions.
[0059] It should be noted that the description merely illustrates the principles of the
present subject matter. It will thus be appreciated that those skilled in the art will be able to
devise various arrangements that, although not explicitly described herein, embody the principles
of the present subject matter and are included within its spirit and scope. Furthermore, all
examples recited herein are principally intended expressly to be only for pedagogical purposes to
aid the reader in understanding the principles of the invention and the concepts contributed by
17
the inventor(s) to furthering the art, and are to be construed as being without limitation to such
specifically recited examples and conditions. Moreover, all statements herein reciting principles,
aspects, and embodiments of the invention, as well as specific examples thereof, are intended to
encompass equivalents thereof.
[0060] The manner in which the systems and methods for management of subscription
account in communication devices shall be implemented has been explained in details with
respect to the Figures 1 to 17. While aspects of described systems and methods for management
of subscription account in communication devices can be implemented in any number of
different computing systems, transmission environments, and/or configurations, the
embodiments are described in the context of the following exemplary system(s).
[0061] It will also be appreciated by those skilled in the art that the words during, while,
and when as used herein are not exact terms that mean an action takes place instantly upon an
initiating action but that there may be some small but reasonable delay, such as a propagation
delay, between the initial action and the reaction that is initiated by the initial action.
Additionally, the word “connected” and “coupled” is used throughout for clarity of the
description and can include either a direct connection or an indirect connection.
[0062] Figure 1 schematically illustrates a subscription account management system 100
implementing a SAMU system 102 for monitoring and updating a subscription account of a user,
and a SARR system 104 for retrieving and reporting details of the subscription account of the
user, in accordance with an embodiment of the present subject matter. As mentioned earlier, the
SAMU system 102 may be implemented as an application in a communication device 106 that
includes, but is not restricted to, a phone, a smart phone, a PDA, and the like, and the SARR
system 104 may be implemented in a communication network entity 108 of a communication
network 110 over which the SAMU system 102 and the SARR system 104 are communicatively
coupled. The communication network entity is a computing system that includes, but is not
restricted to a mainframe computer, a server, and the like. For the sake of simplicity, Figure 1
shows one SAMU system 102 communication with the SARR system 104. However, in various
implementations, a plurality of SAMU systems 102, each implemented in a communication
device, may communicate with the SARR system 104.
18
[0063] Further, the SARR system 104 may be communicatively coupled to an OCS 112
of the communication network 110 for retrieving the details of the subscription account of the
user. As mentioned earlier, the OCS 112 is a communication network entity that keeps a track of
a variety of details of subscription accounts, including the account balance, the upper limits of
services, the validity term, the free and paid service units balance, the rate plan, the charging
rates, the on-going active service session details, the type of on-going call, the roaming details,
and such, for all the users. Although, in Figure 1, the SARR system 104 and the OCS 112 are
shown as separate entities; however, in an implementation, the SARR system 104 and the OCS
112 may be part of the same communication network entity.
[0064] The communication network 110 may be a wireless or a wired network, or a
combination thereof. The communication network 110 can be a collection of individual
networks, interconnected with each other and functioning as a single large network. Examples of
such individual networks include, but are not limited to, GSM network, UMTS network, LTE
network, PCS network, TDMA network, CDMA network, NGN, PSTN, ISDN, and IP network.
Depending on the terminology, the communication network 110 includes various network
entities, such as gateways and routers; however, such details have been omitted to maintain the
brevity of the description. Further, it may be understood that the communication between the
SAMU system 102, the SARR system 104, and the OCS 112 may take place based on the
communication protocol compatible with the communication network 110.
[0065] In an implementation, the communication network 110, along with other entities,
includes a standard telecommunication network entity (not shown) that may include one or more
of BSC, BTS, VMSC/VLR, Radio Network Controller (RNC), Node B, etc., depending on the
type of communication network 110. As apparent, the telecommunication network entity
continues to deal with the conventional telecommunication standard based signals in a
conventionally manner.
[0066] In an implementation, the SAMU system 102 includes a monitoring module 114
which is configured to generate and send a request to SARR system 104 for obtaining at least
one subscription account detail from the OCS 112, in real-time, during an on-going call, for the
purpose of monitoring the details of the subscription account. The SARR system 104 includes a
retrieving module 116 which is configured to receive the request from the SAMU system 102,
19
and retrieve the subscription account details from the OCS 112 for being sent to the SAMU
system 102. The details of monitoring of the subscription account are described later in the
description with reference to the description of Figure 2.
[0067] Figure 2 illustrates the SAMU system 102 and the SARR system 104, in
accordance with an embodiment of the present subject matter. In accordance with the afore going
description, the SAMU system 102 and the SARR system 104 are communicatively coupled to
each other for the purposes of monitoring, updating, retrieval and reporting of details of
subscription account of a user via a telecommunication/IP network. For the sake of brevity and
ease of explanation, the present subject matter is described in context of phones coupled to a
GSM/IP based communication network capable of providing voice and data services to users.
However, the same should not be construed as a limitation. It will be appreciated by those skilled
in the art, that the present subject matter may be implemented for other communication
networks, albeit with a few variations, as will be understood by a person skilled in the art. With
the GSM/IP based communication network, the OCS 112 may be a service control point.
[0068] The SAMU system 102 and the SARR system 104 include processor(s) 202-1 and
202-2, collectively referred to as processors 202 and individually referred to as a processor 202.
The processors 202 may be implemented as one or more microprocessors, microcomputers,
microcontrollers, digital signal processors, central processing units, state machines, logic
circuitries, and/or any devices that manipulate signals based on operational instructions. Among
other capabilities, the processors 202 are configured to fetch and execute computer-readable
instructions stored in the memory.
[0069] The functions of the various elements shown in the figure, including any
functional blocks labeled as “processor(s)”, may be provided through the use of dedicated
hardware as well as hardware capable of executing software in association with appropriate
software. When provided by a processor, the functions may be provided by a single dedicated
processor, by a single shared processor, or by a plurality of individual processors, some of which
may be shared. Moreover, explicit use of the term “processor” should not be construed to refer
exclusively to hardware capable of executing software, and may implicitly include, without
limitation, digital signal processor (DSP) hardware, network processor, application specific
integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for
20
storing software, random access memory (RAM), non-volatile storage. Other hardware,
conventional and/or custom, may also be included.
[0070] Also, the SAMU system 102 and the SARR system 104 include interface(s) 204-1
and 204-2, collectively referred to as interfaces 204 and individually referred to as an interface
204. The interfaces 204 may include a variety of software and hardware interfaces that allow the
SAMU system 102 and the SARR system 104 to interact with each other. Further, the interfaces
204 may enable the SAMU system 102 and the SARR system 104 to communicate with other
communication and computing devices, such as web servers and external repositories. The
interfaces 204 may facilitate multiple communications within a wide variety of networks and
protocol types, including wire networks, for example, LAN, cable, SS7, IP, etc., and wireless
networks, for example, WLAN, cellular, satellite-based network, etc.
[0071] Further, the SAMU system 102 and the SARR system 104 include memory 206-1
and 206-2, coupled to the processors 202-1, 202-2, collectively and individually referred to as
memory 206. The memory 206 may include any computer-readable medium known in the art
including, for example, volatile memory (e.g., RAM), and/or non-volatile memory (e.g.,
EPROM, flash memory, etc.).
[0072] Further, the SAMU system 102 and the SARR system 104, respectively, includes
modules 208-1, 208-2 and data 210-1, 210-2, collectively and individually referred to as modules
208 and data 210, respectively. The modules 208 may be coupled to the processors 202. The
modules 208, amongst other things, include routines, programs, objects, components, data
structures, etc., which perform particular tasks or implement particular abstract data types. The
modules 208 may also be implemented as, signal processor(s), state machine(s), logic circuitries,
and/or any other device or component that manipulate signals based on operational instructions.
The modules 208 further include modules that supplement applications on the SAMU system
102 and the SARR system 104, for example, modules of an operating system. The data 210
serves, amongst other things, as a repository for storing data that may be fetched, processed,
received, or generated by one or more of the modules 208. Although the data 210 is shown
internal to the SAMU system 102 and the SARR system 104, it may be understood that the data
210 can reside in an external repository (not shown in the figure), which may be coupled to the
SAMU system 102 and the SARR system 104. The SAMU system 102 and the SARR system
21
104 may communicate with the external repository through the interfaces 204 to obtain
information from the data 210.
[0073] Further, the modules 208 can be implemented in hardware, instructions executed
by a processing unit, or by a combination thereof. The processing unit can comprise a computer,
a processor, a state machine, a logic array or any other suitable devices capable of processing
instructions. The processing unit can be a general-purpose processor which executes instructions
to cause the general-purpose processor to perform the required tasks or, the processing unit can
be dedicated to perform the required functions.
[0074] In another aspect of the present subject matter, the modules 208 may be machinereadable
instructions (software) which, when executed by a processor/processing unit, perform
any of the described functionalities. The machine-readable instructions may be stored on an
electronic memory device, hard disk, optical disk or other machine-readable storage medium or
non-transitory medium. In one implementation, the machine-readable instructions can be also be
downloaded to the storage medium via a network connection.
[0075] In an implementation, the modules 208-1 of the SAMU system 102 includes the
monitoring module 114, a charging unit selection module 214, a rate plan selection module 216,
a sync-up module 218, a balance translation module 220, and other module(s) 222. In an
implementation, the data 210-1 of the SAMU system 102 includes subscription account data
230-1, and other data 232. The other module(s) 222 may include programs or coded instructions
that supplement applications and functions, for example, programs in the operating system of the
SAMU system 102, and the other data 232 comprise data corresponding to one or more other
module(s) 222.
[0076] Similarly, in an implementation, the modules 208-2 of the SARR system 104
includes the retrieving module 116, a reporting module 226, and other module(s) 228. In an
implementation, the data 210-2 of the SARR system 104 includes subscription account data 230-
2, and other data 234. The other module(s) 228 may include programs or coded instructions that
supplement applications and functions, for example, programs in the operating system of the
SARR system 104, and the other data 234 comprise data corresponding to one or more other
module(s) 228.
22
[0077] Further, as mentioned, the SAMU system 102 and the SARR system 104 may
communicate with each other for the purposes of monitoring, updating, retrieving and reporting
various details of the subscription account of a user. The procedures implemented for such
purposes are explained in detail, in reference to the SAMU system 102 and the SARR system
104, under the following sections, viz., subscription account monitoring, charging unit selection,
rate plan selection, subscription account sync-up, and balance translation.
Subscription Account Monitoring
[0078] The functionality of subscription account monitoring relates to monitoring one or
more details of a subscription account, dynamically or in real-time, while making a call and
during the call. In an implementation, for the purpose of monitoring the details of the
subscription account, the monitoring module 114 of the SAMU system 102 is configured to
generate an account retrieval request message and send the account retrieval request message to
the SARR system 104 for obtaining at least one subscription account detail from the OCS 112, in
real-time, during an on-going call. As mentioned earlier, the on-going call may be referred to as
an on-going active service session on the phone. The account retrieval request message may be
encoded with information related to retrieval or obtaining at least one subscription account detail.
The subscription account details include, but not restricted to, an account balance and at least one
service units balance. In an implementation, the subscription account details may also include a
validity term, a rate plan for an on-going call, a charging rate for an on-going call, on-going
service, on-going type of call, and roaming status.
[0079] After the account retrieval request message is sent by the monitoring module 114,
the retrieving module 116 of the SARR system 104 receives the account retrieval request
message from the monitoring module 114, and, based on the account retrieval request message,
retrieves the at least one subscription account detail from the OCS 112, during the on-going call.
After retrieving the subscription account detail from the OCS 112, the reporting module 226
generates an account retrieval response message, comprising the at least one subscription
account detail, and sends the account retrieval response message to the SAMU system 102,
during the on-going call on the phone. The account retrieval response message is encoded with
information associated with the at least one subscription account detail which is retrieved from
23
the OCS 112 during the call. Further, the retrieved subscription account details are stored in the
subscription account data 230-2 of the SARR system 104.
[0080] After the account retrieval response message is sent by the reporting module 226,
the monitoring module 114 of the SAMU system 102 receives the account retrieval response
message during the on-going call on the phone. In an implementation, the monitoring module
114 is configured to identify the at least one subscription account detail encoded in the account
retrieval response message, and display the at least one subscription account detail to the user, on
the phone, during the on-going call. The obtained subscription account details are stored in the
subscription account data 230-1 of the SAMU system 102.
[0081] Further, in an implementation, at the time the user initiates a call on the phone, the
SAMU system 102 may be activated, and the monitoring module 114 of the SAMU system 102
may generate and send the account retrieval request message to the SARR system 104. The user
may initiate a data call or a voice call. Based on the account retrieval request message, the
retrieving module 116 of the SARR system 104 may retrieve the at least one subscription
account detail from the OCS 112 periodically, at a predefined time interval, during the on-going
call. It may be understood that the details of the subscription account, such as the account
balance and service units balance, get updated, in real-time, during the on-going call, at the OCS
112. Further, the reporting module 226 may be configured to generate the account retrieval
response message, each time the at least one subscription account detail is retrieved, and send the
response message periodically, at the predefined time interval, during the on-going call. In an
implementation, the predefined time interval may be in a range from about 10 seconds to 5
minutes. This facilitates the user to have knowledge of details of his subscription account,
including the account balance and/or at least service units balance, in real-time, during the call.
[0082] Figure 3 shows a plurality of displays 300-1, 300-2, … , 300-n illustrating the
details of the subscription account which may be provided on the screen of the phone repeatedly
at the predefined time interval during the on-going call initiated by the user, in accordance with
an implementation of the present subject matter. The displays 300-1, 300-2, … , 300-n
hereinafter may be collectively referred to as the displays 300, and individually referred to as the
display 300. The display 300-1 may be provided at the time call is initiated by the user, i.e., time
is 0 second, the display 300-2 may be provided at the predefined time interval during the call,
24
and the subsequent displays 300 may be provided after every predefined time interval during the
call, till the call is terminated by the user. The displays 300 provide the updated account balance
and/or the updated service units balances, at predefined time intervals, which are reduced during
the call. As shown in the displays 300, the account balance is reduced for each subsequent
display 300 for the voice call initiated by the user. The displays 300 also provide details of the
subscription account, such as the on-going active service session, the rate plan for the call, the
charging rate for the call, and the validity term. It may be noted that Figure 3 shows examples of
displays 300 for illustrative purposes. The details of the subscription account may be provided or
displayed on a communication device of the user in other forms, in real-time, during the call.
[0083] In an implementation, the monitoring module 114 is configured to send the
account retrieval request message once at the time a call is initiated by the user; the retrieving
module 116 is configured to retrieve the subscription account details periodically, at a predefined
time interval, during the on-going call; and the reporting module 226 is configured to send the
account retrieval response message with the subscription account details to the SAMU system
102 periodically, at the predefined time interval, during the on-going call.
[0084] In another implementation, the monitoring module 114 is configured to send the
account retrieval request message at the time a call is initiated by the user and subsequently at a
predefine time interval during the on-going call; the retrieving module 116 is configured to
retrieve the subscription account details periodically, at the predefined time interval, during the
on-going call; and the reporting module 226 is configured to send the account retrieval response
message with the subscription account details to the SAMU system 102 periodically, at the
predefined time interval, during the on-going call.
[0085] Further, in an implementation, the monitoring module 114 is configured to send a
request only for the account balance and service units balance in the account retrieval request
message; the retrieving module 116 is configured to retrieve, during the on-going call, the
account balance and the service units balance, along with other details, such as the validity term,
the rate plan for the on-going call, the charging rate for the on-going call, the on-going service,
the on-going type of call, and the roaming status; and the reporting module 226 is configured to
send the account retrieval response message with all the subscription account details to the
SAMU system 102 periodically, at the predefined time interval, during the on-going call. In
25
another implementation, the monitoring module 114 is configured to send separate request
messages for the account balance and the service units balance, and for the other details.
[0086] In an implementation, as the account balance and the service units balance is
monitored in real-time, during the on-going call, the monitoring module 114 may generate an
alert signal, to alert the user, in case the account balance or the service units balance, which is
being deducted during the on-going call, is reduced below a predefined limit value. For this, the
account balance or the service units balance received in the account retrieval response message,
from the SARR system 104, periodically during the on-going call, is compared, at each instance,
with the predefined limit value. If the account balance or the service units balance is below the
predefined limit value, the alert signal may be generated to alert the user. In an implementation,
the predefined limit value may be defined by the user on the phone, or defined by the service
provider. Further, in an implementation, the monitoring module 114 may generate an audio alert
signal and/or a visual alert signal that may be played by the phone or displayed on the screen of
the phone. With the alert signal, the user may get an indication that his account balance or the
service units balance, which is being used for the on-going call, is about to get exhausted.
Charging Unit Selection
[0087] The functionality of charging unit selection relates to selection of a charging unit,
dynamically or in real-time, by a user for the call initiated by him. The user may be able to select
a charging unit for the call from the account balance and service units balances available in the
subscription account. In an implementation, for the purpose of selection of a charging unit, as the
user initiates a call on the phone, the SAMU system 102 may be activated, and the charging unit
selection module 214 may generate a call-type indication request message and send the call-type
indication request message to the SARR system 104 for obtaining call-specific subscription
account details from the OCS 112 depending on the type of call. The call-specific subscription
account details for the charging unit selection may include the account balance, and the service
units balances, which may be charged for the call. The call-type indication request message is
encoded with information related to the type of call initiated by the user and information related
to the request for obtaining the call-specific subscription account details.
26
[0088] After the call-type indication request message is sent by the charging unit
selection module 214, the retrieving module 116 of the SARR system 104 receives the call-type
indication request message from the charging unit selection module 214, and, based on the calltype
indication request message, retrieves the call-specific subscription account details from the
OCS 112. In an implementation, the retrieving module 116 may identify the type of call initiated
by the user, and accordingly retrieve the call-specific subscription account details. In an
implementation, the call-specific subscription account details may include the account balance
and/or one or more service units balances which can be selected by the user for charging for the
initiated call. For example, the service units balance may include a voice time units balance if a
voice call is initiated, and an SMS units balance and a data download units balance if a data call
is initiated. The retrieved subscription account details are stored in the subscription account data
230-2 of the SARR system 104.
[0089] After retrieving the above mentioned subscription account details from the OCS
112, the retrieving module 116 generates a charging unit selection request message and sends the
charging unit selection request message to the SAMU system 102 for selection of a charging unit
by the user, for the call. The charging unit selection request message, generated by the retrieving
module 116, is encoded with the information associated with the balances, retrieved from the
OCS 112 based on the type of call, either of which can be selected by the user for the call. The
charging unit selection request message is also encoded with information related to a request for
selection of a charging unit based on the subscription account details in the message.
[0090] After the charging unit selection request message is sent to the SAMU system
102, the charging unit selection module 214 receives the message. The charging unit selection
module 214 identifies the balances in the charging unit selection request message, and displays
such details to the user, on the phone. The details of the balances are stored in the subscription
account data 230-1 of the SAMU system 102. Further, the charging unit selection module 214
identifies the request for selection of a charging unit from the charging unit request message, and
displays the balances that are possible for selection as the charging unit for the call by the user.
In an implementation, charging unit selection module 214 may configure the balances, which are
possible for selection, as active on the phone for selection by the user. The user may be able to
select one from the account balance and any of the active service units balances as an active
27
charging unit. The active charging unit is indicative of the balance, either from the service units
balance or the account balance of the pre-paid or the post-paid type subscription account, which
is to be deducted for the call to be made by the user.
[0091] Further, based on the charging unit selection request message, the charging unit
selection module 214 receives an input from the user for selection of the active charging unit,
generates a charging unit selection response message with details of the active charging unit, and
sends the charging unit selection response message to the SARR system 104. The charging unit
selection response message, generated by the charging unit selection module 214, is encoded
with information related to the active charging unit as selected by the user. The retrieving
module 116 receives the charging unit selection response message. The reporting module 226
identifies the details of the active charging unit in the charging unit selection response message
and reports the details to the OCS 112, which may accordingly charge the subscription account.
[0092] The process of charging unit selection, as described above, is initiated as a call is
initiated by the user on the phone. In an implementation, the process of charging unit selection
may be initiated along with the initiation of the rate plan selection process for selection of a rate
plan for a call, in accordance with the present subject matter, and the user may be able to view
the account balance and/or the service units balance, in real-time, during the call.
[0093] Figure 4 shows displays 400-1 and 400-2 illustrating the details which may be
provided on the screen of the phone for the charging unit selection by the user for the call, in
accordance with an implementation of the present subject matter. For the charging unit selection,
the display 400-1 may be provided for selection of a type of call to be initiated by the user. The
user may select the data call or the voice call. Based on the type of call initiated by the user, the
display 400-2 may be provided with the account balance and/or the service units balances, which
are possible for selection by the user for the call, as retrieved from the OCS 112. The user may
select either the account balance or one of the service units balances, as the active charging unit
for the call initiated by him. It may be noted that Figure 4 shows examples of displays 400-1 and
400-2 for illustrative purposes. The details may be provided or displayed on a communication
device of the user in other forms, in real-time.
Rate Plan Selection
28
[0094] The functionality of rate plan selection relates to selection of a rate plan,
dynamically or in real-time, by a user for the call initiated by him. The user may be able to select
a rate plan for the call from multiple rate plans available in the subscription account. In an
implementation, for the purpose of selection of a rate plan, as the user initiates a call on the
phone, the SAMU system 102 may be activated, and the rate plan selection module 216 may
generate a call-type indication request message and send the call-type indication request message
to the SARR system 104 for obtaining rate plan subscription account details from the OCS 112
depending on the type of call. The rate plan subscription account details for the rate plan
selection may include multiple rate plans that are provided to the user by the service provider.
One of the multiple rate plans may be selected by the user for the call initiated by him. The
service provider may provide two or more rate plans to a user. As mentioned earlier, the multiple
rate plans may be provided based on a variety of parameters, including the type of subscription
account, the type of call service from international call service and national call service, roaming,
the type of call from voice and data call, and such.
[0095] The call-type indication request message, generated by the rate plan selection
module 216, is encoded with information related to the type of call initiated by the user and
information related to rate plan request. After the call-type indication request message is sent by
the rate plan selection module 216, the retrieving module 116 of the SARR system 104 receives
the call-type indication request message from the rate plan selection module 216, and, based on
the call-type indication request message, retrieves the rate plan subscription account details from
the OCS 112. In an implementation, the retrieving module 116 may identify the type of call
initiated by the user, and accordingly retrieve the rate plan subscription account details. In an
example, the retrieving module 116, in this case, may retrieve details related to multiple rate
plans that are associated with the type of call, and from which the user can select one of the rate
plans for the initiated call. The retrieved details are stored in the subscription account data 230-2
of the SARR system 104.
[0096] After retrieving the details of multiple rate plans from the OCS 112, the retrieving
module 116 generates a rate plan selection request message and sends the rate plan selection
request message to the SAMU system 102 for selection of a rate plan, from the multiple rate
plans, by the user for the call. The rate plan selection request message, generated by the
29
retrieving module 116, is encoded with the information associated with the multiple rate plans
retrieved from the OCS 112, and encoded with information related to a request for selection of a
rate plan based on the rate plan subscription account details in the message.
[0097] After the rate plan selection request message is sent to the SAMU system 102, the
rate plan selection module 216 receives the message. The rate plan selection module 216
identifies the multiple rate plans in the rate plan selection request message, and display such
details to the user, on the phone. The details of the multiple rate plans are stored in the
subscription account data 230-1 of the SAMU system 102. Further, the rate plan selection
module 216 identifies the request for selection of the rate plan from the rate plan selection
request message, and displays the multiple rate plans that are possible for selection as an active
rate plan by the user. The user may be able to select one of the multiple rate plans as the active
rate plan for the call. The active rate plan is indicative of the charging rates, for example, per
second, per minute, per SMS, per data packets, and such, at which the subscription account is
charged for the voice or data call.
[0098] Based on the rate plan selection request message, the rate plan selection module
216 receives an input from the user for selection of the active rate plan, generates a rate plan
selection response message with details of the active rate plan, and sends the rate plan selection
response message to the SARR system 104. The rate plan selection response message, generated
by the rate plan selection module 216, is encoded with information related to the active rate plan
as selected by the user. The retrieving module 116 receives the rate plan selection response
message. The reporting module 226 identifies the details of the active rate plan in the rate plan
selection response message and reports the details to the OCS 112, which may accordingly
charge the subscription account.
[0099] The process of rate plan selection, as described above, is initiated as a call is
initiated by the user on the phone. In an implementation, the process of rate plan selection may
be initiated along with the initiation of charging unit selection, in accordance with the present
subject matter, and the user may be able to view the account balance and/or the service units
balance, in real-time, during the call.
[0100] Figure 5 shows displays 500-1 and 500-2 illustrating the details which may be
provided on the screen of the phone for the rate plan selection by the user for the call, in
30
accordance with an implementation of the present subject matter. For the rate plan selection, the
display 500-1 may be provided for the selection of a type of call to be initiated by the user. The
user may select the data call or the voice call. Based on the type of call initiated by the user, the
display 500-2 may be provided with multiple rate plans, which are possible for selection by the
user for the call, as retrieved from the OCS 112. The user may select any one of the multiple rate
plans, as the active rate plan for the call initiated by him. It may be noted that Figure 5 shows
examples of displays 500-1 and 500-2 for illustrative purposes. The details may be provided or
displayed on a communication device of the user in other forms, in real-time.
Subscription Account Sync-up
[0101] The functionality of subscription account sync-up relates to synching up of details
of the subscription account on the phone with the updated details of the subscription account on
the OCS 112, in real-time. The user may be able to sync-up the details on the phone based on
subscription of service units balances or recharging of the account balance. In an
implementation, for synching up of details of the subscription account on the phone with updated
details of the subscription account on the OCS 112, the sync-up module 218 is configured to
send a sync request message to the SARR system 104 for obtaining the updated details of the
subscription account from the OCS 112. The sync request message, generated by the sync-up
module 218, is encoded with information related to the request for synching. The updated details
of the subscription account may be based on recharging of the account balance, and/or for one or
more of the service units balances, by the user.
[0102] After the sync request message is sent by the sync-up module 218, the retrieving
module 116 retrieves the updated account balance and/or the updated service units balances, for
the subscription account of the user, from the OCS 112. The retrieved details are stored in the
subscription account data 230-2 of the SARR system 104. Based on the retrieved details, the
reporting module 226 generates a sync response message, comprising the updated account
balance and/or the updated service units balances, and sends the sync response message to the
SAMU system 102. The sync response message, generated by the reporting module 226, is
encoded with information related to the updated account balance and/or the updated service units
balance.
31
[0103] After the sync response message is sent by the reporting module 226, the sync-up
module 218 receives the sync response message, and identifies the updated account balance
and/or the updated service units balances from the sync response message. Subsequent to this,
the sync-up module 218 syncs the details on phone with the updated details, identified from the
sync response message. The updated account balance and/or the updated service units balance
are stored in the subscription account data 230-1 of the SAMU system 102 and displayed to the
user on the phone.
[0104] Figure 6 shows displays 600-1 and 600-2 illustrating the details which may be
provided on the screen of the phone during the subscription account sync-up process, in
accordance with an implementation of the present subject matter. The display 600-1 may be
provided with various balances of the subscription account before the subscription account syncup,
and the display 600-2 may be provided with the updated balances of the subscription account
after the subscription account sync-up, as described in the description herein. As illustrated, the
SMS units may be zero before the subscription account sync-up, and may be 100 units after the
subscription account sync-up, depending on the recharging of the SMS units by the user. It may
be noted that Figure 6 shows examples of displays 600-1 and 600-2 for illustrative purposes. The
details may be provided or displayed on a communication device of the user in other forms, in
real-time.
[0105] In an implementation, the sync-up module 218 may send the sync request
message automatically to the SARR system 104, or based on an input by the user for synching up
with the updated subscription account details. In an implementation, the sync-up module 218
may send the sync request message periodically, at a predefined time interval. The synching up
of the details on the phone through the SAMU system 102 and the SARR system 104 facilitates
the user to view all his balances, as and when modified, due to recharging of the account balance
and/or for the service units balance.
Balance Translation
[0106] Balance translation relates to translation or conversion of a part of one of the
balances of the subscription account to another balance, in real-time. The user may be able to
translate any of the balances, from the account balance and the service units balances, to increase
32
another balance. In an implementation, for the translation of a balance in the subscription
account on the phone, the sync-up module 218 may first send the sync request message to the
SARR system 104 and receive the sync response message from the SARR system 104 for
obtaining the updated details of the subscription account, including the updated account balance
and the updated service units balances, from the OCS 112, in accordance with the subscription
account sync-up process as described earlier. The user may be able to select one of the account
balance or any of the service units balances for the balance translation. After the sync-up
process, the balance translation module 220 sends a balance translation request message to the
SARR system 104 for translating a balance of the subscription account. The balance translation
module 220 receives an input from the user for a source balance which is to be translated,
generates the balance translation request message with the details of type of source balance, and
sends the balance translation request message to the SARR system 104. The user may select
either the account balance available in the subscription account or select one of the service units
balances, for example the voice call units balance, or the SMS units balance, or the data
download units balance, available in the subscription account, as the source balance for
translation. The balance translation request message, generated by the balance translation module
220, is encoded with information related to the details of the type of source balance selected by
the user for translation.
[0107] After the balance translation request message is sent the balance translation
module 220, the retrieving module 116 identifies the source balance details from the balance
translation request message, and sends the identified details to the OCS 112. In response to the
balance translation request message, the retrieving module 116 obtains, from the OCS 112,
details of one or more target balances to which the source balance, selected by the user, can be
translated. The target balances to which the source balance can be translated to include the
account balance and/or the service units balances. Along with the target balances, the retrieving
module 116 may also obtain, from the OCS 112, details of conversion ratios from the translation
of the source balance to the target balances. The obtained details are stored in the subscription
account data 230-2 of the SARR system 104.
[0108] After the details are obtained from the OCS 112, the reporting module 226
generates a balance translation response message, comprising the details of target balances and
33
the conversion ratios. The reporting module 226 sends the balance translation response message
to the SAMU system 102. The balance translation response message, generated by the reporting
module 226, is encoded with information related to the target balances and the conversion ratios.
[0109] After the balance translation response message is sent by the reporting module
226, the balance translation module 220 receives the balance translation response message, and
identifies the target balances and the conversion ratios from the balance translation response
message. The identified details are displayed on the phone to the user. Also, the identified details
are stored in the subscription account data 230-1 of the SAMU system 102.
[0110] Further, in response to the balance translation response message for the SARR
system 104, the balance translation module 220 receives inputs from the user for selection of a
destination balance from the target balances and a number of source balance units. The
destination balance is the balance to which the user may want to translate the selected number of
source balance. The user may select any of the target balances as the destination balance. The
user’s selection may depend on the conversion ratios. Based on the received inputs from the user,
the balance translation module 220 generates a balance translation commit request message with
details of the destination balance and the number of source balance units, and sends the balance
translation commit request message to the SARR system 104. The balance translation commit
request message is encoded with information related to the destination balance and the number of
source balance units.
[0111] After the balance translation commit request message is sent by the balance
translation module 220, the retrieving module 116 identifies the destination balance and number
of source balance details from the balance translation commit request message, and sends the
identified details to the OCS 112 for translation. Based on the received details, the OCS 112 may
perform one or more checks for whether the translation of the number of source balance units, as
selected by the user, to the destination balance is possible or not. For example, the OCS 112 may
check for whether the number selected by the user is possible for translation, and may check for
whether the translation between the source and the destination balances is possible or not. In case
the translation of balances is not possible, the OCS 112 sends an error message to the SARR
system 104, and the reporting module 226 sends the error message to the SAMU system 102.
The error message may be provided or displayed to the user on the phone.
34
[0112] Further, in case the translation of balances is possible, the OCS 112 alters the
source balance and the destination balance, as the case may be, in the subscription account of the
user. The retrieving module 116 then retrieves the altered balances, for the subscription account
of the user, from the OCS 112. The retrieved details are stored in the subscription account data
230-2 of the SARR system 104. Based on the retrieved details, the reporting module 226
generates a balance translation commit response message, comprising the altered balances, and
sends the balance translation commit response message to the SAMU system 102. The balance
translation commit response message, generated by the reporting module 226, is encoded with
information related to the balances that are altered in the subscription account.
[0113] After the balance translation commit response message is sent by the reporting
module 226, the balance translation module 220 receives the balance translation commit
response message, and identifies the altered balances from the balance translation commit
response message. The obtained details are stored in the subscription account data 230-1 of the
SAMU system 102. Subsequent to this, the balance translation module 220 displays the altered
balances, identified from the balance translation commit response message, on the phone. The
translation of the balances in the subscription account through the SAMU system 102 and the
SARR system 104 facilitates the user to selectively translate any of the available balances to
increase another balance, and view the altered balances, in real-time.
[0114] Figure 7 shows a plurality of displays 700-1, 300-2, 700-3, and 700-4 illustrating
the details which may be provided on the screen of the phone for the balance translation, in
accordance with an implementation of the present subject matter. The displays 700-1, 700-2,
700-3, and 700-4 hereinafter may be collectively referred to as the displays 700, and individually
referred to as the display 700. The display 700-1 may be provided with various balances,
retrieved from the OCS 112 by the sync-up process, for the selection of a source balance. The
user may select any of the balances as the source balance for translation. The display 700-2 may
be provided with one or more target balances and the corresponding conversion ratios, as
retrieved from the OCS 112, for the selection of a destination balance by the user. The user may
select any of the target balance as the destination balance. The display 700-3 may be provided
for entering the number of source balance units which the user may select for translation to the
destination balance. Subsequently, the display 700-4 may be provided after the translation of
35
balances as described earlier. It may be noted that Figure 7 shows examples of displays 700 for
illustrative purposes. The details may be provided or displayed on a communication device of the
user in other forms, in real-time.
[0115] In an implementation, the account balance and the service units balances,
obtained by the monitoring module 114 for the monitoring of the subscription account details, or
obtained by the charging unit selection module 214 for the selection of the charging unit, or
obtained by the sync-up module 218 based on the synching up with the updated subscription
account details, or obtained by the balance translation module 220 based on the translation of
balances in the subscription account, may be stored in the subscription account data 230-1 of the
SAMU system 102 and displayed on the phone in the form of graphical icons with the values of
the respective balances. Further, in an implementation, in case the user recharges for a new
service units, for example, for SMS units, data downloading units, talktime units, and such, a
new graphical icon may be generated to display the new service units and the corresponding
balance value.
[0116] Although as described in description herein, the SAMU system 102 and the
SARR system 104 may send and receive various messages, including request messages and
response messages, over the communication network 110; it may be understood that the
messages are send and received via one or more communication network entities. For example,
in the case of GSM/IP based network, the SAMU system 102 and the SARR system 104 may
communicate via Gateway GPRS Support Node (GGSN) / Serving GPRS Support Node (SGSN)
of the network, as understood to a person skilled in the art.
[0117] In an implementation, the various messages, including request messages and
response messages, which are sent and received by the SAMU system 102 and/or the SARR
system 104 may be configured or coded based on the type of communication network, based on
the communication network entities of the communication network, and based on the interfaces
through which the communication network entities may communicate for send and receiving
messages to and from the SAMU system 102 and the SARR system 104.
[0118] In an implementation, for the GSM/IP based network, the GGSN/SGSN may
communicate with an SCP, the SAMU system 102, and the SARR system 104 over diameter
interfaces. For said implementation, the various messages, including request messages and
36
response messages, which are communicated between the SAMU system 102 and the SARR
system 104 are in the form of diameter messages. A diameter message includes a plurality of
information fields comprising identification fields and attribute-value pair (AVP) fields. The
identification fields may have information required for various identifications of the diameter
message, and the AVP fields may have data associated with the diameter message, which are
encoded based on the type of diameter message and the function to be performed by the diameter
message. In an implementation, each of the identification fields and each of the AVP fields are of
a predefined length, for example, 32-bits, and encoded in binary format. For the sake of
simplicity, only those identification fields and the AVP fields that may be encoded for the
purposes of the present subject matter are described herein. Other fields may be configured and
encoded as understood to a person skilled in the art.
[0119] In an implementation, one of the identification fields in the diameter message may
include a command flags field which is encoded based on the type of diameter message. The
command flags fields may be of 8-bits. The command flags field may include a request bit (R).
The request bit (R) may be set to 1 if the diameter message is a request, and set to 0 if the
diameter message is a response message.
[0120] Further, in an implementation, each of the AVP fields in the diameter message
may be associated with a category flags field which is encoded based on the type of AVP field.
The category flags field may be of 8-bits. The category flags field may include a mandatory bit
(M). The mandatory bit (M) may be set to 1 to indicate the necessity of support of the AVP field,
in the diameter message, by the receiving system or the receiving node. If a diameter message
having the mandatory bit (M) as 1 is received by a system or a node, and if the AVP field is not
supported by the system or the node, the diameter message may be rejected.
[0121] The description below describes call flows for communications between the
SAMU system 102 and the SARR system 104 for each of the functions, including the
subscription account monitoring, the charging unit selection, the rate plan selection, the
subscription account sync-up, and the balance translation, in accordance with an implementation
of the present subject matter. Along with the call flows, the description also describes details of
various request messages and response messages, each as a diameter message encoded with
37
information depending on the type of function to be performed, in accordance with an
implementation of the present subject matter.
[0122] Figure 8 illustrates a call flow diagram 800 for communications between the
SAMU system 102 and the SARR system 104 for monitoring details of subscription account, in
accordance with an embodiment of the present subject matter. Various arrow indicators used in
the call flow diagram 800 depict transfer of data between the SAMU system 102, a Charging
Triggering Module (CTM), the SARR system 104, and the OCS 112. The CTM may be an
originating Service Switch Point (SSP) that may communicate with the OCS 112 during an ongoing
call for various purposes including indication of a time slot granted for the on-going call,
and updating the OCS 112 with the lapsed time for the call for reducing the account balance or
the service units balance in real-time during the call. The call flow diagram 800 shows various
steps pertaining to the steps required for the purpose of monitoring of subscription account
during the on-going call; however steps for various other communications, as conventionally
known in the art, between the SAMU system 102, the CTM, the OCS 112, the SARR system 104
and/or other network entities may also be part of the call flow diagram 800.
[0123] In the call flow diagram 800, at step 800-1, the CTM sends a message to the OCS
112 to indicate the beginning of a call initiated by the user. The user may initiate the call on a
communication device implemented with the SAMU system 102. As the call is initiated by the
user, the SAMU system 102 sends an account retrieval request message to the SARR system
104, at step 800-2, for obtaining at least one subscription account detail as described earlier.
Upon receiving the account retrieval request message from the SAMU system 102, the SARR
system 104 sends a request to the OCS 112, at step 800-3, for retrieving the at least one
subscription account detail from the OCS 112. Based on the request from the SARR system 104,
the OCS 112 sends a response with the at least one subscription account detail to the SARR
system 104 at step 800-4. Upon receiving the details from the OCS 112, the SARR system 104
sends an account retrieval response message, encoded with the obtained details, to the SAMU
system 102 at step 800-5. The account retrieval response message may be encoded with the
account balance and/or one or more service units balances retrieved from the OCS 112 during
the call. The account retrieval response message may also be encoded with other subscription
account details including a validity term, a rate plan for an on-going call, a charging rate for an
38
on-going call, on-going service, on-going type of call, and roaming status, retrieved from the
OCS 112 during the call. The account retrieval response message may be sent by the SARR
system 104 to the SAMU system 102, in response to the account retrieval request message
initially at the time the call is initiated by the user. The SAMU system 102, upon receiving the
account retrieval response message identifies the details encoded therein, and provides the details
on the communication device of the user, in real-time.
[0124] Subsequent to this, as the call is in progress, other communications between the
CTM and the OCS 112, for the purposes of indication of a time slot granted for the on-going call,
and updating the OCS 112 with the lapsed time for the call for reducing the account balance or
the service units balance in real-time during the call, may take place in a conventionally known
manner (not shown).
[0125] Further, after a predefined time interval, as the call is in progress and the account
balance or the service units balance which may be deducted at the OCS 112 based on the lapsed
time for the call, the OCS 112 sends the updated account balance and/or the updated service
units balance to the SARR system 104 at step 800-6. At step 800-7, upon receiving the updated
details from the OCS 112 after the predefined time interval during the call, the SARR system
104 sends another account retrieval response message, encoded with the updated details, to the
SAMU system 102. The SAMU system 102, upon receiving the account retrieval response
message identifies the updated details encoded therein, and provides the updated details on the
communication device of the user, in real-time, during the call.
[0126] Subsequent to this, the call may continue, and, as the call is in progress,
communications between the CTM and the OCS 112, for the purposes of indication of a time slot
granted for the on-going call, and updating the OCS 112 with the lapsed time for the call for
reducing the account balance or the service units balance in real-time during the call, may take
place in a conventionally known manner (not shown), as described above.
[0127] Further, again after the predefined time interval, as the call is in progress and the
account balance or the service units balance which may be deducted at the OCS 112 based on the
lapsed time for the call, the OCS 112 sends the updated account balance and/or the updated
service units balance to the SARR system 104 at step 800-8. At step 800-9, upon receiving the
updated details from the OCS 112 after the predefined time interval during the call, the SARR
39
system 104 sends another account retrieval response message, encoded with the updated details,
to the SAMU system 102. The SAMU system 102, upon receiving the account retrieval response
message identifies the updated details encoded therein, and provides the updated details on the
communication device of the user, in real-time, during the call. The call may continue and the
communication between the SAMU system 102, the CTM, the OCS 112 and the SARR system
104 may continue to take place, and the account balance and/or the service units balance details
may be obtained by the SARR system 104 and sent to the SAMU system 102, in real-time,
during the call, as described above.
[0128] As the call is terminated by the user, at step 800-10, the CTM sends a message to
the OCS 112 for indicating the disconnection of the call. At step 800-11, the OCS 112 sends a
message to the CTM for acknowledging the end of the call.
[0129] As mentioned earlier, for the monitoring of subscription account details, the
account retrieval request message is generated in the SAMU system 102 for obtaining the
subscription account details in real-time during an on-going call, and the account retrieval
response message is generated in the SARR system 104 in response to the account retrieval
request message. In an implementation, the account retrieval request message may be generated
as a diameter message with the request bit (R) set to 1, and the account retrieval response
message may be generated as a diameter message with the request bit (R) set to 0.
TABLE 1
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Origin-Realm 1
Code for identifying the realm of the
GGSN
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for account retrieval request
Request Number 1 Value of the request number
Subscription ID Type 1 Code for IMSI number
Subscription ID Data 1 Value of IMSI number
40
TABLE 2
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for account retrieval request
Request Number 1 Value of the request number
Result Code 1
Code for indicating an error or a
successful completion of the request
Service Units Type 1 Code for indicating the account balance
Service Units Data 1 Value of account balance
Service Units Type 1
Code for indicating the type of service
units balance
Service Units Data 1 Value of the service units balance
…. 1 …..
….. 1 …..
[0130] Table 1 lists details of various AVP fields that may be encoded in the account
retrieval request message, and Table 2 lists details of various AVP fields that may be encoded in
the account retrieval response message. The account retrieval request message, amongst other
AVP fields, comprises a request type field which may be encoded with a code for requesting for
retrieval of at least one detail of the subscription account. The account retrieval response
message, amongst other AVP fields, comprises a result code field which may be encoded with a
code to indicate whether the account retrieval request message is completed successfully or not.
If the account retrieval request message is unsuccessful, the result code field may be coded with
a code to indicate an error. Further the account retrieval response message may include one or
more service units type fields and corresponding service units data fields. The account retrieval
response message may have a service units type field for the account balance and may have one
or more further service units type fields for the available service units balances in the
subscription account of the user. Although, in Table 1, the account retrieval response message is
shown to include the account balance and the service units balance; however, in an
41
implementation, the account retrieval response message may include AVP fields related to other
details of the subscription account, such as the validity term, the active rate plan for the user, the
active charging rates based on the rate plan, on-going active service session details (data call or
voice call), the type of on-going call (SMS, email, audio call, web-access, etc.), roaming details,
and such.
[0131] Figure 9 illustrates a call flow diagram 900 for communication between the
SAMU system 102 and the SARR system 104 for charging unit selection, in accordance with an
embodiment of the present subject matter. Various arrow indicators used in the call flow diagram
900 depict transfer of data between the SAMU system 102, the CTM, the SARR system 104 and
the OCS 112. The call flow diagram 900 shows various steps pertaining to the steps required for
the purpose of charging unit selection; however steps for various other communications, as
conventionally known in the art, between the SAMU system 102, the CTM, the OCS 112, the
SARR system 104 and/or other network entities may also be part of the call flow diagram 900.
[0132] In the call flow diagram 900, at step 900-1, the CTM sends a message to the OCS
112 to indicate for the beginning of a call initiated by the user. The user may initiate the call on a
communication device implemented with the SAMU system 102. As the call is initiated by the
user, the SAMU system 102 sends a call-type indication request message to the SARR system
104, at step 900-2, for obtaining call-specific subscription account details, including the account
balance and the service units balances available depending upon the type of call initiated by the
user. Upon receiving the call-type indication request message from the SAMU system 102, the
SARR system 104 sends a request to the OCS 112, at step 900-3, for retrieving the call-specific
subscription account details from the OCS 112. Based on the request from the SARR system
104, the OCS 112 sends a response with the call-specific subscription account details to the
SARR system 104 at step 900-4. Upon receiving the details from the OCS 112, the SARR
system 104 sends a charging unit selection request message, encoded with the obtained details
and encoded with a request for selection of a charging unit for the call, to the SAMU system 102
at step 900-5. The charging unit selection request message may be sent by the SARR system 104
to the SAMU system 102, in response to the call-type indication request message, at the time the
call is initiated by the user.
42
[0133] The SAMU system 102, upon receiving the charging unit selection request
message, identifies the details encoded therein, and provides the details on the communication
device of the user, in real-time. Based on the details, the SAMU system 102 receives an input
from the user for selection of the active charging unit, which may be one from the account
balance and the service units balances available for the type of call initiated by the user.
[0134] At block 900-6, the SAMU system 102 sends a charging unit selection response
message, comprising the details of the active charging unit selected by the user for the call, to the
SARR system 104. Upon receiving the charging unit selection response message, the SARR
system 104 identifies the details of the active charging unit, and sends the details of the active
charging unit to the OCS 112, at block 900-7, based on which the OCS 112 charges the
subscription account for the call. Subsequent to this, the call may begin, and communications
between the CTM and the OCS 112 during the call, may take place in a conventionally known
manner (not shown) till the call is terminated by the user.
[0135] Further, as mentioned earlier, for the selection of a charging unit by the user, the
call-type indication request message is generated in the SAMU system 102 for obtaining the callspecific
subscription account details. The charging unit selection request message is generated by
the SARR system 104 in response to the call-type indication request message. The charging unit
selection response message is generated by the SAMU system 102 in response to the charging
unit selection request message. In an implementation, the call-type indication request message
and the charging unit selection request message may be generated as diameter messages with the
request bit (R) set to 1, and the charging unit selection response message may be generated as a
diameter message with the request bit (R) set to 0.
TABLE 3
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Origin-Realm 1
Code for identifying the realm of the
GGSN
Destination-Realm 1
Code for identifying the realm of the
destination node
43
Request-Type 1
Code for call-specific subscription
account details request
Request Number 1 Value of the request number
Call Type ID 1
Code for indicating the type of call
initiated by the user
Subscription ID Type 1 Code for IMSI number
Subscription ID Data 1 Value of IMSI number
[0136] Table 3 lists details of various AVP fields that may be encoded in the call-type
indication request message for the selection of a charging unit. The call-type indication request
message, amongst other AVP fields, comprises a call type ID field which may be encoded with a
code to identify the type of call initiated by the user, and comprises a request type field which
may be encoded with a code for requesting balance details in the subscription account related to
the type of call initiated by the user.
[0137] Table 4 lists details of various AVP fields that may be encoded in the charging
unit selection request message, and Table 5 lists details of various AVP fields that may be
encoded in the charging unit selection response message. The charging unit selection request
message, amongst other AVP fields, comprises a request type field which may be encoded with a
code for requesting the charging unit (active charging unit) which may be selected for the call by
the user. Further, the charging unit selection request message may include one or more service
units type fields and corresponding service units data fields that may be retrieved by the SARR
system 104 based on the type of call initiated by the user. The charging unit selection request
message may have a service units type field for the account balance and may have one or more
further service units type fields for the available service units balances in the subscription
account of the user. The charging unit selection response message, amongst other AVP fields,
comprises a result code field which may be encoded with a code to indicate whether the charging
unit selection request message is completed successfully or not. If the charging unit selection
request message is unsuccessful, the result code field may be coded with a code to indicate an
error. Further the charging unit selection response message may include an active charging unit
type field which may be encoded with a code to indicate the active charging unit based on which
the subscription account of the user be charged for the call.
TABLE 4
44
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for charging unit selection request
Request Number 1 Value of the request number
Service Units Type 1 Code for indicating the account balance
Service Units Data 1 Value of account balance
Service Units Type 1
Code for indicating the type of service
units balance
Service Units Data 1 Value of the service units balance
…. 1 …..
….. 1 …..
TABLE 5
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for charging unit selection request
Request Number 1 Value of the request number
Result Code 1
Code for indicating an error or a
successful completion of the request
Active Charging Unit
Type
1
Code for indicating the active charging
unit based on which the subscription
account be charged for the call
[0138] Figure 10 illustrates a call flow diagram 1000 for communication between the
SAMU system 102 and the SARR system 104 for rate plan selection, in accordance with an
embodiment of the present subject matter. Various arrow indicators used in the call flow diagram
1000 depict transfer of data between the SAMU system 102, the CTM, the SARR system 104
45
and the OCS 112. The call flow diagram 1000 shows various steps pertaining to the steps
required for the purpose of rate plan selection; however steps for various other communications,
as conventionally known in the art, between the SAMU system 102, the CTM, the OCS 112, the
SARR system 104 and/or other network entities may also be part of the call flow diagram 1000.
[0139] In the call flow diagram 1000, at step 1000-1, the CTM sends a message to the
OCS 112 to indicate for the beginning of a call initiated by the user. The user may initiate the
call on a communication device implemented with the SAMU system 102. As the call is initiated
by the user, the SAMU system 102 sends a call-type indication request message to the SARR
system 104, at step 1000-2, for obtaining rate plan subscription account details, including
multiple rate plans that are provided by the service provider to the user. The rate plans may
depend upon the type of call initiated by the user. Upon receiving the call-type indication request
message from the SAMU system 102, the SARR system 104 sends a request to the OCS 112, at
step 1000-3, for retrieving the rate plan subscription account details from the OCS 112. Based on
the request from the SARR system 104, the OCS 112 sends a response with the rate plan
subscription account details to the SARR system 104 at step 1000-4. Upon receiving the details
from the OCS 112, the SARR system 104 sends a rate plan selection request message, encoded
with the obtained details and encoded with a request for selection of a rate plan for the call, to the
SAMU system 102 at step 1000-5. The rate plan selection request message may be sent by the
SARR system 104 to the SAMU system 102, in response to the call-type indication request
message, at the time the call is initiated by the user.
[0140] The SAMU system 102, upon receiving the charging unit selection request
message, identifies the details encoded therein, and provides the details on the communication
device of the user, in real-time. Based on the details, the SAMU system 102 receives an input
from the user for selection of the active rate plan, which may be one from the multiple rate plans
available for the type of call initiated by the user.
[0141] At block 1000-6, the SAMU system 102 sends a rate plan selection response
message, comprising the details of the active rate plan selected by the user for the call, to the
SARR system 104. Upon receiving the rate plan selection response message, the SARR system
104 identifies the details of the active rate plan, and sends the details of the active rate plan to the
OCS 112, at block 1000-7, based on which the OCS 112 charges the subscription account for the
46
call. Subsequent to this, the call may begin, and communications between the CTM and the OCS
112 during the call, may take place in a conventionally known manner (not shown) till the call is
terminated by the user.
[0142] Further, as mentioned earlier, for the selection of a rate plan by the user, the calltype
indication request message is generated in the SAMU system 102 for obtaining the rate plan
subscription account details. The rate plan selection request message is generated by the SARR
system 104 in response to the call-type indication request message. The rate plan selection
response message is generated by the SAMU system 102 in response to the rate plan selection
request message. In an implementation, the call-type indication request message and the rate plan
selection request message may be generated as diameter messages with the request bit (R) set to
1, and the rate plan selection response message may be generated as a diameter message with the
request bit (R) set to 0.
TABLE 6
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Origin-Realm 1
Code for identifying the realm of the
GGSN
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1
Code for rate plan subscription account
details request
Request Number 1 Value of the request number
Call Type ID 1
Code for indicating the type of call
initiated by the user
Subscription ID Type 1 Code for IMSI number
Subscription ID Data 1 Value of IMSI number
[0143] Table 6 lists details of various AVP fields that may be encoded in the call-type
indication request message for the selection of a rate plan. This call-type indication request
message, amongst other AVP fields, comprises a call type ID field which may be encoded with a
code to identify the type of call initiated by the user, and comprises a request type field which
47
may be encoded with a code for requesting details of multiple rate plans available for the
subscription account and related to the type of call initiated by the user.
[0144] Table 7 lists details of various AVP fields that may be encoded in the rate plan
selection request message, and Table 8 lists details of various AVP fields that may be encoded in
the rate plan selection response message. The rate plan selection request message, amongst other
AVP fields, comprises a request type field which may be encoded with a code for requesting the
rate plan (active rate plan) which may be selected for the call by the user. Further, the rate plan
selection request message may include one or more rate plan type fields, each based on a rate
plan from the multiple rate plans provided to the user based on the type of call initiated by the
user. The rate plan selection response message, amongst other AVP fields, comprises a result
code field which may be encoded with a code to indicate whether the rate plan selection request
message is completed successfully or not. If the rate plan selection request message is
unsuccessful, the result code field may be coded with a code to indicate an error. Further the rate
plan selection response message may include an active rate plan type field which may be
encoded with a code to indicate the active rate plan based on which the subscription account of
the user be charged for the call.
TABLE 7
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for rate plan selection request
Request Number 1 Value of the request number
Rate Plan Type 1 Code for indicating a rate plan
Rate Plan Type 1 Code for indicating a rate plan
…. 1 …..
TABLE 8
AVP Field Name
Mandatory Bit
Status
Value
48
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for rate plan selection request
Request Number 1 Value of the request number
Result Code 1
Code for indicating an error or a
successful completion of the request
Active Rate Plan Type 1
Code for indicating the active rate plan
based on which the subscription account
be charged for the call
[0145] Figure 11 illustrates a call flow diagram 1100 for communication between the
SAMU system 102 and the SARR system 104 for synching up with subscription account, in
accordance with an embodiment of the present subject matter. Various arrow indicators used in
the call flow diagram 1100 depict transfer of data between the SAMU system 102, the SARR
system 104, and the OCS 112. The call flow diagram 1100 shows various steps pertaining to the
steps required for the purpose of sync-up; however steps for various other communications, as
conventionally known in the art, between the SAMU system 102, the OCS 112, the SARR
system 104 and/or other network entities may also be part of the call flow diagram 1100.
[0146] In the call flow diagram 1100, at step 1100-1, the SAMU system 102 sends a sync
request message to the SARR system 104 for obtaining updated details of the subscription
account. The updated details of the subscription account may be based on recharging of the
account balance, and/or one or more service units balances, by the user. Upon receiving the sync
request message from the SAMU system 102, the SARR system 104 sends a request to the OCS
112, at step 1100-2, for retrieving the updated account balance and/or the updated service units
balances for the subscription account from the OCS 112. Based on the request from the SARR
system 104, the OCS 112 sends a response with the updated details to the SARR system 104 at
step 1100-3. Upon receiving the details from the OCS 112, the SARR system 104 sends a sync
response message, encoded with the obtained updated details, to the SAMU system 102 at step
1100-4.
49
[0147] The SAMU system 102, upon receiving the sync response message, identifies the
updated account balance and/or the updated service units balance encoded therein, and syncs up
the details on the communication device with the updated details, in real-time. The updated
account balance and/or the updated service units balances, after the sync up, are displayed on the
communication to the user.
[0148] Further, as mentioned earlier, for the synching up of details of the subscription
account on the phone with updated details of the subscription account, the sync request message
is generated in the SAMU system 102 for obtaining the updated subscription account details, and
the sync response message is generated in the SARR system 104 in response to the sync request
message. In an implementation, the sync request message may be generated as a diameter
message with the request bit (R) set to 1, and the sync response message may be generated as a
diameter message with the request bit (R) set to 0.
[0149] Table 9 lists details of various AVP fields that may be encoded in the sync request
message, and Table 10 lists details of various AVP fields that may be encoded in the sync
response message. The sync request message, amongst other AVP fields, comprises a request
type field which may be encoded with a code for requesting for updated details of the
subscription account. The sync response message, amongst other AVP fields, comprises a result
code field which may be encoded with a code to indicate whether the sync request message is
completed successfully or not. If the sync request message is unsuccessful, the result code field
may be coded with a code to indicate an error. Further the sync response message may include
one or more service units type fields and corresponding service units data fields. The sync
response message may have a service units type field for the updated account balance and may
have one or more further service units type fields for the updated service units balances in the
subscription account of the user.
TABLE 9
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Origin-Realm 1
Code for identifying the realm of the
GGSN
50
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for sync request
Request Number 1 Value of the request number
Subscription ID Type 1 Code for IMSI number
Subscription ID Data 1 Value of IMSI number
TABLE 10
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code of corresponding to the session ID
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for sync request
Request Number 1 Value of the request number
Result Code 1
Code for indicating an error or a
successful completion of the request
Service Units Type 1
Code for indicating the updated account
balance
Service Units Data 1 Value of updated account balance
Service Units Type 1
Code for indicating the type of updated
service units balance
Service Units Data 1
Value of the updated service units
balance
…. 1 …..
….. 1 …..
[0150] Figure 12 illustrates a call flow diagram 1200 for communication between the
SAMU system 102 and the SARR system 104 for translation of a balance, in accordance with an
embodiment of the present subject matter. Various arrow indicators used in the call flow diagram
1200 depict transfer of data between the SAMU system 102, the SARR system 104, and the OCS
112. The call flow diagram 1200 shows various steps pertaining to the steps required for the
purpose of the translation of a balance by the user; however steps for various other
communications, as conventionally known in the art, between the SAMU system 102, the OCS
51
112, the SARR system 104 and/or other network entities may also be part of the call flow
diagram 1200.
[0151] In the call flow diagram 1200, at step 1200-1, the SAMU system 102 sends a sync
request message to the SARR system 104 for obtaining updated details of the subscription
account, and, at step 1200-2, the SARR system 104 sends the sync response message with the
updated details to the SAMU system 102, as described in the call flow diagram 1100. After the
sync-up process, the SAMU system 102 sends, at step 1200-3, a balance translation request
message to the SARR system 104 for the translation of a source balance selected by the user. The
details of the source balance, selected by the user, are encoded in the balance translation request
message. Upon receiving the balance translation request message, the SARR system 104
identifies the details of the source balance and sends a request, at step 1200-4, to the OCS 112
for obtaining target balances and conversion ratios based on the identified source balance. Based
on the request, the OCS 112 sends a response to the SARR system 104, at step 1200-5, where the
response includes details of target balances to which the user may translate the source balance,
and includes conversion ratios corresponding to the translation of the source balance to the target
balances.
[0152] After obtaining the details of the target balances and the conversion ratios, the
SARR system 104 sends a balance translation response message with the obtained details to the
SAMU system 102 at step 1200-6. The SAMU system 102 identifies the details of the target
balances and the conversion ratios from the balance translation response message, and displays
the identified details on the communication device, based on which the user may translate the
source balance. Further, the SAMU system 102 receives inputs from the user for selection of a
destination balance to which the source balance is to be translated, and for a number of source
balance units that are to be converted to the destination balance.
[0153] Based on the inputs received from the user, the SAMU system 102 generates and
sends a balance translation commit request message with the details of the destination balance
and the number of source balance units to the SARR system 104 at step 1200-7. Upon receiving
this message, the SARR system 104 identifies the details of the destination balance and the
number of source balance units, and sends a request to the OCS 112, at step 1200-8, for
translation of the number of source balance units to the destination balance. Based on the
52
received request, the OCS 112 performs a check, as described earlier, and alters the source
balance and the destination balance in the subscription account of the user. Based on the
alterations, the OCS 112 sends a response with the altered balances to the SARR system 104 at
step 1200-9. The SARR system 104 then generates a balance translation commit response
message with the altered balances, and sends the balance translation commit response message to
the SAMU system 102 at step 1200-10. Upon receiving the balance translation commit response
message, the SAMU system 102 identifies the details of the altered balances from the balance
translation commit response message and provides the identified details on the communication
for the user.
[0154] Further, as mentioned earlier, for the translation of a balance of the subscription
account, the balance translation request message is generated in the SAMU system 102. The
balance translation response message is generated in the SARR system 104 in response to the
balance translation request message. The balance translation commit request message is
generated by the SAMU system 102 in response to the balance translation response message.
The balance translation commit response message is generated by the SARR system 104 in
response to the balance translation commit request message. In an implementation, the balance
translation request message and the balance translation commit request message may be
generated as diameter messages with the request bit (R) set to 1, and the balance translation
response message and the balance translation commit response message may be generated as
diameter messages with the request bit (R) set to 0.
[0155] Table 11 lists details of various AVP fields that may be encoded in the balance
translation request message, and Table 12 lists details of various AVP fields that may be encoded
in the balance translation response message. The balance translation request message, amongst
other AVP fields, comprises a request type field which may be encoded with a code for
requesting for translation of a balance of the subscription account, and comprises a source
balance type field which may be encoded with a code for the source balance which the user may
translate. The balance translation response message, amongst other AVP fields, comprises a
result code field which may be encoded with a code to indicate whether the balance translation
request message is completed successfully or not. If the balance translation request message is
unsuccessful, the result code field may be coded with a code to indicate an error. Further the
53
balance translation response message may include one or more target balance type fields and
corresponding conversion ratios data fields, based on which the user may translate a number of
source balance units.
TABLE 11
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Origin-Realm 1
Code for identifying the realm of the
GGSN
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for balance translation request
Request Number 1 Value of the request number
Source Balance Type 1
Code for indicating the type of source
balance selected by the user for
translation
TABLE 12
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code of corresponding to the session ID
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1 Code for balance translation request
Request Number 1 Value of the request number
Result Code 1
Code for indicating an error or a
successful completion of the request
Target Balance Type 1
Code for indicating the type of target
balance
Conversion Ratio Data 1
Value of conversion ratio for the target
balance with respect to the source
balance
Target Balance Type 1
Code for indicating the type of target
balance
54
Conversion Ratio Data 1
Value of conversion ratio for the target
balance with respect to the source
balance
…. 1 …..
….. 1 …..
[0156] Table 13 lists details of various AVP fields that may be encoded in the balance
translation commit request message, and Table 14 lists details of various AVP fields that may be
encoded in the balance translation commit response message. The balance translation commit
request message, amongst other AVP fields, comprises a request type field which may be
encoded with a code for requesting for translation of the source balance to a destination balance.
The balance translation commit request message also comprises a destination balance type field
which may be encoded with a code for the destination balance to which the user may translate
the source balance, and comprise a source balance units data field which may be encoded with a
code for the number of source balance units that are selected for translation to the destination
balance. The balance translation commit response message, amongst other AVP fields,
comprises a result code field which may be encoded with a code to indicate whether the balance
translation commit request message is completed successfully or not. If the balance translation
commit request message is unsuccessful, the result code field may be coded with a code to
indicate an error. The error in the result code field of the balance translation commit response
message may be encoded if the number of source balance units selected for translation is
insufficient, or if the number of destination balance units, upon translation, is more than a
predefined limit. Further, the balance translation commit response message may include a source
balance type field and the corresponding source balance units data fields based on the translation,
and may also include a destination balance type field and the corresponding destination balance
units data based on the translation from the source balance units.
TABLE 13
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code for identifying the active session
Origin-Host 1
Code for identifying GGSN from which
the request message is received
55
Origin-Realm 1
Code for identifying the realm of the
GGSN
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1
Code for balance translation commit
request
Request Number 1 Value of the request number
Destination Balance
Type
1
Code for indicating the type of
destination balance selected by the user
for translation
Source Balance Units
Data
1
Value of number of source balance units
selected for translation to the destination
balance
TABLE 14
AVP Field Name
Mandatory Bit
Status
Value
Session ID 1 Code of corresponding to the session ID
Origin-Host 1
Code for identifying GGSN from which
the request message is received
Destination-Realm 1
Code for identifying the realm of the
destination node
Request-Type 1
Code for balance translation commit
request
Request Number 1 Value of the request number
Result Code 1
Code for indicating an error or a
successful completion of the request
Source Balance Type 1
Code for indicating the type of source
balance
Source Balance Units
Data
1
Value indicating the number of source
balance units based on the translation
Destination Balance
Type
1
Code for indicating the type of
destination balance
Destination Balance
Units Data
1
Value indicating the number of
destination balance units based on the
translation
[0157] Figure 13 illustrates a method 1300 for management of a subscription account, in
accordance with an embodiment of the present subject matter. The method 1300 is directed to
56
describe the monitoring of at least one subscription account detail, including the account balance
and/or the service units balance, during an on-going call.
[0158] The order in which the method 1300 is described is not intended to be construed
as a limitation, and any number of the described method blocks can be combined in any order to
implement the method 1300, or an alternative method. Additionally, individual blocks may be
deleted from the method 1300 without departing from the spirit and scope of the subject matter
described herein. Furthermore, the methods can be implemented in any suitable hardware,
software, firmware, or combination thereof.
[0159] A person skilled in the art will readily recognize that steps of the method 1300
can be performed by programmed computers. Herein, some embodiments are also intended to
cover program storage devices, for example, digital data storage media, which are machine or
computer readable and encode machine-executable or computer-executable programs of
instructions, wherein said instructions perform some or all of the steps of the described method.
The program storage devices may be, for example, digital memories, magnetic storage media
such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data
storage media. The embodiments are also intended to cover both communication network and
communication devices configured to perform said steps of the exemplary method.
[0160] Referring to Figure 13, although the method 1300 for management of a
subscription account may be implemented in a variety of communication devices working in
different network environments, in an embodiment described in Figure 13, the method 1300 is
explained in context of the aforementioned SAMU system 102 and the SARR system 104 for the
ease of explanation.
[0161] In an implementation, at block 1302, an account retrieval request message is sent
by the SAMU system 102 to the SARR system 104 for obtaining at least one subscription
account detail, from a communication network entity, such as the OCS 112, during an on-going
call. The account retrieval request message may be in the form of a diameter message encoded
with a code for account retrieval request, as described earlier. The account retrieval request
message is received by the SARR system 104 which, upon identifying the code for account
retrieval request in the account retrieval request message, retrieves the account balance and/or
the service units balance from the OCS 112. Based on the obtained details, the SARR system 104
57
generates an account retrieval response message, encoded with the obtained details, and sends
the account retrieval response message to the SAMU system 102. The account retrieval response
message may be in the form of a diameter message encoded with the details of account balance
and service units balance, and other details of the subscription account, as described earlier.
[0162] At block 1304, the account retrieval response message, comprising the at least one
subscription account detail, is received by the SAMU system 102 from the SARR system 104, in
response to the account retrieval request message, during the on-going call. The at least one
subscription account detail includes the account balance and/or the service units balance. The
account retrieval response message is obtained at a predefined time interval, during the on-going
call. As it may be understood that the account balance and/ one of the service units balance may
get reduced during the on-going call, depending upon the usage, each account retrieval response
message, sent after a predefined time interval, comprises the updated account balance and/or the
updated service units balance. In an implementation, as mentioned earlier, further details,
including the validity term, the active rate plan for the user, the active charging rates based on
the rate plan, on-going active service session details (data call or voice call), the type of on-going
call (SMS, email, audio call, web-access, etc.), roaming details, may be encoded in the account
retrieval response message sent by the SARR system 104 to the SAMU system 102.
[0163] After receiving the account retrieval response message, the at least one
subscription account detail, received in the account retrieval response message, is displayed on
the communication device, in real-time, during the on-going call, at block 1306. The updated
details in the account retrieval response message, as received periodically, at the predefined time
interval, are displayed on the communication device during the on-going call.
[0164] Further, in an implementation, the account balance and/or the service units
balance, which are received in the account retrieval response message, are compared with a
predefined limit value, and, based on the comparison, an alert signal may be generated on the
communication for alerting the user against exhaustion of the account balance and/or the service
units balance, during the on-going call.
[0165] Figures 14, 15, 16, and 17 illustrate methods 1400, 1500, 1600, and 1700 for
management of a subscription account, in accordance with an embodiment of the present subject
matter. The method 1400 is directed to describe the updating of the subscription account with a
58
charging unit selected for a call, in accordance with the description herein. The method 1500 is
directed to describe the updating of the subscription account with a rate plan selected for a call,
in accordance with the description herein. The method 1600 is directed to describe the synching
of details of subscription account on the communication device with the details on the OCS 112,
in accordance with the description herein. The method 1700 is directed to describe the translation
of a balance in the subscription account, in accordance with the description herein. In an
implementation, any of the methods 1400 and 1500 may be performed along with the method
1300 for a call by the user. Further, in an implementation, any of the methods 1600 and 1700
may be performed, based on a selection by the user, before or after the methods 1300, 1400, and
1500.
[0166] The order in which the methods 1400, 1500, 1600, and 1700 are described is not
intended to be construed as a limitation, and any number of the described method blocks can be
combined in any order to implement the methods 1400, 1500, 1600, and 1700, or an alternative
method. Additionally, individual blocks may be deleted from the methods 1400, 1500, 1600, and
1700 without departing from the spirit and scope of the subject matter described herein.
Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or
combination thereof.
[0167] A person skilled in the art will readily recognize that steps of the methods 1400,
1500, 1600, and 1700 can be performed by programmed computers. Herein, some embodiments
are also intended to cover program storage devices, for example, digital data storage media,
which are machine or computer readable and encode machine-executable or computerexecutable
programs of instructions, wherein said instructions perform some or all of the steps of
the described method. The program storage devices may be, for example, digital memories,
magnetic storage media, such as a magnetic disks and magnetic tapes, hard drives, or optically
readable digital data storage media. The embodiments are also intended to cover both
communication network and communication devices configured to perform said steps of the
exemplary method.
[0168] Referring to Figure 14, although the method 1400 for management of a
subscription account may be implemented in a variety of communication devices working in
different network environments, in an embodiment described in Figure 14, the method 1400 is
59
explained in context of the aforementioned SAMU system 102 and the SARR system 104 for the
ease of explanation.
[0169] At block 1402, a call-type indication request message is sent by the SAMU
system 102 to the SARR system 104 for obtaining call-specific subscription account details,
from a communication network entity, such as the OCS 112. The call-type indication request
message may be in the form of a diameter message encoded with a code for call-specific
subscription account details request and a code for indicating the type of call initiated by the
user, as described earlier. The call-type indication request message is received by the SARR
system 104 which, upon identifying the codes for the call-specific subscription account details
request and for the type of call in the call-type indication request message, retrieves the account
balance and/or the service units balance from the OCS 112, based on the type of call initiated by
the user, which may be selected by the user for the call. Based on the obtained details, the SARR
system 104 generates a charging unit selection request message, encoded with the obtained
details and details for charging unit selection request, and sends the charging unit selection
request message to the SAMU system 102. The charging unit selection request message may be
in the form of a diameter message encoded with the details of account balance and/or service
units balance and encoded with a code for charging unit selection request, as described earlier.
[0170] At block 1404, the charging unit selection request message is received by the
SAMU system 102 from the SARR system 104, in response to the call-type indication request
message, for selection of an active charging unit for the call initiated by the user. The charging
unit selection request message is received by the SAMU system 102 which, upon identifying the
code for charging unit selection request in the charging unit selection request message, displays
the account balance and the service units balances that are possible for selection by the user for
the call. The user may select either the account balance or one of the service units balances as the
active charging unit for the call. Based on the input received from the user, a charging unit
selection response message is generated by the SAMU system 102. The charging unit selection
response message may be in the form of a diameter message encoded with a code for active
charging unit based on which the subscription account be charged for the call, as described
earlier.
60
[0171] At block 1406, the charging unit selection response message, comprising the
details of the active charging unit, is sent by the SAMU system 102 to the SARR system 104, in
response to the charging unit selection request message. The SARR system 104, after receiving
the charging unit selection response message, identifies the details of the active charging unit
from the charging unit selection response message, and reports the details to the OCS 112 based
on which the subscription account is charged.
[0172] Referring to Figure 15, although the method 1500 for management of a
subscription account may be implemented in a variety of communication devices working in
different network environments, in an embodiment described in Figure 15, the method 1500 is
explained in context of the aforementioned SAMU system 102 and the SARR system 104 for the
ease of explanation.
[0173] At block 1502, a call-type indication request message is sent by the SAMU
system 102 to the SARR system 104 for obtaining rate plan subscription account details, from a
communication network entity, such as the OCS 112. The call-type indication request message
may be in the form of a diameter message encoded with a code for rate plan request and a code
for indicating the type of call initiated by the user, as described earlier. The call-type indication
request message is received by the SARR system 104 which, upon identifying the codes for the
rate plan request and for the type of call in the call-type indication request message, retrieves
details of multiple rate plans from the OCS 112, based on the type of call initiated by the user,
which the user may select for the initiated call. Based on the obtained details, the SARR system
104 generates a rate plan selection request message, encoded with the obtained details and details
of rate plan selection request, and sends the rate plan selection request message to the SAMU
system 102. The rate plan selection request message may be in the form of a diameter message
encoded with the details of the multiple rate plans and encoded with a code of rate plan selection
request, as described earlier.
[0174] At block 1504, the rate plan selection request message is received by the SAMU
system 102 from the SARR system 104, in response to the call-type indication request message,
for selection of an active rate plan for the call initiated by the user. The rate plan selection
request message is received by the SAMU system 102 which, upon identifying the code for rate
plan selection request in the rate plan selection request message, displays the multiple rate plans
61
that are possible for selection by the user for the call. The user may select either of the multiple
rate plans as the active rate plan for the call. Based on the input received from the user, a rate
plan selection response message is generated by the SAMU system 102. The rate plan selection
response message may be in the form of a diameter message encoded with a code for active rate
plan based on which the subscription account be charged for the call, as described earlier.
[0175] At block 1506, the rate plan selection response message, comprising the details of
the active rate plan, is sent by the SAMU system 102 to the SARR system 104, in response to the
rate plan selection request message. The SARR system 104, after receiving the rate plan
selection response message, identifies the details of the active rate plan from the rate plan
selection response message, and reports the details to the OCS 112 based on which the
subscription account be charged.
[0176] Referring to Figure 16, although the method 1600 for management of a
subscription account may be implemented in a variety of communication devices working in
different network environments, in an embodiment described in Figure 16, the method 1600 is
explained in context of the aforementioned SAMU system 102 and the SARR system 104 for the
ease of explanation.
[0177] At block 1602, a sync request message is sent for synching details of the
subscription account on the communication device with updated details of the subscription
account on a communication network entity, such as the OCS 112. The sync request message
may be in the form of a diameter message encoded with a code for sync request, as described
earlier. The sync request message is received by the SARR system 104 which, upon identifying
the code for the sync request in the sync request message, retrieves details of the updated account
balance and the updated service units balance from the OCS 112 based on the subscription
account of the user. Based on the obtained details, the SARR system 104 generates the sync
response message, encoded with the obtained details, and sends the sync response message to the
SAMU system 102. The sync response message may be in the form of a diameter message
encoded with the details of the updated account balance and the updated service units balance, as
described earlier.
62
[0178] At block 1604, the sync response message with the updated details of subscription
account is received by the SAMU system 102 from the SARR system 104, in response to the
sync request message sent at block 1602.
[0179] At block 1606, detail of the subscription account on the communication device
are synched with the updated details of the subscription account received in the sync response
message by the SAMU system 102. After synching the details, the updated details are displayed
to the user on the communication device at block 1608.
[0180] Referring to Figure 17, although the method 1700 for management of a
subscription account may be implemented in a variety of communication devices working in
different network environments, in an embodiment described in Figure 17, the method 1700 is
explained in context of the aforementioned SAMU system 102 and the SARR system 104 for the
ease of explanation.
[0181] At block 1702, a balance translation request message is sent for translating a
balance into another balance of the subscription account. The balance translation request
message is sent for translation of a balance of the subscription account, in real-time. The balance
translation request message may be in the form of a diameter message encoded with a code for a
source balance selected by the user for translation, as described earlier. The balance translation
request message is received by the SARR system 104 which, upon identifying the code for the
source balance in the balance translation request message, reports the details of source balance to
the OCS 112. The OCS 112, based on the source balance, sends details of target balances to
which the source balance may be translated by the user, and conversion ratios for the translation
of the source balance to one of the target balances. The SARR system 104 obtains the details of
the target balances and the conversion ratios from the OCS 112. Based on the obtained details,
the SARR system 104 generates a balance translation response message, encoded with the details
of target balances and conversion ratios, and sends the balance translation response message to
the SAMU system 102. The balance translation response message may be in the form of a
diameter message encoded with the codes of the target balances and codes of the conversion
ratios, as described earlier.
[0182] At block 1704, the balance translation response message with the target balances
and the conversion ratios is received by the SAMU system 102 from the SARR system 104, in
63
response to the balance translation request message sent at block 1702. The SAMU system 102
identifies the codes of the target balances and the conversion ratios, and displays the identified
details on the communication device for the translation of the source balance by the user. The
user may select a destination balance from the target balances and also select a number of source
balance units that are to be translated to the destination balance. Based on the inputs received
from the user, a balance translation commit request message is generated by the SAMU system
102. The balance translation commit request message may be in the form of a diameter message
encoded with a code for the destination balance and a code for the number of source balance
units, as described earlier.
[0183] At block 1706, the balance translation commit request message is sent by the
SAMU system 102 to the SARR system 104, in response to the balance translation response
message. The SARR system 104, after receiving the balance translation commit request message,
identifies the details of the destination balance and the number of source balance units, and
reports the identified details to the OCS 112 for translation. Based on the received details, the
OCS 112 may perform a check for translation of balances, as described earlier, and may translate
the source balance to the destination balance, based on the number of source balance units, in the
subscription account of the user. Further, after the alteration of balances, the SARR system 104
obtains details of altered balances from the OCS 112, and generates a balance translation commit
response message with the details of the altered balances. The SARR system 104 sends the
balance translation commit response message to the SAMU system 102. The balance translation
commit response message may be in the form of a diameter message encoded with codes for the
balances that are altered and codes for the number of units in the balances that are altered, as
described earlier.
[0184] At block 1708, the balance translation commit response message is received by
the SAMU system 102 from the SARR system 104, in response to the balance translation
commit request message. The SAMU system 102, after receiving the balance translation commit
response message, identifies the details of the altered balances. At block 1710, detail of the
altered balances, received in the balance translation commit response message by the SAMU
system 102, are displayed on the communication device for the user.
64
[0185] Although implementations for the subscription account management system 100
have been described in language specific to structural features and/or methods, it is to be
understood that the appended claims are not necessarily limited to the specific features or
methods described. Rather, the specific features and methods are disclosed as exemplary
implementations for management of subscription accounts.

I/We claim:
1. A subscription account monitoring and updating (SAMU) system (102) comprising:
a processor (202-1); and
a monitoring module (114) coupled to the processor (202-1), the monitoring module
(114) configured to,
send an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session, wherein the account retrieval
request message is based on initiation of a service session by a user of a communication
device (106), and wherein the at least one subscription account detail comprises one of an
account balance and at least one service units balance;
receive an account retrieval response message comprising the at least one
subscription account detail, during the on-going active service session on the
communication device (106) based on the account retrieval request message; and
provide the at least one subscription account detail on the communication device
(106) during the on-going active service session.
2. The SAMU system (102) as claimed in claim 1, wherein the account retrieval request
message is sent at a predefined time interval during the on-going active service session.
3. The SAMU system (102) as claimed in claim 1, wherein the monitoring module (114) is
configured to,
generate an alert signal when the one of the account balance and the at least one
service units balance is below a predefined limit value.
4. The SAMU system (102) as claimed in claim 1, wherein the account retrieval response
message further comprises at least one of a validity term, a rate plan, a charging rate, on-going
service, on-going type of call, and roaming status.
5. The SAMU system (102) as claimed in claim 1 further comprising:
a charging unit selection module (214) coupled to the processor (202-1), the charging unit
selection module (214) configured to,
send a call-type indication request message for obtaining call-specific subscription
account details based on a type of call initiated by the user, wherein the call-type
66
indication request message is sent at a time the call is initiated on the communication
device (106) by the user;
receive a charging unit selection request message, in response to the call-type
indication request message for selection of an active charging unit by the user, the
charging unit selection request message comprising the account balance and the service
units balances as the call-specific subscription account details, wherein the active
charging unit is indicative of one of the account balance and the service units balance,
which is to be deducted for the call; and
send a charging unit selection response message in response to the charging unit
selection request message, the charging unit selection response message comprising
details of the active charging unit, selected by the user.
6. The SAMU system (102) as claimed in claim 1 further comprising:
a rate plan selection module (216) coupled to the processor (202-1), the rate plan
selection module (216) configured to,
send a call-type indication request message for obtaining rate plan subscription
account details based on a type of call initiated by the user, wherein the call-type
indication request message is sent at a time the call is initiated on the communication
device (106) by the user;
receive a rate plan selection request message, in response to the call-type indication
request message for selection of an active rate plan by the user, the rate plan selection
request message comprising multiple rate plans, offered by a service provider to the user,
wherein the active rate plan is one of the multiple rate plans; and
send a rate plan selection response message in response to the rate plan selection
request message, the rate plan selection response message comprising details of the active
rate plan, selected by the user.
7. A subscription account retrieving and reporting (SARR) system (104) comprising:
a processor (202-2);
a retrieving module (116) coupled to the processor (202-2), the retrieving module (116)
configured to,
67
receive an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session over a communication network,
wherein the at least one subscription account detail comprises one of an account balance
and at least one service units balance; and
retrieve the at least one subscription account detail based on the account retrieval
request message, during the on-going active service session; and
a reporting module (226) coupled to the processor (202-2), the reporting module (226)
configured to,
send an account retrieval response message in response to the account retrieval
request message during the on-going active service session, the account retrieval response
message comprising the at least one subscription account detail.
8. The SARR system (104) as claimed in claim 7, wherein the account retrieval response
message is sent at a predefined time interval, based on the account retrieval request message,
during the on-going active service session.
9. The SARR system (104) as claimed in claim 7, wherein the retrieving module (116) is further
configured to,
send a charging unit selection request message for selection of an active charging unit, by
the user, based on a type of call initiated by the user on a communication device (106),
wherein the charging unit selection request message is sent at a time a call is initiated over
the communication network by the user, and wherein the active charging unit is indicative of
one of the account balance and the service units balance, which is to be deducted for the call;
and
receive a charging unit selection response message in response to the charging unit
selection request message, the charging unit selection response message comprising details of
the active charging unit, selected by the user, such that the reporting module (226) reports the
details of the active charging unit to a communication network entity.
10. The SARR system (104) as claimed in claim 7, wherein the retrieving module (116) is further
configured to,
send a rate plan selection request message for selection of an active rate plan, by the user,
based on a type of call initiated by the user on a communication device (106), wherein the
68
rate plan selection request message is sent at a time a call is initiated over the communication
network by the user, and wherein the active rate plan is one of a multiple rate plans indicative
of a charging rate for the call; and
receive a rate plan selection response message in response to the rate plan selection
request message, the rate plan selection response message comprising details of the active
rate plan, selected by the user, such that the reporting module (226) reports the details of the
active rate plan to a communication network entity.
11. A method for monitoring and updating subscription account, the method comprising:
sending an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session on a communication device (106)
over a communication network, wherein the account retrieval request message is based on
initiation of a service session by a user of the communication device (106), and wherein the
at least one subscription account detail comprises one of an account balance and at least one
service units balance; and
receiving an account retrieval response message comprising the at least one subscription
account detail, during the on-going active service session on the communication device (106)
based on the account retrieval request message.
12. The method as claimed in claim 11 further comprising:
sending a balance translation request message for translating a balance of a subscription
account in a communication network entity, wherein the balance translation request message
comprises details of a source balance which is to be translated,
receiving a balance translation response message in response to the balance translation
request message, the balance translation response message comprising details of target
balances and conversion ratios;
sending a balance translation commit request message in response to the balance
translation response message, the balance translation commit request message comprising
details of a destination balance and a number of source balance units, selected by the user;
receiving a balance translation commit response message in response to the balance
translation commit request message, the balance translation commit response message
69
comprising details of altered balances of subscription account, based on translation of the
source balance to the destination balance.
13. A method for retrieving and reporting details of subscription account, the method
comprising:
receiving an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session over a communication network,
wherein the at least one subscription account detail comprises one of an account balance and
at least one service units balance;
retrieving the at least one subscription account detail based on the account retrieval
request message, during the on-going active service session; and
sending an account retrieval response message comprising the at least one subscription
account detail, wherein the account retrieval response message is sent during the on-going
active service session, at a predefined time interval, based on the account retrieval request
message.
14. The method as claimed in claim 13 further comprising:
receiving a sync request message for obtaining updated details of subscription account,
wherein the updated details of subscription account are based on recharging for one of an
account balance and at least one service unit by a user;
retrieving the updated details from a communication network entity, based on the sync
request message; and
sending a sync response message in response to the sync request message, the sync
response message comprising the updated details of subscription account.
15. A computer-readable medium having computer-executable instructions that when executed
perform acts comprising:
sending an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session on a communication device (106)
over a communication network, wherein the account retrieval request message is based on
initiation of a service session by a user of the communication device (106); and
70
receiving an account retrieval response message comprising the at least one subscription
account detail, during the on-going active service session on the communication device (106)
based on the request message.
16. A computer-readable medium having computer-executable instructions that when executed
perform acts comprising:
receiving an account retrieval request message for obtaining at least one subscription
account detail during an on-going active service session over a communication network,
wherein the at least one subscription account detail comprises one of an account balance and
at least one service units balance;
retrieving the at least one subscription account detail based on the account retrieval
request message, during the on-going active service session; and
sending an account retrieval response message comprising the at least one subscription
account detail, wherein the account retrieval response message is sent during the on-going
active service session, at a predefined time interval, based on the account retrieval request
message.