Vehicle-mounted computing power sharing income determination method and device, equipment, medium and product

Abstract

The invention relates to a vehicle-mounted computing power sharing income determination method and device, equipment, a medium and a product, and relates to the technical field of automobiles. The method comprises the following steps: obtaining a total income provided by executing a calculation task and execution parameters of each vehicle when a plurality of vehicles execute the calculation task; the execution parameter is used for representing the contribution of the vehicle during execution of the calculation task; determining the income of each vehicle based on the total income and the execution parameters of each vehicle; the revenue is used to pay a consumption order for each vehicle. Therefore, earnings can be allocated to the vehicles according to the total earnings of the calculation tasks and the execution parameters of the vehicles, and the problem that when the vehicle-mounted computing power resources are shared, some vehicle owners have poor enthusiasm to share the vehicle-mounted computing power resources, and then the utilization rate of the vehicle-mounted computing power resources is low is solved.

Description

Technical Field

[0001] This application relates to the field of automotive technology, specifically to a method, apparatus, equipment, medium, and product for determining revenue from vehicle-mounted computing power sharing. Background Technology

[0002] With the rapid development of automotive intelligence, high-performance onboard computing units have become an indispensable component of intelligent vehicles. These units not only handle critical control functions during vehicle operation but also possess powerful data processing and computing capabilities (also known as computing power). However, in practical applications, vehicles spend a significant amount of time in non-driving states, leaving onboard computing units idle for extended periods. This results in underutilization of onboard computing resources and a waste of these resources. Currently, the solution is to provide these idle onboard computing resources to external computing tasks to achieve effective utilization.

[0003] However, some car owners are not very enthusiastic about sharing in-vehicle computing resources, resulting in low utilization rates of these resources. Therefore, how to increase car owners' enthusiasm for sharing in-vehicle computing resources has become an urgent problem to be solved. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and product for determining revenue from sharing in-vehicle computing power, to at least address the problem that some car owners have low enthusiasm for sharing in-vehicle computing power resources, leading to low utilization rates of these resources. The technical solution of this application is as follows:

[0005] According to the first aspect of this application, a method for determining revenue from vehicle-mounted computing power sharing is provided, applied to a computing power sharing device. The method includes: obtaining the total revenue provided by executing a computing task and the execution parameters of each vehicle when multiple vehicles execute the computing task; the execution parameters are used to characterize the contribution of each vehicle in executing the computing task; determining the revenue of each vehicle based on the total revenue and the execution parameters of each vehicle; and using the revenue to pay for the consumption orders of each vehicle.

[0006] Based on the aforementioned technical means, this application can obtain the total revenue provided by executing a computing task and the execution parameters of each vehicle when multiple vehicles execute the computing task, representing the vehicle's contribution to the task. Furthermore, based on the total revenue and the execution parameters of each vehicle, the revenue of each vehicle is determined, and this revenue is used to pay for each vehicle's consumption orders. That is, the greater the vehicle's contribution to the computing task, the more computing resources it shares, and the more revenue the vehicle should receive, thus enabling it to pay for more consumption orders. This incentivizes vehicle owners to actively share computing resources to obtain more revenue to pay for consumption orders. This solves the problem that some vehicle owners have low enthusiasm for sharing onboard computing resources, leading to low utilization rates of these resources. Therefore, it increases vehicle owners' enthusiasm for sharing onboard computing resources, thereby improving the utilization rate of these resources.

[0007] In one possible implementation, the execution parameters include at least one of the following: available computing resources, the amount of data to be processed for the computing task, the duration of the computing task execution, and the speed at which the computing task is transmitted.

[0008] Based on the aforementioned technical means, this application can characterize the vehicle's contribution to a computational task by utilizing its available computing resources, the amount of data processed, the execution time, and the transmission speed. Specifically, generally, the more available computing resources a vehicle has, the more data it processes, the shorter the execution time, and the faster the transmission speed, the greater its contribution to the computational task, and consequently, the greater its reward. This improves the accuracy and rationality of reward allocation.

[0009] In one possible implementation, the revenue of each vehicle is determined based on the total revenue and the execution parameters of each vehicle, including: determining the contribution value of each vehicle in performing the computation task based on the execution parameters of each vehicle and the weights of the execution parameters; and determining the revenue of each vehicle based on the contribution value of each vehicle and the total revenue.

[0010] Based on the aforementioned technical means, this application can determine the contribution value of a vehicle in performing a computational task according to the weight of the execution parameters, and then determine the revenue of each vehicle based on the contribution value of the vehicle and the total revenue. That is, different execution parameters contribute differently to the computational task. Therefore, determining the contribution value of a vehicle based on the weight of the execution parameters can improve the accuracy of determining the contribution value of the vehicle, and thus improve the accuracy of revenue allocation.

[0011] In one possible implementation, the revenue of each vehicle is determined based on its contribution value and total revenue, including: summing the contribution values ​​of each vehicle to determine the total contribution value; dividing the contribution value of each vehicle by the total contribution value to determine the contribution value percentage of each vehicle; and multiplying the contribution value percentage of each vehicle by the total revenue to determine the revenue of each vehicle.

[0012] Based on the aforementioned technical means, this application can determine the vehicle's revenue according to the proportion of the vehicle's contribution value. That is, the higher the proportion of the vehicle's contribution value, the more revenue should be allocated to the vehicle, thereby improving the accuracy and rationality of revenue allocation.

[0013] In one possible implementation, the method further includes: upon receiving a payment request from a consumer transaction device, if the amount of the consumer order for the target vehicle is less than or equal to the revenue of the target vehicle, then the revenue of the target vehicle is used to pay for the consumer order of the target vehicle; the target vehicle is any one of multiple vehicles; the payment request is used to request the computing power sharing device to pay for the consumer order of the target vehicle; if the amount of the consumer order for the target vehicle is greater than the revenue of the target vehicle, then the revenue of the target vehicle is not used to pay for the consumer order of the target vehicle.

[0014] Based on the aforementioned technical means, this application can utilize the revenue generated from vehicle-shared computing resources to pay for vehicle consumption orders, thereby providing a channel for the use of revenue, further promoting the effective utilization of onboard computing resources, and improving the travel payment experience for car owners.

[0015] In one possible implementation, upon receiving a payment request from the consumer transaction device, if the amount of the target vehicle's consumption order is less than or equal to the target vehicle's revenue, before using the target vehicle's revenue to pay for the target vehicle's consumption order, the method further includes: receiving a verification request from the consumer transaction device, the verification request being used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle; the verification request includes the vehicle identifier of the vehicle to be verified; the vehicle to be verified is a vehicle detected by the consumer transaction device; if the vehicle identifier of the vehicle to be verified is the vehicle identifier of the target vehicle, it is determined that the vehicle to be verified has passed verification; if the vehicle identifier of the vehicle to be verified is not the vehicle identifier of the target vehicle, it is determined that the vehicle to be verified has failed verification.

[0016] Based on the aforementioned technical means, this application can pre-verify whether a vehicle that may have a payment request supports using revenue to pay for the vehicle's consumption orders. This facilitates using the vehicle's revenue to pay for the consumption orders when they are generated later, thereby improving the efficiency of order payment and avoiding the problem of reduced order payment efficiency when the vehicle does not support using revenue to pay for the vehicle's consumption orders.

[0017] According to the second aspect of this application, a method for determining revenue from vehicle-mounted computing power sharing is provided, applied to a consumer transaction device. The method includes: when the consumer transaction device generates a consumption order for a target vehicle, sending a payment request to the computing power sharing device via an interface call; the payment request is used to request the computing power sharing device to pay for the consumption order of the target vehicle using the revenue from the target vehicle; the target vehicle is any one of multiple vehicles; the revenue of each of the multiple vehicles is determined based on the total revenue provided by executing the computing task and the execution parameters of each vehicle when the multiple vehicles execute the computing task.

[0018] Based on the aforementioned technical means, this application can determine the revenue obtained by each vehicle from sharing computing resources based on the total revenue provided by executing the computing task and the execution parameters of each vehicle when multiple vehicles execute the computing task. Furthermore, by calling an interface, the revenue obtained from the shared computing resources of the vehicles can be used to pay for vehicle consumption orders. Calling the interface enables the connection between the consumption transaction device and the computing power sharing device. That is, the execution parameters can characterize the vehicle's contribution to the computing task. The greater the vehicle's contribution to the computing task, the more computing power resources the vehicle shares, and the more revenue the vehicle should receive. Consequently, more consumption orders can be paid using these revenues. This incentivizes car owners to actively share computing resources to obtain more revenue to pay for consumption orders. This solves the problem that some car owners have poor enthusiasm for sharing vehicle computing resources, leading to low utilization rates of vehicle computing resources. Moreover, it provides a channel for using the revenue, further promoting the effective utilization of vehicle computing resources and improving the travel payment experience for car owners.

[0019] In one possible implementation, before sending a payment request to the computing power sharing device by calling an interface when the consumer transaction device generates a consumer order for the target vehicle, the method further includes: when the consumer transaction device detects a vehicle to be verified, sending a verification request to the computing power sharing device by calling an interface; the verification request is used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle; the verification request includes the vehicle identifier of the vehicle to be verified.

[0020] Based on the aforementioned technical means, this application can pre-verify whether a vehicle that may have a payment request supports using revenue to pay for the vehicle's consumption orders by calling an interface. This facilitates the use of vehicle revenue to pay for vehicle consumption orders when generating consumption orders in the future, thereby improving the efficiency of order payment and avoiding the problem of reduced order payment efficiency when the vehicle does not support using revenue to pay for vehicle consumption orders.

[0021] According to a third aspect provided in this application, a revenue distribution device is provided, applied to a computing power sharing device, including a transmission module and a determination module; the transmission module is used to acquire the total revenue provided by executing a computing task and the execution parameters of each vehicle when multiple vehicles execute the computing task; the execution parameters are used to characterize the contribution of each vehicle in executing the computing task; the determination module is used to determine the revenue of each vehicle based on the total revenue and the execution parameters of each vehicle; the revenue is used to pay for the consumption orders of each vehicle.

[0022] In one possible implementation, the execution parameters include at least one of the following: available computing resources, the amount of data to be processed for the computing task, the duration of the computing task execution, and the speed at which the computing task is transmitted.

[0023] In one possible implementation, the determining module is further configured to determine the contribution value of each vehicle in performing the computation task based on the execution parameters and weights of each vehicle; the determining module is further configured to determine the revenue of each vehicle based on the contribution value of each vehicle and the total revenue.

[0024] In one possible implementation, the determining module is further configured to determine the total contribution value by summing the contribution values ​​corresponding to each vehicle; the determining module is further configured to determine the contribution value percentage of each vehicle by dividing the contribution value corresponding to each vehicle by the total contribution value; and the determining module is further configured to determine the revenue of each vehicle by multiplying the contribution value percentage of each vehicle by the total revenue.

[0025] In one possible implementation, the revenue distribution device further includes a processing module; the processing module is configured to, upon receiving a payment request from the consumer transaction device, use the revenue of the target vehicle to pay for the consumer order of the target vehicle if the amount of the consumer order of the target vehicle is less than or equal to the revenue of the target vehicle; the target vehicle is any one of multiple vehicles; the payment request is used to request the computing power sharing device to pay for the consumer order of the target vehicle; the processing module is further configured to, if the amount of the consumer order of the target vehicle is greater than the revenue of the target vehicle, not use the revenue of the target vehicle to pay for the consumer order of the target vehicle.

[0026] In one possible implementation, the transmission module is further configured to receive a verification request sent by the consumer transaction device, the verification request being used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle; the verification request includes the vehicle identifier of the vehicle to be verified; the vehicle to be verified is a vehicle detected by the consumer transaction device; the determination module is further configured to determine that the vehicle to be verified has passed verification if the vehicle identifier of the vehicle to be verified is the vehicle identifier of the target vehicle; the determination module is further configured to determine that the vehicle to be verified has failed verification if the vehicle identifier of the vehicle to be verified is not the vehicle identifier of the target vehicle.

[0027] According to the fourth aspect provided in this application, a revenue distribution device is provided, applied to a consumer transaction device, including a transmission module; the transmission module is used to send a payment request to a computing power sharing device by calling an interface when the consumer transaction device generates a consumer order for a target vehicle; the payment request is used to request the computing power sharing device to pay for the consumer order of the target vehicle through the revenue of the target vehicle; the target vehicle is any one of multiple vehicles; the revenue of each of the multiple vehicles is determined based on the total revenue provided by executing the computing task and the execution parameters of each vehicle when the multiple vehicles execute the computing task.

[0028] In one possible implementation, the transmission module is further configured to send a verification request to the computing power sharing device by calling an interface when the consumer transaction device detects a vehicle to be verified; the verification request is used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle; the verification request includes the vehicle identifier of the vehicle to be verified.

[0029] According to a fifth aspect provided in this application, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement the method of the first aspect described above and any possible implementation thereof.

[0030] According to a sixth aspect provided in this application, a computer-readable storage medium is provided that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0031] According to the seventh aspect provided in this application, a computer program product is provided, the computer program product including computer instructions, which, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect and any possible implementation thereof.

[0032] Therefore, the above-mentioned technical features of this application have the following beneficial effects:

[0033] (1) This application can obtain the total revenue provided by executing a computing task and the execution parameters of each vehicle when multiple vehicles execute a computing task, which characterize the vehicle's contribution to the computing task. Furthermore, based on the total revenue and the execution parameters of each vehicle, the revenue of each vehicle is determined, and the revenue of each vehicle is used to pay for each vehicle's consumption orders. That is, the greater the vehicle's contribution to the computing task, the more computing resources the vehicle shares, and the more revenue the vehicle should receive, thus enabling the use of that revenue to pay for more consumption orders. This incentivizes vehicle owners to actively share computing resources to obtain more revenue to pay for consumption orders. This solves the problem that some vehicle owners have low enthusiasm for sharing vehicle computing resources, leading to low utilization of vehicle computing resources. Therefore, it increases the enthusiasm of vehicle owners to share vehicle computing resources, thereby improving the utilization rate of vehicle computing resources.

[0034] (2) This application can characterize the vehicle's contribution to the computational task by utilizing the available computing resources, the amount of data processed, the execution time, and the transmission speed of the computational task. That is, generally, the more available computing resources, the more data processed, the shorter the execution time, and the faster the transmission speed of the computational task, the greater the vehicle's contribution, and the greater its corresponding benefit. This improves the accuracy and rationality of benefit allocation.

[0035] (3) This application can determine the contribution value of a vehicle in performing a computational task based on the weight of the execution parameters, and then determine the revenue of each vehicle based on the contribution value of the vehicle and the total revenue. That is, different execution parameters have different contributions to the computational task. Therefore, determining the contribution value of a vehicle based on the weight of the execution parameters can improve the accuracy of determining the contribution value of the vehicle, and thus improve the accuracy of revenue allocation.

[0036] (4) This application can determine the revenue of a vehicle based on the proportion of its contribution value. That is, the higher the proportion of the vehicle's contribution value, the more revenue should be allocated to the vehicle, thereby improving the accuracy and rationality of the revenue allocation.

[0037] (5) This application can use the revenue from vehicle-shared computing resources to pay for vehicle consumption orders, thereby providing a channel for the use of revenue, further promoting the effective use of vehicle-mounted computing resources, and improving the travel payment experience of car owners.

[0038] (6) This application can pre-verify whether a vehicle that may have a payment request supports using revenue to pay for the vehicle's consumption order, so that when generating a consumption order later, the vehicle's revenue can be used to pay for the vehicle's consumption order, thereby improving the efficiency of order payment and avoiding the problem of reduced order payment efficiency when the vehicle does not support using revenue to pay for the vehicle's consumption order.

[0039] (7) This application can determine the revenue obtained by each vehicle from sharing computing resources based on the total revenue provided by the execution of the computing task and the execution parameters of each vehicle when multiple vehicles execute the computing task. Furthermore, by calling an interface, the revenue obtained from the shared computing resources of the vehicles can be used to pay for vehicle consumption orders. Calling the interface can realize the connection between the consumption transaction device and the computing power sharing device. That is, the execution parameters can characterize the vehicle's contribution to the computing task. The greater the vehicle's contribution to the computing task, the more computing resources the vehicle shares, and the more revenue the vehicle should receive. Consequently, more consumption orders can be paid using these revenues. This can incentivize car owners to actively share computing resources to obtain more revenue to pay for consumption orders. This solves the problem that some car owners have poor enthusiasm for sharing vehicle computing resources, leading to low utilization rates of vehicle computing resources. Furthermore, it provides a channel for using the revenue, further promoting the effective utilization of vehicle computing resources and improving the travel payment experience for car owners.

[0040] (8) This application can pre-verify whether a vehicle that may have a payment request supports using revenue to pay for the vehicle's consumption order by calling the interface. This makes it convenient to use the vehicle's revenue to pay for the vehicle's consumption order when generating the consumption order in the future, thereby improving the efficiency of order payment and avoiding the problem of reduced order payment efficiency when the vehicle does not support using revenue to pay for the vehicle's consumption order.

[0041] It should be noted that the technical effects of any of the implementation methods in aspects three through seven can be found in the technical effects of the corresponding implementation methods in aspects one and two, and will not be repeated here.

[0042] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0043] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0044] Figure 1 This is a schematic diagram illustrating the structure of a revenue distribution system according to an exemplary embodiment;

[0045] Figure 2 This is a flowchart illustrating a method for determining the revenue from sharing in-vehicle computing power, according to an exemplary embodiment.

[0046] Figure 3 This is a flowchart illustrating yet another method for determining revenue sharing of onboard computing power, according to an exemplary embodiment;

[0047] Figure 4 This is a flowchart illustrating yet another method for determining revenue sharing of onboard computing power, according to an exemplary embodiment;

[0048] Figure 5 This is a flowchart illustrating yet another method for determining revenue sharing of onboard computing power, according to an exemplary embodiment;

[0049] Figure 6 This is a flowchart illustrating yet another method for determining revenue sharing of onboard computing power, according to an exemplary embodiment;

[0050] Figure 7 This is a flowchart illustrating yet another method for determining revenue sharing of onboard computing power, according to an exemplary embodiment;

[0051] Figure 8 This is a flowchart illustrating yet another method for determining revenue sharing of onboard computing power, according to an exemplary embodiment;

[0052] Figure 9 This is a schematic diagram illustrating a third-party application scenario for revenue payment based on shared vehicle computing power, according to an exemplary embodiment.

[0053] Figure 10 This is a flowchart illustrating a payment settlement based on vehicle-mounted computing power revenue according to an exemplary embodiment;

[0054] Figure 11 This is a block diagram of a revenue distribution device according to an exemplary embodiment. Figure 1 ;

[0055] Figure 12 This is a block diagram of a revenue distribution device according to an exemplary embodiment. Figure 2 ;

[0056] Figure 13 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0057] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0058] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0059] In related technologies, idle vehicle computing resources can be provided to external computing tasks to achieve effective utilization of these resources. However, some car owners are not very enthusiastic about sharing vehicle computing resources, resulting in low utilization rates.

[0060] Against the backdrop of the Internet of Things (IoT), intelligent transportation systems and IoT technologies are developing rapidly, and third-party payment systems related to vehicles are also advancing quickly, leading to increasingly frequent interactions between intelligent vehicles and external systems. For example, transportation infrastructure such as parking lots, charging stations, and highways all require data interaction and deep integration with vehicles. Therefore, deep data fusion and interaction between vehicles and external systems is an inevitable trend in technological development.

[0061] To overcome the problem of low enthusiasm among car owners for sharing in-vehicle computing resources, leading to insufficient utilization of these resources, this application provides a method for determining revenue from in-vehicle computing resource sharing. This method aggregates idle in-vehicle computing resources to an in-vehicle computing resource sharing and revenue settlement platform via a communication network, enabling the management of both in-vehicle computing resources and computing tasks. Furthermore, revenue (also known as computing power revenue) is generated by scheduling external computing tasks to be executed on corresponding vehicles, and corresponding computing power revenue is allocated to each vehicle. This not only achieves effective utilization of in-vehicle computing resources but also brings additional economic benefits to car owners. This helps improve user acceptance and satisfaction with in-vehicle computing resource sharing and promotes the development of in-vehicle computing resource sharing services.

[0062] Meanwhile, to further incentivize car owners to participate in sharing in-vehicle computing resources, a revenue settlement and transaction module and an interface open module were constructed. The interface open module provides corresponding APIs for third-party application payment systems to call, enabling seamless integration between computing power sharing devices (also known as in-vehicle computing power sharing and revenue settlement platforms) and consumer transaction devices (also known as third-party application payment systems) (such as parking fee systems, charging station fee systems, or highway systems). This provides diverse channels for using computing power revenue, allowing third-party application payment systems to pay for consumer orders based on computing power revenue (such as parking fee payments, charging station fee payments, and highway electronic toll collection (ETC) fee payments). This satisfies diverse user needs, stimulates car owners to participate in sharing idle vehicle resources, further promotes the effective utilization of in-vehicle computing resources, revitalizes idle vehicle computing resources, and increases the added value of vehicles.

[0063] Furthermore, the seamless integration of the vehicle-mounted computing power sharing and revenue settlement platform with third-party application payment systems can improve the payment process experience in travel payment scenarios. By connecting with third-party application payment systems, payment can be made, simplifying the payment process and enhancing the payment experience during travel.

[0064] For ease of understanding, the following section provides a detailed description of the method for determining the revenue from vehicle-mounted computing power sharing provided in this application, in conjunction with the accompanying drawings.

[0065] The method for determining revenue from vehicle-mounted computing power sharing provided in this application embodiment can be applied to revenue distribution systems. Figure 1 This is a schematic diagram illustrating the structure of a revenue distribution system according to an exemplary embodiment. For example... Figure 1 As shown, the revenue distribution system 10 includes: vehicle 11, computing power sharing device 12 (i.e., vehicle-mounted computing power sharing and revenue settlement platform), and consumer transaction device 13 (i.e., third-party application payment system).

[0066] The vehicle 11 includes: a vehicle-side hardware module 111 and a vehicle-side software module 112. The vehicle-side hardware module 111 includes: an onboard computing unit 1111, a storage unit 1112, and an onboard communication unit 1113. The vehicle-side software module 112 includes: a computing task receiving module 1121, a computing task execution module 1122, a computing resource monitoring module 1123, and a personal earnings account module 1124.

[0067] The computing power sharing device 12 includes: an onboard computing power resource management module 121, a computing task management module 122, a revenue settlement and transaction module 123, and an interface opening module 124. The onboard computing power resource management module 121 includes an onboard computing power resource access module 1211, an onboard computing power resource virtualization module 1212, and an onboard computing power resource monitoring module 1213. The computing task management module 122 includes: a computing task processing module 1221, a computing task scheduling module 1222, a computing task distribution module 1223, and a computing task monitoring module 1224. The revenue settlement and transaction module 123 includes a computing power revenue settlement module 1231, a payment transaction processing module 1232, a log recording module 1233, and an account management module 1234. The interface open module 124 includes: application access authentication interface 1241, vehicle identity authentication interface 1242, computing power account query interface 1243, order payment request interface 1244, payment notification callback interface 1245, payment order query interface 1246, transaction order query interface 1247, and transaction data statistics interface 1248.

[0068] The consumer transaction device 13 includes an application access module 131, a vehicle identification and authentication module 132, a payment request module 133, a payment status monitoring module 134, an order processing module 135, and a third-party hardware module 136.

[0069] Vehicle 11 and computing power sharing device 12 can interact via communication networks (such as 4G / 5G, Wi-Fi, etc.). Computing power sharing device 12 and consumer transaction device 13 can interact via API.

[0070] The computing power sharing device 12 is used to receive computing tasks, distribute computing tasks to vehicles 11 for execution, obtain the total revenue provided by executing computing tasks and the execution parameters of vehicles 11 when executing computing tasks, determine the revenue of vehicles 11 based on the total revenue and the execution parameters of vehicles 11, receive payment requests sent by the consumer transaction device 13, and use the revenue of vehicles 11 to pay for consumer orders. Vehicles 11 include multiple vehicles.

[0071] The vehicle-side hardware module 111 is the foundational module for the revenue distribution system 10, responsible for providing onboard computing power, storage resources, and the ability to communicate with external systems. The onboard computing unit 1111 is the hardware module that executes computing tasks, responsible for the computational logic, output control, general computing, and artificial intelligence (AI) computing. In this application, the onboard computing unit 1111 is used to execute computing tasks based on general computing and AI computing capabilities. The onboard computing unit 1111 includes a cockpit domain controller and a driving domain controller.

[0072] Storage unit 1112 is responsible for storing various data and control commands of vehicle 11, including real-time data and historical data. In this application, storage unit 1112 is used to store data related to computing tasks. Vehicle communication unit 1113 includes an in-vehicle communication unit, a cellular communication unit, and an inter-vehicle communication unit. Vehicle communication unit 1113 is responsible for data exchange and information transmission between various modules within vehicle 11 and between the vehicle and the outside world. In this application, the in-vehicle communication unit is used to connect the cockpit domain controller and the driving domain controller to achieve in-vehicle data transmission; the cellular communication unit is used to enable communication between vehicle 11 and computing power sharing device 12.

[0073] The vehicle-side software module 112 provides functions such as receiving computing tasks, monitoring and managing computing power revenue. The computing task receiving module 1121 is used to listen for, verify, and allocate computing tasks. Specifically, it is responsible for listening to computing tasks issued by the computing power sharing device 12. Upon receiving a computing task, it is responsible for verifying the compliance of the computing task and whether it is compatible with the computing capabilities of the vehicle 11, and then allocating the verified computing tasks to the computing task execution module 1122 for further processing.

[0074] The computing task execution module 1122 is used to load computing tasks, execute computing tasks, process the execution results of computing tasks, and return the execution results of computing tasks. Specifically, it receives computing tasks assigned by the computing task receiving module 1121 and loads the computing tasks into the on-board computing unit 1111. Further, it uses the on-board computing resources of the driving domain controller or cockpit domain controller to execute computing tasks and monitors the execution status and progress of computing tasks; after processing the execution results of computing tasks, it generates the final execution result of the computing tasks and returns the final execution result of the computing tasks to the computing power sharing device 12.

[0075] The computing resource monitoring module 1123 is used to monitor and provide early warnings for onboard computing resources. Specifically, it monitors the real-time usage of available computing resources, storage resources, and network communication resources of vehicle 11, and evaluates the current performance and computing power of vehicle 11 based on resource usage to ensure the smooth execution of computing tasks. When resource usage exceeds a preset threshold or an anomaly occurs, an alarm is triggered and corresponding computing task scheduling measures are taken.

[0076] The personal earnings account module 1124 is used to present the account information, earnings records, and payment records of vehicle 11. Specifically, it displays the number of computing tasks that vehicle 11 has participated in, the completion status of the computing tasks, the contribution to the computing tasks (also known as the contribution value percentage), the corresponding computing power earnings, and the records of payments made by consumer transaction device 13 using computing power earnings.

[0077] The vehicle-mounted computing resource management module 121 is an important component of the revenue distribution system 10. It is responsible for the access, monitoring, management, and dynamic allocation of computing resources of vehicles 11. This module can manage the access of vehicles 11, collect computing resource data of vehicles 11 in real time, ensure that only legitimate vehicles can access the computing resource sharing device 12, and provide isolation and flexible allocation of computing resources through virtualization technology, as well as dynamically allocate computing resources according to the needs of computing tasks, so as to ensure the maximum utilization of resources and the smooth execution of computing tasks.

[0078] The vehicle-mounted computing resource access module 1211 is used for vehicle 11 access authentication and authorization, connection management and maintenance, and access to computing resources. Specifically, it performs identity authentication and authorization for vehicles 11 accessing the computing resource sharing device 12, ensuring that only legitimate vehicles 11 with certain computing resources can access the computing resource sharing device 12; it is responsible for managing and maintaining the communication connection status between vehicles 11 and the computing resource sharing device 12, ensuring the stability of the communication connection; and after the vehicle 11 accesses the platform, it obtains information about the vehicle-mounted computing unit 1111 and storage unit 1112.

[0079] The vehicle-mounted computing power resource virtualization module 1212 is used to virtualize and isolate the vehicle-mounted computing power resources of the vehicle 11 connected to the computing power sharing device 12. Specifically, virtualization technologies (such as containers (Docker), virtual machines (VMs), etc.) are used to abstract the vehicle-mounted computing power resources into a virtual resource pool. Furthermore, according to the needs of computing tasks, vehicle-mounted computing power resources are allocated and scheduled for computing tasks. At the same time, virtualization technology is used to achieve resource isolation between different computing tasks, ensuring that the resources of one computing task will not affect the operation of other computing tasks.

[0080] The vehicle-mounted computing resource monitoring module 1213 is used for real-time monitoring of the vehicle-mounted computing resources of the vehicle 11. Specifically, it monitors the vehicle-mounted computing resources in real time by collecting various performance index data of the vehicle-mounted computing unit 1111 (such as computing power utilization, memory usage, disk storage space usage, and network bandwidth); it continuously monitors the operating status of the vehicle 11 and the operating status of the vehicle-mounted computing unit 1111, providing data support for the distribution and scheduling of computing tasks.

[0081] The computing task management module 122 is responsible for managing various computing tasks. It has functions such as receiving, parsing, scheduling, issuing and real-time monitoring of computing tasks to ensure that computing tasks can be executed in an orderly manner according to the needs of computing tasks.

[0082] The computation task processing module 1221 receives external computation tasks, parses and verifies them to ensure the accuracy of the task's format, priority, algorithm parameters, and dependencies. It also performs necessary preprocessing (e.g., data preparation, environment configuration) based on the task's characteristics and requirements. Furthermore, it stores the processed computation tasks in a task queue or database for subsequent scheduling and execution. This module also handles the collection, organization, verification, and storage of computation task execution results.

[0083] After the on-board computing unit 1111 completes the execution of the computing task, it will send the execution result of the computing task to this module for unified collection, ensuring the integrity and accuracy of the collected execution result of the computing task, and performing necessary formatting and standardization processing on the original result, as well as verifying and validating the collected execution result of the computing task according to the preset verification rules (such as data integrity check, range verification, consistency check), generating the final execution result of the computing task, and storing the final execution result of the computing task.

[0084] The computing task scheduling module 1222 is used to formulate corresponding scheduling strategies based on factors such as the priority of each computing task to be executed, computing resource requirements, and the time required to execute the computing task. It retrieves computing tasks to be executed from the task queue or database, selects the most suitable on-board computing resources to allocate each computing task to be executed according to the scheduling strategy, coordinates the allocation of computing tasks and load balancing among different on-board computing resources to ensure the efficient utilization of on-board computing resources, and handles the dependencies and execution order between computing tasks to ensure that computing tasks are executed correctly according to the scheduling strategy.

[0085] The computation task distribution module 1223 is used to distribute computation tasks to the corresponding vehicles 11 according to the instructions of the computation task scheduling module 1222, send detailed information of the computation task (such as input data, execution algorithm script, environment configuration) to the vehicles 11, and track the distribution status of the computation task to ensure that the computation task can be successfully distributed to the vehicles 11 (for example, if the vehicles 11 are faulty or have insufficient resources, the computation task scheduling module 1222 will be automatically restarted to select other vehicles 11 for distribution).

[0086] The computing task monitoring module 1224 is used to monitor the execution status of computing tasks in real time (including the execution progress of computing tasks, the usage of on-board computing resources, and the execution duration of computing tasks). It can acquire and process anomalies during the execution of computing tasks and perform early warning monitoring. It provides monitoring data of computing tasks to provide data support for the formulation of scheduling strategies of the computing task scheduling module 1222.

[0087] The revenue settlement and transaction module 123 is used to accurately calculate the computing power revenue of the vehicle 11 participating in the execution of computing tasks based on the on-board computing power resources and the execution status of computing tasks, ensuring the rationality and fairness of the distribution of computing power revenue. Furthermore, this module is also used to process payment requests between computing power revenue and the consumption transaction device 13, ensuring the settlement of computing power revenue and providing stable services for the distribution and payment transactions of computing power revenue.

[0088] The computing power revenue settlement module 1231 allocates corresponding computing power revenue to vehicle 11 based on the execution status of computing tasks. The payment transaction processing module 1232 processes payment requests between computing power revenue and the consumption transaction device 13, and performs deduction operations on computing power revenue according to the payment requests. The log recording module 1233 records all computing power revenue allocation and payment settlement information and provides corresponding interfaces for other modules to call and query. The account management module 1234 creates an account for vehicle 11, updates the account in real time, displays the account's computing power revenue balance and details, and payment record details. It also provides notification and reminder functions for the vehicle owner, sending notifications of changes in computing power revenue balance, payment success or failure reminders, etc.

[0089] The interface opening module 124 defines the interface for the computing power sharing device 12 and the consumer transaction device 13 to interact and exchange data. The application access authentication interface 1241 verifies whether the consumer transaction device 13 has permission to access the computing power sharing device 12 and assigns it a corresponding application access authentication key. When the consumer transaction device 13 needs to connect with the computing power sharing device 12, it first sends an application access request to the computing power sharing device 12. After the computing power sharing device 12 approves the application access request, it assigns a unique application access authentication key (i.e., App_AccessKey) to the consumer transaction device 13. Each time the consumer transaction device 13 calls a relevant interface of the computing power sharing device 12, it needs to carry this application access authentication key for identity verification. After the computing power sharing device 12 verifies the validity of the application access authentication key, it allows the computing power sharing device 12 to complete the relevant interface call operation.

[0090] The vehicle identity authentication interface 1242 is used to verify whether the vehicle identifier submitted by the consumer transaction device 13 belongs to the vehicle connected to the computing power sharing device 12 (i.e., vehicle 11). When a vehicle triggers a payment scenario on the consumer transaction device 13, the consumer transaction device 13 calls the interface to send a verification request to the computing power sharing device 12 for identity verification based on the identified vehicle identifier (e.g., license plate number). After receiving the vehicle identifier, the computing power sharing device 12 performs identity verification and returns the verification result.

[0091] The computing power account query interface 1243 is used to allow the consumer transaction device 13 to query the computing power revenue balance of vehicle 11. The consumer transaction device 13 calls this interface through App_AccessKey to send a query request for vehicle 11 to the computing power sharing device 12. After receiving the query request, the computing power sharing device 12 queries the corresponding computing power account information based on the vehicle identifier of vehicle 11 to obtain the computing power revenue balance, and returns it to the consumer transaction device 13.

[0092] The order payment request interface 1244 is used to allow the consumer transaction device 13 to send a payment request and pay the consumer order fee with the computing power revenue balance. The consumer transaction device 13 calls this interface through App_AccessKey to send a payment request to the computing power sharing device 12. If the computing power revenue balance meets the payment conditions, the computing power sharing device 12 verifies the validity of the consumer order and deducts the corresponding computing power revenue to pay the consumer order.

[0093] The payment notification callback interface 1245 is used by the computing power sharing device 12 to proactively notify the consumer transaction device 13 of the status change of the consumer order after the payment is completed. After the computing power sharing device 12 completes the payment for the consumer order, it calls this interface to return the unique code (Identity document, ID) and status change information of the consumer order to the consumer transaction device 13. The consumer transaction device 13 then updates the information of the consumer order based on the ID and status change of the consumer order.

[0094] The payment order query interface 1246 allows the consumer transaction device 13 to query the status and details of consumer orders. The consumer transaction device 13 calls this interface and specifies the ID of the consumer order to be queried. Further, the computing power sharing device 12 queries the status and details of the consumer order based on the ID and returns the information to the consumer transaction device 13, including the status of the consumer order, the cost of the consumer order, and the payment time of the consumer order.

[0095] The transaction order query interface 1247 allows the consumer transaction device 13 to query transaction orders based on conditions such as time range and vehicle identification. The consumer transaction device 13 calls this interface and specifies the time range and vehicle identification of the transaction orders to be queried. Further, the computing power sharing device 12 queries the transaction orders and returns the information to the consumer transaction device 13. The returned information includes a list of consumer orders, the total cost of the consumer orders, and the number of consumer orders. The consumer transaction device 13 can generate a settlement detail table based on the returned information.

[0096] The transaction data statistics interface 1248 provides query functions for transaction data statistics and analysis, allowing the consumer transaction device 13 to understand order transaction trends. The computing power sharing device 12 collects and analyzes transaction data, generates statistical data, and the consumer transaction device 13 can call this interface to obtain statistical information on transaction data within a time range.

[0097] The consumer transaction device 13 is used to interface with the computing power sharing device 12, and requires system upgrades according to the interface specifications. The application access module 131 provides the function of interface interface with the computing power sharing device 12, realizing data interaction with the computing power sharing device 12. It calls the application access authentication interface 1241 to initiate an application access request to the computing power sharing device 12, obtains the App_AccessKey, and completes the encapsulation of relevant interfaces according to the interface specifications.

[0098] The vehicle identification and authentication module 132 identifies the vehicle's identifier and calls the vehicle identity authentication interface 1242 and the computing power account query interface 1243 to determine whether the vehicle has the authority to use computing power revenue to pay for consumer orders. The payment request module 133 adds the function of sending payment requests to the computing power sharing device 12 to the existing consumer order module. Based on the vehicle's identifier and the consumer order information, it calls the order payment request interface 1244 to send the payment request. The payment status monitoring module 134 monitors the status changes of consumer orders by periodically or in real-time calling the payment order query interface 1246 to obtain the latest status of the consumer orders.

[0099] The order processing module 135 is responsible for the creation of all consumer orders, payment requests, and exception handling functions of the consumer transaction device 13. Based on the status changes of consumer orders obtained by the payment status monitoring module 134, it updates the status information of local consumer orders.

[0100] A third-party hardware module 136 is used to identify vehicle identification information and physically interact with the vehicle. For example, the third-party hardware module 136 can be a parking lot camera and gate, a charging station charging pile, or a highway entrance ETC system and gate. For instance, after a parking lot camera identifies a vehicle's license plate number, this module notifies the order processing module 135 to create a consumption order. After payment for the consumption order is completed, it receives a gate opening command to open the gate. After the vehicle finishes charging, the charging pile generates a consumption order based on the vehicle's identification information. When the vehicle exits the highway, a consumption order is generated after the ETC or camera identifies the vehicle's license plate number. After payment for the consumption order is completed, it receives a gate opening command.

[0101] Figure 2 This is a flowchart illustrating a method for determining revenue from vehicle-mounted computing power sharing according to an exemplary embodiment, applicable to computing power sharing devices, such as... Figure 2 As shown, the method for determining the revenue from vehicle-mounted computing power sharing includes the following steps:

[0102] S201. Obtain the total revenue provided by the execution of the computation task and the execution parameters of each vehicle when multiple vehicles execute the computation task.

[0103] Among them, the execution parameters are used to characterize the vehicle's contribution when performing computational tasks.

[0104] Optionally, the computation task can be a computational task from an external system other than multiple vehicles. Computational tasks refer to those primarily limited by processor speed, requiring significant computing resources to complete. The total reward provided by executing the computation task can be the reward obtained upon completion, which can exist in the form of a balance in an e-wallet, allowing for operations such as topping up, transferring, and spending. A computational task can include multiple subtasks, each executed by multiple vehicles. The vehicle's execution parameters can be some of the vehicle's own operating parameters during the execution of the computation task. There can be n vehicles, where n is a positive integer.

[0105] For example, the computing task can be a map building task, an image recognition task, or a speech recognition task, which require computing resources to complete.

[0106] The revenue settlement and transaction module of the computing power sharing device can obtain the total revenue provided by the execution of the computing task and the execution parameters of each vehicle when multiple vehicles execute the computing task after the computing task is completed.

[0107] Optionally, the vehicle's execution parameters may include at least one of the following: available computing power resources (also known as onboard computing power, i.e., Vehicle_ComputingPower), the amount of data processed for the computing task (data processing volume, i.e., Data_ProcessingVolume), the duration of executing the computing task (also known as task completion time, i.e., Task_CompletionTime), and the speed of transmitting the computing task (also known as data transmission speed, i.e., Data_TransmissionSpeed). The vehicle's execution parameters can be the average of the execution parameters over a certain period of time.

[0108] It should be noted that onboard computing power measures the computing power that the vehicle's onboard computing unit can provide to the subtasks of the computing task to be executed. Data processing volume measures the amount of data processed by the vehicle during the execution of the subtasks of the computing task. Task completion time measures the time consumed by the vehicle's onboard computing unit to process the subtasks of the computing task. Data transmission speed measures the efficiency of data exchange related to the subtasks of the computing task between the vehicle's internal and external systems.

[0109] Optionally, during the execution of the computing task, the revenue settlement and transaction module of the computing power sharing device can monitor the vehicle's available computing power resources and the amount of data processed by the vehicle in the process of executing the sub-tasks of the computing task in real time through the vehicle computing power resource monitoring module, so as to obtain the vehicle's available computing power resources and the amount of data processed in the computing task.

[0110] Optionally, during the execution of the computing task, the revenue settlement and transaction module of the computing power sharing device can monitor in real time the time consumed by the vehicle in executing the sub-tasks of the computing task and the transmission speed of the data related to the sub-tasks of the computing task through the computing task monitoring module, so as to obtain the time consumed by the vehicle in executing the sub-tasks of the computing task.

[0111] S202. Based on the total revenue and the execution parameters of each vehicle, determine the revenue for each vehicle.

[0112] The proceeds are used to pay for each vehicle's purchase order.

[0113] Optionally, the revenue settlement and transaction module of the computing power sharing device can determine the revenue based on the execution parameters of each vehicle. Furthermore, the revenue settlement and transaction module can determine the revenue of each vehicle based on the total revenue and the contribution value of each vehicle when executing the computing task. The revenue of each vehicle can be the revenue that the vehicle should receive after completing the sub-tasks of the computing task. Vehicle users can view the vehicle's computing power revenue data in real time through the vehicle's infotainment system or an application (APP).

[0114] In one possible implementation, the specific method for determining the revenue of each vehicle based on the total revenue and the execution parameters of each vehicle can be found in the embodiments described below.

[0115] Figure 3 This is a flowchart illustrating a method for determining revenue sharing of onboard computing power according to an exemplary embodiment, such as... Figure 3 As shown, step S202 above specifically includes the following steps:

[0116] S301. Based on the execution parameters and weights of each vehicle, determine the contribution value of each vehicle in performing the computation task.

[0117] Optionally, the weights of execution parameters can be manually set through the computing power revenue settlement module of the computing power sharing device. Furthermore, the computing power revenue settlement module of the computing power sharing device can determine the contribution value of each vehicle when performing a computing task based on the execution parameters and weights of each vehicle. Specifically, for a given vehicle, the computing power revenue settlement module can multiply a certain execution parameter of that vehicle by its weight, and then sum the products corresponding to each execution parameter to obtain the contribution value of that vehicle when performing the computing task.

[0118] It should be noted that the sum of the weights of each execution parameter is 1.

[0119] For example, assume that the vehicle's execution parameters include available computing power (i.e., Vehicle_ComputingPower), the amount of data processed for the computing task (i.e., Data_ProcessingVolume), the duration of executing the computing task (i.e., Task_CompletionTime), and the speed of transmitting the computing task (i.e., Data_TransmissionSpeed). The weight of available computing power is α, the weight of the amount of data processed for the computing task is β, the weight of the duration of executing the computing task is γ, and the weight of the speed of transmitting the computing task is δ. In particular, the sum of these four weights is 1, i.e., α + β + γ + δ = 1.

[0120] Then, the computing power revenue settlement module of the computing power sharing device can obtain the contribution value of a certain vehicle when performing a computing task through Formula 1 (i.e., Contribution_Value in Formula 1).

[0121] Contribution_Value=(Vehicle_ComputingPower*α)+(Data_ProcessingVolume*β)+(Task_CompletionTime*γ)+(Data_TransmissionSpeed*δ) Formula 1;

[0123] Wherein, Vehicle_ComputingPower represents available computing power resources, Data_ProcessingVolume represents the amount of data processed for computing tasks, Task_CompletionTime represents the duration of executing computing tasks, Data_TransmissionSpeed ​​represents the speed of transmitting computing tasks, α is the weight of available computing power resources, β is the weight of the amount of data processed for computing tasks, γ is the weight of the duration of executing computing tasks, and δ is the weight of the speed of transmitting computing tasks.

[0124] S302. Determine the revenue for each vehicle based on its contribution value and total revenue.

[0125] Optionally, based on the contribution value and total revenue of each vehicle, the computing power revenue settlement module of the computing power sharing device can determine the revenue of each vehicle.

[0126] Figure 4 This is a flowchart illustrating yet another method for determining revenue sharing of onboard computing power according to an exemplary embodiment, such as... Figure 4 As shown, step S302 above specifically includes the following steps:

[0127] S401. The sum of the contribution values ​​corresponding to each vehicle is determined as the total contribution value.

[0128] Optionally, the computing power revenue settlement module of the computing power sharing device can use Formula 2 to sum the contribution values ​​of each vehicle to determine the total contribution value.

[0129]

[0130] Where n is the total number of vehicles, i represents the i-th vehicle (where i is a positive integer), and Vi_Contribution_Value represents the contribution value of the i-th vehicle.

[0131] S402. The quotient of the contribution value of each vehicle to the total contribution value is used to determine the contribution value percentage of each vehicle.

[0132] Optionally, since the contribution values ​​of different vehicles may have different ranges, it is necessary to normalize the contribution values ​​to obtain the contribution ratio (also known as the contribution value percentage) of each vehicle participating in the computing task. The computing power revenue settlement module of the computing power sharing device can determine the contribution value percentage of each vehicle (i.e., Contribution_Value_Percentage in Formula 3) by dividing the contribution value of each vehicle by the total contribution value.

[0133]

[0134] Where Vi_Contribution_Value is the contribution value corresponding to the i-th vehicle. This represents the total contribution value of n vehicles.

[0135] Optionally, depending on the actual execution of the calculation task, some additional adjustment factors may need to be considered to ensure the fairness and reasonableness of the profit distribution. Two adjustment factors can be defined: additional incentives and penalty deductions. When settling profit distribution, if adjustment factors are required, their coefficients can be flexibly set according to the execution of the calculation task. A coefficient greater than 1 indicates additional incentives, and a coefficient less than 1 indicates penalty deductions. Based on the set coefficients, the contribution percentage of each vehicle can be recalculated.

[0136] For example, if a vehicle has high revenue in a recent period, it indicates that the vehicle has made a significant contribution to the computing task and that the vehicle owner is highly motivated to share computing resources. In this case, it is possible to consider providing additional incentives for the vehicle by multiplying its contribution percentage by an adjustment factor greater than 1, thereby increasing the vehicle's contribution percentage and thus improving its revenue, thereby incentivizing vehicle owners to share computing resources.

[0137] If a vehicle's revenue has been low recently, it indicates that the vehicle's contribution to the computing task is small and the owner's enthusiasm for sharing computing resources is low. In this case, it is advisable to penalize the vehicle by multiplying its contribution percentage by an adjustment factor less than 1, thereby reducing the vehicle's contribution percentage and thus lowering its revenue, incentivizing the owner to share computing resources.

[0138] S403. The revenue for each vehicle is determined by multiplying the contribution value of each vehicle by the total revenue.

[0139] Optionally, the computing power revenue settlement module of the computing power sharing device can use Formula 4 to calculate the revenue (i.e., Revenue in Formula 4) by multiplying the contribution value ratio of each vehicle with the total revenue (i.e., Total_Revenue in Formula 4).

[0140] Vi_Revenue=Total_Revenue*Vi_Contribution_Value_Percentage Formula 4;

[0141] Where Vi_Revenue represents the revenue of the i-th vehicle, Total_Revenue represents the total revenue of the computation task, and Vi_Contribution_Value_Percentage represents the percentage of the contribution value of the i-th vehicle.

[0142] Figure 5 This is a flowchart illustrating another method for determining vehicle-mounted computing power sharing revenue according to an exemplary embodiment. After step S202 above, the method further includes the following steps:

[0143] S501. Upon receiving a payment request from the consumer transaction device, if the amount of the consumer order for the target vehicle is less than or equal to the revenue of the target vehicle, the revenue of the target vehicle shall be used to pay for the consumer order for the target vehicle.

[0144] The target vehicle is any one of multiple vehicles; the payment request is used to request the computing power sharing device to pay for the consumption order of the target vehicle.

[0145] Optionally, when the computing power sharing device receives an application access request from the application access module of the consumer transaction device through the application access authentication interface of the interface open module, the computing power sharing device, upon verifying that the consumer transaction device has the authority to access the computing power sharing device, allocates and issues a corresponding application access authentication key to it. The consumer transaction device can then use the application access authentication key to call its relevant interfaces to send verification requests and identity authentication requests.

[0146] Furthermore, after the verification request from the consumer transaction device is approved, the computing power sharing device can receive the payment request sent by the consumer transaction device through the order payment request interface of the interface opening module. The payment request may include the consumer order of the target vehicle and the vehicle identifier of the target vehicle.

[0147] Furthermore, the order payment request interface can call the revenue settlement and query module to check whether the amount of the target vehicle's consumption order is less than or equal to the target vehicle's revenue. If the amount of the target vehicle's consumption order is less than or equal to the target vehicle's revenue, the revenue settlement and query module uses the target vehicle's revenue to pay for the target vehicle's consumption order (i.e., deducts the target vehicle's revenue), and the payment notification callback interface returns the status change of the consumption order after payment to the order processing module through the application access module, so that the order processing module can update the status of the consumption order.

[0148] S502. If the amount of the consumption order for the target vehicle is greater than the revenue of the target vehicle, then the revenue of the target vehicle will not be used to pay for the consumption order for the target vehicle.

[0149] Optionally, if the amount of the consumption order for the target vehicle is greater than the revenue of the target vehicle, the revenue settlement and query module will not use the revenue of the target vehicle to pay for the consumption order of the target vehicle.

[0150] Figure 6 This is a flowchart illustrating yet another method for determining revenue sharing of onboard computing power according to an exemplary embodiment, such as... Figure 6 As shown, prior to step S501 above, the method further includes the following steps:

[0151] S601, Receive the verification request sent by the consumer transaction device.

[0152] The verification request is used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle; the verification request includes the vehicle identifier of the vehicle to be verified; the vehicle to be verified is the vehicle detected by the consumer transaction device.

[0153] Optionally, the computing power sharing device can receive verification requests sent by the consumer transaction device through the vehicle identity authentication interface of the interface open module. The verification request is used to determine whether the vehicle to be verified has a computing power account (i.e., whether the vehicle to be verified is a vehicle that supports using computing power revenue to pay for consumer orders), that is, whether the vehicle to be verified is allowed to share its own computing power resources to perform computing tasks.

[0154] S602. If the vehicle identifier of the vehicle to be verified is the same as that of the target vehicle, the vehicle to be verified is deemed to have passed verification.

[0155] Optionally, the computing power sharing device can query whether the vehicle to be verified is the target vehicle (i.e., whether there is a computing power account for the vehicle to be verified) through the vehicle identity authentication interface of the interface open module, based on the vehicle identifier of the vehicle to be verified. If the vehicle identifier of the vehicle to be verified is the same as that of the target vehicle (i.e., there is a computing power account for the vehicle to be verified), the computing power sharing device can determine that the vehicle to be verified has passed verification (i.e., it supports using computing power revenue to pay for consumer orders).

[0156] S603. If the vehicle identifier of the vehicle to be verified is not the same as that of the target vehicle, the vehicle to be verified shall be determined to fail verification.

[0157] Optionally, if the vehicle identifier of the vehicle to be verified is not the same as that of the target vehicle (i.e., there is no computing power account for the vehicle to be verified), the computing power sharing device can determine that the vehicle to be verified fails verification (i.e., it does not support using computing power revenue to pay for consumer orders).

[0158] Figure 7 This is a flowchart illustrating a method for determining revenue sharing from vehicle-mounted computing power according to an exemplary embodiment, applicable to consumer transaction devices, such as... Figure 7 As shown, the method for determining the revenue from vehicle-mounted computing power sharing includes the following steps:

[0159] S701. When the consumer transaction device generates a consumer order for the target vehicle, a payment request is sent to the computing power sharing device by calling the interface.

[0160] The payment request is used to request the computing power sharing device to pay for the consumption order of the target vehicle through the revenue of the target vehicle; the target vehicle is any one of multiple vehicles; the revenue of each of the multiple vehicles is determined based on the total revenue provided by the execution of the computing task and the execution parameters of each vehicle when the multiple vehicles execute the computing task.

[0161] Optionally, the application access module of the consumer transaction device can send an application access request to the application access authentication interface of the interface opening module of the computing power sharing device, and receive the application access authentication key when verifying that the consumer transaction device has the right to access the computing power sharing device, and develop the interface according to the interface specification to complete the encapsulation of the relevant interface.

[0162] After the verification request from the consumer transaction device is approved, and the order processing module of the consumer transaction device generates a consumption order for the target vehicle, the consumer transaction device can send a payment request to the computing power sharing device by calling the order payment request interface of the interface opening module through the application access module. After the payment request is approved, the application access module receives the status change of the consumption order after payment, and the order processing module updates the status of the consumption order.

[0163] After the payment for the purchase order is completed, the target vehicle can complete the payment and drive out of the parking lot, or complete the charging at the charging station, or drive out of the highway.

[0164] Figure 8 This is a flowchart illustrating yet another method for determining revenue sharing of onboard computing power according to an exemplary embodiment, such as... Figure 8 As shown, prior to step S701 above, the method further includes the following steps:

[0165] S801. When the consumer transaction device detects a vehicle to be verified, it sends a verification request to the computing power sharing device by calling the interface.

[0166] The verification request is used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle; the verification request includes the vehicle identifier of the vehicle to be verified.

[0167] Optionally, when a payment scenario is triggered by a vehicle (i.e., the vehicle to be verified) (e.g., the vehicle leaves a parking lot, finishes charging at a charging station, or exits a highway), the third-party hardware module of the consumer transaction device can identify the vehicle's identifier (i.e., the consumer transaction device detects the vehicle to be verified). The third-party hardware module can then send the vehicle's identifier to the order processing module of the consumer transaction device and generate a corresponding consumption order. Simultaneously, the third-party hardware module's application access module sends a request to call the vehicle identity authentication interface. Further, the application access module calls the vehicle identity authentication interface of the interface opening module to send a verification request.

[0168] Figure 9 This is a schematic diagram illustrating a third-party application scenario for revenue payment based on shared vehicle computing power, according to an exemplary embodiment. Figure 9 As shown, the onboard computing resources of multiple vehicles can be connected to a computing power sharing device via a communication network. This device manages computing resources and computing tasks, scheduling tasks to be executed on the corresponding vehicles through a task scheduling module. Furthermore, a computing power revenue settlement module allocates corresponding computing power revenue to each vehicle. Additionally, an open interface module provides corresponding API interfaces for third-party application scenarios (e.g., parking fee payment, charging station fee payment, or highway toll payment) to accept payment requests, enabling third-party application scenarios to use computing power revenue for payment. After payment, the computing power revenue settlement module generates a payment log.

[0169] Figure 10This is a flowchart illustrating payment settlement based on vehicle-mounted computing power revenue according to an exemplary embodiment, such as... Figure 10 As shown, the vehicle submits a computing resource access request to the onboard computing resource management module of the computing power sharing device. The onboard computing resource management module virtualizes the vehicle's computing resources and returns the access status of the computing resources to the vehicle. Furthermore, the computing task management module of the computing power sharing device can receive, decompose, and schedule computing tasks, and distribute these tasks to the vehicle for execution. During the process of the vehicle receiving and executing computing tasks, the computing task management module monitors the status of the computing tasks, and the onboard computing resource management module monitors the computing resources.

[0170] Furthermore, the vehicle submits the execution results of the computing tasks to the computing task management module. The computing task management module then integrates these results and returns the final execution status of the computing tasks to the vehicle. Additionally, the onboard computing resource management module transmits the usage details of the computing resources to the revenue settlement and transaction module of the computing power sharing device, and the computing task management module transmits the details of the computing tasks to the revenue settlement and transaction module. The revenue settlement and transaction module allocates the total computing power revenue for the computing tasks and returns the corresponding revenue to the vehicle, which then updates its computing power revenue.

[0171] The consumer transaction device sends an application access request to the interface opening module of the computing power sharing device. The interface opening module assigns a corresponding application access authentication key and sends the key to the request. The application access request encapsulates the relevant interfaces according to the interface specifications. When a vehicle triggers a payment scenario (e.g., the vehicle leaves a parking lot, finishes charging at a charging station, or exits a highway), a third-party hardware module of the consumer transaction device (e.g., parking lot cameras and gates, charging stations, or highway ETC and gates) identifies the vehicle's identifier and sends it to the order processing module, which then generates a consumption order. Simultaneously, the third-party hardware module sends a request to the application access module to call the vehicle identity authentication interface. Further, the application access module calls the vehicle identity authentication interface of the interface opening module to perform identity authentication and computing power account lookup based on the vehicle's identifier, and returns the authentication and lookup results to the application access module.

[0172] Furthermore, the application access module determines whether the vehicle supports using computing power revenue to pay for the consumption order. If the vehicle supports this, it sends a message to the order processing module indicating that the vehicle supports this payment method. The order processing module then sends a payment request for the consumption order to the application access module. The application access module forwards the payment request to the interface opening module, which in turn calls the revenue settlement and transaction module to deduct the computing power revenue and returns the consumption order status change to the interface opening module. The interface opening module forwards the consumption order status change to the application access module, which then forwards it to the order processing module, which updates the consumption order status. Finally, the order processing module returns the updated consumption order status to the vehicle, enabling the vehicle to complete the payment (the vehicle can leave the parking lot, confirm completion of charging at the charging station, or exit the highway).

[0173] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the revenue distribution device or electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0174] This application embodiment can, according to the above method, exemplarily divide a revenue distribution device or electronic device into functional modules. For example, the revenue distribution device or electronic device may include functional modules corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0175] Figure 11 This is a block diagram of a revenue distribution device according to an exemplary embodiment. Figure 1 . Reference Figure 11 The revenue distribution device 130 includes: a transmission module 1301 and a determination module 1302.

[0176] The transmission module 1301 is used to obtain the total benefit provided by the execution of the computation task and the execution parameters of each vehicle when multiple vehicles execute the computation task; the execution parameters are used to characterize the contribution of each vehicle when executing the computation task.

[0177] The determination module 1302 is used to determine the revenue of each vehicle based on the total revenue and the execution parameters of each vehicle; the revenue is used to pay for the consumption orders of each vehicle.

[0178] In one possible implementation, the execution parameters include at least one of the following: available computing resources, the amount of data to be processed for the computing task, the duration of the computing task execution, and the speed at which the computing task is transmitted.

[0179] In one possible implementation, the determining module 1302 is further configured to determine the contribution value of each vehicle when performing the computation task based on the execution parameters and weights of each vehicle; the determining module 1302 is further configured to determine the revenue of each vehicle based on the contribution value corresponding to each vehicle and the total revenue.

[0180] In one possible implementation, the determining module 1302 is further configured to determine the total contribution value by summing the contribution values ​​corresponding to each vehicle; the determining module 1302 is further configured to determine the contribution value percentage of each vehicle by dividing the contribution value corresponding to each vehicle by the total contribution value; and the determining module 1302 is further configured to determine the revenue of each vehicle by multiplying the contribution value percentage of each vehicle by the total revenue.

[0181] In one possible implementation, the revenue distribution device further includes a processing module 1303; the processing module 1303 is configured to, upon receiving a payment request from the consumer transaction device, use the revenue of the target vehicle to pay for the consumer order of the target vehicle if the amount of the consumer order of the target vehicle is less than or equal to the revenue of the target vehicle; the target vehicle is any one of multiple vehicles; the payment request is used to request the computing power sharing device to pay for the consumer order of the target vehicle; the processing module 1303 is further configured to, if the amount of the consumer order of the target vehicle is greater than the revenue of the target vehicle, not use the revenue of the target vehicle to pay for the consumer order of the target vehicle.

[0182] In one possible implementation, the transmission module 1301 is further configured to receive a verification request sent by the consumer transaction device, the verification request being used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle; the verification request includes the vehicle identifier of the vehicle to be verified; the vehicle to be verified is a vehicle detected by the consumer transaction device; the determination module 1302 is further configured to determine that the vehicle to be verified has passed verification if the vehicle identifier of the vehicle to be verified is the vehicle identifier of the target vehicle; the determination module 1302 is further configured to determine that the vehicle to be verified has failed verification if the vehicle identifier of the vehicle to be verified is not the vehicle identifier of the target vehicle.

[0183] Figure 12 This is a block diagram of a revenue distribution device according to an exemplary embodiment. Figure 2 . Reference Figure 12 The revenue distribution device 140 includes a transmission module 1401.

[0184] The transmission module 1401 is used to send a payment request to the computing power sharing device by calling an interface when the consumer transaction device generates a consumer order for the target vehicle. The payment request is used to request the computing power sharing device to pay for the consumer order of the target vehicle through the revenue of the target vehicle. The target vehicle is any one of multiple vehicles. The revenue of each of the multiple vehicles is determined based on the total revenue provided by the execution of the computing task and the execution parameters of each vehicle when the multiple vehicles execute the computing task.

[0185] In one possible implementation, the transmission module 1401 is further configured to send a verification request to the computing power sharing device by calling an interface when the consumer transaction device detects a vehicle to be verified; the verification request is used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle; the verification request includes the vehicle identifier of the vehicle to be verified.

[0186] Figure 13 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Figure 13 As shown, the electronic device 160 includes, but is not limited to, a processor 1601 and a memory 1602.

[0187] The aforementioned memory 1602 is used to store the executable instructions of the aforementioned processor 1601. It is understood that the aforementioned processor 1601 is configured to execute instructions to implement the method for determining vehicle-mounted computing power sharing revenue in the above embodiments.

[0188] It should be noted that those skilled in the art will understand that Figure 13 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 13 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0189] Processor 1601 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 1602, and by calling data stored in memory 1602, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Processor 1601 may include one or more processing modules. Optionally, processor 1601 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 1601.

[0190] The memory 1602 can be used to store software programs and various data. The memory 1602 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and application programs required by at least one functional module (such as an acquisition unit, a determination unit, a processing unit, etc.). Furthermore, the memory 1602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0191] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1602 including instructions, which can be executed by a processor 1601 of an electronic device 160 to implement the method for determining vehicle computing power sharing revenue in the above embodiments.

[0192] In actual implementation, Figure 11 The functions of the transmission module 1301, the determination module 1302, and the processing module 1303 in the middle and Figure 12 The transmission module 1401 in the middle can be made by Figure 13 The processor 1601 calls the computer program stored in the memory 1602 to implement the process. The specific execution process can be found in the description of the method for determining vehicle-mounted computing power sharing revenue in the previous embodiment, and will not be repeated here.

[0193] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0194] In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by the processor 1601 of an electronic device to complete the method for determining vehicle computing power sharing revenue in the above embodiments.

[0195] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of the electronic device, they implement the various processes of the above-described method for determining the revenue from vehicle-mounted computing power sharing, and can achieve the same technical effect as the above-described method for determining the revenue from vehicle-mounted computing power sharing. To avoid repetition, these will not be repeated here.

[0196] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0197] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0198] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the constituent units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0199] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0200] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, essentially, or the part that contributes to the prior art, or a complete or partial classification of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0201] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for determining revenue from vehicle-mounted computing power sharing, characterized in that, Applied to computing power sharing devices, the method includes: Obtain the total benefit provided by performing the computation task and the execution parameters of each vehicle when multiple vehicles perform the computation task; the execution parameters are used to characterize the contribution of each vehicle when performing the computation task. Based on the total revenue and the execution parameters of each vehicle, the revenue for each vehicle is determined; the revenue is used to pay for the consumption orders of each vehicle.

2. The method according to claim 1, characterized in that, The execution parameters include at least one of the following: available computing resources, the amount of data to be processed for the computing task, the duration of the computing task execution, and the speed at which the computing task is transmitted.

3. The method according to claim 1, characterized in that, The determination of the revenue for each vehicle based on the total revenue and the execution parameters of each vehicle includes: Based on the execution parameters of each vehicle and the weights of the execution parameters, the contribution value of each vehicle in performing the computation task is determined; The revenue of each vehicle is determined based on its contribution value and the total revenue.

4. The method according to claim 3, characterized in that, The determination of the revenue for each vehicle based on its contribution value and the total revenue includes: The sum of the contribution values ​​corresponding to each vehicle is determined as the total contribution value; The quotient of the contribution value of each vehicle to the total contribution value is determined as the contribution value percentage of each vehicle. The revenue of each vehicle is determined by multiplying the contribution value of each vehicle by the total revenue.

5. The method according to claim 1, characterized in that, The method further includes: Upon receiving a payment request from the consumer transaction device, if the amount of the consumer order for the target vehicle is less than or equal to the revenue of the target vehicle, then the revenue of the target vehicle is used to pay for the consumer order of the target vehicle; the target vehicle is any one of the plurality of vehicles; the payment request is used to request the computing power sharing device to pay for the consumer order of the target vehicle; If the amount of the consumption order for the target vehicle is greater than the revenue of the target vehicle, then the revenue of the target vehicle will not be used to pay for the consumption order for the target vehicle.

6. The method according to claim 5, characterized in that, Upon receiving a payment request from the consumer transaction device, if the amount of the target vehicle's consumption order is less than or equal to the target vehicle's revenue, before using the target vehicle's revenue to pay for the target vehicle's consumption order, the method further includes: The device receives a verification request sent by the consumer transaction device. The verification request is used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle. The verification request includes the vehicle identifier of the vehicle to be verified. The vehicle to be verified is the vehicle detected by the consumer transaction device. If the vehicle identifier of the vehicle to be verified is the same as the vehicle identifier of the target vehicle, then the vehicle to be verified is determined to have passed verification. If the vehicle identifier of the vehicle to be verified is not the same as the vehicle identifier of the target vehicle, the vehicle to be verified is determined to have failed verification.

7. A method for determining revenue from vehicle-mounted computing power sharing, characterized in that, Applied to consumer transaction devices, the method includes: When the consumer transaction device generates a consumer order for a target vehicle, a payment request is sent to the computing power sharing device via an interface call. The payment request is used to request the computing power sharing device to pay for the consumer order of the target vehicle using the revenue of the target vehicle. The target vehicle is any one of multiple vehicles. The revenue of each of the multiple vehicles is determined based on the total revenue provided by executing the computing task and the execution parameters of each vehicle when the multiple vehicles execute the computing task.

8. The method according to claim 7, characterized in that, Before sending a payment request to the computing power sharing device by calling the interface when the consumption transaction device generates a consumption order for the target vehicle, the method further includes: When the consumer transaction device detects a vehicle to be verified, it sends a verification request to the computing power sharing device by calling an interface; the verification request is used to request the computing power sharing device to verify whether the vehicle to be verified is the target vehicle; the verification request includes the vehicle identifier of the vehicle to be verified.

9. A profit distribution device, characterized in that, Applied to computing power sharing devices, including transmission modules and determination modules; The transmission module is used to obtain the total revenue provided by the execution of the computation task and the execution parameters of each vehicle when multiple vehicles execute the computation task; The execution parameters are used to characterize the vehicle's contribution when performing the computational task; The determining module is used to determine the revenue of each vehicle based on the total revenue and the execution parameters of each vehicle; The revenue is used to pay for the consumption orders of each of the vehicles.

10. A profit distribution device, characterized in that, Applications in consumer transaction devices, including transmission modules; The transmission module is used to send a payment request to the computing power sharing device by calling an interface when the consumer transaction device generates a consumer order for the target vehicle; the payment request is used to request the computing power sharing device to pay for the consumer order of the target vehicle using the revenue of the target vehicle; the target vehicle is any one of multiple vehicles; the revenue of each of the multiple vehicles is determined based on the total revenue provided by executing the computing task and the execution parameters of each vehicle when the multiple vehicles execute the computing task.

11. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, When the computer-executable instructions stored in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is capable of performing the method as described in any one of claims 1 to 8.

13. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 8.

Images