(57)【要約】【課題】個人が使用するような複数のパーソナルコンピュータを用いて、データの共有を行い、共有するデータの可用性及び信頼性を高めること。【解決手段】他のノードの可用性を確認するために、ノード確認部３１から他のノードにノード確認要求を送信する。他のノードのノード確認応答メッセージ送信部３２から可用性を示す情報を含むノード確認応答メッセージをノード確認部３１が受信する。分散保存設定部３３が、ノード確認応答メッセージの内容に応じてパラメータＮ、Ｍを決定する。分散保存部３４が、共有データをＮ分割して前記可用性が確認されているＮ台のノードにＭ重に分散して保存する。分割データ収集部３５が前記Ｎ分割された分割データを選択的にＮ個集め、データ復元部３６が、集めたＮ個の分割データを結合し元のデータを復元する。【選択図】図２
2009037318.tif 000002
【特許請求の範囲】
【請求項１】
自グループに属する複数のノードがネットワークに接続される情報通信システムにおいて、
前記複数のノードのそれぞれは、
前記ネットワークを経由して前記自グループに属する他のノードの可用性を確認するために、前記他のノードにノード確認要求を送信し、前記他のノードから可用性を示す情報を含むノード確認応答メッセージを受信するノード確認手段と、
前記他のノードの前記ノード確認手段からノード確認要求を受信した場合に、前記ノード確認応答メッセージを前記ノード確認要求を送信したノードに送信するノード確認応答メッセージ送信手段と、
前記ノード確認応答メッセージの内容に応じてパラメータＮ，Ｍを設定する分散保存設定手段と、
共有データをＮ分割し、前記共有データの各分割データをＮ台のノードにＭ重に分散して保存する分散保存手段と、
（Ｎ−Ｍ＋１）台以上のノードから前記Ｎ分割された分割データを選択的にＮ個集める分割データ収集手段と、
前記他のノードの分割データ収集手段の要求に応じて前記要求に応じた分割データを前記要求を発行したノードに転送する分割データ転送手段と、
集めたＮ個の分割データを結合することによって前記共有データを復元するデータ復元手段とを具備することを特徴とする情報通信システム。
【請求項２】
前記分散保存設定手段は、前記ノード確認応答メッセージの内容および前記共有データの機密度を用いて前記Ｎ、Ｍのパラメータを決定することを特徴とする請求項１記載の情報通信システム。
【請求項３】
前記ノード確認応答メッセージは、自ノードで利用可能な記録容量を含むことを特徴とする請求項１記載の情報通信システム。
【請求項４】
前記各ノードは、アクセスしてきたノードのユーザや機器を認証する認証する認証手段を更にそれぞれ具備し、
前記分割データ転送手段は、前記認証手段による認証が成功した場合に前記分割データを転送することを特徴とする請求項１記載の情報通信システム。
【請求項５】
前記各ノードは、
第１のオペレーティングシステムと前記第１のオペレーティングシステム上で動作する第１のプログラムグループを含む第１のソフトウェアと、第２のオペレーティングシステムと前記第２のオペレーティングシステム上で動作する第２のプログラムグループとを含む第２のソフトウェアとが同時実行する情報処理装置であって、
前記第１のソフトウェアから第２のソフトウェア内の資源へ直接アクセスできないようにする手段と、
を具備することを特徴とする請求項１〜４の何れか一つに記載の情報通信システム。
【請求項６】
前記各分割データ、前記ノード確認手段、前記ノード確認応答メッセージ送信手段、前記分散保存手段、前記分割データ転送手段、前記分割データ転送手段、および前記データ復元手段は、前記第２ソフトウェアに属することを特徴とする請求項５記載の情報通信システム。
【請求項７】
前記分散保存設定手段は、前記第２ソフトウェアに属することを特徴とする請求項５記載の情報通信システム。
【請求項８】
自グループに属する複数のノードがネットワークに接続される情報通信システムのデータ共有方法であって、
前記ネットワークを経由して前記自グループに属する他のノードの可用性を確認するために、前記他のノードにノード確認要求を送信し、
前記他のノードから可用性を示す情報を含むノード確認応答メッセージを受信し、
前記ノード確認応答メッセージの内容に応じてパラメータＮ、Ｍを決定し、
共有データをＮ分割し、前記共有データの各分割データをＮ台のノードにＭ重に分散して保存し、
（Ｎ−Ｍ＋１）台以上のノードから前記Ｎ分割された分割データを選択的にＮ個集め、
集めたＮ個の分割データを結合することによって前記共有データを復元することを特徴とするデータ共有方法。
【請求項９】
前記Ｎ、Ｍのパラメータは、前記ノード確認応答メッセージの内容および前記共有データの機密度を用いて決定されることを特徴とする請求項８記載のデータ共有方法。
【請求項１０】
前記ノード確認応答メッセージは、自ノードで利用可能な記録容量を含むことを特徴とする請求項８記載のデータ共有方法。
【請求項１１】
前記Ｎ分割された分割データを選択的にＮ個集める時において、
前記他のノードに分割データの転送を要求し、
前記要求を受けたノードが前記要求を送信したノードに前記要求に応じた前記分割データを転送することを特徴とする請求項８記載のデータ共有方法。
【請求項１２】
前記要求を送信したノードと前記要求を受信したノードとの間で認証処理を行い、
前記認証処理が成功した場合に、前記要求を受けたノードが前記要求を送信したノードに前記要求に応じた前記分割データを転送することを特徴とする請求項１１記載のデータ共有方法。
【請求項１３】
前記各ノードは、
第１のオペレーティングシステムと前記第１のオペレーティングシステム上で動作する第１のプログラムグループを含む第１のソフトウェアと、第２のオペレーティングシステムと前記第２のオペレーティングシステム上で動作する第２のプログラムグループとを含む第２のソフトウェアとが同時実行する情報処理装置であって、
前記第１のソフトウェアから第２のソフトウェア内の資源へ直接アクセスできないようにする手段と、
を具備することを特徴とする請求項８〜１２の何れか一つに記載のデータ共有方法。
【請求項１４】
前記各分割データは、前記第２ソフトウェアに属することを特徴とする請求項１３記載のデータ共有方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のノードでデータを共有する情報通信システム、およびデータ共有方法に関する。
【背景技術】
【０００２】
サーバ機を導入していない企業や部門は多い。しかし、このような企業や部門もほとんどがパソコンを業務に利用している。従来このようなサーバ機を導入せずパソコンだけを利用している企業に対し、ワークグループの業務に適する利便性に優れ、機密性の高いデータの共有が可能となる情報通信システムは少ない。
【０００３】
特許文献１には、第１〜第ｎのコンピュータをネットワークを介して接続し、データベースを第１〜第ｎのスロットに分割し、第１〜第ｎのスロットを原本スロットとして各コンピュータに格納し、各原本スロットの複製を原本スロットが記憶されているデータ格納部と異なる格納部に記憶する技術が開示されている。
【特許文献１】特開２００４−９４６８１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述した技術では、１台のコンピュータが故障してもデータを復旧することが出来る。ところで、上述した技術では、第１〜第ｎのコンピュータとしてサーバであることを想定している。従って、サーバを導入することが出来ないような部門では、上述した技術を導入することが困難である。
【０００５】
本発明の目的は、個人が使用するような複数のパーソナルコンピュータを用いて、データの共有を行い、共有するデータの可用性及び信頼性を高めることが可能な情報通信システム、及びデータ共有方法を提供することにある。
【課題を解決するための手段】
【０００６】
本発明の一例に係わる、自グループに属する複数のノードがネットワークに接続される情報通信システムにおいて、前記複数のノードのそれぞれは、前記ネットワークを経由して自グループに属する他のノードの可用性を確認するために、他のノードにノード確認要求を送信し、他のノードから可用性を示す情報を含むノード確認応答メッセージを受信するノード確認手段と、他のノードの前記ノード確認手段からノード確認要求を受信した場合に、前記ノード確認応答メッセージを前記ノード確認要求を送信したノードに送信するノード確認応答メッセージ送信手段と、前記ノード確認応答メッセージの内容に応じてパラメータＮ，Ｍを設定する分散保存設定手段と、共有データをＮ分割し、各分割データをＮ台のノードにＭ重に分散して保存する分散保存手段と、（Ｎ−Ｍ＋１）台以上のノードから前記Ｎ分割された分割データを選択的にＮ個集める分割データ収集手段と、前記他のノードの分割データ収集手段の要求に応じて前記要求に応じた分割データを前記要求を発行したノードに転送する分割データ転送手段と、集めたＮ個の分割データを結合することによって前記共有データを復元するデータ復元手段とを具備することを特徴とする。
【０００７】
本発明の一例に係わる、自グループに属する複数のノードがネットワークに接続される情報通信システムのデータ共有方法は、前記ネットワークを経由して自グループに属する他のノードの可用性を確認するために、他のノードにノード確認要求を送信し、他のノードから可用性を示す情報を含むノード確認応答メッセージを受信し、前記ノード確認応答メッセージの内容に応じてパラメータＮ、Ｍを決定し、共有データをＮ分割し、各分割データをＮ台のノードにＭ重に分散して保存し、（Ｎ−Ｍ＋１）台以上のノードから前記Ｎ分割された分割データを選択的にＮ個集め、集めたＮ個の分割データを結合することによって前記共有データを復元することを特徴とする。
【発明の効果】
【０００８】
個人が使用するような複数のパーソナルコンピュータを用いて、データの共有を行い、共有するデータの可用性及び信頼性を高めることが可能になる。
【発明を実施するための最良の形態】
【０００９】
本発明の実施の形態を以下に図面を参照して説明する。
【００１０】
図１に本発明の一実施例による情報通信システムの構成図を示す。図１に示すように、パソコンやサーバ、あるいはネットワークストレージ機器などの複数のノード１〜８がネットワーク９に接続されている。
【００１１】
これらの複数のノード１〜８は社内ＬＡＮ（有線ＬＡＮ、無線ＬＡＮ）、インターネット、移動体通信網などのネットワーク９を経由して、お互いに通信ができる。
【００１２】
本実施形態に係わる情報通信システムは、Ｎ台のノード１〜８がハードディスクの一部もしくは全部を提供し合ってネットワーク上に仮想的な共有ディスクを構築し、Ｎ台のノード１〜８で共通に利用するデータを共有ディスクに分散して保存する。
【００１３】
各ノードは、ノード確認部３１、ノード確認応答メッセージ送信部３２、分散保存設定部３３、分散保存部３４、分割データ収集部３５、データ復元部３６、認証処理部３７、分割データ転送部３８等を有する。
【００１４】
ノード確認部３１は、ネットワーク９を経由して自グループに属する他のノードの可用性を確認するために、他のノードにノード確認要求を送信し、他のノードから可用性を示す情報を含むノード確認応答メッセージを受信する。各ノード１〜８は可用性確認部を有するが、マスターとして設定されたノードのノード確認部３１のみが動作する。なお、本実施形態では、ノード１がマスターとして設定されているものとする。
【００１５】
ノード確認応答メッセージ送信部３２は、マスターとして設定されたノード１のノード確認部３１からノード確認要求を受信した場合に、自ノードの可用性を示す情報を含むノード確認応答メッセージをノード１のノード確認部３１に送信する。
【００１６】
分散保存設定部３３は、上述した仮想的な共有ディスクにデータを保存する場合に、どのようにデータを分散させて保存するかを設定する。分散保存設定部３３は、少なくともノード確認応答メッセージに含まれる可用性の情報を用いて設定を決定する。分散保存設定部３３は、設定情報を各ノードに送信し、各ノードは設定情報を自ノードに保存する。
【００１７】
分散保存部３４は、分散保存部３４が決定した設定に基づいて共有データをＮ分割し、Ｎ台のノードにＭ重に分散して保存する。
【００１８】
分割データ収集部３５は、（Ｎ−Ｍ＋１）台以上のノード２〜８からＮ分割された分割データを選択的にＮ個集める。この時、分割データ収集手段は、自ノードにない分割データを他のノードから収集する場合に、分割データ転送要求を他のノードに送信する。分割データ転送要求を受信した他のノード２〜８の分割データ転送部３８は、分割データ転送部３８から要求された分割データを分割データ転送要求を送信したノード１に送信する。
【００１９】
なお、分割データ転送部３８の分割データの転送に先立って、認証処理部３７が分割データ転送要求を送信したノードとの間で認証処理を行う。そして、認証処理が成功した場合に、分割データ転送部３８が分割データを転送する。なお、認証処理を省略して分割データの転送を行うことも可能である。しかし、セキュリティ上、認証処理があった方が好ましい。
【００２０】
データ復元部３６は、分割データ収集部３５によって選択的に集められたＮ個の分割データを結合し元のデータを復元する。
【００２１】
図３に、データを分散して保存する例（Ｎ＝８，Ｍ＝４）を示す。図３に示すように、ノードｘ（ｘ：１〜８のいずれか）は元データを生成した後、分散保存設定部３３の設定に基づいて元データを８個の分割データＡ〜Ｈに分割する。その後、ノードｘは、分散保存設定部３３の設定に基づいて分割データＡ〜Ｈを４重に分散して他のノードに保存する。
【００２２】
この例では、ノード１がデータＡ〜Ｄを保存し、ノード２がデータＢ〜Ｅを保存し、ノード３がデータＣ〜Ｆを保存し、同様にノード４〜８も異なる組み合わせの４個の分割データを保存するように配信している。
【００２３】
次に、上述した手順で保存された分割データから元のデータを復元する手順について説明する。図４は、ノードｘが８台のノード１〜８に分散して、４個ずつ保存された分割データから元のデータを復元する場合を示したものである。また、この例では、３台のノード（ノード３，ノード５，ノード６）がこの時、ネットワークに接続されていない場合を示している。
【００２４】
図４からわかるように、ノード３が保存している分割データ（Ｃ，Ｄ，Ｅ，Ｆ）と、ノード５が保存している分割データ（Ｅ，Ｆ，Ｇ，Ｈ），ノード５が保存している分割データ（Ｆ，Ｇ，Ｈ，Ａ）に関しては、前記ノードｘはノード３、ノード５、ノード６からネットワークを経由して参照あるいは受信することができない。
【００２５】
しかしながら、同図をみればわかるように
分割データＣは、ノード１、ノード２、およびノード８のいずれか１つから参照あるいは受信することができる。  
分割データＤは、ノード１、ノード２、およびノード４のいずれか１つから参照あるいは受信することができる。  
分割データＥは、ノード２、およびノード４のいずれか１つから参照あるいは受信することができる。  
分割データＦは、ノード４から参照あるいは受信することができる。  
分割データＧは、ノード４、およびノード７のいずれか１つから参照あるいは受信することができる。  
分割データＨは、ノード７、およびノード８のいずれか１つから参照あるいは受信することができる。  
分割データＡは、ノード１、ノード７、およびノード８のいずれか１つから参照あるいは受信することができる。  
分割データＢは、ノード１、ノード２、およびノード７のいずれか１つから参照あるいは受信することができる。
【００２６】
従って、ノードｘは、ネットワークに接続されている他の４台のノードから、全部で８個の分割データＡ〜Ｈを集めることができる。
【００２７】
このように、元の情報をＮ分割し、分割したＮ個の分割情報をＭ個ずつＮ台のノードに分散して保存した場合、（Ｎ−Ｍ＋１）台以上のノードが集まれば、元のデータを復元できる。
【００２８】
次に、上述した情報通信システムにおいてノード間の相互のやり取りについて説明する。なお、ここでは説明のためにこのノード間のメッセージのやり取りをＷＧＳ（Work Group  Sharing）プロトコルと呼ぶ。ＷＧＳプロトコルは、ＴＣＰプロトコルの上位のレイヤに属する。
【００２９】
図５は、ＷＧＳプロトコルメッセージの基本フォーマットを示したものである。同図に示すように、グループＩＤ１１、宛先ノードＩＤ１２、送信元ノードＩＤ１３、メッセージＩＤ１４、暗号フラグ１５、ＨＣＳ（Header Check Sequence）１６をフィールドとするヘッダ１０と、各種パラメータが含まれるメッセージのコンテンツ２１と、ＣＲＣ２２とから構成される。
【００３０】
グループＩＤ１１は、情報通信システム内の各ノードが属するグループを識別するための識別子であり、本情報通信システム内で一意に定まる。このグループＩＤ１１は、本情報通信システムにおける利用者の所属に応じて定めてもよいし、後述するワークグループ型共有ファイルシステムにおいては、アプリケーションプログラムが会議毎に自動的に割り当てるようにしてもよい。各ノードは、後述する手順でグループへの参加、離脱を行うことができる。そして、各ノードには、本情報通信システム内で一意に定まるノードＩＤが与えられる。本ノードＩＤは、本システムで独自に割り当てるようにしてもよいし、ＩＰアドレスで代用してもよい。
【００３１】
メッセージＩＤ１４はＷＧＳプロトコルでやり取りするメッセージを識別するため識別子であり、図６に示すような１０種類のメッセージとしてもよい。図６に示すように、「ノード確認要求メッセージ」、「ノード確認応答メッセージ」、「分割データ配信メッセージ」、「分割データ割当リスト配信メッセージ」、「分割データ割当リスト要求メッセージ」、「分割データ割当リスト応答メッセージ」、「分割データ転送要求メッセージ」、「分割データ転送応答メッセージ」、「グループ参加・離脱要求メッセージ」、および「グループ参加・離脱応答メッセージ」が有る。
【００３２】
暗号フラグ１５は、メッセージのコンテンツ２１を暗号化したか否かを示すものであり、暗号した場合はＤＥＳなどの暗号方式やバージョンを識別できるようにするためのものである。ＨＣＳ１６はヘッダ内のフィールドのデータに伝送路上で生じた誤りがないかチェックするためのデータである。一方、メッセージのコンテンツは、個々のパラメータをＴＬＶ（Type, Length, Value）形式で表し、メッセージＩＤに応じて必要なパラメータを連結したフォーマットで表現してよい。
【００３３】
図７にＷＧＳメッセージに利用されるパラメータの一覧を示す。図７に示すように、“Node ID”、“Response Status”、“Node Availability Info”、“User ID”、“Transaction ID”、“Filename”、“File Access Control”、“Fragment ID”、“Fragment Length”、“Fragment Offset”、“Fragment Data”、“Fragment CRC”、“Fragment Allocation Table”、“MIC”、および“Registoration Request”が存在する。
【００３４】
図７において、“Node Availability Info”は、ノードの可用性を示すパラメータであり、ノード確認部３１およびノード確認応答メッセージ送信部３２で重要な役割を果たすパラメータである。例えば、パソコンでノードを構成した場合、常にそのパソコンが電源ＯＮであり、かつネットワークに接続されているとは限らない。また、パソコンによっては、共有データを保存するスペースがない、あるいはＩＰ電話などリアルタイム性が要求されるようなアプリケーションを利用中である、あるいは他の重要な業務を実行中であり共有データの保存による影響を受けたくないなど、種々の状況がある。
【００３５】
“Node Availability Info”は、このような各ノードの状況を確認するための情報であり、図８に示すようなサブパラメータを組み合わせた情報で構成することができる。同表に示すように、“Node Availability Info”は、ノードやシステムの特徴に合わせて、ノードが提供する共有ディスクに関する情報だけでなく、そのノードでパソコンの利用者が利用しているソフトウェアのオペレーティングシステム名や、利用者のログインの状況、パソコンで動かしているプロセス（アプリケーション）の名前やその状態、メモリの使用率、CPU利用率、ネットワークデバイスの種類、ネットワークの種別（社内ＬＡＮ、無線ＬＡＮ、ケーブルモデム、ＡＤＳＬ，ＦＴＴＨ、携帯網など）などの情報を利用できる点が特徴である。
【００３６】
また、“File Name”は、元のデータのファイル名、若しくはファイルを識別するためのＩＤである。“File Access Control”は、ファイルに対する読み書きなどのパーミション（permission）情報である。“Fragment ID”は、分割したデータの識別子である。例えば、先頭のファイルから順に１，２，３，…とナンバリングされる。“Flagment Length”は、分割したデータのデータ長である。“Fragment Offset”は分割データの先頭バイトが元データにおいて何バイト目に当たるかを示すパラメータである。“Fragment Data”は実際の分割データである。“Fragment CRC”は分割データに対するパリティチェックシーケンスである。“Fragmento Allocation Table”は、分割したデータをどのノードに割り当てたかを示す表である。“MIC”はメッセージの完全性をチェックするためのＨＭＡＣダイジェストである。“Registration Request”は、“０ｘ０１”はグループ参加を示し、“０ｘＦＦ”グループからの離脱を示す。
【００３７】
以下、本ＷＧＳプロトコルで使用する各メッセージの概要を説明する。
【００３８】
［ノード確認要求メッセージ］  
図９にノード確認要求メッセージの例を示す。このノード確認要求メッセージは、共有データの保存、再構築の際、ノードの可用性を確認する（調べる）ためのメッセージである。同図に示すヘッダ部分のグループＩＤには、本ノードが属するグループＩＤを設定し、宛先ノードＩＤには個別のノードＩＤを設定してよい。グループ内の全てのノードに対して要求をだす場合には、宛先ノードＩＤを“0ｘFF”, “0ｘFF”, “0xFF”, “0xFF”としてもよい。また、メッセージＩＤフィールドには、ノード確認要求メッセージを示す値（0x01）がセットされる。
【００３９】
一方、コンテンツ部分には、“Node Availability Info”と呼ばれるパラメータがＴＬＶ形式で記述される。これは、図８に示した“Node Availability Info”パラメータの中でどのパラメータを必要（要求）しているか示すためのものである。例えば、この“Node Availability Info”フィールドに下記のような１４バイトの値を設定すれば、宛先ノードに対し、“Status”、“Shared Disk Availabile Size”、“User Login Status”の３つの情報を応答するよう要求していることを示している。どのパラメータを必要とするかは、ノードやシステムの特徴に合わせて動的に決めるようにしてもよいし、予めシステム管理者が定めて設定できるようにしてもよい。
【００４０】
“0x03 0x0C 0x01 0x01 0x00 0x03 0x04 0x00 0x00 0x00 0x00 0x08 0x01 0x00”  
最初のバイト“0x03”は、“Node Availability Info”のタイプを示す。2番目のバイト“0x0C”は、後に続くパラメータの長さが１２バイトであることを示す。３番目のバイト“0x01”は、“Status”を示す。４バイト目が“Status”フィールドのバイト数を示す。５バイト目がStatus値が“0x00”、６バイト目がサブタイプが“0x03”、すなわち“Shared Disk Available Size”を示し、７バイト目が“Shared Disk Available Size”のフィールド長が４バイト、８から１１バイトで値がゼロ、１２バイト目がサブタイプが０ｘ０８、すなわちUser Login Statusを示し、User Login Status フィールド長が１バイト、値が０を示している。
【００４１】
このように、各ノードの可用性を示すことができる種々あるパラメータから必要なパラメータを指定し、宛先ノードに問い合わせするのが特徴である。
【００４２】
なお、図９に示すように、発信ノードがメッセージを送る時に特定の番号を発番し、複数の応答メッセージを受信した場合に、応答メッセージがどの要求メッセージに対してのものか判断できるように、発番号した番号をTransaction IDとして本要求メッセージに含めてもよい。また、メッセージの改ざんなどを防ぐためにＨＭＡＣやＭＤ５などの計算値を示すＭＩＣ（Message Integration Check）パラメータに含んでもよい。
【００４３】
［ノード確認応答メッセージ］  
図１０にノード確認応答メッセージの例を示す。本メッセージは、ノード確認要求メッセージに対して各ノードが応答する際に使うメッセージである。同図に示すように、ヘッダ部分のメッセージＩＤフィールドに0x02がセットされる。また、ノード確認要求メッセージに対する応答ステータス（OKかNG）をResponse Statusフィールドにいれる。そして、OKの場合は、要求された“Node Availability Info”にあるパラメータに対応する自ノードの情報を示すNode Availiability  Infoとしてデータを作成し、本メッセージを使って応答する。たとえば、同図の例にあるように、下記のような１４バイトを設定した場合、について説明する。
【００４４】
0x03 0x0C 0x01 0x01 0x00 0x03 0x04  0x1E 0x84 0x80 0x00  0x08 0x01 0x01
“0x01 0x0C”：“Node Availability Info”
“0x01 0x01 0x00”：“Node Status”  （利用可）
“0x03 0x04 0x1E 0x84 0x80 0x00”：“Shared Disk Availabile Size”  （512Mバイト）
“0x08 0x01 0x01”：User Login Status  （ログイン中）
なお、応答メッセージにいれるTransaction IDは、ノード確認要求メッセージのTransaction IDを設定するようにしてよい。同様に、メッセージの改ざんなどを防ぐためにＨＭＡＣやＭＤ５などの計算値をＭＩＣ（Message Integration Check）パラメータに含んでもよい。
【００４５】
［分割データ配信メッセージ］  
図１１に分割データ配信メッセージの例を示す。本メッセージは、分割したデータを各ノードに配信するときに使うメッセージである。図１１に示すように、ヘッダ部分のメッセージＩＤフィールドに“0x03”がセットされる。また、コンテンツ部分には、元データのファイル名（またはファイルを識別するためのＩＤ）と元データのAccess Control情報が含まれ、その後にＭ個分の分割データ各々に対して、それぞれ、分割データのFragment  ID、  元データのどの部分であるかを示すFragment Offset、また分割データの長さを示すFragment Length、分割データを示すFdagment Data、およびFragment Data部分に関するＣＲＣ（Cyclic Redundancy Check）などの情報が含まれる。また、データの改ざんの有無を検出するための、ＨＭＡＣやＭＤ５などのＭＩＣ（Message Integration Check）の計算値を含めてもよい。
【００４６】
［分割データ割当リスト配信メッセージ］  
図１２に分割データ割当リスト配信メッセージの例を示す。本メッセージは、どのノードにどの分割データを配信したかを通知するためのメッセージである。図１２に示すように、ヘッダ部分のメッセージＩＤフィールドに0x04がセットされる。グループ内の全てのノードに対して通知する場合には、ヘッダ部分の宛先ノードＩＤを0ｘFF, 0ｘFF, 0xFF, 0xFFとしてもよい。また、Contents部分には、元データのファイル名（またはファイルを識別するためのID）と元データのAccess Control情報が含まれ、またN個分の分割データ各々に対してそれぞれ、分割データのFragment ID、元データのどの部分であるかを示すFragment Offset、また分割データの長さを示すFragment Length、当該分割データをどこのノードに割り当てたか（保存したか）を示すNode ID、およびFragment Data部分に関するCRC（Cyclic Redundancy Check）の情報が含まれる。また、同図にあるいように、データの改ざんの有無を検出するための、ＨＭＡＣやＭＤ５などのアルゴリズムを用いて計算した値をＭＩＣ（Message Integration Check）として含めてもよい。
【００４７】
［分割データ割当リスト要求メッセージ］  
図１３に分割データ割当リスト要求メッセージの例を示す。本メッセージは、新たに起動したノードやファイルを読みだそうとしたノードが、他ノードに対して分割データ割り当てリストを要求する際に使われる。オプションフィールドにNode IDがある場合は、そのNode が保持している分割データのリストを要求していることを示す。また、オプションフィールドにFragment IDが指定された場合には、そのNodeが保持している分割データのうちFragment IDで指定されている分割データがあるか問い合わせることを意味する。
【００４８】
また、発信ノードがメッセージを送る時に特定の番号を発番し、複数の応答メッセージを受信した場合に、応答メッセージがどの要求メッセージに対してのものか判断できるように、発番号した番号をTransaction IDとして本要求メッセージに含めてもよい。
【００４９】
［分割データ割当リスト応答メッセージ］  
図１４に分割データ割当リスト応答メッセージの例を示す。本メッセージは、分割データ割り当てリスト要求メッセージに対する応答メッセージである。同図に示すように、メッセージＩＤが“0x06”となる。また、基本的な構造は分割データ割当リスト配信メッセージを同じである。しかし、分割データ割当リストはＮ分割されたデータＮ個分の割り当て情報が含まれるのに対し、本メッセージは部分的な分割データの割り当て情報が含まれる点が異なる。
【００５０】
［分割データ転送要求メッセージ］  
図１５に分割データ転送要求メッセージの例を示す。本メッセージは、他のノードに対し分割データの送信を要求するために使われる。同図に示すように、メッセージＩＤが０ｘ０７となる。また、コンテンツ部分には、元データのファイル名（またはファイルを識別するためのID）が含まれる。さらに、同図の例にあるように、オプションフィールドにFragment IDが指定された場合には、そのNodeが保持している分割データのうちFragment IDで指定して、送信を要求することができる。
【００５１】
［分割データ転送応答メッセージ］  
図１６に分割データ転送応答メッセージの例を示す。本メッセージは、分割データ転送要求メッセージに対する応答する際につかうメッセージである。同図に示すように、メッセージＩＤが０ｘ０８となる。また、コンテンツ部には、前記分割データ転送の要求に対する応答ステータスをResponse Statusがあり、
Response StatusがOKの場合、同図にあるように、データのファイル名（またはファイルを識別するためのID）と元データのAccess Control情報が含まれ、またM個分の分割データ各々に対してそれぞれ、分割データのFragment ID、 元データのどの部分であるかを示すFragment Offset、また分割データの長さを示すFragment Length、分割データを示すFdagment Data、およびFragment Data部分に関するＣＲＣ（Cyclic Redundancy Check）の情報が含まれる。また、同図にあるいように、データの改ざんの有無を検出するための、ＨＭＡＣやＭＤ５などのＭＩＣ（Message Integration Check）の計算値を含めてもよい。一方、要求された分割データが自ノードが保持していない場合などエラー時には、Response Statusに“ＮＧ”をいれて応答する。
【００５２】
なお、応答メッセージにいれるTransaction IDは、ノード確認要求メッセージのTransaction IDを設定するようにしてよい。同様に、メッセージの改ざんなどを防ぐためにＨＭＡＣやＭＤ５などの計算値をＭＩＣ（Message Integration Check）パラメータに含んでもよい。
【００５３】
［グループ登録要求メッセージ］  
図１７にグループ登録要求メッセージの例を示す。本メッセージは、新たにグループメンバーになる場合、あるいはグループから離脱する場合に、ノードが送信するメッセージである。新たにグループメンバーに参加登録する場合、自ノードで一意にTransaction IDを定め、Registration Requestの値を“0x01”とし、グループから離脱する場合には、“0xFF”とする。
【００５４】
グループＩＤは、予めシステムで決められているＩＤであり、管理者から入手したり、他のメンバーから入手することができる。また、グループウェア等のアプリケーションで自動的に入手するなど、本発明の範囲外で情報が入手できる。グループへ参加する場合は、宛先ノードＩＤを“0xFF”, “0ｘFF”, “0xFF”, “0xFF”とし、ブロードキャストして送信してもよい。本メッセージ送信後は、本メッセージに対する応答を待つ。
【００５５】
［グループ登録応答メッセージ］  
図１８にグループ登録応答メッセージの例を示す。本メッセージは、前記グループ登録要求に対する応答を返すために使われる。同図に示すように、Transaction IDの後、Responseステータスで“ＯＫ”か“ＮＧ”が応答が返される。このメッセージを送信するのは、予めマスターとして設定されたノードである。
【００５６】
次に、ノード間の相互作用について図面をつかって説明する。  
図１９にデータ保存時の動作シーケンス例を示す。図１９は、ノード１がデータを作成し、ノード２〜８にそのデータを分散して保存する例を示している。図１９に示すように、ノード１のノード確認部３１は、ノード２〜８に対しノード確認要求メッセージを送信する。ノード２〜８のノード確認応答メッセージ送信部３２は各々自分の可用性をチェックし、ノード１に対してノード確認応答メッセージを送信する。ノード１の分散保存設定部３３は、ノード２〜８のノード確認応答メッセージを受信すると、データの分割数Ｎおよび多重度数Ｍを決定し、どのノードにどの分割データを割り当てるか決定する。その後、分散保存設定部３３が分割データ配信メッセージをつかってデータを配信する。分割データは、下位の層にＴＣＰなどのトランスポートプロトコルをつかって配信され、途中にパケットロスなどが発生した場合は自動的にパケットの再送が行われる。分割データ配信の途中でネットワークから離脱などの理由で配信に失敗し失敗したノード数をチェックし、失敗したノード数が所定の数（例、Ｍ−１）を超える場合、配信をキャンセルして、もう一度元データの分割数Nおよび多重度数Ｍを変更して、再度配信しなおす。
【００５７】
上述した分割データ配信が終わると分散保存部３４は、分散保存設定部３３が生成した、どのノードにどの分割データを配信したかを示す分割データ割当リストメッセージを他のノードに送信する。
【００５８】
図２０にデータ復元時の動作シーケンス例を示す。同図は、ノード１がデータを復元する時、ノード３、ノード５、ノード６がネットワーク９に接続されていなかった例を示している。まず、ノード１は他の全てのノードに対し、ノード確認要求を送信する。各ノードはノード確認応答メッセージに自ノードの可用性を示すパラメータを入れてノード１に送信する。ノード１の分割データ収集部３５は、各ノードからのノード確認応答メッセージを受信すると、どのノードからデータを集めるか決定し、選んだノードに対し分割データ転送要求を送信する。図２０の例では、ノード１は分割データＡ，Ｂ，Ｃ，Ｄを自ノードに保存しているため、自ノードが保存していない分割データＥ，Ｆ，Ｇ，Ｈのうち、最も保持しているノード４にまず分割データ転送要求を出した。その後、分割データＨは、ノード７とノード８の可用性を比較し、可用性の値が高かったノード７に対して分割データ転送要求を出した。このように、分割データを収集して元データを復元する際に、各ノードが持っている分割データの組み合わせや利用可能性に応じて最適なノードを決定する点が特徴である。
【００５９】
なお、図２０では、マスターであるノード１が分割データを収集し、元のデータに復元する例を示したが、他のノード２〜８が分割データを収集し、元のデータに復元しても良い。
【００６０】
以上、本システムの原理やノード間のメッセージのやり取りを説明したが、以下、本システムの具体的な適用例を具体的に説明する。
【００６１】
［第１実施例：ワークグループ型ファイル共有システム］  
図２１に本発明の第１実施例に係わるパソコンの構成の一例、図２２に本発明の第１実施例に係わるワークグループ型ファイル共有システムの一例を示す。図２１に示すように、本共有ファイルシステムで利用するパソコン１００は、ハードウェア１０１上で動作する仮想マシンモニタ１１１を搭載し、ソフトウェアリソース１１０がユーザ・パーティション１３０とサービス・パーティション１２０とに分けられている。ユーザ・パーティション１３０は、ユーザＯＳ１３１、ユーザが利用するアプリケーションプログラム１３２、およびユーザデータ１３３を有する。サービス・パーティション１２０は、サービスＯＳ１２１、共有ファイルシステムプログラム１２２、および共有データ１２３を有する。ユーザが利用する部分とグループで共有する部分を完全に分けているのが特徴である。また、サービスＯＳ１２１は、ユーザ・パーティション１３０からサービス・パーティション１２０内の共有データ１２３等の資源に直接アクセスすることを禁止する。仮想マシンモニタ１１１は、１台のＰＣのハードウェアリソースを複数の仮想マシン１２０，１３０が共有し、同時に稼動するための機能を提供するソフトウェアである。
【００６２】
共有ファイルシステムプログラム１２２は、ノード確認部３１、ノード確認応答メッセージ送信部３２、分散保存設定部３３、分散保存部３４、分割データ収集部３５、データ復元部３６、認証処理部３７、および分割データ転送部３８を含むプログラムである。
【００６３】
なお、ユーザ・パーティション１３０上には、エージェントソフトウェア１３２Ａが動作している。エージェントソフトウェア１３２Ａは、ユーザＯＳ１３１のバージョンやユーザが利用中のアプリケーション（プロセス）の情報を調べることができる。そして、エージェントソフトウェア１３２Ａは、サービス・パーティション１２０上で稼働する共有ファイルシステムプログラム１２２からの問い合わせに対し、上述したユーザＯＳ１３１上の可用性情報を応答する可用性情報応答機能を備えている。また、共有ファイルシステムプログラム１２２は、このエージェントソフトウェアの可用性情報応答機能を利用し、前述したノード確認応答メッセージを作成する。このようにすることで、パソコンで動作しているアプリケーションの情報に応じて、利用者への影響を考慮したワークグループ型ファイル共有システムを実現することができる。
【００６４】
また、例えばＮ人のメンバーで構成される業務上のグループにおいて、各メンバーが所有するパソコンＮ台をつかって、グループ内で共有するようなデータ（例えば会議録や仕事で利用する電子ファイルなど）をＭ重に分散して保存し、データを共有するものである。
【００６５】
例えば、Ｎ＝８、Ｍ＝４とし、各メンバーが、各パソコンのサービス・パーティション１２０のハードディスク（Ｂ＝１Ｇバイト）をグループのデータ共有のために提供するようにしてもよい。このようにすると、各メンバーから提供されたハードディスクを集め、最大Ｃ＝Ｎ×Ｂ／Ｍ＝８×１／４＝２ＧＢの仮想共有ディスク２０１を有する仮想サーバ２００を構成するとこができる。
【００６６】
そして、図２２に示すように、会議等などで８名がパソコン１〜８を持ち合って出席した会議の場で、互いのパソコンで共通の仮想共有ディスク２０１内の電子ファイルを参照しながら業務を進め、会議の途中や会議が終わった段階で、会議で利用した電子ファイルを８人のメンバーのパソコン１〜８に分散して保存する。また、後日、８名のうち５名のメンバーが集まって各自のパソコンを持ち寄ると、保存された資料を復元することができる。
【００６７】
また、本実施例によると、分散保存後、分散情報を保有するパソコンが（Ｍ＋１）台集まらないと、元の情報を復元できないため、仮に８台のうち１台を盗難にあったり、紛失した場合であっても、保存した情報の漏洩心配がなくなるというメリットがある。また、利用者がユーザパーティション上のアプリケーションを利用中に誤ってウイルスに感染しても、まず共有ファイルはサービス・パーティション１２０上にあるので、共有ファイルにある機密情報の情報漏えいを防ぐことができる。さらに、上述したようにサービスパーティション側の共有ファイルの情報が漏えいしても、そこにあるのは分割されたデータであるため機密性を高めることができる。なお、このような機密性は従来のＰ２Ｐ（peer to peer）型のファイル共有ソフトウェアでは実現されていない。
【００６８】
このように、本実施例によれば、特別なサーバ機やファイルサーバを必要せず、各自のパソコンをつかってファイル共有することができる。また、業務上のグループ（ワークグループ）においてメンバーで共通して利用する電子ファイルやデータを機密性を高めると共に、可用性の高いワークグループ型のファイル共有システムを提供することができる。
【００６９】
また、参加者のノード（パソコン）の可用性や元データの機密度に応じて、前記Ｎ、Ｍのパラメータを適応的に変更してもよい。例えば、会議の参加者が８人居て、次回の会議では３名程度欠席する恐れがあるような場合、図３，４の例のようにＮ＝８，Ｍ＝４とすればよい。一方、次回の会議では１名程度欠席する恐れがある場合には、Ｎ＝８，Ｍ＝２とすればよい。
【００７０】
また、例えば、メンバーの過半数以上が実際に参加しなければならないようなルールが定められているような会議などで、事前に会議の資料（データ）を８人のメンバーに４重に分散して配布しておき、会議が始まって５人以上のメンバーが集まると、事前に送付した会議の資料（データ）を開くことができるようにしてもよい。このようにすれば、参加メンバーが足りないと会議の資料を開くことができないため、ルールに反して資料を変更することができないようになる。
【００７１】
［第２実施例：サーバ機のバックアップ］
中小企業や大企業の部門や拠点に設置されるような部門サーバの定期保守などで、一時的にデータをバックアップし、物理的に他の場所に退避しておかなければならない場合がある。しかし、部門に導入されている他のサーバのハードディスクの空き容量が少ないなどの理由でバックアップするデータの保管（置き）場所を用意できない場合がある。
【００７２】
本実施例は、上述した問題を解決することにも利用できる。図２３に示すように、部門のネットワークに接続されているＮ台のパソコンが空きハードディスクの一部を提供する。そして、サーバ３００の物理ディスク３０１内のバックアップするべきデータをＮ分割し、Ｎ台のパソコンにＭ重にシーケンシャルに分散して保存する。このようにすれば、定期保守などの作業が終わって、Ｎ台中のパソコンのうち（Ｎ−Ｍ＋１）台のパソコンがそろっていればよいなど、サーバ機の運用管理業務を支援することができる。
【００７３】
［第３実施例：複数サーバ機によるフェイルオーバ］
大手企業のＩＴセンターやインターネット上でサービスを提供するデータセンター等では、複数のサーバと、前記複数のサーバがデータやメモリを共有するための共有ディスク装置を用意して、サーバの故障時や定期保守などの場合にフェイルオーバ（代わりの別のサーバにサービスの処理やデータが引き継ぐ）機能が要求される。本実施例を利用すれば、図２４に示すように、Ｎ台のサーバ（又はパソコン）１〜８がディスクを提供して仮想的な共有ディスクを構成して、複数の仮想サーバにＭ重に分散して置いておくことができる。
【００７４】
このようにすれば、正サーバ４００と同時に任意のＭ−２台のサーバが突然故障しても、残りの（Ｎ−Ｍ＋１）台のサーバ１〜８によってデータが保全される。（Ｎ−Ｍ＋１）台のサーバ１〜８、いずれかが引き継ぐことによってサービスの中断を防ぐことができるようになる。なお、（Ｎ−Ｍ＋１）台のサーバ１〜８でサーバ４００のサービスを代行すると、パフォーマンスが落ちるおそれがある。しかし、そして、新サーバ４０１をネットワークに接続し、（Ｎ−Ｍ＋１）台のサーバ１〜８からデータを新サーバ４０１に格納することによって、旧サーバ４００でのサービスのパフォーマンスと同等以上のパフォーマンスを得ることが出来る。
【００７５】
［第４実施例：機密情報のアクセス制御］
元の情報をＮ分割し、分割したＮ個の分割情報をＭ個ずつＮ台のノードに分散して保存した場合、（Ｎ−Ｍ＋１）台以上のノードが集まれば、元の情報を復元できるという原理に着目すると、分散型の認証システムに利用できる。
【００７６】
例えば、社内で使う特定の機密情報に関して、第１実施例で説明したように機密情報自体を分割するのではなく、機密情報を暗号化に用いた暗号鍵のデータをＮ個に分割し、Ｎ台の情報処理装置（パソコン、ＵＳＢメモリ、ハードディスクなど）にＭ重に分散して保存するようにしてもよい。そして、社員が暗号化された機密情報を復号して読み出すためには、（Ｎ−Ｍ＋１）台以上の情報処理装置（パソコン、ＵＳＢメモリ、ハードディスクなど）から暗号鍵の分割データを入手しなければならないようにしてもよい。このようにすれば、機密情報に対するセキュリティレベルを高めることができるようになる。
【００７７】
なお、上述したシステムにおいて、マスターとして設定されているノードがネットワークから離脱する場合、例えば予め設定された順位に従ってマスターの役割を受け渡す。また、離脱する前のマスターとして設定されているノードが “Node Availability Info”から負荷の低いノードを探し、負荷が最も低いノードにマスターの役割を受け継がせるようにしても良い。
【００７８】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【図面の簡単な説明】
【００７９】
【図１】本発明の一実施形態に係わる情報通信システムの構成を示す図。
【図２】図１に示すノードの構成を示すブロック図。
【図３】データを８分割して、各分割データを８個のノードに４重に分散して保存する例を示す図。
【図４】３つのノードがネットワークに接続されていない状態で、元のデータを復元する例を示す図。
【図５】ＷＧＳプロトコルメッセージの基本フォーマットの一例を示す図。
【図６】図５に示すメッセージＩＤの一例を示す図。
【図７】ＷＧＳメッセージに利用されるパラメータの一覧の一例を示す図。
【図８】“Node Availability Info”を構成するサブパラメータの一例を示す図。
【図９】ノード確認要求メッセージの一例を示す図。
【図１０】ノード確認応答メッセージの一例を示す図。
【図１１】分割データ配信メッセージの一例を示す図。
【図１２】分割データ割当リスト配信メッセージの一例を示す図。
【図１３】分割データ割当リスト要求メッセージの一例を示す図。
【図１４】分割データ割当リスト応答メッセージの一例を示す図。
【図１５】分割データ転送要求メッセージの一例を示す図。
【図１６】分割データ転送応答メッセージの一例を示す図。
【図１７】グループ登録要求メッセージの一例を示す図。
【図１８】グループ登録応答メッセージの一例を示す図。
【図１９】データ保存時の動作シーケンスの一例を示す図。
【図２０】データ復元時の動作シーケンスの一例を示す図。
【図２１】第１実施例に係わるパソコンの構成の一例を示すブロック図。
【図２２】第１実施例に係わるワークグループ型ファイル共有システムの一例を示す図。
【図２３】第２実施例に係わるワークグループ型ファイル共有システムの一例を示す図。
【図２４】第３実施例に係わるワークグループ型ファイル共有システムの一例を示す図。
【符号の説明】
【００８０】
３１…ノード確認部，３２…ノード確認応答メッセージ送信部，３３…分散保存設定部，３４…分散保存部，３５…分割データ収集部，３６…データ復元部，３７…認証処理部，３８…分割データ転送部，１００…パソコン，１０１…ハードウェア，１１０…ソフトウェアリソース，１１１…仮想マシンモニタ，１２０…サービス・パーティション，１２０．１３０…仮想マシン，１２１…サービスＯＳ，１２２…共有ファイルシステムプログラム，１２３…共有データ，１３０…ユーザ・パーティション，１３１…ユーザＯＳ，１３２…アプリケーションプログラム，１３２Ａ…エージェントソフトウェア，１３３…ユーザデータ。
【図１】
2009037318.tif 000003
【図２】
2009037318.tif 000004
【図３】
2009037318.tif 000005
【図４】
2009037318.tif 000006
【図５】
2009037318.tif 000007
【図６】
2009037318.tif 000008
【図７】
2009037318.tif 000009
【図８】
2009037318.tif 000010
【図９】
2009037318.tif 000011
【図１０】
2009037318.tif 000012
【図１１】
2009037318.tif 000013
【図１２】
2009037318.tif 000014
【図１３】
2009037318.tif 000015
【図１４】
2009037318.tif 000016
【図１５】
2009037318.tif 000017
【図１６】
2009037318.tif 000018
【図１７】
2009037318.tif 000019
【図１８】
2009037318.tif 000020
【図１９】
2009037318.tif 000021
【図２０】
2009037318.tif 000022
【図２１】
2009037318.tif 000023
【図２２】
2009037318.tif 000024
【図２３】
2009037318.tif 000025
【図２４】
2009037318.tif 000026