Cross-device methods, devices, and computer-readable storage media for network applications

Abstract

The embodiment of the application discloses a cross-device method, device and computer readable storage medium of network application, wherein the method comprises the following steps: receiving a cross-device placeholder request of a target object, the cross-device placeholder request is used for requesting to reserve cross-device resources for the target object, and the cross-device placeholder request carries a first cross-device role data identifier. Cross-device resources are allocated for the target object based on the cross-device placeholder request, placeholder success return information is sent to an original device to trigger the original device to log out the target object. When receiving a cross-device login request initiated by the target object, cross-device role data of the target object is received from a client, and a second cross-device role data identifier is generated based on the cross-device role data. If the first cross-device role data identifier and the second cross-device role data identifier are the same, the cross-device role login of the target object is performed. By using the application, the cross-device efficiency can be improved, the occupied resource amount of cross-device can be saved, the cross-device success rate can be improved, and the applicability is strong.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet, in particular to a cross-device method of network application, a device and a computer readable storage medium. BACKGROUND

[0002] In some network applications, due to the limitation of the performance and resources of computer devices (or simply devices), in the process of using the network application, different devices can be used to carry the processes of application functions for different users to relieve the pressure of the devices. Taking network games as an example, game developers will build multiple independent servers, and players must select a server before entering the game and participate in the game in the selected server. In order to meet the interaction needs between players selecting different servers, game developers develop cross-server game play, that is, players selecting different servers (players selecting different servers) log in to a public server or a server where a group of players are located to participate in the cross-server game play. However, in the cross-server process, a large number of concentrated cross-server requests from players will cause the load of the cross-server processing process of the server to be too high, thereby causing the data of part of the players to be lost, the success rate of cross-server to be low, and the applicability to be poor. In addition, the servers need to undertake the migration of player data in the cross-server process, the data transmission amount is large, and the game operation cost is high. SUMMARY

[0003] The embodiments of the present application provide a cross-device method of network application, a device and a computer readable storage medium, which can improve the cross-device efficiency, save the occupied resource amount of cross-device, improve the success rate of cross-device, and have strong applicability.

[0004] In a first aspect, the embodiments of the present application provide a cross-device method of network application, which comprises:

[0005] receiving a cross-device placeholder request of a target object, the cross-device placeholder request being used to request to reserve cross-device resources for the target object, and the cross-device placeholder request carrying a first cross-device role data identifier of the target object;

[0006] allocating cross-device resources for the target object based on the cross-device placeholder request, and sending a placeholder success return information to an original device to trigger the original device to log out the target object;

[0007] when receiving a cross-device login request initiated by the target object, receiving cross-device role data of the target object from a client, and generating a second cross-device role data identifier based on the cross-device role data;

[0008] if the first cross-device role data identifier is the same as the second cross-device role data identifier, performing cross-device role login of the target object.

[0009] In a possible implementation, before the cross-device resource is allocated to the target object based on the cross-device placeholder request, the method further includes:

[0010] detecting whether the target object has an online role in the target device;

[0011] If it is detected that the target object has an online role in the target device, performing role logout on the online role or feeding back prompt information to the original device that the target object has an online role.

[0012] In a possible implementation, before the cross-device role login of the target object is performed, the method further includes:

[0013] filling the cross-device role data of the target object into a designated storage space of the target device for storing player role data.

[0014] In a second aspect, an embodiment of the present application provides a cross-device method of a network application, and the method includes:

[0015] receiving a cross-device request initiated by a target object, the cross-device request being used to request cross-device from an original device to a target device;

[0016] obtaining cross-device role data of the target object, generating a first cross-device role data identifier based on the cross-device role data, and sending a cross-device placeholder request carrying the first cross-device role data identifier to the target device, the cross-device placeholder request being used to request the target device to reserve cross-device resources for the target object;

[0017] when the placeholder success return information is received, performing cross-device role logout of the target object.

[0018] In a possible implementation, before the first cross-device role data identifier is generated based on the cross-device role data, the method further includes:

[0019] performing state verification on the cross-device role of the target object;

[0020] when it is verified that the cross-device role is in a target cross-device state, returning a cross-device failure notification to the client;

[0021] wherein the target cross-device state is that it is detected that, before the cross-device request is received, the cross-device request of the cross-device role has been received and the cross-device role is online.

[0022] In a third aspect, an embodiment of the present application provides a cross-device device of a network application, and the device is suitable for a target device, and the device includes:

[0023] The receiving module is configured to receive a cross-device placeholder request of a target object, the cross-device placeholder request being used to request reservation of cross-device resources for the target object, and the cross-device placeholder request carrying first cross-device role data identification of the target object;

[0024] The resource allocation module is configured to allocate cross-device resources for the target object based on the cross-device placeholder request received by the receiving module, and send placeholder success return information to the original device to trigger the original device to log out the target object;

[0025] The receiving module is further configured to receive cross-device role data of the target object from the client when receiving a cross-device login request initiated by the target object;

[0026] The identification generation module is configured to generate second cross-device role data identification based on the cross-device role data received by the receiving module;

[0027] The role login module is configured to perform cross-device role login of the target object when the first cross-device role data identification is the same as the second cross-device role data identification.

[0028] In a possible implementation, the device further comprises:

[0029] The online detection module is configured to perform role online detection on the target object, and perform role logout on an online role of the target object or feed back prompt information that the target object has an online role to the original device if the online role of the target object in the target device is detected.

[0030] In a fourth aspect, the embodiments of the present application provide a cross-device device of a network application, the device being applicable to an original device, and the device comprises:

[0031] The receiving module is configured to receive a cross-device request initiated by a target object, the cross-device request being used to request cross-device from the original device to a target device;

[0032] The identification generation module is configured to obtain cross-device role data of the target object, and generate first cross-device role data identification based on the cross-device role data;

[0033] The sending module is configured to send a cross-device placeholder request carrying the first cross-device role data identification generated by the identification generation module to the target device, the cross-device placeholder request being used to request the target device to reserve cross-device resources for the target object;

[0034] The receiving module is further configured to receive placeholder success return information from the target device;

[0035] The character logout module is configured to perform cross-device character logout of the target object when the receiving module receives the placeholder success return information.

[0036] In a fifth aspect, an embodiment of the present application provides a computer device, which comprises a processor, a memory and a network interface.

[0037] The processor is connected with the memory and the network interface, wherein the network interface is configured to provide a data communication function, the memory is configured to store program codes, and the processor is configured to invoke the program codes to execute the method in the first aspect or the second aspect.

[0038] In a sixth aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program comprises program instructions, and the program instructions are configured to be executed by the processor to execute the method in the first aspect or the second aspect.

[0039] In a seventh aspect, an embodiment of the present application provides a computer program product, which comprises computer instructions stored in a computer readable storage medium and adapted to be read and executed by a processor to enable a computer device with the processor to execute the method in the first aspect or the second aspect.

[0040] In the embodiment of the present application, the target device can receive a cross-device placeholder request of a target object, the cross-device placeholder request is used to request to reserve cross-device resources for the target object, and the cross-device placeholder request carries a first cross-device character data identifier. The target device allocates cross-device resources for the target object based on the cross-device placeholder request, and sends a placeholder success return information to the original device to trigger the original device to log out the target object. When receiving a cross-device login request initiated by the target object, the target device directly receives cross-device character data of the target object from the client, and the target device and the original device do not need to interact to backup the cross-device character data of the target object, so that the interaction link between devices can be shortened to improve the cross-device efficiency. In addition, the cross-device character data of the target object is uploaded by the client, which can solve the problem that the cross-device processing process of the device is overloaded due to a large number of concentrated cross-device requests in the process of transmitting the cross-device character data by the original device, improve the cross-device success rate, and have stronger applicability. The second cross-device character data identifier is generated based on the cross-device character data, and if the first cross-device character data identifier is the same as the second cross-device character data identifier, the cross-device character login of the target object is performed. BRIEF DESCRIPTION OF DRAWINGS

[0041] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1a This is a schematic diagram of a system architecture provided in an embodiment of this application;

[0043] Figure 1b This is another system architecture diagram provided in the embodiments of this application;

[0044] Figure 2 This is a flowchart illustrating a cross-device method for network applications provided in an embodiment of this application;

[0045] Figure 3 This is another flowchart illustrating the cross-device method for network applications provided in this application embodiment;

[0046] Figure 4 This is another flowchart illustrating the cross-device method for network applications provided in this application embodiment;

[0047] Figure 5 This is a schematic diagram of the structure of the first cross-device device provided in the embodiments of this application;

[0048] Figure 6 This is a schematic diagram of the structure of the second cross-device device provided in the embodiments of this application;

[0049] Figure 7 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0050] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0051] The cross-device method for network applications provided in this application embodiment can be executed by computer devices such as terminal devices or servers (or simply devices). The descriptions of servers, device terminals, computer devices, and devices mentioned in this application embodiment can refer to independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Terminal devices can be smart terminals capable of running the above applications, such as smartphones, tablets, laptops, desktop computers, PDAs, mobile internet devices (MIDs), wearable devices (e.g., smartwatches, smart bracelets), smart computers, and smart vehicles. The terminal devices and servers can be connected directly or indirectly via wired or wireless means; this application embodiment does not impose any limitations on this connection. For ease of description, the following will use devices as an example for illustration.

[0052] In this application embodiment, network applications may include, but are not limited to, online games, instant messaging applications, and web searches. For ease of description, this application embodiment will use online games as an example for illustration. To alleviate the operational pressure on devices, online game developers will equip multiple devices, with each device carrying a certain number of objects (such as game players) to solve the limitations of computer performance and resources, thereby enabling players to participate in cross-device games. Taking online games as an example, the aforementioned devices can be servers, and cross-device can mean cross-server (referred to as cross-server). This application embodiment will use the example of using multiple devices to achieve cross-device operation of online games or network work applications (which can be collectively referred to as network applications), and will not be elaborated further below.

[0053] The cross-device method for network applications provided in this application can be applied to players or objects (or users) from different servers in online games or network work applications logging into a public device (which can be a game server or a device platform with large computing power), or objects (e.g., players) from different servers (e.g., game servers) logging into the device where a group of objects (e.g., players) reside (e.g., players from one game server logging into another game server (i.e., switching from the server associated with the original game server to the server associated with another game server)) to participate in cross-device operations (e.g., cross-server gameplay). This method solves the problem of excessive server load on cross-device processing caused by a large number of concentrated cross-device requests when transmitting cross-device character data using the original device. It boasts a high cross-device success rate and strong applicability. Furthermore, using the client to handle cross-device character data migration reduces the resources consumed by data migration, improving cross-device efficiency while also reducing game operating costs.

[0054] See Figure 1a This is a schematic diagram of a system architecture provided in an embodiment of this application. Figure 1a As shown, the system architecture may include a service server 100a and a terminal cluster. The terminal cluster may include terminal devices 101a, 101b, ..., 101n. The service server 100a can establish communication connections with each terminal device in the terminal cluster. In other words, the service server 100a can establish communication connections with each terminal device among terminal devices 101a, 101b, ..., 101n. For example, a communication connection can be established between terminal device 101a and the service server 100. The communication connection method is not limited; it can be established directly or indirectly through wired communication or wireless communication, etc., depending on the actual application scenario. This application does not impose any restrictions on this.

[0055] It should be understood that, such as Figure 1a Each terminal device in the terminal cluster shown can have a client installed (such as a game client or a work client). When this client runs on each terminal device, it can interact with the aforementioned... Figure 1aThe business servers 100a shown interact with each other, enabling business servers 100a to receive business data from each terminal device. The client can be a network-based multiplayer interactive game (e.g., a multiplayer video game, referred to as an online game). The client can be a game client, and the categories of game clients include, but are not limited to, first-person shooter games, role-playing games, real-time strategy games, action games, adventure games, and strategy games. The client can also be a work client, and the categories of work clients include, but are not limited to, first-person work, role-playing work, real-time work, and interactive work. For example, a massively multiplayer online role-playing game (MMORPG) client can be installed on terminal device 101a, and its corresponding server can be business server 100a. That is, business server 100a can handle data interaction and business processing (or game progress) with the MMORPG client on terminal device 101a. Suppose that object A registers object account X through an MMORPG client in terminal device 101a. This account X can contain multiple characters. Then, business server 100a can carry the relevant game process of the characters in object account X registered by object A.

[0056] Understandably, to alleviate server load, developers of online games or online work applications often deploy multiple servers. Each server handles a specific number of objects to address limitations in computer performance and resources. For example, before entering the application, an object (or user) selects a server and participates in the game or work within that server. The selected server can correspond to one or more servers. For instance, object (or user) A registers an account X and selects a server (e.g., server Country-1). The server corresponding to this server could be business server 100a.

[0057] Please see also Figure 1b This is another system architecture diagram provided in an embodiment of this application. For example... Figure 1bAs shown, business server 101b is also a server provided by the developer of online games or online work applications. If object (or user) B registers object account Y and selects server Country-2, that is, object A and object B log in to different servers, and since the character data of objects in different servers are stored on different servers, object A and object B will be restricted in their interaction and cannot participate in application activities together (such as real-time battles, online chat, etc.). In order to realize the interaction of objects selected from different servers, one or more objects from different servers can be allowed to log in to a public server across devices, such as objects from different servers (such as game servers), and the public server can jointly host objects from different servers. Alternatively, objects from different servers can log in to a server where a certain group of objects reside, and the server where a certain group of objects resides can jointly host objects from different servers. This application embodiment will use the method of objects from different servers logging in to a server where a certain group of objects resides as an example for explanation, and will not be repeated below.

[0058] Understandably, in multiple servers within an online game or network application, the logical architecture of a single server can be divided into an access layer, a data layer, and a logic layer. The access layer is responsible for maintaining client connections, the data layer for storing object (or user) data, and the logic layer for carrying application processes. The logic layer can include zone layers and world layers. Zone layers are responsible for carrying application processes within specific application scenarios (such as application processes in a game scenario). A single server can have multiple different application scenarios, each handled by a corresponding zone layer. For example, server Country-1 can have application scenarios S11, S12, ..., S1n, and the application processes for these scenarios can be handled by zone11, zone12, ..., zone1n layers, respectively. The world layer is responsible for hosting application processes that manage online information within a server. Different world layers can handle the management of online information within different servers of the same network application. For example, if a network application has multiple servers, such as Country-1, Country-2, ..., Country-k, the application processes managing online information for each server can be hosted by world-1, world-2, ..., world-k layers. Furthermore, connections between the client and servers Country-1, Country-2, ..., Country-k can be established through the access layers Tconnd-1, Tconnd-2, ..., Tconnd-k, respectively, to facilitate data interaction with each server.

[0059] Specifically, the zone layer and the world layer can be business servers. A single business server can have both a zone layer and a world layer, or the zone layer and the world layer can each correspond to different business servers. Furthermore, when the zone layer and the world layer correspond to different business servers, a single server can correspond to all zone layers or all world layers, or different zone layers can correspond to different business servers, and different world layers can correspond to different business servers. The specific implementation depends on the actual application scenario and is not limited here. This application embodiment will use the example of zone layers and world layers corresponding to different business servers, with different zone layers corresponding to different business servers and different world layers corresponding to different business servers, for illustration. Please refer again... Figure 1b Each different single server (including server Country-1, server Country-2, ..., server Country-k) can have multiple application scenarios (including application scenario S11, application scenario S12, ..., application scenario Skn). Figure 1b The region-1 contains multiple business servers (i.e., business server 100a, business server 100b, ..., business server 100n), Country-2 contains multiple business servers (i.e., business server 101a, business server 101b, ..., business server 101n), and so on. Country-k also contains multiple business servers (i.e., business server 10ka, business server 10kb, ..., business server 10kn). Application processes for different application scenarios can be handled by the corresponding business servers (i.e., the zone layer within the logical layer of a single region-1 server). For example, business servers 100a, 100b, ..., 100n can respectively handle the application processes for application scenarios S11, S12, ..., S1n. In addition, the application processes managing online information in each region-1 server can also be handled by the relevant business servers within the region-1 server (i.e., the world layer within the logical layer of a single region-1 server). Figure 1b (Not shown in the image).

[0060] Figure 1bThe system also includes a business server 10 and a terminal device 20. The business server 10 and terminal device 20 can establish communication connections with each business server within each service area (this connection can be established through the access layer of each service area). The communication connection method is not limited; it can be established directly or indirectly through wired communication or wireless communication, etc., depending on the actual application scenario. This application does not impose any restrictions on this. To enable cross-service interaction, a global-proxy process can be used to handle cross-service data interaction. All cross-service data interaction in the network application is completed through a global-proxy cluster (which can consist of multiple global-proxy processes). The global-proxy process can be... Figure 1b The business server 10 (or global server) in the system hosts the data exchange between the origin and target devices when an object performs cross-device operations, involving the transmission of relevant cross-device instructions and business data. All of these data exchange processes can be implemented through the business server 10. The terminal device 20 can have a client (which can be an MMORPG client) installed. When this client runs on each terminal device, it can interact with... Figure 1b Data interaction is performed between the business servers configured in each single server region. After the terminal device 20 selects a server region through the installed MMORPG client, the server corresponding to the server region can carry the application processes related to the MMORPG client in the terminal device 20.

[0061] Assume terminal device 20 has an MMORPG client installed. Object (or user) A registers object account X through the MMORPG client on terminal device 20. Object account X can contain multiple roles, and object account X selects server Country-1 as the login server. Assume that role R1 in object account X is currently located in application scenario S11 hosted on business server 100a. Object A wants to move across devices to server Country-2, that is, log out of object account X from server Country-1 and log in to server Country-2. At this time, server Country-1 can be called the original server, and server Country-2 can be called the target server. It can be understood that if object A moves from server Country-2 to server Country-1, server Country-2 can be called the original server, and server Country-1 can be called the target server. Furthermore, the device corresponding to the original server can be the original device, which can consist of business servers within its corresponding server. For example, in this case, the original device consists of business servers in server Country-1 (including business servers 100a, 100b, ..., 100n, and business servers responsible for managing online information application processes, etc.). Similarly, the device corresponding to the target server can be the target device, which can consist of business servers within its corresponding server. For example, in this case, the target device consists of business servers in server Country-2 (including business servers 101a, 101b, ..., 101n, and business servers responsible for managing online information application processes, etc.). First, the originating device receives a cross-device request initiated by object A from the MMORPG client in terminal device 20. Based on this request, it obtains the cross-device role data of object A (i.e., role R1 in object account X) and generates a first cross-device role data identifier based on the aforementioned cross-device role data. It then sends a cross-device placeholder request carrying the first cross-device role data identifier of object A to the target device (data interaction between the originating device and the target device can be implemented through the global-proxy process in the business server 10, which will not be elaborated below). Next, the target device allocates cross-device resources for role R1 in object account X of object A based on the aforementioned cross-device placeholder request and sends a placeholder success return information to the originating device. When the originating device receives the placeholder success return information, it logs out role R1 in object account X and sends a cross-device notification to the MMORPG client to trigger the MMORPG client to send a cross-device login request and cross-device role data to the target device.Finally, the target device receives the cross-device login request initiated by object A from the MMORPG client, receives the cross-device role data from the MMORPG client, generates a second cross-device role data identifier based on the cross-device role data, and if the first cross-device role data identifier is the same as the second cross-device role data identifier, the target device executes the login of role R1 in object account X.

[0062] The following example illustrates a cross-device method for network applications. Please refer to [link to example]. Figure 2 , Figure 2 This is a flowchart illustrating a cross-device method for network applications provided in an embodiment of this application. For example... Figure 2 As shown, this method is applicable to target devices (such as target servers for online games or network work applications, or device platforms with large computing capabilities for online games or network work applications), and includes the following steps:

[0063] Step S101: Receive a cross-device placeholder request for the target object. The cross-device placeholder request is used to request that cross-device resources be reserved for the target object. The cross-device placeholder request carries the first cross-device role data identifier of the target object.

[0064] In some feasible implementations, the target device (which may be a server corresponding to the target region / server, or a device platform with large computing power corresponding to the target region / server) can receive a cross-device placeholder request and allocate cross-device resources (which may be a specified size of storage space for storing cross-device character data received from the client) to the target object (which may be a target player, or a player account that needs cross-device access) based on the cross-device placeholder request. The cross-device placeholder request may originate from the original device (which may be a server corresponding to the original region / server, or a device platform with large computing power corresponding to the original region / server). The cross-device placeholder request may contain a first cross-device character data identifier for the target object. This identifier is generated by the original device based on the cross-device character data and is used by the target device to verify the cross-device character data subsequently received from the client.

[0065] Step S102: Perform online role detection on the target object. If it is detected that the target object has an online role on the target device, then log out the online role or send a prompt message to the original device that the target object has an online role.

[0066] In some feasible implementations, to restrict each object account to logging in only one region / server and to prevent simultaneous logins via multiple clients, the object account needs to be logged out of the original device corresponding to the original region / server during cross-device processing. Login is only performed after confirming that the object account is not currently logged in on the target device. Therefore, upon receiving a cross-device placeholder request, the target device performs an online check on the target object for which cross-device resources need to be allocated. Specifically, each object's registered object account in the network application can contain multiple roles, and the object can select different roles after logging into the object account. During cross-device processing, the target device can detect the online status of the object account, i.e., obtain the object account's online information (login or offline). If it detects that a role is already logged in on the target device, the target device can send a notification to the original device indicating that the target object has an online role. The client receives the notification from the original device and displays it to the object. Based on this information, the object can log out of the online role on the target device through the client, preventing the object from simultaneously logging into the object account via multiple clients.

[0067] Optionally, in some feasible implementations, the target device can obtain the online information (login or logout) of the object account. If it detects that the object account is already logged in on the target device, the target device can also log out the online role of the object account. For example, if role R1 in object account X of object A wants to move from server Country-1 to server Country-2 across devices, and the target device corresponding to server Country-2 (or the target server) detects that object account X is already logged in on the target device and role R2 is already online, then the target device will log out the online role R2 of object account X, thus preventing the object from logging into the object account through multiple clients simultaneously.

[0068] Step S103: Allocate cross-device resources to the target object based on the cross-device placeholder request, and send a placeholder success return message to the original device to trigger the original device to log out of the target object.

[0069] In some feasible implementations, the target device receives a cross-device placeholder request from the originating device and allocates specified cross-device resources (which may be a specified size of storage space for storing cross-device role data received from the client) to the object account that needs cross-device access based on the cross-device placeholder request. For example, the target device allocates 300MB of storage space for each object account that needs cross-device access to store the cross-device role data received from the client.

[0070] Optionally, in some feasible implementations, the cross-device placeholder request received by the target device from the originating device includes cross-device object information. The target device can obtain the amount of cross-device role data from this cross-device object information to allocate cross-device resources based on this information. For example, if the target device obtains 500MB of cross-device role data from the cross-device object information in the cross-device placeholder request, then 500MB of storage space will be allocated to that object account to store the cross-device role data received from the client.

[0071] Optionally, in some feasible implementations, the target device allocates specified cross-device resources to the object account requiring cross-device access based on the cross-device placeholder request, and sends a placeholder success return message to the original device. This return message may contain authentication information from the target device, used for identity verification when the object account requiring cross-device access attempts to log in to the target device. Specifically, if the target device allows the object account corresponding to the current cross-device placeholder request to log in across devices, it adds authentication information to the placeholder success return message and sends the placeholder success return message to the original device. Upon subsequently receiving a cross-device login request from a client, the target device can then authenticate the object account based on this authentication information.

[0072] Step S104: When a cross-device login request initiated by the target object is received, the cross-device role data of the target object is received from the client, and a second cross-device role data identifier is generated based on the cross-device role data.

[0073] In some feasible implementations, when the target device receives a cross-device login request from a client, it receives the cross-device role data sent by the client. This cross-device role data may include role information such as experience, level, equipment, friends, role quests, and items of the role requiring cross-device access from the target account. Upon receiving the cross-device role data, a second cross-device role data identifier can be generated based on the data. This second cross-device role data identifier, along with the first cross-device role data identifier, is used by the target device to verify the cross-device role data. Specifically, an encryption algorithm can be used to generate the second cross-device role data identifier from the received cross-device role data. This encryption algorithm can be the MD5 Message-Digest Algorithm, a widely used cryptographic hash function that transforms data (such as text) into a fixed-length value. Based on the fundamental principles of hash algorithms, a 128-bit (16-byte) hash value can be generated, with different inputs yielding different outputs. This algorithm can be used to ensure the integrity and consistency of transmitted information. For example, the target device receives a cross-device login request from the client (which could be a character R1 in account X moving from server Country-1 to server Country-2). At the same time, it receives cross-device character data from the client (which could include character R1's experience, level, equipment, friends, character quests, and items). Based on the received cross-device character data, a 128-bit hash value (i.e., the second cross-device character data identifier) ​​can be generated using the MD5 message digest algorithm.

[0074] Optionally, in some feasible implementations, when the target device receives cross-device role data, it arranges the received cross-device role data. After receiving and arranging all the cross-device role data, it uses an encryption algorithm (such as the MD5 message digest algorithm) to generate a second cross-device role data identifier for the processed cross-device role data.

[0075] Optionally, in some feasible implementations, the target device receives a cross-device login request sent by the client. The cross-device login request contains authentication information. The target device authenticates the object account corresponding to the cross-device login request based on the authentication information. If the authentication is successful, a second cross-device role data identifier is generated based on the cross-device role data. Otherwise, a prompt message is sent to the client that the current cross-device object account login is rejected.

[0076] Step S105: If the first cross-device role data identifier is the same as the second cross-device role data identifier, then the cross-device role data of the target object is filled into the designated storage space in the target device used to store the object role data, and the cross-device role login of the target object is performed.

[0077] In some feasible implementations, the target device generates a second cross-device role data identifier based on the cross-device role data, and compares this data identifier with the first cross-device role data identifier carried in the cross-device placeholder request from the original device. If the first cross-device role data identifier and the second cross-device role data identifier are the same, it indicates that the cross-device role data received from the client is complete and consistent with the cross-device role data obtained by the original device. After the comparison is successful, the data is filled into the designated storage space in the target device used to store object role data, and cross-device role login is performed for the object account that requires cross-device access.

[0078] Optionally, in some feasible implementations, the target device arranges the received cross-device role data and generates a second cross-device role data identifier using, for example, an MD5 message digest algorithm. If the first cross-device role data identifier is the same as the second cross-device role data identifier, the target device restores the arranged cross-device role data to its initial state before arrangement and fills the data into a designated storage space in the target device used for storing object role data.

[0079] Optionally, in some feasible implementations, when the target device receives a cross-device login request initiated by the client, the target account carries state information during the cross-device role login process based on this request. The target device performs state reversal on the target account when transitioning from one login step to another, ensuring that the target account carries different state information in different login steps, thus avoiding login process confusion.

[0080] In this embodiment, the target device (e.g., the target server of an online game or network work application, or a device platform with large computing power for an online game or network work application) can receive a cross-device placeholder request from the origin device (e.g., the origin server of an online game or network work application, or a device platform with large computing power for an online game or network work application) and allocate cross-device resources (which can be a specified size of storage space used to store cross-device role data received from the client) to the target object (or the object account that needs cross-device access) based on the cross-device placeholder request. The cross-device placeholder request may include a first cross-device role data identifier, which is generated by the origin device based on the cross-device role data and used to verify the cross-device role data received from the client. After receiving the cross-device placeholder request, the target device performs online detection on the target object for which cross-device resources need to be allocated, i.e., obtains the online information (login or offline) of the object account. If it detects that a role is already logged in on the target device, the target device can send a notification to the origin device indicating that the target object has an online role or log out the online role of the object account. Furthermore, the target device can also receive a cross-device placeholder request sent by the original device, and allocate specified cross-device resources to the object account that needs cross-device access based on the request. Alternatively, the target device can obtain the amount of cross-device role data from the cross-device object information, allocate cross-device resources on demand based on this information, and send a placeholder success return message to the original device. This return message may contain authentication information for identity verification when the object account that needs cross-device access logs into the target device. When a cross-device login request initiated by the client is received from the client, the cross-device role data sent by the client is received. This cross-device role data may include role information such as experience, level, equipment, friends, role quests, and items of the character in the object account that needs cross-device access. When the cross-device role data is received, a second cross-device role data identifier can be generated based on the data while receiving it, or the received cross-device role data can be sorted. After all the cross-device role data has been received and sorted, a second cross-device role data identifier (using the MD5 message digest algorithm) can be generated from the processed cross-device role data. If the first cross-device role data identifier is the same as the second cross-device role data identifier, it means that the cross-device role data received from the client is complete and consistent with the cross-device role data obtained from the original device. After the comparison is successful, the data is filled into the designated storage space in the target device used to store object role data, and cross-device role login is performed in the object account that needs to cross devices.Therefore, by using a client to transmit cross-device role data to the target device, the problem of excessive server load on cross-device processing caused by a large number of concentrated cross-device requests can be solved when using the original device to transmit cross-device role data. The cross-device success rate is high and the applicability is strong. At the same time, using the client to carry out cross-device role data migration can reduce application operation costs.

[0081] Please see Figure 3 , Figure 3 This is another flowchart illustrating the cross-device method for network applications provided in this application embodiment, such as... Figure 3 As shown, this method is applicable to the original equipment (such as the original server of a network application, or the original equipment platform with large computing power for network games or network applications, etc.), and includes the following steps:

[0082] Step S201: Receive a cross-device request initiated by the target object. The cross-device request is used to request a cross-device transfer from the original device to the target device.

[0083] Step S202: Perform a status check on the cross-device role of the target object to confirm whether the cross-device role is in the target cross-device state. If yes, proceed to step S203; otherwise, proceed to step S204.

[0084] S203 returns a cross-device failure notification to the client.

[0085] In some feasible implementations, the aforementioned target cross-device state is determined by the original device (e.g., the original server of an online game or network work application, or the original device platform of an online game or network work application with large computing capabilities) detecting that it has received a cross-device request from the current cross-device role before receiving the cross-device request itself, and that the cross-device role has not yet logged out of the original device. The original device can receive cross-device requests from clients, which are used to request a cross-device transfer from the original server to the target server (or from the original device corresponding to the original server to the target device corresponding to the target server). For example, in object account X created by object A, there is a role R1 online in server Country-1. The client responds to object A's cross-device operation by sending a cross-device request (e.g., from server Country-1 to server Country-2) to the original device (i.e., the server corresponding to server Country-1). When a cross-device request is received from a client, the original device can perform a status check on the cross-device role in the object account. If the cross-device role has a target cross-device state, and the original device detects that the cross-device role is in the target cross-device state, the original device can return a cross-device failure notification to the client. For example, the original device performs a status check on role R1. If it detects that a cross-device request for role R1 has been received before the original device's cross-device request is received, and role R1 has not yet logged out of the original device (this can be understood as role R1 initiating a cross-device request but not yet completing the cross-device process; role R1 may be in a cross-device state from region-1 to region-3), then it can return a cross-device failure notification to the client. The client receives the cross-device failure notification and displays it to the object. The object can then cancel the current cross-device request through the client based on this notification, or it can cancel the cross-device process corresponding to the target cross-device state and continue the current cross-device request, thus preventing a single cross-device role from simultaneously requesting cross-device requests from two regions (or their corresponding servers).

[0086] Step S204: Obtain cross-device role data of the target object, generate a first cross-device role data identifier based on the cross-device role data, and send a cross-device placeholder request carrying the first cross-device role data identifier to the target device. The cross-device placeholder request is used to request the target device to reserve cross-device resources for the target object.

[0087] In some feasible implementations, the origin device can acquire cross-device role data, which may include role information such as experience, level, equipment, friends, role quests, and items of the character in the target account that needs to cross devices. Based on this data, a first cross-device role data identifier is generated. This first cross-device role data identifier is used by the target device to verify the cross-device role data. Specifically, the origin device can use an encryption algorithm, such as MD5, to generate the first cross-device role data identifier from the acquired cross-device role data. Further, the origin device adds the generated first cross-device role data identifier to a cross-device placeholder request and sends this request, carrying the first cross-device role data identifier, to the target device (such as the target server of a network game or network work application, or a device platform with large computing power for a network game or network work application). This request requests the target device to reserve cross-device resources (which may be a specified size of storage space for storing the cross-device role data received from the client) for the cross-device role. For example, during the cross-device process of character R1 from server Country-1 to server Country-2, the original device corresponding to server Country-1 obtains the cross-device character data of character R1, generates a first cross-device character data identifier based on the cross-device character data, and sends a cross-device placeholder request carrying the first cross-device character data identifier to the target device corresponding to server Country-2, in order to request the target device to reserve cross-device resources for character R1.

[0088] Step S205: When a successful placeholder return message is received, perform cross-device role logout of the target object.

[0089] In some feasible implementations, the origin device can receive a placeholder success return message sent by the target device. This placeholder success return message indicates that the target device has reserved cross-device resources for the cross-device role. At the same time, the origin device can perform cross-device role logout to avoid an object account logging in to different regions and servers at the same time, and send a cross-device notification to the client to inform that the placeholder is successful so as to trigger the client to send a cross-device login request and cross-device role data to the target device.

[0090] Optionally, in some feasible implementations, the returned information may include authentication information from the target device, used for authentication when an object account needs to log in to the target device across devices. Specifically, the originating device receives the returned information carrying authentication information from the target device and sends the authentication information along with a cross-device notification to the client, enabling the client to send a cross-device login request carrying the authentication information, facilitating the target device to authenticate cross-device roles.

[0091] In this embodiment, the originating device (i.e., the server corresponding to the target region / server) can receive a cross-device request initiated by the target object from the client. This cross-device request is used to request a cross-device transfer from the originating device to the target device (i.e., the server corresponding to the target region / server). Simultaneously, the originating device can perform status verification on the cross-device role in the target account. If the cross-device role is detected to be in the target cross-device state, the originating device can return a cross-device failure notification to the client. Further, the originating device can obtain cross-device role data, which may include character information such as experience, level, equipment, friends, character quests, and items of the character in the target account requiring cross-device access. Based on this data, an encryption algorithm (such as MD5 message digest algorithm) is used to generate a first cross-device role data identifier. This first cross-device role data identifier is used by the target device to verify the cross-device role data. The originating device can add the generated first cross-device role data identifier to a cross-device placeholder request, send the cross-device placeholder request carrying the first cross-device role data identifier to the target device, and perform cross-device role logout upon receiving a placeholder success return message from the target device. Therefore, by using a client to transmit cross-device role data to the target device, the problem of excessive server load on cross-device processing caused by a large number of concentrated cross-device requests can be solved when using the original device to transmit cross-device role data. The cross-device success rate is high and the applicability is strong. At the same time, using the client to carry out cross-device role data migration can reduce application operation costs.

[0092] To make it easier to understand, the following will be combined with Figure 4 This application provides an example illustrating the process by which the source and target devices collaborate to complete the cross-device interaction of a network application in an embodiment of the cross-device method for network applications. Please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is another flowchart illustrating the cross-device method for network applications provided in this application embodiment, such as... Figure 4 As shown, the cross-device method of this network application mainly includes a placeholder phase and a login phase. Assume object A registers object account X through a client. Object account X selects the login region as Country-1. This account X contains a role R1, and the application scenario that role R1 is currently using is application scenario S11 within region-1. The application process of this application scenario can be handled by the zone11 layer, which can be represented as a business server (e.g., ...). Figure 1bIn addition to the business server 100a in the region, the application process managing online information within the region Country-1 can be handled by the world-1 layer, which can also be represented as a business server within the region. Suppose object A wants role R1 to migrate across devices to region Country-2, and the application scenario going online in region Country-2 is application scenario S21 within region Country-2. Similarly, the application process for this scenario can be handled by the zone21 layer, which can be represented as a business server (e.g., ...). Figure 1b In the context of business server 101a, the application processes managing online information within the Country-2 region can be handled by the world-2 layer. It should be noted that when object A moves from Country-1 to Country-2 across devices, this is referred to as the original region, and Country-2 as the target region. The device corresponding to the original region can be the original device (either the server corresponding to the original region or a device platform with large computing capabilities corresponding to the original region). See also... Figure 4 At this point, the original device can be composed of the business servers corresponding to zone11 and world-1 layers, and the device corresponding to the target zone can be the target device (which can be the server corresponding to the target zone, or the device platform with large computing capabilities corresponding to the target zone). At this point, the target device can be composed of the business servers corresponding to zone21 and world-2 layers. Figure 4 In this context, global-proxy represents the business server that hosts the global-proxy process (e.g., Figure 1b The business server 10 in the process is responsible for carrying out the transmission of relevant cross-device instructions and business data between the origin and target devices during the cross-device process. The specific steps are as follows:

[0093] Positioning phase:

[0094] Step S301: The client sends a cross-device request to the original device.

[0095] In some feasible implementations, the client can respond to cross-device operations of object A by sending a cross-device request from region-1 to region-2 to the original device, which can be received by the business server corresponding to zone11 layer in the original device (referred to as zone11 layer server).

[0096] Step S302: The original device performs status verification on cross-device roles.

[0097] In some feasible implementations, when a cross-device request is received from a client, the zone11 layer server in the original device performs a status check on role R1 in object account X. If role R1 is detected to be in the process of crossing devices from region-1 to another region, a cross-device failure notification is returned to the client to avoid a single cross-device role simultaneously requesting cross-device access from two regions (or the corresponding servers). If role R1 is not in the process of crossing devices from region-1 to another region, step S303 is executed.

[0098] Step S303: The originating device sends a cross-device placeholder request carrying the first cross-device role data identifier to the target device.

[0099] In some feasible implementations, the zone11 layer server in the original device obtains cross-device character data for character R1. This cross-device character data may include character information such as R1's experience, level, equipment, friends, character quests, and items, and a first cross-device character data identifier is generated based on this data. The first cross-device character data identifier can be generated using an encryption algorithm, such as the MD5 message digest algorithm. Further, a cross-device placeholder request carrying the first cross-device character data identifier is sent to the target device corresponding to the country-2 region, requesting the target device to reserve cross-device resources for character R1.

[0100] Step S304: The target device performs online detection of cross-device roles.

[0101] In some feasible implementations, the business server corresponding to the world-2 layer in the target device (hereinafter referred to as the world-2 layer server) can detect the online status of the target account X, that is, obtain the online information (login or offline) of the target account X. If it is detected that there is already a role logged in on the target device in the target account X, the world-2 layer server can send a prompt message to the original device that there is a role online in the target object.

[0102] Step S305: The target device performs a kick-out operation.

[0103] In some feasible implementations, through the online detection in step S304, if it is detected that a role has already logged in on the target device in the object account X, the world-2 layer server can perform role logout (or kick-out) on the online role of the object account X, thus preventing the object from logging in to the object account through multiple clients at the same time.

[0104] Step S306: The target device allocates cross-device resources.

[0105] In some feasible implementations, the world-2 layer server in the target device allocates a specified cross-device resource (which may be a specified size of storage space for storing cross-device role data received from the client) to the object account X that needs to cross devices based on the cross-device placeholder request. For example, the world-2 layer server allocates 300MB of storage space for each object account that needs to cross devices to store the cross-device role data received from the client.

[0106] Alternatively, the world-2 layer server in the target device may receive a cross-device placeholder request from the source device containing cross-device object information. The world-2 layer server can then obtain the amount of cross-device role data from this cross-device object information and allocate cross-device resources based on this information. For example, if the target device obtains 500MB of cross-device role data for role R1 from the cross-device object information in the cross-device placeholder request, then 500MB of storage space will be allocated to role R2 to store the cross-device role data received from the client.

[0107] In step S307, the world-2 layer server in the target device sends a notification request to the zone21 layer server to place a position.

[0108] Step S308: The target device updates its online information.

[0109] In some feasible implementations, the world-2 layer server in the target device sends a placeholder notification request to the zone21 layer server. The zone21 layer server places a place for role R1 in the target account X to ensure that the cross-device resources allocated to role R1 are not occupied by other roles. At the same time, it updates the online information, that is, updates the online roles in the current server Country-2.

[0110] Step S309: The target device obtains authentication information.

[0111] In step S310, the target device sends a successful placeholder return message to the original device.

[0112] In some feasible implementations, after the zone21 layer server in the target device reserves the role R1, it sends a reservation success return message to the original device to notify the original device that the reservation was successful. This return message may contain authentication information for identity verification when the target account X logs in to the target device.

[0113] Step S311: Write back the original device data.

[0114] In some feasible implementations, before role R1 in object account X logs into the target device, in order to avoid data loss and irretrievable data loss during cross-device role data migration, it is necessary to write back role data of role R1 to the world-1 layer server of the original device.

[0115] Step S312: The original device performs a cross-device role logout.

[0116] Step S313: The source device sends a cross-device notification to the client.

[0117] In some feasible implementations, in order to prevent the target account X from logging in to different servers at the same time, the zone11 layer server in the original device can execute the logout of role R1 and send a cross-device notification to the client to inform the target device that the login has been successfully placed, thereby triggering the client to send a cross-device login request and the cross-device role data of role R1 to the target device.

[0118] Login phase:

[0119] Step S314: The client sends a cross-device login request and cross-device role data to the target device.

[0120] In some feasible implementations, when a client sends a cross-device login request to the zone21 server in the target device, the zone21 server receives the cross-device role data of role R1 sent by the client. The cross-device role data may include role information such as experience, level, equipment, friends, role quests, and items of role R1 in the target account X.

[0121] Step S315, target device authentication and verification.

[0122] In some feasible implementations, the zone21 server in the target device receives a cross-device login request sent by the client. The cross-device login request contains authentication information. The target device authenticates the object account X corresponding to the cross-device login request based on the authentication information. If the authentication is successful, a second cross-device role data identifier is generated based on the cross-device role data. Otherwise, a prompt message is sent to the client that the current cross-device object account login is rejected.

[0123] Step S316: Target device identifier comparison.

[0124] In some feasible implementations, when the zone21 server in the target device receives cross-device role data of role R1, it can generate a second cross-device role data identifier based on the data while receiving the data. The second cross-device role data identifier can be generated by an encryption algorithm (such as the MD5 message digest algorithm). Alternatively, when the target device receives cross-device role data, it can arrange the received cross-device role data. After receiving and arranging all the cross-device role data, it can use the MD5 message digest algorithm to generate a second cross-device role data identifier for the processed cross-device role data.

[0125] Furthermore, the zone21 server compares the second cross-device role data identifier with the first cross-device role data identifier carried in the cross-device placeholder request from the original device. If the first cross-device role data identifier is the same as the second cross-device role data identifier, it means that the cross-device role data received from the client is complete and consistent with the cross-device role data obtained from the original device. After the comparison is successful, the data is filled into the designated storage space in the target device used to store object role data, and cross-device role login is performed for the object account that needs to cross devices.

[0126] Step S317: The target device reverses the cross-device role state.

[0127] In some feasible implementations, when the target device receives a cross-device login request initiated by the client, and performs cross-device role login based on the request, the target account X carries state information. When moving from one login step to another, the target device reverses the state of the target account X, so that the target account carries different state information in different login steps, thus avoiding situations such as login process confusion.

[0128] Step S318: The target device restores cross-device role data.

[0129] In some feasible implementations, the zone21 server in the target device arranges the cross-device role data of the received role R1, and generates a second cross-device role data identifier using the MD5 message digest algorithm on the processed cross-device role data. If the first cross-device role data identifier is the same as the second cross-device role data identifier, the target device restores the arranged cross-device role data to the initial state before the data was arranged.

[0130] In step S319, the zone21 server in the target device sends a role login request to the world2 server.

[0131] In step S320, the world2 server on the target device returns a login response to the zone21 server.

[0132] Step S321: The target device sends login return information to the client.

[0133] In some feasible implementations, the zone21 server sends a role login request to the world2 server. After the world2 server completes the login of role R1, it returns a login response to the zone21 server. The zone21 server then sends login return information to the client based on the login response, and role R1 is completed across devices.

[0134] In this embodiment, the originating device (i.e., the server corresponding to the target region / server) can receive a cross-device request initiated by the target object from the client. This cross-device request is used to request a cross-device connection from the originating device to the target device (which may be the server corresponding to the target region / server, or a device platform with large computing power corresponding to the target region / server). Simultaneously, the originating device can perform status verification on the cross-device role in the target account. If the cross-device role is detected to be in the target cross-device state, the originating device can return a cross-device failure notification to the client. Further, the originating device can obtain cross-device role data, which may include character information such as experience, level, equipment, friends, character quests, and items of the character in the target account requiring cross-device access. Based on this data, an encryption algorithm (which may be the MD5 message digest algorithm) is used to generate a first cross-device role data identifier. This first cross-device role data identifier is used by the target device to verify the cross-device role data. The originating device can add the generated first cross-device role data identifier to the cross-device placeholder request, send the cross-device placeholder request carrying the first cross-device role data identifier to the target device, and perform cross-device role logout upon receiving a successful placeholder return message from the target device, sending a cross-device notification to the client to inform them of the successful placeholder and triggering the client to send a cross-device login request and cross-device role data to the target device. The target device (i.e., the server corresponding to the target region / server) can receive the cross-device placeholder request from the originating device (i.e., the server corresponding to the originating region / server) and allocate cross-device resources (which can be a specified size of storage space used to store the cross-device role data received from the client) to the target object (or the object account that needs cross-device access) based on the cross-device placeholder request. The cross-device placeholder request may contain the first cross-device role data identifier, which is generated by the originating device based on the cross-device role data and used to verify the cross-device role data received from the client. Upon receiving a cross-device placeholder request, the target device performs an online check on the target object for which cross-device resources are requested, i.e., obtains the online information (login or offline) of the object's account. If it detects that a role is already logged in on the target device with the object's account, the target device can either send a notification to the original device indicating that the target object has an online role or log out the online role of the object's account. Furthermore, the target device can also receive cross-device placeholder requests from the original device and allocate specified cross-device resources to the object account requiring cross-device access based on these requests. Alternatively, the target device can obtain the amount of cross-device role data from the cross-device object information, allocate cross-device resources on demand based on this information, and send a placeholder success return message to the original device. This return message may contain authentication information for identity verification when the object account requiring cross-device access logs in on the target device. When a cross-device login request initiated by a client is received from the client, the cross-device role data sent by the client is received, and a second cross-device role data identifier (which can use the MD5 message digest algorithm) is generated.If the first cross-device role data identifier is the same as the second cross-device role data identifier, it indicates that the cross-device role data received from the client is complete and consistent with the cross-device role data obtained from the original device. After the comparison is successful, the data is filled into the designated storage space on the target device used to store object role data, and cross-device role login is performed for the object account that needs to cross devices. Therefore, by using a client to transmit cross-device role data to the target device, the problem of excessive server load on cross-device processing caused by a large number of concentrated cross-device requests during the process of transmitting cross-device role data using the original device can be solved. This method has a high cross-device success rate, strong applicability, and reduces application operating costs by using a client to handle cross-device role data migration.

[0135] Based on the description of the cross-device method embodiments of the above-mentioned network applications, this application also discloses a cross-device device for network applications (hereinafter referred to as the first cross-device device). This cross-device device can be applied to the aforementioned target device and can be applied to... Figure 2 In the illustrated embodiment of the cross-device method for a network application, steps are used to execute the steps in the cross-device method for the network application. Please refer to... Figure 5 , Figure 5 This is a schematic diagram of the structure of the first cross-device device provided in an embodiment of this application. In this embodiment, the device can operate the following modules:

[0136] The receiving module 41 is used to receive a cross-device placeholder request for the target object, wherein the cross-device placeholder request is used to request the reservation of cross-device resources for the target object, and the cross-device placeholder request carries the first cross-device role data identifier of the target object.

[0137] The resource allocation module 42 is used to allocate cross-device resources to the target object based on the cross-device placeholder request received by the receiving module 41, and send a placeholder success return information to the original device to trigger the original device to log out of the target object.

[0138] The receiving module 41 is also used to receive cross-device role data of the target object from the client when it receives a cross-device login request initiated by the target object.

[0139] The identifier generation module 43 is used to generate a second cross-device role data identifier based on the cross-device role data received by the receiving module 41.

[0140] The role login module 44 is used to perform cross-device role login for the target object when the first cross-device role data identifier is the same as the second cross-device role data identifier.

[0141] In some feasible implementations, the memory snapshot acquisition device described above may further include:

[0142] The online detection module 45 is used to perform online role detection on the target object. If it detects that the target object has an online role on the target device, it will log out the online role or send a prompt message to the original device that the target object has an online role.

[0143] In some feasible implementations, the receiving module 41 is further configured to:

[0144] Before the role login module 44 performs cross-device role login for the target object, the cross-device role data of the target object is filled into the designated storage space in the target device used to store the object role data.

[0145] According to the above Figure 2 The corresponding implementation, Figure 2 The implementation described in steps S101 to S105 of the cross-device method for the network application shown can be derived from... Figure 5 The various modules of the illustrated device are executed. For example, the above... Figure 2 The implementation described in step S101 of the cross-device method for the network application shown can be derived from... Figure 5 The receiving module 41 in the illustrated device performs the following actions: the implementation described in step S102 can be performed by the online detection module 45; the implementation described in step S103 can be performed by the resource allocation module 42; the implementation described in step S104 can be performed by the receiving module 41 and the identifier generation module 43; and the implementation described in step S105 can be performed by the receiving module 41 and the role login module 44. The implementation methods performed by the receiving module 41, resource allocation module 42, identifier generation module 43, role login module 44, and online detection module 45 are as described above. Figure 2 The implementation methods provided for each step in the corresponding embodiments will not be repeated here.

[0146] In this embodiment, the first cross-device device can receive a cross-device placeholder request from the original device and allocate cross-device resources (which may be a specified size of storage space for storing cross-device role data received from the client) to the target application (or the object account requiring cross-device access) based on the cross-device placeholder request. The cross-device placeholder request may include a first cross-device role data identifier, which is generated by the original device based on the cross-device role data and used to verify the cross-device role data received from the client. After receiving the cross-device placeholder request, the first cross-device device performs online detection on the target application for which cross-device resources need to be allocated, i.e., obtains the online information (login or offline) of the object account. If it detects that a role is already logged in on the target device, the device can send a notification to the original device indicating that a role is online in the target application or log out the online role of the object account. Furthermore, the first cross-device device can also receive a cross-device placeholder request sent by the original device and allocate specified cross-device resources to the object account requiring cross-device access based on the request. Alternatively, the device can obtain the amount of cross-device role data from the cross-device object information, allocate cross-device resources on demand based on this information, and send a placeholder success return message to the original device. This return message may contain authentication information for identity verification when the object account requiring cross-device login attempts to log in to the target device. When a cross-device login request initiated by the client is received from the client, the cross-device role data sent by the client is received. Upon receiving the cross-device role data, a second cross-device role data identifier can be generated based on the data while receiving it, or the received cross-device role data can be arranged. After all the cross-device role data has been received and arranged, a second cross-device role data identifier (using the MD5 message digest algorithm) can be generated for the processed cross-device role data. If the first cross-device role data identifier is the same as the second cross-device role data identifier, it means that the cross-device role data received from the client is complete and consistent with the cross-device role data obtained by the original device. After the comparison is successful, the data is filled into the designated storage space in the target device used to store object role data, and cross-device role login is performed for the object account requiring cross-device login. Therefore, by using a client to transmit cross-device role data to the target device, the problem of excessive load on the device's cross-device processing process caused by a large number of centralized cross-device requests can be solved when using the original device to transmit cross-device role data. The cross-device success rate is high and the applicability is strong. At the same time, using a client to carry out cross-device role data migration can reduce the operating costs of network applications.

[0147] This application also discloses another cross-device device for network applications (hereinafter referred to as the second cross-device device), which can be applied to... Figure 3 In the illustrated embodiment of the cross-device method for a network application, steps are used to execute the steps in the cross-device method for the network application. Please refer to...Figure 6 , Figure 6 This is a schematic diagram of the structure of the second cross-device device provided in an embodiment of this application. In this embodiment, the device can operate the following modules:

[0148] The receiving module 51 is used to receive cross-device requests initiated by the target object. The cross-device request is used to request a cross-device transfer from the original device to the target device.

[0149] The identifier generation module 52 is used to generate a first cross-device role data identifier based on the acquired cross-device role data.

[0150] The sending module 53 is used to send a cross-device placeholder request carrying the first cross-device role data identifier generated by the identifier generation module 52 to the target device. The cross-device placeholder request is used to request the target device to reserve cross-device resources for the target object.

[0151] The receiving module 51 is also used to receive a successful placeholder return information from the target device.

[0152] The role logout module 54 is used to perform cross-device role logout of the target object when the receiving module 51 receives the placeholder success return information.

[0153] The identifier generation module 52 is also used to perform status verification on the cross-device role of the target object before generating the first cross-device role data identifier based on the acquired cross-device role data. When the cross-device role is found to be in the target cross-device state, a cross-device failure notification is returned to the client.

[0154] According to the above Figure 3 The corresponding implementation, Figure 3 The implementation described in steps S201 to S205 of the cross-device method for network applications shown can be derived from... Figure 6 The various modules of the illustrated device are executed. For example, the above... Figure 3 The implementation described in step S201 of the cross-device method for the network application shown can be derived from... Figure 6 The receiving module 51 in the illustrated device performs the execution of step S202. The implementation described in step S202 can be performed by the identifier generation module 52. The implementation described in step S203 can be performed by the identifier generation module 52 and the sending module 53. The implementation described in step S205 can be performed by the receiving module 51, the character logout module 54, and the sending module 53. The implementation methods performed by the receiving module 51, the identifier generation module 52, the sending module 53, and the character logout module 54 are as described above. Figure 3 The implementation methods provided for each step in the corresponding embodiments will not be repeated here.

[0155] In this embodiment, the second cross-device device can receive a cross-device request initiated by the target application from the client. This cross-device request is used to request a cross-device transition from the original device to the target device (i.e., the device corresponding to the target region / server). Simultaneously, the device can perform status verification on the cross-device role in the target account. If the cross-device role is detected to be in the target cross-device state, a cross-device failure notification can be returned to the client. Further, the second cross-device device can obtain cross-device role data and generate a first cross-device role data identifier based on this data using an encryption algorithm (which could be the MD5 message digest algorithm). The second cross-device device can add the generated first cross-device role data identifier to a cross-device placeholder request, send the cross-device placeholder request carrying the first cross-device role data identifier to the target device, and upon receiving a placeholder success return message from the target device, execute a cross-device role logout, sending a cross-device notification to the client to inform them of successful placeholder placement, thus triggering the client to send a cross-device login request and cross-device role data to the target device. Therefore, by using a client to transmit cross-device role data to the target device, the problem of excessive load on the device's cross-device processing process caused by a large number of centralized cross-device requests can be solved when using the original device to transmit cross-device role data. The cross-device success rate is high and the applicability is strong. At the same time, using a client to carry out cross-device role data migration can reduce the operating costs of network applications.

[0156] In the embodiments of this application, the modules in the device shown in the figures above can be individually or entirely combined into one or more other modules, or some of the modules can be further divided into multiple functionally smaller modules. This achieves the same operation without affecting the technical effect of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can be implemented by multiple modules, or the function of multiple modules can be implemented by one module. In other feasible implementations of this application, the device may also include other modules. In practical applications, these functions can also be implemented with the assistance of other modules, and can be implemented collaboratively by multiple modules, without limitation.

[0157] Please see Figure 7 This is a schematic diagram of the structure of the computer device provided in an embodiment of this application. Figure 7 As shown, the computer device 1000 can be the above-mentioned Figure 1aThe corresponding embodiment includes a business server 100a. The computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1004 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. The memory 1005 may optionally be at least one storage device located remotely from the aforementioned processor 1001. Figure 7 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0158] The network interface 1004 in the computer device 1000 can also be connected to the aforementioned Figure 1a The terminal 101a in the corresponding embodiment connects to the network, and the optional user interface 1003 may further include a display screen and a keyboard. Figure 7 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for users (or developers); and the processor 1001 can be used to call the device control application stored in the memory 1005 to implement the aforementioned functions. Figure 2 and / or Figure 3 The cross-device method for network applications in the corresponding embodiments.

[0159] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 2 and / or Figure 3 The description of the cross-device method for network applications in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0160] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the first cross-device device and the second cross-device device mentioned above. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 2 andFigure 3 The description of the cross-device method for network applications in the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0161] Furthermore, it should be noted that this application also provides a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, causing the computer device to perform the aforementioned actions. Figure 2 and Figure 3 The description of the cross-device method for network applications in the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program products or computer program embodiments related to this application, please refer to the description of the method embodiments of this application.

[0162] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0163] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A cross-device method for network applications, characterized in that, The method includes: Receive a cross-device placeholder request for a target object. The cross-device placeholder request is used to request that cross-device resources be reserved for the target object. The cross-device placeholder request carries a first cross-device role data identifier of the target object. The first cross-device role data identifier is used by the target device to verify the data consistency of the cross-device role data. Based on the cross-device placeholder request, cross-device resources are allocated to the target object, and a placeholder success return message is sent to the original device to trigger the original device to log out of the target object and send a cross-device notification to the client, thereby triggering the client to send a cross-device login request and the target object's cross-device role data to the target device. The cross-device role data includes various role information such as the character's experience, level, equipment, friends, character tasks, and items. When the client sends a cross-device login request initiated by the target object and the target object's cross-device role data, the target object is authenticated based on the authentication information contained in the cross-device login request. After the target object's authentication is successful, the cross-device role data includes various role information such as the character's experience, level, equipment, friends, role tasks, and items, which are arranged in order. A second cross-device role data identifier is generated based on the arranged cross-device role data using an encryption algorithm. If the first cross-device role data identifier is the same as the second cross-device role data identifier, the arranged cross-device role data is restored to its initial state before being arranged, and the cross-device role data restored to its initial state before being arranged is filled into the designated storage space in the target device used to store object role data, and the cross-device role login of the target object is performed.

2. The method according to claim 1, characterized in that, Before allocating cross-device resources to the target object based on the cross-device placeholder request, the method further includes: Perform online role detection on the target object; If it is detected that the target object has an online role on the target device, then the online role is logged out or a notification message indicating that the target object has an online role is sent to the original device.

3. A cross-device device for network applications, characterized in that, The device is suitable for the target equipment and includes: A receiving module is used to receive a cross-device placeholder request from a target object. The cross-device placeholder request is used to request that cross-device resources be reserved for the target object. The cross-device placeholder request carries a first cross-device role data identifier of the target object. The first cross-device role data identifier is used by the target device to verify the data consistency of the cross-device role data. The resource allocation module is used to allocate cross-device resources to the target object based on the cross-device placeholder request received by the receiving module, and send a placeholder success return information to the original device to trigger the original device to log out of the target object and send a cross-device notification to the client to trigger the client to send a cross-device login request and the cross-device role data of the target object to the target device. The cross-device role data includes various role information such as the character's experience, level, equipment, friends, character tasks, and items. The receiving module is also used to receive cross-device role data of the target object from the client when it receives a cross-device login request initiated by the target object. The cross-device role data includes various role information such as the character's experience, level, equipment, friends, character tasks, and items. The identifier generation module is used to authenticate the target object based on the authentication information contained in the cross-device login request. After the target object is authenticated, the module arranges various character information, including the character's experience, level, equipment, friends, character tasks, and items, in the cross-device character data. The module then uses an encryption algorithm to generate a second cross-device character data identifier based on the arranged cross-device character data. The role login module is used to restore the sorted cross-device role data to its initial state before sorting when the first cross-device role data identifier and the second cross-device role data identifier are the same, and to fill the cross-device role data restored to its initial state before sorting into the designated storage space in the target device used to store object role data, and to perform cross-device role login for the target object.

4. The apparatus according to claim 3, characterized in that, The device further includes: The online detection module is used to perform online role detection on the target object. If it is detected that the target object has an online role on the target device, the module will either log out the online role or send a prompt message to the original device that the target object has an online role.

5. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1-2.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method of any one of claims 1-2.

7. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-2.

Images