Blocking Driver Texting in Moving Vehicles while Allowing Passengers to Text

Abstract

Systems and methods are described to block texting for a driver of a moving vehicle while allowing passengers to text. For one embodiment, the GPS position and/or speed of Texting-Capable Devices (TCDs) are compared via local communication (WiFi or Bluetooth) with those of local TCDs. If the position and/or speed track with one or more neighboring TCDs, those TCDs are assumed to be in the same vehicle. Further and via local communication, a TCD can query local TCDs to determine, using Known Acquaintance validation, if a TCD user is known to another TCD user. If so, they are assumed to be in the same vehicle. If one TCD in a vehicle is a registered Driver/Master TCD, then other TCDs in the vehicle (Passenger TCDs) are allowed to text. A TCD submitting a query need only reveal its GPS and/or Known Acquaintance data locally within its immediate vicinity.

Claims

1. A computerized method for controlling texting while driving, comprising: determining a velocity of a first Texting Capable Device (hereinafter: TCD); if the first TCD is travelling in excess of a velocity threshold, determining if there is at least a second TCD located within a position envelope encompassing the first and second TCDs; if there is no locatable second TCD within the position envelope, then disabling texting for the first TCD; if there is at least a locatable second TCD within the position envelope, then determining if either the first or second TCD is a registered Driver TCD (hereinafter: DTCD); and disabling texting for the DTCD and enabling texting for other TCDs determined to be within the position envelope; wherein the other TCDs determined to be within the position envelope are assumed to be Passenger TCDs (hereinafter: PTCDs); wherein the determining that the first and at least second TCDs are located within the position envelope is performed using local communication involving the first and at least second TCDs, wherein the local communication is established by wireless communication, and comprises one or more of the following methods: a) direct communication among the first and the at least second TCDs via Bluetooth of WiFi; or b) indirect communication among the first and the at least second TCDs via a local wireless hotspot operating within the same position envelope where the first and the at least second TCDs are located; or c) common communication wherein the first and the at least second TCDs communicate with one or more Texting Control Servers (hereinafter: TCS) by way of a common URL, the common URL being associated with a wireless capable device located in the same position envelope where the first and the at least second TCDs are located; and wherein both the first and at least second TCDs communicate with the one or more Texting Control Servers (TCSs) located remotely via a cellular communications network.

2. The computerized method of claim 1, wherein determining, using local communication, that the first and at least second TCDs are both located within the same position envelope is performed by comparing time-stamped GPS position data passed locally among the first and the at least second TCDs.

3. The computerized method of claim 2, wherein determining the velocity of the first TCD is performed remotely from the first TCD by monitoring a strength of a signal transmitted from the first TCD as received at one or more cell towers.

4. The computerized method of claim 2, wherein determining the velocity of the first TCD is performed by determining a velocity parameter within the first TCD, wherein the velocity parameter is transmitted from the first TCD to the TCS.

5. The computerized method of claim 2, wherein neither the DTCD nor any of the PTCDs in the position envelope transmit their GPS coordinates to the TCS.

6. The computerized method of claim 2, wherein determining that the first and the at least second TCDs are in the same position envelope is performed by an app installed in the first or at least second TCDs, or alternately by a software program integrated with a TCD operating system controlling the first or at least second TCDs.

7. The computerized method of claim 2, wherein determining, using local communication, that the first and at least second TCDs are both located within the same position envelope, is performed using a combination of: i) comparing time-stamped GPS position and/or speed data passed locally among at least the first and at least second TCDs; and ii) performing known acquaintance validation involving at least the first and second TCDs.

8. The computerized method of claim 2, wherein when a user attempts to register a DTCD, an identity of the user associated with the DTCD is queried in a drivers license database, and if the associated user is not a licensed driver then the registration is disallowed.

9. The computerized method of claim 2, wherein the first and at least second TCDs communicate with the one or more TCSs by way of different cellular carriers and/or different cell towers.

10. The computerized method of claim 2, wherein determining using local communication among the first and at least second TCDs, that the first and at least second TCDs are all located within the same position envelope, is performed using one or more queries with respect to GPS data, wherein: one of the first and at least second TCDs is a registered DTCD; wherein the registered DTCD queries one or more TCDs via the local communication by supplying GPS location and/or speed data associated with the registered DTCD; wherein each of the one or more TCDs responds to indicate whether or not the GPS data associated with the registered DTCD tracks within a pre-set margin with the corresponding GPS data of any of the one or more TCDs; and wherein for any of the one or more TCDs that respond positively, it is assumed that the TCDs responding positively are within the same envelope as the registered DTCD and are therefore determined to be PTCDs and are allowed to text.

11. The computerized method of claim 2, wherein a telematics system is located in the same position envelope where a TCD is located; wherein the telematics system is aware that a vehicle in which the telematics system resides has self-driving capability; and wherein for a time period where the vehicle is in a self-driving mode, the telematics system is considered to be the DTCD for the purpose of enabling texting for TCDs in the position envelope.

12. The computerized method of claim 1, wherein determining, using local communication among the first and at least second TCDs, that the first and at least second TCDs are all located within the position envelope, is performed using known acquaintance validation based on one or more contact data types and/or communication modalities determined to be in common among the first and at least second TCDs.

13. The computerized method of claim 12, wherein the one or more contact data types include: a) cellular contact numbers contained in an internal address book; b) cellular contact numbers contained in a record of recent calls, either sent or received; or c) cellular contact numbers contained in a record of recent texts, either sent or received; and wherein if a specific contact data type associated with one of the first and at least second TCDs is the same as a specific contact data type associated with the other of the first and at least second TCDs, then assuming that the first and at least second TCDs are located within the same position envelope.

14. The computerized method of claim 12, wherein the one or more contact data types include: d) email addresses contained in an internal address book; e) email addresses contained in a record of recent emails, either sent or received; or f) a list of social media contact numbers or user identifiers stored in, or accessible by, either or both of the first and at least second TCDs; and wherein if a specific contact data type associated with one of the first and at least second TCDs is the same as a specific contact data type associated with the other of the first and at least second TCDs, then assuming that the first and at least second TCDs are located within the same position envelope.

15. The computerized method of claim 12, wherein the one or more communication modalities include: g) a URL from which the TCS is contacted by both of the first and at least second TCDs; and wherein if a specific communication modality associated with one of the first and at least second TCDs is the same as a specific communication modality associated with the other of the first and at least second TCDs, then assuming that the first and at least second TCDs are located within the same position envelope.

16. The computerized method of claim 12, wherein determining the velocity of the first TCD is performed remotely from the first TCD by monitoring a strength of a signal transmitted from the first TCD as received at one or more cell towers.

17. The computerized method of claim 12, wherein determining the velocity of the first TCD is performed by determining a velocity parameter within the first TCD, wherein the velocity parameter is transmitted from the first TCD to the TCS.

18. The computerized method of claim 12, wherein neither the DTCD nor any of the PTCDs transmit their GPS coordinates to a TCS.

19. The computerized method of claim 12, wherein determining that the first and second TCDs are in the same position envelope is performed by an app installed in the first and second TCDs, or alternately by a software program integrated with a TCD operating system controlling the first and second TCDs.

20. The computerized method of claim 12, wherein determining, using local communication, that the first and at least second TCDs are both located within the same position envelope, is performed using a combination of: i) performing known acquaintance validation among at least the first and at least second TCDs; and ii) comparing time-stamped GPS position data passed locally among at least the first and at least second TCDs;

21. The computerized method of claim 12, wherein when the first and at least second TCDs contact the TCS from a common URL, it is assumed that the first and at least second TCDs are in contact with a hotspot or telematics system located in the same position envelope where the first and at least second TCDs are both located, and therefore that users of the first and at least second TCDs are therefore known acquaintances.

22. The computerized method of claim 12, wherein a telematics system is located in the same position envelope where a TCD is located; and wherein the telematics system is aware that a vehicle in which the telematics system resides has self-driving capability; and wherein for time periods when the vehicle is in a self-driving mode, the telematics system is considered to be the DTCD for the purpose of enabling texting for TCDs in the position envelope.

23. The computerized method of claim 12, wherein when a user attempts to register a DTCD, an identity of the user associated with the DTCD is queried in a drivers license database, and if the associated user is not a licensed driver then the registration is disallowed.

24. The computerized method of claim 12, wherein the first and at least second TCDs communicate with the one or more TCSs by way of different cellular carriers and/or different cell towers.

25. The computerized method of claim 12, wherein determining using local communication among the first and at least second TCDs, that the first and at least second TCDs are all located within the same position envelope, is performed using known acquaintance validation wherein: one of the first and at least second TCDs is a registered DTCD; wherein the registered DTCD queries one or more TCDs via the local communication by supplying one or more specific contact data types associated with the registered DP; wherein each of the one or more TCDs respond to indicate whether or not the one or more specific contact data types associated with the registered DTCD exist within any of the one or more TCDs; and wherein for any of the one or more TCDs that respond positively, it is assumed that the TCDs responding positively are within the same envelope as the registered DTCD and are therefore determined to be PTCDs and are allowed to text.

26. A Texting Capable Device (TCD) capable of wireless communication while residing within a moving vehicle, comprising: a wireless transceiver capable of local communication with one or more other Texting Capable Devices (TCDs) residing within the same moving vehicle; wherein it is determined, using the local communication among the TCD and the one or more other TCDs, that the TCD and the one or more other TCDs are all located within the same position envelope; wherein the determination is performed using known acquaintance validation based on one or more contact data types and/or communication modalities determined to be in common among the TCD and the one or more other TCDs; and wherein when either the TCD or one of the other TCDs is registered as a DTCD, any of the TCD or the one or more other TCDs that are not registered as the DTCD are allowed to text.

27. A telematics system capable of being incorporated into a vehicle, comprising: a wireless transceiver capable of local communication with one or more texting Capable Devices (TCDs) residing within the same moving vehicle; wherein it is determined, using the local communication among the telematics system and the one or more TCDs, that the telematics system and the one or more TCDs are all located within the same position envelope; and wherein the telematics system is aware that the vehicle in which it is incorporated has self-driving capability, and when that vehicle is in a self-driving mode for one or more periods of time, the telematics system is considered to act as a DTCD (Driver texting Capable Device), and any of the one or more TCDs located within the same position envelope are allowed to text during the one or more periods of time.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0065] FIG. 1 shows both side and top views of a bus including cell phones used by passengers and a driver.

[0066] FIG. 1A shows a side view of the bus of FIG. 1 including passenger cell phones and a registered master phone owned by a professional driver.

[0067] FIG. 1B shows a cell tower as well as a top view of the bus of FIG. 1, including a position envelope encompassing passenger cell phones and the registered master phone owned by the professional driver.

[0068] FIG. 2 shows both side and top views of a car including cell phones used by passengers and a driver.

[0069] FIG. 2a shows a side view of the car of FIG. 2 including cell phones belonging to carpool passengers and a registered master phone owned by the driver.

[0070] FIG. 2b shows a cell tower as well as a top view of the car of FIG. 2 including a position envelope encompassing cell phones belonging to carpool passengers and the registered master phone owned by the driver.

[0071] FIG. 3 shows the validation sequence whereby a service provider will prevent the driver of a vehicle from texting while allowing passengers to text.

[0072] FIG. 4 shows the process of registration of a master phone.

[0073] FIG. 5 shows the process whereby the SP system determines that an un-registered professional operator is traveling within the moving envelope of a group of phones, and the professional operator is prompted to register as a master phone user.

[0074] FIG. 6 shows a train on a railroad bed where passengers are allowed to text on their cell phones and the operator of the train is not.

[0075] FIG. 7 shows multiple cell phones traveling within the same vehicle where each cell phone is serviced by a different service provider.

[0076] FIG. 8 shows an information flow graph for passing parameter data and time markers between service providers to enable the required analysis according to the present invention.

[0077] FIG. 9 shows a method for operation of the FIG. 8 embodiment to determine texting enablement when multiple service providers are involved.

[0078] FIG. 10 shows both side and top views of a car including cell phones used by passengers and a driver.

[0079] FIG. 10A shows a side view of the car of FIG. 10 including cell phones belonging to passengers as well as a cell phone belonging to the driver.

[0080] FIG. 10B shows a top view of the car of FIG. 10 including a cell tower and a position envelope encompassing cell phones belonging to passengers and driver, the envelope being established in order to track and warn drivers of probable texting while driving.

[0081] FIG. 11 shows a table describing some possible and exemplary status conditions for multiple cell phones traveling within the same vehicle, and conditions under which some cell phone users would be warned for probable texting while driving.

[0082] FIG. 12 shows a block diagram including functions at a cellular service provider for implementing a speech-text capability without any modifications or additions required of a user's cell phone.

[0083] FIG. 13 shows a flow chart for operation of the system of FIG. 12.

[0084] FIG. 14 shows a flow chart for operation of the system of FIG. 12, specifically for a phone user sending a text message solely by voice phone call communication with a service provider.

[0085] FIG. 15 shows a car including cell phones used by passengers and a driver, as well as a flow chart for voice control and conversion.

[0086] FIG. 15a shows a side view of the car of FIG. 10 including cell phones belonging to passengers as well as a cell phone belonging to the driver.

[0087] FIG. 15b shows a block diagram including an interface with a cellular service provider as well as functions for implementing a speech-text conversion capability, including validation of software.

[0088] FIG. 16 shows a flow chart for operation of the system of FIG. 15 where speech-text conversion is performed on a user's phone, including functions within a user's phone for validation of software on the phone for control and speech-text conversion.

[0089] FIG. 17 shows a block diagram including functions within a user's phone and within a service provider infrastructure for implementing a speech-text capability, including validation of software on a user's phone.

[0090] FIG. 18 shows a flow chart for operation of the system of FIG. 17 where speech-text conversion is performed at the service provider, including functions within a user's phone for validation of control software on the phone.

[0091] FIG. 19 shows an embodiment of the invention where a vehicle includes a telematics system, and various mobile communication devices (MCDs) including cellular phones and at least a tablet or PC, where the telematics system provides a hotspot to which mobile communication devices are connected.

[0092] FIG. 20 shows an embodiment of the invention where a vehicle includes a telematics system, cellular phones, and at least a tablet or PC, where the telematics system provides a hotspot to which mobile communication devices are connected, and a cell phone—usually the driver's phone—is tethered to the telematics system by wired or wireless connection.

[0093] FIG. 21 shows an embodiment of the invention where a vehicle includes a telematics system, cellular phones, and at least a tablet or PC, where the driver's phone provides a hotspot to which mobile communication devices are connected.

[0094] FIG. 22 shows an embodiment of the invention where a vehicle includes a telematics system, cellular phones, and at least a tablet or PC, where a passenger's phone provides a hotspot to which mobile communication devices are connected.

[0095] FIG. 23 shows non-limiting embodiments where local communication is performed within a vehicle position envelope, and where GPS and or Known Acquaintance data passed locally is analyzed locally to determine which PTCD's are located within the same vehicle envelope as a master/driver phone (DTCD).

[0096] FIG. 24 shows other non-limiting embodiments where local communication is performed among devices within a vehicle position envelope, and where packets are analyzed to determine which PTCD's are located within the same vehicle envelope as a master/driver phone (DTCD) based on a common communication modality.

DETAILED DESCRIPTION OF THE INVENTION

[0097] According to the present invention, it requires a certain minimum velocity of movement of a cell phone to disable texting. This velocity should be greater than what can be achieved jogging or walking. Speeds achievable on a bicycle are probably acceptable to cause text prevention since a person texting on a bicycle at speed is a danger to traffic and himself, and because it is less likely that a person will be texting while riding a bicycle at speed.

[0098] The velocity for setting the disable threshold speed may be a specific level, for instance, 10, 12, or 15 mph. For a person to travel at more than 10 miles per hour he is either running, cycling, skateboarding, or in a motor vehicle. Texting while running at over 10 mph is probably difficult enough to be considered unnecessary. Texting while bicycling or skateboarding at over 10 mph may be considered dangerous.

[0099] Simply disabling texting for cell phones traveling in excess of a disable threshold is not acceptable because it would discourage people from utilizing mass transit and carpools when riding as passengers. Therefore, the present invention focuses on a system and methodology that provides such passengers the ability to text message while traveling at speed. This is accomplished by the service provider's system determining that an individual's cell phone traveling in excess of the disable threshold speed is within the envelope of a registered master phone. While the description provided herein focuses on system and software infrastructure provided by a mobile communications Service Provider (SP), it should be understood that the SP's system may operate in conjunction with systems and software belonging to government agencies to implement the functionalities described herein.

[0100] FIG. 1 shows the cell phones of individuals traveling on a mass transit vehicle, in this case a bus. In the cross-section diagram shown in FIG. 1A, passenger phones 101 are shown in proximity with master phone 102. The top view shown in FIG. 1B again shows passenger phones 101 and master phone 102, now in communication with cellular tower 103. Also shown is position envelope 104 which is established based on the master phone position such that passenger phones 101 are encompassed within the envelope.

[0101] FIG. 2A shows a similar scenario to that of FIG. 1 except that instead of a mass transit vehicle, the vehicle is a conventional passenger car wherein at least one passenger is accompanying the driver to form a carpool. Thus per FIG. 2B, passenger phones 201 are in close proximity to master phone 202 and all phones are in communication with cell tower 203. In a similar manner to FIG. 1, a position envelope 204 is established with respect to master phone 202, that envelope encompassing passenger phones 201.

[0102] The owner of a master phone must have a valid driver's license. To better support the present invention, SPs may require that each phone in a family be assigned to a specific individual if this has not been previously done, so that a child's phone, an elderly person's phone, or any phone that belongs to person without a driver's license cannot be used to spoof a master phone. Government agencies may also correlate across cellular providers to ensure that each individual has only one cell phone assigned and active, again so as to prevent an individual from using one phone to spoof a master while texting on the other. Alternately, if an individual is allowed to have multiple phones assigned to him, the SP system may prevent texting on all such phones if any are moving in excess of a disable threshold speed while not within the envelope of a master phone.

[0103] A professional driver/operator of a public transportation vehicle may also be treated specially. The SP may maintain a database of known professional drivers, or be in communication with organizations that maintain such databases such as mass transit companies and/or government agencies that monitor and/or administrate mass transit operations. An SP may always treat the phone of a professional driver as a potential master phone, and in one embodiment the professional driver may be required to make a “request” to text while moving when he is not acting as an on-duty operator. If he is found to be texting during hours he is scheduled for duty, he may be found to be in violation of the law. Given their liability for an entire vehicle full of passengers, it is proper that professional drivers be given some form of special scrutiny.

[0104] FIG. 3 shows a possible validation sequence for allowing texting on a moving cell phone according to the present invention when that cell phone is within the envelope of a master phone. In step 301, the SP system determines the location and speed of a cell phone and may optionally also determine the direction of travel of the phone. Then, in step 302 the SP system compares the determined speed of the cell phone with a minimum threshold (the disable threshold speed) in order to determine if the phone is moving fast enough to be considered a danger for texting. According to step 303, if the cell phone's speed is greater than the disable threshold, a determination according to step 304 will be made to decide if the cell phone is within the envelope of a master phone. If the speed of the cell phone exceeds the disable threshold and is not within a master phone envelope, then according to step 306 texting will be disabled for that cell phone. If however, the cell phone is within a master phone envelope, then according to step 305 texting will be allowed for that individual's cell phone. If the system determines that according to step 303 the speed of the cell phone is less than the disable threshold, then according to step 307 a determination will be made to decide if the cell phone speed has been less than the disable threshold for a period of time—the “re-enable period”. Only if the cell phone speed has been less than the disable threshold for a period of time equal to the re-enable period, will the user of that cell phone once again be allowed to text.

[0105] When a person's phone stops moving, or drops below the disable threshold for a certain amount of time, it is assumed that the vehicle is no longer moving or is no longer in stop-and-go traffic, and his phone is re-enabled for texting. This re-enable period may be chosen to be sufficiently longer than the longest traffic signal cycle time, or by other means. It may be set by varying the re-enable delay and measuring the results. For instance, if a text message is sent immediately after the re-enable period expires and the length of the message is such that it could not have been composed by a typical user within the re-enable period, that is a clue that the re-enable period may not be long enough. The time delay for the re-enable period provides extra minutes of time to compose a text message after completing a period of driving, rather than trying to compose a message while driving. To ensure that a driver is not simply caught in stop and go traffic whereby a cessation of motion is simply temporary, the re-enable period must be of sufficient length. Regarding the stop and go scenario, were it not for the re-enable period that prevents sending messages after stopping, some drivers addicted to text messaging would compose their messages while moving and send them while stopped during the cyclical pattern of stop and go driving.

[0106] A registration sequence for a master phone according to the present invention is shown in FIG. 4. Here, in step 401 the user of a master phone registers by a communication with the SP. This communication may take a number of forms such as for example a text message, calling a registration phone number, or an Internet link. It is important that the act of registration does not distract the driver any more than necessary. Therefore it would be useful for a driver who frequently registers to assign the registration phone number to a speed dial number, or to create a standard text message that can be sent with the press of a single key, preferably to a special destination set up by the SP and reserved for this purpose that is enabled for texting even when a phone is traveling faster than the disable threshold. Also, the SP may create a short number sequence that when dialed automatically registers a phone as a master phone. In step 402 the SP system logs the master phone user as the current active user of a master phone. Then, in step 403 and 404, the SP system will disable texting for the master phone user as long as he is still registered. When he is no longer registered according to step 404, he may be allowed to resume text messaging per step 405 as long as a re-enable time period has passed.

[0107] Alternately, it is possible to install a cell phone or equivalent functionality in a mass transit vehicle to act as a form of permanent master phone. This is one solution to the problem that occurs when the operator forgets to register as a master phone, thus leaving his passengers without the ability to text. However, this still leaves the problem that the operator's personal cell phone must be disabled while moving. Assuming that the service provider is made aware of the cell phones of all professional mass transit drivers, these phones can be disabled when moving. Unfortunately, that prevents a professional driver from texting when traveling on mass transit as a passenger. Thus, the best overall solution may be for the actual operator of a mass transit vehicle to be required to register his phone as a master phone, thereby allowing a different professional driver to text on a mass transit vehicle when off duty and riding as a passenger.

[0108] De-registration of a master phone may occur in a number of ways. The driver may be offered the following choices for example: [0109] 1) auto-deregistration (x minutes of slow or stopped motion, equal to or longer than the re-enable period). [0110] 2) manual deregistration—stay registered until operator deregisters. [0111] 3) registration for a fixed time (one shift for a professional driver).

[0112] Note that having multiple active master phones on a vehicle could enable the driver to de-register and text. People who drive in carpools as registered master phone user and then park and get on public transport can compound this problem if their phones don't de-register automatically. Thus, it may be preferred to have automatic de-registration after the re-enable period has transpired. Still, the following sequence of events demonstrates one scenario that could arise even with automatic de-registration after a re-enable period: [0113] 1. The cell phone of a non-professional driver is currently registered as a master phone; [0114] 2. For a period of time less than the re-enable period, the speed of his phone has been less than the disable threshold; and [0115] 3. His phone is then determined to be within the envelope of a master phone registered to a professional driver of a mass transit vehicle.

[0116] Upon detecting this situation, the cell phone of the nonprofessional driver can be automatically de-registered to avoid the situation where two master phones are present on the mass transit vehicle. Regardless, it may be beneficial for the SP system to determine if multiple master phones are active on the same mass transit vehicle and take steps to remedy the situation. A general way to handle this scenario is that if registered master phones of a non-professional driver and a professional driver are within the same envelope, the phone of the non-professional driver is automatically de-registered and allowed to text at speed.

[0117] For several embodiments of the present invention, a mass transit driver must register his phone in order for his passenger's phones to text. If he forgets to register, his passengers will be annoyed when attempting to text. In order to avoid unhappy passengers, a driver can also be known to the SP system as a professional driver, and then when his phone is in the presence of a group of people with the same position and speed as the professional driver, the professional driver can be prompted to register. Essentially, a group of cell phone users riding as passengers may form their own envelope and a professional driver whose phone is also in that envelope may be prompted to register in order to enable the passengers to text. This registration could also be done automatically, but that could disable the driver in some scenarios when he is on a bus as a passenger. An example process for prompting a professional driver to register his phone as a master phone is shown in FIG. 5. In step 501, the SP system determines that a professional driver whose cell phone is currently not registered as a master phone is traveling within the envelope of a group of cell phones. In step 502 the system then prompts the professional driver to register his phone as a master phone. In the interest of safety, this prompt should occur in a manner with minimal distraction of the professional driver in case he should currently be operating the vehicle. In step 503 a determination is made by the professional driver as to whether he is the operator of the vehicle or a passenger. If he is a passenger, his phone will be enabled for texting according to step 504. If however, he is the operator of the vehicle, he would register his cell phone according to step 505 as a master phone, and would be logged at the SP system as a master phone user and the active operator of the vehicle. Subsequently, in step 507 the SP system will disable texting for the professional driver. In step 508 upon deregistration of the professional driver's phone to be no longer a master phone, he would be allowed to text according to step 509 after a re-enable period of time has passed.

[0118] Trains have unique problems as described for FIG. 6. They also have restrictions that simplify these problems. A long train 601 can travel on a railroad bed 602 that curves substantially, so the envelope 603 for a train of any substantial length is unusually shaped and difficult to associate with a passenger's cell phone 604 based simply on following a master phone 605. At the same time, the roadbed is known and each increment of a railroad bed has a very specific GPS location. For (long) trains, it may be better to determine the locations of passengers' cell phones based on roadbed coordinates and deal with the operator of the train by another means—for instance automatic registration of an operator's phone when on a roadbed that causes automatic disablement of texting for his phone. Alternately, a professional operator's phone can remind him when on a roadbed that he should register it as a master phone, and if he is a passenger and not the active operator, he can signal via his phone that he is a passenger and to not remind him further for the duration of the trip. For a professional operator to successfully indicate that he is a passenger, there must be another phone on the same train belonging to the active operator and currently registered as a master phone. For trains, the delay that a train must be below the minimum disabling speed before texting is re-enabled may be different than for cars, trucks, and busses, and is most probably set according to the maximum time that a train is typically stopped at a station. A very short train (cable car, or a light rail) may be treated like a bus or alternately like a train.

[0119] A goal of the present invention is to be as effective as possible in preventing drivers and operators of motor vehicles from texting while in motion. At the same time, another goal of the present invention is to accomplish this with an implementation strategy that can be executed quickly and using existing equipment wherever possible. While the system as described herein may accomplish this goal with a high degree of success, there may still be individuals who attempt to circumvent the system. For instance, a solitary driver may find a way to carry two phones such that one can be registered as a master phone while the other is used for texting. Such an attempt at circumvention can be detected by the SP system for example by: [0120] 1) Determining that a driver frequently has a second phone active in his car and it always comprises the same phone. Working in conjunction with government authorities, the user assigned to each phone may be contacted and validated; [0121] 2) Determining that a driver frequently has a second phone in his car yet rarely uses the carpool lane. Working in conjunction with government authorities, the user assigned to each phone may be contacted and validated; or [0122] 3) Determining that a registered driver frequently has a passenger's phone directly to his left or in front of him, but within the same envelope.

Multiple Service Provider Scenarios

[0123] While it will often occur that all persons traveling in the same vehicle have cell phones serviced by the same service provider such as in the case of a family, it will of course also occur that some people riding in a vehicle will have different service providers from others in the same vehicle. When this occurs, the system heretofore described for the present invention will function properly as long as appropriate communications exist between multiple service providers. To clarify how such communications might operate, consider the multiple service provider scenario of FIG. 7 where three individuals have cell phones 701, 703, and 705, each serviced by a different service provider. Phone 701 is serviced by provider 702, phone 703 by provider 704, and phone 705 by provider 706. In this example, the user of phone 701 has registered that phone is a master phone with provider 702. Each service provider keeps track of any or all of position, velocity, and direction parameters for cell phones it services. When the velocity of a phone such as 703 or 705 exceeds the disable threshold, the associated service provider must determine if that phone is within the envelope 707 of a master phone in order to make the decision to enable or disable texting for that phone. Thus, envelope information for master phones must be made available to all participating service providers. This information may be transferred between service providers directly via communication links such as link 708. Alternately, this information may be transferred from the originating service provider to a third party 710 or central database repository of some kind where the information is then made available to any participating service provider by accessing the central database via communication links such as links 709. The central database could be maintained by a third party co-op organization operated by participating service providers, or by an independent third party. An independent third party could be operated as an independent organization or alternately under the auspices of a government agency—for instance the NHTSA (National Highway Traffic Safety Administration).

[0124] When a first service provider registers a cell phone as a master phone and subsequently tracks and records information parameters concerning the master phone such as position, velocity, and direction of travel, it is also useful to record a specific point in time for each parameter measurement with a time marker or time stamp. When this time marker is supplied along with the corresponding master phone envelope information to a second service provider, the time markers allow the second service provider to synchronize or correlate the behavior of a particular cell phone with that of master phones in its vicinity—making meaningful parameter comparisons for similar points in time. Due to system inaccuracies and delays, as well as the interval spacing for taking parameter measurements for a particular phone, there may not exist time markers that match exactly. However, as long as the time markers match within an acceptable threshold of equality, the validity of the overall methodology is maintained.

[0125] An information flow for passing parameter data and time markers between service providers to enable the required analysis is demonstrated graphically in FIG. 8. Here, a first service provider records master phone envelope information 801 at different points in time that may include for instance position information such as that recorded at time marker 1 (802), time marker 2 (803), and time marker (n) 804. This information is then made available to a second service provider by way of a third-party 805 or directly via communications link 806. Meanwhile, the second service provider has been maintaining information parameters 807 concerning a cell phone it services, and when that cell phone has been observed to travel at a velocity greater than a disable threshold, various parameters for that phone are tracked by the second service provider along with time marker information for each measured parameter. The second service provider might maintain for instance position information at time marker (a) 808, time marker (b) 809, and time market (z) 810. Subsequently, the second service provider might determined that the time value of time marker (b) is within a threshold of equivalence to the time value of time marker 1 for the information 801 supplied by the first service provider for a master phone. With this timing synchronization having been made, the second service provider can then determine if the position of the cell phone is within the position envelope of the master phone at this specific point in time. Other parameter comparisons such as the velocity and direction of travel of the phone in question compared with that of various master phones may be made as appropriate, with an overall determination eventually made by the second service provider to enable or disable texting for the particular cell phone if it is determined to not be in the envelope of a master phone. Because the position accuracy of GPS and other cell phone position location means varies with location and other conditions, it may be important to bring other parameters into the determination—in particular velocity. If the position envelope of a master phone in a particular circumstance is wide enough to encompass drivers of adjacent vehicles, the probability that an adjacent vehicle with have a velocity that precisely tracks that of the master phone is unlikely. Thus, including instantaneous velocity in the determination of the master phone envelope is very useful, and marking such parameter measurements with time-stamps is useful to align the parameters in time.

[0126] Cell phone base stations typically contain GPS receivers that access time information supplied by the atomic clocks in the GPS satellites. This precise time information enables time stamping or marking of events observed at the base station with the degree of accuracy required to accurately perform parameter comparisons for multiple cell phones.

[0127] According to Wikipedia.org:

[0128] “Since the advent of the Global Positioning System, highly precise, yet affordable timing is available from many commercial GPS receivers. Its initial system design expected general timing precision better than 340 nanoseconds using low-grade “coarse mode” and 200 ns in precision mode. A GPS receiver functions by precisely measuring the transit time of signals received from several satellites. These distances combined geometrically with precise orbital information identify the location of the receiver. Precise timing is fundamental to an accurate GPS location. The time from an atomic clock on board each satellite is encoded into the radio signal; the receiver determines how much later it received the signal than it was sent. To do this, a local clock is corrected to the GPS atomic clock time by solving for three dimensions and time based on four or more satellite signals. Improvements in algorithms lead many modern low cost GPS receivers to achieve better than 10 meter accuracy, which implies a timing accuracy of about 30 ns. GPS-based laboratory time references routinely achieve 10 ns precision.”

[0129] When comparing parameter data, or time-stamps associated with parameter data, different values may often be close enough to equal to be considered equal from a practical standpoint without actually being equally when viewed with a higher degree of precision. Thus for the present invention, it may often be required that two parameters be equal within a “threshold of equality”. This essentially means that there is a tolerance on judging the equality of parameter values and that this tolerance may vary depending on the needs of a particular implementation.

[0130] The method for the FIG. 8 embodiment to determine texting enablement when multiple service providers are involved is shown in FIG. 9. Here, the second service provider observes at regular intervals the velocities of it's customer's cell phones and occasionally determines that a particular phone is traveling 901 at a velocity in excess of a disable threshold. The second service provider then records 902 (or continues to record) time-stamped parameters (parameters with time-markers that mark the instance in time of the parameter measurement) such as any or all of position, velocity, and direction of travel. The second service provider then compares 903 parameters for the cell phone with parameters for master phones in the vicinity—some parameters acquired externally such as from the first service provider or a general 3.sup.rd party database, and some registered and tracked by the second service provider itself—according to time-stamps that are equal within a threshold of equality. By lining up these parameter measurements in time, a valid comparison and determination can be made to determine 904 if the phone in question is within the envelope of a master phone. If it is, then the second service provider will allow 905 text messages. If the second service provider determines that the cell phone is not within a master phone envelope, then text messaging will be disabled 906 for that phone until it's velocity has dropped below the disable threshold for a pre-determined period of time.

[0131] For multiple service provider scenarios such as those of FIGS. 8 and 9, each service provider will typically watch multiple registered master phones and thus be considered at times the “first service provider”. At the same time, each service provider will also watch multiple cell phones that are not so registered, thereby functioning at times as the “second service provider” relative to those un-registered phones. When both a master phone and a non-master phone are serviced by the same provider, that service provider may function as both the first and second service providers.

Tracking and Warning of Probable Texting while Driving

[0132] A functionality for tracking texting while driving according to the present invention provides a useful interim solution where drivers exhibiting a high probability of texting while driving are warned of this condition. This embodiment for tracking and warning serves both as a deterrent and also prepares cell phone users for a possible ban where texting is actually disabled according to other embodiments of the present invention. As with the apparatus and methods described herein for disabling texting, the embodiment for tracking and warning may be implemented without requiring changes to currently deployed user phones, existing cellular hardware infrastructure, or existing vehicles.

[0133] FIG. 10 shows multiple cell phones traveling within the same vehicle where an envelope is established in order to track and warn drivers of probable texting while driving. In FIG. 10A, passenger phones 1001 and 1002 are riding within the same envelope as is driver's phone 1003. The service provider for each of these phones determines the position, velocity and other parameters for the phone as well as whether the phone is being used for texting. However, since this tracking mechanism is passive, there is no master phone registration as described previously for embodiments focused on disabling texting. If all of the phones in the vehicle are serviced by the same service provider, then that service provider can determine that these phones are within the same envelope 1005, and also which are texting and not texting. If some phones are serviced by a first service provider by way of cell tower 1004 and others are serviced by different service providers, then coordination between service providers is required for this tracking and warning embodiment in a manner similar to that described for FIGS. 7, 8, and 9.

[0134] FIG. 11 shows a table describing some possible and exemplary status conditions for multiple cell phones traveling within the same vehicle envelope, and conditions under which some cell phone users would be warned of probable texting while driving. Columns 1101 and 1102 represent two cell phone users traveling in the same envelope where both are licensed drivers. For this embodiment, a database containing records of driver licensing is queried to determine for each cell phone user whether or not they are a licensed driver. Unlicensed drivers corresponding to columns 1103 and 1104 are assumed it to be not driving. They are allowed to text under any and all conditions, and are therefore not warned of a possible texting while driving condition. Licensed drivers are scrutinized and may be warned of probable texting while driving under certain conditions. According to action column 1105 in FIG. 11, if only one licensed driver has an active phone and that phone is used for texting while moving, that driver will be warned of the possible violation. If two licensed drivers within the envelope have their phones active and one is texting, it is indeterminate as to whether the individual texting is driving, and no warning is given. It is assumed for this scenario that because texting while driving is against the law that the passenger in the vehicle is far more likely to be the person texting. If two or more cell phones within the envelope are all active and all are being used for texting, it is assumed that the driver of the vehicle is texting and a warning is issued. For this scenario, it is not required that all phones be texting simultaneously, only that all have texted during the transit time for the vehicle. To minimize the possibility of distracting a driver, warnings are typically given after the fact through either email or regular mail or a message (text or automated voice) to their phone that is sent at a time when it is determined that the person is no longer in a moving vehicle. As mentioned earlier, if two or more cell phone users within the same envelope are serviced by more than one service provider, then coordination between service providers is required for this tracking and warning embodiment in a manner similar to that described for FIGS. 7, 8, and 9.

Speech-to-Text and Text-to-Speech

[0135] The presence of a conventional Speech-to-Text and Text-to-Speech function on a cell phone doesn't necessarily prevent the user from viewing texts on the phone's display or from creating a text manually. A solution that seeks to disable conventional texting for drivers must take this into account. To be comprehensive, for phones identified to belong to a current driver of a vehicle, a solution must require that all interaction between a user and their phone is performed via bi-directional voice communication, and that a user is never allowed to enter a text manually or view a text optically while driving. According to the invention, a phone user who wishes to use speech-text capability while driving would typically indicate this preference in advance. They could also indicate this desire once determined to be driving, preferably by a single button operation such as for instance a speed dial. As part of inventions described herein, a service provider may determine that a particular phone is likely to be in use by a driver of a vehicle. This can be performed by methods described herein for envelope determination and tracking, and can also be performed by other methods known in the art. That a particular phone is used by a driver and not a passenger in a moving vehicle can be accomplished by the voluntary registration method described herein, or by other methods known in the art. Once a particular phone has been determined to be in use by a driver of a vehicle, conventional texting for that phone is disabled by the service provider, and if desired by the individual and allowed by local laws, a speech-text capability may be activated and utilized.

[0136] If it is paramount to ensure that users can never circumvent speech-text capability while driving, the best solution is to have all speech-text functions performed at the service provider, requiring users to communicate solely by voice when dealing with text capability while driving. A representative and non-limiting infrastructure at a service provider 1202 for performing such functions is shown in FIG. 12. In general, a cellular service provider infrastructure may consist of any or all of central offices, base stations, cell towers, various backhauls and communication links, and the Internet, to name a few components. A user's phone 1201 interfaces with a conventional cellular service provider infrastructure 1202 via a wireless communication interface 1203 which in turn communicates with a software platform 1204 at the service provider. Functions shown in FIG. 12 as being performed at a cellular service provider may be performed at any location in the servicer provider's infrastructure. In the scenario of FIG. 12, a speech-to-text capability 1206 is performed at the service provider under control of voice command interpretation and process control functionality 1205. Since users accustomed to dealing with textual representations of their messages may wish to obtain text copies of voice conversions once their driving is complete, a message caching capability 1207 may also be included.

[0137] FIG. 13 describes a process whereby speech-text conversion is performed at a service provider and all control of the process from a user's perspective is performed by way of bidirectional voice communication with the service provider. This includes menus provided by the service provider and commands issued by a user while determined to be driving. In step 1301, a service provider determines that a phone belongs to the driver of a vehicle. In step 1302, the service provider determines that the driver's phone is traveling in excess of a disable threshold, and if so, conventional text messaging for the phone is disabled. As described earlier herein, different criteria may be utilized to determine when conventional texting may be re-enabled, including that the phone has been traveling at a speed or velocity less than the disable threshold for a predetermined amount of time. In step 1303 it is determined that a user of the phone, already determined to be a driver, has chosen speech-text conversion when determined to be driving. In some embodiments this step may be optional. In step 1304 incoming texts intended for the driver's phone are converted at the service provider and sent as voice messages to the driver's phone. Such messages having a voice format yet conveying text information are hereinafter described as “text-voice” messages. Text-voice messages may be transferred by any means that include voice communication, including but not limited to any of: conventional phone calls; voice Instant Messages; or voicemail. In step 1305 text-voice messages from the driver's phone are converted to conventional text format and forwarded to one or more recipients. As mentioned with regard to FIG. 12, incoming and outgoing texts may be cached at the service provider in their conventional text message format, and forwarded to the driver's phone when it is determined by the service provider that the phone is no longer in a moving vehicle and conventional texting is restored. Such caching and forwarding functionality may be optional according to the stated preference of an individual phone user. Also, when a message is thus saved and later forwarded to a user's phone, it can be marked to the effect of having been “already sent” or “already received” so the user can keep track of those messages without confusion.

[0138] FIG. 14 shows a more detailed process description of how a driver would communicate via voice with a service provider in order to send and receive text-voice messages while determined to be driving. In step 1401 a driver places a conventional voice call to a service provider to initiate the process of sending or receiving text voice messages. In one embodiment this can be a speed dial number which a user can call with a single button push, with a call to this special number being allowed while driving. In step 1402 the service provider answers the call with a voice command interpretation functionality—typically including a menu capability with voice recognition—and proceeds to interact with the driver according to a process control function capability at the service provider. As part of this step a user may listen to messages converted from text, or dictate 1403 a message that they wish to be converted to a text. In step 1404 the system at the service provider converts a message dictated by the driver to a conventional text message and forwards to one or more recipients. In step 1405 the outgoing text message may be saved at the service provider for later retrieval by the driver after their driving is completed.

[0139] Other embodiments described herein include functions for voice command interpretation and process control of speech-text capability that are resident on a user's phone. In some embodiments the actual speech-text conversion may be performed on the user's phone while in other embodiments this conversion may be performed at the service provider. When the conversion is performed on the user's phone, text will be transferred back and forth between the service provider and the user's phone. When the conversion is performed at the service provider, text message information will be transferred back and forth in the form of a text-voice message. A “text-voice message” is a voice message that contains information originating from, or intended for, a conventional text message. Text-voice messages may be transferred by a conventional phone call, or alternative communication formats between a user's phone and a service provider including a voice Instant Massage (voice IM). A text-voice message may also include header information including source, destination, or other pertinent information. For the various embodiments described herein, a user may optionally choose to have incoming texts queued so that they can be listened to in sequence, thereby eliminating the need to scroll through a list on their phone whereby they would take their eyes off the road. If software or firmware is present on a user's phone to control and/or convert as part of a speech-text capability and that software is modified or hacked, it may be possible for a user to circumvent the speech-text functionality and either enter or view texts in a conventional manner. As such, and according to the present invention, when software or firmware functionality exists on a user's phone to allow speech-text capability while driving, a validation function is also included to ensure that the software or firmware has not been modified, hacked, or circumvented in any way.

[0140] When any of voice command interpretation, process control for speech-text capability, and the actual speech-text conversion, are resident on a user's phone, the software applications that perform these functions should be initially certified and then validated from time to time as described herein. When such an application is added to a smart phone, other communication can be performed between the user's phone and the service provider including sending codes to either enable or disable speech-text related functions.

[0141] FIG. 15 shows a scenario where speech-text conversion is performed on a user's phone. FIG. 15a shows a driver's phone 1501 as well as passenger's phones 1502 and 1503. As described elsewhere herein and as known in the art for alternative solutions, a service provider may determine that phone 1501 should be disabled for conventional texting due to its use by a driver, while conventional texting is allowed for phones 1502 and 1503 belonging to passengers. In FIG. 15b, functionalities 1504 within phone 1501 are shown including operating system 1505 which communicates with and controls functions for voice command interpretation and process control 1507 as well as text-to-speech and speech-to-text conversion 1508, both of which are viewed as subsystem 1506 which is protected against tampering by a validation engine function 1509. Validation engine 1509 may be a separate hardware engine, or alternately a software module which executes on a processor within the phone. If executed on a processor this may be the same processor that executes the phone's operating system 1505 or may be a separate processor. Validation engine 1509 may access software or firmware for functions 1507 and 1508 via O/S 1505, or alternately may access functions 1507 and 1508 directly by means of access path 1510 which may either be a hardware path with separate bus structures or a software path using bus structures shared with other functions. Regardless of the specific implementation, the validation engine must be able to ensure from time to time that no tampering has occurred with either the voice command interpretation and process control function 1507 or speech-text conversion functionality 1508. This validation may include various encryption techniques known in the art or other validation techniques known in the art. From time to time validation functionality in phone 1501 may communicate through wireless communication interface 1511 with cellular service provider 1512 to ensure that all speech-text related functionality in phone 1501 is valid. The process of validation may also utilize communication with a government controlled server 1513 which may supply validation-related software updates or encryption-related updates. Alternately, cellular service provider 1512 may supply such updates. In the embodiment of FIG. 15, since speech-text conversion is performed on the user's phone, text message information being communicated between the user's phone and the service provider would be in a voice format and therefore is considered a text-voice message. Although not shown in FIG. 15, text messages may be cached at the service provider or on the user's phone for later viewing after driving is completed. If cached on the user's phone, these would be encrypted or otherwise hidden from a user while driving so that conventional text viewing is unavailable while driving.

[0142] FIG. 16 shows a process for operation of the functions of FIG. 15. In step 1601 it is determined that a phone belongs to the driver of the vehicle. In step 1602 it is determined that the driver's phone is traveling in excess of a disable threshold, and if so conventional text messaging is disabled for the phone. In step 1603 it is optionally determined that a user of the phone has chosen speech-text conversion when determined to be driving. In step 1604 the speech text control function as well as the conversion software/firmware on the phone are validated to ensure that no tampering or alteration has been performed that might allow circumvention of the speech-text functionality. In step 1605 incoming texts are converted to speech and the driver is allowed to listen to voice information representing a text. Since information transferred between a service provider and a user's phone in the scenario of FIGS. 15 and 16 is still in text format, such information may be encrypted in order to better ensure the integrity of the speech-text functionality. In step 1606 a user dictates information intended for texting, conversion functionality 1508 creates text information from the dictated voice information, while at the same time any textual representations of incoming or outgoing texts are hidden from the user of the phone (the driver) until they are determined to be no longer driving.

[0143] An alternative embodiment is shown in FIG. 17 where voice interpretation command and control is performed on a driver's phone, but actual speech-text conversion is performed at the service provider. Here, text message information being communicated between the user's phone and the service provider are in a text message format which in one exemplary embodiment may be encrypted. The embodiments of FIGS. 15 and 17 may provide some additional element of convenience to a user. However, due to the presence of speech-text related software on the user's phone, additional provisions are required to ensure that users cannot circumvent the intended capabilities and somehow perform conventional text entry or viewing while driving. In FIG. 17 a user's phone 1701 communicates with cellular service provider 1702. Speech-text conversion 1703 is performed at the service provider along with optional message caching 1705 in case a user wishes to view text-voice messages as conventional texts when no longer driving. Conversion 1703 at the service provider is controlled by the service provider software platform 1704 which communicates through a wireless communication interface 1706 with wireless communication interface 1707 on a user's phone 1701. The phone's 0/S 1708 then communicates with a voice command interpretation and process control functionality 1710 which allows the user to operate a speech-text capability while driving. Since function 1710, if altered or tampered with, might allow conventional texting while driving, it is shown closely coupled in module 1709 with validation engine 1711 which as described earlier may perform validation of various software and firmware modules either directly or via the phone O/S 1708.

[0144] FIG. 18 describes a process for operation of the functionality described in FIG. 17. In step 1801 it is determined that a phone belongs to the driver of a vehicle. In step 1802 it is determined that the driver's phone is traveling in excess of a disable threshold, and if so conventional text messaging for the driver's phone is disabled. In step 1803 it is optionally determined that a user of the phone has previously chosen speech-text conversion while driving. In step 1804 the speech-text control function on the phone is validated to ensure it has not been hacked or tampered with in any way. In step 1805 incoming texts are converted to speech at the service provider and sent as text-voice messages to the driver's phone. And in step 1806 text-voice messages from the driver's phone are converted at the service provider to conventional text messages and are forwarded to one or more recipients.

[0145] With respect to FIGS. 19-22 and Tables 1-3, operation of the invention is described in more detail for scenarios where a telematics system is included in the vehicle, and or hotspots are provided by cell phones within a vehicle to provide Internet connectivity.

[0146] All moving GPS-enabled devices (cellular-connected devices) are tracked in manners previously described herein. Those devices in the same envelope are assumed to be in the same vehicle. For passengers in a vehicle to be allowed to text, a master phone must be registered for that vehicle, regardless of how the master phone communicates texts: [0147] a) through itself; [0148] b) through a telematics hot-spot; or [0149] c) through a hotspot of another phone in the vehicle.

[0150] A registered master phone may be allowed to send/receive texts through a strict voice-only protocol, if allowed by the municipality and/or cellular provider. A registered master phone cannot text via a WiFi hotspot in the vehicle. As described earlier herein, once a phone in a vehicle is registered as a master phone, passengers in the vehicle are allowed to send and receive texts.

[0151] An app on smartphones (and non-phone devices such as Tablets and PCs) may be utilized to facilitate the process: [0152] a) The app provides direct control of local cell phone functions in the vehicle, and also enables local processing of at least cell phone position information to offload processing from servers connected to the cellular infrastructure; and [0153] b) The requirement of an app may provide encouragement for proliferation of smartphones which benefits cellular providers, encouraging upgrading to Smartphones for 73 M users with less capable phones. [0154] c) The app may serve to reinforce the privilege given to passengers—being allowed to text while in a moving vehicle; [0155] d) The app may display a message to texting passengers indicating whose phone is registered as a master phone.

[0156] Embodiments described previously herein for blocking texting in moving vehicles as well as tracking and warning of unsafe texting in moving vehicles relate to at least, and without limitation, the scenarios shown in FIGS. 19-22.

[0157] FIG. 19 shows a vehicle 1902 that includes a telematics system 1904 and where one of the cell phones within the vehicle may have been registered as a master phone 1906. Two cellular towers are shown in FIG. 19, tower 1908 operated by a first service provider (SP1) and tower 1914 operated by a second service provider (SP2). A passenger phone 1910 is shown communicating with SP2 and another passenger phone 1912 is also shown communicating with SP2, where the user of cell phone 1912 also has a tablet or PC 1916 which is communicating locally via Wi-Fi hotspot 1918 with telematics system 1904. Passenger phone 1920 communicates with SP1 and also via hotspot 1918 with telematics system 1904. Phone 1906 can also communicate with telematics system 1904. Telematics system 1904 may or may not be GPS enabled, and if enabled is tracked along with cellular phones 1906, 1910, 1912, and 1920 according to the invention to determine that these phones are in close proximity to each other and moving at similar speeds, and therefore all reside within envelope 1922.

[0158] The scenario of FIG. 20 is similar to FIG. 19 except that here a driver's phone 1906, which may also be a master phone, is tethered to telematics system 1904 by wired or wireless local connection 2002. When a wireless connection is used, it may be BlueTooth, WiFi, or some other wireless protocol. How local connection 2002 operates is dependent upon the telematics system provider and to some extent on the type of phone 1906. Tethering phone 1906 via connection 2002 may: [0159] a) render phone 1906 inoperable for texting; [0160] b) may render phone 1906 inoperable for texting but allow texting performed exclusively by voice communication; [0161] c) may render phone 1906 inoperable for connecting to a local Wi-Fi hotspot; [0162] d) may prevent phone 1906 from providing a hotspot within the vehicle; [0163] e) may provide a Wi-Fi hotspot to other phones within the vehicle; or [0164] f) may provide a data connection for telematics system 1904 to support Wi-Fi hotspot connections within the vehicle such as hotspot 2004;

[0165] When tethered to telematics system 1904, phone 1906 may connect to cellular provider 1908 via connection 2006, or alternately may rely in some way on telematics system 1904 in communicating with cellular provider 1908 via connection 2008.

[0166] The scenario of FIG. 21 is similar to FIGS. 19 and 20, except that here driver's phone 1906 provides a hotspot 2102 for some of the passenger phones and mobile communication devices such as tablet or PC 1916. Driver's phone 1906, which may or may not be a master phone, communicates via connection 2104 with provider SP1 via cell tower 1908. Telematics system 1904 communicates independently with cell tower 1908 via connection 2106.

[0167] The scenario of FIG. 22 is similar to FIGS. 19, 20, and 21, except that here a passenger phone 1910 provides hotspot 2202 for phones 1906, 1920, 1912, and tablet or PC 1916. Phone 1910 connects with SP2 cell tower 1914 for both voice and data connections. Driver's phone 1906's communicates with cell tower 1908 via connection 2204, and telematics system 1904 communicates with cell tower 1908 via connection 2206.

[0168] In keeping with the scenarios of FIGS. 19-22, embodiments of the invention prevent texting while driving and utilize: [0169] one or more mobile communication devices used by persons travelling in a vehicle; [0170] one or more cellular service providers supplying cellular infrastructure and services; [0171] a wide area communications network such as the Internet; and [0172] a telematics system optionally installed in the vehicle;
and wherein to prevent texting while driving an exemplary and non-limiting process implementing the invention comprises: [0173] (i) tracking positions of cell phones and GPS-enabled telematics systems in communication with at least a first service provider; [0174] (ii) determining at least a position of each tracked cell phone and GPS-enabled telematics system, utilizing at least a GPS function contained in each of the tracked cell phones and GPS-enabled telematics systems; and [0175] (iii) determining that one or more of the tracked cell phones and GPS-enabled telematics systems are in the same envelope;

[0176] Further, if a cell phone determined to be in the envelope has been registered by its user as a master phone and is determined to be travelling in excess of a specified threshold velocity, the process prevents texting for that master phone wherein texts are communicated by any of the following: [0177] a) via a cellular network of the at least a first service provider; [0178] b) via a telematics system determined to be in the envelope; or [0179] c) via a hotspot of another phone within the envelope;

[0180] Note that the process may optionally allow texting communicated solely by voice for the registered master phone.

[0181] Texting for passengers whose mobile communication devices are determined to be in the envelope is allowed as long as the master phone remains registered. Texting for all mobile communication devices determined to be in the envelope is prevented when it is determined that there is no registered master phone within the envelope, and the velocity of the envelope exceeds the specified threshold velocity. A mobile communication device (MCD) is any mobile electronic device capable of sending/receiving texts, either by direct communication with a service provider, or by local connection which may include wired or wireless connection within the vehicle and communication via a cell phone or a telematics system.

[0182] As previously described with respect to FIGS. 7-9, if any of the tracked cell phones and GPS-enabled telematics systems determined to be in the envelope are determined to communicate via a second cellular provider, then a determination that the tracked cell phones and GPS-enabled telematics systems communicating via the second cellular provider are in the envelope is performed by comparing at least time-stamped position information for each of the tracked cell phones and GPS-enabled telematics systems. In another embodiment, information for velocity and direction of travel are also time stamped and compared between first and second service providers.

[0183] Note that it may be useful to have a software app installed on one or more of the mobile communication devices. This may serve a number of useful purposes. First, the software app can track at least a position of the one or more of the tracked cell phones and GPS-enabled telematics systems, and provide that information via at least a first service provider. Velocity and direction of travel can also be tracked locally by such a software app which offloads processing from the service provider's infrastructure and reduces bandwidth required for GPS tracking. Where devices in a vehicle are in communication with more than one service provider, the provided at least a position is time-stamped by the app to enable a position comparison made when both first and second cellular service providers provide connections to the tracked cell phones and GPS-enabled telematics systems located in the vehicle.

[0184] A local software app installed on phones can support the tracking process and also encourage millions of users to upgrade to Smartphones. Such an app can also be installed on some telematics systems. Requiring a software app to be installed on smartphones should be a benefit and motivation for cellular service providers to implement the Masterphone System, since they frequently encourage users to upgrade to more capable phones. An additional function includes an optional app to enable safe speech-to-text and text-to-speech for use where hands-free voice is legal. (Such a safe speech/text capability has been described herein with respect to FIGS. 12-18.) Cellular providers are always looking for ways to encourage users to upgrade to more capable phones. Survey data from Pew Research Center indicates 90% of American adults have cell phones and 64% have Smartphones, leaving 26% of adults possible to upgrade or 63 M phones. Recent survey data from Growing Wireless indicates that 78% of teenagers 12-17 have a cell phone while only 37% have Smartphones, leaving 41% possible to upgrade or 10 M phones. So, the available number of non-Smartphone users that could be encouraged to upgrade to Smartphones is approximately 73 M at the time of filing of this application.

[0185] To reinforce that the Masterphone system is operating, for passengers within the envelope a name or number associated with the master phone can be displayed on a mobile communications device associated with each passenger.

[0186] In some scenarios, a driver's phone either individually or working in conjunction with a telematics system supplies a WiFi hotspot within the vehicle. For some telematics systems, the cellular connection to support the Wi-Fi hotspot is provided by the driver's cell phone when the cell phone is tethered to the telematics system by either a wired or wireless connection. For some telematics systems, tethering a driver's phone may automatically cause texting capabilities on the phone to be disabled including Internet connectivity. Voice only communication including texting solely by voice may still be enabled and supported for some telematics systems.

[0187] To determine if any mobile communication device within the envelope is texting, packets transmitted by any of the mobile communication devices within the envelope can be optionally analyzed at the service provider or by a 3.sup.rd party server by examining one or more of the following parameters: [0188] a) a Time to Live number; [0189] b) a MAC address; [0190] c) a TCP/IP Stack Fingerprint; or [0191] d) a Destination IP/URL

[0192] Every network packet travelling across a TCP/IP network, like the internet, has a built-in time-to-live (TTL) set on it, so that in case there is a problem with that packet reaching its destination this will stop it travelling around the network forever clogging everything up. The packet starts with a TTL number (say 128) set on it when it leaves the sending device (a phone or laptop), and then every time that packet travels through a router of any kind that router decrements the TTL. Also, mobile communication devices on a TCP/IP network, like the internet, all have a unique MAC ID set on their network interfaces. Further, different computer operating systems (eg Android, iOS, Windows, Mac OSX, Linux, etc) set up their TCP/IP stacks with different default values and settings, like the Initial Packet Size, Initial TTL, Window Size. etc. The combination of these values can give a “fingerprint” that can be used to identify what operating system is running on the originating device. Last, many OSs these days do Captive Portal Detection when they first connect to a WiFi network, such as a WiFi hotspot. They do this by trying to connect to a known web server across the internet, and checking to see if they get the response that they're expecting. If the expected response is not received, then it's likely that the WiFi connection the device is on is a “captive portal” and one may need to log in, or pay, to connect to it. As Microsoft OSs (like Windows) check with a Microsoft server by default and other OSs like Android, MacOS, etc. all connect to their parent company's servers to do these checks, it can be used as a good indication of the operating system just after the initial connection is made.

Tracking and Warning

[0193] The following scenarios describe exemplary operation of the invention with respect to the inclusion of a telematics system within a vehicle, and for some scenarios the inclusion of Wi-Fi hotspots within a vehicle where the hotspot is provided by a cellular phone.

[0194] First, if a GPS-enabled telematics system is seen as moving at a velocity greater than a specified threshold velocity and transferring texts, but there is no licensed driver with a cell phone in the envelope, the invention warns: [0195] a) any phone in the vehicle even if not a licensed driver, or [0196] b) warns via the telematics system, and/or [0197] c) sends a warning to any mobile communication device connected to the telematics system.

[0198] Note that a reasonable assumption is that if someone is old enough to send texts, they are old enough to have a cell phone—and the cell phone is probably on (active) while they are in a vehicle even if they are using a tablet to communicate with a hotspot or are using their phone's data connection to send text messages via social networking.

[0199] In general, the Track & Warn functionality of FIG. 11 is still a reasonable probabilistic approach, even with the addition of telematics. Texting from a tablet or PC must travel via a cell phone or telematics system, and if travelling via a cell phone the transmission can be associated with the owner of the cell phone and it can be determined if they are licensed or not.

[0200] Where texting is detected via a telematics system, the following exists: [0201] a) Texting detected from moving phones->the phones can be associated with drivers licenses. [0202] b) Texting detected from a tablet or PC->the transmission is associated with the envelope, and also associated with the cellular connected device used to transmit/receive data from the Internet.

[0203] While the specific user of a tablet or PC may not be absolutely associated with a cell phone (and hence a DL) under all conditions, the number of non-cell phone devices and the path that texting data follows can be determined by analyzing transmitted packets as described earlier. Further, if the service provider analyzes packets transmitted to/from a hotspot, a unique mobile communications device (tablet, PC, or WiFi-connected phone) can be identified by one or more previously mentioned techniques used either singly or in combination.

TABLE-US-00001 TABLE 1 Tracking with Telematics System Included—analyzing detected phones and telematics Phone #2 Tablet #1 Tablet #2 Phone #1 (DL- (DL- (NoDL- Scenario (DL-phone) phone) phone) phone) Action Comments T101 Not Not Not Not Warn owner of No phones are Detected Detected Detected Detected vehicle listed active so for Telematics driver probably Sys texting via some other MCD or directly via the TM System T102 Detected & Not Not Not Warn owner of One DL-phone NOT texting Detected Detected Detected detected is active, so it via cell texts phone probably is the driver texting T103 Detected & Detected Not Not Do Not warn NOT texting Detected Detected via cell texts T104 Detected & Not Detected Not Do Not warn NOT texting Detected Detected via cell texts T105 Detected & Not Not Detected Do Not warn NOT texting Detected Detected via cell texts

[0204] Table 1 shows an analysis matrix for tracking with a telematics system included where texting has been detected in the telematics connection (from a Telematics hotspot) & the envelope is moving at a velocity above a specified threshold. For scenario T101, no cell phone is detected within the envelope and therefore a warning is issued via the telematics system since it is most probable that texting is occurring via a telematics-provided hotspot. For scenario T102, a detected phone is texting but not via cellular texts, therefore it must be texting via a Telematics hotspot, and since that phone is determined to have an owner with a drivers license (a DL-phone), that owner is warned. Warnings may be issued by any means previously described with respect to FIG. 11. For scenarios T103, T104, and T105, multiple DL-phones are detected in the envelope with one detected phone not texting on each scenario, and so no warning is provided since it is probable that the DL-phone that is not texting belongs to the driver.

TABLE-US-00002 TABLE 2 Tracking with Telematics System Included—analyzing all packets communicated from envelope Phone #1 Phone #2 Tablet #1 Tablet #2 (DL- (DL- (DL- (NoDL- Scenario phone) phone) phone) phone) Action Comments T201 Not Not Not Not Warn owner of No phones are Detected Detected Detected Detected vehicle listed active so for Telematics driver probably Sys texting via some other MCD or directly via the TM System T202 Detected & Not Not Not Warn owner of texting via Detected Detected Detected detected telematics phone T203 Detected & Detected & Not Not Do Not warn NOT texting via Detected Detected texting via telematics telematics T204 Detected & Detected & Detected & Detected & Warn owners Number of texting via texting via texting via texting via of phones #1, active phones telematics telematics Telematics telematics #2, and 3 match number of texting streams, so warn active phones except non-DL pone. T205 Detected & Not Detected & Detected & Do Not warn NOT Detected texting via texting via texting via Telematics telematics telematics T206 Not Not Detected & Detected & Warn owner of Only one DL Detected Detected texting via texting via detected (DL- phone is active Telematics telematics phone) and texting, so it is probably the driver

[0205] Table 2 describes texting detected in a Telematics connection (from a Telematics hotspot) while the envelope is determined to be moving, and where packets communicated for texting from all mobile communication devices (MCDs) are analyzed. For scenario 201, no phones in a moving envelope are detected as active from a cellular standpoint, and therefore some MCD must be texting via the Telematics hotspot. Therefore, the owner of the vehicle is warned since the telematics system is associated with the vehicle. For scenario T202, DL-phone #1 is detected as texting via telematics system while no other phones are detected in the moving envelope. Therefore, the owner of the detected phone is warned. For scenario T203, two DL-phones are detected where one is not texting and is therefore assumed to be a driver's phone. Therefore, for scenario T203 no one in the envelope is warned. For scenario T204 all detected phones are texting via the telematics system and therefore all DL-phones are warned. For scenario 205 all but one detected phone is texting, and therefore the detected DL-phone which is not texting is assumed to be the driver and no warning is issued. For scenario T206, one detected DL-phone is texting and one detected non-DL phone is texting, resulting in a warning being issued since the DL phone is assumed to be probably the driver.

TABLE-US-00003 TABLE 3 Tracking with phone-based hotspot - either direct or via telematics Phone #2 Tablet #1 Tablet Phone #1 (DL- (DL- #2 Scenario (DL-phone) phone) phone) (NoDL) Action Comments T301 Texting Not Not Not Warn owner One detected detected via Detected Detected Detected of phone #1 phone is probably phone #1 driver HotSpot T302 Texting Detected Detected Not Warn owners Three DL-phones detected via & Texting & Texting Detected of all are active and phone #1 via via detected DL three devices are HotSpot HotSpot HotSpot phones texting, so driver is probably texting T303 Texting Detected Not Not Do Not warn At least one DL- detected via &NOT Detected Detected phone that is not phone #1 Texting texting could be HotSpot the driver T304 Texting Not Detected Not Do Not warn At least one DL- detected via Detected & NOT Detected phone that is not phone #1 Texting texting could be HotSpot the driver T305 Texting Not Not Detected Do Not warn Texting could be detected via Detected Detected Texting from non-DL phone #1 phone owner HotSpot T306 Texting Not Not Detected Warn owner Only one DL- detected via Detected Detected &NOT of phone #1 phone is detected phone #1 Texting and no other HotSpot device is texting

[0206] Table 3 describes texting detected for a cell phone provided hotspot, in this example Phone #1, and where the envelope is determined to be moving. Note that for all scenarios listed in table 3 phone #1 shows texting detected via phone #1's hotspot. For scenario T301, texting is not detected from any other MCD and therefore the owner of phone #1 is warned. For scenario T302 texting is detected for all other DL-phones in the envelope, and therefore the driver is probably texting. Since the phone used by the driver is not specifically known, owners of all three DL-phones are warned. For scenarios T303, T304, and T305, at least one DL phone that is detected is not texting. This could be the driver, so no warning is issued. For scenario T306, texting is detected via the phone #1 hotspot, and tablet #2 is detected and may correspond to a cell phone owned by a person with no drivers license (NoDL-phone). Since tablet #2 is not texting, it is likely that only one DL phone is texting and is probably the driver. Hence, the owner of phone #1 is warned.

[0207] Therefore, to summarize some of the exemplary embodiments for tracking and warning of texting while driving, that process utilizes: [0208] one or more mobile communication devices used by persons travelling in a vehicle; [0209] one or more cellular service providers supplying cellular infrastructure and services; [0210] a wide area communications network such as the Internet; and [0211] a telematics system optionally installed in the vehicle;

[0212] At least positions of cell phones and GPS-enabled telematics systems in communication with at least a first service provider are tracked, and at least a position of each tracked cell phone and GPS-enabled telematics system is determined utilizing at least a GPS function contained in each of the tracked cell phones and GPS-enabled telematics systems. Velocities and directions of travel may also be tracked. It is then determined if one or more of the tracked cell phones and a GPS-enabled telematics system are in an envelope, and that the tracked cell phones and GPS-enabled telematics system are travelling at a velocity in excess of a specified threshold velocity. Then, for all cell phones thus determined according to at least their position information to be within the envelope, a database to is accessed to determine which cell phones in the envelope belong to licensed drivers and which do not.

[0213] Communications between the at least a first service provider and the cell phones and GPS-enabled telematics system within the envelope are analyzed determined to determine whether any mobile communication device contained within the envelope is texting. Based on this analysis, a vehicle occupant is warned of probable unsafe texting under the following conditions:

[0214] (i) the vehicle occupant is determined to be a licensed driver; and

[0215] (ii) the vehicle occupant's mobile communication device is determined to be within the envelope; and

[0216] (iii) an activity for the vehicle occupant's mobile communication device falls into one of the following categories: [0217] (a) the vehicle occupant's mobile communication device is determined to be the only device within the envelope that is texting; [0218] (b) the vehicle occupant's mobile communication device is determined to be texting, and any other mobile communication devices in the envelope that are determined to be texting belong to users with no drivers license; and [0219] (c) the vehicle occupant's mobile communication device is determined to be texting and the mobile communication devices of all other licensed drivers within the envelope are determined to be texting.

[0220] If any of the cell phones and GPS-enabled telematics systems determined to be in the envelope are determined to also communicate via a second cellular provider, then it is determined that the cell phones and GPS-enabled telematics systems are in the envelope by comparing at least time-stamped position information for each of the cell phones and GPS-enabled telematics systems, where the data compared is obtained via both the first and second cellular service providers.

[0221] Note that if no cell phones are detected within the envelope and texting is detected communicated with at least a first service provider from the telematics system within the vehicle, then a database is accessed to determine the registered owner of the vehicle and the registered owner is warned of probable unsafe texting. Note also that it is assumed that any user of a mobile communication device probably has a cell phone, and that if they are in the envelope their cell phone is probably active while their mobile communication device is in use.

[0222] If advantageous, a software app may be included on one or more of the mobile communication devices where the software app tracks at least a position of the one or more of the tracked cell phones and GPS-enabled telematics systems, and provides the at least a position via the at least a first service provider. When both a first and second cellular service provider provide connections to the tracked cell phones and GPS-enabled telematics systems located in the envelope, the provided at least a position is time-stamped by the software app to enable accurate position comparisons made between devices tracked by both service providers.

[0223] If texting is detected from within the envelope and no active cell phones are detected within that envelope, a warning message is displayed on at least a mobile communication device located within the envelope or alternately sent to the owner of the vehicle containing the telematics system.

[0224] Where it is useful to analyze transmitters packets to determine if any mobile communication device within an envelope is texting, packets transmitted by any of the mobile communication devices within the envelope are analyzed by examining one or more of the following parameters: [0225] a) a Time to Live number; [0226] b) a MAC address; [0227] c) a TCP/IP Stack Fingerprint; or [0228] d) a Destination IP/URL

[0229] For another embodiment of the invention where a cell phone hotspot is utilized for texting by one or more MCDs within a vehicle, the process for tracking and warning of texting while driving utilizes: [0230] one or more mobile communication devices used by persons travelling in a vehicle; [0231] one or more cellular service providers supplying cellular infrastructure and services; and [0232] a wide area communications network such as the Internet;

[0233] The process for tracking and warning then operates by tracking at least positions of cell phones in communication with at least a first service provider, and determining at least a position of each tracked cell phone, utilizing at least a GPS function contained in each of the tracked cell phones. Further, the process determines that one or more of the tracked cell phones are in an envelope, and for all cell phones thus determined to be within the envelope, a database is accessed to determine which cell phones in the envelope belong to licensed drivers and which do not.

[0234] Then, communications between the at least a first service provider and the cell phones are analyzed to determine whether any mobile communication device contained within the envelope is texting, followed by warning a vehicle occupant of probable unsafe texting under the following conditions:

[0235] (i) the vehicle occupant is determined to be a licensed driver; and

[0236] (ii) the vehicle occupant's mobile communication device is determined to be within the envelope; and

[0237] (iii) an activity for the vehicle occupant's mobile communication device falls into one of the following categories: [0238] (a) the vehicle occupant's mobile communication device is determined to be the only device within the envelope that is texting; [0239] (b) the vehicle occupant's mobile communication device is determined to be texting, and any other mobile communication devices in the envelope that are determined to be texting belong to users with no drivers license; and [0240] (c) the vehicle occupant's mobile communication device is determined to be texting and the mobile communication devices of all other licensed drivers within the envelope are determined to be texting.

[0241] If any of the tracked cell phones determined to be in the envelope are determined to communicate via a second cellular provider, then it is further determined that the cell phones are in the envelope by comparing at least time-stamped position information for each of the cell phones. Velocity and direction of travel parameters can also be time-stamped and compared. To determine that a mobile communication device contained within the envelope is texting, the analysis may additionally determine that the mobile communication device is texting via a hotspot of a cell phone within the envelope.

[0242] To determine if any mobile communication device within the envelope is texting, including texting via a hotspot of a cell phone within the envelope, packets transmitted by any of the mobile communication devices within the envelope may be analyzed by examining one or more of the following parameters: [0243] a) a Time to Live number; [0244] b) a MAC address; [0245] c) a TCP/IP Stack Fingerprint; or [0246] d) a Source or Destination IP/URL
Validation Via Local Analysis of GPS Data and/or Known Acquaintance Data

[0247] Certain embodiments described in applicant's earlier patents on this topic have been focused on GPS locations, where time stamped GPS location parameters are compared to determine the proximity of two or more cell phones with respect to a position envelope. Further for some (but not all) of those embodiments, those GPS location parameters are sometimes sent via cellular carriers to a server where those location comparisons are performed. For those specific embodiments where GPS data is sent to a server via the cellular infrastructure, it may be that for certain municipalities, areas, or districts, a concern may arise with respect to the privacy of the cell phone users. It is therefore useful to instead determine the proximity of two or more cell phones with respect to a position envelope without passing a phone user's location data, personal data, or contact data beyond the immediate vicinity of the position envelope encompassing the vehicle in which they are a driver or passenger.

[0248] Accordingly for additional embodiments described herein, the GPS position and/or speed of Texting-Capable Devices (TCDs) are compared via local wireless communication (for example and without limitation WiFi, Bluetooth, etc.) with those of other TCDs in the vicinity. Such local communication may be direct between two TCDs using WiFi or Bluetooth, or alternately may be indirect via a local hotspot. Such a hotspot may be implemented in a TCD, or alternately in an on-board access point or telematics system which itself may or may not operate as a TCD. A TCD may include may include for example and without limitation: cell phones, laptop computers, tablet computers, an onboard telematics system, or any device residing in a moving vehicle capable of sending and receiving textual/visual communications. “Textual/Visual” communications, referred to herein as “texting” may include SMS texts, email, or any textual and/or visual communications sent or received by a TCD via any form of social media communications such as, for example and without limitation: Twitter, Facebook (Meta), WhatsApp, Instagram, WeChat, TikTok, etc., as well as any online games, where the visual nature of the communications could be a distraction to a driver. In fact, web-browsing in general typically involves entering textual data for URLs and search terms, and visual interpretation of webpages that result—all of which can be distracting to a driver, and thus fall under the definition of “texting” with respect to the invention.

[0249] Where communications are filtered to allow only audible information, or where text-to-voice or voice-to-text technology is incorporated, such communication may be allowed as an exception. Of course, conveying information to a driver for route guidance can also sometimes be considered as an exception, since it also has safety benefits that offset distraction dangers.

[0250] When comparing GPS data via local communication, if the position and/or speed of one TCD track within an established margin with those parameters for one or more neighboring TCDs, it is assumed that those TCDs are in the same vehicle. Further and via local communication, a TCD can query local TCDs to facilitate a comparison of position and/or speed. To accomplish this validation using a query method, it is not necessary that all TCDs in the vicinity locally divulge their GPS position and/or speed data. For example, a TCD registered as a driver (a DTCD) may query other TCD's in the vicinity. The DTCD may divulge its time-stamped GPS-determined position and/or speed data as part of a query to neighboring TCD's, and each TCD thus queried can perform (using a resident safe-texting app) its own comparison. Any TCD whose GPS data tracks within a preset margin with the DTCD is determined to be within the envelope containing the DTCD, and is therefore validated and allowed to perform textual communication. Note that for an alternate embodiment, a TCD that is not a registered DTCD may query other TCDs in the local vicinity in a like manner to the foregoing.

[0251] In addition to comparisons based on GPS-determined data, the determination that a TCD is positioned within an envelope containing a DTCD, may also be facilitated using a method referred to herein as “Known Acquaintance Validation”, wherein a user of a passenger-operated TCD (a PTCD) is a known acquaintance of a TCD user whose TCD is registered as a driver (a DTCD). If so, they are assumed to be in the same vehicle. If one TCD in a vehicle is a registered Driver/Master TCD (a DTCD), then other TCDs in the same envelope/vehicle (PTCDs) are allowed to text.

[0252] Further and via local communication, a TCD can query other local TCDs with respect to their “Known Acquaintance” data. Known Acquaintance data incudes any data that provides an indication that two users know each other, and/or are communicating through a common modality that indicates they are probably in the same vehicle. As such, known acquaintance data may include for example and without limitation: contact data and/or communication modality data.

[0253] Note that contact data types may include for example and without limitation:

a) cellular contact numbers contained in an internal address book;
b) cellular contact numbers contained in a record of recent calls, either sent or received;
c) cellular contact numbers contained in a record of recent texts, either sent or received.
d) email addresses contained in an internal address book;
e) email addresses contained in a record of recent emails, either sent or received;
f) one or more lists of social media contact numbers or user identifiers stored in, or accessible by, either or both of the first and at least second TCDs;

[0254] In addition, communication modalities among TCDs in a local vicinity may include for example and without limitation:

a) a URL from which the TCS is contacted by one or more TCDs in the same envelope/vehicle; or
b) Analysis results related to packets transmitted from TCDs within the envelope with respect to one or more of the following parameters: [0255] i) a Time to Live number; [0256] ii) a MAC address; [0257] iii) a TCP/IP Stack Fingerprint; or [0258] iv) a Source or Destination IP/URL

[0259] Note that a TCS can be any server or computer or processor that is communicated with via a cellular infrastructure servicing an area where a subject vehicle/envelope is positioned, and where that TCS pays a role in deciding whether textual communications are allowed for a TCD positioned within a vehicle/envelope.

[0260] To accomplish local communication in order to determine DTCDs and PTCDs in a vehicle envelope, it is not necessary that all TCDs in the vicinity divulge their Known Acquaintance data, even locally. Instead, a first TCD may query others in the vicinity and provide its information, enabling other local TCDs to make their own comparisons regarding any Known Acquaintance parameters. For example, a TCD registered as a driver (a DTCD) may query other TCD's in the vicinity after establishing local communication links. The DTCD may divulge its contact and/or communication modality data as part of a query to neighboring TCD's, and each neighboring TCD thus queried can perform (using a resident safe-texting app) its own comparisons. Any TCD containing the contact and/or communication modality data supplied by the DTCD is determined to be a “Known Acquaintance” and is therefore considered to be a PTCD within the envelope containing the DTCD, and thus validated is allowed to perform textual communication. Such a validated PTCD may then supply a validation code or certificate to the relevant TCS. Likewise, any TCD containing time-stamped GPS data that matches (within a pre-determined threshold margin) that supplied by a DTCD is determined to be most probably located within the same envelope as the DTCD, and is therefore considered to be a PTCD within the envelope containing the DTCD. Thus validated, the PTCD is allowed to perform textual communication. Such validated PTCDs may then supply a validation code or certificate to the relevant TCS. Or, the registered DTCD may provide a list of authorized PTCDs to the TCS.

[0261] FIG. 23 shows local communication links 2302 between a master/driver phone (DTCD) 1906 and various (PTCDs), including passenger phones (PTCDs) 1920, 1912, and 1910, and tablet or laptop PTCDs 1916, as well as telematics system 1904 which may for some embodiments also act as a PTCD, or sometimes even as a DTCD. When vehicle 1902 possesses self-driving capability, the vehicle's control circuitry represented in FIG. 23 as part of telematics system 1904 may act as a DTCD during time periods where the vehicle is in self-driving mode. During that self-driving time period, for some embodiments a person sitting in a driver seat may in fact be allowed to text temporarily until the vehicle leaves the self-driving mode and the person in the driver seat is back in control. For one embodiment, the registered DTCD queries other devices in the vicinity via local communications to determine by way of local GPS data analysis and/or Known Acquaintance validation whether or not the various PTCDs are within the same location envelope. Note that for an alternate embodiment, a TCD that is not a registered DTCD may query other TCDs in the local vicinity in a like manner to the foregoing.

[0262] In yet a different embodiment, PTCDs 1920, 1916, 1912, 1910, and telematics system 1904 may communicate with a TCS 2304 by way of a hotspot emanating from DTCD 1906, where DTCD 1906 communicates with TCS 2304 by way of an Internet connection via cell tower 1908.

[0263] In yet a different embodiment of the invention, FIG. 24 shows telematics system 1904 acting as a central hotspot for local communication within vehicle 1902. Such local communication can be accomplished by way of Wi-Fi, Bluetooth or any other short range wireless technology. Through packet analysis, the TCS 2304 would understand that all TCDs in the vehicle communicating 2402 by way of telematics system 1904 and cell tower 1908 are communicating via the same URL associated with telematics system 1904, and are therefore most probably located within the same vehicle envelope 1922. Thus, as long as one TCD located within envelope 1922 is registered as a master/driver phone (a DTCD 1906), then other TCDs (PTCDs) within the envelope are allowed to text.

[0264] For all embodiments of the invention, it is important to block texting by a driver when they are not registered as the driver of a vehicle. To do so, there are numerous methods possible. As mentioned earlier in this specification, for some embodiments the GPS location of a user's phone can be examined by a remote server via a cellular provider servicing the particular user. For some municipalities, this may cause concern due to a user's privacy when the user does not wish to be remotely tracked. Instead for an additional embodiment of the invention, the velocity of a first TCD is performed remotely from the first TCD by monitoring a strength of a signal transmitted from the first TCD as received at one or more cell towers. Such a monitoring of velocity is no different from a policeman's radar sensing of a vehicle velocity, or by a police car pacing a vehicle to determine its speed, and is therefore no more a privacy violation than speed checks performed by police on a daily basis.

[0265] Additionally, many cellular phones (TCDs) comprise a software framework internally that tracks both GPS location and speed, and given a mandated requirement that a TCD contain a safe-texting app (if passengers in the same vehicle envelope wish to text), the Safe-Texting app can retrieve the velocity of the TCD at any point in time and transmit the velocity to a Texting Control Server (TCS) such as server 2304 shown in FIGS. 23 and 24. Therefore, whether the velocity of a TCD is determined remotely based on signal strength, or is transmitted from the TCD to a remote TCS, the invention can determine when texting is being performed at a velocity greater than a predetermined threshold and can therefore block texting for that TCD unless that TCD is registered as a DTCD. Further this velocity determination can be performed wherein neither the DTCD nor any of the PTCDs in the position envelope transmit their GPS coordinates to the TCS. Note that such a safe texting app can be installed as a conventional phone app in a TCD, or alternately can comprise a software program integrated with an operating system that controls the TCD.

[0266] Since according to the present invention, a determination that multiple TCD's are located within the same vehicle envelope can be determined by either comparing timestamped GPS locations or examining known acquaintance data and or communication modality, it is therefore possible to use more than one of these methods in combination. Therefore the process of determining, using local communication, that a first and at least a second TCD are both located within the same position envelope, may be performed using a combination of: [0267] i) comparing time-stamped GPS position and/or speed data passed locally among the first and at least second TCDs; and [0268] ii) performing known acquaintance validation and/or communication modality analysis involving at least the first and second TCDs.

[0269] As with any system, there may be times that a user may attempt to bypass the restrictions afforded by the system to suit their own purposes. In the case of a system to block texting while driving, one possible method that could be used to bypass such a safe-texting system would be to register a child's phone as a driver phone (DTCD), thereby allowing the parent to be considered a PTCD that could be used for texting while driving. To avoid such a scenario, when a user attempts to register a DTCD, an identity of the user associated with the DTCD can be queried in a drivers license database, and if the associated user is not a licensed driver then the registration is disallowed.

[0270] Another consideration for safe texting in a moving vehicle relates to vehicles with self-driving capability. Such vehicles will always include some form of telematics system, and the telematics system will typically be aware of whether or not the vehicle is in a self-driving mode at any moment in time. At the time of this filing, many vehicles are available with a part-time self-driving capability, and in the future it is expected that vehicles will be available that are fully autonomous—some of which do not require a driver at any point in time. There is even discussion of some vehicles being sold without a steering wheel at some time in the future. For a fully autonomous vehicle that is always in “self-driving” mode, the vehicle (the telematics system residing vehicle) may be considered a registered driver. For vehicles that may be intermittently, but not always, in a self-driving mode, it may be desirable that for those time periods where the vehicle is in a self-driving mode and in complete control the vehicle, that an individual sitting in the driver seat is allowed to text only for that time period.

[0271] The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the relevant arts. For example, it will be apparent to one skilled in the art that the embodiments described and claimed herein, while directed to preventing texting while driving, may also be used with minor modification to also prevent voice communication while driving. Such minor modifications would include, for instance, a shortening of the re-enable period.

[0272] Also for example, steps preformed in the embodiments of the invention disclosed can be performed in alternate orders, certain steps can be omitted, and additional steps can be added. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims and their equivalents.