Method, game server, apparatus for a node of a blockchain and game client

Abstract

It is provided a method for reducing latency when using an in-game asset. The method comprises detecting an in-game event by a game server. The in-game event indicating that a player playing at a game client has earned the in-game asset. The method further comprises updating a game server database to record the player's ownership of the in-game asset. The method further comprises issuing the in-game asset from the game server to the game client. The in-game asset is directly usable by the player upon its reception by the game client. The method further comprises generating a record on a blockchain, the blockchain record indicating the player's ownership of the in-game asset.

Description

[0001] METHOD, GAME SERVER, APPARATUS FOR A NODE OF A BLOCKCHAIN AND GAME CLIENT

[0002] Field

[0003] The present disclosure relates to a method, a game server, an apparatus for a node of a blockchain and a game client. In particular, examples of the present disclosure relate to a method for reducing latency, a game server, an apparatus for a node of a blockchain and a game client.

[0004] Background

[0005] Blockchain-based gaming (also referred to as “web3 gaming”) may introduce new opportunities for secure and verifiable ownership of in-game assets, allowing players to trade, transfer, and manage digital items independently of a centralized game server. In a web3 game an in-game asset may be stored on the blockchain as a token. Those tokens may then be traded or exchanged between players. Because these tokens are stored on-chain, a game server running the game cannot simply revoke the tokens after having issued them to a player. In conventional gaming systems, in-game assets may be fully controlled by the game publisher, where ownership and usage rights are stored in a game server database, limiting player autonomy. In contrast, Web3 gaming may leverage blockchain technology to provide decentralized asset management, where in-game assets may be represented as blockchain-based tokens recorded on a distributed ledger. This may enable greater transparency and player control. In some examples, blockchain transactions may introduce latency, as the confirmation of ownership updates on the blockchain may take several seconds to minutes, depending on network congestion and transaction fees. This delay may disrupt gameplay, especially in real-time multiplayer environments where players expect immediate access to newly acquired assets.

[0006] Existing blockchain gaming solutions may require players to wait for on-chain confirmation before using an in-game asset, leading to interruptions in the gaming experience. Furthermore, the game server may not always have real-time awareness of asset transfers occurring directly on the blockchain, causing inconsistencies between the game state and blockchain ownership records. While conventional Web3 games prioritize decentralized ownership, they may lack efficient mechanisms for ensuring low-latency usability of assets while maintaining blockchain-backed security.Hence, there may be a need for improved systems and methods that enable faster usability of in-game assets.

[0007] Summary

[0008] Some aspects of the present disclosure relate to a method for reducing latency when using an in-game asset. The method comprises detecting an in-game event by a game server, the in-game event indicating that a player playing at a game client has earned the in-game asset. The method further comprises updating a game server database to record the player's ownership of the in-game asset, issuing the in-game asset from the game server to the game client, wherein the in-game asset is directly usable by the player upon its reception by the game client. The method further comprises generating a record on a blockchain, the blockchain record indicating the player's ownership of the in-game asset.

[0009] Some aspects of the present disclosure relate to a game server comprising circuitry configured to detect an in-game event, the in-game event indicating that a player playing at a game client has earned the in-game asset. The circuity is further configured to update a game server database to record the player's ownership of the in-game asset. The circuity is further configured to issue the in-game asset to the game client, wherein the in-game asset is directly usable by the player upon its reception by the game client.

[0010] Some aspects of the present disclosure relate to an apparatus for a node of a blockchain, the apparatus comprising circuitry configured to receive a request by a game client to generate a blockchain record on the blockchain. The circuity is further configured generate the record on the blockchain corresponding to an in-game asset, the blockchain record indicating the player's ownership of the in-game asset, wherein the in-game asset is earned by the player playing at the game client.

[0011] Some aspects of the present disclosure relate to a game client comprising circuitry configured to receive an in-game asset from a game server, wherein the in-game asset is earned by the player playing at the game client, wherein the in-game asset is directly usable by the player upon its reception. The circuity is further configured to request to generate a blockchain record on the blockchain, the blockchain record indicating the player's ownership of the in-game asset. The game server comprising circuitry configured to detect an in-game event, the in-game event indicating that a player playing at a game client has earned the ingame asset. The circuity is further configured to update a game server database to record the player's ownership of the in-game asset. The circuity is further configured to issue thein-game asset to the game client, wherein the in-game asset is directly usable by the player upon its reception by the game client. The apparatus for the node of the blockchain comprising circuitry configured to receive a request by a game client to generate a blockchain record on the blockchain. The circuity is further configured generate the record on the blockchain corresponding to an in-game asset, the blockchain record indicating the player's ownership of the in-game asset, wherein the in-game asset is earned by the player playing at the game client. The game client comprising circuitry configured to receive an ingame asset from a game server, wherein the in-game asset is earned by the player playing at the game client, wherein the in-game asset is directly usable by the player upon its reception. The circuity is further configured to request to generate a blockchain record on the blockchain, the blockchain record indicating the player's ownership of the in-game asset.

[0012] Brief description of the Figures

[0013] Some examples of apparatuses and / or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which

[0014] Fig. 1 illustrates a flowchart of an example of a method for reducing latency when using an in-game asset;

[0015] Fig. 2 illustrates a block diagram of an example of an apparatus;

[0016] Fig. 3 illustrates a block diagram of an example of an apparatus;

[0017] Fig. 4 illustrates a block diagram of an example of an apparatus;

[0018] Fig. 5 illustrates a system comprising a game server, a node apparatus of a blockchain and a game client; and

[0019] Fig. 6 illustrates an example of a process for reducing latency when using an in-game asset.

[0020] Detailed Description

[0021] Some examples are now described in more detail with reference to the enclosed figures. However, other possible examples are not limited to the features of these embodimentsdescribed in detail. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not be restrictive of further possible examples.

[0022] Throughout the description of the figures same or similar reference numerals refer to same or similar elements and / or features, which may be identical or implemented in a modified form while providing the same or a similar function. The thickness of lines, layers and / or areas in the figures may also be exaggerated for clarification.

[0023] When two elements A and B are combined using an “or”, this is to be understood as disclosing all possible combinations, i.e. only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the same combinations, "at least one of A and B" or "A and / or B" may be used. This applies equivalently to combinations of more than two elements.

[0024] If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the same function. If a function is described below as implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. It is further understood that the terms "include", "including", "comprise" and / or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof.

[0025] Fig. 1 illustrates a flowchart of an example of a method 100 for reducing latency when using an in-game asset. For example, the method 100 may be performed by one or more or all of the apparatuses as described herein, such as apparatus 200, 300 or 400 (see Figs, 2, 3, 4). For example, the method 100 may be performed by a computational system such system 500 (see Fig. 5). The method 100 comprises detecting 110 an in-game event by a game server. The in-game event indicates that a player, which is playing a computer game at a game client, has earned the in-game asset. For example, a computer game may be interactive software designed to provide a virtual environment in which the player may engage with digital content according to predefined rules, objectives, and mechanics. The computer game may involve audiovisual output, player inputs, and programmed logic that together create a simulated experience, allowing the player to perform actions, make decisions, and interact with virtual elements. The computer game may present tasks,challenges, or competitive activities and may involve progression systems, achievements, and rewards based on player performance. In some examples, the computer game may be executed across multiple systems, where different components of the game may be processed or managed separately, such as through a game server and a game client. For example, a computer game may be an adventure game where a player explores different worlds, solves puzzles, and completes missions.

[0026] For example, the game server may be apparatus 200. For example, the game server may be a computing system configured to manage, control, and coordinate the operation of a computer game. The game client may be a software running on apparatus 400. In some examples, the game client may be apparatus 400. For example, the game client may be a computing system or software application through which the player may access and interact with the computer game. The game server may handle core game logic, maintain the state of the game world, process player actions, and ensure consistency across multiple players. The game client may provide the player-facing interface, including input handling, visual and audio output, and communication with the game server. The game client may transmit player actions to the game server and receive updates to reflect the current state of the computer game. For example, the game server may determine the results of player interactions during a multiplayer match, while the game client displays the gameplay to the player and allows the player to control a character.

[0027] For example, the in-game event may be a specific occurrence within the computer game that may arise as a result of player actions, interactions with virtual elements, or the fulfillment of particular conditions defined within the computer game's logic. The in-game event may represent a moment of significance within the game, such as the completion of a task, the discovery of a particular location, or the defeat of an opponent, and may trigger changes in the game's state or progress. In some examples, the in-game event may indicate that a player who is playing the computer game via a game client has earned an ingame asset, where the in-game event may mark the completion of the conditions required for the player to receive the in-game asset as a reward for gameplay achievements. The ingame event may serve as a mechanism through which the computer game recognizes that a player has met the criteria necessary for rewards, status updates, or new gameplay opportunities. For example, an in-game event may occur when a player successfully finishes a level, unlocks a secret area, reaches a certain score threshold, or opens a treasure chest, where the opening of the treasure chest may trigger the awarding of an ingame asset such as a new tool, item, or enhancement like a Magic Sword.For example, the in-game asset may be a digital resource within the computer game that may be awarded to a player, created within the game, or obtained through gameplay. The in-game asset may have specific attributes, functions, or values within the computer game and may enhance gameplay by providing abilities, customization options, progression advantages, or collectible value. The in-game asset may be linked to the player's profile within the computer game and may be stored, modified, or used during gameplay. For example, an in-game asset may be a virtual sword with enhanced powers, a unique character costume, or a digital badge representing the completion of a rare achievement.

[0028] For example, the detecting of the in-game event by the game server may be comprise identifying that a specific in-game event has occurred within the computer game, based on monitoring the actions performed by the player playing via the game client and evaluating whether predefined conditions of the computer game's logic have been fulfilled. The detecting of the in-game event by the game server may comprise receiving data from the game client that reflects player interactions within the virtual environment, such as the completion of tasks, interaction with game elements, or the achievement of milestones, and determining that an event, such as the opening of a treasure chest, has occurred, thereby confirming that the player has earned an in-game asset, such as a Magic Sword, in response to the in-game event.

[0029] The method 100 further comprises updating a game server database to record the player's ownership of the in-game asset. For example, the game server database may be a structured data storage system operated by the game server, which may maintain information relevant to the current state of the computer game, including data on players, ingame events, and in-game assets. For example, the database may be a storage circuitry of the apparatus 200. The game server database may store records that associate specific players with specific in-game assets. The game server database may enable the game server to track which player possesses which in-game asset at any given time and may support real-time gameplay operations by providing fast access to this ownership information. For example, the ownership of the in-game asset may be the recognized association between a player and a specific in-game asset within the computer game, whereby the player is entitled to use, manage, and potentially transfer the in-game asset during gameplay or through interactions with a blockchain (see below). The ownership of the in-game asset may be established when the player fulfills the conditions of an in-game event, such as discovering the asset in the virtual environment, and may be reflected both within the computer game and externally in a blockchain record. For example, ownershipmay mean that the player is authorized to use the Magic Sword in the game or to transfer the Magic Sword to another player via the blockchain.

[0030] For example, updating the game server database to record the player’s ownership of the ingame asset may comprise modifying the relevant data in the game server database to reflect that the player has obtained rights to the in-game asset as a result of an in-game event. The updating may comprise creating a new record when the in-game asset is generated for the first time or modifying an existing record when the in-game asset previously belonged to another player and has been transferred. The updating of the game server database may ensure that the game server has an accurate and current record of which player is entitled to use the in-game asset, which may be essential both for in-game functionality and for maintaining consistency with asset ownership recorded on the blockchain. For example, the game server database may be updated to show that Player 1 now owns the Magic Sword after opening a treasure chest.

[0031] The method 100 further comprises issuing the in-game asset from the game server to the game client. The in-game asset is directly usable by the player upon its reception by the game client. For example, the issuing of the in-game asset from the game server to the game client may comprise transmitting the in-game asset to the game client following the detection of an in-game event indicating that the player has earned the in-game asset. The issuing of the in-game asset may comprise generating asset data that represents the ingame asset. For example, the issuing of the in-game asset from the game server to the game client may comprise transmitting the asset data representing the in-game asset and / or the asset data and the in-game asset. The asset data may then be transmitted over a communication network to the game client, where the game client may receive and process the data. For example, the issuing of the in-game asset from the game server to the game client may enable the player to immediately obtain and use the in-game asset.

[0032] For example, the in-game asset being directly usable means that the usability of the ingame asset by the player may not depend on the completion of an external confirmation (such as a blockchain transaction or validation by a decentralized network), which may otherwise introduce latency. Instead, the direct usability may rely on the fact that the game server has acknowledged the player's right to the in-game asset through the transmission of the in-game asset and / or the corresponding asset data. In this context, the direct usability of the in-game asset may be enabled solely based on the transmission and reception of the asset and / or asset data between the game server and the game client, which may occur over a local network or internet connection with only short latency, such as within a fewmilliseconds to a few hundred milliseconds. For example, the player may, upon reception of the in-game asset, immediately access, equip, or activate the in-game asset in the computer game, once the game client has received the asset and / or asset data transmitted by the game server. By allowing the player to immediately use the in-game asset upon reception from the game server, it is ensured that gameplay remains uninterrupted and responsive, even while an external confirmation (such as a blockchain recordation) may be pending. For example, a player may immediately use the Magic Sword in battle upon receiving it, without needing to wait for external confirmation.

[0033] The method 100 further comprises generating a record on a blockchain. The blockchain record indicates the player's ownership of the in-game asset. For example, a blockchain may be a distributed digital ledger that records data in a secure, transparent, and immutable way across a network of nodes, where each node stores a copy of the entire ledger and verifies new transactions according to a consensus mechanism. For example, apparatus 300 may operate one or more nodes of the blockchain. For example, the blockchain may consist of a continuous sequence of blocks, where each block contains data, a reference to the previous block, and a cryptographic hash ensuring the integrity of the entire chain. The blockchain may store any type of data, such as financial transactions, ownership records, or in-game asset information, where the data is included as part of the blocks. For example, the blockchain may store transactions.

[0034] For example, a blockchain address may serve as unique identifier derived from a public key, and these blockchain addresses may be included in transactions stored within the blockchain to define which participant is sending or receiving an asset. The blockchain records transactions that show how assets move from one blockchain address to another. By reading the transaction history in the blockchain, an external program may determine which blockchain address currently controls a specific asset, such as an in-game asset, based on the most recent relevant transaction. This system allows the blockchain to indirectly manage asset ownership by permanently linking assets to blockchain addresses within the transaction data stored across the blockchain.

[0035] In some examples, generating the blockchain record may comprise using a blockchain key pair associated with the player. The blockchain key pair may comprise a private key and a corresponding public key. The public key may be used to derive the player's blockchain address, which is included in the blockchain record to indicate the ownership of the in-game asset. The private key may be used by the player to digitally sign the transaction that generates the blockchain record, ensuring that only the player can authorize the creation ofthe blockchain record for the in-game asset. This signature provides cryptographic proof that the transaction is valid, and that the player has agreed to the registration of the in-game asset on the blockchain. Without the correct private key, no valid blockchain record linking the in-game asset to the player's blockchain address may be generated. For example, by using the blockchain key pair associated with the player, the blockchain record may link the in-game asset directly to the player's blockchain address, making the player the verifiable owner of the asset on the blockchain. The blockchain key pair may ensure that control over the asset remains secured by cryptographic means, where only the player in possession of the private key can initiate further actions regarding the asset, such as transferring ownership to another player. In this way, the blockchain record created using the player's blockchain key pair may serve both to establish ownership and to restrict control of the ingame asset to the rightful player, as defined by the key pair, within the decentralized structure of the blockchain.

[0036] For example, the blockchain record may be a unit of data stored within a block of the blockchain that may document specific information relevant to the blockchain system, such as asset ownership, transaction details, or other associated data. The blockchain record may exist as part of the structured content of a block and may include or result from a transaction, or may form part of the data within a transaction, depending on the design of the blockchain. For example, a transaction on a blockchain may be an interaction between two blockchain addresses, where one address acts as the sender and another address acts as the receiver, and the transaction transfers value, ownership of an asset, or triggers a function such as a smart contract execution. The blockchain record may serve as the stored evidence of a particular event, state change, or piece of information within the blockchain and may be permanently maintained across the distributed network as part of the blockchain’s immutable ledger.

[0037] For example, the blockchain record may comprise information necessary to define and verify the ownership of an in-game asset, including a unique identifier of the in-game asset, the blockchain address of the current owner, a timestamp indicating when the record was created or updated, and a reference to the smart contract or token standard governing the asset, such as an ERC-721 or ERC-1155 contract. In some examples, the blockchain record may also contain metadata references, such as a URL or a cryptographic hash pointing to external storage where additional details about the in-game asset, such as its description or visual representation, may be stored. If the blockchain record is generated through a smart contract, it may include logged events, such as a Transfer event, which documents changes in ownership. The blockchain record may provide immutable andpublicly verifiable ownership tracking, allowing the game server and other participants to determine the rightful owner of the in-game asset based on the most recent recorded blockchain entry.

[0038] For example, generating a blockchain record may refer to creating a new entry of data on the blockchain that becomes part of a block, where the blockchain record stores information such as asset details, ownership data, or other relevant information in a permanent and verifiable manner. The blockchain record may be generated by one or more nodes of the blockchain, such as apparatus 300 and may be forwarded into the network to other nodes. The generation of the blockchain record may be requested by the game client, the game server, or an external service, which may submit the required data to one or more blockchain nodes. These nodes may verify the correctness and validity of the request according to the blockchain’s rules and, after successful validation, may add the data as part of a block, thereby creating the blockchain record and making it permanently accessible and verifiable across all nodes that maintain a copy of the blockchain.

[0039] In some examples, the blockchain record may be based on at least one of a smart contract, a blockchain token or a non-fungible token (NFT). For example, a smart contract may be an executable program deployed on the blockchain that automatically manages data and processes actions, such as assigning ownership of in-game assets according to predefined logic. In this case, the blockchain record may be generated when a request is sent to a blockchain node to call a function of the smart contract, such as “assignAsset”. The blockchain node processes the function call, verifies the required signatures, and executes the smart contract code, which updates internal storage structures, such as a “mapping” that links the unique asset ID of the in-game asset to the player's blockchain address. The result of the execution, including the updated ownership information, is stored in the state of the smart contract, and the details of the function call are recorded in the block, making the ownership information permanently verifiable through the blockchain.

[0040] For example, a blockchain token may be a digital representation of value or rights managed by a token contract, often following standards such as ERC-20, where tokens are fungible and interchangeable. In this case, the blockchain record may be generated when a blockchain node processes a request to mint or transfer tokens, updating a balance “mapping” that assigns a certain number of tokens to the player's blockchain address. Ownership of the in-game asset may be indicated through the player's token balance, with the presence of one or more tokens serving as proof that the player controls the corresponding in-game asset. The blockchain node verifies the transaction, updates thetoken contract’s internal ledger, and includes the transaction in the block, where the updated balances are stored as part of the blockchain’s state.

[0041] For example, a non-fungible token (NFT) may be a unique digital asset managed by an NFT smart contract, following standards such as ERC-721 or ERC-1155, where each NFT represents an individual in-game asset with a distinct identifier. In this case, the blockchain record may be generated when a blockchain node executes a minting function, such as “mint”, which creates a new NFT and assigns it to the player's blockchain address. Ownership of the in-game asset is indicated through a “mapping” that links the unique token ID of the NFT to the player's blockchain address. The blockchain node validates the minting request, updates the NFT contract’s state, and includes the minting transaction in the block, making the association between the in-game asset and the player's blockchain address permanently stored and publicly verifiable on the blockchain.

[0042] For example, latency may occur when generating the blockchain record for the in-game asset because the process of adding new data to the blockchain requires submitting the data to one or more blockchain nodes, which must validate the request, execute any related smart contracts, and reach consensus with other nodes in the network before including the data in a new block. This process may introduce delays due to factors such as network congestion, limited block size, block production times, and the prioritization of transactions based on paid fees. For example, in public blockchains, such as Ethereum, block times may range from around 12 to 15 seconds, but depending on network load and transaction fees, the total confirmation time required for a blockchain record may vary from approximately 10 seconds to several minutes, and in extreme cases, up to 30 minutes or more. As a result, there may be a significant waiting period from the moment the request to generate the blockchain record is made until the blockchain record is officially confirmed and permanently stored on the blockchain. For example, this latency may mean that although the player has already earned the in-game asset in the computer game and expects to use the asset immediately during gameplay, the corresponding blockchain record indicating ownership may not yet be available, since the network requires time to process and finalize the record. This delay may be particularly disruptive in Web3 gaming environments, where immediate, real-time use of assets is expected as part of the gaming experience, but the confirmation of ownership on the blockchain depends on external factors such as the blockchain’s block time, the total number of transactions waiting to be processed, and the transaction fees paid to prioritize the request. For example, in a multiplayer game where fast-paced interactions occur, if a player acquires a powerful in-game asset, such as a rare weapon or a special ability, they may expect to use it immediately to impact gameplay.However, in blockchain-based gaming systems, the ownership update may first be recorded on the blockchain, which may introduce a significant delay before the asset becomes available for use. Depending on the blockchain network this latency may range from several seconds to multiple minutes, and in cases of network congestion or low transaction fees, it may take up to 30 minutes or longer for the transaction to be confirmed. This delay may disrupt gameplay flow, as the player must wait for blockchain processing rather than being able to use the asset instantly upon acquisition.

[0043] The above described method may reduce latency when using an in-game asset by using blockchain-based ownership with the low-latency interaction of direct communication between a game server and a game client. The above described method may allow a player to earn an in-game asset through gameplay, with the game server detecting the relevant ingame event, recording the player's ownership in a local game server database, and issuing the in-game asset directly to the game client, where the player can immediately use the asset without waiting for blockchain confirmation. While the blockchain may be used to provide secure, transparent, and permanent records of asset ownership, the player benefits from real-time gameplay because the blockchain record is generated separately and asynchronously. The proposed technique may solve the latency problems of Web3 gaming by allowing the player to use assets immediately after earning them while ensuring that ownership of the in-game asset is reliably recorded on the blockchain, preserving the decentralized and tamper-proof advantages of blockchain technology without delaying the player’s experience.

[0044] Issuing the in-game asset

[0045] In some examples, issuing the in-game asset to the game client may comprise generating asset data by the game server. The asset data comprising at least information indicating the player's ownership of the in-game asset. Issuing the in-game asset to the game client may comprise transmitting the asset data from the game server to the game client. For example, generating asset data by the game server may immediately provide the player with proof of ownership and enable the in-game asset’s usage within the game, without waiting for the blockchain record to be created or updated. The asset data may be generated when the game server detects that the player has earned the in-game asset, for example, as a reward for completing a task, purchasing an item, or receiving a transfer from another player. The asset data may comprise at least information indicating the player's ownership of the in-game asset. The generated asset data allows the game client to recognize that theplayer is the rightful owner of the in-game asset, enabling the game mechanics to grant immediate access to the asset without reliance on external blockchain confirmation.

[0046] For example, transmitting the asset data from the game server to the game client may involve sending a structured data package over a secure communication channel, such as an encrypted API request, a WebSocket message, or a direct in-game network protocol. Because the game server itself may maintain an internal record of asset ownership that is kept in sync with the blockchain, the game client can trust the received asset data and allow the player to use the in-game asset immediately upon reception. This approach eliminates blockchain-related delays, as the blockchain record is generated asynchronously in the background. The player does not need to wait for blockchain confirmation, which could take several seconds or even minutes depending on network congestion and transaction fees. Instead, the game server guarantees immediate usability of the in-game asset within the game world, ensuring a smooth gameplay experience while maintaining blockchain-backed ownership verification.

[0047] In some examples, the asset data may comprise at least one of the following information: information on ownership of the in-game asset, a unique asset identifier, a description of the in-game asset, a visual representation of the in-game asset, a timestamp when the in-game asset was earned or a game state indicator corresponding to the time the asset was earned. For example, the information on ownership of the in-game asset may indicate which player or blockchain address currently holds the rights to the in-game asset. This ownership data may be represented as a player identifier within the game server or as a blockchain address if the asset is linked to a blockchain-based system. This information allows the game client and game server to determine whether the player has the authority to use, trade, or transfer the in-game asset.

[0048] For example, the unique asset identifier may be a distinct value assigned to each in-game asset to differentiate it from other assets. In a blockchain-based implementation, this identifier may be a token ID in an ERC-721 or ERC-1155 contract, while in a game servermanaged system, it may be an internal database entry or unique string identifier. Because a single blockchain address may own multiple assets, the unique asset identifier may be used to specify which asset is being referenced, ensuring that transactions, transfers, and game mechanics apply to the correct asset. The unique asset identifier ensures that each asset can be independently referenced, tracked, and transferred, preventing ambiguity when interacting with blockchain records or game server databases.For example, the description of the in-game asset may include textual or metadata-based information that defines the attributes of the asset. This may describe the asset’s type, name, function, and possible effects within the game. For instance, if the asset is a weapon, the description may include details such as damage level, rarity, and special abilities.

[0049] For example, the visual representation of the in-game asset may be a reference to an image, 3D model, or other graphical content that allows the game client to display the asset correctly in the game environment. This visual representation may be stored within the game itself, referenced via a URL, or retrieved from an external decentralized storage system, such as IPFS, ensuring that the appearance of the asset is consistent across different game clients.

[0050] For example, the timestamp when the in-game asset was earned may record the exact moment the player acquired the asset, which may be useful for tracking progression, verifying legitimacy, or determining eligibility for certain in-game rewards or events. In a blockchain system, this may correspond to the timestamp of the transaction that created or transferred the asset, whereas in a game server-based system, it may be a servergenerated timestamp.

[0051] For example, the game state indicator corresponding to the time the asset was earned may capture relevant in-game conditions or parameters at the moment the asset was obtained. This may include information such as the level of the player, the outcome of a game event, or any contextual data that may later influence the asset’s behavior, value, or eligibility for certain game mechanics. This allows the game server or blockchain system to enforce specific rules based on how and when the asset was acquired.

[0052] In some examples, issuing the in-game asset to the game client comprises signing the generated asset data by the game server using a private key of a private-public key pair. Issuing the in-game asset to the game client may comprise verifying the signature of the signed asset data by the game client using a corresponding public key of the private-public key pair. The in-game asset is directly usable by the player upon successful verification of the signature of the signed asset data. For example, signing the generated asset data by the game server using a private key of a private-public key pair may ensure the authenticity and integrity of the issued in-game asset by cryptographically proving that the asset data originates from a trusted source. When the game server generates the asset data it may apply a digital signature using its private key. This private key belongs to a cryptographic key pair, where only the game server has access to the private key, while the correspondingpublic key is made available to game clients for verification. The signature may be generated by applying a cryptographic hashing function to the asset data and encrypting the resulting hash with the private key. This process ensures that the signed asset data cannot be modified or forged without detection, allowing the game client to validate that the asset data was legitimately issued by the game server and has not been tampered with.

[0053] For example, verifying the signature of the signed asset data by the game client using the corresponding public key of the private-public key pair may allow the game client to confirm the authenticity of the in-game asset before allowing the player to use it. Upon receiving the signed asset data, the game client may apply a verification algorithm using the public key associated with the game server. This verification process involves decrypting the digital signature using the public key and comparing the result to a freshly computed hash of the received asset data. If the values match, the game client confirms that the asset data is authentic and has not been altered. Since the verification occurs locally on the game client, the in-game asset becomes directly usable by the player upon successful verification of the signature, without requiring interaction with the blockchain or waiting for a blockchain transaction to be confirmed. This approach ensures low-latency usability while maintaining trust, as only assets properly signed by the game server are accepted, preventing fraudulent or unauthorized asset issuance.

[0054] Asset ownership

[0055] In some examples, the method 100 may further comprise continuously monitoring of the blockchain by the game server to monitor the ownership of the in-game asset. For example, the game server may run a process that regularly queries blockchain nodes or operates its own blockchain node to observe newly added blocks and the records within them. The game server may parse each new block as it is added to the blockchain and extract relevant records and / or transactions that affect ownership of specific in-game assets by checking for asset-related events, such as transfers, mints, or burns, within smart contracts or token standards like ERC-20, ERC-721, or ERC-1155. To perform this monitoring, the game server may track the unique identifiers of the in-game assets and associated blockchain addresses, comparing the stored ownership data in the game server database to the current state reflected on the blockchain, ensuring that any ownership changes are detected in near real-time as new blocks are confirmed. For example, the game server may implement event listeners or use blockchain APIs, such as WebSocket-based interfaces or polling mechanisms, to subscribe to specific smart contract events that broadcast ownership changes, such as a Transfer event emitted by an NFT contract. When theblockchain emits such an event, the game server may automatically receive notifications containing the updated ownership details, such as the previous owner’s and new owner’s blockchain addresses and the asset identifier. This allows the game server to continuously synchronize its internal database with the blockchain state, ensuring that if a player transfers an in-game asset to another player through the blockchain - without direct involvement of the game server - the updated ownership is correctly reflected within the computer game and prevents inconsistencies such as allowing a player to use an asset they no longer own.

[0056] In some examples, the method 100 may further comprise updating the game server database according to a detected update of ownership of the in-game asset in the blockchain record. For example, when the game server monitors the blockchain, it may detect an update of ownership of the in-game asset in a blockchain record. For example, new blockchain records or smart contract events are detected indicating that an in-game asset has been transferred from one blockchain address to another. In order to correctly apply such updates within the computer game, the game server database may maintain a link between each blockchain address and the corresponding player of the computer game, or the blockchain record itself may include information identifying the player associated with the blockchain address. The link between a blockchain address and a player in the game server database may be stored as a mapping structure, such as a table associating player IDs or usernames with their registered blockchain addresses, or it may be implemented through an account authentication mechanism where players sign a message with their private key to prove ownership of a blockchain address. In some examples, the game server may require players to register their blockchain addresses upon account creation, linking them permanently to their in-game identity. When an ownership update is detected, the game server may modify its internal database to reflect the new association between the in-game asset and the blockchain address of the new owner, and by using the link between the blockchain address and the player, the game server may update the player-related data accordingly. This ensures that the computer game remains consistent with the state of the blockchain and that only the correct player has access to the in-game asset within the game. This may prevent situations where a player continues to use an in-game asset in the computer game even though, according to the blockchain records, the asset has been transferred to another player, and may allow the game server to enforce correct usage of in-game assets based on the verified blockchain ownership.

[0057] In some examples, the method 100 further comprising issuing a request, by the game client, to assign the ownership of the in-game asset in the blockchain record. In some examples,the method 100 may further comprise issuing a request, by the game server, to assign the ownership of the in-game asset in the blockchain record. For example, the request to assign the ownership of the in-game asset in the blockchain record may be issued either by the game client or the game server. When the game client issues the request, the apparatus 400 may generate a transaction that includes the details of the in-game asset and the blockchain address of the player who is to be assigned ownership. The game client may then sign the transaction using the private key associated with the player’s blockchain address before submitting it to a blockchain node for validation and recording. Alternatively, when the game server issues the request, the game server may generate and broadcast the transaction on behalf of the player, for example, in cases where the game server has the authority to distribute assets directly. In this case, the game server may sign the transaction using its own private key, and depending on the blockchain’s rules, the player may later need to claim or confirm the asset transfer by signing a follow-up transaction.

[0058] For example, the assignment of ownership in the blockchain record may occur through the creation of a new blockchain record (transaction) that registers the in-game asset under the player's blockchain address for the first time. This may be implemented using a minting mechanism in a smart contract, where a function such as “mint” creates a new entry in the blockchain that associates the asset identifier with the player’s blockchain address. If the asset is represented as a non-fungible token (NFT) under standards such as ERC-721 or ERC-1155, the smart contract’s internal mapping may be updated to reflect the new owner. If the asset is represented by a fungible token, such as an ERC-20 token, the token balance of the player’s blockchain address may be increased to reflect the newly assigned asset. Once this blockchain record is validated by the blockchain network and included in a block, the ownership of the in-game asset is permanently recorded, and any entity monitoring the blockchain, such as the game server, may detect the new assignment and update its internal database accordingly.

[0059] In some examples, the method 100 may further comprise issuing a request, by the game client (for example apparatus 400), to update the ownership of the in-game asset in the blockchain from the player to a second player. For example, issuing a request by the game client to update the ownership of the in-game asset in the blockchain from the player to a second player may involve the game client generating and submitting a transaction that transfers the asset from one blockchain address to another. Since the in-game asset is already recorded on the blockchain and associated with the player’s blockchain address, the player, as the current owner, may have to authorize the transaction using his private key. The game client may construct a transaction containing the unique asset identifier(because the blockchain address may comprise more than one in-game asset), the blockchain address of the current owner (the player), and the blockchain address of the new owner (the second player). Before submission to the blockchain network, the transaction may be digitally signed by the game client using the player’s private key to prove that the transfer is authorized. Once signed, the transaction is broadcast to a blockchain node, which validates the request according to the rules of the blockchain protocol and forwards it to the network for processing.

[0060] For example, to ensure that the computer game remains consistent with the blockchain state without introducing unnecessary delays, the game client may also inform the game server of the intended transfer at the time the request is issued. By notifying the game server, the game may immediately reflect the asset’s new ownership, allowing the second player to use the in-game asset without waiting for the blockchain transaction to be confirmed. This may for example prevent mismatches where the blockchain has recorded the updated ownership, but the game server still considers the first player as the owner due to latency in monitoring blockchain updates. In some examples, the game server may temporarily approve asset usage for the second player based on the game client’s request, even before the blockchain confirmation is completed, ensuring a seamless gameplay experience while still maintaining blockchain-backed ownership verification.

[0061] For example, the ownership of the in-game asset is updated in the blockchain when the transaction is confirmed and included in a new block, generating a new blockchain record that documents the transfer of ownership. If the asset is managed by a smart contract, such as an ERC-721 or ERC-1155 NFT contract, the smart contract’s Transfer function may be executed, which updates the contract’s internal mapping to reassign the asset’s unique identifier to the blockchain address of the second player. If the asset is recorded as a fungible token, such as an ERC-20 token, the contract may adjust the token balances of both players, deducting the asset from the sender’s balance and crediting the recipient. Once the transaction is finalized on the blockchain, any entity monitoring the blockchain, such as the game server, may detect the ownership update and synchronize its internal game database to reflect the new ownership, ensuring that only the second player has access to the asset within the game.

[0062] In some examples, the method 100 may further comprise paying, by the game server and / or by the game client, a fee required for generating the record on the blockchain. For example, paying a fee required for generating the record on the blockchain may be necessary because some blockchain networks require transaction fees to compensate forthe computational resources used by blockchain nodes to validate and store data. When the blockchain record is generated to register, assign, or transfer the ownership of the in-game asset, the transaction may be processed and included in a block by blockchain validators or miners, depending on a consensus mechanism of the blockchain. The fee amount may vary based on factors such as network congestion, the complexity of the transaction (e.g., smart contract interactions requiring more gas on Ethereum), and the priority of the transaction, where higher fees may lead to faster processing. Without paying this fee, the transaction may be delayed or rejected, preventing the in-game asset from being properly recorded on the blockchain.

[0063] For example, the fee may be paid by either the game server or the game client. If the game client pays the fee, the player may be responsible for covering the transaction cost using cryptocurrency stored in their blockchain wallet, ensuring that only players who actively participate in blockchain interactions bear the cost. If the game server pays the fee, the game publisher or operator may cover the cost of recording in-game assets on the blockchain, allowing for a more seamless user experience where players do not need to hold or interact with cryptocurrency directly. In some implementations, the game server may batch multiple transactions together to optimize costs or may deduct a service fee from the player’s in-game balance to offset blockchain transaction costs. By allowing either the game server or game client to pay the fee, the system provides flexibility in handling blockchain costs while ensuring that the in-game asset is successfully recorded on the blockchain.

[0064] In some example, a fee required for generating the record on the blockchain, is paid by a third party. For example, a third party may be an external entity that is neither the game server nor the game client but has an interest in facilitating blockchain transactions. The third party may include advertisers, who sponsor blockchain transaction fees in exchange for promotional opportunities within the game, game publishers, who subsidize transaction costs to enhance user experience and encourage engagement, blockchain infrastructure providers, who offer fee sponsorship as part of a broader Web3 adoption strategy, or decentralized gaming guilds, which support player interactions by covering blockchain fees as part of a community-driven model. The third party may pay the fee by directly signing and broadcasting the transaction on behalf of the game client or game server, where the transaction fee is deducted from the third party’s blockchain wallet. Alternatively, the third party may fund a gasless transaction system, where the game client submits a request to a relayer service that pays the fee and processes the transaction using a smart contract mechanism, such as meta-transactions in Ethereum-based systems. This enables playersto interact with blockchain-based assets without needing to hold cryptocurrency, reducing friction in onboarding and gameplay.

[0065] Further details and aspects are mentioned in connection with the examples described below. The example shown in Fig. 1 may include one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described below (e.g., Figs. 2 - 6).

[0066] Fig. 2 illustrates a block diagram of an example of an apparatus 200. The apparatus 200 may be a game server. The apparatus 200 comprises circuitry that is configured to provide the functionality of the apparatus 200. The apparatus 200 comprises a processing circuitry 210. For example, the processing circuitry 210 may be a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which or all of which may be shared, a digital signal processor (DSP) hardware, an application specific integrated circuit (ASIC), a neuromorphic processor or a field programmable gate array (FPGA). The processing circuitry 210 may optionally be coupled to, e.g., memory such as read only memory (ROM) for storing software, random access memory (RAM) and / or non-volatile memory. For example, the apparatus 200 may comprise memory configured to store instructions, which when executed by the processing circuitry 210, cause the processing circuitry 210 to perform the steps and methods described herein. In some examples, the apparatus 200 may further comprise storage circuitry configured to store data. The storage circuitry may operate in cooperation with the processing circuitry 210 to ensure the persistent and consistent management of information within the apparatus 200. In some examples, the apparatus 200 may further comprise interface circuitry configured to facilitate communication between the apparatus 200 and external entities (such as the game client 400, and / or the node apparatus 300 of the blockchain). The interface circuitry may be responsible for transmitting and receiving data (such as asset data).

[0067] The circuitry 210 may be configured to perform parts or all of the method as described above with regards to Fig. 1.

[0068] The circuitry 210 is configured to detect an in-game event. The in-game event indicates that a player playing at a game client (for example apparatus 400) has earned the in-game asset. The circuitry 210 is further configured to update a game server database to record the player's ownership of the in-game asset. The circuitry 210 is further configured to issue the in-game asset to the game client. The in-game asset is directly usable by the player upon its reception by the game client.In some examples, the circuitry 210 may be further configured to continuously monitor the blockchain, to monitor the ownership of the in-game asset. For example, the circuitry 210 may run a process that regularly queries blockchain nodes or operates its own blockchain node to observe newly added blocks and the records within them. The circuitry 210 may parse each new block as it is added to the blockchain and extract relevant records and / or transactions that affect ownership of specific in-game assets by checking for asset-related events, such as transfers, mints, or burns, within smart contracts or token standards like ERC-20, ERC-721, or ERC-1155. To perform this monitoring, the circuitry 210 may track the unique identifiers of the in-game assets and associated blockchain addresses, comparing the stored ownership data in the game server database to the current state reflected on the blockchain, ensuring that any ownership changes are detected in near real-time as new blocks are confirmed. For example, the circuitry 210 may implement event listeners or use blockchain APIs, such as WebSocket-based interfaces or polling mechanisms, to subscribe to specific smart contract events that broadcast ownership changes, such as a Transfer event emitted by an NFT contract. When the blockchain emits such an event, the game server may automatically receive notifications containing the updated ownership details, such as the previous owner’s and new owner’s blockchain addresses and the asset identifier. This allows the circuitry 210 to continuously synchronize its internal database with the blockchain state, ensuring that if a player transfers an in-game asset to another player through the blockchain - without direct involvement of the game server - the updated ownership is correctly reflected within the computer game and prevents inconsistencies such as allowing a player to use an asset they no longer own.

[0069] Further details and aspects are mentioned in connection with the examples described above or below. The example shown in Fig. 2 may include one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Fig. 1) or below (e.g., Figs. 3 - 6).

[0070] Fig. 3 illustrates a block diagram of an example of an apparatus 300. The apparatus 300 may be a node of a blockchain. The apparatus 300 comprises circuitry that is configured to provide the functionality of the apparatus 300. The apparatus 300 comprises a processing circuitry 310. For example, the processing circuitry 310 may be a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which or all of which may be shared, a digital signal processor (DSP) hardware, an application specific integrated circuit (ASIC), a neuromorphic processor or a field programmable gate array (FPGA). The processing circuitry 310 may optionally be coupled to, e.g., memorysuch as read only memory (ROM) for storing software, random access memory (RAM) and / or non-volatile memory. For example, the apparatus 300 may comprise memory configured to store instructions, which when executed by the processing circuitry 310, cause the processing circuitry 310 to perform the steps and methods described herein. In some examples, the apparatus 300 may further comprise storage circuitry configured to store data. The storage circuitry may operate in cooperation with the processing circuitry 310 to ensure the persistent and consistent management of information within the apparatus 300. In some examples, the apparatus 300 may further comprise interface circuitry configured to facilitate communication between the apparatus 300 and external entities (such as the game 200, and / or the game client 400). The interface circuitry may be responsible for transmitting and receiving data.

[0071] The circuitry 310 may be configured to perform parts or all of the method as described above with regards to Fig. 1.

[0072] For example, a blockchain (also referred to as blockchain network) may be a distributed digital ledger that records data in a secure, transparent, and immutable way across a network of nodes, where each node stores a copy of the entire ledger and verifies new transactions according to a consensus mechanism. For example, apparatus 300 may operate one or more nodes of the blockchain. For example, the blockchain may consist of a continuous sequence of blocks, where each block contains data, a reference to the previous block, and a cryptographic hash ensuring the integrity of the entire chain. The blockchain may store any type of data, such as financial transactions, ownership records, or in-game asset information, where the data is included as part of the blocks. For example, the blockchain may store transactions.

[0073] The circuitry 310 is configured to receive a request by a game client to generate a blockchain record on the blockchain. The circuitry 310 is further configured to generate the record on the blockchain corresponding to an in-game asset. The blockchain record indicates the player's ownership of the in-game asset. The in-game asset is earned by the player playing at the game client.

[0074] For example, generating a blockchain record may refer to creating a new entry of data on the blockchain by the node apparatus 300 that becomes part of a block, where the blockchain record stores information such as asset details, ownership data, or other relevant information in a permanent and verifiable manner. The blockchain record may be generated by one or more nodes of the blockchain, such as apparatus 300 and may beforwarded into the network to other nodes. The generation of the blockchain record may be requested by the game client, the game server, or an external service, which may submit the required data to one or more blockchain nodes. Other nodes of the blockchain may verify the correctness and validity of the request according to the blockchain’s rules and, after successful validation, may add the data as part of a block, thereby creating the blockchain record and making it permanently accessible and verifiable across all nodes that maintain a copy of the blockchain.

[0075] Further details and aspects are mentioned in connection with the examples described above or below. The example shown in Fig. 3 may include one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Figs. 1 - 2) or below (e.g., Figs. 4 -6).

[0076] Fig. 4 illustrates a block diagram of an example of an apparatus 400. The apparatus 400 may be a game client. The apparatus 400 comprises circuitry that is configured to provide the functionality of the apparatus 400. The apparatus 400 comprises a processing circuitry 410. For example, the processing circuitry 410 may be a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which or all of which may be shared, a digital signal processor (DSP) hardware, an application specific integrated circuit (ASIC), a neuromorphic processor or a field programmable gate array (FPGA). The processing circuitry 410 may optionally be coupled to, e.g., memory such as read only memory (ROM) for storing software, random access memory (RAM) and / or non-volatile memory. For example, the apparatus 400 may comprise memory configured to store instructions, which when executed by the processing circuitry 410, cause the processing circuitry 410 to perform the steps and methods described herein. In some examples, the apparatus 400 may further comprise storage circuitry configured to store data. The storage circuitry may operate in cooperation with the processing circuitry 410 to ensure the persistent and consistent management of information within the apparatus 400. In some examples, the apparatus 400 may further comprise interface circuitry configured to facilitate communication between the apparatus 400 and the external entities (such as the game server 200, and / or the node apparatus 300 of the blockchain). The interface circuitry may be responsible for transmitting and receiving data (such as asset data).

[0077] The circuitry 410 may be configured to perform parts or all of the method as described above with regards to Fig. 1.The circuitry 410 is configured to receive an in-game asset from a game server such as apparatus 200. The in-game asset is earned by the player playing at the game client 400. The in-game asset is directly usable by the player upon its reception. The circuitry 410 is further configured to request to generate a blockchain record on the blockchain. The blockchain record indicates the player's ownership of the in-game asset. For example, the in-game asset being directly usable means that the usability of the in-game asset by the player playing at the game client may not depend on the completion of an external confirmation (such as a blockchain transaction or validation by a decentralized network), which may otherwise introduce latency. Instead, the direct usability may rely on the fact that the game server 200 has acknowledged the player's right to the in-game asset through the transmission of the in-game asset and / or the corresponding asset data. In this context, the direct usability of the in-game asset may be enabled solely based on the transmission and reception of the asset and / or asset data between the game server 200 and the game client 400, which may occur over a local network or internet connection with only short latency, such as within a few milliseconds to a few hundred milliseconds. For example, the player may, upon reception of the in-game asset by the circuitry 410 of the game server 400, immediately access, equip, or activate the in-game asset in the computer game, once the game client 400 has received the asset and / or asset data transmitted by the game server 200. By allowing the player to immediately use the in-game asset upon reception from the game server 200, it is ensured that gameplay remains uninterrupted and responsive, even while an external confirmation (such as a blockchain recordation) may be pending. For example, a player may immediately use the Magic Sword in battle upon receiving it, without needing to wait for external confirmation.

[0078] For example, to ensure that the computer game remains consistent with the blockchain state without introducing unnecessary delays, the circuitry 410 may be configured to inform the game server of the intended transfer at the time the request is issued. By notifying the game server 200, the game may immediately reflect the asset’s new ownership, allowing the second player to use the in-game asset without waiting for the blockchain transaction to be confirmed. This may for example prevent mismatches where the blockchain has recorded the updated ownership, but the game server still considers the first player as the owner due to latency in monitoring blockchain updates. In some examples, the game server 200 may temporarily approve asset usage for the second player based on the game client’s request, even before the blockchain confirmation is completed, ensuring a seamless gameplay experience while still maintaining blockchain-backed ownership verification.For example, the in-game asset may be directly usable by the player upon successful verification of the signature of the signed asset data by the circuitry 410. For example, signing the generated asset data by the game server 200 using a private key of a privatepublic key pair may ensure the authenticity and integrity of the issued in-game asset by cryptographically proving that the asset data originates from a trusted source. When the game server 200 generates the asset data it may apply a digital signature using its private key. This private key belongs to a cryptographic key pair, where only the game server 200 has access to the private key, while the corresponding public key is made available to game clients 400 for verification. The signature may be generated by applying a cryptographic hashing function to the asset data and encrypting the resulting hash with the private key. This process ensures that the signed asset data cannot be modified or forged without detection, allowing the circuitry 410 of the game client 400 to validate that the asset data was legitimately issued by the game server 200 and has not been tampered with.

[0079] In some examples, the circuitry 410 may be further configured to issue a request to update the ownership of the in-game asset in the blockchain record, from the player to a second player. For example, issuing a request may comprise the circuitry 410 generating and submitting a transaction that transfers the asset from one blockchain address to another. Since the in-game asset is already recorded on the blockchain and associated with the player’s blockchain address, the player, as the current owner, may have to authorize the transaction using his private key. The circuitry 410 may construct a transaction containing the unique asset identifier (because the blockchain address may comprise more than one in-game asset), the blockchain address of the current owner (the player), and the blockchain address of the new owner (the second player). Before submission to the blockchain network, the transaction may be digitally signed by the circuitry 410 using the player’s private key to prove that the transfer is authorized. Once signed, the transaction is broadcast to a blockchain node, which validates the request according to the rules of the blockchain protocol and forwards it to the network for processing.

[0080] Further details and aspects are mentioned in connection with the examples described above or below. The example shown in Fig. 4 may include one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Figs. 1 - 3) or below (e.g., Figs. 5 -6).

[0081] Fig. 5 illustrates a system 500 comprising a game server 200, a node apparatus 300 of a blockchain and a game client 400. The game server 200, the node apparatus 300 of ablockchain and the game client 400 may be configured as described above and may perform the method as described above (see Figs. 1 to 4). The game server 200, the node apparatus 300 of a blockchain and the game client 400 may comprise interface circuitry configured to facilitate communication between them.

[0082] Further details and aspects are mentioned in connection with the examples described above or below. The example shown in Fig. 5 may include one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Figs. 1 - 4) or below (e.g., Fig. 6).

[0083] Fig. 6 illustrates an example of a process 600 for reducing latency when using an in-game asset. The process 600 comprises interactions between a first player game client 610 (Player 1), a game server 620, a blockchain comprising one or more nodes 630, and a second player game client 640 (Player 3). The game server 620 may be the system that controls the flow of the game, and that enforces the game rules. It may under control of a game publisher. The game client 630 may be the system that is running on the Player’s computer or may be the clients computer. For example, at home or on a train or the like. It may run a client software designed by the game publisher and communicates with the game server. The blockchain may be secure distributed ledger where the ownership of an in-game assets may be recorded, for example as a token (such as “Player 1 found Magical Sword S1 at time T1 ; or “Player 2 sold Proton Pack P1 to Player 3 at time T2”).

[0084] Process 600 describes a sequence of steps where an in-game asset (e.g., Magic Sword) is acquired, utilized, and transferred between players, with its ownership being monitored and recorded on the blockchain 630 to ensure immutable tracking and enforcement of asset transactions. At step 650 the game server 620 continuously monitors der blockchain 630 to check which player owns which asset. At step 651, Player 1 initiates a game session by interacting with the game server 620. At step 652, Player 1 performs an action, such as opening a treasure chest. This triggers an update 653 of the game state by the game server 620 to reflect that Player 1 has acquired an in-game asset (Magic Sword). At step 654, the acquired in-game asset (Magic Sword) is represented as a blockchain-based token. The ingame asset may be for example a prize won by Player 1 , a certain attribute for the player’s character, or even proof of certain high scores or levels that were reached. The token includes metadata 655 such as a timestamp, description, and cryptographic signature, forming a tokenized digital representation of the asset. This ensures that the ownership state of the in-game asset is stored immutably on the blockchain 630, allowing for transparent validation and decentralized enforcement of ownership. At step 656, Player 1decides to use the in-game asset (Magic Sword), for example to attack another player (Player 2). At step 657, the game server 620 verifies the current game state to confirm that Player 1 still owns the in-game asset (Magic Sword). This verification ensures that no unauthorized duplication or fraudulent transactions occur. Upon successful verification, at step 658, the game server registers the attack and applies its effect in the game world. At step 659, the in-game asset acquisition is recorded on the blockchain 630, ensuring that the use of the in-game asset (Magic Sword) is cryptographically registered, thereby preventing unauthorized modifications or disputes over its usage. At step 660, Player 1 initiates a transfer of the in-game asset (Magic Sword) to Player 3. This transfer triggers an update on the blockchain 630, reflecting the new ownership state. At step 661, Player 3 receives confirmation from the blockchain 630 that he is now the rightful owner of the in-game asset (Magic Sword). At step 662 the game server 620 continuously monitors these ownership transactions to ensure that players only use the assets they verifiably own. At step 663, the game server 620 updates the game state to reflect that Player 3 now holds the in-game asset (Magic Sword). Player 3 subsequently chooses to use the in-game asset (Magic Sword) at step 664, initiating another attack on Player 2. At step 665 the game server 620 performs another verification step to ensure that Player 3 is indeed the current owner of the in-game asset (Magic Sword). Upon verification, at step 666, the attack is successfully executed, and Player 2 is eliminated from the game.

[0085] Further details and aspects are mentioned in connection with the examples described above. The example shown in Fig. 6 may include one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Figs. 1 - 5).

[0086] In the following, some examples of the proposed concept are presented:

[0087] An example (e.g., example 1) relates to a method for reducing latency when using an ingame asset, comprising detecting an in-game event by a game server, the in-game event indicating that a player playing at a game client has earned the in-game asset, updating a game server database to record the player's ownership of the in-game asset, issuing the ingame asset from the game server to the game client, wherein the in-game asset is directly usable by the player upon its reception by the game client, generating a record on a blockchain, the blockchain record indicating the player's ownership of the in-game asset.

[0088] Another example (e.g., example 2) relates to a previous example (e.g., example 1) or to any other example, further comprising that issuing the in-game asset to the game clientcomprises generating asset data by the game server, the asset data comprising at least information indicating the player's ownership of the in-game asset, and transmitting the asset data from the game server to the game client.

[0089] Another example (e.g., example 3) relates to a previous example (e.g., example 2) or to any other example, further comprising that issuing the in-game asset to the game client comprises signing the generated asset data by the game server using a private key of a private-public key pair, verifying the signature of the signed asset data by the game client using a corresponding public key of the private-public key pair, wherein the in-game asset is directly usable by the player upon successful verification of the signature of the signed asset data.

[0090] Another example (e.g., example 4) relates to a previous example (e.g., one of the examples 2 to 3) or to any other example, further comprising that the asset data comprises at least one of the following information: information on ownership of the in-game asset, a unique asset identifier, a description of the in-game asset, a visual representation of the in-game asset, a timestamp when the in-game asset was earned or a game state indicator corresponding to the time the asset was earned.

[0091] Another example (e.g., example 5) relates to a previous example (e.g., one of the examples 1 to 4) or to any other example, further comprising that the method further comprises continuously monitoring of the blockchain by the game server to monitor the ownership of the in-game asset.

[0092] Another example (e.g., example 6) relates to a previous example (e.g., one of the examples 1 to 5) or to any other example, further comprising that the method further comprises updating the game server database according to a detected update of ownership of the ingame asset in the blockchain record.

[0093] Another example (e.g., example 7) relates to a previous example (e.g., one of the examples 1 to 6) or to any other example, further comprising that the method further comprises issuing a request, by the game client, to update the ownership of the in-game asset in the blockchain from the player to a second player.

[0094] Another example (e.g., example 8) relates to a previous example (e.g., one of the examples 1 to 7) or to any other example, further comprising that the method further comprisingissuing a request, by the game client, to assign the ownership of the in-game asset in the blockchain record.

[0095] Another example (e.g., example 9) relates to a previous example (e.g., one of the examples 1 to 10) or to any other example, further comprising that the method further comprises issuing a request, by the game server, to assign the ownership of the in-game asset in the blockchain record.

[0096] Another example (e.g., example 10) relates to a previous example (e.g., one of the examples 1 to 9) or to any other example, further comprising that generating the blockchain record comprises using a blockchain key pair associated with the player.

[0097] Another example (e.g., example 11) relates to a previous example (e.g., one of the examples 1 to 10) or to any other example, further comprising that the blockchain record is based on at least one of a smart contract, a blockchain token or a non-fungible token, NFT.

[0098] Another example (e.g., example 12) relates to a previous example (e.g., one of the examples 1 to 11) or to any other example, further comprising that the method further comprises issuing, by the game client, a request to generate the blockchain record on the blockchain.

[0099] Another example (e.g., example 13) relates to a previous example (e.g., one of the examples 1 to 12) or to any other example, further comprising that the method further comprises paying, by the game server and / or by the game client, a fee required for generating the record on the blockchain.

[0100] Another example (e.g., example 14) relates to a previous example (e.g., one of the examples 1 to 12) or to any other example, further comprising that a fee required for generating the record on the blockchain, is paid by a third party.

[0101] An example (e.g., example 15) relates to a game server comprising circuitry configured to detect an in-game event, the in-game event indicating that a player playing at a game client has earned the in-game asset, update a game server database to record the player's ownership of the in-game asset, issue the in-game asset to the game client, wherein the ingame asset is directly usable by the player upon its reception by the game client.Another example (e.g., example 16) relates to a previous example (e.g., example 15) or to any other example, further comprising that the circuitry is further configured to continuously monitor the blockchain to monitor the ownership of the in-game asset.

[0102] An example (e.g., example 17) relates to an apparatus for a node of a blockchain, the apparatus comprising circuitry configured to receive a request by a game client to generate a blockchain record on the blockchain, generate the record on the blockchain corresponding to an in-game asset, the blockchain record indicating the player's ownership of the in-game asset, wherein the in-game asset is earned by the player playing at the game client.

[0103] An example (e.g., example 18) relates to a game client comprising circuitry configured to receive an in-game asset from a game server, wherein the in-game asset is earned by the player playing at the game client, wherein the in-game asset is directly usable by the player upon its reception, request to generate a blockchain record on the blockchain, the blockchain record indicating the player's ownership of the in-game asset.

[0104] Another example (e.g., example 19) relates to a previous example (e.g., example 18) or to any other example, further comprising that the circuitry is further configured to issue a request to update the ownership of the in-game asset in the blockchain record, from the player to a second player.

[0105] An example (e.g., example 20) relates to a system comprising the game server of any one of examples 15 to 16, the apparatus for a node of a blockchain of example 17, and the game client of any one of examples 18 to 19.

[0106] An example (e.g., example 21) relates to a system comprising A game server comprising circuitry configured to detect an in-game event, the in-game event indicating that a player playing at a game client has earned the in-game asset, update a game server database to record the player's ownership of the in-game asset, issue the in-game asset to the game client, wherein the in-game asset is directly usable by the player upon its reception by the game client, an apparatus for a node of a blockchain, the apparatus comprising circuitry configured to receive a request by a game client to generate a blockchain record on the blockchain, generate the record on the blockchain corresponding to an in-game asset, the blockchain record indicating the player's ownership of the in-game asset, wherein the ingame asset is earned by the player playing at the game client, a game client comprising circuitry configured to receive an in-game asset from a game server, wherein the in-game asset is earned by the player playing at the game client, wherein the in-game asset isdirectly usable by the player upon its reception, request to generate a blockchain record on the blockchain, the blockchain record indicating the player's ownership of the in-game asset.

[0107] The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

[0108] Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, steps, operations or processes of different ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and / or contain machineexecutable, processor-executable or computer-executable programs and instructions. Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

[0109] It is further understood that the disclosure of several steps, processes, operations or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execution of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process or operation may include and / or be broken up into several sub-steps, -functions, -processes or -operations.

[0110] If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described inrelation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.

[0111] The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not intended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

ClaimsWhat is claimed is:

1. A method for reducing latency when using an in-game asset, comprising detecting an in-game event by a game server, the in-game event indicating that a player playing at a game client has earned the in-game asset;updating a game server database to record the player's ownership of the in-game asset;issuing the in-game asset from the game server to the game client, wherein the ingame asset is directly usable by the player upon its reception by the game client;generating a record on a blockchain, the blockchain record indicating the player's ownership of the in-game asset.

2. The method of claim 1, wherein issuing the in-game asset to the game client comprises:generating asset data by the game server, the asset data comprising at least information indicating the player's ownership of the in-game asset; andtransmitting the asset data from the game server to the game client.

3. The method of claim 2, wherein issuing the in-game asset to the game client comprises:signing the generated asset data by the game server using a private key of a private-public key pair;verifying the signature of the signed asset data by the game client using a corresponding public key of the private-public key pair,wherein the in-game asset is directly usable by the player upon successful verification of the signature of the signed asset data.

4. The method of claim 2, wherein the asset data comprises at least one of the following information: information on ownership of the in-game asset, a unique asset identifier, a description of the in-game asset, a visual representation of the in-game asset, a timestamp when the in-game asset was earned or a game state indicator corresponding to the time the asset was earned.

5. The method of claim 1, wherein the method further comprises continuously monitoring of the blockchain by the game server to monitor the ownership of the in-game asset.

6. The method of claim 1, wherein the method further comprises updating the game server database according to a detected update of ownership of the in-game asset in the blockchain record.

7. The method of claim 1, wherein the method further comprises issuing a request, by the game client, to update the ownership of the in-game asset in the blockchain from the player to a second player.

8. The method of claim 1, wherein the method further comprising issuing a request, by the game client, to assign the ownership of the in-game asset in the blockchain record.

9. The method of claim 1, wherein the method further comprises issuing a request, by the game server, to assign the ownership of the in-game asset in the blockchain record.

10. The method of claim 1, wherein generating the blockchain record comprises using a blockchain key pair associated with the player.

11. The method of claim 1, wherein the blockchain record is based on at least one of a smart contract, a blockchain token or a non-fungible token, NFT.

12. The method of claim 1, wherein the method further comprises issuing, by the game client, a request to generate the blockchain record on the blockchain.

13. The method of claim 1, wherein the method further comprises paying, by the game server and / or by the game client, a fee required for generating the record on the blockchain.

14. The method of claim 1, wherein a fee required for generating the record on the blockchain, is paid by a third party.

15. A game server comprising circuitry configured to:detect an in-game event, the in-game event indicating that a player playing at a game client has earned the in-game asset;update a game server database to record the player's ownership of the in-game asset;issue the in-game asset to the game client, wherein the in-game asset is directly usable by the player upon its reception by the game client.

16. The game server of claim 15, wherein the circuitry is further configured to continuously monitor the blockchain to monitor the ownership of the in-game asset.

17. An apparatus for a node of a blockchain, the apparatus comprising circuitry configured to:receive a request by a game client to generate a blockchain record on the blockchain,generate the record on the blockchain corresponding to an in-game asset, the blockchain record indicating the player's ownership of the in-game asset,wherein the in-game asset is earned by the player playing at the game client.

18. A game client comprising circuitry configured to:receive an in-game asset from a game server, wherein the in-game asset is earned by the player playing at the game client,wherein the in-game asset is directly usable by the player upon its reception; request to generate a blockchain record on the blockchain, the blockchain record indicating the player's ownership of the in-game asset.

19. The game client of claim 18, wherein the circuitry is further configured to issue a request to update the ownership of the in-game asset in the blockchain record, from the player to a second player.

20. A system comprising:a game server comprising circuitry configured to:detect an in-game event, the in-game event indicating that a player playing at a game client has earned the in-game asset;update a game server database to record the player's ownership of the ingame asset;issue the in-game asset to the game client, wherein the in-game asset is directly usable by the player upon its reception by the game client;an apparatus for a node of a blockchain, the apparatus comprising circuitry configured to:receive a request by a game client to generate a blockchain record on the blockchain,generate the record on the blockchain corresponding to an in-game asset, the blockchain record indicating the player's ownership of the in-game asset, wherein the in-game asset is earned by the player playing at the game client;a game client comprising circuitry configured to:receive an in-game asset from a game server, wherein the in-game asset is earned by the player playing at the game client,wherein the in-game asset is directly usable by the player upon its reception; request to generate a blockchain record on the blockchain, the blockchain record indicating the player's ownership of the in-game asset.

Images