Information Processing Method, Apparatus, Device, and Storage Medium

Abstract

The present disclosure relates to an information processing method, apparatus, device, and storage medium. If the method is applied to a vehicle-mounted terminal, the method includes: sending, by an application layer in the vehicle-mounted terminal, a path request for a resource to a system layer of the vehicle-mounted terminal; wherein, a token is carried in the path request; determining, in the system layer, whether the token is a pre-stored authorized token; wherein, the authorized token is feedback by a server after authenticating the application; if the token is the authorized token, sending, by the system layer, an address of the resource in the vehicle-mounted terminal to the application layer; and enabling, by the application layer based on the address, the application to obtain the resource. By this method, the security of resource access can be improved.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technologies, and in particular, to an information processing method, apparatus, device, and storage medium. Background Art

[0002] Data security is a core point that has received much attention in the current Internet industry, and both China and the international community have legislated on data security. For example, legislation on the security of user privacy data. The hardware data, software data, behavior data, personal information data, etc. generated by users when using mobile devices are all personal privacy information assets of users and are information protected by law. Applications must comply with relevant laws and regulations when reading, transmitting, storing, and using user personal privacy information, and ensure information security based on relevant principles.

[0003] In the field of vehicle networking technology, the security of data has also received attention. Summary of the Invention

[0004] The present disclosure provides an information processing method, apparatus, device, and storage medium.

[0005] According to the first aspect of the embodiments of the present disclosure, an information processing method is provided, which is applied to a vehicle-mounted terminal and includes:

[0006] Sending a path request for a resource by an application layer in the vehicle-mounted terminal to a system layer of the vehicle-mounted terminal; wherein, a token is carried in the path request;

[0007] Determining, in the system layer, whether the token is a pre-stored authorized token; wherein, the authorized token is feedback after the application is authenticated by a server;

[0008] If the token is the authorized token, sending, by the system layer, an address of the resource in the vehicle-mounted terminal to the application layer;

[0009] Enabling the application to obtain the resource based on the address through the application layer.

[0010] In some embodiments, the resource pointed to by the address is a resource encrypted by a first key;

[0011] The enabling the application to obtain the resource based on the address through the application layer includes:

[0012] Obtaining the encrypted resource based on the address through the application layer;

[0013] Decrypting the encrypted resource by the application layer using a second key paired with the first key, so that the application obtains the decrypted resource.

[0014] In some embodiments, the first key and the second key are the same, and the authorization token is obtained by the server encrypting the first key with a third key negotiated with the application;

[0015] The method further includes:

[0016] The application layer decrypts the authorization token with a fourth key negotiated between the application and the server to obtain the second key.

[0017] In some embodiments, the first key and the second key have a mapping relationship with the resource.

[0018] In some embodiments, the authorization token is attached with time limit information;

[0019] Determining whether the token is a pre-stored authorization token at the system layer includes:

[0020] At the system layer, determining whether the content of the token is consistent with the content of the authorization token, and whether the time limit of the token is consistent with the time limit information of the authorization token.

[0021] In some embodiments, the method further includes:

[0022] Sending a request for the access permission of the resource by the application to the server; wherein, the account information of the application is carried in the access permission request;

[0023] Receiving the authorization token fed back by the server after authenticating the account information;

[0024] Saving the authorization token at the application layer and the system layer.

[0025] In some embodiments, the method further includes:

[0026] Receiving the resource sent by the server through the system layer, and storing the resource at a predetermined address in the in-vehicle unit.

[0027] In some embodiments, the resource sent by the server is attached with time limit information, and the method further includes:

[0028] Determining whether the resource is within the time limit range at a preset time interval through the system layer;

[0029] If the resource is not within the time limit range, requesting the server to update the resource through the system layer.

[0030] According to the second aspect of the embodiments of the present disclosure, an information processing method is provided, which is applied to a server and includes:

[0031] Receive an access permission request for resources sent by the in-vehicle head unit; wherein, the access permission request carries the account information of the application.

[0032] Authenticate the application according to the account information of the application, and generate an authorization token after successful authentication.

[0033] Send the authorization token to the in-vehicle head unit; wherein, the authorization token is used to be stored in the in-vehicle head unit, and enables the application in the in-vehicle head unit to obtain the resources stored in the in-vehicle head unit from the system layer in the in-vehicle head unit.

[0034] In some embodiments, the resources stored in the in-vehicle head unit are resources encrypted using a first key; the second key of the resources is the same as the first key, and the second key is a decryption key.

[0035] The step of sending the authorization token to the in-vehicle head unit according to the access permission request includes:

[0036] Obtain the first key according to the access permission request.

[0037] Encrypt the first key using a third key negotiated with the application in the in-vehicle head unit to obtain the authorization token.

[0038] Send the authorization token to the in-vehicle head unit.

[0039] In some embodiments, the access permission request carries the identifier of the resource.

[0040] The step of obtaining the first key according to the access permission request includes:

[0041] Obtain the first key corresponding to the identifier of the resource according to the access permission request.

[0042] In some embodiments, the first key is the account information of the application.

[0043] In some embodiments, the method further includes:

[0044] Before receiving the access permission request sent by the in-vehicle head unit, encrypt the resources using the first key, and send them to the in-vehicle head unit after attaching time limit information.

[0045] In some embodiments, the method further includes:

[0046] Receive a resource update request sent by the in-vehicle head unit after determining that the resources have expired.

[0047] Send the encrypted resource after updated timeliness to the in-vehicle device according to the resource update request.

[0048] According to a third aspect of the embodiments of the present disclosure, there is provided an information processing device, which is applied to an in-vehicle device. The device includes:

[0049] A first sending module, configured to send a path request of a resource by the application to the system layer of the in-vehicle device through an application layer in the in-vehicle device; wherein, a token is carried in the path request.

[0050] A first determining module, configured to determine whether the token is a pre-stored authorized token in the system layer; wherein, the authorized token is fed back after the application is authenticated by the server.

[0051] A second sending module, configured to send an address of the resource in the in-vehicle device to the application layer through the system layer if the token is the authorized token.

[0052] An obtaining module, configured to cause the application to obtain the resource based on the address through the application layer.

[0053] In some embodiments, the resource pointed to by the address is a resource encrypted by a first key.

[0054] The obtaining module is further configured to obtain the encrypted resource based on the address through the application layer; and decrypt the encrypted resource by using a second key paired with the first key through the application layer, so that the application obtains the decrypted resource.

[0055] In some embodiments, the first key and the second key are the same, and the authorized token is obtained by the server encrypting the first key according to a third key negotiated with the application.

[0056] The device further includes:

[0057] A decryption module, configured to decrypt the authorized token by using a fourth key negotiated between the application and the server through the application layer to obtain the second key.

[0058] In some embodiments, the first key and the second key have a mapping relationship with the resource.

[0059] In some embodiments, the authorized token is attached with timeliness information.

[0060] The first determining module is further configured to determine whether the content of the token is consistent with the content of the authorized token, and whether the timeliness of the token is consistent with the timeliness information of the authorized token in the system layer.

[0061] In some embodiments, the device further comprises:

[0062] A third sending module, configured to send a request for access permission of the application to the resource to the server; wherein, the account information of the application is carried in the access permission request;

[0063] A first receiving module, configured to receive the authorization token fed back by the server after authenticating the account information;

[0064] A saving module, configured to save the authorization token in the application layer and the system layer.

[0065] In some embodiments, the device further comprises:

[0066] A second receiving module, configured to receive the resource sent by the server through the system layer and store the resource at a predetermined address in the in-vehicle unit.

[0067] In some embodiments, the resource sent by the server is attached with time limit information, and the device further comprises:

[0068] A second determining module, configured to determine whether the resource is within the time limit range at a preset time interval through the system layer;

[0069] A request module, configured to request the server to update the resource through the system layer if the resource is not within the time limit range.

[0070] According to a fourth aspect of the embodiments of the present disclosure, an information processing device is provided, which is applied to a server, and the device comprises:

[0071] A third receiving module, configured to receive a request for access permission of an application to a resource sent by an in-vehicle unit; wherein, the account information of the application is carried in the access permission request;

[0072] A generating module, configured to authenticate the application according to the account information of the application and generate an authorization token after the authentication passes;

[0073] A fourth sending module, configured to send the authorization token to the in-vehicle unit; wherein, the authorization token is used to be saved in the in-vehicle unit and is used for the application in the in-vehicle unit to obtain the resource stored in the in-vehicle unit from the system layer in the in-vehicle unit.

[0074] In some embodiments, the resource stored in the in-vehicle unit is the resource encrypted by a first key; a second key of the resource is the same as the first key, and the second key is a decryption key;

[0075] The fourth sending module is further configured to obtain the first key according to the access permission request; encrypt the first key with a third key negotiated with the application in the in-vehicle device to obtain the authorization token; and send the authorization token to the in-vehicle device.

[0076] In some embodiments, the access permission request carries an identifier of the resource;

[0077] The fourth sending module is further configured to obtain the first key corresponding to the identifier of the resource according to the access permission request.

[0078] In some embodiments, the first key is the account information of the application.

[0079] In some embodiments, the apparatus further includes:

[0080] A fifth sending module, configured to encrypt the resource with the first key and send it to the in-vehicle device with expiration information attached before receiving the access permission request sent by the in-vehicle device.

[0081] In some embodiments, the apparatus further includes:

[0082] A fourth receiving module, configured to receive a resource update request sent by the in-vehicle device after determining that the resource has expired;

[0083] A sixth sending module, configured to send the encrypted resource with updated expiration to the in-vehicle device according to the resource update request.

[0084] According to a fifth aspect of the embodiments of the present disclosure, there is provided a device, including:

[0085] A processor;

[0086] A memory for storing processor-executable instructions;

[0087] Wherein, the processor is configured to execute the information processing method as described in the first aspect or the second aspect above.

[0088] According to a sixth aspect of the embodiments of the present disclosure, there is provided a storage medium, including:

[0089] When the instructions in the storage medium are executed by a processor of the in-vehicle device, the in-vehicle device can execute the information processing method as described in the first aspect above; or when the instructions in the storage medium are executed by a processor of the server, the server can execute the information processing method as described in the second aspect above.

[0090] The technical solutions provided by the embodiments of the present disclosure may include the following beneficial effects:

[0091] In an embodiment of the present disclosure, since third-party applications in the in-vehicle device terminal come from third-party developers, directly exposing resources to third-party applications may cause privacy leakage. Therefore, the application layer of the in-vehicle device terminal of the present disclosure requests resources from the system layer according to a token, and grants the application layer the permission to obtain resources only when the system layer determines that the token is an authorization token feedback by the server for authenticating the application, which can improve the security of resource access. In addition, since the authorization token is saved in the in-vehicle device terminal, when the application needs to use resources, it can send a path request to the system layer through the application layer without authenticating with the server every time. Moreover, since the present disclosure stores resources in the in-vehicle device terminal without requesting from the server every time, the stability of resource acquisition is improved while controlling the access permission of the application to resources, and the instruction interaction is reduced.

[0092] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0093] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present disclosure, and are used together with the specification to explain the principles of the present disclosure.

[0094] Figure 1 is a flowchart of an information processing method shown in an embodiment of the present disclosure Figure 1 。

[0095] Figure 2 is an architecture diagram of an in-vehicle central control system.

[0096] Figure 3 is a flowchart of an information processing method shown in an embodiment of the present disclosure Figure 2 。

[0097] Figure 4 is an interaction diagram of an information processing method in an embodiment of the present disclosure

[0098] Figure 5 is an interaction example diagram of an information processing method in an embodiment of the present disclosure

[0099] Figure 6 is an information processing device in an embodiment of the present disclosure Figure 1 。

[0100] Figure 7 is an information processing device in an embodiment of the present disclosure Figure 2 。

[0101] Figure 8 is a block diagram of an in-vehicle device terminal shown in an embodiment of the present disclosure

[0102] Figure 9It is a block diagram of a server shown in an embodiment of the present disclosure. Detailed implementation manners

[0103] Here, exemplary embodiments will be described in detail, and examples thereof are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present disclosure. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0104] Figure 1 It is a flowchart of an information processing method shown in an embodiment of the present disclosure Figure 1 and is applied to a vehicle-mounted terminal. As Figure 1 shown, the information processing method applied to the vehicle-mounted terminal includes the following steps:

[0105] S11. Send a path request for resources of the application from the application layer in the vehicle-mounted terminal to the system layer of the vehicle-mounted terminal; wherein, a token is carried in the path request.

[0106] S12. Determine whether the token is a pre-stored authorized token in the system layer; wherein, the authorized token is feedback after the server authenticates the application.

[0107] S13. If the token is the authorized token, send the address of the resource in the vehicle-mounted terminal from the system layer to the application layer.

[0108] S14. Based on the address, enable the application to obtain the resource through the application layer.

[0109] In the embodiments of the present disclosure, the vehicle-mounted terminal refers to an in-vehicle terminal installed in a vehicle, and applications (Application, APP) are installed on the vehicle-mounted terminal, such as a phone application, a smart connection application, a navigation application, a video playback application, or a voice assistant application, etc. The applications in the vehicle-mounted terminal are basically implemented based on the in-vehicle central control. With the advancement of technology, especially the development of the Internet, the vehicle-mounted terminal applications of the current vehicle networking system have been closely connected to the Internet. The vehicle-mounted terminal can communicate wirelessly with the server, and the server can support the operation of the applications in the vehicle-mounted terminal. In the embodiments of the present disclosure, the server is also referred to as an authorization server.

[0110] The in-vehicle central control is a bridge for the driver to interact with the vehicle. The driver can conveniently and quickly query, set, and switch various information of the vehicle system based on the in-vehicle central control, ensuring driving safety while enhancing driving pleasure. As follows Figure 2 is an architecture diagram of the in-vehicle central control system. As Figure 2As shown, it includes a hardware layer, a system layer, and an application layer. Among them, devices such as a display screen and sensors are shown in the hardware layer. The sensors are, for example, temperature sensors, etc., which are used to sense the temperature inside the vehicle; the display screen is used to display the application interface or relevant information about the vehicle's driving, so as to facilitate human-machine interaction. The system layer includes system programs. The system programs are the interfaces between users and in-vehicle hardware, and at the same time, they are also the interfaces between in-vehicle hardware and upper-layer applications. The functions of the system programs include managing the hardware, software, and data resources of the in-vehicle system, controlling program operation, improving the human-machine interface, providing support for upper-layer applications, etc. The data resources managed by the system layer. In the embodiments of the present disclosure, the system layer can also be referred to as a "resource server", and the resources it manages include the resources sent from the server side to the in-vehicle terminal. These resources can be dynamically updated by the server side, and can also include the resources directly saved in the in-vehicle terminal. The application layer includes various applications such as navigation and intelligent voice, so as to provide intelligent services for the driver. In the embodiments of the present disclosure, the application layer and the system layer in the in-vehicle terminal are as described above Figure 2 shown.

[0111] In step S11, the in-vehicle terminal sends a path request for resources by the application layer to the system layer of the in-vehicle terminal. For example, the application is a third-party voice assistant application, and the requested resources are, for example, an algorithm model for voice processing. When the voice assistant responds to the user's voice command, it needs to use this algorithm model to determine the content of the voice command in order to give a corresponding response. Another example is that the application is a third-party navigation application, and the requested resources are, for example, location-related configuration files, etc. The normal operation of the applications in the in-vehicle terminal requires obtaining the corresponding resources first.

[0112] It should be noted that in the embodiments of the present disclosure, the resources can be the resources stored in the in-vehicle terminal itself, or the resources sent by the server side. The embodiments of the present disclosure do not limit this. If the resources are the resources sent by the server side, the reason for the server side to send the resources to the in-vehicle terminal for storage is that during the vehicle's driving process, due to changes in geographical locations (such as tunnels, garages, bridges, etc.), the connection signal between the in-vehicle terminal and the server side is unstable. Therefore, sending the resources to the in-vehicle terminal in advance can improve the stability of the applications in the in-vehicle terminal to obtain resources.

[0113] As mentioned above, the system layer manages data resources, and the paths of the resources are stored in the system layer. In this regard, the present disclosure can request the paths of the resources required by the application from the system layer through the application layer.

[0114] In this embodiment, the path request received by the system layer includes a token. For example, the token is Token. A more popular explanation of the token can be called a secret signal. Before some data transmissions, the secret signal needs to be verified first to determine the usage permission of the data.

[0115] In step S12, the in-vehicle device determines at the system layer whether the token is a pre-stored authorized token, and in step S13, after determining that it is an authorized token, the in-vehicle device sends the address of the resource in the in-vehicle device to the application layer through the system layer. When the system layer determines whether the token is a pre-stored authorized token, it needs to at least determine whether the content of the token is consistent with the content of the authorized token.

[0116] It should be noted that the authorized token is fed back to the in-vehicle device by the server after the application authentication is passed, and both the application layer and the system layer of the in-vehicle device need to save the authorized token. Therefore, when the application needs to use the resource, it can send a path request carrying the token to the system layer, so that the system layer authenticates the token.

[0117] The server authenticates the application, for example, based on the client credential mode in the OAuth 2.0 protocol. In this mode, the client (i.e., the application) sends an access permission request to the server in its own name, rather than in the name of the user. After receiving the access permission request, the server can send the authorized token. It should be noted that in the embodiments of the present disclosure, the client (application) will be backed up in the system layer in advance, and the system layer will issue account information to the client, such as including the application identifier (client_id) and the application password (client_secret).

[0118] The application in the in-vehicle device can request an authorized token from the server based on the account information issued by the system layer for it. For example, the in-vehicle device can send an access permission request for the application to the resource to the server, and the access permission request carries the account information of the application. After the server confirms that the account information of the application is consistent with its own storage, it can issue an authorized token for the application.

[0119] In addition, in the embodiments of the present disclosure, the path request may also carry the identifier of the resource. The identifier of the resource is used to identify different resources. For example, the voice algorithm model resource is identified by "0", and the navigation configuration file is identified by "1", etc. The present disclosure does not limit the form of the identifier of the resource. After the system layer determines that the token is a pre-stored authorized token, it can send the address of the resource in the in-vehicle device to the application layer based on the identifier of the resource carried in the path request. It can be understood that by carrying the identifier of the resource, when different resources are stored in different locations, it is also convenient for the system layer to determine the location where the resource is located according to the identifier of the resource.

[0120] In the embodiments of the present disclosure, the path request may also carry the account information of the application, so that the system layer can determine whether the application has been backed up according to the account information. In this embodiment, after the system layer determines that the application has been backed up, it can then determine whether the token is valid.

[0121] In step S14, after the application layer obtains the address in the in-vehicle device where the resource is located, the application that requests the resource can obtain the resource for the application to use.

[0122] It should be noted that, in the embodiments of the present disclosure, the operations performed by the application layer are also the operations performed by the application that requests the resource. In the subsequent description of the present disclosure, the application is directly used to replace the application layer.

[0123] It can be understood that, in the embodiments of the present disclosure, since the third-party applications in the in-vehicle device come from third-party developers, if the resources are directly exposed to the third-party applications, it may cause privacy leakage. Therefore, the application layer of the in-vehicle device of the present disclosure requests resources from the system layer based on the token, and only gives the application layer the permission to obtain resources when the system layer determines that the token is the authorization token feedback by the server after authenticating the application, which can improve the security of resource access. In addition, since the authorization token is stored in the in-vehicle device, when the application needs to use the resources, it can send a path request to the system layer through the application layer without authenticating with the server every time, and the present disclosure stores the resources in the in-vehicle device without requesting from the server every time, so the stability of resource acquisition is also improved while controlling the access permission of the application to the resources.

[0124] In one embodiment, the resource pointed to by the address is the resource encrypted with the first key; step S14 includes:

[0125] The encrypted resource is obtained by the application layer based on the address;

[0126] The encrypted resource is decrypted by the application layer using the second key paired with the first key, so that the application obtains the decrypted resource; wherein, the first key and the second key are obtained through negotiation between the server and the in-vehicle device.

[0127] In this embodiment, the resource is the resource encrypted with the first key. For example, the resource can be encrypted by the server and sent to the in-vehicle device. Of course, the in-vehicle device itself can also encrypt the unencrypted resource sent by the server.

[0128] It should be noted that the first key for encryption and the second key for decryption can be negotiated by the system layers in the server and the in-vehicle unit. Exemplarily, if the resource sent by the server is encrypted, the first key and the second key negotiated by the server and the in-vehicle unit enable one end to encrypt and the other end to decrypt, which can improve the security of the resource. In addition, the first key for encryption and the second key for decryption can also be determined by the system layer in the in-vehicle unit. On the one hand, without going through the server, the security of the first key and the second key can be improved, thereby improving the security of the resource; on the other hand, encrypting the resource in the in-vehicle unit can also make the stored resource unusable even if the in-vehicle unit is stolen after being connected to the network, thereby also improving the security of the resource.

[0129] In the present disclosure, whether the first key and the second key are determined by the in-vehicle unit or determined through negotiation between the in-vehicle unit and the server, after the system layer determines that the token is an authorization token, the system layer can send the key for decryption to the application, so that the application can use the second key to obtain the decrypted resource.

[0130] In this embodiment, the first key and the second key can be keys obtained based on an asymmetric encryption algorithm. In this case, the first key and the second key are different; of course, the first key and the second key can also be keys obtained based on a symmetric encryption algorithm. In this case, the first key and the second key are the same. Among them, the asymmetric encryption algorithm is, for example, the RSA encryption algorithm, the ElGamal encryption algorithm, etc.; the symmetric encryption algorithm is, for example, the DES, DESede, IDEA, or PBE encryption algorithm, etc. The embodiments of the present disclosure do not limit this.

[0131] It can be understood that in the embodiments of the present disclosure, by encrypting the resource, while controlling the access role of the resource (i.e., controlling the access permission of the application), the security or privacy of the resource can be improved.

[0132] It should be noted that in the embodiments of the present disclosure, all the resources stored in the in-vehicle unit can correspond to the same key (including the first key and the second key), and of course, one resource can also correspond to one key. The embodiments of the present disclosure do not limit this.

[0133] In some embodiments, the first key and the second key are the same, and the authorization token is obtained by the server encrypting the first key with a third key negotiated with the application;

[0134] The method further includes:

[0135] The application layer decrypts the authorization token with a fourth key negotiated by the application and the server to obtain the second key.

[0136] In this embodiment, since the first key and the second key are the same, the authorization token is obtained by the server encrypting the first key of the resource with the third key negotiated with the application. Therefore, after the system layer on the in-vehicle device determines that the token carried in the path request is the authorization token, the application can use the fourth key to decrypt the authorization token to obtain the first key, which is also the second key, so that the application can use the decrypted second key to decrypt the resource and obtain the decrypted resource.

[0137] In this embodiment, the first key and the second key may be the account information of the application. Exemplarily, both the first key and the second key are the passwords of the application.

[0138] In this embodiment, the third key and the fourth key may also be keys obtained based on an asymmetric encryption algorithm or a symmetric encryption algorithm, which is not limited herein.

[0139] In the related art, the resource is encrypted, and the corresponding decryption key is usually stored on the server and often changes. Therefore, every time the in-vehicle device is used, it needs to apply to the server for the decryption key and then use the decryption key to access the resource. In this way, after the resource is encrypted, each access will request authorization from the server. Due to the mobile characteristics of the in-vehicle device, it is very likely to request the server in a situation with poor network conditions (such as tunnels, garages, bridges, etc.), resulting in resource access failure.

[0140] In this embodiment, the encryption of the resource is combined with the generation of the authorization token. Since the authorization token is fed back to the in-vehicle device by the server after the application's access permission request and stored in the in-vehicle device, the application in the in-vehicle device can use the fourth key to decrypt the authorization token to obtain the decryption key (the second key) of the resource and further obtain the decrypted resource, without having to request the decryption key of the resource from the server, reducing the number of times the in-vehicle device accesses the server, and thus further enhancing security.

[0141] In one embodiment, the first key and the second key have a mapping relationship with the resource.

[0142] In this embodiment, the first key and the second key have a mapping relationship with the resource, that is, one resource corresponds to one key as described above. In this way, the confidentiality of the resource can be improved.

[0143] In addition, since the authorization token can be obtained based on the first key, the mapping relationship between the first key and the resource is equivalent to the mapping relationship between the authorization token and the resource. This method can not only improve the confidentiality of the resource, but also enhance the security of the application accessing the resource.

[0144] In one embodiment, the authorization token is attached with time-limited information;

[0145] Determining whether the token is a pre-stored authorized token at the system layer includes:

[0146] At the system layer, determining whether the content of the token is consistent with the content of the authorized token, and whether the expiration time of the token is consistent with the expiration information of the authorized token.

[0147] In this embodiment, the authorized token is also attached with expiration information. Therefore, when determining whether a token is an authorized token at the system layer, not only the token content needs to be compared, but also the expiration time needs to be compared. Through the setting of the expiration time, the security of access can be further improved.

[0148] In one embodiment, the method further includes:

[0149] Sending a request for the access permission of the application to the resource to the server; wherein, the access permission request carries the account information of the application;

[0150] Receiving the authorized token feedback by the server after authenticating the account information;

[0151] Saving the authorized token at the application layer and the system layer.

[0152] In the embodiments of the present disclosure, when an application first needs to use a resource, it can send a request for access permission to the server through the in-vehicle device. The server can directly send an authorized token to the in-vehicle device based on the client credential mode in the foregoing OAuth 2.0 protocol. In this mode, the in-vehicle device can send an access permission request carrying the account information of the application to the server, so that the server can authenticate the application according to the account information and send an authorized token. After receiving the authorized token, the in-vehicle device can save the authorized token in the system layer and the application layer, which is convenient for the subsequent application to request the resource path according to the saved token. As mentioned above, the feedback authorized token can be attached with expiration information. In this embodiment, for example, an access permission request can be directly sent to the server through the application in the in-vehicle device, and the application can receive the feedback authorized token. After receiving the authorized token, the application can send it to the system layer for saving.

[0153] In one embodiment, the access permission request may also carry the identifier of the resource. After obtaining the access permission request carrying the identifier of the resource, the server can obtain the first key corresponding to the identifier of the resource and encrypt the first key to obtain the authorized token, that is, the authorized token obtained by the in-vehicle device mentioned above is obtained by the server encrypting the first key according to the third key negotiated with the application, which will not be elaborated here.

[0154] It should be noted that in the embodiments of the present disclosure, if a path request is sent from the application layer to the system layer and the system layer determines that the token is not an authorization token, the in-vehicle device can resend an access permission acquisition request to the server to obtain an authorization credential (i.e., an authorization token) from the server. It should be noted that the system layer determining that the token is not an authorization token can be that the content of the token is inconsistent with the content of the authorization token, and / or the expiration time of the token is inconsistent with the expiration time of the authorization token.

[0155] In one embodiment, the method further includes:

[0156] Receiving, by the system layer, the resource sent by the server, and storing the resource in the in-vehicle device at a predetermined address.

[0157] In the embodiments of the present disclosure, the resource can be sent from the server to the in-vehicle device, and the system layer of the in-vehicle device stores the resource at a predetermined address.

[0158] In one embodiment, the resource sent by the server is attached with expiration information, and the method further includes:

[0159] Determining, by the system layer, at a preset time interval whether the resource is within the expiration range;

[0160] If the resource is not within the expiration range, requesting, by the system layer, the server to update the resource.

[0161] In this embodiment, the resource sent by the server is also attached with expiration information. Within the expiration range, the resource can be used normally. If it expires (i.e., is not within the expiration range), the resource cannot be used normally. Therefore, the system layer needs to regularly determine whether the resource is still within the expiration period. If not, the system layer requests the server to update the resource.

[0162] Exemplarily, the expiration time of the resource sent by the server is from January 1, 2021 to December 31, 2021, and the current time determined by the system layer of the in-vehicle device is January 3, 2022. Then the system layer determines that the resource is not within the expiration range and requests the server to update the resource. For example, the server can reset the expiration time of the resource according to this request and send it to the in-vehicle device.

[0163] It can be understood that in the embodiments of the present disclosure, the resource is attached with an expiration time, and the system layer in the in-vehicle device regularly checks whether the resource is within the valid period, which can ensure that the resources stored in the in-vehicle device are as up-to-date as possible and can improve the accuracy of the application using the resources.

[0164] Figure 3 is a flow of an information processing method shown in the embodiments of the present disclosure Figure 2 , applied to the server, such as Figure 3As shown in the figure, the information processing method applied to the server side includes the following steps:

[0165] S21. Receive the access permission request of the application for resources sent by the vehicle-mounted terminal; wherein, the access permission request carries the account information of the application.

[0166] S22. Authenticate the application according to the account information of the application, and generate an authorization token after the authentication passes.

[0167] S23. Send the authorization token to the vehicle-mounted terminal; wherein, the authorization token is used to be stored in the vehicle-mounted terminal and is used for the application in the vehicle-mounted terminal to obtain the resources stored in the vehicle-mounted terminal from the system layer in the vehicle-mounted terminal.

[0168] In step S21, when the server side receives the access permission request of the application for resources sent by the vehicle-mounted terminal, it can be a request sent when the application in the vehicle-mounted terminal first needs to use resources, or it can be a request sent by the vehicle-mounted terminal again after determining that the authorization token has expired, for example, after exceeding the time limit. The embodiments of the present disclosure do not limit this.

[0169] The access permission request carries the account information of the application, and this account information is issued by the system layer for the client (application) when the client (application) backs up in the system layer in advance.

[0170] In step S22, the server side authenticates the application according to the account information of the application. For example, it confirms whether the account information of the application is consistent with the stored one. If it is consistent, an authorization token is generated, and in step S23, the authorization token is sent to the vehicle-mounted terminal.

[0171] Since in this embodiment, the authorization token is used for the application in the vehicle-mounted terminal to obtain resources from the system layer in the vehicle-mounted terminal, therefore, the third-party application in the vehicle-mounted terminal cannot use resources arbitrarily. Through this method, the security of resource access can be improved. In addition, after obtaining the authorization token, the vehicle-mounted terminal can save it. When the application needs to use resources, it can apply to the system layer in the vehicle-mounted terminal based on the authorization token without having to authenticate with the server side every time, and the present disclosure stores the resources in the vehicle-mounted terminal without having to request from the server side every time. Therefore, while controlling the access permission of the application to resources, the stability of resource acquisition is also improved, and the instruction interaction is reduced.

[0172] In one embodiment, the resources stored in the vehicle-mounted terminal are resources encrypted with a first key, and the second key of the resources is the same as the first key, and the second key is a decryption key.

[0173] Sending the authorization token to the vehicle-mounted terminal according to the access permission request includes:

[0174] Obtain the first key according to the access permission request;

[0175] Encrypt the first key with a third key negotiated with the application in the in-vehicle unit to obtain the authorization token;

[0176] Send the authorization token to the in-vehicle unit.

[0177] In this embodiment, the resources stored in the in-vehicle unit are resources encrypted with the first key. When the server sends the authorization token according to the access permission request, the generation of the authorization token is combined with the encryption of the resources. Since the authorization token is generated after encrypting the first key of the resources, and the encryption key (the first key) of the resources is the same as the decryption key of the resources, the application in the in-vehicle unit can obtain the first key, that is, the second key, after decrypting the authorization token with the fourth key negotiated with the server. Thus, the application in the in-vehicle unit can decrypt the resources with the decrypted second key to obtain the decrypted resources.

[0178] It can be understood that the server combines the encryption of the resources with the generation of the authorization token. Since the authorization token is sent by the server to the in-vehicle unit according to the access permission request of the application and stored in the in-vehicle unit, the application in the in-vehicle unit can decrypt the authorization token with the fourth key to obtain the decryption key (the second key) of the resources and further obtain the decrypted resources, without requesting the decryption key of the resources from the server, reducing the number of times the in-vehicle unit accesses the server, and thus further enhancing security.

[0179] In one embodiment, the access permission request carries the identifier of the resource;

[0180] The step of obtaining the first key according to the access permission request includes:

[0181] Obtain the first key corresponding to the identifier of the resource according to the access permission request.

[0182] In this embodiment, the access permission request carries the identifier of the resource, and the server obtains the corresponding first key according to the identifier of the resource, that is, different keys are assigned to each resource, thus enhancing the confidentiality of the resources. In addition, since the authorization token is generated based on the first key, the authorization token also has a mapping relationship with the resources, that is, the server feedbacks different authorization tokens according to the identifier of the resource. In this way, the security of the application accessing the resources can also be enhanced.

[0183] In one embodiment, the first key is the account information of the application.

[0184] In this embodiment, the first key and the second key may be the account information of the application. Exemplarily, both the first key and the second key are the passwords of the application.

[0185] In the embodiments of the present disclosure, the account information of the application carried in the access permission request can be used not only as a credential for the application in the in-vehicle device to obtain an authorization token, but also as an encryption key and a decryption key.

[0186] In one embodiment, the method further includes:

[0187] Before receiving the access permission request sent by the in-vehicle device, encrypt the resource with the first key, and send it to the in-vehicle device after attaching time-limited information.

[0188] In the embodiments of the present disclosure, the resource can be encrypted by the server with the first key and sent to the in-vehicle device after attaching time-limited information, which can improve the confidentiality of the resource. In addition, because the resource is time-limited, it can also limit the use of the application in the in-vehicle device and improve the security of the resource.

[0189] It should be noted that after sending the encrypted resource with time-limited information to the in-vehicle device, the system layer of the in-vehicle device stores the resource in the in-vehicle device at a predetermined address.

[0190] In one embodiment, the method further includes:

[0191] Receive a resource update request sent by the in-vehicle device after determining that the resource is out of the time limit;

[0192] According to the resource update request, send the encrypted resource with updated time limit to the in-vehicle device.

[0193] In this embodiment, the system layer in the in-vehicle device will regularly check whether the resource is within the time limit. If the resource is out of the time limit, it will send a resource update request to the server. After receiving the resource update request, the server can send the encrypted resource with updated time limit to the in-vehicle device.

[0194] It can be understood that the server updates the resource to the in-vehicle device according to the resource update request of the in-vehicle device, which can make the resource stored in the in-vehicle device as up-to-date as possible and improve the accuracy of the application using the resource.

[0195] Figure 4 This is an interaction diagram of an information processing method in the embodiments of the present disclosure. As Figure 4 shown, the information processing method applied to the in-vehicle device and the server includes the following steps:

[0196] S31. Receive an access permission request of the application for the resource sent by the in-vehicle device; wherein, the access permission request carries the account information of the application;

[0197] S32. Authenticate the application according to the account information of the application, and generate an authorization token after successful authentication;

[0198] S33. Send the authorization token to the in-vehicle device;

[0199] S34. The in-vehicle device saves the authorization token;

[0200] S35. Send a path request for the application to access the resource to the system layer of the in-vehicle device through the application layer in the in-vehicle device; wherein, the path request carries the token;

[0201] S36. The in-vehicle device determines whether the token is a pre-stored authorization token in the system layer;

[0202] S37. If the token is the authorization token, send the address of the resource in the in-vehicle device to the application layer through the system layer;

[0203] S38. The in-vehicle device enables the application to obtain the resource based on the address through the application layer.

[0204] It should be noted that in this embodiment, steps S31 to S34 are not required to be executed every time the application accesses the resource. The above steps S31 to S34 can be executed when the application in the in-vehicle device first needs to access the resource, or when the in-vehicle device determines that the authorization token has expired, for example, after the expiration time.

[0205] It can be understood that in the embodiments of the present disclosure, the in-vehicle device requests the application to obtain an authorization token and save it based on the access permission request, so that when the application needs to access the resource subsequently, it can request through the application layer according to the authorization token to the system layer, which can improve the security of resource access. In addition, since the authorization token is saved in the in-vehicle device, when the application needs to access the resource, it can send a path request to the system layer through the application layer, without the need to authenticate with the server every time, and the present disclosure stores the resource in the in-vehicle device without the need to request the server every time. Therefore, while controlling the access permission of the application to the resource, the stability of resource acquisition is improved, and the instruction interaction is reduced.

[0206] Figure 5 This is an interaction example diagram of an information processing method in an embodiment of the present disclosure. Figure 5The authorization server in it, i.e., the server side, is the same as the server side of the present disclosure. The system program and the third-party side application both belong to the in-vehicle device side. The system program is the system layer of the in-vehicle device side, which can manage resources and is thus also called the resource server; the third-party side application is the application located in the application layer in the present disclosure, that is, the requesting client. The requesting client can obtain an authorization token for accessing resources from the authorization server based on the OAuth 2.0 protocol. Among them, the authorization server can be the role declared in the OAuth 2.0 protocol, specifically responsible for the permission control of the client request and for issuing the authorization token. The requesting client can also be the role declared in the OAuth 2.0 protocol, the initiator of the permission request and the resource requester. The resource server can be the role declared in the OAuth 2.0 protocol, responsible for managing the path of resources, verifying the legality of the token, and finding the path of the specific resource.

[0207] It can be seen from Figure 5 that the information processing method includes two processes. Among them, the process identified by steps 1.1 - 1.4 is the process of the server side and the system layer in the in-vehicle device side managing resources; the process of steps 2.1 - 2.7 is the process of the application located in the application layer requesting an authorization token from the server side and requesting resources from the system layer based on the authorization token and obtaining the decrypted resources. Among the above steps, the process of steps 2.1 - 2.2 does not require the application to apply to the server side every time it uses resources. The operations performed in each step of the above two processes can be seen in the description in Figures 1 to 4 above and will not be elaborated here.

[0208] Figure 6 This is an information processing device in an embodiment of the present disclosure Figure 1 . Referring to Figure 6 , it is applied to the in-vehicle device side, and the device includes:

[0209] The first sending module 101 is configured to send a path request of the application for resources to the system layer of the in-vehicle device side through the application layer in the in-vehicle device side; wherein, the path request carries a token;

[0210] The first determination module 102 is configured to determine in the system layer whether the token is a pre-stored authorization token; wherein, the authorization token is the feedback after the server side authenticates the application;

[0211] The second sending module 103 is configured to, if the token is the authorization token, send the address of the resource in the in-vehicle device side to the application layer through the system layer;

[0212] The obtaining module 104 is configured to, through the application layer based on the address, enable the application to obtain the resource.

[0213] In some embodiments, the resource pointed to by the address is a resource encrypted with a first key;

[0214] The obtaining module 104 is further configured to obtain the encrypted resource based on the address through the application layer; and decrypt the encrypted resource through the application layer by using a second key paired with the first key, so that the application obtains the decrypted resource.

[0215] In some embodiments, the first key and the second key are the same, and the authorization token is obtained by the server encrypting the first key with a third key negotiated with the application;

[0216] The device further includes:

[0217] A decryption module 105, configured to decrypt the authorization token through the application layer by using a fourth key negotiated between the application and the server to obtain the second key.

[0218] In some embodiments, the first key and the second key have a mapping relationship with the resource.

[0219] In some embodiments, the authorization token is attached with time limit information;

[0220] The first determination module 102 is further configured to determine, in the system layer, whether the content of the token is consistent with the content of the authorization token, and whether the time limit of the token is consistent with the time limit information of the authorization token.

[0221] In some embodiments, the device further includes:

[0222] A third sending module 106, configured to send a request for the application's access permission to the resource to the server; wherein, the access permission request carries the account information of the application;

[0223] A first receiving module 107, configured to receive the authorization token fed back by the server after authenticating the account information;

[0224] A saving module 108, configured to save the authorization token in the application layer and the system layer.

[0225] In some embodiments, the device further includes:

[0226] A second receiving module 109, configured to receive the resource sent by the server through the system layer and store the resource at the in-vehicle terminal according to a predetermined address.

[0227] In some embodiments, the resource sent by the server is attached with time limit information, and the device further includes:

[0228] A second determination module 110, configured to determine whether the resource is within the time limit by the system layer at a preset time interval;

[0229] A request module 111, configured to, if the resource is not within the time limit, request the server to update the resource through the system layer.

[0230] Figure 7 It is an information processing device in an embodiment of the present disclosure Figure 2 . Refer to Figure 7 , applied to the server, the device includes:

[0231] A third receiving module 201, configured to receive an access permission request for a resource sent by the in-vehicle terminal; wherein, the access permission request carries the account information of the application;

[0232] A generation module 202, configured to authenticate the application according to the account information of the application, and generate an authorization token after the authentication passes;

[0233] A fourth sending module 203, configured to send the authorization token to the in-vehicle terminal; wherein, the authorization token is used to be stored in the in-vehicle terminal and is used for the application in the in-vehicle terminal to obtain the resource stored in the in-vehicle terminal from the system layer in the in-vehicle terminal.

[0234] In some embodiments, the resource stored in the in-vehicle terminal is the resource encrypted by the first key; the second key of the resource is the same as the first key, and the second key is the decryption key;

[0235] The fourth sending module 203 is further configured to obtain the first key according to the access permission request; encrypt the first key with a third key negotiated with the application in the in-vehicle terminal to obtain the authorization token; and send the authorization token to the in-vehicle terminal.

[0236] In some embodiments, the access permission request carries the identifier of the resource;

[0237] The fourth sending module 203 is further configured to obtain the first key corresponding to the identifier of the resource according to the access permission request.

[0238] In some embodiments, the first key is the account information of the application.

[0239] In some embodiments, the device further includes:

[0240] The fifth sending module 204 is configured to, before receiving the access permission request sent by the in-vehicle device, encrypt the resource using the first key and send it to the in-vehicle device after attaching aging information.

[0241] In some embodiments, the apparatus further includes:

[0242] The fourth receiving module 205 is configured to receive a resource update request sent by the in-vehicle device after determining that the resource has expired;

[0243] The sixth sending module 206 is configured to send the encrypted resource with updated aging to the in-vehicle device according to the resource update request.

[0244] Regarding Figure 6 and Figure 7 For the apparatus in the illustrated embodiments, the specific manners in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated herein.

[0245] Figure 8 is a block diagram of an in-vehicle device 800 shown according to an exemplary embodiment. Referring to Figure 8 , the device 800 may include one or more of the following components: a processing component 802, a memory 804, a power component 806, a multimedia component 808, an audio component 810, an input / output (I / O) interface 812, a sensor component 814, and a communication component 816.

[0246] The processing component 802 generally controls the overall operation of the device 800, such as operations associated with display, telephone calls, data communication, camera operations, and recording operations. The processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the above method. In addition, the processing component 802 may include one or more modules to facilitate the interaction between the processing component 802 and other components. For example, the processing component 802 may include a multimedia module to facilitate the interaction between the multimedia component 808 and the processing component 802.

[0247] The memory 804 is configured to store various types of data to support the operation of the device 800. Examples of these data include instructions for any application or method operating on the device 800, contact data, phone book data, messages, pictures, videos, etc. The memory 804 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disk.

[0248] The power supply component 806 provides power for various components of the device 800. The power supply component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device 800.

[0249] The multimedia component 808 includes a screen that provides an output interface between the device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can not only sense the boundaries of touch or swipe actions, but also detect the duration and pressure associated with the touch or swipe operation. In some embodiments, the multimedia component 808 includes a front camera and / or a rear camera. When the device 800 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera can receive external multimedia data. Each of the front camera and the rear camera can be a fixed optical lens system or have focal length and optical zoom capabilities.

[0250] The audio component 810 is configured to output and / or input audio signals. For example, the audio component 810 includes a microphone (MIC) that is configured to receive external audio signals when the device 800 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory 804 or transmitted via the communication component 816. In some embodiments, the audio component 810 further includes a speaker for outputting audio signals.

[0251] The I / O interface 812 provides an interface between the processing component 802 and a peripheral interface module, and the peripheral interface module can be a keyboard, a click wheel, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a power-on button, and a lock button.

[0252] The sensor assembly 814 includes one or more sensors for providing a status assessment of various aspects of the device 800. For example, the sensor assembly 814 can detect the on / off state of the device 800, the relative positioning of components, such as the display and keypad of the device 800. The sensor assembly 814 can also detect a change in the position of the device 800 or a component of the device 800, the presence or absence of user contact with the device 800, the orientation or acceleration / deceleration of the device 800, and the temperature change of the device 800. The sensor assembly 814 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 814 can also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 814 can also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0253] The communication component 816 is configured to facilitate communication between the device 800 and other devices in a wired or wireless manner. The device 800 can access a wireless network based on communication standards, such as Wi-Fi, 4G, or 5G, or a combination thereof. In an exemplary embodiment, the communication component 816 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 816 further includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0254] In an exemplary embodiment, the device 800 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for performing the above methods.

[0255] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, and the above instructions can be executed by the processor 820 of the device 800 to complete the above methods. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device, etc.

[0256] A non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by a processor of a vehicle head unit, enables the vehicle head unit to execute an information processing method, and the method includes:

[0257] Send a path request for resources from the application layer in the in-vehicle device to the system layer of the in-vehicle device; wherein, a token is carried in the path request.

[0258] In the system layer, determine whether the token is a pre-stored authorized token; wherein, the authorized token is feedback after the application is authenticated by the server.

[0259] If the token is the authorized token, send the address of the resource in the in-vehicle device to the application layer through the system layer.

[0260] Based on the address, enable the application to obtain the resource through the application layer.

[0261] Figure 9 It is a block diagram of a server device 900 shown according to an exemplary embodiment. Refer to Figure 9 , the device 900 includes a processing component 922, which further includes one or more processors, and memory resources represented by a memory 932 for storing instructions executable by the processing component 922, such as application programs. The application programs stored in the memory 932 may include one or more modules each corresponding to a set of instructions. In addition, the processing component 922 is configured to execute instructions to perform the above information processing method.

[0262] The device 900 may further include a power supply component 926 configured to perform power management of the device 900, a wired or wireless network interface 950 configured to connect the device 900 to a network, and an input / output (I / O) interface 958. The device 900 may operate based on an operating system stored in the memory 932, such as Windows ServerTM, Mac OSXTM, UnixTM, LinuxTM, FreeBSDTM or the like.

[0263] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as the memory 932 including instructions, and the above instructions can be executed by the processing component 922 of the device 900 to complete the above method. For example, the non-transitory computer-readable storage medium may be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device, etc.

[0264] A non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by a processor of a server, enables the server to execute an information processing method, and the method includes:

[0265] Receive an access permission request for resources sent by the in-vehicle head unit; wherein, the access permission request carries the account information of the application.

[0266] Authenticate the application according to the account information of the application, and generate an authorization token after the authentication passes.

[0267] Send the authorization token to the in-vehicle head unit; wherein, the authorization token is used to be saved in the in-vehicle head unit and is used for the application in the in-vehicle head unit to obtain the resources stored in the in-vehicle head unit from the system layer in the in-vehicle head unit.

[0268] After considering the specification and practicing the invention disclosed herein, those skilled in the art will readily conceive of other embodiments of the present disclosure. The present disclosure is intended to cover any variations, uses, or adaptations of the present disclosure, which follow the general principles of the present disclosure and include known common knowledge or conventional technical means in the technical field not disclosed by the present disclosure. The specification and examples are only regarded as exemplary, and the true scope and spirit of the present disclosure are pointed out by the following claims.

[0269] It should be understood that the present disclosure is not limited to the precise structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present disclosure is only limited by the appended claims.

Claims

1. An information processing method, characterized in that Applied to the in-vehicle device terminal, the method includes: Sending, by the application layer in the in-vehicle device terminal, a path request for resources to the system layer of the in-vehicle device terminal; wherein, a token is carried in the path request; Determining, in the system layer, whether the token is a pre-stored authorized token; wherein, the authorized token is feedback after the application is authenticated by the server; If the token is the authorized token, sending, by the system layer, the address of the resources in the in-vehicle device terminal to the application layer; wherein, the resources pointed to by the address are resources symmetrically encrypted using a first key; the authorized token is obtained by the server encrypting the first key using a third key negotiated with the application; Enabling the application to obtain the resources based on the address by the application layer.

2. The method according to claim 1, wherein: The enabling the application to obtain the resources based on the address by the application layer includes: Obtaining, by the application layer, the encrypted resources based on the address; Decrypting, by the application layer, the encrypted resources using a second key paired with the first key, so that the application obtains the decrypted resources.

3. The method according to claim 2, wherein The first key and the second key are the same, and the method further includes: Decrypting, by the application layer, the authorized token using a fourth key negotiated between the application and the server to obtain the second key.

4. The method according to claim 2 or 3, characterized in that, The first key and the second key have a mapping relationship with the resources.

5. The method according to claim 1, characterized in that The authorized token is attached with time limit information; The determining, in the system layer, whether the token is a pre-stored authorized token includes: Determining, in the system layer, whether the content of the token is consistent with the content of the authorized token, and whether the time limit of the token is consistent with the time limit information of the authorized token.

6. The method according to claim 1, wherein The method further includes: Sending a resource access permission request of the application to the server; wherein, the application's account information is carried in the access permission request; Receiving the authorized token feedback by the server after authenticating the account information of the application; Saving the authorized token in the application layer and the system layer.

7. The method according to claim 1, wherein The method further includes: Receiving, by the system layer, the resources sent by the server, and storing the resources in the in-vehicle device terminal at a predetermined address.

8. The method according to claim 7, characterized in that, The resources sent by the server are attached with time limit information, and the method further includes: Determining, by the system layer, whether the resources are within the time limit range at a preset time interval; If the resources are not within the time limit range, requesting the server to update the resources by the system layer.

9. An information processing method, characterized in that, Applied to the server, the method includes: Receiving a resource access permission request of the application sent by the in-vehicle device terminal; wherein, the application's account information is carried in the access permission request; Authenticating the application according to the application's account information, and generating an authorized token after the authentication is passed; Send the authorization token to the in-vehicle device terminal; wherein, the authorization token is used to be stored in the in-vehicle device terminal and is used by an application in the in-vehicle device terminal to obtain resources stored in the in-vehicle device terminal from the system layer in the in-vehicle device terminal; wherein, the resources are resources symmetrically encrypted using a first key; the authorization token is obtained by the server encrypting the first key using a third key negotiated with the application in the in-vehicle device terminal.

10. The method according to claim 9, wherein The second key of the resources is the same as the first key, and the second key is a decryption key. Sending the authorization token to the in-vehicle device terminal according to the access permission request includes: Obtain the first key according to the access permission request. Encrypt the first key using a third key negotiated with the application in the in-vehicle device terminal to obtain the authorization token. Send the authorization token to the in-vehicle device terminal.

11. The method according to claim 10, characterized in that, The access permission request carries an identifier of the resource. Obtaining the first key according to the access permission request includes: Obtain the first key corresponding to the identifier of the resource according to the access permission request.

12. The method according to claim 10, wherein The first key is the account information of the application.

13. The method according to claim 10, characterized in that, The method further includes: Before receiving the access permission request sent by the in-vehicle device terminal, encrypt the resources using the first key, and send them to the in-vehicle device terminal after attaching expiration information.

14. The method according to claim 13, wherein The method further includes: Receive a resource update request sent by the in-vehicle device terminal after determining that the resources have expired. According to the resource update request, send the encrypted resources with updated expiration to the in-vehicle device terminal.

15. An information processing apparatus, characterized in that, Applied to the in-vehicle device terminal, the device includes: A first sending module, configured to send a path request for resources by an application to the system layer of the in-vehicle device terminal through the application layer in the in-vehicle device terminal; wherein, the path request carries a token. A first determining module, configured to determine in the system layer whether the token is a pre-stored authorization token; wherein, the authorization token is feedback by the server after authenticating the application. A second sending module, configured to, if the token is the authorization token, send the address of the resources in the in-vehicle device terminal to the application layer through the system layer; wherein, the resources pointed to by the address are resources symmetrically encrypted using a first key; the authorization token is obtained by the server encrypting the first key using a third key negotiated with the application. An obtaining module, configured to enable the application to obtain the resources based on the address through the application layer.

16. An information processing apparatus, characterized in that, Applied to the server, the device includes: A third receiving module, configured to receive an access permission request for resources by an application sent by the in-vehicle device terminal; wherein, the access permission request carries the account information of the application. A generating module, configured to authenticate the application according to the account information of the application, and generate an authorization token after the authentication passes. A fourth sending module, configured to send the authorization token to the in-vehicle device; wherein, the authorization token is used to be stored in the in-vehicle device and is used by an application in the in-vehicle device to obtain resources stored in the in-vehicle device from the system layer in the in-vehicle device; wherein, the resources are resources symmetrically encrypted using a first key; the authorization token is obtained by the server encrypting the first key using a third key negotiated with the application in the in-vehicle device.

17. An information processing apparatus, characterized in that, Comprising: A processor; A memory for storing processor-executable instructions; Wherein, the processor is configured to execute the information processing method according to any one of claims 1 to 8; or, is configured to execute the information processing method according to any one of claims 9 to 14.

18. A non-transitory computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the in-vehicle device, the in-vehicle device is enabled to execute the information processing method according to any one of claims 1 to 8; or, when the instructions in the storage medium are executed by the processor of the server, the server is enabled to execute the information processing method according to any one of claims 9 to 14.

Images