マルチモーダルアーキテクチャとインターフェース

マルチモーダル アーキテクチャとインターフェイスは、 2005 年からWorld Wide Web Consortiumによって開発されたオープン スタンダードです。2012 年 10 月 25 日に W3C の勧告マルチモーダル インタラクション容易にするためマルチモーダルシステム アーキテクチャとその汎用インターフェイスを規定する技術レポート。これは、W3C のマルチモーダル インタラクション ワーキング グループ。

マルチモーダル アーキテクチャとインターフェイスの推奨事項では、マルチモーダルシステム内のモジュールが相互に通信できるよう にするための汎用構造と通信プロトコルが導入されています。

この仕様では、制御フローデータ交換に重点を置いた一般的な参照フレームとして、イベント駆動型アーキテクチャを提案しています。この仕様は、アプリケーションのマルチモーダル サービスを制御するために必要な基本インフラストラクチャを決定するために使用できます。

このアーキテクチャは、モバイルデバイスや携帯電話、家電製品、モノのインターネットオブジェクト、テレビやホームネットワーク、エンタープライズアプリケーション、Webアプリケーション、^[1] 「スマート」カー、医療機器やアプリケーションなど、複数のデバイス上でさまざまな種類のマルチモーダルサービスプロバイダーを実装するタスクを容易にすることも提案されています。

マルチモーダルアーキテクチャとインターフェースは、マルチモーダルシステムに必要な主な機能を提供するランタイムフレームワークと呼ばれる、より大規模なサービスインフラストラクチャの詳細な説明です。このフレームワークは、MMIアーキテクチャよりも抽象度が高いです。^[2] MMIランタイムフレームワークは、マルチモーダルシステムのランタイムサポートと通信モジュールであり、MMIアーキテクチャはその主なモジュール、インターフェース、通信モードの説明と仕様です。

マルチモーダルアーキテクチャとインターフェースの仕様は、ユーザーインターフェース構造をモデル、ビュー、コントローラーの3つの部分に編成することを提案するMVC設計パターンに基づいています。^[3]この設計パターンは、Voice Browserワーキンググループのデータフロープレゼンテーションアーキテクチャでも示されています。^[4]

このアーキテクチャの特徴は、ビューによって表されるプレゼンテーション層は従来グラフィカル インターフェイスに関連付けられてきましたが、この推奨抽象化により、ビューが、ユーザーが視覚、聴覚、生体認証、および/または触覚のモダリティを組み合わせて使用​​できる、 マルチモーダル インタラクションのより広いコンテキストに一般化されることです。

MMI アーキテクチャの推奨事項では、インタラクション マネージャー(IM)、データ コンポーネント(DC)、およびモダリティコンポーネント(MC) の 3 種類のコンポーネントを区別しています。この区別は、MVC パターンのコントローラー、モデル、およびビューのプレゼンテーション ドキュメント間の分離に似ています。

もう一つの特徴は再帰性です。モジュールはブラックボックスであり、より複雑なコンポーネントに複数のコンポーネントをカプセル化して、より高いレベルのインタラクションマネージャと通信することができます。このように、アーキテクチャは入れ子人形の原則に従います。^[5]

この仕様では、ネットワーク内の複数のマテリアル リソースに対する分散実装や、すべてのモジュールが単一のマテリアル サポートにインストールされている集中実装の問題も取り上げています。モジュール間の情報共有は疎結合です。これにより、モジュール間の依存性が低くなり、1 つのモジュールの変更が他のモジュールに与える影響が軽減され、モジュールの再利用が容易になります。このように、モジュールは他のモジュールの機能についてほとんどまたはまったく認識せず、モジュール間の通信は、アーキテクチャのAPIによって提供される正確な通信プロトコルに従ってメッセージの交換を通じて行われます。^[6]

インタラクション マネージャーは、システムのコンポーネントとマルチモーダル ランタイム フレームワーク間のすべてのメッセージ交換を担当する論理コンポーネントです。これは通信バスであり、イベント ハンドラーでもあります。

各アプリケーションは、必要なインタラクション ロジックを定義するために、少なくとも 1 つのインタラクション マネージャーを構成できます。このコントローラーは、マルチモーダル インタラクションの中核です。

• さまざまな入力コンポーネントと出力コンポーネント間で交換されるイベントによってトリガーされる特定の動作を管理します。
• モジュールとクライアント アプリケーション間の通信を管理します。
• 複数の入力と出力間の一貫性を確保し、アプリケーションの現在の状態を全体的に把握できます。
• データの同期を担当します。
• フォーカス管理を担当します。
• システム外部の他のエンティティとの通信を管理します。

モダリティ コンポーネントは、音声、書き込み、ビデオなど、さまざまな方法での入力と出力の処理を含む特定のタスクを担当します。

これらは、マルチモーダル システムに関連付けられたさまざまなハードウェア デバイス (マイク、グラフィック タブレット、キーボード) およびソフトウェア サービス (モーション検出、生体認証の変更) の入力と出力を処理する論理エンティティです。たとえば (下図を参照)、モダリティ コンポーネントAは、音声認識とオーディオ入力管理を同時に実行できます。別のモダリティ コンポーネントB は、グラフィック タブレットとマイクの 2 つの異なるデバイス上の補完的なコマンド入力を管理できます。2 つのモダリティ コンポーネントCは、カムコーダという 1 つのデバイスから提供される 2 つの補完的な入力を個別に管理できます。最後に、モダリティ コンポーネントD は、外部の認識 Web サービスを使用し、認識タスクに必要な通信交換の制御のみを担当できます。

4 つのケースすべてにおいて、実装の違いはあるものの、システムには音声コマンド入力を検出するための汎用モダリティ コンポーネントがあります。どのモダリティ コンポーネントも、複数の物理デバイスによって提供される複数の機能をラップする可能性がありますが、1 つのデバイスに複数のモダリティ コンポーネントを含めることもできます。この意味で、モダリティ コンポーネントは、各ケースで異なる方法で処理および実装される同じ種類の入力の抽象化です。

このため、W3C 勧告では、現在、モダリティ コンポーネントの構造や実装については詳しく説明されていません。W3C 勧告では、インタラクション マネージャーとの通信インターフェイスの必要性と、特定の通信プロトコル (ライフサイクル イベント) に従う実装の必要性のみに焦点が当てられています。

データ コンポーネントの主な役割は、1 つまたは複数のモダリティ コンポーネントまたは他のモジュール (フレームワークのセッション モジュールなど) で必要となる可能性のあるアプリケーションのパブリック データを保存することです。

データ コンポーネントは、Interaction Manager の内部モジュールAまたは外部モジュールBになります (図を参照)。これは、各アプリケーションで選択された実装によって異なります。ただし、データ コンポーネントに直接アクセスできるのは Interaction Manager のみであり、必要に応じてデータの表示と編集、および外部サーバーとの通信を行えるのは Interaction Manager のみです。そのため、Modality コンポーネントは、マルチモーダル アプリケーションのパブリック データにアクセスするために、Interaction Manager を仲介として使用する必要があります。

ただし、プライベート データの保存については、各モダリティ コンポーネントが独自のデータ コンポーネントを実装できます。このプライベート データ コンポーネントは、外部サーバーB (図を参照) にアクセスして、モダリティ コンポーネントが音声認識タスクなどで必要とする可能性のあるデータを保存することもできます。これは、MMI アーキテクチャ推奨事項で示されている入れ子人形の原則に従った実装の場合です。

MMI アーキテクチャでは、通信プロトコルは非同期かつ双方向であり、ユーザーのアクションまたは何らかの内部アクティビティに続いてシステムによって発生する イベント通知の交換に基づいています。

このプロトコルは、交換モードと、モジュール間の通信を確立および終了する方法を定義します。この仕様の場合、これはライフサイクル イベントに反映されます。これらは、デバイスとマテリアル サービス (ビデオ プレーヤーやサウンド再生デバイスなど) を制御するために提案された 6 つの標準制御イベントと、マルチモーダル システムの現在の状態を監視するために提案された 2 つの通知です。

仕様では、リクエスト > レスポンス交換のペアとして指定される 8 つの標準ライフサイクル イベントが推奨されています。

• NewContext ( NewContextRequest / NewContextResponse )

1 つまたは複数のモダリティ コンポーネントを持つ 0 人、1 人、または複数のユーザー間のインタラクション サイクル (コンテキスト) の作成を示します。コンテキストは、モジュールが情報を利用できるようにしておく必要があるインタラクションの最長期間です。

コンテキストは、インタラクション サイクル中のユーザーとシステムのアクティビティのセマンティクスに関連付けられます。これにより、実装は、情報を保持することが現在のアクティビティの実行にとって意味があるかどうかを判断できます。

通常、コンテキストはユーザー入力から作成されます。イベントは通常、1 つ以上のモダリティ コンポーネントによって、クエリに応答する必要があるインタラクション マネージャーに送信されます。

たとえば、タッチ スクリーンで表示される Web ページ内の指のジェスチャ ( touchmove ) に関連付けられた入力を管理するモダリティ コンポーネントがあるとします。物理的なインタラクションの開始時に、モダリティ コンポーネントは次のクエリを送信します。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:newContextRequestリクエストID= "myReq1"ソース= "myPointerMC.php"ターゲット= "myIM.php"データ= "myMCStatus.xml" /> </mmi:mmi>  
     

このリクエストに対して、インタラクション マネージャーは次のように応答します。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:newContextResponseリクエストID= "myReq1"ソース= "myIM.php"ターゲット= "myPointerMC.php"コンテキスト= "myContextID1"ステータス= "成功" /> </mmi:mmi>  
      

Interaction Manager がリクエストの発信元である可能性もあります。この場合、構文は同じままですが、ソース プロパティとターゲットプロパティの値を変更する必要があります。

• ClearContext (ClearContextRequest / ClearContextResponse)クリアコンテキスト

インタラクション マネージャーによって送信されるこのイベントは、インタラクション (コンテキスト) サイクルの終了をマークし、現在のインタラクション コンテキストに割り当てられたリソースの解放を要求します。ClearContext イベントは、ユーザーまたはシステム アクティビティの終了に関連付けられる場合があります。例:

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:clearContextRequestリクエストID= "myReq2"ソース= "myPointerMC.php"ターゲット= "myIM.php"コンテキスト= "myContextID1" /> </mmi:mmi>  
     

要求を受信すると、モダリティ コンポーネントは応答として次のものを返します。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:clearContextResponseリクエストID= "myReq2"ソース= "myPointerMC.php"ターゲット= "myIM.php"コンテキスト= "myContextID1"ステータス= "成功" /> </mmi:mmi>  
      

• 準備(PrepareRequest / PrepareResponse)

インタラクション マネージャーによって送信されるこのイベント コントロールは、モダリティ コンポーネントに、タスクを開始する準備が必要であり、作業を実行するために必要なデータをロードできることを通知します。例:

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch" version= "1.0" xmlns:svg= "http://www.w3.org/2000/svg" > <mmi:prepareRequest requestID= "myReq3" source= "myIM.php" target= "myDisplayMC.php" context= "myContextID2" > <mmi:content> <svg:svg width= "100%" height= "100%" version= "1.1" > <rect width= "300" height= "100" style= "fill:rgb(0,0,255);stroke-width:1;stroke:rgb(0,0,0)" /> </svg:svg> </mmi:content> </mmi:prepareRequest> </mmi:mmi>   
    

   
   

準備フェーズで読み込むドキュメントやデータが複数ある場合、Interaction Manager は各リクエストの後にタスクを開始せずに PrepareRequest イベントを複数回トリガーできます。ただし、各リクエスト呼び出しには応答する必要があります。この例では、コンテンツが適切にプリロードされている場合、応答は次のようになります。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:prepareResponseリクエストID= "myReq3"ソース= "myDisplayMC.php"ターゲット= "myIM.php"ステータス= "成功"コンテキスト= "myContextID2" > </mmi:prepareResponse> </mmi:mmi>  
     

• 開始(StartRequest / StartResponse)

Interaction Manager によって送信されるこのコントロール イベントは、Modality コンポーネントにタスクを開始できることを通知します。例:

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch" version= "1.0" > <mmi:startRequest requestID= "myReq4" source= "myIM.php" target= "myPlayerMC.php" context= "myContextID3" data= "myPlayerParams.xml" > <mmi:contentURL href= "myAnimation.swf" /> </mmi:startRequest> </mmi:mmi>  
     
 

作業の実行中に Modality コンポーネントが新しい StartRequest イベントを受信した場合、新しいタスクを開始するか、失敗を報告することができます。実行が成功した場合、応答は次のようになります。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:startResponseリクエストID= "myReq4"ソース= "myPlayerMC.php"ターゲット= "myIM.php"ステータス= "success"コンテキスト= "myContextID3" > </mmi:startResponse> </mmi:mmi>  
     

失敗した場合の応答は、たとえば次のようになります。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:startResponseリクエストID= "myReq4"ソース= "myPlayerMC.php"ターゲット= "myIM.php"ステータス= "失敗"コンテキスト= "myContextID3" > <mmi:statusInfo>  
     

コンテンツなし
</mmi:statusInfo> 
</mmi:startResponse> 
</mmi:mmi>

• キャンセル(CancelRequest / CancelResponse)

Interaction Manager によって送信されるこの制御イベントは、Modality コンポーネントに現在のタスクを停止するように通知します。例:

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch" version= "1.0" > <mmi:cancelRequest requestID= "myReq5" source= "myIM.php" target= "mySpokerMC.php" context= "myContextID4" Immediate= "true" /> </mmi:mmi>  
     

モダリティ コンポーネントの応答は次のようになります。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:cancelResponseリクエストID= "myReq5"ソース= "mySpokerMC.php"ターゲット= "myIM.php"コンテキスト= "myContextID4"ステータス= "成功"データ= "myMCStatus.xml" /> </mmi:mmi>  
      

• 一時停止( PauseRequest / PauseResponse )

インタラクション マネージャーによって送信されるこのコントロール イベントは、モダリティ コンポーネントに現在のタスクを一時停止する必要があることを通知します。たとえば、グラフィック タブレットの入力を管理するモダリティ コンポーネントの要求は次のようになります。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:pauseRequest requestID= "myReq6"ソース= "myIM.php"ターゲット= "myWriterMC.php"コンテキスト= "myContextID5"即時= "false" /> </mmi:mmi>  
     

モダリティ コンポーネントの応答は次のようになります。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:pauseResponseリクエストID= "myReq6"ソース= "myWriterMC.php"ターゲット= "myIM.php"コンテキスト= "myContextID5"ステータス= "成功"データ= "myMCStatus.xml" /> </mmi:mmi>  
      

• 再開( ResumeRequest / ResumeResponse )

インタラクション マネージャーによって送信されるこの制御イベントは、以前に一時停止されたタスクを再開する必要があることをモダリティ コンポーネントに通知します。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:resumeRequestリクエストID= "myReq7"ソース= "myIM.php"ターゲット= "myWriterMC.php"コンテキスト= "myContextID5" /> </mmi:mmi>  
    

モダリティ コンポーネントの応答は次のようになります。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:resumeResponseリクエストID= "myReq7"ソース= "myWriterMC.php"ターゲット= "myIM.php"コンテキスト= "myContextID5"ステータス= "成功" /> </mmi:mmi>  
     

• ステータス( StatusRequest / StatusResponse )

これは、インタラクション マネージャーまたはモダリティ コンポーネントによって送信されます。このイベントは、インタラクションのサイクルがまだ実行中であるかどうか、つまりコンテキストが「生きている」かどうかを示します。たとえば、モダリティ コンポーネントは、障害またはスタンバイの場合にプロセスを停止するためにシステムの状態を監視する必要がある場合があります。この場合、インタラクション マネージャーに次のメッセージを送信できます。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:statusRequest requestID= "myReq8"ソース= "myRecorderMC.php"ターゲット= "myIM.php" requestAutomaticUpdate= "true" /> </mmi:mmi>  
     

リクエストにコンテキストパラメータがない場合は、コントローラは現在のインタラクション コンテキストのステータスではなく、システムまたはホスト サーバーのステータスを返す必要があります。このリクエストに対して、インタラクション マネージャは次のように応答します。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch"バージョン= "1.0" > <mmi:statusResponse requestID= "myReq8"ソース= "myIM.php"ターゲット= "myRecorderMC.php"ステータス= "alive"自動更新= "true" /> </mmi:mmi>  
      

仕様では、2 種類の通知も推奨されています。そのうちの 1 つは拡張通知で、デバイスやマテリアル サービスを処理するための制御データまたはコマンド データを含めることができます。このため、この通知は例外、つまり要求 > 応答のペアとして記述されない標準制御イベント (以前のバージョンではデータ イベントと呼ばれていました) と見なされます。2 つの通知は次のとおりです。

• 拡張機能(ExtensionNotification)

このイベントは、アプリケーション固有の制御データやその他の必要なデータを通信するために使用されます。これは、インタラクション マネージャーまたはモダリティ コンポーネントによって生成できます。アプリケーション固有のニーズ専用の汎用 API を提供することで、アーキテクチャの拡張性を確保します。たとえば、DVD プレーヤーを処理するモダリティ コンポーネントは、DVD のメイン メニューとのインタラクションをシステムに通知できます。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch" version= "1.0" > <mmi:extensionNotification requestID= "myReq9" source= "myPlayerMC.php" target= "myIM.php" context= "myContextID6" name= "playerNavigation" > <applicationdata> <data id= "menu" selected= "true" /> </applicationdata> </mmi:extensionNotification> </mmi:mmi>  
          
     
            
     
     

• 完了(DoneNotification)

この通知は、Modality コンポーネントがタスクを完了したときに、Interaction Manager に送信されます。たとえば、認識 Modality コンポーネントが画像認識タスク (顔の検出) を完了したときは次のようになります。

<mmi:mmi xmlns:mmi= "http://www.w3.org/2008/04/mmi-arch" version= "1.0" > <mmi:doneNotification requestID= "myReq10" source= "myDetectorMC.php" target= "myIM.php" context= "myContextID7" status= "success" > <mmi:data> <data id= "detectionList" > <users> <user id= "u58" confidence= ".85" /> <user id= "u32" confidence= ".75" /> <user id= "u87" confidence= ".60" /> </users> </data> </mmi:data> </mmi:doneNotification> </mmi:mmi>  
          
         
            
               
                      
                      
                      
               
           
         
     

• MMIF: マルチモーダル インタラクション フレームワーク (James A. Larson、TV Raman、Dave Raggett 編、W3C、2003 年)。この W3C ノートでは、マルチモーダル システムの主な汎用コンポーネントを説明するフレームワークを提案しています。このフレームワークは、マルチモーダル アプリケーションを開発するための基礎であり、使用する言語、スクリプト、スタイル、その他の有用なリソースを提案します。
• SCXML: ステート チャート XML。制御抽象化のためのステート マシン表記法、Jim Barnett 他著。W3C 編集、2006 年。SCXML は、イベントに基づく汎用ステート マシン言語です。さまざまなタイプの認識を呼び出すダイアログ制御言語として、データベースやビジネス ロジック モジュールへのアクセスも制御できる音声アプリケーションのメタ言語( VoiceXMLダイアログとキーボード、マウス、インク、視覚、触覚デバイスなどの他のモダリティを組み合わせたマルチモーダル制御言語など)、拡張コール センターの管理言語、そして音声処理を伴わない他のコンテキストでの一般的なプロセスの制御言語として使用できます。
• CCXML: Voice Browser Call Control バージョン 1.0、RJ Auburn 編集、W3C、2005。CCXML を使用すると、ダイアログ システムでの音声通話を制御できます。たとえば、 VoiceXMLを使用するシステムでは、さまざまな種類のメディアを処理できます。
• EMMA: マイケル・ジョンソンら編、W3C、2005 年、拡張可能なマルチモーダル注釈マークアップ言語。EMMA は、信頼レベル、タイムスタンプ、入力様式、入力データの認識に関連するオプションなどのアプリケーション固有の情報を使用して、ユーザー入力の解釈をマークアップする XML 形式です。
• MMIUse: マルチモーダル インタラクション ユース ケース、Emily Candell および Dave Raggett 編、W3C、2002 年。この W3C ノートでは、マルチモーダル インタラクションのユース ケースをいくつか説明し、複数のデバイスの機能と各ユース ケースに必要なイベントの観点からそれらを提示しています。これは、音声、書き込み、ショートカット、音声コマンドを使用してオーディオまたはビジュアル出力結果を得るなど、ユーザーが複数のモダリティでインタラクトできるマルチモーダル アプリケーションのさまざまなコンポーネントを組み立てるのに役立ちます。
• SMIL: 同期マルチメディア統合言語バージョン 2.1、Dick Bulterman 他編、W3C、2005 年。SMILは、画面上のプレゼンテーションのレイアウトを記述するメディアへのリンクを組み合わせることで、プレゼンテーションの時間的な動作を記述するインタラクティブなマルチメディア プレゼンテーションを作成できる言語です。また、他の言語で必要なタイミングと同期も提供します。
• VoiceXML: 音声拡張マークアップ言語バージョン 2.0、Scott McGlashan 他編、W3C、2004 年。これにより、ユーザーが自分の声やサウンドで対話できるページを作成できます。また、合成音声、デジタル化されたオーディオ信号、音声入力、またはDTMF トーンを使用して、ユーザーと Web ページ間のダイアログを作成することもできます。
• HTML: HyperText Markup Language バージョン 4.01、Raggett 他編、W3C、1999 年。Web ページの表示とテキストを記述し、ページに追加のテキスト、メディア リソース (画像、ビデオ、サウンド)、インタラクティブ メディア リソース (フォーム、アニメーション、インタラクティブ ユニバース 3D) へのリンクを含めるために使用されます。この記述は、構造化コードで記述されたタグを使用して作成され、特定のグラフィック スタイル ( CSS ) に関する情報やスクリプト ( ECMAScript ) によるプログラムされたインタラクションによって補完できます。
• SVG: Scalable Vector Graphics 1.1、Jon Ferraiolo 他編、W3C、1995 年。SVGは、適応可能なベクター グラフィックスを記述するためのファイル形式です。
• XMLSig: XML-SignatureSyntax and Processing、Eastlake 他編、W3C、2001 年。Web ページの作成者を認証し、 XML ドキュメントのデジタル署名を通じてその整合性を確保するために使用されます。

• RFC 7230: HTTP/1.1 メッセージ構文とルーティング。IETF、2014 年。
• RFC 2119: IETF の要件レベルを示すために RFC で使用されるキーワード、1997 年。
• RFC 2396: IETF の Uniform Resource Identifiers、1995 年。

• 分散およびユビキタス コンピューティングにおけるマルチモーダル インタラクション、Pous, M. および Ceccaroni, L、インターネットおよび Web アプリケーションとサービス (ICIW)、2010 年第 5 回国際会議、バルセロナ、スペイン、2010 年。
• Wegscheider, F. 他著「デバイスに依存しないモバイル アプリケーション向けのマルチモーダル インタラクション マネージャー」、インターネットおよび Web アプリケーションとサービス (ICIW)、2010 年第 5 回国際会議、バルセロナ、スペイン、2010 年。
• STANCIULESCU, Adrian (2008).情報システムのマルチモーダルユーザーインターフェースを開発するための方法論. ルーヴァン大学出版局. ISBN 978-2-87463-114-6。
• 適応型マルチモーダル モバイル通知のモデル、William Brander 著、ネルソン マンデラ メトロポリタン大学、ポート エリザベス、南アフリカ、2007 年。
• モバイル ユーザーへのマルチモーダル コンテキスト依存サービスの提供、Ardit, C 他著、仮想モバイル ガイドに関する全国イベント、イタリア、トリノ、2006 年。
• 2004 年 7 月 19 ～ 20 日に開催された W3C のマルチモーダル アーキテクチャとインターフェイス ワークショップで発表された論文。フランス、ソフィア アンティポリス
• Irina KONDRATOVA 著「コンクリート品質管理情報のためのモバイル フィールド データ入力」、欧州製品およびプロセス モデリング会議 (ECPPM 2004) の議事録。NRC 発行番号: NRC 47158。

• W3C が新しいマルチモーダル標準を草案、Leonard Klie、speechtechmag、2009 年 2 月 17 日。
• W3C のマルチモーダル アーキテクチャとインターフェイス ワークショップ、2007 年 11 月 16 ～ 17 日、慶應義塾大学。
• W3C マルチモーダル アーキテクチャ、パート 2: XML 仕様スタック。SCXML、XHTML、REX などを使用したマルチモーダル オーサリング、Gerald MCCOBB、IBM、2007 年 5 月 31 日。
• マルチモーダル インタラクションとモバイル Web、パート 1: マルチモーダル自動入力。フォームに個人情報を自動的に入力、著者: Gerald MCCOBB、IBM、2005 年 11 月 15 日。
• マルチモーダル インタラクションとモバイル Web、パート 2: Find-It を使用した簡単な検索、Yahoo! ローカル検索エンジンへの音声アクセスを有効にする方法、Gerald MCCOBB、IBM、2005 年 12 月 6 日。
• マルチモーダル インタラクションとモバイル Web、パート 3: ユーザー認証。音声と視覚的なインタラクションによる安全なユーザー認証、Gerald MCCOBB、IBM、2006 年 1 月 10 日。
• 分散マルチモーダル同期プロトコル (DMSP)、Chris Cross 著、Gerald McCobb および Les Wilson 協力、IBM Corporation、2006 年 7 月 13 日。
• W3C が新しいヨーロッパ プロジェクト「マルチモーダル Web」を主導 (Ercim News、2004 年)。
• マルチモーダルインタラクションにより、デバイスの統合、アクセシビリティ、および通信サービスの強化が期待されます (Techrepublic、2003 年)。
• Paolo Baggia による Deborah Dahl 博士へのインタビュー。VoiceXML イタリア ユーザー グループ、2003 年 7 月。

• W3C の MMI グループ
• マルチモーダルインタラクションアクティビティ
• W3C ウェブサイトのマルチモーダル インタラクション アクティビティ