CA2268765A1 - Personalized messaging system - Google Patents

Abstract

The present invention provides telephone subscribers with a reverse voice mail system that plays personalized messages left by a subscriber to incoming callers, rather than incoming callers leaving a personalized message to a telephone subscriber. A subscriber is provided with the capability for the one or more unique messages to be delivered to the groups of callers, without the subscriber being required to contact each caller individually. The present invention is implemented with a messaging system host which can be an Intelligent Peripheral (IP) which forms part of the Advanced Intelligence Network (AIN).

Description

PERSONALIZED MESSAGING SYSTEM
FIELD OF THE INVENTION
This invention relates to telecommunications, and in particular to telecommunication networks offering personalized messaging system functionality.
BACKGROUND OF THE INVENTION
Recent advancements in telecommunication networks have made possible enhanced services that were not previously available to telephone subscribers. Calling Line Identification (CLID), voice mail, automatic call back are just a few of the many enhanced services that telephone subscribers have become accustomed to using in the past few years.
Many of the aforementioned enhanced services have become available on a wide-scale basis due to the Advanced Intelligent Network (AIN). AIN is an infrastructure proposed by Bellcore which is being put in place and used by exchange carriers to deploy new services quickly and effectively. The AIN infrastructure simplifies the design and implementation of new telecommunication services by defining a set of network elements, messages and call models. This allows for many services to be constructed using these standard building blocks and deployed quickly and effectively to end users. The AIN
architecture is outlined by Berman et al in the ICC '91 proceedings, Volume 2 at pages 21.1.1 to 21.1.5, June 1991.
The contents of this publication are incorporated herein by reference .
SUMMARY OF THE INVENTION
The present invention provide telephone subscribers with a voice mail system that allows personalized messages to be played back to specific callers or groups of callers. The personalized messaging system of the present invention can be thought of as a kind of reverse voice mail system, in that personalized messages can be played out to incoming callers, rather than incoming callers leaving a personalized message to a telephone subscriber. The present invention is particularly useful for telephone subscribers who must deliver one or more of the same unique messages to a group or groups of callers.
The present invention provides the capability for the one or more unique messages to be delivered to the groups of callers, without the telephone subscriber being required to contact each caller individually.
In accordance with one feature of the present invention, there is a provided a reverse voice mail personal messaging system that allows a subscriber's personalized messages to be played back to specific callers or groups of callers.
In accordance with another feature of the present invention a subscriber can designate a group or groups of callers to receive one or more personalized message.
In accordance with another feature of the present invention a subscriber can specify conditions when the reverse voice mail personal messaging system is to operate, and the conditions under which it is to cease.
In accordance with another feature of the present invention the subscriber may receive confirmation of receipt of personalized messages by callers.
In accordance with another feature of the present invention the callers are prompted to enter identification information prior to delivery of the subscriber's personalized message.
In accordance with another feature of the present invention there is provided a reverse voice mail personal messaging system that is implemented in accordance with AIN.
In accordance with an aspect of the present invention there is provided a messaging system host comprising: a database for storing a message left by a subscriber and a password associated with said message; a receiver for receiving an incoming call from a caller; a processor for prompting the caller to input a caller identifier and for comparing the caller identifier to the password stored in said database; and, message playback means for playing said message to said caller when said caller identifier matches said password.
In accordance with another aspect of the present invention there is provided a method for delivering a message left by a subscriber for a caller comprising the steps of:
i, storing a subscriber message and associated password in a database at a messaging system host; ii. diverting an incoming call from said caller to said messaging system host; iii.
prompting said caller for a caller identifier; iv. comparing said caller identifier to said password; and, v. playing back said subscriber message to said caller if said caller identifier matches said password.
BRIEF DESCRIPTION OF THE DRAWINGS
Preferred embodiments of the invention will now be described with reference to the attached drawings in which:
Figure 1 is a schematic diagram of a typical telephone network configuration offering the features of the present invention;
Figure 2a is a general flowchart of the steps taken when an incoming call is received by the system of the present invention;
Figure 2b is a general flowchart of the record new outgoing message steps of the present invention;
Figure 2c is a general flowchart of the set password for outgoing message steps of the present invention;

Figure 2d is a general flowchart of the set conditions steps of the present invention;
Figure 2e is a general flowchart of the check receipt of messages steps of the present invention;
Figure 2f is a general flowchart of the play reply messages steps of the present invention;
Figure 2g is a general flowchart of the incoming call from caller steps of the present invention;
Figure 3 is a schematic diagram of a typical CCS7 network configuration;
Figure 4 is an AIN call model of the message setup steps of the present invention;
Figure 5 is an AIN call model of the message retrieval steps of the present invention; and, Figure 6 is a block diagram of an Internet enabled message setup embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Figure 1 is a schematic diagram of a typical telephone network configuration offering the features of the present invention. In summary, the present invention allows a subscriber 25 to leave a personalized message or messages at messaging system host 10 for specific callers 15 or groups of callers to receive. The system of the present invention is a type of reverse voice mail system. Callers 15 dialling the directory number of subscriber 25 when the system of the present invention is operational are diverted instead to messaging system host 10 through the Public Switched Telephone Network (PSTN) 20. The PSTN 20 illustrated in Figure 1 is meant to include any public switched connection between callers 15 and subscriber 25, be it analog, digital, land-based, sea-based, radio, microwave, cellular, etc. After the identity of callers 15 is confirmed, messaging system host 10 will play a personalized message left by subscriber 25. Once the personalized message is played, caller 15 is given the option to continue normal call processing.
In accordance with one embodiment of the present invention, system host 10 is one of the building blocks of the AIN architecture known as an Intelligent Peripheral (IP). The IP provides resources such as voice recognition, customized concatenated voice announcements, and dual tone multi-frequencies (DTMF) digit collection. The latter two of these resources are essential to the operation of the present invention, and therefore any system host that can provide these two resources can be used in the place of an AIN IP (referred to herein as "IP").
The IP contains a processor and switching matrix to connect callers 15 and subscriber 25 (collectively referred to herein as "users") to the aforementioned resources. In addition, the IP supports flexible information interactions between users and the PSTN 20, including message playback means. Typically, the IP has resource management capabilities to search for idle resources, initiate those resources, and return them to their idle state.
When system host 10 is an IP, it is typically connected to another AIN building block, the Service Switching Point (SSP) which forms part of the PSTN 20. The interface between the SSP and IP is an integrated services digital network (ISDN), primary rate interface (PRI) and/or basic rate interface (BRI). A typical network configuration that supports AIN messaging will be described in detail hereinafter with respect to Figure 3.
The system of the present invention is to be distinguished from a traditional voice mail system, where caller 15 is provided with the capability to leave a personalized message for subscriber 25. Traditional voice mail systems do not provide the necessary functionality in circumstances where subscriber 25 needs to deliver personalized messages to one or more groups of callers.
The present invention is particularly useful for subscribers who, due to their elevated position in a hierarchy, are frequently charged with the responsibility of delivering the same unique message to one or more groups of callers. A
cogent example would be a subscriber who is a sports coach, who must inform the members of his/her team of the location of the next game. If the number of team members is numerous, then the delivery of such a message to each team member individually can be time consuming and inefficient. Thus, the present invention provides the capability for one or more unique messages to be delivered to callers or groups of callers, without subscriber being required to contact each caller 15 individually.
In accordance with the present invention, subscriber 25 can leave multiple messages for different groups of callers 15, with each message being assigned its own message 20 identifier, or password. Upon being connected to system host 10 through a receiver, callers 15 can identify themselves by the entry of a personal identification number (PIN) or voice print, or by CLID, all of which can act as a password for the message to be retrieved. A PIN can be any combination of 25 numbers entered from a numeric keypad of any telephone. System host 10 contains resources and memory for the purpose of storing PIN information and/or digitized voice prints assigned to each personalized message. voice recognition systems well known in the art are utilized by system host 10 to verify voice data. System host 10 verifies the integrity of all security information entered by caller 15, and if accepted, proceeds to play the personalized message left by subscriber 25.

Subscriber 25 may also leave multiple messages for different groups of callers, with each group of callers being assigned unique security information for the purpose of retrieving their appropriate message. With reference to the sports coach paradigm above, different members of the team may be required to attend different practise sessions. Through the use of the present invention, the sports coach (as subscriber 25) is able to assign different PIN codes or other security information to different groups of team members. For the purposes of illustration, the sports coach may wish to deliver three different messages to three distinct groups of team members. The three groups of team members would be informed in advance of the security information, be it PIN numbers or otherwise, assigned to the group to which they belong. When such team members (as callers 15) dial the directory number of the sports coach, they will be prompted by system host 10 for the security information. Upon the entry of accurate security information, system host 10 will retrieve the appropriate personal message assigned to the group of callers to which they belong.
Figure 2a is a general flowchart of the steps taken when an incoming call is received by the system of the present invention. Persons skilled in the art will appreciate that all of Figures 2a - 2g are general in nature and are designed for illustrative purposes only. Many systems can be designed that embody the basic features of the present invention without utilizing the steps shown in Figures 2a - 2g.
At step 100, an incoming call is received by system host 10 (shown in Figure 1). The incoming call could have been made by one of callers 15, subscriber 25, or a third party. At step 102, the incoming caller is prompted for a password by a concatenated voice announcement resource of system host 10. By making use of one or more processor resources of system host 10 such as voice recognition, DTMF digit collection or CLID, the identity of the incoming caller can be confirmed. If identity confirmation is confirmed by means of DTMF digit collection, the incoming caller would be asked to enter a PIN number.
System host 10 would then use DTMF digit collection to collect the digits entered by the incoming caller, and compare the PIN
number to one of the PIN numbers already stored in memory. If the PIN number entered by the incoming caller matched one of the PIN numbers assigned to a caller 15, then the system would proceed to step 220 (described in Figure 2g). If the PIN
number matched the PIN number assigned to a subscriber, then system would proceed to step 104. If the PIN number did not match any PIN number stored by system host 10, the system would proceed to step 200 and exit (with an option for the caller to leave a voice mail message for the subscriber).
At step 104 (the step which is reached if the incoming caller is identified as the subscriber), the subscriber has five options: 1. To record new outgoing message, 2. To set password for outgoing message, 3. To set conditions for outgoing message, 4. To check receipt of outgoing message, 5. To play reply message, and 6. To exit. The system would then use DTMF digit collection to collect the digits) entered by the subscriber, and depending on the digit, proceed to one of steps 120, 140, 160, 180, 190 or 200 as illustrated in Figure 2a.
If the subscriber selects option 1 (record new outgoing message), the system proceeds to step 120 illustrated in Figure 2b. The system will then use customized concatenated voice announcements to prompt the subscriber at step 122 to record a new outgoing message which will be stored using conventional memory devices associated with system host 10.

Typically, the message will be digitized using techniques well-known in the art, but any method of voice collection and storage may be used in accordance with the present invention.
For the purpose of simplicity, Figure 2b only shows the steps taken to record a single outgoing message. However, the system of the present invention has the capability to record a plurality of outgoing messages, which can be retrieved by one or more groups of callers. Once all the outgoing messages to be recorded by the subscriber at this session have been recorded, the system returns to subscriber options at step 104 of Figure 2a.
Referring back to Figure 2a, step 104, if the subscriber selects option 2 (set password for outgoing message), the system proceeds to step 140 illustrated in Figure 2c. At step 142, the subscriber is provided with four options, 1. To set Personal Identification Number (PIN) password, 2. To set voice password, 3. To set Calling Line ID as Password, and 4. To return to subscriber options (step 140 of Figure 2a). If the subscriber selects option 1, the system proceeds to step 144 and will use DTMF digit collection to collect the digits of a PIN password for an outgoing message. That PIN password will then be stored in a database by the system host. If the subscriber selects option 2, the system will proceed to step 146 and prompt the user to enter a voice password for an outgoing message. Typically, the system will collect the voice password, digitize it, and store it, though any means of voice storage and retrieval system will work in accordance with the present invention. If the user selects option 3, the system will proceed to step 148 to collect the directory number of the intended caller. If the user selects option 4 (or after steps 144, 146 or 148 have been concluded), the system will return to subscriber options at step 104 of Figure 2a. For the purpose of simplicity, Figure 2c does not show other attributes of the set password for outgoing message routine. For example, the subscriber may also utilize steps 144 or 146 to set his/her own personal password which provides the means for subscriber identification in Figure 2a. As well, while not shown in Figure 2c, the subscriber has the option of specifying different PINS, voice passwords or Calling Line Identification (CLID) numbers for different outgoing messages. Persons skilled in the art will appreciate that the Steps shown in Figure 2c can be easily modified to provide for these attributes.
Referring back to Figure 2a, step 104, if the subscriber selects option 3, the system proceeds to step 160 illustrated in Figure 2d. The subscriber is then provided with a number of choices of conditions for the outgoing messages stored by the system including: choice 1. To terminate when message played once, 2. To terminate when message played to all callers, 3. To terminate when message played for a specified number of times, 4. To terminate after specified number of days, and 5. To return to subscriber options (step 140 of Figure 2a). The system then uses DTMF digit collection to collect the choice of the subscriber, and institute the selected option. For the sake of simplicity Figure 2d is illustrated in a manner that suggests that conditions may be set for only one message. However, as with Figures 2b and 2c, the system can accommodate the entry of conditions for a number of messages meant for one or more groups of callers. If the user selects options 1 or 2, the system will institute the selected condition and proceed to subscriber options (step 104 of Figure 2a). If the user selects option 3, the system will proceed to step 164 and prompt the subscriber to enter the number of times the message is to be played. This data will then be stored. By the use of this option, the subscriber can control the number of accesses to the message. Once the desired number of message accesses has been reached, the outgoing message will not be available for playback to any caller. If the subscriber selects option 4, the system will prompt the user to enter the number of days the message is to be played. This data will then be stored. Option 4 is a variation of option 3, except that the maximum number of accesses associated with a message is replaced with a maximum number of days. Of course, option 4 can be changed to any period of time, including hours, weeks, etc. The subscriber thereby has maximum flexibility and control over accessing periods for each outgoing message. If the subscriber selects option 5, the system proceeds to step 104 of Figure 2a.
Referring back to Figure 2a, step 104, if the subscriber selects option 4 of Figure 2a, the system proceeds to step 180 of Figure 2e where the subscriber can check receipt of messages by callers. At step 182, the subscriber is prompted to enter a message number. Though not shown in Figures 2b, 2c and 2d, each outgoing message is associated with a unique message number, thereby enabling the subscriber to keep track of each outgoing message. The system host 10 will use a database to associate each message number with a different outgoing message. Included in that database will be a field for message status keeping track of whether the message has been retrieved, the number of accesses, the dates and times of accesses, etc. DTMF digit collection will be used to collect the digits) of the message number. At step 184, the system will check the aforementioned database for message status. At step 186, the system will provide a voice prompt to subscriber of message status, including any and all information stored in the aforementioned database concerning the message.

Once message status has been relayed to the subscriber, the system will return to subscriber options 104.
Referring back to Figure 2a, step 104, if the subscriber selects option 5, the system proceeds to step 190 of Figure 2f where the subscriber can play reply message(s). At step 192, the system plays all reply messages left by callers at step 226 (see Figure 2g). The subscriber then returns to subscriber options 104.
Figure 2g is a general flowchart of the incoming call from caller steps of the present invention. Referring back to Figure 2a, a caller is identified by the system following the entry of a caller password or message identifier (i.e. one of the caller passwords input by the subscriber at steps 144 or 146 of Figure 2c). At step 220, the system recognizes that it has received an incoming call from a caller. At step 222, the system plays the outgoing message destined for that caller. If the system is designed to store only one message, then that message is played to the caller. If the system is designed to store more than one outgoing message (the more typical embodiment), then the caller's password entered at step 102 of Figure 2a will designate the outgoing message to which the caller in intended to hear. In one embodiment of the present invention, a different password will be associated with each outgoing message so that one caller may be provided with a plurality of passwords for receipt of a number of messages. In another embodiment, the caller may be provided with a unique password enabling retrieval of multiple outgoing messages. In that circumstances, step 222 will be repeated until all outgoing messages intended for the caller have been played.
After playback of all outgoing messages, the system proceeds to step 224, where the caller is then provided with a number of choices, including 1. To leave reply message, and 2. To exit.

The system then uses DTMF digit collection to collect the choice of the caller, and institute the selected option. If the caller selects option 1, the system will then use customized concatenated voice announcements to prompt the caller at step 226 to record the reply message which will be stored using conventional memory devices associated with system host 10. Typically, the message will be digitized using techniques well-known in the art, but any method of voice collection and storage may be used in accordance with the present invention. After the reply message is recorded, of if the caller selects option 2, the system exits at step 200.
In one embodiment of the present invention, the system of the present invention is implemented by the use of an Intelligent Network (IN) such as AIN. In that case, the system is said to be network-based (as opposed to switch-based) with the functionality of the present invention being provided by network elements, rather than telephone switches. However, persons skilled in the art will appreciate that though it would not involve the most efficient allocation of resources, the present invention could be deployed at the switch level.
Referring to Figure 1, system host 10 would not provide the functionality of the present invention in one centralized location, but instead would be deployed at each telephone switch (such as a Nortel DMS switch) directly connected to a subscriber's telephone.
However, a switch-based solution is not preferred since it involves a duplication of network resources. The advantage of using an intelligent network such as AIN to implement the present invention is that service logic is transferred from the switch level to the network level, thereby providing an efficient allocation of resources and allowing for the freeing up of trunk circuits between switches to handle actual calls.
Figure 3 is a block diagram of a typical CCS7 network configuration that supports AIN messaging. There is shown two Service Switching Points (SSPs) 310, 312 connected by means of a multiplicity of voice trunks 314, four Signalling Transfer Points (STPs) 316, 318, 320, 322 in mated pair configuration, and two Service Control Points (SCPs) 324, 326, all of which are interconnected by signalling links 328, 329, 330, 332, 334.
A signalling link is the most basic CCS7 entity, and is a direct physical connection between two CCS7 nodes. Subscriber CPE 311 is shown connected to SSP 310. SSP 310 is known as the "central office" to which Subscriber CPE 311 is connected.
Caller CPE 325 is connected to SSP 312.
SSPs 310, 312 are telephone switches which provide telephony services, and actually host lines and trunks containing voice and data traffic. An example of a SSP switch is the Digital Multiplex Switch (DMS) manufactured by Nortel.
Unlike other nodes in a CCS7 network, the STPs 316, 318, 320, 322 do not host any lines or trunks, and do not act as a source or ultimate destination for CCS7 messages. STPs 316, 318, 320, 322 are packet switches responsible for receiving incoming control CCS7 messages from different SSPs 310, 312 or SCPs 324, 326, and routing the messages to the appropriate destination SSP or SCP. To ensure network availability, STPs 316, 318, 320, 322 are customarily deployed in mated pairs, so that if problems develop in one STP (for example 316), the mated STP
(in this case 318) would provide an uninterrupted transfer of application and network management messages to all concerned nodes in the network. In Figure 3, STPs 316, 318 are mated pairs. Similarly, STPs 320, 322 are mated pairs. STPs in a mated pair perform identical functions, and are redundant.
Each SSP 310, 312 has two links 328, 329 (or sets of links), one to each STP of a mated pair. These links connect SSPs 310, 312 to SCPs 324, 326 which house databases with call routing information for advanced services such as Caller ID, 800 number service, credit card validation, and Centrex.
The basic principle of AIN is that it allows an SSP
in a CCS7 network to stop and request information from an SCP
on how to proceed at a number of points (detection points) during the processing of a call. In a CCS7 network supporting AIN, SSPs send and receive messages to/from an SCP that combines a large consolidated database and the service logic needed to access and use the data to apply call services. SSPs enhanced for AIN use a special set of Transactions Capability Applications Part (TCAP) messages to dialog with the appropriate AIN service logic in an SCP. In an AIN SSP, upgraded call processing software provides 'hold points' where call processing can be suspended while a query message is sent to an SCP. SSPs that receive query messages from SSPs can instruct SSPs to continue with normal call processing, or over-ride normal call processing and perform specific actions such as: (i) collect more digits, (ii) route the call to a new directory number, (iii) route the call using a specific route list, (iv) play an announcement.
During call processing in an AIN CCS7 network, a number of detection points are reached where call processing can be temporarily suspended. AIN 'triggers' are used to determine whether to send a message to an SCP to invoke the service logic associated with a particular detection point.
Depending on the services sought by the customer, there may be one or more triggers at each detection point, that is a list of conditions which must be met before an AIN message is sent. At each detection point, a call is checked for subscriptions to triggers. When a subscribed trigger is found, details of the call are checked against the criterion list associated with the trigger. If all criteria are matched, the SSP generates a query to the SCP, and suspends call processing until instructions from the SCP are received. Usually, subsequent call processing for that call will be influenced by the instruction provided by the SCP.
In the CCS7 network illustrated in Figure 3, query messages from SSP 310 to SCP 324 in response to an AIN trigger are sent in TCAP format across CCS7 links 328, 332. Upon receipt of the query message, SCP 324 will access its database tables and construct a call control message that is returned to SSP 10 across CCS7 links 328, 332. SSP 310 will then use the call control message to complete the call through the network.
An AIN-capable intelligent peripheral (IP) 340 is connected to SSP 310 by CCS7 link 342. IP 340 is an intelligent telecommunications device which provides capabilities for the playback of prompts or announcements, long and short-term message recording, DTMF digit collection and detection, DTMF tone generation, message compression, call control and voice recognition. IP 340 is application independent and its capabilities can be used by multiple applications.
For the embodiment of the invention that is implemented by an AIN network, all subscribers to the service implemented by the present invention (such as subscriber CPE
311) would be assigned one or more AIN triggers in SSP 310 using known AIN capabilities. Subscribed triggers are provisioned to the customer's line, so that any calls originating from or terminating to that line would encounter the trigger. When an AIN SSP detects that AIN service control is needed (i.e. where an active trigger is detected), normal switching system call processing is suspended until the SSP and SCP and/or IP complete communications. First, the SSP will send an AIN message containing information, such as calling/called party identity and other call processing information, to the appropriate SCP. The SCP uses service control logic and subscription information to return a message to the SSP requesting it to perform some further processing of a call or customer service request. This may include one or more interactions with an IP. Upon completion, the call progresses in the usual manner.
Figure 4 is a call model of the message setup steps of the present invention, when the invention is implemented by the use of AIN. It should be emphasized that Figure 4 is only one of many possible call models for implementing the present invention. As such, it is provided for illustration purposes only. Further information concerning all of the AIN triggers, messages and principles discussed herein can be obtained from Bellcore GR-1298-CORE. The AIN elements of Figure 3 will be used to illustrate the call model of Figure 4.
At step 401, the subscriber (such as any subscriber using subscriber CPE 311) dials a special directory number (DN) or access code (such as *123) to access the service of the present invention. At step 402, the dialling of the DN or access code results in a trigger, such as the Specific Digit-String trigger, being encountered at SSP 310.
The leads to the construction of an Info Analyzed AIN message by SSP 310, which will be sent to SCP 324. The Info Analyzed Message is populated by the SSP with information such as the Access Code (if applicable), Calling Party DN, etc.
At step 403, SCP 324 receives the Info Analyzed AIN
message and thereby recognizes that the service of the present invention is being invoked. SCP 324 then forwards a Send_to Resource message to direct the caller to IP 340. At step 404, IP 340 prompts the subscriber to record a customized message and requests identification parameters (such as PIN, CLI, Name, etc.) for the intended callers) (see the description of Figures 2b and 2c). After completing these steps, IP 340 sends the identity parameters to SCP 324 using the Call-Info From Resource AIN message.
At step 405, SCP 324 stores the identity parameters received from IP 340. Using the Update AIN message, SCP 324 then instructs SSP 310 to set the Termination Attempt trigger against the subscriber's directory number. This will allow the service of the present invention to be invoked whenever a caller dials the subscriber's directory number. Also at step 405, the Call-Info To Resource message is forwarded by SCP 324 to instruct IP 340 to provide confirmation and release call after an announcement is made to the subscriber. At step 406, IP 340 provides an announcement to the subscriber that the service of the present invention has been activated. The call is then released. At step 407, the subscriber hangs up.
Figure 5 is a call model of the message retrieval steps of the present invention, when the invention is implemented by the use of AIN. As with Figure 4, Figure 5 is only one of many possible call models for implementing the present invention. Once again, the AIN elements of Figure 3 will be used to illustrate the call model of Figure 4.
At step 451, the caller (such as any caller having access to caller CPE 325) dials the subscriber's DN. At step 452, this results in a triggering of the Termination Attempt trigger at SSP 310, which queries SCP 324 using the Termination Attempt AIN message. In accordance with AIN
principles, SSP 310 will send a Termination Attempt message whenever it encounters a Termination Attempt trigger.
At step 453, SCP 324 recognizes that the service of the present invention is being accessed and initially attempts to terminate the call (as the preferred option) to the intended DN. SCP 324 also instructs SSP 310 to arm the Busy/No Answer Event against that DN using the Authorize Termination AIN
message. At step 454, SSP 310 arms the requested AIN event and attempts to terminate the call to the subscriber's DN. If the subscriber does not answer the call, the call would hit the Busy/No Answer event. SSP 310 would then inform SCP 324 using the T Busy/T No Answer AIN message. At step 455, SCP 324 instructs SSP 310 to connect the IP 340 to the caller and instructs IP 340 to check the caller's identity. If Calling Line Identification (CLID) is the identifying mechanism, SCP
324 performs that function immediately and the system proceeds directly to step 458.
If some other identification means has been selected by the user (such as PIN or voice password), at step 456, SSP
310 sets up a link between the caller and IP 340. At step 457, IP 340 prompts the caller for the message identifier (PIN, voice password, etc. See step 102 of Figure 1). IP 340 then utilizes a Call_Info_From Resource message to forward the collected message identifier to SCP 324.
At step 458, SCP 324 validates the collected message identifier with that previously stored by the subscriber. If the message identifier is incorrect, the caller is given the option to leave a voicemail message for the subscriber (at step 460). If that option is rejected, the call is terminated. If the message identifier entered by the caller is correct, SCP
324 utilizes the Call-Info To Resource AIN message to instruct IP 340 to play the message for the caller and check if a reply is needed. At step 459, IP 340 plays the message, and prompts the caller to leave a reply message for the subscriber. If no message is left, the call terminates. If the caller chooses to leave a reply message, IP 340 advises SCP 324 using the Resource Clear AIN message. IP 340 then releases its link to SSP 310. At step 460, SCP 324 instructs SSP 310 using the Forward Call AIN message to forward the call to the subscriber's network voice mail system. At step 461, the call is forwarded to the subscriber's network voice mail and is collected and stored using conventional means. The reply message left by the caller would normally be retrieved by the subscriber in accordance with voice mail systems well known in the art.
The call model steps illustrated in Figures 4 and 5 demonstrate minimum functionalities for the invention. The AIN
system can accommodate all of the optional features of the invention discussed in relation to Figures 2a - 2g using known AIN triggers and messages. Other telecommunications networks that are capable of accommodating the features illustrated in Figures 2a - 2g can be used in the place of AIN network to implement the system and method of the present invention.
Many modifications and variations to the preferred embodiment are possible. For example, another method for a subscriber to activate the message service of the present invention is via the Internet. Figure 6 is a block diagram of an Internet enabled message setup embodiment of the present invention. Instead of dialling an access code or DN to reach the system host of the present invention, a subscriber would use the Internet to reach the system host.
In the embodiment illustrated in Figure 6, a subscriber at computer terminal 600 would access, though Internet 601, a server 602 supporting the service of the present invention. The server 602 would likely be a front-end to an AIN Service Management System (SMS) 603. Upon reaching server 602, the subscriber would enter the necessary identity information and message through a Graphical User Interface (GUI) template. When the information is complete, the user would submit the information to the Internet for forwarding to server 602. Upon receipt, server 602 will transmit the information to SMS 603, where it will be forwarded to the SCP
604. In this embodiment, SCP 604 will then activate the AIN
TAT trigger on the subscriber's telephone line and inform server 602 of this activation. SCP 604 would also provide SMS
with the IP address for this message to be stored. The SMS 603 would then forward the message text to the IP 605 where it is to be stored. Upon receipt, the IP 605 would inform the SMS
603 of the successful storage of the message. The SMS 603 would then transmit a message over the Internet 601 to the subscriber 600 that the service has been successfully activated. All message retrieval operations as described above would be unaffected by the Internet setup model shown in Figure 6.
The above description of a preferred embodiment should not be interpreted in any limiting manner since variations and refinements can be made without departing from the spirit of the invention. The scope of the invention is defined by the appended claims and their equivalents.

Claims (26)

1. A messaging system host comprising:
a database for storing a message left by a subscriber and a password associated with said message;
a receiver for receiving an incoming call from a caller;
a processor for prompting the caller to input a caller identifier and for comparing the caller identifier to the password stored in said database; and, message playback means for playing said message to said caller when said caller identifier matches said password.

2. The messaging system host of claim 1 wherein said database can store a plurality of personalized messages and passwords associated with each of said personalized messages.

3. The messaging system host as claimed in claim 1 or 2 wherein the caller identifier is one of calling number identification (CLID), personal identification number (PIN), or voice print.

4. The messaging system host as claimed in any one of claims 1 to 3 wherein said database can store a reply message left by said caller for said subscriber.

5. The messaging system host as claimed in any one of claims 1 to 4 wherein upon said messaging system host being invoked, all calls destined to said subscriber are routed to said messaging system host.

6. The messaging system host as claimed in any one of claims 1 to 5 wherein all calls destined to said subscriber are routed to said messaging system host when the telephone line of said subscriber is busy or does not answer.

7. The messaging system host as claimed in any one of claims 1 to 6 wherein said messaging system host is invoked by the entry of a subscriber identifier.

8. The messaging system host as claimed in any one of claims 1 to 7 wherein said subscriber identifier is one of calling number identification (CLID), personal identification number (PIN), or voice print.

9. The messaging system host of claim 5 wherein said messaging system host remains invoked until said message has been played to said caller.

10. The messaging system host as claimed in any one of claims 1 to 9 wherein said messaging system host is an Advanced Intelligent Network (AIN) Intelligent Peripheral (IP) part of an AIN network, said AIN network comprising interconnections between an AIN Service Switching Point (SSP) and a telephone line for said caller, an AIN SSP and a telephone line for said subscriber, and an AIN Service Control Point (SCP) and said AIN
SSPs.

11. The messaging system host of claim 10 wherein an AIN
Termination Attempt trigger is assigned to said subscriber's telephone line.

12. The messaging system host as claimed in claim 10 or 11 wherein said database can store a plurality of personalized messages and passwords associated with each of said personalized messages.

13. The messaging system host as claimed in any one of claims 10 to 12 wherein the caller identifier is one of calling number identification (CLID), personal identification number (PIN), or voice print.

14. The messaging system host as claimed in any one of claims 10 to 13 wherein said database can store a reply message left by said caller for said subscriber.

15. The messaging system host as claimed in any one of claims 10 to 14 wherein upon said messaging system host being invoked, all calls destined to said subscriber are routed to said messaging system host.

16. The messaging system host as claimed in any one of claims 10 to 15 wherein all calls destined to said subscriber are routed to said messaging system host when the telephone line of said subscriber is busy or does not answer.

17. The messaging system host as claimed in any one of claims 10 to 16 wherein said messaging system host is invoked by the entry of a subscriber identifier.

18. The messaging system host as claimed in any one of claims 10 to 17 wherein said subscriber identifier is one of calling number identification (CLID), personal identification number (PIN), or voice print.

19. The messaging system host of claim 15 wherein said messaging system host remains invoked until said message has been played to said caller.

20. The messaging system host of claim 17 wherein said subscriber identifier is forwarded to said messaging system host via the Internet.

21. The method for delivering a message left by a subscriber for a caller comprising the steps of:
i. storing a subscriber message and associated password in a database at a messaging system host;
ii. diverting an incoming call from said caller to said messaging system host;
iii. prompting said caller for a caller identifier;
iv. comparing said caller identifier to said password;
v. playing back said subscriber message to said caller if said caller identifier matches said password.

22. The method of claim 21 further including the step of invoking said messaging system host by the entry of a subscriber identifier.

23. The method as claimed in claim 21 or 22 further including the step of forwarding a subscriber identifier via the Internet to invoke said messaging system host.

24. The method as claimed in claim 21, 22 or 23 further including the step of assigning the AIN Termination Attempt trigger to the telephone line of said subscriber.

25. The method as claimed in any one of claims 21 to 24 further including the step of checking the status of the telephone line of said subscriber, and only diverting an incoming call from said caller to said messaging system host when said telephone line is busy or does not answer.

26. The method as claimed in any one of claims 21 to 25 further including the step of checking the playback status of the subscriber message, and only diverting an incoming call from said caller to said messaging system host when said subscriber message has not yet been played back.