Electrical computers and digital processing systems: multicomput – Computer-to-computer data addressing
Reexamination Certificate
1998-06-30
2003-07-08
Powell, Mark R. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data addressing
C709S203000
Reexamination Certificate
active
06591305
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to the computerized delivery of data from a server object to a client object, and more specifically to a method and system for sequentially delivering video data to network clients while adhering to the hypertext transfer protocol.
2. Related Art
With the increased popularity of the Internet, a strong need has developed to provide a method and system for delivering video data across the World Wide Web. Developing such technology is difficult, however, because the hypertext transfer protocol, which defines the standard for delivering Web data, does not provide a protocol for the sequential delivery of images. As a result, a number of proprietary protocols have been developed. But from these, no single protocol has emerged as the de facto standard.
The reasons for this are many, but perhaps most important is that the computers connected to the Web subscribe to a variety of platforms. These differing platforms may include different operating systems, such as those promulgated and trademarked by UNIX, SUN MICROSYSTEMS (e.g., SOLARIS), IBM (e.g., OS/2), MICROSOFT (e.g., WINDOWS NT, WINDOWS 95, WINDOWS 3.1) and APPLE (e.g., MacOS, OS8). These operating systems have varying application program interfaces. Thus, video delivery software must be individually tailored to each API to run on the associated operating system—a costly and time consuming process.
Another impediment to the development of a consistent method of video delivery is that the computers connected to the Web vary greatly in terms of processing power. This variance is problematic because a protocol that works well with powerful computers may yield unsatisfactory results with computers having more limited power.
The prior art has not even attempted to create a universal delivery system. Instead, the most common approaches cater to computers that have substantial processing power or that are run under the more common operating systems. One such approach requires the installation of a “plug-in.” This is illustrated in
FIG. 1
, which depicts a client computer
100
connected to a server computer
102
over the Internet
104
. As shown, the computers connect to the Internet
104
via modems
106
, although those skilled in the art will recognize that other forms of communication are possible, such as wireless hookups.
In addition to the modem
106
, the client computer
100
has the standard array of components: a central processing unit
108
; a user interface
110
, which typically consists of a keyboard, a mouse, and a monitor; a primary memory
112
, such as a random access memory, for program execution; and a secondary memory
114
, such as a disk, for storing programs and data that are not immediately needed for execution. As illustrated, the server computer
102
contains the same array of basic computer components
108
,
110
,
114
, with the exception of the user interface
110
. Those skilled in the art will appreciate, however, that the server computer
102
could also possess such an interface.
The client and the server computers
100
,
102
also each have an operating system
118
that is stored in the secondary memory
114
and loaded into the primary memory
112
to manage the respective computer's resources. For example, with respect to the client computer
100
, the operating system
118
provides an application program interface that allows programs, such as the browser
120
, to interact with the modem
106
so that communication may be made with the server computer
102
. Similarly, the programs of the server computer
102
, such as the proprietary video server
122
, access the server computer's operating system
118
to communicate to the client computer
100
.
The plug-in method requires the server computer
102
to install the proprietary video server
122
and requires the client computer
100
to install a proprietary plug-in
124
. The proprietary server
122
retrieves video data
126
from the disk
114
of the server computer
102
and downloads it to the client computer
100
. The plug-in
124
is then invoked on the client side to display the downloaded data
128
. Plug-ins can be installed as stand alone programs, or, as shown in
FIG. 1
, can be installed “in-line” in a web browser
120
. In advanced systems, the downloaded data
128
will be displayed using a process known as “streaming,” which is a compression and buffering technology that allows the client computer
100
to display data in near real-time. If the server
102
is incapable of streaming data, the plug-in
124
displays the data
128
after it has been downloaded.
While the plug-in technique provides a capable method of delivering video data in certain environments, the technique has several disadvantages First, it requires the purchase of the proprietary server
122
and associated development tools to even create the video data
126
. And because this data
126
is designed for use with a proprietary plug-in
124
, it often does not conform to formats that are viewable under the hypertext transfer protocol. Thus, only those who have purchased the plug-in
124
can view the created video
126
,
128
. This purchase cost frequently represents more than a one-time investment because the proprietary protocol may require constant upgrades. Also, a newly emerging protocol may displace an old one, requiring the user to start anew.
Even if purchase costs do not represent a significant impediment to broad deployment of the media, other obstacles do. The installation of the plug-in
124
is often a complex procedure, and one made particularly difficult if the data is to be delivered through a secure gateway, sometimes referred to as a “firewall.” Plug-ins also frequently require an elaborate infrastructure, such as repeaters, and can require more processing power than the client computer
100
can deliver. When this problem arises, the results can be merely unsatisfactory or nearly catastrophic. For example, when the modem
106
provides a limited bandwidth, the time required to download the video data may be so great that the user will abort the process in frustration. When the CPU
108
operates at a relatively low processing speed, or when the client computer
100
contains limited RAM
112
, the video may appear as a disjointed sequence of images or may be displayed so slowly that the client computer
100
appears to have ceased its processing.
Attempts to improve upon the plug-in system have been only marginally successful. For example, one attempt has the client object sequentially accessing image files stored on the server's disk. In one version of this approach, the client object requests the image files at a rate independent of that which the server creates them. In this scheme, the client computer could request image files at a rate of two frames per second while the server computer retrieved images from a camera and stored them to disk at a rate of three frames per second. It was hoped that this rate decoupling would provide for efficient delivery because the client could control its use of network bandwidth. Unfortunately, the technique introduced fatal timing errors: Because the client requested data at a rate independent of the server, requests for image files occurred while the data server was updating the needed image, e.g., when the server was storing or retrieving images to and from the disk. As a result, the data server would return a “File not Found” message that caused some servers to permanently suspend the exchange of data. In colloquial terms, this is known as “crashing” and, next to the destruction of data, is the most undesirable result that a communication error can produce.
To avoid such errors, some methods deliver video data using casting technologies, such as the “PUSH” hypertext transfer protocol extension that is proprietary to NETSCAPE. This extension allows for the delivery of data across a network channel at a speed dictated by server software. While this can be efficient for some system
Cardone Jason D.
Powell Mark R.
Sonnenschein Nath & Rosenthal
Sun Microsystems Inc.
LandOfFree
Method and system for delivering data from a server object... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for delivering data from a server object..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for delivering data from a server object... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3067699