(57)【要約】　　　（修正有）【課題】シン−クライアント／サーバーのローミングの適用【解決手段】シン−クライアント／サーバーのためのマルチアプリケーションサーバー・アーキテクチャー・モデルは、シン−クライアント機器をもつユーザーが透過的な作業環境で広域エリア・ネットワーク周辺をローミングすることを可能にする目的で提供される。このシステムはディスプレー・プロトコル、マルチアプリケーションサーバー・ネットワーク、アプリケーションサーバー・ディスカバリプロトコルおよび分配ファイルシステムといった主要な構成要素を有する。アプリケーションサーバー・ディスカバリプロトコルはシン−クライアント機器が接続するために最適なアプリケーションサーバーを判別する。分配ファイルシステムは、迅速なサービスを効果的に行うためのアクセス、場所および移動の透過性をもつ作業環境を達成させるデータ・マイニング・ベースのインテリジェント・プリフェッチング機能を有する。【選択図】図２
2004094411.tif 000002
【特許請求の範囲】
【請求項１】
広域エリアネットワーク内でシン−クライアントのローミング方法であって、
シン−クライアント機器をマルチアプリケーションサーバー・ネットワークに接続するステップと、
前記マルチアプリケーションサーバー・ネットワーク内で適切なアプリケーションサーバーを判別するステップと、
前記シン−クライアント機器を前記アプリケーションサーバーに接続するよう導くステップと、
前記の適切なアプリケーションサーバーにユーザーのデータをプリフェッチングすることで、透過的な作業環境を提供し、ユーザーが前記マルチアプリケーションサーバー・ネットワーク内で接続するアプリケーションサーバーがどのようなものであっても実質的に同一の作業環境を体感するようにするステップと
を有する。
【請求項２】
請求項１の方法において、
前記の適切なアプリケーションサーバーを判別するステップはアプリケーションサーバーへのマルチキャスト・ブロードキャストを実行する前記シン−クライアント機器によって達成されるものである。
【請求項３】
請求項１の方法において、
前記の適切なアプリケーションサーバーを判別するステップは、
前記シン−クライアント機器は適切なアプリケーションサーバーを求めてユニキャスト・ルックアップを参照先変更サーバーに発するステップと、
前記参照先変更サーバーは前記の適切なアプリケーションサーバーを判別するステップ
からなる。
【請求項４】
請求項３の方法において、
前記参照先変更サーバーは前記シン−クライアント機器の場所に応じて前記の適切なアプリケーションサーバーを判別するものである。
【請求項５】
請求項３の方法において、
前記参照先変更サーバーはマルチアプリケーションサーバー・ネットワーク内の各アプリケーションサーバーの配置および状態に応じて前記の適切なアプリケーションサーバーを判別するものである。
【請求項６】
請求項１の方法において、
プリフェッチングのステップはインテリジェント・プリフェッチングのステップを有する。
【請求項７】
請求項１の方法において、
前記プリフェッチングのステップはアポインテド・プリフェッチングのステップを有する。
【請求項８】
請求項６の方法において、
前記インテリジェント・プリフェッチングのステップは優先プリフェッチング方法に基づいて達成される。
【請求項９】
請求項６の方法において、
前記インテリジェント・プリフェッチングのステップはユーザーのアクセスのパターンに基づいて達成される。
【請求項１０】
請求項１の方法において、
前記シン−クライアント機器は、Ｘターミナル、ＳＬＩＭコンソール、ＩＣＡのウインドウズ（登録商標）ベース・ターミナル、パーソナル・コンピューター、ワークステーション、テレビ受像機の上部ボックス、携帯情報端末（ＰＤＡ）または携帯電話である。
【請求項１１】
マルチアプリケーションサーバー・シン−クライアント／サーバーシステムであって、
マルチアプリケーションサーバー・ネットワーク内でシン−クライアント機器が適切なアプリケーションサーバーを判別できるようにするアプリケーションサーバー・ディスカバリプロトコルと、
前記シン−クライアント機器と前記アプリケーションサーバーが通信を行うようにするディスプレープロトコルと、
透過的な作業環境を提供し、ユーザーがマルチアプリケーションサーバー・ネットワーク内でいかなるアプリケーションに接続していても実質的に同一の作業環境を体感することを可能にする分配ファイルシステムと
を有する。
【請求項１２】
請求項１１のシステムにおいて、
前記アプリケーションサーバー・ディスカバリプロトコルはマルチキャスト・ディスカバリプロトコルであり、前記シン−クライアント機器はアプリケーションサーバーを求めてマルチキャスト・ブロードキャストを行うものである。
【請求項１３】
請求項１１のシステムにおいて、
前記アプリケーションサーバー・ディスカバリプロトコルはユニキャスト・ディスカバリプロトコルであり、前記シン−クライアント機器から発令されたアプリケーションサーバーのルックアップが参照先変更サーバーに送信されるものである。
【請求項１４】
請求項１３のシステムにおいて、
前記参照先変更サーバーは前記マルチアプリケーションサーバー・ネットワーク内の各アプリケーションサーバーに関する情報を収容するデータベースを備える。
【請求項１５】
請求項１３のシステムにおいて、
前記参照先変更サーバーは前記シン−クライアント機器の設置場所に応じて前記の適切なアプリケーションサーバーを判別する。
【請求項１６】
請求項１３のシステムにおいて、
前記参照先変更サーバーは前記マルチアプリケーションサーバー・ネットワーク内の各アプリケーションサーバーの配置および状態に応じて前記の適切なアプリケーションサーバーを判別し、前記シン−クライアント機器を前記の適切なアプリケーションサーバーに接続するよう導く。
【請求項１７】
請求項１１のシステムにおいて、
分配ファイルシステムはプリフェッチング機能を有する。
【請求項１８】
請求項１７のシステムにおいて、
前記プリフェッチング機能はインテリジェント・プリフェッチング機能を有する。
【請求項１９】
請求項１７のシステムにおいて、
前記プリフェッチング機能はアポインテド・プリフェッチング機能を有する。
【請求項２０】
請求項１８のシステムにおいて、
前記インテリジェント・プリフェッチング機能は優先プリフェッチング機能を有する。
【請求項２１】
請求項１８のシステムにおいて、
前記インテリジェント・プリフェッチング機能はアクセスパターンベース・プリフェッチング機能を有する。
【請求項２２】
請求項２０のシステムにおいて、
前記優先プリフェッチング機能はファイルのアクセス頻度と容量に応じてプリフェッチングの優先順位を決定する。
【請求項２３】
請求項２１のシステムにおいて、
前記アクセスパターンベース・プリフェッチング機能は以前のファイルのアクセスパターンに応じて次のファイルのアクセスを予測する。
【請求項２４】
請求項１９のシステムにおいて、
前記アポインテド・プリフェッチング機能は送信されるファイルのうち少なくとも１つのファイルを特定する。
【請求項２５】
請求項１９のシステムにおいて、
前記アポインテド・プリフェッチング機能は仕事を特定し、その仕事が遂行される持続時間と場所およびその仕事が必要とする少なくとも１つのファイルを特定する。
【請求項２６】
請求項１１のシステムにおいて、
前記シン−クライアント機器は、Ｘターミナル、ＳＬＩＭコンソール、ＩＣＡのウインドウズ（登録商標）ベース・ターミナル、パーソナル・コンピューター、ワークステーション、テレビ受像機の上部ボックス、携帯情報端末（ＰＤＡ）または携帯電話である。
【請求項２７】
請求項１１のシステムにおいて、
前記ディスプレープロトコルはＸプロトコル、ＩＣＡプロトコル、リモートデスクトッププロトコルまたはＳＬＩＭプロトコルである。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、シン−クライアント（Ｔｈｉｎ−Ｃｌｉｅｎｔ：　”細いクライアント”）／サーバーのアーキテクチャーに関し、具体的にはシン−クライアント／サーバー機器のユーザーが透過的な作業環境で広域ネットワーク周辺をローミングすることが可能な、シン−クライアント／サーバーにおけるマルチアプリケーションサーバーのアーキテクチャーに関するものである。
【０００２】
【従来の技術】
シン−クライアント／サーバーのコンピューターモデルは、それが低コストであること、サーバー側で実行されるアプリケーション、いわゆるサーバーベースのコンピューティングが急激に進歩されることから近年急速にその利用が増大している。サーバー・ベース・コンピューティングによって、企業は各デスクトップ上でなくサーバー・インフラにおいてアプリケーション管理を行うことなので、それらのアプリケーションの管理をより一層行うことができる。マルチユーザーシン−クライアント／サーバーのコンピューティングモデルはこれをもう一段階進めてアプリケーション実行をひとつのサーバーのみに託すものである。全てのアプリケーションとデータの展開、管理およびサポートはこのサーバーで行われる。従ってクライアント機器はマウスやキーボードからのインプットを単に傍受し、サーバーにそのインプットを送り、サーバーから返ってくる表示を待つだけでよい。
【０００３】
図１に示すように、従来のシン−クライアント／サーバーコンピューティングモデルにおいて、１又は２以上の複数のシン−クライアント機器１ａがアプリケーションサーバー１ｂに接続されている。使用されるシン−クライアント機器の種類や、そのシン−クライアント機器の設置場所にかかわらず、つまりこれらシン−クライアント機器がアプリケーションサーバーの属するまさにそのローカルエリアネットワークに接続されている限り、その限定される地域における透過的な作業環境がユーザーに与えられる。
【０００４】
ディスプレープロトコルがシン−クライアント機器とアプリケーションサーバー間の通信のため確立される。このディスプレープロトコルは特定のソフトウェアＡＰＩがバンド幅要件を減らすのに最適化されているもので、例えばＸプロトコル、インディペンデントコンピューティングアーキテクチャ（ＩＣＡ）プロトコル、リモートデスクトッププロトコル（ＲＤＰ）や無国籍低水準インターフェースマシン（ＳＬＩＭ）プロトコルがある。
【０００５】
シン−クライアント機器はマウスクリックやキーボードの形でユーザーからインプットを収集し、これをアプリケーションサーバーに送信して処理させ、アプリケーションサーバーからのレスポンスとしてスクリーン表示のアップデートを得る。
【０００６】
全てのアプリケーションのインストールおよび実行がアプリケーションサーバーにて行われることから集中保守環境が提供される。企業の情報システム部門はデスクトップやＰＣの何れにも”タッチする”ことなく即時にアプリケーションを展開、アップデートをすることができ、アプリケーションのアップデートや展開のコストを劇的に減らすことができる。また、ユーザーは限定された地域のネットワーク内でアプリケーションやデータにアクセスすることができるので、その生産力は向上し、また、全てのデータがアプリケーションサーバーに保守されているのでセキュリティも強化される。更に、シン−クライアント／サーバーコンピューティングモデルはアプリケーションサーバー上のコンピューティング資源やメモリー資源の共有性を高める。
【０００７】
シン−クライアント機器は低コスト、ディスクレスのコンピューターのＲＯＭにディスプレープロトコルを組むことで実現できる。それらはキーボード、モニター、シリアルインターフェース又はネットワークインターフェース、高速シリアルポートおよび双方向性パラレルポートのようなハードウェア部品のみを必要とする。メーカーが独自に開発したシン−クライアント機器の中にはＸターミナル、ＳＬＩＭコンソール、ＩＣＡのウインドウズ（登録商標）ベースのターミナル等が挙げられる。ディスプレープロトコルをサポートする適切なソフトウェアをインストールすることによって通常のパーソナルコンピューター、ワークステーション、テレビ受像機の上部ボックス、ＰＤＡ（携帯情報端末）や携帯電話もまたシン−クライアント機器として使用することができる。
【０００８】
【発明が解決しようとする課題】
ところで、従来のシン−クライアント／サーバーモデルは各クライアント機器が常に同一アプリケーションサーバーに接続する単一アプリケーションサーバーネットワークを想定するため使用が限られている。ユーザーのデータおよびアプリケーションソフトウェアが全て同一の単一アプリケーションサーバーに保管されているため、ユーザーは、該アプリケーションサーバーがユーザーに透過的な作業環境を提供する要件を満たす際にリンクする限定地域（ローカルエリアネットワーク、ＬＡＮ）内でしかローミングできない。
【０００９】
各シン−クライアント機器が常に単一アプリケーションサーバーと接続している場合のみ、ユーザーはその所有権を主張できるファイルおよびアプリケーションに透過的アクセスをすることができる。更に、レスポンス時間はネットワークのバンド帯域およびアプリケーションサーバーの負荷によって決定されるので、望ましいレスポンス時間はシン−クライアント機器がアプリケーションサーバーと同一のローカルエリアネットワークで接続している時のみ実現する。
【００１０】
従来のシン−クライアント／サーバーシステムの欠点および不便性はユーザーのデータが単一のアプリケーションサーバーに保管されるという制限にある。ユーザーはアプリケーションサーバーがリンクするローカルエリアネットワークから離れる際、旅行する場所にあるアプリケーションサーバーを指定する必要がある。これはユーザーにとって不慣れなある特定の環境設定を意味する可能性があり、更に、従来の方法によると、ユーザーの所有権を主張できる全てのデータを指定アプリケーションサーバーに送信する必要があり、それは各アプリケーションサーバーに大量の記憶容量を要求することにつながるとともに、データ送信中における莫大なバンド帯域を使用することになる。
【００１１】
多国籍企業に勤めるユーザーを例にとる。ユーザーがカリフォルニアにある自分の事務所から日本に出張する場合、従来の方法では問題が生じる。もしユーザーがカリフォルニアにあるアプリケーションサーバーに日本から接続しようとしたならばおそらくレスポンス時間のあまりの長さにとても耐えられないであろう。
【００１２】
また別の状況として、企業あるいは機関の中には各ユーザーのデータおよびアプリケーションソフトウェアを全てのアプリケーションサーバーに複製することを試みるかもしれない。しかし、ユーザーのデータを完全に複製することは莫大な費用がかかる。従業員１００００名の企業の場合、各個人のディスク割り当て量を１００メガバイトとすると、ユーザーのデータを完全複製するためには各アプリケーションサーバーに１００００名掛ける１００メガバイトでなんと１０００ギガバイトのディスク記憶量を配置する必要がある。
【００１３】
この莫大なディスクスペース要件に加え、ユーザーのデータを同時発生させることはネットワークのバンド帯の多くを消費する可能性がある。例えば、１０メガバイトのファイルをアップデートするためには１００００名掛ける１０メガバイトで１００ギガバイトのデータを全アプリケーションサーバー内に転送することになる（これはいわゆるリード・ワン・ライト・オールのスキームを使って行われる）。
【００１４】
なお、アプリケーションソフトウェアは全てのアプリケーションサーバーに完全に複製されていると推定されるので、上記例には含まれない。もし必要な場合には、これはよく起こりうることだが、あらかじめアプリケーションソフトウェアを適切にインストール、セットアップしておかなければならない。これは上記と同様の問題を生じさせることになる。
従って、従来のシン−クライアント／サーバーの欠点を克服する必要性がある。
【００１５】
【課題を解決するための手段】
マルチアプリケーションサーバーシン−クライアント／サーバー（ＭＡＳ　ＴＣ／Ｓ）と呼ばれる新規性のあるシン−クライアント／サーバーコンピューティングモデルが本発明において開示される。ＭＡＳ・ＴＣ／Ｓシステムによって、シン−クライアント機器が広域エリアネットワーク（ＷＡＮ）をローミングする際に透過的作業環境が提供される。本発明のＭＡＳ・ＴＣ／Ｓシステムは、多国籍企業のＯＡおよび新規インターネットサービス等広範にわたるアプリケーションに適用することが可能である。
【００１６】
ＭＡＳ・ＴＣ／Ｓシステムは、例えばディスプレープロトコル、マルチアプリケーションサーバーネットワーク、アプリケーションサーバー・ディスカバリプロトコルおよび分配ファイルシステム等様々な主要構成要素をもつ。ディスプレープロトコルは、Ｘ、ＩＣＡ、ＲＤＰおよびＳＬＩＭ等、従来からのＬＡＮベースのシン−クライアント／サーバーアーキテクチャにおいて使用される標準プロトコルに従うものである。アプリケーションサーバー・ディスカバリプロトコルは、シン−クライアント機器がその接続に最適なアプリケーションサーバーを判別できるようにするものである。分配ファイルシステムは従来の分配ファイルシステムの機能性を多少強化したもので、例えば、インテリジェント・プリフェッチング構造およびアポインテド・プリフェッチング構造等が挙げられる。
【００１７】
実施結果によると、本発明のＭＡＳ・ＴＣ／Ｓシステムによって広域エリアネットワークＷＡＮにおけるサービス用移動体アプリケーションの実用的インフラが提供される。
本発明の利点および精神は、以下の発明と図面の詳細な説明により更に理解される。
【００１８】
【発明の実施の形態】
透過的な作業環境
配置されたシステムはその構成要素がユーザーから隠されている場合、通常透過的とみなされ、そのシステム全体は独立した要素の集まりというよりもむしろ全体としてとらえられる。本発明のＭＡＳ・ＴＣ／Ｓシステムは透過的な作業環境を提供するので、ユーザーはマルチアプリケーションサーバー・ネットワーク内でいかなるアプリケーションに接続していても実質的に同一の作業環境を体感することになる。すなわち、ユーザーは広域エリアネットワーク内でローミングする際にどのアプリケーションサーバーに接続しているかを認識しない。ユーザーはマルチアプリケーションサーバー・ネットワークへの接続を様々な場所から試みる場合でも実質的に同一の作業環境を体感する。
【００１９】
ＭＡＳ・ＴＣ／Ｓシステムの透過的な作業環境は主として、ユーザーのデータの一部（必ずしも全てのデータでなくてもよい）を、好ましくはユーザーから最も近い場所にある適切なアプリケーションサーバーにプリフェッチングすることで達成される。ＭＡＳ・ＴＣ／Ｓシステムは、ユーザーがマルチアプリケーションサーバー・ネットワーク内で接続するアプリケーションサーバーがどのようなものでも実質的には同じオペレーション・インターフェースをもつ透過的な作業環境を提供することが望まれる。例えばデスクトップ・オペレーション・ウインドウやアプリケーション・ソフトウェアの好ましい設定等、ユーザー側のオペレーション・インターフェースは実質的に同一に保持され、ユーザーが使い慣れている作業環境を提供する。ただし、例えば現在どのアプリケーションサーバーがユーザー側のオペレーション・インターフェースに接続されているかを示す等、インターフェース上に現出するわずかな相違は、以下の透過的な作業環境の定義を逸脱することはない。
【００２０】
一般的に、透過性は以下のような形をとる。
アクセス透過性は、同一の操作により地元および遠隔にある情報資源にアクセスすることを可能にする。
場所（ロケーション）透過性は、情報資源が存在する場所を知らなくてもその情報資源にアクセスすることを可能にする。
移動性（モバイル）透過性は、広域エリアネットワーク内で情報資源とクライアントの移動をユーザー側の操作に影響を与えずに行うことを可能にする。
【００２１】
本発明では、ユーザーはＷＡＮやＬＡＮ内のさまざまな場所から同一のアカウントとパスワードを使用してシステムにログオンすることができ、手動による環境設定や変換を一切行わずに、実質的に同一のファイル、アプリケーションおよびそれらの好ましい設定、さらにデスクトップ作業インターフェースを使って作業することができるが、これを透過的な作業環境を有するという。
【００２２】
ＬＡＮ内で透過的な作業環境を保持できるシステムの例としてはＳｕｎ社のＮＦＡ＋ＮＩＳ、Ｎｏｖｅｌｌ社のＮｅｔｗａｒｅおよびＭｉｃｒｏｓｏｆｔ社のウインドウズ（登録商標）ＮＴがある。しかし、これらシステムの作業環境の透過性はＷＡＮには適用できない。
【００２３】
ＭＡＳ・ＴＣ／Ｓシステム　
本発明のＭＡＳ・ＴＣ／Ｓシステムは以下に述べる主要な要素を有する。このＭＡＳ　ＴＣ／Ｓアーキテクチャーを図示した図２を参照。
マルチアプリケーションサーバー・ネットワーク２２内でシン−クライアント機器２ａが適切なアプリケーションサーバーを判別できるようにするアプリケーションサーバー・ディスカバリプロトコル２１。
シン−クライアント機器２ａとアプリケーションサーバーが通信を行えるようにするディスプレープロトコル２３。
透過的な作業環境を提供し、ユーザーがマルチアプリケーションサーバー・ネットワーク２２内でいかなるアプリケーションに接続していても実質的に同一の作業環境を体感すること可能にする分配ファイルシステム２４。
なお、以上述べた要素２１〜２４は図２に説明のため示されているが、必ずしもその接続や機能を限定的に表したものではない。
【００２４】
ＭＡＳ・ＴＣ／Ｓシステム内のディスプレープロトコル２３は、例えば、Ｘプロトコル、インデペンデント・コンピューティング・アーキテクチャ（ＩＣＡ）・プロトコル、遠隔デスクトップ（ＲＤＰ）プロトコルおよび無国籍低水準インターフェース・マシーン（ＳＬＩＭ）プロトコル等、従来のシン−クライアント／サーバーのコンピューターモデルで使われているものと同じものにすることが可能である。従って、例えばＸターミナル、ＳＬＩＭコンソール、ＩＣＡのウインドウズ（登録商標）ベースターミナル、パーソナル・コンピューター、ワークステーション、テレビ受像機の上部ボックス、携帯情報端末（ＰＤＡ）または携帯電話等、従来のシン−クライアント／サーバーのコンピューターモデルのために設計されたシン−クライアント機器もＭＡＳ・ＴＣ／Ｓシステムを使用することができる。
【００２５】
図２に示されるように、マルチアプリケーションサーバー・ネットワーク２２内に複数のアプリケーションサーバー２ｄ、２ｅ、２ｆ、２ｇおよび２ｈがある。マルチアプリケーションサーバー・ネットワーク２２はＷＡＮ、さらにインターネットとしてもよい。
【００２６】
ここでＭＡＳ・ＴＣ／Ｓシステムがどのように作動するかを説明するために１つのある状況を想定する。図２では、ユーザーは通常、最も効率がよく実行可能なアプリケーションサーバー２ｄに接続していて、そのデータおよびファイルは全てこのサーバー２ｄに保管されている。ユーザーが、特にこのアプリケーションサーバー２ｄがリンクするＬＡＮを離れて別の場所に旅行する場合、ＭＡＳ・ＴＣ／Ｓシステムは以下の方法で作動する。
【００２７】
ユーザーがシン−クライアント機器２ａを使ってマルチアプリケーションサーバー・ネットワーク２２に接続する際、アプリケーションサーバー・ディスカバリプロトコル２１はシン−クライアント機器２ａが接続するための適切なアプリケーションサーバー２ｈを探知することを助ける。通常、適切なアプリケーション２ｈはシン−クライアント機器２ａと同じＬＡＮ内にあるので、シン−クライアント機器２ａはネットワークの伝送スピードの制約をうけず迅速なサービスを得られる。ある実施例では、マルチアプリケーションサーバー・ネットワーク２２内で利用可能な全てのアプリケーションサーバーに関する情報を収容するデータベース２ｃを備えた参照先変更サーバー２ｂが、シン−クライアント機器２ａが適切なアプリケーションサーバー２ｈを探知することを助ける。
【００２８】
図３は本発明のＭＡＳ　ＴＣ／Ｓ方法のステップ別フローチャートを示す。ステップ３ａでは、シン−クライアント機器はマルチアプリケーションサーバー・ネットワークに接続されている。ステップ３ｂでは、マルチアプリケーションサーバー・ネットワーク内で上記のシン−クライアント機器にとって最適なアプリケーションサーバーが特定される。ステップ３ｃでは、シン−クライアント機器が上記の適切なアプリケーションサーバーに接続するよう誘導される。さらにステップ３ｄにおいて、シン−クライアント機器の透過的な作業環境を保持するためにファイルが適切なアプリケーションサーバーに配信される。
【００２９】
アプリケーションサーバー・ディスカバリプロトコル
ユーザーがシン−クライアント機器を使用してアプリケーションサーバーに接続しようとする際、マルチアプリケーションサーバー・ネットワーク内の最適なアプリケーションサーバーを判別するためにアプリケーションサーバー・ディスカバリプロトコルが使われる。
【００３０】
本発明では２種類のアプリケーションサーバー・ディスカバリプロトコル、（１）シン−クライアント機器が１または２以上の特定のグループ名もしくは初期設定のグループ名を使いアプリケーションサーバーを求めてマルチキャスト・ブロードキャストを行うマルチキャスト・ディスカバリプロトコルおよび（２）アプリケーションサーバーを求めてシン−クライアント機器が発信する各検索が、全てのアプリケーションサーバーに関する情報を収容するデータベースを備えた１または複数の参照先変更サーバーに送信されるユニキャスト・ディスカバリプロトコルが提案、実施される。
【００３１】
参照先変更サーバーはシン−クライアント機器にどのアプリケーションサーバーが最適なものかを伝え、そのシン−クライアント機器の設置場所に応じて最適のアプリケーションサーバーに接続するよう誘導する。最適アプリケーションサーバーはシン−クライアント機器に最も近い場所にある方が望ましい。更に、参照先変更サーバーは、設置場所以外にもマルチアプリケーションサーバー・ネットワーク内の各アプリケーションサーバーの配置およびその状態に応じ、適切なアプリケーションサーバーを判別することができる。例えば、各アプリケーションサーバーの負荷状態も、どのアプリケーションサーバーが最適かを判断する際に考慮されることがある。
【００３２】
図４は適切なアプリケーションサーバーを判別するためのユニキャストのルックアップのステップ別フローチャートを示す。ステップ４ａでは、シン−クライアント機器がアプリケーションサーバーを求めてユニキャストのルックアップを参照先変更サーバーに発し、ステップ４ｂでは、参照先変更サーバーが、シン−クライアント機器の設置場所およびマルチアプリケーションサーバー・ネットワーク内で利用できる各アプリケーションサーバーの配置およびその状態に応じて最適なアプリケーションサーバーを判別する。
【００３３】
本発明において、ＭＡＳ・ＴＣ／Ｓのための分配ファイルシステムは、透過的な作業環境を体感させるために適用され、この透過的な作業環境はアクセス、場所および移動性に関するものであることが好ましい。多数のアプリケーションサーバーがＷＡＮ内に設置されると、全アプリケーションサーバー内のユーザーの全データとファイルを複製するのに必要な保存コストと通信コストが非常に高くなる。実際、ＭＡＳ・ＴＣ／Ｓシステムの効果的な分配ファイルシステムは非常に重要であり、ユーザーのデータ需要を予測できるファイル・プリフェッチング機能をもっていることが望まれる。本発明の分配ファイルシステムは、従来の分配ファイルシステムの機能性に充実したファイル・プリフェッチング機能を加えている。
【００３４】
ユーザーのための作業環境は以下に述べる形のデータを必要とする。
１．　ユーザーの記録またはそのプリファレンス（お気に入り）。これはウインドウ・マネジャーの記録および各種のアプリケーションの記録ファイルを含む。
２．　ユーザー・ファイル。例えば電子メールのファイル、ワードプロセッサー、スプレッドシート、画像およびマルチメディア等、ユーザーだけに属する個人ファイルがある。
３．　アプリケーション・ソフトウェア。これらは各種のアプリケーションに対するバイナリコードである。
【００３５】
以上の３つの形態のデータはアプリケーションサーバーにファイル形式で存在する。本明細書では以下、ユーザー・データという表現は、ユーザーの記録およびそのファイルの両方を集合的に言及するために使われる。ユーザーに透過的な作業環境を提供するため、ユーザーがアプリケーションサーバーにログオンした後で必要なファイルが用意されていなければならない。ただし、ＷＡＮ内にいれば、ユーザーはシン−クライアント機器を通してどの場所にも行くことができ、どのようなアプリケーションサーバーにもログオンすることができるので、アプリケーションサーバーは迅速なサービスを提供するためにユーザーの各データを用意しておく必要がある。
【００３６】
本発明の分配ファイルシステムは、ユーザー・データを全アプリケーションサーバーに完全に複製することを必要としない。従って、ユーザーが適切なアプリケーションサーバーにログオンした時ユーザー・データの一部が不在という状況を解決する必要がある。ユーザーが不在のファイルを必要とする場合、この接続されたアプリケーションサーバーがそのファイルをフェッチ（ｆｅｔｃｈ：読み出す）する必要がある。
【００３７】
従来のシン−クライアント／サーバーのコンピューティングモデルでは、以下に述べる２つの要件さえ満たせば許容範囲のレスポンス時間が得られる。（１）シン−クライアント機器と接続するアプリケーションサーバー間のネットワークのバンド帯域がディスプレープロトコルを行うのに十分な速さであること、および（２）アプリケーションサーバーの負荷が適度であることである。しかし、ＭＡＳ・ＴＣ／Ｓシステムでは、ユーザー・データが必ずしも全アプリケーションサーバーに複製されるとは限らないので、許容範囲のレスポンス時間を測定する際、上記に述べた２つの要件に加え、不存在のファイルをフェッチする際に伴う遅延を考慮しなければならない。
【００３８】
フェッチング機能にはデマンド・フェッチングおよびプリフェッチングの２種類がある。デマンド・フェッチングはユーザーがファイルのアクセスを要求した後で行われ、一方、プリフェッチングではファイルはあらかじめフェッチされる。
【００３９】
データのフェッチングを行う類似の技術はＣＰＵ（中央処理装置）のキャッシュの動作およびオペレーティング・システムのページング・システムに見出すことができる。ＣＰＵのキャッシュやページング・システムでのデータのフェッチングの粒状度（ｇｒａｎｕｌａｒｉｔｙ）がそれぞれキャッシュ回線およびメモリーページ毎であるのに対し、アプリケーションサーバーはファイル毎にフェッチする。ＣＰＵキャッシュおよびページングシステムのプリフェッチング技術に関する従来の研究によると、普通のプログラムへのメモリーアクセスは通常順次的に行われるので、通常、錯誤率の点でプリフェッチングの方がデマンド・フェッチングよりもはるかに優れている。
【００４０】
プロセッサーによるメモリーアクセスとユーザーによるファイルアクセスの間には多少の差があることは明らかである。まず第１に、キャッシュ回線とメモリページは通常一定の容量であるが、ファイルの容量は可変である。第２に、ファイルは、例えば作成日、アップデートされた時間、著者および形式等、多少の追加情報を有する。ＭＡＳ・ＴＣ／Ｓシステムでプリフェッチング機能を設計する際、（１）マルチアプリケーションサーバー・ネットワーク、および（２）透過的な作業環境の必要性、の２つの要素がさらに考慮される。
インテリジェント・プリフェッチングおよびアポインテド・プリフェッチングの２種のプリフェッチング機能が存在し、これらの説明は以下のとおりである。
【００４１】
インテリジェント・プリフェッチング
インテリジェント・プリフェッチング機能は、アプリケーションサーバーによってユーザーのデータ要求が処理される時に同時進行する。その主要な役目は、データ要求の後でユーザーが必要とするような一連のデータを予測することである。接続中のユーザーのデータは以下のような３種のカテゴリーに分類される。
【００４２】
１．システムデータ。これは、ユーザーがログオンした直後にユーザーのデスクトップ作業環境によって要求された一連のデータを差し、ウインドウ・マネジャーの記録ファイル、各種のアプリケーションのセットアップおよびホーム・ファイル・ディレクトリに関する情報を含む。あるユーザーのシステムデータは、そのユーザー独自の環境をユーザーに提供するためアプリケーションサーバーが必要とする。
２．作業データ。これは、ユーザーが接続中に作業するたに必要な一連のファイルを差す。
３．未使用データ。これは接続中に使用されない他のファイル全てを差す。
【００４３】
好ましくは、ユーザーのシステムデータおよび作業データの両方が実際に必要とされる前にフェッチされればよい。しかし、システムデータは正確に割り出されるが、作業データが正確に割り出されることはほとんどない。さらに、あるユーザーに属するシステムデータの容量はその作業データと比較するとはるかに少ない。システムデータの容量は通常１００キロバイトしかないが、ユーザーがホーム・ディレクトリに数百または数千メガバイトのファイルを所有していることはよくあることである。従って、システムデータは通常少量で不変のままなので、それに対応するにはデマンド・フェッチングで充分に間に合うことが多い。
【００４４】
インテリジェント・プリフェッチング機能は、好ましくは以前の接続で得られたこれまでのデータを基にして、アクセス時間、アクセス操作およびファイルの容量等、一連の作業データを予測する。特に、以下のような２つの方法がある。
【００４５】
１．優先プリフェッチング。これは、ユーザーに属するファイルをある種の優先順位でリストアップする方法である。あるファイルの優先度はその属性の機能として決められる。例えば、頻繁にアクセスされ、より小容量のファイルの優先度はより高くなる。
【００４６】
２．アクセスパターンベース・プリフェッチング。これは、ユーザーによる現在進行中のファイル要求とそのユーザーが最も頻繁に行うアクセスのパターンに基づいてファイルを動的にフェッチする方法である。例えば、ユーザーがファイル開示の要求をすると、どのファイルがその後必要になるかというある種の確率に対する予測がなされる。これら予測されたファイルはプリフェッチングの候補である。
【００４７】
例えばデータ・マイニング、神経回路網、人工知能およびファジー技術等、各種の技術がインテリジェント・プリフェッチングに適用される。本発明においては、上記のアクセスパターンベース・プリフェッチングを行うため、データ・マイニング技術を基礎とした包括的アルゴリズムが開発され、以下その概要を説明する。
【００４８】
現在アクセス中のファイルに関連するその後のファイルアクセスを予測する際、アプリケーションサーバーは以下のような問題に対する解答を求める。「θおよびｓがユーザー特定の限界値である時、今からθ時間内に、少なくともｓ％の確率で順次アクセスされるようなファイルの組み合わせを検出せよ。」
【００４９】
この問題に解答するためには、ファイルアクセスの最も頻繁に行われるパターンを把握している必要がある。ファイルアクセス・パターンは、先端がファイルを示し、ファイルｆ２へのアクセスがファイルｆ１へのアクセスの後に続いて短時間で行われるという場合に（ｆ１，ｆ２）がエッジになるような有方向の非環式グラフで表される。このようなグラフを時間的グラフという。時間的グラフにおけるファイルの組み合わせは全て追随もしくは重複の時間的関係をもつ。もしファイルｆ１をファイルｆ２に接続する経路が存在する時、時間的グラフにおいてｆ１の後にｆ２が続き、また、どちらのファイルも互いに追随しない時はこれらのファイルは重複している。
【００５０】
実際、ファイルアクセスの例も時間的グラフとして表すことができる。例えば、各ファイルのインターバルがファイルの開時間と閉時間とで示されているファイルアクセスの一例を示す図５ａで検討する。図５ｂはファイルＦ１〜Ｆ６の呼び出し関係を示す。すなわち、Ｆ１はＦ２およびＦ３を呼び出し、次にＦ３がＦ５およびＦ６を呼び出す。Ｆ２もＦ３も同一のファイル例えばＦ１等によって呼び出されかつその開示時が非常に近接しているので、この例においてＦ２およびＦ３は重複しているという。これに対して、Ｆ１とＦ２は同一のファイルによって呼び出されず、かつＦ１の開／時はＦ２より前にあるので、Ｆ２はＦ１に追随しているという。また、Ｆ５とＦ６は同一のファイルＦ３によって呼び出されているが、Ｆ５の開／時がＦ６の開／時よりずっと前にあるのでＦ６はＦ５に追随しているという。
【００５１】
上記例に対応する時間的グラフは図５ｃに表されており、ここでは描線が重複する時間的関係を示している。ファイルアクセスの経歴から頻繁に観測される時間的（サブ・）グラフを見出すことやマイニング・アルゴリズムに関する詳細は、Ｃ．−Ｐ．　Ｗｅｉｒ　ｅｔ　ａｌ，　（Ｃ．−Ｐ．　Ｗｅｉｒ，　Ｓ．−Ｙ．　Ｈｗａｎｇ，　Ｗ．−Ｓ．　Ｙａｎｇ，Ｍｉｎｉｎｇ　Ｆｒｅｑｕｅｎｔ　Ｔｅｍｐｏｒａｌ　Ｐａｔｔｅｒｎｓ　ｉｎ　Ｐｒｏｃｅｓｓ　Ｄａｔａｂａｓｅ：　Ｐｒｏｃ．　ｏｆ　ｔｈｅ　１０’ｔｈ　Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｗｏｒｋｓｈｏｐ　ｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｅｃｈｎｏｌｏｇｉｅｓ　ａｎｄ　Ｓｙｓｔｅｍｓ　（ＷＩＴＳ００）：　Ｂｒｉｓｂａｎｅ，　Ａｕｓｔｒａｌｉａ，　２０００）にある。
【００５２】
時間的グラフにおける各エッジ（ｆｉ，ｆｊ）は、ｆｉおよびｆｊの開示時の持続時間の配分を表す一対の時間値（μ，　σ）と関連し、μおよびσはそれぞれ平均値および標準偏差値を表す。これらの時間値は特定の時間内に次のファイルアクセスを行う確率を計算するために使うことができる。例えば、（ｆｉ，ｆｊ）のサポートをｆｉのサポートで割ると３０％となり、その持続時間が正規分布に従う場合、ｆｉにアクセスした後、μ＋σ単位時間内にｆｊにアクセスする確率は３０％　×　８４．１３％となる。なお、この８４．１３％は
【００５３】
【数１】
2004094411.tif 000003
【００５４】
（通常、Ｘは平均値μおよび偏差値σ２とともに正規分布され、また、
【数２】
2004094411.tif 000004
【００５５】
である）から求められる。
【００５６】
以下に述べるアルゴリズム１は、上記の問題を解決するファイルの組み合わせを判別するためのアルゴリズムをリストアップしたものである。
アルゴリズム１：アクセスパターンに基づくプリフェッチング・アルゴリズム／＊現在進行中のデータ要求ｆｉの後に引き続き、今からθ単位時間内に、少なくともｓ％の確率でアクセスされると思われるファイルの組み合わせを検出せよ。＊／
【００５７】
【数３】
2004094411.tif 000005
【００５８】
【数４】
2004094411.tif 000006
【００５９】
における最大値を有する経路を検出せよ。なお、ここで（μｊ，　σｊ）はｊ番目のエッジと関連する持続時間の分布を表す。もしｄ　＞θならば、次の時間的グラフに進行せよ。
【００６０】
Ｂ．最長の経路を検出せよ。経路の長さを　ｌ　、ｆおよびＴｉのサポートをそれぞれｓ１およびｓ２とする。もし、ｓ１／ｓ２　×　（８４．１３％）　＜　ｓの場合、次の時間的グラフに進行せよ。
Ｃ．Ｔｉにおけるファイルをリターン−セットに加えよ。
４．リターン−セットをリターンせよ。
なお、上記のアルゴリズムは限定された数の頻出する時間的グラフのためのものである。
【００６１】
θを大きな値にし、ｓを小さな値にすると、多数のファイルをプリフェッチングする結果になり、従って、その後順次にアクセスされる各ファイルを含む可能性が高くなる。しかし、大量のファイル転送はネットワークの性能の低下につながり、その時すぐに必要なファイルが時間内に到着しないことがある。θおよびｓの設定の間のトレードオフが予測される。
【００６２】
最も一般的なファイルのアクセスパターンも、置換されたファイルを割り出すために使うことができる。以下に述べる問題への解答は重要である。「今からθ２時間内に、少なくともｓ２％の確率で順次アクセスされるようなファイルの組み合わせＳ２を検出せよ。」
【００６３】
Ｓ２は充分に長い時間θ２をかけてアクセスされるファイルを含む。Ｓ２に属さないキャッシュ化されたファイルは置換の対象となる。Ｓ２は置換されることを意図されているファイルの組み合わせであることから、θ２　と　ｓ２の設定は前出の問題のθよりもはるかに大きく、　ｓよりもはるかに小さくなるであろう。上記の問題を解決するための直接的なアルゴリズムがアルゴリズム１と同様にして導き出される。
【００６４】
アポインテド・プリフェッチング　
システムがユーザーの日常スケジュールに頻繁に現れるファイルのアクセスパターンを割り出そうとするインテリジェント・プリフェッチングの他にも、アポインテド・プリフェッチングと呼ばれるプリフェッチング機能がユーザーの不規則なスケジュールを把握するために提供される。アポインテド・プリフェッチング機能はユーザーが必要とする少なくとも１つのファイルを特定し、特定されたファイルは事前に適切なアプリケーションファイルに転送される。ある実施例によると、ユーザーのスケジュールはそのデータの流れに焦点をおいた仕事の流れとして説明されている。具体的には、スケジュールを一連の仕事としてひな型がつくられ、それぞれの仕事は三重項（Ｄ，Ｌ，Ｆｓ）で表され、ＤとＬはこの仕事が行われる持続時間および場所をそれぞれ表し、Ｆｓは仕事に必要なファイルの組み合わせを表す。
【００６５】
次の一例では、ピーターはカリフォルニアにある会社に勤務し、東京にある彼の会社のＲ＆Ｄ部門でプレゼンテーションを行うため日本に出張することになった。プレゼンテーションの間、彼はｐｒｅ１．ｄｏｃ，　ｐｒｅ１．ｐｐｔ，　ａｎｄ　ｐｒｅ１．ｓｃｒというファイルを使用する予定である。彼はこのファイルを日本に持って行く代りに、事前に、仕事プレゼンテーション　（（２００２／２／３０：９：００　￣　２００２／２／３０：１２：００），　日本　Ｒ＆Ｄ，　（ｐｒｅ１．ｄｏｃ，　ｐｒｅ１．ｐｐｔ，　ｐｒｅ１．ｓｃｒ））を特定するだけである。システムはこれらのファイルを彼の東京でのプレゼンテーションに先立って日本のＲ＆Ｄ部門にあるアプリケーションサーバーに転送する。
【００６６】
インテリジェント・プリフェッチングの場合と全く同じように、アポインテド・プリフェッチングにて特定されたスケジュールはプリフェッチングおよび置換の双方に使用される。必要とされるファイルの容量、仕事が行われる予定の時間と場所およびネットワークのバンド帯域を考慮し、仕事が実際に行われる前にファイルが正確な場所に到着していなければならないという制約下で、システムはファイルを転送するための最低費用のスケジュールを決定する。仕事の遂行時間が過ぎると、これらのファイルは置換の対象となる。
【００６７】
実施
ＭＡＳ・ＴＣ／Ｓシステムの未開示のプロトタイプが作られている。このプロトタイプは台湾の３つの都市に位置する３つの大学、台北の国立台湾一般大学（台湾北部）、Ｈｓｉｎｃｈｕの国立Ｔｓｉｎｇ−Ｈｕａ大学（台湾中部）およびＫａｏｈｓｉｕｎｇの国立Ｓｕｎ　Ｙａｔ−Ｓｅｎ大学（台湾南部）のキャンパスを網羅する。この３つの大学のネットワークシステムはＷＡＮを形成する。
【００６８】
各アプリケーションサーバーはＬｉｎｕｘ　ＯＳを実行するペンティアム（登録商標）のＰＣで実行され、各ＬｉｎｕｘのワークステーションはＸプロトコルが組み込まれているので、ディスプレープロトコルとして選ばれた。シン−クライアント機器としては、以下の３つのタイプのプラットフォームが考えられる。
【００６９】
シン−クライアント機器タイプ１：これは一般的な目的のＰＣあるいはＸプロトコルおよびウエブ・ブラウザーが組み込まれたワークステーションを差す。　シン−クライアント機器タイプ２：これはＸプロトコルおよびウエブ・ブラウザーが組み込まれたＰＤＡを差す。
シン−クライアント機器タイプ３：これはＪａｖａ（登録商標）ＪＤＫ１．３アプレットを実行可能なウエブ・ブラウザーをもつその他のコンピューターを差す。これらのコンピューターにはＸプロトコルを組み込まれている必要はない。
【００７０】
ウエブサーバーがユニキャスト・アプリケーションサーバー・ディスカバリ・プロトコルを実施するのに使われることから、以上の３つのシン−クライアント機器は全てウエブ・ブラウザーを備えている。参照先変更サーバーは、設置されたアプリケーションサーバーの全てに関する情報を収容するデータベースと関連する。シン−クライアント機器がアプリケーションサーバーと接続しようとすると、それはまずウエブ・ブラウザーで参照先変更サーバーのホームページを訪れる。図６ａに示されるように、設置されたアプリケーションサーバーの全てが一覧となっており、ユーザーは自分でアプリケーションサーバーを選択してもよいし、またはシステムに適切なアプリケーションサーバーを選択してもらってもよい。
【００７１】
シン−クライアントとアプリケーションサーバー間の接続過程が図７ａおよび７ｂに表されている。図７ａはシン−クライアント機器のタイプ１またはタイプ２（例えば、Ｘプロトコルがを組み込まれたもの）の接続過程を示す。まず第１に、ステップ（１）ではシン−クライアント機器７ａが指示サーバー７ｂ（スクリーンショットが図６ｃに表示されている）のホームページを訪れる。第２に、ステップ（２）では、参照先変更サーバー７ｂがシン−クライアント機器７ａの参照先をログインのホームページをもつ選択されたアプリケーションサーバー７ｃに変更し、さらに、ユーザーはラジオボタンをクリックしてアプリケーションサーバー７ｃにシン−クライアント機器７ａにＸプロトコルが組み込まれていること（スクリーンショットが図６ｂに表示されている）を知らせる。最後に、ステップ（３）では、アプリケーションサーバー７ｃがユーザーのシン−クライアント機器７ａと通信するために、Ｘプロトコルを使用する適切なウインドウ・マネージャーを実行する。
【００７２】
図７ｂはタイプ３のシン−クライアント機器７ｄの接続過程を表す。ステップ（１）および（２）において、参照先変更サーバー７ｅはシン−クライアント機器７ｄの参照（接続）先を選択されたアプリケーションサーバー７ｆに変更する。これは図５ａで示したステップと実質的に同一のものであるが、シン−クライアント機器７ｄがタイプ３であるのでＸプロトコルを設置していない点が異なる。ユーザーはこのことをアプリケーションサーバー７ｆ（スクリーンショットは図６ｃに表示されている）に指摘する。さらに、ステップ（３）において、アプリケーションサーバー７ｆはＸプロトコルをエミュレートするＸｗｅｉｒｄというＪａｖａ（登録商標）アプレットを送信する。図６ｄはＸプロトコルが組み込まれたオペレーショナル・シン−クライアントのスクリーンショットを示し、図６ｅはＸｗｅｉｒｄ　Ｊａｖａ（登録商標）アプレットを実行するウエブ・ブラウザーを備えたアプリケーションサーバーに接続するオペレーショナル・シン−クライアントのスクリーンショットを示している。
【００７３】
【発明の効果】
本発明のＭＡＳ・ＴＣ／Ｓシステムは、例えばインターネットのサービスプロバイダーのためのサービス指向のインフラや多国籍企業のためのオフィス・オートメーション等、多種多様のアプリケーションに適用することができる。
【００７４】
上記に述べた詳細な説明は本発明の特徴および精神を明らかにするためであり、本発明の適用範囲を限定しようとするものではない。各種の変更および同意義の修正は本発明によって網羅されるべきである。従って、本発明の適用範囲は上記に述べたクレームおよび説明を基づき最も広い意味で解釈されるべきである。
【図面の簡単な説明】
【図１】図１はシン−クライアント／サーバーのコンピューターモデルである。
【図２】図２は本発明のＭＡＳ　ＴＣ／Ｓアーキテクチャーである。
【図３】図３は本発明のＭＡＳ　ＴＣ／Ｓ方法のステップ別フローチャートである。
【図４】図４は適切なアプリケーションサーバーを判別するためのユニキャストのルックアップのステップ別フローチャートである。
【図５ａ】図５ａはアクセスパターンに応じたプリフェッチングの一例である。
【図５ｂ】図５ｂはアクセスパターンに応じたプリフェッチングの一例である。
【図５ｃ】図５ｃはアクセスパターンに応じたプリフェッチングの一例である。
【図６ａ】図６ａは本発明のＭＡＳ・ＴＣ／Ｓシステムの実施例である。
【図６ｂ】図６ｂは本発明のＭＡＳ・ＴＣ／Ｓシステムの実施例である。
【図６ｃ】図６ｃは本発明のＭＡＳ・ＴＣ／Ｓシステムの実施例である。
【図６ｄ】図６ｄは本発明のＭＡＳ・ＴＣ／Ｓシステムの実施例である。
【図６ｅ】図６ｅは本発明のＭＡＳ・ＴＣ／Ｓシステムの実施例である。
【図７ａ】図７ａはシン−クライアント機器とアプリケーションサーバーとの接続過程である。
【図７ｂ】図７ｂはシン−クライアント機器とアプリケーションサーバーとの接続過程である。
【図１】
2004094411.tif 000007
【図２】
2004094411.tif 000008
【図３】
2004094411.tif 000009
【図４】
2004094411.tif 000010
【図５ａ】
2004094411.tif 000011
【図５ｂ】
2004094411.tif 000012
【図５ｃ】
2004094411.tif 000013
【図６ａ】
2004094411.tif 000014
【図６ｂ】
2004094411.tif 000015
【図６ｃ】
2004094411.tif 000016
【図６ｄ】
2004094411.tif 000017
【図６ｅ】
2004094411.tif 000018
【図７ａ】
2004094411.tif 000019
【図７ｂ】
2004094411.tif 000020