Contents
2 Scope of the MPAI Metaverse Model – Architecture CfT.
4 Evaluation Criteria and Procedure
5 Expected development timeline
Annex C: Check list of data formats proposed by a respondent
Annex D: Technologies that may require specific testing
Annex E: Mandatory text in responses
1 Introduction
Moving Picture, Audio and Data Coding by Artificial Intelligence (MPAI) is an international non-profit organisation with the mission of developing standards for Artificial Intelligence (AI)-enabled data coding and for technologies that facilitate integration of data coding components into ICT systems [1]. The MPAI Statutes assign to MPAI the task to facilitate the creation of patent pool that rely on clear IPR licensing frameworks established by the Framework Licences [2].
MPAI has developed several Technical Specifications relevant to its mission: execution environment of multi-component AI applications, context-based audio enhancements, multimodal human-machine conversation, company performance prediction, neural network watermarking, and governance of the MPAI ecosystem. Three Technical Specifications have been adopted by IEEE without modification and two more are in the pipeline.
MPAI is engaged in several other projects on AI health, connected autonomous vehicles, MPAI metaverse model, and XR Venues. When the functional requirements of a project are consolidated, MPAI principal members adopt a “Framework Licence” that sets some important elements of the future licence for the standard essential patents and MPAI issues a Call for Technologies, a document inviting the submission of contributions in response to the Call for Technologies by parties who accept to licence their technologies according to the Framework Licence, if accepted to be part of the target Technical Specification.
This document is a Call for Technologies (CfT) for the MPAI Metaverse Model (MPAI-MMM) – Architecture Technical Specification. MPAI has already published two documents belonging to the MPAI-MMM project: MPAI Metaverse Model – Functionalities [3] and MPAI Metaverse Model – Functionality Profiles [4]. They were developed as a basis for the planned Technical Specification: MPAI-MMM Architecture. Three documents are attached to this Call for Technologies:
- Use Cases and Functional Requirements: MPAI Metaverse Model – Architecture [5].
- Framework Licence: MPAI Metaverse Model – Architecture [6].
- Template of Responses: MPAI Metaverse Model – Architecture [7]
2 Scope of the MPAI Metaverse Model – Architecture CfT
This Call for Technologies: MPAI Metaverse Model MPAI-MMM – Architecture invites any party wishing to contribute to the development of the planned Technical Specification: MPAI Metaverse Model (MPAI-MMM) – Architecture to submit a response. They may do so irrespective of their ownership of technologies that satisfy Functional Requirements of Use Cases and Functional Requirements: MPAI-MMM – Architecture [5]. If they own such technologies, they are required to eventually license their technologies according to Framework Licence: MPAI-MMM – Architecture [6] if the technologies are selected by MPAI for possible modification and inclusion in the planned Technical Specification: MPAI-MMM – Architecture.
Any respondent who is not an MPAI member and wishes to participate in the development of the said Technical Specification shall join MPAI. If they own accepted technologies and do not join MPAI, they lose the opportunity to have their technologies included in the planned Technical Specification: MPAI-MMM – Architecture.
MPAI is not aware of any essential IP in Use Cases and Functional Requirements: MPAI-MMM – Architecture [5].
The planned Technical Specification: MPAI-MMM – Architecture will be developed using technologies that comply with the following mandatory requirements:
- Be part of responses to this Call submitted by parties accepting Framework Licence: MPAI-MMM – Architecture [6] and satisfy Use Cases and Functional Requirements: MPAI-MMM – Architecture [5].
- Be Based on technologies specified in published MPAI standards, where relevant, desirable, and feasible [1].
Therefore, the scope of this Call is restricted to responses whose specification in the planned Technical Specification: MPAI-MMM – Architecture conforms to [5].
However, respondents are welcome to additionally do one or more of the following:
- Make comments on any technical element of [5].
- Make motivated proposals of changes or proposal of technologies not included in [5] if they:
- Are in line with the scope of Use Cases and Functional Requirements: MPAI-MMM – Architecture [5].
- Satisfy the Framework Licence [6].
At this stage, MPAI membership is not a prerequisite for responding to this Call for Technologies. However, proponents should be aware that, if their proposal or part thereof is accepted for inclusion in the planned Technical Specification: MPAI-MMM – Architecture, they will be requested to immediately join MPAI, or lose the opportunity to have their accepted technologies included in the standard.
MPAI will select the most suitable technologies based on their technical merits. However, MPAI in not obligated, by virtue of this Call, to select a particular technology or to select any of the proposed technologies if those submitted are found inadequate.
Note that in the future, MPAI may decide to further extend the planned Technical Specification: MPAI-MMM – Architecture as a part or an extension of it.
3 How to submit a response
Those planning to respond to this Call are:
- Advised that the Call for Technologies: MPAI-MMM – Architecture will be presented at two online events on 2023/06/24.
- Requested to communicate their intention to respond to this Call with an initial version of the form of Annex A to the MPAI secretariat (secretariat@mpai.community) by 2023/06/30. Submission of an Annex A helps MPAI to properly plan for the revision of submissions. This, however, is not a requirements and the submission of a respondent to this Call who did not the submit Annex A will still be accepted.
- Encouraged to regularly visit the Call for Technologies webpage where relevant additional information will be posted.
- Required to deliver their submissions to the MPAI secretariat (secretariat@mpai.community) by 2023/07/10 T23:59 UTC. The secretariat will acknowledge receipt of the submission via email.
- Required to attend the review of submissions according to the schedule that the 34th MPAI General Assembly (MPAI-34) will define at its online meeting on 2023/07/12. For details on how non MPAI members who have made a submission can attend the said review sessions should contact the MPAI secretariat (secretariat@mpai.community).
Responses to this Call for Technologies: MPAI Metaverse Model Architecture may/shall include:
Table 1 – Optional and mandatory elements of a response
| Item | Status |
| Detailed documentation describing the proposed technologies | mandatory |
| The final version of Annex A. | mandatory |
| The text of Annex B duly filled out with the table indicating to which Functional Requirements the response applies. | mandatory |
| Comments on the completeness and appropriateness of the MPAI-MMM – Architecture Functional Requirements and any motivated suggestion to amend and/or extend those Requirements. | optional |
| A preliminary demonstration, with a detailed document describing it. | optional |
| Any other additional relevant information that may help evaluate the submission, such as additional use cases. | optional |
| The text of Annex E. | mandatory |
Respondents are invited to take advantage of the check list of Annex C before filling out Annex A and submitting their response.
Respondents are mandatorily requested to present their submission at a teleconference meeting to be properly announced to submitters by the MPAI Secretariat. If no presenter of a submission will be in attendance to that meeting, the submission will be discarded.
Further information on MPAI can be obtained from the MPAI website.
4 Evaluation Criteria and Procedure
Proposals will be assessed using the following process:
- Evaluation panel is created from:
- MPAI members in attendance.
- Non-MPAI members who are respondents.
- Non respondents/non MPAI member experts invited in a consulting capacity.
- No one from 1.1.-1.2. is denied membership in the Evaluation panel.
- Respondents present their proposals.
- Evaluation Panel members ask questions.
- If required, subjective and/or objective tests are carried out with the following process:
- The required tests are defined.
- The required tests are carried out.
- A report is produced.
- If required, at least 2 reviewers are appointed to review and report about specific points in a proposal.
- Evaluation panel members fill out Annex B for each proposal.
- Respondents respond to evaluations.
- Proposal evaluation report is produced.
5 Expected development timeline
Timeline of the CfT, deadlines and response evaluation:
Table 2 – Dates and deadlines
| Step | Date | Time |
| Call for Technologies: MPAI-MMM – Architecture | 2023/06/14 | 17:00 UTC |
| Online presentations of Call for Technologies: MPAI-MMM – Architecture | 2023/06/23 | 08:00 UTC
15:00 UTC |
| Notification of intention to submit proposal | 2023/06/30 | 23.59 UTC |
| Submission deadline | 2023/07/10 | 23.59 UTC |
| Evaluation of responses starts | 2023/07/12 (MPAI-34) | |
| Publication of draft Technical Specification: MPAI-MMM – Architecture for Community Comments | 2023/08/23 | |
| Adoption and publication of Technical Specification: MPAI-MMM – Architecture | 2023/09/29 | |
Evaluation to be carried out during 2-hour online sessions according to the calendar agreed at MPAI-34.
6 References
- MPAI Standards Resources; https://mpai.community/standards/resources/.
- MPAI Patent Policy; https://mpai.community/about/the-mpai-patent-policy/.
- MPAI; Technical Report: MPAI Metaverse Model (MPAI-MMM) – Functionalities V1; January 2023; https://mpai.community/standards/mpai-mmm/mpai-metaverse-model/mmm-functionalities/
- MPAI; Technical Report: MPAI Metaverse Model (MPAI-MMM) – Functionality Profiles V1; April 2023; https://mpai.community/standards/mpai-mmm/mpai-metaverse-model/mmm-functionality-profiles/
- MPAI; Use Cases and Functional Requirements: MPAI Metaverse Model (MPAI-MMM) – Architecture; N1250:
- MPAI; Framework Licence: MPAI Metaverse Model (MPAI-MMM) – Architecture; N1251;.
- MPAI; Template for Responses: MPAI Metaverse Model (MPAI-MMM) – Architecture; N1252;.
Annex A: Information Form
This information form is to be filled in by a Respondent to this Call for Technologies: MPAI-MMM – Architecture.
- Title of the proposal.
- Organisation: company name, position, e-mail of contact person.
- What are the main functionalities of your proposal?
- Does your proposal provide or describe a formal specification and APIs?
- Will you provide a demonstration to show how your proposal meets the evaluation criteria?
Annex B: Evaluation Sheet
NB: This evaluation sheet will be filled out by Evaluation Team members.
Proposal title:
Main functionalities:
Response summary: (a few lines)
Comments on relevance to the CfT (Requirements):
Comments on possible MPAI-MMM – Architecture profiles[1]
Evaluation table:
Table 3 – Assessment of submission features
| Note 1 | Table 4 gives the semantics of submission features. |
| Note 2 | Evaluation Elements indicate the elements used by the evaluator in assessing the submission. |
| Note 3 | Final Assessment indicates the ultimate assessment based on the Evaluation Elements. |
| Submission features | Evaluation Elements | Final Assessment |
| Completeness of description | ||
| Understandability | ||
| Extensibility | ||
| Use of standard technology | ||
| Efficiency | ||
| Test cases | ||
| Maturity of reference implementation | ||
| Relative complexity | ||
| Support of MPAI use cases | ||
| Support of non-MPAI use cases |
Content of the criteria table cells:
Evaluation facts should mention:
- Not supported / partially supported / fully supported.
- What supports these facts: submission/presentation/demo.
- The summary of the facts themselves, e.g., very good in one way, but weak in another.
Final assessment should mention:
- Possibilities to improve or add to the proposal, e.g., any missing or weak features.
- How sure the evaluators are, i.e., evidence shown, very likely, very hard to tell, etc.
- Global evaluation (Not Applicable/ –/ – / + / ++)
New Use Cases/Requirements Identified:
(Please describe)
Evaluation summary:
- Main strong points, qualitatively:
- Main weak points, qualitatively:
- Overall evaluation: (0/1/2/3/4/5)
0: could not be evaluated
1: proposal is not relevant.
2: proposal is relevant but requires significant more work.
3: proposal is relevant, but with a few changes.
4: proposal has some very good points, so it is a good candidate for standard.
5: proposal is superior in its category, very strongly recommended for inclusion in standard.
Additional remarks: (points of importance not covered above.)
The submission features in Table 3 are explained in the following Table 4.
Table 4 – Explanation of submission features
| Submission features | Criteria |
| Completeness of description | Evaluators should:
1. Compare the list of requirements (Annex C of the CfT) with the submission. 2. Check if respondents have described in sufficient detail how the requirements are supported by the proposal. Note1: Completeness of a proposal for a Use Case is a merit because reviewers can assess how the components are integrated. Note2: Submissions will be judged for the merit of what is proposed. A submission on a single technology that is excellent may be considered instead of a submission that is complete but has a less performing technology. |
| Understandability | Evaluators should identify items that are demonstrably unclear (inconsistencies, sentences with dubious meaning etc.) |
| Extensibility | Evaluators should check if respondent has proposed extensions to the Use Cases.
Note: Extensibility is the capability of the proposed solution to support use cases that are not supported by current requirements. |
| Use of standard Technology | Evaluators should check if new technologies are proposed where widely adopted technologies exist. If this is the case, the merit of the new technology shall be proved. |
| Efficiency | Evaluators should assess power consumption, computational speed, computational complexity. |
| Test cases | Evaluators should report whether a proposal contains suggestions for testing the technologies proposed. |
| Maturity of reference implementation | Evaluators should assess the maturity of the proposal.
Note1: Maturity is measured by the completeness, i.e., having all the necessary information and appropriate parts of the HW/SW implementation of the submission disclosed. Note2: If there are parts of the implementation that are not disclosed but demonstrated, they will be considered if and only if such components are replicable. |
| Relative complexity | Evaluators should identify issues that would make it difficult to implement the proposal compared to the state of the art. |
| Support of non MPAI-MMM use cases | Evaluators should check whether the technologies proposed can demonstrably be used in other significantly different use cases. |
Annex C: Check list of data formats proposed by a respondent
Table 5 is a suggested check list to inform MPAI about the data formats contained in a response.
Table 5 – List of data formats in Use Cases and Functional Requirements: MPAI-MMM – Architecture [5]
Note: The numbers in the first column refer to the section numbers of [5].
Table 6 – Table of response areas
| # | MPAI-MMM Architecture elements | Response |
| 2 | Use Cases | |
| 3 | Functionalities of the MPAI Metaverse Model | Y/N |
| 3.1 | Disclaimer | Y/N |
| 3.2 | Basic Functionalities | Y/N |
| 3.3 | Processes | Y/N |
| 3.4 | Items | Y/N |
| 3.5 | Data Types | Y/N |
| 3.6 | Interoperability support | Y/N |
| 4 | Functional Requirements | Y/N |
| 4.2 | Processes | Y/N |
| 4.2.2 | App | Y/N |
| 4.2.3 | Device | Y/N |
| 4.2.4 | Service | Y/N |
| 4.2.5 | User | Y/N |
| 4.3 | Items | Y/N |
| 4.3.1 | General | Y/N |
| 4.3.2 | Account | Y/N |
| 4.3.3 | Activity Data | Y/N |
| 4.3.4 | Asset | Y/N |
| 4.3.5 | AuthenticateIn | Y/N |
| 4.3.6 | AuthenticateOut | Y/N |
| 4.3.7 | Contract | Y/N |
| 4.3.8 | DiscoverIn | Y/N |
| 4.3.9 | DiscoverOut | Y/N |
| 4.3.10 | Entity | Y/N |
| 4.3.11 | Event | Y/N |
| 4.3.12 | Experience | Y/N |
| 4.3.13 | Identifier | Y/N |
| 4.3.14 | InformIn | Y/N |
| 4.3.15 | InformOut | Y/N |
| 4.3.16 | Interaction | Y/N |
| 4.3.17 | InterpretIn | Y/N |
| 4.3.18 | InterpretOut | Y/N |
| 4.3.19 | Ledger | Y/N |
| 4.3.20 | Map | Y/N |
| 4.3.21 | M-Environment | Y/N |
| 4.3.22 | Message | Y/N |
| 4.3.23 | M-Location | Y/N |
| 4.3.24 | Model | Y/N |
| 4.3.25 | Object | Y/N |
| 4.3.26 | Persona | Y/N |
| 4.3.27 | Personal Profile | Y/N |
| 4.3.28 | Program | Y/N |
| 4.3.29 | Provenance | Y/N |
| 4.3.30 | Request-Action | Y/N |
| 4.3.31 | Response-Action | Y/N |
| 4.3.32 | Rights | Y/N |
| 4.3.33 | Rules | Y/N |
| 4.3.34 | Scene | Y/N |
| 4.3.35 | Social Graph | Y/N |
| 4.3.36 | Stream | Y/N |
| 4.3.37 | Transaction | Y/N |
| 4.3.38 | U-Location | Y/N |
| 4.3.39 | User Data | Y/N |
| 4.3.40 | Value | Y/N |
| 4.3.41 | Wallet | Y/N |
| 4.4 | Actions | Y/N |
| 4.4.2 | Authenticate | Y/N |
| 4.4.3 | Author | Y/N |
| 4.4.4 | Change | Y/N |
| 4.4.5 | Convert | Y/N |
| 4.4.6 | Discover | Y/N |
| 4.4.7 | Execute | Y/N |
| 4.4.8 | Hide | Y/N |
| 4.4.9 | Identify | Y/N |
| 4.4.10 | Inform | Y/N |
| 4.4.11 | Interpret | Y/N |
| 4.4.12 | MM-Add | Y/N |
| 4.4.13 | MM-Animate | Y/N |
| 4.4.14 | MM-Disable | Y/N |
| 4.4.15 | MM-Embed | Y/N |
| 4.4.16 | MM-Enable | Y/N |
| 4.4.17 | MM-Send | Y/N |
| 4.4.18 | Modify | Y/N |
| 4.4.19 | MU-Actuate | Y/N |
| 4.4.20 | MU-Render | Y/N |
| 4.4.21 | MU-Send | Y/N |
| 4.4.22 | Post | Y/N |
| 4.4.23 | Register | Y/N |
| 4.4.24 | Resolve | Y/N |
| 4.4.25 | Track | Y/N |
| 4.4.26 | Transact | Y/N |
| 4.4.27 | UM-Animate | Y/N |
| 4.4.28 | UM-Capture | Y/N |
| 4.4.29 | UM-Render | Y/N |
| 4.4.30 | UM-Send | Y/N |
| 4.4.31 | Validate | Y/N |
| 4.5 | Data Types | Y/N |
| 4.5.2 | Address | Y/N |
| 4.5.3 | Amount | Y/N |
| 4.5.4 | Cognitive State | Y/N |
| 4.5.5 | Coordinates | Y/N |
| 4.5.6 | Currency | Y/N |
| 4.5.7 | Emotion | Y/N |
| 4.5.8 | Orientation | Y/N |
| 4.5.9 | Personal Status | Y/N |
| 4.5.10 | Point of View | Y/N |
| 4.5.11 | Position | Y/N |
| 4.5.12 | Social Attitude | Y/N |
| 4.5.13 | Spatial Attitude | Y/N |
| 4.5.14 | Time | Y/N |
Respondent should in any case review the equivalent list in the table of contents of [5].
Annex D: Technologies that may require specific testing
Table 7 will be compiled based on the responses received.
Table 7 – Functional Requirements that may require specific testing
| Section | Technology | Nature of Test |
Annex E: Mandatory text in responses
A response to this MPAI-MMM – Architecture Call for Technologies shall mandatorily include the following text
<Company/Member> submits this technical document in response to Call for Technologies: MPAI Metaverse Model (MPAI-MMM) – Architecture V1 (N1249).
<Company/Member> explicitly agrees to the steps of the MPAI standards development process defined in Annex 1 to the MPAI Statutes (N421), in particular <Company/Member> declares that <Company/Member> or its successors will make available the terms of the Licence related to its Essential Patents according to the Framework Licence: MPAI Metaverse Model (MPAI-MMM) – Architecture (N1251), alone or jointly with other IPR holders after the approval of the planned Technical Specification: MPAI Metaverse Model (MPAI-MMM) – Architecture by the General Assembly and in no event after commercial implementations of the Technical Specification: MPAI Metaverse Model (MPAI-MMM) – Architecture become available on the market.
In case the respondent is a non-MPAI member, the submission shall mandatorily include the following text
If (a part of) this submission is identified for inclusion in a specification, <Company> understands that <Company> will be requested to immediately join MPAI and that, if <Company> elects not to join MPAI, this submission will be discarded.
Subsequent technical contribution shall mandatorily include this text
<Member> submits this document to MPAI as a contribution to the development of the planned the Technical Specification: MPAI Metaverse Model (MPAI-MMM) – Architecture.
<Member> explicitly agrees to the steps of the MPAI standards development process defined in Annex 1 to the MPAI Statutes (N421), in particular <Company> declares that <Company> or its successors will make available the terms of the Licence related to its Essential Patents according to the Framework Licence: MPAI Metaverse Model (MPAI-MMM) – Architecture (N1251), alone or jointly with other IPR holders after the approval of the Technical Specification: MPAI Metaverse Model (MPAI-MMM) – Architecture by the General Assembly and in no event after commercial implementations of the Technical Specification: MPAI Metaverse Model (MPAI-MMM) – Architecture become available on the market.
[1] Profile of a standard is a particular subset of the technologies that are used in a standard and, where applicable, the classes, subsets, options and parameters relevan for the subset.
