WO2005015880A1 - Architecture de reseau informatique pour environnements virtuels distribues persistants - Google Patents

Architecture de reseau informatique pour environnements virtuels distribues persistants Download PDF

Info

Publication number
WO2005015880A1
WO2005015880A1 PCT/US1999/027187 US9927187W WO2005015880A1 WO 2005015880 A1 WO2005015880 A1 WO 2005015880A1 US 9927187 W US9927187 W US 9927187W WO 2005015880 A1 WO2005015880 A1 WO 2005015880A1
Authority
WO
WIPO (PCT)
Prior art keywords
mutech
virtual environment
node
nodes
telepresence
Prior art date
Application number
PCT/US1999/027187
Other languages
English (en)
Inventor
R. Coulter
Chun-Ming Chang
Yuntao Cui
Mike Fletcher
Todd Schneider
Eric Mason
Henry Gnad
Henning Pangels
Original Assignee
Tpresence, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tpresence, Inc. filed Critical Tpresence, Inc.
Publication of WO2005015880A1 publication Critical patent/WO2005015880A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/131—Protocols for games, networked simulations or virtual reality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/563—User guidance or feature selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/567—Multimedia conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/10—Aspects of automatic or semi-automatic exchanges related to the purpose or context of the telephonic communication
    • H04M2203/1016—Telecontrol
    • H04M2203/1025—Telecontrol of avatars
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
    • H04M2203/2038—Call context notifications

Definitions

  • This invention relates generally to the field of electronic communication, and more particularly relates to a method and apparatus for providing "telepresence" connectivity between two or more users of computers communicating via a network.
  • Telepresence may be defined generally as the projection of a person's presence across a distance, achieved by integrating audio and visual communications technologies. Telepresence systems have been the topic of research for at least a decade, with many systems being developed for military and space applications. Telepresence may be regarded as an natural offshoot or extension of various computer-based simulation technologies, such as the well-known flight simulator systems developed over the years for the benefit of defense department, aviation, and even entertainment concerns. Telepresence technology may be distinguished from such simulation applications primarily by the former's emphasis on real-time interaction between two or more users, whereas simulation technology in its simplest form involves the presentation of a "virtual" environment to perhaps only a single user of the technology.
  • the expression "virtual environment” is e sensation of being within, and interacting within, an environment in which he or she is not actually present, and which may not actually even exist.
  • Advances in computer technology have increasingly enabled virtual environments to involve the interaction between two or more human users-example of multi-user virtual environment-desktop videoconferencing in which two or more remotely-located computer users may interact as if actually situated in a common location.
  • each user can interact with the other(s) in essentially the same manner as if each user was actually present at a single location, for example, in a conference room.
  • the "virtual"-ness of the situation arises from the reality that the participants may in fact be located in quite distant locations with respect to one another.
  • the "virtual environment” is established primarily through the use of visual
  • the present invention is a system for supporting shared, multi-user Internet telepresence sessions.
  • Internet telepresence allows users to project their presence over the Internet into 3D virtual reality spaces.
  • the system of the present invention is produced by integrating a virtual reality graphics engine such as the CosmoPlayer 2.1 of Computer Associates, Inc.; an Internet telephony system; and a collection of file transfer protocols; with a client / server application - also called a node (hereinafter also referred to as "N").
  • Telepresence sessions in the present invention are enabled by the creation of a novel network communications system that is comprised of a set of client / server applications linked in a decentralized network architecture.
  • the network communications system links together a number of users who wish to share the experience of a single virtual reality world.
  • the shared world experience is created by rending the same world scene on each user's local machine.
  • Data is passed among the users to maintain a consistent world state, to support Internet telephony, and to transfer files.
  • client / server application This software module can act as either a network client or a network server, depending upon the needs of the user and of the system.
  • the network topography generalizes from the classical central server architecture to a generic set of interconnected nodes, which is referred to herein as a decentralized server architecture.
  • the decentralized architecture has several advantages over centralized architectures of the prior art. In the first place the architecture of the present invention is generally more flexible; more robust to failure and more graceful in degradation; and more efficient in its utilization of available resource.
  • any node in the network can act as a network host.
  • the function of network host can be dynamically reassigned among network nodes as needed.
  • the invention also provides more efficient utilization of available bandwidth, especially where intelligent monitoring of network messaging permits the application of classical network optimization solutions, such as dynamic programming. Further efficiencies are obtained in the present invention by reducing the required messaging sets to be delivered among system nodes. Scene geometries, for example, are downloaded and locally cached once, minimal sets of state information describing the configuration of system objects are passed thereafter. File descriptors are passed to users rather than entire files - users may then load files directly to their local machine, rather than through a central server.
  • the system nodes enable point to point transfer of digital data throughout the network.
  • the integration of compression schemes specifically enables the support of Internet telephony in addition to general file transfer. Distribution of data among multiple nodes can be supported, assuming the availability of sufficient network bandwidth.
  • Interactive objects allow passing and visualization of data within the virtual reality world.
  • File transfer and image display objects allow users to import and display files and images for other users sharing the telepresence session.
  • Interactive objects provide maximum system integrability as they can be tied to databases, back-end systems, shopping cart systems, and other general corporate information systems.
  • Connection information is provided by a database server (the Listing Server) which maintains a listing of the IP address of each node within the system.
  • the listing server enables users to employ dial-up services where their IP address is dynamically allocated.
  • the listing server can track system usage parameters; telepresence site usage; world usage; and can be expanded to track user behavior within individual worlds.
  • the present invention is directed to a shared telepresence system for enabling multiple users, who may be remotely located with respect to one another, to interact within a shared virtual environment. More generally, the present invention relates to a distributed architectural arrangement whereby a plurality of computers cooperate to establish a persistent, shared virtual environment within which one or more users may interact, and obtain and exchange information.
  • a session host software component for a telepresence session.
  • the session host is a software module which may reside and be executed on the computer(s) of one or more of the participants in the telepresence session.
  • users as e.g. represented by their avatars
  • they periodically exchange messages with the session host.
  • Users may send messages requesting information about the status and attributes of shared objects defined within the virtual environment, and may also send messages informing the session host that they have changed the state of the environment or of a shared object within the environment.
  • the session host responds to requests for state information about the environment and objects within the environment with a message identifying for the requesting user(s) the location of the requested information.
  • the session host does not necessarily itself provide the requested information, but may provide only an identification of the location of the requested information.
  • individual users need the information, they are responsible for establishing a link, e.g., via the Internet, to the location identified by the session host, to obtain the desired state information.
  • the session host is informed of a change in the state of the shared environment made by one of the participants in the session, the host provides this information to all other users.
  • the host does not necessarily provide the changed state information itself to the users, but may merely identify the location from which the changed information may be obtained.
  • the distributed control of the state of the virtual environment among all participants in a telepresence session is accomplished without the necessity of a large, computationally powerful, high-bandwidth central server.
  • the present invention relates in another aspect to a set of architectural attributes for providing distributed, persistent, shared virtual environments, where the communications protocols employed may be dynamically reconfigured in real-time to improve quality of service by reallocating bandwidth usage. Improved quality of service may exist in reduced system latencies, reduced processor overhead, improved network flow and the like.
  • the architecture in accordance with the present invention enables the employment of the principles of operations research including, but not limited to, the solutions to linear and dynamic programming problems (well known branches of operations research mathematics).
  • communication between nodes is achieved through communication between modules.
  • Communication between nodes is dynamically reconfigurable by altering the path through the network of nodes through which messages are selectively passed between any selected nodes, e.g. communications in the network may be point to point, broadcast, daisychained, etc...
  • Messages may be passed from one node to another through one or more intermediary nodes, which may take one or more of the following actions: the message be forwarded to one or more nodes; the message may be acted upon in the present node; and the like.
  • the architecture of the present invention is implemented by a system comprising general-purpose personal computers operating over the Internet or like network.
  • Each of the computers comprises, or is a constituant component of, one or more "nodes,” where each node comprises one or more software "modules.”
  • the software implementation of the various modules in a given system may not be the same at each node, e.g. one module may be tailored toward broadcast and another might save messages without acting upon them; both would use the same communication protocol, but perform different functions.
  • a collection of extensions to the virtual reality modeling language (“VRML”) are provided to support the distributed architectural arrangement used to establish a persistent and dynamic virtual environment.
  • the extensions include: the addition of system-level hooks to allow VRML content to affect and be affected by system-level elements of individual users' computers; user interface mechanism to allow VRML content to function as control interfaces within the shared virtual environment; enhance inter-object and inter-participant messaging flexibility; definitions of shared, metaphor-mediated simulation systems within VRML environments for visualization of files; and a system for facilitating run-time binding of animations and controls within a multi-user VRML system.
  • One embodiment of the invention referred to as the Holodesk application, comprises a Communicator Node made up of a MuTech module, an Achat module, an http module, a link module, and a listing module, and a Connector Node made up of one or more link modules and a listing module.
  • a listing node is also preferably included for coordinating information regarding the identities and addresses of nodes that may be available for participation in a telepresence session.
  • the disclosed system is believed to be particularly beneficial for establishing virtual environments adapted to support electronic commerce transactional interaction among a plurality of users.
  • Figure 1 is a block diagram depicting the hardware configuration and software architecture of a multi-user telepresence system in accordance with one embodiment of the invention
  • Figure 2 is a depiction of the appearance of a graphical user interface presented to a user of the system of Figure 1, showing one view of a virtual environment
  • Figure 3 is depiction of the appearance of a graphical user interface presented to a user of the system of Figure 1, showing a different view of the virtual environment from
  • Figure 2 Figure 4 is depiction of the appearance of a graphical user interface presented to a user of the system of Figure 1, showing still a different view of the virtual environment from Figure 2;
  • Figure 5 is a block diagram depicting the topology of a telepresence system in accordance with one embodiment of the invention;
  • Figure 6 is a block diagram depicting an alternative topology of the telepresence system from Figure 5;
  • Figure 7 is a block diagram illustrating another alternative topology of the telepresence system from Figure 5;
  • Figure 8 is a block diagram illustrating a message passing protocol implemented in the system from Figure 5;
  • Figure 9a is a flow diagram illustrating the procedure followed for a user, via its connection service 40, to connect to a telepresence session;
  • Figure 9b is a flow diagram illustrating the steps taken by a user's HolodeskTM application upon connection to a telepresence session;
  • Figure 9c is a flow diagram illustrating the procedure undertaken when a telepresence session participant wishes to introduce an
  • Network A connection between or among two or more nodes.
  • Local Telepresence Network a group or sub-group of interconnected nodes.
  • Nodes A grouping of one or more modules which may be interconnected so as to form a network.
  • One or more nodes may reside on a single computer, or a node may be distributed across multiple interconnected computers.
  • Module A generalized term referring to a software implementation of an input output function. Modules are typically implemented as computer software programs, routines, or subroutines. Modules are implemented on nodes and hence may be implemented on one computer or on a plurality of interconnected computers. Telepresence Session: A sequence of events in which one or more users accesses nodes in a network so as to perceive and interact within a virtual environment. Because of the persistent nature of the virtual environment as established in accordance with the principles of the present invention, multiple telepresence sessions may be started, stopped, and resumed within a given virtual environment. Link Module: a specialized module for supporting communication between nodes in a network.
  • User Interface (UI) Module An interface between a user and one or more modules.
  • Streaming Module A module used to encode, send, route, receive, and decode data packets, data streams and the like.
  • MUTech Module A streaming module with additional characteristics, such as login, user identification and tracking, and the like; a module employed to track environment state, structure and/or pose information.
  • AChat Module A module for supporting streams of audio data between two or more nodes.
  • VChat Module A module for supporting streams of video data between two or more nodes.
  • TChat Module A module for supporting streams of text data between two or more nodes.
  • Http Module A module supporting http communication between two or more nodes.
  • Listing Module A module that updates and tracks node addresses, thereby enabling nodes with potentially dynamic network addresses to connect to one another
  • Arbitration Module A module that arbitrates between nodes to determine what roles different modules within the node may have during a given telepresence session.
  • Database Module A module that makes a database available to other modules.
  • Artificial Intelligence (Al) Module A module that uses Al algorithms to access database information and operate on the information, including but not limited to the contents of the database and the pose information in the world.
  • World A collection of static variables (such as geometry, texture, color, and the like) maintained by one or more nodes in a network and accessible from one or more nodes on such network.
  • a World may contain one or more independent or dependent objects that may be inserted or removed from the world, and whose state may be changed. Also referred to herein as "Virtual Environment.”
  • State As applied to a virtual environment, state refers to user or system variable parameters which can be included in structure to provide change therein.
  • Structure Fixed environment state information which may include scalar data such as integers and floating-point values as well as character strings and combinations of sealers identifying properties such as geometry, texture, color.
  • Pose The union of environment state and structure information.
  • MUTech Node A node containing a MUTech module and is capable of changing the state of a virtual environment.
  • Passivated node A node containing a MUTech module, but not capable of changing the state of a virtual environment.
  • Support node A node without a MUTech module.
  • Distributed environment A pose which can be observed and / or altered from one or more nodes
  • Persistent environment A virtual environment which maintains pose memory after execution.
  • Shared Virtual Environment A virtual environment whose pose is identical as perceived from all connected nodes.
  • FIG. 1 there is shown in block diagram form a representation of the hardware configuration and software architecture of a share telepresence system 10 in accordance with one embodiment of the invention.
  • FIG. 1 a representation of the hardware configuration and software architecture of a share telepresence system 10 in accordance with one embodiment of the invention.
  • each computer included as part of a shared telepresence system 10 in accordance with the disclosed embodiment is configured substantially identically with all others in the system (although it is to be understood that each computer may differ in terms of its particular make and model, processing speed, memory capacity, and so on).
  • computers 12 are shown in the system 10 of Figure 1, it is specifically contemplated that any number of computers 12 may be included in a given implementation of the invention or for a given telepresence "session” in which multiple users at mutually remote locations interact within a virtual environment.
  • the invention is implemented as a computer software application, hereinafter referred to as the "Holodesk " application, suitable for execution on "conventional" personal computers (“PCs").
  • PCs personal computers
  • Conventional PCs are currently nominally characterized as being based on a 133- to 450-MHz PentiumTM class of microprocessor platform with, in a typical configuration, 32 or more megabytes of on-board random access memory (“RAM”), a one or more gigabyte capacity hard disk drive mass storage unit, and a 28.8 kilobit-per-second (kbps) or faster modem with associated software for providing connectivity to the Internet.
  • RAM on-board random access memory
  • kbps kilobit-per-second
  • a "conventional" PC-class of computer will also have standard peripheral equipment, including a keyboard, mouse (or other cursor control device), and graphics display monitor.
  • the present invention does not rely upon the provision of a central computer or computational facility having one or more computers of substantially greater computational power, memory capacity and, most significantly, connectivity bandwidth, such as, for example, a server computer facility with Internet connectivity via a "Tl" telecommunications link, in order to be advantageously practiced.
  • a server computer facility with Internet connectivity via a "Tl" telecommunications link in order to be advantageously practiced.
  • none of the computers 12 included in system 10 is required to have extraordinary computational, processing, data storage, or communications capabilities.
  • a communications link 14 is shown between computer 12-1 and 12-2.
  • link 14 is intended to represent an electronic data connection between the computers, which connection may involve a direct connection, connection via a local area network (LAN), connection via a wide-area network (WAN), and/or, notably, connection via the Internet.
  • LAN local area network
  • WAN wide-area network
  • Internet Internet
  • connection 14 may perhaps be best established via the Internet, whereas for computers 12 located within the same building, for example, connection(s) 14 may be advantageously made via a LAN. In any event, the present invention is believed to be particularly advantageous in the context of multiple computers communicating via the Internet.
  • link 14 in Figure 1 may incorporate several components, including, for example, a connection between a modem associated with computer 12 via telephone lines to an Internet service provider ("ISP") for connection via the Internet to another computer 12 which may be similarly coupled to the Internet via a modem and telephone line connection to another (or the same) ISP.
  • ISP Internet service provider
  • FIG. 1 shows that computers 12-1 and 12-2 in system 10 are connected via links 14 to a listing service module 18.
  • links 14 may be established in accordance with any one of numerous well-known computer connectivity schemes, including by way of example but not limitation, direct connections, LAN or WAN connections, and or Internet connections.
  • the details of how links 14 in system 10 are established are not believed to be of any particular relevance for the purposes of the present disclosure, and will not be further discussed herein.
  • Listing service module 18 may operate on conventional PC class of computers. The primary function of listing service module 18 is to establish and maintain a telepresence listing service represented by block 20 in Figure 1. As will be hereinafter described in further detail, listing service module 18 maintains a mapping of the identities of participants in a telepresence session to their last known online addresses, for example, their last known Internet addresses. When two or more users wish to initiate a telepresence session in accordance with the presently disclosed embodiment, each user will establish a connection 14 with and consult listing service module 18 to obtain the address(es) of the other users intended to be included in the particular telepresence session being initiated. Obtaining this address information enables each user to establish, as necessary, connections 14 with other users.
  • the present invention is implemented in the form of a computer application adapted to be executed by each computer 12 included in system 10.
  • This application is sometimes referred to herein as the Holodesk application, and the software architecture of the Holodesk application is what is represented by the blocks within each computer 12 shown in Figure 1.
  • the Holodesk application is implemented as one or more computer programs or modules written in the C++ programming language (although those of ordinary skill in the field of computer science will appreciate that the application(s) may be written in other programming languages).
  • the Holodesk application comprises a plurality of individual functional components, including, as shown in Figure 1: a graphical user interface component 20 having associated therewith a graphics component 21, a text component 22, and a list component 24; a listing module 26; a MUTech module 28; a link module 30; an AChat module 32; a service manager module 34; an http module 38. Finally, each computer has associated therewith a connection service module 40.
  • a graphical user interface component 20 having associated therewith a graphics component 21, a text component 22, and a list component 24; a listing module 26; a MUTech module 28; a link module 30; an AChat module 32; a service manager module 34; an http module 38.
  • each computer has associated therewith a connection service module 40.
  • the Holodesk application will be described hereinbelow in terms of these various architectural components.
  • GUI Graphical user interface
  • CRT cathode ray tube
  • a graphics component 21 of GUI 20 is, in the presently disclosed embodiment of the invention, a virtual reality modeling language (“VRML”) browser with a Component Object Model- (“COM”)-based interface.
  • VRML browsers are well-known to those of ordinary skill in the art; in the presently preferred embodiment of the invention, graphics component 21 is the Cosmo ® Player 2.1 Universal VRML 2.0 Client, commercially available from Platinum Technology, Inc., Oakbrook Terrace, Illinois. Other VRML browsers believed to be suitable for the purposes of practicing the invention are known and commercially available.
  • GUI 20 may "pop up" within GUI 20 at different times during a Holodesk telepresence session and ask user to take action.
  • text component 22 may be displayed within GUI 20 with a request that the user identify (for example, by typing on the computer keyboard (not shown)) a computer file stored on a user's hard disk drive to be brought into the virtual environment and made accessible to other participants in a telepresence session.
  • text component 22 is
  • List component 24 of GUI 20 essentially comprises a menu or list of various operations that may be performed in connection with a telepresence session.
  • operations include, by way of example, initiating a private textual exchange ("whispering") to another participant during a telepresence session. It is believed that the development of a list component 24 would be a matter of routine software development for those of ordinary skill in the art.
  • Each GUI 20, accompanied by audio communication between participants of a telepresence session constitutes the primary means by which a virtual environment is presented to users of system 10.
  • each GUI 20 is displayed on a computer display screen (monitor) associated with one of the computers 12 in system 10.
  • the virtual environment is "shared" among each user, in the sense that the virtual environment is dynamic in its appearance, and in the sense that changes to the virtual environment are manifested in real-time in the GUI of each user of system 10.
  • real-time shall be construed to take into account the transmission delays that may be introduced as electronic information is communicated between computers 12 via links 14 in system 10.
  • the shared virtual environment is a two-dimensional rendering of a virtual three-dimensional space.
  • a virtual environment is provided that uses the metaphor of a business office space, with virtual desks, tables, chairs, doors, windows, and the like. It is contemplated that the users of system 10 may select from among a plurality of different "worlds" upon initiation of a telepresence session using system 10.
  • the range of possible "worlds” is essentially limitless; some worlds may be more or less realistic, such as the office metaphor world mentioned above, while others may be more fanciful or surreal.
  • the virtual environment is presented in a manner such that each user of system 10 is able to "navigate” through the virtual world represented by an avatar.
  • each user can "see” and interact with the avatars representing the other participants in the session.
  • the "world” defining a virtual environment consists of a plurality of "objects” defined in the VRML language.
  • Each object in a world has certain initial attributes, including, by way of example, a predefined appearance (i.e., how that object is visually represented in GUI 20), behavior (i.e., how it may move within the virtual environment), and properties (i.e., how users may interact with an object in the world).
  • a predefined appearance i.e., how that object is visually represented in GUI 20
  • behavior i.e., how it may move within the virtual environment
  • properties i.e., how users may interact with an object in the world.
  • the term "world” essentially refers to the aggregation of VRML objects which initially define the appearance of a virtual environment as it is displayed in the GUI 20 of each user of system 10.
  • state of the virtual environment i.e., the aggregation of objects in the world and their attributes at any given time, is dynamic, being subject to changes as a result of actions that individuals interacting in the virtual environment might take during a telepresence session.
  • users may introduce new objects into the world, thereby altering the overall state of the virtual environment. For example, a user may cause a computer file stored on his or her local hard disk drive to be introduced into the world.
  • the file could be assigned its own representation in the virtual environment much like an "avatar,” (although the term “avatar” is more commonly applied to the representation of human beings in a virtual environment), and could be made accessible to other users who might, through their respective avatars, "pick up” the representation of the file, copy the file to their hard drives, and so on.
  • an “avatar” is more commonly applied to the representation of human beings in a virtual environment
  • MUTech module 28 associated with each user's Holodesk application that is primarily responsible for coordinating the exchange of virtual environment state information to support this shared virtual environment aspect of the system 10 in accordance with the presently disclosed embodiment of the invention.
  • Listing module 26 is a software module responsible for communicating with listing service 18.
  • listing module 26 is responsible for keeping entries in listing service 18 up-to-date. For example, listing module 26 must inform listing service 20 when a user has an active Internet connection (i.e., when the user's IP address may change on a dynamic basis).
  • Listing module 26 is also responsible for enabling a user to create one or more profiles to be listed in listing service 20, and to modify those profiles.
  • Listing module 26 may communicate with listing service 18 over a TCP/IP socket, and may communicate using Microsoft ASP web-forms.
  • listing module 26 The primary function of listing module 26 is to "register" a user with the listing service 18, i.e., to inform listing service 18 about a user's status (e.g., IP address, port number, user profile).
  • the listing service information may be accessed by others wishing to locate and conduct a telepresence session with other users who are registered with listing service 18.
  • MUTech (short for "Multi-User Technology") module 28 is a software module which operates to support avatar-based interaction within a virtual environment established in accordance with the presently disclosed embodiment.
  • MUTech modules 28 among all participating computers 12 in a system 10 collectively function to, among other things, coordinate the position and state of objects, including avatars, present in the virtual environment; coordinate the exchange of information between objects in a virtual environment; and identify and integrate at run-time, interaction capabilities implemented outside of VRML.
  • one or more MUTech modules 28 D but not necessarily more than one MUTech module 28 D is designated at any time during a telepresence session on system 10 as the "host" MUTech module(s) 28 for a given telepresence session.
  • MUTech module 28 includes components that are to some extent derived from technology developed or being developed by the "Living Worlds" Working Group of the VRML Consortium, Inc.
  • the VRML Consortium, Inc. http://www.yrml.org; contact@vrml.org
  • the VRML Consortium, Inc. http://www.yrml.org; contact@vrml.org
  • the present invention also adopts technology developed or being developed by the Humanoid Animation Working Group of the VRML Consortium, Inc.
  • Living Worlds is essentially a specification for method of multi-user communication in VRML, i.e., a proposal for extension or recommended practice of use for VRML.
  • Living Worlds is public domain technology.
  • MUTech module 28 is engaged in communicating the state of objects and environment to a MUTech module 28 acting as the host for a given telepresence session; the MUTech host 28H, in turn, functions to communicate the state information to all computers 12 in the telepresence system 10.
  • MUTech host 28H shall be used to designate the one (or more) MUTech modules designated and functioning as the host for a given telepresence session, it being understood that all other MUTech modules 28 associated with other computers 12 in a system 10 having certain operational and functional responsibilities involving interaction with the MUTech host 28H for a particular telepresence session.
  • MUTech modules 28 in accordance with the presently disclosed embodiment of the invention also include components derived to some degree from the work done by the Humanoid Animation Working Group (http://ece.uwaterloo.ca/ ⁇ h-anim), which has developed a specification or definition of interchangeable humanoids and animations (e.g., avatars) in standard VRML 2.0.
  • Animations include limb movements and the like, and possibly (in future versions), facial expressions, and lip synchronization with sound.
  • the Humanoid Animation Working Group's specification is referred to herein as "H- Anim.”
  • the above-referenced Living Worlds specification is incorporated into the present disclosure as Appendix 1. Further, the specification of a "core subset" of the overall Living Worlds specification is incorporated herein as Appendix 2.
  • the above-referenced H-Anim specification is incorporated herein as Appendix 3. It is assumed that persons of ordinary skill in the art have a working familiarity with and understanding of the specifications of Appendices 1, 2, and 3.
  • communication of state information between computers 12 in system 10 is accomplished by socket TCP protocol using binary encoded packets.
  • the packets may be compressed by MUTech modules 28 using any one of a number of known and commercially available compression technologies.
  • Link module 30 is a software module used to communicate with the connection services 40 associated with other computers 12 in system 10. Together, link module 30 and connection service 40 operate to perform connection arbitration between computers 12 in system 10. It is the responsibility of connection service 40 of each computer 12 to verify other users by consulting with listing service 18 .
  • Connection service 40 for each computer 12 communicates with listing service 18 via a TCP/IP socket, as well as via a web interface.
  • Connection service 40 notifies listing service 18 of its current IP address and port number. Such notification is important to the extent that it supports dynamic IP addresses of users, i.e., users who access the Internet via an Internet service provider, whereby the user's IP address is likely to be different each time the user logs onto the Internet via his or her ISP.
  • AChat module 32 is a software component responsible for establishing point-to-point connections for two-way audio streaming between computers 12 in system 10. During a given telepresence session, each user can establish any number of connections, up to limit of user's bandwidth.
  • Various audio streaming technologies are known and commercially- available, and it is believed that the details of implementing AChat module 32 for supporting audio streaming across links 14 between computers 12 in system 10 would be a matter of routine development to those of ordinary skill in the art.
  • SERVICE MANAGER 34 Service manager 34 is a software component of the Holodesk application that is designed to provide extra services to the VRML content.
  • service manager 34 provides a bridge between VRML content (description of world, what objects are in it, and so on) and the user's local operating system. This enables, for example, a user to introduce a locally-stored file as a new object in the virtual environment, such that other participants can access that file.
  • VRML content description of world, what objects are in it, and so on
  • HTTP MODULE 38 For each computer 12 in system 10, an http component 38 is provided for establishing hypertext transfer protocol ("http") connections with other computers 12 in the system. Such connections are established periodically during a telepresence session when files or other data must be exchanged between two computers 12. For example, one participant may introduce a local file as a shared object into the virtual environment. Within the virtual environment, such a file would be identified with a URL. When another participant wishes to access the file, that participant would not obtain it from MUTech host 28H, but instead by establishing an http connection with the computer from which the file was introduced into the virtual environment. When a participant shares a file in Holodesk, that file becomes available for download via the built-in HTTP server module.
  • http hypertext transfer protocol
  • a participant In common use, a participant is likely to be attached to a publicly available network such as the Internet. Other users of this larger network may be able to download files without the participant's intention to provide access to those files.
  • each file shared during a telepresence session is assigned a text-encoded 64-bit semi-random identifier only valid for the session in progress. Addresses created using these identifiers are provided to the VRML content instead of actual file paths on the user's computer.
  • the HTTP server will also not service any directories or provide lists of files in any directory. The HTTP server will not service file requests other than those explicitly shared from the user's computer. It is believed that implementation of the http module 38 for the purposes of practicing the present invention would be a matter of routine development to those of ordinary skill in the art; hence the details of such implementation shall not be further described herein.
  • Listing service module 18 verifies the identity of the user and sends a response message indicating whether the user can connect to the telepresence session.
  • host i.e., the user(s) on whose computer(s) 12 a MUTech module 28 will take responsibility for the duties of MUTech host 28H as herein described.
  • the MUTech host 28H is executed on the computer 12 of one or more of the participants in the telepresence session, and not on any sort of central server.
  • a user After being granted permission to participate in the telepresence session, a user next must specify the avatar with which it desires to be represented in the virtual environment, along with a specification of the avatar's capabilities.
  • This information is communicated to the MUTech host 28H for the telepresence session; MUTech host 28H is responsible for disseminating the information to all participants.
  • avatars are VRML objects.
  • a user To identify its avatar to the participants in the telepresence session, a user merely specifies the location where the avatar is stored. Notably, this location may be essentially anywhere; users' avatars need not even be stored on any of the computers 12 participating in the session, but may be stored at a central location functioning essentially as a "library" of avatars.
  • the "location" of a user's avatar may be identified to the MUTech host 28H in the form of an IP address or URL and a filename. This address/filename information is disseminated by the MUTech host 28H to all participants in the session; each participant's MUTech module 28 is then responsible for retrieving the avatar VRML objects for other participants from the specified locations.
  • MUTech host 28H sends a message to all participants identifying the VRML "world" defining the appearance of the virtual environment.
  • the identification of the world is done in the form of an IP address or URL and a filename.
  • the VRML world may reside essentially anywhere. It is incumbent upon each user to retrieve the identified world from the specified location.
  • individual computers 12 in system 10 may have one or more VRML worlds stored locally on their hard drives.
  • the world identified by the MUTech host 28H in initiating a given telepresence session may already be present on some of the computers 12. In such instances, it would not be necessary for those computers 12 to retrieve the world from an external source.
  • the file information provided by the MUTech host 28H includes a simple name, for example, "Garden" which may match a name of a world already installed on the client user's machine.
  • MUTech client 28 Also included in the file information is a small amount of identification data, which the MUTech client 28 uses to identify if the world on the client user's machine with the same simple name is actually the same binary file as the one referred to by the address provided by the MUTech host 28H. If both the simple name and the binary data match, the data is loaded from the client user's machine locally without using the network address.
  • MUTech host 28H will begin sending packets of information to each of the participating computers 12 identifying other participants in the session. These packets of information would be essentially the same as those that each user initially sends to the
  • MUTech host 28H comprising URL and/or IP addresses corresponding to the avatars by which each of the other users wishes to be represented in the virtual environment. Each user's MUTech module 28 would then be responsible for retrieving the identified avatars corresponding to the other users. Next, MUTech host 28H will broadcast information to all users identifying all
  • shared objects are those VRML objects in the virtual environment with which each user's avatar may interact. Examples of shared objects will be described hereinbelow in further detail.
  • MUTECH MESSAGING Because the telepresence system 10 in accordance with the presently disclosed embodiment of the invention relies upon establishing, as necessary, communications links directly between individual computers 12 via the Internet or similar means, the packets of incremental, updated environment state information sent between MUTech modules 28 on individual computers 12 and MUTech host 28H are relatively small. In addition, there is a limited, predefined set of message types that are communicated between computers 12 and MUTech host 28H. In one embodiment, MUTech messages sent between MUTech modules 28 on computers 12 and MUTech host 28H are encoded, binary packets and include an opcode (operation code) identifying the type of message, along with one or more arguments.
  • opcode operation code
  • Tables 1 and 2 describe the messages that MUTech modules 28 can send to MUTech host 28H, and the types of messages that the MUTech modules 28 receive, respectively, in one embodiment of the invention: Table 1 : Messages that the MUTech Module sends to the MUTech Host
  • int refers to a data type "integer,” e.g., a 16- or 32-bit binary number
  • “String” refers to a data type “String,” i.e., a series of eight-bit ASCII or UTF8 alphanumeric character codes. It is believed that those of ordinary skill in the art will be familiar with such designations.
  • ⁇ int usernumber> refers to an integer identifying a participant's unique user number assigned to that participant upon he or she joining the telepresence session
  • ⁇ String URL> refers to an alphanumeric URL designator.
  • the telepresence system enters into a steady-state mode of operation.
  • each participant through his or her avatar, can navigate (i.e., "move") within the virtual environment, and can interact with other participant's avatars and with any shared objects defined within the virtual environment. It is contemplated that it will commonly be the case that not all areas of a particular virtual environment, and not all shared objects in the virtual environment, will be "visible” to a given user's avatar at one time.
  • each user's avatar's movement and interaction with objects and avatars in the virtual environment causes the "state" of the virtual environment to change on an ongoing, dynamic basis.
  • steady-state operation of system 10 involves the sending and receiving of MUTech messages between MUTech modules 28 and MUTech host 28H.
  • MUTech modules send messages to MUTech host 28H reporting any changes to the state of the environment caused by the user with which they are associated, as well as messages requesting information about the environment and shared objects that are encountered in the environment.
  • MUTech host 28H broadcasts messages it has received from MUTech modules 28 reporting changes to the environment state, and responds to requests from MUTech modules 28 for information about shared objects.
  • each time a user performs an action which changes the state of the virtual environment that user's MUTech module 28 sends a packet of information to the MUTech host 28H describing the changes made. For example, if one user causes his avatar to move from one location to another within the virtual environment, information describing the user's new location is conveyed to the MUTech host, which then broadcasts the information to all users. In this way, the movement of the user is perceived by all participants.
  • sharing of environment state information among all participants in a telepresence session as described herein essentially amounts to distributing control of the state of the virtual environment among the multiple users.
  • MUTech host 28H does not function in the role that a conventional central server does in known multiple-user systems; instead, MUTech host 28H functions merely as a broadcast point through which incremental packets of state information are disseminated from one user to all others.
  • system 10 is provided with a text chat feature by which participants may communicate with one another via typewritten text appearing in text component 22 of GUI 20. It is believed that implementation of this feature, which would involve transmission of text information across links 14 between two or more users, would be a matter of routine development to a person of ordinary skill in the art.
  • Two different text chat modes are contemplated. In a broadcast chat mode, text entered by one participant is displayed in text component 22 of all other participants. One way to accomplish this mode is to have the sending computer 12 communicate the text information to MUTech host 28H, which would then relay the text to all participants.
  • a participant can communicate text to a specified participant, rather than to all participants. Again, this feature would involve the specified participant sending the text to MUTech host 28H with a specification of the user for which it was intended. MUTech host 28H would, in turn, forward the text to the intended recipient.
  • FIG. 2 there are shown line- drawing depictions of the appearance of GUI 20 during a telepresence session conducted on system 10.
  • Figures 2 through 4 are line drawings in order to conform with the requirements for patent drawings, while in actual implementation, the screens appearing in GUI 20 during a telepresence session would preferably be much more life-like, having colors, textures, shading, and the like, as would be familiar to those of ordinary skill in the art.
  • the virtual environment shown in Figure 2 is a scene from a VRML "world” that adopts a business office metaphor, as discussed hereinabove.
  • GUI 20 comprises a graphics component 21, a text component 22, and a list component 24.
  • graphics component 21 displays a realistic depiction of a conference room having a table 150, chairs 152, windows, 154, and so on.
  • a collection of navigation buttons designated generally with reference numeral 156 in Figure 2 enables a user to navigate his or her avatar within the virtual environment, a concept that will be familiar to those of ordinary skill in the art.
  • table 150 may be one of the shared objects within the virtual environment with which telepresence session participants may jointly interact.
  • the VRML data defining the appearance and attributes of table 150 within the virtual environment is initially stored at some specified location (which may be essentially anywhere).
  • the location of this data i.e., a network address such as a IP address or URL
  • the active MUTech hosts(s) 28H for the session.
  • each user's MUTech module 28 is responsible for obtaining the data corresponding to the overall appearance of the room and the appearance and attributes of all shared objects in the room. To obtain this data, each user's MUTech module 28 issues queries to MUTech host 28H. MUTech host 28H responds by providing the addresses of relevant data, including appearance and object description data. When queried by the user's MUTech module, MUTech host 28H identifies the objects in the virtual environment. The host is again queried for current object state data.
  • table 150 is a shared object
  • each user whose avatar is in proximity to table 150 will be provided the same information about the appearance and attributes of table 150.
  • One of the attributes of table 150 may be, for instance, that it is capable of having other shared objects placed thereon, such that those objects may be viewed and/or otherwise interacted with by other users.
  • one user through operation of its service manager 34, may retrieve a computer file from his or her local storage and introduce a representation of that file into the virtual environment.
  • the user's MUTech module 28 would exchange messages with active MUTech host 28H for the purpose of informing MUTech host 28H that a new object has been introduced having a particular representation (i.e., VRML description), particular attributes, and a particular location within the virtual environment.
  • MUTech host 28H will then broadcast a message to all participants (or at least those participants in proximity to table 15) informing each user of the introduction of the new object, and identifying for each user the locations from which the relevant data defining the object may be retrieved.
  • Each user's MUTech module 28 is then responsible for retrieving the data.
  • Each user's graphic component 21 would then be updated to display the newly-introduced shared object.
  • the object may be represented on table 150, for example, as an icon.
  • HTTP server 38 of the user who originally introduced the file as a shared object into the virtual environment Having obtained this address, the user seeking a copy of the file would establish a connection 14 to the specified address and request a copy of the file. This request would be handled by HTTP server 38 of the first user, and the requested data would be sent via connection 14 to the requesting user.
  • the only information passed to and from MUTech host 28H may be address information identifying the locations of relevant data, and not necessarily the relevant data itself.
  • Figure 3 depicts another scene from the virtual environment of the presently disclosed example.
  • a shared object in this case having a defined appearance of a fountain and designated with reference numeral 158 in Figure 3 is given attributes like table 150 described above with reference to Figure 2 whereby it functions as a central repository for users to introduce computer files into the virtual environment.
  • files introduced by users into the virtual environment are represented by familiar file icons 160 (such as those used to represent files within the Microsoft ® Windows ® operating system).
  • the process of introducing files into the environment would be the same as previously described with reference to Figure 2.
  • the introducing user advises MUTech host 28H of the creation of the shared object and of the locations (e.g., IP addresses and/or URLs) of the object's representation and the file represented by the object.
  • the MUTech host 28H provides this information to the appropriate users. Other users wishing to obtain a copy of the file represented by a particular icon 160 would do so by establishing a connection 14 to the specified location and download the data.
  • Figure 4 there is shown still another scene from the exemplary embodiment of the invention. At this location in the virtual environment, a shared object 162 having the appearance of a projection screen is defined.
  • projection screen 162 may be used to enable multiple users present in the room (e.g., avatar 164 is shown in Figure 4) to view images displayed thereon, as follows: First, the MUTech module 28 of a user wishing to display images on screen 162 would exchange messages with the active MUTech server 28 identifying the location(s) of images to be "displayed.” MUTech server 28 then relays this information to the MUTech modules 28 of the appropriate users. Those MUTech modules 28 are then responsible for accessing the information at the specified location. In one example, a user may wish to display a Microsoft ® PowerPoint ® or other type of graphics presentation on screen 162 to be viewable by other users whose avatars are in proximity to screen 162 in the virtual world.
  • the presenting user's MUTech module 28 will exchange messages with active MUTech server 28 advising of the location of the graphics data to be displayed.
  • This data may reside on the computer 12 of the presenting user, or can reside essentially anywhere else to which a connection can be established. All participants wishing to view the images on screen 162 will establish a connection to the specified location and retrieve the data.
  • the graphics data itself is not necessarily transferred from its source to individual users via the active MUTech server 28 (although it may be); only the location(s) of the data incremental updated information about the state of the virtual environment, including identification of the shared object and its attributes may be transferred in this way.
  • responsibility for the functions and operations of MUTech host 28H as herein described may be distributed among more than one of the computers 12 comprising a system 10. In another aspect, it is contemplated that the functions and operations of MUTech host 28H may be performed redundantly and/or simultaneously by more than one computer 12 in a given system 10. It is also to be noted that responsibility for the functions and operations performed by listing service 18, while represented as being performed by separate computer in Figure 1, may in fact be allocated or distributed among multiple computers 12 which are at the same time participating in a given telepresence session, and/or among one or more computers which may be dedicated to the MUTech host functions.
  • the raw data necessary to establish a particular virtual environment may be distributed among not only the computers 12 associated with the participants in a telepresence session, but also among any number of other computers at essentially any locations.
  • the VRML "world” data selected to be used for a particular telepresence session may be stored essentially anywhere accessible by a network (e.g., Internet) connection.
  • Each participant in a given telepresence session merely consults the MUTech hosts(s) 28H nominated or otherwise selected to be “active" for the telepresence session to obtain the network address where the "world” data is located, and then accesses that location (and not the location of the active MUTech host 28H itself) to obtain the "world” data.
  • MUTech hosts(s) 28H nominated or otherwise selected to be “active” for the telepresence session to obtain the network address where the "world” data is located, and then accesses that location (and not the location of the active MUTech host 28H itself) to obtain the "world” data.
  • any number of "telepresence service providers” may exist where libraries of "world” data, avatars, shared object data, and the like may be stored.
  • That service provider would become a part of system 10 only in the sense that that service provider would be periodically accessed by the participants in the session to obtain the necessary data.
  • the service provider would not function in the capacity of controlling the telepresence session, as in conventional central- server multi-user systems, but merely as a repository or database of data to be shared among participants in the telepresence system.
  • node shall be used herein as a more general designation of a computer that is or is capable of becoming a part of a telepresence session (e.g., a MUTech node), either to perform the function of computers 12 in the embodiment described with reference to Figure 1, or to perform the function of a database to be accessed by such computers 12 (e.g., a passivated or support node), or both, as the case may be.
  • a MUTech node e.g., a MUTech node
  • a telepresence system as contemplated by the inventors may comprise an interconnection and interaction of entire systems 10, in the sense that each of computers 12 in the embodiment of Figure 1 may, in some embodiments in fact comprise a separate (but by definition not necessarily or entirely unconnected) telepresence system 10.
  • a system 10 such as is depicted in the illustrative embodiment of Figure 1 can itself comprise a node in a larger telepresence system of interconnected telepresence systems 10.
  • FIG 5 there is shown one example of an interconnected system 100 of telepresence nodes, designated in Figure 5 with reference numerals 102, in accordance with one embodiment of the invention. In Figure 5, the character of each node 102 may be different.
  • Some nodes 102 may be individual computers 12 executing the Holodesk application (e.g., nodes executing on one or more MUTech modules). Other nodes may comprise one or more computers not executing the Holodesk application but providing databases accessible to other computers in the system (e.g., passivated nodes or support nodes. Notably, and as is apparent from Figure 5, some nodes 102 in system 100 may comprise an entire telepresence system 10 comprising a plurality of interconnected computers 12 executing the HolodeskTM application. In this sense, the term "node 102" shall be interpreted herein to include both individual computers 12 and entire telepresence systems 10.
  • node 102 shall also be interpreted to include passivated nodes or support nodes, that is, computers or networks of computers functioning as a database of data accessed by other computers 12, telepresence systems 10, and/or nodes 102 to provide VRML "world” data, avatar data, shared object data, and the like, to participants in a telepresence session.
  • the links between nodes 102 in system 100 are designated with reference numeral 14, just as the links between computers 12 in the simple embodiment of Figure 1 were.
  • connection 14 is established between two computers 12 and a connection 14 established between two telepresence systems 10, or between two nodes 102, or between two complete telepresence systems 100, and so on.
  • Connections 14 are established sporadically and on an as-needed basis, whenever information is to be communicated between two nodes 102 in a system.
  • Connections 14 are established, for example, to provide to or request from active MUTech host 28H incremental updated information about the current state of the shared virtual environment.
  • Connections 14 are also established for the purposes of obtaining data (such as VRML data and the like) from specified locations.
  • Connections 14 are also established in support of the real-time audio Achat function discussed above.
  • node 102 and “connection 14" as set forth above, it will be apparent to those of ordinary skill in the art that systems 100 in accordance with the presently disclosed embodiment of the invention have an essentially recursive- or fractallike nature. Indeed, it is contemplated, for example, that one or more of computers 12 in system 10 shown in Figure 5 may comprise a separate telepresence system 10 comprising a network of computers 12.
  • system 100 in Figure 5 may itself be nothing more than a node 102 of a larger telepresence system; such larger telepresence system, in turn, may itself be a node of an even larger telepresence system, and so on ad infinitum.
  • a "node" 102 may reside on a single computer 12, or may be distributed across multiple computers 12 interconnected by links 14, and that multiple nodes 102 may reside on a single computer.
  • telepresence systems such as system 10 in Figure 1 or system 100 in
  • Each system (10 or 100) is a collection of nodes 102, where a "node 102" may itself comprise, without limitation, a computer 12, a system 10 of interconnected computers 12, a system 100 of interconnected systems 10, and so on.
  • Each node 102 has a connection, direct or indirect, most commonly over the Internet, to at least one active MUTech host 28H residing on some computer 12.
  • Each node 102 can establish a connection to one or more databases containing data defining the appearance and content of a shared virtual environment.
  • the overall collection of data defining a given virtual environment may (and is likely to) be distributed over a plurality of remote locations, i.e., the data may be stored in a plurality of separate remote nodes 102 in the overall system.
  • Each active Holodesk application associated with a particular telepresence session is capable of searching for, transferring, receiving or otherwise acting upon data stored in any database in any node associated with the overall telepresence system.
  • Users participating in a telepresence session are registered with a listing service 18, such that even if a user has a dynamic network (e.g., IP) address, other users shall be capable of maintaining contact with that user.
  • a dynamic network e.g., IP
  • the function of the listing service 18 may be performed by a single computer 12 in one of the nodes 102 of the overall system, or may be distributed among multiple computers 12, or may be performed collectively by a system 10 or even a system 100.
  • the functions of the active MUTech host 28H may at any given time be performed by a single computer 12, or by multiple computers 12, or collectively by a system 10 or by a system 100.
  • the allocation of responsibility for performing the functions of the active MUTech host 28H may be dynamic, in the sense that the duties of the active MUTech host 28H may be transferred from computer 12 to computer 12, from system 10 to system 10, and/or from system 100 to system 100.
  • listing service 18 is depicted as residing in one location. It has already been noted herein that, as is the case for any functional node, the function of listing service 18 to maintain on a dynamic basis the necessary identifying information about users, including their addresses (e.g., IP addresses and/or URLs), names, locations from which avatar data may be retrieved, and so on) D can be performed centrally by any computer or may be distributed among a plurality of interconnected computers.
  • addresses e.g., IP addresses and/or URLs
  • the listing service function can be performed by any computer whether or not that computer is also executing the Holodesk application; that is, the listing service function may be performed by a MUTech node, a passivated node, or a support node.
  • the listing service function can be performed by any node 102 in a telepresence system, where, as noted above, a node 102 can itself comprise a computer 12, or a telepresence system 10 comprised of a plurality of computers 122, or a telepresence system 100 comprised of a plurality of telepresence systems 10, and so on.
  • one node 102 in a system 100 may perform a so-called meta-listing service function.
  • a node may maintain a list of a plurality of separate listing services 18.
  • WWW Internet World Wide Web
  • This concept of a meta-listing service is very similar to Internet World Wide Web (“WWW”) sites that contain nothing but hyperlinks to other WWW sites.
  • WWW World Wide Web
  • the concept of a meta-listing may be better appreciated with reference to the illustrative embodiment of Figure 6, which, like the embodiment of Figure 5, comprises a system 100' comprising a plurality of nodes 102 interconnected by connections 14, wherein each node 102 may be an individual computer 12, a telepresence system 10, and so on.
  • each of the computers in each of the nodes collectively comprises a telepresence system in accordance with the present embodiment of the invention
  • at least one MUTech host 28H and at least one listing service 18 will be provided.
  • the MUTech host function 28H may be distributed among one or more computers in one or more nodes 102 in system 100', as may the functions of listing service 18.
  • a meta-listing node (“MLN") 110 is also included in the embodiment of Figure 6.
  • MLN 110 is depicted in Figure 6 as a separate, apparently “standalone" component, it is to be understood that like the MUTech host 28H and listing service 20, the functions performed by MLN 110 as will be described herein may be performed by any one or more computers, including any one or more computers of which system 110' is comprised. In the disclosed embodiment, MLN 110 functions to maintain a listing of listing services like listing service 18. That is, MLN provides essentially a database of separate telepresence systems such as telepresence system 10 from Figure 1 or telepresence system 100 from Figure 5.
  • MLN 110 gives a telepresence system such as telepresence system 100 the ability to allow migration of individual users, alone or in groups, from one subset of nodes to another, to define and undefine subsets of nodes by division or integration of other subgroups, on a dynamic basis, all without requiring any overriding or central control hierarchy.
  • system 100' can be thought of as comprising essentially two sub-groups of nodes 102, a first being designated within dashed line 112-1 and a second being designated within dashed line 112-2.
  • subgroups of nodes 102 such as 112-1 and 112-2 in Figure 6 will be referred to generally as "local telepresence networks 112," with the "-x" suffix convention being used to distinguish one specific local telepresence network from another.
  • a particular local telepresence network 112 is characterized by the definition and state of its virtual environment.
  • participants may join or leave a given telepresence session at will.
  • a participant needs only to identify the desired active MUTech host 28H for the session by means of a look-up in listing service 20, and then, through the participant's MUTech module 28, advising the active MUTech host 28H of its desire to join.
  • the MUTech host 28H will notify all other participants of the "newcomer's" arrival, which essentially amounts to an incremental change in the state of the virtual environment. Other participants thereafter must retrieve information about the newcomer for example, the newcomer's avatar data and other attributes. Thus, adding a new participant to a telepresence session amounts to little more than the establishment of new links 14 between that newcomer, the MUTech host 28H, and other participants, a process that is coordinated through operation of MUTech server. In much the same way, it is contemplated to be possible to join two telepresence systems together; this is illustrated in Figure 6.
  • MLN 110 in Figure 6 maintains a list of multiple listing services 18, including the listing services 18 associated with the local telepresence networks 112-1 and 112-2 in Figure 6.
  • local networks 112-1 and 112-2 it is possible for local networks 112-1 and 112-2 to become aware of each other's existence, and for a link 14 to be established, either directly or indirectly, between one or more nodes 102 in the respective local networks 112-1 and 112-2. This may be accomplished even if the two (or more) local networks have completely different virtual environments.
  • MUTech host 28H associated with local telepresence network 112-1 define a new shared object within the virtual environment of local network 112-1. This new shared object is defined to take on the appearance of a door in the virtual environment of local network 112-1.
  • the new shared object is defined to have attributes such that when activated by a participant in the telepresence environment of local network 112-1, it appears to the participant that he or she enters the virtual environment of local network 112-2; that is, the participant is directed to the active MUTech server in local network 112-2 to obtain virtual environment state information.
  • a corresponding, reciprocal "door" can be defined within the virtual environment of local network 112-2, to enable participants in the virtual environment within local network 112-2 to similarly migrate to the virtual environment within local network 112-1.
  • the migration of participants or nodes from the virtual environment of one local telepresence network to the virtual environment of another may or may not involve a connection made via MLN 110.
  • maintaining a connection between nodes in two local telepresence networks 112 via MLN 110 may be advantageous for the purposes of maintaining and ultimately reestablishing an association of a particular node 102 with its original local network 112, although it is also contemplated that a direct connection between a node 102 in one local network and the active MUTech host 28H in another local network, without further involvement by MLN, may also offer advantages In addition to migrating between separate virtual environments established within separate local telepresence networks 112, it is also possible to create separate subsidiary local telepresence networks, having separate virtual environments, within an individual local telepresence network.
  • FIG. 6 This is illustrated in Figure 6, wherein a subgroup of nodes 102 within local telepresence network 112-2 are shown within a dashed line designated with reference numeral 116.
  • Participants associated with a sub-group of nodes 102 within a given local telepresence network, such as sub-group 114 of local network 112-2 can, without the intervention of any centralized server or controller, perceive a "space" within the virtual environment different from that perceived by participants associated with the remaining nodes 102 in the local network 112-2.
  • sub-group 114 otherwise retains its association with the other nodes 102 in local network 112-2, including its links 14 with such other nodes, however, participants associated with nodes in sub-group 114 would perceive that others in the local network 112-2 are within the same virtual environment, but "seeing" different things at a different location. For example, all users within local network 112-2 would retain their abilities to AChat with one another even while sub-group 114 constitutes a subsidiary local network of local network 112-2.
  • each individual link 14 in a system 10 or 100 may vary dynamically over time, depending, for example, upon the levels of traffic present on the communications provider(s) on which the links 14 are established. Some links 14 in a system 10 or 100 may be inherently faster "Tl" connections, for example, while others may have bandwidth limitations arising from the use of a relatively slower modem. To address the issue of link performance, it is contemplated that in one embodiment of the invention, one or more nodes 102 performing a message and data repeater function may be provided in a system 10 or system 100.
  • a node 102 providing such a repeater function (hereinafter referred to as a "repeater node 102") will establish multiple connections 14 with other nodes 102 such that it accepts input (MUTech messages, data, and the like) from one or more nodes 102 and output the received messages and data to one or more nodes 102.
  • MUTech messages input
  • data data
  • repeater nodes output the received messages and data to one or more nodes 102.
  • the system as a whole can benefit from the higher bandwidth of some links 14 present in the system.
  • Such a repeater node is one example of a passivated node (as that term is described above) that is capable of taking in and sending out data, including but not necessarily limited to environment state information, but not adapted to alter the state of the environment.
  • a system 10 or 100 in accordance with the presently disclosed embodiment of the invention may include one or more than one repeater node. Further, it is contemplated that decisions as to which nodes 102, if any, in a given system are to perform the function of a repeater node may be made on a dynamic basis. For example, one or more nodes 102 in a system may periodically or on an ongoing basis undertake system performance monitoring to identify links 14 that are exhibiting poor throughput, and, conversely, links 14 that are exhibiting good throughput, and thereafter make decisions regarding the allocation of repeater duties with the goal of optimizing overall system performance.
  • one or more nodes 102 may participate in monitoring the performance of various links 14 in the system by exchanging and relaying time-encoded test messages to assess the throughput performance.
  • Various off- the-shelf network performance monitoring software packages that would be suitable for the purposes of this aspect of the invention are known and commercially available.
  • network service providers e.g., Internet service providers
  • network service providers will provide real-time feedback to users regarding throughput performance.
  • the architectural characteristics of systems in accordance with the principles of the present invention are such that the optimization of overall system performance can be reduced to the classic computer science maximum flow problem.
  • the maximum flow problem has been the subject of substantial study over the years, and those of ordinary skill in the art will appreciate how the fruits of such study may be applied to the task of optimizing a system such as systems 10 or 100 as disclosed herein.
  • the optimization of a system in accordance with the principles of the present invention can be accomplished by dynamically configuring the number and location of repeater nodes within a system.
  • ECOMMERCE The present invention as described herein is believed to have characteristics of significant benefit to the area of many types of informational, promotional and/or transactional interaction conducted via computer-based platforms, including, e.g., Internet- based retail sales transactions.
  • One expression of this concept is presently referred to in common parlance as "ecommerce," a concept generally known as encompassing the promotion, advertisement and/or exchange of data, information, goods or services, whether or not for value, conducted electronically.
  • ecommerce at the time of this disclosure is widely understood and is commonly most closely associated with transactions involving communication conducted electronically via the Internet. It is specifically contemplated, however, that interconnections between computers, or networks of computers, not entirely or even at all involving the Internet would be suitable for the purposes of practicing the present invention.
  • FIG. 7 represents one example of how systems in accordance with the present invention may be applied to the field of ecommerce.
  • a system 100 comprising a plurality of local telepresence networks 112.
  • each local telepresence network 112 comprises a plurality of nodes 102 connected by links 14, where, to reiterate, each node 102 may be a single computer 12 associated with a single telepresence session participant, or a separate local telepresence network 112 or telepresence system 10, or a separate telepresence system 100 of interconnected telepresence systems 10.
  • each node 102 in system 100 may or may not be executing the Holodesk application, and/or may be simply a database of information accessible by other computers 12 in the system 100".
  • At least one node 102 in system 100' ' has associated therewith a computer 12 functioning as the active MUTech host 28H for the overall system 100".
  • this node is a member of local telepresence network 112-4, and is designated with reference numerals 102, 12 and 28H to emphasize that this node 102 is a computer 12 functioning as the MUTech host 28H for system 100".
  • At least one node 102 in system 100" has associated therewith a computer 12 functioning as a listing service 18.
  • this node is a member of local telepresence network 112-3, and is designated with reference numerals 102, 12, and 20 to emphasize that this node 102 is a computer 12 functioning as the listing service 18 for the system 100".
  • system 100" has associated therewith a meta- listing node 110, also a member of local telepresence network 112-3 in the present embodiment. This node is designated with reference numerals 102 and 114 to emphasize that this node 102 is performing the function of MLN 110 for the system 100".
  • the virtual environment defined for the telepresence session adopts a retail shopping mall metaphor; that is, the virtual environment or "world” VRML data accessed by each participant's computer 12 as directed by MUTech host 28H is defined to present the image of a shopping mall on each participant's graphic component 21.
  • the address of local network 112-5 is the address of local network 112-5.
  • local network 112-5 comprises a plurality of telepresence nodes 102 at which virtual environment data is stored which, when accessed enables participants to enter a virtual retail store in the virtual environment.
  • local telepresence network 112-5 is maintained by the nationally chain of retail outlets, and that each node 102 in local network 112-5 corresponds to a different category of goods offered for sale by that chain.
  • One or more participants in the telepresence session being conducted on system 100' ' may wish to "shop" for particular goods. From meta-listing node 110, these participants can identify the address of the node 102 in local network 112-5 corresponding to those goods, and can, by establishing a subsidiary local network within whatever local network 112 they are in, can access the virtual environment data in the node 102 corresponding to those goods.
  • the virtual environment data maintained at the nodes 102 in local network 112-5 can include shared objects corresponding to the goods offered for sale. Interacting with these shared objects would enable a participant to, for example, view a graphical image of the goods in question, view textual information regarding prices, sizes, availability, and so on.
  • the virtual environment data may further include shared objects akin to virtual "cash registers" whereby a participant could purchase goods electronically (for example by using a credit card).
  • the virtual environment databases it maintains in local network 112-5 may be tied into or be a part of the retailer's actual catalog sales, inventory system and/or accounting systems, such that when a purchase is made in the virtual environment, the purchased goods are automatically sent to the purchaser, and the transaction reflected in the retailer's inventory and accounting systems.
  • the system discussed above with reference to Figure 7 is but one example of how telepresence systems in accordance with the presently disclosed embodiment of the invention may find advantageous application to the emerging concept of on-line transactions and ecommerce. It is believed that those of ordinary skill in the art having the benefit of the present disclosure will readily appreciate that other metaphors and configurations may be adopted for accomplishing a very wide variety of on-line transactions. To be sure, the technology of the present invention is in no sense limited to retail sales, but may find application in many types of transactional and/or interactive situations.
  • the present invention enables online merchants to render a virtual reality representation of a store and support interactive customer service online.
  • the invention supports contextual selling, by enabling the creation of worlds that provide supporting context for the sale of a product. For example, a sporting goods retailer might create as their virtual reality world containing a football arena, baseball park, and hockey rink. Virtual reality simulations of players using selected products, demonstrating their features and capabilities within this world inform customers and encourage product sales.
  • the invention makes more efficient use of display space, by allowing dynamic reallocation of display space.
  • a commercial electronic commerce may reconfigure itself to better display products to meet the expectations of an individual customer, a new level of customer personalization.
  • the invention supports integrated online transactions, as objects within the world can be tied to database constructs in the merchants inventory and pricing databases. Transactions in the virtual world mimic exactly transactions at an electronic cash register or customer service terminal.
  • the interactive nature of telepresence enables direct, online customer service and support.
  • Telepresence fundamentally changes online commerce by lowering the distinction between brick-and-mortar establishments and online commerce sites.
  • the virtual reality world can exactly model the features and aesthetics of its real counterpart, including interactive customer service. More impressively, however, virtual reality enables the creation of fantastic commercial environments. It will provide a different way of shopping from that conducted over the internet. This new experience as set out above is based on the shared object.
  • Catalogue sales is an important component of e-commerce over the networks of the present invention. Online customer service and customer relations management. Various catalogue items can be downloaded into the personal computer and reviewed off-line and sales and inquires completed online. By using a combination of stored data at user's node the bandwidth to conduct business is minimized.
  • Online Education is another feature of the present invention as mentioned with respect to share objects.
  • the present invention provides new learning environments that complement current University and online learning models.
  • the education community has been concentrating on the new possibilities afforded by distance education, as enabled by the Internet.
  • the invention combines the power of network communications with an immersive learning environment to create a compelling new platform for online education.
  • an anatomy class in which the students and the lecturer are aspirated into the human lung, cross over into the blood stream, and explore the human heart.
  • a chemistry class can be provided in which the periodic table of the elements is three- dimensional; students can directly observe the shell construction of Einsteinium and other elements.
  • Figures 9a through 9g are flow diagrams outlining in detail the steps taken to initiate and conduct a telepresence session on a system such as a system 100 in accordance with one embodiment of the invention.
  • Figures 9a through 9g utilize a standard flow diagramming convention, wherein individual steps of the process being diagrammed appear in rectangular symbols such as those designated with reference numerals 300 and 302 in Figure 9a, and decision steps in which the process can proceed in two or more separate directions depending upon dynamic system and state conditions are represented in diamond-shaped symbols, such as that designated with reference numeral 310 in Figure 9a.
  • Figure 9a is a flow diagram consisting of elements designated with reference numerals in the range from 300 to 366 inclusive, and illustrates the procedure followed for a user, via its connection service 40, to connect to a telepresence session.
  • Figure 9b is a flow diagram consisting of elements designated with reference numerals in the range from 368 to 410 inclusive, and illustrates the steps taken by a user's HolodeskTM application upon connection to a telepresence session;
  • Figure 9c is a flow diagram consisting of elements designated with reference numerals in the range from 412 to 436 inclusive, and illustrates the procedure undertaken when a telepresence session participant wishes to introduce an electronic file into the virtual environment associated with a telepresence session;
  • Figure 9d is a flow diagram consisting of elements designated with reference numerals in the range from 438 to 460 inclusive, and illustrates the steps associated with initiation of an AChat (audio chat) connection between two participants in a telepresence session;
  • Figure 9e is a flow diagram consist
  • the invention may be implemented in part by programming a computer processor.
  • the programming may be accomplished through the use of a program storage device readable by the processor that encodes a program of instructions executable by the processor for performing the operations described above.
  • the program storage device may take the form of, e.g., a floppy disk; a CD-ROM; a memory device (e.g., RAM, ROM, EPROM, EEPROM, etc.); and other forms of the kind well-known in the art or subsequently developed.
  • the program of instructions may be "object code,” i.e., in binary form that is executable more-or-less directly by the computer; in "source code” that requires compilation or interpretation before execution; or in some intermediate form such as partially compiled code.
  • the program storage device may be one that is directly readable by the processor, or it may be one that is unusable by the processor er se but that provides intermediate storage of the program of instructions.
  • the program of instructions may be read directly from the program storage device by the processor; alternatively, the program of instructions may be temporarily or permanently stored in the program storage device and transmitted from it to the processor over one or more links, e.g., over a telephone connection (such as a modem connection or an ISDN line); over a cable-modem hookup; over the Internet; via radio- or satellite transmission; etc., possibly with other program storage devices providing intermediate storage along the way.
  • a telephone connection such as a modem connection or an ISDN line
  • cable-modem hookup over the Internet
  • radio- or satellite transmission etc.

Abstract

L'invention concerne un système de téléprésence partagé comprenant une pluralité d'ordinateurs séparés permettant à leurs utilisateurs respectifs d'interagir à l'intérieur d'un environnement virtuel commun. Cet environnement virtuel commun comprend un « monde » VRML constitué d'une pluralité d'objets partagés avec lesquels les avatars des participants peuvent interagir. Des participants individuels à une session de téléprésence communiquent entre eux par l'intermédiaire d'une connexion de réseau, tel qu'Internet. Un hôte de session sert à coordonner la commande distribuée de l'état de l'environnement virtuel partagé entre une pluralité de participants à une session de téléprésence. L'hôte de session peut résider sur un des participants à la session de téléprésence ou être exécuté par celui-ci. L'hôte de session reçoit des messages provenant de chaque participant, contenant des informations concernant des modifications de l'environnement et des objets partagés à mesure qu'elles sont apportées. L'hôte de session diffuse des messages aux participants. Lesdits messages contiennent des informations concernant les emplacements de réseau où sont stockées des informations mises à jour supplémentaires concernant l'état modifié de l'environnement. Des participants individuels récupèrent les informations d'état d'environnement mises à jour supplémentaires, directement à partir des emplacements de réseau désignés dans les messages diffusés par l'hôte de session. La commande distribuée de l'état de l'environnement virtuel est mise en oeuvre de sorte qu'un serveur central présentant une capacité computationnelle ou une largeur de bande extraordinaire ne soit pas nécessaire. Un service de listage sert à valider l'identité des utilisateurs et à fournir des informations d'adresses réseau aux utilisateurs, notamment à ceux qui disposent d'adresses réseau dynamiques. Dans un aspect de la présente invention, un ensemble d'extensions avec le langage de modélisation en réalité virtuelle (VRML) permettent de faciliter l'établissement de l'environnement virtuel partagé, dynamique, distribué et persistant. L'architecture selon l'invention permet la mise en oeuvre d'un environnement de commerce électronique basé sur des transactions.
PCT/US1999/027187 1998-12-29 1999-11-17 Architecture de reseau informatique pour environnements virtuels distribues persistants WO2005015880A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US22251798A 1998-12-29 1998-12-29
US09/222,517 1998-12-29
US43921299A 1999-11-12 1999-11-12
US09/439,212 1999-11-12

Publications (1)

Publication Number Publication Date
WO2005015880A1 true WO2005015880A1 (fr) 2005-02-17

Family

ID=34138211

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/027187 WO2005015880A1 (fr) 1998-12-29 1999-11-17 Architecture de reseau informatique pour environnements virtuels distribues persistants

Country Status (1)

Country Link
WO (1) WO2005015880A1 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006096629A1 (fr) * 2005-03-04 2006-09-14 Qualcomm Incorporated Procedes et appareils pouvant fournir un canal de commande dans un reseau de donnees
WO2009053014A2 (fr) * 2007-10-22 2009-04-30 Nortel Networks Limited Intégration d'un centre de contact dans des environnements virtuels
WO2009114937A1 (fr) * 2008-03-18 2009-09-24 Nortel Networks Limited Inclusion d'un contenu web dans un environnement virtuel
US7769806B2 (en) 2007-10-24 2010-08-03 Social Communications Company Automated real-time data stream switching in a shared virtual area communication environment
US7844724B2 (en) 2007-10-24 2010-11-30 Social Communications Company Automated real-time data stream switching in a shared virtual area communication environment
US8600731B2 (en) 2009-02-04 2013-12-03 Microsoft Corporation Universal translator
US8812358B2 (en) 2009-03-19 2014-08-19 Motorola Mobility Llc Method of providing a shared virtual lounge experience
US9210236B2 (en) 2001-01-12 2015-12-08 Parallel Networks, Llc Method and system for dynamic distributed data caching
US9483157B2 (en) 2007-10-24 2016-11-01 Sococo, Inc. Interfacing with a spatial virtual communication environment
US9853922B2 (en) 2012-02-24 2017-12-26 Sococo, Inc. Virtual area communications
WO2018085851A1 (fr) * 2016-11-07 2018-05-11 Constructive Labs Système et procédé pour faciliter le partage d'un espace tridimensionnel virtuel
WO2020154818A1 (fr) * 2019-01-31 2020-08-06 Treasured Inc. Système et procédé pour la mise à jour d'objets dans un environnement simulé
US20230015909A1 (en) * 2017-01-30 2023-01-19 Global Tel*Link Corporation System and method for personalized virtual reality experience in a controlled environment
US20230128648A1 (en) * 2021-10-27 2023-04-27 International Business Machines Corporation Real and virtual world management

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BROLL W: "BRINGING PEOPLE TOGETHER - AN INFRASTRUCTURE FOR SHARED VIRTUAL WORLDS ON THE INTERNET", PROCEEDINGS - THE WORKSHOP ON ENABLING TECHNOLOGIES: INFRASTRUCTURE FOR COLLABORATIVE ENTERPRISES,US,IEEE COMPUTER SOCIETY PRESS, LOS ALAMITOS, CA, June 1997 (1997-06-01), pages 199 - 204, XP000669964, ISSN: 1080-1383 *
DWYER D ET AL: "Creating a virtual classroom for interactive education on the Web", COMPUTER NETWORKS AND ISDN SYSTEMS,NL,NORTH HOLLAND PUBLISHING. AMSTERDAM, vol. 27, no. 6, 1 April 1995 (1995-04-01), pages 897 - 904, XP004013192, ISSN: 0169-7552 *
IYENGAR ET AL: "Distributed virtual malls on the World Wide Web", INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS,US,LOS ALAMITOS, CA: IEEE COMPUTER SOC, 26 May 1998 (1998-05-26), pages 58 - 65, XP002102567, ISBN: 0-7803-5004-9 *

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9602618B2 (en) 2001-01-12 2017-03-21 Parallel Networks, Llc Method and system for dynamic distributed data caching
US9210236B2 (en) 2001-01-12 2015-12-08 Parallel Networks, Llc Method and system for dynamic distributed data caching
JP2008532439A (ja) * 2005-03-04 2008-08-14 クゥアルコム・インコーポレイテッド データネットワークにおいて制御チャネルを提供する方法および装置
US7587752B2 (en) 2005-03-04 2009-09-08 Qualcomm Incorporated Methods and apparatus for providing a control channel in a data network
KR100942125B1 (ko) * 2005-03-04 2010-02-16 콸콤 인코포레이티드 데이터 네트워크에서 제어 채널을 제공하는 방법 및 장치
WO2006096629A1 (fr) * 2005-03-04 2006-09-14 Qualcomm Incorporated Procedes et appareils pouvant fournir un canal de commande dans un reseau de donnees
US8301474B2 (en) 2007-10-22 2012-10-30 Avaya Inc. Contact center integration into virtual environments
WO2009053014A2 (fr) * 2007-10-22 2009-04-30 Nortel Networks Limited Intégration d'un centre de contact dans des environnements virtuels
WO2009053014A3 (fr) * 2007-10-22 2009-08-27 Nortel Networks Limited Intégration d'un centre de contact dans des environnements virtuels
US20100306021A1 (en) * 2007-10-22 2010-12-02 O'connor Neil Contact center integration into virtual environments
US8621079B2 (en) 2007-10-24 2013-12-31 Social Communications Company Automated real-time data stream switching in a shared virtual area communication environment
US7844724B2 (en) 2007-10-24 2010-11-30 Social Communications Company Automated real-time data stream switching in a shared virtual area communication environment
US7769806B2 (en) 2007-10-24 2010-08-03 Social Communications Company Automated real-time data stream switching in a shared virtual area communication environment
US9483157B2 (en) 2007-10-24 2016-11-01 Sococo, Inc. Interfacing with a spatial virtual communication environment
US9762641B2 (en) 2007-10-24 2017-09-12 Sococo, Inc. Automated real-time data stream switching in a shared virtual area communication environment
US9258337B2 (en) 2008-03-18 2016-02-09 Avaya Inc. Inclusion of web content in a virtual environment
WO2009114937A1 (fr) * 2008-03-18 2009-09-24 Nortel Networks Limited Inclusion d'un contenu web dans un environnement virtuel
US8600731B2 (en) 2009-02-04 2013-12-03 Microsoft Corporation Universal translator
US8812358B2 (en) 2009-03-19 2014-08-19 Motorola Mobility Llc Method of providing a shared virtual lounge experience
US9853922B2 (en) 2012-02-24 2017-12-26 Sococo, Inc. Virtual area communications
WO2018085851A1 (fr) * 2016-11-07 2018-05-11 Constructive Labs Système et procédé pour faciliter le partage d'un espace tridimensionnel virtuel
US11290572B2 (en) 2016-11-07 2022-03-29 Constructive Labs System and method for facilitating sharing of virtual three-dimensional space
US20230015909A1 (en) * 2017-01-30 2023-01-19 Global Tel*Link Corporation System and method for personalized virtual reality experience in a controlled environment
US11882191B2 (en) * 2017-01-30 2024-01-23 Global Tel*Link Corporation System and method for personalized virtual reality experience in a controlled environment
WO2020154818A1 (fr) * 2019-01-31 2020-08-06 Treasured Inc. Système et procédé pour la mise à jour d'objets dans un environnement simulé
US20230128648A1 (en) * 2021-10-27 2023-04-27 International Business Machines Corporation Real and virtual world management
US11647080B1 (en) * 2021-10-27 2023-05-09 International Business Machines Corporation Real and virtual world management

Similar Documents

Publication Publication Date Title
Doyle et al. The potential of web-based mapping and virtual reality technologies for modelling urban environments
US8539085B2 (en) Networked computer system for communicating and operating in a virtual reality environment
EP0753836B1 (fr) Méthode et système de partage d'un espace à trois dimensions à réalité virtuelle
US6708172B1 (en) Community-based shared multiple browser environment
US20060184886A1 (en) Spatial chat in a multiple browser environment
WO2002031683A1 (fr) Systeme et procede de configuration et d'obtention d'un environnement informatique tridimensionnel mis en service sur des reseaux
WO2005015880A1 (fr) Architecture de reseau informatique pour environnements virtuels distribues persistants
EP2255492A1 (fr) Inclusion d'un contenu web dans un environnement virtuel
JPH1040295A (ja) 通信装置
Shen et al. vCOM: Electronic commerce in a collaborative virtual world
US20030128205A1 (en) User interface for a three-dimensional browser with simultaneous two-dimensional display
GB2622261A (en) System and method for providing a relational terrain for social worlds
Smith et al. Visual communication in urban planning and urban design
Shen et al. A heterogeneous scalable architecture for collaborative haptics environments
Berger et al. Playing the e-business game in 3D virtual worlds
Matsuda et al. Virtual society: Multi-user interactive shared space on WWW
Khoury et al. A peer-to-peer collaborative virtual environment for E-commerce
Fukuda et al. Networked VR system: Kitchen layout design for customers
Bogdanovych et al. 3D electronic institutions: Social interfaces for e-commerce
Khoury et al. Accessibility and scalability in collaborative e-commerce environments
WO2001046840A2 (fr) Environnement d'exploration multiple partage communautaire
Hudson-Smith et al. Visual communication in urban planning and urban design
KR20010112736A (ko) 가상 현실 공간을 통한 웹브라우징 시스템 및 방법과 그프로그램 소스를 기록한 기록 매체
Agbaje et al. The Challenges of Migration from 2D to 3D Internet (3DI)
Nakai et al. Sclable Collaborative Virtual Environment Considering User's Interests Based on P2P Overlay Network

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA IN JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: JP

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase