Virtual space management systems and their methods

Abstract

To solve a problem of absence of a mechanism for easily sharing a private content displayed on a screen of a virtual PC object corresponding to an own PC brought into a virtual space by a user with an avatar of another user in the virtual space.SOLUTION: A virtual space management system manages a virtual space in which each of a plurality of users can participate as an avatar by using a client terminal, and performs control such that private content in a display area of a user device object is provided through the client terminal of a second user based on at least one of gesture relative to a user device object by an avatar of a first user in the virtual space and an avatar of the second user and operation by the avatar of the second user.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] The present invention relates to a technology for sharing content between avatars in a virtual space in AR and VR.

Background Art

[0002] XR is attracting attention as a general term for technologies that create a space for providing a pseudo-experience by integrating the real and virtual worlds such as VR (Virtual Reality) and AR (Augumented Reality), and various standardization efforts are being carried out. In recent years, a virtual space or service using such technology is called a metaverse, and it is being used not only for entertainment purposes such as games but also in business scenes such as virtual offices and VR meeting rooms.

[0003] In a virtual office system, each worker wears an HMD (Head Mounted Display) and commutes to an office in a virtual space as an avatar via the HMD, and works in the same way as in a conventional real space. Not all work is completed in the virtual space, and work may be advanced in a hybrid of the virtual space and the real space depending on the scene. As one of the means for this, there is a technology for synchronizing the PC (Personal Computer) screen in the real space with the virtual space in order to seamlessly connect the virtual space and the real space. By connecting a PC existing in the real space to the virtual space and synchronizing the PC screen with one's own viewpoint in the virtual space, it is possible to experience as if bringing the PC in the real space into the virtual space.

[0004] Also, as a technology for assisting communication between users in a virtual space, there is Patent Document 1. According to Patent Document 1, it is possible to determine whether a conversation is possible or adjust the volume during a conversation according to the distance between avatars in the virtual space, and it is possible to improve the user experience in voice communication with nearby users in the virtual space.

Prior Art Documents

[0005] [Patent Document 1] Japanese Patent Publication No. 2022-2387 [Overview of the project] [Problems that the invention aims to solve]

[0006] As mentioned earlier, when bringing a PC screen into a virtual space, the virtual object corresponding to the actual PC is visible to other users, but the content displayed on the virtual screen of that PC object is private information and therefore not visible to other users. However, just like in the real world, there may be cases where you want to discuss while showing your PC screen only to nearby users, for example, users around your seat in the virtual space.

[0007] If you want to share your PC screen with other users, you can do so by creating a meeting room, having them join, and enabling screen sharing, just like with traditional online meeting systems. However, if you want to have an ad-hoc discussion by showing your PC screen, which you've brought into a virtual space rather than a formal meeting, to users around you, using the screen sharing function of the online meeting system described above is cumbersome.

[0008] This invention was made to solve the above problems and aims to provide a mechanism for easily sharing content displayed on a PC screen brought into a virtual space with users located nearby within that virtual space. [Means for solving the problem]

[0009] A virtual space management system that manages a virtual space in which multiple users can participate as avatars using client terminals, comprising: a first providing means that controls the provision of the virtual space via the client terminal of a first user and the client terminal of a second user; and a second providing means that controls the provision of virtual objects in the virtual space, wherein the second providing means further controls the provision of user device objects held by the first user in the virtual space via the client terminal of the first user and the client terminal of the second user, and controls the provision of the first user's private content in the display area of ​​the user device object via the first user's client terminal, in the virtual space Based on a gesture including contact between the first user's avatar and the second user's avatar, The system is also characterized by controlling whether the private content is provided via the second user's client terminal. [Effects of the Invention]

[0010] According to the present invention, a mechanism can be provided for easily sharing content displayed on a PC screen brought into a virtual space with users located nearby within that virtual space. [Brief explanation of the drawing]

[0011] [Figure 1] A diagram showing an example of a network configuration. [Figure 2] Example hardware configuration diagram [Figure 3] Example software configuration diagram [Figure 4] A diagram showing examples of gestures for sharing a PC screen brought into a virtual space. [Figure 5] Sequence diagram showing the process of sharing a PC screen brought into a virtual space. [Figure 6] A flowchart for determining whether or not to share a PC screen brought into a virtual space. [Figure 7] Flowchart for determining when to disable sharing of a PC screen brought into a virtual space. [Figure 8] This diagram illustrates an example of a method for sharing a PC screen brought into a virtual space with multiple users within that virtual space. [Modes for carrying out the invention]

[0012] The best mode for carrying out the present invention will be described below with reference to the drawings.

[0013] (Example 1) Figure 1 is a diagram showing an example of the overall configuration of a network system including a virtual space management system according to an embodiment of the present invention. In Figure 1, the virtual space management system 111, client terminals 121, 122, 131, and 132 are connected via networks 101 to 103. Networks 101 to 103 are so-called communication networks, which can be realized by, for example, LANs such as the Internet, WANs, telephone lines, dedicated digital lines, ATM or frame relay lines, cable television lines, wireless lines for data broadcasting, etc. Networks 101 to 103 only need to be capable of transmitting and receiving data. In the present invention, network 101 is the Internet, and networks 102 and 103 are wireless LANs set up on the Internet or in general household or company networks.

[0014] Client terminals 121 and 131 are dedicated hardware devices that support the rendering of virtual objects handled in XR, such as HMDs (head-mounted displays) and smart glasses. Alternatively, client terminals 121 and 131 may be mobile devices with a built-in program execution environment, such as smartphones. Users can participate as avatars in the virtual space provided by the virtual space management system 111 using their respective client terminals. In the virtual space, multiple users' avatars can interact with each other.

[0015] The client terminals 121 and 131 include a camera for photographing the surroundings and a display for projecting or displaying a virtual space and virtual objects arranged thereon. The client terminals 121 and 131 recognize the user's fingers through the camera and provide a pseudo-experience that combines the real and virtual worlds by overlaying the operations in the real space and the virtual space. When the client terminals 121 and 131 are not dedicated hardware such as a smartphone, etc., the virtual objects are drawn using the APIs provided by a web browser, an OS, etc. In this embodiment, the client terminals 121 and 131 are described as HMDS.

[0016] The client terminals 122 and 1,32 are personal computers (PCs), which are information processing devices having displays such as notebook PCs, desktop PCs, smartphones, etc. The client terminals 122 and 132 have a function of transmitting the content displayed on the PC screen to the virtual space management system 111 in order to bring (synchronize) the PC screen of the real space into the virtual space. Hereinafter, a virtual object indicating the PC itself of a certain user in the virtual space is called a user device object held by the user on the virtual space. The content including the private information displayed in the display area (PC screen) of the user device object is called private content. Also, in this embodiment, other users in the virtual space can see the user device object itself, but usually cannot see the private content displayed on the screen of the user device object.

[0017] The virtual space management system 111 is a system for providing each client terminal with virtual objects in the virtual space, avatars modeled after each user, and their location information. The virtual space management system 111 also has the function of receiving and providing private content transmitted from client terminals 121, 131, etc., which is the objective of the present invention, and managing the sharing status, etc. Furthermore, the virtual space management system 111 also manages the users utilizing client terminals 121, 122, 131, and 132. That is, the virtual space management system 111 receives login and logout requests from client terminals 121, 122, 131, and 132 and performs login and logout processing. The virtual space management system 111 is constructed using a server computer. Alternatively, it can be constructed using cloud computing technology, etc. Hereinafter, virtual objects corresponding to users operating in the virtual space will be referred to as avatars.

[0018] The functions of the virtual space management system 111 described in this invention may be implemented by a single server or a single virtual server, or by multiple servers or multiple virtual servers. Alternatively, multiple virtual servers may be running on a single server.

[0019] Figure 2 is a hardware configuration diagram of the virtual space management system 111 and client terminals 121, 122, 131, and 132 according to an embodiment of the present invention. In FIG. 2, a Central Processing Unit (CPU) 202 controls the entire apparatus. The CPU 202 executes application programs, an OS, etc. stored in the HDD 205, and performs control to temporarily store information, files, etc. necessary for program execution in the RAM 203. A Graphics Processing Unit (GPU) 210 performs arithmetic processing necessary for real-time drawing of virtual objects and avatars. A Read Only Memory (ROM) 204 is a storage means, and stores various data such as a basic I / O program therein. The RAM 203 is a temporary storage means and functions as a main memory and a work area of the CPU 202 and GPU 210. A Hard Disk Drive (HDD) 205 is one of external storage means, functions as a large-capacity memory, and stores application programs such as a web browser, programs of a service server group, an OS, related programs, etc.

[0020] A display 206 is a display means and displays virtual objects, information necessary for operations, etc. Further, the display 206 may be a device having a function of receiving an operation instruction from a user such as a touch panel. A camera 207 is an out-camera that captures surrounding images and an in-camera that mainly captures oneself in client terminals 121 and 131.

[0021] By analyzing the video captured by the camera 207, particularly the out-camera, with an application program stored in the HDD 205, it is possible to synchronize the movement of one's own fingers in the real space with the movement of the fingers of one's own avatar in the virtual space. Furthermore, it becomes possible to virtually contact virtual objects and other avatars in the virtual space displayed on the display 206 with the synchronized fingers. The virtual space management system 111 and client terminals 122 and 132 do not necessarily require the camera 207.

[0022] Interface 208 is an external device interface for connecting peripheral devices such as various external sensors. While the aforementioned camera 207 allows for the manipulation of virtual objects in the virtual space and contact with other avatars by recognizing the user's fingers in the real world, the same functionality can be achieved by operating a dedicated controller connected to interface 208.

[0023] The system bus 201 controls the flow of data within the device. The Network Interface Card (NIC) 209 exchanges data with external devices via the NIC 209 and networks 100-102. Note that the above computer configuration is just one example and is not limited to the configuration shown in Figure 2. For example, the storage location of data and programs can be changed to ROM 204, RAM 203, HDD 205, etc., depending on their characteristics. In addition, the CPU 202 and GPU 210 execute processing based on the programs stored in HDD 205, thereby realizing the processing in the software configuration shown in Figure 3.

[0024] Figure 3 illustrates the software configuration of the virtual space management system 111 and client terminals 121, 122, 131, and 132 according to this embodiment, with the functions related to the present invention extracted.

[0025] The virtual space management system 111 includes a user management unit 312 and a login processing unit 314 as user management functions. In addition, the virtual space management system 111 also includes a virtual object management unit 316, a virtual object provision unit 318, a location information management unit 320, a location information receiving unit 322, and a location information provision unit 324 as basic functions for providing a virtual space.

[0026] Furthermore, the virtual space management system 111 also includes a content management unit 326, a content receiving unit 328, a content providing unit 330, a shared state management unit 332, and a shared state providing unit 334, which are features of the present invention.

[0027] The user management unit 312 manages user information and login information. The login processing unit 314 receives login requests from client terminals 121, 122, 131, and 132, compares them with the information in the user management unit 312, and returns the login processing result to client terminals 121, 122, 131, and 132. Table 1 below shows an example of the data managed by the user management unit 312.

[0028] [Table 1]

[0029] The User ID column is an ID that uniquely identifies the user. The Password column is the password used for basic authentication when logging in with the User ID. The Login Processing Unit 314 compares the User ID and password combinations included in the login requests from client terminals 121, 122, 131, and 132 with Table 1, and if they match, returns the login result as successful to each client terminal. The Login Status column indicates the user's login status, where "on" indicates logged in and "off" indicates logged out. The Login Expiration Date column indicates the expiration date of the authentication status of the logged-in user.

[0030] The Object ID column contains a unique, randomly assigned ID if the target user device object exists within the virtual space, that is, if client terminals 122 and 132 (PCs) have been brought into the virtual space as virtual objects.

[0031] The virtual object management unit 316 manages virtual objects placed in the virtual space, as well as 3D data of each user's avatar. The virtual object provision unit 318 provides the 3D data managed by the virtual object management unit 316 to client terminals 121 and 131.

[0032] The location information management unit 320 manages the location information of virtual objects and avatars managed by the virtual object management unit 316. Table 2 below shows an example of the location information of each user's avatar managed by the location information management unit 320.

[0033] [Table 2]

[0034] The User ID column is an ID that uniquely identifies the user. The Spatial ID column is an ID that uniquely identifies the virtual space. The Main Coordinates column contains information indicating the avatar's current position (center of gravity). The Left Hand Coordinates column and Right Hand Coordinates column contain information indicating the positions of the avatar's left and right hands, and are used to determine the contact state with virtual objects and the avatar. Details regarding the contact state will be described later.

[0035] Similar to Table 2, Table 3 below shows an example of virtual object location information.

[0036] [Table 3]

[0037] The Virtual Object ID column is an ID that uniquely identifies the virtual object in the virtual space. The Spatial ID column and Main Coordinate column are described as in Table 2.

[0038] The location information receiving unit 322 has the function of receiving location information from client terminals 121 and 131 when there is a change in the position of virtual objects or avatars in the virtual space due to operations from client terminals 121 and 131, or periodically. The location information providing unit 324 provides the client terminals 121 and 131 with location information of virtual objects and avatars in the virtual space that is managed by the location information management unit 320.

[0039] The content management unit 326 manages private content sent from client terminals 122 and 132. The content receiving unit 328 receives private content sent from client terminals 122 and 132. The content providing unit 330 provides private content to client terminals 121 and 131 of avatars that are authorized to share private content. Further details will be described later.

[0040] The sharing status management unit 332 manages data to determine whether or not private content, a feature of the present invention, can be shared. Table 4 below shows an example of the data managed by the sharing status management unit 332.

[0041] [Table 4]

[0042] The User ID column contains the ID that uniquely identifies the user. The Contact with User Device Object column indicates whether the owner of the user device object in the virtual space is in contact with the user device object they own. The Contact User column lists the user IDs of the avatars that are in contact in the virtual space. The Shared User column lists the user IDs of the users to whom the private content is being shared. Details regarding contact determination and sharing permission determination will be described later using a separate diagram.

[0043] Next, we will explain the software configuration of client terminals 121 and 131.

[0044] Client terminals 121 and 131 are equipped with a display unit 352, a login unit 354, a local virtual object management unit 356, and a virtual object acquisition unit 358. Client terminals 121 and 131 are also equipped with a local location information management unit 360, a location information transmission unit 362, a location information acquisition unit 364, a content acquisition unit 366, and a shared status acquisition unit 368.

[0045] The display unit 352 projects and displays virtual objects and avatars in the virtual space via the display 206. The login unit 354 transmits the username and password entered via a finger captured by the camera 207 or an input device connected to the interface 208 to the login processing unit 314. The authentication method for the virtual space management system 111 may also be facial recognition using a facial image captured by the camera 207, iris recognition using the iris, or fingerprint recognition using a fingerprint sensor connected to the interface 208.

[0046] The local virtual object management unit 356 manages information such as virtual objects and 3D data of avatars acquired from the virtual space management system 111 on client terminals 121 and 131. The virtual object acquisition unit 358 acquires information such as virtual objects and 3D data of avatars from the virtual object provision unit 318 and stores it in the local virtual object management unit 356.

[0047] The local location information management unit 360 manages the location information of virtual objects and avatars in the virtual space, as shown in Tables 2 and 3, which is obtained from the virtual space management system 111. The local location information management unit 360 also has the function of detecting the location of virtual objects and avatars on the client terminals 121 and 131 that have changed due to their operation, and saving the location information to the local location information management unit 360 itself.

[0048] The location information transmission unit 362 transmits the location information of virtual objects and avatars to the location information reception unit 322 when there is a change in location information in the virtual space due to operations on client terminals 121 and 131, or periodically. The location information acquisition unit 364 periodically acquires the location information of virtual objects and avatars from the location information provision unit 324 and stores it in the local location information management unit 360. Through the functions of 352 to 364, the behavior and status of virtual objects and other avatars in the virtual space provided by the virtual space management system 111 can be reflected on the display 206 in real time.

[0049] The content acquisition unit 366 and the sharing status acquisition unit 368 are part of the characteristic components of the present invention for sharing private content with other avatars. The content acquisition unit 366 acquires private content from the content provision unit 330 when it is permitted to share the private content as a recipient user (as listed in the recipient user column of Table 4). The display unit 352 then maps the private content acquired by the content acquisition unit 366 onto a user device object deployed in the virtual space, enabling control as if viewing a PC screen in the real world from the virtual space. The sharing status acquisition unit 368 acquires the sharing status of the private content from the sharing status provision unit 334, as shown in Table 4, when its own private content is in a shared state. The information on the sharing status that the sharing status acquisition unit 368 can acquire is used to understand which avatar the private content sharing source user is sharing it with. Alternatively, it is also used to determine which private content the recipient user will acquire.

[0050] Finally, the software configuration of client terminals 122 and 132 will be described. Client terminals 122 and 132 consist of a display unit 382, ​​a login unit 384, and a content transmission unit 386.

[0051] The display unit 382 displays content on the PC displays 206 of the client terminals 122 and 132 in the real world. The login unit 384, like the login unit 354, transmits the username and password entered by the input device connected to the interface 208 to the login processing unit 314. The content transmission unit 386 periodically transmits the content displayed on the PC screens of the client terminals 122 and 132 in the real world to the content receiving unit 328.

[0052] The content transmission unit 386 periodically transmits private content to the content receiving unit 328, and the content acquisition unit 366 periodically retrieves it from the content provision unit 330. This makes it possible for client terminals 121 and 131 to access content that would normally only be accessible from client terminals 122 and 132. It is obvious that if the logged-in user of the client terminal transmitting the private content is the same as the logged-in user of the client terminal acquiring the private content, the private content can be acquired regardless of the sharing status. Furthermore, if local communication is possible between the client terminals via interface 208 or the like, it is also possible to send and receive private content in a configuration that does not go through the virtual space management system 111.

[0053] Figures 4, 5, and 6 illustrate how to share private content with other people's avatars located near your own in a virtual space.

[0054] Figures 4(a) to 4(d) all show images of the virtual space displayed on the displays 206 of client terminals 121 and 131, illustrating examples of gestures used by each avatar to share private content in this embodiment.

[0055] Figure 5 shows an example of the sequence from the owner of private content (hereinafter referred to as the owner) to sharing the content with another user's (hereinafter referred to as the non-owner) avatar. Figures 6(a) to 6(c) are flowcharts that explain the processes within the sequence shown in Figure 5.

[0056] In this embodiment, the owner operates client terminal 121 (HMD) and client terminal 122 (PC), and is the user A in the user ID column of Tables 1, 2, and 4 mentioned above. Figures 4(a) and 4(d) represent the images displayed on the display 206 of the owner's client terminal 121. On the other hand, the non-owner operates client terminal 131 (HMD), and is the user B in the user ID column of Tables 1, 2, and 4 mentioned above. Figures 4(b) and 4(c) represent the images displayed on the display 206 of the non-owner's client terminal 131.

[0057] Figure 4(a) is a video of the virtual space from the owner's perspective, as described above. 412 indicates the display 206 of the client terminal 121. The virtual object 414 is the owner's user device object, which corresponds to the client terminal 122 brought into the virtual space. Since Figure 4(a) is from the owner's perspective, private content is displayed on the virtual object 414, which is the user device object. The virtual object 416 is a virtual object representing the owner's avatar's fingers in the virtual space, and is synchronized with the movement of the fingers in the real world.

[0058] Figure 4(b) shows the virtual space from the non-owner's perspective. 432 indicates the display 206 of the client terminal 131. Avatar 434 is the avatar of userA, the owner. Virtual object 436 is a virtual object representing the fingers of avatar 434. Virtual object 438 is a virtual object representing the fingers of userB, the non-owner, and is synchronized with the movement of the fingers in the real world, as in the case of Figure 4(a). Virtual object 440 is the owner's user device object, corresponding to the client terminal 122 that the owner brought into the virtual space. At this stage, from the non-owner's perspective, the virtual object 440 itself, which is the user device object, can be seen, but the private content displayed on virtual object 440 cannot be seen.

[0059] Figure 4(c) shows the virtual space from the non-owner's perspective. In Figure 4(c), the owner avatar 434's virtual object 436 (left hand) is in contact with the user device object, virtual object 414. Also, the owner avatar 434's virtual object 436 (right hand) is in contact with the non-owner avatar's fingers, virtual object 438. In this embodiment, sharing of private content is permitted on the condition that the owner avatar 434 touches the user device object displaying the private content it wishes to share, and also touches the non-owner avatar to whom the content will be shared. The process of determining contact with virtual objects and determining sharing permission is explained in the flowchart of Figure 6. After sharing is permitted, the private content is displayed on the user device object, virtual object 414, even from the non-owner's perspective in Figure 4(c).

[0060] Figure 4(d) shows the virtual space from the owner's perspective, and is a diagram showing the image after permission has been granted to share private content, as explained in Figure 4(c). Virtual object 472 is showing that it is sharing private content with userB, who is not the owner's avatar.

[0061] Next, we will explain the overall processing sequence using Figure 5.

[0062] In S502, the login unit 384 of userA's client terminal 122 (PC), the owner of the private content, sends the user ID and password to the login processing unit 314. In S504, the login processing unit 314 verifies that the user ID and password managed by the user management unit 312 match those of userA, and if they match, returns the login result as successful. Similarly, in S506, the login unit 384 of userA's client terminal 121 (HMD) sends the user ID and password to the login processing unit 314. In S508, the login processing unit 314 verifies that the user ID and password managed by the user management unit 312 match those of userA, and if they match, returns the login result as successful. Assume that the same user ID is used in S502 and S504.

[0063] In S510, the content transmission unit 386 of the client terminal 122 transmits the private content displayed on the PC screen to the content receiving unit 328. At this time, the private content transmitted by the content receiving unit 328 is managed by the content management unit 326 using the ID shown in the object ID column of Table 1 as an identifier. In S512, the content receiving unit 328 returns a response indicating that the reception of the private content is complete. From here on, S510 and S512 are executed asynchronously and periodically with respect to other steps.

[0064] In S514, the content acquisition unit 366 of the client terminal 122 sends a request to the content provision unit 330 to acquire private content. In S516, the content provision unit 330 returns a response to the content acquisition unit 366 that includes the data of the private content. In S518, the display unit 352 of the client terminal 122 displays the private content acquired in S516 on the display 206 of the client terminal 122 as shown in Figure 4(a). From here on, steps S514 to S518 are executed asynchronously and periodically with respect to other steps.

[0065] In S522, the login unit 354 of the non-owner userB's client terminal 131 (HMD) sends the user ID and password to the login processing unit 314. In S524, the login processing unit 314 checks if the user ID and password managed by the user management unit 312 match those of userB, and if they match, it returns the login result as successful. At this point, the display 206 of the client terminal 131 shows an image of the virtual space as shown in Figure 4(b).

[0066] Subsequently, steps S532 to S543 execute the operations, contact detection, and sharing permission detection steps for each avatar shown in Figure 4(c), and these steps are performed asynchronously and periodically from the other steps.

[0067] In S532, the owner manipulates the avatar's fingers from the client terminal 121. At this time, the local location information management unit 360 acquires the location information of userA's avatar's fingers based on the finger manipulation and transmits the location information from the location information transmission unit 362 to the location information receiving unit 322. As a result, the location information management unit 320 updates userA's location information as shown in Table 2. In S534, the location information receiving unit 322 returns to the location information transmission unit 362 that it has completed reception. In S536, the shared state management unit 332 determines whether the owner avatar and the user device object are in contact. Hereinafter, the state in which the owner avatar and the user device object are in contact will be referred to as the first contact state.

[0068] Here, the specific processing details of S536 will be explained using the flowchart in Figure 6(a).

[0069] In S612, the shared state management unit 332 obtains the location information of the owner avatar and user device object shown in Tables 2 and 3 from the location information management unit 320 and proceeds to S614. In S614, the shared state management unit 332 determines whether the owner avatar and user device object are in contact. Specifically, the shared state management unit 332 determines whether they are in contact based on the coordinates of each avatar and virtual object obtained in S612. If the shared state management unit 332 determines in S614 that they are in contact, it executes S616; otherwise, it executes S618. In S616, the shared state management unit 332 sets the contact state (first contact state) between the owner avatar and user device object shown in Table 4 to contact state (ON) and terminates the process. On the other hand, in S618, the shared state management unit 332 sets the contact state (first contact state) between the owner avatar and user device object shown in Table 4 to contact state (OFF) and terminates the process.

[0070] Next, in S538, the non-owner manipulates the avatar's fingers from the client terminal 131. At this time, the local location information management unit 360 acquires the location information of userB's avatar's fingers based on the finger manipulation and transmits the location information from the location information transmission unit 362 to the location information receiving unit 322. As a result, the location information management unit 320 updates userB's location information as shown in Table 2. In S540, the location information receiving unit 322 returns to the location information transmission unit 362 that it has completed reception. In S542, the shared state management unit 332 determines whether the avatars are in contact with each other.

[0071] Hereafter, the state in which avatars are in contact with each other will be referred to as the second contact state. The specific processing details of S542 will be explained using the flowchart in Figure 6(b).

[0072] In S632, the shared state management unit 332 obtains the location information of each avatar shown in Table 2 from the location information management unit 320 and proceeds to S634. In S634, the shared state management unit 332 determines the contact status between avatars, updates the contact user column in Table 4, and then terminates processing. The contact status is determined based on the coordinates of the avatars, similar to S614. In this embodiment, main coordinates, left-hand coordinates, and right-hand coordinates are defined for each avatar, and the shared state management unit 332 determines that the avatars are in contact if the coordinates of any part of the avatar are close together.

[0073] Then, in S543, the sharing status management unit 332 makes a decision on whether or not to allow the owner's private content to be shared with non-owners. The specific processing details of S543 are explained using Figure 6(c).

[0074] In S652, the shared state management unit 332 obtains the contact status from the shared state management table shown in Table 4 and proceeds to S654. In S654, the shared state management unit 332 makes a sharing permission decision based on the first and second contact statuses obtained in S652. Specifically, the shared state management unit 332 checks if there are avatars that are in a relationship with the second contact status and the first contact status is ON. If the conditions are met, the process proceeds to S656; otherwise, the process ends. Using Table 4 as an example, for userA, the contact column with the user device object (first contact status) is ON, and userB exists as a contact user in the contact user column (second contact status). Therefore, in S656, the shared state management unit 332 determines that the conditions are met. In S656, the shared state management unit 332 enables the sharing status of private content for non-owner avatars that are in a relationship with the second contact status. Using Table 4 as an example, since the non-owner avatar in the second contact state relationship is userB, the sharing state management unit 332 sets userB in the shared user column for userA in Table 4 and enables permission for userB to share private content.

[0075] Steps S544-S550 involve processing between userB's client terminal 131 (who is not the owner) and the virtual space management system 111, and are performed asynchronously and periodically with respect to the other steps.

[0076] In S544, the shared status acquisition unit 368 of the client terminal 131 requests the shared status provision unit 334 to acquire a list of object IDs associated with private content that is in a shared state. In S545, the shared status provision unit 334 refers to the shared destination user column in Table 4, and if the user requested in S544 is included in the shared destination, it acquires the object ID of the source user from the object ID column in Table 1. Then, the shared status provision unit 334 returns a list of object IDs of all source users to the shared status acquisition unit 368 of the client terminal 131. In S546, the content acquisition unit 366 of the client terminal 131 sends a request to the content provision unit 330 to acquire the private content associated with the object ID acquired in S545. In S548, the content provision unit 330 refers to the shared status management unit table in Table 4, which is managed by the shared status management unit 332, and if sharing permission has been granted to the requesting user, it returns the private content to the content acquisition unit 366. Using Table 4 as an example, since userB has permission to share private content as a sharing recipient user, the content acquisition unit 366 of the client terminal 131 can acquire the private content.

[0077] In S550, the display unit 382 of the client terminal 131 displays the user device object, including the private content acquired in S548, on the display 206 of the client terminal 131 (the state shown in Figure 4(c)). If the shared state acquisition unit 368 of the client terminal 131 acquires multiple object IDs in S545, the content acquisition unit 366 of the client terminal 131 can acquire multiple private content items in S548. In this case, in S550, the display unit 382 of the client terminal 131 can display the user device object, including the multiple private content items acquired in S548, on the display 206 of the client terminal 131.

[0078] Steps S552-S556 are processes between the owner userA's client terminal 121 and the virtual space management system 111, and are to be executed asynchronously and periodically from the other steps.

[0079] In S552, the sharing status acquisition unit 368 of the client terminal 121 executes a request to the sharing status provision unit 334 to acquire the sharing status. In S554, the sharing status provision unit 334 returns the sharing status data shown in Table 4 to the sharing status acquisition unit 368 of the client terminal 121. In S556, the display unit 352 of the client terminal 121 displays the users to whom the private content is shared on the display 206, as shown in the virtual object 472 in Figure 4(d), based on the acquired sharing status.

[0080] As described above, this embodiment explains a method for determining permission to share private content based on contact with avatars or virtual objects within a virtual space. This method allows sharing private content with a specific avatar nearby in the virtual space using only a simple gesture.

[0081] In this embodiment, permission to share private content was determined based on physical contact, but any other gesture may be used as long as it can identify the user device object displaying the private content to be shared and the recipient avatar.

[0082] For example, information indicating orientation in addition to coordinates could be assigned to the user device object or avatar, and sharing of private content could be permitted when the user device object and a non-owner avatar face each other within a predetermined distance. Alternatively, private content could be shared when the owner avatar and a non-owner avatar face each other within a predetermined distance. Therefore, the method of sharing private content is not limited to the contact-based method described in this embodiment; it is also possible to share private content based on the positional relationship between the user device object and the avatar, or the gestures exchanged between the avatars.

[0083] Furthermore, private content can be shared through operations other than avatar gestures within the virtual space. For example, the owner notifies the non-owner outside the virtual space of an ID that has been signed, which can be obtained through a request equivalent to S545. Then, the content acquisition unit 366 of the non-owner's client terminal 131 includes that ID in the request and executes S546 within the virtual space. Then, in S548, the content provision unit 330 verifies the signed ID, and if the signature is correct, it returns the private content to the content acquisition unit 366. In this way, the content acquisition unit 366 of the non-owner's client terminal 131 can acquire private content from the content provision unit 330 without avatar gestures within the virtual space.

[0084] Furthermore, the owner of private content can bring the client terminal 122 into the virtual space in a mode that does not share the private content. In that case, even if the conditions for determining sharing permission described in this embodiment are met, the sharing state management unit 332 will control the private content so as not to be shared with other avatars.

[0085] From a usability standpoint, it is desirable that private content, once shared, remains shared even after the avatars have separated. However, it is possible that the owner might forget to explicitly cancel the sharing. Considering such cases, an example of how to cancel the sharing is explained using Figure 7.

[0086] Figures 7(a) and 7(b) are flowcharts showing the process for releasing the sharing status of private content, and are performed asynchronously and periodically from each step in the sequence diagram in Figure 5.

[0087] First, Figure 7(a) explains the method for determining whether to terminate the shared state based on the distance between the owner avatar and the non-owner avatar in the virtual space.

[0088] In S712, the shared state management unit 332 obtains the location information of the avatars that are in a shared relationship based on the data in Tables 2 and 4. In this embodiment, userA and userB are in a shared relationship, so the shared state management unit 332 obtains the location information of each of their avatars. Then the process proceeds to S714.

[0089] In S714, the shared state management unit 332 determines whether the owner avatar and the shared avatar are separated by a predetermined distance or more. If it determines they are separated, it proceeds to S714; otherwise, it terminates the process. The predetermined distance is an arbitrary threshold defined by the virtual space management system 111. The shared state management unit 332 calculates the distance from the coordinate values ​​in the main coordinate column of the avatar in Table 2 and determines truth or falsity by comparing it with the threshold. Alternatively, the shared state management unit 332 can determine truth or falsity based on the difference in the spatial ID, for example, by referring to the spatial ID column in Table 2, rather than using a numerical value for distance. In S716, the shared state management unit 332 turns OFF the sharing status of private content to the shared avatar and terminates the process.

[0090] Next, Figure 7(b) explains how to determine whether to remove the sharing status based on the login status of the user to whom the sharing is being shared.

[0091] In S732, the shared state management unit 332 uses the data from Tables 1 and 4 to obtain the login status of the shared avatar and proceeds to S734. In S734, the shared state management unit 332 determines whether the shared avatar is logged out based on the login status of the shared avatar obtained in S732. If the avatar is logged out, the process proceeds to S736; otherwise, the process ends. In S736, the shared state management unit 332 turns off the sharing status of private content to the shared avatar and ends the process.

[0092] As described above, it is also possible to automatically disable the sharing of private content depending on the relative positions of avatars in the virtual space and the login status. Note that the methods for disabling sharing shown in Figure 7 are just examples and are not the only methods that can be used.

[0093] (Example 2) Example 1 described a method for sharing private content between two people, the owner and the non-owner. However, there are also cases where you want to share private content with multiple avatars that are nearby in the virtual space with a single action. Example 2 describes a method for sharing private content with multiple avatars with a single action.

[0094] In Example 2, similar to Example 1, userA, the owner of the private content, is treated as the owner avatar, and userB is treated as a non-owner avatar. In addition, userC is also treated as a non-owner avatar. Tables 1', 2', and 4', which are modified versions of the data in Tables 1, 2, and 4 explained in Example 1, are shown below.

[0095] [Table 5]

[0096] [Table 6]

[0097] [Table 7]

[0098] The contents of each column are the same as in Example 1, but the concept of "indirectly contacted users" has been added to the "contacted users" column in Table 4'. Indirectly contacted users are users who have not had direct contact but have had indirect contact through other avatars. Now we will move on to the explanation of Figure 8.

[0099] Figure 8(a) shows the virtual space as seen from a non-owner avatar client terminal 131, and is a diagram of Figure 4(c) with avatar 812 added. Here, avatar 434 is userA, avatar 812 is userB, and the avatar with virtual object 438 (fingers) is userC. Avatar 812 is in contact with avatar 434, which is the owner avatar. On the other hand, the avatar of virtual object 438 is in contact with avatar 812 but not with avatar 434. In Example 2, the shared state management unit 332 determines that the avatar with virtual object 438 is indirectly in contact with avatar 434 via avatar 812, and adds it to the contact user column in Table 4' as an indirect contact user.

[0100] Figure 8(b) shows the virtual space as seen from the client terminal 121 of the owner avatar (userA) when userC, an indirect contact user, is set to a shared state as a shared user. The virtual object 832 is the same virtual object as the virtual object 472 in Example 1, and in Example 2, it shows that userB and userC are in a shared state as shared users.

[0101] Figure 8(c) is a flowchart that adds the judgment of the indirectly contacted user to the flowchart in Figure 6(b).

[0102] In S852, similar to S632, the shared state management unit 332 acquires the location information of the avatars and proceeds to S854. In S854, the shared state management unit 332 updates the contact state (second contact state) of the avatars and proceeds to S856.

[0103] In S856, the shared state management unit 332 determines whether there are any avatars in an indirect contact state. If there are, it proceeds to S858; otherwise, it terminates the process. The indirect contact determination performed by the shared state management unit 332 is performed in the same way as described in Example 1, as the coordinates of the avatars can be obtained from Table 2', so it first extracts avatars that are in direct contact. After that, the shared state management unit 332 can determine the existence of avatars that are indirectly in contact by tracing the avatars that are in direct contact. In S858, the shared state management unit 332 reflects the contact state (second contact state) of the avatars that are indirectly in contact, extracted in S856, in Table 4'.

[0104] Using the method described above, even if there are multiple non-owner avatars, it becomes possible to share private content with non-owner avatars in a single action.

[0105] (Other examples) The present invention also includes apparatuses, systems, and methods configured by appropriately combining the embodiments described above.

[0106] Here, the present invention is a device or system that is the main body for executing one or more software programs that realize the functions of the embodiments described above. Furthermore, a method for realizing the embodiments described above that are executed on that device or system is also part of the present invention. In addition, the program is supplied to the system or device via a network or various storage media, and the program is read into one or more memories by one or more computers (CPU, MPU, etc.) of the system or device and executed. In other words, as part of the present invention, the program itself or various storage media that can be read by the computer storing the program are also included. Furthermore, the present invention can also be realized by a circuit (e.g., ASIC) that realizes the functions of the embodiments described above. [Explanation of symbols]

[0107] 111 Virtual Space Management System 121, 131 Client terminals

Claims

1. A virtual space management system that manages a virtual space in which multiple users can participate as avatars using client terminals, The first providing means controls the provision of the virtual space via the client terminal of the first user and the client terminal of the second user, A second providing means for controlling the provision of virtual objects in the aforementioned virtual space, The second means of provision described above further, Control that the user device objects owned by the first user in the virtual space are provided via the first user's client terminal and the second user's client terminal. Control the display area of ​​the user device object so that the private content of the first user is provided via the client terminal of the first user. A virtual space management system characterized by also controlling whether the private content is provided via the second user's client terminal based on gestures, including contact between the first user's avatar and the second user's avatar, by the first user's avatar in the virtual space.

2. The virtual space management system according to claim 1, further characterized in that the second providing means controls the private content not to be provided via the second user's client terminal when the distance between the first user's avatar and the second user's avatar in the virtual space exceeds a predetermined distance.

3. A method in a virtual space management system that manages a virtual space in which multiple users can participate as avatars using client terminals, A first provisioning step involves controlling the provision of the virtual space via the client terminal of the first user and the client terminal of the second user, A second provisioning step controls the provision of virtual objects in the aforementioned virtual space, In the above second supply process, further, The user device objects owned by the first user in the virtual space are controlled to be provided via the first user's client terminal and the second user's client terminal. The display area of ​​the user device object is controlled to provide the first user's private content via the first user's client terminal. A method characterized in that the private content is also controlled to be provided via the second user's client terminal based on gestures, including contact between the first user's avatar and the second user's avatar by the first user's avatar in the virtual space.

4. A client terminal, A first control means that performs control for displaying a virtual space provided by a virtual space management system, in which a user using a client terminal can participate as an avatar, for the user of the client terminal, The system includes a second control means that performs control for displaying the virtual objects provided by the virtual space management system for the user of the client terminal, The second control means is, When the avatar of the client terminal user participates in the virtual space, and user device objects and private content of another user provided in the virtual space are provided to that other user, the private content is provided to the client terminal by the virtual space management system based on gestures including contact between the user device objects and the client terminal user avatar by the other user's avatar in the virtual space, thereby executing controls to display the private content for the client terminal user as well. A client terminal characterized by the following features.

Images