Patent Application
20170120813
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings that form a part of this document: Copyright Revolution Solutions, LLC 2015, All Rights Reserved.
This disclosure relates to transportation systems, and more particularly to systems and methods to transport passengers.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 62/247,691, filed on Oct. 28, 2015 and U.S. Provisional Patent Application Ser. No. 62/255,683, filed on Nov. 16, 2015 which are both incorporated by reference herein in their entirety.
Each year in the United States, numerous deaths are caused by leaving children in vehicles. Most of these deaths are attributed to hyperthermia from exposure to high temperatures. Many of these deaths are attributed to forgetfulness and distraction.
Example systems and methods to safely transport passengers are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the systems and methods to safely transport passengers may be practiced without these specific details.
The vehicle 102 includes a system monitor control unit (SMCU) 104 that communicates, over a network 106 (radio frequency (RF), blue tooth, etc.), with network elements in the form of system units. The SMCU 104 may communicate with system units that are located inside a network perimeter 108. The SMCU 104 may not communicate with system units that are located outside of the network perimeter 108 as the system units are beyond the communication range of the SMCU 104. The vehicle 102 may move to cause the SMCU 104 to move making the network perimeter 108 mobile. Accordingly, the vehicle 102 and the SMCU 104 may operate synergistically to form a communication hub that is mobile and that reaches to a network perimeter 108 that is mobile. Further, the SMCU 104 supports bidirectional communication with the system units. For example, the system units may receive messages from the SMCU 104 and send messages to the SMCU 104. In addition, the SMCU 104 supports the scaling of system units. For example, the SMCU 104 supports the incremental addition or removal of system units in accordance with the requirements of the particular system 100. The system units (SU) may include standard system units (SSU) and optional system units (OSU) including alerting system units (ASU) where the OSU may be utilized by the SMCU 104 to supplement services that are provided by the SSU.
The standard system units are illustrated to the right of the SMCU 104. The standard system units may include a FOB control unit (FOBCU) 110, a car seat control unit (CSCU) 112, a passenger seat control unit (PSCU) 114 and a booster seat control (BSCU) unit 116. The CSCU 112, the FOBCU 110, the PSCU 114 and the BSCU 116 are scalable. Accordingly, the system 100 may support one or more CSCUs 112, FOBCUs 110, PSCU 114s and/or BSCUs 116. For example, a family with twins may add two CSCUs 112 to the SMCU 104 to safely transport the twins together in the vehicle 102. Each of the control units for seats (e.g., CSCUs 112, PSCUs 114, BSCUs 116) further includes one or more sensors to identify the presence/absence of an occupant and a software module for communicating a status of the sensed occupant, over the network 106, to the SMCU 104. Further, each of the control units for seats includes one or more sensors to identify whether seat belts are fastened/unfastened and further utilizes the respective software modules to communicate the status of the seat belt(s) to the SMCU 104. Further, the SMCU 104 includes a sensor that measures the ambient temperature of the vehicle 102 and the LLCU 118 may include a backup sensor to measure the ambient temperature of the vehicle 102.
The FOBCU 110 is a small security hardware device with a built-in authentication system that is used to control and secure access to network 106 services and data. The FOBCU 110 may include a physical loop-like extension enabling a driver of the vehicle 102 to thread their keys through the loop and attach they keys to the FOBCU 110. Accordingly, the FOBCU 110 and a set of keys may function as a single logical unit. The FOBCU 110, and other system units, are illustrated in
The system 100 may identify and communicate alerts responsive to an identification of an unsafe condition. For example, the SMCU 104 may produce an audible alert responsive receipt of message(s) from a CSCU 112, PSCU 114, or BSCUs 116 identifying the presence of an occupant and further identifying an unfastened seat belt. In addition, an audible alert may also be produced by the SMCU 104 responsive to receipt of a message identifying an unfastening of a seat belt after the seat belt has been detected and reported as fastened. To this end, buckle sensors in each of the seat units may be calibrated for identifying a proper placement of the buckle in a latch and retention of the buckle in the latch (e.g., “fastened seat belt”). Accordingly, the system 100 includes standard system units that continually monitor the occupying/vacating of seats in conjunction with the buckling/unbuckling of seat belts and that produce audible alerts responsive to the identification of an unsafe condition.
Alerts may be detected by one or more FOBCUs 110 (e.g., FOB) and/or communicated to one or more FOBCUs 110. The FOB may function in the system 100 as a two-way communication device for receiving and communicating alerts to the holder of the FOB who is typically the driver of the vehicle 102 but may also be a passenger in the vehicle. For example, the FOB may communicate a haptic or audible alert to its holder responsive to receiving an alert for a seat belt that is unbuckled. Further, a movement of a FOB outside of a radius that is centered in the SMCU 104 may also cause an alert to be communicated to the holder of the FOB. The holder of a FOB is typically the first responder to an unsafe condition in the vehicle 102. Accordingly, a FOB that is identified as moving towards the network perimeter 108 may be suggestive of an unsafe condition because the holder of the FOB may be unable to respond to an unsafe condition in the vehicle 102 and because the FOB may become unreachable to the SMCU 104. Accordingly, a movement towards the network perimeter 108 may be identified and alerted based on two predetermined distances (e.g., radiuses) from the SMCU 104. For example, the FOBCU 110 may detect and communicate a “first distance alert” (e.g., first stage alert) to the holder of the FOB responsive to the FOBCU 110 identifying itself as moving beyond a “first distance” from the vehicle 102. Further for example, the FOBCU 110 may communicate a “second distance alert” (e.g., second stage alert) to the holder of the FOB responsive to the FOB identifying itself as moving beyond a second (e.g., greater) distance from the vehicle 102 but before moving beyond the network perimeter 108. The holder of the FOB (e.g., driver) may initially dismiss (e.g., “snooze” button) the “first distance alert,” however, after a predetermined number of dismissals, the “first distance alert” may no longer be dismissed. As mentioned above, the FOBCU 110 is a standard system unit that is scalable. For example, the SMCU 104 may identify the addition of a second FOB, a third FOB, etc. responsive to the SMCU 104 identifying a FOB as entering the network perimeter 108. In one example, the vehicle 102 may be driven away without the second FOB being present in the vehicle 102 causing a “first distance alert” at the second FOB, a “second distance alert” at the second FOB, and finally resulting in the second FOB being outside the network perimeter 108. In this example, the second FOB communicates single alert to the holder of the second FOB. The holder of the second FOB may deactivate (e.g., manually) the alert by pressing a Standby button on the second FOB, as described further below.
The system 100 may further alert the detection of an unsafe temperature condition. For example, the SMCU 104 may detect and alert an unsafe temperature, an unsafe rate of change of temperature, or an unsafe duration of an unsafe temperature or range of temperatures. The SMCU 104 may distinguish a safe temperature condition from an unsafe temperature condition by continually sensing the temperature, computing a rate of temperature change, measuring a duration of exposure and comparing the gathered information with predetermined thresholds. For example, the SMCU 104 may include a temperature sensor that senses and communicates messages including information regarding temperature to the SMCU 104. The SMCU 104 may identify that a temperature that was measured exceeds a predetermined threshold and communicate an alert (Temperature Alert) to all FOBCUs 110 that are identified as linked to the SMCU 104. The alert for an unsafe temperature condition may override other alerts/alarms. For example, the alert for an unsafe temperature condition may cause the cancelation of all previously transmitted alarms/alerts (e.g., unbuckled seat belt), according to an embodiment. Further, the alarm for an unsafe temperature condition may not be disabled or deactivated, according to an embodiment. In addition, the alert for an unsafe temperature condition may be escalated to alert FOBCUs 110 other than FOBCUs 110 that are linked to the SMCU 104. For example, responsive to the SMCU 104 not detecting an intervention (e.g., detecting a sensor that indicates a removal of child from a seat) after the elapse of a predetermined period of time (e.g., ten minutes) or detecting no FOB s as being detected inside the network perimeter 108 (Temperature—No Fob—Alert), the SMCU 104 may escalate the temperature alert to a temperature exposure alert. The SMCU 104 broadcasts a message indicating a “temperature exposure alert” to any FOBCU 110 inside the network perimeter 108. Accordingly, any FOBCU 110 (e.g., not only FOBCUs 110 linked in a session with the SMCU 104) that are located inside the network perimeter 108 may receive temperature exposure alert. For example, a FOBCU 110 that is not linked with the first system 100 may nevertheless receive the broadcasted temperature exposure alert. Further, the SMCU 104 of the first system 100 may progressively lengthen the radius of the network perimeter 108 to communicate with FOBCUs 110 that were previously unreachable. For example, an SMCU 104 that is utilizing a radio frequency network may progressively boost the radio frequency signal to progressively lengthen the radius of the network perimeter 108 to enable communication with FOBCUs 110 that were previously unreachable.
“Table A” describes alerts that are asserted by the SMCU 104.
The system 100 may further include an object finder. For example, the SMCU 104 may include a “Find Object” button that activates the object finding function. To this end, pressing the “Find Object” button in association with a second selection that identifies a target may cause a particular SSU to emit an audible sound, all SSUs to emit an audible sound, or an identified class of SUs to emit an audible sound (e.g., FOBCUs 110).
The system 100 further includes optional system units. The optional system units are illustrated to the left of the SMCU 104. The optional system units may include a video display control unit (VDCU) 122, a car electronics control unit (CECU) 124, an emergency responder control unit (ERCU) 126, one or more object tracking control units (OTCU) 128, one or more object monitoring control units (OMCU) 130, and one or more pet collar control units (PCCU) 132. The VDCU 122 includes a visual display unit that may be mounted on or inside the vehicle 102. The visual display unit may luminesce patterns that communicate an urgency and that are associated with alarm definitions (e.g., unsafe temperature condition). In another embodiment, the VDCU 122 may include a scrolling display unit in the form of a “Ticker Display” that scrolls a message across a display that may be read by a person passing by the vehicle 102. For example, the “Ticker Display” may be configured to display a message warning that the vehicle 102 has an endangered child. Further, the message may include instructions. For example, the instructions may describe particular actions to be performed (e.g., “please remove child,” “please telephone 911,” etc.). Accordingly, a person passing by the vehicle 102 (e.g., without a FOB), including another driver, may identify an occupant of the vehicle as being in danger.
The CECU 124 may be utilized to communicate an alert to the electronics of the vehicle 102 that may, in turn, communicate the alert via specialized devices of the vehicle 102. For example, the SMCU 104 may utilize the CECU 124 to communicate with the electronics of the vehicle 102 to control honking the horn of the vehicle 102 or the flashing the headlights of the vehicle 102.
The ERCU 126 is an emergency responder interface (ERI) for communicating over the network 106 (e.g., WiFi, radio frequency, etc.) with the SMCU 104 and for communicating over a network 134 (e.g., cellular, emergency, Internet, WAN, etc.) with external network elements. The ERCU 126 may be utilized to hale an emergency responder and/or to facilitate the provision of other emergency services. For example, the SMCU 104 may communicate a message, over the network 106, to the ERCU 126 that, in turn, communicates the message over the network 134 (e.g., cellular, satellite, plain old telephone service (POTS), Internet, etc.) to a wireless device 135 (e.g., smartphone), computer 136 or a call center server 138. Further, the ERCU 126 may include a global position receiver that receives information from one or more global position system satellites 144 and calculates its geographical location (e.g., geographic coordinates) based on the information. Accordingly, the ERCU 126 may append geographic coordinates to any message that is communicated by the SMCU 104 to or via the ERCU 126. For example, the SMCU 104 may communicate a message including an email message, a text message or a voice message for requesting emergency services and the ERCU 126 may append geographic coordinates to the message that identifies the location of the vehicle 102 as the ERCU 126 is located inside the vehicle 102. The call center server 138 may be operated by operators who receive the message and contact emergency services (e.g., 911, Fire, Police, etc.). In another embodiment, the call center server 138 may automatically forward the message to the emergency services. Further, the call center server 138 may be coupled to a database 140 that is utilized to store configurable parameters as control unit information to personalize the operation of a particular SMCU 104. The configurable parameters may be retrieved by the SMCU 104 and utilized by the SMCU 104 to configure the system 100. According to one embodiment, a user may enter the configurable parameters, via a user interface, that are received by the computer 136 that may, in turn, communicate the configurable parameters, over the network 134, to the call center server 138 that, in turn, stores the configurable parameters in the database 140. Subsequently, an SMCU 104 may retrieve the configurable parameters from the database 140 and utilize the configurable parameters to configure the SMCU 104 and other SUs.
The system 100 may further include an object tracking system for locating objects. The object tracking system may include one or more object tracking control units 128 and one or more object monitoring control units 130. The object tracking control units 128 and the object monitoring control units 130 may communicate with the SMCU 104. The object tracking control units 128 may be respectively associated with mobile objects (e.g., people) and may communicate, via the SMCU 104, to the one or more object monitoring control units 130, to enable the SMCU 104 and the object monitoring control units to identify the location of the object tracking control units, as described in further detail below.
The system 100 may further include a pet collar system. The pet collar system may be included in the object tracking system and is used for finding a pet that is lost and/or monitoring the temperature in the immediate environment of the pet. The pet collar system may include a pet collar that includes a pet collar control unit 132 and that includes a temperature sensor that measures temperature. The pet collar may be worn by the pet (e.g., small animal, dog, cat, etc.). Responsive, to detecting an unsafe temperature at the pet collar, the SMCU 104 may communicate an alert to the FOBCU(s) 110 to prompt the holder of the FOB to return to the vehicle 102. Further, the pet collar may be tracked, as described further below, to enable a vehicle 102 that is equipped with the pet collar system and the object tracking system to travel through a neighborhood and locate a pet that is lost and wearing the collar. In another embodiment, the pet collar control unit 132 may include a global tracking receiver enabling the pet collar control unit 132 to communicate global coordinates to the SMCU 104 that, in turn, may be utilized by the SMCU 104 to communicate the location of the pet.
According to a first embodiment, the call center server 138 may communicate the user interface 159 including input boxes for configurable parameters over the network 134 to the computer 136, receive the configurable parameters, via the input boxes, from the computer 136 and store the configurable parameters in the appropriate row of the passenger transport system information 142 in the database 140. Further, the call center server 138 may communicate the configurable parameters over the network 134 to the ERCU 126 that, in turn, communicates the configurable parameters, over the network 106, to the SM module 170 at SMCU 104, that, in turn stores the configurable parameters in the system monitor information storage 174. Accordingly, the SM module 170 may retrieve and utilize the configurable parameters from the system monitor information storage 174, as needed.
According to another embodiment, the SM module 170, at the SMCU 104, may communicate the user interface 159 including input boxes for receiving configurable parameters to the touch sensitive screen on the SMCU 104, receive the configurable parameters from the touch sensitive screen, and store the configurable parameters in the system monitor information storage 174. Accordingly, the SM module 170 may retrieve and utilize the configurable parameters from the system monitor information storage 174, as needed.
The “Find Object” button 160 and the “Initialize” button 162 may be pressed to perform various functions. The “Find Object” button 160 may be pressed to cause a system unit that is selected on the display to produce an audible sound. For example, the touch sensitive screen displays an object tracking control unit 128 (e.g., “Tracked Object #3”) as being selected. Responsive to the “Find Object” button 160 being pressed, the object tracking control unit 128 (e.g., “Tracked Object #3”) emits an audible sound. Further, the right side of the display illuminates an object tracking control unit 128 (e.g., “TRACKED OBJECT #3”) as being seventy-five feet from the SMCU 104 and as not moving (e.g., “SUBJECT IS STATIONARY”) as determined by a signal strength. Other embodiments may display geographic coordinates or a location of the object tracking control unit 128 on a map that is displayed on the touch sensitive screen. The “Initialize” button 162 may be pressed to cancel an alert. For example, unbuckling a seat belt may cause an audible alert that is canceled by pressing the “INITIALIZE” push button 162.
In another embodiment, the touch sensitive screen may illustrate additional statuses. For example, in an embodiment that includes a vehicle in the form of a commercial airplane, the touch sensitive screen, on the SMCU 104, may display one or more statuses for each of the seats on the airplane. For example, the touch sensitive screen may display a first status indicating whether a particular seat is occupied or not occupied. Further, for example the touch sensitive screen may display a second status indicating whether the seat belt for a particular seat is occupied or not occupied.
The SMM 170 may communicate with system units including standard system units and optional system units. The standard system units may include one or more FOBCUs 110, one or more CSCUs 112, one or more PSCUs 114, and one or more BSCUs 116. The optional system units may include the VDCU 122, the CECU 124, the ERCU 126, one or more OTCUs 128, one or more OMCUs 130, and the PCCU 132, according to an embodiment.
The system monitor module (SMM) 170 periodically checks for receipt of an “occupant present” message (OPM) from an LLCU 118, BSCU 116 or PSCU 114. Responsive to identifying receipt of an OPM message, the SMM 170 exits a “Standby” mode to enter an “Up” mode. After receiving the OPM, the SMM 170 waits to receive a “belts buckled” message from the LLCU 118 (three belts including two of its own and one of the ULCU 120), BSCU 116 and/or PSCU 114, according to an embodiment. It will be appreciated that a particular system 100 may include various numbers of various types of standard system units or none at all. Accordingly, the architecture of the system 100 to safely transport passengers enables an independent and real-time scaling of multiple types of standard system units.
The SMM 170 may receive a “belts bucked” or “belts unbuckled” message from an LLCU 118 with an occupant, a BSCU 116 with an occupant or a PSCU 114 with an occupant. The SMM 170 may identify whether all occupied seats are associated with a status indicating a buckled seat belt.
A user may press the “INITIALIZE” button 162 to indicate a seat is being vacated. Responsive to receiving an indication of the “INITIALIZE” button 162 being pressed to indicate a seat is being vacated, the SMM 170 may initialize a timer with a predetermined period of time (e.g., five minutes), according to an embodiment. If the SMM 170 receives an “occupant vacated seat” message from a standard system unit for a seat before the “INITIALIZE” button 162 is pressed (indicating a seat vacate), the SMCU 104 may produce an audible alert until the “INITIALIZE” button 162 is pressed (indicating a seat vacate), according to an embodiment.
The system monitor module (SMM) 170 “links” to a system unit (SU) by broadcasting a “Request to link” message. The SUs located inside the network perimeter 108 may respond to the “Request to link” message with an acknowledgment including the system unit identifier 150 and the system unit type 188. SUs located outside the network perimeter 108 may not respond to the “Request to link” message as the SUs located outside the network perimeter 108 may not receive the “Request to link” message. Whether or not the SU responds to the “Request to link” message may be determined by a signal strength that is utilized by the SMM 170 to broadcast the “Request to link” message. In some instances, the SMM 170 may increase the radius of the network perimeter 108 by increasing the signal strength that is used to broadcast the “Request to link” message. The SU may respond to the “Request to link” message by communicating an acknowledgment message to the SMM 170 to acknowledge receipt of the “Request to link” message. The acknowledgment message may include the system unit identifier 150 and the system unit type 188. The system unit identifier 150 uniquely identifies the SU that is responding from other SUs. The system unit type 188 identifies the type of SU (e.g., CSCU 112, PSCU 114, BSCU 116, VDCU 122, CECU 124, ERCU 126, OTCU 128, OMCU 130, PCCU 132). The SMM 170 may update the system unit status 190 for the appropriate SU in the session information 180 to “LINKED” responsive to the SMM 170 receiving the message that acknowledges receipt of the “Request to link” message. The system unit status 190 “STANDBY” signifies the SU may communicate with the SMCU 104 but is not presently “LINKED.” The system unit status 190 “LINKED” signifies the SU is linked with the SMCU 104 and communicating with the SMCU 104. “Table B” describes system unit statuses (excluding FOBs).”
The SMM 170 may periodically communicate an “Are you there?” message to an SU other than a FOBCU 110 and other than an OTCU 128 responsive to identifying the SU as being registered in the session information 180. The SUs may receive and respond to the “Are you there?” message by communicating an acknowledgment of receipt of the handshake message to the SMCU 104. Receipt of the acknowledgement by the SMCU 104 indicates the SU is LINKED and communicating.
The SMM 170 may “link” to a FOBCU 110 by broadcasting a “Request to link” message. FOBCUs 110 located inside the network perimeter 108 may respond to the “Request to link” message with a FOB acknowledgment including a system unit identifier 150 in the form of a FOB identifier 192. FOBs located outside the network perimeter 108 may not respond to the “Request to link” message as the FOB may not receive the “Request to link” message. Whether or not the FOB responds to the “Request to link” message may be determined by a signal strength that is utilized by the SMCU 104 to broadcast the “Request to link” message. In some instances, the SMCU 104 may increase the radius of the network perimeter 108 by increasing the signal strength for communicating messages.
The SMM 170 may receive the FOB acknowledgement and adds a row to the FOB information 182 responsive to identifying the particular FOB as not being previously registered in the FOB information 182. Each row stores the FOB identifier 192, the FOB distance 194, and the FOB status 196. The FOB identifier 192 uniquely identifies the FOB from other system units. The FOB distance 194 is an estimate of the distance between the FOBCU 110 and the SMCU 104. The FOB distance 194 is estimated by the SMM 170 based on the signal strength of the FOB acknowledgment that is being received from the particular FOB. The SMCU 104 provides an indication of signal strength in conjunction with receipt of the FOB acknowledgement that is received by the SMM 170 to enable the system monitor module 170 to estimate the distance. For example, the transceiver that is coupled to the SMCU 104 may provide the indication of the signal strength to the SMCU 104 that, in turn, provides the indication of the signal strength to the SMM 170. A strong signal strength indicates a short distance between the SMCU 104 and the FOBCU 110 and a weak signal strength indicates a long distance. For example, a received signal strength of “100%” may correspond to a distance of twenty-five feet; a received signal strength of “50%” may correspond to a distance of fifty feet; and the received signal strength of “25%” may correspond to a distance of one hundred feet. Other embodiments may utilize other schemes to associate a received signal strength with a distance. The FOB status 196 may be identified by the SMM 170 based on the FOB distance 194.
“Table C” describes the FOB status 196 at the SMCU 104.
The SMM 170 may register a “no FOB alert” responsive to the SMM 170 identifying at least one seat as being occupied with its associated seat belt being buckled and no FOBCUs 110 being registered in the FOB information 182. The SMM 170 maintains the “no FOB alert” until a FOBCU 110 responds to the “Request to link” message or the status of the seat changes.
The SMM 170 may periodically communicate an “Are you there?” message to a FOBCU 110 responsive to identifying the FOBCU 110 as being registered in the FOB information 182. The FOB may receive and respond to the “Are you there?” message by communicating a FOB acknowledgment of the “Are you there?” message to the SMCU 104. Receipt of the FOB acknowledgement indicates the FOB is linked and communicating. The SMM 170 further utilizes the strength of the FOB acknowledgment (e.g., “I am here” message) to update the FOB distance 194 in the FOB information 182, as described above.
In another embodiment, the LLCU 118 may be included in a housing that is affixed to the housing of an existing lower seat belt receptacle of the child car seat 200. For example, the housing that includes the LLCU 118 may be affixed with a sticky adhesive to the housing of the existing lower seat belt receptacle. Further, according to the same embodiment, the ULCU 120 may be included in a housing that is affixed to the housing of an existing upper seat belt receptacle of the child car seat 200. For example, the housing that includes the ULCU 120 may be affixed with a sticky adhesive to the housing of the upper seat belt receptacle.
The ULCU 120 may operate in “Standby” mode until the belt buckle sensor 214 registers a seat belt as buckled. The ULCU 120 may send “belt buckled” message to the LLCU 120 and transition to the “Up” mode responsive to the belt buckle sensor 214 sensing the seat belt being buckled. Further, the ULCU 120 may send “belt unbuckled” message to ULCU 120 and transition to the “Standby” mode responsive to the belt buckle sensor 214 sensing the seat belt being unbuckled. The ULCU 120 may further periodically read the temperature sensor 212 and communicate a message including temperature information to the LLCU 112 that, in turn, communicates a message to the SMCU 104. For example, the temperature information may include the ambient temperature.
The LLCU 120 may operate in “Standby” mode until the left belt buckle sensor 224 senses the seat belt as buckled, the right belt buckle sensor 226 senses the seat belt as buckled, and a message is received from the ULCU 120 indicating a sensing of its seat belt as being buckled. Further, the LLCU 118 may send a “belt unbuckled” message to SMCU 104 and transition to the “Standby” mode responsive to the LLCU 118 identifying the left belt buckle sensor 224 sensing its seat belt unbuckled, the right belt buckle sensor 226 sensing its seat belt unbuckled, or receiving a message from the ULCU 120 indicating the belt buckle sensor 214 sensing its seat belt unbuckled.
The PSCU 114 may operate in “Standby” mode until the belt buckle sensor 244 registers a seat belt as buckled. The PSCU 114 may send the “belt buckled” message to the SMCU 104 and transition to the “Up” mode responsive to the belt buckle sensor 244 sensing the seat belt being buckled. Further, the PSCU 114 may send “belt unbuckled” message to SMCU 104 and transition to the “Standby” mode responsive to the belt buckle sensor 244 sensing the seat belt being unbuckled.
The BSCU 116 may operate in “Standby” mode until the belt buckle sensor 264 registers a seat belt as buckled. The BSCU 116 may send “belt buckled” message to the SMCU 104 and transition to the “Up” mode responsive to the belt buckle sensor 264 sensing the seat belt being buckled. Further, the BSCU 116 may send “belt unbuckled” message to SMCU 104 and transition to the “Standby” mode responsive to the belt buckle sensor 264 sensing the seat belt being unbuckled.
In another embodiment, the FOB 109 may communicate additional statuses. For example, in an embodiment that includes a vehicle in the form of a commercial airplane, the FOB 109 may emit a status that identifies a row of seats as the holder of the FOB 109 walks by the row of seats. Continuing with the example, the FOB 109 may emit a haptic alert responsive to the FOB 109 being carried by a row of seats that includes at least one seat that is registered as being occupied and with the seat belt being registered as unbuckled. For example, the SMCU 104 may utilize signal strength, as previously described, to identify whether the FOB 109 is being carried by the described row of seats and communicate the haptic alert to the FOBCU 110 that, in turn, causes the FOB 109 to emit a haptic alert in the form of a burst.
Each local FOB status 296 and corresponding SMCU distance 294 in the local FOB information 290 may be periodically updated by the FOB module 280. For example, the local FOB 296 status and the SMCU distance 294 may be updated by the FOB module 280 responsive to the FOB module 280 receiving an “Are you there?” message from an SMCU 104. That is, the SMCU 104 may periodically broadcast an “Are you there?” message to the FOBCU 110 that may be received by the FOBCU 110 and processed by the FOB module 280 which responds by communicating a FOB acknowledgment to the SMM 170 (e.g., handshake) and further by updating the SMCU distance 294 and the local FOB status 296 in the local FOB information 290, as described above. Accordingly, the FOB module 280 may utilize the local FOB information 290 in conjunction with periodic receipt of “Are you there?” messages to maintain an accurate SMCU distance 294 and local FOB status 296 for the FOBCU 110.
The visual display module 330 may receive a message indicating an alert from the SMCU 104 and respond to the alert by turning on or off the scrolling display unit 334 and/or the visual display unit 336. The alert may include the “Temperature—No FOB—Alert” and the “Temperature Exposure Alert.”
The visual display module 330 may control the displaying of scrolling display messages on the scrolling display unit 334. The scrolling display messages are stored as scrolling display message information 157 in the control unit information 152 in the database 140 that is coupled to the call center server 138. The call center server 138 may communicate the scrolling display message information 157 to the SMCU 104 that, in turn, communicates the scrolling display message information 157 to the VDCU 122. In another embodiment, the visual display module 330 may retrieve the scrolling display message information 157 directly from call center server 138 via the emergency responder control unit 126.
The emergency responder module (ERM) 340 may receive, over the network 106, a message, indicating an alert, from the SMCU 104 and communicate the message, over the network 134, to the call center server 138 that, in turn, communicates the message to emergency responders. The ERM 340 may append the system unit identifier 150 of the SMCU 104 and geographic coordinates to the message. The call center server 138 may receive the message and communicate the message to emergency responders. The emergency responders may include public entities (e.g., “911 services,” fire, police, etc.) and private entities (e.g., family members). The call center server 138 may communicate the message to private entities by accessing the control unit information 152 in the database 140 that is coupled to the call center server 138 based on the system unit identifier 150. For example, the control unit information 152 may be accessed based on the system unit identifier 150 that is appended to the message. For example, the call center server 138 may retrieve telephone number information 153 (e.g., telephone numbers) and email address information 154 (e.g., email addresses) based on the system unit identifier 150 and communicate the message over the network 134 by utilizing the telephone numbers and email addresses. In one embodiment the ERM 340 may utilize the phone dialer 346 to place a telephone call over an Internet connection established over the network 134 (e.g., Internet). For example, the ERM 340 may utilize voice over Internet protocol. In another embodiment the ERM 340 may utilize the phone dialer 346 to place a telephone call using plain old telephone service (POTS).
At operation 404, the SMM 170 receives, from over the network 106 (e.g., wireless network), an “occupant present” message from LLM(s), BSM(s), PSM(s) or a “Belt Clicked” message from LLM(s), BSM(s), PSM(s). The dashed line indicates external network input (e.g., message, push button, etc.).
At decision operation 406, the SMM 170 identifies whether a session is in progress. If the SMM 170 identifies a session is in progress, then processing continues at decision operation 408. Otherwise, processing continues at operation 410. At operation 410, the SMM 170 performs a temperature check.
At decision operation 408, the SMM 170 identifies whether the “occupant present” message received at operation 404 indicates a child is occupying a child car seat 200. For example, the “occupant present” message may indicate the occupant present sensor 222 on the LLCU 118 indicates the presence of an occupant in the child car seat 200. If the SMM 170 identifies the “occupant present” message indicates a child is occupying the child car seat 200, then processing continues at decision operation 412. Otherwise processing continues at operation 414.
At decision operation 414, the SMM 170 identifies whether the “occupant present” message received at operation 404 indicates a child is occupying a booster seat 250. For example, the occupant present message received at operation 404 message may indicate the occupant present sensor 262 on the BSCU 116 indicates the presence of an occupant in the booster seat 250. If the SMM 170 identifies the “occupant present” message indicates a child is occupying a booster seat 250, then processing continues at decision operation 416. Otherwise processing continues at decision operation 418.
At decision operation 418, the SMM 170 identifies whether the “occupant present” message indicates a child is occupying a passenger seat 230. For example, the occupant present message received at operation 404 may indicate the occupant present sensor 242 on the PSCU 114 indicates the presence of an occupant in the passenger seat 230. If the SMM 170 identifies the “occupant present” message indicates a child is occupying a passenger seat 230, then processing continues at decision operation 420. Otherwise processing continues at operation 402.
At decision operation 412, the SMM 170 identifies whether the seat belts at the child car seat 200 are buckled. For example, the SMM 170 may have previously received a “belts buckled” message from the LLCU 118 and stored a “belts buckled” status in the system monitor information storage 174. If the SMM 170 identifies the seat belts at the child car seat 200 are buckled based on the “belts buckled” status, then processing continues at decision operation 420 (via on-page connector “X”). Otherwise processing continues at operation 422.
At operation 422, the SMM 170 activates a “belt unbuckled alert.” For example, the SMM 170 may cause the SMCU 104 to emit an audible alert responsive to the activation of the “belt unbuckled alert.”
At decision operation 416, the SMM 170 identifies whether the seat belt at the booster seat 250 is buckled. For example, the SMM 170 may have previously received a “belts buckled” message from the BSCU 116 and stored a “belts buckled” status in the system monitor information storage 174. If the SMM 170 identifies the seat belt at the booster seat 250 is buckled based on the “belts buckled” status, then processing continues at decision operation 420. Otherwise processing continues at operation 422.
At decision operation 420, the SMM 170 identifies whether all seats that are registered as sensing an occupant present are also registered with seat belts buckled. If the SMM 170 identifies that all seats registered as occupied are further registered with seat belts buckled, then processing continues at operation 424. Otherwise, processing continues at operation 422.
At operation 424, the SMM 170 deactivates the “belt unbuckled alert.” For example, the SMM 170 may cause an audible alert to cease. At operation 426, the SMM 170 registers the beginning of a session. For example, the SMM may store an “in session” status in the system monitor information storage 174.
At operation 428, the SMM 170 periodically broadcasts a “Looking for FOBs” (e.g., Request to link) message. In addition, the SMM 170 periodically scans the FOB information 182 and communicates an “Are you there??” message to a FOBCU 110 responsive to identifying the FOBCU 110 as being registered in the FOB information 182. The SMM 170 repeats this operation for each FOBCU 110 that is identified as registered in the FOB information 182. The frequency of broadcasting the “looking for FOBs”/“Request to link” message and the frequency of communicating the “Are you there??” message may be the same or different. For example, the SMCU 104 may broadcast the “looking for FOBs”/“Request to link” message every second and communicate the “Are you there??” message every 500 milliseconds.
At operation 430, the SMM 170 may receive an “I am here” message from a FOBCU 110 that received the “Are you there?” (e.g., operation 504 on
Returning to
Off page connectors are described. Entering the method 400 from off-page connector 438 (“B”), the SMM 170 continues processing at operation 410. The off-page connector 438 (“B”) on
At decision operation 450, the SMM 170 identifies whether any of the seats that are registered as occupied are also registered with a seat belt being unbuckled. If the SMM 170 identifies that any of the seats that are registered as occupied are also registered with a seat belt being unbuckled, then processing continues at operation 452. Otherwise, processing continues at operation 456.
At operation 454, the SMM 170 may receive an indication that the initialize button 162 on the SMCU 104 was pushed. For example, pressing the initialize button 162 on the SMCU 104 may cause an interrupt that is serviced by the SMM 170 that, in turn, stores a status indicating the initialize button 162 was pushed in the system monitor information storage 174.
At decision operation 456, the SMM 170 identifies whether the initialize button 162 was pushed. For example, the SMM 170 may identify whether the status in system monitor information storage 174 indicates the initialize button 162 was pushed. If the SMM 170 identifies the initialize button 162 was pushed then processing continues at operation 457, Otherwise, processing continues at decision operation 458.
At decision operation 458, the SMM 170 identifies whether the temperature is OK. For example, SMM 170 may compare the temperature being sensed by the temperature sensor 172 on the SMCU 104 with a predetermined threshold to identify whether the temperature exceeds a predetermined threshold. If the SMM 170 identifies the temperature as exceeding a threshold (e.g., temperature not OK), then processing continues at decision operation 460. Otherwise, processing continues at operation 450.
At operation 460, the SMM 170 communicates a “temperature alert” to all FOBs that are linked to the SMCU 104 (see method 550,
At operation 462, the SMM 170 may wait for a predetermined period of time. For example, the SMM 170 may wait for 30 seconds.
At decision operation 464, the SMM 170 identifies whether a “temperature exposure alert” should be asserted. For example, the SMM 170 may 1) compute a rate of temperature change based on sensing the temperature during the wait period, and 2) compare the computed rate of temperature change with a predetermined threshold to identify whether a “temperature exposure alert” should be asserted. Further for example, the SMM 170 may compute whether an exposure to a range of temperatures during the wait time exceeds a predetermined threshold to identify whether a “temperature exposure alert” should be asserted. Other embodiments may utilize a time period that is different from the wait time. If the SMM 170 identifies a “temperature exposure alert” should be asserted, then a branch is made to operation 466. Otherwise, processing continues at decision operation 468.
At operation 466, the SMM 170 broadcasts a “temperature exposure alert” to linked and non-linked FOBCUs 110. For example, the SMM 170 broadcasts the “temperature exposure alert” to FOBCUs 110 that are linked to the SMCU 104 and to FOBCUs 110 that are not linked to the SMCU 104 (see method 580,
At operation 470, the SMM 170 communicates the “temperature exposure alert” to the VDCU 122, CECU 124 and ERCU 126. The ERCU 126 communicates the “temperature exposure alert” to the call center server 138 that, in turn, communicates the “temperature exposure alert” to public emergency responders, including “911” services, other emergency responders, and the like. The CECU 124 may cause the horn to honk, the headlights to flash, and the like responsive to receiving the “temperature exposure alert.” The VDCU 122 may cause a scrolling display message (e.g., “Please rescue child in car seat from excessive temperature”) to be displayed on the scrolling display unit 334 responsive to receiving the “temperature exposure alert” and a strobing to commence on the visual display unit 336 responsive to receiving the “temperature exposure alert.” The SMM 170 may further send a message including a request to the ERCU 126 that, in turn, communicates the message to the call center server 138 that, in turn, communicates the message to public emergency services including“911” services, fire services, police servers, etc. The request may be an emergency responder to come to the vehicle 102. The request may further include geographic coordinates identifying the location of the vehicle 102, an indication of the temperature alert, the temperature of the vehicle 102, and the type of seat(s) (e.g., child, booster, etc.) that are occupied.
At decision operation 468, the SMM 170 identifies whether a FOBCU 110 is near. For example, the SMM 170 may compare FOB distances 194 in the FOB information 182 with a predetermined threshold and identifies a FOBCU 110 as being near if the FOB distance 194 for at least one FOBCU 110 is less than a “second distance” (e.g., associated with the “second distance alert”). If the SMM 170 identifies a FOBCU 110 is near, then a branch is made to decision operation 472. Otherwise processing continues at operation 466 via the on-page connector (“Z”).
At decision operation 472, the SMM 170 identifies whether the initialize button 162 was pushed. If the SMM 170 identifies the initialize button 162 was pushed then processing continues, via on-page connecter (“Y”) at decision operation 478. Otherwise, processing continues at operation 462.
At operation 452, the SMM 170 activates the “belt unbuckled alert.” For example, the SMM 170 may cause the SMCU 104 to emit an audible alert responsive that signals a “belt unbuckled alert.”
At decision operation 455, the SMM 170 identifies whether the initialize button 162 was pushed. If the SMM 170 identifies the initialize button 162 was pushed, then processing continues at operation 457. Otherwise, processing continues at operation 452.
At operation 457, the SMM 170 deactivates the “belt unbuckled alert.” For example, the SMM 170 may cause the deactivation of an audible alert that signifies the “belt unbuckled alert.”
At decision operation 478, the SMM 170 identifies whether at least one occupant is sensed. For example, the SMM 170 may identify whether at least one BSCU 116, PSCU 114, or CSCU 112, that is linked with the SMCU 104, is reporting an occupant as being present. If the SMM 170 identifies at least one occupant is sensed then a branch is made, via off-page connecter 438 (“B”), to operation 410. Otherwise, processing continues, via off-page connecter 440 (“C”), to operation 402.
At operation 504, the FOB module 280 performs a handshake with the SMCU 104. The FOB module 280 performs the handshake by waiting for an “Are you there?” message from the SMM 170. Responsive to receiving the “Are you there?” message, the FOB module 280 sends a FOB acknowledgement to the SMCU 104, as described further in method 630 of
At decision operation 506, the FOB module 280 identifies whether the FOBCU 110 is being placed in the standby mode by the SMM 170. If the FOB module 280 is being placed in the standby mode by the SMM 170 then a branch is made to “standby” state 508. Otherwise, processing continues at decision operation 516.
At decision operation 516, the FOB module 280 identifies whether its distance from the SMCU 104 is greater than a “first distance” that is predetermined (e.g., distance information 155). For example, the FOB module 280 may compare the SMCU distance 294 in the local FOB information 290 with a “first distance” that is predetermined (e.g., distance information 155). If the SMCU distance 294 is greater than a predetermined “first distance”, a branch is made to operation 518. Otherwise, processing continues at operation 520.
At operation 518, the FOB module 280 asserts a “first distance alert.” For example, FOB module 280 may cause the FOBCU 110 to generate a haptic alert that signals the “first distance alert.”
At operation 522, the FOB module 280 may receive an indication that the snooze button 272 on the FOBCU 110 was pushed. For example, pressing the snooze button 272 on the FOBCU 110 may cause an interrupt that is serviced by the FOB module 280 that, in turn, stores a status in the FOB information storage 282 indicating that the snooze button 272 was pushed.
At decision operation 523, the FOB module 280 may identify whether the snooze button 272 on the FOBCU 110 was pushed. For example, the FOB module 280 may read a status in the FOB information storage 282 indicating whether the snooze button 272 was pushed. If the FOB module 280 identifies the snooze button 272 on the FOBCU 110 was pushed, then a branch is made to decision operation 524. Otherwise, a branch is made to decision operation 526.
At decision operation 526, the FOB module 280 identifies whether its distance from the SMCU 104 is greater than a “second distance” that is predetermined (e.g., distance information 155). For example, the FOB module 280 may compare the SMCU distance 294 in the local FOB information 290 with a “second distance” that is predetermined. If the SMCU distance 294 is greater than the “second distance” that is predetermined, a branch is made to operation 528. Otherwise, processing continues at operation 530.
At operation 528, the FOB module 280 asserts a “second distance alert.” For example, FOB module 280 may cause the FOBCU 110 to generate a haptic alert that signals the “second distance alert.”
At operation 512, the FOB module 280 may receive an indication that the standby button 270 on the FOBCU 110 was pushed. For example, pressing the standby button 270 on the FOBCU 110 may cause an interrupt that is serviced by the FOB module 280 that, in turn, stores a status in the FOB information storage 282 indicating that the standby button 270 was pushed. At operation 514, the FOB module 280 sends a “going to standby” message to the SMM 170 indicating that the FOBCU 110 is going to the “standby” state and, at operation 508, the FOB enters the standby state.
At operation 530, the FOB module 280 deactivates the “second distance alert.” For example, the FOB module 280 may cause a haptic alert that signifies the “second distance alert” to cease. At decision operation 524, the FOB module 280 identifies whether the snooze button 272 on the FOBCU 110 was pressed three or more times. If the snooze button 272 was pressed three or more times, then a branch is made to decision operation 526. Otherwise, a branch is made operation 532. At operation 532, the FOB module 280 deactivates the “first distance alert.” For example, the FOB module 280 may cause the FOBCU 110 to cease generating a haptic alert signifying a “first distance alert.” At operation 534, the FOB module 280 waits for a predetermined period of time. For example, the FOB module 280 may wait for 500 milliseconds.
At decision operation 554, the FOB module 280 identifies whether it is linked to the SMCU 104 that communicated the message indicating the “temperature alert.” For example, the FOB module 280 may compare the SMCU identifier 151 in the message with the SMCU identifier 151 in the local FOB information 290 to identify a match, signifying the FOBCU 110 is linked to the SMCU 104. If the FOB module 280 identifies it is linked to the SMCU 104 then a branch is made to operation 556. Otherwise, processing ends.
At operation 556, the FOB module 280 asserts a “temperature alert.” For example, FOB module 280 may cause the FOBCU 110 to generate a haptic alert that signals the “temperature alert.”
At decision operation 584, the FOB module 280 identifies whether it is linked to the SMCU 104. For example, the FOB module 280 may compare the SMCU identifier 151 in the message indicating the “temperature exposure alert” with the SMCU identifier 151 in the local FOB information 290 to identify a match, signifying the FOBCU 110 is linked to the SMCU 104. If the FOB module 280 identifies it is linked to the SMCU 104, then a branch is made to operation 586. Otherwise, processing continues at decision operation 588.
At operation 586, the FOB module 280 asserts a “temperature exposure alert.” For example, FOB module 280 may cause the FOBCU 110 to generate a haptic alert that signals the “temperature exposure alert.”
At decision operation 588, the FOB module 280 identifies whether it is held by a community helper. For example, a user may designate themselves as a community helper by indicating “YES” to a prompt for “COMMUNITY HELPER” in the user interface 159. If the FOB module 280 identifies it is held by a community helper, then a branch is made to operation 590. Otherwise, processing ends.
At operation 590, the FOB module 280 asserts a community helper alert. For example, FOB module 280 may cause the FOBCU 110 to generate a haptic alert that signals a “community helper alert.”
At operation 604, at a FOBCU 110, the FOB module 280 receives the message and at decision operation 606 the FOB module 280 identifies whether it is linked with the SMCU 104 that broadcasted the “request for link” message. For example, the FOB module 280 may identify whether an SMCU identifier 151 in the “Request to link” message matches an SMCU identifier 151 in the local FOB information 290 in the FOB information storage 282. If the FOB module 280 identifies a match, then processing ends. Otherwise, processing continues at operation 608.
At operation 608, the FOB module 280 registers the link with the SMCU 104 in the local FOB information 290 at the FOBCU 110 by populating the local FOB information 290. For example, the FOB module 280 may write an SMCU identifier 151, an SMCU distance 294, and a local FOB status 296 in the local fob information 290, as previously described.
At operation 610, the FOB module 280 communicates a “FOB Acknowledgment” message to the SMCU 104 that communicated the “Request to link” message.
At operation 616, at the SMCU 104, the SMM 170 receives the “FOB Acknowledgment.” At operation 614, the SMM 170 registers a link with the FOBCU 110 in the FOB information 182 by populating a row in the FOB information 182. For example, the SMM 170 may write an FOB identifier 192, a FOB distance 194, and a FOB status 196 in the row, as previously described.
At operation 634, at the FOBCU 110, the FOB module 280 receives the “Are you there?” message and at decision operation 636 the FOB module 280 identifies whether the FOBCU 110 is linked with the SMCU 104 that communicated the message. For example, the FOB module 280 may read the local FOB information 290 in the FOB information storage 282 at the FOBCU 110 to identify the SMCU identifier 151 matches the SMCU identifier 151 in the message. If the FOB identifies a matching SMCU identifier 151 then a branch is made to operation 638. Otherwise processing ends.
At operation 638, the FOB communicates an “I am here” message to the SMCU 104. The “I am here” message includes a FOB identifier 192 that uniquely identifies the FOB that communicates the message.
At operation 640, at the SMCU 104, the SMM 170 receives the “I am here” message and at operation 642, the SMM 170 updates the row corresponding to the FOBCU 110 in the FOB information 182 in the system monitor information storage 174 on the SMCU 104. For example, the SMM 170 may write the FOB identifier 192, a FOB distance 194 and a FOB status 196 into the identified row, as previously described.
Each local OTCU status 748 and corresponding SMCU distance 294 in the local object tracking control unit information 746 may be periodically updated by the object tracking module 740. For example, the local OTCU status 748 and an SMCU distance 294 for a row may be updated by the object tracking module 740 responsive to the object tracking module 740 receiving an “Are you there?” message from an SMCU 104. That is, an SMCU 104 may periodically broadcast an “Are you there?” message to the OTCU 128 that may be received by the OTCU 128 and processed by the object tracking module 740 which responds by communicating a OTCU acknowledgment to the SMM 170 (e.g., handshake) and further by updating the SMCU distance 294 and the local OTCU status 748 in the local object tracking control unit information 746, as described above. Accordingly, the object tracking module 740 may utilize the local object tracking control unit information 746 in conjunction with periodic receipt of “Are you there?” messages to maintain an accurate SMCU distance 294 and local OTCU status 748 for the OTCU 128 that is linked/registered in the local object tracking control unit information 746.
The SMM 170 may “link” to an OTCU 128 by broadcasting a “Request to link” message. OTCUs 128 located inside the network perimeter 108 may respond to the “Request to link” message with a OTCU acknowledgment including a system unit identifier 150 in the form of a OTCU identifier 782. OTCUs 128 located outside the network perimeter 108 may not respond to the “Request to link” message as the OTCU 128 may not receive the “Request to link” message. Whether or not the OTCU 128 responds to the “Request to link” message may be determined by a signal strength that is utilized by the SMCU 104 to broadcast the “Request to link” message. In some instances, the SMCU 104 may increase the radius of the network perimeter 108 by increasing the signal strength for communicating messages.
The SMM 170 may receive the OTCU acknowledgement and update the row in the object tracking control unit (OTCU) information 780 responsive to identifying the particular OTCU 128 as not being previously registered in the OTCU information 780. The SMM 170 may store the OTCU identifier 782, the OTCU distance 784, and the OTCU status 786. The OTCU identifier 782 is included in the OTCU acknowledgement and uniquely identifies the OTCU 128 from other system units. The OTCU distance 784 is an estimate of the distance between the SMCU 104 and the OTCU 128. The OTCU distance 784 may be estimated by the SMM 170 based on the signal strength of the OTCU acknowledgment that is being received from the particular OTCU 128. The SMCU 104 provides an indication of signal strength in conjunction with receipt of the OTCU acknowledgement that is received by the SMM 170 to enable the system monitor module 170 to estimate the distance. For example, the transceiver that is coupled to the SMCU 104 may provide the indication of the signal strength to the SMCU 104 that, in turn, provides the indication of the signal strength to the SMM 170. A strong signal strength indicates a short distance between the SMCU 104 and the OTCU 128 and a weak signal strength indicates a long distance, as was previously described. The OTCU status 786 is described below.
The geographical information 790 may be used to store geographical coordinates and/or other information describing the location of the OTCU 128. The geographical information 790 be appended by the OTCU 128 to the OTCU acknowledgment to the “Request to link” message. Responsive to receipt of the OTCU acknowledgment to the “Request to link” message at the SMCU 104, the SMM 170 copies the geographical information 790 from the OTCU acknowledgment into the geographical information 790 in the OTCU status 786 of the appropriate row in the OTCU information 780.
The location information 792 may store a distance between the OTCU 128 and the SMCU 104, an indication whether the OTCU 128 is moving towards the SMCU or away from the SMCU 104, a current signal strength measurement, and a previous signal strength measurement (e.g., signal strength information). For example, the signal strength information may be obtained from the transceiver on the SMCU 104 in association with the receipt of a particular message.
The SMM 170 may periodically communicate an “Are you there?” message to an OTCU 128 responsive to the SMM identifying the OTCU 128 as being registered in the OTCU information 780. At the OTCU 128, the OTCU 128 receives and responds to the “Are you there?” message by communicating an OTCU acknowledgment to the SMCU 104. Receipt of the OTCU acknowledgement, at the SMCU 104, indicates the OTCU 128 is “linked” and communicating. The SMM 170 further utilizes the strength of the OTCU acknowledgment (e.g., “I am here” message) to update the OTCU distance 784 in the OTCU information 780, as described above. The geographical information 790 may be appended by the OTCU 128 to the OTCU acknowledgment to the “Are you there?” message. Responsive to receipt of the OTCU acknowledgment to the “Are you there?” message, the SMM 170 updates the geographical information by copying the geographical information 790 from the OTCU acknowledgment into the geographical information 790 in the OTCU status 786 of the appropriate row in the OTCU information 780 at the SMCU 104.
At operation 804, at a OTCU 128, the OTM 740 receives the “Request to link” message and at decision operation 806 the OTM 740 identifies whether it is “linked” with the SMCU 104. For example, the OTM 740 may identify whether an SMCU identifier 151 in the “Request to link” message matches the SMCU identifier 151 in the local OTCU information 746 in the object tracking information storage 742 at the OTCU 128. If the OTM 740 identifies a match, then processing ends. Otherwise, processing continues at operation 808.
At operation 808, the OTM 740 registers the “link” with the SMCU 104 in the local OTCU information 746 at the OTCU 128 by populating the row in the local OTCU information 746. For example, the OTM 740 may write an SMCU identifier 151, an SMCU distance 294, and a local OTCU status 748 in the row, as previously described.
At operation 810, the OTM 740 communicates an OTCU acknowledgment message to the SMCU 104. The OTM 740 may append geographical information to the OTCU acknowledgment message responsive to identifying a global position receiver 744 on the OTCU 128 and retrieving geographical information from the global position receiver 744. For example, the geographical information may include geographic coordinates identifying the location of the OTCU 128 and other information.
At operation 812, at the SMCU 104, the SMM 170 receives the OTCU Acknowledgment message including the geographical information. At operation 814, the SMM 170 registers a “link” with the OTCU 128 in the object tracking control unit information 780 by populating a row in the object tracking control unit information 780. For example, the SMM 170 may write an OTCU identifier 782 that identifies the OTCU 128 that communicated the OTCU Acknowledgment message.
At operation 816 the SMM 170 identifies location information. For example, the SMM 170 may identify location information by obtaining a signal strength that is associated with the receipt of the OTCU acknowledgement message. For example, the transceiver that is coupled to the SMCU 104 may provide the indication of the signal strength to the SMCU 104 that, in turn, provides the indication of the signal strength to the SMM 170. A strong signal strength indicates a small distance between the SMCU 104 and the OTCU 128 and a weak signal strength indicates a long distance. For example, a received signal strength of “100%” may correspond to a distance of twenty-five feet; a received signal strength of “50%” may correspond to a distance of fifty feet; and the received signal strength of “25%” may correspond to a distance of one hundred feet. Other embodiments may utilize other schemes to associate a received signal strength with a distance. Further, the SMM 170 may compare the most recently obtained signal strength with the previously obtained signal strength to identify whether the object is moving closer to the SMCU 104 (signal strength increase) or away from the SMCU 104 (signal strength decrease). Accordingly, the location information may include a distance between the OTCU 128 and the SMCU 104, an indication whether the object is moving towards the SMCU 104 or away from the SMCU 104, a current signal strength measurement, and a previous signal strength measurement.
At operation 818, the SMM 170 stores the location information in the appropriate row of the object tracking control unit information 780. For example, the SMM 170 stores the distance between the OTCU 128 and the SMCU 104 in the OTCU distance 784 field. Further, for example, the SMM 170 stores an indication whether the object is moving towards the SMCU 104 or away from the SMCU 104, a current signal strength measurement, and a previous signal strength measurement in the location information 792 field of the object tracking control unit status 786 of the object tracking control unit information 780.
At operation 820, the SMM 170 copies the geographical information that is appended to the end of the OTCU acknowledgement message from the OTCU acknowledgement message into the geographical information 790 field of the object tracking control unit status 786 of the object tracking control unit information 780.
At operation 854, at the OTCU 128, the object tracking module (OTM) 740 receives the “Are you there?” message and at decision operation 856 the OTM 740 identifies whether the OTCU 128 is “linked” with the SMCU 104 that communicated the message. For example, the OTM 740 may compare the SMCU identifier 151 in the local object tracking control unit information 746 in the object tracking information storage 742 at the OTCU 128 with the SMCU identifier 151 in the message to identify whether the two match. If the OTCU 128 identifies a matching SMCU identifier 151 then processing continues at operation 858. Otherwise processing ends.
At operation 858, the OTM 740 communicates the OTCU acknowledgment message to the SMCU 104. For example, the OTM 740 may communicate an “I am here” acknowledgment message to the SMCU 104. The “I am here” acknowledgment message includes an OTCU identifier 782 that uniquely identifies the OTCU 128 that communicates the message. Further, the OTM 740 may append geographical information to the OTCU acknowledgment message as described in operation 810 on
At operation 860, the SMM 170 receives the “I am here” acknowledgment message from the OTCU 128. At operation 862, the SMM 170 identifies location information, as described in operation 816 on
At the PCCU 132, the PCM 920 may read an ambient temperature from the temperature sensor 926, append that ambient temperature to an acknowledgment to the “Request to link” message, and communicate the acknowledgment message to the SMCU 104 responsive to receipt of a “Request to link” message. In addition, the PCM 920 may read an ambient temperature from the temperature sensor 926, append that ambient temperature to an acknowledgment to the “I am here” message, and communicate the acknowledgment message to the SMCU 104 responsive to receipt of a “Are you there?” message.
In the example architecture of
The operating system 2014 may manage hardware resources and provide common services. The operating system 2014 may include, for example, a kernel 2028, services 2030, and drivers 2032. The kernel 2028 may act as an abstraction layer between the hardware and the other software layers. For example, the kernel 2028 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on. The services 2030 may provide other common services for the other software layers. The drivers 2032 may be responsible for controlling or interfacing with the underlying hardware. For instance, the drivers 2032 may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, audio drivers, power management drivers, and so forth depending on the hardware configuration.
The libraries 2016 may provide a common infrastructure that may be utilized by the applications 2020 and/or other components and/or layers. The libraries 2016 typically provide functionality that allows other software modules to perform tasks in an easier fashion than to interface directly with the underlying operating system 2014 functionality (e.g., kernel 2028, services 2030 and/or drivers 2032). The libraries 2016 may include system 2034 libraries (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries 2016 may include API libraries 2036 such as media libraries (e.g., libraries to support presentation and manipulation of various media format such as moving picture experts group (MPEG) 4, H.264, MPEG-1 or MPEG-2 Audio Layer (MP3), AAC, AMR, joint photography experts group (JPG), portable network graphics (PNG)), graphics libraries (e.g., an Open Graphics Library (OpenGL) framework that may be used to render 2D and 3D in a graphic content on a display), database libraries (e.g., Structured Query Language (SQL) SQLite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like. The libraries 2016 may also include a wide variety of other libraries 2038 to provide many other APIs 2036 to the applications 2020 and other software components/modules.
The frameworks 2018 (also sometimes referred to as middleware) may provide a higher-level common infrastructure that may be utilized by the applications 2020 and/or other software components/modules. For example, the frameworks 2018 may provide various graphic user interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks 2018 may provide a broad spectrum of other APIs 2036 that may be utilized by the applications 2020 and/or other software components/modules, some of which may be specific to a particular operating system 2014 or platform.
The applications 2020 include built-in applications 2040 and/or third party applications 2042. Examples of representative built-in applications 2040 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and/or a game application. Third party applications 2042 may include any of the built in applications as well as a broad assortment of other applications 2020. In a specific example, the third party application 2042 (e.g., an application developed using the Android™ or iOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system 2014 such as iOS™, Android™, Windows® Phone, or other mobile operating systems 2014. In this example, the third party application 2042 may invoke the API calls 2024 provided by the mobile operating system such as operating system 2014 to facilitate functionality described herein.
The applications 2020 may utilize built in operating system functions (e.g., kernel 2028, services 2030 and/or drivers 2032), libraries (e.g., system 2034, APIs 2036, and other libraries 2038), frameworks/middleware 2018 to create user interfaces to interact with users of the system. Alternatively, or additionally, in some systems, interactions with a user may occur through a presentation layer, such as presentation layer 2044. In these systems, the application/module “logic” can be separated from the aspects of the application/module that interact with a user.
Some software architectures 2002 utilize virtual machines. In the example of
The machine 2100 may include processors 2110, memory 2130, and I/O components 2150, which may be configured to communicate with each other such as via a bus 2102. In an example embodiment, the processors 2110 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 2112 and processor 2114 that may execute instructions 2116. The term “processor” is intended to include multi-core processors 2112 that may comprise two or more independent processors 2112 (sometimes referred to as “cores”) that may execute instructions 2116 contemporaneously. Although
The memory/storage 2130 may include a memory 2132, such as a main memory, or other memory storage, and a storage unit 2136, both accessible to the processors 2110 such as via the bus 2102. The storage unit 2136 and memory 2132 store the instructions 2116, embodying any one or more of the methodologies or functions described herein. The instructions 2116 may also reside, completely or partially, within the memory 2132, within the storage unit 2136, within at least one of the processors 2110 (e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine 2100. Accordingly, the memory 2132, the storage unit 2136, and the memory of processors 2110 are examples of machine-readable media.
As used herein, “machine-readable medium” means a device able to store instructions 2116 and data temporarily or permanently and may include, but is not be limited to, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., erasable programmable read-only memory (EEPROM)) and/or any suitable combination thereof. The term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions 2116. The term “machine-readable medium” shall also be taken to include any medium, or combination of multiple media, that is capable of storing instructions (e.g., instructions 2116) for execution by a machine (e.g., machine 2100), such that the instructions 2116, when executed by one or more processors of the machine 2100 (e.g., processors 2110), cause the machine 2100 to perform any one or more of the methodologies described herein. Accordingly, a “machine-readable medium” refers to a single storage apparatus or device, as well as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices. The term “machine-readable medium” excludes signals per se.
The I/O components 2150 may include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components 2150 that are included in a particular machine 2100 will depend on the type of machine. For example, portable machines 2100 such as mobile phones will likely include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I/O components 2150 may include many other components that are not shown in
In further example embodiments, the I/O components 2150 may include biometric components 2156, motion components 2158, environmental components 2160, or position components 2162 among a wide array of other components. For example, the biometric components 2156 may include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram based identification), and the like. The motion components 2158 may include acceleration sensor components (e.g., accelerometer), gravitation sensor components, rotation sensor components (e.g., gyroscope), and so forth. The environmental components 2160 may include, for example, illumination sensor components (e.g., photometer), temperature sensor components (e.g., one or more thermometer that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detect concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The position components 2162 may include location sensor components (e.g., a Global Position System (GPS) receiver component), altitude sensor components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor components (e.g., magnetometers), and the like.
Communication may be implemented using a wide variety of technologies. The I/O components 2150 may include communication components 2164 operable to couple the machine 2100 to a network 2180 or devices 2170 via coupling 2182 and coupling 2172 respectively. For example, the communication components 2164 may include a network interface component or other suitable device to interface with the network 2180. In further examples, communication components 2164 may include wired communication components, wireless communication components, cellular communication components, near field communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices 2170 may be another machine 2100 or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a Universal Serial Bus (USB)).
Moreover, the communication components 2164 may detect identifiers or include components operable to detect identifiers. For example, the communication components 2164 may include radio frequency identification (RFID) tag reader components, NFC smart tag detection components, optical reader components (e.g., an optical sensor to detect one-dimensional bar codes such as Universal Product Code (UPC) bar code, multi-dimensional bar codes such as Quick Response (QR) code, Aztec code, Data Matrix, Dataglyph, MaxiCode, PDF417, Ultra Code, UCC RSS-2D bar code, and other optical codes), or acoustic detection components (e.g., microphones to identify tagged audio signals). In addition, a variety of information may be derived via the communication components 2164, such as, location via Internet Protocol (IP) geo-location, location via Wi-Fi® signal triangulation, location via detecting a NFC beacon signal that may indicate a particular location, and so forth.
In various example embodiments, one or more portions of the network 2180 may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), the Internet 80, a portion of the Internet 80, a portion of the public switched telephone network (PSTN), a plain old telephone service (POTS) network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, the network 2180 or a portion of the network 2180 may include a wireless or cellular network and the coupling 2182 may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile communications (GSM) connection, or other type of cellular or wireless coupling. In this example, the coupling 2182 may implement any of a variety of types of data transfer technology, such as Single Carrier Radio Transmission Technology (1xRTT), Evolution-Data Optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for GSM Evolution (EDGE) technology, third Generation Partnership Project (3GPP) including 3G, fourth generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standard, others defined by various standard setting organizations, other long range protocols, or other data transfer technology.
The instructions 2116 may be transmitted or received over the network 2180 using a transmission medium via a network interface device (e.g., a network interface component included in the communication components 2164) and utilizing any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)) Similarly, the instructions 2116 may be transmitted or received using a transmission medium via the coupling 2172 (e.g., a peer-to-peer coupling) to devices 2170. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions 2116 for execution by the machine 2100, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.
Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.
Although an overview of the inventive subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of embodiments of the present disclosure. Such embodiments of the inventive subject matter may be referred to herein, individually or collectively, by the term “disclosure ” merely for convenience and without intending to voluntarily limit the scope of this application to any single disclosure or inventive concept if more than one is, in fact, disclosed.
The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled. As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
| Number | Date | Country | |
|---|---|---|---|
| 62247691 | Oct 2015 | US | |
| 62255683 | Nov 2015 | US |
