Access control device and access control method

Abstract

In the present invention, an access control unit (10), if acceptance determination units (211, 212) have determined that acceptance is permissible, imparts to an API-using application (30) a right to access a vehicle API that provides a function of a start confirmation unit (222). if the start confirmation unit has confirmed a user's intention to start, the access control unit imparts to the API-using application a right to access a vehicle API that is necessary for providing an intended service.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2022-156690, filed with the Japan Patent Office on September 29, 2022, the entire contents of which are incorporated herein by reference. [Technical Field]

[0002] The present disclosure relates to a technology for providing services using vehicle functions. [Background technology]

[0003] Patent Document 1 describes a system that includes a travel assistance device and an in-vehicle terminal, and in which a plurality of vehicles travel in a formation according to a plan generated by the travel assistance device.

[0004] In a platooning system, an in-vehicle device repeatedly transmits vehicle position information, planned route information, etc. to a center device. The center device generates information for platooning based on information collected from multiple vehicles and transmits the information to each vehicle in the platoon. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2018-181142 Summary of the Invention

[0006] Incidentally, when considering platooning of vehicles configured to provide their own information and functions via APIs (hereinafter referred to as vehicle APIs), it is necessary to allow access to the vehicle API from external devices (e.g., center devices and other vehicles).However, it is necessary to prevent such access to the vehicle API from external devices from leading to the leakage of personal information unrelated to the provision of services or unauthorized vehicle control unintended by the user.

[0007] One aspect of the present disclosure provides a technique for appropriately restricting access to a vehicle API from outside the vehicle.

[0008] One aspect of the present disclosure is an access control device including an access control unit, an acceptance determination unit, and a start confirmation unit. The access restriction unit is configured to receive an access request from an API-using app installed outside the vehicle and control access to the vehicle API. The vehicle API is an interface for providing vehicle functions possessed by the vehicle. The API-using app is an application that realizes a service using the vehicle API. The acceptance determination unit is configured to provide, via the vehicle API, a function for determining whether the vehicle can accept a target service, which is a service provided by the API-using app. The start confirmation unit is configured to provide, via the vehicle API, a function for confirming with a vehicle user whether provision of the target service should be started.

[0009] The access control unit includes a first granting unit and a second granting unit. The first granting unit is configured to grant, to the API-using app, an access right to the vehicle API that provides the function of the start confirmation unit when the acceptance determination unit determines that the service is acceptable. The second granting unit is configured to grant, to the API-using app, an access right to the vehicle API necessary for providing the target service when the start confirmation unit confirms the user's intention to start the service.

[0010] With this configuration, access to the vehicle API from outside the vehicle can be appropriately restricted.

[0011] One aspect of the present disclosure is an access control method that receives an access request from a service provider that provides an API-based service located outside a vehicle and controls access to a vehicle API. The vehicle API is an interface for providing vehicle functions that the vehicle possesses. An API-based app is an application that realizes a service using the vehicle API.

[0012] The acceptance determination unit is configured to provide, via the vehicle API, a function for determining whether the vehicle can accept a target service, which is a service provided by an API-using app. If the acceptance determination unit determines that the vehicle can accept the target service, it grants the service provider access rights to the vehicle API that provides the function of the start confirmation unit. The start confirmation unit is configured to provide, via the vehicle API, a function for confirming to the vehicle user whether or not to start providing the target service. If the start confirmation unit confirms the user's intention to start, it grants the API-using app access rights to the vehicle API necessary for providing the target service.

[0013] According to this method, access to the vehicle API from outside the vehicle can be appropriately restricted. [Brief explanation of the drawings]

[0014] [Figure 1] 1 is a block diagram showing the configuration of a mobility service providing system 1. FIG. [Figure 2] FIG. 2 is a block diagram showing the functional configuration of the in-vehicle system. [Figure 3] 10 is a flowchart showing the processing content in an authenticator granting unit. [Figure 4] 10 is a flowchart showing processing contents in an access restriction unit. [Figure 5] FIG. 2 is a sequence diagram showing a typical operation example of the in-vehicle system. [Figure 6] FIG. 2 is a sequence diagram showing a typical operation example of the in-vehicle system. [Figure 7] FIG. 2 is a sequence diagram showing a typical operation example of the in-vehicle system. [Figure 8] FIG. 10 is a block diagram showing a functional configuration when the API-using service is a platooning service. [Figure 9] 10 is a block diagram showing a functional configuration when the API-using service is an AVP service. [Figure 10] FIG. 10 is a sequence diagram showing an example of the operation of the AVP service. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0016] [1. Configuration] As shown in FIG. 1, the mobility service providing system 1 of this embodiment includes an in-vehicle system 100 mounted on a vehicle, an automated valet parking (hereinafter, referred to as AVP) infrastructure 200, another vehicle 300, and a user terminal 400.

[0017] A vehicle equipped with the in-vehicle system 100 may have an automatic driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an engine and an electric motor as a driving source. The vehicle is not limited to a vehicle having an automatic driving function or a hybrid vehicle, but may be a vehicle having only a manual driving function, or a vehicle having only an engine or only an electric motor as a driving source. Hereinafter, a vehicle equipped with the in-vehicle system 100 will be simply referred to as a vehicle.

[0018] The in-vehicle system 100 includes one ECU 2, a plurality of ECUs 3, a plurality of ECUs 4, an external communication device 5, and an internal communication network 6. ECU is an abbreviation for Electronic Control Unit.

[0019] The ECU 2 realizes coordinated control of the entire vehicle by controlling the multiple ECUs 3. The ECU 2 is connected to an in-vehicle communication network 6 to which the multiple ECUs 3 are connected, and relays data frames communicated from each ECU 3 and an external communication device 5.

[0020] An ECU 3 is provided for each domain, which is divided according to the vehicle's functions, and mainly controls the multiple ECUs 4 present within that domain. Each ECU 3 is connected to its subordinate ECUs 4 via a lower-level network (e.g., CAN) provided individually. CAN is an abbreviation for Controller Area Network and is a registered trademark. The ECU 3 has the function of centrally managing access rights to the subordinate ECUs 4 and authenticating users. The domains are, for example, the powertrain, body, chassis, and cockpit.

[0021] The ECUs 4 connected to the ECUs 3 belonging to the powertrain domain include, for example, an ECU 4 that controls the engine, an ECU 4 that controls the motor, and an ECU 4 that controls the battery.

[0022] The ECUs 4 connected to the ECU 3 belonging to the body domain include, for example, an ECU 4 that controls an air conditioner, an ECU 4 that controls doors, and the like.

[0023] The ECUs 4 connected to the ECUs 3 belonging to the chassis domain include, for example, an ECU that controls braking and an ECU that controls steering.

[0024] The ECUs 4 connected to the ECU 3 belonging to the cockpit domain include, for example, an ECU 4 that controls the display of meters and navigation systems, and an ECU 4 that controls an in-vehicle HMI operated by a vehicle user (hereinafter referred to as a user). HMI is an abbreviation for Human Machine Interface.

[0025] The exterior-vehicle communication device 5 performs peer-to-peer data communication within a small range (for example, within several tens of meters) with an external device that provides an API-based service (i.e., the AVP infrastructure 200 or another vehicle 300). The API-based service will be described later. The exterior-vehicle communication device 5 also performs data communication with a user terminal 400 carried by a user via a wide-area wireless communication network.

[0026] The in-vehicle communication network 6 includes, for example, CAN FD and Ethernet. Ethernet is a registered trademark. CAN FD is an abbreviation for CAN with Flexible Data Rate. CAN FD connects the ECU 2 to each ECU 3 and the external-vehicle communication device 5 via a bus. Ethernet individually connects the ECU 2 to each ECU 3 and the external-vehicle communication device 5.

[0027] The ECU2 is an electronic control device mainly composed of a microcomputer including a CPU2a, a ROM2b, a RAM2c, etc. Various functions of the microcomputer are realized by the CPU2a executing a program stored in a non-transitory storage medium. In this example, the ROM2b corresponds to the non-transitory storage medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU2a may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the ECU2 may be one or more.

[0028] Like the ECU 2, the ECU 3, the ECU 4, and the exterior communication device 5 are all electronic control devices mainly configured with a microcomputer including a CPU, a ROM, a RAM, etc. Furthermore, the number of microcomputers configuring the ECU 3, the ECU 4, and the exterior communication device 5 may be one or more.

[0029] In the following description, the ECU 2, ECU 3, ECU 4, and the external vehicle communication device 5 will be referred to as the on-vehicle devices 2 to 5 unless otherwise specified.

[0030] The AVP infrastructure 200 is infrastructure installed in a parking lot that provides the AVP service. The AVP service allows vehicles to automatically drive in a large unmanned parking lot and automatically park in an available parking space.

[0031] The AVP infrastructure 200 includes a communication unit 201 , an HMI unit 202 , and a control unit 203 .

[0032] The communication unit 201 performs peer-to-peer data communication with the in-vehicle system 100 within a small range.

[0033] The HMI unit 202 is used to input information and commands required for providing the AVP service. The HMI unit 202 may be configured so that information and commands are input via the user terminal 400.

[0034] The control unit 203 is mainly configured with a microcomputer including a CPU, ROM, RAM, etc. A service application (hereinafter, service app) that realizes the AVP service is implemented in the control unit 203. The service app that realizes the AVP service accesses the vehicle API of the in-vehicle system 100 via the communication unit 201 to exchange information necessary to start the AVP service and to perform vehicle control such as steering and acceleration / deceleration of the vehicle equipped with the in-vehicle system 100. This vehicle control realizes the entry and exit of the vehicle by autonomous driving. API is an abbreviation for Application Programming Interface.

[0035] Vehicle APIs are used to access functions provided by vehicles and are standardized interfaces that are not dependent on specific vehicle models or grades. In other words, vehicle APIs are structured so that even engineers who are not familiar with the characteristics and constraints of vehicles can easily develop service apps that use vehicle APIs.

[0036] The other vehicle 300 is equipped with an in-vehicle system similar to the in-vehicle system 100 described above. A service app that realizes the platooning service is implemented in the in-vehicle system of the other vehicle 300. Of the vehicles using the platooning service, the service app implemented in the vehicle that will be the lead vehicle in the platoon accesses the vehicle API possessed by the in-vehicle system 100 of the vehicle that will be the following vehicle in the platoon. By accessing this vehicle API, the service app of the leading vehicle exchanges information necessary to start the platooning service, and performs vehicle control such as steering and acceleration / deceleration of the following vehicle so as to maintain the platoon. This vehicle control realizes platooning by autonomous driving.

[0037] The user terminal 400 is, for example, a mobile terminal such as a smartphone or a tablet.

[0038] [2. Functional configuration] The functional configuration of the in-vehicle system 100 will be described.

[0039] 2, the in-vehicle system 100 includes an access control unit 10, a vehicle function unit 20, and a vehicle API unit 50. The access control unit 10 and the vehicle function unit 20 may be arranged in any of the in-vehicle devices 2 to 5. For example, the access control unit 10, the vehicle function unit 20, and the vehicle API unit 50 are arranged in the ECU 2.

[0040] [2-1. Vehicle Functionality] The vehicle function unit 20 is a set of modules into which the functions of the vehicle are subdivided. Each module belonging to the vehicle function unit 20 is installed in one of the on-vehicle devices 2 to 5.

[0041] There are multiple categories in the modules belonging to the vehicle function unit 20, and different access restrictions are set for each category. A vehicle API with access restrictions set will accept and process an API access request only if the API access request is accompanied by an authenticator associated with the category to which it belongs.

[0042] The vehicle function unit 20 has four sections corresponding to four attributes F, S, O, and P defined as security-protected assets, and one section with no access restrictions. F stands for Financial, S stands for Safety, O stands for Operational, and P stands for Privacy.

[0043] Corresponding to each division, the vehicle function unit 20 includes an N-system function block group 21, an O-system function block group 22, a P-system function block group 23, an S-system function block group 24, and an F-system function block group 25. Furthermore, the vehicle function unit 20 includes a vehicle state database (hereinafter referred to as vehicle state DB) 26.

[0044] The N-system functional block group 21 is a collection of modules that provide functions that do not require access to vehicle functions or vehicle information. The O-system functional block group 22 is a collection of modules that provide functions related to the vehicle's operating performance. The P-system functional block group 23 is a collection of modules that provide functions related to the user's privacy information stored in the vehicle. The S-system functional block group 24 is a collection of modules that provide functions related to safety. The F-system functional block group 25 is a collection of modules that provide functions related to corporate or personal property.

[0045] The vehicle state DB 26 stores vehicle state data representing the state of the vehicle. The vehicle state data stored in the vehicle state DB 26 is updated successively. The vehicle state data includes at least the vehicle's position and traveling speed. The vehicle state data may also include the vehicle's operating state, the operating state of on-board devices, and detection results from various monitoring sensors that monitor the vehicle's surroundings and interior.

[0046] The vehicle API unit 50 is a set of vehicle APIs provided for accessing functions provided by the vehicle, i.e., modules belonging to the vehicle function unit 20. The vehicle API unit 50 includes an N-system API group 51, an O-system API group 52, a P-system API group 53, an S-system API group 54, and an F-system API group 55.

[0047] The N-system API group 51 is a collection of vehicle APIs (hereinafter referred to as N-system APIs) used to access each module belonging to the N-system functional block group 21. The N-system APIs have no access restrictions and accept access requests even if an authenticator is not attached to the access request.

[0048] As shown in FIGS. 5 and 10 , the N-system functional block group 21 may include, for example, an acceptance determination module 211, a reliability confirmation module 212, and a termination determination module 213. The acceptance determination module 211 provides a function of determining whether the vehicle is in a state where it can accept a service provided by an API-using app and notifying the provider of the API-using app. The reliability confirmation module 212 provides a function of determining the reliability of the service provider based on reliability information provided by the API-using app and notifying the access control unit 10 of the determination result. The termination determination module 213 provides a function of determining whether a condition for terminating a target service is met and, if met, notifying the access control unit 10 of that fact. The O-system API group 52 is a collection of vehicle APIs (hereinafter referred to as O-system APIs) used to access each module belonging to the O-system functional block group 22. The O-system APIs accept an access request when an O-system authenticator is attached to the access request.

[0049] The O-system functional block group 22 may include, for example, a provision confirmation module 221, a start confirmation module 222, etc. The provision confirmation module 221 provides a function of confirming whether or not the user intends to receive the provision of a service using an in-vehicle HMI provided in the user's own vehicle. The start confirmation module 222 provides a function of confirming whether or not the provision of a service can be started using an in-vehicle HMI provided in the user's own vehicle.

[0050] The P-system API group 53 is a set of vehicle APIs (hereinafter referred to as P-system APIs) used to access each module belonging to the P-system functional block group 23. The P-system APIs accept an access request when a P-system authenticator is attached to the access request.

[0051] The P-system functional block group 23 may include, for example, an information providing module 231, an alighting confirmation module 232, etc. The information providing module 231 provides a function of reading out privacy information stored in the vehicle. The privacy information may include route information to a destination set by the user, parking lot reservation information, etc. The alighting confirmation module 232 provides a function of accessing privacy information stored in the vehicle (for example, an image taken of the interior of the vehicle) and notifying information obtained from the image (for example, whether or not there is an occupant).

[0052] The S-system API group 54 is a vehicle API (hereinafter referred to as S-system API) used to access each module belonging to the S-system functional block group 24. The S-system API accepts an access request when an S-system authenticator is attached to the access request.

[0053] The S-system functional block group 23 may include, for example, a vehicle control module 241. The vehicle control module 241 provides functions for performing vehicle control that changes the behavior of the vehicle, such as steering, acceleration, and deceleration, and includes different modules for each type of vehicle control.

[0054] The F-system API group 55 is a set of vehicle APIs (hereinafter referred to as F-system APIs) used to access each module belonging to the F-system functional block group 25. The F-system APIs accept an access request when an F-system authenticator is attached to the access request.

[0055] The F-system functional block group 25 may include, for example, an adjustment module 251. The adjustment module 251 provides a function for adjusting fees for the services provided.

[0056] [2-2. API-using apps] The service application 30 that realizes a desired function using the vehicle API is called an API-using application. The API-using application realizes a service that uses vehicle information and vehicle functions by accessing the vehicle API.

[0057] The API-using application may be installed in the in-vehicle system 100, but here, the case where it is installed in an external device such as the AVP infrastructure 200 or another vehicle 300 will be described.

[0058] The API-using app may be provided by the OEM or by a third party.

[0059] OEM is the vehicle manufacturer that produced the vehicle. OEM stands for Original Equipment Manufacturer. OEM apps may include apps developed by the OEM itself and apps developed by other vendors.

[0060] Third parties are any party other than the vehicle owner and the OEM.

[0061] Services provided by API-using apps include, for example, a platooning service that realizes platooning by autonomous driving, an AVP service that realizes AVP by autonomous driving, etc. In the case of the platooning service, the other vehicle 300 traveling at the front of the platoon corresponds to the external device in this disclosure. In the case of the AVP service, the AVP infrastructure 200 installed in the parking lot corresponds to the external device in this disclosure.

[0062] When an API-using application uses a function provided by the vehicle function unit 20, it transmits an API access request, which is a request for access to a vehicle API belonging to the vehicle API unit 50. The API access request includes at least information identifying a service application that is the source of use (hereinafter referred to as the source application) and information identifying a vehicle API that is the destination of use (hereinafter referred to as the destination API). The API access request may be accompanied by an authenticator indicating that the application has access rights to a specific API.

[0063] The API access request is transferred to the vehicle API unit 50 via the access control unit 10, and is further transferred from the vehicle API unit 50 to the vehicle function unit 20.

[0064] [2-3. Access Control Unit] The access control unit 10 has a function of controlling access to the vehicle API provided by each module belonging to the vehicle function unit 20 .

[0065] The access control unit 10 includes an authentication code providing unit 11, an access restriction unit 12, and an access management database (hereinafter referred to as access management DB) 13.

[0066] The authenticator granting unit 11 executes a process of granting an authenticator prepared for each category to an API-using application. Hereinafter, an API-using application that uses the vehicle API of the vehicle is referred to as a target application 30. There may be multiple target applications 30. Furthermore, a service provided by a target application 30 is referred to as a target service.

[0067] The authenticator granting process executed by the authenticator granting unit 11 will be described with reference to the flowchart shown in Fig. 3. The authenticator granting process is executed individually for each API-using application.

[0068] When the authenticator granting process starts, the authenticator granting unit 11 determines in S110 whether the host vehicle is in a state where it can accept the target service. This determination is made using the acceptance determination module 211 belonging to the N-system functional block group 21. The acceptance determination module 211 is installed in advance in the in-vehicle system 100 of the host vehicle when the target service is to be used, for example. If the host vehicle is in a state where it can accept the target service, the acceptance determination module 211 notifies the authenticator granting unit 11 of this fact.

[0069] The acceptance determination module 211 receives reliability information from an external device that is the provider of the target service, and determines, based on the reliability information provided, whether the service is provided by the service provider intended by the driver.

[0070] When the target service is platooning, the leading vehicle in the platoon is the service provider, and the location, traveling speed, etc. of the leading vehicle are used as reliability information. When the target service is automatic parking, the infrastructure that provides the automatic parking service is the service provider, and the location, name, etc. of the infrastructure are used as reliability information. The acceptance determination module 211 then compares the reliability information provided by the service provider with the location, traveling speed, map information, etc. of the vehicle stored in the vehicle state DB 26, to determine whether the vehicle is located in a position where the service can be provided. Note that the position where the service can be provided may be, for example, a position where the vehicle or infrastructure that is the service provider is visible to the driver of the vehicle.

[0071] When the authenticator granting unit 11 receives a notification from the acceptance determination module 211, it determines that the service is acceptable and moves the process to S120. On the other hand, when the authenticator granting unit 11 does not receive a notification from the acceptance determination module 211, it determines that the service is not acceptable and waits by repeating the same step.

[0072] In S120, the authenticator granting unit 11 transmits an acceptance notification to the target application 30 implemented in the external device.

[0073] In the following S130, the authenticator granting unit 11 determines whether the target service has ended. This determination may be made when a payment completion notification indicating that the payment process has ended is received from the settlement module 251. Alternatively, when the payment process is omitted, the authenticator granting unit 11 may make the determination using the completion determination module 213 belonging to the N-system functional block group 21. Similar to the acceptance determination module 211, the completion determination module 213 is pre-installed in the in-vehicle system 100 of the host vehicle when the target service is used. When a completion condition for terminating the service is met, the completion determination module 213 notifies the authenticator granting unit 11 of this fact. The completion determination module 213 may determine whether the completion condition is met, for example, based on vehicle status data stored in the vehicle status DB 26. The authenticator granting unit 11 may determine that the service has ended when a notification is received from the completion determination module 213.

[0074] If the authenticator granting unit 11 determines that the service has ended, it shifts the process to S140, and if it determines that the service has not ended, it shifts the process to S150.

[0075] In S140, the authenticator granting unit 11 invalidates the authenticators granted to the target application 30 in S160, S180, S200, and S220, which will be described later, and ends the process.

[0076] In S150, the authenticator granting unit 11 determines whether the O-system opening condition that permits access to the O-system API is met, and if the O-system opening condition is met, the process proceeds to S160, and if the O-system opening condition is not met, the process proceeds to S170.

[0077] In S160, the authenticator granting unit 11 grants an O-system authenticator to the target application 30 implemented in the external device, and the process returns to S130.

[0078] In S170, the authenticator granting unit 11 determines whether the P system opening condition that allows access to the P system API is met, and if the P system opening condition is met, the processing proceeds to S180, and if the P system opening condition is not met, the processing proceeds to S190.

[0079] In S180, the authenticator granting unit 11 grants a P-system authenticator to the target application 30 implemented in the external device, and the process returns to S130.

[0080] In S190, the authenticator granting unit 11 determines whether the S-system opening condition that allows access to the S-system API is met, and if the S-system opening condition is met, the processing proceeds to S200, and if the S-system opening condition is not met, the processing proceeds to S210.

[0081] In S200, the authenticator granting unit 11 grants an S-series authenticator to the target application 30 implemented in the external device, and the process returns to S130.

[0082] In S210, the authenticator granting unit 11 determines whether or not the F-system opening condition for permitting access to the F-system API is satisfied, and if the F-system opening condition is satisfied, the process proceeds to S220, and if the F-system opening condition is not satisfied, the process returns to S130.

[0083] In S220, the authenticator granting unit 11 grants an F-series authenticator to the target application 30 implemented in the external device, and the process returns to S130.

[0084] The release conditions used in S150, S170, S190, and S210 may include, for example, a condition that a predetermined result is obtained from a process executed in response to an API access request from the target application 30. The release conditions may also include a condition that an authenticator of another category has already been assigned to the target application 30. In other words, the order in which authenticators of each category are assigned may be controlled depending on how the release conditions are set.

[0085] The access restriction unit 12 classifies the authenticators assigned to the target applications 30 in S160, S180, S200, and S220 into O-system, P-system, S-system, and F-system categories and stores them in the access management DB 13. The access restriction unit 12 invalidates the authenticators in S140 by deleting the authenticators stored in the access management DB 13.

[0086] The access restriction unit 12 receives an API access request from the target application 30 (that is, an external device) and executes an access restriction process to determine whether or not to permit access to the vehicle API that is the access destination.

[0087] Next, the access restriction process executed by the access restriction unit 12 will be described with reference to the flowchart shown in Fig. 4. The access control process is executed in common for all API-using applications.

[0088] When the access restriction process starts, the access restriction unit 12 determines in S310 whether or not an API access request has been received from the target application 30 implemented in the external device. If the access restriction unit 12 determines that an API access request has been received, the process proceeds to S320, and if the access restriction unit 12 determines that an API access request has not been received, the access restriction unit 12 waits by repeating the same step.

[0089] In S320, the access restriction unit 12 determines whether the destination API indicated in the API access request is an N-system API with no access restrictions, and if it is an N-system API, it transfers the processing to S350, and if it is not an N-system API, it transfers the processing to S330.

[0090] In S330, the access restriction unit 12 determines whether an authenticator is attached to the API access request, and if an authenticator is attached, the process proceeds to S340, and if an authenticator is not attached, the process proceeds to S360.

[0091] In S340, the access restriction unit 12 determines whether the authenticator attached to the API access request is compatible with the destination API, and if it is compatible, the process proceeds to S350, and if it is not compatible, the process proceeds to S360. Specifically, for example, if the destination API is an O-system API, the authenticator attached to the API access request may be determined to be compatible if it matches an O-system authenticator stored in the access management DB 13.

[0092] In S350, the access restriction unit 12 determines that the target application 30 has access authority to the use-destination API, transfers the API access request to the use-destination API, and ends the process.

[0093] In S360, the access restriction unit 12 determines that the target application 30 does not have access authority to the destination API, discards the API access request, and ends the process. At this time, the access restriction unit 12 may notify the target application 30 that the API access request has been discarded.

[0094] [3. Example of operation] [3-1. Typical operation examples] A representative example of operation will be described using the sequence diagrams of Figures 5 to 7. In Figures 5 to 7, to make the drawings easier to understand, the API groups 51 to 55 are omitted. This is because there is a one-to-one correspondence between the N-system API group 51 and the N-system functional block group 21, the O-system API group 52 and the O-system functional block group 22, the P-system API group 53 and the P-system functional block group 23, the S-system API group 54 and the S-system functional block group 24, and the F-system API group 55 and the F-system functional block group 25.

[0095] When a vehicle (hereinafter, referred to as the host vehicle) equipped with the in-vehicle system 100 is started up, the in-vehicle system 100 determines whether the host vehicle is in a state where it can accept the target service by the acceptance determination module 211. Then, as shown in FIG. 5, the in-vehicle system 100 transmits a result notification M1 indicating the determination result of the acceptance determination module 211 to the target application 30 implemented in the external device.

[0096] Upon receiving the result notification M1 indicating that the service is acceptable, the target application 30 transmits an API access request M2 to the reliability confirmation module 212. The API access request M2 is accompanied by reliability information, which is information relating to the reliability of the service itself.

[0097] Upon receiving the API access request M2, the access control unit 10 checks the destination API indicated in the API access request M2. In this case, since the request is for access to an N-system API (i.e., the determination in S320 is affirmative), the access control unit 10 forwards the API access request M2 to the destination API. The destination API activates the trust confirmation module 212, which is a destination module, in accordance with the forwarded API access request M2.

[0098] The reliability confirmation module 212, which receives the API access request M2, notifies the access control unit 10 of a reliability notification M3 indicating the result of determining the reliability of the target service based on the reliability information attached to the API access request M2.

[0099] When the access control unit 10 receives the reliability notification M3 and determines that the target service is sufficiently reliable, it determines that the O-system opening condition is met (i.e., a positive determination is made in S150), and transmits an access permission notification M4 with an O-system authenticator attached to the target application 30. For example, the access control unit 10 may determine that the target service is sufficiently reliable when the reliability of the target service in the reliability notification M3 exceeds a predetermined threshold.

[0100] Furthermore, if the access control unit 10 receives the reliability notification M3 and determines that the target service is not reliable, it sends an access denial notification M5 to the target application 30, indicating that it is refusing to grant access to the O-system API, as shown in Figure 6.

[0101] Returning to Fig. 5, upon receiving the access permission notification M4, the target application 30 transmits an API access request M6 to the provision confirmation module 221. The O-system authenticator acquired in the access permission notification M4 is attached to the API access request M6. The provision confirmation module 221 provides a function to confirm the user's intention regarding the provision of the target service via the in-vehicle HMI.

[0102] Upon receiving API access request M6, the access control unit 10 checks the destination API, etc., indicated in API access request M6. In this case, it is a request to access an O-system API (i.e., a negative determination is made in S320), an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards API access request M6 to the destination API. The destination API activates the provision confirmation module 221, which is a destination module, in accordance with the forwarded API access request M6.

[0103] The provision confirmation module 221, which has been activated in accordance with the API access request M6, transmits a provision confirmation request M7 to the ECU that controls the in-vehicle HMI.

[0104] Upon receiving the provision confirmation request M7, the ECU displays a message via the in-vehicle HMI prompting the user to confirm whether or not they wish to receive the target service, and when the user enters input, it returns a user response M8 indicating the input content to the provision confirmation module 221.

[0105] The provision confirmation module 221 receives the user response M8 and transmits to the access control unit 10 a provision confirmation notification M9 indicating the user's intention indicated in the user response M8.

[0106] When the provision confirmation notification M9 has received, if the provision of the target service is desired, the access control unit 10 determines that the P-system opening condition is met (i.e., a positive determination is made in S170), and transmits an access permission notification M10 with a P-system authenticator attached to the target application 30. On the other hand, when the provision confirmation notification M9 indicates that the provision of the target service is not desired, the access control unit 10 transmits an access denial notification M11 to the target application 30, indicating that the granting of access to the P-system API is denied, as shown in FIG.

[0107] 5, upon receiving the access permission notification M10, the target application 30 transmits an API access request M12 to the information providing module 231. The P-series authenticator acquired in the access permission notification M10 is attached to the API access request M12.

[0108] Upon receiving the API access request, the access control unit 10 checks the destination API, etc., indicated in the API access request M12. In this case, it is a request for access to a P-system API (i.e., a negative determination is made in S320), an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M12 to the destination API. The destination API activates the information providing module 231, which is a destination module, in accordance with the forwarded API access request M12.

[0109] The information providing module 231, which is activated in accordance with the API access request M12, acquires the privacy information indicated in the API access request M12 and transmits the acquired privacy information to the target application 30 by an information provision notification M13.

[0110] Upon receiving the information provision notification M13, the target application 30 transmits an API access request M14 to the start confirmation module 222. The O-system authenticator acquired in the access permission notification M4 is attached to the API access request M14. The start confirmation module 222 provides a function to confirm the user's intention regarding the start of the target service via the in-vehicle HMI.

[0111] Upon receiving the API access request M14, the access control unit 10 checks the destination API, etc., indicated in the API access request M14. In this case, it is a request to access an O-system API (i.e., a negative determination is made in S320), an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M14 to the destination API. The destination API activates the start confirmation module 222, which is a destination module, in accordance with the forwarded API access request M14.

[0112] The start confirmation module 222, which has been activated in accordance with the API access request M14, sends a start confirmation request M15 to the ECU that controls the in-vehicle HMI.

[0113] The ECU that receives the start confirmation request M15 displays a message via the in-vehicle MHI prompting the user to confirm whether or not they wish to start the target service, and when the user makes an input, returns a user response M16 indicating the input content to the start confirmation module 222.

[0114] The start confirmation module 222 receives the user response M16 and transmits to the access control unit 10 a start necessity notification M17 indicating the user's intention indicated in the user response M16.

[0115] When the start necessity notification M17 indicates that the target service is desired to be started, the access control unit 10, upon receiving the start necessity notification M17, determines that the S-system opening condition is met (i.e., a positive determination is made in S190), and transmits an access permission notification M18 with an S-system authenticator attached to the target application 30. Furthermore, when the start necessity notification M17 indicates that the target service is not desired to be started, the access control unit 10 transmits an access denial notification (not shown) to the target application 30 indicating that the granting of access to the S-system API is denied.

[0116] Upon receiving the access permission notification M18, the target application 30 transmits an API access request M19 to the vehicle control module 241. The API access request M19 is accompanied by the S-series authenticator acquired in the access permission notification M18.

[0117] Upon receiving the API access request M19, the access control unit 10 checks the destination API, etc., indicated in the API access request M19. In this case, it is a request to access an S-series API (i.e., a negative determination is made in S320), an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M19 to the destination API. The destination API operates the vehicle control module 241, which is the destination module, in accordance with the forwarded API access request M19.

[0118] The vehicle control module 241, operating in accordance with the API access request M19, executes vehicle control necessary to realize the target service in accordance with the instructions indicated in the API access request M19. Although only one API access request M19 to the vehicle control module 241 is shown in Fig. 5, multiple API access requests M19 may be sent.

[0119] Thereafter, the target application transmits an API access request M20 to the termination determination module 213 when it is necessary to terminate the service.

[0120] Upon receiving the API access request M20, the access control unit 10 checks the destination API, etc., indicated in the API access request M20. In this case, since the request is for access to an N-system API (i.e., the determination in S320 is affirmative), the access control unit 10 forwards the API access request M20 to the destination API. The destination API activates the termination determination module 213, which is a destination module, in accordance with the forwarded API access request M20.

[0121] The termination determination module 213, which has been activated in accordance with the API access request M20, transmits a termination notification M21 to the access control unit 10 when the status of the vehicle satisfies a preset termination condition. The termination condition is not limited to receiving the API access request M20, but may also include detection of a vehicle abnormality, etc.

[0122] Upon receiving the completion notification M21, the access control unit 10 determines that the F-line opening condition is met (that is, a positive determination is made in S210), and transmits an access permission notification M22 with an F-line authenticator attached to the target application 30.

[0123] Upon receiving the access permission notification M22, the target application 30 transmits an API access request M23 to the settlement module 251. The API access request M23 is accompanied by the F-series authenticator acquired in the access permission notification M22.

[0124] Upon receiving the API access request M23, the access control unit 10 checks the destination API, etc., indicated in the API access request M23. In this case, it is a request to access the F-system API (i.e., a negative determination is made in S320), and an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator is compatible with the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M23 to the destination API. The destination API operates the settlement module 251, which is the destination module, in accordance with the forwarded API access request M23.

[0125] The settlement module 251, which has been activated in response to the API access request M23, executes the process of settling the cost required for the target service, and then transmits a payment completion notification M24 to the access control unit 10.

[0126] Upon receiving the payment completion notification M24, the access control unit 10 determines that the service has ended (i.e., a positive judgment was made in S130), invalidates each authenticator assigned to the target application 30 during the processing, and sends a service completion notification M25 to the target application.

[0127] Upon receiving the service termination notification M25, the target application 30 discards each authenticator given by the access control unit 10 as a processing assumption, and terminates the provision of the service.

[0128] In addition, if the fee is not settled, the access control unit 10 may assume that the service has ended (i.e., a positive judgment was made in S130) upon receiving the termination notification M21, and may invalidate the authenticator and send a service termination notification M25 to the target application 30.

[0129] [3-2. Example of operation in platooning service] Next, an example of operation when an API-using application provides a platooning service will be described.

[0130] In this case, as shown in Fig. 8, another vehicle 300 that is the lead vehicle in the platooning becomes an external device that provides a service (hereinafter referred to as a service providing vehicle). The service providing vehicle 300 includes a service application (hereinafter referred to as a target application) 30 for providing the platooning service.

[0131] The procedure for the platooning service follows the general procedure shown in Figures 5 to 7.

[0132] However, the acceptance determination module 211 used in the platooning service may include, for example, in the determination conditions, that the vehicle is traveling on a road on which the provision of the platooning service is permitted. The road on which the provision of the platooning service is permitted may be, for example, a specific road on which there are no pedestrians, such as an expressway.

[0133] The reliability confirmation module 212 used in the platooning service acquires the position and speed of the service providing vehicle as reliability information, and calculates a reliability that increases as the distance between the service providing vehicle and the host vehicle decreases and the relative speed between the service providing vehicle and the host vehicle decreases. The reliability of a service providing vehicle that is equal to or greater than a threshold value may be used as a criterion for determining whether the service providing vehicle is sufficiently reliable. Alternatively, the criterion for determining whether at least one of the distance and the relative speed between the service providing vehicle and the host vehicle is within an acceptable range may be used.

[0134] The information providing module 231 used in the platooning service may provide, as privacy information, route information to the destination to the target application 30. The route information may be set using, for example, a navigation device mounted on the vehicle.

[0135] The termination determination module 213 used in the convoy driving service may determine that the termination condition is met when the destination is reached, when the service providing vehicle is instructed to leave the convoy, when the user inputs a request to leave the convoy via the in-vehicle HMI, etc.

[0136] That is, in the platooning service, when the host vehicle is in a state where it can accept the service and the service-providing vehicle is sufficiently reliable, the in-vehicle system 100 of the host vehicle assigns an O-system authenticator to the target application 30. The target application 30 uses the assigned O-system authenticator to access the provision confirmation module 221 belonging to the O-system functional block group 22 to confirm with the user whether or not the user intends to receive the service. Once the user's intention is confirmed, the in-vehicle system 100 assigns a P-system authenticator to the target application 30. The target application 30 uses the assigned P-system authenticator to access the information provision module 231 belonging to the P-system functional block group 23 to obtain route information, which is private information. Furthermore, the target application 30 uses the previously assigned O-system authenticator to access the start confirmation module 222 belonging to the O-system functional block group 22 to again confirm with the user whether or not to start providing the service. Once the user's intention to start providing the service is confirmed, the in-vehicle system 100 assigns an S-system authenticator to the target application 30. The target application 30 uses the assigned S-system authenticator to access a vehicle control module 241 belonging to the S-system functional block group 24, thereby performing vehicle control to realize platooning. When the in-vehicle system 100 confirms that the termination condition of the target application 30 is met, it assigns an F-system authenticator to the target application 30. The target application 30 uses the assigned F-system authenticator to access an accounting module 251 belonging to the F-system functional block group 25, thereby performing accounting for the service provided by the target application 30. When accounting is completed, the in-vehicle system 100 invalidates each authenticator assigned to the target application 30.

[0137] [3-3. Example of operation with AVP service] Next, an example of operation when an API-using application provides an AVP service will be described.

[0138] In this case, as shown in Fig. 9, an AVP infrastructure 200 installed in a parking lot serves as an external device that provides a service. The AVP infrastructure 200 includes a service application (hereinafter, a target application) 30 that is executed to realize the AVP service. The AVP infrastructure 200 also includes a vehicle calling device 40 that calls a parked vehicle.

[0139] Instead of using the vehicle calling device 40, the user terminal 400 may be configured to call a vehicle.

[0140] The AVP service procedures are the same as the general procedures shown in Figures 5 to 7, including service acceptance judgment, service reliability confirmation, confirmation of whether the service is required for the user, and service termination / settlement, i.e., the procedures using messages M1 to M10 and M20 to M25.

[0141] However, the acceptance determination module 211 used in the AVP service may determine that the vehicle is acceptable when the vehicle's location is near a parking lot where the AVP service is provided, for example.

[0142] The reliability confirmation module 212 used in the AVP service may obtain reliability information such as the location and name of the parking lot where the AVP service is provided from the target application 30, and if the location and name of the parking lot where the parking is planned to be parked match the pre-stored information, it may determine that the AVP infrastructure 200 is reliable.

[0143] In the AVP service, as shown in FIG. 10, upon receiving an access permission notification M10, the target application 30 transmits an API access request M31 to the alighting confirmation module 232 belonging to the P-system functional block group 23. The P-system authenticator acquired in the access permission notification M10 is attached to the API access request M31. The alighting confirmation module 232 acquires an image of the interior of the vehicle, and confirms whether all occupants have alighted based on the image analysis results, etc., and transmits the confirmation result to the access control unit 10. Because the processing in the alighting confirmation module 232 includes access to private information (i.e., an image of the interior of the vehicle), the API access request M31 to the alighting confirmation module needs to have a P-system authenticator attached.

[0144] Upon receiving the API access request M31, the access control unit 10 checks the destination API, etc., indicated in the API access request M31. In this case, the request is for access to a P-system API (i.e., a negative determination is made in S320), an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator is compatible with the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M31 to the destination API. The destination API activates the destination module, the disembarkation confirmation module 232, in accordance with the API access request M31.

[0145] The dismounting confirmation module 232, which is activated in response to the API access request M31, transmits to the access control unit 10 a dismounting confirmation notification M32 indicating whether all passengers have dismounted.

[0146] When the disembarking confirmation notification M32 indicates that all passengers have disembarked, the access control unit 10 determines that the S-system release condition is met (i.e., a positive determination is made in S190) and transmits an access permission notification M33 with an S-system authenticator attached to the target application 30. Furthermore, when the disembarking confirmation notification M32 indicates that there are passengers who have not yet disembarked, the access control unit 10 transmits an access denial notification (not shown) to the target application 30 indicating that the granting of access to the S-system API is denied.

[0147] Upon receiving the access permission notification M33, the target application 30 transmits an API access request M34 to the vehicle control module 241. The API access request M34 is accompanied by the S-series authenticator acquired in the access permission notification M33.

[0148] Upon receiving the API access request M34, the access control unit 10 checks the destination API, etc., and transfers the API access request M34 to the destination API. The destination API operates the vehicle control module 241 in accordance with the API access request M34.

[0149] The vehicle control module 241, activated in accordance with the API access request M34, controls the vehicle in accordance with the instructions contained in the API access request M34. The target application 30 repeatedly transmits the API access request M34 until the vehicle reaches the parking space. As a result, the vehicle enters the parking space by autonomous driving.

[0150] Thereafter, the target application 30, which has received the call command via the vehicle call device 40, transmits an API access request M35 to the vehicle control module 241. The API access request M35 is accompanied by the S-series authenticator acquired in the access permission notification M33.

[0151] Upon receiving the API access request M35, the access control unit 10 checks the use API, etc., and transfers the API access request M35 to the use API. The use API operates the vehicle control module 241, which is the use module, in accordance with the API access request M35.

[0152] The vehicle control module 241, activated in accordance with the API access request M35, controls the vehicle in accordance with the instructions contained in the API access request M35. The target application 30 repeatedly sends the API access request M34 until the vehicle leaves the parking space and arrives at the designated boarding / exiting space. As a result, the vehicle leaves the parking space by autonomous driving.

[0153] When the vehicle has been released from the garage, the target application 30 transmits an API access request M20 to the completion determination module 213. The following procedure is similar to the general procedure shown in FIG.

[0154] That is, in the AVP service, when the vehicle is located near a parking lot and information obtained from the AVP infrastructure of that parking lot indicates that the parking lot is the parking lot where the vehicle is scheduled to park, the in-vehicle system 100 of the vehicle assigns an O-system authenticator to the target application 30. The target application 30 uses the assigned O-system authenticator to access the provision confirmation module 221 belonging to the O-system functional block group 22 to confirm with the user whether or not the user intends to receive the service. Once the user's intention is confirmed, the in-vehicle system 100 assigns a P-system authenticator to the target application 30. The target application 30 uses the assigned P-system authenticator to access the disembarkation confirmation module 232 belonging to the P-system functional block group 23 to confirm that all occupants have disembarked from images of the vehicle interior. Once it is confirmed that all occupants have disembarked, the in-vehicle system 100 assigns an S-system authenticator to the target application 30. The target application 30 uses the assigned S-system authenticator to repeatedly access the vehicle control module 241 belonging to the S-system functional block group 24 to perform vehicle control to realize parking.

[0155] When a vehicle call instruction is input via the vehicle call device 40, the target application 30 executes vehicle control to realize the departure of the specified vehicle by repeatedly accessing the vehicle control module 241 belonging to the S-system functional block group 24 using the previously assigned S-system authenticator. When the departure is completed, thereby establishing a termination condition for terminating the service, the in-vehicle system 100 assigns an F-system authenticator to the target application 30. The target application 30 executes settlement for the AVP service provided by the target application 30 by accessing the settlement module 251 belonging to the F-system functional block group 25 using the assigned F-system authenticator. When settlement is completed, the in-vehicle system 100 invalidates each authenticator assigned to the target application 30.

[0156] [4. Terminology] In this embodiment, the in-vehicle system 100 corresponds to the access control device in the present disclosure, and the acceptance determination module 211 and the reliability confirmation module 212 correspond to the acceptance determination unit in the present disclosure. The start confirmation module 222 corresponds to the start confirmation unit in the present disclosure, and the settlement module 251 corresponds to the settlement unit in the present disclosure. The authenticator granting unit 11 corresponds to the first granting unit to the third granting unit in the present disclosure. In particular, the processes of S150 to S160 correspond to the first granting unit in the present disclosure, the processes of S170 to S200 correspond to the second granting unit in the present disclosure, and the processes of S210 to S220 correspond to the third granting unit in the present disclosure.

[0157] [5. Effects] According to the embodiment described above in detail, the following effects are achieved.

[0158] (a) When receiving an API-based service, the reliability of the service provider is confirmed, and if the service provider is found to be trustworthy, access to the vehicle API used to obtain information necessary for providing the service and to control the vehicle is granted in stages. This makes it possible to appropriately restrict unnecessary access to the vehicle API from outside the vehicle, allowing for the safe use of API-based services.

[0159] (b) When granting access rights, the user's consent is included, so even if the conditions for receiving the service are met, it is possible to prevent vehicle information from being leaked or vehicle control from being performed against the user's intention.

[0160] (c) When the API-based service is a platooning service, the other vehicle 300 becomes the service provider and realizes the service through vehicle-to-vehicle communication without going through the center device. Therefore, since there is no time lag due to communication via the center device, it is possible to provide an appropriate service according to the situation around the vehicle.

[0161] That is, in conventional platooning systems, services are provided via a center device, which causes a time lag depending on the processing status of the center device and the communication status between the center device and the in-vehicle system 100. Such a time lag is fatal to a traveling vehicle whose surrounding circumstances are constantly changing in real time. In this embodiment, it is possible to prevent such a time lag from preventing a user from receiving the necessary service at the moment when it is needed, and to prevent, for example, a situation from occurring where an opportunity to join or leave a platoon is missed.

[0162] (d) If the API-using service is an AVP service, the AVP infrastructure is granted access to the vehicle API that provides vehicle control when it has been confirmed that all passengers have exited the vehicle by accessing private image information captured inside the vehicle. This prevents the vehicle from being moved to a parking space while some passengers remain locked inside the vehicle.

[0163] 6. Other Embodiments Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modified forms.

[0164] (a) In the above embodiment, the vehicle API is divided into categories by FSOP, and access rights are granted collectively for each category. However, for example, the stage at which access rights are granted may be different for each type of vehicle control within the S category.

[0165] (b) In the above embodiment, when a service is started, the procedure for starting the service is started without authenticating the service provider, and when a user accesses via an HMI device, user input is accepted without personal authentication. To improve safety, authentication of the service provider or personal authentication may be performed.

[0166] (c) The in-vehicle devices 2 to 5 and the methods therefor described herein may be implemented by a dedicated computer configured with a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the in-vehicle devices 2 to 5 and the methods therefor described herein may be implemented by a dedicated computer configured with a processor constituted by one or more dedicated hardware logic circuits. Alternatively, the in-vehicle devices 2 to 5 and the methods therefor described herein may be implemented by one or more dedicated computers configured by combining a processor and memory programmed to execute one or more functions with a processor constituted by one or more hardware logic circuits. Furthermore, the computer program may be stored on a computer-readable non-transitory tangible recording medium as instructions to be executed by a computer. The methods for implementing the functions of each unit included in the in-vehicle devices 2 to 5 do not necessarily need to include software; all of the functions may be implemented using one or more hardware devices.

[0167] (d) Multiple functions of one component in the above embodiments may be realized by multiple components, or one function of one component may be realized by multiple components. Also, multiple functions of multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of the above embodiments may be omitted. Also, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0168] (e) In addition to the access control device described above, the present disclosure can also be realized in various forms, such as a system that includes the access control device as a component, a program for causing a computer to function as the access control device, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and an access control method. [7. Technical Ideas Disclosed in the Present Specification] [Item 1] an access control unit (10) configured to receive an access request from an API-using application (30) provided outside the vehicle, the API-using application (30) being an interface for providing a vehicle function of the vehicle, and to control access to the vehicle API; an acceptance determination unit (211, 212) configured to provide, via the vehicle API, a function of determining whether the vehicle can accept a target service that is a service provided by the API-using app; a start confirmation unit (222) configured to provide, via the vehicle API, a function of confirming with the user of the vehicle whether or not to start provision of the target service; Equipped with The access control unit a first granting unit (11: S150 to S160) configured to grant, to the API-using application, an access right to the vehicle API that provides the function of the start confirmation unit when the acceptance determination unit determines that the application is acceptable; a second granting unit (11: S170 to S200) configured to grant, to the API-using application, an access right to the vehicle API necessary for providing the target service when the start confirmation unit confirms the user's intention to start the target service; Equipped with Access control device. [Item 2] Item 1, an access control device comprising: The API-using application is provided in an external device (200, 300) that is present within a range where peer-to-peer communication with the vehicle is possible. Access control device. [Item 3] The access control device according to item 1 or 2, Further, a settlement unit (251) configured to provide a function of settling the payment related to the target service via the vehicle API, The access control unit The vehicle control unit further includes a third granting unit (11: S210 to S220) configured to grant, when the termination of the target service is confirmed, an access right to the vehicle API that provides the function of the settlement unit to the API-using application. Access control device. [Item 4] An access control device according to any one of items 1 to 3, The target service is a platooning service that controls subsequent vehicles so that the subsequent vehicles maintain the platoon in accordance with instructions from a leading vehicle, The API-using application is installed in another vehicle (300) at the front of the platoon. Access control device. [Item 5] Item 4. An access control device according to item 4, The acceptance determination unit determines whether the vehicle is traveling on a road on which the platooning service is permitted. Access control device. [Item 6] Item 4 or Item 5, an access control device The acceptance determination unit determines whether at least one of the distance and the relative speed to the other vehicle is within an allowable range. Access control device. [Item 7] An access control device according to any one of items 4 to 6, The vehicle APIs required to provide the platooning service include a privacy-related API that provides a function to acquire route information to the destination of the vehicle, and a safety-related API that provides a function to control the behavior of the vehicle. Access control device. [Item 8] An access control device according to any one of items 1 to 3, The target service is an auto valet parking service in which parking is entered and exited by automated driving, The API-using application is provided in an infrastructure device (200) installed in a parking lot that realizes the auto valet parking service. Access control device. [Item 9] Item 8. An access control device according to item 8, The acceptance determination unit determines whether the vehicle position and the pre-set parking lot name match the information provided by the service provider. Access control device. [Item 10] Item 8 or Item 9, an access control device The vehicle APIs required to provide the auto valet parking service include a privacy-related API that provides a function to acquire information necessary to confirm that the vehicle's occupants have exited the vehicle, and a safety-related API that provides a function to control the behavior of the vehicle. Access control device.

Claims

1. an access control unit (10) configured to receive an access request from an API-using application (30) provided outside the vehicle and control access to the vehicle API, the API-using application (30) being an interface for providing a vehicle function of the vehicle; an acceptance determination unit (211, 212) configured to provide, via the vehicle API, a function of determining whether the vehicle can accept a target service that is a service provided by the API-using application; a start confirmation unit (222) configured to provide, via the vehicle API, a function of confirming with the user of the vehicle whether or not to start provision of the target service; Equipped with The access control unit a first granting unit (11: S150 to S160) configured to grant, to the API-using application, an access right to the vehicle API that provides the function of the start confirmation unit when the acceptance determination unit determines that the application is acceptable; a second granting unit (11: S170 to S200) configured to grant, when the start confirmation unit confirms the user's intention to start the target service, an access right to the vehicle API necessary for providing the target service to the API-using application; An access control device comprising:

2. The access control device according to claim 1, The API-using application is provided in an external device (200, 300) that is present within a range where peer-to-peer communication with the vehicle is possible. Access control device.

3. The access control device according to claim 1, Further, a settlement unit (251) configured to provide a function of settling the payment related to the target service via the vehicle API, The access control unit The system further includes a third granting unit (11: S210 to S220) configured to grant, when the termination of the target service is confirmed, an access right to the vehicle API that provides the function of the settlement unit to the API-using application. Access control device.

4. The access control device according to any one of claims 1 to 3, The target service is a platooning service that controls subsequent vehicles so that the subsequent vehicles maintain the platoon in accordance with instructions from a leading vehicle, The API-using application is provided in another vehicle (300) at the head of the platoon. Access control device.

5. 5. The access control device according to claim 4, The acceptance determination unit determines whether the vehicle is traveling on a road on which the platooning service is permitted. Access control device.

6. 5. The access control device according to claim 4, The acceptance determination unit determines whether at least one of the distance and the relative speed to the other vehicle is within an allowable range. Access control device.

7. 5. The access control device according to claim 4, The vehicle APIs necessary for providing the platooning service include a privacy-related API that provides a function for acquiring route information to the destination of the vehicle, and a safety-related API that provides a function for controlling the behavior of the vehicle. Access control device.

8. The access control device according to any one of claims 1 to 3, The target service is an auto valet parking service in which parking is entered and exited by automated driving, The API-using application is provided in an infrastructure device (200) installed in a parking lot that realizes the auto valet parking service. Access control device.

9. 9. The access control device according to claim 8, The acceptance determination unit determines whether the vehicle position and the pre-set parking lot name match the information provided by the service provider. Access control device.

10. 9. The access control device according to claim 8, The vehicle APIs necessary for providing the auto valet parking service include a privacy-related API that provides a function for acquiring information necessary to confirm that the occupants of the vehicle have exited the vehicle, and a safety-related API that provides a function for controlling the behavior of the vehicle. Access control device.

11. An access control method for controlling access to a vehicle API by receiving an access request from an API-using application (30) provided outside the vehicle, the method comprising: When an acceptance determination unit (211, 212) configured to provide a function of determining whether the vehicle can accept a target service, which is a service provided by the API-using application, via the vehicle API determines that the target service is acceptable, the API-using application is granted an access right to the vehicle API that provides the function of a start confirmation unit (222) (S150 to S160); The start confirmation unit is configured to provide the vehicle user with a function to confirm whether or not to start provision of the target service via the vehicle API. When the user's intention to start the service is confirmed, the start confirmation unit grants the API-using app an access right to the vehicle API required for providing the target service (S170 to S200). Access control methods.

Images