Equipment sharing method and system, equipment and computer readable storage medium

By generating and transmitting the association information of device identifiers and security credentials through cloud servers, the complex operation problem when connecting devices with different accounts and shared devices is solved, realizing convenient trusted device authentication and seamless connection, and improving user experience.

CN121644128APending Publication Date: 2026-03-10HUAWEI TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-08-03
Publication Date
2026-03-10

AI Technical Summary

Technical Problem

In device sharing scenarios, when devices with different accounts establish a connection with shared devices, users need to manually scan a QR code or enter a PIN code for trusted device authentication, which is a complicated process and results in a poor user experience.

Method used

By generating and transmitting the association information of device identifiers and security credentials through cloud servers, devices with different accounts can be authenticated based on device security credentials, simplifying the connection process.

Benefits of technology

Without requiring users to manually scan QR codes or enter PIN codes, devices with different accounts can seamlessly and conveniently establish a trusted connection with shared devices, enhancing the user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121644128A_ABST
    Figure CN121644128A_ABST
Patent Text Reader

Abstract

The embodiment of the invention discloses a device sharing method and system, a device and a computer readable storage medium, the system comprises a first device, a cloud server, a second device and a third device, the first device and the second device log in a first account, and the third device logs in a second account; the target message is sent to the cloud server, so that the cloud server transmits first credible authorization information to the second device and transmits second credible authorization information to the third device, the first credible authorization information comprises a device security credential of the third device, and the second credible authorization information comprises a device security credential of the second device; and the second equipment and the third equipment perform equipment credible authentication according to the equipment security credential of the opposite-end equipment. In this way, the second device and the third device can carry out credible authentication on the different account number devices according to the device security credentials, authentication can be carried out without inputting pin codes or scanning codes, operation is easy and convenient, and user experience is better.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application. The original application has the application number 202310976487.6 and the original application date is August 3, 2023. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to the field of terminal technology, and in particular to a device sharing method, system, device, and computer-readable storage medium. Background Technology

[0003] With the continuous development of terminal technology and the increasing popularity of terminal devices, users are owning more and more diverse types of terminal devices and a growing number of terminal devices.

[0004] Currently, when a user shares or shares a terminal device they own with other users (i.e., device sharing), since different users' terminal devices are logged into with different accounts, other users' terminal devices need to complete trusted authentication through methods such as scanning a code or entering a PIN code before they can establish a connection with the terminal device shared by the user, thus enabling other users to use the terminal device shared by the user.

[0005] However, in device sharing scenarios, when other users' terminal devices (i.e., devices with different accounts) establish a connection with the user's shared terminal device (i.e., the shared device), the user needs to manually scan a QR code or manually enter a PIN code for device authentication, which is a complicated process and results in a poor user experience. Summary of the Invention

[0006] This application provides a device sharing method, system, device, and computer-readable storage medium, which can solve the problem that during the process of establishing a connection between devices with different accounts and shared devices, users need to manually scan a QR code or manually enter a PIN code for device authentication, which is complicated and results in a poor user experience.

[0007] In a first aspect, an embodiment of this application provides a device sharing system, including a first device, a cloud server, a second device, and a third device. The first device and the second device log in to a first account, and the third device logs in to a second account. The first account and the second account are different. The first device is used to: in response to one or more operations, send a target message to the cloud server, the target message including first information for indicating a first account and second information for indicating a second account, the first operation being used to share the second device with the second account; The cloud server is used to: transmit first trusted authorization information to a second device and second trusted authorization information to a third device based on first information and second information; the first trusted authorization information includes the association information between the device identifier of the third device and the security credential of the first device; the second trusted authorization information includes the association information between the device identifier of the second device and the security credential of the second device; the first security credential is the security credential of the third device and the second security credential is the security credential of the second device.

[0008] The second device is used to: receive first trusted authorization information from the cloud server and store the first trusted authorization information, which is authentication information used to authenticate the third device during the connection establishment process between the second device and the third device; The third device is used to: receive and store the second trusted authorization information from the cloud server; the second trusted authorization information is the authentication information used to authenticate the second device during the connection establishment process between the second device and the third device.

[0009] As shown above, after a user inputs one or more operations to the first device to authorize a trusted relationship between the second device and the second account, the first device responds by sending a target message to the cloud server. Based on the target message, the cloud server can determine that the devices of the first account and the second account have a trusted authorization relationship. Based on this trusted authorization relationship, it generates the association information between the device identifier of the second device and the security credentials of the second device, as well as the association information between the device identifier of the third device and the security credentials of the first device. The cloud server then transmits this information to the second and third devices accordingly, so that the trusted authorization relationship on the cloud side is reflected through the device security credentials on the device side. In this way, the second device (i.e., the shared device) and the third device (i.e., the device with a different account) can authenticate the trustworthiness of the other device based on its device security credentials. Users of devices with different accounts do not need to perform device trust authentication by entering PIN codes or scanning QR codes, making the operation simpler and providing a better user experience.

[0010] In some possible implementations of the first aspect, the first device is specifically used to: display a group member addition interface in response to a first operation, the first operation being an operation on a group member invitation control; receive a second operation applied to the group member addition interface, the second operation being used to determine the user invited to join the group; and send a target message to a cloud server in response to a third operation; the first information includes the identifier of the group owner or information of a first account, the second information includes the member identifier of the invited user in the group or information of a second account, the group owner being the first account, the account of the user invited to join the group being the second account, and the second device being a device within the group.

[0011] In this way, the group owner can invite other users (i.e., second accounts) to join the group to share devices within the group with other users (i.e., second accounts). This enables sharing devices within the group with devices of different accounts in a group setting, and allows devices of different accounts to use devices within the group (i.e., shared devices) as seamlessly and conveniently as devices of the same account, resulting in a better user experience.

[0012] In some possible implementations of the first aspect, the first device is specifically used to: in response to a fourth operation, determine a second device from multiple devices logged into a first account, the fourth operation being used to determine the sharing device; in response to a fifth operation, send a target message to the cloud server, the fifth operation being an operation on the member sharing options displayed on the shared member selection interface or at least one user information, the fifth operation being used to determine the user sharing the second device, the user's account being the second account; the first information includes information about the second device or information about the first account, and the second information includes information about the second account. In this way, a user can specify to share a device with other users (i.e., the second account), and devices with different accounts can use the shared device seamlessly and conveniently, just like devices with the same account, resulting in a better user experience.

[0013] In some possible implementations of the first aspect, the cloud server is specifically used to: obtain device information of the second device based on the first information, and generate association information between the device identifier of the second device and the security credentials of the second device based on the device information of the second device; obtain device information of the third device based on the second information, and generate association information between the device identifier of the third device and the security credentials of the first device based on the device information of the three devices.

[0014] In some possible implementations of the first aspect, the cloud server is also used to: obtain device information of the first device based on the first information, and generate association information between the device identifier of the first device and the security credential of the third device based on the device information of the second device; the security credential of the third device is the security credential of the first device.

[0015] Specifically, the cloud server is used to: generate second trusted authorization information based on the association information between the device identifier of the second device and the security credentials of the second device, and the association information between the device identifier of the first device and the security credentials of the third device; and transmit the second trusted authorization information to the third device. At this time, the second trusted authorization information is the authentication information used to authenticate the second device during the connection establishment process between the second device and the third device, or it can be the authentication information used to authenticate the first device during the connection establishment process between the first device and the third device.

[0016] The cloud server is also used to: transmit first trusted authorization information to the first device; The first device is also used to: receive first trusted authorization information from the cloud server and store the first trusted authorization information. At this time, the first trusted authorization information is authentication information used to authenticate the third device during the connection establishment process between the first device and the third device.

[0017] In this implementation, after the device sharing operation, not only are device security credentials for the second and third devices generated, but also the third device security credentials for the first device are generated. The third device security credentials of the first device are then transmitted to the third device, and the first device security credentials of the third device are transmitted to the first device. This allows the first and third devices (i.e., devices with different accounts) to perform trusted device authentication based on the device security credentials of the peer device, making it convenient and quick to establish a trusted connection with devices with different accounts, resulting in a better user experience.

[0018] In some possible implementations of the first aspect, the device information of the first device, the second device, and the third device may each include a device identifier and at least one of the following: device security level information, device model, device version information, and device inherent attribute information. At least one of the device security level information, device model, device version information, and device inherent attribute information is used to generate device security credentials. In this implementation, generating device security credentials based on long-term, fixed inherent information such as device security level information, device model, device version information, and device inherent attribute information allows the generated device security credentials to be valid for a long period.

[0019] In some possible implementations of the first aspect, the cloud server is specifically used for: obtaining the association information between the device identifier and the security credentials of the second device based on the first information; generating second trusted authorization information based on the association information between the device identifier and the security credentials of the second device; obtaining the association information between the device identifier and the security credentials of the third device based on the second information; generating first trusted authorization information based on the association information between the device identifier and the security credentials of the third device; transmitting the second trusted authorization information to the third device; and transmitting the first trusted authorization information to the second device. In this implementation, the cloud server can store pre-generated device security credentials for each device. Based on the information of the first account and the second account, the device security credentials and device identifiers of each device can be queried, and the association relationship between the device identifier and the device security credentials can be generated accordingly.

[0020] In some possible implementations of the first aspect, the cloud server is also used to: obtain, based on the first information, the association information between the device identifier of the first device and the security credentials of the third device; and transmit the first trusted authorization information to the first device; Specifically, the cloud server is used to generate second trusted authorization information based on the association information between the device identifier of the second device and the security credentials of the second device, and the association information between the device identifier of the first device and the security credentials of the third device.

[0021] In some possible implementations of the first aspect, the second trusted authorization information also includes the association information between the device identifier of the first device and the security credentials of the third device; The first device is also configured to: obtain wireless broadcast information of the third device, wherein the wireless broadcast message of the third device includes the device identifier of the third device; if the first device security credential corresponding to the device identifier of the third device is found in the first trusted authorization information, then the third device is determined to be a trusted device.

[0022] After the third device determines that the first device is trustworthy based on the second trusted authorization information, i.e., after authenticating the trustworthiness of both devices, the first device and the third device establish a trusted communication connection. At this point, the second trusted authorization information is not only the authentication information used to authenticate the second device during the connection establishment process between the second and third devices, but also the authentication information used to authenticate the first device during the connection establishment process between the first and third devices. Alternatively, in other embodiments, a separate third trusted authorization information can be generated and sent to the third device. This third trusted authorization information is used to authenticate the first device during the connection establishment process between the first and third devices. In this way, the first device and the third device (i.e., devices with different accounts) can also perform trusted device authentication based on device security credentials, facilitating a convenient and quick establishment of a trusted connection and providing a better user experience.

[0023] In some possible implementations of the first aspect, the second device is further configured to: obtain the wireless broadcast information of the third device, wherein the wireless broadcast message of the third device includes the device identifier of the third device; if the first device security credential corresponding to the device identifier of the third device is found in the first trusted authorization information, then the third device is determined to be a trusted device; at this time, the second device can initiate a connection to the third device, and the third device receives the connection request from the second device. After the third device determines that the second device is trusted based on the second trusted authorization information, that is, after authenticating the trustworthiness of both devices, the second device and the third device establish a trusted communication connection. In this way, the second device (i.e., the shared device) and the third device (i.e., the device with different accounts) can authenticate whether the other device is trusted based on the device security credential of the other device, thus establishing a trusted connection conveniently and quickly, resulting in a better user experience.

[0024] Alternatively, the third device may further be configured to: obtain the wireless broadcast information of the second device, the wireless broadcast information of the second device including the device identifier of the second device; if the security credentials of the second device corresponding to the device identifier of the second device are found in the second trusted authorization information, then the second device is determined to be a trusted device. In this case, the third device may initiate a connection to the second device, and the second device receives the connection request from the third device. In some possible implementations of the first aspect, the second device is also used to: automatically send connection requests to trusted third devices; or, if at least two trusted third devices exist, display at least two trusted third devices in the list of connectable devices, and in response to a user's selection operation on the list of connectable devices, send a connection request to the trusted third device specified by the selection operation. In this way, the second device (i.e., the shared device) can proactively initiate connections to devices with different accounts based on the association information between the device credentials and device identifier of the third device.

[0025] In some possible implementations of the first aspect, when displaying the list of connectable devices, the second device displays the user information and device information of the user to whom the connectable devices belong. For example, in a family group device sharing scenario, the large-screen device displays Xiaoming's Mate 30 when displaying the list of connectable devices. The large-screen device locally stores the association between the user information and the device information.

[0026] In some possible implementations of the first aspect, the first device is also used to: in response to the sixth operation, send a cancel sharing instruction to the cloud server, the sixth operation being used to cancel sharing the second device with the second account; The cloud server is also used to: receive a cancel sharing instruction from the first device, respond to the cancel sharing instruction, delete the authorization relationship between the second account and the second device, and send a first deletion instruction to the second device and a second deletion instruction to the third device; The second device is used to: receive a first deletion instruction from the cloud server, and in response to the first deletion instruction, delete the first trusted authorization information stored locally; The third device is used to: receive a second deletion instruction from the cloud server, and in response to the second deletion instruction, delete the second trusted authorization information stored locally.

[0027] In this implementation, when the user of the first device cancels device sharing, the trusted authorization information of the cloud server and the device security credentials stored on the device side can be deleted in a timely manner.

[0028] In some possible implementations of the first aspect, the first device and the second device are the same device. In this case, the first device will share itself as a shared device with the second account.

[0029] In some possible implementations of the first aspect, if the first device, second device, or third device is powered on again after being powered off, the first device, second device, or third device is further configured to: send a query command to the cloud server and then receive the response information returned by the cloud server in response to the query command, wherein the query command is used to query whether the device sharing relationship has been updated. This avoids the inability to update the information promptly if the device sharing relationship changes (e.g., sharing is canceled) during the device's power-off period.

[0030] Secondly, embodiments of this application provide a device sharing method applied to a first device, the method comprising: In response to the first action, the group member addition interface is displayed. The first action is an operation on the group member invitation control. In response to the second operation, a target message is sent to the cloud server. The target message is used to trigger the cloud server to transmit the first trusted authorization information to the second device and the second trusted authorization information to the third device. The second operation is an operation on the member invitation option displayed on the group member addition interface or at least one user information. The second operation is used to determine the user invited to join the group. The target message includes first information indicating the first account and second information indicating the second account. The group owner is the first account, and the user invited to join the group is the second account. The second device is a device within the group. The first and second devices log in to the first account, and the third device logs in to the second account. The first and second accounts are different. The first trusted authorization information includes the association information between the device identifier of the third device and the security credentials of the first device; The second trusted authorization information includes the association information between the device identifier of the second device and the security credentials of the second device; The first trusted authorization information is the authentication information used to authenticate the third device during the connection establishment process between the second device and the third device. The second trusted authorization information is the authentication information used to authenticate the second device during the connection establishment process between the second device and the third device.

[0031] In some possible implementations of the second aspect, the first information includes the identifier of the group owner or the information of the first account, and the second information includes the member identifier of the invited user in the group or the information of the second account.

[0032] Thirdly, embodiments of this application provide a device sharing method applied to a first device, the method comprising: In response to the first operation, a second device is determined from multiple devices logged into the first account, the first operation being used to determine the shared device; In response to the second operation, a target message is sent to the cloud server. The target message is used to trigger the cloud server to transmit first trusted authorization information to the second device and second trusted authorization information to the third device. The target message includes first information for indicating the first account and second information for indicating the second account. The second operation is an operation on the member sharing option or at least one user information displayed on the shared member selection interface. The second operation is used to determine the user sharing the second device, and the user sharing the second device is the second account. The first and second devices log in to the first account, and the third device logs in to the second account. The first and second accounts are different. The first trusted authorization information includes the association information between the device identifier of the third device and the security credentials of the first device; The second trusted authorization information includes the association information between the device identifier of the second device and the security credentials of the second device; The first trusted authorization information is the authentication information used to authenticate the third device during the connection establishment process between the second device and the third device. The second trusted authorization information is the authentication information used to authenticate the second device during the connection establishment process between the second device and the third device.

[0033] In some possible implementations of the third aspect, the first information includes information about the second device or information about the first account, and the second information includes information about the second account.

[0034] In some possible implementations of the second or third aspect, the group is a family group.

[0035] In some possible implementations of the second or third aspect, after sending the target message to the cloud server, the method further includes: in response to a third operation, sending a cancel sharing instruction to the cloud server, the third operation being used to cancel sharing the second device with the second account, the cancel sharing instruction being used to trigger the cloud server to delete the authorization relationship between the second account and the second device, and sending a first deletion instruction to the second device and a second deletion instruction to the third device, the first deletion instruction being used to instruct the second device to delete the stored first trusted authorization information, and the second deletion instruction being used to instruct the third device to delete the stored second trusted authorization information.

[0036] In some possible implementations of the second or third aspect, the second trusted authorization information further includes association information between the device identifier of the first device and the security credentials of the third device; the method further includes: Receive first trusted authorization information from the cloud server; obtain wireless broadcast information from the third device, the wireless broadcast message of the third device including the device identifier of the third device; if the first device security credential corresponding to the device identifier of the third device is found in the first trusted authorization information, then the third device is determined to be a trusted device; after the third device determines that the first device is a trusted device based on the second trusted authorization information, establish a communication connection with the third device.

[0037] Fourthly, embodiments of this application provide a device sharing method applied to a cloud server, the method comprising: Receive a target message from a first device. The target message includes first information for indicating a first account and second information for indicating a second account. The first account and the second account are different. The target message is information sent by the first device in response to an operation of sharing the second device with the second account. The first device and the second device log in to the first account. Based on the target message, the first trusted authorization information is transmitted to the second device, and the second trusted authorization information is transmitted to the third device, and the third device logs in to the second account; The first trusted authorization information includes the association information between the device identifier of the third device and the security credentials of the first device; the second trusted authorization information includes the association information between the device identifier of the second device and the security credentials of the second device; the first trusted authorization information is the authentication information used to authenticate the third device during the connection establishment process between the second device and the third device, and the second trusted authorization information is the authentication information used to authenticate the second device during the connection establishment process between the second device and the third device.

[0038] In some possible implementations of the fourth aspect, based on the target message, transmitting first trusted authorization information to the second device and second trusted authorization information to the third device includes: Based on the first information, obtain the device information of the second device, and based on the device information of the second device, generate the association information between the device identifier of the second device and the security credentials of the second device; Based on the second information, obtain the device information of the third device, and based on the device information of the three devices, generate the association information between the device identifier of the third device and the security credentials of the first device; Based on the association information between the device identifier of the second device and the security credentials of the second device, the second trusted authorization information is transmitted to the third device. Based on the association information between the device identifier of the third device and the security credentials of the first device, the first trusted authorization information is transmitted to the second device.

[0039] Among some possible implementations of the fourth aspect, the method also includes: Based on the first information, obtain the device information of the first device, and based on the device information of the second device, generate the association information between the device identifier of the first device and the security credentials of the third device; Based on the association information between the device identifier and device security credentials of the second device, second trusted authorization information is transmitted to the third device, including: Based on the association information between the device identifier of the second device and the security credentials of the second device, and the association information between the device identifier of the first device and the security credentials of the third device, a second trusted authorization information is generated; Transmit a second trusted authorization information to a third device.

[0040] In some possible implementations of the fourth aspect, based on the target message, transmitting first trusted authorization information to the second device and second trusted authorization information to the third device includes: Based on the first information, obtain the association information between the device identifier of the second device and the security credentials of the second device; Generate second trusted authorization information based on the association information between the device identifier of the second device and the security credentials of the second device; Based on the second information, obtain the association information between the device identifier of the third device and the security credentials of the first device; First trusted authorization information is generated based on the association information between the device identifier of the third device and the security credentials of the first device; Transmit the second trusted authorization information to the third device, and transmit the first trusted authorization information to the second device.

[0041] Among some possible implementations of the fourth aspect, the method also includes: Based on the first information, obtain the association information between the device identifier of the first device and the security credentials of the third device; Transmit the first trusted authorization information to the first device; Based on the association information between the device identifier of the second device and the security credentials of the second device, second trusted authorization information is generated, including: A second trusted authorization information is generated based on the association information between the device identifier of the second device and the security credentials of the second device, and the association information between the device identifier of the first device and the security credentials of the third device.

[0042] In some possible implementations of the fourth aspect, the device information includes the device identifier and at least one of the following: device security level information, device model, device version information, and device inherent attribute information.

[0043] Among some possible implementations of the fourth aspect, the method also includes: Receive a cancel sharing instruction from the first device, the cancel sharing instruction being an instruction sent by the first device in response to canceling the operation of sharing the second device with the second account; In response to the cancellation sharing command, the authorization relationship between the second account and the second device is deleted, and a first deletion command is sent to the second device and a second deletion command is sent to the third device. The first deletion command is used to instruct the second device to delete the stored first trusted authorization information, and the second deletion command is used to instruct the third device to delete the stored second trusted authorization information.

[0044] Fifthly, embodiments of this application provide a device sharing method applied to a second device, the method comprising: Receive first trusted authorization information from the cloud server. The first trusted authorization information includes the association information between the device identifier of the third device and the security credentials of the first device. The second device logs in to the first account, and the third device logs in to the second account. The first account and the second account are different. The first trusted authorization information is information sent by the cloud server based on the first information from the first device. The target message includes first information for indicating the first account and second information for indicating the second account. The target message is information sent by the first device in response to the first operation. The first operation is used to share the second device with the second account. The first device logs in to the first account. The system stores first trusted authorization information, which is authentication information used to authenticate the third device during the connection establishment process between the second and third devices.

[0045] Among some possible implementations of the fifth aspect, the method also includes: Obtain the wireless broadcast information of the third device, whose wireless broadcast message includes the device identifier of the third device; If the security credentials of the first device corresponding to the device identifier of the third device are found in the first trusted authorization information, then the third device is determined to be a trusted device. Automatically send a connection request to a trusted third device; or, if at least two trusted third devices exist, display at least two trusted third devices in the list of connectable devices, and in response to the user's selection operation on the list of connectable devices, send a connection request to the trusted third device specified by the selection operation.

[0046] In some possible implementations of the fifth aspect, the method further includes: receiving a first deletion instruction from a cloud server, and in response to the first deletion instruction, deleting the first trusted authorization information stored locally; wherein the first deletion instruction is an instruction sent by the cloud server according to a cancellation sharing instruction from the first device, the cancellation sharing instruction is an instruction sent by the first device in response to a sixth operation, and the sixth operation is used to cancel sharing the second device with the second account.

[0047] Sixthly, embodiments of this application provide a device sharing system, including a first device, a second device, and a third device. The first device and the second device log in to a first account, and the third device logs in to a second account. The first account and the second account are different. The first device is configured to: in response to a first operation, send a target message to a cloud server, the target message including first information for indicating a first account and second information for indicating a second account, the first operation being configured to share the second device with the second account; the target message being configured to trigger the cloud server to transmit first trusted authorization information to the second device and second trusted authorization information to the third device; The second device is used to: receive first trusted authorization information from the cloud server and store the first trusted authorization information, which is authentication information used to authenticate the third device during the connection establishment process between the second device and the third device; The third device is used to: receive second trusted authorization information from the cloud server and store the second trusted authorization information, which is the authentication information used to authenticate the second device during the connection establishment process between the second device and the third device; The first trusted authorization information includes the association information between the device identifier of the third device and the security credentials of the first device; the second trusted authorization information includes the association information between the device identifier of the second device and the security credentials of the second device.

[0048] In some possible implementations of the sixth aspect, the first device is specifically used for: In response to the second operation, a group member addition interface is displayed. The second operation is an operation on the group member invitation control. In response to the third operation, a target message is sent to the cloud server. The third operation is an operation on the member invitation option or at least one user information displayed on the group member addition interface. The third operation is used to determine the user invited to join the group. The first information includes the identifier of the group owner or the information of the first account. The second information includes the member identifier of the invited user in the group or the information of the second account. The group owner is the first account, the account of the user invited to join the group is the second account, and the second device is a device in the group. The first operation includes the second operation and the third operation.

[0049] In some possible implementations of the sixth aspect, the first device is specifically used for: In response to the fourth operation, a second device is determined from multiple devices logged into the first account. The fourth operation is used to determine the shared device. In response to the fifth operation, a target message is sent to the cloud server. The fifth operation is an operation on the member sharing options displayed on the shared member selection interface or at least one user information. The fifth operation is used to determine the user sharing the second device, and the user sharing the second device is the second account. The first information includes the information of the second device or the information of the first account, the second information includes the information of the second account, and the first operation includes the fourth operation and the fifth operation.

[0050] In some possible implementations of the sixth aspect, the first device is also used to: in response to the sixth operation, send a cancel sharing instruction to the cloud server, the sixth operation being used to cancel sharing the second device with the second account, the cancel sharing instruction being used to trigger the cloud server to delete the authorization relationship between the second account and the second device, and send a first deletion instruction to the second device and a second deletion instruction to the third device; The second device is used to: receive a first deletion instruction from the cloud server, and in response to the first deletion instruction, delete the first trusted authorization information stored locally; The third device is used to: receive a second deletion instruction from the cloud server, and in response to the second deletion instruction, delete the second trusted authorization information stored locally.

[0051] In some possible implementations of the sixth aspect, the second device is further configured to: obtain wireless broadcast information from the third device, wherein the wireless broadcast message of the third device includes the device identifier of the third device; if a first device security credential corresponding to the device identifier of the third device is found in the first trusted authorization information, then the third device is determined to be a trusted device. After the third device determines that the second device is trusted based on the second trusted authorization information, the second device and the third device establish a trusted communication connection.

[0052] In some possible implementations of the sixth aspect, the second device is also used to: automatically send a connection request to a trusted third device; or, if there are at least two trusted third devices, display at least two trusted third devices in the list of connectable devices, and in response to a user's selection operation on the list of connectable devices, send a connection request to the trusted third device specified by the selection operation.

[0053] In some possible implementations of the sixth aspect, when displaying the list of connectable devices, the second device displays user information and device information of the user to whom the connectable devices belong.

[0054] In some possible implementations of the sixth aspect, the second trusted authorization information also includes the association information between the device identifier of the first device and the security credentials of the third device; The first device is also configured to: obtain wireless broadcast information of the third device, wherein the wireless broadcast message of the third device includes the device identifier of the third device; if the first device security credential corresponding to the device identifier of the third device is found in the first trusted authorization information, then the third device is determined to be a trusted device.

[0055] After the third device determines that the first device is trustworthy based on the second trusted authorization information, that is, after authenticating the trustworthiness of both ends of the device, the first device and the third device establish a trusted communication connection.

[0056] In some possible implementations of the sixth aspect, the first device and the second device are the same device. In this case, the first device will share itself as a shared device with the second account.

[0057] In some possible implementations of the sixth aspect, if the first, second, or third device is powered on again after being powered off, the first, second, or third device is also used to: send a query command to the cloud server and then receive the response information returned by the cloud server in response to the query command, wherein the query command is used to query whether the device sharing relationship has been updated. This avoids the inability to update the information in a timely manner if the device sharing relationship changes during power-off (e.g., sharing is canceled).

[0058] In a seventh aspect, embodiments of this application provide a device sharing method applied to a device sharing system, the device sharing system including a first device, a second device, and a third device, wherein the first device and the second device log in with a first account, and the third device logs in with a second account, the first account and the second account being different; the method includes: In response to one or more operations, the first device sends a target message to the cloud server. The target message includes first information for indicating a first account and second information for indicating a second account. The first operation is used to share the second device with the second account. The target message is used to trigger the cloud server to transmit first trusted authorization information to the second device and second trusted authorization information to the third device. The second device receives and stores the first trusted authorization information from the cloud server. The first trusted authorization information is the authentication information used to authenticate the third device during the process of establishing a connection between the second device and the third device. The third device receives and stores the second trusted authorization information from the cloud server. The second trusted authorization information is the authentication information used to authenticate the second device during the connection establishment process between the second device and the third device. The first trusted authorization information includes the association information between the device identifier of the third device and the security credentials of the first device; the second trusted authorization information includes the association information between the device identifier of the second device and the security credentials of the second device.

[0059] In some possible implementations of the seventh aspect, the first device, in response to one or more operations, sends a target message to the cloud server, including: In response to the first operation, a group member addition interface is displayed, the first operation being an operation on the group member invitation control; in response to the second operation, a target message is sent to the cloud server, the second operation being an operation on the member invitation option or at least one user information displayed on the group member addition interface, the second operation being used to determine the user invited to join the group; the first information includes the identifier of the group owner or the information of the first account, the second information includes the member identifier of the invited user in the group or the information of the second account, the group owner is the first account, the user invited to join the group is the second account, and the second device is a device in the group.

[0060] In some possible implementations of the sixth aspect, the first device, in response to one or more operations, sends a target message to the cloud server, including: In response to the third operation, a second device is determined from multiple devices logged into the first account. The third operation is used to determine the shared device. In response to the fourth operation, a target message is sent to the cloud server. The fourth operation is an operation on the member sharing options displayed on the shared member selection interface or at least one user information. The fourth operation is used to determine the user sharing the second device. The account of the user sharing the second device is the second account. The first information includes the information of the second device or the information of the first account, and the second information includes the information of the second account.

[0061] Among some possible implementations of the seventh aspect, the method also includes: The first device responds to the fifth operation by sending a cancel sharing instruction to the cloud server. The fifth operation is used to cancel sharing the second device with the second account. The cancel sharing instruction is used to trigger the cloud server to delete the authorization relationship between the second account and the second device, and send a first deletion instruction to the second device and a second deletion instruction to the third device. The second device receives a first deletion command from the cloud server and, in response to the first deletion command, deletes the first trusted authorization information stored locally. The third device receives a second deletion command from the cloud server and, in response to the second deletion command, deletes the second trusted authorization information stored locally.

[0062] Among some possible implementations of the seventh aspect, the method also includes: The second device obtains the wireless broadcast information of the third device, and the wireless broadcast message of the third device includes the device identifier of the third device; if the first device security credential corresponding to the device identifier of the third device is found in the first trusted authorization information, then the third device is determined to be a trusted device. After the third device determines that the second device is trustworthy based on the second trusted authorization information, the second device and the third device establish a trusted communication connection.

[0063] In some possible implementations of the seventh aspect, after the third device determines that the second device is trustworthy based on the second trusted authorization information, the second device and the third device establish a trusted communication connection, including: The second device automatically sends a connection request to a trusted third device; or, if there are at least two trusted third devices, displays at least two trusted third devices in the list of connectable devices, and in response to the user's selection operation on the list of connectable devices, sends a connection request to the trusted third device specified by the selection operation.

[0064] The third device, based on the device identifier of the second device in the connection request, retrieves the security credentials of the second device corresponding to the device identifier of the second device from the second trusted authorization information, determines that the second device is trustworthy, and establishes a connection with the second device.

[0065] In some possible implementations of the seventh aspect, when displaying the list of connectable devices, the second device displays user information and device information of the user to whom the connectable devices belong.

[0066] In some possible implementations of the seventh aspect, the second trusted authorization information also includes association information between the device identifier of the first device and the security credentials of the third device; the method further includes: The first device obtains the wireless broadcast information of the third device, and the wireless broadcast message of the third device includes the device identifier of the third device; if the first device security credential corresponding to the device identifier of the third device is found in the first trusted authorization information, then the third device is determined to be a trusted device.

[0067] After the third device determines that the first device is trustworthy based on the second trusted authorization information, that is, after authenticating the trustworthiness of both devices, the first device and the third device establish a trusted communication connection.

[0068] In some possible implementations of the seventh aspect, the first device and the second device are the same device. In this case, the first device will act as a shared device and share itself with the second account.

[0069] In some possible implementations of the seventh aspect, if the first device, the second device, or the third device is powered on again after being powered off, the method further includes: after the first device, the second device, or the third device sends a query command to the cloud server, it receives response information returned by the cloud server in response to the query command, wherein the query command is used to query whether the device sharing relationship has been updated. This avoids the inability to update the information promptly if the device sharing relationship changes during power-off (e.g., sharing is canceled).

[0070] Eighthly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method as described in any of the second, third, or fourth aspects above. The electronic device may be a first device, a second device, a third device, or a cloud server.

[0071] Ninthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any of the second, third, or fourth aspects above.

[0072] In a tenth aspect, embodiments of this application provide a chip system including a processor coupled to a memory. The processor executes a computer program stored in the memory to implement the methods described in any of the second, third, or fourth aspects above. The chip system may be a single chip or a chip module composed of multiple chips.

[0073] In one aspect, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to perform the methods described in the second, third, or fourth aspects.

[0074] It is understood that the beneficial effects of aspects two through eleven above can be found in the relevant descriptions in aspect one above, and will not be repeated here. Attached Figure Description

[0075] Figure 1A This is a schematic diagram of a multi-terminal device scenario provided in an embodiment of this application; Figure 1B A schematic diagram of a mobile login account provided in an embodiment of this application; Figure 1C This is a schematic diagram of a super desktop scene provided in an embodiment of this application; Figure 1D This is a schematic diagram of QR code authentication provided in an embodiment of this application; Figure 1E This is a schematic diagram of PIN code authentication provided in an embodiment of this application; Figure 2 A schematic block diagram of a device sharing system provided in an embodiment of this application; Figure 3 A schematic flowchart illustrating a device sharing method provided in an embodiment of this application; Figure 4A A schematic diagram of a device sharing process provided in an embodiment of this application; Figure 4B A schematic diagram illustrating the invitation process for family group members provided in an embodiment of this application; Figure 5 This is a schematic diagram of a super desktop scene provided in an embodiment of this application; Figure 6 A schematic flowchart illustrating a device sharing method provided in an embodiment of this application; Figure 7A A schematic diagram of a device sharing scenario provided in the embodiments of this application. Figure 7B This is a schematic diagram illustrating the process of device sharing within a family group, as provided in an embodiment of this application. Figure 8 This is a schematic diagram illustrating a scenario for canceling device sharing, provided in an embodiment of this application. Figure 9 A schematic diagram of a device sharing system provided in an embodiment of this application; Figure 10 This is a schematic diagram illustrating the implementation process of a super desktop in a family group device sharing scenario provided in this application embodiment; Figure 11 This is a schematic diagram of the super desktop service provided in an embodiment of this application; Figure 12 This is a schematic diagram of the structure of the electronic device 1200 provided in the embodiments of this application. Detailed Implementation

[0076] In the following description, specific details such as particular system architectures and technologies are set forth for illustrative purposes and not for limiting purposes, in order to provide a thorough understanding of the embodiments of this application.

[0077] Multiple devices belonging to the same user typically log in to the same account, while different users' devices typically log in to different accounts.

[0078] For example, see Figure 1A The illustrated multi-terminal device scenario provided in this application embodiment includes, for example, a cloud server 11, a first user 12, and a second user 13. The first user 12 includes a mobile phone 121, a tablet 122, a computer 123, a smart speaker 124, a large-screen device 125, and a smart cockpit 126; the second user 13 includes a mobile phone 131, a smartwatch 132, and a Bluetooth headset 133.

[0079] All of the terminal devices of the first user 12 are logged into the same account, and all of the terminal devices of the second user 13 are also logged into the same account. However, the accounts logged into by the terminal devices of the first user 12 are different from the accounts logged into by the second user 13.

[0080] For example, see Figure 1BThe diagram shown illustrates the mobile phone login account provided in this application embodiment. The first user 12's mobile phone 121 logs in to account 127. The other terminal devices of the first user 12, namely tablet 122, computer 123, smart speaker 124, large screen device 125, and smart cockpit 126, also log in to account 127.

[0081] The second user 13 logged into account 134 on mobile phone 131. The other terminal devices of the second user 13, namely smartwatch 132 and Bluetooth headset 133, also logged into account 134.

[0082] Account 127 is 188******27, and account 134 is 158******66; the two accounts are not the same.

[0083] Understandable, Figure 1B The example demonstrates using a mobile phone number as an account to log in to a terminal device, but in practical applications, other methods such as email addresses can also be used to log in; it is not limited to a mobile phone number. Furthermore, Figure 1B The example shows two phones logging into Huawei accounts, but in actual applications, the accounts logged into by the two phones may not be from the same manufacturer.

[0084] Multiple terminal devices of the first user 12 can communicate and connect with the cloud server 11, as can multiple terminal devices of the second user 13. Typically, the cloud server 11 stores relevant information about each user's terminal devices. For example, the cloud server 11 stores the account information of the first user 12, as well as the information of each terminal device associated with the first user 12's account. The terminal device information may include, for example, device identity document (ID), device model, device usage data (such as user behavior data), and application data.

[0085] In a distributed environment, based on account management capabilities and distributed technologies (such as distributed databases), various terminal devices under the same account can securely and conveniently establish trusted communication connections and synchronize data through these trusted communication connections to achieve cross-device business.

[0086] For example, see Figure 1C The illustrated super desktop scenario diagram provided in this application embodiment shows that both the mobile phone 121 and the large-screen device 125 are terminal devices of the first user 12 and are logged into the same account. The mobile phone 121 and the large-screen device 125 first establish a trusted communication connection, and then synchronize data through the trusted communication connection to realize the "super desktop" service.

[0087] Specifically, mobile phone 121 and large-screen device 125 are on the same WLAN, and Bluetooth is enabled on both mobile phone 121 and large-screen device 125. The user turns on the "Super Desktop" switch on mobile phone 121 and enters the "Super Desktop" on large-screen device 125. The user gradually moves mobile phone 121 closer to large-screen device 125, and large-screen device 125 will automatically discover mobile phone 121 and display mobile phone 121 in the list of connectable devices. The user clicks on mobile phone 121 in the list of connectable devices on large-screen device 125, and large-screen device 125 can establish a communication connection with mobile phone 121.

[0088] After the large-screen device 125 and the mobile phone 121 establish a communication connection, the large-screen device 125 obtains application data and user data from the mobile phone 121, and displays the application icons installed on the mobile phone 121 on the "Super Desktop," such as... Figure 1C The large-screen device 125 displays icons of applications installed on the mobile phone 121, such as Smart Life, Settings, Recorder, App Store, Gallery, and Video. When the user clicks on the application icon on the "Super Desktop" of the large-screen device 125, the mobile phone 121 can synchronize the application data to the large-screen device 125 through the communication connection. The large-screen device 125 displays the application based on the synchronized data from the mobile phone 121, so that the user can use the applications installed on the mobile phone 121 on the large-screen device 125.

[0089] However, in distributed device sharing scenarios, when a user wants to share one of their terminal devices with other users, the user's terminal device and the other user's terminal device need to log in to different accounts. At this time, when establishing a trusted communication connection between terminal devices logged in with different accounts, the user needs to perform trusted device authentication by scanning a QR code or entering a PIN code to ensure that the devices are mutually trusted.

[0090] For example, in Figure 1C In the "Super Desktop" scenario shown, the first user 12 can directly use applications installed on the mobile phone 121 on the large-screen device 125. If the first user wants to share the large-screen device 125 with the second user 13, the large-screen device 125 becomes the shared device, and the second user 13's terminal devices are all devices with different accounts than the shared device. That is, when the first user 12 shares or shares the large-screen device 125 with the second user 13, the large-screen device 125 is the device that the first user 12 wants to share. For the shared device (i.e., the large-screen device 125), the second user 13's mobile phone 131, smartwatch 132, and Bluetooth headset 133 are all devices with different accounts, that is, terminal devices logged into different accounts.

[0091] If the second user 13 needs to use the large-screen device 125, they need to access the large-screen device 125 through their own terminal device. Suppose the second user 13 wants to use their mobile phone 131 to access the large-screen device 125 and use applications installed on their phone. However, since the large-screen device 125 is logged into the account of the first user 12, and the mobile phone 131 is logged into the account of the second user 13, the two devices are logged into different accounts. Therefore, the second user 13 cannot directly control the large-screen device 125 to access applications and data on their mobile phone 131. The second user 13 needs to use their mobile phone 131 to scan the QR code displayed on the large-screen device 125 or enter the PIN code displayed on the large-screen device 125 to complete device authentication between the mobile phone 131 and the large-screen device 125 before a trusted communication connection can be established.

[0092] For example, see Figure 1D The illustrated diagram of the QR code authentication provided in this application embodiment shows that the mobile phone 131 and the large-screen device 125 have Bluetooth enabled and are connected to the same WLAN. The user turns on the "Super Desktop" switch on the mobile phone 131 and enters the "Super Desktop" on the large-screen device 125. After clicking the "Connect to other devices" option displayed on the "Super Desktop," the large-screen device 125 displays the following on its screen: Figure 1D The QR code shown; after the user scans the QR code on the screen of the large-screen device 125 with their mobile phone 131, the mobile phone 131 will display a pop-up message as follows: Figure 1D The prompt message shown is used to ask the user whether to allow the connection to the super desktop of the large screen device. If the user clicks the "Yes" option, the mobile phone 131 will perform device authentication based on the device information of the large screen device 125 carried in the QR code, and after successful authentication, it will actively connect to the large screen device 125 based on the device information of the large screen device 125.

[0093] For example, see Figure 1E The schematic diagram of input PIN code authentication provided in the embodiment of this application is shown below. Figure 1D Type: After the user clicks the "Connect to other devices" option displayed on the "Super Desktop" of the large-screen device 125, the large-screen device 125 will display the following on its screen: Figure 1E The PIN code shown is used by the user to enter the PIN code on the mobile phone 131 so that the mobile phone 131 and the large screen device 125 can perform device authentication and establish a communication connection after successful authentication.

[0094] After the mobile phone 131 and the large-screen device 125 establish a communication connection, the second user 13 can use the application installed on the mobile phone 131 on the large-screen device 125 to realize the "super desktop" service.

[0095] As can be seen above, when a user shares one or more of their terminal devices with other users, the other users need to use their own terminal devices to scan a code or enter a PIN code for trusted device authentication in order to establish a trusted communication connection between the device with the different account and the shared device, and then allow other users to use the shared terminal device. The user operation process is relatively complicated and the user experience is poor.

[0096] In other words, in device sharing scenarios, users of devices with different accounts need to perform operations such as scanning a code or entering a PIN code to complete trusted device authentication between devices with different accounts and shared devices. The operation is relatively complicated and the user experience is poor.

[0097] To address the issue mentioned above where establishing a connection between devices with different accounts and shared devices requires users to perform trusted device authentication via scanning QR codes or entering PIN codes, resulting in complex operations and a poor user experience, this application provides a technical solution based on a device sharing system. After a user performs a device sharing operation on the device side, the cloud server records the device sharing information corresponding to the operation. This device sharing information represents the trusted authorization relationship between the shared device and the different account. The cloud server generates device security credentials based on the trusted authorization relationship and sends these credentials to the device side. The trusted authorization relationship on the cloud side is reflected through the device security credentials on the device side, enabling trusted authentication between devices with different accounts and shared devices using the device security credentials of the other device. This eliminates the need for users of the different account devices to perform trusted device authentication by entering PIN codes or scanning QR codes during the connection establishment process, making the operation simpler and providing a better user experience.

[0098] See Figure 2 The diagram shown is a schematic block diagram of a device sharing system provided in an embodiment of this application. The device connection system may include a first device 21, a cloud server 22, at least one second device 23 and at least one third device 24. The first device 21 and at least one second device 23 log in to a first account, and at least one third device 24 logs in to a second account. The first account and the second account are different.

[0099] The first device 21, the second device 23, or the third device 24 can be, but is not limited to, mobile phones, smart wearable devices (e.g., smart glasses, smart bracelets, etc.), in-vehicle devices, augmented reality (AR), virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs) and other electronic devices.

[0100] For example, such as Figure 1A In the scenario shown, the first device 21 and at least one second device 23 are both terminal devices of the first user 12, and both are logged into the first account. At this time, the first device 21 is a mobile phone 121, and the at least one second device 23 includes a tablet 122, a computer 123, a smart speaker 124, a large-screen device 125, and a smart cockpit 126. The at least one third device 24 is a device of the second user 13, which may include a mobile phone 131, a smartwatch 132, and a Bluetooth headset 133.

[0101] The cloud server 22 can be a single cloud server or a cluster of multiple single cloud servers. A single cloud server can be a software module providing cloud services or a physical device providing cloud services. In some embodiments, the cloud server 22 can include a home cloud, a device cloud, and a trust ring cloud. The home cloud can provide smart home cloud services, such as managing various smart home devices; the device cloud can provide device management cloud services, typically storing the association between accounts and devices, as well as device information for each device; the trust ring cloud can provide cloud services such as generating, storing, and encrypting device security credentials.

[0102] See Figure 3 The diagram shown is a schematic flowchart of a device sharing method provided in an embodiment of this application. This method can be applied to, for example... Figure 2 The device sharing system shown may include the following steps: Step S301: In response to one or more operations, the first device 21 sends a target message to the cloud server 22. The target message includes first information for indicating the first account and second information for indicating the second account. One or more operations are used to share the second device 23 with the second account.

[0103] The first operation is typically a device sharing operation input by the user of the first device 21, used to instruct the sharing of at least one second device with the second account. The first operation can consist of multiple operations such as clicking, long pressing, and selecting, to achieve the purpose of sharing at least one second device with the second account.

[0104] In some embodiments, one or more operations can be used to determine a second device from multiple devices logged into a first account, to determine a shared device, and to determine the user sharing the second device. For example, one or more operations may include operations to determine a second device from multiple devices logged into a first account, to determine a shared device. In this case, the shared device may be a second device 23, that is, selecting one or more second devices 23 from multiple devices logged into the first account to share one or more second devices as shared devices with other users. Operations may also include operations to determine the user sharing the second device. For example, this operation may be an operation on the member sharing options displayed on the shared member selection interface or an operation on at least one user information. Through this operation, information about the second account can be obtained to determine whether to share one or more second devices 23 with the second account. In this way, users can specify to share one or more devices with other users (i.e., the second account), and devices with different accounts can use the shared device seamlessly and conveniently, just like devices with the same account, resulting in a better user experience.

[0105] For example, based on Figure 1A In the scenario shown, the first user 12 shares the large-screen device 125 with the second user 13 via mobile phone 121. At this time, see... Figure 4A This diagram illustrates a device sharing process provided in an embodiment of this application. The main interface of mobile phone 121 displays icons for various applications, including but not limited to Smart Life 41, Settings, Recorder, App Store, Video, and Gallery. When a user clicks the Smart Life 41 icon, mobile phone 121 responds by displaying the "My Home" interface 42. The "My Home" interface 42 displays cards for various devices associated with the first user 12's account. Figure 4A The example shows card 43 of large screen device 125 and card of Huawei router, and also shows control 44.

[0106] In one implementation, users can share the device via card 43 on the large-screen device 125. Specifically, after a user long-presses card 43 on the large-screen device 125, the mobile phone 121 responds to the long-press operation and displays window 46. Window 46 displays two options: Share Device and Delete Device. The user clicks the Share Device option in window 46 to designate the large-screen device 125 as the shared device. In response to the Share Device option in window 46, the mobile phone 121 displays a sharing member selection interface 47. The sharing member selection interface 47 displays multiple member sharing options, such as scan sharing, sharing via Huawei account, and sharing with WeChat friends. It also displays multiple user accounts (e.g., accounts of Xiao Zhang, Xiao Wang, and Xiao Li). Users can select member sharing options and sharing members as needed.

[0107] The "Scan to Share" option refers to sharing via scanning the other party's "Smart Life" QR code. When a user clicks the "Scan to Share" option, the phone 121 responds to the click by automatically opening the camera and displaying a QR code scanning interface to scan the QR code presented by the other party.

[0108] The "Share via Huawei Account" option refers to sharing by entering a Huawei account or adding an account from contacts. When a user clicks the "Share via Huawei Account" option, the phone 121 responds to the click and displays the account input interface. The user enters the account to be shared on the account input interface to share the large-screen device 125 with the second account.

[0109] In addition to sharing the device via scanning, sharing via Huawei account, or sharing with WeChat friends, users can also share the large-screen device 125 with one or more user accounts by selecting multiple user accounts displayed in the sharing member selection interface 47.

[0110] In this scenario, one or more operations may include a long press operation on the card 43 of the large-screen device 125 and an operation to click the share device option in window 46 to select the large-screen device 125 as the sharing device. It may also include related operations on the sharing member selection interface 47, such as selecting multiple user accounts, clicking the share option via Huawei account, or entering a Huawei account. The fifth operation is used to determine the information of the second account. After determining the sharing device and the second account, the mobile phone 121 sends a target message to the cloud server 22. At this time, the first information used to indicate the first account may include the information of the second device (e.g., the device identifier of the large-screen device 125) or the information of the first account, and the second information may include the information of the second account. If the first information includes the information of the second device, the cloud server 22 can obtain the information of the first account based on the information of the second device according to the association between the device and the account (or user).

[0111] In another implementation, users can also share the device via control 44. Specifically, when a user clicks control 44, mobile phone 121 responds by displaying window 45, which includes multiple options such as sharing device, deleting device, and adding device. When a user clicks the sharing device option displayed in window 45, mobile phone 121 responds by displaying a sharing member selection interface 47. Users can then select the account to share with based on the sharing member selection interface 47, thus sharing the large-screen device 125 with the second account.

[0112] exist Figure 4AIn the scenario shown, the second device 23 shared with the second account is a large-screen device 125. The first operation may include long-pressing a card or clicking a control, as well as operations such as account selection or input. It can be understood that the first operation may instruct the first account to share one or more second devices with the second account, for example, in... Figure 1A In this scenario, the first user 12 can input a first operation into the mobile phone 121 to instruct the large screen device 125 and the smart cockpit 126 to be shared with the second user 13 (i.e., the second account).

[0113] In other embodiments, the first device 21 displays a group member addition interface in response to an operation on the group member invitation control; and in response to an operation on the member invitation option or at least one user information displayed on the group member addition interface, the operation is used to determine the user invited to join the group. After determining the user invited to join the group, a confirmation operation can be entered to trigger the first device 21 to send a target message to the cloud server 22 (i.e., in response to the user operation, send a target message to the cloud server). At this time, the first information may include the identifier of the group owner or the information of the first account, and the second information includes the member identifier of the invited user in the group or the information of the second account, where the group owner is the first account. The cloud server can obtain the information of the first account based on the identifier of the group owner and the information of the second account based on the member identifier. The account of the user invited to join the group is the second account, and the second device is the device in the group.

[0114] For example, consider a family group. In this case, a user can create a family group and invite other users to join, thus sharing their device with them. Inviting other users to join the family group can be viewed as a device sharing operation.

[0115] See Figure 4B The diagram shown in this application illustrates the invitation process for family group members, based on... Figure 4A In the scenario where the mobile phone 121 displays the "My Home" interface 42, and the user clicks on the control 48 displayed on the interface, the mobile phone 121 responds to the click operation on the control 48 and displays window 49. Window 49 displays multiple options such as My Home, Family Management, and Creating a New Family. After the user clicks on the Family Management option in window 49, the mobile phone 121 responds to the click operation and displays the Family Management interface 410.

[0116] The family management interface 410 displays a control 411. When the user clicks control 411, the phone 121 responds and displays interface 412. Interface 412 displays a family member addition control 413. When the user clicks family member addition control 413, the phone 121 responds and displays a member addition interface 414. The member addition interface 414 displays various member addition options, including adding members by scanning a QR code, adding members via Huawei account, and adding members via WeChat, and also displays account information for multiple users. Users can use the member addition interface 414 to send invitations to other users to join the family group. Figure 4B In this context, the owner of the family group is account 188******27. At this point, the second operation could include, for example, a click on control 413, and the third operation could include, for example, related operations on the member addition interface 414, to identify the second account.

[0117] Once the invited user agrees to the invitation, they become a member of the family group. Family group members can use all or some of the devices within the family group. Thus, the family group owner can invite other users to join the family group, thereby sharing all or some of the devices within the family group with them. For example, in... Figure 1A In the scenario shown, the first user 12 (i.e., the first account) invites the second user 13 (i.e., the second account) to join the family group through the Smart Life app on mobile phone 121. At this time, one or more operations may include related operations for initiating an invitation to the second account (e.g., clicking the family management option and clicking the family member addition control 413). The first operation is used to instruct the first account to share one or more third terminal devices with the second account. At this time, the multiple third terminal devices shared may include tablet 122, computer 123, smart speaker 124, large screen device 125, and smart cockpit 126.

[0118] It should be noted that in scenarios where the group owner invites other users to join a group to share all or part of the group's devices, the group is not limited to... Figure 4B The example shows a family group. For instance, user 12 and user 13 are friends. User 12 temporarily creates a friend group and invites user 13 to join it.

[0119] As can be seen, group owners can share devices within the group with other users (i.e., second accounts) by inviting them to join the group. This enables sharing of devices within the group with devices of different accounts in a group setting, allowing devices of different accounts to use the group's devices (i.e., shared devices) seamlessly and conveniently, just like devices of the same account, resulting in a better user experience.

[0120] It should be noted that users create a family group and identify the devices associated with that family group, thus determining which devices need to be shared; the group owner then designates a second account by requesting other users to join the family group. Furthermore, after creating a family group and identifying the devices associated with it, users can add or remove devices associated with the family group, thereby managing the devices shared with other users.

[0121] It should be noted that the above example uses the Smart Life application as the entry point for device sharing, but the entry point for device sharing is not limited to what is mentioned above, and is not restricted in this regard.

[0122] After a user inputs one or more operations into the first device 21 to instruct a first account to share at least one second device with a second account, the first device 21, in response to these operations, sends a target message to the cloud server 22. This target message includes first information indicating the first account and second information indicating the second account, thus representing that the first account has shared at least one second device with the second account. That is, the cloud server 22 can determine the second device shared by the first account with the second account based on the target message. For example, in... Figure 4A In the device sharing scenario shown, the target message sent by mobile phone 121 to the cloud server may include information about the second account (such as account number, account name, etc.) and information about the large-screen device 125 (such as the ID or identifier of the large-screen device, etc.). In this way, the cloud server can determine from the target message that the first account has shared the large-screen device 125 with the second account, thus establishing a trusted authorization relationship between the large-screen device 125 and the second account. For example, in... Figure 4B In the family group device sharing scenario shown, the target message can include information about the second account (such as the member ID of the second account in the family group) and information about the first account (such as the group owner ID of the family group). In this way, the cloud server can obtain the trusted authorization relationship between the devices in the family group and the second account based on the target message.

[0123] In some embodiments, the first information may include information about the target second device, and the second information may include information about the second account.

[0124] For example, the information of the second account may be the user identifier of the second account, the account information of the second account (such as the account number), or the member ID of the second account in the family group. In a family group scenario, after an invited user agrees to join the family group, a member ID within the group is assigned to the newly joined family member to identify that family member. The information of the target second device may include the device identifier or device name of the target second device. The target second device is one of multiple second devices, and this device is designated by the user to be shared with other users. For example, in Figure 4A In a device sharing scenario, when a user shares a large-screen device 125 with a second account, the mobile phone 121 uploads the device identifier or device name of the large-screen device 125 to the cloud server. At this time, the target second device is the large-screen device 125.

[0125] In other embodiments, the first information may include information about a first account, and the second information may include information about a second account. The first account information may include the user identifier of the first account, the account information of the first account (e.g., the account number of the first account), or the unique ID of the first account in the family group. The second account information may include the user identifier of the second account, the account information of the second account (e.g., the account number), or the member ID of the second account in the family group. For example, in a family group scenario, the first account is the owner of the family group and has its own owner ID within the family group. The second account is a member of the family group. When the user of the second account agrees to join the family group, the first device 21 uploads the owner ID and member ID to the cloud server 22.

[0126] In some other embodiments, the first information may include information about a first account and information about a target second device, and the second information may include information about a second account. The target second device is one or more devices specified by the user.

[0127] In step S302, the cloud server 22 transmits the first trusted authorization information to the second device 23 and the second trusted authorization information to the third device 24 based on the first information and the second information.

[0128] The first trusted authorization information includes the association information between the device identifier of the third device 24 and the first device security credential; the second trusted authorization information includes the association information between the device identifier of the second device 23 and the second device security credential. The first device security credential is the device security credential of the third device, and the second device security credential is the device security credential of the second device.

[0129] The cloud server 22 can provide account management and device management capabilities. It can store the correspondence between various accounts and devices. Through the correspondence between accounts and devices, all devices associated with an account can be queried. In addition, it also stores the device information of each device, which may include, but is not limited to: device model, device ID, device name, device security level information, device version information, and device inherent attribute information.

[0130] In some embodiments, the first information includes information about a first account, and the second information includes information about a second account. Based on the information of the first account, the cloud server 22 can query each second device associated with the first account and obtain the device information of each second device. For each second device, based on the device information, a second device security credential for that second device is generated, and the second device security credential and the device identifier of that second device are associated to establish a relationship between the second device security credential and the device identifier. Finally, based on the relationship between the second device security credential and the device identifier of each second device, second trusted authorization information is obtained. That is, the second trusted authorization information may include the association information between the second device security credential and the device identifier of at least one second device.

[0131] After generating the second trusted authorization information, the cloud server 22 can obtain relevant information (such as communication addresses) of each third device associated with the second account based on the information of the second account. Then, based on the relevant information of the third devices, it can send the second trusted authorization information to one or more third devices. It is understandable that the cloud server 22 can send the second trusted authorization information to all third devices, to some third devices, or even to specific third devices.

[0132] Similarly, based on the information of the second account, cloud server 22 can obtain the information of each third device associated with the second account and the device information of each third device. For each third device, based on the device information, a first device security credential is generated for that third device, and the first device security credential is associated with the device identifier of the third device to establish a relationship between the first device security credential and the device identifier of the third device. Finally, based on the relationship between the third devices, first trusted authorization information is obtained. That is, the first trusted authorization information may include the association information between the first device security credential and the device identifier of at least one third device.

[0133] After generating the first trusted authorization information, the cloud server 22 can obtain the relevant information (such as communication address) of each second device associated with the first account based on the information of the first account, and then send the first trusted authorization information to one or more second devices based on the relevant information of the second devices.

[0134] It should be noted that the security level, model, version, and inherent attributes of the second and first devices are generally fixed and unlikely to change over a considerable period. Based on this fixed and unchanging information, the generated device security credentials can remain unchanged for a long time, eliminating the need for frequent credential generation. However, if device security credentials are generated based on non-fixed information that changes rapidly, the cloud server 22 would need to regenerate the credentials every time the device information changes, potentially requiring frequent credential generation.

[0135] In other embodiments, the first information may include information about the target second device, or information about the first account and information about the target second device; the second information may include information about the second account. In this case, the cloud server 22 can obtain the information of the first account based on the correspondence between the account and the device, and based on the information of the target second device. It then generates second trusted authorization information based on the first account information and first trusted authorization information based on the second account information. The specific process can be found above and will not be repeated here.

[0136] In practical applications, when cloud server 22 generates device security credentials based on device information, it can use public key infrastructure (PKI) technology to sign the device information, thereby maximizing the security of device security credential transmission.

[0137] It is worth noting that the cloud server 22 can pre-generate device security credentials for each device. After obtaining the target message, it can query the second device security credentials of the second device and the first device security credentials of the third device based on the first and second information, and establish the association between the device security credentials and device identifiers of each device. Alternatively, the cloud server 22 can pre-generate the association between the device security credentials and device identifiers of each device. After obtaining the target message, it can query the association information between the second device security credentials and the device identifier of the second device, as well as the association information between the device identifier of the third device and the first device security credentials, based on the first and second information.

[0138] In step S303, the second device 23 receives the first trusted authorization information from the cloud server 22 and stores the first trusted authorization information. The first trusted authorization information is the authentication information used to authenticate the third device during the connection establishment process between the second device and the third device.

[0139] In step S304, the third device 24 receives the second trusted authorization information from the cloud server 22 and stores the second trusted authorization information; the second trusted authorization information is the authentication information used to authenticate the second device during the connection establishment process between the second device and the third device.

[0140] The second device 23 and the third device 24 can authenticate whether the peer device is trustworthy based on the device security credentials of the peer device stored locally. If both devices are authenticated as trustworthy, the two devices can establish a trusted communication connection.

[0141] For example, after scanning for wireless broadcast information emitted by surrounding devices, the second device 23 reads each piece of first trusted authorization information locally. For each piece of wireless broadcast information, based on the first trusted authorization information, it determines whether a device security credential corresponding to the device identifier carried in the wireless broadcast information has been found. Specifically, for each piece of wireless broadcast information, the device identifier carried in the wireless broadcast information is compared with the device identifier in the first trusted authorization information to determine whether they are consistent. If the device identifier carried in the wireless broadcast information is consistent with one of the device identifiers in the first trusted authorization information, then the device security credential corresponding to that device identifier is used as the device security credential corresponding to the device identifier of the wireless broadcast information, that is, it is determined that a device security credential corresponding to the device identifier carried in the wireless broadcast information has been found. If none of the device identifiers in the first trusted authorization information are consistent with the device identifier carried in the wireless broadcast information, then it is determined that no device security credential corresponding to the device identifier carried in the wireless broadcast information has been found. The wireless broadcast information can be, for example, Bluetooth broadcast information or Wi-Fi broadcast information.

[0142] For each wireless broadcast message, if the second device finds the device security credentials corresponding to the device identifier of the wireless broadcast message, it determines that the device corresponding to the device identifier of the wireless broadcast message is a trusted device and adds it to the trusted device list; conversely, if it cannot find the device security credentials corresponding to the device identifier of the wireless broadcast message, it determines that the device corresponding to the device identifier of the wireless broadcast message is an untrusted device. In this way, during the process of establishing a connection between devices with different accounts and shared devices, the third terminal device (i.e., the shared device) can perform trusted authentication on each second terminal device (i.e., devices with different accounts) based on the first correspondence.

[0143] In some embodiments, if the second device initiates a connection request to the third device, the second device obtains the third device's radio broadcast information, which includes the third device's device identifier. If the second device finds a first device security credential corresponding to the third device's device identifier in the first trusted authorization information, then the second device is determined to be a trusted device; that is, the second device authenticates the third device as a trusted device through the first trusted authorization information. After determining that the third device is a trusted device, the second device can send a connection request to the third device, which includes information such as the second device's device identifier. The third device can query the device security credential corresponding to the device identifier carried in the connection request from the second trusted authorization information. If the corresponding device security credential is found, the third device is determined to be a trusted device, and a trusted communication connection is established with the second device.

[0144] Similarly, if a third device initiates a connection request to the second device, the third device obtains the second device's wireless broadcast information, which includes the second device's device identifier. If the third device finds the second device's security credentials corresponding to its device identifier in the second trusted authorization information, then the second device is confirmed as a trusted device. That is, the third device 24 authenticates the second device as a trusted device through the second trusted authorization information. The second device, based on the first trusted authorization information, determines whether it has the third device's device security credentials stored locally to perform trusted authentication of the third device.

[0145] Understandably, the first trusted authorization information includes the relationship between the device identifier of the third device and the security credentials of the first device. When the device identifier of the target radio broadcast information (i.e., one of the multiple radio broadcast information scanned) is the same as the device identifier in the first trusted authorization information, the device sending the target radio broadcast information is considered to be one of at least one third device. Based on the correspondence between the device security credentials and the device identifier, the second device can identify the third device among the surrounding devices. Since it locally stores the device security credentials of the third device, it confirms that the authentication of the third device is successful, identifies the third device as a trusted device, and initiates a connection to the trusted third device to establish a communication connection. Specifically, the connection request sent by the second device to the third device carries the device information of the second device (e.g., the device identifier). After receiving the connection request, the third device determines whether it can find the device security credentials of the second device in the second trusted authorization information. If it can find the device security credentials of the second device, it determines that the second device is trusted and establishes a trusted communication connection with the second device.

[0146] It is understandable that there may be one or more third devices in the surrounding environment of the second device, so the second device can identify one or more trusted third devices. When a trusted third device is identified, the second device can proactively send a connection request to the trusted third device to establish a communication connection. Of course, it can also send a connection request to the trusted third device after receiving a trigger command from the user.

[0147] When multiple trusted third devices are identified, the second device can, at the user's request, send a connection request to the user-specified trusted third device to establish a connection. Alternatively, the second device can proactively send connection requests to all trusted third devices.

[0148] For example, see Figure 5 The illustrated super desktop scenario diagram provided in this application embodiment depicts a device sharing scenario within a family group. The owner of the family group wants to share their large-screen device 51 with other members of the family group. The large-screen device 51 is logged into the owner's account. The owner can do this through... Figure 4B The process illustrated involves inviting two users, Xiaoming and Jack@mail.com, to a family group. For each of these two users, cloud server 22 generates first trusted authorization information for that user account and sends it to the large-screen device 51. Cloud server 22 also generates second trusted authorization information for the large-screen device and sends it to each device under the usernames Xiaoming and Jack@mail.com. Thus, large-screen device 51 stores the device security credentials for each of Xiaoming and Jack@mail.com's devices, and each of Xiaoming and Jack@mail.com's devices stores the device security credentials for large-screen device 51. The large-screen device 51, Xiaoming's phone, and Jack@mail.com's phone all have Bluetooth enabled. The large-screen device 51, Xiaoming's phone, and Jack@mail.com's phone broadcast wireless information. The large-screen device 51 scans and obtains the wireless broadcast information in the surrounding environment, and based on the first trusted authorization information stored locally, it authenticates Xiaoming's Mate 30 Pro and P50, as well as Jack@mail.com's Mate 40 Pro, as trusted, and displays multiple phones in the connectable device connection 53 of the super desktop 52. Similarly, Xiaoming's Mate 30 Pro and P50, as well as Jack@mail.com's Mate 40 Pro, will also perform device trust authentication on the large-screen device 51 based on the second trusted authorization information.

[0149] Users can click on a device in the list of connectable devices 53 to specify the terminal device to send a connection request. The large-screen device 51 then responds to the click operation by sending a request to the clicked device. For example, if the user clicks on Xiaoming's Mate 30 Pro in the list of connectable devices 53, the large-screen device 51 will send a connection request to Xiaoming's Mate 30 Pro to establish a communication connection with that device.

[0150] It should be noted that, in Figure 5 In the scenario shown, when the large screen device 51 is shared with only one user—that is, the Owner shares the large screen device 51 with Xiaoming and invites Xiaoming to join the family group—the large screen device 51 identifies Xiaoming's two trusted devices and displays them on the list of connectable devices 53 for the user to choose from. Furthermore, when the large screen device 51 is shared with at least two users—that is, the Owner shares the large screen device 51 with Xiaoming and Jack@mail.com and invites Xiaoming and Jack@mail.com to join the family group—the large screen device 51 can identify the trusted devices of each user and display them on the list of connectable devices 53 for the user to choose from.

[0151] It is worth pointing out that, in Figure 5 In this scenario, when the large-screen device 51 displays a list of connectable devices, it not only shows device information (such as device name) but also user information for each device (such as Xiaoming), i.e., it displays the user to which each device belongs. At this time, the large-screen device 51 locally stores the correspondence between user information (such as user identifier) ​​and device information. Based on this correspondence, it can query the user and user information to which each device belongs. By concatenating the device information and user information, it obtains display information including both device and user information, which is then displayed on the list of connectable devices, resulting in a better user experience.

[0152] Understandably, in distributed scenarios, to ensure secure connections between multiple devices and enable the secure transfer of user and application data across these devices, it's typically necessary to guarantee mutual trust and reliability between devices. This means that trust relationships must have been established between devices, and a secure connection channel can be built after verifying these trust relationships to achieve secure transmission of user and application data. However, for devices logged into different accounts, establishing a trusted connection only after verification via QR code scanning or PIN code entry results in a poor user experience.

[0153] In this embodiment, when a user inputs a first operation to the first device 21 to instruct the sharing of the second device with the second account, the authorization of the second device and the second account can be considered trustworthy. In response to the first operation, the first terminal device sends a target message to the cloud server. Based on the target message, the cloud server obtains a trustworthy authorization relationship between the second device and the second account. Based on this trustworthy authorization relationship, it generates association information between the device identifier of the second device and the security credentials of the second device, as well as association information between the device identifier of the third device and the security credentials of the first device and the device identifier. The cloud server then transmits this information to the second and third devices accordingly, so that the trustworthy authorization relationship on the cloud side is reflected through the device security credentials on the terminal side. In this way, the second device (i.e., the sharing device) and the third device (i.e., the device with a different account) can authenticate whether the other device is trustworthy based on its device security credentials. Users of the device with a different account do not need to perform device trust authentication by entering a PIN code or scanning a QR code, making the operation simpler and providing a better user experience. For example, in a group device sharing scenario, through the device sharing scheme of this application embodiment, after the second account confirms joining the group, the user of the second account can use the device logged in by the first account within the group by logging into the device of the second account, so that the user of the second account can obtain the same or similar experience as the user of the same account (i.e. the first account), thereby improving the user experience of the second account.

[0154] It should also be noted that when users of devices with different accounts perform trusted authentication by entering a PIN code or scanning a QR code, and the shared device establishes a connection between the device with the different account, the shared device cannot discover the device with the different account on its own and the user needs to add it manually. Furthermore, every time the shared device and the device with the different account establish a connection, the user needs to repeatedly enter a PIN code or scan a QR code, which means that from the user's perspective, authentication is required every time.

[0155] In this embodiment, the shared device (i.e., the second device) can proactively discover the user to which the device belongs by comparing the device identifier carried in the wireless broadcast information with the device identifier in the authorized information based on the correspondence between the device identifier and the device security credentials. In addition, the shared device and the device with different accounts can persistently store trusted authorization information. Therefore, during each connection establishment process, trusted device authentication can be performed based on the stored trusted authorization information. From the user's perspective, there is no need to perform repeated authentication every time.

[0156] As described above, the cloud server 22 can generate first trusted authorization information and second trusted authorization information based on the first information and the second information, and transmit the first trusted authorization information to the second device and the second trusted authorization information to the third device.

[0157] Of course, besides transmitting the first trusted authorization information to the second device, it can also be transmitted to the first device, or to all devices associated with the first account, including both the first device and each of the second devices. This allows not only the second device to perform trusted device authentication on the third device based on the first trusted authorization information, but also the first device to perform trusted device authentication on the third device based on the first trusted authorization information, enabling cross-device services (such as Super Desktop, Distributed Photo Album, Super Terminal, etc.) with each of the third devices. In this case, the second trusted authorization information also includes the association between the device identifier of the first device and the security credentials of the third device.

[0158] For example, when the first information includes information about a second device or a target second device, and the second information includes information about a second account, the cloud server 22, based on the association between the account and the device, searches for the information of the first account according to the information of the target second device or the second device, and obtains the device information of the first device and the device information of each second device based on the information of the first account. Based on the device information of the first device, it generates association information between the device identifier of the first device and the security credentials of the third device; based on the device information of each second device, it generates association information between the device identifier of the second device and the security credentials of the second device, and generates second trusted authorization information based on the association information between the device identifier of the second device and the security credentials of the second device, as well as the association information between the device identifier of the first device and the security credentials of the third device. The second trusted authorization information is transmitted to the third device, which can then automatically discover and authenticate the first device based on the association information between the device identifier of the first device and the security credentials of the third device in the second trusted authorization information, and automatically discover and authenticate the second device based on the association information between the device identifier of the second device and the security credentials of the second device in the second trusted authorization information.

[0159] Similarly, cloud server 22 generates first trusted authorization information based on the information of the second account, and transmits the first trusted authorization information to the first device and the second device.

[0160] In this way, the first device and the third device can establish a trusted communication connection after authenticating the trustworthiness of the peer device based on device security credentials, thereby enabling cross-device services between the first device and the third device; the second device and the third device can also establish a trusted communication connection after authenticating the trustworthiness of the peer device based on device security credentials, thereby enabling cross-device services between the second device and the third device.

[0161] To better explain the device sharing process, the following will combine... Figure 6 The following is a schematic flowchart illustrating a device sharing method provided in an embodiment of this application.Figure 6 As shown, the method may include the following steps: Step S601: In response to the first operation, the first device 21 sends a target message to the cloud server 22. The target message includes first information for indicating the first account and second information for indicating the second account. The first operation is used to share the second device 23 with at least one second account.

[0162] It should be noted that users can share devices with a single user or multiple users. For example, in a family group device sharing scenario, the owner can require multiple users to join the family group to share devices within the family group with multiple users. When sharing a device with at least one secondary account, steps S602 to S607 are executed for each secondary account. Thus, the secondary device (i.e., the shared device) stores the correspondence between the device security credentials and device identifiers of each secondary account. Based on the correspondence between the device security credentials and device identifiers of each secondary account, the device autonomously discovers the terminal devices associated with each secondary account and performs trusted authentication. For example, see... Figure 5 In the scenario shown, both Xiaoming and Jack@mail.com are secondary accounts, and the large-screen device 51 can identify the trusted devices of Xiaoming and Jack@mail.com.

[0163] Step S602: The cloud server 22 obtains the first trusted authorization information and the second trusted authorization information based on the first information and the second information.

[0164] The second trusted authorization information includes the association information between the device identifier of the first device and the security credentials of the third device, as well as the association information between the device identifier of the second device and the security credentials of the second device. The first trusted authorization information includes the association information between the device identifier of the third device and the security credentials of the first device.

[0165] It should be noted that the first and second trusted authorization information can be generated in advance or in real time. For details on the generation process, please refer to the relevant content above, which will not be repeated here.

[0166] The first trusted authorization information is the authentication information used to authenticate the third device during the connection establishment process between the second device and the third device; the second trusted authorization information is the authentication information used to authenticate the second device during the connection establishment process between the second device and the third device; the second trusted authorization information is also the authentication information used to authenticate the first device during the connection establishment process between the first device and the third device.

[0167] Step S603: Cloud server 22 sends first trusted authorization information to first device 21.

[0168] Step S604: Cloud server 22 sends first trusted authorization information to second device 23.

[0169] Step S605: Cloud server 22 sends second trusted authorization information to third device 24.

[0170] Step S606: The first device 21 performs device trust authentication on the third device 24 based on the first trusted authorization information.

[0171] Step S607: The second device 23 performs device trust authentication on the third device 24 based on the first trusted authorization information.

[0172] In step S608, the third device 24 performs device trust authentication on the first device 21 and the second device 23 based on the second trusted authorization information.

[0173] Step S609: Trusted authentication is passed at both ends of the first device 21 and the third device 24, and a trusted communication connection is established.

[0174] For example, if the first device 21 initiates a connection request to the third device 24, the first device 21 obtains the wireless broadcast information of the third device 24. The wireless broadcast message of the third device includes the device identifier of the third device. If the first device security credential corresponding to the device identifier of the third device 24 is found in the first trusted authorization information, then the third device 24 is determined to be a trusted device. After determining that the third device 24 is trusted, the first device 21 can send a connection request to the third device 24. This connection request carries the device information of the first device 21 (such as the device identifier). After receiving the connection request, the third device determines whether the device security credential of the first device can be found in the second trusted authorization information. If the device security credential of the first device can be found, then the first device is determined to be trusted, and a trusted communication connection is established with the first device.

[0175] For example, in the super terminal service scenario, if the first device 21 needs to obtain relevant information of each third device, it can perform automatic discovery, trusted authentication and automatic connection initiation processes based on the first trusted authorization information to establish a trusted communication connection with the third device.

[0176] In step S610, the trusted authentication of both ends of the second device 23 and the third device 24 is passed, and a trusted communication connection is established.

[0177] As can be seen from the above, not only is the association information between the device identifier of the second device and the security credentials of the second device generated, but also the association information between the device identifier of the first device and the security credentials of the third device is generated. The second trusted authorization information, including these two association information, is transmitted to the third device, and the first trusted authorization information is transmitted to the first device and the second device. This ensures that all devices associated with the first account store the device security credentials of the devices associated with the second account, and the devices associated with the second account also store the device security credentials of the devices associated with the first account. Devices between the two accounts can automatically discover and authenticate devices of different accounts based on their local device security credentials, and establish trusted communication connections. This enables cross-device services between devices of different accounts, is easy to operate, and allows users to have the same user experience as devices with the same account, resulting in a better user experience.

[0178] For example, see Figure 7A The diagram illustrates a device sharing scenario. The first and second devices log into the first account, while the third device logs into the second account. The first device responds to a first operation by sending a target message to the cloud server. Based on the target message, the cloud server sends first trusted authorization information to the second device and second trusted authorization information to the third device. The second device performs trusted authentication on the third device based on the first trusted authorization information, and the third device performs trusted authentication on the second device based on the second trusted authorization information. Once both ends pass trusted authentication, the second and third devices establish a trusted communication connection to perform cross-device services.

[0179] Furthermore, the cloud server can also transmit first trusted authorization information to the first device. At this time, the second trusted authorization information also includes the association information between the device identifier of the first device and the security credentials of the third device. The first device performs trusted authentication on the third device based on the first trusted authorization information, and the third device performs trusted authentication on the first device based on the second trusted authorization information. After both ends pass trusted authentication, the first device and the third device establish a trusted communication connection to conduct cross-device services.

[0180] It is worth noting that the first device can also be shared with other users. In this case, the second device and the first device mentioned above can be the same device. The first device responds to the first operation by sharing itself with the second account and sending a target message to the cloud server. Based on the target message, the cloud server transmits first trusted authorization information to the first device and second trusted authorization information to the third device. After the first device and the third device perform trusted authentication based on the first and second trusted authorization information, a trusted communication connection is established.

[0181] It should also be noted that after the cloud server 22 sends the trusted authorization information to the terminal device, the terminal device can perform trusted device authentication for devices with different accounts based on the trusted authorization information. For example, the first target device receives trusted authorization information from the cloud server. The trusted authorization information includes the association information between the device identifier and the device security credentials of the second target device. The first target device is logged into a first account, and the second target device is logged into a second account. The first account and the second account are different.

[0182] The first target device acquires at least one scanned wireless broadcast message. If, based on trusted authorization information, a device security credential corresponding to the device identifier in the target wireless broadcast message is found, then the device corresponding to the target wireless broadcast message is determined to be a trusted second target device, and the target wireless broadcast message is one of the broadcast messages in the at least one wireless broadcast message. A communication connection is established with the trusted second target device. That is, the trusted authorization relationship on the cloud side is reflected through the device security credential on the terminal side, enabling trusted device authentication between two devices with different accounts based on the device security credential of the peer device. Furthermore, the trusted authorization information does not need to be generated based on device sharing operations. That is, the embodiments of this application do not need to apply the device sharing scenario, but can perform trusted device authentication on any two devices with different accounts based on the peer device security credential stored locally.

[0183] To better explain the device sharing process, the following will combine... Figure 7B The process of sharing devices within a family group, as illustrated in the embodiments of this application, is explained.

[0184] In a home group device sharing scenario, the home group is created by the Owner user. After a user creates a home group, the terminal device generates a Group ID and sends it to the home cloud. For example, referring to the scenario diagram shown in 4B, the user can create a new home group by clicking the Create New Home option in window 49 or by clicking the Create New Home option in the home management interface 410. Mobile phone 121 responds to the user's home group creation operation, sends relevant information to the home cloud, and the home cloud assigns a Group ID to the home group and records the association between the Group ID and the user account or user ID.

[0185] Each new user added to a family group is assigned a member ID. A family group contains multiple devices, and each device has a unique device ID.

[0186] like Figure 7BAs shown, in this scenario, the system architecture can include an account family, a home cloud, a device cloud, a signal ring cloud, device 1, device 2, and device 3. Device 1 and device 3 log in to account A, and device 2 logs in to account B. Accounts A and B are different. Device 1 and device 3 are the owner user's devices, and device 2 is the device of a family group member.

[0187] Device 1 and Device 2 both include a Smart Living App, HiLink service, soft bus, and trusted authorization relationship data. Device 3 includes HiLink service or credential authorization service and trusted authorization relationship data. Device 1 and Device 2 can be, for example, mobile phones, and Device 3 can be, for example, a large-screen device.

[0188] Among them, Account Family, Home Cloud, Device Cloud, and Signal Ring Cloud are all cloud-based. Trust Ring Cloud provides the ability to generate device security credentials and an interface for querying device credentials. It stores various device security credentials, as well as encrypted device security credentials. That is, Trust Ring Cloud can generate device security credentials based on device information provided by Device Cloud and establish a correspondence between device security credentials and device identifiers. After generating device security credentials, it persistently stores them and provides a query interface. Device Cloud can query the device security credentials corresponding to a device identifier (e.g., device ID).

[0189] Device cloud can provide the ability to maintain relationships between devices and users, as well as interfaces for notification authorization relationships. Device cloud stores the devices associated with each account, as well as device information for each device. Device cloud typically stores the relationship between device IDs and user IDs or user accounts (i.e., the relationship between DeviceId and Uid).

[0190] Home Cloud (or Smart Home Cloud) provides interfaces for Push, MQTT, message center notifications, retrieving account family members, adding family members, requesting authorization relationships, and notifying device cloud authorization relationships. In other words, Home Cloud can associate user accounts, manage family groups, receive information from various terminal devices, and send notifications or messages to various terminal devices. An account family can be viewed as a specific data structure stored on Home Cloud; it is an abstract concept. Home Cloud can synchronize user account family group information, meaning it synchronizes members from the account family and notifies the Home Cloud when a new member is added. The Smart Living App retrieves new members from the Home Cloud.

[0191] like Figure 7B As shown, the process of sharing devices within a family group may include: 1. Add family members. The owner user invites account B to join the family group on the Smart Life App of device 1. The process of inviting users to join the family group can be found in [link to app]. Figure 4BThis will not be elaborated further here. Device 1 responds to the Owner user's action of adding a family member by sending relevant information to the Home Cloud. This information may include the family group ID and the member's user ID (UID). In this scenario, the Owner user's action of adding a family member on Device 1 can be seen as an action of sharing the device with account B, and the group ID and member's user ID sent by Device 1 to the Home Cloud can be seen as the target message.

[0192] 2. Home Cloud push or feed notification for member authorization confirmation. That is, based on the user ID of the member uploaded by device 1, Home Cloud sends an invitation notification message to the Smart Life App of device 2 via push or feed, so that the user of device B can confirm whether to join the family group.

[0193] 3. Member Authorization Confirmation. After member B confirms joining the family group on the Smart Living App of device 2, device 2 sends a confirmation message to the Home Cloud to inform the Home Cloud that it has confirmed joining the family group. After receiving the confirmation message from device 2, the Home Cloud assigns a member ID to account B and records a sharing relationship (or authorization relationship) to record the trusted authorization relationship between account B and various devices under account A.

[0194] 4. After receiving the confirmation message from Device 2, the Home Cloud transmits the OwnerId, Member ID, and DevIds to the Device Cloud. The OwnerId can be used to find the devices associated with the Owner user based on the group ID. The DevIds can be the device IDs of all devices associated with account A, or a specific device ID under account A; in this example, it's the device ID of device 3. In other words, the Home Cloud synchronizes the relationships between Owner, Member, and authorized device DevIds to the Device Cloud. 5. The Device Cloud obtains device information for Device 1, Device 2, and Device 3 based on OwnerId, Member ID, and DevIds, and sends this information to the Trust Ring Cloud. The Trust Ring Cloud generates DevId credentials (i.e., the mapping between device security credentials and device identifiers) for Device 1, Device 2, and Device 3 based on the device information and provides a query interface for the Device Cloud to query. The Device Cloud can retrieve the DevId credentials for Device 1, Device 2, and Device 3 from the Trust Ring Cloud using the device ID.

[0195] The device cloud obtains the DevId credentials of device 1, device 2, and device 3, and pushes a notification to the home cloud. This notification may include the DevId and push notification, or the Uid and push notification, to inform the home cloud which device to send the trusted authorization relationship to or to notify the device to query the trusted authorization relationship.

[0196] 6. Based on the push notification from the device cloud, the home cloud sends authorization relationship data to devices 2 and 3, or notifies devices 2 and 3 to actively query authorization relationship data. Alternatively, the home cloud can also send authorization relationship data to device 1, or device 1 can obtain authorization relationship data from device 3 through distributed data synchronization technology.

[0197] After obtaining the authorization relationship data, Device 1, Device 2, and Device 3 can persist the authorization relationship to disk (i.e., store it locally). Device 1 and Device 3 have the same authorization relationship data, which can include a Uidlist. The Uidlist includes the corresponding DevIdlist and Udidlist for each Uid. Device 2's authorization relationship data is a DevInfolist (DeviId and Udid). Here, UID is the user ID, and DevId (device ID) is a unique identifier within the environment. The device ID changes when a device is deleted or added. Udid is a unique identifier for the device across the entire network; it remains unchanged when a device is deleted or added. Typically, a device identifier includes both the device ID and the device's Udid. Figure 7B The DevIdlist in the document contains device security credentials, which typically include a series of security certificates and the device's security identifiers.

[0198] exist Figure 7B In the process, device 2 stores the correspondence between device identifiers and device security credentials of device 1 and device 3, and device 3 stores the correspondence between device identifiers and device security credentials of device 2.

[0199] Device 3 can autonomously discover Device 2 based on trusted authorization relationship data, perform trusted authentication on Device 2, and establish a trusted communication connection with Device 2. Similarly, Device 2 can autonomously discover Device 1 and Device 3 based on trusted authorization relationship data, perform trusted authentication on Device 1 and Device 3, and establish a trusted communication connection with Device 1 and Device 3.

[0200] exist Figure 7B In the scenario shown, the family group owner can share devices within the group with other group members, and supports the synchronization of device security credentials.

[0201] In some embodiments, after device sharing, the user can cancel device sharing. In this case, the first device 21 can respond to the device sharing cancellation operation by sending a cancellation sharing instruction to the cloud server 22. The device sharing cancellation operation is used to cancel sharing the second device with the second account, and the cancellation sharing instruction is used to instruct the cancellation of sharing the second device with the second account.

[0202] For example, see Figure 8 The schematic diagram shown in this application embodiment illustrates a scenario for canceling device sharing, based on...Figure 4A In the device sharing scenario shown, the "My Home" interface 42 of mobile phone 121 displays a "My" control 415. After the user clicks the "My" control 415, mobile phone 121 responds to the click operation and displays interface 416, which displays a sharing management option 417. After the user clicks the sharing management option 417, mobile phone 121 responds to the click operation and displays interface 418. Interface 418 displays information about the devices currently shared by the account and a "Remove Sharing" control 419. After the user selects one or more devices to be unshared, they click "Remove Sharing" control 419 to cancel the sharing of the selected devices. At this time, the sixth operation can include clicking the "Remove Sharing" control 419, or it can include multiple operations such as clicking the sharing management option 417 and clicking "Remove Sharing" control 419.

[0203] After receiving the cancellation sharing instruction from the first device 21, the cloud server 22 responds to the cancellation sharing instruction by deleting the authorization relationship between the second account and the second device, and sends a first deletion instruction to the second device and a second deletion instruction to the third device. The first deletion instruction is used to instruct the second device to delete the stored first trusted authorization information, and the second deletion instruction is used to instruct the third device to delete the stored second trusted authorization information.

[0204] It is understandable that if cloud server 22 sends first trusted authorization information to first device 21 during device sharing, cloud server 22 can also send deletion command to first device 21 to allow first device 21 to delete the first trusted authorization information stored locally.

[0205] In this way, when the user of the first device 21 cancels device sharing, the trusted authorization information of the cloud server and the device security credentials stored on the terminal device can be deleted in a timely manner.

[0206] Users may cancel device sharing when a device goes offline, and cloud server 22 may not be able to promptly notify the offline terminal device to delete its local device security credentials. In this case, if the first, second, or third device powers on again after being powered off, it can send a query command to the cloud server and receive a response from the cloud server. The query command is used to check whether the device sharing relationship has been updated. This avoids the inability to update in a timely manner after the device sharing relationship changes (e.g., sharing is canceled) during power-off. When the response information indicates that the device sharing relationship has changed and device sharing has been canceled, the terminal device promptly deletes the locally stored trusted authorization information. For example, in... Figure 7B In the scenario shown, after device 1, device 2, or device 3 is powered on again, it can send a query command to the cloud side. This query command carries the device ID, so that the cloud side can pull again based on the device ID to obtain information such as device security credentials and device identification.

[0207] As described above, through the device sharing scheme provided in this application embodiment, the terminal device can locally store the correspondence between device security credentials and device identifiers, and perform processes such as autonomous discovery, trusted authentication, and automatic connection initiation for devices with different accounts based on the correspondence between device security credentials and device identifiers, so as to realize cross-device services.

[0208] To better illustrate the technical solutions provided in the embodiments of this application, the following will use the Super Desktop cross-device service as an example to illustrate the process of automatic device discovery, authentication, and connection after device sharing, as well as the process of using the shared device.

[0209] See Figure 9 The diagram shown is a framework schematic of a device sharing system provided in this application embodiment. The device sharing system may include a cloud side and an end side. The cloud side may include a home cloud, a device cloud, and a trust ring cloud, as detailed above, and will not be repeated here. The software system architecture of the terminal device on the end side may include an application layer, a framework and service layer, a hardware abstraction layer (HAL) layer, and a Linux kernel. The first device 21, the second device 23, and the third device 24 may all include this software system architecture.

[0210] The application layer includes applications such as Smart Living, Shell Applications, Device Credential Association Service, and End-to-Cloud Connection Service. Smart Living provides device sharing and storage, enabling management of devices within a family group. Shell Applications handle cross-device application opening and control. Desktop Applications handle cross-device application information synchronization and display. The End-to-Cloud Connection Service implements end-to-cloud communication, handling communication between end devices and the cloud service. The Device Credential Management Service provides device security credential management capabilities.

[0211] The framework and service layer include modules such as collaborative configuration management, distributed hardware virtualization, device management (DM), device authentication, device profile (DP), and soft bus.

[0212] Among them, the collaborative configuration management service provides atomic capabilities for collaborative services such as "application migration management", "hardware migration management" and "display adaptation strategy". It can make decisions on collaborative strategies based on configurable collaborative rules, call the distributed capabilities of the super terminal to achieve collaboration, and realize migration management and display strategy adaptation.

[0213] Distributed hardware virtualization is used to support the invocation of hardware capabilities across devices, such as calling hardware capabilities like cameras, audio, and GPS through camera virtualization, audio virtualization, and GPS virtualization. Device management is used to support device discovery, device binding, querying the list of trusted devices, and querying currently trusted devices.

[0214] The device profile is used to store trusted authorization relationship data, that is, to store the correspondence between device security credentials and device identifiers.

[0215] Device certification is used to support device certification services.

[0216] The soft bus is used to provide connectivity capabilities such as underlying device discovery and device connection.

[0217] based on Figure 9 The software system architecture of the end-side device shown allows the shared device to listen for device online and offline events via the soft bus after device sharing. During device trust authentication, the device security credentials and device identifier correspondence stored in the DP can be obtained to identify whether there are trusted devices in the surrounding area (e.g., whether there are trusted devices in the family group). After the device is trusted, the device connection is automatically initiated via the soft bus, and the device's application data is synchronized.

[0218] For example, see Figure 10 The illustration shows a schematic diagram of the super desktop implementation process in a family group device sharing scenario provided by the embodiments of this application. This process can be divided into several stages, such as family device scanning, automatic discovery and connection of family devices, and cross-device exchange of application information and user interface. Figure 10 The example provided shows that the common household equipment is a cockpit or a large-screen device, and the main control device for family members is a member's mobile phone.

[0219] Understandably, in family group device sharing scenarios, common family devices are typically shared with other users within the family group. For example, see... Figure 1A The first user 12 and the second user 13 are in the same family group. The first user 12 is the owner and owns the large-screen device 125 and the smart cockpit 126. The large-screen device 125 and the smart cockpit 126 are public devices in the family. The first user 12 shares these public devices with the second user 13 through the device sharing operation on the mobile phone 121. The second user 13 can then use the large-screen device 125 and the smart cockpit 126 through the mobile phone 131. For example, based on the super desktop service, the second user can use the application installed on the mobile phone 131 on the large-screen device 125 and the smart cockpit 126.

[0220] During the home device scanning phase, home public devices and member control devices first enable wireless functions such as Bluetooth and Wi-Fi to trigger them to send out wireless broadcast information and scan for surrounding wireless broadcast information. For example... Figure 10As shown, the main control device for each member is a mobile phone, and the shared home devices are the cockpit or large-screen devices. After the mobile phone and the cockpit or large-screen device enable Bluetooth, the shared home devices scan for Bluetooth broadcasts from surrounding devices.

[0221] During the automatic discovery and connection phase of home devices, the device discovery capabilities provided by the soft bus and device management module allow the cockpit or large-screen device to discover the device via Bluetooth. Then, the device authentication module can be invoked for trusted device authentication. During authentication, the device authentication module can query the phone's device security credentials in the Device Authentication Module (DP). If the DP finds the phone's security credentials, it confirms the phone is secure and trustworthy, and initiates a connection. After the cockpit or large-screen device establishes a connection with the phone, the Device Management Module (DM) binds the phone's device information and notifies the desktop application device to come online, synchronizing the phone's application data. The DP stores the mapping between the phone's device identifier and its security credentials, which can be obtained through the device sharing scheme described earlier.

[0222] During the cross-device application information exchange phase, desktop applications between mobile phones and cockpit or large-screen devices perform business interactions so that the cockpit or large-screen devices can obtain application data from the mobile phones.

[0223] During the user interface phase, the cockpit or large-screen device, based on the phone's application data, displays the phone's application icons on the super desktop through shell applications and desktop applications; that is, it displays the super desktop icons. For example, see... Figure 1C In the scene shown, the interface of the large-screen device 125 displays the icons of the applications installed on the mobile phone 121.

[0224] It should be noted that in a family group device sharing scenario, when sharing a device with multiple family group members, the shared device can locally store the device security credentials of multiple users' terminal devices. Based on the device security credentials of multiple users' terminal devices, the terminal devices of multiple users can be automatically discovered and authenticated. For example, see... Figure 5 Xiaoming and Jack@mail.com are both members of a family group, and the large-screen device 51 can identify Xiaoming and Jack@mail.com as trusted devices. Furthermore, the shared device locally stores the mapping between user information and terminal devices, thus identifying the user to whom the terminal device belongs and displaying that user information in the list of connectable devices.

[0225] As can be seen from the above, the device sharing scheme provided in this application embodiment allows the device security credentials of devices with different accounts to be stored on the terminal side. Based on these credentials, the shared device can automatically discover the devices of family group members (devices with different accounts), perform trusted authentication on the family group members' devices, and automatically initiate connections to the family group members' devices. Family group members do not need to perform trusted authentication through scanning QR codes or entering PIN codes, and they do not need to perform such operations every time they connect. For example, device A can directly access the application list on device B and support application filtering and control according to device capabilities.

[0226] After the shared device displays the Super Desktop, users can use applications installed on devices with different accounts. When users use applications installed on devices with different accounts on the shared device, the shared device can adapt to its screen resolution and orientation, and supports cross-device hardware migration. For example, the shared device can display applications according to the shared device's screen resolution; it can also use its microphone for application recording, its speakers for playback, its camera for video recording, and its GPS for location services, etc.

[0227] For example, see Figure 11 The illustrated diagram of the super desktop service provided in this application embodiment shows that the shared device is a cockpit or large-screen device, and the device with a different account is a mobile phone. The cockpit or large-screen device synchronizes the application data of the mobile phone and displays the super desktop based on the Launcher application. The super desktop includes icons of various applications installed on the mobile phone. This process may include: 1. When a user clicks an application icon on the super desktop of the cockpit or large screen device, the cockpit or large screen device responds to the click operation, launches or pulls up the screen casting shell application, loads the phone's application interface through the screen casting shell application, and launches the application through starActivity.

[0228] 2. The collaborative configuration management service of the cockpit or large screen device notifies the mobile phone's collaborative configuration management service to launch the corresponding application.

[0229] 3. The mobile phone's collaborative configuration management service calculates application display strategies (such as landscape / portrait switching and resolution adaptation); calls virtualization hardware capabilities; calls DDMS to create a virtual display; obtains and uses hardware capabilities (including virtual audio, virtual camera, and fused GPS); configures camera strategies to use the cockpit or large-screen device's camera; and configures audio offloading strategies to offload media audio and navigation audio from the mobile phone application to the audio devices of the cockpit or large-screen device.

[0230] 4. The phone's collaborative configuration management service calls the system interface to launch the application and display it on the virtual display.

[0231] 5. Start screen mirroring on your phone, which means starting the distributed hardware virtualization service and sending the virtual application interface to the cockpit or large screen device for display.

[0232] 6. The cockpit or large-screen device receives the screen projection data stream transmitted by the mobile phone, so as to receive the data stream displayed by the mobile phone application, and sends the screen projection data stream to the shell application for display.

[0233] As can be seen from the above, in a home group device sharing scenario, the end-device uses device security credentials to implement application flow functionality, and enables applications to adapt to the device screen display and support access to distributed hardware capabilities. For example, device A can open applications on device B, the application interface is adapted to device A's screen, and the application supports using various hardware capabilities of device A.

[0234] In other words, when a user displays an app icon across devices on the large screen, the large screen launches the HiWindow app; the collaborative configuration management on the large screen notifies the collaborative configuration management on the mobile phone to launch the corresponding app; the collaborative configuration management on the mobile phone handles the app display strategy (parallel view / landscape, etc.), calls virtualization hardware capabilities, and calls DDMS to create a virtual display; the collaborative configuration management service on the mobile phone calls the AMS interface to launch the app and displays it on the virtual display; the mobile phone starts the screen casting service, preparing to cast the virtual display to the large screen; the large screen receives the screen casting data and displays it in the HiWindow app.

[0235] Among them, HiWindow is responsible for displaying applications on the mobile phone; Launcher is used for super desktop component notifications and UI display; Collaborative Configuration Management is used to manage cross-device application migration and hardware migration strategies; Parallel View is used to support applications opening in parallel view mode and support multi-window display of applications. Distributed Hardware Platform is used to provide hardware virtualization, cast+screen projection capabilities, etc.; Distributed Window Management (DWMS) is used to provide application screen projection interface capabilities, window display adaptation logic, and architecture refactoring.

[0236] Figure 12 A schematic diagram of the structure of electronic device 1200 is shown. Electronic device 1200 may include processor 1210, memory 1220 and communication module 1230. Electronic device 1200 may be a first device, a second device or a third device, and may also be a cloud server.

[0237] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 1200. In other embodiments of this application, the electronic device 1200 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware. For example, when the electronic device 1200 is a terminal device, the electronic device 1200 may also include a camera, an audio module, a display screen, and a sensor module, etc.

[0238] Processor 1210 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (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). These different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0239] The communication module 1230 of the electronic device 1200 can be either a wireless communication module or a mobile communication module.

[0240] The mobile communication module can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G in electronic devices 1200. The mobile communication module may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module can receive electromagnetic waves via an antenna, filter and amplify the received electromagnetic waves, and transmit them to a modem processor for demodulation. The mobile communication module can also amplify the signal modulated by the modem processor and radiate it as electromagnetic waves via the antenna.

[0241] The wireless communication module can provide solutions for wireless communication applications on electronic device 1200, 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), and infrared (IR) technologies. The wireless communication module can be one or more devices integrating at least one communication processing module. The wireless communication module receives electromagnetic waves via an antenna, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 1210. The wireless communication module can also receive signals to be transmitted from processor 1210, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via the antenna.

[0242] In some embodiments, the antenna of the electronic device 1200 is coupled to the mobile communication module, and the antenna is coupled to the wireless communication module, enabling the electronic device 1200 to communicate with networks and other devices via 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, etc. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS).

[0243] The memory 1220 can be used to store computer executable program code, which includes instructions. The memory 1220 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the electronic device 1200 (such as audio data, phonebook, etc.). Furthermore, the memory 1220 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. The processor 1210 executes various functional applications and data processing of the electronic device 1200 by running instructions stored in the memory 1220 and / or instructions stored in memory disposed in the processor.

[0244] For example, when electronic device 120 is the first device, when processor 1210 executes the instructions stored in memory 1220, it implements the relevant processes executed by the first terminal device in the above-mentioned arbitrary device sharing process, such as sending a target message to the cloud server in response to the first operation.

[0245] For example, when electronic device 1200 is a second or third device, when processor 1210 executes the instructions stored in memory 1220, it implements the relevant processes executed by the second or third terminal device in the above-mentioned any-device sharing process.

[0246] For example, when electronic device 1200 is a cloud server, when processor 1210 executes the instructions stored in memory 1220, it implements the relevant processes executed by the cloud server in the above-mentioned arbitrary device sharing process. For example, based on the device information, it generates the correspondence between device security credentials and device identifiers and sends them to the corresponding terminal devices.

[0247] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0248] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to an electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0249] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0250] In the embodiments provided in this application, it should be understood that the disclosed devices, electronic devices, and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0251] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0252] The electronic device provided in this application embodiment may include a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method as described in any of the above method embodiments.

[0253] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0254] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0255] This application also provides a chip system, which includes a processor coupled to a memory. The processor executes a computer program stored in the memory to implement the methods described in the above embodiments. The chip system may be a single chip or a chip module composed of multiple chips.

[0256] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not detailed or described in a particular embodiment can be referred to in the relevant descriptions of other embodiments. It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. Furthermore, in the description of this application specification and the appended claims, the terms "first," "second," "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance. References to "one embodiment" or "some embodiments" in this application specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in yet other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0257] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A device sharing method, characterized by, The method applied to a first device comprises: in response to a first operation, displaying a group member adding interface, the first operation being an operation on a group member invitation control for inviting to join a group, members of the group being able to use a second device, the second device being a device within the group; wherein the first device and the second device log in a first account, an account of a group owner being the first account; in response to a second operation, sending a target message to a cloud server; wherein the second operation is an operation on a member invitation option or at least one user information displayed on the group member adding interface, the second operation being used to determine a user invited to join the group, an account of the user invited to join the group being a second account, the first account and the second account being different; the target message comprising first information used to indicate the first account and second information used to indicate the second account.

2. The method of claim 1, wherein, The first information comprises an identifier of the group owner or information of the first account, and the second information comprises a member identifier of the invited user within the group or information of the second account.

3. A device sharing method characterized by, The method applied to a first device logging in a first account comprises: in response to a first operation, determining a second device as a shared device from a plurality of devices logging in the first account; in response to a second operation, sending a target message; wherein the second operation is used to determine a user sharing the second device, an account of the user sharing the second device being a second account, the target message comprising first information used to indicate the first account and second information used to indicate the second account, the first account and the second account being different.

4. The method of claim 3, wherein, The first information comprises information of the second device or information of the first account, and the second information comprises information of the second account.

5. The method according to claim 3 or 4, characterized in that, The third device logs in the second account, and after sending the target message to the cloud server, the method further comprises: in response to a third operation, sending a cancel sharing instruction to the cloud server, the third operation being used to cancel sharing the second device to the second account, the cancel sharing instruction being used to trigger the cloud server to delete an authorization relationship between the second account and the second device, and send a first deletion instruction to the second device and a second deletion instruction to the third device.

6. The method according to any one of claims 3 to 5, characterized in that, The third device logs in the second account. The method further comprises: receiving first trusted authorization information from the cloud server; the first trusted authorization information comprising association information between a device identifier of the third device and a first device security credential; obtaining wireless broadcast information of the third device, the wireless broadcast information of the third device comprising the device identifier of the third device; if the device identifier of the third device corresponds to the first device security credential in the first trusted authorization information, determining the third device as a trusted device; establishing a communication connection with the third device.

7. The method according to any one of claims 3-6, characterized in that, The first device and the second device are the same device.

8. A device sharing method applied to a second device, the method comprising: receiving first trusted authorization information, the first trusted authorization information comprising association information between a device identifier of a third device and a first device security credential, the second device logging in a first account, the third device logging in a second account, the first account and the second account being different; storing the first trusted authorization information, the first trusted authorization information being used for authenticating the third device in a process of establishing a connection between the second device and the third device.

9. The method of claim 8, wherein, The method further comprises: obtaining wireless broadcast information of the third device, the wireless broadcast information of the third device comprising the device identifier of the third device; if the device identifier of the third device corresponds to the first device security credential in the first trusted authorization information, determining that the third device is a trusted device; automatically sending a connection request to the trusted third device; or if there are at least two trusted third devices, displaying a connectable device list, the connectable device list comprising the at least two trusted third devices, and in response to a selection operation of a user on the connectable device list, sending a connection request to a trusted third device designated by the selection operation.

10. The method according to claim 8 or 9, characterized in that, The method further comprises: after the connection with the third device is established, performing cross-device service with the third device.

11. The method according to any one of claims 8-10, characterized in that, The method further comprises: receiving a first deletion instruction; in response to the first deletion instruction, deleting the locally stored first trusted authorization information.

12. An apparatus comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, The processor executes the computer program to implement the method of any one of claims 1-2 or 3-7 or 8-11.

13. A computer-readable storage medium, the computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1-2 or 3-7 or 8-11.