Communication mechanism for calls in which speaking is not possible

BACKGROUND OF THE INVENTION

The invention relates to methods and equipment for implementing a communication mechanism for calls in which speaking is not possible.

There are several situations in which one or both parties of a call cannot speak on a telephone. For instance, libraries, restaurants and public performances (concerts, theatres, movies, etc.) are situations in which speaking on a telephone is prohibited or socially unacceptable. If the called party (B) cannot take a call, the calling party (A) is usually directed to voice mail. Alternatively, the parties may communicate via short messages. Short message service, like the one provided by the GSM system and its derivatives, provides a widely-used substitute for conventional calls if one or both parties cannot speak on a telephone. But the short message service has its share of problems. For instance, reading and sending each message requires several acts via the telephone's menu system.

BRIEF DESCRIPTION OF THE INVENTION

An object of the present invention is to provide improved methods and equipment for calls in which two-way speech is not possible.

The object of the invention is achieved by the methods and equipment which are characterized by what is stated in the independent claims. The preferred embodiments of the invention are disclosed in the dependent claims.

For example, the invention can be implemented as a method for processing a voice call establishment request from a calling terminal to a called terminal. A conventional method comprises detecting the call establishment request, alerting the called terminal or its user and setting up a two-way connection between the calling and the called terminals. A method according to the invention also comprises the following steps:

determining that a two-way voice call between the calling terminal and the called terminal is not allowed;

receiving silent messages via the called and/or calling terminal's user interface; and

conveying information based on said silent messages to the calling and/or called terminal, respectively.

An aspect of the invention is a method for processing a call setup request from an A party to a B party. Another aspect of the invention is an apparatus, such as a mode server, for supporting or implementing the above method. The mode server can be located in a network element or in the called terminal or both. As used herein, the mode server is an entity that determines or affects the mode of the call in the incoming and/or outgoing direction. An illustrative but non-exhaustive list of call modes comprises normal speaking, messaging, chatting and limited chatting. Speaking is the preferred mode for calls between two persons, but there are situations in which speaking is not allowed. As far as the invention is concerned, the precise reason as to why speaking is not allowed does not matter. Speaking may be prohibited by law or etiquette, or the called party may wish to avoid being overheard. From the point of view of the equipment, the called party gives an indication that speaking is not allowed. Such an indication may be given before alerting the called party, in which case the indication is a “current profile” or part of it. Or, indication may be given after the alert, in which case the called party selects the call mode on a case-by-case basis. What matters is that at least one party cannot participate in a two-way voice call and must participate silently instead. Yet further, the need to establish a silent call, in at least one direction, may develop during the call. For instance, one of the parties may be in a movie, and it may be possible to speak before the movie starts, but when it starts, the call must be continued silently, if at all. However, changing the call mode during a call may be technically simpler than having a silent call from the beginning, because the parties can inform each other on the situation.

In the context of this invention, the attribute “silent” means a call mode in which the party in question does not speak. Such a call mode could also be called a “non-voice” call. For example, if the B party is in a library, he/she can have a call in which the incoming half-call is a conventional voice call but the outgoing half-call is a silent one. On the other hand, a hearing-impaired person may participate in a call in which the incoming half-call is silent but the outgoing one is a conventional voice call, assuming that the hearing-impaired person is able to speak.

An example of a silent call mode is chatting. Chatting means a mode of conversation in which the chatting party sends his/her messages by typing on the terminal's keyboard or keypad. Obviously, sending arbitrary messages by chatting requires the ability to see the terminal's display and keyboard/keypad, and this is impossible in many public performances. But even in such situations a party can participate in a two-way dialogue by limited chatting. Limited chatting is a mode of conversation in which a limited number of messages are available. For example, a terminal's user interface may offer two keys for “yes” and “no”, and optionally, a third key for “I don't understand” (or “I cannot answer right now”). Instead of the few dedicated keys, or in addition to them, there may be a few different key presses. For example, a single click, a double click and a long press may mean three different things. A combination of three keys and three different key presses provides nine different messages such that the terminal user does not have to move his/her fingers or see the terminal. Alternatively, or in addition to the different keys/key presses, the terminal may store several pre-stored responses of which one is selected. The terminal's user interface may provide next/previous selection keys and an OK key. Whenever, the next/previous keys are used, a next or previous message may be displayed or read out to the terminal user via an earphone, and the message is only sent to the other party when the user selects the message with the OK key.

A server, as in the context of “mode server”, is something that provides a service. The mode server may be a separate server or an attachment to pre-existing call processing equipment, such as a mobile switching centre or private branch exchange. Or, the mode server may be implemented as a software agent in the user equipment, such as a mobile telephone. As a further alternative, the mode server may be implemented as a distributed collection of software, such as a client/server system.

The invention is based on the idea of processing the two directions (or “half-calls”) of the call, ie from A to B and B to A, separately. An example of such separate processing is that if B is unable to speak, the direction from A to B is processed as a conventional voice call but the inverse direction from B to A is processed as a chat connection.

This separate processing does not mean that the directions of the call are always processed differently. For example, it is possible to process both directions as chat connections. But even such a two-way chat connection is different from a conventional exchange of short messages because each message of the chat connection does not have to be addressed separately. The present invention also differs from the conventional short message service in that the caller attempts to initiate a normal voice call but the mode server automatically determines that the voice call is not permitted and changes the call mode to silent, at least in one direction.

The invention brings about certain problems or questions that do not exist in conventional call processing systems. These problems or questions are related to the fact that a call may be first attempted as a conventional call but if either party is unable to speak, at least one call direction must be processed as silent. For instance, which element determines which calls are processed as silent? How is this determination made? Various preferred embodiments of the invention provide solutions to these problems.

One solution to the above residual problems is as follows. The mobile phone's user interface provides two (or more) different techniques to answer an incoming call. For instance, the user interface may have buttons for “normal call” and “silent call”. Alternatively, a single short click on an “answer” button results in a normal call whereas a double click or a long press on the same button results in a silent call. In this embodiment, the mobile terminal user provides the input that lets the mobile telephone (or the underlying network) to determine the call mode on a per-call basis.

An alternative solution to the above residual problems is based on user profiles. Before entering a location in which speaking on a telephone is prohibited or unacceptable, the terminal user changes his/her profile to one that indicates silent calls. The profile may be maintained in the terminal or in an appropriate network element. Co-assigned Finnish patent application 20021664, filed 18 Sep. 2002, titled “User-configurable call answering/redirection mechanism”, discloses various techniques for maintaining user profiles. That patent application is not public at the filing date of the present invention, and its relevant parts are repeated later in this specification.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention will be described in greater detail by means of preferred embodiments with reference to the attached drawings, in which:

FIGS. 1A and 1B show examples of network architectures in which the invention can be used;

FIG. 2 shows the major functional blocks of a mode server according to a preferred embodiment of the invention;

FIG. 3 is a flow chart illustrating mode-related decisions at the time of answering a call;

FIG. 4 shows a mobile terminal's user interface that has been specially adapted to select a special call mode;

FIG. 5A shows a signalling diagram for a two-way chat connection;

FIG. 5B shows a signalling diagram for an asymmetric voice/chat connection;

FIG. 6 shows a user interface for selecting one of a number of predetermined responses (messages);

FIG. 7 illustrates user records and caller groups;

FIG. 8 illustrates reachability profiles;

FIG. 9 illustrates redirection settings;

FIG. 10 illustrates associations of caller groups, reachability profiles and redirection settings; and

FIG. 11 is a flow chart illustrating the operation of a reachability server.

DETAILED DESCRIPTION OF THE INVENTION

FIGS. 1A and 1B show examples of network architectures in which the invention can be used. FIG. 1A shows an example of a network architectures in which the mode server is located in the access network serving the subscribers. Reference sign TE generally denotes user terminals 101 and 102, of which terminal 101 is used by the calling party A and terminal 102 is used by the called party B. The terminals 101, 102 are connected to an access network AN. The access network AN can use any network technology capable of processing calls, including but not limited to GSM, UMTS or WLAN with VoIP. The access network AN has base stations BS to provide a radio interface to user terminals 101, 111. One or more switching elements SW route calls, via different base stations, to different terminals. For example, in a GSM network, the switching elements are mobile services switching centres (MSC). A Home Location Register HLR stores subscriber data. An answering server AS provides voice mail services when Bill is unable to receive calls.

The access network AN is connected to other networks via one or more gateway elements GW. For example, the other networks may be a Public Switched Telephone Network PSTN and/or a data network DN, such as the Internet and/or its closed subnetworks, commonly called intranets or extranets. The elements of FIGS. 1A and 1B described above are or can be entirely conventional. In addition to the conventional elements, the network architecture comprises a mode service function. In the example shown in FIG. 1A, the mode service function is implemented as a mode server MS that is closely coupled to the switching element SW. The internal structure of an exemplary embodiment of the mode server MS will be shown in FIG. 2.

FIG. 1B shows an embodiment of a network architecture in which the mode server, here denoted by MS′, is located in the called user's terminal 102. The two placements for the mode server, namely in the access network AN and in the terminal 102, need not be mutually exclusive, however, and an optimal implementation of the mode service is achieved by a combination of a centralized mode server MS and terminal-based mode server MS′. For example, terminals capable of multimedia operations have sufficient memory for acting as a voice storage for incoming and/outgoing voice messages, and/or as a speech synthesizer. An advantage of a voice mail box in a terminal is that the terminal can inform the caller that the call cannot be answered and store a voice message from the caller, without disturbing people near the terminal. A terminal-provided voice mail box is independent from the current access network operator. Voice storage for incoming voice messages provides the terminal with answering machine capability. In other words, the terminal has an integrated voice mail box that is independent of the access network. Voice storage for outgoing voice messages enables the terminal user to select and send one of several pre-stored voice messages to the other party. In other words, the terminal user needs only a few keys to respond by voice, without speaking on the telephone. Similar functionality is provided by a speech synthesizer integrated in the terminal.

FIG. 2 shows the major functional blocks of a mode server according to a preferred embodiment of the invention. If the mode server is a network-based mode server MS shown in FIG. 1A, it is preferably installed in the switching element SW. On the other hand, if the mode server is a terminal-based mode server MS′ shown in FIG. 1B, it is installed in the terminal TE (shown as terminal 102 in FIG. 1B).

An essential functional block of the mode server MS, MS′ is a mode converter MC that is capable of changing the call mode from a voice call to one or more variants of non-voice calls, such as chatting, limited chatting, transmission of pre-stored or synthesized voice, etc.

According to a preferred embodiment of the invention, the mode server MS comprises a reachability server RS and an associated database DB. The database DB stores profile records PR that indicate the current profile of the called subscriber. If the mode server MS′ is located in the called party's terminal, a single current profile is sufficient, and the subscriber information is redundant. Further preferred embodiments of the reachability server RS and the profiles will be described in connection with FIGS. 7 through 11. As far as the invention in its broadest sense is concerned, it is not strictly necessary to store any profiles, as long as the called party explicitly indicates a desired call mode each time he/she answers an incoming call. A stored profile PR is beneficial, however, because it provides the mode server with a default mode for the incoming call, and enables the mode server to direct the incoming call to an answering service when the called party is unable to take any calls, including silent ones.

FIG. 3 is a flow chart illustrating a preferred embodiment for mode-related decisions at the time of answering a call. This embodiment shows how pre-stored profiles and on-the-fly decisions can both be used to determine an appropriate mode for an incoming call. In step 3-2, the mode server MS checks whether the called party's profile, if any, indicates voice mail, that is, an answering service. If yes, the call is directed to voice mail in step 3-8. If the profile does not indicate voice mail, or none exists, the user is alerted in step 3-4. If the current profile indicates silent calls, the user is alerted silently, preferably by a vibrating alert. In step 3-6, the mode server MS checks whether the called party responds in a predetermined time, such as 10 seconds. If not, the call is directed to voice mail in step 3-8. If the user does respond, the process advances to step 3-10 in which the mode server MS checks whether the called party selects an explicit call mode when responding to the alert. Techniques for on-the-fly indication of a call mode will be described in connection with FIG. 4. If the called party selects an explicit call mode, the call is processed in the user-selected mode in step 3-12. Otherwise the process advances to step 3-14 in which the mode server MS checks if there is a profile that indicates a certain call mode. If yes, the call is processed in the mode indicated by the profile in step 3-16.

The embodiment shown in FIG. 3 is beneficial in the sense that the user can select a profile that indicates a default mode for incoming calls. However, the user may override that default on a per-call basis. It should be noted, however, that the flow chart shown in FIG. 3 is only an illustrative example, and the different checks may be performed in other orders as well.

FIG. 4 shows a mobile terminal's user interface UI that has been specially adapted to select a special call mode. The user interface UI comprises a display DI that indicates the calling party. The user interface UI also comprises a set of function keys 41 that allow the user to respond with a desired call mode. The function keys 41 may be supported by associated legends 42. In this example, the function keys 41 comprise keys for a normal call and chatting. The function keys 41 may be implemented in a variety of ways. For instance, there may be up/down/ok keys or a joystick-type switch. Or, the set of function keys 41 may be replaced by a roller that is rolled upwards or downwards and clicked for selecting the current call mode.

FIG. 5A shows a signalling diagram for a two-way chat connection. This signalling diagram relates to an embodiment in which a network-based mode server MS comprises (or is otherwise associated with) a mode converter MC, a reachability server RS and its associated database DB. In step 5-0, the calling terminal A sends a call setup signal which proceeds to the switching element SW. In step 5-2, the switching element SW makes an inquiry to the reachability server RS (which in turn makes an inquiry to its database DB) concerning the called party's current profile. In step 5-4, the reachability server RS/database DB return the current profile to the switching element SW. Let us assume that the current profile indicates a call mode of “chat”. In step 5-6, the switching element SW conveys the call setup signal to the terminal of the called party B. In step 5-8, the B party responds. Now the switching element SW knows that the B party is able to take the call. For example, the B party may be located in a place where speaking or voice alert are prohibited but the B party is able to take the call because the terminal's alert is set to silent/vibrating. In step 5-10, the switching element SW requests the mode converter MC to read instructions to the calling party A. In step 5-12, the mode converter MC reads a voice announcement that tells the caller A that B can hear A's voice but can only respond by chatting. The voice announcement is preferably read to the B party as well. Otherwise, B could be confused because he/she does not hear anything as long as A listens to the voice announcement. In step 5-14 there is a two-way chat connection between A and B.

FIG. 5B shows a signalling diagram for an asymmetric voice/chat connection. This means that A communicates by voice and B responds by chatting. Steps 5-0 through 5-12 are similar to the corresponding steps in FIG. 5A and will not be described again. However, FIG. 5B shows a scenario in which A can keep talking for the entire duration of the connection, and the contents of the announcement in step 5-12 are adapted accordingly. In step 5-22, A talks to B who may hear A's speech via an earphone connected to the terminal. In step 5-24, B responds by chatting (typing text). In step 5-26, B's text response is converted to speech. For example, the mode converter MC may comprise a speech synthesizer for converting chat responses to speech. Alternatively, the mode converter MC may store a number of pre-recorded voice responses of which the B party selects one. This means that the signal in step 5-24 is a selection of one of the pre-recorded voice responses. A preferred embodiment of the mode converter MC supports both options, ie, synthesized speech and pre-recorded voice responses. A benefit of synthesized speech is that an arbitrary response can be sent. In other words, the responses do not have to be pre-recorded. On the other hand, it is beneficial to be able to store certain frequently-used responses as pre-recorded voice responses, because it is faster to select one of pre-recorded voice responses than to type the response from scratch. Also, if the B party is in a theatre or the like, even chatting may be impossible, and the only way for the B party to communicate bi-directionally is to select one of pre-recorded messages. In step 5-28, the B party's response is finally conveyed to the A party.

In the example shown in FIG. 5B, the mode converter MC performs text-to-speech conversion. If the mode converter MC comprises a speech-recognition apparatus, it is also possible to perform speech-to-text conversion. This means, for example, that the parties can have a two-way communication in which one party speaks and listens while the other party communicates by chatting. Naturally, current speech-to-text conversion is not yet mature enough to support continuous speech from an arbitrary caller in arbitrary surroundings, but speech-to-text conversion is possible with limited vocabulary and small pauses between words.

FIG. 6 shows a user interface for selecting one of a number of predetermined messages. This embodiment eliminates the need to type frequently-used responses key by key. In the example shown in FIG. 6, the terminal's user interface UI comprises programmable function keys 61 that are preferably associated with adaptive legends 62. The user uses the function keys 61 to select a desired response from a list of several pre-stored messages 63. In this example, the user is about to select the phrase “I will call you later”, denoted by reference numeral 64.

The terminal shown in FIG. 6 has the capability to store the pre-recorded messages 63. The act of storing pre-recorded messages is technically similar to editing a terminal's address book and needs no detailed description. One way to use the pre-stored messages is such that a speech synthesizer converts a text message to synthesized speech. Another possibility is that the pre-stored messages are pre-recorded audio messages, in which case the terminal user can respond with his/her own voice. The act of storing pre-recorded audio messages is technically similar to recording user voices in voice dialling and needs no detailed description.

The user interface UI shown in FIG. 6 can be used even in darkness if the currently-selected message 64 (synthesized or pre-stored) is read out to the terminal user via the terminal's earphone, and only when the terminal user presses the OK button, the selected message 64 is transmitted to the other party.

In the above description of the invention, a cursory reference was made to the use of profiles in connection with the mode server shown in FIG. 2. FIGS. 7 through 11 illustrate the use of profiles and redirection settings in more detail, in the context of further preferred embodiments of the invention.

Within this detailed description, the name “Bill” refers to the terminal user whose incoming calls will be processed according to the invention. The reason for this name is that Bill will be acting the called or B party during a call, and “Bill” begins with a B.

FIG. 7 illustrates Bill's address book 70 and caller groups 73. As used herein, a caller group means a set or group of potential callers (future A parties) sharing similar redirection settings. A call group can comprise one or several members. The address book 70 is basically similar to the address book stored in a SIM card that is attached to a GSM mobile telephone. The address book contains a record for each of Bill's contacts (persons or companies). Each record comprises a name field 71 and a number (or address) field 72. The name field 71 contains a free-format name, as is well known from conventional GSM telephones. The number/address field 72 may contain a conventional telephone number or any usable network address, such as an MSISDN number, TCP/IP address, e-mail address or the like.

Reference numeral 73 generally denotes Bill's caller groups. In this example, the caller group “Family” consists of the records for Alice, Bob and Cecilia. Another caller group “Colleagues” consists of the records for Dave L, Eric M and Frank W. The third caller group “Secretary” only comprises Bill's secretary Gail T. The fourth caller group “Friends” comprises Harry P and Ian R. The four first caller groups are formed explicitly, such that Bill explicitly adds records 70 (potential callers) to one of the caller groups 73.

In addition to explicit caller groups, there may be implicit caller groups, two of which are shown in FIG. 7. In this example, a first implicit caller group “others” comprises all the records 70 in the terminal's address book that do not belong to any of the explicit caller groups. As soon as a record 70 is added to one of the explicit caller groups, that record is removed from the “Others” group. The caller group “Others” may be used to indicate how to process calls from persons that are listed in Bill's address book 70 but do not belong to any of the explicit caller groups. Another implicit caller group “Unknown” comprises persons that are not stored in Bill's address book. The caller group “Unknown” may be used to indicate how to process calls from persons that are not known to the called party.

As regards the association of the records 70 and caller groups 73, what really matters to the reachability server/service is the association of a number/address field 72 and a caller group 73. This is because the reachability server detects the caller's identity based on the callers number (or other network address) 72. For the reachability server (and call processing in general), the name 71 is irrelevant. From Bill's point of view, however, it is much more convenient to associate a caller group 73 to a name 71 than to a number 72.

FIG. 8 illustrates reachability profiles 80. If the profiles 80 are stored in a centralized (network-based) mode server, the profiles have to be associated with a certain subscriber, such as the profile PR shown in FIG. 2. In FIG. 8, we assume that the profiles 80 are stored in a terminal-based mode server, or that the profiles are associated with a certain subscriber, although such association is not shown.

Each reachability profile 80 comprises at least a label (or identifier) field 81. According to a further preferred embodiment of the invention, a reachability profile 80 may also comprise a free-format presence information field 82. For example, the reachability profile “Meeting” comprises a presence information field 82 whose contents is “I am in a meeting . . . ” This presence information may be returned to a caller if the called party cannot answer calls.

According to another preferred embodiment of the invention, a reachability profile 80 may also comprise a default redirection setting field 83. The use of redirection settings will be explained in connection with FIG. 9.

FIG. 9 illustrates Bill's redirection settings 90. A redirection setting is a parameter that is used to answer the following question: what to do with a call setup request? The redirection setting indicates one or both of the following: 1) where (and whether) the call is redirected, and 2) which mode the call is changed into. An example of the first alternative is a setting which determines that an incoming call is to be redirected to a different number (or another network address). For example, a redirection setting may indicate that a call is first attempted to the B party's user terminal for five seconds, then to a home number for 10 seconds and then to an answering service. Alternatively, a call may be routed to an Internet address, either temporarily or during waiting. An example of the second alternative is a setting which determines that the call mode of an incoming call is changed to chat. In other words, if a voice call cannot be established, a chat connection may be set up instead. Thus the redirection setting may include a call mode indicator that indicates a changed call mode. For example, the changed call mode may indicate a silent communication for one or both of the parties.

Each redirection settings record 90 consists of a label (or identifier) field 91 and an actual redirection setting field 92. The label/identifier field 91 is preferably a free-format field, whereby Bill can enter short but descriptive names. From the point of view of the reachability server, however, any identifier is usable. The first redirection settings record 901 has a label field 91 of “OfficeFirst” and a redirection setting field 92 of “5sOffice#/5sMobile#/Answer#”. Herein, “Office#” stands for Bill's office telephone number, Mobile# stands for his mobile terminal number and Answer# stands for the number of the answering service (voice mail). The redirection setting field 92 of “5sOffice#/5sMobile#/Answer#” is interpreted so that a call to the office number is attempted first for five seconds, then the mobile terminal's number is attempted for another five seconds, and if that fails too, the call is redirected to the answering service. The next two records 902 and 903 are self-explanatory based on the previous example. The fourth redirection settings record 904 means that an incoming call will be redirected to the telephone of Bill's secretary. Records 905 and 906 indicate that a caller is redirected to URL addresses www.addr1.fi and www.addr2.fi, respectively. For instance, www.addr1.fi may be the address of a web page informing the caller that the terminal user is unable to receive calls, and www.addr2.fi may be the address of a more informative web page for more trusted callers.

Instead of a different number or network address, or in addition to it, the redirection setting field 92 may indicate a change of call mode. For instance, Bill may be in a library in which it is socially unacceptable to speak on the telephone but Bill may be able to chat via the telephone's keyboard or keypad. According to a further preferred embodiment, the call mode is processed separately for each half-call or direction of call, that is, for the incoming and outgoing directions. For instance, when eating in the restaurant, Bill may not be able to speak on the telephone but may be able to listen to the caller's voice and respond via a chat connection.

In the example shown in FIG. 9, the “>” and “<” signs mean change of call mode in the incoming and outgoing directions, respectively. For instance, redirection settings record 907, labelled “Chat”, has a redirection setting of “>Chat<Chat” which means that both the incoming and outgoing half-calls are converted to chat mode. The next record 908, labelled “Voice/Chat”, has a redirection setting of “<Chat” which means that only the outgoing half-call is converted to chat mode.

The last record 909, labelled “Voice/2KeyChat”, has a redirection setting of “<2KeyChat” which means that the outgoing half-call is converted to 2-key chat mode. The 2-key chat mode in the outgoing direction means that the mobile terminal user is able to listen to the caller's voice but is only able to respond with a very small number of keys, such as two or three. The two keys can be “yes” and “no”. An optional third key may mean “I don't know/understand”. The 2- (or 3-) key chat mode is useful in a situation where even conventional chatting is impossible. For instance, Bill may be in a concert, and calls from most caller groups are redirected to voice mail but calls from a babysitter are converted to 2-key chat mode. The babysitter, who may be facing an urgent problem, calls Bill. The alert of Bill's terminal is set to silent but vibrating. As soon as Bill feels the vibrating alert, he can place an ear-phone to his ear and take the call. The babysitter may then describe the situation and ask questions that can be answered by “yes” and “no” keys which Bill can memorize and use without taking the terminal out of his trouser pocket.

FIG. 10 illustrates associations 100 of (reachability) profiles 101, caller groups 102 and redirection settings 103. The first association 1001 associates profile “Work” and caller group “Family” with redirection setting “OfficeFirst”. This means that whenever profile “Work” is Bill's current profile, calls from members of the “Family” group are processed according to redirection setting “OfficeFirst”. This redirection setting was described as record 901 in FIG. 9. In the example shown in FIG. 10, there are six associations, namely 1001 to 1006, for the profile “Work”. Associations 1001 to 1003 specify that calls from members of the “Family”, “Colleague” and “Secretary” groups are processed according to redirection setting “OfficeFirst”, while calls from “Friends”, “Others” and “Unknown” groups are processed according to redirection setting “Secretary”, which means that the call is routed to Bill's secretary.

The example shown in FIG. 10 does not have an association for each combination of profile, caller group and redirection setting. This is because this example makes use of the (optional) default redirection setting field 83 shown in FIG. 8. For instance, the profile “Abroad” has a default redirection setting of “MobileFirst” which is used unless an overriding association for some caller groups have been specified. FIG. 10 shows an association 1031 of profile “Abroad”, caller group “Unknown” and redirection setting “VoiceMail”. This means that when Bill is abroad, he does not wish to take calls from unknown callers because he would have to pay for those calls. Accordingly, calls from unknown callers are routed to voice mail.

An advantage of the profiles and redirection settings is that it is very easy for users to change their reachability settings, even when there are multiple caller groups, all requiring different reachability settings. Because the profiles are separated from the redirection settings, the profiles may be very simple and, in a simple embodiment, only a profile name or indicator is necessary.

The invention is preferably implemented by co-operation between the terminal and an element (mode server) in the fixed network. This co-operation is further improved by setting the alert of the terminal automatically to silent/vibrating if the current profile of the B party indicates silent communication. This way, the user does not have to select a profile that indicates silent communication and silence the terminal's alert separately.

Preferably, the profiles comprise presence information and/or instructions which is/are returned to the A party. For example, the presence information/instructions may indicate “I am in a meeting, please dial 1 if you wish to leave a message, or, dial 2 if you have urgent business; I can reply by chatting”.

FIG. 11 is a flow chart illustrating the operation of a reachability server. FIG. 11 shows a preferred implementation of steps 3-14 and 3-16 shown in FIG. 3. In step 1101, the reachability server receives and stores in memory Bill's caller lists 70 (of which only field 72 is essential) and caller groups 73 (see FIG. 7), his profiles 80 (see FIG. 8), redirection settings 90 (see FIG. 9) and associations 100 of the above three types of data (see FIG. 10). Step 1101 can take place in one go or in a distributed manner. In other words, Bill can indicate the settings 70, 73, 80, 90 and 100 during one session, or he may update previous settings.

Dashed lines 1102 and 1105 denote occasions in which the reachability server waits for more actions from Bill or a caller, respectively. In step 1103, Bill's reachability settings change and he updates his current profile in the reachability server. In other words, he indicates the current one of the pre-existing profiles stored in the reachability server. For instance, if Bill is about to enter an airplane, he selects “Flight” as his current profile.

The remaining steps 1111 to 1118 relate to processing of one call. In step 1111, the reachability server detects a call to Bill from an A user. In step 1112, the reachability server retrieves Bill's current profile. In step 1113, the reachability server determines the A user's identity. For example, the A user can be identified by means of a Calling Line Indicator (CLI). In step 1114, the reachability server determines the A user's caller group, that is, the caller group 73 corresponding to the A user's identity 71. In step 1115, the reachability server attempts to retrieve the redirection settings record 100 corresponding to the A user's caller group 73 and Bill's current profile 80. In step 1116, it is checked if such a redirection settings record could be determined, which means that there was an association corresponding to the A user's identity and Bill's current profile. If yes, the process continues to step 1118 in which the call is processed according to the redirection settings.

According to a preferred embodiment, if the check in step 1116 failed, the process continues to step 1117 in which it is checked if Bill's current profile indicates a default redirection setting. For instance, each of the profiles “Theatre”, “Flight” and “Abroad” in FIG. 8 do indicate a default redirection setting. If Bill's current profile indicates a default redirection setting, the process again continues to step 1118 in which the call is processed according to the (default) redirection settings.

If checks 1116 and 1117 both fail, the process continues to step 1119 in which the call is processed normally (no redirection or mode change).

An advantage of the profiles and redirection settings as shown in FIGS. 7 to 11 is that the terminal user has to send the reachability server only one piece of information, namely an indicator of the current profile, whenever the reachability conditions change. The caller groups, profiles and redirection/call mode settings are pre-stored and are changed much less often. Because the caller groups, profiles and redirection/call mode settings are pre-stored at the reachability server (or are otherwise accessible by it), call processing is much more flexible than in a system which only supports a single redirection setting to all callers.

Further Enhancements to the Mode/Reachability Server

Preferably, the mode server MS and the reachability server RS (or equivalent functions in other network elements) support as many as possible from the following redirections and mode changes:

- 1. redirection to another telephone;
- 2. redirection to voice mail;
- 3. timed redirection to another telephone/voice mail (e.g. five seconds to office phone, 5 seconds to mobile phone, then to voice mail;
- 4. sending the caller a data message, such as a short message or an MMS (Multimedia Messaging Specification) message, or a partial or whole web page;
- 5. sending the caller a network address, such as a URL, preferably formatted as a link, wherein the network address contains more detailed information;
- 6. conversion of incoming and/or outgoing call to chat or limited chat (e.g. 2-key chat);
- 7. conversion of incoming and/or outgoing voice to text or vice versa;
- 8. providing additional services (music, video, games . . . ) during waiting;
- 9. personalized voice answering in the answer service (network-based or terminal based); that is, the voice information depends on A's caller group and B's current profile;

Option 6 is implemented without text-to-speech or speech-to-text conversion. That is, if B can only chat but not talk, then a chat connection is established in at least one direction. For instance, A can talk to B but B will type his responses. Alternatively, both parties can resort to chatting. Option 7 requires text-to-speech or speech-to-text conversion. For instance, A can talk and B's typed responses are converted to speech.

The invention is useful if one or both parties of a call cannot speak on a telephone, regardless of why such two-way speaking is impossible. Two-way speaking may be prohibited by law or etiquette, or one or both parties may be physically handicapped. It is readily apparent to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

Acronyms:

CLI: Calling Line Indicator

GSM: Global System for Mobile Communication

MSISDN: Mobile Subscriber Integrated Services Data Network

PSTN: Public Switched Telephone Network

SIM: Subscriber Identity Module

TCP/IP: Transport Control Protocol/Internet Protocol

UMTS: Universal Mobile Telecommunications System

URL: Uniform Resource Locator

VoIP: Voice over Internet Protocol

Communication mechanism for calls in which speaking is not possible

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims

Priority Claims (1)

PCT Information