WO2001041446A1

WO2001041446A1 - Method and apparatus for communication of video between multiple users on a network

Info

Publication number: WO2001041446A1
Application number: PCT/US2000/022241
Authority: WO
Inventors: Koh Hee Chang; Tham Jo Yew; Goh Seng Chai; Ong Lon Voon
Original assignee: Moani, Inc.
Priority date: 1999-11-30
Filing date: 2000-08-11
Publication date: 2001-06-07
Also published as: AU6770600A

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, in response to authorized requests from users of the client computer systems.

Description

Method and Apparatus for Communication of Video Between Multiple Users on a Network

FIELD OF THE INVENTION

The present invention pertains to techniques for allowing computer users to communicate video to 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 video files in a network environment. BACKGROUND OF THE INVENTION

Human beings are communicative, visually-oriented creatures. Accordingly, the use of video is of great interest in many areas of communications. The Internet is a well-known communications medium. As is well-known, the Internet is a global network of computers that 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. Communication of video and other types of isochronous data requires a large amount of bandwidth. With recent advances in data communication technology, however, network communication of video has become practical. 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 providing a network-based video messaging system. A number of video files are maintained in a server system on the network. The server system is used to allow a first user, remote from the server system, to associate one of the video files stored in the server system with content on the network. The content is for communication to a second user on the network. The video file that has been associated with the content by the first user is then transmitted over the network from the server system to a remote client system of the second user, in response to input from the second user.

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 to the block diagram showing how multiple security levels are 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; and

Figures 11 and 12 are flow diagrams collectively showing a process for accessing a stored video file. 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.

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.

Note that 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. 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 network, such as the Internet. Another 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. 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.

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 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 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 streaming 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.

Note that 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 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. Note that 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 mapper 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 mapper 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 file name 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 mapper database 62. The pointer to the map or database 62 points to a location in the mapper database 62 that identifies the physical location 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 mapper 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 mapper 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 provides 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.

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

CLAIMS.What is claimed is:

1. A method of providing a network-based video messaging system, the method comprising: maintaining a plurality of video files in a server system on the network; using the server system to allow a first user remote from the server system to associate one of the video files stored in the server system with content on the network, the content for communication to a second user on the network; and transmitting said one of the video files over the network from the server system to a remote client system of the second user, in response to input from the second user.

2. A method as recited in claim 1, wherein the content comprises a user-to-user electronic message.

3. A method as recited in claim 1, wherein the content comprises a hypermedia document.

4. A method as recited in claim 1, further comprising allowing a user of a client system on the network to store a video file in the server system via the network.

5. A method as recited in claim 4, wherein the video file is maintained on the server system for future association with content by the user.

6. A method as recited in claim 1, wherein said transmitting comprises transmitting said one of the video files in a streaming mode.

7. A method as recited in claim 6, wherein said transmitting comprises transmitting said one of the video files in a streaming mode, such that said one of the video files is not saved in the remote client system of the second user as a result of said transmitting.

8. A method as recited in claim 1, wherein said using the server system comprises using the server system to include a reference to said one of the video files within the content.

9. A method as recited in claim 8, wherein the reference comprises a hypermedia link referencing said one of the video files.

10. A method as recited in claim 9, wherein the reference includes authentication information for enabling the server system to regulate playback of said one of the video files.

11. A method as recited in claim 1, further comprising using the server system to regulate access to the stored video files.

12. A method as recited in claim 11, further comprising: mamtaining a plurality of security levels in the server system for regulating access to the stored video files; and selectively providing a user with access to a stored video file based on a security levels associated with the user.

13. A method as recited in claim 12, wherein said selectively providing access comprises selectively allowing the user to view a stored video file based on a security level of the user.

14. A method as recited in claim 13, wherein said selectively allowing the user to view a stored video file comprises allowing the user to view the stored video file only for a specified period of time.

15. A method as recited in claim 12, wherein said selectively providing a user with access comprises selectively allowing the user to update a stored video file based on a security level associated with the user.

16. A method of providing a network-based video messaging system, the method comprising: storing a plurality of video clips in a server system on the network; using the server system to enable a client system of a first user on the network to associate one of the video clips with a message from the first user to a second user of a client system on the network, in response to input from the first user; and using the server system to transmit said one of the video clips to the client system of the second user in response to input from the second user.

17. A method as recited in claim 16, wherein said input from the second user is responsive to the message from the first user to the second user.

18. A method as recited in claim 17, wherein said using the server system to transmit said one of the video clips comprises transmitting said one of the video clips in a streaming mode.

19. A method as recited in claim 16, wherein said storing comprises storing video clips posted by a user of a client system on the network.

20. A method as recited in claim 16, wherein said one of the video clips has been previously posted to the server system by the first user.

21. A method as recited in claim 17, wherein said one of the video clips has been previously posted to the server system by a user other than the first user.

22. A method as recited in claim 17, further comprising using the server system to include a reference to said one of the video clips in the message.

23. A method as recited in claim 22, wherein the reference comprises a hypermedia link referencing said one of the video clips.

24. A method as recited in claim 23, wherein the reference includes authentication information for enabling the server system to regulate playback of said one of the video clips.

25. A method as recited in claim 17, further comprising using the server system to regulate access by said users to the stored video clips.

26. A method as recited in claim 25, further comprising: maintaining a plurality of security levels in the server system for regulating access to the stored video clips; and selectively providing a user with access to a stored video clip based on a security levels associated with the user.

27. A method as recited in claim 26, wherein said selectively providing access comprises selectively allowing the user to view a stored video clip based on a security level of the user.

28. A method as recited in claim 27, wherein said selectively allowing the user to view a stored video clip comprises allowing the user to view the stored video clip only for a specified period of time.

29. A method as recited in claim 26, wherein said selectively providing a user with access comprises selectively allowing the user to update a stored video clip based on a security level associated with the user.

30. A method of providing communication of video across a computer network, the method comprising: maintaining a plurality of video files in a server system on the network; receiving first input via the network, the first input representing user inputs selecting a video file of the plurality of stored video files; in response to the first input, providing an authorized processing system on the network with a hypermedia link, the hypermedia link including a reference to the selected video file and information for authorizing playback of the selected video file; receiving second input from a client system via the network, the second input representing a selection of the hypermedia link by a user of the client system; authorizing access to the selected video file based on the second input; and playing back the selected video file to the second client system via the network.

31. A method as recited in claim 30, wherein the client system obtains the hypermedia link from the authorized processing system prior to the selection of the hypermedia link by the user of the client system.

32. A method as recited in claim 29, wherein said playing back the selected video file comprises using the server system to play back the selected video file to the client system in a streaming mode.

33. A method as recited in claim 29, wherein said content comprises an electronic mail message.

34. A method as recited in claim 29, wherein said content comprises a hypermedia document.

35. A method as recited in claim 29, further comprising allowing shared access to at least some of the plurality of stored videos by each of a plurality of users.

36. A method as recited in claim 29, further comprising providing a plurality of security levels for controlling access to the stored video files, including assigning each of a plurality of users a security level.

37. A method as recited in claim 29, wherein the stored video files comprise a plurality of pre-prepared video files, each corresponding to at least one of a plurality of user-selectable message themes, and each selectable by any of a plurality of users for association with a message to another user.

38. A method as recited in claim 29, further comprising: including in the message to the user of the second client system, information for enabling the second client system to control a frame rate of playback of the specified video file.

39. A method of operating a server system on a network to enable users of a plurality of computer systems on the network to communicate video files with each other, the method comprising: storing a plurality of video files in the server system; receiving, at the server system, first input and an associated video file from a first client system via the network; storing the video file in the server system in response to the first input, such that the video file becomes stored as one of the plurality of video files maintained in the server system; receiving second input via the network, the second input representing user inputs selecting a video file of the plurality of stored video files; in response to the second input, providing an authorized processing system on the network with a hypermedia link, the hypermedia link including a reference to the selected video file and a first key for authorizing playback the selected video file, such that the authorized processing system can incorporate the hypermedia link into content maintained by the authorized processing system; receiving third input from a second client system via the network, the third input representing a selection of the hypermedia link by a user of the second client system; determining whether access to the selected video file is authorized in response to receiving the third input; if access to the selected file is determined to be authorized, then providing a second key to the second client system; receiving the second key from the second client system after providing the second key to the second client system; using the second key to locate the selected video file in the server system in response to receiving the second key from the second client system; and playing back the selected video file to the second client system by streaming the video to the second client system via the network.

40. A method as recited in claim 39, wherein said content comprises an electronic mail message.

41. A method as recited in claim 39, wherein said content comprises a hypermedia document.

42. A video messaging system (VMS) for providing access to video by users of a plurality of processing systems on a network, the VMS comprising: a video streaming server subsystem storing a plurality of video files posted to the VMS by said users over the network, the video streaming server subsystem streaming video files over the network to client computer systems on the network in response to inputs representing authorized requests from users of the client computer systems; and a video messaging server subsystem regulating access to the video files by said users.

43. A VMS as recited in claim 42, wherein the video messaging server subsystem regulates access to the video files by selectively authorizing playback of video files by the video streaming server subsystem in response to user inputs from remote client systems.

44. A VMS as recited in claim 43, wherein the video messaging server subsystem further regulates access to the video files by selectively authorizing posting of videos to the video streaming server subsystem by said users.

45. A VMS as recited in claim 42, wherein the video streaming server subsystem comprises a video file server storing the video files and a video streaming server caching particular ones of the video files.

46. A VMS as recited in claim 45, wherein the video streaming server subsystem further comprises a plurality of video file servers substantially identical to said video file server.

47. A VMS as recited in claim 45, wherein the video streaming server subsystem further comprises a plurality of video streaming servers substantially identical to said video streaming server.

48. A VMS as recited in claim 45, wherein the video streaming server subsystem further comprises: a plurality of video file servers substantially identical to said video file server; and a plurality of video streaming servers substantially identical to said video streaming server.

49. A VMS as recited in claim 42, wherein the video messaging server subsystem comprises: a command interpreter configured to interpret commands representing user inputs from said users, a security controller configured to implement a plurality of security levels for regulating user access to the video files, and further configured to determine validity of the commands based on the security levels, a command executor to execute the commands that are determined to be valid, and a plurality of databases coupled to the command executor and storing information for use in regulating access of the video files.

50. A video messaging system (VMS) for allowing access to video stored centrally in the VMS by users of a plurality of client computer systems coupled to the VMS remotely on a network, the VMS comprising: a video streaming subsystem including a video file server (VFS) storing video files posted by said users over the network, and a video streaming server coupled to the VFS and to the network, the video streaming server caching video files stored in the VFS and responding to user inputs received to stream video files over the network to the client computer systems; and a video messaging server subsystem configured to regulate posting and playback of video files by said users, the video messaging server subsystem including, a command interpreter configured to interpret commands representing user inputs from said users, a security controller configured to implement a plurality of security levels for regulating user access to the video files, and further configured to determine validity of the commands based on the security levels, a command executor to execute the commands that are determined to be valid, and a plurality of databases coupled to the command executor and storing information for use in regulating access of the video files.

51. A VMS as recited in claim 50, wherein the video streaming server subsystem further comprises a plurality of VFS substantially identical to said VFS.

52. A VMS as recited in claim 51, wherein the video streaming server subsystem further comprises a plurality of video streaming servers substantially identical to said video streaming server.

53. A VMS as recited in claim 51, wherein the video streaming server subsystem further comprises: a plurality of VFS substantially identical to said VFS; and a plurality of video streaming servers substantially identical to said video streaming server.

54. An apparatus for providing a network-based video messaging system, the method comprising: means for maintaining a plurality of video files in a server system on the network; means for allowing a first user to associate one of the stored video files with content on the network by using the server system, the content for communication to a second user on the network; and means for transmitting said one of the video files over the network from the server system to a client system of the second user, in response to input from the second user.

55. An apparatus as recited in claim 54, wherein the content comprises a user-to- user electronic message.

56. An apparatus as recited in claim 54, wherein the content comprises a hypermedia document.

57. An apparatus as recited in claim 54, further comprising means for allowing a user of a client system on the network to store a video file in the server system via the network.

58. An apparatus as recited in claim 57, wherein the video file is maintained on the server system for future association with content by the user.

59. An apparatus as recited in claim 54, wherein said means for transmitting comprises transmitting said one of the video files in a streaming mode.

60. An apparatus as recited in claim 54, wherein said means for allowing comprises using the server system to include a reference to said one of the video files within the content.

61. An apparatus as recited in claim 60, wherein the reference comprises a hypermedia link referencing said one of the video files.

62. An apparatus as recited in claim 61, wherein the reference includes authentication information for enabling the server system to regulate playback of said one of the video files.

63. An apparatus as recited in claim 54, further comprising means for using the server system to regulate access to the stored video files.

64. An apparatus as recited in claim 63, further comprising: means for maintaining a plurality of security levels in the server system for regulating access to the stored video files; and means for selectively providing a user with access to a stored video file based on a security levels associated with the user.

65. An apparatus as recited in claim 64, wherein said means for selectively providing access comprises means for selectively allowing the user to view a stored video file based on a security level of the user.

66. An apparatus as recited in claim 65, wherein said selectively means for allowing the user to view a stored video file comprises means for allowing the user to view the stored video file only for a specified period of time.

67. An apparatus as recited in claim 64, wherein said means for selectively providing a user with access comprises means for selectively allowing the user to update a stored video file based on a security level associated with the user.