Account binding and management method and device, electronic equipment and storage medium

Abstract

The application discloses a kind of account binding and management method, device, electronic equipment and storage medium, the method includes: receiving the binding request sent by vehicle terminal;Binding request includes car machine account identification and application identification;According to application identification, determine application server and the calling rule corresponding to application server;According to calling rule, obtain authorization code from application server, and send authorization code to vehicle terminal and display;In the case where polling application server returns authorization success flag, obtain application account identification from application server;Authorization success flag is generated after application server authorizes through authorization code by mobile terminal;According to car machine account identification and the application account identification, establish the binding relationship between car machine account and application account, bind car machine account and the account of different application, so that when logging in car machine account, each application is synchronously logged in, and when exiting car machine account, each application is synchronously exited.

Description

Technical Field

[0001] This application belongs to the field of vehicle Internet of Things (IoT) technology, specifically relating to an account binding and management method, device, electronic device, and storage medium. Background Technology

[0002] As the automotive cockpit ecosystem continues to expand, in-vehicle infotainment systems are offering users an increasing number of applications and functions. Currently, in-vehicle infotainment systems can integrate various third-party applications to enhance the interactive experience and user convenience of the vehicle's Internet of Things (IoT) in-vehicle system, such as music and shopping applications.

[0003] The vehicle infotainment system account and each third-party application account are independent of each other. Multiple third-party applications involve multiple application accounts. When a user logs into a third-party application on the vehicle infotainment system, they need to enter their username and password for each application separately to complete the login. When a user changes vehicles, they also need to log in to each application individually on the new vehicle. With a large number of applications, logging in one by one is extremely cumbersome and affects login efficiency. Summary of the Invention

[0004] The purpose of this application is to provide an account binding and management method, device, electronic device, and storage medium that adaptively binds the vehicle system account and the accounts of different applications through a cloud server, enabling all applications to log in simultaneously when logging into the vehicle system account and to log out simultaneously when logging out of the vehicle system account, thereby improving operational efficiency.

[0005] In a first aspect, embodiments of this application provide an account binding method, the method comprising: Receive a binding request sent by the vehicle terminal; the binding request includes the vehicle account identifier and the application identifier; Based on the application identifier, determine the application server and the corresponding invocation rules; According to the aforementioned calling rules, the authorization code is obtained from the application server and then sent to the vehicle terminal for display. If the application server returns an authorization success flag during polling, the application account identifier is obtained from the application server; the authorization success flag is generated by the application server after the mobile terminal authorizes the application using the authorization code. A binding relationship is established between the vehicle system account and the application account based on the vehicle system account identifier and the application account identifier.

[0006] Secondly, embodiments of this application provide an account management method, the method comprising: In response to the successful login of the vehicle system account, the binding relationship corresponding to the vehicle system account is obtained from the cloud server; the binding relationship is established by the cloud server according to the account binding method described in the first aspect, and the binding relationship includes an application account and an access token, wherein the access token is used to indicate that the vehicle terminal has the permission to access the application account; The access token and the application account are sent to the corresponding vehicle application, so that the vehicle application can use the access token to call the corresponding application server to log in to the application account; In response to the vehicle system account logging out, a logout notification is sent to the in-vehicle application to cause the in-vehicle application to log out of the application account.

[0007] Thirdly, embodiments of this application provide an account binding device, which includes: The request receiving module is used to receive a binding request sent by the vehicle terminal; the binding request includes the vehicle account identifier and the application identifier; The rule determination module is used to determine the application server and the calling rules corresponding to the application server based on the application identifier; The authorization code acquisition module is used to obtain the authorization code from the application server according to the calling rules, and send the authorization code to the vehicle terminal for display. The identifier acquisition module is used to obtain the application account identifier from the application server when the application server returns an authorization success flag during polling; the authorization success flag is generated by the application server after the mobile terminal authorizes the application account using the authorization code. The relationship establishment module is used to establish a binding relationship between the vehicle system account and the application account based on the vehicle system account identifier and the application account identifier.

[0008] Fourthly, embodiments of this application provide an account management apparatus, the apparatus comprising: The token acquisition module is used to obtain the binding relationship corresponding to the vehicle account from the cloud server in response to the successful login of the vehicle account; the binding relationship is established by the cloud server according to the account binding method in the first aspect, and the binding relationship includes an application account and an access token, and the access token is used to indicate that the vehicle terminal has the permission to access the application account; The login module is used to send the access token and the application account to the corresponding vehicle application, so that the vehicle application can call the corresponding application server to log in to the application account through the access token; The exit module is used to send a logout notification to the in-vehicle application in response to the vehicle account logging out, so that the in-vehicle application logs out of the application account.

[0009] Fifthly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first or second aspect.

[0010] In a sixth aspect, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first or second aspect.

[0011] In this embodiment, all complex interactions with third-party application servers are handled by the cloud server. The in-vehicle terminal only needs to send a binding request and display an authorization code, reducing the development and maintenance costs of the in-vehicle terminal. Furthermore, based on the application identifier, the application server and its corresponding calling rules are determined; according to the calling rules, the authorization code is obtained from the application server. In other words, the cloud server encapsulates the interface differences between different application vendors internally, providing a unified binding process that is adaptable to various application types and highly responsive. Moreover, when a car manufacturer adds a third-party application, it only needs to add rules in the cloud; the in-vehicle terminal does not require an upgrade. In this embodiment, after the cloud server establishes the binding relationship, when a user changes vehicles and logs into the same in-vehicle account, the cloud server can return all bound application information for that in-vehicle account, enabling simultaneous login and logout of both the in-vehicle account and application accounts, improving operational convenience and efficiency. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating the steps of an embodiment of the account binding method of the present invention; Figure 2 This is a schematic diagram of the architecture of an in-vehicle terminal and a cloud server according to the present invention; Figure 3 This is a flowchart illustrating the steps of another embodiment of the account binding method of the present invention; Figure 4 This is a flowchart of the steps for unbinding an account according to the present invention; Figure 5 This is a flowchart illustrating the steps of another embodiment of the account binding method of the present invention; Figure 6This is a flowchart illustrating the steps of another embodiment of the account binding method of the present invention; Figure 7 This is a flowchart illustrating the steps of an embodiment of the account management method of the present invention; Figure 8 This is a flowchart of the account login steps according to the present invention; Figure 9 This is a flowchart of the steps for logging out of an account according to the present invention; Figure 10 This is a structural block diagram of an account binding device according to the present invention; Figure 11 This is a structural block diagram of an account management device according to the present invention; Figure 12 This is a structural block diagram of an electronic device provided by the present invention. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, the first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In embodiments of this invention, the term "multiple" refers to two or more, and other quantifiers are similar.

[0017] Method Implementation Examples Reference Figure 1 The diagram illustrates a flowchart of an embodiment of an account binding method according to the present invention, the method comprising: Step 101: Receive a binding request sent by the vehicle terminal; the binding request includes the vehicle account identifier and the application identifier; Step 102: Determine the application server and the corresponding invocation rules based on the application identifier; Step 103: According to the calling rules, obtain the authorization code from the application server and send the authorization code to the vehicle terminal for display; Step 104: If the application server returns an authorization success flag during polling, obtain the application account identifier from the application server; the authorization success flag is generated by the application server after the mobile terminal authorizes the application using the authorization code. Step 105: Establish a binding relationship between the vehicle system account and the application account based on the vehicle system account identifier and the application account identifier.

[0018] Regarding steps 101 to 105, it should be noted that the account binding method provided in this application embodiment can be applied to cloud servers of the Internet of Vehicles, such as cloud user centers built by car manufacturers.

[0019] The method provided in this application embodiment is applicable to scenarios where different third-party application vendors provide different authorization interfaces and processes. The cloud server performs differentiated adaptation for each application, but shields these differences from the in-vehicle terminal, providing a unified and standardized binding interface. In this application embodiment, the cloud server acts as a unified adaptation layer, pre-configuring the calling rules for different third-party application servers. When the in-vehicle terminal, i.e., the vehicle-mounted terminal, initiates a binding request, the cloud server selects the corresponding calling rule based on the application identifier, interacts with the third-party application server according to the calling rule, completes user authorization confirmation, obtains the application account identifier, and finally establishes the binding relationship between the vehicle-mounted terminal account and the application account. The cloud server encapsulates all differences internally, providing a standardized binding process for the in-vehicle terminal. During the process of establishing the binding relationship, the in-vehicle terminal is responsible for initiating the binding request, displaying the authorization code, and receiving the binding result, without participating in any direct interaction with the third-party application server or being aware of the interface differences between different applications.

[0020] The in-vehicle terminal refers to the vehicle's infotainment system, including the in-vehicle user center module. In this embodiment, the in-vehicle terminal acts as the front end for user interaction, responsible for receiving user operations, sending binding requests, displaying authorization codes, and receiving binding result notifications. The binding request is an instruction sent by the in-vehicle terminal to the cloud server to initiate the binding process. The binding request contains at least two pieces of information: the in-vehicle account identifier and the application identifier. The in-vehicle account identifier is a unique identifier for the user in the vehicle manufacturer's system, such as a mobile phone number, user identifier (ID), or email address, used to distinguish different users. The application identifier is used to uniquely identify third-party applications, such as "netease_music" or "ktv_app".

[0021] Application servers are the backend servers of third-party application providers, such as NetEase Cloud servers and WeChat Open Platform servers. Application servers are responsible for handling authorization, issuing tokens, and providing user information, etc. (See reference...) Figure 2 The diagram illustrates the architecture between the in-vehicle terminal and the cloud server. The user center on the in-vehicle system is used to interact with multiple applications, namely application A, application B, and application N. The user center on the cloud server is used to interact with the cloud servers of multiple applications, namely application servers.

[0022] Invocation rules are a set of pre-configured interaction protocols for a specific application server. This protocol can be a Hypertext Transfer Protocol (HTTP) request or other protocols. For example, invocation rules include the interface address and request parameter format for obtaining the authorization code, the interface address and polling interval for querying the authorization status, and the interface address and parameter mapping for obtaining the application account identifier. It should be noted that the cloud server internally stores multiple mappings between application identifiers and invocation rules. Upon receiving a binding request, it uses the application identifier in the request as the key to look up the corresponding invocation rule. The cloud server then sends a network request to the corresponding application server according to the invocation rule, and the application server returns the authorization code. Specific details vary depending on the application, but are uniformly encapsulated in the cloud.

[0023] An authorization code is a temporary credential generated by the application server for this binding session, typically appearing as a QR code, short link, or string of numbers. After the user scans or enters the authorization code using a mobile device, the application server can confirm the user's authorization intent, such as when the user scans the code using a music app on their phone.

[0024] Polling refers to the cloud server periodically sending query requests to the application server's authorization status interface to check whether the user has completed authorization. Polling parameters include at least: polling interval, timeout, and termination conditions. After sending the authorization code to the vehicle terminal, the cloud server starts a timer to repeatedly call the application server's status query interface at preset intervals according to the calling rules. Each request carries an identifier for the current session, and the application server returns the corresponding result based on its internally recorded authorization status.

[0025] The authorization success flag is a status value generated by the application server after the user completes the QR code authorization, such as status="authorized" or code=200. The authorization success flag indicates that the user has agreed to the authorization. For example, after a user scans the authorization code on the vehicle's infotainment system with their mobile application (APP), the APP sends an authorization confirmation message to the application server. After verifying the user's identity and confirmation intent, the application server updates the session status to authorized. The cloud server obtains this status through a polling interface, thus receiving the authorization success flag.

[0026] An application account identifier is a unique identifier for a user within a third-party application, such as NetEase Cloud's user_id or WeChat's openid. After obtaining the application account identifier, the cloud server associates it with the vehicle's account identifier, forming a binding relationship. Specifically, after polling for a successful authorization flag, the cloud server requests user information from the application server according to the pre-defined user information retrieval interface in the calling rules, and the application server returns the user information.

[0027] After obtaining the application account identifier, the cloud server associates it with the vehicle-mounted account identifier carried in the binding request and stores it in the database. Simultaneously, the access token and refresh token obtained in this transaction can also be stored for subsequent automatic refresh and simultaneous login. The binding relationship refers to the one-to-one correspondence between the vehicle-mounted account and the third-party application account. The binding relationship includes information such as the vehicle-mounted account identifier, application identifier, application account identifier, access token, and refresh token. For example, the binding relationship can take the form of a database record, a JavaScript Object Notation (JSON) object, or any data structure that can be persistently stored. It should be noted that the binding relationship is stored on the cloud server for subsequent querying by the in-vehicle terminal when performing simultaneous login and logout of the application.

[0028] It should be noted that upon initial binding, the in-vehicle terminal's cockpit interface will display a user privacy agreement regarding account binding and simultaneous login / logout. Only after receiving the user's consent will the in-vehicle terminal send a binding request to the cloud server.

[0029] In this embodiment, the cloud server performs adaptation processing for different application identifiers, that is, it pre-configures different calling rules. The calling rules can adapt to the interface differences of different application vendors. For example, some applications require a QR code application first, while others require an authorization code; some use JSON format, while others use Extensible Markup Language (XML); some use ` / poll` for polling, while others use ` / status`. The cloud dynamically selects the calling rule at runtime and executes the binding process according to the rule. Regardless of how the calling rules change, the interface and behavior exposed by the cloud server to the vehicle-mounted terminal are consistent. When the vehicle-mounted terminal initiates a binding request, it provides the vehicle-mounted account identifier and application identifier. All subsequent differentiated processing is completed internally in the cloud. The vehicle-mounted terminal sees a unified authorization code display and a unified binding result notification. This means that when adding or updating third-party applications, only the cloud server configuration needs to be modified or new calling rules added; the vehicle-mounted terminal requires no upgrades or modifications, achieving a seamless integration effect.

[0030] Reference Figure 3 The flowchart illustrates another embodiment of the account binding method of the present invention, the method comprising: Step 201: Receive the binding request sent by the vehicle terminal; the binding request includes the vehicle account identifier and the application identifier.

[0031] Step 201 can be referred to step 101 above, and will not be repeated here.

[0032] The cloud server pre-stores multiple sets of association relationships.

[0033] Step 202: Among multiple sets of associations, find the target association that matches the application identifier; Step 203: Determine the application server and the calling rule in the target association relationship as the application server and the calling rule corresponding to the application identifier.

[0034] For steps 202 and 203, each set of associations is a set of mapping entries pre-stored in the cloud server. Each entry binds the application identifier to the application server and the calling rules. For example, the specific form of each set of associations can be a configuration record or a branch logic, used to determine the docking method between the cloud server and the application server.

[0035] Multiple sets of associations refer to a collection of associations stored on the cloud server that support multiple third-party in-vehicle applications. For example: the application identifier "netease" corresponds to the NetEase Cloud server and its calling rules; the application identifier "ktv" corresponds to the KTV server and its calling rules; and the application identifier "wechat" corresponds to the WeChat Open Platform and its calling rules. The target association is a single association matched from these multiple sets of associations based on the application identifier in the current binding request. The calling rules are a set of predefined interaction protocols, including: how to obtain the authorization code, how to poll the authorization status, and how to exchange for the application account identifier, etc.

[0036] After receiving a binding request, the cloud server needs to locate the corresponding application server and invocation rules based on the application identifier in the request. For example, the cloud server maintains a configuration file that records the application server address and invocation rules corresponding to each application identifier in key-value pairs or a list. The cloud server reads the configuration file, indexes the corresponding entry based on the application identifier, and retrieves the application server and invocation rules from that entry as the application server and invocation rules. If the application identifier does not exist in the configuration file, an error is returned, indicating that the cloud server does not support the application. Alternatively, the association can be implemented using program branches. For example, in the cloud server's code, the processing logic corresponding to each application identifier can be hard-coded through conditional statements. The program enters the corresponding branch based on the application identifier, directly specifying the application server and invocation rule objects within the branch. Alternatively, the application server address can be stored in a configuration file, while the invocation rules are implemented through code branches.

[0037] In this embodiment, by pre-storing multiple sets of association relationships, binding is performed using preset rules within these relationships when establishing a binding relationship, making it adaptable to various applications. If binding logic for third-party in-vehicle applications is added, only one set of association relationships needs to be added; no modification to the vehicle's processing logic is required, resulting in high scalability. Differences between different applications are encapsulated within their respective association relationships, with a unified interface provided to the cloud. The matching process is simple and extremely time-efficient, improving operational efficiency and user experience.

[0038] The calling rules include: the interface address, the request parameter format, and the field name of the authorization code.

[0039] Step 204: Send a request with the requested parameter format to the application server through the interface address; Step 205: Receive the response data returned by the application server, and parse the authorization code from the response data according to the field names.

[0040] Regarding steps 204 and 205, in this embodiment, the invocation rules include: the interface address, the request parameter format, and the field names in the response data. The interface address refers to the Uniform Resource Locator (URL) on the application server specifically used to generate authorization codes, such as https: / / api.example.com / oauth / qrcode.

[0041] The request parameter format indicates the name and value organization of the parameters to be sent when sending a request to the interface indicated by the above interface address. For example, it specifies whether the parameter name or value should be placed in the URL query string or transmitted in JSON format in the HTTP request body. The response data returned by the application server is usually in JSON or XML format, where a specific field stores the authorization code. The calling rules pre-specify the name or extraction path of this field.

[0042] For example, the interface address is a complete network address, including the protocol, hostname, port, and path. For instance, https: / / api.music.163.com / openapi / qrcode / get, the cloud server directly initiates a network request based on the interface address. The response data is the HTTP response returned by the application server to the cloud server, typically containing response headers and a response body. The response body carries the authorization code and other auxiliary information, such as session identifier and expiration time. In the response data, the field name refers to the key or path where the authorization code is stored. For example, in a JSON response: {"data": {"qr_code": "https: / / ..."}}, the field name could be data.qr_code.

[0043] After determining the target application server and the corresponding invocation rules, the cloud server generates a request conforming to the transmission protocol specifications based on the interface address and request parameter format requirements specified in the invocation rules. The cloud server then sends the request to the interface address over the network. The purpose of the request is to notify the application server to generate an authorization code for this binding session. Upon receiving the request, the application server generates a unique, temporary authorization code for the session, typically represented as a QR code text, short link, or numeric string, and encapsulates it in the response data, returning it to the cloud server. Upon receiving the response, the cloud server obtains the response body. The cloud server extracts the authorization code from the response data according to the predefined field names in the invocation rules. For example, if the response is in JSON format, the cloud server parses the JSON tree and extracts the corresponding string based on the field path. The extracted authorization code is temporarily stored in the context of this binding session, ready to be sent to the vehicle terminal.

[0044] In this embodiment, the interfaces and parameter formats for obtaining authorization codes differ across application servers. Requests are constructed and responses are parsed according to the calling rules. Standardizing the binding process simplifies the development process, requiring fewer parameter adjustments for different application servers, such as interface addresses, parameter formats, and field names. Furthermore, it supports dynamic expansion, facilitating the addition of binding processes for other application types.

[0045] Step 206: If the application server returns an authorization success flag during polling, obtain the application account identifier from the application server; the authorization success flag is generated by the application server after the mobile terminal authorizes the application using the authorization code.

[0046] Step 206 can be referred to step 104 above, and will not be repeated here.

[0047] Step 207: Establish a binding relationship between the vehicle system account and the application account based on the vehicle system account identifier and the application account identifier.

[0048] Step 207 can be referred to step 105 above, and will not be repeated here.

[0049] Step 208: Receive the unbinding request sent by the vehicle terminal; the unbinding request includes the vehicle account identifier and the application account identifier; Step 209: Determine the binding relationship corresponding to the application account identifier based on the vehicle system account identifier and the application account identifier; Step 210: Unbind the binding relationship and send a successful unbinding notification to the vehicle terminal.

[0050] For steps 208 to 210, the unbinding request is an instruction sent by the in-vehicle terminal to the cloud server, used to request the removal of the binding relationship between a specific application account and the current vehicle system account. The unbinding request includes the vehicle system account identifier and the application account identifier.

[0051] A binding relationship refers to the association record previously established by the cloud server between the vehicle system account and the application account. Each binding relationship typically includes: vehicle system account identifier, application identifier, application account identifier, access token, refresh token, creation time, etc., and the binding relationship is stored in the cloud server's database.

[0052] The cloud server uses the vehicle system account identifier and application account identifier provided in the unbinding request to match and search the stored binding relationship dataset to locate the binding record. The specific method for unbinding can be to perform a deletion operation, removing the binding record from the cloud server's storage. Simultaneously, access tokens, refresh tokens, and other data associated with the binding relationship can also be deleted to avoid data residue.

[0053] A successful unbinding notification is a confirmation message sent by the cloud server to the in-vehicle terminal after the unbinding operation is completed. Upon receiving the notification, the in-vehicle terminal can clear the corresponding local cache and notify the relevant in-vehicle applications to log out, thus ensuring a timely update of the user interface.

[0054] In this embodiment, the cloud server acts as the server, providing a unified unbinding interface. When a user clicks the unbinding button on the interactive interface provided by the in-vehicle terminal, the in-vehicle terminal constructs a request and sends it to the unbinding interface of the cloud server. Upon receiving the unbinding request, the cloud server extracts the vehicle account identifier and application account identifier from the request parameters. Then, the cloud server performs a query operation in its relational database. It determines the binding relationship record in the database using the combination of the vehicle account identifier and the application account identifier. If the query result is empty, the cloud server can directly return an error message indicating that the binding relationship does not exist; if a binding relationship record is found, it is deleted from the cloud server's database. After the deletion operation is completed, the cloud server constructs an unbinding success notification and returns this notification as a response to the in-vehicle terminal. This notification informs the in-vehicle terminal that the unbinding is complete, allowing the terminal to refresh its interface, for example, changing the bound status of the corresponding application to unbound and immediately logging out of the application, achieving a user experience of immediate logout upon unbinding.

[0055] For example, refer to Figure 4 The flowchart illustrates the steps of unbinding an account according to the present invention.

[0056] A11. The user unbinds the account within the application. A12. Select an application to unbind from the vehicle's infotainment system; A13. Disconnect the vehicle system account and application account from the cloud.

[0057] It's important to clarify that the vehicle infotainment user center refers to the user center on the in-vehicle terminal. Specifically, the unbinding operation means that the user selects options such as "unbind" or "cancel account association" through the settings page of a specific application or the vehicle infotainment account management interface on the vehicle screen. For example, the user clicks to enter the vehicle infotainment account center or application management interface and sees a list of bound applications, such as "NetEase Cloud Music - Bound". The user clicks the "Unbind" button next to an application or finds the "Unbind Vehicle Account" option in the application's function menu. After the user initiates the unbinding operation, the vehicle infotainment system captures the user's unbinding intention, determines the specific application to be unbound, and then the vehicle infotainment user center sends an unbinding request to the cloud server.

[0058] The vehicle infotainment system's user center constructs and sends an unbinding request to the cloud server based on the specific application selected by the user. For example, the user center extracts the application identifier and application account identifier corresponding to the user's selected application, as well as the current vehicle infotainment system account identifier, from the locally stored list of binding information. The user center encapsulates this information into a request, targeting the unified unbinding interface provided by the cloud server. After sending the request, the vehicle infotainment system enters a waiting state, awaiting the unbinding result from the cloud. Upon receiving the unbinding request, the cloud server performs a deletion operation, completely removing the binding relationship and related data between the vehicle infotainment system account and the application account. For example, the cloud server executes a database deletion command, removing the binding record corresponding to the binding relationship. Simultaneously, to ensure thorough data cleanup, it also deletes the access token and refresh token associated with this binding relationship. The cloud server returns a successful unbinding notification to the vehicle infotainment system; if the unbinding fails due to a non-existent record or other reasons, it returns the corresponding error code. After successful unbinding, the cloud user center no longer considers the application account as an associated account of the current vehicle infotainment system account. In the future, when the user logs into the vehicle infotainment system account, the binding information list returned by the cloud will no longer contain this application, so the vehicle infotainment system will no longer attempt automatic login. If the vehicle's infotainment system is still logged in and the application is running, after the cloud returns a successful unbinding notification, the vehicle's user center can clear the application's access token from the local cache and send a logout notification to the application.

[0059] In this embodiment, unbinding is essentially the reverse operation of the binding process. It involves creating an association and storing a token for subsequent automatic login. Deleting the association and token prevents the application from automatically logging in. The unbinding process can be triggered by the in-vehicle terminal, a cloud-based administrator, or a security policy. When unbinding occurs on the in-vehicle terminal, a notification is sent to the cloud upon completion. This embodiment provides users with a clear unbinding entry point and operational feedback, simplifying the process and improving efficiency and user experience. Timely deletion of unnecessary binding data and tokens reduces storage usage and prevents token abuse.

[0060] In summary, the account binding method provided in this application uses the cloud as an intermediate layer to encapsulate differentiated processing while unifying the logic on the vehicle-mounted system. When adding a new application, only the calling rules need to be configured in the cloud, improving scalability, and the vehicle-mounted system can seamlessly obtain the binding capability of the new application. Tokens are uniformly stored and refreshed in the cloud, and the vehicle-mounted system only holds short-term valid access tokens, which are not persistent, reducing the risk of leakage. The binding relationship is stored in the cloud, and after the user changes vehicles or restores the same vehicle to factory settings, logging back into the vehicle-mounted system account will automatically restore all application bindings without the need for reauthorization.

[0061] Reference Figure 5 The flowchart illustrates another embodiment of the account binding method of the present invention, the method comprising: B11. User initiates binding; B12. The vehicle terminal, carrying the vehicle owner's identification, initiates a binding request; B13. Obtain the login QR code from the cloud server; B14. The application server returns a login QR code; B15. User scans QR code to log in and confirm; B16. The vehicle terminal initiates a polling process; B17. Check the QR code status on the cloud server; B18. The application server returns an access token and an update token; B19. Query user information on the cloud server; B20, The application server returns the user identifier; B21. Cloud server binding and recording; B22. The cloud server shows that the binding was successful.

[0062] For example, this application embodiment is used to establish a binding relationship between a music software account and a vehicle infotainment system account. Specifically, the user clicks the "Bind Music Software" button on the vehicle infotainment system interface to trigger the binding process, such as NetEase Cloud Music. The vehicle infotainment system user center collects the identifier of the currently logged-in vehicle infotainment system account and the application identifier of the selected application, constructs a binding request, and sends it to the cloud server. Based on the application identifier and according to the pre-configured calling rules, the cloud server sends a request to the NetEase Cloud server's QR code acquisition interface to request the QR code data for this login session. The NetEase Cloud server generates a temporarily valid QR code and returns it to the cloud server, which then forwards the QR code to the vehicle terminal. For example, the interface for obtaining the login QR code is: / openapi / music / basic / user / oauth2 / qrcodekey / get / v2, https: / / developer.music.163.com / st / developer / document?docId=ad4a9e6cd5f34bbf9bd631109645ee40.

[0063] After seeing the QR code on the car's infotainment screen, the user scans it using the NetEase Cloud Music app on their mobile phone. The app sends authorization confirmation information to the NetEase Cloud Music server, and the user clicks to confirm, completing the authorization. The car's user terminal then periodically queries the cloud server to confirm whether the binding is complete. For example, the interface for checking the QR code status is: / openapi / music / basic / oauth2 / device / login / qrcode / get, https: / / developer.music.163.com / st / developer / document?docId=75d457cb78594874a342310500b853f63.

[0064] After receiving the polling request from the vehicle's infotainment system, the cloud server calls the QR code status interface of NetEase Cloud Server to check whether the user has scanned and confirmed the code. When NetEase Cloud Server detects that the user has authorized the transaction, it returns an authorization code. The cloud server uses the authorization code to obtain an access token and a refresh token. Using the obtained access token, the cloud server calls the user information interface of NetEase Cloud Server to request the user's unique identifier (user_id) and nickname, among other basic information. After verifying the token's validity, NetEase Cloud Server returns the user's unique identifier and other information. For example, the interface for obtaining basic user information is: / openapi / music / basic / user / profile / get / v2, https: / / developer.music.163.com / st / developer / document?docId=56615bc1d3cd4289bd481fe7a02eeb6c.

[0065] The cloud server binds the vehicle's account identifier with the acquired application user identifier, and simultaneously stores access tokens, refresh tokens, and other data in the database. The cloud server sends a successful binding notification to the vehicle terminal, and the vehicle's interface displays a message indicating that binding is complete. The user can then automatically log in to the application immediately using the access token as needed. The cloud server can also periodically update the access token using a refresh token. For example, the interface for refreshing the AccessToken using RefreshToken is: / openapi / music / basic / user / oauth2 / token / refresh / v2, https: / / developer.music.163.com / st / developer / document?docId=74a40419a7a444d98c88a33a023624ed In this embodiment, by pre-establishing a binding relationship between the music software account and the host account, the binding relationship can be retrieved from the cloud server during subsequent login to the vehicle's infotainment system. Then, based on the access token and application account carried in the binding relationship, the user can automatically log in to the music software. This eliminates the need for re-authorization and entering a username and password, improving the convenience and efficiency of logging into the music software.

[0066] Reference Figure 6 The flowchart illustrates another embodiment of the account binding method of the present invention, the method comprising: C11, User Use; C12, Vehicle terminal login; C13. Cloud server requests authorization code; C14. The application server verifies the validity of the request; C15. The cloud server returns the authorization code; C16. The cloud server returns the generated login QR code; C17. The cloud server polls for the QR code scanning status. C18. User logs in by scanning QR code; C19. The application server obtains the encoding; C20. Application server verifies the encoding and authorizes the application. C21. Application server authorization successful; cloud server polling for authorization success flag; C22. Obtain an access token from the cloud server; C23. The application server returns information such as access token and account identifier; C24. Cloud server account binding and storage update token; C25. Successful login to the vehicle terminal.

[0067] For example, this application embodiment is used to establish a binding relationship between a video application software account and a vehicle-mounted system account, such as iQiyi. Here, the vehicle-mounted terminal can also be referred to as a third-party front-end, the cloud server as a third-party back-end, the application server as an open platform back-end, and the mobile terminal as an open platform front-end. Specifically, the user opens the binding / login interface of the video application on the vehicle-mounted system and clicks "Bind Account." The vehicle-mounted system user center checks if the current vehicle-mounted system account is logged in, obtains the vehicle-mounted system account identifier, and prepares to initiate a binding request; if not logged in, it first guides the user to log in.

[0068] The in-vehicle terminal sends a binding request to the cloud server. The cloud server, based on pre-configured calling rules, requests an authorization code ( / light_qr_code) from the video application server. Upon receiving the authorization code request, the video application server verifies it, checking for tampering with the signature and verifying the validity of the application's identity. It also checks for completeness and consistency of necessary parameters to confirm the application's authorization. Only after all verifications are successful does the application server generate and return the authorization codes qr_sig and qr_code. The cloud server uses the authorization code to construct a login QR code containing the session identifier and displays it to the in-vehicle terminal. The cloud server then periodically calls the application server's status query interface to check if the user has scanned the code and confirmed authorization. The user scans the QR code on the in-vehicle screen using their mobile video app. The app sends the scan result and user confirmation information to the video application server. Upon receiving the authorization confirmation message from the mobile app, the application server parses the user's identity and session identifier, confirming the user's authorization. The application server verifies the code sent from the mobile app, checking its validity and the user's login credentials. If verification is successful, it generates a successful authorization flag, such as `auth_code`. When the cloud server receives this `auth_code` during polling, it confirms successful user authorization.

[0069] The cloud server, carrying the auth_code, calls the application server's token exchange interface to request an access_token and a refresh_token. The application server returns the access token, refresh token, and the user's account identifier (such as user_id, openid, etc.). The cloud server establishes a binding relationship between the vehicle's account identifier and the application's account identifier, and stores the access token and refresh token in the database for subsequent automatic login and token refresh. The cloud server returns a binding success notification to the in-vehicle terminal. Upon receiving this notification, the in-vehicle terminal can immediately use the access token to automatically log in to the video application, and the user interface will display that the connection is complete.

[0070] In this embodiment, by pre-establishing a binding relationship between the video software account and the host account, the binding relationship can be retrieved from the cloud server during subsequent login to the vehicle's infotainment system. Then, based on the access token and application account carried in the binding relationship, the user can automatically log in to the video software. No further authorization or password input is required, improving the convenience and efficiency of logging into the music software. Furthermore, during the authorization process, the application server verifies the binding request and user authorization, ensuring the security of establishing the binding relationship.

[0071] Reference Figure 7 The diagram illustrates a flowchart of an embodiment of an account management method according to the present invention, the method comprising: Step 301: In response to the successful login of the vehicle system account, obtain the binding relationship corresponding to the vehicle system account from the cloud server; the binding relationship is established by the cloud server according to the account binding method described above, and the binding relationship includes an application account and an access token, the access token being used to indicate that the vehicle terminal has the permission to access the application account; Step 302: Send the access token and the application account to the corresponding vehicle application, so that the vehicle application can use the access token to call the corresponding application server to log in to the application account; Step 303: In response to the vehicle system account logging out, send a logout notification to the vehicle application to make the vehicle application log out of the application account.

[0072] For steps 301 to 303, the cloud server stores the binding relationships between the vehicle infotainment account and multiple third-party in-vehicle application accounts, as well as the corresponding access tokens. The method provided in this application embodiment is applied to the in-vehicle terminal, i.e., the vehicle infotainment user center, and is responsible for actively or passively distributing access tokens to the corresponding in-vehicle applications when the vehicle infotainment account status changes, thus uniformly controlling login and logout behavior. It fully utilizes the binding relationships stored on the cloud server, avoiding duplicate authorization by users and improving ease of use and security.

[0073] Successful login to the vehicle infotainment system means that the user enters their account password or completes identity authentication through biometrics on the vehicle infotainment system, and the vehicle infotainment user center obtains the currently logged-in user's identifier. Obtaining the binding relationship from the cloud server means that the vehicle infotainment user center sends a query request to the cloud server, carrying the current vehicle infotainment system account identifier. The cloud server returns information on all third-party in-vehicle applications bound to that account, including the application account identifier and corresponding access token for each application.

[0074] The binding relationship refers to the data records pre-established and stored on the cloud server using the aforementioned binding methods. These records include the vehicle infotainment system account identifier, application identifier, application account identifier, access token, refresh token, and expiration time. The access token is a short-term valid string credential used by in-vehicle applications to prove user authorization when calling third-party application server APIs. After obtaining the access token, the vehicle infotainment system can directly pass it to the in-vehicle application, which then uses this token to access the application server and complete the login process. Both the access token and refresh token are periodically refreshed and extended; for example, the access token expires in 7 days, and the refresh token expires in 20 days.

[0075] In-vehicle applications are third-party applications such as music and video applications that run on the vehicle's infotainment system. These applications have been integrated with the software development kit (SDK) of the vehicle's infotainment system user center or communicate with the user center through system interfaces.

[0076] Calling the corresponding application server refers to the in-vehicle application obtaining an access token, placing it in the HTTP request header, and initiating a business request to the application server. Once the application server verifies the token's validity, it considers the user logged in. Logging out of the vehicle's account refers to the user actively clicking the logout button, or the vehicle automatically logging out due to security policies. The vehicle's user center clears the local session state and needs to notify all in-vehicle applications to log out. The logout notification refers to the vehicle's user center sending a command via inter-process communication to all running in-vehicle applications, indicating that the current vehicle account has logged out. Upon receiving the command, the application clears its local user state, stops background services requiring login, and switches its interface to a logged-out state.

[0077] For example, the vehicle infotainment system user center constructs a query request, including the current vehicle infotainment system account identifier, and sends a request to the cloud server's interface for obtaining binding relationships. The cloud server retrieves all bound application records from the database based on the vehicle infotainment system account identifier and returns a list. The vehicle infotainment system user center receives and parses this list, temporarily storing it in memory. The vehicle infotainment system user center iterates through each entry in the list, finding the corresponding application package name or process identifier on the vehicle infotainment system based on the application identifier. It then sends an access token and application account to the application through the operating system's inter-process communication mechanism; this can be done through active push or passive response.

[0078] When a user clicks the logout button or the system triggers a logout event, a logout command is sent to all currently running in-vehicle applications. Upon receiving the command, the application clears its internally stored tokens and user information, stops background services requiring a login state, and redirects to the non-login interface. This ensures that all associated third-party applications are simultaneously logged out after the in-vehicle account is logged out, preventing privacy leaks and ensuring information security.

[0079] In this embodiment, when logging into the vehicle infotainment system account, all bound applications automatically come online; when logging out of the vehicle infotainment system account, all applications simultaneously go offline. This avoids long-term storage of tokens locally on the vehicle infotainment system, as the latest token is retrieved from the cloud in real time each time the account is logged in; and the local application state is forcibly cleared upon logout. The vehicle infotainment system is only responsible for distribution and notification; the addition, deletion, and modification of binding relationships are entirely managed by the cloud. Even after changing vehicles, logging into the same account will still automatically log into all applications, improving operational efficiency and convenience.

[0080] Optionally, step 302 may specifically include the following sub-steps: Sub-step 3021: Upon receiving a query request from the vehicle application, find the corresponding access token and application account in the query request, and return the found access token and application account to the vehicle application. Sub-step 3032: Determine the in-vehicle application based on the application identifier in the binding relationship, and send the access token to the in-vehicle application.

[0081] Regarding sub-steps 3021 to 3032, in this embodiment, when the in-vehicle application starts up or requires login, it proactively initiates a request to the vehicle infotainment user center. This request carries at least the application identifier and may also carry the request type. The vehicle infotainment user center internally maintains an in-memory data structure, such as a hash table, where the key is the application identifier and the value is the binding information corresponding to the application. Upon receiving a query request, it quickly searches the hash table using the application identifier in the request as the key. The found access token and application account are encapsulated into response data and returned to the in-vehicle application that initiated the request. If the search fails, for example, if the application is not yet bound, an empty string or an error code is returned.

[0082] After successful login with the vehicle infotainment system account, the user center retrieves the binding relationship list from the cloud server and temporarily stores all entries in the list in a memory cache. When a vehicle application starts, it sends a query request to the user center via its integrated SDK. Upon receiving the request, the user center searches the cache based on the application identifier: if found, it retrieves the application account and access token, constructs a response, and returns it. If not found, it returns an unbound status code. After receiving the response, if the vehicle application has obtained a token, it directly uses the token to call its application server to complete the login; if not bound, it displays a binding guide interface. Through this passive response method, the user center does not need to track the application's startup status. Applications installed or started after login can still function normally. The user center does not need to actively wake up applications that are not currently running, saving resources.

[0083] Alternatively, after successful login with the vehicle infotainment account, the vehicle infotainment user center retrieves a list of binding relationships from the cloud, iterates through the list, and for each application identifier, obtains the corresponding application package name or process status through system services. If the application is already installed, a data packet containing the application account and access token is constructed and actively sent to the target application. If the application has not yet started, the token can be temporarily stored and sent after the application starts, or it can be sent directly. Upon receiving the pushed token, the in-vehicle application immediately uses the token to log in without actively querying it. Through proactive push, the vehicle infotainment user center controls the distribution timing, while applications passively receive the token. After the vehicle infotainment account is logged in, all installed applications can quickly complete the login process, and users do not need to wait when opening applications, improving login efficiency. Through these two flexible distribution methods, the vehicle infotainment user center can reliably deliver access tokens and application accounts to various in-vehicle applications, ensuring smooth implementation of the simultaneous login function. At the same time, different in-vehicle applications can adopt the method most suitable for their own startup strategy to obtain the token, thereby optimizing user experience and system resource consumption.

[0084] In this embodiment, some applications start automatically with the system, while others only launch after the user clicks. Active push notifications allow automatically launched applications to log in immediately; passive responses allow later-launched applications to also obtain tokens. These two methods complement each other, covering all scenarios. Active push notifications are executed only once upon successful login, while passive responses are triggered only when the application needs them, avoiding frequent and useless interactions between the vehicle system and applications. For frequently used applications, active push notifications enable immediate login upon opening, improving response speed; for less frequently used applications, passive responses avoid wasting resources.

[0085] Reference Figure 8 The flowchart illustrates the steps of account login according to the present invention. D11. Obtain the list of bound applications from the vehicle's infotainment system; D21. The cloud returns the binding relationship and token information; D22. The vehicle's infotainment system records the binding relationship and token information; D23. Use the application to query the application's account and token information; D24. Vehicle-to-vehicle synchronization account and token information; D25. Application API call; D26. The cloud refreshes the token when it expires; D27. Apply cloud refresh token.

[0086] In this embodiment, after successfully logging into the vehicle infotainment system account, the vehicle infotainment user center immediately sends a request to the cloud server to obtain a list of all third-party applications currently bound to the vehicle infotainment account. The cloud server retrieves all binding records from the database based on the vehicle infotainment account identifier and packages the application identifier, application account identifier, access token, and other information from each record, returning them to the vehicle infotainment system. The vehicle infotainment user center receives the data returned from the cloud and temporarily stores it in memory. The vehicle infotainment system can then distribute tokens to each application based on the binding record information.

[0087] When an in-vehicle application starts, it sends a query request to the vehicle's user center, including its application identifier. Upon receiving the query request, the user center retrieves the corresponding binding information from its local cache based on the application identifier and returns the application account identifier and access token to the application. If the application is not yet bound, it returns an empty value. After obtaining the access token, the in-vehicle application includes it in the request header and calls its own application server interface. Once the application server verifies the token's validity, it returns the business data, and the application completes the login process.

[0088] It's important to note that the cloud server has a scheduled task or check mechanism that periodically scans the expiration dates of stored access tokens. When a token is about to expire, for example, if its remaining validity is less than 7 days, the cloud uses the refresh token associated with that token to send a refresh request to the corresponding application server, obtaining a new access token and updating the database. Upon receiving the refresh request from the cloud, the application server verifies the validity of the refresh token, generates a new access token, and returns it to the cloud. The cloud then stores the new token and can choose to push it to the vehicle's infotainment system or have the system retrieve it for the next query.

[0089] In this embodiment, a binding relationship is pre-established between the vehicle system account and various application accounts. When logging into the vehicle system account, the binding relationship is retrieved from the cloud. The access token and application account carried in the binding relationship are sent to each bound application via active push or passive response, enabling the application to automatically log in. This achieves the effect of simultaneous login of the vehicle system account and application accounts, simplifying the login process and improving its efficiency.

[0090] Reference Figure 9 The flowchart illustrates the steps of account logout according to the present invention. E11. User logs out of vehicle infotainment account; E12, In-vehicle system notification to log out of accounts in all applications; E13. Log out of the application.

[0091] In this embodiment, the user's specific action to log out of the vehicle infotainment system account can be clicking the logout button on the vehicle infotainment interface, or issuing a logout command via voice, physical button, or other means. The vehicle infotainment system user center captures this event and prepares to execute the logout process. After receiving the logout command, the vehicle infotainment system user center clears the local cache, that is, deletes the list of binding relationships and all access tokens stored in memory to ensure that tokens cannot be distributed subsequently. A logout notification is sent, that is, a logout command is sent to all currently running in-vehicle applications on the vehicle infotainment system through the inter-process communication mechanism of the operating system. Applications that are not running can be left unprocessed. When they are launched again, since the vehicle infotainment system user center no longer has a valid token, the application will not be able to obtain a token and will naturally be in an unlogged-in state.

[0092] Upon receiving a logout notification from the vehicle's user center, each in-vehicle application clears its local state, deleting user information, access tokens, session data, and other data stored within the application. It stops background services, terminating all background tasks requiring a login state, such as music playback, data synchronization, and push notifications. The application's user interface is redirected to an logged-out state, and a notification may be sent to the application server. If the application is performing an operation such as payment or playback, a prompt message "Account logged out, please log in again" may appear before exiting to prevent data errors or user experience issues.

[0093] In this embodiment, the unbinding operation is the reverse of establishing a binding relationship. When the vehicle system account logs out, a logout notification is simultaneously sent to the application account that is bound to the vehicle system account. Upon receiving the logout notification, each application logs out from its application account, achieving the effect of simultaneous logout of the vehicle system account and the application account. This prevents the leakage of application information after the user leaves the vehicle and improves the security of application operation information and personal information.

[0094] Device Examples Reference Figure 10 The diagram illustrates a logic block diagram of an account binding device according to an embodiment of the present invention. The device may include: The request receiving module 401 is used to receive a binding request sent by the vehicle terminal; the binding request includes the vehicle account identifier and the application identifier; The rule determination module 402 is used to determine the application server and the calling rules corresponding to the application server based on the application identifier; The authorization code acquisition module 403 is used to acquire the authorization code from the application server according to the calling rules, and send the authorization code to the vehicle terminal for display. The identifier acquisition module 404 is used to obtain the application account identifier from the application server when the application server returns an authorization success flag during polling; the authorization success flag is generated by the application server after the mobile terminal authorizes the application using the authorization code. The relationship establishment module 405 is used to establish a binding relationship between the vehicle system account and the application account based on the vehicle system account identifier and the application account identifier.

[0095] Optionally, the cloud server pre-stores multiple sets of association relationships, each set of association relationships corresponding to an application identifier, as well as the application server and invocation rules corresponding to the application identifier; the rule determination module includes: The relationship determination module is used to find the target relationship that matches the application identifier among multiple sets of relationship relationships; The rule determination submodule is used to determine the application server and the calling rule in the target association relationship as the application server and the calling rule corresponding to the application identifier.

[0096] Optionally, the invocation rules include: the interface address, the request parameter format, and the field name of the authorization code; the authorization code acquisition module includes: The request module is used to send a request in the requested parameter format to the application server through the interface address; The parsing module is used to receive the response data returned by the application server and parse the authorization code from the response data according to the field names.

[0097] Optionally, the device further includes: The unbinding request receiving module is used to receive the unbinding request sent by the vehicle terminal; the unbinding request includes the vehicle account identifier and the application account identifier; The binding relationship determination module is used to determine the binding relationship corresponding to the application account identifier based on the vehicle system account identifier and the application account identifier; The relationship unbinding module is used to unbind the binding relationship and return a successful unbinding notification to the vehicle terminal.

[0098] In summary, the account binding device provided in this application embodiment can use the cloud as an intermediate layer to encapsulate differentiated processing while unifying the logic on the vehicle-mounted system. When adding a new application, only the calling rules need to be configured in the cloud, improving scalability, and the vehicle-mounted system can seamlessly obtain the binding capability of the new application. Tokens are uniformly stored and refreshed in the cloud, and the vehicle-mounted system only holds short-term valid access tokens, which are not persistent, reducing the risk of leakage. The binding relationship is stored in the cloud, and after the user changes vehicles or restores the same vehicle to factory settings, logging back into the vehicle-mounted system account will automatically restore all application bindings without the need for reauthorization.

[0099] Reference Figure 11 The diagram illustrates a logical block diagram of an account management device according to an embodiment of the present invention. The device may include: The token acquisition module 501 is used to obtain the binding relationship corresponding to the vehicle account from the cloud server in response to the successful login of the vehicle account; the binding relationship is established by the cloud server according to the account binding method described above, and the binding relationship includes an application account and an access token, the access token being used to indicate that the vehicle terminal has the permission to access the application account; Login module 502 is used to send the access token and the application account to the corresponding vehicle application, so that the vehicle application can call the corresponding application server to log in to the application account through the access token; The exit module 503 is used to send a logout notification to the in-vehicle application in response to the vehicle account logging out, so that the in-vehicle application logs out of the application account.

[0100] Optionally, the login module includes: The first sending module is used to, upon receiving a query request sent by the vehicle application, find the corresponding access token and application account in the query request, and return the found access token and application account to the vehicle application. The second sending module is used to determine the vehicle application based on the application identifier in the binding relationship, and send the access token to the vehicle application.

[0101] In summary, the account management device provided in this application embodiment allows for login with a vehicle-mounted account, automatically bringing all bound applications online; and logging out of the vehicle-mounted account, synchronously deactivating all applications. It avoids long-term storage of tokens locally on the vehicle-mounted system, retrieving the latest token from the cloud in real time each time the account is logged in; and forcibly clears the local application state upon logout. The vehicle-mounted system is only responsible for distribution and notification; the addition, deletion, and modification of binding relationships are entirely managed by the cloud. Even after changing vehicles, logging in with the same account will still automatically log in to all applications, improving operational efficiency and convenience.

[0102] As the device embodiment is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the description of the method embodiment.

[0103] Reference Figure 12 This is a structural block diagram of an electronic device for account binding and account management provided in an embodiment of this application. Figure 12 As shown, the electronic device includes: a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method of the foregoing embodiments.

[0104] The processor can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0105] The memory may be ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or it may be EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.

[0106] This application also provides a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the method of the foregoing embodiments.

[0107] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0108] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented 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.

[0109] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as 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 terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0110] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive 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.

[0111] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal 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.

[0112] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0113] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device 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 terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0114] The above provides a detailed description of the account binding and management method, apparatus, electronic device, and readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An account binding method, characterized in that, Applied to a cloud server, the method includes: Receive a binding request sent by the vehicle terminal; the binding request includes the vehicle account identifier and the application identifier; Based on the application identifier, determine the application server and the corresponding invocation rules; According to the aforementioned calling rules, the authorization code is obtained from the application server and then sent to the vehicle terminal for display. If the application server returns an authorization success flag during polling, the application account identifier is obtained from the application server; the authorization success flag is generated by the application server after the mobile terminal authorizes the application using the authorization code. A binding relationship is established between the vehicle system account and the application account based on the vehicle system account identifier and the application account identifier.

2. The method of claim 1, wherein, The cloud server pre-stores multiple sets of associations, each set corresponding to an application identifier, as well as the application server and invocation rules corresponding to the application identifier; determining the application server and the invocation rules corresponding to the application server based on the application identifier includes: Among multiple sets of associations, find the target association that matches the application identifier; The application server and the calling rule in the target association are determined as the application server and the calling rule corresponding to the application identifier.

3. The method of claim 1, wherein, The invocation rules include: interface address, request parameter format, and field name of the authorization code; the step of obtaining the authorization code from the application server according to the invocation rules and sending the authorization code to the vehicle terminal for display includes: Send a request with the specified request parameter format to the application server via the specified interface address; Receive the response data returned by the application server, and parse the authorization code from the response data according to the field names.

4. The method of claim 1, wherein, The method further includes: Receive an unbinding request sent by the vehicle terminal; the unbinding request includes the vehicle account identifier and the application account identifier; Based on the vehicle system account identifier and the application account identifier, determine the binding relationship corresponding to the application account identifier; The binding relationship is removed, and a notification of successful unbinding is returned to the vehicle terminal.

5. An account management method characterized by comprising: Applied to vehicle-mounted terminals, the method includes: In response to the successful login of the vehicle system account, the binding relationship corresponding to the vehicle system account is obtained from the cloud server; the binding relationship is established by the cloud server according to the account binding method as described in any one of claims 1 to 4, and the binding relationship includes an application account and an access token, wherein the access token is used to indicate that the vehicle terminal has the permission to access the application account; The access token and the application account are sent to the corresponding vehicle application, so that the vehicle application can use the access token to call the corresponding application server to log in to the application account; In response to the vehicle system account logging out, a logout notification is sent to the in-vehicle application to cause the in-vehicle application to log out of the application account.

6. The method of claim 5, wherein, The binding relationship includes an application identifier, and sending the access token and the application account to the corresponding in-vehicle application includes: Upon receiving a query request from the in-vehicle application, the system searches for the corresponding access token and application account in the query request and returns the found access token and application account to the in-vehicle application. Alternatively, the in-vehicle application can be determined based on the application identifier in the binding relationship, and the access token can be sent to the in-vehicle application.

7. An account binding device, characterized in that, The device, used in a cloud server, includes: The request receiving module is used to receive a binding request sent by the vehicle terminal; the binding request includes the vehicle account identifier and the application identifier; The rule determination module is used to determine the application server and the calling rules corresponding to the application server based on the application identifier; The authorization code acquisition module is used to obtain the authorization code from the application server according to the calling rules, and send the authorization code to the vehicle terminal for display. The identifier acquisition module is used to obtain the application account identifier from the application server when the application server returns an authorization success flag during polling; the authorization success flag is generated by the application server after the mobile terminal authorizes the application account using the authorization code. The relationship establishment module is used to establish a binding relationship between the vehicle system account and the application account based on the vehicle system account identifier and the application account identifier.

8. An account management apparatus characterized by comprising: The device, applied to an in-vehicle terminal, includes: The token acquisition module is used to obtain the binding relationship corresponding to the vehicle account from the cloud server in response to the successful login of the vehicle account; the binding relationship is established by the cloud server according to the account binding method as described in any one of claims 1 to 4, the binding relationship includes an application account and an access token, and the access token is used to indicate that the vehicle terminal has the permission to access the application account; The login module is used to send the access token and the application account to the corresponding vehicle application, so that the vehicle application can call the corresponding application server to log in to the application account through the access token; The exit module is used to send a logout notification to the in-vehicle application in response to the vehicle account logging out, so that the in-vehicle application logs out of the application account.

9. An electronic device, comprising: It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method as claimed in any one of claims 1 to 4 or the method as claimed in any one of claims 5 to 6.

10. A readable storage medium, characterized by, The readable storage medium stores a program or instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 4 or the method as described in any one of claims 5 to 6.

Images