SYSTEM AND METHOD FOR PROVIDING SECURE PORTALS BETWEEN VIRTUAL WORLDS - Patent application

Abstract

Systems and methods are provided for a secure portal between virtual worlds. In some embodiments, the systems and methods include deploying a secure portal between two virtual worlds. This is performed by rendering a top cell of a first virtual world. The rendering includes a transparent area that overlaps with the portal. A middle cell is then stacked below the top cell. The middle cell includes the portal. A message is received from the top cell. The message includes a minimum rendering size, a shape, and at least one transformation. The message is forwarded to a bottom cell for a second virtual world, which renders the bottom cell (in part) in response to the message. The top cell, the middle cell, and the bottom cell are then stacked to generate a scene. In some embodiments, the rendered portion of the bottom cell fits the minimum rendering size, and the middle cell is transparent. In some cases, the cell is either an iFrame or a separate application.

Description

[Technical field]

[0001] The present invention relates to a system and method for secure portals between virtual worlds, which allows virtual spaces from different sandboxes, and even different applications, to have connectivity to each other in a secure manner. [Background technology]

[0002] Portals are known entities in the metaverse space. Traditionally, portals join two virtual spaces together and even allow interaction through the portal. These portals function similarly to URL links in a web page, except they are dynamically loaded and active. Thus, users can visualize in / through the portal before interacting with it.

[0003] If the portal is between two spaces within the same world / application, the process of deploying a portal can be trivial, however, when trying to fully connect different sandboxes, or even more rigidly different applications, the task of deploying a portal becomes more complex.

[0004] A key complication to the deployment of these portals is that traditionally, portals are deployed to each virtual world in the same code space as the world itself. This poses a significant security risk to the virtual world as portals may contain malicious code. Therefore, portal deployment is highly risky or heavily restricted to selecting whitelisted known worlds.

[0005] In addition to security issues, it is equally difficult to like two different "kinds" of space. This generally requires that each world loads the other world's portal linking code. If the two worlds have a shared environment, this may not be a problem. However, most worlds do not have the same model of rendering and interaction, thus making portals between these worlds a non-trivial task. It requires simultaneously browsing and interacting with a variety of applications that have very different rendering techniques and underlying system code. This is sometimes simply not possible, and even if it is possible, it can be very resource-intensive to complete.

[0006] Regardless of obstacles, the metaverse is an evolving and dynamic space. As time progresses, the metaverse becomes more and more ingrained in our daily lives. The need and desire for portals between different virtual spaces will only increase.

[0007] It is therefore clear that there is an urgent need for a new architecture that allows secure portals between different virtual spaces. Such a system and method would allow users to seamlessly move between different virtual spaces without introducing the security loopholes introduced in the interconnected world. Summary of the Invention

[0008] To achieve the above, in accordance with the present invention, a system and method are provided for a secure portal between virtual worlds that allows a means for a user to travel between two different virtual spaces without introducing security loopholes into the worlds that are coupled together.

[0009] In some embodiments, the system and method includes deploying a secure portal between two virtual worlds. This is performed by rendering a top cell of a first virtual world. The rendering includes a transparent area that overlaps with the portal. A middle cell is then stacked below the top cell. The middle cell includes the portal. A message is received from the top cell. The message includes a minimum rendering size, a shape, and at least one transformation. The message is forwarded to a bottom cell for a second virtual world, which renders the bottom cell (partially) in response to the message. The top cell, middle cell, and bottom cell are then stacked to generate a scene. In some embodiments, the rendered portion of the bottom cell fits the minimum rendering size, and the middle cell is transparent. In some cases, the cell is either an iFrame or a separate application.

[0010] The user can "exist" in the upper layer world. The user can interact with the portal, including traveling through it to the lower layer world. When this happens, the order of cells is reversed and the second world (where the user is currently located) becomes the upper cell layer. The transformation used is based on the user's line of sight relative to the portal.

[0011] It should be noted that the various features of the invention described above may be implemented alone or in combination. These and other features of the invention are described in more detail below in the detailed description of the invention, taken in conjunction with the following drawings.

[0012] In order that the invention may be more clearly ascertained, some embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 illustrates an exemplary logical diagram of a system for multiple virtual environments between which portals are utilized to transport users, according to some embodiments. [Diagram 2]FIG. 2 illustrates an exemplary logical diagram of two virtual worlds joined by a portal, according to some embodiments. [Diagram 3] 1 is an example depiction of isolated cells that enable portal travel between different virtual spaces from an oblique viewing angle, according to some embodiments. [Figure 4] 1 is an exemplary depiction of a rendering of a limited portion of the underworld in an isolated cell from an oblique viewing angle, according to some embodiments. [Diagram 5] 1 is an exemplary depiction of a folded top cell and portal cell from an oblique viewing angle according to some embodiments. [Figure 6] 11 is an exemplary depiction of a rendering that a user sees when looking directly at a portal, according to some embodiments. [Figure 7] 1 is an exemplary depiction of a front view rendering of a portal with the underlying cells offset for illustrative purposes, according to some embodiments. [Figure 8] 1 is an exemplary depiction of a front view rendering of a portal without the underlying cells for illustrative purposes, according to some embodiments. [Figure 9] 1 is an exemplary depiction of a front view rendering of a portal without the top cell for illustrative purposes, in accordance with some embodiments. [Figure 10A] 1 is an exemplary depiction of underlying cell sizing and transformation for illustrative purposes, according to some embodiments. [Figure 10B] 1 is an exemplary depiction of underlying cell sizing and transformation for illustrative purposes, according to some embodiments. [Figure 10C] 1 is an exemplary depiction of underlying cell sizing and transformation for illustrative purposes, according to some embodiments. [Figure 11A] 1 is an exemplary depiction of a user's view of a rendering of a portal with underlying cells sized and transformed for illustrative purposes, according to some embodiments. [Figure 11B]1 is an exemplary depiction of a user's view of a rendering of a portal with underlying cells sized and transformed for illustrative purposes, according to some embodiments. [Figure 11C] 1 is an exemplary depiction of a user's view of a rendering of a portal with underlying cells sized and transformed for illustrative purposes, according to some embodiments. [Figure 12] 1 is an exemplary depiction of a perspective view of multiple cells relative to multiple portals, according to some embodiments. [Figure 13] 1 is an exemplary depiction of a user's view of multiple cells relative to multiple portals, according to some embodiments. [Figure 14] FIG. 1 illustrates a flow diagram of an example process for deploying a secure portal between two virtual spaces, according to some embodiments. [Figure 15] FIG. 1 is a flow diagram of underlying cell sizing and conversion according to some embodiments. [Figure 16] FIG. 4 is a flow diagram of an exemplary process of user interaction with a portal, according to some embodiments. [Figure 17A] 1 is an exemplary depiction of a computer system in which the present invention may be implemented. [Figure 17B] 1 is an exemplary depiction of a computer system in which the present invention may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] The present invention will now be described in detail with reference to several embodiments of the invention as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. However, it will be apparent to one skilled in the art that the embodiments may be practiced without some or all of these specific details. In other instances, well-known process steps and / or structures have not been described in detail in order not to unnecessarily obscure the invention. The features and advantages of the embodiments may be better understood with reference to the drawings and the following description.

[0015] Aspects, features, and advantages of exemplary embodiments of the present invention will be better understood with respect to the following description in conjunction with the accompanying drawing(s). It will be apparent to those skilled in the art that the described embodiments of the present invention provided herein are merely illustrative and not limiting, and are presented by way of example only. All features disclosed herein may be replaced by alternative features serving the same or similar purpose, unless specifically stated otherwise. Accordingly, many other embodiments of the modifications thereof are considered to be within the scope of the present invention as defined herein and its equivalents. Thus, for example, the use of absolute and / or sequential terms such as "will," "will not," "shall," "shall not," "must," "must not," "first," "initially," "next," "subsequently," "before," "after," "lastly," and "finally" is not meant to limit the scope of the present invention, as the embodiments disclosed herein are merely illustrative.

[0016] The following systems and methods are for portals between virtual environments. These portals can connect different sandbox worlds, or even different application worlds together. This allows users to seamlessly "teleport" between different virtual environments while avoiding the major work required to connect worlds with different rendering mechanisms and different system code. Similarly, the present systems and methods greatly reduce the security risks of placing portals between virtual worlds.

[0017] It should be noted that throughout this disclosure, a particular nomenclature is adopted agnostic. This is not intended to limit the scope of the inventions described herein. For example, an individual operating in a virtual environment may be referred to as a "user," a "player," or an "individual." These terms are intended to be synonymous. Similarly, "virtual environment," "virtual world," or simply "world" are intended to be synonymous. An "application" is the equivalent of a "program" or a "computer program." A "computer" may also be referred to as a "device" or a "machine." And so forth.

[0018] The portal architecture is also platform independent and can be shared across any device. This ultra-portability allows sharing with virtually any other person, regardless of the device they are using or the platform deployed on the device.

[0019] For ease of explanation, Figure 1 provides a depiction of a system, generally seen at 100, in which this portal technology may be deployed. In this exemplary environment, there are multiple virtual worlds 110a-n. Each of these virtual worlds may comprise a server (or a bank of servers) that hosts the world, or may comprise a distributed virtual environment. In some cases, the virtual worlds 110a-n are different sandboxes of a single application, while in other embodiments, some or all of the virtual worlds 110a-n are different applications.

[0020] Multiple users 120a-m can "present" (or simply visualize) as avatars within these virtual environments 110a-n. Users can access the various virtual worlds through a network connection 150. In some embodiments, the network 150 can include a local area network (LAN), a wide area network, a wireless network, a cellular network, the Internet, or any combination of the above.

[0021] In addition to providing access to the virtual worlds 110a-n for users 120a-m, the network may rely on coupling the various virtual environments 110a-n together through portals. These portals are hosted by one or more portal sandboxes 130.

[0022] In Figure 2, a block diagram 200 is provided for connecting a first virtual environment 110a to a second virtual environment 110b via a portal 210. This allows a user 120 in one virtual environment to "travel" or "teleport" and see the other virtual world. This is accomplished by a "portal" between the two different virtual environments.

[0023] The concept of portals between worlds is not new. However, as mentioned above, a key complication to traditional portal deployments is that the portals are deployed to each virtual world in the same code space as the world itself. This poses a significant security risk to the virtual worlds, as portals may contain malicious code. Furthermore, it is very difficult to favor two different "kinds" of space. This generally requires each world to load the linking code of the other world's portal. This may not be as big an issue if the two worlds have a shared environment. However, most worlds do not have the same model of rendering and interaction, thus making portals between these worlds a non-trivial task. It requires simultaneously browsing and engaging with various applications that have very different rendering techniques and underlying system code. This is simply not possible in some cases, and even if it is possible, it can be very resource-intensive to complete.

[0024] The portal technology of the present disclosure avoids these problems by using what are known as "cell-based" portals. Cell-based portals provide a novel means for viewing and interacting with portals while minimizing security risks. This technology also allows for the mixing of different virtual worlds and even different 3D applications.

[0025] To improve security, the portals themselves run entirely within a separate sandbox environment or as separate applications. This is a major departure from traditional portal technology, where the portal is embedded in the underlying virtual environment. Thus, malicious code, if introduced, remains isolated from the two virtual environments that the portal "connects". Note further that these portals may also allow users to see through them in traditional web pages. These web pages may be transformed in much the same way as the virtual world's view, or may be distorted using CSS3 (Cascading Style Sheets). Thus, while the bulk of this disclosure focuses on the connection of two virtual worlds, it should be understood that this should be read synonymously with connecting a virtual world to a web page.

[0026] The underlying world is implemented as a native application in some embodiments. In alternative embodiments, the underlying connected virtual environment is implemented as a web-based iFrame. Depending on the operating system's allowance, it may be possible to combine the use of iFrames with native applications. However, for clarity in this disclosure, the focus is on the iFrame demonstration of a cell-based portal approach. This is not intended to limit the scope of the disclosure, but is merely for clarity.

[0027] "Cells" as defined herein are different transparent layers that can be stacked on top of each other to create a stack. Within each cell there are typically transparent parts and rendered elements. When stacked together they create a complete image. In this discussion of porting, each cell may be a rendering of an iFrame and / or a native application.

[0028] Essentially, the cell-based approach to portals utilizes a layered image model, where each world is rendered in a separate cell (e.g. a web-based iFrame), leaving certain areas transparent so that the user can see the cell "behind" or "below." The top cell is the world the user is currently in, and is rendered in all areas except the area that is the portal - this area is left transparent - with the layers below being the other worlds that the portal connects to. The portals themselves are a separate middle cell layer. Portals are rendered to be transparent.

[0029] In the case of an iFrame, the top iFrame cell (the world the user is currently in) sends a message to the intermediate portal iFrame cell below it. The message specifies the minimum rectangular shape (or other constructed shape) that needs to be rendered for the instant portal, as well as the transformation required for the underlying rendering. The "bottom" iFrame cell (the "other" world the portal is connected to) then responds with the transformation, rendering the scene into a rectangle (or other desired shape). The portal itself is the only part of the intermediate layer that is transparent, so the user sees a complete portal image in the rendered world. Generally, the transformation applied involves a 4x4 matrix transformation.

[0030] By limiting the rendering to a minimum rectangle / size and requiring transformation of the image, it is not necessary to render the entire world view. Additionally, a world can have many different portals, each pointing to the same world or to another world. By limiting the size and shape of the worlds rendered "below" the top layer world (the world the user is currently located in), there are two main advantages. The first and most important advantage is that it limits the possibility of interrupting the view when there are many portals, or portals seen within portals. When these situations exist, there are many different cells stacked on top of each other. If the rendering of the content in a layer is not "tight" relative to the portal size, it may be seen through a different portal, thus "blocking out" the image that should be visible in the subsequent layer(s). Secondly, by rendering only a portion of the underlying world, it greatly reduces the computational demand. Note that it is most efficient and not necessary to render a minimum sized rectangle (or other specified shape such as an ellipse or polygon that "fits" the portal shape) specified by the top cell. Alternatively, a larger size rendering could be generated, but this is unnecessary, requires additional computational resources, and as stated, may overlap with other portals, causing incorrect content to be seen by other portals.

[0031] Having the rendered cell areas fit closely is especially important when using Augmented Reality (AR) as opposed to Virtual Reality (VR) environments. In AR, the area around the object is transparent, allowing the user to see the real world around the object. Portals in AR require the underlying cells to fit the portal shape very closely or risk blocking the AR vision. This is because in VR, the top layer renders around the portal. If the bottom layer "peaks out" around the portal space, it will be covered by the top layer's rendering. In AR, there is no such luxury feeling because the top layer is already transparent around the portal area (to allow the real world to be seen).

[0032] Although there are many reasons why it may be preferable to have the shape and size communicated to the underlying layer(s) fit the size and shape of the portal very precisely, in some embodiments, using a general shape (such as a rectangle) is easily implemented and easier to render. Furthermore, if a rectangle fits the portal shape reasonably well, the risk of overlapping another portal is relatively minimal, since the other portal would need to be very close to the first portal. However, still, ideally the shape and size of the portal would be communicated more precisely, allowing for a very tight-fitting rendering of the underlying cell layer.

[0033] The advantages of this cell-based approach are significant: since the layers do not need to communicate with each other (other than the minimum size and transformations required), security is greatly improved (since the portal does not need to interface with either world's system code). In fact, without complex screen capture functionality, there is no way for one application to view or access data from the other application (including rendered images). This minimization of shared information further increases the security of such a system. Furthermore, since code from one environment does not need to interact with the system code / rendering technology of the other virtual environment, two completely different worlds / applications can be combined without significant effort to make their rendering compatible.

[0034] To more clearly explain the concepts behind this cell-based approach, a series of depictions are provided to more clearly explain the theory and application of cells to generate portals between spaces. For example, in FIG. 3, one exemplary depiction 300 of various cells in play in a temporary embodiment is shown. These first few depictions (FIGS. 3-5) are perspective views of the cell layers, with the perspective placed to show how the cells are stacked on top of each other. This is a front view of the cell layer rendering, not the view that a user of the system would experience. However, these first few views are provided to clarify the method of cell stacking. The later figures provide more representative views of the rendered cells and should be recognized as the view that would be experienced by the user.

[0035] The "top" cell 310 is a rendering of the world the user is currently in. Although shown as a monolithic layer, this cell includes transparent portions where portals reside, and (as will be seen in later figures) can contain any number of rendered objects (including the 3D environment).

[0036] "Below" the top cell is the portal cell layer 320. As mentioned, the portal layer is a separate sandbox or even a separate application compared to the other cells. Portal cells contain transparent parts within the portal area (and are generally fully transparent). The top layer is not transparent around the portal, so the rest of the portal cell may or may not be transparent. Either way, the top cell layer is rendering the scene around the portal itself.

[0037] Below the portal cell layer is a layer 330 for the "other" world that is viewed and potentially interacted with. Again, a monolithic image is displayed, but this layer can similarly contain shapes, objects, and other users. However, rather than rendering the entire lower layer (with its attendant computational costs and risk of occluding other portals in the upper layer), it is more efficient for the upper cell layer (the world the user is currently in) to provide the minimum shape (rectangular in this example, but other shapes are possible based on the portal shape) and size, as well as any necessary transformations for the image.

[0038] FIG. 4 provides an exemplary depiction 400 of the result of the upper cell layer 310 communicating this sizing and conversion information to the portal cell layer 320. The lower layer then renders a cell containing a rectangle of the correct size and applies the appropriate transformation, thereby resulting in a small rendering within the transparent cell 430. Again, the rendered size does not need to be as small as the minimum size conveyed by the upper cell layer 310, but it is prudent for it to match or at least slightly exceed the specified minimum size in the calculations. Similarly, rendering the lower layer to a tight fit to the portal dimensions ensures that potential other portals in the upper layer are not inadvertently covered by the rendering of an inappropriate layer. Multiple portals and rendering are covered in more detail in connection with Figures 12 and 13 below. Rendering a rectangle (or other specified shape) below the minimum size will result in a "gap" around the rendered image when viewed through the portal. This is disruptive and undesirable from a user perspective.

[0039] 5 provides an exemplary depiction 500 of a partially folded layer, where the top cell layer 310 has been merged with the portal cell layer 320, resulting in a transparent portion in which the portal is located. The bottom cell 430 is still shown as separate and apart from the combined top and portal cell. This is for illustration and clarity purposes only, because once merged as a stack of cell layers, it becomes conceptually difficult to distinguish between them. The resulting display as seen by a user of the system can be seen in the exemplary depiction 600 of FIG.

[0040] In this exemplary depiction 600, the view is from directly in front of the portal (as opposed to the previous three views, which were perspective views to help distinguish the cells of the various layers). Here, however, the cells have been merged and what is seen is the top cell 310, which provides the majority of the rendering. In this depiction, the top cell is shown with a horizontal line and a pair of shapes for illustration purposes. In this temporary demonstration, only the area of ​​the portal 320 is transparent. The user is located in a world that is rendered in this top cell layer.

[0041] Below this layer is the Portal Layer 320. Again, the Portal Layer is transparent in the portal area (and generally the entire cell) so that the user can see the Cell Layer 430 below it. The purpose of the Portal Layer 320 is to provide separation between the two worlds, and to transfer sizing and transformation information from the upper cells to the lower cells.

[0042] The bottom layer 430 receives the sizing and transformation messages, creates a rectangle that is (in this example) at least as large as the minimum size (and preferably no larger), and applies the necessary transformations to ensure that the rendered image looks "right" to the user.

[0043] To better illustrate the arrangement of the cells, Figure 7 provides a representation 700 of the same view of the portal from its front on, but in this exemplary representation, the lower cells 430 are offset to show that it is rendered only relative to the size of the portal 320 itself. Under any normal operation, this view with the lower cells 430 offset would not occur as it would detract from the user's visual experience. However, a temporary representation 700 is provided to understand the arrangement and transparency of the portal layer 320.

[0044] Similarly, Figure 8 provides a representation 800 of an upper cell 310 and a portal cell 320 where there is no lower cell. The upper cell 310 renders the user's entire field of view except where the portal 320 is located. This portion of the cell is transparent. Similarly, the portal cell 320 is similarly transparent, at least in this area. Since there is no lower cell in this exemplary representation 800, nothing is rendered in the portal area of ​​this figure.

[0045] Conversely, Figure 9 provides a depiction 900 of the rendered bottom cell 430 and portal cell 320. The area around the portal is not rendered (is transparent) by any of these cell layers. Since the top cell layer is missing, nothing is rendered except for the portal area. Therefore, all layers must be present to generate a complete rendering of the field of view from the user's perspective (as seen in Figure 6).

[0046] Figure 10A provides a representation 1000A of the bottom layer 430 as viewed from directly on. For illustrative purposes, the rendering contains a set of objects. As the user moves to the side of the portal, the viewing area shifts as the portal's viewing angle changes. This results in different sized rectangles being needed to fill the portal space, distorting and changing what is seen "through" the portal. This causes the top layer (the world the user is in) to provide the bottom layer with new sizing requirements and necessary transformations for the underlying image.

[0047] A messenger API is leveraged to communicate sizing and transformation information from one cell to another. There are three types of messages: 1) sent from application to container, 2) sent from container to application, and 3) sent from container to all applications. An application cannot directly send a message to another application, which increases the security of each virtual world. The messenger API is accessible through the global object.

[0048] In some embodiments, there are two typical communication protocols. The first protocol is where a party sends a request to another party and processes the response when it arrives. For example, a newly launched application sends a request to a messaging platform to inquire about user information, and the platform responds with information. The other kind of protocol is where a party spontaneously sends a message. An example of this protocol is when an application sends the position of the pointing device to the platform when the user moves the position of the pointing device within the application (thus generating a pointer movement event). The API has a convenient way to set up a pointer movement publishing mechanism and handle detach events so that the event handler is removed. Thus, an application can simply call a simple request to let the container know where the pointer is. The platform uses an icon definition, the name of the application, and possibly a readable session name. When the application launches, the application creates a URL from the template and sends a message to the platform informing it that the application is open and ready to receive messages. The application can also send requests to the platform. The platform sends a request to inquire about the application information, and the platform can send a response to the request. The application responds to the information request. Finally, the platform sets up a frame with that information.

[0049] FIG. 10B provides an example depiction 1000B of the renderings that are generated when these sizing and transformation messages are received. Here, the user has moved about 20 degrees to the right of the portal and is looking at it from an angle. The portal width appears narrower due to the squint. The resulting size minimum is therefore a larger height (closer side of the portal) and a reduced width. Again, this assumes that the size and shape of the portal is rectangular rather than being "fitted" to the shape of the portal. Fitting to the portal shape may be superior from a rendering perspective (as it reduces the chance that the rendering will be mistakenly viewed through another portal), but is a more complicated task than rendering a rectangular shaped underlying image. The received transformations are utilized to modify the image quality by tilting, shrinking, or changing the viewing angle of the scene in the bottom cell.

[0050] Similarly, Figure 10C provides a representation 1000C of the rendering when the viewer / user moves further to the right of the portal (approximately a 45 degree angle to the portal). This representation is intended to show how the view and shape change based on the portal viewing angle.

[0051] 11A, a representation 1100A of the portal viewed from directly in front is provided. As can be seen, the top layer is rendered from the user's perspective, and the bottom layer rendering is layered directly underneath the transparent portal area, as seen in FIG. 10A. Comparing this to FIG. 11B and FIG. 11C, which show representations 1100B and 1100C, respectively, after the user has moved to the right of the portal. When viewed from an angle, the newly rendered bottom cell behind the portal cell 320 and top cell 310 is (almost) fitted to the shape and size of the transparent portal. As can be seen, the previously rendered rectangles in FIG. 10B and FIG. 10C, respectively, are now layered behind the other cells. The top and bottom of the cell rendering are partially obscured by the top cell 310 (because the shape used is a rectangle rather than a more precise shape that matches the transparent portion of the portal), resulting in a full view of the rest of the world through the portal.

[0052] Referring now to Figure 12, an oblique depiction 1200 of a set of cell layers when multiple portals are present is shown. Again, this perspective is not what a user would see. Instead, it is intended to provide perspective and clarity around the different layers from a conceptual standpoint. Figure 13 below provides a depiction of what a user of the system would actually see.

[0053] In this Figure 12, the top layer 1210 (the world the user is in) is rendered everywhere except where the portals are. In this depiction, two portals can be seen, one rectangular and one oval. Below the top layer is the portal cell layer 1220, which receives sizing and shape information from the top layer and conveys this to the next lower world. Next is the first "other" world layer 1230, to which the rectangular portal connects. As can be seen, this layer is transparent except for the area where the rectangular portal is. This exact area is rendered relative to this layer 1230.

[0054] Then there is yet another layer 1240 associated with a third world. This world is connected to the first world layer 1210 by an elliptical portal. In this lower layer 1240, the area above the elliptical portal is rendered, and the remaining area around this rendered portion is transparent. In other embodiments (not shown), there may be many additional portals (even portals within portals). These result in yet other layers below the layer shown here. However, what is important to note is that the underlying layer 1240 is visible through the transparent portal in the upper layer 1210, because the layer 1230 is transparent everywhere except in the areas where its portals are.

[0055] When viewed by a user from within the virtual world, the result of this many layered system is presented as a seamless view, as seen in FIG. 13 1300. The world in which the user is located (top layer 1210) renders most of the viewing area. The areas of the portals are transparent, allowing the user to see into the layers below. Through the rectangular portal, the user sees into the first lower world layer 1230. Through the second elliptical portal, the user sees through layer 1230 (as it is transparent in this area) and sees the rendered portion of the next layer 1240. As mentioned above, this can be done multiple times for as many layers as needed, based on the number and location of portals.

[0056] Having disclosed the general concepts of cell rendering and layering to enable secure portals between different worlds (which may include different applications), we now turn our attention to the process flows involved in deploying and interacting with these portals.

[0057] 14 provides a flow diagram 1400 of an example process flow for the deployment and interaction of portals between different virtual worlds. Initially, each world is rendered (at 1410) as a separate cell. The top cell is rendered to include a transparent portion in which the portal resides. The portal cell is similarly rendered (at 1420) as a transparent cell. This portal cell is located between two world cells. The top cell (e.g., the world in which the user's avatar resides) sends a message (at 1430) to the portal cell below it.

[0058] FIG. 15 provides further details regarding the messages provided from the upper world to the cells below. In this sub-process, the upper cell specifies (at 1510) a minimum rendering size that will overlap the portal. This minimum size may be exactly the same size as the portal, or it may be larger than the portal. Being larger than the portal has no adverse effect, as the non-transparent upper cell will hide any underlying cell rendering, unless another portal is close to the first portal (leading to the transparent portion being too close to the first portal). Furthermore, a specified size that is too large may result in more of the underlying world being rendered, as strictly necessary. This takes computational resources, and therefore, for both of these reasons, it may be desirable to avoid specifying a minimum size that is too large for the portal itself, but rather to have the size fit tightly into the transparent portal area. In addition to specifying a minimum rendering size, the upper cell may relay (at 1520) one or more specific transforms to the cells below it. These transforms may provide instructions regarding angle, tilt, zoom, etc. These transformations may be based on the "location" where the user's avatar is located / the user's viewing angle. These transformations modify the rendering of the underlying world to fit the direction and distance at which the underlying world is being viewed.

[0059] Returning now to Figure 14, the bottom cell uses the information in the message to render (at 1440) a rectangle (or other shape based on the portal shape) that meets the minimum size requirements described in the message and is subject to the transformation(s) provided in the message. The cells are all layered so that the user sees the scene as a fully rendered, continuous image. Finally, the user can interact with the portal itself to travel between worlds (at 1450).

[0060] 16 provides in more detail the process of user interaction with a portal. For a user to interact with a portal, the user (at 1610) should "click" or select the portal with an input device (e.g., mouse, VR controller, hands, etc.) or otherwise "walk" through the portal. "Walking" may involve actually physically passing through a space in which the portal is mirrored in the virtual environment, or otherwise controlling the user / user's avatar to move through the portal space.

[0061] When the user "moves" through a portal, the cell order is reversed (at 1620). This reversal means that the bottom cell, which represents the "other" virtual environment, or the cell that the portal renders, becomes the top cell, rendering all visible area except the area where the portal is located (made transparent). Conversely, the old top cell is moved to the bottom, rendering only the portion pointed to by the new top cell. Again, this rendering is subject to the minimum size and transformation requirements of the new top cell (at 1630). Thus, all cells are re-rendered (at 1640) to again provide a seamless viewing experience to the user.

[0062] Having described a system and method for secure portal deployment and interaction between virtual worlds, attention is now directed to a system capable of performing the above functions. To facilitate this description, Figures 17A and 17B illustrate a computer system 1700 suitable for implementing embodiments of the present invention. Figure 17A illustrates one possible physical form of the computer system 1700. Of course, the computer system 1700 can have many physical forms, ranging from printed circuit boards, integrated circuits, and small handheld devices to huge supercomputers. The computer system 1700 can include a monitor 1702, a display 1704, a housing 1706, a server blade including one or more storage drives 1708, a keyboard 1710, and a mouse 1712. The medium 1714 is a computer-readable medium used to transfer data to and from the computer system 1700.

[0063] FIG. 17B is an example of a block diagram of a computer system 1700. Attached to a system bus 1720 are a variety of different subsystems. Processor(s) 1722 (also referred to as a central processing unit or CPU) are coupled to storage devices including memory 1724. Memory 1724 includes random access memory (RAM) and read-only memory (ROM). As is well known in the art, ROM functions to transfer data and instructions unidirectionally to the CPU, while RAM is typically used to transfer data and instructions bidirectionally. Both of these types of memory may include any suitable form of computer readable media, as described below. Fixed media 1726 may also be bidirectionally coupled to the processor 1722. It provides additional data storage capacity and may also include any of the computer readable media, as described below. Fixed media 1726 may be used to store programs, data, and the like, and is typically a secondary storage medium (such as a hard disk) that is slower than the primary storage. It will be appreciated that the information retained within fixed medium 1726 may, in appropriate cases, be embodied in standard fashion as virtual memory within memory 1724. Removable medium 1714 may take the form of any of the computer readable media described below.

[0064] The processor 1722 is also coupled to various input / output devices, such as a display 1704, a keyboard 1710, a mouse 1712, and a speaker 1730. In general, the input / output devices may be any of a video display, a trackball, a mouse, a keyboard, a microphone, a touch-sensitive display, a transducer card reader, a magnetic or paper tape reader, a tablet, a stylus, a voice or handwriting recognition device, a biometric reader, a motion sensor, an electroencephalogram reader, or another computer. The processor 1722 may optionally be coupled to another computer or a telecommunications network using a network interface 1740. With such a network interface 1740, the processor 1722 may receive information from the network or output information to the network in the course of performing the portal deployment described above. Furthermore, embodiments of the method of the present invention may be executed solely on the processor 1722 or may be executed over a network, such as the Internet, with a remote CPU sharing a portion of the processing.

[0065] Software is typically stored in non-volatile memory and / or drive units. In fact, for large programs, it may not even be possible to store the entire program in memory. Nevertheless, it should be understood that in order to execute the software, it is moved, as necessary, to a computer-readable location suitable for processing, and for illustrative purposes, that location is referred to as memory in this disclosure. Even when the software is moved to memory for execution, the processor may typically utilize hardware registers to store values ​​associated with the software, and a local cache, which ideally serves to speed execution. As used herein, a software program is assumed to be stored in any known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as being "embodied in a computer-readable medium." A processor is considered to be "configured to execute a program" when at least one value associated with the program is stored in a register readable by the processor.

[0066] In operation, computer system 1700 may be controlled by operating system software, including a file management system, such as a media operating system. One example of operating system software with its associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Washington, and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux® operating system and its associated file management system. The file management system is typically stored in non-volatile memory and / or drive units, and causes the processor to perform various operations required by the operating system to store data in memory, including inputting and outputting data and storing files in the non-volatile memory and / or drive units.

[0067] Some portions of the detailed descriptions may be presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, primarily for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0068] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the methods of some embodiments. The required structure for a variety of these systems may appear from the description below. In addition, the techniques are not described with reference to any particular programming language, and thus various embodiments may be implemented using a variety of programming languages.

[0069] In alternative embodiments, the machine operates as a stand-alone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

[0070] The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a laptop computer, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, an iPhone, a Blackberry, glasses with a processor, headphones with a processor, a virtual reality device, a processor, cooperating distributed processors, a telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify operations to be performed by the machine.

[0071] Although the machine-readable medium or machine-readable storage medium is shown in the exemplary embodiment to be a single medium, the terms "machine-readable medium" and "machine-readable storage medium" should be interpreted to include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) that store one or more sets of instructions. The terms "machine-readable medium" and "machine-readable storage medium" should also be interpreted to include any medium that can store, encode, or carry a set of instructions for execution by a machine and cause a machine to perform any one or more of the methods of the presently disclosed techniques and innovations.

[0072] Generally, the routines executed to implement embodiments of the present disclosure may be implemented as part of an operating system or a specific application, component, program, object, module, or sequence of instructions referred to as a "computer program." A computer program typically includes one or more instructions that are configured at various times in various memory and storage devices within a computer (or distributed throughout the computer) and that, when read and executed by one or more processing units or processors within the computer (or throughout the computer), cause the computer(s) to perform operations that implement elements that include various aspects of the present disclosure.

[0073] Moreover, while the embodiments are described in the context of fully functional computers and computer systems, those skilled in the art will appreciate that various embodiments can be distributed as program products in a variety of forms, and that the present disclosure applies equally regardless of the particular type of machine or computer-readable medium used to actually accomplish the distribution.

[0074] Although the present invention has been described with respect to several embodiments, there are alterations, modifications, substitutions, and alternative equivalents that fall within the scope of the present invention. Subsection headings are provided to aid in the description of the present invention, but these headings are merely exemplary and are not intended to limit the scope of the present invention. It should also be noted that there are many alternative ways of implementing the methods and apparatus of the present invention. It is therefore intended that the following appended claims be construed to include all such alterations, modifications, substitutions, and alternative equivalents that fall within the true spirit and scope of the present invention.

Claims

1. 1. A method for deploying a secure portal between two virtual worlds, comprising: rendering a top cell for a first virtual world, the rendering including a transparent area overlapping a portal; stacking a middle cell below the top cell, the middle cell including the portal; receiving a message from the top cell including a minimum rendering size, a shape, and at least one transformation; forwarding the message to a lower cell for a second virtual world; and rendering a portion of the second world in response to the message; and stacking the top cell, the middle cell, and the bottom cell to generate a scene.

2. The method of claim 1 , wherein the portion of the second world is the same size as the minimum rendering size.

3. The method of claim 1 , wherein the intermediate cell is transparent.

4. The method of claim 1 , wherein the cell is an iFrame.

5. The method of claim 1 , wherein the cells are separate applications.

6. The method of claim 1 , wherein the first virtual world is a user's location.

7. The method of claim 6 , further comprising the user interacting with the portal.

8. The method of claim 7 , wherein the interaction is one of selecting the portal or passing through the portal.

9. The method of claim 1 , further comprising: reordering the upper and lower cells in response to the interaction.

10. The method of claim 1 , wherein the at least one transformation is generated based on a user's field of view.

11. When executed by a computer system, rendering a top cell for a first virtual world, said rendering including a transparent area overlapping a portal; stacking a middle cell below the top cell, the middle cell including the portal; receiving a message from the top cell including a minimum rendering size, a shape, and at least one transformation; forwarding the message to a bottom cell for a second virtual world; rendering a portion of the second world in response to the message; stacking the top cell, the middle cell, and the bottom cell to generate a scene; A computer program product stored on a non-transitory computer medium, which implements the

12. The computer program product of claim 11 , wherein the portion of the second world is the same size as the minimum rendering size.

13. The computer program product of claim 11 , wherein the intermediate cell is transparent.

14. The computer program product of claim 11 , wherein the cell is an iFrame.

15. The computer program product of claim 11 , wherein the cells are separate applications.

16. The computer program product of claim 11 , wherein the first virtual world is a user's location.

17. The computer program product of claim 6 , further comprising, when executed by the computer system, the step of: the user interacting with the portal.

18. The computer program product of claim 7 , wherein the interaction is one of selecting the portal or passing through the portal.

19. 12. The computer program product of claim 11, further comprising, when executed by the computer system, the step of reordering the top and bottom cells in response to the interaction.

20. The computer program product of claim 11 , wherein the at least one transformation is generated based on a user's field of view.

Images