A function migration method and apparatus

Abstract

Embodiments of the present application provide a function migration method and device, relate to the terminal field, and can guarantee the safe and reliable data sharing. The method is as follows: a first device creates a first group, members of the first group include a first application of the first device; a first request is received from a second device, the first request is used for applying to add a second application of the second device to the first group; the second application of the second device is added to the first group; a first function in the first application is migrated to the second application of the second device, and the second function includes one or more graphical user interfaces.

Description

Technical Field

[0001] This application relates to the field of terminals, and more particularly to a method and apparatus for function transfer. Background Technology

[0002] With the widespread adoption and development of digital devices such as smartphones, tablets, and personal computers (PCs), the number of personal terminals has surged, creating a demand for sharing business data between different devices. Therefore, how to share business data while ensuring its security and reliability has become an urgent problem to be solved. Summary of the Invention

[0003] This application provides a function migration method and apparatus that can ensure the security and reliability of data sharing.

[0004] In a first aspect, embodiments of this application provide a function migration method applied to a first device. The method includes: sending a first request to a second device, the first request carrying an identifier of the first device, an identifier of a first application, and an identifier of a second application; receiving a first response from the second device, the first response indicating a first group created by the second device, the members of the first group including a second application of the second device; sending a second request to the second device, the second request requesting that the first application of the first device be added to the first group; and migrating a first function in the first application to the second application of the second device, the first function including one or more graphical user interfaces (UIs).

[0005] Based on the method provided in this application embodiment, after negotiation between the first device and the second device, a first application of the first device and a second application of the second device can join a first group. That is, the members of the first group may include the first application of the first device and the second application of the second device. Since the first group is established after negotiation between the first device and the second device, the migration of functional data among the members of the first group, such as migrating one or more UIs of the first function, can ensure the security and reliability of data sharing.

[0006] In one possible implementation, the first response includes a personal identification number (PIN) corresponding to the first group and / or the communication connection information of the second device; sending a second request to the second device includes sending the second request to the second device based on the PIN and / or the communication connection information of the second device. Thus, when the first device needs to join a group created by the second device, it can include the PIN corresponding to the group in the request, so that the second device can verify the security of the first device based on the PIN, thereby ensuring the secure and reliable sharing of data.

[0007] In one possible implementation, the method further includes receiving a second response, wherein the second response indicates that the first application on the first device has joined the first group. This allows the first device to know that the first application has joined the first group, enabling subsequent direct feature migration.

[0008] In one possible implementation, the method further includes creating a second group, wherein the members of the second group include the first application of the first device and the second application of the second device. That is, the first device can create a group locally (i.e., the second group), which is the same as the group created by the second device. Thus, when the second application of the second device migrates functionality to the first application of the first device, if the first device determines that the second group is stored locally, it can consider the second application of the second device to be secure and trustworthy, and the functionality migration can proceed directly.

[0009] In one possible implementation, the method further includes: displaying a first pop-up window in response to a first operation by a user in a first application on a first device, the first pop-up window including an identifier of a device in the same network as the first device; and sending a first request to a second device, including: sending the first request to the second device in response to a second operation by the user selecting the second device in the first pop-up window. In this way, the first pop-up window allows the user to select the device for which function migration is required.

[0010] In one possible implementation, devices on the same network as the first device include trusted devices and untrusted devices. Trusted devices include devices logged into the same account as the first device, devices that have performed device-level authentication with the first device, or devices that have performed application-level authentication with the first device's first application. Untrusted devices include devices not logged into the same account as the first device, devices that have not performed device-level authentication with the first device, or devices that have not performed application-level authentication with the first device's first application. This allows the user to be notified of trusted and untrusted devices, facilitating user management of the corresponding devices.

[0011] In one possible implementation, the method further includes: scanning a QR code image displayed on a second device, the QR code image including a personal identification code PIN corresponding to the first group and / or communication connection information of the second device; and sending a second request to the second device, including: sending a second request to the second device based on the PIN and / or the communication connection information of the second device. Here, a QR code image is used as an identifier for illustrative purposes; the QR code image can be replaced with other types of identifiers, such as barcodes, strings, etc., and this application does not impose any limitations.

[0012] In one possible implementation, migrating the first function from the first application to the second device includes: sending business information of the first function to the second device; when the first application is a live streaming application, the business information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live streaming room of the first device; or when the first application is a camera application, the business information of the first function includes the menu bar information of the shooting preview screen or the shooting interface; or when the first application is a karaoke application, the business information of the first function includes at least one of the song title, lyrics, audio information of the song, video information of the song, and control interface of the song; or when the first application is a shopping application, the business information of the first function includes the product information in the shopping cart; or when the first application is an email application, the business information of the first function includes at least one of the subject, body, and attachment of the email.

[0013] In this way, in different scenarios, some functions of different applications (such as live streaming applications, photo applications, karaoke applications, email applications, or shopping applications) on the first device can be migrated to the second device, which can meet the needs of cross-device migration.

[0014] In one possible implementation, the communication connection information of the second device includes the Wi-Fi address or Bluetooth address of the second device.

[0015] In one possible implementation, the method further includes: sending a third request to a third device, the third request carrying the identifier of the first device, the package name of the first application, and the package name of the third application; the third request being used to request the migration of a first function of the first application to the third application of the third device; receiving a second response, the second response including information agreeing to the migration and a group name of a second group created by the third device, the members of the second group including the first application of the first device and the third application of the third device; sending a fourth request to the third device, the fourth request being used to apply to join the second group, the fourth request including the group name of the second group; and migrating the first function in the first application to the third device.

[0016] In one possible implementation, the method further includes updating the locally stored members of the first group, wherein the updated members of the first group include the first application of the first device, the second application of the second device, and the third application of the third device.

[0017] In one possible implementation, the package name of the second application is the same as the package name of the first application.

[0018] In one possible implementation, the trusted device includes a third device, and in response to a user's action of deleting the third device from the trusted device, a group associated with the third device is deleted.

[0019] In one possible implementation, the first group is set to be permanently valid or valid for a preset time.

[0020] In one possible implementation, when the first application is a karaoke application, the method further includes: rearranging the song selection control UI; and in response to the user performing song selection or song switching operations on the song selection control UI, sending song selection or song switching information to the second device.

[0021] In one possible implementation, when the first application is a shopping application, the business information of the first function includes product information in the shopping cart, and the product information includes at least one of product name, product link and product price information.

[0022] In one possible implementation, when the first application is an email application, the business information of the first function includes at least one of the email subject, body, or attachments.

[0023] Secondly, embodiments of this application provide a function migration method applied to a second device. The method includes: receiving a first request from a first device, the first request carrying an identifier of the first device, an identifier of a first application, and an identifier of a second application; creating a first group, the members of the first group including a second application of the second device; sending a first response to the first device, the first response indicating the first group; receiving a second request from the first device, the second request requesting that the first application of the first device be added to the first group; and receiving a first function from the first application being migrated by the first device, wherein the first function includes one or more graphical user interfaces (UIs).

[0024] Based on the method provided in this application embodiment, after negotiation between the first device and the second device, a first application of the first device and a second application of the second device can join a first group. That is, the members of the first group may include the first application of the first device and the second application of the second device. Since the first group is established after negotiation between the first device and the second device, the migration of functional data among the members of the first group, such as migrating one or more UIs of the first function, can ensure the security and reliability of data sharing.

[0025] In one possible implementation, the first response includes a personal identification number (PIN) corresponding to the first group and / or communication connection information of the second device. This allows the second device to verify the security of the first device based on the PIN, thereby ensuring secure and reliable data sharing.

[0026] In one possible implementation, the method further includes sending a second response to the first device, wherein the second response indicates that the first application on the first device has joined the second group. This allows the first device to know that the first application has joined the first group, enabling subsequent direct feature migration.

[0027] In one possible implementation, after receiving the first request from the first device, the method further includes: displaying a first pop-up window, the first pop-up window prompting the user whether to agree to add the first application of the first device to the first group; and receiving an agreement instruction from the user. Thus, the first pop-up window can prompt the user to add the first application of the first device to the first group.

[0028] In one possible implementation, before creating the first group, the method further includes: determining, based on the identifier of the first device, that the second device does not currently have a second group, wherein the members of the second group include both the first device and the second device. That is, if it is determined that no group has been established between the first device and the second device, meaning that the first device and the second device have not previously established a trusted connection, the first group can be created.

[0029] In one possible implementation, before creating the first group, the method further includes: determining, based on the identifier of the first device, the identifier of the first application, and the identifier of the second application, that the second device currently does not have a third group, wherein the members of the third group include the first application of the first device and the second application of the second device. That is, if it is determined that no group has been established between the first application of the first device and the second application of the second device, meaning that the first application of the first device and the second application of the second device have not yet established a trusted connection, the first group can be created.

[0030] In one possible implementation, the method further includes: displaying a QR code image, the QR code image including a personal identification code PIN corresponding to the first group and / or communication connection information of the second device. Here, a QR code image is used as an identifier for illustrative purposes; the QR code image can be replaced with other types of identifiers, such as barcodes, strings, etc., and this application does not impose any limitations on this.

[0031] In one possible implementation, the first function of the first application receiving the migration from the first device includes: receiving business information from the first function of the first device; when the first application is a live streaming application, the business information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live streaming room of the first device; or when the first application is a camera application, the business information of the first function includes the menu bar information of the shooting preview screen or the shooting interface; or when the first application is a karaoke application, the business information of the first function includes at least one of the song title, lyrics, audio information of the song, video information of the song, and control interface of the song; or when the first application is a shopping application, the business information of the first function includes the product information in the shopping cart; or when the first application is an email application, the business information of the first function includes at least one of the subject, body, and attachment of the email.

[0032] In this way, in different scenarios, some functions of different applications (such as live streaming applications, photo applications, karaoke applications, email applications, or shopping applications) on the first device can be migrated to the second device, which can meet the needs of cross-device migration.

[0033] In one possible implementation, the communication connection information of the second device includes the Wi-Fi address or Bluetooth address of the second device.

[0034] In one possible implementation, the package name of the second application is the same as that of the first application.

[0035] In one possible implementation, the first group is set to be permanently valid or valid for a preset time.

[0036] In one possible implementation, after receiving the first request from the first device, the method further includes: displaying a second pop-up window, which prompts the user whether they agree to the first device migrating the first function to the second device.

[0037] In one possible implementation, if the second device has a live streaming application installed, the second device detects whether the live streaming application is logged in; if the live streaming application is logged in, the live streaming application displays the first function on the live streaming screen of the second device.

[0038] In one possible implementation, if the second device does not have a live streaming application installed, the second device displays the first function as an audio player.

[0039] In one possible implementation, when the first application is a camera application, the business information of the first function includes the shooting preview screen and the menu bar information of the shooting interface.

[0040] In one possible implementation, the second device displays the shooting preview screen and the menu bar of the shooting interface of the first device; in response to the user triggering the first device to shoot on the second device, the second device sends a shooting command to the first device, and the first device takes a photo or video.

[0041] In one possible implementation, when the first application is a karaoke application, if the second device has a karaoke application installed, it checks whether the karaoke application is logged in; if the karaoke application is logged in, the karaoke application displays the first function.

[0042] In one possible implementation, when the first application is a karaoke application, if the second device does not have a karaoke application installed, the first function is displayed in the form of an audio player.

[0043] In one possible implementation, when the first application is a shopping application, if the second device has the shopping application installed, it checks whether the shopping application is logged in; if the shopping application is logged in, the shopping application displays a shared shopping cart according to the business information of the first function. The shared shopping cart includes all the items in the shopping cart of the second device and all the items in the shopping cart of the first device.

[0044] In one possible implementation, in response to a user's checkout of all items in a shared shopping cart, the second device sends a payment request to the first device, the payment request including the total amount of all items in the first device's shopping cart.

[0045] In one possible implementation, when the first application is an email application, if the second device has an email application installed, it checks whether the email application is logged in; if the email application is logged in, the email application displays the first function.

[0046] In one possible implementation, when the first application is an email application, if the second device does not have an email application installed, the first function is encoded and rearranged in the form of a graphic editor.

[0047] Thirdly, embodiments of this application provide a function migration method applied to a communication system including a first device and a second device. The method includes: the first device sending a first request to the second device, the first request carrying the identifier of the first device; the second device receiving the first request from the first device; the second device sending a first response from the first device, the first response indicating a first group created by the second device, the members of the first group including the second device; the first device receiving the first response from the second device; the first device sending a second request to the second device, the second request requesting to add the first device to the first group; and the first device migrating a first function from a first application to the second device, the first application being any application in the first device, the first function including one or more graphical user interfaces (UIs).

[0048] In one possible implementation, the first response includes a personal identification number (PIN) corresponding to the first group and / or communication connection information of the second device, and sending a second request to the second device includes: sending a second request to the second device based on the PIN and / or the communication connection information of the second device; the method further includes: receiving a second response from the second device, the second response being used to indicate that the first device has joined the first group.

[0049] In one possible implementation, in response to a user's first action, a first device displays a first pop-up, which includes identifiers of one or more devices that have not been authenticated with the first device; the first device sends a first request to a second device, including: in response to a user's second action of selecting a second device in the first pop-up, sending the first request to the second device.

[0050] In one possible implementation, the method further includes: the first device creating a second group, the members of which include both the first device and the second device.

[0051] In one possible implementation, the method further includes: in response to a user's first operation on a first application on a first device, the first device displays a first pop-up, the first pop-up including an identifier of a device in the same network as the first device; the first device sends a first request to a second device, including: in response to a user's second operation of selecting the second device in the first pop-up, the first device sends the first request to the second device.

[0052] In one possible implementation, devices in the same network as the first device include trusted devices and untrusted devices; wherein, trusted devices include devices that are logged into the same account as the first device, devices that have performed device-level authentication with the first device, or devices that have performed application-level authentication with the first device's first application; untrusted devices include devices that are not logged into the same account as the first device, devices that have not performed device-level authentication with the first device, or devices that have not performed application-level authentication with the first device's first application.

[0053] In one possible implementation, the method further includes: a second device displaying a QR code image, the QR code image including a personal identification code PIN corresponding to the first group and / or communication connection information of the second device; a first device scanning the QR code image displayed by the second device; and the first device sending a second request to the second device, including: the first device sending a second request to the second device based on the PIN and / or the communication connection information of the second device.

[0054] In one possible implementation, the first device migrating a first function from a first application to a second device includes: sending business information of the first function to the second device; when the first application is a live streaming application, the business information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live streaming room of the first device; or when the first application is a photo-taking application, the business information of the first function includes the preview screen of the photo-taking screen or the menu bar information of the photo-taking interface; or when the first application is a karaoke application, the business information of the first function includes at least one of the song title, lyrics, audio information of the song, video information of the song, and control interface of the song; or when the first application is a shopping application, the business information of the first function includes the product information in the shopping cart; or when the first application is an email application, the business information of the first function includes at least one of the subject, body, and attachments of the email.

[0055] Fourthly, embodiments of this application provide a function migration method applied to a first device, comprising: creating a first group, the members of the first group including a first application of the first device; receiving a first request from a second device, the first request being used to request that a second application of the second device be added to the first group; adding the second application of the second device to the first group; and migrating a first function of the first application to the second application of the second device, the second function including one or more graphical user interfaces (UIs).

[0056] In one possible implementation, before receiving the first request from the second device, the method further includes: displaying a first identifier for indicating a first group, wherein the first request corresponds to the first identifier.

[0057] In one possible implementation, the first identifier includes a QR code image, and the first identifier includes a personal identification number (PIN); after receiving the first request from the second device, the method further includes: determining that the first request carries a PIN; and determining to add the second application of the second device to the first group.

[0058] In one possible implementation, migrating the first function in the first application to the second application on the second device includes: sending business information of the first function to the second device; when the first application is a live streaming application, the business information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live streaming room on the first device; or when the first application is a camera application, the business information of the first function includes the camera preview screen or the menu bar information of the camera interface; or when the first application is a karaoke application, the business information of the first function includes at least one of the song title, lyrics, audio information of the song, video information of the song, and the control interface of the song; or when the first application is a shopping application, the business information of the first function includes the product information in the shopping cart; or when the first application is an email application, the business information of the first function includes at least one of the email subject, body, and attachments.

[0059] Fifthly, embodiments of this application provide a function migration method applied to a second device, comprising: sending a first request to a first device, the first request being used to request that a second application of the second device be added to a first group created by the first device, the members of the first group including a first application of the first device and a second application of the second device; receiving a first function from the first application, wherein the first function includes one or more graphical user interfaces (UIs).

[0060] In one possible implementation, before sending the first request to the first device, the method further includes scanning a first identifier for indicating a first group, wherein the first request corresponds to the first identifier.

[0061] In one possible implementation, the first identifier includes a QR code image, and the first identifier includes a personal identification number (PIN); sending a first request to the first device includes sending a first request to the first device, the first request carrying the PIN.

[0062] In one possible implementation, receiving a first function from a first device within a first application includes: receiving business information of the first function from the first device; when the first application is a live streaming application, the business information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live streaming room of the first device; or when the first application is a camera application, the business information of the first function includes the menu bar information of the camera preview screen or the camera interface; or when the first application is a karaoke application, the business information of the first function includes at least one of the song title, lyrics, audio information of the song, video information of the song, and the song control interface; or when the first application is a shopping application, the business information of the first function includes product information in the shopping cart; or when the first application is an email application, the business information of the first function includes at least one of the email subject, body, and attachments.

[0063] Sixthly, this application provides a first device including one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, the computer program code including computer instructions, which, when executed by the one or more processors, cause the first device to perform the method in any possible implementation of any of the first, third, or fourth aspects described above.

[0064] In a seventh aspect, this application provides a second device including one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, including computer instructions, which, when executed by the one or more processors, cause the second device to perform a method in any possible implementation of any of the second, third, or fifth aspects described above.

[0065] Eighthly, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to execute the method in any possible implementation of any of the above aspects.

[0066] Ninthly, this application provides a chip system that can be disposed in a first device. The chip system includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The chip system can be applied to an electronic device including a communication module and a memory. The interface circuits are used for the memory to receive signals and to send the received signals to the processor, the signals including computer instructions stored in the memory. When the processor executes the computer instructions, the first device can perform the methods described in any of the above aspects and any possible implementations thereof.

[0067] In a tenth aspect, embodiments of this application provide a computer storage medium including computer instructions that, when executed on a first device, cause the first device to perform a method in any of the possible implementations of any of the above aspects.

[0068] Eleventhly, embodiments of this application provide a function migration system, including at least two devices (e.g., a first device and a second device), each device being capable of performing the methods described in any of the above aspects and any possible implementation thereof. Attached Figure Description

[0069] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application;

[0070] Figure 2 This application provides another system architecture schematic diagram;

[0071] Figure 3 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0072] Figure 4 A schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0073] Figure 5A A schematic diagram provided for an embodiment of this application;

[0074] Figure 5B This is yet another display schematic diagram provided for an embodiment of this application;

[0075] Figure 5C This is yet another display schematic diagram provided for an embodiment of this application;

[0076] Figure 5D This is yet another display schematic diagram provided for an embodiment of this application;

[0077] Figure 5E This is yet another display schematic diagram provided for an embodiment of this application;

[0078] Figure 5F This is yet another display schematic diagram provided for an embodiment of this application;

[0079] Figure 6A This is yet another display schematic diagram provided for an embodiment of this application;

[0080] Figure 6B This is yet another display schematic diagram provided for an embodiment of this application;

[0081] Figure 6C This is yet another display schematic diagram provided for an embodiment of this application;

[0082] Figure 7A A schematic diagram of signal interaction provided in an embodiment of this application;

[0083] Figure 7B This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0084] Figure 7C This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0085] Figure 8A This is yet another display schematic diagram provided for an embodiment of this application;

[0086] Figure 8B This is yet another display schematic diagram provided for an embodiment of this application;

[0087] Figure 8C This is yet another display schematic diagram provided for an embodiment of this application;

[0088] Figure 8D This is yet another display schematic diagram provided for an embodiment of this application;

[0089] Figure 8E This is yet another display schematic diagram provided for an embodiment of this application;

[0090] Figure 9A This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0091] Figure 9B This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0092] Figure 9C This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0093] Figure 10A This is yet another display schematic diagram provided for an embodiment of this application;

[0094] Figure 10B This is yet another display schematic diagram provided for an embodiment of this application;

[0095] Figure 11 This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0096] Figure 12A This is yet another display schematic diagram provided for an embodiment of this application;

[0097] Figure 12B This is yet another display schematic diagram provided for an embodiment of this application;

[0098] Figure 12C This is yet another display schematic diagram provided for an embodiment of this application;

[0099] Figure 12D This is yet another display schematic diagram provided for an embodiment of this application;

[0100] Figure 12E This is yet another display schematic diagram provided for an embodiment of this application;

[0101] Figure 12F This is yet another display schematic diagram provided for an embodiment of this application;

[0102] Figure 13 This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0103] Figure 14A This is yet another display schematic diagram provided for an embodiment of this application;

[0104] Figure 14B This is yet another display schematic diagram provided for an embodiment of this application;

[0105] Figure 14C This is yet another display schematic diagram provided for an embodiment of this application;

[0106] Figure 14D This is yet another display schematic diagram provided for an embodiment of this application;

[0107] Figure 14E This is yet another display schematic diagram provided for an embodiment of this application;

[0108] Figure 14F This is yet another display schematic diagram provided for an embodiment of this application;

[0109] Figure 15 This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0110] Figure 16A This is yet another display schematic diagram provided for an embodiment of this application;

[0111] Figure 16B This is yet another display schematic diagram provided for an embodiment of this application;

[0112] Figure 16C This is yet another display schematic diagram provided for an embodiment of this application;

[0113] Figure 16D This is yet another display schematic diagram provided for an embodiment of this application;

[0114] Figure 16E This is yet another display schematic diagram provided for an embodiment of this application;

[0115] Figure 17A This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0116] Figure 17B This is yet another display schematic diagram provided for an embodiment of this application;

[0117] Figure 17C This is yet another display schematic diagram provided for an embodiment of this application;

[0118] Figure 17D This is yet another display schematic diagram provided for an embodiment of this application;

[0119] Figure 18A This is yet another display schematic diagram provided for an embodiment of this application;

[0120] Figure 18B This is yet another display schematic diagram provided for an embodiment of this application;

[0121] Figure 18C This is yet another display schematic diagram provided for an embodiment of this application;

[0122] Figure 18D This is yet another display schematic diagram provided for an embodiment of this application;

[0123] Figure 19 This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0124] Figure 20 This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0125] Figure 21 This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0126] Figure 22 This is yet another schematic diagram of signal interaction provided in an embodiment of this application;

[0127] Figure 23 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0128] The system architecture involved in this application embodiment may include multiple electronic devices, which can be networked together to exchange information. The networking methods include, but are not limited to, the following:

[0129] (1) Wireless Fidelity (Wi-Fi) networking: Multiple electronic devices can connect to the same routing device (e.g., a router). Figure 1 As shown, mobile phone 101, mobile phone 102, tablet computer 103, laptop computer 104, and smart TV 105 can connect to router 106 to form a home network. Alternatively, multiple electronic devices can join the same hotspot (e.g., connect to the same mobile phone's hotspot). In this case, information exchange between electronic devices can be forwarded through the hotspot. For example, mobile phone 102, tablet computer 103, laptop computer 104, and smart TV 105 can connect to mobile phone 101 to form a hotspot network, and mobile phone 101 can act as a hotspot to forward information for each electronic device.

[0130] (2) Bluetooth networking mode: Multiple electronic devices can connect to the same Bluetooth device (e.g., mobile phone 104). In this case, information exchange between electronic devices can be forwarded through the Bluetooth device. Figure 2 As shown, mobile phone 101, tablet computer 103, laptop computer 104, and smart TV 105 can connect to mobile phone 102 to form a Bluetooth network. Mobile phone 104 can act as a Bluetooth device to forward information for each electronic device.

[0131] Multiple electronic devices can adopt various networking methods, such as simultaneously using wireless fidelity networking and Bluetooth networking, and this application does not limit them.

[0132] like Figure 3As shown, this application embodiment uses an electronic device 200 (such as a mobile phone) as an example to illustrate the structure of the electronic device provided in this application embodiment. The electronic device 200 (such as a mobile phone) may include: a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, a sensor module 280, buttons 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a subscriber identification module (SIM) card interface 295, etc.

[0133] The aforementioned sensor module 280 may include sensors such as pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, and bone conduction sensors.

[0134] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 200. In other embodiments, the electronic device 200 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.

[0135] Processor 210 may include one or more processing units, such as application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0136] The controller can be the nerve center and command center of the electronic device 200. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0137] The processor 210 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. This memory can store instructions or data that the processor 210 has just used or that are used repeatedly. If the processor 210 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 210, and thus improves the efficiency of the system.

[0138] In some embodiments, the processor 210 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0139] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a structural limitation on the electronic device 200. In other embodiments, the electronic device 200 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0140] The charging management module 240 receives charging input from a charger, which can be either a wireless or wired charger. While charging the battery 242, the charging management module 240 can also supply power to the electronic device via the power management module 241.

[0141] The power management module 241 connects the battery 242, the charging management module 240, and the processor 210. The power management module 241 receives input from the battery 242 and / or the charging management module 240, and supplies power to the processor 210, internal memory 221, external memory, display 294, camera 293, and wireless communication module 260, etc. In some embodiments, the power management module 241 and the charging management module 240 may also be housed in the same device.

[0142] The wireless communication function of electronic device 200 can be implemented through antenna 1, antenna 2, mobile communication module 250, wireless communication module 260, modem processor, and baseband processor. In some embodiments, antenna 1 of electronic device 200 is coupled to mobile communication module 250, and antenna 2 is coupled to wireless communication module 260, enabling electronic device 200 to communicate with networks and other devices through wireless communication technology.

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

[0144] The mobile communication module 250 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 200. The mobile communication module 250 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 250 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation.

[0145] The mobile communication module 250 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via the antenna 1. In some embodiments, at least some functional modules of the mobile communication module 250 can be housed in the processor 210. In some embodiments, at least some functional modules of the mobile communication module 250 and at least some modules of the processor 210 can be housed in the same device.

[0146] The wireless communication module 260 can provide solutions for wireless communication applications on electronic devices 200, including WLAN (such as wireless fidelity, Wi-Fi) networks, Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, etc.

[0147] The wireless communication module 260 can be one or more devices integrating at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 210. The wireless communication module 260 can also receive signals to be transmitted from processor 210, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0148] Electronic device 200 implements display functions through a GPU, a display screen 294, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 294 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 210 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0149] The display screen 294 is used to display images, videos, etc. The display screen 294 includes a display panel.

[0150] The electronic device 200 can implement its shooting function through an ISP, a camera 293, a video codec, a GPU, a display 294, and an application processor. The ISP is used to process the data fed back by the camera 293. The camera 293 is used to capture still images or videos. In some embodiments, the electronic device 200 may include one or N cameras 293, where N is a positive integer greater than 1.

[0151] The external storage interface 220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 200. The external memory card communicates with the processor 210 through the external storage interface 220 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0152] Internal memory 221 can be used to store computer executable program code, which includes instructions. Processor 210 executes various functional applications and data processing of electronic device 200 by running the instructions stored in internal memory 221. For example, in this embodiment, processor 210 can execute instructions stored in internal memory 221, which may include a program storage area and a data storage area.

[0153] The program storage area can store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.). The data storage area can store data created during the use of the electronic device 200 (such as audio data, phonebook, etc.). Furthermore, the internal memory 221 can 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.

[0154] Electronic device 200 can implement audio functions such as music playback and recording through audio module 270, speaker 270A, receiver 270B, microphone 270C, headphone jack 270D, and application processor.

[0155] Buttons 290 include a power button, volume buttons, etc. Buttons 290 can be mechanical buttons or touch-sensitive buttons. Motor 291 can generate vibration alerts. Motor 291 can be used for incoming call vibration alerts or for touch vibration feedback. Indicator 292 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 295 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 295 to achieve contact and separation with the electronic device 200. The electronic device 200 can support one or N SIM card interfaces, where N is a positive integer greater than 1. SIM card interface 295 can support Nano SIM cards, Micro SIM cards, SIM cards, etc.

[0156] like Figure 4 The software architecture of the electronic device provided in this application embodiment is illustrated below. The software architecture of the electronic device may include an application layer, an application framework layer, a hardware abstraction layer (HAL), and a driver layer. This application embodiment uses a dual-framework operating system (i.e., Android and HarmonyOS) as an example for illustration. The electronic device may also use Android, HarmonyOS, iOS, or other operating systems; this application embodiment does not impose any limitations.

[0157] The application layer can include Android applications and HarmonyOS applications. Android applications can include a device manager kit (DM kit) and a distributed execution framework (DEF) kit. A kit (service) can be a software development kit (SDK) used to provide basic services to the application layer (applications). The DM kit can include modules for device discovery, trusted device maintenance, device authentication, device filtering, and sorting. HarmonyOS applications can include the DM kit and the HarmonyOS SDK. An SDK can refer to a collection of related documents, examples, and tools that assist in developing a specific type of software.

[0158] The DM kit may include a device discovery module, a trusted device maintenance module, a device authentication module, and a device filtering and sorting module. Optionally, the application layer may also include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS, etc., which are not limited in this application.

[0159] The application framework layer may include DM, DEF, distributed scheduler management service (DMS), QR code recognition module (hivision), HarmonyOS tag management module, security management module, communication module, and device information database (device profile). Of course, the framework layer 302 may also include an activity manager, window manager, content provider, resource manager, notification manager, etc., and this application embodiment does not impose any limitations on this.

[0160] The Device Management (DM) module primarily provides device discovery, trusted device maintenance, and device authentication capabilities. It establishes secure and trusted connections between devices under the same or different accounts, and between Android and HarmonyOS devices, by maintaining local device information, writing the information into QR codes, scanning and recognizing the codes, establishing physical connections, and maintaining device group information. Optionally, the DM module may include a device discovery module, a trusted device maintenance module, a device authentication module, and a device sorting and filtering module. The device discovery module handles tasks such as sending broadcasts, discovering devices, encapsulating device information, and creating a device list pop-up UI. The trusted device maintenance module handles tasks such as querying the trusted device list, writing trusted device information, maintaining the trusted device list, and monitoring trusted device online / offline status. The device authentication module handles underlying channel management, access control, PIN code mechanisms, and group management. The device sorting and filtering module handles device filtering and sorting.

[0161] HarmonyOS Tag Management Module: Responsible for providing HarmonyOS tag application, parsing, formatting, HarmonyOS tag service query, and service distribution capabilities.

[0162] Distributed Execution Framework (DEF): Responsible for providing atomic service discovery, registration, querying, and migration; responsible for underlying data communication and device discovery between devices.

[0163] QR code recognition module: Provides HarmonyOS label generation and scanning capabilities. It generates HarmonyOS QR code labels based on label information provided by the label service, and triggers the label service to parse the label information by scanning the HarmonyOS QR code label.

[0164] The security management module (HiChain) manages groups in distributed scenarios and device group authentication; groups include public groups and application-level private groups. It provides secure and reliable communication and connections between devices and applications in distributed scenarios.

[0165] Communication module: The soft bus manages the self-discovery and self-networking of devices with the same account in a distributed scenario; it scans and discovers devices with different accounts; and it provides a channel for communication between different devices, ensuring secure and stable data transmission.

[0166] DMS primarily handles cross-device service binding and cross-device Android Interface Definition Language (AIDL) API call capabilities. AIDL is a description language used to define communication interfaces between servers and clients.

[0167] Equipment Information Database: Responsible for reading, writing, storing, and managing equipment information.

[0168] HAL can include microphones, speakers, Wi-Fi modules, Bluetooth modules, cameras, sensors, etc.

[0169] The driver layer is the layer between hardware and software, also known as the kernel layer. The kernel layer includes at least display drivers, camera drivers, audio drivers, and sensor drivers.

[0170] The above software architecture can be deployed on multiple electronic devices within the current network environment (e.g., such as...). Figure 1 or Figure 2 (Including mobile phones 101, mobile phones 102, tablets 103, laptops 104, smart TVs 105, routers 106, etc.).

[0171] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. In the description of this application, unless otherwise stated, "at least one" refers to one or more, and "more than one" refers to two or more. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0172] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the relevant concepts or technologies is given first:

[0173] Ability: An ability is an abstraction of the capabilities an application possesses. An application can contain one or more abilities. HarmonyOS supports deploying applications on a per-ability basis. Abilities are divided into two types: FA (Feature Capabilities) and AA (Meta-Capabilities).

[0174] AA: A single-function program entity developed by a third party based on HarmonyOS system services, used to provide the ability to run background tasks, without a user interface. AA features multi-device deployment and distributed execution. AA has dependencies on system services, but there are no dependencies between AA instances.

[0175] FA (Application Provider): Used to provide the ability (function) to interact with users. An FA can contain a set of related pages (or a set of UIs), each page can be represented by an AbilitySlice instance. FAs can implement complex functions by calling AAs (Application Providers), are developed based on a new interface / data / logic separation structure, and can be packaged and released independently. FAs have the following capabilities: installation-free, independent operation, cross-device UI migration, and cross-device binary migration. FAs share some similarities with the UI of mini-programs or quick apps, but are fundamentally different. The differences include two points: first, FAs can be migrated across devices (for example, an FA on phone A can be migrated to phone B, allowing phone B to control the FA on phone A); second, FAs are cross-platform, for example, FAs can run on both Android and HarmonyOS, while current mini-programs or quick apps typically run on Android.

[0176] Currently, FA (Feature Analyzer) sharing technology can be used to share features between different devices, meaning that the FA from one device can be migrated to another for display and operation. Before sharing the FA, authentication is required to ensure the secure and reliable sharing process.

[0177] This application provides a function migration method, including device-level authentication and application-level authentication. After application-level authentication, specific applications on different devices can interoperate (i.e., applications can exchange business data, such as migrating FA). For example, after mutual authentication between the first application of device A and the first application of device B, the first application of device A and the first application of device B can interoperate, but other applications of device A (e.g., the second application) and other applications of device B (e.g., the second application) cannot interoperate. After device-level authentication, all applications on different devices can interoperate.

[0178] For ease of understanding, the following uses mobile phone A and mobile phone B as examples to introduce the user interface (UI) of device-level authentication provided in this application embodiment.

[0179] like Figure 5A As shown in (a), users can access the Smart Collaboration interface 501 from the Settings app. The Smart Collaboration interface 501 can include a list named "My Devices." "My Devices" includes the device itself (i.e., phone A), kiki's Mate pad, and kiki's Matebook Pro. The device, kiki's Mate pad, and kiki's Matebook Pro can be devices using the same account (e.g., sharing a single Huawei account). Alternatively, the device, kiki's Mate pad, and kiki's Matebook Pro can be devices using different accounts but that have been authenticated (the authentication process can be found in the relevant description below).

[0180] Optionally, the smart collaboration interface 501 may include a "Bind Other Devices" button 502. In this embodiment, binding refers to establishing a trusted relationship between two devices, enabling interoperability between any applications on the two devices, such as mutual migration of application signatures (FAs) without authentication. In response to a user's operation on the "Bind Other Devices" button 502 (e.g., a click), such as... Figure 5A As shown in (b), mobile phone A can display the "Tap to Add" button 503 and the "Scan to Add" button 504. It should be understood that... Figure 5A The positions, names, and shapes of the various elements (e.g., buttons, icons, text, etc.) in the UI interface represented by (a) and (b) are not fixed and can be freely combined or designed according to requirements. For example, they can be... Figure 5A Button 502 in (a) can be replaced with Figure 5A Buttons 503 and 504 in (b) of the diagram.

[0181] For example, in response to a user's click on the "Tap to Add" button 503, such as Figure 5BAs shown in (a), mobile phone A can display a tap-to-add interface 505, which can display a pop-up window 506. The pop-up window 506 includes a prompt image and a prompt message, such as: "Tap to add: After enabling NFC on your phone, tap the back of your phone against the ontag tag on the device." Users can follow the prompts to add new devices via tap-to-add. For example, in response to a user clicking the scan-to-add button 504, as shown... Figure 5B As shown in (b), mobile phone A can display a scan-to-add interface 507, which may include a prompt image and prompt information, such as: "Scan the QR code on the device or packaging." The user can follow the prompt information to add a new device by scanning.

[0182] If phone A does not support adding new devices via tap or scan, such as Figure 5C As shown in (a), in response to the user clicking the "Bind Other Devices" button 502, as... Figure 5C As shown in (b), mobile phone A can display pop-up 508, which includes the prompt message "Please ensure the device is turned on and near the phone." Pop-up 508 can also include devices detected by mobile phone A based on short-range communication networks (e.g., Wi-Fi or Bluetooth), such as a room TV, HUAWEI P20, and Matebook X Pro. Each device corresponds to a binding button. In response to the user's operation of the binding button 509 corresponding to HUAWEI P20, as shown... Figure 5D As shown in (a), the HUAWEI P20 logo can display a prompt message 510 "Waiting for confirmation from the other end...". A cancel button 511 can also be displayed in the pop-up window 508. In response to the user clicking the cancel button 511, phone A can return to the previous screen. Figure 5C The interface shown in (a) is shown in the image.

[0183] If the peer device confirms (for example, the user on the peer device agrees to the binding), such as Figure 5D As shown in (b), mobile phone A can display a new device binding interface 512, which may include the prompt message "Scan the QR code displayed on the other end." The user can then follow the prompt to add a new device. It should be understood that the embodiments of this application do not limit the jump relationships between different UI interfaces. For example, as... Figure 5C As shown in (b), in response to the user clicking the binding button 509, as Figure 5D As shown in (b) in the image, the mobile phone can directly display the scanning interface 512.

[0184] If the peer device does not confirm (e.g., the peer device does not have the binding function, the binding timed out, the peer device is busy, or the user of the peer device does not agree to the binding), such as Figure 5E As shown in (a), phone A can display a pop-up 521 prompting the user "Device authentication failed." In response to the user clicking the "Know" button 522, pop-up 521 can disappear. Alternatively, pop-up 521 can disappear after a preset time (e.g., 3 seconds). In another possible design, as... Figure 5E As shown in (b), mobile phone A can display a pop-up 523, prompting the user "The other end is busy, please initiate the binding later." In response to the user clicking the "Know" button 524, pop-up 523 can disappear. Alternatively, pop-up 523 can disappear after a preset time (e.g., 3 seconds). In yet another possible design, as... Figure 5E As shown in (c), mobile phone A can display pop-up 525, prompting the user "The other end refuses to trust this device, binding failed." In response to the user clicking the "Know" button 526, pop-up 525 can disappear. Alternatively, pop-up 525 can disappear after a preset time (e.g., 3 seconds). Or, as... Figure 5F As shown, mobile phone A can display a pop-up window 527 on interface 512, prompting the user that "the peer's QR code has been closed, device authentication cannot be completed, and binding has failed." In response to the user clicking the "Know" button 528, pop-up window 527 can be hidden.

[0185] Assuming the peer device is mobile phone B (e.g., a HUAWEI P20), if mobile phone B receives a binding request from mobile phone A when displaying desktop 530, such as Figure 6A As shown in (a), mobile phone B can display a pop-up window 531, which may include the prompt message 532 "HUAWEI MATE30 requests to bind to this device, do you trust this device?". Pop-up window 531 may also include a "Don't Trust" button 533 and a "Trust" button 534. The "Don't Trust" button may also display a countdown (e.g., 14 seconds). If the user does not click any button when the countdown ends, pop-up window 531 will automatically disappear. In response to the user clicking the "Trust" button 534, mobile phone A can perform an authentication process with mobile phone B (refer to the relevant descriptions of steps 718A-732 below), thereby allowing mobile phone A to bind to mobile phone B.

[0186] If phone B receives a binding request from phone A while its screen is off or locked, such as Figure 6AAs shown in (b), phone B can display a pop-up 536 on the lock screen 535. Pop-up 536 can prompt the user that the Smart Collaboration application received a device binding request at 7:30 AM. Specifically, it could be "HUAWEI MATE30 (i.e., phone A) requests to bind to this device. Do you trust this device?" This is in response to the user's action of entering the desktop from the lock screen (e.g., entering a password or fingerprint). Figure 6A As shown in (a), pop-up 536 can be changed to pop-up 531, where the user can choose to trust or not trust HUAWEI MATE30 (i.e., phone A).

[0187] If phone B receives a binding request from phone A while playing a video or game, such as Figure 6B As shown in (a), mobile phone B can display a pop-up 541 in the video interface or game interface 540. Pop-up 541 can prompt the user that the Smart Collaboration application has received a device binding request, specifically, "HUAWEI MATE30 requests to bind to this device. Do you trust this device?". In response to the user clicking the drop-down control 542, such as... Figure 6B As shown in (b), pop-up 541 can display more information, such as a distrust button 543 and a trust button 544. The distrust button 543 can also display a countdown (e.g., 14 seconds), and pop-up 541 can automatically disappear if the user does not click any button when the countdown ends. In response to the user clicking the trust button 544, mobile phone A can perform an authentication process with mobile phone B (see the descriptions of steps 718A-732 below).

[0188] In one possible design, in response to the user clicking the trust button, such as Figure 6C As shown, phone B can return to the home screen 530 and display a pop-up window 550. The pop-up window 550 may include a QR code 551 generated by phone B, and may also include a prompt message 552: "Scan to bind, allow HUAWEI MATE30 to scan and bind this device." At this time, the user of phone A can use phone A to scan the QR code displayed on phone B to bind phone A and phone B. The pop-up window 550 may also include a cancel button 553; in response to the user clicking the cancel button 553, the pop-up window 550 can disappear.

[0189] In some embodiments, if mobile phone A and mobile phone B are logged into the same account (e.g., a Huawei account), mobile phone A can be directly bound to mobile phone B (e.g., as shown in the image). Figure 5C In (b), on phone A, click the binding button corresponding to phone B (HUAWEI P20), without waiting for confirmation from phone B (e.g., without needing to...). Figure 5D Like (a) in the example, it awaits confirmation from the other end and does not require... Figure 5D(scan the QR code displayed on the other end, just like in (b)).

[0190] The following uses mobile phone A and mobile phone B as examples to illustrate the specific implementation of the device-level authentication method provided in this application. Mobile phone A and mobile phone B are devices with different account settings. Figure 7A As shown, it includes:

[0191] 701. The user triggers the operation of binding mobile phone B on mobile phone A.

[0192] For example, a user can click the binding button for phone B on phone A. For example, as... Figure 5C As shown in (b), in response to the user clicking the binding button 509 corresponding to mobile phone B (HUAWEI P20) on mobile phone A, mobile phone A executes step 702.

[0193] 702. The settings application of mobile phone A initiates a binding request to the DM of mobile phone A.

[0194] The settings application refers to the application named "Settings". This settings application is used to configure the basic functions of phone A, such as network configuration, display and brightness configuration, sound and vibration configuration, application management configuration, etc.

[0195] The information carried in the binding request may include the name of mobile phone A (e.g., HUAWEI MATE30).

[0196] 703. Optionally, after receiving the binding request sent by the settings application, the DM of mobile phone A requests the information of the authenticated device from the device information database of mobile phone A.

[0197] Mobile phone A's DM can read information about authenticated devices from the device information database. The device information database stores information about devices that have been authenticated with mobile phone A. This information may include the device name and device ID. The device ID can be, for example, an International Mobile Equipment Identity (IMEI). For example, the information about devices authenticated with mobile phone A can be shown in Table 1.

[0198] Table 1

[0199] kiki's Mate pad 123456XXXXXXX kiki's Matebook Pro 654321XXXXXXX

[0200] 704. Optionally, the device information database of mobile phone A returns the information of the authenticated device to the DM of mobile phone A.

[0201] In one possible design, after mobile phone A and mobile phone B authenticate each other, the information of the authenticated device can include the information of mobile phone B.

[0202] It should be understood that steps 703 and 704 are optional during device-level authentication between phone A and phone B. If steps 703 and 704 are executed, i.e., if the information of the authenticated device is obtained, phone A can display the authenticated device to the user. The authenticated device can be in a bound state by default, or the authenticated device can be rebound.

[0203] Steps 703 and 704 are an illustrative implementation of how the DM of mobile phone A obtains information about the authenticated device. The DM of mobile phone A can also obtain information about the authenticated device in other ways (e.g., reading information about the authenticated device from a preset storage space), which is not limited in this application.

[0204] 705. The DM of mobile phone A requests information about nearby devices from the communication module of mobile phone A.

[0205] Device management can continuously broadcast to its surroundings via a persistent service that calls device A's communication module. This allows device management to discover all near-field devices (i.e., all devices using near-field communication, including Wi-Fi and Bluetooth) by registering a broadcast listening service. Combined with information on authenticated devices retrieved from the device information database, DM can categorize and display authenticated devices from the near-field device pool using icons (e.g., ...). Figure 5C (a) shows kiki's Mate pad, kiki's Mate book pro, etc.) and uncertified devices (such as Figure 5C (See room TV shown in (b), including HUAWEI P20 and Matebook X Pro, etc.)

[0206] It should be noted that there is no necessary order of execution between steps 703 and 705, and this embodiment does not impose any specific restrictions on this.

[0207] 706. The communication module of mobile phone A returns information about nearby devices to the DM of mobile phone A.

[0208] 707. DM on mobile phone A pops up a list of nearby devices.

[0209] like Figure 5C As shown in (b), the DM of mobile phone A can call the pop-up capability, thereby popping up pop-up 508 (i.e., the list of nearby devices) on the screen of mobile phone A. Pop-up 508 includes nearby devices such as the room TV, HUAWEI P20 and Matebook X Pro.

[0210] 708. The user selects the device to be bound.

[0211] For example, such as Figure 5C As shown in (b), users can select the device to be bound from the list of nearby devices. For example, users can select HUAWEI P20 (i.e., phone B).

[0212] 709. The DM of mobile phone A requests the creation of an underlying channel from the communication module of mobile phone A.

[0213] The underlying channel can be a Bluetooth channel or a Wi-Fi channel, etc., and this application does not limit it.

[0214] 710. The communication module of mobile phone A interacts with the communication module of mobile phone B to create an underlying channel.

[0215] 711. Optionally, the communication module of mobile phone A sends a creation success notification to the DM of mobile phone A.

[0216] That is, the communication module of mobile phone A sends a notification of successful creation of the underlying channel to the DM of mobile phone A, indicating that the underlying channel has been successfully created between the communication module of mobile phone A and the communication module of mobile phone B.

[0217] It should be understood that step 711 is optional during device-level authentication between phone A and phone B. If step 711 is executed, the DM of phone A can be promptly notified that the underlying channel has been successfully created, allowing subsequent data transmission via the underlying channel. Alternatively, the success of the underlying channel creation can be determined through other means, such as assuming that the underlying channel creation was successful if no notification of failure is received after a preset time.

[0218] 712. The DM of mobile phone A sends an authentication request message to mobile phone B through the communication module of mobile phone A.

[0219] The authentication request message may include the identifier of mobile phone A (e.g., name or ID) and authentication information generated by mobile phone A. The authentication information generated by mobile phone A may include a token generated by mobile phone A. The name of mobile phone A may be, for example, HUAWEI MATE30. The token may be, for example, a random string of several characters.

[0220] The token can be used for identity authentication. In this embodiment, mobile phone A can send a token to mobile phone B. The token can be mobile phone A's device ID / MAC address, or other identifiers used to identify mobile phone A. After receiving the token from mobile phone A, mobile phone B can add the token information to the QR code image subsequently generated by mobile phone B, making the QR code image usable only by mobile phone A.

[0221] like Figure 7B As shown, the above method also includes:

[0222] 713. Optionally, the communication module of mobile phone B sends a creation success notification to the DM of mobile phone B.

[0223] That is, the communication module of mobile phone B sends a notification of successful creation of the underlying channel to the DM of mobile phone B, indicating that the underlying channel has been successfully created between the communication module of mobile phone B and the communication module of mobile phone A.

[0224] It should be understood that step 713 is optional during device-level authentication between phone A and phone B. If step 713 is executed, the DM of phone B can be promptly notified that the underlying channel has been successfully created, allowing subsequent data transmission via the underlying channel. Alternatively, the success of the underlying channel creation can be determined through other means, such as assuming that the underlying channel creation was successful if no notification of failure is received after a preset time.

[0225] It should be noted that there is no necessary order of execution between steps 711 and 713, and this embodiment does not impose any specific restrictions on this.

[0226] 714. The communication module of mobile phone A sends an authentication request message to the communication module of mobile phone B.

[0227] The communication module of mobile phone A can send an authentication request message to the communication module of mobile phone B through the underlying channel.

[0228] 715. The communication module of mobile phone B forwards the authentication request message to the DM of mobile phone B.

[0229] It is understood that steps 712, 714, and 715 describe the process of mobile phone A sending an authentication request message to mobile phone B. The DM of mobile phone A and the DM of mobile phone B need to communicate through the communication modules of mobile phone A and mobile phone B respectively. Of course, the DM of mobile phone A and the DM of mobile phone B can also communicate through other modules, or the DM of mobile phone A and the DM of mobile phone B can have communication capabilities and communicate directly; this application does not impose any limitations.

[0230] 716. Optionally, the DM on mobile phone B may notify the user via a pop-up window whether they agree to the binding.

[0231] For example, such as Figure 6A As shown in (a), mobile phone A can pop up a pop-up window 531, which may include the prompt message 532 "HUAWEI MATE30 requests to bind to this device, do you trust this device?" The pop-up window 531 may also include a distrust button 533 and a trust button 534.

[0232] 717. Optionally, mobile phone B receives the user's consent to the binding process.

[0233] For example, such as Figure 6A As shown in (a), clicking the trust button 534 indicates that the user agrees to the binding.

[0234] If the user agrees (e.g., ... Figure 6A As shown in (a), if the user clicks the trust button (534), the DM of mobile phone B can return the user's consent information to the DM of mobile phone A through the communication module. Mobile phone A can prompt the user to actively scan the QR code (QR code image) displayed on the other end (mobile phone B).

[0235] Additionally, if the user disagrees (for example, if the user clicks the distrust button 533), the DM of phone B can return the user's disagreement information to the DM of phone A through the communication module. Phone A can then display the following: Figure 5E The message shown in (c) indicates that the binding failed.

[0236] It should be understood that steps 716 and 717 are optional when phone A and phone B perform device-level authentication. For example, if phone A and phone B are logged into the same account or have set up services such as family numbers, phone B can directly execute step 718A and the necessary subsequent steps without asking the user for consent to the binding.

[0237] Steps 716 and 717 are one way for mobile phone B to prompt the user whether they agree to the binding. Mobile phone B can also prompt the user in other ways, such as through background system notification messages. This application does not limit this.

[0238] 718A. The DM of mobile phone B determines whether mobile phone B has created a group related to mobile phone A.

[0239] The DM (Distributed Management) of mobile phone B can query its HiChain to see if it has created a public group related to mobile phone A. Mobile phone B's HiChain can store all group information created by mobile phone B, including public and private groups. A public group can be a group created at the device level; for example, two devices belonging to the same public group indicates that the two devices have undergone device-level authentication, and all applications between the two devices can securely communicate. A private group is a group created at the device and application level; for example, a first application on a first device can perform application-level authentication with a second application on a second device. After application-level authentication, the first and second applications belong to the same private group, at which point they can securely communicate (e.g., securely share data). The identifiers of the first and second applications can be the same or different; this application does not limit this. Two applications belonging to the same private group on each device indicate that the two devices have undergone application-level authentication, and the specific applications corresponding to the two devices can securely communicate. For example, all group information created by mobile phone B can be shown in Table 2:

[0240] Table 2

[0241] Group 1 (Phone B, Phone C) Group 3 (Application 1 on phone B, Application 2 on phone D) Group 2 (Phone B, Phone D) Group 4 (Application 1 on phone B, Application 3 on phone E)

[0242] Optionally, Group 1 and Group 2 in Table 2 can be combined into a group with 3 members, such as Group 5 (phone B, phone C, phone D). In this way, phone A can find the devices that have performed device-level authentication with phone A from Group 5 without having to traverse the public groups established between each pair of devices.

[0243] Optionally, groups 3 and 4 in Table 2 can be combined into a group with 3 members, such as group 6 (application 1 on phone B, application 2 on phone D, and application 3 on phone E). In this way, phone A can find the applications of devices that have performed application-level authentication with phone A from group 6 without having to traverse the private groups established between each pair of applications.

[0244] 718B. If mobile phone B has not created a group related to mobile phone A, the DM of mobile phone B requests the creation of the group from the security management module of mobile phone B.

[0245] Phone B's security module creates a group about phone A, named after the device IDs of both phones A and B. Furthermore, the group attribute between phones A and B can be set to public, meaning all applications on phones A and B can communicate with each other.

[0246] 718C and the security management module of mobile phone B send a group creation success notification to the DM of mobile phone B.

[0247] It should be understood that steps 718B and 718C are illustrative ways of creating a group, and this application does not limit other ways of creating a group. For example, the DM of mobile phone B can directly create a group.

[0248] 719. The DM of mobile phone B requests a tag from the HarmonyOS tag management module of mobile phone B.

[0249] The HarmonyOS tag management module on phone B can generate a tag that includes authentication verification information and phone B's session identifier. The authentication verification information may include a token received from phone A. Alternatively, the authentication verification information can be considered to include the token received from phone A and phone B's session identifier. Phone B's session identifier includes phone B's device connection information. For example, phone B's session identifier includes phone B's Wi-Fi address (e.g., IP address and port number) or Bluetooth address.

[0250] The authentication verification information may also include a Personal Identification Number (PIN) corresponding to the group. The PIN can be, for example, a random number of digits, such as 6 or 8 digits. In this embodiment, mobile phone B can send the PIN corresponding to the group to mobile phone A. When mobile phone A needs to join a group created by mobile phone B, it can include the PIN in the request. Mobile phone B determines that the PIN carried by mobile phone A is correct (i.e., it was sent to mobile phone A by mobile phone B), considers mobile phone A to be secure and trustworthy, and allows mobile phone A to join the group created by mobile phone B.

[0251] 720. The HarmonyOS tag management module of mobile phone B requests a QR code image (BitMap) for authentication verification information from the QR code recognition module of mobile phone B.

[0252] The QR code recognition module of mobile phone B can assemble a QR code image based on authentication and verification information. It should be noted that the above embodiments use a QR code image as an identifier for illustrative purposes; the QR code image can be replaced with other types of identifiers, such as barcodes or strings, and this application does not impose any limitations on this.

[0253] 721. The QR code recognition module of mobile phone B returns a QR code image to the HarmonyOS tag management module of mobile phone B.

[0254] 722. The HarmonyOS tag management module of mobile phone B returns a QR code image to the DM of mobile phone B.

[0255] 723a. Optionally, the DM of mobile phone B sends a QR code image to the communication module of mobile phone B.

[0256] In one possible design, the DM of mobile phone B can send the QR code image of mobile phone B to mobile phone A through mobile phone B's communication module, so that mobile phone A can internally scan the QR code image. That is, after step 723a, steps 723b-725 can be executed. In another possible design, mobile phone B can display the QR code image of mobile phone B on mobile phone B's display interface (e.g., ...). Figure 6C The display interface shown allows mobile phone A to directly scan the QR code, enabling the QR code recognition module in mobile phone A to directly obtain the QR code image generated by mobile phone B, thus skipping steps 723b-725. Both of the above designs can achieve the technical effect of this solution, and this application does not limit them.

[0257] 723b. Optionally, the communication module of mobile phone B sends a QR code image to the communication module of mobile phone A.

[0258] The DM function on phone A can activate the QR code recognition module, which can then scan the QR code image generated by phone B.

[0259] like Figure 7C As shown, the above method also includes:

[0260] 724. Optionally, the communication module of mobile phone A sends a QR code image to the DM of mobile phone A.

[0261] 725. Optionally, the DM of mobile phone A sends a QR code image to the QR code recognition module of mobile phone A.

[0262] 726. The QR code recognition module of mobile phone A scans the QR code image and sends the recognized information to the HarmonyOS tag management module of mobile phone A.

[0263] 727. The HarmonyOS tag management module of mobile phone A parses the information sent by the QR code recognition module and obtains the parsing result.

[0264] The parsing results may include information such as token, PIN, and session identifier of mobile phone B.

[0265] 728. The HarmonyOS tag management module of mobile phone A sends the parsing result to the DM of mobile phone A.

[0266] It is understood that steps 724-728 are one illustrative implementation of how mobile phone A processes QR code images. Mobile phone A can also process QR code images in other ways, and this application does not limit this. For example, mobile phone A's DM can integrate QR code image processing functionality, so that mobile phone A's DM can directly scan and parse the QR code image to obtain information such as token, PIN, and mobile phone B's session identifier.

[0267] 729. DM verification token for mobile phone A.

[0268] If the token received from mobile phone B is the same as the token carried in the authentication request message, proceed to step 730.

[0269] 730. DM callback authentication for mobile phone A was successful.

[0270] It should be understood that steps 729 and 730 are optional when phone A and phone B perform device-level authentication. Performing steps 729 and 730, i.e., verifying the DM token of phone A, can better ensure the security of communication between phone A and phone B.

[0271] 731. Phone A joins a public group created by Phone B.

[0272] The DM of mobile phone A determines the Wi-Fi address or Bluetooth address of mobile phone B based on the session identifier, and requests to join the group created by mobile phone B from the security module of mobile phone A.

[0273] Phone A's security module establishes an underlying communication channel using a Wi-Fi or Bluetooth address and sends a group join request to Phone B. The group join request may include a group ID. Optionally, a PIN may also be included in the request. Upon receiving the group join request, Phone B verifies the PIN. If authentication is successful (i.e., the PIN matches the PIN in the QR code image), both devices join the same group (the group members may include both Phone A and Phone B, and the group's attribute is public), thus completing authentication.

[0274] In one possible implementation, when mobile phone B receives a request to join the group and passes authentication, it sends a response message to mobile phone A, indicating that mobile phone A has joined the public group created by mobile phone B.

[0275] 732. The security management module of mobile phone A notifies the application (settings application) that authentication was successful.

[0276] Phone A can save group information locally. Group information can include group members (group members can include both phone A and phone B), and can also include the group name and attribute information (e.g., the attribute is public).

[0277] In this way, device-level authentication is completed between phone A and phone B, enabling all applications on phone A and phone B to communicate with each other. For example, live streaming, karaoke, shopping, and email applications on phone A can communicate with the same applications on phone B.

[0278] In some embodiments, if one of mobile phone A and mobile phone B is logged into an account (e.g., a Huawei account) while the other is not, mobile phone A and mobile phone B can perform all or part of the steps 701-732 described above. This is to perform verification (i.e., device-level authentication) when mobile phone A and mobile phone B are bound together, thereby ensuring the security of data between the devices.

[0279] In some embodiments, if neither mobile phone A nor mobile phone B has a logged-in account (e.g., a Huawei account), mobile phone A and mobile phone B can perform steps 701-732 above. This is to perform verification when mobile phone A and mobile phone B are bound, so as to ensure the security of data between the devices.

[0280] In some embodiments, if mobile phone A and mobile phone B are logged into the same account (e.g., a Huawei account), mobile phone A and mobile phone B can perform steps 701-732 above. This is to verify the data when mobile phone A and mobile phone B are bound together, further ensuring the security of data between the devices.

[0281] It should be noted that some steps in steps 701-732 above are optional, meaning they are not essential technical features of the device-level authentication scheme. For example, steps 703 and 704 are optional, meaning that it is possible to directly view nearby devices without querying already authenticated devices. Similarly, steps 711 and 713 are optional, meaning that a creation success notification may not be sent. Furthermore, steps 716 and 717 are optional, meaning that binding can be performed directly without user consent. Finally, steps 723b-725 are optional, in which case mobile phone A can directly obtain the QR code image generated by mobile phone B (e.g., by scanning the QR code image displayed on mobile phone B).

[0282] If device-level authentication is not performed between devices, application-level authentication can be performed between devices, enabling interoperability between specific applications. The following section describes the UI of the application-level authentication provided in this embodiment, using a live streaming application as an example, in a specific scenario.

[0283] With the development of e-commerce, more and more people are paying attention to live-streaming sales as a new sales channel. Live-streaming sales not only require clear shooting and accurate audio from the equipment used for product demonstrations, but also a better interactive experience. One current pain point in live-streaming sales is that it is impossible to simultaneously showcase the host and clear product details in the same shot, resulting in a decrease in the realism and persuasiveness of the e-commerce show's presentation.

[0284] This application provides a distributed display solution for live streaming services based on cross-device FA (Feature Analyzer) sharing. For example, the live stream from phone A (which can be considered a FA, e.g., FA1) can be shared to phone B. Phone B can simultaneously display both the FA from phone A and its own live stream (which can be considered a FA, e.g., FA2), achieving the experience of displaying one or more FAs across devices. This eliminates the hassle of users switching between devices and significantly reduces user operations. This application does not require devices to be on the same operating system or logged into the same device account (e.g., the same Huawei account), making it widely applicable.

[0285] For example, such as Figure 8A As shown, after a user opens a live streaming application on phone A, phone A can display a live streaming interface 801. The live streaming interface 801 may include a migration button 802, which is located in the upper left corner of the interface 801. It should be understood that the migration button 802 can also be located in the lower left, lower right, or upper right corner of the interface 801, etc., and this application does not limit its location. Of course, the text displayed on the button 802 can also be other content, such as "share" or "transfer," and this application does not limit its location. In response to the user clicking the migration button 802 on the live streaming interface 801 (the migration button 802 is used to migrate (send) the live streaming interface of phone A to another device (e.g., phone B)), as follows... Figure 8B As shown in (a), mobile phone A can display pop-up window 803. It should be understood that the embodiments of this application do not limit the method of transitioning between UI interfaces. For example, as... Figure 8A As shown, in response to user-specific gestures (e.g., three-finger swipe down, knuckle tap, etc.), such as Figure 8B As shown in (a), the mobile phone can display a pop-up window 803. This pop-up window 803 can include nearby devices, including authenticated devices (bedroom TV, Monica's Matepad, etc.) and unauthenticated devices (room TV, HUAWEI P20, and Matebook X Pro, etc.). In response to the user clicking the control 804 corresponding to the HUAWEI P20 (an unauthenticated device), mobile phone A can send an authentication request message to mobile phone B. Furthermore, as... Figure 8B As shown in (b) below, the HUAWEI P20 displays the message 805 "Waiting for confirmation from the other end". Figure 8C As shown in (a), if mobile phone B (HUAWEI P20) receives an authentication request message from mobile phone A while displaying the live broadcast interface 811, mobile phone B can display a pop-up window 812. The pop-up window 812 includes the prompt message "HUAWEI P20 (mobile phone A) requests to migrate the live broadcast interface to this device. Do you agree?". This is in response to the user clicking the drop-down button 813. Figure 8C As shown in (b), the pop-up 812 can display more content, such as a "Disagree" button 814 and an "Agree" button 815a. Optionally, in response to the user clicking the "Agree" button 815a, as shown in (b), the pop-up 812 can display more content, such as a "Disagree" button 814 and an "Agree" button 815a. Figure 8C As shown in (c), the mobile phone can display a pop-up window 815b, which may include a "Agree only this time" button 815c and a "Always agree (don't prompt again)" button 815d. In response to the user clicking the "Agree" button 815a, the "Agree only this time" button 815c, or the "Always agree" button 815d, as shown... Figure 8D As shown, phone B can display a pop-up window 816, which may include a QR code image generated by phone B, and may also include a prompt message 817 "Scan to authenticate, allow HUAWEI MATE30 to scan for authentication". At this time, the user of phone A can scan the QR code image displayed by phone B, and then phone B can receive the live stream (FA1) from phone A, as shown. Figure 8E As shown, mobile phone B can display the live broadcast interface 819 sent by mobile phone A on the live broadcast interface 811. Alternatively, in response to the user clicking the agree button 815, mobile phone B can receive the live broadcast screen (FA1) from mobile phone A, as shown. Figure 8E As shown, mobile phone B can display the live broadcast interface 819 sent by mobile phone A on the live broadcast interface 811.

[0286] The following uses a live streaming application as an example to illustrate the specific implementation of the application-level authentication method provided in this application embodiment. The method provided in this application embodiment can be applied to two near-field devices, such as mobile phone A and mobile phone B, where mobile phone A and mobile phone B are devices with different accounts (e.g., not logged into the same Huawei account), and both mobile phone A and mobile phone B have a live streaming application open. Figure 9A As shown, it includes:

[0287] 901. Mobile phone A receives a user-triggered function migration operation.

[0288] For example, such as Figure 8A As shown, users can click the migration button 802 while the live streamer is on mobile phone A. The migration button can also be called a share button, send button, etc., and this application does not limit it.

[0289] Users can trigger feature migration in other ways, such as by "tap" or "scan", and this application does not limit this.

[0290] 902. An application (e.g., a live streaming application) initiates a migration request to the DM of mobile phone A.

[0291] The migration request may include the identifier of the initiating application (local live streaming application package name), the identifier of the receiving application (parallel live streaming application package name), and the name of mobile phone A. The receiving application package name can be provided by the application (e.g., a live streaming application), depending on the application vendor's design, and will not be elaborated upon here.

[0292] In one possible design, the information carried in the migration request can be arranged in a preset order. For example, the preset order could be the name of phone A, the identifier of the initiating application, and the identifier of the receiving application. Alternatively, the preset order could be the identifier of the initiating application, the identifier of the receiving application, and the name of phone A.

[0293] 903. Optionally, after receiving the migration request, the DM of mobile phone A requests the authenticated device from the device information database of mobile phone A.

[0294] For details on the process, please refer to the relevant description in step 703, which will not be repeated here.

[0295] 904. Optionally, the device information database of mobile phone A returns the information of the authenticated device to the DM of mobile phone A.

[0296] It should be understood that steps 903 and 904 are optional when phone A and phone B perform device-level authentication. If steps 903 and 904 are executed, that is, if the information of the authenticated device is obtained, phone A can display the authenticated device to the user.

[0297] Steps 903 and 904 are an illustrative implementation of how the DM of mobile phone A obtains information about the authenticated device. The DM of mobile phone A can also obtain information about the authenticated device in other ways (e.g., reading information about the authenticated device from a preset storage space), which is not limited in this application.

[0298] 905. The DM of mobile phone A requests information about nearby devices from the communication module of mobile phone A.

[0299] For details on the process, please refer to the relevant description in step 705, which will not be repeated here.

[0300] 906. The communication module of mobile phone A returns information about nearby devices to the DM of mobile phone A.

[0301] 907. DM on mobile phone A pops up a list of nearby devices.

[0302] The list of nearby devices could be, for example, like Figure 8B The pop-up window 803 is shown in (a) above.

[0303] Users can select a device from the list of nearby devices. If the device is untrusted (i.e., a device with a different account that has not been authenticated (e.g., not logged into the same Huawei account)), after step 907, steps 908-936 can be executed for application-level authentication. If the device is trusted (e.g., logged into the same Huawei account, or previously authenticated (including device-level authentication or application-level authentication)), the FA can be migrated directly, i.e., after step 907, steps 933-936 can be executed directly.

[0304] 908. The user selected an uncertified device.

[0305] For example, such as Figure 8B As shown in (a), the user selected HUAWEI P20, which is an untrusted device.

[0306] 909. The DM of mobile phone A requests the creation of an underlying channel from the communication module of mobile phone A.

[0307] The underlying channel can be a Bluetooth channel or a Wi-Fi channel, etc., and this application does not limit it.

[0308] 910. The communication module of mobile phone A interacts with the communication module of mobile phone B to create an underlying channel.

[0309] 911. Optionally, the communication module of mobile phone A sends a notification of successful creation of the underlying channel to the DM of mobile phone A.

[0310] It should be understood that step 911 is optional during device-level authentication between phone A and phone B. If step 911 is executed, the DM of phone A can be promptly notified that the underlying channel has been successfully created, allowing subsequent data transmission via the underlying channel. Alternatively, the success of the underlying channel creation can be determined through other means, such as assuming that the underlying channel creation was successful if no notification of failure is received after a preset time.

[0311] 912. The DM of mobile phone A sends an authentication request message to mobile phone B through the communication module of mobile phone A.

[0312] The authentication request message includes the name of the initiating device (e.g., HUAWEI MATE30), the name of the initiating packet (e.g., com.zhibo.video), and the name of the receiving packet (e.g., com.zhibo.video). The authentication request message also includes a token generated by mobile phone A.

[0313] like Figure 9B As shown, the above method also includes:

[0314] 913. Optionally, the communication module of mobile phone B sends a notification of successful creation of the underlying channel to the DM of mobile phone B.

[0315] It should be noted that there is no necessary order of execution between steps 911 and 913, and this embodiment does not impose any specific restrictions on this.

[0316] It should be understood that step 913 is optional during device-level authentication between phone A and phone B. If step 913 is executed, phone B's DM can be promptly notified of the successful creation of the underlying channel, enabling subsequent data transmission via the underlying channel. Alternatively, the success of the underlying channel creation can be determined through other means, such as assuming successful creation if no notification of underlying channel creation failure is received after a preset time.

[0317] 914. The communication module of mobile phone A sends an authentication request message to the communication module of mobile phone B.

[0318] The information carried in the authentication request message may include the identifier of the initiating application, the identifier of the receiving application, and the name of mobile phone A.

[0319] In one possible design, the information carried in the authentication request message can be arranged in a preset order. For example, the preset order could be the name of mobile phone A, the identifier of the initiating application, and the identifier of the receiving application. Alternatively, the preset order could be the identifier of the initiating application, the identifier of the receiving application, and the name of mobile phone A.

[0320] 915. The communication module of mobile phone B forwards the authentication request message to the DM of mobile phone B.

[0321] It is understood that steps 912, 914, and 915 describe the process of mobile phone A sending an authentication request message to mobile phone B. The DM of mobile phone A and the DM of mobile phone B need to communicate through the communication modules of mobile phone A and mobile phone B respectively. Of course, the DM of mobile phone A and the DM of mobile phone B can also communicate through other modules, or the DM of mobile phone A and the DM of mobile phone B can have communication capabilities and communicate directly; this application does not impose any limitations.

[0322] 916. Optionally, the DM on mobile phone B may notify the user via a pop-up window whether they agree to the migration.

[0323] For example, such as Figure 8C As shown in (a), if mobile phone B receives an authentication request message from mobile phone A while displaying the live broadcast interface 811, mobile phone B can display a pop-up window 812. The pop-up window 812 includes the prompt message "HUAWEI MATE30 requests to migrate the live broadcast interface to this device, do you agree?" This is in response to the user clicking the drop-down button 813, as shown in (a). Figure 8CAs shown in (b), the pop-up 812 can display more content, such as a disagree button 814 and an agree button 815a.

[0324] Optionally, in response to the user clicking the "Agree" button 815a, such as... Figure 8C As shown in (c), the mobile phone can display a pop-up window 815b, which may include a "Agree only this time" button 815c and a "Always agree (don't prompt again)" button 815d. It should be understood that, in response to the user clicking the "Agree only this time" button 815c, after performing steps 917-932 below, mobile phone A can migrate the live streaming interface (i.e., FA1) to mobile phone B once. The next time FA is migrated from the live streaming application on mobile phone A to the live streaming application on mobile phone B, re-authentication is required, for example, steps 901-932 can be performed again. In response to the user clicking the "Always agree" button 815d, after performing steps 917-932 below, the live streaming application on mobile phone A can continuously migrate FA to the live streaming application on mobile phone B without re-authentication (for example, steps 901-932 do not need to be performed again).

[0325] 917. Optionally, mobile phone B receives the user's consent to the migration.

[0326] For example, such as Figure 8C As shown in (b), mobile phone B can receive the user's click on the agree button 815a.

[0327] If the user agrees (for example, if the user clicks the agree button 815a), the DM of mobile phone B can return the user's consent information to the DM of mobile phone A through the communication module. Mobile phone A can then prompt the user to actively scan the QR code (QR code image) displayed on the other end (mobile phone B).

[0328] Additionally, if the user disagrees (for example, if the user clicks the disagree button 814), the DM of mobile phone B can return the user's disagreement information to the DM of mobile phone A through the communication module. Mobile phone A can then display the following: Figure 5E The message shown in (c) indicates that the migration failed.

[0329] It should be understood that steps 916 and 917 are optional when phone A and phone B are performing device-level authentication. For example, if phone A and phone B are logged into the same account or have set up services such as family numbers, phone B can directly execute step 918A and the necessary subsequent steps without asking the user for consent to the migration.

[0330] Steps 916 and 917 are one way for mobile phone B to prompt the user whether they agree to the migration. Mobile phone B can also prompt the user in other ways, such as through background system notification messages. This application does not limit this.

[0331] 918A and Mobile Phone B's DM determines whether Mobile Phone B has created a group related to Mobile Phone A's live streaming application.

[0332] The DM for phone B can be checked in phone B's HiChain to see if phone B has created a private group related to phone A. For details, please refer to step 718A, which will not be repeated here.

[0333] 918B. If mobile phone B has not created a group related to the live streaming application of mobile phone A, the DM of mobile phone B requests the creation of the group from the security management module of mobile phone B.

[0334] The security module on phone B can create a group related to the live streaming application on phone A (the group members can include both the live streaming applications on phone A and phone B). Furthermore, the group attribute can be set to private, meaning it only applies to specific applications (live streaming applications).

[0335] Optionally, phone B can send the group ID of a group it created related to phone A's live streaming application to phone A. Phone A can then join the group created by phone B based on the group ID. Optionally, phone B can also send its device ID to phone A. Phone B's device ID can be used by phone A when communicating with phone B, and it can include a network ID (netId) and a device IP (deviceIP).

[0336] The security management module of 918C and mobile phone B sends a group creation success notification to the DM of mobile phone B.

[0337] It should be understood that steps 918B and 918C are illustrative ways of creating a group, and this application does not limit other ways of creating a group. For example, the DM of mobile phone B can directly create a group.

[0338] 919. The DM of mobile phone B requests a tag from the HarmonyOS tag management module of mobile phone B.

[0339] The HarmonyOS tag management module on phone B can generate tags that include authentication verification information. This information may include a token received from phone A and phone B's session identifier. Phone B's session identifier includes its device connection information. For example, phone B's session identifier may include its Wi-Fi address (e.g., IP address and port number) or Bluetooth address. The authentication verification information may also include a PIN corresponding to the group.

[0340] 920. The HarmonyOS tag management module of mobile phone B requests a QR code image for authentication verification information from the QR code recognition module of mobile phone B.

[0341] The QR code recognition module of mobile phone B can assemble a QR code image based on the authentication and verification information.

[0342] 921. The QR code recognition module of mobile phone B returns a QR code image to the HarmonyOS tag management module of mobile phone B.

[0343] 922. The HarmonyOS tag management module of mobile phone B returns a QR code image to the DM of mobile phone B.

[0344] 923a. Optionally, the DM of mobile phone B sends a QR code image to the communication module of mobile phone B.

[0345] In one possible design, the DM of mobile phone B can send the QR code image of mobile phone B to mobile phone A, so that mobile phone A can perform an internal scan of the QR code image; that is, after step 923a, steps 923b-925 can be executed. In another possible design, mobile phone B can display the QR code image of mobile phone B on mobile phone B's display interface (e.g., ...). Figure 8D The display interface shown allows mobile phone A to directly scan the QR code, enabling the QR code recognition module in mobile phone A to directly acquire the QR code image generated by mobile phone B, thus skipping steps 923b-925. Both of the above designs can achieve the technical effect of this solution, and this application does not limit them.

[0346] 923b. Optionally, the communication module of mobile phone B sends a QR code image to the communication module of mobile phone A.

[0347] The DM function on phone A can activate the QR code recognition module, which can then scan the QR code image generated by phone B.

[0348] like Figure 9C As shown, the above method also includes:

[0349] 924. Optionally, the communication module of mobile phone A sends a QR code image to the DM of mobile phone A.

[0350] 925. Optionally, the DM of mobile phone A sends a QR code image to the QR code recognition module of mobile phone A.

[0351] 926. The QR code recognition module of mobile phone A scans the QR code and sends the recognized information to the HarmonyOS tag management module of mobile phone A.

[0352] 927. The HarmonyOS tag management module of mobile phone A parses the information sent by the QR code recognition module and obtains the parsing result.

[0353] The parsing results may include information such as the token, PIN, and session identifier of mobile phone B.

[0354] 928. The HarmonyOS tag management module of mobile phone A sends the parsing result to the DM of mobile phone A.

[0355] It is understood that steps 924-928 are one illustrative implementation of how mobile phone A processes QR code images. Mobile phone A can also process QR code images in other ways, and this application does not limit this. For example, mobile phone A's DM can integrate QR code image processing functionality, so that mobile phone A's DM can directly scan and parse the QR code image to obtain information such as token, PIN, and mobile phone B's session identifier.

[0356] 929. DM verification token for mobile phone A.

[0357] If the token received from mobile phone B is the same as the token carried in the authentication request message, proceed to step 930.

[0358] 930. Mobile phone A's DM callback authentication was successful.

[0359] It should be understood that steps 929 and 930 are optional when phone A and phone B perform device-level authentication. Performing steps 929 and 930, i.e., verifying the DM token of phone A, can better ensure the security of communication between phone A and phone B.

[0360] 931. Mobile phone A's live streaming application joins a private group created by mobile phone B.

[0361] Based on the session identifier index, the DM of mobile phone A requests to join the private group created by mobile phone B by the security module of mobile phone A to access the Wi-Fi address or Bluetooth address of the peer device (i.e., mobile phone B) stored on the local end.

[0362] Phone A's security module establishes an underlying communication channel using a Wi-Fi or Bluetooth address and sends a group join request to Phone B. This request includes the parsed PIN and group ID. Upon receiving the request, Phone B verifies the PIN. Once authentication is successful (i.e., the PIN matches the PIN in the QR code image), the live streaming applications on both devices join the same group (the group members can include the live streaming applications from both Phone A and Phone B; this group is private), completing the authentication process.

[0363] In one possible implementation, when phone B receives a request to join the group and passes authentication, it sends a response message to phone A, indicating that phone A's live streaming application has joined the private group created by phone B.

[0364] 932. The security management module of mobile phone A notifies that the live streaming application authentication is successful.

[0365] In this way, application-level authentication is completed between the live streaming applications on phone A and phone B, enabling interoperability between the live streaming applications on phone A and phone B.

[0366] 933. Mobile phone A's live streaming application requests mobile phone A's DEF to migrate FA1.

[0367] FA1 can implement all or part of the functions in a live streaming application, and it consists of multiple user interfaces.

[0368] 934. Mobile phone A's DEF sends the service information of FA1 to mobile phone B's DMS.

[0369] FA1's business information may include live video streams, audio streams, and bullet screen information.

[0370] 935. Mobile phone B's DMS request to Mobile phone B's DEF to continue FA1.

[0371] In this context, DEF connection FA1 on mobile phone B refers to mobile phone B processing and displaying FA1 based on the received service information. The content displayed on FA1 on mobile phone B may be synchronized with the content displayed on FA1 on mobile phone A, or it may differ in format or some content from the content displayed on FA1 on mobile phone A; this application does not impose any limitations on this.

[0372] 936. The DEF of mobile phone B pulls up to display FA1.

[0373] Among them, DEF pulls up FA1 on mobile phone B means that mobile phone B runs and displays FA1.

[0374] If phone B is currently displaying a live stream (i.e., running FA2), phone B's DEF can detect phone B's FA2. If FA2 has the capability to display FA1 (i.e., FA2 supports displaying multiple FAs), DEF can pull up and display the live stream FA1 on FA2, that is, display the FA1 interface on the FA2 interface. For example, as... Figure 8E As shown, mobile phone B can display the live broadcast interface 819 sent by mobile phone A on the live broadcast interface 811. In this way, the user can simultaneously watch the live broadcast screen of mobile phone B and the live broadcast screen of mobile phone A on mobile phone B, achieving the experience of displaying one or more FAs across devices, saving the user the trouble of switching back and forth between terminals, simplifying user operation, and improving user experience.

[0375] If phone B is currently in a live stream (i.e. running FA2), but FA2 does not have the ability to display FA1, then the FA1 migration will fail. However, phone A can still continue to share other FAs of the live stream application (e.g., the live shopping cart FA3) without having to establish a connection again.

[0376] If phone B is currently on the desktop, you can preview and control phone A's FA1 on the desktop.

[0377] It should be understood that if there is a scenario where a device FA (e.g., FA4) is migrated from phone C to phone B, and phone B is currently displaying FA2, if FA2 has the ability to display multiple FAs, phone B can display three FAs (FA1, FA2, and FA3) simultaneously, and so on.

[0378] This application's embodiments are mainly applied to scenarios where FA (Features) are shared across devices in live streaming applications. That is, by sharing FA across multiple devices, a single device can simultaneously display multiple FAs. This allows for free dual-view, dual-screen live streaming, which can be used in scenarios such as product review live streaming (unboxing close-up + host), sports broadcasting (athlete's perspective + commentary), educational live streaming (book close-up + teacher), and e-commerce live streaming (product details + show director). This can improve user experience and product competitiveness.

[0379] In some embodiments, if one of mobile phone A and mobile phone B is logged into an account (e.g., a Huawei account) while the other is not logged into an account, mobile phone A and mobile phone B can perform steps 901-936 above. This is to perform verification (i.e., device-level authentication) during FA migration between mobile phone A and mobile phone B, thereby ensuring the security of data (e.g., FA1) between the devices.

[0380] In some embodiments, if neither phone A nor phone B has a logged-in account (e.g., a Huawei account), phone A and phone B can perform steps 901-936 above. This is to perform verification during FA migration between phone A and phone B, ensuring the security of data between the devices.

[0381] In some embodiments, if mobile phone A and mobile phone B are logged into the same account (e.g., a Huawei account), mobile phone A and mobile phone B can perform steps 901-936 above. This is to perform verification during FA migration between mobile phone A and mobile phone B, further ensuring the security of data between the devices.

[0382] It should be noted that some steps in steps 901-936 above are optional, meaning they are not essential technical features of the application-level authentication scheme. For example, steps 903 and 904 are optional, meaning that it is possible to directly view nearby devices without querying already authenticated devices. Similarly, steps 911 and 913 are optional, meaning that a creation success notification does not need to be sent. Furthermore, steps 916 and 917 are optional, meaning that migration can proceed directly without user consent. Finally, steps 923b-925 are optional, in which case mobile phone A can directly obtain the QR code image generated by mobile phone B (e.g., by scanning the QR code image displayed on mobile phone B).

[0383] The following section, using a specific scenario and a photo-taking application as an example, describes the UI interface of the application-level authentication provided in this application embodiment.

[0384] When traveling, groups often need to take group photos, which usually requires finding a stranger or using a watch or other external device to control the shutter button. However, relying on strangers or watches often results in unsuitable photos due to a lack of awareness of the surrounding environment. This application provides a method based on cross-device FA (Field Application Frame) sharing technology. This method establishes a connection between two devices, designating one device (e.g., phone A) as the camera phone and transferring the remote camera FA to the other device (e.g., phone B). This allows the user to observe the camera's view on phone A while holding phone B and control the shutter, leading to more satisfactory photos and improved user experience.

[0385] like Figure 10A As shown, when a user takes a photo using phone A, phone A displays a camera interface 1001, which includes a preview frame and a menu area. In response to user A clicking the migration button 1002 in the menu area, phone A can send its camera interface (which can be considered a FA, for example, FA5) to phone B. Figure 10B As shown, phone B can display the camera interface of phone A, and phone B can control the camera interface of phone A.

[0386] The following uses a camera application as an example to illustrate the specific implementation of the method provided in this application. The method provided in this application can be applied to two near-field devices, such as mobile phone A and mobile phone B, where mobile phone A and mobile phone B are devices with different account numbers. Figure 11 As shown, it includes:

[0387] 1101. The user clicks the "Migrate" button in the camera application on phone A.

[0388] For example, such as Figure 10AAs shown, user A can click the migration button 1002 in the photo-taking interface 1001.

[0389] 1102. The camera application of mobile phone A sends a migration request to the DM of mobile phone A.

[0390] The migration request includes the initiating packet name (the local camera application packet name), the receiving packet name (the remote camera application packet name), and the name of mobile phone A.

[0391] Steps 1103-1132 can be referred to the relevant descriptions of steps 903-932, and will not be repeated here. Some steps in steps 903-932 may be optional.

[0392] 1133. The camera application of mobile phone A requests the migration of FA5 from the DEF file of mobile phone A.

[0393] 1134. Mobile phone A's DEF sends information related to FA5 to mobile phone B's DMS.

[0394] Information about the FA5 can include the shooting preview screen and the menu bar information of the shooting interface.

[0395] 1135. Mobile phone B's DMS request to Mobile phone B's DEF to continue FA5.

[0396] "DEF connection FA5" on mobile phone B refers to mobile phone B processing FA5 based on the received service information and displaying it.

[0397] 1136. The DEF of mobile phone B is pulled up to display FA5.

[0398] like Figure 10B As shown, mobile phone B can display and control the camera interface (FA5) of mobile phone A. This embodiment of the application establishes a connection between the two devices through cross-device FA sharing technology, sharing the FA5 of mobile phone A to mobile phone B. This allows mobile phone B to preview the shooting interface and control the camera function of mobile phone A, helping users take more satisfactory photos and improving the user experience.

[0399] The following section uses a karaoke application as an example to introduce the UI interface of the application-level authentication provided in this application embodiment.

[0400] With the rapid development of the internet, mobile karaoke is becoming increasingly popular. For example, after logging into a karaoke app, users can create a karaoke room and invite other users to join by sharing the room link or invitation code. Other users can then enter the same room by clicking the link or entering the invitation code to request songs and sing. However, this sharing process has several problems: 1) Sharing a karaoke room created on the app face-to-face with friends requires... 1) Sharing the link involves multiple steps; 2) When the user receives the karaoke room link and clicks to enter, if the user's device does not have the karaoke app installed, they need to be redirected to the app store to install the karaoke app, and then click the link again to enter the karaoke room, resulting in a poor user experience; 3) Sharing and entering the karaoke room heavily rely on certain devices. Karaoke apps and similar applications cannot provide a truly immersive experience with devices that offer a better near-field experience (such as televisions).

[0401] This application provides a multi-device collaborative control scheme based on FA (Functional Aid) sharing for karaoke scenarios, supporting cross-device application-level mutual assistance and sharing within the same network (e.g., the same Wi-Fi network). For example, karaoke services on the local device (e.g., mobile phone A) can be seamlessly transferred to other terminal devices (e.g., TV, speakers); simultaneously, no user account authorization login is required, and multiple terminal devices do not need to use the same system. This leverages the audio-visual playback advantages of devices such as TVs and speakers, and the convenient interaction and sound pickup advantages of devices such as mobile phones, with simple and quick operation steps, greatly enhancing the user experience.

[0402] like Figure 12A As shown in (a), after the user opens the karaoke app on phone A, phone A can display the karaoke interface 1201, responding to the user's click on the karaoke button 1202 corresponding to the song "Red Bean". Figure 12A As shown in (b), mobile phone A can display Hongdou's karaoke interface 1203, responding to the user's click on the migration button 1204 (the migration button 1204 is used to migrate (send) the karaoke interface of mobile phone A to another device (e.g., mobile phone B)), as follows: Figure 12B As shown in (a), the mobile phone can display a pop-up window 1205, which can include nearby devices, including authenticated devices (bedroom TV, Monica's Matepad, etc.) and unauthenticated devices (room TV, Brian's Matepad, and Matebook X Pro, etc.). In response to the user clicking the control 1206 corresponding to the room TV (an unauthenticated device), mobile phone A can send an authentication request message to mobile phone B. Furthermore, as... Figure 12B As shown in (b), a message 1207 "Waiting for confirmation from the other end" can be displayed below the room's TV. Figure 12C As shown, the TV can display a pop-up window 1210, which includes the message "HUAWEIMATE30 (phone A) requests to migrate the karaoke service to this device, do you agree?". The pop-up window 1210 may also include a "disagree" button 1212 and an "agree" button 1213. In response to the user clicking the "agree" button 1213, as follows... Figure 12DAs shown, the TV can display a pop-up window 1214, which may include a QR code image generated by the TV and a prompt message 1215 "Scan to authenticate, allow HUAWEI MATE30 to scan for authentication". At this time, the user of mobile phone A can scan the QR code image displayed on the TV. Then, the TV can receive the karaoke interface (which can be considered an FA, such as FA6) from mobile phone A. Figure 12E As shown, the TV can display the karaoke interface 1217. Alternatively, in response to the user clicking the agree button 815, the TV can receive the karaoke interface (FA6) from mobile phone A, as shown. Figure 12E As shown, the TV can display the karaoke interface 1217. Furthermore, as... Figure 12F As shown, mobile phone A can be redesigned to function as a song selection control panel. Users can perform operations such as song selection and song skipping on mobile phone A, and the song list information will be synchronously sent to the TV through the communication data channel, allowing control of music playback on the TV.

[0403] The following uses a karaoke application as an example to illustrate the specific implementation of the method provided in this application. The method provided in this application can be applied to two near-field devices on the same network, such as mobile phone A and a television. Mobile phone A can be an Android system or a dual-frame system, and the television can be a HarmonyOS system. Mobile phone A and the television are devices with different account settings. Figure 13 As shown, it includes:

[0404] 1301. The user clicks the "Migrate" button in the karaoke application on mobile phone A.

[0405] 1302. The karaoke application on mobile phone A sends a migration request to the DM on mobile phone A.

[0406] The migration request includes the initiating packet name (local karaoke application packet name), the receiving packet name (remote karaoke application packet name), and the name of mobile phone A.

[0407] Steps 1303-1332 can be referred to the relevant descriptions of steps 903-932, and will not be repeated here. Some steps in steps 903-932 may be optional.

[0408] 1333. The karaoke application on mobile phone A requests the migration of FA6 from the DEF module of mobile phone A.

[0409] 1334. Mobile phone A sends information related to FA6 to the TV's DMS via its DEF.

[0410] The relevant information for FA6 may include song information from karaoke, which includes at least one of the following: song title (e.g., Red Bean), lyrics, audio information, and video information.

[0411] 1335. The TV's DMS requests the TV's DEF connection FA6.

[0412] 1336. The TV's DEF is pulled up to display FA6.

[0413] If a karaoke app is installed on the TV, the TV's DEF can detect whether the karaoke app and account are logged in, prompting the user to log in to the karaoke app so that the karaoke app can display FA6 sent by phone A.

[0414] If the TV does not have a karaoke app installed, the TV's DEF can pull up FA6, meaning it can display FA6. This allows you to use the karaoke service instantly without pre-installing a karaoke app.

[0415] This application provides a near-field application layer data sharing service for karaoke entertainment scenarios, which can realize one-click migration of FA across devices and operating systems. It does not rely on any third-party platform, does not require the pre-installation of karaoke applications, and allows users to use karaoke services instantly, quickly creating mobile karaoke rooms. It can improve user experience, is easy to operate, and enhance the entertainment experience.

[0416] The following section uses a shopping application as an example to introduce the UI interface of the application-level authentication provided in this application embodiment.

[0417] With the rapid development of the internet, especially the widespread adoption of mobile internet, online shopping has become an indispensable part of daily life for most people. Mobile phones and tablets are the most commonly used devices for online shopping; improving the user shopping experience would undoubtedly greatly enhance their market competitiveness. Taking mobile shopping as an example, during various shopping festivals, merchants offer numerous discounts and coupons. To achieve better prices, users often team up with friends and family to purchase certain items together, reaching the merchant's minimum spending requirement for the discount. This process presents several pain points: 1) Sharing an item face-to-face with friends requires forwarding via WeChat, involving multiple steps; 2) To participate in discounts, users frequently switch between the product selection interface and the shopping cart, making the process cumbersome and complex; 3) When multiple people are purchasing a merchant's product together, sharing items, adding to the cart, and switching interfaces become even more frequent, and a transfer is required after payment, which is extremely inconvenient. To address these issues, some manufacturers have proposed face-to-face group buying solutions, which can... Scanning a QR code allows users to share desired items with others in their vicinity, enabling quick and face-to-face group buying. However, this solution has some drawbacks: firstly, it has significant limitations in terms of merchant platforms and usage scenarios; secondly, from user A's payment to sharing the QR code with user B, and then user B opening WeChat to scan, browse, and purchase the item, the sharing process still relies on the WeChat platform, involving multiple steps.

[0418] This application addresses online shopping scenarios by providing an application-layer data sharing service based on near-field FA (Fast Array Provider) sharing. It supports one-click synchronization of shopping cart information between multiple terminal devices on the same network (e.g., the same Wi-Fi network). The shopping cart (which can be considered a single FA, e.g., FA7) can be migrated from one terminal device to another. Items in both devices' carts can be checked out together to enjoy discounts, and then paid separately, eliminating the hassle of inter-device transfers. The operation is simple and quick, significantly improving the user experience of group-buying. Furthermore, since near-field FA sharing is a fundamental capability provided by the system service, it does not require a shared operating system, login to the same device account (e.g., a Huawei account), or even the installation of a shopping app on the device. It boasts high versatility, can be used by various e-commerce platforms, and has low adaptation costs, allowing more users to enjoy a more convenient online shopping experience.

[0419] For example, such as Figure 14A As shown, after a user opens the shopping app on phone A, they can enter the shopping cart interface 1401. In response to the user clicking the migration button 1402 on the shopping cart interface 1401 (the migration button 1402 is used to migrate (send) the shopping cart from phone A to another device (e.g., phone B)), as... Figure 14B As shown in (a), the mobile phone can display a pop-up window 1403, which can include nearby devices, including authenticated devices (bedroom TV, Monica's Mate pad, etc.) and unauthenticated devices (room TV, HUAWEI P20, and Matebook X Pro, etc.). In response to the user clicking the control 1404 corresponding to the HUAWEI P20 (an unauthenticated device), mobile phone A can send an authentication request message to mobile phone B. Furthermore, as... Figure 14B As shown in (b) below, the HUAWEI P20 displays the message 1405 "Waiting for confirmation from the other end". Figure 14C As shown, if phone B (HUAWEI P20) receives an authentication request message from phone A while displaying the desktop, phone B can display a pop-up window 1410. Pop-up window 1410 includes the message "HUAWEI MATE30 (phone A) requests to move the shopping cart to this device. Do you agree?". Pop-up window 1410 can include a "Disagree" button 1412 and an "Agree" button 1413. In response to the user clicking the "Agree" button 1413, as follows... Figure 14DAs shown, phone B can display a pop-up window 1415, which may include a QR code image generated by phone B, and may also include a prompt message 1416 "Scan to bind, allow HUAWEI MATE30 to scan and authenticate." At this time, the user of phone A can scan the QR code image displayed by phone B, and then phone B can receive the shopping cart (FA6) from phone A. Alternatively, in response to the user clicking the "Agree" button 1413, phone B can receive the shopping cart (FA6) from phone A. Figure 14E As shown, mobile phone B can display a shared shopping cart on the shopping cart interface 1417. This shared shopping cart includes both items added by "me" and items added by user A (the user of mobile phone A). Additionally, mobile phone B can also migrate its own shopping cart (e.g., FA7) to mobile phone A. Thus, as... Figure 14F As shown, mobile phone A can display a shared shopping cart on the shopping cart interface (1407). The shared shopping cart includes both items added by "me" and items added by user B (the user of mobile phone B). In this way, users can complete group shopping with one click, without relying on any third-party platform for sharing, saving the cumbersome steps of sharing products and transferring money between each other, and greatly improving the shopping experience.

[0420] The following uses a shopping application as an example to illustrate the specific implementation of the method provided in this application. The method provided in this application can be applied to two near-field devices, such as mobile phone A and mobile phone B, where mobile phone A and mobile phone B are devices with different account numbers. Figure 15 As shown, it includes:

[0421] 1501. The user clicks the "Migrate" button in the shopping application on mobile phone A.

[0422] like Figure 14A As shown, after a user opens the shopping app on phone A, selects items to add to the shopping cart, and then enters the shopping cart interface 1401, the user can click the migration button 1402 on the shopping cart interface 1401. The migration button 1402 is used to migrate (send) the shopping cart of phone A to other devices (e.g., phone B).

[0423] 1502. The shopping application sends a migration request (sharing request) to the DM of mobile phone A.

[0424] The migration request includes the following information: the initiating package name (the local shopping application package name), the successor package name (the peer shopping application package name), and the name of mobile phone A. For example, the initiating package name could be com.huawei.vmall, and the successor package name could be com.huawei.vmall.

[0425] Steps 1503-1532 can be referred to the relevant descriptions of steps 903-932, and will not be repeated here. Some steps in steps 903-932 may be optional.

[0426] 1533. Mobile phone A's shopping application requests the migration of mobile phone A's DEF to FA7.

[0427] 1534. Mobile phone A's DEF sends information related to FA7 to mobile phone B's DMS.

[0428] The relevant information for FA7 includes product information in the shopping cart, which includes at least one of the following: product name, product link, and product price.

[0429] 1535. Mobile phone B's DMS request to Mobile phone B's DEF to continue FA7.

[0430] 1536. The DEF of mobile phone B is pulled up to display FA7.

[0431] Phone B's DEF pulls up FA7, such as Figure 14E As shown, mobile phone B can display a shared shopping cart on the shopping cart interface (1417), which includes one item from its own cart as well as three items selected by user A. User B can then clearly see all the items purchased through the group purchase. After selecting some or all items in the cart, the user can check if the total amount meets the minimum purchase requirement for a discount, thus realizing a convenient group purchase function.

[0432] In addition, the product information in the shared shopping cart can be updated in real time. For example, if the shopping cart of the device that initiated the migration (e.g., mobile phone A) has new products, the shared shopping cart of the destination device (e.g., mobile phone B) can also be refreshed in time.

[0433] Furthermore, when User B clicks the "Checkout" button, phone B can send a payment request to User A, including payment information such as the payment platform and payment amount. The payment amount can be calculated as: total amount of goods purchased by each user - (each user's total amount / total amount in the shared shopping cart) * discount value. Once payment is complete, the shared shopping cart is emptied, and the group-buying process ends.

[0434] Based on the method provided in the embodiments of this application, the shopping cart of one terminal device (the shopping cart can be regarded as an FA, for example, FA7) can be transferred to another terminal device. The items in the shopping carts of the two devices can be settled in one transaction to enjoy the discount, and then the payment can be made separately to save the trouble of transferring money between them. The operation steps are simple and quick, which can greatly improve the user experience of group shopping.

[0435] In some other embodiments, in a home environment, a user holds a mobile phone and a television, participating in a shopping festival promotion where purchases over 400 yuan receive a 100 yuan discount. In traditional shopping scenarios, this user frequently switches between product detail pages and the shopping cart page while selecting items on their mobile phone to view or modify the cart's contents. Based on the method provided in this application, the user can transfer the shopping cart to the television, browse and select products on their mobile phone, and view the cart's contents on the television at any time, eliminating the cumbersome process of repeatedly switching pages on the mobile phone and improving the user experience.

[0436] In some embodiments, a user selects items and adds them to their shopping cart on two mobile phones (phone A and phone C). The user can then simultaneously transfer both shopping carts from phone A and phone C to TV B. After phone A and phone C are authenticated with TV B, the group members on phone A can include (A's shopping app and B's shopping app); the group members on phone C can include (C's shopping app and B's shopping app); and the group members on TV B can include (A's shopping app, B's shopping app, and C's shopping app). The TV's group includes three members. That is, the TV's shopping app has performed application-level authentication with both phone A's and phone C's shopping apps, and can subsequently interoperate with both phone A's and phone C's shopping apps.

[0437] It should be understood that the shopping cart FA migration scenario based on near-field FA sharing capabilities is primarily applicable to networked environments, such as home and work environments. This solution also has value for scenarios where near-field networking (short-range networking) is not possible; for example, the internet can be used to achieve sharing and real-time synchronization of shopping cart content. Alternatively, e-commerce platforms can integrate internet-connected shopping carts into their own shopping applications, enabling sharing through their cloud services and accounts.

[0438] The following section describes the UI of the application-level authentication provided in this application embodiment, using email as an example, in a specific scenario.

[0439] Currently, the usage scenarios for office software such as email are changing. Besides traditional office and home scenarios, business trips, transportation, waiting, and outdoor activities have all become common use cases for office workers. While some vendors offer email clients on various mobile platforms, allowing users to access their email on multiple devices, seamless switching between mobile and non-mobile work modes is not seamless, resulting in a poor user experience. For example, when receiving an email notification on a smartwatch, replying on a phone or tablet requires opening the device, logging into email, finding the email, and then replying – a cumbersome process with a poor user experience. Apple's Handoff technology allows users to switch from one Apple device (e.g., Mac, iPhone, iPad, or Apple Watch) to another nearby Apple device to continue working without losing progress. However, this requires both devices to be logged into the same Apple ID, have the same email client pre-installed, and be logged into their respective email accounts. Furthermore, this technology cannot select the receiving device; for example, in a meeting room, if an email needs to be shown on a TV, Handoff cannot be achieved because the two devices are not logged into the same Apple ID.

[0440] This application provides a near-field cross-device email migration service for business professionals switching between mobile and non-mobile work scenarios, supporting one-click email migration between multiple terminal devices. For example, a smartwatch can instantly launch the email viewing interface on the mobile phone, allowing direct access to the email content. Similarly, for email drafts being edited on the mobile phone, this application also supports seamless one-click transfer to other devices (e.g., other mobile phones, tablets, or TVs) for continued work, providing an exceptional multi-device email collaboration experience. This application does not require devices to be on the same operating system, logged into the same account, or even have the email application installed on both devices, making it widely applicable.

[0441] For example, after a user receives and opens an email on phone A, such as... Figure 16A As shown, mobile phone A can display an email interface 1601 (the email interface 1601 can be considered as a FA, for example, FA8). In response to the user clicking the migration button 1602 on the email interface 1601 (the migration button is used to migrate (send) the email interface of mobile phone A to another device (e.g., a TV)), as follows... Figure 16BAs shown in (a), mobile phone A can display a pop-up window 1603, which can include nearby devices, including authenticated devices (such as Monica's Matepad) and unauthenticated devices (such as TVs, HUAWEI P20s, and Matebook X Pros). In response to the user clicking the control 1604 corresponding to the TV (an unauthenticated device), mobile phone A can send an authentication request message to the TV. Furthermore, as... Figure 16B As shown in (b), the message "Waiting for confirmation from the other end" can be displayed below the TV. Figure 16C As shown, the TV can display a pop-up window 1610, which includes the message "HUAWEI MATE30 (phone A) requests to migrate emails to this device, do you agree?". The pop-up window 1610 may also include a "disagree" button 1614 and an "agree" button 1615. In response to the user clicking the "agree" button 1613, as follows... Figure 16D As shown, the TV can display a pop-up window 1614, which may include a QR code image generated by the TV and a prompt message 1615 "Scan to authenticate, allow HUAWEI MATE30 to scan for authentication". At this time, the user of mobile phone A can scan the QR code image displayed on the TV. Afterwards, the TV can receive emails from mobile phone A (FA8), as shown... Figure 16E As shown, the TV can display an email interface 1616. Alternatively, in response to the user clicking the "Agree" button 1613, the TV can receive an email interface (FA8) from mobile phone A, as shown. Figure 16E As shown, the TV can display the email interface 1616.

[0442] The following uses an email application as an example to illustrate the specific implementation of the method provided in this application. The method provided in this application can be applied to two near-field devices, such as mobile phone A and a PC. Mobile phone A can be an Android system, and the PC can be a HarmonyOS system. Mobile phone A and PC are devices with different accounts. Figure 17A As shown, it includes:

[0443] 1701. The user clicks the "Migrate" button in the email application on mobile phone A.

[0444] Users open an email on their mobile phones and click the "Migrate" button on the editing interface.

[0445] 1702. Mobile phone A's email application initiates a migration request to mobile phone A's DM.

[0446] The migration request includes the initiating packet name (local email application packet name), the successor packet name (remote email application packet name), and the name of mobile phone A.

[0447] Steps 1703-1732 can be referred to the relevant descriptions of steps 903-932, and will not be repeated here. Some steps in steps 903-932 may be optional.

[0448] 1733. Mobile phone A's email application requests mobile phone A's DEF to migrate FA8.

[0449] The email application can send a connection request FA8 to the DEF of mobile phone A, carrying parameters of the current device and the target device (e.g., the identifiers of the current device and the target device).

[0450] 1734. Mobile phone A sends information related to FA8 to the TV's DMS via its DEF.

[0451] The relevant information for FA8 can include email content information, which may include the subject, body, attachments, etc.

[0452] 1735. The TV's DMS requests the TV's DEF connection service.

[0453] 1736. The TV screen displays FA8 when DEF is pulled up.

[0454] If the TV has an email client installed, the TV's DEF can detect whether the email client and account are logged in, prompting the user to log in to their email account. As a result, the email application can be launched and displayed as FA8, which shows the email interface migrated from mobile phone A.

[0455] If the TV does not have an email client installed, the TV's DEF can display FA8, which involves re-encoding and rearranging the FA8 code. This allows devices that are not logged in or do not have an email client installed to display email content, while preventing the leakage of private information such as email account details. Alternatively, if the TV's DEF does not support displaying FA8, an FA that can display FA8 can be downloaded and installed from the app store (this FA can be developed by a third-party application developer).

[0456] Furthermore, users can edit and reply to emails on the TV. The edited and replied email content can be transmitted back to mobile phone A via data communication, and then sent out based on mobile phone A's account information. This allows for one-click migration even if the TV does not have an email client installed or is not logged into an email account, improving user experience and increasing work efficiency. The migrated device can be used only for display and editing; the final email sending and receiving are handled by the migration initiator. The migrated device can only view emails actively pushed by the initiator, and the content is automatically destroyed after the process is complete, ensuring truly seamless email migration.

[0457] This application enables emails to flow between multiple devices without requiring login to the same device account or installing an email client and logging into an email account on all devices, greatly expanding the range of usable devices.

[0458] Additionally, if networking and authentication have already been completed between the two devices, the migration can be completed simply by clicking the migration button, making it more convenient and faster. For example, assuming that networking and authentication have already been completed between the watch, mobile phone, and PC, such as... Figure 17B As shown, after the user's watch receives an email notification, it can display the email notification interface 1701, prompting the user that there is an email. This is in response to the user clicking the view button 1702. Figure 17C As shown, the watch can directly launch the email viewing interface 1704 on the phone (the watch can send an email viewing request to the phone, and the phone can directly display the email viewing interface 1704), taking you directly to the email body. If a user needs to insert a document while editing a reply email on their phone, but the document is saved on their PC, the user can click the migration button 1705 on their phone to migrate the email to their PC, as shown below. Figure 17D As shown, the PC can display an email editing interface 1706. After inserting attachments in the email editing interface 1706, the user can click the migration button 1707 to migrate the email with attachments back to the mobile phone. In this way, the watch, mobile phone, and PC can work together conveniently and quickly, providing a high level of user experience.

[0459] This application utilizes near-field cross-device FA migration technology to enable one-click, seamless email migration between mobile and non-mobile work environments, significantly enhancing the multi-device collaborative work experience. Multi-device email migration is no longer limited by user accounts / email clients / email accounts, and can cover multiple devices within the same network, greatly expanding the application scenarios for email migration.

[0460] The above embodiment involves the receiver (passively migrated device, such as mobile phone B, TV, etc.) generating QR code information, and the initiator (actively migrated device, such as mobile phone A) parsing the QR code information of mobile phone B and joining the group created by mobile phone B for authentication.

[0461] In other embodiments, the initiator (actively migrating device, such as mobile phone A) can generate QR code information, and the receiver (passively migrating device, such as mobile phone B, TV, etc.) can authenticate based on the QR code information of mobile phone A.

[0462] For example, such as Figure 18AAs shown, User A can select migration option 1801 on the TV's karaoke interface 1800 (migration option 1801 is used to migrate (send) the TV's karaoke interface to another device (e.g., mobile phone B)). Optionally, User A can select the "migrate" option using a control device (e.g., remote control, mobile phone, etc.). Alternatively, if the TV is a touch device, User A can directly click the "migrate" option to select it. Figure 18B As shown, the TV can display a pop-up window 1802, which may include a QR code image generated by the TV and a prompt message 1803: "Scan to authenticate, allow other devices to scan and join my karaoke room." User B can use mobile phone B to scan the QR code image displayed on the TV (mobile phone B can use the scanning entry provided by a third-party application (e.g., a karaoke app), or it can use the system's built-in scanning entry). Then, as... Figure 18C As shown in (a), mobile phone B can display the karaoke interface 1804, and user A's avatar 1805 (the avatar of the karaoke application account logged in on the TV, or the avatar of the device account logged in on the TV (e.g., a Huawei account)) can be displayed below the lyrics, indicating that user A is currently singing a song. In response to the user clicking the song selection button 1806, as follows... Figure 18C As shown in (b), mobile phone B can display a pop-up window 1807 in response to the user clicking the chorus button 1808, as follows: Figure 18D As shown, user A's avatar 1811 (the avatar of the karaoke app account logged in on TV, or the avatar of the device account logged in on TV (e.g., Huawei account)) and user B's avatar 1810 (the avatar of the karaoke app account logged in on mobile phone B, or the avatar of the device account logged in on mobile phone B (e.g., Huawei account)) indicate that user B and user A sang the same song together.

[0463] The following uses a karaoke app as an example to illustrate the specific implementation of the application-level authentication method provided in this application embodiment. The method provided in this application embodiment can be applied to two near-field devices, such as a TV and mobile phone B, where the TV and mobile phone B are devices with different accounts (e.g., not the same Huawei account), and both the TV and mobile phone B have the karaoke app open. Figure 19 As shown, it includes:

[0464] 1901. The user selects the "Migrate" option on the karaoke interface on the TV.

[0465] For example, such as Figure 18AAs shown, the user can select migration option 1801 on the karaoke interface of the TV. (Migration option 1801 is used to migrate (send) a series of karaoke interfaces on mobile phone A (for example, the series of karaoke interfaces can be regarded as FA9) to other devices (for example, mobile phone B)). The migration option can also be called a sharing option, sending option, etc., which is not limited in this application.

[0466] Optionally, users can select the "Migrate" option using a control device (e.g., remote control, mobile phone, etc.). Alternatively, if the TV is a touch screen device, users can directly click the "Migrate" option to select it.

[0467] Optionally, users can further select the device to be migrated after selecting migration option 1801, such as selecting mobile phone B.

[0468] 1902. The TV's QR code recognition module sends a request to the TV's HarmonyOS tag management module to generate a QR code.

[0469] For example, the input parameters for generating a QR code include a Bundle object and an asynchronous callback. The Bundle object contains the source package name (the local karaoke application's package name) and the destination package name (the peer karaoke application's package name or the package name of the FA to be migrated) required by the karaoke service. The asynchronous callback contains the result of creating the QR code; if creation is successful, the QR code field can be retrieved; if creation fails, an error code can be retrieved.

[0470] 1903. The HarmonyOS tag management module of the TV requests the TV's device information from the TV's DM.

[0471] The device information of a television may include the television's name, network ID (netId), and device IP (deviceIP).

[0472] The Bundle object saves the device information obtained by the HarmonyOS tag management module to the device management, which is used to create groups and subsequently transmit information such as the client application package name to the other device through the channel.

[0473] 1904, DM generation PIN for television.

[0474] The TV's DM can generate a random PIN. The PIN can be a number of random digits. Optionally, the TV's DM can also generate a token, which can be a number of random strings.

[0475] 1905. Optional, the TV's DM calls the security management module to obtain the local device connection parameters.

[0476] The local device connection parameters may include the local network ID (netId), device IP (deviceIP), Bluetooth address (BtMac), and Wi-Fi address (Wi-FiPort). The netId is stored locally.

[0477] 1906a. The TV's DM calls the security management module to create a group.

[0478] The created group can be (local device name (i.e., TV, such as HUAWEI TV), local karaoke application package name, (peer device name can be left blank), peer karaoke application package name / FA package name to be migrated), the group is currently missing at least one member, and other devices are allowed to join as members.

[0479] 1906b. Optional, after the security management module successfully creates the group, it sends a callback notification to the DM on the TV.

[0480] 1907. After receiving the callback notification, the TV's DM sends the PIN, token, and TV device information to the HarmonyOS Tag Management Module.

[0481] The TV's DM stores the group name locally and packages the PIN, token, and TV device information into a Bundle type, which is then passed to the HarmonyOS tag management module via a device management callback.

[0482] 1908a The HarmonyOS tag management module generates a QR code image based on the PIN, token, and TV device information.

[0483] 1908b. The HarmonyOS label management module sends the QR code information to the QR code recognition module.

[0484] 1908c: The QR code recognition module generates and displays a QR code image based on the QR code information.

[0485] The QR code recognition module can utilize the TV's display function to show the QR code image on the TV screen.

[0486] 1909a. Mobile phone B opens the QR code recognition module and scans the QR code image displayed on the TV.

[0487] 1909b. The QR code recognition module of mobile phone B recognizes the QR code information (also known as QR code label) in the QR code image, launches the HarmonyOS label management module and passes in the QR code information.

[0488] 1909c, the HarmonyOS tag management module parses QR code information and extracts the fields (strings) stored in the QR code information.

[0489] 1910. The HarmonyOS tag management module of mobile phone B sends an authentication request message to the DM of mobile phone B and registers a callback.

[0490] The authentication request message includes fields parsed from the QR code information.

[0491] 1911a. Mobile phone B's DM processes the authentication request message.

[0492] The DM of mobile phone B can split the fields included in the authentication request message to obtain the deviceIp and Wi-FiPort fields, and call the communication module interface to create a communication channel between mobile phone B and TV based on the deviceIp and Wi-FiPort.

[0493] 1911b. Optionally, the DM of mobile phone B sends an authentication request message to the DM of television via the communication module.

[0494] Mobile phone B's DM can set the token as the requestId parameter. Understandably, mobile phone B's DM can also send information such as mobile phone B's device ID to the TV's DM via the communication module.

[0495] 1912. Optional, DM verification token for the TV.

[0496] The TV's DM extracts a token based on the requestId parameter, compares the extracted token with the token stored on the local end, and if they match, agrees to establish a secure communication channel between the two devices (i.e., the TV and mobile phone B). The secure communication channel can be an encrypted communication channel. Group information is sent to mobile phone B through this secure communication channel. The group information includes the TV's network ID, the group ID (groupId), group type (groupType), and group name (groupName) of the group created by the TV.

[0497] 1913. Mobile phone B's DM receives and saves group information transmitted by the television.

[0498] 1914. Mobile phone B's DM calls the security management module to obtain information on all groups with trusted relationships with the peer device, and then uses the security management module to traverse and query whether the TV's karaoke application has access permissions to the groups.

[0499] If permissions are not granted, device management adds the device to the specified group via HiChain. Successful group joining triggers the onFinish callback on both devices. In this method, HiChain is called to write the packet name information of the other end, which is used for subsequent querying of application-level trusted relationships. If permissions are already granted, step 1915 is executed.

[0500] 1915. Mobile phone B's DMS receives relevant information from the TV's DEF FA9.

[0501] The relevant information for FA9 may include song information from karaoke, which may include at least one of the following: song title (e.g., Red Bean), lyrics, audio information, and video information.

[0502] Optionally, operations such as selecting and switching songs on mobile phone B, as well as playlist information, will be simultaneously sent to the TV via a secure communication channel, allowing control over music playback on the TV.

[0503] In some embodiments, if one of the TV and mobile phone B is logged into an account (e.g., a Huawei account) while the other is not, the TV and mobile phone B can perform steps 1901-1915 as described above. This is to perform verification (i.e., device-level authentication) during FA migration between the TV and mobile phone B, thereby ensuring the security of data between the devices.

[0504] In some embodiments, if neither the TV nor mobile phone B has a login account (e.g., a Huawei account), the TV and mobile phone B can perform steps 1901-1915 as described above. This is to perform verification during FA migration between the TV and mobile phone B, ensuring the security of data between the devices.

[0505] In some embodiments, if the TV and mobile phone B are logged into the same account (e.g., a Huawei account), the TV and mobile phone B can perform steps 1901-1915 as described above. This is to verify the data during FA migration between the TV and mobile phone B, further ensuring the security of data between the devices (e.g., information related to FA9).

[0506] It should be noted that some steps in steps 1901-1915 above are optional, meaning they are not essential technical features of the device-level authentication scheme. For example, step 1905 may be optional, such as the TV's DM obtaining its own device connection parameters from other modules. Another example is step 1906b, which may not send a callback notification to the TV's DM after the security management module successfully creates the group. Yet another example is steps 1911b and 1912, which may not require the mobile phone B's DM to send a token to the TV's DM, and the TV's DM does not need to verify the token.

[0507] Of course, mobile phone C (with a different device account than mobile phone B, for example, not logged into the same Huawei account) can also join the group created by the TV by scanning the QR code (see steps 1809-1818 for details). In this way, multiple devices can quickly launch FA9 by scanning the QR code, without pre-installation, and use the service immediately; and after multiple devices scan the code, they can establish a trust circle for information exchange, such as the ability to refresh and synchronize playlists and other information across multiple devices in real time. Multiple devices (e.g., mobile phone B or mobile phone C) can collaboratively control the host terminal (e.g., the TV), achieving multi-device collaborative control and realizing a true mobile KTV experience.

[0508] In some other embodiments, the initiator (active migration device, such as a TV) can generate a QR code image (e.g., execute steps 1901-1908c), and one or more receivers (passively migration devices, such as mobile phone B and mobile phone C) can authenticate based on the TV's QR code image (e.g., execute steps 1909a-1914). After authentication, the receiver can migrate shopping carts, live streams, emails, etc. to the TV, thereby achieving the effect of sharing shopping carts, live streams, emails, and other information among multiple devices (e.g., TV, mobile phone B, and mobile phone C). The shopping cart product information, live video streams, email content, and other information among multiple devices can be refreshed and synchronized in real time. Multiple devices (e.g., TV, mobile phone B, and mobile phone C) can collaboratively control the chairman terminal (e.g., TV) to achieve multi-device collaborative control and realize a true collaborative shopping, live streaming, or email editing experience.

[0509] It should be noted that, for the various UI interfaces provided in the embodiments of this application, such as those mentioned above... Figures 5A-5F , Figures 6A-6C , Figures 8A-8D , Figures 10A-10B , Figures 12A-12E , Figures 14A-14F , Figures 16A-16E , Figures 18A-18C The UI designs shown are for illustrative purposes only and do not specify the position, name, or shape of any elements within the UI (e.g., buttons, icons, text). For example, Figure 8A Button 802 (originally located in the upper left corner of interface 801) can also be located in the lower right corner of interface 801, and the text displayed on button 802 can be "Share," "Transfer," etc. In some embodiments, elements from different UI interfaces can be rearranged and combined into the same UI interface. For example, Figure 5A Button 502 in (a) can be replaced with Figure 5AButtons 503 and 504 in (b) are shown. This application embodiment does not limit the jump relationship between UI interfaces. For example, if this application embodiment describes a jump from a first UI interface to a second UI interface, it is only an illustration of one jump relationship between the first and second interfaces, and does not limit other jump relationships. For example, as... Figure 5C As shown in (b), in response to the user clicking the binding button 509, as Figure 5D As shown in (b) above, the mobile phone can directly display the scanning interface 512. This application embodiment does not limit the jump method between UI interfaces (for example, if this application embodiment describes clicking the first button on the first UI interface to jump to the second UI, it is only an illustration of one jump method between the first and second interfaces, and other jump methods are not limited). For example, as... Figure 8A As shown, in response to user-specific gestures (e.g., three-finger swipe down, knuckle tap, etc.), such as Figure 8B As shown in (a), the mobile phone can display pop-up 803.

[0510] This application provides a function migration method, such as... Figure 20 As shown, it includes:

[0511] 2001. The first device sends a first request to the second device.

[0512] The first request carries the identifier of the first device, the identifier of the first application, and the identifier of the second application. The first request can be the authentication request message in the above embodiments, and the relevant description will not be repeated here.

[0513] In one possible implementation, in response to a user's first operation on a first application on a first device, a first pop-up is displayed, the first pop-up including an identifier of a device on the same network as the first device; in response to a user's second operation of selecting a second device in the first pop-up, a first request is sent to the second device. For example, the first pop-up here could be as follows: Figure 5C The pop-up window 508 shown in (b) or as shown in the example Figure 8B The pop-up window 803 shown in (a) is an example.

[0514] The devices located on the same network as the first device include trusted devices and untrusted devices. Trusted devices include devices logged into the same account as the first device, devices that have performed device-level authentication with the first device, or devices that have performed application-level authentication with the first device's first application. Untrusted devices include devices not logged into the same account as the first device, devices that have not performed device-level authentication with the first device, or devices that have not performed application-level authentication with the first device's first application. The first device can be mobile phone A in the above embodiments.

[0515] 2002. The second device receives the first request from the first device.

[0516] After receiving the first request, the first device can display a first pop-up window, which prompts the user whether to agree to add the first application of the first device to the first group; and receives the user's consent instruction. For example, the first pop-up window here could be as follows: Figure 6A The pop-up window 531 shown in (a) can be, or it can be, as shown in Figure 8C The pop-up box 812 shown in (a) is an example.

[0517] The second device may be mobile phone B in the above embodiment.

[0518] 2003. The second device creates the first group, whose members include the second application of the second device.

[0519] Before the second device creates the first group, it can be determined that the second device does not currently have a second group based on the identifier of the first device. The members of the second group include both the first device and the second device.

[0520] Before the second device creates the first group, it can determine that the second device does not currently have a third group based on the identifier of the first device, the identifier of the first application, and the identifier of the second application. The members of the third group include the first application of the first device and the second application of the second device.

[0521] 2004. The second device sends a first response to the first device.

[0522] The first response may include a personal identification number (PIN) corresponding to the first group and / or communication connection information of the second device.

[0523] 2005, the first device receives the first response from the second device.

[0524] The first response is used to instruct the second device to create a first group, the members of which include the second application of the second device.

[0525] 2006, the first device sends a second request to the second device.

[0526] The second request is used to apply to add the first application of the first device to the first group.

[0527] In one possible implementation, the second device can display a QR code image, which includes a Personal Identification Number (PIN) corresponding to the first group and / or the communication connection information of the second device. The first device can scan the QR code image displayed by the second device to obtain the PIN corresponding to the first group and / or the communication connection information of the second device. The first device can then send a second request to the second device based on the PIN and / or the communication connection information of the second device.

[0528] Optionally, the first device may send a second request to the second device based on the PIN and / or the communication connection information of the second device.

[0529] 2007. The second device receives a second request from the first device.

[0530] The second device can add the first application of the first device to the first group according to the second request.

[0531] Optionally, the second device may send a second response to the first device, and the first device may receive the second response, wherein the second response is used to indicate that the first application of the first device has joined the first group.

[0532] 2008. The first device migrates a first function from a first application to a second application on a second device. The first function includes one or more UIs.

[0533] In one possible implementation, migrating the first function in the first application to the second application on the second device includes: sending business information of the first function to the second device; when the first application is a live streaming application, the business information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live streaming room on the first device; or when the first application is a camera application, the business information of the first function includes the camera preview screen or the menu bar information of the camera interface; or when the first application is a karaoke application, the business information of the first function includes at least one of the song title, lyrics, audio information of the song, video information of the song, and the control interface of the song; or when the first application is a shopping application, the business information of the first function includes the product information in the shopping cart; or when the first application is an email application, the business information of the first function includes at least one of the email subject, body, and attachments.

[0534] Optionally, the first device may create a second group, wherein the members of the second group include a first application of the first device and a second application of the second device.

[0535] 2009. The second device receives a first function from the first application migrated by the first device, wherein the first function includes one or more UIs.

[0536] Figure 20 In the embodiments, the first device or the second device can be mobile phone A and mobile phone B, as described in the foregoing embodiments. Figure 20 For parts not described in detail in the embodiments, please refer to the foregoing embodiments, and they will not be repeated here.

[0537] This application provides a function migration method, such as... Figure 21 As shown, it includes:

[0538] 2101. The first device sends a first request to the second device.

[0539] The first request carries the identifier of the first device.

[0540] 2102. The second device receives the first request from the first device.

[0541] 2103. The second device sends a first response to the first device.

[0542] The first response is used to indicate the creation of a first group by the second device, the members of which include the second device.

[0543] 2104. The first device receives the first response from the second device.

[0544] 2105. The first device sends a second request to the second device, the second request being used to request that the first device be added to the first group.

[0545] 2106. The first device migrates a first function from a first application to a second device. The first application is any application in the first device, and the first function includes one or more graphical user interfaces (UIs).

[0546] Figure 21 In the embodiments, the first device or the second device can be mobile phone A and mobile phone B, etc., as described in the foregoing embodiments, and the first request can be an authentication request message, etc., as described in the foregoing embodiments. Figure 21 For parts not described in detail in the embodiments, please refer to the foregoing embodiments, and they will not be repeated here.

[0547] This application provides a function migration method, such as... Figure 22 As shown, it includes:

[0548] 2201. The first device creates the first group, and the members of the first group include the first application of the first device.

[0549] 2202. The second device sends a first request to the first device. The first request is used to request that the second application of the second device be added to a first group created by the first device. The members of the first group include the first application of the first device and the second application of the second device.

[0550] 2203. The first device receives a first request from the second device, the first request being used to request that the second application of the second device be added to the first group.

[0551] 2204. The first device adds the second application of the second device to the first group.

[0552] 2205. The first device migrates a first function from a first application to a second application on a second device, the second function including one or more UIs.

[0553] 2206. The second device receives a first function from the first device in the first application, wherein the first function includes one or more UIs.

[0554] Figure 22 In the embodiments, the first device or the second device can be mobile phone A and mobile phone B, etc., as described in the foregoing embodiments, and the first request can be an authentication request message, etc., as described in the foregoing embodiments. Figure 22 For parts not described in detail in the embodiments, please refer to the foregoing embodiments, and they will not be repeated here.

[0555] Other embodiments of this application provide a first device or a second device, which may be as follows: Figure 3 The illustrated electronic device 200 may include a communication module, a memory, and one or more processors. The communication module and memory are coupled to the processors. The memory stores computer program code, including computer instructions.

[0556] Another embodiment of this application provides a chip system, such as Figure 23 As shown, the chip system includes at least one processor 2301 and at least one interface circuit 2302. The processor 2301 and the interface circuit 2302 are interconnected via lines. For example, the interface circuit 2302 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit 2302 can be used to send signals to other devices (e.g., the processor 2301).

[0557] For example, interface circuit 2302 can read instructions stored in the memory of an electronic device and send the instructions to processor 2301. When the instructions are executed by processor 2301, the first device / second device (electronic device 230 as shown in FIG. 6) can perform the various steps in the above embodiments.

[0558] For example, interface circuit 2302 can read instructions stored in the server's memory and send those instructions to processor 2301. When the instructions are executed by processor 2301, the server can perform the steps described in the above embodiments.

[0559] Of course, the chip system may also include other discrete components, and this application embodiment does not specifically limit this.

[0560] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0561] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus 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 device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0562] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0563] Furthermore, the functional units in the various embodiments of this application 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.

[0564] 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 readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0565] 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 function transfer method, applied to a first device, characterized in that, include: Create a first group, whose members include the first application of the first device; A first request is received from the second device, the first request being used to request that a second application of the second device be added to the first group; the first request carries the identifier of the second device, the identifier of the first application, and the identifier of the second application; the first group is a private group, the private group being a group established at the granularity of devices and applications; the first group is set to be permanently valid or valid for a preset time; Add the second application of the second device to the first group; Migrate a first function from the first application to the second application on the second device, wherein the first function includes one or more graphical user interfaces (UIs). When the business information of the first function in the first application of the first device changes, the first function in the second application of the second device is refreshed and displayed in real time.

2. The method according to claim 1, characterized in that, Before receiving the first request from the second device, the method further includes: Display a first identifier for indicating the first group, wherein the first request corresponds to the first identifier.

3. The method according to claim 2, characterized in that, The first identifier includes a QR code image; the first identifier includes a personal identification number (PIN). After receiving the first request from the second device, the method further includes: It is determined that the first request carries the PIN; The second application of the second device is determined to be added to the first group.

4. The method according to any one of claims 1-3, characterized in that, The migration of the first function from the first application to the second application on the second device includes: Send the service information of the first function to the second device; When the first application is a live streaming application, the business information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live streaming room of the first device; or When the first application is a camera application, the business information of the first function includes the menu bar information of the shooting preview screen or the shooting interface; or When the first application is a karaoke application, the business information of the first function includes at least one of the following: song title, lyrics, audio information, video information, and control interface; or When the first application is a shopping application, the business information of the first function includes product information in the shopping cart; or When the first application is an email application, the business information of the first function includes at least one of the email subject, body, and attachments.

5. A function transfer method, applied to a second device, characterized in that, include: A first request is sent to the first device, which requests the addition of the second application of the second device to a first group created by the first device. The members of the first group include the first application of the first device and the second application of the second device. The first group is a private group, which refers to a group established at the device and application level. The first group is set to be permanently valid or valid for a preset time. The first function is received from the first device in the first application, wherein the first function includes one or more graphical user interfaces (UIs).

6. The method according to claim 5, characterized in that, Before sending the first request to the first device, the method further includes: The scan is used to indicate a first identifier of the first group, wherein the first request corresponds to the first identifier.

7. The method according to claim 6, characterized in that, The first identifier includes a QR code image; the first identifier includes a personal identification number (PIN). Sending the first request to the first device includes: Send the first request to the first device, the first request carrying the PIN.

8. The method according to any one of claims 5-7, characterized in that, The step of receiving the first function from the first device in the first application includes: Receive service information for the first function from the first device; When the first application is a live streaming application, the business information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live streaming room of the first device; or When the first application is a camera application, the business information of the first function includes the menu bar information of the shooting preview screen or the shooting interface; or When the first application is a karaoke application, the business information of the first function includes at least one of the following: song title, lyrics, audio information, video information, and control interface; or When the first application is a shopping application, the business information of the first function includes product information in the shopping cart; or When the first application is an email application, the business information of the first function includes at least one of the email subject, body, and attachments.

9. A terminal, said terminal being a first device, characterized in that, include: The system comprises a processor, a near-field communication module, a memory, and one or more programs; wherein the processor and the memory are coupled, and the processor is connected to the near-field communication module; the one or more programs are stored in the memory, and the one or more programs include instructions for performing the method as described in any one of claims 1-4.

10. A terminal, said terminal being a second device, characterized in that, include: The system comprises a processor, a near-field communication module, a memory, and one or more programs; wherein the processor and the memory are coupled, and the processor is connected to the near-field communication module; the one or more programs are stored in the memory, and the one or more programs include instructions for performing the method as described in any one of claims 5-8.

11. A computer-readable medium, characterized in that, For storing one or more programs, wherein the one or more programs are configured to be executed by the one or more processors, the one or more programs including instructions for performing the method as described in any one of claims 1-4 or 5-8.

Images