<-References Go to ToC Processes ->

(Informative)

MMM-TEC defines a metaverse instance (M-Instance) – in the following also called MMM – as an ICT platform populated by Processes that:

  1. Operate with various degrees of autonomy and interactivity under the responsibility of the M-Instance. Third parties may offer services to Processes, and machines and humans. the Universe, i.e., the real world.
  2. Sense Data from U-Environment, portions of the Universe.
  3. Produce three types of Items, i.e., Data that has been Identified in, thus recognised by the M-Instance:
    1. Digitised – i.e., sensed from the Universe – possibly animated by activities in the Universe.
    2. Virtual – i.e., imported from the Universe as Data or internally generated – possibly autonomous or driven by activities in the Universe.
    3. Mixed Digitised and Virtual.
  4. Perform – either on their initiative, or driven by the actions of humans or machines in the Universe – Process Actions that combine:
    1. Action, possibly prepended by
      1. MM: to indicate Actions performed inside the M-Instance, e.g., MM-Animate is the Action that uses a stream to animate a 3D Model with a Spatial Attitude (defined as Position, Orientation, and their velocities and accelerations).
      2. MU: to indicate Actions in the M-Instance influencing the Universe, e.g., MU-Actuate is the Action of a Device rendering one of its Items to a U-Location as Media with a Spatial Attitude.
      3. UM: to indicate Actions in the Universe influencing the M-Instance, e.g., UM-Embed is the Action of placing an Item produced by Identifying a scene, UM-Captured at a U-Location, at an M-Location with a Spatial Attitude.
    2. Items on which the Action is performed or are required for performance, such as Asset, 3D Model, Audio Object, Audio-Visual Scene, etc.
    3. M-Locations and/or U-Locations where the Process Action is performed.
    4. Times during which the Process Action is performed.
  5. May hold Rights on an Item, i.e., may perform a set of Process Actions on that Item that are listed in the Rights..
  6. Affect U-Environments and/or M-Instances using Items in ways that are:
    1. Consistent with the goals set for the M-Instance.
    2. Within the M-Capabilities , e.g., enable Transactions, of the M-Instance.
    3. According to the Rules of the M-Instance.
    4. Respecting applicable laws and regulations.
  7. Perform activities strictly inside the M-Instance or have various degrees of interaction with Data sensed from and/or actuated in the Universe.
  8. May be characterised as:
    1. Services providing specific functionalities, such as content authoring.
    2. Devices connecting the Universe to the M-Instance and the M-Instance to the Universe.
    3. Apps running on Devices.
    4. Users representing and acting on behalf of human entities residing in the Universe. A User may be rendered as a Persona, i.e., a static or dynamic avatar.
  9. May request another Process to perform a Process Action on its behalf by using the Inter-Process Protocol.

An M-Instance is managed by an M-Instance Manager. At the initial time, the M-Instance Manager has Rights covering the entire space of the M-Instance and may decide to define certain subsets of the M-Instance space, called M-Environments, and attach Rights to them.

A Registering human may:

  1. Request to Register to open an Account of a certain class.
  2. Be requested to provide their Personal Profile and to Transact a Value (i.e., an Amount in a Currency) to open an Account.
  3. Obtain in exchange a set of Rights that their Processes may perform. Rights have Levels indicating that the Rights are
    1. Internal, e.g., assigned by the M-Instance at Registration time according to the M-Instance Rules and the Account type.
    2. Acquired, e.g., obtained by initiative of the Process.
    3. Granted to the Process by another Process.

MMM-TEC V2.0 does not specify how an M-Instance verifies the compliance of the Process Actions performed by a Process to its Rights. However, an M-Instance can decide to verify the full set of Activity Data (the log of performed Process Actions), or to make verifications based on claims by another Process, to make random verifications or to not make any verification at all.

A M-Instance can be a costly undertaking if all technologies required by the MMM Technical Specification shall mandatorily be implemented even if an M-Instance has limited scope. MMM-Profiles are introduced to facilitate the take-off of M-Instance implementations. A Profile only includes a subset of the Process Actions that are expected to be needed and are shared by a sizeable number of applications. MMM defines four Profiles:

  1. Baseline Profile enables a human equipped with a Device supporting the Baseline Profile for basic applications such as lecture, meeting, and hang-out.
  2. Finance Profile enables a human equipped with a Device supporting the Finance Profile to perform trading activities.
  3. Management Profile includes the functionalities of the Baseline and Finance Profiles and enables a controlled ecosystem with more advanced functionalities.
  4. High Profile enables all the functionalities of the Management Profile with a few additional functionalities of its own.

Figure 2 – MMM-TEC V2.0 Profiles

MPAI did develop some use cases in the two MPAI-MMM Technical Reports published in 2023 and used them to develop the MMM-ARC and MMM-TEC Technical Specifications. MMM-TEC V2.0 includes several Verification Use Cases that use Process Actions to verify that the currently specified Actions and Items fully support those Use Cases.

Figure 3 gives a summary view of some of the basic MMM elements.

Figure 3 – Main elements of an M-Instance

The fast development of certain technology areas is one of the issues that has prevented the development of standards for metaverse interoperability. MMM deals with this issue by providing the JSON syntax and semantics for all Items. When needed, the JSON syntax references Qualifiers, MPAI-defined Data Types that provide additional information to the Data Type in the form of:

  1. Sub-Type (e.g., the colour space of a Visual Data Type).
  2. Format (e.g., the compression or the file/streaming format of Speech).
  3. Attributes (e.g., the Binaural Cues of an Audio Object).

From the Qualifier, a Process receiving a Visual Object can understand whether it has the required technology to process it, or else rely on a Conversion Service to obtain a version of the Object matching its P-Capabilities.

<-References Go to ToC Processes ->