Calls in a cellular network are setup based on presence of a callee within a network coverage area and callee's availability to receive calls. If the callee is out of the network coverage area or communicating with a caller at an instant, a second caller trying to place a call to the callee is provided with a notification describing the callee's inability to receive other calls.
BRIEF DESCRIPTION OF DRAWINGS [0002] 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 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 which: [0003] Figure 1 illustrates components of a user equipment (UE) to determine usage thereof for determination of a callee's condition, in accordance with an example of the present subject matter, [0004] Figure 2 illustrates the components of the UE to determine the usage thereof for determination of the callee's condition, in accordance with another example of the present subject matter,
[0005] Figure 3 illustrates a method for determining the usage of the UE of the callee for determination of the callee's condition, in accordance with an example of the present subject matter, and
[0006] Figure 4 illustrates the method for determining the usage of the UE of the callee for determination of the callee's condition, in accordance with another example of the present subject matter.

DETAILED DESCRIPTION [0007] With the advent in the field of communication, notifications sent to a caller when a callee is unavailable to receive a call have also improved and have been customized to suit the situation of the callee better. In some instances, the notifications are automatically generated based on determination of callee's condition to notify the caller about the callee's situation more accurately.
[0008] The determination of callee's condition is generally done based on cellular network resources, based on which notifications are auto generated and provided to callers. For instance, when a call is placed between a caller and a callee, the cellular network, based on triangulation and latch conditions of a user equipment (UE) utilized by the callee, may determine that the callee is out of network coverage area and may accordingly send an out of coverage area notification to the caller, indicating callee's inability to receive the call. [0009] Similarly, some cellular networks allow their users to send a busy notification to callers, when the users are driving. In such situations, if the callee receives the call, location and speed of the callee are determined based on cellular network resources and if based on such determination it is determined that the callee is travelling at a motor speed, it is assumed that the callee is driving and a busy notification is sent to the client.
[0010] However, use of cellular network resources do not allow an accurate determination of callee's condition as cellular network resources fail to account for callee's accurate condition. For instance, when it is determined that the callee is travelling at a motor speed based on callee's UE's change of location and the UEs handover between one or more base stations, a notification is sent to the caller, intimating the caller that the callee is driving. However, it is possible that the callee may be driven by someone else instead of driving the

vehicle himself. Therefore, due to inaccurate determination of callee's condition, unnecessary notifications may be sent to the caller, devoiding establishment of a call between the caller and the callee. [0011] According to example implementations of the present subject matter, techniques for accurately determining a callee's condition are described.
[0012] In an example of the present subject matter, the callee's condition may be determined based on a usage of the callee's UE. The usage of the callee's UE is ascertained based on usage parameters associated therewith. Based on the ascertaining, the callee's condition is determined. Thereafter, based on the callee's condition, it is determined if the callee can receive any calls. The UE has been interchangeably referred to as 'callee's UE' and 'UE', hereinafter. Further, the callee has been interchangeably referred to as 'user' and 'callee', hereinafter.
[0013] In operation, when a call is received on the UE, the usage of the UE may be determined. The usage may be determined based on the analysis of certain usage parameters, such as a physical state of the UE, changes in the physical state of the UE, frequency of changes in the physical state of the UE, number of active applications on the UE, type of active applications, frequency of inputs received for the active applications, or a combination thereof. The usage parameters may be determined based on information received from at least one of sensors embedded in the UE and an operating system (OS) of the UE. For instance, while information related to physical state of the UE may be received from various sensors included in the UE, information related to applications running on the UE may be received from the OS. [0014] Based on the analysis of the usage parameters, the callee's condition and the callee's ability to handle calls may be determined. Further, based on the determination, the call may either be presented to the callee or a

notification indicating the callee's inability to receive the calls may be sent to the caller.
[0015] In an illustrative example, when a call is received on the UE, it may be determined that the UE has been kept in face down position. The determination that the UE has been kept face down may be made based on the readings from a proximity sensor embedded on a display of the UE. Based on the determination, it may be derived that the UE is in the do-not-disturb mode. In such a situation, other usage parameters, such as active applications on the UE, type of the active applications, and frequency of inputs being received for the active applications, may be analysed. For instance, if it is determined that a music player application is running on the UE and frequent inputs for change of songs are being received on the music player application, it may be determined the UE may have been kept face down inadvertently. In such a situation, the call may be presented on the UE. However, if it is determined that there are no active applications on the UE other than the default OS applications, it may be determined that the user has kept the UE face down intentionally. In such a situation, a notification indicating callee's inability to receive the calls may be sent to the caller.
[0016] The determination of the callee's condition based on the usage of the UE captures the callee's interaction with the UE along with the information received from the cellular network resources while determining the callee's condition. Accordingly, accuracy involved in the determination of the callee's condition is improved and transmission of any incorrect notifications, i.e., transmission of busy notifications even when the callee is available to receive calls, is avoided.
[0017] The above techniques are further described with reference to Figure 1 to Figure 4. It should be noted that the description and the figures merely illustrate the principles of the present subject matter along with examples

described herein and should not be construed as a limitation to the present subject matter. It is, thus understood that various arrangements may be devised that although not explicitly described or shown herein, embody the principles of the present subject matter. Moreover, all statements herein reciting principles, aspects, and implementations of the present subject matter, as well as specific examples thereof, are intended to encompass equivalents thereof.
[0018] Figure 1 illustrates components of a user equipment (UE) 100 to determine a usage thereof for determination of a callee's condition, in accordance with an example of the present subject matter. Examples of UE 100 may include, but are not limited to, smartphones, tablets, personal digital assistants, and laptops. The UE 100 may be used by a user to make and receive calls, such as voice calls or video calls.
[0019] In an example implementation of the present subject matter, the UE 100 includes a determination engine 102 for determining usage of the UE 100. The determination engine 102 may determine the usage of the UE based on certain usage parameters, such as a physical state of the UE, changes in the physical state of the UE, frequency of changes in the physical state of the UE, number of active applications on the UE, type of active applications, frequency of inputs received for the active applications, or a combination thereof. [0020] The UE 100 further includes an analysis engine 104 coupled to the determination engine 102. The analysis engine 104 may analyse the usage parameters to determine whether the callee is available to receive calls or not. [0021] Based on the determination, a communication engine 106 included in the UE 100 determines if the call is to be presented to the user. If the analysis engine 104 determines that the callee is available to receive calls, the communication engine 106 may present the call on the UE 100. On the other hand, if the analysis engine 104 determines that the callee cannot receive calls

at the moment, the communication engine 106 may send a notification to the caller indicating caller's inability to receive calls at the moment. [0022] The manner in which the callee's condition is determined is described in detail with respect to the forthcoming figures. [0023] Figure 2 illustrates the components of the UE 100 to determine a usage thereof for determination of the callee's condition, in accordance with another example of the present subject matter.
[0024] The UE 100 may include a processor 202 and a memory 204 coupled to the processor 202. The functions of the various elements shown in the figures, including any functional blocks labelled as "processor(s)", may be provided through the use of dedicated hardware as well as hardware capable of executing instructions. 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" would not be construed to refer exclusively to hardware capable of executing instructions, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA). Other hardware, standard and/or custom, may also be coupled to processor 202.
[0025] The memory 204 may include any computer-readable medium including, for example, volatile memory (e.g., Random Access Memory (RAM)), and/or non-volatile memory (e.g., ROM, EPROM, flash memory, etc.). [0026] Further, the UE 100 may also include engine(s) 206, which may include the determination engine 102, the analysis engine 104, and the communication engine 106.
[0027] In an example, the engine(s) 206 may be implemented as a hardware, firmware and a combination thereof. In examples described herein,

such combinations of hardware and firmware may be implemented in several different ways. For example, the firmware of the engine may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the engine may include a processing resource (for example, implemented as either a single processor or a combination of multiple processors), to execute such instructions.
[0028] In accordance with implementations of the present subject matter, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the functionalities of the engine. In such implementations, the UE 100 may include the machine-readable storage medium for storing the instructions and the processing resource to execute the instructions.
[0029] In an example of the present subject matter, machine-readable storage medium may be located within the UE 100. However, in other examples, the machine-readable storage medium may be located at a different location but accessible to UE 100 and the processor 202. [0030] The UE 100 may further include data 208, that serves, amongst other things, as a repository for storing data that may be fetched, processed, received, or generated by the engine(s) 206. The data 208 may include determination data 210, analysis data 212, communication data 214, and other data 216. In an example, the data 210 may be stored in the memory 204. [0031] In an example implementation of the present subject matter, the determination engine 102 may detect reception of a call on the UE 100. In such a situation, the determination engine 102 may determine the callee's condition and accordingly, may determine if the callee is available to receive calls. The determination may be made based on the usage of the UE 100. [0032] It would be noted that while the afore-mentioned subject matter describes that the determination engine 102 determines the usage of the UE

upon reception of the call, the determination engine 102 may also continuously monitor the usage irrespective of the calls being received on the UE 100. [0033] As explained earlier, the determination engine 102 may determine the usage of the UE 100 based on certain usage parameters, such as a physical state of the UE, changes in the physical state of the UE, frequency of changes in the physical state of the UE, number of active applications on the UE, type of active applications, frequency of inputs received for the active applications, or a combination thereof. In an example, the determination engine 102 may store the determined usage parameters in the analysis data 212. [0034] The determination engine 102 may determine the usage parameters based on the information received from various sensors included in the UE, an operating system (OS) of the UE, and the processor 202. For instance, the determination engine 102 may obtain the information related to physical state of the UE, changes in the physical state of the UE, and frequency of changes in the physical state of the UE from the sensors included in the UE. Examples of such sensors include, but are not limited to, gyro sensor, proximity sensor, fingerprint sensor, and accelerator. Further, the determination engine 102 may obtain information related to the number of active applications, type of the active applications, and the frequency of inputs received for the active applications either from the OS or the processor 202.
[0035] The analysis engine 104 may then access the analysis data 212 and fetch the usage parameters stored therein. The analysis engine 104 may then analyse the fetched usage parameters. Based on the analysis, the analysis engine 104 may deduce the callee's condition and may accordingly determine the callee's ability to receive incoming calls. Based on the deduction, the communication engine 106 may either allow the calls to be presented to the callee or may send a notification to the caller indicating the callee's inability to receive calls. In an example, the notification may also include contextual

information, such as a reason for callee's inability to answer calls at the moment. In said example, a call log of the UE 100 may be updated to include a missed call from the caller.
[0036] In an illustrative example, when a call is received, the determination engine 102 may determine the callee to be in a moving vehicle. The determination engine 102 may determine the callee to be in the moving vehicle based on information obtained from a global positioning sensor (GPS) embedded in the UE 100. Alternatively, the determination engine 102 may determine the callee to be in the moving vehicle based on the UE's handover between multiple base stations.
[0037] The analysis engine 104 may then access the analysis data 212 and fetch usage parameters stored therein. If it is determined that the callee is actively using the UE 100 while travelling in the vehicle, the analysis engine 104 may deduce that the callee is either travelling in public transport or being driven by someone else. For instance, if the analysis engine 104 determines that the callee is using an instant messaging application, where the callee is actively providing inputs through a keyboard, the analysis engine 104 may determine that the callee is involved in an active chat with someone. In such a situation, the analysis engine 104 may indicate to the communication engine 106 that the callee is available to receive calls.
[0038] On the other hand, if the analysis engine 104 determines that the callee is not actively interacting with the UE 100, the analysis engine 104 may deduce that the callee is driving the vehicle. For instance, if the analysis engine 104 determines that a music player application and a navigation application are active on the UE 100 and the input received on the UE are only for changing of songs or adjustment of a route on the navigation application, the analysis engine 104 may determine that the callee is not actively interacting with the UE. In such a situation, the analysis engine 104 may also identify an orientation

of the UE along with the frequency of changes in orientation to ascertain that the UE is not being actively used by the callee. In such a situation, the analysis engine 104 may indicate to the communication engine 106 that the callee may not be able to receive any calls.
[0039] Based on the indication, the communication engine 106 may either allow the calls to be presented to the callee or may send a notification to the caller indicating the callee's inability to receive calls. In an example, the busy notification may also include contextual information, such as a reason for callee's ability to answer calls at the moment, i.e., callee's driving status. In said example, a call log of the UE 100 may be updated to include a missed call from the caller.
[0040] In an example, the analysis engine 104 may also store the callee's condition, i.e., information indicating whether the callee is driving or being driven in a database on a communication network. Such a database may be kept in association with a mobile switching centre (MSC) (not shown) and may be similar to that of a Visitor Location Register (VLR). In an example, instead of storing the callee's condition on a database separate from VLR, the contents of the VLR may be augmented to include the callee's condition along with location of UEs present in a service area of the MSC. Accordingly, the calls which are directed to the UE 100 may be evaluated against the callee's condition at the MSC before being routed. As a result, when the callee is not available to receive calls, the calls may not be routed to the UE 100, thereby reducing the consumption of network resources involved in routing of calls between UEs.
[0041] The determination engine 102 may further allow creation of an exception list, where calls from the callers whose contact details are included in the exception list may be presented to the callee irrespective of the callee's condition.

[0042] Figure 3 and Figure 4 illustrate methods 300 and 400 for determining the usage of the UE of the callee for determination of the callee's condition, in accordance with example implementations of the present subject matter. Although the methods 300 and 400 may be implemented in a variety of computing devices, but for the ease of explanation, the description of the exemplary methods 300 and 400 is provided in reference to the above-described UE 100. The order in which the methods 300 and 400 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 300, or an alternative method.
[0043] It may be understood that blocks of the methods 300 and 400 may be performed in the UE 100. The blocks of the methods 300 and 400 may be executed based on instructions stored in a non-transitory computer-readable medium, as will be readily understood. The non-transitory computer-readable medium may include, for example, digital memories, magnetic storage media, such as magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.
[0044] At block 302, usage of the UE may be determined. The usage of the UE may be determined based on analysis of various usage parameters associated with the UE, such as a physical state of the UE, changes in the physical state of the UE, frequency of changes in the physical state of the UE, number of active applications on the UE, type of active applications, frequency of inputs received for the active applications, or a combination thereof. In an example, the usage of the UE may be determined by a determination engine 102 of the UE 100.
[0045] At block 304, the usage parameters may be analysed to determine a callee's condition. Based on the determined callee's condition, it may be

determined if the callee can receive calls at the moment. In an example, the usage parameters may be analysed by an analysis engine 104 of the UE 100. [0046] At block 306, based on the determination of the callee's condition and the callee's ability to receive the calls, the calls may be presented to the callee. In an example, the calls may be presented by a communication engine 106 of the UE 100.
[0047] Figure 4 illustrates the method 400 for determining the usage of the UE of the callee for determination of the callee's condition, in accordance with another example implementation of the present subject matter. [0048] At block 402, it is determined if a callee is travelling at a motor speed. The determination may be made in response to reception of a call on the UE being used by the callee. The determination may be made in a number of ways. In an example, the determination may be made using a global positioning sensor (GPS) included in the UE. In another example, the determination may be made based on the UE's handover between multiple base stations. The determination that the callee is driving at the motor speed may be made by the determination engine 102.
[0049] At block 404, the usage of the UE may be determined. The usage may be determined in response to the determination that the callee is travelling at the motor speed. The usage of the UE may be determined based on various usage parameters associated with the UE, such as a physical state of the UE, changes in the physical state of the UE, frequency of changes in the physical state of the UE, number of active applications on the UE, type of active applications, frequency of inputs received for the active applications, or a combination thereof. In an example, the usage of the UE may also be determined by the determination engine 102.
[0050] At block 406, the usage parameters may be analysed to identify callee's condition. In an example, the identification of the callee's condition may

include identifying whether the callee is driving or non-driving. In said example, the callee's condition may also be stored in a database on the network. Such a database may be kept in association with a mobile switching centre (MSC) and may be similar to that of a Visitor Location Register (VLR). In an example, the usage parameters may be analysed and the identified callee's condition may be stored in the database by analysis engine 104. [0051] At block 408, based on the identified callee's condition, it may be determined if calls are to be presented to the callee. In an example, if the callee's condition is identified to be driving, a notification indicating the callee's inability to receive calls may be sent to a caller. In said example, if the callee's condition is identified to non-driving, the calls may be presented to the callee. The determination of whether the calls are to be presented to the callee or not is made by the communication engine 106.
[0052] The determination of the callee's condition based on the usage of the UE captures the callee's interaction with the UE while the callee is travelling at the motor speed. Accordingly, the techniques explained supra facilitates accurate determination of the callee's condition, i.e., whether the callee is driving or being driven. As a result, transmission of any incorrect notifications, i.e., transmission of busy notifications even when the callee is available to receive calls, is avoided.
[0053] Although implementations of the present subject matter have been described in language specific to methods and/or structural features, it is to be understood that the present subject matter is not limited to the specific methods or features described. Rather, the methods and specific features are disclosed and explained as example implementations of the present subject matter.

I/We Claim:

1. A method comprising:
analysing a plurality of usage parameters associated with a User Equipment (UE), wherein the plurality of usage parameters is indicative of usage of the UE by a callee;
determining a callee's condition based on the analysis of the plurality of usage parameters;
presenting calls to the callee based on the callee's condition.
2. The method as claimed in claim 1, further comprising updating the callee's condition on a database kept in association with a Mobile Switching Centre (MSC) in a communication network.
3. The method as claimed in claim 1, wherein the plurality of communication parameters comprises a physical state of the UE, changes in the physical state of the UE, frequency of changes in the physical state of the UE, number of active applications on the UE, type of active applications, frequency of inputs received for the active applications, or a combination thereof.
4. The method as claimed in claim 1, wherein the plurality of usage parameters is analysed on determining the UE to be within a moving vehicle.
5. The method as claimed in claim 1, wherein the plurality of usage parameters is analysed on reception of a call on the UE.
6. The method as claimed in claim 1, further comprising:
determining the callee's condition to be driving; and

transmitting a notification indicating inability of the callee to receive calls based on determining the callee's condition to be driving.
7. The method as claimed in claim 6, further comprising updating a call log of the UE to include missed calls corresponding to the calls based on determining the callee's condition to be driving.
8. The method as claimed in claim 1, further comprising presenting the calls to the callee on determining the callee's condition to be non-driving.
9. A user equipment (100) comprising:
an analysis engine (104) to:
analyse a plurality of usage parameters associated with a User Equipment (UE), wherein the plurality of usage parameters is indicative of usage of the UE by a callee; and
determine a callee's condition based on the analysis of the plurality of user parameters; and
a communication engine (106) coupled to the analysis engine (104) to present calls to the callee based on the callee's condition.
10. The user equipment (100) as claimed in claim 8, wherein the communication engine (106) is to update the condition of the user on a database kept in association with a Mobile Switching Centre (MSC) in a communication network.
11. The user equipment (100) as claimed in claim 8, wherein the plurality of communication parameters comprises a physical state of the UE, changes in the physical state of the UE, frequency of changes in the physical state of the

UE, number of active applications on the UE, type of active applications, frequency of inputs received for the active applications, or a combination thereof.
12. The user equipment (100) as claimed in claim 8, further comprising a determination engine (102) to determine the UE to be in a moving vehicle, wherein the determination engine (102) is to cause the analysis engine (104) to analyse the plurality of usage parameters on determining the UE to be in the moving vehicle.
13. The user equipment as claimed in claim 1, wherein the analysis engine (104) is to analyse the plurality of usage parameters on reception of a call on the UE.
14. The user equipment (100) as claimed in claim 1, wherein the analysis engine (104) is to:
determine the callee's condition to be driving; and
cause the communication engine to transmit a notification indicating the inability of the callee to receive calls based on determining the callee's condition to be driving.
15. The user equipment (100) as claimed in claim 6, wherein the
communication engine (106) is to update a call log of the UE to include missed
calls corresponding to the calls based on determining the callee's condition to
be driving.