CN103891327B - System and method for blocking incoming calls for a communication device connected to a vehicle telematics system - Google Patents

Abstract

In at least one embodiment, a device for blocking incoming calls from a portable communication device (PCD) in a vehicle is provided. The device includes a controller configured to receive a driver status signal indicating that the driver is one of a primary driver and a secondary driver. The controller is further configured to send a first signal to the PCD to block notification of the incoming call if the driver status signal indicates that the driver is the secondary driver.

Description

Block incoming calls for communication devices connected to the vehicle's telematics system systems and methods

This application claims the benefit of priority of US Provisional Application No. 61/544,907, filed October 7, 2011, the disclosure of which is hereby incorporated by reference in its entirety.

technical field

Embodiments disclosed herein relate generally to a system and method for masking incoming calls to a communication device connected to a vehicle telematics system.

Background technique

It is known to block notifications to the driver regarding incoming communications to the vehicle, such as phone calls. An example of this type of implementation is set forth below.

U.S. Publication No. 2012/0157069 to Elliott et al. provides a computer-implemented method comprising: receiving an incoming communication at a vehicle computing system to be sent to a wireless device in communication with the vehicle computing system Notice. The method also includes determining that a do not disturb feature is activated in the vehicle computing system, and blocking notification to the driver of the incoming communication. Finally, the method includes sending a command from the vehicle computing system to the wireless device to mute any notifications provided by the wireless device in conjunction with the incoming communication.

Contents of the invention

In at least one embodiment, an apparatus for screening incoming calls from a portable communication device (PCD) in a vehicle is provided. The apparatus includes a controller configured to receive a driver status signal indicating that the driver is one of a primary driver and a secondary driver. The controller is further configured to send a first signal to the PCD to prevent notification of the incoming call if the driver status signal indicates that the driver is the co-driver.

Description of drawings

Embodiments of the disclosure are pointed out with particularity in the claims. However, other features of various embodiments will become apparent and best understood by reference to the following detailed description taken in conjunction with the accompanying drawings, in which:

1 illustrates a system for screening incoming calls for communication devices connected to a vehicle telematics system, according to one embodiment;

Figure 2 illustrates a method for screening incoming calls based on driver status, according to one embodiment;

Figure 3 illustrates a method for screening incoming calls based on the speed of a vehicle, according to one embodiment;

4 illustrates a method for screening incoming calls based on a vehicle's transmission state, according to one embodiment;

Figure 5 illustrates a method for screening incoming calls based on a vehicle being in a high density traffic situation, according to one embodiment;

6 illustrates a method for screening an incoming call based on a gap between a vehicle and a first vehicle or based on a forward collision alert, according to one embodiment;

7 illustrates a method for screening incoming calls based on blind spot monitoring or cross traffic alert events, according to one embodiment;

Figure 8 illustrates a method for screening incoming calls based on a rear collision event, according to one embodiment;

Figure 9 illustrates a method for allowing incoming calls based on driver impairment measurements, according to one embodiment;

FIG. 10 illustrates a method for allowing an incoming call based on a detected driver's drowsiness state, according to one embodiment.

detailed description

As required, detailed embodiments of the invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention which may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.

Embodiments of the present disclosure generally provide a number of circuits or other electronic devices. All references to circuits and other electronic devices, and the functionality provided by each of the circuits and other electronic devices, are not intended to be limited to encompassing only what is shown and described herein. Although specific numbers may be assigned to the various circuits or other electronic devices disclosed, these numbers are not intended to limit the scope of operation for the circuits and other electronic devices. These circuits and other electronic devices may be combined with each other and/or separated in any manner based on the particular type of electronic implementation desired. It will be appreciated that any circuit or other electronic device disclosed herein may include any number of microprocessors, integrated circuits, memory devices (e.g., flash memory, RAM, ROM, EPROM, EEPROM, or other suitable variations of the foregoing) body) and software in combination with each other to perform any number of operations disclosed herein.

It will be appreciated that one or more of the apparatuses set forth herein may comprise a computer program, wherein the computer program comprises a computer program operable to store code embedded thereon for performing the various operations set forth herein. A non-transitory computer readable medium of computer logic embodied in computer program code.

When a person places a call to another person's cell phone, the person making the call does not know what type of environment the person he/she is calling is in. For example, the person they are calling may be operating a vehicle and be in a situation where the call should not be answered. A novice driver (eg, a teenager) may not have sufficient driving experience and/or training to ignore/reject incoming calls when the vehicle is being operated in certain driving situations.

The embodiments illustrated herein generally provide a method for enabling a primary driver (e.g., parent, employer, customer of a valet parking service, etc.) A system and method for screening and automatically rejecting all incoming calls by a specific portable communication device (PCD) of a device. The PCD may be a cellular telephone or other suitable device that enables an occupant to communicate with another individual via wireless signals transmitted therebetween. The PCD may belong to the co-driver (eg, teen, employee, valet driver, etc.). Additionally, the system and method may screen and automatically reject incoming calls to a PCD operatively connected to a vehicle controller based on the vehicle environment. In another embodiment, a system and method are provided that enable an incoming call to a vehicle occupant at the moment the driver is detected to be in a drowsy state. In this case, incoming calls are allowed to be routed to the PCD to alert or wake up the driver. These and other aspects are discussed in more detail below.

Figure 1 illustrates a system 10 for screening incoming calls, according to one embodiment. System 10 generally includes a vehicle interface device (“device”) 12 . Device 12 includes a display 14 that provides information regarding the various statuses of vehicle functions and visual warnings to the driver. For example, display 14 may provide driver identification messages during vehicle startup, may provide various administrative menu options, seat belt warning messages, speed limit occurrence messages, vehicle approaching maximum speed messages, maximum speed messages, driver identification speed warnings, a or more levels of visual warnings and forward collision warning (FCW) messages for following too closely and/or inhibiting Electronic Stability Control ("ESC"), alerts notifying the driver that the vehicle is too close to another vehicle or object etc., but not limited to this.

The device 12 may also include a voice recognition command interface 18 , an announcer 20 , a voice output function 22 and a plurality of switches 16 . The driver can toggle switch 16 to view different messages and/or select various options. Voice recognition command interface 18 may enable the vehicle to receive commands from the driver so that the driver can audibly enter commands and/or respond. One example of a voice recognition command interface is disclosed in US Patent Publication No. 20040143440, filed December 31, 2003, entitled "Vehicle Voice Recognition System" (the "'440 publication").

Announcer 20 may audibly notify the driver when predetermined vehicle conditions have been met. In one example, when the vehicle is approaching top speed, the vehicle has reached top speed, the vehicle has exceeded top speed, there is a low level of fuel in the fuel tank, when the vehicle is detected too close to another vehicle or an obstacle (to prevent collision), device 12 may activate announcer 20 when traction control is activated, etc. In one example, voice output functionality 22 enables device 12 to send audio signals to the driver in the manner described in the '440 publication, but is not limited to. In one example, switch 16 may be located within display 14 such that display 14 and switch 16 function as a touch screen. Switch 16 may be implemented as alphanumeric characters. While display 14, switch 16, voice input command interface 18, announcer 20, and voice output functionality 22 are shown as being within controller 12, it is contemplated that one or more of these mechanisms may be located at the controller 12 external.

Safety controller 24 is operatively connected to device 12 . While FIG. 1 generally shows safety controller 24 as being external to device 12 , other implementations may include safety controller 24 implemented directly within device 12 . In general, one or more signals sent to or from device 12 may be transmitted via a data communication bus. The bus may be implemented as a high/medium speed controller area network (CAN) bus, a local interconnect network (LIN) bus, or other suitable bus commonly used to facilitate data transfer therethrough. The particular type of bus used may vary to meet the standards desired by a particular implementation.

An ignition switch (not shown) may receive one or more keys 26 . Device 12 may receive a signal IGN_SW_STS from a body controller (not shown) to determine the position of the ignition switch. The key 26 may be tagged or associated with the primary or secondary driver of the vehicle. The primary driver (or supervisory driver) may be a parent, employer, or other suitable person exercising full control of the vehicle. The co-driver may be a teenager, valet driver, employee, technician, or other person who must abide by the vehicle parameters established by the primary driver. The key 26 includes an ignition key device 28 embedded therein for wireless communication with the vehicle. The ignition key device 28 includes a transponder (not shown) having an integrated circuit and an antenna. The transponder is adapted to transmit the electronic code as the signal DRIVER_STATUS to a receiver (not shown) in the security controller 24 . Data in signal DRIVER_STATUS may indicate which driver (eg, primary or secondary driver) is driving the vehicle. The signal DRIVER_STATUS may be in the form of a radio frequency identification (RFID) tag or a radio frequency (RF) based signal corresponding to binary data. Before allowing the vehicle to start, the security controller 24 determines whether additional data in the signal DRIVER_STATUS matches predetermined data stored therein (eg, in a lookup table of the security controller 24 ) for theft prevention purposes. The powertrain control module (or engine controller) 30 allows the vehicle to start the engine if the data in the signal DRIVER_STATUS matches predetermined data.

The safety controller 24 may send the signal DRIVER_STATUS_1 indicating whether a particular driver is the primary driver or the secondary driver as a hardwired signal or digital data on a data communication bus to various vehicle controllers or modules. The master key and the slave key are known to the safety controller 24 before the safety controller 24 sends the signal DRIVER_STATUS_1. Learning and programming of the key 26 as a primary or secondary key is described in U.S. Patent No. 7,868,759 to Miller et al. (the "'759 patent"), which is hereby incorporated by reference in its entirety. It will be appreciated that security controller 24 may be a passive antitheft controller as set forth in the '759 patent. It will also be appreciated that the security controller 24 set forth in FIG. 1 of the present disclosure may be implemented as a Passive Entry Passive Start (PEPS) controller set forth in the '759 patent.

An engine controller 30 is operatively coupled to device 12 . In response to determining that key 26 is authorized to start the vehicle, device 12 sends an authorization signal (not shown) to engine controller 30 . Engine controller 30 is configured to provide signal VEH_SPEED to device 12 via a data communication bus. The signal VEH_SPEED corresponds to the speed of the vehicle. Engine controller 30 is also configured to provide signal TRANS_STATUS to device 12 via the data communication bus. Signal TRANS_STATUS corresponds to the transmission state of the vehicle (eg, vehicle is in park, medium, drive, low (PRNDW gear)). Optionally, engine controller 30 is configured to send signal PARK_BK_STS to device 12 via a data communication bus. The signal PARK_BK_STS corresponds to the parking brake state of the vehicle (eg, whether the parking brake switch is engaged). In the case of a vehicle equipped with a manual transmission, the signal PARK_BK_STS may be beneficial. For example, if the signal PARK BKSTS indicates that the parking brake is engaged when the vehicle is equipped with a manual transmission, this condition may correspond to the vehicle being in park. Transmission status may not be available on manual transmission based vehicles. Such a condition may indicate that the vehicle is moving if the signal PARK_BK_STS indicates that the parking brake is not engaged.

A driver alert system (DAS) module 40 is operatively connected to the device 12 . The DAS module 40 uses a forward-pointing camera 42 to determine which side of the vehicle is departing from or crossing a lane to issue a warning. DAS module 40 sends signal LDW to device 12 to generate an audible and/or visual warning to the driver.

The DAS module 40 is configured to detect transitions in the driver's behavior that may cause the vehicle to leave a lane or change direction from the road. For example, the DAS module 40 measures and assigns a rating to Driver Impairment Monitoring (DIMON) (or Driver Alertness Rating (DAR)). DIMON tracks vehicle changes within the lane. Generally, the DAS module 40 monitors DIMON to detect shifts in the driver's performance that may result from the driver exhibiting a drowsy or drowsy state. In the event that the DIMON rating is low (or below a predefined threshold), the DAS module 40 may send a signal DIMON to the device 12 to visually and/or audibly inform the driver that the driver's performance indicates that the driver is in "Drowsy state". The reminder is provided to the driver so that the driver can pull himself out of the drowsy state.

The FCW module 43 is operatively connected to the device 12 . The FCW module 43 is generally configured to detect when a vehicle may be in a path leading to a forward collision (FC). The FCW module 43 generates a signal FCW_ALERT indicating that the vehicle may be on a path leading to a forward collision. One or more forward looking (FL) radars 44 are operatively connected to the FCW module 43 . The FL radar 44 detects the presence/approach of a vehicle (or object, obstacle, etc.) that may collide with the vehicle from ahead. The FL radar 44 sends data indicative of the presence/approach of the vehicle to the FCW module 43 . In one example, the FCW module 43 may monitor the gap between the vehicle (ie, the host vehicle) and another vehicle/object located in front of the vehicle. In the event that a vehicle is detected to be too close to a vehicle in front of the host vehicle, device 12 typically issues a spatial alert (audible and/or visual) to the driver so that the driver can take corrective action. The FCW module 43 may process the gap information and send a signal GAP_EVENT to the device 12 to trigger a forward collision alert warning/warning if the gap is less than a predetermined gap amount. The FCW alert is a higher alert relative to the space alert (or gap alert) when the vehicle is determined to be on a path leading to a forward collision. Conversely, a gap alert corresponds to the point at which the host vehicle is detected to be too close to another vehicle/object. For example, the host vehicle may be following too closely with another vehicle.

A blind spot monitoring (BSM) and cross traffic alert (CTA) module 41 (“BSM module 41 ”) is operatively connected to the device 12 . One or more side radars 46 are operatively connected to the BSM module 41 . BSM module 41 is configured to determine whether the vehicle is in or is entering the vehicle based on information provided by radar 46 (eg, radar 46 may include a radar located at the left rear corner of the vehicle and another radar located at the right rear corner of the vehicle). Location zones on either side (eg, left or right) of the . A location zone may be defined as the area extending rearwardly from the exterior rearview mirror of the vehicle to a minimum of at least three meters beyond the bumper of the vehicle. The location area can extend up to 1.5 lanes from the right or left side of the vehicle. The BSM module 41 provides an alert to the driver when a vehicle overtakes the host vehicle or stays in the location area. The BSM module 41 sends a signal BSM to the device 12 to generate (eg audible and/or visual) warnings to the driver. The warning is intended to inform the driver that a vehicle is located in the location area or is close to the vehicle.

The BSM module 41 may also perform cross traffic alert (CTA) operations. For example, signal CTA may be generated as generated by BSM module 41 in the event that the vehicle backs out of a parking space and side radar 46 detects an oncoming vehicle within the location area. The BSM module 41 receives the signal VEH_SPEED and the signal TRANS_STATUS from the device 12 (or directly from the PCM 30 ) to determine the vehicle speed and the transmission state of the vehicle. The BSM module 41 determines vehicle speed and transmission state to perform CTA operations. In one example, a threshold speed of 3 kph or above and a vehicle in reverse may be used as preconditions to perform a CTA operation.

Typically, device 12 monitors space management events using signal BSM. For example, the DAS module 40 is configured to trigger an event if the vehicle deviates from the left or right side of the lane, and the BSM module 41 provides an alert to the driver informing the driver that a vehicle is in the location area. Appliance 12 uses these alerts to monitor space management events.

Rear video module 47 may be operably connected to device 12 . One or more rearward facing cameras 48 may be connected to the rearward video module 47 to determine the presence/approach of vehicles (or objects, obstacles, etc.) located behind the vehicle. In the event a vehicle is detected to be on a route or path leading to a rear collision, device 12 typically issues a warning (audible and/or visual) to the driver so that the driver can take corrective action. In the event that the rear video module 47 detects that the vehicle is in a path that could result in a rear collision (or if a vehicle is rapidly approaching the vehicle from behind), the rear video module 47 sends a signal RCW_EVENT to the device 12 to generate an alarm. It will be appreciated that instead of a camera, a rear facing radar may be used to monitor the presence of a rearwardly positioned vehicle for the vehicle.

An interior camera 49 is also provided to capture images of the driver to additionally monitor whether the driver is drowsy. The internal camera 49 also includes hardware and software for generating a signal CAMERA_STS to provide a status as to whether the driver is drowsy or not. The interior camera 44 may provide a signal CAMERA_STS indicating that the driver is drowsy. For example, interior camera 49 may capture images of the driver while the driver is in the vehicle and process the images to determine whether the driver's eyes have been closed for a period of time exceeding a predetermined amount of time, or whether the driver's head is Tilting to one side or the other, or whether the driver's body is slumped in a downward position, to determine when the driver is drowsy, thereby determining the driver's alertness.

Generally, device 12 is configured to access vehicle-specific side or More information about space management on the side. An example of such an implementation is set forth in co-pending US Publication No. 13/091,474 to Miller et al., filed April 21, 2011, which is hereby incorporated by reference in its entirety. For example, apparatus 12 may be configured to determine whether the vehicle is in a heavy traffic environment (or high density traffic condition (“HDTC”)) based on information received from these modules. The device 12 may monitor the adjacent space around at least one side of the vehicle to determine when it is necessary to notify the driver that the host vehicle will come too close to the vehicle/object. The device 12 determines: (i) whether the vehicle is in a high density traffic situation, (ii) whether the vehicle is in a turning or intentional merge situation (CIM), or (iii) whether the driver of the vehicle is distracted in order to effectively Generate an alert.

An auxiliary protocol interface module (APIM) 45 is operatively connected to the device 12 . The APIM 45 is wirelessly connectable to the PCD 52 via the Bluetooth protocol. APIM 45 is part (and includes at least one transmitter (not shown) and at least one receiver (not shown)) of an in-vehicle communications system that interfaces with PCD 52 to enable its normal operation , perform voice input control to perform functions with the PCD 52 so that the driver does not have to directly input data into the PCD 52 . APIM 45 may allow a user to operate PCD 52 in a handheld mode (eg, manual mode) or in a voice-controlled mode (eg, w/o touch input control). APIM 45 may interface via a switch (not shown) located within the vehicle to enable touch selection controls to function with PCD 52 so that the driver does not have to enter data directly into PCD 52 . In one example, APIM45 can be implemented by with developing part of the system. A switch may be located on the APIM 45 , the vehicle's steering wheel (not shown), or on the device 12 to enable touch input.

In general, the APIM 45 can be configured to prevent calls from being received (or screen incoming calls) under certain conditions. The device 12 may send a signal DRIVER_STATUS_1 to the APIM 45 indicating that the driver of the vehicle is the co-driver. If this is the case, the APIM 45 sends a signal REJECT to the PCD 52 to reject the incoming call since it is detected that the co-driver is driving the vehicle. In this case, PCD 52 sends signal INCOMMING_CALL to APIM 45 . In response, the APIM 45 sends a signal REJECT to the PCD 52, causing the call to be rejected and no announcement or notification is provided to the driver that a call is being received. The function may be activated by the primary driver via the switch 16 and/or voice command 18 (ie if the vehicle detects that the driver of the vehicle is the primary driver via the signal DRIVER_STATUS from the ignition key device 28 ). In case the primary driver activates the function, then the device 12 prevents the secondary driver from deactivating the function when it is detected that the secondary driver is driving the vehicle. After PCD 52 is no longer operatively connected to APIM 45, notification of incoming calls may be provided. Optionally, the PCD 52 may provide a notification (or an announcement that a call was received) when the ignition state is off. In this case, device 12 may send signal IGN_SW_STS to APIM 45 . In turn, APIM 45 may wirelessly send signal IGN_SW_STS to PCD 52 to communicate ignition status. If the ignition status indicates that the vehicle is in the off position, the PCD 52 may provide notification to the co-driver (or primary driver) that a call was received, and also indicate the time, etc., or other data related to the call being received.

The APIM 50 may also prevent calls from being received under other factors not based on driving state. For example, APIM 50 may deny a call if the gap between the vehicle and another vehicle in front of the vehicle is less than a predetermined threshold and signal GAP_EVENT is active. Likewise, if a forward collision event is active (i.e., signal FCW_EVENT is active), a blind spot monitor event or cross traffic alert is active (i.e., signal BSM indicates blind spot monitoring, or cross traffic alert is active), a rear collision event is active (i.e., signal RCW_EVENT is active ), a rear collision event is active (i.e., RCW_EVENT is active), a high-density traffic condition is detected via signal HDTC sent from device 12, the vehicle speed exceeds a predetermined vehicle speed, and/or the transmission state (or parking brake state) indicates that the vehicle is in In non-parking mode, the APIM 50 can reject the call.

When a drowsy driver is detected, the APIM 45 may allow incoming calls to attempt to wake the driver. For example, the APIM 45 may allow an incoming call to wake up the driver when the signal DIMON or CAMERA_STS is received (ie, each signal providing an indication of the driver's drowsiness state). This can be done regardless of the driver's driver status. Optionally, the APIM 45 may control the PCD 52 to alert the driver or contact emergency contacts in the event that a drowsy driver is detected.

FIG. 2 illustrates a method 70 for screening incoming calls based on driver status, according to one embodiment.

At operation 71 , the APIM 45 receives a signal DRIVER_STATUS_1 indicating whether the driver is the primary driver or the secondary driver.

At operation 72 , the APIM 45 determines whether the signal DRIVER_STATUS_1 corresponds to the primary driver or the secondary driver. If a primary driver is detected, method 70 moves back to operation 71 . If a co-driver is detected, method 70 moves to operation 74 .

At operation 74 , the APIM 45 determines whether the primary driver has activated the block incoming call operation for the secondary driver. APIM 45 receives signal DND_ACTIVE from device 12 to determine whether screening of incoming calls is active. If so, method 70 moves to operation 76 . If not, method 70 moves to operation 92 .

At operation 76, the APIM 45 activates the blocking of incoming calls.

At operation 78 , the device 12 prevents the co-driver from deactivating the operation of blocking incoming calls.

At operation 80, the APIM 45 is programmed to block any incoming calls (or notifications of incoming calls such as ringtones, caller ID, etc.) on the PCD 52 when activated.

At operation 82, the APIM 45 determines whether an incoming call is being received from the PCD 52 via the signal ICOMING_CALL. If so, method 70 moves to operation 84 . If not, method 70 moves to operation 88 .

At operation 84, APIM 45 sends a signal REJECT to PCD 52, causing PCD 52 to reject the incoming call. PCD 52 may not provide notification to the co-pilot that an incoming call is being made.

At operation 86, the PCD 52 saves the call information and provides this data at a later point in time.

At operation 88, the APIM 45 determines whether the vehicle is in park. If so, method 70 moves to operation 90 . If not, method 70 moves to operation 82 .

At operation 90 , the APIM 45 sends a control signal to the PCD 52 so that the PCD 52 notifies the co-pilot that the call is received and notifies the co-pilot of relevant information related to the call.

At operation 92, the device 12 allows the primary driver to selectively enable/disable the blocking of incoming calls for him/herself.

At operation 94, the APIM 45 determines whether the primary driver has activated blocking of incoming calls for himself/herself. If so, method 70 moves to operation 96 . If not, method 70 moves to operation 102 .

At operation 96, the APIM 45 is programmed to block any incoming calls (or notifications of incoming calls such as ringtones, caller ID, etc.) on the PCD 52.

At operation 98, the APIM 45 determines whether an incoming call is being received via the signal INCOMMING_CALL. If so, method 70 moves to operation 100 . If not, method 70 moves to operation 92 .

At operation 100, APIM 45 sends a signal REJECT to PCD 52, causing PCD 52 to reject the incoming call. The PCD 52 may not provide notification to the primary driver that an incoming call is being made.

At operation 102 the APIM 45 allows all incoming calls from the PCD 52 .

FIG. 3 illustrates a method 110 for screening incoming calls based on a vehicle's speed, according to one embodiment.

At operation 112 , APIM 45 receives signal VEH_SPEED from device 12 .

At operation 114 , the APIM 45 determines whether the speed indicated by the signal VEH_SPEED is greater than a predetermined speed threshold (eg, 5 mph). If so, method 100 moves to operation 116 . If not, method 110 moves to operation 112 .

At operation 116, when the vehicle speed exceeds a predetermined speed threshold, the APIM 45 sends a signal REJECT to the PCD 52, causing the PCD 52 to reject any incoming calls. When the vehicle speed exceeds a predetermined speed threshold, the PCD 52 may not provide notification to the driver (primary or co-driver) that an incoming call is being made.

FIG. 4 illustrates a method 120 for screening incoming calls based on a vehicle's transmission state, according to one embodiment.

At operation 122 , the APIM 45 receives the signal TRANS_STATUS (or PARK_BK_STS) from the device 12 .

At operation 124 , the APIM 45 determines whether the vehicle is in park or out of park mode. If the vehicle is in park mode, method 120 moves back to operation 122 . If not, method 120 moves to operation 126 .

At operation 126, when the vehicle is in the out-of-park mode, the APIM 45 sends a signal REJECT to the PCD 52, causing the PCD 52 to reject any incoming calls. When the vehicle is in out-of-park mode, the PCD 52 may not provide notification to the driver (primary or co-driver) that an incoming call is being made.

FIG. 5 illustrates a method 130 of screening incoming calls based on the vehicle being in a high density traffic situation.

At operation 132 , the APIM 45 monitors the signal HDTC received from the device 12 .

At operation 134 , the APIM 45 determines whether the vehicle is in a high density traffic condition based on the signal HDTC. If so, method 130 moves to operation 136 . If not, method 130 moves back to operation 132 .

At operation 136, when the vehicle is in a high density traffic situation, the APIM 45 sends a signal REJECT to the PCD 52, causing the PCD 52 to reject any incoming calls. When the vehicle is in a high density traffic situation, the PCD 52 may not provide the driver (primary or co-driver) with notification that an incoming call is being made.

FIG. 6 illustrates a method 140 of screening an incoming call based on a gap between a vehicle and a first vehicle positioned in front of the vehicle.

At operation 142 , the APIM 45 monitors a signal GAP_EVENT indicating that the vehicle is too close to a first vehicle located in front of the vehicle or a signal FCW_ALERT indicating whether the vehicle is on a path that could result in a forward collision.

At operation 144 , the APIM 45 determines whether the vehicle is too close to the first vehicle based on the signal GAP_EVENT or whether the FCW condition is active. If the vehicle is too close or the FCW condition is active, method 140 moves to operation 146 . If not, method 140 moves to operation 142 .

At operation 146, when the vehicle is located too close to the first vehicle, the APIM 45 sends a signal REJECT to the PCD 52, causing the PCD 52 to reject any incoming calls. The PCD 52 may not provide notification to the driver (primary or co-driver) that an incoming call is being made.

FIG. 7 illustrates a method 150 for screening incoming calls based on blind spot monitoring or cross traffic alert conditions, according to one embodiment.

At operation 152 , the APIM 45 detects a signal BSM/CSA indicative of a blind spot monitor or cross traffic alert event.

At operation 154 , the APIM 45 determines whether the vehicle is experiencing a blind spot monitoring or cross traffic alert event based on the signal BSM/CSA. If the condition is true, method 150 moves to operation 156 . If not, method 150 moves back to operation 152 .

At operation 156 , when the vehicle is experiencing a blind spot monitoring event or a cross traffic alert event, the APM 45 sends a signal REJECT to the PCD 52 causing the PCD 52 to reject any incoming calls. When the vehicle is experiencing a blind spot monitoring event or cross traffic alert, the PCD 52 may not provide notification to the driver (primary or co-driver) that an incoming call is being made.

FIG. 8 illustrates a method 160 for screening incoming calls based on a rear collision event, according to one embodiment.

At operation 162 , the APIM 45 monitors a signal RCW_EVENT indicating that the vehicle is on a path that could result in a rear collision so that a warning can be issued to prevent an actual rear collision.

At operation 164 , the APIM 45 determines whether the vehicle is on a path that could result in a rear collision based on the signal RCW_EVENT. If the condition is true, method 160 moves to operation 166 . If not, method 160 moves back to operation 162 .

At operation 166, when the vehicle is experiencing a rear impact event, the APIM 45 sends a signal REJECT to the PCD 52, causing the PCD 52 to reject any incoming calls. When the vehicle is experiencing a rear collision event, the PCD 52 may not provide notification to the driver (primary or co-driver) that an incoming call is being made.

FIG. 9 illustrates a method 170 for admitting an incoming call based on a DIMON rating, according to one embodiment. As mentioned above, in situations where the driver is experiencing a drowsy state, it may be desirable to allow an incoming call such that the incoming call warns or wakes the driver.

At operation 172, APIM 45 monitors data received in signal DIMON.

At operation 174 , the APIM 45 determines whether the data in signal DIMON indicates that the driver is drowsy. If the condition is true, method 170 moves to operation 176 . If not, method 170 moves to operation 172 .

At operation 176 , the APIM 45 allows the PCD 52 to provide an incoming call to the vehicle in an attempt to bring the driver (primary or co-driver) out of the drowsy state.

At operation 178, when the DIMON rating indicates that the driver may be drowsy, the APIM 45 automatically and wirelessly controls the PCD 52 to contact the driver's emergency contacts in the event that an incoming call is not received (or answered).

FIG. 10 illustrates a method 180 for allowing an incoming call based on a driver's alertness state, according to one embodiment. As mentioned above, in situations where the driver is experiencing a drowsy state, it may be desirable to allow an incoming call such that the incoming call alerts or wakes the driver.

At operation 182, APIM 45 monitors data received in signal CAMERA_STS.

At operation 184 , the APIM 45 determines whether the data in the signal CAMERA_STS indicates that the driver (driver or co-driver) is dozing off. As mentioned above, the interior camera 49 captures and processes images related to the driver's alertness. The signal CAMERA_STS may provide information that the driver is drowsy. If the condition is true, method 180 moves to operation 186 . If not, method 180 moves back to operation 182 .

At operation 186, the APIM 45 allows the PCD 52 to provide an incoming call to the vehicle in an attempt to bring the driver (primary or co-driver) out of the drowsy state.

At operation 188 , when the signal CAMERA_STS indicates that the driver may be drowsy, the APIM 45 automatically and wirelessly controls the PCD 52 to contact the driver's emergency contact in the event that an incoming call is not received (or answered).

While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.

Claims (14)

1. An apparatus for screening incoming calls from a portable communication device PCD in a vehicle, the apparatus comprising: Transmitter; Controller, configured as: receiving a driver status signal indicating that the driver is one of the primary driver and the co-driver; sending, by said transmitter, a first signal to the PCD to prevent notification of incoming calls in case the driver status signal indicates that the driver is the co-driver; An ignition status signal indicating that the vehicle is in one of the operating mode and the non-operating mode is sent to the PCD by the transmitter such that in the case of the vehicle being in the non-operating mode, the PCD provides notification of the incoming call after the incoming call is blocked , Wherein, the controller is further configured to: receive a second signal indicative of a drowsy state of the driver, and allow the PCD to receive a notification of an incoming call if the second signal indicates that the driver is in a drowsy state. 2. The apparatus of claim 1, wherein the controller is further configured to receive a vehicle speed signal indicative of a vehicle speed, and when the vehicle speed exceeds a predetermined vehicle speed and the driver status signal indicates that the driver is the primary driver In the case of , a first signal is sent to the PCD by the transmitter to prevent notification of the incoming call. 3. The apparatus of claim 1 , wherein the controller is further configured to: receive a transmission state signal indicating that the vehicle is in one of a moving state and a non-moving state, and when the transmission state signal indicates that the vehicle is in a moving state and the driver Where the status signal indicates that the driver is the primary driver, a first signal is sent by the transmitter to the PCD to prevent notification of incoming calls. 4. The apparatus of claim 1, wherein the controller is further configured to: receive a traffic condition signal indicating that the vehicle is in one of a low-density traffic condition and a high-density traffic condition, and when the traffic condition signal indicates that the vehicle is in a high-density traffic condition In case of traffic conditions and the driver status signal indicates that the driver is the primary driver, a first signal is sent by the transmitter to the PCD to prevent notification of incoming calls. 5. The apparatus of claim 1 , wherein the controller is further configured to: receive a blind spot monitor signal indicating that the first vehicle is in the vehicle's blind spot, and when the first vehicle is in the vehicle's blind spot and the driver status signal indicates driving In case the driver is the primary driver, a first signal is sent to the PCD by said transmitter to block notification of the incoming call. 6. The apparatus of claim 1, wherein the controller is further configured to: receive a collision warning signal indicating that the vehicle is on a path capable of causing a collision, and when the vehicle is on a path capable of causing a collision and the driver status signal Indicating that the driver is the primary driver, a first signal is sent by the transmitter to the PCD to block notification of incoming calls. 7. A vehicle apparatus for interacting with a portable communication device PCD, said apparatus comprising: Transmitter; a controller located in the vehicle, the controller configured to: receiving a first signal indicating that the driver is drowsy; In case the first signal indicates that the driver is drowsy, a second signal is sent by the transmitter to the PCD so that the PCD receives a notification of the incoming call. 8. The apparatus according to claim 7, wherein the controller is further configured to: transmit an ignition status signal indicating that the vehicle is in one of an operating mode and a non-operating mode to the PCD through the transmitter, so that when the vehicle is in the non-operating mode In case of the operating mode, the PCD provides notification of an incoming call if the incoming call was previously blocked. 9. The apparatus of claim 7, wherein the controller is further configured to: receive a collision warning signal indicating that the vehicle is on a path capable of causing a collision, and if the vehicle is on a path capable of causing a collision, by The transmitter sends a third signal to the PCD to prevent notification of incoming calls. 10. The apparatus of claim 7, wherein the controller is further configured to: receive a driver status signal indicating that the driver is one of the primary driver and the co-driver, and when the driver status signal indicates that the driver is In the case of the co-driver, a third signal is sent by said transmitter to the PCD to prevent notification of incoming calls. 11. The apparatus of claim 7, wherein the controller is further configured to: receive a blind spot monitor signal indicating that the first vehicle is in the vehicle's blind spot, and if the first vehicle is in the vehicle's blind spot, through the The transmitter sends a third signal to the PCD to block notification of the incoming call. 12. An apparatus for screening incoming calls from a portable communication device PCD in a vehicle, the apparatus comprising: Transmitter; Controller, configured as: receiving an ignition status signal indicating that the vehicle is in one of an operational mode and a non-operative mode; receiving a vehicle speed signal indicative of vehicle speed; sending, by said transmitter, a first signal to the PCD to prevent notification of incoming calls in case the vehicle speed exceeds a predetermined vehicle speed; with the vehicle in the non-operating mode, sending, by said transmitter, a second signal to the PCD such that the PCD provides notification of the incoming call after the incoming call has been blocked, Wherein, the controller is further configured to: receive a third signal indicative of a drowsy state of the driver, and allow the PCD to receive a notification of an incoming call if the third signal indicates that the driver is in a drowsy state. 13. The apparatus of claim 12, wherein the controller is further configured to: receive a driver status signal indicating that the driver is one of the primary driver and the co-driver, and when the driver status signal indicates that the driver is In the case of the co-pilot, a first signal is sent by said transmitter to the PCD to block the notification of the incoming call. 14. The apparatus of claim 12, wherein the controller is further configured to: receive a blind spot monitor signal indicating that the first vehicle is in the vehicle's blind spot, and if the first vehicle is in the vehicle's blind spot, by the The transmitter sends a first signal to the PCD to block notification of an incoming call.