Meta Patent Shares Quest System Update Compatible With Both Older App Software Versions

CheckCitation/SourcePlease click:XR Navigation Network

(XR Navigation Network March 27, 2024) Backward compatibility is important for users who wish to continue to experience the functionality of older software versions. By convention, applications are updated to the current version, removing or replacing portions of previous versions. In addition, updated applications are typically compatible only with the latest version of the runtime platform, completely eliminating access to older software versions supported by previous versions of the runtime platform.

在名为“Managing updates for an artificial reality system in cross-version and cross-platform environments”的专利申请中，Meta就介绍了一种相关的解决方案。

MetaMeta says that the implementation introduced by the invention is particularly useful in XR systems because of the large number of available experiences and the desire to maintain access to older experiences across platforms. Since application and runtime updates can be frequent, a user's access to older experiences is lost when one of them is updated. The invention introduces implementations that allow backward compatibility with multiple versions of an application, seamlessly improving the ability of XR systems to execute a wide variety of applications that are not possible with traditional systems.

Additionally, specific implementations can phase out and uninstall runtime versions that are no longer in use over time, freeing up storage space as new versions become available, while still allowing access to older experiences that are still in use.

FIG. 4 is an illustration of a component 400 for use in a system employing the techniques of the invention. mediator 420 may include components that mediate resources between hardware 410 and specialized components 430. For example, the intermediary 420 may include an operating system, service, driver, BIOS, controller circuitry, or other hardware or software system.

The specialized component 430 may include software or hardware configured to perform operations for managing updates to the artificial reality system in a cross-version and cross-platform environment. The specialized components 430 may include a runtime version manager 434, an XR experience manager 436, a Meta retrieval module 438, a runtime version selector 440, an XR experience loader 442, and components and APIs that may be used to provide a user interface, transfer data, and control the specialized components.

The runtime version manager 434 can manage multiple versions of the XR runtime stored in the storage memory 418. Each version of the XR runtime may specify a set of packets. When executing a particular version of the XR runtime, the runtime version manager 434 may dynamically select and load the set of packets required to execute the XR experience.

The XR experience manager 436 may manage XR experiences from the application, e.g., stored in the storage memory 418 or received from the network via 1/O 416.The XR experience manager 436 may receive XR experience requests in the application.

The Meta Retrieval Module 438 may access the Meta associated with the requested XR experience.The Meta may specify a set of XR experience compatible versions in multiple versions of the XR runtime. In particular implementations, the Meta may be defined by a developer with XR experience. In other cases, Meta can be automatically generated based on an analysis of XR experience characteristics.

The runtime version selector 440 may select a version of the XR runtime. the XR experience loader 442 may load the XR experience by accessing scripts and assets in a set of packets specified for the selected XR runtime version to execute the application using the selected XR runtime version.

The flowchart of FIG. 5 illustrates a process 500 for managing XR system updates in a cross-version and cross-platform environment.

At 502, process 500 may store multiple versions of the XR runtime. In one embodiment, process 500 may obtain an updated version of the XR runtime and install the updated version of the XR runtime without having to uninstall multiple stored versions of the XR runtime. For example, updating to a new version of the runtime may include storing packages for that runtime and specifying which existing packages and new packages correspond to the runtime version.

As a result, Process 500 can build a repository of XR runtime versions to which new versions of the XR runtime can be added without affecting previous versions of the XR runtime. Thus, older versions of the XR runtime can be preserved and can be used to load experiences that may not be compatible with the latest version of the XR runtime.

At 504, the process 500 may receive a request for an XR experience in an application program.The XR experience may be any experience executable by the XR system described herein. Packets associated with executing the application on a particular version of the XR runtime may be stored remotely and pushed to the user's device when the XR experience is requested.

At 506, a process 500 responding to a request for an XR experience may access a Meta associated with the XR experience.The Meta may specify a set of XR experience-compatible versions among the multiple stored versions of the artificial reality runtime.

At 508, process 500 may select a version of the XR runtime. The selected version of the XR runtime need not be the latest version of the XR runtime, but may be a previous version of the XR runtime that has not been replaced or uninstalled by a newer version.

At 510, the process 500 may load the XR experience by executing the application using a selected version of the artificial reality runtime, by accessing the scripts and resources in the dataset specified for the selected version of the XR runtime.

In one implementation, the process 500 may receive multiple XR experience requests from multiple computing devices, such as for a multi-person XR experience. In such an implementation, the process 500 may obtain data indicative of the XR runtime versions available from the requesting computing device and determine from the data that there is at least one overlapping version among all of the computing device versions available.

FIG. 7A is an exemplary conceptual diagram for selecting the latest supported version of the runtime.

The XR device 752 may request the XR experience 710. the XR experience 710 may be associated with a Meta712, which recognizes a set of runtime versions that are compatible with the XR experience 710. In this example, the runtime versions range from 1.0.1 to 1.1.2. The runtime version selector 740 can obtain Meta712 and access the multi-version runtime library 704.

The multi-version runtime library 704 may include multiple runtime versions 708A-708F. in this example, the runtime version selector 740 may select the most recent runtime version available in the multi-version runtime library 704 that is compatible with the XR experience 710, in this case runtime_version_1.1.2 708E. the runtime version selector 740 may further provide a runtime version for the XR Experience 710 to provide runtime_version_1.1.2 708E to load the XR Experience 710 on the XR device 752.

FIG. 7B illustrates an exemplary system 700B for selecting an up-to-date version of a runtime, said runtime version being backwardly compatible with a supported version of the runtime for the XR experience.

In some cases, it may be desirable to load the XR Experience 710 using a newer runtime version that is available, even though the XR Experience 710 may not be explicitly compatible with that runtime version. However, if the newer runtime version is backward compatible with one of the runtime versions in the set of runtimes that are compatible with the XR Experience 710, the system 700B can still load the XR Experience 710 using the newer runtime version without compatibility issues.

The system 700B may include an XR device 752, a runtime version selector 740, and a multi-version runtime library 704. the runtime version selector 740 may be analogous to the runtime version selector 440 in FIG. 4. the XR device 752 may request an XR experience 710. in this example, the runtime version ranges from 1.0.1 to 1.1.2. The runtime version selector 740 may receive Meta 712 and access the multi-version runtime library 704.

The multi-version runtime library 704 may include multiple runtime versions 708A-708F. in this example, the runtime version selector 740 may select the most recent version of the runtime available in the multi-version runtime library 704 that is backward compatible with the XR experience 710. In this case, runtime_version_1.1.3 708F (which is backward compatible with runtime versions 1.1.0 through 1.1.2) is run, and runtime_version_1.1.3 708F is provided to the XR Experience 710 to load the XR Experience 710 on the XR device 752.

FIG. 8 illustrates an exemplary system 800 for selecting the latest supported overlapping version of a runtime.The system 800 may receive multiple requests for XR experiences from multiple computing devices, such as for a multiplayer XR experience. In such an implementation, the system 800 may obtain data indicative of the available versions of the XR runtime from the requesting computing devices and determine from the data that at least one of the overlapping versions is available for all of the computing device available versions. The system 800 may then select a version of the XR runtime.

The XR experience 810 is associated with Meta812.Meta812 may specify the experience that the computing device 802A-B wishes to load and the set of runtimes that are compatible with that experience. The runtime version selector 840 may obtain the Meta812 as well as the runtime sets available for the computing device 802A and the computing device 802B.

The runtime version selector 840 may be similar to the runtime version selector 440 in FIG. 4. The runtime version selector 840 may select the latest runtime version available to the computing devices 802A and 802B. In this case, the runtime version selector 840 may select runtime_version_1.0.3. The runtime version selector 840 may invoke runtime_version_1.0.3 at the computing device 802A and the computing device 802B to load the XR experience 810.

The conceptual diagram of FIG. 9 illustrates an exemplary system 900 for selecting and pushing the latest supported version of a runtime. in a multiplayer XR experience, while taking into account that one or more of the requesting computing devices may not have a version of the XR runtime that is compatible with the XR experience and/or two or more of the requesting computing devices may not have any overlapping versions. In such an implementation, for example, the system 900 may select the most recent version of the XR runtime that is compatible with the XR experience and push the selected version to computing devices that do not store that version.

The system 900 includes a computing device 902A and a computing device 902B that are each associated with two users attempting to load the XR experience 910. It is envisioned that the components required to load the XR experience 910 may be stored locally on the computing devices 902A-B, on a service over a network, or some components may be stored locally while others are stored on a server. The system 900 includes a runtime version selector 940, which may be similar to the runtime version selector 440 in FIG. 4.

The computing device 902A and the computing device 902B may have a plurality of runtime versions installed locally. Specifically, computing device 902A may access runtime_version_1.0.1, runtime_version_1.0.2, and runtime_version_1.0.3. computing device 902B may access "runtime_version_1.0.2 ", "runtime_version_1.0.3" and "runtime_version_1.0.4".

The XR experience 910 is associated with Meta912.Meta912 may specify the experience that the computing device 802A-B wishes to load, and the set of runtimes that are compatible with that experience. A runtime version selector 940 may obtain the Meta912 and the set of runtime versions available for computing device 902A and computing device 902B.

In this case, the computing device 902A and the computing device 902B do not have any overlapping runtimes. Accordingly, the runtime version selector 940 may select the latest version of a runtime compatible with the XR experience 810 available in at least one of the computing device 902A and the computing device 902B. In this example, runtime_version_1.0.4.

The runtime version selector 940 may access the multi-version runtime library 904 to obtain runtime_version_1.0.4 and push runtime_version_1.0.4 to the computing device 902A in order to load the XR experience 910 on the computing device 902A. the runtime version selector 940 may call the runtime_version_1.0.4 on the computing device 902B to invoke the runtime_version_1.0.4 in order to load the XR experience 910 on the computing device 902B.

The Meta patent application titled "Managing updates for an artificial reality system in cross-version and cross-platform environments" was originally filed in August 2022 and was recently published by the USPTO. August 2022 and was recently published by the USPTO.