U.S. patent application number 13/354003 was filed with the patent office on 2012-08-23 for headgear position and impact sensor.
This patent application is currently assigned to X2Impact, Inc.. Invention is credited to Christoph Mack.
Application Number | 20120210498 13/354003 |
Document ID | / |
Family ID | 46516081 |
Filed Date | 2012-08-23 |
United States Patent
Application |
20120210498 |
Kind Code |
A1 |
Mack; Christoph |
August 23, 2012 |
HEADGEAR POSITION AND IMPACT SENSOR
Abstract
A protective headgear position and impact sensor is described
for use with hard hats, helmets, or other headgear. Proximity
sensors are used to detect whether the headgear is being worn by
the user. In some versions of the invention, additional features
determine the nature of a head impact and store data related to
wear of the headgear by the user. Yet other features may allow the
headgear to serve as a security device, allowing entry into a
facility only if the headgear is in position and if it is properly
associated with an authorized individual who is wearing the
headgear
Inventors: |
Mack; Christoph; (Seattle,
WA) |
Assignee: |
X2Impact, Inc.
Seattle
WA
|
Family ID: |
46516081 |
Appl. No.: |
13/354003 |
Filed: |
January 19, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61434325 |
Jan 19, 2011 |
|
|
|
Current U.S.
Class: |
2/414 ; 2/209.13;
2/410; 2/425 |
Current CPC
Class: |
A42B 3/0466
20130101 |
Class at
Publication: |
2/414 ; 2/209.13;
2/410; 2/425 |
International
Class: |
A42B 3/04 20060101
A42B003/04; A63B 71/10 20060101 A63B071/10; A42B 3/12 20060101
A42B003/12; A42B 1/00 20060101 A42B001/00 |
Claims
1. A headgear, comprising: a head-covering portion configured to
cover at least a portion of the head of a user, the head-covering
portion having an interior side and an exterior side; and one or
more proximity sensors positioned on the head-covering portion and
configured to detect whether the head-covering portion is
positioned atop the head of the user.
2. The headgear of claim 1, wherein the head-covering portion is a
hard-hat.
3. The headgear of claim 2, wherein at least one of the proximity
sensors is secured within the interior side of the hard-hat.
4. The headgear of claim 3, wherein the headgear further comprises
a suspension attached within the interior of the hard-hat, and
further wherein at least one of the proximity sensors is attached
to the suspension.
5. The headgear of claim 2 wherein the proximity sensors comprise
sensors of two or more different types.
6. The headgear of claim 2, wherein the proximity sensors comprise
at least one capacitive sensor and at least one optical sensor.
7. The headgear of claim 2, further comprising a user input device
mounted on the headgear, the user input device being configured to
receive an input identifying the user.
8. The headgear of claim 7, wherein the user input device is a
keypad.
9. The headgear of claim 7, further comprising a transmitter
configured to transmit a code indicating that the headgear is in
position atop the head of the user, as a function of an input
received by the one or more proximity sensors.
10. The headgear of claim 9, wherein the transmitter is further
configured to transmit a code identifying the user.
11. The headgear of claim 2, further comprising a processor and a
memory in communication with the one or more proximity sensors, the
memory being configured to store an indication of the times during
which the headgear is in position atop the head of the user as a
function of an input received by the one or more proximity
sensors.
12. The headgear of claim 2, further comprising one or more impact
sensors.
13. The headgear of claim 12, further comprising a processor and a
memory in communication with the one or more proximity sensors and
the one or more impact sensors, the memory being configured to
store an indication of the times during which the headgear is in
position atop the head of the user as a function of an input
received by the one or more proximity sensors, the memory further
being configured to store an indication of the times during which
the headgear experienced an impact event, as a function of an input
received by the one or more impact sensors.
14. The headgear of claim 1, wherein the head-covering portion is a
sports helmet.
15. The headgear of claim 14, wherein at least one of the proximity
sensors is secured within the interior side of the helmet.
16. The headgear of claim 15, wherein the headgear further
comprises padding attached within the interior of the helmet, and
further wherein at least one of the proximity sensors is attached
to the padding.
17. The headgear of claim 15 wherein the proximity sensors comprise
sensors of two or more different types.
18. The headgear of claim 15, wherein the proximity sensors
comprise at least one capacitive sensor and at least one optical
sensor.
19. The headgear of claim 15, further comprising a transmitter
configured to transmit a code indicating that the headgear is in
position atop the head of the user, as a function of an input
received by the one or more proximity sensors.
20. The headgear of claim 15, further comprising one or more impact
sensors.
Description
PRIORITY CLAIM
[0001] This application claims the benefit of prior U.S.
provisional application Ser. No. 61/434,325, filed Jan. 19, 2011,
the contents of which are hereby incorporated by reference.
BACKGROUND OF THE INVENTION
[0002] There are many situations in which a helmet, hard-hat, or
other protective headgear is essential. For example, many jobs are
performed in hazardous areas requiring a hard hat for protection.
Some example jobs include building or road construction,
manufacturing involving hazardous machinery or materials, logging,
and many others. In some of these settings it can be difficult to
perfectly police the use of headgear by those personnel in areas
that require it. Some may choose not to wear the headgear at all,
while others may remove it from time to time even in hazardous
situations. When employees or other personnel choose not to wear
protective headgear in hazardous situations it exposes those
individuals to a greater risk of head injury. In addition, it
exposes managerial personnel and company owners to liability that
may result from such injuries. Ideally, no personnel would be
allowed entry to a hazardous area without having protective
headgear in place.
[0003] The challenge of preventing head injuries also extends to
athletics. Participation in athletic activities is increasing at
all age levels. All participants may be potentially exposed to
physical harm as a result of such participation. Physical harm is
more likely to occur in athletic events where collisions between
participants frequently occur (e.g., football, field hockey,
lacrosse, ice hockey, soccer and the like). In connection with
sports such as football, hockey and lacrosse where deliberate
collisions between participants occur, the potential for physical
harm and/or injury is greatly enhanced. Approximately 300,000
athletes incur concussions in the United States each year. This may
be a conservative estimate because many minor head injuries go
unreported. Although most concussions occur in high-impact sports,
athletes in low-impact sports are not immune to mild traumatic
brain injury. Head injuries are caused by positive and negative
acceleration forces experienced by the brain and may result from
linear or rotational accelerations (or both). Both linear and
rotational accelerations are likely to be encountered by the head
at impact, damaging neural and vascular elements of the brain.
[0004] At the school level, school authorities have become
sensitive to the risk of injury to which student participants are
exposed, as well as to the liability of the school system when
injury results. Greater emphasis is being placed on proper training
and instruction to limit potential injuries. Some players engage in
reckless behavior on the athletic field or do not appreciate the
dangers to which they and others are subject by certain types of
impacts experienced in these athletic endeavors. Unfortunately, the
use of mouth guards and helmets does not prevent all injuries. One
particularly troublesome problem is when a student athlete
experiences a head injury, such as a concussion, of undetermined
severity even when wearing protective headgear. Physicians,
trainers, and coaches utilize standard neurological examinations
and cognitive questioning to determine the relative severity of the
impact and its effect on the athlete. Return to play decisions can
be strongly influenced by parents and coaches who want a star
player back on the field.
[0005] The same problem arises in professional sports where the
stakes are much higher for a team, where such a team loses a
valuable player due to the possibility of a severe head injury.
Recent medical data suggests that lateral and rotational forces
applied to the head and neck area (for example, flexion/extension,
lateral flexion, and axial rotation) are more responsible for
axonal nerve damage than previously thought. Previous medical
research had indicated that axially directed forces (such as spinal
compression forces) were primarily responsible for such
injuries.
[0006] Identifying the magnitude of acceleration that causes brain
injury may assist in prevention, diagnosis, and return-to-play
decisions. Most field measurements assess the acceleration
experienced by the player with accelerometers attached to the
helmet. The following show some attempts for measuring the impacts
to the skull and brain while the player is participating in a
sporting activity. U.S. Pat. No. 5,539,935, entitled "Sports
Helmet," issued on Jul. 30, 1996 and U.S. Pat. No. 5,621,922,
entitled "Sports Helmet Capable of Sensing Linear and Rotational
Forces," issued on Apr. 22, 1997 are examples of some of those
attempts. Both patents relate to impact sensors for linear and
rotational forces in a football helmet. These devices test the
impact to the skull of a player. If an athlete suffers a
concussion, for example, it will be possible to determine if the
relative magnitude of an impact is dangerously high relative to a
threshold to which each sensing device is adjusted, taking into
consideration the size and weight of the player.
[0007] Another attempt performs testing impact acceleration to the
head with an intraoral device which provides acceleration
information of the brain in various sports. Other attempts have
been made, however all these attempts can be costly to implement
and fail to provide full historical medical information to coaches,
trainers and medical professionals in real-time for dozens of
players at a time on one or more adjacent fields.
SUMMARY OF THE INVENTION
[0008] The present invention relates to a protective headgear such
as a helmet or hard hat which is coupled with additional components
to detect whether the headgear is being worn by the user. In some
versions of the invention, additional features determine the nature
of a head impact. Yet other features may allow the headgear to
serve as a security device, allowing entry into a facility only if
the headgear is in position and if it is properly associated with
an authorized individual who is wearing the headgear.
[0009] In one example, the headgear includes a wirelessly linked
impact sensing and reporting system. The system may include one or
more personnel electronics modules, a sideline or management
module, and a remotely served and remotely accessible recording
database module. In a preferred version of the invention, the
player module is housed within or on a helmet or other form of
protective head gear, the sideline (or management) module is housed
within the structure of an otherwise standard clipboard, and the
database module is accessible via a network, e.g., public or
private Internet.
[0010] In the context of a helmet for an athlete, the player module
may include a plurality of sensors capable of detecting impact
events in multiple axes, a battery, a data memory storage device, a
microprocessor and an LED status indicator array. Each player
module includes an RF transducer module and an antenna system,
capable of establishing a wireless mesh network for reporting the
data associated with an impact to the player. A zinc-air primary
cell battery is used with the present player module device, but may
be substituted by use of a lithium-polymer rechargeable battery or
similar.
[0011] In another version of the invention, the sideline module
includes a radio system capable of acting as a node on the wireless
network and receiving signals from any of the player modules
participating on the wireless mesh network in real-time. The
sideline module also includes a battery, a data memory storage
device, a microprocessor and a display capable of indicating impact
information per player on the wireless mesh network, severity of
impact, and recommended action in near real-time. The sideline
module also includes a loudspeaker capable of generating audible
alert tones to attract a coach's attention to incoming information
in real-time. A zinc-air primary cell battery is used with the
present player module device, but may be substituted by use of a
lithium-polymer rechargeable battery or similar.
[0012] In still another version of the invention, the database
module includes a database of players and associated impact data
arrangeable by name, team, date, severity of impact, frequency of
impact, and many other parameters. The database module is so
constructed to be accessible via the public or private data network
and is configured to provide various degrees of access to its
information contents. Access accounts may be configured according
to individual, team, division, league, physician, and administrator
levels. Each account will be granted access to the appropriate set
of data only, and password protection will ensure dissemination of
data only to authorized parties.
[0013] In a preferred version of the invention, an example system
includes head gear having a proximity sensor, an accelerometer (or
other form if impact sensor), a gyroscope, a processor in signal
communication with the accelerometer and gyroscope, a memory in
data communication with the processor, a transmitter in signal
communication with the processor, and a battery that provides power
to the processor, the memory, the accelerometer, and the gyroscope.
The proximity sensor detects that the helmet or other form of head
gear is in place on the head of the player. In some versions the
processor causes the impact sensor to be disabled such as by
preventing battery power to the sensor when the proximity sensor
determines that the helmet is not in place. In other
implementations, the impact sensor still operates fully but the
player module obtains data for both the proximity sensor and the
impact sensor together so that impact sensor data can be matched
with proximity sensor data to determine whether the impact data is
from an event when the helmet is in place on the head of the
player. The data may be evaluated in the player module or otherwise
locally on a player-worn module, or may be transmitted to the
sideline for evaluation. The processor is also configured to
instruct the transmitter to transmit a signal if an acceleration or
other impact sensor event above a threshold is sensed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] Preferred and alternative embodiments of the present
invention are described in detail below with reference to the
following drawings:
[0015] FIG. 1 is a side view of a hard hat with internal
sensors.
[0016] FIG. 2 is an exemplary view of a system including a hard hat
with keypad and a badge in communication with a computer monitoring
system.
[0017] FIG. 3 is a block diagram of the system of FIG. 2.
[0018] FIG. 4 is a side view of an exemplary sports helmet,
illustrated as a football helmet worn by a player.
[0019] FIG. 5 is a side view of the helmet of FIG. 4, shown with
internal sensors.
[0020] FIG. 6 is a block diagram of an example base unit in
communication with remote devices and having an event evaluation
system.
[0021] FIG. 7 is an example block diagram of example components of
an event evaluation system;
[0022] FIG. 8 is an example screen display illustrating aspects of
an event evaluation system.
[0023] FIG. 9 is an example block diagram of an example computing
device for practicing embodiments of an event evaluation
system.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0024] Several preferred versions of the present invention are
described below, illustrating components and systems for
determining whether headgear is properly in position and further
for the detection, measurement, characterization, transmission, and
reporting of events causing impact forces to be experienced by
individuals, for example workers and athletes. As shown in FIGS. 1
and 2, one preferred version is used in the context of a hard hat
11 for construction or other hazardous situations calling for head
protection. As shown in FIGS. 4 and 5, another preferred example is
configured for use with a helmet or similar protective head gear
10. The descriptions below are generally applicable to either
context, as well as other situations in which headgear is worn and
it is desirable to detect whether the headgear is in place or to
collect information about the wearing of the headgear or
acceleration events experienced by the user of the headgear.
[0025] With reference to the example of FIG. 1, the hard hat 11 may
take any form but is typically configured to have a relatively
rigid outer shell formed from plastic or other materials, generally
being somewhat hemispherical in shape. The hard hat may optionally
have a brim, and typically includes an internal impact-absorbing
suspension system (partially indicated by reference number 18) that
also suspends the shell of the hard hat a short distance above the
wearer's head. The suspension system typically includes an internal
headband 18, which is adjustable and configurable to snugly
encircle the wearer's head. With reference to FIG. 4, the athletic
head gear is illustrated in the form of a football helmet having
features such as a face mask 12 and a chin strap 14. A typical
helmet may further include padding arranged on an inner surface of
the helmet shell.
[0026] In each case, the headgear (10 or 11) is configured with one
or more impact sensors 20, 22, 24 as discussed further below. The
preferred headgear also includes one or more proximity sensors 30,
32, 34. As illustrated in FIGS. 1 and 4, three such proximity
sensors are shown, with the proximity sensors illustrated as being
secured within the helmet shell in substantially the same manner as
for the impact sensors 20, 22, 24, encapsulated within a padding
element 40, as described below.
[0027] The illustration of FIGS. 1 and 4 are intended to indicate
possible locations for the proximity sensors at locations within
the helmet shell. Though three are shown, in the simplest version
only a single proximity sensor is provided. Alternatively, in even
more sophisticated versions more than three proximity sensors may
be employed.
[0028] The locations for the proximity sensors may vary as well.
Functionally, the purpose of the proximity sensor is to determine
whether the headgear is in position and worn by the user. Thus, the
proximity sensors may be placed in any location that would allow
the sensors to determine that the wearer's head is situated within
the headgear. Though illustrated as being within the shell, in
other versions proximity sensors may be mounted on the face mask,
chin strap, webbing, suspension, or other locations suitable for
detecting whether the headgear is in position. Most preferably,
however, one or more proximity sensors is positioned within the
main portion of the headgear shell, trained to detect whether the
head of the wearer is in place closely adjacent the proximity
sensor.
[0029] The proximity sensor may take any form so long as it is able
to determine whether the head of the user is within the helmet. As
one preferred example, the proximity sensor is a capacitive sensor.
Capacitive sensors are commonly employed in touch screen computer
displays and generally operate to detect the presence of anything
that is conductive or which has dielectric properties. Capacitive
sensors can be employed with a hard surface material such as is
used with touch-screen displays, though the use of such a material
may be less ideal when incorporated into headgear. More preferably,
the capacitive sensor is incorporated into a flexible material
which is then used as a covering for the padding within the
headgear such that the capacitive sensor will be in contact with
the player's head when the headgear is worn by the user. Similarly,
the capacitive sensor may be incorporated into the suspension
system 18 at a location expected to contact the wearer's head when
the headgear is worn. Ideally, at least one such sensor is
positioned toward the front of the hard hat such that it would
contact the wearer's head in the vicinity of the forehead.
[0030] Most preferably, several capacitive sensors are used. Where
multiple sensors are provided, the system polls each of the
proximity sensors to determine whether all or a majority of the
proximity sensors detect the presence of a capacitive object such
as the wearer's head. If so, then the system determines that any
impact events detected by the impact event sensors 20, 22, 24 are
related actual events experienced by the head of the wearer as
opposed to spurious events experienced by the helmet alone when
carried by the player.
[0031] Importantly, when it is not worn headgear may be dropped or
banged against a bench, desk, another person, or some other
surface. The detected impact parameters for the headgear when not
worn can be quite severe, and may commonly be associated with a
significant impact event if the same acceleration or other
parameters were detected when the headgear was actually in position
on the person's head. Accordingly, by associating the impact event
data from the impact sensors with the proximity sensor data, the
data produced when the headgear is not in position on the person's
head can be ignored or otherwise filtered out from the useful data
produced when the helmet is in position.
[0032] In another version of the invention, the proximity sensors
are in the form of photo-interrupt sensors. A photo-interrupt
sensor may include an infrared emitter and a receiver for detecting
light from the emitter. In one version, a first side of the
headgear (for example, a left side) may include an infrared emitter
while a second side of the helmet (for example, the right side) may
include an infrared receiver. If the headgear is not worn by the
person, the receiver will detect light from the emitter, thereby
confirming that it is not in position. Once the person puts the
headgear in position, the light beam is interrupted, thereby
indicating that the headgear is in position.
[0033] Yet other types of proximity sensors may be employed to
detect whether the person's head is in position within the head
gear. For example, alternative sensors may take the form of
temperature sensors configured to detect the temperature within the
headgear, taking into consideration an expected temperature range
when the headgear is in place atop a head. Yet other sensors may
monitor electrical conductivity, resistance, impedance, reactance,
or other parameters which may vary between conditions when the
headgear is worn or not worn by a user. The sensors may also detect
pressure, indicative of a downward weight of the headgear on the
head, or of a snugly fitting headband secured about the head. Any
of these or still other sensors may be used as proximity
sensors.
[0034] In some versions of the invention, multiple proximity sensor
types are used within a single helmet. Thus, for example, a single
headgear may include one or more capacitive sensors together with
one or more photo-interrupt pairs of sensors. One type or the other
may be considered to be the primary or the backup form of sensor.
Alternatively, the system may poll multiple sensors to determine
that the headgear is in position only if multiple sensors detect
that it is in position.
[0035] As described above, the proximity sensor data may be used to
prevent the operation of the impact sensors if the helmet is not in
position. Alternatively, it may allow the sensors to operate but
the sensor module collects and pairs the data from the proximity
sensors and the impact sensors to allow the system to determine
which impact events are real and which are spurious. That
evaluation may occur locally at the sensor module (either mounted
on the headgear or in another person-mounted location) or may take
place remotely such as on the sidelines as described above.
[0036] Either with the proximity sensors, or alternatively in the
absence of the use of proximity sensors, the system may evaluate
the impact sensor data to determine whether the headgear was in
position at the time of the impact event. An evaluation of impact
data collected from user impact sensor devices confirms that there
is a boundary of impact parameter values that are likely to be
associated with an impact event experienced by headgear that is
worn by a person, and that impact events for empty headgear can be
quite different. It is therefore possible to compare impact
parameters from the sensors against a database of historically
valid impact parameters to determine whether the impact event could
have been experienced with the helmet in position on the player's
head.
[0037] In this alternative version, the base unit 104 preferably
includes a database stored in the memory 116, in which the database
contains characteristics for valid impact events, with "valid"
impact events meaning those that are possible to have occurred with
a helmet in position, preferably based on an aggregation of
historical data but optionally based on otherwise established
boundaries. In one preferred version, the database includes values
defining a peak acceleration, a duration of acceleration above a
threshold, and a rate of decay of acceleration. Sensed parameters
are compared against the peak, duration, and decay values and when
the sensed parameters are below or otherwise inconsistent with
stored values considered to be valid, the base unit (such as within
the event evaluation system 132) concludes that the impact event
occurred when the helmet was not in position. In some versions of
the invention, the impact evaluation system for determining the
validity of the impact event is also paired with the use of
proximity sensors as an additional method for determining whether a
particular sensed event occurred with a helmet in position, worn by
the user.
[0038] As best seen in FIG. 5, the padding may take the form of a
plurality of individual padding elements 40 formed in (for example)
a rectangular cubic shape. The padding may alternatively be a
single integral component or have any other shape configured to
provide cushioning between the helmet shell and the player's
head.
[0039] The system conveys to an authority figure, preferably a
manager, coach or trainer, useful information about the identity of
the impacted person, the severity of the impact, and suggested
actions for evaluating the condition of the person and for making
decisions about the players subsequent status to return to work, to
continue to play, or to be referred to a physician's care.
[0040] In some versions, particularly as used in the hard hat
context, the system may also be used as a security device and to
gather and store information ensuring compliance with hard hat wear
requirements. As shown in FIG. 2, the hard hat may include a keypad
50 enabling the user to enter a security code associated with a
particular user. Alternatively, the headgear may incorporate a
fingerprint reader or other biometric or user input device to
enable the system to confirm a particular authorized user is in
control of the headgear.
[0041] The headgear may also include a transmitter 52, such as an
RFID transmitter (or tag) that is read by a monitoring receiver 70.
The receiver 70 may correspond to the base unit 104 as described
below, or may be a simplified receiver corresponding to a unit for
more particularly monitoring security. The receiver 70 may also be
substantially in the form of an RFID tag reader for receiving data
transmitted from the tag. The headgear may include internal
components in accordance with the block diagram of FIG. 3. Thus,
the keypad may be in communication with an internal processor 58
and memory 56 containing programming instructions to interpret the
keypad entries and process them accordingly. A power supply 54 such
as a battery provides power for the operation of the system. A
transmitter is optionally coupled to the processor to send
appropriate signals to the receiver 70 or base station 104.
[0042] In an exemplary operation, the wearer enters a code or
personal identification number (PIN) into the keypad. If the code
or PIN is accepted, the processor enables the transmission of
signals to the receiver 70 or base station 104 indicating that the
headgear is enabled by an authorized user. Most preferably, the PIN
number uniquely associates a single headgear to a single wearer.
Once authorized, the processor further determines whether the
proximity sensors 30 detect the presence of a wearer's head in
sufficient proximity with the headgear. If so, programming
instructions within the memory 56 cause the transmitter 52 to send
an appropriate signal indicating that the headgear is in place atop
the head of the authorized user. As discussed further below, the
system thereafter will continue to monitor the impact sensors for
impact events, and likewise will continually monitor the proximity
sensors to determine whether the headgear is in place.
[0043] In some versions, the security system may evaluate the
presence of a badge 60 or similar key card associated with an
individual. Some versions of this type may employ an RFID
transmitter for the transmitter 52, with another RFID transmitter
on the badge 60 (or, alternatively, a magnetic, optical, or other
means of reading the badge). An example of this type may omit the
keypad as a means of associating the headgear with a particular
user, instead relying on a reading by the system receiver 70 that
the badge 60 and headgear 11 (via the RFID transmitter 52) are in
close proximity with one another at the worksite entry point.
[0044] The system as described above may serve to both confirm that
the headgear is associated with an authorized user, but also to
ensure that it is in place atop the wearer's head in order to allow
entry. Thus, the system 70 may receive a signal from the
transmitter 52 and, optionally, the badge 60 to confirm the
presence of an authorized person. The system then further allows
entry to the facility (by sending an appropriate code to unlock a
gate or an approval code to a display screen monitored by a
security gate personnel) only if it also receives a signal from the
transmitter 52 indicating that the headgear is in position as
determined by the proximity sensors. Accordingly, the system
ensures that the headgear is in position and that it is used by an
authorized individual in order to gain entry to a secure or
hazardous area.
[0045] In addition to the proximity sensors, the headgear may
further contain impact sensors to monitor for head impact events.
In such a version the headgear includes an arrangement of a
plurality of low-cost, distributed impact sensors 20, 22, 24
arranged between the inside surface of the player shell and the
bottom surface of a padding elements 40 that provide fit and
cushioning to the wearer's head. These sensors may alternatively be
positioned in other locations, either inside or outside the
headgear. For example, they may be located intermediately within
the padding element, either at the interface of two laminated
elements, or by encapsulation directly within the mass of the
padding element. The sensors may also be situated within cavities
of the headgear or in the spaces between padding or suspension
elements. As illustrated in FIG. 5, the impact sensors 20, 22, 24
are indicated as being encapsulated within padding elements.
[0046] Any of a variety or electronic devices may be used to
monitor the headgear for impact or acceleration events. For
example, the sensors may be MEMS type impact sensors, MEMS
accelerometers, miniature weighted cantilevers fitted with
miniature strain-gauge elements, piezoelectric membranes, or
Force-Sensitive-Resistors (FSR). The sensors may also include one
or more gyroscopes positioned to detect acceleration along one or
more axes.
[0047] In one version, the memory 56 stores data associated with
the variety of impact/acceleration sensors, including the proximity
sensors. The data storage tracks wear of the headgear over time,
preferably associating wear to actual clock time in order to
maintain a record of actual times of day during which the helmet
was worn and not worn. In the event of a subsequent head injury,
the headgear wear data is useful to determine whether the headgear
was in position on the person's head at the time of the head injury
event.
[0048] The sensors employed in the headgear are connected
electronically by means of wires or printed flex circuitry to an
electronics pod or other similar means, in some versions situated
within a primary shell of the headgear, and within the space
available between two or more padding elements. In some versions
the sensors are communicatively coupled to a receiving unit
contained within a chin strap or other such component that may be
internal to or external to the helmet shell. The electronics module
(or, for sports helmets, the player module) preferably includes
electronic components to transmit the data received from the
sensors and then pass it along to a remote or sideline receiving
unit. Most preferably the data is passed along in real time,
although in some versions the data is stored in a memory and
downloaded at a later time.
[0049] In one exemplary version in which headgear data is
downloaded at a later time, the data from the proximity sensors and
impact or acceleration sensors is collected and stored in the
headgear memory for later download or transmission. In one version,
the headgear further includes a port allowing for wired
connectivity (e.g., mini USB or other computer-readable
configurations) to facilitate transmission of stored data to a
computing device. In other versions, the headgear data is
transmitted wirelessly when the headgear is in the vicinity of a
checkpoint such as a security post. While any of a variety of
transmission means are possible as described above, most preferably
the headgear uses a low power protocol such as that used by RFID
tags and readers. When the headgear is detected in the vicinity of
the security post (such as receiver 70), the headgear data is
downloaded by the receiver. The receiver 70 is preferably a
computing device having network connectivity (such as the Internet)
so that the data from one or more receivers can be further
transmitted and aggregated at a remote location.
[0050] An electronics pod (whether in the helmet, the chin strap,
or another location) collects, processes, evaluates, and if
appropriate, transmits data pertaining to an impact event via radio
to one or more other participant nodes of the wireless network to
which the player module belongs. This monitoring and tracking
example is described below with reference to FIGS. 6-9 in the
context of a football helmet monitoring system, but may also be
applied to the context of other situations involving headgear, for
example that of a hard hat in a construction or other hazardous
area as noted above. Thus, it should be understood that concepts
below referring to players, helmets, chinstraps, and the like can
be readily applied to employees, hard hats, and other such
components in other versions of the invention. Likewise, the
sideline module described below may alternatively be a management
or security module used by a company to monitor its personnel,
rather than by a coach to monitor its players.
[0051] The electronics pod contains electronic circuitry having
components such as a microprocessor, flash memory, radio module,
antenna, and status display LEDs. In the circuit's memory resides a
database lookup table for evaluation of sensor data and comparison
to combinations of impact levels that represent suspicious
likelihood of Mild Traumatic Brain Injury (MTBI) or concussion. The
electronics pod is also configured to monitor, evaluate, and/or
display system status information such as link to network, battery
charge status, and proper system functioning.
[0052] An example sideline module is an electronic data gathering
and display device incorporated into a portable enclosure that is
easy for a coach, trainer, or other such game official to carry,
consult, and interact with during the activities of the practice or
game. The sideline module may be in the form of any electronic
receiving device, including laptop or tablet computers, mobile
phones, or any other such device configurable to receive wireless
information. Moreover, the sideline module is described as
receiving information directly from the sensor unit, although in
some versions of the invention the sensor module may pass its data
to an intermediate server or other device which then forwards the
information to the sideline module.
[0053] The sideline module includes electronic components arranged
into a circuit that allows for participation in the wireless mesh
network established by a set of player modules, and specifically
for the receipt of data transmissions from the player modules, and
subsequently the display of impact event information on a visual
display in real-time. The sideline module also produces audible and
vibratory alert signals to call attention to the arrival of new
data messages in real-time, which are disabled by manual conscious
intervention of the coach or trainer, indicating acknowledgement of
receipt of impact event data.
[0054] In one embodiment, the sideline module performs the
classification of incoming impact data into categories, indicating
differing levels of concern and differing levels of urgency of
response. The system may employ a color-coded system to indicate
the severity of the event, for example in which green indicates the
absence of significant impact events for a given player, yellow
indicates the need for immediate sideline evaluation of the player,
and red indicates a severe enough impact that the player be removed
from play and referred to a physician immediately.
[0055] Upon registering a yellow impact event, and upon subsequent
acknowledgement of receipt of the message by the coach or trainer,
the sideline module, in one embodiment, leads the coach or trainer
through a simple protocol for evaluation of the player's condition.
Through answering a series of simple Yes or No questions, the
sideline module guides the coach or trainer to a limited number of
possible suggested actions. These potential outcomes could include
immediate referral to a physician for further examination, or a
period of bench time observation followed by a secondary guided
evaluation before allowing the player to return to play.
[0056] In one embodiment, a durable record of data transactions is
received in real-time and is kept independently of the sideline
module or modules. Such a database provides players, parents,
coaches, trainers, administrators and other stakeholders access to
a record of what impact event information was conveyed, when, to
whom and about which player. The sideline module is equipped with a
wide area network radio module for transmission of a record of all
data transactions on the system with time stamp and a record of the
actions by coaches and content of player evaluations. A standard 1
way or 2 way pager system is used, which has the benefit of being
inexpensive and nearly ubiquitous in availability throughout much
of the world. Alternatives to pager radio systems are cellular
radios of various kinds and other wide area network wireless
connections. The knowledge that this information will be available
to stakeholders provides accountability to all stakeholders in the
health and well being of the player.
[0057] In one embodiment, the database is populated by an automatic
interface to the wide area radio network accessed by the sideline
network, and is accessible to stakeholders by means of internet
based applications, equipped with password protected hierarchical
account structures. The system provides parents the ability to log
on to their account and review the totality of impact event data
and the record of coach responses associated with their player.
[0058] Each player module at the start of each season maps its
unique identifier code to a particular player's name and number. It
is possible that during the course of events players might
accidentally wear the wrong player number and potentially cause
confusion by users of the system. It is for this reason that each
player module has, in one embodiment, a visual indicator array of
LEDs, which will repeatedly flash a visible signal in case of
transmission of an impact event of concern. A yellow light flashes
to indicate the transmission of a yellow event, and a red light
flashes to indicate the transmission of a red event. When the
player is called to the sidelines for evaluation, the coach or
trainer can disable the flashing indicator light by simultaneously
depressing a button on the player module and a button on the
sideline module. This provides positive confirmation that the
player who sustained the reported impact is in fact the player
being evaluated by the coach or trainer.
[0059] FIG. 6 illustrates an exemplary system 100 that performs
aggregation of sensor information such as head-acceleration
information or head-rotational information received from a
plurality of sensors 102 and makes the sensor information available
to relevant parties. The system 100 includes a base unit 104 that
is in wireless communication with one or more sensor units 102 and
is in wired or wireless communication with one or more devices 106.
In one embodiment, the sensor units 102 can be connected to the
base unit 104 via a download and charging station wired or
wirelessly connected with the base unit 104 (not shown). The base
unit 104 includes a processor 112, local memory 116, and a
communication component 120. The base unit 104 receives sensor
information wirelessly from each of the sensor units 102 and makes
that data available to the one or more devices 106.
[0060] In one embodiment, the base unit 104 or any of the devices
106 are in wired or wireless connection with a medical system 124
over a public or private data network 108. The medical system 124
receives sensor data, identification or other information from the
base unit 104 or the devices 106 for analysis with regard to stored
athlete information and/or storage into the database 126.
[0061] In one embodiment, the sensor units 102 include one or more
accelerometers or gyros embedded into a device secured to head gear
such as the helmet 10. When a sensor unit 102 has determined that
an acceleration or rotational event has exceeded a set threshold,
the sensor unit 102 transmits identification information of the
individual sensor unit and recorded acceleration information
associated with the acceleration event that exceeded the
threshold.
[0062] In one embodiment, the communication component 120 of the
base unit 104 receives the sensor information from the sensor unit
102 and delivers it to the processor 112. The processor 112
performs a number of optional operations, such as storing the
received sensor information into the memory 116, activating an
example event evaluation system 132 to analyze the sensor
information stored in the memory 116, and/or sends processed or
unprocessed sensor information to one or more of the devices 106 or
the medical system 124 via the network 108. In one embodiment, the
base unit 104 may simply be a wireless router device that would
only include maybe just a communication component and a simple
router processor.
[0063] The devices 106 may be one of a dummy display that includes
a communication component for communicating with the base unit 104
or may be a smart computing device that includes a processor, a
display and a user interface, such as a computing tablet device, a
personal data assistant (PDA), a watch or any comparable device.
The device 106 may also include local memory. The event evaluation
system 132 may optionally be located in the local memory of the
device 106. The device 106 would process, using event evaluation
system 132, the sensor information received from the sensor units
102 via the base unit 104. Typical users of the devices 106 might
be a team coach, trainer or local medical professional.
[0064] An example event evaluation system 132 includes an event
determination system 128 that receives sensor information and
creates a model of the event. To create a model, an example event
determination system 128 translates linear and/or rotational forces
from the location of a sensor unit 102 to a center of mass of an
athlete's head. The model optionally displays the linear and/or
rotational forces on the athletes head. The example event
evaluation system 132 also optionally includes an injury prediction
engine 130. The injury prediction engine 130 is optionally predicts
an injury to the athlete by comparing the received sensor
information to sensor information stored within the medical system
124. When the injury prediction engine 130 discovers similar sensor
information in the medical system 124, then the injury prediction
engine 130 uses the medical diagnosis of the similar sensor
information in the medical system 124 to predict an injury to the
athlete. The event evaluation system 132 includes a user interface
114 to display event and injury prediction information.
[0065] Example embodiments described herein provide applications,
tools, data structures and other support to implement an event
evaluation system 132 to be used for near real time collection of
data. Other embodiments of the described techniques may be used for
other purposes. In the following description, numerous specific
details are set forth, such as data formats and code sequences,
etc., in order to provide a thorough understanding of the described
techniques. The embodiments described also can be practiced without
some of the specific details described herein, or with other
specific details, such as changes with respect to the ordering of
the code flow, different code flows, etc. Thus, the scope of the
techniques and/or functions described are not limited by the
particular order, selection, or decomposition of steps described
with reference to any particular routine.
[0066] FIG. 7 is an example block diagram of example components of
an event evaluation system. In one embodiment, the event evaluation
system 132 includes one or more functional components/modules that
work together to process received sensor information. These
components may be implemented in software or hardware or both. The
event evaluation system 132, includes an event determination system
128 and an injury prediction engine 130 as mentioned with respect
to FIG. 6.
[0067] The event determination system 128 includes an event
analysis engine 206, an event modeling engine 208, a threshold
determination engine 210 and an alert system 212. The event
analysis engine 206 is configured to receive sensor information
from sensor devices 102 in the form of an indication of an impact
parameter such as acceleration and/or rotational information from
an event to be analyzed and an indication of the player that
experienced the event. The event analysis engine 206 is configured
to determine magnitudes and/or vectors of impacts experienced by
the player. A magnitude may be determined based on a reading from a
sensor or the magnitude may be recreated by measuring, for example,
the length of time an acceleration or other measured parameter was
above a threshold value and/or mathematically estimating the
magnitude of the impact. In one embodiment the parameter is
analyzed by matching a graphical representation of the parameter to
a known pattern. In yet another embodiment, a graphical
representation of the parameter is analyzed for its peak value, it
area under the curve and/or its rate of change. The event analysis
engine 206 preferably provides processed sensor information in the
form and magnitude and/or vector information to the event modeling
engine 208 and the threshold determination engine 210.
[0068] The event modeling engine 208 is optionally configured to
receive processed sensor information and to create a model of the
sensor information on a human form. For example, the event modeling
engine 208 creates a vector of impact and a rotational arc on a
model skull to display the effect of an event on a players head.
The event modeling engine 208 determines the location, with
reference to the body, of the sensor unit that transmitted the
sensor information. The event modeling engine 208 optionally
determines the location of the sensor units 102, with reference to
the body, by accessing configuration information stored in the
memory 116 of the base station 104 described in FIG. 3, receives
sensor location with the sensor information, and/or receives an
indication of a sensor location through a user interface such as
the user interface 114 described with respect to FIG. 3. The event
modeling engine 208 uses the sensor location information and
general characteristics of a human head to model the forces that
the head experienced. In one embodiment, the actual dimensions of a
player's human head are known. The event modeling engine 208 also
adjusts the sensor information using one or more algorithms based
on the location of the sensor on the player. The event modeling
engine 208 transmits the event data to a medical history system 126
to be used in future events and to a mobile device 214 for
display.
[0069] The threshold determination engine 210 is configured to
compare the received processed sensor information to a threshold
value and optionally activate an alert system 212. The threshold
determination engine 210 uses a magnitude, an area under a
graphical representation of the sensor information, a rate of
change and/or a number of total impacts to activate the alarm
system 212. The threshold used by the threshold determination
engine may be a default setting, a user setting, and/or a setting
that is dynamically set in conjunction the injury prediction engine
209 and the medical history system 126. The alert system 212 is
configured to send an alert to a mobile device 214, or optionally
sound an audible alarm or active a visual indicator such as the LED
described above.
[0070] The injury prediction engine 130 includes an event
comparison engine 222 and an injury risk predictor 224. The event
comparison engine 222 is configured to receive processed sensor
data from the event determination system 128. In one embodiment,
the event comparison engine 222 receives normalized data from the
recreation system 204. The normalized data is preferably in the
form of a magnitude and/or vector of an impact. In an embodiment,
the event comparison engine 222 also receives rotational data. The
event comparison engine 222 is in data communication with a medical
history system 126 which stores historical medical and impact data.
The event comparison engine 222 compares the normalized data
received from the event determination system 128 to previous
impacts stored in the medical history system 126. The event
comparison engine 222 attempts to match sensor data, player
characteristics such as size and weight, number of impacts for a
player, and/or prior medical history of the player to previous
events in the medical history system 126. One such comparison
includes the using the event comparison engine 222 to determine one
or more similar impacts, and then to gather their corresponding
medical outcome. For example once an impact is determined to be
similar, the event comparison engine 222 will determine what
medical result happened to a player as a result of the impact.
[0071] The injury risk predictor 224 is configured to receive the
sensor data and the related impacts, with corresponding medical
results from the event comparison engine 222. The injury risk
predictor 224, using all of the received data attempts to predict
an injury based on the impact to the player caused by the received
sensor data. While not a medical evaluation, this prediction can be
used by a coach, trainer, parent, caregiver or doctor to determine
a potential injury and then potentially monitor the player, or run
medical testing before another impact potentially makes the problem
worse. One such prediction algorithm includes the following formula
when attempting to predict an injury. The injury risk predictor 224
uses the received most closely related impact data from the event
comparison engine 222 and its corresponding medical result, and
then sends the medical result to a mobile device 214 as a
prediction as to what may be the medical result of the received
sensor data. In alternate embodiments the injury prediction engine
130 may be a neural network.
[0072] A user interface 250 is configured to provide a user with
information related to the event/impact and to provide information
related to injury risk prediction. The user interface 250 is
further configured to provide configuration information for the
event evaluation system 132, verify that a sensor 202 is connected,
and provides assessment tools for trainers, coaches, parents and
caregivers in case of an injury. The user interface 250 is further
described in FIGS. 10 and 12.
[0073] FIG. 8 is an example screen display illustrating aspects of
an event evaluation system. FIG. 8 depicts a user interface 300
that is an interface for interacting with an event evaluation
system, such as the event evaluation system 132 of FIG. 7. The
interface 300 includes a graphical representation of sensor data,
such as acceleration data shown in a screen area 304. Screen area
304 is located in the bottom left corner of the screen, however in
alternate embodiments may be located elsewhere on the screen or
shown in response to selection of a button (not shown) by a
user.
[0074] The interface 300 includes an indication of a player, and
optionally contains his/her number and if the system is connected
in a screen area 302. The system connected indication includes an
indication of connection of the player's sensor device to the
system and an indication of whether the helmet is in position on
the head of the player. Screen area 302 optionally may be used to
indicate to a coach, trainer or a parent that a player's data is
not being received by the system. Screen area 302 is located above
screen area 304 and shares a top half of the user interface 300
with screen area 306.
[0075] A magnitude of the most recent sensor information is shown
in a screen area 306. The magnitude is optionally shown in the form
of a dial, but also may include numbers, or other indicating
methods. In the preferred version, the presentation is in the form
of a partial dial, using colors such as red/yellow/green to
indicate when experienced acceleration (or other impact parameter)
is within an acceptable range or has heightened to a level
indicative of risk of injury. The indication of screen area 306 is
configured to quickly display to a coach, trainer, or health care
provider the magnitude of the most recent impact.
[0076] A model of the most recent sensor information on a human
form is shown in a model area 308. The model area 308 is located in
the bottom right corner of the user interface 300. The model
includes a rotatable human skull that contains an indication in the
form of an area of a vector of impact and an arrow indicating a
rotational path of the head. The interface 300 is used to show
information to a coach, trainer, caregiver, or health care provider
relating to the most recent event. The interface 300 may be used as
a tool to determine whether a player has suffered an injury.
[0077] FIG. 9 is an example block diagram of an example computing
system 400 for practicing embodiments of an event evaluation
system, such as the event evaluation system 132 shown in FIG. 3. In
particular, FIG. 9 shows a computing system 400 that may be
utilized to implement an event evaluation system 410. Note that one
or more general purpose or special purpose computing
systems/devices may be used to implement the event evaluation
system 410. In addition, the computing system 400 may comprise one
or more distinct computing systems/devices and may span distributed
locations. Furthermore, each block shown may represent one or more
such blocks as appropriate to a specific embodiment or may be
combined with other blocks. Also, the event evaluation system 410
may be implemented in software, hardware, firmware, or in some
combination to achieve the capabilities described herein.
[0078] In the embodiment shown, the computing system 400 comprises
a computer memory ("memory") 401, a display 402, one or more
Central Processing Units ("CPU") 403, Input/Output devices 404
(e.g., keyboard, mouse, CRT or LCD display, and the like), other
computer-readable media 405, and network connections 406. The event
evaluation system 410 is shown residing in memory 401. In other
embodiments, some portion of the contents, some or all of the
components of the event evaluation system 410 may be stored on
and/or transmitted over the other computer-readable media 405. The
components of the event evaluation system 410 preferably execute on
one or more CPUs 403 and extract and provide quotations, as
described herein. Other code or programs 430 (e.g., an
administrative interface, a Web server, and the like) and
potentially other data repositories, such as data repository 420,
also reside in the memory 401, and preferably execute on one or
more CPUs 403. Of note, one or more of the components in FIG. 11
may not be present in any specific implementation. For example,
some embodiments may not provide other computer readable media 405
or a display 402.
[0079] In a typical embodiment, as described above, the event
evaluation system 410 includes an event determination system 412,
an injury prediction engine 415, a configuration manager 413, and a
UI Manager 416. The event determination system 412 performs
functions such as those described with reference to the event
determination system 128 of FIG. 4. For example, the event
determination system 411 receives sensor information and/or sensor
data from sensor units 460 and transforms the sensor information
into a model that displays a recreation of an impact on a human
head. The injury prediction engine 415 performs functions such as
those described with reference to the injury prediction engine 22
of FIG. 7. For example, the injury prediction engine 415 receives
sensor information and/or sensor data and uses the sensor
information to predict an injury on a human head. The configuration
manager 413 provides configuration information to sensor devices
460 and mobile devices 465. The UI Manager 416 performs steps to
create the user interface.
[0080] The event evaluation system 410 interacts via the network
450 with (1) a medical history system 455, (2) mobile devices 465
and/or (3) sensor units 460. The network 40 may be any combination
of media (e.g., twisted pair, coaxial, fiber optic, radio
frequency), hardware (e.g., routers, switches, repeaters,
transceivers), and protocols (e.g., TCP/IP, UDP, Ethernet, Wi-Fi,
WiMAX) that facilitate communication between remotely situated
humans and/or devices. The mobile devices 465 include desktop
computing systems, notebook computers, mobile phones, smart phones,
personal digital assistants, and the like.
[0081] In an example embodiment, components/modules of the event
evaluation system 410 are implemented using standard programming
techniques. For example, the event evaluation system 410 may be
implemented as a "native" executable running on the CPU 403, along
with one or more static or dynamic libraries. In other embodiments,
the Event evaluation system 410 may be implemented as instructions
processed by a virtual machine that executes as one of the other
programs 403. In general, a range of programming languages known in
the art may be employed for implementing such example embodiments,
including representative implementations of various programming
language paradigms, including but not limited to, object-oriented
(e.g., Java, C++, C#, Visual Basic.NET, Smalltalk, and the like),
functional (e.g., ML, Lisp, Scheme, and the like), procedural
(e.g., C, Pascal, Ada, Modula, and the like), scripting (e.g.,
Perl, Ruby, Python, JavaScript, VBScript, and the like), and
declarative (e.g., SQL, Prolog, and the like).
[0082] The embodiments described above may also use either
synchronous or asynchronous client-server computing techniques.
Also, the various components may be implemented using more
monolithic programming techniques, for example, as an executable
running on a single CPU computer system, or alternatively
decomposed using a variety of structuring techniques, including but
not limited to, multiprogramming, multithreading, client-server, or
peer-to-peer, running on one or more computer systems each having
one or more CPUs. Some embodiments may execute concurrently and
asynchronously, and communicate using message passing techniques.
Equivalent synchronous embodiments are also supported. Also, other
functions could be implemented and/or performed by each
component/module, and in different orders, and by different
components/modules, yet still achieve the described functions.
[0083] In addition, programming interfaces to the data stored as
part of the event evaluation system 410, such as in the API 417,
can be made available by standard mechanisms such as through C,
C++, C#, and Java APIs; libraries for accessing files, databases,
or other data repositories; through languages such as XML; or
through Web servers, FTP servers, or other types of servers
providing access to stored data. The data store 418 may be
implemented as one or more database systems, file systems, or any
other technique for storing such information, or any combination of
the above, including implementations using distributed computing
techniques.
[0084] Different configurations and locations of programs and data
are contemplated for use with techniques described herein. A
variety of distributed computing techniques are appropriate for
implementing the components of the illustrated embodiments in a
distributed manner including but not limited to TCP/IP sockets,
RPC, RMI, HTTP, Web Services (XML-RPC, JAX-RPC, SOAP, and the
like). Other variations are possible. Also, other functionality
could be provided by each component/module, or existing
functionality could be distributed amongst the components/modules
in different ways, yet still achieve the functions described
herein.
[0085] Furthermore, in some embodiments, some or all of the
components of the event evaluation system 410 may be implemented or
provided in other manners, such as at least partially in firmware
and/or hardware, including, but not limited to one or more
application-specific integrated circuits ("ASICs"), standard
integrated circuits, controllers executing appropriate
instructions, and including microcontrollers and/or embedded
controllers, field-programmable gate arrays ("FPGAs"), complex
programmable logic devices ("CPLDs"), and the like. Some or all of
the system components and/or data structures may also be stored as
contents (e.g., as executable or other machine-readable software
instructions or structured data) on a computer-readable medium
(e.g., as a hard disk; a memory; a computer network or cellular
wireless network or other data transmission medium; or a portable
media article to be read by an appropriate drive or via an
appropriate connection, such as a DVD or flash memory device) so as
to enable or configure the computer-readable medium and/or one or
more associated computing systems or devices to execute or
otherwise use or provide the contents to perform at least some of
the described techniques. Some or all of the system components and
data structures may also be stored as data signals (e.g., by being
encoded as part of a carrier wave or included as part of an analog
or digital propagated signal) on a variety of computer-readable
transmission mediums, which are then transmitted, including across
wireless-based and wired/cable-based mediums, and may take a
variety of forms (e.g., as part of a single or multiplexed analog
signal, or as multiple discrete digital packets or frames). Such
computer program products may also take other forms in other
embodiments. Accordingly, embodiments of this disclosure may be
practiced with other computer system configurations.
[0086] Although the techniques of the event evaluation system are
generally applicable to any type of sensor data related to a head
impact, the concepts and techniques described here are applicable
to other types of sensor data to include sensors on other parts of
the body and to sensors on other devices like vehicles.
Essentially, the concepts and techniques described are applicable
to any sensor collection environment. For example in detecting and
processing an explosive charge and modeling its effects on a body
or during a car accident to predict injuries to a body. Also,
although certain terms are used primarily herein, other terms could
be used interchangeably to yield equivalent embodiments and
examples. In addition, terms may have alternate spellings which may
or may not be explicitly mentioned, and all such variations of
terms are intended to be included.
[0087] While the preferred embodiment of the invention has been
illustrated and described, as noted above, many changes can be made
without departing from the spirit and scope of the invention.
Accordingly, the scope of the invention is not limited by the
disclosure of the preferred embodiment. Instead, the invention
should be determined entirely by reference to the claims that
follow.
* * * * *