Access control method, related device and system based on authority transfer

By obtaining and passing the permissions required for access requests in the main device, the accuracy and security issues of electronic devices obtaining permissions in distributed scenarios are solved, and resource calls and data security protection between devices are realized.

CN115114637BActive Publication Date: 2025-05-02HUAWEI TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202210221759.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2021-03-23
Filing Date
2022-03-07
Publication Date
2025-05-02
Estimated Expiration
2042-03-07

AI Technical Summary

Technical Problem

In a distributed scenario, how to ensure that the called electronic device can accurately obtain permissions and conduct reliable and secure permission checks to protect data security and user privacy?

Method used

By obtaining the permissions required for access requests in the principal device and passing this permission information to the object device, it allows it to run the corresponding callee instance to access the resource. This method avoids secure authentication of the callee and ensures accurate delivery and isolation of permissions.

Benefits of technology

It realizes resource calls between devices to meet the actual needs of users, and at the same time avoids the expansion of permissions, ensures data security, and prevents data abuse and leakage.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115114637B_ABST
    Figure CN115114637B_ABST
Patent Text Reader

Abstract

The present application provides an access control method, related apparatus and system based on permission transfer. In this method, after receiving multiple access requests for calling the same callee, the object device can create multiple instances of the callee. In addition, the subject device can request the user to grant the permission required for the access request, and send the permission information granted by the user to the object device. The object device can run the corresponding instance of the callee according to the permission information to respond to the access request initiated by the subject device. By implementing this method, the object device can obtain the permission required for the access request, thereby realizing resource calls between devices and meeting the actual needs of users. In addition, the form of providing services in multiple instances can avoid the expansion of permissions, ensure the security of data in the object device, and prevent data abuse and leakage.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application claims priority to Chinese patent application No. 202110310734.X filed on March 23, 2021, and application name “Access control method, related device and system based on authority transfer”, the entire contents of which are incorporated by reference in this application. Technical Field

[0002] The present application relates to the field of computer and communication technology, and in particular to an access control method based on authority transfer, related devices and systems. Background Art

[0003] In a stand-alone scenario involving a single device, the various applications (APPs) in the device can call each other and access various resources in the device. With the development of smart terminals, the types and number of devices in users' lives are increasing, and distributed scenarios where various devices are interconnected are gradually being realized. In distributed scenarios, sharing resources between devices, such as computing power, storage resources, network resources, etc., will become a future trend.

[0004] In order to protect user privacy, relevant technologies require that the electronic device being called must obtain permission to access sensitive information, and can only access the sensitive information after passing the permission check.

[0005] During the calling process, how to ensure that the called electronic device obtains accurate permissions and ensure that the electronic device can perform reliable and secure permission checks on the calling operation, thereby protecting the data security in the electronic device and protecting user privacy, is a problem that needs to be solved urgently. Summary of the invention

[0006] The present application provides an access control method, related device and system based on permission transfer, which can enable the object device to obtain the permission required for the access request, thereby realizing resource calls between devices and meeting the actual needs of users. In addition, it can also avoid permission expansion, ensure the data security in the object device, and prevent data abuse and leakage.

[0007] In the first aspect, an embodiment of the present application provides an access control method based on permission transfer, which is applied to a communication system including a first device, a second device and a third device, wherein a first caller is installed in the first device, a second caller is installed in the second device, and a callee is installed in the third device; the first caller, the second caller and the callee are application programs APP or functional components; APP is a program entity that implements multiple functions, and a functional component is a program entity that implements a single function.

[0008] The method of the first aspect includes: a first device sends a first access request to a third device, the first access request is used by a first caller to call a callee to access a first resource in the third device; a second device sends a second access request to the third device, the second access request is used by a second caller to call a callee to access the first resource; the first device sends first permission information to the third device, the first permission information indicates a first permission granted by a user, the first permission includes a permission to call a callee, and / or a permission to access a first resource; the second device sends a second permission information to the third device, the second permission information indicates a second permission granted by a user, the second permission includes a permission to call a callee, and / or a permission to access a first resource; the third device responds to the first access request, runs a first instance of the callee according to the first permission to access the first resource; the third device responds to the second access request, runs a second instance of the callee according to the second permission to access the first resource. Wherein, the second instance is different from the first instance, the first instance and the second instance are processes or threads running in a random access memory RAM, and the first instance and the second instance are isolated from each other.

[0009] In the method of the first aspect, the first device and the second device may also be referred to as subject devices, and the third device may be referred to as object device.

[0010] By implementing the method provided in the first aspect, regardless of whether the object device or the called party meets the authorization conditions, as long as the subject device or the caller meets the authorization conditions, the object device can obtain the permissions required for the access request, thereby ensuring that the access request initiated by the caller can be successfully responded to, realizing resource calls between devices, and meeting the actual needs of users.

[0011] Furthermore, the method of the first aspect obtains the permissions required for the access request through the main device, and does not rely on the callee to obtain the permissions, nor does it rely on the callee to perform security authentication on the caller, so the method does not have any restrictions on the callee. Regardless of whether the callee is a third-party application or a system application, the implementation of the above method can obtain the permissions required for the access request, and can ensure that only when the caller has the permissions required for the access request, the access request initiated by the caller can be successfully responded to, thereby realizing resource calls between devices and meeting the actual needs of users. In other words, this method can provide system-level access control.

[0012] In addition, in the method provided in the first aspect, the object device provides services to multiple callers in the form of multiple instances, which can ensure that the authority of a caller will only be given to the instance of the callee corresponding to the caller, and can avoid the problems of mixed use of permissions and expansion of permissions, thereby ensuring the security of data in the object device and preventing data abuse and leakage.

[0013] In conjunction with the first aspect, in some implementations, the first permission information further indicates a time limit for the first permission, where the time limit is any one of the following: valid once, valid within a first period of time, valid within a first region, or valid permanently. The third device may run the first instance according to the time limit.

[0014] Specifically, after the third device runs the first instance according to the first permission information to access the first resource, the first device may also send a third access request to the third device, where the third access request is used by the first caller to call the callee to access the first resource. If the time limit is valid once, the third device refuses to respond to the third access request. If the time limit is valid within the first time, and the time length for the third device to receive the first permission information does not exceed the first time; or, if the time limit is valid within the first area, and the third device is located in the first area; or, if the time limit is permanently valid, the third device responds to the third access request and runs the first instance according to the first permission information to access the first resource.

[0015] Through the above implementation, the object device uses the permission to run the instance of the callee created for the caller in the subject device only within the validity period of the permission to respond to the access request initiated by the subject device. In this way, the permissions granted by the user can be accurately controlled to avoid potential permission expansion problems, thereby ensuring the security of data in the object device and preventing data abuse and leakage.

[0016] In conjunction with the first aspect, in some implementations, the first device sends a first access request to the third device, and the first access request carries the first permission information. This can reduce the frequency of interactions between the host and guest devices and improve resource scheduling efficiency in a distributed system.

[0017] In combination with the first aspect, in some implementations, after the third device receives the access request sent by the first device, if the first instance of the callee does not exist in the third device, the third device creates the first instance of the callee in response to the first access request.

[0018] In conjunction with the first aspect, in some implementations, before the first device sends the first permission information to the third device, it may output prompt information, where the prompt information is used to prompt the first permission. The first device may send the first permission information to the third device in response to the received first operation. In this way, the user may grant the first permission by inputting a user operation on the first device.

[0019] In conjunction with the first aspect, in some implementations, before the first device outputs the prompt information, the third device may send an authorization request to the first device in response to the first access request, the authorization request being used to request the user to grant the first permission. In other implementations, the first device may also request the user to grant the first permission before sending the first access request to the third device.

[0020] In combination with the previous embodiment, the first operation includes one or more of the following: a user operation on the display screen, a preset face image, a preset fingerprint, a preset voice command, or a user operation on a button.

[0021] In combination with the previous implementation, the first device may display a first user interface, in which prompt information and a first control are displayed; the first operation includes a user operation acting on the first control.

[0022] In conjunction with the first aspect, in some embodiments, the first permission specifically includes: the permission of the first device to call the callee, and / or the permission of the first device to access the first resource; and / or the permission of the caller to call the callee, and / or the permission of the caller to access the first resource. When the first permission includes information about the first device and / or the first caller, the user can obtain more detailed and detailed information about the permission required for the first access request, thereby deciding whether to grant the first permission. This ensures that the user fully understands the permission required for the access request before performing the authorization operation, which can avoid user misoperation or misauthorization and ensure the data security in the object device.

[0023] In conjunction with the first aspect, in some implementations, the first resource includes: a resource with a privacy level higher than a threshold. For example, the first resource may include a resource that would pose a greater risk to user privacy if leaked. This ensures that when sensitive resources in the object device are accessed, the user's authorization can be obtained, thereby ensuring the security of user data.

[0024] In the second aspect, an embodiment of the present application provides an access control method based on permission transfer, which is applied to an electronic device in which a callee is installed; the callee is an application APP or a functional component, the APP is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function.

[0025] The method provided in the second aspect includes: the electronic device receives a first access request sent by a first device, the first access request is used by a first caller in the first device to call a callee to access a first resource in the electronic device, and the first caller is an APP or a functional component; the electronic device receives a second access request sent by a second device, the second access request is used by a second caller in the second device to call a callee to access the first resource, and the second caller is an APP or a functional component; the electronic device receives first permission information sent by the first device, the first permission information indicates a first permission granted by a user, the first permission includes permission to call the callee, and / or permission to access the first resource; the electronic device receives second permission information sent by the second device, the second permission information indicates a second permission granted by the user, the second permission includes permission to call the callee, and / or permission to access the first resource; the electronic device responds to the first access request, runs a first instance of the callee according to the first permission to access the first resource; the electronic device responds to the second access request, runs a second instance of the callee according to the second permission to access the first resource. Wherein, the second instance is different from the first instance, the first instance and the second instance are processes or threads running in a random access memory RAM, and the first instance and the second instance are isolated from each other.

[0026] By implementing the method provided in the second aspect, the electronic device can obtain the permissions required for the access request, thereby ensuring that the access request initiated by the caller can be successfully responded to, realizing resource calls between devices, and meeting the actual needs of users.

[0027] Furthermore, the method of the second aspect obtains and transmits the permissions required for the access request through the main device, without relying on the callee to obtain the permissions, nor relying on the callee to perform security authentication on the caller, so the method does not have any restrictions on the callee. Regardless of whether the callee is a third-party application or a system application, the implementation of the above method can obtain the permissions required for the access request, and can ensure that only when the caller has the permissions required for the access request, the access request initiated by the caller can be successfully responded to, thereby realizing resource calls between devices and meeting the actual needs of users. In other words, this method can provide system-level access control.

[0028] In addition, in the method provided in the second aspect, the electronic device provides services to multiple callers in the form of multiple instances, which can ensure that the authority of a caller will only be given to the instance of the callee corresponding to the caller, and can avoid the problems of mixed use of permissions and expansion of permissions, thereby ensuring the security of data in the electronic device and preventing data abuse and leakage.

[0029] In the method provided in the second aspect, the various operations performed by the electronic device can refer to the relevant description on the third device side in the method provided in the first aspect, and will not be repeated here.

[0030] On the third aspect, an embodiment of the present application provides an access control method based on permission transfer, which is applied to an electronic device, in which a first caller, a second caller and a callee are installed; the first caller, the second caller and the callee are an application APP or a functional component; the APP is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function.

[0031] The method provided in the third aspect includes: the electronic device generates a first access request, the first access request is used by the first caller to call the callee to access the first resource in the electronic device; the electronic device generates a second access request, the second access request is used by the second caller to call the callee to access the first resource; the electronic device obtains a first permission, the first permission includes the permission to call the callee, and / or the permission to access the first resource; the electronic device obtains a second permission, the first permission includes the permission to call the callee, and / or the permission to access the first resource; the electronic device responds to the first access request, runs the first instance of the callee according to the first permission to access the first resource; the first device responds to the second access request, runs the second instance of the callee according to the second permission information to access the first resource. Wherein, the second instance is different from the first instance, the first instance and the second instance are processes or threads running in the random access memory RAM, and the first instance and the second instance are isolated from each other.

[0032] The method provided in the third aspect is implemented, and the caller in the electronic device obtains the permission required for the access request, without relying on the callee to obtain the permission, nor relying on the callee to perform security authentication on the caller, so the method has no restrictions on the callee. Regardless of whether the callee is a third-party application or a system application, the implementation of the above method can obtain the permission required for the access request, and can ensure that only when the caller has the permission required for the access request, the access request initiated by the caller can be successfully responded to, thereby realizing the resource call in the stand-alone device and meeting the actual needs of the user.

[0033] In addition, in a stand-alone device, the electronic device provides services to multiple callers in the form of multiple instances, which can ensure that the permissions of a caller are only given to the instance of the callee corresponding to the caller, avoiding the problems of mixed permissions and expanded permissions, thereby ensuring the security of data in the electronic device and preventing data abuse and leakage.

[0034] In the first aspect or the second aspect or any one of the above embodiments, the operations performed by the first device or the second device or the third device are all performed by the same electronic device in the method provided in the third aspect, and the interaction between the first device or the second device and the third device can be omitted. For details, please refer to the relevant description above and will not be repeated here.

[0035] In a fourth aspect, an embodiment of the present application provides an electronic device, comprising: a memory and one or more processors; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the electronic device to execute a method such as the second aspect or any one of the implementation methods of the second aspect.

[0036] In the fifth aspect, an embodiment of the present application provides an electronic device, comprising: a memory and one or more processors; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the electronic device to execute a method such as the third aspect or any one of the implementation methods of the third aspect.

[0037] In a sixth aspect, an embodiment of the present application provides a communication system, comprising a first device, a second device and a third device, wherein the third device is used to execute a method as in the second aspect or any one of the implementation modes of the second aspect.

[0038] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, including instructions, which, when executed on an electronic device, cause the electronic device to execute a method as in the second aspect or any one of the embodiments of the second aspect.

[0039] In an eighth aspect, an embodiment of the present application provides a computer program product. When the computer program product runs on a computer, it enables the computer to execute the method of the second aspect or any one of the implementation methods of the second aspect.

[0040] In a ninth aspect, an embodiment of the present application provides a computer-readable storage medium, comprising instructions, which, when executed on an electronic device, enable the electronic device to execute a method as in the third aspect or any one of the implementations of the third aspect.

[0041] In the tenth aspect, an embodiment of the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method of the third aspect or any one of the implementation modes of the third aspect.

[0042] By implementing the technical solution provided by this application, the object device can obtain the permissions required for the access request, thereby realizing resource calls between devices and meeting the actual needs of users. In addition, the form of providing services in multiple instances can avoid the expansion of permissions, ensure the security of data in the object device, and prevent data abuse and leakage. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A schematic diagram of a method for granting and checking permissions;

[0044] Figure 2A A schematic diagram of the structure of a communication system 10 provided in an embodiment of the present application;

[0045] Figure 2B A distributed scenario provided for an embodiment of the present application;

[0046] Figure 3A A hardware structure diagram of an electronic device provided in an embodiment of the present application;

[0047] Figure 3B A software structure diagram of an electronic device provided in an embodiment of the present application;

[0048] Figure 4 A flowchart of an access control method based on permission transfer provided in an embodiment of the present application;

[0049] Figure 5A-Figure 5B A set of user interfaces implemented on the main device 200 provided in an embodiment of the present application;

[0050] Figure 5C-5E A set of user interfaces implemented on the main device 300 provided in an embodiment of the present application;

[0051] Fig. 5F A user interface implemented on the object device 100 provided in an embodiment of the present application;

[0052] Fig. 6A A user interface implemented on the object device 100 provided in an embodiment of the present application;

[0053] Figure 6B The user interface implemented on the main device 300 provided in the embodiment of the present application;

[0054] Fig. 7A A software structure diagram of the main device provided in the embodiment of the present application;

[0055] Figure 7B A software structure diagram of the object device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0056] The technical solutions in the embodiments of the present application will be described clearly and in detail below in conjunction with the accompanying drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0057] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

[0058] The term "user interface (UI)" in the following embodiments of the present application refers to a medium interface for interaction and information exchange between an application or operating system and a user, which realizes the conversion between the internal form of information and the form acceptable to the user. The user interface is a source code written in a specific computer language such as Java and extensible markup language (XML). The interface source code is parsed and rendered on an electronic device, and finally presented as content that can be recognized by the user. The commonly used form of user interface is a graphical user interface (GUI), which refers to a user interface related to computer operation displayed in a graphical manner. It can be a visual interface element such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, widgets, etc. displayed on the display screen of an electronic device.

[0059] In a distributed system including multiple electronic devices, if the electronic device being accessed does not meet the authorization conditions, or the called application does not meet the authorization conditions, the electronic device cannot obtain the permission granted by the user to access the resources, and therefore cannot implement resource calls in a single device or between devices, and cannot meet the actual needs of the user. An electronic device meeting the authorization conditions means that the electronic device supports one or more authorization methods for user authorization. Authorization methods may include, but are not limited to: pop-up authorization, fingerprint verification authorization, face verification authorization, voice command authorization, button authorization, etc., which are not limited here. An application not meeting the authorization conditions means that the application cannot use the various authorization methods provided by the electronic device. For example, when the application does not provide a user interface, the application does not support pop-up authorization.

[0060] When multiple applications (such as APP1 and APP2) call an application (such as APP3) at the same time, APP3 will provide services to both APP1 and APP2 in the form of a single instance. In this case, the permissions of APP1 and APP2 may be mixed by the single instance of APP3, resulting in the problem of expanded permissions, which cannot guarantee the security of data and user privacy.

[0061] like Figure 1 As shown, Figure 1 A way of granting permissions and checking permissions is shown.

[0062] like Figure 1 As shown, APP1 calls APP3, which is a system application trusted by the electronic device. Therefore, the electronic device can directly open the access rights of sensitive resources to APP3. The permission for APP1 to call APP3 can be obtained by the electronic device from the user. After APP3 receives the access request initiated by APP1, it needs to perform the following two permission checks: 1. First, APP3 checks whether APP1 has the permission to call APP3. 2. Then the system checks whether APP3 has the permission to access the resources to be accessed by the access request initiated by APP1. After the two permission checks are passed, APP3 can access the corresponding resources and provide services for APP1.

[0063] visible, Figure 1 The solution shown is only applicable to the case where APP3 is a trusted system application. If the application called in the actual calling process is not a trusted system application, the application cannot obtain the permission to access the corresponding resource, and thus cannot successfully access the resource.

[0064] In addition, Figure 1 In the solution shown, the trusted system application APP3 is relied upon to check whether APP1 has the authority to call APP3. However, the application called in the actual calling process is not necessarily a trusted system application, and relying on the application to perform security authentication on the initiator of the call cannot guarantee the reliability and accuracy of the security authentication result, and thus cannot guarantee the data security during the calling process.

[0065] In order to solve the above problems, the following embodiments of the present application provide an access control method based on permission transfer, which can be applied to a single device or a distributed system including multiple electronic devices.

[0066] When the method is applied to a distributed system, if the object device receives multiple access requests for calling the same callee, the object device can create multiple instances of the callee, and one instance of the callee is used to respond to the access request initiated by one caller. In addition, the main device where the caller is located can also request the user to grant the permission required for the access request initiated by itself, and send the permission information granted by the user to the object device. After that, the object device can run the instance of the callee created for the caller in the main device according to the permission information to respond to the access request initiated by the main device.

[0067] Through the above method, regardless of whether the object device or the callee meets the authorization conditions, as long as the subject device or the caller meets the authorization conditions, the object device can obtain the permissions required for the access request, thereby ensuring that the access request initiated by the caller can be successfully responded to, realizing resource calls between devices, and meeting the actual needs of users.

[0068] Furthermore, the above method obtains the permissions required for the access request through the main device, and does not rely on the callee to obtain the permissions, nor does it rely on the callee to perform security authentication on the caller. Therefore, this method does not have any restrictions on the callee. Regardless of whether the callee is a third-party application or a system application, the implementation of the above method can obtain the permissions required for the access request, and can ensure that only when the caller has the permissions required for the access request, the access request initiated by the caller can be successfully responded to, thereby realizing resource calls between devices and meeting the actual needs of users. In other words, this method can provide system-level access control.

[0069] In addition, the object device provides services to multiple callers in the form of multiple instances, which can ensure that the permissions of a caller are only given to the instance of the callee corresponding to the caller, avoiding the problems of mixed permissions and expanded permissions, thereby ensuring the security of data in the object device and preventing data abuse and leakage.

[0070] In some embodiments, the permission required for the access request requested by the subject device for the user to grant may be time-limited, such as temporary validity, validity within a certain period of time, or permanent validity, etc. In this way, the object device only uses the permission to run the instance of the callee created for the caller in the subject device within the validity period of the permission to respond to the access request initiated by the subject device. In this way, the permissions granted by the user can be accurately controlled to avoid potential permission expansion problems, thereby ensuring the security of data in the object device and preventing data abuse and leakage.

[0071] In the above method, the multiple access requests received by the object device may come from one subject device or from multiple subject devices.

[0072] When the access control method provided by the embodiment of the present application is applied to a stand-alone device, if the electronic device generates multiple access requests for calling the same callee, the electronic device can create multiple instances of the callee, and one instance of the callee is used to respond to the access request initiated by the caller. In addition, the electronic device can also request the user to grant the permission required for the access request initiated by itself when running the caller, and can run the instance of the callee created for the caller in the access request according to the permission information to respond to the access request.

[0073] In a stand-alone device, the above method obtains the permissions required for the access request through the caller in the electronic device, and does not rely on the callee to obtain the permissions, nor does it rely on the callee to perform security authentication on the caller, so the method has no restrictions on the callee. Regardless of whether the callee is a third-party application or a system application, the implementation of the above method can obtain the permissions required for the access request, and can ensure that only when the caller has the permissions required for the access request, the access request initiated by the caller can be successfully responded to, thereby realizing the resource call in the stand-alone device and meeting the actual needs of users.

[0074] In addition, in a stand-alone device, the electronic device provides services to multiple callers in the form of multiple instances, which can ensure that the permissions of a caller are only given to the instance of the callee corresponding to the caller, avoiding the problems of mixed permissions and expanded permissions, thereby ensuring the security of data in the electronic device and preventing data abuse and leakage.

[0075] In a stand-alone device, the permissions required for the access request that the electronic device requests the user to grant may also be time-limited. For details, please refer to the relevant description above.

[0076] In the embodiments of the present application, an instance is an APP or functional component in a running state. An instance can refer to a process or a thread. A process is an execution activity of an application on a computer. A thread is a single sequential control flow in the execution of an application. A process can include multiple threads.

[0077] Instances are isolated from each other. Electronic devices will assign physical addresses in random access memory (RAM) to different instances on a process basis. When an electronic device needs to run an instance, it will find the space in RAM corresponding to the instance based on the virtual address and run the instance in the space. The virtual address is mapped to the physical address assigned to the instance by the electronic device, and the mapping relationship is stored in the controller of the electronic device. In other words, the instance finds the actual storage location of the memory data through the virtual address. Under such a mechanism, different instances can only access the physical address corresponding to their own virtual address through their own virtual address, that is, they cannot access each other's physical space in RAM, so the instances are isolated from each other.

[0078] The definitions of the subject device, the object device, the caller, and the callee may refer to the relevant description of the embodiments below.

[0079] Below, the communication system provided by the embodiment of the present application is first introduced.

[0080] like Figure 2AAs shown, the embodiment of the present application provides a communication system 10. The communication system 10 includes: a plurality of electronic devices. The communication system 10 may also be referred to as a distributed system 10.

[0081] The multiple electronic devices included in the distributed system 10 are all intelligent terminal devices, which can be of various types. The embodiments of the present application do not limit the specific types of the multiple electronic devices. For example, the multiple electronic devices include mobile phones, and may also include tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, smart screens, wearable devices, augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, car machines, smart headphones, game consoles, and may also include Internet of Things (IOT) devices or smart home devices such as smart water heaters, smart lamps, smart air conditioners, etc. Without limitation, the multiple devices in the distributed system 10 may also include non-portable terminal devices such as laptop computers with touch-sensitive surfaces or touch panels, desktop computers with touch-sensitive surfaces or touch panels, and the like.

[0082] When multiple electronic devices in the distributed system 10 are all devices deployed in a home, the distributed system 10 can also be called a home distributed system.

[0083] Multiple electronic devices in the distributed system 10 can be connected by logging in to the same account. For example, multiple electronic devices can log in to the same Huawei account and remotely connect and communicate through the server.

[0084] Multiple electronic devices in the distributed system 10 can also log in to different accounts, but are connected by binding. After an electronic device logs in to an account, it can bind and log in to other electronic devices with different accounts or not logged in in the device management application, and then these electronic devices can communicate through the device management application.

[0085] Multiple electronic devices in the distributed system 10 can also establish connections by scanning QR codes, touching near field communication (NFC), searching for Bluetooth devices, etc., and there is no limitation here.

[0086] In general, the communication connections established between multiple electronic devices in the distributed system 10 may include but are not limited to: wired connections, wireless connections such as Bluetooth (BT) connections, wireless local area networks (WLAN) such as wireless fidelity point to point (Wi-Fi P2P) connections, near field communication (NFC) connections, infrared technology (IR) connections, and remote connections (such as connections established through a server), etc.

[0087] In addition, multiple electronic devices in a distributed system may also be connected and communicated in combination with any of the above-mentioned methods, and the embodiments of the present application do not impose any restrictions on this.

[0088] Multiple electronic devices in the distributed system 10 can be configured with different software operating systems (OS), including but not limited to Etc. Among them, It is Huawei's Hongmeng system.

[0089] The multiple electronic devices may also be configured with the same software operating system, for example, they may all be configured with The software systems of multiple electronic devices are When the distributed system 10 is used, it can be regarded as a super terminal.

[0090] In the embodiment of the present application, each device in the distributed system 10 may install a traditional application (APP), such as a camera application, a gallery application, a setting application, etc. In the subsequent embodiments, the traditional APP may be referred to as APP for short.

[0091] In addition, the distributed system 10 provided in the embodiment of the present application can install a distributed application. The distributed application can be a system application or a third-party application, which is not limited here. System applications refer to applications provided or developed by manufacturers of electronic devices, and third-party applications refer to applications provided or developed by manufacturers of non-electronic devices. Manufacturers of electronic devices may include manufacturers, suppliers, providers or operators of the electronic devices. Manufacturers may refer to manufacturers that manufacture electronic devices with self-made or purchased parts and raw materials. Suppliers may refer to manufacturers that provide complete machines, raw materials or parts for the electronic devices. Operators may refer to manufacturers responsible for the distribution of the electronic devices.

[0092] Unlike apps that contain multiple capabilities, distributed applications support deployment in units of a single capability. A distributed application consists of one or more functional components.

[0093] A functional component is the smallest unit of capability that can run independently in an electronic device. It is a concept that abstractly encapsulates a single capability. An APP combines multiple functions together, while a functional component treats each function as a separate service-oriented basic capability and exists independently. In other words, a functional component is a program entity that implements a single function.

[0094] Each functional component can be downloaded, installed and run independently. Multiple functional components constituting the same distributed application can be deployed in the same electronic device in the distributed system 10 or in different electronic devices.

[0095] Functional component is just a term used in this embodiment. Its meaning has been recorded in this embodiment, and its name does not constitute any limitation to this embodiment. In addition, in some other embodiments of this application, functional component can also be called system component, system service, business function and other terms. Subsequent embodiments of this application are uniformly described as "functional component".

[0096] by For example, The functional components in can include the following two categories:

[0097] (1)Feature ability, FA.

[0098] FA is a functional component that includes one or more UI groups and can provide the ability to interact with users. For example, the navigation interface in a map application, the video call interface in an instant messaging application, etc. can be implemented as FA.

[0099] In some embodiments, FA is developed based on the MVVM (model-view-view-model) pattern, which separates the view UI from the business logic, and deploys the business logic code and the view UI code separately. For example, an electronic device can install the business logic code together with other apps, while the view UI code can be installed in other electronic devices. The device where the view UI code is located can communicate with the device where the business logic code is located to obtain the data required to display the UI.

[0100] FA supports page template capabilities, such as Empty Ability, Login Ability, Setting Ability, etc. FA uses scripting language (javascript, JS) to provide a declarative development model, uses HTML and cascading style sheet (CSS) declarative programming language as the development language for page layout and page style, and supports ECMAScript specification JS language to provide page business logic.

[0101] FA has the capabilities of free installation, independent operation, cross-device UI migration, cross-device binary migration, etc. FA also has the characteristics of multi-terminal deployment and distributed execution.

[0102] FA can call AA or APP to achieve more and more complex functions.

[0103] (2) Particle ability, PA.

[0104] PA is a functional component without UI, which can provide support for FA. For example, PA can provide computing power as a background service, or provide data access capability as a data warehouse. For example, beauty function, positioning function, audio and video encoding and decoding function, etc. can be encapsulated as PA.

[0105] PA also has features such as multi-terminal deployment and distributed execution. PA is only dependent on system services and has no dependencies with other PAs.

[0106] PA actually encapsulates remote virtualization, remote calling, PA management, cross-platform compatibility, security and other implementations, and opens cross-device service enablement and invocation to developers, so that other devices can call the computing power of this device and collaborate with other devices to complete computing work. PA supports Service Ability, Data Ability, etc. Service Ability is used to provide the ability to run tasks in the background. Data Ability is used to provide unified data access abstraction to the outside world.

[0107] PA can call FA or APP to achieve more and more complex functions.

[0108] It is understandable that "FA" and "PA" are just words used in this embodiment, and in other embodiments of the present application, they can also be referred to as other terms. For example, "PA" and "FA" can also be referred to as other terms such as atomic capability (AA), atomic application, meta-capability, atomic service, characteristic capability, etc.

[0109] Multiple functional components that make up a distributed application can be developed or provided by the same developer or by multiple developers separately. There is no restriction here. Different developers jointly developing functional components can improve the development efficiency of distributed applications.

[0110] In the embodiments of the present application, the functional component provides a standardized interface for external invocation. The APP can call the functional component. In some cases, the functional component can also call other functional components or APPs. In addition, the called functional component can also continue to call other functional components or APPs. This multi-level calling method can be called a chain call.

[0111] After each device in the distributed system 10 establishes a communication connection, each device will synchronize the functional component information and APP information of other devices in the distributed system. Specifically, each device can synchronize the names of the functional components and APPs installed by itself to other devices, so as to facilitate the subsequent calling of the FA, PA and other functional components of other devices in the distributed system 10. In some other embodiments, each device can also synchronize its own device identification, device type, etc. to other devices in the distributed system.

[0112] refer to Figure 2B , Figure 2B A possible distributed remote teaching service scenario is exemplified.

[0113] like Figure 2B As shown in the figure, the distributed system includes electronic devices such as smartphones, tablets, and smart screens. Each device in the distributed system is connected to each other. Smartphones, tablets, and smart screens can be configured with different software operating systems (OS). For example, smartphones and tablets can be configured with System, smart screen can be configured system.

[0114] An "online classroom" is installed in a smart phone. "Online classroom" is an application installed in an electronic device that provides teachers and students with various functions required for remote classes. The embodiment of the present application does not limit its name. "Online classroom" may include the following functional components: a blackboard functional component, a whiteboard functional component, an audio and video codec functional component, and a network connection functional component. Among them, the blackboard functional component and the whiteboard functional component belong to FA, and the audio and video codec functional component and the network connection functional component belong to PA. The blackboard functional component provides the function of remotely explaining courses. The whiteboard functional component provides the function of remotely answering questions. The audio and video codec functional component provides video and audio codec functions.

[0115] On the teacher's side, when using the "Online Classroom" on a smartphone, the teacher can migrate or switch the blackboard function components to the smart screen, and explain the course on the smart screen.

[0116] On the student side, when students use the "Online Classroom" on their smartphones, they can migrate or switch the whiteboard function components to their tablets to answer questions on the tablets.

[0117] Migrating or switching a functional component from one device A to another device B can include the following two types: 1. UI migration. When the view UI and business logic of FA are separated, device A can run the business logic code, which can trigger device B to run the view UI code. To the user, it seems that the functional component has been migrated from device A to device B. 2. Overall migration. Overall migration means that after device B downloads and installs the functional component from device A or from the network, it runs the functional component and provides corresponding functions.

[0118] In this remote teaching business scenario, the "online classroom" is the caller, and the whiteboard function component in the tablet computer and the blackboard function component in the smart screen are the callees.

[0119] Figure 2B Another possible distributed video call service scenario is also shown.

[0120] like Figure 2B As shown, the smart phone may also be installed with other distributed applications, such as instant messaging applications. Instant messaging applications may provide video calls, voice calls and other communication functions. Instant messaging applications may include the following functional components: video call functional component, audio and video codec functional component, and network connection functional component.

[0121] When users use instant messaging apps on their smartphones, they can migrate or switch the app's video call function component to a smart screen, thereby using the smart screen's camera and display to make video calls.

[0122] The blackboard function component in the above-mentioned "online classroom" and the video call function component in the instant messaging application can be the same function component. In other words, the function component in the smart screen can be called by the "online classroom" and instant messaging applications installed on the smartphone respectively.

[0123] In this video call service scenario, the instant messaging application is the caller, and the video call function component in the smart screen (i.e., the video call function component) is the callee.

[0124] It should be noted that if Figure 2B The business scenarios shown are only used to assist in describing the technical solutions of the embodiments of the present application. Figure 2BThe distributed system shown may include more terminal devices, more or fewer functional components may be deployed in each device, and each distributed application may include more or fewer functional components.

[0125] pass Figure 2A The distributed system 10 shown, and Figure 2B The distributed scenario shown can integrate the software and hardware capabilities of different devices to achieve a smart full-scenario experience.

[0126] In some embodiments, after each device in the distributed system 10 establishes a communication connection, each device will synchronize the functional component information and APP information of other devices in the distributed system. Specifically, each device can synchronize the names of the functional components and APPs installed by itself to other devices, so that the APPs, functional components, etc. of other devices can be called in the distributed system 10 later.

[0127] In the subsequent embodiments of the present application: the party that initiates the call to the functional component or APP can be called the caller. The caller can be, for example, APP, FA or PA. The initial initiator of the entire call chain can be called the first caller. The first caller can be, for example, APP or FA. For example, the call chain is: APP1 calls PA1, PA1 calls PA2, PA2 calls FA1, then APP1 is the first caller. For another example, the call chain is: FA1 calls PA1, PA1 calls PA2, then FA1 is the first caller.

[0128] In the entire call chain, the party called in the middle and the party called at the end can be called the callee. The callee can be, for example, APP, FA or PA.

[0129] In some embodiments of the present application, the caller may also be referred to as a subject application, and the callee may also be referred to as an object application.

[0130] In the call chain, the caller and the callee can be deployed in the same electronic device or in different electronic devices.

[0131] The device where the caller is located is called the subject device, and the device where the callee is located is called the object device.

[0132] The application referred to in the following embodiments of the present application may include an APP or a functional component.

[0133] In the distributed system 10 provided in the embodiment of the present application:

[0134] After establishing a communication connection between the electronic devices, each device will synchronize its capability information open to other devices. Among them, the capabilities open to other devices by the electronic device include APPs, functional components or resources that can be called, etc. The capability information open to other devices by the electronic device is used to indicate the above capabilities, for example, it may include: the identification of the APP and functional components that the electronic device opens to other devices for calling, the identification of the resources that the electronic device opens to other devices for access, etc.

[0135] The ability of an electronic device to open to other devices can be pre-set by the electronic device or set by the user, and there is no restriction here. For example, an electronic device can open APPs or functional components with lower confidentiality or sensitivity to other devices, such as an electronic device can open camera applications, gallery applications, etc. to other devices, but not open banking applications to other devices.

[0136] The capabilities that an electronic device provides to different electronic devices may be the same or different, and there is no restriction here.

[0137] After the electronic device synchronizes the capability information that it opens to other devices to other devices, other devices in the distributed system 10 can subsequently call the APP or functional components in the electronic device according to the capability information.

[0138] In some embodiments, when an object device in the distributed system 10 receives multiple access requests for calling the same callee, the object device may create multiple instances of the callee, and one instance of the callee is used to respond to an access request initiated by a caller. In addition, the main device where the caller is located may also request the user to grant the permissions required for the access request initiated by itself, and send the permission information granted by the user to the object device. Afterwards, the object device may run the instance of the callee created for the caller in the main device according to the permission information to respond to the access request initiated by the main device. Among them, the permissions required for the access request requested by the main device to be granted by the user may be time-limited, such as temporary validity, validity within a certain period of time, or permanent validity, etc.

[0139] In some embodiments, when the subject device and the object device are the same electronic device, if the electronic device generates multiple access requests for invoking the same callee, the electronic device can create multiple instances of the callee, and one instance of the callee is used to respond to the access request initiated by one caller. In addition, the electronic device can also request the user to grant the permissions required for the access request initiated by itself, and can run the instance of the callee created for the caller in the access request based on the permission information to respond to the access request. The permissions required for the access request that the electronic device requests the user to grant can also be time-limited.

[0140] For the specific implementation of the operations performed by each electronic device in the distributed system 10, reference may be made to the relevant description of the subsequent method embodiments, which will not be repeated here.

[0141] refer to Figure 3A , Figure 3A A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application. The electronic device may be Figure 1 Any electronic device in the distributed system 10 shown. The electronic device can be a main device, can be an object device, or can be both a main device and an object device.

[0142] like Figure 3A As shown, the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0143] It is to be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0144] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0145] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0146] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0147] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor.

[0148] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0149] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to electronic devices. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0150] The modem processor may include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be sent into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After the low-frequency baseband signal is processed by the baseband processor, it is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 170A, a receiver 170B, etc.), or displays an image or video through a display screen 194. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 110 and be set in the same device as the mobile communication module 150 or other functional modules.

[0151] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to electronic devices. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, demodulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0152] In some embodiments, the antenna 1 of the electronic device is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the electronic device can communicate with the network and other devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology. The GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

[0153] The electronic device implements the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0154] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0155] The electronic device can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0156] ISP is used to process the data fed back by camera 193. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to ISP for processing and converts it into an image visible to the naked eye. ISP can also perform algorithm optimization on the noise, brightness, and skin color of the image. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, ISP can be set in camera 193.

[0157] The camera 193 is used to capture still images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then passes the electrical signal to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format. In some embodiments, the electronic device may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0158] Digital signal processors are used to process digital signals. In addition to processing digital image signals, they can also process other digital signals. For example, when an electronic device selects a frequency point, a digital signal processor is used to perform Fourier transform on the frequency point energy.

[0159] Video codecs are used to compress or decompress digital videos. Electronic devices can support one or more video codecs. In this way, electronic devices can play or record videos in multiple coding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0160] NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and continuously self-learn. NPU can realize applications such as intelligent cognition of electronic devices, such as image recognition, face recognition, voice recognition, text understanding, etc.

[0161] The internal memory 121 may include one or more random access memories (RAM) and one or more non-volatile memories (NVM).

[0162] Random access memory may include static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM, for example, the fifth generation DDR SDRAM is generally referred to as DDR5 SDRAM), etc.; non-volatile memory may include disk storage devices and flash memory.

[0163] The random access memory can be directly read and written by the processor 110, and can be used to store executable programs (such as machine instructions) of the operating system or other running programs, and can also be used to store user and application data.

[0164] The non-volatile memory may also store executable programs and user and application data, etc., and may be loaded into the random access memory in advance for direct reading and writing by the processor 110 .

[0165] The external memory interface 120 can be used to connect to an external non-volatile memory to expand the storage capacity of the electronic device. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos are stored in the external non-volatile memory.

[0166] The electronic device can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0167] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signal. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 can be arranged in the processor 110.

[0168] The speaker 170A, also called a "speaker", is used to convert an audio electrical signal into a sound signal. The electronic device can listen to music or listen to a hands-free call through the speaker 170A.

[0169] The receiver 170B, also called a "earpiece", is used to convert audio electrical signals into sound signals. When the electronic device receives a call or voice message, the voice can be received by placing the receiver 170B close to the human ear.

[0170] Microphone 170C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can speak by putting their mouth close to the microphone 170C to input the sound signal into the microphone 170C. The electronic device can be provided with at least one microphone 170C. In other embodiments, the electronic device can be provided with two microphones 170C, which can not only collect sound signals but also realize noise reduction function. In other embodiments, the electronic device can also be provided with three, four or more microphones 170C to realize the collection of sound signals, noise reduction, identification of sound sources, and directional recording function, etc.

[0171] The fingerprint sensor 180H is used to collect fingerprints. Electronic devices can use the collected fingerprint characteristics to achieve fingerprint unlocking, access application locks, fingerprint photography, fingerprint call answering, etc.

[0172] The key 190 includes a power key, a volume key, etc. The key 190 can be a mechanical key or a touch key. The electronic device can receive key input and generate key signal input related to user settings and function control of the electronic device.

[0173] Motor 191 can generate vibration prompts.

[0174] Indicator 192 may be an indicator light, which may be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0175] The pressure sensor 180A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A can be disposed on the display screen 194 .

[0176] The touch sensor 180K is also called a "touch control device". The touch sensor 180K can be set on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, also called a "touch control screen". The touch sensor 180K is used to detect touch operations acting on or near it. The touch sensor can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In other embodiments, the touch sensor 180K can also be set on the surface of the electronic device, which is different from the position of the display screen 194.

[0177] when Figure 3A When the electronic device shown is the main device:

[0178] The mobile communication module 150 or the wireless communication module 160 can be used to establish a communication connection with other electronic devices (such as object devices) in the distributed system 10. The specific method of establishing a communication connection can be referred to Figure 2A Related description in .

[0179] The mobile communication module 150 or the wireless communication module 160 may also be used to receive capability information synchronously opened to the main device by other electronic devices after establishing a communication connection with other electronic devices.

[0180] The mobile communication module 150 or the wireless communication module 160 may also be used to send an access request to the object device for invoking a callee in the object device, where the callee and resources to be accessed by the access request are within the capabilities of the object device open to the subject device.

[0181] Modules such as the display screen 194, the fingerprint sensor 180H, the camera 193, the audio module 170, and the button 190 can be used to provide various authorization methods to request the user to grant the permissions required for the access request initiated by the main device. The processor 110 can obtain the permissions required for the access request granted by the user in response to the user operations received by the above modules.

[0182] The mobile communication module 150 or the wireless communication module 160 may also be used to send the acquired permission required for the access request to the object device. In some embodiments, the mobile communication module 150 or the wireless communication module 160 may also be used to send the timeliness information of the permission required for the access request to the object device.

[0183] The display screen 194 may also be used to display a user interface displayed on the main device provided in subsequent embodiments.

[0184] The internal memory 121 may be used to store open capability information synchronized from other electronic devices in the distributed system 10 .

[0185] The internal memory 121 can also be used to store the call relationship between the caller in the subject device and the callee in the object device. The call relationship includes: a call relationship ID, caller information, and callee information. The specific content of the call relationship can refer to the relevant description of the subsequent embodiments.

[0186] when Figure 3A When the electronic device shown is the object device:

[0187] The mobile communication module 150 or the wireless communication module 160 can be used to establish a communication connection with other electronic devices (such as a main device) in the distributed system 10. The specific method of establishing a communication connection can be referred to in Figure 2A Related description.

[0188] The mobile communication module 150 or the wireless communication module 160 may also be used to synchronously open capability information of other electronic devices to other electronic devices after establishing a communication connection with other electronic devices.

[0189] The mobile communication module 150 or the wireless communication module 160 can also be used to receive access requests sent by multiple main devices for calling the same callee, and the callee and resources to be accessed by the access request are within the capabilities of the object device open to the main device.

[0190] The mobile communication module 150 or the wireless communication module 160 can also be used to receive permission information required for the access request granted by the user sent by the main device. In some embodiments, the mobile communication module 150 or the wireless communication module 160 can also be used to receive timeliness information of the permission required for the access request sent by the main device.

[0191] The processor 110 may be used to respond to access requests received from multiple subject devices and create multiple instances of the callee, where one instance of the callee is used to respond to an access request initiated by one caller.

[0192] The processor 110 may also be configured to run an instance of a callee created for a caller in the subject device according to the permission information sent by the subject device, so as to respond to an access request initiated by the subject device.

[0193] The display screen 194 may also be used to display a user interface displayed on the object device provided in subsequent embodiments.

[0194] The internal memory 121 may be used to store permission information, time validity information, etc. required for access requests sent by various subject devices.

[0195] The internal memory 121 can also be used to store the call relationship between the callee in the object device and the caller in the subject device. The call relationship includes: the call relationship ID, the instance information of the callee, and the information of each caller that calls the instance. The specific content of the call relationship can refer to the relevant description of the subsequent embodiments.

[0196] when Figure 3A When the electronic device shown is both a main device and an object device, the operations performed by each module in the main device and the object device are all performed by the electronic device, and the communication step between the main device and the object device can be omitted. The operations performed by each module in the electronic device can be referred to the relevant description above and will not be repeated here.

[0197] refer to Figure 3B , Figure 3B A schematic diagram of the software structure of an electronic device provided in an embodiment of the present application. The electronic device may be Figure 1 Any electronic device in the distributed system 10 shown. The electronic device can be a main device, can be an object device, or can be both a main device and an object device.

[0198] The software system of the electronic device may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. For example, the software system of the electronic device includes but is not limited to Linux or other operating systems.

[0199] The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system library, and the kernel layer.

[0200] The application layer can include a series of application packages.

[0201] like Figure 3B As shown, the application package may include APPs, such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, etc. The application layer may also include functional components, such as FA, PA, etc.

[0202] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0203] like Figure 3B As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0204] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0205] Content providers are used to store and retrieve data and make it accessible to applications. The data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0206] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0207] The phone manager is used to provide communication functions for electronic devices, such as the management of call status (including answering, hanging up, etc.).

[0208] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0209] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

[0210] Android Runtime includes core libraries and virtual machines. Android runtime is responsible for scheduling and management of the Android system.

[0211] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

[0212] The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0213] The system library may include multiple functional modules, such as surface manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

[0214] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

[0215] The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0216] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0217] A 2D graphics engine is a drawing engine for 2D drawings.

[0218] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and sensor driver.

[0219] based on Figure 2A The distributed system 10 shown, Figure 3AThe hardware structure of the electronic device shown, Figure 3B The software structure of the electronic device shown in the figure, and the access control method based on permission transfer provided by the embodiment of the present application are introduced in detail below.

[0220] refer to Figure 4 , Figure 4 A flowchart of an access control method based on permission transfer provided in an embodiment of the present application. Figure 4 The method shown is explained by taking the subject device calling the resources in the object device as an example.

[0221] like Figure 4 As shown, the method may include the following steps:

[0222] S101, a connection is established between an object device and a subject device, and the number of the subject devices is one or more.

[0223] The number of the object device is one, and the object device can be any electronic device in the distributed system 10 .

[0224] The number of the main device may be one or more. The main device may be any electronic device in the distributed system 10.

[0225] The embodiments of the present application do not limit the way in which the object device and the subject device establish a communication connection. For example, the communication connection can be established by logging into the same account, binding devices, scanning QR codes, etc. The embodiments of the present application do not limit the type of communication connection established between the subject device and the object device. For example, it can include wired connection, wireless connection such as Bluetooth connection, Wi-Fi P2P connection, NFC connection, IR connection, and remote connection, etc. For details, please refer to Figure 2A Related description in .

[0226] In some embodiments, after the object device and the main device establish a connection, the object device can send the main device the function component information and APP information installed by itself, such as identification, etc. The function component or APP that can be called is declared or defined by the developer during the development stage. The function component or APP that can be called here only means that the function component or APP can be called by the caller, not that it is open or authorized to be called by a certain device.

[0227] In some embodiments, after the object device and the main device establish a connection, the object device may send capability information open to the main device to the main device, and the capability information indicates the APP, functional components, resources, etc. that the object device opens to the main device for calling. Here, the capability information open to the main device means that the corresponding APP, functional components, and resources can be called by the main device. The capabilities open to the main device by the object device can be pre-set by the object device or set by the user. The capabilities open to different main devices by the object device can be the same or different, and there is no restriction here.

[0228] S102: The subject device generates an access request and sends the access request to the object device. The access request is used by a caller in the subject device to call a callee in the object device to access a first resource.

[0229] In the embodiment of the present application, a caller is installed in the main device, and a callee is installed in the object device. Both the caller and the callee can be APP or functional component. The definition of APP and functional component can refer to the relevant description above.

[0230] The access request generated by the subject device may include: the identifier of the caller, the identifier of the callee, and the identifier of the first resource. In some embodiments, the access request may also include: the identifier of the subject device and the identifier of the object device.

[0231] The identifier of the subject device or the object device can be a device type, a device model, a device name, etc., which is not limited in the present embodiment. The device type here can be viewed from the device function, for example, including mobile phones, tablet computers, smart headphones, IOT devices or smart home devices, etc.

[0232] The caller's ID and the callee's ID may be an application ID (APP ID).

[0233] In the embodiment of the present application, the first resource may be a software resource or a hardware resource. Hardware resources may include, for example, a camera, a fingerprint sensor, an audio device, a display screen, a motor, a flash, etc. possessed by the device. Software resources may include, for example, memory resources, computing capabilities (such as beauty algorithm capabilities, audio and video encoding and decoding capabilities), network capabilities, positioning functions, etc. possessed by the device. The first resource may include one or more resources, which are not limited here.

[0234] In some cases, the identifier of the callee and the identifier of the first resource may be the same. For example, when the first resource is a camera, the identifier of the callee may also be the identifier of the camera, which is used to indicate that the callee is a camera application.

[0235] In the embodiment of the present application, each access request corresponds to the initiator device (i.e., the main device) of the access request, the caller, the callee, and the first resource requested to be accessed. The callee and the first resource corresponding to different access requests are the same, and the main device and caller corresponding to different access requests may be different.

[0236] In some embodiments, the subject device may generate an access request in response to a received user operation during the execution of the caller.

[0237] The following is an example in which the main device 200 and the main device 300 each generate an access request for the object device 100. The main device 200 may be a smart phone. The main device 300 may be a tablet computer. The object device 100 may be a smart screen.

[0238] refer to Figure 5A , Figure 5A A user interface 51 is shown when a main device 200 (such as a smart phone) is running an instant messaging application. The user interface 51 is a video call interface.

[0239] Displayed in the user interface 51 are: an image of the user at the main device 200 end, images of other users who are making video calls with the user at the main device 200 end, and one or more device options 501. The one or more device options 501 may correspond to devices in the distributed system 10 that can provide camera resources to meet the video call requirements of the main device 200, such as a smart screen, a tablet computer, and the like.

[0240] like Figure 5A As shown, the main device 200 can detect user operations acting on the device option 501, and generate an access request in response to the user operation. The access request is used for the instant messaging application in the main device 200 to call the video call function component (FA) and camera resources in the smart screen (i.e., the object device 100) corresponding to the device option 501.

[0241] refer to Figure 5C , Figure 5C The figure shows a user interface 53 displayed by the main device 300 (eg, a tablet computer) when running an "online classroom" application, and the user interface 53 is used for remote teaching. The users of the main device 300 and the main device 200 may be different.

[0242] The user interface 52 may be a user interface when a student uses an "online classroom". The user interface 52 displays: a page 503 provided by a blackboard function component and a page 504 provided by a whiteboard function component. The definitions of the blackboard function component and the whiteboard function component can be found in Figure 2B Related description in .

[0243] Page 503 displays: an image 503a of the teacher, and images 503b of one or more students participating in the remote teaching. The images 503b of the one or more students may include images of the user of the main device 300, such as Figure 5C The second image 503b in the top row of images on the display screen shown in FIG. Both images 503a and 503b are real-time images, thereby realizing the function of remote teaching.

[0244] Page 504 displays: exercises, input boxes, input controls, etc.

[0245] In addition, one or more device options 505 may be displayed in the user interface 52. The one or more device options 505 may correspond to devices in the distributed system 10 that can provide camera resources to meet the remote teaching function of the main device 300, such as a smart screen, etc.

[0246] like Figure 5C As shown, the main device 300 can detect user operations acting on the device option 505, and generate an access request in response to the user operation. The access request is used for the "online classroom" application in the main device 300 to call the blackboard function components and camera resources in the smart screen (i.e., the object device 100) corresponding to the device option 505.

[0247] Among them, the blackboard function component and the video call function component in the object device 100 are the same function component. That is to say, both the main device 200 and the main device 300 generate access requests for the object device 100. The access request generated by the main device 200 is used for the instant messaging application to call the video call function component (FA) in the object device 100 and access the camera, and the access request generated by the main device 300 is used for the "online classroom" application to call the video call function component (FA) in the object device 100 and access the camera.

[0248] In other embodiments, the subject device may also autonomously generate access requests for the object device in some cases during the process of running the caller. For example, the subject device may generate access requests for the video call function components and camera resources in the smart screen (i.e., the object device 100) by default every time a video call is made.

[0249] In some embodiments, after generating an access request, the main device may first query whether the object device has opened the permission for the main device to access the callee and the first resource in the access request. If so, the main device may further query whether it has the permission required for the access request. Only when the results of both queries are yes, the main device sends the access request to the object device. If the result of the second query is no, the main device may apply to the user for the permission required for the access request. The specific method for the main device to apply for permission and the definition of the permission required for the access request can be referred to the relevant description below, which will not be repeated here. Of course, the main device may also only perform the first query, and send the access request to the object device if the result of the first query is yes.

[0250] Executing the first query operation in the above embodiment can ensure that the main device initiates an access request within the capabilities opened by the object device to the main device, and will not initiate an access request outside the scope of the open capabilities, which can increase the probability of the access request being responded to and reduce ineffective communication between devices.

[0251] Executing the second query operation in the above embodiment can ensure that the main device initiates the access request after obtaining the authority required for the access request, thereby ensuring the security of the entire calling process.

[0252] In other embodiments, the subject device may also directly send the access request to the object device after generating the access request.

[0253] In some embodiments, after receiving the access request, the object device may directly execute subsequent S103 - S105 .

[0254] In other embodiments, after receiving the access request, the object device may execute subsequent S103-S105 on the premise of confirming that the callee and / or the first resource are sensitive resources. In this way, it can be ensured that when sensitive resources in the object device are accessed, the user's authorization can be obtained, thereby ensuring the security of user data. Sensitive resources may refer to resources that will cause a greater risk to user privacy after being leaked, such as resources with a privacy level higher than a threshold. Sensitive resources may include hardware resources, software resources, and stored data in electronic devices. Hardware resources may include, for example, cameras, audio equipment, display screens, and the like. Software resources may include, for example, memory resources, computing capabilities (such as beauty algorithm capabilities, audio and video encoding and decoding capabilities), network capabilities, positioning functions, highly confidential APPs (such as banking APPs), and the like. The stored data may include, for example, stored user information, photos, videos, passwords for users to log in to applications, and the like.

[0255] In optional step S103 , the object device creates and runs multiple callee instances in response to the received access request.

[0256] Specifically, after receiving multiple access requests, the object device may enable different instances according to one or more of the following: the caller, the subject device, the developer of the caller, the user to whom the caller belongs or the account of the subject device, etc. When one or more of the above are different, the object device may enable different callee instances to provide services for the corresponding callers.

[0257] In some embodiments, if there is an instance of the callee that provides services for the caller in the subject device in the object device, that is, the object device has previously created the instance, then the object device does not need to execute S103 to recreate the instance. If there is no instance of the callee that provides services for the caller in the subject device in the object device, then the object device executes S103 to create the instance.

[0258] For example, an application identified as "ID2" in the subject device 200 and an application identified as "ID3" in the subject device 300 simultaneously call an application identified as "ID1" in the object device 100. The object device 100 creates two instances to provide services to the two callers respectively.

[0259] For another example, an application identified as "ID3" in the main device 300 and an application identified as "ID4" in the main device 400 simultaneously call an application identified as "ID1" in the object device 100. Since the two callers have the same developer, the object device 100 creates an instance and provides services to the two callers at the same time.

[0260] Reference Figure 5A and Figure 5C In the example, the object device 100 will create two instances of the video call function component (FA) to provide services to the main device 200 and the main device 300 respectively.

[0261] In some embodiments, the object device may be installed in advance in the callee. In other embodiments, the object device may download and install the callee from the network or directly download and install the callee from the subject device after receiving the access request sent by the object device.

[0262] When the object device creates an instance of the callee, a UID and a PID may be assigned to the instance. In some embodiments, the object device may assign different UIDs to different instances of the callee. In some embodiments, the object device may assign different PIDs to different instances of the callee. Therefore, the object device may distinguish different instances of the same callee by UID or PID.

[0263] In some embodiments, after the object device creates the instance of the callee, it can save the call relationship formed by the caller and the instance of the callee. The specific content of the call relationship can refer to the relevant description above. The object device can also synchronize part of the content of the call relationship, such as the call relationship ID, the UID and PID of the callee instance created for the caller in the subject device, to the subject device to facilitate the subject device to store the call relationship.

[0264] In optional step S104, the object device queries whether it has the authority required for the access request sent by the subject device.

[0265] The authority required for the access request includes: the authority to call the callee in the object device, and / or the authority to access the first resource in the object device.

[0266] In some embodiments, the permissions required for the access request specifically include: permissions for the subject device to call the callee in the object device and / or access the first resource.

[0267] In some embodiments, the permissions required for the access request specifically include: permissions for the caller to call the callee in the object device and / or access the first resource.

[0268] In some embodiments, the permissions required for the access request specifically include: permissions for a caller in a subject device to call a callee in an object device and / or access a first resource.

[0269] If S104 is not executed, the object device can execute S105 each time after receiving an access request sent by the main device. If S105 is executed, the object device will execute S105 to apply for permission from the user through the main device only when it does not have the permission required by the access request sent by the main device, which can reduce the interaction between the main and object devices and improve the efficiency of cross-device resource calls in the distributed system.

[0270] S105, the object device sends an authorization request to the subject device, where the authorization request is used to request the subject device to apply to the user for the authority required for the access request sent by the subject device.

[0271] The permissions required for the access request may refer to the relevant description in S104.

[0272] In some embodiments, the object device can find the subject device corresponding to the access request according to the stored calling relationship, and send an authorization request to the subject device.

[0273] S106: The main device requests the user to grant the authority required for the access request sent by the main device.

[0274] When an electronic device supports one or more authorization modes for user authorization, the electronic device meets the authorization condition. When a caller supports one or more authorization modes for user authorization, the caller meets the authorization condition.

[0275] Authorization methods may include but are not limited to: pop-up authorization, fingerprint verification authorization, face verification authorization, voice command authorization, button authorization, etc., and there is no restriction here.

[0276] Whether an electronic device meets the authorization conditions and the types of authorization methods supported depends on the hardware and / or software configuration of the electronic device. For example, to support pop-up authorization, the electronic device needs to be equipped with a display screen. To support fingerprint verification authorization, the electronic device needs to be equipped with a fingerprint sensor. To support face verification authorization, the electronic device needs to be equipped with a camera and a face recognition algorithm. To support voice command authorization, the electronic device needs to be equipped with a microphone or other sound pickup device. To support button authorization, the electronic device needs to be equipped with physical buttons.

[0277] Whether the caller meets the authorization conditions depends on the function of the caller itself. For example, when the caller can provide a user interface, the caller can support pop-up authorization. For another example, when the caller can call a fingerprint sensor, the caller can support fingerprint verification authorization.

[0278] In S106, the main device can use the authorization method supported by both the main device and the caller to request the user to grant the permission required for the access request sent by itself during the operation of the caller. The following introduces different authorization methods respectively.

[0279] When the main device supports pop-up authorization, a prompt message can be output on the display screen, which is used to prompt the permissions required for the access request. Afterwards, the main device can detect the user operation acting on the display screen, and in response to the user operation, obtain the permissions required for the access request.

[0280] refer to Figure 5B , Figure 5B The user interface 52 displayed when the main device 200 requests user authorization by using a pop-up authorization method is exemplified.

[0281] The user interface 52 displays a window 502. The window 502 includes: prompt information 502a, control 502b, control 502c, and control 502d. The prompt information 502a is used to prompt the user to grant the permission required for the access request initiated by the main device 200. The prompt information 502a can be, for example, the text "The "Instant Messaging Application" needs to access your camera. After authorization, the following applications will use this permission: Video Call Function Component (FA)", where "Instant Messaging Application" indicates the caller, "Video Call Function Component (FA)" indicates the caller, and "Camera" indicates that the first resource is a camera resource. In combination with the device providing the current user interface 52, the user in Figure 5A In the device option 501 selected in the embodiment, the user can also know that the subject device is a smart phone and the object device is a smart screen. In some other embodiments, the prompt information 502a may include information of the subject device and the object device.

[0282] That is to say, prompt information 502a is used to prompt the user to grant permission to the instant messaging application in the smartphone to call the video call function component (FA) in the smart screen and access camera resources.

[0283] The prompt information 502a is not limited to the form shown in the prompt information 502a. The specific content of the prompt information 502a depends on the authority required for the access request and is not limited here.

[0284] The control 502b may be used to monitor user operations, and the main device 200 responds to the user operations and learns that the permission required for the access request sent by the main device 200 has not been obtained.

[0285] Control 502c can be used to monitor user operations, and the main device 200 responds to the user operation and successfully obtains the permission required for the access request sent by the main device 200, and the validity period of the permission is one time. That is, the permission required for the access request obtained by the main device 200 is valid once, and after the access request is responded to, the main device 200 no longer has the permission.

[0286] The control 502d can be used to monitor user operations, and the main device 200 responds to the user operation and successfully obtains the permission required for the access request sent by the main device 200, and the validity period of the permission is permanent. That is, the permission required for the access request obtained by the main device 200 is permanently valid.

[0287] like Figure 5B As shown, the main device 200 receives the user operation acting on the control 502b, and fails to obtain the authority required for the access request sent by the main device 200.

[0288] refer to Figure 5D , Figure 5DThe user interface 54 is shown as an example when the main device 300 uses the pop-up authorization method to request user authorization. The window 506 included in the user interface 54 can refer to Figure 5B The window 502 in the user interface 52 is not described in detail here.

[0289] like Figure 5D As shown, the main device 300 can receive a user operation acting on the control 506a, and the main device 300 responds to the user operation and successfully obtains the permission required for the access request sent by the main device 300, and the validity period of the permission is permanent.

[0290] When the main device supports fingerprint verification authorization, the fingerprint sensor can be used to collect the user's fingerprint, and the collected fingerprint is compared with the preset fingerprint. If the two fingerprints are consistent, the main device obtains the permission required for the access request. In some embodiments, the main device can preset multiple fingerprints, and when different preset fingerprints are collected, the permission required for the access request with different validity periods is obtained.

[0291] When the main device supports face verification authorization, it can collect the user's face image through the camera and compare the collected face image with the preset face image. If the two are consistent, the main device obtains the permission required for the access request.

[0292] When the main device supports voice command authorization, it can collect the voice command input by the user through a microphone, a receiver or other sound pickup device, and compare the collected voice command with the preset voice command. If the two are consistent, the main device obtains the permission required for the access request. In some embodiments, the main device can preset multiple voice commands, and when different preset voice commands are collected, it obtains the permission required for the access request with different time limits.

[0293] When the main device supports key authorization, the user's pressing operation can be collected through the physical key. If a preset pressing operation (such as a single pressing operation, a long pressing operation, a continuous double pressing operation, etc.) is collected on the physical key, the main device obtains the permission required for the access request. In some embodiments, the main device can preset multiple pressing operations, and when different preset pressing operations are collected, the permission required for the access request with different time limits is obtained.

[0294] In the embodiment of the present application, when the subject device requests the user to grant the permission required for the access request sent by the subject device, if the permission required for the access request contains information of the subject device and / or the caller, the user can obtain more detailed information about the permission required for the access request currently received by the object device, thereby deciding whether to grant the permission. This ensures that the user fully understands the permission required for the access request before performing the authorization operation, which can avoid user misoperation or misauthorization and ensure the data security in the object device.

[0295] It can be seen that in S106, the main device can obtain the permission required for the access request sent by the main device in response to the received user operation, and the permission granted by the user has a time limit. The time limit of the permission can include multiple types, not limited to the above Figure 5B or Figure 5D The one-time validity and permanent validity shown in the figure may also have more situations, such as validity within a week, validity within a month, validity within a certain area, etc., which are not limited here.

[0296] S107, the subject device sends the acquired permission information required for the access request to the object device.

[0297] The permission information indicates one or more of the following: whether the subject device obtains the permission required for the access request, the permission required for the access request obtained by the subject device, and the validity period of the permission obtained by the subject device.

[0298] For example, reference Figure 5B , the main device 200 failed to obtain the authority required for the access request sent by the main device 200.

[0299] For example, reference Figure 5D , the main device 300 obtains the permission required for the access request sent by the main device 300, and the validity period of the permission is permanent.

[0300] In some embodiments, the subject device may find the object device corresponding to the access request according to the stored calling relationship, and send the acquired permission information required for the access request to the object device.

[0301] In some embodiments, after executing S107 , the subject device may also record or store the permission information of the callee in the object device to access the resource. Referring to Table 1 , Table 1 exemplarily shows a type of permission information recorded by the subject device 300 .

[0302]

[0303]

[0304] Table 1

[0305] As shown in Table 1, the "online classroom" application in the subject device grants the video call application (FA) permission to use the camera and microphone, and the food delivery APP grants the location FA permission to use the location service. Here, the granting of permissions by the caller in the subject device is triggered by user operations.

[0306] S108, the object device receives the permission information required for the access request obtained by the subject device, and grants the permission indicated by the permission information to the instance of the callee created for the caller in the subject device.

[0307] Specifically, after the object device obtains the permission information sent by the subject device, it grants the permission indicated by the permission information to the instance of the callee created by the caller in the subject device. If the permission information also indicates the validity period of the permission, the validity period can be simultaneously granted to the instance of the callee created by the caller in the subject device.

[0308] For example, reference Figure 5A-Figure 5B After the main device 200 sends the acquired permission information to the object device 100, the object device 100 determines that the instance of the video call function component (FA) created for the instant messaging application does not have the permission required for the access request sent by the main device 200. The specific content of the permission can be referred to the relevant description above.

[0309] For example, reference Figure 5C-5D After the main device 300 sends the acquired permission information to the object device 100, the object device 100 determines that the instance of the video call function component (FA) created for the "online classroom" application has the permission required for the access request sent by the main device 300. The specific content of the permission can refer to the relevant description above, and the permission is valid for one time.

[0310] In some embodiments, after the object device executes S108 , it may also record or store the permission information of the callee in the object device to access the resource. Referring to Table 2, Table 2 exemplarily shows a type of permission information recorded by the object device 100 .

[0311]

[0312] Table 2

[0313] As shown in Table 2, the video call application (FA) in the object device obtains the permission to use the camera and microphone granted by the "online classroom application", and the positioning FA obtains the permission to use the positioning service granted by the takeaway APP. Here, the permissions granted by the caller in the subject device are all triggered by user operations.

[0314] In some other embodiments of the present application, before the main device sends an access request to the object device in S102, it can actively execute steps S106-S107 without being triggered by the object device through S105.

[0315] In some embodiments, if the subject device executes S106 before sending an access request to the object device in S102, that is, requests the user to grant the permission required for the access request, the subject device can carry the obtained permission information in the access request and send it to the object device together.

[0316] In some other embodiments of the present application, the object device may perform the operation of creating an instance in S103 after S107, that is, after receiving the permission information required for the access request obtained by the subject device. Further, the object device may perform the operation of creating an instance in S103 after receiving the permission information required for the access request obtained by the subject device and confirming that the subject device has obtained the permission required for the access request. This can increase the probability of the access request being responded to and reduce ineffective communication between devices.

[0317] S109: The object device decides whether to respond to the access request sent by the subject device according to the permission information sent by the subject device.

[0318] If the permission information sent by the subject device indicates that the subject device has not obtained the permission required for the access request sent by the subject device, the object device will refuse to respond to the access request. Specifically, the object device may refuse to create an instance of the callee for the caller in the subject device, or refuse to run an instance of the callee created for the caller in the subject device.

[0319] For example, reference Figure 5A-Figure 5B After the main device 200 sends the acquired permission information to the object device 100, the object device 100 can reject the instance of the video call function component (FA) created for the instant messaging application, or refuse to run the instance of the video call function component (FA) created for the instant messaging application.

[0320] If the permission information sent by the subject device indicates the permission required by the subject device for the access request sent by the subject device, the object device can respond to the access request according to the permission, run the instance of the callee created for the caller, and access the first resource. In some other embodiments, the object device can also query whether the permission to access the callee and / or the first resource is open to the subject device, and only respond to the access request if it is.

[0321] In some embodiments, the object device responds to the access request, which may specifically include one or more of the following:

[0322] 1. The object device runs an instance of the callee created by the caller, accesses the first resource to perform a series of operations, such as displaying a video call interface through a display screen, capturing images through a camera, performing calculation operations, obtaining location information, etc.

[0323] 2. The object device sends the access result of the first resource to the main device, such as sending the image captured by the camera to the main device, so that the main device can send it to the other end device of the video call with it, or sending the calculation result and the obtained location information to the main device, etc.

[0324] 3. The object device receives data sent by the main device and uses the data to access the first resource. For example, the object device can receive an image captured by the other end device of the video call sent by the main device and display the image in the video call interface of the display screen.

[0325] For example, reference Figure 5C-5D After the main device 300 sends the acquired permission information to the object device 100, the object device 100 can create an instance of the video call function component (FA) for the "online classroom" application, and respond to the access request sent by the main device 300, run the instance of the video call function component (FA), and access the camera of the object device 100.

[0326] refer to Fig. 5F , Fig. 5F The user interface 56 is displayed when the object device 100 responds to the access request sent by the main device 300. The user interface 56 includes a page provided by the blackboard function component, and the user interface 56 displays: an image 503a on the teacher's side, and an image 503b on one or more student sides participating in remote teaching. The one or more student-side images 503b may include an image of the user on the main device 300 side. Among them, the image of the user on the main device 300 side is acquired by the camera of the object device 100, and the images 503b on the other student sides and the image 503a on the teacher side can be acquired by the main device 300 and then sent to the object device. After the object device 100 acquires the image through the camera, it can also send the image to the main device 300, so that the main device 300 sends the image to other student-side and teacher-side devices. In this way, the function of migrating the page provided by the whiteboard function component to the object device 100 can be realized. Since the sizes of the display screens of the main device 300 and the object device 100 may be different, compared with the page provided by the blackboard function component displayed on the main device 300, Fig. 5F The layout of the various elements of the page shown may vary.

[0327] contrast Fig. 5F and Figure 5C , Figure 5C The image of the user on the main device 300 is collected by the main device 300. Fig. 5F The image of the user on the main device 300 side is collected by the object device 100. Since the main device 300 and the object device 100 are in different positions, the images of the user on the main device 300 side collected by the two are different. Figure 5C and Fig. 5F The second image 503b in the top row of images on the display screen shown in FIG. 5 is different.

[0328] In some embodiments, the user interface 56 may also display a prompt message 509 and a control 510. The prompt message 509 is used to prompt the user that the current subject device 300 (e.g., a tablet computer) is accessing the camera resources of the object device 100 (e.g., a smart screen). The control 510 can monitor user operations, and the object device 100 can stop responding to the access request sent by the subject device 300 in response to the user operation.

[0329] Not limited to Fig. 5F In the scenario shown, in a specific implementation, the object device may respond to the access request in other types of forms, depending on the specific content of the access request, and the embodiments of the present application do not limit this.

[0330] refer to Figure 5E , Figure 5E The user interface 55 displayed by the subject device 300 after the object device 100 responds to the access request sent by the subject device 300. The user interface 55 includes a page provided by the whiteboard function component. The content of the page can be referred to Figure 5C The relevant description in the user interface 53 is shown.

[0331] In some embodiments, the user interface 55 may also display a prompt message 507 and a control 508. The prompt message 507 is used to prompt the user that the current blackboard function component (FA) has been migrated to the smart screen. The control 508 can monitor the user operation, and the main device 300 can respond to the user operation, stop migrating the blackboard function component (FA) to the smart screen, and redisplay the user interface before the migration, for example Figure 5C User interface 53 is shown.

[0332] If the permission information sent by the main device also indicates the time limit of the permission required for the access request obtained by the main device, the object device will run the instance created for the caller in the main device according to the time limit. Specifically, if the time limit is valid once, the object device refuses to respond to the access request that has the same effect as the access request that is subsequently sent by the main device. If the time limit is valid within the first time, and the object device receives the permission information sent by the main device for a period of time not exceeding the first time; or, if the time limit is valid within the first area, and the object device is located in the first area; or, if the time limit is permanently valid, the object device will respond to the access request that has the same effect as the access request that is subsequently sent by the main device, and run the first instance according to the first permission information to access the first resource. Here, the access request that has the same effect as the access request that is subsequently sent by the main device can be referred to as a third access request.

[0333] For example, refer to Figure 5D , the time limit of the permission required for the access request obtained by the subject device 300 is one-time valid. After the object device 100 runs the instance of the video call function component (FA) created for the "online classroom" application to access the camera, if the user instructs to stop access, for example, the user Fig. 5F , the object device 100 stops running the instance, and the instance no longer has the permissions obtained by the subject device 300. Afterwards, if the subject device 300 sends an access request for the same purpose to the object device 100 again, the object device 100 and the subject device 300 need to re-execute the above steps S104-S109 and re-apply to the user for the permissions required for the access request.

[0334] For another example, if the time limit of the permission required for the access request obtained by the subject device 300 is permanent, and the permission is specifically the permission for the subject device 300 to call the video call function component (FA) in the object device 100 to access the camera, after the object device 100 runs the instance of the video call function component (FA) created for the "online classroom" application to access the camera, if the user instructs to stop access, for example, the user Fig. 5F , the object device 100 stops running the instance, but the instance continues to have the permissions obtained by the subject device 300. Afterwards, if the subject device 300 sends an access request for the same purpose to the object device 100 again, for example, an access request initiated by an instant messaging application in the subject device 300, the object device 100 and the subject device 300 do not need to re-execute the above steps S104-S108, and can directly respond to the access request according to the previous permission information.

[0335] In the embodiment of the present application, the main device or the object device can provide a user interface for the user to view the permission information of each application installed by the user, as well as the permission information granted by each application to the callee.

[0336] The permission information of each application may include the permission owned by the application, the status of the permission, the grantor, the granting device, the validity period, etc.

[0337] refer to Fig. 6A , Fig. 6A The permission information owned by each application in the object device 100 is exemplarily shown.

[0338] like Fig. 6A As shown, the video call application (FA) in the object device 100 has the camera and microphone permissions granted by the "online classroom", including its own network permissions, but does not have the permissions to access SMS services, phone services, photo albums, positioning services, etc. In addition, the food delivery APP in the object device 100 has the permission to access the positioning service granted by the positioning FA, including its own network permissions, but does not have the permission to access the photo album.

[0339] exist Fig. 6A In the user interface shown, the user can click on the permission status icon to view the permissions possessed by each application in the object device 100.

[0340] The permission information granted by each application to the callee may include the permission granted by the application, the status of the permission, the granting callee, the granting device, the validity period, etc.

[0341] refer to Figure 6B , Figure 6B The authority information granted by each application in the main device 300 to the callee is exemplarily shown.

[0342] like Figure 6B As shown, the "online classroom" application in the main device 300 grants the video call application (FA) camera permission and microphone permission, and the takeaway APP grants the location FA permission to access the location service. The user can click the permission status icon to change the permissions granted by each application in the main device 300.

[0343] In an embodiment of the present application, the object device can manage the life cycle of the instance of the callee created for the caller in the subject device. In some embodiments, the object device can stop running or destroy the instance after running the instance and successfully responding to the access request, or stop running or destroy the instance after a preset time, or stop running or destroy the instance when the running instance has not accessed the resources in the object device for a certain period of time. Stopping the instance means that the instance still exists in the object device, but the instance is not in a running state. Destroying the instance means that the object device deletes all data related to the instance, and the instance no longer exists in the object device.

[0344] exist Figure 4 In the access control method shown:

[0345] The object device 100 may be referred to as a third device, one subject device (eg, the subject device 300 ) may be referred to as a first device, and another subject device (eg, the subject device 400 ) may be referred to as a second device.

[0346] The caller in the first device may be referred to as a first caller, and the caller in the second device may be referred to as a second caller.

[0347] The access request sent by the first device to the third device may be referred to as a first access request. The access request sent by the second device to the third device may be referred to as a second access request.

[0348] The permission information sent by the first device to the third device may be referred to as the first permission information. The permission information sent by the second device to the third device may be referred to as the second permission information. The permission to call the callee and / or the permission to access the first resource may be referred to as the first permission or the second permission.

[0349] The instance of the callee run by the third device in response to the first access request may be referred to as a first instance. The instance of the callee run by the third device in response to the second access request may be referred to as a second instance.

[0350] In S106, the operation for granting the first permission received by the main device 300 may be referred to as a first operation. Examples of the first operation may include: Figure 5D The user operation acting on the control 506a displayed on the display screen, the preset face image collected by the camera, the preset fingerprint collected by the fingerprint sensor, the preset voice command collected by the sound pickup device, or the user operation acting on the key. The specific implementation of the first operation can be referred to Figure 4 Related description of S106.

[0351] In S106, the user interface provided by the main device 300 for receiving the first operation may be referred to as a first user interface, for example Figure 5D The user interface 54 is shown. The control 506a in the user interface 54 can be referred to as a first control.

[0352] Through the above Figure 4 In the access control method based on permission transfer shown in the figure, the instance created by the object device for the caller in the subject device only has the permission transferred by the subject device. The object device can only use the permission transferred by the subject device to run the instance created for the caller in the subject device, thereby providing services to the caller in the subject device, but cannot use the permission to run the instance created for the caller in other subject devices, and cannot use the permission to provide services to the callers in other subject devices. In this way, in the form of multiple instances, it can be ensured that the permission of a caller will only be given to the instance of the callee corresponding to the caller, which can avoid the problem of mixed permission and permission expansion, thereby ensuring the data security in the object device and preventing data abuse and leakage.

[0353] Moreover, through the above method, regardless of whether the object device meets the authorization conditions, as long as the subject device meets the authorization conditions, the object device can obtain the permissions required for the access request, thereby ensuring that the access request initiated by the caller can be successfully responded to, realizing resource calls between devices, and meeting the actual needs of users.

[0354] In addition, the above method obtains the permissions required for the access request through the main device, and does not rely on the callee to obtain the permissions, nor does it rely on the callee to perform security authentication on the caller. Therefore, this method does not have any restrictions on the callee. Regardless of whether the callee is a third-party application or a system application, the implementation of the above method can obtain the permissions required for the access request, and can ensure that only when the caller has the permissions required for the access request, the access request initiated by the caller can be successfully responded to, thereby realizing resource calls between devices and meeting the actual needs of users. In other words, this method can provide system-level access control.

[0355] Not limited to the above exemplary distributed systems, Figure 4 The method shown can also be applied to a single electronic device. For example, the electronic device is installed with multiple callers and callees, and the electronic device is both a subject device and an object device. The electronic device can generate multiple access requests for calling the same callee, and the access request is used by the caller to call the callee to access the first resource in the electronic device. The timing and method of generating the access request can be referred to Figure 4 After the electronic device generates the access request, it can execute Figure 4The difference between S103-S109 in the method shown is that Figure 4 The communication process between the object device and the subject device can be omitted. Figure 4 The relevant description will not be repeated here.

[0356] When a single electronic device implements the above access control method, the permission required for the access request is obtained through the electronic device, without relying on the callee to obtain the permission, nor relying on the callee to perform security authentication on the caller, so the method has no restrictions on the callee. Regardless of whether the callee is a third-party application or a system application, the implementation of the above method can obtain the permission required for the access request, and can ensure that only when the caller has the permission required for the access request, the access request initiated by the caller can be successfully responded to, thereby realizing the resource call within the single device and meeting the actual needs of the user.

[0357] In addition, in a stand-alone device, the electronic device provides services to multiple callers in the form of multiple instances, which can ensure that the permissions of a caller are only given to the instance of the callee corresponding to the caller, avoiding the problems of mixed permissions and expanded permissions, thereby ensuring the security of data in the electronic device and preventing data abuse and leakage.

[0358] When the access control method based on permission transfer provided by the embodiment of the present application is executed in a stand-alone device, one caller in the electronic device may be referred to as the first caller, and the other caller may be referred to as the second caller. The access request for calling the callee and accessing the first resource generated when the electronic device runs the first caller may be referred to as the first access request. The access request for calling the callee and accessing the first resource generated when the electronic device runs the second caller may be referred to as the second access request.

[0359] The permission to call the callee and / or the permission to access the first resource obtained by the electronic device when running the first caller can be called the first permission. The permission to call the callee and / or the permission to access the first resource obtained by the electronic device when running the second caller can be called the second permission.

[0360] The instance of the callee run by the electronic device in response to the first access request may be referred to as the first instance. The instance of the callee run by the third device in response to the second access request may be referred to as the second instance.

[0361] refer to Fig. 7A , Fig. 7A A schematic diagram of the software structure of the main device provided in the embodiment of the present application. The main device may be Figure 4The main device 200 or the main device 300 in the embodiment.

[0362] like Fig. 7A As shown, the main device may include the following modules: application information management module, distributed application permission management module, local application permission management module, distributed permission information library, local permission information library, permission application module, permission transfer module, call relationship management module, call relationship library, access control module. Among them:

[0363] The application information management module is used to manage the information of each APP and functional component installed on the main device, such as the name, etc. The application information management module is also used to synchronize the information of the local APP and functional components to other devices, and receive the information of APP and functional components synchronized by other devices (such as the object device).

[0364] The distributed application rights management module is used to synchronize the capability information of other devices (such as object devices) in the distributed system 10 to the main device, and can also be used to synchronize the capability information of the main device to other devices to other electronic devices.

[0365] The distributed permission information library is used to store the capability information that other devices (such as object devices) in the distributed system 10 open to the main device, and can also be used to store the capability information that the main device opens to other devices.

[0366] The permission application module is used to request the user to grant the permission required for the access request sent by the subject device to the object device.

[0367] The local application permission management module is used to manage the permission of each application (including APP and functional components) in the main device to use the capabilities of other devices in the distributed system 10. The method of obtaining this permission can be specifically referred to the permission application module and the relevant description of the method embodiment above, which will not be repeated here.

[0368] The local permission information library is used to store the permission information of each application (including APP and functional components) in the main device to use the capabilities of other devices in the distributed system 10. In some embodiments, the local permission information library can also be used to store the timeliness information of the permission of each application in the main device to use the capabilities of other devices.

[0369] The permission transfer module is used to send the permission information applied by the permission application module to the object device according to the calling relationship.

[0370] The call relationship management module is responsible for maintaining the call relationship consisting of the caller and the callee instance that provides services to the caller, and storing it in the call relationship library.

[0371] The call relationship library is used to store the call relationship consisting of the caller and the callee instance. The call relationship includes: the call relationship ID, the instance information of the callee, and the information of each caller that calls the instance.

[0372] The call relationship ID can be allocated by the subject device. For the same call relationship, the object device and the subject device can share the same call relationship ID, which can be carried in the access request sent to the object device and is allocated by the subject device and sent to the object device.

[0373] The instance information of the callee may include one or more of the following: the device ID of the object device, the APP ID of the callee, the user ID (UID) and process identifier (PID) of the instance. PID is the identity of the instance. When an electronic device runs an instance, it will assign a unique PID to the instance. PID and UID can be synchronized from the object device to the subject device.

[0374] The caller information includes the caller's application ID (APP ID), and may also include one or more of the following: the device ID of the subject device, the developer signature of the caller, the user ID (UID) of the caller, and the account ID of the subject device. Among them:

[0375] APP ID, used to identify an APP or functional component.

[0376] Device ID is used to identify a device. The device ID may be, for example, the name, serial number, media access control (MAC) address, etc. of the device.

[0377] Developer signature, used to identify the developer.

[0378] UID is used to identify the user to whom an APP or functional component belongs. Usually, electronic devices assign different UIDs to different installed APPs or functional components to distinguish them. In some embodiments, the electronic device may assign the same UID to each APP or functional component developed by the same developer. The same APP or functional component may have different UIDs in different electronic devices.

[0379] The account ID is used to identify the user currently logged in to the electronic device, for example, it can be a Huawei account.

[0380] Refer to Table 3 to Table 5, which exemplarily show the call relationships stored in the call relationship libraries of the three main devices.

[0381]

[0382] Table 3

[0383]

[0384] Table 4

[0385]

[0386] Table 5

[0387] The electronic device 200 may be the main device 200 in the above method embodiment, for example, a smart phone. The electronic device 300 may be the main device 300 mentioned in the above method embodiment, for example, a tablet computer. The electronic device 100 may be the object device 100 in the above method embodiment, for example, a smart screen.

[0388] It can be seen from Tables 3 to 5 that three main devices (electronic device 200, electronic device 300 and electronic device 400) simultaneously call the APP or functional component identified as "ID1" in the object device (electronic device 100), and the object device creates two instances, one instance provides services for the caller in electronic device 200, and the other instance provides services for two callers developed by the same developer in electronic devices 300 and 400.

[0389] The access control module is used to query the object device through the distributed application permission management module to see whether the object device has opened the permission required for the access request to the subject device when the subject device initiates an access request to the object device, and then query the caller who initiated the access request through the local application permission management module to see whether the caller has the permission required for the access request. When the results of the above two queries are both yes, the access control module confirms that the subject device can initiate the access request to the object device.

[0390] Fig. 7A This is only an illustrative example. The main device provided in the embodiment of the present application may also include more or fewer modules, which is not limited here.

[0391] Fig. 7A The modules in the main equipment mentioned above can be located in Figure 3B The application layer, application framework layer, system service layer, kernel layer, etc. in the electronic device shown are not limited here.

[0392] refer to Figure 7B , Figure 7B A schematic diagram of the software structure of the object device provided in the embodiment of the present application. The object device may be Figure 4 The object device 100 in the embodiment.

[0393] like Figure 7B As shown, the object device may include the following modules: application information management module, distributed application permission management module, local application permission management module, distributed permission information library, local permission information library, instance management module, permission transfer module, call chain management module, call relationship library, access control module. Among them:

[0394] The application information management module is used to manage the information of each APP and functional component installed on the object device, such as the name, etc. The application information management module is also used to synchronize the information of the local APP and functional components to other devices, and receive the information of the APP and functional components synchronized by other devices (such as the main device).

[0395] The distributed application permission management module is used to synchronize the capability information of the object device open to other devices (such as the main device) to other electronic devices, and is also used to synchronize the capability information of other devices (such as the main device) in the distributed system 10 open to the object device.

[0396] The distributed permission information library is used to store the capability information that the object device opens to other devices, and can also be used to store the capability information that other devices (such as the main device) in the distributed system 10 open to the object device.

[0397] The instance management module is responsible for dynamically enabling the instance of the callee according to the caller's information and providing services to the caller. Specifically, the instance management module can enable different instances of the callee for different callers.

[0398] The authority transfer module is used to receive the authority information required for the access request initiated by the main device and sent by the main device.

[0399] The local application permission management module is used to manage the usage permissions of each instance of the application (including APP and functional components) in the object device to its own resources. The local application permission management module can be used to grant the permission information required for the access request initiated by the subject device received by the permission transfer module to the instance of the callee created by the object device for the caller in the subject device.

[0400] The local permission information library is used to store the permission information of each instance of the application (including APP and functional components) in the object device to use its own resources. The method of obtaining this permission can be specifically referred to the permission application module and the relevant description of the method embodiment above, which will not be repeated here.

[0401] The call chain management module is responsible for maintaining the call relationship consisting of the caller and the callee instance that provides services to the caller, and storing it in the call relationship library.

[0402] The call relationship library is used to store the call relationship between the caller and the callee instance. The call relationship includes: call relationship ID, callee instance information, and each caller information that calls the instance. For the specific content of the call relationship, please refer to Fig. 7A Related description of the main device in.

[0403] Refer to Table 6, which exemplarily shows a calling relationship stored in the object device.

[0404]

[0405] Table 6

[0406] It can be seen from Table 6 that the APP or functional component identified as "ID1" in the object device (electronic device 100) is called by three main devices (electronic device 200, electronic device 300 and electronic device 400) at the same time, and the object device creates two instances, one instance provides services for the caller in electronic device 200, and the other instance provides services for two callers developed by the same developer in electronic devices 300 and 400.

[0407] The access control module is used to, when receiving an access request initiated by the main device to the object device, first query the object device through the distributed application permission management module whether the permission required for the access request is opened to the main device. When the object device opens the permission to the main device, the access control module can check through the local application permission management module whether the instance of the callee created for the caller in the main device has the permission required for the access request. If yes, the access control module confirms that the object device can run the instance, thereby responding to the access request. If not, the access control module can find the main device where the caller is located based on the call relationship maintained by the call chain management module, and apply to the main device for the permission required for the access request.

[0408] Figure 7B This is only an illustrative example, and the object device provided in the embodiment of the present application may also include more or fewer modules, which is not limited here.

[0409] Figure 7B The modules in the mentioned object device can be located in Figure 3B The application layer, application framework layer, system service layer, kernel layer, etc. in the electronic device shown are not limited here.

[0410] The various implementation modes of the present application can be combined arbitrarily to achieve different technical effects.

[0411] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

[0412] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.

[0413] In short, the above is only an embodiment of the technical solution of this application, and is not intended to limit the protection scope of this application. Any modification, equivalent replacement, improvement, etc. made according to the disclosure of this application shall be included in the protection scope of this application.

Claims

1. An access control method based on authority transfer, characterized in that: The method is applied to a communication system comprising a first device, a second device and a third device, wherein a first caller is installed in the first device, a second caller is installed in the second device, and a callee is installed in the third device; The first caller, the second caller, and the callee are an application program APP or a functional component; the APP is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function; The method comprises: The first device sends a first access request to the third device, where the first access request is used by the first caller to call the callee to access a first resource in the third device; The second device sends a second access request to the third device, where the second access request is used by the second caller to call the callee to access the first resource; The first device sends first permission information to the third device, where the first permission information indicates a first permission granted by a user, where the first permission includes a permission to call the callee and / or a permission to access the first resource; The second device sends second permission information to the third device, where the second permission information indicates a second permission granted by a user, where the second permission includes a permission to call the callee and / or a permission to access the first resource; The third device runs the first instance of the callee according to the first permission in response to the first access request to access the first resource; The third device runs the second instance of the callee according to the second permission in response to the second access request to access the first resource; The second instance is different from the first instance, the first instance and the second instance are processes or threads running in a random access memory RAM, and the first instance and the second instance are isolated from each other.

2. The method according to claim 1, characterized in that The first permission information further indicates the validity period of the first permission, and the validity period is any one of the following: valid once, valid within the first time, valid within the first area, or valid permanently; After the third device runs the first instance according to the first permission information to access the first resource, the method further includes: The first device sends a third access request to the third device, where the third access request is used by the first caller to call the callee to access the first resource; If the time limit is valid once, the third device refuses to respond to the third access request; If the time limit is valid within the first time and the time length for which the third device receives the first permission information does not exceed the first time; or, if the time limit is valid within the first area and the third device is located in the first area; or, if the time limit is permanently valid, the third device responds to the third access request and runs the first instance according to the first permission information to access the first resource.

3. The method according to claim 1 or 2, characterized in that: The first device sends a first access request to the third device, and the first device sends first permission information to the third device, specifically including: The first device sends a first access request to the third device, where the first access request carries first permission information.

4. The method according to any one of claims 1 to 3, characterized in that: Before the third device runs the first instance of the callee according to the first permission to access the first resource, the method further includes: The third device creates a first instance of the callee in response to the first access request.

5. The method according to any one of claims 1 to 4, characterized in that: Before the first device sends the first permission information to the third device, the method further includes: the first device outputting prompt information, where the prompt information is used to prompt the first permission; The first device sending the first permission information to the third device specifically includes: the first device sending the first permission information to the third device in response to the received first operation.

6. The method according to claim 5, characterized in that Before the first device outputs the prompt information, the method further includes: In response to the first access request, the third device sends an authorization request to the first device, where the authorization request is used to request a user to grant the first permission.

7. The method according to claim 5 or 6, characterized in that: The first operation includes one or more of the following: a user operation on a display screen, a preset face image, a preset fingerprint, a preset voice command, or a user operation on a button.

8. The method according to any one of claims 5 to 7, characterized in that: The first device outputs prompt information, specifically including: The first device displays a first user interface, in which prompt information and a first control are displayed; the first operation includes a user operation acting on the first control.

9. The method according to any one of claims 1 to 8, characterized in that: The first authority specifically includes: The permission of the first device to call the callee, and / or the permission of the first device to access the first resource; and / or, The caller's permission to call the callee, and / or the caller's permission to access the first resource.

10. The method according to any one of claims 1 to 9, characterized in that: The first resources include: resources with a privacy level higher than a threshold.

11. An access control method based on authority transfer, characterized in that: The method is applied to an electronic device, in which a callee is installed; the callee is an application program APP or a functional component, the APP is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function; The method comprises: The electronic device receives a first access request sent by a first device, where the first access request is used by a first caller in the first device to call the callee to access a first resource in the electronic device, where the first caller is the APP or the functional component; The electronic device receives a second access request sent by a second device, where the second access request is used by a second caller in the second device to call the callee to access the first resource, and the second caller is the APP or the functional component; The electronic device receives first permission information sent by the first device, where the first permission information indicates a first permission granted by a user, where the first permission includes a permission to call the callee and / or a permission to access the first resource; The electronic device receives second permission information sent by the second device, where the second permission information indicates a second permission granted by a user, where the second permission includes a permission to call the callee and / or a permission to access the first resource; The electronic device runs the first instance of the callee according to the first permission in response to the first access request to access the first resource; The electronic device runs a second instance of the callee according to the second permission in response to the second access request to access the first resource; The second instance is different from the first instance, the first instance and the second instance are processes or threads running in a random access memory RAM, and the first instance and the second instance are isolated from each other.

12. The method according to claim 11, characterized in that The first permission information further indicates the validity period of the first permission, and the validity period is any one of the following: valid once, valid within the first time, valid within the first area, or valid permanently; After the electronic device runs the first instance according to the first permission information to access the first resource, the method further includes: The electronic device receives a third access request sent by the first device, where the third access request is used by the first caller to call the callee to access the first resource; If the time limit is valid once, the electronic device refuses to respond to the third access request; If the time limit is valid within the first time and the time length during which the electronic device receives the first permission information does not exceed the first time; or, if the time limit is valid within the first area and the electronic device is located in the first area; or, if the time limit is permanently valid, the electronic device responds to the third access request and runs the first instance according to the first permission information to access the first resource.

13. The method according to claim 11 or 12, characterized in that: The electronic device receives a first access request sent by a first device, and the electronic device receives first permission information sent by the first device, specifically including: The electronic device receives a first access request sent by a first device, where the first access request carries first permission information.

14. The method according to any one of claims 11 to 13, characterized in that: Before the electronic device runs the first instance of the callee according to the first permission to access the first resource, the method further includes: The electronic device creates a first instance of the callee in response to the first access request.

15. The method according to any one of claims 11 to 14, characterized in that: Before the electronic device receives the first permission information sent by the first device, the method further includes: In response to the first access request, the electronic device sends an authorization request to the first device, where the authorization request is used to request a user to grant the first permission.

16. The method according to any one of claims 11 to 15, characterized in that: The first authority specifically includes: The permission of the electronic device to call the callee, and / or the permission of the electronic device to access the first resource; and / or, The caller's permission to call the callee, and / or the caller's permission to access the first resource.

17. The method according to any one of claims 11 to 16, characterized in that: The first resources include: resources with a privacy level higher than a threshold.

18. An electronic device, characterized in that: include: A memory and one or more processors; the memory is coupled to the one or more processors, the memory is used to store computer program codes, the computer program codes include computer instructions, and the one or more processors call the computer instructions to enable the electronic device to execute: receiving a first access request sent by a first device, where the first access request is used by a first caller in the first device to call a callee in the electronic device to access a first resource in the electronic device; The first caller and the callee are APP or functional component, the APP is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function; receiving a second access request sent by a second device, where the second access request is used by a second caller in the second device to call the callee to access the first resource, and the second caller is the APP or the functional component; receiving first permission information sent by the first device, where the first permission information indicates a first permission granted by a user, where the first permission includes a permission to call the callee and / or a permission to access the first resource; receiving second permission information sent by the second device, where the second permission information indicates a second permission granted by a user, where the second permission includes a permission to call the callee and / or a permission to access the first resource; In response to the first access request, running a first instance of the callee according to the first permission to access the first resource; In response to the second access request, running a second instance of the callee according to the second permission to access the first resource; The second instance is different from the first instance, the first instance and the second instance are processes or threads running in a random access memory RAM, and the first instance and the second instance are isolated from each other.

19. The electronic device according to claim 18, characterized in that: The first permission information further indicates the validity of the first permission, and the validity is any one of the following: valid once, valid within a first time, valid within a first region, or permanently valid; the one or more processors are further used to call the computer instruction to enable the electronic device to execute: After running the first instance according to the first permission information to access the first resource, a third access request sent by the first device is received, where the third access request is used by the first caller to call the callee to access the first resource; If the time limit is valid for one time, refusing to respond to the third access request; If the validity period is valid within the first time, and the duration for which the electronic device receives the first permission information does not exceed the first time; Alternatively, if the time limit is valid within the first area and the electronic device is located in the first area; or if the time limit is permanently valid, then in response to the third access request, the first instance is run according to the first permission information to access the first resource.

20. The electronic device according to claim 18 or 19, characterized in that: The one or more processors are specifically configured to call the computer instructions so that the electronic device executes: A first access request sent by a first device is received, where the first access request carries first permission information.

21. The electronic device according to any one of claims 18 to 20, characterized in that: The one or more processors are further configured to call the computer instructions to cause the electronic device to execute: Before running the first instance of the callee according to the first permission to access the first resource, the first instance of the callee is created in response to the first access request.

22. The electronic device according to any one of claims 18 to 21, characterized in that: The one or more processors are further configured to call the computer instructions to cause the electronic device to execute: Before receiving the first permission information sent by the first device, in response to the first access request, an authorization request is sent to the first device, where the authorization request is used to request a user to grant the first permission.

23. The electronic device according to any one of claims 18 to 22, characterized in that: The first authority specifically includes: The permission of the electronic device to call the callee, and / or the permission of the electronic device to access the first resource; and / or, The caller's permission to call the callee, and / or the caller's permission to access the first resource.

24. The electronic device according to any one of claims 18 to 23, characterized in that: The first resources include: resources with a privacy level higher than a threshold.

25. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on an electronic device, the electronic device is caused to execute the method as claimed in any one of claims 11 to 17.

26. A computer program product, characterized in that When the computer program product is run on a computer, the computer is caused to execute the method according to any one of claims 11 to 17.

27. A communication system, characterized in that: The communication system comprises: a first device, a second device and a third device, wherein the third device is configured to execute the method according to any one of claims 11 to 17.

Citation Information

Patent Citations

  • Open authorization, resource access method and device, and a server

    CN105991614A

  • Method and device for accessing device identifiers

    CN110637449A