An application arousal method and apparatus

Abstract

The application discloses an application arousing method and device, and relates to the technical field of computers. A specific implementation of the method comprises the following steps: uploading a signature element of a first application to an agency background system for signature to obtain first signature information; requesting to arouse a second application to perform first business processing through an arousing application jump protocol, wherein parameters of the arousing application jump protocol comprise the first signature information; in response to an arousing request of the first application initiated by the second application through a back-pulling application jump protocol, acquiring parameters of the back-pulling application jump protocol, wherein the parameters comprise second signature information generated by the agency background system; and verifying the second signature information through the agency background system, and arousing the first application to perform second business processing after verification. The implementation can be applied to arousing of mobile applications under a double-layer operation architecture system, and ensures security and non-tamperability of data transmission in the application arousing process.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an application invocation method and apparatus. Background Technology

[0002] A two-tier operating architecture in a digital currency system involves the central bank issuing legal digital currency to designated operating institutions, which are then responsible for exchange and circulation transactions. In electronic payment transactions, especially within a two-tier operating architecture, business needs necessitate the ability to mutually invoke mobile applications. Existing application invocation solutions require both applications to exchange keys for signature verification via their respective backends, and utilize an H5 intermediary page to launch the applications.

[0003] In the process of realizing this invention, the inventors discovered at least the following problems in the prior art:

[0004] The existing solution is not applicable to the mutual invocation of mobile applications under a two-tier operating architecture, and cannot guarantee the security and immutability of data transmission during the application invocation process. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide an application invocation method and apparatus that can be applied to the mutual invocation of mobile applications under a two-tier operating architecture, ensuring the security and immutability of data transmission during the application invocation process.

[0006] To achieve the above objectives, according to one aspect of the present invention, an application invocation method is provided.

[0007] An application invocation method includes: uploading the signature elements of a first application to an institutional backend system for signing to obtain first signature information; requesting the invocation of a second application via an application invocation redirection protocol, wherein the second application performs a first business process, the parameters of the application invocation redirection protocol including the first signature information; responding to an invocation request to the first application initiated by the second application via a pullback application redirection protocol, obtaining the parameters of the pullback application redirection protocol, the parameters of the pullback application redirection protocol including second signature information, the second signature information being generated by the institutional backend system; verifying the second signature information through the institutional backend system, and after the second signature information is verified, invoking the first application to perform a second business process, wherein the institutional backend system is a backend system associated with the first application or the second application.

[0008] Optionally, uploading the signature elements of the first application to the institution's backend system for signing includes: uploading a first set of elements composed of the signature elements of the first application to the institution's backend system for encrypted signing, wherein the first set of elements includes a first common element, a first parameter set, and business-defined parameters of the first application.

[0009] Optionally, the first public element includes the timestamp and validity period of the first signature information; when the first application is a digital currency application and the second application is a third-party application, the first parameter set includes a business identifier; when the first application is a third-party application and the second application is a digital currency application, the first parameter set includes the business identifier and the identifier of the institutional back-end system, and the business identifier is used by the second application to perform the first business processing corresponding to the business identifier.

[0010] Optionally, if the first application is a digital currency application and the second application is a third-party application, the first parameter set may further include first custom additional information; if the first application is a third-party application and the second application is a digital currency application, the first parameter set may further include the unique identifier of the first application and / or the second custom additional information.

[0011] Optionally, the first custom additional information or the second custom additional information includes encryption and signing algorithm information, and the second application uses the encryption and signing algorithm information to verify and decrypt the first signature information.

[0012] Optionally, the parameters of the application invocation redirection protocol may also include the signature elements of the first application and the first parameter set.

[0013] Optionally, before requesting to invoke the second application via the application invocation redirection protocol, the process includes: constructing the application invocation redirection protocol, which includes a protocol name, hostname, path, and parameters; if the first application is a third-party application and the second application is a cryptocurrency application, the protocol name, hostname, and path are provided by the second application; if the first application is a cryptocurrency application and the second application is a third-party application, the protocol name, hostname, and path are provided by the institutional backend system, which is associated with the third-party application.

[0014] Optionally, the parameters of the pullback application redirection protocol further include a second parameter set. The second signature information is generated by the institution's backend system encrypting and signing the second element set, and the second element set includes the second parameter set. The verification of the second signature information by the institution's backend system includes: sending the parameters of the pullback application redirection protocol to the institution's backend system, and having the institution's backend system verify and decrypt the second signature information. If the second signature information passes verification and the second parameter set in the decrypted second element set is consistent with the second parameter set obtained from the parameters of the pullback application redirection protocol, the second signature information is verified successfully.

[0015] According to another aspect of the present invention, an application invocation method is provided.

[0016] An application invocation method includes: responding to a request from a first application to invoke a second application via an application invocation redirection protocol, obtaining parameters of the application invocation redirection protocol, wherein the parameters of the application invocation redirection protocol include first signature information, the first signature information being generated in an institutional backend system, the institutional backend system being a backend system associated with the first application or the second application; verifying the first signature information through the institutional backend system, and invoking the second application to perform a first business process after the first signature information has been verified; signing the result of the first business process through the institutional backend system to obtain second signature information; and requesting the first application to invoke a pullback application redirection protocol so that the first application can perform the second business process, wherein the parameters of the pullback application redirection protocol include the second signature information.

[0017] Optionally, the parameters of the application invocation redirection protocol further include a first parameter set. The first signature information is generated by the institution's backend system encrypting and signing a first element set, and the first element set includes the first parameter set. The verification of the first signature information by the institution's backend system includes: sending the parameters of the application invocation redirection protocol to the institution's backend system, and having the institution's backend system verify and decrypt the first signature information. If the first signature information passes verification and the first parameter set in the decrypted first element set is consistent with the first parameter set obtained from the parameters of the application invocation redirection protocol, the first signature information is verified.

[0018] Optionally, signing the result of the first business processing through the institution's back-end system includes: using the result of the first business processing as a business-defined parameter of the second application, and signing the second element set after encryption through the institution's back-end system. The second element set includes a second common element, a second parameter set, and the business-defined parameter of the second application.

[0019] Optionally, the second public element includes the timestamp and validity period of the second signature information; when the first application is a digital currency application and the second application is a third-party application, the second parameter set includes a business identifier and the identifier of the institution's back-end system; when the first application is a third-party application and the second application is a digital currency application, the second parameter set includes the business identifier; wherein, the business identifier is used by the first application to perform the second business processing corresponding to the business identifier.

[0020] Optionally, if the first application is a digital currency application and the second application is a third-party application, the second parameter set may further include the unique identifier of the second application and / or the first preset custom information; if the first application is a third-party application and the second application is a digital currency application, the second parameter set may further include the second preset custom information.

[0021] Optionally, the first preset custom information or the second preset custom information includes encryption and signing algorithm information, and the first application uses the encryption and signing algorithm information to verify and decrypt the second signature information.

[0022] Optionally, the parameters of the pullback application jump protocol may also include the second element set and the second parameter set.

[0023] Optionally, before requesting to invoke the first application via the pullback application redirection protocol, the process includes: constructing the pullback application redirection protocol, which includes a protocol name, hostname, path, and parameters; when the first application is a third-party application and the second application is a cryptocurrency application, the protocol name, hostname, and path are provided by the institutional backend system, which is associated with the third-party application; when the first application is a cryptocurrency application and the second application is a third-party application, the protocol name, hostname, and path are provided by the first application.

[0024] According to another aspect of the present invention, an application wake-up device is provided.

[0025] An application invocation device includes: a signature element uploading module for uploading the signature elements of a first application to an institutional backend system for signing to obtain first signature information; a second application invocation module for requesting the invocation of a second application via an application invocation redirection protocol, wherein the second application performs a first business process, the parameters of the application invocation redirection protocol including the first signature information; a pullback application parameter acquisition module for responding to an invocation request for the first application initiated by the second application via the pullback application redirection protocol, acquiring the parameters of the pullback application redirection protocol, wherein the parameters of the pullback application redirection protocol include second signature information, the second signature information being generated by the institutional backend system; and a first application invocation module for verifying the second signature information through the institutional backend system, and, after the second signature information is verified, invoking the first application to perform a second business process, wherein the institutional backend system is a backend system associated with the first application or the second application.

[0026] Optionally, the signature element upload module is further configured to: upload a first element set consisting of the signature elements of the first application to the institution's backend system for encrypted signing, wherein the first element set includes a first common element, a first parameter set, and business-defined parameters of the first application.

[0027] Optionally, the first public element includes the timestamp and validity period of the first signature information; when the first application is a digital currency application and the second application is a third-party application, the first parameter set includes a business identifier; when the first application is a third-party application and the second application is a digital currency application, the first parameter set includes the business identifier and the identifier of the institutional back-end system, and the business identifier is used by the second application to perform the first business processing corresponding to the business identifier.

[0028] Optionally, if the first application is a digital currency application and the second application is a third-party application, the first parameter set may further include first custom additional information; if the first application is a third-party application and the second application is a digital currency application, the first parameter set may further include the unique identifier of the first application and / or the second custom additional information.

[0029] Optionally, the first custom additional information or the second custom additional information includes encryption and signing algorithm information, and the second application uses the encryption and signing algorithm information to verify and decrypt the first signature information.

[0030] Optionally, the parameters of the application invocation redirection protocol may also include the signature elements of the first application and the first parameter set.

[0031] Optionally, it also includes an application invocation redirection protocol construction module, used to: construct the application invocation redirection protocol, the application invocation redirection protocol including a protocol name, hostname, path and parameters; when the first application is a third-party application and the second application is a digital currency application, the protocol name, the hostname and the path are provided by the second application; when the first application is a digital currency application and the second application is a third-party application, the protocol name, the hostname and the path are provided by the institutional backend system, the institutional backend system is associated with the third-party application.

[0032] Optionally, the parameters of the pullback application redirection protocol further include a second parameter set. The second signature information is generated by the institution's backend system encrypting and signing the second element set, and the second element set includes the second parameter set. The first application invocation module includes a second signature information verification submodule, used to: send the parameters of the pullback application redirection protocol to the institution's backend system, and have the institution's backend system verify and decrypt the second signature information. If the second signature information passes verification and the second parameter set in the decrypted second element set is consistent with the second parameter set obtained from the parameters of the pullback application redirection protocol, the second signature information is verified.

[0033] According to another aspect of the present invention, an application wake-up device is provided.

[0034] An application invocation device includes: an application invocation parameter acquisition module, configured to acquire parameters of the application invocation protocol in response to an invocation request for a second application initiated by a first application through an application invocation jump protocol, the parameters of the application invocation jump protocol including first signature information, the first signature information being generated in an institutional backend system, the institutional backend system being a backend system associated with the first application or the second application; a second application invocation execution module, configured to verify the first signature information through the institutional backend system, and invoking the second application to execute a first business process after the first signature information has been verified; a signature information acquisition module, configured to sign the result of the first business process through the institutional backend system to obtain second signature information; and a first application invocation execution module, configured to request the invocation of the first application through a pullback application jump protocol so that the first application can execute the second business process, the parameters of the pullback application jump protocol including the second signature information.

[0035] Optionally, the parameters of the application invocation redirection protocol further include a first parameter set, wherein the first signature information is generated by the institution's backend system by encrypting and signing the first element set, and the first element set includes the first parameter set; the second application invocation execution module includes a first signature information verification submodule, used to: send the parameters of the application invocation redirection protocol to the institution's backend system, and have the institution's backend system verify and decrypt the first signature information; if the first signature information is verified and the first parameter set in the decrypted first element set is consistent with the first parameter set obtained from the parameters of the application invocation redirection protocol, the first signature information is verified.

[0036] Optionally, the signature information acquisition module is further configured to: use the result of the first business processing as the business-defined parameter of the second application, and encrypt and sign the second element set through the institution's back-end system, wherein the second element set includes a second public element, a second parameter set, and the business-defined parameter of the second application.

[0037] Optionally, the second public element includes the timestamp and validity period of the second signature information; when the first application is a digital currency application and the second application is a third-party application, the second parameter set includes a business identifier and the identifier of the institution's back-end system; when the first application is a third-party application and the second application is a digital currency application, the second parameter set includes the business identifier; wherein, the business identifier is used by the first application to perform the second business processing corresponding to the business identifier.

[0038] Optionally, if the first application is a digital currency application and the second application is a third-party application, the second parameter set may further include the unique identifier of the second application and / or the first preset custom information; if the first application is a third-party application and the second application is a digital currency application, the second parameter set may further include the second preset custom information.

[0039] Optionally, the first preset custom information or the second preset custom information includes encryption and signing algorithm information, and the first application uses the encryption and signing algorithm information to verify and decrypt the second signature information. Optionally, the parameters of the pullback application redirection protocol also include the second element set and the second parameter set.

[0040] Optionally, it also includes a pullback application redirection protocol construction module, used to: construct the pullback application redirection protocol, the pullback application redirection protocol including a protocol name, hostname, path, and parameters; when the first application is a third-party application and the second application is a digital currency application, the protocol name, hostname, and path are provided by the institutional backend system, and the institutional backend system is associated with the third-party application; when the first application is a digital currency application and the second application is a third-party application, the protocol name, hostname, and path are provided by the first application.

[0041] According to another aspect of the present invention, an electronic device is provided.

[0042] An electronic device includes: one or more processors; and a memory for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the application invocation method provided in the embodiments of the present invention.

[0043] According to another aspect of the present invention, a computer-readable medium is provided.

[0044] A computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the application invocation method provided in the embodiments of the present invention.

[0045] One embodiment of the above invention has the following advantages or beneficial effects: The signature elements of the first application are uploaded to the institutional backend system for signing to obtain first signature information; a second application is invoked via an application invocation jump protocol to execute the first business process, the parameters of which include the first signature information; in response to the second application's invocation request to the first application via a pullback application jump protocol, the parameters of the pullback application jump protocol are obtained, including second signature information generated by the institutional backend system, which is a backend system associated with either the first or second application; the second signature information is verified by the institutional backend system, and after successful verification, the first application is invoked to execute the second business process. This invention is applicable to mutual invocation of mobile applications under a two-tier operating architecture, ensuring the security and immutability of data transmission during application invocation.

[0046] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0047] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0048] Figure 1 This is a schematic diagram of the main steps of an application activation method according to an embodiment of the present invention;

[0049] Figure 2 This is a schematic diagram of the main steps of an application awakening method according to another embodiment of the present invention;

[0050] Figure 3 This is a timing diagram illustrating how a third-party application invokes a digital currency application according to an embodiment of the present invention.

[0051] Figure 4 This is a timing diagram illustrating how a digital currency application invokes a third-party application according to an embodiment of the present invention.

[0052] Figure 5 This is a schematic diagram of the main modules of an application awakening device according to an embodiment of the present invention;

[0053] Figure 6 This is a schematic diagram of the main modules of an application awakening device according to another embodiment of the present invention;

[0054] Figure 7 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0055] Figure 8 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0056] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0057] Figure 1 This is a schematic diagram illustrating the main steps of an application activation method according to an embodiment of the present invention. Figure 1 As shown, the application invocation method of one embodiment of the present invention mainly includes the following steps S101 to S104.

[0058] Step S101: Upload the signature elements of the first application to the institution's backend system for signing to obtain the first signature information;

[0059] Step S102: Request to wake up the second application through the application wake-up jump protocol so that the second application can perform the first business process. The parameters of the application wake-up jump protocol include the first signature information.

[0060] Step S103: In response to the second application's request to invoke the first application via the pullback application jump protocol, obtain the parameters of the pullback application jump protocol. The parameters of the pullback application jump protocol include the second signature information, which is generated by the organization's backend system.

[0061] Step S104: Verify the second signature information through the institution's back-end system. After the second signature information is verified, invoke the first application to execute the second business process.

[0062] The first application and the second application are different mobile applications. The business processing performed by the first application is the second business processing, and the business processing performed by the second application is the first business processing. The mobile application in this embodiment of the invention can be a digital currency application or a third-party application.

[0063] The signature elements of the first application may specifically include a first common element, a first parameter set, and business-defined parameters of the first application. The signature elements of the first application constitute a first element set, that is, the first element set includes the first common element, the first parameter set, and the business-defined parameters of the first application. The business-defined parameters of the first application are determined according to the specific business.

[0064] Uploading the signature elements of the first application to the institution's back-end system for signing specifically includes: uploading the first element set, which consists of the signature elements of the first application, to the institution's back-end system for encryption and then signing.

[0065] The first public element may specifically include the timestamp and validity period of the first signature information.

[0066] In the case where the first application is a digital currency application and the second application is a third-party application, the first parameter set may include a business identifier (or business identification character), which is used to identify the business involved in the current interaction between the first application and the second application.

[0067] When the first application is a third-party application and the second application is a digital currency application, the first parameter set may include a business identifier and an identifier for the institution's back-end system. Specifically, the identifier for the institution's back-end system may be the institution's ID (InstNo).

[0068] The business identifier in the first parameter set is used by the second application to perform the first business processing corresponding to the business identifier.

[0069] In the case where the first application is a digital currency application and the second application is a third-party application, the first parameter set may also include first custom additional information. The first custom additional information includes, but is not limited to, encryption and signature algorithm information, which is used to indicate the algorithm used to encrypt and sign the signature elements of the first application.

[0070] In the case where the first application is a third-party application and the second application is a digital currency application, the first parameter set may also include the unique identifier (appId) of the first application and / or second custom additional information, which includes, but is not limited to, encryption and signature algorithm information.

[0071] The second application uses the encryption and signing algorithm information in the first custom additional information or the second custom additional information to verify and decrypt the first signature information.

[0072] The application invocation redirection protocol, also known as the URL scheme for a first application to invoke a second application, is a protocol that allows applications to redirect to each other. The parameters of the application invocation redirection protocol include the signature elements of the first application and a first parameter set.

[0073] Before requesting to invoke a second application via the invoke application redirection protocol, the invoke application redirection protocol is constructed. The invoke application redirection protocol includes the protocol name, hostname, path, and parameters.

[0074] When the first application is a third-party application and the second application is a digital currency application, the protocol name, hostname, and path are provided by the second application.

[0075] When the first application is a digital currency application and the second application is a third-party application, the protocol name, hostname, and path are provided by the institutional back-end system, which is associated with the third-party application.

[0076] An institutional back-end system is a back-end system associated with either the first or second application. Specifically, the first or second application associated with the institutional back-end system is a third-party application. That is, the association between the institutional back-end system and a third-party application means that the institutional back-end system can be the third-party application's own back-end system, or it can be the back-end system of an operating institution that has a cooperative relationship with the third-party application. The operating institution back-end system is the back-end system of the operating institution responsible for the exchange and circulation of digital currencies.

[0077] The pullback application redirection protocol, also known as the URL scheme for the second application to invoke (pull back) the first application in this embodiment, can also be called the pullback URL scheme. The parameters of the pullback application redirection protocol also include a second parameter set. The second signature information is generated by the organization's backend system encrypting and signing the second element set. The second element set includes the second parameter set, as well as second common elements and the business-defined parameters of the second application. Specifically, the business-defined parameters of the second application include the result of the first business processing.

[0078] The second public element includes the timestamp and validity period of the second signature information.

[0079] When the first application is a cryptocurrency application and the second application is a third-party application, the second parameter set includes a business identifier and an identifier for the institution's back-end system. When the first application is a third-party application and the second application is a cryptocurrency application, the second parameter set includes a business identifier.

[0080] When the first application is a digital currency application and the second application is a third-party application, the second parameter set may further include the unique identifier of the second application and / or the first preset custom information. When the first application is a third-party application and the second application is a digital currency application, the second parameter set may further include the second preset custom information. Both the first and second preset custom information can be set as needed, such as encryption and signature algorithm information, algorithm version information, etc. This embodiment of the invention does not limit the specific content of the preset custom information.

[0081] The verification of the second signature information is performed through the institution's backend system. Specifically, this includes sending the parameters of the pullback application redirection protocol to the institution's backend system, which then verifies and decrypts the second signature information. The second signature information is considered verified if the verification is successful and the second parameter set in the decrypted second element set matches the second parameter set obtained from the pullback application redirection protocol parameters. Generating and verifying the second signature information through the institution's backend system eliminates the need for key exchange between the two applications, ensuring the security and immutability of data transmission.

[0082] Figure 2 This is a schematic diagram illustrating the main steps of an application invocation method according to another embodiment of the present invention. Figure 2 As shown, the application invocation method of one embodiment of the present invention mainly includes the following steps S201 to S204. The content already described in detail in the above embodiments will not be repeated in this embodiment.

[0083] Step S201: In response to the first application's request to invoke the second application through the invoke application jump protocol, obtain the parameters of the invoke application jump protocol. The parameters of the invoke application jump protocol include the first signature information, which is generated in the organization's backend system.

[0084] Step S202: Verify the first signature information through the institution's back-end system. After the first signature information is verified, invoke the second application to execute the first business process.

[0085] Step S203: Sign the result of the first business processing through the organization's back-end system to obtain the second signature information;

[0086] Step S204: The first application is invoked by requesting the pullback application jump protocol so that the first application can perform the second business processing. The parameters of the pullback application jump protocol include the second signature information.

[0087] The parameters of the application invocation redirection protocol (URL Scheme when the first application invokes the second application) also include the first parameter set. The first signature information is generated by the organization's backend system encrypting and signing the first element set. The first element set includes the first parameter set, as well as the first common element and the business-defined parameters of the first application.

[0088] The verification of the first signature information is performed through the institution's backend system. Specifically, this includes sending the parameters of the application redirection protocol to the institution's backend system, which then verifies and decrypts the first signature information. The first signature information is considered verified if the verification is successful and the first parameter set in the decrypted first element set matches the first parameter set obtained from the parameters of the application redirection protocol. Generating and verifying the first signature information through the institution's backend system eliminates the need for key exchange between the two applications, ensuring the security and immutability of data transmission.

[0089] The result of the first business process is signed through the institution's back-end system. Specifically, the result of the first business process is used as a business-defined parameter of the second application. The second element set is encrypted and signed through the institution's back-end system. The second element set includes a second common element, a second parameter set, and business-defined parameters of the second application.

[0090] The second public element includes the timestamp and validity period of the second signature information.

[0091] In the case where the first application is a digital currency application and the second application is a third-party application, the second parameter set includes a business identifier and an identifier of the institution's back-end system.

[0092] In the case where the first application is a third-party application and the second application is a digital currency application, the second parameter set includes a business identifier.

[0093] The business identifier in the second parameter set is used by the first application to perform the second business process corresponding to the business identifier. If the first application is a digital currency application and the second application is a third-party application, the second parameter set may further include the unique identifier of the second application and / or first preset custom information (ExtraInfo).

[0094] If the first application is a third-party application and the second application is a digital currency application, the second parameter set may also include second preset custom information (ExtraInfo).

[0095] The first or second preset custom information includes encryption and signing algorithm information. The first application uses the encryption and signing algorithm information to verify and decrypt the second signature information.

[0096] The parameters of the pullback application redirection protocol (the URL Scheme when the second application invokes (pulls back) the first application) also include a second set of elements and a second set of parameters.

[0097] Before requesting to invoke the first application via the pullback application redirection protocol, a pullback application redirection protocol is constructed, which includes the protocol name, hostname, path, and parameters.

[0098] When the first application is a third-party application and the second application is a cryptocurrency application, the protocol name, hostname, and path are provided by the institutional backend system. The institutional backend system is a backend system associated with either the first or second application. Specifically, the first or second application associated with the institutional backend system is a third-party application; that is, the institutional backend system is associated with a third-party application. When the first application is a cryptocurrency application and the second application is a third-party application, the protocol name, hostname, and path are provided by the first application.

[0099] This invention provides a unified data transmission implementation for mutual invocation between external applications (third-party applications) and digital currency apps (digital currency applications). There are two scenarios: Scenario 1 involves a third-party application invoking a digital currency app, followed by a callback to the third-party application; Scenario 2 involves a digital currency application invoking (i.e., activating) a third-party application, followed by a callback to the digital currency application. The digital currency app in this invention can be various digital currency apps, such as a digital RMB app, a digital USD app, or a digital Euro app, and is not limited to the types of digital currency apps listed above.

[0100] Scenario 1: A third-party application launches a cryptocurrency application, and then the user is redirected back to the third-party application. Due to increasing business demands, a third-party application needs to launch the cryptocurrency app for business processing and return the processing results to the launching application.

[0101] An embodiment of the present invention describes a process for a third-party application to invoke a digital currency application, comprising: the third-party App (application) requests a signature string (i.e., first signature information) from an institutional backend system (hereinafter referred to as the institutional backend) and generates a URLScheme for invocation; the digital currency App is invoked through the URL Scheme; the digital currency App verifies and decrypts the signature string through the institutional backend; the institutional backend returns the successfully decrypted data to the digital currency App; the digital currency App performs business processing (i.e., first business processing); the digital currency App requests the business processing result (i.e., the result of the first business processing) from the institutional backend for encryption and signing processing to obtain second signature information; the digital currency App concatenates the URL Scheme and sends it back to the third-party App; the third-party App verifies and decrypts the second signature information and processes the corresponding business logic (second business processing). In this process, the third-party application is the first application, and the digital currency application is the second application.

[0102] A timing diagram illustrating the invocation of a digital currency application by a third-party application according to an embodiment of the present invention is shown below. Figure 3As shown, the third-party app requests a signature string from the institution's backend (S301); the institution's backend returns the signature string to the third-party app (S302); the third-party app launches the cryptocurrency app via the URL Scheme (S303), where the URL... The scheme can be called the launch URL scheme. The cryptocurrency app verifies the launcher's program signature and decrypts the launch data through the institution's backend (S304). That is, the cryptocurrency app verifies the signature string through the institution's backend, which includes signature verification and decryption operations. The institution's backend verifies the signature string and returns a successful request message (S305). The cryptocurrency app performs business processing (S306), that is, it processes the cryptocurrency app's business logic. The cryptocurrency app sends the business processing result to the institution's backend for encryption and signing (S307). That is, the cryptocurrency app uses the result of the business processing (the result of the first business processing) as the cryptocurrency app's business-defined parameters, and signs the second element set after encryption through the institution's backend. The second element set includes the second public element, the second parameter set, and the cryptocurrency app's business-defined parameters. For details of the second element set, please refer to the descriptions of the above embodiments. The institution's backend returns the encrypted and signed result (S308). The encrypted and signed result returned by the institution's backend is the second signature information. The cryptocurrency app pulls back the third-party app through the URL scheme based on the encrypted and signed result (S309). The scheme can be called a pullback URL scheme. The parameters of this URL scheme include second signature information. The third-party app verifies and decrypts the second signature information, and processes the business logic (S310) based on the decrypted data, i.e., executes the second business processing. The third-party app can verify and decrypt the second signature information through the institution's backend. Specifically, the parameters of the URL scheme can be sent to the institution's backend, which will then verify and decrypt the second signature information. If the second signature information verification passes and the second parameter set in the decrypted second element set matches the second parameter set obtained from the pullback URL scheme, then the second signature information verification passes and the process continues to the next step. If the second signature information verification fails and / or the second parameter set is inconsistent, the entire process terminates.

[0103] In Scenario 1, the launch URL scheme for a third-party application to invoke a cryptocurrency application is designed such that the protocol, hostname, and path are provided by the cryptocurrency application. An example is shown below:

[0104] a) Protocol: example;

[0105] b) Hostname: example.com;

[0106] c) Path: / path;

[0107] d) Parameters: Refer to Table 1.

[0108] Table 1

[0109]

[0110] The JSON string composed of the signature elements (first element set) in Table 1 above is concatenated into a single JSON string, which is obtained by concatenating the information of "time", "validity", "appId", "extraInfo", "biz", "instNo" and "walletId" in Table 1.

[0111] In this embodiment of the invention, the parameters of the URL Scheme need to be URL encoded.

[0112] An example before URL encoding:

[0113] example: / / example.com / path? extraInfo=xxx&appId=22222222&biz=openWallet&instNo=C3333333&signInfo=ecJIb1hJrA2nsRJ3DRPSyQ==&sign=11a22222f2a33ad4b4fc555555ee6666

[0114] Example of URL encoding:

[0115] example: / / example.com / path? extraInfo=xxx&appId=22222222&biz=openWallet&instNo=C3333333&signInfo=ecJIb1hJrA2nsRJ3DRPSyQ%25253D%25253D&sign=11a22222f2a33ad4b4fc555555ee6666

[0116] URL encoding is used to convert “==” in the example above to “%25253D%25253D”.

[0117] Scenario 1: Design of the pull-back URL scheme for a cryptocurrency application to invoke (pull back) a third-party application.

[0118] Format: sourceApplication?signInfo=XXX&sign=XXX;

[0119] Parameters: Refer to Table 2.

[0120] Table 2

[0121]

[0122]

[0123] The signature elements (second element set) in Table 2 above are concatenated into a JSON, that is, the information of "time", "validity", "extraInfo", "biz" and "walletId" in Table 2 is concatenated into JSON data.

[0124] The parameter "walletId" is a custom parameter for the business and can be replaced with the result of the first business processing obtained by the digital currency App.

[0125] In this embodiment of the invention, the parameters of the URL Scheme need to be URL encoded.

[0126] The URL encoding of URL Scheme parameters has been explained in detail above and will not be elaborated upon here or in the following text. An example before URL encoding: icbc: / / icbc.example.com?biz=openWallet&extraInfo=xxx&signInfo=ecJIb1hJrA2nsRJ3DRPSyQ==&sign=22a33333f2a44ad4b9fc555555ee6666

[0127] An example of URL encoding:

[0128] icbc: / / icbc.example.com? biz=openWallet&extraInfo=xxx&signInfo=ecJIb1hJrA2nsRJ3DRPSyQ%25253D%25253D&sign=22a33333f2a44ad4b9fc555555ee6666

[0129] Scenario 2: A cryptocurrency app launches a third-party application, then redirects back to the cryptocurrency app. Due to increasing business demands, the cryptocurrency app needs to launch a third-party application for business processing and return the processing results to the cryptocurrency app.

[0130] An embodiment of the present invention describes a process for a digital currency application to invoke a third-party application, comprising: the digital currency app requesting a signature string from the institution's backend and generating a launch URL scheme; launching the third-party app via the URL scheme; the third-party app verifying and decrypting the signature from the institution's backend; returning the successfully decrypted data to the third-party app; the third-party app performing business processing; the third-party app requesting the business processing result to the institution's backend for encryption and signature processing; the third-party app reassembling the URL scheme and launching it back to the digital currency app; and the digital currency app verifying and decrypting the signature and processing the corresponding business logic. This process is similar to the process of a third-party application invoking a digital currency application in Scenario 1 described above, except that in this process, the digital currency application is the first application and the third-party application is the second application. In Scenario 1, the third-party application is the first application and the digital currency application is the second application. Since the operations performed by the first application in both scenarios (Scenario 1 and 2) are the same, the operations performed by the second application in both scenarios are also the same. For the specific implementation of the process of a digital currency application invoking a third-party application in Scenario 2, please refer to the detailed description of the process of a third-party application invoking a digital currency application in Scenario 1 described above.

[0131] A timing diagram illustrating how a digital currency application (digital currency App) invokes a third-party application (third-party App) according to an embodiment of the present invention is shown below. Figure 4As shown. The digital currency app requests a signature string from the institution's backend (S401), which is the first signature information; the institution's backend returns the signature string to the digital currency app (S402); the digital currency app launches a third-party app through a URL Scheme (S403), which can be called the launch URL Scheme; the third-party app verifies and decrypts the signature (S404), and the third-party app can verify the signature string through the institution's backend, specifically including signature verification and decryption operations; after the signature string is successfully verified, the third-party app is launched and the business logic is implemented (S405), that is, the third-party app executes the first business processing; the third-party app encrypts and signs the business processing result (S406), and the third-party app can send the business processing result to the institution's backend for encryption and signing. Specifically, the institution's backend can encrypt and sign the second element set, which includes the second common element, the second parameter set, and the second application's business-defined parameters. The business-defined parameters are the result of the third-party app's business processing. The second element set is described in the above embodiments; the third-party app launches the third-party app through the pull-back URL. The Scheme invokes the digital currency App, carrying encrypted ciphertext and a signature (S407). The encrypted ciphertext and signature include the second signature information obtained by encrypting and signing the above business processing results. The digital currency App verifies and decrypts the initiator's signature through the institution's backend (S408), that is, the institution's backend verifies and decrypts the second signature information. After the institution's backend successfully verifies and decrypts the signature, it returns a message indicating that the request was successful (S409). If the second signature information is verified and the second parameter set in the decrypted second element set is consistent with the second parameter set obtained from the parameters of the pull-back URL Scheme, then the second signature information is verified successfully, and a message indicating that the request was successful is returned to continue to the next step. If the second signature information is not verified and / or the above second parameter set is inconsistent, then the entire process terminates. The digital currency App uses the decrypted data to perform business logic processing (S410), that is, to execute the second business processing.

[0132] In Scenario 2, the URL scheme for a cryptocurrency app to launch a third-party application is designed as follows: The protocol name, hostname, and path are provided by the institution's backend system, as detailed below:

[0133] a) Agreement: Provided by the organization itself, for example: ICBC;

[0134] b) Hostname: Provided by the organization itself, for example: icbc.example.com;

[0135] c) Path: Provided by the organization itself;

[0136] d) Parameters: Refer to Table 3.

[0137] Table 3

[0138]

[0139] The signature elements (first element set) in Table 3 above are concatenated into a JSON, that is, the information of "time", "validity", "extraInfo", "biz" and "walletId" in Table 3 are concatenated into JSON data.

[0140] In this embodiment of the invention, the parameters of the URL Scheme need to be URL encoded.

[0141] An example before URL encoding:

[0142] icbc: / / icbc.example.com? biz=openWallet&extraInfo=xxx&signInfo=ecJIb1hJrA2nsRJ3DRPSyQ==&sign=22a33333f2a44ad4b9fc555555ee6666

[0143] An example of URL encoding:

[0144] icbc: / / icbc.example.com? biz=openWallet&extraInfo=xxx&signInfo=ecJIb1hJrA2nsRJ3DRPSyQ%25253D%25253D&sign=22a33333f2a44ad4b9fc555555ee6666

[0145] Scenario 2: Design of the pull-back URLScheme for a third-party application to invoke (pull back) a cryptocurrency app

[0146] a)Format: sourceApplication? signInfo=XXX&sign=XXX;

[0147] b) Parameters: Refer to Table 4.

[0148] Table 4

[0149]

[0150]

[0151] The signature elements (second element set) in Table 4 above are concatenated into a JSON string, that is, the information based on "time", "validity", "appId", "extraInfo", "biz" and "walletId" in Table 4 is concatenated into JSON data.

[0152] The parameter "walletId" is a custom parameter for business operations and can be replaced with the result of the first business processing obtained by a third-party application.

[0153] In Tables 1 to 4 above, “[1..1]” in the attribute column indicates a required item, and “[0..1]” indicates a non-required item.

[0154] Parameters for the URL Scheme need to be URL encoded.

[0155] Here is an example before URL encoding:

[0156] example: / / example.com / path? extraInfo=xxx&appId=22222222&biz=openWallet&instNo=333333333&signInfo=ecJIb1hJrA2nsRJ3DRPSyQ==&sign=11a22222f2a33ad4b4fc555555ee6666

[0157] Example of URL encoding:

[0158] example: / / example.com / path? extraInfo=xxx&appId=22222222&biz=openWallet&instNo=333333333&signInfo=ecJIb1hJrA2nsRJ3DRPSyQ%25253D%25253D&sign=11a22222f2a33ad4b4fc555555ee6666

[0159] The organization number mentioned above needs to be assembled by the organization itself.

[0160] The interactive process for mutual revival of mobile applications based on a two-tier operating architecture proposed in this invention achieves the validity and immutability of verification data through self-signing and self-verification by the institution. This ensures the security and immutability of data transmission during mutual revival, meets the data transmission requirements under the two-tier operating architecture, and proposes a data format standard under the two-tier operating architecture, filling the technical gap in mutual revival of mobile applications under the two-tier operating system.

[0161] Figure 5 This is a schematic diagram of the main modules of an application awakening device according to an embodiment of the present invention.

[0162] like Figure 5 As shown, an application invocation device 500 according to an embodiment of the present invention mainly includes: a signature element uploading module 501, a second application invocation module 502, a pull-back application parameter acquisition module 503, and a first application invocation module 504. The application invocation device 500 can be set in a first application, that is, the functions of each module of the device 500 can be the functions of the first application.

[0163] The signature element upload module 501 is used to upload the signature elements of the first application to the institution's back-end system for signing, and obtain the first signature information;

[0164] The second application initiation module 502 is used to request the initiation of a second application through an application initiation jump protocol so that the second application can perform the first business processing. The parameters of the application initiation jump protocol include the first signature information.

[0165] The pullback application parameter acquisition module 503 is used to respond to the second application's request to wake up the first application through the pullback application jump protocol, and to acquire the parameters of the pullback application jump protocol. The parameters of the pullback application jump protocol include the second signature information, which is generated by the organization's backend system.

[0166] The first application invocation module 504 is used to verify the second signature information through the institution's back-end system. After the second signature information is verified, the first application is invoked to execute the second business process. The institution's back-end system is a back-end system associated with the first application or the second application.

[0167] The signature element upload module 501 is specifically used to: upload the first element set, which consists of the signature elements of the first application, to the institution's back-end system for encryption and signing. The first element set includes the first common element, the first parameter set, and the business-defined parameters of the first application.

[0168] The first public element specifically includes the timestamp and validity period of the first signature information.

[0169] In the case where the first application is a digital currency application and the second application is a third-party application, the first parameter set includes a business identifier.

[0170] In the case where the first application is a third-party application and the second application is a digital currency application, the first parameter set includes a business identifier and an identifier of the institution's back-end system.

[0171] The service identifier is used by the second application to perform the first service processing corresponding to the service identifier.

[0172] In the case where the first application is a digital currency application and the second application is a third-party application, the first parameter set may also include first custom additional information.

[0173] In the case where the first application is a third-party application and the second application is a digital currency application, the first parameter set may also include the unique identifier of the first application and / or second custom additional information.

[0174] The first or second custom additional information includes encryption and signing algorithm information, and the second application uses the encryption and signing algorithm information to verify and decrypt the first signature information.

[0175] The parameters of the application jump protocol also include the signature elements of the first application and the first parameter set.

[0176] The application invocation device 500 may also include an application invocation jump protocol construction module for: constructing an application invocation jump protocol, which includes a protocol name, hostname, path, and parameters.

[0177] When the first application is a third-party application and the second application is a digital currency application, the protocol name, hostname, and path are provided by the second application.

[0178] When the first application is a digital currency application and the second application is a third-party application, the protocol name, hostname, and path are provided by the institutional back-end system, which is associated with the third-party application.

[0179] The parameters of the pullback application redirection protocol also include a second parameter set. The second signature information is generated by the institution's back-end system encrypting and signing the second element set, which includes the second parameter set.

[0180] The first application invocation module 504 may include a second signature information verification submodule, which is used to: send the parameters of the pullback application jump protocol to the institution's backend system, and have the institution's backend system verify and decrypt the second signature information. If the second signature information is verified and the second parameter set in the decrypted second element set is consistent with the second parameter set obtained from the parameters of the pullback application jump protocol, the second signature information is verified.

[0181] Figure 6 This is a schematic diagram of the main modules of an application wake-up device according to another embodiment of the present invention. Figure 6As shown, an application invocation device 600 according to an embodiment of the present invention mainly includes: an application invocation parameter acquisition module 601, a second application invocation execution module 602, a signature information acquisition module 603, and a first application invocation execution module 604. The application invocation device 600 can be configured in a second application, that is, the functions of each module of the device 600 can be functions of the second application.

[0182] The application wake-up parameter acquisition module 601 is used to respond to the wake-up request to the second application initiated by the first application through the application wake-up jump protocol, and to acquire the parameters of the application wake-up jump protocol. The parameters of the application wake-up jump protocol include first signature information, which is generated in the institutional back-end system; the institutional back-end system is a back-end system associated with the first application or the second application.

[0183] The second application initiation and execution module 602 is used to verify the first signature information through the institution's back-end system. After the first signature information is verified, the second application is invoked to execute the first business process.

[0184] The signature information acquisition module 603 is used to sign the result of the first business process through the institution's back-end system to obtain the second signature information.

[0185] The first application invocation execution module 604 is used to request the invocation of the first application through the pullback application jump protocol so that the first application can perform the second business processing. The parameters of the pullback application jump protocol include the second signature information.

[0186] The parameters of the application redirection protocol also include the first parameter set. The first signature information is generated by the institution's backend system encrypting and signing the first element set. The first element set includes the first parameter set.

[0187] The second application invocation execution module 602 may include a first signature information verification submodule, which is used to: send the parameters of the application invocation jump protocol to the institution's back-end system, and have the institution's back-end system verify and decrypt the first signature information. If the first signature information is verified and the first parameter set in the first element set obtained by decryption is consistent with the first parameter set obtained from the parameters of the application invocation jump protocol, the first signature information is verified.

[0188] The signature information acquisition module 603 is specifically used to: take the result of the first business processing as the business-defined parameter of the second application, and sign the second element set after encrypting it through the institution's back-end system. The second element set includes the second public element, the second parameter set, and the business-defined parameter of the second application.

[0189] The second public element may include the timestamp and validity period of the second signature information.

[0190] In the case where the first application is a digital currency application and the second application is a third-party application, the second parameter set includes a business identifier and an identifier of the institution's back-end system.

[0191] In the case where the first application is a third-party application and the second application is a digital currency application, the second parameter set includes a business identifier.

[0192] The business identifier is used by the first application to perform the second business processing corresponding to the business identifier.

[0193] In the case where the first application is a digital currency application and the second application is a third-party application, the second parameter set also includes the unique identifier of the second application and / or the first preset custom information.

[0194] In the case where the first application is a third-party application and the second application is a digital currency application, the second parameter set also includes second preset custom information.

[0195] The first or second preset custom information includes encryption and signature algorithm information. The first application uses the encryption and signature algorithm information to verify and decrypt the second signature information.

[0196] The parameters of the pullback application redirection protocol also include a second set of elements and a second set of parameters.

[0197] The application invocation device 600 may also include a pullback application jump protocol construction module for: constructing a pullback application jump protocol, which includes a protocol name, hostname, path, and parameters.

[0198] When the first application is a third-party application and the second application is a digital currency application, the protocol name, hostname, and path are provided by the institutional back-end system, which is associated with the third-party application.

[0199] When the first application is a digital currency application and the second application is a third-party application, the protocol name, hostname, and path are provided by the first application.

[0200] Figure 7 An exemplary system architecture 700 is shown that can be applied to the application invocation method or application invocation device of the present invention.

[0201] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, and 703, a network 704, and a server 705. Network 704 serves as the medium for providing communication links between terminal devices 701, 702, and 703 and server 705. Network 704 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0202] Users can use terminal devices 701, 702, and 703 to interact with server 705 via network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0203] Terminal devices 701, 702, and 703 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0204] Server 705 can be a server that provides various services, such as a backend management server that supports shopping websites browsed by users using terminal devices 701, 702, and 703 (for example only). The backend management server can analyze and process received data such as information query requests, and feed back the processing results (such as payment results - for example only) to the terminal devices.

[0205] It should be noted that the application activation method provided in the embodiments of the present invention is generally executed by terminal devices 701, 702, and 703, and correspondingly, the application activation device is generally disposed in terminal devices 701, 702, and 703.

[0206] It should be understood that Figure 7 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0207] The following is for reference. Figure 8 It shows a schematic diagram of the structure of a computer system 800 suitable for implementing terminal devices or servers in the embodiments of this application. Figure 8 The terminal device or server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0208] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 802 or programs loaded from storage section 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the system 800. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0209] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.

[0210] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the main step schematic diagrams can be implemented as computer software programs. For example, embodiments of this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the main step schematic diagrams. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs the functions defined above in the system of this application.

[0211] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0212] The schematic diagrams and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in the schematic diagrams or block diagrams may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams or schematic diagrams, and combinations of blocks in the block diagrams or schematic diagrams, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0213] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor may be described as including a signature element uploading module, a second application invocation module, a pull-back application parameter acquisition module, and a first application invocation module. The names of these modules do not necessarily limit the module itself; for example, the signature element uploading module may also be described as "a module for uploading the signature elements of a first application to an institutional backend system for signing to obtain first signature information."

[0214] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to: upload the signature elements of a first application to an institutional backend system for signing to obtain first signature information; request the invocation of a second application via an application invocation redirection protocol, so that the second application performs a first business process, wherein the parameters of the application invocation redirection protocol include the first signature information; in response to a request from the second application to invoke the first application via a pullback application redirection protocol, obtain the parameters of the pullback application redirection protocol, wherein the parameters of the pullback application redirection protocol include second signature information, which is generated by the institutional backend system; verify the second signature information through the institutional backend system, and after the second signature information is verified, invoke the first application to perform a second business process. Alternatively, it may include: responding to a request from a first application to invoke a second application via an invocation application redirection protocol, obtaining parameters of the invocation application redirection protocol, wherein the parameters of the invocation application redirection protocol include first signature information, the first signature information being generated in an institutional backend system, the institutional backend system being a backend system associated with the first application or the second application; verifying the first signature information through the institutional backend system, and invoking the second application to execute the first business process after the first signature information has been verified; signing the result of the first business process through the institutional backend system to obtain second signature information; and requesting to invoke the first application via a pullback application redirection protocol so that the first application can execute the second business process, wherein the parameters of the pullback application redirection protocol include the second signature information.

[0215] According to the technical solution of the present invention, the signature elements of the first application are uploaded to the institutional backend system for signing to obtain the first signature information; a second application is invoked through an application invocation jump protocol containing the first signature information so that the second application can perform the first business processing; in response to the second application's invocation request to the first application initiated through the application pullback jump protocol, the parameters of the application pullback jump protocol are obtained; the second signature information in the parameters of the application pullback jump protocol is verified by the institutional backend system, and the first application is invoked to perform the second business processing after the second signature information is verified. The interactive process of mutual invocation of mobile applications based on a two-tier operation architecture proposed in the embodiments of the present invention ensures the security and immutability of data transmission during mutual invocation, meets the data transmission requirements under the two-tier operation architecture, and proposes a data format standard under the two-tier operation architecture, filling the technical gap of mutual invocation of mobile applications under the two-tier operation architecture.

[0216] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An application invocation method, characterized in that, include: The signature elements of the first application are uploaded to the institution's back-end system for signing to obtain the first signature information; A request to invoke a second application is initiated through an application invocation redirection protocol, wherein the parameters of the application invocation redirection protocol include the first signature information; The first signature information is verified by the institution's back-end system. After the first signature information is verified, the second application is invoked to execute the first business process. In response to the second application's request to invoke the first application via the pull-back application redirection protocol, the parameters of the pull-back application redirection protocol are obtained. The parameters of the pull-back application redirection protocol include second signature information, which is generated by the institution's backend system. The institution's backend system verifies the second signature information. After the second signature information is verified, the first application is invoked to execute the second business process. The institution's backend system is a backend system associated with the first application or the second application.

2. The method according to claim 1, characterized in that, The step of uploading the signature elements of the first application to the institution's backend system for signing includes: The first element set, which consists of the signature elements of the first application, is uploaded to the institution's backend system for encryption and signing. The first element set includes a first common element, a first parameter set, and business-defined parameters of the first application. The first public element includes the timestamp and validity period of the first signature information; In the case where the first application is a digital currency application and the second application is a third-party application, the first parameter set includes a business identifier; When the first application is a third-party application and the second application is a digital currency application, the first parameter set includes the business identifier and the identifier of the institution's back-end system. The business identifier is used by the second application to execute the first business processing corresponding to the business identifier.

3. The method according to claim 2, characterized in that, In the case where the first application is a digital currency application and the second application is a third-party application, the first parameter set also includes first custom additional information; In the case where the first application is a third-party application and the second application is a digital currency application, the first parameter set also includes the unique identifier of the first application and / or second custom additional information; The first custom additional information or the second custom additional information includes encryption and signing algorithm information, and the second application uses the encryption and signing algorithm information to verify and decrypt the first signature information.

4. The method according to any one of claims 2 to 3, characterized in that, The parameters of the application invocation redirection protocol also include the signature elements of the first application and the first parameter set.

5. The method according to claim 1, characterized in that, Before requesting to invoke the second application via the application invocation redirection protocol, the process includes: constructing the application invocation redirection protocol, which includes a protocol name, hostname, path, and parameters; When the first application is a third-party application and the second application is a digital currency application, the protocol name, the hostname, and the path are provided by the second application; In the case where the first application is a digital currency application and the second application is a third-party application, the protocol name, the hostname, and the path are provided by the institutional back-end system, which is associated with the third-party application.

6. The method according to claim 1, characterized in that, The parameters of the pullback application redirection protocol also include a second parameter set. The second signature information is generated by the institution's back-end system encrypting and signing the second element set. The second element set includes the second parameter set. When the first application is a digital currency application and the second application is a third-party application, the second parameter set includes a business identifier and the identifier of the institution's back-end system. When the first application is a third-party application and the second application is a digital currency application, the second parameter set includes a business identifier. The verification of the second signature information through the institution's backend system includes: The parameters of the pullback application redirection protocol are sent to the institution's backend system, which verifies and decrypts the second signature information. If the second signature information passes verification and the second parameter set in the decrypted second element set is consistent with the second parameter set obtained from the parameters of the pullback application redirection protocol, the second signature information is verified.

7. An application invocation method, characterized in that, include: In response to a request from the first application to invoke the second application via an application invocation redirection protocol, the parameters of the application invocation redirection protocol are obtained. The parameters of the application invocation redirection protocol include first signature information, which is generated in the institutional backend system, and the institutional backend system is a backend system associated with the first application or the second application. The first signature information is verified by the institution's back-end system. After the first signature information is verified, the second application is invoked to execute the first business process. The result of the first business process is signed through the institution's back-end system to obtain the second signature information; A request to invoke the first application is initiated through a pullback application redirection protocol, wherein the parameters of the pullback application redirection protocol include the second signature information; The second signature information is verified through the institution's backend system. After the second signature information is verified, the first application is invoked to execute the second business process.

8. The method according to claim 7, characterized in that, The parameters of the application invocation redirection protocol also include a first parameter set. The first signature information is generated by the institution's backend system encrypting and signing a first element set. The first element set includes the first parameter set. When the first application is a digital currency application and the second application is a third-party application, the first parameter set includes a business identifier. When the first application is a third-party application and the second application is a digital currency application, the first parameter set includes the business identifier and the identifier of the institution's backend system. The business identifier is used by the second application to perform the first business processing corresponding to the business identifier. The verification of the first signature information through the institution's backend system includes: The parameters of the application invocation redirection protocol are sent to the institution's backend system, which verifies and decrypts the first signature information. If the first signature information passes verification and the first parameter set in the decrypted first element set is consistent with the first parameter set obtained from the parameters of the application invocation redirection protocol, the first signature information is verified.

9. The method according to claim 7, characterized in that, The step of signing the result of the first business processing through the institution's back-end system includes: The result of the first business processing is used as the business-customized parameter of the second application. The second element set is encrypted and signed by the institution's back-end system. The second element set includes a second public element, a second parameter set, and the business-customized parameter of the second application. The second public element includes the timestamp and validity period of the second signature information; In the case where the first application is a digital currency application and the second application is a third-party application, the second parameter set includes a business identifier and the identifier of the institution's back-end system. In the case where the first application is a third-party application and the second application is a digital currency application, the second parameter set includes the business identifier; The service identifier is used by the first application to perform the second service processing corresponding to the service identifier.

10. The method according to claim 9, characterized in that, When the first application is a digital currency application and the second application is a third-party application, the second parameter set also includes the unique identifier of the second application and / or the first preset custom information; In the case where the first application is a third-party application and the second application is a digital currency application, the second parameter set also includes second preset custom information; The first or second preset custom information includes encryption and signing algorithm information. The first application uses the encryption and signing algorithm information to verify and decrypt the second signature information.

11. The method according to any one of claims 9 to 10, characterized in that, The parameters of the pullback application jump protocol also include the second element set and the second parameter set.

12. The method according to claim 7, characterized in that, Before requesting to wake up the first application via the pullback application jump protocol, the process includes: constructing the pullback application jump protocol, which includes a protocol name, hostname, path, and parameters; In the case where the first application is a third-party application and the second application is a digital currency application, the protocol name, the hostname, and the path are provided by the institutional back-end system, which is associated with the third-party application. When the first application is a digital currency application and the second application is a third-party application, the protocol name, the hostname, and the path are provided by the first application.

13. An application wake-up device, characterized in that, include: The signature element upload module is used to upload the signature elements of the first application to the institution's backend system for signing, and obtain the first signature information; The second application initiation module is used to request the initiation of a second application through an application initiation jump protocol, so that the second application can perform the first business processing. The parameters of the application initiation jump protocol include the first signature information. The pullback application parameter acquisition module is used to respond to the second application's request to wake up the first application through the pullback application jump protocol, and to acquire the parameters of the pullback application jump protocol. The parameters of the pullback application jump protocol include second signature information, which is generated by the institution's backend system. The first application invocation module is used to verify the second signature information through the institution's back-end system. After the second signature information is verified, the first application is invoked to execute the second business process. The institution's back-end system is a back-end system associated with the first application or the second application.

14. An application wake-up device, characterized in that, include: The application wake-up parameter acquisition module is used to respond to a wake-up request to the second application initiated by the first application through the application wake-up jump protocol, and to acquire the parameters of the application wake-up jump protocol. The parameters of the application wake-up jump protocol include first signature information, which is generated in the institutional backend system. The institutional backend system is a backend system associated with the first application or the second application. The second application initiation and execution module is used to verify the first signature information through the institution's back-end system. After the first signature information is verified, the second application is invoked to execute the first business process. The signature information acquisition module is used to sign the result of the first business process through the institution's back-end system to obtain the second signature information. The first application invocation and execution module is used to request the invocation of the first application through the pullback application jump protocol, so that the first application can perform the second business processing. The parameters of the pullback application jump protocol include the second signature information.

15. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method as described in any one of claims 1-12.

16. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-12.

Images