AU7859998A - Message deletion/replacement delivery option system - Google Patents

Description

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION NAME OF APPLICANT(S): Comverse Network Systems, Inc.

ADDRESS FOR SERVICE: DAVIES COLLISON CAVE Patent Attorneys 1 Little Collins Street, Melbourne, 3000.

*t.

INVENTION TITLE: Message deletion/replacement delivery option system The following statement is a fuldescription of thids invention, including the best method of performing it known to me/us:- 4! nl 1- Y la

CC*

9 a **0 a *0 0 *9 BACKGROUND OF THE INVENTION Field of the Invention The present invention is directed to a system that allows a user of a message system, such as a voice mail system, to specify that messages that become invalid be deleted or replaced and, more particularly, to a system that allows the person who leaves a message to specify a time/date for the 10 deletion of a message or to specify that a particular prior message that is no longer valid be deleted or replaced with a current message.

Description of the Related Art Currently message systems, such as voice 15 mail systems, e-mail systems, etc., allow a sender (an individual or a machine) to leave a message for another person or recipient. The sender can specify delivery options, such as marking the message "urgent" or requesting a return receipt. Some systems include a system level feature whereby all messages are marked for deletion after a specified period of time, such as 30 days. However, the sender does not have the capability of specifying when a message should be deleted. This can cause unnecessary work on the part of a recipient in listening to messages that are no longer valid. For example, when a message is left for a recipient concerning a meeting and the recipient does not listen to the message until after the meeting has occurred, the recipient's time is wasted. What is 2 782.1042 needed is a message delivery option that allows the sender to specify a message expiration date.

Some subscribers to messaging systems request automatic delivery of messages, such as weather and stock quotes. If the subscriber does not listen to the stored messages until after a number of such automatic messages are stored, the subscriber wastes time in listening to outdated messages. What is needed is the capability of automatically replacing a previous message with a •more current message.

SUMMARY OF THE INVENTION It is an object of the present invention to allow a message sender to leave a message for a recipient and to specify when that message is to be deleted.

It is an additional object of the present invention to delete messages that have a senderspecified expiration date only when the messages 20 have not already been played to, or reviewed by, the recipient.

~I It is also an object of the present invention to provide the ability to identify the source of messages and allow the source to delete or replace previously stored messages.

It is a further object of the present invention to reduce the unnecessary storage of invalid messages.

It is an object of the present invention to reduce the number of irrelevant messages stored in a message system.

It is an additional object of the present invention to give users more control over message delivery options.

It is an object of the present invention to optionally notify the sender of a message that includes an expiration date that the message has |1 been deleted without being reviewed by the recipient.

K

j

I

3 782.1042 It is also an object of the present invention to optionally provide a copy of a deleted, but unread, message back to the sender when it is deleted, thus allowing the sender to check the contents of an unread message- It is an object of the present invention to reclaim storage allocated for expired messages.

The above objects can be attained by a system that allows a user to specify an expiration 10 date and/or time for a "perishable" message as part of the specification of delivery options for the message. A message deletion process of the system checks messages for expiration and deletes those .4 that have not been reviewed by the recipient and which are expired. The deletion process can optionally alert the sender that the message has been deleted and/or return the message to the sender. The system also allows the sender to provide an identifier for the message when the 20 message is recorded, where the identifier is later used to find previously-stored and unread messages i *so that they can be replaced or deleted. The identifier can be a unique code or a unique pattern, such as a voice print.

These together with other objects and advantages, which will be subsequently apparent, reside in the details of construction and operation as more fully hereinafter described and claimed, reference being had to the accompanying drawings forming a part hereof, wherein like numerals refer to like parts throughout.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 depicts a voice mail system 8 into 4 which the present invention can be incorporated.

k 35 Fig. 2 depicts a bubble diagram of a send process sequence for messages.

:A a"

P-CU-

4 782.1042 Fig. 3 illustrates a modified delivery option prompt selection man-machine-interface sequence.

Fig. 4 shows a prompt sequence of the manmachine-interface for a perishable message delivery option.

Fig. 5 is a message record 30 for a voice message.

Fig. 6 is a message file header 32 for a S 1 0 voice message.

Fig. 7 depicts a delivery process.

Fig. 8 illustrates a purge process.

Fig. 9 depicts a linked list of perishable messages.

S s 15 Fig. 10 depicts generating a code for a replaceable message.

Fig. 11 shows replacing a message.

Fig. 12 depicts a modified user interface sequence regarding a number of perishable messages.

S. 20 Fig. 13 depicts a modified user interface sequence that announces the status of individual messages.

S DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention is directed to 25 allowing a message, such as a voice mail message, to be marked with an expiration date/time by the message sender. When the expiration date/time has passed, the system storing the message deletes or purges the message if it has not been read by the intended recipient.

The present invention is preferably implemented in a voice mail system 8, such as Sdepicted in Fig. 1, as described in U.S. Patent 5,029,199 which is incorporated by reference herein.

Such systems, e.g. the CO ACCESS@ and Access NP® systems, are available from Boston Technology, Inc.

S Systems 8, such as that depicted in Fig. 1, typically mark each message with a retention time 4~.na the time remaining before the message 1kT 782.1042 is purged. The systems 8 also include a process that deletes messages (or message files) that are marked for deletion or purging, such as those that have reached their maximum retention time- Such a process, which is often whimsically called a "grim reaper" program, is typically executed on a daily basis during a period in which the system is typically not busy. The present invention preferably uses such a program to delete or purge messages that have reached their expiration time.

S The typical deletion process that executes daily can g oo be used or such a program can be modified to execute I. more often.

To provide the sender with the ability to 15 specify an expiration date, in a system, such as a 1 o, voice mail system, the user interface that prompts the sender to select among delivery options needs to be modified to add a prompt sequence for delivery of perishable messages. The typical send sequence is s 20 depicted in Fig. 2. The Delivery Options 13 portion \I of the sequence is modified as depicted in Fig. 3.

Sa A prompt script 20 for the delivery options voice prompts is modified to include, as a menu item, a voice prompt 22 speaking, for example, "To [no longer] set an expiration date, press The *Gap" process flow path is also modified to include a selection 24 and the perishable delivery prompt sequence 26. This sequence 26 is depicted in more detail in Fig. 4.

The messages for a subscriber to a voice mail system, such as depicted in Fig. 1, are stored in message files. A linked list of message records (or entries), includes the names of the message files for each subscriber and is maintained in a S 35 subscriber database in a master control unit (MCU) 4 or in a specialized database management (DBU) j system/server. The message files themselves are stored in the disk storage of voice processing units (VPU). Each message file has a header followed by inww"'MMMM" 5 782.1042 the voice data as depicted in Figs. 5 and 6. The I data structure for the message record entry 30 in the linked list and the file header 32 of the message file can both be modified to include a message expiration time field 34 and 36, although it is not necessary that both the entry 30 and header 32 be modified. The header of Fig. 6 is preferably the one modified. If the modification is made in both places, a search of either the file headers or the linked list will uncover expired messages.

The sequence of events that is performed by the delivery options process to set the expiration time is depicted in the flow chart of .Fig. 7. When the record message 40 option is selected, the process determines 42 whether "Delivery Options" has been selected. If so, the process determines 44 whether "Other Delivery Options," such as a future delivery date, have been Sselected and sets 46 those other delivery options.

20 The process then determines 48 whether the "Perishable Delivery Option" has been selected and if so sets 50 the expiration time for the message from the senders input of the expiration time. The message is then sent or stored 52.

There are several different methods by which the messages that have expiration dates/times can be purged from the system. A first approach sends a command to a perishable message management process where the command specifies the message (either the record of the linked list or the message file itself) that is to be purged and the expiration time of the message. Such an expiration time command would typically be sent in association with step 50 of Fig. 7. A perishable message management process, such as depicted in Fig. 8, starts after the perishable message is sent 70 or stored and after the expiration time is set 72 in the record entry 30 and/or in the message file header 32. The expiration command for message i Ih~i

_-J

7 782.1042 expiration is recorded 74 in a queue of commands based on the time specified in the command. This queue can be stored, in a file or other suitable memory. A notify process awakes from a wait state on a regular basis and scans the queue for events that need to be started. If the scan discovers an expiration command, the management process is notified. When the perishable message management process receives a notification, it 0 compares 76 the expiration time to the current time and, if the expiration time is passed, the message is purged 78 from the recipient's mailbox by removing the message record from the linked list and deleting the message file using a process, such as the grim reaper process previously mentioned.

Note that if the queue of expiration commands is a queue sorted by time then the notify process only needs to look at the first entry in the queue to determine if the perishable message management process needs to be notified.

After the message is purged, the expiration command is removed 80 from the queue.

Removal from the queue stops the management process from starting the purge check sequence shown in Fig.

25 8 since it will not be notified. If the expiration time has not passed, the process checks 82 to see if the message has already been deleted and if so the command is removed 80 from the queue. If the message has not been deleted, the process checks 84 to see if the message has been saved, which indicates that it has been reviewed by the recipient. If the message has been saved, the command is removed 80 from the queue. If two commands have the same expiration time, the notify process notifies the management process for each of I these commands.

At step 78 the purge operation can be configured to notify the sender that the message is .o -8 782.1042 of Fig. 5, much like a conventional return receipt process notifies a sender when a message has been reviewed. The operation can also return the message to the sender rather than just nctifying the sender that the message is being deleted- A second approach to perishable message management utilizes the expiration time stored in the record 30 or the header 32 for each message.

Periodically the delete program is activated and all S 10 message records 30 and/or message file headers 32 are examined to determine if the expiration time stored therein has passed. If so, the message is purged. i A third approach involves creating a 15 linked list of messages that have expiration times.

This requires that the records for the messages or the headers of the message file be modified to include a further set of links. In this data structure, as depicted in Fig. 9, each mailbox includes a pointer 90 to the linked list of messages 92, 94 and 96 for that mailbox and each message includes a pointer to the next message in the list.

A perish list head pointer 98 points to the message (92) that has the earliest expiration time and each message has a pointer to the message (94) that has the next earliest expiration time so that the list starting with the pointer 98 is in expiration time order. Periodically, the delete or purge process examines the first entry in the expiration list using the pointer 98. If the expiration time for the first message on the list has passed (and the message has not been saved), the message file is deleted and the pointer 98 is made to point to the next (second) message (94) on the list. If the first message expiration time has not passed, no action is required because no other messages have Sexpired. This approach requires that new messages that are set for expiration be conventionally added

O-N

9 -782-1042 to the list by scanning the list to insert the links to the message in the appropriate point in the listinstead of deleting messages that have become aged, it is possible to replace them with a newer message- During the recording process discussed previously it is possible to modify the "Other Delivery Options" to allow a sender to specify that a message may be replaced in the future and to identify a message that-,is to be replaced- When the user selects 100 this option, as illustrated in Fig- 10, the system generates 102 and returns or provides 104 to the sender a unique code identifying the message and then stores 106 the code in~ the record 30. The sender can instead optionally be allowed to supply or input the unique code thereby allowing the sender to select a code that is easy to remember. At some future date when the sender again interacts with the mailbox where the replaceable message is stored, the delivery options process allows the sender to select .110 the option of replacing a message and then to specify 112, with the unique code, the message to be replaced as depicted in Fig. 11. The system then searches 114 the message list for the mailbox using the unique code, deletes 116 the message to be replaced, if it has not already been replaced or saved, and adds the newA message to the message list. of course, the message with the unique code can just be deleted instead of replaced- A further refinement on the replacement of messages involves conventionally obtaining a voice print of the sender while the replacement message is being recorded. The voice print of the sender is obtained and used at a future date to search the messages in the mailbox for a matching voice. When a match is found, the sender can be played the message and is allowed to replace the found message with the replacement message.

10 782.1042 The unique code or identifier can also be used to allow a sender to identify a previously stored message that is to be deleted rather than being replaced, essentially saying "Never mind." When the sender and recipient are both subscribers to the system, the sender's mailbox ID can be used as the unique identifier.

The processes and data structures of the present invention are typically stored on the hard disk media of the system of Fig. 1, however, the processes can be stored on other media such a floppy disk, ROM and PROM.

To make the system easier to -use for the message recipient, preferably, the system will check for perishable messages and announce to the recipient, when the recipient accesses the mailbox, that the recipient has one or more messages that are perishable in the same way that systems announce urgent messages. The system could also particularly indicate the number of messages that will expire within the next 24 hours. The system can also announce to the recipient that messages have expired unreviewed. A modification of an interface prompt "sequence to announce the number of message and the time of expiration is illustrated in Fig. 12. In addition the system can indicate whether each Sindividual message is a perishable message as the subscriber steps through the list of messages in the subscriber's mailbox to play them or skip them.

30 This is illustrated by the interface sequence of Fig. 13.

When playing the messages to the recipient, the system can play them in time of recording order or play perishable messages with a higher priority.

The present invention has been described with respect to messages of a voice mail system.

J The present invention is. however, applicable to other types or message systems such as text, 81 3 fl m m ii 782.1042 facsimile, e-mail, video, etc. The present invention has also been described with respect to setting a time or date for expiration. Instead, a variable retention period could be set by the user.

The system has also been described with respect to setting a variable time. It is possible for the system to allow the user to select preset expiration times such as "at the end of the month." The present invention has also been described with respect to detecting an expired message at the expiration time. The deletion operation could instead be performed at specified intervals such as nightly.

The many features and advantages of the invention are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the invention which fall within the true spirit and scope of the invention. Further, *i 20 since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact "4 construction and operation illustrated and described, and accordingly all suitable I 25 modifications and equivalents may be resorted to, falling within the scope of the invention.

Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

/'-41 -7 7 7 M 1 1

Claims (3)

1. A message Process' comnprisinlg: allowing a message sender to Set an expiration time for a Message recorded by the sender S for a recipient; and to deleting the message when the expirato tim ha p2.e A process as recited in claim 1, wheeinthemesageis not deleted if the recipient 0 has reviewed the message, A message storage systm opiig a user interface allowing a user to store a mesagefor a recipient and designate an expiration time for the message.

154. A system as recited in claim 3, furhe copising means f or purging the msage when the expiration time has passed. A computer readable storage media including a process allowing a message sender to set an expiration time for a message stored by the sender for a recipient and deleting the message when the expiration time has passed. 6. A computer readable storage media including a message having an expiration time for he~e~ae stored by a sender for a recipient and used to delete the message when the expiration time has passed.L J 7. A message processi comprising: 13

782.1042 storing a replaceable message having a unique replacement identifier; and replacing the replaceable message with a replacement message or deleting the message when the replaceable message is specified with the identifier. 8. A message system, comprising: a computer system storing a replaceable message having a unique replacement identifier and replacing the replaceable message with a replacement message or deleting the message when the replaceable I message is specified with the identifier. 9. A message process, comprising: 1. storing a deletable message having a 15 unique identifier; and deleting the deletable message when the deletable message is specified with the identifier. A message system, comprising: a computer system storing a deletable 20 message having a unique identifier and deleting the deletable message when the deletable message is i specified with the identifier. 11. A message storage system, comprising: a user interface announcing to a stored S. 25 message recipient that an unreviewed stored message is set for expiration. 12. A system as recited in claim 11, wherein the announcing occurs at a predetermined time before the message is deleted. r. o ii i i. 14 13. A message process substantially as hereinbefore described with reference to the drawings. 14. A message storage system substantially as hereinbefore described with reference to the drawings. 15. A computer readable storage media substantially as hereinbefore described with reference to the drawings. S. 16. The steps, features, compositions and compounds disclosed herein or referred to or indicated in the specification and/or claims of this application, individually or collectively, and any and all combinations of any two or more of said steps or features. a DATED this FOURTH day of SEPTEMBER 1998 Comverse Network Systems, Inc. by DAVIES COLLISON CAVE Patent Attorneys for the applicant(s) -L I-I I 1; i 11 :I