Abstract:
Several telecommunication-processing methods and an associated apparatus are provided. In one embodiment, the method includes: a) determining a mobile called party is not available for an original call initiated by a calling party, b) communicating an announcement to the calling party offering notification when the mobile called party becomes available, c) in response to the calling party electing the notification offer, periodically determining if the mobile called party is available, d) after determining the mobile called party is available, initiating a first call to the calling party with an announcement indicating that the mobile called party is available and offering to connect the calling party with the mobile called party, and e) in response to the calling party electing the connect offer, initiating a second call to the mobile called party and connecting the first and second calls. In other embodiments, the mobile called party is either “not registered” or “busy.”

Description:
BACKGROUND OF INVENTION  
         [0001]    The invention generally relates to a telecommunication network and, more particularly, to an apparatus and method for notification of a calling party when a mobile called party becomes available (i.e., not busy and registered) and will be described with particular reference thereto. However, it is to be appreciated that the invention is also amenable to other applications.  
           [0002]    A telecommunication network often includes one or more wireless networks. These types of telecommunication networks are generally known in the art. One example of a typical telecommunication network is depicted in FIG. 1. The telecommunication network  10  includes a calling party “A”  12 , an originating mobile switching center (O-MSC)  14 , a standalone home location register (SHLR)  16 , a service control point (SCP)  18 , a serving mobile switching center (S-MSC)  20 , and a mobile called party “B”  22 .  
           [0003]    Calling party “A”  12  may be using a wired telephone, personal communication system (PCS), or a mobile station (MS). Calling party “A”  12  is in communication with the O-MSC  14  via a voice trunk  24   a  or any other connection capable of carrying a voice or data call.  
           [0004]    Each mobile switching center (SC) is an automatic system that provides an interface for user traffic between a wireless network and other public switched networks, or other MSCs in the same or other wireless networks. The O-MSC  14  receives incoming calls for mobile unit subscribers (e.g., mobile called party “B”  22 ). The O-MSC  14  is in communication with the S-MSC  20  via a voice trunk  24   b  or any other connection capable of carrying a voice or data call. The O-MSC  14  is in communication with SHLR  16  and SCP  18  via control signaling links  26 .  
           [0005]    The S-MSC  20  provides service to mobile units that have traveled or roamed into their designated or predetermined geographic region (e.g., mobile called party “B”  22 ). The S-MSC  20  is in communication with mobile called party “B”  22  via a radio access network (RAN) connection  24 c. The S-MSC  20  is in communication with SHLR  16  and SCP  18  via control signaling links  26 .  
           [0006]    The SHLR  16  includes a database that serves as a registrar to which a user&#39;s identity is assigned for record purposes. The database, for example, includes subscriber information, mobile station information, and location information for users. The SHLR  16  provides service control and mobility management for subscribers. Typically, an SHLR serves more than one MSC (as shown in FIG. 1). However, an HLR may be located within, and indistinguishable from, a particular MSC. The SHLR  16  is in communication with the SCP  18  via control signaling links  26 .  
           [0007]    The SCP  18  is a database and transaction-processing system that provides service control and service data functions. The SCP  18  performs a subscriber and application specific service in response to a query and then sends back instructions to perform specific functions and instructions for continuing call processing. Additionally, the SCP  18  is a mechanism for introducing new services and customizing services and features.  
           [0008]    Mobile called party “B”  22  includes interface equipment (e.g., MS) used to terminate the radio (i.e., wireless) path at the mobile user side. Typically, such equipment also provides mobile called party “B”  22  with access to the communication network for outgoing calls.  
           [0009]    Currently, when calling party “A”  12  calls mobile called party “B”  22 , if party “B” is not registered or busy, the call is generally forwarded to a voice message system. The only options for interactively communicating with party “B” are: 1) to leave a message and wait for the party “B” to return the call or 2) to call party “B” again later.  
           [0010]    There is a particular need to provide another option to the calling party when a mobile user is busy or not registered that notifies the original calling party when the mobile user becomes available.  
         BRIEF SUMMARY OF INVENTION  
         [0011]    In one aspect of the invention, a method of notifying a calling party when a mobile called party becomes available in a telecommunication network including a wireless network is provided. The method includes: a) determining the mobile called party is not available for an original call initiated by the calling party, b) communicating an announcement to the calling party offering notification when the mobile called party is available, c) in response to the calling party electing the notification offer, periodically determining if the mobile called party is available, d) after determining the mobile called party is available, initiating a first call to the calling party with an announcement indicating that the mobile called party is available and offering to connect the calling party with the mobile called party, and e) in response to the calling party electing the connect offer, initiating a second call to the mobile called party and connecting the first and second calls.  
           [0012]    In another aspect of the invention, a telecommunication processing method is provided. The method includes: a) determining a mobile called party is busy for an original call initiated by a calling party, b) communicating an announcement to the calling party and offering notification when the mobile called party becomes available, c) if the calling party elects the notification offer, periodically determining if the mobile called party has become available, d) after determining the mobile called party has become available, initiating a first call to the calling party with an announcement indicating that the mobile called party has become available and offering to connect the calling party with the mobile called party, and e) in response to the calling party electing the connect offer, initiating a second call to the mobile called party and connecting the first and second calls.  
           [0013]    In still another aspect of the invention, a method of telecommunication processing is provided. The method includes: a) determining a mobile called party is not registered for an original call initiated by a calling party, b) communicating an announcement to the calling party and offering notification when the mobile called party becomes available, c) if the calling party elects the notification offer, periodically determining if the mobile called party has become available, d) after determining the mobile called party has become available, initiating a first call to the calling party with an announcement indicating that the mobile called party has become available and offering to connect the calling party with the mobile called party, and e) in response to the calling party electing the connect offer, initiating a second call to the mobile called party and connecting the first and second calls.  
           [0014]    Benefits and advantages of the invention will become apparent to those of ordinary skill in the art upon reading and understanding the description of the invention provided herein. 
       
    
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0015]    The invention is described in more detail in conjunction with a set of accompanying drawings.  
         [0016]    [0016]FIG. 1 is a block diagram of a telecommunications network.  
         [0017]    [0017]FIG. 2 is a flowchart according-to an embodiment of the invention of a calling party notification process for a call to a mobile user that was originally not available at the time the call was made.  
         [0018]    [0018]FIG. 3 is a call flow diagram according to an embodiment of the invention for a mobile user not registered scenario.  
         [0019]    [0019]FIG. 4 is a call flow diagram according to an embodiment of the invention for a mobile user busy scenario. 
     
    
     DETAILED DESCRIPTION  
       [0020]    While the invention is described in conjunction with the accompanying drawings, the drawings are for purposes of illustrating exemplary embodiments of the invention and are not to be construed as limiting the invention to such embodiments. It is understood that the invention may take form in various components and arrangement of components and in various steps and arrangement of steps beyond those provided in the drawings and associated description. In the drawings, like reference numerals denote like elements and similar reference numerals denote similar elements.  
         [0021]    With reference to FIG. 2, a process of notifying a calling party when a called party becomes available  50  is provided according to an embodiment of the invention. The calling party may be a landline user, PCS user, a mobile user, or any other type of telephone service user. The called party is a mobile user. The process begins at step  52  when the calling party calls the mobile user. The invention is associated with calls where the mobile user is originally not available (step  54 ). The system recognizes several conditions for which the mobile user is not available. For example, when the mobile user&#39;s line is busy and when the mobile user is not registered (i.e., not active). If the mobile user is available, the original call will ring through and either be answered by the mobile user or terminated by the calling party prior to being answered.  
         [0022]    With the mobile user not available, at step  56  the process plays an announcement to the calling party asking whether the calling party wants to be notified when the mobile user becomes available or connected to the mobile user&#39;s voice mail. If the calling party selects to be notified, the process continues to step  58 . Otherwise, the calling party is routed to the mobile user&#39;s voice mail (step  60 ).  
         [0023]    At step  58 , the process begins a loop to periodically check if the mobile user becomes available for a predetermined period. If the mobile user is not available, the process checks to see if the predetermined period has timed out (step  62 ). If the period has not timed out, the process repeats step  58 . If the period has timed out, the process is ended (step  64 ).  
         [0024]    If the mobile user becomes available at step  58 , the process calls the calling party and announces that the mobile user is available (step  66 ) with an option to automatically place a call to the mobile user (step  68 ). If the calling party elects to have the process automatically call the mobile user, the process continues to step  70  and automatically calls the mobile user for the calling party. Otherwise, the process is ended (step  72 ) and the calling party may call the mobile user again, at the calling party&#39;s choosing.  
         [0025]    In one embodiment, the called mobile user is within the service provider&#39;s SHLR network.  
         [0026]    With reference to FIG. 3, a call flow diagram for a mobile user “not registered” scenario according to an embodiment of the invention is provided. An exemplary telecommunications infrastructure for the call flow diagram includes the calling party “A”  12 , O-MSC  14 , SHLR  16 , SCP  18 , S-MSC  20 , and mobile called party “B”  22  as depicted in FIG. 1. Alternate infrastructure components providing similar functions are also contemplated. The call flow begins at line (a) and continues in a step fashion to line (q).  
         [0027]    The “not registered” scenario begins at line (a) when calling party “A”  12  places a call to mobile called party “B”  22 . At this point, call “a” is communicated from calling party “A”  12  to the O-MSC  14 . Next, at line (b), a Location Request (LOCREQ) message is communicated from the O-MSC  14  to the called party&#39;s SHLR  16 . The SHLR  16  checks to see if called party is authorized and active. In this scenario, the called party is not active (i.e., not registered). Thus, the SHLR  16  communicates a Remote User Interaction Directive (RUIDIR) message with Announcement and Digits parameters to the O-MSC  14  to play an announcement requesting instructions on whether the calling party wants to be notified when the called party is available or be directed to voice mail (line (c)).  
         [0028]    After the calling party responds, at line (d), the O-MSC  14  communicates a remote user interaction directive (ruidir) return result to the SHLR  16 . If notification is requested, the SHLR  16  marks the called party record accordingly. If notification is not requested, the calling party is given access to the called party&#39;s voice mail or the call is simply ended. At line (e), the SHLR  16  communicates a locreq return result to the O-MSC  14 . Next, at line (f), the SHLR  16  communicates a Service Request (SERREQ) message to the SCP  18  with DigitsDialed and CallingPartyDigits parameters. The “notify me” process stores this information. A service request (servreq) return result is communicated from the SCP  18  to the SHLR  16  (line (g)).  
         [0029]    At line (h), in response to party B  22  entering the serving area of S-MSC  20  and registering with the S-MSC  20 , the S-MSC  20  communicates to the SHLR  16  a Registration Notification (REGNOT) message. This is acknowledged by the SHLR  16  returning a registration notification return result (regnot RR) to the the S-MSC  20 . At this point, the SHLR  16  recognizes that the called party is available and sends a SERVREQ message to the “notif me” process in the SCP  18  (line (j)). Next, at line (k), the SCP  18  communicates a servreq return result to the SHLR  16 .  
         [0030]    At line (l), the SCP  18 , via, for example, an enhanced media resource server (eMRS), initiates a call to original calling party “A”  12  and communicates a first initial address message ([AM) with an announcement to O-MSC  14 , resulting in O-MSC  14  alerting calling party “A”  12 . In response, calling party “A”  12  answers the incoming call, causing the O-MSC  14  to communicate an answer message (ANM) return result to the SCP  18  (line (m)). Next, at line (n), the SCP  18  plays the announcement to calling party “A”  12 . The announcement, for example, states that mobile directory number (MDN) xxxxxxxxx (i.e., mobile called party “B”  22 ) is available and to press “1” to call the party. A response by calling party “A”  12  is also communicated to the SCP  18  in line (n).  
         [0031]    Next, if calling party “A”  12  pressed “1” (i.e., requested the process to automatically call the mobile user), at line (o), the SCP  18 , via, for example, the eMRS, initiates a call to original mobile called party “B”  22  and communicates a second IAM to S-MSC  20 , resulting ins S-MSC  20  alerting mobile called party “B”  22 . If mobile called party “B”  22  is busy, the process returns to line (c) (see paragraph 27) to retry the notification process for the “not registered” scenario. If mobile called party “B”  22  answers, an ANM is communicated to the SCP  18  (line (p)) from the S-MSC  20 . When both the calls (i.e., first IAM and second IAM) are successful, at line (q), calling party “A”  12  and mobile called party “B”  22  are connected by the SCP  18 .  
         [0032]    With reference to FIG. 4, a call flow diagram for a mobile user “busy” scenario according to an embodiment of the invention is provided. An exemplary telecommunications infrastructure for the call flow diagram includes the calling party “A”  12 , O-MSC  14 , SHLR  16 , SCP  18 , S-MSC  20 , and mobile called party “B”  22  as depicted in FIG. 1. Alternate infrastructure components providing similar functions are also contemplated. The call flow begins at line (a) and continues in a step fashion to line (q).  
         [0033]    The “busy” scenario begins at line (a) when calling party “A”  12  places a call to mobile called party “B”  22 . At this point, in call “a” is communicated from calling party “A”  12  to the O-MSC  14 . Next, at line (b), a LOCREQ message is communicated from the O-MSC  14  to the called party&#39;s SHLR  16 . The SHLR  16  checks to see if called party is authorized and active. In this scenario, the called party is busy. Thus, the SHLR  16  communicates a RUIDIR message with Announcement and Digits parameters to the O-MSC  14  to play an announcement requesting instructions on whether the calling party wants to be notified when the called party is available or be directed to voice mail (line (c)).  
         [0034]    After the calling party responds, at line (d), the O-MSC  14  communicates a ruidir return result to the SHLR  16 . If notification is requested the SHLR  16  marks the called party record accordingly. If notification is not requested, the calling party is given access to the called party&#39;s voice mail or the call is simply ended. At line (e), the SHLR  16  communicates a locreq return result to the O-MSC  14 . Next, at line (f), the SHLR  16  recognizes that the mobile called party is busy and communicates a SERVREQ message to the SCP  18  with DigitsDialed and CallingPartyDigits parameters. The “notify me” process stores this information. A servreq return result is communicated from the SCP  18  to the SHLR  16  (line (g)).  
         [0035]    At line (h), the SCP  18  periodically sends an Inter-System Position Request (ISPOSREQ) message to the S-MSC  20  for a predetermined period of time to see if the mobile called party is available. The S-MSC  20  communicates an inter-system position request (isposreq) return result with an MS status parameter having bits set if the mobile user is on a traffic channel (e.g., Chann bit) (line (i)). The number of trials and periodicity of the busy query may be specified in the “notify me” process. Lines (j) and (k) depict one repetition of the query.  
         [0036]    When mobile called party “B”  22  is available (i.e., no longer busy), the SCP  18 , via, for example, the eMRS, initiates a call to original calling party “A”  12  and communicates a first LAM with an announcement to O-MSC  14 , resulting in O-MSC  14  alerting calling party “A”  12  (line (l)). In response, calling party “A”  12  answers the incoming call, causing the O-MSC  14  to communicates an ANM return result to the SCP  18  (line (m)). Next, at line (n), the SCP  18  plays the announcement to calling party “A”  12 . The announcement, for example, states that mobile directory number (MDN) xxxxxxxxx (i.e., mobile called party “B”  22 ) is available and to press “1” to call the party. A response by calling party “A”  12  is also communicated to the SCP  18  in line (n).  
         [0037]    Next, if calling party “A”  12  pressed “1” (i.e., requested the process to automatically call the mobile user), at line (o), the SCP  18 , via, for example, the eMRS, initiates a call to original mobile called party “B”  22  and communicates a second LAM to mobile called party “B”  22 . If mobile called party “B”  22  is busy, the process returns to line (c) to retry the notification process for the “busy” scenario. If mobile called party “B”  22  answers, an ANM is communicated to the SCP  18  (line (p)). When both the calls (i.e., first IAM and second IAM) are successful, at line (q), calling party “A”  12  and mobile called party “B”  22  are connected by the SCP  18 .  
         [0038]    While the invention is described herein in conjunction with exemplary embodiments, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the embodiments of the invention in the preceding description are intended to be illustrative, rather than limiting, of the spirit and scope of the invention. More specifically, it is intended that the invention embrace all alternatives, modifications, and variations of the exemplary embodiments described herein that fall within the spirit and scope of the appended claims or the equivalents thereof