WO2000052898A2

WO2000052898A2 - Method and apparatus for implementing data communications via a web-based communications system

Info

Publication number: WO2000052898A2
Application number: PCT/US2000/005842
Authority: WO
Inventors: Jon Louis; Mark R. Spowage; William Calvert Appleton
Original assignee: Message Bay, Inc.
Priority date: 1999-03-02
Filing date: 2000-03-02
Publication date: 2000-09-08
Also published as: WO2000052898A3; WO2000052898A9; AU3514500A

Abstract

A method of streaming data (e.g., video and audio data) over a network (e.g., the Internet) begins with the receipt of data input at a messaging client (e.g., a Java applet) executing on a client machine. Concurrently with the receipt of the data input, the messaging client streams data output over the network, the data output being derived from the data input. Once a user has completed an input (e.g., reach the end of a voice message), the user selects a 'send' option, which sends a confirmation indication from the messaging client to a storage system that has already received the streamed data output. The storage system then, responsive to the confirmation indication, validates a data file constructed utilizing the streamed data output of the messaging client. Thus, for example, audio data may be streamed from the messaging client concurrently with audio input thereto, and merely confirmed by user-selection of a 'send' option.

Description

METHOD AND APPARATUS FOR IMPLEMENTING DATA COMMUNICATIONS VIA A WEB-BASED COMMUNICATIONS SYSTEM

The present application claims priority from U.S. provisional patent application number 60/122,572 entitled "METHOD AND APPARATUS FOR IMPLEMENTING A DATA COMMUNICAΗONS SYSTEM VIA A WEB-BASED COMMUNICAΗONS HOST SERVER" filed March 2, 1999, and U.S. utility patent application entitled "METHOD AND APPARATUS FOR IMPLEMENTING DATA COMMUNICAΗONS VIA A WEB-BASED COMMUNICAΗONS SYSTEM" filed March 1, 2000.

FIELD OF THE INVENTION

The present invention relates generally to the field of data communications and, more specifically, to a method and apparatus for corrununicating data from a source to a target via a network-based communications system.

BACKGROUND OF THE INVENTION

The propagation of data files over networks, such as for example the

Internet, is most commonly performed in two ways. Specifically, 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). While these methods of communicating data files over a network of workable, they present a number of disadvantages (e.g., long waits for downloads to complete, unreliable download operations) where large data files are propagated. Furthermore, where a data file is propagated from a single source to multiple targets, inefficiencies in the propagation result from the duplication of the propagated data file to each of the multiple targets. Consider, for example, the prior art case illustrated in Figure 1 in which 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. In this case, 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. Further, for the target users 106 that have client e-mail applications executing on respective client machines, each target user 106 will store the received data file 104 on a local storage device. For each target user 106 having a web-based e-mail account, 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.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention, there is provided a method of implementing a data communications system. 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.

According to a second aspect of the present invention, there is provided a communications server. The 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. According to 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.

According to a further aspect of the present invention, there is provided 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.

According to an even further aspect of the present invention, there is provided 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.

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

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: Figure 1 is a 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.

DETAILED DESCRIPTION

A method and apparatus for implementing streaming data communications system via a network-based communications host server are described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details. Figure 2A is diagrammatic representation of a network-based communication system202, according to an exemplary embodiment, within which the present invention may be implemented. Specifically, 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. Alternatively, 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

Network Hotmail service offered by Microsoft Corporation. In yet a further embodiment, 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

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

Internet.

The communications server 210, regarding which further details are provided below, 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.

As is shown in Figure 2A, 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. In one embodiment, 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. In an alternative embodiment of the present invention, 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. In an even further embodiment, 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. For example, 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. In the exemplary embodiment illustrated in Figure 2B, 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.

In contrasting the situations shown in the prior art Figure 1, and the situations depicted in Figures 2A and 2B, it will be noted that only a single copy of the data file 206 is stored in a domain 214 owned by the source 204. Only unique access keys 218 that provide authorized links to the single copy of the data file 206 are distributed to the targets 220. In one embodiment, the access keys 218 are distributed by e-mail to the targets 220 outside the communications server 210. In another embodiment of the invention, the access keys 218 are provided to the target 220 within the context and facilities of the communications server 210 itself. It will be appreciated that, by only propagating unique access keys 218 that provide access to the single data file 206 owned by the source, multiple copies of the data file 206 are not distributed to each of the targets 220. This is advantageous in that the capacity of the network 208 is not consumed by propagating duplicate copies of a data file (as occurs with the situation illustrated in Figure 1). Furthermore, as each access key 218 is unique, the communications server 210 is able to monitor and impose constraints on access by any particular target 220. In one embodiment of the invention, the source 204 may define such constraints to be placed on access to a data file 206 by any particular target.

Architecture Figure 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. In exemplary embodiments of the present invention, 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. In an alternative embodiment, 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). In a further embodiment, the messaging client 312 may be a stand-alone application

Figure 4 is a block diagram illustrating further architectural details of a messaging client 312, according to an exemplary embodiment of the present invention. Specifically, 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.

Specifically, 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. Alternatively, 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. For example, the media processing layer 318 may include TrueSpeech™ 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. To this end, 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.

While 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. For example, the Windows ® Operating System developed by Microsoft Corporation incorporates TrueSpeech™ 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.

Returning now to Figure 3A, the data communications system 308 is shown to include a number of components. A web server 330 generates web pages for viewing on a browser 310 and facilitates access to the data communications system 308. The 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.

Figure 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. The SQL server 334 is responsible for maintaining the tables 338 as a relational database.

Figure 6 illustrates exemplary tables 338 that may be maintained within the database 340. Specifically, 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. As such, 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:

1. A "key" column 608 that contains a primary key for each record within the access key table 602;

2. 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;

3. 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;

4. 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; and

5. An "access constraints" column 614 that stores data specifying access constraints particular to the relevant access key. For example, 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:

1. A "key" column 616 containing a unique primary key for each record within the transaction table 604;

2. An "access key" column 618 that stores entries referencing access key records within the table 602; and 3. A "when" column 620 that records date and time information at which a particular access transaction to a data file 206 occurred. The subscriber table 606 includes the following columns:

1. A "key" column 630 storing a unique primary key for each record stored within the subscriber table 606;

2. A "name" column 632 that stores the actual name for each subscriber;

3. An "email" column 634 that stores an e-mail address for each subscriber;

4. An "Internet Protocol (IP) address" column 636 that stores an IP address for a subscriber, when available;

5. An "access privilege" column 638 that 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.

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

Returning now to Figure 3A, 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". Responsive to a request from a messaging client 312, 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 formatted video files. The media server 336 may be able to both download and upload any one, or all, files of such format.

Figure 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. Specifically, 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.

Accordingly, it will be appreciated that 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. For example, 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. In one exemplary embodiment, 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. To this end, 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.

In an alternative embodiment, 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. For example, in the case where 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. In the case where 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.

At block 704, 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. Alternatively, 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.

At block 706 the source user, the data communications system 308 itself, or both, define access constraints for each target recipient of the data file 206. Such 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. These 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. For example, 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. At this time, 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. At decision box 708, a determination is made by the access control logic 332 whether all designated target recipients of the data file are recorded as subscribers to the data communications system 308 in the subscriber table 606 of the tables 338. If not, at block 710, a respective record for each target recipient not recorded within the subscriber table 606 is then created within this table 606. Records so created within the table 606 are furthermore flagged as being "unregistered" in the column 640.

At block 712, 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.

At block 714, the access control logic 332 proceeds to communicate the unique access key 218 to each target recipient. As described above, with reference to Figures 2A and 2B, 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:

You've got a MessageBay voice message!

This message has been sent to you by abcs@messagebay.com. You can listen to it by clicking the link below.

http://63.236.33.37/vp/receive.php3?voiceid=vpmsg.38adb6d05c64.20218131 Make sure you have a recent version of Internet Explorer, Netscape, or AOL.

Voice-enabled by MessageBay. http://www.messagebay.com

In an alternative embodiment of the present invention, 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. In this case, 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:

Code for MS Internet Explorer:

Code for Netscape Navigator:

<EMBED type=application/x-mbayplug

PLUGINURL="http://www.messagebay.com/codel/mbayplug.jar" name-mbay width=240 height=53 playstr=vpmsg.38a85ded4c4e4.20000214115629 recdstr=vpmsg.38a85e0defel3.20000214115701>

A unique access key communication is described above with reference to Figure 2A. Alternatively, for those target recipients that are participants within the data communications system 308, 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.

Methodology - Data File Retrieval by a Target Recipient

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.

At block 802, 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 URI, that comprises the unique access key, embedded within an HTML document of a received e-mail message. In an alternative embodiment, the HTML document may specify a plugin application that is automatically retrieve (or activated if already retrieved) to access the data communication system 308.

Upon accessing the data communications system 308 via the web server 330, a determination will be made by the web server 330 whether the messaging client 312 is installed on a computer system from which the target recipient is accessing the data communications system 308. This determination is made at decision box 806. If the messaging client 312 is not installed on the target machine, the messaging client 312 is loaded and installed on this machine at block 808. At block 810, 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.

At block 812, 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.

At decision box 814, 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.

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.

At optional block 820, 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.

At block 882, 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. At block 824, the target recipient may elect to upload the data file 206 from the data communications system 308 to the messaging client 312. For example, in the case where the data file 206 consists of an audio file, 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. Utilizing the driver access logic 316, the audio file will be played over a speaker system of the target recipient's computer system.

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

Voice and Video Messaging Communication System 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. In addition to the 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. Specifically, 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 is user-selectable to pause the play back of a message. Further details regarding the propagation of a message from a computer system on which the HTML document 900 (incorporating the message bar 904) is displayed will be described below.

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.

As mentioned above, 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. In one embodiment, the data communications system 308 is accessed via the network 306 by a target. Specifically, 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.

Following successful login to the data communications system 308 via the login screen illustrated in Figure 10, 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. User selection of a graphical representation of a message (e.g., a title displayed within the mailbox panel 1102) will cause the relevant data file 206 that constitutes the message (e.g., a text, video or audio data file) to be retrieved in the manner described above by the media server 336 from the media database 342, and then to be presented to the target user by the messaging client 312.

The target user furthermore has the option of sending a message utilizing the message panel 1104.

Methodology - Supply of Message Bar HTML Code

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.

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. At block 1204, 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.

Alternatively, 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.

At block 1206, 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. At block 1208, 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.

At block 1210, 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. In the case where 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. In one embodiment, this communication may be a SET request in terms of the HTTP protocol. The method 1200 then terminates at block 1212.

Methodology- Sending Messages 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. For example, a source user may access a web page similar to that shown in Figure 9.

At block 1304, responsive to the user access of the web page, 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. At block 1306, the source user then selects an icon presented within the message bar 904, (e.g., the "record" button 910). Responsive to the selection, at block 1308, 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. At block 1310, 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. At block 1314, again responsive to the user selection of the "record" button within the message bar 904, 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. At the data communications system 308, 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.

At block 1316, 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.

At block 1318, 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.

Figure 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. At block 1404, responsive to the selection of the "record" button 910, 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.

In alternative embodiment, the messaging client 312 initiates recording of video data via a video camera (or recorder) coupled to the computer system. At block 1406, 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. To this end, the media processing layer 318 may leverage compression and decompression software, such as TrueSpeech™ 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. At 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. In one embodiment, 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. In an alternative embodiment, 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.

At decision box 1408, a determination is made as to whether the user has selected the "stop" button 911. If not, the media processing layer 318 proceeds to perform the above operations. Alternatively, should a user have selected the "stop" button 911, at block 1410 the media-processing layer 318 terminates the recording, decoding and compression operations. The streaming and local storing operations will continue until all received audio data has been streamed and stored.

At decision box 1412, a determination is made as to whether the source user has selected the "send" button 914. It will be appreciated that all recorded audio data will at this stage already have been streamed to the data communications system 308 (i.e., the recording and streaming operations are performed concurrently). Accordingly, user selection of the "send" button 914 serves merely as a confirmation that the user has completed the generation of the audio file, and is satisfied with the content thereof. Accordingly, if it is determined at decision box 1412, that the "send" button 914 has been selected, at block 1414 the final construction and verification of the audio file by the media server 336 occurs, and the verified audio file is stored within the database 342.

Following block 1414, or following a negative determination at decision box 1412, 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.

User selection of the "pause" button 922 at block 1408 would also result in the termination of the recording, decoding and compression operations by the media processing layer 318. Further, while operations responsive to selections of the "fast forward" and "rewind" buttons 918 and 920 have not been described, it will be appreciated that these buttons 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.)

Methodology - Retrieval of Data Files from the Data Communication System Figure 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. At block 1504, 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.

At block 1506, 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. At block 1508, the selected URI is propagated from a client machine to the data communications system 308.

At block 1510, responsive to the receipt of the URI from the client machine, the data communications system 308 propagates the data file 206 identified by the unique access key embedded within the URI to the client machine. Specifically, in an exemplary embodiment, 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.

At decision box 1512, any further customer requests pertaining to the data file 206 are detected. For example, 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.

Methodology - Streaming of a Data File from the Messaging Client to the Data Communications System

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. At block 1602, 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.

At block 1604, the messaging client 312 is downloaded to the source user machine. This download is performed automatically responsive to the accessing of the web page.

At block 1606, the source user may then select the "record" button 910 on the message bar 904. Responsive to the user selection of the "record" button 910, the messaging client 312 requests a unique file key identifier 1711 from the data communications system 308. Specifically, 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.

At block 1614, 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.

In one embodiment, at block 1616, 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. To this end, 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. At block 1618, 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. It should be noted that 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.

In an alternative embodiment, a continuous and uninterrupted stream may be communicated from the messaging client 312 to the data communications system 308.

At block 1620, 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. In one embodiment, the media server 336 then utilizes the file identifiers 1711 to identify three-second intervals of audio data belonging to a common recording. To this end, the communications interface 320 may include an ordering number (or indication) within the header associated with each three-second interval.

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.

Returning to the flow chart shown in Figure 16, at decision box 1622, 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.

It will be appreciated that 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. Specifically, 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. Specifically, 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. Again, 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. Specifically, 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. As illustrated, 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. To this end, 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.

Computer System 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. In alternative embodiments, 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. 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.

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.

For the purposes of the present specification, the term "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.

Thus, method and apparatus for implementing streaming data communications via a web-based communications host system have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

CLAIMS What is claimed is:

1. A method of implementing streaming data communications, the method including:

storing a data file, propagated from a source to a storage system via a communications network, at the storage system so as to be accessible via the communications network;

generating a unique access key for a target of the data file identified by target information associated with the data file; and

communicating the unique key to the target so as to enable the target to stream the data file from the storage system.

2. The method of claim 1 including identifying a constraint imposed upon the access to the data file by the target, and associating the constraint with the unique key.

3. The method of claim 2 wherein the constraint specifies a predetermined maximum number of accesses to the data file by the target.

4. The method of claim 2 wherein the constraint specifies a predetermined time window within which the target may access the data file stored at the storage system.

5. The method of claim 2 wherein the constrained specifies a machine from which the target may access the data file stored at the storage system.

6. The method claim 1 wherein the target information identifies a plurality of targets for the data file, the method including the generation of a unique access key for each of the plurality of targets, and communicating each respective unique key to each of the targets so as to enable each of the targets to access the data file stored at the storage system.

7. The method of claim 1 wherein the propagating of the data file from the source comprises streaming data from the source to the storage system.

8. The method of claim 1 wherein the data file comprises an audio file, and the propagating comprises streaming the audio file from the source to the storage system.

9. The method of claim 1 wherein the communication of the unique access key comprises incorporating the unique access key within an interface for the target provided by the storage system.

10. The method of claim 9 including providing a hypertext link within the interface, the hypertext link embodying the unique access key.

11. The method of claim 1 wherein the communication of the unique access key comprises propagating an electronic mail message to the target.

12. The method of claim 11 wherein the electronic mail message includes a hypertext link embodying the unique access key.

13. The method of claim 12 wherein the electronic mail message includes a first hypertext link to a further document including a second hypertext link embodying the unique access key.

14. The method of claim 11 wherein the electronic mail message identifies an application that is automatically communicated from the storage system to the target and that utilizes the unique key to identify and retrieve the data file.

15. The method of claim 1 including, responsive to a provision of a first access key to the storage system, determining whether the first access key corresponds to the unique access key provided to the target and, if so, then facilitating access to the data file stored at the storage system.

16. The method of claim 15 wherein the facilitating of access to the data file comprises streaming the data file from the storage system to a provider of the first access key.

17. A communications server comprising:

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 to generate a unique access key for a target of the data file identified by target information associated with the data file; and

communications logic to propagate the unique key to the target so as to enable the target to stream the data file from the communications server over the communications network.

18. The communications server of claim 17 wherein the target information identifies a plurality of targets for the data file, the access key logic generates a unique access key for each of the plurality of targets and the communications logic communicates each respective unique key to each of the targets so as to enable each of the targets to access the data file.

19. The communications server of claim 17 wherein the communications server receives the data file as streamed data from the source.

20. The communications server of claim 17wherein the data file comprises an audio file.

21. The communications server of claim 17 wherein the communications logic incorporates the unique access key within a communication interface for the target provided by the communications server.

22. The communications server of claim 21 wherein the communications logic provides a hypertext link within a document, the hypertext link embodying the unique access key.

23. The communications server of claim 21 wherein the communications logic propagates an electronic mail message to the target.

24. The communications server of claim 23 wherein the electronic mail message includes a hypertext link embodying the unique access key.

25. The communications server of claim 23 wherein the electronic mail message includes a first hypertext link to a further document including a second hypertext link embodying the unique access key.

26. The communications server of claim 23 wherein the electronic mail message identifies an application that is automatically communicated from the storage system to the target and that utilizes the unique key to identify and retrieve the data file.

27. The communications server of claim 17 wherein the access key logic, responsive to a provision of a first access key to the communications server, determines whether the first access key corresponds to the unique access key provided to the target and, if so, then facilitates access to the data file stored on the storage facility.

28. The communications server of claim 26 wherein the facilitating of access to the data file comprises streaming the data file from the communications server to a provider of the first access key.

29. A method including:

receiving streamed message data from a source at a message hosting system;

storing the message data at the message hosting system; and

notifying a target of the message data of receipt of the message data at the message hosting system.

30. The method of claim 29 wherein the source records the message data and concurrently streams the message data to the message hosting system.

31. The method of claim 29 wherein the message data is streamed from the source to the message hosting system as a packet stream over a packet-switched network.

32. The method of claim 31 wherein the packet-switched network comprises the Internet.

33. The method of claim 31 wherein the message data is streamed from the source to the message hosting system utilizing a real-time streaming protocol.

34. The method of claim 31 wherein the message data is streamed utilizing the HTTP protocol.

35. The method of claim 29 including, responsive to a request from the target for retrieval of the message data, streaming the message data from the message hosting system to the target.

36. The method of claim 30 including encoding and compressing the message data prior to the streaming thereof.

37. The method of claim 30 wherein the recording includes maintaining a local copy of the message data at the source.

38. The method of claim 29 including validating storage of the message data at the message hosting system upon receipt of a user-generated confirmation indication from the source.

39. The method of claim 38 wherein the validation includes construction and verification of a data file including the message data for storage in a database.

40. The method of claim 29 including receiving target information identifying at least one target to receive the message data, generating a unique access key for the at least one target and communicating the unique access key to the at least one target so as to enable to the at least one target to access the message data.

1. A communications system comprising:

a network server to receive streamed message data from a source via a communications network; and

a database server to store the message data,

the network server to notify a target of the message data of receipt of the message data at the network server.

42. The communications system of claim 41 wherein the communications network comprises a packet-switched network and the message data is received at the network server as a packet stream over a packet-switched network.

43. The communications system of claim 41 wherein the network server, responsive to a request from the target for retrieval of the message data, streams the message data from the database server to the target via the communications network.

44. The method of claim 41 wherein the network server validates storage of the message data by the database server upon receipt of a user-generated confirmation indication from the source.

45. The communications system of claim 44 wherein the validation includes construction and verification of a data file including the message data for storage by the database server.

46. The communications system of claim 41 wherein the network server receives target information identifying at least one target to receive the message data, generates a unique access key for the at least one target, and communicates the unique access key to the at least one target so as to enable the at least one target to access the message data.

47. A method of communicating data, the method including:

receiving data input at a source;

concurrently with the receipt of the data input, streaming data output over a communications network from the source to the storage system as discrete packets, the data output being derived from the data input; and

validating a data file at the storage system upon receipt of a confirmation indication from the source, the data file being constructed from the data output of the source.

48. The method of claim 47 wherein the data input is received at the source from an audio output.

49. The method of claim 47 wherein the data input is received at the source from a video output.

50. The method of claim 47 including, concurrently with the receipt of the data input, constructing a local data file derived from the data input.

51. The method of claim 47 including, responsive to a transmission request from the source, communicating a file identifier from the storage system to the source, the file identifier being for the data file.

52. The method of claim 51 wherein each of the discrete packets includes the file identifier.

53. The method of claim 47 including, concurrently with the receipt of the data input, encoding and compressing the data input to generate the data output.

54. The method of claim 50 including, in response to an absence of the data input to the source for a predetermined time period, stopping construction of the local data file and stopping the streaming of the data output of the communications network from the source to the storage system.

55. A messaging client comprising:

a media processing layer to receive data input; and

a communications interface, concurrently with the receipt of the data input by the media processing layer, to stream data output over a communications network from the messaging client to a storage system as discrete packets, the data output being derived from the data input from the media processing layer,

the communications interface to communicate a user-generated confirmation indication from the messaging client to the storage system responsive to which the storage system validates a data file constructed from the data output received from the communications interface.

56. The messaging client of claim 55 wherein the media processing layer receives the data input from an audio output.

57. The messaging client of claim 55 wherein the media processing layer receives the data input from a video output.

58. The messaging client of claim 55 wherein the media processing layer, concurrently with the receipt of the data input, constructs a local data file derived from the data input.

59. The messaging client of claim 47 wherein the media processing layer includes a file identifier within each of the discrete packages, the file identifier having been received from the storage system responsive to a transmission request from the messaging client.

60. The messaging client of claim 55 wherein the media processing layer, concurrently with the receipt of the data input, encodes and compresses the data input to generate the data output.

61. The messaging client of claim 58 wherein the media processing layer, responsive to an absence of the data input for a predetermined time period, starts construction of the local data file and stops streaming of the data output via the communications network to the storage system.

62. A method comprising:

generating an identifier code for each of a plurality of entities, each identifier code being unique to an associated entity;

providing each identifier code to an associated entity for inclusion within a network interface for the respective entity;

receiving a storage request, including a specific identifier code, at a data storage facility; identifying a target entity utilizing the specific identifier code;

receiving streamed data via a communications network at the storage system;

storing a data file, constructed from the streamed data, at the storage system; and

identifying the data file as being associated with the target client.

63. A machine readable medium having stored thereon a sequence of instructions, that when executed by a machine, causes the machine to perform a method including:

64. A machine readable medium having stored thereon a sequence of instructions, that when executed by a machine, causes the machine to perform a method including:

receiving streamed message data from a source at a message hosting system;

storing the message data at the message hosting system; and

65. A machine readable medium having stored thereon a sequence of instructions, that when executed by a machine, causes the machine to perform a method including:

receiving data input at a source;

validating a data file at the storage system upon receipt of a confirmation indication from the source, the data path being constructed from the data output of the source.

66. A communication server comprising:

storage means for storing a data file, propagated from a source to the communications server via a communications network, so as to be accessible by the communications network;

access means to generate a unique access key for a target of the data file identified by target information associated with the data file; and communication means to communicate the unique key to the target so as to enable the target to stream the data file from the communications server over the communications network.

67. A communications system including:

first means for receiving data input at a source; and

second means, concurrently with the receipt of the data input, for streaming 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, and for communicating a confirmation indication to the storage system, the confirmation indication validating a data file constructed at the storage system from the data output of the source.