A driving device charging system, method, storage medium and electronic device

Abstract

The specification discloses a driving device charging system, method, storage medium and electronic device. The driving device charging system comprises a driving device and a first server, a client of the driving device, a second server of a payment service party, a charging device and a third server; the client sends a binding request to the first server; the first server sends account information and identification information of the driving device to the second server according to the binding request; the second server generates a contract certificate based on the identification information; the charging device performs a charging task after establishing a charging connection with the driving device, and sends a data acquisition request to the third server through the charging connection; the third server sends the contract certificate to the driving device through the charging device according to the data acquisition request; the driving device sends a deduction request to the second server based on the contract certificate, and the second server determines a deduction account bound by the driving device to perform deduction according to the contract certificate carried by the deduction request.

Description

Technical Field

[0001] This specification relates to the field of new energy vehicles, and in particular to a charging system, method, storage medium and electronic device for a driving device. Background Technology

[0002] With the continuous upgrading of new energy technologies, new energy vehicles have also developed rapidly. Compared with traditional fuel vehicles, new energy vehicles are mainly powered by batteries, which has advantages in many aspects.

[0003] However, the current common charging methods for new energy vehicles usually require swiping a card for authorization or scanning a code with a mobile app after plugging in the charging gun. The whole charging process is relatively cumbersome, and the card swiping or code scanning operation also takes up extra time, which seriously reduces the user experience.

[0004] Therefore, simplifying the charging process for new energy vehicles, shortening the charging time, and further improving the user experience is an urgent problem to be solved. Summary of the Invention

[0005] This specification provides a charging system, method, storage medium, and electronic device for driving equipment to partially solve the aforementioned problems existing in the prior art.

[0006] The following technical solution is adopted in this specification:

[0007] This specification provides a driving device charging system, including: the driving device charging system includes: a driving device belonging to a user and a first server corresponding to the driving device, a client corresponding to the driving device, a second server corresponding to a payment service provider, a charging device and a third server corresponding to the charging device;

[0008] The client is used to send a binding request to the first server in response to a binding operation performed by the user on the driving device;

[0009] The first server is configured to send the user's deduction account information and the identification information corresponding to the driving device to the second server according to the binding request;

[0010] The second server is used to generate a contract certificate based on the received identification information, establish a correspondence between the account information and the contract certificate, and send the contract certificate to the third server so that the third server can save the binding relationship information between the driving device and the contract certificate.

[0011] The charging device is used to perform a charging task for the driving device after establishing a charging connection with the driving device, and to send a data acquisition request to the third server through the charging connection.

[0012] The third server is used to determine the contract certificate corresponding to the driving device based on the data acquisition request sent by the driving device during charging and the binding relationship information, and send the contract certificate to the driving device through the charging device;

[0013] The driving device is used to send a deduction request to the second server based on the contract certificate returned by the charging device, so that the second server can determine the deduction account bound to the driving device according to the contract certificate carried in the deduction request and the corresponding relationship, and deduct the payment based on the deduction account.

[0014] Optionally, the third server is used to receive the identity certificate of the driving device sent by the first server and store it locally;

[0015] The charging device is used to forward the identity certificate sent by the driving device to the third server after establishing a charging connection with the driving device, so that the third server can authenticate the identity certificate sent by the driving device according to the locally stored identity certificate, and send a charging command to the charging device after successful authentication, so as to perform the charging task through the charging device.

[0016] Optionally, the second server is configured to query the identity certificate corresponding to the driving device from the third server based on the received identification information, and generate a contract certificate based on the identity certificate.

[0017] Optionally, the first server is configured to receive the V2G root certificate of the manufacturer corresponding to the charging device sent by the third server, and send the V2G root certificate to the driving device for storage;

[0018] The driving device is used to authenticate the V2G root certificate sent by the charging device based on the locally stored V2G root certificate after establishing a charging connection with the driving device, and to perform the charging task after successful authentication.

[0019] Optionally, the driving equipment charging system further includes a control terminal, wherein the first server is equipped with a certificate generation module;

[0020] The control terminal is used to determine the basic certificate data of the driving device, and when a data update instruction is received, to update the basic certificate data to obtain the updated basic certificate data, and to send the updated basic certificate data to the first server.

[0021] The first server is configured to generate an initial certificate based on the updated basic certificate data through the certificate generation module, and return the initial certificate to the driving device so that the driving device can sign the initial certificate to obtain the identity certificate corresponding to the driving device, and send the identity certificate to the first server.

[0022] This specification provides a method for charging a driving device, the method being applied to a driving device, including:

[0023] After establishing a charging connection with the charging device, a charging task is performed through the charging device. Based on the charging connection, a data acquisition request is sent to the third server corresponding to the charging device. The third server determines the contract certificate corresponding to the driving device based on the data acquisition request and the binding relationship information between the driving device and the contract certificate. The contract certificate is then sent to the driving device through the charging device. The contract certificate is generated by the second server corresponding to the payment service provider during the account binding phase based on the identification information of the driving device sent by the first server corresponding to the driving device. The binding relationship information is stored locally on the third server after receiving the contract certificate sent by the second server. The identification information is sent by the first server to the second server along with the user's deduction account information based on the binding request sent by the client. The binding request is sent by the client to the first server in response to the binding operation performed by the user on the driving device. The driving device belongs to the user.

[0024] Based on the contract certificate returned by the charging device, a deduction request is sent to the second server, so that the second server determines the deduction account bound to the driving device according to the contract certificate carried in the deduction request and the pre-established correspondence between the account information and the contract certificate, and deducts money based on the deduction account.

[0025] Optionally, after establishing a charging connection with the charging device, the charging task is performed through the charging device, specifically including:

[0026] After establishing a charging connection with the charging device, the V2G root certificate sent by the charging device is authenticated based on the locally stored vehicle-to-network (V2G) root certificate, and the charging task is executed after successful authentication. The V2G root certificate stored locally by the driving device is sent to the driving device by the first server after receiving the V2G root certificate of the manufacturer corresponding to the charging device from the third server.

[0027] Optionally, after establishing a charging connection with the charging device, the charging task is performed through the charging device, specifically including:

[0028] After establishing a charging connection with the charging device, the driver's identity certificate stored locally is sent to the charging device through the charging connection, so that the charging device can authenticate the identity certificate sent by the driver through the identity certificate of the driver stored locally on the third server, and execute the charging task based on the charging command sent by the third server after successful authentication.

[0029] This specification provides a method for charging a driving device, the method being applied to the charging device, including:

[0030] After establishing a charging connection with the driving device, a charging task is performed for the driving device. Furthermore, through the charging connection, the data acquisition request sent by the driving device during charging is forwarded to a third server corresponding to the charging device. This allows the third server to determine the contract certificate corresponding to the driving device based on the data acquisition request and the binding relationship information between the driving device and the contract certificate, and then send the contract certificate to the charging device. The contract certificate is generated by the second server corresponding to the payment service provider during the account binding phase, based on the identification information of the driving device sent by the first server corresponding to the driving device. The binding relationship information is stored locally on the third server after receiving the contract certificate sent by the second server. The identification information is sent by the first server to the second server along with the user's payment account information based on the binding request sent by the client. The binding request is sent by the client to the first server in response to the binding operation performed by the user on the driving device. The driving device belongs to the user.

[0031] The system receives the contract certificate and sends it to the driving device, so that the driving device sends a deduction request to the second server based on the contract certificate returned by the charging device. The second server then determines the deduction account bound to the driving device based on the contract certificate carried in the deduction request and the pre-established correspondence between the account information and the contract certificate, and performs the deduction based on the deduction account.

[0032] Optionally, after establishing a charging connection with the driving device, a charging task for the driving device is performed, specifically including:

[0033] After establishing a charging connection with the driving device, the system receives the identity certificate sent by the driving device.

[0034] The identity certificate is sent to the third server so that the third server can authenticate the identity certificate sent by the driving device based on the identity certificate stored locally, and send a charging command to the charging device after successful authentication. The identity certificate stored locally by the third server is the one sent in advance by the first server.

[0035] Based on the charging command, the charging task is executed.

[0036] This specification provides a charging method for a driving device, the method being applied to a third server corresponding to the charging device, including:

[0037] Receive data acquisition requests sent by the charging device after establishing a charging connection with the driving device;

[0038] Based on the data acquisition request and the binding relationship information between the driving device and the contract certificate, the contract certificate corresponding to the driving device is determined. The contract certificate is generated by the second server corresponding to the payment service provider during the account binding phase, based on the identification information of the driving device sent by the first server corresponding to the driving device. The binding relationship information is stored locally on the third server after receiving the contract certificate sent by the second server. The identification information is sent by the first server to the second server along with the user's deduction account information based on the binding request sent by the client. The binding request is sent by the client to the first server in response to the binding operation performed by the user on the driving device. The driving device belongs to the user.

[0039] The contract certificate is sent to the driving device via the charging device, so that the driving device sends a deduction request to the second server based on the contract certificate returned by the charging device. The second server then determines the deduction account bound to the driving device based on the contract certificate carried in the deduction request and the pre-established correspondence between the account information and the contract certificate, and deducts the payment based on the deduction account.

[0040] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described charging method for the driving device.

[0041] This specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described driving device charging method.

[0042] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects:

[0043] The driving device charging system provided in this specification includes: a driving device and a first server, a client of the driving device, a second server of the payment service provider, a charging device, and a third server; the client sends a binding request to the first server; the first server sends account information and the identification information of the driving device to the second server according to the binding request; the second server generates a contract certificate based on the identification information; the charging device performs a charging task after establishing a charging connection with the driving device, and sends a data acquisition request to the third server through the charging connection; the third server sends the contract certificate to the driving device through the charging device according to the data acquisition request; the driving device sends a deduction request to the second server based on the contract certificate, and the second server determines the deduction account bound to the driving device based on the contract certificate carried in the deduction request and performs the deduction.

[0044] As can be seen from the above method, this solution stores the contract certificate of the driving device and the binding relationship between the contract certificate and account information on a third-party server in advance during the binding phase. This allows the driving device to send a deduction request based on the contract certificate obtained from the third-party server during the actual charging process. The third-party server then queries the user's account information based on the contract certificate to deduct the payment. The entire process does not require the user to perform any additional authentication operations. Once the driving device and the charging device establish a connection, automatic charging and payment can be achieved. Compared with the traditional authentication method of scanning a code or swiping a card, this solution greatly simplifies the authentication and payment process during charging and effectively improves the user experience. Attached Figure Description

[0045] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0046] Figure 1 This is a schematic diagram of a charging system for a driving device provided in this specification;

[0047] Figure 2 This is a schematic diagram of the interaction framework of a driving equipment charging system provided in this specification.

[0048] Figure 3 This is a schematic diagram of a charging method for a driving device provided in this specification;

[0049] Figure 4 This is a schematic diagram of a charging method for a driving device provided in this specification;

[0050] Figure 5 This is a schematic diagram of a charging method for a driving device provided in this specification;

[0051] Figure 6 This specification provides a corresponding Figure 3 , Figure 4 or Figure 5 A schematic diagram of an electronic device. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0053] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0054] Figure 1 This is a schematic diagram of a driving device charging system provided in this specification. The driving device charging system includes: a driving device and a first server corresponding to the driving device, a client corresponding to the driving device, a second server corresponding to a payment service provider, a charging device and a third server corresponding to the charging device, and a control terminal.

[0055] Among them, the driving equipment belongs to the user, and the first server can refer to the server of the original equipment manufacturer (OEM) of the driving equipment. During the production process of the driving equipment, the first server can generate a unique identity certificate for each driving equipment and store the identity certificates of all driving equipment in the certificate pool (CCP) of the first server.

[0056] Specifically, the first server can deploy a Vehicle and Configuration Test Solutions (VCATS) module and a Manufacturing Execution System (MES) module. When the identity certificate is first installed on the driving device, the VCATS module can write the vehicle identification number (VIN) of the driving device into the electric vehicle communication controller (EVCC) of the driving device, and trigger the EVCC to generate basic certificate data such as key pairs and certificate signing requests (CSRs). Then, an identity certificate is generated based on this basic certificate data, and the identity certificate and the aforementioned basic certificate data are sent to the MES module. The MES module can generate the PCID of the driving device based on the VIN of the driving device and record the mapping relationship between the PCID and the VIN. Then, the PCID, basic certificate data, and identity certificate are sent to the driving device for storage.

[0057] It should be noted that during the online upgrade process of the driving equipment, MES can send the PCID, basic certificate data and identity certificate to the Over-the-Air Technology (OTA) module, thereby sending the PCID, basic certificate data and identity certificate to the driving equipment for storage through the OTA module.

[0058] In addition, when the driving equipment has been produced but not yet delivered to the user, the control terminal can determine the basic certificate data of the driving equipment, and when it receives a data update instruction, update the basic certificate data to obtain the updated basic certificate data, and then send the updated basic certificate data to the first server.

[0059] The first server can generate an initial certificate based on the updated base certificate data through the certificate generation module (TRC), and return the initial certificate to the driving device so that the driving device can sign the initial certificate to obtain the identity certificate corresponding to the driving device, and then send the identity certificate to the first server.

[0060] Specifically, after-sales personnel can select "Main Upgrade" on the control terminal (VIDA), which requires a main upgrade to the vehicle system (PIE) of the driving equipment. The vehicle system can detect that the updated basic certificate data is usable and send it to the first server via Open API.

[0061] The certificate generation module in the first server can generate an initial certificate based on the received updated basic certificate data, and encapsulate the initial certificate in a VBF file using DER encoding and return it to the control terminal. At this time, the control terminal sends a signature request to the certificate generation module of the first server.

[0062] After receiving the signature request, the certificate generation module returns the signature to the vehicle system of the driving equipment, so that the vehicle system writes the signature into the VBF file. The control terminal can download the VBF file and check the status. When the vehicle system receives the confirmation status from the control terminal, it sends the VBF file of the identity certificate to the first server with the updated basic certificate data.

[0063] Furthermore, in aftermarket scenarios for driving equipment, the PCID and identity certificate may need to be rewritten to the EVCC. Therefore, the control terminal and vehicle system can request the PCID and configuration certificate from the certificate generation module of the first server.

[0064] Specifically, after-sales personnel can select ECU REPLACEMENT on the control terminal. Then, the control terminal writes the VIN into the EVCC to trigger the EVCC to generate rewritten certificate data, and reads the rewritten data from the EVCC and sends it to the vehicle system.

[0065] The vehicle system can send the rewritten certificate data to the first server via the Open API. The certificate generation module on the first server can generate an initial certificate based on the received rewritten certificate data and encapsulate the initial certificate in a VBF file using DER encoding, then return it to the control terminal. At this point, the control terminal sends a signature request to the certificate generation module on the first server. After receiving the signature request, the certificate generation module returns a signature to the vehicle system of the driving device, enabling the vehicle system to write the signature into the aforementioned VBF file. The control terminal can download the aforementioned VBF file and check its status. When the vehicle system receives confirmation from the control terminal, it sends the VBF file of the identity certificate with the updated basic certificate data to the first server and sends a notification to the first server to delete the original identity certificate and basic certificate data.

[0066] After establishing a business partnership (such as signing a contract) between the manufacturers of driving equipment and charging equipment, the first server can send the identity certificates of each driving device in the local CCP to the third server, so that the third server can store the identity certificates of each driving device in the local CCP.

[0067] At the same time, the first server can also obtain the vehicle-to-grid (V2G) root certificate corresponding to the charging equipment manufacturer from the third server and download it to the EVCC of the driving device for storage.

[0068] Specifically, the first server can be equipped with a Public Key Infrastructure (PKI) module, which can obtain the V2G root certificate from the storage module (RCP) of the second server through an Application Program Interface (API).

[0069] In practical applications, V2G root certificates vary across different regions. When adding or updating a V2G root certificate, the PKI module can subscribe to events from a third-party server and obtain the latest V2G root certificate from the RCP. The PKI module can package the obtained V2G root certificate, obtain the V2G root certificate VBF file, and push it to the OTA module. The OTA module synchronizes the VBF file to the vehicle system on the first server for storage. When the vehicle returns to the after-sales workshop, after-sales personnel can select TOTALUPGRADE and download the latest VBF file to the vehicle's EVCC.

[0070] The V2G root certificate should be packaged into a single VBF file and preloaded into the EVCC during the end-of-life (EOL) test. All root certificates are DER encoded. A VBF file can contain a maximum of five DER-encoded certificates.

[0071] Furthermore, users can perform a binding operation for the driving device in the client corresponding to the driving device (such as the car owner's APP), thereby sending a binding request to the first server through the client. After receiving the binding request, the first server can send the user's deduction account information and the identification information corresponding to the driving device to the second server. The identification information can be the PCID of the driving device.

[0072] After receiving the aforementioned identification information and account information, the second server corresponding to the payment service provider can bind the two together. At the same time, it forwards the received identification identifier to the third server. After receiving the identification identifier, the third server can query the identity certificate corresponding to the driving device from its local CCP and then return the queried identity certificate to the second server.

[0073] In this specification, the aforementioned payment service provider can be a mobile operator, or, of course, a business service provider such as a bank that provides payment services.

[0074] After receiving the identity certificate returned by the third server, the second server can generate an initial contract certificate based on the identity certificate. The initial contract certificate may include contractSignatureCertChain, dhPublicKey, contractSignature EncryptedPrivateKey, and EMAID.

[0075] The second server can then sign the initial contract certificate using its own certificate signing module (MO CA) to obtain the final contract certificate, establish the correspondence between the user's account information and the contract certificate, and then send the final contract certificate to the third server.

[0076] After receiving the contract certificate, the third server can determine the binding relationship between the driving device and the contract certificate, and store the contract certificate and the binding relationship between the contract certificate and the driving device in the local CCP.

[0077] When the driving device and the charging device establish a charging connection, the charging device can forward the identity certificate sent by the driving device to the third server. Then, the third server authenticates the identity certificate sent by the driving device based on the locally stored identity certificate, and sends a charging command to the charging device after successful authentication. After receiving the charging command, the charging device can execute the charging task for the driving device. Of course, when the driving device sends the identity certificate, it can also send the locally stored V2G to the third server for authentication through the charging device.

[0078] In addition, the charging device can also send its own V2G root certificate to the driving device. The driving device authenticates the V2G root certificate sent by the charging device based on its locally stored V2G root certificate, and allows the charging device to charge it after successful authentication to perform the charging task. Of course, the charging device can also send the driving device's locally stored identity certificate to the driving device for authentication at the same time as sending the V2G root certificate.

[0079] It should be noted that, in this manual, the driving device can be charged after the third server of the charging device completes the authentication (one-way authentication), or the driving device can be charged after the third server of the charging device completes the authentication and the driving device completes the authentication (two-way authentication).

[0080] After the driving device is authenticated, it can send a data acquisition request to the charging device based on the aforementioned charging connection. The charging device can forward the received data acquisition request to the third server. After receiving the data acquisition request, the third server determines the driving device's contract certificate based on the driving device's identity certificate carried in the data acquisition request and the pre-stored binding relationship information between the driving device and the contract certificate, and issues the contract certificate to the charging device. The charging device can then install the received contract certificate in the driving device based on the charging connection.

[0081] Furthermore, the driving device can generate a deduction request and send it to the second server based on the charging data generated during the charging process (such as charging time, power consumption, etc.) and the received contract certificate. The second server can determine the deduction account bound to the driving device based on the contract certificate carried in the deduction request and the correspondence between the pre-established account information and the contract certificate, and deduct the payment from the deduction account according to the charging data carried in the deduction request.

[0082] Of course, the driving device can also send charging data and contract certificate to a third server corresponding to the charging device. The third server can determine the deduction information based on the charging data and forward the deduction information and contract certificate to a second server, so that the second server can deduct the payment from the account based on the deduction information. For ease of understanding, this specification provides a schematic diagram of the interaction framework of the driving device charging system, such as... Figure 2 As shown.

[0083] Figure 2 This is a schematic diagram of the interaction framework of a driving equipment charging system provided in this specification.

[0084] During the contract certificate generation process, the customer sends a PCID to the second server. The second server obtains the OEM supply certificate from the storage module PCP of the third server based on the PCID. Then, the second server retrieves the contract data based on the certificate, encrypts the private data, and sends the contract data to the certificate signing module MO CA of the third server. The MO CA issues the contract certificate and sends it to the contract signing module CPS of the third server. The CPS signs the contract data and sends it to the certificate pool CCP of the third server.

[0085] During the installation of the contract certificate, the driving equipment can connect to the charging equipment via the Transport Layer Security (TLS) protocol. The charging equipment requests a contract certificate from the CPO through the communication interface between the charging equipment and the third server. This prompts the CPO to request a contract certificate from the third server's certificate pool, CCP. The CCP then replies with the contract certificate to the CPO, which responds with the contract certificate to the charging equipment's Supplier Equipment Communication Controller (SECC) and issues the contract certificate to the charging equipment for installation.

[0086] For ease of understanding, the following explanation will focus on the charging method for the driving device provided in this manual, from the perspective of the driving device itself. Figure 3 As shown.

[0087] Figure 3 A flowchart illustrating a charging method for a driving device provided in this specification includes the following steps:

[0088] S301: After establishing a charging connection with the charging device, a charging task is performed through the charging device. Based on the charging connection, a data acquisition request is sent to the third server corresponding to the charging device through the charging device. This allows the third server to determine the contract certificate corresponding to the driving device based on the data acquisition request and the binding relationship information between the driving device and the contract certificate. The third server then sends the contract certificate to the driving device through the charging device. The contract certificate is generated by the second server corresponding to the payment service provider during the account binding phase, based on the identification information of the driving device sent by the first server corresponding to the driving device. The binding relationship information is stored locally on the third server after receiving the contract certificate sent by the second server. The identification information is sent by the first server to the second server along with the user's deduction account information based on the binding request sent by the client. The binding request is sent by the client to the first server in response to the binding operation performed by the user on the driving device. The driving device belongs to the user.

[0089] S302: Based on the contract certificate returned by the charging device, a deduction request is sent to the second server, so that the second server determines the deduction account bound to the driving device according to the contract certificate carried in the deduction request and the pre-established correspondence between the account information and the contract certificate, and deducts money based on the deduction account.

[0090] In addition, this specification also provides a method for charging driving equipment using a charging device as the executing entity, such as... Figure 4 As shown.

[0091] Figure 4 This is a schematic diagram of a charging method for a driving device provided in this specification, including the following steps;

[0092] S401: After establishing a charging connection with the driving device, a charging task is performed for the driving device. Furthermore, through the charging connection, the data acquisition request sent by the driving device during charging is forwarded to a third server corresponding to the charging device. This allows the third server to determine the contract certificate corresponding to the driving device based on the data acquisition request and the binding relationship information between the driving device and the contract certificate, and then send the contract certificate to the charging device. The contract certificate is generated by the second server corresponding to the payment service provider during the account binding phase, based on the identification information of the driving device sent by the first server corresponding to the driving device. The binding relationship information is stored locally on the third server after receiving the contract certificate sent by the second server. The identification information is sent by the first server to the second server along with the user's deduction account information based on the binding request sent by the client. The binding request is sent by the client to the first server in response to the binding operation performed by the user on the driving device. The driving device belongs to the user.

[0093] S402: Receive the contract certificate and send the contract certificate to the driving device, so that the driving device sends a deduction request to the second server based on the contract certificate returned by the charging device, and the second server determines the deduction account bound to the driving device according to the contract certificate carried in the deduction request and the pre-established correspondence between the account information and the contract certificate, so as to deduct the payment based on the deduction account.

[0094] In addition, this specification also provides a method for charging a driving device, in which a third server corresponding to the charging device acts as the execution subject, such as... Figure 5 As shown.

[0095] Figure 5 This is a schematic diagram of a charging method for a driving device provided in this specification, including the following steps;

[0096] S501: Receives a data acquisition request sent by the charging device after establishing a charging connection with the driving device.

[0097] S502: Based on the data acquisition request and the binding relationship information between the driving device and the contract certificate, determine the contract certificate corresponding to the driving device. The contract certificate is generated by the second server corresponding to the payment service provider during the account binding phase, based on the identification information of the driving device sent by the first server corresponding to the driving device. The binding relationship information is stored locally on the third server after receiving the contract certificate sent by the second server. The identification information is sent by the first server to the second server along with the user's deduction account information based on the binding request sent by the client. The binding request is sent by the client to the first server in response to the binding operation performed by the user on the driving device. The driving device belongs to the user.

[0098] S503: The contract certificate is sent to the driving device through the charging device, so that the driving device sends a deduction request to the second server based on the contract certificate returned by the charging device, and the second server determines the deduction account bound to the driving device according to the contract certificate carried in the deduction request and the pre-established correspondence between the account information and the contract certificate, so as to deduct the payment based on the deduction account.

[0099] As can be seen from the above methods, this solution can use built-in certificate authentication, avoiding the need to scan a code or swipe a card after establishing a charging connection. By using two certificates, the identity authentication certificate and the contract certificate, information security, identity authentication, and charging settlement can be achieved.

[0100] Compared to traditional plug-in charging, this solution eliminates the need for a cumbersome QR code payment process after plugging in the charger, fundamentally preventing the possibility of user data leakage and making it safer than traditional charging methods.

[0101] Furthermore, because this solution eliminates the need for intermediate QR code scanning, it does not require a display screen or corresponding software module on the charger side. All charging data can be exchanged between the vehicle's infotainment system and the charging station through software upgrades on existing hardware. This allows for cost optimization for the charging station industry.

[0102] In terms of user experience, traditional QR code scanning suffers from recognition issues due to angle and lighting. Users also need to use different apps at different charging stations to complete prepayment or final payment, resulting in a high learning curve. Older users often feel helpless when faced with these problems. This solution fundamentally avoids these inconveniences. Users only need to plug in the charging station; the system handles the rest of the payment, greatly improving the user experience.

[0103] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 3 , Figure 4 or Figure 5 The provided method for charging the driving equipment.

[0104] This instruction manual also provides Figure 6 The one shown corresponds to Figure 3 , Figure 4 or Figure 5 A schematic diagram of the structure of an electronic device. (e.g.) Figure 6 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for the business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above-mentioned functions. Figure 3 , Figure 4 or Figure 5 The described method for charging the driving device. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0105] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0106] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0107] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0108] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0109] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0110] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0111] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0112] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0113] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0114] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0115] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0116] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0117] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0118] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0119] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0120] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A charging system for driving equipment, characterized in that, The driving device charging system includes: a driving device belonging to a user and a first server corresponding to the driving device, a client corresponding to the driving device, a second server corresponding to a payment service provider, a charging device and a third server corresponding to the charging device; The client is used to send a binding request to the first server in response to a binding operation performed by the user on the driving device; The first server is configured to send the user's deduction account information and the identification information corresponding to the driving device to the second server according to the binding request; The second server is used to generate a contract certificate based on the received identification information, establish a correspondence between the account information and the contract certificate, and send the contract certificate to the third server so that the third server can save the binding relationship information between the driving device and the contract certificate. The charging device is used to perform a charging task for the driving device after establishing a charging connection with the driving device, and to send a data acquisition request to the third server through the charging connection. The third server is used to determine the contract certificate corresponding to the driving device based on the data acquisition request sent by the driving device during charging and the binding relationship information, and send the contract certificate to the driving device through the charging device, so that the charging device installs the contract certificate in the driving device based on the charging connection; The driving device is used to send a deduction request to the second server based on the contract certificate returned by the charging device and installed locally on the driving device, so that the second server determines the deduction account bound to the driving device according to the contract certificate carried in the deduction request and the corresponding relationship, and performs deduction based on the deduction account.

2. The driving equipment charging system as described in claim 1, characterized in that, The third server is used to receive the identity certificate of the driving device sent by the first server and store it locally; The charging device is used to forward the identity certificate sent by the driving device to the third server after establishing a charging connection with the driving device, so that the third server can authenticate the identity certificate sent by the driving device according to the locally stored identity certificate, and send a charging command to the charging device after successful authentication, so as to perform the charging task through the charging device.

3. The driving equipment charging system as described in claim 2, characterized in that, The second server is used to query the identity certificate corresponding to the driving device from the third server based on the received identification information, and generate a contract certificate based on the identity certificate.

4. The driving equipment charging system as described in claim 1, characterized in that, The first server is used to receive the V2G root certificate of the manufacturer corresponding to the charging device sent by the third server, and send the V2G root certificate to the driving device for storage; The driving device is used to authenticate the V2G root certificate sent by the charging device based on the locally stored V2G root certificate after establishing a charging connection with the driving device, and to perform the charging task after successful authentication.

5. The driving equipment charging system as described in claim 2, characterized in that, The driving equipment charging system further includes a control terminal, wherein the first server is equipped with a certificate generation module. The control terminal is used to determine the basic certificate data of the driving device, and when a data update instruction is received, to update the basic certificate data to obtain the updated basic certificate data, and to send the updated basic certificate data to the first server. The first server is configured to generate an initial certificate based on the updated basic certificate data through the certificate generation module, and return the initial certificate to the driving device so that the driving device can sign the initial certificate to obtain the identity certificate corresponding to the driving device, and send the identity certificate to the first server.

6. A method for charging a driving device, characterized in that, The method is applied to driving equipment, including: After establishing a charging connection with the charging device, the charging device performs a charging task. Based on the charging connection, the charging device sends a data acquisition request to the third server corresponding to the charging device. The third server determines the contract certificate corresponding to the driving device based on the data acquisition request and the binding relationship information between the driving device and the contract certificate. The third server then sends the contract certificate to the driving device through the charging device, allowing the charging device to install the contract certificate in the driving device based on the charging connection. The contract certificate is generated by the second server corresponding to the payment service provider during the account binding phase based on the identification information of the driving device sent by the first server corresponding to the driving device. The binding relationship information is stored locally on the third server after receiving the contract certificate sent by the second server. The identification information is sent by the first server to the second server along with the user's deduction account information based on the binding request sent by the client. The binding request is sent by the client to the first server in response to the binding operation performed by the user on the driving device. The driving device belongs to the user. Based on the contract certificate returned by the charging device and installed locally on the driving device, a deduction request is sent to the second server, so that the second server determines the deduction account bound to the driving device according to the contract certificate carried in the deduction request and the pre-established correspondence between the account information and the contract certificate, and deducts the payment based on the deduction account.

7. The method as described in claim 6, characterized in that, After establishing a charging connection with the charging device, the charging task is performed through the charging device, specifically including: After establishing a charging connection with the charging device, the V2G root certificate sent by the charging device is authenticated based on the locally stored vehicle-to-network (V2G) root certificate, and the charging task is executed after successful authentication. The V2G root certificate stored locally by the driving device is sent to the driving device by the first server after receiving the V2G root certificate of the manufacturer corresponding to the charging device from the third server.

8. The method as described in claim 6, characterized in that, After establishing a charging connection with the charging device, the charging task is performed through the charging device, specifically including: After establishing a charging connection with the charging device, the driver's identity certificate stored locally is sent to the charging device through the charging connection, so that the charging device can authenticate the identity certificate sent by the driver through the identity certificate of the driver stored locally on the third server, and execute the charging task based on the charging command sent by the third server after successful authentication.

9. A method for charging a driving device, characterized in that, The method is applied to a charging device and includes: After establishing a charging connection with the driving device, a charging task is performed for the driving device. Furthermore, through the charging connection, the data acquisition request sent by the driving device during charging is forwarded to a third server corresponding to the charging device. This allows the third server to determine the contract certificate corresponding to the driving device based on the data acquisition request and the binding relationship information between the driving device and the contract certificate, and then send the contract certificate to the charging device. This allows the charging device to install the contract certificate in the driving device based on the charging connection. The contract certificate is generated by the second server corresponding to the payment service provider during the account binding phase, based on the identification information of the driving device sent by the first server corresponding to the driving device. The binding relationship information is stored locally on the third server after receiving the contract certificate sent by the second server. The identification information is sent by the first server to the second server along with the user's deduction account information based on the binding request sent by the client. The binding request is sent by the client to the first server in response to the binding operation performed by the user on the driving device. The driving device belongs to the user. The system receives the contract certificate and sends it to the driving device, so that the driving device sends a deduction request to the second server based on the contract certificate returned by the charging device and installed locally on the driving device. The second server then determines the deduction account bound to the driving device based on the contract certificate carried in the deduction request and the pre-established correspondence between the account information and the contract certificate, and performs the deduction based on the deduction account.

10. The method as described in claim 9, characterized in that, After establishing a charging connection with the driving device, a charging task for the driving device is performed, specifically including: After establishing a charging connection with the driving device, the system receives the identity certificate sent by the driving device. The identity certificate is sent to the third server so that the third server can authenticate the identity certificate sent by the driving device based on the identity certificate stored locally, and send a charging command to the charging device after successful authentication. The identity certificate stored locally by the third server is the one sent in advance by the first server. Based on the charging command, the charging task is executed.

11. A charging method for a driving device, characterized in that, The method is applied to a third server corresponding to the charging device, including: Receive data acquisition requests sent by the charging device after establishing a charging connection with the driving device; Based on the data acquisition request and the binding relationship information between the driving device and the contract certificate, the contract certificate corresponding to the driving device is determined. The contract certificate is generated by the second server corresponding to the payment service provider during the account binding phase, based on the identification information of the driving device sent by the first server corresponding to the driving device. The binding relationship information is stored locally on the third server after receiving the contract certificate sent by the second server. The identification information is sent by the first server to the second server along with the user's deduction account information based on the binding request sent by the client. The binding request is sent by the client to the first server in response to the binding operation performed by the user on the driving device. The driving device belongs to the user. The contract certificate is sent to the driving device via the charging device, so that the charging device installs the contract certificate in the driving device based on the charging connection. Based on the contract certificate returned by the charging device and installed locally on the driving device, the driving device sends a deduction request to the second server. The second server determines the deduction account bound to the driving device based on the contract certificate carried in the deduction request and the pre-established correspondence between the account information and the contract certificate, so as to deduct the payment based on the deduction account.

12. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 6 to 11.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method described in any one of claims 6 to 11.

Images