Account login method and related device

Abstract

An account login method and a related device, which are used for implementing password-free login for an account, and can simplify user operation steps required in a password-free login process, thereby improving convenience. For example, in response to the approach of a second device, a first device displays a code scanning interface, wherein the second device has not logged in to a first account; the first device scans, by means of the code scanning interface, a first graphic displayed by the second device, so as to establish a near-field communication connection with the second device; and the first device sends first data to the second device by means of the near-field communication connection, so that the second device logs in to the first account on the basis of the first data, wherein the first data comprises a first login credential, the first login credential is an identity credential issued to the first device by a server corresponding to the first account, and the first login credential comprises a token.

Description

An account login method and related devices

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202410799669.5, filed on June 20, 2024, entitled "An Account Login Method and Related Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of terminal technology, and in particular to an account login method and related equipment. Background Technology

[0004] To protect privacy, electronic devices can have accounts set up for their operating systems, applications, and files, along with corresponding login passwords. Users can then log in using the password to view relevant information within their account. However, this method requires users to remember both the username and password, placing a high demand on them. Furthermore, this becomes difficult to remember when dealing with a large number of accounts, negatively impacting the user experience. Summary of the Invention

[0005] This application provides an account login method and related equipment for enabling passwordless login, and simplifies the user operation steps required for the passwordless login process, thereby improving convenience.

[0006] Firstly, a method for account login is provided, which can be applied to a communication system. The communication system includes a first device and a second device. The operating system of the first device is currently logged into a first account. For example, the second device displays a first interface, which is used for account login. In response to detecting the second device's proximity, the first device displays a QR code scanning interface. In response to detecting the first device's proximity, the second device displays a first graphic, which is used to establish near-field communication (NFC). The first device scans the first graphic through the QR code scanning interface to establish a NFC connection with the second device. The first device sends first data to the second device through the NFC connection, the first data including the first device's first login credentials. The second device logs into the first account based on the first login credentials.

[0007] In this embodiment, when the second device displays the first interface, the two devices can automatically pull up their respective interfaces when they are close to each other. For example, the first device pulls up the QR code scanning interface, and the second device pulls up the first graphic. This process eliminates the need for users to perform cumbersome operations on both devices, simplifying the user experience and improving convenience. Furthermore, the automatic pull-up of the corresponding interface when the second device displays the first interface can prevent accidental triggering; for example, if the second device displays an interface other than the first interface, the interface will not be pulled up when the two devices are close together. In addition, after establishing a near-field communication connection between the first and second devices, the first device can send its first login credential to the second device via the near-field communication connection, enabling the second device to log in to the first account using the first login credential. During this process, the first device does not transmit the account information and password of the first account to the second device, preventing password leakage. Moreover, the first login credential has an expiration date; if stolen, it becomes unusable after its expiration, thus mitigating the risk of continuous data leakage.

[0008] In one possible design, the first interface includes any of the following: the first interface is an interface for logging into an account in the settings application of the second device; the first interface is an interface of the second device during the OOBE process; or the first interface is an interface for migrating data from other devices.

[0009] In this embodiment, when the second device displays the first interface, the corresponding interface can be automatically pulled up when the two devices are close together, which can avoid accidental triggering to some extent. Moreover, the first interface may be an interface used in various scenarios. For example, the first interface could be an interface for logging into an account in the settings application of the second device, an interface used during the OOBE process on the second device, or an interface used for migrating data from other devices. Therefore, in account login, OOBE, or data migration scenarios, the corresponding interface can be automatically pulled up when the two devices are close together. Furthermore, after the two devices pull up the interface, a near-field communication connection is established by scanning a QR code. Then, based on the near-field communication connection, the needs for account login, OOBE, and data migration are met, achieving convenient account login, OOBE, and data migration, and improving the user experience.

[0010] In one possible design, the first device is currently in a no-network state.

[0011] In this embodiment of the application, when the first device is in a network-free state, it can assist the second device in logging into the first account, breaking the limitation of traditional technology that the old device (i.e., the first device) must be connected to the network to assist the new device (i.e., the second device) in logging into the account.

[0012] In one possible design, before the first device displays a QR code scanning interface in response to detecting the proximity of the second device, the method further includes: the first device displaying a lock screen, a black screen, a desktop, a negative one screen, or an application interface.

[0013] In this embodiment of the application, when the second device displays the first interface, the two devices can automatically pull up the corresponding interface when they are close together. During this process, the interface of the first device is not limited, and the user does not need to open a specific interface on the first device, thus saving user operation.

[0014] In one possible design, detecting the proximity of the second device includes: detecting that the distance between the first device and the second device is less than a first distance, and / or receiving a request signal broadcast by the second device, the request signal being a short-range communication signal; detecting the proximity of the first device includes: detecting that the distance between the first device and the second device is less than a second distance, and / or receiving an agreement signal returned by the first device.

[0015] In this embodiment, the interface is activated when the two devices are close together. This can be achieved by detecting the proximity of the two devices or by receiving a short-range communication signal from the other device. In short, this method eliminates the need for users to perform cumbersome operations on both the first and second devices to open the scanning interface and the first graphic, simplifying the user's operation and improving convenience.

[0016] In one possible design, the first device displays a QR code scanning interface in response to detecting the second device approaching, including: the first device displays a prompt message in response to detecting the second device approaching, the prompt message being used to prompt whether to agree to the second device logging into the first account; and the first device displays the QR code scanning interface when it receives the agreement.

[0017] In this embodiment of the application, when the first device detects that the second device is approaching, it can first output a prompt message, and then pull up the scanning interface after obtaining the user's consent, so as to avoid interrupting the user's current business by directly pulling up the scanning interface.

[0018] In one possible design, the method further includes: the first device sending an agreement instruction to the second device, the agreement instruction indicating consent for the second device to log in to the first account; the second device displaying a first graphic in response to detecting the first device approaching, including: the second device displaying the first graphic upon receiving the agreement instruction.

[0019] In this embodiment, after the user of the first device agrees, the first device sends an agreement instruction to the second device, and the second device pulls up the first graphic. This avoids the second device directly pulling up the first graphic before obtaining the user's consent, which would affect the user experience.

[0020] In one possible design, the first login credential is a token.

[0021] In this embodiment, the first device can send its first login credential (token) to the second device via a near-field communication connection, enabling the second device to log in to the first account using the first login credential. The token has an expiration date; thus, even if the token is stolen, it cannot be used once it expires, which can, to some extent, prevent the continuous leakage of data.

[0022] In one possible design, the first data does not contain the login password for the first account, and / or the first data is encrypted using a first key, which is a key agreed upon by the first device and the server corresponding to the first account.

[0023] In this embodiment, the first device can send its first login token to the second device via a near-field communication connection, enabling the second device to log in to the first account using the first login token. During this process, the first device does not transmit the account information or password of the first account to the second device, thus preventing password leakage. Furthermore, the first data is encrypted, further ensuring the security of the first login token.

[0024] In one possible design, the first device displays a QR code scanning interface in response to detecting the second device approaching, including: the first device displaying N accounts of the first device, where N is a positive integer, in response to detecting the second device approaching; and the first device displaying the QR code scanning interface when it receives an operation to select the first account.

[0025] In this embodiment, the first device can display multiple accounts, and the user of the first device can select one account to allow the second device to log in to that account, resulting in a better user experience.

[0026] In one possible design, the second device logs into the first account based on the first login credential, including: the second device sending a login request to the server corresponding to the first account, the login request being used to request login to the first account, the login request including the first login credential; and the second device receiving a second login credential sent by the server.

[0027] In this embodiment, the second device uses the first device's first login credential to log in to the first account. From the perspective of the first account's server, this constitutes the second device acting as a proxy for the first device to log in to the first account. During this process, the first device does not transmit the account information and password of the first account to the second device, thus preventing password leakage.

[0028] In one possible design, before the second device receives the second login credential sent by the server, the method further includes: the second device receiving a prompt message sent by the server, the prompt message indicating that the first device needs to connect to the network for authentication; the second device sending the prompt message to the first device via the near-field communication connection; the first device outputting the prompt message; and after connecting to the network, the first device sending authentication information to the server, the authentication information indicating that the second device is authorized to log in to the first account.

[0029] In this embodiment, the second device uses the first device's first login credential to log in to the first account. From the server's perspective, the first login credential originally issued to the first device is now being used by the second device. The server would consider this as the second device stealing the first device's first login credential, and therefore, the server can request the first device to perform online authentication. Since the first device is offline, the server can send a notification message to the second device, which in turn sends a notification message to the first device, reminding the first device to perform online authentication and ensuring account login security.

[0030] In one possible design, when the first interface is an interface for migrating data from other devices, the method further includes: the first device sending second data to the second device via the near-field communication connection, the second data including user data stored in the first device; and the second device storing the second data.

[0031] In this embodiment of the application, after the first device and the second device approach the pull-up interface, they establish a near-field communication connection by scanning a QR code. Then, data migration is performed through the near-field communication connection to improve the efficiency of data transmission.

[0032] Secondly, an account login method is also provided, applied to a first device, wherein the operating system of the first device is currently logged into a first account. The method includes: the first device displaying a QR code scanning interface in response to detecting the approach of a second device; the first device scanning a first graphic on the second device through the QR code scanning interface to establish a near-field communication connection with the second device; and the first device sending first data to the second device through the near-field communication connection, wherein the first data includes a first login credential of the first device, and the first login credential is used by the second device to log into the first account.

[0033] In one possible design, the first device is currently in a no-network state.

[0034] In one possible design, before the first device displays a QR code scanning interface in response to detecting the proximity of the second device, the method further includes: the first device displaying a lock screen, a black screen, a desktop, a negative one screen, or an application interface.

[0035] In one possible design, detecting the proximity of the second device includes: detecting that the distance between the first device and the second device is less than a first distance, and / or receiving a request signal broadcast by the second device, the request signal being a short-range communication signal.

[0036] In one possible design, the first device displays a QR code scanning interface in response to detecting the second device approaching, including: the first device displays a prompt message in response to detecting the second device approaching, the prompt message being used to prompt whether to agree to the second device logging into the first account; and the first device displays the QR code scanning interface when it receives the agreement.

[0037] In one possible design, the first login credential is a token.

[0038] In one possible design, the first data does not contain the login password for the first account, and / or the first data is encrypted using a first key, which is a key agreed upon by the first device and the server corresponding to the first account.

[0039] In one possible design, the first device displays a QR code scanning interface in response to detecting the second device approaching, including: the first device displaying N accounts of the first device, where N is a positive integer, in response to detecting the second device approaching; and the first device displaying the QR code scanning interface when it receives an operation to select the first account.

[0040] In one possible design, the method further includes: the first device receiving a prompt message sent by the second device via the near-field communication connection, the prompt message indicating that the first device needs to be authenticated online; the first device outputting the prompt message; and after connecting to the network, the first device sending authentication information to the server corresponding to the first account, the authentication information indicating that the second device is authorized to log in to the first account.

[0041] In one possible design, when the first interface is an interface for migrating data from other devices, the method further includes: the first device sending second data to the second device via the near-field communication connection, the second data including user data stored in the first device.

[0042] Thirdly, an account login method is also provided, applied to a second device. The method includes: the second device displaying a first interface, the first interface being an interface for logging into an account; the second device displaying a first graphic in response to detecting the proximity of a first device, the first graphic being used to establish near-field communication; the second device establishing a near-field communication connection with the first device in response to the first device scanning the first graphic; the second device receiving first data sent by the first device through the near-field communication connection, the first data including a first login credential of the first device; and the second device logging into a first account based on the first login credential.

[0043] In one possible design, the first interface includes any of the following: the first interface is an interface for logging into an account in the settings application of the second device; the first interface is an interface of the second device during the OOBE process; or the first interface is an interface for migrating data from other devices.

[0044] In one possible design, the first device is currently in a no-network state.

[0045] In one possible design, before the first device displays a QR code scanning interface in response to detecting the proximity of the second device, the method further includes: the first device displaying a lock screen, a black screen, a desktop, a negative one screen, or an application interface.

[0046] In one possible design, detecting the proximity of the first device includes: detecting that the distance between the first device and the second device is less than a second distance, and / or receiving an agreement signal returned by the first device.

[0047] In one possible design, before the second device displays the first graphic in response to detecting the first device's proximity, the method further includes: when the second device receives an consent instruction sent by the first device, displaying the first graphic, the consent instruction indicating consent for the second device to log in to the first account.

[0048] In one possible design, the first login credential is a token.

[0049] In one possible design, the first data does not contain the login password for the first account, and / or the first data is encrypted using a first key, which is a key agreed upon by the first device and the server corresponding to the first account.

[0050] In one possible design, the second device logs into the first account based on the first login credential, including: the second device sending a login request to the server corresponding to the first account, the login request being used to request login to the first account, the login request including the first login credential; and the second device receiving a second login credential sent by the server.

[0051] In one possible design, before the second device receives the second login credential sent by the server, the method further includes: the second device receiving a prompt message sent by the server, the prompt message indicating that the first device needs to connect to the network for authentication; and the second device sending the prompt message to the first device via the near-field communication connection.

[0052] In one possible design, when the first interface is an interface for migrating data from other devices, the method further includes: the second device receiving second data sent by the first device via the near-field communication connection, the second data including user data stored in the first device; and the second device storing the second data.

[0053] Fourthly, an account login method is also provided, applied to a server, the method comprising: receiving a login request from a second device, the login request being used to request login to a first account, the login request including a first login credential of the first device; and sending a second login credential to the second device.

[0054] In this embodiment, the server can enable proxy login for the same account across different devices. For example, a second device uses the first device's first login credentials to log in to the first account. From the server's perspective, this is the second device acting as a proxy for the first device to log in to the first account. It does not require the second device to obtain the first account's password to log in, thus achieving the efficiency and convenience of passwordless login.

[0055] In one possible design, the login request includes a first code value; before sending the second login credential to the second device, the method further includes: determining that the first code value is a code value that the server has previously sent to the second device, and that the first code value is valid.

[0056] In this embodiment of the application, the server can verify the second device (e.g., verify the first code value), and only after the verification is successful will it issue a second login credential to the second device to ensure the security of the account.

[0057] In one possible design, before sending the second login credential to the second device, the method further includes: sending a prompt message to the second device, the prompt message indicating that the first device needs to be connected to the network for authentication; and receiving authentication information sent by the first device, the authentication information indicating that the second device is authorized to log in to the first account.

[0058] In this embodiment, the second device uses the first device's first login credential to log in to the first account. From the server's perspective, the first login credential originally issued to the first device is now being used by the second device. The server would consider this as the second device having stolen the first device's first login credential. Therefore, the server can request the first device to perform online authentication. For example, the server can send a notification to the second device to remind it that online authentication by the first device is required, thus ensuring account security.

[0059] Fifthly, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as described in the second or third aspect above.

[0060] Sixthly, an electronic device is also provided, comprising a module / unit for performing the method corresponding to any one of the designs in the second or third aspects described above. These modules / units may be implemented in hardware or by hardware executing corresponding software.

[0061] In a seventh aspect, a server is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method described in the fourth aspect above.

[0062] Eighthly, a server is also provided, including modules / units for performing the methods corresponding to any of the designs in the fourth aspect above. These modules / units can be implemented in hardware or by executing corresponding software in hardware.

[0063] A ninth aspect also provides a chip including a processor and an interface; the processor is configured to read instructions via the interface to perform the method described in any one of the first, second, third, or fourth aspects described above.

[0064] In a tenth aspect, a chip system is also provided, the chip system including a processing circuit and a storage medium, the storage medium storing instructions; when the instructions are executed by the processing circuit, they implement the method described in any one of the first, second, third, or fourth aspects above.

[0065] Eleventhly, a communication system is also provided, comprising: a first device for performing the method as described in the second aspect above; and a second device for performing the method as described in the third aspect above.

[0066] In a twelfth aspect, a communication system is also provided, comprising: a first device for performing the method as described in the second aspect above; a second device for performing the method as described in the third aspect above; and a server for performing the method as described in the fourth aspect above.

[0067] In a thirteenth aspect, a computer-readable storage medium is also provided, the computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any one of the first, second, third, or fourth aspects above.

[0068] In a fourteenth aspect, a computer program product is also provided, the computer program product comprising a computer program that, when run on a computer, causes the computer to perform the method as described in any one of the first, second, third, or fourth aspects above.

[0069] The beneficial effects of the design in any of the second to fourteenth aspects mentioned above can be referred to the beneficial effects of the corresponding design in the first aspect mentioned above, and this application will not elaborate on them one by one. Attached Figure Description

[0070] Figure 1 is a schematic diagram of a communication system provided in an embodiment of this application;

[0071] Figure 2 is a schematic diagram of QR code login provided in an embodiment of this application;

[0072] Figures 3A and 3B are two example diagrams of QR code login provided in an embodiment of this application;

[0073] Figure 4 is another schematic diagram of scanning login provided in an embodiment of this application;

[0074] Figures 5A to 5F are schematic diagrams of two devices approaching a pull-up interface according to an embodiment of this application;

[0075] Figures 6A and 6B are another schematic diagram of two devices approaching the pull-up interface according to an embodiment of this application;

[0076] Figures 7A and 7B are another schematic diagram of two devices approaching the pull-up interface according to an embodiment of this application;

[0077] Figure 8 is a schematic flowchart of the first method for account login provided in an embodiment of this application;

[0078] Figure 9 is a schematic diagram of a second type of account login method provided in an embodiment of this application;

[0079] Figure 10 is a schematic diagram of a third type of account login method provided in an embodiment of this application;

[0080] Figures 11A and 11B are schematic diagrams of the fourth process of the account login method provided in an embodiment of this application;

[0081] Figure 12A is a schematic diagram of the fifth type of account login method provided in an embodiment of this application;

[0082] Figure 12B is a schematic diagram of the sixth type of account login method provided in an embodiment of this application;

[0083] Figure 13 is a schematic diagram of an electronic device provided in an embodiment of this application;

[0084] Figure 14 is another schematic diagram of a communication system provided in an embodiment of this application;

[0085] Figure 15 is another schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0086] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0087] The embodiments of this application involve at least one, including one or more; where "multiple" means two or more. Furthermore, it should be understood that in the description of this specification, terms such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating relative importance or order. For example, "first device" and "second device" do not represent the degree of importance of the two or their order, but are merely for descriptive distinction. In the embodiments of this application, "and / or" merely describes an association relationship, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0088] The directional terms mentioned in the embodiments of this application, such as "up", "down", "left", "right", "inner", and "outer", are only for reference to the directions in the accompanying drawings. Therefore, the directional terms used are for better and clearer explanation and understanding of the embodiments of this application, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0089] References to "one embodiment," "in some examples," or "some embodiments" as described in this specification mean that one or more embodiments of this specification include a particular feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in some examples," "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0090] As mentioned earlier, the password-based account login method requires users to remember both the username and password, which places high demands on the user. To solve this problem, this application embodiment allows for passwordless login. This eliminates the need for users to remember passwords, reducing the difficulty of remembering them and improving the user experience of electronic devices. In this application embodiment, passwordless login can include: QR code login. QR code login involves two devices: one is a device already logged into the account, such as device A, and the other is a device not logged into the account, such as device B. Device B can display a graphic to be scanned, such as a QR code or barcode. Device A can display a scanning interface. Device A scans the graphic displayed on device B through the scanning interface, allowing device B to log into device A's account.

[0091] The following will describe in detail the QR code login process provided in the embodiments of this application, with reference to the accompanying drawings.

[0092] The technical solutions provided in this application can be applied to communication systems. For example, please refer to Figure 1, which is a schematic diagram of a communication system provided in an embodiment of this application. As shown in Figure 1, the communication system includes a first device, a second device, and a cloud side.

[0093] In Figure 1, the first device logs into the first account. Therefore, the first device can be referred to as the logged-in device. Optionally, the first device logging into the first account can include: the first operating system of the first device logging into the first account (i.e., the first account is a system account), or the first application on the first device logging into the first account. The first operating system can be Android. System, HarmonyOS system, system, system, system, system, system, The system can be any operating system. The first application can be any application in the first device, which can be a system application or a third-party application. Optionally, the first account can be any form of account such as a mobile phone number, email address, or bank card number, and this application embodiment does not limit it. In Figure 1, the first device is a mobile phone as an example. It should be understood that the first device can also be other types of devices. For example, the first device can be a mobile phone, tablet computer, laptop computer, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), and other portable devices; or it can be a wearable device such as a watch or bracelet; or it can be a virtual reality (VR) device, augmented reality (AR) device, mixed reality (MR) device, etc. In short, this application embodiment does not limit the specific type of the first device.

[0094] In this embodiment, the first device may have distance sensing capability, enabling it to sense the distance between itself and other devices. For example, the first device may include a ranging unit. Optionally, the ranging unit may be a laser ranging unit, an acoustic ranging unit, an ultrasonic ranging unit, radar, etc., and this embodiment does not limit the scope. After the first device senses the distance between itself and other devices, if the distance is less than a first distance, it determines that the other device is close to the first device and can automatically bring up the corresponding interface. This process will be described later.

[0095] In Figure 1, the second device is not logged into the first account. Therefore, the second device can be referred to as an unlogged-in device. Optionally, the second device not being logged into the first account can include: the second operating system of the second device not being logged into the first account, or the second application on the second device not being logged into the first account. The second operating system can be... system, system, system, system, system, system, system, The system can be any operating system. Optionally, the second operating system can be the same as or different from the first operating system; for example, both the second and first operating systems can be... The system. The second application can be any application in the second device, which can be a system application or a third-party application. Optionally, the second application can be the same as or a different application from the first application mentioned above. Figure 1 uses a mobile phone as an example for the second device, but it should be understood that the second device can also be other types of devices. For example, the second device can be a mobile phone, tablet computer, laptop computer, PC, UMPC, netbook, PDA, or other portable devices; or it can be a television, game console, or other entertainment device; or it can be a watch, bracelet, or other wearable device; or it can be an in-vehicle device, such as a device installed in a vehicle, such as a display device; of course, the vehicle can also be replaced by other vehicles or means of transportation such as trains, aircraft, or mobile platforms; or it can be a VR device, AR device, MR device, etc. In short, the specific type of the second device is not limited in the embodiments of this application. Optionally, the second device and the first device can be the same type of device or different types of devices, for example, the first device is a mobile phone and the second device is a PC or tablet computer. This article uses the example of both the first device and the second device being mobile phones for illustration.

[0096] In this embodiment, the second device may have distance sensing capability, enabling it to sense the distance between itself and other devices. For example, the second device may include a ranging unit. Please refer to the preceding text for information on ranging units. After the second device senses the distance between itself and other devices, if the distance is less than a first distance, it determines that the other device is close to the second device and can automatically bring up the corresponding interface. This process will be described later.

[0097] In Figure 1, the cloud side may include the server corresponding to the first account, i.e., the login server of the first account, such as the first server. The first device logging into the first account can be simply understood as the first device being able to access the data resources on the first server. The second device not logging into the first account can be simply understood as the second device being unable to access the data resources on the first server. Optionally, the first server can be various types of servers, such as application servers, account servers, identity management (IDM) servers, etc. In Figure 1, the cloud side may also include other servers, such as the second server. The second server can be understood as an auxiliary server to the first server. For example, for a device that needs to log in via QR code (e.g., the second device), the second server can provide it with verification information. The verification information can be a login code value (code), hereinafter referred to as: code value. Optionally, the code value can be any combination of one or more forms such as text, numbers, symbols, letters, patterns, sound, and video. The code value can be used to generate a graphic to be scanned, such as a QR code, barcode, or other arbitrary form of graphic. In other words, the second server can be used to generate code values ​​and provide these values ​​to devices that need to perform QR code login (e.g., the second device), so that the device displays the graphic to be scanned. When this graphic is scanned by a device with an already logged-in account (e.g., the first device), passwordless login can be achieved. For example, the second server can be a Quick Response Code (QR code) server, and the generated code value can be a QR code. QR codes are used to generate various forms of graphics such as QR codes and barcodes. It should be noted that Figure 1 uses the example of the second server and the first server as two independent servers. It can be understood that the second server and the first server can also be a single server; for example, the second server can be integrated into the first server. In other words, the first server has the function of generating code values.

[0098] The following explanation will continue using the communication system shown in Figure 1 as an example.

[0099] In Figure 1, the first device is logged into the first account, while the second device is not. For ease of understanding, this example assumes the first device's first operating system is logged into the first account, while the second device's second operating system is not. If both the first and second operating systems are Huawei systems, then the first account can be a Huawei account. In this embodiment, the second device's second operating system can be logged into the first account via QR code login.

[0100] For example, please refer to Figure 2, which is a schematic diagram of a QR code login provided in an embodiment of this application. In Figure 2, the first operating system of the first device has logged into the first account. The second operating system of the second device has not logged into the first account. As shown in Figure 2(a), the second device displays interface 100, which includes a first graphic. As shown in Figure 2(b), the first device displays interface 200. Interface 200 can also be called a QR code scanning interface. Interface 200 includes an image captured by the camera of the first device. The user can point the camera of the first device at the first graphic on the second device to scan, so that the second operating system of the second device can log into the first account. The specific login process will be described later. In Figure 2, the first graphic can be a QR code, barcode, or other forms of graphic. Optionally, the shape of the first graphic can be any shape such as a square, rectangle, circle, or ring, which is not limited in this embodiment.

[0101] In this embodiment of the application, the first graphic can be generated in two ways, including the following two methods.

[0102] In the first method, the first graphic is generated based on a first code value. The first code value is obtained by the second device from the cloud (e.g., from the second server in Figure 1) and is used to achieve passwordless login. For example, as shown in Figure 3A, the second device displays the first graphic, which is a QR code generated based on the first code value. The first device scans the QR code to obtain the first code value, and then requests authorization from the cloud to log in to the first account based on the first code value.

[0103] In the second method, the first graphic is generated based on a second code value. The second code value differs from the first code value mentioned earlier, and this difference may include different sources and / or different functions. Different sources include, for example, the first code value being obtained by the second device from the cloud side (e.g., the second server in Figure 1) for passwordless login, while the second code value may be generated locally by the second device or obtained from a third server. The third server may be the same server as the second server or a different server from the first server. Different functions include, for example, the first code value being used by the cloud side to authenticate the second device to determine whether to authorize the second device to log in to the first account, while the second code value is used to establish a near-field communication (NFC) connection. For example, as shown in Figure 3B, the second device displays the first graphic, which is a ring code generated based on the second code value. If the operating system of the second device is HarmonyOS, the ring code can be called a HarmonyOS ring; however, this application embodiment does not limit this name. When the first device scans the ring code, it can establish a NFC connection with the second device. The first device can use this NFC connection to assist the second device in logging into the first account; the specific implementation process will be described later.

[0104] In this embodiment, the second device can generate the first graphic based on either of the two methods described above. For example, if the second device only includes program code for the first method, then the first method is used to generate the first graphic. Alternatively, if the second device only includes program code for the second method, then the second method is used to generate the first graphic. Or, if the second device includes program code for both the first and second methods, in this case, the second device can randomly select one method, or select one method based on the actual situation. For example, if the second device determines that the near-field communication function (e.g., Bluetooth) is not enabled, it can use the first method; otherwise, it can use the second method. Alternatively, the user can also set which method the second device uses.

[0105] It should be noted that different methods of generating the first graphic (e.g., the first or second method mentioned above) result in different login processes, which will be explained separately below. For ease of understanding, the following explanation mainly uses the second method of generating the first graphic (i.e., Figure 3B) as an example, where the first graphic is used to establish a near-field communication connection. As shown in Figure 3B, to achieve QR code login, the second device needs to open interface 100, and the first device needs to open interface 200. The following explanation will describe the process of the second device opening interface 100 and the first device opening interface 200. It should be emphasized that the principles of the second device opening interface 100 and the first device opening interface 200 in the following explanation also apply to Figure 3A.

[0106] For example, as shown in Figure 4(a), the second device displays the desktop. After receiving one or more user operations (e.g., click operations), the second device displays an interface for logging into an account, such as an interface for logging into a system account (e.g., a Huawei account). This interface may be, for example, the interface shown in Figure 4(b). This interface includes a "Near Field Login" button. When the second device receives an operation on the "Near Field Login" button, it displays interface 100 as shown in Figure 4(c). Interface 100 includes a first graphic used to establish a near field communication connection. As shown in Figure 4(d), the first device displays the desktop. After receiving one or more user operations (e.g., click operations), the first device displays the interface shown in Figure 4(e). This interface may be the account center interface of the first device's account. This interface includes a scan button. When the first device receives an operation on the scan button, it activates the camera and displays interface 200 as shown in Figure 4(f). Therefore, through the process shown in Figure 4, the second device opens interface 100, and the first device opens interface 200. However, this process requires users to perform cumbersome operations on both the first and second devices, which is inconvenient and results in a poor user experience.

[0107] To simplify user operations and enable the second device to quickly open interface 100, and / or the first device to quickly open interface 200, one possible solution is that both devices automatically bring up the corresponding interfaces when a trigger condition is met. Optionally, the trigger condition may include: the two devices are close together. That is, the corresponding interfaces are automatically brought up when the two devices are close together.

[0108] For example, as shown in Figure 5A(b), when the first device detects the approach of the second device, there are two processing methods. Method A: The first device displays a prompt box as shown in Figure 5A(e). The prompt box includes the first device's account information (e.g., mobile phone number) and a prompt message indicating that the first device's account will be logged in on the second device. The prompt box also includes a "Log in with this account" button. When the first device receives an operation on the "Log in with this account" button, it pulls up interface 200 as shown in Figure 5A(d), i.e., the QR code scanning interface. Method B: The first device directly pulls up interface 200 as shown in Figure 5A(d). As shown in Figure 5A(a), when the second device detects the approach of the first device, it can directly pull up interface 100 as shown in Figure 5A(c). Interface 100 includes a first graphic used to establish a near-field communication connection; or, when the second device receives a pull-up command sent by the first device, it pulls up interface 100 as shown in Figure 5A(c). For example, in Figure 5A(e), after receiving an operation on the "Log in with this account" button, the first device sends a pull-up command to the second device. After receiving the pull-up command, the second device pulls up the interface 100 as shown in Figure 5A(c).

[0109] It should be noted that Figure 5A illustrates an example where the first device displays the desktop, and the second device displays the desktop, with the corresponding interface automatically appearing when the two devices are close together. Optionally, before the second device displays interface 100, other interfaces besides the desktop can be displayed, such as a lock screen, a black screen, or other interfaces. These other interfaces can be the negative one screen or any interface accessed by the user when the device is unlocked. Optionally, before the first device displays interface 200, other interfaces besides the desktop can also be displayed, such as a lock screen, a black screen, or other interfaces. These other interfaces can be the negative one screen or any interface accessed by the user when the device is unlocked.

[0110] Comparing Figure 5A with Figure 4 above, in Figure 4, the user needs to perform cumbersome operations on the first and second devices respectively. In Figure 5A, the user only needs to bring the two devices close together, and the corresponding interfaces will automatically pop up on both devices. This method of automatically popping up the interface when close together greatly simplifies the user's operation steps and improves convenience and user experience.

[0111] In Figure 5A, when two devices are close together, the corresponding interface will automatically pop up, which can be implemented in various ways.

[0112] In Method A, when the second device detects the first device approaching, it automatically displays interface 100 and triggers the first device to display interface 200. For example, it sends a command to the first device to open interface 200, causing the first device to open interface 200 based on this command. In this method, the second device performs distance detection. When it determines that the first device is approaching based on the distance (e.g., the distance is less than a first distance), it displays interface 100 itself and triggers the first device to display interface 200. In this method, the workload of the first device is relatively small.

[0113] In Method B, when the first device detects the second device approaching, it automatically displays interface 200 and triggers the second device to display interface 100. For example, it sends a command to the second device to open interface 100, causing the second device to open interface 100 based on that command. In this method, the first device performs distance detection, and when it determines that the second device is approaching (e.g., the distance is less than a second distance), it displays interface 200 itself and triggers the second device to display interface 100. In this method, the workload of the second device is relatively small.

[0114] In method C, when the second device detects the first device approaching, interface 100 is automatically displayed; when the first device detects the second device approaching, interface 200 is automatically displayed. In this method, the computational load of the first and second devices is balanced.

[0115] Optionally, the system can default to using method A, where the distance detection and interface launch are performed by the device without a logged-in account (i.e., the second device). One possible scenario is that when the second device's second operating system is not logged into any account, the distance sensing unit in the second device (see previous description) can remain on, constantly sensing if other devices are approaching, preparing to launch the interface and complete the QR code login as quickly as possible. Meanwhile, the first device's first operating system is logged into the first account, so the distance sensing unit in the first device does not need to be constantly on; the first device only needs to launch the interface 200 after receiving the interface launch command from the second device. Of course, the system can also default to using method B or method C; this embodiment does not limit the choice.

[0116] In Figure 5A, the corresponding interfaces automatically pop up when the two devices are close together. This embodiment also considers that the automatic pop-up of interfaces when the two devices are close together may not be what the user expects. For example, the user may not intend to log into the first account on the second operating system of the second device; they may simply place the second device close to the first device. If the interfaces automatically pop up when the two devices are close together, it may affect the user experience.

[0117] Therefore, to avoid accidental triggering, the embodiments of this application provide the following solution.

[0118] The first solution is that when the second device displays the first interface (also known as the first specific interface), the corresponding interface will automatically pop up when the two devices are close together. When the second device does not display the first interface, the interface will not pop up when the two devices are close together, in order to avoid accidental triggering.

[0119] The primary interface of the second device can differ depending on the scenario. Three examples are given below.

[0120] The first scenario is the scenario where the second device logs in with an account. Optionally, the scenario where the login account is used can be the scenario where the system account is logged in (e.g., a Huawei account).

[0121] For example, as shown in Figure 5B(a), the second device displays the desktop. After receiving one or more user operations, the second device displays an interface for logging into an account. Taking logging into a system account (e.g., a Huawei account) as an example, the interface for logging into a system account could be interface 301 as shown in Figure 5B(b). As an example, the process of the second device opening interface 301 can include: Desktop -> Settings -> Account. As shown in Figure 5B(b), interface 301 includes a "Near Field Login" button. When the second device receives an operation on the "Near Field Login" button, it can display interface 302 as shown in Figure 5B(c), or directly display interface 100 as shown in Figure 5B(d). It should be noted that, as shown in interface 301 in Figure 5B(b), the account can be a mobile phone number, email address, or username, used to log into the operating system on the second device.

[0122] Optionally, the first interface can be any of the interfaces 301 in Figure 5B(b), 302 in Figure 5B(c), and 100 in Figure 5B(d), or other interfaces. Other interfaces can be, for example, the homepage of the settings application or any interface accessed from the homepage.

[0123] Taking interface 302 (c) in Figure 5B as an example, when the second device displays interface 302, the corresponding interface can be pulled up if the two devices are close together. For example, as shown in Figure 5B (e), when the first device displays the desktop and detects the second device approaching (the second device is currently displaying interface 302), there are two processing methods. Method A: The first device automatically pops up a prompt box as shown in Figure 5B (f). The prompt box includes a message indicating that the first device's account will be logged in on the second device. The prompt box also includes a "Log in with this account" button. When the first device receives an operation on the "Log in with this account" button, it pulls up interface 200 as shown in Figure 5B (g). Method B: The first device directly pulls up interface 200 as shown in Figure 5B (g), without going through the process in Figure 5B (f), saving operations and simplifying the process. When the second device displays interface 302, if the first device is detected to be close, interface 100 as shown in Figure 5B(d) can be automatically pulled up. Alternatively, when a pull-up command is received from the first device, interface 100 as shown in Figure 5B(d) can be pulled up. For example, in Figure 5B(f), after the first device receives an operation on the "Log in with this account" button, it sends a pull-up command to the second device. After receiving the pull-up command, the second device pulls up interface 100 as shown in Figure 5B(d). It should be noted that in this example, taking the second device displaying interface 302 and the first device displaying the desktop as an example of the two devices automatically pulling up the interface when close, optionally, the first device can also display other interfaces besides the desktop, such as the lock screen, black screen, or other interfaces. Other interfaces can be any interface that the user enters when the first device is unlocked, such as the negative one screen or the interface of a certain application.

[0124] Taking interface 100 (d) in Figure 5B as an example, when the second device displays interface 100, the corresponding interface can be pulled up if the two devices are close together. For example, as shown in Figure 5B (e), when the first device displays the desktop and detects the second device approaching (the second device is displaying interface 100), there are two processing methods, such as method A and method B mentioned above. It should be understood that since the second device is already displaying interface 100, when the second device detects the first device approaching, the second device remains on interface 100. It should be noted that in this example, taking the automatic pull-up of the interface when the two devices are close together as an example of the second device displaying interface 100 and the first device displaying the desktop, optionally, the first device can also display other interfaces besides the desktop, such as the lock screen, black screen, or other interfaces. Other interfaces can be any interface that the user enters when the first device is unlocked, such as the negative one screen or the interface of a certain application.

[0125] Taking interface 301 in Figure 5B(b) as an example, when the second device displays interface 301, the corresponding interface can be pulled up if the two devices are close together. For example, as shown in Figure 5B(e), when the first device displays the desktop and detects that the second device is close (the second device is displaying interface 301), there are two processing methods, such as method A and method B mentioned above. When the second device displays interface 301, if it detects that the first device is close, it can directly pull up interface 100 as shown in Figure 5B(d); or, when it receives a pull-up command sent by the first device, it pulls up interface 100 as shown in Figure 5B(d). For example, in Figure 5B(f), after the first device receives an operation on the "Log in with this account" button, it sends a pull-up command to the second device. After receiving the pull-up command, the second device pulls up interface 100 as shown in Figure 5B(d). It should be noted that in this example, taking the second device displaying interface 301 and the first device displaying the desktop as an example, when the two devices are close together, the interface automatically pulls up. Optionally, the first device can also display other interfaces besides the desktop, such as the lock screen, black screen, or other interfaces. Other interfaces can be any interface that the user enters when the first device is unlocked, such as the negative one screen or the interface of a certain application.

[0126] The second scenario is the out-of-box experience (OOBE) of the second device.

[0127] For example, as shown in Figure 5C(a), the second device is in a powered-off state. After receiving a power-on operation, the second device can display the power-on interface shown in Figure 5C(b). Optionally, the second device can perform processes such as SIM card network search and registration to enable the SIM card to be used normally. Optionally, it can also perform a wireless connection process, such as accessing WLAN. These processes are not described in detail in this embodiment. After completing the above processes, the second device can display interface 303 as shown in Figure 5C(c). The user can select a language, such as Simplified Chinese, in interface 303. When the second device receives an operation on the "Start" button, it displays interface 304 as shown in Figure 5C(d), where the user can select a region, such as China. When the second device receives an operation on the "Continue" button, it can display an interface for logging into an account, such as an interface for logging into a system account (e.g., a Huawei account). The interface can be, for example, interface 305 as shown in Figure 5C(e), or interface 100 as shown in Figure 5C(f). Interface 305 includes the following prompt: Please bring another device close to this device to easily complete the setup.

[0128] Optionally, the first interface can be any interface in the OOBE process, such as interface 303 in Figure 5C(c), interface 304 in Figure 5C(d), interface 305 in Figure 5C(e), or interface 100 in Figure 5C(f).

[0129] Taking interface 305 as shown in Figure 5C(e) as an example, when the second device displays interface 305, the corresponding interface can be pulled up if the two devices are close together. For example, as shown in Figure 5C(g), when the first device displays the lock screen interface and detects the second device approaching (the second device is currently displaying interface 305), there are two processing methods. Method A: The first device automatically pops up a prompt box as shown in Figure 5C(g), which includes the device information of the second device and a prompt message. The prompt message is used to prompt the user to set up the second device using the account of the first device. The prompt box also includes a "Settings" button. When the first device receives an operation on the "Settings" button, it can directly pull up interface 200 as shown in Figure 5C(h). Optionally, since the first device is in a locked screen state, when the first device receives an operation on the "Settings" button, it can prompt the user to perform identity authentication (this process is not shown in Figure 5C) to ensure that it is the owner of the first device operating. For example, the first device can prompt the user to enter an unlock fingerprint or unlock password. If the verification is successful, it will pull up interface 200 as shown in Figure 5C(h). In Method B, the first device directly pulls up interface 200 as shown in Figure 5C(h), without needing to display the prompt box in Figure 5C(g), saving operations and simplifying the process. When the second device displays interface 305, if it detects the first device approaching, it can automatically pull up interface 100 as shown in Figure 5C(f); or, upon receiving a pull-up command from the first device, it pulls up interface 100 as shown in Figure 5C(f). For example, in Figure 5C(g), after receiving an operation on the "Settings" button, the first device sends a pull-up command to the second device, and the second device, upon receiving the pull-up command, pulls up interface 100 as shown in Figure 5C(f). It should be noted that in this example, taking the second device displaying interface 305 and the first device displaying the lock screen interface as an example of the two devices automatically pulling up the interface when they approach each other, optionally, the first device can also display other interfaces besides the lock screen interface. Other interfaces include a black screen, or any interface that the user enters when unlocked, such as the desktop, the negative one screen, or the interface of a certain application.

[0130] Taking interface 100 as shown in Figure 5C(f) as an example, when the second device displays interface 100, the corresponding interface can be pulled up if the two devices are close together. For example, as shown in Figure 5C(g), when the first device displays the lock screen interface and detects that the second device is close (the second device is displaying interface 100), there are two processing methods, such as method A and method B mentioned above. It should be understood that since the second device is already displaying interface 100, when the first device is detected to be close, the second device remains on interface 100. It should be noted that in this example, taking the second device displaying interface 100 and the first device displaying the lock screen interface as an example of the two devices automatically pulling up the interface when close together, optionally, the first device can also display other interfaces besides the lock screen interface. Other interfaces include a black screen or any interface that the user enters when unlocked, such as the desktop, the negative one screen, or the interface of a certain application.

[0131] Taking interface 304 as shown in Figure 5C(d) as an example, when the second device displays interface 304, the corresponding interface can be pulled up if the two devices are close together. For example, as shown in Figure 5C(g), when the first device displays the lock screen interface and detects that the second device is close (the second device is displaying interface 304), there are two processing methods, such as method A and method B mentioned above. When the second device displays interface 304, if it detects that the first device is close, it can directly pull up interface 100 as shown in Figure 5C(f); or, when it receives a pull-up command sent by the first device, it pulls up interface 100 as shown in Figure 5C(f). For example, in Figure 5C(g), after the first device receives an operation on the "Settings" button, it sends a pull-up command to the second device. After receiving the pull-up command, the second device pulls up interface 100 as shown in Figure 5C(f). It should be noted that in this example, taking the second device displaying interface 304 and the first device displaying the lock screen interface as an example, when the two devices are close together, the interface automatically pulls up. Optionally, the first device can also display other interfaces besides the lock screen interface. Other interfaces include a black screen or any interface that the user enters when the device is unlocked, such as the desktop, the negative one screen, or the interface of a certain application.

[0132] The third scenario is the data cloning scenario.

[0133] For example, as shown in Figure 5D(a), the second device displays an interface that includes two options: "This is the old device" and "This is the new device". Optionally, the process of the second device opening the interface shown in Figure 5D(a) may include: Desktop -> Settings -> System and Updates -> Data Cloning; or, after the second device installs an application for data cloning (such as "Huawei Phone Cloning") from the app store, it opens the application's interface as shown in Figure 5D(a). When the second device receives an operation for the "This is the new device" option, it may display interface 306 as shown in Figure 5D(b), or directly display interface 100 as shown in Figure 5D(c).

[0134] Optionally, the first interface can be interface 306 in Figure 5D(b), interface 100 in Figure 5D(c), or other interfaces. Other interfaces may be other interfaces that the second device may display after receiving the operation for the "This is a new device" option.

[0135] Taking interface 306 in Figure 5D(b) as an example, when the second device displays interface 306, the corresponding interface can be pulled up if the two devices are close together. For example, as shown in Figure 5D(f), when the first device displays the lock screen interface and detects that the second device is close (the second device is displaying interface 306), there are two processing methods. Method A: The first device automatically pops up a prompt box as shown in Figure 5D(f), which includes the device information of the second device and a prompt message. The prompt message is used to prompt that data be cloned to the second device. The prompt box also includes a "Confirm" button. When the first device receives an operation for the "Confirm" button, it can pull up interface 200 as shown in Figure 5D(g); or, when the first device receives an operation for the "Confirm" button, it can prompt the user to perform identity authentication (this process is not shown in Figure 5D) to ensure that it is the owner of the first device operating. For example, the first device can prompt the user to enter an unlock fingerprint or unlock password. If the verification is successful, interface 200 as shown in Figure 5D(g) is pulled up. In Method B, the first device directly pulls up interface 200 as shown in Figure 5D(g), without needing to display the prompt box in Figure 5D(f), saving operations and simplifying the process. When the second device displays interface 306, if it detects the first device approaching, it can directly pull up interface 100 as shown in Figure 5D(c); or, upon receiving a pull-up command from the first device, it pulls up interface 100 as shown in Figure 5D(c). For example, in Figure 5D(f), after receiving an operation on the "Confirm" button, the first device sends a pull-up command to the second device, and the second device, upon receiving the pull-up command, pulls up interface 100 as shown in Figure 5D(c). It should be noted that in this example, taking the second device displaying interface 306 and the first device displaying the lock screen interface as an example of the two devices automatically pulling up the interface when they approach each other, optionally, the first device can also display other interfaces besides the lock screen interface. Other interfaces include a black screen, or any interface that the user enters when unlocked, such as the desktop, the negative one screen, or the interface of a certain application.

[0136] Taking interface 100 (c) in Figure 5D as an example, when the second device displays interface 100, the corresponding interface can be pulled up if the two devices are close together. For example, as shown in Figure 5D (f), when the first device displays the lock screen and detects the second device approaching (the second device is currently displaying interface 100), there are two processing methods, such as method A and method B mentioned above. It should be understood that since the second device is already displaying interface 100, it remains on interface 100 when it detects the first device approaching. It should be noted that in this example, which uses the automatic pull-up of interfaces when the two devices are close together as an example of the second device displaying interface 100 and the first device displaying the lock screen, the first device can optionally display other interfaces besides the lock screen, such as a black screen or any interface the user enters when unlocked, such as the desktop, the negative one screen, or the interface of a certain application.

[0137] As shown in Figure 5D, after the first device scans the first graphic in the interface 100 of the second device through the scanning interface 200, a near-field communication connection is established between the two devices. For example, the first device can display the interface shown in Figure 5D (h), which displays the prompt message: Connecting. After a successful connection, the first device displays the interface shown in Figure 5D (i), which includes the prompt message: Please operate on the new device (i.e., the second device). The second device can display an interface for logging into an account, for example, an interface for logging into a system account (e.g., a Huawei account). This interface can be the one shown in Figure 5D (k), which includes the account information of the first device (e.g., mobile phone number), a prompt message for the second device to log into the account of the first device, and two buttons: "Synchronize Login to This Account" and "Set Up Later".

[0138] In Figure 5D(k), when the second device receives an operation to press the "Synchronize Login to this Account" button, it logs into the first device's account via a near-field communication connection (the implementation principle is explained later). For example, the second device can display the interface shown in Figure 5D(l), which displays the message "Login in". After the second device logs into the first device's account via near-field communication, it can obtain the account's data in several ways. Method A: Since the second device has already logged into the first device's account, it can obtain the account's data from the cloud. Method B: The second device does not need to obtain data from the cloud; instead, it receives the account's data from the first device via near-field communication. Method C: Considering that the first device may upload some data to the cloud while not uploading others, the second device can obtain the uploaded data from the cloud, and for the data not uploaded to the cloud, it can obtain it from the first device via near-field communication. Taking Method B as an example, the second device can obtain all or part of the account's data from the first device via near-field communication, where the part of the data may be user-selected data. For example, in Figure 5D(l), after the second device successfully logs into the account of the first device, it can display the data selection interface shown in Figure 5D(d). The user can select data on this interface. When the second device receives an operation on the "Start Migration" button, it sends a start migration command to the first device. After receiving the start migration command, the first device migrates the data (the user-selected data) to the second device via a near-field communication connection. For example, the first device can display the prompt message shown in Figure 5D(j): Data migration in progress. The second device displays the migration progress shown in Figure 5D(e).

[0139] In Figure 5D(k), when the second device receives an operation on the "Set Later" button, since it does not need to log in to the first device's account, the second device can directly display the data selection interface in Figure 5D(d). The user can select data within this interface. When the second device receives an operation on the "Start Migration" button, it sends a start migration command to the first device. After receiving the start migration command, the first device migrates the data (the user-selected data) to the second device via a near-field communication connection. For example, the first device can display the prompt message "Data migration in progress" as shown in Figure 5D(j). The second device displays the migration progress as shown in Figure 5D(e).

[0140] The above are some examples of the first interface. It should be understood that the first interface can also be other interfaces, which are not listed in this application embodiment. It should be noted that in the first solution, when the second device displays the first interface, the display interface of the first device is not required. Regardless of what interface the first device displays (e.g., lock screen, black screen, desktop, negative one screen, or any other interface), the interface can be automatically pulled up when approached.

[0141] The second solution is to automatically pull up the corresponding interface when the two devices are close together if the first device displays the second interface (also known as the second specific interface). If the first device does not display the second interface, the interface will not be pulled up when the two devices are close together, in order to avoid accidental triggering.

[0142] Taking the first scenario mentioned earlier (the scenario where the second device logs in to an account) as an example, the first device is already logged in to an account, and the second interface can be any interface in the account center of the first device. For example, as shown in Figure 5E(a), the first device displays the desktop. After receiving one or more user operations, the first device displays interface 401 in the account center as shown in Figure 5E(b). The process of the first device opening interface 401 is not described in detail. The upper right corner of interface 401 includes a scan button. When the first device receives an operation on the scan button, it displays interface 200 as shown in Figure 5E(c).

[0143] Optionally, the second interface can be interface 401 in Figure 5E(b), interface 200 in Figure 5E(c), or other interfaces of the account center of the first device.

[0144] Taking interface 200 (c) in Figure 5E as an example, when the first device displays interface 200, the corresponding interface can be pulled up if the two devices are close together. For example, as shown in Figure 5E (d), the second device displays its desktop. When the second device detects that the first device is close (the first device is displaying interface 200), there are two possible processing methods. Method A: The second device pops up a prompt box as shown in Figure 5E (f), which includes the prompt message: whether to log in to the first device's account, and also includes a "Log in with this account" button. When the second device receives an operation to confirm the button, it pulls up interface 100 (e) in Figure 5E. Method B: The second device directly pulls up interface 100 (e) in Figure 5E, without needing to pop up the prompt box in Figure 5E (f), thus saving operation steps. It should be understood that since the first device is already displaying interface 200, the first device remains on interface 200 when the two devices are close together.

[0145] Taking interface 401 in Figure 5E(b) as an example, when the first device displays interface 401, the corresponding interface can be automatically pulled up if the two devices are close together. For example, the first device automatically pulls up interface 200, as shown in Figure 5E(c). As shown in Figure 5E(d), when the second device displays the desktop, and the second device detects that the first device is close (the first device is displaying interface 401), it automatically pulls up interface 100, as shown in Figure 5E(e).

[0146] It should be noted that in the example of Figure 5E, taking the second device displaying the desktop as an example, the second device may optionally also display a lock screen, a black screen, or other interfaces. Other interfaces can be any interface that the user enters after unlocking, such as the desktop, the negative one screen, or an application interface.

[0147] Taking the third scenario (data cloning scenario) mentioned earlier as an example, as shown in Figure 5F(a), the first device displays an interface that includes two options: "This is the old device" and "This is the new device". Optionally, the process of the first device opening the interface shown in Figure 5F(a) can include: Desktop -> Settings -> System and Updates -> Data Cloning; or, after the first device installs an application for data cloning (such as "Huawei Phone Cloning") from the app store, it opens the application's interface as shown in Figure 5F(a). When the first device receives an operation for the "This is the old device" option, it displays interface 402 as shown in Figure 5F(b), or directly displays interface 200 as shown in Figure 5F(c).

[0148] Optionally, the second interface may be interface 402 in Figure 5F(b), interface 200 in Figure 5F(c), or other interfaces. Other interfaces may be other interfaces that the first device may display in response to an operation that says "This is an old device".

[0149] Taking interface 402 in Figure 5F(b) as an example, when the first device displays interface 402, the corresponding interface can be automatically pulled up if the two devices are close together. For example, as shown in Figure 5F(g), the second device displays the lock screen interface. When the second device detects that the first device is close (the first device is displaying interface 402), there are two processing methods. Method A: The second device automatically pops up a prompt box as shown in Figure 5F(g). The prompt box includes the device information of the first device and a prompt message. The prompt message is used to indicate that the data of the first device will be cloned to the second device. The prompt box also includes a "Confirm" button. When the second device receives an operation for the "Confirm" button, it can pull up interface 100 as shown in Figure 5F(h); or, when the second device receives an operation for the "Confirm" button, it can prompt the user to perform identity authentication (this process is not shown in Figure 5F) to ensure that it is the owner of the second device operating. For example, the second device can prompt the user to enter an unlock fingerprint or unlock password. If the verification is successful, interface 100 as shown in Figure 5F(h) will be pulled up. In Method B, the second device directly pulls up interface 100 as shown in Figure 5F(h), without needing to display the prompt box in Figure 5F(g), saving operations and simplifying the process. When the first device displays interface 402, if the second device is detected to be close, it can directly pull up interface 200 as shown in Figure 5F(c); or, upon receiving a pull-up command from the second device, it pulls up interface 200 as shown in Figure 5F(c). For example, in Figure 5F(g), after receiving an operation on the "Confirm" button, the second device sends a pull-up command to the first device, and after receiving the pull-up command, the first device pulls up interface 200 as shown in Figure 5F(c). It should be noted that in this example, taking the automatic pull-up of interfaces when the two devices are close together as an example of the first device displaying interface 402 and the second device displaying the lock screen interface, the second device can optionally display other interfaces besides the lock screen interface, such as a black screen or any interface entered by the user when unlocked, such as the desktop, the negative one screen, or the interface of a certain application.

[0150] Taking interface 200 (c) in Figure 5F as an example, when the first device displays interface 200, the corresponding interface can be automatically pulled up if the two devices are close together. For example, as shown in Figure 5F (g), the second device displays the lock screen interface. When the second device detects that the first device is close (the first device is displaying interface 200), there are two processing methods, such as method A and method B mentioned above. Since the first device has already displayed interface 200, the first device remains on interface 200 when the two devices are close together. It should be noted that in this example, which uses the automatic pull-up of the interface when the two devices are close together as an example of the first device displaying interface 200 and the second device displaying the lock screen interface, optionally, the second device can also display other interfaces besides the lock screen interface. Other interfaces include a black screen or any interface that the user enters when the device is unlocked, such as the desktop, the negative one screen, or the interface of a certain application.

[0151] As shown in Figure 5F, after the first device scans the first graphic in the interface 100 of the second device through the scanning interface 200, a near-field communication connection can be established. For example, the first device can display the interface shown in Figure 5F(d), which displays the prompt message: Connecting. After a successful connection, the first device displays the interface shown in Figure 5F(e), which includes the prompt message: Please operate on the new device (i.e., the second device). The second device can display an interface for logging into an account, for example, an interface for logging into a system account (e.g., a Huawei account). This interface can be the interface shown in Figure 5F(k), which includes the account information of the first device (e.g., mobile phone number), a prompt message for the second device to log into the account of the first device, and two buttons: "Synchronize Login to This Account" and "Set Up Later". When the second device receives an operation on the "Synchronize Login to This Account" button, it logs into the account of the first device through the near-field communication connection (the implementation principle is explained later). For example, the second device can display the interface shown in Figure 5F(l), which displays the prompt message "Login in". After the second device logs into the first device's account via near-field communication (NFC), it can obtain the account's data, for example, through any of the methods A to C described above. Taking method B as an example, after the second device successfully logs into the first device's account, it can display the data selection interface shown in Figure 5F(i), where the user can select data. When the second device receives an operation on the "Start Migration" button, it sends a start migration command to the first device. After receiving the start migration command, the first device migrates the data (the user-selected data) to the second device via NFC. For example, the first device can display the prompt message shown in Figure 5F(f): Data migration in progress. The second device displays the migration progress shown in Figure 5F(j). In Figure 5F(k), when the second device receives an operation on the "Set Later" button, since it does not need to log into the first device's account, the second device can directly display the data selection interface shown in Figure 5F(i) and then perform data migration, as described above.

[0152] The above are some examples of the second interface. It should be understood that the second interface can also be other interfaces, which are not listed in this application embodiment. It should be noted that in the second solution, when the first device displays the second interface, the display interface of the second device is not required. Regardless of what interface the second device displays (e.g., lock screen, black screen, desktop, negative one screen, or any other interface), the interface can be automatically pulled up when approached.

[0153] The third solution involves determining whether a condition is met when two devices are close together. If the condition is met, the corresponding interface is displayed; otherwise, the interface is not displayed. In this solution, the condition determination can be performed by either of the two devices; alternatively, each device can perform its own condition determination. As mentioned earlier, automatically displaying an interface when two devices are close together can include three methods, from method A to method C. If method A is used, the second device performs the condition determination; if method B is used, the first device performs the condition determination; and if method C is used, each device performs its own condition determination. When each device performs its own condition determination, the conditions for each device can be the same or different. The following description uses method A as an example: when the second device detects that the first device is close together, it determines whether the condition is met. If the condition is met, interface 100 is automatically displayed, and the first device is triggered to display interface 200. Optionally, the condition may include at least one of the following:

[0154] Condition a: The second operating system of the second device is the same as the first operating system of the first device, for example, both are HarmonyOS.

[0155] Condition b: The second operating system of the second device is not logged into any account.

[0156] Condition c: The first device's first operating system is currently logged into an account. In this method, the second device needs to determine whether the first device's first operating system is logged into an account. One possible approach is for the second device to send a query request (e.g., via Bluetooth) to the first device to inquire whether the first device's first operating system is logged into an account. After receiving the query response from the first device, the second device determines whether the first device's first operating system is logged into an account based on the query response. Optionally, the query response may include account information of the first device's first operating system's currently logged-in account, such as username, avatar, etc. The username may be the registered phone number, email address, or a nickname set by the user.

[0157] Condition d: The second operating system of the second device is not logged into the first account. The first account is the account currently logged into the first operating system of the first device. In this method, the second device needs to determine the currently logged-in account (i.e., the first account) of the first operating system of the first device, and then determine whether the second operating system of the second device is logged into that account. The method by which the second device determines the currently logged-in account of the first operating system of the first device can be found in the relevant description of condition c, which will not be repeated here.

[0158] In condition e, the second device outputs a prompt message asking whether to log in to the first device's first account, and the second device receives a confirmation command to confirm logging in to the first device's device account. Optionally, the first device can also output a prompt message in response to the second device's proximity, asking whether to agree to authorize the second device to log in to the first account; if the first device receives the agreement command, it will launch the QR code scanning interface. In this way, the interface is only launched after the two devices are close together and the user agrees, avoiding the situation where the interface is launched directly when the two devices are close together, which would affect the user experience.

[0159] The three solutions described above can be used individually or in combination. Taking the combination of the first and second solutions as an example, when the second device displays the first interface and the first device displays the second interface, the corresponding interface will automatically appear when the two devices are brought close together. The above lists three solutions, all of which can avoid accidental triggering. It should be understood that there may be other solutions to prevent accidental triggering, which are not listed in this application's embodiments.

[0160] As mentioned above, the interface automatically pops up when two devices are brought close together, simplifying the user's operation. However, in actual use, users may not be aware of this feature and therefore may not use it effectively. To guide users, one possible solution is for the first and / or second devices to output instructional information to instruct users on how to operate the device, thus improving the user experience.

[0161] Taking the guidance information output by the second device (which can be referred to as the first guidance information) as an example, as shown in Figure 6A(a), the second device displays interface 600, which includes the guidance information: Please bring another device close to log in to the account of the other device. The user brings the first device close to the second device according to the guidance information. As shown in Figure 6A(b), when the first device displays the desktop or other interfaces (the other interfaces may include, for example, a lock screen, a black screen, a negative one screen, or any interface entered after unlocking), the user brings the first device close. When the first device detects the second device approaching, there are two processing methods. Method A: The first device pops up a prompt box as shown in Figure 6A(f), which includes the account information of the first device (e.g., mobile phone number) and a prompt message indicating that the account of the first device will be logged in on the second device. The prompt box also includes a "Log in with this account" button. When the first device receives an operation on the "Log in with this account" button, it pulls up interface 200 as shown in Figure 6A(d). Method B: The first device directly pulls up interface 200 as shown in Figure 6A(d). When the second device detects the approach of the first device, it can directly pull up interface 100 as shown in Figure 6A(c), or it can pull up interface 100 as shown in Figure 6A(c) upon receiving a pull-up command from the first device. For example, in Figure 6A(f), after receiving an operation on the "Log in with this account" button, the first device sends a pull-up command to the second device, and the second device pulls up interface 100 as shown in Figure 6A(c) upon receiving the command. It should be noted that the method by which the second device opens interface 600 in Figure 6A(a) is not limited in this embodiment. For example, in Figure 5B(b) above, interface 300 contains a button (e.g., a near-field login button), and interface 600 is opened when this button is triggered.

[0162] Taking the first device outputting guidance information (which can be called the second guidance information) as an example, as shown in Figure 6B(a), the first device displays interface 700, which includes guidance information: Please approach another device to authorize it to log in to this account. The user, following the guidance information, approaches the second device towards the first device. As shown in Figure 6B(b), when the second device displays a desktop or another interface (such as a lock screen, black screen, negative one screen, or any interface entered after unlocking), it approaches the first device. When the first device detects the approach of the second device, there are two processing methods. Method A: The first device pops up a prompt box as shown in Figure 6B(f), which includes the first device's account information (e.g., mobile phone number) and a prompt message indicating that the first device's account will be logged in on the second device. The prompt box also includes a "Log in with this account" button. When the first device receives an operation on the "Log in with this account" button, it pulls up interface 200 as shown in Figure 6B(d). Method B: The first device directly pulls up interface 200 as shown in Figure 6B(d). When the second device detects the approach of the first device, it can directly pull up interface 100 as shown in Figure 6B(c), or it can pull up interface 100 as shown in Figure 6B(c) upon receiving a pull-up command from the first device. For example, in Figure 6B(f), after receiving an operation on the "Log in with this account" button, the first device sends a pull-up command to the second device, and the second device pulls up interface 100 as shown in Figure 6B(c) upon receiving the command. It should be noted that the method by which the first device opens interface 700 in Figure 6B(a) is not limited in this embodiment.

[0163] In the above scheme, if the first operating system of the first device is already logged into the first account, the first device and the second device will automatically bring up the corresponding interface when they are close together. Then, the second operating system of the second device will log into the first account via QR code login. It is possible that the first operating system of the first device corresponds to multiple accounts. For example, the multiple accounts may be accounts that the first operating system has previously logged into, and the first account may be the currently logged-in account among the multiple accounts. Alternatively, the multiple accounts may be related; for example, the multiple accounts may be family-related accounts, such as the first account being an adult account and the other accounts being child accounts corresponding to the adult account.

[0164] If the first device has multiple accounts for its first operation, the user can select one account to allow the second operating system on the second device to log in to that account. Optionally, the user can select an account on either the first device or the second device.

[0165] Taking selection on the first device as an example, as shown in Figure 7A(a), the second device displays interface 600, or may display other interfaces or a black screen. As shown in Figure 7A(b), the first device displays the desktop or other interfaces besides the desktop, or a black screen. When the first device and the second device are close together, the second device automatically pulls up interface 100 as shown in Figure 7A(c). The first device automatically pulls up interface 100 as shown in Figure 7A(d), which includes identifiers for multiple accounts (e.g., phone number, avatar, etc.). The user can select an account, for example, by swiping left or right. When the first device receives an operation for the "Log in with this account" button, it displays interface 200 as shown in Figure 7A(e). At this time, when the first device scans the first graphic within the second device's interface 100 through interface 200, it can authorize the second device to log in to the account selected by the user.

[0166] Taking selection on a second device as an example, as shown in Figure 7B(a), the second device displays interface 600, or it may display other interfaces, such as a lock screen, a black screen, a desktop, a negative one screen, or any interface entered after unlocking. As shown in Figure 7B(b), the first device displays a desktop or an interface other than the desktop, such as a lock screen, a black screen, a negative one screen, or any interface entered after unlocking. When the first device is close to the second device, the second device automatically pulls up the interface shown in Figure 7B(c), which includes the identifiers of multiple accounts on the first device, allowing the user to select a specific account. In this method, the second device needs to determine which accounts the first device corresponds to, for example, by querying information via Bluetooth broadcast. When the second device receives an operation on the "Log in with this account" button, it displays interface 100 as shown in Figure 7B(d). The second device can notify the first device of the user's selected account. After the first device confirms the user's selected account, it can proceed in two ways. In Method A, the first device displays a prompt box as shown in Figure 7B(f), which includes the user-selected account information (e.g., mobile phone number) and a notification message indicating that the account will be logged in on the second device. The prompt box also includes a "Log in with this account" button. When the first device receives an operation on the "Log in with this account" button, it displays interface 200 as shown in Figure 7B(e). In Method B, the first device directly displays interface 200 as shown in Figure 7B(e). In this case, when the first device scans the first graphic within the second device's interface 100 through interface 200, it can authorize the second device to log in with the user-selected account.

[0167] The above embodiments illustrate the process of the second device opening interface 100 and the first device opening interface 200. It should be understood that after the second device opens interface 100 and the first device opens interface 200, QR code login can be performed.

[0168] The following text will continue to explain the implementation principle of QR code login with reference to the attached diagram.

[0169] As mentioned earlier, there are two ways to generate the first graphic, and the corresponding login process differs depending on the generation method. For example, if the second method is used to generate the first graphic (i.e., the first graphic is used to establish a near-field communication connection), the login process corresponds to Figures 8, 9, or 10. If the first method is used to generate the first graphic, the login process corresponds to Figure 11A. These will be explained separately below.

[0170] Taking the second device generating the first image using the second method as an example, where the first image is used to establish a near-field communication (NFC) connection, the second device can then achieve passwordless login for the account based on the NFC connection. Specifically, the second device's implementation of passwordless login based on the NFC connection can include at least the following three methods.

[0171] Option 1

[0172] Please refer to Figure 8, which is a schematic flowchart of another account login method provided in an embodiment of this application. This process can be applied to the scenarios shown in Figures 1, 2, 3B, and 5A to 5F. As shown in Figure 8, the process may include:

[0173] S800, the first device logs in to the first account.

[0174] Taking the first device as an example in the system shown in Figure 1, the first device logs into the first account, that is, the first device logs into the cloud side through the first account, such as logging into the first server in the cloud side. Taking the user logging in by entering the account information and password information of the first account on the first device as an example, S800 can include four sub-steps, namely S800a, S800b, S800c, and S800d. S800a: The first device receives an input operation, which is used to input the account information and password information of the first account. The account information is, for example, the username. The username can be the mobile phone number, email address, or nickname set by the user for registering the account. The password information can be the login password set by the user, for example, a combination of one or more of numbers, letters, and symbols. S800b: The first device sends a login request to the cloud side to request login to the first account. The login request can include the account information and password information of the first account. S800c: The cloud side verifies the first account according to the login request. Verifying the first account can include: verifying the correctness of the account information and password information of the first account. For example, the cloud side compares the account and password information carried in the login request with the stored account and password information. If they match, the verification passes; otherwise, the verification fails. After successful verification, S800d is executed, and the cloud side sends a first login credential to the first device. Correspondingly, the first device receives the first login credential sent by the cloud side. The first login credential can be understood as an identity credential issued by the cloud side to the first device, representing that the first device has successfully logged in. Subsequently, the first device can use the first login credential to access data on the cloud side. For example, when the first device needs to access data, it can send a data access request to the cloud side, carrying the first login credential in the data access request. After receiving the data access request, the cloud side verifies the identity of the first device based on the first login credential carried in the data access request. After successful verification, the cloud side returns the data to the first device. The cloud side's verification of the first device's identity based on the first login credential carried in the data access request may include: comparing the first login credential carried in the data access request with the login credential stored locally on the cloud side. If they match, the verification passes; otherwise, the verification fails.

[0175] For example, the first login credential could be a token.

[0176] Optionally, the first login credential can remain unchanged. However, to ensure data security, the first login credential can also be dynamically changed. For example, the server can update the first login credential at a certain period and send the updated first login credential to the first device, so that the first device can access the data using the latest first login credential. The period can be 1 week, 15 days, 1 month, or even 1 day, 2 days, etc., and this application embodiment does not limit it. In other words, the first login credential has an expiration time; it is valid within a specified period and expires outside of that period. Therefore, once the first login credential is stolen, it cannot be used after its expiration date, which can, to some extent, prevent the continuous leakage of data.

[0177] It's important to note that, as seen in the four sub-steps of the S800 process, the first login credential is different from the password for the first account. The first login credential is an identity certificate issued to the first device after the cloud side has verified the account information and password of the first account. Subsequently, the first device can access data based on the first login credential without needing to carry the account information and password again, thus preventing password leakage. Furthermore, generally, the password for the first account remains unchanged unless the user changes it, but the first login credential can be dynamically changed and has an expiration period; please refer to the previous text for the explanation of this principle.

[0178] S801, the second device displays the first interface. The first interface can be the first interface in the first scenario described above (i.e., the account login scenario), namely interface 301 in Figure 5B(b), interface 302 in Figure 5B(c), and interface 100 in Figure 5B(d); or it can be the first interface in the second scenario described above (OOBE scenario), such as interface 303 in Figure 5C(c), interface 304 in Figure 5C(d), interface 305 in Figure 5C(e), and interface 100 in Figure 5C(f); or it can be the first interface in the third scenario described above (data cloning scenario), such as interface 306 in Figure 5D(b) and interface 100 in Figure 5D(c), etc. Optionally, S801a may or may not be executed, so it is represented by a dashed line in the figure.

[0179] S802, the second device automatically pulls up the interface when it approaches the first device, wherein the second device is not logged into the first account.

[0180] Optionally, S802 may include S802a to S801e.

[0181] S802a, the second device broadcasts a request signal. The request signal is a short-range communication signal, such as a Bluetooth signal. The first device receives the request signal when it is close to the second device (e.g., within 30cm). The content requested by the request signal can differ for the three different application scenarios mentioned above. Taking the first scenario (the account login scenario) as an example, when the second device displays the first interface (interface 301 in Figure 5B(b), interface 302 in Figure 5B(c), or interface 100 in Figure 5B(d),) it broadcasts a request signal to request assistance in logging into the account. Taking the second scenario (OOBE scenario) as an example, when the second device displays the first interface (interface 303 in Figure 5C(c), interface 304 in Figure 5C(d), interface 305 in Figure 5C(e), or interface 100 in Figure 5C(f),) it broadcasts a request signal to request assistance in logging into the account. Taking the third scenario (data cloning scenario) as an example, when the second device displays the first interface (interface 306 in Figure 5D(b) and interface 100 in Figure 5D(c)), it broadcasts a request signal to request data migration.

[0182] S802b, the first device outputs a prompt message to indicate whether the user agrees to the content requested by the request signal. Taking the first scenario as an example, after receiving the request signal, the first device displays a prompt box as shown in Figure 5B(f), which includes a "Log in with this account" button. Taking the second scenario as an example, after receiving the request signal, the first device displays a prompt box as shown in Figure 5C(g), which includes a settings button. Taking the third scenario as an example, after receiving the request signal, the first device displays a prompt box as shown in Figure 5D(f), which includes a confirmation button.

[0183] S802c, when the first device receives an agreement operation, it sends an agreement signal to the second device. Taking the first scenario as an example, after the first device displays the prompt box shown in Figure 5B(f), it receives an operation on the "Log in with this account" button and sends an agreement signal to the second device. Taking the second scenario as an example, after the first device displays the prompt box shown in Figure 5C(g), it receives an operation on the settings button and sends an agreement signal to the second device. Taking the third scenario as an example, after the first device displays the prompt box shown in Figure 5D(f), it receives an operation on the confirm button and sends an agreement signal to the second device.

[0184] Optionally, S802b to S802c can be executed or not, so they are represented by dashed lines in the diagram. If they are not executed, that is, S801d and S801e are executed directly after S801a.

[0185] S802d, the second device displays the first graphic. The first graphic is generated based on a second code value and is used to establish a near-field communication connection. Please refer to the previous description for the second code value. For example, the first graphic may be the interface 100 in Figure 5B(d), the interface 100 in Figure 5C(f), or the HarmonyOS ring in the interface 100 in Figure 5D(c).

[0186] S802e, the first device displays a barcode scanning interface. For example, the barcode scanning interface can be interface 200 in Figure 5B(g), interface 200 in Figure 5C(h), or interface 200 in Figure 5D(g).

[0187] S803, the first device scans the first pattern and establishes a near-field communication connection.

[0188] Since the first pattern is generated based on the second code value, the first device can obtain the second code value by scanning the first pattern, and a near-field communication connection can be established based on the second code value. One possible implementation is that the first device sends a near-field communication connection request to the second device, which includes the second code value. After receiving the request, the second device can verify the first device. If the verification is successful, the second device sends an indication to the first device to agree to the connection, thus completing the near-field communication connection. One way the second device verifies the first device is to compare the second code value carried in the request with a locally stored second code value. If they match, the verification is successful; otherwise, the verification fails. Optionally, the near-field communication connection request may also include the service ID of the second device. The service ID can be created by the second device. For example, the second device broadcasts a signal that includes the service ID. After the first device receives the signal, it obtains the service ID from the signal and then sends the second code value and the service ID together with the near-field communication connection to the second device. After receiving the near-field communication connection request, the second device verifies the first device. For example, the second device compares the second code value carried in the near-field communication connection request with the second code value stored locally, and compares the service ID carried in the near-field communication connection request with the service ID stored locally. If they are consistent, the verification is successful; otherwise, the verification fails.

[0189] Optionally, to ensure data security, data transmitted via the near-field communication (NFC) connection can be encrypted using a session key. For example, the second device generates a session key and synchronizes it with the first device. Thus, when the first and second devices transmit data via the NFC connection, the session key can be used for encryption to prevent data leakage.

[0190] S804, the second device obtains the first code value from the cloud side.

[0191] It should be noted that the execution order between S804 and S802-S803 is not limited.

[0192] S805, the second device sends a first request to the first device via a near-field communication connection. The first request is used to request login to the first device's account. For example, the first request may include a first code value.

[0193] S806, the first device sends an authorization login request to the cloud side to request authorization for the second device to log in to the first account.

[0194] Optionally, the authorization login request may include at least one of the following information:

[0195] (1) First login credentials. Please refer to the previous description for details on first login credentials.

[0196] (2), First code value. For information on the first code value, please refer to the previous description.

[0197] (3) Information related to the first account. The information related to the first account may include the account information of the first account, and optionally, may also include the password information of the first account. Please refer to the previous description for the account information and password information of the first account.

[0198] (4) Equipment information of the first device. The equipment information of the first device may include the equipment type, equipment model, etc.

[0199] (5) Equipment information of the second device. The equipment information of the second device may include the equipment type, equipment model, etc.

[0200] S807, the cloud side verifies the login based on the authorization request.

[0201] Optionally, S807 may include: the cloud side verifying at least one of the first account, the first device, and the second device. Specifically, cloud-side verification of the first account may include: verifying the correctness of the account information and password information of the first account, which has been described in S800 and will not be repeated. Cloud-side verification of the first device may include: verifying the identity of the first device. For example, if the authorized login request includes a first login credential, the cloud side compares the first login credential carried in the authorized login request with the stored login credential of the first device. If they match, the verification passes; otherwise, the verification fails. As another example, if the authorized login request includes device information of the first device, the cloud side matches the device information of the first device carried in the authorized login request with the stored device information corresponding to the first account. If they match, the verification passes; otherwise, the verification fails. Cloud-side verification of the second device may include verifying the identity of the second device. For example, if the authorized login request includes a first code value, as mentioned above, the first code value is the verification information requested by the second device from the cloud side for QR code login. The cloud side can determine whether the first code value carried in the authorized login request is a code value that the cloud side has previously sent to the second device, and / or whether it is within its validity period. If so, the verification passes; otherwise, the verification fails. The validity period can be the validity period of the code value specified by the cloud side, such as 30 seconds, 50 seconds, etc. For example, if the authorized login request includes device information of the second device, the cloud side will match the device information of the second device carried in the authorized login request with the device information corresponding to the stored first account. If they match, the verification passes; otherwise, the verification fails.

[0202] S808, the cloud side sends a second login credential to the second device.

[0203] In the first scheme (i.e. the scheme shown in Figure 8), the first device requests authorization from the cloud side for the second device to log in to the first account. From the cloud side's perspective, since it is the first device that sends the authorization login request, the cloud side will assume that the first device has agreed to authorize the second device to log in to the first account. Therefore, the cloud side does not need to perform secondary verification (which will be explained later), thus saving processing steps.

[0204] The second option

[0205] In the first scheme (i.e., the scheme shown in Figure 8), the first device sends an authorization login request to the cloud side. This requires the first device to be connected to the internet. If the first device is not connected to the internet, it cannot send an authorization login request to the cloud side, meaning it cannot assist the second device in logging into the first account. Unlike the first scheme, in the second scheme, the second device can still log into the first account even when the first device is offline.

[0206] For example, please refer to Figure 9, which is a schematic flowchart of another account login method provided in an embodiment of this application. This process can be applied to the scenarios shown in Figures 1, 2, 3B, and 5A to 5F. As shown in Figure 9, the process may include:

[0207] S900, the first device logs in to the first account.

[0208] It should be noted that the implementation principle of S900 is the same as that of S800 in Figure 8 above. For example, S900 may also include four sub-steps (not shown in Figure 9), which have been explained in detail above and will not be repeated here.

[0209] S901, the second device displays the first interface. Please refer to the previous description for information about the first interface.

[0210] S902, the interface automatically pops up when the second device approaches the first device. The second device is not logged into the first account.

[0211] As mentioned earlier, when the two devices are close together, the second device displays the first graphic, which is generated based on the second code value and used to establish a near-field communication connection. The second device then displays the scanning interface. It should be noted that the implementation principle of S902 is the same as that of S802 in Figure 8 above. For example, S902 may also include five sub-steps (not shown in Figure 9), which have already been explained in detail in Figure 8 and will not be repeated here.

[0212] S903, the first device scans the first pattern and establishes a near-field communication connection.

[0213] It should be noted that the process of establishing a near-field communication connection between the first device and the second device is described in S803 in Figure 8 above, and will not be repeated here.

[0214] S904, the first device sends the account information and password information of the first account to the second device through a near-field communication connection.

[0215] S905, the second device sends a login request to the cloud side, which includes the account information and password information of the first account.

[0216] S906, the cloud side performs verification based on the login request.

[0217] Optionally, S906 may include: the cloud side verifying the correctness of the account information and password information of the first account. For example, the cloud side compares the account information and password information carried in the login request with the stored account information and password information. If they match, the verification passes; otherwise, the verification fails.

[0218] S907, the cloud sends a second login credential to the second device.

[0219] In the second scheme (as shown in Figure 9), the first device sends the account information and password of the first account to the second device via a near-field communication connection. After receiving the account information and password, the second device logs in to the first account. In this scheme, the first device does not need to send an authorization login request to the cloud side, so the first device can be in a network-free state. Therefore, this scheme breaks the limitation that the old device (i.e., the first device) must be connected to the network to assist the new device (i.e., the second device) in logging into the account.

[0220] The third option

[0221] In the second scheme (as shown in Figure 9), the first device needs to send the account information and password of the first account to the second device, which can easily lead to password leakage. Once the password is leaked, the first account can be occupied by others and is difficult to recover. Unlike the second scheme, in the third scheme, the first device does not need to send the password to the second device, and can still assist the second device in logging into the first account, reducing the possibility of password leakage. Moreover, the third scheme can also be used when the first device is offline.

[0222] For example, please refer to Figure 10, which is a schematic flowchart of another account login method provided in an embodiment of this application. This process can be applied to the scenarios shown in Figures 1, 2, 3B, and 5A to 5F. As shown in Figure 10, the process may include:

[0223] S1000, the first device logs in to the first account.

[0224] It should be noted that the implementation principle of S1000 is the same as that of S800 in Figure 8 above. For example, S1000 may also include four sub-steps (not shown in Figure 10), which have been explained in detail above and will not be repeated here.

[0225] S1001, The first device and the cloud side agree on the first key.

[0226] Optionally, the first device may agree on a first key with the cloud while it is connected to the network.

[0227] S1002, the second device displays the first interface. Please refer to the previous description for information about the first interface.

[0228] S1003, the second device automatically brings up the interface when it approaches the first device. The second device is not logged into the first account.

[0229] As mentioned earlier, when the two devices are close together, the second device displays the first graphic, which is generated based on the second code value and used to establish a near-field communication connection. The second device then displays the scanning interface. It should be noted that the implementation principle of S1003 is the same as that of S802 in Figure 8 above. For example, S1003 may also include five sub-steps (not shown in Figure 10), which have already been explained in detail in Figure 8 and will not be repeated here.

[0230] S1004, the first device scans the first pattern and establishes a near-field communication connection.

[0231] It should be noted that the process of establishing a near-field communication connection between the first device and the second device is described in S803 in Figure 8 above, and will not be repeated here.

[0232] S1005, the second device obtains the first code value from the cloud side.

[0233] S1006, the second device sends a first request to the first device via a near-field communication connection. The first request is used to request login to the first device's account. For example, the first request includes a first code value. Please refer to the previous description for the first code value.

[0234] Optionally, S1005 and S1006 can be executed or not, so they are represented by dashed lines in Figure 10.

[0235] Optionally, the implementation principles of S1002 to S1006 are the same as those of S801 to S805 in Figure 8 above, and will not be repeated.

[0236] S1007, the first device uses the first key to encrypt the first data.

[0237] In some embodiments, the first data includes a first login credential for the first device; please refer to the preceding description for the first login credential. Optionally, the first data may also include other information, such as device information of the first device, account information of the first account, and a first code value. To prevent password leakage, the first data does not include the login password of the first account.

[0238] S1008, the first device sends encrypted first data to the second device via near-field communication connection.

[0239] S1009, the second device sends a login request to the cloud side to request login to the first account. The login request includes encrypted first data.

[0240] S1010, the cloud side uses the first key to decrypt the encrypted first data.

[0241] S1011: The cloud side performs verification based on the login request. For details on S1011, please refer to S906 in Figure 9; it will not be repeated here.

[0242] It should be noted that in Figure 10, steps S1001, S1007, and S1010 are optional, hence they are represented by dashed lines. Furthermore, in S1001, the first device and the cloud side agree on a key ID in addition to the first key. The key ID indicates the first key. Thus, after the first device encrypts the first data using the first key in S1007, it can send the key ID along with the encrypted first data to the second device. The second device then sends the key ID and the encrypted first data along with the login request to the cloud side. The cloud side can first determine the first key based on the key ID, and then use the first key to decrypt the encrypted first data. This allows the cloud side to efficiently find the first key based on the key ID.

[0243] S1012, the second device receives a prompt message sent by the cloud side, which prompts the first device to perform network authentication.

[0244] It should be understood that, as mentioned above, the login request sent by the second device to the cloud includes the first device's first login credentials. The cloud may suspect that the second device has stolen the first device's first login credentials. For security reasons, the cloud can perform secondary verification (i.e., S1012-S1014), that is, verify whether the first device agrees to authorize the second device to log in to the first account. Optionally, S1012-S1014 can be executed or not, so it is represented by dashed lines in Figure 10.

[0245] Optionally, before S1012, the process may further include: the cloud side determining whether the first device is connected to the internet; if it determines that the first device is not connected to the internet, then S1012 is executed; if it determines that the first device is connected to the internet, then a prompt message is sent to the first device to indicate whether the first device agrees to authorize the second device to log in to the first account. Optionally, after receiving the prompt message, the first device may output the prompt message, and optionally, it may also display corresponding display components, which may include buttons (e.g., an agree button and a refuse button) or others. When the first device receives an operation on the agree button, it sends an authorization instruction to the cloud side. After receiving the instruction, the cloud side sends a second login credential to the second device.

[0246] S1013, the second device sends a prompt message to the first device via near-field communication connection.

[0247] In this embodiment, after receiving the prompt information from the cloud side, the second device can send the prompt information to the first device via a near-field communication connection. The first device can output the prompt information, and optionally, it can also display corresponding display components, which may include buttons (e.g., an agree button and a refuse button) or others.

[0248] S1014, the first device performs network authentication.

[0249] After the first device outputs a prompt message, the user sees the message and can connect the first device to the network. One possible approach is that, upon detecting a network connection, the first device proactively sends authentication information to the cloud, indicating its agreement to authorize the second device to log in to the first account. Upon receiving the authentication information, the cloud sends a second login credential to the second device. Another possible approach is that the cloud continuously sends prompt messages to the first device (e.g., every 5 seconds). After connecting to the network, the first device receives the prompt messages from the cloud, and can then output the prompt message and display corresponding display components. Upon receiving an action to agree to the action, the first device sends an authorization command to the cloud. Upon receiving this command, the cloud sends a second login credential to the second device.

[0250] S1015, the cloud sends a second login credential to the second device.

[0251] Compare Figures 9 and 10. In Figure 9, the first device sends the account information and password of the first account to the second device via a near-field communication (NFC) connection. The second device can then use this information to request login to the first account from the cloud. From the cloud's perspective, this is considered an independent login based on the account and password information. In Figure 10, the first device sends first data to the second device via NFC. This first data includes the first device's first login credentials, and the second device's login request to the cloud includes this first data. From the cloud's perspective, the first login credentials originally issued to the first device appear in the second device's login request, leading the cloud to believe that the second device is acting as a proxy for the first device's login to the first account—a proxy login. Therefore, Figures 10 and 9 represent two different login processes. It should be noted that while sending the first login credentials to the second device via NFC in Figure 10 carries a certain risk of leakage, the first login credentials are time-sensitive and cannot be used once they expire. This method does not leak the password, so the first account will not be occupied by others. Compared with the situation of password leakage, it can avoid the continuous leakage of data to a certain extent.

[0252] The above embodiments illustrate three schemes for passwordless login of a second device based on near-field communication (NFC) connections. The system (e.g., the communication system shown in Figure 1) can use any one of the three schemes, or it can select one scheme according to the actual situation. Optionally, the selection methods include the following:

[0253] Method A: The first device can determine whether it is currently connected to the internet. If it is connected, the first solution can be used; if it is not connected, the second or third solution can be used.

[0254] Method B, as mentioned above, involves an expiration date for the first login credential. Therefore, the first device can determine if the first login credential has expired. If it has, it can use either the first or second method; if it hasn't expired, it can use the third method. One possible scenario is that the first device has been offline for an extended period. Although the cloud has updated the first login credential, because the first device has been offline, the cloud cannot synchronize the latest credential to the first device, causing the first login credential to expire. In this case, the first device can use either the first or second method.

[0255] Methods A and B above can be used individually or in combination. Taking combined use as an example, if the first device uses method A, it may be determined to use either the second or third scheme (i.e., the first device is not connected to the network). Furthermore, if the first device uses method B, it may be determined to use the third scheme (the first login credential has not expired).

[0256] As mentioned earlier, if the first operation of the first device has multiple accounts, the user can select one of them, allowing the second operating system of the second device to log in with the selected account. In this case, the account information contained in the login request (or authorized login request) in Figures 8 to 10 above is the account information of the user-selected account.

[0257] Figures 8 to 10 above illustrate an example where the second device generates the first graphic using the second method (i.e., the first graphic is used to establish a near-field communication connection). If the second device generates the first graphic using the first method (i.e., generates the first graphic based on the first code value), the login process shown in Figure 11A can be used. Figure 11A is a schematic diagram of another flow of an account login method provided in an embodiment of this application. This flow can be applied to the scenarios shown in Figures 1, 2, and 3A. As shown in Figure 11A, the flow may include:

[0258] S1100, the first device logs in to the first account.

[0259] Optionally, the implementation principle of S1100 is the same as that of S800 in Figure 8, and will not be repeated here.

[0260] S1101, the second device displays the first interface. As shown in Figure 11B(a), the second device displays the desktop. After receiving one or more user operations, the second device displays interface 1101 as shown in Figure 11B(b). Interface 1101 includes a "Scan to Log In" button. When the second device receives an operation on the "Scan to Log In" button, it displays interface 1102 as shown in Figure 11B(c), or directly displays interface 100 as shown in Figure 11B(d). Interface 100 includes a first graphic, which is generated based on a first code value obtained by the second device from the cloud. The first interface can be interface 1102 as shown in Figure 11B(c), or interface 100 as shown in Figure 11B(d).

[0261] S1102, the interface automatically pops up when the first device and the second device approach each other. The second device is not logged into the first device's account.

[0262] Optionally, S1102 may include S1102a to S1102e.

[0263] S1102a, the second device broadcasts a request signal, which is a short-range communication signal, such as a Bluetooth signal. The first device will receive the request signal if it is close to the second device (e.g., within 30cm). The request signal is used to request login to the first device's account. For example, as shown in Figure 11B(e), the first device receives the request signal from the second device when displaying its desktop. Optionally, the first device may also display other interfaces besides the desktop, such as the lock screen, a black screen, the negative one screen, the interface of a specific application, or any interface entered after the first device is unlocked.

[0264] S1102b, the first device outputs a prompt message to indicate whether it agrees to allow the second device to log in to the first device's account. For example, as shown in Figure 11B(e), when the first device displays its desktop, it receives a request signal from the second device and then displays the prompt box shown in Figure 11B(f). The prompt box includes a prompt message asking whether the user agrees to allow the second device to log in to this account. The prompt box may also include a "Log in with this account" button.

[0265] S1102c, when the first device receives the consent operation, it sends a consent signal to the second device. For example, as shown in Figure 11B(f), when the first device receives the operation for the "Log in with this account" button, it sends a consent signal to the second device.

[0266] Optionally, S1102b to S1102c can be executed or not, so they are represented by dashed lines in the diagram. If they are not executed, that is, S1102d and S1102e are executed directly after S1102a.

[0267] S1102d, the second device displays the first graphic. The first graphic is generated based on a first code value, which is obtained from the cloud. Please refer to the previous description for the first code value. For example, the first graphic is, for instance, the HarmonyOS ring in interface 100 of Figure 11B(d).

[0268] S1102e, the first device displays a barcode scanning interface. For example, the barcode scanning interface can be interface 200 in (g) of Figure 11B.

[0269] S1103, the first device scans the first image to obtain the first code value.

[0270] One possible approach is for the first device to obtain an image of the first graphic by scanning it, and then automatically parse the first code value from the image. Another possible approach is for the first device to obtain an image of the first graphic by scanning it, then send the image to the cloud (e.g., a second server), use the cloud to parse the first code value, and then return the first code value to the first device.

[0271] S1104, the first device sends an authorization login request to the cloud side. The authorization login request is used to instruct the second device to request login to the first account.

[0272] S1105, the cloud side verifies the login based on the authorization request.

[0273] S1106, the cloud sends a second login credential to the second device.

[0274] Optionally, the principles of S1104 to S1106 are the same as those of S806 to S808 in Figure 8, and will not be repeated.

[0275] Figure 12A is a schematic flowchart of another account login method provided in an embodiment of this application. This process can be applied to the first scenario (i.e., Figure 5B) or the second scenario (i.e., Figure 5C) mentioned above. As shown in Figure 12A, the process includes:

[0276] S1200: The first device logs into the first account. The implementation principle of S1200 is the same as that of S800 in Figure 8, and will not be repeated.

[0277] S1201, the second device displays the first interface. Optionally, the first interface is the interface used by the second device to log in to the account. Taking the first scenario mentioned above (i.e., the account login scenario in Figure 5B) as an example, the first interface can be interface 301 in Figure 5B(b), interface 302 in Figure 5B(c), or interface 100 in Figure 5B(d). Taking the second scenario mentioned above (i.e., the OOBE scenario in Figure 5C) as an example, the first interface can be interface 303 in Figure 5C(c), interface 304 in Figure 5C(d), interface 305 in Figure 5C(e), or interface 100 in Figure 5C(f). Taking the third scenario mentioned above (i.e., the data cloning scenario in Figure 5D) as an example, the first interface can be interface 306 in Figure 5D(b) or interface 100 in Figure 5D(c).

[0278] S1202, the interface automatically pops up when the first and second devices approach each other.

[0279] For example, the first device displays a QR code scanning interface in response to detecting the second device approaching. Optionally, the first device can display any interface before displaying the QR code scanning interface, such as a lock screen, a black screen, a desktop, a negative one screen, or an application interface.

[0280] Optionally, the first device displays a prompt message in response to detecting the second device's proximity. The prompt message indicates whether the user agrees to allow the second device to log in to the first account. For example, in the first scenario (i.e., the account login scenario in Figure 5B), the prompt message could be the prompt box shown in Figure 5B(f), which includes a "Log in with this account" button. In the second scenario (i.e., the OOBE scenario in Figure 5C), the prompt message could be the prompt box shown in Figure 5C(g), which includes a settings button. In the third scenario (i.e., the data cloning scenario in Figure 5D), the prompt message could be, for example, the prompt box shown in Figure 5D(f), which includes a confirmation button. After displaying the prompt message, if the first device receives an agreement operation, it displays a QR code scanning interface. For example, in the first scenario, after displaying the prompt box shown in Figure 5B(f), if the first device receives an operation for the "Log in with this account" button, it displays the QR code scanning interface 200 shown in Figure 5B(g). Taking the second scenario as an example, after the first device displays the prompt box shown in Figure 5C(g), if it receives an operation on the setting button, it displays the QR code scanning interface 200 shown in Figure 5C(h). Taking the third scenario (i.e., the data cloning scenario in Figure 5D) as an example, after the first device displays the prompt box shown in Figure 5D(f), if it receives an operation on the confirm button, it displays the QR code scanning interface 200 shown in Figure 5D(g).

[0281] Optionally, the first device detecting the proximity of the second device may include: the first device detecting that the distance between the first device and the second device is less than a first distance (e.g., 30cm), and / or the first device receiving a request signal broadcast by the second device, the request signal being a short-range communication signal, such as a Bluetooth signal, see S801 in Figure 8.

[0282] For example, in response to detecting the proximity of the first device, the second device displays a first graphic, which is used to establish near-field communication. Optionally, the second device may directly display the first graphic in response to detecting the proximity of the first device, or it may display the first graphic upon receiving a consent instruction from the first device. Taking Figure 5B as an example, when the second device displays interface 302, if it detects the proximity of the first device, it may automatically pull up interface 100 as shown in Figure 5B(d), which includes the first graphic; or, the second device may pull up interface 100 as shown in Figure 5B(d) upon receiving a pull-up instruction from the first device. For example, in Figure 5B(f), after receiving an operation on the "Log in with this account" button, the first device sends a pull-up instruction to the second device, and the second device, upon receiving the pull-up instruction, pulls up interface 100 as shown in Figure 5B(d).

[0283] Optionally, the second device detecting the proximity of the first device may include: the second device detecting that the distance between the first and second devices is less than a second distance (e.g., 30cm), and / or the second device receiving an agreement signal returned by the first device, as shown in S801 of Figure 8. Taking the first scenario as an example, after the first device displays the prompt box shown in Figure 5B(f), it receives an operation on the "Log in with this account" button and sends an agreement signal to the second device. Taking the second scenario as an example, after the first device displays the prompt box shown in Figure 5C(g), it receives an operation on the settings button and sends an agreement signal to the second device. Taking the third scenario as an example, after the first device displays the prompt box shown in Figure 5D(f), it receives an operation on the confirm button and sends an agreement signal to the second device.

[0284] S1203, the first device scans the first graphic through the barcode scanning interface to establish a near-field communication connection with the second device.

[0285] Optionally, the first device can obtain the second code value by scanning the first pattern. The principle of establishing a near-field communication connection based on the second code value is shown in 803 of Figure 8.

[0286] S1204, the first device sends first data to the second device via a near-field communication connection, wherein the first data includes a first login credential.

[0287] Optionally, the first login credential can be a token. In some embodiments, the first data may not include the login password of the first account to avoid password leakage. In other embodiments, the first data is encrypted using a first key, which is a key agreed upon by the first device and the server corresponding to the first account, see S1007 in Figure 10.

[0288] S1205, The second device logs into the first account based on the first login credential.

[0289] Optionally, for the implementation principle of S1206, please refer to S1009 to S1012 in Figure 10.

[0290] It should be noted that if the first interface displayed by the second device in S1201 is the first interface in the third scenario mentioned above (i.e., the data cloning scenario in Figure 5D), such as interface 306 in Figure 5D(b) or interface 100 in Figure 5D(c), then after S1205, it may also include: the first device sending second data to the second device via a near-field communication connection, the second data being user data stored in the first device. After receiving the second data, the second device stores the second data. For example, in Figure 5D(l), after the second device successfully logs into the account of the first device, it can display the data selection interface in Figure 5D(d), where the user can select data. When the second device receives an operation on the "Start Migration" button, it sends a start migration command to the first device. After receiving the start migration command, the first device sends the second data (e.g., the data selected by the user) to the second device via a near-field communication connection. For example, the first device can display the prompt message as shown in Figure 5D(j): Data migration in progress. The second device displays the migration progress as shown in Figure 5D(e).

[0291] Figure 12B is a schematic flowchart of another account login method provided in an embodiment of this application. This process can be applied to the third scenario mentioned above (i.e., Figure 5D). As shown in Figure 12B, the process includes:

[0292] S1300: The first device logs into the first account. The implementation principle of S1200 is the same as that of S800 in Figure 8, and will not be repeated.

[0293] S1301, the second device displays the first interface. The first interface is used to migrate data from other devices. Taking the third scenario mentioned above (i.e., the data cloning scenario in Figure 5D) as an example, the first interface can be interface 306 in Figure 5D (b) or interface 100 in Figure 5D (c).

[0294] S1302, the interface automatically pops up when the first and second devices approach each other.

[0295] For example, the first device displays a QR code scanning interface in response to detecting the second device approaching. Optionally, before displaying the QR code scanning interface, the first device can display any interface, such as a lock screen, a black screen, a desktop, a negative one screen, or an application interface.

[0296] Optionally, the first device displays a prompt message in response to detecting the approach of the second device. The prompt message indicates whether the user agrees to migrate data to the second device. Taking the third scenario (i.e., the data cloning scenario in Figure 5D) as an example, the prompt message could be a prompt box as shown in Figure 5D (f), which includes a confirmation button. After displaying the prompt message, if the first device receives an agreement, it displays a QR code scanning interface. For example, in the third scenario, after displaying the prompt box as shown in Figure 5D (f), if the first device receives an operation related to the confirmation button, it displays the QR code scanning interface 200 shown in Figure 5D (g).

[0297] Optionally, the first device detecting the proximity of the second device may include: the first device detecting that the distance between the first device and the second device is less than a first distance (e.g., 30cm), and / or the first device receiving a request signal broadcast by the second device, the request signal being a short-range communication signal, such as a Bluetooth signal, see S801 in Figure 8.

[0298] For example, in response to detecting the proximity of the first device, the second device displays a first graphic, which is used to establish near-field communication. Optionally, the second device may directly display the first graphic in response to detecting the proximity of the first device, or it may display the first graphic upon receiving a consent command from the first device. Taking Figure 5D as an example, when the second device displays interface 306, if it detects the proximity of the first device, it may automatically pull up interface 100 as shown in Figure 5D(c), which includes the first graphic; or, the second device may pull up interface 100 as shown in Figure 5D(c) upon receiving a pull-up command from the first device. For example, in Figure 5D(f), after receiving an operation on the "Confirm" button, the first device sends a pull-up command to the second device, and the second device, upon receiving the pull-up command, pulls up interface 100 as shown in Figure 5D(c).

[0299] Optionally, the second device detecting the proximity of the first device may include: the second device detecting that the distance between the first and second devices is less than a second distance (e.g., 30cm), and / or the second device receiving an agreement signal returned by the first device, as shown in S801 of Figure 8. Taking the third scenario as an example, after the first device displays the prompt box shown in Figure 5D(f), when it receives an operation for the confirmation button, it sends an agreement signal to the second device.

[0300] S1304, the first device scans the first graphic through the barcode scanning interface to establish a near-field communication connection with the second device.

[0301] Optionally, the first device can obtain the second code value by scanning the first pattern. The principle of establishing a near-field communication connection based on the second code value is shown in 803 of Figure 8.

[0302] S1305, the first device sends first data to the second device via a near-field communication connection. The first data includes user data stored in the first device. The user data may be data from various applications (system applications or third-party applications) on the first device, such as data from applications like photo album, memo, contacts, and calendar.

[0303] S1306, The second device stores the first data.

[0304] The following describes an electronic device provided in an embodiment of this application. The electronic device may be the first device, the second device, or a cloud-based device as described above.

[0305] For example, please refer to Figure 13, which is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. As shown in Figure 13, the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0306] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. The controller may serve as the nerve center and command center of the electronic device. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. Processor 110 may also include memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that processor 110 has just used or is repeatedly used. If processor 110 needs to reuse the instruction or data, it can directly retrieve it from the memory. This avoids repeated access, reduces the waiting time of processor 110, and thus improves system efficiency.

[0307] In some embodiments, the processor 110 may execute the account login method provided in the embodiments of this application.

[0308] In some embodiments, the processor 110 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.

[0309] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0310] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0311] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0312] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0313] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

[0314] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0315] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

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

[0317] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in conjunction with a tuning switch.

[0318] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G in electronic devices. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 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. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0319] The wireless communication module 160 can provide solutions for wireless communication applications in electronic devices, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0320] In some embodiments, antenna 1 of the electronic device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the electronic device to communicate with networks and other devices via wireless communication technology.

[0321] The display screen 194 is used to display the application's interface, etc. The display screen 194 includes a display panel. In some embodiments, the electronic device may include one or N display screens 194, where N is a positive integer greater than 1.

[0322] The electronic device 100 can perform shooting functions through an ISP, a camera 193, a video codec, a GPU, a display 194, and an application processor. The ISP is used to process the data fed back by the camera 193.

[0323] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of the electronic device by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system and software code for at least one application program. The data storage area may store data generated during the use of the electronic device (e.g., images, videos, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, general-purpose flash memory, etc.

[0324] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, images, videos, and other files can be saved on the external memory card.

[0325] Electronic devices can implement audio functions such as music playback and recording through audio modules 170, speakers 170A, receivers 170B, microphones 170C, headphone jacks 170D, and application processors.

[0326] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0327] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or listen to hands-free calls and other external playback scenarios through one or more speakers 170A.

[0328] The receiver 170B, also known as a "handpiece," can be one or more, and is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a telephone call or voice message, the receiver 170B can be brought close to the ear to listen to the voice.

[0329] The microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals.

[0330] The 170D headphone jack is used to connect wired headphones.

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

[0332] The gyroscope sensor 180B can be used to determine the motion attitude of an electronic device. In some embodiments, the gyroscope sensor 180B can determine the angular velocity of the electronic device about three axes (i.e., the x, y, and z axes). The gyroscope sensor 180B can be used for image stabilization.

[0333] The barometric pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device calculates altitude using the air pressure value measured by the barometric pressure sensor 180C to assist in positioning and navigation.

[0334] The magnetic sensor 180D includes a Hall effect sensor. Electronic devices can use the magnetic sensor 180D to detect the opening and closing of a flip cover.

[0335] The 180E accelerometer can detect the magnitude of acceleration in various directions (typically three axes) of electronic devices. When the electronic device is stationary, it can detect the magnitude and direction of gravity.

[0336] The 180F distance sensor is used to measure distance. Electronic devices can measure distance using infrared or laser.

[0337] The proximity sensor 180G may include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The LED may be an infrared LED. The electronic device emits infrared light outward through the LED. The electronic device uses the photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that an object is near the electronic device. When insufficient reflected light is detected, the electronic device can determine that no object is near the electronic device.

[0338] An ambient light sensor 180L is used to detect ambient light levels. Electronic devices can adaptively adjust the brightness of the display screen 194 based on the detected ambient light levels.

[0339] The fingerprint sensor 180H is used to collect fingerprints.

[0340] The 180J temperature sensor is used to detect temperature.

[0341] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touch screen." Touch sensor 180K is used to detect touch operations applied to or near it. The touch sensor can then transmit the detected touch operation to the application processor to determine the type of touch event.

[0342] The bone conduction sensor 180M can acquire vibration signals. In some embodiments, the bone conduction sensor 180M can acquire vibration signals from the vibrating bone segments of the human vocal cords.

[0343] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch buttons. The electronic device can receive button inputs and generate key signal inputs related to user settings and function control. Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to achieve contact and separation with the electronic device.

[0344] It is understood that the components shown in Figure 13 do not constitute a specific limitation on the electronic device. The electronic device in embodiments of the present invention may include more or fewer components than those shown in Figure 13. Furthermore, the combination / connection relationships between the components in Figure 13 can also be adjusted and modified.

[0345] Figure 14 is another schematic diagram of the communication system provided in an embodiment of this application. As shown in Figure 14, the communication system includes a first device and a second device. Optionally, although not shown in Figure 14, the communication system may also include a cloud side. The left half of Figure 14 shows the structure of the second device, and the right half shows the structure of the first device. The second device includes various applications and a second operating system. The second operating system may include a code value acquisition unit and an account login unit. The second device may also include a distributed architecture. The distributed architecture includes a device discovery module and a device connection module. It should be noted that, in Figure 14, the distributed architecture is independent of the second operating system as an example; optionally, the distributed architecture may also be built into the second operating system. The first device includes various applications and a first operating system. The first operating system may include a code value acquisition unit and an account login unit. The first device may also include a distributed architecture. The distributed architecture includes a device discovery module and a device connection module. It should be noted that, in Figure 14, the distributed architecture is independent of the first operating system as an example; optionally, the distributed architecture may also be built into the first operating system.

[0346] The following uses Figure 14 as an example to illustrate the account login method provided in the embodiments of this application.

[0347] The device discovery module within the distributed architecture of the second device can discover nearby devices. Therefore, when the first device approaches the second device, the device discovery module in the second device can discover the first device. Similarly, the device discovery module within the distributed architecture of the first device can also discover nearby devices. Therefore, when the second device approaches the first device, the device discovery module in the first device can also discover the second device. In other words, the first and second devices can discover each other.

[0348] Subsequently, the code value acquisition unit in the second device acquires the second code value. The second operating system generates a first graphic based on the second code value, used to establish a near-field communication connection, and displays the first graphic. The second device can trigger the first device to launch the scanning interface. For example, the second device broadcasts a signal through a distributed architecture, which instructs the receiving end to launch the scanning interface. After receiving the signal, the first device launches the scanning interface.

[0349] Subsequently, the first device scans the first graphic displayed on the second device via a QR code scanning interface, establishing a near-field communication connection through the connection module in the distributed architecture. The account login unit in the first device can assist the second device in logging into the first account based on this near-field communication connection. Specifically, the account login unit in the first device can assist the second device in logging into the first account through three schemes. These three schemes are the first, second, and third schemes mentioned above. Please refer to the preceding text for details on these three schemes; they will not be repeated here.

[0350] Figure 15 is a schematic diagram of another structure of the electronic device provided in an embodiment of this application. The electronic device 1500 can be the first device, the second device, or the cloud-side device described above. As shown in Figure 15, the electronic device 1500 may include: one or more processors 1501; one or more memories 1502; a communication interface 1503; and one or more computer programs 1504. The above-mentioned devices can be connected through one or more communication buses 1505. The one or more computer programs 1504 are stored in the memory 1502 and configured to be executed by the one or more processors 1501. The one or more computer programs 1504 include instructions. For example, when the electronic device 1500 is the first device described above, the instructions can be used to perform the relevant steps of the first device as described in any of the embodiments of Figures 1 to 14 above. For example, when the electronic device 1500 is the second device described above, the instructions can be used to perform the relevant steps of the second device as described in any of the embodiments of Figures 1 to 14 above. For example, when the electronic device 1500 is the cloud-side device described above, the instructions can be used to perform the relevant steps of the cloud-side device as described in any of the embodiments of Figures 1 to 14 above. The communication interface 1503 is used to enable communication between the electronic device 1500 and other devices, such as a transceiver.

[0351] The methods provided in the embodiments of this application above are described from the perspective of an electronic device (e.g., a mobile phone or cloud device) as the executing entity. To implement the functions of the methods provided in the embodiments of this application above, the terminal device may include hardware structures and / or software modules, implementing the above functions in the form of hardware structures, software modules, or a combination of hardware structures and software modules. Whether a particular function is implemented in the form of hardware structures, software modules, or a combination of hardware structures and software modules depends on the specific application and design constraints of the technical solution.

[0352] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)). Where there is no conflict, the solutions in the above embodiments can be combined.

[0353] Based on the above embodiments, this application also provides a computer program product containing instructions, which, when run on a computer, causes the computer to execute the methods described in the embodiments of this application.

[0354] Based on the above embodiments, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a computer, causes the computer to perform the methods described in the embodiments of this application.

[0355] Based on the above embodiments, this application also provides a chip for reading computer programs stored in a memory to implement the methods described in the embodiments of this application.

[0356] Based on the above embodiments, this application provides a chip system including a processor for supporting a computer device in implementing the methods described in the embodiments of this application. In one possible design, the chip system further includes a memory for storing necessary programs and data of the computer device. This chip system may be composed of chips or may include chips and other discrete devices.

[0357] Based on the above embodiments, this application provides a communication system, including: a first device and a second device, and optionally, a server (i.e., a cloud-side device). For details regarding the method steps performed by the first device, the second device, and the server, please refer to the preceding description.

[0358] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0359] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0360] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0361] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0362] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope and intent of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and variations.

Claims

1. An account login method, characterized in that, Applied to a communication system, the communication system including a first device and a second device, wherein the operating system of the first device is currently logged into a first account, the method includes: The second device displays a first interface, which is used to log in to an account; The first device displays a QR code scanning interface in response to detecting the second device approaching; In response to detecting the proximity of the first device, the second device displays a first graphic, which is used to establish near-field communication; The first device scans the first graphic through the scanning interface to establish a near-field communication connection with the second device; The first device sends first data to the second device through the near-field communication connection, the first data including the first login credentials of the first device; The second device logs into the first account based on the first login credential.

2. The method according to claim 1, characterized in that, The first interface includes any one of the following: The first interface is the login interface for the account in the settings application of the second device. The first interface is an interface of the second device during the OOBE process, or The first interface is used to migrate data from other devices.

3. The method according to claim 1 or 2, characterized in that, The first device is currently in a no-network state.

4. The method according to any one of claims 1-3, characterized in that, Before the first device displays a QR code scanning interface in response to detecting the proximity of the second device, the method further includes: the first device displaying a lock screen, a black screen, a desktop, a negative one screen, or an application interface.

5. The method according to any one of claims 1-4, characterized in that, The detection of the second device approaching includes: detecting that the distance between the first device and the second device is less than a first distance, and / or receiving a request signal broadcast by the second device, the request signal being a short-range communication signal; The detection of the first device approaching includes: detecting that the distance between the first device and the second device is less than a second distance, and / or receiving an agreement signal returned by the first device.

6. The method according to any one of claims 1-5, characterized in that, In response to detecting the approach of the second device, the first device displays a QR code scanning interface, including: In response to detecting the second device approaching, the first device displays a prompt message, which asks whether the user agrees to allow the second device to log in to the first account. When the first device receives the consent request, it displays the QR code scanning interface.

7. The method according to claim 6, characterized in that, The method further includes: the first device sending an agreement instruction to the second device, the agreement instruction indicating consent for the second device to log in to the first account; the second device displaying a first graphic in response to detecting the first device approaching, including: the second device displaying the first graphic upon receiving the agreement instruction.

8. The method according to any one of claims 1-7, characterized in that, The first login credential is a token.

9. The method according to any one of claims 1-8, characterized in that, The first data does not contain the login password of the first account, and / or the first data is encrypted using a first key, which is a key agreed upon by the first device and the server corresponding to the first account.

10. The method according to any one of claims 1-9, characterized in that, In response to detecting the approach of the second device, the first device displays a QR code scanning interface, including: In response to detecting the second device approaching, the first device displays N accounts of the first device, where N is a positive integer; When the first device receives an operation to select the first account, it displays the QR code scanning interface.

11. The method according to claim 1, characterized in that, The second device logs into the first account based on the first login credential, including: The second device sends a login request to the server corresponding to the first account. The login request is used to request login to the first account, and the login request includes the first login credential. The second device receives the second login credential sent by the server.

12. The method according to claim 11, characterized in that, Before the second device receives the second login credential sent by the server, the method further includes: The second device receives a prompt message sent by the server, the prompt message being used to indicate that the first device needs to connect to the network for authentication; The second device sends the prompt message to the first device via the near-field communication connection; The first device outputs the prompt information; After the first device connects to the network, it sends authentication information to the server, which indicates that the second device is authorized to log in to the first account.

13. The method according to any one of claims 2-12, characterized in that, When the first interface is an interface used for migrating data from other devices, the method further includes: The first device sends second data to the second device through the near-field communication connection, the second data including user data stored in the first device; The second device stores the second data.

14. An account login method, characterized in that, Applied to a first device, the operating system of the first device is currently logged into a first account, the method includes: The first device displays a QR code scanning interface in response to detecting the second device approaching; The first device scans the first graphic on the second device through the scanning interface to establish a near-field communication connection with the second device. The first device sends first data to the second device through the near-field communication connection. The first data includes a first login credential of the first device, which is used by the second device to log in to the first account.

15. The method according to claim 14, characterized in that, The first device is currently in a no-network state.

16. The method according to claim 14 or 15, characterized in that, Before the first device displays a QR code scanning interface in response to detecting the proximity of the second device, the method further includes: the first device displaying a lock screen, a black screen, a desktop, a negative one screen, or an application interface.

17. The method according to any one of claims 14-16, characterized in that, In response to detecting the approach of the second device, the first device displays a QR code scanning interface, including: In response to detecting the second device approaching, the first device displays a prompt message, which asks whether the user agrees to allow the second device to log in to the first account. When the first device receives the consent request, it displays the QR code scanning interface.

18. The method according to any one of claims 14-17, characterized in that, The first login credential is a token.

19. The method according to any one of claims 14-18, characterized in that, The first data does not contain the login password of the first account, and / or the first data is encrypted using a first key, which is a key agreed upon by the first device and the server corresponding to the first account.

20. The method according to any one of claims 14-19, characterized in that, In response to detecting the approach of the second device, the first device displays a QR code scanning interface, including: In response to detecting the second device approaching, the first device displays N accounts of the first device, where N is a positive integer; When the first device receives an operation to select the first account, it displays the QR code scanning interface.

21. The method according to any one of claims 14-20, characterized in that, The method further includes: The first device receives a prompt message sent by the second device through the near-field communication connection. The prompt message is used to indicate that the first device needs to be connected to the network for authentication. The first device outputs the prompt information; After the first device connects to the network, it sends authentication information to the server corresponding to the first account. The authentication information is used to indicate that the second device is allowed to log in to the first account.

22. The method according to any one of claims 15-21, characterized in that, When the first interface is an interface used for migrating data from other devices, the method further includes: The first device sends second data to the second device through the near-field communication connection, the second data including user data stored in the first device.

23. An account login method, characterized in that, Applied to a second device, the method includes: The second device displays a first interface, which is used to log in to an account; In response to detecting the proximity of the first device, the second device displays a first graphic, which is used to establish near-field communication; The second device, in response to the first device scanning the first pattern, establishes a near-field communication connection with the first device; The second device receives first data sent by the first device through the near-field communication connection, the first data including the first login credentials of the first device; The second device logs into the first account based on the first login credential.

24. The method according to claim 23, characterized in that, The first interface includes any one of the following: The first interface is the login interface for the account in the settings application of the second device. The first interface is an interface of the second device during the OOBE process, or The first interface is used to migrate data from other devices.

25. The method according to claim 23, characterized in that, Before the second device displays the first graphic in response to detecting the first device approaching, the method further includes: when the second device receives an consent instruction sent by the first device, displaying the first graphic, the consent instruction being used to indicate consent for the second device to log in to the first account.

26. The method according to any one of claims 23-25, characterized in that, The first login credential is a token.

27. The method according to any one of claims 23-26, characterized in that, The first data does not contain the login password of the first account, and / or the first data is encrypted using a first key, which is a key agreed upon by the first device and the server corresponding to the first account.

28. The method according to any one of claims 23-27, characterized in that, The second device logs into the first account based on the first login credential, including: The second device sends a login request to the server corresponding to the first account. The login request is used to request login to the first account, and the login request includes the first login credential. The second device receives the second login credential sent by the server.

29. The method according to claim 28, characterized in that, Before the second device receives the second login credential sent by the server, the method further includes: The second device receives a prompt message sent by the server, the prompt message being used to indicate that the first device needs to connect to the network for authentication; The second device sends the prompt message to the first device via the near-field communication connection.

30. The method according to any one of claims 25-29, characterized in that, When the first interface is an interface used for migrating data from other devices, the method further includes: The second device receives second data sent by the first device through the near-field communication connection, the second data including user data stored in the first device; The second device stores the second data.

31. An account login method, characterized in that, Applied to a server, the method includes: Receive a login request sent by a second device, the login request being used to request login to a first account, the login request including a first login credential of the first device; Send the second login credential to the second device.

32. The method according to claim 31, characterized in that, The login request includes a first code value; before sending the second login credential to the second device, the method further includes: It is determined that the first code value is a code value that the server has sent to the second device, and that the first code value is within its validity period.

33. The method according to claim 31 or 32, characterized in that, Before sending the second login credential to the second device, the method further includes: Send a prompt message to the second device, the prompt message being used to indicate that the first device needs to connect to the network for authentication; The system receives authentication information sent by the first device, which indicates that the second device agrees to log in to the first account.

34. A communication system, characterized in that, include: A first device is configured to perform the method as described in any one of claims 14-22; A second device is used to perform the method as described in any one of claims 23-30.

35. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 14 to 22, or the method as described in any one of claims 23 to 30, or the method as described in any one of claims 31 to 33.

36. A chip system, characterized in that, The chip system includes a processing circuit and a storage medium, wherein the storage medium stores instructions; when the instructions are executed by the processing circuit, they implement the method as described in any one of claims 1 to 33.

37. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 33.

38. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 33.

Images