JP4197315B2 - コラボレーションサーバ、コラボレーションシステム、そのセッション管理方法及びプログラム - Google Patents

Description

【０００１】
技術分野
本発明は、複数台のコンピュータにて、ネットワークを介して共通のリソースに対する共同作業を行うコラボレーションシステムに関する。
【０００２】
背景技術
今日、コンピュータネットワークの普及に伴い、複数のコンピュータ間でデータやリソースへのアクセスが容易になっている。そこで、ファイルやデータベース、ネットワークに対するユーザの不正なアクセスを防ぐため、ユーザに与えるアクセス権限（検索のみ、更新可能など）を規定するアクセス管理が一般的に行われている。
【０００３】
また、ネットワークを介して接続されている複数のコンピュータの間で入出力やデータ処理を同期させることができる。すなわち、当該複数のコンピュータの表示装置に共通の画像を表示させたり、いずれかのコンピュータへの入力を他の各コンピュータに反映させたりする。この技術を用いて、当該コンピュータを利用する複数のユーザが、各々のコンピュータの表示装置に共通の作業画面を表示させて共同作業を行うシステム（以下、コラボレーションシステムと称す）が普及している。
【０００４】
このようなコラボレーションシステムでは、共通のリソースに対して複数のユーザが同時にアクセスする。したがって、かかるコラボレーションシステムでアクセス管理を行う場合、共同作業を行う全てのユーザが作業対象であるリソースへのアクセス権限を有していることが必要となる。
【０００５】
上述したように、コラボレーションシステムにおいてアクセス管理を行う場合、システムの安全を考慮すれば、共同作業を行う全てのユーザに対して作業対象であるリソースへのアクセス権限を有していることが要求される。
しかし、共同作業を行うユーザのうちの一部のみがアクセス権限を有するリソースに対して共同作業を行いたい場合がある。例えば、ＣＲＭ（Customer Relationship Management）におけるサービスの一環として、お客様とエージェントとが共通のウェブページを参照しながら、お客様からの相談や質問に応対する場合がある。この場合、お客様のみがアクセス権限を有するウェブページであっても、かかる応対の作業時には当該エージェントも当該ウェブページを閲覧できるようにすることが望ましい。
【０００６】
このような場合に当該リソースに対してアクセス権限を有しないユーザに対しても一時的にアクセス権限を認めることができれば、柔軟で利用価値の高いコラボレーションシステムを実現することができる。
そこで、本発明は、コラボレーションシステムにおいて、作業を行うユーザのうちの特定のユーザのみがアクセス権限を有するリソースに対して、一定条件下で他のユーザのアクセスを認めるアクセス管理を実現することを目的とする。
【０００７】
発明の開示
上記の目的を達成するため、本発明は、ネットワークを介してデータを交換することにより行われる複数の端末による共同作業を支援する、次のように構成されたコラボレーションサーバとして実現される。すなわち、このコラボレーションサーバは、端末からの要求に応じてリソースを取得し、要求元の端末に返送するリソース取得手段と、この端末による共同作業のセッションを管理するセッション管理手段とを備え、リソース取得手段は、所定のセッションにおいて、セッションオーナーがアクセス権限を持つリソースに対してセッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、セッションオーナーのアクセス権限に基づいてリソースを取得することを特徴とする。
これにより、セッションオーナーの持つアクセス権限を、このセッションの限りにおいて、他のユーザも共用できることとなる。
【０００８】
ここで、さらに詳細には、このリソース取得手段は、セッションオーナーの端末によるアクセス要求から取得されたアクセス権限を示す情報を、セッションオーナー以外のユーザの端末からの取得リクエストに付加することにより、所望のリソースを取得する。
また、リソース取得手段は、このリソースに対してセッションオーナー以外のユーザの端末から取得リクエストを受け取った場合であって、セッションオーナーの端末によるアクセス要求から取得されたアクセス権限を示す情報を保存していない場合や保存できない場合に、セッションオーナーの端末にこのリソースへのアクセス要求を行わせることによって、このリソースを取得する。
【０００９】
また、本発明の他のコラボレーションサーバは、端末からの要求に応じてリソースを取得し、要求元の端末に返送するリソース取得手段と、端末による共同作業のセッションを管理するセッション管理手段とを備え、リソース取得手段は、所定のセッションにおいて、アクセス制御されているリソースに対してアクセス権限のないアクセス要求があった場合に、このリソースへのアクセス権限のある他のアクセス要求から取得されたアクセス権限を示す情報に基づいてリソースを取得することを特徴とする。
【００１０】
本発明のさらに他のコラボレーションサーバは、端末からの要求に応じてリソースを取得し、要求元の端末に返送する送受信制御部と、端末による共同作業のセッションを管理するセッション管理部とを備え、送受信制御部は、所定の端末から受信した所定のリソースへの取得リクエストにアクセス権限を示す認証情報が付加されている場合に、この認証情報を所定の記憶装置に保存する。そして、所定の端末から受信したリソースの他の取得リクエストに認証情報が付加されていない場合に、保存されている認証情報を他の取得リクエストに付加してリソースのサーバに送信することを特徴とする。
【００１１】
より詳細には、この送受信制御部は、個々のセッションにおけるセッションオーナーの端末から受信した取得リクエストから認証情報を取得し保存する。すなわち、各セッションでは、セッションオーナーのアクセス権限により、他のユーザにおけるリソースへのアクセスが可能となる。
また、送受信制御部は、認証情報が保存されていない状態でセッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、この取得リクエストに対するレスポンスから認証情報の入力要求を除去して、この取得リクエストの送信元に返送する。このため、レスポンスを取得した端末では認証情報を入力することができないが、通常のコラボレーションにおける動作として、セッションオーナーがかかるリソースの取得要求を送信し、このリソースを取得する。そしてこれ以後は、セッションオーナー以外のユーザも、このリソースを取得することが可能となるため、結果としてセッションオーナーのアクセス権限に基づいてリソースの取得ができることとなる。
【００１２】
さらに本発明は、上述したコラボレーションサーバを備えて構成されるコラボレーションシステムとしても実現される。すなわち、このコラボレーションシステムは、ネットワークを介してデータを交換し共同作業を行う複数の端末と、この端末からの要求に応じてリソースを取得し各端末に渡すコラボレーションサーバとを備え、このコラボレーションサーバは、所定のセッションにおいて、アクセス制御されているリソースに対してアクセス権限を持たない端末からアクセス要求があった場合に、他の端末が持つこのリソースへのアクセス権限を用いてこのリソースを取得することを特徴とする。
ここで、このコラボレーションサーバは、さらに詳細には、アクセス制御されているリソースに対してアクセス権限を持たない端末からアクセス要求があった場合に、このリソースへのアクセス権限を持つ他の端末にこのリソースへのアクセス要求を行わせることにより、このリソースを取得する。
【００１３】
さらに上記の目的を達成する他の本発明は、ネットワークを介してデータを交換することにより行われる複数の端末による共同作業を支援する、次のようなコラボレーションサーバのセッション管理方法として実現される。このセッション管理方法は、所定の端末から受信した所定のリソースへの取得リクエストにアクセス権限を示す認証情報が付加されていない場合に、予め保存されている認証情報をこの取得リクエストに付加するステップと、受信した取得リクエストまたは認証情報が付加された取得リクエストを目的のリソースのサーバへ送信し、レスポンスを取得するステップと、取得したレスポンスを取得リクエストの送信元である端末に返送するステップとを含むことを特徴とする。
【００１４】
ここで、より好ましくは、このセッション管理方法は、共同作業のセッションにおけるセッションオーナーの端末から受信した取得リクエストから認証情報を取得し、所定の記憶装置に保存するステップをさらに含む。
また、レスポンスの内容が、リソースがアクセス制限されていることを示す情報（すなわちステータスコード４０１）である場合に、このレスポンスの返送に先立って、このレスポンス中からアクセス権限を示す情報の入力要求（すなわちWWW-Authenticateヘッダ）を除去するステップをさらに含む。
【００１５】
さらにまた、本発明は、上述したコラボレーションサーバとしてコンピュータを機能させ、またはコンピュータを制御して上記のセッション方法における各ステップに相当する処理を実行させるプログラムとして実現することができる。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録装置に格納して配布したり、ネットワークを介して配信したりすることにより提供することができる。
【００１６】
発明を実施するための最良の形態
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
図１は、本実施の形態によるコラボレーションシステムを適用するネットワークシステムの構成例を説明する図である。
図１に示すように、このネットワークシステムは、複数のユーザが共同作業を行うための端末１００と、端末１００によるウェブベースでの共同作業をサポートするコラボレーションサーバ２００と、共同作業の対象であるリソースとしてウェブコンテンツを提供するウェブサーバ３００とを備える。コラボレーションサーバ２００、端末１００及びウェブサーバ３００は、それぞれワークステーションやパーソナルコンピュータなどのネットワーク機能を備えたコンピュータ装置にて実現され、ネットワーク４００を介してデータ交換を行うことができる。ネットワーク４００は、インターネットや、その他のウェブベースのＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）等のネットワークであり、伝送路は有線であると無線であるとを問わない。
【００１７】
図２は、図１に示したネットワークシステムを用いて構築される本実施の形態によるコラボレーションシステムの全体構成を示す図である。以下、本実施の形態では、ＣＲＭにおいて、お客様（カスタマー）とエージェントとが共通のウェブページを参照しながら行う作業に用いるコラボレーションシステムとして説明する。
図２を参照すると、本実施の形態のコラボレーションシステムにおいて、端末１００は、コラボレーションサーバ２００の管理下で共同作業を行う（以下、この共同作業をセッションと呼ぶ）。また、セッションにおいては、コラボレーションサーバ２００を介してウェブサーバ３００にアクセスし、作業対象であるウェブページ（コンテンツ）を取得する。
なお、図２には、カスタマーとエージェントとに対応して２つの端末１００が図示されているが、実際には３つ以上の端末が接続されていても良い。また、以下の説明において、カスタマーが使用する端末１００とエージェントが使用する端末１００とを区別する必要がある場合には、カスタマー端末１００ａ、エージェント端末１００ｂというように添え字を付して記載するが、これらを区別する必要がない場合は、単に端末１００と記載する。これは、各端末１００の構成要素（後述するブラウザ、クライアントプログラム）に関しても同様とする。
【００１８】
コンピュータ装置にて実現される端末１００は、特に図示しないが、ハードウェア構成として、プログラム制御によりデータ処理を行うＣＰＵ（Central Processing Unit）と、ＣＰＵを制御するプログラム及び種々のデータを格納するメインメモリや磁気ディスク装置などの記憶装置と、出力手段であるＬＣＤ（液晶ディスプレイ）やＣＲＴディスプレイなどの表示装置と、キーボードやマウスなどの入力装置と、ネットワーク４００を介して他の端末１００やコラボレーションサーバ２００、ウェブサーバ３００と接続するためのネットワークインターフェイスとを備える。
【００１９】
さらに、図２に示すように、端末１００は、ウェブベースでのコラボレーションのセッションを実現する機能として、作業実行部１１０とコラボレーション制御部１２０とを備える。
この作業実行部１１０は、プログラム制御されたＣＰＵにて実現される仮想的なソフトウェアブロックであり、ネットワーク４００上のウェブサーバ３００にアクセスして所望のウェブページを取得し、表示装置に表示したり、入力装置による操作（入力フォームへの入力やスクロール、表示ページの遷移、アノテーションによる書き込みなど）を表示装置に表示されたウェブページに反映させたりする。作業実行部１１０を実現するソフトウェアとしては、例えば米国マイクロソフト社のInternet Explorerや、米国ネットスケープ・コミュニケーションズ社のNetscape Navigatorなどのブラウザを用いることができる。
【００２０】
また、コラボレーション制御部１２０は、プログラム制御されたＣＰＵにて実現される仮想的なソフトウェアブロックであり、作業実行部１１０にて行われたウェブページに対する操作を、セッション中の端末１００の間で同期させる。このコラボレーション制御部１２０は、既存のコラボレーションシステムにおけるクライアントプログラムを用いて実現することができる。クライアントプログラムは、ユーザが予め端末１００のコンピュータ装置にインストールしても良いし、Ｊａｖａのアプレットのような形式で提供し、コラボレーションによるセッションを開始する際にコラボレーションサーバ２００からダウンロードして実行するようにしても良い。
【００２１】
コラボレーションサーバ２００は、特に図示しないが、ハードウェア構成として、プログラム制御によりデータ処理を行うＣＰＵ（Central Processing Unit）と、ＣＰＵを制御するプログラム及びウェブページを含む種々のデータを格納するメインメモリや磁気ディスク装置などの記憶装置と、ネットワーク４００を介して端末１００と接続するためのネットワークインターフェイスとを備える。
さらに、図２に示すように、コラボレーションサーバ２００は、端末１００によるコラボレーションのセッションを管理するセッション管理部２１０と、セッションにおける端末１００によるウェブページの取得を仲介するリソース取得手段としてのＨＴＴＰ送受信制御部２２０とを備える。
【００２２】
このセッション管理部２１０は、プログラム制御されたＣＰＵにて実現される仮想的なソフトウェアブロックであり、端末１００にて行われるコラボレーションのセッションを管理する。具体的にはユーザごとにキャッシュテーブル２１１を作成し、ＵＡＩテーブル２１２にて管理する。そして、複数のユーザがセッションを結ぶと、同じキャッシュテーブル２１１を使うように、ＵＡＩテーブル２１２におけるキャッシュテーブル２１１へのポインタを書き換える。このキャッシュテーブル２１１及びＵＡＩテーブル２１２は、記憶装置に格納され、ユーザの操作に応じて、所定の情報が登録される。キャッシュテーブル２１１及びＵＡＩテーブル２１２の詳細については後述する。
【００２３】
ＨＴＴＰ送受信制御部２２０は、プログラム制御されたＣＰＵにて実現される仮想的なソフトウェアブロックであり、コラボレーションサーバ２００を実現するコンピュータ装置のネットワークインターフェイスを制御して、端末１００からのリクエストに応じて所定のウェブサーバ３００からウェブページを取得し、要求元の端末１００に返す。また、キャッシュテーブル２１１に登録されているウェブページのリクエストを受け付けた場合は、キャッシュされている当該ウェブページを要求元の端末１００に返す。
【００２４】
図３は、セッション管理部２１０によるセッションの管理に利用されるキャッシュテーブル２１１及びＵＡＩテーブル２１２の構成を示す図である。
キャッシュテーブル２１１は、ユーザごとに作成され、当該ユーザの操作に基づいて取得されキャッシュされたウェブページと、そのＵＲＬ（Uniform Resource Locators）とを対応付けて登録する。所定のセッションにおいて、コラボレーションサーバ２００が所定の端末１００からキャッシュテーブル２１１に登録されているＵＲＬへのリクエストを受信した場合、キャッシュテーブル２１１に基づいて、キャッシュされているウェブページが当該端末１００へ返送される。
また、キャッシュテーブル２１１は、セッションオーナー（セッションを開始させたユーザ）のウェブページへのアクセス権限を示す認証情報を登録する。詳しくは後述するが、このキャッシュテーブル２１１に登録された認証情報を用いることにより、当該セッションに参加している全てのユーザが当該セッションのみにおいて、セッションオーナーのアクセス権限に基づいてウェブページへのアクセスを行うことができる。
【００２５】
ＵＡＩテーブル２１２は、セッションに参加するユーザを特定するＩＤ情報と当該ユーザが参加しているセッションのキャッシュテーブル２１１へのポインタとを登録している。本実施の形態では、ユーザのＩＤ情報としてIBMCF_UAIというcookie（以下、ＵＡＩと略記する）を用いるものとする。所定のセッションに参加するユーザに関しては、参加するセッションのセッションオーナーの持つ（対応付けられている）キャッシュテーブル２１１へのポインタが登録される。これにより、１つのセッションにおいては１つのキャッシュテーブル２１１が各参加者によって共有されることとなる。
なお、所定のセッションに参加しているユーザが当該セッションからはずれる場合は、ＵＡＩテーブル２１２における当該ユーザのエントリから当該セッションで用いられているキャッシュテーブル２１１へのポインタが消去される。そして、必要な場合には、当該ユーザをセッションオーナーとして新たなキャッシュテーブル２１１が作成され、ＵＡＩテーブル２１２のエントリに当該新たなキャッシュテーブル２１１へのポインタが登録される。
【００２６】
ここで、通常のコラボレーションにおけるセッションの開始、作業の実行、セッションの終了の各動作例を説明する。なお、ユーザはカスタマーとエージェントの２人とし、カスタマーからのリクエストによりセッションが開始されるものとする。また、エージェントは複数存在し、そのうちの１人のエージェントがカスタマーとのセッションに参加するものとする。
初期状態として、各エージェントのエージェント端末１００ｂはコラボレーションサーバ２００にログインしているものとする。
【００２７】
まず、カスタマーがカスタマー端末１００ａにてコラボレーションサーバ２００にログインする。このとき、コラボレーションサーバ２００のセッション管理部２１０により、当該ユーザ（カスタマー）を特定するＵＡＩが設定され、カスタマーに対して設定されたＵＡＩの情報（ここでは［０００１］とする）が、ＵＡＩテーブル２１２に登録され、キャッシュテーブル２１１が作成される。また、必要な場合には、コラボレーションサーバ２００からカスタマー端末１００ａへ、クライアントプログラムが転送される。
なお、エージェント及びエージェント端末１００ｂに対しては、以上の動作が既に済んでいる。
【００２８】
次に、カスタマー端末１００ａからコラボレーションサーバ２００へ、コラボレーションのセッションの開始リクエストが送られたものとする。すると、コラボレーションサーバ２００のセッション管理部２１０により、当該セッションに対して作業の相手となるエージェントが割り振られ、セッションが開始される。ここで、相手となるエージェントは、カスタマーの指定に基づいて割り振られるようにしても良いし、セッションの開始リクエストがあった時点でセッション可能な（例えば他のセッションに参加していない）エージェントの中から適当に選択して割り振られるようにしても良い。
また、カスタマーに対して割り振られたエージェントに関して、ＵＡＩテーブル２１２の当該エージェントのエントリ（ＵＡＩ：［０００２］とする）におけるキャッシュテーブルポインタは、当該カスタマーのキャッシュテーブル２１１をポイントするように書き換えられる。この際、自分の元のキャッシュテーブル２１１は削除される。これにより、このセッションにおいて当該エージェントとカスタマーとが１つのキャッシュテーブル２１１を共有する。
【００２９】
セッションにおいて、カスタマー端末１００ａの作業実行部１１０ａからコラボレーションサーバ２００へ、所定のＵＲＬを指定したウェブページの取得リクエストが送信されたものとする。すると、コラボレーションサーバ２００のＨＴＴＰ送受信制御部２２０が当該ＵＲＬに対応するウェブサーバ３００にアクセスし、この取得リクエストにて要求されるウェブページが取得される。取得されたウェブページは、コラボレーションサーバ２００の記憶装置にキャッシュされ、キャッシュテーブル２１１に登録される。そして、このキャッシュされたウェブページがカスタマー端末１００ａへ返送される。
【００３０】
カスタマー端末１００ａにて要求したウェブページが取得されると（すなわち作業実行部１１０ａにて表示装置に当該ウェブページが表示されると）、コラボレーション制御部１２０ａにより、エージェント端末１００ｂへＵＲＬ遷移の通知がなされる。この通知は、コラボレーションサーバ２００を介して行っても良いし、カスタマー端末１００ａからエージェント端末１００ｂへ直接行っても良い。
この通知を受信したエージェント端末１００ｂでは、コラボレーション制御部１２０ｂが作業実行部１１０ｂに、当該通知に基づいて遷移先のＵＲＬのウェブページを取得させる。
【００３１】
エージェント端末１００ｂの作業実行部１１０ｂからコラボレーションサーバ２００へ、当該ＵＲＬを指定したウェブページの取得リクエストが送信されると、当該ＵＲＬのウェブページがキャッシュされているので、ＨＴＴＰ送受信制御部２２０により、キャッシュされている当該ウェブページがエージェント端末１００ｂへ返送される。
ここで、ウェブサーバ３００からウェブページを毎回取得するのではなく、キャッシュされているウェブページをカスタマー端末１００ａ及びエージェント端末１００ｂに配信するのは、例えば、取得リクエストを受け付けるたび、あるいは取得要求の送信者ごとにダイナミックにウェブページの内容やレイアウトを変更して送信するウェブサイトの場合、カスタマー端末１００ａとエージェント端末１００ｂとが別々にウェブページを取得すると、その内容やレイアウトが異なってしまい、コラボレーションによる作業を行えなくなってしまうためである。すなわち、キャッシュされたウェブページをカスタマー端末１００ａ及びエージェント端末１００ｂの双方に渡すことにより、同一の内容及びレイアウトのウェブページで作業を行えることを保証している。
【００３２】
以上の動作は、セッション中に作業が行われている所定のウェブページから他のウェブページ（ＵＲＬ）へ遷移した場合も同様である。また、エージェント側からＵＲＬを遷移した場合も同様であり、エージェント端末１００ｂが取得したウェブページのＵＲＬがカスタマー端末１００ａに通知され、共にキャッシュされたウェブページを取得する。
このセッションからエージェントが抜ける場合は、新規にキャッシュテーブル２１１を作成し、ＵＡＩテーブル２１２の当該エージェントのエントリ（図３の［０００２］）において、キャッシュテーブルポインタが新規に作成されたキャッシュテーブル２１１（図３のキャッシュテーブル＃２）を指すように書き換える。また、セッションオーナーであるカスタマーが抜ける場合は、新規にキャッシュテーブル２１１を作成し、上記と同様にＵＡＩテーブル２１２の当該エージェントのエントリにおいて、キャッシュテーブルポインタが各々のキャッシュテーブル２１１を指すように書き換える。つまり既存のキャッシュテーブル２１１はカスタマーが引き継ぎ、そこに保管されている認証情報が他人に用いられることはない。
【００３３】
ここで、上述したカスタマーとエージェントとによるセッションにおいて、カスタマーのみがアクセス権限を有するウェブページ（コンテンツ）のＵＲＬへ遷移しようとした場合について考える。
この場合、カスタマーが先にＵＲＬの遷移を行ったのであれば、カスタマー自身は当該ウェブページへのアクセス権限を有しているので、問題なくウェブページを取得できる。また、エージェントはコラボレーションサーバ２００にキャッシュされた当該ウェブページを取得することができるので、このウェブページに関してセッションを行うことが可能である。
【００３４】
しかしながら、エージェントが先にＵＲＬの遷移を行った場合、エージェントは当該ウェブページへのアクセス権限を有していないので、コラボレーションサーバ２００がウェブサーバ３００からウェブページを取得することができない。このため、このウェブページに関してセッションを行うことができないこととなる。
本実施の形態によるコラボレーションシステムは、このような場合に、コラボレーションサーバ２００がカスタマー端末１００ａから取得したカスタマーの認証情報を用いて、当該ウェブページを取得する。以下、具体的に説明する。
【００３５】
図４、５は、本実施の形態におけるコラボレーションサーバ２００の動作を説明するフローチャートである。
図４、５に示すように、コラボレーションサーバ２００のＨＴＴＰ送受信制御部２２０は、所定の端末１００からウェブページの取得リクエスト（ＨＴＴＰリクエスト）を受信すると（ステップ４０１）、まず当該取得リクエストがセッションオーナーから発行されたリクエストか否かを調べる（ステップ４０２）。そして、セッションオーナーからのリクエストである場合は次に、当該取得リクエストに認証情報（Authorization header）が付されているかどうかを調べる（ステップ４０３）。
【００３６】
セッションオーナーからの取得リクエストに認証情報が付されている場合、ＨＴＴＰ送受信制御部２２０は、その認証情報を記憶装置に保管し（ステップ４０４）、ＵＡＩテーブル２１２及びキャッシュテーブル２１１を参照して、当該取得リクエストにて指定されたＵＲＬが登録されているかどうかを調べる（ステップ４０５）。また、取得リクエストがセッションオーナーから発行されたものでない場合、及びセッションオーナーからの取得リクエストに認証情報が付されていない場合も、キャッシュテーブル２１１に、当該取得リクエストにて指定されたＵＲＬが登録されているかどうかを調べる（ステップ４０２、４０３、４０５）。そして、キャッシュテーブル２１１に該当ＵＲＬが登録されている場合、次に、ＨＴＴＰ送受信制御部２２０は、当該ＵＲＬに対応付けられてキャッシュされているＨＴＴＰレスポンスの内容がステータスコード４０１かどうか、すなわちアクセス権限がないことを示す内容かどうかを調べる（ステップ４０６）。
【００３７】
キャッシュされているＨＴＴＰレスポンスがステータスコード４０１でない場合、キャッシュの内容は取得リクエストにて要求されているウェブページである。したがって、ＨＴＴＰ送受信制御部２２０は、次に、当該取得リクエストがセッションオーナーから発行されたリクエストか否かを調べ、セッションオーナーからのリクエストであれば、当該ウェブページ（ＨＴＴＰレスポンス）を端末１００へ返す（ステップ４０７、４１０）。
取得リクエストがセッションオーナーから発行されたものでない場合、ＨＴＴＰ送受信制御部２２０は、次に、キャッシュされているＨＴＴＰレスポンスにWWW-Authenticateヘッダがあるかどうかを調べる（ステップ４０７、４０８）。ここでは、ステップ４０６で当該ＨＴＴＰレスポンスがステータスコード４０１でないことから当然に、WWW-Authenticateヘッダは存在しない。そこで、ＨＴＴＰ送受信制御部２２０は、当該ウェブページ（ＨＴＴＰレスポンス）を端末１００へ返す（ステップ４１０）。
【００３８】
ステップ４０５で、取得リクエストにて指定されたＵＲＬがキャッシュテーブル２１１に登録されていない場合、及びステップ４０６で、キャッシュされているＨＴＴＰレスポンスがステータスコード４０１であった場合は、取得リクエストにて要求されているウェブページがキャッシュされていないので、当該ウェブページをウェブサーバ３００から取得する処理（図５）に移行する。
ＨＴＴＰ送受信制御部２２０は、まずセッションオーナーの認証情報が記憶装置に保管されているかどうかを調べ、保管されている場合には、当該認証情報を端末１００からの取得リクエストに付加する（ステップ５０１、５０２）。そして、当該取得リクエストにて指定されたＵＲＬに対応するウェブサーバ３００に当該取得リクエストを送り（ステップ５０３）、当該ウェブサーバ３００からＨＴＴＰレスポンスを受信してキャッシュする（ステップ５０４、５０５）。このとき取得するＨＴＴＰレスポンスは、取得リクエストにて要求されるウェブページである場合と、取得リクエストが当該ウェブページへのアクセス権限に基づかないことを意味するステータスコード４０１である場合とがある。後者の場合、ＨＴＴＰレスポンスには当該ウェブページへのアクセス権限を示す認証情報の入力を要求するWWW-Authenticateヘッダが存在する。
【００３９】
この後、ＨＴＴＰ送受信制御部２２０は、当該取得リクエストがセッションオーナーから発行されたリクエストか否かを調べ、セッションオーナーからのリクエストであれば、ステップ５０５でキャッシュされたＨＴＴＰレスポンスを端末１００へ返す（図４、ステップ４０７、４１０）。
取得リクエストがセッションオーナーから発行されたものでない場合、ＨＴＴＰ送受信制御部２２０は、次に、キャッシュされているＨＴＴＰレスポンスにWWW-Authenticateヘッダがあるかどうかを調べる（ステップ４０７、４０８）。そして、WWW-Authenticateヘッダがない場合は、当該ＨＴＴＰレスポンスが当該取得リクエストにて要求されたウェブページであるので、当該ウェブページ（ＨＴＴＰレスポンス）を端末１００へ返す（ステップ４１０）。
一方、WWW-Authenticateヘッダがある場合は、当該ＨＴＴＰレスポンスはステータスコード４０１である。これに対し、セッションオーナーでないユーザは当該ウェブページへのアクセス権限を持たず、認証情報を返すこともできないので、認証情報の入力を要求するWWW-Authenticateヘッダを削除し（ステップ４０９）、ＨＴＴＰレスポンスを端末１００へ返す（ステップ４１０）。
【００４０】
以下、上記のように動作するコラボレーションサーバ２００の管理下で、上述したカスタマー（ＵＡＩ：［０００１］）とエージェント（ＵＡＩ：［０００２］）とによるコラボレーションのセッションにおいて、カスタマーのみがアクセス権限を有するウェブページに対する作業を行う場合の動作について詳細に説明する。
＜動作例１＞
まず、カスタマーが先にアクセス制御されたウェブページにアクセスする場合の動作について説明する。なお、ここでは、アクセス制御されたウェブページとして、/protected/foo.htmlと/protected/bar.htmlとにアクセスするが、これらのページには同一の認証情報（ユーザＩＤ及びパスワード）でアクセスできるものとする。
【００４１】
カスタマー端末１００ａの作業実行部１１０ａからコラボレーションサーバ２００へ、/protected/foo.htmlの取得リクエスト（GET /protected/foo.html）が送信されたものとする。この取得リクエストには認証情報であるAuthorization headerが付加されていない（アクセス権限のないアクセス要求）。この時点では、該当するウェブページはキャッシュされていないので、当該取得リクエストはコラボレーションサーバ２００からウェブサーバ３００へ送られる（図４、５、ステップ４０１〜４０５、５０１、５０３参照）。そして、取得リクエストに認証情報がないため、ウェブサーバ３００からコラボレーションサーバ２００へ、ステータスコード４０１のＨＴＴＰレスポンスが返される（ステップ５０４参照）。このＨＴＴＰレスポンスには、認証情報の入力を要求するWWW-Authenticateヘッダが付加されている。
このＨＴＴＰレスポンスは、コラボレーションサーバ２００の記憶装置にキャッシュされ、カスタマー端末１００ａに送られる（ステップ５０５、４０７、４１０参照）。
【００４２】
上記のＨＴＴＰレスポンスを受信したカスタマー端末１００ａの表示装置には、WWW-Authenticateヘッダに基づいてユーザＩＤ及びパスワードの入力を要求する入力フィールドが表示される。図６は、カスタマー端末１００ａにおける表示画面の例を示す図である。図６において、作業実行部１１０ａにて表示されたブラウザウィンドウ６０１に、入力フィールド６０２が表示されている。
カスタマーがユーザＩＤ及びパスワードを入力し、確定すると（ＯＫボタンを押すと）、このユーザＩＤ及びパスワードを含む認証情報（Authorization header）の付加された/protected/foo.htmlの取得リクエストがコラボレーションサーバ２００へ送られる（アクセス権限のあるアクセス要求）。
【００４３】
コラボレーションサーバ２００では、受信した取得リクエストに付加されている認証情報が抽出して記憶装置に保存される（ステップ４０１〜４０４参照）。そして、この取得リクエストに対して再度キャッシュの検索が行われるが、この時点では、先に受信したステータスコード４０１のＨＴＴＰレスポンスがキャッシュされているため、当該取得リクエストはコラボレーションサーバ２００からウェブサーバ３００へ送られる（ステップ４０５、４０６、５０１、５０３参照）。今回は、取得リクエストに認証情報があるため、ウェブサーバ３００からコラボレーションサーバ２００へ、所望のウェブページが返される（ステップ５０４参照）。
ここで取得されたウェブページは、コラボレーションサーバ２００の記憶装置にキャッシュされ、カスタマー端末１００ａに送られる（ステップ５０５、４０７、４１０参照）。
なお、認証情報のユーザＩＤ及びパスワードの一方または双方が間違っている場合は、再びステータスコード４０１のＨＴＴＰレスポンスが返されるので、ユーザＩＤ及びパスワードの入力から各動作をやり直す。
【００４４】
カスタマー端末１００ａが/protected/foo.htmlのウェブページを取得すると、通常のコラボレーションのセッションにおける動作として、カスタマー端末１００ａのコラボレーション制御部１２０ａからエージェント端末１００ｂへセッション対象であるＵＲＬが遷移したことが通知される。そして、エージェント端末１００ｂの作業実行部１１０ｂからコラボレーションサーバ２００へ、/protected/foo.htmlの取得リクエスト（GET /protected/foo.html）が送信される。この取得リクエストには認証情報であるAuthorization headerが付加されていないが、コラボレーションサーバ２００には、先にカスタマー端末１００ａの取得リクエストに応じて取得されたウェブページがキャッシュされているため、これがエージェント端末１００ｂに返送されることとなる（ステップ４０１〜４０３、４０５、４０６、４０７、４０８、４１０）。
以上のようにして、カスタマー端末１００ａ及びエージェント端末１００ｂがコラボレーションサーバ２００にキャッシュされている同一のウェブページを取得したので、このウェブページに対するセッションが可能となる。
【００４５】
また、エージェント端末１００ｂの作業実行部１１０ｂからコラボレーションサーバ２００へ、/protected/bar.htmlの取得リクエスト（GET /protected/bar.html）が送信されたものとする。/protected/bar.htmlは、/protected/foo.htmlと同一の認証情報でアクセスできるウェブページである。この時点では、該当するウェブページはキャッシュされていないので、ウェブサーバ３００から取得されることとなる。
エージェント端末１００ｂから送られた取得リクエストには、protected/bar.htmlにアクセスするための認証情報であるAuthorization headerは付加されていないが、コラボレーションサーバ２００には、先にカスタマー端末１００ａの取得リクエストから抽出したAuthorization headerが保存されている（図３参照）ので、これが取得リクエストに付加されて、コラボレーションサーバ２００からウェブサーバ３００へ送られる（ステップ４０１〜４０３、４０５、５０１〜５０３参照）。
この場合、取得リクエストに認証情報があるため、ウェブサーバ３００からコラボレーションサーバ２００へ、所望のウェブページが返される（ステップ５０４参照）。そして、当該ウェブページは、コラボレーションサーバ２００の記憶装置にキャッシュされ、エージェント端末１００ｂに送られる（ステップ５０５、４０７、４０８、４１０参照）。
【００４６】
エージェント端末１００ｂが/protected/bar.htmlのウェブページを取得すると、通常のコラボレーションのセッションにおける動作として、エージェント端末１００ｂのコラボレーション制御部１２０ｂからカスタマー端末１００ａへセッション対象であるＵＲＬが遷移したことが通知される。そして、上述したエージェント端末１００ｂが/protected/foo.htmlのウェブページを取得する動作と同様の動作にて、/protected/bar.htmlのウェブページがカスタマー端末１００ａにも取得される。
以上のようにして、カスタマー端末１００ａ及びエージェント端末１００ｂがコラボレーションサーバ２００にキャッシュされている同一のウェブページを取得したので、このウェブページに対するセッションが可能となる。
【００４７】
＜動作例２＞
次に、エージェントが先にアクセス制御されたウェブページにアクセスする場合の動作について説明する。
エージェント端末１００ｂの作業実行部１１０ｂからコラボレーションサーバ２００へ、/protected/foo.htmlの取得リクエスト（GET /protected/foo.html）が送信されたものとする。この取得リクエストには認証情報であるAuthorization headerが付加されていない。この時点では、該当するウェブページはキャッシュされていないので、当該取得リクエストはコラボレーションサーバ２００からウェブサーバ３００へ送られる（ステップ４０１〜４０５、５０１、５０３参照）。そして、取得リクエストに認証情報がないため、ウェブサーバ３００からコラボレーションサーバ２００へ、ステータスコード４０１のＨＴＴＰレスポンスが返される（ステップ５０４参照）。このＨＴＴＰレスポンスには、認証情報の入力を要求するWWW-Authenticateヘッダが付加されている。
【００４８】
このＨＴＴＰレスポンスは、コラボレーションサーバ２００の記憶装置にキャッシュされ、エージェント端末１００ｂに送られる。ただし、エージェント端末１００ｂはセッションオーナーではなく、認証情報を入力することができないため、WWW-Authenticateヘッダは削除される（ステップ５０５、４０７〜４１０参照）。
上記のＨＴＴＰレスポンスを受信したエージェント端末１００ｂの表示装置には、アクセス権限が無いことを通知する画面が表示される。図７は、エージェント端末１００ｂにおける表示画面の例を示す図である。図７において、作業実行部１１０ｂにて表示されたブラウザウィンドウ７０１には、入力フィールドが表示されておらず、アクセス制限されていることを示すメッセージのみが表示されている。
【００４９】
エージェント端末１００ｂがステータスコード４０１のＨＴＴＰレスポンスを受信すると、通常のコラボレーションのセッションにおける動作として、エージェント端末１００ｂのコラボレーション制御部１２０ｂからカスタマー端末１００ａへセッション対象であるＵＲＬが遷移したことが通知される。そして、カスタマー端末１００ａの作業実行部１１０ａからコラボレーションサーバ２００へ、/protected/foo.htmlの取得リクエスト（GET /protected/foo.html）が送信される。この取得リクエストには認証情報であるAuthorization headerが付加されていない（ステップ４０１〜４０４参照）。
【００５０】
コラボレーションサーバ２００では、この取得リクエストに対して再度キャッシュの検索が行われるが、この時点では、先に受信したステータスコード４０１のＨＴＴＰレスポンスがキャッシュされているため、当該取得リクエストはコラボレーションサーバ２００からウェブサーバ３００へ送られる（ステップ４０５、４０６、５０１、５０３参照）。そして、取得リクエストに認証情報がないため、ウェブサーバ３００からコラボレーションサーバ２００へ、ステータスコード４０１のＨＴＴＰレスポンスが返される（ステップ５０４参照）。このＨＴＴＰレスポンスには、認証情報の入力を要求するWWW-Authenticateヘッダが付加されている。
このＨＴＴＰレスポンスは、コラボレーションサーバ２００の記憶装置にキャッシュされ、カスタマー端末１００ａに送られる（ステップ５０５、４０７、４１０参照）。これにより、カスタマー端末１００ａの表示装置には、図６に示した、ユーザＩＤ及びパスワードの入力を要求する画面が表示される。そして、このＨＴＴＰレスポンスに応じて、カスタマー端末１００ａからコラボレーションサーバ２００へ、カスタマーのユーザＩＤ及びパスワードを含む認証情報（Authorization header）の付加された/protected/foo.htmlの取得リクエストが送られる。
【００５１】
コラボレーションサーバ２００では、受信した取得リクエストに付加されている認証情報が抽出して記憶装置に保存される（ステップ４０１〜４０４参照）。そして、この取得リクエストに対して再度キャッシュの検索が行われるが、この時点では、先に受信したステータスコード４０１のＨＴＴＰレスポンスがキャッシュされているため、当該取得リクエストはコラボレーションサーバ２００からウェブサーバ３００へ送られる（ステップ４０５、４０６、５０１、５０３参照）。今回は、取得リクエストに認証情報があるため、ウェブサーバ３００からコラボレーションサーバ２００へ、所望のウェブページが返される（ステップ５０４参照）。
ここで取得されたウェブページは、コラボレーションサーバ２００の記憶装置にキャッシュされ、カスタマー端末１００ａに送られる（ステップ５０５、４０７、４１０参照）。
なお、認証情報のユーザＩＤ及びパスワードの一方または双方が間違っている場合は、再びステータスコード４０１のＨＴＴＰレスポンスが返されるので、ユーザＩＤ及びパスワードの入力から各動作をやり直す。
【００５２】
このとき、エージェント端末１００ｂには既に/protected/foo.htmlというＵＲＬのＨＴＴＰレスポンスが受信されており、各端末１００のコラボレーション制御部１２０はＵＲＬの同期が取れたと認識するが、実際には、エージェント端末１００ｂが受信したＨＴＴＰレスポンスはステータスコード４０１であり、目的のウェブページではない。したがって、このままではセッションを行うことができない。そこで、エージェント端末１００ｂから改めて当該ウェブページの取得リクエストを送信し、コラボレーションサーバ２００にキャッシュされているウェブページを取得して、同期を取ることが必要である。
また、以上のプロセスで、コラボレーションサーバ２００にはカスタマーの認証情報が保存されたので、これ以降、当該認証情報にてアクセス可能なウェブページに対しては、エージェント端末１００ｂが先に取得リクエストを送信しても取得することが可能である。
なお、コラボレーションサーバ２００において一度認証情報を保存した後は、カスタマー端末１００ａから再度/protected/foo.htmlにアクセスしたり、/protected/bar.htmlにアクセスしたりする場合にも、保存されている認証情報を用いることができるので、カスタマーがユーザＩＤ及びパスワードを改めて入力する必要はない。
【００５３】
以上のように、本実施の形態によれば、セッションオーナーのみがアクセス権限を有するリソースに対して、当該セッションオーナーがアクセスした際の認証情報をコラボレーションサーバ２００に保存しておくことにより、当該セッション中においては、当該セッションオーナーの認証情報すなわちアクセス権限を用いて、当該セッションに参加している他のユーザからのアクセスが可能となる（動作例１における/protected/bar.htmlの場合）。
また、そのようなアクセス制御されたリソースに対し、セッションオーナーがアクセスするより先に他のユーザがアクセスしようとした場合でも、コラボレーションにおけるＵＲＬの同期を取るために、セッションオーナーが直ちにアクセスすることとなるので、再度アクセス要求を行うことで、当該リソースを取得することができる（動作例２）。これはすなわち、セッションオーナーに当該リソースにアクセスさせることにより、当該セッションオーナーのアクセス権限を利用することを意味する。
【００５４】
なお、上記の動作例において、/protected/foo.htmlと/protected/bar.htmlとを同一の認証情報でアクセス可能として説明した。これに対し、セッションにおいて、複数のアクセス制御されたディレクトリに存在するウェブページ/protected1/foo.htmlと/protected2/bar.htmlとにアクセスしようとする場合、アクセス制御は一般にディレクトリ単位でなされるため、これらにアクセスするために異なるユーザＩＤまたはパスワードを要することが考えられる。この場合、各ウェブページに対して、セッションオーナーによるアクセスを待ってリソースを取得することとなる。そして、どの認証情報がどのディレクトリに対するものかを管理するために、コラボレーションサーバ２００において認証情報と当該認証情報でアクセス可能となるディレクトリとを対応付けたテーブル等を用意し管理することが必要となる。
【００５５】
上述したように動作例２において、セッションオーナーがリソースを取得した時点で、セッションオーナーの端末１００と他のユーザの端末１００とでは、ＵＲＬの同期は取られているものの表示画面の内容が異なっている（セッションオーナーの端末１００には目的のウェブページが表示され、他のユーザの端末１００にはステータスコード４０１に基づくメッセージ画面（図７参照）が表示される）。通常のコラボレーションにて提供される、ＵＲＬの同期を取る動作では、既にＵＲＬが共通であるために他のユーザの端末１００に対して自動的に目的のウェブページを再度取得させることができないため、上述した本実施の形態では、他のユーザの端末１００（エージェント端末１００ｂ）から改めて当該ウェブページに対する取得リクエストが送信された場合に、ウェブページの同期が取られることとした。
しかしながら、処理が複雑になるが、コラボレーション制御部１２０の機能等を拡張し、各端末１００で表示されている画面のレイアウト等を比較し、一致していない場合にセッションオーナー以外の端末１００に対して再度ウェブページの取得リクエストを送信させるように制御すれば、自動的に画面の同期を取ることも可能である。
【００５６】
なお、上記の説明では、コラボレーションのセッションを行うユーザ（セッションオーナー）がアクセス権限を有するものとして説明したが、セッションの参加者は、ＵＡＩテーブル２１２により、ユーザが使用する端末１００で特定されるので、各セッションにおいてはアクセス権限の所在が端末１００（セッションオーナーの端末）にあると認定することもできる。すなわちこの場合、コラボレーションサーバ２００は、所定のリソースに対してアクセス権限を持たない端末１００からアクセス要求があった場合に、他の端末１００が持つアクセス権限を用いてリソースを取得し、各端末１００に返送することとなる。
【００５７】
以上説明したように、本発明によれば、コラボレーションシステムにおいて、作業を行うユーザのうちの特定のユーザのみがアクセス権限を有するリソースに対して、一定条件下で他のユーザのアクセスを認めるアクセス管理を実現することができる。
【図面の簡単な説明】
【図１】 本実施の形態によるコラボレーションシステムを適用するネットワークシステムの構成例を説明する図である。
【図２】 図１に示したネットワークシステムを用いて構築される本実施の形態によるコラボレーションシステムの全体構成を示す図である。
【図３】 本実施の形態におけるセッション管理部によるセッションの管理に利用されるキャッシュテーブル及びＵＡＩテーブルの構成を示す図である。
【図４】 本実施の形態におけるコラボレーションサーバの動作を説明するフローチャートであり、取得リクエストの受け付け時及びＨＴＴＰレスポンスの返送時の動作を示すフローチャートである。
【図５】 本実施の形態におけるコラボレーションサーバの動作を説明するフローチャートであり、ウェブサーバにアクセスする際の動作を説明するフローチャートである。
【図６】 ステータスコード４０１を受信した際のカスタマー端末における表示画面の例を示す図である。
【図７】 ステータスコード４０１を受信した際のエージェント端末における表示画面の例を示す図である。

Claims (12)

1. ネットワークを介してデータを交換することにより行われる複数の端末による共同作業を支援するコラボレーションサーバにおいて、
   前記端末からの要求に応じてリソースを取得し、要求元の端末に返送するリソース取得手段と、
   前記端末による共同作業のセッションを管理するセッション管理手段とを備え、
   前記リソース取得手段は、所定の前記セッションにおいて、当該セッションを開始させたユーザであるセッションオーナーがアクセス権限を持つリソースに対して、当該セッションに参加する当該セッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、当該セッションオーナーのアクセス権限に基づいて当該リソースを取得することを特徴とするコラボレーションサーバ。
2. 前記リソース取得手段は、前記セッションオーナーの端末からの前記リソースに対するアクセス要求から取得された前記アクセス権限を示す情報を、前記セッションオーナー以外のユーザの端末からの取得リクエストに付加することにより、当該リソースを取得することを特徴とする請求項１に記載のコラボレーションサーバ。
3. 前記リソース取得手段は、前記リソースに対して前記セッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、当該セッションオーナーの端末に当該リソースへのアクセス要求を行わせ、当該リソースを取得することを特徴とする請求項２に記載のコラボレーションサーバ。
4. ネットワークを介してデータを交換することにより行われる複数の端末による共同作業を支援するコラボレーションサーバにおけるセッション管理方法であって、
   前記端末からの要求に応じてリソースを取得し、要求元の端末に返送するステップと、
   前記端末による共同作業のセッションを管理するステップと、
   所定の前記セッションにおいて、当該セッションを開始させたユーザであるセッションオーナーがアクセス権限を持つリソースに対して、当該セッションに参加する当該セッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、当該セッションオーナーのアクセス権限に基づいて当該リソースを取得するステップと
   を有することを特徴とする前記方法。
5. 前記リソースを取得するステップは、前記セッションオーナーの端末からの前記リソースに対するアクセス要求から取得された前記アクセス権限を示す情報を、前記セッションオーナー以外のユーザの端末からの取得リクエストに付加することにより、当該リソースを取得することを特徴とする請求項４に記載の方法。
6. 前記リソースを取得するステップは、前記リソースに対して前記セッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、当該セッションオーナーの端末に当該リソースへのアクセス要求を行わせ、当該リソースを取得することを特徴とする請求項５に記載の方法。
7. ネットワークを介してデータを交換することにより行われる複数の端末による共同作業を支援するようにコンピュータを動作させるためのプログラムであって、前記プログラムはコンピュータを
   前記端末からの要求に応じてリソースを取得し、要求元の端末に返送するリソース取得手段と、
   前記端末による共同作業のセッションを管理するセッション管理手段として機能させるものであり、さらに
   前記リソース取得手段は、所定の前記セッションにおいて、当該セッションを開始させたユーザであるセッションオーナーがアクセス権限を持つリソースに対して、当該セッションに参加する当該セッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、当該セッションオーナーのアクセス権限に基づいて当該リソースを取得するようにコンピュータを機能させることを特徴とするプログラム。
8. 前記リソース取得手段は、前記セッションオーナーの端末からの前記リソースに対するアクセス要求から取得された前記アクセス権限を示す情報を、前記セッションオーナー以外のユーザの端末からの取得リクエストに付加することにより、当該リソースを取得するようにコンピュータを機能させることを特徴とする請求項７に記載のプログラム。
9. 前記リソース取得手段は、前記リソースに対して前記セッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、当該セッションオーナーの端末に当該リソースへのアクセス要求を行わせ、当該リソースを取得するようにコンピュータを機能させることを特徴とする請求項８に記載のプログラム。
10. ネットワークを介してデータを交換し共同作業を行う複数の端末と、
    前記複数の端末に接続され、前記共同作業を支援するコラボレーションサーバと、
    を有するコラボレーションシステムにおいて、前記コラボレーションサーバは、
    前記端末からの要求に応じてリソースを取得し、要求元の端末に返送するリソース取得手段と、
    前記端末による共同作業のセッションを管理するセッション管理手段とを備え、
    前記リソース取得手段は、所定の前記セッションにおいて、当該セッションを開始させたユーザであるセッションオーナーがアクセス権限を持つリソースに対して、当該セッションに参加する当該セッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、当該セッションオーナーのアクセス権限に基づいて当該リソースを取得することを特徴とするコラボレーションシステム。
11. 前記リソース取得手段は、前記セッションオーナーの端末からの前記リソースに対するアクセス要求から取得された前記アクセス権限を示す情報を、前記セッションオーナー以外のユーザの端末からの取得リクエストに付加することにより、当該リソースを取得することを特徴とする請求項１０に記載のコラボレーションシステム。
12. 前記リソース取得手段は、前記リソースに対して前記セッションオーナー以外のユーザの端末から取得リクエストを受け取った場合に、当該セッションオーナーの端末に当該リソースへのアクセス要求を行わせ、当該リソースを取得することを特徴とする請求項１１に記載のコラボレーションシステム。

Images