Application-selective, vehicle-state-based API access lock

Abstract

An application-selective, vehicle-state-based API access lock is implemented by receiving a command to run an application, determining if the application is in a first group of applications, detecting if a vehicle is in a parked state in response to a determination that the application is in the first group, and preventing the application from accessing one or more application programming interfaces (APIs) based on whether the vehicle is in the parked state.

Description

BACKGROUND

[0001] A vehicle system consists of many electronic control units (ECUs). Many ECUs are capable of functioning like computers, with the ability to access externally stored data and communicate via packet-based networks. Software applications are run by ECUs to provide various services to the vehicle or a user. These software applications query vehicle information through an application programming interface (API). BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Aspects of this disclosure are best understood from the following detailed description when read in conjunction with the accompanying figures. It should be noted that, in accordance with common industry practice, various features are not drawn to scale. Indeed, the dimensions of the various features may be arbitrarily enlarged or reduced to enhance clarity of discussion. Fig. Figure 1 is a schematic diagram of a system for application-selective, vehicle-state-related API access blocking according to at least some embodiments of the present disclosure. Fig. 2 is an operation for managing API access, according to at least some embodiments of the present disclosure. Fig. 3 is an operation for application-selective, vehicle-state-related API access blocking, according to at least some embodiments of the present disclosure. Fig. Figure 4 is a block diagram of a hardware configuration for an application-selective, vehicle-state-related API access lock according to at least some embodiments of the present disclosure. DETAILED DESCRIPTION

[0003] The following disclosure contains many different embodiments for implementing various features of the provided subject matter. To simplify the present disclosure, specific examples of components, values, operations, materials, arrangements, and the like are described below. These are, of course, only examples and are not to be understood as limitations. Other components, values, operations, materials, arrangements, or the like are conceivable. Furthermore, reference numbers and / or letters may be repeated in the various examples in this disclosure. This repetition serves the purpose of simplicity and clarity and does not in itself establish a relationship between the various embodiments and / or configurations discussed.

[0004] Releasing APIs for accessing vehicle data and vehicle control to various applications, such as those from original equipment manufacturers (OEMs) or third-party vendors, carries a number of risks. Managing access to these APIs makes it possible to reduce, mitigate, or avoid these risks. While different types of applications are designed to run in-vehicle, some applications are not suitable for running while the vehicle is running, and others are not suitable for running while the vehicle is stationary.

[0005] In at least some of the embodiments described here, access to the vehicle APIs by a first group of applications is prevented or prohibited based on whether the vehicle is in motion. In at least some embodiments, access by the first group of applications is prevented or prohibited when the vehicle is parked. In at least some embodiments, access by the first group of applications is prevented or prohibited while the vehicle is not parked. In at least some embodiments, access by the first group of applications is prevented or prohibited while the vehicle is parked, and access by a second group of applications is prevented or prohibited while the vehicle is not parked.In at least some examples, a "parked" state is understood as stopped, not driven, not moving, etc.

[0006] In at least some implementation examples, appropriate management of application access to vehicle APIs based on whether the vehicle is parked enables improved vehicle security.

[0007] In at least some embodiments, the first group of applications includes those that can distract the driver's attention. In at least some embodiments, the first group includes applications for games, applications for browsing information such as news, videos, websites, etc., or any other application that uses a display to generate visual content. In at least some embodiments, the first group of applications includes those that cannot be operated by voice input. In at least some embodiments, the operability of voice input is determined by the presence or absence of VUI (Voice User Interface) operations during the previous execution of the application. In at least some embodiments, the first group of applications includes those that affect vehicle operation, such as...Applications for seat adjustment, driving mode settings, etc., as well as applications whose operation has not yet been verified. In at least some embodiments, access to the vehicle APIs by a second group of applications is prevented when the vehicle is stopped. In at least some embodiments, this second group of applications includes those configured to influence the vehicle's operation, such as acceleration, braking, steering, etc. In at least some embodiments, access to the vehicle APIs by all applications is prevented when the vehicle is stopped and an over-the-air (OTA) operation, such as a vehicle firmware update, is being performed. In at least some embodiments, access to the vehicle APIs by all applications is prevented while the vehicle is stopped and the battery is being charged.At least in some embodiments, preventing or prohibiting access to APIs while the vehicle is stopped and charging allows for improved charging efficiency, prevention of battery damage, prevention of overcrowding of the charging station, etc.

[0008] Fig. Figure 1 is a schematic diagram of a system for application-selective, vehicle-state-related API access blocking or access prevention or access prohibition, according to at least some embodiments of the present disclosure. The system for application-selective, vehicle-state-related API access blocking comprises the vehicle 100, the application 110, the API access manager 112, the APIs 114A and 114B, the sensor 116, the application database 118, and the display 108.

[0009] Vehicle 100 is a component of the application-selective, vehicle-state-based API access lock system. In at least some embodiments, Vehicle 100 takes the form of a car, truck, or other type of vehicle, such as those commonly used for passenger transport, commercial transport, etc. In at least some embodiments, Vehicle 100 includes entertainment systems, air conditioning, etc. In at least some embodiments, Vehicle 100 is configured to provide power and network connectivity. In at least some embodiments, Vehicle 100 is configured to interact with user equipment. In at least some embodiments, Vehicle 100 is configured to connect to charging stations.

[0010] Application 110 is a component of the system for application-selective, vehicle-state-based API access control. In at least some embodiments, Application 110 takes the form of a mobile app, an embedded software program, or a vehicle-specific application, such as those commonly used in mobile devices, smart home integration, wearable devices, etc. In at least some embodiments, Application 110 is configured to perform background updates, non-critical notifications, etc. In at least some embodiments, Application 110 is configured to query vehicle data, provide services to users, etc. In at least some embodiments, Application 110 is configured to submit requests to the API access manager 112 and to send and receive data via APIs.In at least some embodiments, the application 110 is configured to interact with peripheral devices such as the sensor 116 and the display 108.

[0011] The API Access Manager 112 is a component of the system for application-selective, vehicle-state-based API access control. In at least some embodiments, the API Access Manager 112 is implemented as middleware software, API gateways, security modules, etc. In at least some embodiments, the API Access Manager 112 is of the type commonly used in enterprise API management, IoT facility management, cloud services, etc. In at least some embodiments, the API Access Manager 112 is configured to log non-critical data and include debugging tools. In at least some embodiments, the API Access Manager 112 is configured to manage API access, enforce access rules, monitor vehicle state, etc.In at least some implementation examples, the API access manager 112 is configured to receive commands from applications, communicate with APIs, communicate with sensors, etc.

[0012] APIs 114A and 114B are components of the system for application-selective, vehicle-state-based API access control. In at least some implementations, APIs 114A and 114B are provided as RESTful APIs, SOAP APIs, GraphQL APIs, etc. In at least some implementations, APIs 114A and 114B are of the type commonly used in web services, mobile app backends, IoT device interfaces, etc. In at least some implementations, APIs 114A and 114B are configured to provide vehicle data, control vehicle functions, interface to applications, etc.

[0013] Sensor 116 is a component of the application-selective, vehicle-state-based API access lock system. In at least some embodiments, sensor 116 takes the form of a speedometer, accelerometer, transmission sensor, etc. In at least some embodiments, the vehicle 100 includes more than one sensor 116 to acquire more than one type of information. In at least some embodiments, sensor 116 is of the type commonly used in consumer vehicles, commercial vehicles, autonomous vehicles, industrial automation, environmental monitoring, smart home devices, etc. In at least some embodiments, sensor 116 is configured to acquire the vehicle's state, provide data to the API access manager 112, monitor the vehicle's conditions, etc.

[0014] The application database 118 is a component of the system for application-selective, vehicle-state-related API access control. In at least some embodiments, the application database 118 is implemented as one or more SQL databases, NoSQL databases, cloud-based storage solutions, etc. In at least some embodiments, the application database 118 is commonly used in enterprise data management, cloud services, mobile application backends, etc. In at least some embodiments, the application database 118 is configured to store application data, manage application states, provide data to the API access manager 112, etc. In at least some embodiments, the application database 118 is configured to interface with the API access manager 112, store application permissions, communicate with applications, etc.

[0015] Display 108 is a component of the application-selective, vehicle-state-based API access lock system. In at least some embodiments, Display 108 comprises one or more of the following: touchscreen displays, head-up displays, or infotainment screens. In at least some embodiments, Display 108 is of the type commonly used in consumer electronics, industrial control panels, smart home devices, etc. In at least some embodiments, Display 108 is configured to display application interfaces, provide user feedback, display vehicle data, etc. In at least some embodiments, Display 108 is configured to receive data from applications, interface with vehicle systems, communicate with ECUs, etc.

[0016] Fig. 2 is an operation for managing API access, according to at least some embodiments of the present disclosure. At least in some embodiments, the operational sequence provides a method for managing API access. In at least some embodiments, the method is performed by a control unit or controller of a vehicle, such as the control unit or controller 402 of the vehicle 400. Fig. 4, which is described below.

[0017] In S220, the control unit or a part thereof receives an application execution command. At least in some embodiments, the control unit receives a command to execute an application. At least in some embodiments, the control unit listens for incoming commands, validates the command format, and identifies the application to be executed. At least in some embodiments, the control unit logs the command for verification purposes and provides traceability.

[0018] In S222, the ECU, or a part thereof, determines whether an over-the-air (OTA) operation is performed. In at least some embodiments, the ECU detects an OTA operation. In at least some embodiments, the ECU checks the OTA status and verifies the requirements for the OTA operation. In at least some embodiments, in response to an ongoing OTA operation, the ECU prioritizes this operation by delaying non-critical tasks and preventing access to the vehicle APIs for other applications. In response to the ECU determining that an OTA operation is being performed, the operational sequence proceeds to API access lock in S227. If the ECU determines that no OTA operation is being performed, the operational sequence proceeds to battery charge determination in S223.

[0019] In S223, the control unit, or a part thereof, determines whether the vehicle battery is being charged. In at least some embodiments, the control unit detects an operation to charge the battery. In at least some embodiments, the control unit monitors the state of the vehicle battery to determine whether the vehicle is in a state of charge. In at least some embodiments, the control unit uses battery sensors and feedback from the charging system to determine the state of the charging process. In at least some embodiments, in response to the vehicle being in a state of charge, the control unit prevents access to the vehicle APIs for certain applications to control power distribution and prevent overloading. In response to the control unit determining that the vehicle battery is being charged, the operational sequence proceeds to the API access lock in S227.If the control unit determines that the vehicle battery is not being charged, the operating sequence in S225 switches to vehicle-state-related access authorization.

[0020] In S225, the control unit, or a part thereof, allows access based on the vehicle's state. At least in some embodiments, the control unit only allows access to the vehicle APIs when the vehicle is in predetermined states. In at least some embodiments, the control unit checks the vehicle's state using various sensors and compares the vehicle's state with rules defined for different application groups. At least in some embodiments, the control unit performs this process to ensure that applications are used safely and appropriately, to improve the user experience, and to comply with safety protocols. At least in some embodiments, the control unit performs the operation of Fig. 3, which is described below.

[0021] In S227, the control unit or a part thereof prevents access to the API. At least in some embodiments, the control unit prevents the application from accessing one or more of the vehicle's APIs in response to detecting that the vehicle is performing an OTA operation. At least in some embodiments, the control unit prevents the application from accessing one or more of the vehicle's APIs when it detects that the vehicle is performing a charging operation. At least in some embodiments, the control unit prevents access to the APIs regardless of whether the vehicle is in a parked state. At least in some embodiments, the control unit rejects all requests directed to the vehicle's APIs. At least in some embodiments, the control unit blocks the application's access to the APIs.

[0022] Fig. 3 is an operation for an application-selective, vehicle-state-related API access lock according to at least some embodiments of the present disclosure. At least in some embodiments, the operating sequence provides a method for application-selective, vehicle-state-related API access lock. In at least some embodiments, the method is performed by a control unit of a vehicle, such as the control unit 402 of vehicle 400. Fig. 4, which is described below.

[0023] In S330, the ECU, or a part thereof, determines whether the application belongs to a first group of applications. At least in some embodiments, the ECU retrieves the application ID and compares it to a database of application groups. In at least some embodiments, the ECU compares the application ID to the list of applications in the first group. Based on this comparison, the ECU categorizes the application and determines the next steps. If the ECU determines that the application belongs to the first group, it proceeds with acquiring the vehicle's state in S333. If the ECU determines that the application does not belong to the first group, it proceeds with providing API access in S336.

[0024] In S333, the control unit, or a part thereof, detects whether the vehicle is in a parked state. In at least some embodiments, the control unit detects whether the vehicle is in a parked state in response to determining that the application is in the first group. In at least some embodiments, the control unit reads data from vehicle sensors, such as the speedometer, accelerometer, transmission sensor, or any combination thereof. In at least some embodiments, the control unit analyzes this sensor data to determine whether the vehicle is in a parked state. In at least some embodiments, the detection is based on at least one speedometer, accelerometer, or transmission sensor.In at least some embodiments, the control unit identifies the vehicle's state and uses this information as a decision point for API access. In response to the determination that the vehicle is not in a parked state, the control unit prevents API access at S338. In response to the determination that the vehicle is in a parked state, the control unit enables API access at S336.

[0025] In S336, the control unit or a part thereof provides API access. In at least some embodiments, the control unit authenticates the application and grants API access tokens. In at least some embodiments, the control unit logs the access event for auditing purposes. In at least some embodiments, the control unit performs this operation to ensure that legitimate applications function correctly and to improve the user experience by maintaining system integrity.

[0026] In S338, the control unit or a part thereof prevents access to the API. In at least some embodiments, the control unit prevents the application from accessing one or more of the vehicle's APIs based on whether the vehicle is parked. In at least some embodiments, the control unit prevents the application in response to the detection that the vehicle is not parked. In at least some embodiments, the control unit prevents access to API tokens and logs the prohibition event for auditing purposes. In at least some embodiments, the control unit notifies the application of the prohibition, so that the application is aware of the prevented access. In at least some embodiments, the control unit performs this operation to increase vehicle security by protecting sensitive vehicle data and preventing unauthorized access.

[0027] In dem in Fig. In the embodiment shown in Figure 3, API access is blocked for applications in the first group of applications when it is determined that the vehicle is not in the parked state, and API access is granted when it is determined that the vehicle is in the parked state. At least in some embodiments, the first group of applications includes applications that distract the driver's attention. At least in some embodiments, the first group of applications includes applications that affect the operation of the vehicle. At least in some embodiments, the first group of applications includes applications that cannot be operated by voice input.In at least some other embodiments, API access is blocked for applications in the first group of applications when it is determined that the vehicle is in a parked state, and API access is granted when it is determined that the vehicle is not in a parked state. In at least some of these embodiments, the first group of applications includes applications that operate the vehicle. At least in some embodiments, the application-selective, vehicle-state-related API access block applies to multiple groups of applications. In at least some embodiments, API access is blocked for applications in the first group of applications when it is determined that the vehicle is not in a parked state, and API access is blocked for applications in a second group of applications when it is determined that the vehicle is in a parked state.

[0028] Fig.Figure 4 is a block diagram of a hardware configuration for an application-selective, vehicle-state-based API access lock, according to at least some embodiments of the present disclosure. The hardware configuration comprises the vehicle 400, which interacts directly or via the network 409 with the display 408. In at least some embodiments, the display 408 is a touchscreen, a microphone, a camera, or other device configured to receive tactile, acoustic, visual, etc., input. In at least some embodiments, the network 409 is an Ethernet network, a controller area network (CAN), or another wired or wireless network, or a combination thereof. At least in some embodiments, the vehicle 400 is a computer or other device that receives input or commands from the display 408.In at least some embodiments, the vehicle 400 is integrated into the display 408. In at least some embodiments, the vehicle 400 is a computer system that executes computer-readable instructions to perform operations for application-selective, vehicle-state-related API access locks.

[0029] The vehicle 400 comprises the control unit 402, the memory 404, the input / output interface 406, and the communication interface 407. In at least some embodiments, the control unit 402 comprises a processor or a programmable circuit that executes instructions to cause the processor or programmable circuit to perform operations in accordance with the instructions. In at least some embodiments, the control unit 402 comprises analog or digital programmable circuits, or any combination thereof. In at least some embodiments, the control unit 402 comprises physically separate memories or circuits that communicate with each other. In at least some embodiments, the memory 404 comprises a non-volatile, computer-readable medium capable of storing executable and non-executable data for access by the control unit 402 during the execution of the instructions.In at least some embodiments, the communication interface 407 sends and receives data from the network 409. In at least some embodiments, the input / output interface 406 establishes a connection to various input and output units, such as the display 408, via a parallel port, a serial port, a keyboard port, a mouse port, a monitor port, and the like, in order to accept commands and display information. In some embodiments, the memory 404 is located outside the vehicle 400.

[0030] The control unit 402 comprises a determination section 450, a detection section 452, and a prevention section 454. The memory 404 comprises application groups 460, vehicle condition conditions 462, and prevention parameters 464.

[0031] The determination section 450 is the circuitry or instructions of the control unit 402 configured to determine the group membership of applications. In at least some embodiments, the determination section 450 is configured to determine whether an application belongs to a first group of applications. In at least some embodiments, the determination section 450 uses the memory 404 to read or record information such as the application groups 460. In at least some embodiments, the determination section 450 includes subsections for performing additional functions, as described in the preceding flowcharts. In at least some embodiments, such subsections are referenced by a name associated with a corresponding function.

[0032] The sensing section 452 consists of the circuits or commands of the control unit 402 that are configured to sense the vehicle's state. In at least some embodiments, the sensing section 452 is configured to sense whether a vehicle is in a parked state when the application is determined to be in the first group. In at least some embodiments, the sensing section 452 uses the memory 404 to read or record information, such as vehicle state conditions 462. At least in some embodiments, the sensing section 452 includes subsections for performing additional functions, as described in the preceding flowcharts. In at least some embodiments, such subsections are referred to by a name associated with a corresponding function.

[0033] The prevention section 454 is the circuit or instructions of the control unit 402 that is / are configured for API access blocking. In at least some embodiments, the prevention section 454 is configured to prevent the application from accessing one or more application programming interfaces (APIs) of the vehicle based on whether the vehicle is in a parked state. In at least some embodiments, the prevention section 454 uses the memory 404 to read or record information, such as prevention parameters 464. In at least some embodiments, the prevention section 454 includes subsections for performing additional functions, as described in the preceding flowcharts. In at least some embodiments, such subsections are referenced by a name associated with a corresponding function.

[0034] In at least some embodiments, the vehicle is another device capable of processing logical functions to perform the operations described herein. In at least some embodiments, the control unit and the memory need not be completely separate devices, but may share a circuit or one or more computer-readable media. In at least some embodiments, the memory comprises a hard disk on which both the computer-executable instructions and the data accessed by the control unit are stored, and the control unit comprises a combination of a central processing unit (CPU) and a working memory (RAM) into which the computer-executable instructions can be copied, in whole or in part, for execution by the CPU during the performance of the operations described herein.

[0035] In at least some embodiments where the vehicle is a computer, a program installed in the computer can cause the computer to function or perform operations as described herein. In at least some embodiments, such a program is executable by a processor to cause the computer to perform certain operations associated with some or all of the blocks of the flowcharts and block diagrams described herein.

[0036] At least some embodiments are described with reference to flowcharts and block diagrams, the blocks of which represent (1) steps of processes in which operations are performed, or (2) sections of hardware responsible for performing operations. In at least some embodiments, certain steps and sections are implemented by dedicated circuits, programmable circuits provided with computer-readable instructions stored on computer-readable media, and / or processors provided with computer-readable instructions stored on computer-readable media. In at least some embodiments, the dedicated circuit comprises digital and / or analog hardware circuits and includes integrated circuits (ICs) and / or discrete circuits.In at least some embodiments, the programmable circuit includes reconfigurable hardware circuits that feature logical AND, OR, XOR, NAND, NOR and other logical operations, flip-flops, registers, memory elements, etc., such as field-programmable gate arrays (FPGAs), programmable logic arrays (PLAs), etc.

[0037] In at least some embodiments, the computer-readable medium comprises a physical device capable of receiving and storing instructions for use by an instruction-executing device. In some embodiments, the computer-readable medium includes, for example, but not exclusively, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof.A non-exhaustive list of more specific examples of computer-readable medium includes the following: a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable read-only memory for compact discs (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically coded device such as punched cards or raised structures in a groove with instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable medium, as used here, is not to be understood as consisting of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., a cable).Light pulses traveling through a fiber optic cable), or electrical signals transmitted through a wire.

[0038] Although exemplary embodiments of the present invention have been described, the technical scope of the claimed subject matter is not limited to the exemplary embodiments described above. Those skilled in the art will understand that various modifications and improvements to the exemplary embodiments described above are possible. It is also clear to those skilled in the art from the scope of the claims that the exemplary embodiments with such modifications or improvements are included in the technical scope of the invention.

[0039] The operations, methods, steps, and stages of any process performed by a device, system, program, or procedure, as shown in the claims, embodiments, or diagrams, may be performed in any order, provided that the order is not specified by "before," "before," or the like, and provided that the result of an earlier process is not used in a later process. Even if the process flow is described in the claims, embodiments, or diagrams using terms such as "first" or "next," such a description does not necessarily mean that the processes must be performed in the described order.

[0040] The application-selective, vehicle-state-based API access lock is implemented by receiving a command to execute an application, determining whether the application is in a first group of applications, in response to the determination that the application is in the first group, detecting whether a vehicle is in a parked state, and denying the application access to one or more application programming interfaces (APIs) based on whether the vehicle is in the parked state.

[0041] In at least some embodiments, preventing includes preventing the first group of applications in response to the detection that the vehicle is not in the parked state. In at least some embodiments, the first group of applications includes applications that distract the driver's attention. In at least some embodiments, the first group of applications includes applications that affect the operation of the vehicle. In at least some embodiments, the first group of applications includes applications that cannot be operated by voice input. In at least some embodiments, prohibiting includes preventing the first group of applications in response to the detection that the vehicle is in the parked state. In at least some embodiments, the first group of applications includes applications involving vehicle operation.In at least some embodiments, the detection is based on at least one speedometer, accelerometer, or transmission sensor. In at least some embodiments, an application-selective, vehicle-state-based API access lock is further implemented by detecting an OTA operation and preventing the application from accessing one or more of the vehicle's APIs in response to the detection that the vehicle is in a parked state and from performing an OTA operation. In at least some embodiments, the application-selective, vehicle-state-based API access lock is further implemented by detecting a battery charging process and preventing the application from accessing one or more of the vehicle's APIs in response to the detection that the vehicle is in a parked state and from performing a charging process.

[0042] Application-selective, vehicle-state-based API access lock is implemented by receiving a command to run an application, determining if the application is in a first group of applications, detecting if a vehicle is in a parked state in response to determining that the application is in the first group, and preventing the application from accessing one or more of the vehicle's application programming interfaces (APIs) based on whether the vehicle is in the parked state.

[0043] In at least some embodiments, the prevention includes preventing the first group of applications in response to the detection that the vehicle is not in the parked state. In at least some embodiments, the first group of applications includes applications that distract the driver's attention. In at least some embodiments, the prohibition includes preventing the first group of applications in response to the detection that the vehicle is in the parked state. In at least some embodiments, the first group of applications includes applications involving vehicle operation.

[0044] The application-selective, vehicle-state-based API access lock is implemented by an electronic control unit (ECU) containing circuitry configured to perform operations that include: receiving a command to run an application, detecting whether the application is in a first group of applications, detecting whether a vehicle is in a parked state in response to the detection that the application is in the first group, and preventing the application from accessing one or more of the vehicle's application programming interfaces (APIs) based on whether the vehicle is in the parked state.

[0045] In at least some embodiments, the prevention includes preventing the first group of applications in response to the detection that the vehicle is not in the parked state. In at least some embodiments, the first group of applications includes applications that distract the driver's attention. In at least some embodiments, the prohibition includes preventing the first group of applications in response to the detection that the vehicle is in the parked state. In at least some embodiments, the first group of applications includes applications involving vehicle operation.

[0046] The foregoing outlines features of several embodiments to help the person skilled in the art better understand the aspects of this disclosure. The person skilled in the art should recognize that this disclosure can readily be used as a basis for developing or modifying other processes and structures to achieve the same purposes and / or the same advantages as the embodiments presented here. The person skilled in the art should also recognize that such equivalent designs do not deviate from the fundamental concept and scope of this disclosure and that various modifications, substitutions, and adaptations are possible without deviating from the fundamental concept and scope of this disclosure.

Claims

[1] Computer program that causes one or more processors to perform operations that exhibit: Receiving a command to execute an application; Determine whether the application is in a first group of applications; Determining whether a vehicle is in a parked state, in response to a determination that the application is in the first group; and Preventing the application from accessing one or more of the vehicle's application programming interfaces (APIs) based on whether the vehicle is in the parked state. [2] Computer program according to claim 1, wherein the prevention comprises preventing the first group of applications in response to the detection that the vehicle is not in the parked state. [3] Computer program according to claim 2, wherein the first group of applications comprises applications that distract the attention of a driver. [4] Computer program according to claim 2 or 3, wherein the first group of applications includes applications that influence a vehicle operation. [5] Computer program according to any one of claims 2 to 4, wherein the first group of applications includes applications that cannot be operated by voice input. [6] Computer program according to claim 1, wherein the prevention comprises preventing the first group of applications in response to the detection that the vehicle is in the parked state. [7] Computer program according to claim 6, wherein the first group of applications includes such applications with a vehicle operation. [8] Computer program according to any one of claims 1 to 7, wherein the detection is based on at least one speedometer, accelerometer or gear sensor. [9] Methods, with: Receiving a command to execute an application; Determine whether the application is in a first group of applications; Determining whether a vehicle is in a parked state, in response to a determination that the application is in the first group; and Preventing the application from accessing one or more of the vehicle's application programming interfaces (APIs) based on whether the vehicle is in the parked state. [10] Institution, with: a control unit that includes a circuit configured to perform operations with: Receiving a command to execute an application, determining whether the application is in a first group of applications, Determining whether a vehicle is in a parked state, in response to a determination that the application is in the first group, and Preventing the application from accessing one or more of the vehicle's application programming interfaces (APIs) based on whether the vehicle is in the parked state.

Images