FIELD OF INVENTION
[0001] The present subject matter relates to communication networks and,
particularly but not exclusively, to call rejections in the communication networks5 .
BACKGROUND
[0002] Communication devices, such as cellular phones, personal digital
assistants, and tablet computers, provide users with a variety of mobile
communications services. These communications services allow voice calls, video
10 calls, and data to be exchanged between the users through communication networks,
such as Global System for Mobile Communication (GSM), Code Division Multiple
Access (CDMA), and Public Switched Telephone Network (PSTN). In order to avail
a communication service, a communication device may establish a communication
link with a communication network. When a call is made by a user of a calling
15 device, a user of a called device is provided with a plurality of options for handling
the call. For example, the user of the called device may accept the call, reject the
call, redirect the call, or take other similar actions.
SUMMARY
[0003] This summary is provided to introduce concepts related to call
20 rejections in the communication networks. This summary is not intended to identify
essential features of the claimed subject matter nor is it directed to use in
determining or limiting the scope of the claimed subject matter.
[0004] In an embodiment of the present subject matter, a method for rejecting a
call request is disclosed. The method includes, indicating, by a processor, a call
25 request from a calling device. The method further includes rendering, by the
processor, a plurality of rejection options on an interface of a called device. The
3
plurality of rejection options are rendered upon receiving a call rejection command
in response to indicating the call request. Further, each of the plurality of rejection
options is associated with a cause code. The method also includes generating, by the
processor, a message, upon receiving a selection of a rejection option from the
plurality of rejection options. The message is shared with a call rejectio5 n
announcement system for being provided to the calling device.
[0005] In accordance with another embodiment of the present subject matter, a
method for providing a call rejection announcement is disclosed. The method may
include receiving, by a processor, a message from a called device. The message is
10 received upon rejection of a call request. The message may include a cause code for
rejecting the call request. The method may further include providing, by the
processor, an announcement to a calling device. The announcement may correspond
to the cause code indicated in the message.
[0006] In accordance with another embodiment of the present subject matter, a
15 communication device is disclosed. The communication device may include a
processor, a rendering module coupled to the processor, and a message generation
module coupled to the processor. The rendering module may indicate a call request
from a calling device. Further, the rendering module may render a plurality of
rejection options on an interface, upon receiving a call rejection command. Each of
20 the plurality of rejection options is associated with a cause code. In addition, the
message generation module may generate a message, upon receiving a selection of a
rejection option. The message is shared with a call rejection announcement system
for being provided to the calling device.
[0007] In yet another embodiment of the present subject matter, a call rejection
25 announcement system is disclosed. The call rejection announcement system may
include a processor, a determination module coupled to the processor, and an
announcement module coupled to the processor. The determination module may
4
receive a message from a called device, upon rejection of a call request by the called
device. The message may include a cause code for rejecting the call request. Further,
the announcement module may provide an announcement to a calling device, upon
receipt of the message. The announcement may correspond to the cause code
indicated in the message5 .
[0008] In still another embodiment of the present subject matter, a nontransitory
computer-readable medium having embodied thereon a computer program
for executing a method for rejecting a call request is disclosed. The method includes,
indicating, by a processor, a call request from a calling device. The method further
10 includes rendering, by the processor, a plurality of rejection options on an interface
of a called device. The plurality of rejection options are rendered upon receiving a
call rejection command in response to indicating the call request. Further, each of the
plurality of rejection options is associated with a cause code. The method also
includes generating, by the processor, a message, upon receiving a selection of a
15 rejection option from the plurality of rejection options. The message is shared with a
call rejection announcement system for being provided to the calling device.
[0009] In still another embodiment of the present subject matter, a nontransitory
computer-readable medium having embodied thereon a computer program
for executing a method for providing a call rejection announcement is disclosed. The
20 method may include receiving, by a processor, a message from a called device. The
message is received upon rejection of a call request. The message may include a
cause code for rejecting the call request. The method may further include providing,
by the processor, an announcement to a calling device. The announcement may
correspond to the cause code indicated in the message.
25 BRIEF DESCRIPTION OF THE FIGURES
[0010] 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
5
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 system 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 which5 :
[0011] Figure 1(a) schematically illustrates a communication network
environment comprising a network device, in accordance with an embodiment of the
present subject matter.
[0012] Figure 1(b) schematically illustrates a communication network
10 environment comprising a call rejection announcement system, in accordance with
an embodiment of the present subject matter.
[0013] Figure 2 illustrates an exemplary call flow diagram for rejecting calls in a
communication network, according to an embodiment of the present subject matter.
[0014] Figure 3(a) illustrates a method for rejecting a call request, according to
15 an embodiment of the present subject matter.
[0015] Figure 3(b) illustrates a method for providing a call rejection
announcement, according to an embodiment of the present subject matter.
[0016] It should be appreciated by those skilled in the art that any block
diagrams herein represent conceptual views of illustrative systems embodying the
20 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.
6
DESCRIPTION OF EMBODIMENTS
[0017] Systems and methods for call rejections in a communication network
are described. The systems and methods can be implemented in a variety of
communication devices. The communication devices that can implement the
described method(s) include, but are not limited to, desktop computers, hand-hel5 d
devices, laptops or other portable computers, mobile phones, fixed phones, and the
like. Additionally, the method can be implemented in any communication network,
such as Global System for Mobile Communication (GSM) network, Universal
Mobile Telecommunications System (UMTS) network, Personal Communications
10 Service (PCS) network, Time Division Multiple Access (TDMA) network, Code
Division Multiple Access (CDMA) network, Next Generation Network (NGN), and
IP-based network, Public Switched Telephone Network (PSTN), Integrated Services
Digital Network (ISDN), or their combinations. Although the description herein is
with reference to certain networks, the systems and methods may be implemented in
15 other networks and devices, albeit with a few variations, as will be understood by a
person skilled in the art.
[0018] Even though communication services allow voice and video calls to
be exchanged between users of communication devices, there exist certain scenarios
where the voice and video calls may fail due to unavailability of users. For example,
20 when a user of a called device, hereinafter referred to as a called user, is not in a
position to answer the call, such as when they are in a meeting or travelling, the
called user rejects the call. With the advent of intelligent network, a user of a calling
device, hereinafter referred as a caller, is merely informed by providing an
announcement that the called user is busy or unavailable. For example, the network
25 providers may provide call rejection announcements, such as "User is busy. Please
call after some time". In some cases, the caller may leave a voicemail for the called
user. There is generally no context given to the caller on the availability of the called
7
user and in what activity the called user is busy or when the voicemail might be
listened to.
[0019] Some existing solutions allow the called user to send a pre-configured
text message (also referred to Short Message Service) to the caller. However, the
SMS may be chargeable to the called user. In addition, in situations where the calle5 r
is using a fixed telephone which does not have a messaging facility, the SMS
delivery may fail. As a result, the caller may not receive information about the
availability of the called user.
[0020] Further, the rejection of an attempted communication can be
10 frustrating in urgent situations. For an urgent matter, a caller may attempt to contact
the called user by additional methods, e.g., sending text messages, emails, or
messages using instant messaging services, and these can place additional burdens
on the caller. In some situations, callers often place repetitive calls to the called user
until the call is answered. Placing repetitive calls is inconvenient as it wastes the time
15 of the callers, who repeatedly re-key or re-dial a phone dialing sequence. In addition,
wireless network resources, which repetitively route and process the voice calls until
a call is answered, are also wasted. The resource consumption is particularly high for
voice and video calls as the voice and the video calls generally receive high network
priority.
20 [0021] According to an embodiment of the present subject matter, methods
and systems for rejecting calls in a communication network are provided. When a
caller attempts to establish a call, such as a voice call or a video call, with the caller,
a call request may be sent to a communication device of the called user over a
communication network. Upon receiving the call request, the called user may either
25 accept or reject the call request. If the called user selects to reject the call request, the
communication device of the called user may receive a reject call command from the
called user. Based on the reject call command, the communication device may render
8
a plurality of rejection options for selection by the called user. Each of the plurality
of the call rejection options may be associated with a cause code. The cause code
may be understood as a pre-defined code that is indicative of a reason for rejection of
the call request.
[0022] Based on the call rejection, the communication device may generate 5 a
message for being sent to the communication network. The message may include the
cause code of the call rejection option as may be selected by the called user. In an
implementation, the message may include a new cause code or may include an
existing cause code with a new parameter. In another implementation, the message
10 may also include a pre-defined time interval for being communicated to the calling
device. In one implementation, the pre-defined time interval may be set according to
the called user preferences. The pre-defined time interval is indicative of a time
period after which caller may send another call request to the communication device.
[0023] In an implementation, the message may be analyzed by a network
15 device in the communication network to determine the cause code. The network
device may determine whether the cause code or the parameter associated with the
cause code is defined in the communication network or not. Upon identifying the
cause code of the message, the network device may identify an announcement from a
plurality of pre-configured announcements, corresponding to the cause code or the
20 parameter. In an implementation, the network device may receive instructions about
the announcement to be played to the calling device. Upon identification, the
announcement may be provided to the calling device, for example, may be played
back as a voice message, thereby indicating the reason for rejecting the call request.
[0024] In this manner, the present subject matter provides example methods
25 and systems to reject calls, such as voice calls or video calls, in the communication
network, by providing the called user with a plurality of call rejection options. As
each of the call rejection option is associated with a reason for rejection of the call
9
request, the present subject matter facilitates in intimating the caller about the reason
for call rejection. In addition, the call rejection message/ reason is provided to the
caller in the form of an announcement. Accordingly, even if the caller is using a
communication device, such as a fixed telephone, that does not support text
messages, the announcement may indicate to him the reason for call rejection5 .
Further, the present subject matter may facilitate in reducing number of un-billable
calls in the communication network which results in optimal network resource
utilization.
[0025] The above methods and system are further described in conjunction
10 with the following figures. It should be noted that the description and figures merely
illustrate 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 or shown herein, embody the principles of the present subject
matter and are included within its spirit and scope. Furthermore, all examples recited
15 herein are principally intended expressly to be only for pedagogical purposes to aid
the reader in understanding the principles of the present subject matter and the
concepts contributed by 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
20 present subject matter, as well as specific examples thereof, are intended to
encompass equivalents thereof.
[0026] 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
25 reasonable delay, such as a propagation delay, between the initial action, and the
reaction that is initiated by the initial action. Additionally, the words “connected”
and “coupled” are used throughout, for clarity of the description and can include
either a direct connection or an indirect connection.
10
[0027] The manner in which the systems and methods for call rejection in a
communication network shall be explained in details with respect to the Figures 1-
3(b). While aspects of described systems and methods for call rejection in a
communication network can be implemented in any number of different computing
systems, transmission environments, and/or configurations, the embodiments ar5 e
described in the context of the following exemplary system(s).
[0028] Figure 1(a) schematically illustrates a communication network
environment 100 comprising a network device 102, in accordance with an
embodiment of the present subject matter. The network device 102 may provide
10 announcements to one or more communication devices, such as communication
devices 104-1 and 104-2. For the purpose of explanation, the communication device
104-2 from where a call, such as a voice call or a video call, is initiated, may be
hereinafter referred to as the calling device 104-2 and the communication device
104-1 at the receiving end may be referred to as the called device 104-1.
15 [0029] In an implementation, when a user of the calling device 104-2
attempts to establish a call, such as a voice call or a video call, with the user of the
called device 104-1, a call request may be sent to the called device 104-1 over the
communication network 106. The user of the called device 104-1 may receive an
indication of the call request on an interface (not shown) of the called device 104-1.
20 The indication may include a call acceptance option, a call rejection option, a call
forward option, and the like. Accordingly, as the case may be, the user of the called
device 104-1 may either accept or reject the call request. If the user of the called
device 104-1 selects to reject the call request, a reject call command may be sent to
the called device 104-1. For example, when the user of the called device 104-1
25 presses a key corresponding to the call rejection option, the reject call command may
be sent to the called device 104-1.
11
[0030] Upon receiving the reject call command, the called device 104-1 may
render a plurality of rejection options for selection by the called user. In an
implementation, each of the plurality of the call rejection options may be associated
with a cause code. The cause code may be understood as a pre-defined code that is
indicative of a reason for rejection of the call request. When the user of the calle5 d
device 104-1 selects any of the call rejection options, the called device 104-1 may
receive a selection of the call rejection option. Based on the call rejection option, the
called device 104-1 may generate a message for being sent to the communication
network 106. The message may include the cause code of the call rejection option as
10 may be selected by the called user. In an implementation, the message may include a
new cause code or may include an existing cause code with a new parameter. In
another implementation, the message may also include a pre-defined time interval
for being communicated to the calling device 104-2. In one implementation, the predefined
time interval may be set according to the called user preferences. The pre15
defined time interval is indicative of a time period after which user of the calling
device 104-2 may send another call request to the called device 104-1.
[0031] In an implementation, the message may be analyzed by the network
device 102 in the communication network 106, to determine the cause code. Upon
identifying the cause code of the message, the network device 102 may identify an
20 announcement from a plurality of pre-configured announcements, corresponding to
the cause code or the parameter. Upon identification, the announcement may be
provided to the calling device 104-2, for example, may be played back as a voice
message, thereby indicating the reason for rejecting the call request.
[0032] Figure 1(b) schematically illustrates a communication network
25 environment 150 comprising a call rejection announcement system 102, hereinafter
referred to as an announcement system 102, in accordance with an embodiment of
the present subject matter. In one example, the announcement system 102 may be
implemented in a Mobile Switching Center (MSC). In other examples, it may be
12
implemented in different systems. The announcement system 102 may provide
announcements to one or more communication devices 104-1, 104-2, 104-3,..., 104-
N. The communication devices 104-1, 104-2, 104-3,…, 104-N, may be collectively
referred to as communication devices 104. In the communication network
environment 150, the communication devices 104 communicate with each othe5 r
through a communication network 106. The communication devices 104 also interact
with various network entities, for example, to avail various communication services
or to communicate with other communication devices 104. The communication
devices 104 may include, without limitation, fixed/wired telephones, hand-held
10 devices, tablet computers, mobile phones, PDAs, smart phones, and the like. Each of
the communication devices 104 works on a communication protocol as defined by a
communication network 106 to which the communication device 104 is coupled.
[0033] The communication network 106 may be a wireless or a wired
network, or a combination thereof. The communication network 106 can be a
15 collection of individual networks, interconnected with each other and functioning as
a single large network (e.g., the internet or an intranet). Examples of such individual
networks include, but are not limited to, Global System for Mobile Communication
(GSM) network, Universal Mobile Telecommunications System (UMTS) network,
Personal Communications Service (PCS) network, Time Division Multiple Access
20 (TDMA) network, Code Division Multiple Access (CDMA) network, Next
Generation Network (NGN), Public Switched Telephone Network (PSTN), and
Integrated Services Digital Network (ISDN). Depending on the technology, the
communication network 106 includes various network entities, such as gateways,
routers; however, such details have been omitted for ease of understanding.
25 [0034] The foregoing description is explained with reference to the
communication devices 104 and it will be understood that the same can be extended
to other communication devices as well. In order to communicate with each other,
13
the communication devices 104 connect to a base station controller (BSC) (not
shown in the figure), which provides local switching to effect handover between base
stations. The BSC is further connected to a MSC, for example, the MSC
implementing the announcement system 102, of the communication network 106,
which is responsible for allowing the different communication devices 104 t5 o
communicate with each other.
[0035] Further, in order to provide one or more services, the communication
network 106 includes a service control point (SCP) server 108, hereinafter referred to
as the SCP 108, connected to the MSC. The SCP 108 checks parameters, such as
10 user’s credit information and user subscription details to verify whether the user has
balance to receive or initiate a call. The announcement system 102 communicates
with the SCP 108, either directly or through various entities (not shown in the
figure), for providing various services to the communication devices 104. For
example, in GSM networks, the announcement system 102 communicates with the
15 SCP 108 over Customized Applications for Mobile networks Enhanced Logic
(CAMEL) protocol. In CDMA networks the communication between the
announcement system 102 and the SCP 108 occurs over Wireless Intelligent
Network (WIN) protocol. Additionally, the SCP 108 is configured to manage
announcements, such as call connection announcements, service announcements, and
20 other similar network announcements that have to be provided to the communication
devices 104.
[0036] In one embodiment, in order to provide announcements to the
communication devices 104, the announcement system 102 communicates with a
specialized resource function (SRF) or an intelligent peripheral (IP) 110. The SRF
25 110 may be understood as a node that connects to the SCP 108 and MSC and
provides additional special resources into the call, for example, to provide voice
announcements. The announcement system 102, on receiving a message from a
14
called communication device, such as the communication device 104-1, for rejecting
a call request from a calling communication device, such as the communication
device 104-2, requests the SRF 110 to provide an announcement to the calling device
104-2. The SRF 110 is configured to provide announcements to the communication
devices 104 that are registered with a service provider based on requests receive5 d
from the announcement system 102.
[0037] In one implementation, the announcement system 102 includes one or
more processor(s) 112-1, I/O interface(s) 114-1, and a memory 116-1 coupled to the
processor 112-1. Further, each of the communication devices 104 includes
10 processor(s) 112-2, I/O interface(s) 114-2, and a memory 116-2 coupled to the
processor 112-2. Although, the processor(s) 112-2, the I/O interface(s) 114-2, and
the memory 116-2 have been shown for the communication device 104-1, it will be
understood that the same will be implemented in all the communication devices 104.
[0038] Each of the processors 112-1 and 112-2 can be a single processing
15 unit or a number of units, all of which could also include multiple computing units.
The processors 112-1 and 112-2 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, each of the
20 processors 112-1 and 112-2 is configured to fetch and execute computer-readable
instructions and data stored in the memory 116-1 and 116-2, respectively.
[0039] Functions of the various elements shown in the figures, 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
25 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
15
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 storing software, random access memory (RAM), and non volatile storage. Othe5 r
hardware, conventional and/or custom, may also be included.
[0040] Each of the I/O interfaces 114-1 and 114-2 may include a variety of
software and hardware interfaces, for example, interface for peripheral device(s),
such as a keyboard, a mouse, an external memory, and a printer. Further, the I/O
10 interface 114-1 may enable the announcement system 102 to communicate with
other network entities, such as the SCP 108, the SRF 110, and like. Likewise the I/O
interface 114-2 may enable the communication devices 104 to communicate with
other network entities, such as the announcement system 102, and like.
[0041] Each of the memory 116-1 and 116-2 may include any computer15
readable medium known in the art including, for example, volatile memory, such as
static random access memory (SRAM) and dynamic random access memory
(DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable
programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[0042] In one implementation, the announcement system 102 and the
20 communication devices 104 include modules 118-1 and 118-2 respectively. The
module(s) 118-1 and 118-2 include routines, programs, objects, components, data
structures, etc., which perform particular tasks or implement particular abstract data
types. The module(s) 118-1 further include a determination module 120, an
announcement module 122, and other module(s) 124. The modules 118-2 further
25 include a rendering module 126, a message generation module 128, and other
module(s) 130. The other module(s) 124 and 130 may include programs or coded
16
instructions that supplement applications and functions of the announcement system
102 and the communication devices 104, respectively.
[0043] In one implementation, the announcement system 102 and the
communication devices 104 include data 132-1 and 132-2 respectively. The data
132-1 and 132-2, amongst other things, serves as a repository for storing dat5 a
processed, received, and generated by one or more of the module(s) 118-1 and 118-2
respectively. The data 132-1 includes, for example, announcement data 134 and
other data 136. The data 132-2 includes, for example, message data 138 and other
data 140. The other data 136 and 140 includes data generated as a result of the
10 execution of one or more modules in the other module(s) 124 and 130, respectively.
[0044] In order to establish a call with a communication device, such as the
communication device 104-1, another communication device 104-2 may send a call
request to the communication device 104-1 over the communication network 106.
The communication device 104-2 attempting to establish a call with another
15 communication device may be referred as a calling device 104-2. Further, the
communication device 104-1 receiving the call request from the calling device 104-2
may be referred as a called device 104-1. The calling device 104-2 sends a request to
the called device 104-1 through the communication network 106 to establish a call
session with the called device 104-1. The call request may be sent by the calling
20 device 104-2 irrespective of the type of communication protocol implemented by the
communication network 106. In one implementation, the call request may include a
request call address which contains the Public User Identity (PUI) of the called
device 104-1. The PUI may define the details regarding the called device 104-1, such
as its address and location. Further, the call request may also include a contact
25 header field which may include a Session Initiation Protocol (SIP) call address. The
SIP call address may indicate the physical address of the device where the calling
device 104-2 wishes to receive the media content pertaining to the call, from the
17
called device 104-1. The call request may thus include the address and location
details of the called device 104-1 along with the address and location details of the
calling device 104-2.
[0045] The rendering module 126 of the called device 104-1 may receive the
call request from the calling device 104-2 over the communication network 1065 .
Based on the call request, the rendering module 126 may provide a user of the called
device 104-1 with options to manage the call request. For example, the options may
include acceptance of the call request, rejection of the call request, forwarding the
call request to a voicemail, and the like. As may be understood, the rendering module
10 126 may provide the options to the user of the called device 104-1 through the I/O
interface 114-2, such as a display screen. In a scenario, if the user of the called
device 104-1 may be available to take the call, the user may press or touch an accept
call button on the called device 104-1.
[0046] In another scenario, if the user is not available to attend the call
15 request, the user may select the call reject option as provided by the rendering
module 126. The selection of the call reject option may be received by the rendering
module 126 as a call rejection command. Upon receiving the call rejection
command, the rendering module 126 may render a plurality of call rejection options
to the user of the called device 104-1. In an implementation, each of the call rejection
20 options may be associated with a reason for rejection of the call request. The call
rejection options may be pre-defined in the communication device 104-1. In an
example, the call rejection options may be visual call rejection options. For example,
the visual call rejection options may indicate a plurality of reasons due to which the
user of the called device 104-1 is unable to accept the call request. The visual options
25 may include a driving symbol, a meeting symbol, a call later symbol, and the like. In
another example, the call rejection options may be textual options.
18
[0047] In an implementation, each of the plurality of call rejection options is
associated with a separate cause code. The cause code may be understood as a
numeric code, a string, or an alphanumeric code, that can be transmitted from the
communication device 104 to an entity, such as the MSC, in the communication
network 106. The cause code is associated with a definition pertaining to an actio5 n
performed by the user of the called device 104-1. For example, a cause code '17'
indicates that the user of the called device 104-1 is busy on another call, a cause code
'18' indicates that the user of the called device 104-1 is not responding to the call
request initiated by the calling device 104-2, a cause code '21' indicates that the call
10 request is rejected by the user of the called device 104-1, and the like. Thus, each
cause code is pre-associated with a reason for the action of the user of the called
device 104-1. In an implementation, the cause code associated with each of the
plurality of call rejection options may be associated with an existing cause code
having an additional parameter attached thereto. The additional parameter may be
15 indicative of the reason for rejection of the call request. In another implementation,
new cause code may be associated with each of the call rejection options.
[0048] When the user of the called device selects any of the plurality of call
rejection options, the message generation module 128 may receive a selection of the
rejection option and based on the receipt may generate a message corresponding to
20 the call rejection option. The message may include the cause code corresponding to
the selected call rejection option. As mentioned above, the cause code may be an
existing cause code with an additional parameter or a new cause code based on preconfigured
settings of the communication device 104. Further, the message may
include a pre-defined time interval for being communicated to the calling device
25 104-2. The pre-defined time interval is indicative of a time period after which the
user of the calling device 104-2 may again attempt to establish a call with the called
device 104-1. The pre-defined time interval may be associated with each of the
plurality of call rejection options. For example, the user of the called device 104-1
19
may select a call rejection option that indicates that the user is busy in a meeting. The
message, when generated, may include the cause code for the reason of call rejection
along with a time-interval that will be communicated to the calling device 104-2.
The time-interval indicates that the user of the called device 104-1 is going to
unavailable to accept the call request for another half an hour or 15 minutes. Thi5 s
will provide a context to the user of the calling device 104-2 and he may then
attempt the next call after the time-interval as indicated in the message. The message
generation module 128 may store the cause code and the corresponding time
intervals as the message data 138.
10 [0049] In an implementation, the message may be transmitted by the called
device 104-1 to the announcement system 102 in the communication network 106. In
an example, the message transmitted through a Customized Application for Mobile
networks Enhanced Logic (CAMEL) protocol. For example, the called device 104-1
may send a RELEASE message to the announcement system 102 in the
15 communication network 106. The determination module 120 may receive the
message from the called device 104-1. Upon receiving the message, the
announcement system 102 sends a request message to the SCP 108. The request
message includes information about the call request made by the calling device 104-
2. For instance, the announcement system 102 sends a request message informing the
20 SCP 108 about the call request made by the calling device 104-2. The SCP 108, on
receiving the request message, checks few user parameters, such as user’s credit
information.
[0050] On verifying the parameters, the SCP 108 requests the announcement
system 102 to initiate a communication link with the calling device 104-2. Upon
25 initiation of the communication link, the determination module 120 of the
announcement system 102 may analyze the message to determine the cause code
sent by the called device 104-1. Upon identification of the cause code, the
announcement module 122 may identify an announcement from a plurality of pre20
defined announcements. In an implementation, the announcement module 122 may
communicate with the SRF 110 to identify the announcement corresponding to the
cause code. The SRF 110 may be associated with an SRF database (not shown). The
SRF database may be configured to store various announcements that may be
applicable for the communication devices 104. Although the SRF 110 is show5 n
outside the MSC, functionality of the SRF 110 may reside within the MSC. For
example, the announcements may reside within the MSC and the MSC may play
these announcements to the calling device 104-2.
[0051] Therefore, the announcement module 122 may read announcement
10 identification information corresponding to the cause code. The announcement
identification information may include, but not limited to, communication device
identity information and an announcement ID corresponding to the announcement
that has to be provided to a communication device 104, such as the calling device
104-2. Based on the announcement ID, the announcement module 122 may identify
15 the announcement corresponding to the cause code that has to be provided to the
calling device 104-2. The announcement module 122 may then instruct the SRF 110
to provide the announcement to the calling device 104-2.
[0052] In another implementation, the SCP 108 may provide the mapping of
the announcement ID against the cause code to the announcement system 102
20 residing in the MSC. The SCP 108 may identify the SRF 110 containing the
announcement to be played to the calling device 104-2. For example, the SCP 108
may therefore, share an SRF ID and an announcement ID with the announcement
system 102. The announcement system 102 may communicate with the SRF 110
corresponding to the SRF ID and instruct the SRF 110 to play the announcement
25 corresponding to the announcement ID as shared by the SCP 108. Upon receiving
the announcement ID, the announcement module 122 may communicate with the
SRF 110 to provide the announcement to the calling device 104-2.
21
[0053] Based on the announcement ID, the announcement module 122 may
identify, from the announcement data 134, an announcement corresponding to the
cause code that has to be provided to the calling device 104-2. In one
implementation, the announcement data 134 includes a table having a list of
announcement and the announcement ID corresponding to all the announcements5 .
The announcement module 122 may use the table to identify and subsequently select
the announcement corresponding to the cause code as indicated in the message. For
instance, the announcement module 122 may identify an announcement
corresponding to the call rejection option based on the announcement ID and
10 instructs the SRF 110 to provide the announcement to the calling device 104-2.
[0054] The present subject matter thus enables users to reject calls in the
communication network 106. The user of the called device 104-1 is provided with a
plurality of call rejection options. As each of the call rejection option is associated
with a cause code indicating a reason for rejection of the call request. The present
15 subject matter thus facilitates in intimating the caller about the reason for call
rejection. In addition, the call rejection options are provided to the user of the calling
device 104-2 in the form of announcements. Accordingly, even if the calling device
104-2 is a fixed telephone, that does not support text messages; the announcement
may indicate to the caller the reason for call rejection. In addition, the announcement
20 system 102 in reduced number of un-billable calls in the communication network
106 which results in optimal network resource utilization.
[0055] Figure 2 illustrates an exemplary call flow diagram 200 for rejecting
calls in the communication network 106, according to an embodiment of the present
subject matter. The various arrow indicators used in the call-flow diagram 200 depict
25 the transfer of data between the various entities in the communication network 106
and between the communication devices 104 and the various entities in the
communication network 106. Although the description of Figure 2 has been made in
considerable detail with respect to a GSM network, it will be understood the
22
announcements can be provided to communication device using other networks as
well, for example, CDMA network.
[0056] In one implementation, at step 202, the calling device 104-2 DIALS a
number of the called device 104-1. The step of dialing may be understood as sending
a call request to the called device 104-1. To this end, the calling device 104-5 2
initiates a session with the announcement system 102 residing in the MSC of the
communication network 106. On receiving the call request from the calling device
104-2, the announcement system 102 connects to the SCP 108. As described
previously, the announcement system 102 communicates with the SCP 108 over the
10 CAMEL protocol in GSM, whereas in CDMA networks the communication between
the announcement system 102 and the SCP 108 occurs over the WIN protocol.
However, for the purpose of explanation, and not as a limitation, the call flow
diagram 200 has been explained with reference to the GSM networks.
[0057] In one implementation, the announcement system 102 may exchange
15 INAP/CAMEL based messages with the SCP 108, as indicated by step 204. For
example, the announcement system 102 may send an Initial detection point
(INITIAL DP) message to the SCP 108. The INITIAL DP indicates detection of a
trigger, which can be understood as a condition under which the external service
logic is to be invoked to provide a service requested by the user. The INITIAL DP in
20 one implementation provides the call request to the SCP 108. In response to the
INITIAL DP, the SCP 108 may send a Request Report Basic Call State Model
(RRBCSM) message to the announcement system 102. The RRBCSM message may
be understood to be a request to identify occurrence of an event, for example, call
answered, route select failure, no reply, called party busy, and service center busy.
25 [0058] In addition, the SCP 108 may check certain parameters associated
with the call request. For example, the SCP 108 may check the credit information of
the user of the calling device 104-2. On verifying the parameters, the SCP 108 may
23
send an Apply Charging (AC) message to the announcement system 102. The AC
message may indicate that the user of the calling device 104-2 has sufficient balance
to establish the call with the called device 104-1. The announcement system 102 may
upon receiving the AC message from the SCP 108 may send an Initial Address
Message (IAM) to the called device 104-1, as shown in step 206. The IAM is sent t5 o
inform the called device 104-1 that the call has to be established with the calling
device 104-2. The IAM includes details about the called device 104-1, such as the
contact number, type of service (speech or data), and other parameters.
[0059] Further, at step 208, the called device 104-1 may send an Address
10 Complete Message (ACM) to the announcement system 102 residing in the MSC.
The ACM is a message that is returned from the called device 104-1 when a
subscriber is reached and the called device 104-1, such as a phone starts ringing, or
when the call traverses an interworking point and an intermediate trunk is seized.
When the user of the called device 104-1 rejects the call request by selecting one of a
15 plurality of call rejection options, a RELEASE message may be sent to the
announcement system 102, in the MSC, as shown in step 210. The RELEASE
message may include a cause code indicating a reason for rejection of the call
request. In an implementation, the cause code may be associated with a parameter
indicating the reason for the rejection of the call request.
20 [0060] The announcement system 102 may, upon receiving the RELEASE
message, determine the cause code and also identify an announcement to be provided
to the calling device 104-2. In an implementation, the announcement system 102
may communicate with the SRF 110 to identify the announcement corresponding to
the cause code. The SRF 110 may be associated with an SRF database (not shown).
25 The SRF database may be configured to store various announcements that may be
applicable for the communication devices 104.
24
[0061] In an alternative implementation, the announcement system 102 and
the SCP 108 may exchange INAP/CAMEL based messages, as shown in step 212.
The INAP/CAMEL based messages may be related to details about the
announcement for being played to the calling device 104-2. For example, the SCP
108 may provide an announcement ID corresponding to the cause code. The SC5 P
108 may identify the SRF 110 containing the announcement to be played to the
calling device 104-2. The SCP 108 may therefore, share an SRF ID and the
announcement ID with the announcement system 102. Based on the announcement
details, the announcement system 102 may instruct the SRF 110 to play
10 announcement to the calling device 104-2, as shown in step 214. For example, the
announcement system 102 may send a Provide Announcement With Elementary
Message ID (PA with EMID) message to the SRF 110. The PA with EMID message
includes details about the announcement corresponding to the cause code of the call
rejection option, from the plurality of announcements stored in the SRF 110. The
15 announcement system 102 may communicate with the SRF 110 corresponding to the
SRF ID and instruct the SRF 110 to play the announcement corresponding to the
announcement ID as shared by the SCP 108. The SRF 110 may accordingly play the
announcement to the calling device 104-2, as shown in step 216.
[0062] Once the announcement is provided to the calling device 104-2, the
20 announcement system 102 and the SCP 108 may exchange INAP/CAMEL based
messages with each other, as indicated in step 218. For example, the announcement
system 102 may send an Event RBCSM message to the SCP 108. The Event
RBCSM message may be sent to the SCP 108, by the announcement system 102 to
determine whether the call was established between the calling device 104-2 and the
25 called device 104-1 or not. Further, the Event RBCSM message determines if the call
took place between the two devices what the call charges were for the same. As the
call request was rejected by the called device 104-1, the SCP 108 may send a
DISCONNECT/RELEASE CALL message to the MSC.
25
[0063] Figure 3(a) illustrates a method 300 for rejecting a call request and
Figure 3(b) illustrates a method 350 for providing a call rejection announcement,
according to an embodiment of the present subject matter. The order in which the
method 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 th5 e
methods 300 and 350 or any alternative method. Additionally, individual blocks may
be deleted from the method without departing from the spirit and scope of the subject
matter described herein. Furthermore, the method can be implemented in any
suitable hardware, software, firmware, or combination thereof.
10 [0064] The method(s) may be described in the general context of computer
executable instructions. Generally, computer executable instructions can include
routines, programs, objects, components, data structures, procedures, modules,
functions, etc., that perform particular functions or implement particular abstract data
types. The methods may also be practiced in a distributed computing environment
15 where the functions are performed by remote processing devices that are linked
through a communications network. In a distributed computing environment,
computer executable instructions may be located in both local and remote computer
storage media, including memory storage devices.
[0065] A person skilled in the art will readily recognize that steps of the
20 methods 300 and 350 can be performed by programmed computers. Herein, some
embodiments are also intended to cover program storage devices or computer
readable medium, for example, digital data storage media, which are machine or
computer readable and encode machine-executable or computer-executable programs
of instructions, where said instructions perform some or all of the steps of the
25 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
26
also intended to cover both communication network and communication devices to
perform said steps of the method(s).
[0066] Referring to Figure 3(a), at block 302, the method 300 may include
indicating a call request from a calling device 104-2. In an implementation, the
rendering module 126 may indicate the call request from the calling device 104-2 t5 o
initiate communication with a called device 104-1. The call request may include
details about the called device 104-1, such as an address of the called device 104-1 in
conjunction with information about interconnections in the communication network
106. The call request may also include details about the calling device 104-2, such as
10 the address and location details of the calling device 104-2.
[0067] At block 304, the method 300 may include rendering a plurality of
call rejection options on an interface 114-1 of the called device 104-1, upon receipt
of a call rejection command. Further, each of the plurality of call rejection options is
associated with a cause code indicating a reason for rejection of the call request. In
15 an implementation, the rendering module 126 may, based on the call request, provide
a user of the called device 104-1 with options to manage the call request. For
example, the options may include acceptance of the call request, rejection of the call
request, forwarding the call request to a voicemail, and the like. If the user is not
available to attend the call request, the user may select the call reject option as
20 provided by the rendering module 126. The selection of the call reject option may be
received by the rendering module 126 as a call rejection command. Upon receiving
the call rejection command, the rendering module 126 may render a plurality of call
rejection options to the user of the called device 104-1. In an implementation, each
of the call rejection options may be associated with a cause code indicating a reason
25 for rejection of the call request.
[0068] At block 306, the method 300 may include generating a message,
upon receiving a selection of a call rejection option from the plurality of rejection
27
options. The message is shared with the call rejection announcement system 102, for
being provided to the calling device 104-2. In an implementation, the message
generation module 128 may receive a selection of the rejection option and based on
the receipt may generate a message corresponding to the rejection option. The
message may include the cause code corresponding to the selected rejection option5 .
Further, the message may include a pre-defined time interval for being
communicated to the calling device 104-2. The pre-defined time interval is indicative
of a time period after which the user of the calling device 104-2 may again attempt to
establish a call with the called device 104-1.
10 [0069] The present subject matter thus enables the called device 104-1 to
indicate the reason for rejection of the call request to the calling device 104-2 by
selecting any of the pre-defined rejection options.
[0070] Referring to Figure 3(b), at block 352, the method 350 may include
receiving a message from a called device 104-1, upon rejection of the call request.
15 The message may include a cause code for rejecting the call request. In an
implementation, the determination module 120 may receive the message from the
called device 104-1. Upon receiving the message, the announcement system 102
sends a request message to the SCP 108. The request message includes information
about the call request made by the calling device 104-2. Further, the determination
20 module 120 may analyze the message to determine the cause code sent by the called
device 104-1.
[0071] At block 354, the method 350 may include identifying an
announcement from a plurality of pre-defined announcements. In an implementation,
the announcement module 122 may identify the announcement. The announcement
25 module 122 may communicate with the SRF 110 to identify the announcement
corresponding to the cause code. The SRF 110 may be associated with an SRF
database (not shown). The SRF database may be configured to store various
28
announcements that may be applicable for the communication devices 104. The
announcement module 122 may read an announcement identification information
corresponding to the cause code. The announcement identification information may
include an announcement ID corresponding to the announcement that has to be
provided to the calling device 104-5 2.
[0072] Further, at block 356, the method 350 may include providing the
announcement to the calling device 104-2. The announcement corresponds to the
cause code indicated in the message. In an implementation, upon identifying the
announcement, the announcement module 122 may instruct the SRF 110 to provide
10 the announcement to the calling device 104-2.
[0073] Although embodiments for call rejection in a communication network
have been described in a language specific to structural features or method(s), it is to
be understood that the present subject matter is not necessarily limited to the specific
features or method(s) described. Rather, the specific features and methods are
15 disclosed as embodiments for call rejection in a communication network.
29
I/We claim:
1. A method for rejecting a call request, the method comprising:
indicating, by a processor (112-2), the call request from a calling
device (104-2)5 ;
rendering, by the processor (112-2), a plurality of rejection options on
an interface (114-2) of a called device (104-1), upon receiving a call rejection
command in response to indicating the call request, wherein each of the
plurality of rejection options is associated with a cause code; and
10 generating, by the processor (112-2), a message, upon receiving a
selection of a rejection option from the plurality of rejection options, wherein
the message is shared with a call rejection announcement system (102) for
being provided to the calling device (104-2).
2. The method as claimed in claim 1, wherein the indicating comprises
15 providing, upon receipt of the call request, at least a call acceptance option
and a call rejection option.
3. The method as claimed in claim 1, wherein the cause code is indicative of a
reason of rejection of the call request.
4. The method as claimed in claim 1, wherein the call request is one of an audio
20 call and a video call.
5. The method as claimed in claim 1, wherein sharing the message comprises
sending the message to a Mobile Switching Center (MSC).
6. A method for providing a call rejection announcement, the method
comprising:
30
receiving, by a processor (112-1), a message from a called device
(104-1), upon rejection of a call request, wherein the message comprises a
cause code for rejecting the call request; and
providing, by the processor (112-1), an announcement to a calling
device (104-2), wherein the announcement corresponds to the cause cod5 e
indicated in the message.
7. The method as claimed in claim 6, wherein the providing comprises
identifying the announcement from a plurality of pre-defined announcements.
8. The method as claimed in claim 6, wherein the message is received through a
10 Customized Application for Mobile networks Enhanced Logic (CAMEL)
protocol.
9. A communication device (104-1) comprising:
a processor (112-2); and
a rendering module (126), coupled to the processor (112-2), to
15 indicate a call request from a calling device (104-2);
render a plurality of rejection options on an interface (114-2),
upon receiving a call rejection command, wherein each of the
plurality of rejection options is associated with a cause code; and
a message generation module (128), coupled to the processor (112-2),
20 to generate a message, upon receiving a selection of a rejection
option, wherein the message is shared with a call rejection
announcement system (102) for being provided to the calling device
(104-2).
10. The communication device (104-1) as claimed in claim 9, wherein the cause
25 code comprises a parameter indicating a reason for the rejection of the call
request.
31
11. The communication device (104-1) as claimed in claim 9, wherein the
message further comprises a pre-defined time interval for being
communicated to the calling device (104-2), wherein the pre-defined time
interval is indicative of a time period after which a user of the calling devic5 e
(104-2) sends another call request.
12. A call rejection announcement system (102) comprising:
a processor (112-1); and
a determination module (120), coupled to the processor (112-1), to
10 receive a message from a called device (104-1), upon rejection of a call
request by the called device (104-1), wherein the message comprises a cause
code for rejecting the call request; and
an announcement module (122), coupled to the processor (112-1), to
provide an announcement to a calling device (104-2) upon receipt of the
15 message, wherein the announcement corresponds to the cause code indicated
in the message.
13. The call rejection announcement system (102) as claimed in claim 12,
wherein the determination module (120) further,
analyzes the message to determine the cause code sent by the called
20 device (104-1); and
determines the announcement, from a plurality of pre-defined
announcements, corresponding to the cause code, wherein upon
determination, the announcement is provided to the calling device (104-2).
14. The call rejection announcement system (102) as claimed in claim 12,
25 wherein the determination module (120) receives the message through a
Customized Application for Mobile networks Enhanced Logic (CAMEL)
protocol.
32
15. The call rejection announcement system (102) as claimed in claim 12,
wherein the announcement is one of an audio announcement and a video
announcement.
16. The call rejection announcement system (102) as claimed in claim 12,
wherein the announcement module (122) is associated with th5 e
communication network (106) selected from at least one of a Global System
for Mobile Communication (GSM) network, Universal Mobile
Telecommunications System (UMTS) network, Personal Communications
Service (PCS) network, Time Division Multiple Access (TDMA) network,
10 Code Division Multiple Access (CDMA) network, Next Generation Network
(NGN), IP Multimedia Subsystem (IMS) network, Public Switched
Telephone Network (PSTN), and Integrated Services Digital Network
(ISDN).
17. The call rejection announcement system (102) as claimed in claim 12,
15 wherein the providing comprises providing an audio message as a service
message.
18. A non-transitory computer-readable medium having embodied thereon a
computer program for executing a method for rejecting a call request, the
method comprising:
20 indicating, by a processor (112-2), the call request from a calling
device (104-2);
rendering, by the processor (112-2), a plurality of rejection options on
an interface (114-2) of a called device (104-1), upon receiving a call rejection
command, wherein each of the plurality of rejection options is associated
25 with a cause code; and
generating, by the processor (112-2), a message, upon receiving a
selection of a rejection option from the plurality of rejection options, wherein
33
the message is shared with a call rejection announcement system (102) for
being provided to the calling device (104-2).
19. A non-transitory computer-readable medium having embodied thereon a
computer program for executing a method for providing a call rejection
announcement, the method comprising5 :
receiving, by a processor (112-1), a message from a called device
(104-1), upon rejection of a call request, wherein the message comprises a
cause code for rejecting the call request; and
providing, by the processor (112-1), an announcement to a calling
10 device (104-2), wherein the announcement corresponds to the cause code
indicated in the message.