Telephonic communications – Audio message storage – retrieval – or synthesis – Interacting voice message systems
Reexamination Certificate
1998-09-25
2003-01-07
Tsang, Fan (Department: 2645)
Telephonic communications
Audio message storage, retrieval, or synthesis
Interacting voice message systems
C370S235000, C348S014080, C707S793000, C707S793000, C709S206000, C709S235000
Reexamination Certificate
active
06504915
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to messaging systems, and more particularly to a multiple node messaging system wherein each node has shared access to the message stores of other nodes.
BACKGROUND OF THE INVENTION
Messaging systems that provide voice, fax and/or e-mail messaging capabilities are well known.
FIG. 1
illustrates an exemplary prior art messaging system developed by Unisys Corporation, the assignee of the present invention. The system of
FIG. 1
comprises multiple servers (e.g., an A-series or Clearpath™ computer offered by Unisys Corp.) each supporting a network applications platform (NAP), which provides an underlying platform for storage and retrieval of messages, and a messaging application running on the platform. A voice mail application, such as the Unisys Universal Voice Messaging System (UVMS), is an example of a messaging application that runs on the messaging platform. The UVMS application determines how calls to the messaging system are handled, what prompts are played to callers, and which features are available. Such applications typically maintain a database of subscribers who have “mailboxes” on the system. The messaging platform interfaces to a telephone network through a Network Interface Unit (NIU). Received messages are stored by the messaging platform in a local message store, or voice file.
Network Interface Units are available from a number of different vendors. For example, NIUs suitable for use with the present invention include: (a) the Telephony Services Platform available from Unisys Corporation, Blue Bell, Pa.; (b) the Summa Four VCO 80 available from Summa Four, Inc., Manchester, N.H.; and (c) the Voice Frame 2020 available from Harris Corporation, Melbourne, Fla. The Telephony Services Platform (TSP) is most preferred. The difference between it and the other products just mentioned is that the TSP includes a board that plays back digitized voice from a voice file whereas the other products require a separate playback module.
In use, if a subscriber is not available when an incoming call is received, the Public Switched Telephone Network (PSTN) forwards the call to the messaging system, which typically allows the caller to record a message, and then will store the message for later retrieval by the subscriber. A key (or token) will be returned to the messaging application that uniquely identifies the stored message data within the message store. This key can be used at a later time to retrieve the message from the message store for playback to the subscriber.
In the exemplary system shown in
FIG. 1
, a first node of the system comprises a server/NAP
10
a
, voice file and database
12
a
and NIU
14
a
. Similarly, a second node comprises a server/NAP
10
b
, voice file and database
12
b
and NIU
14
b
; and a third node comprises a server/NAP
10
c
, voice file and database
12
c
and NIU
14
c
. The first node could be responsible for a predefined geographic area encompassing hundreds of thousands of subscribers. For example, the first node could be responsible for a large area such as Northern California, the second node could be responsible for Middle California, and the third node could be responsible for Southern California. The respective nodes are separately coupled to a public switched telephone network, or PSTN,
16
, and are thereby made accessible to their subscribers. Moreover, subscribers of one node can employ messaging to transfer copies of messages (such as voice messages) to subscribers of another node. The respective nodes, however, do not share access to each other's voice files, databases or NIUs.
FIG. 2
depicts the structure of the voice files
12
and database. This structure is described in detail in U.S. Pat. No. 5,138,710, Aug. 11, 1992, “Apparatus and Method for Providing Recoverability in Mass Storage Data Base Systems Without Audit Trail Mechanisms.” Briefly, each voice file is made up of a first database
12
-
1
(referred to as a Voice I/O Database, or VIODB) and a second database
12
-
2
, which is referred to as the “flat file” in the '710 patent. The VIODB
12
-
1
contains a series of records each of which includes a 48-bit (or 6-byte) message number (MN) and a series of pointers. Each pointer identifies a different voice message segment (VMS) in the flat file
12
-
2
. Each VMS comprises 32,256 bytes of voice data and is associated with recovery data (RD) including the MN corresponding to that VMS, the number of bytes in the voice message segment with that MN, as well as other information.
The VIODB
12
-
1
is utilized to provide access to stored data in the flat file
12
-
2
. In the embodiment disclosed in detail in the '710 patent, each record in the VIODB
12
-
1
comprises a Message Number (MN), Sequence Number (SN), Segment Counter (SC), DB Number (DBN), Incomplete Message Flag (IMF), and Segment Descriptors (SD). The MN is a token used to identify and access messages. When a message is received by the system, a Message Number that is unique within the particular node is created and returned to the client application. The Sequence Number is utilized when a message requires more Message Segments (MS) than the maximum number of Segment Descriptors in a single database record. The Segment Counter indicates the number of Message Segments in a message. The DB Number is utilized to associate this message with a particular client application. The Incomplete Message Flag indicates that the message was not fully reconstructed during recovery of the database from the flat file
12
-
2
because of I/O errors. Each Segment Descriptor contains a pointer that contains an address (record number) of a Message Segment in the flat file and a field that indicates the number of bytes in the MS. The structure of the flat file
12
-
2
is based on each message comprising Message Segments stored as a record in the flat file at an address identified by the corresponding SD.
The recovery data (RD) is utilized to provide data integrity and could be used to recover the VIODB
12
-
1
in the event that it was damaged beyond repair such that it could not be recovered by database management algorithms. Moreover, the RD could be used if synchronization between the VIODB
12
-
1
and the voice file
12
-
2
is ever lost. This loss of synchronization could occur if the database VIODB
12
-
1
was not able to be fully recovered to the same point in time as the voice file. The RD comprises the following data items: an Available Marker (AM) indicating whether a MS is in use or available; a Self Pointer (SP) containing the flat file address of the containing MS; a Message Number (MN) that indicates which message the MS belongs to; a Segment Sequence Number (SSN) indicating the order in which the Message Segments were received; a Data Base Number (DBN) indicating which client application owns the MS; a Final Flag (FF) indicating that the MS is the last MS of a message; a Length (L) indicating the number of valid bytes in the MS; a Last Address (LA) pointing to the last MS of a message; and a Checksum used to verify integrity.
An important characteristic of a messaging system is that it be highly reliable and able to quickly recover from system failures. This characteristic is generally referred to as system “availability.” The present invention relates to a messaging system architecture that comprises multiple redundant messaging nodes in order to achieve high availability. In other words, the present invention was developed in the process of designing a messaging system that would continue to provide access to messages stored in one disk file (say, voice file
12
a
) even while its corresponding host (server/NAP
10
a
) is inoperative. A related aspect of the present invention concerns the structure of the voice files. Although the voice file structure described above and depicted in
FIG. 2
permits the messaging system to receive, store and retrieve high volumes of real-time data, it is not suited for use in a shared disk system of the kind employed in accordance with the pres
Hahn Linda K.
Kruesi Frederick C.
Russell Gary P.
Atlass Michael B.
Gauthier Gerald
Starr Mark T.
Tsang Fan
Unisys Corporation
LandOfFree
Multiple node messaging system wherein nodes have shared... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Multiple node messaging system wherein nodes have shared..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Multiple node messaging system wherein nodes have shared... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3019331