Interactive call identification

<u>Technical Field</u>

This invention relates generally to telecommunications systems, and more particularly, to a method and apparatus for implementing interactive call identification to facilitate caller identification.

<u>Related Background Art</u>

Prior to picking up the handset on a ringing telephone, thereby accepting an incoming call, it is increasingly desirable for a call recipient to have access to certain information about that incoming call prior to accepting the call. Having access to this information will aid the call recipient in screening the incoming call to decide whether or not to accept it.

Various call identification methods are currently available which provide selected information to the call recipient regarding the incoming call to aid him or her in identifying that incoming call.

These known call identification methods include features to display call information to the call recipient by sending and displaying a data message to the called station. These methods however, are inherently limited in the scope of information they are capable of conveying to the screening call recipient.

The call information (i.e., the data message) provided in these known call identification methods consists of, or at best is derived from, the phone number of the station from which the caller is placing the call, providing little more information than the calling station number to the called party. The nature or purpose (i.e., subject matter) of the call or any other information, is left to be discovered by the called party only after accepting the call.

These known methods typically identify the number of the station from which the calling party is placing the call from a unique code associated with that station from which the call is placed. Where the subscribing call recipient has installed the necessary hardware (i.e., digital display of some type or an ISDN station), the station number from where the calling party is placing the call will be displayed. Where the call recipient has a conventional analog station, these identification services are unavailable without additional equipment. Further, the calling number will be available to the called party only where the calling party has not blocked the information.

Since a called party will typically only have a few of the more frequently used numbers committed to memory, a method of merely displaying the calling station number is of limited utility.

Related methods will also display the caller's name, derived from the calling station number, or other limited data messages. While these methods are potentially more helpful to the call recipient in deciding whether to take a call, they still suffers from the inherent limitation that any information provided to the called party is by necessity tied to the phone station from which the call is placed.

A call-announcement method is also available for call identification.

In the call announcement scheme, a text-to-speech converter generates speech signals from text retrieved from a database, for transmission to the called station. The database contains information associated with the calling party's number, specifically, the calling party's name. After answering the call, a subscribing call recipient will receive synthesized, spoken information consisting of the calling party's name and/or number. This service is made available to customers having conventional analog or ISDN equipment.

A related development in call identification is that the call recipient who subscribes to the call announcement service can also make a personalized list, resident in the subscribing party's station equipment or central office, where the phone number of frequent callers is correlated to an identifying message, either recorded voice or text, entered by the subscriber. However, the calling party must have an entry in the called party's database corresponding to the number from which the calling party is calling in order for their call to be meaningfully announced to the called party. Where there is no corresponding entry on the list, an incoming call may remain unidentified or may be mis-identified.

Also, as is common to the previously mentioned call identification methods, where a known and welcome caller is calling from someone else's phone or is identified as an 'unlisted caller' because he is calling from an unknown (such as a payphone) or blocked number, a call from an otherwise welcome caller may go unanswered due to the lack of or improper identification.

As has been illustrated, an inherent limitation in these known methods is that identification of a calling party is constricted to the station from which the call is being placed, providing little, if any, information beyond the calling station number. This is of limited value if someone with whom the recipient wishes to speak is calling from an unfamiliar telephone. With the known call identification methods, the call recipient would in this case see an unfamiliar telephone number as identifying the incoming call and have no further information upon which to decide whether or not the call should be accepted. Even the slightly more sophisticated call-announcement method gives little more pre-answer information to the call recipient as it is still tied to the station number from which the incoming call is placed and any possible messages to be retrieved can, practically speaking, only be generic in nature (i.e., "This is Bob.")

In any event, the nature or subject of the call will remain unknown to the recipient until he or she actually takes the incoming call.

Thus, to illustrate, with the known methods, calling party 'A' cannot be properly identified to the called party as 'A' unless 'A' is placing the call from a phone or station having a directory number associated with 'A'. If 'A' places the call from a station assigned to party 'B', party 'A' will be mis-identified to the call recipient as party 'B'.

Other known messaging methods which allow a caller to send a voice message to a called party are restricted by other limitations. Although providing capabilities of custom message recording, a separate call is required during which the message is created. The message is then delivered at a scheduled delivery time to a recipient party.

As is evident from the foregoing, limitations in known methods limit the effectiveness, and therefore the utility, of the current level of advancement achieved in the area of call identification.

<u>Summary Of The Invention</u>

Limitations of known call identification and announcement methods are resolved and technical advances are achieved in the present invention by a method and system for interactively identifying a telephone call on a communication network as part of call establishment procedure.

A telephone call is terminated in a first telephone connection from a calling location. A message is received from the calling location. This message is then stored. The message is then relayed over a second telephone connection to the called location. The telephone call is then processed based on an input from the called location.

Alternatively, the first connection can be placed on hold prior to relaying the message, while the second connection is established. The method and system can include prompting the calling party to enter a message.

The message transfer can be initiated by either the calling or called party, via subscription or via activation by the calling party entering special activation codes when placing the call.

The processing of the telephone call can include bridging the telephone connection immediately, forwarding the call to a forwarding location, accommodation for call waiting, and rejecting the call where a message can be sent back to the calling party and the call can then be released.

The method and system of the present invention can be implemented on an Integrated Services Digital Network; a broad band signalling Integrated Services Digital Network; a packet network or a POTS network utilizing DTMF signals.

The messaging transfer can be implemented on a network server, an originating switch, an intermediate switch, or a terminating switch.

The method and system are capable of supporting both voice and text messages which can be entered on a call-by-call, or real-time basis. The text messages may be entered via a keyboard or personal computer. The text message may also be pre-stored and/or selectable and/or expandable. The text message may also be converted into audio.

<u>Brief Description Of Drawings</u>

The following drawings are referenced in the detailed description which follows and are provided to facilitate a better understanding of the invention disclosed herein.

Figure 1 illustrates a typical communication path for an end-to-end call from a calling party to a called party.

Figure 2 illustrates typical ISDN signalling flow for the completed end-to-end call of Figure 1.

Figure 3 illustrates a communication path of the present invention as routed through a special server and intermediate central office switches.

Figure 4 illustrates the ISDN processing flow for an implementation of the present invention according to one embodiment of the present invention initiated by the called party for voice messaging.

Figure 5 illustrates the message flow for the processing flow of Figure 4.

Figure 6 illustrates the ISDN processing flow for an implementation of the present invention according to one embodiment initiated by the called party for text messaging.

Figure 7 illustrates the message flow for the processing flow of Figure 6.

Figure 8 illustrates the ISDN processing flow for an implementation of the present invention according to one embodiment initiated by the calling party.

Figure 9 illustrates the message flow for the processing flow of Figure 8.

Figure 10 illustrates the processing flow for the server function element processing a voice message according to the present invention.

Figure 11 illustrates the processing flow for the server function element processing a text message according to the present invention.

<u>Detailed Description Of The Preferred Embodiments</u>

Referring to Figure 1, when a calling party <b>100</b> places a call to a called party <b>200</b>, current technology establishes a connection between these two end-users. This is achieved by the signalling system. The signalling system attempts to confirm a clear line via a specific route from the calling party <b>100</b> to originating switch <b>110</b> through the central office <b>300</b>, to the appropriate terminating switch <b>210</b>, finally to the called party <b>200</b>. The route is established by the signalling system via connections through the various required paths until the line is complete from end-to-end.

With reference to Figure 2, the standard procedure of determining a clear line connection involves what can be summarized as a three stage process. First, the calling party station <b>100</b> must establish a connection to its originating switch <b>110</b>; second, the originating switch <b>110</b> must then establish connection to the destination or terminating switch <b>210,</b> via any intermediate devices (for illustrative purposes, the described embodiments of the present invention assume that the calling and called parties are served by different switches, however, the principles of the present invention are equally applicable where both the calling and called parties are served by the same switch, i.e., originating and terminating switches are the same); and, finally, the terminating switch <b>210</b> must establish a connection to the called party station <b>200</b>. When all stages of the connection process are completed a clear line is established between calling <b>100</b> and called <b>200</b> party stations.

Once the clear line is thus established, the called party <b>200,</b> by picking up the handset of his ringing telephone, accepts the call and the originating switch <b>110</b> completes the connection between the calling and called stations, and end-to-end communication (between calling and called stations) may then begin.

Figure 3 illustrates a communication path for an end-to-end call from a calling party <b>100</b> to a called party <b>200</b> according to one exemplary embodiment of the present invention.

In the present invention, information converning the identity of the caller, subject matter of the call or any other user-user information (UUI"), is sent by the caller <b>100</b> and is received by the called party <b>200</b> in advance of the called party <b>200</b> answering the call as part of the call set-up. The UUI information of the present invention is provided in the form of a voice or text message which is created interactively on a call-by-call basis by the calling party upon initiating the call. The message can be entered by the calling party on a real-time basis or generated from messages pre-stored on a database.

Refering to Figure 3, an end-to-end communication path is established between a calling party <b>100</b> and a called party <b>200</b>. The signalling system attempts to confirm a clear line via a specific route from the calling party <b>100</b> to originating switch <b>110</b> through the central office <b>300</b>, which in this embodiment may include central office intermediate switches <b>115</b> and special network server <b>120</b>, to the appropriate terminating switch <b>210</b>, finally to the called party <b>200</b>. The route is established by the signalling system via connection through the various required paths until the line is complete from end-to-end.

Either the calling or called party can initiate message transfer according to the present invention.

One embodiment of the present invention is implemented where the called party <b>200</b> subscribes to the message transfer service of the present invention and is thus the initiator of the message transfer service. When a call is placed to the called party <b>200,</b> the call is routed to a special server <b>120</b> which terminates the call. Therefore, the called party number dialed by the calling party is an "alias" which instructs the network to route the call to the special server <b>120.</b> The special server <b>120</b> then prompts the calling party <b>100</b> for their message. Once their message has been accepted, the special server <b>120</b> places the call on hold, and initiates a second call to the called party <b>200</b>, over which it delivers the voice or text message as will be explained. If the called party <b>200</b> accepts the call, the special server <b>120</b> bridges the two calls, the connection is completed and communication can begin. Alternatively, the called party <b>200</b> may forward the call, where the special server <b>120</b> completes the call to the forwarding point, and then bridges the connections. Finally, in the system default, the called party <b>200</b> does not answer the call, and the special server <b>120</b> generates a ring-back to the calling party <b>100</b> which will experience a "ring-no-answer" condition and eventually hang up.

Figure 4 illustrates the Integrated Services Digital Network ("ISDN") processing flow for a special server based implementation in one exemplary embodiment of the present invention. In this embodiment, message transfer is initiated by a subscribing called party. Illustrated in Figure 4 is a voice message sent from a calling party <b>100</b> to a subscribing called party <b>200</b>, where the call is accepted by the called party <b>200</b>. Figure 5 presents detailed message flow for the processing flow illustrated in Figure 4, depicting this embodiment of the present invention in a condition where the called party accepts the incoming call.

Referring to Figure 4, in step <b>400,</b> a SETUP message is generated from the calling party to originating switch when the calling party dials the called party's number. This SETUP message contains the alias for the called party number ("called #'") which instructs the originating switch, in step <b>405</b>, to route the call to a special server <b>120</b> using standard ISDN procedures. The special server, in step <b>410</b>, prompts the calling party to enter a message over the established connection. In step <b>415,</b> the calling party enters the desired message, in this example a voice message, by speaking into the telephone handset. This voice message is stored in the special server in step <b>420</b> and the call between the calling party and the special server is placed on hold in step <b>425</b>. The special server <b>120</b> then initiates a call to the called party using standard ISDN procedures in step <b>430</b> to establish a voice path to the called party. After the voice path is established to the called party in step <b>435</b> (for example, either a speakerphone is activated or the receiver is picked up on a conventional telephone), the special server plays the voice message over the newly established voice path in step <b>440</b>. The called party, then decides in step <b>445</b> whether to accept the call based on the content of the message, enters a code to either accept the call, forward the call, or reject (i.e., ignore) the call. If the called party accepts the call in step <b>450,</b> the special server will bridge the two calls to create an end-to-end connection in step <b>455</b> and the call can proceed normally in step <b>480.</b> If the called party forwards the call in step <b>460,</b> the special server will forward the call to the forwarding number according to standard procedures and the call can proceed normally in step <b>480.</b> If the called party rejects or ignores the call in step <b>470</b>, a "ring-no answer" is encountered by the calling party and the call proceeds normally in step <b>480</b> where a "ring-no answer" is experienced by the calling party <b>100</b> until the calling party hangs up.

Referring now to Figure 5, a SETUP message is generated over signaling links from the calling party <b>100</b> to originating switch <b>110</b> when the calling party dials the called party's number. (See <b>400,</b> Fig. 4.) This SETUP message contains an alias for the called party number ("called #'") which instructs the originating switch <b>110</b> to route the call to a special server <b>120</b>, via any central office intermediate switches <b>115</b>. (See <b>405,</b> Fig. 4.) Using standard ISDN procedures, the call is completed to the special server <b>120</b>. The special server <b>120</b> prompts the calling party <b>100</b> to enter a message, voice or text, over the established connection. (See <b>410</b>, Fig. 4.) In this example, the calling party <b>100</b> enters a voice message by speaking the message into the telephone handset. (See <b>415</b>, Fig. 4.) This voice message is stored in the special server <b>120</b> (See <b>420,</b> Fig. 4.) and the call between the calling party <b>100</b> and the special server <b>120</b> is placed on hold. (See <b>425</b>, Fig. 4.) The special server <b>120</b> then initiates a call via any central office intermediate switches <b>115</b> and terminating switch <b>210</b> to the called party <b>200</b> using standard ISDN procedures. (See <b>430</b>, Fig. 4.) After the called party <b>200</b> answers the call (See <b>435,</b> Fig. 4.), as is indicated by the CONNECT message sent over signalling links from the called party <b>200</b> to its terminating switch <b>210</b> through to special server <b>120</b>, the special server <b>120</b> plays the voice message over the newly established connection. (See <b>440</b> Fig. 4.) The special server <b>120</b> also prompts <b>230</b> the called party <b>200</b> to enter a code to either accept the call, forward the call, or reject (i.e., ignore) the call. In the example implementation illustrated in Figure 5, the called party <b>200</b> signals to accept the call. At this time, the special server <b>120</b> bridges the connections between the calling party <b>100</b> and called party <b>200</b> and the call is established end-to-end (<b>100</b> to <b>200</b>). (See steps <b>445, 450, 455</b> Fig. 4.) The call now proceeds normally. (See <b>480</b> Fig. 4.)

Figure 6 illustrates the ISDN processing flow for a special server based implementation in another exemplary embodiment of the present invention. In this embodiment, message transfer is initiated by a subscribing called party. Illustrated in Figure 6 is a text message is sent from the calling party <b>100</b> to the subscribing called party <b>200</b>, where the call is accepted by the called party <b>200.</b> Figure 7 presents detailed message flow for the processing flow illustrated in Figure 6, depicting this embodiment of the present invention in a condition where the called party <b>200</b> accepts the incoming call.

Referring to Figure 6, in step <b>500</b>, a SETUP message is generated over signaling links from the calling party <b>100</b> to the originating switch <b>110</b> as in the implementation example of Figures 4 and 5. Again, using standard ISDN procedures, the call is completed to a special server <b>120</b> in step <b>505.</b> The special server <b>120</b> prompts the calling party <b>100</b> to enter a text message over the established connection in step <b>510.</b> (Again, the calling party can select either a voice or text message, but for this exemplary embodiment, a text message was chosen for illustrative purposes.) In step <b>515,</b> the calling party either enters the text message using a keyboard (via, for example, a personal computer with a modem), or enters a code for a message that is pre-stored in its phone. Where a code for a pre-stored message is chosen, the telephone expands the message code into a full textual message using known methods. The text message is then stored in the special server <b>120</b> in step <b>520</b> and the call between the calling party and the special server <b>120</b> is placed on hold in step <b>525.</b> The special server <b>120</b> then initiates a call to the called party in step <b>530</b>, using standard ISDN procedures, and sends the text message for display to called party <b>200</b>.

In step <b>531,</b> an option is selected to either "wait" or "bridge" the call.

If the "bridge" option is chosen, the call is bridged immediately in step <b>535</b>. When the called party accepts the call, as in this example, process flow continues in step <b>535</b> where the special server will bridge the two calls to create an end-to-end connection in step and the call can proceed normally in step <b>550</b>.

If the "wait" option is chosen, the call will not be bridged, forwarded or released until a user response from the called party has been received. In step <b>532,</b> the called party sends instructions and the flow continues to step <b>540</b>.

In step <b>540</b>, the server function element resolves, based on input from the called party, to either accept the call (step <b>542</b>), or not (step <b>541</b>). Where the called party has accepted the call (<b>542</b>), the server function element will bridge the call (either connect or forward) in step <b>544.</b> Where the called party has not accepted the call (<b>541</b>), the server function element will either, at the choice of the called party, do nothing and "Ring Back" (i.e., allow a "ring no answer" condition to persist) in step <b>545</b>, or it can be configured to play an announcement to the called party that the call was not accepted by the called party <b>200</b> (step <b>543</b>) and finally release the call in step <b>547</b>.

Referring now to Figure 7, a SETUP message is generated over signaling links from the calling party <b>100</b> to originating switch <b>110</b> when the calling party dials the called party's number. (See <b>500</b>, Fig. 6.) This SETUP message contains an alias for the called party number ("called #'") which instructs the originating switch <b>110</b> to route the call to a special server <b>120,</b> via any central office intermediate switches <b>115.</b> (See <b>505</b>, Fig. 6.) Using standard ISDN procedures, the call is completed to the special server <b>120</b>. The special server <b>120</b> prompts the calling party <b>100</b> to enter a message over the established connection. (See <b>510,</b> Fig. 6.) The calling party <b>100</b> enters and sends the text message. (See <b>515,</b> Fig. 6.) (Again, the calling party can select either a voice or text message, but for this exemplary embodiment, a text message was chosen for illustrative purposes.) This text message is stored in the special server <b>120</b> (See <b>520</b>, Fig. 6) and the call between the calling party <b>100</b> and the special server <b>120</b> is placed on hold. (See <b>525,</b> Fig. 6.) The special server <b>120</b> then initiates a call to the called party <b>200</b> using standard ISDN procedures, sending the text message as well. The message is sent to the called party <b>200</b> by the terminating switch <b>210</b> in the DISPLAY information element of the SETUP message. (See <b>530,</b> Fig. 6.) The special server <b>120</b> bridges the connections between the calling party <b>100</b> and called party <b>200</b>, and the text message will then be displayed at the called party cite. (See step <b>535</b> Fig. 6.) After the called party <b>200</b> answers the call, and the call is established end-to-end (<b>100</b> to <b>200</b>). The call now proceeds normally. (See <b>550</b> Fig. 6.)

Although in the embodiment depicted in Figure 7, the call is bridged immediately (i.e., with reference to Figure 6, flow continues, from step <b>530</b>, through step <b>531</b>, to step <b>535</b>), an option can be selected to "wait". (Step <b>531</b>, Fig. 6). If the "wait" option is chosen, the call will not be bridged, forwarded or released until a user response from the called party has been received (step <b>532</b>, Fig. 6). A signal flow, corresponding to the process flow for steps <b>531</b> to <b>540</b> (Fig. 6), along the "WAIT" path, would then be implemented.

In another exemplary embodiment of the present invention, the calling party is the subscribing party and thus can initiate the message transfer on demand. Figure 8 illustrates the ISDN processing flow for the case in which the calling party explicitly designates the call as belonging to a special service by dialing digits to request the message service (i.e., the calling party initiates the message transfer.) Figure 9 presents the detailed message flow for the processing flow illustrated in Figure 8, depicting this embodiment of the present invention. In the embodiment of Figures 8 and 9, the message is assumed to be textual for illustrative purposes, however, as for the other example embodiments, voice messages may equally be used.

Referring to Figure 8, the calling party invokes the message transfer in step <b>600</b> by entering a special code or series of digits which are contained in the SETUP message sent over signaling links. In step <b>605</b>, the originating switch <b>110</b> acknowledges the request and prompts the calling party for more information. The calling party <b>100</b> in step <b>610</b> enters the called party number and the textual message that to be sent. The originating switch <b>110</b> will the route the call to the terminating switch <b>210</b> of the called party <b>200,</b> along with the text message, in step <b>615</b>, using standard ISDN procedures. In this embodiment, the functions performed by the special server <b>120</b> in the embodiments of Figures 4 through 7 are performed by the originating switch <b>110</b>. The terminating switch <b>210</b> then delivers the text message to the called party <b>200</b> for display in step <b>620</b>. At this point, the call proceeds normally in step <b>630</b>.

Referring now to Figure 9, the SETUP message generated by the calling party <b>100</b> as in the previous embodiments specifies that the messaging service is being invoked via the calling party's entering a special code or series of digits. (See step <b>600</b> Fig. 8.) The originating switch <b>110</b> responds with a SETUP ACKNOWLEDGEMENT requesting more information. (See step <b>605</b> Fig. 8.) The calling party <b>100</b> then enters the called party number and the textual message that they wish to send. (See step <b>610</b> Fig. 8.) This information is packaged and delivered to the originating switch <b>110</b> in one or more INFORMATION ("INFO") messages. When all of the information has been received by the originating switch <b>110</b>, the originating switch <b>110</b> generates a CALL PROCEEDING message to the calling party <b>100,</b> and completes the call using standard ISDN procedures to the terminating switch <b>210</b>. (See step <b>615</b> Fig. 8.) The Initial Address Message ("IAM") contains the text message being delivered in the UUI element. The message is sent to the called party <b>200</b> by the terminating switch <b>210</b> in the DISPLAY information element of the SETUP message. (See step <b>620</b> Fig. 8.) At this point, the call proceeds normally. (See step <b>630</b> Fig. 8.)

A server function element is required in the present invention. The server function element of the present invention must be able to perform the following functions: (1) terminate multiple telephone connections; (2) place a connection on hold (When a text message is sent in a embodiment which does not utilize a special network server, there is no need to place the call on hold prior to sending the message.); (3) bridge connections; (4) receive and store voice messages; (5) play stored messages over telephone connections; and, (6) retrieve a called party address from a dialed alias. In the example embodiments of Figures 4-7, the server function element was the special server <b>120.</b> In the example embodiment of Figures 8-9, the server function element was the originating switch <b>110.</b> An example of the server function element, as utilized in the several illustrative embodiments of Figures 4 through 7 discussed, is AT&amp;T's Conversant™ System. Examples of the originating switch of the embodiments of Figures 8 and 9 which are capable of performing these functions are AT&amp;T's 4ESS™ or SESS™ switches. In other embodiments, the terminating switch <b>210</b> or any other similar device in the communication network (i.e., a device having the necessary "intelligence" to perform the above enumerated functions) can be utilized as the server function element.

The processing flow for the server function element of the present invention is shown in Figures 10 and 11 and is described in detail below.

Figure 10 presents the server process flow for a voice message. In step <b>500,</b> the server function element receives an incoming call destined for the called party <b>200</b>. In step <b>502</b>, the server function element accepts the call and prompts the calling party <b>100</b> for a message. In step <b>504</b>, the server function element then accepts the calling party voice message and records or stores it. The calling party is then placed on hold in step <b>505</b> and waits for instructions from the calling party. The server function element, in step <b>506</b>, resolves the called party alias with the actual address of the called party <b>200</b>, and in step <b>508</b> the server function element places the call to the resolved address of the called party. The flow continues along the "VOICE" path to step <b>510</b> where, after receiving an indication that the called party <b>200</b> has answered the call (i.e., the connection has been established), the server function element in step <b>512</b> plays the stored message for the called party over the newly established connection.

In step <b>514</b>, the server function element resolves, based on input from the called party, to either accept the call (step <b>516</b>), or reject the call (step <b>520</b>). Where the called party has accepted the call (<b>516</b>), the server function element will bridge the call (either connect or forward) in step <b>518</b>. Where the called party has not accepted the call (<b>520</b>), the server function element will either, at the choice of the called party, do nothing and "Ring Back" (i.e., allow a "ring no answer condition to persist) in step <b>522,</b> or can be configured to play an announcement to the called party that the call was not accepted by the called party <b>200</b> (step <b>524</b>) and finally release the call in step <b>530.</b>

Figure 11 presents the server process flow for a text message. In step <b>700</b>, the server function element receives an incoming call destined for the called party <b>200</b>. In step <b>702,</b> the server function element accepts the call and prompts the calling party <b>100</b> for a message. In step <b>704</b>, the server function element then receives the text message from the calling party voice message and records or stores it. The calling party is then placed on hold in step <b>705</b> and waits for instructions from the calling party. The server function element, in step <b>706</b>, resolves the called party alias with the actual address of the called party <b>200</b>, and in step <b>708</b> the server function element then initiates a call to the resolved address of the called party, using standard ISDN procedures, and sends the text message for display to called party <b>200</b> as part of the call SETUP message.

In step <b>710</b>, an option is selected to either "wait" or "bridge" the call.

If the "bridge" option is chosen, the call is bridged immediately in step <b>735</b>. The call then proceeds normally (step <b>740</b>).

If the "wait" option is chosen, the server function element resolves in step <b>714,</b> based on input from the called party, to either accept the call (step <b>716</b>), or reject the call (step <b>720</b>). Where the called party has accepted the call (<b>716</b>), the server function element will bridge the call (either connect or forward) in step <b>718</b>. Where the called party has not accepted the call (<b>720</b>), the server function element will either, at the choice of the called party, do nothing and "Ring Back" (i.e., allow a "ring no answer" condition to persist) in step <b>722,</b> or it can be configured to play an announcement to the called party that the call was not accepted by the called party <b>200</b> (step <b>724</b>) and finally release the call in step <b>730</b>.

In another embodiment of the present invention, as in the called party initiated messaging service, in calling party initiated service the call could be routed to a server function element upon receiving the called party number. The server function element would then prompt the calling party for the message. The message flows for text and voice messages would be similar to those of the called party initiated messaging service. For the illustrative embodiments where the voice message is stored in a server function element as acquired over the voice path established between the server function element and the calling party, signalling messages may be used instead to carry the voice message. Here, the voice message would be digitized at the ISDN phone, INFORMATION messages would carry the voice message into the network, and USR messages would be used to carry the voice message within the network. The called party phone would decode the digitized voice and play the message for the called party.

In alternative embodiments, a packet network may be used to carry the voice conversation, such as an ATM-based B-ISDN, or and Internet-like network, then voice and text messages would be carried between the calling party and network within these packets using procedures similar to those described above.

Although both the calling or called party initiated service in the illustrative embodiments described herein are implemented assuming ISDN equipment, the features of the present invention can also be realized using POTS ("Plain Old Telephone Service"). For POTS implementation, the signalling between the calling and called parties and the networks would be done using DTMF signals.

This messaging service can be combined with other existing services. For example, this service can be combined with call waiting where when a call arrives at a terminating switch for a party that is already active in a call, a textual message is displayed when the tone is generated to the called party indicating that a second call has arrived. If the message is a voice message, the called party will signal by a flash-hook to receive the voice message. This service will allow a subscriber to decide to either interrupt their current call to handle the second call, forward the second call to voice mail, or not answer the second call.

The present invention has been illustrated and described with respect to specific exemplary embodiments thereof. It will be readily understood, however, that the above-described embodiments are merely illustrative of the principles of the invention and are not intended to be exclusive or otherwise limiting embodiments. It should further be understood that the foregoing and many various modifications, omissions and additions may be devised by one skilled in the art without departing from the scope of the invention.