Mobility service providing system, in-vehicle device, and method for determining app usability

Abstract

To provide a technique for appropriately determining whether an application program can be used in an in-vehicle device regardless of the presence of an extension device.SOLUTION: An application DB 42 stores a hardware requirement required for an application. A basic information acquisition section 21 acquires basic information that is hardware information regarding functions of a vehicle 100. An additional information acquisition section 22 acquires additional information that is hardware information regarding a peripheral device group 17 detachably attached to the vehicle 100. An information abstraction section 23 converts the acquired hardware information into information in a common format. An application providing section 44 compares hardware requirements associated with the application with abstracted hardware information regarding an in-vehicle device 10 to which the application is downloaded, and determines whether the application can be used in the in-vehicle device 10.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to a technique for acquiring an application program to be executed by an in-vehicle device. [Background technology]

[0002] Patent Document 1 listed below proposes a technology in which, when an application program (hereinafter referred to as an app) is downloaded from a server and installed on an information device, information about the devices required to run the app is compared with information about devices that can be provided at the location where the app is implemented (hereinafter referred to as provided device information) to determine whether or not the app can be installed. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-182309 Summary of the Invention [Problem to be solved by the invention]

[0004] However, as a result of detailed investigation by the inventors, the following problem was found: When the conventional technology is applied to a vehicle, only information about devices that are originally installed in the vehicle is taken into account as provided device information, and information about extension devices that are later added to the vehicle is not taken into account. Therefore, there is a problem in that it is not possible to accurately determine whether an app can be used in the vehicle (i.e., whether it can be installed).

[0005] One aspect of the present disclosure provides a technique for accurately determining whether an application program can be used in an in-vehicle device, regardless of whether an expansion device is present. [Means for solving the problem]

[0006] One aspect of the present disclosure is a mobility service providing system comprising a server (30), an in-vehicle device (10), a requirement memory unit (42), a first acquisition unit (21, 11: S130), a second acquisition unit (22, 11: S140), an abstraction unit (23, 11: S150, S220), and a feasibility determination unit (44, 31: S520 to S540).

[0007] The server is configured to provide an application program for executing processing utilizing functions provided in the vehicle. The in-vehicle device is mounted on the vehicle and configured to acquire and execute the application program from the server. The requirements storage unit is configured to store hardware requirements necessary for executing the application program. The first acquisition unit is configured to acquire basic information, which is information regarding functions provided in the vehicle that is the vehicle that mounts the in-vehicle device. The second acquisition unit is configured to acquire additional information, which is information regarding removable peripheral devices attached to the vehicle. The abstraction unit is configured to convert the basic information and additional information into abstracted information, which is information in a common format that is independent of the vehicle and the peripheral devices. The feasibility determination unit is configured, when a request is made to download an application program from the server to the in-vehicle device, to compare the hardware requirements associated with the application program to be downloaded with the abstracted information held by the in-vehicle device that is the download destination, and determine whether the application program can be used on the in-vehicle device.

[0008] With this configuration, it is possible to accurately determine whether the on-board device meets the hardware requirements required by the application program, i.e., whether the application program can be used on the on-board device, taking into account not only the vehicle's functions but also the functions of peripheral devices.

[0009] Furthermore, when determining whether an app can be run, not only the vehicle's functions but also the functions of the peripheral devices are taken into consideration. This allows for the development of new business models, such as minimizing the vehicle's functions and customizing peripheral devices according to the app you want to use, or selecting a vehicle that can run the app you want when renting a car.

[0010] One aspect of the present disclosure is an onboard device (10) that acquires from a server and executes an application program for executing processing that utilizes functions provided in the vehicle, and includes a first acquisition unit (21, 11: S130), a second acquisition unit (22, S140), an abstraction unit (23, 11: S150, S220), and a provision unit (25, 43, 11: S160, S230).

[0011] The first acquisition unit is configured to acquire basic information, which is information regarding functions of an on-board vehicle that is a vehicle equipped with the on-board device. The second acquisition unit is configured to acquire additional information, which is information regarding detachable peripheral devices attached to the on-board vehicle. The abstraction unit is configured to convert the basic information and additional information into abstracted information, which is information in a common format independent of the vehicle and the peripheral devices. The provision unit is configured to provide the abstracted information to a server as information for determining whether or not to download an application program.

[0012] With this configuration, it can be suitably used as an in-vehicle device that constitutes the above-mentioned mobility service providing system. One aspect of the present disclosure is an app usability determination method for determining whether an application program for executing processing utilizing functions provided in a vehicle can be used on an onboard device installed in the vehicle, and includes acquisition steps (S130 to S140, S210), abstraction steps (S150, S220), and determination steps (S520 to S540).

[0013] In the acquisition step, basic information, which is information about the functions of the vehicle in which the on-board device is installed, and additional information, which is information about removable peripheral devices attached to the on-board vehicle, are acquired. In the abstraction step, the basic information and additional information are converted into abstract information, which is information in a common format that is independent of the vehicle and the peripheral devices. In the determination step, the hardware requirements necessary to execute the specified application program are compared with the abstraction information possessed by the on-board device that executes the application program, thereby determining whether the application program can be used on the on-board device.

[0014] This method can provide the same effects as those provided by the above-mentioned mobility service providing system. [Brief explanation of the drawings]

[0015] [Figure 1] 1 is a block diagram showing the configuration of a mobility service providing system. [Figure 2] FIG. 2 is a block diagram showing the functional configuration of a cloud server and an in-vehicle device. [Figure 3] 10 is a flowchart showing an attachment process executed by a control unit of the vehicle-mounted device. [Figure 4] 10 is a flowchart showing a restart process executed by a control unit of the vehicle-mounted device. [Figure 5] 10 is a flowchart showing a user setting synchronization process executed by a control unit of an in-vehicle device. [Figure 6] 10 is a flowchart illustrating a server-side synchronization process executed by a control unit of a cloud server. [Figure 7] 10 is a flowchart showing a download process executed by a control unit of a cloud server. DETAILED DESCRIPTION OF THE INVENTION

[0016] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. [1. Hardware configuration] As shown in FIG. 1, the mobility service providing system 1 of this embodiment includes a plurality of on-vehicle devices 10, each mounted on a separate vehicle 100, a cloud server 30, and a terminal device 50. The vehicle 100 may have an automatic driving function in addition to a manual driving function. The vehicle 100 may also be a hybrid vehicle having an engine and an electric motor as a driving source. The vehicle 100 is not limited to a vehicle having an automatic driving function or a hybrid vehicle, but may also be a vehicle having only a manual driving function, or a vehicle having only an engine or only an electric motor as a driving source. Hereinafter, a vehicle equipped with the on-vehicle device 10 will simply be referred to as the vehicle 100.

[0017] The vehicle-mounted device 10 is connected to an in-vehicle network 13. The in-vehicle network 13 may use, for example, a CAN, Ethernet, etc. Both CAN and Ethernet are registered trademarks.

[0018] The on-vehicle device 10 is connected to a communication unit 15 and an ECU group 16 via an on-vehicle network 13. The on-vehicle device 10 performs wireless communication with a cloud server 30 via the communication unit 15. The on-vehicle device 10 also communicates with the ECU group 16 to collect information (hereinafter, basic information) related to functions provided in the vehicle 100.

[0019] The basic information is information about hardware that vehicle 100 is originally equipped with. The basic information may include, for example, the type, performance, and installation location of the hardware. The type of hardware may include, for example, imaging devices, display devices, audio devices, lighting devices, sensors, actuators, and the like. The sensors may include, for example, sensors for detecting the behavior and state of the vehicle, such as a vehicle speed sensor, an acceleration sensor, and a steering angle sensor, as well as sensors for grasping the conditions inside and outside the vehicle, such as radar, lidar, sonar, and cameras. The actuators may include, for example, devices that change the opening and closing of doors and windows, door locks, seat positions, and orientations of mirrors and sensors. The performance of the hardware may include, for example, resolution, frame rate, angle of view, and range of motion. The installation location of the device may include, for example, the front, rear, right side, left side, and interior of the vehicle.

[0020] The vehicle-mounted device 10 is connected to a peripheral device IF 14 to which peripheral devices are connected. The vehicle-mounted device 10 collects information (hereinafter, additional information) relating to functions of a peripheral device group 17 connected to the peripheral device IF 14 via the peripheral device IF 14. The peripheral device group 17 is an additional device that is retrofitted to the vehicle 100, and may include, for example, an imaging device, a display device, an audio device, a lighting device, a sensor, an actuator, etc., similar to the above-mentioned hardware. The content of the additional information is the same as that of the basic information. Hereinafter, the basic information and additional information will be collectively referred to as hardware information.

[0021] The vehicle-mounted device 10 includes a control unit 11 and a storage unit 12 . The control unit 11 includes a CPU 111 and a semiconductor memory such as a RAM or a ROM (hereinafter referred to as a memory 112). The functions of the control unit 11 are realized by the CPU 111 executing a program stored in the memory 112. Furthermore, by executing this program, a method corresponding to the program is performed.

[0022] The storage unit 12 stores at least basic information and additional information acquired via the in-vehicle network 13 and the peripheral device IF 14. The cloud server 30 includes a control unit 31, a communication unit 32, and a storage unit 33. The control unit 31 includes a CPU 311 and a semiconductor memory such as a RAM or a ROM (hereinafter referred to as a memory 312).

[0023] The functions of the control unit 31 are realized by the CPU 311 executing a program stored in the memory 312. Furthermore, by executing this program, a method corresponding to the program is executed.

[0024] The cloud server 30 is a server installed to provide application programs to the vehicle-mounted device 10 in response to requests from users. The application programs (hereinafter referred to as apps) are programs for executing various processes using functions provided in the vehicle 100.

[0025] The cloud server 30 performs wireless communication with the in-vehicle device 10 and the terminal device 50 via the communication unit 32. The storage unit 33 stores applications to be provided to the vehicle-mounted device 10, hardware information provided by the vehicle-mounted device 10, and the like.

[0026] The terminal device 50 is a mobile terminal such as a smartphone, a tablet terminal, or a laptop computer that is owned by a user of the vehicle 100. The user may be the owner of the vehicle 100 or a person who has obtained the right to temporarily use the vehicle 100.

[0027] [2. Functional configuration] The functions of the vehicle-mounted device 10 and the cloud server 30 that allow the vehicle-mounted device 10 to download and execute an application from the cloud server 30 will be described with reference to FIG.

[0028] The in-vehicle device 10 includes a basic information acquisition unit 21, an additional information acquisition unit 22, an information abstraction unit 23, a vehicle-side DB 24, and a vehicle-side synchronization unit 25. The vehicle-side DB 24 is provided in the storage unit 12. The basic information acquisition unit 21, the additional information acquisition unit 22, the information abstraction unit 23, and the vehicle-side synchronization unit 25 are realized by processing executed by the control unit 11.

[0029] The basic information acquisition unit 21 acquires basic information via the in-vehicle network 13. The basic information acquisition unit 21 acquires the unique frame format, bit assignment, etc. used in the in-vehicle network 13 from the model of the vehicle 100, and extracts basic information according to the acquired information.

[0030] The additional information acquisition unit 22 acquires the additional information via the peripheral device IF 14 . The information abstraction unit 23 further abstracts the hardware information obtained by merging the basic information obtained from the basic information acquisition unit 21 and the additional information obtained from the additional information acquisition unit 22, and stores the information in the vehicle-side DB 24.

[0031] The information abstraction unit 23 abstracts the hardware information by applying it to a predefined data structure. The data structure may include, for example, an item for writing which of the predefined categories the type of hardware that is the information source belongs to. The data structure may also include, for example, an item for converting hardware performance expressed in a format specific to the hardware manufacturer or model into a common format (for example, the same unit system) and writing it.

[0032] The hardware information may include the installation location and installation status of the hardware that is the source of the information. In the case of a peripheral device that is added later, the hardware information indicating the installation location and installation status is difficult to automatically identify, so it may be set manually. A method for supplementing the hardware information by manual setting will be described later.

[0033] The vehicle-side synchronization unit 25 transmits the hardware information stored in the vehicle-side DB 24 to the cloud server 30 when the vehicle 100 is started, etc. Furthermore, when the vehicle-side synchronization unit 25 receives a notification from the cloud server 30 indicating that the hardware information has been updated by manual setting, the vehicle-side synchronization unit 25 updates the hardware information stored in the vehicle-side DB 24 in accordance with the content of the received notification. In this way, the vehicle-side synchronization unit 25 synchronizes the hardware information held by the in-vehicle device 10 with the hardware information held by the cloud server 30.

[0034] The cloud server 30 includes a server-side database (hereinafter referred to as server-side DB) 41, an application database (hereinafter referred to as app DB) 42, a server-side synchronization unit 43, and an app providing unit 44. The server-side DB 41 and the app DB 42 are provided in the storage unit 33. The server-side synchronization unit 43 and the app providing unit 44 are realized by processing executed by the control unit 31.

[0035] The server-side DB 41 stores hardware information provided from each in-vehicle device 10, linked to the in-vehicle device 10 that provided the information. The hardware information stored in the server-side DB 41 can be manually updated via the terminal device 50. The server-side DB 41 also stores information specific to the vehicle model related to the acquisition of basic information, such as the bit assignment of communication frames used in the in-vehicle network 13, linked to the vehicle model of the vehicle 100.

[0036] The application DB 42 stores applications in association with application manifests that describe hardware requirements necessary for executing the applications. The hardware requirements are defined by information that can be included in the hardware information.

[0037] The server-side synchronization unit 43 updates the contents of the server-side DB 41 with the hardware information provided from each vehicle-mounted device 10. When the hardware information stored in the server-side DB 41 is updated via the terminal device 50, the server-side synchronization unit 43 transmits the updated hardware information to the vehicle-mounted device 10 associated with the updated hardware information. This synchronizes the hardware information stored in the server-side DB 41 with the hardware information stored in the vehicle-side DB 24.

[0038] The application providing unit 44 receives instructions from a user operating the terminal device 50 via an application store, which is a homepage viewable from the terminal device 50. The application providing unit 44 reads an application designated by the user (hereinafter referred to as a designated application) from the application DB 42 and provides the application to an in-vehicle device 10 designated by the user (hereinafter referred to as a designated in-vehicle device). At this time, the application providing unit 44 reads hardware information associated with the designated in-vehicle device from the server-side DB 41 and also reads an application manifest associated with the designated application from the application DB 42. The application providing unit 44 then compares the read hardware with the application manifest, and if the hardware provided by the designated in-vehicle device satisfies the hardware requirements required by the designated application, allows the designated application to be provided to the designated in-vehicle device.

[0039] The user of the vehicle 100 can arbitrarily set and update the contents of the hardware information stored in the server-side DB 41 via the terminal device 50. In addition, the user of the vehicle 100 can install a specified application into a specified in-vehicle device 10 via the terminal device 50.

[0040] [3. Processing] [3-1. Installation process] The installation process executed by the control unit 11 when the vehicle-mounted device 10 is first started up after the vehicle-mounted device 10 is installed in the vehicle 100 will be described with reference to the flowchart of FIG.

[0041] In S110, the control unit 11 executes an initial setting to acquire, via the terminal device 50, information such as the vehicle model of the vehicle 100 (hereinafter referred to as the subject vehicle) in which the on-board device 10 is installed. In the next step S120, the control unit 11 acquires information related to the acquisition of basic information (e.g., bit assignment of communication frames) that depends on the vehicle model based on the acquired vehicle model information of the vehicle itself from the cloud server 30 via the communication unit 15. By using this unique information, it becomes possible to collect basic information via the in-vehicle network 13.

[0042] In the next step S130, the control unit 11 acquires basic information, which is hardware information relating to the functions of the vehicle 100, via the in-vehicle network 13. In the next step S140, the control unit 11 acquires additional information, which is hardware information relating to the functions of the peripheral device group 17 connected to the peripheral device IF 14, via the peripheral device IF 14.

[0043] In the next step S150, the control unit 11 abstracts the hardware information acquired in steps S130 and S140 by converting it into a common format that is independent of the vehicle model. In the next step S160, the control unit 11 stores the abstracted hardware information in the vehicle-side DB 24 and transmits it to the cloud server 30, and then ends the process. Of the abstracted hardware information stored in the vehicle-side DB 24, at least basic information is stored in a non-volatile memory.

[0044] [3-2. Processing at restart] The restart process executed by the control unit 11 of the vehicle-mounted device 10 each time the vehicle-mounted device 10 is restarted after the control unit 11 has executed the installation process will be described with reference to the flowchart of FIG.

[0045] In S210, the control unit 11 acquires additional information, which is hardware information relating to the functions of the peripheral device group 17 connected to the peripheral device IF 14, via the peripheral device IF 14. In the next step S220, the control unit 11 abstracts the hardware information acquired in step S210 by converting it into a common format that is independent of the vehicle model.

[0046] In the following S230, the control unit 11 stores the hardware information abstracted in S220 in the vehicle-side DB 24 and transmits it to the cloud server 30, and then ends the process. That is, the basic information among the hardware information is collected only once when the on-board device 10 is installed, and the information is synchronized between the on-board device 10 and the cloud server 30. The additional information among the hardware information is collected every time the on-board device 10 is started, and the information is synchronized between the on-board device 10 and the cloud server 30 each time. Note that in this embodiment, only the additional information is repeatedly collected at restart, but the basic information may also be repeatedly collected at restart.

[0047] [3-3. User settings synchronization process] The user setting synchronization process that the control unit 11 of the vehicle-mounted device 10 repeatedly executes while the vehicle-mounted device 10 is running will be described with reference to the flowchart of FIG.

[0048] In S310, the control unit 11 determines whether or not user setting information has been received from the cloud server 30, and if so, the process proceeds to S320, and if not, the process ends.

[0049] In S320, the control unit 11 updates the hardware information stored in the vehicle-side DB 24 in accordance with the update contents of the hardware information indicated in the received user setting information, and then ends the process. Through this update, the control unit 11 synchronizes the hardware information held by the vehicle-mounted device 10 with the hardware information held by the cloud server 30.

[0050] [3-4. Server-side synchronization processing] The server-side synchronization process that is repeatedly executed by the control unit 31 of the cloud server 30 will be described with reference to the flowchart of FIG.

[0051] In S410, the control unit 31 determines whether or not the hardware information has been received from the vehicle-mounted device 10, and if so, proceeds to S420, and if not, proceeds to S430.

[0052] In S420, the control unit 31 associates the received hardware information with the in-vehicle device 10 that transmitted the hardware information (hereinafter referred to as the target in-vehicle device), stores the information in the server-side DB 41, and ends the process. Note that if the hardware information of the target in-vehicle device has already been stored, the stored hardware information is updated with the received hardware information.

[0053] In S430, the control unit 31 determines whether or not a user setting request for hardware information has been received from the terminal device 50, and if a user setting request has been received, the control unit 31 proceeds to S440, and if a user setting request has not been received, the control unit 31 terminates the processing.

[0054] In S440, the control unit 31 updates the hardware information (hereinafter referred to as target information) stored in the server-side DB 41 linked to the vehicle-mounted unit 10 (hereinafter referred to as target vehicle-mounted unit) indicated in the user setting request with the hardware information indicated in the user setting request.

[0055] In the next S450, the control unit 31 transmits the target information to the target vehicle-mounted device so that the hardware information updated in response to the user setting request is reflected in the hardware information held by the target vehicle-mounted device, and then ends the process.

[0056] Examples of hardware information that may be updated in response to a user setting request include information about the performance of peripheral devices for which the information necessary for abstraction is not provided, and information about the installation location and orientation of peripheral devices that cannot be automatically obtained by the vehicle-mounted device 10.

[0057] [3-5. Download process] The download process repeatedly executed by the control unit 31 of the cloud server 30 will be described with reference to the flowchart of FIG.

[0058] In S510, the control unit 31 determines whether or not a download request has been received from the terminal device 50, and if a download request has been received, the process proceeds to S520, and if a download request has not been received, the process ends.

[0059] In the following description, the application program indicated in the download request will be referred to as a target application, and the vehicle-mounted device 10 to which the application is to be downloaded will be referred to as a target vehicle-mounted device. In S520, the control unit 31 acquires the application manifest associated with the target application from the application DB 42.

[0060] In the next step S530, the control unit 31 acquires the hardware information of the target vehicle-mounted device from the server-side DB 41. In the next S540, the control unit 31 determines whether the target application can be used on the target in-vehicle device, and if the target application can be used, the process proceeds to S550, and if the target application cannot be used, the process proceeds to S570. Specifically, the control unit 31 compares the application manifest acquired in S520 with the hardware information acquired in S530, and determines that the target in-vehicle device can be used if the hardware requirements indicated in the application manifest are met by the target in-vehicle device, and determines that the target application cannot be used if the hardware requirements are not met.

[0061] In S550, the control unit 31 notifies the terminal device 50 that is the source of the download request (hereinafter, the request source terminal) of the download permission. In the next step S560, the control unit 31 downloads the target application to the target vehicle-mounted device and ends the process. After the download of the target application to the target vehicle-mounted device is completed, the target vehicle-mounted device installs the target application and executes the target application.

[0062] In S570, the control unit 31 notifies the requesting terminal of a denial of the download, and ends the process. [4. Terminology] In this embodiment, the application DB 42 corresponds to the requirement storage unit in the present disclosure. The basic information acquisition unit 21 and the process of S130 correspond to the first acquisition unit in the present disclosure. The additional information acquisition unit 22 and the process of S140 correspond to the second acquisition unit in the present disclosure. The information abstraction unit 23 and the processes of S150 and S220 correspond to the abstraction unit in the present disclosure. The application provision unit 44 and the processes of S520 to S540 correspond to the possibility determination unit in the present disclosure. The process of S110 corresponds to the specific information acquisition unit in the present disclosure. The vehicle-side synchronization unit 25 and the server-side synchronization unit 43, and the processes of S160, S230, S310 to S320, and S410 to S450 correspond to the information synchronization unit in the present disclosure. The vehicle-side synchronization unit 25 and the server-side synchronization unit 43, and the processes of S160 and S230 correspond to the provision unit in the present disclosure. The processes of S430 to S450 correspond to the user setting unit in the present disclosure. The processes of S130 to S140 and S210 correspond to the acquisition step in this disclosure. The processes of S150 and S220 correspond to the abstraction step in this disclosure. The processes of S520 to S540 correspond to the determination step in this disclosure.

[0063] [5. Effects] According to the first embodiment described above in detail, the following effects are achieved. (1) The mobility service providing system 1 abstracts and manages hardware information (i.e., basic information) related to the functions that the vehicle 100 originally has and hardware information (i.e., additional information) related to the peripheral devices 17 that are added to the in-vehicle device 10. Therefore, when adding an application to the in-vehicle device 10, it is possible to accurately determine whether the in-vehicle device 10 meets the hardware requirements required by the application, i.e., whether the application can be executed on the in-vehicle device 10, taking into account not only vehicle functions but also the functions of the peripheral devices 17. Furthermore, this determination result can be useful when purchasing or installing an application.

[0064] (2) In the mobility service providing system 1, when determining whether an application can be executed, not only the vehicle functions but also the functions of the peripheral device group 17 are taken into consideration. Therefore, new business models can be developed, such as minimizing the functions of the vehicle 100 and customizing the peripheral device group 17 according to the application that the user wants to use, or selecting a vehicle 100 that can run the application that the user wants to use when renting a vehicle.

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

[0066] (a) In the above embodiment, the on-vehicle device 10 abstracts the acquired hardware information and provides it to the cloud server 30. The on-vehicle device 10 may be configured to provide non-abstracted hardware information to the cloud server 30, and the cloud server 30 may abstract the hardware information.

[0067] (b) In the above embodiment, when the cloud server 30 determines whether an app can be used, the cloud server 30 uses hardware information stored in the cloud server 30. The cloud server 30 may be configured to acquire and use hardware information stored in the in-vehicle device 10 as needed. In this case, the server-side DB 41 may be omitted from the cloud server 30. Furthermore, in S530 of the download process shown in FIG. 7, the control unit 31 of the cloud server 30 acquires abstracted hardware information from the in-vehicle device 10 that is the target of app download. In this case, the process of S530 corresponds to the abstracted information acquisition unit.

[0068] (c) In the above embodiment, the cloud server 30 determines whether the application can be used. However, the vehicle-mounted device 10 may be configured to receive an application manifest along with the application from the cloud server 30 and determine whether the application can be used on the vehicle-mounted device 10 side.

[0069] (d) In the above embodiment, the cloud server 30 is used, but it may also be an on-premise server. (e) The control unit 11, 31 and the method thereof 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 control unit 11, 31 and the method thereof 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 control unit 11, 31 and the method thereof 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 as instructions executed by a computer on a computer-readable non-transitory tangible recording medium. The method for implementing the functions of each unit included in the control unit 11, 31 does not necessarily need to include software; all of the functions may be implemented using one or more hardware devices.

[0070] (f) 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.

[0071] (g) In addition to the mobility service providing system 1 described above, the present disclosure can also be realized in various forms, such as the in-vehicle device 10 and cloud server 30 that are components of the mobility service providing system 1, a program for causing a computer to function as the in-vehicle device 10 and cloud server 30, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and a method for determining whether an app can be used.

[0072] [7. Technical Ideas Disclosed in the Present Specification] [Item 1] a server (30) configured to provide an application program for executing processing utilizing functions provided in the vehicle; an on-board device (10) mounted on a vehicle and configured to acquire and execute the application program from the server; a requirements storage unit (42) configured to store hardware requirements necessary for executing the application program; a first acquisition unit (21, 11: S130) configured to acquire basic information that is information about functions of an on-board vehicle that is a vehicle that mounts the on-board device; a second acquisition unit (22, 11: S140) configured to acquire additional information that is information about a detachable peripheral device attached to the vehicle; an abstraction unit (23, 11: S150, S220) configured to convert the basic information and the additional information into abstract information that is information in a common format independent of the vehicle and the peripheral devices; a possibility determination unit (44, 31: S520 to S540) configured to, when a request for downloading the application program from the server to the on-board device is received, compare the hardware requirements associated with the application program to be downloaded with the abstraction information held by the on-board device as the download destination, and determine whether the application program can be used on the on-board device; A mobility service providing system comprising:

[0073] [Item 2] The mobility service providing system according to item 1, the on-board device includes the first acquisition unit, the second acquisition unit, and the abstraction unit; the server includes the requirement storage unit and the possibility determination unit, The vehicle-mounted device further includes an information synchronization unit (25, 43, 11: S160, S230, S310 to S320, 31: S410 to S450) configured to synchronize the abstract information between the vehicle-mounted device and the server. Mobility service provision system.

[0074] [Item 3] The mobility service providing system according to item 1, the on-board device includes the first acquisition unit, the second acquisition unit, and the abstraction unit; the server includes the requirement storage unit and the possibility determination unit, The server further includes an abstraction information acquisition unit configured to acquire the abstraction information from the vehicle-mounted device to be downloaded when the feasibility determination unit performs the feasibility determination. Mobility service provision system.

[0075] [Item 4] A mobility service providing system according to any one of items 1 to 3, The vehicle-mounted device further includes a unique information acquisition unit (11: S110) configured to acquire unique information necessary for understanding the content of the basic information described in a format unique to the vehicle model of the vehicle in which the vehicle-mounted device is installed, when the vehicle-mounted device is initialized. Mobility service provision system.

[0076] [Item 5] A mobility service providing system according to any one of items 1 to 4, the first acquisition unit is configured to operate at least when the in-vehicle device is first started up; The second acquisition unit is configured to operate every time the in-vehicle device is started. Mobility service provision system.

[0077] [Item 6] A mobility service providing system according to any one of items 1 to 5, The apparatus further includes a user setting unit (31: S430 to S450) configured to set the abstraction information by input from outside. Mobility service provision system.

[0078] [Item 7] An in-vehicle device (10) that acquires from a server and executes an application program for executing a process using a function provided in the vehicle, a first acquisition unit (21, 11: S130) configured to acquire basic information that is information about functions of an on-board vehicle that is a vehicle that mounts the on-board device; a second acquisition unit (22, S140) configured to acquire additional information that is information about a detachable peripheral device attached to the vehicle; an abstraction unit (23, 11: S150, S220) configured to convert the basic information and the additional information into abstract information that is information in a common format independent of the vehicle and the peripheral devices; a providing unit (25, 43, 11: S160, S230) configured to provide the abstraction information to the server as information for determining whether or not the application program can be downloaded; An in-vehicle device comprising:

[0079] [Item 8] 1. A method for determining whether an application program for executing a process using a function of a vehicle can be used on an in-vehicle device mounted on the vehicle, comprising: an acquisition step (S130 to S140, S210) of acquiring basic information which is information about functions of a vehicle equipped with the on-board device, and additional information which is information about detachable peripheral devices attached to the on-board vehicle; an abstraction step (S150, S220) of converting the basic information and the additional information into abstract information that is information in a common format independent of the vehicle and the peripheral devices; a determination step (S520 to S540) of determining whether the application program can be used in the on-board device by comparing hardware requirements necessary for executing the designated application program with the abstraction information held by the on-board device that executes the application program; The method for determining whether an application is usable or not comprises the steps of: [Explanation of symbols]

[0080] 10...In-vehicle device, 13...In-vehicle network, 14...Peripheral device IF, 15, 32...Communication unit, 21...Basic information acquisition unit, 22...Additional information acquisition unit, 23...Information abstraction unit, 24...In-vehicle DB, 25...In-vehicle synchronization unit, 30...Cloud server, 41...Server-side DB, 42...Application DB, 43...Server-side synchronization unit, 44...Application provision unit, 50...Terminal device

Claims

1. a server (30) configured to provide an application program for executing a process using a function provided in the vehicle; an on-board device (10) mounted on a vehicle and configured to acquire and execute the application program from the server; a requirements storage unit (42) configured to store hardware requirements necessary for executing the application program; a first acquisition unit (21, 11: S130) configured to acquire basic information that is information related to functions of a vehicle that is a vehicle that mounts the on-board device; a second acquisition unit (22, 11: S140) configured to acquire additional information that is information about a detachable peripheral device attached to the vehicle; an abstraction unit (23, 11: S150, S220) configured to convert the basic information and the additional information into abstract information that is information in a common format independent of the vehicle and the peripheral devices; a possibility determination unit (44, 31: S520 to S540) configured to, when a request for downloading the application program from the server to the on-board device is received, compare the hardware requirements associated with the application program to be downloaded with the abstraction information held by the on-board device as the download destination, and determine whether the application program can be used on the on-board device; A mobility service providing system comprising:

2. The mobility service providing system according to claim 1, the on-board device includes the first acquisition unit, the second acquisition unit, and the abstraction unit; the server includes the requirement storage unit and the possibility determination unit, The vehicle-mounted device further includes an information synchronization unit (25, 43, 11: S160, S230, S310 to S320, 31: S410 to S450) configured to synchronize the abstract information between the vehicle-mounted device and the server. Mobility service provision system.

3. The mobility service providing system according to claim 1, the on-board device includes the first acquisition unit, the second acquisition unit, and the abstraction unit; the server includes the requirement storage unit and the possibility determination unit, The server further includes an abstraction information acquisition unit configured to acquire the abstraction information from the vehicle-mounted device to be downloaded when the feasibility determination unit performs the feasibility determination. Mobility service provision system.

4. A mobility service providing system according to any one of claims 1 to 3, The vehicle-mounted device further includes a unique information acquisition unit (11: S110) configured to acquire unique information necessary for understanding the content of the basic information described in a format unique to the vehicle model of the vehicle in which the vehicle-mounted device is installed, when the vehicle-mounted device is initialized. Mobility service provision system.

5. A mobility service providing system according to any one of claims 1 to 3, the first acquisition unit is configured to operate at least when the in-vehicle device is first started up; The second acquisition unit is configured to operate every time the in-vehicle device is started up. Mobility service provision system.

6. A mobility service providing system according to any one of claims 1 to 3, The apparatus further includes a user setting unit (31: S430 to S450) configured to set the abstraction information by input from an external device. Mobility service provision system.

7. An in-vehicle device (10) that acquires from a server and executes an application program for executing a process using a function provided in the vehicle, a first acquisition unit (21, 11: S130) configured to acquire basic information that is information related to functions of a vehicle that is a vehicle that mounts the on-board device; a second acquisition unit (22, S140) configured to acquire additional information that is information about a detachable peripheral device attached to the vehicle; an abstraction unit (23, 11: S150, S220) configured to convert the basic information and the additional information into abstract information that is information in a common format independent of the vehicle and the peripheral devices; a providing unit (25, 43, 11: S160, S230) configured to provide the abstraction information to the server as information for determining whether or not the application program can be downloaded; An in-vehicle device comprising:

8. 1. An application usability determination method for determining whether an application program for executing a process using a function of a vehicle can be used on an in-vehicle device mounted on the vehicle, comprising: an acquisition step (S130 to S140, S210) of acquiring basic information, which is information about functions of a vehicle equipped with the on-board device, and additional information, which is information about detachable peripheral devices attached to the on-board vehicle; an abstraction step (S150, S220) of converting the basic information and the additional information into abstract information that is information in a common format independent of the vehicle and the peripheral devices; a determination step (S520 to S540) of determining whether the application program can be used on the on-board device by comparing hardware requirements necessary for executing the designated application program with the abstraction information held by the on-board device that executes the application program; The method for determining whether an application is usable or not comprises:

Images