GB2449762A

GB2449762A - A telephone call answering system

Info

Publication number: GB2449762A
Application number: GB0809756A
Authority: GB
Inventors: Martin Friedgut
Original assignee: Individual
Current assignee: Individual
Priority date: 2007-05-30
Filing date: 2008-05-29
Publication date: 2008-12-03
Also published as: AU2008202383A1; GB0809756D0

Abstract

Disclosed is an answering system (900) configured to interact with a calling phone (536, 540) and a called cellphone (532). The system (900) includes a user interface module in the called cellphone (532) which is configured to establish one of a wait-for-me mode and a take-the-call mode. In the wait-for-me mode a control module (921) (a) advises the called cellphone (532) that an incoming call (909) from the calling phone (536, 540) is being parked or placed on hold, and (b) connects the incoming call (909) to a message module (922). In the take-the-call mode the control module (921) connects the incoming call from the calling phone (536, 540) to a voice interface (902) of the called cellphone (532). The message module (922) is configured, in the wait-for-me mode, to play a wait-for-me message to the calling phone (536, 549). The call may be rejected after being placed on hold, the call may timeout after a predetermined time on hold the on hold message may vary depending on the caller i.d. of the incoming call.

Description

AN ANSWERING SYSTEM

Field of the Invention

The present invention relates generally to cellular telephones (also referred to in this description as celiphones), and in particular to arrangements by which a user of a celiphone is better able to manage telephone calls using his cellphone.

Background

Cellular telephones have proliferated in many parts of the world, and users can be contacted almost anywhere, and at any time in such countries. This can be useful for the user who wishes to be contactable anywhere and at any time.

Summary

It has been recognized that the very ubiquity of cellular telephone availability has led, in many instances, to a discarding of manners in human affairs into which the cellular telephone intrudes, in effect, the ability to reach someone anywhere and at any time can sometimes be disturbing and unpleasant for other people in the vicinity of the user.

It is an object of the present invention to ameliorate one or more disadvantages of existing arrangements.

Disclosed are arrangements, referred to as "Polite Mode Call Handling" arrangements, otherwise referred to as PMCH arrangements in this description. The PMCH arrangements enable a user to park an incoming call and automatically advise the calling party to wait on the line while the called party (ie the user) excuses himself and moves away from the people he or she is with when the call came in. Thus, for instance, the PMCH arrangement can play a pre-recorded outgoing message (referred to as a "wait-for-me message" or merely as a "message" in this description) asking the caller to wait a few moments while the called party (ie the user) waits a polite interval before excusing himself and moving away from the people he or she is with when the call came in order to take the call.

The called party thus need not immediately answer or indeed react to the incoming call, which might disturb andlor annoy the person or people he is with. The user can instead keep his attention on the people or person he or she is with and then, after a polite delay, excuse himself knowing that the calling party has been asked to wait a few moments on the line. The user can then exit the room in a polite manner and take the call without unduly disturbing the people he was with.

The PMCH arrangements can, if desired, be preset by the user and then automatically initiated by an incoming call. Alternately, the user may manually activate the PMCH arrangements upon receiving an incoming call by depressing a sequence of keys on the celiphone when the user detects an incoming call.

The PMCH arrangements can be implemented in a stand-alone fashion using software residing and executing on the celiphone (this being referred to as the cellphone-centric approach). The PMCH arrangements can alternately be implemented by the celiphone communicating with signalling and control modules external to the celiphone (eg in the network) and a message server that is accessible over the network (this being referred to as the network-centric approach). Other arrangements including hybrid versions of the celiphone-centric and network-centric arrangements can also be used.

In a further refinement, personalised wait-for-me messages can, if desired, be recorded for people whose Calling Line Identifiers (CLIs) are available. The personalised wait-for-me messages can be stored, indexed by their associated CLI. These personalised wait-for-me messages can subsequently be played to calling parties for whom they have been recorded. A default message can be played if the incoming CLI is not recognized or available.

Messages can, if desired, be recorded by the user, or can be downloaded from a remote download server over the network.

The PMCH arrangements can, if desired, be used while the celiphone is set to "silent" (ie vibration) mode, or while the celiphone is set to normal "ring" mode.

According to a first aspect of the present invention, there is provided an answering system (900) configured to interact with a calling phone (536, 540) and a called celiphone (532), the system (900) comprising: a user interface module (908) in the called cellphone (532), said user interface module (908) being configured to establish one of a wait-for-me mode and a take-the-call mode, wherein: in the wait-for-me mode a control module (921) (a) advises the called celiphone (532) that an incoming call (909) from the calling phone (536, 540) is being parked, and (b) connects the incoming call (909) to a message module (922); and in the take-the-call mode the control module (921) connects the incoming call (909) from the calling phone (536, 540) to a voice interface (902) of the called cellphone (532); the control module (921); and the message module (922) being configured, in the wait-for-me mode, to play a wait-for-me message to the calling phone (536, 549).

According to another aspect of the present invention, there is provided a method of handling an incoming call from a calling phone to a called cellphone, said method comprising the steps of: establishing by the called celiphone a wait-for-me mode, and in said wait-for-me mode; advising the called called cellphone that an incoming call from the calling phone is being parked; connecting the incoming call to a message module; and playing by the message module a wait-for-me message to the calling phone; establishing by the called celiphone a take-the-call mode and in said take-the-call mode: connecting the incoming call from the calling phone to the called cellphone.

According to another aspect of the present invention, there is provided a system for handling an incoming call from a calling phone to a called celiphone, said system comprising: at least one memory for storing a program; and at least one processor for executing the program, said program comprising: code for establishing by the called celiphone a wait-for-me mode; code for advising in said wait-for-me mode the called called celiphone that an incoming call from the calling phone is being parked; code for connecting in said wait-for-me mode the incoming call to a message module; and code for playing in said wait-for-me mode by the message module a wait-for-me message to the calling phone; code for establishing by the called cellphone a take-the-call mode and in said take-the-call mode: and code for connecting in said take-the-call mode the incoming call from the calling phone to the called celiphone.

According to another aspect of the present invention, there is provided a computer program product including a computer readable medium having recorded thereon a computer program for directing at least one processor to execute a method for handling an incoming call from a calling phone to a called celiphone, said program comprising: code for establishing by the called celiphone a wait-for-me mode; code for advising in said wait-for-me mode the called called celiphone that an incoming call from the calling phone is being parked; code for connecting in said wait-for-me mode the incoming call to a message module; and code for playing in said wait-for-me mode by the message module a wait-for-me message to the calling phone; code for establishing by the called cellphone a take-the-call mode and in said take-the-call mode: and code for connecting in said take-the-call mode the incoming call from the calling phone to the called celiphone.

Other aspects of the invention are also disclosed.

Brief Description of the Drawings

Some aspects of the prior art, and one or more embodiments of the present invention will now be described with reference to the drawings, in which: Fig. 1 is a schematic diagram of an example system in which a celiphone-centric PMCH arrangements can be practiced; Fig. 2 is a process flow chart showing operation of another PMCH arrangement using the system of Fig. 9; Fig. 3 is a process flow chart showing how a (default) wait-for-me message can be recorded for use in the PMCH arrangement in Fig. 2; Figs. 4A and 4B are process flow chart fragments showing how personalised wait-for-me messages can be recorded for use in the PMCH arrangement in Fig. 2; Fig. 5 is a process flow chart showing how the personalised wait-for-me messages recorded in Figs. 4A and 4B can be used in the PMCH arrangement in Fig. 2; Fig. 6 shows a process flow chart fragment of a prior art telephone answering machine, in which the arrangements associated with the personalised wait-for-me messages described in relation to Figs. 4A, 4B and 5 can be incorporated, to form a personalised-message answering machine; Fig. 7 is a schematic diagram of an example system in which network-centric PMCH arrangements can be practiced; Fig. 8 is a signal flow diagram of operational scenarios for the network-centric PMCH system of Fig. 10; Fig. 9 is a functional block diagram representation of a celiphone-centric PMCH system that can be implemented using the system of Fig. 1; Fig. 10 is a functional block diagram representation of a network-centric PMCH system that can be implemented using the system of Fig. 7; and Fig. 11 is a signal flow diagram of operational scenarios for the celiphone-centric PMCH system of Fig. 9.

Detailed Description including Best Mode

Where reference is made in any one or more of the accompanying drawings to steps andlor features which have the same reference numerals, those steps andlor features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

Fig. 1 is a schematic diagram of a system 500 comprising a called cellphone 532 and an associated network 506 in which disclosed celiphone-centric PMCH arrangements can be practiced. The called celiphone 532 is connected to the network 506 by a radio connection 508. The term "network" (exemplified by 506) refers to the transmission and switching elements necessary to connect a calling device (such as a calling cellphone 536 or a calling fixed phone 540) and the called celiphone 532, whether the network is based on circuit switching technology (as in the Public Switched Telephone Network which is also referred to as the PSTN), or on packet switching technology (as in Voice over the Internet Protocol or VOIP using the Internet). The terms called celiphone and calling S phone are used for ease of understanding, and are not intended to limit the functionality of the aforementioned devices. Thus the called celiphone 532 can also make calls, and the calling phones 536, 540 can also receive calls.

A remote download server 502 is connected, as depicted by an arrow 504, to the network 506. The called celiphone 532 can thus communicate with the calling cellphone 536 via the network 506 and a connection 538, or with the calling fixed phone 540 via the network 506 and a connection 542. The called celiphone 532 can also communicate with the remote download server 502 over the network 506 in order, for example, to download pre-recorded wait-for-me messages from the remote download server 502 to be stored in a memory 528 in the called celiphone 532.

The called cellphone 532 can be implemented in the form of a special purpose computer that comprises a network interface 510, a processor 512, a Read Only Memory (ROM) 514, a Random Access Memory (RAM) 528, a user interface 530 and special purpose hardware/software module 544. These modules are interconnected as depicted by respective arrows 516, 518, 520, 526, 524 and 546 to a bus 522 over which the various modules communicate in a manner known in the art of computers.

Non-volatile storage of data can be provided by incorporating a suitable long life battery (not shown) in the called cellphone 532 which provides power to the RAM 528 to ensure that data is not lost when the called celiphone 532 is powered down. Alternately, non-volatile flash memory (not shown) can be incorporated in the called cellphone 532, this enabling data to be written to the flash memory which does not lose the data so written when power is removed from the flash memory.

The network interface 510 comprises transmitter and receiver modules and other modules known in the art for communicating over the radio path 508 with the network 506. The user interface 530 comprises one or more of a keyboard, display, microphone and loudspeaker.

A computer software program 534 (in the form of computer code and data), shown as being stored in the ROM 514, is used by the processor 512 in conjunction with the other cellphone modules to perform the known functions of the called celiphone 532 as well as individual steps of the disclosed PMCH method(s) described herein with reference to Figs. 11, 2-5, and 8.

Some portions of the following description are presented, explicitly or implicitly, in terms of algorithms and symbolic representations of operations on data stored in a computer memory such as the ROM 514 and the RAM 528. The aforementioned approach is used by those skilled in the data processing arts to convey their work to others skilled in the art. An algorithm is a self-consistent sequence of process steps leading to a desired result. The steps are generally those requiring physical manipulations of physical quantities. The physical quantities include, but are not limited, to electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is convenient to refer to these signals as parameters, signals, quantities, bits, values, elements, symbols, characters, terms, numbers, or the like.

The above and similar terms are to be associated with the appropriate physical quantities, and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, in relation to those portions of the description that relate to operations performed in the system 500 in Fig 1, discussions utilizing terms such as "interact", "calling", "called", "establish", "advise", "connect", "play", "terminate", "record", "download" "park", or the like, refer to the actions and processes of various modules of the system 500, or similar electronic device, that manipulate and transform data represented as physical (electronic) quantities within the registers and memories of the system 500 into other data similarly represented as physical quantities within the system memories or registers or other such information storage, transmission or display devices.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various machines may be used with programs in accordance with the teachings herein.

In addition, the disclosed PMCH arrangements disclose the PMCH computer software program and data 534 (see Fig. 1), in regard to which the individual steps of the disclosed PMCH method(s) described herein with reference to Figs. 11, 2-5, and 8, for example, are put into effect by computer code. The computer program 534 is not intended to be limited to any particular programming language and implementation thereof. A variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program 534 is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows withoi4 departing the spirit or scope of the disclosed PMCH arrangements. Furthermore one or more of the steps of the computer program 534 may be performed in parallel rather than sequentially.

Such a computer program 534 may be stored on any computer readable medium.

The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a computer.

The computer readable medium may also include a hard-wired transmission medium such as exemplified in the Internet system, or wireless transmission medium such as exemplified in the GSM mobile telephone system.

The PMCH arrangements may thus be implemented using the computer system 500, such as that shown in Fig. 1 wherein the processes of Figs. 11, 2-5, and 8 may be implemented as software, such as one or more application programs 534 executable within the computer system 500. In particular, the PMCH method steps are effected by instructions in the software 534 that are carried out within the computer system 500. The instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules perform the PMCH methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

The software may be stored in a computer readable medium, including the storage and/or transmission devices and media described above, for example. The software is loaded into the computer system 500 from the computer readable medium, and then executed by the computer system 500. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer system 500 preferably effects an advantageous PMCH apparatus.

As seen in Fig. 1, the system 500 is formed by the called celiphone 532 having input devices 530 such as a keyboard (also referred to as a keypad) and a microphone, and output devices including a display device and loudspeaker. The network interface 510 is used by the called cellphone 532 for communicating, for example, to and from the remote download server 502 and/or the calling cellphone 536 over the communications network 506 via the connection 508. The network 506 may be a wide-area network (WAN), such as the Internet or a private WAN, and may include wireless networks such as the GSM network and so on. The radio connection 508 may be narrow or broad-band.

Typically, the application programs 534 discussed above are resident in the ROM 514 and read and controlled in execution by the processor 512. Intermediate storage of such programs and any data fetched from the network 506 may be accomplished using the semiconductor RAM 528. In some instances, the application programs 534 may be supplied to the user over the network 506. Still further, the software can also be loaded into the called celiphone 532 from other computer readable media. Computer readable media refers to any storage or transmission medium that participates in providing instructions andlor data to the called celiphone 532 for execution andlor processing.

Examples of such storage media include a ROM or integrated circuit and the like, whether or not such devices are internal or external of the called celiphone 532.

Examples of computer readable transmission media that may also participate in the provision of instructions and/or data include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

The second part of the application programs and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display in the user interface 530.

Through manipulation of the keyboard in the user interface 530, a user of the called cellphone 532 and the application 534 may manipulate the user interface 530 to provide controlling commands and/or input to the applications associated with the GUI(s).

Fig. 9 is a functional block diagram representation of a celiphone-centric PMCH system 900 that can be implemented using the system of Fig. 1. The system 900 comprises the calling phone 536 or 540 (only the calling celiphone 536 will be referred to in the remainder of the description for Fig. 9 for the sake of simplicity), the network 506, the called celiphone 532, and the download server 502 (see Fig. 1). Fig. 9 includes solid -12 -lines (such as 909) that depict traffic connections (such as voice traffic) between modules.

Dashed lines (such as 920) depict control or signal connections between modules.

The calling phone 536 has a voice interface 901 and a user interface 903. The voice interface 901 typically comprises a loudspeaker and a microphone which are the components that are operative in conveying voice information to and from the user of the calling phone 536. The user interface 903 typically comprises a keypad (using either or both hard keys or soft keys displayable on a display) and a display. The calling device voice interface 901 is connected to the calling device user interface 903 by a solid line 924. This indicates that the user of the calling phone 536 can generate a voice command via the voice interface 901, and this command is conveyed to the user interface 903 to emerge from the user interface 903 as, for instance, depicted by a dashed line 911.

The called celiphone comprises a message module 922 and a signal/control module 921. The incorporation of these functional modules into the called celiphone 532 enables the called cellphone 532 to practice the PMCH arrangement without specialised capabilities being provided in the network 506. In other words, the system 900 supports the PMCH capability by virtue of capabilities included in the called celiphone 532, and thus this arrangement is referred to as a celiphone-centric PMCH arrangement.

The message module has a wait-for-me message store 906, and a leave-a-message store 907. The signal/control module 921 has a controller 904 and a switching module 905. The called cellphone 532 also has a voice interface 902 and a user interface 908. The voice interface 902 typically comprises a loudspeaker and a microphone. The user interface 908 typically comprises a keypad (using either or both hard keys or soft keys displayable on a display) and a display. The called device voice interface 902 is connected to the called device user interface 908 by a solid line 923. This indicates that the user of the called phone 532 can generate a voice command via the voice interface -13 - 902, and this command is conveyed to the user interface 908 to emerge from the user interface 908 as, for instance, depicted by a dashed line 920.

The signal/control module 921 and the message module 922 in the called celiphone can typically be implemented using the processor 512 in conjunction with the PMCH application software 534, and/or the special purpose hardware/software module 544 (see Fig. 1). The message module 922 can be implemented using the processor 512 in conjunction with the ROM 514 and the RAM 528, and/or using the special purpose hardware/software module 544.

In the PMCH arrangement shown in Fig. 9, in regard to control and signalling, the user interface 908 communicates, as depicted by the dashed line 920 with the controller 904. The controller 904 communicates with the switch 905, the wait-for-me message store 922, and the leave-a-message store 907 as depicted by respective dashed lines 917, 918 and 919. The controller 904 also communicates with the calling device voice interface 901, the calling device user interface 903, and the download server 502, as depicted by respective dashed lines 910, 911 and 916.

In regard to voice traffic (which may in some cases include) an incoming call connection is established between the calling device voice interface 901 and the switch 905 as depicted by the solid line 909. A voice signal connection is also established between the download server 502 and the switch 905 as depicted by a solid line 912. The switch 905 can establish a connection between the incoming traffic incoming on 909, and/or the wait-for-me message from the download server 502 on 912, to the wait-for-me message store 906 as depicted by the solid line 915, or to the leave-a-message store 907 as depicted by the solid line 914, or to the called device voice interface 902 as depicted by the solid line 913. Operational scenarios for the celiphone-centric PMCH system 900 will be described with reference to the signal flow diagram of Fig. 11.

-14 -Although Fig. 9 depicts a particular functional module arrangement and distribution of functionality, other functional arrangements can be used provided that they can support the same general functionality described in relation to Fig. 9.

Fig. 11 is a signal flow diagram of operational scenarios for the celiphone-centric PMCH system of Fig. 9. Other scenarios are described with reference to Figs. 2-5 and 8. Dotted lines (such as 1102) depict signalling/control connections between functional modules (such as the called device user interface 908 sending a signal/control signal to the signal and control module 921 in the case of the dotted arrow 1102). Solid lines (such as 1103) depict traffic connections between operational modules (such as traffic being connected between the calling phone 536 and the signal and control module 921 in the case of the solid line 1103). Dash-dot lines (such as 1105) depict voice communication taking place over the corresponding traffic connection (such as voice communication flowing from the message module 922 and the calling phone 536 in the case of the dash-dot arrow 1105, which takes place over the connection 1104).

In one operational example (ie the "wait-for-me" mode between heavy solid lines 1101 and 1107), prior to going into a meeting, the user of the called cellphone 532 uses the called device user interface 908 (in Fig. 9) to communicate, as depicted by the dotted arrow 1102, from the user interface 908 to the control module 921 in order to establish the "wait-for-me" mode (via 920 in Fig. 9). This is the operational mode during which the user can participate in the meeting without needing to react immediately when an incoming call arrives at his called celiphone 532 from the calling celiphone 536 (see 909 in Fig. 9).

As depicted by the solid line 1103 the incoming call from the calling phone 536 (see 909 in Fig. 9) is connected to the control module 921 (and in particular to the switch 905), which establishes a connection, as depicted by a solid line 1104, to the message module 922 (and in particular the wait-for-me message store 906) as depicted by the -15 -concatenation of 909 and 915 in Fig. 9. The wait-for-message store 906 then plays, as depicted by a dash-dot line 1105, a wait-for-me message telling the user of the calling celiphone 536 to wait on the line. The wait-for-me message module 906 in this example is controlled, as depicted by the dashed line 918, by the controller 904 (see Fig. 9).

S The control module 921 (and in particular the controller 904) communicates, as depicted by a dotted line 1106 with the called device user interface 908 (see 920 in Fig. 9) to alert the user of the called cellphone 532 that an incoming call has been parked and is waiting. This alert signal 1106 can take the form of a single chime, or a flash on the display (using components of the user interface 530). Knowing that the incoming call has been parked, the user of the called celiphone 532 need not react immediately to the incoming call, and can instead keep her attention on the person to whom she is talking.

Then after a polite interval, she can excuse herself, move away and attend to the call as described below.

Moving to the "take the call" mode of Fig. 11 (between the heavy lines 1107 and 1113) the user of the called celiphone 532, after a reasonable polite interval, signals as depicted by a dotted line 1108 (see 920 in Fig. 9) from the called cellphone user interface 908 to the control module 921 (and in particular the switch 905) the user's readiness to take the incoming call. The controller 904 then establishes a connection for the incoming call between the calling phone 536 voice interface 901 and the called device voice interface 902 as depicted by a solid line 1109 (formed by concatenating 909 and 913 in Fig. 9). The respective users of the calling phone 536 and the called phone 532 speak to each other in a normal manner, as depicted by a dashed arrow 1110. When they complete their conversation, the connection is terminated as depicted by "X" symbols 1111and 1112.

In the event that the user of the called celiphone 532 decides, some time after receiving the alert signal 1106, that it would not be polite to take the incoming call after -16-all, the user can establish the "reject-the-call" mode (between heavy lines 1113 and 1118), using the user interface 908 to generate a signal depicted by a dotted arrow 1114, from the user interface 908 to the control module 921. The control module 921 then directs the message module 922 to advise the calling party, as depicted by a dash-dot line 1116, that the called party is unable after all to take the call. In one arrangement, this communication 1116 asks the calling party if they wish to leave a message for the called party, and if this option is taken up, the calling party can leave a message on the leave-a-message store (via a concatenation os 909 and 914 in Fig. 9). The control module 921 then terminates the call as indicated by an "X" symbol 1117.

In the event that the user of the called cellphone 532 is unable, some time after receiving the alert signal 1106, to either take the call (by establishing the take-the-call mode) or to actively reject the call (by establishing the reject-the-call mode), then the control module 921 establishes a timeout mode (between heavy lines 1118 and 1122). In this mode the control module 921 directs the message module 922 to advise the calling party, as depicted by a dash-dot line 1120, that the called party is unable after all to take the call. In one arrangement, this communication 1120 asks the calling party if they wish to leave a message for the called party, and if this option is taken up, the calling party can leave a message on the leave-a-message store (via a concatenation of 909 and 914 in Fig. 9). The control module 921 then terminates the call as indicated by an "X" symbol 1121.

Fig. 2 is a flow chart of a process 102 showing another PMCH arrangement using the system of Fig. 9. The process commences with a step 108 in which the controller 904 in Fig. 9 determines if an incoming call has been detected over the connection 909 from the calling phone 536. If this is not the case, then the process 102 follows a NO arrow from the step 108 back to the step 108. If however a call has been detected, then the process 102 follows a YES arrow from the step 108 to a step 114. -17-

In the step 114 the controller 904 determines if the "Polite Mode" (also referred to as the wait-for-me mode) has been preset. This mode can be set, for example, by the user of the called celiphone 532 having previously depressed a pre-programmed key or key sequence on the keypad in the user interface 908 prior to going into a meeting, so that the wait-for-me mode would be operational for any calls received during the meeting.

Alternately the called phone 532 can be programmed to activate the wait-for-me mode upon startup ie when powering up the celiphone. Other mechanisms for activating the wait-for-me mode can also be used.

If the Polite Mode is active, then the process 102 follows a YES arrow from the step 114 to a step 122 in which the controller 904 signals the called party (see 1106 in Fig. 11) that an incoming call has been detected, waits for a preset number of rings, and then picks up the incoming call via the network interface 510, thus placing the called cellphone 532 in an "off-hook" state. The incoming call is not, however, connected through to the voice interface 902 of the called celiphone 532, and is instead connected to is the wait-for-me message store 906 which generates the wait-for-me message as described below.

The signal 1106 that the controller 904 arranges to send to the user in the step 122 is typically an unobtrusive signal, such as a single chime and a vibration, as might be used to signal an incoming Short Message Service (SMS) message. This minimises the disturbance to other people in the vicinity of the called party. Clearly however the signal should be of a sufficient power to ensure that the called party is aware that an incoming call has been detected.

As noted above, the step 122 waits for a preset number of rings, and then picks up the incoming call via the network interface 510, thus placing the called cellphone 532 in an off-hook state. The aforementioned rings are audible to the calling party ie the user of the calling phone 536, however they are not made audible to the called party (ie the -18-user of the called celiphone 532), and serve merely to provide the calling party with a normal interval before the call is picked up. The number of rings that are preset can be adjusted as desired.

The process 102 then follows an arrow 132 from the step 122 to a step 128 in which the controller 904 directs the wait-for-me message store 906 to play a pre-recorded walt-for-me message to the calling party. The wait-for-me message is audible to the calling party, but is not audible to the user of the called cellphone 532 (ie the called party). The wait-for-me message can either be a default message that is played to all incoming callers, or alternately it can be a customised personalised message, which is selected on a per-incoming-caller basis. The message is stored in the RAM 528 and/or in the ROM 514, as described in more detail in regard to Figs. 3-5.

The process 102 then follows an arrow 142 from the step 128 to a step 140, in which the controller 904 determines if an end-of-message command has been received.

This end-of-message command can be generated in various ways. In one example, the end-of-message command is generated when the user of the called celiphone 532 presses a pre-defmed pre-programmed key on the keypad in the user interface 908 to signal (see 1108) when he or she is ready to take the call. In another example the user of the called celiphone 532 can press any key in order to terminate the wait-for-me message (generating the signal 1108) and take the call. In yet another example, the end-of-message command can be generated when the controller 904 detects a voice other than the wait-for-me message on the communication channel (also referred to as the communication circuit, or merely as the circuit), eg by the user of the called cellphone 532 speaking into the voice interface 902 which effects a voice command via 923 and the user interface 908 to the controller 904, or when a pre-defmed time has elapsed since the wait-for-me message was started. The wait-for-me message can in one arrangement be played once, or in another arrangement, can be repeated until the end-of-message command is received.

-19 -If the step 140 outputs a logical FALSE value, then the process 102 follows a NO arrow from the step 140 back to the step 128. If on the other hand the step 140 determines that the end-of-message command has been received, then the process 102 follows a YES arrow from the step 140 to a step 144.

In the step 144, the controller 904 terminates the wait-for-me message, and maintains the communication channel open (ie does not hang up the phone by shutting down the communication channel) as depicted by 1109. In a following step 148, the controller 904 continues to maintain the communication channel open so that communication can proceed between the calling party and the called party (depicted by 1110). In a following step 158, the controller 904 determines if a "hang-up" command has been received. The hang-up command is typically generated when the user of the called celiphone 532 (ie the called party) presses a pre-programmed key on the keypad in the user interface 530. If the hang-up command is not received, then the process 102 follows a NO arrow from the step 158 back to the step 148. If on the other hand a hang-up command has been received, then the process 102 follows a YES arrow from the step 158 to a step 154 in which the controller 904 shuts down the communication channel via the network interface 510, thereby terminating the call, and placing the called cellphone 532 in an on-hook state (depicted by the X symbols 1111 and 1112). The process 102 then follows an arrow 106 from the step 154 back to the step 108.

Returning to the step 114, if the controller 904 determines that the Polite Mode has not been preset, then the process 102 follows a NO arrow from the step 114 to a step 124, and in the mean time, the called cellphone 532 rings in the "normal" way, ie in a maimer that enables the cellphone user and anyone in the vicinity, to hear the ringing sound.

In the step 124, the controller 904 determines if a manual polite mode command has been detected. This can occur, for example, when the user of the called cellphone 532 -20 -feels the phone vibrate in his pocket, remembers that he forgot to preset the polite mode (using 1102 for example), and quickly presses the pre-programmed key on the keypad (in the user interface 908) that commands the controller 904 to activate the polite mode. If the step 124 detects a manual polite mode command, then the process follows a YES arrow from the step 124 to a step 166. In the step 166 the controller 904 picks up the call (placing the called celiphone 532 in the off-hook state and terminating the ringing sound that is audible to the user of the called celiphone 532 and the other people in the vicinity) and the process 102 follows an arrow 168 to the step 128.

If the step 124 does not detect a manual polite mode command, as for example would occur if the user of the called cellphone 532 has left his phone unattended on his desk without the polite mode being preset, then the process 102 follows a NO arrow from the step 124 to a step 136, and in the mean time, the called cellphone 532 rings in the "normal" way, ie in a manner that enables the user of the called cellphone 532 user anyone in the vicinity, to hear the ringing sound. In the step 136, the controller 904 determines if the incoming call has been terminated, as would occur if either the called party rejects the call (eg by pressing the "clear" key), or if the calling party hangs up without the called party answering the call.

If the step 136 does not detect that the call has been terminated, then the process 102 follows a NO arrow from the step 136 back to the step 114, and in the meantime, the called celiphone 532 rings in the "normal" way, ie in a manner that enables the user of the called cellphone 532mand anyone in the vicinity, to hear the ringing sound. If the step 136 does detect that the incoming call has been terminated, then the process 102 follows a YES arrow from the step 136 back to the step 108.

Fig. 3 is a flow chart showing a process 200 of how a (default) wait-for-me message can be recorded for use in the PMCH arrangement in Fig. 2. The process 200 commences with a start step 202 in which the controller 904 detects if a manual record or a download command has been detected. The user of the called celiphone 532 can provide the aforementioned commands by, for example, depressing relevant pre-programmed keys on the keypad in the user interface 530. If neither of these commands has been detected, then the process 200 follows a NO arrow from the step 202 back to the step 202.

If on the other hand the step 202 detects a manual record command (generated, for example, by the user depressing the relevant pre-programmed key on the keypad in the user interface 530), then the process 200 follows a MANUAL arrow from the step 202 to a step 206. In the step 206 the controller 904 activates a record control program, that in a subsequent step 210, enables the user to record a message by dictating the message into the microphone in the user interface 530, this dictated message being recorded and stored in the RAM 528 for later playback. The process 200 then follows an arrow 205 from the step 210 back to the step 202.

Returning to the step 202, if the step detects a download command (generated, for example, by the user depressing the relevant pre-programmed key on the keypad in the user interface 530, ie the called voice interface 902), then the process 200 follows a DOWNLOAD arrow to a step 208. In the step 208 the controller 904 activates a download control program that, in a subsequent step 212, enables the user to download a message from the remote download server 502 over the network 506 (see Fig. 1). This downloaded message is stored in the RAM 528 (ie in the wait-for-me message store 906) for later playback. The process 200 then follows an arrow 204 from the step 212 back to the step 202.

Figs. 4A and 4B are flow chart fragments 400 and 420 showing how the user of the called cellphone 532 can record personalisec wait-for-me messages for use in the PMCH arrangement in Fig. 2.

When a calling party, using the calling phone 536, cafls a called party using the called cellphone 532, the calling party's Calling Line Identifier (CLI) can, if the network -22 - 506 supports this capability, be provided to the called party. The CLI of the calling party is typically merely the telephone number of the phone 536 from which the calling party is placing the call. Thus if the network 506 supports the aforementioned CLI provision, then if Ted calls Jim from Ted's phone, Jim will see, on a display on Jim's phone, the number of Ted's phone. If however Ted blocks provision of the CLI from his phone, then Jim will see a message, on the display on Jim's phone, indicating that the CLI of the incoming call has been blocked.

For people whom the user of the called cellphone 532 knows, the user can store in the memory 528 in the called celiphone 532, using relevant keys on the keypad in the user interface 530, names and corresponding CLIs (ie telephone numbers).

In regard to incoming callers whose names and CLI's the user may not have previously stored, the process fragment 400 in Fig. 4A shows how the user can capture and store Calling Line Identifiers (CLIs), storing each CLI together with the corresponding name of the incoming caller.

The process fragment 420 in Fig. 4B shows how the user of the called celiphone 532 can record personalised messages for one or more of the people whose CLIs and names have been recorded, either (a) according to the fragment 400 in Fig. 4A, or (b) as described in relation to people whom the celiphone user knows.

Fig. 4A shows the process fragment 400 that commences with a step 406 in which the controller 904 determines if an incoming call has been picked up. If this is not the case, then the process fragment 400 follows a NO arrow from the step 406 back to the step 406. If on the other hand the step 406 returns a logical TRUE value, then the process fragment 400 follows a YES arrow from the step 406 to a step 410 in which the controller 904 determines if the Calling Line Identifier (CLI) of the incoming caller should be stored. This can be determined, for example, by the user of the called celiphone 532 depressing the appropriate pre-programmed key on the keypad in the user interface 530.

-23 -This presupposes that the CLI of the incoming caller has not been blocked as described below. The user of the called celiphone 532 would typically only direct the step 410 to store the CLI for an incoming caller if the name and CLI have not previously been stored, either using the process fragment 400, or by manually entering the name of a person and their telephone number as described above.

If the step 410 returns a logical TRUE value, then the process fragment 400 follows a YES arrow from the step 410 to a step 414 which stores the CLI of the incoming caller in the RAM 528 indexed by the name of the incoming caller. In one arrangement, the program 534 provides a series of dialog boxes on the display in the user interface 530 (ie 908 in Fig. 9) instructing the user of the called celiphone 532 to record the name of the incoming caller when the user wishes to store the CLI of the incoming caller. The process fragment 400 then follows an arrow 408 from the step 414 back to the step 406. Returning to the step 410, if the step 410 returns a logical FALSE value, then the process fragment 400 follows a NO arrow from the step 410 back to the step 406.

As previously noted, therefore, the process fragment 400 in Fig. 4A results in a list of names and corresponding CLIs being stored in the memory 528 in the called cellphone 532.

The process fragment 420 in Fig. 4B commences with a start step 421 in which the controller 904 determines if another personalised message is to be recorded. This can be determined, for example, by whether the user of the called celiphone 532 has depressed a relevant pre-progranimed key on the keypad in the user interface 530. If the step 421 returns a logical FALSE value, then the fragment 420 follows a NO arrow from the step 421 back to the step 421 in a looping fashion. If on the other hand the step 421 returns a logical TRUE value, then the fragment 420 follows a YES arrow from the step 421 to a step 423. In the step 423, the controller 904 receives a person's name, for -24 -example, by the user of the called celiphone 532 using the keypad in the user interface 530 to type in the persons name in question.

In a following step 425 the controller 904 determines if a caller's CLI has previously been stored in the memory 528 indexed by the person's name entered in the step 423, using the process fragment 400 in Fig. 4A. If this is not the case, then the fragment 420 follows a NO arrow from the step 425 to a step 427 in which the controller 904 displays a message on the display in the user interface 530 (ie 908 in Fig. 9), telling the user that a personalised message cannot be recorded because the person's name & CLI have not been stored in the memory 528. The process fragment 420 then follows an arrow 428 from the step 427 back to the step 421.

If on the other hand the step 425 returns a logical TRUE value, then the fragment 420 follows a YES arrow from the step 425 to a step 430. In the step 430 the controller 904 activates a record control program that enables the user of the called celiphone 532 to record a personalised message for the particular person whose name was entered in the step 423, by dictating the message into the microphone in the user interface 530. The dictated personalised message is then recorded and stored in the RAM 528 indexed by the name of the person in question and their CLI. The process 420 then follows an arrow 431 from the step 430 back to the step 421.

Fig. 5 is a flow chart showing how the process 128 (see Fig. 2) can use the personalised wait-for-me messages recorded in Figs. 4A and 4B in the PMCH arrangement in Fig. 2. As described in regard to Fig. 2, the step 122 in the process 102 waits for a preset number of rings, and then picks up the incoming call via the network interface 510, thus placing the called celiphone 532 in an off-hook state. The process 102 then follows an arrow 132 from the step 122 to the step 128 that plays the wait for me message from the wait-for-me message store 906.

-25 -In the arrangement of Figs. 2 and 3, a single (default) message is played to any incoming caller. However in the arrangement of Figs. 4A, 4B and 5, personalised messages are recorded (in Figs. 4A and 4B) and can be played on a per-incoming caller basis, as will now be described in regard to Fig. 5.

In Fig. 5, the arrow 132 (from the step 122 in Fig. 2) is directed to a step 300 in which the controller 904 determines whether the calling line identifier for the incoming caller can be acquired from the incoming call. This relates to the fact that some callers "block" their calling line identifiers, eg for privacy reasons, thus denying the called party the ability to "see" the calling line identifier of the calling party. In such cases where the CLI of the incoming caller is blocked, the controller 904 in the step 300 will not be able to obtain the CLI of the calling party, in which case the process 128 follows a NO arrow from the step 300 to a step 318. In the step 318 the controller 904 retrieves a default message (such as has been recorded using the process 200 in Fig. 3), and in the following step 322, the controller 904 directs the speaker in the user interface 530 (ie 908) to play the pre-recorded default wait-for-me message to the calling party. The process 128 is then directed from the step 322 via the arrow 142 to the step 140 in Fig. 2.

If on the other hand the CLI of the calling party has not been blocked and is available to the controller 904 in the step 300, then the process 128 follows a YES arrow from the step 300 to a step 304. In the step 304 the controller 904 reads the CLI and determines if a personalised message has been recorded and stored together with the caller's name, either manually or by the process fragment 400, and by the process fragment 420, in Figs. 4A and 4B, indexed by the CLI of the calling party. If this is the case then the process 128 follows a YES arrow from the step 304 to a step 312. In the step 312 the processor 512 (ie the controller 904) retrieves, using the CLI of the calling party as an index, the personalised message from storage 528. In a following step 316, the controller 904 directs the speaker in the user interface 530 to play the personalised pre- -26 -recorded wait-for-me message to the calling party. The process 128 then follows the arrow 142 to the step 140 in Fig. 2.

Returning to the step 304, if the controller 904 reads the CLI and determines that a personalised message has not been recorded and stored, together with the caller's name, against the callers CLI, the process 128 follows a NO arrow from the step 304 to the step 318.

Fig. 6 shows a process flow chart fragment 600 for a prior art telephone answering machine, into which the arrangements associated with the personalised wait-for-me messages described in relation to Figs. 4A, 4B and 5 can be incorporated, to form a personalised message answering machine. In operation, in a step 602 the processor in the answering machine picks up the call after a pre-determined number of rings, placing the telephone associated with the answering machine in an off-hook state.

The process 600 then follows an arrow 603 from the step 602 to a step 604 in which the processor in the answering machine directs the answering machine to play a pre-recorded message to the calling party. The pre-recorded message is not a wait-for-me message, and instead typically advises the calling party that the called party is unavailable, and invites the calling party to leave a message for the called party. After the pre-recorded message has been played in the step 604, the process 600 follows an arrow 605 to a step 606 that activates a recording device in the answering machine for a pre-determined time that is long enough for the typical calling party to leave a useful message for the called party. In a following step 608, the processor in the answering machine hangs up the call, placing the telephone associated with the answering machine in an on-hook state.

The arrangements implementing the process fragments of Figs, 4A and 4B can be incorporated into the aforementioned answering machine, thereby enabling personalised messages to be recorded by the user of the answering machine. The process -27 -fragment of Fig. 5 can be incorporated into the step 604 of Fig. 6, thereby playing personalised messages to incoming callers who do not block their CLI, and for whom personalised messages have been previously recorded.

Fig. 7 is a schematic diagram of an example system 700 in which network-S centric PMCH arrangements can be practiced. The network-centric system 700 is essentially the same as the celiphone-centric system 500 in Fig. 1 except that a signalling and control module 745 and a message server 743 are provided outside the called celiphone 732 (in contrast, in Fig. 9 which is associated with Fig. 1 the signallcontrol module 921 and the message module 922 are provided within the called cellphone 532).

The provision of the functional modules 745 and 743 outside the called cellphone 732 (ie typically within or associated with the network 706) enables the called cellphone 732 to practice the network-centric PMCH arrangement without specialised capabilities being provided in the called celiphone 732. In other words, the system 700 supports the PMCII capability by virtue of capabilities included in or associated with the network 706, and thus this arrangement is referred to as a networkcentric PMCH arrangement. Although Fig. 7 depicts a particular functional module arrangement and distribution of functionality, other functional arrangements can be used provided that they can support the same general functionality described in relation to Fig. 7.

Fig. 10 is a functional block diagram representation of a network-centric PMCH system 1000 that can be implemented using the system of Fig. 7. The network-centric system 1000 is essentially the same as the celiphone-centric system 900 in Fig. 9 except that the signalling and control module 745 and the message server 743 are provided outside the called cellphone 732.

Fig. 8 is a signal flow diagram of operational scenarios for the network-centric PMCH system of Fig. 10. The other scenario described with reference to Figs. 2-5 and 8 can also be practiced in a network-centric PMCH system. In one operational example (ie -28 -the "wait-for-me" mode between heavy solid lines 801 and 807), prior to going into a meeting, the user of the called cellphone 732 uses the called device user interface 1008 (in Fig. 10) to communicate, as depicted by the dotted arrow 802, from the called celiphone 732 to the control module 745 in order to establish the "wait-for-me" mode (via 1020 in Fig. 10). This is the operational mode during which the user can participate in the meeting without needing to react immediately when an incoming call arrives at his called celiphone 732 from the calling cellphone 736 (see 1009 in Fig. 10).

As depicted by the solid line 803 the incoming call from the calling phone 736 (see 1009 in Fig. 10) is connected to the control module 745 (and in particular to the switch 1005), which establishes a connection, as depicted by a solid line 804, to the message server 743 (and in particular the wait-for-me message store 1006) as depicted by the concatenation of 1009 and 1015 in Fig. 10. The wait-for-me message store 1006 then plays, as depicted by a dash-dot line 805, a wait-for-me message telling the user of the calling cellphone 736 to wait on the line. The wait-for-me message module 1006 in this example is controlled, as depicted by the dashed line 1018, by the controller 1004 (see Fig. 10).

The control module 745 (and in particular the controller 1004) communicates, as depicted by a dotted line 806 with the called cellphone 732 (see 1020 in Fig. 10) to alert the user of the called cellphone 732 that an incoming call has been parked and is waiting.

This alert signal 806 can take the form of a single chime, or a flash on the display (using components of the user interface 730). Knowing that the incoming call has been parked, the user of the called cellphone 732 need not react immediately to the incoming call, and can instead keep her attention on the person to whom she is talking. Then after a polite interval, she can excuse herself, move away and attend to the call as described below.

Moving to the "take the call" mode of Fig. 8 (between the heavy lines 807 and 813) the user of the called celiphone 732, after a reasonable polite interval, signals as -29 -depicted by a dotted line 808 (see 1020 in Fig. 10) from the called celiphone 732 to the control module 745 (and in particular the switch 1005) the user's readiness to take the incoming call. The controller 1004 then establishes a connection for the incoming call between the calling phone 736 voice interface 1001 and the called device voice interface 1002 as depicted by a solid line 909 (formed by concatenating 1009 and 1013 in Fig. 10).

The respective users of the calling phone 736 and the called phone 732 speak to each other in a normal manner, as depicted by a dashed arrow 810. When they complete their conversation, the connection is terminated as depicted by "X" symbols 811 and 812.

In the event that the user of the called celiphone 732 decides, some time after receiving the alert signal 806, that it would not be polite totake the incoming call after all, the user can establish the "reject-the-call" mode (between heavy lines 813 and 818), using the user interface 1008 to generate a signal depicted by a dotted arrow 814, from the user interface 1008 to the control module 745. The control module 745 then directs the message server 743 to advise the calling party, as depicted by a dash-dot line 816, that the called party is unable after all to take the call. In one arrangement, this communication 816 asks the calling party if they wish to leave a message for the called party, and if this option is taken up, the calling party can leave a message on the leave-a-message store (via a concatenation of 1009 and 1014 in Fig. 10). The control module 745 then terminates the call as indicated by an "X" symbol 817.

In the event that the user of the called cellphone 732 is unable, some time after receiving the alert signal 806, to either take the call (by establishing the take-the-call mode) or to actively reject the call (by establishing the reject-the-call mode), then the control module 745 establishes a timeout mode (between heavy lines 818 and 822). In this mode the control module 745 directs the message server 743 to advise the calling party, as depicted by a dash-dot line 820, that the called party is unable after all to take the call.

In one arrangement, this communication 820 asks the calling party if they wish to leave a message for the called party, and if this option is taken up, the calling party can leave a message on tHe leave-a-message store (via a concatenation of 1009 and 1014 in Fig. 10).

The control module 745 then terminates the call as indicated by an "X" symbol 821.

Industrial Applicability

It is apparent from the above that the arrangements described are applicable to the telecommunications industry.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. Thus, for example, while the description is directed to celiphones as a particular example of a mobile communications device, the inventive concept can equally be used with Personal Digital Assistants (PDAs) and similar devices.

In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of'. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

Claims

The claims defining the invention are as follows: I. An answering

system configured to interact with a calling phone and a called celiphone, the system comprising: a user interface module in the called celiphone, said user interface module being configured to establish one of a wait-for-me mode and a take-the-call mode, wherein: in the wait-for-me mode a control module (a) advises the called celiphone that an incoming call from the calling phone is being parked, and (b) connects the incoming call to a message module; and to in the take-the-call mode the control module connects the incoming call from the calling phone to a voice interface of the called celiphone; the control module; and the message module being configured, in the wait-for-me mode, to play a wait-for-me message to the calling phone.
2. An answering system according to claim 1, wherein the user interface module in the called cellphone is further configured to establish a reject-the-call mode and the control module is configured in the reject-the-call mode to advise the calling phone of the rejection, and to terminate the call.
3. An answering system according to claim 1, wherein the user interface module in the called cellphone is further configured to establish a timeout mode, and the control module is configured in the timeout mode to advise the calling phone of the timeout, and to terminate the call.
4. An answering system according to claim 1, wherein the control module is configured to enter a timeout mode after a time period and to advise the calling phone of the timeout, and to terminate the call.
5. An answering system according to any one of claims 1-4, wherein the message module is further configured, in at least one of the wait-for-me mode, the reject-the-call mode, and the timeout mode, to record a message from the calling phone.
6. An answering system according to claim 1, wherein the control module, and the message module are incorporated in the called celiphone.
7. An answering system according to claim 1, wherein the control module, and the message module are external to the called celiphone.
8. An answering system according to claim 1, wherein the user interface module in the called celiphone establishes the wait-for-me mode before the incoming call is received.
9. An answering system according to claim 1, further comprising a download server from which the wait-for-message is downloaded to the message module.
10. An answering system according to claim 1, wherein the message module is configured: to store a plurality of wait-for-me messages each indexed by a corresponding calling line identifier; and to play, in the wait-for-me mode, one of the recorded plurality of wait-for-me messages dependent upon a calling line identifier of the incoming call.
11. An answering system according to claim I, wherein the message module repeats the wait-for-me message until the means for detecting detects that the called party has commenced speaking.
12. A method of handling an incoming call from a calling phone to a called cellphone, said method comprising the steps of: establishing by the called celiphone a wait-for-me mode, and in said wait-for-me mode; advising the called called celiphone that an incoming call from the calling phone is being parked; connecting the incoming call to a message module; and playing by the message module a wait-for-me message to the calling phone; establishing by the called cellphone a take-the-call mode and in said take-the-call mode: connecting the incoming call from the calling phone to the called celiphone.
13. A system for handling an incoming call from a calling phone to a called celiphone, said system comprising: at least one memory for storing a program; and at least one processor for executing the program, said program comprising: code for establishing by the called celiphone a wait-for-me mode; -34 -code for advising in said wait-for-me mode the called called celiphone that an incoming call from the calling phone is being parked; code for connecting in said wait-for-me mode the incoming call to a message module; and code for playing in said wait-for-me mode by the message module a wait-for-me message to the calling phone; code for establishing by the called cellphone a take-the-call mode and in said take-the-call mode: and code for connecting in said take-the-call mode the incoming call from the calling phone to the called celiphone.
14. A computer program product including a computer readable medium having recorded thereon a computer program for directing at least one processor to execute a method for handling an incoming call from a calling phone to a called celiphone, said program comprising: code for establishing by the called cellphone a wait-for-me mode; code for advising in said wait-for-me mode the called called cellphone that an incoming call from the calling phone is being parked; code for connecting in said wait-for-me mode the incoming call to a message module; and code for playing in said wait-for-me mode by the message module a wait-for-me message to the calling phone; code for establishing by the called celiphone a take-the-call mode and in said take-the-call mode: and code for connecting in said take-the-call mode the incoming call from the calling phone to the called celiphone.
15. An answering system, substantially as described herein with reference to any one of the embodiments, as that embodiment is shown in the accompanying drawings.
16. A method of handling an incoming call from a calling phone to a called celiphone, substantially as described herein with reference to any one of the embodiments, as that embodiment is shown in the accompanying drawings.
17. A computer program product, substantially as described herein with reference to any one of the embodiments, as that embodiment is shown in the accompanying drawings.