API RATING SYSTEM AND PROGRAM

Abstract

An information acquisition unit (S410 to S420) captures an API access log, which represents the usage status of an API according to a request from an application installed in a vehicle. A sales-related index generation unit (S480 to S490) generates a sales-related index according to a log aggregation value. This index is the result of aggregating the API access log for each vehicle classification, obtained by classifying the vehicle based on vehicle sales data, and for each API type. The sales-related index is an API index that indicates the degree of influence of the API on the application and a vehicle user. An output unit (S510) outputs the sales-related index.

Description

CROSS-REFERENCE TO RELATED REGISTRATION

[0001] This application is based on Japanese patent application No. 2023-122458, filed on July 27, 2023, the full disclosure of which is hereby incorporated by reference. TECHNICAL AREA

[0002] The present disclosure relates to a technology for API evaluation. STATE OF THE ART

[0003] Patent document 1, described below, discloses a technology for extracting an occurrence part of incompatibilities for an application platform and for providing a method for fixing the incompatibilities. STATE-OF-THE-ART LITERATURE PATENT LITERATURE

[0004] Patent document 1: JP 2013 - 164 879 A BRIEF SUMMARY OF THE INVENTION

[0005] A vehicle function is provided via an application programming interface (hereinafter referred to as API). The API is updated (upgraded) accordingly to accommodate configuration changes of sensors, actuators, ECUs, and the like for implementing functions, to support an increase in the number of supported OEM and vehicle model variants, and to improve usability. It is desirable that the updated or upgraded APIs are backward compatible so that they can be used without modifications to existing applications.

[0006] However, maintaining backward compatibility across all APIs is very time-consuming, so it is necessary to carefully select APIs that ensure backward compatibility and to develop the APIs efficiently.

[0007] With conventional technology, information is only obtained to correct the incompatibility, and it is not possible to determine whether maintaining compatibility is actually necessary.

[0008] One aspect of the present disclosure provides a technology for API evaluation to maintain backward compatibility.

[0009] According to one aspect of the present disclosure, an API rating system comprises an information acquisition unit, a sales-related index generation unit, and an output unit. The information acquisition unit captures an application programming interface (API) access log, which represents a usage state of an API that is an interface for providing a vehicle function in response to a request from an application installed in a vehicle. The sales-related index generation unit generates a sales-related index according to a log aggregation value, which is the result of aggregating the API access log for each vehicle classification—obtained by classifying the vehicle based on vehicle sales data in relation to sales of the vehicle—and for each API type.The sales-related index is an application programming interface (API) index that indicates the degree of influence of the API on the application and a vehicle user. The output unit displays the sales-related index.

[0010] According to such a configuration, it is possible to choose the API that should be prioritized to maintain backward compatibility using the generated sales-related index and to develop the API efficiently.

[0011] According to one aspect of the present disclosure, an API evaluation system comprises an access log store, a sales data store, an information acquisition unit, a sales-related index generation unit, and an output unit. The access log store collects, from a vehicle, and stores an application programming interface (API) access log, which represents a usage state of an API that is an interface for providing a vehicle function in response to a request from an application installed in the vehicle. The sales data store accumulates vehicle sales data relating to vehicle sales. The information acquisition unit retrieves the API access log and the vehicle sales data from the access log store and the sales data store.The sales-related index generation unit generates a sales-related index based on a protocol aggregation value. This value is the result of aggregating the application programming interface (API) access protocol for each vehicle classification, obtained by classifying the vehicle based on vehicle sales data, and for each API type. The sales-related index is an API index that indicates the degree of influence the API has on the application and a vehicle user. The output unit prints the sales-related index.

[0012] According to such a configuration, it is possible to choose the API that should be prioritized to maintain backward compatibility using the generated sales-related index and to develop the API efficiently.

[0013] According to one aspect of the present disclosure, a program causes a computer to act as an information acquisition unit, a sales-related index generation unit, and an output unit.

[0014] Running such a program achieves the same effect as the API rating system described above. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows a block diagram illustrating a hardware configuration of an API rating system. Fig. Figure 2 shows a block diagram illustrating a functional configuration of an API rating system. Fig. Figure 3 shows an explanatory illustration to demonstrate the contents of an application operating log. Fig. Figure 4 shows a flowchart of an application log management process. Fig. Figure 5 shows an explanatory figure to illustrate the contents of an API access protocol. Fig. Figure 6 shows a flowchart of an API protocol management process. Fig. Figure 7 shows an explanatory figure to illustrate the contents of application information managed by an application store. Fig. Figure 8 shows an explanatory figure to illustrate the contents of information that represents the impact on security protection assets managed by the application store. Fig. Figure 9 shows an explanatory figure to illustrate an API access log with additional information accumulated in an application store. Fig. Figure 10 shows an explanatory figure to illustrate the contents of vehicle sales data managed by a vehicle sales database. Fig. Figure 11 shows a flowchart of an Apl index calculation process. Fig. Figure 12 shows an explanatory diagram of a basic API index. Fig. Figure 13 shows an explanatory figure to illustrate a procedure for aggregating API access logs, which is used in a calculation of API indices and takes into account an application usage situation. Fig. Figure 14 shows an explanatory figure illustrating an example of calculating an API index taking into account the number of application downloads. Fig. Figure 15 shows an explanatory figure to illustrate an example of calculating an API index taking into account an application evaluation. Fig. Figure 16 shows an explanatory figure illustrating a procedure for aggregating API access logs, which is used in calculating the API index and takes vehicle sales data into account. Fig. Figure 17 shows an explanatory figure to illustrate an example of a calculation of the API index taking into account vehicle sales data. Fig. Figure 18 shows an explanatory figure illustrating an example of calculating the API index, taking into account the impact on the security asset. DESCRIPTION OF EXECUTION FORMS

[0015] An embodiment of the present disclosure is described below with reference to the drawings. (1. Configuration)

[0016] As in Fig. As shown in Figure 1, an API rating system 1 of the present embodiment comprises an in-vehicle system 100 attached to a vehicle, an application store 200, a vehicle sales database 300, and a terminal device 400. DB is an abbreviation for database. The vehicle may have an automated driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle with an internal combustion engine and an electric motor as its drive source. The vehicle is not limited to vehicles with the automated driving function or hybrid vehicles, but may also be a vehicle with only a manual driving function, or a vehicle with only an internal combustion engine or only an electric motor as its drive source. Hereinafter, the vehicle equipped with the in-vehicle system 100 is simply referred to as a vehicle.

[0017] The vehicle-internal system 100 comprises an electronic control unit (hereinafter referred to as ECU) 2, several ECUs 3, several ECUs 4, a vehicle external communication device 5 and a vehicle internal communication network 6. ECU stands for Electronic Control Unit.

[0018] The ECU 2 controls the multiple ECUs 3 to achieve coordinated control of the entire vehicle.

[0019] The ECU 3 is dedicated to each domain, which is divided according to functions within the vehicle, and primarily controls several ECUs 4 located within that domain. Each ECU 3 is connected to a subordinate ECU 4 via an individually located lower-layer network. A Controller Area Network (hereinafter referred to as CAN) is used as the lower-layer network. CAN is a registered trademark. The ECU 3 has the function of centrally managing access rights for the subordinate ECU 4, authenticating users, and similar tasks. The domain might include, for example, a powertrain, a body, a chassis, a cockpit, and so on.

[0020] The ECUs 4, which are connected to the ECU 3 belonging to the powertrain domain, include, for example, an ECU 4 that controls an internal combustion engine, an ECU 4 that controls a motor, and an ECU 4 that controls a battery.

[0021] The ECUs 4, which are connected to the ECU 3 belonging to the body domain, include, for example, an ECU 4 that controls an air conditioning system and an ECU 4 that controls the doors.

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

[0023] The ECUs 4, which are connected to ECU 3, belonging to the cockpit domain, include, for example, an ECU 4 that controls the display of counters and navigation, and an ECU 4 that controls HMI devices operated by vehicle occupants. HMI stands for Human Machine Interface.

[0024] The vehicle external communication device 5 performs data communication with vehicle external devices such as the application store 200 via a wide-area wireless communication network.

[0025] The vehicle's internal communication network 6 comprises a flexible data rate CAN (hereinafter referred to as CAN FD) and Ethernet. Ethernet is a registered trademark. The CAN FD can connect the ECU 2 to any ECU 3 and the vehicle's external communication device 5 via a bus. The Ethernet can connect the ECU 2, each ECU 3, and the vehicle's external communication device 5 individually.

[0026] The ECU 2 is an electronic control unit that primarily contains a microcomputer with a CPU 2a, a ROM 2b, a RAM 2c, and similar components. Various functions of the microcomputer are implemented by the CPU 2a, which executes programs stored on a non-volatile, physical storage medium. In this example, the ROM 2b corresponds to a non-volatile, physical storage medium for storing a program. Furthermore, executing this program triggers a procedure corresponding to the program. It should be noted that some or all of the functions performed by the CPU 2a can be implemented by a hardware circuit, such as one or more integrated circuits (ICs). Additionally, the number of microcomputers comprising the ECU 2 can be one or more.

[0027] The ECU 3, the ECU 4, and the vehicle external communication device 5 are all electronic control units that primarily contain a microcomputer equipped with a CPU, ROM, RAM, and the like, similar to the ECU 2. Furthermore, the number of microcomputers comprising the ECU 3, the ECU 4, and the vehicle external communication device 5 can be one or more.

[0028] Unless otherwise specified, the ECU 2, the ECU 3, the ECU 4 and the vehicle external communication device 5 are collectively referred to as in-vehicle devices 2 to 5.

[0029] The Application Store 200 and the Vehicle Sales DB 300 are both electronic control units (ECUs) that primarily contain a microcomputer equipped with a CPU, ROM, RAM, and similar components. The microcomputer's various functions are implemented by the CPU executing programs stored on a non-volatile physical storage medium. In this example, the ROM corresponds to the non-volatile physical storage medium where the programs are stored. Furthermore, executing this program triggers a procedure corresponding to the program. It should be noted that some or all of the functions performed by the CPU can be implemented by a hardware circuit, such as one or more integrated circuits (ICs). Additionally, the number of microcomputers comprising the ECU can be one or more.

[0030] The Application Store 200 is a cloud server that can communicate with at least the in-vehicle system 100 and the terminal device 400 and manages the service applications (hereinafter also referred to as apps) run by the in-vehicle system 100. The Application Store 200 sells applications to be installed on the in-vehicle system 100 and collects, from the in-vehicle system 100 where the application is installed, an application operation log indicating the operational status of the application and an API access log indicating the status of any application access to the API. Furthermore, the Application Store 200 generates application usage fee aggregate data, API usage fee aggregate data, and similar data based on the application operation log and the API access log.Application usage fee collection data is data used to collect application usage fees from an application purchaser (hereinafter referred to as a user). API usage fee collection data is data used to collect API usage fees from application developers or operators (hereinafter referred to as service providers).

[0031] The vehicle sales database 300 is a cloud server that is capable of communicating with at least the terminal device 400, collecting data relating to vehicle sales, and providing the collected data upon request from the terminal device 400 or the like.

[0032] The Terminal Device 400 is an electronic control unit consisting primarily of a microcomputer with a CPU 401, a ROM 402, a RAM 403, and similar components. Various functions of the microcomputer are implemented by instructing the CPU 401 to execute programs stored on a non-volatile physical storage medium. In this example, the ROM 402 corresponds to the non-volatile physical storage medium on which the program is stored. Furthermore, executing this program triggers a procedure corresponding to the program. It should be noted that some or all of the functions performed by the CPU 401 can be implemented by a hardware circuit, such as one or more integrated circuits (ICs). Additionally, the number of microcomputers comprising the Terminal Device 400 can be one or more.

[0033] The terminal device 400 further includes a communication unit 404 and an input / output unit 405. The communication unit 404 performs data communication with the application store 200, the vehicle sales database 300, and the like via a wide-area wireless communication network. The input / output unit 405 comprises various input devices for receiving input from an operator of the terminal device 400 and various output devices for displaying results of processes and the like from the terminal device 400 to the operator. The input device may include a keyboard, a pointing device, a touch panel, a microphone, and the like. The output device may include a display, a speaker, a printer, or the like.

[0034] Terminal device 400 performs at least one index calculation process. This process gathers information from application store 200 and vehicle sales database 300 to calculate the API index. The API index is used to evaluate each API, determine a prioritized API, and decide whether to maintain backward compatibility when updating the API installed in the vehicle. The index calculation process is described in more detail below. (2. Functional Configuration)

[0035] The following describes various functions of the API rating system 1. (2-1. In-vehicle system)

[0036] As in Fig. As shown in Figure 2, the in-vehicle system 100 has functions as an equipment device management unit 10, a vehicle function module group 20, an API gateway 30, and a service provisioning unit 40. The functions provided by the in-vehicle system 100 are distributed among the in-vehicle devices 2 to 5 belonging to the in-vehicle system 100. (2-1-1. Equipment Device Management Unit)

[0037] The Equipment Device Management Unit 10 manages several types of vehicle equipment devices that are installed in the vehicle.

[0038] The equipment management unit 10 operates the vehicle equipment according to the operating instructions from the vehicle function module group 20 and communicates the operating result to the vehicle function module group. The vehicle equipment can include actuators, sensors, storage devices, HMI equipment, and the like. For example, if the vehicle equipment is an actuator, the operating result can indicate whether the actuator operation was completed normally or abnormally. If the vehicle equipment is a sensor, the operating result can show data acquired by the sensor. If the vehicle equipment is a storage device, the reported result can include data read from the storage device.

[0039] The equipment device management unit 10 can be configured to operate the vehicle equipment device in accordance with an operating instruction issued by the vehicle function module group 20, as well as to automatically detect the status of the vehicle equipment device and transmit the notification to the vehicle function module group. (2-1-2. Vehicle Function Module Group)

[0040] The vehicle function module group 20 is a collection of vehicle function modules, which are modules that execute processes to implement various functions using the vehicle equipment. The functions of the vehicle function modules are provided via an application programming interface (hereinafter referred to as API) 31. The vehicle function modules can be classified according to vehicle operation, which can be easily requested by the service provisioning unit 40, for example, into condition detection, motion system equipment control, HMI system equipment control (HMI: Human Machine Interface), body system equipment control, and the like.

[0041] Condition detection corresponds to an operation for recognizing the situation of the vehicle itself and its environment, such as the positions of the vehicle and pedestrians. A control target of the vehicle function module classified as condition detection is, for example, a vehicle equipment device (e.g., a camera, a millimeter-wave sensor, or the like) that is part of the detection control system.

[0042] The motion system equipment device control corresponds to operations such as turning, driving, and stopping the vehicle. A control target of the vehicle function module classified as a motion system equipment device control is, for example, a vehicle equipment device (e.g., an actuator) that is part of the brake and steering control systems.

[0043] The HMI system equipment control responds to vehicle operations related to the display of information to the user. The vehicle function module classified as the HMI system equipment control is, for example, a vehicle equipment device (such as a display, a speaker, or the like) that is part of the display and audio control system.

[0044] The body system equipment device control corresponds to the vehicle's body system operation in relation to the vehicle environment. For example, a control target of the vehicle function module classified as the body system equipment device control is a vehicle equipment device (e.g., an actuator) that is part of the lighting control, HVAC control, and seat control. HVAC is an abbreviation for Heating, Ventilation, and Air Conditioning, collectively referred to as an air conditioning system. (2-1-3. Service Deployment Unit)

[0045] The service provisioning unit 40 runs an application 41, which was downloaded and installed from the application store 200, to perform various functions, such as information gathering, theft prevention, and remote control using the vehicle equipment device managed by the equipment device management unit 10. There can be multiple applications 41.

[0046] Basically, the application 41 uses API 31 to access the vehicle function modules belonging to the vehicle function module group 20 via API gateway 30 in order to use the functions of various vehicle equipment devices and to implement the intended services.

[0047] The user can purchase application 41 from application store 200. The application purchased from application store 200 is installed on any of the vehicle's internal devices 2 to 5. Furthermore, the user can update or delete applications 41 installed on the vehicle's internal devices 2 to 5 as needed.

[0048] It should be noted that in the case of an application that serves to provide a service that collects vehicle information from many vehicles and analyzes vehicle behavior, driver driving operations and the like, the service provider who is the provider of application 41 may install application 41 with the permission of the vehicle user in any of the vehicle's internal devices 2 to 5.

[0049] The application 41 can be installed not only in any of the vehicle internal devices 2 to 5, but also in an external device that is remotely connected to the vehicle internal communication network 6 via the vehicle external communication device 5.

[0050] The service provisioning unit 40 contains an application management unit 42 and an application operations log database 43.

[0051] The application management unit 42 generates an application operating log based on the results of monitoring the operating status of the application 41 installed in the vehicle, stores this log in the application operating log database 43, and executes a process to upload the accumulated application operating log to the application store 200 in a suitable manner. The application management unit 42 and the application operating log database 43 can be distributed and placed in all vehicle internal devices 2 to 5 where the application 41 can be installed, or they can be integrated and placed in any one of the vehicle internal devices 2 to 5.

[0052] The application operation log accumulated in application operation log DB 43 is stored in conjunction with an "application ID", as described in Fig. Figure 3 illustrates this. The "Application ID" is an identifier for application 41, provided by application store 200. The application operation log is classified into basic data and processed data. The basic data is updated as needed, according to the operational status of application 41. The processed data is generated when the application operation log is uploaded to application store 200. Only basic data can also be stored in the application operation log database 43.

[0053] The application identified by the "application ID" is referred to below as the target application.

[0054] The basic data includes "Number of Application Executions," "Application Execution Time," "Monitoring Start Time," and "Last Execution Time." The "Number of Application Executions" is the number of times the target application has been activated in the vehicle's internal system 100. The "Application Execution Time" is the time the target application is running in the vehicle's internal system 100. The "Monitoring Start Time" is the time at which the counting of the "Number of Application Executions" and the integration of the "Application Execution Times" for the target application begin. The "Last Execution Time" indicates the time the target application was last executed.It should be noted that the "Number of application executions" is set to a value indicating that the target application is inactive if the elapsed time between the time specified by the "Time of last execution" and the current time is longer than a preset allowable inactivity time.

[0055] The processed data includes "number of application executions per unit of time" and "application execution times per unit of time." The "number of application executions per unit of time" is calculated in accordance with the "number of application executions" and a period (hereinafter referred to as the monitoring period) specified in the base data, from the time indicated by the "monitoring start time" until the upload execution time. The "application execution time per unit of time" is calculated in accordance with the "application execution time" and the monitoring period in the base data. The time unit can be, for example, 24 hours, i.e., one day. The processed data is standardized to facilitate integration when aggregating the "number of application executions" and the "application execution times" uploaded by numerous in-vehicle systems to application store 100.

[0056] The following is the application log management process executed by application management unit 42, with reference to the one in Fig. The flowchart shown in section 4 is described.

[0057] The application log management process is executed repeatedly when the vehicle's internal system 100 is activated.

[0058] In S110, application management unit 42 determines whether application 41, belonging to service delivery unit 40, has been activated. If application 41 has been activated, the process proceeds to S120. If application 41 has not been activated, the process proceeds to S140.

[0059] In S120, the application management unit 42 captures time information indicating the current time (i.e., the time at which application 41 was activated).

[0060] Subsequently, in S130, the application management unit 42 updates the "Number of Application Executions" and the "Time of Last Execution" of the activated application 41 in the application operation logs stored in the application operation log DB 43 and terminates the process. Specifically, the application management unit 42 updates the "Number of Application Executions" by incrementing it by 1 and updates the "Time of Last Execution" with the time information captured in S120.

[0061] In S140, the application management unit 42 determines whether application 41, belonging to the service delivery unit 40, has been stopped. If application 41 has been stopped, the process proceeds to S150. If application 41 has not been stopped, the process proceeds to S170.

[0062] In S150, the application management unit 42 captures time information indicating the current time (i.e., the time at which application 41 was stopped).

[0063] Subsequently, in S160, the application management unit 42 updates the "application execution time" of the application operation log stored in application operation log DB 43 for the stopped application 41 and terminates the process. Specifically, the application management unit 42 performs an update by adding the time from the activation to the stop of application 41 to the "application execution time" stored in application operation log DB 43, calculating the time according to the time information captured in S120 and S150.

[0064] In S170, application management unit 42 determines whether the protocol termination condition of the application operations log is met. If the protocol termination condition is met, the process proceeds to S180. If the protocol termination condition is not met, the process terminates. The protocol termination condition of the application operations log can be that a specific period of time (e.g., a day, a week, or a month) has elapsed, that it is a specific date, or that an upload instruction has been received from application store 200.

[0065] In S180, the application management unit 42 captures time information representing the current time (i.e., the time at which the application operations log is uploaded).

[0066] Subsequently, in S190, the application management unit 42 generates the processed data according to the application operations log base data stored in the application operations log DB 43. Specifically, the monitoring time is calculated from the time specified by the "Monitoring Start Time" in the base data to the current time, which is specified by the time information captured in S180. Then, the "Number of Application Executions per Unit of Time" is calculated by dividing the "Number of Application Executions" by the monitoring time, and the "Application Execution Time per Unit of Time" is calculated by dividing the "Application Execution Time" by the monitoring time. Finally, the inactivity time is calculated from the time specified by the "Last Execution Time" to the current time, which is specified by the time information captured in S180.Subsequently, if the calculated inactivity time exceeds the allowed time, values ​​indicating inactivity are set in the "Number of application executions" and the "Number of application executions per unit of time" of the basic data.

[0067] Subsequently, in step S200, the application management unit 42 transmits (i.e., uploads) the application operations log, along with the time information captured in step S180, to application store 200. The application operations log to be uploaded can include all basic and processed data, only the basic data, or only the processed data. If only the basic data is uploaded, application store 200 can generate the processed data.

[0068] Subsequently, in S210, the application management unit 42 resets the "Number of Application Executions," the "Application Execution Time," and the "Monitoring Start Time" of the application operations log base data stored in application operations log DB 43 and terminates the process. Specifically, the "Number of Application Executions" and the "Application Execution Time" are set to zero, and the "Monitoring Start Time" is set to the time information recorded in S180.

[0069] The above describes the case in which the upload timing of the application operation protocol is the same for all applications 41. However, the upload timing can be different for each application 41. (2-1-4. API Gateway)

[0070] As in Fig. As shown in Figure 2, the API gateway 30 provides an interface that connects the applications 41, as well as an interface that connects the application 41 and the hardware. The API gateway 30 includes an access controller 31, an API management unit 32, and an API access protocol database 33.

[0071] When the access controller 31 receives an API access request (hereinafter referred to as an API call) from the application 41, it determines whether the API call can be accepted from a formal perspective, such as with regard to the request format and the caller's access authorization. If the access controller 31 determines that the API call can be accepted, it forwards the API call to the vehicle function module group 20. More precisely, the API call is transmitted to the vehicle devices 2 to 5, which have the vehicle function module that implements the process based on the API call. Furthermore, the access controller 31 transmits the response (hereinafter referred to as the API response) to the API call, received from the vehicle function module group 20, to the calling application 41. If the access controller 31 determines that the API call cannot be accepted, it discards the API call.In this case, the calling source application 41 can be notified of the aborted API call.

[0072] The API management unit 32 monitors the operation of the access controller 31, generates an API access log, and executes a process to accumulate the generated API access log in the API access log database 33. Furthermore, the API management unit 32 executes a process to upload the API access logs accumulated in the API access log database 33 to the application store 200 in a suitable manner.

[0073] The API access log can use information recorded for billing purposes for the call source application 41 that made the API call.

[0074] As in Fig. As shown in Figure 5, the API access logs stored in the API access log database 33 are classified and stored for each “API deployment application ID”, each “API ID”, and each “call source application ID”.

[0075] The "API Deployment Application ID" is the identifier of the API deployment application. The API deployment application is a vehicle function module that provides an API. Because the same API can be provided by multiple API deployment applications, the API deployment application to which the used API belongs is identified by its "API Deployment Application ID." For example, if the same API is provided by multiple API deployment applications, the API belonging to the application with the lowest communication costs is selected. The "API ID" is an identifier of the API. The "Call Source Application ID" is an identifier of the call source application, i.e., the application that made the API call.

[0076] The API access log contains information such as the "number of API calls", the "number of completed API executions", the "number of unnecessary API executions", the "number of abnormal API executions", and the "amount of API communication data".

[0077] The "Number of API calls" is the number of times the API call was made. The "Number of completed API executions" is the number of times the API call completed normally and the requested operation was completed. The "Number of unnecessary API executions" is the number of times the API call completed normally, but the requested operation had already been executed, and the operation was aborted. For example, if a request to open a window is received, but the window is already open, this count is taken. The "Number of abnormal API executions" is the number of times the API call did not complete normally, or the number of times the API call completed normally, but the requested operation was not achieved.The “API data communication set” is the integrated value of the amount of data captured by the call source application 41 via the API call.

[0078] In other words, the API access log records which application used which API, how often it was used, and what the result of the usage was.

[0079] The following is the API protocol management process executed by API Management Unit 32, with reference to the [document / document / etc.]. Fig. The flowchart shown in section 6 is described.

[0080] The log management process is executed repeatedly when the vehicle's internal system 100 is activated.

[0081] In S310, the API management unit 32 determines whether the API call has been accepted by the access controller 31. If it has been accepted, the process proceeds to S320. If it has not been accepted, the process proceeds to S330. Note that the API call must contain at least the following information: "API Deployment Application ID", "API ID", and "Call Source Application ID".

[0082] In S320, the API management unit 32 updates the "Number of API calls" in the API access log, which is stored in the API access log DB 33, for the API that was called and then terminates the process. Specifically, the value of the "Number of API calls" is incremented by one.

[0083] In S330, the API management unit 32 determines whether the API response has been transmitted by the access controller 31. If the API response has been transmitted, the process proceeds to S340. If the API response has not been transmitted, the process proceeds to S350.

[0084] In S340, API Management Unit 32 updates the API access log stored in API Access Log DB 33 for the API to which the API response was sent, according to the content of the API response, and terminates the process. Specifically, if the API response indicates that the process completed normally based on the API call, API Management Unit 32 updates the "Number of Completed API Executions." If the API response indicates that the process did not complete normally based on the API call, the "Number of Abnormal API Executions" is updated. Furthermore, even if the process completed normally based on the API call, if the requested operation is unnecessary, the "Number of Unnecessary API Executions" is updated. Additionally, if data communication is performed by the process based on the API call, the "Amount of API Communication Data" is updated.

[0085] In S350, API Management Unit 32 determines whether the protocol termination condition of the API access protocol is met. If the protocol termination condition is met, the process proceeds to S360. If the protocol termination condition is not met, the process terminates. The protocol termination conditions of the API access protocol can be identical or different from the protocol termination conditions of the application operations protocol.

[0086] In S360, API Management Unit 32 captures vehicle information, including the vehicle type and the destination country. The destination country represents the vehicle's sales region. Vehicle information is captured data stored in an information source (e.g., a body type ECU). This information can be captured via API or through a method other than API. It can be captured from the information source each time the vehicle is activated or only once, and stored in API Access Log DB 33 or similar, for subsequent capture and retrieval.

[0087] Subsequently, in S370, the API management unit 32 captures time information indicating the current time (i.e., the time at which the API access log is uploaded).

[0088] Subsequently, in S380, the API management unit 32 transmits data to application store 200 (i.e., uploads it). The transmitted data is obtained by adding the vehicle information captured in S360 and the time information captured in S370 to the API access log stored in the API access log DB 33.

[0089] Subsequently, in S390, the API management unit 32 resets the API access log and terminates the process. In the reset API access log, the values ​​of all elements are set to zero. (2-2. Application Store)

[0090] As in Fig. As shown in Figure 2, the application store 200 contains an application delivery unit 51, a log acquisition unit 52, an information DB 53 and a log DB 54.

[0091] The application delivery unit 51 downloads the application 41, stored in the information database 53, to the vehicle's internal system 100 or the like in response to a request from the user or service provider. The application delivery unit 51 accumulates the aggregation value, which is obtained by aggregating the number of downloads of each application 41 for each application ID in the information database 53, as part of the application information.

[0092] In addition to application 41 and application information, information database 53 stores API security protection asset data.

[0093] As in Fig. As shown in Figure 7, the application information is classified by "Application ID" and includes elements such as "Number of downloads", "Total application runtime", "Application rating" and "Number of API uses".

[0094] The "Number of Downloads" provides a cumulative value that counts the number of downloads of the target application, which is application 41 identified by the "Application ID," as well as the "Number of Active Applications," which represents the number of applications that are essentially running. The "Number of Active Applications" is a log aggregation value that aggregates the number of target applications that are not shown as inactive in the "Number of Application Runs" or the "Number of Application Runs per Unit of Time" in the application operations log. That is, the cumulative value of the "Number of Downloads" is updated each time application 41 is downloaded, and the "Number of Active Applications" is updated each time the application operations log is uploaded.

[0095] The "Total Application Execution Time" is a log aggregation value that aggregates the "Application Execution Time" from the application operations log for the target application. This means that the "Total Application Execution Time" is updated each time the application operations log is uploaded.

[0096] The "application rating" is information that indicates how users rate an application. For example, the "application rating" is a result obtained by aggregating application ratings collected on application rating websites or similar platforms. That is, the "application rating" is updated when the aggregated rating results are recorded.

[0097] The "Number of API Uses" is information that indicates the number of API calls for each API of all APIs used in the target application. The "Number of API Uses" is not the number of actual API uses, but rather the number of times the target application makes an API call, and is applied by the service provider that registers the target application in application store 200.

[0098] The API security protection asset data is data that links the "API ID" and the "security protection asset data", as described in Fig. Figure 8 illustrates this. The "Security Protection Asset Data" is defined according to SFOP, an attribute that is defined as a Security Protection Asset. The "S" is an abbreviation for "Safety" and represents APIs that provide functions impacting safety. The "F" is an abbreviation for "Financial" and represents APIs that provide functions impacting corporate or personal assets. The "O" is an abbreviation for "Operational" and represents APIs that provide functions impacting the vehicle's operational performance. The "P" is an abbreviation for "Privacy" and represents APIs that provide functions impacting privacy information. The API Security Protection Asset Data is generated by the manufacturer of the API deployment application or similar entity. (See table of...) Fig. The 8 circles indicate that this effect occurs.

[0099] The log acquisition unit 52 sequentially accumulates the application operation log and the API access log, which are uploaded by the vehicle's internal system 100, in the log database 54 and updates the "number of downloads" and the "total application execution time" of the data in Fig. The application information shown in Figure 7 is based on the application operation log. For the application operation log, both the base data and the processed data can be accumulated, or only the processed data can be accumulated.

[0100] Furthermore, as in Fig. Figure 9 shows the “API access log” together with the “upload time”, the “vehicle type”, and the “destination country”, which are uploaded by the vehicle's internal system 100 along with the “API access log” and stored in the log database 54. The “API access log” in Fig. 9 contains the entire table of Fig. 5. (2-3. Vehicle Sales Database)

[0101] The vehicle sales database 300 is a cloud server that accumulates vehicle sales data and makes the accumulated vehicle sales data available in response to a request from the terminal device 400 or the like.

[0102] As in Fig. As shown in Figure 10, the vehicle sales data accumulated in the vehicle sales database 300 includes items such as "Total number of units sold" and "Time since the start of mass production" for each "Vehicle Classification". In this embodiment, the "Vehicle Classification" is categorized by "Vehicle type" and "Country of destination". (2-4th terminal device)

[0103] The 400 terminal device is operated by an API administrator who manages the API and runs at least one API index generation process. The API index generation process is used to create an API index, which is then used to select APIs that should be prioritized to maintain backward compatibility when many APIs are updated. Maintaining backward compatibility means that the existing application used before the update can still be used by the updated API.

[0104] The APL index generation process performed by terminal device 400 is described below with reference to the [document / reference] in Fig. The flowchart shown in section 11 describes the process. The valuation value generation process begins when terminal device 400 performs an operation to activate the process.

[0105] In S410, the terminal device 400 captures the application operating log and the API access log from the application store 200.

[0106] Subsequently, in S420, the terminal device 400 records the vehicle sales data from the vehicle sales database 300.

[0107] Subsequently, in S430, the terminal device calculates 400, as in Fig. Figure 12 shows the "first total number of API executions" and the "first total API fee amount" by aggregating the "number of API calls" and the "API fee amount" in the API access logs for each "API ID". The aggregation result and the calculation result can be stored in RAM 403.

[0108] The "API fee amount" is calculated, for example, by aggregating the "number of API calls," the "number of API execution completions," the "number of unnecessary API executions," the "number of abnormal API executions," and the "API communication data volume" from the API access log for each "API ID." Each aggregated value is then weighted using predefined weighting factors and summed. It should be noted that information on the "total API fee amount" can be obtained from an external server that determines the fee amount for each API based on the API access log.

[0109] Subsequently, in step S440, Terminal Device 400 calculates the API index based on the aggregation result from S430. Specifically, Terminal Device 400 uses the "first total number of API executions" and the "first total API charge amount" as API indices and also calculates the "first total API usage rate" and the "first total API execution rate".

[0110] The "Total API Usage Rate" is the number of API uses per application and is calculated using an initial equation based on the "Number of Downloads" contained in the application information. However, the cumulative value is used for the "Number of Downloads". (First equation) "First Total API Usage Rate"="First Total Number of API Uses"""Number of Downloads"

[0111] The "Total API Execution Rate" is the number of API executions per average application execution time and is calculated using a second equation with a "Total Application Execution Time" and the "Number of Downloads" contained in the application information. However, the cumulative value is used for the "Number of Downloads". (Second equation) "First Total API Execution Rate"="First Total Number of API Uses""Total Number of Application Executions" / "Number of Downloads"

[0112] The API index calculated in this way simply rates APIs with a higher number of executions, higher fees, or higher usage and execution rates higher, and such APIs receive a higher priority when the APIs are updated to maintain backward compatibility.

[0113] Then, in S450, as in Fig. As shown in Figure 13, Terminal Device 400 aggregates the "Number of API Calls" for each "Application ID" and "API ID" in the API access log. Furthermore, the first and second equations calculate the "API Usage Rate" and "API Execution Rate" for each "Application ID" and "API ID," using the aggregated value of the "Number of API Calls" in this step instead of the "Total Number of API Executions." The aggregation result and the computation result can be stored in RAM 403.

[0114] Subsequently, in step S460, the terminal device 400 calculates the "second overall API usage rate" and the "second overall API execution rate" based on the "API usage rate" and "API execution rate" calculated in step S450 for each "application ID" and "API ID," as well as the "number of downloads" specified in the application information. The "second overall API usage rate" and the "second overall API execution rate" are API indices that take the "number of downloads" into account.

[0115] In particular, as in Fig. Figure 14 shows that weighting factors are assigned according to the "number of downloads" such that a larger "number of downloads" corresponds to a higher value. Here, the number of downloads is classified into five levels: 0 to 500, 501 to 1000, 1001 to 5000, 5001 to 10000, and 10001 to 10000, and assigned a weighting factor from 1 to 5. The classification of the number of downloads and the values ​​of the weighting factors (hereinafter referred to as "download-related information") can be preset or set as needed by an API administrator or similar entity operating Terminal Device 400. If the download-related information is preset, it may, for example, be obtained from the information database 53 of Application Store 200 or may have been previously stored in ROM 402. Subsequently, based on the table in Figure 14, the download-related information is determined. Fig. 13, which aggregates the “API usage rate” and “API execution rate” calculated in S450 for each “number of downloads” according to the “application ID”. Fig. Figure 14 shows an example where an “API ID” is aggregated. Here, a case with “API ID” = 1 is shown. That is, for all “API IDs”, the same aggregation table is used as in Fig. 14 generated. The aggregation table can be stored in RAM 403.

[0116] According to the aggregation table based on the "number of downloads", which is located in the upper part of Fig. As shown in Figure 14, a weighted summation is performed for both the "API usage rate" and the "API execution rate" using the "weighting factors," thereby calculating the "second API usage rate" and the "second overall API usage rate" for each "API ID." That is, the "second overall API usage rate" for "API ID = 1," as shown in the table at the bottom of Figure 14, is calculated as follows: Fig. As shown in 14, according to the table in the upper part of Fig. The second overall API execution rate (API-ID) of 1 is calculated using the expression 5×2+4×3+3×1+2×1+1×1. Similarly, the second overall API execution rate of API-ID=1 is calculated using the expression 5×10+4×20+3×5+2×2+1×2. The result of the calculation can be stored in RAM 403.

[0117] The API index calculated in this way assigns a high rating to frequently used APIs for applications downloaded to many vehicles and has a high priority for maintaining backward compatibility when updating APIs. It is assumed that "API-ID"=1 by <1> is shown. In a table in the lower part of Fig. 14 is the priority order <1> → <2> → <4> → <5> → <3> in the case of a "weighted sum of API usage rate". Furthermore, the priority order in the case of a "weighted sum of API execution rate" <2> → <1> → <4> → <5> → <3> .

[0118] Subsequently, in step S470, the terminal device 400 calculates the "second total number of API executions" based on the "API usage rate" and "API execution rate" calculated in S450 for each "application ID" and "API ID," as well as the "application score" specified in the application information. The "second total number of API executions" is an API index that incorporates the "application score."

[0119] In particular, as in Fig. Figure 15 shows the "application rating," whose value increases with higher ratings, and is used unchanged as the "weighting factor." Here, weighting factors from 1 to 5 are used. The "weighting factor" can be adjusted at any time by the API administrator or similar entity operating the 400 terminal device. Subsequently, with reference to Fig. 7, the aggregation value calculated in S450 of the “number of API calls” for each “application rating” is aggregated according to the “application ID”. Fig. Figure 15 shows an example where aggregation is performed for an “API ID”. Here, the case “API ID” = 1 is shown. That is, the same aggregation table is used for all “API IDs” as in Fig. 15 generated. The aggregation table can be stored in RAM 403.

[0120] According to the aggregation table based on the "Application Score," a weighted summation of the aggregation values ​​of "Number of API Calls" is performed using "weighting factors," thereby calculating the "second total number of API executions" for each "API ID." That is, the "second total number of API executions" in the case of "API ID" = 1, which is shown in the table below. Fig. As shown in 15, the expression 5×1000+4×5000+3×1000+2×200+1×100 according to the table above is used. Fig. 15 calculated. The calculation result can be stored in RAM 403.

[0121] The API indices calculated in this way rate APIs frequently used in applications with high user ratings higher, and such APIs are given a higher priority for maintaining backward compatibility when APIs are updated. In the case of the table in the bottom row of Fig. The priority order is 15. <1> → <4> → <2> → <3> → <5> .

[0122] Then, in S480, as in Fig. As shown in Figure 16, Terminal Device 400 aggregates the "Number of API Calls" and the "API Fee Amount" from the API access log for each "API ID" and each "Vehicle Classification" (i.e., "Vehicle Type" and "Country of Destination"). The aggregation result can be stored in RAM 403.

[0123] Subsequently, in S490, the Terminal Device 400 calculates the "Number of API Executions by Classification" and the "API Fee Amount by Classification" based on the "Number of API Calls" and the "API Fee Amount" calculated for each "API ID" and "Vehicle Classification" in S480, as well as the "Number of Units Sold" and the "Time Since Mass Production Start" specified in the vehicle sales data. The "Number of API Executions by Classification" and the "API Fee Amount by Classification" are API indices that incorporate vehicle sales data.

[0124] In particular, as in Fig. Figure 17 shows that a "first multiplication factor" is assigned according to the "time since the start of mass production," such that the longer the time, the smaller the value of the "first multiplication factor." In this case, the value is set to 1.5 if the period is less than five years, to 1 if the period is five years or more but less than ten years, and to 0 if the period is ten years or more. Information (hereafter referred to as "mass production period-related information") that specifies how the "first multiplication factor" is assigned can be preset or set as needed by the API administrator or the like who operates the Terminal Device 400. If the mass production period-related information is preset, for example, information stored in the Vehicle Sales DB 300 or the like can be captured or pre-stored in ROM 402.Subsequently, both the "API usage rate" and the "API fee amount," which are aggregated in S480, are multiplied by the "number of units sold" according to the "vehicle classification" and by the "first multiplication factor" according to the "time since the start of mass production." The "number of versions by classification" and the "fee amount by classification" are calculated for each classification that becomes the aggregation unit.

[0125] For example, in the case of “API-ID”=1, “Vehicle Type”=A and “Destination Country” = a, as shown in a table at the bottom of Fig. Figure 17 shows that the “number of units produced by classification” is calculated as follows. Specifically, it is based on the “total number of units sold” and the “time since the start of mass production” shown in the table of Fig. 10 are shown, which is in Fig. 16 shown “number of API calls” and the one in the table above. Fig. The value of the "first multiplication factor" shown in Figure 17 is calculated as 100 × 100,000 × 1.5. Similarly, the "API fee amount by classification" is calculated as 10,000 × 100,000 × 1.5. The result of the calculation can be stored in RAM 403.

[0126] The API index calculated in this way is frequently used in vehicle classifications where the number of units sold is high and the period since the start of mass production is short. Within the same vehicle classification, the value increases for APIs with higher fee amounts. This means that an API expected to be frequently used in the future receives a higher priority for maintaining backward compatibility when the API is updated. Conversely, if the period since the start of mass production exceeds a predetermined timeframe, a decline in API usage is expected due to vehicle scrapping or similar factors. Therefore, such cases are excluded from the evaluation by setting the "first multiplication factor" to zero.The aggregation results obtained by aggregating the "number of API executions by classification" and the "API fee amount by classification", calculated for each "API ID" as described above, can be used as the API index.

[0127] Subsequently, in S500, the terminal device 400 calculates the "third total number of API executions" and the "third total API charge amount", which are API indices that take the "security protection asset" into account.

[0128] In particular, as in Fig.Figure 18 shows the "second multiplication factor" assigned according to the classification of the "security protection asset." Here, S equals 10, F equals 5, O equals 3, and P equals 5. Information (hereafter referred to as protection asset-related information) specifying how to assign the "second multiplication factor" can be preset or set each time by an API administrator or similar operating the terminal device 400. If the protection asset-related information is preset, for example, the information stored in the application store 200's information database 53 can be retrieved, or the ROM 402 can store it in advance. Subsequently, the aggregation values ​​of the “number of API calls” and the “API fee amount” that were aggregated in S430, i.e. the “first total number of API executions” and the “first total API fee amount”, are multiplied by the “second multiplication factor”.Consequently, the "third total number of API executions" and the "third total API fee amount" are calculated for each "API ID," which serves as the aggregation unit. The result of the calculation can be stored in RAM 403.

[0129] The API index calculated in this way is widely used, has a high rating of the API which impacts the perspective of SFOP, and has a high priority for maintaining backward compatibility when the API is updated.

[0130] Subsequently, in S510, terminal device 400 outputs the calculated API index to a screen or similar display and terminates the process. It should be noted that terminal device 400 can also send the calculated API index to a server that accumulates the API index or to other terminal devices that use the API index.

[0131] The API administrator sets the priority for updates or upgrades that maintain backward compatibility for each API, either according to a single selected API index or by combining multiple API indexes. (3. Correspondence of concepts)

[0132] In the present embodiment, the "second total API usage rate," the "second total API execution rate," and the "second total number of API executions" correspond to an application-related index of the present disclosure. In the present embodiment, the "number of API executions by classification" and the "fee amount by classification" correspond to a sales-related index of the present disclosure. In the present embodiment, the "third total number of API executions" and the "third total API fee amount" correspond to a security-related index of the present disclosure. In the present embodiment, S410 to S420 correspond to an information acquisition unit of the present disclosure, S430 to S440 correspond to a basic index generation unit of the present disclosure, and S450 to S470 correspond to an application-related index generation unit of the present disclosure.In the present embodiment, S480 to S490 correspond to a sales-related index generation unit of the present disclosure, S500 corresponds to a security-related index generation unit of the present disclosure, and S510 corresponds to an output unit of the present disclosure. The application store 200 in the present embodiment corresponds to an access log memory of the present disclosure, and the vehicle sales database 300 corresponds to a sales data memory of the present disclosure. (4th effect)

[0133] According to the first embodiment described in more detail above, the following effects are achieved.

[0134] The API rating system calculates an API index based on the number and frequency of API uses, an API index that considers the application's usage status, an API index that considers vehicle sales data, and an API index that considers the impact on security assets. By referencing such an API index, it is possible to quantify the impact of each API on the application using it and on the user using the application. Based on the extent of this impact, it is easy to select the API that should prioritize maintaining backward compatibility.

[0135] This section describes a specific procedure for extracting APIs to be developed while maintaining backward compatibility using several types of API indices.

[0136] For example, APIs (hereinafter referred to as "first extraction APIs") are extracted from all APIs. The first extraction API has an API index value (i.e., "second overall API usage rate" or "second overall API execution rate") that reflects the application's usage status. This value corresponds to the top 50% of APIs. That is, the API frequently used in applications deployed in many vehicles is extracted.

[0137] Subsequently, APIs (hereinafter referred to as second extraction APIs) are extracted from the first extraction APIs. The second extraction API has an API index value (i.e., "number of API executions by classification" or "API fee amount by classification") that takes vehicle sales data into account. This value corresponds to the top 50% of the first extraction APIs. In other words, APIs expected to be used extensively in the future are extracted.

[0138] Subsequently, APIs (referred to below as "third extraction APIs") are extracted from all APIs. The third extraction API has an API index value (i.e., "third total number of API executions" or "third total API charge amount") that reflects its impact on security assets. This value corresponds to the top 20% of APIs. In other words, critical APIs are extracted from the perspective of security assets.

[0139] Finally, the merged APIs are determined based on the second extraction API and the third extraction API to ensure backward compatibility. (5. Other embodiments)

[0140] Although the embodiment of the present disclosure has been described above, the present disclosure is not limited to the embodiment described above, and various modifications are possible to realize the present disclosure.

[0141] (5a) In the embodiment above, the weighted sum of the aggregation values ​​of the “API usage rate” and the “API execution rate” is used as the API index that reflects the number of application downloads. However, the weighted sum of the aggregation values ​​of the “number of API calls” can also be used. Furthermore, the weighted sum of the aggregation value of the “number of API calls” is used as the API index that reflects the “application rating.” However, the weighted sum of the aggregation values ​​of the “API usage rate” and the “API execution rate” can also be used.

[0142] (5b) In the embodiment above, both the “number of units sold” and the “first multiplication factor” based on the “period since the start of mass production” are used in calculating the API index, which takes vehicle sales data into account. However, either the “number of units sold” or the “first multiplication factor” can be used. Alternatively, instead of the “number of units sold” as such, the “third multiplication factor” can be used, which is determined according to the number of units sold.

[0143] (5c) In the embodiment above, the API index that takes the security protection assets into account is not limited to the “first total number of API executions” and the “first total APL fee amount”. The API index that takes the security protection assets into account can, for example, be generated by multiplying any API index other than the “first total number of API executions” and the “first total APL fee amount” by a “second multiplication factor”.

[0144] (5d) The vehicle-internal devices 2 to 5, the application store 200, the vehicle sales DB 300, the terminal device 400 (hereinafter referred to as the control device group) and the method described in this disclosure can be implemented by a dedicated computer equipped with a memory and a processor programmed to perform one or more functions embodied by a computer program of the memory. Alternatively, the control device group and the method described in this disclosure can be implemented by a dedicated computer provided by a processor with one or more dedicated hardware logic circuits.Alternatively, the control device group and the method described in this disclosure can be implemented by one or more dedicated computers, provided by a combination of a processor and memory, programmed to perform one or more functions, and a processor with one or more hardware logic circuits. The computer program can be stored on a computer-readable, non-volatile, physical storage medium as an instruction to be executed by the computer. The method for implementing the functions of the respective units included in the control device group need not necessarily include software, and all functions can be implemented using one or more hardware components.

[0145] (5e) The multiple functions of a component in the above embodiment can be implemented by multiple components, or a single function of a component can be implemented by multiple components. Furthermore, multiple functions of multiple components can be implemented by a single component, or a single function that is implemented by multiple components can be implemented by a single component. Part of the configuration of the above embodiment can be omitted. At least part of the configuration in one embodiment can be added to or replaced in the configuration of another embodiment.

[0146] (5d) In addition to the API rating system described above, the present disclosure can be implemented in various forms, for example as a system which includes the API rating system as a component, as a program which causes the computer to act as the API rating system, as a non-volatile material storage medium, for example a semiconductor memory, for storing the program, and as an API rating index generation method. (6. Technical concept of the present disclosure) (First feature)

[0147] An API rating system includes: an information acquisition unit (400: S410 to S420) configured to capture an application programming interface access log representing a usage status of an application programming interface that is an interface for providing a vehicle function in accordance with a request from an application installed in a vehicle;a sales-related index generation unit (400: S480 to S490) configured to generate a sales-related index, which is an application programming interface index indicating the degree of influence of the application programming interface on the application and a user of the vehicle, according to a protocol aggregation value that is a result of aggregating the application programming interface access protocol for each vehicle classification, which is determined by classifying the vehicle based on vehicle sales data related to sales of the vehicle, and for each type of application programming interface; and an output unit (400: S510) configured to output the sales-related index. (Second characteristic)

[0148] An API rating system comprises: an access log store (200) configured to collect and store an application programming interface (API) access log from a vehicle, representing the usage state of an API that provides an interface for delivering a vehicle function in response to a request from an application installed in the vehicle; a sales data store (300) configured to accumulate vehicle sales data relating to sales of the vehicle; and an information acquisition unit (400: S410 to S420) configured to capture the API access log and vehicle sales data from the access log store and the sales data store.a sales-related index generation unit (400: S480 to S490) configured to generate a sales-related index, which is an application programming interface index indicating the degree of influence of the application programming interface on the application and a user of the vehicle, according to a protocol aggregation value that is a result of aggregating the application programming interface access protocol for each vehicle classification obtained by classifying the vehicle based on vehicle sales data, and for each type of application programming interface; and an output unit (400: S510) configured to output the sales-related index. (Third characteristic)

[0149] In the API rating system according to the first or second characteristic, the sales-related index generation unit is configured to calculate the sales-related index by multiplying a multiplication factor determined according to the vehicle sales data with the protocol aggregation value aggregated for each vehicle classification and application programming interface type. (Fourth characteristic)

[0150] In the API rating system, according to one of the first to third characteristics, the vehicle classification is determined using at least either a vehicle type or a sales region of the vehicle. (Fifth characteristic)

[0151] In the API rating system according to one of the first to fourth characteristics, the vehicle sales data includes at least either a numerical number of units of the vehicle sold or a period from the start of mass production of the vehicle. (Sixth characteristic)

[0152] In the API scoring system according to one of the first to fifth features, the protocol aggregation value includes at least either a numerical number of application programming interface calls or an application programming interface fee amount, where the numerical number of application programming interface calls is a numerical number of times the application programming interface is called by the application, and the application programming interface fee amount is imposed on a provider of the application in accordance with a communication data set associated with a use of the application programming interface. (Seventh characteristic)

[0153] In the API rating system according to one of the first to sixth features, the information acquisition unit further collects data indicating whether there is an impact on a security asset for each type of application programming interface, and the application programming interface rating system further includes a security-related index generation unit (300: S500) configured to multiply a multiplication factor specified for each classification of the security asset by the protocol aggregation value to generate a security-related index which is an application programming interface index that takes into account the impact on the security asset. (Eighth characteristic)

[0154] In the API rating system according to one of the first to seventh features, the information acquisition unit further records an application operation log containing a numerical number of executions and an execution time of the application installed in the vehicle, wherein the log aggregation value includes at least either an application programming interface usage rate, which is a numerical number of uses of the application programming interface per application, or an application programming interface execution rate, which is a numerical number of uses of the application programming interface per average execution time of the application, and the application programming interface rating system further includes an application-related index generation unit (300: S450 to S470) configured to generate an application-related index, which is an application programming interface index.which takes into account the application's usage status, according to a protocol aggregation value that is a result of aggregating the application programming interface access protocol for each application type and for each application programming interface type. (Ninth characteristic)

[0155] In the API rating system according to the eighth feature, the application-related index generation unit is configured to generate the application-related index by weighted summation of the protocol aggregation value using a weighting factor that is set for each application type according to a cumulative value of the application downloaded to the vehicle. (Tenth characteristic)

[0156] In the API rating system according to the eighth or ninth feature, the application-related index generation unit is configured to generate the application-related index by weighted summation of the protocol aggregation value using a weighting factor that is set for each application type according to a user application rating for the application. (Eleventh characteristic)

[0157] In the API rating system according to one of the first to tenth features, a base index generation unit is configured to generate a base index that is an application programming interface index that takes into account the usage status of the application programming interface according to a protocol aggregation value that is a result of an aggregation of the application programming interface access protocol for each type of application programming interface. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] JP 2013 - 164 879 A

[0004]

Claims

[1] Application programming interface rating system, comprising: an information acquisition unit (400: S410 to S420) configured to capture an application programming interface access log representing the usage status of an application programming interface that is an interface for providing a vehicle function in accordance with a request from an application installed in a vehicle; a sales-related index generation unit (400: S480 to S490) configured to generate a sales-related index, which is an application programming interface index indicating a degree of influence of the application programming interface on the application and a user of the vehicle, according to a protocol aggregation value that is a result of aggregating the application programming interface access protocol for each vehicle classification obtained by classifying the vehicle based on vehicle sales data related to sales of the vehicle, and for each type of application programming interface; and an output unit (400: S510) configured to output the sales-related index. [2] Application programming interface rating system, comprising: an access log store (200) configured to collect and store an application programming interface access log from a vehicle, representing a usage state of an application programming interface that is an interface for providing a vehicle function in accordance with a request from an application installed in the vehicle; a sales data store (300) configured to accumulate vehicle sales data related to sales of the vehicle; an information acquisition unit (400: S410 to S420) configured to capture the application programming interface access log and vehicle sales data from the access log memory and sales data memory; a sales-related index generation unit (400: S480 to S490) configured to generate a sales-related index, which is an application programming interface index indicating a degree of influence of the application programming interface on the application and a user of the vehicle, according to a protocol aggregation value that is a result of aggregating the application programming interface access protocol for each vehicle classification obtained by classifying the vehicle based on vehicle sales data, and for each type of application programming interface; and an output unit (400: S510) configured to output the sales-related index. [3] Application programming interface rating system according to claim 1 or 2, wherein the sales-related index generation unit is configured to calculate the sales-related index by multiplying a multiplication factor determined according to the vehicle sales data by the protocol aggregation value aggregated for each vehicle classification and each application programming interface type. [4] Application programming interface rating system according to claim 1 or 2, wherein the vehicle classification is determined based on at least either a vehicle type of the vehicle or a sales region of the vehicle. [5] Application programming interface evaluation system according to claim 1 or 2, wherein the vehicle sales data includes at least either a numerical number of units of the vehicle sold or a period of time from the start of mass production of the vehicle. [6] Application programming interface rating system according to claim 1 or 2, wherein the protocol aggregation value includes at least either a numerical number of application programming interface (API) calls or an application programming interface (API) fee amount, The numerical number of application programming interface calls is a numerical number of times the application programming interface is called by the application, and The application programming interface (API) fee is imposed on an application provider according to the amount of communication data associated with the use of the application programming interface. [7] Application programming interface rating system according to claim 1 or 2, wherein The information acquisition unit further collects data indicating whether there is an impact on a security protection asset for each type of application programming interface, and The application programming interface rating system further includes a security-related index generation unit (300: S500) configured to multiply a multiplication factor specified for each classification of the security asset by the protocol aggregation value to generate a security-related index which is an application programming interface index that takes into account the impact on the security asset. [8] Application programming interface rating system according to claim 1 or 2, wherein The information acquisition unit also records an application operation log that includes a numerical number of executions and an execution time of the application installed in the vehicle. The protocol aggregation value includes at least either an application programming interface (API) usage rate, which is a numerical number of API uses per application, or an API execution rate, which is a numerical number of API uses per average application execution time, and The application programming interface rating system further includes an application-related index generation unit (300: S450 to S470) configured to generate an application-related index which is an application programming interface index which takes into account the usage status of the application, according to the protocol aggregation value which is the result of aggregating the application programming interface access protocol for each application type and for each application interface type. [9] Application programming interface rating system according to claim 8, wherein the application-related index generation unit is configured to generate the application-related index by weighted summation of the protocol aggregation value using a weighting factor that is set for each type of application according to a cumulative value of the application downloaded to the vehicle. [10] Application programming interface rating system according to claim 8, wherein the application-related index generation unit is configured to generate the application-related index by weighted summation of the protocol aggregation value using a weighting factor that is specified for each type of application according to a user application rating for the application. [11] Application programming interface evaluation system according to claim 1 or 2, further comprising: a base index generation unit configured to generate a base index that is an application programming interface index that reflects the application programming interface usage status, according to the protocol aggregation value, which is the result of aggregating the application programming interface access protocol for each application programming interface type. [12] Program that causes a computer to function as the following: an information acquisition unit (S410 to S420) configured to capture an application programming interface access log representing the usage status of an application programming interface, which is an interface that provides a function of a vehicle in accordance with a request from an application installed in the vehicle; a sales-related index generation unit (S480 to S490) configured to generate a sales-related index, which is an application programming interface index indicating a degree of influence of the application programming interface on the application and a user of the vehicle, according to a protocol aggregation value that is a result of aggregating the application programming interface access protocol for each vehicle classification obtained by classifying the vehicle based on vehicle sales data related to sales of the vehicle, and for each type of application programming interface; and an output unit (S510) configured to output the sales-related index.

Images