Method and system for optimizing the execution of user commands related to power management

Abstract

A computer-implemented method and system for optimizing user experience are disclosed. The method and system include: determining a power profile of a device; determining historical behavior of at least one user and using a criterion based on the power profile to examine the historical behavior of the at least one user, such that if the determined power profile is equal to a first predetermined profile, the device establishes a connection when the at least one user enables a remote application to issue a command, but before the command is issued; if the determined power profile is equal to a second predetermined profile, the device establishes a connection based on the historical behavior of the at least one user; and if the determined power profile of the device is equal to a third predetermined profile, the device establishes a connection only when the at least one user issues a command.

Description

[0001] This application is a divisional application of a Chinese national phase patent application with application number 201680023262.7, which entered the Chinese national phase on October 20, 2017, and is a divisional application of the PCT application with international application number PCT / US2016 / 029048, international filing date April 22, 2016, and invention title "Methods and Systems for Optimizing the Execution of User Commands Related to Power Management". Technical Field

[0002] The present invention generally relates to wireless services, and more particularly, to devices capable of connecting to cellular or other wireless services and service optimization related to the management of the use of power and communication resources by these devices. Background Art

[0003] Many devices can be controlled or operated by instructions wirelessly transmitted by a remote device. When the "target" device is in a low-power state and not actively connected to a communication network to conserve energy or battery and reduce the use of communication resources, there is usually a significant delay between the remote device issuing a command and the command being executed.

[0004] Accordingly, there is a need to provide a method and system for optimizing the means of establishing communication between a remote device and a target device that utilizes the efficient management of power and communication resources by the target device to balance the user's need for rapid execution of user instructions. Summary of the Invention

[0005] Disclosed is a computer-implemented method and system for optimizing the user experience related to the efficient management of power and communication resources.

[0006] In a first aspect, the computer-implemented method includes: determining the power profile of a device, determining the historical behavior of at least one user, and using criteria based on the power profile to examine the historical behavior of at least one user. The criteria are used to select at least one of a plurality of means for establishing communication with the device, where (1): if the determined power profile is a first predetermined profile, the device establishes a connection for receiving commands when at least one user enables a remote application to issue a command to the device, but before the command is issued; (2) if the determined power profile is a second predetermined profile, the device establishes a connection for receiving commands based on the historical behavior of at least one user; and (3) if the determined power profile of the device is a third predetermined profile, the device establishes a connection for receiving commands only when the at least one user issues a command.

[0007] In a second aspect, a computer-implemented system includes a processor and a memory communicatively coupled to the processor, where the memory contains program instructions that, when executed by the processor, perform operations that include: determining a power profile of a device; determining historical behavior of at least one user; and examining the historical behavior of the at least one user using criteria based on the power profile. The criteria are used to select at least one of a plurality of communication channels for establishing communication with the device, where (1): if the determined power profile is a first predetermined profile, the device establishes a connection for receiving commands when at least one user enables a remote application to issue a command to the device, but before the command is issued; (2) if the determined power profile is a second predetermined profile, the device establishes a connection for receiving commands based on the historical behavior of at least one user; and (3) if the determined power profile of the device is a third predetermined profile, the device establishes a connection for receiving commands only when the at least one user issues a command. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 FIG. shows a baseline flowchart of a method for selecting a communication channel for establishing communication with a target device to enable execution of commands from a user, possibly considering either or both of the power profile of the target device and the historical behavior of at least one user.

[0009] Figure 2 FIG. shows an optimization of a method for selecting a communication channel for establishing communication with a target device to quickly execute user commands when the target device is powered on or when the battery level of the target device is greater than X%, considering only the power profile of the target device and not the historical behavior of at least one user.

[0010] Figure 3 FIG. shows a method for adjusting a communication channel for establishing communication with a target device to achieve an optimal balance between quick execution of user commands and power management when the target device is not powered on and when the battery level of the target device is less than X% but greater than Y%, considering the power profile of the target device and the historical behavior of at least one user.

[0011] Figure 4 FIG. shows a method for adjusting the optimal communication channel for establishing communication with a target device to adjust the protocol for executing user commands to optimize power management when the target device is not powered on and the battery level of the target device is less than Y%, considering only the power profile of the target device and not the historical behavior of at least one user.

[0012] Figure 5 FIG. shows a data processing system 500 suitable for storing a computer program product and / or executing program code related to a user's selection according to an embodiment of the present invention. Detailed Implementation Manner

[0013] The present invention generally relates to wireless services, and more particularly to devices capable of connecting to cellular or other wireless services and optimization of the execution of user commands related to power management of such devices.

[0014] The following description is presented to enable a person of ordinary skill in the art to make and use the invention, and the following description is provided in the context of a patent application and its claims. Various modifications to the preferred embodiments and the general principles and features described herein will be apparent to those skilled in the art. Accordingly, the invention is not intended to be limited to the embodiments shown, but rather to the broadest scope consistent with the principles and features described herein.

[0015] Although this application is described with respect to applications for devices capable of connecting to cellular or other wireless services and optimization of the execution of user commands related to power management of such devices, in the M2M field, the term "application" as used herein is intended to be inclusive, interchangeable, and / or synonymous with other similar applications further described below. However, it should be recognized that different types of applications may have features, functions, and / or operations specific to their respective capabilities and / or deployments.

[0016] Machine-to-machine (M2M) network communication involves techniques for communicating with other devices that typically have similar capabilities different from traditional cellular communication networks. In a basic M2M environment, devices with limited logic (such as sensors, meters, etc.) and limited resources (such as computing power) are located at positions where they typically capture measurable event data (such as temperature, pressure, quantity, available power, etc.). The device is connected to a remote computer or server at the application layer with specific software through a communication network. The data received from the device is converted by the application into relevant information related to the measured event data and may often be analyzed or further similarly evaluated thereafter. In many cases, when activated, the device can trigger and communicate the events it anticipates so that the communicated events will be subsequently acted upon by other machines, applications, and / or users on the network.

[0017] An M2M environment typically involves systems of wired and wireless networks that are connected to the Internet and include personal devices and similar equipment. In an M2M network, devices can typically be fixed or mobile and are connected via wired or wireless access protocols (usually via WiFi network protocols or 3GPP mobile network protocols). These devices can also have seasonal and / or flexible connectivity requirements (e.g., agricultural business requirements, store-and-forward capabilities). Typically in a busy M2M network, "always-on" devices such as General Packet Radio Service (GPRS) or Internet gateways are used. However, the M2M communication infrastructure is still most suitable for communication requirements and patterns with similar capabilities, characterized by communicating with other systems and devices on the same network.

[0018] As used herein, for the purposes of the present invention, the terms device, third-party system, smart phone, terminal, remote device, target device, wireless asset, etc. are intended to be inclusive, interchangeable, and / or synonymous with each other and with equipment based on similar communications, but it should be recognized that functionally they can each have unique features, functions, and / or operations that can be specific to their respective capabilities and / or deployments.

[0019] Many devices can be controlled or operated by instructions wirelessly transmitted by a remote device. When the "target" device is in a low-power state and not actively connected to the communication network to save energy or battery and reduce the use of communication resources, there is usually a significant delay between the issuance of a command from the remote device and the execution of the command. This delay can substantially reduce the user's satisfaction with the experience of using the remote device to control or operate the target device, especially when the user tends to issue a given command frequently, at regular times, or in predictable situations (e.g., within a given physical proximity). However, the alternative of keeping the target device in a full-power state and actively connected to the communication network to optimize the quick enabling and response to commands issued by the user's remote device may result in shortening the duration of the target device's battery life or increasing its energy consumption and the use of communication resources, thereby reducing the user's satisfaction with the power and communication resource management of the target device.

[0020] Accordingly, there is a desire to provide a method and system for optimizing the means of establishing communication between a remote device and a target device, which utilizes the efficient management of power and communication resources by the target device to balance the user's need for the quick execution of user commands.

[0021] It is generally known that for a remote device to issue commands to another "target" device, mechanisms are required to establish, actively maintain, or manage an effective wireless connection between the remote device and other devices, such as via infrared, Wi-Fi, or cellular connections. If the target device is powered on, commands issued by a remote device operating within a short range (such as an infrared "line-of-sight" device) can be effectively executed immediately. However, remote devices that can operate from a distance over a cellular network (such as wireless phones and other wireless devices ("remote devices")) must often enable an active data session through public and private networks in order to communicate with and command a target device such as an M2M device.

[0022] For a target device to receive, understand, and act on wireless communications, the target device must generally be in a sufficient power state to operate and must have an active data session established with the wireless network. However, in cases where the target device is placed in a lower power mode and has terminated the data session to conserve battery, energy, or the use of wireless resources, the transmission of a command for a user request may be delayed by the time required to transmit an initial "shoulder-tap" message from the wireless network. The shoulder-tap message commands the target device to establish a data session with the wireless network in response to any user command that can be communicated. If the device is in a low power mode when the shoulder-tap message is received, the target device may also need to return to an operating power level to establish the data session. Optimizing the target device for efficient use of power and communication resources thus frequently results in delays. The delay can last for many seconds between when a user issues a command using a remote device operating on a wireless network and when the target device responds to that command. This delay can substantially reduce user satisfaction when using an application on the remote device to control or operate the target device, especially when the user tends to issue a given command frequently, at regular times, or in predictable situations (such as within a given physical proximity).

[0023] There are two simple alternatives for reducing response time: 1) Optimize the quick enabling and completion of commands issued by a user's remote device by maintaining the target device in a full power state and keeping the data session with the wireless network continuously active, or 2) Bring the target device to that full power state and enable the data session whenever the user enables an application on the remote device, even if it is known from past behavior that the user does not issue commands in the presence at that time. Each of these alternatives can lead to depletion of the target device's battery or an increase in its energy consumption as well as an increase in the consumption of communication resources. These two alternatives can lead to reduced user satisfaction with how the remote instruction application manages power and communication resources.

[0024] Accordingly, it is desirable to provide methods and systems for optimizing the means for establishing communication between a remote and a target device, which utilize efficient management of the use of power and communication resources by the target device to balance the user's demand for rapid execution of user instructions.

[0025] While there are many environments where it would be beneficial to optimize the balance between the rapid execution of user commands issued from a remote device and the efficient management of the use of power and communication resources for a target device, an important use case is the automotive industry.

[0026] Many vehicles are equipped with a target device, such as a telematics control unit (“TCU”), which can typically communicate wirelessly via a cellular network. The TCU is used to communicate with a user or other parties (such as an original equipment manufacturer (“OEM”) or an entity providing telematics or other information management services) and to convey commands (such as “turn on the lights”) to other vehicle systems. The power for the TCU is provided by the vehicle's power system. Many TCUs are periodically programmed to reach full power and enable a data session in order to send data to the OEM or a telematics service provider and to check for commands from the user or another party. Like most wireless communication devices, if no communication is received after a specified interval, the control logic of the TCU typically requires it to terminate any ongoing packet data session on the wireless network, and when the vehicle ignition is not started or when the battery level is below a specified level or the vehicle is not connected to another continuous power source (such as utility power), the control logic of the TCU typically requires it to enter a low-power state. The low-power / inactive data session state can conserve the vehicle battery and reduce the consumption of communication resources. Since the TCU must be fully powered and a data session must be established to respond to commands transmitted over the cellular network, there is typically a time lapse between the time when a user issues a command (such as “unlock the door”) via an application on a remote device such as a smartphone and the time when the response to that command is generated by the TCU and communicated to the user.

[0027] If the TCU is in a low-power state with no active data session when a command is received from a remote device, which is typically the case where the vehicle's protocol prioritizes minimizing the consumption of power and communication resources over the rapid execution of user instructions, it cannot operate based on the command until the TCU is instructed to establish an active data session, which may include returning to the full-power mode. The operation of launching a control application on the user's remote device (or bringing the application to the foreground, meaning the application has been running in the background of the remote device but is brought to the foreground, such as by the user touching an icon on the screen so that the user can interact with it) typically serves as this “shoulder tap” instruction to the TCU.

[0028] Shoulder tapping is a request to enable a connection to the cellular network for the TCU in order to open a packet data session with an entity that receives commands from a remote device and forwards the commands to the TCU, and to check for the presence of commands. The entity that receives commands from the remote device is typically an intermediate server, but in alternative embodiments may include the remote device or another entity; for convenience, it is referred to as the "remote command server". The method may also include instructions for the remote command server to wait for a command to be issued before sending a shoulder tap and instructing the target device to establish an active data session. When a command is issued via the remote device, the remote command server will instruct the TCU to establish an active data session if needed, receive and respond to the command, and then report the result of the command execution to the remote command server. The remote command server will then report these results to the user's remote device. The time required to complete this cycle (from the issuance of the user command to the execution of the command and then the user receiving confirmation that the command has been executed) can be a long time (up to 30 to 40 seconds), which can result in a negative user experience. If the system has been configured such that the establishment of the data session is delayed until the user not only launches the control application on the remote device but actually issues a command, the interval between the issuance and execution of the command will be further extended.

[0029] Conversely, using a device protocol that prioritizes minimizing the time elapsed between the issuance and execution of user commands (e.g., by keeping the TCU in a full-power mode and a continuous active data session, or by establishing an active data session each time the user launches an application on the remote device) may result in excessive consumption of cellular resources and vehicle power. This can lead to rapid battery discharge and the cost of using cellular resources, which can also result in an unsatisfactory user experience. Since many users only enable the remote device application a few times a day to give commands to the target device, or often wait a significant amount of time between enabling the application and actually issuing a command, the risk of depleting the battery and using cellular resources to keep the target device powered on and in an active data session at all times, or each time the application is enabled or brought to attention, may make the user dissatisfied with the application.

[0030] The system and method according to the present invention solve the problem of having to choose between prioritizing fast command execution by keeping the target device powered on and in an active communication mode, which may result in rapid battery discharge and excessive consumption of communication resources; and prioritizing minimizing the use of these power and communication resources, which may result in excessive time elapsed from when the user issues a command to the target device until a report of the command operation and successful execution is transmitted to the user. The problem is solved by a set of rules executed by an algorithm on the remote command server, remote device, or other entity to determine the optimal way to enable a packet data session.

[0031] One embodiment of the present invention includes a method of evaluating and applying, considering the power profile of a target device, for selecting the best way to instruct the target device to establish communication in a particular situation from a variety of possible ways. The power profile of the target device shows the power resources available to the target device, such as but not limited to the level of stored power, such as battery charge, ignition status, connection to utility power, etc.

[0032] For example, if it is determined that the target device has an acceptable power profile (e.g., ignition on, vehicle connected to utility power, or battery not discharged below a threshold of X%) when the user first starts the relevant control application using a remote device, the TCU can be instructed, as part of the initial over-the-air communication, to immediately establish a packet data session with the remote device or server so that it can respond to any user commands, as the TCU has sufficient available power resources. In one embodiment, establishing the packet data session to enable receiving user commands may also include powering on the target device such as the TCU.

[0033] In the case where it is determined that the target device is in an undesirable power profile (e.g., ignition off or ignition status unknown, or vehicle not connected to utility power or connection status unknown and battery discharged to below a minimum level of Y%) when the user first starts using the remote device related control application, the TCU can be instructed, as part of the initial over-the-air communication, to wait to establish the packet data session until the user issues an actual command. In the first case, the time required to execute the user command is minimized, and in the second case, the risk of battery depletion is avoided, thus improving the overall user experience. In one embodiment, establishing the packet data session to enable receiving user commands may also include powering on the target device such as the TCU.

[0034] One embodiment of the present invention includes a method of evaluating and applying, considering user behavior analysis and information about the power profile of a target device, for selecting the best way to instruct the target device to establish communication in a particular situation from a variety of possible ways.

[0035] "User behavior analysis" can be used to predict the likelihood that a user of a particular remote device will issue a particular command to a target device at a particular time or within a given physical proximity. User behavior analysis includes the analysis of data collected from the application of monitoring the behavior of one or more users of a particular remote device to predict the probability of possible user behavior. For example, data is collected regarding the behavior of users of that remote device who actually issued that particular command in those situations, such as, for example, which commands are issued by users of that particular remote device at that particular time of day, on that particular day of the week, at that particular location, or within a particular physical proximity of the target device. Then, by applying rules or algorithms to determine how and when to establish an active grouped data session, this determination of the probability of issuing a command in a given situation can be used in combination with information regarding the power profile of the target device (such as a vehicle).

[0036] For example, in the case where it is determined that the target device has an intermediate power profile (e.g., ignition off or ignition status unknown, or the vehicle is not connected to utility power or connection status unknown, and the battery charge level of the vehicle is greater than Y% but less than X%) when the user first uses the remote device to start the relevant control application, the method can consider the probability of issuing a given command based on the analysis instructions of the user's historical behavior when determining the appropriate method for establishing a data session. For example, the remote device or an intermediate server can use an algorithm such as the following: "If the ignition is off (or ignition status unknown), the vehicle is not connected to utility power or connection status unknown, and the battery charge level of the vehicle is greater than Y% but less than X%, and the probability of a command from that user (or remote device) is greater than or equal to N is true, then immediately establish a grouped data session based on the notification of application startup; otherwise, if the probability of a command from that user (or remote device) is less than N, then wait to establish a data session until notified that the user actually issues that command." In one embodiment, establishing a grouped data session to enable communication can also include powering on the target device such as a TCU.

[0037] In one embodiment, an appropriate method can be selected as follows. 1) The method can specify a way to optimize the rapid execution of user commands by immediately establishing a packet data session based on a notification initiated by a control application on a remote device when the target device is powered on (e.g., vehicle ignition is on or the vehicle is connected to utility power) or when the battery is fully charged (or greater than or equal to power level X%). In this case, user behavior analysis regarding the probability that the user will quickly issue a command from the remote device is not considered. In an alternative embodiment, user behavior analysis can be used to proactively establish a packet data session when the ignition is off or the ignition state is unknown, the vehicle is not connected to utility power or the connection state is unknown, and the power level is greater than X%. 2) The method can specify other ways to be used when the target device is unknown to be powered on (e.g., vehicle ignition is off or the ignition state is unknown or the vehicle is not connected to utility power or the connection state is unknown) and the battery is partially discharged but not below a minimum acceptable threshold (e.g., power level is less than X% but greater than Y%). In this case, the method provides for using the following way: by immediately establishing a packet data session based on a notification initiated by a control application on the remote device only when user behavior analysis indicates that the probability that the user will quickly issue a command from the remote device is greater than or equal to N, thereby achieving a better balance between the rapid execution of user commands and the efficient management of the use of power and communication resources. 3) The method can specify other ways to be used when the vehicle ignition is off or the ignition state is unknown, the vehicle is not connected to utility power or the connection state is unknown and the battery power is below a certain minimum acceptable threshold power level (e.g., power level is less than or equal to Y%). This way optimizes power savings by instructing the target device to establish a packet data session only when the user actually issues a command; user behavior analysis regarding the probability that the user will quickly issue a command from the remote device will not be considered. In one embodiment, establishing a packet data session to enable communication can also include powering on the target device (e.g., TCU).

[0038] In one embodiment, the method and system determine whether the power profile of a device matches one of the predefined profiles, and use the identified power profile as a criterion for whether to consider the historical behavior of the user of the device before establishing a connection for communication such as sending and receiving data (e.g., user commands). Predefined profiles can be defined for an application, for example, in the case of a vehicle, in an embodiment, Profile 1: when the power profile of the device indicates that the ignition is on or the vehicle is connected to utility power or the battery power level is higher than X%. Profile 2: when the power profile of the device indicates that the battery power level is less than or equal to X% but higher than Y%. Profile 3: when the power profile of the device indicates that the battery power level is less than or equal to Y%. Since these profiles are defined for the application, developers can set them as needed.

[0039] Similarly, for an application-defined probability N that a user will quickly issue a command from a remote device, and a developer can set it as needed. For example, it can be set to "immediately establish a packet data session based on a notification initiated by a control application on a remote device only when the analysis of user behavior indicates that the probability that the user will quickly issue a command from the remote device is greater than or equal to N" or simply "greater than N".

[0040] To describe the features of the present invention in more detail in the context of the automotive industry, reference is made to the accompanying drawings in connection with the following discussion. These examples are for illustrative purposes only and should not be construed as limiting.

[0041] Figure 1 A baseline flowchart of a system is shown that allows a vehicle user to issue commands to a vehicle from a remote device and uses a method of selecting a path to establish a data session based on criteria considering an analysis including the power profile of the vehicle and user behavior data to balance the efficient management of the use of power and communication resources with the rapid execution of user commands. In one embodiment, the control logic in vehicle TCU 101 can instruct it to enable a data session to report the power profile of the vehicle to a remote command server that receives data and executes remote commands 111, for example, by changing the ignition state or connecting to utility power, or whenever its battery charge level drops to a specified threshold (e.g., less than X%), either periodically via step 106 or whenever there is a change. Periodically receiving and storing the power profile enables the remote command server to quickly determine the most recent vehicle power profile. Via step 104, the vehicle owner or user uses a smart phone or other remote device 131 to launch or bring to focus an application operating on the remote device for issuing commands to the vehicle TCU. When the application is launched or brought to focus, the remote device 131 sends a signal to the remote command server 111 via step 106. The remote command server 111 checks the most recent power profile of the vehicle via step 108.

[0042] Based on the vehicle's power profile, the remote command server 111 can query the analysis database 121 for the user's typical behavior using user behavior analysis via step 110. In one embodiment, the typical user behavior can be represented as the probability of a command being issued by the user or a remote device in a particular situation. Based on the probability value received from the analysis database 121, the remote command server 111 sends an instruction to the vehicle TCU 101 via step 112 by over-the-air (OTA) to establish a packet data session. The vehicle TCU 101 initiates the packet data session via step 114 and queries the remote command server 111 for the presence of a user command. The remote command server 111 saves the query from the vehicle TCU 101 via step 116. If and when the owner or user selects a command via step 118, the remote command request is sent from the owner's smartphone or other remote device 131 to the remote command server 111 via step 120 and relayed by the remote command server to the vehicle TCU 101.

[0043] Then, the vehicle TCU 101 executes the user command request via step 122. Via step 124, the execution result is published to the remote command server 111, and the vehicle TCU 101 checks for the presence of another user command. The execution result of the command is sent by the remote command server 111 to the owner or user's smartphone or other remote device 131 via step 126, and the remote device is updated with the result via step 128. The user behavior analysis database is updated via step 130. A decision is made based on the vehicle's power profile and the user's behavior in sending the command request regarding whether to maintain the connection between the vehicle TCU and the remote command server; according to the decision made, the remote command server 111 sends a "keep-alive" command or an instruction to terminate the data session and return to the low-power mode to the vehicle TCU 101 via step 132.

[0044] In one embodiment, the target device can report its power profile by periodically reporting its current battery level. In another embodiment, the power profile can be reported when it changes from one threshold to another, regardless of the preset reporting interval. For example, since the battery level drops from Y + 1% to Y% or from Y% to Y - 1%, it will be reported even if no reporting is scheduled. Similarly, when the ignition state changes from ignition "off" to ignition "on", or the state of connection to the utility power changes from "not connected" to "connected", it will be reported even if no reporting is scheduled.

[0045] In one embodiment, the analytics database 121 is capable of assigning a probability that an owner or user will issue a command by collecting and analyzing data regarding user behavior under specific circumstances. For example, if a user typically unlocks the vehicle door using an application on a smartphone or other remote device between 8:00 a.m. and 8:15 a.m. on each weekday (when the remote device is within X meters of the vehicle), or if the user typically starts the vehicle air conditioner between 5:30 p.m. and 6:00 p.m. on each weekday using the remote device application, the analytics database will record this data. The next time the remote device application is launched or brought to attention, the analytics database 121 will calculate the probability that a command will be issued and provide the requested probability value to the remote command server 111 based on factors such as the time of day and the proximity of the remote device to the vehicle.

[0046] For example, when the time is closer to 8:00 a.m. or 5:00 p.m. on a weekday and when the remote device is within X meters of the vehicle, the probability value will be higher, and if the remote command server 111 considers the probability value based on the vehicle's power profile and the value assigned by the analytics database 121 is greater than N, the remote command server will first instruct the vehicle TCU 101 to immediately establish a packet data session without waiting for a user command, and then keep the connection active for a given period of time to allow for the rapid execution of additional commands, resulting in a substantial reduction in the time delay between the issuance of a user command and the response to these commands, and improving user satisfaction with the vehicle and remote device control applications.

[0047] Figure 2 Embodiments of the present invention are shown for a method of selecting a path for establishing an active data session to optimize the rapid execution of user commands when the vehicle ignition is on, the vehicle is connected to public power, or when the battery is fully charged (or the battery level is greater than battery level X%). In such a case, the consumption of power and communication resources for receiving user commands and operating based on user commands by maintaining the TCU powered on and in an active communication state is not a significant issue, and the remote command server can instruct the TCU to immediately establish a packet data session when the user launches or brings to attention an application on a smartphone or other remote device, eliminating the delay caused by the TCU receiving a piggyback and then waiting for notification of the actual receipt of a command before establishing a data session. In another embodiment, the method uses user behavior analysis to proactively establish a packet data session based on historical user behavior at a time of day, day of the week, location of the target device, and location of the remote device containing the remote application when the power profile shows the ignition off or the ignition state unknown or the vehicle is not connected to public power or the connection state is unknown but the battery level is greater than X%.

[0048] As Figure 2As shown, the vehicle owner (or user) starts or focuses on the control application operating on the remote device 231 via step 204 to issue a command to the vehicle TCU 201. When the application starts or is focused on, the remote device 231 sends a signal to the remote command server 211 via step 206, and the remote command server 211 checks the power profile of the vehicle via step 208. Since the power profile of the vehicle is reported as ignition on or the vehicle is connected to utility power or the battery charge level is greater than or equal to X%, the remote command server will not query the probability of the command from the user behavior analysis database 221 and will send an instruction to the vehicle 201 via step 210 to immediately establish a packet data session. Alternatively, based on the time of day, day of the week, location of the target device, and location of the remote device containing the remote application, etc., user behavior analysis can be used to proactively establish a packet data session when the power level is greater than or equal to X% based on typical or historical user behavior.

[0049] The vehicle TCU 201 starts a packet data session via step 212 and queries the remote command server 211 for the existence of a user command. The remote command server 211 saves the query from the vehicle TCU 201 via step 214. If and when the user selects a remote command via step 216, the remote command request is sent from the remote device 231 to the remote command server 211 via step 218 and is relayed by the remote command server to the vehicle TCU 201. This user command is then executed by the vehicle TCU 201 via step 220. Via step 222, the execution result is published to the remote command server 211, and the vehicle TCU 201 checks for the existence of another user command. The execution result of the user command is sent by the remote command server 211 to the remote device 231 via step 224 and the remote device is updated with the result via step 226. The user behavior analysis database is updated via step 228. Since the power profile of the vehicle is ignition on or the vehicle is connected to utility power or the battery charge level is greater than or equal to X%, the remote command server 211 will instruct the vehicle TCU 201 to keep the connection between the vehicle TCU and the remote command server active for a given period of time so that further user commands can be executed immediately.

[0050] In an alternative embodiment, the Remote Command Server 211 uses user behavior analysis to instruct the vehicle TCU to maintain a connection between the vehicle TCU and the Remote Command Server for a given period of time based on typical user behavior determined by the User Behavior Analysis Database when the power profile is ignition on, the vehicle is connected to utility power, or the battery charge level is greater than or equal to X%. The connection between the vehicle TCU and the Remote Command Server remains active when the ignition is on or the vehicle is connected to utility power, regardless of user behavior analysis, because in this state, the battery is being continuously charged or the charge level is high and this connection will not cause depletion of power resources.

[0051] Figure 3 Illustrates a method for selecting a path for establishing an active data session when the last known vehicle power profile is vehicle ignition off (or ignition state unknown), the vehicle is not connected to utility power (or connection state unknown), and the battery is partially discharged and below a certain threshold. Since the battery charge has dropped to less than X% but greater than or equal to Y%, the method will adjust the instruction for establishing a packet data session by considering the typical user behavior profile. If, based on user behavior analysis, the probability that the user will issue a command when the application has been launched or made prominent on the remote device is greater than or equal to N, the Remote Command Server may instruct the TCU to immediately establish a packet data session. Any user command will be executed without any delay due to the TCU receiving a piggyback and then waiting for notification that the command has actually been received before establishing the data session. If the probability is less than N, the method will prioritize reducing the use of power and communication resources and will instruct the vehicle TCU to wait for a command to be issued before establishing a packet data session when the application on the remote device has been launched or made prominent.

[0052] As Figure 3As shown, the vehicle owner (or user) starts or makes the application that operates on the remote device 331 to issue a command to the vehicle TCU via step 304. When the application starts or is made to be in focus, the remote device 331 sends a signal to the remote command server 311 via step 306, and the remote command server 311 checks the power profile of the vehicle via step 308. Since the power profile of the vehicle is reported as ignition off (or ignition status unknown), the vehicle is not connected to utility power (or connection status unknown), and the battery charge level is less than X% but greater than or equal to Y%, the remote command server 311 queries the analysis database 321 for the probability of the command via step 310. If the received probability value is less than N, the remote command server 311 will wait for the actual command to be issued before instructing the vehicle TCU to establish a packet data session. However, if the probability value received from the analysis database 321 is greater than or equal to N, the remote command server 311 will send an instruction to the vehicle TCU 301 via step 312 to immediately establish a packet data session. The vehicle TCU 301 starts a packet data session via step 314 and queries the remote command server 311 for the existence of a user command.

[0053] The remote command server 311 saves the query from the vehicle TCU 301 via step 316. If no command is received within X seconds, the remote command server 311 will instruct the vehicle TCU 301 to terminate the data session and return to the low power mode via step 316, and the process will return to the initial state. However, if the user selects a command within this time period via step 320, the command request is sent from the smart phone or other remote device 331 to the remote command server 311 via step 322 and relayed by the remote command server 311 to the vehicle TCU 301. The user command is executed by the vehicle TCU 301 via step 324. Via step 326, the execution result is posted to the remote command server 311, and the vehicle TCU 301 checks for the existence of other user commands. The execution result of the command is sent by the remote command server 311 to the remote device 331 via step 328, and the remote device is updated with the result via step 330. The user behavior analysis database is updated via step 332.

[0054] Then a decision is made based on the power profile of the vehicle and the user behavior in sending the command request on whether to keep the connection activity between the vehicle TCU 301 and the remote command server 311; depending on the decision made, a "keep alive" command or an instruction to terminate the connection and return to the low power mode is sent to the vehicle TCU 301 via the remote command server 311 via step 334.

[0055] Figure 4A method for selecting a means to establish an active data session when the battery power drops below a certain threshold level is shown. For example, if the ignition is off (or the ignition status is unknown), the vehicle is not connected to utility power (or the connection status is unknown), and the battery charge is less than Y%, it is a problem that maintaining the TCU in an active power and communication state to receive user commands and the consumption of power and communication resources resulting from operating based on user commands. Therefore, the remote command server will wait to instruct the TCU to establish a packet data session only when the user actually issues a command, without any consideration of typical user behavior. Once the command is issued and executed, the TCU will remain in full-power mode, and the data session will remain connected for a short period, waiting for other commands. Although there will be a delay in the execution of the user command because the TCU is not connected to the remote command server until the user command is actually received and the instruction to establish the data session has been sent to the TCU, the user may be more dissatisfied if optimizing the rapid execution of the command causes the battery discharge to drop below the level required for ignition.

[0056] As Figure 4 shown, the vehicle owner (or user) starts or focuses on an application that operates on the remote device 431 to issue a command to the vehicle TCU 401 via step 404. When the application is started or focused, the remote device 431 sends a signal to the remote command server 411 via step 406, and the remote command server 411 checks the last known power profile of the vehicle stored in the remote command server via step 408. Since the power profile of the vehicle reports that the battery charge level is less than Y% and the ignition status is unknown or off and the vehicle is not connected to utility power or the connection status is unknown, the remote command server will not query the analysis database 421 for the probability of the command and will wait to send a sidecar connection to the vehicle TCU 401 until the user actually selects a command. Once the user selects a command, the remote command request is sent from the smartphone or other remote device 431 to the remote command server 411 via step 414.

[0057] The remote command server 411 sends a tethered attachment to the vehicle TCU 401 via step 414, instructing it to establish a packet data session. The vehicle TCU 401 starts the packet data session via step 416 and asks the remote command server about the existence of user commands; the remote command server relays the commands to the vehicle TCU via step 418. Then, the user command is executed by the vehicle TCU 401 via step 420. Via step 422, the execution result is posted to the remote command server 411 and the vehicle TCU 401 checks for the existence of another user command. The execution result of the remote command is sent by the remote command server 411 to the remote device 431 via step 424, and the remote device is updated with the result based on step 426. Since the power profile of the vehicle is a battery charge level less than Y%, the remote command server 411 does not wait for additional user commands, but instead immediately instructs the vehicle TCU 401 via step 428 to terminate the packet data session and the connection between the vehicle TCU and the remote command server and return to the low power mode in order to conserve battery and communication resources. The user behavior analysis database is updated via step 430.

[0058] According to the present invention, there is provided another embodiment of the present invention, which includes a computer program product system having a method of selecting one or more ways to establish a data connection, the ways optimizing the balance between the rapid execution of user commands and the efficient management of the use of power and communication resources depending on context characteristics, the context characteristics including but not limited to the power profile of the device and user behavior analysis. Figure 5 A data processing system 500 suitable for storing a computer program product and / or executing program code in accordance with an embodiment of the present invention is shown. The data processing system 500 includes a processor 502 coupled to memory elements 504a-b via a system bus 506. In other embodiments, the data processing system 500 may include more than one processor, and each processor may be directly or indirectly coupled to one or more memory elements via the system bus.

[0059] The memory elements 504a-b may include local memory, mass storage, and cache memory employed during the actual execution of the program code, the cache memory providing temporary storage of at least some of the program code in order to reduce the number of times code must be retrieved from mass storage during execution. As shown, input / output or I / O devices 508a-b (including but not limited to a keyboard, a display, a pointing device, etc.) are coupled to the data processing system 500. The I / O devices 508a-b may be directly or indirectly coupled to the data processing system 500 through an intermediate I / O controller (not shown).

[0060] In Figure 5In it, network adapter 510 is coupled to data processing system 902 such that data processing system 502 can be coupled to other data processing systems or remote printers or storage devices via communication link 512. Communication link 512 can be a private or public network. Modems, cable modems, and Ethernet cards are just some of the currently available types of network adapters.

[0061] Embodiments described herein may take the form of an all-hardware embodiment, an all-software embodiment, or an embodiment including both hardware and software elements. The embodiments may be implemented in software including, but not limited to, application software, firmware, resident software, microcode, etc.

[0062] The steps described herein may be implemented using any suitable controller or processor and software applications that may be stored in any suitable storage location or computer-readable medium. The software applications provide instructions that enable the processor to cause the receiver to perform the functions described herein.

[0063] In addition, the embodiments may take the form of a computer program product accessible from a computer-usable or computer-readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For the purposes of this specification, a computer-usable or computer-readable medium can be any device that can contain, store, communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0064] The medium can be electronic, magnetic, optical, electromagnetic, infrared, semiconductor system (or device or apparatus), or propagation medium. Examples of computer-readable media include semiconductor or solid-state memory, magnetic tape, removable computer disk, random access memory (RAM), read-only memory (ROM), rigid disk, and optical disk. Current examples of optical disks include digital versatile disk (DVD), compact disk read-only memory (CD-ROM), and compact disk read / write (CD-R / W).

[0065] Any theory, operating mechanism, evidence, or finding described herein is intended to further enhance the understanding of the present invention and not to make the present invention depend on such theory, operating mechanism, evidence, or finding in any way. It should be understood that although the word "preferred", "preferably", or "preferred use" in the above description indicates that the features so described may be more desirable, they may not be essential, and embodiments lacking such features may be considered within the scope of the present invention, the scope of which is defined by the appended claims.

[0066] As used herein, for purposes of the present invention, the terms device, target device, apparatus, terminal, remote device, computer, server, wireless asset, smart phone, remote device, etc. are intended to be inclusive, interchangeable, and / or synonymous with each other and with other similar communication-based or computing devices, but it will be recognized that each may have unique characteristics, functions, and / or operations functionally specific to their respective capabilities and / or deployments.

[0067] Similarly, the present invention contemplates that the terms "communication," "wireless," or "cellular" network include communication across networks using one or more communication architectures, methods, and networks (e.g., communication for M2M communication but not limited thereto), the communication architectures, methods, and networks including but not limited to: Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM) ("GSM" is a trademark of the GSM Association), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Fourth Generation Cellular System (4G) LTE, Wireless Local Area Network (WLAN), and one or more wired networks.

[0068] As used herein, the term M2M communication is understood to include the use of various connected computing devices, servers, server clusters, wired and / or wireless methods that provide network infrastructure to deliver computing, processing, and storage capacity as a service, where users typically access applications through connected modules such as, but not limited to, web browsers, terminals, mobile applications, or similar programs, while the main software and data are stored on servers or in locations different from the devices.

[0069] Although the present invention has been described in terms of the illustrated embodiments, those of ordinary skill in the art will readily recognize that the embodiments may vary and such variations will be within the spirit and scope of the present invention. Accordingly, many modifications may be made by those of ordinary skill in the art without departing from the spirit and scope of the present invention.

Claims

1. A computer-implemented method for optimizing user experience and power management, comprising: Determining the historical behavior of at least one user, wherein determining the historical behavior is based on a set of parameters related to the device; Determining the power profile of the device, the power profile showing the power resources available to the device; Determining at least one condition for establishing a connection with the device, wherein determining at least one condition for establishing a connection with the device includes: determining the probability that the at least one user will issue a remote command based on the historical behavior of the at least one user regarding the set of parameters related to the device, and further includes at least one user invoking a remote application for issuing a command to the device; and Using a rule for selecting at least one of a plurality of ways to establish a connection with the device; Wherein at least one of the selected plurality of ways includes proactively establishing a connection with the device based on the typical historical behavior of at least one user regarding the set of parameters related to the device, so that the remote application issues a command to the device, and wherein the rule for selecting at least one of the plurality of ways includes: considering any one or more of the following: the power profile of the device, the historical behavior data of the at least one user, and at least one condition for establishing a connection with the device; and further includes: If the determined power profile is a first predetermined profile, the device establishes a connection for receiving a command when the at least one user enables the remote application to issue a command to the device, but before the command is issued; If the determined power profile is a second predetermined profile, the device establishes a connection for receiving a command based on the historical behavior of the at least one user; and If the determined power profile of the device is a third predetermined profile, the device establishes a connection for receiving a command only when the at least one user issues a command; and Selecting at least one of the plurality of ways to establish a connection with the device in relation to the result of the consideration, Wherein the first predetermined profile includes: determining that the power profile of the device is any of the following: the stored power level is equal to or higher than a first predetermined percentage, and the device receives continuous power supply through a power source; Wherein the second predetermined profile includes: determining that the power profile of the device is that the stored power level is equal to or higher than a second predetermined percentage and lower than the first predetermined percentage; Wherein the third predetermined profile includes: determining that the power profile of the device is that the stored power level is lower than the second predetermined percentage.

2. The method according to claim 1, wherein the set of parameters includes any one of the following: the location of the device when the at least one user issues a command, the location of the remote device including the remote application, the proximity of the remote device to the device, the time of day, the day of the week, the type of command issued, and combinations of the above.

3. The method according to claim 1, wherein establishing a connection with the device further includes powering on the device.

4. A system for optimizing user experience and power management, comprising devices, a database, and a server, the server including a processor and a memory communicating with the processor, wherein the server: Determines the historical behavior of at least one user based on a set of parameters related to the device; Determines the power profile of the device, the power profile showing the power resources available to the device; Determines at least one condition for establishing a connection with the device, wherein determining at least one condition for establishing a connection with the device includes: Determining the probability that the at least one user will issue a remote command based on the historical behavior of the at least one user regarding the set of parameters related to the device, and further including at least one user invoking a remote application for issuing a command to the device; And Using rules for selecting at least one of a plurality of ways to establish a connection with the device, wherein at least one of the selected plurality of ways includes actively establishing a connection with the device based on the typical historical behavior of at least one user regarding the set of parameters related to the device, so that the remote application issues a command to the device, wherein the rules for selecting at least one of the plurality of ways include considering any one or more of the following: the power profile of the device, the historical behavior data of the at least one user, and at least one condition for establishing a connection with the device, and further including: If the determined power profile is a first predetermined profile, the device establishes a connection for receiving a command when the at least one user enables the remote application to issue a command to the device, but before the command is issued; If the determined power profile is a second predetermined profile, the device establishes a connection for receiving a command based on the historical behavior of the at least one user; and If the determined power profile of the device is a third predetermined profile, the device establishes a connection for receiving a command only when the at least one user issues a command; and Selects at least one of the plurality of ways to establish a connection with the device in relation to the result of the consideration, Wherein the first predetermined profile includes: determining that the power profile of the device is any of the following: the stored power level is equal to or higher than a first predetermined percentage, and the device receives continuous power supply through a power source; Wherein the second predetermined profile includes: determining that the power profile of the device is that the stored power level is equal to or higher than a second predetermined percentage and lower than the first predetermined percentage; Wherein the third predetermined profile includes: determining that the power profile of the device is that the stored power level is lower than the second predetermined percentage.

5. The system according to claim 4, wherein the set of parameters includes any one of the following: the location of the device when the at least one user issues a command, the location of the remote device including the remote application, the proximity of the remote device to the device, the time of day, the day of the week, the type of command issued, and combinations of the above.

6. The system according to claim 4, wherein establishing a connection with the device further includes powering on the device.

7. A non - transitory computer - readable medium having executable instructions stored therein that, when executed, cause one or more processors corresponding to a system having a device, a database, and a server to perform operations, wherein the server includes a processor and a memory communicating with the processor, and the operations include: Determining the historical behavior of at least one user, wherein determining the historical behavior is based on a set of parameters related to the device; Determining the power profile of the device, the power profile showing the power resources available to the device; Determining at least one condition for establishing a connection with the device, wherein determining at least one condition for establishing a connection with the device includes: determining the probability that the at least one user will issue a remote command based on the historical behavior of the at least one user regarding the set of parameters related to the device, and further includes at least one user invoking a remote application for issuing a command to the device; and Using a rule for selecting at least one of a plurality of ways to establish a connection with the device; Wherein at least one of the selected plurality of ways includes proactively establishing a connection with the device based on the typical historical behavior of at least one user regarding the set of parameters related to the device so that the remote application can issue a command to the device, and wherein the rule for selecting at least one of the plurality of ways includes considering any one or more of the following: the power profile of the device, the historical behavior data of the at least one user, and at least one condition for establishing a connection with the device, and further includes: If the determined power profile is a first predetermined profile, the device establishes a connection for receiving commands when the at least one user enables the remote application to issue a command to the device, but before the command is issued; If the determined power profile is a second predetermined profile, the device establishes a connection for receiving commands based on the historical behavior of the at least one user; and If the determined power profile of the device is a third predetermined profile, the device establishes a connection for receiving commands only when the at least one user issues a command; and Selecting at least one of the plurality of ways to establish a connection with the device in relation to the result of the consideration, Wherein the first predetermined profile includes: determining that the power profile of the device is any one of the following: the stored power level is equal to or higher than a first predetermined percentage, and the device receives continuous power supply through a power source; Wherein the second predetermined profile includes: determining that the power profile of the device is that the stored power level is equal to or higher than a second predetermined percentage and lower than the first predetermined percentage; Wherein the third predetermined profile includes: determining that the power profile of the device is that the stored power level is lower than the second predetermined percentage.

8. The non-transitory computer-readable medium according to claim 7, wherein the set of parameters includes any one of the following: the location of the device when the at least one user issues a command, the location of a remote device including a remote application, the proximity of the remote device to the device, the time of day, the day of the week, the type of command issued, and combinations of the foregoing.

9. The non-transitory computer-readable medium according to claim 7, wherein the operation of establishing a connection with the device further includes powering on the device.

10. A computer-implemented method for optimizing user experience and power management, comprising: Determining a power profile of a target device, the power profile showing power resources available to the target device; Determining historical behavior of at least one user associated with the target device, the historical behavior being determined based on a set of parameters associated with the device; Considering the power profile of the target device; Based on the determined power profile of the target device, considering historical behavior data of the at least one user associated with the target device; and Using rules in relation to the result of the consideration to select at least one of a plurality of ways to establish a connection with the target device, wherein at least one of the selected plurality of ways includes proactively establishing a connection with the device based on typical historical behavior of the at least one user regarding the set of parameters associated with the device, so that a remote application issues a command to the device, and wherein using rules to select at least one of a plurality of ways to establish a connection with the target device includes: determining a probability that the at least one user will issue a remote command based on the historical behavior of the at least one user associated with the set of parameters; wherein one of the plurality of ways to establish a connection with the target device includes the at least one user invoking a remote application for issuing a command to the target device; wherein the rules include: If the determined power profile is a first predetermined profile, the device establishes a connection for receiving a command when the at least one user enables the remote application to issue a command to the device, but before the command is issued; If the determined power profile is a second predetermined profile, the device establishes a connection for receiving a command based on the historical behavior of the at least one user; and If the determined power profile of the device is a third predetermined profile, the device establishes a connection for receiving a command only when the at least one user issues a command, wherein the first predetermined profile includes: determining that the power profile of the device is any one of the following: the stored power level is equal to or higher than a first predetermined percentage, and the device receives continuous power supply through a power source; wherein the second predetermined profile includes: determining that the power profile of the device is that the stored power level is equal to or higher than a second predetermined percentage and lower than the first predetermined percentage; wherein the third predetermined profile includes: determining that the power profile of the device is that the stored power level is lower than the second predetermined percentage.

11. The method according to claim 10, wherein the set of parameters includes any one of the following: the location of the target device when the at least one user issues a command, the location of the remote device including the remote application, the proximity of the remote device to the target device, the time of day, the day of the week, the type of command issued, and combinations of the foregoing.

12. The method according to claim 10, wherein establishing a connection with the target device further includes powering on the target device.

13. A system for optimizing user experience and power management, comprising a target device, a database, and a server, the server including a processor and a memory communicating with the processor, wherein the server: Determines the historical behavior of at least one user based on a set of parameters related to the target device; Determines the power profile of the target device, the power profile showing the power resources available to the target device; Considers the power profile of the target device, Based on the determined power profile of the target device, considers the historical behavior data of the at least one user; and Uses rules in relation to the result of the consideration to select at least one of a plurality of ways to establish a connection with the target device, wherein at least one of the selected plurality of ways includes proactively establishing a connection with the device based on the typical historical behavior of the at least one user regarding the set of parameters related to the device, so that a remote application issues a command to the device, and wherein using rules to select at least one of a plurality of ways to establish a connection with the target device includes: determining the probability that the at least one user will issue a remote command based on the historical behavior of the at least one user related to the set of parameters; Wherein one of the plurality of ways to establish a connection with the target device includes the at least one user invoking a remote application for issuing a command to the target device; Wherein the rules include: If the determined power profile is a first predetermined profile, the device establishes a connection for receiving a command when the at least one user enables the remote application to issue a command to the device, but before the command is issued; If the determined power profile is a second predetermined profile, the device establishes a connection for receiving a command based on the historical behavior of the at least one user; and If the determined power profile of the device is a third predetermined profile, the device establishes a connection for receiving a command only when the at least one user issues a command, Wherein the first predetermined profile includes: determining that the power profile of the device is any one of the following: the stored power level is equal to or higher than a first predetermined percentage, and the device receives continuous power supply through a power source; Wherein the second predetermined profile includes: determining that the power profile of the device is that the stored power level is equal to or higher than a second predetermined percentage and lower than the first predetermined percentage; Wherein the third predetermined profile includes: determining that the power profile of the device is that the stored power level is lower than the second predetermined percentage.

14. The system according to claim 13, wherein the set of parameters includes any one of the following: the location of the target device when the at least one user issues a command, the location of the remote device including the remote application, the proximity of the remote device to the target device, the time of day, the day of the week, the type of command issued, and combinations of the foregoing.

15. The system according to claim 13, wherein establishing a connection with the target device further includes powering on the target device.

16. A non-transitory computer-readable medium having executable instructions stored therein that, when executed, cause one or more processors corresponding to a system having a target device, a database, and a server to perform operations, wherein the server includes a processor and a memory in communication with the processor, and the operations include: Determining the historical behavior of at least one user, wherein determining the historical behavior is based on a set of parameters related to the device; Determining a power profile of the target device, the power profile showing the power resources available to the target device; Considering the power profile of the target device, Based on the determined power profile of the target device, considering the historical behavior data of the at least one user; and Using rules in relation to the result of the consideration to select at least one of a plurality of ways to establish a connection with the target device, wherein at least one of the selected plurality of ways includes proactively establishing a connection with the device based on the typical historical behavior of the at least one user with respect to the set of parameters related to the device so that a remote application can issue a command to the device, and wherein using rules to select at least one of a plurality of ways to establish a connection with the target device includes: determining the probability that the at least one user will issue a remote command based on the historical behavior of the at least one user related to the set of parameters; Wherein one of the plurality of ways to establish a connection with the target device includes the at least one user invoking a remote application for issuing a command to the target device; Wherein the rules include: If the determined power profile is a first predetermined profile, the device establishes a connection for receiving a command when the at least one user enables the remote application to issue a command to the device, but before the command is issued; If the determined power profile is a second predetermined profile, the device establishes a connection for receiving a command based on the historical behavior of the at least one user; and If the determined power profile of the device is a third predetermined profile, the device establishes a connection for receiving a command only when the at least one user issues a command, Wherein the first predetermined profile includes: determining that the power profile of the device is any one of the following: the stored power level is equal to or higher than a first predetermined percentage, and the device receives continuous power supply through a power source; Wherein the second predetermined profile includes: determining that the power profile of the device is that the stored power level is equal to or higher than a second predetermined percentage and lower than the first predetermined percentage; Wherein the third predetermined profile includes: determining that the power profile of the device is that the stored power level is lower than the second predetermined percentage.

17. The non-transitory computer-readable medium according to claim 16, wherein the set of parameters includes any one of the following: the location of the target device when the at least one user issues a command, the location of the remote device including the remote application, the proximity of the remote device to the target device, the time of day, the day of the week, the type of command issued, and combinations of the foregoing.

18. The non-transitory computer-readable medium according to claim 16, wherein the operation for establishing a connection with the target device further includes powering on the target device.

Images