Methods and systems for determining the authenticity of modified objects in a virtual environment

Information

  • Patent Grant
  • 11957984
  • Patent Number
    11,957,984
  • Date Filed
    Tuesday, March 16, 2021
    3 years ago
  • Date Issued
    Tuesday, April 16, 2024
    8 months ago
Abstract
A server computer is connected to a plurality of client computers through a network, and controls objects in a Metaverse accessed by the client computers. The server computer includes a storage unit for storing an object ID specifying an object accessible in the Metaverse by the plurality of client computers and authenticity information associated with the object ID. The authenticity information indicates that the object is genuine. The server computer also includes a communication unit for communicating with each of the client computers. The server computer also includes an enquiry unit for causing the communication unit to transmit the authenticity information corresponding to the object ID to at least one of the plurality of client computers upon receipt of an enquiry request to enquire about the object ID of the object from one of the plurality of client computers.
Description
BACKGROUND

The present embodiments relates to a technique for determining whether an object is genuine or fake in a Metaverse.


In recent years, the number of users of Metaverses has been expanding rapidly. A Metaverse is a three-dimensional virtual world formed as electronic data, such as a virtual world or a massively-multiplayer online role-playing game (MMORPG). In some recent types of Metaverses, users are allowed to generate objects freely. Generally, users can restrict copying and giving of generated objects. Due to the rareness of these objects, objects, such as avatar clothing and game items, are purchased and sold (by use of virtual world currency or real world currency) in Metaverses. For examples of conventional techniques relating to Metaverses, see Japanese Patent Application Publication Nos. 2005-50081 and 2005-234633.


However, since the objects are pieces of electronic data, unauthorized copies or the like are made in some cases. For example, a malicious user may make a copy of an object existing in a Metaverse in a certain place outside the Metaverse (such as in a storage device in the real world), and bring back the copied object to the Metaverse pretending that the object is an original. Such copying becomes a serious problem particularly in the case where it is important to determine whether the object is genuine or fake (for example, where the object is a luxury brand item or an employee badge in the Metaverse). With the increase in the number of users and contents in Metaverses in the future, it may become increasingly important to be able to determine whether an object is genuine or fake, in order to maintain and improve brand images as well as to assure company security, for example. On the other hand, excessive restriction on users generating objects in Metaverses and on users bringing in objects from outside may inhibit free activities of users, which spoils the merits and pleasure of the Metaverses. The present embodiments are provided in view of such technical problems, and one object thereof is to provide means for determining whether an object is genuine or fake with a simple system configuration, while assuring users in the Metaverse to freely generate objects and to bring in objects from outside the Metaverse.


SUMMARY

The present embodiments include a server computer connected to a plurality of client computers through a network, and controls objects in a Metaverse accessed by the client computers. The server computer includes a storage unit for storing an object ID specifying an object accessible in the Metaverse by the plurality of client computers and authenticity information associated with the object ID. The authenticity information indicates that the object is genuine. The server computer also includes a communication unit for communicating with each of the client computers. The server computer also includes an enquiry unit for causing the communication unit to transmit the authenticity information corresponding to the object ID to at least one of the plurality of client computers upon receipt of an enquiry request to enquire about the object ID of the object from one of the plurality of client computers.


The present embodiments also include a method including storing in a server computer an object ID specifying an object in a Metaverse accessible by a plurality of client computers and authenticity information associated with the object ID, the authenticity information indicating that the object is genuine. The method includes receiving, by the server computer, from one of the plurality of client computers an enquiry request including the object ID to enquire about the object. The method further includes transmitting, by the server computer, the authenticity information corresponding to the object ID to the client computer, the server computer maintaining the authenticity information stored in the server computer.


The present embodiments also include a computer readable tangible medium incorporating a sequence of program instructions that when implemented, will cause a computer to perform a method including storing in a server computer an object ID specifying an object in a Metaverse accessible by a plurality of client computers and authenticity information associated with the object ID, the authenticity information indicating that the object is genuine. The method includes receiving, by the server computer, from one of the plurality of client computers an enquiry request including the object ID to enquire about the object. The method further includes transmitting, by the server computer, the authenticity information corresponding to the object ID to the client computer, the server computer maintaining the authenticity information stored in the server computer.





BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

For a more complete understanding of the present embodiments and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings.



FIG. 1 is a schematic view of an embodiment of the present disclosure.



FIG. 2 is a functional block diagram illustrating the function of an object management server 1C according to the embodiment of the present disclosure.



FIG. 3 is a schematic view illustrating the data structure of an object database 11 according to Example 1.



FIG. 4 is a schematic view illustrating the data structure of a management database 12 according to Example 1.



FIG. 5 is a conceptual diagram illustrating the genuine/fake determination of a bag object in the Metaverse, according to Example 1.



FIG. 6 is a flowchart for further explanation of step S1 in which user A applies for a brand.



FIG. 7 is a schematic view of the management database 12 in a state where a new entry is registered.



FIG. 8 is a flowchart for further explanation of step S2 in which user A carries out settings for the brand.



FIG. 9 is a schematic view of the object database 11 before and after the brand setting.



FIG. 10 is a flowchart for further explanation of step S3 of object giving.



FIG. 11 is a schematic view of the object database 11 before and after the object giving.



FIG. 12 is a flowchart for further explanation of step S4 of object copying.



FIG. 13 is a schematic view of the object database 11 illustrating object copying, object modification, and object creation.



FIG. 14 is a flowchart for further explanation of step S5 of object modification.



FIG. 15 is a flowchart for further explanation of step S6 of object creation.



FIG. 16 is a flowchart for further explanation of step S6 of object enquiry.



FIG. 17 is a schematic view of the data structure of a management database 12 according to Example 2.



FIG. 18 is a schematic view of the data structure of a management database 12 according to Example 3.



FIG. 19 is a schematic view illustrating a hardware configuration of the object management server 1C.





DETAILED DESCRIPTION

An enquiry request may be transmitted from a client computer to the server in response to an action of an avatar in the Metaverse. Specifically, first and second users access the Metaverse as first and second avatars, through first and second client computers, respectively, and the object is owned by the first avatar. The enquiry unit receives an enquiry request on condition that the second avatar makes an enquiry for the object in the Metaverse, and has authenticity information of the object transmitted to the second client computer (so as to be recognizable by the second avatar in the Metaverse), on condition that the authenticity information corresponding to the object ID is stored.


More specific application examples of this aspect include cases where the object is a luxury brand product and where the object is an employee badge. That is, the object is an accessory object for avatars in the Metaverse; and the authenticity information further includes manager information specifying a manager of the brand of the accessory object, a brand name indicating the name of the brand, and logo data indicating the logo of the brand. Moreover, upon receipt of an enquiry including an object ID to enquire about the object of the object ID from a certain client computer, the enquiry unit may have transmit, at least one of the manager information, the brand name, and the logo data corresponding to the object ID transmitted to the client computer, on condition that the authenticity information corresponding to the object ID is stored in the storage unit. The object may also be an employee badge object of an avatar in the Metaverse; and the authenticity information further includes owner information specifying an owner of the employee badge object, a company name indicating the name of the company, and logo data indicating the logo of the company. Moreover, upon receipt of an enquiry request including an object ID to enquire about the object of the object ID from a certain client computer, the enquiry unit may transmit at least one of the owner information, the company name, and the logo data corresponding to the object ID transmitted to the client computer, on condition that the authenticity information corresponding to the object ID is stored in the storage unit.


An expiration time of an object can be referred to as a condition of transmitting authenticity information. Specifically, the object information includes time period information indicating an expiration time of the authenticity information; and upon receipt of an enquiry request including an object ID to enquire about the object of the object ID from a certain client computer, the enquiry unit has authenticity information corresponding to the object ID transmitted to the client computer, on condition that the authenticity information corresponding to the object ID is stored in the storage unit and is still valid since its expiration time has not come yet. More specific application examples of this aspect include a case where the object is a ticket having the expiration time in the Metaverse.


In contrast, if authenticity information is not stored in the storage unit, the enquiry unit notifies the client computer of the fact. Specifically, upon receipt of an enquiry request including an object ID to enquire about the object of the object ID from a certain client computer, the enquiry unit has a notification that authenticity information is not stored transmitted to the client computer, on condition that the authenticity information corresponding to the object ID is not stored in the storage unit. The notification that the authenticity information is not stored is transmitted to the client computer which has transmitted the enquiry request. In addition, the notification may be configured to be transmitted also to a predetermined server or a client computer (such as an administrative server administrating the Metaverse).


The notification may be transmitted to a user who created the object (a user who created the object in the Metaverse or who brought the object in to the Metaverse). That is, the object information includes history information indicating at least any one of creation, copying, modification, and giving of the object; and the enquiry unit may specify an original user of the object according to the history information, and transmit a notification that the authenticity information is not stored to a client computer of the original user.


The object information may further separately include owner information specifying the owner of the object and manager information specifying the manager of the object. The authenticity information or the message indicating that the authenticity information is not stored may be transmitted according to the owner information and the manager information, to client computers of the owner and manager.


Processing for copying, modification and giving of an object in the Metaverse may be carried out in the following manner, for example. As for object copying, the object information includes form data of the object; and the server may further include an update unit which copies the form data of an object before the copying upon receipt of a copying request including an object ID to copy the object of the object ID from a certain client computer, and which invalidates authenticity information of the copied object and generates a new record in the storage unit. As for object modification, the object information further includes form data of the object; and the server may further include an update unit which modifies the form data of an object before the modification upon receipt of a modification request including an object ID to modify the object of the object ID from a certain client computer, and which invalidates authenticity information of the modified object and generates a new record in the storage unit. As for object creation, the object information further includes form data of the object; and the server may further include an update unit which registers form data of a new object upon receipt of a new object creation request including form data from a certain client computer, and which does not store authenticity information of the new object and generates a new record in the storage unit. As for object giving, the object is owned by a first user; and the object information further includes owner information specifying the owner of the object.


The server computer may further comprise an update unit which changes the owner information from the first user to a second user, upon receipt of a giving request to give the object from the first user to the second user including a corresponding object ID, and which does not change the authenticity information. Note that the object may be given from a first avatar to a second avatar, in the Metaverse to which the first and second users log in as the first and second avatars through the first and second client computers, respectively. In other words, authenticity information is not registered with object creation, existing authenticity information is invalidated with object copying or modification, and existing authenticity information is kept the same with object giving.


The registration and setting of authenticity information is carried out as follows in the case where the object is, for instance, a brand product. Specifically, the object is an accessory object for avatars in the Metaverse; and the authenticity information further includes manager information specifying a manager of the brand of the accessory object and a brand name indicating the name of the brand.


The server computer may further include a registration unit. Upon receipt of a brand registration request to register a certain user as a manager of a brand from a certain client computer, the registration unit registers, in the storage unit, the user as the manager of the brand and the brand name as the name of the brand, on condition that the same brand name is not already registered with another user assigned as the manager. Upon receipt of an accessory object registration request to register a certain accessory object as a genuine object from a certain client computer, the registration unit may register, in the storage unit, a corresponding object ID and authenticity information in association with each other as object information, on condition that the user of the client computer is registered as the manager of the brand. In the case where the object is an employee badge, the procedure is as follows. Specifically, the object is an employee badge object of an avatar in the Metaverse, and the authenticity information further includes owner information specifying an owner of the employee badge object and a company name indicating the name of the company.


The server computer may further include a registration unit. Upon receipt of an employee badge registration request to register a certain user as an owner of a certain employee badge object from a certain client computer, the registration unit registers, in the storage unit, the user as the owner of the employee badge object and the company name as the name of the company, on condition that the same company name is not already registered with another user assigned as the owner. Upon receipt of an employee badge object registration request to register a certain employee badge object as a genuine object from a certain client computer, the registration unit may register a corresponding object ID and authenticity information in association with each other as object information in the storage unit, when the user of the client computer is registered as the owner of the employee badge object.


Referring to FIG. 1, further details of the embodiments will be clear from a schematic view showing an embodiment of the present disclosure. As shown in FIG. 1, the Metaverse system is configured with multiple clients 3A to 3N including clients (client computers) 3A to 3C, a server (server computer) 1, and a network 2 connecting the clients 3A to 3N and the server 1. Although a personal computer is assumed as each of the clients 3A to 3N in the embodiment, the invention is not limited to this. A PDA, a mobile phone, a dedicated gaming machine, an appliance, or other similar devices may be employed instead. Although a PC server is assumed as the server 1 in the embodiment, the invention is not limited to this. A blade server, a large general-purpose computer, or the like may be also employed otherwise. Note that the server 1 may include multiple servers, each serving a corresponding function of the server 1. Examples of the servers provided in the server 1 are a login server 1A responsible for login of users to the Metaverse, an environment server 1B that provides a Metaverse environment for each avatar representing a corresponding user, and an object management server (server) 1C that manages objects in the Metaverse.


The servers for respective functions may be configured in grids of multiple servers. Although the Internet is assumed as the network 2 in the embodiment, networks such as an intranet, an extranet, or other networks, or a network including these networks may also be employed. As the platform of the Metaverse in which the users A to C participate as avatars A to C through the respective clients 3A to 3C, Second Life of Linden Lab of the United States, meet-me of Co-Core Inc. of Japan, HiPiHi World of HiPiHi Co., Ltd of China, Ultima Online of Origin Systems, Inc. of the United States, Lineage of NCsoft Corporation of Korea, or others may be used. Since system configurations of the login server 1A and the environment server 1B are already known, details thereof will be omitted here. The hardware and software configuration of the object management server 1C will be described later with reference to FIG. 19.



FIG. 2 is a functional block diagram illustrating functions of the object management server 1C according to an embodiment of the present disclosure. The object management server 1C includes: a storage module (storage unit) 10 for storing object information and management information; a communication module (communication unit) 13 for communicating with the clients 3A to 3N through the network 2; a registration module (registration unit) 14 for newly registering information in the storage module 10; an update module (update unit) 15 for updating the information stored in the storage module 10; an enquiry module (enquiry unit) 16 for responding to enquiries on the basis of the information stored in the storage module 10. The storage module 10 further includes an object database 11 for storing object information, and a management database 12 for storing management information.


EXAMPLE 1

Hereinafter, as Example 1, a description will be given of a case of determining whether a bag object (accessory object), which is an object in the Metaverse, is genuine or fake.



FIG. 3 is a schematic view of the data structure of the object database 11 according to Example 1. As shown in FIG. 3, entries (records) in the object database 11 include: object IDs for specifying individual bag objects; 3D form data of bag objects in the Metaverse; object owner information for specifying the owners of the bag objects; history information indicating an update history of the bag objects; and brand IDs (authenticity information) each pointing to management information of the corresponding bag object. Meanwhile, FIG. 4 is a schematic view illustrating the data structure of the management database 12 according to Example 1. As shown in FIG. 4, entries (records) in the management database 12 include: brand IDs (authenticity information) for specifying the brands; manager information (authenticity information) for specifying the manager of each brand; names of the brands (authenticity information); and brand logo data (authenticity information). Note that, as a matter of course, other types of information may be registered as object information and management information.



FIG. 5 is a conceptual diagram illustrating the genuine/fake determination of a bag object in the Metaverse, according to Example 1. Here, suppose that users A to C log in through respective clients 3A to 3C, and participate in the Metaverse as avatars A to C. Additionally, user A also manages brand A in the real world, and is the manufacturer and vendor (manager) of products (such as bags) of brand A. Avatar A is the manufacturer and vendor of product objects (including bag objects) of brand A in the Metaverse. Avatar B is a distributor of product objects (including bag objects) in the Metaverse. Avatar C is a consumer of product objects (such as bag objects) in the Metaverse. Hereinafter, a description will be given according to steps indicated by arrows S1 to S7.


(Brand Application)



FIG. 6 is a flowchart for explaining, in detail, a step indicated by an arrow S1 in FIG. 5, that is, step S1 in which user A applies for registration of a brand. The communication module 13 of the object management server 1C receives a brand application request from client 3A (step S11). The brand application request includes a brand name “A” and a logo “A logo” which user A wishes to register. Upon receipt of the brand application request, the registration module 14 of the brand management server 1C searches through the management database 12 to see whether the same brand name “A” is registered by users other than user A (any of users B to/V) (step S12). As long as the brand name “A” is not registered by other users, the registration module 14 registers a new entry in the management database 12 (step S13). Meanwhile, user A is allowed to register a different logo (such as “a logo”) for the same brand name “A”. The minimum condition here for brand application is the brand name not being registered. Instead, since processing for brand application is not carried out frequently, a more severe examination may be carried out by the manager of the Metaverse. For instance, the manager may carry out an examination on whether user A holds the right (trademark right) of the applied brand name in the real world. In addition, when the registration application is permitted, the manager may charge user A for the right to use the brand in the Metaverse.



FIG. 7 is a schematic view of the management database 12 in the state where a new entry is registered. As shown in FIG. 7, “201” is registered as the brand ID, “user A” is registered as the manager information, “A” is registered as the name of the brand, and “A logo” is registered as the logo data. Incidentally, the brand ID “201” is a value unique to this entry, which is automatically assigned by the registration module 14 to every entry. The manager information “user A” is specified by a user ID and a password inputted by the user at the time of log-in to the Metaverse, and is provided by the login server 1A. Moreover, the registration module 14 charges user A (according to need) (step S14). Then, the registration module 14 transmits the brand ID “201” to client 3A through the communication module 13 (step S15).


(Brand Setting)



FIG. 8 is a flowchart for explaining, in detail, a step indicated by an arrow S2 in FIG. 5, that is, step S2 in which user A carries out settings for the brand. The communication module 13 of the object management server 1C receives a brand setting request from client 3A (step S21). The brand setting request includes an object ID “101” and a brand ID “201” respectively of the object and the brand which user A wishes to set. Incidentally, the brand ID “201” is given by the register module 14 to user A in the brand application previously made (step S1). Upon receipt of the brand setting request, the registration module 14 of the object management server 1C searches through the management database 12, and determines whether or not user A that transmitted the brand setting request coincides with the brand manager “user A” of the brand ID “201” (step S22). Note that, as mentioned above, the user that transmitted the brand setting request is specified at the time of log-in to the Metaverse. Next, the registration module 14 searches through the object database 11, and determines whether or not user A that transmitted the brand setting request coincides with the object owner “user A” of the object ID “101” (step S23), and determines thereafter whether or not the brand ID of the object ID “101” is yet to be set (null) (step S24). When all of these conditions (steps S22 to 24) are satisfied, the registration module 14 changes the brand ID of the entry for the received object ID from “null” to “201” (step S25). Additionally, the registration module 14 charges user A (according to need) (step S26).



FIG. 9 is a schematic view of the object database 11 before and after brand setting is carried out. Entries for the object ID “101” before the brand setting include: form data “D (101)” of the bag object B (101); object owner information “user A” for specifying the owner of the bag object; history information “created by A” indicating the update history of the bag object B (101); and the brand ID “null” that points to management information of the bag object. Here, the history information “created by A” indicates that the form data “D (101)” was generated in the Metaverse or brought in from outside (the real world or another Metaverse) by user A. The brand ID “null” indicates that management information of the bag object B (101) is yet to be recorded. Meanwhile, after the brand setting, the brand ID of the entry for the object ID “101” is changed from “null” to “201”. The brand ID “201” indicates the existence of management information entries (manager information “user A”, name of brand “A”, and logo data “A logo”) specified by the brand ID “201” in the management database 12. No changes are made in the other entries: object ID “101”, form data “D (101)”, object owner information “user A”, and history information “created by A”. Incidentally, in response to the change in the brand ID from “null” to “201”, “brand set to 201” may be added to the history information “created by A”, to add the history of brand setting.


(Object Giving)



FIG. 10 is a flowchart for explaining, in detail, a step indicated by an arrow S3 in FIG. 5, that is, the object giving step S3 in which the bag object B (101) is given from the user A to the user B. The communication module 13 of the object management server 1C receives an object giving request from client 3A (step S31). The object giving request includes an object ID “101” of the object which the user A wishes to give and a user name “user B” of a user to which the user A wishes to give the object. Upon receipt of the object giving request, the update module 15 of the object management server 1C carries out a conventional check for object giving (step S32). Then, the update module 15 changes, among the entries for the object ID “101” in the object database 11, an entry of the object owner information from “user A” to “user B”, and additionally registers “given to B” to the history information “created by A” (step S33). Then, the update module 15 carries out a conventional processing for object giving (step S34).



FIG. 11 is a schematic view of the object database 11 before and after object giving. Entries for the object ID “101” before the object giving include: form data “D (101)” of the bag object B (101); object owner information “user A” for specifying the owner of the bag object B (101); history information “created by A” indicating the update history of the bag object B (101); and the brand ID “201” that points to management information of the bag object B (101). Meanwhile, after the user A gives the object to the user B, the object owner of the object ID “101” is changed from “user A” to “user B”, and “given to B” is added to the history information. The history information “given to B” indicates that the object B (101) is given to user B. No changes are made in the other entries: object ID “101”, form data “D (101)”, and brand ID “201”.


(Object Copying)



FIG. 12 is a flowchart for explaining, in detail, a step indicated by an arrow S4 in FIG. 5, that is, the object copying step S4 in which user B copies the bag object B (101) to create a new bag object B (102). The communication module 13 of the object management server 1C receives an object copying request from client 3B (step S41). The object copying request includes an object ID “101” of the object that user B wishes to copy. Upon receipt of the object copying request, the update module 15 of the object management server 1C carries out a conventional check for object copying (step S42). Then, the update module 15 generates a new entry (such as object ID “102”) in the object database 11 (step S43), and carries out a conventional processing for object copying (step S44).



FIG. 13 is a schematic view of the object database 11 for explaining object copying, object modification (to be described later), and object creation (to be described later). As has been described, the entry of the object ID “101” indicates the bag object B (101) given from user A to user B. Entries for the object ID “102” include: form data D (101); object owner “user B”; history information “copied from ID (101)”; and brand ID “null”. Here, the form data D (101) is copied from the entry for the object ID “101”. The history information “copied from ID (101)” indicates that the form data of this entry (for the object ID “102”) is copied from the object ID (101). Additionally, the brand ID “null” indicates that the brand ID has become invalid because the object has been copied.


(Object Modification)



FIG. 14 is a flowchart for explaining, in detail, a step indicated by a dashed line arrow S5 in FIG. 5, that is, the object modification step S5 in which user B creates a new bag object B (103) by modifying the bag object B (101). The communication module 13 of the object management server 1C receives an object modification request from client 3B (step S51). The object modification request includes an object ID “101” of the object before the modification by user B, and form data D (103) of the object after the modification. Upon receipt of the object modification request, the update module 15 of the object management server 1C carries out a conventional check for object modification (step S52). Then, the update module 15 creates a new entry (such as object ID “103”) in the object database 11 (step S53), and carries out a conventional processing for object modification (step S54). Referring back to the schematic view of the object database 11 in FIG. 13, entries for the object ID “103” include: form data D (103); object owner “user B”; history information “modified from ID (101)”; and brand ID “null”. Here, the form data D (103) is modified from the form data D (101) of the object ID “101”. The history information “modified from ID (101)” indicates that the form data of this object (of the object ID “103”) is modified from the form data of the object of the object ID “101”. Additionally, the brand ID “null” indicates that the brand ID has become invalid because the object has been modified.


(Object Creation)



FIG. 15 is a flowchart for explaining, in detail, a step indicated by a dashed line arrow S6 in FIG. 5, that is, the object creation step S6 in which user B creates a bag object B (104). The communication module 13 of the object management server 1C receives an object creation request from client 3B (step S61). The object creation request includes form data D (104) of the object that user B wishes to create. Upon receipt of the object creation request, the update module 15 of the object management server 1C carries out a conventional check for object creation (step S62). Then, the update module 15 creates a new entry (such as an object ID “104”) in the object database 11 (step S63), and carries out a conventional processing for object creation (step S64). Referring back to the schematic view of the object database 11 in FIG. 13, entries for the object ID “104” include: form data D (104); object user “user B”; history information “created by user B”; and brand ID “null”. The form data D (104) is created by user B. The history information “created by B” indicates that the form data D (104) is created in the Metaverse or brought in to the Metaverse from outside by user B. The brand ID “null” indicates that brand management information of the bag object B (104) is yet to be recorded. Thus, even if form data very similar to the “brand product” is brought in to the Metaverse from outside, not being assigned with a brand ID, it is possible to tell that the object is fake by making an object enquiry in the following manner.


(Object Enquiry)



FIG. 16 is a flowchart for explaining, in detail, a step indicated by an arrow S7 in FIG. 5, that is, the object enquiry step S7 in which user C makes enquiries for the bag objects B (101) to B (104). The communication module 13 of the object management server 1C receives an object enquiry request from client 3C (step S71). The object enquiry request includes an object ID of the bag object B for which user C wishes to make an enquiry. Upon receipt of the object enquiry request, the enquiry module 16 of the object management server 1C searches through the object database 11 and retrieves a brand ID of the entry for the received brand ID (step S72). The enquiry module 16 determines whether or not the brand ID is “null” (step S73). If the brand ID of the received object ID is not “null”, the enquiry module 16 searches through the management database 12, and transmits the brand name and logo of the brand ID to client 3C (step S74). Meanwhile, if the corresponding brand ID is “null”, the enquiry module 16 transmits a message indicating “no corresponding brand ID” to client 3C (step S75). Moreover, the enquiry module 16 may transmit an alert to a predetermined Metaverse administrator or concerned parties determined on the basis of history information.


More specifically, an object enquiry request is transmitted to the object management server 1C when user C clicks a bag object B in the Metaverse. If the bag object B is the bag object B (101), the brand ID is “201” instead of “null”, and thus the enquiry module 16 searches through the management database 12 and transmits the brand name “A” and its logo “A logo” of the brand ID “201” to client 3C (step S74). The brand name “A” and logo “A logo” are displayed to be recognizable by at least avatar C in the Metaverse. The brand name and logo may be displayed to be recognizable also by other avatars A and B. Here, it should be noted that, if the bag object B clicked by avatar C is the bag object B (101), the brand name “A” and logo “A logo” are displayed, regardless of whether the bag object B (101) has been given or not (see FIG. 11), that is, whether the owner of the bag object B (101) is user A or user B.


In contrast, if the bag object B that avatar C clicks in the Metaverse is any of the bag objects B (102) to B (104), the corresponding brand ID is “null” (see FIG. 13), and thus the enquiry module 16 transmits a message indicating “no corresponding brand ID” to client 3C (step S74). The message is displayed to be recognizable by at least avatar C in the Metaverse. The message may be displayed to be recognizable also by other avatars A and B. The enquiry module 16 may also transmit a message indicating “no corresponding brand ID” to the administrator of the Metaverse in the form of a mail. In other words, when avatar C clicks the bag object B (102) or B (103), the bag object B (101) being the original of the copying or modification is specified by the history information “copied from ID (101)” or “modified from ID (101)” of the entry. Moreover, the creator of the original bag object B (101) is specified as “user A” by the history information “created by A” of the entry. As a result, the enquiry module 16 may transmit an alert message to user A, as a concerned party, that “the bag object B (102) (or B (103)) owned by user B is a copy or modification of the bag object B (101) created by user A”. The alert message may otherwise be transmitted in response to an approval by user C. Here, note that the enquiry made by user C for the bag object B (102) or B (103) owned by avatar B allows transmission of an alert message to the original user A, who has no direct association with any of the avatars B and C or users B and C.


Although object owners and brand managers are specified by user names (such as “user A”) in Example 1, these may also be specified by avatar names (such as “avatar A”) in the Metaverse.


EXAMPLE 2

In Example 1, a case of determining whether a bag object in the Metaverse is genuine or fake has been described. In Example 2, a case of determining whether an employee badge object I in the Metaverse is genuine or fake will be described. FIG. 17 is a schematic view of the data structure of a management database 12 according to Example 2. As shown in FIG. 17, entries in the management database 12 include: corporate IDs (authenticity information) for specifying the companies, instead of brand IDs for specifying the brands; owner information (authenticity information) for specifying the owner of each employee badge object, instead of manager information for specifying the manager of each brand; company names showing names of the companies (authenticity information), instead of names of the brands; and company logo data (authenticity information) instead of the brand logo data.


A description will be given of an enquiry for the employee object I with reference to FIG. 16. A communication module 13 of the object management server 1C receives an object enquiry request from client 3C (step S71). The object enquiry request includes an object ID of the employee badge object I for which user C wishes to make an enquiry. Upon receipt of the object enquiry request, an enquiry module 16 of the object management server 1C searches through an object database 11, and retrieves the corporate ID of the entry for the received object ID (step S72). The enquiry module 16 determines whether or not the corporate ID is “null” (step S73). If the corresponding corporate ID is not “null”, the enquiry module 16 searches through the management database 12, and transmits the company name and logo of the corporate ID to client 3C (step S74). Meanwhile, if the corresponding corporate ID is “null”, the enquiry module 16 transmits a message indicating “no corresponding corporate ID” to client 3C (step S75). Since other processes are the same as Example 1, descriptions thereof are omitted. However, note that in this case, giving of an employee badge object to another need to be prohibited.


EXAMPLE 3

In Example 1, a case of determining whether a bag object in the Metaverse is genuine or fake has been described. In Example 3, a case of determining whether a ticket object T of an event held for a certain time period in the Metaverse is genuine or fake will be described. FIG. 18 is a schematic view of the data structure of a management database 12 according to Example 3. As shown in FIG. 18, entries in the management database 12 include: event IDs (authenticity information) for specifying the events instead of brand IDs for specifying the brands; sponsor information (authenticity information) for specifying the sponsor of each event instead of manager information for specifying the manager of each brand; event names showing names of the events (authenticity information) instead of names of the brands; event logo data (authenticity information) instead of the brand logo data; and period information indicating the valid period of the event.


A description will be given of an enquiry for the ticket object T with reference to FIG. 16. A communication module 13 of the object management server 1C receives an object enquiry request from client 3C (step S71). The object enquiry request includes an object ID of the ticket object T for which user C wishes to make an enquiry. Upon receipt of the object enquiry request, an enquiry module 16 of the object management server 1C searches through an object database 11, and retrieves the event ID of the entry for the received object ID (step S72). The enquiry module 16 determines whether or not the corporate ID is “null” (step S73). If the corresponding event ID is not “null”, on condition that its expiration time has not come yet, the enquiry module 16 searches through the management database 12, and transmits the event name and logo of the event ID to client 3C (step S74).


In the case where the expiration time has not come yet, the enquiry module 16 notifies client 3C of the fact. Meanwhile, if the corresponding event ID is “null”, the enquiry module 16 transmits a message indicating “no corresponding event ID” to client 3C (step S75). Since other processes are the same as Example 1, descriptions thereof are omitted.


Hereinafter, descriptions will be given of a typical hardware and software configuration of the object management server 1C. FIG. 19 is a schematic view illustrating the hardware configuration of the object management server 1C. The object management server 1C includes a (high-speed/low-speed) bus 40, a CPU (central processing unit) 41 connected to the bus, a RAM (random access memory) 42, a ROM (read only memory) 43, an HDD (hard disk drive) 44, a communication interface 45, and an input/output interface 46. The object management server 1C further includes a printer 47, a display 48, a keyboard 49 and other devices connected to the input/output interface 46. Note that although personal computer architecture has been employed for the object management server 1C in the present embodiment, the CPU 41, the HDD 44 and the like may be multiplexed for higher data processing abilities and possibilities. Otherwise, multiple computers may be employed to implement the functions of the object management server 1C.


The software of the object management server 1C is configured of an OS (operating system) for providing basic functions, middleware such as database management software, and application software utilizing the functions of the OS and middleware. Each piece of software is loaded onto the RAM 42 and executed by the CPU 41. Functions shown in FIG. 2 can be implemented with this hardware and software configuration. To be specific, the function of the storage module is mainly implemented by cooperation of the HDD 44, the OS, and the database management software. Additionally, the functions of the registration module 14, the update module 15, and the enquiry module 16 are mainly implemented by cooperation of the OS, the database management software and the application software, and the function of the communication module 13 is mainly implemented by cooperation of the communication interface 45 and the OS.


The present embodiments enables determination of whether an object in a Metaverse is genuine or fake with a simple configuration, under the assumption that the objects are freely generated in the Metaverse and objects are freely brought in from outside by users. To be specific, even if an unauthorized copy of an object created by a user has exactly the same appearance as the original object in the Metaverse, the object does not hold authenticity information, and thus a third party can judge that the object is fake. Accordingly, the present embodiments are extremely advantageous as a countermeasure for fake objects of brand products, employee badges, tickets and the like which only make sense or become effective when shown to a third party.


Although some embodiments have been described in detail, it should be understood that various changes, substitutions and alternations can be made therein without departing from spirit and scope of the embodiments as defined by the appended claims.

Claims
  • 1. A system for identifying whether an object has been modified in a virtual environment, the system comprising: a server computer in communication with one or more client computers, the server computer configured to: store information about the object in the virtual environment, wherein the information comprises at least a unique ID and authenticity data;process a modification request from the one or more client computers, wherein the modification request corresponds to the object, wherein processing the modification request modifies the object to form the modified object, and wherein the modification request is processed by storing information corresponding to the modified object together with information corresponding to the object;process a request for the modified object from the one or more client computers; andgenerate authenticity information corresponding to the modified object, wherein the authenticity information indicates the modification of the object.
  • 2. The system of claim 1, wherein, upon receiving the request for the modified object, the server computer is configured to communicate via the one or more client computers with an owner of the object being modified.
  • 3. The system of claim 1, wherein the one or more client computers comprises a first client computer, a second client computer, and a third client computer, wherein the object is owned by a first user corresponding to the first client computer and a first avatar of the virtual environment, wherein the modification request is received from the second client computer corresponding to a second user and a second avatar of the virtual environment, and wherein the request for the modified object is received from the third client computer corresponding to a third user and a third avatar of the virtual environment.
  • 4. The system of claim 1, wherein processing the modification request corresponding to the object further comprises creating a unique object ID for the modified object and storing the unique object ID for the modified object together with a unique object ID of the object.
  • 5. The system of claim 1, wherein the information about the object in the virtual environment further comprises an expiration time of the authenticity data and a history of at least any one of a creation, a modification or a transfer of the object in the virtual environment.
  • 6. The system of claim 1, wherein the object is an accessory object for an avatar in the virtual environment and wherein the authenticity data further comprises manager information specifying a manager of a brand of the accessory object, a brand name indicating a name of the brand, and logo data indicating a logo of the brand.
  • 7. The system of claim 1, wherein the object is an employee badge object of an avatar in the virtual environment and wherein the authenticity data further comprises owner information specifying an owner of the employee badge object, data indicating a name of a company, and logo data indicating a logo of the company.
  • 8. The system of claim 1, wherein the object is a ticket having an expiration time in the virtual environment and wherein information corresponding to the object comprises time period data indicating an expiration time of authenticity information.
  • 9. A computer-implemented method of determining modifying of an object in a virtual environment, the method being implemented in a computer system having one or more physical processors programmed with computer program instructions that, when executed by the one or more physical processors, cause the computer system to perform the method, the method comprising: using the computer system, storing information corresponding to the object in the virtual environment wherein the information comprises at least a unique object ID and authenticity data;using the computer system, processing a modification request from one or more client computers to modify the object in the virtual environment, to thereby create a modified object in the virtual environment, by storing information for the modified object, wherein the information for the modified object comprises at least a unique object ID and authenticity information indicative of the modification of the object; andusing the computer system, processing a request for the modified object from the one or more client computers by using the unique object ID of the modified object and returning the authenticity information indicative of the modified object.
  • 10. The method of claim 9, wherein the returned authenticity information indicates whether the modified object is fake or genuine.
  • 11. The method of claim 9, wherein the computer program instructions, when executed, further cause the computer system to communicate with an owner of the modified object upon receiving a request for the modified object and to convey the request for the modified object to the owner.
  • 12. The method of claim 9, wherein processing the modification request further comprises creating a unique object ID for the modified object and storing the unique object ID for the modified object along with a unique ID of the object.
  • 13. The method of claim 9, wherein the information corresponding to the object further comprises an expiration time of the authenticity data and a history of at least any one of a creation, a modification, or a transfer of the object.
  • 14. The method of claim 9, wherein the object is an accessory object for an avatar in the virtual environment and wherein the authenticity data of the object further comprises manager information specifying a manager of a brand of the accessory object, a name indicating a name of the brand, and logo data indicating a logo of the brand.
  • 15. The method of claim 9, wherein the object is an employee badge object of an avatar in the virtual environment, wherein the authenticity data further comprises owner information specifying an owner of the employee badge object, a company name indicating a name of the company, and logo data indicating a logo of the company.
  • 16. The method of claim 9, wherein the object is a ticket having an expiration time and wherein the information corresponding to each object in the virtual environment comprises time period information indicating an expiration time of the authenticity data.
  • 17. A computer program product for determining a modification of an object in a virtual environment, computer program product comprising: one or more tangible, non-transitory computer readable storage devices;program instructions, stored on at least one the one or more tangible, non-transitory computer readable storage devices that, when executed, cause a computer to: store information corresponding to the object, wherein the information comprises at least a unique object ID and authenticity information;process a modification request corresponding to the object, from one or more of the client computers, to form a modified object in the virtual environment, by storing information about the modified object, wherein the information comprises at least a unique object ID and authenticity data indicative of a modification of the object; andprocess a request for the modified object from one or more of the client computers by using the unique object ID of the modified object and returning the corresponding authenticity data indicative of a modification of the object.
  • 18. The computer program product of claim 17, wherein the corresponding authenticity information indicates whether the modified object is fake or genuine.
  • 19. The computer program product of claim 17, wherein the program instructions when executed, further cause the computer to communicate, via one or more client computers and upon receiving a request for the modified object, with an owner of the object being modified and conveying the request to the owner.
  • 20. The computer program product of claim 17, wherein the object is an accessory object for an avatar, wherein the authenticity data of the object further comprises manager information specifying a manager of a brand of the accessory object, a name indicating a name of the brand, and logo data indicating a logo of the brand.
  • 21. The computer program product of claim 17, wherein the object is an employee badge object of an avatar, wherein the authenticity data further comprises owner information specifying an owner of the employee badge object, a company name, and logo data.
  • 22. The computer program product of claim 17, wherein the object is a ticket having an expiration time and wherein the information comprises time period information indicating an expiration time of the authenticity data.
Priority Claims (1)
Number Date Country Kind
2008-058489 Mar 2008 JP national
CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No. 12/399,349, filed Mar. 6, 2009, which claims priority to Japanese Patent Application 2008-58489, the disclosure of which is incorporated by reference herein in its entirety.

US Referenced Citations (476)
Number Name Date Kind
5442780 Takanashi Aug 1995 A
5506902 Kubota Apr 1996 A
5530796 Wang Jun 1996 A
5561736 Moore Oct 1996 A
5563946 Cooper Oct 1996 A
5685775 Bakoglu Nov 1997 A
5706507 Schloss Jan 1998 A
5708764 Borrel Jan 1998 A
5734898 He Mar 1998 A
5736985 Lection Apr 1998 A
5737416 Cooper Apr 1998 A
5737533 De Apr 1998 A
5745678 Herzberg Apr 1998 A
5762552 Vuong Jun 1998 A
5768511 Galvin Jun 1998 A
5825877 Dan Oct 1998 A
5835094 Ermel Nov 1998 A
5835692 Cragun Nov 1998 A
5878233 Schloss Mar 1999 A
5883628 Mullaly Mar 1999 A
5900879 Berry May 1999 A
5903266 Berstis May 1999 A
5903271 Bardon May 1999 A
5911045 Leyba Jun 1999 A
5920325 Morgan Jul 1999 A
5923324 Berry Jul 1999 A
5933849 Srbljic Aug 1999 A
5969724 Berry Oct 1999 A
5977979 Clough Nov 1999 A
5990888 Blades Nov 1999 A
6006034 Heath Dec 1999 A
6009458 Hawkins Dec 1999 A
6014145 Bardon Jan 2000 A
6025839 Schell Feb 2000 A
6032129 Greef Feb 2000 A
6059842 Dumarot May 2000 A
6069632 Mullaly May 2000 A
6081270 Berry Jun 2000 A
6081271 Bardon Jun 2000 A
6091410 Lection Jul 2000 A
6094196 Berry Jul 2000 A
6098056 Rusnak Aug 2000 A
6098093 Bayeh Aug 2000 A
6104406 Berry Aug 2000 A
6105008 Davis Aug 2000 A
6111581 Berry Aug 2000 A
6119229 Martinez Sep 2000 A
6134588 Guenthner Oct 2000 A
6135646 Kahn Oct 2000 A
6138152 Jalote Oct 2000 A
6144381 Lection Nov 2000 A
6148299 Yoshimoto Nov 2000 A
6148328 Cuomo Nov 2000 A
6154811 Srbljic Nov 2000 A
6170013 Murata Jan 2001 B1
6179713 James Jan 2001 B1
6182077 Tokumine Jan 2001 B1
6185614 Cuomo Feb 2001 B1
6199059 Dahan Mar 2001 B1
6201881 Masuda Mar 2001 B1
6205481 Heddaya Mar 2001 B1
6219675 Pal Apr 2001 B1
6219676 Reiner Apr 2001 B1
6222551 Schneider Apr 2001 B1
6270416 Komoto Aug 2001 B1
6271842 Bardon Aug 2001 B1
6271843 Lection Aug 2001 B1
6282547 Hirsch Aug 2001 B1
6292835 Huang Sep 2001 B1
6311206 Malkin Oct 2001 B1
6321236 Zollinger Nov 2001 B1
6334141 Varma Dec 2001 B1
6336134 Varma Jan 2002 B1
6337700 Kinoe Jan 2002 B1
6343738 Ogilvie Feb 2002 B1
6353449 Gregg Mar 2002 B1
6356297 Cheng Mar 2002 B1
6366285 Brush Apr 2002 B1
6397080 Viktorsson May 2002 B1
6404426 Weaver Jun 2002 B1
6411312 Sheppard Jun 2002 B1
6421047 De Jul 2002 B1
6426757 Smith Jul 2002 B1
6445389 Bossen Sep 2002 B1
6449518 Yokoo Sep 2002 B1
6452593 Challener Sep 2002 B1
6462760 Cox, Jr. Oct 2002 B1
6466550 Foster Oct 2002 B1
6469712 Hilpert, Jr. Oct 2002 B1
6473085 Brock Oct 2002 B1
6499053 Marquette Dec 2002 B1
6505208 Kanevsky Jan 2003 B1
6509925 Dermler Jan 2003 B1
6525731 Suits Feb 2003 B1
6549933 Barrett Apr 2003 B1
6567109 Todd May 2003 B1
6567813 Zhu May 2003 B1
6591250 Johnson Jul 2003 B1
6618751 Challenger Sep 2003 B1
RE38375 Herzberg Dec 2003 E
6657617 Paolini Dec 2003 B2
6657642 Bardon Dec 2003 B1
6684255 Martin Jan 2004 B1
6694306 Nishizawa Feb 2004 B1
6717600 Dutta Apr 2004 B2
6734884 Berry May 2004 B1
6745236 Hawkins Jun 2004 B1
6765596 Lection Jul 2004 B2
6781607 Benham Aug 2004 B1
6798407 Benman Sep 2004 B1
6810418 Shah Oct 2004 B1
6819669 Rooney Nov 2004 B2
6832239 Kraft Dec 2004 B1
6836480 Basso Dec 2004 B2
6845389 Sen Jan 2005 B1
6886026 Hanson Apr 2005 B1
6901379 Balter May 2005 B1
6948168 Kuprionas Sep 2005 B1
6954728 Kusumoto Oct 2005 B1
6954906 Kamachi Oct 2005 B1
RE38865 Dumarot Nov 2005 E
6993596 Hinton Jan 2006 B2
7006616 Christofferson Feb 2006 B1
7028296 Irfan Apr 2006 B2
7062533 Brown Jun 2006 B2
7089083 Yokoo Aug 2006 B2
7143409 Herrero Nov 2006 B2
7209137 Brokenshire Apr 2007 B2
7230616 Taubin Jun 2007 B2
7249123 Elder Jul 2007 B2
7249139 Chuah Jul 2007 B2
7250944 Anderson Jul 2007 B2
7251622 Yan Jul 2007 B2
7263511 Bodin Aug 2007 B2
7287053 Bodin Oct 2007 B2
7305438 Christensen Dec 2007 B2
7308476 Mannaru Dec 2007 B2
7404149 Fox Jul 2008 B2
7426538 Bodin Sep 2008 B2
7427980 Partridge Sep 2008 B1
7428588 Berstis Sep 2008 B2
7429987 Leah Sep 2008 B2
7436407 Doi Oct 2008 B2
7439975 Hsu Oct 2008 B2
7443393 Shen Oct 2008 B2
7447996 Cox Nov 2008 B1
7467181 McGowan Dec 2008 B2
7475354 Guido Jan 2009 B2
7478127 Creamer Jan 2009 B2
7484012 Hinton Jan 2009 B2
7503007 Goodman Mar 2009 B2
7506264 Polan Mar 2009 B2
7512548 Bezos Mar 2009 B1
7515136 Kanevsky Apr 2009 B1
7517282 Pryor Apr 2009 B1
7525964 Astley Apr 2009 B2
7552177 Kessen Jun 2009 B2
7565650 Bhogal Jul 2009 B2
7571224 Childress Aug 2009 B2
7571389 Broussard Aug 2009 B2
7580888 Ur Aug 2009 B2
7593864 Shuster Sep 2009 B2
7596596 Chen Sep 2009 B2
7640587 Fox Dec 2009 B2
7657340 Lind Feb 2010 B2
7667701 Leah Feb 2010 B2
7698656 Srivastava Apr 2010 B2
7702784 Berstis Apr 2010 B2
7713116 Keam May 2010 B2
7714867 Doi May 2010 B2
7719532 Schardt May 2010 B2
7719535 Tadokoro May 2010 B2
7729951 Dawson Jun 2010 B2
7734691 Creamer Jun 2010 B2
7737969 Shen Jun 2010 B2
7743095 Goldberg Jun 2010 B2
7747679 Galvin Jun 2010 B2
7765478 Reed Jul 2010 B2
7768514 Pagan Aug 2010 B2
7773087 Fowler Aug 2010 B2
7774407 Daly Aug 2010 B2
7780532 Van Aug 2010 B2
7782318 Shearer Aug 2010 B2
7792263 D Amora Sep 2010 B2
7792801 Hamilton, II Sep 2010 B2
7792808 Stuart Sep 2010 B2
7796128 Radzikowski Sep 2010 B2
7797168 Kusumoto Sep 2010 B2
7801228 Lehne Sep 2010 B2
7805680 Meyers Sep 2010 B2
7808500 Shearer Oct 2010 B2
7814152 McGowan Oct 2010 B2
7824253 Thompson Nov 2010 B2
7827318 Hinton Nov 2010 B2
7843471 Doan Nov 2010 B2
7844663 Boutboul Nov 2010 B2
7847799 Taubin Dec 2010 B2
7856469 Chen Dec 2010 B2
7873485 Castelli Jan 2011 B2
7882222 Dolbier Feb 2011 B2
7882243 Ivory Feb 2011 B2
7884819 Kuesel Feb 2011 B2
7886045 Bates Feb 2011 B2
7890623 Bates Feb 2011 B2
7893936 Shearer Feb 2011 B2
7904829 Fox Mar 2011 B2
7921128 Hamilton, II Apr 2011 B2
7940265 Brown May 2011 B2
7945620 Bou-Ghannam May 2011 B2
7945802 Hamilton, II May 2011 B2
7958047 Jung Jun 2011 B2
7958055 Hsu Jun 2011 B2
7962751 Dudley Jun 2011 B2
7970837 Lyle Jun 2011 B2
7970840 Cannon Jun 2011 B2
7985138 Acharya Jul 2011 B2
7990387 Hamilton, II Aug 2011 B2
7996164 Hamilton, II Aug 2011 B2
7996264 Kusumoto Aug 2011 B2
8001161 George Aug 2011 B2
8004518 Fowler Aug 2011 B2
8005025 Bodin Aug 2011 B2
8006182 Bates Aug 2011 B2
8013861 Hamilton, II Sep 2011 B2
8018453 Fowler Sep 2011 B2
8018462 Bhogal Sep 2011 B2
8019797 Hamilton, II Sep 2011 B2
8019858 Bauchot Sep 2011 B2
8022948 Garbow Sep 2011 B2
8022950 Brown Sep 2011 B2
8026913 Garbow Sep 2011 B2
8028021 Reisinger Sep 2011 B2
8028022 Brownholtz Sep 2011 B2
8037416 Bates Oct 2011 B2
8041614 Bhogal Oct 2011 B2
8046700 Bates Oct 2011 B2
8051462 Hamilton, II Nov 2011 B2
8055656 Cradick Nov 2011 B2
8056121 Hamilton, II Nov 2011 B2
8057307 Berstis Nov 2011 B2
8062130 Smith Nov 2011 B2
8063905 Brown Nov 2011 B2
8070601 Acharya Dec 2011 B2
8082245 Bates Dec 2011 B2
8085267 Brown Dec 2011 B2
8089481 Shearer Jan 2012 B2
8092288 Theis Jan 2012 B2
8095881 Reisinger Jan 2012 B2
8099338 Betzler Jan 2012 B2
8099668 Garbow Jan 2012 B2
8102334 Brown Jan 2012 B2
8103640 Lo Jan 2012 B2
8103959 Cannon Jan 2012 B2
8105165 Karstens Jan 2012 B2
8108774 Finn Jan 2012 B2
8113959 De Judicibus Feb 2012 B2
8117551 Cheng Feb 2012 B2
8125485 Brown Feb 2012 B2
8127235 Haggar Feb 2012 B2
8127236 Hamilton, II Feb 2012 B2
8128487 Hamilton, II Mar 2012 B2
8131740 Cradick Mar 2012 B2
8132235 Bussani Mar 2012 B2
8134560 Bates Mar 2012 B2
8139060 Brown Mar 2012 B2
8139780 Shearer Mar 2012 B2
8140340 Bhogal Mar 2012 B2
8140620 Creamer Mar 2012 B2
8140978 Betzler Mar 2012 B2
8140982 Hamilton, II Mar 2012 B2
8145676 Bhogal Mar 2012 B2
8145725 Dawson Mar 2012 B2
8149241 Do Apr 2012 B2
8151191 Nicol, II Apr 2012 B2
8156184 Kurata Apr 2012 B2
8165350 Fuhrmann Apr 2012 B2
8171407 Huang May 2012 B2
8171408 Dawson May 2012 B2
8171559 Hamilton, II May 2012 B2
8174541 Greene May 2012 B2
8176421 Dawson May 2012 B2
8176422 Bergman May 2012 B2
8184092 Cox May 2012 B2
8184116 Finn May 2012 B2
8185450 McVey May 2012 B2
8185829 Cannon May 2012 B2
8187067 Hamilton, II May 2012 B2
8199145 Hamilton, II Jun 2012 B2
8203561 Carter Jun 2012 B2
8214335 Hamilton, II Jul 2012 B2
8214433 Dawson Jul 2012 B2
8214750 Hamilton, II Jul 2012 B2
8214751 Dawson Jul 2012 B2
8217953 Comparan Jul 2012 B2
8219616 Dawson Jul 2012 B2
8230045 Kawachiya Jul 2012 B2
8230338 Dugan Jul 2012 B2
8233005 Finn Jul 2012 B2
8234234 Shearer Jul 2012 B2
8234579 Do Jul 2012 B2
8239775 Beverland Aug 2012 B2
8241131 Bhogal Aug 2012 B2
8245241 Hamilton, II Aug 2012 B2
8245283 Dawson Aug 2012 B2
8265253 D Amora Sep 2012 B2
8310497 Comparan Nov 2012 B2
8334871 Hamilton, II Dec 2012 B2
8360886 Karstens Jan 2013 B2
8364804 Childress Jan 2013 B2
8370370 Huang Feb 2013 B2
8425326 Chudley Apr 2013 B2
8442946 Hamilton, II May 2013 B2
8506372 Chudley Aug 2013 B2
8514249 Hamilton, II Aug 2013 B2
8554841 Kurata Oct 2013 B2
8607142 Bergman Dec 2013 B2
8607356 Hamilton, II Dec 2013 B2
8624903 Hamilton, II Jan 2014 B2
8626836 Dawson Jan 2014 B2
8692835 Hamilton, II Apr 2014 B2
8721412 Chudley May 2014 B2
8827816 Bhogal Sep 2014 B2
8838640 Bates Sep 2014 B2
8849917 Dawson Sep 2014 B2
8911296 Chudley Dec 2014 B2
8924308 Mehta Dec 2014 B1
8992316 Smith Mar 2015 B2
9083654 Dawson Jul 2015 B2
9152914 Haggar Oct 2015 B2
9205328 Bansi Dec 2015 B2
9286731 Hamilton, II Mar 2016 B2
9299080 Dawson Mar 2016 B2
9364746 Chudley Jun 2016 B2
9525746 Bates Dec 2016 B2
9583109 Kurata Feb 2017 B2
9682324 Bansi Jun 2017 B2
9764244 Bansi Sep 2017 B2
9789406 Marr Oct 2017 B2
9808722 Kawachiya Nov 2017 B2
10386988 Koh Aug 2019 B1
20010007979 Teshima Jul 2001 A1
20010049651 Selleck Dec 2001 A1
20010056383 Shuster Dec 2001 A1
20020002514 Kamachi Jan 2002 A1
20020007319 Yu Jan 2002 A1
20020073043 Herman Jun 2002 A1
20020095387 Sosa Jul 2002 A1
20020105533 Cristo Aug 2002 A1
20020125312 Ogilvie Sep 2002 A1
20020169644 Greene Nov 2002 A1
20020169665 Hughes Nov 2002 A1
20030004774 Greene Jan 2003 A1
20030014423 Chuah Jan 2003 A1
20030135433 Yan Jul 2003 A1
20030164827 Gottesman Sep 2003 A1
20040001616 Gutta Jan 2004 A1
20040014514 Yacenda Jan 2004 A1
20040030888 Roh Feb 2004 A1
20040053690 Fogel Mar 2004 A1
20040107125 Guheen Jun 2004 A1
20040122553 Phan Jun 2004 A1
20040143852 Meyers Jul 2004 A1
20040163133 Ueda Aug 2004 A1
20040166935 Gavin Aug 2004 A1
20040167880 Smith Aug 2004 A1
20040172339 Snelgrove Sep 2004 A1
20040228291 Huslak Nov 2004 A1
20040243664 Horstemeyer Dec 2004 A1
20040268386 Logan Dec 2004 A1
20050021472 Gettman Jan 2005 A1
20050054381 Lee Mar 2005 A1
20050071306 Kruszewski Mar 2005 A1
20050075934 Knight Apr 2005 A1
20050102188 Hutchison May 2005 A1
20050137015 Rogers Jun 2005 A1
20050143174 Goldman Jun 2005 A1
20050177428 Ganz Aug 2005 A1
20050177453 Anton Aug 2005 A1
20050182729 Kananen Aug 2005 A1
20050192864 Ganz Sep 2005 A1
20050216346 Kusumoto Sep 2005 A1
20050216361 Fukada Sep 2005 A1
20050240531 Wolff Oct 2005 A1
20050251512 McCauley Nov 2005 A1
20050253840 Kwon Nov 2005 A1
20060004659 Hutchison Jan 2006 A1
20060028475 Tobias Feb 2006 A1
20060031128 Lamitie Feb 2006 A1
20060161788 Turpin Jul 2006 A1
20060178966 Jung Aug 2006 A1
20060178968 Jung Aug 2006 A1
20060178975 Jung Aug 2006 A1
20060194632 Hendrickson Aug 2006 A1
20060195462 Rogers Aug 2006 A1
20060258462 Cheng Nov 2006 A1
20070002057 Danzig Jan 2007 A1
20070026942 Kinsley Feb 2007 A1
20070050716 Leahy Mar 2007 A1
20070066400 Kogo Mar 2007 A1
20070087822 Van Apr 2007 A1
20070087831 Van Apr 2007 A1
20070111770 Van Luchene May 2007 A1
20070112574 Greene May 2007 A1
20070155508 Sun Jul 2007 A1
20070197297 Witchey Aug 2007 A1
20070214117 Shu Sep 2007 A1
20070218987 Van Sep 2007 A1
20070223607 Lehne Sep 2007 A1
20070226176 Bestgen Sep 2007 A1
20070233839 Gaos Oct 2007 A1
20070247979 Brillon Oct 2007 A1
20070255677 Alexander Nov 2007 A1
20070265969 Horwat Nov 2007 A1
20070282695 Toper Dec 2007 A1
20070288387 Park Dec 2007 A1
20080004094 Mueller Jan 2008 A1
20080004116 Van Jan 2008 A1
20080014917 Rhoads Jan 2008 A1
20080086382 Ur Apr 2008 A1
20080097891 Park Apr 2008 A1
20080133392 Jung Jun 2008 A1
20080159634 Sharma Jul 2008 A1
20080162317 Banaugh Jul 2008 A1
20080207327 Van Aug 2008 A1
20080208749 Wallace Aug 2008 A1
20080209527 Dudley Aug 2008 A1
20080215540 Bestgen Sep 2008 A1
20080215975 Harrison Sep 2008 A1
20080220876 Mehta Sep 2008 A1
20080222104 Stewart Sep 2008 A1
20080228607 Jung Sep 2008 A1
20080235111 Dotan Sep 2008 A1
20080252716 Kano Oct 2008 A1
20080263460 Altberg Oct 2008 A1
20080275789 Ganz Nov 2008 A1
20080281622 Hoal Nov 2008 A1
20080282090 Leybovich Nov 2008 A1
20080288343 Ho Nov 2008 A1
20080297515 Bliss Dec 2008 A1
20090030774 Rothschild Jan 2009 A1
20090063283 Kusumoto Mar 2009 A1
20090083192 Bokor Mar 2009 A1
20090089157 Narayanan Apr 2009 A1
20090094225 Cradick Apr 2009 A1
20090099925 Mehta Apr 2009 A1
20090100352 Huang Apr 2009 A1
20090113448 Smith Apr 2009 A1
20090144633 Schultz Jun 2009 A1
20090157495 Cahuzac Jun 2009 A1
20090157625 Jung Jun 2009 A1
20090210885 Bantz Aug 2009 A1
20090216546 Huang Aug 2009 A1
20090228550 Kawachiya Sep 2009 A1
20090234948 Garbow Sep 2009 A1
20090235191 Garbow Sep 2009 A1
20090248544 Ganz Oct 2009 A1
20090254417 Beilby Oct 2009 A1
20090287765 Hamilton Nov 2009 A1
20090299960 Lineberger Dec 2009 A1
20090307021 Hamilton Dec 2009 A1
20100030578 Siddique Feb 2010 A1
20100169798 Hyndman Jul 2010 A1
20100205179 Carson Aug 2010 A1
20100210349 Blair Aug 2010 A1
20100293569 Kusumoto Nov 2010 A1
20110010270 Hamilton Jan 2011 A1
20110107433 Steelberg May 2011 A1
20110126272 Betzler May 2011 A1
20110208615 Steelberg Aug 2011 A1
20110261071 Ganetakos Oct 2011 A1
20130111367 Park May 2013 A1
20140344725 Bates Nov 2014 A1
20160191671 Dawson Jun 2016 A1
20170052676 Pulier Feb 2017 A1
20180104595 Kawachiya Apr 2018 A1
20200311245 Pollard Oct 2020 A1
Foreign Referenced Citations (86)
Number Date Country
768367 Mar 2004 AU
2005215048 Oct 2011 AU
2143874 Jun 2000 CA
2292678 Jul 2005 CA
2552135 Jul 2013 CA
1334650 Feb 2002 CN
1202652 Oct 2002 CN
1141641 Mar 2004 CN
1494679 May 2004 CN
1219384 Sep 2005 CN
1858757 Nov 2006 CN
1307544 Mar 2007 CN
100407675 Jul 2008 CN
100423016 Oct 2008 CN
100557637 Nov 2009 CN
101001678 May 2010 CN
101436242 Dec 2010 CN
101801482 Dec 2014 CN
668583 Aug 1995 EP
0969430 Jan 2000 EP
0627728 Sep 2000 EP
0717337 Aug 2001 EP
1207694 May 2002 EP
0679977 Oct 2002 EP
0679978 Mar 2003 EP
0890924 Sep 2003 EP
1377902 Aug 2004 EP
0813132 Jan 2005 EP
1380133 Mar 2005 EP
1021021 Sep 2005 EP
0930584 Oct 2005 EP
0883087 Aug 2007 EP
1176828 Oct 2007 EP
2076888 Jul 2015 EP
2339938 Oct 2002 GB
2352154 Jul 2003 GB
3033956 Apr 2000 JP
3124916 Jan 2001 JP
3177221 Jun 2001 JP
2001204973 Jul 2001 JP
3199231 Aug 2001 JP
3210558 Sep 2001 JP
3275935 Feb 2002 JP
3361745 Jan 2003 JP
3368188 Jan 2003 JP
3470955 Sep 2003 JP
3503774 Dec 2003 JP
2004062539 Feb 2004 JP
3575598 Jul 2004 JP
3579823 Jul 2004 JP
3579154 Oct 2004 JP
2005050081 Feb 2005 JP
2005234633 Sep 2005 JP
3701773 Oct 2005 JP
3777161 Mar 2006 JP
3914430 Feb 2007 JP
3942090 Apr 2007 JP
3962361 May 2007 JP
4009235 Sep 2007 JP
4225376 Dec 2008 JP
4653075 Dec 2010 JP
5063698 Aug 2012 JP
5159375 Mar 2013 JP
5352200 Nov 2013 JP
5734566 Jun 2015 JP
20020038229 May 2002 KR
20030039019 May 2003 KR
117864 Aug 2004 MY
55396 Dec 1998 SG
424213 Mar 2001 TW
527825 Apr 2003 TW
0062231 Oct 2000 WO
0203645 Jan 2002 WO
2002073457 Sep 2002 WO
20020087156 Oct 2002 WO
03049459 Jun 2003 WO
03058518 Jul 2003 WO
2004086212 Oct 2004 WO
2005079538 Sep 2005 WO
2007101785 Sep 2007 WO
2008037599 Apr 2008 WO
2008074627 Jun 2008 WO
2008095767 Aug 2008 WO
2009037257 Mar 2009 WO
2009104564 Aug 2009 WO
2010096738 Aug 2010 WO
Non-Patent Literature Citations (11)
Entry
Plouznikoff, Alexandre, et al., Enhancing Human-Machine Interactions: Virtual Interface Alteration Through Wearable Computers, CHI 2006 Proceedings, Interaction Methods, Apr. 22-27, 2006, Montreal, Quebec, Canada.
Jancke, Gavin, et al., Linking Public Spaces: Technical and Social Issues, CHI 2001, Mar. 31-Apr. 5, 2006, vol. No. 4, issue No. 1.
“CMAX Promotional Footwear,” http://web.archive.org/web/20040405163227/http://promo.customatix.com/, Apr. 5, 2004.
“Fascinating Facts about the Invention of Cabbage Patch kids by Xavier Roberts in 1983,” http://www.ideafinder.com/history/inventions/cabbagepatch.htm, Oct. 25. 2006.
Barr et al., “Changing the Virtual Self, Avatar Transformations in Popular Games,” 8 pages, pulled from http://www.mcs.vuw.ac.nz/.about.chikken/research/papers/cgie2006/Transfor-mingVirtualSelf.pdf.
Y. Zhao et al., “A 3D virtual shopping mall that has the intelligent virtual purchasing guider and cooperative purchasing functionalities”, CSCWD 2004—8th International Conference on Computer Supported Cooperative Work in Design—Proceedings, 2004, p. 381-385.
V. Stojanovic, “Virtual boutique-try clothes on-line”, 5th International Conference on Telecommunications in Modern Satellite, Cable and Broadcasting Service. TELSIKS 2001. Proceedings of Papers (Cat. No.01EX517), 2001, pt. 2, p. 802-3 vol. 2.
International Search Report as Published as WO2005/079538 in corresponding international application No. PCT/US2005/005550, dated Jul. 5, 2006.
Roaming Virtual World Is a Real Trip; [Final Edition] Leslie Walker. The Washington Post. Washington, D.C.: Mar. 30, 2006.
E-Entrepreneurship: Learning in a Simulated Environment Salim Jiwa, Dawn Lavelle, Arjun Rose. Journal of Electronic Commerce in Organizations. Hershey: Jul.-Sep. 2005. vol. 3, Iss. 3.
Peter Jorissen et al., “Dynamic Interactions in Physically Realistic Collaborative Virtual Environments,” 2005, IEEE Transactions on Visualization and Computer Graphics, vol. 11, No. 6, published by IEEE Computer Society, pp. 649-660.
Related Publications (1)
Number Date Country
20210268389 A1 Sep 2021 US
Continuations (3)
Number Date Country
Parent 15725607 Oct 2017 US
Child 17202677 US
Parent 13533359 Jun 2012 US
Child 15725607 US
Parent 12399349 Mar 2009 US
Child 13533359 US