Game resource management method, device, equipment and storage medium

Abstract

This application provides a method, apparatus, device, and storage medium for managing game resources, relating to the field of game technology. The method includes: initiating voting requests to each first user possessing target resources regarding preset game requirements; wherein the target resources are obtained by the first users after staking preset resources; and receiving the voting results from each of the first users regarding the preset game requirements. Compared to existing technologies, this avoids the problem that users can only play according to game settings and have no decision-making power over the game's outcome.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a method, apparatus, device, and storage medium for managing game resources. Background Technology

[0002] With the development of internet technology, games are playing an increasingly important role in people's lives. People use games as a form of leisure and entertainment, and team-based games are particularly popular.

[0003] In existing technologies, in some competitive games, users can engage in battles according to the game's rules. For example, users can battle against other players in the game, such as in arena or battlefield battles; users can also battle against computer players, that is, users can perform dungeon quests.

[0004] However, in this kind of game process, users can only play according to the game settings, and have no decision-making power over the subsequent development of the game, the development of game dungeons, or game functions. Summary of the Invention

[0005] The purpose of this application is to address the shortcomings of the prior art by providing a method, apparatus, device, and storage medium for managing game resources, thereby solving the problem that users can only play the game according to the game settings and do not have decision-making power over the game's outcome.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0007] In a first aspect, one embodiment of this application provides a method for managing game resources, applied to a blockchain node, the method comprising:

[0008] A voting request is initiated to each first user who possesses the target resource regarding the preset game requirements; wherein, the target resource is obtained by the first user after staking the first preset resource;

[0009] Receive the voting results from each of the third users regarding the preset game requirements.

[0010] Secondly, another embodiment of this application provides a game resource management device, the device comprising: a sending module and a receiving module, wherein:

[0011] The sending module is used to initiate voting requests for preset game requirements to each first user who possesses the target resource; wherein, the target resource is obtained by the first user after pledging the first preset resource;

[0012] The receiving module is used to receive the voting results of each of the third users regarding the preset game requirements.

[0013] Thirdly, another embodiment of this application provides a game resource management device, including: a processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the game resource management device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of any of the methods described in the first aspect above.

[0014] Fourthly, another embodiment of this application provides a storage medium storing a computer program, which, when executed by a processor, performs the steps of any of the methods described in the first aspect above.

[0015] The beneficial effects of this application are as follows: By adopting the game resource management method provided in this application, the first user who owns the target resource in the game can obtain a voting request for the preset game requirements. Users can vote on the voting request according to their expectations for the preset game requirements, and return the voting results to the blockchain node. The final decision on the preset game requirements is determined based on the voting results. That is, the first user who owns the target resource can directly participate in the game's decision-making. Each first user who owns the target resource can make decisions on the subsequent direction of the game, thereby achieving the effect of users and game developers jointly controlling the game's direction and improving the game users' participation and decision-making ability. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a method for managing game resources according to an embodiment of this application;

[0018] Figure 2 A flowchart illustrating a method for managing game resources according to another embodiment of this application;

[0019] Figure 3 A flowchart illustrating a method for managing game resources according to another embodiment of this application;

[0020] Figure 4 A schematic diagram of the structure of a game resource management device provided in an embodiment of this application;

[0021] Figure 5 A schematic diagram of the structure of a game resource management device provided in another embodiment of this application;

[0022] Figure 6 A schematic diagram of the structure of a game resource management device provided in an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of this application, but not all embodiments.

[0024] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0025] Furthermore, the flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed in order or performed simultaneously. Moreover, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0026] The following explanation, using several specific application examples, illustrates a method for managing game resources provided in this application. Figure 1 This is a flowchart illustrating a method for managing game resources according to an embodiment of this application, applied to a blockchain node, such as... Figure 1 As shown, the method includes:

[0027] S101: Initiate a voting request for the preset game requirements to the first users who possess the target resources.

[0028] The target resource is obtained by the first user after pledging the preset resources.

[0029] In the embodiments of this application, the target resource may be, for example, a decision resource. This application blockchainizes all decision resources, virtual items, and virtual currencies in the game. Users can determine the decision resources obtained by pledging virtual items or virtual currencies using a preset pledging model based on the amount of virtual items or virtual currencies pledged. The preset pledging model is pre-configured, and the pledging strategies of the pledging model may be different for different virtual items or virtual currencies.

[0030] During the process of initiating a voting request, for example, multiple preset game requirements may have been set by the game operations personnel. These preset game requirements may include, for example, the subsequent game direction, multiple game instances, or multiple game activities. These multiple preset game requirements are sent to the first users who possess the target resources in a single-choice or multiple-choice format, so that the first users can choose from the multiple preset game requirements according to the preset selection method. The number of preset game requirements that can be selected can be flexibly adjusted according to the user's needs. For example, it can be set to allow only single selection, or it can allow multiple selection. Multiple selection may mean that only a preset number of preset game requirements can be selected, or it can be selected according to the user's actual ideas, without limiting the number of multiple selections. It should be understood that the above embodiments are only illustrative examples, and the specific implementation can be flexibly adjusted according to the user's needs, and is not limited to the embodiments given above.

[0031] Alternatively, in some other possible embodiments, during the voting process, an additional "Other" option can be added to the voting request, and an input box can be added after the "Other" option. If the first user selects "Other", it means that the first user is not satisfied with any of the preset game requirements options. Then, after selecting the "Other" option, the user can directly express their desired content by entering the desired content in the input box.

[0032] Alternatively, in other possible embodiments, for some first users who have a number of target resources greater than a preset threshold, or for first users whose number of target resources ranks higher than a preset ranking among all first users, they can actively write proposals and send them to the blockchain for other first users to vote on. After obtaining the voting results, the voting results are provided to the game operation and maintenance personnel for their reference.

[0033] S102: Receive the voting results of each first user regarding the preset game requirements.

[0034] Each user selects from a voting request provided by the operations and maintenance personnel based on their desired preset game requirements. The selection result is then fed back to the blockchain node as the voting result. The game operations and maintenance personnel decide on the preset game requirements based on the voting results returned by each user. For example, the preset game requirement ranked first in the voting results can be used as the final game decision, or the top three preset game requirements can be obtained and used as new voting requests. The decision on the preset game requirements is then determined based on the results of these new voting requests. It should be understood that the above embodiments are merely illustrative, and the specific decision-making method for dating game requirements can be flexibly adjusted according to user needs and is not limited to the methods given in the above embodiments.

[0035] In other words, the game operators' decisions on the preset game requirements depend on the voting results returned by each first user. This means that each first user can participate in the decision-making process for the preset game requirements, thereby enabling the first users to jointly control the game and determine its direction with the game operators.

[0036] In the embodiments of this application, the more preset resources a first user pledges, the more target resources they obtain. The more target resources a first user possesses, the greater the weight their voting results carry in the decision-making process. For example, if the total share of all target resources in the game is currently 100, and the first user A possesses 60 of the target resources, then if all first users participate in the voting and their votes are successful, the voting result of the first user A alone accounts for 60% of the voting results for the preset game requirements. That is, even if the voting results of all other first users are different from those of the first user A, the sum of the shares of the voting results of all other first users is only 40%. In other words, the voting result of the first user A can directly determine the direction of the preset game requirements; that is, the first user can gain the right to speak in game decision-making by acquiring more preset resources.

[0037] Using the game resource management method provided in this application, each first user who owns the target resource can, after receiving a voting request for preset game requirements, provide feedback on the voting results. This allows game operators to make decisions on preset game requirements based on the voting results, ultimately giving the decision-making power over preset game requirements to each first user. In other words, the first user can jointly control the game's direction with the operators, thereby increasing the first user's participation in the game. Each user can obtain target resources by staking preset resources, becoming a first user and participating in the decision-making on preset game requirements. The more target resources a first user stakes, the greater their weight in the decision-making on preset game requirements, meaning their decision-making results are more likely to be referenced when making decisions on preset game requirements.

[0038] In other possible embodiments, in addition to participating in game decision-making, the first user can also allocate a portion of the game's revenue within a preset time period, for example, according to a preset time period. The allocation rule can be, for example, based on the percentage of the target resources owned by each first user relative to the total number of target resources, to determine the allocation ratio of each first user, and then allocate the total revenue to be allocated based on the total amount of revenue to be allocated and the allocation ratio of each first user, thereby further improving the first user's participation in the game.

[0039] Optionally, based on the above embodiments, this application embodiment may also provide a method for managing game resources, and the implementation process of the above method will be illustrated below with reference to the accompanying drawings. Figure 2 A flowchart illustrating a game resource management method according to another embodiment of this application is shown below. Figure 2 As shown, before S101, the method may further include:

[0040] S111: In response to the first user's staking operation for a first number of preset resources, determine the target resources corresponding to the staking operation according to the staking rules pre-configured in the management contract.

[0041] In the embodiments of this application, the preset resources and target resources are pre-configured by the game operation and maintenance personnel. For example, the specific configuration method may be: in response to the configuration operation of the second user on the management contract, at least one resource type is created in the management contract, and the at least one resource type includes: preset resources and target resources.

[0042] The second user can be, for example, a user corresponding to a game operations and maintenance personnel or a user corresponding to a game publisher. The configuration method can be, for example, that the second user creates preset resources and target resources within the management contract and sets the operator of the management contract to the management contract address, so that the second user can manage the management contract.

[0043] In the embodiments of this application, the preset resources include: a first preset resource, a second preset resource, and / or a third preset resource; wherein, the first preset resource may be, for example, a virtual currency resource ERC20, the second preset resource may be, for example, a private virtual resource ERC721, and the third preset resource may be, for example, a consumable virtual resource ERC1155.

[0044] ERC-20 is a standard token issuance protocol based on the Ethereum network. In the embodiments of this application, each ERC20 virtual currency serves as a virtual decision-making currency. Users who possess virtual decision-making currency have decision-making power over the subsequent development of the game, and the more virtual decision-making currency they possess, the greater the likelihood that their decisions will be referenced when making decisions about the subsequent development of the game. ERC-721 is a standard on the Ethereum blockchain, widely used in digital collectibles. Each ERC-721 virtual currency is unique. Therefore, in this application, ERC-721 virtual currency is generally used as a unique virtual character, virtual equipment, or virtual item corresponding to each user. In this application, ERC-1155 virtual currency is generally used as a non-unique virtual item for the user, such as virtual food, virtual replenishment items, virtual water, and other virtual consumable items.

[0045] The pledging rules for different preset resources may not be the same. In the specific pledging process, the pledging rules corresponding to the current pledging operation are determined according to the pledging rules of each type of preset resource pre-configured in the management contract. Based on the pledging rules, the first preset quantity of preset resources is pledged to obtain the target resource.

[0046] For example, ERC20 virtual currency can be directly pledged to obtain virtual decision currency. ERC-721 and ERC-1155 virtual currencies can first be pledged according to preset pledging rules to obtain ERC20 virtual currency. Then, by pledging the obtained ERC20 virtual currency, virtual decision currency can be further obtained. For example, after pledging 3 ERC-721 virtual currencies and 15 ERC-1155 virtual currencies, one ERC20 virtual currency can be obtained. It should be understood that the above embodiments are only illustrative examples, and the specific pledging rules can be flexibly adjusted according to user needs and are not limited to those given in the above embodiments.

[0047] S112: Convert the first number of preset resources in the first user's account into the target resources.

[0048] That is, in the embodiments of this application, the first user obtains the target resource by pledging preset resources, thereby gaining decision-making power over the game.

[0049] In some possible embodiments, the specific configuration operation for the resource to be configured may be, for example, in response to a configuration operation initiated by a first user, determining the type and a second quantity of the resource to be configured; the type of the resource to be configured is any of at least one resource type; and configuring the second quantity of the resource to be configured in the first user's account according to the type of the resource to be configured.

[0050] For example, the configuration operation for each resource to be configured may be as follows: upon receiving a supplementary operation from a first user for a first preset resource, determine the second quantity of the first preset resource corresponding to the supplementary operation, and after verifying the successful supplementary operation, configure the second quantity of the first preset resource in the first user's account; or, upon receiving a replacement operation from a first user for a second preset resource, such as virtual character A, determine whether the first user's account has a first preset resource for replacing virtual character A. If the first user's account has a first preset resource that can replace virtual character A, deduct the first preset resource for replacing virtual character A from the first user's account, and configure virtual character A in the first user's account. It should be understood that the above embodiments are only illustrative examples, and can be flexibly adjusted according to user needs, and are not limited to the embodiments given above.

[0051] Optionally, based on the above embodiments, this application embodiment may also provide a method for managing game resources, and the implementation process of the above method will be illustrated below with reference to the accompanying drawings. Figure 3 A flowchart illustrating a game resource management method according to another embodiment of this application is shown below. Figure 3 As shown, the method may further include:

[0052] S121: In response to the first user's unstaking operation for the third number of target resources, determine the first preset resource corresponding to the unstaking operation according to the staking rules pre-configured in the management contract.

[0053] In the embodiments of this application, unstaking means reducing the user's target resources on the blockchain, and at the same time obtaining the first preset resources corresponding to the reduced third amount of target resources, thereby realizing the conversion from target resources to the first preset resources.

[0054] S122: Convert the third quantity of target resources in the first user's account into the first preset resources.

[0055] The first preset resource can be used as the target resource for pledging, or it can be used to exchange for the second or third preset resource; the specific use of the first preset resource can be flexibly adjusted according to the user's needs, and is not limited to the above embodiments.

[0056] In the embodiments of this application, each first user can also exchange preset resources if both parties agree to the exchange. In response to the first user's exchange operation for the preset resources, the third user corresponding to the exchange operation is determined, and the preset resources in the first user's account are transferred to the third user's account.

[0057] In one embodiment of this application, by designing a unified contract technical specification, all virtual items in the game are blockchainized. Users can become game decision-makers by staking, which can not only drive the game's direction but also obtain game rewards. After configuring the management contract, the management contract allows users to withdraw currency from the game to the blockchain. After the user initiates a withdrawal request, the game will give the user an administrator signature. Subsequently, the user can use the administrator signature to call the deposit function or withdraw currency (withdrawal) function on the blockchain.

[0058] Each type of cryptocurrency maintains its rules according to the corresponding contract, and the staking rules are also maintained through pre-set staking contracts, for example:

[0059] The contract corresponding to ERC20 virtual currency is an in-game virtual currency model, and its contract design is as follows:

[0060]

[0061] The contract design for ERC721 cryptocurrencies is as follows:

[0062]

[0063]

[0064] The contract design for ERC1155 cryptocurrency is as follows:

[0065]

[0066] The share pledge agreement is designed as follows:

[0067]

[0068]

[0069] Each pledge has its own corresponding pledge sequence number, which can uniquely identify a pledge.

[0070] In the embodiments of this application, the game also abstracts four types of functional interfaces, corresponding to various management contracts. These include, for example, a payment function interface, which allows all transactions between virtual items in the game to be realized through virtual currency transactions and records game transaction volume in real time; a deposit / withdrawal function interface, which mainly supports the function of users depositing existing virtual currency from the game to the blockchain and withdrawing it from the blockchain to the game. Operating the centralized database will modify the item status and the owner's game account. If the virtual currency is withdrawn to the blockchain, its use is suspended; a signature function interface: all user withdrawals / deposits, exchanges within the same game, and exchanges outside the same game require the administrator's signature. The administrator will determine in advance whether the user's operation can be executed; and a staking function interface: users sign contract function data and then initiate contract calls to complete the staking and become shareholders.

[0071] By adopting the game resource management method provided in this application, all virtual items in the game can be blockchainized, allowing users to obtain target resources by staking virtual items or virtual currencies in the game. This enables users who possess the target resources to participate in the game's expansion and obtain a portion of the game's revenue, thereby increasing user participation in the game.

[0072] The following description, in conjunction with the accompanying drawings, explains the game resource management device provided in this application, which can perform the above-described functions. Figures 1-4 The specific implementation and beneficial effects of the management method for any game resource are as described above, and will not be repeated below.

[0073] Figure 5 A schematic diagram of the structure of a game resource management device provided in an embodiment of this application is shown below. Figure 5 As shown, the device includes: a transmitting module 201 and a receiving module 202, wherein:

[0074] The sending module 201 is used to initiate a voting request for preset game requirements to each first user who has the target resource; wherein the target resource is obtained by the first user after pledging the first preset resource;

[0075] The receiving module 202 is used to receive the voting results of each third user regarding the preset game requirements.

[0076] Optionally, based on the above embodiments, this application embodiment may also provide a game resource management device, as described below with reference to the accompanying drawings. Figure 5 The implementation process of the given device is illustrated with examples. Figure 6 A schematic diagram of the structure of a game resource management device provided in another embodiment of this application, as shown below. Figure 6 As shown, the device further includes: a determining module 203 and a conversion module 204, wherein:

[0077] The determination module 203 is used to respond to the first user's staking operation for a first number of preset resources and determine the target resources corresponding to the staking operation according to the staking rules pre-configured in the management contract.

[0078] The conversion module 204 is used to convert a first number of preset resources in the first user's account into target resources.

[0079] like Figure 6 As shown, the device also includes a creation module 205, which, in response to a second user's configuration operation on the management contract, creates at least one resource type in the management contract, the at least one resource type including: a preset resource and a target resource.

[0080] Optionally, the determining module 203 is specifically used to respond to the configuration operation initiated by the first user, determine the type and second quantity of the resource to be configured; the type of the resource to be configured is any type of at least one resource type; and configure the second quantity of the resource to be configured in the first user's account according to the type of the resource to be configured.

[0081] Optionally, the determining module 203 is specifically used to respond to the first user's unpledge operation for a third number of target resources, and determine the first preset resource corresponding to the unpledge operation according to the pledge rules pre-configured in the management contract;

[0082] The conversion module 204 is specifically used to convert the third quantity of target resources in the first user's account into the first preset resources.

[0083] Optionally, the determining module 203 is specifically used to respond to the first user's exchange operation on preset resources, determine the third user corresponding to the exchange operation, and transfer the preset resources in the first user's account to the third user's account.

[0084] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.

[0085] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0086] Figure 6 This is a schematic diagram of the structure of a game resource management device provided in an embodiment of this application. The game resource management device can be integrated into a terminal device or a chip of a terminal device.

[0087] like Figure 6 As shown, the management device for the game resources includes: processor 501, bus 502 and storage medium 503.

[0088] Processor 501 is used to store programs, and processor 501 calls the programs stored in storage medium 503 to execute the above-mentioned programs. Figures 1-3 The corresponding method implementation is similar in both implementation and technical effect, and will not be described in detail here.

[0089] Optionally, this application also provides a program product, such as a storage medium storing a computer program, including a program that executes the embodiments corresponding to the above-described methods when run by a processor.

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

[0091] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0093] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for managing game resources, characterized in that, The method, applied to blockchain nodes, includes: A voting request is initiated to each first user who possesses the target resources regarding the preset game requirements; wherein, the target resources are obtained by the first user after staking the preset resources. Receive the voting results from each of the first users regarding the preset game requirements; The preset game requirements include: subsequent game progression, game instances, or game activities; the preset resources include: a first preset resource, a second preset resource, and / or a third preset resource; wherein the first preset resource is virtual currency, the second preset resource is private virtual resource, and the third preset resource is consumable virtual resource.

2. The method as described in claim 1, characterized in that, Before initiating a voting request for preset game requirements to each of the first users who possess the target resources, the method further includes: In response to a first user’s staking operation for a first number of the preset resources, the target resources corresponding to the staking operation are determined according to the staking rules pre-configured in the management contract. Convert the first number of preset resources in the first user's account into the target resources.

3. The method as described in claim 1, characterized in that, The method further includes: In response to a configuration operation by a second user on a management contract, at least one resource type is created in the management contract, the at least one resource type including: the preset resource and the target resource.

4. The method as described in claim 3, characterized in that, The method further includes: In response to the configuration operation initiated by the first user, the type and second quantity of the resource to be configured are determined; the type of the resource to be configured is any of the at least one resource type. Based on the type of the resource to be configured, the second number of resources to be configured are configured in the first user's account.

5. The method as described in claim 1, characterized in that, The method further includes: In response to the first user's unstaking operation for a third number of target resources, the first preset resource corresponding to the unstaking operation is determined according to the staking rules pre-configured in the management contract. Convert the third quantity of target resources in the first user's account into the first preset resources.

6. The method as described in claim 1, characterized in that, The method further includes: In response to a first user's exchange operation for preset resources, a third user corresponding to the exchange operation is identified, and the preset resources in the first user's account are transferred to the third user's account.

7. A device for managing game resources, characterized in that, The device includes: a transmitting module and a receiving module, wherein: The sending module is used to initiate voting requests for preset game requirements to each first user who possesses the target resource; wherein, the target resource is obtained by the first user after pledging the first preset resource; The receiving module is used to receive the voting results of each third user regarding the preset game requirements; The preset game requirements include: subsequent game progression, game instances, or game activities; the preset resources include: a first preset resource, a second preset resource, and / or a third preset resource; wherein the first preset resource is virtual currency, the second preset resource is private virtual resource, and the third preset resource is consumable virtual resource.

8. A device for managing game resources, characterized in that, The device includes a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executed by the processor. When the game resource management device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the method described in any one of claims 1-6.

9. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, performs the method described in any one of claims 1-6.

Images