JP3790674B2 - 共同マルチデバイス・ウェブ・ブラウズのシステムおよび方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、全般的には、コンテンツのウェブベース・ブラウズに関し、具体的には、コンテンツのうちで、複数のユーザ位置の１つに選択的に供給される部分のユーザ表示および対話に関する。
【０００２】
【従来の技術】
グループウェア・アプリケーションは、複数のリモート位置から単一の文書に対して行われる共同作業の必要をサービスするために開発された。たとえば、複数の会社従業員が、全世界のめいめいのオフィスからプレゼンテーションを見ることができ、複数の学生が、めいめいのリモート位置にあるワークステーションから教授の講義に「出席」することができる。ほとんどの入手可能なグループウェア・アプリケーションは、イントラネット・ベースであり、中央の会社または大学をベースとするサーバが、文書をロードし、文書へのアクセスを管理する。イントラネット・グループウェア・モデルのワールドワイド・ウェブへの拡張が、最近の研究開発の対象になってきた。ワールドワイド・ウェブの最適利用として複数当事者の共同作業能力を提供し、これによって、複数のユーザが単一の文書を同時に表示できるようにすることが望ましい。
【０００３】
University of North Carolinaでのプロジェクト（Ｄ．ストッツ（Stotts）、Ｊ．プリンズ（Prins）、Ｌ．ナイランド（Nyland）、Ｔ．ファン（Fan）共著、「CobWeb: Tailorable, Analyzable Rules for Collaborative Web Use」を参照されたい）で、共同ウェブ・ブラウズ・システムの１バージョンが教示されている。ストッツ他のプロジェクトの目標は、世界中の別々のワークステーションで作業する複数の個人（リーダーと部下達）が、共同でウェブをブラウズできるようにすることである。部下達は、リーダーが取り出したウェブ・ページを見ることができ、すべての参加者が、共用ホワイトボードを介して通信することができる。リーダーと聴衆の間の対話は、セッションの始めに選択される共同作業プロトコルによって決定される。プロトコルの選択によって、どのアプレットをユーザに送信するかが決定される。プロトコルには、講義と会議の２つがあり、これらは、参加者に提供される機能のセットに相違がある。たとえば、ウェブ講義プロトコルでは、ユーザが「先導する」か「中断する」（そのユーザが当面は講師のビューを受信することを望まないことを意味する）ことを行わせるボタンが、ユーザに表示される。ウェブ会議プロトコルでは、これと同一の機能がユーザに提供されない。たとえば、ウェブ会議プロトコルでは、「発言権を得る」または「人物を加える」などの機能を有するボタンがある。ストッツ他のシステムが提供しないものは、すべてではないコンテンツをすべてではないユーザまたはユーザのデバイスに供給する機構である。
【０００４】
もう１つのグループウェア・モデルが、VIEW Media^*（これおよびこれ以降のアスタリスク^*は、この文書全体を通じて、指定された単語がめいめいの所有者の商標である可能性があることを示す）共同ハイパーメディア・システムであり、これは、共用される文書に対する各ユーザのアクセス権に基づいて、会議システムが、異なるユーザが得ることのできる共用される文書のビューを制限できるようにするシステムである（Ｙ．ヨコタ（Yokota）、Ｔ．ナカムラ（Nakamura）、Ｈ．タルミ（Tarumi）、Ｙ．カンバヤシ（Kambayashi）共著、「Multiple Dynamic View Support for Cooperative Work」、Proc. of IEEE Int'l Conf. on Database Systems for Advanced Applications、１９９９年、第３３１ページ〜３３８ページを参照されたい）。VIEW Mediaは、講師が、生徒に講師の私的な注釈を見られないようにする方法を提供する。VIEW Media手法では、ハイパーメディア文書を複数のコンポーネントからなるものとみなし、これによって、これらのコンポーネントの異なるサブセットを、グループウェア・セッションの異なる受信側に選択的に送信することができる。その結果、通常のグループウェアに見られるＷＹＳＩＷＩＳ（What-you-see-is-what-I-see：あなたが見るものは私が見るもの）原理の代わりに、複数の部分的なビューがサポートされる。また、４レベルのユーザ・アクセス権すなわち、ハイパーメディア・オブジェクトをユーザが全部受信することができる、オブジェクトを部分的に受信することができる、オブジェクトを受信することはできないがその存在の知識を受信することができる、オブジェクトおよびその存在の両方をユーザが受信することができない、がサポートされる。ウェブ・サーバ上に配置される、Resource Manage Server（リソース管理サーバ）と称する中間プロキシが、ハイパーテキスト文書（たとえばウェブ・ページ）から複数のビューを作成し、これらのビューの配布を管理する。
【０００５】
もう１つのグループウェア・システム、ＣＡＴ^*（collaborative active textbooks）システムでは、複数のユーザが、同一のウェブ・アニメーション・ショウの異なる部分的なビューを見ることができる（Ｍ．ブラウン（Brown）、Ｍ．ナジョーク（Najork）共著、「Collaborative Active Textbooks: a Web-Based Algorithm Animation System for an Electronic Classroom」、IEEE Symposium on Visual Languages、１９９６年、第２６６ページ〜２７５ページを参照されたい）。講師の画面に、同一のアルゴリズムの複数のアニメーション・ビューを、アニメーションを調整する（たとえば速度）ための制御画面と共に含めることができる。各学生は、同一のウェブ・ページをポイントし、アニメーションの複数のビューを受信するが、制御画面は見ない。アニメーションは、シーケンス内の興味のあるポイントを識別する特殊な言語で記述される。ダウンロードされたクライアント側アプレットが、興味のある点を受信し、これに反応する。この形で、講師は、アニメーションのペースを制御するが、学生は、その学生が見るビューを制御する。各学生は、講師および他の学生と独立に、彼自体のビューと対話することができる。しかし、講師がウェブ・ページを変更する場合には、すべての学生が、新しいアニメーションを受信するために、その新しいウェブ・ページに手作業で変更しなければならない。しかし、望ましいものは、講師がページを変更した後に、聴衆の中のユーザが、新しいウェブ・ページを自動的に受け取ることができるようにすることである。ブラウン他の作品のもう１つの短所は、複数のビューが、作成者によって先験的に構成されることである。基礎のウェブ・ページの副文書への切り分けに基づいて、複数のビューを「オンザフライ」で作成することを提供することが望ましい。
【０００６】
ビデオ会議アプリケーションの共用リモート・コントロールが、Ｔ．ホーデス（Hodes）、Ｍ．ニューマン（Newman）、Ｓ．マッケイン（McCanne）、Ｒ．カッツ（Katz）、およびＪ．ランデイ（Landay）共著、「Shared Remote Control of a Video Conferencing Application: Motivation, Design, and Implementation」、SPIE Multimedia Computing and Networking（ＭＭＣＮ）, Proc. SPIE, vol. 3654、１９９８年（会議は１９９９年１月に開催）、第１７ページ〜２８ページで提案された。ＰＤＡが、ビデオ会議アプリケーション「ｒｖｉｃ」（remote video conferencing）を操作するためのリモート・コントロールとして使用される。ホーデス他は、サービス・ディスカバリ機構も記述している。ホーデス他のリモート・コントロールのアプリケーションは、ストリーミング会議アプリケーションに対処するが、ウェブには対処していない。
【０００７】
http://graphics.stanford.edu/projects/iwork/にある論文でフォックス（Armando Fox）教授が説明しているスタンフォード大学のInteractive Workspace Projectでは、「マルチブラウズ（multi-browsing）」という概念が導入されている。このプロジェクトの目標は、マルチデバイス、マルチユーザ環境を用いる実験であり、具体的には、すべての種類の作業をある計算装置から別の計算装置に移動することと、グループ対話をサポートし、促進することである。そのようなシステムの下で、ユーザは、直列化された形で複数のデバイスと対話する。たとえば、ユーザが、室内で移動する際に、彼のアプリケーションを見るかタスクを完了するために彼が対話しているデバイスが変化する。それぞれが同一の文書を表示する複数のデバイスを並列に使用するという概念もある。主に、このプロジェクトは、各ディスプレイ上で異なる絵を見ることができる壁掛けディスプレイに焦点を合わせている。たとえば、スライド・プレゼンテーションの場合、プレゼンテーションの異なるページが、異なるスクリーンに現われ、ユーザが移動する際に、プレゼンテーションがそのユーザに追従する。このプロジェクトは、室内インフラストラクチャとの対話方法により多くを投資しており、位置情報を得るためにセンサを用いる。
【０００８】
Ｊ．レキモト（Rekimoto）著、「A Multiple Device Approach for Supporting Whiteboard-based Interactions」、Human Factors in Computing Systems（ＣＨＩ）、１９９８年、第３４４ページ〜３５１ページに詳細に示されているように、１つまたは複数のＰＤＡとディジタル・ホワイトボードの間の対話が実施された。最初の例で、レキモトは、ユーザがあるコンピュータの画面上でオブジェクトを「ピック」し、別のコンピュータの画面にドロップできるシステムを記載している。第２の例では、レキモトは、ユーザがＰＤＡ上で描画し、その後、新たに描画されたオブジェクトを、同一のペンを使用してＰＤＡからディジタル・ホワイトボードに「ピックアンドドロップ」できるようにするシステムの実例を示している。ＰＤＡは、ブラシ・タイプおよびペンの色を設定するのにも使用され、画面上のオブジェクトの外見属性を変更することができる。この形で、ＰＤＡが、ホワイトボード・アプリケーションを操作するためのリモート・コントロールとして使用される。
【０００９】
MIT Media Labの「Let's Browse」^*システムでは、Ｈ．リーバーマン（Lieberman）、Ｎ．バン−ダイク（Van Dyke）、およびＡ．ビバクア（Vivacqua）共著、「Let's Browse: a collaborative browsing agent」、Knowl. Based Syst. (UK), Vol.12, No. 8、１９９９年１２月、第４２７ページ〜４３１ページに記載されているように、もう１つの形の共同ウェブ・ブラウズが実施される。「Let's Browse」システムでは、各ユーザが、好ましいウェブ・ページのプロファイルを有する。ユーザが、ウェブ・ブラウズ・コンピュータに近接している時に、コンピュータ上のエージェントが、そのユーザのプロファイルに一致するウェブ・ページを事前に取り出す。一緒にブラウズ・セッションを見ている複数のユーザがいる時には、エージェントは、ユーザの興味の交わりと一致するページを見つける。リーバーマン他は、１つまたは複数のユーザからのアクティブ入力と、各ユーザのプロファイルの更新に対するそのアクティブ入力の影響も企図している。
【００１０】
もう１つの共同作業システムが、RealNetworks^*社によって提供された。Real Presenterと称するその製品は、複数の受信側が、ウェブ・プレゼンテーションを見られるようにし（http://www.realnetworks.com/products/presenterplus/info.htmlを参照されたい）、ニュース放送者が、プレゼンテーションの各スライド（または一部のビデオ）と共にナレーションを記録できるようにする。ニュース放送者は、その後、プレゼンテーションをRealMedia^*文書に変換し、ウェブ・サーバにアップロードし、このウェブ・サーバで、誰もが自分のローカル・コンピュータからその文書にアクセスできる。
【００１１】
ウェブ・サイトhttp://web.calstatela.edu/ats/real/develop/broadcast.htmで見ることができる、RealPresenter^*の生放送版もある。生版では、ユーザがプレゼンテーション・リンクをクリックする場合に、ユーザは、ニュース放送者がRealPresenterソフトウェアを使用して自分のデスクで行っている生のプレゼンテーションを受信する。音声およびスライド・データは、RealServer^*に送信され、このRealServer^*が、データをストリーム化して、リンクをクリックしたすべての人に送る。この製品で追加的に望ましいものは、個々の所有者の複数のデバイスの間で出力を分割し、いくつかの特権グループの概念を用いてアクセスを規制することができるようにすることである。
【００１２】
Microsoft社のNetMeeting^*（ウェブ・サイトhttp://www.microsoft.com/catalog/display.asp?site=113&subid=22&pg=1で見ることができる）を用いると、参加者が、リアル・タイムで共同作業し、Windows文書を共用することができる。すべてのユーザが、標準データ会議プロトコルＴ１２０を使用して、自分の画面で同一の情報を見る。
【００１３】
Netscape Conference^*（ウェブ・サイトｈｔｔｐ://www.aibn.com/help/Software/Netscape/Communicator/Conference/browsing.htmlで見ることができる）は、２人がインターネットを介して同時に同一のウェブ・ページを見られるようにし、各自がいつでもブラウザの制御を得ることができる、共同ブラウズ機能を提供する。標準ビデオ会議プロトコル（Ｈ．３２３）が使用される。Netscape Conference^*も、情報交換に使用されるホワイトボードを提供する。
【００１４】
WebEx.com^*で見つかるもう１つのサービスは、複数のユーザがオンラインで共通のプレゼンテーションに従うことを可能にする（http://www.webex.comを参照されたい）。ブラウズするユーザの画面が、取り込まれ、WebEx.comのサーバに送信され、そこで、その画面が、会議セッションの他のユーザに中継される。このシステムは、誰が発言権を有するかを制御する機構をサポートし、ウェブ・ページだけではなく、すべてのアプリケーションの文書（たとえばMicrosoft Excel^*文書またはＰＤＦ文書）について使用することができる。
【００１５】
もう１つのシステム、Yahoo!^* Gamesは、複数のユーザが、同一のゲームを見られるようにし、ウェブベースの参加機構を有する。対話型オンライン・ゲームは、しばしば、部分的なビューが可能である。たとえば、x-trek^*などのゲームでは、他のプレイヤが見ることのできないインスタント・メッセージを友人と交換することができる。しかし、そのような選択的コンテンツ表示は、ウェブベースではなく、ＨＴＴＰではないプライベート・プロトコルに基づく。さらに、これらのオンラインの労作は、複数の出力デバイスの間で出力を分割しない。
【００１６】
追加的に望ましいものは、コンテンツの異なる部分が異なるユーザに使用可能にされる、ウェブベース共同作業システムおよびウェブベース共同作業方法である。上で参照した機構は、その機能を有しない。さらに、複数の小さいクライアント・デバイスへの出力を分割することが望ましい。たとえば、ユーザの要求元デバイスがセル電話である場合には、小さいセル電話のディスプレイおよびその制限されたオーディオ機能を使用して、要求されたコンテンツにアクセスすることが実用的でない場合がある。むしろ、ユーザは、関連するテレビジョン画面またはコンピュータ・モニタに視覚的コンテンツを表示させ、オーディオをフル・レンジ・ステレオ・システムに配送させることを望む可能性がある。
【００１７】
ビデオ会議の共通規格には、パケット交換網／ＩＰネットワークを介するオーディオ／ビデオ会議用のＨ．３２３ならびにＴ．１２０が含まれる。ウェブ・コンテンツに注釈を付けてトランスコーディングを可能にするための、Ｗ３Ｃに対する提案、「Annotation of Web Content for Transcoding」［Ｗ３Ｃ］がある。この手法では、コンテンツに、メタデータを用いて注釈が付けられ、このメタデータによって、ダウンストリーム・エンティティまたはサーバのいずれかに、各コンポーネントの重要性と、エンド・デバイスでの表示のためにそのコンポーネントをトランスコードする方法が説明される。したがって、この労作は、ウェブ・コンテンツを、受信側デバイスの機能に適応させることを試みている。Ｗ３Ｃ提案では、ウェブ・コンテンツが、ＸＭＬで記述され、トランスコーディング規則の定義にＲＤＦ（resource description framework）ファイルを使用することが前提になっている。このファイルでは、エンドデバイスの機能に対して送るべきものの規則が、それを必要とするコンポーネント（画像ファイルまたはビデオ・ファイルなど）について定義される。しかし、この注釈は、文書の分割を許容しない。この適応からもたらされるウェブ・ページは１つだけであり、そのページがエンド・デバイスに送信される。
【００１８】
パーソナル・デバイスで現れつつある傾向は、ユーザがいつでもどこにでも持ち運び、使用することができる、より小さくポータブルなデバイスに向かっている。ＰＤＡなどのモバイル・デバイスは、しばしば、機能の小さいセットだけをサポートするように技術的に制限され、たとえば、ＰＤＡは、小さい画面を有し、オーディオがなく、これによって、テキストのみのサポートに制限される場合がある。ハードウェア制限のほかに、このようなモバイル・デバイスは、独立の切断されたモードで働く時に、限られた機能性を有する。ＰＤＡは、日程表および住所録などの非常に有用なアプリケーションをサポートするが、ＰＤＡが提供することのできる機能は、切断された時のデバイスの機能性によって固有の形で制限される。ネットワーク接続性をポータブル・デバイスに統合することによって、モバイル・デバイスのユーザが、ネットワークによって供給することのできるアプリケーションのはるかに豊富なセットにアクセスできるようになり、たとえば、ユーザは、自分自身のデスクトップ・アプリケーション、電子メール、およびウェブにアクセスでき、ネットワーク化されたＰＤＡまたは機能強化されたセル電話を介して他のユーザと接触することができる。
【００１９】
【発明が解決しようとする課題】
前述に鑑みて、必要なもの、したがって本発明の目的は、モバイルと固定式の両方の複数のネットワーク化されたデバイスが互いに共同作業できるようにすることによって、モバイルのネットワーク化されたデバイスの機能性を強化するシステムおよび方法である。
【００２０】
本発明のもう１つの目的は、複数の固定式デバイスおよびモバイル・デバイスの集合として定義される、単一のアプリケーションの出力を共同環境内でデバイスのそれぞれの間で選択的に配布できる、仮想計算機を提供することである。
【００２１】
【課題を解決するための手段】
前述および他の目的は、アクセス特権のレベルに従って、ウェブ・コンテンツのユーザに表示される部分へのアクセスを選択的に提供し、異なるユーザ指定デバイスでの表示のためにウェブ・コンテンツの異なる部分を送信する、共同作業システムおよび共同作業方法を提供する本発明によって実現される。本発明のウェブ・ブラウズのシステムおよび方法は、マルチメディア出力を要求元デバイスに制限せず、エンド・ユーザが、ウェブ・コンテンツを受信するデバイスを選択でき、ウェブ・コンテンツを表示するために共同作業する複数のデバイスを選択することも可能にする。たとえば、コンテンツのサウンド部分を、高品質スピーカに送信することができ、それと同時に、ビデオ部分をテレビジョン画面に送信することができ、これによって、ユーザが、ウェブ・ページの各コンポーネントの再生または表示に使用可能な最適（品質または便利さによる）のデバイスを選択できるようにする。その結果、共同マルチデバイス・ウェブ・ブラウズを用いると、エンド・ユーザが、コンテンツまたはそのコンテンツの部分をサービスするのにより適した、より高いまたは異なる出力機能性を有する他の近くの出力デバイスを利用することによって、要求元デバイスの限られた機能性（たとえばセル電話の小さいディスプレイ）を克服できるようになる。各デバイスの機能性が、これによって、複数のデバイスの共同作業から生じる仮想計算機を作成することによって機能強化される。
【００２２】
ウェブ・ページのコンテンツの全体または一部のいずれかを、複数のエンド・ユーザに送信することもできる。本発明の共同マルチデバイス・ウェブ・ブラウズを用いると、ウェブ・ページのコンテンツを、人間のグループ全体に自動的に配布することができる（グループの１人だけがそれを要求した場合に）。グループのメンバは、各自の特権レベルに応じて、ページ全体またはページの一部だけを受信することができる。たとえば、授業を行う教師の場合、教師は、ナビゲーション・バーを用いてスライドの間でナビゲートできなければならないが、学生は、講義中にナビゲーションを変更できてはならない。この場合、システムは、学生からナビゲーション・バーを隠すはずである。というのは、学生が、教師と同一の特権レベル・グループに属さないからである。このシステムおよび方法は、これによって、一部のユーザが文書の部分的なビューだけを受信するので、ウェブ・セッションの参加者の間の制御された対話性を導入する。
【００２３】
共同マルチデバイス・ウェブ・ブラウズでは、どのデバイスまたはどのユーザが、ウェブ・コンテンツのどの部分を受信することになるかの決定が、ＸＭＬ文書ごとにその文書の作成時にウェブ作成者によって記述されたポリシ・ファイルを使用して、セッションの開始時に動的に行われる。ポリシ・ファイルには、複数の特権グループを定義する規則を含む、ＸＭＬウェブ・ページ上のメタデータが含まれる。各特権グループは、タグの異なるセットへのアクセス権を有する。各ユーザは、所与のグループにログ・インし、そのユーザが所有するデバイスのすべてを、サービス・ディスカバリを介してプロキシに識別する。この情報のすべてを与えられて、プロキシは、許可される出力デバイスへの許可されるタグの総合マッピングを構成することができる、すなわち、ユーザがアクセスを許可されるタグのそれぞれが、ユーザが所有するかアクセスを許可される１つまたは複数の出力デバイスにマッピングされる。
【００２４】
異なるデバイスおよびエンド・ユーザに送信される副文書を作成するために、ウェブ・コンテンツを、好ましくはＸＭＬを使用して、トランスコーディングする。変換を適用して適当なタグを選択し、適当な出力フォーマット、通常はＨＴＭＬ、ＸＭＬ、ＷＭＬなどの、またはスピーカに送られるエンコードされたオーディオのストリームなどの非テキスト・フォーマットの、文書を作る。各デバイスによって期待されるコーデック・フォーマットについて知るために、サービス・ディスカバリを実行する。
【００２５】
マルチデバイス・ウェブ・ブラウズの処理全体が、ユーザから透過的に行われるが、エンド・ユーザが見ることを許可されるタグのそれぞれがどこに表示されるかに関して、そのユーザにある程度の制御が与えられる。マルチデバイス・ウェブ・ブラウズ・プロキシは、タグおよびユーザがそのそれぞれについて有するデバイスの選択のリストと共に、アプレットをユーザに送信する。エンドユーザは、ユーザの位置での最適表示のためにタグとデバイスのより便利な関連付けを選択することによって、グループ・セッションをパーソナライズすることができる。
【００２６】
【発明の実施の形態】
以下の説明のために、本発明のシステムおよび方法は、ウェブ・クライアントがユーザの計算機上でローカルに稼働し、ウェブ・サーバがインターネット内でリモートに稼働する通常のウェブ・ブラウズ応用例に適用されると仮定する。ユーザが、ウェブ・ブラウザを介してウェブ・ページを要求する時に、その要求が、適当なウェブ・サーバに送信され、そのウェブ・サーバが、ウェブ・ブラウザに直接に文書を返す。ウェブ・ブラウザには、返されたコンテンツに含まれるＨＴＭＬを解析し、レンダリングするのに十分な知能が含まれる。用語「ウェブ・ページ」および「ウェブ文書」は、交換可能に使用することができ、ウェブ・ページまたはウェブ文書のコンテンツは、それに対するアクセスが選択的に制御される「部分」または「副文書」に選択的に分割される。本発明の好ましい実施形態は、ウェブ文書がＸＭＬを使用して作成されることを必要とし、以下の説明では、言語としてのＸＭＬの使用を前提とする。本発明は、ＨＴＭＬで供給される文書に適用できることに留意されたい。しかし、本発明の目的のいくつかは、ＨＴＭＬ文書と共に動作する時には実現できない。
【００２７】
図１は、通常のウェブ・ブラウズ実施形態の概略図である。図１を参照すると、ユーザ位置１０にいるユーザ（図示せず）が、インターネット１４を介してウェブ・サーバ１２からコンテンツを得る。コンテンツは、ユーザ位置ブラウザ１６で受信された後に、表示コンポーネント１７での視覚的表示またはオーディオ表示コンポーネント１８でのオーディオ・レンダリングもしくはその両方の形でユーザに「配布」される。共同環境では、このモデルが、１つのユーザ位置の複数の表示コンポーネントだけではなく、複数のユーザ位置を含むように拡張される。
【００２８】
本発明の共同マルチデバイス・ウェブ・ブラウズの背後にあるアイデアは、まずウェブ文書を独立の部分に分割し、次にこれらの部分を表示のために選択的に配送することである。共同作業の主題は、複数のレベルで適用される。第１に、ウェブをブラウズしているユーザが１人だけの時には、共同作業の概念は、仮想計算機を形成するために共同作業する互いに近接した複数のクライアント・デバイスに適用される。各ウェブ文書の部分が、ウェブ・ブラウズ・セッションを開始した要求元デバイスの近くに配置されている、この仮想計算機の複数のクライアント・コンポーネントの間で分離される。この種の共同マルチデバイス・ウェブ・ブラウズによって、単独ユーザのウェブ・ブラウズ体験が豊かなものになる。第２に、複数の人間のユーザがいる時には、共同作業の概念が、ユーザ位置にまたがって適用される。その結果、ウェブ文書の部分を複数のローカル・デバイスにサービスできるだけではなく、ウェブ文書の部分を、地理的に隔たって分散したものとすることができる複数のユーザに、各ユーザの設定および許可に従って同時にサービスすることもできる。
【００２９】
共同マルチデバイス・ウェブ・ブラウズの鍵になる前提条件の１つが、ユーザならびにデバイスの両方が、そのサービスを登録する手段ならびに、他者によって登録されたサービスを発見する手段を有しなければならないことである。ユーザおよびデバイスの登録およびディスカバリの機構は、ＳＬＰ（Service Location Protocol）、Sun Microsystems^*社のJini^*、Bluetooth^*のＳＤＰ（Service Discovery Protocol）、Microsoft^*社のＵＰ＆Ｐ^*（Universal Plug and Play）などによって提供されるものなどの、サービス・ディスカバリ・プロトコルおよびミドルウェア・レジストリを必要とする。複数のユーザが、ウェブ・ブラウズ・セッションについて登録し、その後、セッション・プレゼンタによって制御されるセッションに追従することができる。各デバイスも、その機能を公示することができると仮定される。
【００３０】
機能に関するデバイス入力を受信し、ウェブ・コンテンツを受信し、解析するために設けられるのが、図２に示されたプロキシ・エンティティ２０であり、これは、ウェブ・サーバ１２とユーザ位置１０の間に配置される。プロキシは、ウェブ文書の形のウェブ・サーバからの入力、およびユーザ位置デバイス機能情報の形のユーザ位置からの入力を受信するように適合されている。下でさらに説明するように、プロキシは、入力情報を使用して、ユーザ・アクセス特権情報およびデバイス機能情報に従って、ウェブ文書の諸部分へのアクセスを選択的に制御する。
【００３１】
図３に、共同マルチデバイス・ウェブ・ブラウズの第１のシナリオすなわち、より高機能の近くの出力デバイスを使用することによる単独ユーザのウェブ・ブラウズ・セッションの拡充を示す。これは、ウェブ文書のうちで、元のデバイスが効果的にサポートできない部分の再生または表示のために他の近くの出力デバイスを活用することによって、ウェブ・ブラウズに使用される元のデバイスの機能を拡張するという発想である。たとえば、家庭環境では、ユーザが、小さい画面、低い解像度、およびおそらくはサウンド・サポートのないＰＤＡなどのユーザ要求元デバイス３０からウェブのブラウズを開始する可能性がある。高品質スピーカ、ラジオ３２、およびテレビジョン３４が近くにあり、両方がたとえば短距離無線接続性を提供するBluetooth^*チップを備えている場合には、ユーザは、ウェブ・コンテンツのサウンド部分をスピーカに、グラフィカル・コンテンツをテレビジョン画面に送ること決定することができる。ユーザは、ウェブをナビゲートするためのリモート・コントロールとして、元のＰＤＡを使用し続けることができる。周囲の入出力周辺機器を用いて、限られたモバイル・デバイスの機能を拡張する能力によって、ユーザのブラウズ体験が豊かになる。ユーザは、どの出力データ／ストリームをどの出力デバイスで再生／表示するかを制御することもでき、ビデオ画像をテレビジョン３４に送りながら、静止画像を、ＰＣ ３６のモニタ上での表示のために送るか、プリンタ３８でハード・コピーとして出力するために送ることもできる。
【００３２】
図４に、共同マルチデバイス・ウェブ・ブラウズの第２のシナリオすなわち、他のデバイスに加えて、他のユーザが、ブラウズ・セッションの出力を受信できるようにすることによるウェブ・ブラウズ体験の拡充を示す。図４に示されたシナリオでは、講師が、ウェブ・サーバに格納されるウェブ・プレゼンテーション４００を記述し終えており、このプレゼンテーションを、おそらくは電話会議、会議室、または講演ホールで他のユーザに見せることを所望している。講師は、講義位置４１０に到着することができ、この講義位置４１０は、すでに、スピーカ４１３を、ラップトップ・コンピュータ４１１およびWinCE^*デバイス４１２と共に備え、後者を用いて、講師が、プレゼンテーション中に自由に歩き回ることができる。この場合、概略的に示されているウェブ・プレゼンテーション４００には、視覚表示部分４１７、オーディオ表示部分４１４、ナビゲーション・バー４１６、および講師のメモ４１５が含まれる。forward／back（進む／戻る）ボタンを有するナビゲーション・バー４１６は、WinCEデバイスおよび講師のラップトップ・コンピュータだけに送信される。それと同時に、講師は、グラフィカル・スライドである視覚表示部分４１７を、講師のラップトップ機に送信させ、その結果、そのスライドを講演ホールの大きい画面（図示せず）に映写できるようにすることができる。さらに、講師は、プレゼンテーションのオーディオ表示部分４１４を、その室内で使用可能なスピーカ４１３に送らせることを望む可能性がある。ここまでに説明したものは、第１のシナリオの仮想計算機の概念と同一であり、それぞれのアクセスされるウェブ・ページのコンテンツが、単独ユーザのコンピュータ、ＰＤＡ、およびステレオ・システムに分割される。ウェブ・プレゼンテーション４００の図では、メモ４１５（ウェブ・ページの左部分）、ナビゲーション・バー４１６（最上部の絵）、およびスライドである視覚表示部分４１７（中央部分）のすべてが、講師のラップトップ機に送られる。ナビゲーション・バーは、講師がプレゼンテーション中に歩き回るためにリモート・コントロールを所望する場合に、講師のＰＤＡ（図示せず）に送信することもできる。オーディオは、講師の室内で使用可能なステレオ・スピーカに再送される。
【００３３】
仮想計算機のシナリオの拡張として、図示されているように、室内（またはリモート位置）の他者も、デバイスを有し、そのデバイスでプレゼンテーションの一部を受信することを望むと仮定する。たとえば、室内の学生の一部が、ＰＤＡ４１８を有し、それ以外が、ラップトップ機４１９を有する可能性がある。聴衆に、スライドである視覚表示部分４１７を送信することができる（低解像度にトランスコードされた版がＰＤＡに送信される）。リモート位置にいる学生は、図示されていないが、プレゼンテーションのオーディオ部分およびスライド部分の両方が、その学生ユーザによるアクセスのために供給されると仮定する。ユーザは、どのユーザのグループがウェブ・ページ内のどのマルチメディア・オブジェクトの受信を許可されるかを制御するために、異なるアクセス特権を有することができる。たとえば、講師は、室内の人々より高い特権を有する。講師は、メモとナビゲーション・バーを受信することを許可される。対照的に、聴衆メンバは、ナビゲーション・バーを用いて再生することによってプレゼンテーションに割り込むことを許可されず、したがって、ウェブ文書のナビゲーション・バー部分を受信することを許可されない。したがって、このシナリオの下では、所与のオブジェクト（たとえばナビゲーション・バー）が、複数の宛先を有することができ、複数のオブジェクトが、同一の宛先（たとえば講師のコンピュータ）を有することができ、ユーザが、複数の出力デバイス（たとえば、コンピュータ、ＰＤＡ、ステレオ・スピーカ）を所有／制御することができる。前述の講師／学生のシナリオは、すべての会議のシナリオに同等に良好に適用される。たとえば、発言者が発言中に異なるスライドを通じて移動し、他の参加者がオンライン・グラフィカル・プレゼンテーション（受信する特権を与えられた部分のみ）に追従する並列ウェブ・セッションにも参加者が参加できるようにすることによって、通常の電話会議を機能強化することができる。
【００３４】
前述を可能にするために、セッション・プレゼンタは、まず、スライド・プレゼンテーションを構成し（「ウェブ・オーサリング」と称するステップで）、スライドのシーケンスを、ＸＭＬウェブ・ページとしてウェブ・サーバに格納する。オーサリングの一部として、構成者は、任意選択としてＸＭＬ「ポリシ」ファイルを作成することもできる。ポリシ・ファイルには、どのＸＭＬタグがどの特権グループへの送信を許可されるかを指示するマッピング規則が含まれる。後に、セッション・プレゼンタが、共同プレゼンテーションの一部としてウェブ・スライドへのアクセスを望む時に、セッション・プレゼンタは、プレゼンテーションの最初のページをダウンロードする。プレゼンテーションの最初のページは、プロキシによって代行受信される。最初のページが、ポリシ・ファイルを参照している場合には、プロキシは、ポリシ・ファイルを要求し、明確に形成されたタグ・マッピング規則を構成する。ポリシ・ファイルがない場合には、プロキシは、デフォルトの副最適マッピング規則の組を生成することを強制される。この時点で、プロキシは、他のユーザにセッション・プレゼンタのブラウズ・セッションに追従することを許可する、共同マルチデバイス・ウェブ・ブラウズ・セッションの状態を作成する。プロキシは、サービス・ディスカバリ機構にこの新しいセッションを登録し、その結果、新しいサブスクライバが、そのセッションを見つけられるようになる。
【００３５】
新しい潜在的なサブスクライバが、確立されたセッションへの参加を希望する時には、そのサブスクライバは、まず、サービス・ディスカバリ機構に照会し、サービス・ディスカバリ機構は、使用可能なサービスのリストを返す。サブスクライバが、所望の共同マルチデバイス・ブラウズ・セッションを選択した時に、選択されたプロキシからサブスクライバに、ユーザ名およびパスワードを求めるログイン・フォームが返される。与えられたパスワードをポリシ・ファイル内で定義されたパスワードと突き合わせることによって、プロキシは、各新しいサブスクライバに特権グループを関連付ける。また、プロキシは、サービス・ディスカバリに、入力されたユーザ名に関連するすべてのデバイスを要求する。この時点で、プロキシは、個々のサブスクライバのデバイスに送信しなければならないＸＭＬタグだけを選択するマッピング規則を構成することができる。プロキシは、さまざまな部分または副文書を作成する適当なＸＳＬ文書を構成し、これらの部分または副文書が、その後、サブスクライバおよびサブスクライバの複数のデバイスにプッシュされる。各サブスクライバおよび各デバイスは、ウェブ・プレゼンテーションの部分的なビューを受信する。データ・プッシュ機構は、サブスクライバのブラウザでデータ・プッシュがサポートされる方法に非常に依存する。エンドポイントが、ブラウザではなくデバイスである場合には、データ・プッシュは、その物理デバイスにアクセスするのに必要な方法に非常に依存する。最後に、サブスクライバは、マルチメディア・タグ／オブジェクトの出力デバイスへのプロキシの初期マッピングを変更することを望む可能性があるので、プロキシは、ユーザがマッピングをカスタマイズするためにいつでも呼び出すことができる、パーソナライズされた構成アプレットを作成することができる。プロキシは、これらのカスタマイズされたマッピングを使用して、タグ／マルチメディア配布の最終的なポリシを確立する。
【００３６】
プロキシ
プロキシの基本コンポーネントには、ユーザ要求を受信し、これらの要求をウェブ・サーバに転送し、サービス・ディスカバリ（下で詳細に説明するように、ローカル機能または分散機能とすることができる）中にユーザ位置と通信するための少なくとも１つの通信コンポーネント、ウェブ・サーバから取り出した文書を解析するための少なくとも１つの処理コンポーネント、ならびに、ポリシ・ファイルを解釈するための少なくとも１つの処理コンポーネント、文書の部分をユーザ位置に動的にマッピングするための処理コンポーネント、および事前に取り出されたファイルをキャッシュ記憶するための少なくとも１つのキャッシュ位置が含まれる。文書がＸＭＬで供給される場合、この解析をＸＳＬファイルを使用して行うことが最適であり、これには、ＸＭＬパーサおよびＸＳＬエンジンが必要である。変換を行うために使用可能な多数のＸＳＬプロセッサがあり、その詳細は、周知であり、本明細書では繰り返さない。プロキシには、さらに、ユーザ位置にある機能に配送されるコンテンツを「カスタマイズ」するためにウェブ文書のすべてまたは部分をトランスコーディングするためのコンポーネントを含めることができる。
【００３７】
プロキシは、システム内のどこにでも配置することができる（ウェブ・サーバ内またはユーザ位置を含む）が、エンド・ユーザとウェブ・サーバの間に配置されるプロキシに情報を配置することが最適である。プロキシは、マルチデバイス、マルチユーザ選択的処理を実行するようにカスタマイズされた、Apache^*プロキシなどの使用可能なプロキシとすることができる。その代わりに、プロキシを、サーブレットを用いてウェブ・サーバとして実施することができる。実際、マルチデバイス・プロキシは、送信しなければならない文書を作成し、それらを宛先に配布するので、エンドクライアントにとってはウェブ・サーバのように見える。したがって、サーブレットが、インターネット・ウェブ・サーバへの要求の転送、応答の受信、および解析の実行を処理することができる。ウェブ・サーバ部分は、サーブレットによってキャッシュ記憶された文書を検索して、エンドデバイスに配布する。
【００３８】
プロキシの解析機能およびアクセス制御機能に加えて、中間プロキシの使用には、複数の他の長所がある。プロキシは、インターネットからエンドデバイスを隠蔽し、その結果、必ずしもＩＰアドレスを有しないスピーカなどのデバイスにローカルにアクセスできるようになる。さらに、プロキシは、インターネットとエンドデバイスの間のバッファとして働く。たとえば、オーディオ・コンポーネントをストリーム化する場合には、ネットワーク遅延の変動によって、ストリームが停止し、再開されるようになる。プロキシは、データをバッファリングし、よりスムーズかつ規則的にエンドデバイスにストリーミングすることができる。プロキシの使用のもう１つの長所は、プロキシが、クライアント側で何かを稼働させる必要をなくすことであり、これは、エンドデバイスが小さく、限られた機能を有する可能性があるので望ましい。プロキシが適用するトランスコーディング機能は、ウェブ・コンテンツをある種のデバイスに配送するのに適するようにするためにウェブ・コンテンツに適用することができる。たとえば、Palm Pilot^*は、２ビット・グレイスケール・ピクチャだけをサポートするので、画像をエンド・デバイスに配送する前に、プロキシで画像のトランスコーディングを適用することができる。
【００３９】
また、プロキシは、エンドユーザが要求するのを待たずに、必要な追加ファイル（たとえば画像、オーディオ・ファイルなど）を取り出すという点で、ブラウザのように振る舞う。ウェブ・ページを受信するエンドデバイスのすべてが、追加ファイルについて照会すると期待される。したがって、プロキシに、ウェブ・サーバにそれらを一度に照会させ、キャッシュ記憶させ、要求元エンドデバイスにサービスさせることが有益である。図５に、本発明によるデータ転送の前述の効率を示す。
【００４０】
図５からわかるように、デバイス１が、ウェブ文書の照会を開始する。プロキシは、この要求を転送するが、ウェブ・サーバから応答が返ってきた時に、プロキシは、ブラウザと同様に、そのファイルを解析し、画像ファイル、サウンド・ファイルなどを照会する。したがって、これらの画像ファイル、サウンド・ファイルなどの照会が、エンド・デバイスから来る時には、プロキシは、キャッシュ記憶した文書をエンド・デバイスに返すことができる。プロキシによる取出およびキャッシュ記憶の手法では、非ブラウザ・エンドデバイスの問題も解決される。たとえば、ユーザは、画像をテレビジョン画面に送ることを選択できるが、テレビジョン画面がバイナリ・データを期待するので、プロキシが、テレビジョン画面の代わりにＸＭＬファイルに含まれる画像を取り出さなければならない。これがプロキシのデフォルトの振る舞いである場合には、プロキシは、そのデータをテレビジョン画面に送る方法を知るだけでよい。
【００４１】
サービス・ディスカバリ
共同マルチデバイス・ウェブ・ブラウズは、次の２つの理由からサービス・ディスカバリ機構を必要とする。第１に、プロキシが、複数のエンド・デバイスへのマルチメディア・セッションを分割できるようになるために、プロキシが、登録されたユーザならびにそのユーザの登録されたデバイスを発見する手段を有しなければならない。第２に、ユーザがブラウズ・セッションを確立するかそれに参加することができるようにするために、ユーザおよびそのデバイスが、登録されたプロキシを発見する手段を有しなければならない。ユーザ、デバイス、およびプロキシの登録および発見の機構は、サービス・ディスカバリ・プロトコルを必要とする。Sun Microsystems^*社のJini^*、ＳＬＰ^*、およびMicrosoft^*社のＵＰ＆Ｐ^*を含む、本発明のシステムで使用することができる多数の使用可能なサービス・ディスカバリ・プロトコルがある。これらは周知のプロトコルであるから、サービス・ディスカバリ・プロトコルの詳細を本明細書で説明する必要はない。
【００４２】
図６に示されているように、サービス・ディスカバリおよびサービス登録は、共同マルチデバイス・ウェブ・ブラウズによって、セッション確立フェーズならびにセッション参加フェーズの両方で使用される。セッション確立フェーズには、プロキシとサービス・ディスカバリの間の一連の対話がある。サービス・ディスカバリは、プロキシのローカル・コンポーネントとするか、複数のサイトの間で分散するか、集中位置で見つけることができる。第１ステップでは、プロキシ６１０が、サービス・ディスカバリ６１２にそれ自体を登録し、その結果、クライアント（すなわちセッション作成者６１４）が、後にそのプロキシを見つけられるようになる。同様に、ユーザ／セッション作成者は、そのユーザによって所有される各デバイスをサービス・ディスカバリに登録する。ユーザ登録は、セッションの確立時に行うことができ、また、以前に行われ、セッション確立時でのユーザのデバイス可用性に基づいて、必要に応じて更新することができる。
【００４３】
次に、セッション作成者６１４が、所望のプロキシのハイパーリンクをクリックするか、他の形でウェブ対話を開始する。セッション作成者のシステムは、単にウェブへの接続を試みることによってセッション作成者がプロキシにアクセスするように、プロキシの呼出しがユーザに透過的になるように構成することができる。後者の場合、ウェブ対話の開始時に、セッション作成者のシステムが、サービス・ディスカバリに照会して、登録されたプロキシを見つけ、プロキシが選択され、接続される。接続されたプロキシ６１０は、セッション・ログイン・メニューを返し、セッション名と最初のＸＭＬウェブ・ページのＵＲＬを要求する。その後、プロキシは、要求されたＸＭＬページおよびそれに関連するポリシ・ファイル６１７をウェブ・サーバ６１５からプルする。プロキシは、ＸＭＬページおよびポリシ・ファイルを解析して、特権グループを作成し、その後、ログイン・メニューをセッション作成者に送信し、ユーザ名およびパスワードを要求する。ユーザを特権グループに突き合わせた後に、プロキシは、新しいセッションをサービス・ディスカバリに告知し、セッション作成者によって登録されたデバイスを要求する。最後に、要求されたＸＭＬページのうちでセッション作成者が受信を許可される部分が、セッション作成者に返される。
【００４４】
既存のセッションがすでに確立されているセッション参加フェーズでは、プロキシ／ユーザとサービス・ディスカバリの間に、次の３つの対話がある。第１に、新しいユーザまたはサブスクライバが、そのデバイスをサービス・ディスカバリに登録する。第２に、サブスクライバが、サービス・ディスカバリに、進行中のブラウズ・セッションのリストを要求する。第３に、プロキシが、サービス・ディスカバリに、新しいサブスクライバに関連するすべての登録されたデバイスを要求する。テーブル６１６に、プロキシおよびセッションの登録のためにサービス・ディスカバリ・コンポーネントによって維持されるレコードの例を示す。
【００４５】
本発明のシステムおよび方法と既存のサービス・ディスカバリとの間の上の対話は、２つの動作すなわちregister()（登録）およびquery()（照会）に還元することができる。既存のサービス・ディスカバリ・プロトコルは、プロキシおよびブラウズ・セッションならびにユーザおよびそのユーザのデバイスを登録（register()）することができる。さらに、サービス・ディスカバリは、照会（query()）に応答して、登録されたプロキシまたはセッションもしくはその両方のリスト、または、各ユーザに関連するデバイスと共に登録されたユーザのリストを返すことができる。サービス・ディスカバリのレジストリが、集中化されるか分散されるか、または、登録されたプロキシ／セッションが、ローカル・エリア専用であるか、広域で使用可能であるかは、選択されるサービス・ディスカバリ・プロトコルによって決定できる要因であり、本発明のシステムおよび方法を変化させる要因ではない。もちろん、広域サポートによって、プロキシがリモートの広域共同作業、たとえばリモート学生との遠距離学習を提供する能力が拡張される。
【００４６】
サービス・ディスカバリへのインターフェースは、クライアントまたはプロキシのどちらがサービス・ディスカバリと対話するかに応じて変更することができる。プロキシは、サービス・ディスカバリとの視覚的インターフェースを必要とせず、単純な手続きＡＰＩでよい。対照的に、クライアントのエンド・ユーザは、サービス・ディスカバリへのグラフィカルＵＩまたはブラウザタイプのインターフェースを有することができる。クライアントとサービス・ディスカバリの間の対話の詳細は、やはり、本発明の範囲を超える。必要なのは、そのような対話が存在し、クライアント・デバイスを登録でき、リストされたプロキシまたはセッションをクライアントに返せることである。
【００４７】
更新データ配送
更新されたデータが生じるたびに、そのデータを、すべてのブラウザおよび、スピーカまたはテレビジョン画面のようなデバイスにプッシュし、その結果、誰もが見るものについて同期化されるようにしなければならない。しかし、変更が、クライアント側で必要になってはならず、マルチデバイス・ウェブ・ブラウズを機能させるためにプログラムを実行する必要があってもならない。その理由の一部は、Palm Pilot^*などのいくつかのデバイスが、マルチスレッド式ではなく、その結果、これらのデバイスでデーモンを稼働させることができないからである。したがって、ウェブ・ブラウザの現在の特徴だけを使用して、それらにデータをプッシュすることを試みることが好ましい。２つの手法すなわちサーバ・プッシュまたはクライアント・プルのいずれかを使用して、エンド・ブラウザにデータを送信することができる。サーバ・プッシュでは、サーバが、データを送信し、ブラウザは、そのデータを表示するが、接続をオープンしたままにし、サーバが求める時にはいつでも、サーバが次のデータを送信し、ブラウザがそれを表示し、接続をオープンしたままにする。逆に、クライアント・プルでは、サーバが、「このデータを５秒で再ロードせよ」または「１０秒でこの他のＵＲＬに行き、ロードせよ」と命じるディレクティブ（ＨＴＴＰ応答または文書ヘッダ内の）を含むデータを送信する。指定された時間が満了した後に、クライアントが、指示されたことを実行する（すなわち、現在のデータを再ロードするか、新しいデータを得る）。
【００４８】
クライアント・プルに対するサーバ・プッシュの主な長所は、サーバが、いつどのように新しいデータを送信するかに関する完全な制御を有することである。また、この方法は、新しいＨＴＴＰ接続を毎回オープンする必要がないので、より効率的になる可能性がある。短所は、オープン接続が、それがオープンされている間にサーバ側のリソースを消費することである。残念ながら、すべての種類のブラウザが同一の特性を有するわけではなく、たとえば、Netscape Navigator^*とＩＥ^*は、サーバ・プッシュまたはクライアント・プルの実装に同一の技法を使用してはいない。たとえば、サーバ・プッシュ（サーバがブラウザにデータをプッシュできるようにする）を行うために、Netscape Navigatorは、単一メッセージ（またはＨＴＴＰ応答）に多数のデータ項目を含められるようにする、「multipart/mixed」と称する固有のＭＩＭＥタイプに依存する。プッシュされるデータの異なる部分は、定義済みの区切り文字列によって分離される。しかし、ＩＥブラウザは、ＭＩＭＥタイプを使用せず、したがって、本発明は、この方法を使用してこれらにデータをプッシュすることができない。WinCE^*デバイスで使用されるポケットＩＥについては、完全なＨＴＴＰ仕様が実施されておらず、クライアント・プル技法を使用できるようにすることができるJavaScriptもサポートされない。
【００４９】
したがって、サポートされる特徴の相違に対して、必要なものは、ブラウザの種類ごとに（少なくとも最も一般的なものについて）データをプッシュする異なる方法である。以下の解決策が適用される。Netscape Navigator^*の場合、プロキシは、クライアントがNetscape Navigatorを実行していることを見つけた場合に、サーバ・プッシュまたはクライアント・プル・モデルを使用することを決定することができる。サーバ・プッシュ・モデルでは、プロキシとクライアントのデバイスのウェブ・ブラウザとの間に永久的なリンクがオープンされる。このリンクは、エンドブラウザがＨＴＴＰヘッダ内でmultipart/mixedのＭＩＭＥタイプを受信した時にオープンされる。その後、データを、このパイプを介してウェブ・ブラウザにプッシュすることができる。次のコードに例を示す。

この例では、永久的なリンクは、クライアント・ブラウザが「Content-type multipart/mixed」でメッセージを受信した時に作成される。属性boundaryは、その文字列が、サーバによってプッシュされるデータの区切りに使用されることを示す。したがって、サーバは、クライアントにデータを送信したい時に、boundary文字列を用いてデータを区切り、ヘッダのContent-typeを用いてデータ型を定義する。
【００５０】
クライアント・プル方法は、JavaScriptを使用するか、ウェブ・ページを周期的に再ロードできるようにする、Refresh（最新表示）と称する特殊なＨＴＴＰヘッダを使用して行われる。したがって、文書がプロキシ側で変更された場合には、新しいコンテンツが、規則的な時間間隔で表示される。特殊なＨＴＴＰヘッダは、「Refresh: 3」のような形になる。同一のウェブ・ページが、３秒ごとに最新表示される。
【００５１】
エンド・クライアントがＩＥを実行している場合には、ＩＥの現在のバージョンではサーバ・プッシュがサポートされていないので、クライアント・プル・モデルだけが使用可能である。したがって、クライアント・ブラウザが、規則的にプロキシに照会して、更新を入手しなければならない（JavaScriptまたはＨＴＴＰ Refreshヘッダを使用する）。
【００５２】
Netscape NavigatorおよびＩＥのためのもう１つの代替案が、プロキシからの通知をlistenし、プロキシによって送信されたＵＲＬを有する文書を表示するようにブラウザに指示するアプレットを使用することである。この手法は、隠されたクライアント・プルであり、新しいデータが使用可能になった時について通知を受けるアプレットの存在によってより柔軟にされる。この形では、ページは、規則的な瞬間に最新表示されるのではなく、新しいデータが使用可能になった時に限って最新表示される。同一のことを、Netscape Navigatorの場合にはNetscapeプラグイン、ＩＥの場合にはMicrosoft Active X^*コンポーネントを用いて行うことができる。
【００５３】
クライアントがポケットＩＥを実行している（WinCEデバイス）場合、ポケットＩＥが、完全な版のＨＴＴＰを実行せず、Refresh ＨＴＴＰヘッダを理解せず、JavaScriptまたはJavaを理解せず、サーバ・プッシュをサポートしないので、明白な方法はない。解決策は、ＨＴＭＬ文書を表示するＡＰＩを提供する、ＨＴＭＬビューア・コントロールと称する機能を使用することとすることができる。そのようなシステムでは、プロキシからデータを受信（ソケットを使用して）することができるプログラムを作成でき、ＨＴＭＬビューアＡＰＩを使用してＨＴＭＬ文書を表示することができる。
【００５４】
共同作業の処理
本発明のプロキシベースの解決策を使用してデバイスおよびユーザが共同作業するために必要なステップの具体的なシーケンスを、これから説明する。一般的に言って、図７に示された処理は、プロキシが、ウェブ・ページ内のＸＭＬタグを各ユーザの異なる出力デバイスにマッピングする規則のセットを作成する方法の輪郭を示すものである。概念を明確にするために、共同マルチデバイス・ウェブ・ブラウズ・セッションの正常動作を、４つのフェーズに分割することができる。最初のステップでは、ステップ７０１に示されているように、ウェブ・ページをＸＭＬで事前にオーサリングしなければならない。ウェブ・オーサリングのステップには、複数のユーザの間の共同作業を助けるＸＭＬポリシ・ファイルの作成を追加的に含めることができる（ポリシ・ファイルには、タグを特権グループにマッピングするデフォルト規則が含まれる）。ウェブ・オーサリングの後に、ステップ７２０に示されているように、前述のＸＭＬウェブ・ページと、ポリシ・ファイルがある場合にポリシ・ファイルをユーザが要求することによって、プロキシ側でブラウズ・セッションを確立しなければならない。次に、ステップ７４０に示されているように、新しい潜在的なサブスクライバが、セッションにログ・インし、自分が属する特権グループを識別することによって、すでに確立されているブラウズ・セッションに参加することができる。最後に、確立されたセッションに参加した後に、サブスクライバが、ステップ７６０で、そのサブスクライバが所有するかアクセスを許可されているエンド・デバイスにＸＭＬタグをマッピングする規則をカスタマイズすることができる。前述のステップのそれぞれを、これから詳細に説明する。
【００５５】
ウェブ・オーサリング
共同マルチデバイス・ウェブ・ブラウズでは、ウェブ・サイトの作成者が、図７のウェブ・オーサリング・ステップ７０１で、ＸＭＬウェブ・ページ、それに付随するＸＳＬ文書、および、非常に有益であるが任意選択のポリシ文書を含む、複数のＸＭＬ関係文書を作成することが必要である。ウェブ・ページの記述に使用された従来の言語は、ＨＴＭＬである。ＨＴＭＬは、ウェブ・ページのコンポーネントの書式設定を記述する標準化されたマークアップ言語である。ウェブ・ページの内容に無関係に、汎用タグが使用され、このため、人間がＨＴＭＬソースを読み、理解することが困難になっている。ＨＴＭＬタグは、書式設定の意味を有するが、ウェブ文書の一部としてのコンテンツの意味を有しない。その結果、ＨＴＭＬは、本発明によく適していない。JavaScriptまたはMicrosoft社のJScriptに似たスクリプトを使用することによって、ＨＴＭＬをより柔軟で豊富にしようと試みる努力がなされているが、現在のＨＴＭＬは、ウェブ作成者がポリシ・ファイルを作成する機能を提供することができない。これは、本発明が、ＨＴＭＬを使用して作成された文書に適用できないと述べているわけではない。実際、本発明を使用して、ＨＴＭＬ文書を、異なるユーザ・デバイスでのコンテンツの部分の配布のために文書部分に分割することができる。しかし、ポリシ・ファイルに基づく、文書の分割および異なる特権グループに属するユーザへの選択的なコンテンツの配布の態様は、ＨＴＭＬ文書を用いて簡単には実施されない。
【００５６】
その代わりに、ＸＭＬが、作成者が文書を創る際に必要なタグを構成する言語である。ＸＭＬでは、書式設定ではなくセマンティクスが記述され、書式設定は、ＸＳＬまたはＣＳＳで記述することができるスタイル・シートを用いて文書に追加される。本発明を実施するためのウェブ・コンテンツのオーサリング言語として、ＸＭＬに頼ることが好ましい。ウェブ・コミュニティは、豊富なウェブ・コンテンツを開発する上でのＨＴＭＬの限界を意識しており、これが、マークアップ言語としてのＸＭＬへの遷移を始めることを試みる努力の理由である。ＸＨＴＭＬなどのＷ３提案は、ＨＴＭＬとＸＭＬの間の互換性を定義する方法を示している。さらに、多数のウェブ・サーバが、すでにウェブ・コンテンツをＸＭＬ文書として格納しているが、エンド・ユーザに送信する前に、それらのコンテンツをＨＴＭＬに変換している。
【００５７】
ＸＭＬは、その柔軟性に起因して、本発明の実施に非常に適する。すべての作成者が、独自のタグおよび独自のコンポーネントを定義するので、結果の文書を、選択されたデバイスに送信することができる独立のコンポーネントに分割することが非常に簡単である。あるページの独自の名前を有するタグのそれぞれが、そのタグの配送先にすることができる出力デバイスを記述する、それ自体のデマルチプレクス・ポリシを有することが最適である。ＸＭＬによって、各タグの名前を一意に定義する能力が提供され、ＸＳＬによって、各タグの使用法を定義することができる。さらに、ＸＳＬ文書は、カスタマイズされたＸＭＬをブラウザがレンダリングできる言語に変換するために、ＸＭＬ対応ブラウザによって必要とされる。このＸＳＬ文書によって、ＸＭＬからＨＴＭＬ（または、必要であれば別のマークアップ言語）への変換が定義され、これによって、サーバとブラウザの間でプロキシが使用されない場合であっても、ＸＭＬ非対応ブラウザがウェブ文書を処理できることが保証される。
【００５８】
図４に示されたスライド・プレゼンテーション用のＸＭＬウェブ・ページの次の例を検討されたい。そのウェブ・ページには、ナビゲーション・ボタン、グラフィカル・スライド、私的メモ、およびオーディオという４つのコンポーネントがあったことを想起されたい。そのようなページの非オーディオ・コンポーネントを記述するのに使用されるＸＭＬファイルは、次のようになる。

この文書は、タイトル（タグ<title>）およびナビゲーション・バー（タグ<nav_bar>）を有するヘッダ部分と、スライド（タグ<picture>）を含むものおよび私的メモ（タグ<notes>）を含むものの２つの本文部分とを有する。
【００５９】
これら２つのファイル（ＸＭＬおよびＸＳＬ）のほかに、作成者は、任意選択として、どのＸＭＬタグをどの特権グループおよびどのデバイスに配布しなければならないかを支配するマッピング規則を定義するポリシ・ファイルを記述することができる。ポリシ・ファイルによってもたらされる大きい利益が、誰がウェブ・プレゼンテーションの何を見るかを制御する能力である。ポリシ・ファイルでは、特権グループが定義され、次に、各特権グループが受信を許可されるＸＭＬタグのサブセットが定義される。作成者は、ポリシ・ファイルを使用して、あるグループがウェブ・プレゼンテーションの部分的なビューだけを受信するように制限すると同時に、セッションへの他のサブスクライバにすべてのアクセス特権を与えることができる。

【００６０】
ポリシ・ファイルの重要な責任は、特権グループの定義である。特権グループの背後にあるアイデアは、共同ブラウズ・セッションの参加者のアクセス特権に区別を立てるための機構を提供することである。１つのセッションによって、異なる特権グループにウェブ・ブラウズ・セッションの異なる部分的ビューを提供することができる。ブラウズ・セッションで複数のユーザに提示されるウェブ・ページの作成者は、あるユーザ・グループに、他のグループより高いまたはより低い、あるＸＭＬタグにアクセスする特権を与えることを望む場合がある。上の例では、ポリシ・ファイルによって、共同プロキシを介して学生にオンラインで大学の授業を提示する講師が、学生が提示されるウェブ・ページのそれぞれのタグのサブセットだけを見るように制限できるようになる、すなわち、講師は、学生が私的な覚え書きのメモを見られないようにし（<notes>タグが学生に使用不能）、学生が講義へのナビゲーション制御にアクセスできないようにする（<nav_bar>タグが学生に使用不能）。
【００６１】
ポリシ・ファイルは、ＸＭＬ文書の一部とすることができるが、ポリシ・ファイルを、そのポリシ・ファイルを参照するＸＭＬウェブ・ページとは別の第２のファイルにすることが好ましい。別々のファイルを使用することによって、複数のウェブ・ページから同一のポリシ・ファイルを参照できるようになる。たとえば、これは、ウェブ・スライド・プレゼンテーションを構成する作成者が、すべてのウェブ・ページに対して特権グループの同一のセットを定義したいが、ページごとに新しいポリシ・ファイルを書き直したくない場合に役立つことができる。そうではなくて、作成者は、プレゼンテーションの各ページから参照される単一のポリシ・ファイルを記述するのである。同一のポリシ・ファイルを参照するすべてのページが、同一の特権グループを共用する。作成者は、プレゼンテーションの複数のページを横断する間に出会うすべてのＸＭＬタグを、１つのポリシ・ファイルに集める。ポリシ・ファイルを別のファイルにすることに対する代替案は、ポリシ・ファイルの情報を各ＸＭＬページに埋め込むことである。しかし、ポリシ・ファイルのメタデータ情報を独自のファイルに分離することによって、作成者が特権グループを更新するのが簡単になる。作成者は、同一の特権グループの同一の埋め込まれた定義を含むウェブ・ページのそれぞれを編集する必要なしに、単に、各ウェブ・ページから参照される１つのポリシ・ファイルを変更する。
【００６２】
上で説明した例のＸＭＬページのために開発された、ポリシ・ファイルの例を下に示す。このポリシ・ファイルは、ＸＭＬ文書として構成される。この文書内では、ネームスペースを定義して、このポリシ・ファイルで使用されるタグおよび値を標準化する。以下では、ネームスペース・プレフィックスｃｍｄｂ（collaborative multi-device browsing）が導入される。前の例に対応するＸＭＬポリシ・ファイルは、次のようになる。

【００６３】
作成者がポリシ・ファイル内で使用しなければならないタグおよび属性を標準化するスキーマを定義する必要がある。いくつかの属性に使用される値も標準化しなければならない。たとえば、すべての共同マルチデバイス・プロキシが、特権グループが定義されていることを理解するために、すべての作成者が、標準タグ名「group」を使用することが重要である。例のＸＭＬポリシ・ファイルには、以下の提案される標準タグ名が含まれる：group、device、taglist、undefinedtag_list、media_types、images、およびtext(videoおよびaudioは示されていない）。さらに、各タグは、それ自体の独自の属性を有し、たとえば、groupタグは、属性「name」、「password」、および「input_permitted」を有する。最後に、属性「name」および「password」の値は、標準化する必要がないが、いくつかの属性の値は、作成者が何を意図しているかをプロキシが例外なく理解できるようにするために標準化しなければならず、たとえば、input_permittedは、「yes」または「no」のいずれかにセットされる標準化された値を有しなければならない（そうでなければ、異なる作成者が、true/false、on/off、1/0などを使用することになる）。周知の名前についてはある程度の自由度を設けることができる、すなわち、プロキシは、<device name=”InternetExplorer”>が、デバイス属性ＩＥに言及していることを理解することができる。しかし、他のエンド・デバイスの場合、これはより困難になる可能性がある。その結果、デバイスに言及するための共通の用語に同意することが好ましい。この語彙は、いつでも指定することができ、もちろん拡張可能である。
【００６４】
デバイス・タグの属性機能も、作成者がコンテンツ出力デバイスの機能に関する特殊な要件を指定できるようにするために導入することができる。たとえば、<cmdb:device capability=”sound_card”>を使用することができ、これは、それに続くタグのセットを、サウンド・カードを有するデバイス用に送信できることを意味する。機能属性の値を標準化し、その結果、プロキシが、サービス・ディスカバリから検索するものとそれら値を照合できるようにすることが、さらに重要である。プロキシは、各デバイスについてサービス・ディスカバリ・データベースに登録されたさまざまな属性から、デバイスの機能を知る。しかし、機能を記述する標準化された方法がない場合には、プロキシは、この情報を活用することができない。したがって、デバイスは、作成者がサービス・ディスカバリを用いてそれらの機能をリストするのと同一の語彙を使用しなければならない。Ｗ３Ｃ草案「Composite Capability/Preference Profiles（ＣＣ／ＰＰ）」は、デバイスの特性のグローバルな標準化を提案することを試みており、これによって、将来に本発明のこの態様を実装することが、より簡単になる可能性がある。
【００６５】
セッションによってプロキシにダウンロードされる最初のＸＭＬページに関連する（または、そのＸＭＬページの一部である）初期ポリシ・ファイルによって、特権グループが定義され、したがって、セッションを通じて観察されるタグ・マッピング規則が定義されると仮定する。異なるポリシ・ファイルを有する他のページに遭遇する可能性があるが、初期ポリシ・ファイルによって定義された特権グループおよびタグ・マッピング規則が、後続のポリシ・ファイルより優先される。未定義タグに関する以下の議論では、ブラウズ・セッションがすでに確立されていることと、初期ポリシ・ファイルがそのセッションの最初のＸＭＬページと共にダウンロードされていることを仮定する。
【００６６】
ポリシ・ファイルのUndefined_Tags変数は、共同ブラウズ・セッションを確立した最初のウェブ・ページによって参照されるポリシ・ファイル内で定義されていないタグを有するウェブ・ページに講師またはセッション・プレゼンタがアクセスした場合に、未知のＸＭＬタグをどこに送信するかをプロキシに知らせる変数である。セッション・プレゼンタが、初期ポリシ・ファイルの定義に従うウェブ・ページだけにアクセスするように制限することは、厳密にすぎるはずである。その代わりに、セッション・プレゼンタが、初期ウェブ・ページのポリシ・ファイルの有効範囲の外のウェブ・サイトをブラウズする権利を有することを許容することが望ましい。たとえば、ウェブ聴衆にスライド・ショウを提示している講師が、準備された講義のスライドだけではなく、デモンストレーションのために、準備された講義の外部のウェブ・ページも見せたいと思う場合がある。そのようなシナリオでは、セッション・プレゼンタが、事前に定義されたポリシ・ファイルを有しないウェブ・ページ、たとえば、共同ウェブ・ブラウズを意識していない、ＣＮＮなどの商業ウェブ・サイトに行き、初期ポリシ・ファイルＰＦと異なるポリシ・ファイルＰＦ'およびＰＦ"を有する２つの他のウェブ・ページに行く。
【００６７】
ユーザは、ポリシ・ファイルを有するウェブ・ページにアクセスせずに、共同ブラウズ・セッションを確立することもできる。この場合、目的は、人間のグループが一緒にブラウズすることを望むが、ユーザの異なるサブセットの特権グループを形式的に定義することに関心がない場合の一般的なシナリオをサポートすることである。しかし、セッション・プレゼンタが、異なるグループが見るものをより形式的に制御する方法を必要とする時には、ポリシ・ファイルによって、同一のウェブ素材の部分的ビューを供給する手段がもたらされる。
【００６８】
初期ポリシ・ファイルの有効範囲の外のウェブ・ページへのアクセスを許可した結果として、プロキシが、初期ポリシ・ファイルで定義されていない、未知のＸＭＬタグに出会う。未定義タグを処理するために、Undefined_Tags変数という概念を導入する。Undefined_Tags変数によって、プロキシに、未定義タグを送信する先が指示される。プロキシは、未定義タグに出会った時に、タグの未知の名前に基づいて切り替えることが不可能なので、そのメディア・タイプまたはＭＩＭＥタイプに基づいてそのタグを切り替える。セクションmedia_typesが、この目的のためにポリシ・ファイルに含まれる。作成者は、どのタグがどのメディア・タイプに属するかをリストし、このリストは、プロキシが、どのタグがどのmedia_typesからのものであるかを知る方法である。上の例では、ポリシ・ファイルで、タイプtext、images、audio、およびvideoの未定義タグを、アクセスのためにＰＣベース・ブラウザを使用する講師および学生に送信し、タイプtextの未定義タグだけを、アクセスのためにＰＤＡベース・ブラウザを使用する講師および学生に送信するようにプロキシに指示している。ポリシ・ファイルによって定義されていないタグ名を有するページにアクセスすると、最適でないページのプレゼンテーションがもたらされる。
【００６９】
同一のポリシ・ファイルを、複数のウェブ・ページから参照することができる。セッション・プレゼンタは、プレゼンテーション用のウェブ・スライドのシーケンスをオーサリングし、そのスライド・シーケンスの開始ページに、そのプレゼンテーションでアクセスされるすべての後続ページに適用されるポリシ・ファイルへの参照を含めることができる。プレゼンテーションでアクセスされるそれぞれの後続ページは、同一のポリシ・ファイルを参照する。複数のウェブ・ページによって参照されるポリシ・ファイルには、ブラウズ・セッション中に出会うすべてのタグのできる限り完全なリストを含めなければならない。誤ってポリシ・ファイルから省略された未定義タグは、前に述べたUndefined_Tags機構によって捕まえられ、最適でないプレゼンテーションがもたらされる。
【００７０】
ポリシ・ファイルには、タグ名のスーパーセットが含まれるので、ポリシ・ファイルによってカバーされる個々のウェブ・ページは、リストされたタグ名の異なるサブセットを使用することができ、したがって、異なる外見を有することができる。現在の例のコンテンツでは、プレゼンテーションの次のスライドで、前に定義されたページの同一のタグ名を再利用するか、タグ名の異なるサブセットを使用し、これによって異なるルックアンドフィールをもたらすかのいずれかを行うことができる。
【００７１】
ポリシ・ファイルの有効範囲を拡張して複数のウェブ・ページに適用する理由の１つが、カスタマイズを単純にすることである。各ウェブ・ページで、異なるタグのセットを使用するが、同一の特権グループのセットを使用する場合には、エンド・ユーザが、各ページをダウンロードする際に、新しいマッピングを要求するか作成しなければならない。１セッション内のすべてのタグを単一のポリシ・ファイルに集めることによって、エンド・ユーザが、プレゼンテーションの早期に講義のレイアウトをカスタマイズできるようになる。異なるページで、まだ異なるタグが使用される可能性があるので、集合ポリシ・ファイル内でページによってタグをグループ化し、その結果、エンド・ユーザが、どのタグがプレゼンテーションのどのページに属するかを理解できるようにする機構が必要である。
【００７２】
ユーザが、特定のＸＭＬタグにアクセスする特権を有することができるが、そのユーザが、そのＸＭＬタグを処理することができる出力デバイスを有しない場合がありえる。たとえば、あるユーザが、ラウドスピーカのないＰＤＡだけを用いて共同ブラウズ・セッションにアクセスし、そのユーザが、<audio_music>と称するタグにアクセスする許可を有する場合には、そのユーザは、ハードウェア制約が原因で<audio_music>を実際に利用することができない。
【００７３】
共同セッションの確立
図７のステップ７２０を参照すると、新しい共同ブラウズ・セッションは、ポリシ・ファイルなしでセッションを確立することが可能ではあるが、通常は、ポリシ・ファイルがプロキシにダウンロードされる時に確立される。ポリシ・ファイルの追加の長所は、共同ブラウズ・セッション内で、特権グループと称するサブスクライバの異なるグループを定義できるようになり、その結果、プロキシが、ＸＭＬタグの異なるサブセットを異なる特権グループに選択的に送信できるようになることである。新しいサブスクライバのそれぞれは、ログイン・パスワードを供給することによって、確立された共同ブラウズ・セッションに参加する。このパスワードによって、そのサブスクライバが、ポリシ・ファイルで定義された特権グループに関連付けられる。パスワードは、電子メールなどのアウト・オブ・バンド機構によって、ユーザに前もって与えられると仮定する。共同ブラウズ・セッションで所望される特権のレベルに応じて、ポリシ・ファイルの一部またはすべてを暗号化することができる。上の例では、ポリシ・ファイルで、「lecturer」および「students」という２つの特権グループが定義され、各グループに関連するパスワードが定義され、各グループが受信を許可されるタグが定義される。ポリシ・ファイルがない場合、これをヌル・ポリシ・ファイルと呼ぶが、プロキシは、デフォルト・マッピング規則を構成することを強制されるが、これは作成者の望みと一致しない可能性がある。
【００７４】
正しいログインに続いて、プロキシは、ポリシ・ファイルを調べて、各特権グループ、そのグループの正しくログ・インしたサブスクライバのそれぞれが、受信を許可されるＸＭＬタグを調べる。各特権グループ内で、ＸＭＬタグをどこに送信できるかを支配するマッピング規則を、ユーザの出力デバイス／ブラウザに基づいてさらに詳細化することができる。ポリシ・ファイルでは、各ＸＭＬタグのメディア・タイプも識別され、これによって、エンド・ユーザが、一意の名前を付けられたＸＭＬタグ（image、audioなど）のそれぞれの目的を理解できるようになる。後で述べるように、タグごとのメディア識別は、出力デバイスへのタグのマッピング規則をカスタマイズしようとするエンド・ユーザを助ける。前述によって、作成者が、さまざまな共通のシナリオを予期するためにデフォルト・タグ・マッピング規則をより柔軟に構成できるようになる。上の例では、講師のラップトップ機を介して教室の大きい映写スクリーンにスライドを提示する講師が、歩き回り、講師の無線ＰＤＡを介してプレゼンテーションをリモート・コントロールすることを好むことを、ウェブ・ページの作成者が想定することができる。この場合、上のポリシ・ファイルで、私的メモがラップトップ機に送信されるのではなく、ＰＤＡに送信され、その結果、講師が、講義中に室内のどの地点からでもメモを調べられるようになる、デフォルト規則を指定する。第２の例として、講師の教室内にいるのではなく、リモートから講師のセッションに追従している２人の学生がいると仮定する。一方の学生は、接続されたラップトップ機のブラウザを介してセッションに追従し、もう一方の学生は、接続されたＰＤＡ、おそらくはクラムトップWinCE^*デバイスまたは無線ＰＤＡを介して講義に追従する。上の例では、ポリシ・ファイルで、タイトルおよびグラフィカル・スライドだけが、ラップトップ・ブラウザを有する学生に送信され、タイトルおよびトランスコーディングされたグラフィカル・スライドだけが、ＰＤＡを有する学生に送信される、デフォルト規則が定義されている。具体的なデフォルト・トランスコーディング・パラメータも、作成者によって与えられる。
【００７５】
ＸＭＬウェブ・ページが、付随するポリシ・ファイルを有するか否かを判定するために、プロキシは、検索したＸＭＬページを解析しなければならない。プロキシは、ポリシ・ファイルへの参照を見つけた場合に、そのポリシ・ファイルを取り出さなければならない。ポリシ・ファイルは、それ自体のＭＩＭＥタイプ、おそらくはtext/policy_fileと共にそれ自体のＵＲＬを有することができ、これによって、プロキシにトリガがかけられ、プロキシが、画像と同様に余分なファイルを取り出す。
【００７６】
ポリシ・ファイルへの参照を埋め込む手法の１つが、スタイルシート文書がＸＭＬから参照されるのと同じ方法に従うことである。ＸＭＬ文書は、次のタイプの処理情報を用いて、使用するスタイルシートを示す。
<?xml:stylesheet type="text/xsl" href="present.xsl"?>
同じ形で、次のような処理命令を使用することができる。
<?xml-cmdb href = "location of policy file"?>
マルチデバイス・ウェブ・ブラウズ・プロキシは、この命令を認識し、href属性で指定されたアドレスに配置されたファイルを検索する。
【００７７】
第３ステージすなわち図７のステップ７４０で、ＸＭＬウェブ・ページの要求によってトリガされる、プロキシ内のブラウズ・セッションが確立される。図８および図９に示されているように、プロキシ内で共同マルチデバイス・ウェブ・ブラウズ・セッションを確立する処理フローには、１０個のステップがある。ステップ８０１で、プロキシが、それ自体をサービス・ディスカバリ・データベースに登録する。プロキシが、活動中になった後に、プロキシは、サービス・ディスカバリ・プロトコルを介してその名前およびＩＰアドレスを、概念上サービス・ディスカバリ・データベース（ＳＤＤＢ）と称するものに登録する。サービス・ディスカバリ・プロトコルは、（１）プロキシを登録でき、各プロキシ内の各ブラウズ・セッションを登録でき、（２）各デバイスの所有者と共に各デバイスを登録でき、（３）どのプロキシ、セッション、およびユーザ・デバイスが、すでにＳＤＤＢにそれ自体を登録したかに関する照会に応答できなければならない。概念上、サービス・ディスカバリ・プロトコルは、本質的に、書き込まれ、照会されるデータベースとして実行する。しかし、どのサービス・ディスカバリ・プロトコルが使用され、そのサービス・ディスカバリ・プロトコルがどのようにしてそのＳＤＤＢを実施するかの詳細は、本発明の実施にとってクリティカルではない。たとえば、上で述べたように、ＳＤＤＢは、集中データベース・レジストリとして、または分散データベース登録方式として、実施することができる。
【００７８】
次のステップである図８の８０２には、セッション作成者がそのブラウザをサービス・ディスカバリ・データベースに登録することが含まれる。セッション作成者は、発信元のブラウザ対応コンピュータをＳＤＤＢに登録することを要求する登録メッセージをＳＤＤＢに送信する。デバイス（この場合は発信元のコンピュータ）の登録は、デバイスのＩＰアドレス、デバイスの名前、デバイス所有者の名前、デバイスのメディア・デコード機能（ＭＰＥＧビデオ、．wav^*、MP3^*、RealVideo^*、WindowsMedia^*、ＪＰＥＧ^*、ＧＩＦ^*、ＨＴＭＬ ４．０、ＸＭＬなど）、およびデバイスのアクセス・モード（デバイス・ドライバに類似する、そのデバイスと通信するのに用いられるプロトコル）の供給を必要とする。登録メッセージには、すべての登録されたプロキシおよびそれらの登録されたセッションのリストの要求も含まれる。
【００７９】
登録の後に、セッション作成者は、ステップ８０３で、ブラウズ・セッションを作成するプロキシを選択し、ステップ８０４で、「セッション作成」メッセージをそのプロキシに送信する。具体的に言うと、ブラウザ対応コンピュータの登録の後に、ＳＤＤＢが、使用可能なプロキシおよびそれらの進行中のセッションのリストを含む応答をセッション作成者に返す。このリストは、単純なハイパーテキスト・インターフェースをセッション作成者に供給することができ、セッション作成者が、接続したいプロキシを手作業でクリックすることができるように記述されなければならない。リンクは、プロキシがそれ自体をＳＤＤＢに登録した時にプロキシによって供給された定義済みウェブ・ページを指す。このウェブ・ページは、新規セッション確立フォームになり、ユーザがプロキシ名をクリックする時に、この定義済みフォームの要求がプロキシに送信され、プロキシが、その文書をセッション作成者に返す。このフォームのおかげで、ユーザは、新しいウェブ・ブラウズ・セッションを作成することができるようになる。ブラウザが、プロキシ・フィールドの自動更新をサポートする場合には、プロキシ名のクリックによってブラウザがリダイレクトされ、その結果、ブラウザが所望のプロキシを指す（すべてのブラウザＨＴＴＰ ＧＥＴ要求がプロキシを介してルーティングされる）ならば有用である。しかし、ブラウザが自動リダイレクションをサポートしない場合には、セッション作成者が、手作業でプロキシ・パラメータをブラウザに転送しなければならない、すなわち、ユーザが、「Edit Preferences（設定）」（Netscape Navigator）または「Tool->Internet Options（ツール→インターネット・オプション）」メニュー（Internet Explorer）のいずれかを編集し、プロキシ・フィールドに適当なアドレスおよびポートを設定しなければならない。この時点で、ブラウザが、次のステップすなわち、選択されたプロキシを介するＸＭＬウェブ・ページの要求のために正しくセット・アップされる。
【００８０】
プロキシの選択にユーザが手作業でかかわることは、プロキシの自動化された選択およびブラウザの自動化されたリダイレクションと比較して望ましくないように見える可能性がある。手作業のかかわりは、実施が複雑にならないという長所を有し、これに対して、自動選択およびリダイレクションは、サービス・ディスカバリ・プロトコルに対する追加要件を課す可能性がある。たとえば、ＳＤＤＢへの登録メッセージに、その最も単純な形態で、登録済みプロキシ・リストおよび進行中セッション・リストの両方に関する広い照会として解釈されるサービス・ディスカバリ要求が組み込まれる。そのような広いサービス・ディスカバリ要求を与えられたＳＤＤＢは、要求元ユーザが、プロキシ・リストだけに興味を持っているセッション作成者であるか、進行中のブラウズ・セッションの１つへの加入だけに興味を持っている一般ユーザであるかを知ることができない。サブスクライバの場合には、サブスクライバによる手作業の介入が存在しなければならず、このサブスクライバは、セッションを選択するために、進行中のセッションの表示されたリストを走査することができなければならない。したがって、要求元デバイスのユーザがサブスクライバである可能性があることを予期して、両方のリストが、ＳＤＤＢによって返されなければならず、要求元デバイスでサービス・ディスカバリ・プロトコルによって表示されなければならない。セッション作成者であってサブスクライバでないユーザは、プロキシを選択するために自動化されたアルゴリズムを適用することが可能な場合であっても、手作業でプロキシを選択することを強制される。プロキシの自動化された選択を完全にサポートするためには、サービス・ディスカバリ・プロトコルに対する追加要件を課し、その結果、サービス・ディスカバリ・プロトコルが、登録要求の２つのタイプすなわち、セッション開始元からの要求（プロキシのリストだけを要求する）とサブスクライバからの要求（ブラウズ・セッションのリストだけを要求する）を区別できるようにする。この形で、ＳＤＤＢは、サブスクライバであるユーザを登録する場合にセッション・リストだけを選択的に返し、セッション開始元であるユーザを登録する場合にはプロキシ・リストだけを選択的に返すことができる。その結果、自動的な方法（プロキシ選択およびブラウザ・リダイレクション）を、手作業の方法（セッション選択）から分離することができる。自動化機構は、使用可能なプロキシの受信されたリストの手作業の表示をオーバーライドし、抑止するはずである。
【００８１】
一般に、セッション作成者は、複数のデバイス、おそらくはＰＤＡならびにラップトップ機およびステレオ・システムを所有し、登録することができる。唯一の要件は、セッション作成者が、プロキシを介してＸＭＬウェブ・ページを要求することによって共同ブラウズ・セッションを開始することができる、少なくとも１つのブラウザ対応ＨＴＴＰデバイスを有することである。例を単純にするために、図６には、１つのデバイスすなわちブラウザをサポートすることができるラップトップ機だけを有するセッション作成者を示した。
【００８２】
ステップ８０５で、プロキシが、セッション作成者にセッション作成メニューを送信し、セッション名およびセッションの最初のＸＭＬウェブ・ページのＵＲＬを要求する。セッション作成者が、プロキシを選択し、それをクリックした時に、要求がプロキシに送信され、そのプロキシが、新規セッション確立フォームを返す。ユーザは、ステップ８０６で、セッションの名前、取り出される最初のウェブ・ページのＵＲＬ、および、潜在的に、パスワードを指定する。パスワードは、セッション名が事前に予約されている場合に使用される。セッション名を事前に予約するとは、セッション作成者が、前もって（たとえば数日前に）使用するセッション名を指定し、それにパスワードを関連付けたことを意味する。この関連セッション名−パスワードは、セッションを保護する目的で、システム管理者が共同マルチデバイス・ウェブ・ブラウズ・プロキシに格納することができる。その形で、事前に格納されたパスワードを知っている人だけが、この名前を有するセッションを確立することができる。これによって、誰も、プレゼンタが所望するウェブ・ページと異なるウェブ・ページを指す、この名前を持つセッションを作成できないことが保証される。セッションの事前予約のこのアイデアは、家庭のシナリオではなく、スライド・プレゼンテーションの場合に有用である。
【００８３】
プロキシは、完成したフォームを受信した時に、ステップ８０７で、このセッション名に関するパスワードを有するかどうかを判定する。そうである場合には、プロキシは、格納されたパスワードを、ユーザが指定したパスワードと比較する。ユーザが入力したパスワードが一致しない場合には、要求を除去する。しかし、パスワードが正しい場合、または、このセッションに関する事前に格納された情報がない場合には、プロキシは、ステップ８０８で、適当なウェブ・サーバからウェブ・ページを取り出すことができる。プロキシは、要求がそこから来たソケットおよびＩＰアドレスを記憶し、ウェブ・ブラウザから返されたファイルとそれらを関連付ける。
【００８４】
セッション作成フォームで指定されたＵＲＬに対応するページ（ＸＭＬまたはＨＴＭＬ）が、プロキシに到着した時に、プロキシは、ステップ８０９で、セッションを確立するためにそれを処理する必要がある。それがＨＴＭＬ文書である場合には、そのセッションは、上で述べたようにポリシ・ファイルを有しないので、行うことができる文書部分の分割は、media_typesに制限され、異なる特権グループの、準備のできた実装はない。ＸＭＬ文書の好ましい実施形態では、ＸＭＬ文書を解析して、他のどの文書を取り出さなければならないかを判定する必要がある。通常は、ＸＳＬ文書も取り出す必要がある。さらに、ページに、「ポリシ」ファイルへの参照が含まれ、ポリシ・ファイルを取り出す必要があることが示される場合がある。
【００８５】
解析されたＸＭＬページにポリシ・ファイルへの参照がある場合には、ステップ８１０で、プロキシが、ウェブ・サーバからポリシ・ファイルをダウンロードする。プロキシは、ポリシ・ファイルを使用して、特権グループに基づく、ウェブ・ページのさまざまなコンポーネントを異なるユーザおよび出力デバイスにディスパッチする規則を確立する。プロキシは、次の３つのシナリオの１つに出会う：１）ポリシ・ファイルが、ウェブ・ページによって参照され、そのポリシ・ファイルですべての特権グループのパスワードが定義される、２）ポリシ・ファイルが参照されるが、いくつかの特権グループのパスワードが定義されていない、３）ウェブ・ページにポリシ・ファイルへの参照が含まれない。
【００８６】
ポリシ・ファイルにアクセスする際に、プロキシは、グループおよび各グループが何を受信することを許可されているかに関する一般的な情報だけを有する。プロキシは、まだ特定のユーザまたはデバイスに関するポリシを作成していない。ユーザごとの許可されるＸＭＬタグの許可される出力デバイスへの完全なマッピングを作成するためには、プロキシは、各ユーザが、パスワードを介してログインし、所与の特権グループのメンバとしてユーザ自身を識別し、各ユーザが、彼らの出力デバイスを登録し、その結果、ウェブ・マルチメディア（この登録はすでに行われている可能性があるので図示せず）を受信するのに使用可能なデバイスをプロキシが知るようにすることを必要とする。
【００８７】
ステップ８１１の判定で、ポリシ・ファイルが存在し、ステップ８１２の判定で、そのポリシ・ファイルですべての特権グループのパスワードが定義されている場合に、プロキシは、ポリシ・ファイルを分析して、可能な特権グループの値およびそれに関連するパスワードおよび許可を識別する。ポリシ・ファイルによって、誰が何を見、どのデバイスが文書のどの部分を受信するかを制御することが可能になる。それを行うために、ポリシ・ファイルで、特権グループと、各特権グループがＸＭＬタグのどのサブセットの受信を許可されるかを定義する。ポリシ・ファイルは、さらに、アクセス・デバイスのタイプに従って、各特権グループ内でより微細な粒度でタグをデマルチプレクスできるようにする詳細を提供することができる。したがって、セッションを確立するために、プロキシは、作成者によって定義された特権グループ値、それに関連するパスワードが存在する場合にそのパスワード、およびこのグループについて許可されるタグのリストを分離する必要がある。プロキシによる規則の作成および各加入ユーザに文書のどの部分を送信できるかのマッピングは、この情報を使用することによって行われる。ステップ８１３で、パスワードを検証した後に、プロキシは、ポリシ・ファイル情報を適用して、ステップ８１４で文書を文書部分に分割し、ステップ８１５でこれらの部分を配送のためにマッピングすることができる。ユーザが出力デバイスを指定した場合には、プロキシは、クライアント位置への配送のために文書部分をマッピングする際に、この情報も「調べる」。
【００８８】
ステップ８１１の判定でポリシ・ファイルがない場合、ユーザへのタグのマッピングを、なんらかのヒューリスティックを使用して、プロキシによって生成しなければならない。すべてのタグが、基本的に未定義であるから、デフォルトは、メディア・タイプまたはＭＩＭＥタイプに基づいてタグを切り替えることになる可能性が高い。この場合は、セッション作成者によってＨＴＭＬ文書が要求される場合と同一である。実際、ＸＭＬ文書がポリシ・ファイル参照を有しない場合、このＸＭＬ文書は、ＸＳＬ文書の助けを得てＨＴＭＬ文書に変換されなければならない。そうでなければ、タグがプロキシに対して何も意味しないので、まったくデマルチプレクスを行うことができない。ＨＴＭＬ文書の場合、行うことができる唯一の解析は、メディア・タイプに基づくものであり、画像またはオーディオを文書の残りから分離することができ、これらの異なるメディア・タイプを異なるデバイスに送信する申し出が、ユーザに対して行われる。さらに、ポリシ・ファイルがないか、ユーザの特権レベルを検証するためのパスワードがない場合には、１つのデフォルト特権グループだけが存在する。したがって、パスワードが定義されていないので、この単一の特権グループへのアクセスはオープンである。したがって、このセッションに参加するすべてのユーザが、アクセスを許可され、自分のデバイスの間での、ウェブ・コンテンツのメディアタイプ・ベースの分割しか選択できない。プロキシの役割は、ステップ８１６で、文書をメディアタイプ文書部分に分割することと、ステップ８１７で、ユーザ・デバイス情報に従って、これらの部分を配布のためにクライアント出力デバイスにマッピングすることになる。
【００８９】
プロキシが、任意のＵＲＬを受信した場合には、プロキシは、新しいセッションを確立しなければならないか否かを判定しなければならない。これは、セッション作成者がセッションを確立した後であっても、セッション作成者が、プレゼンテーションの一部でないページまたは同一のウェブ・サイトの一部でないページをブラウズすることができなければならないという発想である。２つのサイトまたは２つのプレゼンテーションの間の相違は、これらのページのオーサリングに使用されるタグと、その結果としてこれらが参照するポリシ・ファイルである。ユーザが、自分のブラウザから任意のウェブ・ページまたはＵＲＬを要求する時には、プロキシは、所望されたページを、既存のセッション内で表示しなければならないのか、新しいセッションの最初のページとして表示しなければならないのかを判定する必要がある。第１に、要求は、新しいセッションの確立を望むセッション作成者から来る可能性がある。第２に、要求は、既存のセッション内でウェブ・ページを表示したいと思っているだけの、すでに確立されたセッションのリーダーから来る可能性がある。第３に、要求は、現在のセッションを去り、新しいセッションを始めることを望む、既存のセッションのリーダーから来る可能性がある。具体的に言うと、第２および第３の可能性が、曖昧であり、プロキシを混乱させる可能性がある。この曖昧さは、次に説明する手順によって解決される。
【００９０】
プロキシが任意のウェブ・ページの要求を受信した時に新しいセッションを確立するかどうかを判断するために、プロキシは、ポリシ・ファイルの比較に基づく手順を使用する。要求されたウェブ・ページのポリシ・ファイルが、セッションの確立に使用された最初のウェブ・ページの初期ポリシ・ファイルと一致する場合には、プロキシは、そのウェブ・ページを同一のブラウズ・セッション内で表示する。セッションが最初に確立される時に、プロキシは、その最初のページによって参照されるポリシ・ファイルの名前を記憶し、ポリシ・ファイル（または、ポリシ・ファイルが参照されていない場合には、ヌル・プレースホルダ）をキャッシュ記憶する。同一の初期ポリシ・ファイルを参照する後続のウェブ・ページのすべてが、キャッシュ記憶されたポリシ・ファイルの特権グループおよびタグ名を再利用し、同一のブラウズ・セッション内で表示される。異なるポリシ・ファイルがアクセスされるか、要求されたウェブ・ページについてポリシ・ファイルが存在しないので、一致が存在しない場合には、プロキシは、新しいセッションをオープンしなければならないかどうかをユーザに尋ねることを強制される。曖昧さの問題は、要求元のユーザによって解決され、このユーザは、未知の要求されたウェブ・ページを、既存のセッション内で表示しなければならないのか、新しいセッションを確立するのに使用しなければならないのかを示す。
【００９１】
上の手順の定義は、新しいセッションを確立するかどうかを判定するために、現在のポリシ・ファイルを既存セッションの初期ポリシ・ファイルと比較するので、再帰的であるように見える可能性がある。初期ポリシ・ファイルによって定義される既存セッションが、確立されるものと同一の手順に従う場合に、その既存セッションはどうなるかという疑問が生じる。解決策は、いくつかのセッションを、異なる経路によって作成することである。上で注記したように、セッション開始には３つの代替案があるが、後者の２つだけが曖昧さを引き起こす。第１の代替案（すなわち、セッション作成者が、プロキシに未知であり、要求されたＵＲＬも未知である）について、初期ポリシ・ファイルと共に新しいセッションを確立しなければならないことは明白である。セッション開始の第１の代替案が、再帰を停止させ、新しいセッションの確立のブートストラップになる。
【００９２】
ページ要求（この段落の残りでは、「ページ要求」は、初期ポリシ・ファイルと一致しないポリシ・ファイルを有するウェブ・ページの要求と同義である）が行われた後に新しいセッションの確立に関してユーザに照会するという事後手法の代替案は、ページ要求を行う前に、ユーザに、そのユーザが新しいセッションを所望することをプロキシに明示的に知らせるようにさせるという先験的手法である。エンド・ユーザは、次に要求するＵＲＬが、新しいセッションの確立に使用されなければならないことをプロキシに知らせる。しかし、先験的にプロキシに明示的に知らせるためには、メッセージを生成するクライアント側コードが必要である。これは、たとえば、プロキシに通信するのに使用されるコントロールを含む、ウェブ・ページ内のフレームまたはアプレットによって提供することができる。コントロール・フレームを挿入するために各ウェブ・ページを再度生み出すことには、ウェブ・ページのレイアウトが変化するというそれ自体の危険性が伴う。特に画面の小さいＰＤＡの場合に、フレームおよびアプレットのサポートに依存することはできない。対照的に、ページ要求が行われた後に、ユーザに新しいセッションを確立するかどうかを尋ねる手法は、クライアント側コードを必要とするのではなく、単に、ブラウザによりサポートされるフォームを必要とし、これはＰＤＡであっても一般的である。ウェブ・ページは変更されず、ウェブ・ブラウザとのユーザの対話は変更されない、すなわち、ユーザは、通常の対話を継続するか、ポイント・アンド・クリックを行うか、新しいＵＲＬを入力する。ユーザに要求される処置は、ユーザに対する画面プロンプトとして送信される。共同ブラウズ・プロキシとの対話は、自己誘導式であって、ユーザが知る必要のあるすべてのものが、画面プロンプトに含まれる。対照的に、先験的にプロキシに明示的に知らせる手法では、共同ウェブ・ブラウズ・プロキシを使用するためにユーザがブラウザと対話する方法を、ユーザが変更する必要がある、すなわち、ユーザは、新しいＵＲＬをポイント・アンド・クリックする前に、新しいセッションを明示的に要求しなければならないことを知る必要がある。この手法は、初期ポリシ・ファイルに従わないウェブ・ページをユーザが要求するたびに、おそらく高い頻度で迷惑なポップアップ・メニューがもたらされるという短所を有する。このポップアップ効果は、複数のウェブ・ページに適用されるようにポリシ・ファイルの有効範囲を拡張することによって、軽減することができる。さらに、下で説明する任意選択の機構を使用して、ポップアップ照会を完全に抑止することができる。この任意選択の機構は、明示的手法と同一の短所を有する、すなわち、ユーザが、プロキシと対話する方法について事前に知識を有することを必要とする。
【００９３】
ページ要求の後に新しいセッションの確立に関してユーザに照会するという事後手法は、セッション・リーダーがセッション確立照会を抑止できるようにする任意選択の機構を用いて補足することができる。これは、初期ポリシ・ファイルの有効範囲の外の多数のウェブ・ページにアクセスするセッション・リーダーに、セッション確立照会が送信される頻度を最小にするのに役立つ。１つの解決策は、セッション確立照会を明示的に抑止またはイネーブルするオン／オフ・ボタンまたはチェック・ボックスを設けることである。チェック・ボックスが、セッション確立照会を抑止するようにセットされているブラウズ・セッション中は、セッション・リーダーは、プレゼンテーション中に繰り返される照会で悩まされない。もちろん、これらの照会が抑止されている間は、セッション・リーダーは新しいセッションを確立することができなくなる。初期ポリシ・ファイルの有効範囲の外のウェブ・ページに関する要求のそれぞれが、既存のブラウズ・セッション内でそのウェブ・ページを表示する要求であると仮定される。Undefined_tags機構は、未知のポリシ・ファイルまたは欠けているポリシ・ファイルをオーバーライドする。照会が再びイネーブルされた後に、セッション・リーダーは、初期ポリシ・ファイルの有効範囲の外のウェブ・ページを要求することができ、その後、新しいセッションの確立に関する照会を受ける。このオン／オフ機能は、ブラウザが保護されたウェブ・ページに出会う時にしばしば表示されるポップアップ・メニューの抑止に似ており、ブラウザにダウンロードされるユーザ・カスタマイズ・アプレットと共に含めることができる。セッション・リーダーのブラウザが、ダウンロード可能なアプレットまたはクライアント側カスタマイズ・コードをサポートしない場合には、デフォルト設定を、照会をイネーブルするようにセットしなければならない。照会の明示的抑止は、事後セッション確立機構と相補的であり、したがって、共同ウェブ・ブラウズの正しい機能のために絶対に必要ではない。
【００９４】
図１０に、ＵＲＬを受信した時にセッション確立を判定するためにプロキシによって使用される最終的なアルゴリズムを要約した擬似コードを示す。このアルゴリズムは、考慮しなければならない多数の特殊な場合に起因して、前に輪郭を示したものより複雑である。図１０では、「現在のポリシ・ファイル」が、現在要求されているウェブ・ページ／ＵＲＬに関連するポリシ・ファイルを指す。「既存セッション内でページを表示する」は、要求されたページに基づいて新しいセッションを確立するのではなく、既存のブラウズ・セッションのすべてのサブスクライバに、要求されたウェブ・ページを送信することを意味する。
【００９５】
この段階で、プロキシは、要求されたウェブ・ページのために新しいセッションをセット・アップするか否かを知っている。したがって、プロキシは、次の、ユーザ・ログインに進んで、新しいセッションを開始するか、そのステップを飛び越えて、単に要求されたウェブ・ページを共同ブラウズ・セッションのサブスクライバに配布するかのいずれかを行う。
【００９６】
図１１に、前述のステップ８０７の「ユーザ許可」を実行するためにプロキシが作成するカスタマイズされたログイン・ページを示す。プロキシは、このログイン・ページに、すべての可能な特権グループのリストを含め、その結果、ユーザが自分の属する特権グループを選択できるようにする必要がある。プロキシは、このページを動的に作成した後に、これからセッション作成者と呼ばれるユーザに送信する。セッション作成者に送信されるハイパーテキストＨＴＭＬ／ＸＭＬログイン・インターフェースを、図１１に示す。このインターフェースは、合成物であり、インターフェースのすべてのフィールドが、各セッション作成者に示されるわけではない。プロキシは、ログイン処理によって供給されるパスワードを使用して、セッション作成者を特権グループに分類し、ユーザ名を使用して、セッション開始元の登録された出力デバイスに関してＳＤＤＢに照会する。
【００９７】
ログイン・ページは、セッション確立に関する下記の条件すなわち、（条件ｉ）ユーザがプロキシに未知の場合、または（条件ｉｉ）ユーザがプロキシに既知（進行中のセッションに加入）であり、ユーザが加入してる進行中のセッションの初期ポリシ・ファイルと一致しないポリシ・ファイルを有するＵＲＬを要求し、そのユーザが、新しいセッションを確立するかどうかを尋ねるプロキシからの質問に「はい」と応答し、その後、セッションを確立した場合のどちらかの下で、セッション作成者に送信される。図８および図９のアルゴリズムでは、初期ポリシ・ファイルがセッション確立中に存在した場合と存在しなかった場合を区別するが、条件ｉｉでは、一般性を失わずにその区別を無視することができ、両方の場合を１つに合体させることができる。ログイン・ページは、セッション確立に使用される条件のセットに応じて変化する。
【００９８】
セッション作成者は、ログイン・ページのルック・アンド・フィールに影響する３つの追加の可能性すなわち、（条件ａ）現在のポリシ・ファイルが、要求されたウェブ・ページによって参照され、すべての特権グループのパスワードを定義する、（条件ｂ）現在のポリシ・ファイルが、参照されるが、一部の特権グループのパスワードを定義しない、（条件ｃ）ウェブ・ページが現在のポリシ・ファイルへの参照を含まない、に出会う。
【００９９】
ログイン・ページの最初のフィールドでは、セッション作成者に、そのユーザ名を識別するように要求する。このフィールドは、セッション作成者がプロキシにとって新規である時（条件ｉ）に、唯一の絶対に必要なフィールドであり、セッション作成者が進行中のブラウズ・セッションの一部である、すなわち、セッション作成者の識別がすでに既知である時（条件ｉｉ）には、技術的には必要でない。条件ｉの場合、プロキシは、セッション作成者と、ＳＤＤＢにそのユーザ名の下で登録された出力デバイスとを一致させるために、セッション開始元のユーザ名を知る必要がある。供給されるユーザ名は、セッション作成者のデバイスと共に登録されたユーザ名と同一でなければならない。ユーザ名に相違がある場合、プロキシは、デバイスをその正しい所有者に関連付けることができなくなる。条件ｉｉの場合、プロキシは、ユーザ名フィールドを送信するというオプションを有する。この現在の意図は、プロキシがすでにセッション開始元の過去のユーザ名を知っている場合であっても、このフィールドを表示することである。セッション作成者が、過去のセッションから去って新しいセッションを確立する間に、識別を変更したい状況が存在する可能性がある。もちろん、セッション作成者は、新しいユーザ名の下でそのセッション作成者が所有するデバイスを再登録しなければならない。
【０１００】
第２のフィールドでは、ユーザに、パスワードの同等物を供給するように要求し、その結果、プロキシが、セッション作成者が属する特権グループを識別できるようにする。パスワードと同等とみなされるものは、条件ａ、ｂ、およびｃに応じて変化する。現在のポリシ・ファイルで定義されているすべての特権グループへのアクセスが、パスワードによって保護されている場合（条件ａ）、ログイン・ページには、パスワード・フィールドだけが表示される。しかし、特権グループの一部が、パスワードによってアクセス保護されていない場合（条件ｂ）、ログイン・ページには、パスワード・フィールドと、パスワード保護されない公開特権グループのリストのハイブリッドが提示される。このハイブリッド・シナリオの例が、図１１に示されており、この図では、スライド・プレゼンテーションの公開特権グループ「lecturer」および「students」が、パスワード保護されておらず、少なくとも１つの他の特権グループが、パスワード入力を必要とする。セッション作成者が、非パスワード保護グループのメンバとして参加することを望む場合には、セッション作成者は、単に所望の公開グループのボックスをチェックする。そうでない場合には、セッション作成者は、適当なパスワードを入力する。最後に、要求されたウェブ・ページに関連する現在のポリシ・ファイルがない場合（条件ｃ）、プロキシは、１つの公開特権グループだけを作成する。その結果、１つの特権グループだけが、チェックボックスと共にリストされ、パスワード・フィールドは表示されない。
【０１０１】
パスワードは、スライド・プレゼンテーションの最初のウェブ・ページの作成者からの電子メールなど、なんらかのアウト・オブ・バンド方法を介して、セッション作成者に前もって知らされることが仮定されている。しかし、聴衆のすべてのメンバが、かならず先験的に既知ではない場合があり、その結果、事前のパスワード配布を、必ず仮定することはできない。たとえば、進行中のブラウズ・セッションへの加入を希望する一部の学生が、自分のパスワードを忘れた、パスワードを一度も受け取っていない、またはそのクラスに入ったばかりであるという可能性がある。これらの場合には、公開のパスワード保護されない特権グループのサポートによって、すべてのサブスクライバがパスワードを知ることを要求せずに、そのような学生が進行中のブラウズ・セッションに簡単に参加できるようになる。
【０１０２】
第３のフィールドは、セッション作成者がセッションを私的または単一ユーザに保つことを望む場合に、セッション作成者がチェックすることができるボックスである。このボックスがチェックされている場合には、そのセッションはＳＤＤＢに公示されない。この場合には、セッション作成者が、本発明のプロキシのマルチデバイス機能を利用することを望むが、共同機能を望んでいない。要求されたウェブ・ページによるポリシ・ファイルへの参照（条件ａおよびｂ）によって、公開共同セッションをセット・アップしなければならないことが暗示されると思われる場合であっても、ポリシ・ファイルの存在が、必ず新しいセッションを強制的に公開または共同にするという制約を課さないことが好ましい。要求されるウェブ・ページがポリシ・ファイルを参照するかどうかに無関係に、セッションの公開／私的性質を決定するために、完全な柔軟性がセッション作成者に与えられる。
【０１０３】
第４のフィールドは、セッション作成者が、後続のウェブ・ブラウズ・セッション中に新しいセッションを形成するかどうかを尋ねる照会のすべてを即座に抑止することを望む場合に、セッション作成者がチェックすることができるボックスである。そのような照会は、条件ｉｉがあてはまる時すなわち、セッション・リーダーが、セッションの確立に使用された初期ポリシ・ファイルと異なるポリシ・ファイルを有するさまざまなウェブ・サイトを訪れる時に、生成される。このオプションは、頻繁に初期ポリシ・ファイルの有効範囲の外に出るユーザが、繰り返される照会を即座に抑止できるようにするために、ログイン・ページ内に設けられる。ユーザは、ログイン・フォームに書き込み、プロキシにサブミットする。
【０１０４】
データ・プッシュ処理が、この段階で初期化される。Netscape NavigatorおよびＩＥの場合、データ・プッシュは、クライアントの計算機にダウンロードされるアプレットを使用することになる。このアプレットは、ログイン・ページがユーザに送信される時にダウンロードされる。これは、この時点から、プロキシがブラウザにデータをプッシュできることを意味する。
【０１０５】
プロキシは、セッションを確立しなければならない（セッション作成者が、このセッションを確立することを許可された）ことを知っているので、そのセッションをサービス・ディスカバリに登録することができ、その結果、そのセッションが公示され、人々がそのセッションに参加できるようになることに留意されたい。プロキシは、ポリシ・ファイルに含まれる情報を使用して、このセッションをサービス・ディスカバリに登録する。プロキシは、アクセス・モードとしてＵＲＬを供給してこのセッションを登録する。これは、プロキシがポリシ・ファイルから作成する動的ログイン・ページのＵＲＬであり、この動的ログイン・ページでは、このセッションの特権グループのリストが指定され、ユーザのパスワードおよび名前が要求される（図１１）。サービス・ディスカバリ・データベースへの登録に使用されるＡＰＩ機能呼出しは、次のようになる（具体的な呼出しは、選択されたプロトコルに依存する）。
register(name, access_url, proxy_@);
ここで、nameは、セッションを識別し（たとえばトランスコーディング・プロキシ）
access_urlは、登録のためにプロキシによって作成されるフォームのＵＲＬであり
proxy_@は、セッションをホスティングするプロキシのアドレスである
このステップの後に、サービス・ディスカバリは、その室内で使用可能であり、エンドユーザが参加することのできるサービスとして、そのセッションをリストする。登録されたセッションは、図６のＳＤＤＢの右側の箱の右欄に現れる。
【０１０６】
サービス・ディスカバリは、登録されたセッションを「告知解除」する能力を許容しなければならない。たとえば、ユーザが、「keep new session private」をクリックする場合に、そのセッションを、ＳＤＤＢのセッション・リストから取り除かなければならない。
【０１０７】
プロキシは、ユーザによって登録されたデバイスに関する情報も検索する。具体的に言うと、プロキシは、ユーザがセッションを確立するのに使用しているデバイスのアクセス・モードを知る必要がある。この場合のアクセス・モードは、セッション作成者が使用してるブラウザのタイプ（ＩＥ、Netscape Navigator、Pocket IE）である。この情報は、プロキシによって、プロキシがユーザに送信しなければならないデータのフォーマットを知るために使用される。たとえば、ブラウザがＩＥ ５である場合には、ＩＥ ５はＸＭＬ対応なので、プロキシは、直接にＸＭＬ文書を送信することができるが、ブラウザがNetscape Navigatorである場合には、Netscape Navigatorの現在入手可能なバージョンがＸＭＬを理解しないので、ＨＴＭＬ文書を作成しなければならない。
【０１０８】
プロキシは、ユーザが所有するデバイスについて知る必要があるが、室内で使用可能な公共インフラストラクチャについても知る必要がある。プロキシは、この情報を使用して、パーソナライゼーション・フォームを設計して、ユーザが、見ることを許可されるものの各部分が送信される出力デバイスを選択するように、ユーザが、データのより詳細な分割を選択できるようにする。これらのデバイスのそれぞれについて、プロキシは、それにデータを送信する方法を知る必要がある。たとえば、ユーザは、Palm Pilot^*を使用してプロキシと通信することができ、したがって、規則ファイルから、プロキシがこのエンドデバイスにＭＰＥＧファイルを送信してはならないことが示される可能性がある。しかし、プロキシがＳＤＤＢに照会する時に、ＳＤＤＢは、誰でも使用することができる公共ディスプレイがその部屋にあることを返す。したがって、プロキシは、ＭＰＥＧタグを公共ディスプレイに関連付けることができるパーソナライズ・フォームを作成することができる。ＳＤＤＢは、このディスプレイがデータのストリームまたはＭＰＥＧファイルのどちらを期待するかなど、このディスプレイにアクセスする方法に関する情報も送信しなければならない。
【０１０９】
プロキシがこの「セッション」について知った後には、このセッションに関連するタグ、このセッションに関連するグループ、グループへのタグのデフォルト・マッピング（より正確には、各グループ内のソフトウェア／ハードウェア・デバイスへのタグのデフォルト・マッピング）が既知になる。プロキシは、ＳＤＤＢにセッションを告知しており、１人のユーザすなわちセッション作成者がログ・オンしている。次に、プロキシは、個々のユーザ、各ユーザが属するグループ、および各ユーザに関連するデバイスを見つける。
【０１１０】
プロキシは、元の文書のどのサブセット（どのタグ）を、セッション作成者が受信することができるかを（彼の特権グループおよび彼が使用しているデバイスを与えられて）知る。したがって、プロキシは、このユーザのためにカスタマイズされたＸＳＬ変換ファイルを作成することができる。このファイルによって、元のＸＭＬファイルから、ユーザが受信を許可され、受信することができるタグだけが選択される。その後、どのエンドデバイスが文書の宛先であるかに応じて、その文書をＨＴＭＬに変換するか、エンドユーザに直接に送信することができる。使用されるフォーマットは、上で述べたように、ユーザのデバイスのディスカバリ中に知られる。この時点で、プロキシは、ユーザが見ることを許可されている部分的ビューを送信することができる。
【０１１１】
既存セッションへの参加
図７に示された処理フローのステップ７４０は、既存セッションに参加する新しいユーザまたはデバイスに関する。この参加処理には、図１２に示された、次の６つのステップが含まれる。ステップ１１００で、新しいクライアント位置／ユーザのそれぞれが、それ自体をサービス・ディスカバリ・データベースに登録し、既存のブラウズ・セッションのリストを検索する。ユーザが、セッションが進行中の部屋に来た時、またはリモート講義への参加を望む時に、そのユーザは、まず、そのユーザが所有するすべてのデバイスをサービス・ディスカバリに登録する。次に、ユーザは、サービス・ディスカバリ・データベースから、使用可能なサービスのリストを検索する。プロキシおよびそれがサポートするセッションのリストの例を、図６に示す。プロキシごとに複数のセッションが存在する場合がある。
【０１１２】
次に、新しいユーザが、ステップ１１０２で、既存の共同ブラウズ・セッションの１つへの参加または加入を要求する。ユーザは、ユーザが所望のセッションを手作業で選択できるようにするために表示される、進行中のセッションのリストを受信する。供給される各セッション・レコードは、３つのセッション情報すなわち、プロキシのＩＰアドレス、プロキシのポート番号、およびセッションのＵＲＬからなる。上のセッション・レコードの情報は、手作業または自動的な方法のいずれかによって、サービス・ディスカバリ・インターフェースからユーザのブラウザに転送されなければならない。ユーザは、リストから（上の場合のプロキシの代わりに）セッションを選択する。ブラウザが、プロキシ・パラメータの自動設定およびセッションのＵＲＬの自動取出をサポートする場合には、ユーザのセッション名のクリックに対する応答が、ブラウザ・プロセスの開始、プロキシ・パラメータ・フィールドの初期化、およびセッションのＵＲＬを取り出すことのブラウザへの要求になる。ブラウザが、自動転送をサポートしない場合には、ユーザが、手作業でブラウザを起動し、ブラウザのプロキシ・パラメータ・フィールドを設定し、セッションのＵＲＬを入力しなければならない。
【０１１３】
プロキシ側では、すべてのＵＲＬ要求が代行受信され、要求されたＵＲＬならびにＵＲＬ要求が到着したポート番号に基づいて、プロキシが、要求者が既存セッションへの参加を求めているかどうかと、そうである場合にどのセッションを望んでいるかを確認することができる。要求が参加要求であると判定される場合には、ユーザに、そのセッションの適当なログイン・ページを送信する。
【０１１４】
ステップ１１０３で、プロキシが、潜在的なサブスクライバのそれぞれに、ユーザ名およびパスワードを要求するログイン・メニューを送信する。このログイン・メニューは、エンド・ユーザに送信される。このログイン・メニューは、これ以降サブスクライバと呼ばれるユーザが、セッションを私的に保つためのチェックボックス・オプションを有しないことを除いて、図１１に類似する。ユーザは、他のすべてのフィールドを使用可能にさせ、ユーザ名を入力しなければならず、パスワードの入力または特権グループのクリックのいずれかを行わなければならない。セッションの参加には、セッションの確立より少ない数のステップが含まれることに留意されたい。というのは、セッションの参加では、セッション確立メニューと、最初のＸＭＬページおよびポリシ・ファイルのダウンロードがスキップされるからである。セッション確立処理のフローと同様に、データ・プッシュ・アプレットがダウンロードされ、クライアント内で初期化される。
【０１１５】
プロキシは、ステップ１１０４で、ユーザが共同作業セッションへの参加を許可されることを判定した後に、ステップ１１０５で、サービス・ディスカバリ・データベースに要求を送信する。このサービス・ディスカバリ・データベースへの要求では、新たにログインするユーザに対して登録されたすべてのデバイスのリストが要求される。プロキシは、この情報について新たにログ・インしたユーザに照会することもできるが、上で述べたように、サービス・ディスカバリ・データベースにすでに格納されている使用可能なユーザ・デバイス情報を使用することが好ましい。上で詳細に述べたセッション確立処理と同様に、このステップには、新しいサブスクライバに対して登録されたすべてのデバイスのリストを検索する作業が含まれるが、セッション参加処理のフローでは、セッションをサービス・ディスカバリに告知する必要はない。
【０１１６】
最後に、ステップ１１０６で、プロキシが、１つまたは複数のユーザ・デバイスでの表示のために、新たにログ・インしたユーザに、ウェブ・ページの適当な部分的ビュー（すなわち、文書の１つまたは複数の部分）を返す。ウェブ・ページの部分的ビューは、新しいサブスクライバならびにセッション作成者の両方によってプルされる。というのは、この両方が、そのログイン入力に起因するプロキシからの応答を期待しているからである。さらに、新しいサブスクライバとセッション作成者の両方が、入力許可を有するセッションの他のメンバによって開始されるプッシュ・イベントに応答することができるアプレットをダウンロードしている。別のメンバが新しいページを要求した時に、プロキシは、この更新をセッション・メンバのディスプレイにプッシュするか、新しいデータを、加入したエンドデバイス（スピーカなど）に送信する。
【０１１７】
エンドデバイスがブラウザの場合には、データのプッシュに使用する方法を決定するために、使用されるブラウザのタイプを知る必要がある。登録時に、プロキシは、どのエンドユーザがどのブラウザ・タイプを使用しているかを、ＨＴＴＰヘッダのUser-Agentフィールドの完了によって知る。その後、プロキシは、ブラウザのタイプに従ってデータ・プッシュを開始する方法を知る。ブラウザ以外のデバイスの場合、サービス・ディスカバリによって返される情報は、これらのデバイスにアクセスする方法をプロキシに直接に知らせるものか、エンド・デバイスと通信する方法を知る方法をプロキシに与えるもののいずれかでなければならない。
【０１１８】
副文書からデバイスへのマッピング
サブスクライバが、確立されたセッションに参加した後、またはセッション作成者が、セッション確立を終了した後に、セッションの各参加者は、ユーザの個人的趣味に従って、デバイスへのタグのマッピングを構成することができる。プロキシは、当初、ポリシ・ファイルによって供給される情報を使用して、許可されるタグの許可される出力デバイスへのデフォルト・マッピングを構成する。しかし、このデフォルト・マッピングが、エンド・ユーザを満足させない可能性があり、図７に詳細に示された処理フローのステップ７６０に関して上で注記したように、セッション作成者が、文書部分の出力デバイスへのマッピングを動的に変更することを望む場合がある。セッション作成者は、自分のデバイス上で、自分のために作成されたデフォルト設定を見ることができ、どのタグをどのデバイスに送るかを決定することによって、より微細なレベルでカスタマイズすることを望むことを決定することができる。プロキシによって行われるデフォルト構成は、たとえば、セッションを開始するデバイスが表示できるタグだけを送信する可能性があり、これは、小型デバイスの場合に制限的になる可能性がある。その結果、セッション作成者は、パーソナライゼーション・フォームを使用して、自分にとってより便利なデータの分割を行う。
【０１１９】
パーソナライゼーション・ボタンは、ログアウト・ボタンと共にコントロール・パネル上に配置することができる。ユーザは、１つのブラウザ・ウィンドウ上でセッションの初期化を行うが、プロキシがユーザに部分的なビューを送信する準備ができた時には、プロキシは、それを子ウィンドウで行う。ユーザは、コントロール・パネルを親ウィンドウに送り、ユーザが、２つのウィンドウすなわち、ブラウズ・セッションに追従するウィンドウと１つのコントロール・ウィンドウを有することになる。コントロール・パネルには、ユーザがセッションからログアウトできるようにするボタンが含まれる。ユーザがコントロール・ログアウト・ボタンを呼び出すことによって、プロキシが、このユーザをリストから除去し、彼に適用された変換ファイルのすべてを削除するように指示される。コントロール・パネルには、ユーザが現在の設定に満足しない場合に、パーソナライゼーション・フォームを要求し、タグとデバイスの間の関連付けを変更できるようにする、パーソナライズのためのボタンも含まれる。
【０１２０】
ユーザが、「カスタマイズ」ボタンをクリックする時に、プロキシが、接続され、情報の第３の画面を返す。プロキシは、許可されるマルチメディア・タグの許可される出力デバイスへのマッピングを作成するのに必要なすべての情報を有する。タグは、ＸＭＬファイルから取られる。ユーザの識別およびユーザが関連するグループは、ユーザのログイン／登録から取られる。使用可能なデバイスおよびその所有者のリストは、サービス・ディスカバリから取られる。これによって、プロキシが、許可されるタグの許可されるデバイスへのマッピングを作成できるようになる。このマッピングは、「カスタマイズ」ボタンがクリックされた時にエンド・ユーザに公開され、ユーザは、適当なリストされたデバイスにタグを単純に「プル」して、マッピングを変更することができる。
【０１２１】
通常、ユーザは、セッションにログ・インする前に、複数のデバイスを登録する。しかし、ユーザが、ログ・インの後にデバイスを追加することを望む場合がある。この場合、ＳＤＤＢに登録した後に、新しいデバイスが、メディア供給の受信を自動的に開始し、アプレットが、自動的に更新される。オプションの１つが、コールバック関数（callback()）の使用である。コールバックは、所与のユーザ名に一致するユーザが新しいデバイスを登録したかどうかをプロキシに知らせる／通知するようにサービス・ディスカバリに指示する（ＵＮＩＸのselect()に類似する）関数である。プロキシとクライアントの間のプッシュ／プルの問題に類似して、コールバックでは、サービス・ディスカバリが、新しい更新をプロキシにプッシュすることが許容される。コールバックは、効率的な機構であり、これによって、ユーザごとのプロキシの状態の自動更新も可能になる。しかし、コールバックは、サービス・ディスカバリに対する機能的な重荷を課し、ほとんど、または一部の、サービス・ディスカバリ・プロトコルにまたがってサポートされない可能性がある。
【０１２２】
もう１つのオプションは、エンド・ユーザが受信するカスタマイズ画面上の「最新表示」ボタンを介する手動更新を有することである。ユーザが「カスタマイズ」ボタンをクリックした時には、これが、最新表示と同等になる。しかし、エンド・ユーザが、一時的にカスタマイズ画面を開き、その画面を更新しなかった場合には、カスタマイズ画面に「最新表示」ボタンも含めることが必要になる。カスタマイズ画面の最新表示ボタンを、最初の画面のカスタマイズ・ボタンと組み合わせると、コールバック関数の必要がなくなる。その代わりに、エンド・ユーザが、新しいデバイスが追加された時にプロキシ状態（およびカスタマイズ画面）のすべての更新を手作業で開始する。エンド・ユーザは、基本的に、そのユーザに対して新たに登録されたデバイスに対応するデータを、プロキシを介して、サービス・ディスカバリからカスタマイズ画面にプルする。
【０１２３】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１２４】
（１）サーバから複数のクライアント位置へ文書コンテンツを選択的に供給する方法であって、
前記サーバからプロキシへ少なくとも１つの文書を供給するステップと、
前記少なくとも１つの文書を複数の文書部分に選択的に分割するステップと、
前記複数の文書部分の少なくとも１つを前記複数のクライアント位置のそれぞれに選択的に供給するステップと
を含む方法。
（２）前記少なくとも１つの文書が、少なくとも１つの他のファイルへのリンクを含み、前記方法がさらに、前記プロキシが、前記少なくとも１つの他のファイルを事前取出しし、前記少なくとも１つの他のファイルをキャッシュ記憶するステップを含む、上記（１）に記載の方法。
（３）前記プロキシが、前記少なくとも１つの文書が、関連するポリシ・ファイルを有することを判定するステップと、
前記ポリシ・ファイルにアクセスするステップと
をさらに含む、上記（１）に記載の方法。
（４）前記選択的に分割するステップが、前記ポリシ・ファイルに従って前記文書を文書部分に分割するステップを含む、上記（３）に記載の方法。
（５）前記ポリシ・ファイルが、クライアント・アクセス情報を指定し、前記選択的に供給するステップが、前記クライアント・アクセス情報に基づいて文書部分をクライアント位置に向けるステップを含む、上記（４）に記載の方法。
（６）文書部分を選択的に供給するステップが、前記文書部分のすべてより少ない文書部分を、前記複数のクライアント位置の少なくとも１つに向けるステップを含む、上記（５）に記載の方法。
（７）前記複数のクライアント位置が、１つのクライアント位置でコンテンツを出力するための複数のデバイスを含む、上記（１）に記載の方法。
（８）さらに、前記プロキシが、前記複数のデバイスのそれぞれのコンテンツ出力機能を判定するステップを含む、上記（７）に記載の方法。
（９）前記クライアント位置に関するサービス・ディスカバリを行うステップと、
前記クライアント位置のためのサービス・ファイルを作成するステップと
をさらに含む、上記（７）に記載の方法。
（１０）前記行うステップおよび前記作成するステップが、前記プロキシで実行される、上記（９）に記載の方法。
（１１）さらに、前記プロキシが、前記サービス・ファイルにアクセスするステップを含む、上記（９）に記載の方法。
（１２）前記選択的に分割するステップが、前記コンテンツ出力機能に基づいて、前記文書を文書部分に分割するステップを含む、上記（８）に記載の方法。
（１３）前記選択的に分割するステップが、前記サービス・ファイルに基づいて、前記文書を文書部分に分割するステップを含む、上記（１１）に記載の方法。
（１４）さらに、前記プロキシが、前記文書部分を前記複数のデバイスにマッピングするステップを含む、上記（７）に記載の方法。
（１５）さらに、前記クライアント位置のユーザが、前記マッピングを動的に変更するステップを含む、上記（１４）に記載の方法。
（１６）前記プロキシが、前記複数の文書部分の少なくとも１つをトランスコーディングするステップを追加的に含む、上記（１）に記載の方法。
（１７）前記プロキシが、前記コンテンツ出力機能に基づいて、前記複数の文書部分の少なくとも１つをトランスコーディングするステップを追加的に含む、上記（１２）に記載の方法。
（１８）少なくとも１つの文書を作成するステップと、
前記少なくとも１つの文書を前記サーバで格納するステップと
をさらに含む、上記（１）に記載の方法。
（１９）前記少なくとも１つの文書に関する少なくとも１つのポリシ・ファイルを定義するステップと、
前記少なくとも１つのポリシ・ファイルを前記少なくとも１つの文書に関連付けるステップと
をさらに含む、上記（１８）に記載の方法。
（２０）前記関連付けるステップが、前記ポリシ・ファイルを前記少なくとも１つの文書に組み込むステップを含む、上記（１９）に記載の方法。
（２１）前記少なくとも１つのポリシ・ファイルを定義するステップが、前記文書の前記少なくとも１つの文書の複数の文書部分を指定するステップを含む、上記（１９）に記載の方法。
（２２）前記複数の文書部分のそれぞれのアクセス規則を確立するステップをさらに含む、上記（２１）に記載の方法。
（２３）前記複数の文書部分のそれぞれへのアクセスに関する特権グループを確立するステップをさらに含む、上記（２１）に記載の方法。
（２４）前記特権グループが、前記複数の文書部分のそれぞれにアクセスできるクライアントを識別する、上記（２３）に記載の方法。
（２５）複数のクライアント位置、ウェブ・サーバ、少なくとも１つのサービス・ディスカバリ・データベース、および前記ウェブ・サーバと前記複数のクライアント位置との間に配置される複数のプロキシ・コンポーネントを含むシステム内で、クライアント・セッション要求者からの要求に応答して共同ウェブ・ブラウズ・セッションを確立する方法であって、
前記プロキシが、前記サービス・ディスカバリ・データベースに登録するステップと、
前記セッション要求者が、前記サービス・ディスカバリ・データベースに登録するステップと、
前記セッション要求者が、プロキシを選択するステップと、
前記セッション要求者が、セッションを作成する要求を前記プロキシに送信するステップと、
前記プロキシが、少なくともセッション名と少なくとも１つのセッション文書の記憶位置とを含むセッション情報を要求するステップと、
前記セッション要求者が、前記セッション情報を入力するステップと、
前記プロキシが、前記少なくとも１つのセッション文書を取り出すステップと、
前記プロキシが、前記少なくとも１つのセッション文書に関するプロキシ・ファイルが存在するかどうかに関する判定を行うステップと、
前記プロキシが、前記判定に基づいて、前記少なくとも１つのセッション文書を複数の文書部分に選択的に分割するステップと、
前記プロキシが、前記複数の文書部分を前記複数のクライアント位置の少なくとも１つに選択的に供給するステップと
を含む方法。
（２６）少なくとも１つの新しいユーザが前記セッションに参加するステップをさらに含み、前記参加するステップが、
前記少なくとも１つの新しいユーザが、既存セッションのリストを得るステップと、
前記少なくとも１つの新しいユーザが、前記既存セッションの１つの選択されたセッションを選択し、前記選択されたセッションに参加する要求を生成するステップと、
前記プロキシが、前記少なくとも１つの新しいユーザにログイン・メニューを供給するステップと、
前記プロキシが、前記少なくとも１つの新しいユーザに関するユーザ・アクセスを検証するステップと、
前記プロキシが、ユーザ出力デバイス情報について前記セッション・ディスカバリ・データベースに照会するステップと、
前記プロキシが、前記ユーザ出力デバイス情報に基づいて、前記少なくとも１つの新しいユーザの少なくとも１つのデバイスに、前記複数の文書部分の少なくとも１つを選択的に配送するステップと
を含む、上記（２５）に記載の方法。
（２７）文書コンテンツを複数のクライアント位置に選択的に供給するシステムであって、
複数のクライアント位置と、
前記文書コンテンツを格納し、クライアント要求に応答して少なくとも１つの文書を配送する、少なくとも１つのサーバと、
前記少なくとも１つの文書を前記サーバから受信し、前記少なくとも１つの文書を複数の文書部分に選択的に分割し、前記複数の文書部分の少なくとも１つを前記複数のクライアント位置のそれぞれに選択的に供給する、少なくとも１つのプロキシと
を含むシステム。
（２８）前記少なくとも１つのプロキシが、前記少なくとも１つの文書に関するポリシ・ファイルにアクセスし、前記少なくとも１つの文書を選択的に分割するために前記少なくとも１つのポリシ・ファイルを使用する、少なくとも１つの処理コンポーネントを含む、上記（２７）に記載のシステム。
（２９）前記少なくとも１つのクライアント位置が、１つのクライアント位置にある複数のデバイスを含む、上記（２７）に記載のシステム。
（３０）前記少なくとも１つのクライアント位置が、前記少なくとも１つの文書に関して共同するための複数の異なるクライアント位置を含む、上記（２７）に記載のシステム。
（３１）前記少なくとも１つのプロキシが、少なくとも１つの前記クライアント位置に配置されたデバイスに前記複数の文書部分をマッピングする、少なくとも１つの処理コンポーネントを含む、上記（２７）に記載のシステム。
（３２）サーバから複数のクライアント位置ヘ文書コンテンツを選択的に供給する方法ステップを実行するために計算機によって実行可能な命令のプログラムを具体的に実施する、計算機によって可読のプログラム記憶デバイスであって、前記方法が、
前記サーバからプロキシへ少なくとも１つの文書を供給するステップと、
前記少なくとも１つの文書を複数の文書部分に選択的に分割するステップと、
前記複数のクライアント位置のそれぞれに前記複数の文書部分の少なくとも１つを選択的に供給するステップと
を含む、プログラム記憶デバイス。
【図面の簡単な説明】
【図１】通常のウェブ・ブラウズ・システムの概略図である。
【図２】本発明によるウェブ・ブラウズ・システムの概略図である。
【図３】単独のユーザのウェブ・ブラウズ・セッションが、より高機能の近くの出力デバイスを使用することによって機能強化される、共同マルチデバイス・ウェブ・ブラウズの第１のシナリオを示す図である。
【図４】他のデバイスに加えて、他のユーザが、ブラウズ・セッションの出力の選択された部分を受信する、共同マルチデバイス・ウェブ・ブラウズの第２のシナリオを示す図である。
【図５】本発明によるデータ転送の効率を示す図である。
【図６】新しい共同セッションの確立に用いられるエンティティを示す概略図である。
【図７】本発明の対話の全体的シーケンスを示す図である。
【図８】新しい共同セッションの確立の処理フローの詳細を示す図である。
【図９】新しい共同セッションの確立の処理フローの詳細を示す図である。
【図１０】ウェブ・ページのＵＲＬ要求が新しいブラウズ・セッションの確立をもたらす時をプロキシが決定するための代表的なアルゴリズムを示す図である。
【図１１】プロキシからセッション開始元のブラウザに送信される代表的なログイン／登録画面を示す図である。
【図１２】確立されたセッションに参加する新しいユーザまたはデバイスの代表的な処理フローを示す図である。
【符号の説明】
１０ ユーザ位置
１２ ウェブ・サーバ
１４ インターネット
２０ プロキシ・エンティティ
６１０ プロキシ
６１２ サービス・ディスカバリ
６１４ セッション作成者
６１５ ウェブ・サーバ
６１６ テーブル
６１７ ポリシ・ファイル

Claims (24)

1. サーバから複数のクライアント位置へ文書コンテンツを選択的に供給する方法であって、
   プロキシが、サービス・ディスカバリ・データベースに登録するステップと、
   セッション要求者が、前記サービス・ディスカバリ・データベースにユーザ登録するステップと、
   前記セッション要求者が、登録された前記プロキシを選択するステップと、
   前記セッション要求者が、セッションを作成する要求を前記プロキシに送信するステップと、
   前記プロキシが、少なくともセッション名と少なくとも１つのセッション文書の記憶位置とを含むセッション情報を要求するステップと、
   前記セッション要求者が、前記セッション情報を入力するステップと、
   前記プロキシが、前記少なくとも１つのセッション文書を取り出すステップと、
   前記プロキシが、前記少なくとも１つのセッション文書に関するポリシ・ファイルに関する判定を行うステップと、
   前記プロキシが、前記判定に基づいて、前記少なくとも１つのセッション文書をタグにより選択して複数の文書部分に分割するステップと、
   前記プロキシが、前記複数の文書部分を前記複数のクライアント位置の少なくとも１つにいる前記セッション要求者に選択的に供給するステップと
   を含む方法。
2. 前記方法がさらに、前記プロキシが、前記少なくとも１つの他のファイルを事前取出しし、前記少なくとも１つの他のファイルをキャッシュ記憶するステップを含む、請求項１に記載の方法。
3. 前記選択的に分割するステップが、前記ポリシ・ファイルにのアクセス特権を定義する特権グループに従って前記文書を文書部分に分割するステップを含む、請求項１に記載の方法。
4. 前記選択的に供給するステップが、特権グループに従って前記クライアント・アクセス情報に基づいて文書部分をクライアント位置に向けるステップを含む、請求項３に記載の方法。
5. 文書部分を選択的に供給するステップが、前記文書部分のすべてより少ない文書部分を、前記複数のクライアント位置の少なくとも１つに向けるステップを含む、請求項４に記載の方法。
6. 前記複数のクライアント位置が、１つのクライアント位置でコンテンツを出力するための複数のデバイスを含む、請求項１に記載の方法。
7. さらに、前記プロキシが、前記複数のデバイスのそれぞれのコンテンツ出力機能を判定するステップを含む、請求項６に記載の方法。
8. 前記クライアント位置に関するサービス・ディスカバリを行うステップと、
   前記クライアント位置のためのサービス・ファイルを作成するステップと
   をさらに含む、請求項６に記載の方法。
9. 前記行うステップおよび前記作成するステップが、前記プロキシで実行される、請求項８に記載の方法。
10. さらに、前記プロキシが、前記サービス・ファイルにアクセスするステップを含む、請求項８に記載の方法。
11. 前記選択的に分割するステップが、前記コンテンツ出力機能に基づいて、前記文書を文書部分に分割するステップを含む、請求項７に記載の方法。
12. 前記選択的に分割するステップが、前記サービス・ファイルに基づいて、タグにより選択して前記文書を文書部分に分割するステップを含む、請求項１０に記載の方法。
13. さらに、前記プロキシが、前記文書部分を前記複数のデバイスにマッピングするステップを含む、請求項６に記載の方法。
14. さらに、前記クライアント位置のユーザが、前記マッピングを動的に変更するステップを含む、請求項１３に記載の方法。
15. 前記プロキシが、前記複数の文書部分の少なくとも１つをトランスコーディングするステップを追加的に含む、請求項１に記載の方法。
16. 前記プロキシが、前記コンテンツ出力機能に基づいて、前記複数の文書部分の少なくとも１つをトランスコーディングするステップを追加的に含む、請求項１１に記載の方法。
17. 少なくとも１つの文書を作成するステップと、
    前記少なくとも１つの文書を前記サーバで格納するステップと
    をさらに含む、請求項１に記載の方法。
18. 前記少なくとも１つの文書に関するアクセス特権を定義する特権グループを含む少なくとも１つのポリシ・ファイルを定義するステップと、
    前記少なくとも１つのポリシ・ファイルを前記少なくとも１つの文書に関連付けるステップと
    をさらに含む、請求項１７に記載の方法。
19. 前記関連付けるステップが、前記ポリシ・ファイルを前記少なくとも１つの文書に組み込むステップを含む、請求項１８に記載の方法。
20. 前記少なくとも１つのポリシ・ファイルを定義するステップが、前記文書の前記少なくとも１つの文書の複数の文書部分を指定するステップを含む、請求項１８に記載の方法。
21. 前記特権グループが、前記複数の文書部分のそれぞれにアクセスできるクライアントを識別する、請求項２０に記載の方法。
22. 複数のクライアント位置、ウェブ・サーバ、少なくとも１つのサービス・ディスカバリ・データベース、および前記ウェブ・サーバと前記複数のクライアント位置との間に配置される複数のプロキシ・コンポーネントを含むシステム内で、クライアント・セッション要求者からの要求に応答して共同ウェブ・ブラウズ・セッションを確立する方法であって、
    前記プロキシが、前記サービス・ディスカバリ・データベースに登録するステップと、
    前記セッション要求者が、前記サービス・ディスカバリ・データベースにユーザ登録するステップと、
    前記セッション要求者が、登録された前記 プロキシを選択するステップと、
    前記セッション要求者が、セッションを作成する要求を前記プロキシに送信するステップと、
    前記プロキシが、少なくともセッション名と少なくとも１つのセッション文書の記憶位置とを含むセッション情報を要求するステップと、
    前記セッション要求者が、前記セッション情報を入力するステップと、
    前記プロキシが、前記少なくとも１つのセッション文書を取り出すステップと、
    前記プロキシが、前記少なくとも１つのセッション文書に関するポリシ・ファイルに関する判定を行うステップと、
    前記プロキシが、前記判定に基づいて、前記少なくとも１つのセッション文書をタグにより選択して複数の文書部分に分割するステップと、
    前記プロキシが、前記複数の文書部分を前記複数のクライアント位置の少なくとも１つにいる前記セッション要求者に選択的に供給するステップと
    を含む方法。
23. 少なくとも１つの新しいユーザが前記セッションに参加するステップをさらに含み、前記参加するステップが、
    前記少なくとも１つの新しいユーザが、既存セッションのリストを得るステップと、
    前記少なくとも１つの新しいユーザが、前記既存セッションの１つの選択されたセッションを選択し、前記選択されたセッションに参加する要求を生成するステップと、
    前記プロキシが、前記少なくとも１つの新しいユーザにログイン・メニューを供給するステップと、
    前記プロキシが、前記少なくとも１つの新しいユーザに関するユーザ・アクセスを検証するステップと、
    前記プロキシが、ユーザ出力デバイス情報について前記セッション・ディスカバリ・データベースに照会するステップと、
    前記プロキシが、前記ユーザ出力デバイス情報に基づいて、前記少なくとも１つの新しいユーザの少なくとも１つのデバイスに、前記複数の文書部分の少なくとも１つを選択的に配送するステップと
    を含む、請求項２２に記載の方法。
24. 請求項１から２３のいずれかの１つに記載の方法のステップをコンピュータに実行させるためのコンピュータプログラム。

Images