Remote service calling method, equipment, system and storage medium
By performing authorization on the calling device and sending permission information to the target device for authentication, the cumbersome authorization operation for cross-device calls in the Android system is solved, improving the user experience and realizing permission verification in cross-device calls.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2020-07-31
- Publication Date
- 2026-04-14
AI Technical Summary
The existing Android application permission management mechanism requires users to perform authorization confirmation on both the calling and called ends when making distributed cross-device calls, which makes the authorization process cumbersome and reduces the user experience.
By performing authorization once on the calling device and sending the permission information to the target device for authentication, the authorization process is simplified, enabling remote service invocation.
It avoids users having to authorize multiple operations on multiple devices, improving the user experience, and provides permission verification in cross-device calls by identifying the calling entity through distributed user IDs.
Smart Images
Figure CN121858322A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of authorization verification technology, and in particular to a remote service invocation method, device, system, and storage medium. Background Technology
[0002] With the continuous development of smart terminals, users own more and more smart electronic devices, such as smartphones, smart TVs, and smartwatches. When a user is using one smart electronic device and wants to access a specific service on another device, such as a phone using the camera of a smart TV to record video during a WeChat video call, the Android system has a complete application permission management mechanism. For example, when an application accesses system services or devices involving user privacy, such as the camera or recording equipment, it needs the user's authorization. However, the existing Android application permission management mechanism has the following shortcomings in distributed cross-device calls: Users need to perform authorization confirmation on both the calling and called ends, which is cumbersome and greatly reduces the user experience. Summary of the Invention
[0003] This invention provides a remote service invocation method, device, system, and storage medium. The remote service invocation method allows for authorization to be performed only once on the invoking device and the corresponding permission information to be sent to the target device for authentication during the process of the invoking device sending a remote service invocation request to the target device. After the target device passes the authentication, the remote service invocation can be realized, avoiding the need for users to authorize multiple times on multiple devices, simplifying the authorization process, and thus improving the user experience.
[0004] This invention provides a remote service invocation method based on a calling device, comprising: Send a remote service call request to the target device, the remote service call request including the calling device ID, the calling application ID, and the target service information; Receive permission information invocation instruction sent by the target device, wherein the permission information invocation instruction includes the invoking application ID and the target service information; The corresponding permission information is sent to the target device according to the permission information invocation instruction. The permission information is used to reflect whether the invoking application has the permission to invoke the target service.
[0005] Furthermore, before sending the remote service call request to the target device, the method further includes: In response to the remote service call request, determine whether it is the first time the calling application has requested to call the target service. If yes, execute the permission determination process; otherwise, execute the process of sending the remote service call request to the target device. The permission determination process includes: The user determines the permission information and saves the permission information locally.
[0006] Furthermore, the process of determining the permission information based on the user and saving the permission information locally includes: An authorization confirmation interface is generated so that users can select whether the application has the permission to call the target service based on the authorization confirmation interface.
[0007] This invention also provides a method for remote service invocation based on a target device, comprising: Receive a remote service call request sent by the calling device, wherein the remote service call request includes the calling device ID, the calling application ID, and the target service information; Send a permission information invocation instruction to the invocation device, the permission information invocation instruction including the invocation application ID and the target service information; Receive permission information sent by the calling device, the permission information being used to reflect whether the calling application has the permission to call the target service; Based on the permission information, determine whether the calling application has the permission to call the target service. If so, execute the call to the target service by the calling application in the calling device.
[0008] Furthermore, before sending the permission information invocation instruction to the invocation device, the method further includes: A distributed user ID is assigned as the calling subject ID based on the calling device ID and the calling application ID. The distributed user ID is used to identify the device and the application. Determine the type of the calling entity ID. If the type of the calling entity ID is a distributed user ID, then execute the process of sending the permission information calling instruction to the calling device. If the type of the calling entity ID is a local ID, then execute the local calling permission verification.
[0009] Furthermore, in the process of determining whether the calling application has the permission to call the target service based on the permission information, if not, the calling application in the calling device is rejected from calling the target service and a call failure message is returned to the calling device.
[0010] This invention also provides a calling device, which includes a processor and a memory. The memory is used to store at least one instruction, which is loaded and executed by the processor to implement the above-described remote service calling method based on the calling device.
[0011] This invention also provides a target device, which includes a processor and a memory. The memory stores at least one instruction, which is loaded and executed by the processor to implement the above-described remote service invocation method based on the target device.
[0012] This invention also provides a system comprising at least one calling device and at least one target device.
[0013] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned remote service invocation method based on the calling device or the aforementioned remote service invocation method based on the target device.
[0014] The above technical solution involves sending a remote service call request from the calling device to the target device. The remote service call request includes the calling device ID, the calling application ID, and the target service information. This allows the target device to identify the calling device, the calling application, and the target service through the received remote service call request. During the process of the calling device sending the remote service call request to the target device, authorization only needs to be performed once on the calling device, and the corresponding permission information needs to be sent to the target device for authentication. Once the target device successfully authenticates, the remote service call can be implemented. This avoids the user having to perform multiple authorization operations on multiple devices, simplifying the authorization process. Only one authorization is required on the calling device, and the target device requests the corresponding permission information of the calling entity from the calling device for authentication. Furthermore, the user only makes a selection operation on the authorization confirmation interface displayed on the calling device when the calling entity first requests to call the target service. Therefore, the permission verification method in this application not only identifies the calling entity through the calling entity ID in cross-device calls but also provides a distributed authentication interface to authenticate cross-device calling entities, improving the user experience. Attached Figure Description
[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0016] Figure 1 This is a schematic diagram of a remote service invocation method based on a calling device provided in an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the authorization confirmation for the call transfer service provided in an embodiment of the present invention; Figure 3This is a schematic diagram of a remote service invocation method based on a target device provided in an embodiment of the present invention; Figure 4 A schematic diagram illustrating the call transfer service provided by a smart TV according to an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the connection and interaction between the calling device and the target device provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the interaction between the calling device and the target device provided in Embodiment 1 of the present invention; Figure 7 This is a schematic diagram of the interaction between the calling device and the target device provided in Embodiment 2 of the present invention; Figure 8 This is a schematic diagram of the interaction between the calling device and the target device provided in Embodiment 3 of the present invention; Figure 9 This is a schematic diagram of the structure of the calling device provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of the target device provided in an embodiment of the present invention; Figure 11 This is a schematic diagram of the structure of a distributed system provided in an embodiment of the present invention. Detailed Implementation
[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0018] The following is a brief explanation of the cross-device authentication process in the prior art: In distributed cross-device calls, a proxy service is added to the called device. For example, if device A calls a service on device B, there will be a proxy service on device B. Device B verifies the permissions of the proxy service, thereby indirectly authenticating the application that initiates the cross-device call.
[0019] Based on the cross-device authentication process in the aforementioned prior art, it can be determined that: In existing technology for cross-device calls, target device B provides a proxy service for calling device A. Target device B authenticates calling device A. Here, target device B can identify the calling entity that makes the target service call as calling device A, but it cannot identify which calling application within the calling device is the calling subject.
[0020] Based on the cross-device authentication process in the aforementioned existing technology, it can also be determined that: When making cross-device calls using existing technology, if calling device A requests to call a certain service of target device B, calling device A needs to perform an authorization locally. When the target device receives the target service call request sent by calling device A, it provides a proxy service for calling device A, enabling the user to authorize calling device A, and provides the corresponding target service after the target device B has successfully authenticated calling device A.
[0021] To avoid the aforementioned defects in the prior art, the embodiments of the present invention provide the following technical solutions to overcome the aforementioned defects in the prior art, as detailed below: Figure 1 This is a schematic diagram of a remote service invocation method based on a calling device provided in an embodiment of the present invention, such as... Figure 1 As shown, the method includes: Step 101: Send a remote service call request to the target device; Step 102: Receive the permission information retrieval instruction sent by the target device; Step 103: Send the corresponding permission information to the target device according to the permission information call instruction.
[0022] Regarding step 101 When a user wants to invoke a target service on another device through an application on one device (such as a device running the Android system) across multiple running devices, they can send a remote service invocation request to that device. The calling device can be considered the calling device, the application sending the remote service invocation request can be considered the calling application, and the called device can be considered the target device. The target service can be a system service or a third-party developed service available for remote invocation. The remote service invocation request sent by the calling device to the target device includes the calling device ID, the calling application ID, and the target service information. For example, when a user is making a video call with a friend using the "Changlian" application on their Huawei smartphone at home, they can choose to invoke the "Call Transfer Service" on their smart TV to transfer the video and audio. This means that the Huawei Changlian app on the smartphone can send a remote service invocation request to the smart TV to invoke the "Call Transfer Service." This remote service invocation request includes the smartphone ID, the Changlian ID, and information used to identify the "Call Transfer Service."
[0023] It should be noted that when an application calls a target service for the first time, the user needs to authorize the application to call that target service. Therefore, before sending a remote service call request to the target device, in response to the request, it is determined whether this is the application's first request to call the target service. If so, a permission determination process is executed. This permission determination process includes generating an authorization determination interface on the application's interface on the calling device, allowing the user to select whether the application has permission to call the target service.
[0024] In this embodiment, the requirement can be further defined as follows: when the calling application calls the target service for the first time and the permission required by the called service is at a dangerous level (such as calling camera, microphone device services, etc.), the user needs to authorize the calling application to call the target service. Similarly, before sending a remote service call request to the target device, in response to the remote service call request, it is determined whether the request is for a target service whose permission level is at a dangerous level for the first time requested by the calling application. If so, a permission determination process is executed, which includes generating an authorization determination interface on the interface of the calling application on the calling device, so that the user can select whether the calling application has the permission to call the target service based on the authorization determination interface.
[0025] For example, such as Figure 2 As shown, when the "Changlian" APP on the calling device (smartphone) makes its first request to access the "Call Transfer Service" of the target device (smart TV), an authorization confirmation interface U2 is generated on top of the "Changlian" APP interface U1. This interface U2 displays a prompt for user authorization confirmation, such as: "Allow Changlian to access the smart TV's Call Transfer Service?" This allows the user to authorize the "Changlian" APP's request to access the "Call Transfer Service." If the user clicks the "Always Allow" button on the authorization confirmation interface, the authorization is complete, meaning the "Changlian" APP on the smartphone has permission to access the smart TV's "Call Transfer Service." In other words, the "Changlian" APP on the smartphone has permission to access the smart TV's camera and microphone. If the user clicks the "Deny" button on the authorization confirmation interface, authorization is denied, meaning the "Changlian" APP on the smartphone does not have permission to access the smart TV's "Call Transfer Service."
[0026] Regarding step 102 After the target device receives a remote service call request from the calling device, in order to confirm whether the calling application requesting the remote service call request has the corresponding calling permissions, the target device will request the corresponding permission information from the calling device. The calling device receives the permission information call instruction sent by the target device, and this permission information call instruction includes the calling application ID and target service information. For example, if the "Changlian" APP on a smartphone calls the "Call Transfer Service" of a smart TV, the smart TV will ask the smartphone whether the "Changlian" APP can access the smart TV's camera and microphone. The smartphone receives the call instruction from the smart TV regarding whether the "Changlian" APP can access the smart TV's camera and microphone permission information. This permission information call instruction also includes the application ID (the ID of the "Changlian" APP) and the target service information (calling the smart TV's "Call Transfer Service").
[0027] Regarding step 103 After receiving a permission information invocation command from the target device, the invoking device will send the corresponding permission information to the target device according to the command. Specifically, after receiving the permission information invocation command and target service information from the target device, the invoking device identifies the corresponding invoking application based on the invoking application ID in the permission information invocation command, determines the permission type based on the target service information in the permission information invocation command, and further queries the locally stored permission data to find the permission information of the identified invoking application regarding the permission type. This permission information reflects whether the invoking application has the permission to invoke the target service. The retrieved permission information is then sent to the target device. For example, a smartphone receives a command from a smart TV requesting permission from the "Changlian" app to access the smart TV's camera and microphone. This permission request includes the application ID (the ID of the "Changlian" app) and the target service information (calling the smart TV's "call forwarding service"). Based on the application ID, the calling application is identified as the "Changlian" app. Based on the target service information, the permission type is identified as smart TV camera access permission and smart TV microphone access permission. Furthermore, the permission information of the "Changlian" app regarding smart TV camera access permission and smart TV microphone access permission in the currently stored permission data is queried, and the retrieved permission information is sent to the smart TV.
[0028] Figure 3 This is a schematic diagram of the remote service invocation method based on the target device provided in an embodiment of the present invention, such as... Figure 3 As shown, the method includes: Step 201: Receive the remote service call request sent by the calling device; Step 202: Send the permission information call command to the calling device; Step 203: Receive permission information sent by the calling device; Step 204: Based on the permission information, determine whether the calling application has the permission to call the target service. If so, execute the call to the target service by the calling application in the calling device.
[0029] Regarding step 201 The target device receives a remote service call request sent by the calling device. This request includes the calling device ID, the calling application ID, and the target service information. For example, when a user makes a video call with a friend using the "Call Forward" app on their Huawei smartphone at home, they can choose to use the "Call Forward Service" on their smart TV to transfer the video and audio. This means the user can send a remote service call request to the smart TV via the Huawei Connect app on their smartphone. This request includes the smartphone ID, the Connect ID, and information used to identify the "Call Forward Service."
[0030] After the target device receives the remote service call request from the calling device, it can assign a Distributed User Identification (DUID) as the caller ID based on the device ID and user ID (UID) in the remote service call request. Then, it initiates a target service call based on the remote service call request, where the initiated target service call includes the Distributed User Identification (DUID) to indicate the caller.
[0031] Furthermore, after the target server receives the target service call, it needs to determine whether the calling entity has the permission to call the target service. First, it needs to determine the type of the calling entity ID. If the type of the calling entity ID is a Distributed User ID (DUID), it is determined that this target service call is a cross-device remote service call, and then it is necessary to send a permission information call instruction to the calling device to determine whether the calling entity has the permission to call the target service. If the type of the calling entity ID is a local ID, it is determined that this target call is a local call, and then a local call permission verification is performed.
[0032] Since the target service call request received by the target server of the target device during the ongoing cross-device remote service call is of the type of Distributed User ID (DUID), it is necessary to send an authorization information call instruction to the calling device, i.e., proceed to step 202.
[0033] Regarding step 202 As described in step 201, to determine whether the calling entity has the permission to call the target service of the target device, it is necessary to send a permission information call instruction to the calling device. Specifically, this permission information call instruction needs to explicitly specify the calling entity and the target service. However, in the target device, the calling entity ID is a Distributed User ID (DUID). Since the calling device cannot identify which application on the calling device corresponds to the Distributed User ID, when the target device sends the permission information call instruction to the calling device, it needs to include the calling entity ID that the calling device can recognize. Since this Distributed User ID (DUID) is assigned by the calling device's device ID and the calling application ID (UID), and the call action of this permission information call instruction is an interaction between the target device and the calling device, it is not necessary to emphasize the calling device ID; it is only necessary to specify the calling application. Therefore, the permission information call instruction can include the calling application ID. Furthermore, it is also necessary to make the calling device aware of the target service corresponding to this permission information call. Therefore, the permission information call instruction also needs to include the target service information. In summary, the target device sends a permission information call instruction to the calling device, and the permission information call instruction includes the calling application ID and the target service information.
[0034] Regarding steps 203-204 After receiving the permission information invocation command from the target device, the invoking device queries the corresponding permission information and sends the queried permission information to the target device. The target device receives the permission information from the invoking device and authenticates it to determine whether the invoking application (the invoking subject) in the invoking device has the permission to invoke the target service in its own device (the target device). If, after authentication, the invoking application has the permission to invoke the target service, then the invoking application in the invoking device executes the invocation of the target service in the target device. For example, if a smart TV successfully authenticates the "Changlian" application on a smartphone, then the "Changlian" application's invocation of the "Call Transfer Service" is successful. Figure 4 As shown, the smart TV executes the "Call Transfer Service," which transfers the video call service to the smart TV. The smart TV's camera captures the video, the screen displays the video call interface U3, and the microphone captures the user's voice conversation. Furthermore, a successful call result can be sent back to the calling device. After authentication, if the calling application does not have permission to call the target service, the application's call to the target service on the target device is rejected, and a call failure result is sent back to the calling device.
[0035] Compared to existing cross-device call authentication methods, the cross-device call and authentication methods described in steps 101-103 and 201-204 above, when a calling application (APP) on the calling device requests to call a target service on the target device, a remote service call request is sent to the target device. This remote service call request includes the calling device ID, the calling application ID, and the target service information. The target device can identify the calling subject through the calling device ID and the calling application ID in the remote service call request, and can further allocate a distributed user ID as the calling subject ID based on the calling device ID and the calling application ID.
[0036] When the target device authenticates the calling entity, it does so by accessing the calling entity's permission information regarding the calling target service stored in the calling device and authenticating the received permission information, without requiring the user to perform an authorization operation on the target device.
[0037] Figure 5 This diagram illustrates the interaction between the calling device and the target device according to an embodiment of the present invention. Figure 5 As shown, the permission verification process for cross-device remote service invocation is fully described in conjunction with the interaction between the calling device and the target device. Devices D1 and D2 are both in a distributed scenario, and both devices D1 and D2 are running the Android system. Device D1 is the calling device, and device D2 is the target device. APPD10 on device D1 makes a cross-device call to the target service D20 on device D2. The target service D20 can be a system service or a third-party developed service that can be remotely invoked.
[0038] like Figure 5 As shown, the distributed scenario where devices D1 and D2 reside provides a Distributed Execution Framework Service (DEFS) and a Distributed Permission Management Service (DPMS). DEFS is used to provide cross-device communication and call proxy in the distributed scenario, providing an interface for device 1 to call the target service of device 2. DPMS provides a distributed permission verification (authentication) interface to the Android native permission management service (PMS) in each device.
[0039] A comparison is made between remote service invocation methods based on the calling and target devices and authentication methods for cross-device invocations in existing technologies, as follows: First, existing technologies cannot distinguish between different applications of the calling subject in cross-device call processing. That is, they cannot further refine the distinction of the calling application based on the calling device, and therefore cannot authorize different applications in the same calling device.
[0040] However, in the technical solution claimed in this application, when the calling application (APP) D10 in the calling device requests to call the target service D20 of the target device, the calling device and the target device can communicate with each other through the DEFS provided by the distributed environment where the calling device and the target device reside. Specifically, the calling device sends a remote service call request to the DEFS (D22) of the target device through the DEFS (D12). This remote service call request includes the calling device ID, the calling application ID, and the target service information. The target device can identify the calling subject through the calling device ID and the calling application ID in the remote service call request, and can further allocate a distributed user ID as the calling subject ID based on the calling device ID and the calling application ID.
[0041] Secondly, existing technologies require two authorization confirmations for cross-device invocation processing: one on the calling device and one on the called device. Specifically, when an application on the calling device requests to invoke a target service on the target device, the user needs to perform authorization confirmation on the calling device and store the confirmed permission information locally. Upon receiving the target service invocation request from the calling device, the target device performs authorization confirmation again, similarly storing the confirmed permission information locally. Only after both the calling and target devices complete authentication can the target service invocation be completed, making the process cumbersome. Furthermore, the aforementioned permission verification process in existing technologies is susceptible to unauthorized invocation. Specifically, since both the calling and target devices store permission information for a particular target service invocation request, if the permission is revoked on the calling device but the target device does not change the status of that permission information, when the calling device sends the same target service invocation request to the target device, the target device remains in an authorized state, leading to unauthorized invocation.
[0042] However, in the technical solution claimed in this application, user authorization confirmation is performed only on the calling device, and the authorized permission information is stored on the calling device. When the target device needs authentication, it requests the corresponding permission information stored in the calling device for authentication. Using the permission information of the calling device as the sole criterion avoids the problem of discrepancies between the permission information of the calling device and the target device regarding the same target service call, which occurs in existing technologies. When the target device authenticates the calling subject, it does so by calling the permission information of the calling subject regarding the target service stored in the calling device and authenticating the received permission information, eliminating the need for the user to perform another authorization operation on the target device.
[0043] Specifically, the following embodiments illustrate the process of APP (D10) on device 1 calling target service on device 2 across devices under different authorization conditions.
[0044] Example 1 The authorization status type corresponding to this embodiment is: the "Changlian" APP (D10) on the smartphone calls the "Call Transfer Service" of the smart TV for the first time, which is used when the call operation is not authorized.
[0045] Figure 6 This diagram illustrates the interaction between the calling device and the target device according to Embodiment 1 of the present invention. Figure 6 As shown, the cross-device invocation process in Embodiment 1 is implemented through multiple steps as shown in the attached figures. Specifically, the embodiment formed by these multiple steps is as follows: Step S001: The user opens the "Changlian" APP (D10) on their smartphone and selects to use the "Call Transfer Service" on the smart TV.
[0046] Step S002: The "Changlian" APP (D10) calls the PMS (D11) interface of the smartphone to request the permission required to call the "Call Transfer Service" of the smart TV.
[0047] Step S003: In response to the request information from the "Changlian" APP (D10) to call the "Call Transfer Service" on the smart TV, the PMS (D11) determines whether the request information is the first request from the "Changlian" APP (D10) to call the "Call Transfer Service" on the smart TV. If the PMS (D11) determines that the request information is the first request from the "Changlian" APP (D10) and the permission level required to call the "Call Transfer Service" (which requires access to the smart TV's camera and microphone, and the access permissions of both devices are at the dangerous level) is dangerous, as shown in 2, the generated authorization determination interface U2 is overlaid on the interface U1 of the "Changlian" APP (D10) on the smartphone.
[0048] Step S004: After the user clicks the "Always Allow" button on the authorization confirmation interface, the authorization operation is completed. The PMS (D11) obtains the user's operation result (authorization result) on the authorization confirmation interface U2 and stores the authorization result as the permission information for the "Changlian" APP (D10) to request the "Call Transfer Service" on the smart TV in the local corresponding database.
[0049] Step S005: After "Changlian" obtains the permission information to call the "Call Transfer Service" of the smart TV through the PMS (D11) interface, "Changlian" further sends the smartphone ID (device ID), "Changlian" ID (APP ID) and information used to identify the "Call Transfer Service" (target service) (remote service call request) to DEFS (D12) to call the smartphone's DEFS (D12) interface to communicate with the smart TV.
[0050] Step S006: DEFS (D12) sends a remote service call request to the smart TV, wherein the remote service call request sent to the smart TV includes the smartphone ID (device ID), the "Connect" ID (APP ID), and information for identifying the "target service".
[0051] Step S007: After receiving the remote service call request sent by the smartphone, the DEFS (D22) of the smart TV allocates a distributed user ID from the resource pool of the reserved distributed user ID (DUID) of the smart TV according to the smartphone ID and "Changlian" ID in the remote service call request.
[0052] Step S008: The DEFS (D22) of the smart TV uses the allocated distributed user ID as the calling subject ID in this cross-device call operation, and sends the target service call request of the calling subject to the target service (D20) of the smart TV. The target service call request contains the calling subject ID, which is the DUID allocated based on the smartphone ID and the "Changlian" ID.
[0053] Step S009: After receiving the target service call request, the target service calls the native authentication interface of the smart TV's Android PMS (D21) based on the DUID to perform permission verification, so as to determine whether the "Changlian" APP (D10) has the permission to call the smart TV's "Call Transfer Service".
[0054] Step S010: The PMS (D21) of the smart TV identifies the calling subject ID type in the target service call request as DUID, and determines that the target service call request of the calling subject is a cross-device remote service call request.
[0055] Step S011: If the target service call request of the calling subject is determined to be a cross-device remote service call request, directly call the DPMS (D23) interface of the smart TV to request authentication.
[0056] Step S012: After the DPMS (D23) of the smart TV receives an authentication request to determine whether the calling entity has the permission to call the target service, it requests a cross-device call to the DPMS (D13) of the smartphone to request the calling entity "Changlian" regarding permission information for calling the "Call Transfer Service". Specifically, the DPMS (D23) calls the DEFS (D22) interface of the smart TV to communicate with the smartphone and sends the permission information call instruction to the DEFS (D12) of the smartphone. The permission information call instruction sent to the DEFS (D12) of the smartphone includes the "Changlian" ID and information for identifying the "Call Transfer Service".
[0057] Step S013: The smartphone's DEFS (D12) sends the received permission information call instruction to the smartphone's DPMS (D13). The smartphone's DPMS (D13) requests permission information from the smartphone's PMS (D11) to allow "Changlian" to call the smart TV's "Call Transfer Service" according to the permission information call instruction.
[0058] Step S014: The smartphone's PMS (D11) sends the queried permission information for "Changlian" to call the smart TV's "Call Transfer Service" back to the smartphone's DPMS (D13).
[0059] Step S015: The smartphone's DPMS (D13) further sends the permission information for "Changlian" to call the smart TV's "Call Transfer Service" to the smart TV's DEFS (D22) through the smartphone's DEFS (D12). The smart TV's DEFS (D22) then feeds back the permission information for "Changlian" to call the smart TV's "Call Transfer Service" to the smart TV's DPMS (D23), thereby synchronizing the access permissions of the "Changlian" APP between the smartphone and the smart TV.
[0060] Step S016: The DPMS (D23) of the smart TV authenticates the permission information of "Changlian" to call the "Call Transfer Service" of the smart TV to determine whether "Changlian" has the permission to call the "Call Transfer Service" of the smart TV. Since the user has already authorized it, the authentication result is that "Changlian" has the permission to call the "Call Transfer Service" of the smart TV, and the authentication is deemed successful. The authentication result is then sent to the PMS (D21) of the smart TV.
[0061] Step S017: If the DPMS (D23) successfully authenticates the permission information of "Changlian" to call the "Call Transfer Service" of the smart TV, the PMS of the smart TV will also send the authentication result back to the target service of the smart TV (D20).
[0062] Step S018: After obtaining the above authentication information, the target service (D20) executes the call transfer service, and the call is successful.
[0063] Step S019: The target service (D20) sends the successful call result to the DEFS (D22) of the smart TV.
[0064] Step S020: Further, the smart TV's DEFS (D22) sends the successful call result to the smartphone's DEFS (D12).
[0065] Step S021: The smartphone's DEFS (D12) sends a successful call result back to the calling application "Changlian" (D10).
[0066] Example 2 The authorization status type corresponding to this embodiment is: the "Changlian" APP (D10) on the smartphone is not calling the "Call Transfer Service" of the smart TV for the first time, and the user's prior authorization has not been cancelled.
[0067] Figure 7 This illustrates an interaction diagram between the calling device and the target device provided in Embodiment 2 of the present invention, as shown below. Figure 7 As shown in the figure, the cross-device invocation process in Embodiment 2 is implemented through multiple steps shown in the attached figures. Specifically, the embodiment formed by these multiple steps is as follows: Step S031: The user opens the "Changlian" APP (D10) on their smartphone and selects to use the "Call Transfer Service" of the smart TV.
[0068] Step S032: The "Changlian" APP (D10) calls the PMS (D11) interface of the smartphone to request the permission required to call the "Call Transfer Service" of the smart TV.
[0069] Step S033: In response to the request information from the "Changlian" APP (D10) to call the "Call Transfer Service" on the smart TV, the PMS (D11) determines whether the request information is the first time the "Changlian" APP (D10) has requested to call the "Call Transfer Service" on the smart TV. If the PMS (D11) determines that the request information is not the first time the "Changlian" APP (D10) has requested to call the "Call Transfer Service", it does not need to request user authorization.
[0070] Step S034: The "Changlian" APP directly sends the smartphone ID (device ID), "Changlian" ID (APP ID), and information used to identify the "target service" to DEFS (D12).
[0071] Step S035: The smartphone's DEFS (D12) sends a remote service call request to the smart TV. The remote service call request sent to the smart TV includes the smartphone ID (device ID), the "Connect" ID (APP ID), and information used to identify the "target service".
[0072] Step S036: After receiving the remote service call request sent by the smartphone, the DEFS (D22) of the smart TV allocates a distributed user ID from the resource pool of the reserved distributed user ID (DUID) of the smart TV according to the smartphone ID and "Changlian" ID in the remote service call request, and uses the allocated distributed user ID as the calling subject ID in this cross-device call operation.
[0073] Step S037: Further, the DEFS (D22) of the smart TV sends the target service call request of the calling subject to the target service (D20) of the smart TV, wherein the target service call request contains the calling subject ID, which is a DUID assigned based on the smartphone ID and the "Changlian" ID.
[0074] Step S038: After receiving the target service call request, the target service (D20) calls the native authentication interface of the smart TV's Android PMS (D21) based on the DUID to perform permission verification in order to determine whether the "Changlian" APP has the permission to call the smart TV's "Call Transfer Service".
[0075] Step S039: The PMS (D21) of the smart TV identifies the calling subject ID type in the target service call request as DUID, and can further determine that the target service call request of the calling subject is a cross-device remote service call request.
[0076] Step S040: If it is determined that the target service call request of the calling subject is a cross-device remote service call request, directly call the DPMS (D23) interface of the smart TV to request authentication.
[0077] Step S041: After the DPMS (D23) of the smart TV receives an authentication request to determine whether the calling entity has the permission to call the target service, it requests a cross-device call to the DPMS (D13) of the smartphone to request the calling entity "Changlian" regarding permission information for calling the "Call Transfer Service". Specifically, the DPMS (D23) calls the DEFS (D22) interface of the smart TV to communicate with the smartphone and sends the permission information call instruction to the DEFS (D12) of the smartphone. The permission information call instruction sent to the DEFS (D12) of the smartphone includes the "Changlian" ID and information for identifying the "Call Transfer Service".
[0078] Step S042: The smartphone's DEFS (D12) sends the received permission information call instruction to the smartphone's DPMS (D13). The smartphone's DPMS (D13) requests permission information from the smartphone's PMS (D11) to allow "Changlian" to call the smart TV's "Call Transfer Service" according to the permission information call instruction.
[0079] Step S043: The smartphone's PMS (D11) sends the queried permission information for "Changlian" to call the smart TV's "Call Transfer Service" back to the smartphone's DPMS (D13).
[0080] Step S044: The smartphone's DPMS (D13) further sends the permission information for "Changlian" to call the smart TV's "Call Transfer Service" to the smart TV's DEFS (D22) via the smartphone's DEFS (D12). The smart TV's DEFS (D22) then feeds back the permission information for "Changlian" to call the smart TV's "Call Transfer Service" to the smart TV's DPMS (D23), thereby synchronizing the access permissions for the "Changlian" APP (D10) between the smartphone and the smart TV.
[0081] Step S045: The DPMS (D23) of the smart TV authenticates the permission information of "Changlian" to call the "Call Transfer Service" of the smart TV to determine whether "Changlian" has the permission to call the "Call Transfer Service". Since the user has previously granted authorization and the authorization has not been revoked, the authentication result is that "Changlian" has the permission to call the "Call Transfer Service" of the smart TV, and the authentication is deemed successful. The authentication result is sent to the PMS (D21) of the smart TV. Step S046: If the DPMS (D23) authenticates the permission information of "Changlian" to call the "Call Transfer Service" of the smart TV, the PMS (D21) of the smart TV will also send the authentication information back to the target service (D20) of the smart TV.
[0082] Step S047: After obtaining the above authentication information, the target service (D20) executes the call transfer service, and the call is successful.
[0083] Step S048: The target service (D20) sends the successful call result to the DEFS (D22) of the smart TV.
[0084] Step S049: Further, the DEFS (D22) of the smart TV sends the success result of the call to the DEFS (D12) of the smartphone.
[0085] Step S050: The smartphone's DEFS (D12) sends a successful call result back to the calling application "Changlian" (D10).
[0086] Example 3 The authorization status type corresponding to this embodiment is: the "Changlian" APP (D10) on the smartphone is not calling the "Call Transfer Service" of the smart TV for the first time, and the previous authorization has been cancelled.
[0087] Figure 8 This illustrates a schematic diagram of the interaction between the calling device and the target device provided in Embodiment 3 of the present invention, as shown below. Figure 8 As shown, the cross-device invocation process in Embodiment 3 is implemented through multiple steps as shown in the attached figures. Specifically, the embodiment formed by these multiple steps is as follows: Step S061: The user cancels the permission for the "Changlian" APP (D10) to access the "Call Transfer Service" of the smart TV in the relevant settings of the smartphone.
[0088] Step S062: The user opens the "Changlian" APP (D10) on their smartphone and selects to use the "Call Transfer Service" of the smart TV.
[0089] Step S063: The "Changlian" APP (D10) calls the PMS (D11) interface of the smartphone to request the permission required to call the "Call Transfer Service" of the smart TV. In response to the request information of the "Changlian" APP (D10) to call the "Call Transfer Service" on the smart TV, the PMS (D11) determines whether the request information is the first time that the "Changlian" APP (D10) has requested to call the "Call Transfer Service" on the smart TV. If the PMS (D11) determines that the request information is not the first time that the "Changlian" APP (D10) has requested to call the "Call Transfer Service", it does not need to ask the user for authorization. "Changlian" directly sends the smartphone ID (device ID), "Changlian" ID (APP ID) and the information used to identify the "Call Transfer Service" (target service) to the DEFS (D12) to call the smartphone's DEFS (D12) interface to communicate with the smart TV. Step S064: The smartphone's DEFS (D11) sends a remote service call request to the smart TV. The remote service call request sent to the smart TV includes the smartphone ID (device ID), the "Connect" ID (APP ID), and information used to identify the "target service".
[0090] Step S065: After receiving the remote service call request sent by the smartphone, the DEFS (D12) of the smart TV allocates a distributed user ID from the resource pool of the reserved distributed user ID (DUID) of the smart TV according to the smartphone ID and "Changlian" ID in the remote service call request, and uses the allocated distributed user ID as the calling subject ID in this cross-device call operation.
[0091] Step S066: The DEFS (D22) of the smart TV sends the target service call request of the calling subject to the target service (D20) of the smart TV. The target service call request contains the calling subject ID, which is a DUID assigned based on the smartphone ID and the "Changlian" ID.
[0092] Step S067: After receiving the target service call request, the target service (D20) calls the native authentication interface of the smart TV's Android PMS (D21) based on the DUID to perform permission verification, so as to determine whether the "Changlian" APP (D10) has the permission to call the smart TV's "Call Transfer Service".
[0093] Step S068: Further, the PMS (D21) of the smart TV identifies the calling subject ID type in the target service call request as DUID, and can further determine that the target service call request of the calling subject is a cross-device remote service call request.
[0094] Step S069: If it is determined that the target service call request of the calling subject is a cross-device remote service call request, directly call the DPMS (D23) interface of the smart TV to request authentication.
[0095] Step S070: After the DPMS (D23) of the smart TV receives an authentication request to determine whether the calling entity has the permission to call the target service, it requests a cross-device call to the DPMS (D13) of the smartphone to request the calling entity "Changlian" regarding permission information for calling the "Call Transfer Service". Specifically, the DPMS (D23) calls the DEFS (D22) interface of the smart TV to communicate with the smartphone and sends the permission information call instruction to the DEFS (D12) of the smartphone. The permission information call instruction sent to the DEFS (D12) of the smartphone includes the "Changlian" ID and information for identifying the "Call Transfer Service".
[0096] Step S071: The smartphone's DEFS (D12) sends the received permission information call instruction to the smartphone's DPMS (D13). The smartphone's DPMS (D13) requests permission information from the smartphone's PMS (D11) to allow "Changlian" to call the smart TV's "Call Transfer Service" according to the permission information call instruction.
[0097] Step S072: The smartphone's PMS (D11) sends the queried permission information for "Changlian" to call the smart TV's "Call Transfer Service" back to the smartphone's DPMS (D13).
[0098] Step S073: The smartphone's DPMS (D13) further sends the permission information for "Changlian" to call the smart TV's "Call Transfer Service" to the smart TV's DEFS (D22) via the smartphone's DEFS (D12). The smart TV's DEFS (D22) then feeds back the permission information for "Changlian" to call the smart TV's "Call Transfer Service" to the smart TV's DPMS (D23), thereby synchronizing the access permissions for the "Changlian" APP (D10) between the smartphone and the smart TV.
[0099] Step S074: The DPMS (D23) of the smart TV authenticates the permission information of "Changlian" to call the "Call Transfer Service" of the smart TV to determine whether "Changlian" has the permission to call the "Call Transfer Service" of the smart TV. Since the user has previously revoked the authorization, the authentication result is that "Changlian" does not have the permission to call the "Call Transfer Service" of the smart TV, and the authentication is deemed to have failed. The authentication result is sent to the PMS (D21) of the smart TV.
[0100] Step S075: If the DPMS (D23) fails to authenticate the permission information of "Changlian" to call the "Call Transfer Service" of the smart TV, the PMS (D21) of the smart TV will also send the authentication failure information back to the target service (D20) of the smart TV.
[0101] Step S076: After receiving the above authentication failure information, the target service (D20) refuses to execute the call transfer service, and this call fails.
[0102] Step S077: The target service (D20) sends the result of the failed call to the DEFS (D22) of the smart TV.
[0103] Step S078: Further, the smart TV's DEFS (D22) sends the call failure result to the smartphone's DEFS (D12).
[0104] Step S079: The smartphone's DEFS (D12) reports the call failure to the calling application "Changlian" (D10).
[0105] If a user wishes to re-invoke the target service after a failed call, they can adjust the permissions for the "Changlian" APP (D10) regarding the "Call Transfer Service" on the smart TV in the corresponding settings on their smartphone; that is, manually authorize it. After completing this manual authorization, when "Changlian" requests the "Call Transfer Service" from the smart TV again, it will meet the authorization status type of Embodiment 2, and the call will be successfully initiated after authentication on the smart TV.
[0106] This invention also provides a calling device, such as... Figure 9 The schematic diagram of the calling device provided in this embodiment of the invention shown shows that the calling device includes a processor 10A and a memory 20A. The memory 20A is used to store at least one instruction. When the instruction is loaded and executed by the processor 10A, it implements the following remote service calling method based on the calling device: Send a remote service call request to the target device, the remote service call request including the calling device ID, the calling application ID, and the target service information; Receive permission information invocation instruction sent by the target device, wherein the permission information invocation instruction includes the invoking application ID and the target service information; The corresponding permission information is sent to the target device according to the permission information invocation instruction. The permission information is used to reflect whether the invoking application has the permission to invoke the target service.
[0107] Furthermore, before sending the remote service call request to the target device, the method further includes: In response to the remote service call request, determine whether it is the first time the calling application has requested to call the target service. If yes, execute the permission determination process; otherwise, execute the process of sending the remote service call request to the target device. The permission determination process includes: The user determines the permission information and saves the permission information locally.
[0108] Furthermore, the process of determining the permission information based on the user and saving the permission information locally includes: An authorization confirmation interface is generated so that users can select whether the application has the permission to call the target service based on the authorization confirmation interface.
[0109] This invention also provides a remote service invocation control device based on a target device, such as... Figure 10 The schematic diagram shown in this embodiment of the invention illustrates a remote service invocation control device based on a target device. The target device includes a processor 10B and a memory 20B. The memory 20B stores at least one instruction, which, when loaded and executed by the processor 10B, implements the following remote service invocation method based on the target device: Receive a remote service call request sent by the calling device, wherein the remote service call request includes the calling device ID, the calling application ID, and the target service information; Send a permission information invocation instruction to the invocation device, the permission information invocation instruction including the invocation application ID and the target service information; Receive permission information sent by the calling device, the permission information being used to reflect whether the calling application has the permission to call the target service; Based on the permission information, determine whether the calling application has the permission to call the target service. If so, execute the call to the target service by the calling application in the calling device.
[0110] Furthermore, before sending the permission information invocation instruction to the invocation device, the method further includes: A distributed user ID is assigned as the calling subject ID based on the calling device ID and the calling application ID. The distributed user ID is used to identify the device and the application. Determine the type of the calling entity ID. If the type of the calling entity ID is a distributed user ID, then execute the process of sending the permission information calling instruction to the calling device. If the type of the calling entity ID is a local ID, then execute the local calling permission verification.
[0111] Furthermore, in the process of determining whether the calling application has the permission to call the target service based on the permission information, if not, the calling application in the calling device is rejected from calling the target service and a call failure message is returned to the calling device.
[0112] This invention also provides a distributed system, and as follows: Figure 11 The diagram shown is a schematic representation of the structure of a distributed system provided in this embodiment of the invention. This distributed system may include multiple devices (D1, D2, D3, D4, D5, Dn), wherein each of these multiple devices includes at least one calling device and at least one target device. The login accounts for these multiple devices can be the same account (e.g., all using the same Huawei account).
[0113] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described remote service invocation method based on the calling device or the above-described remote service invocation method based on the target device.
[0114] It should be noted that the devices involved in the embodiments of the present invention may include, but are not limited to, personal computers (PCs), personal digital assistants (PDAs), wireless handheld devices, tablet computers, mobile phones, MP3 players, MP4 players, etc.
[0115] It is understood that the application may be a native application installed on the terminal, or it may be a web application of a browser on the terminal. This embodiment of the invention does not limit this.
[0116] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0117] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.
[0118] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0119] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.
[0120] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0121] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
[0122] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.
Claims
1. A method for remote service invocation, characterized in that, include: The calling device sends a remote service call request to the target device, the remote service call request including the calling device ID, the calling application ID, and the target service information; The calling device receives a permission information calling instruction sent by the target device, the permission information calling instruction including whether the calling application has the right to access the target service of the target device; The calling device sends the corresponding permission information to the target device according to the permission information calling instruction. The corresponding permission information is used to call the target service of the target device.
2. The method according to claim 1, characterized in that, Before sending the remote service call request to the target device, the method further includes: In response to the remote service call request, determine whether it is the first time the calling application has requested to call the target service. If yes, execute the permission determination process; otherwise, execute the process of sending the remote service call request to the target device. The permission determination process includes: The user determines the permission information and saves the permission information locally.
3. The method according to claim 2, characterized in that, The process of determining the permission information based on the user and saving the permission information locally includes: An authorization confirmation interface is generated so that users can select whether the application has the permission to call the target service based on the authorization confirmation interface.
4. A method for remote service invocation based on a target device, characterized in that, include: Receive a remote service call request sent by the calling device, wherein the remote service call request includes the calling device ID, the calling application ID, and the target service information; Send a permission information invocation instruction to the invocation device, the permission information invocation instruction including the invocation application ID and the target service information; Receive permission information sent by the calling device, the permission information being used to reflect whether the calling application has the permission to call the target service; Based on the permission information, determine whether the calling application has the permission to call the target service. If so, execute the call to the target service by the calling application in the calling device.
5. The method according to claim 4, characterized in that, Before sending the permission information invocation instruction to the invocation device, the method further includes: A distributed user ID is assigned as the calling subject ID based on the calling device ID and the calling application ID. The distributed user ID is used to identify the device and the application. Determine the type of the calling entity ID. If the type of the calling entity ID is a distributed user ID, then execute the process of sending the permission information calling instruction to the calling device. If the type of the calling entity ID is a local ID, then execute the local calling permission verification.
6. The method according to claim 4, characterized in that, In the process of determining whether the calling application has the permission to call the target service based on the permission information, if not, the calling application in the calling device is rejected from calling the target service and a call failure message is returned to the calling device.
7. A calling device, characterized in that, The calling device includes a processor and a memory, the memory being used to store at least one instruction, which, when loaded and executed by the processor, implements the remote service invocation method based on the calling device as described in any one of claims 1-3.
8. A target device, characterized in that, The target device includes a processor and a memory, the memory being used to store at least one instruction, which, when loaded and executed by the processor, implements the remote service invocation method based on the target device as described in any one of claims 4-6.
9. A system, characterized in that, include: At least one calling device as described in claim 7, and at least one target device as described in claim 8.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the remote service invocation method based on the invoking device as described in any one of claims 1-3 or the remote service invocation method based on the target device as described in any one of claims 4-6.