WO2000067867A2 - Method and apparatus for distributing sporting event content over a global communications network with remote regeneration and player participation - Google Patents

Abstract

A system for collecting telemetry information about any object of interest in a live sporting event and distributing the collected telemetry information to remote computer user (71) over the Internet (17). Client computers (18) receiving the telemetry information can recreate a simulated rendition of the actual live event through loaded application software (21). The system (10) as applied to a live automobile racing event for illustration purposes, but can be applied to any live sporting event. For telemetry collection, a series of data collection devices (86) serve as simple crossing point indicators, such as radio beacon receivers, to signal when an object of interest car crosses a sensor positioned on the race track (82) at the race. Pre-created models of the racing cars, the track venue, and sponsor messages information are incorporated into the system and sent to remote client computer in the form of a data script file. Each client computer (18) has running in memory an Internet communications agent (19) and a software viewer (21), similar to gaming software, for converting the data scripting file into a live regenerated scene. By streaming updated scripting files to the client computer (18), a live simulated scene corresponding to the live event is created on the client computer's display device.

Description

DESCRIPTION

METHOD AND APPARATUS FOR DISTRIBUTING SPORTING EVENT

CONTENT OVER A GLOBAL COMMUNICATIONS NETWORK

WITH REMOTE REGENERATION AND PLAYER PARTICIPATION

This application claims the benefit of filing priority under 37 C.F.R. § 1.78 of the copending U.S. Provisional Application Serial No. 60/133,068 filed May 7, 1999, for a Computer Racing Game with Live Network Interaction. All information disclosed in that prior parent application is incorporated herein by reference.

Technical Field

The present invention relates generally to the recordation and distribution of content media over a network. The present invention also relates generally to gaming software, especially gaming software having the capability to update scene play in accordance with the state of a remote event. In greater particularity, this invention relates to the transmittal of telemetry information about a sporting event for scene recreation at a remote location.

Background Art

For decades now sporting event has been distributed over various forms of communications media, mostly on high-bandwidth systems such as blanket radio transmissions. Initially, most signals were simply broadcast over the airwaves for remote reception by television sets. A tuner in each set received a transmitted signal from a connected antenna and then an analog decoder separated-out the television signal and reproduced it on a cathode ray tube. As black and white broadcasts have given way to high- definition color in transmitted events, the information content of transmitted signal has grown exponentially, but with the noticeable benefit of much higher resolution and clarity.

New conduits have been created for transmitting the higher resolution images, including color images which people take for granted, but which contains a great deal more information. Notably, cable and optical fiber transmission mediums are now employed to transmit televised events, as well as direct satellite ground reception with dish antennas. Each of these mediums transmit data from a point source to a point receiver, thereby creating a high-bandwidth live data stream.

However, one mode of communications which has outstripped all other forms of communications due to its now ubiquitous world-wide acceptance is the Internet. At present, the Internet is a relatively low bandwidth transmission medium, primarily due to its inherent structure and the relatively slow connection speeds of client computers connected to the Internet. While broad-band connections are increasing such as cable and ISDN lines, the structure of the Internet is such that all information is packetized and reassembled at a point of reception, thereby limiting the ability for continuous, uninterrupted transmission of streamed data as in high-bandwidth broadcast television media.

Most of the time, Internet users do not perceive the reassembly function, and data files arrive error free and complete at their PCs. However, while the Internet's redundant structure improves guaranteed reception from one pont to another due to the availability of multiple connection paths from one point on the Internet to another, timely reception of information is less reliable than direct broadcast system. At times, the Internet can become congested in a particular routing path such that continuous transmission from one point to another is interrupted, as anyone who uses Real Audio® or other live streaming media receivers is painfully aware.

Attempting to distribute televised sporting events over the Internet is challenging and requires significant reduction in data content. Even with broadband connections, live event streams are prone to missed data packets, corruption of the final image, and reduction in content of the available image. Standard dial-up connections are of very limited usefulness for viewing televised events over the Internet, even with today's advanced compression technologies. Hence, there exists a need for providing a distribution system for a remote viewer to see a delayed or live event over the Internet, not hampered by the inherent bandwidth limitations of the Internet.

Concurrently with the increased utilization of the Internet, client computer gaming technology has advanced rapidly. PC gaming software now provides smooth, photo-realistic simulations of created gaming events for smooth viewing on a PC's high resolution monitor. Today, PC games such as combat with aliens, flight simulations, dungeon exploration, and racing events are of such high quality such that the live insertion of a PC user into a near photo-realistic environment is common place. Further, multiple player interaction is available so that remote gamers can compete in gaming events. These remote competitors, or combatants as the case may be, are connected to one another through a single PC with multiple joy sticks, or multiple remote users being connected to a gaming server over the Internet. Since the data transmitted between PC's for multiple gaming interaction is very small, interruption of play due to Internet congestion is rare. And, since the game is not dependant on data received over the Internet to recreate the simulated environment of the game, a games displayed image is not affected by the rare loss of any remote user's action date.

However, hereto far, no-one has tied the PC game's function to a live event so that a remote PC can recreate a remote live event over the Internet. The present invention sets-out both a novel apparatus and novel methods for the recreation of a live sporting event at a remote user's PC by combining today's gaming software with a unique recordation and distribution system to enable a remote user to see a live re-created sporting event at their own home PC. Further, live interaction using standard software gaming techniques may be utilized to enable competition between the remote user and other users, or participants in the live event.

One inventor, Forsberg (published PCT application Ser. No. PCT/GB99/03136), has attempted to disclose and protect a remote computer game using racing cars. In particular, he discloses a computer game with a racing car example in which car dynamics data are taken from live vehicles on a race track and then broadcasted from a track collection point to remote users running gaming software. The gaming software generates a user controlled dynamic vehicle that can be raced against live and remote players.

While Forsberg discloses the naked idea of disseminating the dynamics data via the Internet, among a list of other communication conduits, Forsberg discloses insufficient structure and methods for accomplishing the transmission and regeneration of the dynamic data at a remote client computer. Further, Forsberg does not disclose a system or method for any of the following: (1) transmitting dynamics data to a remote client computer; (2) a method or structure for locating a car's position on a race track; (3) a method or structure for avoiding car collisions; (4) a method or structure for utilizing multiple game servers; (5) a method or structure for including sponsor advertisements; (6) or a plausible data scripting format for low-bandwidth transmissions, each of which are features of the herein described invention. Moreover, most of the Forsberg application talks in generalities and does not provide enough information to enable any ordinary worker in the applicable arts to reproduce the claimed invention. Conversely, the present invention discloses specific novel methods and a system for making distribution of sporting events over the Internet or other similar media a reality. Therefore, the present invention sets out in detail a structure and method for accomplishing what Forsberg nakedly describes, solving a need existing in the industry for remote, low bandwidth distribution of live sporting events, including the liver insertion of sponsor advertisement into the recreated sporting event at the remote PC.

Disclosure of Invention

It is the object of the present invention to provide a method and system for recording live sporting events and transmitting data about the sporting event from sensors at the live event to client computers.

It is also an object of the present invention to provide a method and system for recreating a live sporting event at a remote computer.

It is a further object of the present invention to provide a method and system for recording and distributing telemetry information about objects of interest at a sporting event to a network of client computers.

It is yet another object of the present invention to provide a method for calculating the speed of racing cars traveling about a track.

It is also an object of the present invention to provide a method and system of collision avoidance for fictionally created racing cars controlled by remote users.

It is a still further object of the present invention to provide a method for transmitting limited data information about a live automobile racing event to remote computer users over the Internet such that software running on these client computers can recreate a simulation of the racing event in real-time.

In summary, the invention consists of a system of data collection devices and a telemetry server that distributes information from a live event to remote client computers over the Internet. The sensor are typically simple crossing indicators such as radio beacons that indicate when a car has crossed a sensor position on the track. Pre-created models of the racing cars, the track venue, and GUI information are incorporated with retrieved telemetry information into a scripting data file that is sent to remote client computers. Each client computer has running in memory an Internet communications agent and a software viewer, similar to gaming software, for converting the data scripting file into a live regenerated scene. By continually resenting scripting files in a data file stream to the client computer, a live simulated scene corresponding to the live event is created on the client computer. Sponsor's advertisements can also be inserted into the modeling process so that sponsor information can be incorporated into the scripting file so that a sponsor's messages be inserted into the regenerated scene. A network server can also be incorporated to control access to the live event or for accessing recorded events for later viewing.

Other features and objects and advantages of the present invention will become apparent from a reading of the following description as well as a study of the appended drawings.

Brief Description Of Drawings

The invention will be better understood by reference to the following detailed description of best mode of the invention together with the figures that form part of this description and wherein:

Figure 1 is a layout diagram of the primary elements of the system;

Figure 2 is a structural diagram of the primary components of the system;

Figure 3 is a system flow chart of the primary elements of the telemetry server and the applicable client computer software;

Figure 4 is a more detailed system flow chart of the telemetry server;

Figure 5 is a system flow diagram of the script file generation module;

Figure 6 is a system flow diagram of the venue data module;

Figure 7 is a more detailed system flow diagram of the client computer software for the invention;

Figure 8 is a data flow diagram for the telemetry server;

Figure 9 is a conceptual diagram showing a method for calculating the speed of a particular racing car participating in the live racing event; and,

Figure 10 is a process flow diagram for showing the steps in collision avoidance for an inserted, imaginary race car controlled by a user when racing against live participants. Best Mode for Carrying Out the Invention

Referring to the drawings for a better understanding of the function and structure of the invention, Fig 1 shows an overall view of the system 10. A telemetry server 1 1 having a race monitor 12 gathers information from sensors strategically positioned around the sporting event venue Through a dial-up connection 13 , a network computer 14 provides permissible access to receiving telemetry information supplied by the telemetry server 1 1 by at least, but potentially thousands, of client computers 18 As is well known in the communication arts,

Internet service providers or "ISPs" as they are commonly referred to provide a communication conduit over the Internet 17, for both the users of the client computers 18 and the network computer 14

Additional game servers 16 can optionally serve archived sporting events to client computers 18 through the Internet 17 The network computer 14 includes a web server for communication to remote users through an Internet browser, and a series of hyper media pages (e.g. HTML) accessible over the World Wide Web can provide an access portal for remote users to easily access live and archived events The client computer 18 includes a web agent 19 for communication to the network computer 14 and or the game server computer 16, and to a game viewer 21 which has the capability to regenerate data sent by the telemetry server into a simulated live image.

The invention is described in terms of a live automobile racing event such as the Indy 500, but this type of event application is for illustration purposes only and the present invention may be practiced on any event in which positioning of sensor receptors at known locations throughout the event venue is possible

Fig. 2 shows further definition of the primary elements of the invention and the overall structure of the data flow between those components A group of telemetry sensors 22 are positioned in the venue with a single numerically coded transponder transmitter located in each car. As a transmitter enabled race car traverses the track at a racing event, the sensors 22 pick-up the signal transmitted by each car to indicate a crossing point by a receiving sensor The crossing trigger events are buffered and collected by the race monitor 12 and transferred to the telemetry server 1 1 upon the server's request. Additional telemetry data such as pitch, roll, and yaw of each car, geo-position from satellite tπangulation (i.e. "GPS") of each car at any selected moment, car speed, engine RPM, three dimensional G-force on a car, crash status, race status such as red, green, and yellow flags, can also be supplied to provide data about both car and race status.

The telemetry server 1 1 retrieves buffered sensor events as needed and combines other telemetry event information from a manual operator at the live event. The manual operator 23 can either use a remote electronic device to receive and transmit additional race status information or car position information, such as a car pitting to re-fueling or a car involved in an accident to server 1 1 to improve the positional accuracy of the race cars, or he or she can use a graphical user interface or "GUI" running on the telemetry server itself.

The telemetry server 1 1 produces, as will be discussed further, output data 26 about the racing venue and cars to a game server . The server 1 1 also outputs information 27 about the state of the racing event itself and car definitions for cars participating in the event. The network computer/server 14 includes a server component 15 which may server as a game and network information server. The network computer 14 also administers remote game enthusiasts' access to selected race event, download of client computer viewer/player applications, and user profiles. As shown, once access to a game is provided to a remote user, the game/network server 15 or other gaming servers 16 can establish direct connections with the client computer 18 to stream event data to the viewer/game application 21 via the web agent 19. All communications can occur through the Internet.

Referring now to Fig. 3 for a clearer understanding about the interaction between the telemetry server 1 1 and the client computer 18, it may be first seen that according to the nature of the invention that communication from the telemetry server 1 1 at the live event directly to the client computer 18 is quite available. A race event owner may wish to distribute race information directly to remote computers without the necessity of distributing content through a separate network computer. This structure may even be preferable to minimize the computer and communication resources utilized in the system. As such, a web server and self-contained distribution component 29 may be incorporated into the telemetry server 1 1. If incorporated, the distribution site 29 provides HTTP and FTP server capabilities to the World Wide Web for the purposing of promoting, tracking, and regulating the distribution of the client applications as well as the required live script data files. A local area network ("LAN") 31 allows the telemetry server 1 1 uninterrupted access to the race monitor 12, which may comprise several monitors each connected to the telemetry server over the network 31. A standard computer server component 32 controls the creation and storage of scripts 33 through a script installer and constructor module 34 that has access to received and stored telemetry, other scripts, and visual model information. Server install and uninstall applications 99 such as Install Shield™ are provided throughout the invention' s system to facilitate installation and removal of software components of the system 10. In as much as these programs 99 are well understood and not necessary for an understanding of the invention, they shall not be discussed further. The telemetry server 1 1 can run any type of high performance server application having Internet I/O administration capabilities such as Microsoft Windows Enterprise™ Server. A wide area network ("WAN") 37 provides a communication channel to client computer 18. However, for the purposes of the disclosed embodiment, the WAN will be assumed to be the Internet, although it will be clear to those skilled in the art that any type of communications medium such as microwave, optical, satellite, dedicated line, or radio transmission may be used to transfer the necessary telemetry information to the client computer 18.

The script installer construction module 34 is responsible for taking a set of script files (produced by the script generation module 44) and generating a self-extracting installation script and for placing these files at the appropriate location on a remote client computer's system. As this is required for each script to be distributed, the module 44 produces these installation applications in a continuously repeatable manner.

The client computer 18, includes an agent 19 for receiving and storing scripts 38, for the regeneration of the sporting event through the operation of the viewer/gaming application

21 running locally on the client hardware 39. The agent 19 can be any type of standard HTML browser, but it is preferred to have a custom GUI interface to suit a racing game environment. Since data files are transferred about the system 10 using standard file transfer protocol ("FTP"), the agent must include FTP capability in addition to HTML browsing capability. Both of these communication capabilities are well known in the industry, and will not be discussed further.

Referring now to Fig. 4, it may be seen that the script installer 34a and the script constructor 34b transfers a constructed and complete script data file to FTP server 41 that transfers the files over the Internet 37 to either a client computer 18, a network computer 14, or a gaming server 16. The FTP server 41 has the capability to continuously stream updated script files in order to satisfy the data requirements of the viewer application 21 to provide a smooth and error free regeneration of the sporting event. Further, created scripting files may be either encrypted or compressed as necessary to reduce the size of the data file. In as much as FTP processes, encryption, compression, and communication handshake protocols are well understood in the arts, and not necessary for an understanding of the invention, further explanation of the process of transferring files from the telemetry server to the client computer or other elements of the system shall discussed only as needed.

Raw telemetry data is received by the telemetry date module 42 from LAN I/O ports 43 on the server 32 and transferred to a script generation module 44. The telemetry' data module 42 is responsible for accessing the network stream or secondary file format of raw car telemetry being received from the LAN 31 and making that information available to other modules. Specifically, it provides a query-based interface to the telemetry sources in an efficient manner and encapsulates all of the format, access, and extrapolation issues for using the raw car telemetry data. It also provides an application programming interface or "API" about files in the system, records the state and timing data held by a timing element (not shown) associated with the race monitor 12, and provides and interpolates car state data. The a script generation module 44 obtains input from the car model module 46 and the venue data module 47. The venue data module 47 is responsible for accessing the venue data file formats referenced by the scripting files transferred to and from either a client computer or the network computer and making them available to other modules. Specifically, it provides access to venue data in an efficient manner by encapsulating all of the format and access issues for loading venue data. Venue data includes both a venue's visual models as well as informative files concerning track conditions and the sensor positions used for cross track estimates. The car model module is responsible for updating a car's state (as further described below) in view of a car's current state on the track and the venue's current state. It does so by using Newtonian algorithms to realistically compute the dynamics necessary to update a particular state. The car module 46 is important to maintain a best possible position accuracy of a car as described in a script when telemetry data is insufficient and extrapolation is necessary.

A script data file contains a set of state data for each scripted car visible in the sporting event venue. The script determines a desired position and appearance for the scripted cars. The state of the scripted car may also be adjusted to avoid collisions with the locally modeled car. In the event of a collision, a physics model will extrapolate the state of the scripted car during the resulting accident. The script file also provides visual models capable of allowing other software modules to meet their functional requirements of a proper visual experience, an acceptable frame rate, and the insertion of sponsor messages. A simplified, but functional, scripting data file example is shown below as Example 1. The three essential sections of a script file are a venue definition (line beginning with 112), a base definition section for an object of interest in the sporting event (lines beginning with 1 13), and time stamped dimensional state data relative to the modeled venue coordinate frame (lines beginning with 105). Obviously, Example 1 below is the ASCII text output and for illustration purposes only. All scripting files would normally be in binary form and compressed.

112, 952976173, 200, "Delphi Indy 200 (01-29-2000) 10 Cars Laps 7-21",

"2000DelphiIndy200"

1 13,1,1 ,5,-2.24,0.14,6.203,0,"Ray, Greg","2000D2000AF","Ray 1_01 "

113, 14,2,5,-30,1.12,0.018,0,"Ward, Jeff \"2000G1999AF","Wardl4_01"

113,91,3,5,-51.09,0.03,0.067,0,"Lazier, Buddy","2000R2000AF","Lazier91_01" 1 13,28,4,5,-85.54,-1.2,6.246,0,"Dismore, Mark","2000D2000AF","Dismore28_01 "

1 13,12,5,5,-184.38,5.09,6.037,0,"Calkins, Buzz","2000D2000AF","Calkinsl2_01"

1 13,100,6,5,-199.38,8.0,6.037,30,"UNKNOWN","UNKNOWN","UNKNOWN"

105, 1, 1

105, 2, 230125, 91, -51.08, 0.02, 0.0674952, 4265, 0, 0 105, 2, 230125, 28, -85.54, -1.2, 6.24637, 4218, 0, 0

105, 2, 230125, 14, -30, 1.12, 0.0184078, 4265, 0, 0

105, 2, 230125, 12, -184.38, 5.08, 6.03775, 4171, 0, 0

105, 2, 230125, 1, -2.24, 0.14, 6.20342, 4312; 0, 0

105,3 105,1,1

105, 2, 230235, 91, -48.2, 0.22, 0.0490874, 4265, 0, 0

105, 2, 230235, 28, -82.66, -1.24, 6.25251, 4218, 0, 0

105, 2, 230235, 14, -27.04, 1.14, 0, 4265, 0, 0

105, 2, 230235, 12, -181.6, 4.48, 6.06843, 4171, 0, 0 105, 2, 230235, 1, 0.68, 0, 6.2341, 4312, 0, 0

105,3

<REPEAT with subsequent state>

Example 1.

Telemetry, stored scripts, and various types of visual models may be stored 36 either within the server 32 or on a separate storage device accessed through the I/O ports on the server 32. The script data module 48 is responsible for accessing the file data stream and secondary files of available scripts and making them available to other software modules. Specifically, it provides a query-based interface to a script files in an efficient manner, and also encapsulates all of the format, access, and extrapolation issues for using script data. Additional script data in the form of updates to models may be obtained via the Internet 37 through I/O ports 43, which may then be transferred to the script generation module 44 to improve script file accuracy. As previously discussed, external non-telemetry information 49 may be used by the manual operator 23 to improve the overall accuracy of the telemetry server's 1 1 processing by accessing various software modules through a GUI interface 51 designed for the telemetry server.

The GUI 51 displays the currently selected server status as well as allowing the operator to modify the options provided by the server. As an interface, it has two sides: on one side interfacing with the operator, it consists of a number of form entries and graphical controls showing the currently selected options and the state of the script generation module 44; on another side it interfaces with the script generation module 44 and consists of a number of flags, switches, and values indicating the desires of the operator.

As shown in Fig. 5, the script generation module 44 selects telemetry sources existing scripts, and car model input, as selected by the operator, and generates and merges the resulting data into a new script. It ensures that the resulting script is constructed in a time ordered manner and based upon data selected by the manual operator 23 and in accordance with his or her wishes. Data sources depended upon are the telemetry Data module 42, the script data module 48, and car model module 46. Interim and finished files generated by the module 44 are stored in the script data module 48.

Referring now to Fig. 6, it may be seen that local storage 61 stores data about the default starting point 62 for cars on the track, venue geometry 63 which is information and models about the scene elements visually representing the venue, textures 64 for filing venue scene elements, and information about the track geometry 66 which is also passed to the car model module 46. Some of the software modules of the system 10 are common to both the client computer's software as well as the telemetry server's applications. The script interpreter 67 is one of these modules as more fully discussed below.

As is shown in Fig. 7, the client computer 18 has several software components common with the telemetry server 1 1. The script data module 48, the venue data module 47, and the car model module 46 each run on the client computer 18 as well as the telemetry server. The client computer agent 19 sends and receives script data files and places them in local storage 73 on the client computer. A two dimensional GUI 72 controls the client agent 19 in response to user 71 commands. The 2D-GUI 72 also displays the currently selected client computer status and allows through a selectable interface the user to modify options provided by the client agent. The 2D-GUI interface has two primary functions: one function is to interface with a user 71 , which consists of a number of form entries and graphical controls showing the currently selected options and the state of the client computer and agent software; and another function is to interface with the viewer/gaming application and consists of a number of flags, switches, and values indicating the desires of the user 71.

An input device module 63 is responsible for taking the keyboard, mouse, joystick, steering wheel, and/or pedal inputs and mapping them to the appropriate control settings on the viewer/gaming application. Analog control settings are specifically for steering setting, throttle setting, brake setting, and transmission gear selection. Input source values are normalized such that application requiring information about a steering setting are insensitive as to whether a setting was made via a keyboard, mouse, or joystick.

The script interpreter 67 receives data from the common modules of the script data module 48, the venue data module 47, and the car model module 46, and outputs data to the three-dimensional graphical user interface ("3D-GUI") 68 and the award module 77. The script interpreter module 67 is responsible for sampling and adjusting events within the script being rendered. As stated previously, a script date file provides a set of data for some number of cars, venue appearance information, as well as sponsor message information. The script interpreter module 67 is responsible for sampling script data for the current time and adjusting a cars actual position in accordance a locally modeled cars. For car states, if the scripted position is in conflict with the locally modeled car, it adjusts the actual position. Hence, the locally modeled car queries, from time to time, this module for the actual current state of a remote car instead of using the raw scripted position information previously received. The module also sets the initial appearance switches of the car's visual model, and as events indicate changes in appearance for a particular car the module adjusts the appearance of switches accordingly. For venue and sponsor message changes, the module sets the related visual model's switches and textures to be consistent with the events found in the script.

The 3D-GUI 68 is responsible for displaying a three-dimensional scene. The placement and orientation of the visual models for the viewpoint, venue, cars, sponsor messages defines the required scene. Additionally, sounds associated with the visual models are typically rendered as a multi-channel audio stream. The 3D-GUI includes a scene renderer and associated creator module to passing a rendered 3D image to the client computer display device. As shown, venue data, car model data, and scripting data are coalesced into a rendered image through the 3D-GUI.

The award module 77 is responsible for assessing whether a specific criterion has been met and displaying a final analysis of a user's performance after the completion of a driving session. A local (i.e. by the client computer) user's performance is monitored in relationship to a clock element at the sports event, the track, and the other participating cars. Statistics, and other criteria associated with final results are calculated and also maintained by the award module. The award module also generates a final display showing performance results after play completion. Player specific keys associated with successfully meeting a specified criterion are incorporated to limit the number of rewards to any particular user. A feed back function is included to store the key and would likely be used by a sponsor to track and regulate the distribution of incentives to remote users. A replay generator 76 records user actions and events, records live event data received over the Internet, and allows users to play back recorded events to regenerate realistic replays.

Referring now to Fig. 8 for a discussion of the data flow 81 in the telemetry server 14, it may be seen that the race monitor 12 transmits serial messages about numerically identified car crossing events and other gathered non-telemetry events to a message decoder, which then decode and assigns the data to an appropriate event time-line (83, 84, and 86). An event time- line is a series of events that can be randomly accessed and held in primary memory. Each car racing in the event has a unique event time-line. The car event time-line 86 holds a series of changes in a car's non-telemetry event, including start/stops of a spin, start/stopping for a pit stop, or other repair/damage event. A race flag time-line 84 holds a series of changes regarding the racing event's status such as red, yellow, or green flag conditions, and a segment time-line marks the crossing times for a race car to cross a sensor reception point on the track.

A speed profile (as further described below) records the average speed of each car over a specified segment of the track, as recorded by the track sensor elements.

A series of processes 89, 91-94, select profile data as needed through a profile selection function 88. A clock function 96 provides timing data as needed and is calibrated to a timing element at the actual event. A table of speed factor verses segment factor is used to calculate instantaneous speeds throughout a given segment of the track for each car. Values of around 1.0 are used for the average of the values equals to 1.0. Given recorded crossing times for each car, a car's average speed through a segment can be determined (see example below). By mathematically integrating into a particular track segment over time, the car's instantaneous speed and position can be accurately guessed. Starting at the front of a selected track segment (0.0 of segment-down the track from the start/finish line or "down-track") the instantaneous speed is the average speed multiplied by the speed factor at 0.0 of down track.

Using speed and delta time, a position can then be computed. Successive iterations can use the speed factor function at the new down track data to compute a new instantaneous speed and position. Sub-integration is then used to reduce error caused by any dramatic changes in the speed profile. The speed profile function 94 performs this integration using the speed profile.

Speed profiles are good for nominal green flag racing. However, pit stops, yellow flags, accidents, and parade laps are not considered by the speed profile. Therefore, specialized profiles integrate the car through the segments, maintaining the crossing times, with speed profiles matching specific events during a race. For example, the pit profile function 89 calculates the slowing and stopping times required to allow a car to pit on a specified lap. A parade profile 91 is used only at the starting time of the race and integrates the starting sequence used in formation flying starts common to America oval track racing. A stopping profile 92 calculates the slowing and stopping times of a car that may have stalled, spun, or wrecked at an arbitrary point of the track. A yellow profile 93 calculates the transition into and out of a yellow flag condition on the track, and the slower speeds maintained during a yellow lap.

A segment transition and smoothing function 96 removes any potential for jerky motion of a rendered car. RPM 97 is calculated depending upon the instantaneous speed of a car and shift tables and gear rations in a mathematical calculation. Referring to Fig. 9, a method for calculating a car's speed around a track is shown.

A racing track 83 is divided into segments 0-3. Start/stop end points 86 are situated along each segment. Sensor are situated at each start/stop end point 86 and communicate with race monitor 12 when a car having a proximity transmitter passes by. The race monitor 12 is continuously recording and transmitting crossing events to the telemetry server 14 during a race.

As indicated in the prior discussion about speed profiles, instantaneous speeds throughout a given segment of a track can be calculated for each car. For example, assume we have a single track segment in our speed profile. The profile encompasses the entire track and 0 to 100 percent of the speed profile correlates to 0 to 100 percent of the track length. Let us assume the initial position pθ(tθ) is equal to zero percent of the track length (e.g. the start/finish line). Further assume we have a 1 mile track and a 23 second lap time. For simplicity, lets use a 1 second delta time between integrations (tl=l, -2=2, t3=3...). The average speed for the lap is 5280ft / 23s or about 229.56 ft/s (i.e. 156.52 mph). The charts 87 of Fig. 9 shows a model speed profile for each segment of the track . Notice that at zero percent down-track (i.e. down the track) the speed factor is 1.0. This distance traveled in this iteration is: dl = avg speed (ft/s) x speed factor x delta time (s) = 229.56 x 1.0 x 1.0 =229.56 ft. Therefore, pi = pO + dl = 229.56 ft. Since pi is at about 4% of down-track, the speed profile factor found there is a little faster than 1.0, maybe 1.02. Therefore, d2 = avg speed (ft/s) x speed factor x delta time (s) = 229.56 x 1.02 x 1.0=234.15 ft; and p2 = pi + d2 = 229.56 + 234.15 = 463.72 ft. A very small delta T is required to ensure that the final position for the lap is very close to the track length, where 100% becomes 0% for the next lap. An additional smoothing factor is applied to the above calculations. So the actual function used is px = p(x- 1 ) + avg speed x speed factor x delta time x a smoothing factor. The model profile speeds shown on charts 87 in Fig. 9 are established a priori from recorded race track performance statistics. A race car's average speed is calculated and an instantaneous speed for each car calculated by comparing a car's actual average speed to the profile curves and producing an estimated instantaneous speed result.

However, segment average speed times must be smoothed to address any segment transition inequalities. The smoothing function is applied on top of each speed profile established for each car. Any segment transition inequalities are smoothed by computing and applying an acceleration calculated to compensate for half of the difference encountered between segments transitions. A transition time is also established as to when the adjustment acceleration should be applied to the pertinent race car. Typically, the front and back quarter of a segment profile is utilized in the transition to the previous and next segments. To maintain a proper average speed, a peak or valley is introduced into the middle half of each segment as shown below:

Figure 1

The 1 dimensional down- track position is converted to a 3 dimensional position using knowledge of the racing lines taken by cars at a particular track for specific situations. Slow, fast, pitting, caution, and warm up lines are known for a particular track. Standard interpolation procedures are employed for the computation of position and orientation of the car. As situations change for a particular car, transitions between the different lines are employed to smooth the change and produce a realistic effect. A prioritization algorithm reviews a particular car's situation at any given time and selects what line and when to transition between lines.

Referring to Fig. 10, a collision detection and avoidance process is shown that is utilized in the racing sporting event to avoid remote player cars from over-running actual cars participating in the event. A player's (i.e. remote user) car location and orientation is assigned a flat, 2-dimensional Cartesian coordinate location x,y 88. An actual racing car's telemetry location 89 and orientation is likewise assigned. During the racing event, each car in the racing event, whether created for a remote client computer or in actual competition has it's x,y position calculated in 88 and 89 has a down-track distance (i.e. "tape measure" distance on track from start/finish line) computed 92. Each car is sorted 93 based upon the down- track measure, which helps to minimize the number of cars that each car must consider prior to passing. The distance between each car to another proximate car is computed and a threshold applied 94. Any distance between two cars greater than the threshold halts any further processing of those cars. The remaining car groups are analyzed to compute the time of closest approach 96 and an estimated propagation 97 to determine the location where the cars will be at the time of closes approach is made. Depending upon threshold propagation values, either no collision is imminent 98 and no action to alter the location of a particular car is taken, or an eminent collision will be detected 99 and the telemetry car will be made to pass the remote player car. In an imminent collision scenario, a computation is made to determine which side of the remote player car the telemetry car is easiest (i.e. most room) to pass. Computation 101 also determines the distance to obstructions and track venue walls. If the decision to go left 102 has been made in process 101, the passing car is estimated to be to the right of the other car at the closest approach and enough room is deemed to exist between the other car and the inside wall of the race venue. If a go right 102 decision is made, the same estimate is made with regard to the outside wall of the track. The lateral adjustment necessary for the pass is computed 103, and velocity changes in the telemetry car to make the pass are managed and averaged 104 to have a sum zero effect on the actual performance of the telemetry car. The telemetry car's position (x,y) is then adjusted 106 to avoid the remote player's car. Additional checks to ensure that the adjustment does not push the telemetry car into the wall, and the change in position is calculated. A continuous loop of calculations is on-going during the racing event to prevent a remote player 71 from interfering with actual competitors' racing in the live event, but while maintaining a smooth on-going racing event.

While I have shown my invention in one form, it will be obvious to those skilled in the art that it is not so limited but is susceptible of various changes and modifications without departing from the spirit thereof. For example, the methods of live event modeling and scripting, and the distribution and remote regeneration system may be utilized on any event that has a set course or a track. Dog, horse, car, sail boats, planes, or any other objects that travers a known path can be modeled, scripted, and distributed for regeneration on a remote computer. Similarly, the speed calculations and collision avoidance methods are fully applicable.

Further, the Internet communications medium is only an example of the type of communications network to which the herein described invention is applicable. For example, new communications networks are being conceived and implemented often. One type is a hybrid combination of TV and Internet broadcasting called Interactive TV. Interactive TV is highly susceptible to being utilized for distribution of telemetry scripting data files to remote PCs for recreation of a sporting or other event. In summary, any type of communications network may be utilized, albeit implementation would be dependant upon the practical economics of the particular medium selected.

Claims

Having set forth the nature of the present invention, what is claimed is:

1. A system for distributing sporting event content over a communication network for viewing on a remote client computer, comprising: a. a telemetry sensor positioned on an object of interest in a sporting event; b. a telemetry server in communication with said telemetry sensor for receiving data therefrom; said telemetry server including means for generating a scripting data file based upon said sensor data; and, c. a client computer in communication with said telemetry server over said communications network, said client computer including means for regenerating a simulated rendition of said sporting event based upon said scripting data file.

2. A system as recited in claim 1 , including means connected to said telemetry server for manual intervention by a local operator to enhance position accuracy of said scripting data file.

3. A system as recited in claim 1, further comprising a network computer in communication with said telemetry server and said client computer to coordinate permissible access to a selected sporting event.

4. A system as recited in claim 1, wherein said client computer is in communication with said telemetry server over the Internet.

5. A system as recited in claim 1 , wherein said telemetry server comprises: a. a computer server including: i. means for receiving telemetry data; ii. means for generating a data scripting file from said telemetry data; iii. means for storing received telemetry data, generated data script files, venue data, and visual models pertaining to said obj ect of interest; and, iv. means for communicating data stored in said storage means to said client computer.

6. A system as recited in claim 5, wherein said client computer is connected to other client computers for interactive competitive racing against other remote users.

7. A system as recited in claim 1 , wherein said regeneration means comprises a software agent for reading hypermedia files and communicating with said telemetry server, and a software game for receiving scripting data file information from said software agent and recreating said sporting event.

8. A system as recited in claim 1 , wherein said data script file has a format comprising: a. a venue definition section; b. a group of base definitions for an object of interest; and, c. time stamped dimensional data section.

9. A system as recited in claim 1, wherein said client computer is connected to other client computers for interactive competitive racing against other remote users.

10. A system as recited in claim 1 , wherein said client computer includes computing game software for inserting an artificial object of interest controlled by a user of said client computer to enable said user to compete against others participating in said sporting event.

1 1. A system as recited in claim 1 , further comprising a plurality of game server computers in communication with said network computer and selected client computers for providing access to additional sporting events.

12. Method for recreating a sporting event at a remote client computer, comprising the steps of: a. collecting telemetry data from an object of interest at said sporting event; b. generating a scripting data file from a telemetry server based upon said telemetry data that includes information about the venue of said sporting event and modeling variables pertaining to said object of interest; c. sending said scripting data file to said remote client computer; and, d. in conjunction with software running on said client computer, regenerating a simulated rendition of said sporting event based upon said scripting data file and displaying said rendition on a display device connected to said client computer.

13. The method as recited in claim 12, wherein said method repeats continuously such that said simulated rendition is updated continuously to create a continuous and near real-time rendition of said sporting event.

14. The method as recited in claim 12, wherein said step of sending said scripting data file comprises transmitting said scripting data file to said client computer over a communications network such as the Internet.

15. The method as recited in claim 12, wherein said step of sending of said scripting file includes the step of initiating said sending step by a remote computer server in communication with said client computer and said telemetry server.

16. The method as recited in claim 15, wherein said remote computer server comprises an Internet web site, and wherein said sending step is initiated by a user of said client computer having accessed said Internet web site.

17. The method as recited in claim 12, wherein said generation step includes generating data specific to an advertisement for display on said client computer within said simulated rendition of said sporting event.

18. The method as recited in claim 12, wherein prior to said generating step receiving additional telemetry data pertinent to said object of interest from a manual operator responding to live conditions at said sporting event to enhance position accuracy of said object of interest.

19. The method as recited in claim 18, wherein said generated scripting data file is continuously recorded in an archive database for delayed transmission or selected archive retransmission of said sporting event to said client computer.

20. The method as recited in claim 12, further including the step of continuously recording said generated scripting data file in an archive database for delayed transmission or selected archive re-transmission of said sporting event to said client computer.

21. The method as recited in claim 12 , wherein said step of collecting telemetry data includes the steps of: a. dividing a defined course at said sporting event venue into multiple segments with a minimum of one segment, each segment having a known distance; b. establishing a timing element; c. receiving crossing telemetry data from a selected sensor positioned on each segment to indicate the crossing of said obj ect of interest past a known point on said segment; d. correlating said know point's position with data from said timing element to calculate the total distance traveled over said segment and the total time to traverse said segment; and, e. calculating a speed of said object passing over each segment by dividing said total distance by said total time.

22. Method for calculating the speed of a object around an event track, comprising: a. dividing said track into multiple segments with a minimum of one segment, each segment having a known distance; b. establishing a timing element; c. receiving crossing telemetry data from a sensor positioned on each segment to indicate the crossing of said object past said sensor; d. correlating said sensor's position, with said passing telemetry data, with data from said timing element to calculate the total distance traveled over said segment and the total time to traverse said segment; and, e. calculating a speed of said object passing over each segment by dividing said total distance by said total time.

23. The method as recited in claim 22, including the further step of averaging said calculated speed of said object with other speeds calculated from other segments to arrive at a track lap speed for said object.

24. A computer racing game with remote racing event correspondence, comprising: a. at least one telemetry sensor positioned on at least one racing car for transmitting position data about said car; b. a telemetry server for receiving said position data, said telemetry server including means for generating a data file pertaining to selected racing cars participating in said racing event; c. a network computer in communication with said telemetry server for controlling access to said telemetry server data files; and, d. a client computer in communication with both said network computer and said telemetry server, said client computer including means for regenerating a simulated rendition of said racing event based upon said telemetry server data files.

25. A computer racing game as recited in claim 24, wherein said data file includes position data on each selected racing car, visual modeling data about each said selected car, and visual and positional data pertinent to a venue associated with said racing event.

26. A computer racing game as recited in claim 24, wherein said network computer is in communication with a plurality of client computers and said regenerating means includes means for competing against others.

27. A computer racing game as recited in claim 24, including means connected to said telemetry server for manual intervention by a local operator to enhance position accuracy of said data file.

28. A computer racing game as recited in claim 24, wherein said client computer is in communication with said telemetry server over the Internet.

29. A computer racing game as recited in claim 24, wherein said telemetry server comprises: a. a computer server including: i. means for receiving telemetry data; ii. means for generating a data scripting file from said telemetry data; iii. means for storing received telemetry data, generated data script files, venue data, and visual models pertaining to said object of interest; and, iv. means for communicating data stored in said storage means to said client computer.

30. A computer racing game as recited in claim 24, wherein said data script file has a format comprising: a. a venue definition section; b. a group of base definitions for an object of interest; and, c. time stamped dimensional data section.

31. A computer racing game as recited in claim 24, wherein said regeneration means comprises a software agent for reading hypermedia files and communicating with said telemetry server and said network computer; and, a software game for receiving scripting data file information from said software agent.

32. A method for enabling live interaction of remote computer users with a live racing event, comprising the steps: a. collecting telemetry data from one or more racing cars in a racing event; b. generating a scripting data file for each racing car from a telemetry server based upon telemetry data received from each racing car, said scripting file including information about the venue of said racing event and modeling variables pertaining to said object of interest; c. sending said scripting data file to a client computer; and, d. in conjunction with software running on said client computer, regenerating a simulated rendition of said racing event based upon said scripting data file and displaying said rendition on a display device connected to said client computer.

33. The method as recited in claim 32, wherein said method repeats continuously such that said simulated rendition is updated continuously to create a continuous and near real-time rendition of said racing event.

34. The method as recited in claim 32, wherein said scripting data file is streamed to said client computer over a communications network such as the Internet.

35. The method as recited in claim 32, wherein said step of sending said scripting data file is initiated by a remote computer server in communication with said client computer and said telemetry server.

36. The method as recited in claim 35, wherein said remote computer server comprises an Internet web site, and wherein said sending step is initiated by a user of said client computer having accessed said Internet web site.

37. The method as recited in claim 32, wherein said generation step includes generating data specific to an advertisement for display on said client computer within said recreated event.

38. The method as recited in claim 32 , wherein prior to said generating step, receiving additional telemetry data pertinent to a selected race car from a manual operator to enhance position accuracy of said selected race car.

39. The method as recited in claim 32, wherein said client computer software inserts a user controlled, imaginary race car into said simulated rendition of said racing event for competition against live event race care drivers.

40. The method as recited in claim 39 further including the step of continuously recording said generated scripting data file in an archive database for delayed transmission or selected archive re-transmission of said sporting event to said client computer.

41. The method as recited in claim 32, further including the step of continuously recording said generated scripting data file in an archive database for delayed transmission or selected archive re-transmission of said sporting event to said client computer.

42. A method for collision avoidance of racing cars in a networked racing game having correspondence to a live racing event, comprising the steps of: a. assigning two dimensional locations to two proximal cars; b. determining whether a collision is imminent; c. selecting one car over the other to pass; d. determining whether the car selected in the previous selecting step should pass on the right or on the left of the other car; and e. adjusting the position of the car selected to pass to pass the other car without a collision on the side selected in the previous step.

43. The method as recited in claim 42, further including the step of sorting cars participating in the live event based upon the distance from the start/finish line on the event's race track.

44. The method as recited in claim 42, further comprising the step of avoiding collisions with obstructions and walls at the racing event.

45. A method for collision avoidance of two objects in a networked game having correspondence to a live event, comprising the steps of: a. assigning two dimensional locations to two proximal objects of interest in the live event; b. determining whether a collision is imminent between the objects; c. selecting one object over the other to pass; d. determining whether the object selected in the previous selecting step should pass on the right or on the left of the other object; and, e. adjusting the position of the object selected to pass to pass the other object without a collision on the side selected in the previous step.