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

Abstract

(57)【要約】 （修正有） 【課題】 モバイルと固定式の両方の複数のネットワー
ク化されたデバイスが互いに共同作業できるようにする
ことによって、モバイルのネットワーク化されたデバイ
スの機能性を強化する。 【解決手段】 アクセス特権のレベルに従って、ウェブ
・コンテンツのユーザに表示される部分へのアクセスを
選択的に提供し、異なるユーザ指定デバイスでの表示の
ためにウェブ・コンテンツの異なる部分を送信する。プ
ロキシ・エンティティが、ウェブ・サーバとユーザ位置
の間に導入される。複数のユーザに提示される文書は、
複数の特権グループを定義するポリシ・ファイルを有す
る。各特権グループは、タグの異なるセットへのアクセ
ス権を有する。各ユーザは、所与のグループにログ・イ
ンし、そのユーザが所有するデバイスのすべてを、サー
ビス・ディスカバリを介してプロキシに識別する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、全般的には、コン
テンツのウェブベース・ブラウズに関し、具体的には、
コンテンツのうちで、複数のユーザ位置の１つに選択的
に供給される部分のユーザ表示および対話に関する。

【０００２】

【従来の技術】グループウェア・アプリケーションは、
複数のリモート位置から単一の文書に対して行われる共
同作業の必要をサービスするために開発された。たとえ
ば、複数の会社従業員が、全世界のめいめいのオフィス
からプレゼンテーションを見ることができ、複数の学生
が、めいめいのリモート位置にあるワークステーション
から教授の講義に「出席」することができる。ほとんど
の入手可能なグループウェア・アプリケーションは、イ
ントラネット・ベースであり、中央の会社または大学を
ベースとするサーバが、文書をロードし、文書へのアク
セスを管理する。イントラネット・グループウェア・モ
デルのワールドワイド・ウェブへの拡張が、最近の研究
開発の対象になってきた。ワールドワイド・ウェブの最
適利用として複数当事者の共同作業能力を提供し、これ
によって、複数のユーザが単一の文書を同時に表示でき
るようにすることが望ましい。

【０００３】University of North Carolinaでのプロジ
ェクト（Ｄ．ストッツ（Stotts）、Ｊ．プリンズ（Prin
s）、Ｌ．ナイランド（Nyland）、Ｔ．ファン（Fan）共
著、「CobWeb: Tailorable, Analyzable Rules for Col
laborative Web Use」を参照されたい）で、共同ウェブ
・ブラウズ・システムの１バージョンが教示されてい
る。ストッツ他のプロジェクトの目標は、世界中の別々
のワークステーションで作業する複数の個人（リーダー
と部下達）が、共同でウェブをブラウズできるようにす
ることである。部下達は、リーダーが取り出したウェブ
・ページを見ることができ、すべての参加者が、共用ホ
ワイトボードを介して通信することができる。リーダー
と聴衆の間の対話は、セッションの始めに選択される共
同作業プロトコルによって決定される。プロトコルの選
択によって、どのアプレットをユーザに送信するかが決
定される。プロトコルには、講義と会議の２つがあり、
これらは、参加者に提供される機能のセットに相違があ
る。たとえば、ウェブ講義プロトコルでは、ユーザが
「先導する」か「中断する」（そのユーザが当面は講師
のビューを受信することを望まないことを意味する）こ
とを行わせるボタンが、ユーザに表示される。ウェブ会
議プロトコルでは、これと同一の機能がユーザに提供さ
れない。たとえば、ウェブ会議プロトコルでは、「発言
権を得る」または「人物を加える」などの機能を有する
ボタンがある。ストッツ他のシステムが提供しないもの
は、すべてではないコンテンツをすべてではないユーザ
またはユーザのデバイスに供給する機構である。

【０００４】もう１つのグループウェア・モデルが、VI
EW Media^*（これおよびこれ以降のアスタリスク^*は、こ
の文書全体を通じて、指定された単語がめいめいの所有
者の商標である可能性があることを示す）共同ハイパー
メディア・システムであり、これは、共用される文書に
対する各ユーザのアクセス権に基づいて、会議システム
が、異なるユーザが得ることのできる共用される文書の
ビューを制限できるようにするシステムである（Ｙ．ヨ
コタ（Yokota）、Ｔ．ナカムラ（Nakamura）、Ｈ．タル
ミ（Tarumi）、Ｙ．カンバヤシ（Kambayashi）共著、
「Multiple Dynamic View Support for Cooperative Wo
rk」、Proc. of IEEE Int'l Conf. on Database System
s 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-Base
dAlgorithm Animation System for an Electronic Clas
sroom」、IEEE Symposiumon Visual Languages、１９９
６年、第２６６ページ〜２７５ページを参照された
い）。講師の画面に、同一のアルゴリズムの複数のアニ
メーション・ビューを、アニメーションを調整する（た
とえば速度）ための制御画面と共に含めることができ
る。各学生は、同一のウェブ・ページをポイントし、ア
ニメーションの複数のビューを受信するが、制御画面は
見ない。アニメーションは、シーケンス内の興味のある
ポイントを識別する特殊な言語で記述される。ダウンロ
ードされたクライアント側アプレットが、興味のある点
を受信し、これに反応する。この形で、講師は、アニメ
ーションのペースを制御するが、学生は、その学生が見
るビューを制御する。各学生は、講師および他の学生と
独立に、彼自体のビューと対話することができる。しか
し、講師がウェブ・ページを変更する場合には、すべて
の学生が、新しいアニメーションを受信するために、そ
の新しいウェブ・ページに手作業で変更しなければなら
ない。しかし、望ましいものは、講師がページを変更し
た後に、聴衆の中のユーザが、新しいウェブ・ページを
自動的に受け取ることができるようにすることである。
ブラウン他の作品のもう１つの短所は、複数のビュー
が、作成者によって先験的に構成されることである。基
礎のウェブ・ページの副文書への切り分けに基づいて、
複数のビューを「オンザフライ」で作成することを提供
することが望ましい。

【０００６】ビデオ会議アプリケーションの共用リモー
ト・コントロールが、Ｔ．ホーデス（Hodes）、Ｍ．ニ
ューマン（Newman）、Ｓ．マッケイン（McCanne）、
Ｒ．カッツ（Katz）、およびＪ．ランデイ（Landay）共
著、「Shared Remote Control ofa Video Conferencing
Application: Motivation, Design, and Implementati
on」、SPIE Multimedia Computing and Networking（Ｍ
ＭＣＮ）, Proc. SPIE, vol. 3654、１９９８年（会議
は１９９９年１月に開催）、第１７ページ〜２８ページ
で提案された。ＰＤＡが、ビデオ会議アプリケーション
「ｒｖｉｃ」（remote video conferencing）を操作す
るためのリモート・コントロールとして使用される。ホ
ーデス他は、サービス・ディスカバリ機構も記述してい
る。ホーデス他のリモート・コントロールのアプリケー
ションは、ストリーミング会議アプリケーションに対処
するが、ウェブには対処していない。

【０００７】http://graphics.stanford.edu/projects/
iwork/にある論文でフォックス（Armando Fox）教授が
説明しているスタンフォード大学のInteractive Worksp
ace Projectでは、「マルチブラウズ（multi-browsin
g）」という概念が導入されている。このプロジェクト
の目標は、マルチデバイス、マルチユーザ環境を用いる
実験であり、具体的には、すべての種類の作業をある計
算装置から別の計算装置に移動することと、グループ対
話をサポートし、促進することである。そのようなシス
テムの下で、ユーザは、直列化された形で複数のデバイ
スと対話する。たとえば、ユーザが、室内で移動する際
に、彼のアプリケーションを見るかタスクを完了するた
めに彼が対話しているデバイスが変化する。それぞれが
同一の文書を表示する複数のデバイスを並列に使用する
という概念もある。主に、このプロジェクトは、各ディ
スプレイ上で異なる絵を見ることができる壁掛けディス
プレイに焦点を合わせている。たとえば、スライド・プ
レゼンテーションの場合、プレゼンテーションの異なる
ページが、異なるスクリーンに現われ、ユーザが移動す
る際に、プレゼンテーションがそのユーザに追従する。
このプロジェクトは、室内インフラストラクチャとの対
話方法により多くを投資しており、位置情報を得るため
にセンサを用いる。

【０００８】Ｊ．レキモト（Rekimoto）著、「A Multip
le Device Approach for Supporting Whiteboard-based
Interactions」、Human Factors in Computing System
s（ＣＨＩ）、１９９８年、第３４４ページ〜３５１ペ
ージに詳細に示されているように、１つまたは複数のＰ
ＤＡとディジタル・ホワイトボードの間の対話が実施さ
れた。最初の例で、レキモトは、ユーザがあるコンピュ
ータの画面上でオブジェクトを「ピック」し、別のコン
ピュータの画面にドロップできるシステムを記載してい
る。第２の例では、レキモトは、ユーザがＰＤＡ上で描
画し、その後、新たに描画されたオブジェクトを、同一
のペンを使用してＰＤＡからディジタル・ホワイトボー
ドに「ピックアンドドロップ」できるようにするシステ
ムの実例を示している。ＰＤＡは、ブラシ・タイプおよ
びペンの色を設定するのにも使用され、画面上のオブジ
ェクトの外見属性を変更することができる。この形で、
ＰＤＡが、ホワイトボード・アプリケーションを操作す
るためのリモート・コントロールとして使用される。

【０００９】MIT Media Labの「Let's Browse」^*システ
ムでは、Ｈ．リーバーマン（Lieberman）、Ｎ．バン−
ダイク（Van Dyke）、およびＡ．ビバクア（Vivacqua）
共著、「Let's Browse: a collaborative browsing age
nt」、Knowl. Based Syst. (UK), Vol.12, No. 8、１９
９９年１２月、第４２７ページ〜４３１ページに記載さ
れているように、もう１つの形の共同ウェブ・ブラウズ
が実施される。「Let's Browse」システムでは、各ユー
ザが、好ましいウェブ・ページのプロファイルを有す
る。ユーザが、ウェブ・ブラウズ・コンピュータに近接
している時に、コンピュータ上のエージェントが、その
ユーザのプロファイルに一致するウェブ・ページを事前
に取り出す。一緒にブラウズ・セッションを見ている複
数のユーザがいる時には、エージェントは、ユーザの興
味の交わりと一致するページを見つける。リーバーマン
他は、１つまたは複数のユーザからのアクティブ入力
と、各ユーザのプロファイルの更新に対するそのアクテ
ィブ入力の影響も企図している。

【００１０】もう１つの共同作業システムが、RealNetw
orks^*社によって提供された。RealPresenterと称するそ
の製品は、複数の受信側が、ウェブ・プレゼンテーショ
ンを見られるようにし（http://www.realnetworks.com/
products/presenterplus/info.htmlを参照されたい）、
ニュース放送者が、プレゼンテーションの各スライド
（または一部のビデオ）と共にナレーションを記録でき
るようにする。ニュース放送者は、その後、プレゼンテ
ーションをRealMedia^*文書に変換し、ウェブ・サーバに
アップロードし、このウェブ・サーバで、誰もが自分の
ローカル・コンピュータからその文書にアクセスでき
る。

【００１１】ウェブ・サイトhttp://web.calstatela.ed
u/ats/real/develop/broadcast.htmで見ることができ
る、RealPresenter^*の生放送版もある。生版では、ユー
ザがプレゼンテーション・リンクをクリックする場合
に、ユーザは、ニュース放送者がRealPresenterソフト
ウェアを使用して自分のデスクで行っている生のプレゼ
ンテーションを受信する。音声およびスライド・データ
は、RealServer^*に送信され、このRealServer^*が、デー
タをストリーム化して、リンクをクリックしたすべての
人に送る。この製品で追加的に望ましいものは、個々の
所有者の複数のデバイスの間で出力を分割し、いくつか
の特権グループの概念を用いてアクセスを規制すること
ができるようにすることである。

【００１２】Microsoft社のNetMeeting^*（ウェブ・サイ
トhttp://www.microsoft.com/catalog/display.asp?sit
e=113&subid=22&pg=1で見ることができる）を用いる
と、参加者が、リアル・タイムで共同作業し、Windows
文書を共用することができる。すべてのユーザが、標準
データ会議プロトコルＴ１２０を使用して、自分の画面
で同一の情報を見る。

【００１３】Netscape Conference^*（ウェブ・サイトｈ
ｔｔｐ://www.aibn.com/help/Software/Netscape/Commu
nicator/Conference/browsing.htmlで見ることができ
る）は、２人がインターネットを介して同時に同一のウ
ェブ・ページを見られるようにし、各自がいつでもブラ
ウザの制御を得ることができる、共同ブラウズ機能を提
供する。標準ビデオ会議プロトコル（Ｈ．３２３）が使
用される。Netscape Conference^*も、情報交換に使用さ
れるホワイトボードを提供する。

【００１４】WebEx.com^*で見つかるもう１つのサービス
は、複数のユーザがオンラインで共通のプレゼンテーシ
ョンに従うことを可能にする（http://www.webex.comを
参照されたい）。ブラウズするユーザの画面が、取り込
まれ、WebEx.comのサーバに送信され、そこで、その画
面が、会議セッションの他のユーザに中継される。この
システムは、誰が発言権を有するかを制御する機構をサ
ポートし、ウェブ・ページだけではなく、すべてのアプ
リケーションの文書（たとえばMicrosoft Excel^*文書ま
たはＰＤＦ文書）について使用することができる。

【００１５】もう１つのシステム、Yahoo!^* Gamesは、
複数のユーザが、同一のゲームを見られるようにし、ウ
ェブベースの参加機構を有する。対話型オンライン・ゲ
ームは、しばしば、部分的なビューが可能である。たと
えば、x-trek^*などのゲームでは、他のプレイヤが見る
ことのできないインスタント・メッセージを友人と交換
することができる。しかし、そのような選択的コンテン
ツ表示は、ウェブベースではなく、ＨＴＴＰではないプ
ライベート・プロトコルに基づく。さらに、これらのオ
ンラインの労作は、複数の出力デバイスの間で出力を分
割しない。

【００１６】追加的に望ましいものは、コンテンツの異
なる部分が異なるユーザに使用可能にされる、ウェブベ
ース共同作業システムおよびウェブベース共同作業方法
である。上で参照した機構は、その機能を有しない。さ
らに、複数の小さいクライアント・デバイスへの出力を
分割することが望ましい。たとえば、ユーザの要求元デ
バイスがセル電話である場合には、小さいセル電話のデ
ィスプレイおよびその制限されたオーディオ機能を使用
して、要求されたコンテンツにアクセスすることが実用
的でない場合がある。むしろ、ユーザは、関連するテレ
ビジョン画面またはコンピュータ・モニタに視覚的コン
テンツを表示させ、オーディオをフル・レンジ・ステレ
オ・システムに配送させることを望む可能性がある。

【００１７】ビデオ会議の共通規格には、パケット交換
網／ＩＰネットワークを介するオーディオ／ビデオ会議
用のＨ．３２３ならびにＴ．１２０が含まれる。ウェブ
・コンテンツに注釈を付けてトランスコーディングを可
能にするための、Ｗ３Ｃに対する提案、「Annotation o
f Web Content for Transcoding」［Ｗ３Ｃ］がある。
この手法では、コンテンツに、メタデータを用いて注釈
が付けられ、このメタデータによって、ダウンストリー
ム・エンティティまたはサーバのいずれかに、各コンポ
ーネントの重要性と、エンド・デバイスでの表示のため
にそのコンポーネントをトランスコードする方法が説明
される。したがって、この労作は、ウェブ・コンテンツ
を、受信側デバイスの機能に適応させることを試みてい
る。Ｗ３Ｃ提案では、ウェブ・コンテンツが、ＸＭＬで
記述され、トランスコーディング規則の定義にＲＤＦ
（resource description framework）ファイルを使用す
ることが前提になっている。このファイルでは、エンド
デバイスの機能に対して送るべきものの規則が、それを
必要とするコンポーネント（画像ファイルまたはビデオ
・ファイルなど）について定義される。しかし、この注
釈は、文書の分割を許容しない。この適応からもたらさ
れるウェブ・ページは１つだけであり、そのページがエ
ンド・デバイスに送信される。

【００１８】パーソナル・デバイスで現れつつある傾向
は、ユーザがいつでもどこにでも持ち運び、使用するこ
とができる、より小さくポータブルなデバイスに向かっ
ている。ＰＤＡなどのモバイル・デバイスは、しばし
ば、機能の小さいセットだけをサポートするように技術
的に制限され、たとえば、ＰＤＡは、小さい画面を有
し、オーディオがなく、これによって、テキストのみの
サポートに制限される場合がある。ハードウェア制限の
ほかに、このようなモバイル・デバイスは、独立の切断
されたモードで働く時に、限られた機能性を有する。Ｐ
ＤＡは、日程表および住所録などの非常に有用なアプリ
ケーションをサポートするが、ＰＤＡが提供することの
できる機能は、切断された時のデバイスの機能性によっ
て固有の形で制限される。ネットワーク接続性をポータ
ブル・デバイスに統合することによって、モバイル・デ
バイスのユーザが、ネットワークによって供給すること
のできるアプリケーションのはるかに豊富なセットにア
クセスできるようになり、たとえば、ユーザは、自分自
身のデスクトップ・アプリケーション、電子メール、お
よびウェブにアクセスでき、ネットワーク化されたＰＤ
Ａまたは機能強化されたセル電話を介して他のユーザと
接触することができる。

【００１９】

【発明が解決しようとする課題】前述に鑑みて、必要な
もの、したがって本発明の目的は、モバイルと固定式の
両方の複数のネットワーク化されたデバイスが互いに共
同作業できるようにすることによって、モバイルのネッ
トワーク化されたデバイスの機能性を強化するシステム
および方法である。

【００２０】本発明のもう１つの目的は、複数の固定式
デバイスおよびモバイル・デバイスの集合として定義さ
れる、単一のアプリケーションの出力を共同環境内でデ
バイスのそれぞれの間で選択的に配布できる、仮想計算
機を提供することである。

【００２１】

【課題を解決するための手段】前述および他の目的は、
アクセス特権のレベルに従って、ウェブ・コンテンツの
ユーザに表示される部分へのアクセスを選択的に提供
し、異なるユーザ指定デバイスでの表示のためにウェブ
・コンテンツの異なる部分を送信する、共同作業システ
ムおよび共同作業方法を提供する本発明によって実現さ
れる。本発明のウェブ・ブラウズのシステムおよび方法
は、マルチメディア出力を要求元デバイスに制限せず、
エンド・ユーザが、ウェブ・コンテンツを受信するデバ
イスを選択でき、ウェブ・コンテンツを表示するために
共同作業する複数のデバイスを選択することも可能にす
る。たとえば、コンテンツのサウンド部分を、高品質ス
ピーカに送信することができ、それと同時に、ビデオ部
分をテレビジョン画面に送信することができ、これによ
って、ユーザが、ウェブ・ページの各コンポーネントの
再生または表示に使用可能な最適（品質または便利さに
よる）のデバイスを選択できるようにする。その結果、
共同マルチデバイス・ウェブ・ブラウズを用いると、エ
ンド・ユーザが、コンテンツまたはそのコンテンツの部
分をサービスするのにより適した、より高いまたは異な
る出力機能性を有する他の近くの出力デバイスを利用す
ることによって、要求元デバイスの限られた機能性（た
とえばセル電話の小さいディスプレイ）を克服できるよ
うになる。各デバイスの機能性が、これによって、複数
のデバイスの共同作業から生じる仮想計算機を作成する
ことによって機能強化される。

【００２２】ウェブ・ページのコンテンツの全体または
一部のいずれかを、複数のエンド・ユーザに送信するこ
ともできる。本発明の共同マルチデバイス・ウェブ・ブ
ラウズを用いると、ウェブ・ページのコンテンツを、人
間のグループ全体に自動的に配布することができる（グ
ループの１人だけがそれを要求した場合に）。グループ
のメンバは、各自の特権レベルに応じて、ページ全体ま
たはページの一部だけを受信することができる。たとえ
ば、授業を行う教師の場合、教師は、ナビゲーション・
バーを用いてスライドの間でナビゲートできなければな
らないが、学生は、講義中にナビゲーションを変更でき
てはならない。この場合、システムは、学生からナビゲ
ーション・バーを隠すはずである。というのは、学生
が、教師と同一の特権レベル・グループに属さないから
である。このシステムおよび方法は、これによって、一
部のユーザが文書の部分的なビューだけを受信するの
で、ウェブ・セッションの参加者の間の制御された対話
性を導入する。

【００２３】共同マルチデバイス・ウェブ・ブラウズで
は、どのデバイスまたはどのユーザが、ウェブ・コンテ
ンツのどの部分を受信することになるかの決定が、ＸＭ
Ｌ文書ごとにその文書の作成時にウェブ作成者によって
記述されたポリシ・ファイルを使用して、セッションの
開始時に動的に行われる。ポリシ・ファイルには、複数
の特権グループを定義する規則を含む、ＸＭＬウェブ・
ページ上のメタデータが含まれる。各特権グループは、
タグの異なるセットへのアクセス権を有する。各ユーザ
は、所与のグループにログ・インし、そのユーザが所有
するデバイスのすべてを、サービス・ディスカバリを介
してプロキシに識別する。この情報のすべてを与えられ
て、プロキシは、許可される出力デバイスへの許可され
るタグの総合マッピングを構成することができる、すな
わち、ユーザがアクセスを許可されるタグのそれぞれ
が、ユーザが所有するかアクセスを許可される１つまた
は複数の出力デバイスにマッピングされる。

【００２４】異なるデバイスおよびエンド・ユーザに送
信される副文書を作成するために、ウェブ・コンテンツ
を、好ましくはＸＭＬを使用して、トランスコーディン
グする。変換を適用して適当なタグを選択し、適当な出
力フォーマット、通常はＨＴＭＬ、ＸＭＬ、ＷＭＬなど
の、またはスピーカに送られるエンコードされたオーデ
ィオのストリームなどの非テキスト・フォーマットの、
文書を作る。各デバイスによって期待されるコーデック
・フォーマットについて知るために、サービス・ディス
カバリを実行する。

【００２５】マルチデバイス・ウェブ・ブラウズの処理
全体が、ユーザから透過的に行われるが、エンド・ユー
ザが見ることを許可されるタグのそれぞれがどこに表示
されるかに関して、そのユーザにある程度の制御が与え
られる。マルチデバイス・ウェブ・ブラウズ・プロキシ
は、タグおよびユーザがそのそれぞれについて有するデ
バイスの選択のリストと共に、アプレットをユーザに送
信する。エンドユーザは、ユーザの位置での最適表示の
ためにタグとデバイスのより便利な関連付けを選択する
ことによって、グループ・セッションをパーソナライズ
することができる。

【００２６】

【発明の実施の形態】以下の説明のために、本発明のシ
ステムおよび方法は、ウェブ・クライアントがユーザの
計算機上でローカルに稼働し、ウェブ・サーバがインタ
ーネット内でリモートに稼働する通常のウェブ・ブラウ
ズ応用例に適用されると仮定する。ユーザが、ウェブ・
ブラウザを介してウェブ・ページを要求する時に、その
要求が、適当なウェブ・サーバに送信され、そのウェブ
・サーバが、ウェブ・ブラウザに直接に文書を返す。ウ
ェブ・ブラウザには、返されたコンテンツに含まれるＨ
ＴＭＬを解析し、レンダリングするのに十分な知能が含
まれる。用語「ウェブ・ページ」および「ウェブ文書」
は、交換可能に使用することができ、ウェブ・ページま
たはウェブ文書のコンテンツは、それに対するアクセス
が選択的に制御される「部分」または「副文書」に選択
的に分割される。本発明の好ましい実施形態は、ウェブ
文書がＸＭＬを使用して作成されることを必要とし、以
下の説明では、言語としてのＸＭＬの使用を前提とす
る。本発明は、ＨＴＭＬで供給される文書に適用できる
ことに留意されたい。しかし、本発明の目的のいくつか
は、ＨＴＭＬ文書と共に動作する時には実現できない。

【００２７】図１は、通常のウェブ・ブラウズ実施形態
の概略図である。図１を参照すると、ユーザ位置１０に
いるユーザ（図示せず）が、インターネット１４を介し
てウェブ・サーバ１２からコンテンツを得る。コンテン
ツは、ユーザ位置ブラウザ１６で受信された後に、表示
コンポーネント１７での視覚的表示またはオーディオ表
示コンポーネント１８でのオーディオ・レンダリングも
しくはその両方の形でユーザに「配布」される。共同環
境では、このモデルが、１つのユーザ位置の複数の表示
コンポーネントだけではなく、複数のユーザ位置を含む
ように拡張される。

【００２８】本発明の共同マルチデバイス・ウェブ・ブ
ラウズの背後にあるアイデアは、まずウェブ文書を独立
の部分に分割し、次にこれらの部分を表示のために選択
的に配送することである。共同作業の主題は、複数のレ
ベルで適用される。第１に、ウェブをブラウズしている
ユーザが１人だけの時には、共同作業の概念は、仮想計
算機を形成するために共同作業する互いに近接した複数
のクライアント・デバイスに適用される。各ウェブ文書
の部分が、ウェブ・ブラウズ・セッションを開始した要
求元デバイスの近くに配置されている、この仮想計算機
の複数のクライアント・コンポーネントの間で分離され
る。この種の共同マルチデバイス・ウェブ・ブラウズに
よって、単独ユーザのウェブ・ブラウズ体験が豊かなも
のになる。第２に、複数の人間のユーザがいる時には、
共同作業の概念が、ユーザ位置にまたがって適用され
る。その結果、ウェブ文書の部分を複数のローカル・デ
バイスにサービスできるだけではなく、ウェブ文書の部
分を、地理的に隔たって分散したものとすることができ
る複数のユーザに、各ユーザの設定および許可に従って
同時にサービスすることもできる。

【００２９】共同マルチデバイス・ウェブ・ブラウズの
鍵になる前提条件の１つが、ユーザならびにデバイスの
両方が、そのサービスを登録する手段ならびに、他者に
よって登録されたサービスを発見する手段を有しなけれ
ばならないことである。ユーザおよびデバイスの登録お
よびディスカバリの機構は、ＳＬＰ（Service Location
Protocol）、Sun Microsystems^*社のJini^*、Bluetooth
^*のＳＤＰ（Service Discovery Protocol）、Microsoft
^*社のＵＰ＆Ｐ^*（Universal Plug and Play）などによ
って提供されるものなどの、サービス・ディスカバリ・
プロトコルおよびミドルウェア・レジストリを必要とす
る。複数のユーザが、ウェブ・ブラウズ・セッションに
ついて登録し、その後、セッション・プレゼンタによっ
て制御されるセッションに追従することができる。各デ
バイスも、その機能を公示することができると仮定され
る。

【００３０】機能に関するデバイス入力を受信し、ウェ
ブ・コンテンツを受信し、解析するために設けられるの
が、図２に示されたプロキシ・エンティティ２０であ
り、これは、ウェブ・サーバ１２とユーザ位置１０の間
に配置される。プロキシは、ウェブ文書の形のウェブ・
サーバからの入力、およびユーザ位置デバイス機能情報
の形のユーザ位置からの入力を受信するように適合され
ている。下でさらに説明するように、プロキシは、入力
情報を使用して、ユーザ・アクセス特権情報およびデバ
イス機能情報に従って、ウェブ文書の諸部分へのアクセ
スを選択的に制御する。

【００３１】図３に、共同マルチデバイス・ウェブ・ブ
ラウズの第１のシナリオすなわち、より高機能の近くの
出力デバイスを使用することによる単独ユーザのウェブ
・ブラウズ・セッションの拡充を示す。これは、ウェブ
文書のうちで、元のデバイスが効果的にサポートできな
い部分の再生または表示のために他の近くの出力デバイ
スを活用することによって、ウェブ・ブラウズに使用さ
れる元のデバイスの機能を拡張するという発想である。
たとえば、家庭環境では、ユーザが、小さい画面、低い
解像度、およびおそらくはサウンド・サポートのないＰ
ＤＡなどのユーザ要求元デバイス３０からウェブのブラ
ウズを開始する可能性がある。高品質スピーカ、ラジオ
３２、およびテレビジョン３４が近くにあり、両方がた
とえば短距離無線接続性を提供するBluetooth^*チップを
備えている場合には、ユーザは、ウェブ・コンテンツの
サウンド部分をスピーカに、グラフィカル・コンテンツ
をテレビジョン画面に送ること決定することができる。
ユーザは、ウェブをナビゲートするためのリモート・コ
ントロールとして、元のＰＤＡを使用し続けることがで
きる。周囲の入出力周辺機器を用いて、限られたモバイ
ル・デバイスの機能を拡張する能力によって、ユーザの
ブラウズ体験が豊かになる。ユーザは、どの出力データ
／ストリームをどの出力デバイスで再生／表示するかを
制御することもでき、ビデオ画像をテレビジョン３４に
送りながら、静止画像を、ＰＣ ３６のモニタ上での表
示のために送るか、プリンタ３８でハード・コピーとし
て出力するために送ることもできる。

【００３２】図４に、共同マルチデバイス・ウェブ・ブ
ラウズの第２のシナリオすなわち、他のデバイスに加え
て、他のユーザが、ブラウズ・セッションの出力を受信
できるようにすることによるウェブ・ブラウズ体験の拡
充を示す。図４に示されたシナリオでは、講師が、ウェ
ブ・サーバに格納されるウェブ・プレゼンテーション４
００を記述し終えており、このプレゼンテーションを、
おそらくは電話会議、会議室、または講演ホールで他の
ユーザに見せることを所望している。講師は、講義位置
４１０に到着することができ、この講義位置４１０は、
すでに、スピーカ４１３を、ラップトップ・コンピュー
タ４１１およびWinCE^*デバイス４１２と共に備え、後者
を用いて、講師が、プレゼンテーション中に自由に歩き
回ることができる。この場合、概略的に示されているウ
ェブ・プレゼンテーション４００には、視覚表示部分４
１７、オーディオ表示部分４１４、ナビゲーション・バ
ー４１６、および講師のメモ４１５が含まれる。forwar
d／back（進む／戻る）ボタンを有するナビゲーション
・バー４１６は、WinCEデバイスおよび講師のラップト
ップ・コンピュータだけに送信される。それと同時に、
講師は、グラフィカル・スライドである視覚表示部分４
１７を、講師のラップトップ機に送信させ、その結果、
そのスライドを講演ホールの大きい画面（図示せず）に
映写できるようにすることができる。さらに、講師は、
プレゼンテーションのオーディオ表示部分４１４を、そ
の室内で使用可能なスピーカ４１３に送らせることを望
む可能性がある。ここまでに説明したものは、第１のシ
ナリオの仮想計算機の概念と同一であり、それぞれのア
クセスされるウェブ・ページのコンテンツが、単独ユー
ザのコンピュータ、ＰＤＡ、およびステレオ・システム
に分割される。ウェブ・プレゼンテーション４００の図
では、メモ４１５（ウェブ・ページの左部分）、ナビゲ
ーション・バー４１６（最上部の絵）、およびスライド
である視覚表示部分４１７（中央部分）のすべてが、講
師のラップトップ機に送られる。ナビゲーション・バー
は、講師がプレゼンテーション中に歩き回るためにリモ
ート・コントロールを所望する場合に、講師のＰＤＡ
（図示せず）に送信することもできる。オーディオは、
講師の室内で使用可能なステレオ・スピーカに再送され
る。

【００３３】仮想計算機のシナリオの拡張として、図示
されているように、室内（またはリモート位置）の他者
も、デバイスを有し、そのデバイスでプレゼンテーショ
ンの一部を受信することを望むと仮定する。たとえば、
室内の学生の一部が、ＰＤＡ４１８を有し、それ以外
が、ラップトップ機４１９を有する可能性がある。聴衆
に、スライドである視覚表示部分４１７を送信すること
ができる（低解像度にトランスコードされた版がＰＤＡ
に送信される）。リモート位置にいる学生は、図示され
ていないが、プレゼンテーションのオーディオ部分およ
びスライド部分の両方が、その学生ユーザによるアクセ
スのために供給されると仮定する。ユーザは、どのユー
ザのグループがウェブ・ページ内のどのマルチメディア
・オブジェクトの受信を許可されるかを制御するため
に、異なるアクセス特権を有することができる。たとえ
ば、講師は、室内の人々より高い特権を有する。講師
は、メモとナビゲーション・バーを受信することを許可
される。対照的に、聴衆メンバは、ナビゲーション・バ
ーを用いて再生することによってプレゼンテーションに
割り込むことを許可されず、したがって、ウェブ文書の
ナビゲーション・バー部分を受信することを許可されな
い。したがって、このシナリオの下では、所与のオブジ
ェクト（たとえばナビゲーション・バー）が、複数の宛
先を有することができ、複数のオブジェクトが、同一の
宛先（たとえば講師のコンピュータ）を有することがで
き、ユーザが、複数の出力デバイス（たとえば、コンピ
ュータ、ＰＤＡ、ステレオ・スピーカ）を所有／制御す
ることができる。前述の講師／学生のシナリオは、すべ
ての会議のシナリオに同等に良好に適用される。たとえ
ば、発言者が発言中に異なるスライドを通じて移動し、
他の参加者がオンライン・グラフィカル・プレゼンテー
ション（受信する特権を与えられた部分のみ）に追従す
る並列ウェブ・セッションにも参加者が参加できるよう
にすることによって、通常の電話会議を機能強化するこ
とができる。

【００３４】前述を可能にするために、セッション・プ
レゼンタは、まず、スライド・プレゼンテーションを構
成し（「ウェブ・オーサリング」と称するステップ
で）、スライドのシーケンスを、ＸＭＬウェブ・ページ
としてウェブ・サーバに格納する。オーサリングの一部
として、構成者は、任意選択としてＸＭＬ「ポリシ」フ
ァイルを作成することもできる。ポリシ・ファイルに
は、どのＸＭＬタグがどの特権グループへの送信を許可
されるかを指示するマッピング規則が含まれる。後に、
セッション・プレゼンタが、共同プレゼンテーションの
一部としてウェブ・スライドへのアクセスを望む時に、
セッション・プレゼンタは、プレゼンテーションの最初
のページをダウンロードする。プレゼンテーションの最
初のページは、プロキシによって代行受信される。最初
のページが、ポリシ・ファイルを参照している場合に
は、プロキシは、ポリシ・ファイルを要求し、明確に形
成されたタグ・マッピング規則を構成する。ポリシ・フ
ァイルがない場合には、プロキシは、デフォルトの副最
適マッピング規則の組を生成することを強制される。こ
の時点で、プロキシは、他のユーザにセッション・プレ
ゼンタのブラウズ・セッションに追従することを許可す
る、共同マルチデバイス・ウェブ・ブラウズ・セッショ
ンの状態を作成する。プロキシは、サービス・ディスカ
バリ機構にこの新しいセッションを登録し、その結果、
新しいサブスクライバが、そのセッションを見つけられ
るようになる。

【００３５】新しい潜在的なサブスクライバが、確立さ
れたセッションへの参加を希望する時には、そのサブス
クライバは、まず、サービス・ディスカバリ機構に照会
し、サービス・ディスカバリ機構は、使用可能なサービ
スのリストを返す。サブスクライバが、所望の共同マル
チデバイス・ブラウズ・セッションを選択した時に、選
択されたプロキシからサブスクライバに、ユーザ名およ
びパスワードを求めるログイン・フォームが返される。
与えられたパスワードをポリシ・ファイル内で定義され
たパスワードと突き合わせることによって、プロキシ
は、各新しいサブスクライバに特権グループを関連付け
る。また、プロキシは、サービス・ディスカバリに、入
力されたユーザ名に関連するすべてのデバイスを要求す
る。この時点で、プロキシは、個々のサブスクライバの
デバイスに送信しなければならないＸＭＬタグだけを選
択するマッピング規則を構成することができる。プロキ
シは、さまざまな部分または副文書を作成する適当なＸ
ＳＬ文書を構成し、これらの部分または副文書が、その
後、サブスクライバおよびサブスクライバの複数のデバ
イスにプッシュされる。各サブスクライバおよび各デバ
イスは、ウェブ・プレゼンテーションの部分的なビュー
を受信する。データ・プッシュ機構は、サブスクライバ
のブラウザでデータ・プッシュがサポートされる方法に
非常に依存する。エンドポイントが、ブラウザではなく
デバイスである場合には、データ・プッシュは、その物
理デバイスにアクセスするのに必要な方法に非常に依存
する。最後に、サブスクライバは、マルチメディア・タ
グ／オブジェクトの出力デバイスへのプロキシの初期マ
ッピングを変更することを望む可能性があるので、プロ
キシは、ユーザがマッピングをカスタマイズするために
いつでも呼び出すことができる、パーソナライズされた
構成アプレットを作成することができる。プロキシは、
これらのカスタマイズされたマッピングを使用して、タ
グ／マルチメディア配布の最終的なポリシを確立する。

【００３６】プロキシ プロキシの基本コンポーネントには、ユーザ要求を受信
し、これらの要求をウェブ・サーバに転送し、サービス
・ディスカバリ（下で詳細に説明するように、ローカル
機能または分散機能とすることができる）中にユーザ位
置と通信するための少なくとも１つの通信コンポーネン
ト、ウェブ・サーバから取り出した文書を解析するため
の少なくとも１つの処理コンポーネント、ならびに、ポ
リシ・ファイルを解釈するための少なくとも１つの処理
コンポーネント、文書の部分をユーザ位置に動的にマッ
ピングするための処理コンポーネント、および事前に取
り出されたファイルをキャッシュ記憶するための少なく
とも１つのキャッシュ位置が含まれる。文書がＸＭＬで
供給される場合、この解析をＸＳＬファイルを使用して
行うことが最適であり、これには、ＸＭＬパーサおよび
ＸＳＬエンジンが必要である。変換を行うために使用可
能な多数のＸＳＬプロセッサがあり、その詳細は、周知
であり、本明細書では繰り返さない。プロキシには、さ
らに、ユーザ位置にある機能に配送されるコンテンツを
「カスタマイズ」するためにウェブ文書のすべてまたは
部分をトランスコーディングするためのコンポーネント
を含めることができる。

【００３７】プロキシは、システム内のどこにでも配置
することができる（ウェブ・サーバ内またはユーザ位置
を含む）が、エンド・ユーザとウェブ・サーバの間に配
置されるプロキシに情報を配置することが最適である。
プロキシは、マルチデバイス、マルチユーザ選択的処理
を実行するようにカスタマイズされた、Apache^*プロキ
シなどの使用可能なプロキシとすることができる。その
代わりに、プロキシを、サーブレットを用いてウェブ・
サーバとして実施することができる。実際、マルチデバ
イス・プロキシは、送信しなければならない文書を作成
し、それらを宛先に配布するので、エンドクライアント
にとってはウェブ・サーバのように見える。したがっ
て、サーブレットが、インターネット・ウェブ・サーバ
への要求の転送、応答の受信、および解析の実行を処理
することができる。ウェブ・サーバ部分は、サーブレッ
トによってキャッシュ記憶された文書を検索して、エン
ドデバイスに配布する。

【００３８】プロキシの解析機能およびアクセス制御機
能に加えて、中間プロキシの使用には、複数の他の長所
がある。プロキシは、インターネットからエンドデバイ
スを隠蔽し、その結果、必ずしもＩＰアドレスを有しな
いスピーカなどのデバイスにローカルにアクセスできる
ようになる。さらに、プロキシは、インターネットとエ
ンドデバイスの間のバッファとして働く。たとえば、オ
ーディオ・コンポーネントをストリーム化する場合に
は、ネットワーク遅延の変動によって、ストリームが停
止し、再開されるようになる。プロキシは、データをバ
ッファリングし、よりスムーズかつ規則的にエンドデバ
イスにストリーミングすることができる。プロキシの使
用のもう１つの長所は、プロキシが、クライアント側で
何かを稼働させる必要をなくすことであり、これは、エ
ンドデバイスが小さく、限られた機能を有する可能性が
あるので望ましい。プロキシが適用するトランスコーデ
ィング機能は、ウェブ・コンテンツをある種のデバイス
に配送するのに適するようにするためにウェブ・コンテ
ンツに適用することができる。たとえば、Palm Pilot ^*
は、２ビット・グレイスケール・ピクチャだけをサポー
トするので、画像をエンド・デバイスに配送する前に、
プロキシで画像のトランスコーディングを適用すること
ができる。

【００３９】また、プロキシは、エンドユーザが要求す
るのを待たずに、必要な追加ファイル（たとえば画像、
オーディオ・ファイルなど）を取り出すという点で、ブ
ラウザのように振る舞う。ウェブ・ページを受信するエ
ンドデバイスのすべてが、追加ファイルについて照会す
ると期待される。したがって、プロキシに、ウェブ・サ
ーバにそれらを一度に照会させ、キャッシュ記憶させ、
要求元エンドデバイスにサービスさせることが有益であ
る。図５に、本発明によるデータ転送の前述の効率を示
す。

【００４０】図５からわかるように、デバイス１が、ウ
ェブ文書の照会を開始する。プロキシは、この要求を転
送するが、ウェブ・サーバから応答が返ってきた時に、
プロキシは、ブラウザと同様に、そのファイルを解析
し、画像ファイル、サウンド・ファイルなどを照会す
る。したがって、これらの画像ファイル、サウンド・フ
ァイルなどの照会が、エンド・デバイスから来る時に
は、プロキシは、キャッシュ記憶した文書をエンド・デ
バイスに返すことができる。プロキシによる取出および
キャッシュ記憶の手法では、非ブラウザ・エンドデバイ
スの問題も解決される。たとえば、ユーザは、画像をテ
レビジョン画面に送ることを選択できるが、テレビジョ
ン画面がバイナリ・データを期待するので、プロキシ
が、テレビジョン画面の代わりにＸＭＬファイルに含ま
れる画像を取り出さなければならない。これがプロキシ
のデフォルトの振る舞いである場合には、プロキシは、
そのデータをテレビジョン画面に送る方法を知るだけで
よい。

【００４１】サービス・ディスカバリ 共同マルチデバイス・ウェブ・ブラウズは、次の２つの
理由からサービス・ディスカバリ機構を必要とする。第
１に、プロキシが、複数のエンド・デバイスへのマルチ
メディア・セッションを分割できるようになるために、
プロキシが、登録されたユーザならびにそのユーザの登
録されたデバイスを発見する手段を有しなければならな
い。第２に、ユーザがブラウズ・セッションを確立する
かそれに参加することができるようにするために、ユー
ザおよびそのデバイスが、登録されたプロキシを発見す
る手段を有しなければならない。ユーザ、デバイス、お
よびプロキシの登録および発見の機構は、サービス・デ
ィスカバリ・プロトコルを必要とする。Sun Microsyste
ms^*社のJini^*、ＳＬＰ^*、およびMicrosoft^*社のＵＰ＆
Ｐ^*を含む、本発明のシステムで使用することができる
多数の使用可能なサービス・ディスカバリ・プロトコル
がある。これらは周知のプロトコルであるから、サービ
ス・ディスカバリ・プロトコルの詳細を本明細書で説明
する必要はない。

【００４２】図６に示されているように、サービス・デ
ィスカバリおよびサービス登録は、共同マルチデバイス
・ウェブ・ブラウズによって、セッション確立フェーズ
ならびにセッション参加フェーズの両方で使用される。
セッション確立フェーズには、プロキシとサービス・デ
ィスカバリの間の一連の対話がある。サービス・ディス
カバリは、プロキシのローカル・コンポーネントとする
か、複数のサイトの間で分散するか、集中位置で見つけ
ることができる。第１ステップでは、プロキシ６１０
が、サービス・ディスカバリ６１２にそれ自体を登録
し、その結果、クライアント（すなわちセッション作成
者６１４）が、後にそのプロキシを見つけられるように
なる。同様に、ユーザ／セッション作成者は、そのユー
ザによって所有される各デバイスをサービス・ディスカ
バリに登録する。ユーザ登録は、セッションの確立時に
行うことができ、また、以前に行われ、セッション確立
時でのユーザのデバイス可用性に基づいて、必要に応じ
て更新することができる。

【００４３】次に、セッション作成者６１４が、所望の
プロキシのハイパーリンクをクリックするか、他の形で
ウェブ対話を開始する。セッション作成者のシステム
は、単にウェブへの接続を試みることによってセッショ
ン作成者がプロキシにアクセスするように、プロキシの
呼出しがユーザに透過的になるように構成することがで
きる。後者の場合、ウェブ対話の開始時に、セッション
作成者のシステムが、サービス・ディスカバリに照会し
て、登録されたプロキシを見つけ、プロキシが選択さ
れ、接続される。接続されたプロキシ６１０は、セッシ
ョン・ログイン・メニューを返し、セッション名と最初
のＸＭＬウェブ・ページのＵＲＬを要求する。その後、
プロキシは、要求されたＸＭＬページおよびそれに関連
するポリシ・ファイル６１７をウェブ・サーバ６１５か
らプルする。プロキシは、ＸＭＬページおよびポリシ・
ファイルを解析して、特権グループを作成し、その後、
ログイン・メニューをセッション作成者に送信し、ユー
ザ名およびパスワードを要求する。ユーザを特権グルー
プに突き合わせた後に、プロキシは、新しいセッション
をサービス・ディスカバリに告知し、セッション作成者
によって登録されたデバイスを要求する。最後に、要求
されたＸＭＬページのうちでセッション作成者が受信を
許可される部分が、セッション作成者に返される。

【００４４】既存のセッションがすでに確立されている
セッション参加フェーズでは、プロキシ／ユーザとサー
ビス・ディスカバリの間に、次の３つの対話がある。第
１に、新しいユーザまたはサブスクライバが、そのデバ
イスをサービス・ディスカバリに登録する。第２に、サ
ブスクライバが、サービス・ディスカバリに、進行中の
ブラウズ・セッションのリストを要求する。第３に、プ
ロキシが、サービス・ディスカバリに、新しいサブスク
ライバに関連するすべての登録されたデバイスを要求す
る。テーブル６１６に、プロキシおよびセッションの登
録のためにサービス・ディスカバリ・コンポーネントに
よって維持されるレコードの例を示す。

【００４５】本発明のシステムおよび方法と既存のサー
ビス・ディスカバリとの間の上の対話は、２つの動作す
なわちregister()（登録）およびquery()（照会）に還
元することができる。既存のサービス・ディスカバリ・
プロトコルは、プロキシおよびブラウズ・セッションな
らびにユーザおよびそのユーザのデバイスを登録（regi
ster()）することができる。さらに、サービス・ディス
カバリは、照会（query()）に応答して、登録されたプ
ロキシまたはセッションもしくはその両方のリスト、ま
たは、各ユーザに関連するデバイスと共に登録されたユ
ーザのリストを返すことができる。サービス・ディスカ
バリのレジストリが、集中化されるか分散されるか、ま
たは、登録されたプロキシ／セッションが、ローカル・
エリア専用であるか、広域で使用可能であるかは、選択
されるサービス・ディスカバリ・プロトコルによって決
定できる要因であり、本発明のシステムおよび方法を変
化させる要因ではない。もちろん、広域サポートによっ
て、プロキシがリモートの広域共同作業、たとえばリモ
ート学生との遠距離学習を提供する能力が拡張される。

【００４６】サービス・ディスカバリへのインターフェ
ースは、クライアントまたはプロキシのどちらがサービ
ス・ディスカバリと対話するかに応じて変更することが
できる。プロキシは、サービス・ディスカバリとの視覚
的インターフェースを必要とせず、単純な手続きＡＰＩ
でよい。対照的に、クライアントのエンド・ユーザは、
サービス・ディスカバリへのグラフィカルＵＩまたはブ
ラウザタイプのインターフェースを有することができ
る。クライアントとサービス・ディスカバリの間の対話
の詳細は、やはり、本発明の範囲を超える。必要なの
は、そのような対話が存在し、クライアント・デバイス
を登録でき、リストされたプロキシまたはセッションを
クライアントに返せることである。

【００４７】更新データ配送 更新されたデータが生じるたびに、そのデータを、すべ
てのブラウザおよび、スピーカまたはテレビジョン画面
のようなデバイスにプッシュし、その結果、誰もが見る
ものについて同期化されるようにしなければならない。
しかし、変更が、クライアント側で必要になってはなら
ず、マルチデバイス・ウェブ・ブラウズを機能させるた
めにプログラムを実行する必要があってもならない。そ
の理由の一部は、Palm Pilot^*などのいくつかのデバイ
スが、マルチスレッド式ではなく、その結果、これらの
デバイスでデーモンを稼働させることができないからで
ある。したがって、ウェブ・ブラウザの現在の特徴だけ
を使用して、それらにデータをプッシュすることを試み
ることが好ましい。２つの手法すなわちサーバ・プッシ
ュまたはクライアント・プルのいずれかを使用して、エ
ンド・ブラウザにデータを送信することができる。サー
バ・プッシュでは、サーバが、データを送信し、ブラウ
ザは、そのデータを表示するが、接続をオープンしたま
まにし、サーバが求める時にはいつでも、サーバが次の
データを送信し、ブラウザがそれを表示し、接続をオー
プンしたままにする。逆に、クライアント・プルでは、
サーバが、「このデータを５秒で再ロードせよ」または
「１０秒でこの他のＵＲＬに行き、ロードせよ」と命じ
るディレクティブ（ＨＴＴＰ応答または文書ヘッダ内
の）を含むデータを送信する。指定された時間が満了し
た後に、クライアントが、指示されたことを実行する
（すなわち、現在のデータを再ロードするか、新しいデ
ータを得る）。

【００４８】クライアント・プルに対するサーバ・プッ
シュの主な長所は、サーバが、いつどのように新しいデ
ータを送信するかに関する完全な制御を有することであ
る。また、この方法は、新しいＨＴＴＰ接続を毎回オー
プンする必要がないので、より効率的になる可能性があ
る。短所は、オープン接続が、それがオープンされてい
る間にサーバ側のリソースを消費することである。残念
ながら、すべての種類のブラウザが同一の特性を有する
わけではなく、たとえば、Netscape Navigator ^*とＩＥ^*
は、サーバ・プッシュまたはクライアント・プルの実装
に同一の技法を使用してはいない。たとえば、サーバ・
プッシュ（サーバがブラウザにデータをプッシュできる
ようにする）を行うために、Netscape Navigatorは、単
一メッセージ（またはＨＴＴＰ応答）に多数のデータ項
目を含められるようにする、「multipart/mixed」と称
する固有のＭＩＭＥタイプに依存する。プッシュされる
データの異なる部分は、定義済みの区切り文字列によっ
て分離される。しかし、ＩＥブラウザは、ＭＩＭＥタイ
プを使用せず、したがって、本発明は、この方法を使用
してこれらにデータをプッシュすることができない。Wi
nCE^*デバイスで使用されるポケットＩＥについては、完
全なＨＴＴＰ仕様が実施されておらず、クライアント・
プル技法を使用できるようにすることができるJavaScri
ptもサポートされない。

【００４９】したがって、サポートされる特徴の相違に
対して、必要なものは、ブラウザの種類ごとに（少なく
とも最も一般的なものについて）データをプッシュする
異なる方法である。以下の解決策が適用される。Netsca
pe Navigator^*の場合、プロキシは、クライアントがNet
scape Navigatorを実行していることを見つけた場合
に、サーバ・プッシュまたはクライアント・プル・モデ
ルを使用することを決定することができる。サーバ・プ
ッシュ・モデルでは、プロキシとクライアントのデバイ
スのウェブ・ブラウザとの間に永久的なリンクがオープ
ンされる。このリンクは、エンドブラウザがＨＴＴＰヘ
ッダ内でmultipart/mixedのＭＩＭＥタイプを受信した
時にオープンされる。その後、データを、このパイプを
介してウェブ・ブラウザにプッシュすることができる。
次のコードに例を示す。 Content-type: multipart/mixed;boundary=DelimitorString --DelimitorString Content-type: text/plain 最初のオブジェクトのデータ。 --DelimitorString Content-type: image/gif 第２の最後のオブジェクトのデータ。 --DelimitorString-- この例では、永久的なリンクは、クライアント・ブラウ
ザが「Content-type multipart/mixed」でメッセージを
受信した時に作成される。属性boundaryは、その文字列
が、サーバによってプッシュされるデータの区切りに使
用されることを示す。したがって、サーバは、クライア
ントにデータを送信したい時に、boundary文字列を用い
てデータを区切り、ヘッダのContent-typeを用いてデー
タ型を定義する。

【００５０】クライアント・プル方法は、JavaScriptを
使用するか、ウェブ・ページを周期的に再ロードできる
ようにする、Refresh（最新表示）と称する特殊なＨＴ
ＴＰヘッダを使用して行われる。したがって、文書がプ
ロキシ側で変更された場合には、新しいコンテンツが、
規則的な時間間隔で表示される。特殊なＨＴＴＰヘッダ
は、「Refresh: 3」のような形になる。同一のウェブ・
ページが、３秒ごとに最新表示される。

【００５１】エンド・クライアントがＩＥを実行してい
る場合には、ＩＥの現在のバージョンではサーバ・プッ
シュがサポートされていないので、クライアント・プル
・モデルだけが使用可能である。したがって、クライア
ント・ブラウザが、規則的にプロキシに照会して、更新
を入手しなければならない（JavaScriptまたはＨＴＴＰ
Refreshヘッダを使用する）。

【００５２】Netscape NavigatorおよびＩＥのためのも
う１つの代替案が、プロキシからの通知をlistenし、プ
ロキシによって送信されたＵＲＬを有する文書を表示す
るようにブラウザに指示するアプレットを使用すること
である。この手法は、隠されたクライアント・プルであ
り、新しいデータが使用可能になった時について通知を
受けるアプレットの存在によってより柔軟にされる。こ
の形では、ページは、規則的な瞬間に最新表示されるの
ではなく、新しいデータが使用可能になった時に限って
最新表示される。同一のことを、Netscape Navigatorの
場合にはNetscapeプラグイン、ＩＥの場合にはMicrosof
t Active X^*コンポーネントを用いて行うことができ
る。

【００５３】クライアントがポケットＩＥを実行してい
る（WinCEデバイス）場合、ポケットＩＥが、完全な版
のＨＴＴＰを実行せず、Refresh ＨＴＴＰヘッダを理解
せず、JavaScriptまたはJavaを理解せず、サーバ・プッ
シュをサポートしないので、明白な方法はない。解決策
は、ＨＴＭＬ文書を表示するＡＰＩを提供する、ＨＴＭ
Ｌビューア・コントロールと称する機能を使用すること
とすることができる。そのようなシステムでは、プロキ
シからデータを受信（ソケットを使用して）することが
できるプログラムを作成でき、ＨＴＭＬビューアＡＰＩ
を使用してＨＴＭＬ文書を表示することができる。

【００５４】共同作業の処理 本発明のプロキシベースの解決策を使用してデバイスお
よびユーザが共同作業するために必要なステップの具体
的なシーケンスを、これから説明する。一般的に言っ
て、図７に示された処理は、プロキシが、ウェブ・ペー
ジ内のＸＭＬタグを各ユーザの異なる出力デバイスにマ
ッピングする規則のセットを作成する方法の輪郭を示す
ものである。概念を明確にするために、共同マルチデバ
イス・ウェブ・ブラウズ・セッションの正常動作を、４
つのフェーズに分割することができる。最初のステップ
では、ステップ７０１に示されているように、ウェブ・
ページをＸＭＬで事前にオーサリングしなければならな
い。ウェブ・オーサリングのステップには、複数のユー
ザの間の共同作業を助けるＸＭＬポリシ・ファイルの作
成を追加的に含めることができる（ポリシ・ファイルに
は、タグを特権グループにマッピングするデフォルト規
則が含まれる）。ウェブ・オーサリングの後に、ステッ
プ７２０に示されているように、前述のＸＭＬウェブ・
ページと、ポリシ・ファイルがある場合にポリシ・ファ
イルをユーザが要求することによって、プロキシ側でブ
ラウズ・セッションを確立しなければならない。次に、
ステップ７４０に示されているように、新しい潜在的な
サブスクライバが、セッションにログ・インし、自分が
属する特権グループを識別することによって、すでに確
立されているブラウズ・セッションに参加することがで
きる。最後に、確立されたセッションに参加した後に、
サブスクライバが、ステップ７６０で、そのサブスクラ
イバが所有するかアクセスを許可されているエンド・デ
バイスにＸＭＬタグをマッピングする規則をカスタマイ
ズすることができる。前述のステップのそれぞれを、こ
れから詳細に説明する。

【００５５】ウェブ・オーサリング 共同マルチデバイス・ウェブ・ブラウズでは、ウェブ・
サイトの作成者が、図７のウェブ・オーサリング・ステ
ップ７０１で、ＸＭＬウェブ・ページ、それに付随する
ＸＳＬ文書、および、非常に有益であるが任意選択のポ
リシ文書を含む、複数のＸＭＬ関係文書を作成すること
が必要である。ウェブ・ページの記述に使用された従来
の言語は、ＨＴＭＬである。ＨＴＭＬは、ウェブ・ペー
ジのコンポーネントの書式設定を記述する標準化された
マークアップ言語である。ウェブ・ページの内容に無関
係に、汎用タグが使用され、このため、人間がＨＴＭＬ
ソースを読み、理解することが困難になっている。ＨＴ
ＭＬタグは、書式設定の意味を有するが、ウェブ文書の
一部としてのコンテンツの意味を有しない。その結果、
ＨＴＭＬは、本発明によく適していない。JavaScriptま
たはMicrosoft社のJScriptに似たスクリプトを使用する
ことによって、ＨＴＭＬをより柔軟で豊富にしようと試
みる努力がなされているが、現在のＨＴＭＬは、ウェブ
作成者がポリシ・ファイルを作成する機能を提供するこ
とができない。これは、本発明が、ＨＴＭＬを使用して
作成された文書に適用できないと述べているわけではな
い。実際、本発明を使用して、ＨＴＭＬ文書を、異なる
ユーザ・デバイスでのコンテンツの部分の配布のために
文書部分に分割することができる。しかし、ポリシ・フ
ァイルに基づく、文書の分割および異なる特権グループ
に属するユーザへの選択的なコンテンツの配布の態様
は、ＨＴＭＬ文書を用いて簡単には実施されない。

【００５６】その代わりに、ＸＭＬが、作成者が文書を
創る際に必要なタグを構成する言語である。ＸＭＬで
は、書式設定ではなくセマンティクスが記述され、書式
設定は、ＸＳＬまたはＣＳＳで記述することができるス
タイル・シートを用いて文書に追加される。本発明を実
施するためのウェブ・コンテンツのオーサリング言語と
して、ＸＭＬに頼ることが好ましい。ウェブ・コミュニ
ティは、豊富なウェブ・コンテンツを開発する上でのＨ
ＴＭＬの限界を意識しており、これが、マークアップ言
語としてのＸＭＬへの遷移を始めることを試みる努力の
理由である。ＸＨＴＭＬなどのＷ３提案は、ＨＴＭＬと
ＸＭＬの間の互換性を定義する方法を示している。さら
に、多数のウェブ・サーバが、すでにウェブ・コンテン
ツをＸＭＬ文書として格納しているが、エンド・ユーザ
に送信する前に、それらのコンテンツをＨＴＭＬに変換
している。

【００５７】ＸＭＬは、その柔軟性に起因して、本発明
の実施に非常に適する。すべての作成者が、独自のタグ
および独自のコンポーネントを定義するので、結果の文
書を、選択されたデバイスに送信することができる独立
のコンポーネントに分割することが非常に簡単である。
あるページの独自の名前を有するタグのそれぞれが、そ
のタグの配送先にすることができる出力デバイスを記述
する、それ自体のデマルチプレクス・ポリシを有するこ
とが最適である。ＸＭＬによって、各タグの名前を一意
に定義する能力が提供され、ＸＳＬによって、各タグの
使用法を定義することができる。さらに、ＸＳＬ文書
は、カスタマイズされたＸＭＬをブラウザがレンダリン
グできる言語に変換するために、ＸＭＬ対応ブラウザに
よって必要とされる。このＸＳＬ文書によって、ＸＭＬ
からＨＴＭＬ（または、必要であれば別のマークアップ
言語）への変換が定義され、これによって、サーバとブ
ラウザの間でプロキシが使用されない場合であっても、
ＸＭＬ非対応ブラウザがウェブ文書を処理できることが
保証される。

【００５８】図４に示されたスライド・プレゼンテーシ
ョン用のＸＭＬウェブ・ページの次の例を検討された
い。そのウェブ・ページには、ナビゲーション・ボタ
ン、グラフィカル・スライド、私的メモ、およびオーデ
ィオという４つのコンポーネントがあったことを想起さ
れたい。そのようなページの非オーディオ・コンポーネ
ントを記述するのに使用されるＸＭＬファイルは、次の
ようになる。 <?xml version="1.0"?> <?xml:stylesheet type="text/xsl" href="present.xsl"?> <presentation> <head> <title>トランスコーディング・プロキシ</title> <nav_bar xml:link="simple" href="c:＼xml＼nav_bar.gif"/> </head> <slide> <picture xml:link="simple" href="c:＼xml＼transco.gif"/> </slide> <notes> テキスト… </notes> </presentation> この文書は、タイトル（タグ<title>）およびナビゲー
ション・バー（タグ<nav_bar>）を有するヘッダ部分
と、スライド（タグ<picture>）を含むものおよび私的
メモ（タグ<notes>）を含むものの２つの本文部分とを
有する。

【００５９】これら２つのファイル（ＸＭＬおよびＸＳ
Ｌ）のほかに、作成者は、任意選択として、どのＸＭＬ
タグをどの特権グループおよびどのデバイスに配布しな
ければならないかを支配するマッピング規則を定義する
ポリシ・ファイルを記述することができる。ポリシ・フ
ァイルによってもたらされる大きい利益が、誰がウェブ
・プレゼンテーションの何を見るかを制御する能力であ
る。ポリシ・ファイルでは、特権グループが定義され、
次に、各特権グループが受信を許可されるＸＭＬタグの
サブセットが定義される。作成者は、ポリシ・ファイル
を使用して、あるグループがウェブ・プレゼンテーショ
ンの部分的なビューだけを受信するように制限すると同
時に、セッションへの他のサブスクライバにすべてのア
クセス特権を与えることができる。 # 図３のＸＭＬウェブ・ページ用のポリシ・ファイル # 共同セッションのグループおよび各グループに関連するパスワードを定義す る group = "lecturer", password = lecturer_password, Input_permitted = TR UE group = "students", password = students_password, Input_permitted = FA LSE # 各グループが受信することのできる、許可されるタグのセットを定義する # 許可されるタグのセットは、さらに、ブラウザ・タイプに基づいてサブセ ットに分割することができる If (group = "lecturer") If access = "Internet Explorer" or "Netscape Navigator" Tags = presentation, head, title, nav_bar, slide, picture Undefined_Tags = images, text, audio, video Else if access = "Pocket Explorer" (WinCE) or "ProxiWeb" (Palm) Tags = presentation, head, title, nav_bar, notes Undefined_Tags = text If (group = "students") If access = "Internet Explorer" or "Netscape Navigator" Tags = presentation, slide, picture Undefined_Tags = images, text, audio, video Else if access = "Pocket Explorer" (WinCE) or "ProxiWeb" (Palm) Tags = presentation, slide, picture (transcoding param's (a=_, b=_ , ....)) Undefined_Tags = text # 各タグ名のメディア・タイプを定義し、エンド・ユーザが各タグ名の # 目的を理解できるようにする Images: nav_bar, slide, picture Text: title, notes

【００６０】ポリシ・ファイルの重要な責任は、特権グ
ループの定義である。特権グループの背後にあるアイデ
アは、共同ブラウズ・セッションの参加者のアクセス特
権に区別を立てるための機構を提供することである。１
つのセッションによって、異なる特権グループにウェブ
・ブラウズ・セッションの異なる部分的ビューを提供す
ることができる。ブラウズ・セッションで複数のユーザ
に提示されるウェブ・ページの作成者は、あるユーザ・
グループに、他のグループより高いまたはより低い、あ
るＸＭＬタグにアクセスする特権を与えることを望む場
合がある。上の例では、ポリシ・ファイルによって、共
同プロキシを介して学生にオンラインで大学の授業を提
示する講師が、学生が提示されるウェブ・ページのそれ
ぞれのタグのサブセットだけを見るように制限できるよ
うになる、すなわち、講師は、学生が私的な覚え書きの
メモを見られないようにし（<notes>タグが学生に使用
不能）、学生が講義へのナビゲーション制御にアクセス
できないようにする（<nav_bar>タグが学生に使用不
能）。

【００６１】ポリシ・ファイルは、ＸＭＬ文書の一部と
することができるが、ポリシ・ファイルを、そのポリシ
・ファイルを参照するＸＭＬウェブ・ページとは別の第
２のファイルにすることが好ましい。別々のファイルを
使用することによって、複数のウェブ・ページから同一
のポリシ・ファイルを参照できるようになる。たとえ
ば、これは、ウェブ・スライド・プレゼンテーションを
構成する作成者が、すべてのウェブ・ページに対して特
権グループの同一のセットを定義したいが、ページごと
に新しいポリシ・ファイルを書き直したくない場合に役
立つことができる。そうではなくて、作成者は、プレゼ
ンテーションの各ページから参照される単一のポリシ・
ファイルを記述するのである。同一のポリシ・ファイル
を参照するすべてのページが、同一の特権グループを共
用する。作成者は、プレゼンテーションの複数のページ
を横断する間に出会うすべてのＸＭＬタグを、１つのポ
リシ・ファイルに集める。ポリシ・ファイルを別のファ
イルにすることに対する代替案は、ポリシ・ファイルの
情報を各ＸＭＬページに埋め込むことである。しかし、
ポリシ・ファイルのメタデータ情報を独自のファイルに
分離することによって、作成者が特権グループを更新す
るのが簡単になる。作成者は、同一の特権グループの同
一の埋め込まれた定義を含むウェブ・ページのそれぞれ
を編集する必要なしに、単に、各ウェブ・ページから参
照される１つのポリシ・ファイルを変更する。

【００６２】上で説明した例のＸＭＬページのために開
発された、ポリシ・ファイルの例を下に示す。このポリ
シ・ファイルは、ＸＭＬ文書として構成される。この文
書内では、ネームスペースを定義して、このポリシ・フ
ァイルで使用されるタグおよび値を標準化する。以下で
は、ネームスペース・プレフィックスｃｍｄｂ（collab
orative multi-device browsing）が導入される。前の
例に対応するＸＭＬポリシ・ファイルは、次のようにな
る。 <cmdb:group name = "lecturer" password = "YYYYY" input_permitted = "yes" > <cmdb:device name = "IE||Netscape Navigator"> <cmdb:taglist> presentation, head, title, nav_bar, slide, picture</cmd b:taglist> <cmdb:undefinedtag_list>images, text, audio, video</cmdb:undefinedta g_list> </cmdb:device> <cmdb:device name = "PocketIE"> <cmdb:taglist>presentation, head, title, nav_bar, notes</cmdb:taglis t> <cmdb:undefinedtag_list>text</cmdb:undefinedtag_list> </cmdb:device> </cmdb:group> <cmdb:group name = "students" password = "ZZZZZ" input_permitted = "no"> <cmdb:device name = "IE||Netscape Navigator"> <cmdb:taglist> presentation, slide, picture</cmdb:taglist> <cmdb:undefinedtag_list>images, text, audio, video</cmdb:undefinedta g_list> </cmdb:device> <cmdb:device name = "PocketIE"> <cmdb:taglist>presentation, slide, picture(transcoded)</cmdb:taglist> <cmdb:undefinedtag_list>text</cmdb:undefinedtag_list> </cmdb:device> </cmdb:group> <cmdb:media_types> <cmdb:images> <cmdb:taglist>nav_bar, slide, picture</cmdb:taglist> </cmdb:images> <cmdb:text> <cmdb:taglist>title, notes</cmdb:taglist> </cmdb:text> </cmdb:media_types>

【００６３】作成者がポリシ・ファイル内で使用しなけ
ればならないタグおよび属性を標準化するスキーマを定
義する必要がある。いくつかの属性に使用される値も標
準化しなければならない。たとえば、すべての共同マル
チデバイス・プロキシが、特権グループが定義されてい
ることを理解するために、すべての作成者が、標準タグ
名「group」を使用することが重要である。例のＸＭＬ
ポリシ・ファイルには、以下の提案される標準タグ名が
含まれる：group、device、taglist、undefinedtag_lis
t、media_types、images、およびtext(videoおよびaudi
oは示されていない）。さらに、各タグは、それ自体の
独自の属性を有し、たとえば、groupタグは、属性「nam
e」、「password」、および「input_permitted」を有す
る。最後に、属性「name」および「password」の値は、
標準化する必要がないが、いくつかの属性の値は、作成
者が何を意図しているかをプロキシが例外なく理解でき
るようにするために標準化しなければならず、たとえ
ば、input_permittedは、「yes」または「no」のいずれ
かにセットされる標準化された値を有しなければならな
い（そうでなければ、異なる作成者が、true/false、on
/off、1/0などを使用することになる）。周知の名前に
ついてはある程度の自由度を設けることができる、すな
わち、プロキシは、<device name=”InternetExplore
r”>が、デバイス属性ＩＥに言及していることを理解す
ることができる。しかし、他のエンド・デバイスの場
合、これはより困難になる可能性がある。その結果、デ
バイスに言及するための共通の用語に同意することが好
ましい。この語彙は、いつでも指定することができ、も
ちろん拡張可能である。

【００６４】デバイス・タグの属性機能も、作成者がコ
ンテンツ出力デバイスの機能に関する特殊な要件を指定
できるようにするために導入することができる。たとえ
ば、<cmdb:device capability=”sound_card”>を使用
することができ、これは、それに続くタグのセットを、
サウンド・カードを有するデバイス用に送信できること
を意味する。機能属性の値を標準化し、その結果、プロ
キシが、サービス・ディスカバリから検索するものとそ
れら値を照合できるようにすることが、さらに重要であ
る。プロキシは、各デバイスについてサービス・ディス
カバリ・データベースに登録されたさまざまな属性か
ら、デバイスの機能を知る。しかし、機能を記述する標
準化された方法がない場合には、プロキシは、この情報
を活用することができない。したがって、デバイスは、
作成者がサービス・ディスカバリを用いてそれらの機能
をリストするのと同一の語彙を使用しなければならな
い。Ｗ３Ｃ草案「Composite Capability/Preference Pr
ofiles（ＣＣ／ＰＰ）」は、デバイスの特性のグローバ
ルな標準化を提案することを試みており、これによっ
て、将来に本発明のこの態様を実装することが、より簡
単になる可能性がある。

【００６５】セッションによってプロキシにダウンロー
ドされる最初のＸＭＬページに関連する（または、その
ＸＭＬページの一部である）初期ポリシ・ファイルによ
って、特権グループが定義され、したがって、セッショ
ンを通じて観察されるタグ・マッピング規則が定義され
ると仮定する。異なるポリシ・ファイルを有する他のペ
ージに遭遇する可能性があるが、初期ポリシ・ファイル
によって定義された特権グループおよびタグ・マッピン
グ規則が、後続のポリシ・ファイルより優先される。未
定義タグに関する以下の議論では、ブラウズ・セッショ
ンがすでに確立されていることと、初期ポリシ・ファイ
ルがそのセッションの最初のＸＭＬページと共にダウン
ロードされていることを仮定する。

【００６６】ポリシ・ファイルのUndefined_Tags変数
は、共同ブラウズ・セッションを確立した最初のウェブ
・ページによって参照されるポリシ・ファイル内で定義
されていないタグを有するウェブ・ページに講師または
セッション・プレゼンタがアクセスした場合に、未知の
ＸＭＬタグをどこに送信するかをプロキシに知らせる変
数である。セッション・プレゼンタが、初期ポリシ・フ
ァイルの定義に従うウェブ・ページだけにアクセスする
ように制限することは、厳密にすぎるはずである。その
代わりに、セッション・プレゼンタが、初期ウェブ・ペ
ージのポリシ・ファイルの有効範囲の外のウェブ・サイ
トをブラウズする権利を有することを許容することが望
ましい。たとえば、ウェブ聴衆にスライド・ショウを提
示している講師が、準備された講義のスライドだけでは
なく、デモンストレーションのために、準備された講義
の外部のウェブ・ページも見せたいと思う場合がある。
そのようなシナリオでは、セッション・プレゼンタが、
事前に定義されたポリシ・ファイルを有しないウェブ・
ページ、たとえば、共同ウェブ・ブラウズを意識してい
ない、ＣＮＮなどの商業ウェブ・サイトに行き、初期ポ
リシ・ファイルＰＦと異なるポリシ・ファイルＰＦ'お
よびＰＦ"を有する２つの他のウェブ・ページに行く。

【００６７】ユーザは、ポリシ・ファイルを有するウェ
ブ・ページにアクセスせずに、共同ブラウズ・セッショ
ンを確立することもできる。この場合、目的は、人間の
グループが一緒にブラウズすることを望むが、ユーザの
異なるサブセットの特権グループを形式的に定義するこ
とに関心がない場合の一般的なシナリオをサポートする
ことである。しかし、セッション・プレゼンタが、異な
るグループが見るものをより形式的に制御する方法を必
要とする時には、ポリシ・ファイルによって、同一のウ
ェブ素材の部分的ビューを供給する手段がもたらされ
る。

【００６８】初期ポリシ・ファイルの有効範囲の外のウ
ェブ・ページへのアクセスを許可した結果として、プロ
キシが、初期ポリシ・ファイルで定義されていない、未
知のＸＭＬタグに出会う。未定義タグを処理するため
に、Undefined_Tags変数という概念を導入する。Undefi
ned_Tags変数によって、プロキシに、未定義タグを送信
する先が指示される。プロキシは、未定義タグに出会っ
た時に、タグの未知の名前に基づいて切り替えることが
不可能なので、そのメディア・タイプまたはＭＩＭＥタ
イプに基づいてそのタグを切り替える。セクションmedi
a_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.xs
l"?> 同じ形で、次のような処理命令を使用することができ
る。 <?xml-cmdb href = "location of policy file"?> マルチデバイス・ウェブ・ブラウズ・プロキシは、この
命令を認識し、href属性で指定されたアドレスに配置さ
れたファイルを検索する。

【００７７】第３ステージすなわち図７のステップ７４
０で、ＸＭＬウェブ・ページの要求によってトリガされ
る、プロキシ内のブラウズ・セッションが確立される。
図８および図９に示されているように、プロキシ内で共
同マルチデバイス・ウェブ・ブラウズ・セッションを確
立する処理フローには、１０個のステップがある。ステ
ップ８０１で、プロキシが、それ自体をサービス・ディ
スカバリ・データベースに登録する。プロキシが、活動
中になった後に、プロキシは、サービス・ディスカバリ
・プロトコルを介してその名前およびＩＰアドレスを、
概念上サービス・ディスカバリ・データベース（ＳＤＤ
Ｂ）と称するものに登録する。サービス・ディスカバリ
・プロトコルは、（１）プロキシを登録でき、各プロキ
シ内の各ブラウズ・セッションを登録でき、（２）各デ
バイスの所有者と共に各デバイスを登録でき、（３）ど
のプロキシ、セッション、およびユーザ・デバイスが、
すでにＳＤＤＢにそれ自体を登録したかに関する照会に
応答できなければならない。概念上、サービス・ディス
カバリ・プロトコルは、本質的に、書き込まれ、照会さ
れるデータベースとして実行する。しかし、どのサービ
ス・ディスカバリ・プロトコルが使用され、そのサービ
ス・ディスカバリ・プロトコルがどのようにしてそのＳ
ＤＤＢを実施するかの詳細は、本発明の実施にとってク
リティカルではない。たとえば、上で述べたように、Ｓ
ＤＤＢは、集中データベース・レジストリとして、また
は分散データベース登録方式として、実施することがで
きる。

【００７８】次のステップである図８の８０２には、セ
ッション作成者がそのブラウザをサービス・ディスカバ
リ・データベースに登録することが含まれる。セッショ
ン作成者は、発信元のブラウザ対応コンピュータをＳＤ
ＤＢに登録することを要求する登録メッセージをＳＤＤ
Ｂに送信する。デバイス（この場合は発信元のコンピュ
ータ）の登録は、デバイスのＩＰアドレス、デバイスの
名前、デバイス所有者の名前、デバイスのメディア・デ
コード機能（ＭＰＥＧビデオ、．wav^*、MP3^*、RealVide
o^*、WindowsMedia^*、ＪＰＥＧ^*、ＧＩＦ^*、ＨＴＭＬ
４．０、ＸＭＬなど）、およびデバイスのアクセス・モ
ード（デバイス・ドライバに類似する、そのデバイスと
通信するのに用いられるプロトコル）の供給を必要とす
る。登録メッセージには、すべての登録されたプロキシ
およびそれらの登録されたセッションのリストの要求も
含まれる。

【００７９】登録の後に、セッション作成者は、ステッ
プ８０３で、ブラウズ・セッションを作成するプロキシ
を選択し、ステップ８０４で、「セッション作成」メッ
セージをそのプロキシに送信する。具体的に言うと、ブ
ラウザ対応コンピュータの登録の後に、ＳＤＤＢが、使
用可能なプロキシおよびそれらの進行中のセッションの
リストを含む応答をセッション作成者に返す。このリス
トは、単純なハイパーテキスト・インターフェースをセ
ッション作成者に供給することができ、セッション作成
者が、接続したいプロキシを手作業でクリックすること
ができるように記述されなければならない。リンクは、
プロキシがそれ自体をＳＤＤＢに登録した時にプロキシ
によって供給された定義済みウェブ・ページを指す。こ
のウェブ・ページは、新規セッション確立フォームにな
り、ユーザがプロキシ名をクリックする時に、この定義
済みフォームの要求がプロキシに送信され、プロキシ
が、その文書をセッション作成者に返す。このフォーム
のおかげで、ユーザは、新しいウェブ・ブラウズ・セッ
ションを作成することができるようになる。ブラウザ
が、プロキシ・フィールドの自動更新をサポートする場
合には、プロキシ名のクリックによってブラウザがリダ
イレクトされ、その結果、ブラウザが所望のプロキシを
指す（すべてのブラウザＨＴＴＰ ＧＥＴ要求がプロキ
シを介してルーティングされる）ならば有用である。し
かし、ブラウザが自動リダイレクションをサポートしな
い場合には、セッション作成者が、手作業でプロキシ・
パラメータをブラウザに転送しなければならない、すな
わち、ユーザが、「Edit Preferences（設定）」（Nets
cape Navigator）または「Tool->Internet Options（ツ
ール→インターネット・オプション）」メニュー（Inte
rnet Explorer）のいずれかを編集し、プロキシ・フィ
ールドに適当なアドレスおよびポートを設定しなければ
ならない。この時点で、ブラウザが、次のステップすな
わち、選択されたプロキシを介するＸＭＬウェブ・ペー
ジの要求のために正しくセット・アップされる。

【００８０】プロキシの選択にユーザが手作業でかかわ
ることは、プロキシの自動化された選択およびブラウザ
の自動化されたリダイレクションと比較して望ましくな
いように見える可能性がある。手作業のかかわりは、実
施が複雑にならないという長所を有し、これに対して、
自動選択およびリダイレクションは、サービス・ディス
カバリ・プロトコルに対する追加要件を課す可能性があ
る。たとえば、ＳＤＤＢへの登録メッセージに、その最
も単純な形態で、登録済みプロキシ・リストおよび進行
中セッション・リストの両方に関する広い照会として解
釈されるサービス・ディスカバリ要求が組み込まれる。
そのような広いサービス・ディスカバリ要求を与えられ
たＳＤＤＢは、要求元ユーザが、プロキシ・リストだけ
に興味を持っているセッション作成者であるか、進行中
のブラウズ・セッションの１つへの加入だけに興味を持
っている一般ユーザであるかを知ることができない。サ
ブスクライバの場合には、サブスクライバによる手作業
の介入が存在しなければならず、このサブスクライバ
は、セッションを選択するために、進行中のセッション
の表示されたリストを走査することができなければなら
ない。したがって、要求元デバイスのユーザがサブスク
ライバである可能性があることを予期して、両方のリス
トが、ＳＤＤＢによって返されなければならず、要求元
デバイスでサービス・ディスカバリ・プロトコルによっ
て表示されなければならない。セッション作成者であっ
てサブスクライバでないユーザは、プロキシを選択する
ために自動化されたアルゴリズムを適用することが可能
な場合であっても、手作業でプロキシを選択することを
強制される。プロキシの自動化された選択を完全にサポ
ートするためには、サービス・ディスカバリ・プロトコ
ルに対する追加要件を課し、その結果、サービス・ディ
スカバリ・プロトコルが、登録要求の２つのタイプすな
わち、セッション開始元からの要求（プロキシのリスト
だけを要求する）とサブスクライバからの要求（ブラウ
ズ・セッションのリストだけを要求する）を区別できる
ようにする。この形で、ＳＤＤＢは、サブスクライバで
あるユーザを登録する場合にセッション・リストだけを
選択的に返し、セッション開始元であるユーザを登録す
る場合にはプロキシ・リストだけを選択的に返すことが
できる。その結果、自動的な方法（プロキシ選択および
ブラウザ・リダイレクション）を、手作業の方法（セッ
ション選択）から分離することができる。自動化機構
は、使用可能なプロキシの受信されたリストの手作業の
表示をオーバーライドし、抑止するはずである。

【００８１】一般に、セッション作成者は、複数のデバ
イス、おそらくはＰＤＡならびにラップトップ機および
ステレオ・システムを所有し、登録することができる。
唯一の要件は、セッション作成者が、プロキシを介して
ＸＭＬウェブ・ページを要求することによって共同ブラ
ウズ・セッションを開始することができる、少なくとも
１つのブラウザ対応ＨＴＴＰデバイスを有することであ
る。例を単純にするために、図６には、１つのデバイス
すなわちブラウザをサポートすることができるラップト
ップ機だけを有するセッション作成者を示した。

【００８２】ステップ８０５で、プロキシが、セッショ
ン作成者にセッション作成メニューを送信し、セッショ
ン名およびセッションの最初のＸＭＬウェブ・ページの
ＵＲＬを要求する。セッション作成者が、プロキシを選
択し、それをクリックした時に、要求がプロキシに送信
され、そのプロキシが、新規セッション確立フォームを
返す。ユーザは、ステップ８０６で、セッションの名
前、取り出される最初のウェブ・ページのＵＲＬ、およ
び、潜在的に、パスワードを指定する。パスワードは、
セッション名が事前に予約されている場合に使用され
る。セッション名を事前に予約するとは、セッション作
成者が、前もって（たとえば数日前に）使用するセッシ
ョン名を指定し、それにパスワードを関連付けたことを
意味する。この関連セッション名−パスワードは、セッ
ションを保護する目的で、システム管理者が共同マルチ
デバイス・ウェブ・ブラウズ・プロキシに格納すること
ができる。その形で、事前に格納されたパスワードを知
っている人だけが、この名前を有するセッションを確立
することができる。これによって、誰も、プレゼンタが
所望するウェブ・ページと異なるウェブ・ページを指
す、この名前を持つセッションを作成できないことが保
証される。セッションの事前予約のこのアイデアは、家
庭のシナリオではなく、スライド・プレゼンテーション
の場合に有用である。

【００８３】プロキシは、完成したフォームを受信した
時に、ステップ８０７で、このセッション名に関するパ
スワードを有するかどうかを判定する。そうである場合
には、プロキシは、格納されたパスワードを、ユーザが
指定したパスワードと比較する。ユーザが入力したパス
ワードが一致しない場合には、要求を除去する。しか
し、パスワードが正しい場合、または、このセッション
に関する事前に格納された情報がない場合には、プロキ
シは、ステップ８０８で、適当なウェブ・サーバからウ
ェブ・ページを取り出すことができる。プロキシは、要
求がそこから来たソケットおよびＩＰアドレスを記憶
し、ウェブ・ブラウザから返されたファイルとそれらを
関連付ける。

【００８４】セッション作成フォームで指定されたＵＲ
Ｌに対応するページ（ＸＭＬまたはＨＴＭＬ）が、プロ
キシに到着した時に、プロキシは、ステップ８０９で、
セッションを確立するためにそれを処理する必要があ
る。それがＨＴＭＬ文書である場合には、そのセッショ
ンは、上で述べたようにポリシ・ファイルを有しないの
で、行うことができる文書部分の分割は、media_types
に制限され、異なる特権グループの、準備のできた実装
はない。ＸＭＬ文書の好ましい実施形態では、ＸＭＬ文
書を解析して、他のどの文書を取り出さなければならな
いかを判定する必要がある。通常は、ＸＳＬ文書も取り
出す必要がある。さらに、ページに、「ポリシ」ファイ
ルへの参照が含まれ、ポリシ・ファイルを取り出す必要
があることが示される場合がある。

【００８５】解析されたＸＭＬページにポリシ・ファイ
ルへの参照がある場合には、ステップ８１０で、プロキ
シが、ウェブ・サーバからポリシ・ファイルをダウンロ
ードする。プロキシは、ポリシ・ファイルを使用して、
特権グループに基づく、ウェブ・ページのさまざまなコ
ンポーネントを異なるユーザおよび出力デバイスにディ
スパッチする規則を確立する。プロキシは、次の３つの
シナリオの１つに出会う：１）ポリシ・ファイルが、ウ
ェブ・ページによって参照され、そのポリシ・ファイル
ですべての特権グループのパスワードが定義される、
２）ポリシ・ファイルが参照されるが、いくつかの特権
グループのパスワードが定義されていない、３）ウェブ
・ページにポリシ・ファイルへの参照が含まれない。

【００８６】ポリシ・ファイルにアクセスする際に、プ
ロキシは、グループおよび各グループが何を受信するこ
とを許可されているかに関する一般的な情報だけを有す
る。プロキシは、まだ特定のユーザまたはデバイスに関
するポリシを作成していない。ユーザごとの許可される
ＸＭＬタグの許可される出力デバイスへの完全なマッピ
ングを作成するためには、プロキシは、各ユーザが、パ
スワードを介してログインし、所与の特権グループのメ
ンバとしてユーザ自身を識別し、各ユーザが、彼らの出
力デバイスを登録し、その結果、ウェブ・マルチメディ
ア（この登録はすでに行われている可能性があるので図
示せず）を受信するのに使用可能なデバイスをプロキシ
が知るようにすることを必要とする。

【００８７】ステップ８１１の判定で、ポリシ・ファイ
ルが存在し、ステップ８１２の判定で、そのポリシ・フ
ァイルですべての特権グループのパスワードが定義され
ている場合に、プロキシは、ポリシ・ファイルを分析し
て、可能な特権グループの値およびそれに関連するパス
ワードおよび許可を識別する。ポリシ・ファイルによっ
て、誰が何を見、どのデバイスが文書のどの部分を受信
するかを制御することが可能になる。それを行うため
に、ポリシ・ファイルで、特権グループと、各特権グル
ープがＸＭＬタグのどのサブセットの受信を許可される
かを定義する。ポリシ・ファイルは、さらに、アクセス
・デバイスのタイプに従って、各特権グループ内でより
微細な粒度でタグをデマルチプレクスできるようにする
詳細を提供することができる。したがって、セッション
を確立するために、プロキシは、作成者によって定義さ
れた特権グループ値、それに関連するパスワードが存在
する場合にそのパスワード、およびこのグループについ
て許可されるタグのリストを分離する必要がある。プロ
キシによる規則の作成および各加入ユーザに文書のどの
部分を送信できるかのマッピングは、この情報を使用す
ることによって行われる。ステップ８１３で、パスワー
ドを検証した後に、プロキシは、ポリシ・ファイル情報
を適用して、ステップ８１４で文書を文書部分に分割
し、ステップ８１５でこれらの部分を配送のためにマッ
ピングすることができる。ユーザが出力デバイスを指定
した場合には、プロキシは、クライアント位置への配送
のために文書部分をマッピングする際に、この情報も
「調べる」。

【００８８】ステップ８１１の判定でポリシ・ファイル
がない場合、ユーザへのタグのマッピングを、なんらか
のヒューリスティックを使用して、プロキシによって生
成しなければならない。すべてのタグが、基本的に未定
義であるから、デフォルトは、メディア・タイプまたは
ＭＩＭＥタイプに基づいてタグを切り替えることになる
可能性が高い。この場合は、セッション作成者によって
ＨＴＭＬ文書が要求される場合と同一である。実際、Ｘ
ＭＬ文書がポリシ・ファイル参照を有しない場合、この
ＸＭＬ文書は、ＸＳＬ文書の助けを得てＨＴＭＬ文書に
変換されなければならない。そうでなければ、タグがプ
ロキシに対して何も意味しないので、まったくデマルチ
プレクスを行うことができない。ＨＴＭＬ文書の場合、
行うことができる唯一の解析は、メディア・タイプに基
づくものであり、画像またはオーディオを文書の残りか
ら分離することができ、これらの異なるメディア・タイ
プを異なるデバイスに送信する申し出が、ユーザに対し
て行われる。さらに、ポリシ・ファイルがないか、ユー
ザの特権レベルを検証するためのパスワードがない場合
には、１つのデフォルト特権グループだけが存在する。
したがって、パスワードが定義されていないので、この
単一の特権グループへのアクセスはオープンである。し
たがって、このセッションに参加するすべてのユーザ
が、アクセスを許可され、自分のデバイスの間での、ウ
ェブ・コンテンツのメディアタイプ・ベースの分割しか
選択できない。プロキシの役割は、ステップ８１６で、
文書をメディアタイプ文書部分に分割することと、ステ
ップ８１７で、ユーザ・デバイス情報に従って、これら
の部分を配布のためにクライアント出力デバイスにマッ
ピングすることになる。

【００８９】プロキシが、任意のＵＲＬを受信した場合
には、プロキシは、新しいセッションを確立しなければ
ならないか否かを判定しなければならない。これは、セ
ッション作成者がセッションを確立した後であっても、
セッション作成者が、プレゼンテーションの一部でない
ページまたは同一のウェブ・サイトの一部でないページ
をブラウズすることができなければならないという発想
である。２つのサイトまたは２つのプレゼンテーション
の間の相違は、これらのページのオーサリングに使用さ
れるタグと、その結果としてこれらが参照するポリシ・
ファイルである。ユーザが、自分のブラウザから任意の
ウェブ・ページまたはＵＲＬを要求する時には、プロキ
シは、所望されたページを、既存のセッション内で表示
しなければならないのか、新しいセッションの最初のペ
ージとして表示しなければならないのかを判定する必要
がある。第１に、要求は、新しいセッションの確立を望
むセッション作成者から来る可能性がある。第２に、要
求は、既存のセッション内でウェブ・ページを表示した
いと思っているだけの、すでに確立されたセッションの
リーダーから来る可能性がある。第３に、要求は、現在
のセッションを去り、新しいセッションを始めることを
望む、既存のセッションのリーダーから来る可能性があ
る。具体的に言うと、第２および第３の可能性が、曖昧
であり、プロキシを混乱させる可能性がある。この曖昧
さは、次に説明する手順によって解決される。

【００９０】プロキシが任意のウェブ・ページの要求を
受信した時に新しいセッションを確立するかどうかを判
断するために、プロキシは、ポリシ・ファイルの比較に
基づく手順を使用する。要求されたウェブ・ページのポ
リシ・ファイルが、セッションの確立に使用された最初
のウェブ・ページの初期ポリシ・ファイルと一致する場
合には、プロキシは、そのウェブ・ページを同一のブラ
ウズ・セッション内で表示する。セッションが最初に確
立される時に、プロキシは、その最初のページによって
参照されるポリシ・ファイルの名前を記憶し、ポリシ・
ファイル（または、ポリシ・ファイルが参照されていな
い場合には、ヌル・プレースホルダ）をキャッシュ記憶
する。同一の初期ポリシ・ファイルを参照する後続のウ
ェブ・ページのすべてが、キャッシュ記憶されたポリシ
・ファイルの特権グループおよびタグ名を再利用し、同
一のブラウズ・セッション内で表示される。異なるポリ
シ・ファイルがアクセスされるか、要求されたウェブ・
ページについてポリシ・ファイルが存在しないので、一
致が存在しない場合には、プロキシは、新しいセッショ
ンをオープンしなければならないかどうかをユーザに尋
ねることを強制される。曖昧さの問題は、要求元のユー
ザによって解決され、このユーザは、未知の要求された
ウェブ・ページを、既存のセッション内で表示しなけれ
ばならないのか、新しいセッションを確立するのに使用
しなければならないのかを示す。

【００９１】上の手順の定義は、新しいセッションを確
立するかどうかを判定するために、現在のポリシ・ファ
イルを既存セッションの初期ポリシ・ファイルと比較す
るので、再帰的であるように見える可能性がある。初期
ポリシ・ファイルによって定義される既存セッション
が、確立されるものと同一の手順に従う場合に、その既
存セッションはどうなるかという疑問が生じる。解決策
は、いくつかのセッションを、異なる経路によって作成
することである。上で注記したように、セッション開始
には３つの代替案があるが、後者の２つだけが曖昧さを
引き起こす。第１の代替案（すなわち、セッション作成
者が、プロキシに未知であり、要求されたＵＲＬも未知
である）について、初期ポリシ・ファイルと共に新しい
セッションを確立しなければならないことは明白であ
る。セッション開始の第１の代替案が、再帰を停止さ
せ、新しいセッションの確立のブートストラップにな
る。

【００９２】ページ要求（この段落の残りでは、「ペー
ジ要求」は、初期ポリシ・ファイルと一致しないポリシ
・ファイルを有するウェブ・ページの要求と同義であ
る）が行われた後に新しいセッションの確立に関してユ
ーザに照会するという事後手法の代替案は、ページ要求
を行う前に、ユーザに、そのユーザが新しいセッション
を所望することをプロキシに明示的に知らせるようにさ
せるという先験的手法である。エンド・ユーザは、次に
要求するＵＲＬが、新しいセッションの確立に使用され
なければならないことをプロキシに知らせる。しかし、
先験的にプロキシに明示的に知らせるためには、メッセ
ージを生成するクライアント側コードが必要である。こ
れは、たとえば、プロキシに通信するのに使用されるコ
ントロールを含む、ウェブ・ページ内のフレームまたは
アプレットによって提供することができる。コントロー
ル・フレームを挿入するために各ウェブ・ページを再度
生み出すことには、ウェブ・ページのレイアウトが変化
するというそれ自体の危険性が伴う。特に画面の小さい
ＰＤＡの場合に、フレームおよびアプレットのサポート
に依存することはできない。対照的に、ページ要求が行
われた後に、ユーザに新しいセッションを確立するかど
うかを尋ねる手法は、クライアント側コードを必要とす
るのではなく、単に、ブラウザによりサポートされるフ
ォームを必要とし、これはＰＤＡであっても一般的であ
る。ウェブ・ページは変更されず、ウェブ・ブラウザと
のユーザの対話は変更されない、すなわち、ユーザは、
通常の対話を継続するか、ポイント・アンド・クリック
を行うか、新しいＵＲＬを入力する。ユーザに要求され
る処置は、ユーザに対する画面プロンプトとして送信さ
れる。共同ブラウズ・プロキシとの対話は、自己誘導式
であって、ユーザが知る必要のあるすべてのものが、画
面プロンプトに含まれる。対照的に、先験的にプロキシ
に明示的に知らせる手法では、共同ウェブ・ブラウズ・
プロキシを使用するためにユーザがブラウザと対話する
方法を、ユーザが変更する必要がある、すなわち、ユー
ザは、新しいＵＲＬをポイント・アンド・クリックする
前に、新しいセッションを明示的に要求しなければなら
ないことを知る必要がある。この手法は、初期ポリシ・
ファイルに従わないウェブ・ページをユーザが要求する
たびに、おそらく高い頻度で迷惑なポップアップ・メニ
ューがもたらされるという短所を有する。このポップア
ップ効果は、複数のウェブ・ページに適用されるように
ポリシ・ファイルの有効範囲を拡張することによって、
軽減することができる。さらに、下で説明する任意選択
の機構を使用して、ポップアップ照会を完全に抑止する
ことができる。この任意選択の機構は、明示的手法と同
一の短所を有する、すなわち、ユーザが、プロキシと対
話する方法について事前に知識を有することを必要とす
る。

【００９３】ページ要求の後に新しいセッションの確立
に関してユーザに照会するという事後手法は、セッショ
ン・リーダーがセッション確立照会を抑止できるように
する任意選択の機構を用いて補足することができる。こ
れは、初期ポリシ・ファイルの有効範囲の外の多数のウ
ェブ・ページにアクセスするセッション・リーダーに、
セッション確立照会が送信される頻度を最小にするのに
役立つ。１つの解決策は、セッション確立照会を明示的
に抑止またはイネーブルするオン／オフ・ボタンまたは
チェック・ボックスを設けることである。チェック・ボ
ックスが、セッション確立照会を抑止するようにセット
されているブラウズ・セッション中は、セッション・リ
ーダーは、プレゼンテーション中に繰り返される照会で
悩まされない。もちろん、これらの照会が抑止されてい
る間は、セッション・リーダーは新しいセッションを確
立することができなくなる。初期ポリシ・ファイルの有
効範囲の外のウェブ・ページに関する要求のそれぞれ
が、既存のブラウズ・セッション内でそのウェブ・ペー
ジを表示する要求であると仮定される。Undefined_tags
機構は、未知のポリシ・ファイルまたは欠けているポリ
シ・ファイルをオーバーライドする。照会が再びイネー
ブルされた後に、セッション・リーダーは、初期ポリシ
・ファイルの有効範囲の外のウェブ・ページを要求する
ことができ、その後、新しいセッションの確立に関する
照会を受ける。このオン／オフ機能は、ブラウザが保護
されたウェブ・ページに出会う時にしばしば表示される
ポップアップ・メニューの抑止に似ており、ブラウザに
ダウンロードされるユーザ・カスタマイズ・アプレット
と共に含めることができる。セッション・リーダーのブ
ラウザが、ダウンロード可能なアプレットまたはクライ
アント側カスタマイズ・コードをサポートしない場合に
は、デフォルト設定を、照会をイネーブルするようにセ
ットしなければならない。照会の明示的抑止は、事後セ
ッション確立機構と相補的であり、したがって、共同ウ
ェブ・ブラウズの正しい機能のために絶対に必要ではな
い。

【００９４】図１０に、ＵＲＬを受信した時にセッショ
ン確立を判定するためにプロキシによって使用される最
終的なアルゴリズムを要約した擬似コードを示す。この
アルゴリズムは、考慮しなければならない多数の特殊な
場合に起因して、前に輪郭を示したものより複雑であ
る。図１０では、「現在のポリシ・ファイル」が、現在
要求されているウェブ・ページ／ＵＲＬに関連するポリ
シ・ファイルを指す。「既存セッション内でページを表
示する」は、要求されたページに基づいて新しいセッシ
ョンを確立するのではなく、既存のブラウズ・セッショ
ンのすべてのサブスクライバに、要求されたウェブ・ペ
ージを送信することを意味する。

【００９５】この段階で、プロキシは、要求されたウェ
ブ・ページのために新しいセッションをセット・アップ
するか否かを知っている。したがって、プロキシは、次
の、ユーザ・ログインに進んで、新しいセッションを開
始するか、そのステップを飛び越えて、単に要求された
ウェブ・ページを共同ブラウズ・セッションのサブスク
ライバに配布するかのいずれかを行う。

【００９６】図１１に、前述のステップ８０７の「ユー
ザ許可」を実行するためにプロキシが作成するカスタマ
イズされたログイン・ページを示す。プロキシは、この
ログイン・ページに、すべての可能な特権グループのリ
ストを含め、その結果、ユーザが自分の属する特権グル
ープを選択できるようにする必要がある。プロキシは、
このページを動的に作成した後に、これからセッション
作成者と呼ばれるユーザに送信する。セッション作成者
に送信されるハイパーテキストＨＴＭＬ／ＸＭＬログイ
ン・インターフェースを、図１１に示す。このインター
フェースは、合成物であり、インターフェースのすべて
のフィールドが、各セッション作成者に示されるわけで
はない。プロキシは、ログイン処理によって供給される
パスワードを使用して、セッション作成者を特権グルー
プに分類し、ユーザ名を使用して、セッション開始元の
登録された出力デバイスに関してＳＤＤＢに照会する。

【００９７】ログイン・ページは、セッション確立に関
する下記の条件すなわち、（条件ｉ）ユーザがプロキシ
に未知の場合、または（条件ｉｉ）ユーザがプロキシに
既知（進行中のセッションに加入）であり、ユーザが加
入してる進行中のセッションの初期ポリシ・ファイルと
一致しないポリシ・ファイルを有するＵＲＬを要求し、
そのユーザが、新しいセッションを確立するかどうかを
尋ねるプロキシからの質問に「はい」と応答し、その
後、セッションを確立した場合のどちらかの下で、セッ
ション作成者に送信される。図８および図９のアルゴリ
ズムでは、初期ポリシ・ファイルがセッション確立中に
存在した場合と存在しなかった場合を区別するが、条件
ｉｉでは、一般性を失わずにその区別を無視することが
でき、両方の場合を１つに合体させることができる。ロ
グイン・ページは、セッション確立に使用される条件の
セットに応じて変化する。

【００９８】セッション作成者は、ログイン・ページの
ルック・アンド・フィールに影響する３つの追加の可能
性すなわち、（条件ａ）現在のポリシ・ファイルが、要
求されたウェブ・ページによって参照され、すべての特
権グループのパスワードを定義する、（条件ｂ）現在の
ポリシ・ファイルが、参照されるが、一部の特権グルー
プのパスワードを定義しない、（条件ｃ）ウェブ・ペー
ジが現在のポリシ・ファイルへの参照を含まない、に出
会う。

【００９９】ログイン・ページの最初のフィールドで
は、セッション作成者に、そのユーザ名を識別するよう
に要求する。このフィールドは、セッション作成者がプ
ロキシにとって新規である時（条件ｉ）に、唯一の絶対
に必要なフィールドであり、セッション作成者が進行中
のブラウズ・セッションの一部である、すなわち、セッ
ション作成者の識別がすでに既知である時（条件ｉｉ）
には、技術的には必要でない。条件ｉの場合、プロキシ
は、セッション作成者と、ＳＤＤＢにそのユーザ名の下
で登録された出力デバイスとを一致させるために、セッ
ション開始元のユーザ名を知る必要がある。供給される
ユーザ名は、セッション作成者のデバイスと共に登録さ
れたユーザ名と同一でなければならない。ユーザ名に相
違がある場合、プロキシは、デバイスをその正しい所有
者に関連付けることができなくなる。条件ｉｉの場合、
プロキシは、ユーザ名フィールドを送信するというオプ
ションを有する。この現在の意図は、プロキシがすでに
セッション開始元の過去のユーザ名を知っている場合で
あっても、このフィールドを表示することである。セッ
ション作成者が、過去のセッションから去って新しいセ
ッションを確立する間に、識別を変更したい状況が存在
する可能性がある。もちろん、セッション作成者は、新
しいユーザ名の下でそのセッション作成者が所有するデ
バイスを再登録しなければならない。

【０１００】第２のフィールドでは、ユーザに、パスワ
ードの同等物を供給するように要求し、その結果、プロ
キシが、セッション作成者が属する特権グループを識別
できるようにする。パスワードと同等とみなされるもの
は、条件ａ、ｂ、およびｃに応じて変化する。現在のポ
リシ・ファイルで定義されているすべての特権グループ
へのアクセスが、パスワードによって保護されている場
合（条件ａ）、ログイン・ページには、パスワード・フ
ィールドだけが表示される。しかし、特権グループの一
部が、パスワードによってアクセス保護されていない場
合（条件ｂ）、ログイン・ページには、パスワード・フ
ィールドと、パスワード保護されない公開特権グループ
のリストのハイブリッドが提示される。このハイブリッ
ド・シナリオの例が、図１１に示されており、この図で
は、スライド・プレゼンテーションの公開特権グループ
「lecturer」および「students」が、パスワード保護さ
れておらず、少なくとも１つの他の特権グループが、パ
スワード入力を必要とする。セッション作成者が、非パ
スワード保護グループのメンバとして参加することを望
む場合には、セッション作成者は、単に所望の公開グル
ープのボックスをチェックする。そうでない場合には、
セッション作成者は、適当なパスワードを入力する。最
後に、要求されたウェブ・ページに関連する現在のポリ
シ・ファイルがない場合（条件ｃ）、プロキシは、１つ
の公開特権グループだけを作成する。その結果、１つの
特権グループだけが、チェックボックスと共にリストさ
れ、パスワード・フィールドは表示されない。

【０１０１】パスワードは、スライド・プレゼンテーシ
ョンの最初のウェブ・ページの作成者からの電子メール
など、なんらかのアウト・オブ・バンド方法を介して、
セッション作成者に前もって知らされることが仮定され
ている。しかし、聴衆のすべてのメンバが、かならず先
験的に既知ではない場合があり、その結果、事前のパス
ワード配布を、必ず仮定することはできない。たとえ
ば、進行中のブラウズ・セッションへの加入を希望する
一部の学生が、自分のパスワードを忘れた、パスワード
を一度も受け取っていない、またはそのクラスに入った
ばかりであるという可能性がある。これらの場合には、
公開のパスワード保護されない特権グループのサポート
によって、すべてのサブスクライバがパスワードを知る
ことを要求せずに、そのような学生が進行中のブラウズ
・セッションに簡単に参加できるようになる。

【０１０２】第３のフィールドは、セッション作成者が
セッションを私的または単一ユーザに保つことを望む場
合に、セッション作成者がチェックすることができるボ
ックスである。このボックスがチェックされている場合
には、そのセッションはＳＤＤＢに公示されない。この
場合には、セッション作成者が、本発明のプロキシのマ
ルチデバイス機能を利用することを望むが、共同機能を
望んでいない。要求されたウェブ・ページによるポリシ
・ファイルへの参照（条件ａおよびｂ）によって、公開
共同セッションをセット・アップしなければならないこ
とが暗示されると思われる場合であっても、ポリシ・フ
ァイルの存在が、必ず新しいセッションを強制的に公開
または共同にするという制約を課さないことが好まし
い。要求されるウェブ・ページがポリシ・ファイルを参
照するかどうかに無関係に、セッションの公開／私的性
質を決定するために、完全な柔軟性がセッション作成者
に与えられる。

【０１０３】第４のフィールドは、セッション作成者
が、後続のウェブ・ブラウズ・セッション中に新しいセ
ッションを形成するかどうかを尋ねる照会のすべてを即
座に抑止することを望む場合に、セッション作成者がチ
ェックすることができるボックスである。そのような照
会は、条件ｉｉがあてはまる時すなわち、セッション・
リーダーが、セッションの確立に使用された初期ポリシ
・ファイルと異なるポリシ・ファイルを有するさまざま
なウェブ・サイトを訪れる時に、生成される。このオプ
ションは、頻繁に初期ポリシ・ファイルの有効範囲の外
に出るユーザが、繰り返される照会を即座に抑止できる
ようにするために、ログイン・ページ内に設けられる。
ユーザは、ログイン・フォームに書き込み、プロキシに
サブミットする。

【０１０４】データ・プッシュ処理が、この段階で初期
化される。Netscape NavigatorおよびＩＥの場合、デー
タ・プッシュは、クライアントの計算機にダウンロード
されるアプレットを使用することになる。このアプレッ
トは、ログイン・ページがユーザに送信される時にダウ
ンロードされる。これは、この時点から、プロキシがブ
ラウザにデータをプッシュできることを意味する。

【０１０５】プロキシは、セッションを確立しなければ
ならない（セッション作成者が、このセッションを確立
することを許可された）ことを知っているので、そのセ
ッションをサービス・ディスカバリに登録することがで
き、その結果、そのセッションが公示され、人々がその
セッションに参加できるようになることに留意された
い。プロキシは、ポリシ・ファイルに含まれる情報を使
用して、このセッションをサービス・ディスカバリに登
録する。プロキシは、アクセス・モードとしてＵＲＬを
供給してこのセッションを登録する。これは、プロキシ
がポリシ・ファイルから作成する動的ログイン・ページ
のＵＲＬであり、この動的ログイン・ページでは、この
セッションの特権グループのリストが指定され、ユーザ
のパスワードおよび名前が要求される（図１１）。サー
ビス・ディスカバリ・データベースへの登録に使用され
るＡＰＩ機能呼出しは、次のようになる（具体的な呼出
しは、選択されたプロトコルに依存する）。 register(name, access_url, proxy_@); ここで、nameは、セッションを識別し（たとえばトラン
スコーディング・プロキシ）access_urlは、登録のため
にプロキシによって作成されるフォームのＵＲＬであり
proxy_@は、セッションをホスティングするプロキシの
アドレスであるこのステップの後に、サービス・ディス
カバリは、その室内で使用可能であり、エンドユーザが
参加することのできるサービスとして、そのセッション
をリストする。登録されたセッションは、図６のＳＤＤ
Ｂの右側の箱の右欄に現れる。

【０１０６】サービス・ディスカバリは、登録されたセ
ッションを「告知解除」する能力を許容しなければなら
ない。たとえば、ユーザが、「keep new session priva
te」をクリックする場合に、そのセッションを、ＳＤＤ
Ｂのセッション・リストから取り除かなければならな
い。

【０１０７】プロキシは、ユーザによって登録されたデ
バイスに関する情報も検索する。具体的に言うと、プロ
キシは、ユーザがセッションを確立するのに使用してい
るデバイスのアクセス・モードを知る必要がある。この
場合のアクセス・モードは、セッション作成者が使用し
てるブラウザのタイプ（ＩＥ、Netscape Navigator、Po
cket IE）である。この情報は、プロキシによって、プ
ロキシがユーザに送信しなければならないデータのフォ
ーマットを知るために使用される。たとえば、ブラウザ
がＩＥ ５である場合には、ＩＥ ５はＸＭＬ対応なの
で、プロキシは、直接にＸＭＬ文書を送信することがで
きるが、ブラウザがNetscape Navigatorである場合に
は、Netscape Navigatorの現在入手可能なバージョンが
ＸＭＬを理解しないので、ＨＴＭＬ文書を作成しなけれ
ばならない。

【０１０８】プロキシは、ユーザが所有するデバイスに
ついて知る必要があるが、室内で使用可能な公共インフ
ラストラクチャについても知る必要がある。プロキシ
は、この情報を使用して、パーソナライゼーション・フ
ォームを設計して、ユーザが、見ることを許可されるも
のの各部分が送信される出力デバイスを選択するよう
に、ユーザが、データのより詳細な分割を選択できるよ
うにする。これらのデバイスのそれぞれについて、プロ
キシは、それにデータを送信する方法を知る必要があ
る。たとえば、ユーザは、Palm Pilot^*を使用してプロ
キシと通信することができ、したがって、規則ファイル
から、プロキシがこのエンドデバイスにＭＰＥＧファイ
ルを送信してはならないことが示される可能性がある。
しかし、プロキシがＳＤＤＢに照会する時に、ＳＤＤＢ
は、誰でも使用することができる公共ディスプレイがそ
の部屋にあることを返す。したがって、プロキシは、Ｍ
ＰＥＧタグを公共ディスプレイに関連付けることができ
るパーソナライズ・フォームを作成することができる。
ＳＤＤＢは、このディスプレイがデータのストリームま
たはＭＰＥＧファイルのどちらを期待するかなど、この
ディスプレイにアクセスする方法に関する情報も送信し
なければならない。

【０１０９】プロキシがこの「セッション」について知
った後には、このセッションに関連するタグ、このセッ
ションに関連するグループ、グループへのタグのデフォ
ルト・マッピング（より正確には、各グループ内のソフ
トウェア／ハードウェア・デバイスへのタグのデフォル
ト・マッピング）が既知になる。プロキシは、ＳＤＤＢ
にセッションを告知しており、１人のユーザすなわちセ
ッション作成者がログ・オンしている。次に、プロキシ
は、個々のユーザ、各ユーザが属するグループ、および
各ユーザに関連するデバイスを見つける。

【０１１０】プロキシは、元の文書のどのサブセット
（どのタグ）を、セッション作成者が受信することがで
きるかを（彼の特権グループおよび彼が使用しているデ
バイスを与えられて）知る。したがって、プロキシは、
このユーザのためにカスタマイズされたＸＳＬ変換ファ
イルを作成することができる。このファイルによって、
元のＸＭＬファイルから、ユーザが受信を許可され、受
信することができるタグだけが選択される。その後、ど
のエンドデバイスが文書の宛先であるかに応じて、その
文書をＨＴＭＬに変換するか、エンドユーザに直接に送
信することができる。使用されるフォーマットは、上で
述べたように、ユーザのデバイスのディスカバリ中に知
られる。この時点で、プロキシは、ユーザが見ることを
許可されている部分的ビューを送信することができる。

【０１１１】既存セッションへの参加 図７に示された処理フローのステップ７４０は、既存セ
ッションに参加する新しいユーザまたはデバイスに関す
る。この参加処理には、図１２に示された、次の６つの
ステップが含まれる。ステップ１１００で、新しいクラ
イアント位置／ユーザのそれぞれが、それ自体をサービ
ス・ディスカバリ・データベースに登録し、既存のブラ
ウズ・セッションのリストを検索する。ユーザが、セッ
ションが進行中の部屋に来た時、またはリモート講義へ
の参加を望む時に、そのユーザは、まず、そのユーザが
所有するすべてのデバイスをサービス・ディスカバリに
登録する。次に、ユーザは、サービス・ディスカバリ・
データベースから、使用可能なサービスのリストを検索
する。プロキシおよびそれがサポートするセッションの
リストの例を、図６に示す。プロキシごとに複数のセッ
ションが存在する場合がある。

【０１１２】次に、新しいユーザが、ステップ１１０２
で、既存の共同ブラウズ・セッションの１つへの参加ま
たは加入を要求する。ユーザは、ユーザが所望のセッシ
ョンを手作業で選択できるようにするために表示され
る、進行中のセッションのリストを受信する。供給され
る各セッション・レコードは、３つのセッション情報す
なわち、プロキシのＩＰアドレス、プロキシのポート番
号、およびセッションのＵＲＬからなる。上のセッショ
ン・レコードの情報は、手作業または自動的な方法のい
ずれかによって、サービス・ディスカバリ・インターフ
ェースからユーザのブラウザに転送されなければならな
い。ユーザは、リストから（上の場合のプロキシの代わ
りに）セッションを選択する。ブラウザが、プロキシ・
パラメータの自動設定およびセッションのＵＲＬの自動
取出をサポートする場合には、ユーザのセッション名の
クリックに対する応答が、ブラウザ・プロセスの開始、
プロキシ・パラメータ・フィールドの初期化、およびセ
ッションのＵＲＬを取り出すことのブラウザへの要求に
なる。ブラウザが、自動転送をサポートしない場合に
は、ユーザが、手作業でブラウザを起動し、ブラウザの
プロキシ・パラメータ・フィールドを設定し、セッショ
ンのＵＲＬを入力しなければならない。

【０１１３】プロキシ側では、すべてのＵＲＬ要求が代
行受信され、要求されたＵＲＬならびにＵＲＬ要求が到
着したポート番号に基づいて、プロキシが、要求者が既
存セッションへの参加を求めているかどうかと、そうで
ある場合にどのセッションを望んでいるかを確認するこ
とができる。要求が参加要求であると判定される場合に
は、ユーザに、そのセッションの適当なログイン・ペー
ジを送信する。

【０１１４】ステップ１１０３で、プロキシが、潜在的
なサブスクライバのそれぞれに、ユーザ名およびパスワ
ードを要求するログイン・メニューを送信する。このロ
グイン・メニューは、エンド・ユーザに送信される。こ
のログイン・メニューは、これ以降サブスクライバと呼
ばれるユーザが、セッションを私的に保つためのチェッ
クボックス・オプションを有しないことを除いて、図１
１に類似する。ユーザは、他のすべてのフィールドを使
用可能にさせ、ユーザ名を入力しなければならず、パス
ワードの入力または特権グループのクリックのいずれか
を行わなければならない。セッションの参加には、セッ
ションの確立より少ない数のステップが含まれることに
留意されたい。というのは、セッションの参加では、セ
ッション確立メニューと、最初のＸＭＬページおよびポ
リシ・ファイルのダウンロードがスキップされるからで
ある。セッション確立処理のフローと同様に、データ・
プッシュ・アプレットがダウンロードされ、クライアン
ト内で初期化される。

【０１１５】プロキシは、ステップ１１０４で、ユーザ
が共同作業セッションへの参加を許可されることを判定
した後に、ステップ１１０５で、サービス・ディスカバ
リ・データベースに要求を送信する。このサービス・デ
ィスカバリ・データベースへの要求では、新たにログイ
ンするユーザに対して登録されたすべてのデバイスのリ
ストが要求される。プロキシは、この情報について新た
にログ・インしたユーザに照会することもできるが、上
で述べたように、サービス・ディスカバリ・データベー
スにすでに格納されている使用可能なユーザ・デバイス
情報を使用することが好ましい。上で詳細に述べたセッ
ション確立処理と同様に、このステップには、新しいサ
ブスクライバに対して登録されたすべてのデバイスのリ
ストを検索する作業が含まれるが、セッション参加処理
のフローでは、セッションをサービス・ディスカバリに
告知する必要はない。

【０１１６】最後に、ステップ１１０６で、プロキシ
が、１つまたは複数のユーザ・デバイスでの表示のため
に、新たにログ・インしたユーザに、ウェブ・ページの
適当な部分的ビュー（すなわち、文書の１つまたは複数
の部分）を返す。ウェブ・ページの部分的ビューは、新
しいサブスクライバならびにセッション作成者の両方に
よってプルされる。というのは、この両方が、そのログ
イン入力に起因するプロキシからの応答を期待している
からである。さらに、新しいサブスクライバとセッショ
ン作成者の両方が、入力許可を有するセッションの他の
メンバによって開始されるプッシュ・イベントに応答す
ることができるアプレットをダウンロードしている。別
のメンバが新しいページを要求した時に、プロキシは、
この更新をセッション・メンバのディスプレイにプッシ
ュするか、新しいデータを、加入したエンドデバイス
（スピーカなど）に送信する。

【０１１７】エンドデバイスがブラウザの場合には、デ
ータのプッシュに使用する方法を決定するために、使用
されるブラウザのタイプを知る必要がある。登録時に、
プロキシは、どのエンドユーザがどのブラウザ・タイプ
を使用しているかを、ＨＴＴＰヘッダのUser-Agentフィ
ールドの完了によって知る。その後、プロキシは、ブラ
ウザのタイプに従ってデータ・プッシュを開始する方法
を知る。ブラウザ以外のデバイスの場合、サービス・デ
ィスカバリによって返される情報は、これらのデバイス
にアクセスする方法をプロキシに直接に知らせるもの
か、エンド・デバイスと通信する方法を知る方法をプロ
キシに与えるもののいずれかでなければならない。

【０１１８】副文書からデバイスへのマッピング サブスクライバが、確立されたセッションに参加した
後、またはセッション作成者が、セッション確立を終了
した後に、セッションの各参加者は、ユーザの個人的趣
味に従って、デバイスへのタグのマッピングを構成する
ことができる。プロキシは、当初、ポリシ・ファイルに
よって供給される情報を使用して、許可されるタグの許
可される出力デバイスへのデフォルト・マッピングを構
成する。しかし、このデフォルト・マッピングが、エン
ド・ユーザを満足させない可能性があり、図７に詳細に
示された処理フローのステップ７６０に関して上で注記
したように、セッション作成者が、文書部分の出力デバ
イスへのマッピングを動的に変更することを望む場合が
ある。セッション作成者は、自分のデバイス上で、自分
のために作成されたデフォルト設定を見ることができ、
どのタグをどのデバイスに送るかを決定することによっ
て、より微細なレベルでカスタマイズすることを望むこ
とを決定することができる。プロキシによって行われる
デフォルト構成は、たとえば、セッションを開始するデ
バイスが表示できるタグだけを送信する可能性があり、
これは、小型デバイスの場合に制限的になる可能性があ
る。その結果、セッション作成者は、パーソナライゼー
ション・フォームを使用して、自分にとってより便利な
データの分割を行う。

【０１１９】パーソナライゼーション・ボタンは、ログ
アウト・ボタンと共にコントロール・パネル上に配置す
ることができる。ユーザは、１つのブラウザ・ウィンド
ウ上でセッションの初期化を行うが、プロキシがユーザ
に部分的なビューを送信する準備ができた時には、プロ
キシは、それを子ウィンドウで行う。ユーザは、コント
ロール・パネルを親ウィンドウに送り、ユーザが、２つ
のウィンドウすなわち、ブラウズ・セッションに追従す
るウィンドウと１つのコントロール・ウィンドウを有す
ることになる。コントロール・パネルには、ユーザがセ
ッションからログアウトできるようにするボタンが含ま
れる。ユーザがコントロール・ログアウト・ボタンを呼
び出すことによって、プロキシが、このユーザをリスト
から除去し、彼に適用された変換ファイルのすべてを削
除するように指示される。コントロール・パネルには、
ユーザが現在の設定に満足しない場合に、パーソナライ
ゼーション・フォームを要求し、タグとデバイスの間の
関連付けを変更できるようにする、パーソナライズのた
めのボタンも含まれる。

【０１２０】ユーザが、「カスタマイズ」ボタンをクリ
ックする時に、プロキシが、接続され、情報の第３の画
面を返す。プロキシは、許可されるマルチメディア・タ
グの許可される出力デバイスへのマッピングを作成する
のに必要なすべての情報を有する。タグは、ＸＭＬファ
イルから取られる。ユーザの識別およびユーザが関連す
るグループは、ユーザのログイン／登録から取られる。
使用可能なデバイスおよびその所有者のリストは、サー
ビス・ディスカバリから取られる。これによって、プロ
キシが、許可されるタグの許可されるデバイスへのマッ
ピングを作成できるようになる。このマッピングは、
「カスタマイズ」ボタンがクリックされた時にエンド・
ユーザに公開され、ユーザは、適当なリストされたデバ
イスにタグを単純に「プル」して、マッピングを変更す
ることができる。

【０１２１】通常、ユーザは、セッションにログ・イン
する前に、複数のデバイスを登録する。しかし、ユーザ
が、ログ・インの後にデバイスを追加することを望む場
合がある。この場合、ＳＤＤＢに登録した後に、新しい
デバイスが、メディア供給の受信を自動的に開始し、ア
プレットが、自動的に更新される。オプションの１つ
が、コールバック関数（callback()）の使用である。コ
ールバックは、所与のユーザ名に一致するユーザが新し
いデバイスを登録したかどうかをプロキシに知らせる／
通知するようにサービス・ディスカバリに指示する（Ｕ
ＮＩＸ（登録商標）のselect()に類似する）関数であ
る。プロキシとクライアントの間のプッシュ／プルの問
題に類似して、コールバックでは、サービス・ディスカ
バリが、新しい更新をプロキシにプッシュすることが許
容される。コールバックは、効率的な機構であり、これ
によって、ユーザごとのプロキシの状態の自動更新も可
能になる。しかし、コールバックは、サービス・ディス
カバリに対する機能的な重荷を課し、ほとんど、または
一部の、サービス・ディスカバリ・プロトコルにまたが
ってサポートされない可能性がある。

【０１２２】もう１つのオプションは、エンド・ユーザ
が受信するカスタマイズ画面上の「最新表示」ボタンを
介する手動更新を有することである。ユーザが「カスタ
マイズ」ボタンをクリックした時には、これが、最新表
示と同等になる。しかし、エンド・ユーザが、一時的に
カスタマイズ画面を開き、その画面を更新しなかった場
合には、カスタマイズ画面に「最新表示」ボタンも含め
ることが必要になる。カスタマイズ画面の最新表示ボタ
ンを、最初の画面のカスタマイズ・ボタンと組み合わせ
ると、コールバック関数の必要がなくなる。その代わり
に、エンド・ユーザが、新しいデバイスが追加された時
にプロキシ状態（およびカスタマイズ画面）のすべての
更新を手作業で開始する。エンド・ユーザは、基本的
に、そのユーザに対して新たに登録されたデバイスに対
応するデータを、プロキシを介して、サービス・ディス
カバリからカスタマイズ画面にプルする。

【０１２３】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１２４】（１）サーバから複数のクライアント位置
へ文書コンテンツを選択的に供給する方法であって、前
記サーバからプロキシへ少なくとも１つの文書を供給す
るステップと、前記少なくとも１つの文書を複数の文書
部分に選択的に分割するステップと、前記複数の文書部
分の少なくとも１つを前記複数のクライアント位置のそ
れぞれに選択的に供給するステップとを含む方法。 （２）前記少なくとも１つの文書が、少なくとも１つの
他のファイルへのリンクを含み、前記方法がさらに、前
記プロキシが、前記少なくとも１つの他のファイルを事
前取出しし、前記少なくとも１つの他のファイルをキャ
ッシュ記憶するステップを含む、上記（１）に記載の方
法。 （３）前記プロキシが、前記少なくとも１つの文書が、
関連するポリシ・ファイルを有することを判定するステ
ップと、前記ポリシ・ファイルにアクセスするステップ
とをさらに含む、上記（１）に記載の方法。 （４）前記選択的に分割するステップが、前記ポリシ・
ファイルに従って前記文書を文書部分に分割するステッ
プを含む、上記（３）に記載の方法。 （５）前記ポリシ・ファイルが、クライアント・アクセ
ス情報を指定し、前記選択的に供給するステップが、前
記クライアント・アクセス情報に基づいて文書部分をク
ライアント位置に向けるステップを含む、上記（４）に
記載の方法。 （６）文書部分を選択的に供給するステップが、前記文
書部分のすべてより少ない文書部分を、前記複数のクラ
イアント位置の少なくとも１つに向けるステップを含
む、上記（５）に記載の方法。 （７）前記複数のクライアント位置が、１つのクライア
ント位置でコンテンツを出力するための複数のデバイス
を含む、上記（１）に記載の方法。 （８）さらに、前記プロキシが、前記複数のデバイスの
それぞれのコンテンツ出力機能を判定するステップを含
む、上記（７）に記載の方法。 （９）前記クライアント位置に関するサービス・ディス
カバリを行うステップと、前記クライアント位置のため
のサービス・ファイルを作成するステップとをさらに含
む、上記（７）に記載の方法。 （１０）前記行うステップおよび前記作成するステップ
が、前記プロキシで実行される、上記（９）に記載の方
法。 （１１）さらに、前記プロキシが、前記サービス・ファ
イルにアクセスするステップを含む、上記（９）に記載
の方法。 （１２）前記選択的に分割するステップが、前記コンテ
ンツ出力機能に基づいて、前記文書を文書部分に分割す
るステップを含む、上記（８）に記載の方法。 （１３）前記選択的に分割するステップが、前記サービ
ス・ファイルに基づいて、前記文書を文書部分に分割す
るステップを含む、上記（１１）に記載の方法。 （１４）さらに、前記プロキシが、前記文書部分を前記
複数のデバイスにマッピングするステップを含む、上記
（７）に記載の方法。 （１５）さらに、前記クライアント位置のユーザが、前
記マッピングを動的に変更するステップを含む、上記
（１４）に記載の方法。 （１６）前記プロキシが、前記複数の文書部分の少なく
とも１つをトランスコーディングするステップを追加的
に含む、上記（１）に記載の方法。 （１７）前記プロキシが、前記コンテンツ出力機能に基
づいて、前記複数の文書部分の少なくとも１つをトラン
スコーディングするステップを追加的に含む、上記（１
２）に記載の方法。 （１８）少なくとも１つの文書を作成するステップと、
前記少なくとも１つの文書を前記サーバで格納するステ
ップとをさらに含む、上記（１）に記載の方法。 （１９）前記少なくとも１つの文書に関する少なくとも
１つのポリシ・ファイルを定義するステップと、前記少
なくとも１つのポリシ・ファイルを前記少なくとも１つ
の文書に関連付けるステップとをさらに含む、上記（１
８）に記載の方法。 （２０）前記関連付けるステップが、前記ポリシ・ファ
イルを前記少なくとも１つの文書に組み込むステップを
含む、上記（１９）に記載の方法。 （２１）前記少なくとも１つのポリシ・ファイルを定義
するステップが、前記文書の前記少なくとも１つの文書
の複数の文書部分を指定するステップを含む、上記（１
９）に記載の方法。 （２２）前記複数の文書部分のそれぞれのアクセス規則
を確立するステップをさらに含む、上記（２１）に記載
の方法。 （２３）前記複数の文書部分のそれぞれへのアクセスに
関する特権グループを確立するステップをさらに含む、
上記（２１）に記載の方法。 （２４）前記特権グループが、前記複数の文書部分のそ
れぞれにアクセスできるクライアントを識別する、上記
（２３）に記載の方法。 （２５）複数のクライアント位置、ウェブ・サーバ、少
なくとも１つのサービス・ディスカバリ・データベー
ス、および前記ウェブ・サーバと前記複数のクライアン
ト位置との間に配置される複数のプロキシ・コンポーネ
ントを含むシステム内で、クライアント・セッション要
求者からの要求に応答して共同ウェブ・ブラウズ・セッ
ションを確立する方法であって、前記プロキシが、前記
サービス・ディスカバリ・データベースに登録するステ
ップと、前記セッション要求者が、前記サービス・ディ
スカバリ・データベースに登録するステップと、前記セ
ッション要求者が、プロキシを選択するステップと、前
記セッション要求者が、セッションを作成する要求を前
記プロキシに送信するステップと、前記プロキシが、少
なくともセッション名と少なくとも１つのセッション文
書の記憶位置とを含むセッション情報を要求するステッ
プと、前記セッション要求者が、前記セッション情報を
入力するステップと、前記プロキシが、前記少なくとも
１つのセッション文書を取り出すステップと、前記プロ
キシが、前記少なくとも１つのセッション文書に関する
プロキシ・ファイルが存在するかどうかに関する判定を
行うステップと、前記プロキシが、前記判定に基づい
て、前記少なくとも１つのセッション文書を複数の文書
部分に選択的に分割するステップと、前記プロキシが、
前記複数の文書部分を前記複数のクライアント位置の少
なくとも１つに選択的に供給するステップとを含む方
法。 （２６）少なくとも１つの新しいユーザが前記セッショ
ンに参加するステップをさらに含み、前記参加するステ
ップが、前記少なくとも１つの新しいユーザが、既存セ
ッションのリストを得るステップと、前記少なくとも１
つの新しいユーザが、前記既存セッションの１つの選択
されたセッションを選択し、前記選択されたセッション
に参加する要求を生成するステップと、前記プロキシ
が、前記少なくとも１つの新しいユーザにログイン・メ
ニューを供給するステップと、前記プロキシが、前記少
なくとも１つの新しいユーザに関するユーザ・アクセス
を検証するステップと、前記プロキシが、ユーザ出力デ
バイス情報について前記セッション・ディスカバリ・デ
ータベースに照会するステップと、前記プロキシが、前
記ユーザ出力デバイス情報に基づいて、前記少なくとも
１つの新しいユーザの少なくとも１つのデバイスに、前
記複数の文書部分の少なくとも１つを選択的に配送する
ステップとを含む、上記（２５）に記載の方法。 （２７）文書コンテンツを複数のクライアント位置に選
択的に供給するシステムであって、複数のクライアント
位置と、前記文書コンテンツを格納し、クライアント要
求に応答して少なくとも１つの文書を配送する、少なく
とも１つのサーバと、前記少なくとも１つの文書を前記
サーバから受信し、前記少なくとも１つの文書を複数の
文書部分に選択的に分割し、前記複数の文書部分の少な
くとも１つを前記複数のクライアント位置のそれぞれに
選択的に供給する、少なくとも１つのプロキシとを含む
システム。 （２８）前記少なくとも１つのプロキシが、前記少なく
とも１つの文書に関するポリシ・ファイルにアクセス
し、前記少なくとも１つの文書を選択的に分割するため
に前記少なくとも１つのポリシ・ファイルを使用する、
少なくとも１つの処理コンポーネントを含む、上記（２
７）に記載のシステム。 （２９）前記少なくとも１つのクライアント位置が、１
つのクライアント位置にある複数のデバイスを含む、上
記（２７）に記載のシステム。 （３０）前記少なくとも１つのクライアント位置が、前
記少なくとも１つの文書に関して共同するための複数の
異なるクライアント位置を含む、上記（２７）に記載の
システム。 （３１）前記少なくとも１つのプロキシが、少なくとも
１つの前記クライアント位置に配置されたデバイスに前
記複数の文書部分をマッピングする、少なくとも１つの
処理コンポーネントを含む、上記（２７）に記載のシス
テム。 （３２）サーバから複数のクライアント位置ヘ文書コン
テンツを選択的に供給する方法ステップを実行するため
に計算機によって実行可能な命令のプログラムを具体的
に実施する、計算機によって可読のプログラム記憶デバ
イスであって、前記方法が、前記サーバからプロキシへ
少なくとも１つの文書を供給するステップと、前記少な
くとも１つの文書を複数の文書部分に選択的に分割する
ステップと、前記複数のクライアント位置のそれぞれに
前記複数の文書部分の少なくとも１つを選択的に供給す
るステップとを含む、プログラム記憶デバイス。

【図面の簡単な説明】

【図１】通常のウェブ・ブラウズ・システムの概略図で
ある。

【図２】本発明によるウェブ・ブラウズ・システムの概
略図である。

【図３】単独のユーザのウェブ・ブラウズ・セッション
が、より高機能の近くの出力デバイスを使用することに
よって機能強化される、共同マルチデバイス・ウェブ・
ブラウズの第１のシナリオを示す図である。

【図４】他のデバイスに加えて、他のユーザが、ブラウ
ズ・セッションの出力の選択された部分を受信する、共
同マルチデバイス・ウェブ・ブラウズの第２のシナリオ
を示す図である。

【図５】本発明によるデータ転送の効率を示す図であ
る。

【図６】新しい共同セッションの確立に用いられるエン
ティティを示す概略図である。

【図７】本発明の対話の全体的シーケンスを示す図であ
る。

【図８】新しい共同セッションの確立の処理フローの詳
細を示す図である。

【図９】新しい共同セッションの確立の処理フローの詳
細を示す図である。

【図１０】ウェブ・ページのＵＲＬ要求が新しいブラウ
ズ・セッションの確立をもたらす時をプロキシが決定す
るための代表的なアルゴリズムを示す図である。

【図１１】プロキシからセッション開始元のブラウザに
送信される代表的なログイン／登録画面を示す図であ
る。

【図１２】確立されたセッションに参加する新しいユー
ザまたはデバイスの代表的な処理フローを示す図であ
る。

【符号の説明】

１０ ユーザ位置 １２ ウェブ・サーバ １４ インターネット ２０ プロキシ・エンティティ ６１０ プロキシ ６１２ サービス・ディスカバリ ６１４ セッション作成者 ６１５ ウェブ・サーバ ６１６ テーブル ６１７ ポリシ・ファイル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 リチャード・ワイ・ハン アメリカ合衆国 ニューヨーク州ニューヨ ーク ウェスト セブンティフィフス・ス トリート 34 (72)発明者 イブラヒム・コーペログルー アメリカ合衆国 ニューヨーク州ヨークタ ウン・ハイツ ヒッコリー・ストリート 2854 (72)発明者 マーモウド・ナグシネー アメリカ合衆国 ニューヨーク州ホープウ ェル・ジャンクション ポンドビュー・ド ライブ ５ (72)発明者 ヴェロニク・ペレト アメリカ合衆国 ニューヨーク州オシニン グ エリス・プレース 10

Claims (32)

【特許請求の範囲】
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. 【請求項３２】サーバから複数のクライアント位置ヘ文
    書コンテンツを選択的に供給する方法ステップを実行す
    るために計算機によって実行可能な命令のプログラムを
    具体的に実施する、計算機によって可読のプログラム記
    憶デバイスであって、前記方法が、 前記サーバからプロキシへ少なくとも１つの文書を供給
    するステップと、 前記少なくとも１つの文書を複数の文書部分に選択的に
    分割するステップと、 前記複数のクライアント位置のそれぞれに前記複数の文
    書部分の少なくとも１つを選択的に供給するステップと
    を含む、プログラム記憶デバイス。