JP2007533015A - メディア・パッケージならびにメディア・パッケージの管理システムおよび方法 - Google Patents

Abstract

【課題】メディア・パッケージならびにメディア・パッケージの管理システムおよび方法を提供する。
【解決手段】メディア・パッケージは、他のメディア・パッケージへのリンクを含むデータ構造を有することを特徴とする。好ましくは、メディア・パッケージは、他のメディア・パッケージへの双方向リンクを有するヘッダを含む。各メディア・パッケージは、マルチメディア・データ、またはマルチメディア・データのソースへのリンクを含むことができる。グラフィカル・ユーザ・インターフェースについても記載され特許請求されており、グラフィカル・ユーザ・インターフェースでは、レイアウトおよび／または機能性は、少なくとも部分的に、メディア・パッケージ内に収容されている情報によって決定される。メディア・パッケージを用いたテレビ会議方法についても記載し特許請求する。
【選択図】図１

Description

本発明は、メディア・パッケージ、ならびにメディア・パッケージを著作(author)および表示する方法およびシステムに関する。本明細書の内容においては、「メディア・パッケージ」という用語は、論理的であれまたは物理的であれ、少なくとも１つのメディア・ファイルを収容するために利用することができる構造を示すために用いることとする。メディア・ファイルとは、ビデオ・クリップ、オーディオ・クリップというような、プレゼンテーション・エレメント、あるいはスクリプト（またはアプリケーション）を含む、プレゼンテーション・エレメントを形成する際に利用するテキスト文書またはデータのことである。更に具体的には、メディア・パッケージは、マルチメディア・プレゼンテーションを組み立て、編成し、観衆に発表するビヒクル(vehicle)として用いることができる。また、本発明は外部アプリケーションのフロント・エンドとして作用するグラフィカル・ユーザ・インターフェースに関する。

インターネットは、比類ない量の情報を消費者に提供してきた。更に、パーソナル・コンピュータ、インターネット、およびテレビジョンのような他の形態のメディアの間の区別が曖昧になっている。利用可能な量に伴う問題の１つは、有意かつ探索可能なフォーマットでデータを編成するという問題である。これは、特に、異種形態のディジタル・コンテンツを、コンテクスト間の相互交換に適したコヒーレント・グルーピング(coherent grouping)内に導入する必要がある場合に該当する。ディジタル・コンテンツの非対応形態に伴う別の問題は、多数の(sheer number)ファイル・タイプおよびコデックのため、とめどなく増大し続ける量のアプリケーションにユーザが精通していなければならないことである。

種々のメディアをグループ化し公開(present)する現行の方法は、オンラインおよびオフライン環境が別個であったときに開発された。これらの方法は、オンライン、オフライン、「クライアント側」および「サーバ側」の間の境界線が曖昧になっている現在の状況に対する適格性に欠けている。

異種のコンテンツをグループ化する試みの内最も良く知られており広く認識されているのは、ウェブページである。ＨＴＭＬ（ハイパー・テキスト・マークアップ言語）は、あらゆるファイル・フォーマットを参照することができる。しかしながら、これは、ファイルを統合するのではなく、ファイルにリンクすることによってそのようにしているのである。ユーザがＨＴＭＬページをセーブすると、セーブされたページはコンテンツを含んでいない。ページによってリンクされたコンテンツ（例えば、携帯電話からのビデオ・クリップ）は、ＨＴＭＬとは別個に格納され、ファイル・システムのディレクトリ・ツリー内で分散される。

ウェブページを新たなサイトに移送する際、元のウェブ・サイトのディレクトリ全体について技術的な知識がないと、行うことができない。これは、ディジタル・コンテンツの有意なサブグループの標準化、およびコンテクスト間におけるこれらのサブグループの容易な移植に対する障害となる。あるページから別のページへのハイパー・リンク形成は可能であるが、このインターフェース・レベルにおいても、グループ化機構は不適当である。ユーザは、各ページを見ても、全体的な構造を見ることができず、各サイトの各ページは非標準ナビゲーション構造を有する。

平均的なユーザにとって、ディジタル・コンテンツを作成し、集約し、公開し、供給する(syndicate)ことは、相変わらず困難である。個々の比較的小さい集合の活動間で、彼らは、多数の職業人およびずらりと並んだ威圧するようなソフトウェア・アプリケーションに関与することを望んでいる。職業人が作成するコンテンツの殆どは、完全にコンテクストが閉ざされている(context bound)。このため、コンテンツを他のコンテクストに再利用またはコピーすることが困難または不可能となっている。これが意味するのは、多くの作業が不必要に繰り返されており、多大な出費、冗長、そして手間の無駄が生ずるということである。また、これは、アド・ホック・インターフェースが増殖する理由の１つでもあり、エンド・ユーザの問題を一層悪化させている。

職業人やコンテンツ供給者でさえも、大量の関連情報を表示し、伝達し、コヒーレントで容易に探索可能であり直感的なインターフェースに編成するための方法でもがき苦しんでいる。

更に、コンテンツの自動プレゼンテーション（ランダムなブラウジングとは反対）が、これらの問題の各々によって妨害されている。何故なら、自動化は、コンテンツを組み合わせ、グループ化し、再コンテクスト化(re-contextualizing)、表示し、再生することができる規格を必要とするからである。

第１の形態において、本発明は、少なくとも１つのプレゼンテーション・エレメントを収容または参照する記憶手段を備えたメディア・パッケージを提供する。メディア・パッケージは、他のメディア・パッケージと関連付け可能であり、メディア・パッケージ間でプレゼンテーション・エレメントをリンクするようになっている。

メディア・パッケージは、更に、メディア・パッケージを少なくとも１つの他のメディア・パッケージと関連付け、メディア・パッケージ間においてプレゼンテーション・エレメントをリンクするように動作するリンク構造を備えるとよい。

リンク構造は、パッケージ間においてプレゼンテーション・エレメントをリンクするように、メディア・パッケージを複数の他のメディア・パッケージにリンク可能であり、更に、リンク構造は、それが関連付けられているまたは各メディア・パッケージと双方向リンクを確立するように動作可能でとするとよい。

双方向リンクを確立するとき、リンク構造は、前記リンクに変数を含むように動作し、変数は、一方のリンクを主リンクとして定め、他方のリンクを副リンクとして定めるように動作するとよい。

主および副リンクのいずれか一方が、連続的なプレゼンテーションを形成するように、プレゼンテーション・エレメントをリンクしたシーケンスを確立するとよい。

一実施形態では、メディア・パッケージの移動または修正時に、メディア・パッケージは、メディア・パッケージのリンクの少なくとも部分集合を収容するダミー・ファイルを保持させ、メディア・パッケージを参照する他のメディア・パッケージが、メディア・パッケージの移動または修正によって影響を受けないようにする。

ダミー・ファイルは、メディア・パッケージの複製とするとよい。

別の実施形態では、メディア・パッケージの移動または修正時に、メディア・パッケージは、当該メディア・パッケージを参照している他の全メディア・パッケージの全リンクを、メディア・パッケージの修正または移動を反映するように更新する。

別の実施形態では、メディア・パッケージの移動または修正時に、メディア・パッケージは、当該メディア・パッケージを参照している他のメディア・パッケージのリンクの少なくとも部分集合を、メディア・パッケージの修正または移動を反映するように更新する。

実施形態の中には、リンクの少なくとも部分集合を更新するのは、他のメディア・パッケージの１つが移動または修正されたメディア・パッケージにアクアセスしようとしたときにのみでよい場合もある。

同様のメディア・パッケージを求めて探索を行う際に、探索は、メディア・パッケージによって参照されたメディア・パッケージの部分集合を戻すとよく、戻される部分集合を所定の判断基準によって判定する。

メディア・パッケージは、更に、ヘッダ部と二進情報ストアとを備えているとよく、ヘッダ部は、関連性情報を収容し、二進情報ストアは、少なくとも１つのプレゼンテーション・エレメントを収容する。

第２の形態では、本発明は、本発明の第１の形態によるメディア・パッケージの配信方法を提供し、ユーザの要求に応答して、メディア・パッケージのコピーをユーザに送るステップを備えている。

第３の形態では、本発明は、本発明の第１の形態によるメディア・パッケージの配信方法を提供し、ヘッダ情報の少なくとも部分集合をエンド・ユーザおよび少なくとも１つのプレゼンテーション・エレメントの表現に配信するステップと、二進情報の少なくとも一部に対するユーザ要求に応答して、二進情報の少なくとも一部をユーザに配信するステップとを備えている。

第４の形態では、本発明は、プレゼンテーションの格納方法を提供し、本発明の第１の形態によるメディア・パッケージを複数提供するステップと、メディア・パッケージのそれぞれにおいてプレゼンテーションのプレゼンテーション・エレメントを格納するステップと、プレゼンテーション・エレメントを関連付けるように、メディア・パッケージをリンクするステップとを備えている。

前述の方法は、更に、メディア・パッケージを双方向にリンクするステップを備えている。

第５の形態では、本発明は、本発明の第１の形態によるメディア・パッケージを著作し、編集し、格納し、配信するシステムを提供し、メディア・パッケージを格納可能なストレージと、メディア・パッケージに対するクライアント・アプリケーションからの要求の受信時に、メディア・パッケージをクライアント・アプリケーションに配信することが可能なソフトウェア・パッケージとを備えている。

メディア・パッケージを移動または修正するコマンドをメディア・パッケージから受信したとき、システムは、メディア・パッケージのオリジナル・リンクの少なくとも部分集合を収容したダミー・ファイルを保持させ、メディア・パッケージを参照する他のメディア・パッケージがメディア・パッケージの移動または修正によって影響を受けないようにすることができる。

あるいは、メディア・パッケージを移動または修正するコマンドをメディア・パッケージから受信したとき、システムは、メディア・パッケージを参照している他の全メディア・パッケージの全リンクを、メディア・パッケージの修正または移動を反映するように更新させることができる。

更に別の実施形態では、メディア・パッケージを移動または修正するコマンドをメディア・パッケージから受信したとき、システムは、他のメディア・パッケージの１つが、移動または修正したメディア・パッケージにアクセスしようとしたときにのみ、メディア・パッケージを参照している他の全メディア・パッケージの全リンクを、メディア・パッケージの修正または移動を反映するように更新させる。

更に、システムは、格納されているメディア・パッケージを検討し、探索可能なインデックスをコンパイルすることが可能なサーチ・エンジンを備えてもよい。

システムは、コンピュータ・ネットワークを介して相互接続された複数のサーバを備えることができる。

第６の形態では、本発明は、本発明の第１の形態によるメディア・パッケージを複数表示するためのグラフィカル・ユーザ・インターフェースを提供し、ユーザが選択可能な複数の表示部を備えており、ユーザに一意のメディア・パッケージの表現を収容する第１表示部と、他のユーザに一意のメディア・パッケージの表現を収容する第２表示部と、ユーザまたは他のユーザに位置のメディア・パッケージを著作、編集、または目視するように配された第３表示部とを含む。

グラフィカル・ユーザ・インターフェースは、更に、表示部のいずれの１つに収容されているメディア・パッケージであっても選択することにより目視可能なメニュー・システムを備えてもよく、メニュー・システムは、その中に表示されているメディア・パッケージの表現を操作する機能性を提供する。

メニュー・システムは、メディア・パッケージの表現の上に重なることもでき、メディア・パッケージの表現を横切るカーソルの移動によって呼び出すことができる。

メニュー・システムは、更に、複数の表示部の各々を包囲する第２メニューを備えることもでき、このメニューは、その中に表されているメディア・パッケージを操作する機能性を提供する。

メディア・パッケージの操作は、メディア・パッケージをコピーする機能、メディア・パッケージを編集する機能、メディア・パッケージを削除する機能、およびメディア・パッケージを新たなコンテクストに移動する機能を含むことができる。

メディア・パッケージの表現の操作は、主プレゼンテーション・エレメントを目視する機能、および他のプレゼンテーション・エレメントのいずれかを目視する機能を含むことができる。

ユーザのコマンドに応答して、プレゼンテーション・エレメントの表現は、表現から、メディア・パッケージの他の全てのプレゼンテーション・エレメントの異なる表現に変形することができる。

変形は、前面から背面への、表現の仮想回転によって行われるとよい。

第２表示エリアは、ユーザの部分集合のみによってアクセス可能なメディア・パッケージの表現を目視することに限定することもできる。

表示部は、少なくとも１つのメディア・パッケージの表現を収容し、該表現を、グリッド・パターンのような、予め規定したパターンで提供する。

グラフィカル・ユーザ・インターフェースのレイアウトは、選択したメディア・パッケージのコンテンツによって決定することができる。

第７の形態では、本発明は、メディア・コンテンツを表示するように配された少なくとも１つの目視エリアを備えているグラフィカル・ユーザ・インターフェースを提供し、グラフィカル・ユーザ・インターフェースのレイアウトは、少なくとも部分的に、目視エリアの少なくとも１つに表示されるメディア・コンテンツによって決定される。

グラフィカル・ユーザ・インターフェースのレイアウトは、少なくとも１つのメニュー・システムを含むことができ、このメニュー・システムの機能性を目視エリアに表示されるメディア・コンテンツによって決定する。

メニュー・システムは２つのサブ・メニューを含むこともでき、第１サブ・メニューはメディア・コンテンツを操作するための制御部を設け、第２サブ・メニューはインターフェ巣におけるメディア・コンテンツの目視を操作するための制御部を設ける。

グラフィカル・ユーザ・インターフェースでは、更に、メディア・パッケージとインターフェースすることが可能なブログ作成手段を備えることもでき、ブログ作成手段がメディア・パッケージにおいてテキスト・コメントを編集可能である。

第８の形態では、本発明は、請求項１から１３までのいずれか１項に記載のメディア・パッケージの少なくとも部分集合をグラフィカル・ユーザ・インターフェースに配信するように構成された計算システムを備えている、複数のメディア・パッケージを目視するシステムを提供し、メディア・パッケージは、グラフィカル・ユーザ・インターフェースにおいて動作する少なくとも１つの特性を確立する際に用いられる情報を含む。

第９の形態において、本発明は、グラフィカル・ユーザ・インターフェースをカスタム化する方法を提供し、グラフィカル・ユーザ・インターフェースのレイアウトおよび機能性を決定する情報を含むメディア・パッケージを作成するステップと、情報を収容したメディア・パッケージの少なくとも部分集合を、グラフィカル・ユーザ・インターフェースに配信するステップとを備えている。

第１０の形態において、本発明は、メディア・パッケージの作成方法を提供し、少なくとも１つのプレゼンテーション・エレメントを選択するステップと、プレゼンテーション・エレメントをメディア・パッケージの中に形成するステップとを備えている。

第１１の形態において、本発明は、複数のメディア・パッケージを探索する方法を提供し、ユーザに関心のあるメディア・パッケージを選択するステップと、メディア・パッケージにリンクされる全てのメディア・パッケージを特定するステップと、リンクされているメディア・パッケージの少なくとも一部の表現を表示するステップとを備えている。

第１２の形態において、本発明は、複数のメディア・パッケージに収容されているプレゼンテーション・エレメントを一元化する方法を提供し、一連のメディア・パッケージを選択するステップと、選択したメディア・パッケージからプレゼンテーション・エレメントの部分集合を抽出するステップと、抽出したプレゼンテーション・エレメントの部分集合を収容する、別のメディア・パッケージを構成するステップとを備えている。

第１３の形態では、本発明は、請求項１から１３までのいずれか１項に記載の１つのメディア・パッケージの少なくとも部分集合を受け取り、メディア・パッケージの少なくとも１つの部分集合をユーザに表示するように構成されたソフトウェア・アプリケーションを含むデバイスを備えている、プレゼンテーション配信システムを提供する。

メディア・パッケージはストリーム化データを収容することができ、これは、テレビ会議の呼のような、生ソースとすることができる。

ストリーム化データは、メディア・パッケージ内に収容されている一連のプレゼンテーション・エレメントを含むことができ、一連のプレゼンテーション・エレメントを順次公開する。

第１３の形態では、本発明は、複数のユーザにコンテンツを分散する方法を提供し、請求項１から１３までのいずれか１項に記載のメディア・パッケージを組み立てるステップと、メディア・パッケージを多数のユーザに分散するステップとを備えている。

第１４の形態では、本発明は、自己実行メディア・プレゼンテーションをユーザに提供する方法を提供し、少なくとも１つのプレゼンテーション・エレメントをグループ化して、請求項１から１３までのいずれか１項に記載のメディア・パッケージにするステップと、メディア・パッケージをユーザに提供するステップとを備えており、ユーザは少なくとも１つのプレゼンテーション・エレメントを目視することができる。

第１５の形態では、本発明は、テレビ会議方法を提供し、テレビ会議を開始することが可能なスクリプトを含むメディア・パッケージを提供するステップと、タイルをユーザに転送するステップとを備えており、ユーザによる受信および確認時に、テレビ会議を開始する。

これより、添付図面を参照して、一例としてのみ、好適な実施形態について説明するが、他にも本発明の範囲に該当する形態があり得る。

本発明は、少なくとも一実施形態において、メタデータ、コンテンツ、リンク、メソッド、ボタン／メソッド関連付け、およびシーケンス処理情報を含むことができるメディア・パッケージである。これをファイル・フォーマットと記述する。技術的観点からは、実施形態は、オブジェクト系プログラミング・モデルにおけるオブジェクト／一連のオブジェクトと同類である。エンド・ユーザの視点からは、このファイル・フォーマットは、再生可能メディア・ファイルとして体験され、同じタイプの別のファイルを含み、それを関連付けることを可能にする方法に独自性がある。このオブジェクトは、「Ｔｉｌｅｆｉｌｅ」^ＴＭという名称の下で販売されており、以下の説明では「タイルファイル・パッケージ」(tilefile package)と呼ぶことにする。タイルファイル・パッケージは、エンド・ユーザに対して、「タイル」のメタファ(metaphor)を呼び出す。何故なら、ファイル・タイプのコンテンツは、グラフィカル・ユーザ・インターフェースではグリッド(grid)またはその他の象徴的パターンで表される場合があるからである。即ち、以下で更に詳しく説明するグラフィカル・ユーザ・インターフェースは、複数の目視エリアで構成されている。目視エリアの各々は、１つ以上のタイルファイル・パッケージの表現を保持することができる。言い換えると、目視部分は、グリッドまたはその他のパターンにおいて、１つのタイルファイル・パッケージのみを表示することができ、あるいは複数のタイルファイル・パッケージを表示することができる。エンド・ユーザに対して、そしてこの説明の目的上、「タイル」(tile)という用語は、「タイルファイル・パッケージ」の具体的なインスタンスを示すために、特に、グラフィカル・ユーザ・インターフェース内において表現されるときのタイルファイル・パッケージを示すために用いることとする。タイルファイル・パッケージは、ユーザ・インターフェースにおいて表現される場合、「タイル前面」部および「タイル背面」部に分割される（図１３、（１））。タイルファイル・パッケージの前面は、タイルファイル・パッケージの「面」(face)とも呼ばれる。

タイルファイル・パッケージの面は、ユーザには直ちに識別可能であり、通例、写真、ビデオ・クリップ、またはタイルファイル・パッケージのコンテンツのその他の視覚的表現であり、一般に「主要プレゼンテーション・エレメント」の表現である。即ち、デフォルト視覚エレメントである。ユーザ・コマンドに応答して、タイルの前面（または背面）から種々の機能にアクセス可能であり（図１４Ｂ、（３０））、これらは追加のプレゼンテーション・エレメントの加算および減算、エレメント間の関係の変更、タイルファイル・パッケージ（２５）に関する見る人のコメント(viewer comments)の書き込み(logging)、ならびにタイルファイル・パッケージの資産(asset)の１つであり得る「スクリプト」(script)の書き込み、編集および再生を含むことができる。

タイルの前面からアクセス可能な種々の機能は、タイルのコンテンツによって決定される。即ち、各目視エリアはメニューによって覆われているか、または包囲されており、メニュー上の制御は、目視エリアに表示されているタイル、およびユーザがタイルの前面またはタイルの背面のどちらを目視しているかというようなその他の要因に応じて変化する。

タイルファイル・パッケージの背面は、ユーザ・コマンドに応答して目視可能となり（例えば、図１４Ｂにおけるボタン（３１）をクリックする）、著者(author)にセキュリティ、メタデータ、および探索情報というような好み(preference)および特性(property)を設定させることができ、更に特記事項(note)またはその他の資産というような追加のエレメントの加算および減算も可能にすることができる。見る人は、タイルの背面から添付ファイル(attachment)をダウンロードすることができるが、しかしながら、オーサリング・ボタン(authoring button)は、オーサリング特権を有していない見る人には見えないようにするとよい。

スクリプトのような先進の機能性は、通例、タイルの背面を通じてアクセスすることができる。スクリプトは、タイルファイル・パッケージの資産を目視しこれらと双方向処理するための命令、その他の関連するファイルタイル・パッケージと双方向処理しこれらを調整するための命令、外部アプリケーションを実行するための命令、および外部非管理データにアクセスするための命令を収容することができ、このようなスクリプティング(scripting)により、上級のユーザに、基盤のオペレーティング・システムおよびネットワーク・サービスの最大能力へのアクセスを許す。例えば、スクリプトはタイルファイル・パッケージの再生可能コンテンツの交互のプレゼンテーションを規定することができ、スプレッドシート・データを動画グラフに変換することができ、天気報告またはカメラからの生のフィード(feed)を呼び出すことができ、あるいは１つ以上のＲＳＳフィードをカプセル化することができる。

タイルがサーバ側に存在する場合、ユーザが携帯電話機またはデバイスからそのアカウントにコンテンツを送ると、新たなタイルが自動的に開始される。あるいは、ユーザは、彼らのＰＣハード・ドライブからコンテンツをアップロードすることにより、新たなファイルを著作することができる。各タイルにおいて、編集ウィンドウが著作者に提供され、資産のアップロードをし易くしている（図１６、（５０））。これは、タイル（５２）の面をアップロードまたは変更する設備、および多数の添付ファイル（５４）をアップロードまたは変更する設備を含む。

各タイルは、ユーザ・インターフェース「シェル」(shell)のように振る舞い、ユーザ・インターフェースにおいて多数のタイルをあるパターンで目視することは、多数のユーザ・インターフェース・シェルを目視することに類し、各ファイルはそれ自体の１組の制御部を有し、それ自体のコンテンツを「所有」する。各タイルはシェルのように動作するので、タイルを目視エリアに表示するとき、このタイルと関連するメニュー・システムの外観、感触、および機能性も決定する。メニュー・システムのインスタンスは、タイルの一部であり、常にそれに隣接していることができるので、タイルに属するように見られる。このメニュー・システムは、タイルまたはタイルのコンテンツと関連付けるいずれの機能も制御することができる。これは、タイルの目視を操作する機能（例えば、タイルファイル・パッケージ内のコンテンツを表示する）、あるいはタイル内部のデータを操作する機能（例えば、エレメントをタイルファイル・パッケージに追加する（５０、５２、５４））を含むことができる。その場限りの「ポップアップ」メニューとは異なり、タイルファイル・パッケージのメニュー・システムは、ファイルタイル・パッケージ視覚言語の認識可能なインスタンスである。即ち、アプリケーションを含む全てのコンテクストにおけるタイルファイル・パッケージの全てのインスタンスにわたって均一に適用することができる。

言い換えると、タイルファイル・パッケージは、異種形態のディジタル・メディア、即ち、プレゼンテーション・エレメントを単一のエンティティ内に保持するだけでなく、グラフィカル・ユーザ・インターフェースの補助により、タイルのコンテンツを操作する機能性を設けることができる、アクティブ・コンテナ(active container)と見なすことができる。あらゆるタイルファイル・パッケージは、一意のタイルファイル・パッケージ・インターフェースのユーザに対する一意の利点を拠り所とする、新たな形態のビジュアル・リテラシ(visual literacy)に組み合わせることができる単位である。

先に触れたように、グラフィカル・ユーザ・インターフェースでは、タイルファイル・パッケージを共にグループ化して、パターンおよびグリッドに分けることができる。また、タイルファイルを互いにリンクしてシーケンスにすることもでき（図１４Ａ、（４０））、実際には、グリッド全体をシーケンスとすることができ、グリッドの各行が当該シーケンスの次の部分となる。写真のような画像は、タイルの面に表示することができるので、タイルファイル・パッケージのコンテンツを一瞥することが可能となる。尚、以下の説明では、「コンテンツ」という用語は、ディジタル・メディアに言及する場合には、「プレゼンテーション・エレメント」という用語と同等であり、このような用語は相互交換可能に用いられることは理解されよう。これらの画像に関連する他の種類のコンテンツは、タイルファイル内に格納することができ、経時的に「タイル」毎に収集することができる。

「コンテナ」のメタファは、タイルファイル・パッケージの特性の部分集合を説明するために有用である。しかしながら、全てのメタファと同様、コンテナ・メタファも分解する (break down)。例えば、タイルファイル・パッケージの重要な特徴の１つは、コンテナが封止されている場合であっても、タイルファイル・パッケージのコンテンツの表現を利用可能とすることができる点にある。更に、個々のタイルファイル・パッケージは、プレゼンテーションの目的のために、他のタイルファイル・パッケージ内の資産にアクセスすることができる。この意味では、各タイルファイル・パッケージもコントローラ／シーケンサと同様である。

多数のマルチメディア・パッケージを順次配信する（「再生」）ことにより、従来のブラウジング(browsing)に対する代用物が得られる。これは、外部アプリケーションのフロント・エンドとして作用するメディア・パッケージＧＵＩを含むことができる。メディア・パッケージのグループは、オペレーティング・システム上の中間層としても動作し、多数のアプリケーションおよびコンテクストに渡って均一な視覚シェル(visual shell)を形成することができる。

タイルファイル・パッケージはアプリケーションを収容することができ、あるいはタイルを介してアプリケーションに達する通信があってもよい。アプリケーションがタイルファイル・パッケージに埋め込まれていない場合、２つの主な可能性が存在する。

１）タイルファイル・パッケージ／ＧｒｉｄＭｏシステムは自動的に正しいアプリケーションをクライアント・マシンまたはサーバ・マシーンのいずれかにおいて、既知のファイル・タイプ関連付けを用いることによって発見し起動することができる（例えば、ワード・プロセッサは、．ｄｏｃファイルを開くために起動することができる）。

２）タイルファイル・パッケージの著作者または資産の著作者のいずれかによって、タイルファイル・パッケージ内にコンフィギュレーションを埋め込み、正しいリモート・サイトを発見することができ、更に、
ａ．対応するアプリケーション／プラグインを自動的にダウンロードし、クライアント側でそれを実行することができ（更に、実行後再度それを削除することができる）、または、
ｂ．アプリケーションをサーバ側で実行し、遠方にて資産文書を処理することができる。

この後者の特徴は、新たな文書タイプが資産として現れる毎にアプリケーションまたはプラグインをダウンロードしインストールするようにエンド・ユーザを促す必要がないことを意味する。また、これは、異なるフォーマットであり異なるアプリケーションによって用いられる文書が偶然同じファイル名拡張部を有する場合にも、混乱を解消することができる。

タイルファイル・パッケージは、テレビ会議システム(videoconferencing system)の「分散可能な端末」として用いることができる。このようなシステムでは、各タイルファイル・パッケージは２つの役割を果たす。第１に、テレビ会議参加者を「中継する」(hook up)ための構成を収容するまたは参照する転送可能ファイルである。これは、種々のクライアント・サイトにおいてテレビ電話クライアント・アプリケーションを開始することを含むことができる。また、これは、招待(invitation)、スケジューリング、正しい接続の確立、およびログオンを含むことができる。第２に、タイルファイル・パッケージは個々のクライアント・サイトにおいてテレビ電話クライアントのＧＵＩ端末となる。

また、タイルファイル・パッケージは、共用コンテンツを含む、第三者のコンテンツを参照し管理するレイヤとして用いることもできる。この関連では、タイルファイル・パッケージは、シングル・サイン・オン（ＳＳＯ：Single Sign On）の問題に対する解決策を提供する。ユーザが異なるシステムに対して多数のユーザ名／パスワード対を有する場合、単一のタイルファイル・パッケージを用いて、多数のユーザ名／パスワード対を取り出して暗号化し、必要に応じて多数のシステムに対するログオンを管理することができる。

タイルファイル・パッケージ構造
タイルファイル・パッケージの構造は、静的特性（タイルの前面に表示される画像、著作者／所有者の詳細等）、および動的特性（タイルファイル内に収容されているメディア・ファイル、他のタイルファイル・パッケージに対する関係のリスト、現れるメニューの外観、感触、および機能性を決定するコマンド等）を、その属性として含み、更にプレゼンテーション・アクションおよび／またはシーケンスをそのメソッド（機能）として含む。ここに記載する実現例では、静的特性は、全体的にヘッダ部に保持され、動的特性は二進情報ストアに保持される。しかしながら、これらの類別は厳正ではない。例えば、双方向リンクは動的特性であるが、これをヘッダに収容する。同様に、コンテンツを修正する場合、ヘッダ内のサイズ情報も修正することができる。

タイルファイル・パッケージは、論理的に、内蔵エンティティ(self-contained entity)と考えるとよく、したがって、タイルファイル・パッケージは、グラフィカル・ユーザ・インターフェースを介して、ユーザにも内蔵エンティティとして公開され、あるいはタイルファイル・パッケージの部分集合を公開してもよい。いずれの場合でも、前述のように、タイルファイル・パッケージの構造を２つの別個の区間、即ち、ヘッダ部およびメディアまたは資産（二進情報ストア）部に分割する。

ヘッダ部は、フォーマット・バージョン（下位互換性のため）、所有者／著作者の詳細、タイルの面へのポインタ（プレビュー画像を抽出するための単一の画像ファイル上での前進的ダウンロードを容易にする）、タイルファイル・パッケージの読み取り、ダウンロード、実行、および編集に関する特権というような特権、ならびに資産および関係のインデックスというような資産特性のような、一般的な特性のリストを含む。

資産インデックスは、タイルファイル・パッケージ内に収容されている各メディア・ファイルまたはその他の資産の詳細を含む。これらの詳細は、名称、タイプ、最後の修正、特権、サイズ、メディア部におけるオフセット位置、およびダウンロード・ステータスを含む。タイルファイル・パッケージのインスタンス全体では、サイズおよびオフセットの組み合わせを用いれば、メディア部におけるメディア・ファイル・バイナリを突き止め、それを抽出して公開することができる。

一実施形態では、ダウンロード時間を短縮するために、タイルファイル・パッケージをクライアント・マシンに直ちにダウンロードしない。メディア二進ファイルをダウンロードするのは、それが必要となったときのみ、またはユーザの邪魔にならずにダウンロードできるだけの十分な帯域幅が利用可能なとき（バックグラウンド・ダウンロード）だけである。部分的なインスタンスへのバックグラウンド・ダウンロードの場合、タイルファイル・パッケージの部分的インスタンスにダウンロードするメディア・ファイルの中断／再開点を特定するダウンロード・ステータスを記録する。

また、タイルファイル・パッケージは双方向リンクを含むこともできる。双方向リンクとは、別のタイルファイル・パッケージおよび／または現タイルファイル・パッケージ「によって用いられている」(used by)または「が用いている」(using)別のタイルファイル・パッケージにおけるコンテンツへのリンクである。双方向リンクは、１つのタイルファイル・パッケージから別のタイルファイル・パッケージへのリンクの形成が、リンクを最初に形成したタイルファイル・パッケージを逆に示す対応関係によって均衡が取られるという点で、二重入力アカウント・システム(double entry accounting system)と同類である。これによって、分散した抽象データエースのインスタンス化が可能となる。これは、ファイルタイル・パッケージの物理的な場所には関係なく、双方向リンクはシステムにタイルを追跡することを可能にするという考えである。これによって、タイルが移動可能となる。各タイルファイル・パッケージは、高度の自律性を呈するが、いずれのタイルファイル・パッケージもその関係を「知っており」、この知識は、グループ化および／または他のタイルファイル・パッケージの連続処理を要求する際に用いることができる。

タイルファイル・パッケージの複製コピーを作成する場合、オリジナルにおけるメディア・ファイルを最初に複製（部分的インスタンス）にコピーする必要はなく、むしろ複製（部分的インスタンス）内においてこれらに「コピー関係」という印を付ければよい（即ち、個々のメディア・ファイルの実際の物理的コピーは、オリジナル・タイルファイル・パッケージまたはコピー・タイルファイル・パッケージのいずれかにおけるメディア・ファイルを修正するときに作成するだけでよい）。この手法は、リソースの消費を大幅に削減することができる。同様に、多数の他のタイルファイル・パッケージ「によって用いられている」タイルファイル・パッケージのコピーは、「用いている」リンク("used by" links)を含まなくてもよく、オリジナルに対する関係を通じてこれらのリンクにアクセスすればよい。また、この情報のために補助ストアがあってもよく、オリジナルおよび／またはコピーに対する「リンク・コンパニオン」(link companion)と呼ぶことができる。

他のタイルファイル・パッケージとのリンクを有するタイルファイル・パッケージを移動または除去する場合、リンクされているタイルファイル・パッケージ全てを直ちに更新する必要はない。代わりに、あらゆる「用いている」リンクを新たな場所に誘導し直す目的で、移動または除去したタイルファイル・パッケージの場所に「ダミー」タイルファイル・パッケージを挿入すればよい。移動または除去したタイルファイル・パッケージを、これと関係のあるタイルファイル・パッケージが訪問する(visit)とき、ダミーが、訪問したタイルファイル・パッケージに、それ自体を更新するように指令する。関係するタイルファイル・パッケージ全てを更新し終えると、ダミー・タイルファイル・パッケージを自動的に削除することができる。

ダミー・タイルファイル・パッケージ、または異体は、付加的に、新たな場所にコピーまたは移動したタイルファイル・パッケージの「用いている」リンクを保持する目的にも供することができる。「用いている」タイルファイル・パッケージはダミーによって新たな位置に誘導し直されるので、新たな場所におけるタイルファイル・パッケージは、それを用いているリンクのみを更新すればよい。このように、コピーは、そのオリジナルから離れるように発展することができるが、オリジナルとの関係または履歴を再度取得する潜在的可能性を失うことはない。

図
これより図面を参照すると、図１は、タイルファイル・パッケージの基本構造、およびそのグラフィカル・ユーザ・インターフェース（ＧＵＩ）に対する関係を示す。ファイルタイル・パッケージは、テキストであるヘッダと、そのネーティブな二進形態での資産を収容するファイル本体と、同様に二進ファイルとすることができ、あるいは他のいずれかの形態で格納することもできるテキスト情報ストアとから成る。ファイル本体は、１つ以上のスクリプト、即ち、実行または再生することができる命令も収容することができる。

更に詳細には、これらの区間は次の通りである。

（ｉ）テキスト・フォーマットされ、タイルの名称、タイルの記述、著作者（および／またはタイルが関連付けられているユーザ・アカウント）、日時スタンプ、およびバーション番号を収容する基本ヘッダ。

（ｉｉ）双方向リンクとして格納され、タイルファイル・パッケージが、それがメンバーであるタイルファイル・パッケージの種々のグルーピング(grouping)を用いているのか、またはこれらに「用いられている」のかを明示するフラグを収容するヘッダ関係（図１ａも参照）。双方向リンクを使用することにより、あらゆるタイルが、どのタイルファイル・パッケージのグルーピングとそれが関連付けられているのかを「知る」および「思い出す」ことができ、したがって、それ自体のコンテンツおよび他のタイルファイル・パッケージのコンテンツを組み立てて有意なプレゼンテーションにするにはどうすればよいかを「知る」および「思い出す」ことができる。

あらゆるタイルファイル・パッケージは「面」（タイルの「前面」）を有するので、これらの面はビデオ・クリップおよびその他の時間に基づくプレゼンテーション（指定した時間期間だけ公開される静止画像を含む）を表すことができ、タイルファイル・パッケージのシーケンスは、面エレメントを次々に表示することにより、時間に基づくプレゼンテーションを形成することができる。いずれの時点でも、ユーザはプレゼンテーションを一時休止し、現在面が表示されていれる特定のコンテナのコンテンツに侵入する(drill down into)ことができる。

（ｉｉｉ）ヘッダ二進情報ポインタ／資産インデックス。バイト部ストリングがここに格納され、どのようにファイルが二進数を分離するかを、二進の形態と共に記述する。

更に詳細には、次の通りである。

１．二進情報ストア
これは、メディア・コンテンツを格納するところである。二進情報をそのネーティブな形態で格納することにより、多数のファイル・フォーマットに対応することができる。データの操作は、必ずしもタイルファイルにおいて行われるとは限らず、以前のバージョンを添付する、または以前の日付の素材を上書きする、あるいはその双方を行うように、抽出し、操作し、そして戻すことができる。二進情報の多数の繰り返しを格納し、修正の履歴を保持できるようにするとよい。

２．ファイル本体は、特殊カテゴリとして、タイルの「面」を収容する。

これは、ＧＵＩにおいて表示されるタイルの前面である。また、タイルの面は、素早くロードするために、プレビュー形態で格納してもよく、あるいはこれらを徐々にダウンロードして、時と共にＧＵＩにおけるそれらの解像度を高めるようにすることもできる。多数のタイルの面を順次処理し、１回のプレゼンテーションとして、次々に公開することもできる。面が静止画像である場合、スライド・ショーのように、所与の時間期間にわたって公開することができる。これがビデオ・クリップである場合、指定した開始点から終了点まで公開することもできる。このように、静止画像およびビデオ・クリップ（ならびにその他の時間に基づくメディア）は、各々、所与の時間期間を有するシーケンスのサブ・クリップを形成することができる。

３．テキスト系資産(text based assets)
主に、個々のタイルファイル・パッケージ、またはそれ自体が一部をなすタイルファイル・パッケージのグルーピングに関して記入した(log)コメントの記録のために用いられる。これは、ファイル自体に組み込まれるＸＭＬ系データベースとしてもよい。あるいは、各コメントを、タイルファイル・パッケージの資産として、タイルファイル・パッケージに記入してもよい。テキストは、二進形態、またはその他の何らかの形態で格納することができる。

図２を参照すると、ＨＴＭＬウェブページの主要な欠点の１つは、それがコンテナでなく、ＵＲＬ連鎖(linkage)によってそのオリジナル・コンテクストに取り込まれることである。主にテキストとして収容される全てのデータを格納するテキスト・フォーマット、ＨＴＭＬはあらゆるフォーマットのファイルでも受け入れるように適合されている。しかしながら、これは記憶デバイスではなく、単にリンク手段に過ぎない。ＨＴＭＬファイルをそのオリジナル・コンテクストから移動させる場合、これらがリンクされているコンテンツは、ＨＴＭＬファイルと共に移動させられるのでなければ、表示しない。

タイルファイル・パッケージの方が、コンテクスト間を容易に漂浪(roam)することができる。何故なら、これは主要プレゼンテーション・エレメントおよび更に別のプレゼンテーション・エレメントを収容し、ヘッダ内に全ての連鎖も保持することができる（または少なくともその関連のストアを発見することができる）ので、他のタイルファイル・パッケージの内どれをそれが「用い」、他のタイルファイル・パッケージの内どれがそれを「用いている」かが分かるからである。全ての関連付けがヘッダに格納されていない特殊な場合では、必要に応じてタイルファイル・パッケージをこれらの関連付けで更新するか、またはこれらに遠方からアクセスすることができる。

図３を参照すると、どのように双方向リンクが動作するかの表現が示されている。

タイルファイル・パッケージは、双方向リンクの形成を通じて、他のタイルファイル・パッケージを参照することができる。タイルファイル・パッケージは、他のタイルファイル・パッケージを「用いている」か、あるいはそれによって「用いられている」かのいずれかである。これが意味するのは、タイルファイル・パッケージは、潜在的に、それが一部をなすグルーピングの全てを「知っており」、更に書くグルーピングのシーケンスまたは階層におけるその位置も知っているということである。

再度図１ａを参照すると、双方向リンクは、プレゼンテーションの目的のためにメディア・ファイルの共有もし易くする。タイルファイル・パッケージは、０個以上の双方向リンクを、他のタイルファイル・パッケージに対して有することができる。

各リンクは、次のことを記述する。

（１）リンク・タイプ−リンクの他端においてタイルファイル・パッケージを「用いている」（主リンク）か、またはタイルファイル・パッケージに「用いられている」（副リンク）。言い換えると、タイルファイル・パッケージが他のタイルファイル・パッケージにリンクされている状況では、オリジナル・リンクが主リンクであり、他のタイルファイル・パッケージから逆にオリジナル・タイルファイル・パッケージに達するリンクが副リンクとなる。これによって、リンクが動作する順序が確定するので、各タイルファイル・パッケージは、タイルファイル・パッケージの階層におけるその位置がわかる。

（２）経路−リンクの他端におけるタイルファイル・パッケージの名称および経路（必要なときにはいつでも）。

（３）用いられる資産の選択肢リスト。「用いている」場合、リストは他のタイルファイル・パッケージの資産を示す。「用いられている」場合、リストは、現タイルファイル・パッケージの資産を示す。リストが空である場合、または指定されていない場合、デフォルトで、「用いられている」タイルファイル・パッケージの面画像が（唯一の）用いられている資産であると仮定する。

図４を参照すると、タイルファイル・パッケージがどのようにして二進ファイルにおけるメディア位置を参照するかの概略例が示されている。矢印は、ヘッダに格納されている値から、二進ファイルにおける実際の位置までを指し示す。

図５は、タイルファイル・パッケージがどのようにしてタイルファイル・パッケージの面に対するメディア・コンテンツを参照するかを示す。面、または面の最適化バージョンは、素早いダウンロードに利用できるので、タイルファイル・パッケージをＧＵＩにおいて素早く表すことができる。バックグラウンドにおいて徐々に大きな資産をダウンロードするように設定することもできる。

タイルファイル・パッケージは、管理し易くダウンロードできるように、更に小さな区間に区分することもできる。ヘッダ内の値（クライアント・マシン上におけるローカル・ヘッダ）は、二進ファイルにおける実際の位置を指し示す。

図６を参照すると、ＨＴＭＬページの更に別の問題は、ページを全ての資産と共に新たなコンテンツに移植することに成功したとしても、そのページに以前にリンクされていたあらゆる他のページやサイトが行き詰まってしまい、リンクが破断することである。しかしながら、タイルファイル・パッケージのネットワークでは、１つのタイルファイル・パッケージは、それが用いているタイルファイル・パッケージが位置またはコンテクストを変更しても、これらのタイルファイル・パッケージを配置し直すことが、殆ど常に可能である。これを遂行するには、双方向リンクを使用する。

図６ｂを参照すると、タイルファイル・パッケージは双方向にリンクされているので、その関係は、位置の変更をものともせず、以下の例によって例示するように、位置には依存しない。

図７を参照すると、タイルファイル・パッケージのグルーピングを新たなサイトにコピーして、サイト内部で実行する。これは、タイルファイル・パッケージの各々が、それらの関係を知っている内蔵エンティティであるからである。

図７ｂを参照すると、タイルファイル・パッケージの単一のタイルファイル・パッケージのグルーピング（または更に大きなグルーピングの部分集合）をあるサイトから別のサイトに移動する場合でも、遠方よりその関係にアクセスし「使用する」ことができる。

図８を参照すると、異なる関数でもタイルファイル・パッケージを作成できる(ascribe)ことを示す。図８は、タイルファイル・パッケージに潜在的に可能な４つのサブクラスを示す。

（ｉ）メディア・タイルファイル・パッケージ(media tilefile package)
これは、基本的なコンテナである。

（ｉｉ）メニュー・タイルファイル・パッケージ(menu tilefile package)
メニュー・タイルファイル・パッケージは、面を除いて、通常空である。メニュー・タイルファイル・パッケージは、タイルを「グリッドのグリッド」(grid of grids)に編成することを可能にする。メニュー・タイルファイル・パッケージは、グリッドまたはパターンにおいて、メディア・タイルファイル・パッケージと共に表出することができる。しかしながら、メニュー・タイルファイル・パッケージは、選択された場合、最終的にメディア・タイルファイル・パッケージに到達するまで、メディア・タイルファイル・パッケージのサブ・グルーピングを、または更に別のメニュー・タイルファイル・パッケージのサブ・グルーピングを開く。

また、メニュー・タイルファイル・パッケージは、一時的に、または長期間、またはデフォルトの設定値として、メディア・タイルファイル・パッケージのグリッド全体を、大きな単一画像（通常、メニュー・タイルファイル・パッケージの面上の画像）と置き換えるように命令することができる。メニュー・タイルファイル・パッケージは、タイルファイル・パッケージ・アプリケーションの特性を設定するため、そしてインターフェース全体の「スキン」(skin)（外観およびレイアウトを含む）を変更するためにも用いることができる。このように、タイルファイル・パッケージが、他のユーザのアプリケーションＧＵＩの好みおよび／または外観を修正、設定、またはリセットするように、一人のユーザがメニュー・タイルファイル・パッケージを他のユーザと共有することができる。

（ｉｉｉ）メディア＋メニュー・タイルファイル・パッケージ
これは、メディア・タイルファイル・パッケージおよびメニュー・タイルファイル・パッケージの混成であり、ファイルはメニュー項目として機能するが、それ自体の権利(right)ではコンテナとしても機能する。メニュー・タイルファイル・パッケージは、面および関係を除いて、通常空であるが、メディア＋メニュー・タイルファイル・パッケージは、いずれかのメディア・タイルファイル・パッケージを満たすことができると、満たすことができる。

（ｉｖ）「ダミー」タイルファイル・パッケージ("dummy" tilefile package)
ダミー・タイルファイル・パッケージは、双方向リンクを保護し再確立するために存在する。タイルファイル・パッケージを、あるサイトの階層における別の位置に移動させると、異なる問題が生ずる。関係は同じままであるが、位置が変化している。図９ａ〜図９ｅは、単純な解決法を示す。図９ａにおいて、位置の移動が生ずる。図９ｂは、双方向リンクが破断する可能性があるという問題を示す。図９ｃは、解決法を示す。ダミー・タイルファイル・パッケージが自動的に「ミドルマン」(middleman)として挿入され、これが新たな場所への道を瞬時に指し示す。次いで、時間と共に、保守手順により、全てのリンクを新たな場所の対に誘導し直すことができる。これを遂行し終えると、ダミー・タイルファイル・パッケージを自動的に削除することができる（図９ｄ）。図９ｅは、（図９ａのような）ステータス・クオ(status quo)を復元したことを示す。

図１０に示すように、タイルファイル・パッケージは、当該タイルファイル・パッケージが搬送（所蔵）するまたは知っている（リンクする）メディア・ファイルを含むおよび／または順次処理するプレゼンテーションを収容することができる、および／または収容するようにプログラムすることができる。ファイル・タイプが発展するに連れて、最終的にマルチ・トラック能力(multi-track capabilities)を備えたプレゼンテーションを提供する（図１０ａ）。多数の面（タイルの前面）を順次処理してスライド・ショーおよびマルチ・クリップ・ビデオ・プレゼンテーション（ならびに、これら２つのあらゆる混合物）を作成することは、プレゼンテーション機能の単なる部分集合に過ぎない（図１０ｂ参照）。

グラフィカル・ユーザ・インターフェース
メディア・パッケージのタイルファイル・パッケージの実施形態は、多数のアプリケーションを跨ってそしてその内部に実装し、タイルファイル・パッケージのグラフィカル・ユーザ・インターフェースが、表示するタイルファイル・パッケージのコンテンツ、利用するオペレーティング・システム、または第三者のコンテンツの参照には無関係に、認識可能のまま維持するように設計されている。個々にそして集合的に、タイルファイル・パッケージは、移植可能なクロス・プラットフォーム・オペレーティング・システムとして振る舞う、視覚的に均一な「シェル」を形成することができる。図１２を参照すると、多数のタイルファイル・パッケージは、各々、ユーザ・インターフェースにおける種々のパネル(panel)（Ａ、Ｂ、Ｃ、Ｄ）において単一の画像によって表すことができる。インターフェースにおいては、表示画像（タイルファイル・パッケージの「タイル」即ち「面」）上での作用が、メディア・パッケージ上の作用を全体として伝達する。例えば、ユーザ・インターフェース内の表示画像をグループ化またはリンクすることにより、１つよりも多いメディア・パッケージをグループ化またはリンクすることができる（図１４Ａ、参照番号４０）。即ち、ユーザ・インターフェースのレベルにおいて表示画像（面）をグループ化またはリンクすることにより、物理ファイル（タイルファイル・パッケージの物理コンテナおよび論理コンテナ形態双方を含む）間で参照または収容する情報がグループ化される。

表示画像は、グリッド状パターンで、または多数の画像のその他の何らかのグルーピング、クラスタ(cluster)、またはタブロ(tableau)としてグループ化することができる。ユーザ・インターフェースにおいて画像を移動させることにより、パッケージをパッケージのグルーピング内における新しい位置に、あるいはあるグルーピングから別のグルーピングへ、および／またはあるシーケンスから別のシーケンスに移動させることが可能となる。これにより、パッケージとそれらの構成エレメントとの間に新たな相互関係が生ずる。

メディア・パッケージ間の関係を変更するには、タイルファイル・パッケージ・ユーザ・インターフェースを通じて行う。

タイルファイル・パッケージには「面」が設けられている。面とは、タイルファイル・パッケージのアイコンまたはサムネイル表現として設けられる視覚的エレメントである。また、面は、タイルファイル・パッケージがプレゼンテーション・シーケンスにおいてデフォルトに指定されているエレメント、即ち、特に指定されない場合のエレメントも表し、デフォルト・プレゼンテーション・エレメントとは、タイルファイル・パッケージの「面」によって表されるエレメントである。

ボタン(button)の少なくとも部分集合は、標準的な挙動を有する。例えば、「タイルの背面」(back of tile)領域（図１４Ｂの参照番号３１）、またはタイルファイル・パッケージ（３）の面以外の他のビュー(view)を明示するボタンがあり、添付ファイル、セキュリティ優先順のような補助的エレメントへのアクセスを与え、更にプレゼンテーションの編集（図１６の（５０））、あるいはタイルファイル・パッケージ・プレゼンテーションおよび／またはメソッドおよび／または関数および／または挙動をユーザが修正することができるスクリプト作成言語のような補助的プロセスへのアクセスを与える。

図１３は、タイルファイルのためのグラフィカル・ユーザ・インターフェースを示す。参照番号０１は、タイルファイル・パッケージの面（「タイルの面」）を示す。４タイルの面の４つの水平セクタ（０２）のいずれか１つの上でマウスを操作すると、４つの水平バーの１つが現れ、各バーは異なる機能に仲介するボタンとなっている。これらのバーを並べる順序は主観的事項であり、ユーザが、ユーザ設定または好みとして選択可能とするとよい。

図１３（０２）における例では、下位のバー（２０）は、タイルに関連するテキスト・タイトルを明示するタイトル・バー(title bar)である。また、これはドラッグ・バーでもある。即ち、この領域の全部または一部の上にマウスを位置付けると、タイル全体を１つのコンテクスト（例えば、１つのパネルＡ、Ｂ、ＣまたはＤ（図１２））からドラッグし、他のコンテクスト（例えば、異なるパネルＡ、Ｂ、ＣまたはＤにおけるグリッド）内に関連付けることができる。

下から２番目のバーは、「プレイ」バー(play bar)（１８）である。このバーの上にマウスを位置付けてマウスをクリックすると、視認のためにタイルが拡大され、面に時間の次元がある場合（例えば、開始点から終点まで再生するビデオ・クリップ）、拡大タイルが始まり、その時間に基づくコンテンツを公開する。

同様に、一連の面を選択して順次再生する場合（図１４Ａ、参照番号４０）、その一連におけるタイルのいずれか１つの上でプレイ・バーを選択することができ、一連のタイルはそのタイルから先に再生し始める。再生の間、これらのタイルの少なくとも面は、スライド・ショーまたは混成スライド＋ビデオ（あるいは、その他の時間基準メディアまたはウェブ・コンテンツ、例えば、ＲＳＳフィード）ショー）の形態のように、互いに編集される。例えば、写真またはスライドのような静止画像は、例えば、３秒間のデフォルト時間期間、再生中に呈示することができる。このタイル・シーケンスの表示は、一時的に下地のグリッド（図１３の＃０８）を隠すように、拡大したウィンドウ内で行うことができる。

下から３番目のバーは「サークル・メニュー」制御部("circle menu" control)（図１３の参照番号１４）である。このバーの上でクリックすると、タイルの面の周囲にサークル・メニューが表示される（図１３の参照番号２２）。

バーは、主に、タイル（面または背面）をどのように表現するか（例えば、インターフェースにおけるその相対的な表示サイズ）を制御し、一方サークル・メニューは、主に、メディア・パッケージのコンテンツの全体としての編集を制御する。この例では、サークル・メニューは、パッケージ全体のクローン(clone)を作成するためのボタン、パッケージを共有するためのボタン、別個のポップ・アップ・ウィンドウにおいてパッケージの少なくとも面を開くためのボタン（この機能は、厳格には全体パッケージ機能ではないので、代わりにバーによって仲介することもできる）、タイルファイル・パッケージを順次処理したのはどのプレゼンテーションであったかについて特殊な探索を行う（「スパン」探索）ためのボタン、あるコンテクストから別のコンテクストにパッケージ全体を移動させるためのボタン、あるいはパッケージ全体を削除するためのボタンを備えている。

ボタンからの４番目のバー、即ち、一番上のバー（図１３の参照番号１０）は、グリッドにおけるそのコンテクスト（または別のコンテクスト）の外にタイルを拡大し、タイルファイル・パッケージのオーサリング、視認、操作、または寄与(contributing)に合わせて粒度を高めた選択肢を表示可能なサイズにするためのボタンである（これらの粒度を高めた選択肢に対するボタンは、図１４Ｂにおいて、参照番号３０および３１で示されている）。この機能性は、＋／−シンボルによって表されている。即ち、タイルが小さいときには拡大し、既に大きくなっているときには再度縮小する。

タイルファイル・パッケージは、多数のファイル・タイプおよびコデックを含み、異種コンテンツのユーザ体験を簡略化または増幅することができ、またオブジェクトおよびコンテンツの異種形態を順次処理し編成して、このコンテンツをグリッドおよびシーケンスで公開することもでき、ユーザ・インターフェース・レベルでは、ユーザ・インターフェースの本質的に同じタイプがユーザに公開され、「場面の背後」で何が行われていようと無関係である。

ユーザ・インターフェースは、前述のメディア・パッケージに特にその用途を見出すが、多数のアプリケーションに跨って、そして種々の第三者データベース、データストア、または共有コンテンツのレイヤに対する万能フロント・エンドとしても利用することができる。以降の説明では、「表面」(surface)タイルファイル・パッケージおよび「深さ」(depth)タイルファイル・パッケージについて言及する。これらの用語は、第三者コンテンツ（タイルファイル・パッケージ自体はコンテンツを保持しておらず、単にコンテンツへの導線として作用するので、「表面」タイルファイル・パッケージと呼ぶ）および「深さ」タイルファイル・パッケージを表示し管理するときのユーザ・インターフェースを記述するために案出された。ここで、タイルファイル・パッケージは、ここに記載するメディア・パッケージを表示および管理している。

エンド・ユーザに対して、タイルファイル・パッケージのコンテンツには関係なく、タイルファイル・パッケージの各面が、当該面に集約または参照するあらゆるコンテンツへのアクセス・ポイントを設け、１組の熟知しているボタンが標準的な挙動を呈示し、そのコンテンツおよびメソッド等の熟知している編成において、タイルファイル・パッケージのその他の部分へのアクセスを可能にする。

タイルファイル・パッケージのグラフィカル・ユーザ・インターフェースは、実際には、共通のユーザ・インターフェースに共通の制御および予測可能な挙動を設けるように設計されており、各メディア・パッケージおよび／または第三者情報ストア内に収容されているファイル・タイムには無関係である。即ち、グラフィカル・ユーザ・インターフェースは、全てのタイルファイル・パッケージにわたって、したがって多数のアプリケーションおよびコンテクストにわたって、一貫性のある「ビジュアル・リテラシ」の１単位を形成する。

タイルファイル・パッケージは、それらの副エレメント間にアプリケーションを含むことができ、タイルファイル・パッケージのユーザが定めた形態に、コンテンツを「呼び込む」能力ならびに特定的な表示方法および特性を含む、それら自身の唯一の挙動および品質をコード化するために、ユーザにはスクリプトが利用可能となっている。

タイルファイル・パッケージは、増大しつつある数の異種エレメントを収容し集約する手段、およびこれらのエレメント間の関係を修正する手段も有する。

更に、移動電話機およびデスクトップＰＣを含む多数のソースから構成エレメントを受け取ってタイルファイル・パッケージに入れることができる。このように、各タイルは、インターネットと移動ネットワークとの間に集積ハブを形成する。

各タイルファイル・パッケージは、通常、単一の画像として表される（この文脈における画像は、写真、ビデオ・クリップ、アニメーション、グラフィック・エレメント、アイコン、およびテキストの一部を含むものとして定める）。これらの表示画像の操作を通じて、タイルファイル・パッケージ全体を、表示画像のグループ化または関連付けによって、グループ化またはリンクすることができる。フォルダにおけるファイルのグループ化や、フォルダ内における複数のフォルダとは異なり、タイルファイル・パッケージをグリッドのようなパターンにグループ化することにより、複数の画像が得られ、これらをタブロ（画像のグリッドまたは画像の断片のような）に表示することができる。タブロ内では、映像全体が情報を提供し、その個々の部分または映像の総和よりも大きな意味を生成することができる。

各表示画像がその構成資産のみを表しつつ、同時にグリッドのような、タブロにおける他の表示エレメントとの環境において公開されているという事実から、タイルファイル・パッケージ間において増々複雑化する関係を特定することが可能となる。

したがって、これらの画像は二重の機能を有する。グリッドまたはタブロのレベルでは、これらは合体して表示エレメント間に視覚的相互関係を形成する。また、これらは、情報資産のグルーピングに対するマーカとしても役立つので、ユーザが個々の画像をタブロから選択すると、これらは単にファイルおよびフォルダの寄せ集めで公開されるのではなく、グラフィカル・ユーザ・インターフェースとなって公開され、その中で、パッケージ（タイルファイル・パッケージ）における構成資産間の関係を、多数のソースおよびデバイスから修正することができ、構成資産はアプリケーションを含むこと、または参照することもできる。

収容または集中されているアプリケーションは、サービスとしてではなく、コンテンツ（「タイルファイル・パッケージ」）として販売することができる。これには商業上の利点があり、消費者は、コンテンツ（例えば、ムービーまたは歌の提供）の方がサービス（例えば、歌を類別し保持するように構成されているウェブサイト）よりも容易に応答することができる。言い換えると、多数のコデックと同様、タイルファイル・パッケージを通じて、多数のサービスをユーザに提供することができ、ユーザの側には特殊な知識は全く必要でない。これによって、提供業者のユーザ／消費者に対する関係が簡素化する。

更に、タイルファイル・パッケージは、情報管理システムおよびコンテンツ集約システムとして機能するだけでなく、タイルファイル・パッケージのグリッドのような、タブロの更に大きなプレゼンテーション・テクストにおけるマクロ・プレゼンテーションとしても機能することができる。個々のタイルファイル・パッケージはいずれも、他のタイルファイル・パッケージのエレメントを含むプレゼンテーションを収容または参照することができる。このプレゼンテーションのデフォルトの形態は、タイルファイル・パッケージ面である。これは、ウェブの「ブラウジング」の代用となる。多くの情報ページをブラウズする代わりに、更新情報を参照するようにタイルファイル・パッケージのグリッドを編成すればよい（同様に、タイルファイル・パッケージ内に収容されているコンテンツの更新は、当該タイルファイル・パッケージが一部をなすいずれのプレゼンテーションにも伝搬することができる）。同様に、ＲＳＳフィードを参照すること、またはタイルファイル・パッケージに組み込むこともできる。

例えば、グリッドにおける１つのタイルは、ニュース報告更新(updating news report)とすることができ、次が天気報告(weather report)とすることができ、次が新たな映画の評論(new movie review)とすることができ、次がスポーツ・ハイライト(sports highlights)とすることができ、次のいくつかのタイルファイル・パッケージが友人からのメッセージとすることができる。グリッド全体をシーケンスとして毎朝再生することにより、見る人に、彼らに関係するあらゆる情報を呈示することができ、多数の異なるウェブサイトにまたがって情報を「ブラウズ」する必要はない。言い換えると、グラフィカル・ユーザ・インターフェースは、メディア・タイプだけでなく、インターネットと新聞、テレビジョン、およびラジオというようなもっと古くからのメディアとの収束を含む、従来の収束の問題に対する強力な解決法を提供する。

異なるコンテンツ間における増々複雑化する関係を視覚的および直感的に識別することが可能である。何故なら、各表示画像はその構成資産のみを表し、同時にグリッドのような、タブロにおける他の表示エレメントとの環境において公開されて、表示エレメントの画像が有意なタブロを形成し、その主エレメントの合計よりも大きくなることができるからである。

ユーザに入手可能なタイルファイルは、ユーザによるアクセスが可能なあらゆるタイルファイル・パッケージの面で構成された平面グリッドの形態で、個々のタイルファイル・パッケージの集合体として視覚化することができる。面は、タイルファイルが収容するまたは参照する他のエレメントまたはメソッドに対する入力点を設け、他のタイルファイルまたはデータ、プレゼンテーション・データ、メディア、スクリプト、およびアプリケーション等に対するシーケンス関係を含むことができる。

コンテンツの探索
いずれの所与のタイルファイル・パッケージまたは関連するタイルファイル・パッケージを発見するためにも、探索フィルタを用いて、目視可能なタイルの部分集合に最終的に達するまで、グルーピング全体を狭めて、更に狭いグルーピングにする。図１４ｂにおいて、グリッドの周りにあるメニュー（４２）のハロー(halo)は、探索を最新のタイルに狭めるボタン、最後に修正したタイルに探索を狭めるボタン、タイトルまたは著作者または使用頻度が高い順によってタイルを順番に並べるためのボタン等を含む。同様に、（４６）における探索パネルは、部分集合を、ビデオである面のみまたは写真である面等に狭めることを可能にする。探索用語を入力することもでき、この探索用語を適用しようとしている判断基準にしたがって、探索を狭めることができる。目視可能な部分集合が戻され、次いで見る人は、この部分集合から、いずれか１つのタイルに収容されている関係または関連付けられている関係の知識を利用することができ、ユーザは作業して、このタイルファイル・パッケージから逆行して、例えば、プレゼンテーション・シーケンスの一部として特定的に関連付けられている他のタイルファイル・パッケージに移行する。

しかしながら、ユーザにはアカウントを与えることができ、グリッド構造内、およびグリッド内にあるタイルファイル・パッケージのグリッド内においてでも、タイルファイル・パッケージを配列することによって、これをカスタム化することができる。

タイルファイル・パッケージ・アカウントは本質的に探索可能なタイルの１つの平面タイルであるので、これらのタイルを分類に基づく下位グリッドに編成する場合、他のタイルファイル・パッケージに対するこれらの関係の知識を収容するが、実際には他のタイルファイル・パッケージを収容する必要がない、メニュー・タイル・パッケージを介在させることができる。したがって、メニュー・タイルファイル・パッケージ（例えば、グリッドのグリッド）を削除しても、必ずしも、このメニュー・タイルファイル・パッケージによって参照されるタイルファイル・パッケージが削除されることにはならない。これは、プレゼンテーション・モデルの利点の１つであり、タイルファイル・パッケージは（論理的および／または物理的に）これらの関係の知識を、例えば、双方向リンクを通じて収容する。

グラフィカル・ユーザ・インターフェースは、それ自体１つ以上のメニュー・タイルファイル・パッケージ、即ち、それが表示することができる全てのタイルファイル・パッケージを参照するタイルファイル・パッケージによって完全にまたは部分的に定めることができる。このように、インターフェースの多数の異なるレイアウトを、共有することができる多数の異なるメニュー・タイルファイル・パッケージとして実装することができる。例えば、一人の「パワー・ユーザ」がＧｒｉｄｏＭｏインターフェースのために代わりのレイアウトを作成する場合、彼らの一意に編成されたインターフェースを定めるメニュー・タイルファイル・パッケージ（複数のパッケージ）をこれらと共有することにより、その人は彼らの一意のレイアウトをＧｒｉｄｍｏ共同体全体と共有することができる。これを図１８において（６４）で示す。しかるべきタイルをこのインターフェースのヘッダ・バー内の位置にドラッグすることにより、変更を適用することができる。同様に、ヘルプ・ファイルおよびその他の命令マテリアル(instructional material)は、タイルファイル・パッケージによって仲介することができる。ヘルプ・タイルファイル・パッケージは、実行すると問題を特定し、恐らくは修復問題に関してでさえ報告するスクリプトをも収容することができる。

インターフェース・アニメーションおよびメニュー・タイルファイル・パッケージは、グリッドのグリッドのグリッドの中に一層奥深く（または浅く）進む（「飛ぶ」、「追跡する」または「ズームする」）インターフェースの幻想を作成するために用いることができる。しかしながら、同じ概念を簡略化した形式を、３つの主要レイヤに照会する(refer to)メニュー・タブとして適用することができる。これは、タイルファイルと効果的に双方向処理し操作するため、そして高速インターネット接続が入手できない場合にリソース効率を最大に高めるために必要な概念をユーザに習熟させるために用いることができる。

タブ(tab)のシステムは１つ以上の「パネル」に分割することができ、各パネルは少なくとも３つのレイヤ(layer)を有する（図１４ｂの番号２４、２４ｂ、２４ｃ参照）。「最も深い」グリッドを「カテゴリ」(category)と呼び（グリッドのグリッドのグリッド）、中間層を「グリッド集合」(GridSet)と呼び（グリッドのグリッドであり、ここでは、グリッドの各グリッドは、グリッド内の最初のタイルファイル・パッケージの面によって視覚的に表される。言い換えると、グリッドのグリッドは、繰り返し全ての補助グリッドの最初の面のグリッドとなる）、表面層を「グリッド」（または単に「タイル」）と呼ぶ（順次処理され、タイルファイル・パッケージの面のグリッドとして表示されるタイルファイル・パッケージのグループ）。

メニュー・タイルファイル・パッケージによって仲介することができる、このインターフェース概念の使用により、非常に大きな数のタイルファイル・パッケージを、単一のパネルにおいて探索しナビゲートすることができる。

例えば、あらゆるグリッド・マトリクスが３６個のタイルファイル・パッケージに制限される場合（即ち、６×６グリッド）、パネル全体では、３６×３６×３６＝４６，６５６個のタイルファイル・パッケージを参照することができる。

更に、スクローリング・グリッド(scrolling grids)を設けることができる。したがって、単一のパネルが非常に大きな数のタイルファイル・パッケージを参照することができる。更に、パネルを３つの層に限定しなければならない理由がない。しかしながら、３つのパネルは実用上の限度であり、これを超過するとナビゲーションが一層厄介となり、直感性が低下する。

次いで、多数のパネルを編成して、「ライブラリ」と呼ばれる、単純なパネルのリストにすることができる。

また、パネルが、単一レイヤにタイル、グリッド、およびグリッドのグリッドの双方を収容するグリッドのような、グリッドの混成バージョンを含むことも可能である。この場合、グリッド内の各画像には、印を付け、それがどの種のタイルファイル・パッケージであるか示す必要がある場合もある（即ち、普通のタイルファイル・パッケージ、グリッド、グリッドのグリッド等）。この種の更に任意の、その場だけのグリッドを「クランプ」(clump)と呼ぶ。

また、パネルは、「スパン」(span)と呼ぶ、タイルファイル・パッケージ・シーケンスの特別なカテゴリを含むこともできる。これは、部分的コンテクストにおけるタイルファイル・パッケージの素早いプレビューに適している。図１２の参照番号３８は、３つのスパンを示す。スパンは、特定的な新たなカテゴリおよびタイプの探索（スパンまたは「スパナ」(spanner)探索）によって生成することができ、特定的なタイルファイル・パッケージを探索して、それが一部をなす多数のプレゼンテーションの内数個を確定する。「スパナ」パネルを図１２の参照番号３６で示す。スパンの結果は、スパンしたタイルファイル・パッケージ（３６）の素早いプレビュー（３８におけるスパン）をし易くし、スパンが部分列(subsequence)であるグリッド全体のロードやプレビューを不要とする。

これは、特定のプレゼンテーション・シーケンスを解明するためにコンテクストの素早い指示のみを必要とするような探索者にとって、リソースの効率が高く、時間効率も高い。

スパンの結果は、一連の少なくとも３つのタイルファイル・パッケージ（図１２の参照番号３８）から成り、各シーケンスにおける中央のタイルファイル・パッケージは常に同一であり、スパナ・パネル内に表示され、スパン結果（３８）における直前および直後のタイルファイル・パッケージは、中央のタイルファイル・パッケージの多数のマイクロ・コンテクストの視認を容易にする。

中央面を繰り返し表す必要はない。スパンは、３つのタイルファイル・パッケージとして表すことができるが、実際には４つのタイルファイル・パッケージから成る。スパンにおける最初のタイルは、当該スパンが部分列であるグリッドにおける最初のタイルとすることができる。次に、スパンにおける２番目のタイルは、スパンが跨るタイルの直前のタイルファイル・パッケージであり、スパンにおける３番目のタイルファイル・パッケージは、スパンが跨るタイルファイル・パッケージに続くタイルファイル・パッケージである。

図１２は、（３８）におけるこの概念を示し、２番目および３番目のタイルがリンクされ、これらが所与の面に跨ることを示す。勿論、もっと多くの前後のタイルファイル・パッケージも、潜在的には表示することができ、スパン探索の主題であるタイルファイル・パッケージのコンテクストを広げることができる。

また、パネルは、アイコンが表すツールのグリッド（図１７の参照番号５６）も含むことができる。別の面上でツールをドラッグする（またはその逆）ことにより、特定のアクションまたはプロセスがそのタイルファイル・パッケージに適用されることになる。これらのツールはアイコンとすればよく、またはこれらは実際のタイルファイル・パッケージでもよい。このように、グラフィカル・ユーザ・インターフェースは、いずれの数の既存のアプリケーションまたは情報のストアに対するインターフェースでも形成する潜在的能力があり、全てのプロセスには「タイル・アクション上のタイル」が仲介する。

例えば、オーディオ編集アプリケーションでは、１つのタイルファイル・パッケージがオーディオ・ファイルを参照または収容することができ、ツールのグリッドにおける他のタイルはオーディオ・フィルタ・アルゴリズム(audio filtration algorithm)を参照または収容することができる。フィルタ・アルゴリズム・タイルファイル・パッケージをオーディオ・ファイル・タイル上にドラッグする（またはその逆）ことによって、フィルタリングしたオーディオ・ファイルを収容する新たなタイルを作成することができる。これを「結果」グリッドに表示することもできる。

コンテンツをタイルファイル・パッケージに編成することの基本的な利点の１つは、タイルファイル・パッケージの「面」が、静止画（例えば、写真）および動画（例えば、ビデオ・クリップ）の双方を混成プレゼンテーションへの順次処理を含むビジュアル・リテラシの一形態を与えることである。多数の面を順次処理することにより、シーケンスに基づくプレゼンテーションが可能となる。

更に、ユーザはその面を有し、それと集約し続ける他のコンテンツに「到達」(drill down)することができる。このように、タイルファイル・パッケージは、多数の異なるフォーマットで提供されるコンテクスト関連情報の集約および交換のために共通システムを提供する。

例えば、いずれのタイルファイル・パッケージにおいても、見る人は、その面に関連するコメントまたはそのタイルファイル・パッケージのコンテンツを記入することができる。これはブログ作成(blogging)と同様であるが、タイルファイルのグリッド編成のため、これを「グロッギング」(glogging)と呼ぶ。

更に洗練化した例では、ユーザ（またはシステム）は、グログ化したコメント(glogged comment)の全てを、それらのアカウントにおける全てのタイルファイル・パッケージ（またはそれらのアカウントにおける全てのタイルファイル・パッケージの部分集合）から新たなタイルファイルに組み立てるまたはコンパイルすることができる。これは、コメントのストリングが常にそれらの関連するタイルファイル・パッケージに収容されていることを除いて、従来のブログ（図１５の参照番号４８）として識別可能であり、したがって、コメントのストリング全体を、タイルファイル・パッケージの１つのコンテクストまたはグルーピングから別のコンテクストに移動またはコピーすることができる。更に、コメントのストリングがタイルに（論理的または物理的に）収容されるので、コンパイルしたブログ（グログ）を、タイルファイル・パッケージが許すいずれの判断基準（例えば、日付、著作者、主題等）によってでも、順序付けることができる。このコンパイルしたビューに添付されるコメントは、しかるべきタイルファイル・パッケージ内に添付され、したがって、コンパイルしたエントリのいずれのレベルでも添付することができる（単に最上位または最下位だけでない）。

したがって、グログは従来のコメント・リストとして目視することができるが、これは非線形でメッシュ状でない品質(non-linear, non-enmeshed quality)も有しており、コメントのグルーピング全体にアクセスし、探索し、賦課(task)することができ、いずれのコメントの読み手も、そのコメントを収容または参照するタイルファイル・パッケージを目視することを選択することができ、これによってそのコメントと関連付けられている他のコンテンツ全てにアクセスすることができる。

タイルファイルのユーザに対する他の利点は、タイルファイル・パッケージが、潜在的に、極めて多量のユーザには見えないメディア・タイプ全体（企業固有のファイル・タイプおよびコデックを含む）を作成し、これら絶えず増殖し続けるタイプの１つずつに対処する不便さから彼らを救済することである。ユーザの視点からは、プレゼンテーションは単にタイルファイル・パッケージに過ぎない。場面の背後で、タイルファイル・パッケージは、均一でその上なじみがある方法で、コンテンツ全ての収容、参照、コード変換、あるいはそれ以外での解釈または公開を管理または仲介する。グラフィカル・ユーザ・インターフェースを、それが収容および／または参照するいずれの前に置くことにより、均一性が導入される。このように原理を一元化することにより、メディアの収束を簡素化および高能率化し、通常のユーザが過度に複雑なプロセスに関与しなければならないことを軽減する。これによって、ユーザはプロセスではなくコンテンツに集中できるという利点がある。

図１２から図１９は、ブラウザ・ウィンドウにおいて見た場合の、グラフィカル・ユーザ・インターフェースの好ましいレイアウトの異なる図である。これらの図の各々において、インターフェースの主要な特徴を記述する目的のために、インターフェースの異なるエレメントがアクティブとなっている。

インターフェースは、３つの主パネル（Ａ、Ｂ、Ｃ）を備え、これらをタイルファイル・パッケージのグリッドに編成することができる（図１２におけるＡ、Ｂ、Ｃ）。これらのパネルの各々は、その直下にサブパネル（Ａａ、Ｂｂ、Ｃｃ）を有し、タイルに加えて、テキスト情報や、タイムラインおよび探索フィルタのようなツールを表示することができる。これらのパネルにおけるテキスト情報は、実際には、選択したタイルまたはグリッド内に収容されている情報のプレビューとすればよい。タイルの行（Ｄ）として編成されたタイルファイル・パッケージの第４のパネルがある。第４パネルは、移動デバイスから受信し、更に割り当てを必要とする可能性がある新たなコンテンツのための「保持用ベイ」(holding bay)として用いることができる。また、これは、最近目視したタイルの履歴として用いることもでき、あるいは、ライブラリ・コンテンツ、「お気に入り」タイルのようなその他の種々のコンテンツにアクセスし表示するため、あるいはパネルＡ、Ｂ、またはＣに現れる可能性があるグリッドであればそのいずれの行全体をも単に拡大するために用いることもできる。また、タイムライン、シーケンス・ライン、または追加のテキスト・ウィンドウとしても用いることができる。

いずれのタイルでも、エリアス(alias)形態でドック内までドラッグしそこにドロップすることができるので、このタイルをそのドックから逆に１つ以上の代わりのコンテクストにドラッグすることができる。

集中サービスでは、Ｄにおけるドック、またはいずれのタイル位置でも、新たな形態の「タイル」広告("Tile" advertising)のために用いることができ、この場合、タイルファイル・パッケージは広告を収容し、広告は、スクリプトおよびアプリケーション（例えば、ゲーム）を収容するその能力を含む、タイルファイル・パッケージの能力のいずれでも、または全てを利用することができる。

４パネル構成は単一パネル構成に対して、特にタイルのサブセットのファイル共有(file sharing)、メッセージング(messaging)、およびグループ化(grouping)について利点があるが、ここで説明した機能性は、実際、追加のまたは代わりのメニュー・システムの使用によって、単一パネルを用いれば達成することができる。移動電話機、ＰＤＡ、小型ノートブック型コンピュータ、あるいは恐らくはｉＰＯＤ^ＴＭまたはその他の何らかの移動マルチメディア・プレーヤのようなデバイス上においても見られるような、小型表示画面には、単一パネルの方が適している。これらのデバイスでは、タブのようなシステムが、多数のパネル間において移動することを可能にし、一度に１つのパネルのみが画面上に表示される。あるいは、果てしなく、グリッドのグリッドのグリッドというような層に侵入または「飛び込む」ことが可能な場合もある。

図１２から図１９に示すインターフェースでは、パネルＡは、その個別サイトのユーザ（ユーザ「Ａ」、「自分のタイル」(My Tiles)）に属する最新のタイルファイル・パッケージを常時表示する。パネルＢは、友人(friend)および家族(family)に属する最新のタイルファイル・パッケージを常時表示し、パネルＣは、ワークグループ、フォーラムのようなユーザの種々の「共同体」、あるいはニュース、音楽、または映画の評論のような加入サービスの最新のタイルファイル・パッケージを常時表示する。このように、単一のインターフェースが同時に１組よりも多いユーザのタイル（例えば、同時にパネルＡ、Ｂ、およびＣ）にアクセスすることができる。これは、従来のブログおよび共有サイトへの至上の手法であるが、タイルファイル・パッケージで構築しているからというだけでなく、グラフィカル・ユーザ・インターフェースがコンテクスト特定カテゴリに分けてユーザのタイルファイル・パッケージを表示し、ファミリからフレンドに、更にコミュニティに広がるからである。単一の画面内に、ユーザは、有意の情報のサブグループを共有し、再コンテクスト化し、再賦課することができる。

少なくとも３レイヤから成るパネルの概念に戻ると、深い「カテゴリ」レイヤの内左上のタイル位置には「全グリッド」(All Grids)と名称を付けるとよい。これは、このタイルを選択した場合、中央の「グリッド集合］(GridSets)パネルが所与のパネルにおけるグリッドの集合体全体を表示することを意味する。例えば、３×３または６×６マトリクスは、最新の９個または３６個のグリッドを表示し、ユーザは（３１）（図１２）においてボタンをクリックして、次の１組の９個または３６個のグリッドに進む（または次のラインにスクロールする）ことができる。グリッド集合レイヤにおけるこれらのグリッドの内いずれか１つが選択されると、表面タイル・レイヤは、次に、マトリクス・サイズが許す、選択されたグリッドのタイルのその部分集合を表示する。

グリッド、グリッド集合（グリッドのグリッド）、またはカテゴリ（グリッドのグリッドのグリッド）のデフォルトの編成は、日付によって最新から最古まで、またはその逆でもよい。しかしながら、パネル（４２）を包囲する「ハロー・メニュー」(Halo Menu)におけるサイド・メニューは、３つのレイヤのいずれにおいても、例えば、タイトル、修正日付、最も良く見られているものから、著作者、主題等によって、タイルファイル・パッケージの表示を濾過または並び替えするために用いることができる。

同様に、他のいずれのカテゴリであっても、レイヤを通って移動(journey)を開始することができるので、深いカテゴリ・レイヤは、初期システムまたはユーザが定めることが可能なエントリ・ポイントを形成するか、または濾過して全体としてタイルの集合体となる。他のカテゴリおよび／またはグリッド集合は、「家族」(Family)、「仕事」(Work)、「会員」(Members)、「自分の公表タイルファイル・パッケージ」(My Public tilefile packages)、「自分の個人的タイルファイル・パッケージ」(My Private tilefile packages)、「映画の評論」(Movie Review)、「ニュース・ストーリーズ」(News Stories)、「友人」(Friends)、「日本での休日」(holidays in Japan)等を含むことができる。いずれのレイヤにおいても、その層についての全てのコンテンツを収容するマスタ・タイルがあるとよい。更に深いレイヤにおいてマスタ・タイルを選択すると、事実上そのレイヤを迂回することになる（例えば、カテゴリ・レイヤにおいて「全グリッド」を選択することは、カテゴリ・レイヤを事実上迂回し、次の層において全てのグリッド素材が利用可能となることを意味する。）
３５におけるタブは、何を選択するかに応じて、異なる読み方ができる。例えば、「カテゴリ、グリッド集合、タイル」(Categories, GridSets, Tiles)。タブは、「家族」(Family)、「ユキコ」(Yukiko)、「シドニーにおけるユキコ」(Yukiko in Sydney)と読むことができ、これらがディスプレイ上のタイルにどのようにして達したか、そして表示されているタイルを変更するためにはこれらがどのレベルまで戻る必要があるか、即ち、これらは戻って「家族」に変更する必要があるか、または単に「ユキコ」になればよいのかについて瞬時的な階層記述をユーザに与える。

先に論じたように、この階層的ビューは、フォルダにおけるフォルダにおけるファイルの従来のディレクトリ・ツリーとは基本的に異なる。カテゴリおよびグリッド集合は、これらが参照するタイルファイル・パッケージを削除することなく、潜在的に削除可能である。

ある種のカテゴリおよびグリッド集合はシステムに属し、実用性の理由のために削除できない。例えば、「私の全てのグリッド」(All my Grids)というカテゴリを削除することはできない。これは、システムに属するマスタ・カテゴリと呼ぶことができる。

グリッドの特殊なカテゴリは、「兄弟グリッド」(Buddy Grid)または「チーム・グリッド」(Team Grid)、または「加入グリッド」(Subscription Grid)である。これは、ユーザＡおよび兄弟または友人、あるいはユーザＡおよびその家族、仕事のグループ、あるいはユーザＡの加入またはサービス関係に対して完全に個人的なタイルの部分集合である。例えば、Ｃにおいて選択するサービスは、特殊なタイルファイル・パッケージ（例えば、タイルファイル・パッケージの形態のヘルプ・ファイル）を個々の会員に割り当てることができ、あるいは目標とする加入素材(subscription material)の部分集合を割り当てることができる。各場合（兄弟グリッド、チーム・グリッド、加入グリッド、ヘルプ・グリッド等）において、これは、「イン」および「アウト」ボックスの代用である。互いのインおよびアウト・ボックスを満たす代わりに、ユーザＡおよびＢまたはＣにおける個人またはグループは、単にタイルファイル・パッケージをドラッグして、これらの友人あるいはそのグループまたはサービス関係に対して完全に個人的な共有グリッドにドロップするか、または著作(author)することができる。資産は、サーバ側に残ることができ、いずれが望ましくても、ダウンロード、ストリーミング、または選択的ダウンロードすることなく、予め見ることができる。ＡとＢまたはＣにおけるそれらとの関係をヘッダのリスト（電子メール・システムにおけるような）として表す代わりに、関係は、最新のタイルファイル・パッケージの視覚的タブロとして表される。

これは、退屈なテキストから、電話またはウェブカム(webcam)によって記録した「トーキング・アヘッド」(talking ahead)メッセージを含む、最新の面、写真、ビデオ、およびその他の画像の刺激的なタブロに強調を移す。タイルファイル・メッセージは、しかしながら、必要であれば、テキスト・メッセージを伝達するために用い続けることがえきる。兄弟、チーム、グループ、またはサービス等の配列は、実際、１つのアカウントが多数のサブ・サイトとして動作できることを意味する。この意味において、「ウェブサイト」および「ウェブページ」という用語は、もはや適切でない場合もある。ＧＲＩＤＭＯをウェブサイトと呼ぶ代わりに、ユーザは単に「ＧＲＩＤＭＯ」、「貴方のＧＲＩＤＭＯ」、「私のグリッドにタイルを入れる」等と呼ぶことが予期される。

関係グリッド(relationship grids)およびユーザの双方向処理の本質のグリッドとの関係により、コンテンツを容易にそして素早く分散することが可能となる。このようなシステムは、いわゆる「ウィルス性」(viral)促進および販売キャンペーンに用いるのに適している。何故なら、コンテンツが容易にユーザ間で受け渡されるからである。

いずれのパネルであっても、新たなタイルを作成するための空のグリッドまたは白いキャンバス、あるいは新たなグリッド（メニュー・タイル・パッケージ）として設定することができる。これは、ボタン「新」(new)（図１８の参照番号６２）によって遂行される。この場合、兄弟グリッド・プロセスと同様、種々のユーザおよびコンテクストから空白パネルにおけるコンパイル・グリッドに、ドラッグしてドロップするか、またはカットしてペーストすることができる。新たなタイルまたはグリッドを著作するプロセスの間、「新」ボタンはドラッグ・アンド・ドロップ・ハンドルとなる。これによって、オーサリングが行われているパネルからのコンテンツをドラッグして他のパネルの１つの上に位置付け、オーサリング・プロセスの間いずれのパネルにおけるいずれのコンテンツでもアクセスできる状態であり続けるようにし、更に同時にディスプレイ上の同じパネルの少なくとも２つのインスタンスを有することが可能となるようにする。これら３つのパネルの他のいずれの順列も、可能であり、ユーザ選択可能とするとよい。あるいは、多数の「浮遊」キャンバス(floating canvase)およびインスペクタ(inspector)を実施してもよい。

次いで、後に参照するために、タイルファイル・パッケージまたは新たなグリッドをセーブすることができる（６０）（そして、タイルファイル・パッケージまたはメニュー・タイルファイル・パッケージとして参照する）。ＨＴＭＬまたはＰＤＦのような適切なフォーマットでグリッドをエクスポートするために、フィルタが存在することも可能である。

いずれのグリッドであっても、これを開いて、コンテンツをドラッグおよびドロップすること、または並び換えることができるので、「セーブ」(save)ボタン（６０）を選択することにより、保存されているインターフェース内に新たな一連のタイルファイル・パッケージが得られる。

従属パネルＡａ、Ｂｂ、およびＣｃ（図１２）は、種々のツールおよび／または情報を表示するように設定することができる。例えば、所与の時間間隔（日付間隔）に沿って１つ以上のスライダ(slider)を設定することによって、タイルのフィルタリングを可能にするタイムラインを見ることができる。個々のタイルファイル・パッケージ、またはタイルファイル・パッケージのエレメントを探索することができ、探索の範囲は、１つ以上のボタンを（４６）において選択することにより、狭めることができる。タイルファイル・パッケージは、ドラッグしてスパン・ツール（ボタン３６において選択する）ドロップすることができ、スパンの結果(span results)（３８）を主パネルに表示して、このタイルを参照する種々のプレゼンテーション・グリッドのプレビューが可能となる。

グリッドにおけるタイルのいずれの部分集合でも、特定の順序で強調することができ、その部分集合を再生するようにすることができる（図１４Ａ、参照番号４０）。これは、「シフト」(shift)キーのようなキーを押下しつつ、所望の各タイル上にマウスを移動させクリックすることにより、行うことができる。この結果、着色またはその他の方法で強調したフレームが、選択した画像（４０）の周囲に現れる。

画像が強調されている間に「セーブ」ボタン（６０）を選択すると、これによって新たなグリッドを自動的に開き、このグリッドに、強調した一連のタイルを詰め込むことができる。図１６の参照番号５０は、タイルの「アップロード」(upload)画面を示し、ここでは、ユーザのハード・ドライブから直接情報をアップロードすることによって、新たなタイルを著作することができる。例えば、（５２）においてタイルの面をアップロードまたは変更することができ、（５４）において添付ファイルをアップロードすることができる。

図１４ｂにおいて、パネルＢおよびＣには、各々、タイルのグリッドで満たされているが、パネルＡは、パネルを満たすかまたは部分的に隠すためにいずれかのタイルを拡大してもよいことを示し、種々のメニュー・システムをこれらのタイルに、またはその中で適用することができる（１４ａにおける円形メニュー、パネルＢも同様）。

タイルを拡大して、それが生じたタイルのグリッドを隠すようにする場合、これらのタイルをリセットして、Ａａにおいて従属パネル内に表示することができる。このように、コンテクストに対する視覚的参照が維持される。例えば、パネルＡを９個のタイルの３×３マトリクスに設定し、１つのタイルが９個のタイル全てを隠す場合、他の８つの画像全てを、幅が６つ分のマトリクス(6 wide matrix)に表示するだけの十分な空間がパネルＡａにはある（そして、グリッドからの追加の４つの画像も表示することができる）。

メニュー・システムの一形態では、ユーザが彼らのマウスを（いずれのサイズの）インターフェース内のいずれのタイルファイル・パッケージ上に移しても、多数の水平制御バーの１つがオンに切り替わり、正確にタイルの中のどの水平細分割領域でマウスが「上で静止する」(hovering)のかに応じて、画像上に重なって現れる。これらのバーは、マウスがタイルのその特定領域の外側に移ると、再びオフに切り替わる。図１３では、説明を容易にするために、４本の水平制御バー（０２）が全て、パネルＡおよびＢにおける拡大タイル上に同時に示されている。通常、マウスがそのそれ以外の目視可能な位置の上に静止している限り、一度に１本の制御バーのみを示す。これらのバーの機能性の詳しい説明については、２８頁を参照のこと。

選択したアニメーションをタイルファイル・パッケージに適用すると、回転する、即ち、「裏返しになって」(flipping)その逆側を明示するように現れる。この「逆側」(reverse side)には、他の副画像、添付ファイル、セキュリティ・データ、ログ・コメント、およびその他のメタデータのような、種々のその他の資産および制御を明示することができる。タイルのクリエータは、見る人がタイルを「裏返す」(flip)ことができないように選択することもでき、その場合、フリップ・ボタンを不活性化するか、裏返すイベントをパスワードで保護するとよい。

タイルを裏返した場合、タイルの表面にある制御配列と同様の制御配列が、タイルの背面上で動作することができ、タイルを元に戻してその前面を再度明示することができ、更にタイルの前面に適用する拡大およびその他の種々のナビゲーション・プロセスを行うことが可能となる。この意味では、タイルの「背面」は、他の見る人によるテキスト・コメントの画像の追加、タイルに適用したセキュリティ・レベルの変更というような、タイルに対して行っている作成および保守に適用することができる種々のプロセスを仲介するメニュー・システムにおいて、直感的で高レベルの再分割を行おうとするインターフェースの概念である。

この制御メニュー（２２）のハローは、ユーザが関心のあるタイルから長い距離にわたってマウスを移動させ続ける必要はないことを意味する。タイルの周りの円内に現れるメニューまたはコマンドは、通例、タイル「上」で実行うることができるアクションを表し、タイル自体の動作環境「以内」で実行することができるアクションではない。言い換えると、ハロー・メニューに記載されているアクションは、全体としてパッケージに適用される。しかしながら、「共有」のようなメニュー項目の場合、タイル資産の特定の部分集合にアクションを制限することができるサブ・メニューがあるとよい。

いずれの場合でも、これらのアクションは通常タイル自体に対する変更には影響を及ぼさないが、タイル自体、またはタイル自体の複数の側面(aspect)に適用される。

種々の動作メニュー（図１４ｂの参照番号３０）またはボタンは、タイルファイル・パッケージの異なるレベルまたはレイヤに入ることができる。これらのメニューは、直接その特定のタイルに適用され、文書のようなファイルの添付、ファイルの除去、資産間の関係の変更、タイルへの注釈(commentary)の追加、ビデオ・クリップのインおよびアウト・ポイントのトリミング(trimming)等のような、そのタイルの「世界」(world)に対する種々の追加や変更を可能にする。また、これらのメニューは、必ずしもタイルのステータスを変更することなく、タイルの種々の側面の選択的抽出（例えば、ダウンロード）も可能とする。

タイルの（代表的）コンテンツの前面を連続再生するために、多数のタイルを選出し選択することができる。例えば、写真のグループを、単一のスライド・ショーとして再生することができ、あるいはビデオ・クリップのグループを、全て一緒に編集したかのように、再生するように設定することができ、あるいはビデオ・クリップとスライド・ショー・シーケンスの混成を選択し再生することもできる。

更に、タイルは、再生中におけるそれらの挙動を強調する、あるいはタイルを再生するかまたは選択したときに副プロセスをトリガする独特のスクリプトを収容することができる。

グラフィカル・ユーザ・インターフェースでは、個々のタイルにではなく、タイルのパネル全体、および、ユーザ・タイルファイル、他のユーザのタイルファイル、または恐らくはサーバのネットワークまたは何らかのサブ・ネットワークまたはサーバの部分集合におけるあらゆるタイルファイルであっても、その集合体全体に対して「署名」する機能、あるいは探索しフィルタ処理する機能というような、関連する機能に適用する、別のメニュー・システム（図１４ｂの参照番号２４、２６）があってもよい。これらのメニューは、オーディオ・ループのようなタイルまたは資産の種々のグローバル・ライブラリの探索、タイルの部分集合の作成およびセーブ、これらの部分集合の従来のウェブサイトと同様の公表、個々のタイル、サイト全体、または公表したページに対する種々の異なる「スキン」（外観）の適用、テレビ会議、チャット、またはメッセージング機能のオンへの切換、署名するための他の個人に対する電子メールの招待等を容易にすることもできる。更に、これらは、資産またはタイルを電話機またはその他の移動デバイスに押し戻す機能も容易にすることができる。

インターフェース（３つの主パネルの上にあるタイトル・バー）の「ヘッダ・バー」(header bar)は、サイトに対する種々の好みや設定を仲介するタイルファイル・パッケージの特殊なサブクラスを収容することができる。これらのタイルファイル・パッケージは、他のいずれとも同様に、共有することができるので、一人のユーザが他のユーザと彼らの好みや恐らくはスキンを共有することができる。

タイルファイルパッケージ・ファイル・タイプおよびグラフィカル・ユーザ・インターフェースのウェブサイト実施
タイルファイル・パッケージ生産物は、一実施形態では、「ＧｒｉｄＭｏ」（「グリッド」＋「移動」）と呼ばれるサービスとして実施する。ＧｒｉｄＭｏでは、タイルファイル・パッケージは、コンテンツ集約、公開、およびファイル共有ウェブサイトにおける表示および交換の単位を形成する。ＧｒｉｄＭｏは、共有またはメッセージング共同体であり、集中サービスのように、ウェブ系電子メール・サービスまたはブログに対する表面的な類似性を取り去る。しかしながら、ＧｒｉｄＭｏアカウントは、全体的にモジュール状である（タイルファイル・パッケージで構成されている）。ＧｒｉｄＭｏユーザ・インターフェース（ＧＭＵＩ）は、大部分が視覚的であり（タイルファイル・パッケージのグリッドに基づき、各々ＴＦＵＩのそれ自体のインスタンスを有する）、特に（写真またはスライドの）ビデオ・プレゼンテーション、「スライド・ショー」(slide show)に適しており、静止画像およびビデオ・クリップをまとめて順次処理して、混成ショーにすることができる。図１２から図１９は、ＧｒｉｄＭｏインスタンスの種々のビューを示す。

ＧｒｉｄＭｏでは、サーバにおいてタイルファイル・パッケージを形成する。写真、ビデオ・クリップ、およびテキストは、電子メール、ｍｍｓを含む移動電話機から、または専用アプリケーション（図１１参照）を介して、ＧｒｉｄＭｏ内に送ることができる。

例えば、ユーザが写真またはビデオ・クリップを彼らのＧｒｉｄＭｏアカウントに電子メールにて送信すると、ＧｒｉｄＭｏのデーモンはこのメッセージを受信し、それを処理するスクリプトを呼び出すことができる。このスクリプトは、画像を空のタイルファイル・パッケージ内に入れ、それをユーザ・アカウントにセーブし、ユーザが次にアクセスするとき、または彼らの表示をリフレッシュするときに視認する。

一旦このように写真またはビデオ・クリップを「空の」タイルファイル・パッケージの中に入れたならば、新たなタイルファイル・パッケージはアクセス可能となり、したがってハブを形成し、この中に他のコンテンツを集約することができる。例えば、ユーザが他のユーザにファイルを見ることおよび操作することを許可した場合、他のユーザも彼らの注記をタイルファイル・パッケージに書き込むことができ、彼ら自身の写真をタイルファイル・パッケージの本体に添付することができるので、最初の写真は、写真およびコメントの集合体のルーツを形成する（例えば、所与の主題について、ニュース・ストーリまたは結婚式のように）。

あるいは、クライアント側の他のアプリケーションも利用可能にすることができ、これを用いて、ユーザは多数のタイルファイル・パッケージをオフラインで取り込むことができる。

ＧＲＩＤＭＯアカウントはタイルファイル・パッケージの集成体(aggregation)を中心にして構築されるので、ＧＲＩＤＭＯサーバは、マシンに依存せず、単に「ＴＩＬＥＳＲＶＥＲ」の正しいバーションのインストールのみが必要となるようにするとよい。このサーバ・アプリケーションは、ＧｒｉｄＭｏのバックボーンとなる。

「Ｇｒｉｄ」および「ｇｏ」は、ＧｒｉｄＭｏサービスに添付されるサービス・プレフィックスであり、見る人が簡単にＤＮＳを介してサイト・サーバまでナビゲートすることができるようになっている。例えば、プレフィックス「ｇｒｉｄ」は、http://grid.gridmo.comのようなＵＲＬでは、ｇｒｉｄｍｏサーバを示し、ＵＲＬにおいてプレフィックス「ｗｗｗ」がウェブ・サーバを示すのと同様である。

個々のタイルファイル・パッケージを格納し、各ユーザ・サイトはデータベース上のフォルダとすることができる。各タイルファイル・パッケージは、データベース内において名称を有し、表示される資産は、リンク特性において設定される。例えば、?LinkAsset=14は、見る人を資産１４のレベルにおけるタイルファイル・パッケージに導く。

データベース構造は、必要に応じて、動的に作成されるので、タイルファイル・パッケージは、非集中即ち分散データベースの形態を拠り所とし、集中システムの落とし穴を回避する。

いずれのタイルファイル・パッケージ・データベースでも、物理層から離れて抽象化することができる。サーバ上の全てのファイルの位置は、潜在的にメモリに格納することができるので、ファイルに対する要求を素早く満たすことができる。特定のタイルファイル・パッケージが用いられている場合、または関係にある別のタイルファイル・パッケージを変更した場合、アクセスまたはインスタンス化する必要がある唯一の情報は、特定の関係グルーピングに関連し、そのグルーピングにファイル内に収容されている情報である。これによって速度が高くなり、探索時間が短縮し、冗長性が高まり、巨大なシステムをクラスタ化することが一層容易となる。

この手法に可能な実現例の１つに、Ｐｙｔｈｏｎ、Ａｐａｃｈｅ、およびＭｙＳＱＬを実行するＬｉｎｕｘサーバをあげることができる。この状況では、ＧｒｉｄＭｏサーバは、メモリ内に常駐して、Ａｐａｃｈｅモジュールとして、または単に単体プログラムとして実行する。

ＧｒｉｄＭｏサーバは、ポート８０に傾聴してＨＴＴＰ要求がないか調べる。ＨＴＴＰ要求は、次いで、解明されそれらの最終的な宛先に渡される。サーバ上の全てのファイルの位置はメモリに格納されているので、要求をファイルに素早く合わせることができる。ＭｙＳＷＬデータベースが、ファイル、位置および特性のリストを構築するために用いられる。再開時に、サーバはそのスタティック・メモリ（ＳＱＬ ＤＢ）から読み出し、タイル・ファイルおよびタイル名称および特性の関連付けアレイをメモリ内にインスタンス化する。これは、全てのファイルを格納し検索するための簡単で強力なシステムである。タイルファイル毎にパスワードを格納するか、あるいは別個のファイルでは、システムにパスワードを格納する。要求を受信すると、ＧｒｉｄＭｏサーバはファイルの特性をチェックする。ファイルが保護されている場合、サーバはログインおよびパスワードを要求する。一旦ユーザが検証されたならば、サーバはストリームをクライアント（ＧｒｉｄＭｏビューア）に作成し、クライアントはタイルを見ることができる。

タイルファイル・パッケージは、一般に、サーバにおいて作成されるので、この方法論のアクセスを制限すれば、ファイルにおけるいずれの知的財産でも保護される。何故なら、新しいファイルは、タイル・サーバを通じなければ作成できないからである。前述のように、「Ｔｉｌｅｆｉｌｅ ＰａｃｋａｇｅＰｒｏ」という名称のオフライン・ソフトウェア・アプリケーションを利用すれば、オンライン・ファイルだけでなくオフライン・ファイルも作成し保存することができ、タイルファイル・パッケージをインポートし、操作し、またはエクスポートするために、種々の他のアプリケーションを開発することができる。

ＧｒｉｄＭｏサーバは「薄いクライアント」(thin client)を組み込み、移動電話機およびスマート・デバイスからのコンテンツのアップロードを可能にすることができ、更に、これらのデバイスからのブラウズを容易にする層がある場合もある。

タイルファイル・パッケージおよびＧｒｉｄＭｏサーバの専門家向けバージョンであれば、種々の形態のディジタル権利保護を含むことができる。個々のタイルファイル・パッケージは、「ペイ・パー・ビュー」に基づいてのみ利用可能として、プレビュー（面）を提供するが、料金を受領しなければ、タイルの残りの部分へのアクセスを許可しないようにするとよい。

ディジタル権利保護は、ファイルのフォーマット内に構築することができる。ファイルの暗号を解読するために必要なキーは、ＧｒｉｄＭｏサーバ上に格納するとよい。見る人が彼らの個人キー（例えば、クレジット・カードの番号）を提供すると、ＧｒｉｄＭｏサーバはクライアントにキーを供給し、一旦ファイルの視認が完了したなら、クライアントからキーを消し去る。ファイルをセーブするには、更に、視認が可能になる前に、キーをサーバに送る要求を必要とするとよい。

ＧｒｉｄＭｏサーバ上において１つ以上のタイルファイル・パッケージを目視するには、ブラウザのプラグインの使用を必要とするようにするとよく、プラグインがなくてもそれを可能にしてもよい。

一実現例では、目視機能は、種々のコード・ライブラリの使用によって作成することができ、コード・ライブラリは下記を含むことができる。

・ＰＭＥＧ４ コデック（ビデオ）
・ＭＰＥＧ２ コデック（ビデオ）
・ＢＡＳＳサウンド・システム（Ｗｉｎｄｏｗｓ^ＴＭのみ可能）
・Ｏｐｅｎ Ｓｏｕｒｃｅ Ａｕｄｉｏ Ｌｉｂｒａｒｙ Ｐｒｏｊｅｃｔ（いずれのＯＳでも可能）
・ＩｍａｇｅＭａｇｉｃｋ（画像）
・リッチ・テキスト・ディスプレイ・システム
・フラッシュ・ディスプレイ・ライブラリ
・Ｓｈｏｃｋｗａｖｅディスプレイ・ライブラリ
少なくともＧｒｉｄＭｏの実施形態では、多数のタイルファイル・パッケージを単一の画像によってユーザ・インターフェースにおいて表すことができる。このインターフェースでは、表示画像上におけるアクションが、メディア・パッケージ全体としてのアクションを仲介する。例えば、１つよりも多いメディア・パッケージは、ユーザ・インターフェース内において表示画像をグループ化またはリンクすることによって、グループ化またはリンクすることができる（即ち、ユーザ・インターフェースのレベルにおいて表示画像をグループ化またはリンクすることにより、システムにおける下位レベルにおいてタイルファイル・パッケージのグルーピングが得られる）。表示画像は、グリッド状パターンのマトリクスとして、あるいは多数の画像のその他の何らかのグルーピング、クラスタ、またはタブロとしてグループ化することができる。ユーザ・インターフェースにおいて画像を移転させることにより、パッケージをパッケージのグルーピングにおける新たな位置に、または１つのグルーピングから他のグルーピングに移転させることができ、パッケージとそれらの構成エレメントとの間に新たな内部関係を生成することができる。

利点
以上の説明から分かるように、タイルファイル・パッケージは、コンテクスト間におけるグループ化、再グループ化、および交換するために存在する。タイルファイル・パッケージでは、異形のエンティティのモジュール状収容は、以下のプロセスを能率化し簡素化するように設計することが好ましい。

１．コンテンツを標準化されたコンテナに集約する。

２．操作を容易にするために、これらのコンテナを、直感的ユーザ・インターフェースにおいて表示する。

３．これらのコンテナをグループ化、格納、輸送、および交換する。

４．これらのコンテナによって、新たなクラスのウェブサイトを構築する。

５．これらのコンテナをアプリケーション間、ならびにオンラインおよびオフライン環境間で輸送する。

６．スマート・デバイス（電話機のような）およびインターネットをより良く統合する。

７．コンテナのコンテンツを表示し、可能であれば販売する。

８．グループ全体または一連のコンテナのコンテンツを表示する。

９．コンテンツを電話機に「押し出す」(push out)ことができる、新しいクラスのデータ・レポジトリを形成する。

タイルファイル・パッケージを用いると、インターネット・サイトは新しい形態の標準化を採用することができるので、静的なウェブ・サイトの代わりに、ディジタル世界全体にわたって、異種性が高い品目の均一なコンテナを有意にグループ化し、維持し、インポートし、エクスポートすることができるポートまたはハブに一層類似したサイトが提供される。タイルファイル・パッケージは、ビデオ・クリップのような、時間に基づくメディアの特定的な請求に対処するように設計されており、これらはウェブサイト、プレゼンテーション、ファイル共有、およびメッセージング間の境界を曖昧にする潜在的可能性を有する。タイルファイル・パッケージは、オンラインおよびオフライン双方の使用に合わせて設計されている（コンテナ船上、および陸上）。更に、コンテンツを集約する標準化されたコンテナとして、いずれの単一のタイルファイル・パッケージでも、種々のソースからのコンテンツ、例えば、移動電話機からの写真、そしてＰＣから入力したテキスト・コメントを受信することができる。これが意味するのは、タイルファイル・パッケージは、移動電話機とインターネットとの間の関係を徹底的に能率化できるということである。

本発明の好適な実施形態は、他のファイルを収容するファイル・タイプであったが、エレメントの有用な標準化されたサブ・グルーピングも、単一のファイルを格納していないデータ構造を用いて可能であることは認められよう。本発明の好適な実施形態は、コンテナ文書（ファイル・タイプ）としてのタイルファイル・パッケージについてであったが、ＧｒｉｄＭｏインターフェースは、もっと抽象的なエレメントのグルーピングにも適用することができる。尚、メディア・パッケージは、その最も広い概念において、この抽象化を含むことは理解されよう。

図１は、本発明の実施形態によるメディア・パッケージの構造を示す図である。 図１ａは、本発明の実施形態にしたがって、メディア・パッケージをどのようにリンクするかを示す図である。 図２は、メディア・パッケージのある場所から別の場所への移植性を示す図である。 図２ｂは、メディア・パッケージのある場所から別の場所への移植性を示す図である。 図３は、メディア・パッケージ間において双方向リンクがどのように動作するかを示す図である。 図４は、タイル・ファイルのヘッダおよびメディア区間をどのようにリンクするかを示す図である。 図５は、タイル・ファイルのヘッダおよびメディア区間をどのようにリンクするかを示す図である。 図６は、従来技術のＴＨＭＬ文書を本発明の実施形態によるメディア・パッケージと比較する図である。 図７ａは、本発明の実施形態によるメディア・パッケージの移植性を示す図である。 図７ｂは、本発明の実施形態によるメディア・パッケージの移植性を示す図である。 図８は、本発明の実施形態による、メディア・パッケージとグラフィカル・ユーザ・インターフェースとの間のリンクを示す図である。 図９ａは、本発明の実施形態によるメディア・パッケージ間の動的リンク処理を示す図である。 図９ｂは、本発明の実施形態によるメディア・パッケージ間の動的リンク処理を示す図である。 図９ｃは、本発明の実施形態によるメディア・パッケージ間の動的リンク処理を示す図である。 図９ｄは、本発明の実施形態によるメディア・パッケージ間の動的リンク処理を示す図である。 図９ｅは、本発明の実施形態によるメディア・パッケージ間の動的リンク処理を示す図である。 図１０ａは、本発明の実施形態によるメディア・パッケージ内に配することができるコンテンツのタイプを示す図である。 図１０ｂは、本発明の実施形態によるメディア・パッケージ内に配することができるコンテンツのタイプを示す図である。 図１１は、本発明の実施形態によるメディア・パッケージを生成するシステムとインターフェースすることができるネットワークのタイプの一例である。 図１２は、本発明の実施形態によるグラフィカル・ユーザ・インターフェースの図である。 図１３は、本発明の実施形態によるグラフィカル・ユーザ・インターフェースの図である。 図１４Ａは、本発明の実施形態によるグラフィカル・ユーザ・インターフェースの図である。 図１４Ｂは、本発明の実施形態によるグラフィカル・ユーザ・インターフェースの図である。 図１５は、本発明の実施形態によるグラフィカル・ユーザ・インターフェースの図である。 図１６は、本発明の実施形態によるグラフィカル・ユーザ・インターフェースの図である。 図１７は、本発明の実施形態によるグラフィカル・ユーザ・インターフェースの図である。 図１８は、本発明の実施形態によるグラフィカル・ユーザ・インターフェースの図である。 図１９は、本発明の実施形態によるグラフィカル・ユーザ・インターフェースの図である。

Claims (57)

1. メディア・パッケージであって、少なくとも１つのプレゼンテーション・エレメントを収容または参照できる記憶手段を備えており、当該メディア・パッケージ間においてプレゼンテーション・エレメントをリンクするために、別のメディア・パッケージと関連付けられている、メディア・パッケージ。
2. 請求項１記載のメディア・パッケージであって、更に、前記メディア・パッケージを少なくとも１つの他のメディア・パッケージと関連付け、前記メディア・パッケージ間においてプレゼンテーション・エレメントをリンクするように動作するリンク構造を備えている、メディア・パッケージ。
3. 請求項２記載のメディア・パッケージにおいて、前記リンク構造は、パッケージ間においてプレゼンテーション・エレメントをリンクするように、前記メディア・パッケージを複数の他のメディア・パッケージにリンク可能である、メディア・パッケージ。
4. 請求項２または請求項３記載のメディア・パッケージにおいて、前記リンク構造は、それが関連付けられている前記または各メディア・パッケージと双方向リンクを確立するように動作可能である、メディア・パッケージ。
5. 請求項４記載のメディア・パッケージにおいて、双方向リンクを確立するとき、前記リンク構造は、前記リンクに変数を含むように動作し、前記変数は、一方のリンクを主リンクとして定め、他方のリンクを副リンクとして定めるように動作する、メディア・パッケージ。
6. 請求項５記載のメディア・パッケージにおいて、前記主および副リンクのいずれか一方が、連続的なプレゼンテーションを形成するように、プレゼンテーション・エレメントをリンクしたシーケンスを確立する、メディア・パッケージ。
7. 請求項３から６までのいずれか１項に記載のメディア・パッケージにおいて、前記メディア・パッケージの移動または修正時に、前記メディア・パッケージは、前記メディア・パッケージのリンクの少なくとも部分集合を収容するダミー・ファイルを保持させ、前記メディア・パッケージを参照する前記他のメディア・パッケージが、前記メディア・パッケージの移動または修正によって影響を受けないようにする、メディア・パッケージ。
8. 請求項７記載のメディア・パッケージにおいて、前記ダミー・ファイルは、前記メディア・パッケージの複製である、メディア・パッケージ。
9. 請求項３から７までのいずれか１項に記載のメディア・パッケージにおいて、前記メディア・パッケージの移動または修正時に、前記メディア・パッケージは、当該メディア・パッケージを参照している他の全メディア・パッケージの全リンクを、前記メディア・パッケージの修正または移動を反映するように更新する、メディア・パッケージ。
10. 請求項３から６までのいずれか１項に記載のメディア・パッケージにおいて、前記メディア・パッケージの移動または修正時に、前記メディア・パッケージは、当該メディア・パッケージを参照している他のメディア・パッケージのリンクの少なくとも部分集合を、前記メディア・パッケージの修正または移動を反映するように更新する、メディア・パッケージ。
11. 請求項１０記載のメディア・パッケージにおいて、前記リンクの少なくとも部分集合を更新するのは、前記他のメディア・パッケージの１つが前記移動または修正されたメディア・パッケージにアクアセスしようとしたときにのみである、メディア・パッケージ。
12. 請求項１から１１までのいずれか１項に記載のメディア・パッケージにおいて、同様のメディア・パッケージを求めて探索を行う際に、前記探索は、前記メディア・パッケージによって参照されたメディア・パッケージの部分集合を戻し、該戻される部分集合を所定の判断基準によって判定する、メディア・パッケージ。
13. 請求項１から１２までのいずれか１項に記載のメディア・パッケージであって、更に、ヘッダ部と二進情報ストアとを備えており、前記ヘッダ部は、関連性情報を収容し、前記二進情報ストアは、前記少なくとも１つのプレゼンテーション・エレメントを収容する、メディア・パッケージ。
14. 請求項１から１３までのいずれか１項に記載のメディア・パッケージの配信方法であって、ユーザの要求に応答して、前記メディア・パッケージのコピーをユーザに送るステップを備えている、方法。
15. 請求項１から１３までのいずれか１項に記載のメディア・パッケージの配信方法であって、前記ヘッダ情報の少なくとも部分集合をエンド・ユーザおよび前記少なくとも１つのプレゼンテーション・エレメントの表現に配信するステップと、前記二進情報の少なくとも一部に対するユーザ要求に応答して、前記二進情報の少なくとも一部を前記ユーザに配信するステップとを備えている、方法。
16. 請求項１５記載の方法であって、更に、ユーザのコンピュータ・システムが実質的に停止している間に前記二進情報の部分集合をダウンロードするステップを備えている、方法。
17. プレゼンテーションの格納方法であって、請求項１から１３までのいずれか１項に記載のメディア・パッケージを複数提供するステップと、前記メディア・パッケージのそれぞれにおいて前記プレゼンテーションのプレゼンテーション・エレメントを格納するステップと、前記プレゼンテーション・エレメントを関連付けるように、前記メディア・パッケージをリンクするステップとを備えている、方法。
18. 請求項１７記載の方法であって、更に、前記メディア・パッケージを双方向にリンクするステップを備えている、方法。
19. プレゼンテーションにアクセスする方法であって、請求項１７または請求項１８記載の方法によって前記プレゼンテーション・エレメントを格納するステップと、前記メディア・パッケージのいずれか１つを介して前記プレゼンテーションにアクセスするステップとを備えている、方法。
20. 請求項１から１３のいずれか１項によるメディア・パッケージを著作し、編集し、格納し、配信するシステムであって、前記メディア・パッケージを格納可能なストレージと、前記メディア・パッケージに対するクライアント・アプリケーションからの要求の受信時に、前記メディア・パッケージを前記クライアント・アプリケーションに配信することが可能なソフトウェア・パッケージとを備えている、システム。
21. 請求項２０記載のシステムにおいて、メディア・パッケージを移動または修正するコマンドをメディア・パッケージから受信したとき、前記システムは、前記メディア・パッケージのオリジナル・リンクの少なくとも部分集合を収容したダミー・ファイルを保持させ、前記メディア・パッケージを参照する他のメディア・パッケージが前記メディア・パッケージの移動または修正によって影響を受けないようにする、システム。
22. 請求項２０記載のシステムにおいて、メディア・パッケージを移動または修正するコマンドをメディア・パッケージから受信したとき、前記システムは、前記メディア・パッケージを参照している他の全メディア・パッケージの全リンクを、前記メディア・パッケージの修正または移動を反映するように更新させる、システム。
23. 請求項２０記載のシステムにおいて、メディア・パッケージを移動または修正するコマンドをメディア・パッケージから受信したとき、前記システムは、他のメディア・パッケージの１つが、前記移動または修正したメディア・パッケージにアクセスしようとしたときにのみ、前記メディア・パッケージを参照している他の全メディア・パッケージの全リンクを、前記メディア・パッケージの修正または移動を反映するように更新させる、システム。
24. 請求項１６から２３のいずれか１項に記載のシステムであって、更に、前記格納されているメディア・パッケージを検討し、探索可能なインデックスをコンパイルすることが可能なサーチ・エンジンを備えている、システム。
25. 請求項１６から２４のいずれか１項に記載のシステムであって、コンピュータ・ネットワークを通じて相互接続されている複数のサーバを備えている、システム。
26. 請求項１から１３のいずれか１項によるメディア・パッケージを複数表示するためのグラフィカル・ユーザ・インターフェースであって、ユーザが選択可能な複数の表示部を備えており、ユーザに一意のメディア・パッケージの表現を収容する第１表示部と、他のユーザに一意のメディア・パッケージの表現を収容する第２表示部と、前記ユーザまたは他のユーザに位置のメディア・パッケージを著作、編集、または目視するように配された第３表示部とを含む、グラフィカル・ユーザ・インターフェース。
27. 請求項２５または請求項２６記載のグラフィカル・ユーザ・インターフェースであって、更に、前記表示部のいずれの１つに収容されているメディア・パッケージであっても選択することにより目視可能なメニュー・システムを備えており、該メニュー・システムは、その中に表示されているメディア・パッケージの表現を操作する機能性を提供する、グラフィカル・ユーザ・インターフェース。
28. 請求項２７記載のグラフィカル・ユーザ・インターフェースにおいて、前記メニュー・システムは、前記メディア・パッケージの表現の上に重なる、グラフィカル・ユーザ・インターフェース。
29. 請求項２８記載のグラフィカル・ユーザ・インターフェースにおいて、前記メニュー・システムは、前記メディア・パッケージの表現を横切るカーソルの移動によって呼び出す、グラフィカル・ユーザ・インターフェース。
30. 請求項２６から２９のいずれか１項に記載のグラフィカル・ユーザ・インターフェースであって、更に、前記複数の表示部の各々を包囲する第２メニューを備えており、該メニューが、その中に表されているメディア・パッケージを操作する機能性を提供する、グラフィカル・ユーザ・インターフェース。
31. 請求項３０記載のグラフィカル・ユーザ・インターフェースにおいて、前記メディア・パッケージの操作は、前記メディア・パッケージをコピーする機能、前記メディア・パッケージを編集する機能、前記メディア・パッケージを削除する機能、および前記メディア・パッケージを新たなコンテクストに移動する機能を含む、グラフィカル・ユーザ・インターフェース。
32. 請求項３１記載のグラフィカル・ユーザ・インターフェースにおいて、前記メディア・パッケージの表現の操作は、主プレゼンテーション・エレメントを目視する機能、および他のプレゼンテーション・エレメントのいずれかを目視する機能を含む、グラフィカル・ユーザ・インターフェース。
33. 請求項２６から３２のいずれか１項に記載のグラフィカル・ユーザ・インターフェースにおいて、ユーザのコマンドに応答して、前記プレゼンテーション・エレメントの表現は、前記表現から、前記メディア・パッケージの他の全てのプレゼンテーション・エレメントの異なる表現に変形する、グラフィカル・ユーザ・インターフェース。
34. 請求項３３記載のグラフィカル・ユーザ・インターフェースにおいて、前記変形は、前面から背面への、前記表現の仮想回転によって行われる、グラフィカル・ユーザ・インターフェース。
35. 請求項２６から３４のいずれか１項に記載のグラフィカル・ユーザ・インターフェースにおいて、前記第２表示エリアは、ユーザの部分集合のみによってアクセス可能なメディア・パッケージの表現を目視することに限定されている、グラフィカル・ユーザ・インターフェース。
36. 請求項２５から３５のいずれか１項に記載のグラフィカル・ユーザ・インターフェースにおいて、前記表示部は、少なくとも１つのメディア・パッケージの表現を収容し、該表現を予め規定したパターンで提供する、グラフィカル・ユーザ・インターフェース。
37. 請求項３６記載のグラフィカル・ユーザ・インターフェースにおいて、前記規定したパターンは、グリッド・パターンである、グラフィカル・ユーザ・インターフェース。
38. 請求項２５から３７のいずれか１項に記載のグラフィカル・ユーザ・インターフェースにおいて、前記グラフィカル・ユーザ・インターフェースのレイアウトを、選択したメディア・パッケージのコンテンツによって決定する、グラフィカル・ユーザ・インターフェース。
39. メディア・コンテンツを表示するように配された少なくとも１つの目視エリアを備えているグラフィカル・ユーザ・インターフェースであって、前記グラフィカル・ユーザ・インターフェースのレイアウトは、少なくとも部分的に、前記目視エリアの少なくとも１つに表示される前記メディア・コンテンツによって決定される、グラフィカル・ユーザ・インターフェース。
40. 請求項３９記載のグラフィカル・ユーザ・インターフェースにおいて、前記グラフィカル・ユーザ・インターフェースのレイアウトは、少なくとも１つのメニュー・システムを含み、該メニュー・システムの機能性を目視エリアに表示されるメディア・コンテンツによって決定する、グラフィカル・ユーザ・インターフェース。
41. 請求項４０記載のグラフィカル・ユーザ・インターフェースにおいて、前記メニュー・システムは前記目視エリアを包囲する、グラフィカル・ユーザ・インターフェース。
42. 請求項４０または請求項４１記載のグラフィカル・ユーザ・インターフェースにおいて、前記メニュー・システムは２つのサブ・メニューを含み、第１サブ・メニューはメディア・コンテンツを操作するための制御部を設け、第２サブ・メニューは前記インターフェ巣におけるメディア・コンテンツの目視を操作するための制御部を設ける、グラフィカル・ユーザ・インターフェース。
43. 請求項３９から４２までのいずれか１項に記載のグラフィカル・ユーザ・インターフェースにおいて、前記目視エリアの少なくとも１つを、メディア・パッケージの表現を表示可能な複数のサブ・エリアに分割する、グラフィカル・ユーザ・インターフェース。
44. 請求項３９から４３までのいずれか１項に記載のグラフィカル・ユーザ・インターフェースであって、更に、メディア・パッケージとインターフェースすることが可能なブログ作成手段を備えており、該ブログ作成手段がメディア・パッケージにおいてテキスト・コメントを編集可能である、グラフィカル・ユーザ・インターフェース。
45. 請求項１から１３のいずれか１項に記載の１つのメディア・パッケージの少なくとも部分集合をグラフィカル・ユーザ・インターフェースに配信するように構成された計算システムを備えている、複数のメディア・パッケージを目視するシステムであって、前記メディア・パッケージは、前記グラフィカル・ユーザ・インターフェースにおいて動作する少なくとも１つの特性を確立する際に用いられる情報を含む、システム。
46. グラフィカル・ユーザ・インターフェースをカスタム化する方法であって、前記グラフィカル・ユーザ・インターフェースのレイアウトおよび機能性を決定する情報を含むメディア・パッケージを作成するステップと、前記情報を収容した前記メディア・パッケージの少なくとも部分集合を、前記グラフィカル・ユーザ・インターフェースに配信するステップとを備えている、方法。
47. メディア・パッケージの作成方法であって、少なくとも１つのプレゼンテーション・エレメントを選択するステップと、前記プレゼンテーション・エレメントをメディア・パッケージの中に形成するステップとを備えている、方法。
48. 複数のメディア・パッケージを探索する方法であって、ユーザに関心のあるメディア・パッケージを選択するステップと、前記メディア・パッケージにリンクされる全てのメディア・パッケージを特定するステップと、前記リンクされているメディア・パッケージの少なくとも一部の表現を表示するステップとを備えている、方法。
49. 請求項４８記載の方法によって、前記リンクされているメディア・パッケージの少なくとも一部の表現の表示が、所定の判断基準に依存する、方法。
50. 複数のメディア・パッケージに収容されているプレゼンテーション・エレメントを一元化する方法であって、一連のメディア・パッケージを選択するステップと、前記選択したメディア・パッケージからプレゼンテーション・エレメントの部分集合を抽出するステップと、前記抽出したプレゼンテーション・エレメントの部分集合を収容する、別のメディア・パッケージを構成するステップとを備えている、方法。
51. 請求項１から１３までのいずれか１項に記載の１つのメディア・パッケージの少なくとも部分集合を受け取り、前記メディア・パッケージの少なくとも１つの部分集合をユーザに表示するように構成されたソフトウェア・アプリケーションを含むデバイスを備えている、プレゼンテーション配信システム。
52. 請求項５１記載のシステムにおいて、前記メディア・パッケージはストリーム化データを収容する、システム。
53. 請求項５２記載のシステムにおいて、前記ストリーム化データは、テレビ会議の呼のような、生ソースである、システム。
54. 請求項５３記載のシステムにおいて、前記ストリーム化データは、前記メディア・パッケージ内に収容されている一連のプレゼンテーション・エレメントを含み、前記一連のプレゼンテーション・エレメントを順次公開する、システム。
55. 複数のユーザにコンテンツを分散する方法であって、請求項１から１３までのいずれか１項に記載のメディア・パッケージを組み立てるステップと、前記メディア・パッケージを多数のユーザに分散するステップとを備えている、方法。
56. 自己実行メディア・プレゼンテーションをユーザに提供する方法であって、少なくとも１つのプレゼンテーション・エレメントをグループ化して、請求項１から１３までのいずれか１項に記載のメディア・パッケージにするステップと、前記メディア・パッケージをユーザに提供するステップとを備えており、ユーザは前記少なくとも１つのプレゼンテーション・エレメントを目視することができる、方法。
57. テレビ会議方法であって、テレビ会議を開始することが可能なスクリプトを含むメディア・パッケージを提供するステップと、タイルをユーザに転送するステップとを備えており、ユーザによる受信および確認時に、前記テレビ会議を開始する方法。

Images