DYNAMIC STATUS UPDATE REQUEST

Abstract

Method (200) for providing status updates for a mobile device (90), comprising the following steps: (a) Receiving (210) a vehicle action request from the mobile device (90) at a switching station; (b) Initiating (230) communication to a vehicle (12) with an instruction to perform a vehicle action; (c) Determine (215) a status update frequency based on at least one real-time characteristic relating to a current communication capacity of the switching center; and (d) Instructing (222) the mobile device (90) to request status update requests concerning the vehicle action request from the intermediary at the assigned status update frequency; and (e) Changing (220) the status update frequency in response to a change in at least one real-time characteristic.

Description

TECHNICAL AREA

[0001] The present invention relates to systems and methods for controlling vehicles via remote devices and in particular to systems and methods for executing vehicle commands via mobile communication devices, such as mobile phones or smartphones, which serve only as examples. BACKGROUND

[0002] Remote controls for motor vehicles include systems that rely on the use of vehicle-specific parts, such as key fobs for locking, unlocking, or even starting a vehicle's engine. Recently, original equipment manufacturers (OEMs) have equipped vehicles with systems that can be remotely controlled and / or operated via a mobile device such as a smartphone or computer. Some vehicles, for example, are now equipped with systems that respond to user commands transmitted from a mobile device via an application supported on that device. Vehicle users can now access and control an increasing number of vehicle systems. To give just a few examples, users can access vehicle information such as tire pressure, fuel level, oil level, and recent fuel consumption through these applications.Furthermore, users can now send a variety of vehicle commands via these applications, such as unlocking / locking the vehicle, remotely starting the engine, or activating the vehicle's horn or alarm. For example, see the German patent applications KR 10 2003 0 043 083 A, US 2010 / 0 100 307 A1, DE 10 2011 006 184 A1, DE 11 2014 001 445 T5 and US 2011 / 0 060 480 A1.

[0003] The increasing number of available vehicle commands has led to increased demands on the communication systems used by the vehicle and / or manufacturer to send and receive these commands. The intensity of activity that the communication systems must support can also vary considerably. For example, a large number of remote start commands are typically sent by users during extreme weather conditions in a particular region, while comparatively few are sent when ambient temperatures are less extreme. System activity can also increase on certain days of the week and / or at certain times of day, such as at the end of the business day during the workweek when a relatively large number of users access vehicle data upon leaving the office. A variety of other factors influence system activity, creating a wide range of fluctuations in system demand.This large variation in activity forces compromises in the design of communication systems, as maximizing potential to meet peak demand leads to cost inefficiencies outside of peak demand conditions. While rule-based systems can improve efficiency, for example by increasing capacity at certain times of day / week or in response to temperature changes, the multitude of factors influencing system activity intensity still results in system inefficiencies. Additionally, the operating conditions of a mobile device used to transmit a vehicle command, such as battery level or communication signal strength, can negatively impact the user experience.

[0004] It is therefore an object of the invention to eliminate the aforementioned defects.

[0005] This problem is solved according to the invention by the features of the independent claims. Advantageous embodiments are defined in the dependent claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] One or more embodiments of the invention are described below in conjunction with the accompanying drawings, wherein identical designations denote identical elements, and wherein: Fig. 1. A block diagram representing an embodiment of a communication system capable of using the exemplary methods disclosed herein; and Fig. 2 is a process flow diagram of an exemplary procedure for providing status updates regarding vehicle commands to one or more mobile devices. DETAILED DESCRIPTION OF THE ILLUSTRATED FORM(S) OF EXECUTION

[0007] Exemplary representations of a vehicle and associated methods for providing status updates to mobile devices are described herein, such as those that display the status of requests sent by the mobile devices. The disclosed exemplary approaches generally allow the provision of status updates at a frequency determined by at least one real-time characteristic. In this way, the status update frequencies can be optimized according to factors that affect switching traffic. Real-time characteristics include a switching center's capacity to send status updates, but may also include an ambient temperature in which a vehicle is located, or the current time of day or day of the week.In other, non-inventive examples, real-time characteristics can be specific to the mobile device(s) communicating with the switching center, such as the device's battery life or signal strength. Further examples are explained below, and numerous others will become apparent from the following description.

[0008] In some exemplary approaches, different status update frequencies can be used for different mobile devices. For example, mobile devices in different geographic regions may experience different conditions at a given time, which can affect the user experience differently. Additionally, as mentioned above, operating conditions of mobile devices themselves can affect the user experience, such as battery level or the signal strength of an associated communication network. Accordingly, a corresponding variety of different status update frequencies can be used to respond to the different conditions affecting mobile devices, where a variety of mobile devices are influenced by different real-time characteristics at any given time. Communication system

[0009] With reference to Fig. Figure 1 depicts an operating environment comprising a mobile vehicle communication system 10, which can be used to implement the method disclosed herein. The communication system 10 generally includes a vehicle 12, one or more wireless carrier systems 14, a fixed network 16, a computer 18, a remote facility 80, and a mobile device 90. It is understood that the disclosed method can be used with any number of different systems and is not specifically limited to the operating environment shown here. The architecture, construction, configuration, and operation of the system 10 and its individual components are also generally known in the art. Therefore, the following paragraphs simply provide a brief overview of such a communication system 10; however, other systems not shown here could also employ the disclosed method.

[0010] Vehicle 12 is depicted in the illustrated embodiment as a passenger car; however, it should be noted that any other vehicle, including motorcycles, trucks, all-terrain vehicles (SUVs), recreational vehicles (RVs), watercraft, aircraft, etc., can also be used. Part of the vehicle electronics 20 is generally located in Fig. Figure 1 shows a telematics unit 30, a microphone 32, one or more buttons or other control inputs 34, an audio system 36, a visual display 38, a GPS module 40, and a number of vehicle system modules (VSMs) 42. Some of these devices may be directly connected to the telematics unit, such as the microphone 32 and the button(s) 34, while others may be indirectly connected using one or more network connections, such as a communication bus 44 or an entertainment bus 46. Examples of suitable network connections include a controller area network (CAN), a media-oriented system transfer (MOST), a local area network (LIN), a local area network (LAN), and other suitable connections, such as Ethernet or others, which conform to, among others, the known ISO, SAE, and IEEE standards and specifications.

[0011] The telematics unit 30 can be an OEM-installed (embedded) or aftermarket device installed in the vehicle, enabling wireless voice and / or data communication via the mobile network system 14 and wireless networking. This allows the vehicle to communicate with the remote facility 80, other telematics-enabled vehicles, or any other facility or device. The telematics unit preferably uses radio transmissions to establish a communication channel (a voice channel and / or a data channel) with the wireless carrier frequency system 14, enabling voice and / or data transmissions to be sent and received over the channel.By providing both voice and data communication, the telematics unit 30 enables the vehicle to offer a number of different services, including those related to navigation, telephony, emergency assistance, diagnostics, infotainment, etc. Data can be transmitted either via a data connection, such as packet data transmission over a data channel, or via a voice channel using techniques known in the field. For combined services that include both voice communication (e.g., with a live advisor or a voice output unit in the remote facility 80) and data communication (e.g.,(e.g., to provide GPS location data or vehicle diagnostic data to the remote facility), the system can use a single call over a voice channel and, as required, switch between voice and data transmission over the voice channel according to methods known in the field.

[0012] According to one embodiment, the telematics unit 30 uses cellular communication according to either the GSM, CDMA, or LTE standards and therefore includes a cellular standard chipset 50 for voice communication, such as hands-free calling, a wireless modem for data transmission, an electronic processing device 52, one or more digital storage devices 54, and a dual antenna 56. It is understood that the modem can be implemented either by software stored in the telematics unit and executed by the processor 52, or it can be a separate hardware component located inside or outside the telematics unit 30. The modem can operate using any number of different standards or protocols, such as LTE, EVDO, CDMA, GPRS, and EDGE. Wireless networking between the vehicle and other networked devices can also be achieved using the telematics unit 30.For this purpose, the Telematics Unit 30 can be configured to communicate wirelessly according to one or more protocols, including Short Range Wireless Communication (SRWC), such as any of the IEEE 802.11 protocols, WiMAX, ZigBee™, Wi-Fi Direct, Bluetooth, or Near Field Communication (NFC). When the Telematics Unit is used for packet-switched data communication such as TCP / IP, it can be configured with a static IP address or set up to automatically obtain an assigned IP address from another device on the network, such as a router or network address server.

[0013] The processor 52 can be any type of device capable of processing electronic instructions, including microprocessors, microcontrollers, host processors, controllers, vehicle communication processors, and application-specific integrated circuits (ASICs). It can be a dedicated processor used solely for the telematics unit 30, or it can be shared with other vehicle systems. The processor 52 executes various types of digitally stored instructions, such as software or firmware programs stored in memory 54, which enable the telematics unit to provide a wide variety of services. For example, the processor 52 can execute programs or process data to perform at least part of the procedure described herein.

[0014] The telematics unit 30 can be used to provide a diverse range of vehicle services involving wireless communication to and / or from the vehicle. Such services include: directions and other navigation-related services provided in conjunction with the GPS-based vehicle navigation module 40; airbag deployment notification and other emergency call or breakdown service-related services provided in conjunction with one or more crash sensor interface modules, such as a vehicle control module (not shown); diagnostic messages using one or more diagnostic modules; and infotainment-related services, whereby music, web pages, movies, television programs, video games, and / or other information are downloaded and stored for present or later playback by an infotainment module (not shown).The services listed above are by no means a complete list of all the capabilities of the telematics unit 30, but are simply an enumeration of some of the services that the telematics unit can offer. Furthermore, it is understood that at least some of the aforementioned modules could be implemented in the form of software commands stored inside or outside the telematics unit 30, they could be hardware components located inside or outside the telematics unit 30, or they could be integrated and / or shared with each other or with other systems located in the vehicle, to name just a few possibilities. In the event that the modules are implemented as VSM 42 located outside the telematics unit 30, they could use the vehicle bus 44 to exchange data and commands with the telematics unit.

[0015] The GPS module 40 receives radio signals from a constellation 60 of GPS satellites. From these signals, the module 40 can determine the vehicle's position, which is used to provide navigation and other position-related services to the driver. Navigation information can be displayed on the screen 38 (or another display within the vehicle) or presented verbally, as is the case, for example, with turn-by-turn navigation. The navigation services can be provided using an associated vehicle navigation module (which may be part of the GPS module 40), or some or all of the navigation services can be provided via the telematics unit 30, with the position information being sent to a remote location for the purpose of equipping the vehicle with navigation maps, map annotations (points of interest, restaurants, etc.), route calculations, and the like.The position data can be transmitted to the remote facility 80 or to another remote computer system, such as computer 18, for other purposes, such as fleet management. Additionally, new or updated map data can be downloaded from the remote facility 80 to the GPS module 40 via the telematics unit 30.

[0016] Apart from the audio system 36 and the GPS module 40, the vehicle may include 12 other vehicle system modules (VSMs) 42 in the form of electronic hardware components located in the vehicle. These typically receive input from one or more sensors and use the acquired input to perform diagnostics, monitoring, control, reporting, and / or other functions. Each of the VSMs 42 is preferably connected to the other VSMs and the telematics unit 30 via the communication bus 44 and can be programmed to perform vehicle system and subsystem diagnostic tests. For example, a VSM 42 may be an engine control module (ECM) that manages various aspects of engine operation, such as…One VSM 42 controls fuel ignition and ignition timing; another can be a powertrain control module that regulates the operation of one or more components of the vehicle's powertrain; and another can be an onboard electrical system control module that manages various electrical components in the vehicle, such as the vehicle's central locking system and headlights. According to one embodiment, the engine control unit is equipped with integrated onboard diagnostic (OBD) functions that provide a wealth of real-time data, such as data obtained from various sensors, including vehicle emission sensors, and deliver a standardized set of diagnostic trouble codes (DTCs) that enable a technician to quickly identify and rectify malfunctions within the vehicle.Experts in the field will recognize that the aforementioned VSMs are only examples of some of the modules that can be used in vehicle 12, but numerous other modules are also possible.

[0017] The vehicle electronics 20 also includes a number of vehicle user interfaces that provide vehicle occupants with a means of providing and / or receiving information, including microphone 32, button(s) 34, audio system 36, and optical display 38. As used herein, the term “vehicle user interface” broadly encompasses any suitable form of electronic device that includes both the hardware and software components located in the vehicle and enables a vehicle user to communicate with or through a component of the vehicle. The microphone 32 provides audio input to the telematics unit to enable the driver or other occupants to provide voice controls and to operate hands-free communication via the mobile network operator system 14.For this purpose, it can be connected to an integrated automatic speech processing unit, which uses human-machine interface (HMI) technology well-known among experts in the field. The button(s) 34 allow manual user input into the telematics unit 30 to initiate wireless telephone calls and provide other data, responses, or control input. Separate buttons can be used to initiate emergency calls instead of regular customer service calls to the remote facility 80. The audio system 36 provides audio output to a vehicle occupant and can be an associated standalone system or part of the primary vehicle audio system.According to the specific embodiment shown here, the audio system 36 is operationally coupled to both the vehicle bus 44 and the entertainment bus 46 and can provide AM, FM, and satellite radio, CD, DVD, and other multimedia functionality. This functionality can be provided in conjunction with the infotainment module described above or independently. The optical display 38 is preferably a graphic display, such as a touchscreen on the dashboard or a warning display reflected from the windshield, and can be used to provide a variety of input and output functions. Various other vehicle user interfaces can also be used, as the interfaces of . Fig. The numbers 1 serve only as an example of a specific implementation.

[0018] The mobile network operator system 14 is preferably a smartphone system comprising several mobile masts 70 (only one shown), one or more mobile switching centers (MSCs) 72, and any other network components required to connect the mobile network operator system 14 to the fixed network 16. Each mobile mast 70 includes transmit and receive antennas and a base station, with the base stations from different mobile masts being connected to the MSC 72 either directly or via intermediate devices, such as a base station control unit. The cell system 14 can implement any suitable communication technology, including, for example, analog technologies such as AMPS or newer digital technologies such as CDMA (e.g., CDMA2000) or GSM / GPRS. Those skilled in the art will recognize that various mobile mast / base station / MSC arrangements are possible and could be used with the wireless system 14.For example, the base station and mobile phone tower could be located in the same place or far apart, each base station could be responsible for a single mobile phone tower, or a single base station could serve several mobile phone towers, and several base stations could be coupled to a single MSC, to name just a few of the possible arrangements.

[0019] Apart from using the wireless carrier system 14, a different wireless carrier system in the form of satellite communication can be used to provide unidirectional or bidirectional communication with the vehicle. This can be done using one or more telecommunications satellites 62 and an up-facing transmitting station 64. Unidirectional communication could, for example, involve satellite radio services, where programmed content data (news, music, etc.) is received from the transmitting station 64, packaged for uploading, and then sent to satellite 62, which broadcasts the programming to subscribers. Bidirectional communication could, for example, involve satellite telephony services using satellites 62 to relay telephone communications between the vehicle 12 and station 64.When in use, this satellite telephone can be used either in addition to or instead of the wireless carrier frequency system 14.

[0020] The fixed network 16 can be a conventional land-based telecommunications network connected to one or more landline telephones and linking the wireless carrier system 14 to the remote facility 80. For example, the fixed network 16 can be a public switched telephone network (PSTN) such as that used to provide landline telephony, packet-switched data communications, and internet infrastructure. One or more segments of the fixed network 16 could be implemented using a standard wired network, a fiber optic or other optical network, a cable network, power lines, other wireless networks such as wireless local area networks (WLANs) or networks providing wireless broadband access (BWA), or any combination thereof.Furthermore, the remote facility 80 does not need to be connected via the fixed network 16, but could include radio telephony equipment so that it can communicate directly with a wireless network, such as the wireless carrier system 14.

[0021] The computer 18 can be one of a number of computers accessible via a private or public network, such as the Internet. Each of these computers 18 can be used for one or more purposes, such as a web server, accessible from the vehicle via the telematics unit 30 and the wireless carrier system 14.Other said accessible computers 18 may include, for example: a computer in a customer service center where diagnostic information and other vehicle data can be uploaded from the vehicle via the telematics unit 30; a client computer used by the vehicle owner or another participant for such purposes as accessing or receiving vehicle data, setting or configuring participant preferences, or controlling vehicle functions; or a third-party storage location to or from which vehicle data or other information is provided either by communicating with the vehicle 12 or the remote facility 80, or both.A computer 18 can also be used to provide internet connectivity, such as DNS services or as a network address server, using DHCP or another suitable protocol to assign an IP address to the vehicle 12.

[0022] The remote facility 80 is designed to equip the vehicle electronics 20 with a variety of system backend functions. The remote facility 80 can include one or more network switches, servers, databases, live advisors, and an automated speech-to-text system (VRS) with which the experts in the field are familiar. The remote facility 80 can include one or all of the various components, with all of the various components preferably being interconnected via a wired or wireless local area network. The remote facility 80 receives and transmits data via a modem connected to the fixed network 16. A database in the remote facility can store account data, such as subscriber authentication data, vehicle registration numbers, profile records, behavioral patterns, and other relevant subscriber information.Data transmissions can also occur via wireless systems, such as 882.11x, GPRS, and the like. Although the illustrated embodiment has been described as being used in conjunction with a staffed remote facility 80 employing a live advisor, it should be noted that the remote facility may instead use VRS as an automated advisor or a combination of VRS and the live advisor.

[0023] The mobile device 90 is a non-vehicle-integrated device, meaning that it is not part of the vehicle 12 or the vehicle electronics 20. The mobile device includes: hardware, software, and / or firmware that enable cellular telecommunications and / or short-range wireless communication (SRWC), as well as other functions and applications of a wireless device. The hardware of the wireless device 90 includes: a processor and memory for storing the software, firmware, etc. This memory may include either volatile random-access memory or other temporary storage, as well as non-volatile computer-readable media that stores some or all of the software for performing the various external device functions described herein.The wireless device's processor and the software stored in its memory enable various software applications that can be installed or pre-installed by the user (or manufacturer) (e.g., with a software application or a graphical user interface (GUI)). This can include an application 92 that allows a vehicle user to communicate with the vehicle 12 and / or control various aspects or functions of the vehicle—for example, among other things, allowing the user to remotely control and unlock the vehicle doors, turn the vehicle ignition on or off, check tire pressure, fuel level, oil life, etc. The application can also be used to allow the device 90 user to view information relating to the vehicle (e.g.,the current position of the vehicle, whether the vehicle is locked or unlocked) and / or in relation to an account assigned to the user or the vehicle. The wireless device 90 is depicted as a smartphone with mobile phone capabilities. In other embodiments, the device 90 may be a tablet, a laptop computer, or another suitable device. Furthermore, the application 92 enables the user to contact the remote facility 80 or telephone advisors at any time, if necessary. Procedure -

[0024] With reference to now Fig. Figure 2 shows a process flow diagram illustrating various exemplary procedures for providing status updates to one or more mobile devices. Process 200 can begin at block 205, where a user can log in to a mobile device. For example, a user can access application 92, which is supported by mobile device 90. Logging in may require the user to enter credentials, such as a user ID and / or password, to gain access to application 92. In other examples, biometric information, such as a fingerprint, may be required to access mobile device 90, which in turn grants access to application 92. The user can send and receive vehicle action requests from vehicle 12 and / or remote facility 80 via application 92.While a single mobile device 90 in . Fig. As shown in Figure 1, which is assigned to vehicle 12, additional vehicles (not shown) and associated mobile devices 90 may be provided. As described below, for example, in some exemplary representations, a large number of mobile devices 90 may be in communication with corresponding vehicles, and the remote facility 80 may facilitate such communication. Process 200 can then proceed with block 210.

[0025] Block 210 allows a vehicle action request to be sent from the mobile device to a central or remote facility. For example, a user can send a request via mobile device 90 to initiate a remote start of vehicle 12, lock or unlock the door(s) of vehicle 12, or activate an alarm on vehicle 12. The remote facility 80 can facilitate the vehicle action request, for example, by receiving the request from mobile device 90, sending the command to vehicle 12, and / or monitoring the status of vehicle 12 in relation to the request.

[0026] Building on Block 215, a status update frequency can be determined based on at least one real-time characteristic. Furthermore, in examples where a large number of vehicles 12 are each communicating with a corresponding mobile device 90, different status update frequencies can be determined for each of the corresponding device / vehicle pairings. Real-time characteristics can include any factor that influences the communication between the mobile device and the vehicle 12, or any component of the communication between them, in real time.

[0027] For example, a real-time characteristic can refer to the remote facility 80 or the switching center, such as the remote facility's current communication capacity. If the remote facility is less able to facilitate the vehicle action request and its timely implementation, for example, due to the remote facility 80 handling a high volume of communication traffic, the status update frequency can be lower. In this way, the remote facility can reduce the overall volume of status request updates subsequently received by the mobile device 90.

[0028] In another example not according to the invention, real-time characteristics of the mobile device can be used to determine a status update frequency. The mobile device 90 can provide information about its real-time characteristics to the remote device 80, e.g., the sending of the vehicle action request described above in Block 210. In this approach, the real-time characteristics can, by way of example, include the current battery status of the mobile device 90. If the mobile device 90 has a low battery status, e.g., if it is below a predetermined threshold, such as 20% of its total battery life, it may be desirable to reduce the status update frequency sent by the mobile device 90, thereby conserving the available battery power.In another example, the real-time characteristic could be the current signal strength of the mobile device 90. For instance, if the mobile device 90 has a relatively low signal strength, or a signal strength that is decreasing, such as as a result of being near or approaching the edge of a cellular service network, a Wi-Fi network, or another communication network, it may be desirable to increase the status update frequency, as there may be an indication that the device 90 may soon lose contact with the remote facility 80. Furthermore, increasing the status update frequency of the mobile device 90 can help it maintain some form of contact, since it may be easier to stay connected to a communication network than to re-establish contact if it is lost.

[0029] In other exemplary approaches, the properties of vehicle 12 and / or its environment can serve as real-time characteristics used to determine a status update frequency. For example, the current ambient temperature at vehicle 12 can be used. In an example where vehicle 12 experiences extreme temperature conditions, such as very cold temperatures, a status update frequency may be relatively low or reduced if there is an expectation of increased communication activity between the remote facility 80 and all associated vehicles 12. If temperatures in a particular region are relatively cold, there may be an expectation that more users will use remote start commands via their mobile devices.Accordingly, remote facility 80 can use a lower status update frequency when the ambient temperature falls below a predetermined threshold, such as 40 degrees Fahrenheit, within a predetermined range assigned to the vehicles 12 that receive vehicle action requests via remote facility 80. Additionally, similar considerations can be applied when temperatures are relatively high, as users can use a remote start event to initiate cooling of the vehicle interior of vehicle 12 using an air conditioner.

[0030] Further to Block 222, a vehicle action request status update can be performed when the waiting time specified by the status update frequency has elapsed. For example, mobile device 90 may have a timer or counter that counts down according to the specified status update frequency of Block 220. After the waiting time has elapsed, mobile device 90 can perform a check with the back office or remote facility 80 to request a vehicle action request status update.

[0031] At block 225, process 200 can query whether a change in the real-time characteristics has occurred that, for example, requires a change in the status update frequency determined at block 215. Process 200 can monitor the real-time characteristics regularly, for example, at predetermined or adjustable intervals, or continuously. Thus, if a change in the real-time characteristics occurs—for example, if the ambient temperature changes so that vehicle 12 is no longer in a cold or hot environment, or if the communication volume at remote facility 80 changes so that a reduced status update frequency is no longer necessary—a corresponding change to the status update frequency can be made. Process 200 can then return to block 215, where a change was detected.Alternatively, process 200 can return to block 222, so that mobile device 90 requests a status update when the wait time associated with the instructed status update frequency has elapsed. Accordingly, mobile device 90 can continue to request status updates at a suitable status update frequency, as directed at block 220.

[0032] Block 230 can initiate communication from an instruction to execute a vehicle action request. For example, remote facility 80 can send an instruction to vehicle 12 to activate remote vehicle start, lock or unlock the vehicle doors, or any other appropriate command. Communication from remote facility 80 to vehicle 12 can take any appropriate form, such as an SMS text message, communication via cell tower 70, satellite 62, or any other suitable method.

[0033] Continuing with block 235, confirmation of the vehicle action can be received. For example, vehicle 12 can initiate the vehicle action indicated in the instruction of block 230. After successful initiation of the vehicle action, such as locking / unlocking the doors, to name just a few examples, vehicle 12 can initiate communication with remote unit 80 indicating that the vehicle action was successfully completed. Alternatively, if vehicle 12 was unable to perform the vehicle action, for example, if the engine transmission was not in a suitable position so that the engine would not start, or if the door locking mechanism was jammed, etc., vehicle 12 could send an instruction to remote unit to indicate this.Communications indicating the successful or unsuccessful completion of the vehicle action from vehicle 12 to remote facility 80 may be made in any suitable form, such as an SMS text message, communication via mobile phone mast 70, satellite 62, or any other suitable manner.

[0034] Continuing from Block 240, a notification can be sent to the mobile device upon the next request from the mobile device. For example, the remote facility 80 can send a notification indicating the success or failure of the vehicle action request, in accordance with the communication received by the vehicle at Block 235. The notification to the mobile device 90 can take the form of a message in application 92 or any other method, such as an SMS text message, a phone call, or any other communication that the mobile device 90 can receive.In some exemplary approaches, an intermediate state, such as an indication that the instruction to vehicle 12 has been sent but no acknowledgment of success or other confirmation has been received from remote facility 80, can be provided to mobile device 90 if remote facility 80 has not yet received acknowledgment of success or the lack thereof from vehicle 12. Alternatively, in such an intermediate or waiting state, in the absence of any indication from remote facility 80, application 92 can assume that the vehicle action request has been completed successfully or not. After receiving communication from remote facility 80 indicating success or failure with respect to the vehicle action request, mobile device 90 can cease requesting status updates related to the vehicle action request.Furthermore, the mobile device 90 can provide information, for example via the application 92, about the successful completion or failure of the vehicle action request.

[0035] As used in this specification and the claims, the terms "e.g.", "for example", "such as", and "as" and the verbs "comprising", "including", "having", and their other verb forms, when used in conjunction with a list of one or more components or other elements, are each to be interpreted as open, meaning that the list does not exclude other additional components or elements. Other terms are to be interpreted in their broadest reasonable sense unless used in a context that requires a different interpretation.

Claims

[1] Method (200) for providing status updates for a mobile device (90), comprising the following steps: (a) Receiving (210) a vehicle action request from the mobile device (90) at a switching station; (b) Initiating (230) communication to a vehicle (12) with an instruction to perform a vehicle action; (c) Determining (215) a status update frequency based on at least one real-time characteristic relating to a current communication capacity of the switching center; and (d) Instructing (222) the mobile device (90) to request status update requests concerning the vehicle action request from the intermediary at the assigned status update frequency; and (e) Changing (220) the status update frequency in response to a change in at least one real-time characteristic. [2] Method (200) according to claim 1, further comprising a reduction (215) of the status update frequency when a current ambient temperature is below a predetermined threshold temperature. [3] Method (200) according to claim 1, further comprising a reduction (215) of the status update frequency in response to a decrease in the current communication capacity of the switching center. [4] Method (200) according to claim 1, further comprising providing an application (92) supported by the mobile device (90), wherein the status updates of the mobile device (90) are communicated via the application (92). [5] Method (200) according to claim 1, further comprising: (e) receiving an additional vehicle action request from at least one second mobile device (90) at the switching station; (f) determining a different status update frequency for the second mobile device (90) based on a real-time characteristic assigned to the second mobile device (90); and (g) instructing the second mobile device (90) to request status updates concerning the additional vehicle action request with the assigned different status update frequency. [6] System (10) for providing status updates for a mobile device (90), comprising a server configured to to receive a vehicle action request from the mobile device (90) at a switching point; to determine a status update frequency based on at least one real-time characteristic relating to the current communication capacity of the switching center; to instruct the mobile device (90) to request status updates concerning the vehicle action request from the intermediary at the status update frequency; and to change the status update frequency in response to a change in at least one real-time characteristic.

Images