Titre : TRACK EVENT DATA MANAGEMENT SYSTEM AND METHOD OF USE

Domaine Technique

The invention is directed to systems and methods for managing track event data. In particular, the invention is directed to systems and methods for saving and exchanging identified track event data obtained during one or more track events by users of a track event data management application of the system, wherein the exchanged track event data can be used by users to compare track event performances with oneself and/or among other users.

Technique anterieure

Driving enthusiasts often enjoy the innovation of driving as well as the spectacle, with sound, speed, color and vibration among the factors that contribute to a positive driving experience (as used herein,“driver”,“driving enthusiast”,“rider” and“operator” are interchangeable terms that refer to at least one person who operates one or more vehicles, including, but not limited to, cars, trucks, motorcycles, dirt bikes, etc.). Such people enjoy competing as drivers against others and against themselves, and they seek functions related to driving in one or more track events. To fulfill this desire, they can use network connections to connect with a variety of vehicles and their users during simulated and actual track competition events (see, for example, US Patent No. 9,248,378 directed to a system of remote racing that records and reports automobile data developed during a race between an automobile driver and a remote opponent).

Among driving enthusiasts are those who enjoy having different experiences while improving their driving skills during on-track competitions and track competition events (or“track events”). Whether the excitement of the unknown, the capacity to improve, the capacity to win or hands-on experience motivates driving enthusiasts, the capability of using network connections provides access to a variety of driving performance data that is produced during each track event. Such driving performance data can be saved and shared among users, not only as a means of tracking and comparing both long-term and short-term performance, but also to make corresponding modifications that are predicted to improve performance in subsequent track events (e.g., modifications made to driving techniques and/or to vehicle set up).

Users seeking driving performance data may find some of this data to be more useful while the user is in a vehicle during a track event. During the track event, the user is capable of modifying certain identified driver performance traits (for example, speed,

acceleration/deceleration, under steer/ over steer, etc.) that realize immediate improvement in driving performance. Such users may find some other of this data to be more useful in between track events (that is, while the vehicle is stopped), when the vehicle set-up can be optimized based upon the received driver performance data. During these“in-between” periods, users can realize modifications to the vehicle that are likely to improve driver performance in subsequent track events.

Accordingly, it is desirable to manage driver performance data, and particularly track event data, among multiple users both in real time and among offset times. A driver who considers all available track event data is better equipped to benefit from continuous improvement on the track, and thus derives more enjoyment from competition both on and off the track.

Resume de 1’ invention

The invention provides a track event data management system for saving and exchanging identified track event data that is obtained by at least one user of a track event data management application that employs the system during one or more track events. The system includes one or more tires to be used with a track event vehicle during the one or more track events; at least one sensor to be disposed in each tire for detecting at least one parameter relating to the condition of the tire during at least one track event; a receiver associated with the track event vehicle and in wireless communication with each sensor so as to receive track event data detected by each sensor; and a network-connected client device in wireless communication with the receiver and an application server to store and exchange identified track event data that is generated when the user participates in a track event, the client device having one or more processors and memory in which one or more programs are stored and configured to be executed by the one or more processors, the client device having a graphic user interface to which one or more processors are in operative communication with the client device, and the one or more processors including instructions for:

receiving an inquiry from a user associated with the identified track event data;

automatically performing an initial analysis of the inquiry to produce potential answers to the inquiry from the track event data;

automatically analyzing expressions used in the inquiry, the potential answers and the track event data to determine a quality measurement associated with the inquiry, the quality measurement being associated with an associated user as automatically determined by the client device; automatically generating at least one response to the inquiry based upon the quality measurement associated with the inquiry; and

outputting the at least one response to at least the associated user as automatically determined by the client device.

In some embodiments, the one or more processors include instructions for comparing identified track data from the track event with a threshold value for the identified track data; and associating one or more attributes to the identified track data when the identified track data satisfies the threshold value.

In some embodiments, the one or more processors include instructions for transmitting indicia representative of equivalence to the client device when the identified track data satisfies the threshold value; and transmitting indicia representative of non-equivalence to the client device when the identified track data does not satisfy the threshold value. In some of these embodiments, the identified track data includes a tire pressure value detected by the sensor installed in at least one tire, and the indicia representative of non-equivalence includes one or more tire pressure adjustment recommendations for satisfying the threshold value of the identified track data.

In some embodiments, the identified track data includes a tire temperature value detected by the sensor installed in at least one tire.

In some embodiments, the identified track data includes at least one of track-specific data values, run time values and track condition values. In some of these embodiments, the quality measurement associated with the inquiry includes a rating for the associated user with respect to at least one user-designated attribute; and the at least one response includes a response of relatively superior performance and relatively inferior performance based upon the quality measurement associated with the inquiry.

In some embodiments, the one or more processors include instructions for comparing a detected value for the user-designated attribute with a target value for the user-designated attribute that represents the threshold value; transmitting indicia representative of equivalence to the client device when the detected value for the user-designated attribute satisfies the threshold value; and transmitting indicia representative of non-equivalence to the client device when the detected value for the user-designated attribute does not satisfy the threshold value.

In some embodiments, the wireless communication is effected with Bluetooth technology. A computer-implemented method for managing track event data is also provided. The method includes the following steps:

receiving, from a network-connected client device associated with a user, an inquiry associated with a track event in a track event data management application that employs the disclosed system;

automatically performing an initial analysis of the inquiry to produce potential answers to the inquiry from the track event data ;

automatically analyzing expressions used in the inquiry, the potential answers and the track event data to determine a quality measurement associated with the inquiry, the quality measurement being associated with an associated user as automatically determined by the client device;

automatically generating at least one response to the inquiry based upon the quality measurement associated with the inquiry; and

outputting the at least one response to at least the associated user as automatically determined by the client device.

In some embodiments, the method also includes the step of associating, by the client device, a respective time value with each data point of the track event data. In some of these embodiments, the method also includes the step of accessing, by the client device, a model that correlates the identified track event data to a predetermined threshold value for the identified track event data, at which one or more attributes are associated with the identified track event data.

In some embodiments, the method also includes the following steps:

comparing the identified track event data with the threshold value for the identified track event data;

transmitting indicia representative of equivalence to the client device when the identified track event data satisfies the threshold value; and

transmitting indicia representative of non-equivalence to the client device when the identified track event data does not satisfy the threshold value.

In some embodiments, the step of transmitting indicia representative of non equivalence includes a step of transmitting one or more tire pressure adjustment

recommendations when the identified track data includes a tire pressure value corresponding to a tire pressure detected by the sensor installed in at least one tire. A kit for saving and exchanging identified track event data that is generated during at least one track event is also provided. The kit includes at least one sensor to be disposed in one or more corresponding tires that are mounted on a track event vehicle, each sensor detecting at least one parameter relating to the condition of a corresponding tire that is used during one or more track events; and a receiver associated with the track event vehicle and in wireless communication with each sensor so as to receive track event data detected by each sensor, the receiver configured for wireless communication with a network-connected client device that is in wireless communication with an application server to store and exchange identified track event data that is generated when the user participates in a track event, the client device having one or more processors and memory in which one or more programs are stored and configured to be executed by the one or more processors, the client device having a graphic user interface to which one or more processors are in operative communication with the client device, and the one or more processors including instructions for:

receiving an inquiry from a user associated with the identified track event data;

automatically performing an initial analysis of the inquiry to produce potential answers to the inquiry from the track event data;

automatically analyzing expressions used in the inquiry, the potential answers and the track event data to determine a quality measurement associated with the inquiry, the quality measurement being associated with an associated user as automatically determined by the client device;

automatically generating at least one response to the inquiry based upon the quality measurement associated with the inquiry; and

outputting the at least one response to at least the associated user as automatically determined by the client device.

Other aspects of the disclosed invention will become readily apparent from the following detailed description.

Breve description des dessins

The nature and various advantages of the presently disclosed invention will become more apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

FIG. 1 represents a schematic view of a track event data management system of the invention. FIG. 2 represents a schematic representation of tires intended to be mounted on wheel mounting rims of a track event vehicle for the system of FIG. 1 that generates track event data.

FIG. 3 shows an exemplary snapshot image of an interface of a client device of the system of FIG. 1.

FIG. 4 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing a means for selecting at least one track event vehicle.

FIG. 5 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing information specific to each tire of a track event vehicle.

FIG. 6 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing a means for selecting at least one track relative to which track event data is or has been generated.

FIG. 7 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing track event data associated with a selected track.

FIG. 8 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing exemplary indicia of customized and filtered track event data.

FIG. 9 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing a leaderboard corresponding to identified track event data.

FIG. 10 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing user-identified track event data.

FIG. 11 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing indicia of current characteristics of each tire during a track event.

FIG. 12 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing a gauge of track event vehicle behavior.

FIG. 13 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing recommended tire pressure adjustments representative of non equivalence of a tire pressure value and a target tire pressure value representing a threshold value.

FIG. 14 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing an exemplary manometer function.

FIG. 15 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing indicia of a track event vehicle together with one or more identified track event data. FIG. 16 shows an exemplary snapshot image of an interface of the client device of the system of FIG. 1 representing an exemplary replay function.

FIGS. 17 and 18 show flow chart diagrams of embodiments of methods manage track event data using the system of FIG. 1.

FIG. 19 shows an exemplary computing environment having data processing functionality.

Description detaillee

As used herein,“rating” and“ratings” are interchangeable terms that refer to one or more rankings assigned to a user as a result of one or more aspects of track competition.

As used herein,“leaderboard” refers to a ranked collection of ratings that is derived from one or more aspects of track competition stored in a network application and/or service.

As used herein,“track event” and“event” are equivalent terms that refer to any occurrence and/or activity that takes places during a track competition and/or any result thereof. Each track event may include a“run” or multiple“runs” with each run corresponding to a continuous length defined within the track event (for example, a circuit lap) and/or a time required to traverse the continuous length.

As used herein,“track competition” and“competition” are equivalent terms that refer to an entire competition and/or a portion of a competition that is effected on at least one existing track. Data corresponding to one or more tracks may be employed such that ratings can be effected among users on the same track and also among users on different tracks. In a competition, it is understood that a user can compete against one or more other users or against oneself (for example, the user wishes to improve upon results obtained in a previous track event completed by that user; two or more users wish to compete against each other, either on the same identified track or on two or more different tracks; one or more users wish to compete against one another in a newly identified track event, etc.).

“Identified track event data” refers to track data that is obtained and exchanged with respect to one or more associated attributes (or“attributes”). Attributes can be associated by any user-designated attribute (for example, club membership, vehicle ownership (regardless of any club affiliation or lack thereof), garage-associated vehicles, stable-associated vehicles, previous participation at one or more identified tracks, current or previous record holders at one or more track events, etc.). Attributes can include, but are not limited to, track-specific data (for example, track names, configurations and locations), run times (including track conditions and tire conditions upon attaining lap times) and track conditions, including conditions for track sections. Attributes can also include data concerning one or more characteristics associated with a track event vehicle (for example, tire pressure and/or temperature in one or more vehicle tires, fuel consumption data, etc.), data concerning track conditions (for example, weather and temperature conditions at the time of the track event, etc.) and data corresponding to characteristics and/or actions attributable to at least one user (for example, video data, voice data, virtual data, augmented data and combinations and equivalents thereof created by at least one user during a competition, etc.).

As used herein,“user” refers to a single user or a group of users. A user includes, but is not limited to, an individual participant in a track event, an individual member of a team or group that participates in a track event, a team or group participating in a track event and comprising one or more members, one or more vehicles associated with an individual or team that participates in a track event, one or more types of vehicles used in a track event and associated with an individual or team, a digital community associated with a track event, and combinations and equivalents thereof. The user may be a spectator that attends a track event, either physically or digitally (for example, by remotely watching a live track event so as to witness the driver’s experience in real time via visual, audio, tactile and other known interfaces).

As used herein,“user” (or“user device”,“client device”,“network-connected device”, “electronic device”,“device”) can also refer to any electronic apparatus configured for receiving control input and configured to send commands or data either interactively or automatically to at least one other device. A user device can be a user interface that is hosted on servers as retrieved by a user.

As used herein, the term "method" or "process" may include one or more steps performed at least by one electronic or computer-based apparatus having a processor for executing instructions that carry out the steps. Any sequence of steps is exemplary and does not limit the disclosed methods to any particular sequence.

Each method and process, in its entirety or during a portion thereof, can be controlled over a network via one or more network-connected devices, examples of which include, but are not limited to, one or more mobile telephones, one or more portables computers and/or tablets, or one or more other network-connected devices (including those devices having augmented reality, virtual reality and mixed reality capabilities), one or more items of wearable network-connected clothing and/or jewelry (including watches) and combinations and equivalents thereof). Any portable network-connected device can be used to record and save all data corresponding to a user’s track event. This data can be used in a surveillance mode by the same network-connected device or by any other network-connected device.

Now referring further to the figures, in which like numbers identify like elements,

FIG. 1 represents a schematic view of a track event data management system (or“system”)

10. The system 1 manages track event data by saving and exchanging identified track event data obtained during one or more track events. The identified track event data is obtained by users of a track event data management application that employs the system, wherein the exchanged track event data can be used by users to compare track event performances with oneself and/or among other users.

The system 10 includes one or more tires 12 having a summit with a tread for contacting the ground through a rolling surface. Each tire includes two beads that are intended to engage a rim, and two sidewalls that connect the summit and the beads. In a known manner, the tread of a tire, is provided with a sculpture including, in particular, tread elements or elementary blocks delimited by various grooves. The tire 12 may be selected from a plurality of commercially available competition tires, including but not limited to those with speed ratings (Y).

For a tire having a geometry of revolution with respect to an axis of rotation, the geometry of the tire is generally described in a meridian plane containing the axis of rotation of the tire. For a given meridian plane, the radial, axial and circumferential directions respectively designate the directions perpendicular to the axis of rotation of the tire, parallel to the axis of rotation of the tire and perpendicular to the meridian plane.

Each tire 12 has an outer axial edge and an inner axial edge, with the inner axial edge being the edge to be mounted next to the vehicle body when the tire is mounted on the vehicle V in the predetermined mounting direction and inversely for the outer axial edge. It is understood that a direction of mounting a tire 12 on the vehicle is predetermined by the manufacturer. Each tire 12 may therefore include means for indicating the direction of mounting of the tire on the rim. A user can then verify easily that the direction of mounting imposed on the rim has been respected. As used herein, "outer side of the vehicle" designates the outer axial edge.

FIG. 2 schematically shows tires as they are intended to be mounted on wheel mounting rims of a vehicle V and having a predetermined mounting direction on the vehicle: an inner side of the tire PINT corresponds to an inner axial side of the vehicle, and an outer side of the tire PEXT corresponds to the outer axial side of the vehicle.

Referring back to FIG. 1, the system 10 also includes at least one sensor 14 that is capable of being disposed in a corresponding tire 12. The sensor 14 may be detachably affixed to a corresponding tire 12 via a patch that may be integrated into the tire during its production. Alternatively, the sensor 14 may be provided with a rubber patch that forms an integral unit or module for attachment to the corresponding tire 10. In this manner, the placement of the sensor 14 relative to the tire 12 remains customizable as a function of the selected tire and sensor combination.

The sensor 14 may be selected from a plurality of commercially available sensing devices, including, but not limited to, sensors for capturing tire pressure and/or temperature, accelerometers and identification systems (for example, RFID). Before, after and during each track event, each sensor 14 detects track event data that is attributable to the corresponding tire within which the sensor is installed. Such data represents various characteristics about the tire 12, including its running parameters and its identification. The track event data is sent continuously, intermittently or on demand.

The sensor 14 may monitor, either continuously or periodically, corresponding tire pressures and/or temperatures. It is understood that the tire sensors 14 may have different modes for monitoring tire pressure and/or tire temperature (for example, a moving mode in which the tires are in rotation, a stationary mode in which the tires remain stationary, and an interim mode between consecutive tire pressure monitoring events, for example, between a stationary mode and a predetermined time in the moving mode). The track event data corresponding to the tire pressure data and/or the tire temperature data may be transmitted to a receiver (for example, a receiver 16 as discussed herein). One or more algorithms may be executed for determining a tire pressure level and/or a rate of inflation/deflation measured in a unit of time (for example, seconds).

The system 10 further includes a receiver 16 that receives the track event data generated by each sensor 14. In some embodiments, the receiver 16 is a radio frequency receiver module that is removably installed in the vehicle. For such embodiments, the receiver 16 can be placed inside the vehicle so as to optimize the reception of signals coming from the sensors 14 (for example, if four tires 12 each utilize at least one sensor 14, the receiver 16 may be placed in between the two front seats of a passenger car). The receiver 16 may include a cable that is in detachable communication with a power source (for example, the vehicle battery) to ensure continuous and reliable function of the receiver during a track event. It is understood that the receiver 16 can be associated with more than one vehicle.

The information received by the receiver 16 may include identified track event data such as tire pressure (including tire pressure variation), tire temperature (including tire temperature variation), wheel speed, acceleration (including acceleration variation), tread variation (including predicted tread wear) and related track event data (including track event data that can be calculated using one or more of the track event data captured by each sensor 14). Communication between the receiver 16 and each sensor 14 may be effected wirelessly using known communication means (for example, Bluetooth Technology or an equivalent thereof).

The system 10 is further provided with a client device 18 that is capable of being in wireless communication with at least one sensor 14 and the receiver 16. The client device 18 may be a mobile client device such as a smartphone (as represented by FIG. 1). The client device may be selected from a plurality of other mobile communication devices, including but not limited to, cellular/mobile phones, portable tablets and pads, portable or desktop computers, personal digital assistants, wearable garments and accessories (including watches and textiles), interactive devices (including devices having one or more of virtual reality, augmented reality and mixed reality interfaces) and combinations and equivalents thereof.

The client device 18 is configured to interact with an application server to capture and store identified track event data that is generated when the user participates in a track event. The identified track data can include a timeline of the user’s driving performance during a specific track event. The identified track data can also include a timeline of one or more users’ driving performance during multiple track events that occur over a predetermined time period.

The client device 18 involves one or more firmware and/or software applications that manage all exchanges of track event data among the sensors 14, the receiver 16 and a wireless network (represented as communications conduit 320 in FIG. 19). The application server, upon executing an application processor module, provides access to a plurality of modes of the track event data management application. The application server may be any type of server computing device, including one that is available in the cloud, and may be configured as one or more virtual machines executing on one or more hosts. The exchanges of track event data include any encryption keys and/or user information (include any identifying information) such that the user can continue to use the system 10 even when the user changes the client device 18.

The system 10 contemplates the creation of customizable tire and sensor combinations from which the receiver 16 can receive track event data. Therefore, one or more kits may be provided containing the receiver 16 and one or more different sensors 14 that are amenable for use with one or more different corresponding tires 12. A kit of this type may include a plurality of pre-assembled modules (for example, one or more pre-assembled units that include a sensor and patch that is readily integrated with a corresponding tire). In such kits, the receiver may be pre-tuned to facilitate proper data acquisition relative to one or more selected tires.

One or more kits may include, along with one or more modules, accompanying interactive software applications that may be downloaded on a desktop or uploaded from a remote site onto a mobile device. Instructions for use of the software applications may also be included in the kit along with resources for accessing any remote platforms that provide one or more users with an interface for collaboration with others. The kit may optionally include a mobile device having the software applications pre-loaded for ready use (for example, the client device 18, a disposable or“burner” phone, a wireless adapter, a dongle or an equivalent thereof).

The system 10 facilitates the capture of track event data that is generated during one or more track events. By way of example, the one or more track events can include a single track event in which multiple users are participants and/or spectators (either simultaneously or during a period covering the duration of user participation). The one or more track events can include multiple instances of the same type of track event on different tracks. The one or more track events can include multiple types of track events occurring on a single selected track.

Each track event can occur at one or more scheduled times. The system 10 can obtain the track event data at the corresponding scheduled time and exchange the obtained track event data at a later time (which may be scheduled or unscheduled depending upon whether the users wish to receive updated track event data on a continuous or on an intermittent basis). A user can select the track event(s) for participation and thereby trigger the generation of identified track event data attributed to the selected track event(s). As used herein, “participation” refers to physical participation in a vehicle at a physical track location. In some embodiments,“participation” can also refer to remote participation in a vehicle at a remote physical track location. In some embodiments,“participation” can also refer to remote participation via a network (for example, a remote user joins a driver at a physical track location to experience remotely the performance of the driver). Each user can actively review the track event performance of other users and oneself without detriment to any attributed performance ranking. The system 10 thus enables each user to customize the identified track data to be gathered at each track event and exchange only the identified track data having the desired attributes (as determined by comparison of the quality measurement of the gathered track data and the threshold quality measurement that invokes one or more attributes). In a method of exchanging identified track event data obtained during one or more track events, a user may want to identify specific track event data (“identified track event data”) for which a quality measurement will be obtained and compared against generated track event data having one or more shared attributes. As a user is progressing through a track competition, at least one attribute is associated with the identified track data that corresponds to a threshold value of the quality measurement. Upon generation of the identified track event data (“generated track event data”) during at least one track event, a determination is made as to whether the generated track event data exhibits a quality measurement corresponding to the threshold value of the quality measurement. The generated track event data represents actual data that is accurately captured from a live track event in real time.

In some embodiments, the user may want to surveille one or more track events with respect to the identified track event data and obtain corresponding quality measurements. It may be desirable to compare quality measurements among track event data having one or more track event attributes. It may also be desirable to exchange data corresponding to the compared quality measurements

Identified track event data can include any data related to a vehicle condition and/or set-up before, during and after a track event (“vehicle-related track data”). Vehicle-related track data can include generated tire data that is collected from a tire data management module including sensor 14. The tire data may be generated and collected at any time before, during and after a track event. The tire data can include, for example, current and/or projected tire pressure, current and/or projected tire wear, and current and/or projected tire temperature.

The user can personalize the identified track event data to include information that is unique to the user. This information can include, for example, identifying information, including avatars, clothing, symbols, shapes, icons, anatomical features and other features that are selected by and/or assigned to a user. This information can also include, for example, user profile data that includes the user’s present and past performance rankings in one or more track events. This information may also include, for example, whether the user has attributes that correspond to qualifying quality measurements for generated track event data so that the user is invited to participate in identified track events, either by the application or by other users.

FIG. 3 represents an exemplary snapshot image of an interface 20 of the client device 18 via which the user employs the track event data management application. The identified track event data to be generated, stored and/or exchanged is presented in the interface (for example, by one or more indicia). Examples of the identified track event data to be managed by the system 10 include, but are not limited to, track event data corresponding to one or more runs already completed by the user (represented in pane 20a as“My Runs”), one or more vehicles identified as being available to the user for a track event (represented in pane 20b as “My Garage”), one or more tracks that serve as locations for one or more track events

(represented in pane 20c as“The Circuits”), and one or more teams to which the user belongs (these may include teams in which the user is the sole member of the team)(represented in pane 20d as“My Teams”). It is understood that the identifiers for panes 20a, 20b, 20c, 20d are merely exemplary and that the user can personalize the identified track event data to be displayed in interface 20. The system 10 requires, however, the identification and

configuration of at least one vehicle relative to at least one track.

In order to configure at least one vehicle in the track event data management application, the user must identify at least one vehicle that the user will employ during a track event. FIG. 4 shows an exemplary snapshot image of the interface 20 of the client device 18 representing a means for selecting at least one vehicle for a track event (“track event vehicle”). The track event data management application may be pre-loaded with a plurality of track event vehicles, which may be identified by one or more characteristics (for example, the make or mark of the vehicle, the model and/or type of the vehicle, the vehicle’s year of production, the tires 12 to be mounted on the vehicle and their characteristics, etc.).

Alternatively, the user may add one or more track event vehicles according to the user’s desired configurations. The vehicles may be stored as single vehicles from which the user can select one for a selected track event. In some embodiments, the user may select one or more track event vehicles from a vehicle garage that includes a variety of track event vehicles having different characteristics and configurations. In some embodiments, the user may select one or more track event vehicles from a vehicle stable that includes a variety of track event vehicles having at least one shared characteristic (for example, a stable of cars of the same model and produced by the same manufacturer but during different years of production). For all embodiments, the tires corresponding to the stored track event vehicles must always correspond to one or more tires 12 of the system 10 having sensors 14 and receiver 16 in operative communication therewith.

In the context of configuring a selected track event vehicle, the user can monitor and manage tire wear by reviewing the track event data associated with each vehicle tire. FIG. 5 shows an exemplary snapshot image of the interface 20 of the client device 18 representing information specific to each tire 12 of a track event vehicle 22. The displayed information can include, but is not limited to, each tire’s dimensions, speed rating, manufacturer- recommended pressure, identification and placement on the vehicle 22. The track event data management application can manage the data associated with the date that each tire was mounted on the vehicle. This data, along with the track event data corresponding to the mounted tires and the elapsed time since the date of tire mounting, can be used to alert the user when tire rotation is recommended. An alert may be issued that corresponds to a recommended tire rotation, which alert may include indications of recommended rotation placement (see the arrows of FIG. 5).

Referring again to the interface 20 of the client device 18 represented in FIG. 1, and referring further to the interface 20 as represented in FIG. 6, the user can access track data so as to select one or more tracks or circuits relative to which track event data is or has been generated (represented in pane 20c of FIG. 1 as“The Circuits”). The system 10 can include provisions for referencing track data, which can be stored by the track event data management system and/or received periodically (including receipt on an as-needed basis). Updates to the track data can be effected continuously or intermittently as designated by the user. The track data can be provided by various centralized and/or decentralized sources, including but not limited to one or more of commercially available navigation system providers, road transmitters and other vehicles. It is understood that the user may modify the selection of tracks for which track event data is stored and exchanged by the system 1.

Referring to interface 20 of the client device 18 as represented in FIG. 7, an exemplary snapshot image is provided that represents track event data associated with the selected track. The track event data associated with the selected track may include a track outline and/or track cartography (see pane 20e of FIG. 7), the user’s best times realized during track events on the selected track (see pane 20f of FIG. 7), the overall best time for a track event on the selected track established by users of the track event data management application (see pane 20g of FIG. 7) and the teams with which the user has participated in track events on the selected track (along with representative track event data for each time)(see panes 20h of FIG. 7). It is understood that other track event data may be stored and exchanged within the track event data management application that employs the system 10.

For each type of track event data that is stored and exchanged, the user can filter the track event data and customize the filtered track event data to obtain identified track event data for comparison. For example, a customized filter may show the user’s best run times when driving a specified track event vehicle in different track conditions (see the exemplary interface 20 of the client device 18 as represented in FIG. 8). For any selected circuit, the track event data management application employing the system 1 can store and exchange the best driver performance for identified track event data. Such performance can be represented as one or more ratings that are assigned to the user and to other users’ track event data management application who participate in track events at the selected track. A quality measurement associated with an inquiry made to the track event data management application can include a rating for the associated user with respect to at least one user-designated attribute.

On the basis of the quality measurement associated with the inquiry, the track event data management application generates at least one response that includes a response of relatively superior performance and relatively inferior performance. Each user may access a leaderboard corresponding to the identified track event data in order to determine the user’s driving performance relative to other users (see the pane 20i of the exemplary interface 20 as represented in FIG. 9). The system 1 may update the ratings and/or the leaderboard continuously, intermittently or on demand. The users that are ranked may be individual users within a team or entire teams (for example, teams that utilize track event vehicles from the same stable, or teams competing against each other in the same division).

In some embodiments, the track data that is referenced by the system 10 includes map data that can be received on an as-needed basis according to a user’s location (see the map icon 24 of FIG. 7). The map data can be acquired from GPS information that is received from a GPS receiver as is known in the art. The map data can be used to provide directions to users for traveling to one or more tracks where one or more track events occur. The map data may be acquired from determining the shortest path between nodes in a network comprising a plurality of nodes (for example, as disclosed by US Patent No. 8,861,506). The map data may also be used to provide a virtual, augmented and/or mixed reality experience to a remote user who elects to remotely witness an ongoing track event. In such embodiments, the user is also a spectator.

In some embodiments, the track data that is referenced by the system 10 includes weather-related data that is generated according to one or more of the track location and the user’s current location. The weather-related data can be acquired from a third-party application. The weather-related data can be collected from one or more sensors that sense conditions in and around the track event vehicle. Such sensors may be integral with the track event vehicle. Such sensors may be associated with one or more other track event vehicles that collect sensed weather-related data that is subsequently stored and exchanged with the user. The weather-related data can be used to generate meteorological profiles for a track event. For example, users may modify their vehicle setup (including tire pressures) in reliance upon one or more meteorological profiles that demonstrate typical weather conditions at a selected track. In some embodiments, topological and geological data may complement the weather-related data to give the user a more precise understanding of the actual track conditions.

Reference is now made to the interface 20 of the client device 18 as represented in FIG. 10. After selecting the track event vehicle and after identifying the track where a track event will occur, the track event data management application employing the system 1 permits the selection of the applicable track conditions (for example, dry, wet, humid, temperate, extreme heat, extreme cold, etc.)(see pane 20j of FIG. 10). These track conditions may be selected by a user as identified track event data that will be generated, stored and exchanged by the system 1.

Referring to an exemplary snapshot image of the interface 20 of the client device 18 as represented by FIG. 10 (and particularly pane 20k), the track event data management application employing the system 1 associates recommended tire pressures (for front and rear tires) with the applicable track conditions. The recommendations may be manufacturer recommendations for the declared tire use. Alternatively, the recommendations may be user recommendations for the declared tire use using track event data that has been generated by other users in the same conditions and driving the same and/or similar track event vehicles. Visual indicia may be provided that correspond to the tire pressures that are the most adapted to the declared usage. For example, color coding and/or symbols may be used that indicate automatically whether the affected tire is at a pressure within the recommended range of pressures for the selected track event vehicle in the identified conditions.

The track event data management application employing the system 1 can capture track event data both during one or more“warm up” events and during one or more track events. A user can directly interact with the interface 20 to designate whether the track event data to be generated is associated with a warm up event (designated as“WARM-UP” in pane 201 of the interface 20 represented by FIG. 10) or with a live track event (designated as“GO!” in pane 20m of the interface 20 represented by FIG. 10).

Upon designating the generation and collection of track event data, the track event data management application employing the system 1 commences a sequence of track event data collection. During each sequence of track event data collection, each sensor 14 collects track event data representative of current characteristics of the corresponding tire 12. The sensors 14 transmit signals representative of the current tire characteristics to the receiver 16 so as to generate track event data for the track event data management application. The track event data management application determines which of the generated track event data qualifies as identified track event data. In addition to current tire characteristics, the track data management system 10 is configured to exchange various types of track event data on the network, including but not limited to, vehicle position at a track section, vehicle speed (at a track section) and vehicle trajectory.

Referring to an exemplary snapshot image of the interface 20 of the client device 18 as represented by FIG. 11, the current characteristics of each tire 12 are displayed and may contain identified track event data. As shown, a current pressure and a current pressure for each tire 12 are displayed. The track event data management application employing the system 1 can update the tire characteristics in correspondence with the periodicity of data capture by the sensors 14 (continuously, intermittently, on-demand). Visual indicia may be provided that indicate automatically whether each tire is at a pressure and/or temperature within the recommended range of pressures and/or temperatures for the selected track event vehicle subject to the current track conditions.

In some embodiments, the track event data management application employing the system 1 can employ a chronometer that is automatically triggered upon commencing a track event (see pane 20n of the interface 20 represented by FIG. 11). The chronometer may be triggered as a function of the GPS coordinates for the timekeeping line declared in the track event data management application. While it is understood that this virtual line may not always match the physical timing line of the circuit, this does not change the quality of the measurement.

The resulting time measurement may be stored and exchanged as identified track data. In this manner, the user may consult one or more reference times and determine how the reference times will affect the user’s ranking. The chronometer may use various indicia that indicate automatically the user’s time performance. For example, if, during the track event, the user has achieved the best time for the circuit (including the user’s own best time and other users’ times), the chronometer may use a“plus” sign (+) and/or green indicia. If the user is slower than the user’s own best time or slower than other users’ times, the indicia used may be a“minus” sign (-) and/or red indicia. The track event times may be stored and exchanged as identified track event data that may be filtered according to the associated indicia.

Referring to an exemplary snapshot image of the interface 20 of the client device 18 as represented by FIG. 12, the track event data management application employing the system 1 can, on the basis of the generated track event data, generate indicia corresponding to the evolution of the pressures sensed in the tires 12. This information can be relied upon to generate a comparison with the evolution of the equilibrium of the track event vehicle. For example, as shown in figure 12, a gauge 26 is generated that can indicate understeer and oversteer, thereby suggesting potential modifications of tire pressure and/or driving behavior to the user (see pane 20o of the interface 20 represented by FIG. 12). A user experiencing understeer will feel that the vehicle "slides forward" and may thus exaggerate the angle put on the steering wheel in order to enter the vehicle in a turn. A user experiencing oversteer will feel that the vehicle "slips from behind" and may thus risk spinning the vehicle if the tendency to oversteer is very noticeable. The user may therefore examine the gauge and modify the tire characteristics (for example, during a pit stop or in between runs during a track event).

Referring to an exemplary snapshot image of the interface 20 of the client device 18 as represented by FIG. 13, the track event data management application employing the system 1 can determine a change in pressure for each tire 12, which change in pressure can be considered as identified track event data. Consequently, the track event data management application, relying upon this change in tire pressure, will display its recommendations for tire pressure modification to the user. In the example represented by FIG. 13, the track event data management application recommends a reduction of the tire pressure for all four tires. It is understood that a recommended tire pressure adjustment (including a recommendation to increase tire pressure and a recommendation to decrease tire pressure) may be displayed for one or more of the tires.

In some embodiments, the user can engage the track event data management application to adjust the tire pressures as recommended by the application (see the pane 20p of the interface 20 of FIG. 13 designated“Adjust My Pressures”). In such embodiments, the track event data management application employing the system 1 includes a manometer function that enables the user to realize the recommended tire pressure adjustments.

Referring to an exemplary snapshot image of the interface 20 of the client device 18 as represented by FIG. 14, the manometer function shows the extent to which each tire pressure should be adjusted for those tires requiring pressure adjustment. Visual indicia may be provided that indicate automatically whether the user has attained the requisite

inflation/deflation that attains the recommended tire pressure adjustment. For example, if the tire does not require any adjustment of tire pressure, the manometer may use an“OK” indicator and/or green indicia (see panes 20q and 20r of the interface 20 represented by FIG. 14). If the tire requires adjustment, the manometer may show the required numerical adjustment and/or yellow or red indicia (see panes 20s and 20t of the interface 20 represented by FIG. 14). The tire pressure adjustments may be stored and exchanged as identified track event data that may be filtered according to the associated indicia (for example, to enable the user to contribute to recommended tire pressure settings and also to permit the construction of data upon which a machine-learning function may be based) .

Referring to an exemplary snapshot image of the interface 20 of the client device 18 represented by FIG. 15, the track event data management application employing the system 1 can present the user with a visual representation of the track event vehicle together with one or more identified track event data upon which a comparison will be based. In the example represented by FIG. 15, the selected track event vehicle is shown with at least one of sensed tire pressure data and sensed tire temperature data being displayed during the course of a track event.

Visual indicia may indicate the current tire characteristics. For example, a tire may appear green on the interface 20 if its currently sensed pressure and/or temperature fall within a range of acceptable values. A tire may appear yellow or red on the interface 20 if the currently sensed pressure and/or temperature fall outside of a range of acceptable values. The user may toggle between representations of the interface 20 so as to view only one of currently sensed tire pressure data and currently sensed temperature data (see the tire icon 28 and the temperature icon 30 of interface 20 represented in FIG. 15). It is understood that both pressure and temperature data may be displayed on the interface 20. The user may select one or more specific tires and elect to display only the currently sensed pressure and/or temperature data for the selected tire(s) on the interface 20.

Referring further to the exemplary interface 20 of the client device 18 as represented by FIG. 15, the track event data management application employing the system 1 can employ chronological or timing function (represented by timeline 32). The timing function allows the user to follow the progression of the tire characteristics, including the ability to go backwards and determine trends in the tire characteristics. The timing function allows the user to access snapshot images of the sensed tire pressure data and/or the sensed tire temperature data during the track event. In the example shown in FIG. 15, the currently rendered image of the track event vehicle shows a snapshot image of the tire pressure data at point 7: 18 of progression through the track event. The snapshot images along the timeline 32 may be presented as thumbnails that may be selected by the user for enlargement. It is understood that FIG. 15 illustrates an exemplary progression through the track event and not necessarily any time lapse that may affect the generated identified track data.

The track event for which the track event data management application employing the system 1 generates track event data may terminate automatically (for example, upon completion of a user-defined track event). Alternatively, the user can engage the interface 20 of the client device 18 to terminate the generation of track event data for the current track event (represented as a“STOP” icon on the exemplary interfaces represented by FIGS. 11 and 12).

Referring to an exemplary snapshot image of the interface 20 of the client device 18 as represented by FIG. 16, the track event data management application employing the system 1 can include a replay function. The replay function can include a graphical representation of the track upon which the user has completed a track event (see pane 20u of the interface 20 of FIG. 16). The replay function can also include a representation of corresponding track event data (including identified track event data), including, but not limited to, lap duration and lap identification (see pane 20v), the timing progression (pane 20w), the best lap time (pane 20x), the track event vehicle’s speed (see pane 20y), indicators of lateral and longitudinal G forces (see pane 20z) and tire pressures sensed by the sensors 14 of the system 10 (see pane 20aa). The graphical representation that is presented by the replay function may be schematic, or it may be a video of the track event using live-captured video footage of the user.

It is understood that the track event data management application employing the system 1 is not limited to use for track events and other competition events. The track event data management application employing the system 1 may be employed also during use of the stored track event vehicles in non-track event applications (for example, in traveling along an autoroute). The track event data management application employing the system 1 can generate, store and exchange non-track event data in the same manner as described herein with respect to track event data.

The track event data management application employing the system 1 can generate a response to a user-originated inquiry concerning track event data and identified track event data. The generated response corresponds to at least one of an exchange of identified track data and a receipt of exchanged identified track data. A generated response can be represented in any known manner, including but not limited to audible means, visual means, tactile means (for example, haptic interface), virtual/augmented/mixed reality means and any combination and/or equivalent thereof.

It is understood that the system 1 is capable of incorporating random track event data that is generated by an artificial intelligence module. This random track event data may be added in an overlay in order to further engage users and enhance the user experience. For example, a user may be randomly generated to provide an additional source of competition. This randomly generated user may have qualifying track event data against which other users may compare their own generated track event data.

In some embodiments, the track data management system 10 includes an option to provide overlays configured to be exchanged with one or more users. For example, these overlays may include user rankings, messages to the user, images of track events or portions of track events, video feeds of track events, etc. In some embodiments, these overlays may include a virtual input device (e.g., a virtual keyboard or button). In some embodiments, these overlays may include sound overlays (e.g., a user’s voice is overlaid on an audio stream; a vehicle engine is overlaid on a video stream, etc.)

It is understood that system 1 can exchange track event data with a vehicle’s collision warning system. Various collision warning systems are known to map upcoming road or track sections for an obstacle (including another vehicle) and to evaluate potential vehicle travel paths based upon the travel history of other users’ vehicles in the same sections. On the basis of this evaluation, the vehicle collision warning system can detect and alert users to potential collisions at the evaluated road or track section (see, for example, the vehicle collision system disclosed by US Patent No. 8,903,639).

In some embodiments, the system 1 may be configured such that each combination (for example, each track, vehicle and/or driver combination) has a threshold quality measurement at which a track event involving that combination qualifies as an attributed track event. Attributes that are assigned to qualifying track events can include, for example, the following:

- hot laps : The pursuit of the fastest lap generates track event data relative to one or more of a specific track, a specific track event, a specific team, a specific vehicle brand, a specific vehicle set-up, specified track conditions, a specific vehicle stable, etc.

- challenges: The establishment and customization of challenges by users generates track event data relative to single-lap races and multi-lap races (including endurance races and races having one or more pit stops).

- vehicle set-up: The selection of vehicle parameters before a track event and the adjustment of vehicle parameters during a track event generates track event data (for example, with respect to tire selection, tire pressure, tread wear, suspension adjustment, brake bias adjustment, etc.).

It is understood that, in some embodiments, default attributes are assigned to some qualifying track events. For example, if it is known that an identified team competes regularly on a known track, track event data can be generated by default that includes information about the team, their vehicles and the track.

Referring now to FIGS. 17 and 18, a method of utilizing the system 10 is described with respect to exemplary modes of the track event data management application. It is understood that the use of time throughout the disclosure illustrates examples of performance and/or progression during one or more track events, and not necessarily a measure of duration during which the user uses the track event data management application.

FIG. 17 depicts a flow chart diagram of steps of an exemplary method 200 to manage track event data according to example embodiments of the present disclosure. The method 200 can be implemented by one or more computing devices. In particular, as examples, the method 200 can be implemented by the system 10 discussed with reference to FIG. 1.

At step 202, an inquiry associated with a track event in a track event data management application that employs the system 10 is received from a network-connected client device associated with a user.

At step 204, an initial analysis of the inquiry is automatically performed in order to produce potential answers to the inquiry from the track event data.

At step 206, expressions used in the inquiry, the potential answers and the track event data are automatically analyzed to determine a quality measurement associated with the inquiry, the quality measurement being associated with an associated user as automatically determined by the client device. As used herein,“expressions” can include alphabet letters, numerals, lexis, symbols, graphics, sounds and other indicia of values representing track event data.

At step 208, at least one response to the inquiry is automatically generated based upon the quality measurement associated with the inquiry.

At step 210, the at least one response is output to at least the associated user as automatically determined by the client device.

In some embodiments of the method 200, the method also includes a step of associating, by the client device, a respective time value with each data point of the track event data.

In some embodiments of the method 200, the method may also include a step of accessing, by the client device, a model that correlates the identified track event data to a predetermined threshold value for the identified track event data, at which one or more attributes are associated with the identified track event data. Such embodiments may also include additional steps as depicted in the flow chart diagram of FIG. 18. At step 212, the identified track event data is compared with the threshold value for the identified track event data.

At step 214, indicia representative of equivalence is transmitted to the client device when the identified track event data satisfies the threshold value.

At step 216, indicia representative of non-equivalence is transmitted to the client device when the identified track event data does not satisfy the threshold value.

It is understood that the identified track data can include a tire pressure value detected by the sensor (14) installed in at least one tire (12). In such embodiments, the indicia representative of non-equivalence includes one or more tire pressure adjustment

recommendations for satisfying the threshold value of the identified track data. It is further understood that the identified track data can include a tire temperature value detected by the sensor (14) installed in at least one tire (12).

FIG. 19 sets forth illustrative data processing functionality 300 that can be used to implement any aspect of the functions described herein, including implementation in connection with a computing device (including a mobile networking apparatus) that includes hardware, software, or, where appropriate, a combination of both. In one case, the processing functionality 300 may correspond to any type of computing device that includes one or more processing devices. The computing device can include any type of computer, computer system or other programmable electronic device, including a client computer, a server computer, a portable computer (including a laptop and a tablet), a handheld computer, a mobile phone (including a smart phone), a gaming device, an embedded controller and any combination and/or equivalent thereof (including touchless devices). Moreover, the computing device may be implemented using one or more networked computers, e.g., in a cluster or other distributed computing system. It is understood that the exemplary

environment illustrated in FIG. 19 is provided as an example, and that other alternative hardware and/or software environments may be used without departing from the scope of this disclosure.

As used herein,“server” refers to one or more servers, each of which can include one or more computers that manage access to a centralized resource or service in a network. A server can also include at least one program that manages resources (for example, on a multiprocessing operating system where a single computer can execute several programs at once). Further, the terms“computing device”,“computer device”,“computer” and“machine” are understood to be interchangeable terms and shall be taken to include any collection of computing devices that individually and/or jointly execute a set (or multiple sets) of instructions to perform any one or more of the described functions.

As used herein,“mobile phone”,“portable phone”,“mobile device”,“portable device”,“wireless mobile device”,“wireless portable device”, and“wireless device” may be used interchangeably, in the singular or plural, to refer to smartphones, PDAs, tablets, near- field communication devices, devices with applications implemented at least partly using a cloud service and any other complementary and equivalent devices (including those having virtual reality, augmented reality and/or mixed reality capabilities) . The processing functionality 300 can include volatile memory (such as RAM 302) and/or non-volatile memory (such as ROM 304 as well as any supplemental levels of memory, including but not limited to cache memories, programmable or flash memories and read-only memories). The processing functionality can also include as one or more processing devices 306 (e.g., one or more central processing units (CPUs), one or more graphics processing units (GPSs), one or more microprocessors (mR) and similar and complementary devices) and optional media devices 308 (e.g., a hard disk module, an optical disk module, etc.).

The processing functionality 300 can perform various operations identified above with the processing device(s) 306 executing instructions that are maintained by memory (e.g., RAM 302, ROM 304 and elsewhere). Any method disclosed herein may also be practiced via communications embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a client computer, or the like, the machine becomes an apparatus for practicing the presently disclosed method and system. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates to invoke the functionality of the presently disclosed method and system. Additionally, any storage techniques used in connection with the presently disclosed method and/or system may invariably be a combination of hardware and software.

The processing functionality 300 also includes an input/output module 310 for receiving various inputs from a user (via input modules 312) and for providing various outputs to the user. One particular output mechanism may include a presentation module 314 and an associated graphical user interface (GUI) 316 incorporating one or more I/O devices (including but not limited to displays, keyboards, keypads, mice and/or other pointing devices, trackballs, joysticks, haptic feedback devices, motion feedback devices, voice recognition devices, visual recognition devices (including facial recognition devices), digital imprint recognition devices, microphones, speakers, touch screens, touchpads, webcams, one or more cameras, gesture capture and recognition devices, devices incorporating touchless technologies and equivalent and complementary devices that enable operative response to user commands and inputs). It is understood that user input may be received via a computing device coupled to another computing device over a network.

Inputs that generate track event data include video streams of one or more users. The video streams can be exchanged and displayed for viewing (it is understood that access to the video streams is optional and can be customized to limit their accessibility, for example, to those users having attributes in common with qualifying identified track event data). Each user may receive a separate video stream, or a single video stream may include portions of a track event generated specifically for each user having a qualifying attribute (e.g., drivers having attained a minimum lap time on a specified track in wet conditions using rain slicks).

The processing functionality 300 can also include one or more network interfaces 318 for exchanging data with other devices via one or more communication conduits (or networks) 320. One or more communication buses 322 may communicatively couple the above-described components together. A bus 322 can represent one or more bus structures and types, including but not limited to a memory bus or memory controller, a peripheral bus, a serial bus, an accelerated graphics port, a processor or local bus using any of a variety of bus architectures and similar and complementary devices. This configuration may be desirable where a computing device is implemented as a server or other form of multi-user computer, although such computing device may also be implemented as a standalone workstation, desktop, or other single-user computer in some embodiments. In such configuration, the computing device desirably includes a network interface in operative communication with at least one network.

It is understood by those skilled in the art that storage devices utilized to provide computer-readable and computer-executable instructions and data can be distributed over a network. It is understood that the terms“network” and“network-connected” can refer to wired and/or wireless portions as well as cellular, radio and optical links. The terms “network” and“network-connected” can refer to one or more of the Internet, at least one local area networks (LANs), at least one wide-area networks (WANs), at least one storage-area network (SAN) and combinations and equivalents thereof. It is understood by a person of skill in the art that any and all data, as well as instructions corresponding thereto, can be distributed over a network.

It is understood that the term“network” and“network-connected” can refer to cloud based systems and applications that employ computing resources (hardware and software) to deliver services over a network (e.g., the internet). The services, in the context of competition, enable streaming of content to remote users, wherein most processing is done on servers, which may be distributed. Input provided at the remote users will in turn drive exchange of attributed track data without the need for dedicated hardware at the user's location. Cloud- based track competition data management therefore renders remote track competition data accessible to multiple users in remote locations who wish to compete with one another and/or track one another’s track event performance. Users can access more identified track data having the desired attributes without hardware restrictions.

The exchange of the identified track event data may be realized over a cloud network.

In some embodiments, the cloud network may include one or more virtual machines (VMs) running on a host machine.

While the embodiments described herein refer to an example of the system 1 using passenger car tires, it is understood that, as used herein, the term "tire" includes, but is not limited to, one or more tires used for any vehicle that is amenable to participation in a track event.

The terms "at least one" and "one or more" are used interchangeably. Ranges that are described as being "between a and b" are inclusive of the values for "a" and "b."

While particular embodiments of the disclosed apparatus have been illustrated and described, it will be understood that various changes, additions and modifications can be made without departing from the spirit and scope of the present disclosure. Accordingly, no limitation should be imposed on the scope of the presently disclosed invention, except as set forth in the accompanying claims.