Virtual space provision system, virtual space provision method, and virtual space provision program

Abstract

This invention provides a virtual space provision system, a virtual space provision method, and a virtual space provision program that enable more flexible permission for the provision of virtual space information based on the target assigned to the user. [Solution] Based on a user's request to view a virtual space, information about the virtual space is provided to enable the user to view the virtual space. Based on the acceptance of a user's request to view a predetermined area of ​​the virtual space, permission is granted for the user to be provided with information about the predetermined area. Based on the granting of predetermined objects that the user can use within the virtual space, the user is granted the authority to receive information about the predetermined area. Whether or not permission is granted for the provision of information about the predetermined area is granted on the condition that information regarding the user's authority who made the viewing request can be identified.

Description

Technical Field

[0001] The present invention relates to a virtual space providing system, a virtual space providing method, and a virtual space providing program.

Background Art

[0002] As a system for determining whether a user can participate in a predetermined area (for example, an event room) of a virtual space, for example, Patent Document 1 discloses a system that determines according to whether the user owns a predetermined object such as an item.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in such a system, if a user does not own a predetermined object such as a predetermined item when requesting to participate in a predetermined event room, even if the user has owned the item required at the time of entry in the past, the user who has made the participation request cannot participate in the event room. <>

[0005] The present invention has been conceived in view of such circumstances, and provides a virtual space providing system, a virtual space providing method, and a virtual space providing program that enable more flexible permission for providing information on a virtual space based on an object given to a user.

Means for Solving the Problems

[0006] A virtual space provision system according to a certain aspect of the present invention includes means for enabling a user to view a virtual space by providing information about the virtual space based on a user's request to view the virtual space, A means for granting permission to provide information about a predetermined area of ​​the virtual space, which grants permission to provide information about the predetermined area to a user based on the receipt of a user's request to view that area, The system includes a means for granting a user the right to receive information about the predetermined area, which is a right that can be granted based on the granting of a predetermined object that the user can use within the virtual space, The aforementioned permission means grants permission to provide information in the predetermined area, on the condition that it has been possible to identify the permissions of the user who made the viewing request.

[0007] With this configuration, the provision of virtual space information is permitted based on the status of the authorization to receive information about a predetermined area that becomes available to the user based on the user being granted a predetermined target that can be used in the virtual space. This makes it possible to more flexibly permit the provision of virtual space information based on the target granted to the user. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows an example of a communication system's hardware configuration. [Figure 2] This is a block diagram illustrating an example configuration of a distribution server. [Figure 3] This is a block diagram illustrating an example configuration for an administrator terminal. [Figure 4] This is a block diagram illustrating an example of a user terminal configuration. [Figure 5] This is a diagram illustrating the concept of virtual space in this embodiment. [Figure 6] This is a diagram illustrating an example of a predetermined area in this embodiment. [Figure 7] This is a diagram illustrating an example of a predetermined area in this embodiment. [Figure 8] This is a diagram illustrating an example of a predetermined area in this embodiment. [Figure 9] This is a diagram illustrating an example of a predetermined area in this embodiment. [Figure 10] This is a diagram illustrating an example of information in a predetermined area provided in this embodiment. [Figure 11] This figure illustrates an example of a predetermined area in this embodiment. [Figure 12] This is a diagram illustrating an example of event information in this embodiment. [Figure 13] This diagram illustrates a predetermined object that a user can use within the virtual space in this embodiment. [Figure 14] This is a diagram illustrating the individual user information in this embodiment. [Figure 15] This is a flowchart illustrating the permission process based on individual information in this embodiment. [Figure 16] This diagram illustrates an example screen and the concept of the processing flow in this embodiment. [Figure 17] This is a diagram illustrating the list of authorized persons in this embodiment. [Figure 18] This is a flowchart illustrating the authorization process based on the list of authorized holders in this embodiment. [Figure 19] This diagram illustrates an example screen and the concept of the processing flow in this embodiment. [Figure 20] This is a flowchart illustrating the authorization process based on the list of authorized holders in this embodiment. [Figure 21] This diagram illustrates the permissions of sub-events in this embodiment. [Figure 22] This is a flowchart illustrating the sub-event permission process in this embodiment. [Figure 23] This figure illustrates an example of other information related to the authorization determination process in this embodiment. [Figure 24] This is a diagram for explaining another example of a predetermined object in the present embodiment. [Figure 25] This is a diagram for explaining an example of activity scale information in the present embodiment. [Figure 26] This is a diagram for explaining an example of a privilege according to the activity scale information in the present embodiment. [Figure 27] This is a diagram for explaining activity characteristic information and privileges according to a special player in the present embodiment. [Figure 28] This is a diagram for explaining activity characteristic information and privileges according to a special player in the present embodiment. [Figure 29] This is a diagram for explaining activity characteristic information according to a special player in the present embodiment. [Figure 30] This is a diagram for explaining an example of a screen of a special player based on the activity characteristic information according to the special player in the present embodiment.

Embodiments for Carrying Out the Invention

発明を実施するための形態

Embodiments for Carrying Out the Invention

[0009] Hereinafter, a virtual space providing system according to an embodiment of the present disclosure will be described while referring to the drawings. In the following description, the same reference numerals are assigned to the same elements in the description of the drawings, and duplicate descriptions will not be repeated.

[0010] <Configuration of the Virtual Space Providing System> FIG. 1 is a diagram showing an example of the hardware configuration of a virtual space providing system 1. The virtual space providing system 1 includes a distribution server 100, an administrator terminal 200, and a plurality of user terminals 300a, 300b, 300c... The plurality of user terminals each belong to a different user and are hereinafter collectively referred to as user terminals 300.

[0011] The distribution server 100, the administrator terminal 200, and the user terminal 300 are each capable of communicating via network 2 and sending and receiving information (data) bidirectionally. Network 2 is, for example, the internet and consists of access networks such as LAN (Local Area Network), WAN (Wide Area Network), mobile communication networks (e.g., 5G, wireless networks, etc.), wired telephone networks, FTTH (Fiber To The Home), and CATV (Cable Television) networks.

[0012] The distribution server 100 is, for example, a computer such as a workstation or personal computer with communication capabilities. The distribution server 100 manages multiple virtual spaces (also called metaverse spaces), which are virtual worlds built on the computer, and provides these virtual spaces (metaverse spaces) to users via the network 2, and provides services (content) using the virtual space selected by the user.

[0013] In this embodiment, users can participate in a virtual space provided by the distribution server 100 in response to operations on the user terminal 300, and can perform activities, actions, and make statements through a user character corresponding to the user. Users in this embodiment include general consumers, talents, and celebrities. Talents include, for example, talented individuals from various genres, such as talents, entertainers, actors / actresses, comedians, multi-talented individuals, presenters, news anchors, singers, musicians, and models belonging to a virtual space service provider (operating company). Celebrities include, for example, famous company executives or employees, athletes, e-sports players, famous scholars / cultural figures / cram school instructors, famous students, and other influencers. In addition, influencers may be identified and processed based on the number of followers of the follow function in the virtual space provided by the distribution server 100.

[0014] In this embodiment, some users may be treated as special users and given different processing than other users. In the distribution server 100, information on special users may be stored in the database with an ID that allows them to be identified as special users. Special users are, for example, talents, celebrities, etc., and may be given special privileges to perform actions in the metaverse space. For example, as performer users at events, they can perform various performances such as singing, dancing, and talking, and provide content to other users (viewers / participants).

[0015] The content provided to users using the virtual space is managed and configured according to the type of content. Available content includes, but is not limited to, content that allows users to view and experience games, live performances, events, programs, avatar creation, etc., as well as content that facilitates interaction and communication between users using chat, emotes, etc. Users can access the distribution server 100 using their user terminal 300 and select the desired content, thereby seamlessly participating in (navigating) that content and viewing and experiencing the virtual space corresponding to that content.

[0016] The virtual space includes, depending on the type of content, a three-dimensional space (a space constructed based on three-dimensional data) generated by CG (Computer Graphics) and a two-dimensional space (a space constructed based on two-dimensional data). The virtual space also contains virtual characters (avatar objects), objects representing backgrounds and virtual objects according to the type of content, and menu objects that the user can select. The virtual characters placed in the virtual space include user characters that are pre-configured for each user participating in the virtual space and can operate in response to user operations, as well as non-player characters that operate according to a program.

[0017] The distribution server 100 stores in the storage unit 120 information for displaying images in multiple virtual spaces (for example, video from a predetermined virtual camera) corresponding to the content that can be distributed on the user terminal 300, as well as sound information for outputting sound. In addition, in response to access (viewing request) from the user terminal 300, the distribution server 100 provides content (services) to the user by distributing virtual space generation data (for example, content data to allow the user to use the provided content, synchronization information of other users, comment data, etc.) that includes display information for displaying images in the virtual space of the corresponding content (for example, video from a predetermined virtual camera) and sound information for outputting sound.

[0018] The data used to generate the virtual space includes, for example, information that will serve as the background image of the virtual space (metaverse space), information to identify objects placed within the virtual space (e.g., object type, placement, orientation, posture, and appearance), information about each user character participating in the virtual space (e.g., user character type, placement, orientation, posture, appearance, motion data, and audio data), objects representing backgrounds and virtual objects according to the type of content, menu objects selected by the user (e.g., user interface), and information to identify background music in the virtual space.

[0019] Objects in the virtual space change their posture, position, and facial expressions in response to operations from the user terminal 300, and their appearance changes over time. Therefore, by distributing virtual space generation data at predetermined intervals (for example, every 0.016 seconds at approximately 60 fps), the user terminal 300 can display images of the virtual space that are constantly changing. Alternatively, the virtual space generation data distributed at predetermined intervals may be distributed in response to the distribution server 100 receiving a synchronization request signal sent from the user terminal 300, and the timing of the predetermined intervals can be varied depending on the load on the distribution server 100. For example, as the load increases, the number of synchronizations per second can be gradually reduced from 6 to 3, then to 1, and so on. Furthermore, the distribution server 100 may send information (request information) to the user terminal 300 so that processing can be performed on the user terminal 300 to reduce the frequency of signals requesting synchronization. Even if the user terminal 300 requests content data, the interval between responses from the distribution server 100 to the request may lengthen as the load increases.

[0020] Furthermore, the distribution server 100 manages programs and data that enable user terminals 300 to progress through (play) content such as live events or games. For example, when a user selects game content, the distribution server 100 distributes programs and data to provide services using the virtual space of that game content to the user terminal 300. Note that the timing of distribution of programs and data for progressing through content from the distribution server 100 is not limited to when the user selects content, but may also occur when the user logs into the distribution server 100 or when predetermined achievement conditions are met.

[0021] The administrator terminal 200 is used by operators of service providers of the virtual space (metaverse space). The administrator terminal 200 is a computer with operation input functions and communication functions, such as a personal computer. The operator uses the administrator terminal 200 to create, build, modify, and update content and images in the virtual space managed by the storage unit 120 of the distribution server 100. For example, this includes generating and building new content and images in the virtual space, and changing and modifying existing content and images in the virtual space. The operator also uses the administrator terminal 200 to set and update information managed by the storage unit 120 of the distribution server 100.

[0022] In this embodiment, the distribution server 100 and the administrator terminal 200 are each represented as independent computers (devices), but they may be implemented by a single computer, or the functions of one of these computers (for example, the distribution server 100) may be implemented by multiple computers (for example, multiple servers).

[0023] The user terminal 300 is used by users to play in the virtual space provided by the distribution server 100 and to view and experience content. The user terminal 300 may be a computer with operation input functions and communication functions, such as a personal computer, tablet device, or smartphone.

[0024] Furthermore, the user terminal 300 may have motion capture functionality to capture user movements in addition to operation input and communication functions. For example, user movements can be tracked by methods such as estimating movement using a camera without contact with the user (e.g., optical, image processing, etc.) or detecting movement from sensors attached to the user's body (e.g., inertial sensor method). User movements may be reflected in the avatar through upper body tracking, face tracking, full body tracking, or lip-syncing based on voice. For example, motion data (motion capture data) based on tracking user movements by mounting or connecting a camera (e.g., a webcam, a camera with a depth sensor) and processing images acquired from the camera may be reflected in the user character (hereinafter also referred to as the avatar) operated by the user. It may also be possible to estimate movements and control the avatar's facial expressions from an HMD (Head-Mounted Device) worn on the user's head. The HMD may be one in which a user, for example, holding a controller capable of communicating with the HMD, can operate the buttons on the controller or capture hand movements to control the displayed virtual space or virtual character.

[0025] The user terminal 300 acquires motion information to identify the user's head or hand movements and controller operations, as well as audio information to identify the user's voice. This allows the user's player avatar (user character) movements and voice to be reflected in the avatar displayed on the user terminal 300 (an avatar usable in a virtual space, generated based on information provided by the distribution server 100). This makes it possible, for example, to live stream video of the avatar with the motion reflected.

[0026] Furthermore, the motion information and audio information can be transmitted to the distribution server 100 to reflect the movements and voice of the user's avatar (user character) within the virtual space in which they are participating. This allows the user's avatar to operate within the virtual space as if it were a digital representation of the user. As mentioned above, based on the virtual space generation data (including content data, etc.) transmitted from the distribution server 100 at predetermined intervals, the movements and voice of the user's user character in the virtual space can be reflected (synchronized) on each user terminal 300 of the user participating in the virtual space. This makes it possible to communicate with other users participating in the virtual space using avatars that reflect motion and voice.

[0027] The user terminal 300 communicates with the distribution server 100 in response to operations performed on the terminal and receives content data of the content selected by the user. Based on the content data received from the distribution server 100, the user terminal 300 constructs a virtual space of the content selected by the user from among the virtual spaces constructed on the distribution server 100 within the user terminal 300's memory area, displays images within that virtual space, and outputs sound. This makes it possible to view and experience the virtual space of the content via the user terminal 300.

[0028] Furthermore, the user terminal 300 accepts operations on the displayed virtual space and objects, as well as operations such as selecting various icons, selecting content, and inputting text. The user terminal 300 transmits information corresponding to the operations on the terminal to the distribution server 100, which allows the user's player avatar to move and operate within the virtual space of the content they are participating in. As mentioned above, based on the content data transmitted from the distribution server 100 at predetermined intervals, the movement of the player avatar can be reflected (synchronized) in the virtual space of each user terminal 300 of users participating in the same content.

[0029] Furthermore, while enabling users to view and experience the virtual space of the content, the user terminal 300 can also post comments, including arbitrary messages, as an example of actions taken in the virtual space of the content it is participating in, in response to operations performed on the terminal. By posting comments, these comments can be reflected on each user terminal 300 so that users participating in the content can see them.

[0030] Furthermore, the user terminal 300 stores programs and data distributed from the distribution server 100 when content is selected by the user, and based on these programs and data, displays a virtual space corresponding to the selected content and enables the user to proceed with (play) the content. For example, if the user selects the main area, which is a space modeled after a city, on the title screen, the user terminal 300 receives and stores data including a program for displaying the main area, and based on this data, the main area is displayed on the display unit of the user terminal 300. Also, if a predetermined game content is selected within the virtual space, the user terminal 300 receives and stores data including a program for playing the game content, and the game content becomes playable. In this embodiment, a predetermined area within the virtual space may function as a predetermined game content.

[0031] <Configuration of the distribution server> Next, the configuration of the distribution server 100 will be described. As shown in Figure 2, the distribution server 100 includes a communication unit 110 that communicates with other computers, a storage unit 120 that stores various data, and a control unit 130 that controls the entire computer. The communication unit 110, the storage unit 120, and the control unit 130 are interconnected by a bus line.

[0032] The communication unit 110 is a communication interface equipped with a NIC (Network Interface Card controller) for wired or wireless communication. The communication unit 110 communicates with other computers via network 2. For example, it functions as an interface to allow other computers to obtain some of the information stored in the storage unit 120.

[0033] The storage unit 120 consists of RAM (Random Access Memory), ROM (Read Only Memory), flash memory, HDD (Hard Disk Drive), etc. The storage unit 120 stores programs for executing various control processes (for example, programs for managing and providing content using the virtual space, programs for granting permission to receive information about the virtual space, and programs for determining whether or not permission exists), various data, etc. The various data stored in the storage unit 120 include information for identifying images in the virtual space, which are provided for each type of content, and user data 121 for identifying information about the user. Information for identifying images in the virtual space includes, for example, object data 122 and provided content data 123.

[0034] User data 121 includes individual user information managed in association with the user's identification information (ID). This individual information includes, for example, the username, user avatar data, user status, owned items, permissions, information on favorited users, activity history in the virtual space, and information on owned currency.

[0035] Object data 122 includes, for example, data for building objects, item objects, avatar objects, currency, images (stamps) that can be used in place of comments in communication (chat, etc.), and other objects placed in the virtual space or objects that users can use in the virtual space (including placed objects).

[0036] Examples of objects placed in a virtual space include, in the case of game content, item objects, character objects, and user character objects of users playing the game, all of which are placed on a field object corresponding to the game field. In the case of live content, for example, a stage object, audience seating object, and lighting object are placed, with the user character of the performer conducting the live show placed on the stage object and the user character of participating users placed on the audience seating object. In the case of content that facilitates communication, for example, the user character objects of each of the participating users and item objects that can be used for communication are placed. In addition, a space resembling a city may be provided, and not limited to those that enable communication between users, objects such as signs and bulletin boards may be placed to allow users to obtain and view information inside and outside the virtual space.

[0037] The provided content data 123 includes, for example, area data for identifying a specific area within the virtual space, and event data for identifying information about events within the virtual space. Area data includes information for constructing the virtual space, such as various main areas, various rooms where the same main area is provided, and designated regions, as well as information for identifying the content provided in the designated area. Event data includes date and time information for events held in the virtual space, venue information, event distribution data, participant rosters (participant lists), event history, and information regarding event participation rights.

[0038] The control unit 130 consists of a CPU (Central Processing Unit) and the like. The control unit 130 controls the overall operation of the distribution server 100 and performs various calculations by executing programs stored in the memory unit 120.

[0039] The functional configuration of the control unit 130 is described below. The control unit 130 functions as at least a content management unit 131, a data distribution unit 132, and a user management unit 133. Various functions may be operated by separate servers, or multiple functions may be executed on a single server (for example, a virtual server).

[0040] The content management unit 131 stores and updates information about the virtual space (e.g., object data 122, provided content data 123, etc.) in the storage unit 120, which is provided to users configured by the administrator terminal 200 via the communication unit 110, and manages the content. In addition, the content management unit 131 constructs and updates the virtual space based on the virtual space information stored in the storage unit 120, manages synchronization between users, and performs various controls and management related to the content provided in the virtual space. For example, as part of the control and management of event content provided to users, the content management unit 131 identifies the data for generating the virtual space to be provided (distributed) to users, and manages and determines the right to participate in events.

[0041] The data distribution unit 132 distributes virtual space generation data, which includes information for rendering and displaying the virtual space selected by each terminal and managed by the content management unit 131, to the access source (viewing request source) user terminal 300 at predetermined intervals.

[0042] The user management unit 133 stores and updates user information about users as user data 121 (individual user information) in the storage unit 120. The user management unit 133 also grants users objects such as items, rights such as room entry privileges, and privileges, and stores and updates these as user data 121. Furthermore, the user management unit 133 stores and updates the user's activity history in the virtual space as user data 121.

[0043] <Administrator terminal configuration> Next, the configuration of the administrator terminal 200 will be described. As shown in Figure 3, the administrator terminal 200 includes a communication unit 210 for communicating with other computers, a storage unit 220 for storing various data, an input unit 230 for inputting operation instructions, an output unit 240 for outputting images, sound, etc., and a control unit 250 for controlling the entire computer. The communication unit 210, storage unit 220, input unit 230, output unit 240, and control unit 250 are interconnected by a bus line.

[0044] The communication unit 210 is a communication interface equipped with a NIC for wired or wireless communication. The communication unit 210 communicates mainly with the distribution server 100 via network 2. The storage unit 220 consists of RAM, ROM, HDD, etc. The storage unit 220 stores programs for executing various control processes (for example, programs for managing content using virtual space), various data, etc.

[0045] The input unit 230 includes an input device (e.g., a touch panel, touchpad, mouse or other pointing device, keyboard, etc.) for receiving input operations from the administrator. The output unit 240 includes an output device (display, speaker, etc.) for presenting information to the administrator.

[0046] The control unit 250 consists of a CPU and other components. The control unit 250 controls the overall operation of the administrator terminal 200 by executing programs stored in the memory unit 220.

[0047] The functional configuration of the control unit 250 is described below. The control unit 250 functions as at least a content setting unit 251 and a user setting unit 252.

[0048] The content setting unit 251 stores and updates information about content and virtual spaces managed by the content management unit 131 of the distribution server 100 in response to operations on the administrator terminal 200. This allows the storage unit 120 to store and update information such as information for identifying content, information for identifying images within the virtual space for each piece of content, and information for identifying the date and time of distribution. Furthermore, the information that the content setting unit 251 can store and update in the storage unit 120 can be set for each predetermined area within the virtual space.

[0049] The user setting unit 252 sets user information for users managed by the user management unit 133 of the distribution server 100 in response to operations on the administrator terminal 200. For example, an operator operating the administrator terminal 200 can assign an ID to a special user to identify them as a special user, or assign an attribute number to identify them as a special user.

[0050] <User terminal configuration> Next, the configuration of the user terminal 300 will be described in detail. As shown in Figure 4, the user terminal 300 includes a communication unit 310 that communicates with other computers, including the distribution server 100; a storage unit 320 that stores various data; an input unit 330 for inputting operation instructions, etc.; an output unit 340 for outputting images, sounds, etc.; and a control unit 350 that controls the entire computer. The communication unit 310, storage unit 320, input unit 330, output unit 340, and control unit 350 are interconnected by a bus line.

[0051] The communication unit 310 is a communication interface (equipped with a communication module such as a NIC) for wired or wireless communication. The communication unit 310 communicates with other computers, such as the distribution server 100, via the network 2.

[0052] The memory unit 320 consists of RAM, ROM, HDD, etc. The memory unit 320 stores programs for executing various control processes (for example, programs for playing in the virtual space, programs for viewing content using the virtual space, etc.), various data, etc. For example, the memory unit 320 reads virtual space generation data received from the distribution server 100.

[0053] The input unit 330 includes input devices (e.g., touch panel, touchpad, pointing device such as mouse, keyboard, microphone, etc.) for receiving user input operations and voice. The user terminal 300 may also be equipped with input devices such as a camera and an HMD with motion capture functionality, and the input unit 330 may include a motion input unit that acquires the user's movements as motion information. User operations in this embodiment refer to operations from the user to these input units 330. Examples include touch operations on the touch panel, slide operations, flick operations, button operations, drag (swipe) operations, operations on icons displayed on the display unit of the user terminal 300, operations on pointing devices and keyboards, and voice input to the microphone.

[0054] The output unit 340 includes an output device (such as a display unit, speaker, etc.) for presenting and outputting information (text, images, audio, etc.) to the user.

[0055] The control unit 350 consists of a CPU and the like. The control unit 350 controls the overall operation of the user terminal 300 by executing programs stored in the memory unit 320. The functional configuration of the control unit 350 is described below. The control unit 350 functions as an information transmission / reception unit 351, a virtual space generation unit 352, a virtual camera control unit 353, a display control unit 354, an audio output control unit 355, and an operation identification unit 356.

[0056] The information transmission / reception unit 351 receives virtual space generation data (content data and comment information, etc.) from the distribution server 100 via the communication unit 310, and stores information for displaying images in the virtual space where various objects are placed based on the virtual space generation data in the storage unit 320. The information transmission / reception unit 351 also transmits audio information and operation input information acquired by the input unit 330 to the distribution server 100.

[0057] The virtual space generation unit 352 generates (constructs) a virtual space, places objects, and operates them based on the virtual space generation data (content data, etc.) stored in the storage unit 320 acquired by the information transmission / reception unit 351. A virtual camera is placed in the virtual space generated by the virtual space generation unit 352 by the virtual camera control unit 353 (described later), and the virtual space within the viewpoint of the virtual camera is rendered by the display control unit 354 and displayed on the output unit 340 (display unit such as a display).

[0058] The virtual camera control unit 353 is positioned within the virtual space generated by the virtual space generation unit 352 and controls a virtual camera for identifying the area (field of view) of the image within the virtual space that is to be displayed on the user terminal 300. The virtual camera control unit 353 controls the position, orientation, and tilt of the virtual camera according to operations on the input unit 330 or predetermined rules.

[0059] The display control unit 354 performs drawing processing of the virtual space data generated by the virtual space generation unit 352 based on the virtual space generation data acquired by the information transmission / reception unit 351 and stored in the storage unit 320, and executes processing to display it on the display unit (display, etc.) of the output unit 340. The display control unit 354 displays the image (video from the virtual camera) corresponding to the field of view area, which is the view from the virtual camera controlled by the virtual camera control unit 353, on the display unit (display, etc.) of the output unit 340 from the generated virtual space data.

[0060] In this embodiment, the user terminal 300 stores virtual space generation data received from the distribution server 100 in the storage unit 320, and by placing a virtual camera in the virtual space stored in the storage unit 320 and controlling the virtual camera, the field of view displayed on the user terminal 300 is changed. However, the embodiment is not limited to this, and for example, the user's virtual camera may be placed in the virtual space stored in the storage unit 120 of the distribution server 100, the virtual camera control unit 353 may control the virtual camera to change the field of view of the virtual camera, and data for identifying the image within the field of view may be received and displayed on the user terminal 300 (for example, streaming distribution may also be used).

[0061] The audio output control unit 355 outputs audio from the audio output unit (such as a speaker) based on the virtual space generation data acquired by the information transmission / reception unit 351. This audio includes the voices of other users, background music data for the virtual space, and sound data such as live performances and singing.

[0062] Furthermore, the display control unit 354 displays a UI (User Interface) image (for example, a menu image that the user can select and an operation image that accepts operations) in a manner appropriate to the content being provided, based on a program stored in the storage unit 320. In this embodiment, different UI images may be displayed for the user terminal 300 used for participation as a general user and for the user terminal 300 used by a special user different from a general user. For example, a UI image for posting comments may be displayed on the user terminal 300 (during program execution for viewing / experiencing), while not displayed on the user terminal 300 used by a special user who primarily communicates by voice (during program execution for content distribution / event provision, etc.). Also, since the necessary menu items differ between viewing / experiencing and content distribution, the UI image for selecting menus may differ between the general user terminal 300 (during program execution for viewing / experiencing, etc.) and the user terminal 300 used by a special user (during program execution for content distribution / event provision, etc.).

[0063] The operation identification unit 356 identifies the operation input information from the user acquired by the input unit 330. The operation input information includes various types of user input information, such as information on viewing requests to a virtual space (for example, a predetermined area), text input information in chat, user entry and exit information to the virtual space, and operation information to identify operations on objects displayed in the virtual space or user characters placed within the virtual space. User entry and exit information to the virtual space includes user login information (login requests to the virtual space), logout information, and information such as movement between areas and rooms in each virtual space. Based on the identification of the user's operation input information by the operation identification unit 356, the information transmission and reception unit 351 transmits the user's input information to the distribution server 100 via the communication unit 310.

[0064] In this embodiment, the user terminal 300 may be implemented by a single computer, or one of the functions described as being performed by the user terminal 300 may be implemented by multiple computers.

[0065] Special users may participate in the virtual space either as providers of content such as events and live performances, or as general users. The storage unit 320 of the special user's user terminal 300 may be stored with a program for controlling the virtual space provided by the distribution server 100 exclusively for special users, allowing the special user's user terminal 300 to execute different controls than other general users. For example, it may be possible to select or change which role the special user is playing at predetermined timings (e.g., when logging in, providing events or live performances, or displaying the special user's avatar in the provided content). Furthermore, the information of other users displayed on the special user's user terminal 300 may be different from the information of other users displayed on the general user's user terminal 300. "Other users" refers to users different from the user corresponding to user terminal 300a (users corresponding to user terminals 300b, 300c, etc.). For example, on a general user's terminal 300, the username is displayed as information about other users, while on a special user's terminal 300, in addition to the username, information based on the other user's past activities in the virtual space (number of times they have participated in events) and information suggesting their relationship with the special user (for example, information suggesting that they are a general user who supports the special user) may be displayed. This makes it possible, for example, for a special user to provide performances to audience users that are tailored to the nature of the audience users, based on the information of the other user (for example, the information displayed on the special user's terminal 300 in Figure 30, which will be described later).

[0066] <Types of designated areas> Next, with reference to Figures 5 to 11, an example of a predetermined area of ​​the virtual space provided to the user in this embodiment will be described. In the virtual space provision system 1 in this embodiment, based on a user's request to view the virtual space, the system can execute a process that allows the user to view the virtual space. Specifically, the distribution server 100 receives a request from the user terminal 300 for data to render an image of the virtual space, and then distributes information about the virtual space (data for generating the virtual space) to the user terminal 300. In this embodiment, information corresponding to a predetermined area of ​​the virtual space is also provided to the user. Specifically, the distribution server 100 receives a request from the user terminal 300 to view a predetermined area within the virtual space provided by the virtual space provision system 1 (distribution request), and then distributes information about the predetermined area (data for generating the virtual space of the predetermined area) corresponding to that request to the user terminal 300.

[0067] First, referring to Figure 5, the overall concept of the virtual space provided by the virtual space provision system 1 of this embodiment will be explained. The virtual space 10 of this embodiment includes multiple types of spatial areas (spatial area 11, spatial area 12, etc.). Each spatial area can provide content of different types, such as themes and genres. As multiple types of spatial areas, for example, there are areas corresponding to various types of content, such as entrances, live venues, game content, and exhibition halls. For example, an event venue where live content is held is constructed in the entirety of a predetermined spatial area, or in part of a predetermined spatial area. Furthermore, each spatial area can be selected and entered by the user from a menu screen displayed after the user logs into the system that provides the virtual space 10.

[0068] Each spatial area consists of multiple rooms, each providing content for the same spatial area. When entering any spatial area, users can experience its content by entering one of the rooms within that area. Rooms may be configured so that users can choose which room to enter, or they may be automatically assigned a room (e.g., load balancing). Each room has a maximum capacity, for example, up to 200 people. Each room is managed by, for example, a real-time synchronization server. Users in the same room can see each other's avatars and communicate with each other. For example, they can play games together or chat. For example, if spatial area 11 is a space modeled after a city, then rooms 11a, 11b, etc., corresponding to spatial area 11 will provide users with the same city-like space, but the only avatars that can be displayed within the space are those corresponding to users associated with the same room. For example, the avatar of a user associated with Room 11a will not be displayed on the user screen of a user associated with Room 11b. However, as an exception, the avatars of special users (e.g., talents, performers, etc.) can be displayed not only in the room they are actually in, but also in other rooms (mirroring).

[0069] Movement between spatial areas may be restricted to users who log in to the virtual space and must first pass through a designated spatial area providing specific content (e.g., an entrance area) before moving to another spatial area, or it may be possible to move freely between them. For example, movement from spatial area 12 to spatial area 13 may be restricted to spatial area 11, or direct movement between spatial area 12 and spatial area 13 may be possible without passing through spatial area 11. Furthermore, a transition animation may be performed when moving between spatial areas. For example, when moving to another spatial area, the display screen may dim (e.g., a black screen with a message such as "Loading...") before switching. Regarding user access to each spatial area, after logging in, users may first enter an entrance area, or they may be able to choose and enter their preferred spatial area without passing through an entrance area, or they may be transitioned to a spatial area randomly determined by a lottery. Similarly, for each room, users may choose and enter their preferred room, or they may enter a room randomly determined by a lottery. Hereafter, virtual space 10 will also be referred to simply as virtual space.

[0070] Figure 6 is a diagram illustrating an example of a predetermined area (main area and each room) in this embodiment, and is an example of a main area list screen that allows the user to select a main area to enter from the virtual space provided by the virtual space provision system 1. Main areas A to D correspond to space areas 11 to 14, etc., as explained with reference to Figure 5. Also, rooms 1 to 3 displayed at the bottom of main area A in Figure 6 correspond to rooms 11a, 11b, etc., which correspond to space area 11. Main area A is, for example, a space themed as a city, and main area B is a space themed as a forest, etc. Each main area also functions as an event venue. It is possible to enter a main area by entering the room corresponding to that main area. For example, when a button for each area is selected on the user terminal 300, one of the rooms may be automatically assigned, or the user may be able to enter any room by selecting the button for the room shown in the diagram. Furthermore, as an example of the display screen of the user terminal 300, as shown in Rooms 1 to 3 of Figure 6, along with the room buttons, the system may display information to inform the user about the level of congestion and the status of friends (e.g., those who have added each other as friends) entering the virtual space. In addition, each main area itself, or a designated room corresponding to a main area (for example, Room 1 of Rooms 1 to 3), may be designed so that users cannot enter unless they have permission to do so.

[0071] Furthermore, the main area list may display buttons (e.g., shops) that allow users to transition to shops where they can purchase items (e.g., equipment) available in the virtual space, as shown in the diagram. It may also display buttons (e.g., My Room) that allow users to transition to their personal room in the virtual space.

[0072] Figures 7(A) to 7(C) are diagrams illustrating the virtual space information in rooms associated with each main area, which allows users to experience the same virtual space as illustrated in Figure 6. Figure 7(A) corresponds to Room 1, Figure 7(B) to Room 2, and Figure 7(C) to Room 3. The default objects of the main area corresponding to each room (for example, Main Area A) are placed in the same position and manner in each room. For example, the stage object 22 and the building object 23 are common to each room. On the other hand, users accessing (entering) each room are synchronized with other users accessing the same room, but not with users accessing other rooms. However, for users who meet certain conditions, such as special users, the information of those special users (display manner of avatar, voice, location, etc.) is synchronized (mirrored) to users in rooms other than the one the special user is actually accessing. For example, as shown in Figures 7(A) to 7(C), in Rooms 1 to 3, the performer avatar 21 corresponding to a special user (e.g., the performer user) is displayed in the other rooms by mirroring it.

[0073] Figures 8(A) and 8(B) illustrate examples of predetermined areas (each region within the main area) in this embodiment, and illustrate examples of further subdivision within a single main area (for example, main area A). Specifically, this is an example in which multiple types of virtual spaces (different regions) are provided within the main area, and even if a user is accessing a predetermined room within the main area (for example, room 1 in main area A), users in different regions are not synchronized.

[0074] Figure 8(A) illustrates two cases where a predetermined virtual space (for example, one of the main areas) is defined by multiple regions, and these multiple regions are seamlessly connected as a user experience (upper part of Figure 8(A)) and separated (lower part of Figure 8(A)). For example, as shown in Figure 8(A), suppose a predetermined virtual space 30 corresponding to one of the main areas is composed of region 31 and region 32. Regions 31 and 32 are related in a separable way, even within the main area, with further differences in the types of objects placed and the types of content provided to the user, such as a town area and a castle area, a town area and a shrine area, a town area and a venue area, or a town area A and a town area B. For example, during a specific event, region 31 and region 32 can be separated (for example, by assigning different servers or rooms) as shown in the lower part of Figure 8(A). Furthermore, the movement of user avatars between regions may be done via movement points (movement gates, switching points) such as portals 33. Furthermore, when moving between areas, a screen blackout or other transition effect may be implemented. For example, even if a user is associated with a predetermined room (e.g., room 1) in the virtual space 30 by the content management unit 131 in the storage unit 120, area 31 and area 32 are treated as separate virtual spaces (different rooms, predetermined areas). Users accessing one area are synchronized, but users accessing the other area are not.

[0075] Figure 8(A) shows an example where a predetermined area can be in two states: one where it is not separated and one where it is separated. In contrast, Figure 8(B) is a diagram illustrating an example where an area is separated, while still providing a user experience that makes it appear as if it is a seamlessly connected area within a predetermined virtual space (e.g., one of the main areas). In Figure 8(B), the predetermined virtual space 40 is composed of area 41 and area 42, and transitions between area 41 and area 42 occur via a movement point such as an entrance 43 (e.g., a door), similar to the case in Figure 8(A). For example, area 42 corresponds to a building object surrounded by walls, etc., placed within area 41. For example, even if a user is associated and managed by the storage unit 120 as a user of a predetermined room (e.g., room 1) in the virtual space 40 by the content management unit 131, area 41 and area 42 are treated as further different virtual spaces (different rooms, predetermined areas), and users accessing one area are synchronized, but users accessing the other area are not synchronized.

[0076] Furthermore, synchronization that places a load on the distribution server 100, such as location synchronization, may be performed between each area (area 31 and 32, or area 41 and 42), while synchronization that places a light load on the distribution server 100, such as text chat, may be performed between each area. Additionally, when entering the main area (when entering the virtual space 40), users may be allowed to access rooms corresponding to areas 31 and 41, and after accessing areas 31 and 41, users may be allowed to access rooms in areas 32 and 42. Moreover, after accessing areas 31 and 41, users may be prevented from accessing rooms in areas 32 and 42 unless they have the necessary permissions.

[0077] Figures 9(A) and 9(B) illustrate examples of predetermined areas (each region within the main area) in this embodiment, and are diagrams illustrating other examples of further subdivisions within a single main area (for example, main area A). Figures 8(A) and 8(B) illustrate an example where users are asynchronous between regions within a predetermined room in a predetermined main area (different rooms are set up). On the other hand, in the examples of Figures 9(A) and 9(B), different processes are executed in each region that is divided within a certain range of the region within the predetermined main area, but synchronization between users is possible between each region. Different processes include, for example, processes that can be entered by users who have been granted access privileges (permission to receive information about that region) within a predetermined region. In addition, synchronization processes are included in which information about user avatars within a predetermined region (for example, the position and movement of a special user who has gone up to the stage of the predetermined area, etc.) is mirrored to other different rooms (rooms 1 to 3, which are provided with the same main area as exemplified in Figures 7(A) to 7(C), etc.).

[0078] Figure 9(A) is a diagram showing the extent of each region when viewed from above in a predetermined virtual space 50 (for example, Main Area A). For example, it shows an example that includes region 51 defined as a stage, region 52 defined as a shop, and region 53 defined as a plaza. The other regions are designated as region 54. Figure 9(B) is an example of the virtual space 50 viewed from above in Figure 9(A) but shown from the player's perspective. In Figure 9(B), region 51 is the region where stage objects are placed, region 52 is the region where shop objects are placed, and region 53 is a certain range of region where stage objects are placed. Users located in regions 51, 52, and 53 can synchronize the position and appearance of their avatars with users located outside of these regions, but the user experience for each region can be processed differently depending on whether or not the user has the necessary permissions. For example, in the stage of area 51, special users with access privileges (e.g., performer users) may be able to enter (join, participate), but users without access privileges may not be able to enter. Similarly, in the shop of area 52, users with access privileges may be able to enter (join, participate), but users without access privileges may have their entry requests rejected. In this way, even if a user's terminal 300 is denied access or entry (joining, participating), it may be possible to display user avatars located in areas 51, 52, and 53 from outside those areas (e.g., area 54). Conversely, user terminals 300 of users located in areas 51, 52, and 53 may also be able to display user avatars located outside those areas (e.g., area 54). Note that avatars of users who have already entered an area may not be displayed to users who do not have access privileges to enter each of areas 51 to 53.

[0079] Furthermore, if objects such as building objects or other objects that form a closed space surrounded by certain walls are placed, as in area 52, the transparency of the walls may be set so that the inside of the building in area 52 is visible, allowing users outside the area (for example, area 54) to see what is inside. Alternatively, when a door is opened, the inside may also be displayed to users outside the area.

[0080] Figures 10(A) and 10(B) illustrate an example of information for a predetermined area provided in this embodiment. Figures 10(A) and 10(B) are examples of screens displayed on user terminals 300 of different users, and the relationship between these different users is one in which location information is synchronized (for example, they are accessing the same Room 1 in Figure 6). For example, both Figures 10(A) and 10(B) are examples of virtual spaces for a predetermined room corresponding to either main area. Furthermore, the user corresponding to Figure 10(A) has the authority to receive information for the predetermined area, while the user corresponding to Figure 10(B) does not have the authority to receive information for the predetermined area.

[0081] In both Figure 10(A) and Figure 10(B), the user avatars 24 and 25, and the stage object 22 are displayed on the screen of the user terminal 300. In the user terminal 300 in Figure 10(A), the user in Figure 10(A) has the authority to receive information for a predetermined area (information for rendering the performance on the stage object 22), so data for rendering the performer avatar 21 is delivered, and the performer avatar 21 is displayed (viewable). On the other hand, in the user terminal 300 in Figure 10(B), the user in Figure 10(B) does not have the authority to receive information for a predetermined area, so data for rendering the performer avatar 21 is not delivered, and the performer avatar 21 is not displayed (not viewable).

[0082] Here, the designated area in Figures 10(A) and 10(B) may be the main area as illustrated in the corresponding Figure 6, or a designated room in any of the main areas illustrated in Figures 6, 7(A) to 7(C), or a designated region within the main area as illustrated in Figures 8(A) to 9(B). For example, even if an unauthorized user such as in Figure 10(B) can enter region 32 in Figure 8(A) and region 42 in Figure 8(B) regardless of whether they have the authority to receive specific information from the information in the designated area, some specific information (such as event production data) from the virtual space may not be distributed because they do not have the authority. Also, even if neither authorized nor unauthorized users can enter region 51, such as a stage, in Figures 9(A) and 9(B), information on the stage may be distributed to the user terminal 300 of an authorized user, and the performance images on the stage may be displayed. In addition, the distribution server 100 may distribute information that allows users to view performances and other content within a designated area (for example, buildings in area 52, a plaza in area 53, etc.) from a viewpoint outside that area to the user terminal 300 of users who have access privileges to enter that area. For example, data related to performances (including sound data such as singing), such as the appearance inside the buildings in area 52 or the movements and performances of performer avatars in the plaza in area 53, may be made available for display (output) on the user terminal 300 from a viewpoint outside that area, while data for rendering the appearance inside area 52, etc., may not be distributed to the user terminal 300 of users who do not have access privileges, and therefore cannot be displayed.

[0083] Furthermore, even for users who do not have the authority to enter a designated area or receive information, audio may be output outside the designated area (for example, outside the event venue, area 54 in Figures 9(A) and 9(B)). In other words, even if a user does not have the authority, while the data for rendering avatars and performance objects will not be distributed, audio data may be distributed to the user terminal 300 of the user without authority. In addition, the audio information distributed to users without authority may be made different from the audio information that can be received by user terminals 300 of authorized users located within the designated area, such as by lowering the sound quality and volume. As described above, even if entry (participation) into the designated area is possible, the information distributed (provided) can be changed according to the authority each user has.

[0084] Figure 11 is a diagram illustrating a specific area for receiving information about a predetermined area provided in this embodiment. Figure 11 is an example of a virtual space where an event is provided, and shows an example of the arrangement of a stage and seating blocks. For example, seats and a stage are arranged within the main area exemplified in Figure 6. Alternatively, a predetermined area within the main area, as exemplified in Figures 8(A) to 9(B), may be defined as the venue, and the stage and each seating block may be defined within the predetermined area that serves as the venue (for example, within a predetermined area such as a plaza, building, or dome where a street performance or outdoor festival is held). Each seat shown in Figure 11 of the event venue is a specific area for receiving information about a predetermined area (for example, the entire event venue, or the stage within the event venue). For example, when participating in an event, the user avatar is placed at the location of the specific area to which permission has been granted, according to the seat rank permission granted to each user. This makes it possible to view and experience the event from the perspective of the location of the associated specific area.

[0085] As described above, a designated area is a logically separated space in virtual space, and is not limited to spaces separated by objects that function as partitions (e.g., buildings), but also includes spaces that are not separated by partitions. Spaces separated by objects include, for example, spaces that are physically separated in terms of user experience, where collision detection is performed near the boundary (e.g., a wall, or slightly before it) and the user avatar is designed not to clip through (penetrate walls, etc.). Spaces that are not separated also include spaces where there are no physical walls in terms of user experience, where collision detection and room switching processes are not performed, and where movement is seamless (for example, areas such as area 53 in Figures 9(A) and 9(B), where an outdoor festival is held), which can also be designated as a designated area. Furthermore, the entire designated virtual space, for example, the main area itself as shown in Figure 6, and spaces where the servers and room management themselves are separated are also included.

[0086] <Regarding the process for determining participation rights> The participation permission determination process in this embodiment will be explained below with reference to Figures 12(A) to 24(D). In the virtual space of this embodiment, events may be provided (held) in the predetermined area described above. When an event is provided, the virtual space provision system 1 permits the provision of information about the predetermined area to the user based on whether the user has the right to receive information about that predetermined area. Furthermore, the right to receive information about the predetermined area is granted to the user based on the granting of items (for example, items that can be equipped to an avatar) that the user can use in the virtual space. Specifically, in the virtual space provision system 1, when the distribution server 100 receives a viewing request for a predetermined area such as an event venue from the user terminal 300, it refers to the data stored in the storage unit 120 to determine whether the user who made the viewing request has the right to do so. If it is determined that the user has the necessary authority, permission is granted to provide information about the designated area to the user (permission is granted for the user to receive information about the designated area), and the information about the designated area (information to render the designated area, and virtual space generation data that enables rendering and audio output to allow the user to experience events held in the designated area) is delivered to the user terminal 300. In this embodiment, a request to view the designated area includes requests to participate in events offered in the designated area, and requests to enter the designated area (for example, the venue where the event is held), as well as requests to provide experiences in the designated area. The authority to receive information about the virtual space includes the authority to participate in the designated virtual space, the authority to enter, the authority to view, the authority to access, the authority to connect, and the authority to refer to the virtual space.

[0087] Here, we will describe the process of granting user privileges in this embodiment. In this embodiment, information for identifying the right to receive information in a predetermined area associated with the first object (also referred to as the first target, first entity, or first privileged object) is transferred to the second object (also referred to as the second target, second entity, or second privileged object) based on the granting of the first object to the user. The information for identifying the transferred right becomes the user's privilege information. The final determination of whether the user has privileges is made based on the second object, which is different from the first object that triggers the granting of privileges. More specifically, the first object is an object that the user can use in the virtual space, and includes objects that the user can own (manage as possessions) and objects that are managed as user attributes. The second object is an object (the target to which privileges are associated) for managing the user's action privileges in the virtual space, and is the object that is referenced when determining whether the user has action privileges. In the following embodiment, the authority to receive information in a predetermined area is described as the authority to participate in a predetermined event provided in a predetermined area within the virtual space, as described later in Figure 12(A), etc. (the authority to receive information in the predetermined area where the event is provided). Furthermore, the first object that triggers the granting of authority is an item that can be granted to a user through user purchase operations, etc., as described later with reference to Figure 13, etc., and the second object is described as the user ID of the user's individual information, as described later with reference to Figure 14(B), etc., or the authority holder list, as described later with reference to Figure 17, etc.

[0088] (Event Information) Figures 12(A) and 12(B) show examples of event information held in this embodiment, which is managed as event data etc. of the provided content data 123. As shown in Figure 12(A), the event information in this embodiment is associated with each event venue (a predetermined area where the main event is held), including the event name, sub-events, sub-event venues (a predetermined area where the sub-events are held), and period information, which is information about the period during which the event is held. The period information includes, for example, the dates (1 day to multiple days) on which the event is held, the date and time including the time, and other information that specifies the duration of the event, such as dates, times, and days of the week. In addition, the start date to the end date, the opening date to the closing date of the venue, the start time to the end time, the opening time to the closing time of the venue, etc. may also be defined, or only the start date, opening date, start time, opening time, etc., which are the start time (the start timing of the user access period) may be defined. In this embodiment, each event is managed in association with an event ID. In this embodiment, we will describe an example in which one of the main areas exemplified in Figure 6 (for example, Main Area A) is set as Venue A, which will be the main event room (main designated area). For example, event venue "Venue A" corresponds to Main Area A in Figure 6. The event with event ID "EV01" included in the event information of Venue A is "Event A" as the main event, "Handshake Event" as the sub-event, the sub-event venue is "Handshake Event Room", and the event date is set as the period information. Details of the sub-event will be described later with reference to Figures 21 and 22. In addition, events without associated sub-events may be included, such as "Event B" in Figure 12(A).

[0089] Figure 12(B) shows an example of seating information for an event venue. In this embodiment, seat ranks may be defined for each venue. Seat ranks are set, for example, by the content setting unit 251 of the administrator terminal 200. Alternatively, seat ranks may be set from A to C seats from top to bottom, with all other seats having no rank. The seat ranks in Figure 12(B) correspond to the seat blocks shown in Figure 11, for example. For example, seats A to C in Figure 12(B) correspond to A to C in Figure 11, respectively, and the seats with no rank in Figure 12(B) correspond to the blank blocks in Figure 11. For example, a user can view the event from an area within the event venue corresponding to their designated seat rank.

[0090] (Specified target) Figure 13 is a diagram illustrating an example of a predetermined object (first object) that can be used by a user in the virtual space in this embodiment, and which can grant the user the right to participate in an event. Figure 13 is a diagram illustrating an example of item information that is managed as object data 122, etc., and is an item (predetermined object) that can be used by a user in the virtual space, and which is associated with the right to participate in an event. As item information, for example as shown in Figure 13, an event ID is associated with each item ID used to identify each item as information for identifying the right to participate in an event (information for identifying the event to which the right applies, right information). For example, in Figure 13, "Item A" with item ID "IT01" is associated with event ID "EV01" as information for identifying the right to participate in "Event A". The event associated with each item is the right to participate in the corresponding event. This makes it possible to grant items to users and to grant users the right to participate in events.

[0091] Items available to users in the virtual space are, for example, items that can be used by the user in the virtual space and can be managed as data as items owned (possessed) by the user. This includes items that can be equipped to avatars, and other items that can be placed in the virtual space even if they are not equipped to avatars. Items that can be equipped to avatars include, for example, avatar accessories (clothing and accessories), items that help liven up live events such as glow sticks and penlights, and weapons that can be used in games. Avatar accessories may also be items that visually identify an event participant, such as neck straps with cards resembling admission tickets or stickers that can be attached to clothing. Items that can be placed in the virtual space even if they are not equipped to avatars include, for example, housing items (for example, items that can be placed in building games, furniture that can be placed in the user's virtual personal room (my room), stuffed animals, acrylic stands, posters, etc.), and other in-game materials. For example, if a certain item is an avatar accessory limited to a corresponding event (an event associated with participation rights), the user can have their avatar wear the specified item and participate in that event. This allows for a sense of unity throughout the event, for example, by having user avatars, who are audience members, wear event-exclusive avatar decoration items. Furthermore, items such as housing decorations can be kept as mementos of the event even after it ends, by being placed within the virtual space.

[0092] (Permission Grant Example 1: User-Specific Information) Next, referring to Figures 14(A) to 14(D), an example of permission granting mode 1, in which permission to participate in an event is granted to a user based on the granting of predetermined targets such as the items in Figure 13 to the user, will be explained. Figures 14(A) to 14(D) are examples of individual user information associated with the user ID managed by the distribution server 100 as user data 121. Figures 14(A) and 14(C) are examples of database information that manages information for identifying owned items for each user. An item ID is associated with each user ID as information that identifies the granted items (owned item identification information). Figure 14(C) is a diagram showing an example of database information after the information identifying that user "U2" in Figure 14(A) owns the owned item "IT01" has been deleted.

[0093] Figures 14(B) and 14(D) are examples of database information that manages information (permission information, permission information) for identifying each user's permission to participate in events. For example, if "IT01" in Figure 13(A) is assigned to a user, information identifying the rights, such as the associated event ID "EV01", is managed by associating it with the user ID as permission information. Figure 14(B) shows the information regarding participation permissions managed at the time shown in Figure 14(A), and Figure 14(D) shows the information regarding participation permissions after the individual information about owned items has reached the state shown in Figure 14(C).

[0094] In this embodiment, when a user is granted a predetermined object such as an item, the user is granted the right to participate in the event associated with that item as an authority. However, the information used to identify the user's authority to participate in the event is managed independently and is not associated with the item granted to the user. For example, suppose user "U2" as shown in Figure 14(A) transfers item A, item ID "IT01," to another user, resulting in user "U2" no longer owning item A, and it is deleted as shown in Figure 14(C). However, as shown in Figure 14(D), the authority information (event ID "EV01," etc.) used to identify user "U2's" authority to participate in event A, which was granted based on the acquisition of item A, remains associated with user U2. Therefore, even if a user no longer owns the item that triggered the acquisition of the authority to participate in the event, the authority information referenced in determining the existence of the authority remains independent of the item's ownership status, and the user can still participate in the event. In addition to transfers, other ways in which an item may become unowned include, for example, discarding or consuming it. These actions can also be managed as unowned items (by deleting consumed items from the user's individual information). Furthermore, instead of simply deleting from the database, an unavailable flag can be turned on to treat an item as unowned, preventing the user from using consumed items.

[0095] Furthermore, as a method for obtaining permission to participate in the same event (an event with the same content held at the same venue on the same date and time), in parallel with the method of granting permission based on item purchase, it is also possible to grant permission to users by completing predetermined missions within the game, or by allowing users to be granted permission through a route different from the route based on item acquisition (granting of predetermined targets). In other words, a method in which only permission is granted without granting predetermined targets may also be implemented in parallel. In the virtual space provision system 1 of this embodiment, as shown in Figure 14(B), the presence or absence of permission is determined based on permission information associated with the user's individual information, rather than the item ownership status. This allows for flexible management of permissions while still providing an experience in which participation permission to an event is granted based on item purchase.

[0096] (Permission granting method 1: Permission determination based on individual user information) Referring to Figures 15(A), 15(B), and 16, we will provide a more detailed explanation of the example of user authorization mode 1 described in Figures 14(A) to 14(D), and the determination of event participation rights based on authorization mode 1. Figure 15(A) is an example flowchart for explaining the process of associating authorization information with individual user information in authorization mode 1, and Figure 15(B) is an example flowchart for explaining the process of granting event rights based on authorization mode 1. Figure 16 is a diagram that explains an example screen of user terminal 300 in authorization mode 1 on the left and the concept of the processing flow in distribution server 100 on the right.

[0097] The process shown in Figure 15(A) is repeatedly executed by the control unit 130 (user management unit 133, etc.) based on the user's request for item purchase processing. The distribution server 100 executes the processing of authorization grant mode 1 based on the program stored in the storage unit 120.

[0098] First, in Figure 15(A), in step S101, event-related purchase processing is executed based on the user's item purchase operation. For example, when a purchase operation for "Item A" in Figure 13 is performed at an item shop set up in the virtual space on the user terminal 300, purchase request information is sent from the user terminal 300 to the distribution server 100, and payment processing is executed.

[0099] Once the payment processing is complete, step S102A updates the user's individual information by adding the relevant item (e.g., Item A) to the user's individual information and adding information about permissions based on the rights associated with the item. For example, when the purchase of Item A requested by the user is processed, as shown in the upper left of Figure 16, the user terminal 300 displays information notifying that the purchase of Item A has been completed, and further displays information notifying that the user can now participate in Event A by purchasing Item A. Based on this purchase process, the distribution server 100 updates the individual information by adding the purchased Item A to the user's individual information (user data 121), as shown in the upper right of Figure 16, in association with the ID of the user who performed the purchase, for example, in the user's owned item information management database exemplified in Figure 14(A). As a result, Item A is assigned to the purchaser user U1. Furthermore, the rights identification information (event ID) associated with the item ID, as shown in Figure 13, is added to the ID of the user who performed the purchase operation for item A in the user-specific permission information management database exemplified in Figure 14(B), as user-specific information (user data 121), and the individual information is updated. As a result, information that identifies whether or not a predetermined target (e.g., item A) available in the virtual space for which the user performed the purchase operation has been granted (e.g., owned item identification information such as the user-specific item ID in Figure 14(A)) and information regarding the right to participate in the event (e.g., permission information such as the user-specific event ID in Figure 14(B)) are managed as different information.

[0100] Next, referring to Figure 15(B), the determination of permission to participate in the event based on the permissions granted in Figure 15(A) will be explained. The permission determination process is repeatedly executed by the control unit 130 (content management unit 131, etc.) based on request information from the user terminal 300. The distribution server 100 executes the permission determination process based on the program stored in the storage unit 120. Note that the determination process in step S201 may be repeatedly executed at predetermined time intervals.

[0101] In step S201 of Figure 15(B), it is determined whether or not a viewing request (a request to participate in an event) has been made for a predetermined area. The predetermined area is, for example, venue A where event A is held. For example, as shown in the middle left of Figure 16, based on the user terminal 300 selecting venue A (for example, main area A in Figure 6) from the venue list (for example, the main area list in Figure 6), a viewing request for venue A (predetermined area) is sent from the user terminal 300 to the distribution server 100. When the distribution server 100 receives the viewing request information from the user terminal 300, it determines in step S201 that a viewing request for the predetermined area has been made. If it is not determined in step S201 that a viewing request has been made, the process ends.

[0102] On the other hand, if it is determined in step S201 that a viewing request has been made, in step S202A it is determined whether the user has the authority to receive information about the requested designated area (authority to participate in the event). If it is determined that the user has the authority, in step S203 permission is granted to provide the information about the requested designated area to the user who made the request, and in step S204 the information about the requested designated area is provided. For example, as shown in Figure 16, the distribution server 100 refers to user data 121, etc., and determines whether the individual information of the user who sent the viewing request is associated with information that identifies the authority to participate in event A held at venue A (authority to view). For example, if a request is received from user "U1" in Figure 14(B), since the ID of event A "EV01" is associated with the individual information of user "U1" as authority information, it is determined that the user has the authority to receive information about the designated area (venue A), and permission is granted to provide the information about the designated area to the user who made the request. For example, the content management unit 131 authorizes the data distribution unit 132 to provide information about a predetermined area to the user. As a result, virtual space generation data for venue A (including data for rendering a virtual space equivalent to venue A so that the user can view and experience event A) is distributed to the user terminal 300 of the user who made the request. Upon receiving the virtual space generation data distributed in step S204, the user terminal 300 renders venue A, as shown in the lower left of Figure 16, and becomes able to experience and view the effects of event A.

[0103] On the other hand, in step S202A of Figure 15(B), if it cannot be determined that the user's individual information is associated with the authority to receive information for the requested designated area, then in step S205, a rejection process is executed for the user who made the request to receive information for the requested designated area. For example, information such as a notification that the user does not have the right to participate and therefore cannot enter is sent from the distribution server 100 to the user terminal 300. Alternatively, the rejection process may involve transitioning the user to a screen where they can purchase items such as those shown in Figure 13, which grant the right to participate in the rejected event.

[0104] Thus, when determining whether a user who has made a viewing request has the right to participate, even if information specifying whether or not the predetermined target that triggered the granting of that right is not associated with the user, if information regarding the user's participation rights is included in the user's individual information, the user's participation (viewing) will be permitted.

[0105] As explained above with reference to Figures 14(A) to 16, when participation rights (information identifying rights) that were granted to a predetermined first target (item, etc.) are transferred to another second target (individual information (user ID, etc.)) (for example, a digital code identifying rights that was granted to an item is granted to the user ID as an authority), participation rights are managed separately from the target that triggered the granting of those rights. As a result, even if a user no longer owns an item, such as user U2 in Figures 14(A) to 14(D), participation rights can be retained, and permission to provide virtual space information based on the target granted to the user can be handled more flexibly.

[0106] (Authorization Method 2: List of Authorized Persons) Next, referring to Figures 17(A) to 17(D), an example of permission granting method 2 will be explained, in which the right to participate in an event is granted to a user by adding the user ID to the permission holder list based on the granting of predetermined targets such as the items in Figure 13 to the user. Figures 17(A) to 17(D) are examples of information in the database of the permission holder list (authority holder roster) used to identify users who have been granted the right to participate in each event described in Figure 12(A), etc., which is managed by the distribution server 100 as event data, etc. of the provided content data 123. For each event (for example, for each event ID), the user ID with the authority is associated as information about the authority (authority information). In addition, as shown in Figures 17(A) to 17(C), information about each user's seat rank may also be associated as information about the authority. Furthermore, as shown in Figure 17(C), the same event may be held at different times, and different period information may be included in the authority information, and user authority may be managed for each different period information. The term "same event" includes, for example, a re-run of Event A with the same title, an event with the same title but with changes to the performers, music, or other content, and events in a series. For information regarding the duration, please refer to Figure 20, which will be discussed later.

[0107] Furthermore, by managing information about permissions in the permission holder list, it becomes easier to grant and manage participation rights to users through means other than item purchase (item granting). For example, in Figure 17(B), user ID "SP1" is a performer user, and "STAFF1" is an administrator user. In this way, it becomes possible to centrally manage users who participate in the designated area where the event is held, such as special users different from general users, or users acting as administrators, regardless of whether they have been granted the specified items, etc., as shown in Figure 13. Also, even for general users, if a system is adopted that allows participation rights to be granted through means other than item purchase (in parallel with item purchase), managing permissions in the permission holder list makes permission management easier. For example, in parallel with the method of granting permissions based on item purchase for the same event, it becomes possible to centrally manage users who have been granted participation rights through different routes, such as adding users who have acquired permissions by clearing specified missions in the game, or users whose permissions have been decided through a lottery or a gift campaign by the administrator.

[0108] In this embodiment, similar to the example of authorization method 1, when a predetermined target such as an item is granted to a user, the user is granted the right to participate in the event associated with that item as an authorization. However, the information for identifying the right to participate in the event is not associated with the user's owned items, but is managed in the owner list illustrated in Figures 17(A) to 17(C). For example, suppose user "U2" in Figures 14(A) and 14(C) does not own the item "IT01" and it is deleted as shown in Figure 14(C). However, the right to participate in "EV01" for user U2, which was granted based on the acquisition of item "IT01", remains associated with the owner list such as Figures 17(A) and 17(C) as authorization information. Therefore, even a user who no longer owns the item that triggered the acquisition of the right to participate in the event can still participate in the event.

[0109] (Permission decision based on the list of authorized holders) Referring to Figures 18(A), 18(B), and 19, we will provide a more detailed explanation of the authorization mode 2 and the determination of event participation rights based on authorization mode 2, as explained with reference to Figures 17(A) to 17(C). Figure 18(A) is a flowchart illustrating the process of associating authorization information with the authorization holder list in authorization mode 2, and Figure 18(B) is an example flowchart illustrating the process of granting event rights in authorization mode 2. Figure 18(A) and the aforementioned Figure 15(A), and Figure 18(B) and the aforementioned Figure 15(B) differ in the parts enclosed by dotted lines, but are otherwise common. Figure 19 is a diagram illustrating an example screen of user terminal 300 in authorization mode 2 on the left and illustrating the concept of the processing flow in distribution server 100 on the right.

[0110] The process shown in Figure 18(A) is repeatedly executed by the control unit 130 (user management unit 133, etc.) based on the user's request for item purchase processing. The distribution server 100 executes the processing of authorization grant mode 2 based on the program stored in the storage unit 120.

[0111] First, as in Figure 15(A), when the event-related target purchase process is executed in step S101, in Figure 18(A), in step S102B, the process is executed to add and update the target to the user's individual information, and to add and update the information regarding the user's rights associated with the target to the list of holders of the right to receive information in a predetermined area (list of holders of participation rights). For example, when the user terminal 300 completes the payment process based on the purchase operation of "Item A" shown in Figure 13 at an item shop set up in the virtual space, in step S102B, as in step S102A in Figure 15(A), the process is executed to add the target (for example, Item A) to the user's individual information as an owned item. For example, when the purchase process for Item A requested by the user is completed, as in Figure 16, information indicating that the purchase process for Item A has been completed is displayed on the user terminal 300, as shown on the left side of Figure 19. At this time, as shown in the upper right of Figure 19, the distribution server 100 updates the individual information by adding the purchased item A to the user ID that performed the purchase operation in the user-specific item information management database, for example, as exemplified in Figure 14(A). As a result, item A is assigned to the purchaser user U1, similar to the example in Figure 16. The distribution server 100 also identifies a list of persons with the right to participate in event A, as exemplified in Figure 17(A), based on rights information such as the event ID associated with each item exemplified in Figure 13, and adds the user ID that performed the purchase operation for item A to the list of persons with the right to participate in event A, associating it with the right information, thereby updating the list of persons with the right to participate (event user roster). As a result, the information that identifies whether or not a predetermined target (for example, item A) available in the virtual space where the user performed the purchase operation has been assigned (for example, the user-specific item ID in Figure 14(A)) and the information regarding the right to participate in the event (for example, the user ID associated with the list of persons with the right to participate in event A in Figure 17(A)) are managed as different information.

[0112] Next, Figure 18(B) will explain the determination of permission to participate in an event based on the permissions granted in Figure 18(A). In step S201 of Figure 18(B), it is determined whether or not there has been a request to view a predetermined area, similar to step S201 of Figure 15(B). If it is determined in step S201 that there has been a request to view, then in step S202B of Figure 18(B), it is determined whether or not the user's user identification information (such as a user ID) is in the list of persons authorized to receive information about the requested predetermined area. The processing after it is determined that permission is granted, and the processing after it is determined in step S202B that permission is not granted, are the same as in Figure 15(B). For example, as shown in Figure 19, the distribution server 100 refers to the event data of the provided content data 123, etc., and determines whether or not the user ID of the user who sent the participation request is associated with the event user list (authority holder list). For example, if a request is received from user U1 in Figure 17(A), the system refers to the list of authorized event data holders. If the ID of user U1 can be identified, it is determined that the user has the authority to receive information about a predetermined area (venue A), and permission is granted to provide the information about the predetermined area to the user who made the request. As a result, virtual space generation data, including data that allows venue A to be rendered and enabling viewing and experiencing event A, is delivered to the user terminal 300 of the user who made the request. Upon receiving the virtual space generation data delivered in step S204, the user terminal 300 can render venue A, as shown in the lower left of Figure 19. In this way, when determining whether a user who made a viewing request has participation rights, even if information specifying whether the predetermined target that triggered the granting of such rights has been granted is not associated with the user, if information regarding the user's participation rights is included in the list of authorized holders, the user's participation (viewing) is permitted.

[0113] As explained above with reference to Figures 17(A) to 19, the participation rights (information identifying the rights) that were granted to a predetermined first target (item, etc.) are transferred to another second target (list of event participation rights holders, etc.) (for example, information linking the purchaser user's ID to the digital code attached to the item is linked to the rights holder list), so that the participation rights are managed separately from the target that triggered the granting of the rights. As a result, even if a user no longer owns an item, such as user U2 in Figures 14(A) and 14(C), the participation rights can be retained, and permission to provide virtual space information based on the target granted to the user can be handled more flexibly.

[0114] (Permission decision including period information) Next, referring to Figure 20, an example of permission processing for event participation in this embodiment will be explained, specifically when the permission is determined by also referring to the period information included in the authorization information. Figure 20 differs from the permission processing described in Figure 18(B) in step S202C, which is enclosed by a dotted line, but is otherwise common. The difference from Figure 18(B) is that in step S202B, if the distribution server 100 determines that the user who made the viewing request is included in the holder list shown in Figure 17(C), then in step S202C, it is determined whether the period information of the holder list and the current timing information (for example, current information, such as date and time, day of the week, etc., which specifies the information of the current time) are consistent. If the period information of the holder list and the current timing information are consistent in step S202C, the process proceeds to step S203, and permission processing is performed. On the other hand, if it is not determined that they are consistent in step S202C, rejection processing is performed in step S205. In this way, even for the same venue or the same event (same title), it becomes possible to set up user lists according to the duration of the event, such as patterns with different performers, events with the same title but held multiple times, or events with sub-themes related to each season, making event management easier. For example, if a start date and time are specified in the duration information of the owner list, then from the start date and time onward (for example, until the event is closed by the administrator and access is made impossible), it may be determined that the timing information of the user's viewing request is after the start date and time, and that it is consistent with the event period. Also, if the duration information specifies a schedule spanning multiple days (times may also be specified), then it may be determined that it is consistent if the timing information of the user's viewing request is within that schedule. In this way, if it is determined that the current timing information of the user's viewing request falls within the specified period, permission can be granted.

[0115] Furthermore, permission may be granted if the period information in the holder list associated with the user making the viewing request matches the current timing information, so the order of determination is not limited to this. For example, when a viewing request is made, the system may refer to the period information data that matches the current timing in the holder list (or in the user's individual information) and determine whether the user making the viewing request is included in the user list associated with that period information.

[0116] Furthermore, while Figure 20 illustrates an example of determination based on the holder list in Figure 18(B) used in the explanation of authorization method 2, in the example of authorization method 1, permission processing may also be performed based on whether the period information included in the authorization information matches the current information at the time of the user's viewing request. For example, in step S202A of Figure 15(B), when the authorization information corresponding to the requested predetermined area is identified within the individual information, a determination may be made as to whether the period information associated with the identified authorization information (e.g., event ID) as exemplified in Figure 14(B) matches the current timing. Alternatively, the period information of the corresponding event, such as that shown in Figure 12(A) identified based on the event ID of the authorization information identified in Figure 14(B), may be referenced, and a determination may be made as to whether the current timing matches the said period information.

[0117] Furthermore, when determining eligibility to participate in an event, the system may refer only to the time period information included in the eligibility information to determine if it matches the current timing information. If it matches, the system may grant the user who made the viewing request permission to participate in the event (provide information about the virtual space where the event is offered). For example, if only time period information (or other information) is associated with the individual information in Figure 14(B), and a viewing request is made by a user, the system may refer to the time period information included in the individual information and grant permission if it matches the current time.

[0118] (Sub-event) Next, we will explain the details of sub-events with reference to Figures 21(A) to 21(D), Figure 22(A), and Figure 22(B). In this embodiment, the right to participate in the main event (first right) and the right to participate in sub-events (second right) are different rights. In this embodiment, even if a user can identify information regarding the right to participate in the main event (first right) (for example, the event ID in the rights information in Figure 21(A), the user ID included in the list of authorized holders for the main event in Figure 21(B), etc.), they will not be allowed to participate in the sub-event if they cannot identify information regarding the right to participate in the sub-event (second right).

[0119] Figure 21(A) is an example of permission information included in the individual user information managed as user data 121 in the case of permission granting method 1, which was explained with reference to Figures 14(A) to 16. As shown in Figure 21(A), the permission information associated with the individual user information may include not only information to identify the permission to participate in the main event (first permission) (such as the event ID), but also information to identify the permission to participate in sub-events (second permission) (such as the sub-event ID and sub-event name). For example, user "U1" in Figure 21(A) has information to identify the permission to participate in event A in Figure 12(A) (event ID "EV01"), as well as information to identify the permission to participate in the sub-event "Handshake Event" (for example, an identifier for the sub-event "Handshake Event"). On the other hand, in Figure 21(A), user "U2" is associated with information that identifies their right to participate in event A (event ID "EV01"), but not with information that identifies their right to participate in sub-events. Therefore, user "U2" cannot participate in sub-events.

[0120] Furthermore, Figure 21(B) shows an example of the information in the list of authorized users managed as event data, etc., in the case of authorization method 2, which was explained with reference to Figures 17(A) to 19. In Figure 21(B), the user ID associated with the authorization information to participate in event A is further associated with the information of sub-events to which the user has the right to participate. For example, both user "U1" and user "U3" have their user IDs included in the list of users with the right to participate in event A, and are therefore granted the right to participate in the main event, event A (first authority). In other words, information regarding the first authority can be identified for both users. However, user "U1" has "handshake event" (second authority) associated with it as information regarding the right to participate in a sub-event (the user is granted the right to participate in the sub-event), while user "U3" has no information associated with the right to participate in a sub-event (the user is not granted the right to participate in the sub-event).

[0121] The right to participate in these sub-events may be granted to the user based on the acquisition of an item, etc., which is a designated target that triggered the granting of the main event's rights, and the rights information granted to that item also includes the right to participate in the sub-events. Alternatively, the right to participate in the sub-events may be granted to the user based on the user acquiring an item, etc., that is different from the target that triggered the granting of the main event's rights, through separate purchase or other means. In this case, the right associated with the item may be transferred to the user's individual information (user ID in the individual information) or the list of authorized holders. Even in this case, the information used to identify that the designated target that triggered the granting of the sub-event's rights has been granted (for example, the owned item identification information in Figure 14(A)) and the information used to identify the right to participate in the sub-events are different pieces of information.

[0122] Furthermore, in this embodiment, sub-events are described as events provided as after-events (secondary events) after the main event (primary event) has been provided. For example, as shown in Figure 21(C), when the main event has finished, a sub-event information screen 61 may be displayed on the screen showing the venue of the main event, allowing participation in the sub-event. Alternatively, as shown in Figure 21(D), a sub-event room 62 (for example, a building object that functions as a handshake event room) may be placed within the area of ​​the venue in the virtual space where the main event is held, and participation in the sub-event may be made by moving an avatar to the sub-event room 62. The sub-event room 62 in the venue shown in Figure 21(D) corresponds to a predetermined building in the main area, as shown in area 42 in Figure 8(B). However, it is not limited to this, and for example, a predetermined area within the main area, such as area 32 in Figure 8(A) or areas 51 to 53 in Figures 9(A) and 9(B), may be designated as the predetermined area where the sub-event is held. In this way, the sub-events in this embodiment are provided after the information about the main event has been provided.

[0123] Furthermore, the virtual space accessible based on the guidance screen 61 for sub-events in Figure 21(C) may be any of the main areas in Figure 6, any room corresponding to a main area, or areas such as area 32 in Figure 8(A), area 42 in Figure 8(B), or areas 51, 52, and 53 in Figures 9(A) and 9(B) within a predetermined main area. In addition, if a sub-event requires communication with a performer avatar (corresponding to a special user) (for example, a handshake event or a roundtable discussion), it is preferable that the room be synchronized with other users, as explained with reference to Figures 7(A) to 7(C). In other words, it is a room in which special users and general users participating in the sub-event can be synchronized. Note that a room specially set up for sub-events may be managed as provided content data 123, and access to the sub-event room, which is normally inaccessible, may be made available when the event is released.

[0124] Next, we will explain how permission to participate in a sub-event is determined, referring to Figures 22(A) and 22(B). Figure 22(A) is an example where information regarding participation rights in a sub-event is associated with the user's individual information, as shown in Figure 21(A) (Permission Granting Mode 1), and Figure 22(B) is an example where information regarding participation rights in a sub-event is associated with the list of authorized holders, as shown in Figure 21(B) (Permission Granting Mode 2). Note that participation rights in a sub-event will be explained as being granted along with the participation rights in the main event, as exemplified in Figures 15(A) and 18(A).

[0125] The permission determination process is repeatedly performed by the control unit 130 (content management unit 131, etc.) based on request information from the user terminal 300. The distribution server 100 performs the permission determination process based on the program stored in the storage unit 120. The determination process in step S201 may be repeatedly performed at predetermined time intervals.

[0126] In step S301 of Figure 22(A), it is determined whether or not there has been a viewing request (viewing request or participation request) for a predetermined area where the second event is provided. For example, when an operation is performed on the guidance screen 61 shown in Figure 21(C) displayed on the screen of the user terminal 300 that provides the virtual space of venue A where the main event A is held (for example, when the entry button is pressed), viewing request (participation request) information is sent to the distribution server 100. Alternatively, viewing request information may be sent from the user terminal 300 to the distribution server 100 when an operation that triggers movement is performed, such as an entry request to the sub-event room 62 in Figure 21(D) (such as an operation on the door object or an avatar movement operation). When the distribution server 100 receives viewing request information from the user terminal 300, it is determined in step S301 that there has been a viewing request for a predetermined area where the second event is provided. If it is not determined in step S301 that there has been a viewing request, the process ends.

[0127] On the other hand, if it is determined in step S301 that a viewing request has been made, in step S302A it is determined whether the user has the authority to receive information about the area where the requested second event is provided (information about the second event). If it is determined that the user has the authority, in step S203 permission is granted to provide information about the area where the requested second event is provided, and in step S204 the information about the area where the requested second event is provided is provided. For example, the distribution server 100, similar to the determination of participation rights in the main event in Figure 15(B) and Figure 16, refers to the user data 121 and determines whether participation rights in sub-events (information that can identify participation rights in events such as handshake events) are associated with the individual information of the user who sent the viewing request. For example, if the distribution server 100 receives a request from user "U1" in Figure 21(A), the server determines that user "U1" has the authority to receive information about the area where the sub-event "EV01" is provided (information about the second event) because the sub-event of the event "EV01" is associated with the individual information of user "U1". The server then grants permission to the user who made the request to receive information about the designated area where the sub-event is provided. As a result, virtual space generation data, including data to render a virtual space corresponding to the venue of the sub-event and data for the sub-event's presentation, is distributed to the user terminal 300 of the user who made the request.

[0128] On the other hand, if, in step S302A of Figure 22(A), it is not possible to determine that the user's individual information is associated with the authority to receive information about the requested second event, then, similar to step S205 of Figure 15(B), the process of refusing to provide information about the area where the requested second event is provided is executed in step S305, and the process terminates.

[0129] Next, we will refer to Figure 22(B) to explain an example of permission processing based on the list of authorized users. Figure 22(B) differs from Figure 22(A) in step S302B, which is enclosed by a dotted line, but is otherwise the same and will not be explained further. In Figure 22(B), after the distribution server 100 determines in step S301 that there has been a request to view the second event, in step S302 it is determined whether the user in question, who is in the list of users authorized to receive information about the first event, has the authority to receive information about the second event. In other words, it is determined whether the user in the list of users authorized to receive information about the first event (main event) in a predetermined area (first authority) also has the authority to receive information about the second event (sub-event) in a predetermined area (second authority). For example, the distribution server 100, similar to the process for determining participation authority for the main event as explained in Figure 19, refers to the event user list (authorized user list) of the event data in the provided content data 123 and determines whether information regarding participation authority for the sub-event is associated with the user ID of the user who sent the viewing request. If the holder list includes information regarding the user's permission to participate in the sub-event, it is determined that the user has the right to receive information from the designated area where the second event is provided, and the sub-event information is provided to the user.

[0130] <Variations of the participation permission determination process> The following describes some variations of the process for determining participation rights.

[0131] (Regarding event information and permission information) In the embodiment described above, an example was explained in which the details of the event, such as the venue, are determined for each event, with reference to Figure 12(A). However, as illustrated in Figure 23(A), the details of the event may be determined for each venue (for example, Venue A, Venue B, etc.). For example, events with the same title, such as Event A in Venue A, which is a designated area, may be scheduled on different dates. Also, as shown in Figure 23(A), even events with the same title (theme, etc.) may differ in whether or not they have sub-events. Furthermore, the same event may be held at different venues on different dates. For example, Event A in Figure 23(A) (for example, a live event by a specific talent) may include dates held at Venue A and dates held at Venue B.

[0132] Furthermore, even if the rights granted to the event described in the above embodiment with reference to Figure 13 are the same, the rights may differ depending on the type of item (e.g., nature, price, rarity, etc.). In addition, while an event ID was used as an example of information to identify the event participation rights granted to the specified items, information such as the event venue, seat rank, participation rights to sub-events, and duration information may be associated with the item, as long as it identifies the rights. For example, item A and item B in Figure 23(B) are granted participation rights to the same event because their venue and duration information match, but their seat ranks are different (A seat and B seat). Also, item A is granted participation rights to a handshake event, while item B is not. Note that the duration information used to determine the duration information described above with reference to Figure 20 may be included in the rights information for each specified item in Figure 23(B), so that users are granted participation rights to events corresponding to the duration information. Thus, the user experience (the performance-related processing provided to the user) at an event may differ depending on the type of item, etc.

[0133] Furthermore, certain items corresponding to special users who will be performers at the event may be included in object data 122 as targets to which participation rights for the event have been granted. For example, an item granting participation rights to an event featuring performer A may include items related to performer A and items unrelated to performer A, so that the event experience (the performance-related processing provided) differs between users who purchase items related to performer A and users who purchase items unrelated to performer A. For example, users who purchase items related to performer A may be assigned seats closer to performer A. Items related to performer A may include, for example, a T-shirt that can be worn by an avatar displaying an illustration of performer A, or a support effect for performer A that can be used during the event (for example, a fan mark image that can be placed in the venue). Also, in events with multiple performers and multiple stages, or when the stage width is wide, the seats of users who purchase items related to performers may be set to seats closer to the stage (location) where the most performers corresponding to the items are scheduled to be placed.

[0134] Furthermore, in the embodiment described above, an example was explained in which an event ID is associated with information for identifying a user's individual information's right to participate in an event, with reference to Figure 14(B), etc. This information for identifying the right may also include, for example, information that identifies the event venue, seat rank, and duration, which were assigned to the item as information about the right to participate (information identifying the right). In this case, for example, in determining the right in Figure 15(B), if the event information set for the venue, such as in Figure 23(A), matches the right information associated with the individual information, the provision of information may be permitted, and if there is even one mismatch, a rejection process may be performed.

[0135] Furthermore, in the embodiments described above, an example was shown in which a list of authorized persons is managed for each event with reference to Figure 17, etc. However, the list of authorized persons may be organized by venue (or predetermined area), as shown in Figure 23(D), with the user IDs of those with authority associated as authority-related information (authority information). For example, the list of authorized persons for each venue may include user IDs, event names, seat ranks, dates, etc., as authority information, and be managed in association with each other (it may also be a user list for each event for each venue). At a minimum, a list that allows users to refer to authorized persons when participating in an event, with user IDs associated as authority information, can be used in authorization granting mode 2. Also, as shown in Figure 23(D), similar to Figure 17(C), the authority-related information in the list of authorized persons may include information on the period during which each event is held. For example, if different events are held in the same designated area (e.g., venue A), or if the same event (events with the same title, etc.) is held at different times, by including different time period information in the permission information, in addition to checking if the user ID is included in the list, entry can be permitted only when the current information matches the time period information. This makes permission determination processing and management of participation history, etc., as described later in Figure 25, easier.

[0136] Furthermore, in the above-described embodiment, an example was explained in which the permission information that identifies the right to participate in an event (information regarding the right to receive information in a predetermined area) may include the event ID, information about the event venue, seat rank, etc. However, the content of the information regarding the right to receive information in a predetermined area is not limited to this, and may also include, for example, information regarding the right to view virtual cameras located within the predetermined area. Virtual cameras located within the predetermined area include virtual cameras that provide an overview of the entire venue (overhead cameras) and virtual cameras that follow and film only special users (e.g., specific talents) (performer-following cameras). The viewpoints of these virtual cameras may be different from the viewpoint from which the user avatar is placed (referred to as special viewpoints). Multiple virtual cameras with special viewpoints, such as overhead cameras and performer-following cameras, may be placed within the predetermined area, and the permission information may include information that identifies which of the multiple virtual cameras are viewable. For example, the rights information associated with a predetermined object, such as an item, as explained in Figures 13 and 23(B), may include information for identifying these viewable virtual cameras. Furthermore, information identifying different types of virtual cameras may be associated with each item. Also, when the distribution server 100 performs the determination of whether the user who made the viewing request has been granted permission, as described in step S202A in Figure 15(B) and step S202B in Figure 18(B), if it can identify information regarding viewing permission for viewable virtual cameras (the right to receive information to identify the viewpoint of a special camera) included in the permission information associated as the individual user information in Figure 14(B) and Figure 23(C), it may make the video based on the viewpoint of the special camera for which viewing has been permitted possible, available for display on the user terminal 300.

[0137] Furthermore, these special viewpoint virtual cameras may be operated by a camera operator user different from the viewing user (for example, a staff user on the management side), or they may be virtual cameras that automatically move their viewpoint based on a predetermined program. For example, information for identifying a fixed viewpoint, such as the position and orientation of the special viewpoint virtual camera, may be distributed to the user terminal 300 that becomes the viewer, and some of the information for identifying the viewpoint (for example, position information) may be distributed, while some of the information (for example, orientation) may be changeable by the viewer user through operations on the user terminal 300. In addition, the view of the avatar corresponding to the viewer user and the view of the virtual camera from the special viewpoint may be switched on and off according to the user's preference through operations on the user terminal 300.

[0138] (Regarding the granting of participation rights) In the embodiment described above, when an item (a predetermined target) as explained in Figure 13 is granted, the right to participate in an event (information regarding the right to identify whether participation rights have been granted) that was attached to the item becomes a participation right and is always granted to the user. However, this is not the only example; even if an item is granted through purchase or other means, the participation right attached to the item may not be granted to the user. For example, when an item is purchased, the right to participate in an event may be granted by lottery. For example, the right to participate may be granted with a 50 percent probability, and the probability of being granted may be 50 percent, higher than 50 percent, or lower than 50 percent.

[0139] Furthermore, in the embodiments described above, with reference to Figures 15(A), 18(A), etc., an example was explained in which a predetermined target such as an item is granted to a user, that is, when the process of granting the item to the user is executed, the process of granting the user the right to participate in the event is executed. However, the invention is not limited to this, and the timing of granting the item to the user and the timing of granting the user the right to participate in the event may be different. For example, the granting of the right to participate in the event may be executed after a predetermined period has elapsed (e.g., 30 seconds, 24 hours, etc.) since the item was associated with the user's individual information. For example, the association with the user's individual information, such as in Figure 14(B), or the association with the list of authorized holders, such as in Figure 17(A), may occur after a predetermined period has elapsed since the item was granted, or the associated individual information or the authorization information in the list of authorized holders may be activated after a predetermined period has elapsed. Conversely, the process of associating the item with the user's individual information may be executed after a predetermined period has elapsed since the item purchase process (after obtaining the predetermined target) and after the granting of the right to participate in the event. For example, after participating in an event, information identifying whether or not you own the purchased items could be activated during the event, and these items could only be used during the event.

[0140] (Changes in the content of rights) As described in the above embodiment, after a user is granted the right to participate in an event based on an item purchase, etc. (for example, after permission information is associated with the user's individual information, and after the user ID, etc., is associated with the permission holder list), the content of the permission information may be changed in multiple stages. For example, even if the user is granted the right to view from a general rank seat at the time of item purchase (when participation rights are granted), if the user fulfills conditions for updating permission information, such as completing missions in games, winning lotteries, or making payments, the seat rank may be upgraded to a higher rank, thereby updating the user's individual information or the permission information in the permission holder list.

[0141] (Regarding information for identifying the specified target) In the embodiment described above, as illustrated in Figure 14(A), we explained an example where information for identifying whether or not an item (a predetermined target) that triggered the granting of event participation rights has been granted (owned item identification information) is managed without being associated with information regarding the rights to identify event participation rights (for example, the rights information in Figure 14(B)). However, this is not the only example; for example, even if information regarding rights is associated with a predetermined target and linked to the user's individual information, the information regarding rights associated with that predetermined target may not be referenced as event participation rights. For example, when the item in Figure 13 is purchased, it may be associated with the user's individual information in Figure 14(A) as owned item information, along with the rights information (event ID) that identifies the participation rights, and the rights information that identifies the participation rights may be copied and managed associated with the rights information in Figure 14(B). As a result, even if the rights information (such as the event ID) associated with the item exemplified in Figure 13 remains associated with the item ID of the owned item identification information such as in Figure 14(A), when determining whether or not the user has the right to participate in the event in step S202A of Figure 15(B) or step S202B of Figure 18(B), the information that identifies whether or not the item is granted (the database in Figure 14(A)) is not referenced. Instead, information for identifying the rights information (individual information in Figure 14(B) or the owner list in Figure 17(A)) is referenced. Therefore, it becomes easier to manage rights information that is not related to the ownership status of the item.

[0142] Furthermore, in the above-described embodiment, as illustrated in Figures 13 and 23(B), the right to participate in an event (information for identifying the right) is granted to a predetermined object such as an item, and when the item is purchased by the user, the item is granted (Figure 14(A)), and the right that was granted to the item is transferred to the user's individual information rights as the right to participate in the event. However, the embodiment is not limited to this, and when a predetermined object such as an item that triggers the granting of the right is purchased, the granting of the item to the user and the granting of entry rights may be performed simultaneously. Specifically, the item and entry rights may be sold as a set, and when the purchase process of the item is performed based on user operation, the purchased item may be associated with the user's owned item identification information (Figure 14(A)), and the right to participate in the event, which was sold as set data with the item, may be associated with the user's permission information (Figure 14(B)).

[0143] Alternatively, instead of transferring rights associated with items, the system may use the acquisition of a predetermined item (or the granting of the predetermined item) as a trigger to turn on a flag related to event participation rights. In Figure 15(B), when determining participation rights, the system may determine whether or not the rights exist based on whether or not this flag is turned on (enabled). For example, an item related to event participation rights may be provided in the individual user information managed as user data 121 (for example, through an operation on the administrator terminal 200), and the user management unit 133 may use the acquisition of a predetermined item (for example, granted to the user after completing a predetermined mission) as a trigger to turn on the flag for that event item. In other words, information regarding event participation rights is indicated by the flag being turned on (enabled), and the virtual space provision system 1 grants permission to participate in the event to a user who has made a viewing request (participation request), provided that the flag in the user's individual information is turned on. Note that the event item may be set for each specific event whose holding has been decided. For example, there may be separate flag fields for information regarding the permissions of Event A and information regarding the permissions of Event B, which is different from Event A.

[0144] (Regarding sub-events) In the embodiment described above, with reference to Figures 22(A) and 22(B), the determination of whether information regarding the right to participate in the second event (the right to receive information about the predetermined area where the second event is provided) can be identified in steps S302A and S302B is explained as being performed in step S301 when a request to view the second event is made. However, the process is not limited to this, and at the timing of identifying information regarding the right to participate in the main event (first event) (such as step S202A in Figure 15(B) and step S202B in Figure 18(B)), the right to participate in the sub-event may also be determined and permitted at the same time. If the permission determination is performed first, for example, the guidance screen 61 that allows transition to the sub-event room in Figure 21(C) and the sub-event room 62 in Figure 21(D) may be displayed only to users who have been permitted to participate in the sub-event after the event has ended. Alternatively, only users who have the right to participate in the sub-event may be automatically transitioned (automatically connected) to the predetermined room (predetermined area) where the sub-event is provided after the event has ended.

[0145] Furthermore, users who have permission to participate in sub-events may be assumed to also have permission to participate in the main event, and users who do not have permission to participate in the main event but have permission to participate in sub-events may be included. Also, it may be possible to make it so that users cannot participate in sub-events unless they go through the main event (for example, the main event venue), and it may be possible to participate only in sub-events without participating in the main event, even if they have permission.

[0146] Furthermore, Figures 21(A) and 21(B) illustrate an example where information regarding participation rights to the main event (first privilege) and information regarding participation rights to sub-events (second privilege) are associated. However, this is not the only example; the information regarding the first privilege and the information regarding the second privilege may be managed as independent privilege information. For example, as privilege information that is not associated with the individual user information exemplified in Figure 14(B), they may be managed independently as user data 121, associated with the user ID. Also, the list of participants with participation rights exemplified in Figure 17(A) may be managed as separate privilege information for the list of first privilege holders and the list of second privilege holders. This makes it easier to manage, for example, users who only participate in sub-events (e.g., secret performer users (special users) who only participate in sub-events).

[0147] (Other examples of the specified target) Referring to Figures 24(A) to 24(D) and Figure 13, other examples of predetermined objects that can be used by a user in the virtual space in the above-described embodiment and that can grant the user the right to participate in the event in this embodiment will be explained. In Figure 13, an example was shown in which the object that triggers the granting of the right to participate in the event to a user is an item. However, the predetermined object to which the right to participate is associated may be an object that affects the user's status, such as a character (which may be the same as an avatar) that the user operates in the virtual space, or equipment (items). Objects related to status include, for example, parameters that improve HP, attack power, speed, etc., and skills. Objects related to status may be granted based on a purchase operation by the user, similar to items, or they may be granted without a purchase operation, for example, by clearing a predetermined mission, winning a lottery, participating in a giveaway from the operator, or being transferred from another user. In addition, by purchasing and acquiring a predetermined item (for example, a berry that improves parameters), parameter changes or skill granting may occur as an effect of the predetermined item.

[0148] Figures 24(A) and 24(B) are examples of database information that affects the user status, which is managed as object data 122. Figure 24(A) is an example of database information that manages enhancement parameters that improve character parameters, with each enhancement parameter ID associated with an event ID as information regarding the right to participate in an event. For example, parameter A of enhancement parameter ID "P01" is the target that produces the effect of increasing the user character's HP by 20. Figure 24(B) is an example of database information that manages character skills, with each skill ID associated with an event ID as information regarding the right to participate in an event.

[0149] Figure 24(C) shows an example screen on the user terminal 300 when a process is performed to assign a user an object that affects their status. For example, let's explain the case where "Skill A" with skill ID "SK01", which has been granted the right to participate in "Event A" in Figure 24(B), is assigned to the user upon completion of a predetermined mission. When the predetermined mission is completed through user operation or other means (corresponding to step S201 in Figure 15(A)), the distribution server 100 updates the user's individual information in the user data 121 by associating the skill ID to identify Skill A with the user ID, similar to Figure 14(A). In addition, the distribution server 100 associates the information regarding the right to participate in the event (e.g., the event ID) that was assigned to Skill A (associated with the skill ID) with the user ID as permission information, similar to Figure 14(B), and updates the user's individual information (corresponding to step S202A in Figure 15(A)). Furthermore, the user terminal 300 may display information to notify the user that Skill A has been assigned, for example, as shown in the upper left of the user terminal 300 screen in Figure 16. In this case, the name of the acquired target (skill name, etc.) and the name of the event that was assigned along with it may be displayed on the user terminal 300. For example, Figure 24(C) displays "Skill A (Event A) has been acquired!".

[0150] Figure 24(D) is an example of a character status screen displayed on the user terminal 300 (for example, a character affected by changes in parameters used by the user). The display "Attack Power: 40 (+3 / Event D)" in the example screen in Figure 24(D) indicates that some of the 40 total attack power points (3 points) were granted along with the permission to participate in Event D. In addition, the venue and date of the event are displayed together with Skill A. This indicates that Skill A was granted along with the permission to participate in an event held at Venue A on 7 / 1 / 2025. In this way, by displaying the event name, venue name, date, etc., together with the status granted in relation to event participation, it is possible to visualize what kind of event participation permission has been granted by acquiring the target of these skills, etc. Furthermore, even after the event has ended, the user can feel the lingering atmosphere of the event on the status screen, and displays such as Figure 24(C) and Figure 24(D) function as a memento. Furthermore, in both Figure 24(C) and Figure 24(D), it may be possible for the user to toggle the display / hide status (for example, via a pull-down menu). Also, if granting participation rights to different events affects the same status, all effects within the same status may be displayed together, and the user may be able to switch between a display that shows the combined effects and a display that clearly indicates the degree of influence for each event (for example, via a pull-down menu). For example, if the attack power value is affected by both the change based on the user being granted the parameter that grants participation rights to Event A and the change based on the user being granted the parameter that grants participation rights to Event B, it may be possible to switch between a display that clearly indicates the degree of influence for each event, such as "Attack Power: 40 (+5 / Event E, +10 / Event D)", and a display that shows both events together, such as "Attack Power: 40 (+15 / Event Participation))". In this way, the ability to turn it on or off allows users to avoid situations where the display is constantly visible and interferes with gameplay, thus improving convenience.

[0151] Furthermore, regarding the items explained with reference to Figure 13, regardless of whether they were purchased in a shop or elsewhere, users may be granted the right to the designated items through mission completion or promotional giveaways from the operators.

[0152] Furthermore, it is possible to use various objects that are available to the user in the virtual space and can be possessed, discarded, transferred, or consumed, not limited to items that can be equipped or placed, or parameters that affect the status of characters, etc., as the object that triggers the granting of event participation rights (the first object associated with event participation rights). These objects include currency that can be used in the virtual space (for example, purchasing coins within a predetermined period may grant the right to participate in an event). In the above embodiment, an example was described in which the user may no longer own a predetermined object due to transfer, discarding, or consumption, but it is also possible to use an object as the predetermined object that, once owned, cannot be transferred, discarded, consumed, etc., and does not become deleted or unusable. This prevents items from disappearing due to operational errors.

[0153] (Determination based on possession of the specified item) In the embodiment described above, the determination of whether or not a user has the authority to receive information about a predetermined area where events are provided is made not by whether or not they own a predetermined target item, but by referring to the user's individual information and whether or not the authority information is associated with the authority holder list. In addition to this, for example, when providing information about a predetermined area (when a viewing request is made), a process different from the determination of participation authority may be performed depending on whether or not the user owns a predetermined item (item A), etc. (by referring to the information identifying owned items), or whether or not the item is worn or equipped. Different processes may include, for example, making the event presentation different depending on whether or not the user owns a predetermined target item (for example, making the presentation more elaborate than when the item is not owned), or making the actions that can be performed different (for example, making it possible to use different emotes, or to send (speak) voice messages).

[0154] (Regarding how users handle permission information) In the embodiments described above, the items that triggered the granting of event participation rights, such as items, were shown to be able to be discarded, transferred, etc., as explained with reference to Figures 14(A) and 14(C). The permission information (such as the event ID) explained in Figures 14(B) and 14(D), which is different from the ownership item identification information used to determine whether this item has been granted, may also be transferred to other users or discarded. For example, if a list of events for which participation rights are granted can be displayed on the screen of the user terminal 300 (e.g., My Page), and an operation to transfer to another user is performed, the information regarding participation rights to the event to which the transfer operation was performed may be transferred to the individual information of the other user by associating it with the ID of the recipient user as permission information from the permission information such as Figure 14(B) in the individual information of the transferring user. In addition, if a deletion operation is performed, the information regarding participation rights to the event to which the deletion operation was performed may be deleted from the permission information such as Figure 14(B) in the individual information of the transferring user. This allows users to, for example, discard unnecessary permissions if they have multiple privileges (such as permissions for different seating ranks), and participate in events with the privileges they prefer.

[0155] (Regarding the appearance of information about permissions) The event participation rights identified in the information regarding event participation rights (permission information for individual information in Figure 14(B), permission information associated with lists such as Figures 17(A) to 17(C)) referenced in step S202A of Figure 15(B) and step S202B of Figure 18(B), as described in the above-described embodiment, may or may not be visible on the user terminal 300 after the permission is granted. In other words, it may or may not be possible for the user to confirm after the permission is granted so that the user can recognize that they have the permission. Although the completion screen of the purchase process of a predetermined item that triggers the permission granting (the acquisition completion screen of a predetermined target) will notify (display) that event participation rights have been granted, a confirmation screen that explicitly states the permission may not be displayed after acquisition.

[0156] Examples of visualization include, for instance, information identifying a visualizeable item object managed as object data 122, which may be used as visualization information. For example, by making the visualization information information that identifies an item that can be associated with location information (world coordinates where the avatar is placed, space projected by a virtual camera) in a virtual space, the item can be made visible by associating 2D or 3D information with it in the virtual space and placing it on a virtual shelf. Alternatively, it can be made visible on the screen of the user terminal 300 by making it possible to move with the avatar by having the avatar wear, carry, or hold it. Furthermore, when requesting entry into a designated area where an event is being held (for example, when having the avatar enter portal 33 in Figure 8(A), entrance 43 in Figure 8(B), area 52 in Figures 9(A) and 9(B), or area 53), the avatar may be given a visualization item resembling a ticket, and the avatar can be shown to an attendant avatar (NPC, etc.) to gain entry. As mentioned above, referring to the character status screen in Figure 24(D), an example was described where information about events for which participation rights were granted based on the granting of a predetermined target is displayed on the screen showing the granting status of a predetermined target that triggered the granting of the rights. However, this differs from information that shows whether or not the rights are owned; it is information that displays information about the predetermined target that triggered the granting of the rights.

[0157] Alternatively, as another example of how participation rights can be made visible, the user may be able to check their rights in a manner that is not associated with location information within the virtual space. For example, the information visualizing the rights may be displayed in a different display location (a different UI space from the coordinate system projected by the virtual camera) than the location information within the virtual space, such as on the user's item box screen or the user's list of owned rights. For example, text data or image data may be displayed. A manner in which location information is not associated could be, for example, an image data modeled after a ticket as a visualization item, which can be viewed on a screen such as the list of owned tickets on My Page as information to inform the user of their entry rights, or text data (which may also be image data displaying characters) that lists events the user has participation rights for.

[0158] In this way, by making visualization items and permission lists available, users can easily confirm that they have been granted permission to participate in events. It should be noted that visualization information (information of visualization items that identify visualization items) is merely information to make it visible to the user that they have been granted participation permission. The decision of whether or not to allow the provision of information in a predetermined area is made based on the condition that information regarding the user's permissions can be identified from the user's individual information, such as in Figure 14(B), or the permission information in the permission holder list, such as in Figure 17(A), and that the user has been granted participation permission. For example, visualization information may be added to the user's individual information or the permission holder list, and visualization information may also be separately associated with the user's individual information. Even if visualization information is deleted, the user's permission to participate in events is not deleted, but if the permission to participate in an event is deleted, the visualization information for the event's participation permission associated with the user may be deleted. Furthermore, the information used to identify items that can be associated with location information within a virtual space for visualizing permissions (visualization items) is different from the information used to identify whether a predetermined item that triggers permission granting has been granted. The visualization item (for example, an object resembling a ticket) and the predetermined item that triggers permission granting (for example, an avatar decoration) are different items. Note that if the permissions owned are to be displayed in a list rather than as owned items, the permission information of the individual information in Figure 14(B) or the permission holder list information in Figure 17(A) may be referenced, and the corresponding events may be displayed in a list on the screen of the user terminal 300 based on the enabled permission information.

[0159] Furthermore, information about owned permissions, such as items for visualization or displayed in a list of text, may be hidden from the user terminal 300 screen after the participation permission determination (for example, even after the event has ended, or after it has been referenced in the participation permission determination). Even in this case, since participation history is managed separately as described later, and the permissions are visualized on the status screen as shown in Figure 24(D), even if the permissions themselves are no longer visible, the user can still feel the afterglow of having participated in the event. In addition, permission-related information may remain visible even after the event has ended, but after it has been referenced in the permission determination, even if it is displayed in the item list, used items list, used ticket list, etc., it may be displayed in a manner that indicates that it is invalid and cannot be used (for example, displayed as invalid, grayed out and unselectable, details not displayed, displayed as used, etc.).

[0160] Furthermore, even if the user's event participation rights are not made visible to the user, information regarding participation rights for events the user will participate in in the future (events that have not yet taken place) will not be made visible to the user. However, once the user participates in an event, the information about the event they participated in will be stored as part of their participation history, as described later. Based on this stored information, it may be possible to display a visible list of past events the user has participated in on the user terminal 300, allowing the user to review it in a list format.

[0161] (Other examples of designated areas) In the above-described embodiment, the predetermined area that receives viewing requests from users in the participation permission determination process exemplified in Figures 12(A) to 23(D) is an example of a venue corresponding to the main area exemplified in Figure 6 (corresponding to spatial areas 11 to 14 in Figure 5). If the main area has rooms 1 to 3 etc. corresponding to each main area (for example, rooms 11a, 11b etc. corresponding to the spatial areas in Figure 5), as exemplified in Figures 6 and 7(A) to 7(C), then a user can enter the main area by entering any of the rooms. Furthermore, the predetermined area in the participation permission determination process can be other predetermined areas as described above by referring to Figures 5 to 11, even if it is not the main area as shown in Figure 6. For example, as shown in area 32 of Figure 8(A), an area defined as being within the main area but separated during events (for example, an area that transitions to another room) may also be designated as a predetermined area (event venue). Similarly, as shown in area 42 of Figure 8(B), an area defined as being within the main area but separated by a building object enclosed by walls (such as a dome located within the main area) (for example, an area that transitions to another room when entered) may also be designated as a predetermined area (event venue). In the cases of Figures 8(A) and 8(B), for example, when a user performs an operation on portal 33 or entrance 43, or when an avatar is moved, it may be determined that a request to view the predetermined area has been made (step S201).

[0162] Furthermore, when an event is provided by performers on the stage object in area 51 as shown in Figures 9(A) and 9(B), when an event is provided in a building object that is not separated from other areas 54 such as area 52, or when an event is provided in the plaza of area 53, the virtual space 50 that is the main area containing each area may be treated as a predetermined area (venue), and the access rights of each user to the virtual space 50 may be determined. Alternatively, after allowing each user to enter the virtual space 50, it may be determined whether each user has the right to receive information about the events provided in each area (information about the predetermined area) (steps S202A, S202B, S202C, etc.). In this case, for example, the permission determination may be made when the user enters the virtual space 50. Users with permission may be provided with information about events such as performers after entering, as shown in Figure 10(A) (step S204), while users without permission may not be provided with event information, as shown in Figure 10(B) (step S205). Furthermore, when an avatar enters a building in area 52 or enters a plaza in area 53, the distribution server 100 may determine whether the avatar has the authority to receive information about a designated area in that area (steps S202A, S202B, S202C, etc.).

[0163] Furthermore, regarding the seating areas within the event venue (specific areas within a designated area), as explained with reference to Figure 11 and Figure 12(B), if the seat rank is included in the permission information when determining entry into the main area, the user avatar may be placed in the area of ​​the designated seat rank as an area that can be entered during the event. Also, the information provided to the user may differ depending on the seat rank. For example, the performance data (sound, effects, and other rendering information, etc.) delivered to the user terminal 300 of a user with a high seat rank may be more special than the performance data delivered to the user terminal 300 of a user with a low seat rank. For example, the costume data of the performer user delivered may differ depending on the seat rank, or the comment data delivered may differ (for example, a special message from the performer may be delivered). The user avatar may be automatically placed in the seating area after the request to connect to the event venue is permitted, or it may be possible to move to a designated seat by user operation. When moving by user operation, the avatar may not be allowed to enter the seating area of ​​a seat for which the user does not have permission.

[0164] Furthermore, as illustrated in Figures 5, 6, and 7(A) to 7(C), events may be provided only in a designated room (e.g., Room 1) among the rooms that offer the same main area, while events are not provided in other rooms (e.g., Rooms 2 and 3). In this case, the designated area where events are provided is that designated room. When a user performs an action such as clicking the room number button in Figure 6, it is determined that a viewing request has been made. For example, if it is determined that the user has permission to enter Room 1, the user will be able to enter Room 1.

[0165] (Processing on the user terminal) In the embodiments described above, examples were explained in which the processes shown in Figures 15(A), 15(B), 18(A), 18(B), 20, 22(A), and 22(B) are executed on the distribution server 100. However, the process is not limited to this, and the processes for granting participation rights and determining participation rights may be executed on the user terminal 300. For example, based on a program received from the distribution server 100 and stored in the storage unit 120, the control unit 350 of the user terminal 300 receives purchase permission information, etc., from the distribution server 100 based on an item purchase operation, etc. (corresponding to step S101). It then updates the user data 121, etc., stored in the storage unit 120 of the user terminal 300 by adding information that identifies owned items and information regarding permissions (corresponding to steps S102A and S102B; the updated user data 121 information may also be sent to the distribution server 100). Based on user operations, the operation identification unit 356, etc., detects that an operation corresponding to a request to view information in a predetermined area has been performed (for example, detection of an operation to select the main area where event A is provided, corresponding to step S201). The user data 121, etc., in the storage unit 120 is then referenced to determine whether or not information regarding permissions exists (corresponding to steps S202A, S202B and S202C). Once information regarding authorization is identified, permission may be granted to provide information for the designated area, and a request for information for the designated area may be sent to the distribution server 100, causing the distribution server 100 to receive information for the designated area (corresponding to steps S203 and S204). Alternatively, if authorization is not determined to be granted, a process may be executed to notify the distribution server 100 that authorization is not granted, without sending a request for information for the designated area (corresponding to step S205).

[0166] (Regarding applications other than events) In the embodiment described above, the predetermined area in the virtual space where a user submits a viewing request and whether or not they have the right to receive information is determined is described as a predetermined area where an event is provided. However, the process for determining participation rights in this embodiment may also be applied outside of event times. For example, it may be applied to the process for determining entry into a predetermined area that can be entered by purchasing a predetermined item or other object associated with entry rights, regardless of whether or not an event is being held. Furthermore, different entry rights with different periods of validity may be associated with such items or objects.

[0167] <Regarding participation history> Next, the utilization of user history will be explained with reference to Figures 25(A) to 30. In this embodiment, the history (hereinafter referred to as participation history) is the history of receiving information in a predetermined area (event participation (activity) history). The participation history includes activity scale information and activity characteristics information. In the virtual space provision system 1 of this embodiment, benefits are granted according to the user's participation history. The benefits granted are things that the user can use in the virtual space, but it is preferable that they are different from items that triggered the event participation.

[0168] (Activity characteristic information) First, we will explain the activity scale information managed as participation history by the virtual space provision system 1. Figures 25(A) to 25(C) are diagrams illustrating examples of activity scale information managed as user data 121, etc. Activity scale information is information that quantifies past user activities related to events by using indicators such as the number of times an event was attended, or by combining multiple such indicators. Activity scale information makes it possible to identify for each user the number of times an event was attended, the number of times an event was attended at each venue, the number of times an event category was attended (e.g., live concerts, festivals, game tournaments, etc.), and the percentage or number of venues entered out of all venues. For example, Figure 25(A) is an example of database information for managing the number of times each event was attended associated with each user ID. Figure 25(B) is an example of database information for managing the number of times each event venue was attended associated with each user ID. Figure 25(C) is an example of database information for managing the number of venues visited (achieved) for each user ID.

[0169] Figure 26 is a diagram illustrating an example of rewards based on activity scale information, managed as object data 122, etc., and shows an example of database information that manages rewards based on the participation history for each event in Figure 25(A). As illustrated in Figure 26, information that identifies items (equipment such as avatar costumes, housing items, etc.), status parameters (attack power, etc.), skills, and event-related rights is managed as rewards according to the number of times an event is participated in (for example, 3 times, 10 times, 20 times, etc.).

[0170] Event-related rights include, for example, the right to participate in other events, priority access to other events, the right to participate in sub-events of the same event, and priority access to sub-events of the same event. In addition, the right to participate in or priority access to the same event offered at different dates and times (e.g., scheduled to be held at a later date) may also be offered as a benefit. Priority access means, for example, in the case of an event where participation rights are granted by lottery, the right to have a higher probability of winning the lottery than other users. For example, Figure 26 shows an example where priority access to event Y is set as a benefit for a user who has participated in event ID "EV04" five times. For example, a priority user with priority access to event Y may be allowed to be drawn using a lottery table that gives them a higher probability of winning than other users. Also, if there is a limit to the number of participation rights for a given event (e.g., up to 1000 people can participate), the number of winners for priority users in the lottery may be limited to 700 people, and the number of winners for other users in the lottery may also be limited to 300 people.

[0171] Furthermore, the user experience at the next event may change depending on the level of activity scale information (for example, the more times an event is attended). For example, the purchase benefits for event participation rights may change. For example, whether or not purchase benefits are granted may differ depending on the level of activity scale information, and purchase benefits (or early purchase benefits) may be given as more valuable items (rare, expensive, etc.) the more past event participations a user has. In addition, the seat rank may be increased more easily with each participation (for example, after 5 participations, the seat rank for the next event becomes B, and after 10 participation, the seat rank becomes an even higher A). Also, if it is possible to send gifts at the event, the effect of the sent gifts may change depending on the number of participations. For example, the more participations a user has, the more noticeable the effect applied to the gift may be, such as it glowing, changing color, being displayed larger, or the gift display layer being displayed closer to the stage in the front of the audience seats. This makes it easier for performers to recognize user actions during the event, such as sending gifts.

[0172] Furthermore, benefits related to participation rights for future events, such as participation rights, priority participation rights, and purchase benefits for participation rights, may also be applied if the future event is one in which users are granted participation rights based on the purchase of a specified item, such as an item that grants participation rights to the event as explained with reference to Figure 12(A). For example, when an item, such as the one exemplified in Figure 12(A), is granted to a user as a benefit, the participation rights associated with that item may be transferred as permissions to the user's individual information or to the event's list of authorized holders. In addition, the effects of benefits based on participation history may also be applied to participation rights associated with the item, such as the one exemplified in Figure 12(A). For example, after purchasing an item, the probability of winning an associated participation right in a lottery may be increased as a benefit. Alternatively, additional benefits may be granted when purchasing an item, such as one that is associated with participation rights to a future event.

[0173] Furthermore, in addition to the number of times attended, as illustrated in Figure 25(C), if rewards are given based on the proportion or number of venues entered (attended) out of all venues, for example, if there are 10 types of venues in total (for example, the number of main areas used as venues), the rewards given for attending events at 5 of those venues (entering the venues) may be different from the rewards given for attending events at all venues.

[0174] Furthermore, if an event (e.g., a street performance) takes place in a designated area within a designated area, such as area 51 or area 53 in Figures 9(A) and 9(B), the history may be managed as participation in the designated main area that includes the designated area, or it may be managed separately for each designated area. In the former case, for example, if a street performance is held in the plaza of main area B (e.g., town B), the history may be managed as participation in main area B, or as participation in the plaza of town B.

[0175] Furthermore, rewards specific to each event, as shown in Figure 26, and rewards based on history specific to each venue, as shown in Figures 25(B) and 25(C), may be presented in a way that informs the user that these rewards are based on participation in / entering each event or venue, along with the content of the rewards themselves or a display of the reward content. For example, the screen showing when the rewards are granted to the user, or the screen where the user can check their owned rewards, may indicate that the information is based on their participation history. This allows users to recognize the rewards as a memento of their participation in or entry to each event and venue, which can contribute to increased user satisfaction.

[0176] (Activity characteristic information) Next, we will explain the activity characteristic information managed as participation history, referring to Figures 27(A) to 29(B). Activity characteristic information is information related to user activities associated with an event, used to identify the participation history of special users who participate in the event as performers or other participating members. Figure 27(A) is another example of event data, as explained by referring to Figure 12(A), etc., which is managed as event data in the provided content data 123. Figure 27(A) shows an example where the ID of a special user who becomes a performer is associated with the event ID as performer information. For example, the special user "SP01" is associated with the event ID "EV01" as performer information. Figure 27(B) is an example of database information managed as user data 121, which identifies the number of times each special user has participated in an event for each user. For example, user "U1" in Figure 27(B) has participated 5 times in an event where the special user "SP01" is associated as performer information, similar to the event ID "EV01" in Figure 27(A).

[0177] Figure 27(C) shows an example of database information for special user benefits, which are assigned according to activity characteristic information managed as object data 122, etc. For example, a special user "SP01" is given benefits based on the number of times they have participated in events in which "SP01" was a performer (e.g., 3 times, 10 times, 20 times). These benefits are also related to the corresponding special user. For example, if "SP01" is talent X, the benefits could include stamps containing X's image (images that can be used for communication with other users, etc.), posters depicting X that can be placed in the virtual space, acrylic stands depicting X, furniture, decorations, and other items that can be used and placed in the virtual space. Alternatively, the special user's voice (audio data) could be designated as a benefit, and this voice could be played or downloaded on the user terminal 300.

[0178] Figures 28(A) and 28(B) illustrate the benefits offered to special users based on the group to which they belong. As illustrated in Figure 28(A), special users may be assigned to specific groups. For example, if a special user is a talent or artist who sometimes participates in group activities such as Group A or Group B, providing benefits not only for individual special users but also for the groups to which they belong contributes to increased satisfaction for users who support the groups. Individual special users may belong to multiple groups. Furthermore, a group (e.g., 30 people) may be further subdivided into smaller groups (e.g., 4 people), resulting in multiple levels of grouping. As illustrated in Figure 28(B), group-specific benefits are similar to the individual benefits for special users in Figure 27(C), being group-related benefits. For example, benefits could include items that can be placed in the virtual space, such as posters of Group A (e.g., featuring the affiliated talent), acrylic stands, furniture, and decorations.

[0179] The number of events each group participates in may be counted based on, for example, the event participation history shown in Figure 25(A) or the participation history for each user corresponding to a special user shown in Figure 27(B), with each special user's participation count counting the number of events in the group to which they belong. Alternatively, or in addition to this, information on the group to which the special users appearing in the event data belong may be associated with the event data as exemplified in Figure 27(A), so that the number of participations for each user corresponding to each group is aggregated.

[0180] Furthermore, history and rewards may be managed according to combinations of groups and special users. For example, as a reward, a group poster depicting multiple special users may be designated as a reward depending on the history value, and special users with high history values ​​may be particularly highlighted.

[0181] Furthermore, each user in this embodiment may be allowed to register their favorite special users as fans (favorites), and depending on their fan registration status, they may be granted benefits based on their participation history. For example, if a user is a fan, the probability of receiving benefits may be higher than if they are not, or higher-ranking users may be granted benefits. For example, Figure 29(A) is an example of database information for identifying the fan registration status of each user, which is managed as user data 121. Figure 29(B) is another example of benefits based on participation history as illustrated in Figure 26, showing an example where additional benefits are associated with registered fan users. For example, if the special user associated with "EV01" as a performer is "SP01", then users who have not registered "SP01" as a fan will be granted the regular benefit item X, while a user "U1" who has registered "SP01" as a fan will be granted a limited edition of item X (for example, a limited-time design) as a benefit for registered fan users. Furthermore, regarding the priority participation rights perk exemplified in Figure 26, for events featuring special users who have registered as fans, the perk could be a further increased priority right that increases the chances of winning the lottery based on the priority participation rights. Alternatively, the priority participation rights perk could be weighted more heavily during the lottery for participation rights, thus increasing the chances of winning.

[0182] Furthermore, as a measure based on whether or not a user is registered as a fan, it may be possible to provide preferential treatment not only when granting benefits but also when granting event participation rights. For example, when event participation rights are granted based on the purchase of a specified item or other item, users who have registered as fans of a special user appearing in that event may be granted the right to receive information about events associated with higher-ranked seats. Also, not limited to benefits, when participation rights associated with a specified item or other item are granted based on a lottery, the probability of winning the lottery for events featuring a special user who is registered as a fan may be increased.

[0183] Furthermore, the probability of being selected may change depending on the number of special users that a user has registered as a fan. For example, a user with fewer registered fans may have a higher chance of being selected than a user with more registered fans.

[0184] Furthermore, the management of participation history in accordance with fan registration in the virtual space provision system 1 may be performed by obtaining and referencing user fan registration information data from a system different from the virtual space provision system 1. For example, user information (data for general users and special users) in an app on another platform that supports special users may be linked with the user data 121 of the virtual space provision system 1, and special users that a user has registered as a fan of in an app that supports special users may be treated as special users that have registered as fans in the virtual space provision system 1.

[0185] (Use on special user terminal screens) In this embodiment, the participation history of general users may be made visible on the screen of the special user's (performer user's) terminal (for example, the user terminal 300 used by the special user). Furthermore, when the information is made visible in this embodiment, the information of users who have a high level of enthusiasm for the special user or for the event may be highlighted on the special user's terminal screen. A high level of enthusiasm means, for example, a high level of interest in the special user or for the event. Indicators of interest can be the number of times a user has participated in an event (or an event in which the special user who displays the user's information (operating the terminal that displays the user's information) appeared), whether or not the user has registered the special user who displays the user's information as a fan, the number of gifts sent and the amount of gifts sent, and the number of items purchased and the amount of items purchased that correspond to the special user. For example, Figure 30 is an example of a special user's screen based on activity characteristic information corresponding to the special user. Window 71 in Figure 30 is a screen that displays a virtual space from the special user's perspective during the event (information for a predetermined area is drawn). In Figure 30, the special user, acting as a performer at the event, is looking from the stage towards the audience, and can see the avatars of the audience members. At this time, for example, based on the event participation history of the special user as exemplified in Figure 27(B), users with a high number of participations (users with a high level of interest) may be highlighted. For example, in window 71 of Figure 30, the number of participations and the username are displayed in association with the user avatar, and users with a high number of participations are displayed with greater emphasis. Furthermore, it is not limited to displaying readable information such as the number of participations and usernames, but the user avatar itself may be made to glow brighter for users with a high number of participations, or the appearance may differ based on the participation history. Also, in window 72 on the right side of Figure 30, participant information is displayed. For example, for each username, information such as the number of participations to date and whether or not the special user has registered as a fan may be displayed to inform (visualize) the special user.Furthermore, users with a high level of interest may be highlighted by displaying them higher in the list, assigning them a designated mark, or using different text display methods (flashing, color scheme, font type, etc.). This makes it easier for special users to find highly enthusiastic users, enabling smoother fan service.

[0186] (Timing of granting and notifying of benefits) The timing of granting the reward may be at the time of participation in the corresponding event, or after the event has ended. The timing of participation in the event is when the provision of information for the designated area where the event is provided begins in step S204, such as in Figure 15(A), and the user is recorded as being able to connect to the room in the designated area. The timing of being recorded as being able to connect is, for example, when the user is included in the list of entrants (currently in the room) in the memory unit 120. The timing of granting the reward may also be during the event provision period (a predetermined timing during the event). For example, the timing of granting may be set in advance according to the planned progress of the event's performance, and the reward that the user can use during the event to make the event even more exciting may be granted during the event. Furthermore, the granting of the reward during the event may be triggered by the performer user performing the reward granting operation. In addition, "after the event has ended" is not limited to immediately after the event itself has ended, but also includes cases where the reward is granted when leaving the event room or after a certain period of time has elapsed since the end of the event. Furthermore, if the designated area where the event is held remains open for a predetermined period after the event ends and is accessible to users, the user may be granted access when the open period for that area ends (even after the predetermined period has elapsed).

[0187] Furthermore, the timing of notifying users of the right to participate in events or priority access, as illustrated in Figure 26, may be based not on the event that triggered the decision to grant the right (for example, event ID "EV04" where the user participated for the fifth time), but rather on a later event where the right to participate or priority access will have an effect. For example, at the time of the announcement of the relevant event, users who meet the conditions for being granted the right to participate or priority access may be notified that they have an advantage in terms of participation rights to the relevant event based on their activity history.

[0188] Furthermore, if the granted rewards are character skills or parameters as exemplified in Figure 26, then, as exemplified in Figures 24(C) and 24(D), the granting animation or display on the status screen may be implemented to allow the user to recognize that the skills or parameters were obtained as rewards for participating in the event.

[0189] (Virtual space based on participation history) Furthermore, in addition to granting rewards, processing may be carried out according to participation history, such as changing the display of predetermined items (posters, monuments, etc.) placed in the virtual space according to participation history. For example, the display of predetermined items placed in each user's individual virtual space (such as a personal room where housing is possible) may be changed, and even in a virtual space synchronized with other users, such as a predetermined main area, some objects in the virtual space delivered may differ according to participation history. For example, the name of the event participated in may be added to the poster, or the poster of the event participated in may be displayed. In other words, the information delivered to each user may differ even in the same virtual space (area) according to participation history.

[0190] As described above, in the virtual space provision system 1 of this embodiment, information regarding the right to receive information about a predetermined area that becomes available based on the granting of a predetermined target such as an item referenced in the permission determination process (the right to participate in an event) is managed separately from the information that identifies whether a predetermined target such as an item has been granted. This makes it possible to manage participation history based on rights information referenced in permission determination, rather than managing it based on data that manages the ownership status of a predetermined target such as an item that may have disappeared at the time of event participation (for example, Figure 14(A), etc.). Therefore, the management of participation history becomes easier, and this makes it possible to improve user interest through processing based on activity history.

[0191] Furthermore, since participation history information can be managed separately from individual information such as Figure 14(B) and the list of authorized users such as Figure 17(A), participation history information can still be referenced and managed even if the user loses access to each event. For example, participation permissions granted to a user are active before (or during) the event, but after the event ends (after participating, leaving, etc.), the information regarding permissions in the individual information and the list of authorized users may be deleted or disabled. Even if deletion (or disabling) occurs, the information regarding those permissions (information identifying the event attended, seat rank, period information, venue information, etc.) is stored in the separately managed event participation history after the event. Therefore, by referring to the participation history, such as Figures 25(A) to 25(D) and Figure 27(B), it becomes possible to identify information for granting benefits and perform other processing utilizing the history (including changes in the display format within the virtual space and use on special user screens). Furthermore, depending on whether a user participates in an event, a "used" flag may be set to "on" for the referenced individual information and the permission information in the permission holder list, and a history may be accumulated for events with the "used" flag set to "on". In addition, in the virtual space system 1 of this embodiment, after an event ends, the history may be accumulated by the user management unit 133, etc., by referring to the individual information of the event and the permission information in the permission holder list, and when determining whether or not a user has the right to participate in an event, permission may be granted and the participation history may also be accumulated. In other words, information regarding the right to a given item based on the transfer of rights may be further transferred to the participation history, as shown in Figures 25(A) to 25(D) and Figure 27(B). Alternatively, as shown in Figure 13, information for identifying the rights granted to a given item may be transferred from the given item to the participation history (transferred to both the permission information and the participation history), similar to the transfer of individual information to the permission information in Figure 14(B). For example, a digital code that identifies the rights granted to a given item may be linked to the participation history.Furthermore, permission information transferred to the participation history (for example, additional count information) may be kept in a waiting state (pending count) until participation in the event ends, and then treated as a valid count after the event ends.

[0192] Furthermore, while each user may be allowed to check their own participation history from their My Page, if entry permission is granted based on ownership of a predetermined item, as in the past, users would need to refer to each predetermined item individually. However, as shown in Figures 25(A) to 25(C) and 27(B), participation history can be managed as a list independently of the predetermined items, making it easier to present each user with information about the events they have participated in (number of times participated, acquired benefits, etc.) (allowing users to refer to their past history). Thus, in this embodiment, by transferring the information that identifies the right to participate in an event, which was previously granted to a predetermined item, to individual information unrelated to the information that identifies whether the item is owned, it becomes possible to effectively utilize this information not only for determining permission but also for managing history.

[0193] (Processing on the user terminal) The processing described above, which corresponds to the participation history, may be performed on the user terminal 300. For example, the control unit 350 may perform processing to grant benefits according to the participation history, or processing to change the display mode of the virtual space, based on programs and data received and stored from the distribution server 100. For example, based on the participation history included in the user data 121 of the user operating the user terminal 300 received from the distribution server 100, if it is determined that the number of participations has reached a predetermined number, the system may perform processing to grant benefits (for example, sending benefit granting request information to the distribution server 100), or processing to send data request information that will be in a mode according to the history from the virtual space generation data received from the distribution server 100, or processing to select data according to the history from the received drawing data and draw it.

[0194] <Examples of LE configurations and effects> Examples of the specific configurations and effects of the embodiments disclosed above are listed below.

[0195] (1-1) In the above-described embodiment, based on a program stored in a computer such as the distribution server 100 or the user terminal 300 (for example, a program stored in a non-transient computer-readable storage medium), the distribution server 100 distributes information about the virtual space to the user terminal 300 based on the detection by the user terminal 300 of a viewing request for the virtual space 10 from the user (for example, a request to enter (access) a room, or a request to distribute predetermined information for drawing and playback to experience the virtual space) in steps S201, S204 of Figure 15(B), Figure 18(B), and Figure 20, and the transmission of this request to the distribution server 100. Furthermore, based on the distribution server 100 receiving from the user terminal 300 requests for entry into a designated area within the virtual space 10, such as a main area or room corresponding to an event venue, or for the distribution of information for rendering and playing events provided in the designated area, the distribution server 100 determines whether the user has the authority to receive information about the designated area (for example, whether information related to the authority to participate in an event can be identified). If it is determined that the user has the authority, the information about the designated area is distributed to the user.

[0196] Furthermore, the authority to receive information in a designated area is granted to the user based on the granting of designated items, parameters, skills, etc., as shown in Figures 13, 24(A), and 24(B), which are available to the user within the virtual space. This authority is granted to the user by the user management unit 133, etc., based on information regarding the rights associated with the designated items. As a result, the user is also granted the authority to participate in events based on the granting of avatar costumes, etc., which are available to the user within the virtual space. Since the determination of event participation authority refers to information regarding the authority granted based on the granting of items, etc., it becomes possible to grant permission for the provision of virtual space information based on the items granted to the user more flexibly.

[0197] (1-2) In the embodiments described above, as illustrated in Figure 13 and Figure 23(B), the user is granted the right to participate in an event based on the fact that the item, etc., was granted the right to participate in the event (information for identifying the right, and information related to the right). However, the right to participate that was granted to the item, etc., is transferred to the user's individual information and the list of authorized holders, and becomes the user's participation right. Therefore, the authorization information associated with the user's individual information in Figures 14(B), 14(D), and 23(C), which is information related to the right to participate in an event (the right to receive information in a predetermined area), and the user information (user ID, etc.) in the list of holders in Figures 17(A) to 17(C) and 23(D), are different from the information used to identify whether or not the user owns the item that triggered the granting of the right to participate in the event, such as the owned item identification information associated with the user's individual information in Figures 14(A) and 14(C). Therefore, regardless of what kind of owned item information is associated with the owned item identification information that identifies whether a specified target such as an item has been assigned, it becomes possible to grant users permission to enter the event venue.

[0198] (1-3) In the embodiments described above, even if the right to participate in an event granted to a user is granted based on the granting of a predetermined object such as an item (information identifying the rights granted to the item is transferred as a right), the determination of whether or not the user has the right to participate in an event (the right to receive information in a predetermined area) is performed regardless of whether the item is granted to the user who made the viewing request (participation request). In other words, even if user "U2" in Figure 14(A) transfers or destroys item "IT01" as shown in Figure 14(C), and as a result the user no longer owns the item in the data referenced when identifying information about the ownership of the item, the right information for user "U2" in Figure 14(B), which was granted to the user based on the rights information associated with the item, is not related to the item's ownership status, as shown in Figure 14(D). Therefore, even if the item is destroyed, the information regarding the right remains. Therefore, in contrast to methods that refer to item ownership status when determining eligibility to participate in an event, the system in this embodiment can manage a user's eligibility to participate in an event regardless of item ownership status (whether or not the item has been granted, or whether or not the user possesses it), thus enabling more flexible provision of virtual space information based on eligibility.

[0199] (1-4) In the embodiment described above, as shown in step S102A of Figure 15(A), the distribution server 100 executes a process to grant participation rights to the user based on the event participation rights granted to the item. Specifically, information regarding event participation rights (the right to receive information about a predetermined area where the event is provided) is associated with the user ID, thereby associating the information regarding the rights with the individual user information. When determining event participation rights, as shown in S202A to S203 of Figure 15(B), the distribution server 100 refers to the individual information of the user who made the request, and if information regarding the rights, such as the event ID in Figure 14(B) or the event venue name, seat rank, and period information in Figure 23, can be identified (conditional on identification), the server determines that the user has the rights and permits the provision of information to the user who made the request. Thus, because the information regarding permissions that can be granted based on the granting of a predetermined target, and which differs from the information used to determine whether a predetermined target has been granted (such as in Figure 14(A)), is associated with the user's individual information, it becomes possible to permit the provision of information in a predetermined area even if, for example, the predetermined target is no longer owned due to destruction or other reasons. Furthermore, since it is possible to grant permissions without granting the predetermined target, various experiences can be offered to the user regarding how to participate in an event.

[0200] (1-5) In the embodiment described above, as shown in step S102B of Figure 18(A), for example, the distribution server 100 executes a process to grant participation rights to the user based on the event participation rights granted to the item. Specifically, the user ID is associated with the list of event participation rights holders, as shown in Figures 17(A) to 17(C), and the list of venue entry rights holders, as shown in Figure 23(D). When determining participation rights to an event, as shown in steps S202B to S203 of Figure 18(B), the distribution server 100 determines that the user who made the request has the right to participate, provided that the ID of the user who made the request is included in the list of rights holders, and grants permission to the request from the user terminal 300. In this way, since the information associated with the rights holder list is information that can be granted based on the granting of a predetermined target, and is different from the information that determines whether a predetermined target has been granted, such as in Figure 14(A), it is possible to permit the provision of information in the predetermined area even if the predetermined target is no longer owned, for example, due to being discarded. Furthermore, it becomes possible to add users who are only granted permissions without being assigned specific targets, thus simplifying user management for administrators while offering users a variety of experiences regarding how to participate in events.

[0201] (1-6) In the embodiments described above, the predetermined area where the event is provided includes multiple types of predetermined areas. The predetermined area includes an area where the main event (first event) is provided and an area where the sub-event (second event) is provided. The sub-event is provided to the user after the main event has been provided. The sub-event area may be a predetermined area within the main event area, or it may be a different room from the main event area. For both the main event and the sub-event, if it can be determined that the user has been granted the right to participate in each event, participation (providing information about the area where the sub-event is provided (the user receiving the information)) is permitted, as shown in steps S302A to S303 of Figure 22(A) and steps S302B to S303 of Figure 22(B). However, even if a user has been granted the right to participate in the main event, they cannot receive information about the sub-event if they have not been granted the right to participate in the sub-event. Furthermore, each right may be granted to the user based on the fact that the same item or other target is granted to the user, or it may be granted to the user based on the fact that different items or other targets are granted to the user. Information regarding participation rights in sub-events is also associated with the individual information in Figure 21(A) and the list of authorized holders in Figure 21(B), similar to the participation rights in the main event. As a result, not only the first participation rights in the main event, but also the second participation rights in sub-events, are granted to users based on information regarding permissions that is different from the information referenced in determining the granting status of a given target. This allows for more flexible permission to provide information in the virtual space.

[0202] (1-7) In the embodiments described above, benefits are granted to users based on their event participation history, which is accumulated based on permission granted through the participation permission determination process. Benefits such as those shown in Figures 26, 27(C), 28, and 29(B) can be granted to users. This can contribute to improving user satisfaction, increasing motivation to participate in events, and promoting the growth of the virtual space.

[0203] (1-8) In the embodiments described above, users are granted rewards such as those shown in Figure 26 according to their activity scale information, which includes the number of times they have participated in events, such as in Figures 25(A) to 25(C), and their history of venues they have visited. Furthermore, as shown in Figure 26, rewards are granted according to each event, and by displaying the event name and other information along with the reward, for example as in Figure 24(D), the rewards can also function as mementos. This can contribute to improving user satisfaction, increasing motivation to participate in events, and promoting the growth of virtual spaces.

[0204] (1-9) In the embodiments described above, the users include special users who act as performers in events, as shown in Figure 27(A). The event participation history includes activity characteristic information, which is a history specific to each special user, as shown in Figure 27(B). Benefits are granted according to the activity characteristic information, such as benefits specific to each special user, as shown in Figure 27(C), benefits specific to the group to which the special user belongs, as shown in Figure 28(B), and benefits specific to whether or not the special user is a registered fan, as shown in Figure 29(B). This can contribute to improving user satisfaction, increasing motivation to participate in events, promoting the growth of the virtual space, and encouraging each fan's activities.

[0205] (1-10) In the embodiments described above, period information that specifies the period during which participation in an event is possible (that information for a predetermined area can be provided to the user) is included in the individual information and the holder list. As shown in steps S202C to S203 of Figure 20, the distribution server 100 is permitted to provide information to the user who made the request when it determines that the timing information (current information, such as date and time, date and time, etc.) at the time of receiving a viewing request from the user is consistent with the information identified from the user's individual information and the holder list. For example, it may be determined whether the period information included in the authorization information of the individual information in Figure 23(C) or the period information included in the holder list in Figure 17(C) and Figure 23(D) matches the current timing information, or the period information in Figure 12(A) may be identified from authorization information such as Figure 14(B) (e.g., event ID) and it may be determined whether they are consistent. This allows for more flexible permission to provide information in virtual spaces, for example, when the same event is offered over different periods, or when different events or the same event are offered at the same venue, as long as the periods are consistent.

[0206] <Note>

[0207] (1) A virtual space provision system according to a certain aspect of the present invention (for example, virtual space provision system 1) provides information about the virtual space to a user based on a user's request to view the virtual space, thereby enabling the user to view the virtual space (for example, steps S201 and S204 in Figures 15(B), 18(B), and 20, etc., including a distribution server 100 (for example, a control unit 130 (content management unit 131, data distribution unit 132), etc.), a user terminal 300 (for example, a control unit 350 (information transmission / reception unit 351, virtual space generation unit 352), etc.), Based on receiving a user's request to view a predetermined area of ​​the virtual space (for example, each spatial area in Figure 5, each main area in Figure 6, rooms corresponding to the main areas, predetermined areas within the main areas such as Figure 8(A), Figure 8(B), Figure 9(A), Figure 9(B), Figure 10(A), Figure 10(B), etc.), a provision permission means (for example, see Figure 15(B), Figure 18(B), Figure 20, S203, Content Management Unit 131, User Management Unit 133, and Modified Example (Processing at User Terminal)) permits the provision of information about the predetermined area (for example, virtual space generation data, data for rendering the virtual space of the predetermined area, data for rendering events in the predetermined area such as Figure 10(A), etc.) to the user, The system includes means for granting the user the right to receive information in the specified area (for example, see Figures 14(B), 15(A), 17(A) to 17(C), 18(A), User Management Unit 133, and Modified Example (Processing at User Terminal)), which can be granted based on the granting of predetermined targets (for example, items, parameters, skills, etc. in Figures 13, 24(A), and 24(B)) that are available to the user within the virtual space, and for granting the user the right to receive information in the specified area (for example, see Figures 14(B), 15(A), 17(A) to 17(C), 18(A), User Management Unit 133, and Modified Example (Processing at User Terminal)), The provision authorization means grants permission to provide information in the predetermined area on the condition that information regarding the user's permissions has been identified (for example, steps S202A to S203 in Figure 15(B), steps S202B to S203 in Figures 16 and 18(B), and steps S202B to S203 in Figures 19 and 20).

[0208] With this configuration, the provision of virtual space information is permitted based on the status of the authorization to receive information about a predetermined area that becomes available to the user based on the user being granted a predetermined target that can be used in the virtual space. This makes it possible to more flexibly permit the provision of virtual space information based on the target granted to the user.

[0209] (2) In (1) above, the information relating to the permissions (for example, permission information associated with the individual user information in Figures 14(B), 14(D), and 23(C), and user information in the permission holder list in Figures 17(A) to 17(C) and 23(D)) is different from the information that identifies whether or not the predetermined target has been granted (for example, the information that identifies owned items in Figures 14(A) and 14(C)).

[0210] With this configuration, since the information identifying whether or not a predetermined target has been granted is different from the information regarding permissions, it becomes possible to permit the provision of information in a predetermined area regardless of the state of the information identifying whether or not a predetermined target has been granted.

[0211] (3) In (2) above, the granting permission means grants permission on the condition that it can identify the information regarding the user's permissions, regardless of whether the user who made the viewing request has been granted the predetermined target (for example, permission is granted if individual permission information such as Figure 14(B) associated with the user based on the item, or permission information in the user list in Figure 17(B), can be identified, regardless of whether Figure 14(A) or the like contains information that identifies that the item has been granted as an owned item).

[0212] With this configuration, the authority that can be granted based on the granting of a predetermined target can be determined regardless of the granting status of that predetermined target, thus enabling more flexible permission for the provision of information in the virtual space.

[0213] (4) In (3) above, The means for providing the above is, The process of associating the aforementioned permission information with the user's individual information is performed (for example, step S102A in Figure 15(A)), The aforementioned provision authorization means is Provided that it is determined that the user's individual information is associated with the information regarding the aforementioned permissions, permission is granted to provide the user with the information in the predetermined area (for example, S202A to S203 in Figure 15(B)).

[0214] With this configuration, since information regarding the permissions that can be granted based on whether a predetermined target is granted is associated with the user's individual information, it becomes possible to permit the provision of information in a predetermined area regardless of the state of the information that identifies whether or not a predetermined target has been granted.

[0215] (5) In (3) above, The means for providing the above is, The process is executed to associate the information regarding the aforementioned permissions with a list of users who have the authority to view the information in the predetermined area (for example, step S102B in Figure 18(A)), The aforementioned provision authorization means is Provided that the user list is identified to include information regarding the permissions of the user who made the access request, permission is granted to provide the information in the predetermined area to that user (for example, steps S202B to S203 in Figure 18(B)).

[0216] With this configuration, since information regarding permissions that can be granted based on whether a predetermined target is granted is associated with the user list, it becomes possible to permit the provision of information in a predetermined area regardless of the status of the information that identifies whether or not a predetermined target has been granted.

[0217] (6) In (3) above, The aforementioned designated area is the area where the event is held (for example, the event venue and sub-event venues shown in Figures 12(A) and 23(D)). Users can request to view information about the area where the first event is provided (for example, data for rendering the main event of event A provided at venue A in Figure 12(A)), and information about the area where the second event related to the first event is provided (for example, data for rendering the handshake event provided in the handshake room, which is a sub-event of event A in Figure 12(A)). The aforementioned rights to receive include a first right (e.g., the right to participate in the main event), which is the right to receive information about the area where the first event is provided, and a second right (e.g., the right to participate in the sub-event), which is the right to receive information about the area where the second event is provided. The aforementioned provision authorization means is With respect to a request to view information in the area where the second event is provided, even if the first authority of the user who made the viewing request can be identified (for example, even if the authority information for the main event in Figure 21(A) (for example, the event ID of the main event), or the user ID in the list of authorized persons in Figure 21(B), is associated with it), if the information regarding the second authority (for example, the information regarding participation rights for sub-events associated with the individual information in Figure 21(A), or the information regarding participation rights for sub-events associated with the user ID in the list of authorized persons in Figure 21(B)) cannot be identified, the information in the predetermined area where the second event is provided will not be permitted to be provided (for example, step S305 in Figure 22(A), step S305 in Figure 22(B)).

[0218] With this configuration, unless a user has the authority to receive information about the area where the second event related to the first event is provided, they will not be permitted to receive information about the area where the second event is provided to the user who requested access, thus increasing the value of the second event.

[0219] (7) In (3) above, The system further includes means (for example, user management unit 133) for granting benefits (for example, benefits according to history in Figure 26, benefits according to special users in Figure 27(C), benefits according to groups in Figure 28(B), benefits according to registered special users in Figure 29(B), etc.) based on the user's history (for example, event participation history in Figures 25(A) to 25(C), event participation history according to special users in Figure 27(B), etc.) that have been authorized by the aforementioned provision authorization means.

[0220] With this configuration, benefits are granted based on the history of information received in a designated area, which can contribute to improving user satisfaction. (8) In (7) above, The aforementioned designated area is the area where the event will be held. The aforementioned history includes information on the scale of activity for each user in relation to the aforementioned event (for example, event participation history such as Figures 25(A) to 25(C)). The means of granting the aforementioned benefits is, The aforementioned benefits are granted to each user according to their activity scale information (for example, benefits based on the number of events they have participated in, as shown in Figure 26).

[0221] This configuration allows users to receive benefits commensurate with their activity level, contributing to increased user satisfaction and encouraging future user activity.

[0222] (9) In (7) above, The aforementioned designated area is the area where the event will be held. The users include special users who will be performers at the aforementioned event (for example, the special users in Figure 27(A)), The history includes user-specific activity characteristic information corresponding to the special user (for example, the history corresponding to the special user in Figure 27(B)). The means of granting the aforementioned benefits is, The aforementioned benefits are granted to each user according to their activity characteristics (for example, the benefits for special users in Figure 27(C), the benefits for groups in Figure 28(B), and the benefits for registered special users in Figure 29(B)).

[0223] This configuration allows users to receive benefits tailored to their activity characteristics, thereby contributing to increased user satisfaction and encouraging future user activity.

[0224] (10) In (3) above, The aforementioned authorization information is information that can identify that the timing information when the viewing request was received (e.g., current date and time, date and time, etc.) and the information that specifies the period during which the information of the predetermined area included in the authorization information can be provided to the user (e.g., the period information in Figure 17(C), the period information in Figure 23(C), the period information in Figure 23(D), the authorization information in Figure 14(B) that specifies the period information in Figure 12(A), the period information of the rights information in Figure 23(B), etc.) are consistent (e.g., steps S202C to S203 in Figure 20).

[0225] With this configuration, since information about the period can also be used when granting permission to provide information in a designated area, it becomes possible to grant permission to provide information in a virtual space in a more flexible manner.

[0226] (11) A method for providing a virtual space according to a certain aspect of the present invention is: A method for having a computer (for example, a distribution server 100, a user terminal 300) execute the following: The steps include: enabling a user to view a virtual space by providing information about that virtual space based on a user's request to view the virtual space; A provision authorization step, based on receiving a user's request to view a predetermined area of ​​the virtual space, grants permission to provide information about the predetermined area to the user; The authority that can be granted based on the granting of a predetermined target that is available to the user within the virtual space, comprising the step of granting the user the authority to receive information in the predetermined area, In the aforementioned permission step, permission is granted whether or not to provide the information in the predetermined area, on the condition that information regarding the permissions of the user who made the viewing request has been identified.

[0227] With this configuration, the provision of virtual space information is permitted based on the status of the authorization to receive information about a predetermined area that becomes available to the user based on the user being granted a predetermined target that can be used in the virtual space. This makes it possible to more flexibly permit the provision of virtual space information based on the target granted to the user.

[0228] (12) A virtual space provision program according to a certain aspect of the present invention is Computers (for example, distribution server 100, user terminal 300) A means of enabling a user to view a virtual space by providing information about that virtual space based on a user's request to view that virtual space, A means for granting permission to provide information about a predetermined area of ​​the virtual space, which grants permission to provide information about the predetermined area to a user based on the receipt of a user's request to view that area, A privilege that can be granted based on the granting of a predetermined target that is available to the user within the virtual space, and which functions as a means to grant the user the privilege to receive information in the predetermined area. The aforementioned permission means grants permission to provide information in the predetermined area, on the condition that it has been possible to identify the permissions of the user who made the viewing request.

[0229] With this configuration, the provision of virtual space information is permitted based on the status of the authorization to receive information about a predetermined area that becomes available to the user based on the user being granted a predetermined target that can be used in the virtual space. This makes it possible to more flexibly permit the provision of virtual space information based on the target granted to the user.

[0230] [Examples of implementation using software] The various control blocks of the control unit in the server, terminal, or other computer in the embodiments described above may be implemented by logic circuits (hardware) formed on an integrated circuit (IC chip), or by software using a CPU (Central Processing Unit). When implemented by software using a CPU, the computer equipped with the control unit includes a CPU that executes instructions for a program which is software that realizes each function, a ROM (Read Only Memory) or storage device (collectively referred to as a "recording medium") on which the program and various data are recorded in a readable format for the computer (or CPU), and a RAM (Random Access Memory) for loading the program. The object of the present invention is achieved when the computer (or CPU) reads the program from the recording medium and executes it. As the recording medium, a "non-temporary tangible medium" such as tape, disk, card, semiconductor memory, or programmable logic circuit can be used. The program may also be supplied to the computer via any transmission medium capable of transmitting the program (such as a communication network or broadcast wave). One aspect of the present invention can also be realized in the form of a data signal embedded in a carrier wave, in which the program is embodied by electronic transmission.

[0231] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of this invention is indicated by the claims rather than by the foregoing description, and all modifications within the meaning and scope equivalent to the claims are intended to be included. [Explanation of symbols]

[0232] 1 Communication system, 2 Network, 100 Distribution servers, 200 Administrator terminals, 300 User terminals

Claims

1. A means of enabling a user to view a virtual space by providing information about that virtual space based on a user's request to view that virtual space, A means for granting permission to provide information about a predetermined area of ​​the virtual space, which grants permission to provide information about the predetermined area to a user based on the receipt of a user's request to view that area, The system includes a means for granting a user the right to receive information about the predetermined area, which is a right that can be granted based on the granting of a predetermined object that the user can use within the virtual space, The provision authorization means grants permission to provide information in the predetermined area, regardless of whether the predetermined target has been granted to the user who made the viewing request, on the condition that information regarding the user's permissions has been identified.

2. The virtual space provision system according to claim 1, wherein the information relating to the aforementioned authority is different from the information that identifies whether or not the predetermined target has been granted.

3. The means for providing the above is, The process of associating the aforementioned permission information with the user's individual information is performed. The aforementioned provision authorization means is The virtual space provision system according to claim 1, which permits the provision of information about the predetermined area to the user, on the condition that it can be identified that information about the permissions is associated with the individual information of the user.

4. The means for providing the above is, The process is executed to associate the information regarding the aforementioned permissions with a list of users who have the authority to view the information in the predetermined area. The aforementioned provision authorization means is The virtual space provision system according to claim 1, which permits the provision of information in the predetermined area to a user, on the condition that it can be identified that the user list includes information regarding the permissions of the user who made the viewing request.

5. The aforementioned designated area is the area where the event will be held. Users can request to view information about the area where the first event is provided, and information about the area where a second event related to the first event is provided. The aforementioned authority to receive information includes a first authority, which is the authority to receive information about the area where the first event is provided, and a second authority, which is the authority to receive information about the area where the second event is provided. The aforementioned provision authorization means is The virtual space provision system according to claim 1, in response to a request to view information about an area where the second event is provided, even if the first authority of the user who made the viewing request can be identified, if information regarding the second authority cannot be identified, the system will not permit the provision of information about a predetermined area where the second event is provided.

6. The virtual space provision system according to claim 1, further comprising means for granting benefits to each user according to their history based on having received information about the predetermined area as permitted by the provision permission means.

7. The aforementioned designated area is the area where the event will be held. The aforementioned history includes activity scale information for each user in response to the aforementioned event. The means of granting the aforementioned benefits is, The virtual space provision system according to claim 6, which grants the aforementioned benefits according to the activity scale information for each user.

8. The aforementioned designated area is the area where the event will be held. The users include special users who will be performers at the aforementioned event. The aforementioned history includes user-specific activity characteristics information tailored to the special user. The means of granting the aforementioned benefits is, The virtual space provision system according to claim 6, which grants the special benefits to the special user in accordance with the activity characteristics information for each user.

9. The virtual space provision system according to claim 1, wherein the information relating to the authority is information that can identify that the timing information when the viewing request was received and the information specifying the period during which the information of the predetermined area included in the information relating to the authority can be provided to the user are consistent.

10. A method for getting a computer to do something, The steps include: enabling a user to view a virtual space by providing information about that virtual space based on a user's request to view the virtual space; A provision authorization step, based on receiving a user's request to view a predetermined area of ​​the virtual space, grants permission to provide information about the predetermined area to the user; The authority that can be granted based on the granting of a predetermined target that is available to the user within the virtual space, comprising the step of granting the user the authority to receive information in the predetermined area, A method for providing a virtual space, wherein in the provision permission step, permission is granted whether or not to provide information in the predetermined area, on the condition that information regarding the user's permissions has been identified, regardless of whether the user who made the viewing request has been granted the predetermined target.

11. Computers, A means of enabling a user to view a virtual space by providing information about that virtual space based on a user's request to view that virtual space, A means for granting permission to provide information about a predetermined area of ​​the virtual space, which grants permission to provide information about the predetermined area to a user based on the receipt of a user's request to view that area, A privilege that can be granted based on the granting of a predetermined target that is available to the user within the virtual space, and which functions as a means to grant the user the privilege to receive information in the predetermined area. The provision authorization means is a virtual space provision program that allows the provision of information in the predetermined area on the condition that information regarding the user's permissions can be identified, regardless of whether the user who made the viewing request has been granted the predetermined target.

Images