Information processing program, information processing method and information processing device

Abstract

To provide an information processing program, an information processing method and an information processing device capable of distributing merchandise or a service in a plurality of spaces.SOLUTION: An information processing program registers a settlement method to be used in a second space in the settlement method in a first space of a user, provides the user with the merchandise or the service in the second space in the case of executing settlement by the registered settlement method when the merchandise or the service is purchased in the second space, and makes a computer execute processing for providing the merchandise or the service in the first space.SELECTED DRAWING: Figure 10

Description

[Technical field]

[0001] The present invention relates to an information processing program, an information processing method, and an information processing device for sharing a product or service in a plurality of spaces. [Background technology]

[0002] With the development of image processing technology, it is now possible to create a realistic virtual space. Activities in virtual space are becoming as important as activities in real space. In order to enable seamless activities in multiple spaces, a system that allows items to be shared across multiple spaces has been proposed (Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2015-226837 A Summary of the Invention [Problem to be solved by the invention]

[0004] In the metaverse space, goods and services are purchased and the associated financial settlements are also made. However, the system of Patent Document 1 is limited to linking real prizes with virtual prizes, and does not take into consideration the distribution of goods and services in multiple spaces.

[0005] The present invention has been made in view of the above circumstances, and an object of the present invention is to provide an information processing program, an information processing method, and an information processing device that enable distribution of products or services in a plurality of spaces. [Means for solving the problem]

[0006] An information processing program according to one embodiment of the present application registers a payment method to be used in a second space from among the payment methods used by a user in a first space, and when payment is made using the registered payment method when purchasing a product or service in the second space, provides the product or service in the second space to the user and causes a computer to execute a process to provide the product or service in the first space. Effect of the Invention

[0007] In one aspect of the present application, it is possible to distribute products or services in multiple spaces. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is an explanatory diagram illustrating an example of the configuration of an information processing system. [Diagram 2] FIG. 2 is a block diagram showing an example of a hardware configuration of a server. [Diagram 3] FIG. 2 is a block diagram showing an example of a hardware configuration of a user terminal. [Figure 4] FIG. 2 is a block diagram showing an example of a hardware configuration of a store terminal. [Diagram 5] FIG. 11 is an explanatory diagram showing an example of a user DB. [Figure 6] FIG. 11 is an explanatory diagram showing an example of a linked attribute DB; [Figure 7] FIG. 2 is an explanatory diagram showing an example of a store DB. [Figure 8] FIG. 2 is an explanatory diagram showing an example of a product DB; [Figure 9] FIG. 13 is an explanatory diagram showing an example of a purchase DB. [Figure 10] 13 is a flowchart showing an example of a payment process procedure. [Figure 11] 13 is a flowchart illustrating an example of a procedure for a synchronization process. [Figure 12] 13 is a flowchart illustrating an example of a procedure for a providing process. [Figure 13] FIG. 13 is an explanatory diagram showing an example of a transaction management DB. [Figure 14]13 is a flowchart showing an example of a procedure for a transaction registration process. [Figure 15] 13 is a flowchart showing an example of a procedure for a transaction completion process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] (Embodiment 1) An embodiment will be described below with reference to the drawings. FIG. 1 is an explanatory diagram showing an example of the configuration of an information processing system. The information processing system 100 is a system that coordinates the distribution of goods and services between different spaces. The information processing system 100 includes a server 1, a user terminal 2, and a store terminal 3. In FIG. 1, only one user terminal 2 and one store terminal 3 are shown, but there may be two or more of each. The server 1, the user terminal 2, and the store terminal 3 are connected to each other via a network N so that they can communicate with each other. The information processing system 100 communicates with a payment network 4 and makes payments for goods and services.

[0010] The server 1 controls the entire information processing system 100. The server 1 is configured with a server computer, a workstation, a PC (Personal Computer), etc. The server 1 may also be configured with a multicomputer consisting of multiple computers, a virtual machine virtually constructed by software, or a quantum computer. Furthermore, the functions of the server 1 may be realized by a cloud service. The user terminal 2 and the store terminal 3 are configured with a tablet computer, a smartphone, a notebook computer, etc. The store terminal 3 may be configured with a POS (Point of Sale) register.

[0011] 2 is a block diagram showing an example of the hardware configuration of the server 1. The server 1 includes a control unit 11, a main memory unit 12, an auxiliary memory unit 13, a communication unit 14, and a reading unit 15. The control unit 11, the main memory unit 12, the auxiliary memory unit 13, the communication unit 14, and the reading unit 15 are connected by a bus B.

[0012] The control unit 11 has one or more arithmetic processing devices such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), a GPU (Graphics Processing Unit), etc. The control unit 11 reads out and executes a control program 1P (program, program product) stored in the auxiliary storage unit 13, thereby performing various information processing, control processing, etc. related to the server 1, and realizing various functional units.

[0013] The main memory unit 12 is a static random access memory (SRAM), a dynamic random access memory (DRAM), a flash memory, etc. The main memory unit 12 mainly temporarily stores data necessary for the control unit 11 to execute arithmetic processing.

[0014] The auxiliary storage unit 13 is a hard disk or a solid state drive (SSD) or the like, and stores a control program 1P and various DBs (databases) necessary for the control unit 11 to execute processing. The auxiliary storage unit 13 stores a user DB 131, a linked attribute DB 132, a store DB 133, a product DB 134, a purchase DB 135, and a transaction management DB 136. The auxiliary storage unit 13 may be an external storage device that is separate from and externally connected to the server 1. The various DBs and the like stored in the auxiliary storage unit 13 may be stored in a database server or cloud storage different from the server 1. Note that the transaction management DB 136 is not necessary in this embodiment.

[0015] The communication unit 14 communicates with the user terminal 2 and the store terminal 3 via the network N. In addition, the control unit 11 may use the communication unit 14 to download the control program 1P from another computer via the network N or the like, and store it in the auxiliary storage unit 13.

[0016] The reading unit 15 reads the portable storage medium 1a including a CD (Compact Disc)-ROM and a DVD (Digital Versatile Disc)-ROM. The control unit 11 may read the control program 1P from the portable storage medium 1a via the reading unit 15 and store it in the auxiliary storage unit 13. The control unit 11 may also read the control program 1P from the semiconductor memory 1b.

[0017] 3 is a block diagram showing an example of the hardware configuration of a user terminal 2. The user terminal 2 includes a control unit 21, a main memory unit 22, an auxiliary memory unit 23, a communication unit 24, a display panel 25, and an operation unit 26. Each component is connected by a bus B.

[0018] The control unit 21 has one or more arithmetic processing devices such as a CPU, an MPU, a GPU, etc. The control unit 21 provides various functions by reading and executing a control program 2P (program, program product) stored in the auxiliary storage unit 23.

[0019] The main memory unit 22 is an SRAM, a DRAM, a flash memory, etc. The main memory unit 22 mainly temporarily stores data necessary for the control unit 21 to execute arithmetic processing.

[0020] The auxiliary storage unit 23 is a hard disk or an SSD, etc., and stores various data necessary for the control unit 21 to execute processing. The auxiliary storage unit 23 may be an external storage device that is separate from the user terminal 2 and externally connected. The various DBs, etc. stored in the auxiliary storage unit 23 may be stored in a database server or cloud storage.

[0021] The communication unit 24 communicates with the server 1 via the network N. In addition, the control unit 21 may use the communication unit 24 to download the control program 2P from another computer via the network N or the like, and store it in the auxiliary storage unit 23.

[0022] The display panel 25 can be configured with a liquid crystal panel or an organic EL (Electro Luminescence) display, etc. The operation unit 26 can be configured with, for example, a touch panel incorporated in the display panel 25, and can perform predetermined operations performed by the user on the display panel 25. The operation unit 26 can also perform operations on a software keyboard displayed on the display panel 25. The operation unit 26 may also be a hardware keyboard, a mouse, etc.

[0023] 4 is a block diagram showing an example of the hardware configuration of the store terminal. The store terminal 3 includes a control unit 31, a main memory unit 32, an auxiliary memory unit 33, a communication unit 34, a display panel 35, an operation unit 36, and an input / output unit 37. Each component is connected by a bus B. The control unit 31, the main memory unit 32, the auxiliary memory unit 33, the communication unit 34, the display panel 35, and the operation unit 36 ​​are similar to the control unit 21, the main memory unit 22, the auxiliary memory unit 23, the communication unit 24, the display panel 25, and the operation unit 26 of the user terminal 2, so their explanation will be omitted.

[0024] The input / output unit 37 exchanges data with an external device via a wired or wireless connection. For example, the input / output unit 37 communicates with the external device according to the USB (Universal Serial Bus) standard or the Bluetooth (registered trademark) standard. The input / output unit 37 is connected to a code reader CR. The code reader CR reads one-dimensional codes or two-dimensional codes. The code reader CR also reads information stored in a non-contact IC card.

[0025] Next, the database will be described. FIG. 5 is an explanatory diagram showing an example of a user DB. The user DB 131 stores information of a user in the real space. The user DB 131 includes a user ID column, a payment method column, a name column, an address column, a date of birth column, a gender column, a height column, and a weight column. The user ID column stores a user ID that can uniquely identify a user. The payment method column stores a payment method designated by the user. The payment method column may store information for making a payment. For example, if a user selects a credit card as a payment method, the payment method column may store a card number. The payment methods that a user can select as a payment method are those that can be used in the real space, and at least one of them can also be used in the virtual space. The name column stores the user's name. The address column stores the user's address. The date of birth column stores the user's date of birth. The gender column stores the user's gender. The height column stores the user's height. The weight column stores the user's weight.

[0026] FIG. 6 is an explanatory diagram showing an example of the linked attribute DB. The linked attribute DB 132 stores attributes of a user in a virtual space. The linked attribute DB 132 includes a user ID column, a type column, a name column, a other ID column, a name column, an address column, a date of birth column, a gender column, a height column, and a weight column. The user ID column stores a user ID. The type column stores a type of a virtual space (metaverse, game, etc.). The name column stores a name of the virtual space. The other ID column stores an ID of a user in the virtual space. If the user ID of the information processing system 100 is available in the virtual space, the other ID column does not need to store a value. The name column stores the name of a user in the virtual space. Not limited to a name, a nickname, a handle name, etc. in the virtual space may be stored in the name column. The address column stores an address of a user in the virtual space. The date of birth column stores a date of birth of a user in the virtual space. The date of birth column may store only the date without the year of birth, or only the year of birth without the date. The date of birth may be unknown. The gender column stores the gender in the virtual space. The height column stores the height of the user in the virtual space. The weight column stores the weight of the user in the virtual space. Note that if there are restrictions or conditions on the user attributes that can be set due to rules in the virtual space, the attributes stored in linked attribute DB132 will be values ​​that satisfy the restrictions or conditions.

[0027] FIG. 7 is an explanatory diagram showing an example of a store DB. The store DB 133 stores information about stores in real space and virtual space. The store DB 133 includes a store ID column, a location space column, a name column, an address column, and an other ID column. The store ID column stores a store ID that identifies a store. The location space column stores the space in which the store is located. The name column stores the store name in the space in which the store is located. The address column stores the address of the store in the space in which the store is located. If a store has been assigned an ID other than the store ID assigned by the information processing system 100 in the space in which the store is located, the other ID column stores that ID.

[0028] FIG. 8 is an explanatory diagram showing an example of a product DB. The product DB 134 stores information about products. The product DB 134 includes a product ID column, a type column, a store ID column, a valid range column, and a price column. The product ID column stores a product ID that identifies the product. The type column stores the type of product, good, or service. The store ID column stores the store ID of a store that handles the product. The valid range column stores information about the range in which the product is valid, i.e., one or more spaces in which it is valid. The price column stores the price of the product.

[0029] FIG. 9 is an explanatory diagram showing an example of a purchase DB. The purchase DB 135 stores products or services purchased by a user. The purchase DB 135 includes a product ID column, a valid range column, an owner ID column, and a linkage status column. The product ID column stores the product ID of the purchased product. The valid range column stores the valid range of the purchased product. The valid range here may be a subset of the valid range stored in the product DB 134. For example, even if the product is valid in three spaces, namely, the real space, the virtual space A, and the virtual space B, if the user specifies the valid range as the real space and the virtual space A when purchasing, the valid range column stores the real space and the virtual space A, and does not include the virtual space B as the valid range. When purchasing, the user may be prompted to input a reason for not including the virtual space B as the valid range, and the acquired reason may be stored in the purchase DB 135. The owner ID column stores the user ID of the user who owns the product. The linkage status column stores the situation of the product in a space other than the one in which it was purchased. The purchase DB 135 shown in Fig. 9 has one record for each product, but it may also be possible to have a record for each valid range of the product, and manage information on users who own the product for each valid range. By using the purchase DB 135 to aggregate the products owned for each valid range for each owner ID, it is possible to understand the tendency of users to own products in what kind of space. The tendency for each user and the reason why the space was not included as a valid range when purchasing the product can be used as consideration material when considering the promotion content of the product in each space.

[0030] Next, the information processing performed by the information processing system 100 will be described. FIG. 10 is a flow chart showing an example of the procedure of the payment process. FIG. 10 shows the payment procedure in the virtual space. In the store in the virtual space (first space), the user specifies the product and the purchase quantity by putting the list of the product or service to be purchased in the cart. The user instructs the payment. The control unit 21 of the user terminal 2 transmits the payment instruction to the server 1 (step S1). The control unit 11 of the server 1 receives the payment instruction (step S2). The control unit 11 calculates the payment amount from the price and the purchase quantity of the product or service read from the product DB 134 (step S3). The control unit 11 acquires the payment method selected by the user from the user DB 131 (step S4). The control unit 11 transmits confirmation information including the payment amount and the payment method to the user terminal 2 (step S5). The control unit 21 of the user terminal 2 receives the confirmation information (step S6). The control unit 21 displays it in the virtual space (step S7). The user refers to the displayed confirmation information, decides whether or not to make a payment, and performs an action accordingly. For example, the user takes out a credit card in the virtual space and has it read by a card reader or the like in the store. The credit card is issued in the virtual space by a credit card company (issuer) in the real space. The control unit 21 judges whether the user's action is to execute a payment (step S8). If the control unit 21 judges that the payment is to be executed (YES in step S8), it transmits an execution instruction to the server 1 (step S9). The control unit 11 of the server 1 receives the execution instruction (step S10). The control unit 11 performs the payment (step S11). The control unit 11 transmits a payment request to the payment network 4. The payment network 4 attempts to execute the payment according to the payment request, and returns the result to the server 1. The control unit 11 judges whether or not the payment has been successful (step S12). If the control unit 11 judges that the payment has been successful (YES in step S12), it stores the purchase information in the purchase DB 135 (step S13). The control unit 11 performs a synchronization process (step S14). Although details will be described later, the synchronization process is a process in which the product or service purchased by the user is treated as having been purchased in a space other than the space in which the product or service was purchased (second space). The control unit 11 transmits update information to the user terminal 2 (step S15).The control unit 21 of the user terminal 2 receives the update information (step S16). Based on the update information, the purchased product or service is provided to the user in the virtual space. The control unit 21 ends the process. If the control unit 11 determines that the payment is not successful, i.e., has failed (NO in step S12), it sends failure information to the user terminal 2 (step S17). The control unit 21 of the user terminal 2 receives the failure information and displays accordingly (step S18). The control unit 21 ends the process. If the control unit 21 determines that the payment is not to be executed (NO in step S8), it ends the process.

[0031] When payment processing is performed in real space, it is as follows. When making a payment at a physical store, the user terminal 2 is replaced by the store terminal 3 in the flowchart of FIG. 10. A store clerk reads the barcode attached to the product with a code reader connected to the store terminal 3. The store terminal 3 thereby obtains the product ID. The store terminal 3 calculates the purchase price and presents the total amount to the user. The user makes the payment by presenting a credit card or a payment code. Upon payment, the store terminal 3 obtains the user ID. Steps S12 and onward in FIG. 10 are executed. The same applies when a service is provided at a physical store.

[0032] The flow when purchasing a product at an online shop in the real world is similar to that shown in Figure 10. Products are delivered from a physical store or warehouse via a delivery company.

[0033] FIG. 11 is a flowchart showing an example of the procedure of the synchronization process. The synchronization process is a process for treating a product or service that is valid in a plurality of spaces as having been purchased in a space other than the space in which it was purchased when the user purchases the product or service by specifying that the product or service is valid in a plurality of spaces. The control unit 11 of the server 1 selects the product ID of the product to be processed among the products purchased by the user (step S31). The control unit 11 acquires the effective range of the product (step S32). If the user specifies the effective range, the effective range acquired by the control unit 11 is the range specified by the user. If the user does not specify the effective range, the effective range acquired by the control unit 11 is the range stored in the product DB 134. The control unit 11 determines whether or not there is another space other than the space in which the product or service was purchased in the acquired effective range (step S33). If the control unit 11 determines that there is no other space (NO in step S33), the process proceeds to step S37. If the control unit 11 determines that there is another space (YES in step S33), the control unit 11 selects the space to be processed (step S34). The control unit 11 performs a providing process (step S35).

[0034] FIG. 12 is a flowchart showing an example of the procedure of the provision process. The control unit 11 judges whether the product being processed is a product (step S51). When the control unit 11 judges that the product being processed is a product (YES in step S51), it judges whether the space in which the product is provided is the real space (step S52). When the control unit 11 judges that the space to be provided is the real space (YES in step S52), it acquires the attributes of the user in the real space (step S53). The acquired attributes are related to the product to be provided. For example, if the product is an apparel product, the attributes are height and weight. The control unit 11 transmits an instruction to arrange for a product that matches the acquired attributes to the store in the real space (step S54). The control unit 11 transmits an instruction to deliver the product from the store to the user to the delivery company (step S55), and ends the process. The store in the real space prepares and packs the product to be sent to the user. The delivery company collects the packaged product at the store and delivers it to the user. When the control unit 11 determines that the space to be provided is not a real space (NO in step S52), it performs customization according to the user's attributes (step S56). The user's attributes are obtained from the linked attribute DB 132 as the attributes of the user in the target virtual space. The control unit 11 sets the ownership rights of the product in the target and virtual space (step S57) and returns the process to the caller. The control unit 11 stores the ownership rights setting in the purchase DB 135, and requests the setting of the ownership rights to the computer or database server that manages the target virtual space as necessary. When the control unit 11 determines that the product to be processed is a service (NO in step S51), it creates a voucher for the service in the target space (step S58). The control unit 11 transmits the voucher to the user terminal 2 (step S59) and returns the process to the caller. When the space to be processed is a real space, the paper voucher may be mailed to the user. The user who receives the voucher can receive the same service in other spaces as in the purchased space.

[0035] Returning to FIG. 11, the control unit 11 determines whether or not there is an unprocessed space (step S36). If the control unit 11 determines that there is an unprocessed space (YES in step S36), the control unit 11 returns the process to step S34 and processes the unprocessed space. If the control unit 11 determines that there is no unprocessed space (NO in step S36), the control unit 11 determines whether or not there is an unprocessed product (step S37). If the control unit 11 determines that there is an unprocessed product (YES in step S37), the control unit 11 returns the process to step S31 and processes the unprocessed product. If the control unit 11 determines that there is no unprocessed product (NO in step S37), the control unit 11 returns the process to the caller.

[0036] In this embodiment, when a user who is active in real space and virtual space purchases a product or service in one space after requesting that it be provided in multiple spaces, the user can receive the same product or service in a specified space other than the purchased space. In addition, the user can purchase a product or service that is valid in multiple spaces without worrying about having different attributes for each space, since the product or service is provided according to the attribute by setting attributes in each of the real space and the virtual space. In the case where a user is active in multiple spaces with different genders, and it is difficult to provide the same or equivalent product or service in the purchased space in other spaces, a similar product or service may be provided after confirming with the user. A provider of a product or service can increase the unit price per customer by increasing the price for providing the product or service in multiple spaces.

[0037] In this embodiment, when a user purchases a product or service, the user specifies the space (validity range) in which the purchase is valid, but this is not limited to the above. The user may add a valid space after paying the appropriate price after the purchase. Products may be delivered not only in the real space but also in the virtual space. For example, if a product purchase in the real space is also valid in the metaverse space, the product may be delivered and delivered to the user in the metaverse space.

[0038] If the purchase of a product or service in the first space is valid in the second space, the product may be provided in the real space after obtaining confirmation from the user. For example, when furniture is purchased in the metaverse space, it is expected that the user may find it difficult to accept the same furniture in the real space due to the size of the residence. Also, if the metaverse space and the real space are presented differently, the service purchased in the metaverse space may not be accepted in the real space.

[0039] Furthermore, if a product equivalent to one purchased in the real world is offered in the metaverse space, and the product is presented differently in the metaverse space than in the real world, the user may decide not to bring the product into the metaverse space because it does not fit in with the world view of the metaverse.

[0040] In view of the above, when the user is asked whether the purchase of a product or service in the first space can be valid in the second space, a specific image of the product or service received in the second space may be presented. This allows the user to make an accurate decision. Note that the specific image of the product or service received in the second space may be presented to the user not only after the payment is completed, but also before the payment.

[0041] In this embodiment, the payment method available in the virtual space is also available in the real space. Therefore, the payment in the virtual space can be completed in the virtual space without returning to the real space, which reduces the operational burden on the user and prevents the user from losing interest.

[0042] (Embodiment 2) The first embodiment is premised on BtoC transactions. This embodiment is a form that also enables CtoC transactions. In this embodiment, an escrow service is provided. When buying and selling between users, the information processing system 100 is involved to ensure the security of the transaction. In the following explanation, the subject is user-to-user transactions of goods. In the following explanation, a user who sells goods is referred to as a seller user (first user), and the user terminal 2 used by the seller user is referred to as a seller user terminal 2. A user who purchases goods is referred to as a buyer user (second user), and the user terminal 2 used by the buyer user is referred to as a buyer user terminal 2.

[0043] FIG. 13 is an explanatory diagram showing an example of a transaction management DB. The transaction management DB 136 includes a seller ID column, a purchaser ID column, a product ID column, a valid range column, a receipt column, a payment column, and a shipping column. The seller ID column stores the user ID of the user who sold the product. The purchaser ID column stores the user ID of the user who purchased the product. The product ID column stores the product ID of the product that was bought and sold. The valid range column stores the space in which the transaction is valid. The range of the transaction is based on the entire range owned by the seller user. For products that are distributed in large quantities in any space, it may be permitted to allow only a part of the space to be the valid range. For high-value single items or limited-quantity items, it is desirable to allow only the entire range of transactions. The receipt column stores whether the administrator has received the product from the user who is the seller. For example, if the administrator has not received the product from the user, the receipt column stores "not yet". If the administrator has received the product from the user, the receipt column stores the date of receipt. In addition, since the owner of the product can be changed in the virtual space by simply rewriting the database, the administrator may execute the process of receiving the product without requiring user operation. In the metaverse, it is desirable to have the user perform the sending. The deposit column stores whether or not the administrator has received the purchase price from the user who purchased it. For example, if the administrator has not received the purchase price from the user, the deposit column stores "not yet". If the administrator has received the purchase price from the user, the deposit column stores the date of receipt. The shipping column stores whether or not the administrator has shipped the product to the purchaser. For example, if the administrator has not yet shipped the product to the purchasing user, the shipping column stores "not yet". If the administrator has shipped the product to the purchasing user, the shipping column stores the date of shipping.

[0044] FIG. 14 is a flowchart showing an example of a procedure for transaction registration processing. After a sales contract is concluded between users, the seller user inputs sales information including product information, purchaser user information, and sales price to the seller user terminal 2. The control unit 21 of the seller user terminal 2 generates sales information including the product ID, the purchaser user's user ID, the seller user's user ID, and sales price based on the received information, and transmits the sales information to the server 1 (step S71). The control unit 11 of the server 1 receives the sales information (step S72). The control unit 11 generates a confirmation notice requesting the purchaser user to confirm the sales information, and transmits the confirmation notice to the purchaser user terminal 2 (step S73). The control unit 21 of the purchaser user terminal 2 receives the confirmation notice (step S74). The purchaser inputs a response to the notice to the purchaser user terminal 2. The control unit 21 of the purchaser user terminal 2 transmits a response based on the received response to the server 1 (step S75). The control unit 11 of the server 1 receives the response (step S76). The control unit 11 judges whether the response is an acceptance of the sale and purchase (step S77). If the control unit 11 judges that the response is an acceptance of the sale and purchase (YES in step S77), it stores the sale and purchase information in the transaction management DB 136 (step S78). The control unit 11 sends a deposit request to the purchaser user terminal 2 (step S79). The control unit 21 of the purchaser user terminal 2 receives and displays the deposit request information (step S80). The control unit 11 sends a product delivery request to the seller user terminal 2 (step S81). The control unit 21 of the seller user terminal 2 receives and displays the delivery request (step S82). The transaction registration process ends. If the control unit 11 judges that the response is not an acceptance of the sale and purchase (NO in step S77), it sends a notification to the seller user terminal 2 that the transaction has not been completed (step S83). The control unit 21 of the seller user terminal 2 receives and displays the notification (step S84). The transaction registration process ends.

[0045] In Fig. 14, the process starts from the seller's user terminal 2, but the process may also start from the buyer's user terminal 2. In this case, it is the seller's user terminal 2 that receives the confirmation notice and sends a response, and the destination of a notice when the transaction is not concluded is the buyer's user terminal 2. Alternatively, both the seller and the buyer may send trading information from their respective user terminals 2, and if the two pieces of information sent match, steps S78 to S81 in Fig. 14 may be executed.

[0046] The seller user delivers the product based on the delivery request. If the effective range of the product being sold includes real space, the seller user delivers the product to a location specified by the administrator. To expedite delivery, the server 1 may request a delivery company to collect the product.

[0047] The purchaser user pays for the product based on the payment request. The purchaser user deposits the purchase price into a financial account or the like designated by the administrator.

[0048] When a sale between users takes place in real space, the transaction registration process is as follows. The purchaser user obtains a product ID from the product he or she has received. For example, the product may have an RFID tag attached, and the purchaser user reads the tag with a smartphone functioning as the purchaser user terminal 2 to obtain the product ID. The purchaser user transmits to the server 1 sales and purchase information including the seller user's user ID obtained from the seller user, the product ID, and the purchaser user's own user ID. The control unit 11 of the server 1 stores the sales and purchase information in the transaction management DB 136. The control unit 11 stores the receipt, payment, and shipping as all completed. The control unit 11 executes a transaction completion process.

[0049] FIG. 15 is a flowchart showing an example of a procedure for a transaction completion process. It is assumed that the transaction completion process is started when the product is received or the purchase price is received. The control unit 11 of the server 1 refers to the transaction management DB 136 and judges whether the product has been received (step S91). When the control unit 11 judges that the product has been received (YES in step S91), it refers to the transaction management DB 136 and judges whether the purchase price has been paid (step S92). When the control unit 11 judges that the purchase price has been paid (YES in step S92), it customizes the product for the purchaser user (step S93). For the product in the virtual space, the control unit 11 updates the attributes as information by itself or requests the computer that manages the virtual space to update them. For the product in the real space, customization is performed to the extent possible. A customization fee may be collected from the seller user or the purchaser user. The control unit 11 ships the product to the purchaser user and transfers the purchase price deposited by the purchaser user to the seller user (step S94). The control unit 11 ends the process. If the control unit 11 determines that the product has not been received (NO in step S91) or if the control unit 11 determines that the purchase price has not been paid (NO in step S92), the control unit 11 ends the process. If a predetermined period of time has passed since the buying and selling information was registered in the transaction management DB 136, a reminder notice may be sent. That is, if the control unit 11 determines that the product has not been received (NO in step S91), it may send a reminder notice to the seller user terminal 2. Alternatively, if the control unit 11 determines that the purchase price has not been paid (NO in step S92), it may send a reminder notice to the purchaser user terminal 2. Note that steps S91 and S92 may be performed in reverse order or simultaneously.

[0050] In addition to the effects of the above-described embodiment, the present embodiment provides the following effect: When a user who is active in real space and virtual space sells a product to another user in one space, the product can be handed over to another user in a space other than the space where the product was sold.

[0051] In cases where a seller user is active in multiple spaces and it is difficult to provide the purchaser user in other spaces with an identical or equivalent product to the product in the space in which the seller user and the purchaser user have agreed to purchase and sell, the seller user may provide a similar product after confirming with the purchaser user.

[0052] If the effective range of the product to be traded includes a space in which the purchaser user is not active, and trading cannot be performed in the entire range (space), the purchaser user may be prompted to add spaces in which he or she is active, and trading may be completed once the purchaser user is active in the entire effective range. Also, if the purchaser user refuses to add spaces in which he or she is active, the trading may be invalidated. Instead of invalidating the trading, the administrator may purchase the ownership of the product in the spaces in which the trading is not completed.

[0053] In this embodiment, as in embodiment 1, if a sale or purchase between users made in the first space is to be valid in the second space, the purchaser user may be presented with a concrete image of what it would be like to receive the product or service, and asked to confirm whether or not to make the sale or purchase valid.

[0054] Buying and selling between users may be carried out across spaces. A product or service sold by a seller user in a first space may be provided to a buyer user only in a second space, not in the first space.

[0055] The technical features (constituent elements) described in each embodiment can be combined with each other, and by combining them, new technical features can be formed. The embodiments disclosed herein are illustrative in all respects and should not be considered as limiting. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the scope and meaning equivalent to the claims. Furthermore, the claims are written in a format in which a claim cites two or more other claims (multiple claim format), but this is not limited to this format. A multiple claim that cites at least one other claim (multi-multi claim) may also be written. [Explanation of symbols]

[0056] 100: Information processing systems 1: Server 11: Control section 12: Main memory 13: Auxiliary storage section 131: User DB 132: Linked attribute database 133: Store DB 134: Product DB 135:Purchase DB 136: Transaction management database 14: Communications Department 15: Reading section 1P: Control program 1a: Portable storage medium 1b: Semiconductor memory 2: User terminal, seller user terminal, buyer user terminal, 21: Control section 22: Main memory 23: Auxiliary storage section 24: Communications Department 25: Display panel 26:Operation section 2P: Control program 3: Store terminal 31: Control section 32: Main memory 33:Auxiliary storage section 34: Communications Department 35: Display panel 36:Operation unit 37: Input / output section 4: Payment network B: Bus CR: Code reader N: Network

Claims

1. Registering a payment method to be used in the second space among the payment methods in the first space of the user; When a payment is made by the registered payment method at the time of purchase of a product or service in the second space, the product or service in the second space is provided to the user, and the product or service in the first space is also provided. An information processing program that causes a computer to execute processing.

2. The product or service provided in the first space has an attribute corresponding to the attribute of the user in the first space. The information processing program according to claim 1 .

3. When a product or service is provided from a first user to a second user in the second space, the first user provides the second user with a product or service in the first space that corresponds to the product or service.

3. The information processing program according to claim 1 or 2.

4. The first space and the second space are virtual spaces.

3. The information processing program according to claim 1 or 2.

5. The first space is a real space, and the second space is a metaverse space.

3. The information processing program according to claim 1 or 2.

6. When the first space is a real space and the second space is a metaverse space, a delivery instruction for the product is sent to a delivery company in order to provide the product in the first space to the user. The information processing program according to claim 1 .

7. Registering a payment method to be used in the second space among the payment methods in the first space of the user; When a payment is made by the registered payment method at the time of purchase of a product or service in the second space, the product or service in the second space is provided to the user, and the product or service in the first space is also provided. An information processing method in which processing is performed by a computer.

8. Registering a payment method to be used in the second space among the payment methods in the first space of the user; When a payment is made by the registered payment method at the time of purchase of a product or service in the second space, the product or service in the second space is provided to the user, and the product or service in the first space is also provided. An information processing device having a control unit.

Images