WO2001093101A2

WO2001093101A2 - Video messaging system

Info

Publication number: WO2001093101A2
Application number: PCT/US2001/012345
Authority: WO
Inventors: Koh Hee Chang
Original assignee: Moani, Inc.
Priority date: 2000-06-01
Filing date: 2001-04-10
Publication date: 2001-12-06
Also published as: AU2001253548A1; WO2001093101A3

Abstract

A video messaging system (VMS) for providing efficient access to video by users of a plurality of processing systems on a network is provided. The VMS allows an authorized user to associate a video file stored in a server system with content maintained on a remote client system, such as an email message or a hypermedia page, such that another user can view the video file in conjunction with the content. The VMS includes a video streaming server subsystem and a video messaging server subsystem. The video streaming server subsystem archives video files posted to the VMS by users over the network, and streams video files over the network to client computer systems on the network. The video streaming server subsystem includes one or more video file servers for storing the video files and one or more video streaming servers for caching stored video files. The video messaging server subsystem regulates user access to the video files by implementing various security levels. The video messaging subsystem includes components for interpreting user commands, determining the validity of commands based on the security levels, and executing commands determined to be valid, and includes databases of information for use in regulating access to stored video files. The VMS may include a dedicated video mapping server that maps any one or more of multiple user to any one or more of multiple stored video files.

Description

Message Mapping Server

This is a continuation-in-part of U.S. Patent application no. 09/452,288, entitled, "Method and Apparatus for Communication of Video Between Multiple Users on a Network," and filed on November 30, 1999.

FIELD OF THE INVENTION

The present invention pertains to techniques for allowing computer users to communicate messages with each other in a network environment. More particularly, the present invention relates to techniques for allowing multiple computer users to efficiently store, retrieve, and view multiple video files in a network environment.

BACKGROUND OF THE INVENTION

The use of video can be beneficial in many aspects of communications, including applications based on the Internet. The Internet is a well-known communications medium comprising a global network of computers which allows communication of data between remote computer systems. Various applications have been developed which take advantage of the Internet's capabilities, two examples of which are the World Wide Web and electronic mail (email).

Until recently, however, data communications technology was not sufficiently advanced to allow convenient communication of video over computer networks, particularly those subject to substantial and unpredictable delays, such as the Internet. Communication of video and other types of isochronous data requires a large amount of bandwidth. With recent advances in data communication technology, however, network (or internetwork) communication of video has become more feasible. Nonetheless, there is still very little technology which can take advantage of the Internet's potential with respect to video communication. In particular, existing network-based video applications and technologies tend to be unsophisticated and limited in capability.

SUMMARY OF THE INVENTION

The present invention includes a method and apparatus for video messaging. Multiple storage facilities are used to store multiple video files posted by multiple users over a network. A messaging server regulates storage and playback of the video files by the users. A dedicated mapping server responds to the messaging server to map the video files to the users and the storage facilities, such that each of the video files may be mapped to multiple users and multiple storage facilities.

Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

Figure 1 is a block diagram showing a network configuration in which a Video Messaging System (VMS) is implemented;

Figure 2 shows the VMS in greater detail;

Figure 3 shows an example of a computer system that may be used to implement elements of the system of Figure 1;

Figure 4 shows the VSS Subsystem in greater detail;

Figure 5 shows the Video Messaging Server Subsystem (VMSS) in greater detail;

Figure 6 is a block diagram illustrating how multiple security levels can be used to access the VMSS;

Figure 7 illustrates the layout of the session database;

Figure 8 illustrates the layout of the file database; Figure 9 illustrates the layout of the log database;

Figure 10 is a flow diagram illustrating a process for associating a stored video file with content on a remote client system;

Figures 11 and 12 are flow diagrams collectively showing a process for accessing a stored video file.

Figure 13 is a block diagram showing an embodiment of the VMS that includes a mapping server;

Figure 14 is a block diagram of the mapping server;

Figure 15 schematically illustrates a technique for creating a mapping between users, logical filenames, physical filenames, and VFSs;

Figure 16 is a flow diagram showing a process by which the VMS uploads and maps a video message;

Figure 17 is a flow diagram showing a process for copying a video message from one VFS to another VFS;

Figure 18 is a flow diagram showing a process by a which a recipient of a video message can copy and rename a stored video message;

Figure 19 is a flow diagram showing a process for streaming a video message to a user; and

Figure 20 shows the format of an IP address.

DETAILED DESCRIPTION

A method and apparatus for allowing multiple users to communicate video with each other in a network environment are described. As used in this description, the term "video" refers to data that can be used to generate visual output on a conventional computer display device to convey a perception of motion to a user, and the term also includes such visual output. In addition, there may be audio data associated with such data, for generating audible output corresponding to the visual output. Collectively, the data for generating the audible and visual outputs are referred to as "audiovisual" data. In this description, therefore, the term "video" also includes audiovisual data and its corresponding audiovisual output, although any such audio component is optional.

In this description, references to "one embodiment" or "an embodiment" mean that the feature being referred to is included in at least one embodiment of the present invention. Further, separate references to "one embodiment" in this description do not necessarily refer to the same embodiment, however, neither are such embodiments mutually exclusive, unless so stated, and except as will be readily apparent to those skilled in the art.

As will become apparent from the description which follows, the technology described herein allows video messages to be seamlessly integrated into existing text and voice messaging systems and existing Internet/Intranet documents and applications. The described technology provides server-based centralized storage of video messages and allows video messages that are stored in a server to be easily shared by multiple network users, applications, and documents. Note that, henceforth in this description, the term "user" can refer to either a human user or a machine-implemented user, such as a software application or process. The described technology further allows for easy, customizable posting of video messages to the server and provides robust security features for regulating user access to stored video. In addition, the described technology is highly scalable and distributable in terms of processing power, storage space, and geographical location.

As described in greater detail below, the method and apparatus may take the form of a Video Messaging System (VMS) that provides efficient access to video by users of multiple processing systems on a network. The VMS allows an authorized user to easily communicate a video message to another user. In particular, the VMS stores video files and allows a user to associate a stored video file with content maintained on a remote client system on the network, such as an email message or a hypermedia page. Another user, i.e., the intended recipient of a video message, can then view the video file, which he may do in conjunction with viewing or otherwise perceiving that content. Accordingly, the VMS includes a video streaming server subsystem and a video messaging server subsystem, each coupled to a network. The video streaming server subsystem archives video files posted to the VMS by users over the network, and streams video files over the network to client computer systems on the network, in response to authorized requests from users of the client computer systems. The video messaging server subsystem regulates user access to the video files and implements various different security levels for regulating such access.

Refer now to Figure 1, which illustrates a network configuration in which the VMS is implemented. As shown, the network configuration includes the VMS 1, which is connected to a network 2. In one embodiment, the network 2 is an Internet Protocol (IP) based internetwork, such as the Internet. In other embodiments, however, the network 2 may be an intranet, a local area network (LAN), a wide area network (WAN), or any other type of computer network or internetwork. Portions of the network 2 may be wireless, as in the case of a satellite based or cellular network. Also coupled to the network 2 are one or more client computer systems 3 and one or more Video Application Server (VAS) Subsystems 4. Each client system 3 executes a web browser 7, which is software for enabling the client systems 3 to access hypermedia (e.g., hypertext) documents. The web browser 7 may be, for example, Netscape browser or Microsoft Internet Explorer. The web browser 7 includes a Client Messaging Plug-in (CMP) 8, a Client Encoder Plug-in (CEP) 9, and a Client Display Plug-in (CDP) 10. Coupled to each client system 3 are video input devices 5 and video output devices 6.

The VMS 1 is a cluster of servers, namely a VMS Subsystem 11 and a Video Streaming Server (VSS) Subsystem 12, and a set of communication and mapping protocols that facilitate the movements of video messaging over the network environment. These servers may be located at one central location, or they may be geographically distributed. The VMS Subsystem 11 is a set of servers that define and execute the basic communication and mapping protocols in the VMS System. The VMS Subsystem 11 manages and stores all information regarding usage of the VMS 1, as described further below. The VSS Subsystem 12 is a set of servers that enable and control efficient storage and streaming of video messages in the VMS 1. These subsystems are described further below. Note that because playback of a video file normally is done by streaming the video file to a client system 3 (as opposed to, for example, sending the video as an attachment), it is relatively difficult for the recipient to save the video file in his local client system. This feature, therefore, permits a high degree of control over access to video files to be implemented at the VMS 1.

A VAS Subsystem 4 can be any application server on the Internet/Intranet that employs the services provided by the VMS 1. For example, a VAS Subsystem 4 may be an electronic mail (email) server or a World Wide Web server. In the former case, users can access the VMS 1 to associate video messages with email communications managed by the email server (the VAS 4). In the latter case, in which a VAS 4 is a Web site, the user can associate a video message with a Web page or other Web based content. For example, an on-line auction Web site might wish to use video clips stored in the VMS 1 to describe or promote products that are being auctioned. Other examples of a VAS 4 are an instant messaging server, a bulletin board server, a video greeting card server, or a telephone gateway server. Of course, other types of VAS 4 are possible, as are other modes of use for the video messages stored in the VMS 1.

A client computer system 3 may be any processing system that a user uses to access the Internet/Intranet, and to post and retrieve video messages to and from the VMS 1. For example, a client system 3 may be a personal computer (PC), a workstation, a hand-held processing device, such as a personal digital assistant (PDA), personal information manager (PIM), or the like, or a cellular telephone or other type of communication device. The video input devices 5 are conventional audio and video input files and devices, such as a video camera and microphone. Similarly, the video output devices 6 are conventional audio and video output files and devices, such as a display device and audio speaker.

In the process of downloading video from the VMS 1, the CMP 8 receives the video data from the VSS Subsystem 12 and transfers it to the CDP 10. The CDP 10 is a plug-in for the web browser 7, which communicates with the VSS Subsystem 12 through the CMP 8, to provide reliable streaming of video messaging from the VSS Subsystem 12 to the client system 3. The CDP 10 is an audio-video decoder that decodes a received video message and presents it to the audio-video output devices 6 that are connected to the client system 3.

The CEP 9 is a plug-in for the web browser 7 that communicates with the VSS Subsystem 12 via the CMP 8. The CEP 9 interfaces with the audio-video input files and devices 5 and encodes an input video message. The CEP 9 is an audio-video encoder that compresses the audio and video information input at the client system 3 for compact storage. In one embodiment, the CEP 9 uses the Share Video- Audio (SVA) format for encoding and compression. The compressed video message is then uploaded into the VSS Subsystem 12 for storage.

The system of Figure 1 uses two special-purpose protocols, namely, a VMS Application Interface Protocol (VAIP) and a Video Mapping Interface Protocol (VMIP). The VAIP is a communication/messaging protocol that facilitates the access of user /account information with the VMS Subsystem 11. The VAIP protocol also provides the interfaces for third-party application developers to incorporate VMS System services to their applications. . The VAIP protocol is used to prepare the VSS Subsystem 12 to stream a file from the VSS Subsystem 12 to a client system 3.

The VMIP is a protocol that facilitates the streaming of video messages from the VSS Subsystem 12. The VMIP also allows for mapping of logical filenames to physical filenames. The features of these protocols are described further below. As shown in Figure 1, the VAIP is implemented between the VMS Subsystem 11 and the IP network 2 and between the IP network 2 and the client systems 3. The VMIP is implemented between the VMS Subsystem 11 and the IP network 2, between the VSS Subsystem 12 and the IP network 2, and between the IP network 2 and the client systems 3. The CMP 8 is a plug-in for the web browser 7 that allows the web browser 7 to communicate with the VMS 1. The CMP 8 acts as a socket that enables reliable communication between the client system 3 and the VMS 1 using the VAIP and VMIP protocols. The CMP 8 communicates with the VMS Subsystem 11 via the VAIP protocol to authenticate the client for access to the VMS 1.. The CMP 8 also facilitates the access to the user's information in the VMS 1 via the VAIP protocol to the VMS Subsystem 12. In addition, the CMP 8 communicates with the VSS Subsystem 12 via the VMIP protocol to stream data from the VSS Subsystem 12 to the client system 3. During the process of uploading data from a client system 3 to the VMS 1, the CMP 8 receives the data from the CEP 9 and transfers it to the VSS Subsystem 12.

Figure 2 illustrates the architecture of the VMS 1 in greater detail, according to one embodiment. As shown, the VMS Subsystem 11 includes one or more Private VMS Application Servers (PVAS) 21 and one or more Video Messaging Server Subsystems (VMSS) 22, which are coupled to each other and to the IP network 2. The VSS Subsystem 12 includes one or more Video File Server (VFS) 23 and one or more Video Streaming Server (VSS) 24, which are coupled to each other. The VSS 24 is also coupled to the IP network 2. The VMS Subsystem 11 manages and stores all information regarding usage of the VMS 1, as described further below. The VMSS 22 stores all information related to the access of video messages stored in the VSS Subsystem 12. The VMSS 22 maintains the security of the whole VMS 1, facilitates and enables the storage of the video data to the physical storage in the VSS Subsystem 12, and facilitates user access to stored video. The VMSS 22 controls downloading of videos to authorized users based on a key referred to as the VMS key. The VMSS 22 and the VMS key are described further below.

A PVAS 21 is an application server that provides services in addition to the real-time video streaming operation of the VMS 1. These services might include, for example, accounting, new user authentication, backup services, user logging, etc. These servers generally have a relatively high security access to the rest of the VMS 1.

The VSS Subsystem 12 stores all video messages and provides the strearning of the video messages to client systems 3. The VSS Subsystem 12 includes the VFS 23 and the VSS 24. Video files are physically stored in the VFS 23, which has very high data storage capacity. The VSS 24 caches the video data from the VFS 23 and streams the video data to the CDP 10 in the client systems 3. Downloading of files is performed using a key referred to as the VSS key, as discussed further below.

Each of the servers and/or subsystems mentioned above (e.g., client system 3, VAS Subsystem 4, PVAS 21, VMSS 22, VFS 23, or VSS 24) may be implemented in a conventional computer system, such as a PC, a workstation, or the like. In addition, these components may each be implemented in separate computer systems, which may be geographically distributed. Alternatively, any two or more of the above-mentioned components may be implemented in the same computer system. Figure 3 is a high-level block diagram showing an example of the architecture of such a computer system that may be used to implement any of the above-mentioned components. The illustrated computer system includes a central processing unit (CPU) 31, read-only memory (ROM) 32, and random access memory (RAM) 33, each connected to a bus system 42. The bus system 42 may include one or more buses connected to each other through various bridges, controllers and /or adapters, such as are well-known in the art. For example, the bus system 42 may include a "system bus" that is connected through an adapter to one or more expansion buses, such as a Peripheral Component Interconnect (PCI) bus. Also coupled to the bus system 42 are a mass storage device 34, a keyboard 35, a pointing device 36, a display device 37, an audio speaker 38, a video camera 39, a microphone 40, and a data communication device 41. Of course, various ones of these components may be omitted, or supplemented with additional components, as appropriate for the application. For example, it may not be necessary or desirable to include components such as a video camera or microphone in the server subsystems of the VMS 1.

The pointing device 36 may be any suitable device for enabling a user to position a cursor or pointer on the display device 37, such as a mouse, trackball, touchpad, speech recognition interface, or the like. The display device 37 may be any suitable device for displaying alphanumeric, graphical and /or video data to a user, such as a cathode ray tube (CRT), a liquid crystal display (LCD), or the like, and associated controllers. Mass storage device 34 may include any suitable device for storing large volumes of data in a nonvolatile manner, such as a magnetic disk or tape, magneto-optical (MO) storage device, or any variation of Digital Versatile Disk (DVD) or compact disk (CD) storage. The communication device 41 may be any device suitable for or enabling the computer system to communicate data with another computer system over a data communication link 43, such as a conventional telephone modem, a cable modem, an Integrated Services Digital Network (ISDN) adapter, a Digital Subscriber Line (xDSL) adapter, an Ethernet adapter, or the like.

The VSS Subsystem 12 is described further now with reference to Figure 4. As shown, the VSS Subsystem 12 may include one or more VFS 23 connected to one or more VSS 24. In the illustrated embodiment, a number N of VFS 23 are connected to a number M of VSS 24 via network switches 40, using the Network File System (NFS) protocol. In such an embodiment, the numbers N and M are not necessarily equal. This configuration allows high scalability of the VSS Subsystem 12. For example, the addition of more VFS 23 provides for more storage of video files. Similarly, the addition of more VSS 24 provides higher bandwidth for purposes of uploading and downloading video files. Likewise, it will also be noted that the VMS 1 is further scalable by adding additional PVAS 21 and/or VMSS 22 to provide for a greater number of users. As noted, because playback of a video file normally is done by streaming the video file to a client system 3 (as opposed to sending the video as an attachment, for example), it is relatively difficult for the recipient to save the video file in his local client system. This feature, therefore, permits a high degree of control over access to video files to be implemented at the VMS 1.

As noted above, the VAIP defines the control and management protocols of the VMS 1 and facilitates the management of the VMS 1. In the VMS 1, the VAIP protocol is decoded by the PVAS 21 and the VMSS 22. The commands in the VAIP are divided into four classes, based on four levels of security access, i.e., security levels one through four. Security level one access has the highest protection, and is for commands between the internal machines of the VMS 1 only. Security level one commands are defined such that the breach of such a command may result in a severe impact on the system. Security level two accesses are read/write accesses allowing a registered user to read/write from/ to his account. Security level three accesses are read-only accesses allowing a VAS Subsystem 4 (see Figure 1) to pull information from the VMS 1 to its application. Security level four accesses have the lowest protection and are the only accesses to the VMS 1 that require no password. Security level four accesses allow a user to access a video message in the VMS 1 through a VMS token.

The security level one commands used in the VAIP are Add User and Delete User. Add User adds a new user account to the VMS 1, and Delete User deletes an existing user account in the VMS 1.

The VAIP security level two commands include the following: Log In User Session, Log Out User Session, Change Password User Session, Change EMail User Session, Get User Information, Add / Upload File, Rename File, Add Image Descriptor, Add Text Descriptor, Delete File, Get Dir Info User Session, Get Image Descriptor User Session, Get Text Descriptor User Session, Get Image Descriptor User Session, Play File User Session, Get VMS Key User Session, and No Operation.

Log In User Session allows the user to log into the VMS 1; this command must be executed successfully prior to any other security level two commands. Log Out User Session allows the user to close the current session. Change Password User Session allows the user to change his password. Change EMail User Session allows the user to change his email address associated with his VMS account. Get User Information returns the user information associated with the VMS system account. Change User Information allows the user to change the information associated with his VMS account. Add / Upload File allows a user to add and upload a new video messages to the VMS 1. Rename File allows a user to change the filename of a video message stored in the VFS 23. Add Image Descriptor allows a user to upload an image file that may be used to describe a video message. Add Text Descriptor allows a user to upload a text file that may be used to describe a video message. Delete File allows a user to delete a video messages from the VMSS 22. Note that when a Delete File command is issued, the file may not be deleted physically in the VFS 23, such as if that file is used by another user; thus Delete File is only for logically deleting a file. Get Dir Info User Session allows a user to receive his directory information. Get Image Descriptor User Session uploads an image file that describes a video message requested by the user. Get Text Descriptor User Session uploads a text file that describes the video messages requested by the user. Play File User Session allows a user to play back a selected video message. Get VMS Key User Session allows a user to get a VMS key to play a video message; the VMS key is described further below. No Operation performs no action but can be used to extend the user session from timeout.

The VAIP security level three commands include the following: Log In VAS Session, Log Out VAS Session, Get Dir Info VAS Session, Get Image Descriptor VAS Session, Get Text Descriptor VAS Session, Play File VAS Session, Get VMS Key VAS Session, Authenticate User, and No Operation. Log In VAS Session allows an application server to log in to a read-only session. Log Out VAS Session allows an application server to log out of a read-only session. Get Dir Info VAS Session allows an application server to receive the directory information of a particular user. Get Image Descriptor VAS Session uploads an image file that describes a video message requested by a VAS 4. Get Text Descriptor VAS Session uploads a text file that describes a video message requested by a VAS 4. Play File VAS Session allows a VAS 4 to play back a selected video message. Get VMS Key VAS Session allows a VAS 4 to get a VMS key to play back the video messages. Authenticate User allows a VAS 4 to get the VMS system user identifier (ID) of a user through the user's email address. No Operation performs no action but can be used to extend a VAS session from timeout.

The VAIP security level four commands include Play File via VMS key, which allows a video message to be played back by the user.

Two types of keys are used when a user of the VMS 1 wishes to send a video clip to another user, i.e., the VMS key and the VSS key. The VMS key identifies a video message stored in the VMS 1 and includes authentication codes to play back the video message. When a user accesses the VMS 1 and selects a video message to be associated with content, such as in email message or Web page, the VMS 1 provides a VMS key to be incorporated into, or otherwise associated with, that content. More specifically, in one embodiment the VMS 1 appends the VMS key to a Uniform Resource Locator (URL) that references the VMS Subsystem 11. In one embodiment, the VMS key is a concatenation of five character strings, as follows: [Sender ID] [Sender Application ID] [Logical file name] [Timestamp] [Token check sum]. Sender ID identifies the sender of the message. Sender Application ID is either the IP address of the application server accessing the VMS 1 or the ID of a plug-in accessing the VMS 1. Logical filename is the logical filename of the video message. Timestamp may be an expiration time for the video message, or it may be the current time, which may be used by the VMSS 22 to determine whether authorization for the video message has expired. The token checksum is, in one embodiment, a 32-byte checksum generated using Sender ID, Sender's Application ID, Logical file name, Timestamp, and a 1024-bit VMS private key. The 1024-bit VMS private key, which is not to be confused with the "VMS key", is a private key code that is stored internally in the VMS 1 and is known to both the encoder and the decoder in the VMS 1. This private key is used for additional security to prevent an unauthorized party from generating the VMS key himself. Thus, the VMS key is used to authorize a user's access to a stored video file that has been previously associated with content (e.g., in email message) by another user through the VMS 1.

When access to the video message has been authorized based on the VMS key, the VMSS 22 sends another key, the VSS key, to the intended recipient of the video message. The VSS key is used by the message recipient to access the stored video file in the VFS 23. Accordingly, the VSS key includes the physical filename of the video message and a timestamp. The timestamp may be the current time or an expiration time. The physical filename is transparent to the user.

Consider a simple example in which one User, User 1, wishes to use the VMS 1 to send a video clip to another user, User 2. Accordingly, the following operations are performed: Initially, User 1 logs into his account in the VMS 1 from his client computer, using his user name and password. User 1 then selects a video clip that he wishes to send. The video clip may be a video clip which User 1 has previously uploaded to the VMS 1, or it may be a video clip stored by another user, or it may be a "prepackaged" or "canned" video clip provided by the VMS operators for used by some or all users. Such prepackaged video clips may be provided for various different occasions (themes), such as birthdays, anniversaries, holidays, and other significant events. Upon selecting a stored video clip, User 1 receives a VMS key for the video message, which is in response to transmission of the command Get VMS Key User Session by the CMP 8 of User 1. The VMS key may then be included by User 1 (or an application used by User 1) in any content, such as email message. User 1 then sends to User 2, in the case of an email message, the URL of the VMS server with the VMS key appended to it. User 2 then accesses the URL with the appended VMS key, and his client system receives the appropriate VSS key from the VMS 1 in response. The client system of User 2 then sends the VSS key back to the VMS 1, and in response, the VSS 24 streams the video message to the client system of User 2, where the video is played to User 2.

As a variation of the above example, User 1 may wish to associate a stored video file with a Web page (or other network-based content) that User 1 expects to be accessed by User 2. Accordingly, to do this User 1 can incorporate the URL provided by the VMSS 22, with the appended VMS key, into a hypertext document or other content, for subsequent access by User 2.

The VMIP defines the communication protocols within the VMS 1, to facilitate the playback and storage of video message. Unlike the VAIP, the VMIP is transparent to the user. It is a private communication protocol between the CMP 8, the VMSS 22, and the VSS 24. Commands in the VAIP that involve the uploading and downloading of video messages trigger a series of VMIP commands to complete the VAIP command.

In the VMS 1, the VAIP can be decoded by either the VMS Subsystem 11 or the VSS Subsystem 12. The VMS Subsystem 11 authenticates the user, and the VSS Subsystem 12 streams the video messages to the client system 3. In the VMS 1, the video messages are stored physically in the VFS 23. The files are identified by physical filenames that are transparent to the user. The VMSS 22 maps the physical filenames to logical filenames determined by the user. This mapping allows a single physical file to be owned by multiple users, yet each user can name the file differently. The deployment of the VMS 1 does not require the VMS Subsystem 11 and the VSS Subsystem 12 to be in the same location. Thus, all communications between the VMS Subsystem 11 and the VSS Subsystem 12 are encrypted with a time-sensitive encryption key.

The commands of the VMIP are as follows: Open a File for Playback, Packet Authentication, Get New Physical Filename for Uploading, Get File Size, Send a Packet of Data for Playback, Receive a Packet of Data for Upload, Send Multiple Packets of Data for Playback, Receive Multiple Packets of Data for Upload, and Return Streaming Information to VMS. Open a File for Playback is a command from the VMS Subsystem 11 to the VSS Subsystem 12 which prepares a file for playback. After a file has been opened for playback, the CMP 8 can send a packet authentication code to the VSS Subsystem 12 to initiate the playback of the video messages. A timeout is implemented for this command, such that a packet authentication code is only valid for a limited period of time. This timeout reduces the risk of unauthorized access to data stored in the VSS Subsystem 12.

Packet Authentication is a command from the CMP 8 to the VSS Subsystem 12. When a client system requests playback of a file from the VMS 1, the CMP 8 receives a packet authentication code together with the physical file name and sends this information to the appropriate VSS Subsystem 12 to stream the file.

Get New Physical Filename for Uploading is a command from the VMS Subsystem 11 to the VSS Subsystem 12. When a user requests uploading of a file to the VMS 1, a physical filename must be requested from the VSS Subsystem 12. The VMSS 22 maps the user's logical filename to the VSS Subsystem 12 and its physical filename for future access to the file.

Get File Size is a command from the CMP 8 to the VSS Subsystem 12. The CMP 8 sends the Get File Size command to the VSS Subsystem 12 to request the file size of a file that is to be downloaded from the VMS 1.

Send a Packet of Data for Playback is a command from the CMP 8 to the VSS Subsystem 12. This command is used by the CMP 8 to request a packet of data in a file that is to be played back. Multiple packets may be requested by the CMP 8 to improve the performance of video streaming.

Receive a Packet of Data for Upload is a command from the CMP 8 to the VSS Subsystem 12. This command is used by the CMP 8 to upload a packet of data to a file in the VSS Subsystem 12. Multiple packets may be uploaded to increase the speed of the upload process.

Send Multiple Packets of Data for Playback is a command from the CMP 8 to the VSS Subsystem 12. This command is used by the CMP 8 to request multiple packets of Data in a file to be played back.

Receive Multiple Packets of Data for Upload is a command from the CMP 8 to the VSS Subsystem 12. This command is used by the CMP 8 to upload multiple packets of data to a file in the VSS Subsystem 12.

Return Streaming Information to VMS is a command from the VMS Subsystem 11 to the VSS Subsystem 12. After a file has been uploaded or downloaded, the VMS Subsystem 11 may use this command to query streaming information during the upload and download processes.

The VMS Subsystem 11 will now be described in greater detail. In one embodiment, the VMSS 22 is a computer system which uses conventional operating system software, such as Linux or a version of Microsoft Windows operating system. VMS server code "sits on top of" (logically) the operating system. The VMS server code may be written in, for example, the C programming language, with a Transfer Control Protocol /Internet Protocol (TCP/IP) socket connection to the VAIP, the PVAS 21, and the VMIP

Refer now to Figure 5, which shows the internal architecture of the VMSS 22, according to one embodiment. As shown, the VMSS 22 includes a VAIP Interface 51, a command interpreter 52, a security controller 53, a command executor 54, a PVAS database Interface 55, a cluster map database 56, a transaction controller 57, a session database 58, a file database 59, a user database 60, a log database 61, and a mapping database 62. All commands to the VMSS 22 are initiated through the VAIP Interface 51. The command interpreter 52 interprets the commands, and the command executor 54 executes the commands that are valid, using information from its internal databases 56 and 58-62, or information in a PVAS 21 (see Figure 1). VAIP commands that involve the streaming of data from the VMS Subsystem 12 result in additional commands being initiated at the VMIP interface implemented at the output of command executor 54, to complete each VAIP command.

All sessions in the VMSS 22 are initiated by commands in the VAIP. The VAIP Interface 51 packetizes all VAIP commands and starts a thread for each command. The commands are interpreted by the command interpreter 52 and then checked by the security controller 53 to determine whether permission to perform the command is valid. If the command is valid, the command executor 54 then executes the command.

Commands in the VAIP may have any of various different forms. For commands which require directory information , the command executor 54 obtains the directory information from the transaction controller 57, which has access to databases 56 and 58-62. In the VMSS 22, multiple sessions of the command executor 54 may be active at the same instant. Thus, multiple VMS sessions may access (read from and write to) a database, causing a chain of database commands from a VMS thread to be broken up. Therefore, the transaction controller 57 is used to maintain the directory database in the local machine and to ensure data integrity in the VMSS databases. In the VMSS 22, only one transaction controller 57 can be active, and this prevents a chain of database accesses from a VMS thread from being broken up.

VMSS connectivity and security access will now be further described. Figure 6 illustrates how external machines may connect to the VMSS 22. Four different types of user may connect to the VMSS 22 using the VAIP, each with different security access. Registered users access the VMSS 22 at security level two. A PVAS 21 accesses the VMSS 22 at security level one, the highest security level. A VAS 4 may access the VMSS 22 at security level three, or a VAS 4 may also execute a security level two command indirectly through a registered user who is logged-in (i.e., using that user's user name and password). All other users access the VMSS 22 at security level four. Users at security levels one, two and three are required to log into the VMSS 22. Their logged sessions are stored in the session database 58. When a user sends in another command, the security controller 53 checks the user's session logged in the session database 58, allowing the user to execute only the appropriate commands.

The session database 58 will now be further described. The VMSS 22 monitors the VAIP port and initiates a new thread for each received VAIP command. The thread ends upon completion of the command. In such an implementation, all commands' threads are required to be linked into a continuous user session. This operation is performed by the session database 58. This is true for all accesses in security levels one through three. Security level four accesses are all single-command accesses, and thus, no session database entry is needed for such accesses.

When a user logs into the VMSS 22, a new session identifier (ID) is allocated, and a new session database entry is created. The session ID is used to identify all subsequent accesses to the VMSS 22. The session is destroyed when a user logs out or when the session is timed-out.

Figure 7 illustrates the layout of the session database 58, according to one embodiment. In the illustrated example, N+l sessions are available in the VMSS 22. Each entry 71 in the session database 58 identifies a logged-in session, and each entry 71 is identified uniquely by its session ID. There are five fields in each session database entry 71, namely, User ID, Login Time, Last Access Time, User's IP Address, and Security Level Access. User ID allows the VMSS 22 to map the session to the user. This also prevent the user from accessing other users' information, because only one user's database may be accessed per session. Log-in Time is for keeping track of the duration of the session. Last Access Time records the time a command was last received from the user. This field is used to automatically log out a user when the user is inactive for a predetermine time period. User's IP Address is used for comparison to the IP address of a command source. A command can only be validated if the current IP address is the same as the logged-in IP address. This is to prevent other computer users from masquerading as an authorized user. The Security Level field is used to determine whether a command sent by the user corresponds to the correct security level.

Figure 8 shows the layout of the file database 59, according to one embodiment. The file database 59 stores information regarding the video messages stored in the VSS Subsystem 12. Space is allocated in the file database 59 for each user, in which all his file information is stored. This space for each user is identified in the cluster map database 56. The user database 60, log database 61, and the mapping database 62 are also stored in the same location. The file database 59 is used when a user wishes to see the information regarding video messages that he owns in the VMS 1. The file database 59 is also updated when a user successfully uploads a video message or changes the filename or description of one of his video messages.

As shown in Figure 8, each user has an entry location to his database location. The directory tree is created at the roots, identifying the various clusters that a user creates to segment his video messages entries 81. Each cluster can have multiple file entries 81, with each entry 81 identifying a video message. In particular, each entry 81 includes fields for the file prefix, file name, file size, modified date, file attributes, file description, text descriptor, image descriptor, and a pointer to the mapping database 62. The pointer to the mapping database 62 points to a location in the mapping database 62 that identifies the physical location(s) of the corresponding video message. Note that the roots of the user entry also points to the user database 60 and the log database 61.

The user database 60 stores the log-in information of the user and is used to authenticate a log-in command. According to one embodiment, the fields in the user database 60 include the user's email address, security level two password, security level three password, and maximum security level. The email address is used as a cross-check against the user database 60. The security level two password is provided by the registered user and is used to access security level two commands. The security level three password is provided by the VMS 1 and is used by other VAS 4 to access security level three commands. The maximum security level may be set to limit a user's access to the VMS 1.

Figure 9 shows the layout of the log database 61, according to one embodiment. The log database 61 stores the log information of the file access from a user's file storage. The log database 61 is used by a PVAS 21 for accounting and other site management purposes. As shown, each entry 91 in the log database 61 includes a cluster name, file prefix, file name, VSS name, physical filename, access time, and access type.

The mapping database 62 maps a video message entry in the file database 59 to a physical location in the VSS Subsystem 12. According to one embodiment, the fields in each entry of the mapping database 62 include a cluster name, directory name, filename, VSS name, physical filename, and number of instances. The VSS name represents the name of the particular VSS machine in which the file is stored. The number of instances represents the number of logical files corresponding to a given physical file.

Figures 10 through 12 collectively illustrate a process for communicating a video message from one user of the VMS 1 to another user, according to one embodiment. Figure 10 illustrates a process for allowing a sender user to associate a video file stored in the VSS Subsystem 12 with content on the network, while Figures 11 and 12 collectively show a process for providing the video file to the intended recipient. Referring to Figure 10, when an authorized user accesses the VMS 1 for purposes of sending a video message to another user, at 1001 the VMSS 22 receives inputs from the sending user selecting a video file stored in the VSS Subsystem 12. At 1002, the VMSS 22 generates a VMS key corresponding to the selected video file. At 1003, the VMSS 22 appends the logical filename of the selected file, the timestamp, and the VMS key to a URL of the VMS Subsystem 11, and then sends the URL to the client system 3 of the sending user. The sending user can then provide the URL to the recipient user in an email message, a Web page, or with other content.

When the recipient user wishes to access the video message, he selects a hypermedia link corresponding to the URL provided by the sending user. Referring to Figure 11, therefore, at 1101 the VMSS 22 receives inputs representing the recipient user's selection of the hypermedia link. At 1102, the VMSS 22 determines whether access to the specified video file is permitted, such as by examination of the timestamp and/or other parameters. If access is permitted, then at 1103 the VMSS 22 sends a VSS key corresponding to the specified file to the client system of the recipient user. If access is not permitted, then at 1104 the VMSS 22 transmits an access denial message to the client system of the recipient user. Assuming access is permitted, then when the client system of the recipient user receives the VSS key, the CMP 8 of that client system transmits the VSS key back to the VMS 1. This act initiates the process shown in Figure 12.

At 1201, the VSS Subsystem 12 receives the VSS key returned by the client system of the recipient user. At 1202, the VSS Subsystem 12 determines whether the VSS key is valid, based on the timestamp in the VSS key and /or other parameters. If the VSS key is valid, then at 1203 the VSS 24 streams the specified video file to the client system of the recipient user. If the VSS key is not valid, then at 1204 an access denial message is transmitted to the client system of the recipient user.

As noted above, in one embodiment the file database 59 (Figure 5) stores, for each user, the video files to which that user has access. The mapping database 62 contains information which specifies the one or more VFSs 23 in which each video file is stored. In the embodiments described above, each of these two databases is maintained by the VMSS 22.

Figure 13 illustrates an alternative embodiment of the VMS 1, which includes an independent, dedicated mapping server 131. The mapping server 131 is separate from, but functionally coupled to, the VMSS 22. The main purpose of the mapping server 131 is to efficiently manage the sharing of video messages between users. As noted, each video message stored in the VMS 1 may be "owned by" (able to be manipulated by) multiple users, each of whom may assign a different logical filename to the same video message. Also as noted above, video messages may be stored in geographically distributed locations within the VMS 1, and multiple copies of a video message may be stored within different VFSs 23. Accordingly, the mapping server 131 also efficiently manages the streaming of video messages to users.

Each user assigns a logical filename to identify each of his video messages., and each physical copy of a video message has a different physical filename. The mapping server 131 links together the one or more logical filenames and the one or more physical filenames of each video message using a mapping identifier (ID). By allowing multiple logical filenames to be mapped to a single mapping ID, the mapping server 131 permits each user to independently access and manipulate his own logical files. Furthermore, the addition of physical copies of a video message can be accomplished without having to update the file database 59; this is in contrast with the embodiment described above, which does not use a dedicated mapping server. Other tasks of the mapping server 131 include maintaining knowledge of the ownership of each video message and deleting physical copies that no longer have an "owner"; maintaining knowledge of the duplication of video messages (which, again, is independent of the file database 59); and determining the preferred VFS 23 for downloading of video messages (i.e., when copies of a requested video message are stored on multiple VFSs).

Figure 14 shows the mapping server 131, according to one embodiment. The mapping server 131 includes a mapping engine 141 and a mapping database 142. The mapping database 142 stores the associations (mappings) between users, physical filenames, mapping IDs, and VFSs. The mapping engine 141 responds to commands from the VMSS 22 to maintain and update the mapping database 142 and to return mapping information, such as mapping IDs, to the VMSS 22. The mapping database 142 in the mapping server 131 may replace the mapping database 62 in the VMSS 22 (Figure 5) in the previously described embodiment. Note that because the mapping database 142 does not contain (and does not need to contain) the logical filenames of the stored video messages, modifications to the mapping database 142 require no modifications to the file database 59, in contrast with the previously described embodiment which has no dedicated mapping server.

Figure 15 further illustrates the mapping technique employed by the mapping server 131. In particular, Figure 15 shows the mapping for a single video message owned by multiple users and represented by multiple physical copies stored on multiple VFSs 23. Of course, this mapping technique can be used further to map multiple video messages. As noted, the VMSS 11 maintains a file database 59, which includes an entry 81 (as described above; see Figure 8) for each of N users (N > 1) who are authorized to access the video message. Each entry 81 includes the logical filename assigned by the corresponding user to the video message. Associated with each logical filename within each entry 81 is the mapping ID of the video message. Mapping IDs are assigned by the mapping server 131. Because of the association of logical filenames to mapping IDs within the file database 59, each user owning the video message may assign a different logical filename to the video message. As noted above, each entry 81 in the file database 59 includes a pointer to the mapping database 62. In embodiments which employ the mapping server 131, this pointer may be the mapping ID of the video message.

The VSS Subsystem 12 includes M VFSs 23 (M > 1), each of which stores at least one physical copy 155 of the video message. Accordingly, the mapping server 131 includes an entry 153, within mapping database 142, for the video message. The database entry 153 includes the mapping ID of the video message, which is used as the basis for relating logical filenames to physical filenames. The database entry 153 also includes, in association with the mapping ID, a user ID for each of the N users who own the video message and the M physical filenames of the M physical copies 155 of the video message.

Figure 16 shows a process by which the VMS 1 may upload and map a video message, using the mapping server 131. At 1601, the VMSS 22 receives a command from a client system 32 to upload a video message created by a user. This communication may be accomplished in the manner described above. At 1602, the VMSS 22 selects a VFS 23 to store the video message. At 1603, the VMSS 22 requests and receives a new physical filename from the selected VFS 23. At least part of the physical filename may be an identifier of the selected VFS 23, so that the VMSS 22 can identify on which VFS a video message is stored, based on the physical filename. Next, at 1604 the VMSS 22 requests and receives a new mapping ID from the mapping server 131. The new mapping ID is generated by the mapping engine 141 of the mapping server 131. At 1605, the VMSS 22 requests a client system 3 to upload the video message to the selected VFS 23 using the new physical filename, and the client system 3 uploads the video message at 1606 to the designated VFS 23. At 1607, the user inputs a logical filename for the video message at the client system 3, and the client system 3 then sends the logical filename to the VMSS 22. At 1608, the VMSS 22 creates an entry for the user in the file database 59 (or updates the entry, if an entry for the user already exists), associating the logical filename with the assigned mapping ID and the user ID of that user. Next, at 1609 the VMSS 22 requests the mapping server 131 to create an entry in the mapping database 142 to associate the assigned physical filename and the user's user ID with the mapping ID. At 1610, the mapping server 131 creates the requested database entry.

Once the video message is uploaded, it may be desirable to store one or more copies of the video message on separate, geographically distributed VFS 23. The decision whether to do so is generally made by the VMSS 22. One reason storing multiple, geographically distributed copies may be desirable is for redundancy, i.e., for protection against loss of data at a particular VFS 23. Another reason is that when users are distributed over a wide geographic area, the download process may be faster when a files to be downloaded is relatively close to the requesting user. Hence, Figure 17 shows a process for copying and uploaded video message from one VFS 23 to another.

At 1701, the VMSS 22 selects a VFS 23 to store a new copy of a previously- uploaded video message. At 1702, the VMSS 22 requests and receives a new physical filename from the selected VFS 23. At 1703, the VMSS 22 requests the selected VFS 23 to copy the uploaded video message from the VFS on which the message is currently stored to the selected VFS. Next, at 1704 the selected VFS 23 copies the video message and responds to the VMSS 22 with a "copy complete" signal. At 1705, the VMSS 22 requests the mapping server 131 to modify the entry in mapping database 142 to map the new physical filenames to the mapping ID of the video message. Prior to 1705, the mapping idea was already associated with at least one physical filename and at least one user ID. At 1706, the mapping server 131 performs the requested modification.

Suppose now that a first user sends a video message to another user in the manner described above. Suppose further that the recipient user wishes to create his own copy of the video message with a logical filename of his own choosing. Figure 18 shows a process by which this may be accomplished. At 1801, the sending user sends the video message to the recipient user. At 1802, the recipient user views the video message. At 1803, the recipient user then sends a copy command from his client system 3 to the VMSS 22, renaming the video message with a new logical filename. The VMSS 22 receives the copy command 1804, and at 1805, the VMSS 22 creates an entry in the file database 59 for the recipient user (or updates the entry for that user, if one already exists) in order to add the new logical filename in association with the mapping ID of the video message. At 1806, the VMSS 22 requests the mapping server 131 to modify the entry in the mapping database 142 for the video message in order to associate the user ID of the recipient user with the mapping ID of the video message. At 1807, the mapping server 131 performs the requested modification.

One function of the mapping server 131 is to manage the efficient streaming of video messages stored in the VMS 1 to users. As noted above, there may be multiple copies of a particular video message stored on separate, geographically distributed VFSs 23. To facilitate description, the term "VSS cluster" is now defined to mean one VFS 23 with one associated VSS 24. Hence, the VSS Subsystem 12 may include multiple VSS clusters. Note, however, that one VSS 24 may support multiple VFSs 23, and similarly, one VFS 23 may be supported by multiple VSSs 24. Hence, a particular VFS 23 or VSS 24 may be a member of more than one VSS cluster.

The mapping server 131 manages the streaming of video messages by selecting particular VSS clusters to download each video message requested for playback, based on the location of the requesting user. In general, the mapping server 131 selects the VSS cluster that is physically closest to the requesting user or otherwise able to provide the fastest download (e.g., in view of current network loading). Figure 19 is a flow diagram showing a process for streaming a video message to a user in response to a user request to playback the video message.

At 1901, the VMSS 22 receives a request to playback the video message. At 1902, the VMSS forwards the user's IP address to the mapping server 131. At 1903, the mapping server 131 identifies the one or more VSS clusters that contain a physical copy of the requested video message. Next, at 1904, the mapping server 131 determines whether more than one VSS cluster contains a copy of the requested video message. If not, the process continues from 1906, as described below. If more than one VSS cluster contains the requested video message, then at 1905 the mapping server 131 uses the user's IP address to select the best VSS cluster to stream the video message to the user.

Figure 20 schematically shows the format of an IP address. As shown, the IP address 200 includes four fields, 201, 202, 203, and 204, which are the Class A, Class B, Class C, and user-specific fields, respectively, of the IP address 200. As is well-known, each field specifies a range of users, adding precision to the range specified by the field to its left (if any). Each field has 256 possible values. Referring still to Figure 19, at 1905 the mapping server 131 references the users IP address against a database which relates IP addresses to geographic areas and which relates particular VSS clusters to geographic areas. This data may be part of the mapping database 142.

Hence, at 1905, the mapping server 131 successively compares the fields of the user's IP address with this stored information, starting with the Class A field and proceeding as necessary to the less significant fields, to select the VSS cluster that is closest to the user. Next, at 1906, the mapping server 131 indicates the selected VSS cluster to the VMSS 22. At 1907, the VMSS 22 requests the selected VFS cluster to stream the video message to the user. At 1908, the selected VSS cluster streams the video message to the user.

Thus, a method and apparatus for allowing multiple users to communicate video with each other in a network environment have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.

Claims

CLAIMSWhat is claimed is:

1. A messaging system comprising: a plurality of file servers configured to store a plurality of user-to-user messages posted over a network by a plurality of users; a messaging server to regulate storage and playback of the messages over the network by the users, wherein each of the messages may be accessible to a plurality of the users; and a mapping server coupled to the messaging server to map the messages to the users and to the file servers, wherein each of the messages may have a plurality of physical filenames identifying a plurality of physical copies of the message stored in one or more of the file servers, and wherein each of the messages may have a plurality of user-specified logical filenames, each specified by a different one of the users having access to the message.

2. A messaging system as recited in claim 1, wherein the messaging server maintains a file database indicating, for each user, the messages accessible to the user by logical filename, and wherein the mapping server updates the mapping of messages to users and file servers without requiring the file database to be updated.

3. A messaging system as recited in claim 1, wherein the mapping server comprises: a mapping database containing information mapping each of the messages to one or more of the users and one or more of the file servers, wherein each physical copy of the message may be associated with a plurality of logical filenames specified by different ones of the users, and a mapping engine responsive to the video messaging server subsystem to update the mapping database.

4. A messaging system as recited in claim 3, wherein the mapping database includes, for each of the messages, a mapping identifier, one or more physical filenames of the message, and one or more user identifiers identifying the one or more of said users having access the message.

5. A messaging system as recited in claim 1, wherein the mapping server is further configured to respond to a request for one of the messages by one of the users by selecting one of the file servers storing the requested message for playback, based on the location of the user.

6. A messaging system as recited in claim 5, wherein said selecting one of the file servers comprises selecting said one of the file servers based on an Internet Protocol (IP) address associated with a client system of the user.

7. A messaging system as recited in claim 1, wherein the plurality of messages are video messages.

8. A video messaging system for allowing access to a plurality of video files stored by a plurality of users of client computer systems coupled to the video messaging system on a network, the video messaging system comprising: a plurality of video streaming server (VSS) clusters, each of the VSS clusters storing video files posted by said users over the network and configured to stream video files over the network to client computer systems of said users; a video messaging server to regulate posting and playback of the video files to and from the VSS clusters, respectively, by the users, wherein each of the video files may be accessible to a plurality of the users; and a video mapping server coupled to the video messaging server to map the video files to the users and to the VSS clusters, including managing the sharing of video files between users, wherein each of the video files may have a plurality of physical filenames identifying a plurality of physical copies of the video file stored in one or more of the VSS clusters, wherein each of the video files may have a plurality of user-specified logical filenames, wherein each of the logical filenames may be specified by a different one of the users having access to the video file.

9. A video messaging system as recited in claim 8, wherein the video messaging server maintains a file database indicating, for each user, the video files accessible to the user by logical filename, and wherein the video mapping server updates the mapping of video files to users and VSS clusters without requiring the file database to be updated.

10. A video messaging system as recited in claim 8, wherein the mapping server comprises: a mapping database containing information mapping each of the video files to one or more of the users and one or more of the VSS clusters, wherein each physical copy of the video file may be associated with a plurality of logical filenames specified by different ones of the users, and a mapping engine responsive to the video messaging server subsystem to update the mapping database.

11. A video messaging system as recited in claim 10, wherein the mapping database includes, for each of the video files, a mapping identifier, one or more physical filenames of the video file, and one or more user identifiers identifying the one or more of said users having access the video file.

12. A video messaging system as recited in claim 8, wherein each of the VSS clusters comprises: a video file server (VFS) to store video files posted by said users over the network; and a video streaming server (VSS) coupled to the VFS and to the network, the VSS caching video files stored in the VFS and responding to user inputs to stream video files over the network to client computer systems of said users.

13. A video messaging system as recited in claim 8, wherein the video mapping server is further configured to respond to a request for one of the video files by one of the users by selecting one of the VSS clusters storing the requested file based on the location of said one of the users.

14. A video messaging system for allowing access to a plurality of video files stored by a plurality of users of client computer systems coupled to the video messaging system on a network, the video messaging system comprising: a video streaming subsystem including a plurality of video streaming server (VSS) clusters, each of the VSS clusters including a video file server (VFS) to store video files posted by said users over the network, and a video streaming server (VSS) coupled to the VFS and to the network, the VSS caching video files stored in the VFS and responding to user inputs to stream video files over the network to client computer systems of said users; a video messaging server subsystem to regulate posting and playback of the video files by the users, wherein each of the video files can be accessible to a plurality of the users, wherein each of the video files has one or more physical filenames identifying one or more physical copies of the video file stored in one or more of the VSS clusters, and wherein each of the video files has one or more logical filenames, each specified by a different user having access to the video file, the video messaging server maintaining a file database indicating, for each user, the video files accessible to the user by logical filename. and a video mapping server coupled to the video messaging server subsystem to map the video files to the users and to the VSS clusters, including managing the sharing of video files between users, and to manage streaming of the video files to users, the video mapping server including a mapping database containing information mapping each of the video files to one or more of the users and one or more of the VSS clusters, including, for each of the video files, a mapping identifier, one or more physical filenames of the video file, and one or more user identifiers identifying the one or more of said users having access the video file, wherein each physical copy of the video file may be associated with a plurality of logical filenames specified by different ones of the users, and a mapping engine responsive to the video messaging server subsystem to update the mapping database in response to inputs from said users, including updating the mapping of video files to users and VSS clusters without requiring the file database to be updated, the mapping engine further configured to receive a request for one of the video files from one of the users and, in response to the request, to select one of the VSS clusters for streaming the requested video file to said one of the users, based on the location of said one of the users.

15. An apparatus for video messaging, comprising: a plurality of storage facilities to store a plurality of video files posted by a plurality of users over a network; means for regulating storage and playback of the video files by the users; and means for mapping the video files to the users and the storage facilities, such that each of the video files may be mapped to a plurality of the users and a plurality of the storage facilities.

16. An apparatus as recited in claim 15, wherein each of the video files may have a plurality of physical filenames identifying a plurality of physical copies of the video file stored in one or more of the storage facilities, wherein each of the video files may have a plurality of user-specified logical filenames, and wherein each of the logical filenames may be specified by a different one of the users having access to the video file.

17. An apparatus as recited in claim 15, further comprising: means for receiving a request from one of the users to playback one of the video files; and means for selecting one of the storage facilities storing the requested file in response to the request, for playback of the requested video file, based on the location of said one of the users.

18. An apparatus as recited in claim 15, further comprising means for maintaining a file database indicating, for each user, the video files accessible to the user by logical filename, wherein said means for mapping comprises means for updating a mapping of video files to users and storage facilities without requiring the file database to be updated.

19. A method of providing video messaging, comprising: using a plurality of storage facilities to store a plurality of video files posted by a plurality of users over a network; operating a messaging server to regulate storage and playback of the video files by the users; and operating a dedicated mapping server responsive to the messaging server to map the video files to the users and the storage facilities, wherein each of the video files may be mapped to a plurality of the users and a plurality of the storage facilities.

20. A method as recited in claim 19, wherein each of the video files may have a plurality of physical filenames identifying a plurality of physical copies of the video file stored in one or more of the storage facilities, wherein each of the video files may have a plurality of user-specified logical filenames, and wherein each of the logical filenames may be specified by a different one of the users having access to the video file.

21. A method as recited in claim 19, further comprising receiving a request to playback one of the video files from one of the users, wherein said operating the dedicated mapping server comprises using the mapping server to select one of the storage facilities storing the requested file based on the location of said one of the users.

22. A method as recited in claim 21, wherein said using the mapping server to select one of the storage facilities comprises using the mapping server to select one of the storage facilities based on an Internet Protocol (IP) address associated with a client system of said one of the users.

23. A method as recited in claim 19, further comprising maintaining a file database indicating, for each user, the video files accessible to the user by logical filename, wherein said operating the dedicated mapping server comprises updating a mapping of video files to users and storage facilities without requiring the file database to be updated.

24. A method of providing video messaging, comprising: storing a plurality of video files posted by a plurality of users over a network, using a plurality of storage facilities; regulating storage and playback of the video files over the network by the users, wherein each of the video files may be accessible to a plurality of the users; and managing sharing of video files between the users, wherein each of the video files may have a plurality of physical filenames identifying a plurality of physical copies of the video file stored in one or more of the storage facilities, wherein each of the video files may have a plurality of user-specified logical filenames, wherein each of the logical filenames may be specified by a different one of the users having access to the video file.

25. A method as recited in claim 24, wherein said managing sharing of video files comprises using a dedicated mapping server to manage said sharing of video files.

26. A method as recited in claim 24, further comprising maintaining a file database indicating, for each user, the video files accessible to the user by logical filename, wherein said managing sharing of video files comprises updating a mapping of video files to users and storage facilities without requiring the file database to be updated.

27. A method of enabling video messaging over a network by each of a plurality of users, comprising: receiving a video message from a first user over the network; assigning a first physical filename to the message; using a mapping server to assign a mapping identifier to the video message; storing the video message in a first storage facility, the first physical filename representing the video message stored in the first storage facility; receiving a user-specified first logical filename for the video message; storing in a first database information associating the first logical filename with the mapping identifier and a first user identifier, the first user identifier identifying the first user; and using the mapping server to store, in a second database separate from the first database, information associating the mapping identifier with the first physical filename and the first user identifier.

28. A method as recited in claim 27, further comprising: receiving user input from a second user with access to the video message, the user input for copying the video message, the user input specifying a second logical filename for the video message; in response to the user input from the second user storing in the first database information associating the second logical filename with the mapping identifier and a second user identifier, the second user identifier identifying the second user; and using the mapping server to store, in the second database, information associating the second user identifier with the mapping identifier, such that the mapping identifier is associated with the first physical filename, the first user identifier, and the second user identifier in the second database.

29. A method as recited in claim 27, further comprising creating a copy of the video message by: assigning a second physical filename to the video message; copying the video message to a second storage facility, the second physical filename representing the copy of the video message stored in the second storage facility; and using the mapping server to store information associating the second physical filename with the mapping identifier, such that the mapping identifier is associated with the first physical filename, the second physical filename, and the first user identifier in the second database.

30. A method as recited in claim 27, further comprising: receiving user input from a second user with access to the video message, the user input for copying the video message, the user input specifying a second logical filename for the video message; in response to the user input from the second user storing in the first database information associating the second logical filename with the mapping identifier and a second user identifier, the second user identifier identifying the second user; and using the mapping server to store, in the second database, information associating the second user identifier with the mapping identifier, such that the mapping identifier is associated with the first physical filename, the second physical filename, the first user identifier, and the second user identifier in the second database.