WO2024070774A1 - アクセス制御装置、アクセス制御方法 - Google Patents

アクセス制御装置、アクセス制御方法 Download PDF

Info

Publication number
WO2024070774A1
WO2024070774A1 PCT/JP2023/033750 JP2023033750W WO2024070774A1 WO 2024070774 A1 WO2024070774 A1 WO 2024070774A1 JP 2023033750 W JP2023033750 W JP 2023033750W WO 2024070774 A1 WO2024070774 A1 WO 2024070774A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
api
access control
access
service
Prior art date
Application number
PCT/JP2023/033750
Other languages
English (en)
French (fr)
Inventor
康章 栗田
圭 岡田
賢 丹羽
佑介 可児
英之 本谷
Original Assignee
株式会社デンソー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社デンソー filed Critical 株式会社デンソー
Publication of WO2024070774A1 publication Critical patent/WO2024070774A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles

Definitions

  • This disclosure relates to technology for providing services that utilize vehicle functions.
  • Patent Document 1 describes a system that includes a driving assistance device and an in-vehicle terminal, and in which multiple vehicles travel in a platoon according to a plan generated by the driving assistance device.
  • the in-vehicle device repeatedly transmits vehicle position information, planned route information, and other information to the center device.
  • the center device generates information for platooning based on information collected from multiple vehicles, and transmits this information to each vehicle in the platoon.
  • vehicle API When considering platooning of vehicles configured to provide their own information and functions via an API (hereinafter, vehicle API), it is necessary to allow access to the vehicle API from external devices (e.g., a center device or 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.
  • external devices e.g., a center device or other vehicles.
  • One aspect of the present disclosure provides a technique for appropriately restricting access to a vehicle API from outside the vehicle.
  • the access restriction unit is configured to receive an access request from an API-using app provided 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 or not 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 user of the vehicle whether or not to start providing the target service.
  • the access control unit includes a first granting unit and a second granting unit.
  • the first granting unit is configured to grant the API-using app access rights 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 the API-using app access rights to the vehicle API necessary for providing the target service when the start confirmation unit confirms the user's intention to start the service.
  • This configuration makes it possible to appropriately restrict access to the vehicle API from outside the vehicle.
  • One aspect of the present disclosure is an access control method that receives an access request from a service provider that provides an API-using service located outside the vehicle and controls access to a vehicle API.
  • the vehicle API is an interface for providing vehicle functions that the vehicle possesses.
  • the API-using app is an application that realizes a service that uses the vehicle API.
  • the acceptance determination unit is configured to provide, via the vehicle API, a function for determining whether or not 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, 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 user of the vehicle 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.
  • This method makes it possible to appropriately restrict access to the vehicle API from outside the vehicle.
  • FIG. 1 is a block diagram showing a configuration of a mobility service providing system 1.
  • FIG. FIG. 2 is a block diagram showing a functional configuration of the in-vehicle system.
  • 13 is a flowchart showing the processing contents in an authenticator providing unit; 13 is a flowchart showing the processing contents in an access restriction unit.
  • FIG. 2 is a sequence diagram showing a typical operation example of the in-vehicle system.
  • FIG. 2 is a sequence diagram showing a typical operation example of the in-vehicle system.
  • FIG. 2 is a sequence diagram showing a typical operation example of the in-vehicle system.
  • FIG. 11 is a block diagram showing a functional configuration when the API-utilizing service is a platooning service.
  • 11 is a block diagram showing a functional configuration when the API-using service is an AVP service.
  • FIG. 11 is a sequence diagram showing an example of the operation of an AVP service.
  • the mobility service providing system 1 of this embodiment includes an in-vehicle system 100 mounted in a vehicle, an automated valet parking (hereinafter, AVP) infrastructure 200, another vehicle 300, and a user terminal 400.
  • AVP automated valet parking
  • 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 equipped with only a manual driving function, or a vehicle having only an engine or only an electric motor as a driving source.
  • a vehicle equipped with the in-vehicle system 100 will simply be referred to as a vehicle.
  • the in-vehicle system 100 includes one ECU 2, multiple ECUs 3, multiple ECUs 4, an external communication device 5, and an in-vehicle communication network 6.
  • ECU stands for Electronic Control Unit.
  • the ECU 2 manages multiple ECUs 3 to achieve coordinated control of the entire vehicle.
  • the ECU 2 is connected to an in-vehicle communication network 6 to which multiple ECUs 3 are connected, and relays data frames communicated from each ECU 3 and an external communication device 5.
  • ECUs 3 are provided for each domain divided according to the vehicle's functions, and mainly control 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) that is provided individually for each ECU 3.
  • CAN is an abbreviation for Controller Area Network and is a registered trademark.
  • ECUs 3 have the function of centrally managing access rights to the subordinate ECUs 4 and authenticating users, etc. Domains include, for example, the powertrain, body, chassis, and cockpit.
  • 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.
  • the ECUs 4 connected to the ECUs 3 belonging to the body domain include, for example, an ECU 4 that controls the air conditioner and an ECU 4 that controls the doors.
  • the ECU 4 connected to the ECU 3 belonging to the chassis domain includes, for example, an ECU that controls the brakes and an ECU that controls the steering.
  • the ECUs 4 connected to the ECUs 3 belonging to the cockpit domain include, for example, ECUs 4 that control the display of meters and navigation systems, and ECUs 4 that control the in-vehicle HMI operated by the vehicle user (hereinafter, "user").
  • HMI is an abbreviation for Human Machine Interface.
  • the external vehicle communication device 5 performs peer-to-peer data communication within a small range (e.g., within a few tens of meters) with external devices that provide API-based services (i.e., AVP infrastructure 200 and other vehicles 300). The API-based services will be described later.
  • the external vehicle communication device 5 also performs data communication with a user terminal 400 carried by the user via a wide-area wireless communication network.
  • 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.
  • the CAN FD connects the ECU 2 to each ECU 3 and the external-vehicle communication device 5 via a bus.
  • the Ethernet individually connects the ECU 2 to each ECU 3 and the external-vehicle communication device 5.
  • ECU2 is an electronic control device that is mainly composed of a microcomputer equipped with a CPU2a, a ROM2b, and a RAM2c.
  • the various functions of the microcomputer are realized by CPU2a executing a program stored in a non-transient physical recording medium.
  • ROM2b corresponds to the non-transient physical recording medium that stores the program.
  • a method corresponding to the program is executed. Note that some or all of the functions executed by CPU2a may be configured in hardware using one or more ICs, etc. Also, the number of microcomputers that make up ECU2 may be one or more.
  • ECU3, ECU4, and external vehicle communication device 5 are electronic control devices that are configured around a microcomputer equipped with a CPU, ROM, RAM, etc., just like ECU2. Furthermore, the number of microcomputers that make up ECU3, ECU4, and external vehicle communication device 5 may be one or more.
  • ECU2, ECU3, ECU4, and external vehicle communication device 5 will be referred to as in-vehicle devices 2 to 5 unless otherwise specified.
  • AVP infrastructure 200 is infrastructure installed in parking lots that provide the AVP service.
  • the AVP service is a service in which vehicles automatically drive in large unmanned parking lots and automatically park in vacant parking spaces.
  • the AVP infrastructure 200 includes a communication unit 201, an HMI unit 202, and a control unit 203.
  • the communication unit 201 performs peer-to-peer data communication with the in-vehicle system 100 within a small range.
  • the HMI unit 202 is used to input information and commands necessary for providing the AVP service.
  • the HMI unit 202 may be configured to input information and commands via the user terminal 400.
  • the control unit 203 is mainly composed of a microcomputer equipped with 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, and performs vehicle control such as sending and receiving information necessary to start the AVP service and steering and accelerating and decelerating 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.
  • the vehicle API is a standardized interface used to access functions provided by a vehicle, and is not dependent on a specific vehicle model or grade.
  • the vehicle API is configured so that even engineers who are not familiar with the characteristics and constraints of the vehicle can easily develop service apps that use the vehicle API.
  • 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.
  • the service app implemented in the vehicle that will be the lead vehicle in the platoon accesses the vehicle API of the in-vehicle system 100 of the vehicle that will be the following vehicle in the platoon.
  • 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.
  • the user terminal 400 is, for example, a mobile terminal such as a smartphone or tablet.
  • 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 disposed in any of the in-vehicle devices 2 to 5.
  • the access control unit 10, the vehicle function unit 20, and the vehicle API unit 50 are disposed in the ECU 2.
  • the vehicle function unit 20 is a set of modules that subdivide the functions of the vehicle. Each module belonging to the vehicle function unit 20 is mounted in one of the in-vehicle devices 2 to 5.
  • the modules belonging to the vehicle function unit 20 have multiple categories, and different access restrictions are set for each category.
  • a vehicle API for which access restrictions have been set will only accept and process an API access request if an authenticator corresponding to the category to which it belongs is attached to the API access request.
  • the vehicle function unit 20 has four categories corresponding to four attributes F, S, O, and P defined as security-protected assets, and one category with no access restrictions.
  • F stands for Financial
  • S stands for Safety
  • O stands for Operational
  • P stands for Privacy.
  • 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, corresponding to each division. Furthermore, the vehicle function unit 20 includes a vehicle state database (hereinafter, vehicle state DB) 26.
  • vehicle state DB vehicle state database
  • 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.
  • Vehicle state DB26 stores vehicle state data that indicates the state of the vehicle.
  • the vehicle state data stored in vehicle state DB26 is updated successively.
  • the vehicle state data includes at least the vehicle's position and driving 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.
  • the vehicle API unit 50 is a set of vehicle APIs prepared to access 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.
  • the N-system API group 51 is a collection of vehicle APIs (hereinafter, N-system APIs) used to access each module belonging to the N-system function 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.
  • the N-system functional block group 21 may include, for example, an acceptance determination module 211, a reliability confirmation module 212, and an end determination module 213, as shown in FIG. 5 and FIG. 10.
  • the acceptance determination module 211 provides a function of determining whether the vehicle is in a state in which it can accept a service provided by an API-using application, and notifying the provider of the API-using application.
  • 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 application, and notifying the access control unit 10 of the determination result.
  • the end determination module 213 provides a function of determining whether the condition for ending the target service is satisfied, and if satisfied, notifying the access control unit 10 of that fact.
  • the O-system API group 52 is a set of vehicle APIs (hereinafter, O-system APIs) used to access each module belonging to the O-system functional block group 22.
  • O-system APIs accept an access request when an O-system authenticator is attached to the access request.
  • 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 to confirm whether or not there is an intention to receive the provision of a service, using the in-vehicle HMI equipped in the vehicle.
  • the start confirmation module 222 provides a function to confirm whether or not it is OK to start the provision of a service, using the in-vehicle HMI equipped in the vehicle.
  • the P-system API group 53 is a collection of vehicle APIs (hereinafter, P-system APIs) used to access each module belonging to the P-system function block group 23.
  • P-system APIs vehicle APIs (hereinafter, P-system APIs) used to access each module belonging to the P-system function block group 23.
  • the P-system APIs accept an access request when a P-system authenticator is attached to the access request.
  • 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 to read 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 to access privacy information stored in the vehicle (for example, an image taken of the inside of the vehicle cabin) and notify information obtained from the image (for example, the presence or absence of an occupant).
  • the S-system API group 54 is a vehicle API (hereinafter, S-system API) used to access each module belonging to the S-system function block group 24.
  • S-system API a vehicle API (hereinafter, S-system API) used to access each module belonging to the S-system function block group 24.
  • the S-system API accepts an access request when an S-system authenticator is attached to the access request.
  • 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 and acceleration/deceleration, and includes different modules for each type of vehicle control.
  • the F-system API group 55 is a collection of vehicle APIs (hereinafter, F-system APIs) used to access each module belonging to the F-system function block group 25.
  • F-system APIs vehicle APIs (hereinafter, F-system APIs) used to access each module belonging to the F-system function block group 25.
  • the F-system APIs accept an access request when an F-system authenticator is attached to the access request.
  • the F-system functional block group 25 may include, for example, an account settlement module 251.
  • the account settlement module 251 provides a function for settling fees for the services provided.
  • API-using apps The service application 30 that realizes a desired function by 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.
  • the API-using application may be installed in the in-vehicle system 100, but here we will explain the case where it is installed in an external device such as the AVP infrastructure 200 or another vehicle 300.
  • the API-using app may be provided by the OEM or a third party.
  • 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.
  • Third parties are those other than the vehicle owner and the OEM.
  • Services provided by API-using apps include, for example, a platooning service that realizes platooning by autonomous driving, and an AVP service that realizes AVP by autonomous driving.
  • the platooning service the other vehicle 300 traveling at the front of the platoon corresponds to the external device in this disclosure.
  • the AVP infrastructure 200 installed in the parking lot corresponds to the external device in this disclosure.
  • an API-using application uses a function provided by the vehicle function unit 20, it sends 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 the service application that is the source of use (hereinafter, the source application) and information identifying the vehicle API that is the destination of use (hereinafter, the destination API).
  • the API access request may be provided with an authenticator indicating that the application has access rights to a specific API.
  • the API access request is forwarded to the vehicle API unit 50 via the access control unit 10, and is then forwarded from the vehicle API unit 50 to the vehicle function unit 20.
  • 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 .
  • the access control unit 10 includes an authentication code assignment unit 11, an access restriction unit 12, and an access management database (hereinafter, access management DB) 13.
  • the authenticator granting unit 11 executes a process of granting an authenticator prepared for each category to an API-using application.
  • an API-using application that uses the vehicle API of the vehicle is referred to as a target application 30.
  • a service provided by a target application 30 is referred to as a target service.
  • the authenticator assignment process executed by the authenticator assignment unit 11 will be explained using the flowchart shown in FIG. 3.
  • the authenticator assignment process is executed individually for each API-using application.
  • the authenticator granting unit 11 determines whether or not the vehicle is in a state in which 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 vehicle's in-vehicle system 100, for example, when the target service is to be used. If the vehicle is in a state in which it can accept the target service, the acceptance determination module 211 notifies the authenticator granting unit 11 of that effect.
  • the acceptance determination module 211 receives reliability information from an external device that is the provider of the target service, and determines whether the service is provided by the service provider intended by the driver based on the reliability information provided.
  • the target service is platooning
  • the leading vehicle in the platoon becomes the service provider
  • the position and driving speed of the leading vehicle are used as reliability information.
  • the target service is automatic parking
  • the infrastructure that provides the automatic parking service becomes the service provider
  • the location and name of the infrastructure are used as reliability information.
  • the acceptance determination module 211 compares the reliability information provided by the service provider with the vehicle's position, driving speed, map information, etc. stored in the vehicle state DB 26 to determine whether the vehicle is in a position where the service can be provided.
  • the position where the service can be provided may be, for example, a position where the vehicle and infrastructure that are the service provider are visible to the driver of the vehicle.
  • 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. If 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.
  • the authenticator granting unit 11 sends an acceptance notification to the target application 30 implemented in the external device.
  • 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 settlement process has ended is received from the settlement module 251. In addition, when the settlement 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.
  • the completion determination module 213, like the acceptance determination module 211, is installed in advance in the in-vehicle system 100 of the vehicle when the target service is used. When the completion condition for terminating the service is satisfied, 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 satisfied based on, for example, vehicle state data stored in the vehicle state 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.
  • the authenticator granting unit 11 determines that the service has ended, it transitions the process to S140, and if it determines that the service has not ended, it transitions the process to S150.
  • the authenticator assignment unit 11 invalidates the authenticator assigned to the target application 30 in S160, S180, S200, and S220 described below, and ends the process.
  • the authenticator granting unit 11 determines whether the O-system opening condition that permits access to the O-system API is satisfied, and if the O-system opening condition is satisfied, the process proceeds to S160, and if the O-system opening condition is not satisfied, the process proceeds to S170.
  • the authenticator granting unit 11 grants an O-system authenticator to the target application 30 implemented in the external device, and returns the process to S130.
  • the authenticator granting unit 11 determines whether the P system opening condition that permits access to the P system API is met, and if the P system opening condition is met, the process proceeds to S180, and if the P system opening condition is not met, the process proceeds to S190.
  • the authenticator granting unit 11 grants a P-type authenticator to the target application 30 implemented in the external device, and returns the process to S130.
  • the authenticator granting unit 11 determines whether the S-system opening condition that permits access to the S-system API is satisfied, and if the S-system opening condition is satisfied, the process proceeds to S200, and if the S-system opening condition is not satisfied, the process proceeds to S210.
  • the authenticator granting unit 11 grants an S-type authenticator to the target application 30 implemented in the external device, and returns the process to S130.
  • the authenticator granting unit 11 determines whether the F-system opening condition that permits access to the F-system API is met, and if the F-system opening condition is met, the process proceeds to S220, and if the F-system opening condition is not met, the process returns to S130.
  • the authenticator granting unit 11 grants an F-system authenticator to the target application 30 implemented in the external device, and returns the process to S130.
  • the release conditions used in S150, S170, S190, and S210 may include, for example, that the result of the process executed in response to an API access request from the target application 30 is a predetermined content.
  • the release conditions may also include 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.
  • the access restriction unit 12 classifies the authenticators assigned to the target application 30 in S160, S180, S200, and S220 into categories of O, P, S, and F, 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.
  • the access restriction unit 12 receives an API access request from a target application 30 (i.e., an external device) and executes an access restriction process to determine whether or not to permit access to the vehicle API to be accessed.
  • a target application 30 i.e., an external device
  • the access restriction process executed by the access restriction unit 12 will be explained using the flowchart shown in FIG. 4.
  • the access control process is executed in common for all API-using applications.
  • 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, it transitions to S320, and if it determines that an API access request has not been received, it waits by repeating the same step.
  • 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, the process proceeds to S350, and if it is not an N-system API, the process proceeds to 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.
  • 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.
  • 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 source target application 30 that the API access request has been discarded.
  • the in-vehicle system 100 uses the acceptance determination module 211 to determine whether the vehicle itself is in a state in which it can accept the target service. Then, as shown in FIG. 5, the in-vehicle system 100 transmits a result notification M1 indicating the result of the determination made by the acceptance determination module 211 to the target application 30 implemented in the external device.
  • the target application 30 that receives the result notification M1 indicating that the service can be accepted sends an API access request M2 to the reliability confirmation module 212.
  • Reliability information which is information related to the reliability of the service itself, is attached to the API access request M2.
  • the access control unit 10 which has received the API access request M2, checks the destination API indicated in the API access request M2. In this case, since it is a request to access an N-system API (i.e., a positive judgment is made in S320), the access control unit 10 transfers 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 transferred API access request M2.
  • the reliability confirmation module 212 that receives the API access request M2 sends a reliability notification M3 to the access control unit 10 indicating the result of determining the reliability of the target service based on the reliability information attached to the API access request M2.
  • the access control unit 10 receives the reliability notification M3 and determines that the target service is sufficiently reliable, it regards the O-system opening condition as being met (i.e., a positive determination was made in S150) and sends 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 if the reliability of the target service in the reliability notification M3 exceeds a predetermined threshold.
  • 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 the grant of access to the O-system API is denied, as shown in FIG. 6.
  • the target application 30 that has received the access permission notification M4 sends 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.
  • the access control unit 10 which has received the API access request M6, checks the destination API, etc., indicated in the API access request M6. In this case, it is a request for access to 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 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.
  • the ECU that receives the provision confirmation request M7 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 makes an input, it returns a user response M8 indicating the input content to the provision confirmation module 221.
  • the provision confirmation module 221 which receives the user response M8, sends a provision confirmation notification M9 indicating the user's intention indicated in the user response M8 to the access control unit 10.
  • the access control unit 10 upon receiving the provision confirmation notification M9, regards it as the P-system opening condition being met (i.e., a positive judgment was made in S170) and sends the access permission notification M10 with the P-system authenticator attached to the target application 30. Also, if the provision confirmation notification M9 indicates that the provision of the target service is not desired, the access control unit 10 sends the target application 30 an access refusal notification M11 indicating that the grant of access to the P-system API is being refused, as shown in FIG. 7.
  • the target application 30 that has received the access permission notification M10 sends an API access request M12 to the information providing module 231.
  • the P-system authenticator acquired in the access permission notification M10 is attached to the API access request M12.
  • the access control unit 10 which has received the API access request, 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 provision module 231, which is a destination module, in accordance with the forwarded API access request M12.
  • the information provision module 23 which operates in accordance with the API access request M12, obtains the privacy information indicated in the API access request M12 and transmits the obtained privacy information to the target application 30 via an information provision notification M13.
  • the target application 30 that receives the information provision notification M13 sends 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.
  • the access control unit 10 which has received the API access request M14, checks the destination API, etc., indicated in the API access request M14. In this case, it is a request for access to 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.
  • the start confirmation module 222 which operates in accordance with the API access request M14, sends a start confirmation request M15 to the ECU that controls the in-vehicle HMI.
  • the ECU that receives the start confirmation request M15 displays a message via the 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.
  • the start confirmation module 222 that receives the user response M16 sends a start necessity notification M17 indicating the user's intention indicated in the user response M16 to the access control unit 10.
  • the access control unit 10 upon receiving the start necessity notification M17, regards it as the S-system opening condition being met (i.e., a positive judgment was made in S190) and sends an access permission notification M18 with an S-system authenticator attached to the target application 30. Also, if the start necessity notification M17 indicates that the target service is not desired to be started, the access control unit 10 sends an access refusal notification (not shown) to the target application 30 indicating that the grant of access to the S-system API is being refused.
  • the target application 30 that receives the access permission notification M18 sends an API access request M19 to the vehicle control module 241.
  • the S-system authenticator acquired in the access permission notification M18 is attached to the API access request M19.
  • the access control unit 10 which has received the API access request M19, checks the destination API, etc., indicated in the API access request M19. In this case, it is a request for access to an S-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 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.
  • the vehicle control module 241 operating in accordance with the API access request M19, executes the vehicle control required 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.
  • the target application needs to terminate the service, it sends an API access request M20 to the termination determination module 213.
  • the access control unit 10 which has received the API access request M20, checks the destination API, etc., indicated in the API access request M20. In this case, since it is a request to access an N-system API (i.e., a positive judgment is made in S320), the access control unit 10 transfers the API access request M20 to the destination API.
  • the destination API activates the termination judgment module 213, which is a destination module, in accordance with the transferred API access request M20.
  • the termination condition is not limited to receiving the API access request M20, but may also include detection of a vehicle abnormality, etc.
  • the access control unit 10 having received the completion notification M21, determines that the F-system opening condition has been met (i.e., a positive determination was made in S210), and sends an access permission notification M22 with an F-system authenticator attached to the target application 30.
  • the target application 30 that receives the access permission notification M22 sends an API access request M23 to the settlement module 251.
  • the F-system authenticator acquired in the access permission notification M22 is attached to the API access request M23.
  • the access control unit 10 which has received the API access request M23, checks the destination API, etc., indicated in the API access request M23. In this case, it is a request for access to an F-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 M23 to the destination API.
  • the destination API operates the settlement module 251, which is a destination module, in accordance with the forwarded API access request M23.
  • the settlement module 25 which operates in accordance with the API access request M23, executes the process of settling the costs incurred for the target service, and then sends a payment completion notification M24 to the access control unit 10.
  • the access control unit 10 having received the payment completion notification M24, assumes that the service has been completed (i.e., a positive judgment was made in S130), invalidates each authenticator that was assigned to the target application 30 during the processing, and sends a service completion notification M25 to the target application.
  • the target application 30 that receives the service termination notification M25 discards each authenticator that was assigned by the access control unit 10 as a processing assumption, and terminates the provision of the service.
  • the access control unit 10 may assume that the service has ended (i.e., a positive determination has been made in S130) upon receiving the end notification M21, and may invalidate the authenticator and send a service end notification M25 to the target application 30.
  • the other vehicle 300 that is the lead vehicle in the platoon is an external device that provides a service (hereinafter, the service providing vehicle).
  • the service providing vehicle 300 is equipped with a service app (hereinafter, the target app) 30 for providing the platooning service.
  • 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 a highway.
  • 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 is higher the closer the service providing vehicle is to the vehicle itself and the slower the relative speed between the vehicle itself and the vehicle.
  • the reliability being equal to or greater than a threshold value may be used as a criterion for determining whether the service providing vehicle is sufficiently reliable.
  • the criterion for determining whether at least one of the distance and the relative speed between the service providing vehicle and the vehicle itself is within an acceptable range may also be used.
  • the information provision module 231 used in the convoy driving service may provide route information to the destination as privacy information to the target application 30.
  • the route information may be set, for example, using a navigation device installed in the vehicle.
  • 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 a command to leave the convoy is received from the service providing vehicle, when there is an input from the user via the in-vehicle HMI requesting to leave the convoy, etc.
  • the in-vehicle system 100 of the vehicle grants an O-system authenticator to the target application 30.
  • the target application 30 uses the granted 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.
  • the in-vehicle system 100 grants a P-system authenticator to the target application 30.
  • the target application 30 uses the granted 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.
  • the target application 30 uses the previously granted O-system authenticator to access the start confirmation module 222 belonging to the O-system functional block group 22 to confirm with the user again whether or not to start the provision of the service.
  • the in-vehicle system 100 grants 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.
  • 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 a settlement module 251 belonging to the F-system functional block group 25, thereby performing settlement for the service provided by the target application 30.
  • the in-vehicle system 100 invalidates each authenticator assigned to the target application 30.
  • an AVP infrastructure 200 installed in a parking lot becomes 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 for calling a parked vehicle.
  • the vehicle may be called using the user terminal 400.
  • the AVP service procedures are as shown in Figures 5 to 7, including service acceptance judgment, service reliability confirmation, confirmation of the need to provide the service to the user, and service termination/settlement, i.e., the procedures using messages M1 to M10 and M20 to M25, are the same as the general procedures shown in Figures 5 to 7.
  • the acceptance determination module 211 used in the AVP service may determine that the vehicle is acceptable if, for example, the vehicle's location is near a parking lot where the AVP service is provided.
  • the reliability confirmation module 212 used in the AVP service may obtain, as reliability information, the location and name of the parking lot providing the AVP service from the target application 30, and if the location and name of the parking lot where the user plans to park match those stored in advance, determine that the AVP infrastructure 200 is reliable.
  • the target application 30 that has received the access permission notification M10 sends an API access request M31 to the alighting confirmation module 232 that belongs 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 passengers have alighted based on the results of image analysis, etc., and sends the confirmation result to the access control unit 10. Since the processing in the alighting confirmation module 232 includes access to privacy 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.
  • the access control unit 10 which has received the API access request M31, checks the destination API, etc., indicated in the API access request M31. 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 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.
  • the disembarkation confirmation module 232 which is activated in accordance with the API access request M31, sends a disembarkation confirmation notification M32 to the access control unit 10, indicating whether 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 sends an access permission notification M33 with an S-system authenticator attached to the target application 30. If the alighting confirmation notification M32 indicates that there are passengers who have not yet alighted, the access control unit 10 sends an access denial notification (not shown) to the target application 30 indicating that access permission to the S-system API is denied.
  • the target application 30 that receives the access permission notification M33 sends an API access request M34 to the vehicle control module 241.
  • the S-system authenticator acquired in the access permission notification M33 is attached to the API access request M34.
  • the access control unit 10 receives the API access request M34, 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.
  • the vehicle control module 241 operating in accordance with the API access request M34, executes vehicle control in accordance with the instructions indicated in the API access request M34.
  • the target application 30 repeatedly sends the API access request M34 until the vehicle reaches the parking space. As a result, the vehicle enters the parking space by autonomous driving.
  • the target application 30 that has received the call command via the vehicle call device 40 sends an API access request M35 to the vehicle control module 241.
  • the S-system authenticator acquired in the access permission notification M33 is attached to the API access request M35.
  • the access control unit 10 which receives the API access request M35, checks the destination API, etc., and transfers the API access request M35 to the destination API.
  • the destination API operates the destination module, the vehicle control module 241, in accordance with the API access request M35.
  • the vehicle control module 241 operating in accordance with the API access request M35, executes vehicle control in accordance with the instructions indicated 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 reaches the designated boarding/disembarking space. As a result, the vehicle leaves the parking space by autonomous driving.
  • the target application 30 sends an API access request M20 to the end determination module 213.
  • the following procedure is the same as the general procedure shown in FIG. 5.
  • the vehicle-mounted system 100 of the vehicle grants an O-system authenticator to the target application 30.
  • the target application 30 uses the granted O-system authenticator to access the provision confirmation module 221 belonging to the O-system function block group 22 to confirm with the user whether or not the user intends to receive the service.
  • the vehicle-mounted system 100 grants a P-system authenticator to the target application 30.
  • the target application 30 uses the granted P-system authenticator to access the disembarking confirmation module 232 belonging to the P-system function block group 23 to confirm that all occupants have disembarked from an image of the vehicle interior.
  • the vehicle-mounted system 100 grants an S-system authenticator to the target application 30.
  • the target application 30 uses the granted S-system authenticator to repeatedly access the vehicle control module 241 belonging to the S-system function block group 24 to execute vehicle control to realize parking.
  • 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.
  • 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.
  • settlement is completed, the in-vehicle system 100 invalidates each authenticator assigned to the target application 30.
  • the in-vehicle system 100 corresponds to the access control device in this disclosure
  • the acceptance determination module 211 and the reliability confirmation module 212 correspond to the acceptance determination unit in this disclosure
  • the start confirmation module 222 corresponds to the start confirmation unit in this disclosure
  • the settlement module 251 corresponds to the settlement unit in this disclosure.
  • the authenticator granting unit 11 corresponds to the first granting unit to the third granting unit in this disclosure.
  • the processes of S150 to S160 correspond to the first granting unit in this disclosure
  • the processes of S170 to S200 correspond to the second granting unit in this disclosure
  • the processes of S210 to S220 correspond to the third granting unit in this disclosure.
  • a center device which causes a time lag depending on the processing status at 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 moving vehicle where the surrounding conditions are constantly changing in real time.
  • such a time lag can prevent a user from being unable to receive the necessary service at the moment they need it, which can result in, for example, missing an opportunity to join or leave the platoon.
  • the API-using service is an AVP service
  • the image information of the vehicle interior which is private information
  • the AVP infrastructure is granted access to the vehicle API that provides vehicle control. This makes it possible to prevent the vehicle from moving into a parking space while leaving some of the occupants locked inside the vehicle.
  • the vehicle API is classified by FSOP and access rights are granted for each classification together, but for example, the stage at which access rights are granted may be different for each type of vehicle control within the S classification.
  • the in-vehicle devices 2 to 5 and the method thereof described in the present disclosure may be realized by a dedicated computer provided by configuring a processor and a memory programmed to execute one or more functions embodied in a computer program.
  • the in-vehicle devices 2 to 5 and the method thereof described in the present disclosure may be realized by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits.
  • the in-vehicle devices 2 to 5 and the method thereof described in the present disclosure may be realized by one or more dedicated computers configured by combining a processor and a memory programmed to execute one or more functions and a processor configured with one or more hardware logic circuits.
  • the computer program may be stored in a computer-readable non-transient tangible recording medium as instructions executed by a computer.
  • the method for realizing the functions of each part included in the in-vehicle devices 2 to 5 does not necessarily need to include software, and all of the functions may be realized using one or more hardware.
  • Multiple functions possessed by one component in the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by 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.
  • the present disclosure can 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 the program is recorded, and an access control method.
  • an access control unit 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; and an acceptance determination unit (211, 212) configured to provide, via the vehicle API, a function of determining whether or not 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 a function of confirming with a user of the vehicle whether or not to start provision of the target service via the vehicle API; Equipped with The access control unit a first granting unit (11: S150 to S160) configured to grant, when the acceptance determination unit determines that the application is acceptable, an access right to the vehicle API that provides a function of the start confirmation unit to the API-using application; 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
  • the access control device according to item 1 or 2, A settlement unit (251) configured to provide a function of settling a payment related to the target service via the vehicle API,
  • the access control unit further includes a third granting unit (11: S210 to S220) configured to grant access rights to the vehicle API that provides the function of the settlement unit to the API-using application when the termination of the target service is confirmed.
  • the access control device according to any one of claims 1 to 3,
  • the target service is a platooning service that controls the following vehicles so that the following vehicles maintain the platoon in accordance with instructions from a leading vehicle,
  • the access control device includes the API-utilizing application in another vehicle (300) at the front of the platoon.
  • Item 4 Item 4.
  • An access control device comprising: The access control device, wherein the acceptance determination unit includes in a determination condition that the vehicle is traveling on a road on which the provision of the platooning service is permitted.
  • the access control device according to item 4 or 5 The access control device, wherein the acceptance determination unit includes in its determination conditions that at least one of a distance and a relative speed with respect to the other vehicle is within an allowable range.
  • the vehicle API necessary for providing the platooning service includes a privacy-related API that provides a function of obtaining route information to the destination of the vehicle, and a safety-related API that provides a function of controlling the behavior of the vehicle. Access control device.
  • the access control device according to any one of claims 1 to 3,
  • the target service is an auto valet parking service in which entering and leaving a parking lot is done by autonomous driving
  • the access control device includes an infrastructure device (200) installed in a parking lot that realizes the auto valet parking service, and the API-using application is included in the access control device.
  • Item 9 Item 9. An access control device according to item 8, An access control device, wherein the acceptance determination unit includes in its determination conditions that the position of the vehicle and a pre-set parking lot name match the information provided by the service provider.
  • the access control device includes a privacy-related API that provides a function for obtaining information necessary to confirm that the vehicle's occupants have disembarked, and a safety-related API that provides a function for controlling the behavior of the vehicle. Access control device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Health & Medical Sciences (AREA)
  • Human Computer Interaction (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Traffic Control Systems (AREA)

Abstract

アクセス制御部（１０）は、受入判定部（２１１，２１２）にて受け入れ可能と判定された場合、開始確認部（２２２）の機能を提供する車両ＡＰＩに対するアクセス権を、ＡＰＩ利用アプリ（３０）に付与する。アクセス制御部は、開始確認部にて、利用者の開始意図が確認された場合、対象サービスの提供に必要な車両ＡＰＩに対するアクセス権を、ＡＰＩ利用アプリに付与する。

Description

アクセス制御装置、アクセス制御方法 関連出願の相互参照
　本国際出願は、２０２２年９月２９日に日本国特許庁に出願された日本国特許出願第２０２２－１５６６９０号に基づく優先権を主張するものであり、日本国特許出願第２０２２－１５６６９０号の全内容を本国際出願に参照により援用する。
　本開示は、車両機能を利用したサービスを提供する技術に関する。
　特許文献１には、運行支援装置と車載端末とを備え、運行支援装置が生成した計画に従って、複数の車両が隊列走行を行うシステムが記載されている。
　隊列走行システムにおいて、車載装置は、車両の位置情報及び走行を予定している経路情報等を、センター装置に繰り返し送信する。センター装置は、複数の車両から収集した情報に基づいて、隊列走行を行うための情報を生成し、隊列を構成する各車両に送信する。
特開２０１８－１８１１４２号公報
　ところで、自身が有する情報や機能を、ＡＰＩ（以下、車両ＡＰＩ）を介して提供するように構成された車両による隊列走行を考えた場合、外部装置（例えば、センタ装置や他車両）からの車両ＡＰＩへのアクセスを許容する必要がある。しかしながら、このような外部装置からの車両ＡＰＩへのアクセスによって、サービスの提供に関係のない個人情報が漏洩したり、ユーザの意図しない不正な車両制御が行われたりすることを抑止する必要があった。
　本開示の１つの局面は、車両ＡＰＩに対する車両外部からのアクセスを適切に制限する技術を提供する。
　本開示の一態様は、アクセス制御装置であって、アクセス制御部と、受入判定部と、開始確認部と、を備える。アクセス制限部は、車両の外部に設けられたＡＰＩ利用アプリからのアクセス要求を受け付けて、車両ＡＰＩへのアクセスを制御するように構成される。車両ＡＰＩは、車両が有する車両機能を提供するためのインタフェースである。ＡＰＩ利用アプリは、車両ＡＰＩを利用したサービスを実現するアプリケーションである。受入判定部は、車両がＡＰＩ利用アプリによるサービスである対象サービスを受け入れ可能であるか否かを判定する機能を、車両ＡＰＩを介して提供するように構成される。開始確認部は、対象サービスの提供を開始するか否かを車両の利用者に確認する機能を、車両ＡＰＩを介して提供するように構成される。
　アクセス制御部は、第１付与部と、第２付与部と、を備える。第１付与部は、受入判定部にて受け入れ可能と判定された場合、開始確認部の機能を提供する車両ＡＰＩに対するアクセス権を、ＡＰＩ利用アプリに付与するように構成される。第２付与部は、開始確認部にて、利用者の開始意図が確認された場合、対象サービスの提供に必要な車両ＡＰＩに対するアクセス権を、ＡＰＩ利用アプリに付与するように構成される。
　このような構成によれば、車両ＡＰＩに対する車両外部からのアクセスを適切に制限することができる。
　本開示の一態様は、車両の外部に設けられたＡＰＩ利用サービスを提供するサービス提供元からのアクセス要求を受け付けて、車両ＡＰＩへのアクセスを制御するアクセス制御方法である。車両ＡＰＩは、車両が有する車両機能を提供するためのインタフェースである。ＡＰＩ利用アプリは、車両ＡＰＩを利用したサービスを実現するアプリケーションである。
　受入判定部は、車両がＡＰＩ利用アプリによるサービスである対象サービスを受け入れ可能であるか否かを判定する機能を、車両ＡＰＩを介して提供するように構成される。受入判定部にて、受け入れ可能と判定された場合、開始確認部の機能を提供する車両ＡＰＩに対するアクセス権を、サービス提供元に付与する。開始確認部は、車両の利用者に対して、対象サービスの提供を開始するか否かを確認する機能を、車両ＡＰＩを介して提供するように構成される。開始確認部にて、利用者の開始意図が確認された場合、対象サービスの提供に必要な車両ＡＰＩに対するアクセス権を、ＡＰＩ利用アプリに付与する。
　このような方法によれば、車両ＡＰＩに対する車両外部からのアクセスを適切に制限することができる。
モビリティサービス提供システム１の構成を示すブロック図である。 車載システムの機能構成を示すブロック図である。 認証子付与部での処理内容を示すフローチャートである。 アクセス制限部での処理内容を示すフローチャートである。 車載システムの代表的な動作例を示すシーケンス図である。 車載システムの代表的な動作例を示すシーケンス図である。 車載システムの代表的な動作例を示すシーケンス図である。 ＡＰＩ利用サービスが隊列走行サービスである場合の機能構成を示すブロック図である。 ＡＰＩ利用サービスがＡＶＰサービスである場合の機能構成を示すブロック図である。 ＡＶＰサービスの動作例を示すシーケンス図である。
　以下、図面を参照しながら、本開示の実施形態を説明する。
　［１．構成］
　本実施形態のモビリティサービス提供システム１は、図１に示すように、車両に搭載される車載システム１００と、自動バレーパーキング（以下、ＡＶＰ）インフラ２００と、他車両３００と、ユーザ端末４００とを備える。
　車載システム１００を搭載する車両は、手動運転機能に加えて自動運転機能を有していてもよい。車両は、走行駆動源として、エンジンと電動モータとを有するハイブリッド車両であってもよい。車両は、自動運転機能を有する車両とハイブリッド車両とに限らず、手動運転機能のみを備える車両であってもよいし、走行駆動源としてエンジンのみ又は電動モータのみを有する車両であってもよい。以下では、車載システム１００を搭載する車両を、単に車両という。
　車載システム１００は、一つのＥＣＵ２と、複数のＥＣＵ３と、複数のＥＣＵ４と、車外通信装置５と、車内通信網６とを備える。ＥＣＵは、Electronic Control Unitの略である。
　ＥＣＵ２は、複数のＥＣＵ３を統括することにより、車両全体として連携がとれた制御を実現する。ＥＣＵ２は、複数のＥＣＵ３が接続される車内通信網６に接続され、各ＥＣＵ３及び車外通信装置５から通信されるデータフレームを中継する。
　ＥＣＵ３は、車両における機能によって区分けしたドメイン毎に設けられ、主として、そのドメイン内に存在する複数のＥＣＵ４の制御を実行する。各ＥＣＵ３は、それぞれ個別に設けられた下層ネットワーク（例えば、ＣＡＮ）を介して配下のＥＣＵ４と接続される。ＣＡＮは、Controller Area Networkの略であり、登録商標である。ＥＣＵ３は、配下のＥＣＵ４に対するアクセス権限などを一元的に管理し利用者の認証等を行う機能を有する。ドメインは、例えば、パワートレーン、ボデー、シャシ、及びコックピット等である。
　パワートレーンのドメインに属するＥＣＵ３に接続されるＥＣＵ４は、例えば、エンジンを制御するＥＣＵ４、モータを制御するＥＣＵ４、及び、バッテリを制御するＥＣＵ４等を含む。
　ボデーのドメインに属するＥＣＵ３に接続されるＥＣＵ４は、例えば、エアコンを制御するＥＣＵ４、及び、ドアを制御するＥＣＵ４等を含む。
　シャシドメインに属するＥＣＵ３に接続されるＥＣＵ４は、例えば、ブレーキを制御するＥＣＵ、及び、ステアリングを制御するＥＣＵ等を含む。
　コックピットのドメインに属するＥＣＵ３に接続されるＥＣＵ４は、例えば、メータやナビゲーションの表示を制御するＥＣＵ４、及び、車両の利用者（以下、ユーザ）によって操作される車載ＨＭＩを制御するＥＣＵ４等を含む。ＨＭＩは、Human Machine Interfaceの略である。
　車外通信装置５は、ＡＰＩ利用サービスを提供する外部装置（すなわち、ＡＶＰインフラ２００や他車両３００）との間で、ピアツーピアによる狭い範囲内（例えば、数十ｍ以内）のデータ通信を行う。ＡＰＩ利用サービスについては、後述する。また、車外通信装置５は、広域無線通信網を介して、ユーザが所持するユーザ端末４００との間でデータ通信を行う。
　車内通信網６は、例えば、ＣＡＮ　ＦＤとイーサネットとを備える。イーサネットは登録商標である。ＣＡＮ　ＦＤは、CAN with Flexible Data Rateの略である。ＣＡＮ　ＦＤは、ＥＣＵ２と各ＥＣＵ３及び車外通信装置５とをバス接続する。イーサネットは、ＥＣＵ２と各ＥＣＵ３及び車外通信装置５との間を個別に接続する。
　ＥＣＵ２は、ＣＰＵ２ａ、ＲＯＭ２ｂ、及びＲＡＭ２ｃ等を備えたマイクロコンピュータを中心に構成された電子制御装置である。マイクロコンピュータの各種機能は、ＣＰＵ２ａが非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ２ｂが、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、ＣＰＵ２ａが実行する機能の一部又は全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。また、ＥＣＵ２を構成するマイクロコンピュータの数は１つでも複数でもよい。
　ＥＣＵ３、ＥＣＵ４、及び車外通信装置５は、いずれも、ＥＣＵ２と同様に、ＣＰＵ、ＲＯＭ、及びＲＡＭ等を備えたマイクロコンピュータを中心に構成された電子制御装置である。また、ＥＣＵ３、ＥＣＵ４、及び車外通信装置５を構成するマイクロコンピュータの数は１つでも複数でもよい。
　以下では、ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、及び車外通信装置５を、特に区別しない場合は、車載装置２～５と称する。
　ＡＶＰインフラ２００は、ＡＶＰサービスを提供する駐車場に設置されるインフラである。ＡＶＰサービスは、大規模な無人の駐車場内等で、車両が自動走行し、空いている駐車スペースに自動駐車するサービスである。
　ＡＶＰインフラ２００は、通信部２０１と、ＨＭＩ部２０２と、制御部２０３とを備える。
　通信部２０１は、車載システム１００との間でピアツーピアによる狭い範囲内でのデータ通信を行う。
　ＨＭＩ部２０２は、ＡＶＰサービスの提供に必要な情報や指令の入力に用いられる。ＨＭＩ部２０２は、ユーザ端末４００を介して情報や指令が入力されるように構成されてもよい。
　制御部２０３は、ＣＰＵ、ＲＯＭ、及びＲＡＭ等を備えたマイクロコンピュータを中心に構成される。制御部２０３には、ＡＶＰサービスを実現するサービスアプリケーション（以下、サービスアプリ）が実装される。ＡＶＰサービスを実現するサービスアプリは、通信部２０１を介して、車載システム１００が有する車両ＡＰＩにアクセスして、ＡＶＰサービスの開始に必要な情報の授受や、車載システム１００を搭載する車両の操舵及び加減速等の車両制御を実行する。この車両制御により、自動運転による車両の入出庫が実現される。ＡＰＩは、Application Programming Interfaceの略である。
　車両ＡＰＩは、車両が提供する機能にアクセスするために用いられ、特定の車種、特定のグレードに依存しないように標準化されたインタフェースである。つまり、車両ＡＰＩは、車の特徴及び制約を熟知していないエンジニアでも、車両ＡＰＩを利用するサービスアプリを容易に開発できるように構成されている。
　他車両３００は、上述した車載システム１００と同様の車載システムを備える。他車両３００の車載システムには、隊列走行サービスを実現するサービスアプリが実装される。隊列走行サービスを利用する車両のうち、隊列の先頭車両となる車両に実装されたサービスアプリは、隊列において後続車両となる車両の車載システム１００が有する車両ＡＰＩにアクセスする。この車両ＡＰＩへのアクセスにより、先頭車両のサービスアプリは、隊列走行サービスの開始に必要な情報を授受し、隊列が維持されるように後続車両の操舵及び加減速等の車両制御を実行する。この車両制御により、自動運転による隊列走行が実現される。
　ユーザ端末４００は、例えば、スマートフォンやタブレット等の携帯端末である。
　［２．機能構成］
　車載システム１００の機能構成について説明する。
　図２に示すように、車載システム１００は、アクセス制御部１０と、車両機能部２０と、車両ＡＰＩ部５０とを備える。アクセス制御部１０及び車両機能部２０は、車載装置２～５のいずれに配置されてもよい。例えば、アクセス制御部１０、車両機能部２０及び車両ＡＰＩ部５０は、ＥＣＵ２に配置される。
　［２－１．車両機能部］
　車両機能部２０は、車両が有する機能を、細分化したモジュールの集合である。車両機能部２０に属する各モジュールは、それぞれ車載装置２～５のいずれかに実装される。
　車両機能部２０に属するモジュールには複数区分が存在し、区分毎に、異なったアクセス制限が設定される。アクセス制限が設定された車両ＡＰＩは、自身が属する区分に対応づけられた認証子がＡＰＩアクセス要求に添付されている場合のみ、そのＡＰＩアクセス要求を受け付けて処理を実行する。
　車両機能部２０は、セキュリティ保護資産として定義される４つの属性Ｆ，Ｓ，Ｏ，Ｐに対応する４つの区分と、アクセス制限を有さない１つの区分とを有する。ＦはＦｉｎａｎｃｉａｌ（すなわち、財務）の略であり、ＳはＳａｆｅｔｙ（すなわち、安全）の略であり、ＯはＯｐｅｒａｔｉｏｎａｌ（すなわち、操作）の略であり、ＰはＰｒｉｖａｃｙ（すなわち、プライバシー）の略である。
　車両機能部２０は、各区分に対応して、Ｎ系機能ブロック群２１と、Ｏ系機能ブロック群２２と、Ｐ系機能ブロック群２３と、Ｓ系機能ブロック群２４と、Ｆ系機能ブロック群２５とを備える。更に、車両機能部２０は、車両状態データベース（以下、車両状態ＤＢ）２６を備える。
　Ｎ系機能ブロック群２１は、車両機能や車両情報へのアクセスを必要としない機能を提供するモジュールの集合である。Ｏ系機能ブロック群２２は、車両の操作性能に関わる機能を提供するモジュールの集合である。Ｐ系機能ブロック群２３は、車両に記憶されているユーザのプライバシー情報に関わる機能を提供するモジュールの集合である。Ｓ系機能ブロック群２４は、安全性に関わる機能を提供するモジュールの集合である。Ｆ系機能ブロック群２５は、企業もしくは個人の財産に関わる機能を提供するモジュールの集合である。
　車両状態ＤＢ２６は、車両の状態を表す車両状態データが格納される。車両状態ＤＢ２６に格納される車両状態データは、逐次更新される。車両状態データには、車両の位置及び走行速度が少なくとも含まれる。車両状態データには、車両の操作状態、車載機器の操作状態、車両周辺及び車内を監視する各種監視センサによる検出結果等が含まれてもよい。
　車両ＡＰＩ部５０は、車両が提供する機能、すなわち、車両機能部２０に属するモジュールにアクセスするために用意された車両ＡＰＩの集合である。車両ＡＰＩ部５０は、Ｎ系ＡＰＩ群５１と、Ｏ系ＡＰＩ群５２と、Ｐ系ＡＰＩ群５３と、Ｓ系ＡＰＩ群５４と、Ｆ系ＡＰＩ群５５とを備える。
　Ｎ系ＡＰＩ群５１は、Ｎ系機能ブロック群２１に属する各モジュールへのアクセスに用いる車両ＡＰＩ（以下、Ｎ系ＡＰＩ）の集合である。Ｎ系ＡＰＩは、アクセス制限がなく、アクセス要求に認証子が添付されていなくてもアクセス要求を受け付ける。
　Ｎ系機能ブロック群２１には、図５及び図１０に示すように、例えば、受入判定モジュール２１１、信頼度確認モジュール２１２、終了判定モジュール２１３等が含まれてもよい。受入判定モジュール２１１は、自車両がＡＰＩ利用アプリによって提供されるサービスを受け入れ可能な状況にあるか否かを判定して、ＡＰＩ利用アプリの提供元に通知する機能を提供する。信頼度確認モジュール２１２は、ＡＰＩ利用アプリから提供される信頼性情報に基づいて、サービス提供元の信頼度を判定し、判定結果をアクセス制御部１０に通知する機能を提供する。終了判定モジュール２１３は、対象サービスを終了する条件が成立しているか否かを判定し、成立している場合に、その旨をアクセス制御部１０に通知する機能を提供する。Ｏ系ＡＰＩ群５２は、Ｏ系機能ブロック群２２に属する各モジュールへのアクセスに用いる車両ＡＰＩ（以下、Ｏ系ＡＰＩ）の集合である。Ｏ系ＡＰＩは、アクセス要求にＯ系認証子が添付されている場合に、アクセス要求を受け付ける。
　Ｏ系機能ブロック群２２には、例えば、提供確認モジュール２２１、開始確認モジュール２２２等が含まれてもよい。提供確認モジュール２２１は、自車両が備える車載ＨＭＩを利用して、サービスの提供を受ける意思があるか否かを確認する機能を提供する。開始確認モジュール２２２は、自車両が備える車載ＨＭＩを利用して、サービスの提供を開始してよいか否かを確認する機能を提供する。
　Ｐ系ＡＰＩ群５３は、Ｐ系機能ブロック群２３に属する各モジュールへのアクセスに用いる車両ＡＰＩ（以下、Ｐ系ＡＰＩ）の集合である。Ｐ系ＡＰＩは、アクセス要求にＰ系認証子が添付されている場合に、アクセス要求を受け付ける。
　Ｐ系機能ブロック群２３には、例えば、情報提供モジュール２３１、降車確認モジュール２３２等が含まれてもよい。情報提供モジュール２３１は、自車両に記憶されているプライバシー情報を読み出す機能を提供する。プライバシー情報には、ユーザによって設定される目的地までの経路情報や、駐車場の予約情報等が含まれてもよい。降車確認モジュール２３２は、自車両に記憶されているプライバシー情報（例えば、車室内を撮影した画像）にアクセスし、画像から得られた情報（例えば、乗員の有無）を通知する機能を提供する。
　Ｓ系ＡＰＩ群５４は、Ｓ系機能ブロック群２４に属する各モジュールへのアクセスに用いる車両ＡＰＩ（以下、Ｓ系ＡＰＩ）である。Ｓ系ＡＰＩは、アクセス要求にＳ系認証子が添付されている場合に、アクセス要求を受け付ける。
　Ｓ系機能ブロック群２３には、例えば、車両制御モジュール２４１等が含まれてもよい。車両制御モジュール２４１は、操舵及び加減速等、車両の挙動を変化させる車両制御を行うための機能を提供し、車両制御の種類毎に異なるモジュールを備える。
　Ｆ系ＡＰＩ群５５は、Ｆ系機能ブロック群２５に属する各モジュールへのアクセスに用いる車両ＡＰＩ（以下、Ｆ系ＡＰＩ）の集合である。Ｆ系ＡＰＩは、アクセス要求にＦ系認証子が添付されている場合に、アクセス要求を受け付ける。
　Ｆ系機能ブロック群２５には、例えば、精算モジュール２５１等が含まれてもよい。精算モジュール２５１は、提供されたサービスに関する料金精算を行う機能を提供する。
　［２－２．ＡＰＩ利用アプリ］
　車両ＡＰＩを利用して所望の機能を実現するサービスアプリ３０を、ＡＰＩ利用アプリという。ＡＰＩ利用アプリは、車両ＡＰＩにアクセスすることで、車両情報や車両機能を利用したサービスを実現する。
　ＡＰＩ利用アプリは、車載システム１００に搭載されてもよいが、ここでは、ＡＶＰインフラ２００及び他車両３００等の外部装置に搭載されている場合について説明する。
　ＡＰＩ利用アプリは、ＯＥＭによって提供されてもよいし、サードパーティによって提供されてもよい。
　ＯＥＭは、車両を製造した車両メーカである。ＯＥＭは、Original Equipment Manufacturerの略である。また、ＯＥＭアプリには、ＯＥＭ自身によって開発されたアプリと、他ベンダーによって開発されたアプリとが存在してもよい。
　サードパーティは、車両の所有者、及びＯＥＭ以外の第三者である。
　ＡＰＩ利用アプリによって提供されるサービスには、例えば、自動運転による隊列走行を実現する隊列走行サービス、自動運転によるＡＶＰを実現するＡＶＰサービス等が含まれる。なお、隊列走行サービスの場合、隊列の先頭を走行する他車両３００が本開示における外部装置に相当する。ＡＶＰサービスの場合、駐車場に設置されたＡＶＰインフラ２００が本開示における外部装置に相当する。
　ＡＰＩ利用アプリは、車両機能部２０によって提供される機能を利用する場合、車両ＡＰＩ部５０に属する車両ＡＰＩへのアクセス要求であるＡＰＩアクセス要求を送信する。ＡＰＩアクセス要求は、利用元となるサービスアプリ（以下、利用元アプリ）を識別する情報、及び利用先となる車両ＡＰＩ（以下、利用先ＡＰＩ）を識別する情報を少なくとも含む。ＡＰＩアクセス要求は、特定のＡＰＩに対するアクセス権を有していることを示す認証子が付与されていてもよい。
　ＡＰＩアクセス要求は、アクセス制御部１０を介して、車両ＡＰＩ部５０に転送され、更に、車両ＡＰＩ部５０から車両機能部２０に転送される。
　［２－３．アクセス制御部］
　アクセス制御部１０は、車両機能部２０に属する各モジュールが提供する車両ＡＰＩへのアクセスを制御する機能を有する。
　アクセス制御部１０は、認証子付与部１１と、アクセス制限部１２と、アクセス管理データベース（以下、アクセス管理ＤＢ）１３とを備える。
　認証子付与部１１は、ＡＰＩ利用アプリに対して区分毎に用意された認証子の付与する処理を実行する。以下では、自車両の車両ＡＰＩを利用するＡＰＩ利用アプリを、対象アプリ３０という。対象アプリ３０は、複数存在してもよい。また、対象アプリ３０によって提供されるサービスを対象サービスという。
　認証子付与部１１が実行する認証子付与処理を、図３に示すフローチャートを用いて説明する。認証子付与処理は、ＡＰＩ利用アプリ毎に個別に実行される。
　認証子付与部１１は、認証子付与処理が開始されると、Ｓ１１０では、自車両が、対象サービスを受け入れ可能な状態にあるか否かを判定する。この判定は、Ｎ系機能ブロック群２１に属する受入判定モジュール２１１を使用して判定する。受入判定モジュール２１１は、例えば、対象サービスを利用する際に、自車両の車載システム１００に事前にインストールされる。受入判定モジュール２１１は、自車両が対象サービスを受け入れ可能な状況にある場合に、その旨を認証子付与部１１に通知する。
　受入判定モジュール２１１は、対象サービスの提供元となる外部装置から信頼性情報の提供を受け、提供された信頼性情報に基づいて、ドライバが意図するサービス提供元からのサービス提供であるか否かを判定する。
　対象サービスが隊列走行の場合、隊列の先頭車両がサービス提供元となり、信頼性情報として、先頭車両の位置、及び走行速度等が用いられる。また、対象サービスが自動駐車の場合、自動駐車サービスを提供するインフラがサービス提供元となり、信頼性情報として、インフラの位置、及び名称等が用いられる。そして、受入判定モジュール２１１は、サービス提供元から提供される信頼性情報と、車両状態ＤＢ２６に記憶された自車両の位置，走行速度及び地図情報等とを比較することで、サービスの提供を受けることが可能な位置に自車両が存在するか否かを判定する。なお、サービスの提供を受けることが可能な位置とは、例えば、サービス提供元となる車両やインフラを、自車両のドライバが視認可能となる位置であってもよい。
　認証子付与部１１は、受入判定モジュール２１１から通知を受けた場合、サービス受け入れ可能であると判定し、処理をＳ１２０に移行する。また、認証子付与部１１は、受入判定モジュール２１１からの通知を受けていない場合、サービスを受け入れ可能ではないと判定し、同ステップを繰り返すことで待機する。
　Ｓ１２０では、認証子付与部１１は、外部装置に実装された対象アプリ３０に対して、受け入れ可能通知を送信する。
　続くＳ１３０では、認証子付与部１１は、対象サービスが終了したか否かを判定する。この判定は、精算モジュール２５１から精算処理が終了したことを示す支払終了通知を受けた場合、サービスが終了したと判定してもよい。また、精算処理が省略される場合、認証子付与部１１は、Ｎ系機能ブロック群２１に属する終了判定モジュール２１３を使用して判定してもよい。終了判定モジュール２１３は、受入判定モジュール２１１と同様に、対象サービスを利用する際に、自車両の車載システム１００に事前にインストールされる。終了判定モジュール２１３は、サービスを終了させる終了条件が成立している場合に、その旨を認証子付与部１１に通知する。終了判定モジュール２１３は、終了条件が成立しているか否かの判定を、例えば、車両状態ＤＢ２６に記憶された車両状態データに基づいて行ってもよい。認証子付与部１１は、終了判定モジュール２１３からの通知を受けた場合、サービスが終了したと判定してもよい。
　認証子付与部１１は、サービスが終了したと判定した場合、処理をＳ１４０に移行し、サービスが終了していないと判定した場合、処理をＳ１５０に移行する。
　Ｓ１４０では、認証子付与部１１は、後述するＳ１６０，Ｓ１８０，Ｓ２００，Ｓ２２０にて対象アプリ３０に対して付与された認証子を無効化して、処理を終了する。
　Ｓ１５０では、認証子付与部１１は、Ｏ系ＡＰＩへのアクセスを許可するＯ系開放条件が成立しているか否かを判定し、Ｏ系開放条件が成立していれば、処理をＳ１６０に移行し、Ｏ系開放条件が成立していなければ、処理をＳ１７０に移行する。
　Ｓ１６０では、認証子付与部１１は、外部装置に実装された対象アプリ３０に対し、Ｏ系認証子を付与して、処理をＳ１３０に戻す。
　Ｓ１７０では、認証子付与部１１は、Ｐ系ＡＰＩへのアクセスを許可するＰ系開放条件が成立しているか否かを判定し、Ｐ系開放条件が成立していれば、処理をＳ１８０に移行し、Ｐ系開放条件が成立していなければ、処理をＳ１９０に移行する。
　Ｓ１８０では、認証子付与部１１は、外部装置に実装された対象アプリ３０に対し、Ｐ系認証子を付与して、処理をＳ１３０に戻す。
　Ｓ１９０では、認証子付与部１１は、Ｓ系ＡＰＩへのアクセスを許可するＳ系開放条件が成立しているか否かを判定し、Ｓ系開放条件が成立していれば、処理をＳ２００に移行し、Ｓ系開放条件が成立していなければ、処理をＳ２１０に移行する。
　Ｓ２００では、認証子付与部１１は、外部装置に実装された対象アプリ３０に対し、Ｓ系認証子を付与して、処理をＳ１３０に戻す。
　Ｓ２１０では、認証子付与部１１は、Ｆ系ＡＰＩへのアクセスを許可するＦ系開放条件が成立しているか否かを判定し、Ｆ系開放条件が成立していれば、処理をＳ２２０に移行し、Ｆ系開放条件が成立していなければ、処理をＳ１３０に戻す。
　Ｓ２２０では、認証子付与部１１は、外部装置に実装された対象アプリ３０に対し、Ｆ系認証子を付与して、処理をＳ１３０に戻す。
　Ｓ１５０、Ｓ１７０、Ｓ１９０、Ｓ２１０にて使用される開放条件は、例えば、対象アプリ３０からのＡＰＩアクセス要求によって実行される処理の結果が、決められた内容であることを含んでもよい。また、開放条件は、対象アプリ３０に対して他区分の認証子が既に付与されていることを含んでもよい。つまり、開放条件の設定の仕方によって、各区分の認証子の付与順序を制御してもよい。
　アクセス制限部１２は、Ｓ１６０、Ｓ１８０、Ｓ２００、Ｓ２２０にて、対象アプリ３０に対して付与した認証子を、Ｏ系、Ｐ系、Ｓ系、Ｆ系の区分毎に分類してアクセス管理ＤＢ１３に記憶させる。アクセス制限部１２は、Ｓ１４０で行う認証子の無効化を、アクセス管理ＤＢ１３に記憶された認証子を削除することで行う。
　アクセス制限部１２は、対象アプリ３０（すなわち外部装置）からのＡＰＩアクセス要求を受け付けて、アクセス先となる車両ＡＰＩへのアクセスを許可するか否かを判定するアクセス制限処理を実行する。
　次に、アクセス制限部１２が実行するアクセス制限処理を、図４に示すフローチャートを用いて説明する。アクセス制御処理は、すべてのＡＰＩ利用アプリに対して共通に実行される。
　アクセス制限部１２は、アクセス制限処理が開始されると、Ｓ３１０では、外部装置に実装された対象アプリ３０から、ＡＰＩアクセス要求を受信したか否かを判定する。アクセス制限部１２は、ＡＰＩアクセス要求を受信していると判定した場合は処理をＳ３２０に移行し、受信していないと判定した場合は、同ステップを繰り返すことで待機する。
　Ｓ３２０では、アクセス制限部１２は、ＡＰＩアクセス要求に示された利用先ＡＰＩは、アクセス制限のないＮ系ＡＰＩであるか否かを判定し、Ｎ系ＡＰＩであれば処理をＳ３５０に移行し、Ｎ系ＡＰＩでなければ、処理をＳ３３０に移行する。
　Ｓ３３０では、アクセス制限部１２は、ＡＰＩアクセス要求に認証子が添付されているか否かを判定し、認証子が添付されていれば処理をＳ３４０に移行し、認証子が添付されていなければ、処理をＳ３６０に移行する。
　Ｓ３４０では、アクセス制限部１２は、ＡＰＩアクセス要求に添付された認証子が、利用先ＡＰＩに適合しているか否かを判定し、適合していれば処理をＳ３５０に移行し、適合していなければ処理をＳ３６０に移行する。具体的には、例えば、利用先ＡＰＩがＯ系ＡＰＩである場合に、ＡＰＩアクセス要求に添付された認証子が、アクセス管理ＤＢ１３に記憶されているＯ系認証子と一致すれば、適合していると判定してもよい。
　Ｓ３５０では、アクセス制限部１２は、対象アプリ３０は利用先ＡＰＩへのアクセス権限を有するものとして、ＡＰＩアクセス要求を利用先ＡＰＩに転送して、処理を終了する。
　Ｓ３６０では、アクセス制限部１２は、対象アプリ３０は利用先ＡＰＩへのアクセス権限を有さないものとして、ＡＰＩアクセス要求を破棄して、処理を終了する。この時、ＡＰＩアクセス要求を破棄したことを、利用元の対象アプリ３０に通知してもよい。
　［３．動作例］
　［３－１．代表的な動作例］
　図５～７のシーケンス図を用いて、代表的な動作例について説明する。なお、図５～７では、図面を見やすくするために、ＡＰＩ群５１～５５の記載を省略する。これは、Ｎ系ＡＰＩ群５１とＮ系機能ブロック群２１、Ｏ系ＡＰＩ群５２とＯ系機能ブロック群２２、Ｐ系ＡＰＩ群５３とＰ系機能ブロック群２３、Ｓ系ＡＰＩ群５４とＳ系機能ブロック群２４、Ｆ系ＡＰＩ群５５とＦ系機能ブロック群２５は、それぞれ１対１に対応づけられるためである。
　車載システム１００を搭載する車両（以下、自車両）が起動すると、車載システム１００は、受入判定モジュール２１１によって、自車両が対象サービスを受け入れ可能な状況にあるか否かを判定する。そして、車載システム１００は、図５に示すように、受入判定モジュール２１１での判定結果を示す結果通知Ｍ１を、外部装置に実装された対象アプリ３０に送信する。
　サービス受け入れ可能であることが示された結果通知Ｍ１を受信した対象アプリ３０は、信頼度確認モジュール２１２に対して、ＡＰＩアクセス要求Ｍ２を送信する。ＡＰＩアクセス要求Ｍ２には、自サービスの信頼性に関する情報である信頼性情報が添付される。
　ＡＰＩアクセス要求Ｍ２を受信したアクセス制御部１０は、ＡＰＩアクセス要求Ｍ２に示された利用先ＡＰＩを確認する。ここでは、Ｎ系ＡＰＩへのアクセス要求である（すなわち、Ｓ３２０で肯定判定される）ため、アクセス制御部１０は、ＡＰＩアクセス要求Ｍ２を、利用先ＡＰＩに転送する。利用先ＡＰＩは、転送されてくるＡＰＩアクセス要求Ｍ２に従って、利用先モジュールである信頼度確認モジュール２１２を作動させる。
　ＡＰＩアクセス要求Ｍ２の転送を受けた信頼度確認モジュール２１２は、ＡＰＩアクセス要求Ｍ２に添付された信頼性情報に基づいて、対象サービスの信頼度を判定した結果を示す信頼度通知Ｍ３を、アクセス制御部１０に通知する。
　信頼度通知Ｍ３を受信したアクセス制御部１０は、対象サービスが十分信頼できると判定されている場合、Ｏ系開放条件が成立した（すなわち、Ｓ１５０にて肯定判定された）ものとして、Ｏ系認証子を添付したアクセス許可通知Ｍ４を対象アプリ３０に送信する。アクセス制御部１０は、例えば、信頼度通知Ｍ３における対象サービスの信頼度が所定の閾値を上回る場合、十分信頼できると判定してもよい。
　また、信頼度通知Ｍ３を受信したアクセス制御部１０は、対象サービスが信頼できないと判定されている場合、図６に示すように、Ｏ系ＡＰＩに対するアクセス権の付与を拒否することを示したアクセス拒否通知Ｍ５を対象アプリ３０に送信する。
　図５に戻り、アクセス許可通知Ｍ４を受信した対象アプリ３０は、提供確認モジュール２２１に対して、ＡＰＩアクセス要求Ｍ６を送信する。ＡＰＩアクセス要求Ｍ６には、アクセス許可通知Ｍ４にて取得したＯ系認証子が添付される。提供確認モジュール２２１は、対象サービスの提供についてユーザの意思を、車載ＨＭＩを介して確認する機能を提供する。
　ＡＰＩアクセス要求Ｍ６を受信したアクセス制御部１０は、ＡＰＩアクセス要求Ｍ６に示された利用先ＡＰＩ等を確認する。ここでは、Ｏ系ＡＰＩへのアクセス要求であり（すなわち、Ｓ３２０で否定判定され）、かつ、認証子の添付があり（すなわち、Ｓ３３０にて肯定判定され）、かつ、認証子は利用先ＡＰＩに適合している（すなわち、Ｓ３４０にて肯定判定される）。このため、アクセス制御部１０は、ＡＰＩアクセス要求Ｍ６を、利用先ＡＰＩに転送する。利用先ＡＰＩは、転送されてくるＡＰＩアクセス要求Ｍ６に従って、利用先モジュールである提供確認モジュール２２１を作動させる。
　ＡＰＩアクセス要求Ｍ６に従って作動した提供確認モジュール２２１は、車載ＨＭＩを制御するＥＣＵに対して提供確認要求Ｍ７を送信する。
　提供確認要求Ｍ７を受信したＥＣＵは、車載ＨＭＩを介して対象サービスの提供を希望するか否かの確認を促す表示等を行い、ユーザからの入力が行われると、入力内容を示すユーザ応答Ｍ８を、提供確認モジュール２２１に返送する。
　ユーザ応答Ｍ８を受信した提供確認モジュール２２１は、ユーザ応答Ｍ８に示されたユーザの意思を示す提供確認通知Ｍ９を、アクセス制御部１０に送信する。
　提供確認通知Ｍ９を受信したアクセス制御部１０は、提供確認通知Ｍ９に、対象サービスの提供を希望する旨が示されている場合、Ｐ系開放条件が成立した（すなわち、Ｓ１７０にて肯定判定された）ものとして、Ｐ系認証子を添付したアクセス許可通知Ｍ１０を対象アプリ３０に送信する。また、アクセス制御部１０は、提供確認通知Ｍ９に、対象サービスの提供を希望しない旨が示されている場合、図７に示すように、Ｐ系ＡＰＩに対するアクセス権の付与を拒否することを示したアクセス拒否通知Ｍ１１を対象アプリ３０に送信する。
　図５に戻り、アクセス許可通知Ｍ１０を受信した対象アプリ３０は、情報提供モジュール２３１に対して、ＡＰＩアクセス要求Ｍ１２を送信する。ＡＰＩアクセス要求Ｍ１２には、アクセス許可通知Ｍ１０にて取得したＰ系認証子が添付される。
　ＡＰＩアクセス要求を受信したアクセス制御部１０は、ＡＰＩアクセス要求Ｍ１２に示された利用先ＡＰＩ等を確認する。ここでは、Ｐ系ＡＰＩへのアクセス要求であり（すなわち、Ｓ３２０で否定判定され）、かつ、認証子の添付があり（すなわち、Ｓ３３０にて肯定判定され）、かつ、認証子は利用先ＡＰＩに適合している（すなわち、Ｓ３４０にて肯定判定される）。このため、アクセス制御部１０は、ＡＰＩアクセス要求Ｍ１２を、利用先ＡＰＩに転送する。利用先ＡＰＩは、転送されてくるＡＰＩアクセス要求Ｍ１２に従って、利用先モジュールである情報提供モジュール２３１を作動させる。
　ＡＰＩアクセス要求Ｍ１２に従って作動した情報提供モジュール２３１は、ＡＰＩアクセス要求Ｍ１２に示されたプライバシー情報を取得して、取得したプライバシー情報を情報提供通知Ｍ１３により対象アプリ３０に送信する。
　情報提供通知Ｍ１３を受信した対象アプリ３０は、開始確認モジュール２２２に対して、ＡＰＩアクセス要求Ｍ１４を送信する。ＡＰＩアクセス要求Ｍ１４には、アクセス許可通知Ｍ４にて取得したＯ系認証子が添付される。開始確認モジュール２２２は、対象サービスの開始についてユーザの意思を、車載ＨＭＩを介して確認する機能を提供する。
　ＡＰＩアクセス要求Ｍ１４を受信したアクセス制御部１０は、ＡＰＩアクセス要求Ｍ１４に示された利用先ＡＰＩ等を確認する。ここでは、Ｏ系ＡＰＩへのアクセス要求であり（すなわち、Ｓ３２０で否定判定され）、かつ、認証子の添付があり（すなわち、Ｓ３３０にて肯定判定され）、かつ、認証子は利用先ＡＰＩに適合している（すなわち、Ｓ３４０にて肯定判定される）。このため、アクセス制御部１０は、ＡＰＩアクセス要求Ｍ１４を、利用先ＡＰＩに転送する。利用先ＡＰＩは、転送されてくるＡＰＩアクセス要求Ｍ１４に従って、利用先モジュールである開始確認モジュール２２２を作動させる。
　ＡＰＩアクセス要求Ｍ１４に従って作動した開始確認モジュール２２２は、車載ＨＭＩを制御するＥＣＵに対して開始確認要求Ｍ１５を送信する。
　開始確認要求Ｍ１５を受信したＥＣＵは、車載ＭＨＩを介して対象サービスの開始を希望するか否かの確認をユーザに促す表示等を行い、ユーザからの入力が行われると、入力内容を示すユーザ応答Ｍ１６を、開始確認モジュール２２２に返送する。
　ユーザ応答Ｍ１６を受信した開始確認モジュール２２２は、ユーザ応答Ｍ１６に示されたユーザの意思を示す開始要否通知Ｍ１７を、アクセス制御部１０に送信する。
　開始要否通知Ｍ１７を受信したアクセス制御部１０は、開始要否通知Ｍ１７に、対象サービスの開始を希望する旨が示されている場合、Ｓ系開放条件が成立した（すなわち、Ｓ１９０にて肯定判定された）ものとして、Ｓ系認証子を添付したアクセス許可通知Ｍ１８を対象アプリ３０に送信する。また、アクセス制御部１０は、開始要否通知Ｍ１７に対象サービスの開始を希望しない旨が示されている場合、図示を省略するが、Ｓ系ＡＰＩに対するアクセス権の付与を拒否することを示したアクセス拒否通知を対象アプリ３０に送信する。
　アクセス許可通知Ｍ１８を受信した対象アプリ３０は、車両制御モジュール２４１に対して、ＡＰＩアクセス要求Ｍ１９を送信する。ＡＰＩアクセス要求Ｍ１９には、アクセス許可通知Ｍ１８にて取得したＳ系認証子が添付される。
　ＡＰＩアクセス要求Ｍ１９を受信したアクセス制御部１０は、ＡＰＩアクセス要求Ｍ１９に示された利用先ＡＰＩ等を確認する。ここでは、Ｓ系ＡＰＩへのアクセス要求であり（すなわち、Ｓ３２０で否定判定され）、かつ、認証子の添付があり（すなわち、Ｓ３３０にて肯定判定され）、かつ、認証子は利用先ＡＰＩに適合している（すなわち、Ｓ３４０にて肯定判定される）。このため、アクセス制御部１０は、ＡＰＩアクセス要求Ｍ１９を、利用先ＡＰＩに転送する。利用先ＡＰＩは、転送されてくるＡＰＩアクセス要求Ｍ１９に従って、利用先モジュールである車両制御モジュール２４１を作動させる。
　ＡＰＩアクセス要求Ｍ１９に従って作動した車両制御モジュール２４１は、ＡＰＩアクセス要求Ｍ１９に示された指示内容に従って、対象サービスの実現に必要な車両制御を実行する。図５では、車両制御モジュール２４１に対するＡＰＩアクセス要求Ｍ１９が一つだけ示されているが、複数のＡＰＩアクセス要求Ｍ１９が送信されてもよい。
　その後、対象アプリは、サービスを終了させる必要がある場合に、終了判定モジュール２１３に対して、ＡＰＩアクセス要求Ｍ２０を送信する。
　ＡＰＩアクセス要求Ｍ２０を受信したアクセス制御部１０は、ＡＰＩアクセス要求Ｍ２０に示された利用先ＡＰＩ等を確認する。ここでは、Ｎ系ＡＰＩへのアクセス要求である（すなわち、Ｓ３２０で肯定判定される）ため、アクセス制御部１０は、ＡＰＩアクセス要求Ｍ２０を、利用先ＡＰＩに転送する。利用先ＡＰＩは、転送されてくるＡＰＩアクセス要求Ｍ２０に従って、利用先モジュールである終了判定モジュール２１３を作動させる。
　ＡＰＩアクセス要求Ｍ２０に従って作動した終了判定モジュール２１３は、自車両の状況が、予め設定された終了条件を充足している場合に、アクセス制御部１０に終了通知Ｍ２１を送信する。終了条件は、ＡＰＩアクセス要求Ｍ２０の受信に限らず、車両異常の検出等が含まれてもよい。
　終了通知Ｍ２１を受信したアクセス制御部１０は、Ｆ系開放条件が成立した（すなわち、Ｓ２１０にて肯定判定された）ものとして、Ｆ系認証子を添付したアクセス許可通知Ｍ２２を対象アプリ３０に送信する。
　アクセス許可通知Ｍ２２を受信した対象アプリ３０は、精算モジュール２５１に対して、ＡＰＩアクセス要求Ｍ２３を送信する。ＡＰＩアクセス要求Ｍ２３には、アクセス許可通知Ｍ２２にて取得したＦ系認証子が添付される。
　ＡＰＩアクセス要求Ｍ２３を受信したアクセス制御部１０は、ＡＰＩアクセス要求Ｍ２３に示された利用先ＡＰＩ等を確認する。ここでは、Ｆ系ＡＰＩへのアクセス要求であり（すなわち、Ｓ３２０で否定判定され）、かつ、認証子の添付があり（すなわち、Ｓ３３０にて肯定判定され）、かつ、認証子は利用先ＡＰＩに適合している（すなわち、Ｓ３４０にて肯定判定される）。このため、アクセス制御部１０は、ＡＰＩアクセス要求Ｍ２３を、利用先ＡＰＩに転送する。利用先ＡＰＩは、転送されてくるＡＰＩアクセス要求Ｍ２３に従って、利用先モジュールである精算モジュール２５１を作動させる。
　ＡＰＩアクセス要求Ｍ２３に従って作動した精算モジュール２５１は、対象サービスに要した費用を精算する処理を実行後、アクセス制御部１０に対して、支払終了通知Ｍ２４を送信する。
　支払終了通知Ｍ２４を受信したアクセス制御部１０は、サービスが終了した（すなわち、Ｓ１３０にて肯定判定された）ものとして、処理の過程で対象アプリ３０に付与した各認証子を無効化すると共に、対象アプリに対してサービス終了通知Ｍ２５を送信する。
　サービス終了通知Ｍ２５を受信した対象アプリ３０は、処理の仮定でアクセス制御部１０から付与された各認証子を破棄して、サービスの提供を終了する。
　なお、料金の精算を行わない場合は、アクセス制御部１０は、終了通知Ｍ２１を受信した時点で、サービスが終了した（すなわち、Ｓ１３０にて肯定判定された）ものとして、認証子の無効化と、対象アプリ３０へのサービス終了通知Ｍ２５の送信とを行ってもよい。
　［３－２．隊列走行サービスでの動作例］
　次に、ＡＰＩ利用アプリが隊列走行サービスを提供する場合の動作例について説明する。
　この場合、図８に示すように、隊列走行の先頭車両となる他車両３００がサービスを提供する外部装置（以下、サービス提供車両）となる。サービス提供車両３００は、隊列走行サービスを提供するためのサービスアプリ（以下、対象アプリ）３０を備える。
　隊列走行サービスの手順は、図５～図７で示した、一般的な手順に従う。
　但し、隊列走行サービスで用いる受入判定モジュール２１１は、例えば、自車が隊列走行サービスの提供が許容されている道路を走行中であることを判定条件に含んでもよい。隊列走行サービスの提供が許容されている道路は、例えば、高速道路等、歩行者がいない特定の道路であってもよい。
　隊列走行サービスで用いる信頼度確認モジュール２１２では、信頼性情報として、サービス提供車両の位置及び速度を取得し、サービス提供車両が自車両からの距離が近いほど、また、自車両との相対速度が小さいほど高い値となる信頼度を算出する。そして、信頼度がしきい値以上であることを、サービス提供車両を十分に信頼できるか否かの判定条件としてもよい。また、サービス提供車両との距離及び相対速度のうち、少なくとも一つが許容範囲内であることを判定条件としてもよい。
　隊列走行サービスで用いる情報提供モジュール２３１では、プライバシー情報として、目的地までの経路情報を、対象アプリ３０に提供してもよい。経路情報は、例えば、自車両に搭載されたナビゲーション装置などを用いて設定されてもよい。
　隊列走行サービスで用いる終了判定モジュール２１３は、目的地に到達した場合、サービス提供車両から隊列からの離脱を指示された場合、車載ＨＭＩを介してユーザから隊列からの離脱を要求する入力があった場合等に、終了条件が成立したと判定してもよい。
　つまり、隊列走行サービスでは、自車両がサービスを受け入れ可能な状態にあり、サービス提供車両が十分に信頼できる場合に、自車両の車載システム１００は対象アプリ３０にＯ系認証子を付与する。対象アプリ３０は、付与されたＯ系認証子を用いて、Ｏ系機能ブロック群２２に属する提供確認モジュール２２１にアクセスすることで、サービスの提供を受ける意思の有無をユーザに確認する。ユーザの意思が確認されると、車載システム１００は、対象アプリ３０にＰ系認証子を付与する。対象アプリ３０は、付与されたＰ系認証子を用いて、Ｐ系機能ブロック群２３に属する情報提供モジュール２３１にアクセスすることで、プライベート情報である経路情報を取得する。更に、対象アプリ３０は、先に付与されたＯ系認証子を用いて、Ｏ系機能ブロック群２２に属する開始確認モジュール２２２にアクセスすることで、再度、サービスの提供を開始するか否かをユーザに確認する。ユーザの提供開始の意思が確認されると、車載システム１００は、対象アプリ３０にＳ系認証子を付与する。対象アプリ３０は、付与されたＳ系認証子を用いて、Ｓ系機能ブロック群２４に属する車両制御モジュール２４１にアクセスすることで、隊列走行を実現するための車両制御を実行する。車載システム１００は、対象アプリ３０の終了条件の成立を確認すると、対象アプリ３０にＦ系認証子を付与する。対象アプリ３０は、付与されたＦ系認証子を用いて、Ｆ系機能ブロック群２５に属する精算モジュール２５１にアクセスすることで、対象アプリ３０によって提供されたサービスに対する精算を実行する。精算が終了すると、車載システム１００は、対象アプリ３０に付与した各認証子を無効化する。
　［３－３．ＡＶＰサービスでの動作例］
　次に、ＡＰＩ利用アプリがＡＶＰサービスを提供する場合の動作例について説明する。
　この場合、図９に示すように、駐車場に設置されたＡＶＰインフラ２００がサービスを提供する外部装置となる。ＡＶＰインフラ２００は、ＡＶＰサービスを実現するために実行されるサービスアプリ（以下、対象アプリ）３０を備える。また、ＡＶＰインフラ２００は、駐車された車両を呼び出すための車両呼出装置４０を備える。
　車両呼出装置４０を用いる代わりに、ユーザ端末４００を用いて車両を呼び出すように構成されてもよい。
　ＡＶＰサービスの手順は、図５～図７で示した、サービスの受入判定、サービスの信頼度確認、ユーザに対するサービス提供の要否確認、サービス終了／精算、すなわち、Ｍ１～Ｍ１０、Ｍ２０～Ｍ２５のメッセージを使用した手順は、図５～７で示した一般的な手順と同様である。
　但し、ＡＶＰサービスで用いる受入判定モジュール２１１では、例えば、自車位置がＡＶＰサービスの提供を受ける駐車場の近傍である場合に、受け入れ可能と判定してもよい。
　ＡＶＰサービスで用いる信頼度確認モジュール２１２では、信頼性情報として、ＡＶＰサービスを提供する駐車場位置及び駐車場名称等を、対象アプリ３０から取得し、予め記憶された駐車予定の駐車場位置及び駐車場名称と一致している場合、ＡＶＰインフラ２００を信頼できると判定してもよい。
　ＡＶＰサービスでは、図１０に示すように、アクセス許可通知Ｍ１０を受信した対象アプリ３０は、Ｐ系機能ブロック群２３に属する降車確認モジュール２３２に対して、ＡＰＩアクセス要求Ｍ３１を送信する。ＡＰＩアクセス要求Ｍ３１には、アクセス許可通知Ｍ１０にて取得したＰ系認証子が添付される。降車確認モジュール２３２は、車室内を撮影した画像を取得し、画像解析した結果等から、すべての乗員が降車したか否かを確認し、確認結果をアクセス制御部１０に送信する。降車確認モジュール２３２での処理は、プライバシー情報（すなわち、車室内を撮影した画像）へのアクセスが含まれるため、降車確認モジュールに対するＡＰＩアクセス要求Ｍ３１には、Ｐ系認証子の添付が必要となる。
　ＡＰＩアクセス要求Ｍ３１を受信したアクセス制御部１０は、ＡＰＩアクセス要求Ｍ３１に示された利用先ＡＰＩ等を確認する。ここでは、Ｐ系ＡＰＩへのアクセス要求であり（すなわち、Ｓ３２０で否定判定され）、かつ、認証子の添付があり（すなわち、Ｓ３３０にて肯定判定され）、かつ、認証子は利用先ＡＰＩに適合している（すなわち、Ｓ３４０にて肯定判定される）。このため、アクセス制御部１０は、ＡＰＩアクセス要求Ｍ３１を、利用先ＡＰＩに転送する。利用先ＡＰＩは、ＡＰＩアクセス要求Ｍ３１に従って、利用先モジュールである降車確認モジュール２３２を作動させる。
　ＡＰＩアクセス要求Ｍ３１に従って作動した降車確認モジュール２３２は、全乗員が降車したか否かを表す降車確認通知Ｍ３２をアクセス制御部１０に送信する。
　降車確認通知Ｍ３２を受信したアクセス制御部１０は、降車確認通知Ｍ３２に、全乗員が降車していることが示されている場合、Ｓ系開放条件が成立した（すなわち、Ｓ１９０にて肯定判定された）ものとして、Ｓ系認証子を添付したアクセス許可通知Ｍ３３を対象アプリ３０に送信する。また、アクセス制御部１０は、降車確認通知Ｍ３２に、未降車の乗員が存在することが示されている場合、図示を省略するが、Ｓ系ＡＰＩに対するアクセス権の付与を拒否することを示したアクセス拒否通知を対象アプリ３０に送信する。
　アクセス許可通知Ｍ３３を受信した対象アプリ３０は、車両制御モジュール２４１に対して、ＡＰＩアクセス要求Ｍ３４を送信する。ＡＰＩアクセス要求Ｍ３４には、アクセス許可通知Ｍ３３にて取得したＳ系認証子が添付される。
　ＡＰＩアクセス要求Ｍ３４を受信したアクセス制御部１０は、利用先ＡＰＩ等を確認して、ＡＰＩアクセス要求Ｍ３４を、利用先ＡＰＩに転送する。利用先ＡＰＩは、ＡＰＩアクセス要求Ｍ３４に従って車両制御モジュール２４１を作動させる。
　ＡＰＩアクセス要求Ｍ３４に従って作動した車両制御モジュール２４１は、ＡＰＩアクセス要求Ｍ３４に示された指示内容に従って、車両制御を実行する。対象アプリ３０は、ＡＰＩアクセス要求Ｍ３４を、自車両が駐車スペースに到達するまで繰り返し送信する。その結果、自動運転による入庫が実現される。
　その後、車両呼出装置４０を介して呼出指令を受けた対象アプリ３０は、車両制御モジュール２４１に対して、ＡＰＩアクセス要求Ｍ３５を送信する。ＡＰＩアクセス要求Ｍ３５には、アクセス許可通知Ｍ３３にて取得したＳ系認証子が添付される。
　ＡＰＩアクセス要求Ｍ３５を受信したアクセス制御部１０は、利用先ＡＰＩ等を確認して、ＡＰＩアクセス要求Ｍ３５を、利用先ＡＰＩに転送する。利用先ＡＰＩは、ＡＰＩアクセス要求Ｍ３５に従って、利用先モジュールである車両制御モジュール２４１を作動させる。
　ＡＰＩアクセス要求Ｍ３５に従って作動した車両制御モジュール２４１は、ＡＰＩアクセス要求Ｍ３５に示された指示内容に従って、車両制御を実行する。対象アプリ３０は、ＡＰＩアクセス要求Ｍ３４を、自車両が駐車スペースから指定された乗降スペースに到達するまで繰り返し送信する。その結果、自動運転による出庫が実現される。
　対象アプリ３０は、車両の出庫が完了すると、終了判定モジュール２１３に対して、ＡＰＩアクセス要求Ｍ２０を送信する。以下の手順は、図５に示した一般的な手順と同様である。
　つまり、ＡＶＰサービスでは、自車両が駐車場の近くに位置し、その駐車場のＡＶＰインフラから得られる情報が駐車予定の駐車場であることを示している場合に、自車両の車載システム１００は、対象アプリ３０にＯ系認証子を付与する。対象アプリ３０は、付与されたＯ系認証子を用いて、Ｏ系機能ブロック群２２に属する提供確認モジュール２２１にアクセスすることで、サービスの提供を受ける意思の有無をユーザに確認する。ユーザの意思が確認されると、車載システム１００は、対象アプリ３０にＰ系認証子を付与する。対象アプリ３０は、付与されたＰ系認証子を用いて、Ｐ系機能ブロック群２３に属する降車確認モジュール２３２にアクセスすることで、車内の画像から全乗員の降車を確認する。全乗員の降車が確認されると、車載システム１００は、対象アプリ３０にＳ系認証子を付与する。対象アプリ３０は、付与されたＳ系認証子を用いて、Ｓ系機能ブロック群２４に属する車両制御モジュール２４１に繰り返しアクセスすることで、入庫を実現するための車両制御を実行する。
　対象アプリ３０は、車両呼出装置４０を介して車両の呼び出し指示が入力されると、先に付与されたＳ系認証子を用いて、Ｓ系機能ブロック群２４に属する車両制御モジュール２４１に繰り返しアクセスすることで、指定された車両の出庫を実現するための車両制御を実行する。出庫が完了することによって、サービスを終了する終了条件が成立すると、車載システム１００は、対象アプリ３０にＦ系認証子を付与する。対象アプリ３０は、付与されたＦ系認証子を用いて、Ｆ系機能ブロック群２５に属する精算モジュール２５１にアクセスすることで、対象アプリ３０によって提供されたＡＶＰサービスに関する精算を実行する。精算が終了すると、車載システム１００は、対象アプリ３０に付与した各認証子を無効化する。
　［４．用語の対応］
　本実施形態において、車載システム１００が本開示におけるアクセス制御装置に相当し、受入判定モジュール２１１及び信頼度確認モジュール２１２が本開示における受入判定部に相当する。開始確認モジュール２２２が本開示における開始確認部に相当し、精算モジュール２５１が本開示における精算部に相当する。認証子付与部１１が、本開示における第１付与部～第３付与部に相当する。特に、Ｓ１５０～Ｓ１６０の処理が本開示における第１付与部に相当し、Ｓ１７０～Ｓ２００の処理が本開示における第２付与部に相当し、Ｓ２１０～Ｓ２２０の処理が本開示における第３付与部に相当する。
　［５．効果］
　以上詳述した実施形態によれば、以下の効果を奏する。
　（ａ）ＡＰＩ利用サービスの提供を受ける場合に、サービス提供元の信頼性を確認し、信頼できる場合に、サービスの提供に必要な情報の取得や車両制御に用いられる車両ＡＰＩへのアクセス件を段階的に付与している。従って、車両ＡＰＩに対する車両外部からの不必要なアクセスを適切に制限でき、ＡＰＩ利用サービスを安全に利用することができる。
　（ｂ）アクセス権を付与する際に、ユーザの許諾を含めているため、サービスを受ける条件が揃っていたとしても、ユーザの意図に反して、車両情報が漏洩したり、車両制御が行われたりすることを抑制できる。
　（ｃ）ＡＰＩ利用サービスが隊列走行サービスである場合、他車両３００がサービス提供元となり、センター装置を介することなく車車間通信でサービスを実現する。従って、センター装置を介した通信によるタイムラグが発生しないため、自車両の周囲の状況に応じた的確なサービスを提供できる。
　つまり、従来の隊列走行システムでは、センター装置を介してサービスが提供されるため、センター装置での処理状況や、センター装置と車載システム１００との間の通信状況によってタイムラグが生じる。このようなタイムラグは、周辺状況がリアルタイムで変化し続ける走行中の車両においては致命的である。本実施形態では、このようなタイムラグによって、ユーザが必要な瞬間に必要なサービスの提供を受けることができず、例えば、隊列編入・離脱の機会を逸するという事態が発生することを抑制できる。
　（ｄ）ＡＰＩ利用サービスがＡＶＰサービスである場合、プライベート情報である車室内を撮影した画像情報にアクセスして、全乗員の降車が確認された場合に、車両制御を提供する車両ＡＰＩへのアクセス権を、ＡＶＰインフラに付与している。従って、一部の乗員を車両に閉じ込めたまま、車両が駐車スペースに移動してしまうことを抑制できる。
　［６．他の実施形態］
　以上、本開示の実施形態について説明したが、本開示は上述の実施形態に限定されることなく、種々変形して実施することができる。
　（ａ）上記実施形態では、車両ＡＰＩをＦＳＯＰで区分し、区分毎にまとめてアクセス権を付与しているが、例えば、Ｓ区分の中で車両制御の種類毎に、アクセス権を付与する段階を異ならせてもよい。
　（ｂ）上記実施形態では、サービスを開始する際に、サービス提供元の認証を行うことなくサービスを開始する手順を始めたり、ＨＭＩ装置を介したユーザのアクセス時に、個人認証を行うことなく、ユーザの入力を受け付けたりしている。安全性を向上させるために、サービス提供元の認証や個人認証を行うようにしてもよい。
　（ｃ）本開示に記載の車載装置２～５及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の車載装置２～５及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の車載装置２～５及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。車載装置２～５に含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。
　（ｄ）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。
　（ｅ）上述したアクセス制御装置の他、当該アクセス制御装置を構成要素とするシステム、当該アクセス制御装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実体的記録媒体、アクセス制御方法など、種々の形態で本開示を実現することもできる。
［７．本明細書が開示する技術思想］
［項目１］
　車両が有する車両機能を提供するためのインタフェースを車両ＡＰＩとし、前記車両ＡＰＩを利用したサービスを実現するアプリケーションをＡＰＩ利用アプリ（３０）として、前記車両の外部に設けられた前記ＡＰＩ利用アプリからのアクセス要求を受け付けて、前記車両ＡＰＩへのアクセスを制御するように構成されたアクセス制御部（１０）と、
　前記車両が前記ＡＰＩ利用アプリによるサービスである対象サービスを受け入れ可能であるか否かを判定する機能を、前記車両ＡＰＩを介して提供するように構成された受入判定部（２１１，２１２）と、
　前記対象サービスの提供を開始するか否かを前記車両の利用者に確認する機能を、前記車両ＡＰＩを介して提供するように構成された開始確認部（２２２）と、
　を備え、
　前記アクセス制御部は、
　前記受入判定部にて受け入れ可能と判定された場合、前記開始確認部の機能を提供する前記車両ＡＰＩに対するアクセス権を、前記ＡＰＩ利用アプリに付与するように構成された第１付与部（１１：Ｓ１５０～Ｓ１６０）と、
　前記開始確認部にて、前記利用者の開始意図が確認された場合、前記対象サービスの提供に必要な前記車両ＡＰＩに対するアクセス権を、前記ＡＰＩ利用アプリに付与するように構成された第２付与部（１１：Ｓ１７０～Ｓ２００）と、
　を備える
　アクセス制御装置。
［項目２］
　項目１に記載のアクセス制御装置であって、
　前記ＡＰＩ利用アプリを、前記車両との間でピアツーピアによる通信が可能な範囲に存在する外部装置（２００，３００）が備える
　アクセス制御装置。
［項目３］
　項目１又は項目２に記載のアクセス制御装置であって、
　前記対象サービスに関わる精算を行う機能を、前記車両ＡＰＩを介して提供するように構成された精算部（２５１）を更に備え、
　前記アクセス制御部は、
　前記対象サービスの終了が確認された場合、前記精算部の機能を提供する前記車両ＡＰＩに対するアクセス権を、前記ＡＰＩ利用アプリに付与するように構成された第３付与部（１１：Ｓ２１０～Ｓ２２０）を更に備える
　アクセス制御装置。
［項目４］
　項目１から項目３までのいずれか１項に記載のアクセス制御装置であって、
　前記対象サービスは、先頭車両からの指示に従って、後続車両が隊列を維持して走行するように前記後続車両を制御する隊列走行サービスであり、
　前記ＡＰＩ利用アプリを、隊列走行の先頭となる他車両（３００）が備える
　アクセス制御装置。
［項目５］
　項目４に記載のアクセス制御装置であって、
　前記受入判定部は、前記車両が前記隊列走行サービスの提供が許容されている道路を走行中であることを判定条件に含む
　アクセス制御装置。
［項目６］
　項目４又は項目５に記載のアクセス制御装置であって、
　前記受入判定部は、前記他車両との距離及び相対速度のうち、少なくとも一つが許容範囲内であることを判定条件に含む
　アクセス制御装置。
［項目７］
　項目４ないし項目６までのいずれか１項に記載のアクセス制御装置であって、
　前記隊列走行サービスの提供に必要な前記車両ＡＰＩには、前記車両の目的地までの経路情報を取得する機能を提供するプライバシー系ＡＰＩと、前記車両の挙動を制御する機能を提供する安全系ＡＰＩとが含まれる
　アクセス制御装置。
［項目８］
　項目１から項目３までのいずれか１項に記載のアクセス制御装置であって、
　前記対象サービスは、駐車場での入庫及び出庫を自動運転によって行うオートバレー駐車サービスであり、
　前記ＡＰＩ利用アプリを、前記オートバレー駐車サービスを実現する駐車場に設置されたインフラ装置（２００）が備える
　アクセス制御装置。
［項目９］
　項目８に記載のアクセス制御装置であって、
　前記受入判定部は、自車両の位置及び事前に設定された駐車場名称が、前記サービス提供元から提供される情報と一致していることを判定条件に含む
　アクセス制御装置。
［項目１０］
　項目８又は項目９に記載のアクセス制御装置であって、
　前記オートバレー駐車サービスの提供に必要な前記車両ＡＰＩには、前記車両の乗員が降車したことを確認するのに必要な情報を取得する機能を提供するプライバシー系ＡＰＩと、前記車両の挙動を制御する機能を提供する安全系ＡＰＩとが含まれる
　アクセス制御装置。

Claims (11)

  1. 　車両が有する車両機能を提供するためのインタフェースを車両ＡＰＩとし、前記車両ＡＰＩを利用したサービスを実現するアプリケーションをＡＰＩ利用アプリ（３０）として、前記車両の外部に設けられた前記ＡＰＩ利用アプリからのアクセス要求を受け付けて、前記車両ＡＰＩへのアクセスを制御するように構成されたアクセス制御部（１０）と、
    　前記車両が前記ＡＰＩ利用アプリによるサービスである対象サービスを受け入れ可能であるか否かを判定する機能を、前記車両ＡＰＩを介して提供するように構成された受入判定部（２１１，２１２）と、
    　前記対象サービスの提供を開始するか否かを前記車両の利用者に確認する機能を、前記車両ＡＰＩを介して提供するように構成された開始確認部（２２２）と、
    　を備え、
    　前記アクセス制御部は、
    　前記受入判定部にて受け入れ可能と判定された場合、前記開始確認部の機能を提供する前記車両ＡＰＩに対するアクセス権を、前記ＡＰＩ利用アプリに付与するように構成された第１付与部（１１：Ｓ１５０～Ｓ１６０）と、
    　前記開始確認部にて、前記利用者の開始意図が確認された場合、前記対象サービスの提供に必要な前記車両ＡＰＩに対するアクセス権を、前記ＡＰＩ利用アプリに付与するように構成された第２付与部（１１：Ｓ１７０～Ｓ２００）と、
    　を備えるアクセス制御装置。
  2. 　請求項１に記載のアクセス制御装置であって、
    　前記ＡＰＩ利用アプリを、前記車両との間でピアツーピアによる通信が可能な範囲に存在する外部装置（２００，３００）が備える
    　アクセス制御装置。
  3. 　請求項１に記載のアクセス制御装置であって、
    　前記対象サービスに関わる精算を行う機能を、前記車両ＡＰＩを介して提供するように構成された精算部（２５１）を更に備え、
    　前記アクセス制御部は、
    　前記対象サービスの終了が確認された場合、前記精算部の機能を提供する前記車両ＡＰＩに対するアクセス権を、前記ＡＰＩ利用アプリに付与するように構成された第３付与部（１１：Ｓ２１０～Ｓ２２０）を更に備える
    　アクセス制御装置。
  4. 　請求項１から請求項３までのいずれか１項に記載のアクセス制御装置であって、
    　前記対象サービスは、先頭車両からの指示に従って、後続車両が隊列を維持して走行するように前記後続車両を制御する隊列走行サービスであり、
    　前記ＡＰＩ利用アプリを、隊列走行の先頭となる他車両（３００）が備える
    　アクセス制御装置。
  5. 　請求項４に記載のアクセス制御装置であって、
    　前記受入判定部は、前記車両が前記隊列走行サービスの提供が許容されている道路を走行中であることを判定条件に含む
    　アクセス制御装置。
  6. 　請求項４に記載のアクセス制御装置であって、
    　前記受入判定部は、前記他車両との距離及び相対速度のうち、少なくとも一つが許容範囲内であることを判定条件に含む
    　アクセス制御装置。
  7. 　請求項４に記載のアクセス制御装置であって、
    　前記隊列走行サービスの提供に必要な前記車両ＡＰＩには、前記車両の目的地までの経路情報を取得する機能を提供するプライバシー系ＡＰＩと、前記車両の挙動を制御する機能を提供する安全系ＡＰＩとが含まれる
    　アクセス制御装置。
  8. 　請求項１から請求項３までのいずれか１項に記載のアクセス制御装置であって、
    　前記対象サービスは、駐車場での入庫及び出庫を自動運転によって行うオートバレー駐車サービスであり、
    　前記ＡＰＩ利用アプリを、前記オートバレー駐車サービスを実現する駐車場に設置されたインフラ装置（２００）が備える
    　アクセス制御装置。
  9. 　請求項８に記載のアクセス制御装置であって、
    　前記受入判定部は、自車両の位置及び事前に設定された駐車場名称が、前記サービス提供元から提供される情報と一致していることを判定条件に含む
    　アクセス制御装置。
  10. 　請求項８に記載のアクセス制御装置であって、
    　前記オートバレー駐車サービスの提供に必要な前記車両ＡＰＩには、前記車両の乗員が降車したことを確認するのに必要な情報を取得する機能を提供するプライバシー系ＡＰＩと、前記車両の挙動を制御する機能を提供する安全系ＡＰＩとが含まれる
    　アクセス制御装置。
  11. 　車両が有する車両機能を提供するためのインタフェースを車両ＡＰＩとし、前記車両ＡＰＩを利用したサービスを実現するアプリケーションをＡＰＩ利用アプリ（３０）として、前記車両の外部に設けられた前記ＡＰＩ利用アプリからのアクセス要求を受け付けて、前記車両ＡＰＩへのアクセスを制御するアクセス制御方法であって、
    　前記車両が前記ＡＰＩ利用アプリによるサービスである対象サービスを受け入れ可能であるか否かを判定する機能を、前記車両ＡＰＩを介して提供するように構成された受入判定部（２１１，２１２）にて、受け入れ可能と判定された場合、開始確認部（２２２）の機能を提供する前記車両ＡＰＩに対するアクセス権を、前記ＡＰＩ利用アプリに付与し（Ｓ１５０～Ｓ１６０）、
    　前記車両の利用者に対して、前記対象サービスの提供を開始するか否かを確認する機能を、前記車両ＡＰＩを介して提供するように構成された前記開始確認部にて、前記利用者の開始意図が確認された場合、前記対象サービスの提供に必要な前記車両ＡＰＩに対するアクセス権を、前記ＡＰＩ利用アプリに付与する（Ｓ１７０～Ｓ２００）
    　アクセス制御方法。
PCT/JP2023/033750 2022-09-29 2023-09-15 アクセス制御装置、アクセス制御方法 WO2024070774A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022156690 2022-09-29
JP2022-156690 2022-09-29

Publications (1)

Publication Number Publication Date
WO2024070774A1 true WO2024070774A1 (ja) 2024-04-04

Family

ID=90477399

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/033750 WO2024070774A1 (ja) 2022-09-29 2023-09-15 アクセス制御装置、アクセス制御方法

Country Status (1)

Country Link
WO (1) WO2024070774A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006114878A1 (ja) * 2005-04-21 2006-11-02 Mitsubishi Electric Corporation コンピュータ及びコンピュータリソースへのアクセス制御方法及びアクセス制御プログラム
JP2019026067A (ja) * 2017-07-31 2019-02-21 日立オートモティブシステムズ株式会社 自律運転制御装置、自律移動車及び自律移動車制御システム
JP2022120689A (ja) * 2021-02-05 2022-08-18 トヨタ自動車株式会社 車載情報処理装置、情報処理方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006114878A1 (ja) * 2005-04-21 2006-11-02 Mitsubishi Electric Corporation コンピュータ及びコンピュータリソースへのアクセス制御方法及びアクセス制御プログラム
JP2019026067A (ja) * 2017-07-31 2019-02-21 日立オートモティブシステムズ株式会社 自律運転制御装置、自律移動車及び自律移動車制御システム
JP2022120689A (ja) * 2021-02-05 2022-08-18 トヨタ自動車株式会社 車載情報処理装置、情報処理方法及びプログラム

Similar Documents

Publication Publication Date Title
US9513133B2 (en) System for parking time management
US20080204191A1 (en) System and method for controlling information access on a mobile platform
CN109643117B (zh) 车辆移动授权
US20190366979A1 (en) Management server, management system, and management method
US10488862B2 (en) Method for communication between a control station which externally controls an automatically traveling vehicle and a further traffic participant as well as an automatically traveling vehicle
US9475496B2 (en) Modified autonomous vehicle settings
EP3576378B1 (en) Transferring control of vehicles
US20190210560A1 (en) Vehicle access authorization
EP2931567A1 (de) System zum selektiven öffnen eines fahrzeuges durch einen servicedienstleister
CN111798008B (zh) 用于建立对共乘体验特征的主要和次要控制的系统和方法
DE102019122259A1 (de) Intelligente fahrzeugverbindung
DE102017205993A1 (de) System und Verfahren zur selektiven Freischaltung von Fahrzeugfunktionen
US11695766B2 (en) Apparatus and server for sharing position information of vehicle
WO2024070774A1 (ja) アクセス制御装置、アクセス制御方法
WO2021004212A1 (zh) 一种车辆的驾驶权限的移交方法及装置
US20230129668A1 (en) Server, information processing system and information processing method
CN111966087A (zh) 一种无人车操控方法及无人车
DE102019114358A1 (de) Vorübergehender und benutzerdefinierter fahrzeugzugriff
CN114449525A (zh) 运输服务上的认证权限提升
US11610490B2 (en) Control device for vehicle and method of operating vehicle
WO2021019637A1 (ja) セキュリティ装置、サーバ装置、セキュリティシステム、及びセキュリティ機能設定方法
WO2024004791A1 (ja) 認証システム、認証装置および認証プログラム
US20230129564A1 (en) Server, information processing system and information processing method
WO2023189768A1 (ja) 認証システムおよび中継装置
WO2022262679A1 (zh) 车辆控制方法及相关装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23872002

Country of ref document: EP

Kind code of ref document: A1