WO2001093101A2 - Serveur de mise en correspondance de messages - Google Patents

Serveur de mise en correspondance de messages Download PDF

Info

Publication number
WO2001093101A2
WO2001093101A2 PCT/US2001/012345 US0112345W WO0193101A2 WO 2001093101 A2 WO2001093101 A2 WO 2001093101A2 US 0112345 W US0112345 W US 0112345W WO 0193101 A2 WO0193101 A2 WO 0193101A2
Authority
WO
WIPO (PCT)
Prior art keywords
video
user
users
mapping
file
Prior art date
Application number
PCT/US2001/012345
Other languages
English (en)
Other versions
WO2001093101A3 (fr
Inventor
Koh Hee Chang
Original Assignee
Moani, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Moani, Inc. filed Critical Moani, Inc.
Priority to AU2001253548A priority Critical patent/AU2001253548A1/en
Publication of WO2001093101A2 publication Critical patent/WO2001093101A2/fr
Publication of WO2001093101A3 publication Critical patent/WO2001093101A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/10—Multimedia information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data

Definitions

  • 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.
  • 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).
  • 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.
  • FIG. 1 is a block diagram showing a network configuration in which a Video Messaging System (VMS) is implemented;
  • VMS Video Messaging System
  • FIG. 1 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;
  • FIG. 4 shows the VSS Subsystem in greater detail
  • FIG. 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.
  • FIG. 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.
  • 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.
  • audio data associated with such data, for generating audible output corresponding to the visual output.
  • audiovisual data for generating the audible and visual outputs.
  • video also includes audiovisual data and its corresponding audiovisual output, although any such audio component is optional.
  • 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.
  • 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.
  • 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.
  • the described technology is highly scalable and distributable in terms of processing power, storage space, and geographical location.
  • 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.
  • VMS Video Messaging System
  • the VMS allows an authorized user to easily communicate a video message to another user.
  • 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.
  • 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.
  • the network configuration includes the VMS 1, which is connected to a network 2.
  • the network 2 is an Internet Protocol (IP) based internetwork, such as the Internet.
  • IP Internet Protocol
  • 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.
  • client computer systems 3 and one or more Video Application Server (VAS) Subsystems 4.
  • VAS Video Application Server
  • 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.
  • CMP Client Messaging Plug-in
  • CEP Client Encoder Plug-in
  • CDP Client Display Plug-in
  • 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.
  • a VAS Subsystem 4 may be an electronic mail (email) server or a World Wide Web server.
  • users can access the VMS 1 to associate video messages with email communications managed by the email server (the VAS 4).
  • 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.
  • 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.
  • 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.
  • 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.
  • the video output devices 6 are conventional audio and video output files and devices, such as a display device and audio speaker.
  • 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.
  • 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.
  • SVA Share Video- Audio
  • the system of Figure 1 uses two special-purpose protocols, namely, a VMS Application Interface Protocol (VAIP) and a Video Mapping Interface Protocol (VMIP).
  • VAIP VMS Application Interface Protocol
  • VMIP Video Mapping Interface Protocol
  • 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.
  • 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.
  • 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.
  • the CMP 8 receives the data from the CEP 9 and transfers it to the VSS Subsystem 12.
  • FIG. 2 illustrates the architecture of the VMS 1 in greater detail, according to one embodiment.
  • 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 may be implemented in a conventional computer system, such as a PC, a workstation, or the like.
  • these components may each be implemented in separate computer systems, which may be geographically distributed.
  • 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.
  • 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.
  • PCI Peripheral Component Interconnect
  • 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.
  • 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 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.
  • ISDN Integrated Services Digital Network
  • xDSL Digital Subscriber Line
  • the VSS Subsystem 12 may include one or more VFS 23 connected to one or more VSS 24.
  • 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.
  • NFS Network File System
  • the numbers N and M are not necessarily equal.
  • This configuration allows high scalability of the VSS Subsystem 12.
  • the addition of more VFS 23 provides for more storage of video files.
  • the addition of more VSS 24 provides higher bandwidth for purposes of uploading and downloading video files.
  • the VMS 1 is further scalable by adding additional PVAS 21 and/or VMSS 22 to provide for a greater number of users.
  • the VAIP defines the control and management protocols of the VMS 1 and facilitates the management of 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.
  • 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.
  • VMS key 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.
  • 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.
  • URL Uniform Resource Locator
  • 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.
  • 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.
  • the VMSS 22 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.
  • 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.
  • VMS 1 For 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.
  • User 1 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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
  • TCP/IP Transfer Control Protocol /Internet Protocol
  • 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.
  • the command executor 54 obtains the directory information from the transaction controller 57, which has access to databases 56 and 58-62.
  • multiple sessions of the command executor 54 may be active at the same instant.
  • 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.
  • the transaction controller 57 is used to maintain the directory database in the local machine and to ensure data integrity in the VMSS databases.
  • only one transaction controller 57 can be active, and this prevents a chain of database accesses from a VMS thread from being broken up.
  • FIG. 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.
  • 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.
  • 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.
  • FIG. 7 illustrates the layout of the session database 58, according to one embodiment.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG 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.
  • 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.
  • 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.
  • the VMSS 22 receives inputs from the sending user selecting a video file stored in the VSS Subsystem 12.
  • the VMSS 22 generates a VMS key corresponding to the selected video file.
  • 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.
  • the VMSS 22 receives inputs representing the recipient user's selection of the hypermedia link.
  • 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.
  • the VSS Subsystem 12 receives the VSS key returned by the client system of the recipient user.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • 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).
  • ID mapping identifier
  • the mapping server 131 permits each user to independently access and manipulate his own logical files.
  • 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.
  • mapping server 131 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).
  • FIG 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.
  • 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.
  • this mapping technique can be used further to map multiple video messages.
  • 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.
  • mapping IDs are assigned by the mapping server 131.
  • each user owning the video message may assign a different logical filename to the video message.
  • 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.
  • 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.
  • FIG 16 shows a process by which the VMS 1 may upload and map a video message, using the mapping server 131.
  • 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.
  • the VMSS 22 selects a VFS 23 to store the video message.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the mapping server 131 creates the requested database entry.
  • FIG. 17 shows a process for copying and uploaded video message from one VFS 23 to another.
  • the VMSS 22 selects a VFS 23 to store a new copy of a previously- uploaded video message.
  • the VMSS 22 requests and receives a new physical filename from the selected VFS 23.
  • 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.
  • the selected VFS 23 copies the video message and responds to the VMSS 22 with a "copy complete" signal.
  • 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.
  • the mapping server 131 performs the requested modification.
  • a first user sends a video message to another user in the manner described above.
  • 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.
  • the sending user sends the video message to the recipient user.
  • the recipient user views the video message.
  • 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.
  • 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.
  • the mapping server 131 performs the requested modification.
  • mapping server 131 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.
  • the VMSS 22 receives a request to playback the video message.
  • the VMSS forwards the user's IP address to the mapping server 131.
  • the mapping server 131 identifies the one or more VSS clusters that contain a physical copy of the requested video message.
  • 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.
  • FIG 20 schematically shows the format of an IP address.
  • 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.
  • 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.
  • 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.
  • 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.
  • the mapping server 131 indicates the selected VSS cluster to the VMSS 22.
  • the VMSS 22 requests the selected VFS cluster to stream the video message to the user.
  • the selected VSS cluster streams the video message to the user.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

L'invention porte sur un système de messagerie vidéo (VMS) permettant aux utilisateurs de différents systèmes de traitement d'un réseau d'accéder efficacement à des fichiers vidéo. Le VMS permet à un utilisateur agréé d'associer un fichier vidéo stocké dans un système serveur avec un contenu stocké dans un système client distant, tel qu'un E-mail ou une page hypermédia, de manière à ce qu'un autre utilisateur puisse voir le fichier vidéo en association avec le contenu. Le VMS comporte un sous-système de serveur de diffusion en temps réel, et un sous-système de messageries vidéo. Le sous-système de serveur de diffusion en temps réel archive les fichiers vidéo transmis au VMS par les utilisateurs via le réseau, et transmet en direct les fichiers vidéo via le réseau aux systèmes d'ordinateurs clients en réponse à des demandes agrées d'utilisateurs des systèmes d'ordinateurs clients. Le sous-système de serveur de diffusion en temps réel comporte un ou plusieurs serveurs stockant les fichiers vidéo, et un ou plusieurs serveurs de diffusion en temps réel retrouvant les fichiers vidéo stockés. Le sous-système de messageries vidéo, qui réglemente l'accès aux fichiers vidéo en établissant différents niveaux de sécurité, comporte des composants interprétant les ordres des utilisateurs, déterminant leur validité en fonction des niveaux de sécurité, et exécutant les ordres reconnus valables, tout en incluant des bases de données d'informations servant à réglementer l'accès aux fichiers vidéo stockés. Le VMS peut en outre comporter un serveur spécialisé mettant en correspondance un ou plusieurs des utilisateurs avec un ou plusieurs des fichiers vidéo stockés.
PCT/US2001/012345 2000-06-01 2001-04-10 Serveur de mise en correspondance de messages WO2001093101A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001253548A AU2001253548A1 (en) 2000-06-01 2001-04-10 Video messaging system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US58647500A 2000-06-01 2000-06-01
US09/586,475 2000-06-01

Publications (2)

Publication Number Publication Date
WO2001093101A2 true WO2001093101A2 (fr) 2001-12-06
WO2001093101A3 WO2001093101A3 (fr) 2003-01-30

Family

ID=24345897

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/012345 WO2001093101A2 (fr) 2000-06-01 2001-04-10 Serveur de mise en correspondance de messages

Country Status (2)

Country Link
AU (1) AU2001253548A1 (fr)
WO (1) WO2001093101A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100426270B1 (ko) * 2002-05-21 2004-04-08 이승룡 멀티미디어 스트리밍을 제공하는 서버 및 그 장치 내에있는 스트리밍 시스템과 멀티미디어 데이터베이스시스템간의 연동방법
CN102830955A (zh) * 2011-06-15 2012-12-19 昆山漠野软件有限公司 一种摄像机辅助应用系统
US20140059149A1 (en) * 2007-12-07 2014-02-27 Vidiense Technology Pty Ltd. Method to Display a Video in an Email
CN104376131A (zh) * 2013-08-13 2015-02-25 苏州广海信息科技有限公司 一种摄像机辅助软件

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0845894A2 (fr) * 1996-11-05 1998-06-03 Boston Technology Inc. Un système pour accéder aux boítes aux lettres et aux messages multimédias sur Internet et par téléphone
US5867494A (en) * 1996-11-18 1999-02-02 Mci Communication Corporation System, method and article of manufacture with integrated video conferencing billing in a communication system architecture
US5951694A (en) * 1995-06-07 1999-09-14 Microsoft Corporation Method of redirecting a client service session to a second application server without interrupting the session by forwarding service-specific information to the second server

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5951694A (en) * 1995-06-07 1999-09-14 Microsoft Corporation Method of redirecting a client service session to a second application server without interrupting the session by forwarding service-specific information to the second server
EP0845894A2 (fr) * 1996-11-05 1998-06-03 Boston Technology Inc. Un système pour accéder aux boítes aux lettres et aux messages multimédias sur Internet et par téléphone
US5867494A (en) * 1996-11-18 1999-02-02 Mci Communication Corporation System, method and article of manufacture with integrated video conferencing billing in a communication system architecture

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ENGLAND P ET AL: "RAVE: Real-time services for the Web" COMPUTER NETWORKS AND ISDN SYSTEMS, NORTH HOLLAND PUBLISHING. AMSTERDAM, NL, vol. 28, no. 11, 1 May 1996 (1996-05-01), pages 1547-1558, XP004018250 ISSN: 0169-7552 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100426270B1 (ko) * 2002-05-21 2004-04-08 이승룡 멀티미디어 스트리밍을 제공하는 서버 및 그 장치 내에있는 스트리밍 시스템과 멀티미디어 데이터베이스시스템간의 연동방법
US20140059149A1 (en) * 2007-12-07 2014-02-27 Vidiense Technology Pty Ltd. Method to Display a Video in an Email
US9083665B2 (en) * 2007-12-07 2015-07-14 Vidiense Technology Pty Ltd Methods and systems to display a video in an email
US10270722B2 (en) 2007-12-07 2019-04-23 Vidiense Technology Pty Ltd. Methods and systems to display a video in an email
CN102830955A (zh) * 2011-06-15 2012-12-19 昆山漠野软件有限公司 一种摄像机辅助应用系统
CN104376131A (zh) * 2013-08-13 2015-02-25 苏州广海信息科技有限公司 一种摄像机辅助软件

Also Published As

Publication number Publication date
AU2001253548A1 (en) 2001-12-11
WO2001093101A3 (fr) 2003-01-30

Similar Documents

Publication Publication Date Title
US8127222B2 (en) Latches-links as virtual attachments in documents
KR101138434B1 (ko) 실시간 통신 플랫폼에 기반하여 네트워크 하드디스크를실행하는 시스템 및 그 방법
EP1407358B1 (fr) Systeme et procedes de controle d'acces a un contenu numerique y compris des medias de diffusion en continu
US6851113B2 (en) Secure shell protocol access control
US7506034B2 (en) Methods and apparatus for off loading content servers through direct file transfer from a storage center to an end-user
US7203731B1 (en) Dynamic replication of files in a network storage system
CA2399657C (fr) Systeme destine a un reseau media distribue et a un serveur de metadonnees
US7266555B1 (en) Methods and apparatus for accessing remote storage through use of a local device
US7428540B1 (en) Network storage system
KR100972306B1 (ko) 애플리케이션 발생기
US20040015703A1 (en) System and method for controlling access to digital content, including streaming media
US20050246393A1 (en) Distributed storage cluster architecture
US20020111942A1 (en) Method and system for providing remote access to the facilities of a server computer
GB2373067A (en) File transfer method and system using segmented transfer and targeted content
US20050268042A1 (en) Caching based on access rights in connection with a content management server system or the like
US20050044223A1 (en) Method and apparatus for entitlement based dynamic sampling
EP1602049A2 (fr) Systeme et procede de gestion d'un site web
US20030163740A1 (en) User interface system
WO2001041446A1 (fr) Procede et appareil de communication de donnees video entre de multiples utilisateurs sur un reseau
WO2001093101A2 (fr) Serveur de mise en correspondance de messages
US20050108361A1 (en) Method and system for content delivery
WO2007095793A1 (fr) Réseau à fonction de stockage et procédé de stockage de données
KR20020011621A (ko) 인터넷으로 연결된 컴퓨터를 이용한 저장공간의 공유 및접근 시스템
US20030212833A1 (en) Web-based practice management system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69 (1) EPC EPO FORM 1205A DATED 24.03.03

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP