1. Field of the Invention
The present invention generally relates to providing a user of a vehicle voice communication with a service provider through a mobile device.
2. Description of Related Art
Recently, there has been a desire for a low-cost, data-only telematics solution. Such a module may have no voice capability, and may only have power and controller area network (CAN) bus connections to the vehicle. The module could likely include a data-capable network access device (NAD) (e.g., CDMA 1× or GSM GPRS/EDGE) and a vehicle bus interface.
This system could have all of the usual telematics capabilities such as stolen vehicle tracking (SVT), door/window control, remote start, diagnostics, etc., but may not directly have voice capabilities. However in this scenario, the system would lack certain voice related features that are currently available from telematics systems, especially in an emergency call environment.
In view of the foregoing, it is apparent that there is a need for a system that provides voice communication to an occupant of a vehicle through a mobile device.
A system and method for providing voice communication to an occupant of a vehicle through a mobile device. The system communicates with a mobile device of an occupant in the vehicle, for example using a telematics controller or network access device. The system receives an identification from the mobile device and transmits a request, as well as, the identification to a service provider. The service provider then initiates a communication to the mobile device based on the request and identification.
Since most cars in the future will have Bluetooth or similar capabilities, most of the voice features (if part of the telematics subscription) could be performed via a Bluetooth-connected phone.
Data-only emergency calls may send typical advanced automatic crash notification (AACN) crash data when the vehicle is in an accident. The telematics service provider (TSP) may already have a list of contact numbers with which to contact the owner/drivers of the vehicle (pre-set by the vehicle owner). The list may include, for example, the owner's cell phone number, owner's home phone number, phone number of an emergency contact, etc. This list could be called, in order, by the TSP if emergency notification is received.
The telematics module may receive information about a mobile device that is connected to the telematics controller or another device within the vehicle, and send this information to the service provider either before, after, or during a service request. The TSP uses this information to guide or change how the telematics service is provided.
In one example, a mobile phone may be connected to the vehicle (Bluetooth, USB, etc.) via the head unit. The telematics controller may store the caller ID information (phone number or other identifier) in the telematics system or immediately send the ID information to the TSP. For example, the MSISDN of the phone may be captured and stored or sent to the TSP. When a crash occurs, as part of a data-only stream, the system could send the ID information along with the crash notification. This enhances safety services, since the TSP knows which number to call first, and what may be implied if that number is no longer available. The connection status at the time of the message of one or more of the mobile phones may also be included. The status may include, for example, if a Bluetooth phone was connected before the crash, but is no longer available after the crash.
In addition, a data-only telematics service can now seamlessly merge full voice and data capabilities in the car (like OnStar), using both the network access device (NAD) and a mobile phone. The user may press the B-call button on the telematics control unit, and the telematics service provider (TSP) may call the correct mobile phone number in response.
Further objects, features and advantages of this invention will become readily apparent to persons skilled in the art after a review of the following description, with reference to the drawings and claims that are appended to and form a part of this specification.
Now referring to
The display 116 and controls 118 may allow a user to provide additional profile information that may be associated with each cellular phone and stored in the database 114 with the identification for each cellular phone. Further, the telematics controller 110 may identify when a new (unknown) cellular phone is identified. When the new cellular phone is first connected with the telematics controller 110, the user may be prompted through the display 116 to enter profile information for the user. As such, each set of profile information may be readily accessed based on the identification information or other keys such as the phone number or user name. In addition, the telematics controller 110 may be configured to periodically identify mobile devices such as cellular phones within communication range of the transceiver 111. Further, the telematics controller 110 may store the list of mobile devices 112 within communication with the transceiver 111.
In the same or other implementations, the network access device 120 may include a transceiver 121 that communicates with a mobile device 112 as denoted by line 124. The network access device 120 may operate the transceiver 121 in a similar fashion to the transceiver 111. Some implementations may use a separate transmitter and receiver instead of transceiver 111. In such implementations, the network access device 120 will communicate with the telematics controller 110 to notify the telematics controller when a new mobile device has been identified allowing the telematics controller 110 to prompt the user for the profile information as previously discussed.
In one implementation the communication links 122 and/or 124 may be a Bluetooth communication link. When connected via Bluetooth, a mobile device may support the standard Bluetooth Hands Free Profile (HFP), then the vehicle could use the standard command “AT+CNUM”, which is part of the HFP specification, to learn the phone number of the mobile device. This technique may be used to support the scenario in which the vehicle has Bluetooth and the mobile phone is paired with the vehicle. The vehicle also then knows the Bluetooth Device Address associated with the mobile phone, and the Bluetooth Name of the mobile phone. This information can be stored by the vehicle, so that the next time the phone is nearby, the vehicle can detect it and remember the phone number, even without fully establishing a connection.
For the multiple phone scenarios, where the phones are detectable via Bluetooth, the vehicle would need to be paired with the other phones at some point in advance. This way, the vehicle can store the various Bluetooth Device Addresses and associated Bluetooth Names, as well as, the corresponding phone numbers. The vehicle could then use the identifiers to either send the full list of local Bluetooth phones to the TSP, or just a single Bluetooth phone based on priority list. Since the vehicle was previously paired to these mobile devices, it can detect the local Bluetooth Names without fully connecting to those devices.
If the vehicle does not have a connection to the phone, such as over Bluetooth, then the consumer could manually enter the mobile phone number (or calling tree). This could be done in the vehicle through the user interface, or on the TSP servers via web page or other access. Although the vehicle could not detect which phone(s) are present in the vehicle, this would still allow for voice-based telematics services, for example, when using the data-only embedded telematics module in the vehicle.
The following optional approaches can be implemented as well. Potential types and categories of numbers may be configured. A primary voice number may be defined for TSP to call when a telematics service is triggered. If more than one number is provided, the user could define a prioritized list. Prioritization may also be possible by specific day, time, location, or other criteria (e.g., if Monday-Friday, Phone 1 is prioritized; else Phone 2).
The user may also define prioritized phone numbers for other categories such as notification number(s) to call in case of breakdowns, emergencies, etc., as well as, service provider numbers (e.g. vehicle service centers, preferred hospitals, etc.).
Manual entry of mobile phone number(s) may also occur outside of the vehicle. This could be done remotely by the consumer (such as via web page), and sent/stored on either TSP servers or stored by the vehicle. In all cases, there may be multiple numbers entered into the categories above.
Manual entry of mobile phone number(s) may also occur in the vehicle through a user interface. This could be done once, with the vehicle storing the numbers for later use. Further, phone numbers could also be stored on a temporary basis such as use with a rental car, or for a single trip.
The system may automatically detect the primary phone in the vehicle. The primary phone detection may be based on Bluetooth Pairing that was previously done between the vehicle and mobile phone. When vehicle is started, based on priority order, if more than one phone had been paired previously, and which phones are detected, the vehicle can identify the primary voice number. This number can either be sent to the TSP when a telematics service is requested, or sent some time in advance and stored by the TSP.
The system may automatically detect multiple phones in the vehicle. The system may detect each phone in the vehicle base on Bluetooth Pairing that was previously done between the vehicle and mobile phones. When the vehicle is started, vehicle can identify the primary voice number based on a priority order, whether more than one phone had been previously paired, and which phones are detected. Other previously paired phones can be detected, and used to adjust the call lists. For example, if the emergency notification phone is also in the car, the system could select a different phone which is not in the car. The number of the phones can either be sent to the TSP when a telematics service is requested, or sent some time in advance and stored by the TSP.
It should also be understood that the user may enter the preferred mobile calling list (and any associated information) directly onto the TSP servers via web browser or other method. Further, the TSP could use a combination of data sent by the telematics controller and data stored by the TSP. For example, the vehicle may send information about detected mobile phones, which the TSP then uses to compare against the information (number categories, mobile numbers, and any associated information and preferences) that are already stored in the TSP server database. The TSP could then use the information to determine which phone number to call. In one example, the TSP would probably not call a mobile number in the car for a vehicle theft notification; rather, the TSP would likely call a number that is not currently in the car.
The presence of Bluetooth mobile phones may be detected once or multiple times during a drive. If the phones are detected only once, it could be when the car starts, when the vehicle begins moving, or when a telematics service is triggered. If done multiple times, the car could check to see if there is any change to the available devices and adjust the strategy if changes are detected. This is useful if two phones are detected when the car is started, but one person was standing outside the car. When the car drives away, only one phone may then be detected.
The system may also manage phone lists and categories. The preferences and data could be stored and managed on the vehicle. For example, when a telematics service is triggered, the vehicle would send the relevant phone data to the TSP. The preferences and data could also be stored and managed on a server, such as a server controlled by the TSP. For example, the telematics controller could send info about detected phones to the TSP, which then modifies the calling tree accordingly. The telematics controller then does not need to send this information to the TSP when a telematics service is triggered. If there is a collision, and if the detected phones change, then the telematics controller could send the updated information to the TSP.
As such, the telematics controller 110 or the network access device 120 may periodically determine which mobile devices 112 are located within the vehicle and store such information periodically for use in an emergency situation. The network access device 120 may be in communication with a service provider 130, as denoted by line 126. The network communication 126 between the network access device 120 and the service provider 130 is discussed in detail with regard to
Now referring to
Now referring to
The transceiver 318 in the network access device 310 may be used for transmitting uplink communications and receiving downlink communication to and from the network 330 and service center 332 over the wireless communication link 326. The wireless communication link 326 may use a wireless protocol such as a standard cellular network protocol such as Advanced Mobile Phone Service (AMPS), Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), and the like. To transmit data in the cellular environment, different types of standard bearer services exist including, but not limited to, general packet radio service (GPRS), short message service (SMS), circuit switched data service (CSD), and high-speed circuit switched data service (HSCSD). Further, standard transmission control protocol/internet protocol (TCP/IP) may also be used as well as satellite communications. In a further example, the transceiver 318 may be enabled using other wireless technologies such as Bluetooth technology. Bluetooth technology allows for the replacement of a wired connection by enabling devices to communicate with each other through a universal short-range radio link.
The radio tower 328 may be in communication with a service provider 332 including for example, a network server through a network 330. Network 330 may be an analog network such as a plain old telephone service (POTS) or a digital network for example, Ethernet over transmission control protocol/internet protocol (TCP/IP). In other examples, the network 330 could be one of several standard cellular communication networks, a satellite-based network, a public switched telecommunication network (PSTN), the Internet, an integrated services digital network (ISDN), and/or other communication networks. The service provider may include a service center to provide telematics applications and services to the vehicle. For instance, the service center may contain operators, content servers and content databases. The content servers for telematics applications and services may include traffic servers, map servers, user profile servers, location information servers, and the like. The content databases for telematics applications and services may include location information, user profiles, traffic content, map content, point-of-interest content, usage history, and the like.
The network access device 310 may be in communication with the telematics controller 312 through a communication interface 334. In some implementations the network access device 310 may be in the same package as the telematics controller 312. However, other implementations the network access device 310 may be provided in a separate package from the package of the telematics controller 312 and, therefore, may be located in a different area of the vehicle. Various information may be communicated between the telematics controller 312 and the network access device 310.
The telematics controller 312 may include a processor 336 and storage 338. The processor 336 may be a microprocessor, an application specific integrated circuit, a programmable gate array, or other processor. Further, the storage 338 may be a memory device for example, random access memory, read only memory, static memory, or may even be a hard drive or optical drive, or other means of data storage. The telematics controller 312 may be in communication with a plurality of other vehicle sensors and devices through a wire harness or over the vehicle bus as denoted by lines 340. In addition, the telematics controller 312 may be in communication with a user interface 344 as denoted by line 342. The user interface 344 may include a display 346 and controls 348 for providing user input such as vehicle parameters into the telematics controller 312. Also, the user interface 344 may include elements such as a keyboard or keypad, one or more control buttons, indicator lights, one or more speakers, a microphone, and any other user interface type elements for telematics applications and services. Optionally, the telematics controller 312 may also be connected to a positioning unit. The positioning unit could be a system that determines the geographic location of the vehicle such as a global positioning system (GPS), a dead-reckoning system, and the like.
Further, the telematics controller 312 may be in communication with other vehicle systems, such as the engine control system, the vehicle lock controls, the vehicle safety systems (e.g. seatbelt retractors, airbags, etc.), vehicle entertainment system, or a suspension control system to implement the described functions of the telematics controller 312 or network access device 310 based on parameters of such systems.
The telematics controller 312 may be powered by the vehicle battery 350 as denoted by lines 352 and 354. Alternatively, a voltage converter may be provided to convert from the vehicle battery voltage to a different voltage that may be appropriate for running the telematics controller 312. The voltage converter may be included in the package for the telematics controller 312 or alternatively may be in a separate package between the vehicle battery 350 and the telematics controller 312. The vehicle battery 350 may also provide power to the network access device 310.
A circuit 358 may be included between the vehicle battery 350 and the network access device 310. The circuit 358 may include a voltage converter to change the voltage provided to the network access device 310 in lines 360 and 362. In addition, the circuit 358 may be connected to a network access device battery 356. The network access device battery 356 may be charged while the vehicle is running and may for example, be switched to provide power to the network access device 310 when power from the vehicle power system (e.g., the battery or alternator) is not available. Further, the circuit 358 may control the monitoring and periodic powering of the network access device if the vehicle is turned off for a long period of time. Further, the circuit 358 may control the charging of the network access device battery 356 at appropriate times according to the environmental variables or the expected use cycle of the vehicle. In addition, it is possible for network access device battery 356 to be switched to provide power to the network access device 310 and also to the telematics controller 312, as denoted by lines 357. In one example, this secondary battery could be switched to provide power to the network access device 310 alone, or alternatively to both the network access device 310 and telematics controller 312 at the same time.
Now referring to
In block 414, the system determines if the request indicates direct connect request. In this instance, the request may include a phone number or profile that the user wishes to contact. If the request indicates a direct connect request, the method may follow line 416 to block 450. In block 450, the phone number or profile indicated in the request is contacted. In block 452, a call is initiated to the user using the identification provided in the request for the active phone within the vehicle. In block 454, the call to the phone number or profile from block 450 and the call to the user from block 452 are connected. In block 456, the phone number or profile information may be provided directly to the active phone in the vehicle for future use, for example by SMS text. The method then proceeds to block 438 where the method ends.
Referring again to block 414, if the request is not a direct connect request the method follows line 418 to block 420. In this scenario, the request may indicate an operator assisted call. The service provider then initiates a call with the user, as denoted by block 420. In block 422, the service provider connects the user with an operator and the operator receives verbal information from the user, such as the phone number, the name of the person, or the name of the business to call. In block 424, the operator may decide to connect the call based on a preference of the user. If the call is not connected by the operator, the method follows line 426 to block 434. If the call is connected by the operator, the method follows line 428 to block 430. Although it should noted that between steps 422 and 424, it may also be an option to end the service as denoted by line 423. For example, if the user contacts the service center just to check the hours of a restaurant, then the service center can provide this information at step 422 while talking directly to the user; the service could then be ended.
In block 430, the number or profile is contacted based on the verbal information provided to the operator by the user. Once a call is established to the number or profile, the call from block 430 is connected to the call to the user from block 420, as denoted by block 432. The phone number or directory information may be provided directly to the phone, for example by an SMS text, as denoted by block 434. The user may then store the store or use the information that was transmitted to the phone in block 434 to directly call the phone number or profile as indicated in block 436. Again, the method ends at block 438.
Now referring to
In block 518, the service provider may transmit the phone number and information about the location to the active phone in the vehicle based on the identification for the mobile device. The information may include information include the phone number, business hours, menu, web site, or other such information for the destination. In one example, the information may be sent by SMS text or email. In block 520, the user provider may provide voice instructions through the cellular phone connection initiated by the service provider. In block 522, it is determined if the directions have been completed. If the directions have not been completed, the method follows line 524 to block 516 where additional GPS data is received and further directions are provided. Referring again to block 522, if the directions are complete, the method follows line 526 to block 528 where the method ends.
In other embodiments, dedicated hardware implementations, such as application specific integrated circuits, programmable logic arrays and other hardware devices, can be constructed to implement one or more of the methods described herein. Applications that may include the apparatus and systems of various embodiments can broadly include a variety of electronic and computer systems. One or more embodiments described herein may implement functions using two or more specific interconnected hardware modules or devices with related control and data signals that can be communicated between and through the modules, or as portions of an application-specific integrated circuit. Accordingly, the present system encompasses software, firmware, and hardware implementations.
In accordance with various embodiments of the present disclosure, the methods described herein may be implemented by software programs executable by a computer system. Further, in an exemplary, non-limited embodiment, implementations can include distributed processing, component/object distributed processing, and parallel processing. Alternatively, virtual computer system processing can be constructed to implement one or more of the methods or functionality as described herein.
Further, the methods described herein may be embodied in a computer-readable medium. The term “computer-readable medium” includes a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term “computer-readable medium” shall also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the methods or operations disclosed herein.
As a person skilled in the art will readily appreciate, the above description is meant as an illustration of the principles of the invention. This description is not intended to limit the scope or application of the invention in that the invention is susceptible to modification, variation and change, without departing from spirit of the invention, as defined in the following claims.
Number | Name | Date | Kind |
---|---|---|---|
8320893 | Suurmeyer et al. | Nov 2012 | B2 |
20030224840 | Frank et al. | Dec 2003 | A1 |
20070093200 | Dobosz | Apr 2007 | A1 |
20110143668 | Farrell et al. | Jun 2011 | A1 |
20120231821 | Swanson | Sep 2012 | A1 |
Number | Date | Country |
---|---|---|
1494492 | Jan 2005 | EP |
2008115214 | Sep 2008 | WO |
Entry |
---|
Yilin Zhao, “Telematics: Safe and Fun Driving”, IEEE Intelligent Systems, Jan. 1, 2002, pp. 10-14, vol. 17, No. 1, ISSN: 1094-7167, D0I: 10.1109/5254.988442, IEEE Service Center, New York, NY, US. |
International Search Report and Written Opinion dated Jun. 4, 2012, from corresponding International Patent Application No. PCT/US2012/023151. |
Number | Date | Country | |
---|---|---|---|
20120252431 A1 | Oct 2012 | US |