Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
1999-05-20
2001-05-29
Herndon, Heather R. (Department: 2176)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S215000, C709S203000, C709S231000
Reexamination Certificate
active
06239793
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to interactive, Internet-based, program production systems capable of producing live interactive classroom instruction, live interactive entertainment-type shows, pre-recorded interactive programs, and the like. As will become apparent, the type of program content is unlimited, and it is foreseeable that the content can be at least the same as an interactive version of anything currently found on television, albeit Internet based.
For convenience, this disclosure will describe the production system in terms relevant to classroom and/or entertainment programming. Unless the context indicates otherwise, the term “commentator” will be used to denote the classroom instructor, the entertainment program's host and/or other persons being viewed at the moment by the viewer; “client” will denote the viewer's computer system, including hardware and software; “server” will denote the computer(s) (including hardware and software) which deliver the program content to the client, and “viewer” will refer to the person(s) at the client end of the system.
2. Description of the Prior Art
It will be assumed that the reader is familiar with basic Internet technology. To the extent that explanatory information is required, the reader is referred to
How The Internet Works
by Preston Galla (1997, Ziff-Davis Press) and
Computer Networks and Internets
by Douglas Comer (Second Edition, 1999; Prentice-Hall, Inc.), the contents of which are hereby incorporated by reference.
The production of Internet-based program content can be thought of as consisting of two types of signals: (1) the audio and video content of the program itself (hereinafter, the “A/V content”) and (2) commands. Examples of these signals are described below.
The A/V content is typically sent over the Internet as streaming video and streaming audio. Because audio and video content contain a large amount of information, streaming techniques typically compress the content, and transmit the compressed content to the client in IP packets using UDP protocol. Unlike the TCP protocol typically used to transmit text, UDP does not constantly check to see if data has been received by the client, and does not resend packets if they are lost in the course of transmission to the client. The loss of video information (e.g., an occasional frame) or audio information is acceptable and is frequently minimally detectable by the viewer.
UDP is far superior to TCP for A/V streams. While neither the UDP nor TCP protocols guarantee that data will arrive at a steady rate, UDP will statistically hit that rate more often for the very reason that it does not hold earlier packets while later packets are resent and placed in order. For this reason, UDP represents a more efficient way to transmit A/V content than TCP because it does not use otherwise-needed bandwidth to recover essentially non-essential packets that have been dropped or garbled, and it need not acknowledge receipt of successfully transmitted packets.
The audio packets and video packets received by the client are stored in respective buffers. When the buffers fill, or reach some other predetermined condition, an audio player and a video player are launched within the viewer's computer, and A/V content can be watched and heard while later packets are being delivered.
The foregoing descriptions of streaming audio and video signals are exemplary only, and are not intended to limit the scope of the invention in any way.
The aforementioned commands are signals which tell the system to launch such features as poll, chat, and talk-back and are known, per se, in Internet-based broadcast system technology. Poll typically launches one or more text-based questions, with a choice of answers for each question, and is a way to gather information about viewers' tastes, opinions, knowledge, etc. Chat provides the viewer with a way to interact with other viewers. Talk-back permits the viewer to send questions and comments directly to the commentator. Other features are known as well, and this list is intended to be exemplary only. Those skilled in the art will recognize that the number and type of command-initiated features are incidental to the subject invention, and that other commands and analogous signals may utilize the methodology described herein. The scope of the invention is accordingly not to be construed as being limited to these specifically described features.
As the program content is created as part of the interactive presentation, the content's producer launches commands, such as poll, with the intent that the viewer see the poll questions and answer-buttons at a particular point in the presentation. If the commands are not executed in sync with the A/V content, the presentation becomes confusing and, in some cases, meaningless. In the case of a poll, for example, explanations and instructions provided to the viewer within the A/V content must be presented at or near the time the poll is launched on the viewer's screen if the viewer is to understand and act pursuant to the commentator's instructions.
SUMMARY OF THE INVENTION
This invention is concerned with the delays associated with Internet-based transmission of video, and the resulting loss of synchronization between the video-based content and program features such as commands. The delay experienced when A/V content is sent from the server to the client over the Internet is not under the control of the program producer. There is typically, for example, approximately 3 seconds of delay at the client while the client's video buffer gathers the video stream, rebuffers the incoming data as missing packets arrive, decodes the packets, etc. Moreover, the delay is a function of the transmission path, which itself can vary from packet to packet.
At the server, live broadcasts impose additional delays because each video frame must be converted to digital data, processed, compressed and encoded. Moreover, typical compression techniques require that a set of sequential video frames be compared for differences so that data concerning the differences need only be transmitted, and the need to await subsequent frame information contributes substantially to the delay. Server-side delay can range as high as 20 seconds with present technology, compared to 2 seconds for audio and a fraction of a second for simple commands. Even at best, there is about a 7-8 second discrepancy, which is more than enough to cause the lack of synchronization to become significant.
One method for synchronizing commands with the A/V content is to “piggyback” the commands into the “out-of-band” channel provided by such currently available streaming video systems as RealNetwork's RealPlayer™ and Microsoft's NetShow™ (It is currently understood that Microsoft may be changing the name “NetShow” to “Windows Media Services” for the server side, and to “Windows Media Player” for the client side).
Currently, the “out-of-band” channel is used to open URL's at specified times by encoding the website address into the videostream so that the client's browser opens the website at the appropriate time. Information concerning NetShow is currently found at Microsoft's website http://www.microsoft.com, and one can search future Microsoft websites of such keywords as “streaming”, “netshow”, or “media player” to obtain the information if the site changes.
The current site containing information is http://www. microsoft.com/windows/windowsmedia/. The technical support site is http://www.microsoft.com/windows/windowsmedia/Support/default asp. The Windows Media Player Software Development Kit page is http://www.microsoft.com/directx/dxm/help/mmp_sdk/c-frame.htm# default.htm, which includes the documentation for the Media Player Active Control here. The associated links from this page also have useful information helpful to software developers. Http://www.microsoft.com/directx /dxm/help/mmp_sdk/reference/mediaplayercontrolreference.htm is part of the above ment
Barnert Andrew
Byrd Kelly
Dickstein , Shapiro, Morin & Oshinsky, LLP
Herndon Heather R.
Huynh Cong Lac
Rotor Communications Corporation
LandOfFree
Method and apparatus for synchronizing the broadcast content... 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 apparatus for synchronizing the broadcast content..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for synchronizing the broadcast content... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2446671