Permission sharing method, device and system

Abstract

A permission sharing method, a device and a system, relating to the technical field of communications. The method can be applied to a first device (101), and comprises: the first device (101) may display a sharing interface of a target game, the target game being one of games for which a first account possesses a use permission, the first account being associated with at least one game character in the target game, the game character being used for representing the identity of a user in the target game, and the use permission of the first account for the target game comprising the permission to enter the target game with the game character; and the first device (101) may also acquire permission sharing information in response to a first trigger operation on the sharing interface, the permission sharing information being used for entering the target game with the game character on a second device (102). A user can share the use permission of a game character with other users, without sharing a user account and a password, thereby reducing the sharing cost of the user while ensuring the security of the user account. The use experience of the user is improved.

Description

Method, device and system for sharing permission

[0001] The present application claims priority to the Chinese patent application No. 202411038870.8, filed on July 30, 2024, and entitled "Method, device and system for sharing permission", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the field of communication technology, in particular to a method, device and system for sharing permission. BACKGROUND

[0003] With the development of network communication technology, electronic devices such as mobile phones have been highly integrated into people's daily life as an irreplaceable medium for people's daily communication and entertainment.

[0004] Generally, a user can log in to a game platform of a mobile phone with an account and play various types of games in the game platform after logging in to achieve entertainment. In order to facilitate login, the user account can be associated with multiple games in the game platform after the user logs in to the game platform using the user account. Thus, if a first user wants to share the use permission of a game A in the game platform with a second user, the first user's account and password must be shared. In this way, the second user can not only obtain the use permission of the game A, but also obtain the use permission of other games in the game platform. The first user cannot share the use permission of a certain game, and the second user can also use other games not shared by the first user at will, which may easily infringe the privacy information of the first user, thereby reducing the user experience. SUMMARY

[0005] The present application provides a method, device and system for sharing permission, which can meet the needs of users sharing the use permission of a game role with other users without sharing the user account and password, thereby improving the user experience.

[0006] To achieve the above-mentioned purpose, the present application adopts the following technical solutions:

[0007] In a first aspect, the present application provides a method for sharing permission, applied to a first device, the method comprising: the first device can display a sharing interface of a target game, the target game being one of the games having a use permission of a first account, the first account being associated with at least one game role under the target game, the game role being used to represent the identity of a user in the target game, and the use permission of the first account for the target game including the permission to enter the target game with the game role. The first device can also acquire permission sharing information in response to a first triggering operation on the sharing interface, the permission sharing information being used to enter the target game with the game role on a second device.

[0008] Thus, in a scenario where the game is associated with at least one game role, the first device can obtain the permission sharing information so as to be sent to the second device subsequently. The user can enter the target game with the game role on the second device. In this way, the embodiments of the present application can meet the requirement of sharing the use permission of the game role by the user to other users, without sharing the user account and password, thereby reducing the sharing cost of the user while ensuring the security of the user account, avoiding the invasion of the privacy information of the user, and improving the use experience of the user.

[0009] In an implementable manner, the first device can display a sharing user interface, the sharing user interface including at least one to-be-shared user. The first device can further send, in response to a second triggering operation on the sharing user interface, the permission sharing information to the second device, the user of the second device being one of the at least one to-be-shared user.

[0010] Thus, in the embodiments of the present application, the first device can send the permission sharing information to the second device, so as to facilitate the user of the second device to enter the target game with the target role on the second device. In the process of permission sharing, the user does not need to share the user account and password with other users, and the user can share the use permission of the game role in the target game. The security of the user account is ensured while reducing the sharing cost of the user, thereby improving the use experience of the user.

[0011] In an implementable manner, the permission sharing information includes a shared role identifier; the shared role identifier representing one or more game roles shared by the first device to the second device; the shared role identifier being used for the server to verify a target role in a login request of the second device; and the login request being used for requesting to enter the target game with the target role on the second device.

[0012] In an implementable manner, in the process of obtaining the permission sharing information in response to the first triggering operation on the sharing interface, the first device can send an obtaining request to the server, the obtaining request including the first account, a game identifier of the target game, and a role identifier of the game role. The first device can further receive the permission sharing information sent by the server, the shared role identifier in the permission sharing information being generated by the server based on the first account, the game identifier, and the role identifier.

[0013] In an implementable manner, the first device can receive authorization verification information, and perform an authorization operation according to the received authorization verification information. The authorization operation is used for authorizing to enter the target game with the target role on the second device. The authorization verification information is sent by the server in response to a login request of the second device.

[0014] Specifically, the first device can send authorization verification information to the second device. The authorization verification information is used by the second device to send to the server, so that the server performs login verification on the login request based on the received authorization verification information.

[0015] The first device can also send authorization confirmation information to the server in response to a confirmation operation on the authorization verification interface, the authorization confirmation information being used to instruct the server to authorize the second device to enter the target game in the target role.

[0016] Thus, in the embodiments of the present application, after the first device sends the permission sharing information to the second device and the second device sends the login request to the server, the first device needs to authorize the second device. Specifically, the first device can directly send authorization verification information to the second device, and can also send authorization confirmation information to the server in response to a confirmation operation on the authorization verification interface to authorize the second device. In this way, the shared user can log in to the target game in the target role through the second device. The shared user does not need to share the first account and password, but only needs to perform the authorization operation. Therefore, the flexibility of the authorization method and the user experience are improved.

[0017] In one implementation manner, the target game is one of the games in the game platform in the first device, the first account is the current login account of the game platform, and the current login account of the game platform in the second device is the second account.

[0018] In a second aspect, the embodiments of the present application also provide a permission sharing method applied to a second device, which includes that the second device can receive permission sharing information sent by a first device, the permission sharing information being used to enter a target game in a game role under the target game on the second device, the target game being one of games for which a first account has a use permission, the first account being associated with at least one game role under the target game, the game role being used to represent the identity of a user in the target game, and the use permission of the first account for the target game including a permission to enter the target game in the game role. The second device can display the permission sharing information on a user sharing interface.

[0019] Thus, in the scenario where a game is associated with at least one game role, the second device can receive the permission sharing information sent by the first device and display the permission sharing information on the user sharing interface. In this way, the user can enter the target game in the game role on the second device. The embodiments of the present application can meet the requirement of sharing the use permission of the game role by the user to other users, without sharing the user account and password, thereby reducing the sharing cost of the user while ensuring the security of the user account and improving the user experience.

[0020] In one possible implementation, the permission sharing information includes a shared role identifier; the shared role identifier represents one or more game roles shared by the first device to the second device; the shared role identifier is used by the server to verify the target role in the login request of the second device; the login request is used to request to enter the target game on the second device with the target role.

[0021] In one possible implementation, the method further includes: the second device can also send a login request to the server in response to a third triggering operation regarding the shared permission information; the login request includes a shared role identifier; the login request is used to request entry into the target game as the target role. The second device can also receive login confirmation information sent by the server, and display the logged-in interface of the target game based on the login confirmation information. The login confirmation information is sent by the server after the first device authorizes the second device to enter the target game as the target role.

[0022] Therefore, in this embodiment, the second device needs to receive a login request from the server while displaying the logged-in interface. In other words, the server needs to obtain the authorization result from the first device. Only after the server determines that the first device has authorized the second device to log in to the target game with the target character can the second device display the logged-in interface. This improves the security of the permission sharing process and enhances the user experience.

[0023] In one possible implementation, before the second device sends a login request to the server in response to a triggering operation for permission sharing information, the method further includes: the second device receiving an operation from the user selecting a target character from multiple game characters when the shared role identifier represents multiple game characters.

[0024] Thus, the first device in this embodiment can also share the usage rights of multiple game characters to the second device. When the shared character identifier represents multiple game characters, the second device can receive an operation from the user selecting a target character from among the multiple game characters. That is, the user can also select any one of the multiple game characters on the second device to log in to the target game, improving the flexibility of permission sharing.

[0025] In one possible implementation, before the second device receives the login confirmation information sent by the server, the method further includes: the second device receiving authorization verification information sent by the first device, the authorization verification information being sent by the server to the first device in response to the login request. The second device can send the authorization verification information to the server, so that the server can perform login verification on the login request based on the received authorization verification information.

[0026] Thus, in this embodiment, before receiving the login confirmation information from the server, the second device can receive the authorization verification information from the first device to authorize the second device to have the usage permissions corresponding to the game character. The second device also needs to send authorization verification information to the server so that the server can perform login verification. In this way, only after the second device has been authorized by the first device and verified by the server can the logged-in interface of the target game be displayed. This improves the sharing security of the permission sharing process and enhances the user experience.

[0027] Thirdly, this application also provides a permission sharing method applied to a server. The method includes: the server receiving an acquisition request sent by a first device, the acquisition request being used to acquire permission sharing information, the permission sharing information being used on a second device to enter a target game with a game character under a target game, the target game being one of the games that the first account has usage permissions for, the first account being associated with at least one game character under the target game, the game character being used to represent the user's identity in the target game, and the first account's usage permissions for the target game including the permission to enter the target game with a game character. The server can also generate permission sharing information according to the acquisition request and send the permission sharing information to the first device.

[0028] Thus, in this embodiment, the server can generate and send permission-sharing information to the first device based on the acquisition request sent by the first device. This permission-sharing information is used on the second device to enter the target game with a game character under the target game. After the first device sends this permission-sharing information to the second device, the second device can enter the target game with the target character based on the permission-sharing information. In this way, a user can share the usage rights of a game character with other users, who can then log in to the target game on their own devices with the shared game character. This eliminates the need to share user accounts and passwords, ensuring user account security while reducing sharing costs for users and improving the user experience.

[0029] In one possible implementation, the acquisition request includes a first account, a game identifier corresponding to the target game, and a role identifier for the game character; the permission sharing information includes a shared role identifier, which is generated based on the first account, the game identifier, and the role identifier; the shared role identifier represents at least one game character associated with the first account; the shared role identifier is used by the server to verify the target role in the login request of the second device, and the login request is used to request to enter the target game on the second device with the target role.

[0030] In one possible implementation, the server can receive a login request sent by the second device. The login request includes a shared role identifier. The server can also respond to the login request by obtaining the authorization result of the first device. The authorization result indicates whether the first device authorizes the second device to enter the target game as the target role. If the first device authorizes the second device to enter the target game as the target role, the server can send a confirmation login information to the second device. The confirmation login information is used by the second device to display the logged-in interface of the target game. The logged-in role corresponding to the logged-in interface is the target role.

[0031] Thus, in this embodiment, after receiving a login request from the second device, the server needs to obtain the authorization result from the first device. Only after the server determines that the first device has authorized the second device to log in to the target game with the target character can it send confirmation login information so that the second device can display the logged-in interface. This improves the sharing security of the permission sharing process and enhances the user experience.

[0032] In one possible implementation, while responding to a login request and obtaining the authorization result from the first device, the server can also perform device authentication in response to the login request. After successful device authentication, authorization verification information is generated. This authorization verification information is sent from the first device to the second device, enabling the server to perform login verification on the login request based on the authorization verification information sent by the second device. The server can also send authorization verification information to the first device and receive authorization verification information sent by the second device.

[0033] In one possible implementation, during the process of responding to a login request and obtaining the authorization result of the first device, the server can also perform device authentication in response to the login request. After successful device authentication, the server can also generate authorization verification information and send it to the first device. The server can also receive authorization confirmation information sent by the first device in response to the authorization verification information, which indicates that the first device has authorized the second device to enter the target game with the target character.

[0034] Thus, in this embodiment, the server can authenticate the login request sent by the second device, and after successful authentication, generate authorization verification information to authorize the second device to enter the target game with the target role. Therefore, only after the server determines that the second device has the permission to use the target role can it control the second device to execute the subsequent process of displaying the logged-in interface. This improves the security of the permission sharing process and enhances the user experience.

[0035] In one implementation, the server can determine that the authorization verification information sent by the second device matches the authorization verification information sent to the first device, and then send a login confirmation message to the second device. In this way, by matching the authorization verification information sent by the second device with that sent to the first device, the server determines that the second device has the permissions to use the target role before controlling the second device to execute the subsequent process of displaying the logged-in interface. This further enhances the sharing security of the permission sharing process.

[0036] In one possible implementation, the server can establish a first correspondence and a second correspondence. The first correspondence represents the relationship between a shared role identifier and a user account within a preset validity period, while the second correspondence represents the relationship between login token information and a user account within the preset validity period. The user account is the login account for at least one game on the device, and the login token information is used by the server to verify login requests corresponding to the user account.

[0037] Thus, in this embodiment, the server can establish a first correspondence and a second correspondence, and use these two correspondences to authenticate the login request sent by the second device. Only after the server determines that the second device has the permissions to use the target role can it control the second device to execute the subsequent process of displaying the logged-in interface. This further enhances the sharing security of the permission sharing process.

[0038] In one possible implementation, the login request also includes login token information corresponding to the first account. During the device authentication process in response to the login request, the server can determine the user account corresponding to the shared role identifier based on the first correspondence. The server can also determine the user account corresponding to the login token information based on the second correspondence. When the server determines that the user account corresponding to the shared role identifier matches the user account corresponding to the login token information, and the user account is the first account, it determines the number of user accounts corresponding to the shared role identifier within a preset validity period based on the first correspondence. Device authentication is successful when the number of accounts equals a preset threshold.

[0039] Therefore, in this embodiment of the application, in order to determine whether the second device can log in to the target game with the target character, the server needs to perform a secondary authentication process, namely, account authentication based on the first correspondence and shared character identifier authentication based on the second correspondence. This secondary authentication process by the server further verifies the second device's device permissions, confirming its use rights to log in to the target game with the target character, thus improving the security of sharing.

[0040] In one possible implementation, when the server sends login confirmation information to the second device after the first device authorizes the second device to enter the target game with the target character, it can determine the number of user accounts corresponding to the shared character identifier in the authorization confirmation information within a preset validity period based on a first correspondence. The server can also send login confirmation information to the second device when it determines that the number of accounts equals a preset threshold.

[0041] Thus, in this embodiment of the application, when the first device authorizes the second device to enter the target game with the target character, the server can also perform login authentication based on the authorization confirmation information, and send login confirmation information to the second device when the login authentication is successful, so that the second device can display the logged-in interface.

[0042] Specifically, the server can determine the number of user accounts corresponding to the shared role identifier in the authorization confirmation information within a preset validity period based on the first correspondence. When the number of accounts equals a preset threshold, the server sends login confirmation information to the second device. In other words, the shared role identifier authentication process can be executed again during the login authentication process. This server-side authentication process further verifies the security of the second device, confirming its permission to log in to the target game with the target role, thus enhancing the security of the shared login.

[0043] Fourthly, embodiments of this application also provide a permission sharing method applied to a communication system, the communication system including a first device and a second device, the method including:

[0044] The first device displays the shared interface of the target game, which is one of the games that the first account has access to. The first account is associated with at least one game character in the target game. The game character is used to represent the user's identity in the target game. The first account's access to the target game includes the permission to enter the target game as a game character.

[0045] The first device responds to a first trigger operation on the shared interface, obtains permission sharing information, and uses the permission sharing information to enter the target game on the second device as a game character.

[0046] The first device displays a shared user interface, which includes at least one user to be shared with.

[0047] In response to a second triggering operation targeting a shared user interface, the first device sends permission sharing information to the second device, where the user of the second device is one of at least one users to be shared with.

[0048] The second device receives the permission sharing information sent by the first device.

[0049] The second device displays permission sharing information on the user sharing interface.

[0050] Therefore, the permission sharing method provided in this application embodiment can be applied to a communication system. In a scenario where the target game is associated with at least one game character, the first device can obtain permission sharing information and share this information with the second device. The second device can display this permission sharing information. In other words, a user can share the permissions of a game character with other users, who can then use that game character to enter the target game on their own devices. Thus, this application embodiment satisfies the need for users to share their game character usage permissions with other users without sharing their account and password, reducing sharing costs while ensuring user account security and improving the user experience.

[0051] In one possible implementation, the communication system further includes a server, and the method further includes:

[0052] The first device sends an acquisition request to the server, which includes the first account, the game identifier of the target game, and the character identifier of the game character.

[0053] The server generates permission sharing information based on the request. The permission sharing information includes a shared role identifier, which is generated based on the first account, the game identifier, and the role identifier. The shared role identifier represents at least one game role associated with the first account. The shared role identifier is used by the server to verify the target role in the login request of the second device. The login request is used to request to enter the target game on the second device with the target role.

[0054] The server sends permission sharing information to the first device.

[0055] Thus, in this embodiment, the server can generate and send permission-sharing information to the first device based on the acquisition request sent by the first device, so that the first device can subsequently send the permission-sharing information to the second device. The permission-sharing information includes a shared role identifier, which is used by the server to verify the target role in the login request of the second device. The login request is used to request entry into the target game on the second device with the target role. After the first device sends the permission-sharing information to the second device, the second device can enter the target game with the target role based on the permission-sharing information. In this way, users can share the usage rights of a game character with other users without sharing their user account and password, ensuring user account security while reducing sharing costs and improving the user experience.

[0056] Fifthly, embodiments of this application also provide an electronic device, which includes a memory and one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, which includes computer instructions, and when the computer instructions are executed by the processor, the electronic device performs the permission sharing method as described in the first aspect above, or performs the permission sharing method as described in the second aspect above, or performs the permission sharing method as described in the third aspect above.

[0057] Sixthly, embodiments of this application also provide a communication system, which includes a first device and a second device.

[0058] The first device is configured to display a shared interface of the target game, which is one of the games that the first account has access to. The first account is associated with at least one game character in the target game, and the game character is used to represent the user's identity in the target game. The first account's access to the target game includes the permission to enter the target game as a game character.

[0059] The first device is configured to, in response to a first trigger operation on the shared interface, acquire permission sharing information, which is used to enter the target game on the second device as a game character.

[0060] The first device is configured to display a shared user interface, which includes at least one user to be shared with.

[0061] The first device is configured to send permission sharing information to the second device in response to a second trigger operation for a shared user interface, wherein the user of the second device is one of at least one users to be shared with.

[0062] The second device is configured to receive permission sharing information sent by the first device.

[0063] The second device is configured to display permission sharing information on the user sharing interface.

[0064] In a seventh aspect, embodiments of this application also provide a computer-readable medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the permission sharing method as described in the first aspect above, or the permission sharing method as described in the second aspect above, or the permission sharing method as described in the third aspect above.

[0065] Eighthly, embodiments of this application also provide a computer program product containing instructions that, when executed on a computer or processor, cause the computer or processor to perform the permission sharing method as described in the first aspect above, or the permission sharing method as described in the second aspect above, or the permission sharing method as described in the third aspect above. Attached Figure Description

[0066] Figure 1 is a schematic diagram of an application scenario for game permission sharing provided in an embodiment of this application;

[0067] Figure 2 is a schematic diagram of an application scenario for sharing game character permissions provided in an embodiment of this application;

[0068] Figure 3 is a schematic diagram of the structure of a communication system provided in an embodiment of this application;

[0069] Figure 4 is a schematic diagram of the hardware structure of a mobile phone according to an embodiment of this application;

[0070] Figure 5 is a schematic diagram of the software structure of a mobile phone provided in an embodiment of this application;

[0071] Figure 6 is a schematic diagram of the interaction between a first mobile phone and a second mobile phone provided in an embodiment of this application;

[0072] Figure 7 is a schematic diagram of a management interface corresponding to a target application provided in an embodiment of this application;

[0073] Figure 8 is a schematic diagram of the interaction between a first mobile phone and a server provided in an embodiment of this application;

[0074] Figure 9 is a schematic diagram of a sharing link interface provided in an embodiment of this application;

[0075] Figure 10 is a schematic diagram of a sharing link interface provided in an embodiment of this application;

[0076] Figure 11 is a schematic diagram of a logged-in interface provided in an embodiment of this application;

[0077] Figure 12 is a schematic diagram of the interaction between a second mobile phone and a server provided in an embodiment of this application;

[0078] Figure 13 is a schematic diagram of a device authentication process provided in an embodiment of this application;

[0079] Figure 14 is a schematic diagram of an account authentication process provided in an embodiment of this application;

[0080] Figure 15 is a schematic diagram of a shared role identifier authentication process provided in an embodiment of this application;

[0081] Figure 16 is a schematic diagram of an authorization verification code interface provided in an embodiment of this application;

[0082] Figure 17 is a schematic diagram of the interaction between a first mobile phone and a server provided in an embodiment of this application;

[0083] Figure 18 is a schematic diagram of a push message interface provided in an embodiment of this application;

[0084] Figure 19 is a schematic diagram of a login authentication process provided in an embodiment of this application;

[0085] Figure 20 is a schematic diagram of a message notification interface provided in an embodiment of this application;

[0086] Figure 21 is a schematic diagram of the hardware structure of a mobile phone according to an embodiment of this application. Detailed Implementation

[0087] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can represent A or B. "And / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. In addition, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with basically the same function and effect.

[0088] Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or order of execution, and that "first," "second," etc., are not necessarily different. Furthermore, in some embodiments of this application, words such as "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0089] Furthermore, the device architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of device architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0090] Electronic devices such as mobile phones serve as indispensable mediums for daily communication and entertainment. Typically, users can log in to a mobile gaming platform and play various types of games within that platform. For convenience, after logging in with a user account, that account can be linked to multiple games on the platform.

[0091] Therefore, if a user wants to share or trade access to a specific game, they need to share their user account associated with that game platform. However, this user account is linked to all the games they've played on that platform. This makes it impossible to fulfill the user's desire to share or trade access to that specific game, and users may also unnecessarily share access to other games. This results in high sharing costs for users and a reduced user experience.

[0092] Based on the above, this application provides a permission sharing method, which can be applied to a first device. The method includes: the first device can display a shared interface of a target game, the target game being one of the games that the first account has access to, the first account being associated with at least one game character in the target game, the game character representing the user's identity in the target game, and the first account's access to the target game including the permission to enter the target game as a game character; the first device can also respond to a first trigger operation on the shared interface to obtain permission sharing information, and the permission sharing information is used to enter the target game as a game character on a second device.

[0093] The target game can be one of the games on the game platform on the first device, the first account is the currently logged-in account on the game platform, and the currently logged-in account on the game platform on the second device can be the second account.

[0094] It should be noted that the game platform proposed in this application embodiment can be a standalone game application, or it can be a comprehensive platform that aggregates multiple games, such as... Quick Games and Mini-programs, etc. A user account can be a user's communication account, such as a mobile phone number, etc. Account and Accounts, etc. This application does not specifically limit the game platform.

[0095] Referring to Figure 1, the user account on the first device can be a first account, which is associated with multiple games, such as game A, game B, and game C. Game A can be associated with a game character (e.g., character A), meaning the first account is associated with character A in game A. Character A represents the user's identity in game A. The first account's access rights to game A include entering game A as character A. Specifically, in response to the first user's sharing operation on game A, the first device can obtain access sharing information. This access sharing information is used to enter game A on the second device as character A, so that the first device shares the access rights of the game character in game A with the second device.

[0096] Thus, in scenarios where a game is associated with a game character, this embodiment of the application can allow users to share the usage rights of that game character with other users without sharing their user account and password, thereby reducing the sharing cost for users while ensuring user account security and improving the user experience.

[0097] Furthermore, in scenarios where a game involves multiple game characters, the usage rights of one or more game characters can be shared to a second device.

[0098] For example, some games support the creation of multiple game characters. Referring to Figure 2, the game has different game regions, and each game region allows a user to create one game character. Game A is associated with characters A, B, and C. Game B is associated with characters D and E, and game C is associated with character F. Thus, the first device can share the usage rights of character A in game A to the second device, or share the usage rights of characters A, B, and C in game A to the second device.

[0099] Specifically, the first device may, in response to a first trigger operation on the sharing interface, such as a sharing operation for a target character among at least one game character, acquire permission sharing information, which is used on the second device to enter the target game as the target character. Alternatively, the first device may also, in response to a first trigger operation on the sharing interface, such as a sharing operation for all game characters corresponding to the target game, acquire permission sharing information, which is used on the second device to enter the target game as any character among all game characters.

[0100] On one hand, in an embodiment of this application where the target game is associated with a game character, the first device can share the usage rights of that game character with the second device. In this way, the second user can log in to the target game on the second device using the game character corresponding to the first user.

[0101] On the other hand, in scenarios where the target game is associated with multiple game characters, the first device can share the usage permissions of the target character among the multiple game characters to the second device. This allows the second user to log in to the target game on the second device using the target character. Alternatively, the first device can also share the usage permissions of multiple game characters to the second device. The second user can then choose any one of the multiple game characters on the second device to log in to the target game. This increases the flexibility of permission sharing and avoids infringing on user privacy, thereby improving the user experience.

[0102] The permission sharing method provided in this application embodiment can be applied to a communication system. Referring to Figure 3, a communication system provided in this application embodiment includes a first device 101 (e.g., a first mobile phone of a first user), a second device 102 (e.g., a second mobile phone of a second user), and a server 103.

[0103] In some embodiments, a communication connection is established between the first device 101, the second device 102, and the server 103. The server 103 can serve as an interaction medium between the first device 101 and the second device 102. The server 103 is used to execute the corresponding permission-sharing services in the embodiments of this application to complete communication between devices. The server 103 can be implemented as a server cluster consisting of multiple servers, or as a single server.

[0104] In some embodiments, a wired or wireless communication connection may be included between the first device 101 and the second device 102. The communication connection established between the server 103 and the aforementioned devices may include a wireless communication connection.

[0105] In some embodiments, the wireless communication technologies used to establish wireless communication connections include, but are not limited to, at least one of the following: wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT) (e.g., classic Bluetooth or Bluetooth Low Energy (BLE) Bluetooth), near field communication (NFC), Zigbee, frequency modulation (FM), and infrared (IR).

[0106] It is understandable that since the first user shares the game character's usage rights with the second user, the first device 101 can act as the sharing device, and the second device 102 can act as the shared device.

[0107] In some examples, the first mobile phone can obtain permission-sharing information from the server and, in response to a triggering action on the shared user interface, send that permission-sharing information to the second mobile phone. The shared user interface includes at least one user to be shared with, and the user on the second mobile phone is one of those at least one user. In this way, the second mobile phone can log in to the target game using the game character associated with the first user.

[0108] The first device 101 and the second device 102 may include mobile phones, smartwatches, tablets, foldable electronic devices, desktop computers, laptops, handheld computers, laptops, Ultra-Mobile Personal Computers (UMPCs), netbooks, cellular phones, Personal Digital Assistants (PDAs), Augmented Reality (AR) devices, Virtual Reality (VR) devices, Artificial Intelligence (AI) devices, wearable devices, in-vehicle devices, and other electronic devices with communication capabilities. This application does not impose any special limitations on the specific type of electronic device.

[0109] Furthermore, the operating systems installed on the first device 101 and the second device 102 include, but are not limited to, those that... Or other operating systems. This application does not limit the specific type of electronic device or the type of operating system installed on it.

[0110] Of course, the communication system provided in this application embodiment may also include other electronic devices besides the first device 101, the second device 102, and the server 103. The communication system provided in this application embodiment includes, but is not limited to, information exchange between three devices, and may also include information exchange between one device and multiple devices. Those skilled in the art can determine the type and number of electronic devices according to actual needs, and these designs do not exceed the protection scope of this application embodiment.

[0111] The first device 101 and the second device 102 in this application embodiment can be implemented using different or the same devices. For example, the first device 101 and the second device 102 in this application embodiment can be implemented using the mobile phone 100 in FIG4. FIG4 shows a schematic diagram of the hardware structure of the mobile phone provided in this application embodiment.

[0112] As shown in Figure 4, the mobile phone 100 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.

[0113] The aforementioned sensor module 180 may include sensors such as 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, and a bone conduction sensor 180M.

[0114] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the mobile phone 100. In other embodiments of this application, the mobile phone 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

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

[0116] The controller can serve as the central nervous system and command center of the mobile phone 100. Based on the instruction operation code and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

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

[0118] 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.

[0119] The wireless communication function of mobile phone 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor.

[0120] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in mobile phone 100 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 antennas can be used in conjunction with a tuning switch.

[0121] The mobile phone 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0122] The display screen 194 is used to display the sharing interface of the target game, etc., allowing users to share the usage rights of the corresponding game character in the target game with other users. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Miniled LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the mobile phone 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0123] The mobile phone 100 can achieve shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0124] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0125] The mobile phone 100 can achieve audio functions such as music playback and recording through the audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0126] In some examples, the mobile phone can use its wireless communication module to obtain permission to share information from the server.

[0127] In some examples, the phone's display screen can show a shared user interface, and the processor can respond to the user's triggering action on the shared user interface by using a wireless communication module to send permission sharing information to other electronic devices, thereby sharing the usage rights of a game character in the target game with other electronic devices.

[0128] The software system of mobile phone 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture Android system as an example to illustrate the software structure of mobile phone 100.

[0129] Figure 5 is a schematic diagram of the software structure of a mobile phone according to an embodiment of this application.

[0130] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

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

[0132] As shown in Figure 5, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0133] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0134] As shown in Figure 5, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0135] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0136] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, and more.

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

[0138] The phone manager is used to provide communication functions for the mobile phone 100. For example, it manages call status (including connection, hang-up, etc.).

[0139] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0140] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0141] The Android Runtime consists of core libraries and a virtual machine. The Android Runtime is responsible for the scheduling and management of the Android system.

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

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

[0144] A system library can include multiple functional modules, such as a display module, a communication module, and a processing module.

[0145] In some examples, the communication module is used to obtain permission sharing information from the server side. The display module is used to display the shared user interface, and the processing module is used to respond to user triggering actions on the shared user interface, controlling the communication module to send the permission sharing information to other electronic devices, thereby sharing the usage rights of the game character in the target game with other electronic devices.

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

[0147] The following will describe in detail a permission sharing method provided by an embodiment of this application with reference to the accompanying drawings. In the following embodiments, a first device (e.g., a first mobile phone of a first user) and a second device (e.g., a second mobile phone of a second user) will continue to be used as examples. Referring to Figure 6, the method may include:

[0148] S601, the first mobile phone displays the shared interface of the target game.

[0149] S602, the first mobile phone responds to the first trigger operation of the shared interface of the target game and sends permission sharing information to the second mobile phone.

[0150] In some embodiments of this application, the first mobile phone can display a sharing interface of the target game, which can be used by users to share access permissions for game characters associated with the target game. For example, the sharing interface of the target game can be a management interface corresponding to a target application, which can be a game application for a single game or a game platform that aggregates multiple games.

[0151] The gaming platform may include social applications or short video applications, etc. This application does not limit the specific type of the target application. It is understood that users can use the target application to play games, as long as the target application has gaming functionality. Users can share the usage permissions of game characters in the management interface corresponding to the target application.

[0152] For example, referring to Figure 7, as shown in Figure 7(A), is a front view of the first mobile phone provided in an embodiment of this application. The main screen of the first mobile phone displays a target application icon 70, and the first user can click on the target application icon 70 to trigger entry into the user interface corresponding to the target application.

[0153] As shown in Figure 7(B), the first mobile phone responds to a click operation on the target application icon 70 and displays the user interface corresponding to the target application. The user interface may include recently played controls, first function controls (such as welfare function controls, comment function controls, settings function controls, and check update function controls, etc.), and second function controls (such as scene controls, store controls, discovery controls, and my controls, etc.). The first user can click on the recently played control to trigger entry into the target page corresponding to the recently played control. As shown in Figure 7(C), the first mobile phone responds to a click operation on the recently played control and displays the recently played target page. The target page may include the icon corresponding to game A, the open icon corresponding to game A, the icon corresponding to game B, the open icon corresponding to game B, the icon corresponding to game C, and the open icon corresponding to game C. Afterwards, the first user can also long-press the icon corresponding to game A to trigger entry into the management page corresponding to the long-pressed icon corresponding to game A. As shown in Figure 7(D), the first mobile phone responds to a long-press operation on the icon corresponding to game A and displays the management page of game A (i.e., the sharing interface of the target game). The management page for Game A includes controls for storage, notifications, permissions, and character management. The character management controls include controls for character A and a share control, as well as controls for character B and a share control. Finally, after confirming the target character to be shared, such as character A, the first user can click the share control for character A to share character A's usage permissions with the second user. In this way, the first phone responds to the first user's click on the share control for character A, triggering the sharing task and sending permission sharing information to the second phone, enabling the second user to log in to Game A on the second phone as character A.

[0154] In some embodiments of this application, the information sharing functionality can be implemented in the form of a link, a password, or the like.

[0155] In some embodiments of this application, during the process of the first mobile phone sending permission sharing information to the second mobile phone, it is necessary to obtain the permission sharing information from the server side.

[0156] Specifically, as shown in Figure 8, the first mobile phone sends an acquisition request to the server (e.g., S801). The acquisition request includes the first account, the game identifier of the target game, and the character identifier of the target character. The server receives the acquisition request from the first mobile phone and generates permission sharing information based on the request (e.g., S802). The permission sharing information includes a shared character identifier, which is generated based on the first account, the game identifier, and the character identifier. The server then sends the permission sharing information to the first mobile phone (e.g., S803).

[0157] The shared role identifier represents one or more game roles shared by the first mobile phone to the second mobile phone. The shared role identifier is used by the server to verify the target role in the login request of the second mobile phone. The login request is used to request to enter the target game on the second mobile phone with the target role.

[0158] In some embodiments of this application, the request may also include login token information corresponding to the first account, and the permission sharing information generated by the server may also include login token information corresponding to the first account.

[0159] The login token information is used to represent the authentication token corresponding to the first account. The login token information can be a random string or a randomly encrypted string, etc. It should be noted that the request may also include other authentication information corresponding to the first account. This application embodiment does not specifically limit the implementation method of the login token information.

[0160] The game identifier of the target game can be any identification information used to uniquely identify the target game, such as: the target game name (e.g., "Game A"), the corresponding preset value, the target game's application package name, the target game's application ID, or a system-generated string, or one or more plaintext or encrypted information. Alternatively, the game identifier of the target game can also be a preset encrypted field, a preset encrypted value, or a preset encrypted binary string, etc.

[0161] The target role's identifier can be any identifying information used to uniquely identify the target role, such as: the target role's name (e.g., "Role A"), a preset value corresponding to the target role, the target role's role number, or a system-generated string, or one or more plaintext or encrypted information. Alternatively, the target role's identifier can also be a preset encrypted field, a preset encrypted value, or a preset encrypted binary string, etc.

[0162] For example, the first mobile phone can send a retrieval request to the server. For instance, the first mobile phone calls the link generation interface, requesting the link microservice on the server to generate a link. The link microservice generates a shared role identifier based on the first account, game identifier, and role identifier in the retrieval request. The shared role identifier can be any identifier used to uniquely identify the shared role's identity during this sharing process. The link microservice can send permission sharing information, including the shared role identifier and login token information, to the first mobile phone. For instance, the link microservice concatenates the shared role identifier and login token information in the link and returns it to the first mobile phone.

[0163] In some embodiments of this application, after obtaining the permission sharing information from the server, the first mobile phone can directly trigger the process of sending the permission sharing information to the second mobile phone. Specifically, the first mobile phone displays a sharing user interface, which includes at least one user to be shared with. In response to a second triggering operation of the sharing user interface, the first mobile phone sends the permission sharing information to the second mobile phone, where the user of the second mobile phone is one of the at least one user to be shared with.

[0164] For example, referring to Figure 9(A), the first mobile phone can display a sharing interface in response to a click operation on the sharing control corresponding to character A. The first user can select the desired sharing method in the sharing interface, which can display applications that support sharing, such as controls for a first social application, controls for a second social application, and more corresponding controls. In response to the first user's click operation on the control corresponding to the first social application, the first mobile phone triggers the display of the sharing user interface of the first social application, as shown in Figure 9(B). The first user can select a second user who wants to share the game character with them in the sharing user interface. In response to the first user's click operation on the user control corresponding to the second user, the first mobile phone can display a first dialogue interface. During the display of the first dialogue interface, a link is sent to the second user. As shown in Figure 9(C), the first dialogue interface may include a link corresponding to game A.

[0165] As another example, referring to Figure 10(A), the first mobile phone, in response to a click operation on the sharing control corresponding to role A, can display a link generation interface. The first user can copy the link in the link generation interface and launch the first social application to share it with the second user. The link generation interface includes a copy control and a cancel control. In response to a click operation on the copy control, the first mobile phone saves the link to the clipboard. Next, in response to a launch operation on the first social application, the first mobile phone displays the sharing user interface of the first social application as shown in Figure 10(B). The first user can select the second user in the sharing user interface. In response to a click operation on the user control corresponding to the second user, the first mobile phone can display a first dialogue interface as shown in Figure 10(C). The first dialogue interface includes an input area. In response to a paste operation by the first user in the input area, the first mobile phone can directly insert the link corresponding to game A in the input area, or it can directly send the link corresponding to game A. When the first mobile phone detects the paste operation of the first user and sends it, it sends the link corresponding to game A to the second user, displaying the interface shown in Figure 10(D).

[0166] It should be noted that the embodiments of this application do not limit the specific process of the first mobile phone sending permission sharing information to the second mobile phone. The first user can use other applications to share permission sharing information with the second user.

[0167] Based on the above, in this embodiment, the first mobile phone can obtain permission sharing information from the server. This permission sharing information is used on the second mobile phone to enter the target game with the target character associated with the first account. The first mobile phone can also send the permission sharing information to the second mobile phone, so that the second user can subsequently enter the target game with the target character on the second mobile phone. During the permission sharing process, the first user does not need to share their user account and password with the second user, and the first user can only share the usage permissions of the target character in the target game. This reduces the user's sharing cost while ensuring user account security and improves the user experience.

[0168] S603, the second phone displays permission sharing information on the user sharing interface.

[0169] S604, the second mobile phone responds to the third trigger operation for permission sharing information and displays the logged-in interface of the target game, with the logged-in character corresponding to the target character.

[0170] In some embodiments of this application, the second mobile phone can receive permission sharing information sent by the first mobile phone and display the permission sharing information on the user sharing interface.

[0171] For example, referring to Figure 11(A), the second dialogue interface is the interface corresponding to the first social application on the second mobile phone, where the second user can interact with the first user. The second dialogue interface (the aforementioned user sharing interface) may include a link corresponding to game A shared by the first user.

[0172] In some embodiments of this application, a second user can click on the link corresponding to game A in the second dialog interface to trigger entry into the game interface corresponding to game A, and play game A using the target character. Referring to Figure 11(B), the second mobile phone can respond to the second user's click operation on the link and display the logged-in interface of game A, with the logged-in character corresponding to the target character.

[0173] In some embodiments of this application, as shown in FIG12, the second mobile phone can receive permission sharing information sent by the first mobile phone during the process of displaying the logged-in interface, and in response to the third trigger operation for the permission sharing information, send a login request to the server (S1201). The login request includes a shared role identifier and is used to request to enter the target game with the target role.

[0174] The server can respond to the login request and obtain the authorization result from the first mobile phone. The authorization result indicates whether the first mobile phone authorizes the second mobile phone to enter the target game as the target character (S1202). If the first mobile phone authorizes the second mobile phone to enter the target game as the target character, the server sends a login confirmation message to the second mobile phone (S1203). The login confirmation message is used by the second mobile phone to display the logged-in interface of the target game, and the logged-in character corresponding to the logged-in interface is the target character. The second mobile phone receives the login confirmation message sent by the server and displays the logged-in interface of the target game according to the login confirmation message (S1204). Where the permission sharing information includes the login token information corresponding to the first account, the login request sent by the second mobile phone may also include the login token information.

[0175] Therefore, in this embodiment, the second mobile phone needs the server to obtain the authorization result from the first mobile phone before displaying the logged-in interface. Only after the server confirms that the first mobile phone has authorized the second mobile phone to log in to the target game with the target character can the second mobile phone display the logged-in interface. This improves the security of the permission sharing process and enhances the user experience.

[0176] In some embodiments of this application, during the process of the server responding to the login request and obtaining the authorization result of the first mobile phone, it may respond to the login request and perform device authentication operations.

[0177] The following is an example of the process of authenticating a server.

[0178] In some embodiments of this application, the server may establish a first correspondence and a second correspondence.

[0179] The first correspondence represents the relationship between a shared role identifier and a user account within a preset validity period. The second correspondence represents the relationship between a user account and its corresponding login token information within a preset validity period, where the user account is the login account for at least one game on the device.

[0180] For example, after generating the permission sharing information, the server can establish the aforementioned first and second correspondences. These correspondences can be represented using an information list. The first list corresponding to the first correspondence can include a shared role identifier, a game identifier, a target role identifier, a user account, and a preset validity period. For instance, referring to Table 1 below, the shared role identifier in the first list can be "A-Little Flower," the game identifier can be "Game A," the target role identifier can be "Little Flower," the user account can be "First Account," and the preset validity period can be "2024.05.04-2024.05.10."

[0181] Table 1

[0182] The second list corresponding to the second correspondence includes login token information, user account, preset validity period, and status information. For example, referring to Table 2 below, the login token information in the second list can be "4G80X", the user account can be "First Account", the preset validity period can be "2024.05.04-2024.05.10", and the status information can be "1". The status information includes valid and invalid statuses; a valid status can be set to "1", and an invalid status can be set to "0". The status information is used to characterize whether the association between the corresponding data is valid within the preset validity period.

[0183] Table 2

[0184] Thus, in this embodiment, the server can authenticate subsequent login requests sent by the second mobile phone using the established first and second correspondence relationships. Only after the server determines that the second mobile phone has the permissions to use the target role can it control the second mobile phone to execute the subsequent process of displaying the logged-in interface. This further enhances the sharing security of the permission sharing process.

[0185] In some embodiments of this application, during the process of performing device authentication in response to a login request, the server may determine the user account corresponding to the shared role identifier based on a first correspondence. The server may also determine the user account corresponding to the login token information based on a second correspondence. When it is determined that the user account corresponding to the shared role identifier is consistent with the user account corresponding to the login token information, and the user account is the first account, the server determines the number of user accounts corresponding to the shared role identifier within a preset validity period based on the first correspondence. Device authentication is successful when the server determines that the number of accounts equals a preset threshold. The server may also generate authorization verification information after successful device authentication.

[0186] For example, referring to Figure 13, the server can receive a login request (S1301) and perform account authentication in response to the login request (S1302). After successful server account authentication, shared role identifier authentication is performed (S1303). After successful server shared role identifier authentication, device authentication is confirmed as successful and authorization verification information is generated (S1304). Of course, if server account authentication fails, a login failure message needs to be sent to the second mobile phone (S1305) so that the second mobile phone displays a login failure message. If server account authentication succeeds but shared role identifier authentication fails, the server also needs to send a login failure message to the second mobile phone (S1305).

[0187] The following will provide an example of how the server performs account authentication.

[0188] For example, referring to Figure 14, in response to a login request, the server can call the account authentication interface to trigger account authentication (S1401). The server can search for the user account corresponding to the shared role identifier in the first list (S1402). The server can search for the user account corresponding to the login token information in the second list (S1403). If the server successfully finds both the user account corresponding to the shared role identifier and the user account corresponding to the login token information, it determines whether the two user accounts are the same (S1404). If the two accounts are the same, the server's account authentication is successful (S1405). However, if the server fails to find the user account corresponding to the shared role identifier and / or fails to find the user account corresponding to the login token information, a login failure message is sent to the second mobile phone (S1406). If the server successfully finds both the user account corresponding to the shared role identifier and the user account corresponding to the login token information, but the two user accounts are different, a login failure message is also sent to the second mobile phone (S1406).

[0189] It should be noted that a successful user account search means that at least one record of the user account exists in both the first and second lists within the preset validity period. If no record of the user account exists in either the first or second list within the preset validity period, or if multiple records of the user account exist in either list within the preset validity period, the search fails.

[0190] The following will provide an exemplary description of the server's shared role identifier authentication process.

[0191] For example, referring to Figure 15, during the shared role identifier authentication process, the server can call the shared role identifier authentication interface to trigger shared role identifier authentication (S1501). The server can determine the number of user accounts corresponding to the shared role identifier within the preset validity period based on the first correspondence (S1502). The server determines whether the number of accounts is equal to 1 (S1503). If the number of accounts is equal to 1, the shared role identifier authentication process succeeds (S1504). If the number of accounts is less than or equal to 1, the shared role identifier authentication process fails, and a login failure message is sent to the second mobile phone (S1305).

[0192] Therefore, in this embodiment, in order to determine whether the second mobile phone can log in to the target game with the target character, the server needs to perform a secondary authentication process, namely, account authentication based on the first correspondence and shared character identifier authentication based on the second correspondence. This secondary authentication process by the server further verifies the second mobile phone's device capabilities, confirming its permission to log in to the target game with the target character, thus enhancing the security of the shared access.

[0193] In some embodiments of this application, the server may also generate authorization verification information and send it to the first mobile phone after successful device authentication. The first mobile phone can then perform an authorization operation based on the authorization verification information, which authorizes the second mobile phone to enter the target game with the target character.

[0194] Specifically, the first mobile phone can send authorization verification information to the second mobile phone. The second mobile phone can also send authorization verification information to the server. The server can also receive authorization verification information sent by the second mobile phone. This authorization verification information is used by the first mobile phone to send to the second mobile phone, so that the server can verify the login request based on the authorization verification information sent by the second mobile phone. Then, the server can determine that the authorization verification information sent by the second mobile phone is consistent with the authorization verification information sent to the first mobile phone, and send login confirmation information to the second mobile phone.

[0195] In one feasible approach, the authorization verification information generated by the server may include an authorization verification code. The server can generate an authorization verification code and send it to a first mobile phone. After receiving the authorization verification code, the first mobile phone can send it to a second mobile phone, thus authorizing the user. The second mobile phone can then send the authorization verification code to the server, allowing the server to obtain the authorization result from the first mobile phone. Alternatively, the second mobile phone can also send the authorization verification code to the server. After receiving the authorization verification code from the second mobile phone, the server determines that it matches the code sent to the first mobile phone and then sends login confirmation information to the second mobile phone.

[0196] For example, referring to Figure 16(A), the first mobile phone can display a verification code prompt interface, which may include an authorization verification code, such as 123456. The first user can share the authorization verification code with a second user to complete the authorization process. It should be noted that the first user can use an application on the first mobile phone to share the authorization verification code with the second user. Of course, the first user can also use other sharing methods to share the authorization verification code. The authorization verification code can be an SMS verification code, a password verification code, or a random numerical verification code, etc. This application does not limit the specific implementation form of the authorization verification code.

[0197] Thus, after clicking the link, the second user still needs to enter an authorization verification code. That is, before displaying the logged-in interface, the second phone can also display a verification code input interface, as shown in Figure 16(B). The second user can enter the authorization verification code into the input area of ​​the verification code input interface. In response to the input operation for the authorization verification code, the second phone sends the authorization verification code to the server, and the server obtains the authorization result from the first phone. After the server compares the authorization verification code sent by the second phone with the authorization verification code sent to the first phone, it confirms the login information with the second phone. Based on the confirmed login information, the second phone displays the logged-in interface, as shown in Figure 16(C).

[0198] Therefore, in this embodiment, after the first mobile phone shares the link with the second mobile phone and the second mobile phone opens the link, the first mobile phone also needs to authorize the second mobile phone. Specifically, the first mobile phone can authorize the second mobile phone via an authorization verification code. In this way, the second user logs into the target game with the target character. The first user does not need to share their first account and password; simple authorization via the authorization verification code is sufficient. This improves the flexibility of the authorization method and the user experience.

[0199] Simultaneously, before receiving the login confirmation information from the server, the second mobile phone also needs to send authorization verification information to the server so that the server can verify the login. In this way, only after the second mobile phone has been authorized by the first mobile phone and verified by the server can it subsequently display the logged-in interface of the target game. This enhances the security of the permission sharing process and improves the user experience.

[0200] In some other embodiments of this application, in addition to sharing the authorization verification code with the second user, the first user can also authorize the second user using the first mobile phone to directly trigger the second mobile phone to log in to the target game using the first account.

[0201] Specifically, in response to the login request, the server generates authorization verification information (see S1202 in Figure 12). Referring to Figure 17, the server sends the authorization verification information to the first mobile phone (S1701). The first mobile phone receives the authorization verification information sent by the server and can display the authorization verification interface based on the information (S1702). The first user can perform a confirmation operation on the authorization verification interface, and the first mobile phone, in response to the confirmation operation on the authorization verification interface, sends authorization confirmation information to the server (S1703). The server can perform login authentication based on the authorization confirmation information (S1704). When login authentication is successful, the server sends login confirmation information to the second mobile phone (see S1203 in Figure 12) so that the second mobile phone displays the logged-in interface.

[0202] During the login authentication process, the server can determine the number of user accounts corresponding to the shared role identifier in the authorization confirmation information within a preset validity period based on the first correspondence. When the number of accounts equals a preset threshold, the server sends login confirmation information to the second mobile phone. In other words, the shared role identifier authentication process described above can be executed again during the login authentication process.

[0203] The following will provide an example of the display format of the authorization verification interface.

[0204] In one possible implementation, the aforementioned authorization verification interface can be a push message interface. The authorization verification information generated by the server may include a push identifier and a shared role identifier, and the server sends the authorization verification information to the first mobile phone. The server may also establish a third correspondence, which represents the correspondence between the shared role identifier and the push identifier within a preset validity period.

[0205] For example, after generating authorization verification information, the server can establish the aforementioned third-party correspondence. This third-party correspondence can also be represented in the form of an information list. The third list corresponding to the third-party correspondence may include a shared role identifier, a push identifier, and a preset validity period.

[0206] The first mobile phone can display a push message interface based on the authorization verification information (as shown in Figure 18). The push message interface includes a prompt control, a cancel control, and a confirmation control corresponding to the push message prompt. The first user can click on the confirmation control to complete the authorization of the second mobile phone. In response to this click, the first mobile phone sends authorization confirmation information to the server. The authorization confirmation information includes an authorization confirmation identifier, a push identifier, and a shared role identifier. The server can perform login authentication based on the authorization confirmation information.

[0207] During the login authentication process on the server, the server can first perform push identifier authentication and shared role identifier authentication based on the authorization confirmation information. After both authentication processes are successful, the login authentication is confirmed to be successful.

[0208] Specifically, referring to Figure 19, the server can call the push confirmation interface (S1901) based on the authorization confirmation information to trigger login authentication. The server can determine the authorization confirmation identifier based on the authorization confirmation information (S1902). If the authorization confirmation identifier exists in the authorization confirmation information, the push identifier is checked (S1903).

[0209] For example, the server can look up the number of records corresponding to the push identifier in the third list. If the number of records corresponding to the push identifier equals a preset threshold, such as if the number of records corresponding to the push identifier is 1, the check is considered successful. After successfully checking the push identifier, the server performs shared role identifier authentication (S1904). When the shared role identifier authentication is successful, the server determines that login authentication is successful (S1905). It should be noted that S1904 is similar to S1303 above, and will not be described again here. If the server fails to check the push identifier and / or fails to authenticate the shared role identifier, it will also send a login failure message to the second mobile phone (S1305).

[0210] It should be noted that the server performing login authentication and the server generating authorization verification information can be the same or different servers. For example, the server performing login authentication can be an account server, and the server generating authorization verification information can be a push server. When login authentication is successful, the account server can send a push message request to the push server. The push server can generate authorization verification information based on the push message request and send it to the first mobile phone. Of course, the push server can also perform the above-described push authentication process. This application embodiment does not specifically limit the number, type, and corresponding execution process of servers.

[0211] In another possible implementation, the authorization verification interface described above can also be a message notification interface within the target application. The authorization verification information generated by the server includes the target application identifier and the shared role identifier. The server sends this authorization verification information to the first mobile phone, and the first mobile phone can display the message notification interface based on this authorization verification information (as shown in (C) of Figure 20).

[0212] For example, a first user can access the message notification interface within the target application's interface to authorize a second user. Referring to Figure 20(A), the user interface of the target application may also include a message control. In response to a click on this message control, the first mobile phone displays the message interface as shown in Figure 20(B).

[0213] The message interface includes message controls for system messages and message controls for comment messages. The first phone responds to a click on the system message control by displaying a message notification interface. This notification interface includes a message prompt control, a cancel control, and a confirmation control. The first user can click the confirmation control to authorize a second user.

[0214] In response to the click operation, the first mobile phone sends authorization confirmation information to the server. This authorization confirmation information includes an authorization confirmation identifier and a shared role identifier. The server performs login authentication based on this authorization confirmation information. In some examples, the server can perform shared role identifier authentication based on the shared role identifier in the authorization confirmation information. The server determines that login authentication is successful when the shared role identifier authentication is successful. It should be noted that the shared role identifier authentication process is similar to S1303 above and will not be repeated here.

[0215] Based on the above, this application embodiment enables users to share specified game characters with other users. For example, if a first user shares a link corresponding to a target character with a second user, after the second user opens the link, the first user can authorize the second user through methods such as sharing an authorization verification code, confirming a push message, or confirming an application notification. In this way, the second user can log in to the target game with the target character. This reduces the sharing cost for the first user, eliminating the need for unnecessary sharing of other games associated with the first user's account. Simultaneously, both the first and second users can share the target character, extending the game character's lifespan and thus increasing game revenue.

[0216] In some embodiments of this application, when the target game is associated with multiple game characters, the first mobile phone can share the usage rights of multiple game characters with the second mobile phone.

[0217] For example, the first mobile phone can send a request to the server, which includes role identifiers corresponding to multiple game characters. For instance, the first mobile phone calls a link generation interface to request a link microservice on the server to generate a link. Based on the first account, game identifier, and role identifiers corresponding to the multiple game characters in the request, the link microservice generates shared role identifiers corresponding to the multiple game characters. The link microservice can then send permission-sharing information to the first mobile phone, including the shared role identifiers corresponding to the multiple game characters and login token information.

[0218] For example, the linked microservice concatenates shared role identifiers and login token information corresponding to multiple game characters in the link and returns it to the first mobile phone. It should be noted that this embodiment does not limit the number of game characters shared by the first mobile phone to the second mobile phone, as indicated by the shared role identifier.

[0219] When a shared role identifier represents multiple game characters, the second mobile phone can also receive a user's action of selecting a target character from among these characters. The second user can select character A as the target character from among character A, character B, and character C. Before displaying the logged-in interface, the second mobile phone can display a character selection interface, which includes characters A, B, and C associated with game A. In response to the second user's click on the target character, such as character A, in the character selection interface, the second mobile phone can send a login request to the server. This login request includes the shared role identifier and login token information corresponding to the target character, such as character A, to enable subsequent login to the target game using the target character. It should be noted that the subsequent device authentication and login authentication processes performed by the server in response to the login request are similar to the above process and will not be elaborated upon here.

[0220] Thus, in this embodiment of the application, the first mobile phone can also share the usage rights of multiple game characters to the second mobile phone. The second user can also select any one of the multiple game characters on the second mobile phone to log in to the target game, thereby improving the flexibility of permission sharing.

[0221] In some solutions, multiple embodiments of this application can be combined, and the combined solution can be implemented. Optionally, some operations in the process of each method embodiment may be combined, and / or the order of some operations may be changed. Furthermore, the execution order between the steps of each process is merely exemplary and does not constitute a limitation on the execution order between steps; other execution orders are also possible. It is not intended to indicate that the execution order is the only possible order in which these operations can be performed.

[0222] Those skilled in the art will conceive of various ways to reorder the operations described in the embodiments of this application. Furthermore, it should be noted that process details involved in one embodiment of this application are similarly applicable to other embodiments, or different embodiments can be combined.

[0223] Furthermore, some steps in the method embodiments can be equivalently replaced with other possible steps. Alternatively, some steps in the method embodiments may be optional and can be deleted in certain use cases. Or, other possible steps may be added to the method embodiments.

[0224] Furthermore, the various method embodiments can be implemented individually or in combination.

[0225] This application also provides an electronic device, such as the mobile phone described above, as shown in FIG21. The mobile phone may include one or more processors 2110, memory 2120 and communication interface 2130.

[0226] The memory 2120, communication interface 2130, and processor 2110 are coupled together. For example, the memory 2120, communication interface 2130, and processor 2110 can be coupled together via bus 2140.

[0227] The communication interface 2130 is used for data transmission with other devices. The memory 2120 stores computer program code. The computer program code includes computer instructions, which, when executed by the processor 2110, cause the electronic device to perform the relevant method steps in the embodiments of this application.

[0228] Processor 2110 may be a processor or controller, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in connection with this disclosure. A processor may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0229] Bus 2140 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The aforementioned bus 2140 can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 21, but this does not indicate that there is only one bus or one type of bus.

[0230] This application embodiment also provides a permission sharing method applied to a communication system, the communication system including a first device and a second device, the method including:

[0231] The first device displays the shared interface of the target game, which is one of the games that the first account has access to. The first account is associated with at least one game character in the target game. The game character is used to represent the user's identity in the target game. The first account's access to the target game includes the permission to enter the target game as a game character.

[0232] The first device responds to a first trigger operation on the shared interface, obtains permission sharing information, and uses the permission sharing information to enter the target game on the second device as a game character.

[0233] The first device displays a shared user interface, which includes at least one user to be shared with.

[0234] In response to a second triggering operation targeting a shared user interface, the first device sends permission sharing information to the second device, where the user of the second device is one of at least one users to be shared with.

[0235] The second device receives the permission sharing information sent by the first device.

[0236] The second device displays permission sharing information on the user sharing interface.

[0237] In some embodiments of this application, the communication system further includes a server, and the method further includes: a first device sending an acquisition request to the server, the acquisition request including a first account, a game identifier of the target game, and a character identifier of the game character.

[0238] Based on the request, the server generates permission sharing information. This information includes a shared role identifier, generated based on the first account, game identifier, and character identifier. The shared role identifier represents at least one game character associated with the first account. This identifier is used by the server to verify the target character in the login request of the second device, which requests entry into the target game on the second device with the target character. The server then sends the permission sharing information to the first device.

[0239] This application also provides a communication system, which includes a first device and a second device. The first device is configured to display a shared interface of a target game, which is one of the games that the first account has access to. The first account is associated with at least one game character in the target game, and the game character is used to represent the user's identity in the target game. The first account's access to the target game includes the permission to enter the target game as a game character.

[0240] The first device is configured to, in response to a first trigger operation on the shared interface, acquire permission sharing information, which is used to enter the target game on the second device as a game character.

[0241] The first device is configured to display a shared user interface, which includes at least one user to be shared with.

[0242] The first device is configured to send permission sharing information to the second device in response to a second trigger operation for a shared user interface, wherein the user of the second device is one of at least one users to be shared with.

[0243] The second device is configured to receive permission sharing information sent by the first device.

[0244] The second device is configured to display permission sharing information on the user sharing interface.

[0245] This application also provides an electronic device, which includes a memory and one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, which includes computer instructions, and when the computer instructions are executed by the processor, the electronic device performs the relevant method steps in the above method embodiments.

[0246] This application also provides a communication device, which includes a memory and one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, which includes computer instructions, and when the computer instructions are executed by the processor, the communication device performs the relevant method steps in the above method embodiments.

[0247] This application also provides a computer-readable storage medium storing computer program code. When the processor executes the computer program code, the electronic device executes the relevant method steps in the above method embodiments.

[0248] This application also provides a computer program product containing instructions that, when executed on a computer or processor, cause the computer or processor to perform the relevant method steps as described in the above method embodiments.

[0249] This application also provides a chip system, including: a processor coupled to a memory, the memory being used to store programs or instructions, and when the program or instructions are executed by the processor, the chip system enables the methods in any of the above method embodiments.

[0250] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0251] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application does not specifically limit the type of memory or the arrangement of the memory and processor.

[0252] For example, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0253] The electronic devices, computer storage media, or computer program products provided in this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

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

[0255] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0257] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0258] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the contributing parts, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A method of sharing rights, characterized by The method applied to a first device comprises: displaying a sharing interface of a target game, the target game being one of games having a use right of a first account, the first account being associated with at least one game character under the target game, the game character being used to represent an identity of a user in the target game, the use right of the first account to the target game including a right of entering the target game with the game character; in response to a first trigger operation for the sharing interface, obtaining right sharing information, the right sharing information being used to enter the target game with the game character on a second device.

2. The method of claim 1, wherein, The method further comprises: displaying a sharing user interface, the sharing user interface including at least one to-be-shared user; in response to a second trigger operation for the sharing user interface, sending the right sharing information to a second device, a user of the second device being one of the at least one to-be-shared user.

3. The method according to claim 1 or 2, characterized in that, The right sharing information includes a shared character identifier; the shared character identifier represents one or more game characters shared by the first device to the second device; and the shared character identifier is used for the server to verify a target character in a login request of the second device. The login request is used to request to enter the target game with the target character on the second device.

4. The method of claim 3, wherein, The response to the first trigger operation for the sharing interface to obtain the right sharing information comprises: sending an obtaining request to a server, the obtaining request including the first account, a game identifier of the target game, and a character identifier of the game character; receiving the right sharing information sent by the server, the shared character identifier in the right sharing information being generated by the server based on the first account, the game identifier, and the character identifier.

5. The method according to claim 3 or 4, characterized in that, The method further comprises: receiving authorization verification information, the authorization verification information being sent by the server in response to the login request of the second device; performing an authorization operation according to the received authorization verification information, the authorization operation being used to authorize to enter the target game with the target character on the second device.

6. The method of claim 5, wherein, The performance of the authorization operation according to the received authorization verification information comprises: sending the authorization verification information to the second device; and the authorization verification information being used for the second device to send to the server, so that the server performs login verification on the login request based on the received authorization verification information.

7. The method of claim 5, wherein, The method further comprises: displaying an authorization verification interface according to the received authorization verification information; The performance of the authorization operation according to the received authorization verification information comprises: in response to a confirmation operation for the authorization verification interface, sending authorization confirmation information to the server, the authorization confirmation information being used to instruct the server to authorize the second device to enter the target game with the target character.

8. The method according to any one of claims 1 to 7, characterized in that, The target game is one of games in a game platform in the first device, the first account is a current login account of the game platform, and a current login account of the game platform in the second device is a second account.

9. A method of sharing rights, characterized by The method applied to a second device comprises: receiving, from a first device, permission sharing information for entering a target game on a second device with a game character in the target game, the target game being one of games for which a first account has a use permission, the first account being associated with at least one game character in the target game, the game character being used to represent an identity of a user in the target game, the use permission of the first account for the target game including a permission for entering the target game with the game character; displaying, on a user sharing interface, the permission sharing information.

10. The method of claim 9, wherein, The permission sharing information includes a shared character identifier, the shared character identifier representing one or more game characters shared by the first device to the second device, and the shared character identifier being used by the server to verify a target character in a login request of the second device. The login request is used to request entering the target game on the second device with the target character.

11. The method according to claim 9 or 10, characterized in that, The method further includes: in response to a third triggering operation on the permission sharing information, sending a login request to a server, the login request including the shared character identifier, and the login request being used to request entering the target game with the target character; receiving confirmation login information sent by the server, the confirmation login information being sent by the server after the first device authorizes the second device to enter the target game with the target character; and displaying a logged-in interface of the target game according to the confirmation login information.

12. The method of claim 11, wherein, Before the response to the triggering operation on the permission sharing information, the method further includes: in a case where the shared character identifier represents multiple game characters, receiving an operation of selecting a target character from the multiple game characters by a user.

13. The method according to claim 11 or 12, characterized in that, Before receiving the confirmation login information sent by the server, the method further includes: receiving authorization verification information sent by the first device, the authorization verification information being sent by the server to the first device in response to the login request; and sending the authorization verification information to the server, so that the server performs login verification on the login request based on the received authorization verification information.

14. A method of sharing rights, characterized by Applied to a server, the method includes: receiving an acquisition request sent by a first device, the acquisition request being used to acquire permission sharing information for entering a target game on a second device with a game character in the target game, the target game being one of games for which a first account has a use permission, the first account being associated with at least one game character in the target game, the game character being used to represent an identity of a user in the target game, the use permission of the first account for the target game including a permission for entering the target game with the game character; generating the permission sharing information according to the acquisition request; and sending the permission sharing information to the first device.

15. The method of claim 14, wherein, The acquisition request includes a first account, a game identifier corresponding to a target game, and a character identifier of a game character. The permission sharing information includes a shared character identifier, the shared character identifier representing one or more game characters shared by the first device to the second device, and the shared character identifier being used by the server to verify a target character in a login request of the second device. The login request is used to request entering the target game on the second device with the target character. The permission sharing information includes a shared role identifier, which is generated based on the first account, the game identifier, and the role identifier; and the shared role identifier represents at least one game role associated with the first account. The shared role identifier is used by the server to verify a target role in a login request of a second device, the login request being used to request entry into the target game on the second device in the target role.

16. The method according to claim 14 or 15, characterized in that The method further includes: receiving the login request sent by the second device, the login request including the shared role identifier; in response to the login request, obtaining an authorization result of the first device, the authorization result indicating whether the first device authorizes the second device to enter the target game in the target role; in a case where the first device authorizes the second device to enter the target game in the target role, sending confirmation login information to the second device, the confirmation login information being used by the second device to display a logged-in interface of the target game, the logged-in interface corresponding to a login role being the target role.

17. The method of claim 16, wherein, The response to the login request includes: in response to the login request, performing a device authentication operation; after successful device authentication, generating authorization verification information, the authorization verification information being used by the first device to send to the second device, so that the server performs login verification on the login request based on the authorization verification information sent by the second device; sending the authorization verification information to the first device; receiving the authorization verification information sent by the second device.

18. The method of claim 16, wherein, The response to the login request includes: in response to the login request, performing a device authentication operation; after successful device authentication, generating authorization verification information; sending the authorization verification information to the first device; receiving authorization confirmation information sent by the first device for the authorization verification information, the authorization confirmation information being used to indicate that the first device has authorized the second device to enter the target game in the target role.

19. The method of claim 17 or 18, wherein, The sending of the confirmation login information to the second device in a case where the first device authorizes the second device to enter the target game in the target role includes: determining that the authorization verification information sent by the second device is consistent with the authorization verification information sent to the first device, and sending the confirmation login information to the second device.

20. The method according to any one of claims 17-19, characterized by, The method further includes: establishing a first correspondence relationship and a second correspondence relationship; wherein the first correspondence relationship is used to represent a correspondence relationship between the shared role identifier and a user account within a preset validity period, and the second correspondence relationship is used to represent a correspondence relationship between login token information and a user account within the preset validity period, the user account being a login account of at least one game in the device, and the login token information being used by the server to perform login verification on a login request corresponding to the user account.

21. The method of claim 20, wherein, The login request also includes login token information corresponding to the first account, and the device authentication operation is performed in response to the login request, including: In response to the login request, the user account corresponding to the shared role identifier is determined according to the first correspondence relationship; According to the second correspondence relationship, the user account corresponding to the login token information is determined; When it is determined that the user account corresponding to the shared role identifier is consistent with the user account corresponding to the login token information, and the user account is the first account, the number of account numbers corresponding to the user account of the shared role identifier within the preset valid period is determined according to the first correspondence relationship; When it is determined that the number of account numbers is equal to the preset threshold, the device authentication is successful.

22. The method of claim 21, wherein, In the case that the first device authorizes the second device to enter the target game in the target role, the confirmation login information is sent to the second device, including: According to the first correspondence relationship, the number of account numbers corresponding to the shared role identifier in the authorization confirmation information within the preset valid period is determined; When it is determined that the number of account numbers is equal to the preset threshold, the confirmation login information is sent to the second device.

23. A method of sharing rights, characterized by The application is applied to a communication system, and the communication system includes a first device and a second device, and the method includes: The first device displays a shared interface of a target game, the target game is one of the games that the first account has a use right, the first account is associated with at least one game role under the target game, the game role is used to represent the identity of the user in the target game, and the use right of the first account to the target game includes the right to enter the target game in the game role; The first device acquires right sharing information in response to a first trigger operation on the shared interface, and the right sharing information is used to enter the target game in the game role on the second device; The first device displays a shared user interface, and the shared user interface includes at least one shared user; The first device sends the right sharing information to the second device in response to a second trigger operation on the shared user interface, and the user of the second device is one of the at least one shared user; The second device receives the right sharing information sent by the first device; The second device displays the right sharing information on a user sharing interface.

24. The method of claim 23, wherein, The communication system also includes a server, and the method further includes: The first device sends an acquisition request to the server, and the acquisition request includes the first account, the game identifier of the target game, and the role identifier of the game role; The server generates right sharing information according to the acquisition request; the right sharing information includes a shared role identifier, the shared role identifier is generated based on the first account, the game identifier and the role identifier; the shared role identifier represents at least one game role associated with the first account; the shared role identifier is used for the server to verify the target role in the login request of the second device, and the login request is used to request to enter the target game in the target role on the second device; The server sends the permission sharing information to the first device.

25. An electronic device, comprising: The electronic device includes a memory, one or more processors; the memory is coupled with the processors; wherein the memory has stored computer program codes, the computer program codes include computer instructions, when the computer instructions are executed by the processors, make the electronic device execute the permission sharing method as claimed in any one of claims 1-8, or execute the permission sharing method as claimed in any one of claims 9-13, or execute the permission sharing method as claimed in any one of claims 14-22.

26. A communication system, characterized by The communication system includes a first device and a second device; The first device is configured to display a sharing interface of a target game, the target game being one of the games that the first account has a use permission, the first account being associated with at least one game character under the target game, the game character being used to represent the identity of the user in the target game, the use permission of the first account for the target game including the permission to enter the target game with the game character; The first device is configured to, in response to a first trigger operation for the sharing interface, obtain permission sharing information, the permission sharing information being used to enter the target game with the game character on the second device; The first device is configured to display a sharing user interface, the sharing user interface including at least one to-be-shared user; The first device is configured to, in response to a second trigger operation for the sharing user interface, send the permission sharing information to the second device, the user of the second device being one of the at least one to-be-shared user; The second device is configured to receive the permission sharing information sent by the first device; The second device is configured to display the permission sharing information on a user sharing interface.

27. A computer readable medium characterized by The computer readable storage medium has stored instructions, when the instructions run on the electronic device, make the electronic device execute the permission sharing method as claimed in any one of claims 1-8, or execute the permission sharing method as claimed in any one of claims 9-13, or execute the permission sharing method as claimed in any one of claims 14-22.

28. A computer program product, characterised in that, The computer program product contains instructions, when the instructions run on the computer or the processor, make the computer or the processor execute the permission sharing method as claimed in any one of claims 1-8, or execute the permission sharing method as claimed in any one of claims 9-13, or execute the permission sharing method as claimed in any one of claims 14-22.

Images