Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer data streaming
Reexamination Certificate
1998-09-16
2004-03-09
Thompson, Marc D. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer data streaming
C709S203000
Reexamination Certificate
active
06704790
ABSTRACT:
FIELD
This invention relates generally to data streams, and more particularly to server-side switching of such streams.
BACKGROUND
The Internet has become an increasingly popular manner by which to convey information such as multimedia clips. There are generally at least two ways for a user to download such clips from a remote server to be played on his or her (client) computer. First, the user can initiate a download, such that when a clip has finished being downloaded, it can be played on the computer. However, this is disadvantageous, because many clips are relatively large in file size, which means that the user may have to wait a long time before he or she can play a given clip.
A second way is known as streaming. With streaming technology, the user's computer requests that the server begin sending a stream of data thereto. As the stream of data is being received, it is immediately played on the user's computer, with a predetermined buffer allowance so that if there is a delay in transmission, playing of the multimedia clip is not interrupted. Streaming is advantageous over completely downloading a clip before beginning playback, because the user is able to play the clip immediately as it is being received, without the delay in waiting for the downloading of the clip to be completed.
However, a disadvantage with streaming as per its most common transmission mechanism, known as HyperText Transport Protocol, or HTTP, is that the server is usually able only to respond to a relatively simple “get stream” request sent by a client computer. Thus, a user's computer issues a “get stream” request to the server, and in response, the server sends the desired stream to the user's computer. This is disadvantageous because the server is able only to send the requested stream, and after the requested stream has finished being transmitted, must usually wait for another “get stream” request before sending another stream to the user's computer.
For example, a user may desire to have an episode of a television program transmitted via streaming. Such an episode, however, may have multiple streams: a first stream of the introduction of the program, followed by one or more streams related to advertisements, followed by a stream of a first part of the program, followed by more streams related to advertisements, etc. In such a situation, the server is generally not able to indicate to the client computer that a given stream is to end and a new stream is to begin. That is, the server is generally not able to switch streams while streaming multimedia clips to a client computer.
For these and other reasons, there is a need for the present invention.
SUMMARY
The above-identified problems, shortcomings and disadvantages with the prior art, as well as other problems, shortcoming and disadvantages, are solved by the present invention, which will be understood by reading and studying the specification and the drawings. In one embodiment of the invention, a system includes a server and a client. The server is capable of sending data within a first stream and a second stream via packets. The packets begin with a predetermined data designator. The server is also capable of indicating switching from the first to the second stream via a packet with a predetermined switching designator. The client is capable of receiving the packets containing the data within the first and the second streams, as well as the packet with the predetermined switching designator.
Thus, the invention provides for advantages not found in the prior art. In one particular embodiment, desirably the packets are formatted according to the HyperText Transport Protocol (HTTP), and the server and the client are communicatively coupled via the Internet. In response to a “get stream” request from a client, a server is able to send packets of data relating to the desired stream, and is able to indicate to the client that it is switching from transmitting that stream of data to another stream of data, via a packet with a predetermined switching designator. Thus, in an example where a server desires to switch from a stream relating to a television program to a stream relating to an advertisement, it is able to do so.
REFERENCES:
patent: 5761601 (1998-06-01), Nemirofsky et al.
patent: 5838927 (1998-11-01), Gillon et al.
patent: 5859660 (1999-01-01), Perkins et al.
patent: 5905872 (1999-05-01), DeSimone et al.
patent: 5917830 (1999-06-01), Chen et al.
patent: 5928331 (1999-07-01), Bushmitch
patent: 5953506 (1999-09-01), Kalra et al.
patent: 6006264 (1999-12-01), Colby et al.
patent: 6122743 (2000-09-01), Shaffer et al.
patent: 6144375 (2000-11-01), Jain et al.
patent: 6182146 (2001-01-01), Graham-Cumming, Jr.
patent: 6208640 (2001-03-01), Spell et al.
patent: 6269403 (2001-07-01), Anders
patent: 6343328 (2002-01-01), Murphy, Jr. et al.
patent: 6459427 (2002-10-01), Mao et al.
patent: 6487721 (2002-11-01), Safadi
Hoffman et al, RFC 2038 (Request for Comments), “RTP Payload Format for MPEG1/MPEG2 Video”, Oct. 1996.*
Hoffman et al, RFC 2250 (Request for Comments), “RTP Payload Format for MPEG1/MPEG2 Video”, Jan. 1998.
Lee & Hayes PLLC
Microsoft Corporation
Thompson Marc D.
LandOfFree
Server-side stream switching does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Server-side stream switching, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Server-side stream switching will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3187741