Method, apparatus and computer program product for API access barring

Abstract

Application selective vehicle state-based API access barring is implemented by receiving a command for executing an application; determining whether the application is in a first group of applications; detecting whether the vehicle is in a parked state in response to determining that the application is in the first group; and prohibiting access of the application to one or more application programming interfaces (APIs) of the vehicle based on whether the vehicle is in the parked state.

Description

Technical Field

[0001] This disclosure relates to methods, apparatus, and computer program products for selective, vehicle-state-based API access blocking for applications. Background Technology

[0002] A vehicle system consists of numerous ECUs (Electronic Controller Units). Many ECUs function as computers, capable of accessing externally stored data and communicating via packet-based networks. Software applications, executed by the ECUs, provide various services to the vehicle or its users. These applications request vehicle information via Application Programming Interfaces (APIs). Summary of the Invention

[0003] This disclosure provides methods, apparatus, and computer program products for application-selective, vehicle-state-based API access prohibition.

[0004] According to one embodiment, a method for API access denial is provided. The method includes: receiving a command for executing an application; determining whether the application is in a first group of applications; detecting whether a vehicle is in a parked state in response to determining that the application is in the first group; and based on whether the vehicle is in a parked state, denying the application access to one or more application programming interfaces (APIs) of the vehicle.

[0005] According to another embodiment, an apparatus for API access blocking is provided. The apparatus includes a controller comprising circuitry configured to perform actions including: receiving a command to execute an application; determining whether the application is in a first group; detecting whether the vehicle is in a parked state in response to determining that the application is in the first group; and blocking the application from accessing one or more application programming interfaces (APIs) of the vehicle based on whether the vehicle is in a parked state.

[0006] According to yet another embodiment, a computer program product is provided. The computer program product includes a computer program that causes one or more processors to perform actions including: receiving a command to execute an application; determining whether the application is in a first group of applications; detecting whether a vehicle is in a parked state in response to determining that the application is in the first group; and, based on whether the vehicle is in a parked state, prohibiting the application from accessing one or more application programming interfaces (APIs) of the vehicle.

[0007] According to this disclosure, methods, apparatus, and computer program products can be provided for selective API access prohibition based on vehicle status for applications. Attached Figure Description

[0008] The present disclosure will be best understood by reading it in conjunction with the accompanying drawings and the following detailed description. It should be noted that, according to industry standard practice, the various features are not depicted to a fixed scale. In fact, the dimensions of the various features can be arbitrarily increased or decreased for clarity of discussion.

[0009] Figure 1 This is a schematic diagram of a system for application-selective, vehicle-state-based API access blocking according to at least some embodiments of this disclosure.

[0010] Figure 2 This is an action flow for API access management according to at least some embodiments of this disclosure.

[0011] Figure 3 This is an action flow for application-selective, vehicle-state-based API access prohibition, according to at least some embodiments of this disclosure.

[0012] Figure 4 This is a block diagram of the hardware configuration for application-selective, vehicle-state-based API access prohibition, according to at least some embodiments of this disclosure. Detailed Implementation

[0013] The following disclosure provides many different implementations or examples for carrying out various features of the provided subject matter. Specific examples of constituent elements, values, actions, materials, configurations, etc., are described below to simplify this disclosure. These are, of course, merely examples and are not intended to be limiting. Other constituent elements, values, actions, materials, configurations, etc., may be considered. Furthermore, reference numerals and / or text may be repeated in various instances of this disclosure. This repetition is for simplicity and clarity and does not in itself indicate a relationship between the various implementations and / or configurations discussed.

[0014] Various risks arise when APIs used for accessing vehicle data and vehicle control are exposed to different applications, such as Original Equipment Manufacturer (OEM) applications or third-party applications. Managing such access to APIs can reduce, mitigate, or avoid these risks. While various types of applications are designed to function properly in a vehicle, some applications are not suitable for operation while the vehicle is in motion, and others are not suitable for operation while the vehicle is stationary.

[0015] In at least some embodiments described in this specification, access from the first group of applications to the vehicle API is blocked based on whether the vehicle is moving. In at least some embodiments, access from the first group of applications is blocked while the vehicle is parked. In at least some embodiments, access from the first group of applications is blocked while the vehicle is not parked. In at least some embodiments, access from the first group of applications is blocked while the vehicle is parked, and access from the second group of applications is blocked while the vehicle is not parked. In at least some embodiments, "parked" is understood as stopped, not driven, not moving, etc.

[0016] In at least some implementations, properly managing access from the application to the vehicle API based on whether the vehicle is parked can improve vehicle security.

[0017] In at least some embodiments, the first group of applications includes applications that may distract the driver. In at least some embodiments, the first group of applications includes game applications, applications for browsing information such as news, videos, and websites, or any other applications that utilize a display device to generate visual content. In at least some embodiments, the first group of applications includes applications that cannot be activated by voice input. In at least some embodiments, the activatability of voice input is determined based on the presence or absence of VUI (Voice User Interface) actions during the application's previous execution. In at least some embodiments, the first group of applications includes applications that affect vehicle actions, such as applications for seat adjustment and applications for setting driving modes, as well as applications whose actions have not yet been verified. In at least some embodiments, access to the vehicle API from the second group of applications is prohibited while the vehicle is stationary. In at least some embodiments, the second group of applications includes applications configured to affect vehicle actions such as acceleration, braking, and steering. In at least some embodiments, access to the vehicle API from all applications is prohibited during OTA (Over-The-Air) actions, such as vehicle firmware updates, while the vehicle is stationary. In at least some implementations, access to the vehicle API from all applications is prohibited while the vehicle is stopped and receiving battery charging. In at least some implementations, prohibiting API access while the vehicle is stopped and charging can improve charging efficiency, prevent battery degradation, and prevent excessive occupancy of charging stations.

[0018] Figure 1This is a schematic diagram of a system for application-selective vehicle state-based API access prohibition according to at least some embodiments of the present disclosure. The system for application-selective vehicle state-based API access prohibition includes a vehicle 100, an application 110, an API access manager 112, APIs 114A and 114B, a sensor 116, an application database 118, and a display device 108.

[0019] Vehicle 100 is a component of a system for selectively prohibiting API access based on vehicle state for applications. In at least some embodiments, vehicle 100 is any other type of vehicle, such as a car, truck, or vehicle generally used for personal transportation, commercial transportation, etc. In at least some embodiments, vehicle 100 includes an entertainment system, air conditioning controls, 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 a charging station.

[0020] Application 110 is a component of a system for selectively prohibiting API access based on vehicle status. In at least some embodiments, application 110 is in the form of a mobile application, embedded software program, or a vehicle-specific application, such as a program generally used in mobile devices, smart home integration, or wearable devices. In at least some embodiments, application 110 is configured to perform background updates, low-importance notifications, etc. In at least some embodiments, application 110 is configured to request vehicle data and provide services to the user, etc. In at least some embodiments, application 110 is configured to send requests to API access manager 112 and send and receive data via API. In at least some embodiments, application 110 is configured to interact with peripheral devices such as sensor 116 and display device 108.

[0021] API Access Manager 112 is a component of a system for selectively prohibiting API access based on vehicle status for applications. In at least some embodiments, API Access Manager 112 is implemented as middleware software, an API gateway, a security module, etc. In at least some embodiments, API Access Manager 112 is a type of manager commonly used in enterprise API management, IoT (Internet of Things) device management, cloud services, etc. In at least some embodiments, API Access Manager 112 is configured to log low-importance data, including debugging tools. In at least some embodiments, API Access Manager 112 is configured to manage API access, enforce access rules, and monitor vehicle status, etc. In at least some embodiments, API Access Manager 112 is configured to receive commands from applications, communicate with APIs, and interact with sensors, etc.

[0022] APIs 114A and 114B are components of a system for selectively prohibiting vehicle-state-based API access for applications. In at least some embodiments, APIs 114A and 114B are provided as RESTful APIs, SOAP APIs, GraphQL APIs, etc. In at least some embodiments, APIs 114A and 114B are types of APIs commonly used in web services, mobile application backends, and IoT device interfaces. In at least some embodiments, APIs 114A and 114B are configured to provide vehicle data, control vehicle functions, interact with applications, etc.

[0023] Sensor 116 is a component of a system for selectively prohibiting API access based on vehicle status for applications. In at least some embodiments, sensor 116 is in the form of a speedometer, accelerometer, transmission gear sensor, etc. In at least some embodiments, vehicle 100 includes two or more sensors 116 to detect two or more types of information. In at least some embodiments, sensor 116 is a type of sensor generally 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 detect vehicle status, provide data to API access manager 112, monitor vehicle status, etc.

[0024] Application database 118 is a component of a system for selectively denying API access based on vehicle status for applications. In at least some embodiments, application database 118 is implemented as one or more SQL databases, NoSQL databases, cloud-based storage solutions, etc. In at least some embodiments, application database 118 is generally used in enterprise data management, cloud services, mobile application backends, etc. In at least some embodiments, application database 118 is configured to store application data, manage application status, provide data to API access manager 112, etc. In at least some embodiments, application database 118 is configured to interact with API access manager 112, store application licenses, communicate with applications, etc.

[0025] Display device 108 is a component of a system for selectively prohibiting API access based on vehicle status for applications. In at least some embodiments, display device 108 includes one or more of a touchscreen display, head-up display, or infotainment screen. In at least some embodiments, display device 108 is a type of display device commonly used in consumer-facing electronic devices, industrial control panels, smart home devices, etc. In at least some embodiments, display device 108 is configured to display application programming interfaces, provide user feedback, display vehicle data, etc. In at least some embodiments, display device 108 is configured to receive data from applications, interact with vehicle systems, communicate with ECUs, etc.

[0026] Figure 2 This disclosure describes an action flow for API access management according to at least some embodiments. In at least some embodiments, the action flow provides a method for API access management. In at least some embodiments, this method is described later. Figure 4 The vehicle controller 400, 402, and other vehicle controllers are used to execute the commands.

[0027] In S220, the controller or a portion thereof receives an application execution command. In at least some embodiments, the controller receives a command for executing an application. In at least some embodiments, the controller listens for incoming commands, verifies the command format, and identifies the application that should be executed. In at least some embodiments, the controller records the commands for monitoring purposes and provides traceability.

[0028] In S222, the controller or a portion thereof determines whether an over-the-air (OTA) download is being performed. In at least some embodiments, the controller detects the OTA action. In at least some embodiments, the controller checks the OTA status, verifying the requirements for the OTA action. In at least some embodiments, in response to an OTA action in progress, the controller delays low-priority tasks and prohibits access to the vehicle API for other applications, thereby prioritizing the action. In response to the controller determining that an OTA action is being performed, the process flow proceeds to S227, API access prohibition. In response to the controller determining that no OTA action is being performed, the process flow proceeds to S223, battery charging determination.

[0029] In S223, the controller or a portion thereof determines whether the vehicle battery is charging. In at least some embodiments, the controller detects battery charging activity. In at least some embodiments, the controller monitors the vehicle's battery status and detects whether the vehicle is charging. In at least some embodiments, the controller uses feedback from battery sensors and the charging system to determine the charging status. In at least some embodiments, in response to the vehicle being charging, the controller prohibits access to the vehicle API for specific applications in order to manage power distribution and prevent overload. In response to the controller determining that the vehicle battery is charging, the process proceeds to S227, API access prohibition. In response to the controller determining that the vehicle battery is not charging, the process proceeds to S225, vehicle status-based access permission.

[0030] In S225, the controller, or a portion thereof, grants access based on vehicle state. In at least some embodiments, the controller only grants access to the vehicle API when the vehicle is in a specified state. In at least some embodiments, the controller uses various sensors to check the vehicle state and compares the vehicle state against rules defined for different application groups. In at least some embodiments, the controller performs this process to ensure the safe and appropriate use of the application, thereby improving the user experience while maintaining security protocols. In at least some embodiments, the controller performs the following descriptions. Figure 3 The action flow.

[0031] In S227, the controller or a portion thereof disables API access. In at least some embodiments, the controller disables application access to one or more vehicle APIs in response to detecting that the vehicle is performing an OTA (Over-The-Air) operation. In at least some embodiments, the controller disables application access to one or more vehicle APIs in response to detecting that the vehicle is performing a charging operation. In at least some embodiments, the controller disables API access regardless of whether the vehicle is parked. In at least some embodiments, the controller rejects requests for vehicle-oriented APIs. In at least some embodiments, the controller blocks application access to APIs.

[0032] Figure 3 This disclosure describes an action flow for application-selective, vehicle-state-based API access blocking, according to at least some embodiments. In at least some embodiments, the action flow provides a method for application-selective, vehicle-state-based API access blocking. In at least some embodiments, this method is described later. Figure 4 The vehicle controller 400, 402, and other vehicle controllers are used to execute the commands.

[0033] In S330, the controller or a portion thereof determines whether an application is in the first group of applications. In at least some embodiments, the controller retrieves the application ID and verifies it against a database of application groups. In at least some embodiments, the controller compares the application ID with a list of applications in the first group. In at least some embodiments, based on this comparison, the controller categorizes the application and determines the next step. In response to the controller determining that the application is in the first group, the controller proceeds to vehicle state detection in S333. In response to determining that the application is not in the first group, the controller proceeds to API access provision in S336.

[0034] In S333, the controller or a portion thereof detects whether the vehicle is in a parked state. In at least some embodiments, the controller detects whether the vehicle is in a parked state in response to a determination made by the application in a first set of conditions. In at least some embodiments, the controller reads data from vehicle sensors such as a speedometer, accelerometer, transmission gear position sensor, or any combination thereof. In at least some embodiments, the controller analyzes the sensor data and determines whether the vehicle is in a parked state. In at least some embodiments, the above detection is based on at least one of a speedometer, accelerometer, or transmission gear position sensor. In at least some embodiments, the controller identifies the vehicle state and uses this information as a determination point for API access. In response to a determination that the vehicle is not in a parked state, the controller proceeds to S338 to prohibit API access. In response to a determination that the vehicle is in a parked state, the controller proceeds to S336 to provide API access.

[0035] In S336, the controller or a portion thereof provides API access. In at least some embodiments, the controller authenticates the application and grants it an API access token. In at least some embodiments, the controller logs access events for monitoring purposes. In at least some embodiments, the controller performs this action to ensure that legitimate applications function properly and to maintain system integrity, thereby improving the user experience.

[0036] In S338, the controller or a portion thereof blocks API access. In at least some embodiments, the controller blocks an application's access to one or more APIs of the vehicle based on whether the vehicle is parked. In at least some embodiments, the controller blocks the application in response to detecting that the vehicle is not parked. In at least some embodiments, the controller rejects the API access token and logs the blocking event for monitoring purposes. In at least some embodiments, the controller notifies the application of the blocking, resulting in the application identifying the blocked access. In at least some embodiments, the controller performs this action to improve vehicle security by protecting vehicle data that should be handled with care and preventing unauthorized access.

[0037] exist Figure 3In the illustrated embodiments, in response to a determination that the vehicle is not in a parked state, applications in the first group of applications are denied API access; in response to a determination that the vehicle is in a parked state, applications in the first group of applications are granted API access. In at least some of these embodiments, the first group of applications includes applications that distract the driver. In at least some embodiments, the first group of applications includes applications that affect vehicle movement. In at least some embodiments, the first group of applications includes applications that cannot be operated via voice input. In at least some other embodiments, in response to a determination that the vehicle is in a parked state, applications in the first group of applications are denied API access; in response to a determination that the vehicle is not in a parked state, applications in the first group of applications are granted API access. In at least some of these embodiments, the first group of applications includes applications that accompany vehicle movement. In at least some embodiments, selective vehicle state-based API access denial is applied to multiple application groups. In at least some embodiments, in response to a determination that the vehicle is not in a parked state, applications in the first group of applications are denied API access; in response to a determination that the vehicle is in a parked state, applications in the second group of applications are denied API access.

[0038] Figure 4 This is a block diagram of a hardware configuration for application-selective, vehicle-state-based API access prohibition according to at least some embodiments of this disclosure. The hardware configuration includes a vehicle 400 that interacts directly or via a network 409 with a display device 408. In at least some embodiments, the display device 408 is a touchscreen, microphone, camera, or any other device configured to detect tactile, auditory, visual, or other inputs. In at least some embodiments, the network 409 is an Ethernet, a Controller Area Network (CAN), or any other wired or wireless network, or a combination thereof. In at least some embodiments, the vehicle 400 is a computer or other computing device that receives input or commands from the display device 408. In at least some embodiments, the vehicle 400 and the display device 408 are integrated. In at least some embodiments, the vehicle 400 is a computer system that executes computer-readable instructions for performing actions for application-selective, vehicle-state-based API access prohibition.

[0039] Vehicle 400 includes a controller 402, a storage device 404, an input / output interface 406, and a communication interface 407. In at least some embodiments, the controller 402 includes a processor or programmable circuitry that executes instructions, causing the processor or programmable circuitry to perform actions according to the instructions. In at least some embodiments, the controller 402 includes analog or digital programmable circuitry or any combination thereof. In at least some embodiments, the controller 402 includes physically separate storage devices or circuitry that interact via communication. In at least some embodiments, the storage device 404 includes a non-volatile computer-readable medium capable of storing executable and non-executable data for access by the controller 402 during instruction execution. In at least some embodiments, the communication interface 407 sends and receives data from a network 409. In at least some embodiments, the input / output interface 406 is connected to various input / output units such as a display device 408 via parallel ports, serial ports, keyboard ports, mouse ports, monitor ports, etc., and receives commands and current information. In some embodiments, the storage device 404 is located outside the vehicle 400.

[0040] The controller 402 includes a decision unit 450, a detection unit 452, and an prohibition unit 454. The storage device 404 includes an application program group 460, vehicle status conditions 462, and prohibition parameters 464.

[0041] The determination unit 450 is a circuit or indication of a controller 402 configured to determine the membership of an application. In at least some embodiments, the determination unit 450 is configured to determine whether an application is in a first group of applications. In at least some embodiments, the determination unit 450 utilizes a storage device 404 to read or record information such as application group 460. In at least some embodiments, as explained in the flowcharts above, the determination unit 450 includes a sub-section for performing additional functions. In at least some embodiments, such a sub-section is referred to by a name associated with a corresponding function.

[0042] The detection unit 452 is a circuit or indicator configured to perform vehicle status detection on the controller 402. In at least some embodiments, the detection unit 452 is configured to detect whether the vehicle is in a parked state in response to determining that an application is in the first group. In at least some embodiments, the detection unit 452 utilizes the storage device 404 to read or record information such as vehicle status conditions 462. In at least some embodiments, as illustrated in the flowcharts above, the detection unit 452 includes sub-sections for performing additional functions. In at least some embodiments, such sub-sections are referred to by names associated with corresponding functions.

[0043] The prohibition unit 454 is a circuit or indication of a controller 402 configured to prohibit API access. In at least some embodiments, the prohibition unit 454 is configured to prohibit an application from accessing one or more application programming interfaces (APIs) of the vehicle based on whether the vehicle is parked. In at least some embodiments, the prohibition unit 454 utilizes a storage device 404 to read or record information such as prohibition parameters 464. In at least some embodiments, as illustrated in the flowcharts above, the prohibition unit 454 includes sub-sections for performing additional functions. In at least some embodiments, such sub-sections are referred to by names associated with corresponding functions.

[0044] In at least some embodiments, the vehicle is another device capable of processing logical functions to perform the actions described herein. In at least some embodiments, the controller and storage device need not be completely separate devices, but rather share circuitry or one or more computer-readable media. In at least some embodiments, the storage device includes a hard disk drive storing both computer-executable instructions and data accessed by the controller, and the controller includes a combination of a central processing unit and RAM (Random Access Memory), wherein all or part of the computer-executable instructions can be copied for execution by the CPU in the performance of the actions described herein.

[0045] In at least some embodiments where the vehicle is a computer, a program installed on the computer enables the computer to function as a device in the embodiments described herein, or enables the computer to perform actions associated with the device. In at least some embodiments, such a program can be executed by a processor to cause the computer to perform specific actions associated with some or all of the functional blocks of the flowcharts and block diagrams described herein.

[0046] In at least some embodiments, the description is made with reference to flowcharts and block diagrams, which represent (1) steps of processing to perform an action or (2) portions of hardware responsible for performing the action. In at least some embodiments, specific steps and portions are implemented by dedicated circuitry, programmable circuitry supplied with computer-readable instructions stored on a computer-readable medium, and / or a processor supplied with computer-readable instructions stored on a computer-readable medium. In at least some embodiments, the dedicated circuitry includes digital and / or analog hardware circuitry, including integrated circuits (ICs) and / or discrete circuitry. In at least some embodiments, the programmable circuitry includes reconfigurable hardware circuitry, which includes 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.

[0047] In at least some embodiments, a computer-readable medium is a tangible means capable of holding and storing instructions for use by an instruction execution apparatus. In some embodiments, a computer-readable medium includes, for example, 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, but is not limited thereto. A more specific list of exemplary examples of computer-readable media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, punch cards, or mechanically encoded means having protrusions in a slot on which instructions are recorded, and any suitable combination thereof. The computer-readable medium used in this specification should not be construed as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted via wires, which are themselves temporary signals.

[0048] The embodiments of the present invention have been described above, but the technical scope described in the claims is not limited to the above embodiments. Those skilled in the art should understand that various modifications and improvements can be made to the above embodiments. Furthermore, based on the claims, those skilled in the art should understand that forms with such modifications or improvements are also included within the technical scope of the present invention.

[0049] As long as terms like "before" or "formerly" are not used to indicate sequence, and as long as output from previous processes is not used in subsequent processes, the actions, processes, steps, and stages of each process performed by the apparatus, system, program, and method shown in the claims, embodiments, or drawings can be executed in any order. It should be noted that even if the processing flow is described using phrases like "firstly" or "next" in the claims, embodiments, or drawings, this description does not necessarily mean that the processes must be performed in the order described.

[0050] Application-selective, vehicle-state-based API access denial is enforced by: receiving commands to execute the application; determining whether the application is in the first group of applications; detecting whether the vehicle is in a parked state in response to determining that the application is in the first group; and, based on whether the vehicle is in a parked state, denying the application access to one or more application programming interfaces (APIs) of the vehicle.

[0051] In at least some embodiments, the prohibition includes prohibiting a first group of applications in response to detecting that the vehicle is not in a parked state. In at least some embodiments, the first group of applications includes applications that distract the driver. In at least some embodiments, the first group of applications includes applications that affect vehicle movement. In at least some embodiments, the first group of applications includes applications that cannot be operated via voice input. In at least some embodiments, the prohibition includes prohibiting a first group of applications in response to detecting that the vehicle is in a parked state. In at least some embodiments, the first group of applications includes applications that accompany vehicle movement. In at least some embodiments, the detection is based on at least one of a speedometer, accelerometer, or transmission gear position sensor. In at least some embodiments, application-selective vehicle state-based API access prohibition is further implemented by: detecting OTA (Over-The-Air) actions; and prohibiting applications from accessing one or more APIs of the vehicle in response to detecting that the vehicle is in a parked state and performing an OTA action. In at least some embodiments, application-selective vehicle state-based API access prohibition is further implemented by: detecting battery charging actions; and prohibiting applications from accessing one or more APIs of the vehicle in response to detecting that the vehicle is in a parked state and performing a charging action.

[0052] Application-selective, vehicle-state-based API access denial is enforced by: receiving commands to execute the application; determining whether the application is in the first group of applications; detecting whether the vehicle is in a parked state in response to determining that the application is in the first group; and, based on whether the vehicle is in a parked state, denying the application access to one or more application programming interfaces (APIs) of the vehicle.

[0053] In at least some embodiments, the aforementioned prohibition includes a first group of applications being prohibited in response to detecting that the vehicle is not in a parked state. In at least some embodiments, the first group of applications includes applications that distract the driver. In at least some embodiments, the aforementioned prohibition includes a first group of applications being prohibited in response to detecting that the vehicle is in a parked state. In at least some embodiments, the first group of applications includes applications that accompany vehicle movements.

[0054] Application-selective, vehicle-state-based API access prohibition is enforced by a controller including circuitry configured to perform actions including: receiving a command to execute an application; determining whether the application is in a first group of applications; detecting whether the vehicle is in a parked state in response to determining that the application is in the first group; and prohibiting the application from accessing one or more application programming interfaces (APIs) of the vehicle based on whether the vehicle is in a parked state.

[0055] In at least some embodiments, the aforementioned prohibition includes a first group of applications being prohibited in response to detecting that the vehicle is not in a parked state. In at least some embodiments, the first group of applications includes applications that distract the driver. In at least some embodiments, the aforementioned prohibition includes a first group of applications being prohibited in response to detecting that the vehicle is in a parked state. In at least some embodiments, the first group of applications includes applications that accompany vehicle movements.

[0056] The foregoing summary illustrates some features of embodiments to enable those skilled in the art to better understand the solutions of this disclosure. Those skilled in the art should understand that this disclosure can be readily used as a basis for designing or modifying other processes and structures for performing the same purpose and / or for achieving the same advantages of the embodiments described herein. Those skilled in the art should also understand that such equivalent configurations do not depart from the spirit and scope of this disclosure, and that various changes, substitutions, and alterations can be made to this specification without departing from the spirit and scope of this disclosure. Alternatively, a computer program product including the computer program of the above embodiments may be stored on a storage medium or distributed via a communication line.

Claims

1. A computer program product comprising a computer program that causes one or more processors to perform actions, the actions including: Receive commands for executing the application; Determine whether the application is in the first group of applications; In response to determining that the application is in the first group, the system detects whether the vehicle is in a parked state; as well as Based on whether the vehicle is in the parked state, the application is prohibited from accessing one or more application programming interface (API) ports of the vehicle.

2. The computer program product according to claim 1, wherein, The prohibition includes a first group of prohibitions that occur in response to detecting that the vehicle is not in the parked state.

3. The computer program product according to claim 2, wherein, The first group of applications includes applications that distract the driver.

4. The computer program product according to claim 2 or 3, wherein, The first group of applications includes applications that affect vehicle movement.

5. The computer program product according to any one of claims 2 to 4, wherein, The first group of applications includes those that cannot be activated via voice input.

6. The computer program product according to claim 1, wherein, The prohibition includes a first group of prohibitions that occur in response to detecting that the vehicle is in the parked state.

7. The computer program product according to claim 6, wherein, The first group of applications includes applications that accompany vehicle movements.

8. The computer program product according to any one of claims 1 to 7, wherein, The detection is based on at least one of a speedometer, accelerometer, or transmission gear position sensor.

9. The computer program product according to any one of claims 1 to 8, wherein, The action also includes: Detecting over-the-air (OTA) download actions; and In response to the detection that the vehicle is performing an OTA (Over-The-Air) operation, the application is prohibited from accessing one or more APIs of the vehicle.

10. The computer program product according to any one of claims 1 to 9, wherein, The action also includes: Detecting battery charging action; and In response to the detection that the vehicle is charging, the application is prohibited from accessing one or more APIs of the vehicle.

11. A method for prohibiting access to an application programming interface (API), comprising: Receive commands for executing the application; Determine whether the application is in the first group of applications; In response to the determination that the application is in the first group, the system detects whether the vehicle is in a parked state; as well as Based on whether the vehicle is in the parked state, the application is prohibited from accessing one or more application programming interface (API) ports of the vehicle.

12. The method according to claim 11, wherein, The prohibition includes a first group of prohibitions that occur in response to detecting that the vehicle is not in the parked state.

13. The method according to claim 12, wherein, The first group of applications includes applications that distract the driver.

14. The method according to claim 11, wherein, The prohibition includes a first group of prohibitions that occur in response to detecting that the vehicle is in the parked state.

15. The method according to claim 14, wherein, The first group of applications includes applications that accompany vehicle movements.

16. An apparatus for prohibiting access to an application programming interface (API), comprising a controller including circuitry configured to perform the following actions: Receive commands for executing the application; Whether the application is in the first group is determined; In response to the determination that the application is in the first group, the system detects whether the vehicle is in a parked state; as well as Based on whether the vehicle is in the parked state, the application is prohibited from accessing one or more application programming interface (API) ports of the vehicle.

17. The apparatus according to claim 16, wherein, The prohibition includes a first group of prohibitions that occur in response to detecting that the vehicle is not in the parked state.

18. The apparatus according to claim 17, wherein, The first group of applications includes applications that distract the driver.

19. The apparatus according to claim 16, wherein, The prohibition includes a first group of prohibitions that occur in response to detecting that the vehicle is in the parked state.

20. The apparatus according to claim 19, wherein, The first group of applications includes applications that accompany vehicle movements.

Images