WO2000052898A9 - Procede et appareil pour communiquer des donnees au moyen d'un systeme de communication base sur le web - Google Patents

Procede et appareil pour communiquer des donnees au moyen d'un systeme de communication base sur le web

Info

Publication number
WO2000052898A9
WO2000052898A9 PCT/US2000/005842 US0005842W WO0052898A9 WO 2000052898 A9 WO2000052898 A9 WO 2000052898A9 US 0005842 W US0005842 W US 0005842W WO 0052898 A9 WO0052898 A9 WO 0052898A9
Authority
WO
WIPO (PCT)
Prior art keywords
data
target
data file
message
communications
Prior art date
Application number
PCT/US2000/005842
Other languages
English (en)
Other versions
WO2000052898A3 (fr
WO2000052898A2 (fr
Inventor
Jon Louis
Mark R Spowage
William Calvert Appleton
Original Assignee
Message Bay Inc
Jon Louis
Mark R Spowage
William Calvert Appleton
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 Message Bay Inc, Jon Louis, Mark R Spowage, William Calvert Appleton filed Critical Message Bay Inc
Priority to AU35145/00A priority Critical patent/AU3514500A/en
Publication of WO2000052898A2 publication Critical patent/WO2000052898A2/fr
Publication of WO2000052898A3 publication Critical patent/WO2000052898A3/fr
Publication of WO2000052898A9 publication Critical patent/WO2000052898A9/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management

Definitions

  • the present invention relates generally to the field of data communications and, more specifically, to a method and apparatus for communicating data from a source to a target via a network-based communications system.
  • a data file may be sent as an attachment to an e-mail, or may be downloaded to a client service from a server using a network protocol, such as the File Transfer Protocol (FTP) or the Hypertext Transfer Protocol (HTTP).
  • FTP File Transfer Protocol
  • HTTP Hypertext Transfer Protocol
  • FTP File Transfer Protocol
  • HTTP Hypertext Transfer Protocol
  • a source user 102 utilizes a client e-mail application or a web-based e- mail service to send a data file 104 to multiple target users 106.
  • multiple copies of the data file 104 are created and propagated, one to each target user 106 at a respective e-mail address. This may result in a single data file 104, propagated to multiple targets, consuming an excessive amount of network bandwidth on a network 108.
  • each target user 106 will store the received data file 104 on a local storage device.
  • a separate and distinct copy of the relevant data file 104 will be maintained by a host server within a storage space allocated to the respective target user 106.
  • the uploading and downloading of large data files from a client device coupled to network may also be slow and time-consuming.
  • a data file propagated from a source to a communication system via a communication network, is stored on the communications system so as to be accessible by the communications network.
  • a unique access key is generated for a designated target of the data file identified by target information associated with the data file. The unique key is communicated to the target so as to enable the target to stream the data file from the source.
  • a communications server includes a storage facility to store a data file, propagated from a source to the communications server via a communications network, so as to be accessible via the communications network.
  • Access key logic generates a unique access key for a designated target of the data file identified by target information associated with the data file.
  • Communications logic propagates the new key to the target so as to enable the target to stream data file from the source to a destination utilizing the unique key.
  • a third aspect of the present invention there is provided a method of implementing a message system. Message data is streamed from a source to a message hosting system. The message data is then stored on the message hosting system. A target of the message data is notified of receipt of the message data at the message hosting system.
  • a method of communicating data that includes receiving a data input at a source. Concurrently with the receipt of the data input, the source streams a data output over a communications network from the source to a storage system and as discrete packets, the data output being derived from the data input. A data file is validated at the storage system upon receipt of a user-generated confirmation indication from the source, the data file being constructed from the data output of the source.
  • a method that includes the generation of an identifier code for each of a plurality of entities, each identification code being unique to an associated entity. Each identification code is then provided to an associated entity for inclusion within a network interface for the relevant entity.
  • a storage request indicating an identification code, is received at a data storage facility.
  • a target entity is identified utilizing the received identification code.
  • Streamed data is then received via a communications network at the storage system.
  • a data file, constructed from the stream data, is stored at the storage system. The data file is identified as being associated with the target client.
  • Figure 1 is a diagrammatic representation of a prior art data file communications system.
  • Figures 2A and 2B are diagrammatic representations of respective network-based communication environments, according to exemplary embodiments of the present invention.
  • Figures 3A and 3B are diagrammatic representations of respective network-based environments, according to exemplary embodiments of the present invention, showing system-level architectural details.
  • Figure 4 is a block diagram illustrating architectural details of a messaging client, according to an exemplary embodiment of the present invention.
  • Figure 5 is a block diagram showing details pertaining to access control logic, according to an exemplary embodiment of the present invention.
  • Figure 6 includes tables, according to an exemplary embodiment of the present invention, that may be maintained within a data communication system for the purpose of storing access keys, transaction records, and subscriber information.
  • Figure 7 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of communicating a data file from a source user to a target user within a data communications 10 environment.
  • Figure 8 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, by which a designated target recipient of a data file may access and retrieve a data file within a data communications system.
  • Figure 9 illustrates an HTML document, according to an exemplary embodiment of the present invention, incorporated within a web site of an organization and including a message bar, according to an exemplary embodiment of the present invention.
  • Figure 10 is a representation of a login screen, according to an exemplary embodiment of the present invention.
  • Figure 11 shows an exemplary screen display by a browser application including three panels, namely a mailbox panel, a message panel and a menu panel, according to an exemplary embodiment of the present invention.
  • Figure 12 is a flow chart, illustrating a method, according to an exemplary embodiment of the present invention, of selling or distributing message bars to enable utilization of a data communications system.
  • Figure 13 is a flow chart detailing a method, according to an exemplary embodiment of the present invention, by which a source user may send a message to a target user utilizing a data communications system.
  • Figure 14 is a flow chart detailing a method, according to an exemplary embodiment of the present invention, by which a user may interact with a message bar and a messaging client to record and stream a data file to data communications system.
  • Figure 15 is a flow chart detailing a method, according to an exemplary embodiment of the present invention, by which a target user may view and retrieve a data file from a data communications system.
  • Figure 16 is a flow chart detailing a method, according to an exemplary embodiment of the present invention, whereby a source user may stream data from a messaging client to a data communications system.
  • Figure 17 is a diagrammatic representation of an audio capture and streaming operation, according to an exemplary embodiment of the present invention.
  • Figure 18 is a block diagram of a data communications system, illustrating the use of a file identifier within a header associated with a time- limit increment of data propagated from a message client.
  • Figure 19 is a diagrammatic representation of a machine, in an exemplary form of a computer system, within which a set of instructions for causing the machine to perform any one of the methodologies discussed below will be executed.
  • FIG. 2A is diagrammatic representation of a network-based communication system202, according to an exemplary embodiment, within which the present invention may be implemented.
  • the communications system 202 includes a source 204 from which a data file 206 is propagated over a network 208 to a communications server 210.
  • the source 204 may be a client-based e-mail application, such as Microsoft Outlook developed by Microsoft Corporation of Redmond, Washington, or the Eudora e-mail client developed by Qualcomm, Incorporated of San Diego, California.
  • the source may be a web-based e-mail service, such as the Yahoo! Mail service offered by Yahoo! Incorporated of Santa Clara, California or the Microsoft
  • the source 204 may comprise any FTP or HTTP-based client operating on a client or server device coupled to the network 208.
  • the data file may comprise any FTP or HTTP-based client operating on a client or server device coupled to the network 208.
  • the network 206 may include application, text, audio, video or graphic data.
  • the network 208 may be a Local Area Network (LAN), a Wide Area Network (WAN) or the
  • the communications server 210 includes a storage facility 212.
  • the data file 206 is shown to be propagated from the source 204, and stored within a user domain 214 of the storage facility 212 that is associated with, or "owned” by, the source 204.
  • Other sectors of the storage facility 212 may be associated with, or be owned by, other participants within the communications system 202.
  • the storage facility 212 is also shown to be divided by concentric rings that represent conceptual tiers of access privilege within which a data file may be stored within the communications server 210.
  • a single copy of the data file 206 received at the communications server 210 is stored at an appropriate location (i.e., within an owned sector) of the storage facility 212.
  • the communications server 210 is then shown to propagate unique access keys 218, via the network 208, to multiple targets 220 identified by the source 204 targeted recipients of the data file 206.
  • Each of the targets 220 may again comprise a client-based e-mail application program executing on a client device, or may comprise a web-based e-mail account.
  • Each of the access keys 218 is embedded within an e-mail message transmitted from the communications server 210 to each of the targets 220.
  • the access keys each comprise a Uniform Resource Indicator (URI) embedded within a hypertext document that provides a hypertext link from each respective target 220 to a location on the communications server 210 at which the data file 206 is stored.
  • URI Uniform Resource Indicator
  • each access key 218 may be a location description of a location on the communications server 210, accessible via the network 208, at which the data file 206 is stored.
  • the access key may be a pointer (e.g., embedded within a markup language document) to a "plugin" application, which is automatically downloaded and provides access to the data file 206.
  • Each access key 218 transmitted to each target 220 is unique to the respective target 220, and accordingly provides a mechanism by which the communications server 210 may monitor and /or control access to the data file 206 by a target 220. Specifically, as each access key 218 identifies the target 220, the communications server 210 may intelligently implement constraints on the access privileges of the relevant target 220.
  • the communication system 202 illustrated in Figure 2A may be utilized to provide access to the data file 206 by targets 220 that do not own capacity (storage or otherwise) provided by the communications server 210. (i.e., do not have a user domain provided by the server 210).
  • Figure 2B is a diagrammatic representation of an alternative embodiment of the communication system 202, wherein each of the targets 220 has been allocated capacity (e.g., a user domain) within the communications server 210.
  • each of the targets 220 may be allocated a sector of the storage facility 212 that is accessible by the respective target 220 via the network 208.
  • a respective and unique access key 218 is generated within the communications server 210 for each target 220.
  • the communications server 210 then stores each of the access keys 218 that are associated with, and owned by, the relevant targets 220. Accordingly, each of the targets 220 is able to access an appropriate access key 218 that is now stored within a sector of the storage facility 212 accessible only to the relevant target 220. As with the embodiment described above in reference to Figure 2A, each access key 218 provides a unique link to the data file 206, utilizing which a target 220 can access the data file 206 via the network 208.
  • each access key 218 is unique, the communications server 210 is able to monitor and impose constraints on access by any particular target 220.
  • the source 204 may define such constraints to be placed on access to a data file 206 by any particular target.
  • FIG. 3A is a diagrammatic representation of network-based communications system 302, according to an exemplary embodiment of the present invention, showing system-level architectural details.
  • the system 302 includes a number of clients 304 that are coupled via a network 306 to a data communications system 308.
  • Each of the clients 304 may be a source or a target of a data file 206 that is communicated utilizing the data communications system 308.
  • a client 304 may be a browser 310 having an embedded messaging client 312 that facilitates interaction and communication with the data communications system 308.
  • a messaging client 312 may be a companion program, or "plugin", to a browser 310 or an e-mail client program (e.g., MS Outlook).
  • the messaging client 312 may be a stand-alone application
  • FIG. 4 is a block diagram illustrating further architectural details of a messaging client 312, according to an exemplary embodiment of the present invention.
  • the messaging client 312 is shown to include driver access logic 316 that facilitates access by the messaging client 312 to device drive programs that may control various hardware devices coupled to a computer system on which the messaging client 312 is executing.
  • the driver access logic 316 may interact with a microphone device driver program to provide audio data, inputted by the microphone, to the messaging client 312.
  • the driver access logic 316 may interact with a device driver program controlling a digital camera so as to provide video data to the messaging client 312.
  • the messaging client 312 has a media processing layer 318 that comprises software for processing media data received from the driver access logic 316.
  • the media processing layer 318 may include TrueSpeechTM compression and decompression technology developed by the DSP Group, Incorporated of Santa Clara, California, RealAudio compression and decompression technology developed by RealNetworks, Incorporated, of Seattle, Washington, or ToolVox compression and decompression technology developed by Vox Ware, Incorporated of Princeton, New Jersey.
  • the media processing layer 318 operates to compress and encode data propagated from the messaging client 312, via a communications interface 320, to the data communications system 308. Similarly, the media processing layer 318 decompresses and decodes data received at the messaging client 312, via the communications interface 320, from the data communications system 308.
  • the media processing layer 318 also operates to stream data from the messaging client 312, via the communications interface 320, to the data communications system 308.
  • the media processing layer 318 may include RealVideo or RealAudio technology (that may operate without an HTTP server) developed by RealNetworks, or VivoActiv technology developed by Vivo Software Incorporated (now acquired by RealNetworks, Incorporated).
  • the media processing layer 318 also functions to receive streamed data from a server, such as a media server within the data communications system 308.
  • the media processing layer 318 is shown to be incorporated within the messaging client 312, components of the layer 318 may in fact be incorporated within a browser or an operating system of a computer system, and accordingly leveraged by the messaging client 312.
  • the Windows ® Operating System developed by Microsoft Corporation incorporates TrueSpeechTM technology that may be utilized by the media processing layer 318 of a messaging client 312. Further details regarding the streaming of data from the messaging client 312 are provided below.
  • the communications interface 320 implements both HTTP client and server functionality, and accordingly allows the messaging client 312 to communicate with the data communications system 308 utilizing the HTTP protocol.
  • a web server 330 generates web pages for viewing on a browser 310 and facilitates access to the data communications system 308.
  • T e web server 330 may be the Compass Server developed by Netscape Communications of Mountain View, California or the IIS web server developed by Microsoft Corporation.
  • Access control logic 332, which in an exemplary embodiment of the invention comprises a Common Gateway Interface (CGI) script, controls access to a SQL server 334 and a media server 336.
  • CGI Common Gateway Interface
  • FIG. 5 is a block diagram providing further architectural details regarding the access control logic 332.
  • the access control logic 332 is shown to include access key creation logic 500 that generates unique access keys 218, such as those discussed above with reference to Figures 2A and 2B for propagation to designated targets of a data file 206.
  • the access keys 218 created by the access key creation logic 500, and associated constraints specified by a source user, are communicated to the SQL server 334 for storage in tables 338 maintained within a database 340 by the SQL server 334.
  • Access key verification logic 502 operates to (1) control access to a data file 206 by designated targets 220 and to (2) ensure compliance with constraints imposed upon such access. Accordingly, the access key verification logic 502 examines the tables 338, as will be described in further detail below, with a view to verifying access privileges and to determine access constraints.
  • Data file identification logic 504 also accesses the tables 338 maintained by the SQL server 334 within the databases 340 for the purpose of identifying a data file 206 associated with a specific access key 218. Once the location of a data file has been determined by accessing the tables 338, the data file identification logic 504 communicates with the media server 336 to supply the relevant data file, which may be stored in a media database 342, to an appropriate messaging client 312.
  • the SQL server 334 may be a Database Management System (DBMS), such as that provided by Sybase Incorporated of Emeryville, California, Informix Corporation of Redwood City, California, or Microsoft Corporation.
  • DBMS Database Management System
  • the SQL server 334 is responsible for maintaining the tables 338 as a relational database.
  • FIG. 6 illustrates exemplary tables 338 that may be maintained within the database 340.
  • the tables 338 are shown to include an access key table 602 that maintains a record of each access key generated by the access key creation logic 500 of the access control logic 332, a transaction table 604 that maintains a record for each access transaction to a data file 206 stored within the media database 342, and a subscriber table 606 that maintains a record for each user (e.g., a target or a source user) that has been involved in a communications transaction via the data communications system 308.
  • the subscriber table 606 may contain records for both registered and unregistered source and target users.
  • the access key table 602 is shown to include the following columns:
  • a "key" column 608 that contains a primary key for each record within the access key table 602;
  • a "to" column 610 that stores a key referencing a source user from which a data file 206, to which the relevant access key pertains, was received;
  • a "from" column 611 which contains a key referencing an entry within the subscriber table 606 containing the details of a target identified by the relevant source user as a target for the data file 206 to which the access key pertains;
  • a "data file location” column 612 which contains a pointer to a location within the media database 342, at which the data file 206 to which the relevant access key pertains;
  • An "access constraints" column 614 that stores data specifying access constraints particular to the relevant access key.
  • an access key 218 may have time constraints associated therewith (e.g., the relevant data file may only be accessed for a certain period following a first access or during specific hours) or a "number of accesses" constraint that specifies the number of times the relevant data file may be accessed by the target user.
  • the transaction table 604 includes the following columns:
  • a "key" column 616 containing a unique primary key for each record within the transaction table 604;
  • the subscriber table 606 includes the following columns:
  • a "key” column 630 storing a unique primary key for each record stored within the subscriber table 606;
  • a "name” column 632 that stores the actual name for each subscriber
  • An "email" column 634 that stores an e-mail address for each subscriber
  • IP address An "Internet Protocol (IP) address" column 636 that stores an IP address for a subscriber, when available;
  • An "access privilege" column 638 may record access privileges specific to a subscriber. For example, depending upon whether the subscriber is registered or unregistered, paying or unpaying, the subscriber may be granted access to varying degrees of service and functionality within the data communications system 308. For example, a non-paying subscriber may only be provided with access to audio files stored within the media database 342, whereas a paying subscriber may be provided access to both audio and video files stored in the media database 342.
  • a "registered /unregistered" column 640 that records whether the subscriber is registered or unregistered within the data communications system 378. For example, where a subscriber record is created as a result of a user being designated as a target user, the subscriber record for the relevant target user will identify the subscriber as being unregistered within the data communications system 308. However, in order to access a data file maintained within the data communications system 308, the unregistered target subscriber may be required to register, in which case the relevant record for the subscriber will be updated within the subscriber table 606.
  • the media server 336 is shown to be coupled to the media database 342, and to output data files stored within the media database 342 on request from the SQL server 334.
  • the media server 36 may comprise a TrueSpeech-enabled streaming media server from the DSP Group, Incorporated or a RealAudio /RealVideo media server from RealNetworks, Incorporation.
  • the media database 342 is shown to store inter alia, audio files 350, video files 352, document files 354 and e-mail files 356.
  • the files 350-356 will, for the purposes of the present specification, be deemed to comprise non- exhaustive examples of what is understood to comprise "data files”.
  • any one of the files 350-356 may be communicated to a target user.
  • the audio files 350 may be midi wave, RA (RealAudio), AU or TSP (TrueSpeech) formatted audio files.
  • the video files 352 may be MPEG, AVI, MOV or VTv 7 formatted video files.
  • the media server 336 may be able to both download and upload any one, or all, files of such format.
  • FIG. 3B is a diagrammatic representation of a data communications system 302, according to an alternative embodiment of the present invention, within which the data communications system 308 has an alternative architecture.
  • the web server 330 is shown to be coupled to a central media server 360 that is controlled by the access control logic 332.
  • the central media server 360 is coupled to the SQL server 334, as well as a number of dedicated media servers 362-368.
  • Each of the media servers 362-368 is dedicated to providing access to, and maintaining, storing and retrieving a particular type of data file 206.
  • the media server 362 maintains and controls an audio media database 363 storing audio files 350.
  • the video media server 364 maintains and controls a video media database 365 that stores video files 352.
  • a document media server 366 maintains and controls media database 367 that stores document files 354.
  • An e-mail server 368 maintains and controls an e-mail database 369 that stores e-mail files 356.
  • the architecture of the data communications system 308 illustrated in Figure 3B comprises a distributed server arrangement, whereas the architecture of the data communications system 308 shown in Figure 3A provides a more centralized or consolidated server architecture.
  • Methodology - Transmission of a Data File From a Source User to a Target User Figure 7 is a flow chart illustrating a method 700, according to an exemplary embodiment of the present invention, of communicating a data file 206 from a source user 102 within a data communications environment to a target user 106. While the method 700 will be described within the context of the communications system 302 described above with reference to Figures 3A and 3B, it will be appreciated that the method 700 is not limited to this communications environment.
  • the method 700 commences at block 702 at which a source user 102 downloads a data file 206 to a personal user domain within the data communications system 308.
  • a source user may be provided with a predetermined storage capacity (e.g., 10 MB) within the database 342 within which to store data files 206 that the user wishes to communicate.
  • the downloading of the source user is performed by the messaging client 312 and, in one embodiment, may comprise streaming a data file 206 from the messaging client 312 to the media server 336, via the web server 330.
  • the source user may generate an audio (or voice) file that is dynamically streamed by the messaging client 312 to the data communications system 308 for storage by the media server 336 within the database 342.
  • the messaging client 312 utilizing the driver access logic 316 may capture audio data inputted via a microphone. The captured audio data will then be encoded and compressed within the media processing layer 318, before being streamed via the communications interface 320 to the media server 336.
  • the data file 206 to be sent from the messaging client 312 to the media server 336 may be completely constructed and stored on a computer system before being downloaded as a complete file to the media server 336.
  • the data file 206 is an audio or video file
  • all data for the file may be recorded, and then encoded and compressed by the media processing layer 318, to construct a complete data file 206.
  • This complete data file 206 may then be sent from a messaging client 312 to the media server 336.
  • the data file 206 is a document file (e.g., word processor document, e-mail message, spread sheet document or the like)
  • the complete file may be retrieved from a storage location within a computer system by the messaging client 312, and propagated to the media server 336.
  • the source user identifies target recipients for the relevant data file 206 by, merely for example, supplying e-mail addresses to the data communications system 308.
  • the source user may provide a proprietary designation internal to the data communications system 308 for the purposes of identifying target recipients of the data file 206. It will be appreciated that blocks 702 and 704 may be performed in any order, and that the source user may identify the target recipients before, or concurrently with, or after, downloading of the data file 206 to the personal domain of the source user within the data communications system 308.
  • access constraints may include time constraints (e.g., times or days at which the data file 206 may accessed by a particular target recipient) or a number of access constraints specifying the number of times the target recipient may access these files.
  • time constraints e.g., times or days at which the data file 206 may accessed by a particular target recipient
  • access constraints may be specified by the source user, or may be automatically generated by the access key creation logic 500 of the access control logic 332 according to default constraint specifications.
  • the access key creation logic 500 may specify that a data file 206 should be accessed within one month, failing which the relevant data file 206 will no longer be available for access by a particular target recipient.
  • the access control logic 332 may optionally purge the relevant data file 206 from the data communications system 308. Again, block 706 may be performed in any order with respect to blocks 702 and 704.
  • the access key creation logic 500 within the access control logic 332 proceeds to create a unique access key for each designated target recipient of the data file. Specifically, the access key creation logic 500 creates an entry within the access key table 602 that identifies the source user, the target user, a data file location on the media database 342 at which the relevant data file is stored, and the access constraints that were defined at block 706. To this end, the data file identification logic 504 communicates with the media server 336 with a view to determining the file location at which the relevant data file 206 is stored on the media database 342.
  • the access control logic 332 proceeds to communicate the unique access key 218 to each target recipient.
  • this may comprise propagating an e-mail including a hypertext link, which functions as the access key, to the data file 206 to a client-based e-mail application or a web-based e-mail account of the target user, and identified by e-mail addresses provided at block 704.
  • An example of an e-mail message including such a hypertext link is provided below:
  • the access key 218 may comprise an object tag embedded with a markup language document (e.g., a HTML or XML document) that (1) identifies a "plugin" object or application that is automatically uploaded by an e-mail or browser and (2) provides values to the object that identify a target data file 206 and verify access to the data file 206.
  • a markup language document e.g., a HTML or XML document
  • the embedded tag may be viewed as the access key 218. Examples of tags that may be embedded within a markup language document are provided below:
  • a unique access key communication is described above with reference to Figure 2A.
  • the unique access key for each such target recipient may be stored within a personal user domain for each target recipient within the data communications system 308 itself. This method of access key distribution is illustrated in Figure 2B.
  • the method 700 then terminates at block 716.
  • Figure 8 is a flow chart illustrating a method 800, according to an exemplary embodiment of the present invention, by which a designated target recipient of a data file may access and, if required, retrieve the data file 206 within the data communications system 308.
  • the target recipient receives a unique access key, generated in the manner described with reference to Figure 7. If the target user receives the unique access key at a location outside the data communications system 308; the target recipient will access the data communications system 308 at block 804 by, for example, user-selecting a URL that comprises the unique access key, embedded within an HTML document of a received e-mail message.
  • the HTML document may specify a plugin application that is automatically retrieve (or activated if already retrieved) to access the data communication system 308.
  • the target recipient provides a unique access key to the data communications system 308, and specifically to the access control logic 332, at block 810. Specifically, in one embodiment, the messaging client 312 may communicate the access key to the data communications system 308.
  • the access key verification logic 502 within the access control logic 332 references the access key table 602 within the tables 338 to identify the data file 206 and to determine constraints associated with the unique key. To this end, the access key verification logic 502 may issue a SQL query to the SQL server 334 for this information pertaining to the unique access key.
  • the access key verification logic 502 receives the data file location and access constraint information from the SQL server 334responsive to the SQL request, and determines whether any of the access constraints operate to block or restrict access by the target recipient to the relevant data file 206. For example, a predetermined access period may have expired, or the target recipient may have already accessed the data file a predetermined maximum number of times. Further, a "cookie", network address or other identification information may identify the target recipient as operating on a machine that is denied access to the data file.
  • the access key verification logic 502 determines whether the access constraints are determined by the access key verification logic 502 to be blocking at decision box 814. If the access constraints are determined by the access key verification logic 502 to be blocking at decision box 814, then the access transaction is terminated at block 816. Alternatively, at block 818, the access key verification logic 502 creates a new record within the transaction table 604 to record the details of the access transaction. Specifically, the created record records the primary key corresponding to the unique access key as stated in the access key table 602, as well as the date and time at which the relevant access transaction occurred.
  • the access key verification logic 502 may update various access parameters associated with the unique access key. For example, the logic 502 may decrement a count of the number of allowable accesses to the date file 206 by the recipient that are still permissible in terms of specified access constraints.
  • the access key verification logic 502 in combination with the data file identification logic 504, communicates with the media server 336 so as to establish a communications link between the messaging client 312 and the data file 206 referenced by the unique access key.
  • the target recipient may elect to upload the data file 206 from the data communications system 308 to the messaging client 312.
  • the media server 336 may stream the audio file to the messaging client 312, which will then decode and decompress the audio file in the media processing layer 318.
  • the audio file will be played over a speaker system of the target recipient's computer system.
  • the data file 206 comprises a data document, such as a word processing document
  • this may simply be uploaded to the messaging client 312 by the HTTP communications interface 320, and then made accessible to the target recipient on a computer system.
  • the method 800 then terminates at block 826.
  • An exemplary utilization of the data communications system 308 is as a voice or video messaging system whereby a source user, utilizing a messaging client 312, is able to deposit audio or video messages within a "mailbox" maintained for a target user within a personal domain in the data communications system 308.
  • An exemplary implementation of such a messaging system proposes that a so-called “message bar" be available for incorporation into web pages of a web site of an organization or individual. Utilizing these message bars, a source user wishing to communicate an audio or video message to a specific recipient associated with message bar may be able to deposit the relevant message in a mailbox within the data communications system 308.
  • Figure 9 illustrates an HTML document 900, according to an exemplary embodiment of the present invention, incorporated within a web site for an organization, the specific HTML document 900 containing company contact information 902.
  • the HTML document 900 includes a message bar 904, according to an exemplary embodiment of the present invention, that includes buttons that are user- selectable to perform various messaging functions, including sending an audio or video message to a mailbox for the company whose information is displayed at 902.
  • the message bar 904 is generated by a browser 310, which interprets appropriate message bar HTML code embedded within the HTML code underlying the HTML document 900 to generate the message bar 904.
  • the exemplary message bar 904 is shown to include two panels, namely an audio panel 906 and a video panel 908, each of which contain buttons for recording and sending respective audio and video messages from a source user computer system to the data communications system 308.
  • the audio and video panels 906 and 908 each include a "record” button 910 that is user- selectable to record a message, a "play” button 912 that is user-selectable to play a message that has been recorded, a "send” button 914 that is user-selectable to register a user's intention that the message be regarded as sent, a "fast forward” button 918 that is user-selectable to advance the play back of a message commenced responsive to a previous user-selection of the "play” button 912, a "rewind” 920 that is user-selectable to back-up the playback of a message responsive to a previous user-selection of the "play” button 912, and a "pause” button 922 that
  • the message bar 904 may be associated with a specific "mailbox" maintained within a personal user domain of the data communications system 308. Accordingly, the HTML code that presents the message bar 904 includes an identifier that is unique to a mailbox of an intended recipient.
  • messages propagated to the data communication system utilizing the message bar 904 shown in Figure 9 may be stored in a "mailbox" maintained within a personal domain of a target of the message within the data communications system 308.
  • a target of a data message may thus access the data communications system 308 from time to time with a view to ascertaining whether any messages have been deposited in a mailbox.
  • the data communications system 308 is accessed via the network 306 by a target.
  • the data communications system 308 may be accessible utilizing a URL that, when initially accessed by a target wishing to retrieve messages from a mailbox, presents the HTML document 1000, shown in Figure 10, that provides a login screen.
  • the HTML document 1000 includes a "username" field 1002 and a "password” field 1004, into which the target user enters an appropriate user name and password that is verified by the web server 330 to enable access by the target user to a mailbox.
  • a target user may be presented with a mailbox and messaging screen, an exemplary embodiment of which is shown in Figure 11, in the form of an HTML document 1100.
  • the document 1100 is shown to include three panels, namely a mailbox panel 1102, a message panel 1104 and a menu panel 1106.
  • the HTML document 1100 is dynamically generated by the web server 330 utilizing information obtained from the SQL server 334. Specifically, by querying the SQL server 334, the web server 330 may identify whether there are any access keys within the table 602 for which the target recipient is identified as a target. If such access keys exist within the access key table 602, such entries identify messages for the target recipient that may accordingly be listed within the mailbox panel 1102.
  • a graphical representation of a message e.g., a title displayed within the mailbox panel 1102
  • the relevant data file 206 that constitutes the message e.g., a text, video or audio data file
  • the target user furthermore has the option of sending a message utilizing the message panel 1104.
  • Figure 12 is a flow chart illustrating a method 1200, according to an exemplary embodiment of the present invention, of selling or distributing "message bars" (i.e., HTML code including a unique link to a mailbox) to customers or subscribers who utilize the data communications system 308.
  • "message bars" i.e., HTML code including a unique link to a mailbox
  • the method 1200 commences at block 1202 where a customer sets up an account with a communication system supplier that operates the data communications system 308.
  • the customer purchases a "message bar" in the form of, for example, HTML code that may be embedded within a web page operated by the customer and that contains a unique access code assigned to the purchaser.
  • the customer may purchase a unique access number (or code) that may be utilized by the customer to construct a personalized message bar that is user-selectable to cause a browser to issue the unique identifier to the web server 330 of the data communications system 308.
  • a unique access number or code
  • the customer may provide the communications system 308 with a domain name (e.g., www.yourdomain.com) for the server on which the web site for the customer will be hosted.
  • a domain name e.g., www.yourdomain.com
  • the communications systems supplier then provides the customer with either a sample page including HTML code, including a unique identifier, that may be embedded within the web page to generate the message bar 904, or alternatively the unique identifier that may be utilized by the customer to construct a personalized message bar.
  • the customer then creates a web page to be incorporated within their web site including the message bar code, or personalized code, including a link that will cause the unique identifier associated with the customer to be propagated to the web server 330 of the data communications system 308.
  • the message bar code is provided to the customer
  • user selection of, for example, the "record" button 910 of the message bar 904 will cause the unique identifier for the customer to be propagated to the data communication system 308, together with further information regarding the customer such as the domain name supplied at block 1206 and user name for the customer.
  • this communication may be a SET request in terms of the HTTP protocol.
  • the method 1200 then terminates at block 1212.
  • Figure 13 is a flow chart detailing a method 1300, according to an exemplary embodiment of the present invention, by which a source user may send a message (e.g., an audio or video message) to a target user utilizing the data communications system 308 of the present invention.
  • the method 1300 commences at block 1302 with a source user accessing a web page of a web site including a message bar.
  • a source user may access a web page similar to that shown in Figure 9.
  • a messaging client 312 for example in the form of a Java applet or an ActiveX control, is automatically downloaded to the client machine on which a web browser utilized to access the web page is executing.
  • the source user selects an icon presented within the message bar 904, (e.g., the "record” button 910).
  • the messaging client 312 communicates the unique identifier (associated with the customer) to the communications system 308 and requests a unique access key from the communications system 308, and specifically from the access control logic 332.
  • the unique access key may be derived, at least partially, from the unique identifier.
  • the communications system 308 provides a unique access key to the messaging client responsive to the request issued at block 1308. Receipt of the unique access key serves to establish a connection between the communications system 308 and the messaging client 312 at block 1312.
  • the messaging client 312 commences recording a data file 206, in the manner described above, which is then encoded, compressed and transmitted, (e.g., streamed), from the messaging client 312 hosted on the client's machine to the communications system 308, as indicated at block 1314.
  • the received data file 206 is processed in the manner described above by the media server 336 and stored within the media database 342.
  • the unique access key generated by the access control logic 332 (and propagated to the messaging client at block 1310) is utilized to create a record within the access key table 602.
  • the source user may optionally provide return information to the data communication system 308 to enable the target user to respond to the source user.
  • the access control logic 332 may furthermore send a confirmation message to the source user confirming that the data file 206 has been received within the media database 342.
  • the confirmation message may be propagated to an address indicated within the return information provided at block 1316. The method 1300 then terminates at block 1320.
  • FIG 14 is a flow chart detailing a method 1400, according to an exemplary embodiment of the present invention, by which a user may interact with a message bar 904 and a messaging client 312 to record and stream a data file (e.g., an audio file) to the data communications system 308.
  • the method 1400 commences at block 1402 with a source user selection of the "record" button 910 presented within the message bar 904.
  • the driver access logic 316 of the messaging client 312 initiates recording of audio data via a microphone coupled to a computer system on which the messaging client 312 is executing.
  • the messaging client 312 initiates recording of video data via a video camera (or recorder) coupled to the computer system.
  • the media processing layer 318 of the messaging client 312 receives a stream of audio data from the driver access logic 316, and begins to perform three concurrent operations. Specifically, the media-processing layer 318 then encodes and compresses the received stream of audio data.
  • the media processing layer 318 may leverage compression and decompression software, such as TrueSpeechTM technology, incorporated within an operating system of the computer system on which the messaging client 312 is executing.
  • the media processing layer 318 also proceeds to stream the encoded and compressed audio data, via the communications interface 320, over the network 306 to the data communications system 308.
  • the received stream of audio data is fed to the media server 336, which constructs an audio file within the media database 342.
  • the media processing layer 318 also proceeds to store a local copy of the encoded and compressed audio data on the computer system on which the messaging client 312 is executing.
  • the local copy of the audio data is useful for facilitating play back and editing capabilities with respect to the audio data.
  • the local copy of the audio data is stored as a temporary file by the operating system of a computer system on which the messaging client 312 is executing.
  • the messaging client 312 establishes a buffer (e.g., 400 KB) of disk space, this buffer being used to both record new messages, and to store retrieved messages for playback purposes.
  • the utilization of the buffer avoids the need to cache separate files, and may accordingly be no temporary files need be created. There would thus be no large audio or video data files within, for example, a browser's cache directories that would need to be deleted in a house cleaning operation.
  • the method 1400 proceeds to decision box 1416, where a determination is made as to whether a user has selected the "play" button 912. If so, at block 1418, the local copy of the compressed and encoded audio data is replayed utilizing the messaging client 312. Alternatively, a determination is made at decision box 1420 whether the user has again selected the "record" button 910, this indicating that the user wishes to proceed with further recording of audio data to be included within a final audio data file. Following a positive determination at decision box 1420, the method 1400 accordingly loops back to block 1404. Alternatively, should no user selection of the "record" button 910 be detected, the method 1400 loops back to decision box 1412.
  • buttons 918 and 920 may be user selected following user selection of the "play" button 912 to either advance or retreat a current replay of the stored local copy of the audio data. While the above description has described an audio data file for the purposes of illustration, it will be appreciated that the data file could comprise any type of data file (e.g., video, still photograph, text, alphanumeric, an application program, etc.)
  • FIG. 15 is a flow chart detailing a method 1500, according to an exemplary embodiment of the present invention, by which a customer, or target user, may view and optionally retrieve data files, from the data communications system 308, for which the customer has been designated as a target as a source.
  • the method 1500 commences at block 1502, with the customer logging into an account, or user domain, maintained within the data communications system 308. This may be done via, merely or example, the login screen illustrated in Figure 10.
  • the data communications system 308 generates a unique set of URIs for all messages in a customer's message space, or mailbox, maintained by the data communications system 308.
  • any of these URIs may be embedded within an HTML document generated by the web server 330.
  • An example of such an HTML document is illustrated in Figure 11.
  • the generation of the unique URIs for each of the respective messages in the customer's message space may be generated by the access control logic 332 utilizing information retrieved from the access key table 602 within the tables 338. Specifically, the access control logic 332 may issue a number of SQL queries to the SQL server 334 for the purpose of obtaining this information. The access control logic 332 then constructs a unique identifier associated with each message for the logged-in customer. Each of these unique identifiers is communicated to the web server 330 that constructs a web page including hypertext linked URIs that correspond to, or incorporate, the unique access numbers retrieved by the access control logic 332.
  • the logged-in customer may then elect to retrieve or play a message identified by a unique URI by, for example, clicking on a hypertext link associated with the URI.
  • the selected URI is propagated from a client machine to the data communications system 308.
  • the data communications system 308 propagates the data file 206 identified by the unique access key embedded within the URI to the client machine.
  • the media server 336 may stream the relevant data file 206 to the messaging client 312.
  • the identification of the appropriate data file 206 upon receipt of the URI is performed by the data file identification logic 504 within the access control logic 332.
  • the logic 504 may perform a table lookup operation with respect to the access key table 602 to determine a data file location, as recorded within the data file location column 612. Having so determined the location of the data file 206, the access control logic 332 will then issue an appropriate command to the media server 336 to commence the streaming operation of the data file 206 from the media server 336.
  • any further customer requests pertaining to the data file 206 are detected.
  • the customer may elect to delete, forward or append to the data file 206 to a further communication within, or issued from, the data communications system 308. If such a further customer request is detected, the data communications system 308 services the appropriate request at block 1514. Following a negative determination at decision box 1512, or following completion of block 1514, the user will then logout at block 1516, following which the method 1500 terminates at block 1518.
  • Figure 16 is a flow chart detaining a method 1600 whereby a source user may stream data (e.g., text, audio or video data) from the messaging client 312 to the data communications system 308. It will be appreciated that, for this operation, the messaging client 312 assumes a streaming server function within a client/server paradigm.
  • the source user may access a web page, such as that shown in Figure 9, that includes a message bar 904.
  • the message bar 904 includes hypertext links, text or icons (e.g., the "record" button 910) that embody URIs including the identifiers or access keys for respective data files 206.
  • the messaging client 312 is downloaded to the source user machine. This download is performed automatically responsive to the accessing of the web page.
  • the source user may then select the "record" button 910 on the message bar 904.
  • the messaging client 312 requests a unique file key identifier 1711 from the data communications system 308.
  • the access control logic 332 will generate a unique file identifier 1711 that will be utilized to identify an eventual complete audio file generated utilizing the messaging client 312.
  • the unique file identifier is propagated from the data communications system 308 to the messaging client at block 1610. Receipt of the unique file identifier by the messaging client serves to establish and confirm a connection between the messaging client 312 and the data communications system 308 at block 1612.
  • the messaging client 312 specifically the driver access logic 316 and the media processing layer 318, proceed to capture, encode and compress audio data inputted into the computer system on which the messaging client 312 is executing.
  • the media processing layer 318 proceeds to identify the first of a sequence of three-second time interval of the received voice data.
  • a specified three-second interval may or may not contain audio data, depending on whether audio data is inputted into the computer system and received by the messaging client 312 during the relevant three- second increment.
  • the media processing layer 318 is shown in Figure 4 to include timer logic 319 that may be utilized for the identification of successive three-second intervals.
  • the media processing layer 318 attaches the unique file identifier to the three-second interval of audio data as a header.
  • the three- second interval audio data and the header are then sent to the communications interface 320 that, in one exemplary embodiment, encapsulates the three-second interval of audio data and the header as an HTTP packet that is then propagated from the messaging client 312 to the data communications system 308.
  • the media processing layer 318 attaches the same file identifier (as a header) to each successive three-second interval of audio data of a single transmission or recording. This is to enable the media server 336, in the data communications system 308, to identify the packets belonging to a common recording, and to thereby reconstruct a complete data file.
  • a continuous and uninterrupted stream may be communicated from the messaging client 312 to the data communications system 308.
  • the data communications system 308 receives the three- second interval (or continuous stream) of audio data, and associated file identifiers 1711, as HTTP packets.
  • the web server 330 encapsulates the audio data and associated file identifiers 1711, and communicates this information to the media server 336.
  • the media server 336 then utilizes the file identifiers 1711 to identify three-second intervals of audio data belonging to a common recording.
  • the communications interface 320 may include an ordering number (or indication) within the header associated with each three-second interval.
  • the data communications system 308 Upon user selection of the "send" button 914 on the message bar 904, the data communications system 308 will be advised that the recording is complete, and the media server 336 may then proceed to construct a complete and verified audio file, as detailed above with reference to block 1411 shown in Figure 14.
  • the media processing layer 318 detects whether further audio data is being received subsequent to the elapsing of a specific three-second interval. If so, the method 1600 loops back to block 1616. Alternatively, a determination is made at decision box 1624 as to whether ten seconds have elapsed since audio data was last received by the media-processing layer 318. If not, the method 1600 loops back to decision box 1622. If on the other hand, ten seconds have lapsed since the last audio data was received, the messaging client 312 stops recording at block 1626, whereafter the method 1600 terminates at block 1628.
  • method 1600 accordingly provides for the concurrent recording, storing and streaming of audio data by the messaging client, and that the "send" operation performed by the user serves merely as a conformation of the recording or streamed transmission.
  • Figure 17 is a block diagram providing a diagrammatic representation of the audio data capture and streaming operation described above with reference to Figure 16.
  • the messaging client 312 is shown to receive audio data from an audio capture device 1700 whose operation is controlled via the driver access logic 316.
  • the audio data is fed from the audio capture device 1700 to the media processing layer 318 of the messaging client 312, that performs the operations to encode, compress and time-divide the stream of audio data as described above.
  • the media processing layer 318 is shown to feed the encoded and compressed audio data to (1) the communications interface 320, for encapsulation and propagation of the data communications system 308, and (2) to a local storage device 1702, where a local copy 1704 of the compressed and encoded audio data is maintained for replay and editing purposes.
  • the communications interface 320 is shown to transmit a sequence of HTTP packets 1706 to the data communications system 308.
  • Each HTTP packet 1706 is also shown to include a header portion 1708 that includes the file identifier 1711 propagated to the messaging client 312 at block 1610 and a data portion 1710.
  • the data portion 1710 includes the compressed and encoded voice data.
  • the three-second recorded time interval included within a packet 1706 may not be filled with voice data, as silence intervals may have occurred as a result of the audio input being interrupted, as a result of the user pausing in delivery of the audio, or as a result of errors in the propagation of the audio data from the audio capture device to the messaging client 312.
  • Figure 18 is a block diagram that illustrates the utilization of the file identifier 1711 within the header 1708 associated with each three-second interval of voice data propagated from a messaging client 312.
  • Figure 18 illustrates first and second messaging clients 312 operating on respective client machines and propagating respective streams 1705 of HTTP-encapsulated audio data via the network 306 to the media server 336.
  • the media server 336 will receive a continuous stream of three-second intervals of voice data that may have originated from multiple messaging clients 312. Accordingly, it is required that the media server 336 be able to differentiate between received intervals of audio data for the purposes of reconstructing audio files 1804 and 1806 from the data received from the respective messaging clients 312.
  • the media server 336 examines the file identifier 1711 associated with each interval of audio data, and accordingly writes the relevant interval of audio data file within the database 342 identified by the relevant file identifier 1711.
  • Figure 19 is a diagrammatic representation of a machine in exemplary form of a computer system 1900 within which a set of instructions for causing the machine to perform any one of the methodologies discussed above may be executed.
  • the machine may comprise any device capable of executing a sequence of instructions such as, for example, a Personal Digital Assistant (PDA), a cellular (or mobile) telephone or a network appliance.
  • PDA Personal Digital Assistant
  • the computer system 1900 may, for example, operate as a client machine, on which a messaging client 312 executes or as a server machine hosting any one of the web servers, SQL servers, media servers or access control logic discussed above.
  • the computer system 1900 includes a processor 1902, a main memory 1904 and a static memory 1906 that communicate with each other, and other components of the system, via a systems bus 1908.
  • the computer system 1900 is furthermore shown to include a video display unit 1910 (e.g. a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT)).
  • the computer system 1900 also includes an alphanumeric input device 1912, (e.g., a keyboard), a cursor control device 1914 (e.g., a mouse), a disk drive unit 1916, a signal generation device 1918, (e.g., a speaker system) and a network interface device 1920.
  • a video display unit 1910 e.g. a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT)
  • the computer system 1900 also includes an alphanumeric input device 1912, (e.g., a keyboard), a cursor control device 1914 (e.g., a mouse), a disk
  • the disk drive unit 1916 includes a machine-readable medium 1922 on which is stored a set of instructions (i.e., software) 1924 embodying any one, or all, of the methodologies discussed above.
  • the software 1924 is also shown to reside, completely or at least partially within the main memory 1904 and/or within the processor 1902.
  • the software 1924 may furthermore be transmitted from, or received at, the computer system 1900 via the network interface device 1920.
  • machine-readable shall be taken to include any medium that is capable of storing, or communicating, a sequence of instructions for execution by a machine and causes any machine to perform any one of the methodologies of the present invention. Accordingly, the term “machine-readable medium” shall be taken to include, but not be limited to, solid state memories, optical and magnetic disks, magnetic-optical disk, DC-ROMs, ROMs, RAMs, EPROMs, EEPROMs, flash memory and carrier wave signals.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Communication Control (AREA)

Abstract

Selon cette invention, un procédé pour communiquer en continu des données (p.ex., des données vidéo et audio) à travers un réseau (p.ex., l'Internet) consiste en premier lieu en la réception d'une entrée de données par un client messagerie (p.ex., une appliquette Java) qui tourne sur une machine cliente. En parallèle à la réception d'une entrée de données, le client messagerie fournit en continu à travers le réseau une sortie de données, ladite sortie de données étant dérivée à partir de l'entrée de données. Une fois que l'utilisateur a terminé l'entrée (p.ex., en arrivant à la fin d'un message vocal), il sélectionne une option 'envoi' qui envoie une indication de confirmation depuis le client messagerie vers un système de stockage, qui a déjà reçu la sortie des données envoyées en continu. En réponse à l'indication de confirmation, le système de stockage valide un fichier de données construit au moyen de la sortie des données envoyées en continu depuis le client messagerie. Cela permet, par exemple, d'envoyer en continu des données audio depuis le client messagerie en y introduisant en parallèle des entrées audio et de le confirmer simplement au moyen de la sélection par l'utilisateur de l'option 'envoi'.
PCT/US2000/005842 1999-03-02 2000-03-02 Procede et appareil pour communiquer des donnees au moyen d'un systeme de communication base sur le web WO2000052898A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU35145/00A AU3514500A (en) 1999-03-02 2000-03-02 Method and apparatus for implementing data communications via a web-based communications system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12257299P 1999-03-02 1999-03-02
US60/122,572 1999-03-02

Publications (3)

Publication Number Publication Date
WO2000052898A2 WO2000052898A2 (fr) 2000-09-08
WO2000052898A3 WO2000052898A3 (fr) 2001-06-07
WO2000052898A9 true WO2000052898A9 (fr) 2001-08-30

Family

ID=22403499

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/005842 WO2000052898A2 (fr) 1999-03-02 2000-03-02 Procede et appareil pour communiquer des donnees au moyen d'un systeme de communication base sur le web

Country Status (2)

Country Link
AU (1) AU3514500A (fr)
WO (1) WO2000052898A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL135598A0 (en) * 1999-06-02 2001-05-20 Ibm Method and apparatus for accessing a telephony voice-mail system from a terminal using a standard web browser
GB0110542D0 (en) 2001-04-30 2001-06-20 Nokia Corp Messaging system
FR2847752B1 (fr) * 2002-11-27 2006-01-13 At & T Corp Methode et systeme pour gerer l'echange de fichiers joints a des courriers electroniques

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5351276A (en) * 1991-02-11 1994-09-27 Simpact Associates, Inc. Digital/audio interactive communication network
EP0701373B1 (fr) * 1994-09-08 2000-02-23 International Business Machines Corporation Système de serveur vidéo
US5907837A (en) * 1995-07-17 1999-05-25 Microsoft Corporation Information retrieval system in an on-line network including separate content and layout of published titles
US5862220A (en) * 1996-06-03 1999-01-19 Webtv Networks, Inc. Method and apparatus for using network address information to improve the performance of network transactions
US5918013A (en) * 1996-06-03 1999-06-29 Webtv Networks, Inc. Method of transcoding documents in a network environment using a proxy server
EP0974217A2 (fr) * 1996-11-25 2000-01-26 Hyperlock Technologies, Inc. Procede permettant de proteger par verrouillage la gestion serveur sur des supports locaux avec utilisation d'un reseau assurant l'acces local instantane aux donnees cryptees des supports locaux
US6038601A (en) * 1997-07-21 2000-03-14 Tibco, Inc. Method and apparatus for storing and delivering documents on the internet

Also Published As

Publication number Publication date
AU3514500A (en) 2000-09-21
WO2000052898A3 (fr) 2001-06-07
WO2000052898A2 (fr) 2000-09-08

Similar Documents

Publication Publication Date Title
US9807201B2 (en) Information delivery system for generating a data stream with a server system based on a content file received from a client device
JP3762649B2 (ja) 資産管理及びメディア・ストリーマのスケジューリング・グラフィカル・ユーザ・インタフェース
US6584466B1 (en) Internet document management system and methods
US6963910B1 (en) Graphical user interface for creating assets
US20020147687A1 (en) Method and computer system for program recording service
US7117259B1 (en) Server time window for multiple selectable servers in a graphical user interface
US8566410B2 (en) Automated system and method for delivery of messages and processing of message responses
US20060265477A1 (en) Method and apparatus for creating and posting media
US20020076004A1 (en) System using a personal digital assistant to redirect a voice message to a telephone
WO2008134320A1 (fr) Procédé et système pour se lier à un contenu et à des services pour un dispositif de communication
WO2007120257A2 (fr) Moyen de stockage de contenu à distance pour téléphones mobiles
US20010054089A1 (en) System and method for providing a guided tour of a web site
US20030009439A1 (en) Family tree website architecture
US20040098368A1 (en) Data storage system
JP2879547B2 (ja) 電子メールシステムおよび電子メールの処理方法
WO2001014981A1 (fr) Systeme et procede permettant de fournir la livraison d'un contenu audio/video sur un reseau
WO2000052898A9 (fr) Procede et appareil pour communiquer des donnees au moyen d'un systeme de communication base sur le web
US20090097620A1 (en) System and Method for Processing Voicemail Messages Remotely Over A Network Connection
US20100088401A1 (en) Method of transferring data being stored in a database
US20030023850A1 (en) Verifying messaging sessions by digital signatures of participants
KR100768153B1 (ko) 사용자 추진형 그룹 메시징 시스템 및 방법
KR20000049679A (ko) 인터넷을 이용한 메시지 시스템 및 그 방법
US20110066471A1 (en) Data matching and synchronization between two applications
WO2001011824A2 (fr) Procede et systeme d'echange vocal et de distribution vocale
EP1378134A1 (fr) Systeme de distribution de messages

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM 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 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 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 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)
WPC Withdrawal of priority claims after completion of the technical preparations for international publication
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM 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 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: A3

Designated state(s): GH GM KE LS MW 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 BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

AK Designated states

Kind code of ref document: C2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM 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 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: C2

Designated state(s): GH GM KE LS MW 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 BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGES 1/21-21/21, DRAWINGS, REPLACED BY NEW PAGES 1/21-21/21; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

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 DATED 02-12-02

122 Ep: pct application non-entry in european phase