Access control device, access control method, and program

Abstract

An access control device according to an aspect of the present disclosure is mounted on a vehicle, and comprises: a request reception unit; an acquisition unit; and a control unit. The request reception unit receives a request to access at least one API from an application. The control unit controls the request to access said at least one API on the basis of an authorization policy in a region. The control unit changes the control of the request to access said at least one API when movement information is acquired by the acquisition unit.

Description

Access control device, access control method, and program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2023-141359, filed with the Japan Patent Office on August 31, 2023, the entire contents of which are incorporated herein by reference.

[0002] The present disclosure relates to techniques for controlling access.

[0003] The following Patent Document 1 discloses a technology for restricting access based on an access authorization policy when an access to resources or data held by a mobile terminal via a service application is detected in an open platform for mobile terminals. The access authorization policy specifies whether "who," "to what," and "what to do" are permitted or prohibited.

[0004] Patent No. 6124627

[0005] It is expected that in the future, a large number of third-party service applications will be installed in vehicle electronic control systems. When third-party service applications access vehicle functions or information, it will be necessary to restrict access depending on the vehicle's environment in the area in which it is traveling.

[0006] After detailed consideration by the inventors, it was found that the vehicle-related environment differs from region to region, and it is difficult for a third party to develop a service application that can understand the vehicle-related environment in each region and achieve precise access control according to the environment.

[0007] One aspect of the present disclosure is to desirably realize precise access control according to the local environment while reducing the burden on application providers.

[0008] An access control device according to one aspect of the present disclosure is mounted on a vehicle and includes a request receiving unit, an acquisition unit, and a control unit. The request receiving unit receives an access request to each of the at least one API from an application that uses vehicle data and / or vehicle functions via at least one API among a plurality of APIs, each API corresponding to either vehicle data or vehicle functions. The acquisition unit acquires movement information indicating that the vehicle has moved from a first region to a second region. The control unit controls the access request to each of the at least one API based on an authorization policy that defines access authority from the application to each of the plurality of APIs depending on the region. The control unit changes control of the access request to each of the at least one API when the movement information is acquired by the acquisition unit.

[0009] An access control device according to one aspect of the present disclosure automatically changes access request control based on detection of vehicle movement. This eliminates the need for application providers to adapt their applications to the vehicle environments of various regions. This reduces the burden on application providers and enables precise access control tailored to the local environment.

[0010] Another aspect of the present disclosure is an access control method that is executed by an on-board device mounted on a vehicle, and receives an access request to each of at least one API from an application that uses data and / or vehicle functions via at least one API of a plurality of APIs, each API corresponding to either vehicle data or vehicle functions; obtains movement information indicating that the vehicle has moved from a first area to a second area; controls the access request to each of the at least one API based on an authorization policy that specifies access rights from the application to each of the plurality of APIs depending on the area; and changes the control of the access request to each of the at least one API when the movement information is obtained.

[0011] When the access control method is executed by an in-vehicle device, the same effects as those of the access control device are achieved.

[0012] A program according to yet another aspect of the present disclosure causes an onboard device mounted on a vehicle to receive an access request to each of the at least one API from an application that uses vehicle data and / or vehicle functions via at least one API among a plurality of APIs, each API corresponding to either vehicle data or vehicle functions; acquire movement information indicating that the vehicle has moved from a first region to a second region; control the access request to each of the at least one API based on an authorization policy that specifies access rights from the application to each of the plurality of APIs depending on the region; and change the control of the access request to each of the at least one API when the vehicle movement information is acquired.

[0013] When the in-vehicle device executes the program, the same effects as those of the access control device can be achieved.

[0014] 1 is a block diagram showing the configuration of a mobility service providing system. FIG. 2 is a block diagram showing the configuration of an ECU. FIG. 3 is a block diagram showing the functional configuration of an in-vehicle system. FIG. 4 is a block diagram showing the configuration of an API gateway. FIG. 5 is a diagram explaining the contents of user information. FIG. 6 is a diagram showing an example of an authorization policy by region. FIG. 7 is a diagram showing an example of a correspondence between countries and group attributes. FIG. 8 is a diagram showing an example of an authorization policy related to safety. FIG. 9 is a diagram showing an example of an authorization policy related to company property. FIG. 10 is a diagram showing an example of an authorization policy related to personal property. FIG. 11 is a flowchart showing access control processing executed by a request receiving unit, an acquiring unit, and a control unit.

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

[0016] <1. Configuration> <1-1. Configuration of Mobility Service Providing System> The configuration of a mobility service providing system 1 according to this embodiment will be described with reference to FIG. 1 . The mobility service providing system 1 includes an in-vehicle system 100 mounted on a vehicle, a cloud server 200, and a mobile terminal 300. The vehicle may be capable of both manual and automatic driving, or may be capable of only one of manual and automatic driving. The vehicle may be a hybrid vehicle equipped with an engine and an electric motor as a driving source. Alternatively, the vehicle may be a vehicle having only one of an engine and an electric motor as a driving source.

[0017] As shown in FIG. 1 , the in-vehicle system 100 includes one electronic control unit (hereinafter referred to as ECU) 2, multiple ECUs 3, multiple ECUs 4, an external communication device 5, an internal communication network 6, a camera 8, and a GPS receiver 9.

[0018] The ECU 2 has a function of relaying frames transmitted through the in-vehicle communication network 6, and controls a plurality of ECUs 3 to realize coordinated control of the entire vehicle.

[0019] The ECU 2 includes a microcomputer having a CPU 2a, a ROM 2b, a RAM 2c, and the like. Various functions of the ECU 2 are realized by the CPU 2a executing a program stored in a non-transitory tangible recording medium. In this embodiment, the ROM 2b corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program results in the execution of a method corresponding to the program. Note that some or all of the functions executed by the CPU 2a may be configured with hardware such as one or more ICs. Furthermore, the ECU 2 may include one microcomputer or multiple microcomputers.

[0020] Like the ECU 2, the plurality of ECUs 3, the plurality of ECUs 4 and the exterior communication device 5 each include one or more microcomputers having a CPU, a ROM, a RAM and the like.

[0021] Each of the multiple ECUs 3 is installed in a domain divided by the vehicle's function, and mainly controls the multiple ECUs 4 installed in its assigned domain. Each ECU 3 is connected to the subordinate ECUs 4 via a lower-level network (e.g., CAN) installed individually. CAN stands for Controller Area Network. The ECU 3 centrally manages access rights to the subordinate ECUs 4 and performs user authentication, etc. The domains include, for example, state recognition, powertrain, body, chassis, and cockpit.

[0022] The ECUs 4 connected to the ECU 3 belonging to the state recognition domain include, for example, an ECU 4 that controls a camera 8, an ECU 4 that controls a GPS receiver 9, and an ECU 4 that controls a radar. The camera 8 is installed in at least one location on the front, rear, left, or right side of the vehicle to capture images of the outside of the vehicle. The ECU 4 that controls the GPS receiver 9 calculates the current position of the vehicle based on the GPS signal received by the GPS receiver 9.

[0023] The ECUs 4 connected to the ECU 3 belonging to the power train 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.

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

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

[0026] The ECUs 4 connected to the ECU 3 belonging to the cockpit include, for example, an ECU 4 that controls the display of meters and navigation, and an ECU 4 that controls input devices operated by the vehicle occupants.

[0027] The exterior-vehicle communication device 5 performs data communication with the cloud server 200 and the mobile terminal 300 via a wide-area wireless communication network.

[0028] The in-vehicle communication network 6 includes CAN FD and Ethernet. Ethernet is a registered trademark. CAN FD stands for CAN with Flexible Data Rate. The CAN FD connects the ECU 2 to each ECU 3 and the external communication device 5 via a bus. The Ethernet connects the ECU 2 to each ECU 3 and the external communication device 5 individually. As shown in FIG. 2 , the ECU 2 includes an Ethernet switch 7 that switches the Ethernet to be used.

[0029] The cloud server 200 is a computer equipped with a database, and generates an API authorization policy 311 (described later) and stores the API authorization policy 311. The cloud server 200 also stores service applications (i.e., programs) created by multiple service providers. The service providers include suppliers, original equipment manufacturers (hereinafter referred to as OEMs), third parties, etc. The OEM is the vehicle manufacturer that produced the vehicle. The third parties are vehicle owners and third parties other than the OEMs. The third parties are, for example, data utilization businesses that provide services using data collected from vehicles.

[0030] A service user downloads a service application created by a contracted service provider to one of the ECUs 2, 3, and 4. The service user receives a service from the service provider by having one of the ECUs 2, 3, and 4 execute the service application. The service user may be a vehicle user, a vehicle owner, an operation manager, or the like. Services provided by the service provider include a fleet service, a congestion prediction service, a theft prevention service, and the like.

[0031] The mobile terminal 300 is a smartphone, a tablet terminal, a smartwatch, a PC, etc. When any of the ECUs 2, 3, and 4 executes a service application, the service user receives information such as the execution result via the mobile terminal 300. In another embodiment, the mobile terminal 300 may be excluded from the mobility service providing system 1.

[0032] <1-2. Configuration of In-Vehicle System> The software installed in the ECU 2, the plurality of ECUs 3, the plurality of ECUs 4, and the exterior communication device 5 is built in accordance with the AUTomotive Open System ARchitecture (hereinafter referred to as AUTOSAR). AUTOSAR is, for example, an architecture for autonomous driving. AUTOSAR provides functions related to cloud connection and security in addition to communication between software components (hereinafter referred to as SW-C) implemented to realize various applications. SW-C is modularized software to realize a certain function. Note that the software of the mobility service providing system 1 does not necessarily have to be built in accordance with AUTOSAR.

[0033] The ECU 2, the plurality of ECUs 3, the plurality of ECUs 4, and the exterior communication device 5 comprise a platform. The platform provides an environment for executing SW-C written in a hardware-independent format.

[0034] The platform comprises a runtime environment (hereinafter referred to as RTE) and platform software (hereinafter referred to as BSW). The RTE is an interface that connects SW-Cs with each other and between SW-Cs and BSW. The BSW is a layer that connects hardware and SW-Cs, and includes an operating system (hereinafter referred to as OS), drivers, middleware, etc. The functions of the BSW are divided into small modules, and the functions of each module are provided to the SW-Cs via a vehicle API.

[0035] 2, the functional configuration of the ECU 2 will be described. The ECU 2 includes a real-time processing unit 10 and an application processing unit 20. When the ECU 2 includes multiple CPUs 2a, the real-time processing unit 10 and the application processing unit 20 may be realized by processes executed by the same CPU 2a, or the real-time processing unit 10 and the application processing unit 20 may be realized by processes executed by two different CPUs 2a.

[0036] The real-time processing unit 10 executes vehicle control and the like that requires real-time performance in cooperation with the plurality of ECUs 3, 4, and the external-vehicle communication device 5 via the CAN FD. The application processing unit 20 executes various service applications (e.g., entertainment applications) that require high processing power in cooperation with the plurality of ECUs 3, 4, and the external-vehicle communication device 5 via Ethernet.

[0037] The application processing unit 20 transmits instructions based on the processing of various service applications to the real-time processing unit 10. The real-time processing unit 10 transmits information collected from the plurality of ECUs 3, the plurality of ECUs 4, and the exterior communication device 5 via the CAN FD to the application processing unit 20. The real-time processing unit 10 and the application processing unit 20 cooperate with each other to realize various functions.

[0038] The real-time processing unit 10 includes a first platform (hereinafter, referred to as PF) 11. The application processing unit 20 includes a second PF 21.

[0039] The real-time processing unit 10 includes a control system functional block group 12. The control system functional block group 12 is a collection of software modules that operate on the first PF 11. Each software module is configured with one or more SW-Cs, receives a request from a client, processes the request, and returns the result.

[0040] The control system functional block group 12 includes a vehicle API that receives commands related to vehicle motion. The control system functional block group 12 is a software module that manages the commands received by the vehicle API to achieve consistent vehicle control. The control system functional block group 12 outputs various commands to the multiple ECUs 3, multiple ECUs 4, and exterior communication device 5 via CAN FD. The multiple ECUs 3, multiple ECUs 4, and exterior communication device 5 receive and execute the various commands.

[0041] The first PF 11 includes a conversion gateway 111. The conversion gateway 111 converts a communication frame in CAN FD format received by the real-time processing unit 10 into a communication frame in Ethernet format and provides the communication frame to the application processing unit 20. The conversion gateway 111 also converts a communication frame in Ethernet format provided from the application processing unit 20 into a communication frame in CAN FD format.

[0042] The application processing unit 20 includes a hypervisor 22 and executes software on multiple virtual machines. In another embodiment, the hypervisor 22 may be excluded from the application processing unit 20.

[0043] The application processing unit 20 includes service applications 23 and 24. The service applications 23 and 24 are a set of applications that run on the second PF 21, and each of the applications provides a predetermined service.

[0044] The service applications 23 are a collection of applications provided by the OEM. Each of the service applications 23 includes one or more SW-Cs. The service applications 23 may include applications developed by the OEM itself and applications developed by other vendors.

[0045] The service applications 24 are a collection of applications provided by third parties (hereinafter referred to as third-party apps). Each of the service applications 24 includes one or more SW-Cs.

[0046] The second PF 21 includes a control system function block group 25 , a data system function block group 26 , and an API gateway 30 .

[0047] The control system functional block group 25 is a collection of software modules equipped with a vehicle API for receiving requests related to vehicle control from the service applications 23, 24. The control system functional block group 25 converts access requests to the vehicle API from the service applications 23, 24, which are expressed in a vehicle-independent format, into access requests to the vehicle API expressed in a vehicle-dependent format and provides the converted requests to the real-time processing unit 10. The control system functional block group 25 includes a motion-related vehicle API for controlling the motion of the vehicle, and a non-motion-related vehicle API other than the motion-related vehicle API. The vehicle API is an API for using vehicle functions or vehicle data.

[0048] The motor-related vehicle API transfers the received access request to the control-related functional block group 12. The control-related functional block group 12 transfers the access request to any one of the plurality of ECUs 3, 4, and the external-vehicle communication device 5 that corresponds to the access request via the in-vehicle communication network 6 such as CAN FD. The non-motor-related vehicle API transfers the received access request to any one of the plurality of ECUs 3, 4, and the external-vehicle communication device 5 that corresponds to the access request via the in-vehicle communication network 6 such as CAN FD.

[0049] For example, as shown in FIG. 3 , the control system functional block group 25 includes a non-motion system vehicle API 351, and one of the multiple ECUs 3 includes a first vehicle function unit 60. The vehicle API 351 receives an access request to use the first vehicle function unit 60 from the service applications 23 and 24 via the API gateway 30. The access request includes an API-ID. The API-ID is information that uniquely identifies the process ID of the service application 23 or 24 (hereinafter referred to as the source application) that is the user, and the vehicle API that is the destination of the user (hereinafter referred to as the destination API). The vehicle API 351 transfers the received access request to the ECU 3 that includes the first vehicle function unit 60.

[0050] The data-related functional block group 26 is a set of software modules equipped with a vehicle API for handling vehicle data acquired and stored via the real-time processing unit 10. The data-related functional block group 26 abstracts the vehicle data provided by the real-time processing unit 10 and expressed in a vehicle-dependent format into vehicle data in a vehicle-independent format and stores the abstracted vehicle data.

[0051] The data-related functional block group 26 has a vehicle API that provides a function of transmitting designated vehicle data to the ECU 3 or the like via the in-vehicle communication network 6 such as Ethernet. In particular, when the data-related functional block group 26 transmits vehicle data to the exterior communication device 5, the exterior communication device 5 may upload the received vehicle data to the cloud server 200. The data-related functional block group 26 may also have a vehicle API that provides a function of acquiring data from the cloud server 200.

[0052] For example, as shown in FIG. 3 , the data-related functional block group 27 includes vehicle APIs 352, 353, and 354. One of the multiple ECUs 3 includes a second vehicle function unit 70. Furthermore, one of the multiple ECUs 4 includes a third vehicle function unit 80, and another of the multiple ECUs 4 includes a fourth vehicle function unit 90. In this embodiment, the third vehicle function unit 80 provides a function of determining the country or region in which the vehicle is located based on the current location of the vehicle. Furthermore, the third vehicle function unit 80 provides a function of acquiring movement information indicating that the vehicle has moved from a first region to a second region based on the determined region. The second region is different from the first region. The fourth vehicle function unit 90 provides a function of recognizing the external environment based on data acquired by vehicle sensors such as the camera 8 and radar. The external environment is, for example, display objects that indicate information about the region in which the vehicle is traveling, including road markings, signs, billboards, etc., around the vehicle. The fourth vehicle function unit 90 provides a function of recognizing the environment outside the vehicle based on images acquired by vehicle sensors, etc.

[0053] The vehicle API 352 receives an access request for providing vehicle data to the second vehicle function unit 70 from the service applications 23 and 24 via the API gateway 30. In response to the received access request, the vehicle API 352 provides the vehicle data received from the service applications 23 and 24 to the ECU 3 including the second vehicle function unit 70 via the API gateway 30.

[0054] The vehicle API 353 receives an access request for acquiring area information and / or movement information from the service applications 23, 24 via the API gateway 30. The vehicle API 353 transfers the received access request to the ECU 4 including the third vehicle function unit 80, and receives the area information and / or movement information specified by the service applications 23, 24 from the third vehicle function unit 80. The vehicle API 353 provides the received area information and / or movement information to the service applications 23, 24 via the API gateway 30.

[0055] The vehicle API 354 receives an access request for acquiring recognition information of the exterior environment from the service applications 23 and 24 via the API gateway 30. The vehicle API 353 transfers the received access request to the ECU 4 including the fourth vehicle function unit 90, and receives the recognition information of the exterior environment specified by the service applications 23 and 24 from the fourth vehicle function unit 40. The vehicle API 353 provides the received recognition information of the exterior environment to the service applications 23 and 24 via the API gateway 30.

[0056] When the ECU 2 communicates with the plurality of ECUs 3, 4, and the exterior communication device 5 via the control system functional block group 25, the communication means is not limited to CAN FD, but may be Ethernet or another communication means. When the ECU 2 communicates with the plurality of ECUs 3, 4, and the exterior communication device 5 via the data system functional block group 26, the communication means is not limited to Ethernet, but may be CAN FD or another communication means.

[0057] The API gateway 30 is configured using the functions of a virtual function bus (hereinafter referred to as VBF). VBF is middleware, also called a software bus, that realizes communication between SW-Cs and between SW-Cs and BSWs without regard for hardware or communication protocols.

[0058] The API gateway 30 controls whether to accept an access request, the transmission of an access request that is determined to be acceptable, and the transmission and reception of data between the service applications 23 and 24 and the vehicle APIs 351, 352, 353, and 354.

[0059] Communication between SW-Cs is performed between applications belonging to the service applications 23 and 24. That is, communication between SW-Cs corresponds to access from one SW-C to an API provided by another SW-C.

[0060] Communication between the SW-C and the BSW is performed between the service applications 23 and 24 and the control system function block group 25 and data system function block group 26. In other words, communication between the SW-C and the BSW corresponds to access from the SW-C to the vehicle API. In the following description, it is assumed that there is a one-to-one correspondence between the SW-C and the service application.

[0061] In this embodiment, the ECU 2 includes the real-time processing unit 10 and the application processing unit 20 , but in another embodiment, the ECU 2 may not include the real-time processing unit 10 or the application processing unit 20 .

[0062] In this embodiment, the ECU 2 is equipped with service applications 23, 24, a control system functional block group 25, a data system functional block group 26, and an API gateway 30, but in another embodiment, in addition to or instead of the ECU 2, at least one of the multiple ECUs 3, the multiple ECUs 4, and the external communication device 5 may be equipped with the service applications 23, 24, the control system functional block group 25, the data system functional block group 26, and the API gateway 30, in a centralized or distributed manner.

[0063] The first to fourth vehicle function units 60 to 90 may be mounted in one of the ECU 2, the plurality of ECUs 3, the plurality of ECUs 4, and the exterior communication device 5, or may be distributed across multiple units. In another embodiment, the in-vehicle system 100 may include three or less, or five or more, functional units.

[0064] 4, the API gateway 30 will be described in detail. The API gateway 30 includes an information storage unit 31, an API processing unit 32, and a status monitoring unit 33.

[0065] The information storage unit 31 stores an API authorization policy 311, a correspondence table 312, and user information 313. The correspondence table 312 is stored in the RAM 2c, and the API authorization policy 311 and the user information 313 are stored in the ROM 2b. However, the API authorization policy 311 and the user information 313 may also be stored in the non-volatile RAM 2c.

[0066] The API authorization policy 311 is a collection of information for determining whether the service applications 23 and 24 have access rights to the vehicle API. The API authorization policy 311 is downloaded from the cloud server 200 and stored in the information storage unit 31. The API authorization policy 311 may be downloaded and updated based on an instruction from the cloud server 200.

[0067] The correspondence table 312 includes first correspondence information and second correspondence information. The first correspondence information associates a process ID, which is dynamically assigned to a process, with a unique app ID of a service application executed by that process. A process is an execution unit of a program in the OS. The second correspondence information associates a unique API-ID of each of multiple vehicle APIs with a process ID assigned to a service application that uses vehicle functions or vehicle data via the vehicle API. The correspondence table 312 is generated by the OS when the system is started and a process for each service application is generated.

[0068] The user information 313 is arbitrarily set by the vehicle user. The vehicle user may include not only the driver but also passengers in the vehicle. The user information 313 is referenced when the control unit 323 (described later) determines whether or not access authority is granted using the API authorization policy 311. For example, as shown in FIG. 5 , the user information 313 specifies, for each vehicle user, whether or not to permit a request for access to privacy information from the service applications 23 and 24. The vehicle user is identified by a user ID, and the privacy information is identified by a privacy ID. The user information 313 may include contact information for the vehicle user.

[0069] The API processing unit 32 has the functions of a request receiving unit 321, an acquisition unit 322, and a control unit 323. The request receiving unit 321 receives access requests to the vehicle APIs 351 to 354 corresponding to the first to fourth vehicle function units 60 to 90, respectively. The acquisition unit 322 acquires movement information acquired by the third vehicle function unit 80. That is, the acquisition unit 322 acquires movement information indicating that the vehicle has moved from a first region to a second region. The control unit 323 determines whether to permit or prohibit the access request based on the API authorization policy 311. Furthermore, the control unit 323 changes control of the access request when the acquisition unit 322 acquires the movement information. Note that in another embodiment, the acquisition unit 322 may acquire the region determined by the third vehicle function unit 80. Then, the acquisition unit 322 may acquire movement information indicating that the vehicle has moved from the first region to the second region based on the acquired region.

[0070] Laws and regulations regarding vehicles and vehicle users vary from region to region. For example, some countries prohibit certain driver actions while driving, while others do not. Also, some countries protect the privacy of certain information, while others do not. Furthermore, within a single country, there are areas where certain vehicle functions are restricted, while there are areas where certain functions are not restricted.

[0071] The API authorization policy 311 specifies whether or not access is authorized to each of a plurality of vehicle APIs by region. For example, the API authorization policy 311 specifies that in a region where certain information corresponds to privacy information, access is "no" to a vehicle API that provides certain information to the service applications 23 and 24. The API authorization policy 311 specifies that in a region where certain information does not correspond to privacy information, access is "yes" to a vehicle API that provides certain information to the service applications 23 and 24. Furthermore, for example, the API authorization policy 311 specifies that in a region where a certain function is restricted, access is "no" to a vehicle API that provides a certain function to the service applications 23 and 24. The API authorization policy 311 specifies that in a region where the certain function is not restricted, access is "yes" to a vehicle API that provides a certain function to the service applications 23 and 24.

[0072] The control unit 323 controls access requests for each vehicle API by referencing a first policy in the API authorization policy 311 corresponding to a first region in which the vehicle is located, based on the country or region information acquired from the third vehicle function unit 80 and the recognition information of the exterior environment acquired from the fourth vehicle function unit 90. That is, the control unit 323 permits or prohibits access requests for each vehicle API. Furthermore, when movement information is acquired by the acquisition unit 322, the control unit 323 controls access requests for each vehicle API by referencing a second policy in the API authorization policy 311 corresponding to a second region in which the vehicle is located. Furthermore, the control unit 323 acquires exterior information indicated by signs, billboards, and road markings in the region in which the vehicle is located based on the recognition information of the exterior environment, and determines whether or not there are any regional restrictions based on the exterior information. Details of the API authorization policy 311 will be described later.

[0073] When the control unit 323 permits an access request to the vehicle API 351 of the first vehicle function unit 60, the service applications 23 and 24 can use the functions of the first vehicle function unit 60 via the vehicle API 351. When the control unit 323 prohibits an access request to the vehicle API 352 of the second vehicle function unit 70, the service applications 23 and 24 cannot access the functions of the second vehicle function unit 70 via the vehicle API 352.

[0074] When the control unit 323 receives an access request to the vehicle API, it identifies the application ID of the source application based on the process ID indicated in the access request and the correspondence table 312. The control unit 323 executes access restriction processing based on the identified application ID, the API-ID of the destination API indicated in the access request, and the API authorization policy 311, and controls the access request to the vehicle APIs 351 to 352. Details of the access restriction processing will be described later.

[0075] The status monitoring unit 33 monitors the access status from each service application to each of the vehicle APIs 351 to 354 and generates status information indicating the access status. The status information is generated by, for example, tallying up the number of accesses to each of the vehicle APIs 351 to 354 and the amount of data handled in processing for each application.

[0076] 2. API Authorization Policy The cloud server 200 includes a microcomputer having a CPU, ROM, RAM, etc., and a database. Various functions of the cloud server 200 are realized by the CPU executing programs stored on a non-transient tangible recording medium. The cloud server 200 executes an authorization policy generation process to generate an API authorization policy 311, and stores the generated API authorization policy 311 in the database.

[0077] The cloud server 200 generates an API authorization policy 311 that specifies whether or not the service applications 23 and 24 have access rights to each vehicle API for each region. As described above, laws and regulations regarding vehicles and users vary depending on the community or country that includes multiple countries. Furthermore, regulations vary depending on the state, town, or district within a single country. The cloud server 200 generates the API authorization policy 311 that specifies whether or not the service applications 23 and 24 have access rights for each region to comply with the laws and regulations. In this embodiment, the region may be a community or country that includes multiple countries, or a state, town, or district within a single country. In this way, the API authorization policy 311 specifies whether or not the service applications 23 and 24 have access rights for each region and for each service application.

[0078] Furthermore, the cloud server 200 may prepare multiple viewpoint-specific policies generated from different viewpoints for each S.F.O.P. The viewpoint-specific policies may be generated by the cloud server 200, or may be generated elsewhere and collected by the cloud server 200. S.F.O.P is a viewpoint defined as a security protection asset. S stands for Safety and means restricting access to vehicle APIs that affect safety. F stands for Financial and means restricting access to vehicle APIs that affect corporate or personal property. O stands for Operational and means restricting access to vehicle APIs that affect the operational performance of the vehicle. P stands for Privacy and means restricting access to vehicle APIs that affect privacy information. Viewpoint-specific policies do not necessarily need to be prepared for all viewpoints of S.F.O.P. Furthermore, multiple viewpoint-specific policies may be prepared for one viewpoint.

[0079] The viewpoint-based policies include static viewpoint-based policies and dynamic viewpoint-based policies. The static viewpoint-based policies are generated based on the static viewpoints of the service applications 23 and 24. The dynamic viewpoint-based policies are generated based on the dynamic viewpoints of the service applications 23 and 24.

[0080] The static aspect of the service applications 23, 24 is information about characteristics that do not change depending on the usage environment, usage situation, etc. of the service applications 23, 24. The static aspect of the service applications 23, 24 includes, for example, information indicating the safety of the processing executed by the service applications 23, 24, information indicating the provider of the service applications 23, 24, etc. The dynamic aspect of the service applications 23, 24 is information about characteristics that change depending on the usage environment, usage situation, etc. of the service applications 23, 24. The dynamic aspect of the service applications 23, 24 includes, for example, restrictions imposed by a billing contract with the provider of the service applications 23, 24, and information arbitrarily set by the vehicle user, etc.

[0081] The cloud server 200 may generate an API authorization policy 311 for each region for each of a plurality of viewpoints, or may generate an API authorization policy 311 for each viewpoint for each of a plurality of regions.

[0082] 2-1. Authorization Policy by Region The authorization policy by region included in the API authorization policy 311 will be described with reference to FIGS. 6 and 7. The table shown in FIG. 7 associates five countries with group attributes A to D, which are classified based on the laws and regulations of each country. The table of authorization policies by region shown in FIG. 6 indicates whether or not each country identified by the group attribute has access authority to each of the destination APIs P1 to P6 identified by the API-ID. A circle indicates that access authority is present, and an x ​​indicates that access authority is absent. A triangle indicates that access authority is present when permitted by the vehicle user. That is, a triangle indicates that access authority is absent by default, and that the access authority can be changed from "absent" to "present" or maintained at "absent" based on the vehicle user's intention.

[0083] Whether or not to permit access to privacy information from the service applications 23, 24, and to what extent access is permitted, depends on the intention of the vehicle user. Therefore, the control unit 323 prioritizes the intention of the vehicle user regarding whether or not access is authorized to the vehicle APIs 351-354 that provide privacy information. Even if the control unit 323 prohibits access to the vehicle APIs 351-354 that provide specific privacy information based on the initial settings for the area where the vehicle is located, the control unit 323 permits access to the vehicle APIs 351-354 from the service applications 23, 24 if the vehicle user permits access to the specific privacy information.

[0084] Furthermore, the region-specific authorization policy may specify the priority of an access request when a plurality of vehicle APIs 351 to 354 are accessed from a plurality of service applications 23, 24. The priority is specified for a combination of the type of the service application 23, 24 and the type of the vehicle API 351 to 354. Alternatively, the region-specific authorization policy may specify, for each of the vehicle APIs 351 to 354, the priority of the service application 23, 24 using the vehicle API. The priority may be specified as a relative value among the service applications 23, 24, or as an absolute value. For example, the priority may be specified as one of five values, 1, 2, 3, 4, and 5, with a smaller value indicating a higher priority.

[0085] The multiple service applications 23, 24 provide different services. For example, the regional authorization policy may be specified such that, in region A, the priority of an access request from a first service application to the vehicle API_P1 is higher than the priority of an access request from a second service application to the vehicle API_P2. That is, the regional authorization policy may be specified such that processing of the first service application using the vehicle API_P1 is given higher priority than processing of the second service application using the vehicle API_P2. An example of a regional authorization policy will be described below.

[0086] <2-1-1. First Example> In some countries, laws and regulations prohibit the driver from operating the mobile terminal 300 (for example, making calls, sending emails, searching, etc.) while driving the vehicle. In such countries, a regional authorization policy is used to limit, to the minimum necessary, access from the service applications 23, 24 to vehicle APIs that notify the driver's mobile terminal 300 of information while the vehicle is being driven. For example, the regional authorization policy specifies that, among the aspects of S.F.O.P., access from the service applications 23, 24 to vehicle APIs that provide functions related to S is permitted, but access to vehicle APIs that provide functions related to F.O.P. is prohibited.

[0087] An example of a vehicle API that provides a function related to S is an API that provides a function to notify an abnormality in a vehicle system or a vehicle function (e.g., braking function, steering function, etc.). An example of a vehicle API that provides a function related to P is an API that provides a function to notify that the service applications 23, 24 have accessed privacy information stored in the in-vehicle system 100. An example of a vehicle API that provides a function related to O is an API that provides a function to notify the occurrence of congestion around the vehicle. An example of a vehicle API that provides a function related to F is an API that provides a function to notify a vehicle user of a billing request so that the service applications 23, 24 can add or continue a service or function.

[0088] <2-1-2. Second Example> The definition (or scope) of personal information differs from country to country. For example, in some countries, driving history information alone constitutes personal information, while in other countries, driving history information alone does not constitute personal information. Also, in some countries, hands-free phone book information alone constitutes personal information, while in other countries, hands-free phone book information alone does not constitute personal information. Furthermore, in some countries, call and incoming call history information alone constitutes personal information, while in other countries, call and incoming call history information alone does not constitute personal information.

[0089] The region-specific authorization policy is stipulated to prohibit access from the service applications 23, 24 to the vehicle API that provides the driving history information without the permission of the vehicle user, for countries where the driving history information alone constitutes personal information. The region-specific authorization policy is stipulated to permit access from the service applications 23, 24 to the vehicle API that provides the driving history information, even without the permission of the vehicle user, for countries where the driving history information alone does not constitute personal information.

[0090] The region-specific authorization policy is stipulated to prohibit access from the service applications 23, 24 to the vehicle API that provides the phone book information without the permission of the vehicle user for countries where the phone book information alone is considered personal information. The region-specific authorization policy is stipulated to permit access from the service applications 23, 24 to the vehicle API that provides the phone book information without the permission of the vehicle user for countries where the phone book information alone is not considered personal information.

[0091] Furthermore, the region-specific authorization policy is stipulated to prohibit access to the vehicle API that provides the history information from the service applications 23, 24 without the permission of the vehicle user for countries where the history information alone is considered personal information. The region-specific authorization policy is stipulated to permit access to the vehicle API that provides the history information from the service applications 23, 24 even without the permission of the vehicle user for countries where the history information alone is not considered personal information.

[0092] <2-1-3. Third Example> In one country, there are regions where exhaust gas regulations are in place and regions where exhaust gas regulations are not in place. The region-specific authorization policy is defined to prohibit access from service applications 23 and 24 to vehicle APIs that provide a function for changing the drive mode in regions where exhaust gas regulations are in place. The drive mode change that is prohibited here is a change from a drive mode that suppresses exhaust gas to another drive mode. The region-specific authorization policy is defined to permit access to vehicle APIs that provide a function for changing the drive mode in regions where exhaust gas regulations are not in place.

[0093] <2-1-4. Fourth Example> In some countries, pedestrians have priority over vehicles at intersections, while in other countries, vehicles have priority over pedestrians. A regional authorization policy is defined such that a first access is prioritized over a second access for countries where pedestrians have priority over vehicles. The first access is access from a first service application to a vehicle API that provides a function for notifying pedestrians around the vehicle. The second access is access from a second service application to a vehicle API that provides a function for notifying other vehicles around the vehicle.

[0094] 8, the authorization policy related to safety included in the API authorization policy 311 will be described. The authorization policy related to safety is an example of a static viewpoint-specific policy classified into the S viewpoint.

[0095] An assurance level is assigned to service applications 23, 24 that include processes related to vehicle safety (hereinafter referred to as safety-related applications). The assurance level indicates the reliability of the safety of the processes included in the safety-related applications. A requirement level is assigned to vehicle APIs (hereinafter referred to as safety-related APIs) included in the safety-related applications. The requirement level indicates the reliability of safety required of a service application that uses the safety-related API and requests access to the safety-related API.

[0096] The assurance level and the requirement level are, for example, the Automotive Safety Integrity Level (hereinafter referred to as ASIL). ASIL is a risk classification system defined in the ISO 26262 standard for the functional safety of road vehicles. ASIL is determined by three parameters: probability of exposure, controllability, and severity, and is expressed in four levels, A to D. A corresponds to the lowest level, and D corresponds to the highest level. No requirement level is assigned to non-safety system APIs, and the absence of a requirement level is represented by QM. In other words, the assurance level and the requirement level are essentially expressed in five levels, QM and A to D, with QM being the lowest level. The assurance level and the requirement level do not necessarily need to use ASIL, and any indicator indicating the reliability of safety defined to have multiple levels may be used. Therefore, the assurance level and the requirement level do not need to be four-level indicators, A to D, but may be three-level or less, or five-level or more.

[0097] The safety-related authorization policy table shown in Fig. 8 is generated based on application information and API information. The application information associates application IDs with assurance levels assigned to the service applications 23 and 24 identified by the application IDs. The API information associates API-IDs with requirement levels assigned to the vehicle APIs identified by the API-IDs.

[0098] The security authorization policy table shown in Figure 8 indicates whether each of the source applications S1 to S4, identified by an application ID, has access authority to each of the destination APIs P1 to P6, identified by an API-ID. If the assurance level of the service applications 23 and 24 is equal to or higher than the required level of the vehicle APIs 351 to 354, the service applications 23 and 24 have access authority to the vehicle APIs 351 to 354. If the assurance level of the service applications 23 and 24 is lower than the required level of the vehicle APIs 351 to 354, the service applications 23 and 24 do not have access authority to the vehicle APIs 351 to 354.

[0099] 9, the authorization policy related to the corporate property included in the API authorization policy 311 will be described. The authorization policy related to the corporate property is an example of a static viewpoint-specific policy classified into the F viewpoint.

[0100] The service applications 23 and 24 are assigned group attributes according to their providers. The group attributes include GA, GB, and GC. GA represents an OEM application developed in-house. GB represents an OEM application developed by another vendor. GC represents a third-party application developed by a third party.

[0101] The authorization policy table for corporate assets shown in FIG. 9 is generated based on group attribute-specific access information and application information. The application information associates application IDs with group attributes assigned to service applications 23, 24 identified by the application IDs. The group attribute-specific access right information associates, for each group attribute, API-IDs with the presence or absence of access authority to the vehicle API identified by the API-ID. The reliability of the service applications 23, 24 with group attribute GA is higher than the reliability of the service applications 23, 24 with group attribute GB, which in turn is higher than the reliability of the service applications 23, 24 with group attribute GC. The presence or absence of access authority from each group attribute to each vehicle API is set based on the reliability.

[0102] The authorization policy table for corporate assets shown in FIG. 9 indicates whether each of source applications S1 to S4 identified by an application ID has access authority to each of destination APIs P1 to P6 identified by an API-ID.

[0103] 10, an authorization policy regarding personal property included in the API authorization policy 311 will be described. The authorization policy regarding personal property is an example of a dynamic viewpoint-based policy classified into the F viewpoint.

[0104] The control unit 323 determines whether the service applications 23 and 24 have access rights to each of the vehicle APIs 351 to 354 based on the authorization policy regarding personal property and the API billing contract with the provider of the service applications 23 and 24 .

[0105] The table of authorization policies relating to personal property shown in FIG. 10 associates API-IDs with confirmation necessity information, authority type information, and billing contract content information set for the vehicle API identified by the API-ID.

[0106] The confirmation necessity information indicates whether or not confirmation of dynamic authority regarding personal property is necessary when the control unit 323 determines the access authority to the vehicle APIs 351 to 354 from the service applications 23 and 24. In this embodiment, the authorization policy specifies that confirmation of dynamic authority is necessary when a billing contract regarding access to the vehicle APIs 341 to 354 exists.

[0107] The authority type information indicates which perspective of S.F.O.P. the information corresponds to, and is set to F (i.e., Financial) in the "authorization policy regarding personal property."

[0108] The billing contract content information is information that indicates the content of the billing contract for the vehicle APIs 351 to 354. For example, the billing contract content information includes the upper limit on the number of times the vehicle APIs 351 to 354 can be used, restrictions on pay-per-use billing, and the like.

[0109] 11 , the authorization policy related to privacy included in the API authorization policy 311 will be described. The authorization policy related to privacy is an example of a dynamic viewpoint-specific policy classified into the P viewpoint. The privacy information is related to the privacy of the vehicle user and is stored in the vehicle.

[0110] The table of authorization policies related to privacy shown in FIG. 11 associates API-IDs with confirmation necessity information, authority type information, and privacy information IDs set for the vehicle API identified by the API-ID.

[0111] The confirmation necessity information indicates whether confirmation of dynamic authority related to privacy is necessary or not when the control unit 323 determines the access authority to the vehicle API from the service applications 23 and 24. In this embodiment, the authorization policy related to privacy specifies that confirmation of dynamic authority is necessary when the service applications 23 and 24 use privacy information via the vehicle APIs 351 to 354.

[0112] The authority type information indicates which of the S.F.O.P. aspects the information corresponds to, and is set to P (i.e., Privacy) in the "privacy authorization policy."

[0113] The privacy information ID indicates an ID assigned to the privacy information accessed by each of the vehicle APIs 351 to 354. The control unit 323 refers to a part of the user information 313 that corresponds to the user ID and the privacy ID, and determines whether the vehicle user has permitted the access request to the privacy information.

[0114] 2-6. Authorization Policies by Region for Each of Multiple Perspectives The API authorization policy 311 may include a table of authorization policies by region for all or some of the perspectives of S.F.O.P. For example, from the perspective of security, the API authorization policy 311 may include a three-dimensional table that associates group attributes (i.e., region) and source applications with the presence or absence of access permissions for destination APIs. Furthermore, from the perspective of privacy, the API authorization policy 311 may include a three-dimensional table that associates group attributes, whether confirmation is required, permission types, and privacy information IDs with the presence or absence of permissions for destination APIs.

[0115] Alternatively, the API authorization policy 311 may include authorization policies for all or some aspects of S.F.O.P. for each region. For example, the API authorization policy 311 may include a table of authorization policies related to safety in region A, a table of authorization policies related to safety in region B, a table of authorization policies related to privacy in region A, and a table of authorization policies related to privacy in region B.

[0116] When the cloud server 200 receives a distribution request from the in-vehicle system 100 or when it determines that distribution is necessary, it distributes the generated API authorization policy 311. The in-vehicle system 100 stores the API authorization policy 311 acquired from the cloud server 200 in the information storage unit 31 of the API gateway 30 and uses it in the access control process.

[0117] 12, a description will be given of the access control process executed by the request receiving unit 321, the acquisition unit 322, and the control unit 323. The request receiving unit 321, the acquisition unit 322, and the control unit 323 repeatedly execute the access control process at a predetermined cycle.

[0118] In S10, the request receiving unit 321 receives an access request from at least one service application 23, 24 to one or more vehicle APIs 351 to 354.

[0119] Next, in S20, the acquisition unit 322 acquires area information and movement information from the third vehicle function unit 80, and acquires recognition information of the external environment from the fourth vehicle function unit 90. Then, the control unit 323 recognizes the area in which the vehicle is currently located and the regulations in that area based on the information acquired by the acquisition unit 322. The control unit 323 also detects whether the vehicle has moved across areas between the previous processing cycle and the current processing cycle.

[0120] Next, in S30, the control unit 323 determines whether to permit the received access request based on the API authorization policy 311 corresponding to the region and regulation recognized in S20. If the control unit 323 detects that a vehicle has moved across regions between the previous processing cycle and the current processing cycle, the control unit 323 changes the policy to be referenced among the API authorization policies 311 from a first policy corresponding to a first region to a second policy corresponding to a second region. Furthermore, if the control unit 323 receives access requests from multiple service applications 23, 24, the control unit 323 determines the priority of the multiple access requests based on the API authorization policy 311.

[0121] Next, in S40, the control unit 323 determines whether or not permission from the vehicle user is required to permit access to the vehicle API corresponding to the received access request. That is, the control unit 323 determines whether a triangle mark is set in the authorization policy table shown in Fig. 6. If the control unit 323 determines that permission from the vehicle user is required, the process proceeds to S50. If the control unit 323 determines that permission from the vehicle user is not required, the process proceeds to S60.

[0122] In S50, the control unit 323 executes authorization processing for the vehicle user's access to the vehicle APIs 341 to 354. Specifically, the control unit 323 inquires of the vehicle user via the mobile terminal 300, the navigation device, etc. whether or not to permit access to the corresponding vehicle API. If it is necessary to access the privacy information of a passenger other than the driver, the control unit 323 also inquires of the passenger whether or not to permit access to the corresponding vehicle API. The control unit 323 then accepts a response from the vehicle user via the mobile terminal 300, the navigation device, etc., and ends this processing. For vehicle APIs for which the control unit 323 has received an access permission response from the vehicle user in the current processing cycle, the control unit 323 determines in the processing of S40 that permission from the vehicle user is not required from the next processing cycle onwards.

[0123] In S60, the control unit 323 determines whether to permit each of the received access requests. The control unit 323 determines to permit the access request if the API authorization policy 311 or the vehicle user permits access from the service application 23, 24 to the corresponding vehicle API. If the control unit 323 determines to permit each of the access requests, it proceeds to processing of S70, and if it determines to prohibit the access request, it proceeds to processing of S80.

[0124] In S70, the control unit 323 accesses the vehicle functions or vehicle data provided by the vehicle API via the vehicle API corresponding to the permitted access request, and then ends this processing. When the control unit 323 receives access requests from multiple service applications 23, 24, the control unit 323 accesses the vehicle functions or vehicle data provided by the vehicle API corresponding to the access request with a higher priority. In this case, after completing the processing corresponding to the access request with a higher priority, the control unit 323 may access the vehicle functions or vehicle data provided by the vehicle API corresponding to the access request with a lower priority, or may prohibit the access request with a lower priority.

[0125] In S80, the control unit 323 notifies the service application 23, 24 that the access request has been prohibited, and notifies the service application 23, 24 of the reason for the prohibition of the access request, and then ends this process. For example, the control unit 323 notifies that the access request has been prohibited due to laws or regulations in the area where the vehicle is located. Alternatively, the control unit 323 notifies that the priority of the access request has been lowered and the access request has been prohibited in response to the vehicle moving from a first area to a second area.

[0126] Alternatively / in addition, the control unit 323 may notify the service application 23, 24 that the access request has been prohibited, propose an alternative, and terminate this process. Specifically, the control unit 323 proposes a process using an accessible vehicle API instead of the prohibited vehicle API. For example, when access to a vehicle API that provides a function for displaying traffic congestion information on the screen of the mobile terminal 300 is prohibited, the control unit 323 proposes displaying traffic congestion information on the vehicle navigation screen.

[0127] 4. Effects According to the first embodiment described above in detail, the following effects are achieved.

[0128] (1) The control unit 323 changes the control of access requests based on the acquired vehicle movement information. Therefore, service application providers such as third parties do not need to adapt their service applications to the vehicle environment, such as laws and regulations in various regions. Therefore, it is possible to realize precise access control according to the local environment while reducing the burden on the service application provider.

[0129] (2) The API gateway 30 has an authorization policy 311 that specifies whether or not access rights are granted for each region, and the control unit 323 changes the authorization policy to be referenced depending on the region. This makes it possible to realize access control that is appropriate for the vehicle's environment in various regions.

[0130] (3) The control unit 323 can permit or prohibit an access request for each vehicle API. Therefore, the in-vehicle system 100 can provide more services to vehicle users than when the execution of each service application is permitted or prohibited.

[0131] (4) The control unit 323 can change the priority of access requests from each of the service applications 23 and 24 to each of the vehicle APIs 351 to 354 for each region.

[0132] (5) Even if the control unit 323 has prohibited an access request to a vehicle API related to the privacy information of a vehicle user based on the API authorization policy 311, the control unit 323 can change the access request from prohibited to permitted in response to the vehicle user permitting the access request to the vehicle API related to the privacy information. Therefore, the control unit 323 can control the access request to the vehicle API related to the privacy information, giving priority to the intention of the vehicle user.

[0133] (6) When the control unit 323 prohibits an access request to a vehicle API, the control unit 323 presents an alternative means to the service applications 23 and 24, so that the service applications 23 and 24 can execute processing using an alternative vehicle API.

[0134] (7) When the control unit 323 prohibits an access request to the vehicle API, the control unit 323 notifies the service applications 23 and 24 that the access request has been prohibited and the reason for the prohibition. Therefore, the service applications 23 and 24 can recognize the reason why the access request has been prohibited.

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

[0136] (a) The API gateway 30 and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the API gateway 30 and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the API gateway 30 and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions to be executed by a computer. The method for implementing the functions of each unit included in the API gateway 30 does not necessarily need to include software; all of the functions may be implemented using one or more hardware devices.

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

[0138] (c) In addition to the access control device described above, the present disclosure can also be realized in various forms, such as a system that includes the access control device as a component, or a non-transient physical recording medium such as a semiconductor memory that stores a program for causing a computer to function as the access control device. [Technical Ideas Disclosed in the Present Specification] [Item 1] An access control device (2, 3, 4, 5) mounted on a vehicle, comprising: a request receiving unit (321, S10) configured to receive an access request to each of the at least one API from an application (23, 24) that uses vehicle data and / or functions of the vehicle via at least one API out of a plurality of APIs (351, 352, 353, 354), each of which corresponds to one of the vehicle data and the vehicle functions; an acquisition unit (322, S20) configured to acquire movement information indicating that the vehicle has moved from a first region to a second region; and a control unit (323, S30-S80) configured to control the access request to each of the at least one API based on an authorization policy that defines access authority from the application to each of the plurality of APIs depending on the region, and configured to change control of the access request to each of the at least one API when the movement information is acquired by the acquisition unit. [Item 2] The access control device according to Item 1, further comprising a policy storage unit (31) that stores the authorization policy (311), wherein the control unit (323, S30) is configured to refer to a first policy corresponding to the first region among the authorization policies stored in the policy storage unit before the acquisition unit acquires the movement information, and to refer to a second policy corresponding to the second region among the authorization policies stored in the policy storage unit after the acquisition unit acquires the movement information. [Item 3] The access control device according to Item 1 or 2, wherein the control unit (323) is configured to individually permit or prohibit the access requests to each of the at least one API based on the authorization policy (311).[Item 4] The access control device according to any one of items 1 to 3, wherein the authorization policy (311) defines a priority of an access request from each of a plurality of applications (23, 24) corresponding to different services to each of the plurality of APIs (351, 352, 353, 354), and the control unit (323, S30) is configured to change the priority of the access request based on the authorization policy when the movement information is acquired by the acquisition unit. [Item 5] The access control device according to any one of items 1 to 4, wherein the control unit (323, S50) is configured to individually permit or prohibit the access request to each of the at least one API based on the authorization policy (311), and when any of the access requests is prohibited based on the authorization policy, change the prohibition of the access request to permission in response to a user of the vehicle permitting the access request that was prohibited by the control unit. [Item 6] The access control device according to any one of Items 1 to 5, wherein the control unit (323, S80) is configured to individually permit or prohibit the access requests to each of the at least one API based on the authorization policy (311), and, when any of the access requests is prohibited, (i) notify the application (23, 24) that any of the access requests has been prohibited, and (ii) propose a process that uses an accessible API from among the plurality of APIs instead of a process that uses the API corresponding to the prohibited access request. [Item 7] The access control device according to any one of Items 1 to 6, wherein the control unit (323, S80) is configured to individually permit or prohibit the access requests to each of the at least one API based on the authorization policy (311), and, when any of the access requests is prohibited, notify the application (23, 24) that any of the access requests has been prohibited and the reason for the prohibition.[Item 8] An access control method executed by an on-board device (2, 3, 4, 5) mounted on a vehicle, comprising: receiving an access request from an application (23, 24) that uses vehicle data and / or a function of the vehicle via at least one API among a plurality of APIs (351, 352, 353, 354), each corresponding to one of the vehicle data and the vehicle functions; acquiring movement information indicating that the vehicle has moved from a first region to a second region (S20); controlling the access request to each of the at least one API based on an authorization policy (311) that specifies access rights from the application to each of the plurality of APIs depending on the region (S70, S80); and changing control of the access request to each of the at least one API when the movement information has been acquired (S20, S30). [Item 9] A program that causes an on-board device (2, 3, 4, 5) mounted on a vehicle to execute the following steps: receive an access request from an application (23, 24) that uses vehicle data and / or a function of the vehicle via at least one API of a plurality of APIs (351, 352, 353, 354), each corresponding to one of the vehicle data and the vehicle's functions; acquire movement information indicating that the vehicle has moved from a first region to a second region (S20); control the access request to each of the at least one API based on an authorization policy that specifies access rights from the application to each of the plurality of APIs depending on the region (S70, S80); and change control of the access request to each of the at least one API when the movement information has been acquired (S20, S30).

Claims

1. An access control device (2, 3, 4, 5) mounted on a vehicle, comprising: a request receiving unit (321, S10) configured to receive an access request to each of the at least one API from an application (23, 24) that uses the vehicle data and / or functions of the vehicle via at least one of a plurality of APIs (351, 352, 353, 354), each of which corresponds to either vehicle data or a function of the vehicle; an acquisition unit (322, S20) configured to acquire movement information indicating that the vehicle has moved from a first area to a second area; and a control unit (323, S30-S80) configured to control the access request to each of the at least one API based on an authorization policy that specifies access authority from the application to each of the plurality of APIs depending on the area, and configured to change control of the access request to each of the at least one API when the movement information is acquired by the acquisition unit.

2. An access control device as described in claim 1, further comprising a policy memory unit (31) that stores the authorization policy (311), and the control unit (323, S30) is configured to refer to a first policy corresponding to the first region among the authorization policies stored in the policy memory unit before the movement information is acquired by the acquisition unit, and to refer to a second policy corresponding to the second region among the authorization policies stored in the policy memory unit after the movement information is acquired by the acquisition unit.

3. The access control device according to claim 1 or 2, wherein the control unit (323) is configured to individually permit or prohibit the access request to each of the at least one API based on the authorization policy (311).

4. The access control device according to claim 1 or 2, wherein the authorization policy (311) specifies the priority of access requests from each of a plurality of applications (23, 24) corresponding to different services to each of the plurality of APIs (351, 352, 353, 354), and the control unit (323, S30) is configured to change the priority of the access requests based on the authorization policy when the movement information is acquired by the acquisition unit.

5. The access control device according to claim 1 or 2, wherein the control unit (323, S50) is configured to individually permit or prohibit the access request to each of the at least one API based on the authorization policy (311), and when any of the access requests is prohibited based on the authorization policy, to change the prohibition of the access request to permission in response to a user of the vehicle permitting the access request prohibited by the control unit.

6. The access control device according to claim 1 or 2, wherein the control unit (323, S80) is configured to individually permit or prohibit the access request to each of the at least one API based on the authorization policy (311), and, when any of the access requests is prohibited, (i) notify the application (23, 24) that any of the access requests has been prohibited, and (ii) propose a process using an accessible API among the plurality of APIs instead of a process using an API corresponding to the prohibited access request.

7. The access control device according to claim 1 or 2, wherein the control unit (323, S80) is configured to individually permit or prohibit the access requests to each of the at least one API based on the authorization policy (311), and, if any of the access requests is prohibited, to notify the application (23, 24) that any of the access requests has been prohibited and the reason for the prohibition.

8. An access control method executed by an on-board device (2, 3, 4, 5) mounted on a vehicle, comprising: receiving an access request from an application (23, 24) that utilizes vehicle data and / or functions of the vehicle via at least one of a plurality of APIs (351, 352, 353, 354), each of which corresponds to either vehicle data or a function of the vehicle (S10); acquiring movement information indicating that the vehicle has moved from a first area to a second area (S20); controlling the access request to each of the at least one API based on an authorization policy (311) that specifies access rights from the application to each of the plurality of APIs depending on the area (S70, S80); and changing control of the access request to each of the at least one API when the movement information has been acquired (S20, S30).

9. A program that causes an on-board device (2, 3, 4, 5) mounted on a vehicle to: receive an access request from an application (23, 24) that uses vehicle data and / or functions of the vehicle via at least one of a plurality of APIs (351, 352, 353, 354), each of which corresponds to either vehicle data or a function of the vehicle, to each of the at least one API (S10); acquire movement information indicating that the vehicle has moved from a first area to a second area (S20); control the access request to each of the at least one API based on an authorization policy that specifies access rights from the application to each of the plurality of APIs depending on the area (S70, S80); and change control of the access request to each of the at least one API when the movement information is acquired (S20, S30).

Images