DESCRIPTION
TECHNICAL FIELD
The invention generally relates to providing information about a user on mobile device. More particularly, the invention relates to transmission of status information of a called user to a calling mobile device and profile information of a calling user to a called mobile device.

BACKGROUND
Generally, when a first user (hereinafter referred to as calling user) calls a second user (hereinafter referred to as called user), the called user may not be in a position to receive the call from the calling user at the time of the call. In such scenario, the called user manually informs the calling user either by sending messages such as short messaging service (SMS) messages or by rejecting the call. However, the use of such messages increases dependency on cellular network operator and increases traffic on cellular network. Further, details of the calling user are displayed on a mobile device of the called user. However, such display of the details of the calling user is dependent upon details saved by the called user in a contact list. In such scenario, the details of the calling user include a mobile number and a name of the calling user. Further, the display is restricted only to a mobile number of the calling user if the details of the calling user are unavailable in the contact list of the called user. Thus, the call from the calling user may remain unanswered.
In addition, users opt for missed call alert service and voice mail service provided by the cellular network operator. Accordingly, the called user receives a missed call alert via SMS from the cellular network operator in event of a mobile device of the called user is unable to receive the call. Similarly, the cellular network operator directs the calling user to a voice mailbox of the called user when the call remains unanswered. However, both the services do not transmit the status information to the calling user and the profile information to the called user. In addition, both the services require a subscription fee payable by the called user. Moreover, the calling user also pays normal call charges upon directed to the voice mailbox. Additionally, both the services increase the traffic on the cellular network.
To address these deficiencies, some conventional techniques are available for transmitting the status information of called user and the profile information of the calling user. In one conventional technique, status of the called user is transmitted to the calling user only if the called user has set the status as ‘not available’ when a call set-up request is placed by the calling user. However, in such case, the call is not established between the calling user and the called user.
In another conventional technique, the calling user and the called user invoke a notification service by sending a request to the network to notify when the called user is available to accept the call, such as when a mobile deice of the called device is switched on and when the mobile device is within the network coverage. The network notifies the calling user about unavailability of the called user and notifies the called user about attempted call by the calling user when the calling user attempts to call the user. The network also notifies the calling user later when the called user is available to accept the call. However, in this technique, the calling user and the called user have to invoke the service each time a call is attempted. In addition, the notification only provides status of the mobile device of the called user and not the status of the called user.
In one other conventional technique, status of the called user is transmitted to the calling user only if the call to the called user remains unanswered. In one another conventional technique, status of the called user is transmitted when a setting of the called mobile device is one of vibrate mode, silent mode, conference mode, and/or either the called mobile device is in roaming. However, both the techniques do not provide the status of the called user and the profile of the calling user. In yet one another conventional technique, signatures of the calling user and the called user are shared or transmitted when a call is attempted by the calling user. However, this technique requires the called user to update the status information manually to inform a change in status information to all users. In addition, this technique does not provide flexibility to the called user to allow only specific caller to call the called user.
Further, various applications are available for providing status of called user and profile of calling user. One application such as True Caller provides a name of the calling user. However, the displayed name of the calling user is a name saved in a contact list of a third user and is not a name set by the calling user. Another application requires availability of data connection and smart mobile phones for displaying status of called user and profile of calling user. Yet another application provides setting of ring back tone (RBT) specific to a status message. However, such RBT service is limited to network operators.
Thus, the present solutions or techniques do not enable users to set and share personalized profile information and personalized status information without the need for data connection. Further, the present solutions do not transmit the status information and profile information as set by the user in real time, i.e., when a call set up request is made, without checking for device status or setting of mobile devices. Additionally, some of the solutions prevent establishment of the call based on the status. Further, the present solutions do not provide the flexibility to user to allow or prevent other users from calling them after the personalized profile information and personalized status information are transmitted with the other users.

SUMMARY OF THE INVENTION
In accordance with the purposes of the invention, the present invention as embodied and broadly described herein, provides for status information of a called user to a calling mobile device and transmission of profile information of a calling user to a called mobile device.
Accordingly, a calling mobile device transmits a call set-up request for establishing a call with a called mobile device to a mobile switching centre (MSC). The MSC receives the call set-up request and transmits a request for status information set by a user of the called mobile device to a status information sharing server (SISS). Upon receiving the request from the MSC, the SISS retrieves the status information set by the user of the called mobile device from a database. The status information includes a time period for which the status information is valid. The SISS also retrieves either call allowance information or an authorized contact list associated with the status information. Upon retrieving the status information, the SISS generates a push message including either the retrieved the status information or locally derived modified status information based on the time period. The SISS then transmits the push message to a push message gateway communicatively coupled to the calling mobile device such that the push message gateway transmits the push message for display on the calling mobile device. Further, the SISS transmits an instruction message to the MSC based on either of the call allowance information or the authorized contact list. Based on the instruction message, the MSC manages the call between the calling mobile device and the called mobile device.
Similarly, upon receiving the call set-up request, the MSC transmits a request for profile information set by a user of the calling mobile device to a profile information sharing server (PISS). Upon receiving the request from the MSC, the PISS retrieves the profile information set by the user of the calling mobile device from a database. The profile information can be either general profile information set for all users or specific profile information set for a user of the called mobile device. Upon retrieving the profile information, the PISS determines at least one call control option. Thereafter, the PISS generates a push message including the profile information and the at least one call control option. The PISS then transmits the push message to a push message gateway communicatively coupled to the called mobile device such that the push message gateway transmits the push message for display on the called mobile device. Further, the PISS transmits an instruction message to the MSC. Based on the instruction message, the MSC manages the call between the calling mobile device and the called mobile device.
The advantages of the invention include, but not limited to, transmitting push messages to provide status information and profile information to mobile devices in real time, i.e., when a call set up request is made by mobile devices. The use of push messages eliminates the need for a data connection by the mobile devices for sharing and receiving of status information and profile information. Further, the push messages are transmitted independent of device status of the mobile devices of calling user and called user. This enables users to receive the status information and profile information as set by other users; therefore, the users are able to make conscious decisions of accepting the call and rejecting the call. Further, instruction message for enabling the MSC to establish the call is transmitted along with the transmission of push messages, thereby separating the status information and the profile information from the establishment of call. This enables the user to make a call or receive a call irrespective of the status information and the profile information set by other user.
Additionally, the user is able to set status information along with a time period, which indicates a time until which the status information is valid. As such upon expiry of the time period, the status information is automatically updated by the server. This eliminates the need to update the status information manually by the user. In addition to setting up status information, the user can set call allowance information and authorized contact list. This provides the user a flexibility to define when and who can call the user. Similarly, the user is able to set either general profile information for multiple users or specific profile information for specific users, thereby providing flexibility to the user to personalize the profile information as desired.
Furthermore, traffic is reduced on the cellular network, as a calling user may refrain from further calling a called user upon viewing the status information of the called user as unavailable and the called user may refrain from sending messages. This further reduces the cost involved in sending messages to the calling user, and subscribing to the voice mail service and missed call alerts service by the called user. In addition, a considerable reduction on dependency on the cellular network operator is achieved. Furthermore, as the profile set by the calling user is visible to the called user, the called user is able to make conscious decisions of accepting the call and rejecting the call.
These and other aspects as well as advantages will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS:
To further clarify advantages and aspects of the invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings, which are listed below for quick reference.
Figure 1a illustrates an exemplary method implemented by a status information sharing server for transmission of status information to a calling mobile device, in accordance with an embodiment of present invention.
Figures 1b and 1c illustrate exemplary methods for including further information in the status information, in accordance with an embodiment of present invention.
Figure 2 illustrates an exemplary method implemented by a profile information sharing server for transmission of profile information to a called mobile device, in accordance with an embodiment of present invention.
Figure 3 illustrates an exemplary status information sharing server for transmission of status information to calling mobile device, in accordance with an embodiment of present invention.
Figure 4 illustrates an exemplary profile information sharing server for transmission of profile information to a called mobile device, in accordance with an embodiment of present invention.
Figure 5 illustrates an exemplary method implemented by a mobile switching centre for transmission of status information, in accordance with an embodiment of present invention.
Figure 6 illustrates an exemplary method implemented by a mobile switching centre for transmission of profile information, in accordance with an embodiment of present invention.
Figure 7 illustrates an exemplary flow diagram for registering with a server to set status information and profile information, in accordance with an embodiment of present invention.
Figures 8a-8d illustrate exemplary flow diagrams for setting of status information and profile information, and receiving of status information and profile information, in accordance with an embodiment of present invention.
Figure 9 illustrates an exemplary flow diagram for transmission of status information to a calling mobile device and profile information to a called mobile device, in accordance with an embodiment of present invention.
It may be noted that to the extent possible, like reference numerals have been used to represent like elements in the drawings. Further, those of ordinary skill in the art will appreciate that elements in the drawings are illustrated for simplicity and may not have been necessarily drawn to scale. For example, the dimensions of some of the elements in the drawings may be exaggerated relative to other elements to help to improve understanding of aspects of the invention. Furthermore, the one or more elements may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.

DETAILED DESCRIPTION
It should be understood at the outset that although illustrative implementations of the embodiments of the present disclosure are illustrated below, the present invention may be implemented using any number of techniques, whether currently known or in existence. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
The term ‘some’ as used herein is defined as ‘none, or one, or more than one, or all.’ Accordingly, the terms ‘none,’ ‘one,’ ‘more than one,’ ‘more than one, but not all’ or ‘all’ would all fall under the definition of ‘some.’ The term ‘some embodiments’ may refer to no embodiments or to one embodiment or to several embodiments or to all embodiments. Accordingly, the term ‘some embodiments’ is defined as meaning ‘no embodiment, or one embodiment, or more than one embodiment, or all embodiments.’
The terminology and structure employed herein is for describing, teaching and illuminating some embodiments and their specific features and elements and does not limit, restrict or reduce the spirit and scope of the claims or their equivalents.
More specifically, any terms used herein such as but not limited to ‘includes,’ ‘comprises,’ ‘has,’ ‘consists,’ and grammatical variants thereof do NOT specify an exact limitation or restriction and certainly do NOT exclude the possible addition of one or more features or elements, unless otherwise stated, and furthermore must NOT be taken to exclude the possible removal of one or more of the listed features and elements, unless otherwise stated with the limiting language ‘MUST comprise’ or ‘NEEDS TO include.’
Whether or not a certain feature or element was limited to being used only once, either way it may still be referred to as ‘one or more features’ or ‘one or more elements’ or ‘at least one feature’ or ‘at least one element.’ Furthermore, the use of the terms ‘one or more’ or ‘at least one’ feature or element do NOT preclude there being none of that feature or element, unless otherwise specified by limiting language such as ‘there NEEDS to be one or more . . . ‘ or ‘one or more element is REQUIRED.’
Unless otherwise defined, all terms, and especially any technical and/or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having an ordinary skill in the art.
Reference is made herein to some ‘embodiments.’ It should be understood that an embodiment is an example of a possible implementation of any features and/or elements presented in the attached claims. Some embodiments have been described for the purpose of illuminating one or more of the potential ways in which the specific features and/or elements of the attached claims fulfil the requirements of uniqueness, utility and non-obviousness.
Use of the phrases and/or terms such as but not limited to ‘a first embodiment,’ ‘a further embodiment,’ ‘an alternate embodiment,’ ‘one embodiment,’ ‘an embodiment,’ ‘multiple embodiments,’ ‘some embodiments,’ ‘other embodiments,’ ‘further embodiment’, ‘furthermore embodiment’, ‘additional embodiment’ or variants thereof do NOT necessarily refer to the same embodiments. Unless otherwise specified, one or more particular features and/or elements described in connection with one or more embodiments may be found in one embodiment, or may be found in more than one embodiment, or may be found in all embodiments, or may be found in no embodiments. Although one or more features and/or elements may be described herein in the context of only a single embodiment, or alternatively in the context of more than one embodiment, or further alternatively in the context of all embodiments, the features and/or elements may instead be provided separately or in any appropriate combination or not at all. Conversely, any features and/or elements described in the context of separate embodiments may alternatively be realized as existing together in the context of a single embodiment.
Any particular and all details set forth herein are used in the context of some embodiments and therefore should NOT be necessarily taken as limiting factors to the attached claims. The attached claims and their legal equivalents can be realized in the context of embodiments other than the ones used as illustrative examples in the description below.
Figure 1a illustrates an exemplary method (100) implemented by a status information sharing server (SISS) for transmission of status information to a calling mobile device, in accordance with an embodiment of present invention. In said embodiment, the method (100) comprises: receiving (101), by a request receiving unit, a request for status information set by user of a called mobile device from a mobile switching centre (MSC), the MSC sending the request upon receiving a call set-up request from the calling mobile device to establish a call with the called mobile device; accessing (102), by a processor, a database operatively coupled to the SISS, to retrieve a status information and either of a call allowance information or an authorised contact list, the status information indicating a time period of validity of the status information; generating (103), by a message generating unit, a push message including either the retrieved status information or a modified status information as locally derived based on the time period; and transmitting (104), by a message transmitting unit: the push message to a push message gateway communicatively coupled to the calling mobile device, thereby enabling the push message gateway to transmit the push message to the calling mobile device; and an instruction message to the MSC based on either of the call allowance information or the authorized contact list, thereby enabling the MSC to manage the call between the calling mobile device and the called mobile device.
In a further embodiment, the request for status information is sent by the MSC upon determining the user of the called mobile device is a subscriber of a status information sharing service provided by the SISS.
In a further embodiment, the modified status information is locally derived, by the processor, by modifying the status information with blank status information upon expiry of the time period.
In a further embodiment, the status information is set by the user of called mobile device through one of: one or more unstructured supplementary service data (USSD) codes exchanged with the SISS, one or more short codes exchanged with the SISS, one or more short message service (SMS) messages exchanged with the SISS, and one or more inputs provided by the user in response to instruction associated with an interactive voice response (IVR) menu provide by the SISS.
In a further embodiment, the push message is one of an unstructured supplementary service data (USSD) push message, a USSD flash message, and a short message service (SMS) push message.
In a further embodiment, the transmission of the push message is independent of a device status of the called mobile device.
In a further embodiment, the call allowance information is indicative of allowing establishment of the call with the called mobile device during the time period, the call allowance information being set by the user of the called mobile device.
In a further embodiment, the authorised contact list is indicative of one or more users including a user of the calling mobile device authorized to call the user of called mobile device during the time period, the authorised contact list being set by the user of the called mobile device.
Figures 1b illustrates the exemplary method (100) for including further information in the status information, in accordance with an embodiment of present invention. In said embodiment, upon retrieving the authorised contact list the method (100) further comprises: determining (105), by the processor, at least one call control function; generating (106), by the message generating unit, the push message with the at least one call control function; and transmitting (107), by the message transmitting unit: the push message including the at least one call control function to the push message gateway; and the instruction message to the MSC based on a response to the at least one call control function from a user of the calling mobile device.
Figure 1c illustrates the exemplary method (100) for including further information in the status information, in accordance with an embodiment of present invention. In said embodiment, the method (100) comprises: determining (108), by the processor, a roaming information associated with the called mobile device upon receiving the request for status information; and generating (109), by the message generating unit, the push message with the roaming information.
Figure 2 illustrates an exemplary method (200) implemented by a profile information sharing server (PISS) for transmission of profile information to a called mobile device, in accordance with an embodiment of present invention. In said embodiment, the method (200) comprises: receiving (201), by a request receiving unit, a request for profile information set by a user of a calling mobile device from a mobile switching centre (MSC), the MSC sending the request upon receiving a call set-up request from the calling mobile device to establish a call with the called mobile device; accessing (202), by a processor, a database operatively coupled to the PISS, to retrieve a profile information set by the user of the calling mobile device; determining (203), by a processor, at least one call control function upon retrieving the profile information; generating (204), by a message generating unit, a push message including the profile information and the at least one call control function; and transmitting (205), by a message transmitting unit: the push message to a push message gateway communicatively coupled to the called mobile device, thereby enabling the push message gateway to transmit the push message to the called mobile device; and an instruction message to the MSC, thereby enabling the MSC to manage the call between the calling mobile device and the called mobile device.
In further embodiment, the request for profile information is sent by the MSC upon determining the user of the calling mobile device is a subscriber of a profile information sharing service provided by the PISS.
In further embodiment, the profile information is generic profile information set by the user of the calling mobile device.
In further embodiment, the profile information is specific profile information set for a user of the called mobile device by the user of the calling mobile device.
In further embodiment, the profile information is set by the user of the calling mobile device through one of: one or more unstructured supplementary service data (USSD) codes exchanged with the PISS, one or more short codes exchanged with the SISS, one or more short message service (SMS) messages exchanged with the SISS, and one or more inputs provided by the user in response to instruction associated with an interactive voice response (IVR) menu provided by the PISS.
In further embodiment, the at least one call control function includes call forwarding to a mobile number, sending a message, and notifying later.
In further embodiment, the push message is one of an unstructured supplementary service data (USSD) push message, a USSD flash message, and a short message service (SMS) push message.
Figure 3 illustrates an exemplary status information sharing server (SISS) (300) for transmission of status information to a calling mobile device (301), in accordance with an embodiment of present invention. As would be understood, the SISS (300) is capable of implementing the methods as described with reference to preceding figures 1a to 1c.
In one embodiment, the SISS (300) comprises: a request receiving unit (302) to receive a request for status information set by a user of a called mobile device (303) from a mobile switching centre (MSC) (304), the MSC (304) sending the request upon receiving a call set-up request from the calling mobile device (301) to establish a call with the called mobile device (303); a processor (305) coupled to the request receiving unit (302) and a database (306), the processor (305) being adapted to: retrieve a status information set by the user from the database (306), the status information indicating a time period of validity of the status information; and retrieve either of a call allowance information or an authorised contact list set by the user of the called mobile device (303); a message generating unit (307) coupled to the processor (305) to generate a push message including either the retrieved status information or a modified status information as locally derived based on the time period; and a message transmitting unit (308) coupled to the processor (305) and to the message generating unit (307), the message transmitting unit (308) adapted to transmit: the push message to a push message gateway (309) communicatively coupled to the calling mobile device (301), thereby enabling the push message gateway (309) to transmit the push message to the calling mobile device (301); and an instruction message to the MSC (304) based on one of the call allowance information and the authorised contact list, thereby enabling the MSC (304) to manage the call between the calling mobile device (301) and the called mobile device (303).
In a further embodiment, the message generating unit (307) is further adapted to locally derive the modified status information by modifying the status information with blank status information upon expiry of the time period.
In a further embodiment, the status information is set by the user of the called mobile device (303) through one of: one or more unstructured supplementary service data (USSD) codes exchanged with the SISS (300), one or more short codes exchanged with the SISS, one or more short message service (SMS) messages exchanged with the SISS, and one or more inputs provided by the user in response to instruction associated with an interactive voice response (IVR) menu provided by the SISS.
In a further embodiment, wherein the push message is one of an unstructured supplementary service data (USSD) push message, a USSD flash message, and a short message service (SMS) push message.
In a further embodiment, the message transmitting unit (308) transmits the push message independent of a device status of the called mobile device (303).
In a further embodiment, the call allowance information is indicative of allowing establishment of the call with the called mobile device (303) during the time period.
In a further embodiment, the authorised contact list indicative of one or more users including a user of the calling mobile device (301) authorized to call the user of called mobile device (303) during the time period.
In a further embodiment, upon retrieving the authorised contact list: the processor (305) further: determines at least one call control function; the message generating unit (307): generates the push message with the at least one call control function; and the message transmitting unit (308) transmits: the push message including the at least one call control function to the push message gateway (309); and the instruction message to the MSC (304) based on a response to the at least one call control function from a user of the calling mobile device (301).
In a further embodiment, the processor (305) further determines roaming information associated with the called mobile device (303) upon receiving the request for status information; and the message generating unit (307) generates the push message including the roaming information.
Although specific hardware components have been depicted in reference to the SISS (300), it is to be understood that the SISS (300), the MSC (304), the push message gateway (309), the calling mobile device (301), and the called mobile device (303) may include other hardware components as known in the art for performing necessary functions.
Figure 4 illustrates an exemplary profile information sharing server (PISS) (400) for transmission of profile information to a called mobile device (401), in accordance with an embodiment of present invention. As would be understood, the PISS (400) is capable of implementing the methods as described with reference to preceding Figure 2.
In one embodiment, the PISS (400) comprises: a request receiving unit (402) to receive a request for profile information set by a user of a calling mobile device (403) from a mobile switching centre (MSC) (404), the MSC (404) sending the request upon receiving a call set-up request from the calling mobile device (403) to establish a call with the called mobile device (401); a processor (405) coupled to the request receiving unit (402) and a database (406), the processor (405) being adapted to: retrieve the profile information set by the user from the database (406); and determine at least one call control function; a message generating unit (407) coupled to the processor (405) to: generate a push message including the profile information and the at least one call control function; and a message transmitting unit (408) coupled to the message generating unit (407) and the processor (405), the message transmitting unit (408) being adapted to transmit: the push message to a push message gateway (409) communicatively coupled to the called mobile device (401), thereby enabling the push message gateway (409) to transmit the push message to the calling mobile device (401); and an instruction message to the MSC (404), thereby enabling the MSC (404) to manage the call between the calling mobile device (403) and the called mobile device (401).
In a further embodiment, the profile information is generic profile information set by the user of the calling mobile device (403).
In a further embodiment, the profile information is specific profile information set for a user of the called mobile device (401) by the user of the calling mobile device (403).
In a further embodiment, the profile information is set by the user of the calling mobile device (403) through one of: one or more unstructured supplementary service data (USSD) codes exchanged with the PISS (400), one or more short codes exchanged with the SISS, one or more short message service (SMS) messages exchanged with the SISS, and one or more inputs provided by the user in response to instruction associated with an interactive voice response (IVR) menu provided by the PISS.
In a further embodiment, the push message is one of an unstructured supplementary service data (USSD) push message, a USSD flash message, and a short message service (SMS) push message.
In a further embodiment, the at least one call control function includes call forwarding to a preconfigured mobile number, sending a message, and notifying later.
Although specific hardware components have been depicted in reference to the PISS (400), it is to be understood that the PISS (400), the MSC (404), the push message gateway (409), the calling mobile device (403), and the called mobile device (401) may include other hardware components as known in the art for performing necessary functions.
Further, although the above description states that the SISS (300) implements the method described in Figures 1a to 1c, and the PISS (400) implements the method described in Figure 2, it is to be understood that a single server can be adapted to implement the methods described in Figures 1a to 1c and Figure 2.
Furthermore, it would be understood that communication between the SISS (300), the PISS (400), the MSC (304, 404), the push message gateway (309, 409), the calling mobile device (301, 403), and the called mobile device (303, 401) takes place over a radio communication network.
Figure 5 illustrates an exemplary method (500) implemented by a mobile switching centre (MSC) for transmission of status information, in accordance with an embodiment of present invention. In said embodiment, the method (500) comprises: receiving (501), by a call set-up unit, a request from a calling mobile device to establish a call with a called mobile device; determining (502), by a call processing unit, the called mobile device is a subscriber of a status information sharing service; transmitting (503), by a request transmitting unit, a request for a status information of a user of the called mobile device to a status information sharing server (SISS) upon the determination, thereby enabling the SISS to transmit a push message including either a status information or a modified status information of the user of the called mobile device to a push message gateway communicatively coupled to the calling mobile device; receiving (504), by a message handling unit, an instruction message from the SISS, the instruction message being sent by the SISS based on either of a call allowance information or an authorised contact list set by the user of the called mobile device; and managing (505), by the call processing unit, the call between the called mobile device and the calling mobile device based on the instruction message.
In a further embodiment, the determination of the called mobile device being the subscriber of the status information sharing service comprises: querying, by the call processing unit, a home location register associated with the called mobile device for a service subscriber flag; and determining, by the call processing unit, the called mobile device is a subscriber when the service subscriber flag is set.
Figure 6 illustrates an exemplary method (600) implemented by a mobile switching centre (MSC) for transmission of profile information, in accordance with an embodiment of present invention. In said embodiment, the method (600) comprises: receiving (601), by a call set-up unit, a request from a calling mobile device to establish a call with a called mobile device; determining (602), by a call processing unit, the calling mobile device is a subscriber of a profile information sharing service; transmitting (603), by a request transmitting unit, a request for a profile information of a user of the calling mobile device to a profile information sharing server (PISS) upon the determination, thereby enabling the PISS to transmit a push message including the profile information of the user of the calling mobile device and at least one call control function to a push message gateway communicatively coupled to the called mobile device; receiving (604), by a message handling unit, an instruction message from the PISS; and managing (605), by the call processing unit, the call between the called mobile device and the calling mobile device based on the instruction message.
In a further embodiment, the determination of the calling mobile device being the subscriber of the profile information sharing service comprises: querying, by the call processing unit, a home location register associated with the calling mobile device for a service subscriber flag; and determining, by the call processing unit, the calling mobile device is a subscriber when the service subscriber flag is set.
Figure 7 illustrates an exemplary flow diagram (700) for registering with a server to set status information and profile information, in accordance with an embodiment of present invention. For the purposes of illustration and description in the flow diagram (700), ‘server’ represents either the status information sharing server (SISS) (300) depicted in Figure 3 or the profile information sharing server (PISS) (400) depicted in Figure 4. However, the principles of the invention, in particular the registering process, remain same for both the SISS (300, 500) and PISS (400, 500) when considered individually. Further, ‘subscriber’ represents the user of the calling mobile device (301, 403) and/or the user of the called mobile device (303, 401), as depicted in Figures 3 and 4. Furthermore, ‘MSC’ represents the mobile switching centre (304, 404), as depicted in Figure 3 and 4, and ‘HLR’ represents a home location register accessed by the mobile switching centre (304, 404).
At step 701, the subscriber dials a registration code through a mobile device to initiate the registration process. The registration code may be published by a network operator or a service provider providing status information sharing service and/or profile information sharing service, hereinafter referred to as service, in association with the server.
In one embodiment, the registration code is an unstructured supplementary service data (USSD) code. In such embodiment, the subscriber initiates and completes the registration process by exchanging USSD codes with the server. As would be understood, the USSD codes are special numbers starting with an asterisk (*) and ending with a hash (#), used to address USSD messages to service providers or to network operator. Further, as would be understood, the USSD is a session-oriented protocol suited for interactive, menu-driven sessions, which remain open over a radio connection until the session is terminated.
In another embodiment, the registration code is short code. In such embodiment, the subscriber initiates and completes the registration process by exchanging one or more short codes with the server. As would be understood, the short codes are special telephone numbers and are significantly shorter than full telephone numbers, used to address short messaging service (SMS) and multi-media messaging service (MMS) messages to service providers or to network operator.
In one another embodiment, the registration code is a specific SMS number. In such embodiment, the subscriber initiates and completes the registration process by exchanging one or more SMS messages with the server.
In yet another embodiment, the registration code is a telephone number for an interactive voice response (IVR) menu provided by the server. In such embodiment, the subscriber initiates and completes the registration process by dialling the telephone number, listening to instructions provided by the IVR menu, and providing one or more inputs in response to the instructions provided by the IVR menu.
At step 702, the MSC receives the registration code from the mobile device of the subscriber and forwards a request for initiating the registration process to the server. In one embodiment, the MSC forwards the registration code to a gateway (not shown in the figure) communicatively coupled to the MSC and the server. The gateway interprets the registration code as request for initiating the registration process and forwards the request to the server. Accordingly, the gateway can be a USSD gateway when the registration code is a USSD code. Similarly, the gateway can be a short code gateway when the registration code is a short code. Similarly, the gateway can be a SMS gateway when the registration code is a specific SMS number. In another embodiment, the MSC forwards the registration code directly to the server when the registration code is a telephone number for an interactive voice response (IVR) menu provided by the server.
At step 703, in response to receiving the request for initiating the registration process from the MSC, the server either generates and transmits a push message comprising a short menu 703a to the MSC for display on the mobile device or generates voice-based instructions.
The sever transmits the push message when the request is received in the form of either a USSD code, or a short code, or a SMS to a specific SMS number. In one embodiment, the push message is a USSD push message, which requires an action from the subscriber in response to receiving the USSD push message. In another embodiment, the push message is a USSD flash message, which does not require an action from the subscriber in response to receiving the USSD flash message. In one another embodiment, the push message is a SMS push message. The server transmits the push message through a push message gateway (not shown in the figure) communicatively coupled to the server and the MSC. In one embodiment, the gateway and the push message gateway are a single entity. Further, in one embodiment, the short menu 703a includes a welcome message, options for continuing the registration process, instructions for continuing the registration process, and other relevant information.
In an example depicted in the flow diagram (700), the push message comprising the short menu 703a comprises one option as ‘1. Register’ and instruction as ‘Enter your option’.
On the other hand, the server generates the voice-based instructions when the request is received by dialling a telephone number for an interactive voice response (IVR) menu provided by the server. The voice-based instructions are transmitted directly to the MSC from the server.
At step 704, the MSC forwards the push message comprising the short menu 703a for display on the mobile device of the subscriber. Alternatively, the MSC transmits the voice-based instructions through a receiving unit of the mobile device for replay on a speaker of the mobile device.
At step 705, the subscriber selects an option from the push message comprising the short menu 703a by pressing a suitable key on the mobile device. Alternatively, the subscriber selects an option from the IVR menu by pressing a suitable key on the mobile device.
In the above example, the subscriber selects ‘Option 1’ by pressing ‘1’ on the mobile device.
At step 706, the MSC receives the option from the mobile device of the subscriber and forwards a request for registering with the service to the server. The MSC forwards the request in a manner as described in step 702.
At step 707, in response to receiving the request for registering with the service from the MSC, the server registers a mobile number or Mobile Station International Subscriber Directory Number (MSISDN) of the mobile device for the service. Accordingly, the server sets a service flag in a database (not shown in the figure) communicatively coupled with the server to indicate the MSISDN of the mobile device of the subscriber is registered for the service.
At step 708, the server sets a service subscriber flag in the HLR associated with the mobile device of the subscriber.
At step 709, the server receives an acknowledgement response from the HLR when the service subscriber flag is set.
At step 710, the server generates a push message comprising a short response 709a indicating completion of registration process. In one embodiment, the push message comprising the short response 709a includes a small message indicating successful completion of registration process.
In the above example, the push message comprising the short response 709a indicates a response ‘You are successfully registered. Thanks’.
In one embodiment, the push message is a USSD push message. In another embodiment, the push message is a USSD flash message. In one another embodiment, the push message is a short service message SMS push message. The server transmits the push message for display on the mobile device of the subscriber in a manner as described in steps 703 and 704. Alternatively, the server transmits a voice-based acknowledgement response to the mobile device of the subscriber in a manner as described in steps 703 and 704.
Upon completion of the registration, the subscriber of the mobile device is able to set up his/her profile information and status information.
Figures 8a-8d illustrate exemplary flow diagram (800) for setting of status information and profile information, and receiving of status information and profile information, in accordance with an embodiment of present invention. For the purposes of illustration and description in reference to Figures 8a-8d and for the sake of brevity, ‘server’ represents both the status information sharing server (SISS) (300) as depicted in Figure 3 and the profile information sharing server (PISS) (400) as depicted in Figure, 4. However, the principles of the invention, in particular the processes for setting and receiving status information and setting and receiving profile information remain same for both the SISS (300, 500) and PISS (400, 500) when considered individually. Further, ‘subscriber’ represents the user of the calling mobile device (301, 403) and/or the user of the called mobile device (303, 401), as depicted in Figures 3 and 4. Furthermore, ‘MSC’ represents the mobile switching centre (304, 404), as depicted in Figures 3 and 4.
Further, in said embodiment, the Figures 8a-8d are described in a sequence such that each of the processes related to setting of status information, retrieving of set status information, setting of profile information, and retrieving of set profile information, are performed in a continuous manner. However, in another embodiment, each of these processes can be performed separately and independent of each other. Additionally, in one embodiment, the subscriber can perform any of the processes independently after registering with the server, as described in reference to Figure 7 above. In another embodiment, the subscriber can perform any of the processes immediately after registering with the server, as described in reference to Figure 7 above.
Furthermore, as described with reference to Figure 7 above, the subscriber initiates and completes each of the processes by dialling a registration code from the mobile device. The registration code may be published by a network operator or a service provider providing status information sharing service and/or profile information sharing service, hereinafter referred to as service, in association with the server. In one embodiment, the registration code USSD code. In another embodiment, the registration code is a short code. In one another embodiment, the registration code is a specific SMS number. In yet another embodiment, the registration code is a telephone number for an interactive voice response (IVR) menu provided by the server.
Additionally, the server transmits a notification messages in the form of push messages in response to either the registration code or any other action by the subscriber. In one embodiment, the push message is a USSD push message, which requires an action from the subscriber in response to receiving the USSD push message. In another embodiment, the push message is a USSD flash message, which does not require an action from the subscriber in response to receiving the USSD flash message. In one another embodiment, the push message is a SMS push message. Further, Figures 8a-8b are described with respect to push messages received from the server in response to either the registration code or any other action by the subscriber. However, it would be understood that the same processes can be followed using the IVR menu provided by the server in a manner as described with reference to Figure 7. As would be understood, the IVR menu provided by the server will send voice-based instructions to the mobile device of the subscriber and the subscriber responds to the instructions by way of dialling suitable keys on the mobile device.
In Figure 8a, the subscriber initiates and completes process of setting status information.
At step 801, the subscriber dials a registration code through a mobile device to initiate the process.
At step 802, the MSC receives the registration code from the mobile device of the subscriber and forwards a request for initiating the process of setting the status information to the server. To this end, the MSC forwards the registration code to a gateway (not shown in the figure) communicatively coupled to the MSC and the server. The gateway interprets the registration code as request for initiating the process of setting the status information and forwards the request to the server.
At step 803, in response to receiving the request for initiating the process of setting the status information from the MSC, the server validates a registration of a mobile number or Mobile Station International Subscriber Directory Number (MSISDN) of the mobile device for the service. Accordingly, the server access a database, as described in reference to Figure 7 above, and determines if a service flag is set against the MSISDN of the mobile device in the database. If the service flag is not set against the MSISDN of the mobile device, the server generates and transmits a push message indicating the MSISDN of the mobile device is not registered for the service. The server then terminates the process.
If the service flag is set, the server generates and transmits a push message comprising a main menu 803a to the MSC for display on the mobile device. The server transmits the push message through a push message gateway (not shown in the figure) communicatively coupled to the server and the MSC. In one embodiment, the gateway and the push message gateway are a single entity. Further, in an embodiment, the main menu includes a welcome message, options for selecting the processes, instructions for selecting the processes, and other relevant information.
In an example depicted in the flow diagram (800), the push message comprising the main menu 803a comprises the following:
Option: ‘1. Set Status’, ‘2. Get Status’, ‘3. Set Profile’, and ‘4. Get Profile’.
Instruction: ‘Enter your option’.
At step 804, the MSC forwards the push message comprising the main menu 803a for display on the mobile device of the subscriber.
At step 805, the subscriber selects an option of setting status information from the push message comprising the main menu 803a by pressing a suitable key on the mobile device.
In the above example, the subscriber selects ‘Option 1’ by pressing ‘1’ on the mobile device.
At step 806, the MSC receives the option from the mobile device of the subscriber and forwards a request for setting the status information to the server in a manner as described in step 802.
At step 807, in response to receiving the request for setting the status information from the MSC, the server generates and transmits a push message to the mobile device of the subscriber requesting the subscriber to enter the status information. The server transmits the push message in a manner as described in steps 803 and 804.
At step 808, the subscriber inputs status information in response to the received push message. The status information can be a single sentence indicating a status of the subscriber. Examples of the status information include, but not limited to, ‘Busy’, ‘I am in a meeting’, ‘Away for lunch’, and ‘On vacation’. The status information is common to all callers calling the subscriber. Additionally, the subscriber can set only one status information for a current time. The mobile device of the subscriber then forwards a request comprising the status information 808a to the MSC.
In the above example, the subscriber sends the request 808a with status information ‘I am in a meeting’.
At step 809, the MSC receives the request from the mobile device of the subscriber and forwards the request to the server in a manner as described in step 802.
At step 810, in response to receiving the request comprising the status information 808a from the MSC, the server stores the status information in the database such that the status information is mapped with the MSISDN of the mobile device of the subscriber. The server further generates and transmits a push message to the mobile device of the subscriber requesting the subscriber to enter a duration or time period for which the status is valid. The time period can be provided either in 24-hour format or in 12-hour format. The server transmits the push message in a manner as described in steps 803 and 804.
At step 811, the subscriber inputs time period in response to the received push message. The mobile device of the subscriber then forwards a request comprising the time period 811a to the MSC.
In the above example, the subscriber sends the request 811a with time period ‘2 hours’.
At step 812, the MSC receives the request from the mobile device of the subscriber and forwards the request to the server in a manner as described in step 802.
In response to receiving the request comprising the time period 811a from the MSC, the server stores the time period along with status information in the database. Further, the server generates and transmits a push message to the mobile device of the subscriber requesting the subscriber to specify call allowance information. The server transmits the push message in a manner as described in steps 803 and 804.
Upon receiving the push message to specify call allowance information, the subscriber inputs the call allowance information. The call allowance information is set for the time period indicated by the subscriber. The call allowance information indicates that any caller is allowed to call the subscriber during the time period independent of the status information. In one embodiment, the subscriber sets the call allowance information as Boolean value. For example, the subscriber can input ‘1’ for allowing any caller to call the subscriber and ‘0’ for preventing all callers from calling the subscriber. Thus, if the call allowance information is set to ‘1’, then any caller can call the subscriber. For example, the subscriber has set the status as ‘Busy’ for a time period ‘2 hours’ and Call Allowance information is set to ‘1’. In such example, any caller will be allowed to call the subscriber. However, if the call allowance information is set to ‘0’, then all callers are prevented from calling the subscriber. For example, the subscriber has set the status as ‘Busy’ for a time period ‘2 hours’ and Call Allowance information is set to ‘0’. In such example, no caller will be able to call the subscriber. In one embodiment, the call allowance information is set as default value indicating all callers are allowed to call the subscriber by the server. In such embodiment, a request is sent to the subscriber for changing the call allowance information. Accordingly, the subscriber may change the call allowance information or retain the call allowance information as set by the server.
The mobile device of the subscriber then forwards a request comprising the call allowance information to the MSC. The MSC receives the request from the mobile device of the subscriber and forwards the request to the server in a manner as described in step 802.
In response to receiving the request comprising the call allowance information, the server stores the call allowance information along with the time period and the status information in the database. Further, if the call allowance information is set to prevent any caller from calling the subscriber, the server generates and transmits a push message to the mobile device of the subscriber requesting the subscriber to specify an authorized contact list. The server transmits the push message in a manner as described in steps 803 and 804.
Upon receiving the push message to specify the authorized contact list, the subscriber inputs the authorized contact list. The authorized contact list is set for the time period indicated by the subscriber. The authorized contact list indicates one or more callers who are allowed to call the subscriber when the call allowance information is set to prevent any caller from calling the subscriber. In one embodiment, the subscriber sets the authorized contact list by providing mobile numbers or MSISDN numbers of mobile devices of one or more callers. The MSISDN numbers of the mobile devices of the one or more callers may or may not be present in a contact list available in a memory of the mobile device of the subscriber. For example, the subscriber has set the status as ‘Busy’ for a time period ‘2 hours’, Call Allowance information as ‘0’, and authorized contact list to include MSISDN of caller A and C but not of caller B. In such example, only callers A and C will be allowed to call the subscriber and caller B will be prevented from calling the subscriber during the time period.
The mobile device of the subscriber then forwards a request comprising the authorized contact list to the MSC. The MSC receives the request from the mobile device of the subscriber and forwards the request to the server in a manner as described in step 802.
In response to receiving the request comprising the authorized contact list, the server stores the authorized contact list along with the call allowance information in the database. Further, in one embodiment upon receiving the request comprising the time period 811a from the MSC, the server generates and transmits a push message to the mobile device of the subscriber requesting the subscriber to specify a recurring information. The push message also includes an option to skip specifying the recurring information. In another embodiment, the server transmits the push message upon receiving the request comprising the call allowance information, when the call allowance information is set to allow all callers to call the subscriber. In another embodiment, the server transmits the push message upon receiving the request comprising the authorised contact list. The server transmits the push message to the mobile device in a manner as described in steps 803 and 804.
Upon receiving the push message to specify recurring information, the subscriber either inputs the recurring information or skips providing the recurring information. The recurring information indicates that the status information set by the subscriber will be repeated for recurring duration. In one embodiment, the recurring duration includes name of days and/or number of hours. For example, the subscriber can set the status as ‘Playing Tennis’ and the recurring duration as ‘Saturday’ and from 1000 hours to 1300 hours. In one embodiment, the subscriber skips providing the recurring information by selecting the option in the push message received by the subscriber. In an example, the push message received by the subscriber include a request as ‘Enter recurring information’ and option as ‘Press $ to skip’.
The mobile device of the subscriber then forwards a request comprising either the recurring information or the skip value to the MSC. The MSC receives the request from the mobile device of the subscriber and forwards the request to the server in a manner as described in step 802.
In response to receiving the request comprising the recurring information, the server stores the recurring information along with the status information in the database. Further, in response to receiving the request comprising the skip value, the server stores blank value along with the status information in the database.
For the sake of brevity, the steps pertaining to reception of request for providing the call allowance information, the authorized contact list, and the recurring information from the server and corresponding reception of such information by the server are not depicted in the flow diagram (800). However, it is to be understood that the steps lie within the scope of the invention.
At step 813, the server then transmits a push message comprising a success response 813a to the MSC. The server transmits the push message comprising a success message 813a when no further information is required from the subscriber. In one embodiment, the push message comprising the success response 813a includes a small message indicating successful completion of setting of status information process. The push message may include details such as status information, time period, call allowance information, authorized contact list, and recurring information, as available. The push message may further include an instruction. The instruction can be either to return to a main menu or to complete the process. The server transmits the push message in a manner as described in step 803.
In the above example, the push message comprising the success response 813a indicates a response ‘Status “I am busy for 2 hours” successfully set’ and instruction ‘Press # for main menu’.
At step 814, the MSC forwards the push message comprising the success message 813a for display on the mobile device of the subscriber.
Upon receiving the push message comprising the success response 813a, either the next process is started or the current process in completed. If the subscriber inputs a request for main menu, the push message comprising the main menu 803(a) is transmitted to the mobile device of the subscriber in a manner as described in steps 801-804. If the subscriber inputs a request for completion of the current process, the process is completed and a blank screen is displayed on the mobile device of the subscriber.
In Figure 8b, the subscriber initiates and completes process of getting status information.
Steps 801 to 804 are repeated in response to subscriber providing the request for main menu upon receiving the push message comprising the success response 813a.
At step 815, the subscriber selects an option of getting status information from the push message comprising the main menu 803a by pressing a suitable key on the mobile device.
In the above example, the subscriber selects ‘Option 2’ by pressing ‘2’ on the mobile device.
At step 816, the MSC receives the option from the mobile device of the subscriber and forwards a request for getting the status information to the server in a manner as described in step 802.
At step 817, in response to receiving the request for getting the status information from the MSC, the server accesses the database and retrieves status information associated with the MSISDN of the mobile device of the subscriber. The status information can also be recurring status information based on the recurring information set by the subscriber. The status information also includes the time period indicating the validity of the status information. Upon retrieving the status information, based on a current time of receiving the request for status information, the server locally derives modified status information from the saved status information from the retrieved status information. The server locally derives the modified status information by modifying the status information into blank status information upon expiry of the time period in the retrieved status information. Thus, the server denotes either the retrieved status information or the modified status information as a current active status information.
For example, the subscriber has set status information ‘Busy’ for time period ‘2 hours’ at local time 0900 hours. When the subscriber requests for status information until local time 1100 hours, the status information of the subscriber as ‘Busy’ will be denoted as current active status information. However, when the subscriber requests for status information after local time 1100 hours, the modified status information as locally derived will be denoted as current active status information.
The server then generates a push message comprising the current active status information 817a. The server transmits the push message to the MSC in a manner as described in step 803. In addition, the server includes the call allowance information and the authorized contact list in the push message. Further, the status information includes remaining duration information indicating time period for which the status information is valid based on the current time of receiving the request. The push message may further include an instruction. The instruction can be either to return to a main menu or to complete the process.
Continuing with the example stated in reference to Figure 8a above, the subscriber requests for the status information half an hour after setting the status information. The push message 817a, accordingly, includes status information ‘You current active status is “I am in a meeting” for 2 hours’, remaining duration information as ‘Remaining Time 1 hour 35 min.’, and instruction ‘Press # for main menu’.
At step 818, the MSC forwards the push message comprising the current active status information 817a for display on the mobile device of the subscriber.
Upon receiving the push message comprising the current active status information 817a, either the next process is started or the current process in completed. If the subscriber inputs a request for main menu, the push message comprising the main menu 803(a) is transmitted to the mobile device of the subscriber in a manner as described in steps 801-804. If the subscriber inputs a request for completion of the current process, the process is completed and a blank screen is displayed on the mobile device of the subscriber.
In Figure 8c, the subscriber initiates and completes process of setting profile information.
Steps 801 to 804 are repeated in response to subscriber providing the request for main menu upon receiving the push message comprising the success message 817a.
At step 819, the subscriber selects an option of setting profile information from the push message comprising the main menu 803a by pressing a suitable key on the mobile device.
Continuing with the above examples, the subscriber selects ‘Option 3’ by pressing ‘3’ on the mobile device.
At step 820, the MSC receives the option from the mobile device of the subscriber and forwards a request for setting the profile information to the server in a manner as described in step 802.
At step 821, in response to receiving the request for setting the profile information from the MSC, the server generates a push message requesting the subscriber to specify type of profile information. The server transmits the push message to the mobile device of the subscriber in a manner as described in steps 803 and 804.
At step 822, the subscriber inputs type of profile information in response to the received push message. The profile information of a subscriber can be single sentence providing additional details such as company name, designation, location, and relationship with a particular user. The profile information can be either specific profile information or general profile information. The specific profile information is set for a specific user. Example of specific profile information can be ‘Your Grand Father’. The general profile information is set for all users. Example of general profile information can be ‘Gaurav Goyal, Comviva, Gurgaon’, ‘James Peterson, VP, Sales’. In one embodiment, the subscriber can set different profile information for different users. In another embodiment, the subscriber can set general profile information for all users. Accordingly, the push message received by the mobile device of the subscriber includes an instruction for specifying type of profile information, i.e., specific profile information or generic profile information.
In an example, 822a depicts a response message including instruction regarding setting of specific profile information as ‘Enter mobile number’ or generic profile information as ‘enter 0 for generic profile’. Accordingly, the subscriber inputs either MSISDN of a user or ‘0’ through the mobile device. In the example, the subscriber inputs a MSISDN of user in response message 822a. The mobile device of the subscriber then forwards a request comprising the type of profile information 822a to the MSC.
At step 823, the MSC receives the request from the mobile device of the subscriber and forwards the request to the server in a manner as described in step 802.
At step 824, in response to receiving the request comprising the type of profile information 822a from the MSC, the server stores the type of profile information in the database. The server further transmits a push message to the mobile device of the subscriber requesting the subscriber to specify the profile information. The server transmits the push message in a manner as described in step 803.
At step 825, the subscriber inputs the profile information in response to the received push message. In the above example, the subscriber provides profile information as ‘I am XXX from YYYY’ in a response message 825a. The mobile device of the subscriber then forwards a request comprising the profile information 825a to the MSC.
At step 826, the MSC receives the request from the mobile device of the subscriber and forwards the request to the server in a manner as described in step 802.
At step 827, in response to receiving the request comprising the profile information 825a from the MSC, the server stores the profile information according to the type of profile information in the database. When the type of profile information is selected as a MSISDN number of a user, the profile information is stored along with the MSISDN of the user such that the profile information is mapped to the MSISDN of the user as called mobile number and the MSISDN of the subscriber as calling mobile number. When the type of profile information is selected as zero (0), the profile information is stored along with a blank number such that the profile information is mapped to MSISDN of the subscriber as calling mobile number and a blank number.
In the above example, the server stores the profile information ‘I am XXX from YYYY’ such that the profile information ‘I am XXX from YYYY’ is mapped to +91XXXXXXXXX as called mobile number and the MSISDN of the subscriber as the calling mobile number.
The server then generates a push message comprising a success response 827a. The push message may further include an instruction. The instruction can be either to return to a main menu or to complete the process. The server transmits the push message to the MSC in a manner as described in step 803.
In the above example, the push message comprising the success response 827a indicates a response ‘Profile “I am XXX from YYYY” successfully set for “+91XXXXXXXXX”mobile number’ and instruction ‘Press # for main menu’.
At step 828, the MSC forwards the push message comprising the success response 827a for display on the mobile device of the subscriber.
Upon receiving the push message comprising the success response 827a, either the next process is started or the current process in completed. If the subscriber inputs a request for main menu, the push message comprising the main menu 803(a) is transmitted to the mobile device of the subscriber in a manner as described in steps 801-804. If the subscriber inputs a request for completion of the current process, the process is completed and a blank screen is displayed on the mobile device of the subscriber.
Further, the subscriber can set multiple profile information specific to multiple users by selecting option for setting profile information from the push message comprising the main menu 803(a) as described above.
In Figure 8d, the subscriber initiates and completes process of getting profile information.
Steps 801 to 804 are repeated in response to subscriber providing the request for main menu upon receiving the push message comprising the success message 827a.
At step 829, the subscriber selects an option of getting status information from the push message comprising the main menu 803a by pressing a suitable key on the mobile device.
In the above example, the subscriber selects ‘Option 4’ by pressing ‘4’ on the mobile device.
At step 830, the MSC receives the option from the mobile device of the subscriber and forwards a request for getting the profile information to the server in a manner as described in step 802.
At step 831, in response to receiving the request for getting the profile information from the MSC, the server accesses the database and retrieves one or more profile information associated with the MSISDN of the mobile device of the subscriber.
The server then generates a push message comprising the one or more profile information 831a. Continuing with the example stated in reference to Figure 8c above, the push message 831a includes only one profile information set for +91XXXXXXXXX as called mobile number and the MSISDN of the subscriber as the calling mobile number. The server transmits the push message in a manner as described in step 803. The push message may further include an instruction. The instruction can be either to return to a main menu or to complete the process.
In the example, the push message 831a, includes only one profile information as ‘Your current active profile information is “I am XXX from YYYY” for “+91XXXXXXXXX”’ and instruction ‘Press # for main menu’.
At step 832, the MSC forwards the push message comprising the one or more profile information 831a for display on the mobile device of the subscriber.
Upon receiving the push message comprising the one or more profile information 831a, either the next process is started or the current process in completed. If the subscriber inputs a request for main menu, the push message comprising the main menu 803(a) is transmitted to the mobile device of the subscriber. If the subscriber inputs a request for completion of the current process, the process is completed and a blank screen is displayed on the mobile device of the subscriber.
Further, in one embodiment, the server provides an additional option to the subscriber for initiating and completing a process of getting profile of other subscriber. Through this option, the subscriber can obtain profile information of any user who has subscribed to the service. Accordingly, the push message comprising the main menu 803(a) includes another option for getting profile information of other subscribers. For the example, the push message comprising the main menu 803a comprises the following:
Option: ‘1. Set Status’, ‘2. Get Status’, ‘3. Set Profile’, ‘4. Get Profile’ and ‘5. Get Profile of Other Subscriber.
Instruction: ‘Enter your option’.
Accordingly, the subscriber selects the option of getting profile information of other subscriber from the push message comprising the main menu 803a by pressing a suitable key on the mobile device.
In the above example, the subscriber selects ‘Option 5’ by pressing ‘5’ on the mobile device.
The MSC receives the option from the mobile device of the subscriber and forwards a request for getting the profile information of other subscriber to the server in a manner as described in step 802.
In response to receiving the request for getting the profile information of other subscriber from the MSC, the server generates a push message requesting the subscriber to provide MSISDN of a mobile device of the other subscriber. The server transmits the push message to the mobile device of the subscriber in a manner as described in steps 803 and 804.
Upon receiving the push message from the server, the subscriber inputs the MSISDN of the mobile device of the other subscriber by pressing suitable keys on the mobile device. The mobile device of the subscriber then forwards a request comprising the MSISDN of the mobile device of the other subscriber to the MSC. The MSC forwards the request to the server in a manner as described in step 802.
Upon receiving the MSISDN of the mobile device of the other subscriber from the MSC, the server validates a registration of the MSISDN of the mobile device of the other subscriber for the service. Accordingly, the server accesses the database and determines if a service flag is set against the MSISDN of the mobile device of the other subscriber in the database. If the service flag is not set against the MSISDN of the mobile device of the other subscriber, the server generates a push message indicating the MSISDN of the mobile device of the other subscriber is not registered for the service. The server transmits the push message to the mobile device of the subscriber in a manner as described in steps 803 and 804. The server then terminates the process.
If the service flag is set, the server accesses the database and retrieves profile information associated with the MSISDN of the mobile device of the other subscriber. The profile information of the other subscriber can be either specific profile information set for the subscriber or general profile information. The server generates a push message comprising the profile information of the other subscriber. The push message may further include an instruction. The instruction can be either to return to a main menu or to complete the process. The server then transmits the push message to the mobile device of the subscriber in a manner as described in steps 803 and 804. The push message may further include an instruction.
Upon receiving the push message comprising the profile information of the other subscriber, either the next process is started or the current process in completed. If the subscriber inputs a request for main menu, the push message comprising the main menu 803(a) is transmitted to the mobile device of the subscriber. If the subscriber inputs a request for completion of the current process, the process is completed and a blank screen is displayed on the mobile device of the subscriber.
Figure 9 illustrates an exemplary flow diagram (900) for transmission of status information and profile information to a mobile device, in accordance with an embodiment of present invention. For illustration purposes and description, a ‘subscriber1’ having a mobile device with MSISDN-1 and a ‘subscriber2’ having a mobile device with MSISDN-2 are depicted in the flow diagram (900). The subscriber1 and subscriber2 can represent either of the user of the calling mobile device (301, 403) or the user of the called mobile device (303, 401), as depicted in Figures 3 and 4. In addition, the ‘server’ represents either a status information sharing server (SISS) (300) as depicted in Figure 3 or a profile information sharing server (PISS) (400) as depicted in Figure 4. For the sake of brevity, the server represents both the SISS (300) and the PISS (400). However, the principles of the invention remain same for both the SISS (300) and the PISS (400) when considered individually. Furthermore, ‘MSC’ represents the mobile switching centre (304, 404), as depicted in Figures 3 and 4. For the sake of brevity, the MSC is depicted as associated with both mobile devices of the subscriber1 and subscriber2.
Further, in the flow diagram (900), subscriber1 has set status information as ‘I am in meeting for 2 hours’ and specific profile information as ‘I am Gaurav’ for subscriber2. Similarly, subscriber2 has set status information as ‘Online’ and general profile information as ‘I am Anand’. Additionally, two cases, namely, Case 1 and Case 2, are depicted in the flow diagram (900). Case 1 depicts call flow when subscriber1 sends a request for call with subscriber2 and Case 2 depicts call flow when subscriber2 sends a request for call with subscriber1.
Case 1: When subscriber1 sends a request for call with subscriber2
In Case 1, subscriber1 represents calling user and subscriber2 represents called user.
At step 901, subscriber1 sends a call set-up request through a mobile device to establish a call with a mobile device of the subscriber2 to the MSC. In an embodiment, a call set-up unit of the MSC receives the call set-up request from the mobile device of the subscriber1.
At step 902, upon receiving the call set-up request, the MSC determines if the subscriber1 and subscriber2 are registered for status information sharing service and/or profile information sharing service, hereinafter referred to as service, with the server. Accordingly, the MSC queries a home location register associated with the mobile device of the susbcriber1 for a service subscriber flag and determines the susbcriber1 is registered for the service when the service subscriber flag is set against the MSISDN1. Similarly, the MSC queries a home location register associated with the mobile device of the susbcriber2 for a service subscriber flag and determines the susbcriber2 is registered for the service when the service subscriber flag is set against the MSISDN2. In an embodiment, a call processing unit of the MSC determines if the subscriber1 and subscriber2 are registered for the service.
Upon determining the subsciber2 is registered for the service, the MSC transmits a request for status information set by the subscriber2 to the server. Similarly, upon determining the subsciber1 is registered for the service, the MSC transmits a request for profile information set by the subscriber1 to the server. In an embodiment, a transmitting unit of the MSC transmits the request to the server. The transmitting unit transmits the request using techniques as known in the art.
In addition to sending the request to the server, the MSC also performs verifications to determine if the subscriber1 is allowed to make the call and if the subscriber2 is allowed to receive the call. The verifications include, but not limited to, availability of predetermined balance with susbcriber1 to make a call, availability of network coverage area for the mobile device of the susbcriber2, and device status of the mobile device of the subscriber2. The device status, as would be understood, includes switch-on state, switch-off state, and not-reachable state of a mobile device. In one embodiment, the MSC performs the above-described verifications prior to sending the request to the server. In another embodiment, the MSC performs the above-described verifications subsequent to sending the request. In either of the embodiments, the MSC transmits the request for status information set by the subscriber2 and profile information set by the subscriber1 to the server.
Further, as would be understood, upon determining if either of the subscriber1 and subscriber2 is not registered with the service, the MSC would send the request to server for the subscriber registered with the server. For example, if subscriber1 not registered for the service but subscriber2 is registered for the service, the MSC will transmit only transmit the request for status information set by subscriber 2 to the server. The MSC will not transmit the request of profile information set by subscriber1 to the server. Moreover, if neither of the subscribers are registered for the service, the MSC would handle the call set-up request in a manner as known in the art.
At step 903, the server receives the request from the MSC. In one embodiment, a receiving unit of the server receives the request.
Upon receiving the request, the server access a database coupled to the server (not shown in the figure), and retrieves status information set by the subscriber2 and profile information set by subsciber1. As described earlier with reference to Figure 8b, the server retrieves status information associated with the MSISDN1 of the mobile device subscriber2. The status information can also be recurring status information based on the recurring information set by the subscriber. The status information further includes the time period indicating the validity of the status information. Upon retrieving the status information, based on a current time of receiving the request for status information, the server locally derives modified status information from the retrieved status information. The server locally derives the modified status information by modifying the status information into blank status information upon expiry of the time period in the retrieved status information. In an embodiment, a processor of the server retrieves the status information from the database. Further, the server determines roaming information associated with the mobile device of the subscriber2. In an embodiment, the processor of the server determines the roaming information associated with the mobile device of the subscriber2. The processor may determine the roaming information using techniques known in the art.
Similarly, as described earlier with reference to Figure 8d, the server retrieves either a specific profile information mapped with MSISDN1 of the mobile device of the susbcriber1 as calling user and MSISDN2 of the mobile device of the subscriber2 as called user or a general profile information associated with the MSISDN1 of the mobile device of the subscriber1 as calling user and a blank number. In an embodiment, the processor of the server retrieves the profile information from the database.
In the example illustrated in the flow diagram (900), the server receives the request from the MSC when the time period in the status information of subscriber2 is current with respect to a time of receiving the request and therefore retrieves the status information as ‘Online’.
Further, the server retrieves call allowance information and/or authorized contact list set by the subscriber2 from the database. As described with reference to Figure 8a, the call allowance information is indicative of allowing establishment of the call with the called mobile device during the time period. Similarly, as described with reference to Figure 8a, the authorised contact list is indicative of one or more users authorized to call the user of called mobile device during the time period. Additionally, based on the authorized contact list, the server determines at least one call control option. As described with reference to Figure 8a, a user can provide the authorized contact list when the call allowance information is set to prevent callers from calling the user during the time period in the status information of the user.
In the example illustrated in the flow diagram (900), the susbcriber2 has set the call allowance information as allowing all users to call the subscriber2 and has therefore not set any authorised contact list.
Upon retrieving the status information and the call allowance information set by the susbcriber2, the server generates a push message comprising the status information. The push message may also include the roaming information of the subscriber2, as available. As described with reference to Figure 8b, the push message further includes remaining duration information indicating time period for which the status information is valid based on the current time of receiving the request. In one embodiment, the push message is an unstructured supplementary service data (USSD) push message. In another embodiment, the push message is USSD flash message. In yet another embodiment, the push message is short message service (SMS) push message. In an embodiment, a message generating unit of the server generates the push message. The server then transmits push message to the mobile device of the subscriber1 through a push message gateway (not shown in the figure) communicatively coupled to the server and the MSC. In an embodiment, a message transmitting unit of the server transmits the push message to the push message gateway. The push message gateway represents the push message gateway (309, 409) as depicted in Figures 3 and 4. The push message gateway then transmits the push message to the MSC and the MSC forwards the push message for display on the mobile device of the subscriber1.
Further, upon retrieving the profile information set by the susbcriber1, the server determines at least one call control function. In an embodiment, the processor of the server determines the at least one call control function. The call control function provides additional options to a called user to manage the call in addition to options provided on a mobile device of the called user pertaining to accepting the call and rejecting the call. Examples of the call control function include forward to a mobile number, send a message such as short messaging service (SMS) message with a text, and notify later. In an embodiment, the subscriber2 defines the mobile number upon selecting the call control function related to ‘forward to a mobile number’. In another embodiment, the subscriber2 defines the text upon selecting the call control function related to ‘send a message’.
Thereafter, the server generates a push message comprising the profile information and the at least one call control option. In one embodiment, the push message is an unstructured supplementary service data (USSD) push message. In another embodiment, the push message is USSD flash message. In yet another embodiment, the push message is short message service (SMS) push message. Further, in an embodiment, the message generating unit generates the push message. The server then transmits the push message to the mobile device of the subscriber2 through the push message gateway. In an embodiment, the message transmitting unit transmits the push message to the push message gateway. The push message gateway then transmits the push message to the MSC and the MSC forwards the push message to the mobile device of the subscriber2 for display on the mobile device of the subscriber2.
In the example illustrated in the flow diagram (900), a push message (903a) comprising the status information of subscriber2 as ‘Online’ is transmitted to the mobile device of subscriber1 and a push message (903b) comprising the profile information of subscrier1 ‘I am Gaurav’ is transmitted to the mobile device of subscuber2.
At step 904, upon transmitting the push messages to the push message gateway, the server further transmits an instruction message to the MSC. The instruction message enables the MSC to manage the call between the mobile device of the susbcriber1 and the mobile device of the subcriber2. Examples of the management of call include establishment of call, prevention of establishment of call, and forwarding the call to another number. The transmission of the push message and the transmission of the instruction message are performed independently of each other. This enables the server to transmit the push message to a mobile device of calling user irrespective of the device status of a mobile device of called user. More specifically, this enables the server to transmit the push message comprising the status information set by the subscriber2 to the mobile device of the subscriber1 irrespective of the device status of the mobile device of the subscriber2. In one embodiment, the server transmits the instruction message after the display of the push message on either of the mobile devices of the subscriber1 and subscriber2. In another embodiment, the server transmits the instruction message in parallel to the transmission of the push message.
Furthermore, the server transmits the instruction message based on the call allowance information set by the subscriber2. As described with reference to Figure 8a, a user can set the call allowance information either to prevent callers from calling the user or to allow callers to call the user during the time period specified in the status information of the user. When the call allowance information is set to prevent callers from calling the user, the server sends the instruction message to the MSC indicating prevention of establishment of call with the user. However, the server does not prevent the transmission of the push message comprising the profile information of a caller to the user. Additionally, the server transmits a time of the call along with the profile information. Thus, if the susbcriber2 has set the call allowance information as prevent callers from calling the subscriber2, the server transmits the instruction message to the MSC indicating prevention of establishment of call between the subscriber1 and the subscriber2. In addition, the server transmits the push message including the time of the call and the profile information of the subscriber1 to the mobile device of the subscriber2. Accordingly, the MSC does not establish the call between the mobile devices of the subscriber1 and the sinscvriber2, and provides a suitable notification message to the mobile device of the susbcriber1. Example of the notification message includes a voice message playing ‘cannot connect the call’.
On the contrary, when the call allowance information is set to allow callers to call the user, the server sends the instruction message to the MSC indicating allow establishment of call with the user. Thus, if the susbcriber2 has set the call allowance information as allow callers to call the subscriber2, then the server transmits the instruction message to the MSC indicating allow establishment of call between the subscriber1 and the subscriber2. Accordingly, the MSC establishes the call between the mobile devices of the subscriber1 and the sinscriber2.
Furthermore, the server transmits the instruction message to the MSC based on the authorized contact list. As described with reference to Figure 8a, a user can provide the authorized contact list when the call allowance information is set to prevent callers from calling the user during the time period in the status information of the user. The authorized contact list indicates one or more callers who are allowed to call the subscriber when the call allowance information is set to prevent any caller from calling the subscriber. When the authorized contact list does not include a MSISDN of a caller calling a user who has set call allowance information as ‘prevent callers from calling the user’, the server sends the instruction message to the MSC indicating prevention of establishment of call with the user. However, the server transmits the push message comprising the profile information of the caller to the user. Additionally, the server transmits a time of the call along with the profile information.
Thus, if the susbcriber2 has set the call allowance information as prevent callers from calling the subscriber2 and the authorized contact list does not include the MSISDN-1 of the mobile device of the subscriber1, then the server transmits the instruction message to the MSC indicating prevention of establishment of call between the subscriber1 and the subscriber2. In addition, the server provides the time of the call in the push message along with the profile of the subscriber1 to the mobile device of the subscriber2. Accordingly, the MSC does not establish the call between the mobile devices of the subscriber1 and the sinscvriber2 and provides a suitable notification message to the mobile of the susbcriber1. Example of the notification message includes a voice message playing ‘cannot connect the call’.
On the contrary, when the authorized contact list includes a MSISDN of a caller calling a user who has set the call allowance information as ‘prevent callers from calling the user’, the server sends the instruction message to the MSC indicating allow establishment of call with the user. Thus, if the susbcriber2 has set the call allowance information as prevent callers from calling the subscriber2 and set the authorized contact list to include MSISDN-1 of the mobile device of the subscriber1, the server includes the at least one call control function in the push message being transmitted to the subscriber1. The call control function provides options to a calling user to continue the call or disconnect the call based on the status information. Upon receiving a response from the subscriner1 for continuing the call, the server transmits the instruction message to the MSC indicating allow establishment of call between the subscriber1 and the subscriber2. Accordingly, the MSC establishes the call between the mobile devices of the subscriber1 and the sinscriber2.
Alternatively, upon receiving a response from the subscriber1 for disconnecting the call, the server transmits the instruction message to the MSC indicating prevention of establishment of call between the subscriber1 and the subscriber2. In addition, the server provides the time of the call in the push message along with the profile of the subscriber1 to the mobile device of the subscriber2. Accordingly, the MSC does not establish the call between the mobile devices of the subscriber1 and the subscriber2 and provides a suitable notification message to the mobile of the susbcriber1. Example of the notification message includes a voice message playing ‘cannot connect the call’.
Further, the server transmits the instruction message to the MSC based on either upon expiry of a predefined time or at least one of a response to the at least one call control function provided in the push message comprising the profile information. As described earlier, the at least one call control function includes additional functions such as forwarding to a mobile number, sending a message, and notify later. Accordingly, the server transmits instruction message indicating allow establishment of call between the mobile devices of susbcriber1 and subscrber2 after the expiry of the predetermined time when no response is received to the at least one call control option. The predetermined time may be a default value set by the server
Similarly, the server transmits instruction message indicating allow establishment of call between the mobile device of the subscriber1 and a mobile device of third subscriber when ‘forwarding to a mobile number option’ is selected. In the same manner, the server transmits instruction message indicating prevent establishment of call between the mobile devices of the subscriber1 and subscriber2, when ‘send a message’ option is selected. Accordingly, the call is not established by the MSC as described above and the server sends a message to the mobile device of subscriber1. Examples of the message include SMS message, USSD push message, and USSD flash message. In the same manner, the server transmits instruction message indicating prevent establishment of call between the mobile devices of the subscriber1 and subscriber2, when ‘notify later’ option is selected. Accordingly, the call is not established by the MSC as described above and the server sends a message is sent to the mobile device of subscriber2. Examples of the message include SMS message, USSD push message, and USSD flash message.
In the example illustrated in the flow diagram (900), the susbcriber2 has set the call allowance information as allowing all users to call the subscriber2 and has therefore not set any authorised contact list. Consequently, the server sends the instruction message to the MSC for establishing the call between the subscriber1 and the subscriber2.
At step 905, upon receiving the instruction message, the MSC manages the call between the subscriber1 and the subscriber2, as described above in step 904. As would be understood, the MSC will establish the call with the mobile device of the subscriber2 based on a device status of the mobile device of the susbcriber2.
In the example illustrated in the flow diagram (900), the MSC establishes the call between the susbcriber1 and the subscriber2 upon receiving the corresponding instruction message from the server.
Case 2: When subscriber2 sends a request for call with subscriber1
In Case 2, subscriber2 represents calling user and subscriber1 represents called user.
The steps and the functions performed by the server remain same as described with reference to Case 1 above. For the sake of brevity, lengthy descriptions have been omitted.
At step 906, subscriber2 sends a call set-up request through the mobile device to establish a call with the mobile device of the subscriber1 to the MSC. In an embodiment, the call set-up unit of the MSC receives the call set-up request from the subscriber2.
At step 907, upon receiving the call set-up request, the MSC determines if the subscriber1 and subscriber2 are registered for the service, with the server. Accordingly, the MSC queries the HLR associated with a mobile device of the susbcriber1 for a service subscriber flag and determines the susbcriber1 is registered for the service when the service subscriber flag is set as described in step 902. Upon determining the subscriber1 is registered for the service, the MSC transmits a request for status information set by the subscriber1 to the server. Similarly, upon determining the subscriber2 is registered for the service, the MSC transmits a request for profile information offset by the subscriber2 to the server. In an embodiment, the transmitting unit of the MSC transmits the request to the server. The transmitting unit transmits the request using techniques as known in the art.
Further, as would be understood, upon determining if either of the subscriber1 and subscriber2 is not registered with the service, the MSC would send the request to server for the subscriber registered with the server. For example, if subscriber1 not registered for the service but subscriber2 is registered for the service, the MSC will transmit only transmit the request for profile information set by subscriber 2 to the server. The MSC will not transmit the request of status information set by subscriber1 to the server. Moreover, if neither of the subscribers are registered for the service, the MSC would handle the call set-up request in a manner as known in the art.
At step 908, the server receives the request from the MSC. In one embodiment, the receiving unit of the server receives the request.
Upon receiving the request, the server accesses the database and retrieves status information set by the subscriber1 and profile information set by the subsciber2. As described earlier with reference to Figure 8b, the server retrieves status information associated with the MSISDN1 of the subscriber1. The status information can also be recurring status information based on the recurring information set by the subscriber. The status information further includes the time period indicating the validity of the status information. Upon retrieving the status information, based on a current time of receiving the request for status information, the server locally derives modified status information from the retrieved status information. The server locally derives the modified status information by modifying the status information into blank status information upon expiry of the time period in the retrieved status information. Further, the server determines roaming information associated with the subscriber1. Similarly, the server retrieves either a specific profile information mapped with MSISDN2 of susbcriber2 as calling user and MSISDN1 of subscriber1 as called user or a general profile information associated with the MSISDN2 of the subscriber2 as calling user and a blank number. In an embodiment, the processor of the server retrieves the status information and the profile information from the database and determines the roaming information associated with the subscriber1.
In the example illustrated in the flow diagram (900), the server receives the request from the MSC when the time period in the status information of subscriber1 is current with respect to a time of receiving the request and therefore retrieves the status information as ‘I am busy for 2 hours’.
Further, the server retrieves call allowance information and/or authorized contact list set by the subscriber1 from the database as described with reference to step 903.
In the example illustrated in the flow diagram (900), the susbcriber1 has set the call allowance information as preventing all users from calling the subscriber1 and has set the authorised contact list to include the MSISDN2 of the mobile device of the subscriber2. Thus, the subscriber2 is allowed to call the susbcriber1 even when the status information depicts that the subscriber1 is busy for 2 hours.
Upon retrieving the status information of the susbcriber1, the server generates a push message comprising the status information. In one embodiment, the push message is an unstructured supplementary service data (USSD) push message. In another embodiment, the push message is USSD flash message. In another embodiment, the push message is a short message service (SMS) push message. Further, based on the authorized contact list, the server includes at least one call control function in the push message. The call control function provides options to a calling user to continue the call or disconnect the call based on the status information. In an embodiment, the message generating unit generates the push message. The server then transmits the push message to the subscriber2 through the push message gateway for displaying the push message on the mobile device of the subscriber2 in a manner as described in step 903.
Furthermore, upon retrieving the profile information of the susbcriber2, the server determines at least one call control function as described in step 903. In an embodiment, the processor of the server determines the at least one call control function. Thereafter, the server generates a push message comprising the profile information and the at least one call control function. In one embodiment, the push message is an unstructured supplementary service data (USSD) push message. In another embodiment, the push message is a USSD flash message. In another embodiment, the push message is a short message service (SMS) push message. Further, in an embodiment, the message generating unit generates the push message. The server then transmits push message to the subscriber1 through the push message gateway for display on the mobile device of the subscriber1 in a manner as described in step 903.
In the example illustrated in flow diagram (900), a push message (908a) comprising the status information of subscriber1 as ‘I am busy for 2 hours’ is transmitted to the mobile device of subscriber2 and a push message (908b) comprising the profile information of subscrier2 ‘I am Anand’ is transmitted to the mobile device of subscuber1.
At step 909, upon transmitting the push message to the push message gateway, the server also transmits an instruction message to the MSC in a manner as described in step 904. The instruction message enables the MSC to manage the call between the mobile device of the susbcriber1 and the mobile device of the subcriber2.
In the example illustrated in the flow diagram (900), the susbcriber1 has set the call allowance information as preventing all users to call the subscriber1 and has set the authorised contact list to include MSISDN-2 of the mobile device of the subscriber2. Consequently, the server sends the instruction message to the MSC for establishing the call between the subscriber1 and the subscriber2.
At step 905, upon receiving the instruction message, the MSC manages the call between the subscriber1 and the subscriber2 as described above in step 904. It would be understood that the process followed in step 904 with subscriber1 as calling user would be followed in a same manner with subscriber2 as calling user. As would be understood further, the MSC will establish the call with the mobile device of the subscriber1 based on a device status of the mobile device of the susbcriber1.
In the example illustrated in flow diagram (900), the MSC establishes call between the susbcriber1 and the subscriber2 upon receiving the corresponding instruction message from the server.
While certain present preferred embodiments of the invention have been illustrated and described herein, it is to be understood that the invention is not limited thereto. Clearly, the invention may be otherwise variously embodied, and practiced within the scope of the

CLAIMS:WE CLAIM:
1. A method implemented by a status information sharing server (SISS) for transmission of status information to a calling mobile device, the method comprising:
- receiving, by a request receiving unit, a request for status information set by user of a called mobile device from a mobile switching centre (MSC), the MSC sending the request upon receiving a call set-up request from the calling mobile device to establish a call with the called mobile device;
- accessing, by a processor, a database operatively coupled to the SISS, to retrieve a status information and either of a call allowance information or an authorised contact list, the status information indicating a time period of validity of the status information;
- generating, by a message generating unit, a push message including either the retrieved status information or a modified status information as locally derived based on the time period; and
- transmitting, by a message transmitting unit:
- the push message to a push message gateway communicatively coupled to the calling mobile device, thereby enabling the push message gateway to transmit the push message to the calling mobile device; and
- an instruction message to the MSC based on either of the call allowance information or the authorized contact list, thereby enabling the MSC to manage the call between the calling mobile device and the called mobile device.

2. The method as claimed in claim 1, wherein the request for status information is sent by the MSC upon determining the user of the called mobile device is a subscriber of a status information sharing service provided by the SISS.

3. The method as claimed in claim 1, wherein the modified status information is locally derived, by the processor, by modifying the status information with a blank status information upon expiry of the time period.

4. The method as claimed in claim 1, wherein the status information is set by the user of called mobile device through one of: one or more unstructured supplementary service data (USSD) codes exchanged with the SISS, one or more short codes exchanges with the SISS, one or more short message service (SMS) messages exchanged with the SISS, and one or more inputs provided by the user in response to instruction associated with an interactive voice response (IVR) menu provided by the SISS.

5. The method as claimed in claim 1, wherein the push message is one of an unstructured supplementary service data (USSD) push message, an USSD flash message, and a short message service (SMS) push message.

6. The method as claimed in claim 1, wherein the transmission of the push message is independent of a device status of the called mobile device.

7. The method as claimed in claim 1, wherein the call allowance information is indicative of allowing establishment of the call with the called mobile device during the time period, the call allowance information being set by the user of the called mobile device.

8. The method as claimed in claim 1, wherein the authorised contact list is indicative of one or more users including a user of the calling mobile device authorized to call the user of called mobile device during the time period, the authorised contact list being set by the user of the called mobile device.

9. The method as claimed in claim 1, wherein upon retrieving the authorised contact list, the method further comprising:
- determining, by the processor, at least one call control function;
- generating, by the message generating unit, the push message with the at least one call control function; and
- transmitting, by the message transmitting unit:
- the push message including the at least one call control function to the push message gateway; and
- the instruction message to the MSC based on a response to the at least one call control function from a user of the calling mobile device.

10. The method as claimed in claim 1, the method further comprises:
- determining, by the processor, a roaming information associated with the called mobile device upon receiving the request for status information; and
- generating, by the message generating unit, the push message with the roaming information.

11. A method implemented by a profile information sharing server (PISS) for transmission of profile information to a called mobile device, the method comprising:
- receiving, by a request receiving unit, a request for profile information set by user of a calling mobile device from a mobile switching centre (MSC), the MSC sending the request upon receiving a call set-up request from the calling mobile device to establish a call with the called mobile device;
- accessing, by a processor, a database operatively coupled to the PISS, to retrieve a profile information set by the user of the calling mobile device;
- determining, by a processor, at least one call control function upon retrieving the profile information;
- generating, by a message generating unit, a push message including the profile information and the at least one call control function; and
- transmitting, by a message transmitting unit:
- the push message to a push message gateway communicatively coupled to the called mobile device, thereby enabling the push message gateway to transmit the push message to the called mobile device; and
- an instruction message to the MSC, thereby enabling the MSC to manage the call between the calling mobile device and the called mobile device.

12. The method as claimed in claim 11, wherein the request for profile information is sent by the MSC upon determining the user of the calling mobile device is a subscriber of a profile information sharing service provided by the PISS.

13. The method as claimed in claim 11, wherein the profile information is a generic profile information set by the user of the calling mobile device.

14. The method as claimed in claim 11, wherein the profile information is a specific profile information set for a user of the called mobile device by the user of the calling mobile device.

15. The method as claimed in claim 11, wherein the profile information is set by the user of the calling mobile device through one of: one or more unstructured supplementary service data (USSD) codes exchanged with the PISS, one or more short codes exchanges with the SISS, one or more short message service (SMS) messages exchanged with the SISS, and one or more inputs provided by the user in response to instruction associated with an interactive voice response (IVR) menu provided by the PISS.

16. The method as claimed in claim 11, wherein the at least one call control function includes call forwarding to a mobile number, sending a message, and notifying later.

17. The method as claimed in claim 11, wherein the push message is one of an unstructured supplementary service data (USSD) push message, a USSD flash message, and a short message service (SMS) push message.

18. A status information sharing server (SISS) for transmission of status information to calling mobile device, the SISS comprising:
- a request receiving unit to receive a request for status information set by user of a called mobile device from a mobile switching centre (MSC), the MSC sending the request upon receiving a call set-up request from the calling mobile device to establish a call with the called mobile device;
- a processor coupled to the request receiving unit and a database, the processor being adapted to:
- retrieve a status information set by the user from the database, the status information indicating a time period of validity of the status information; and
- retrieve either of a call allowance information or an authorised contact list from the database set by the user of the called mobile device;
- a message generating unit coupled to the processor to generate a push message including either the retrieved status information or a modified status information as locally derived based on the time period; and
- a message transmitting unit coupled to the processor and to the message generating unit, the message transmitting unit adapted to transmit:
- the push message to a push message gateway communicatively coupled to the calling mobile device, thereby enabling the push message gateway to transmit the push message to the calling mobile device; and
- an instruction message to the MSC based on one of the call allowance information and the authorised contact list, thereby enabling the MSC to manage the call between the calling mobile device and the called mobile device.

19. The SISS as claimed in claim 18, wherein the message generating unit is further adapted to locally derive the modified status information by modifying the status information with a blank status information upon expiry of the time period.

20. The SISS as claimed in claim 18, wherein the status information is set by the user of the called mobile device through one of: one or more unstructured supplementary service data (USSD) codes exchanged with the SISS, one or more short codes exchanges with the SISS, one or more short message service (SMS) messages exchanged with the SISS, and one or more inputs provided by the user in response to instruction associated with an interactive voice response (IVR) menu provided by the SISS.

21. The SISS as claimed in claim 18, wherein the push message is one of an unstructured supplementary service data (USSD) push message, a USSD flash message, and a short message service (SMS) push message.

22. The SISS as claimed in claim 18, wherein the message transmitting unit transmits the push message independent of a device status of the called mobile device.

23. The SISS as claimed in claim 18, wherein the call allowance information is indicative of allowing establishment of the call with the called mobile device during the time period.

24. The SISS as claimed in claim 18, wherein the authorised contact list indicative of one or more users including a user of the calling mobile device authorized to call the user of called mobile device during the time period.

25. The SISS as claimed claim 18, wherein upon retrieving the authorised contact list:
- the processor further:
- determines at least one call control function;
- the message generating unit:
- generates the push message with the at least one call control function; and
- the message transmitting unit transmits:
- the push message including the at least one call control function to the push message gateway; and
- the instruction message to the MSC based on a response to the at least one call control function from a user of the calling mobile device.

26. The SISS as claimed in claim 18, wherein:
- the processor further determines a roaming information associated with the called mobile device upon receiving the request for status information; and
- the message generating unit generates the push message including the roaming information.

27. A profile information sharing server (PISS) for transmission of profile information to a called mobile device, the PISS comprising:
- a request receiving unit to receive a request for profile information set by a user of a calling mobile device from a mobile switching centre (MSC), the MSC sending the request upon receiving a call set-up request from the calling mobile device to establish a call with the called mobile device;
- a processor coupled to the request receiving unit and a database, the processor being adapted to:
- retrieve the profile information set by the user from the database; and
- determine at least one call control function in response to the retrieved profile information;
- a message generating unit coupled to the processor to:
- generate a push message including the profile information and the at least one call control function; and
- a message transmitting unit coupled to the message generating unit and the processor, the message transmitting unit being adapted to transmit:
- the push message to a push message gateway communicatively coupled to the called mobile device, thereby enabling the push message gateway to transmit the push message to the called mobile device; and
- an instruction message to the MSC, thereby enabling the MSC to manage the call between the calling mobile device and the called mobile device.

28. The PISS as claimed in claim 27, wherein the profile information is a generic profile information set by the user of the calling mobile device.

29. The PISS as claimed in claim 27, wherein the profile information is a specific profile information set for a user of the called mobile device by the user of the calling mobile device.

30. The PISS as claimed in claim 27, wherein the profile information is set by the user of the calling mobile device through one of: one or more unstructured supplementary service data (USSD) codes exchanged with the PISS, one or more short codes exchanges with the SISS, one or more short message service (SMS) messages exchanged with the SISS, and one or more inputs provided by the user in response to instruction associated with an interactive voice response (IVR) menu provided bythe PISS.

31. The PISS as claimed in claim 27, wherein the push message is one of an unstructured supplementary service data (USSD) push message, a USSD flash message, and a short message service (SMS) push message.

32. The PISS as claimed in claim 27, wherein the at least one call control function includes call forwarding to a preconfigured mobile number, sending a message, and notifying later.

33. A method implemented by a mobile switching centre (MSC) for transmission of status information, the method comprising:
- receiving, by a call set-up unit, a request from a calling mobile device to establish a call with a called mobile device;
- determining, by a call processing unit, the called mobile device is a subscriber of a status information sharing service;
- transmitting, by a request transmitting unit, a request for a status information of a user of the called mobile device to a status information sharing server (SISS) upon the determination, thereby enabling the SISS to transmit a push message including either a status information or a modified status information of the user of the called mobile device to a push message gateway communicatively coupled to the calling mobile device;
- receiving, by a message handling unit, an instruction message from the SISS, the instruction message being sent by the SISS based on either of a call allowance information or an authorised contact list set by the user of the called mobile device; and
- managing, by the call processing unit, the call between the called mobile device and the calling mobile device based on the instruction message.

34. The method as claimed in claim 33, wherein the determination of the called mobile device being the subscriber of the status information sharing service by the call-processing unit comprises:
- querying a home location register associated with the called mobile device for a service subscriber flag; and
- determining the called mobile device is a subscriber when the service subscriber flag is set.

35. A method implemented by a mobile switching centre (MSC) for transmission of profile information, the method comprising:
- receiving, by a call set-up unit, a request from a calling mobile device to establish a call with a called mobile device;
- determining, by a call processing unit, the calling mobile device is a subscriber of a profile information sharing service;
- transmitting, by a request transmitting unit, a request for a profile information of a user of the calling mobile device to a profile information sharing server (PISS) upon the determination, thereby enabling the PISS to transmit a push message including the profile information of the user of the calling mobile device and at least one call control function to a push message gateway communicatively coupled to the called mobile device;
- receiving, by a message handling unit, an instruction message from the PISS in response to the transmitted request; and
- managing, by the call processing unit, the call between the called mobile device and the calling mobile device based on the instruction message.

36. The method as claimed in claim 35, wherein the determination of the calling mobile device being the subscriber of the profile information sharing service by the call-processing unit comprises:
- querying a home location register associated with the calling mobile device for a service subscriber flag; and
- determining the calling mobile device is a subscriber when the service subscriber flag is set.