(57)【要約】【課題】ストレージデバイスなどのデバイスをネットワーク上のクライアントＰＣで共用する場合、サーバ側の処理負荷を低減するとともに、ユーザに手動操作を強いることなく、必要なときだけデバイスにアクセスするように制御する手段を提供する。【解決手段】クライアントＰＣからサーバにセッション開始要求を送ってセッションを接続し、セッション接続中は、クライアントＰＣが生成する第一の制御コマンドをサーバに送ってデバイスとの間でデータの入出力を行うと共に、第二の制御コマンドを定期的に生成してサーバに送ってセッションの接続状態を確認し、第二の制御コマンドに対する応答が所定条件を満たすと、サーバとの間のセッションを切断し、セッション切断後、クライアントＰＣは、定期的に生成する第二の制御コマンドをサーバに送らず、該第二の制御コマンドに対する応答を擬似的に生成し、上位層に通知する。【選択図】図８
2010097492.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してサーバに接続されたデバイスとの間でデータの入出力を行うクライアントであって、
前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層と、
前記上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成手段と、
前記制御コマンド生成手段で生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御手段と、
を備え、
前記セッション制御手段は、
前記制御コマンド生成手段によって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求手段と、
当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始手段と、
前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力手段と、
前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認手段と、
前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断手段と、
当該セッションの切断後、前記制御コマンド生成手段で生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答手段
とから構成されることを特徴とするクライアント。
【請求項２】
前記セッション開始要求手段は、前記セッションの切断後、前記制御コマンド生成手段で生成される制御コマンドが前記第一の制御コマンドである場合、前記サーバに対してセッション開始要求を送ること
を特徴とする請求項１に記載のクライアント。
【請求項３】
前記所定条件とは、前記第二の制御コマンドに対する成功応答が規定回数連続したか否かであること
を特徴とする請求項１に記載のクライアント。
【請求項４】
前記所定条件とは、前記第二の制御コマンドに対する成功応答が規定時間連続したか否かであること
を特徴とする請求項１に記載のクライアント。
【請求項５】
前記第一の制御コマンドは、前記デバイスとの間でデータの入出力を行うためのコマンドであり、前記第二の制御コマンドは、前記デバイスが利用可能か否かを確認するためのコマンドであること
を特徴とする請求項１に記載のクライアント。
【請求項６】
前記セッション制御手段は、前記所定条件を変更するための所定条件変更手段を更に有すること
を特徴とする請求項１に記載のクライアント。
【請求項７】
前記セッション接続状態確認手段は、他のクライアントからのセッション開始要求の有無を前記サーバから受信し、前記所定条件変更手段は、当該セッション開始要求の有無に応じて前記所定条件を変更すること
を特徴とする請求項６に記載のクライアント。
【請求項８】
デバイスと、サーバと、ネットワークを介して前記サーバに接続された前記デバイスとの間でデータの入出力を行うクライアントから構成されるデバイス共有システムにおいて、
前記クライアントは、
前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層と、
前記上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成手段と、
前記制御コマンド生成手段で生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御手段と、
を備え、
前記セッション制御手段は、
前記制御コマンド生成手段によって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求手段と、
当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始手段と、
前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力手段と、
前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認手段と、
前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断手段と、
当該セッションの切断後、前記制御コマンド生成手段で生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答手段
とで構成されることを特徴とするデバイス共有システム。
【請求項９】
前記クライアントは、前記セッション開始要求手段によって、前記セッションの切断後、前記制御コマンド生成手段で生成される制御コマンドが前記第一の制御コマンドである場合、前記サーバに対してセッション開始要求を送ること
を特徴とする請求項８に記載のデバイス共有システム。
【請求項１０】
前記所定条件とは、前記第二の制御コマンドに対する成功応答が規定回数連続したか否かであること
を特徴とする請求項８に記載のデバイス共有システム。
【請求項１１】
前記所定条件とは、前記第二の制御コマンドに対する成功応答が規定時間連続したか否かであること
を特徴とする請求項８に記載のデバイス共有システム。
【請求項１２】
前記第一の制御コマンドは、前記デバイスとの間でデータの入出力を行うためのコマンドであり、前記第二の制御コマンドは、前記デバイスが利用可能か否かを確認するためのコマンドであること
を特徴とする請求項８に記載のデバイス共有システム。
【請求項１３】
前記デバイスは、ストレージデバイスであること
を特徴とする請求項８に記載のデバイス共有システム。
【請求項１４】
前記クライアントのセッション制御手段は、前記所定条件を変更するための所定条件変更手段を更に有すること
を特徴とする請求項８に記載のデバイス共有システム。
【請求項１５】
前記クライアントは、前記セッション接続状態確認手段によって、他のクライアントからのセッション開始要求の有無を前記サーバから受信し、前記所定条件変更手段によって、当該セッション開始要求の有無に応じて前記所定条件を変更すること
を特徴とする請求項１４に記載のデバイス共有システム。
【請求項１６】
前記サーバは、セッション接続中でないクライアントからのセッション開始要求の有無の情報を管理し、前記第二の制御コマンドに対する応答に当該セッション開始要求の有無の情報を付加してセッション接続中のクライアントに送ること
を特徴とする請求項８に記載のデバイス共有システム。
【請求項１７】
前記サーバは、前記クライアントから送られてくる前記第一の制御コマンド及び前記第二の制御コマンドのパケットのヘッダを取り外して前記デバイスに送り、又、前記デバイスからの応答のパケットに対してヘッダを付加して前記クライアントへ送ること
を特徴とする請求項８に記載のデバイス共有システム。
【請求項１８】
ネットワークを介してサーバに接続されたデバイスをクライアントによって共有するデバイス共有方法であって、
前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成ステップと、
前記制御コマンド生成ステップで生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御ステップと、
を実行し、
前記セッション制御ステップでは、
前記制御コマンド生成ステップによって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求ステップと、
当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始ステップと、
前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力ステップと、
前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認ステップと、
前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断ステップと、
当該セッションの切断後、前記制御コマンド生成ステップで生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答ステップ
を実行することを特徴とするデバイス共有方法。
【請求項１９】
前記セッション開始要求ステップは、前記セッションの切断後、前記制御コマンド生成手段で生成される制御コマンドが前記第一の制御コマンドである場合、前記サーバに対してセッション開始要求を送るステップを実行すること
を特徴とする請求項１８に記載のデバイス共有方法。
【請求項２０】
前記セッション切断ステップの所定条件とは、前記第二の制御コマンドに対する成功応答が規定回数連続したか否かであること
を特徴とする請求項１８に記載のデバイス共有方法。
【請求項２１】
前記セッション切断ステップの所定条件とは、前記第二の制御コマンドに対する成功応答が規定時間連続したか否かであること
を特徴とする請求項１８に記載のデバイス共有方法。
【請求項２２】
前記セッション制御ステップは、更に、前記所定条件を変更する所定条件変更ステップを有すること
を特徴とする請求項１８に記載のデバイス共有方法。
【請求項２３】
前記セッション接続状態確認ステップにおいて、他のクライアントからのセッション開始要求の有無を前記サーバから受信するステップを更に実行し、前記所定条件変更ステップによって、当該セッション開始要求の有無に応じて前記所定条件の変更を実行すること
を特徴とする請求項２２に記載のデバイス共有方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してデバイスを共有する機能を備えたシステム、クライアント、およびその制御方法に関するものである。
【背景技術】
【０００２】
ネットワークの普及により、従来、パーソナルコンピュータ（ＰＣ）などにローカル接続して利用していたデバイス（周辺機器）をネットワーク上のクライアントＰＣから利用できるように工夫したデバイスサーバが発表されている。
【０００３】
その中でもストレージデバイスを、ネットワーク上のクライアントＰＣからデバイスサーバを介して共有ストレージとして利用可能とするための実現方法がいくつか提案されている。
【０００４】
ひとつの実現方法として、クライアントＰＣのオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ；以下、ＯＳ）に対して、ネットワークに接続されているストレージとして認識させる方法がある。
【０００５】
この方法では、ＳＭＢ（Ｓｅｒｖｅｒ  Ｍｅｓｓａｇｅ  Ｂｌｏｃｋ）プロトコルを用いてデバイスサーバに排他制御やセッション管理の仕組みを備えることで、複数のクライアントＰＣから１台のストレージに対してファイルアクセスを可能としている。
【０００６】
しかしながら、デバイスサーバにＳＭＢプロトコルを実装する必要があるため、デバイスサーバ側の処理負荷が高くなり、高速なＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）や大容量のメモリが必要となり、デバイスサーバが高価となってしまう問題がある。
【０００７】
また、別の実現方法として、クライアントＰＣのＯＳに対して、ローカル接続されているストレージとして仮想的に認識させる方法がある。
【０００８】
この方法では、クライアントＰＣに専用のアプリケーションソフトウェア（ユーティリティ）を導入しておき、ユーザがストレージにアクセスしようとするときにユーティリティを操作し、クライアントＰＣに対してローカル接続したストレージとして仮想的に認識させることで、ネットワーク上のクライアントＰＣから、ローカル接続した状態と同様にファイルアクセスできるようにしている。
【０００９】
図１４は、クライアントＰＣに導入したユーティリティをユーザが操作し、ストレージとのセッション接続の開始・切断を行う場合の基本的な動作を示すフローチャートである。
【００１０】
まず、ストレージを使用するとき、クライアントＰＣとストレージは接続状態でないため、クライアントＰＣのユーティリティを起動する。ユーティリティが起動すると、ユーザ操作によるストレージの使用開始待ちの状態となる（ステップＳ１４０１）。
【００１１】
そして、ユーザがクライアントＰＣのユーティリティを操作し、ストレージの接続操作を実行すると、クライアントＰＣからデバイスサーバに対してセッション開始要求が送られる（ステップＳ１４０２）。
【００１２】
デバイスサーバとの間でセッションが開始されると（ステップＳ１４０３でＹｅｓ）、ストレージへのアクセスが可能となり（ステップＳ１４０４、Ｓ１４０５）、ユーザによるストレージの切断操作が実行されない限り（ステップＳ１４０６でＮｏ）、繰り返しストレージへのアクセスが行われる。
【００１３】
一方、デバイスサーバとの間でセッションが開始できない場合（ステップＳ１４０３でＮｏ）、ストレージにはアクセスできないことになる（ステップＳ１４１０）。
【００１４】
ストレージに対するアクセスが終了すると、ユーザがクライアントＰＣのユーティリティを操作してストレージの切断操作を実行する。
【００１５】
ストレージに対する切断操作が実行されると（ステップ１４０６でＹｅｓ）、クライアントＰＣからデバイスサーバに対してセッション終了要求が送られ（ステップＳ１４０７）、デバイスサーバとの間のセッションが切断され、ストレージへのアクセスが終了となる（ステップＳ１４０８、Ｓ１４０９）。
【００１６】
図１５は、図１４のフローチャートに基づいて動作するクライアントＰＣ（ＰＣ１，ＰＣ２）が複数台でストレージにアクセスするときの過程を示したタイミングチャートである。
【００１７】
まず、ＰＣ１によってストレージにアクセスを開始するとき、ユーザは、ＰＣ１のユーティリティによりセッションの開始操作を行う。
【００１８】
セッションの開始操作が行われると、ＰＣ１は、デバイスサーバに対してセッション開始要求を送り、セッションが開始されると、デバイスサーバを介してストレージにアクセスすることが可能となる。
【００１９】
続いて、ストレージにアクセスするため、ＰＣ１からデバイスサーバに対して制御コマンドを送ると、デバイスサーバを介してストレージへのデータの読み書きを実行することができる。
【００２０】
ＰＣ１とデバイスサーバがセッション接続中は、ＰＣ１にセッションが専有されているため、ＰＣ２からストレージにアクセスすることができない。
【００２１】
ＰＣ１によるアクセスが終了したら、ユーザは、ＰＣ１のユーティリティを操作してセッションの切断操作を実行する。
【００２２】
セッションの切断操作が実行されると、ＰＣ１からデバイスサーバに対してセッション終了要求が送られ、デバイスサーバとの間でセッションの切断処理を行い、ストレージへのアクセスが終了となる。
【００２３】
ここで、ユーザがＰＣ２のユーティリティによりセッションの開始操作を行うと、ＰＣ２からストレージへのアクセスが開始される。
【００２４】
このように、ユーティリティを使ってセッションの開始・切断を行うことによって、複数のクライアントＰＣからストレージを共有することができる。
【００２５】
しかし、この方法では、ユーザによるセッションの開始・切断操作が必要であり、クライアントＰＣがストレージにデータを読み書きしていない間（実際にアクセスしていない間）もセッションが維持されているため、ユーザがセッションを切断しない限り、他のクライアントＰＣがストレージを使用することができないという問題が生じる。
【００２６】
かかる問題を解決するために、ブロックヘッダで特定されるデータ長のブロックデータが伝送される間だけ、特定のクライアントＰＣによるデータ伝送専有状態として、当該クライアントＰＣとストレージとの間のデータ伝送を許可するデバイスサーバを用いたネットワークファイル管理システムが開示されている。（特許文献１参照）
【００２７】
【特許文献１】特開２００７−３１７０６７号公報
【発明の開示】
【発明が解決しようとする課題】
【００２８】
しかし、特許文献１に開示されたネットワークファイル管理システムでは、ストレージが使用されない無駄な空白時間を発生させることなしに複数のクライアントＰＣからストレージを共有することはできるものの、複数のクライアントＰＣからのアクセス要求が常にネットワーク上を行き交うことでトラフィック量が増大化するという問題が発生する。
【００２９】
しかも、多数のアクセス要求を処理し、特定のクライアントＰＣに対するデータ伝送専有状態の設定・解除を制御するために、デバイスサーバには高い処理性能が要求されるため、上述したＳＭＢプロトコルを用いて実現する方法と同様、デバイスサーバの高価格化は避けられない。
【００３０】
上記問題に鑑みて、本発明は、ストレージなどのデバイス（周辺機器）をネットワーク上のクライアントＰＣで共用する場合、サーバ側の処理負荷を低減するとともに、ユーザに手動操作を強いることなく、必要なときだけデバイスにアクセスするように制御する手段を提供することを目的とする。
【課題を解決するための手段】
【００３１】
上記目的を達するために、請求項１に記載のクライアントは、ネットワークを介してサーバに接続されたデバイスとの間でデータの入出力を行うクライアントであって、前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層と、前記上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成手段と、前記制御コマンド生成手段で生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御手段と、を備え、前記セッション制御手段は、前記制御コマンド生成手段によって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求手段と、当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始手段と、前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力手段と、前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認手段と、前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断手段と、当該セッションの切断後、前記制御コマンド生成手段で生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答手段とから構成されることを特徴とする。
【００３２】
上記目的を達するために、請求項８に記載のデバイス共有システムは、デバイスと、サーバと、ネットワークを介して前記サーバに接続された前記デバイスとの間でデータの入出力を行うクライアントから構成されるデバイス共有システムにおいて、前記クライアントは、前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層と、前記上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成手段と、前記制御コマンド生成手段で生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御手段と、を備え、前記セッション制御手段は、前記制御コマンド生成手段によって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求手段と、当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始手段と、前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力手段と、前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認手段と、前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断手段と、当該セッションの切断後、前記制御コマンド生成手段で生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答手段とで構成されることを特徴とする。
【００３３】
上記目的を達するために、請求項１８に記載のデバイス共有方法は、ネットワークを介してサーバに接続されたデバイスをクライアントによって共有するデバイス共有方法であって、前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成ステップと、前記制御コマンド生成ステップで生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御ステップと、を実行し、前記セッション制御ステップでは、前記制御コマンド生成ステップによって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求ステップと、当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始ステップと、前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力ステップと、前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認ステップと、前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断ステップと、当該セッションの切断後、前記制御コマンド生成ステップで生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答ステップを実行することを特徴とする。
【発明の効果】
【００３４】
本発明によれば、クライアントＰＣに対して、ネットワーク上のデバイスサーバに接続されているデバイスをローカル接続したデバイスとして認識させるとともに、デバイスにアクセスするときだけ、クライアントＰＣとデバイスサーバ間のセッションを接続することができる。
【００３５】
これにより、ネットワーク上でデバイスを共有する際、ＳＭＢプロトコルや特許文献１に開示された処理機能をデバイスサーバへ組み込む必要が無くなるため、デバイスサーバの負荷が軽減され、安価なネットワークシステム構成で複数のクライアントＰＣからデバイスを共有することが可能となる。
【００３６】
また、クライアントＰＣに対してデバイスが常に接続された状態として認識させることにより、クライアントＰＣのユーティリティなどで手動操作して行っていたセッションの開始、切断の操作が不要となり、デバイスがネットワーク環境にあることを意識せずに使用することが可能となる。
【発明を実施するための最良の形態】
【００３７】
以下、本発明の第一の実施の形態について図面を参照して詳細に説明する。
【００３８】
図１は、本発明を実現するためのネットワークシステムの概略構成であり、ＰＣ１００Ａ，ＰＣ１００Ｂと、デバイスサーバ２００と、ストレージ３００から構成されている。
【００３９】
このネットワークシステムでは、デバイスサーバ２００とストレージ３００をＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）やＩＥＥＥ１３９４などのインターフェースに準拠した接続ケーブル４００で接続する。また、デバイスサーバ２００とＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）は、有線または無線のネットワーク５００で接続する。
【００４０】
また、図１のネットワークシステムでは、デバイスサーバ２００、ストレージ３００をそれぞれ別体の装置で構成しているが、この構成に限定されるものではなく、同等の機能を実現できる構成であれば種々の構成を採り得ることは勿論である。例えば、デバイスサーバ２００をストレージ３００のケーシング内に収まるように一体構造としても良い。
【００４１】
なお、以降の説明においては、クライアントＰＣのオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ；以下、ＯＳ）をＷｉｎｄｏｗｓ（登録商標）、デバイスをストレージ、デバイスサーバとデバイスの接続インターフェースをＵＳＢとした場合の構成で説明するが、これらに限定されず、別のＯＳや接続インターフェースを使用しても良い。
【００４２】
次に、図１のネットワークシステムを構成する各装置について順次説明してゆく。
【００４３】
まず、クライアントであるＰＣ１００について説明する。ＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）は、例えば、パーソナルコンピュータのような装置であり、ネットワーク５００と接続し、デバイスサーバ２００を介してストレージ３００を利用することが可能な構成となっている。
【００４４】
図２は、ＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）のハードウェア構成およびソフトウェア構成の一例を示すブロック図である。
【００４５】
ＰＣ１００は、ＣＰＵ１０１、入力部１０２、表示部１０３、メモリ１０４、通信部１０５、外部記憶部１０６などから構成されており、これらが内部バス１０７で接続されている。
【００４６】
外部記憶部１０６は、ＯＳ１１０、アプリケーションプログラム１１１、本発明を実現するためのソフトウェア群１１２〜１１６（後述）など各種ソフトウェアが記録されている。ここで、アプリケーションプログラム１１１とは、ファイル管理ソフトウェアなど、ストレージ３００へのアクセスを発生せしめるソフトウェアプログラムを指す。
【００４７】
外部記憶部１０６に記憶されたこれらソフトウェアは、ＣＰＵ１０１の制御に従い、メモリ１０４上に読み出されて実行される。
【００４８】
通信部１０５は、ネットワーク５００（有線又は無線ネットワーク）に接続するためのインターフェースであり、デバイスサーバ２００との間でデータ通信を行うことで、ＰＣ１００からデバイスサーバ２００を介したストレージ３００へのアクセスを可能とする。
【００４９】
本発明を実現するためのソフトウェア群１１２〜１１６について説明する。
【００５０】
ＳＣＳＩコマンド層１１２は、ストレージ３００にアクセスする際に使用するドライバソフトウェア（例えば、ｄｉｓｋ．ｓｙｓなど）である。
【００５１】
ＰＣ１００内において、上位層（ＯＳ１１０およびアプリケーションプログラム１１１）からの指示によりストレージ３００へのアクセスが発生すると、制御コマンドであるＳＣＳＩコマンドの生成を行い、フィルタドライバ層１１３へ送出し、当該ＳＣＳＩコマンドに対する応答情報を待つ。なお、これ以降の説明では、制御コマンドをＳＣＳＩコマンドとして説明するが、ＳＣＳＩコマンドに限定するものではない。
【００５２】
フィルタドライバ層１１３は、ＳＣＳＩコマンド層１１２又はＵＳＢドライバ層１１４から送られてくるＳＣＳＩコマンドの種類（内容）を解析するソフトウェアである。
【００５３】
また、ＳＣＳＩコマンドの解析結果に基づいてＳＣＳＩコマンド層１１２を介して上位層に擬似応答情報を返すとともに、ネットワークプロトコル層１１５と連携してデバイスサーバ２００との間のセッションを切断する機能を備えている。
【００５４】
ＵＳＢドライバ層１１４は、接続対象となるＵＳＢデバイス（本実施例では、ストレージ３００）が持つ機能に合わせた制御を行うドライバソフトウェア（例えば、ｕｓｂｓｔｏｒ．ｓｙｓなど）であり、また、ＳＣＳＩコマンドとＵＳＢデバイスが扱えるＵＳＢパケットとの変換処理などを行うソフトウェアである。
【００５５】
ネットワークプロトコル層１１５は、ＵＳＢパケットに対してＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ヘッダの付加、取り外しの処理を行い、ネットワーク５００を介して接続されているデバイスサーバ２００との間のデータ通信を制御するソフトウェアである。
【００５６】
ネットワークインターフェース層１１６は、Ｅｔｈｅｒｎｅｔ（登録商標）のような有線ネットワーク、若しくは、ＩＥＥＥ８０２．１１ａやＩＥＥＥ８０２．１１ｂのような無線ネットワークなどネットワーク５００に対応したネットワークパケットによる送受信や通信制御を行うためのドライバソフトウェアである。
【００５７】
なお、本実施例では、フィルタドライバ層１１３がＳＣＳＩコマンド層１１２とＵＳＢドライバ層１１４との間に配置してあるが、この位置に限定されるものではない。例えば、ＵＳＢドライバ層１１４の下に配置する構成や、ネットワークプロトコル層１１５のドライバソフトウェアの一部に組み込まれる構成であっても良い。
【００５８】
次に、デバイスサーバ２００について説明する。デバイスサーバ２００は、ＰＣ１００Ａ，１００Ｂとデバイスであるストレージ３００と間の接続制御を行う装置である。
【００５９】
図３は、デバイスサーバ２００のハードウェア構成およびソフトウェア構成の一例を示すブロック図である。
【００６０】
デバイスサーバ２００は、ＣＰＵ２０１、入力部２０２、表示部２０３、ＲＯＭ２０４、ＲＡＭ２０５、通信部２０６、ＵＳＢインターフェース２０７などから構成されており、これらが内部バス２０８で接続されている。
【００６１】
ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０４には、ＯＳ２１０、制御プログラム２１１、本発明を実現するためのソフトウェア群２１２〜２１３（後述）など各種ソフトウェアが記録されており、これらソフトウェアは、ＣＰＵ２０１の制御に従い、ＲＡＭ２０５上に読み出されて実行される。
【００６２】
ＵＳＢインターフェース２０７は、接続ケーブル４００を介してストレージ３００とローカル接続するためのインターフェースである。
【００６３】
通信部２０６は、ネットワーク５００（有線又は無線ネットワーク）に接続してＰＣ１００との間でデータ通信するためのインターフェースである。
【００６４】
本発明を実現するためのソフトウェア群２１２〜２１３について説明する。
【００６５】
通信層２１２は、ネットワークに接続された通信部２０６の制御を行うとともに、ネットワーク５００に接続されているＰＣ１００との間のセッションやネットワークパケットによる通信を行うソフトウェアである。
【００６６】
また、ＵＳＢコマンド層２１３との間で通信するため、ネットワークパケットとＵＳＢパケットとの変換を行う。ネットワークパケットはＵＳＢパケットにＩＰヘッダを付加して作成するため、変換にはＩＰヘッダの取り付け及び取り外しを行う。
【００６７】
ＵＳＢコマンド層２１３は、ＵＳＢパケットに基づいて、ストレージ３００との間でデータ通信を行うソフトウェアである。
【００６８】
なお、通信層２１２、ＵＳＢコマンド層２１３は、ストレージ３００内に内蔵する構成であっても良い。また、通信層２１２の機能を備えたソフトウェアを別筐体内に設け、デバイス（ストレージ３００）に接続可能なインターフェースを有した外付けアダプタの形態として構成してもよい。この場合は、ＵＳＢコマンド層２１３の機能を持つソフトウェアは、デバイス３００側のＲＡＭや外部記憶装置などに記録しておく構成とする。
【００６９】
ここで、上述した図２及び図３で各ソフトウェア構成を説明したＰＣ１００とデバイスサーバ２００間の通信に関して説明する。
【００７０】
ＰＣ１００のネットワークプロトコル層１１５は、ネットワークインターフェース層１１６を介して、デバイスサーバ２００の通信層２１２とＴＣＰプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を用いて通信する。ＴＣＰプロトコルは、信頼性のある通信を保証するためのプロトコルであり、本実施例においては、ネットワーク５００上に流れるストレージ３００のデータの転送に用いている。
【００７１】
ストレージ３００は、例えば、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）のような装置であり、各種データの書き込み処理や読出し処理が可能な装置である。
【００７２】
なお、本実施例では、デバイスとしてストレージを例に説明しているが、例えば、プリンタやスキャナなど、別のデバイスであってもよい。
【００７３】
図４は、ＰＣ１００からストレージ３００へアクセスするときに使用する主なＳＣＳＩコマンドについて、ＣＤＢ（Ｃｏｍｍａｎｄ  Ｄｅｓｃｒｉｐｔｏｒ  Ｂｌｏｃｋ）の種類、オペレーションコード、サイズと意味を示した一覧リストであり、上述したＰＣ１００のＳＣＳＩコマンド層１１２（図２参照）で生成される制御コマンドである。本発明においては、これらのＳＣＳＩコマンドをセッション制御に利用する。
【００７４】
各ＣＤＢは、１バイトのオペレーションコードとそれに対応する構造体のサイズが定義されており、例えば、Ｔｅｓｔ  Ｕｎｉｔ  ＲｅａｄｙのＣＤＢでは、オペレーションコードは０ｘ００であり、サイズは６バイトである。以下、本実施例の説明で使用するコマンドについて説明する。
【００７５】
Ｔｅｓｔ  Ｕｎｉｔ  Ｒｅａｄｙコマンド（以下、ＴＵＲコマンド）は、ストレージ３００へのアクセスがアイドル状態になった場合、ＰＣ１００から定期的（例えば、一秒間隔）に送出され、ストレージの状態を確認するために用いられている制御コマンドである。
【００７６】
ＲＥＡＤコマンドは、ストレージ３００からデータを読み出すときに用いられるコマンドであり、ＷＲＩＴＥコマンドは、ストレージ３００へデータを書き込むときに用いられるコマンドである。なお、これ以降の説明では、ＴＵＲコマンド以外の制御コマンドを「アクセス制御コマンド」として説明する。
【００７７】
図５は、図４に図示した各ＳＣＳＩコマンドで共通に使用されるＳＲＢ（ＳＣＳＩ  Ｒｅｑｕｅｓｔ  Ｂｌｏｃｋ）のパケットフォーマットである。パケットは、ＳＲＢのサイズを示す２バイトのＬｅｎｇｔｈと、機能を示す１バイトのＦｕｎｃｔｉｏｎのフィールドなどで構成される。
【００７８】
ＳＣＳＩコマンド層１１２からフィルタドライバ層１１３へ送信されるＳＲＢ構造体は、６４バイトのサイズであり、Ｌｅｎｇｔｈ＝６４が設定される。Ｆｕｎｃｔｉｏｎは、ＳＣＳＩコマンドの実行コードとして０ｘ００、ストレージ３００への要求コードとしての０ｘ０１、制御を行う０ｘ０２などの値が設定される。
【００７９】
先頭からオフセット１０バイト目にあたる１バイトのＣｄｂＬｅｎｇｔｈは、ＣＤＢの有効データサイズを示している。ＣＤＢは、ＳＣＳＩデバイスの具体的なコマンドを示しており、オフセット４８バイト目から、１６バイト固定長のデータ領域が確保されている。
【００８０】
次に、ＰＣ１００とストレージ３００間のデータ通信の大まかな流れについて図６を参照しながら説明する。
【００８１】
まず、ＰＣ１００からストレージ３００へデータ送信を行う場合について説明する。
【００８２】
ＰＣ１００においてストレージ３００へのアクセス要求が発生すると、ＳＣＳＩコマンド層１１２は、アクセス要求の内容に応じて図４で説明したＳＣＳＩコマンドのいずれかを生成し、図５で示したフォーマットでフィルタドライバ層１１３へ送る。
【００８３】
フィルタドライバ層１１３は、ＳＣＳＩコマンド層１１２で生成されたＳＣＳＩコマンドの解析を行い、どのような内容のアクセス要求なのかを判定する。
【００８４】
ＵＳＢドライバ層１１４は、フィルタドライバ層１１３で解析されたＳＣＳＩコマンドをＵＳＢパケットに変換する（ＳＣＳＩコマンドをＵＳＢパケットのデータ層に格納する）。
【００８５】
ネットワークプロトコル層１１５は、ＵＳＢドライバ層１１４でＳＣＳＩコマンドから変換されたＵＳＢパケットにＩＰヘッダを付加し、ネットワーク５００に適した形式のデータであるネットワークパケットを作成する。
【００８６】
ネットワークインターフェース層１１６は、ネットワークプロトコル層１１５で作成されたネットワークパケットをネットワーク５００を介してデバイスサーバ２００に送出する。
【００８７】
デバイスサーバ２００では、まず、通信層２１２で、ＰＣ１００からネットワーク５００を介して送信されたネットワークパケットを受信し、ネットワークパケットからＩＰヘッダを取り外すことでＵＳＢパケットに変換し、これをＵＳＢコマンド層２１３へ送る。
【００８８】
ＵＳＢコマンド層２１３では、通信層２１２から送られたＵＳＢパケットを、接続ケーブル４００を介してストレージ３００へ送る。
【００８９】
ストレージ３００は、デバイスサーバ２００から送られてきたＵＳＢパケットに含まれるＳＣＳＩコマンドを解析し、その種類に応じた応答処理を行う。
【００９０】
ＳＣＳＩコマンドがＴＵＲコマンドである場合は、ストレージ３００を使用可能か否かの状態の確認処理を実行する。
【００９１】
ＳＣＳＩコマンドがＲＥＡＤコマンドである場合は、ストレージ３００からの読み込み処理を実行する。
【００９２】
ＳＣＳＩコマンドがＷＲＩＴＥコマンドである場合は、ストレージ３００への書き込み処理を実行する。
【００９３】
ＳＣＳＩコマンドが上述した以外のコマンドである場合は、該当するコマンドに応じた処理を実行する。
【００９４】
次に、ストレージ３００からＰＣ１００へデータ送信（応答）を行う場合について説明する。
【００９５】
上述した応答処理を行ったストレージ３００は、その結果をＰＣ１００に対する応答情報としてＵＳＢパケットでデバイスサーバ２００へ送る。
【００９６】
デバイスサーバ２００では、ＵＳＢコマンド層２１３がストレージからの応答情報であるＵＳＢパケットを受け取り、それを通信層２１２へ送る。
【００９７】
通信層２１２では、ＵＳＢコマンド層２１３からのＵＳＢパケットにＩＰヘッダを付加し、ネットワーク５００に適した形式のデータであるネットワークパケットを作成し、ネットワーク５００を介してＰＣ１００に送出する。
【００９８】
このようにして、ＰＣ１００とストレージ３００との間でデバイスサーバ２００を介したデータ通信が実行されることになる。
【００９９】
次に、ＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）の基本制御について説明する。
【０１００】
ＰＣ１００では、デバイスサーバ２００との接続が定常状態であるかどうかを判断して、定常状態に達した場合には、デバイスサーバ２００とのセッションを切断し、ＰＣ１００の上位層（ＯＳ１１０、アプリケーションプログラム１１１）およびＳＣＳＩコマンド層１１２からはストレージ３００が接続されていると認識される、いわゆる「擬似接続状態」へ移行し、定常状態である期間は「擬似接続状態」を維持する制御を実行する。
【０１０１】
なお、定常状態とは、ＰＣ１００とストレージ３００との接続が一定に保たれている状態をいい、定常状態であるかどうかの判断には、ＴＵＲコマンドに対してストレージ３００が連続して「ＳＵＣＣＥＳＳ」を応答した回数を用いるものとし、この回数（初期値０）をカウントするカウンタを、以降の説明ではＳＵＣＣＥＳＳカウンタと呼ぶものとする。
【０１０２】
図７は、ＰＣ１００がデバイスサーバ２００を介してストレージ３００にアクセスするときの制御動作の手順を示すフローチャートである。
【０１０３】
まず、ＰＣ１００において、ストレージ３００へのアクセスが発生した場合、ＳＣＳＩコマンド層１１２がアクセス要求の内容に応じたＳＣＳＩコマンド（図４参照）の生成を行い、生成されたＳＣＳＩコマンドは、フィルタドライバ層１１３へ送信される（ステップＳ７０１）。
【０１０４】
次に、フィルタドライバ層１１３が、生成されたＳＣＳＩコマンドを解析する（ステップＳ７０２）。
【０１０５】
ＳＣＳＩコマンドがＴＵＲコマンドである場合（ステップＳ７０２でＹｅｓ）、フィルタドライバ層１１３では、ＳＵＣＣＥＳＳカウンタの値を判定する（ステップＳ７０３）。この判定により、擬似接続状態であるか否かの判定が行われる。
【０１０６】
ＳＵＣＣＥＳＳカウンタの値が「５」未満の場合（ステップＳ７０３でＮｏ）、次に、デバイスサーバ２００との間のセッションの有無を判定する（ステップＳ７０５）。
【０１０７】
デバイスサーバ２００との間で「セッションなし」の場合（ステップＳ７０５でＹｅｓ）、即ち、ＳＵＣＣＥＳＳカウンタの値が「０」の場合は、デバイスサーバ２００に対してセッション開始要求を送り、デバイスサーバ２００とセッションを開始する（ステップＳ７０６)。
【０１０８】
デバイスサーバ２００との間で「セッションあり」の場合（ステップＳ７０５でＮｏ）、即ち、ＳＵＣＣＥＳＳカウンタの値が「１」以上「５」未満の場合、ステップＳ７０６の処理はスキップされる。
【０１０９】
続いて、デバイスサーバ２００に対してＴＵＲコマンドを送信する。デバイスサーバ２００は、ストレージ３００にＴＵＲコマンドを送り、ストレージ３００で確認処理が実行され、その応答情報がデバイスサーバ２００に返送される。デバイスサーバ２００は、この応答情報をＰＣ１００に返送する（ステップＳ７０７)。
【０１１０】
ＰＣ１００は、デバイスサーバ２００から送られてくる応答情報を受信すると、応答内容を確認する（ステップＳ７０８) 。
【０１１１】
応答内容が「ＦＡＩＬ」であった場合 （ステップＳ７０８でＮｏ)、デバイスサーバ２００との間のセッションを維持したまま、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし（ステップＳ７１５)、次のＳＣＳＩコマンドの受信待機状態に移る。
【０１１２】
応答内容が「ＳＵＣＣＥＳＳ」であった場合(ステップＳ７０８でＹｅｓ)、ＳＵＣＣＥＳＳカウンタの値を１つインクリメントし（ステップＳ７０９）、続いて、ＳＵＣＣＥＳＳカウンタの値が規定値「５」であるか否かを判定する（ステップＳ７１０）。
【０１１３】
ＳＵＣＣＥＳＳカウンタの値が規定値「５」未満の場合（ステップＳ７１０でＮｏ）、デバイスサーバ２００との間のセッションを維持したまま、次のＳＣＳＩコマンドの受信待機状態に移る。
【０１１４】
ＳＵＣＣＥＳＳカウンタの値が規定値「５」を示す場合（ステップＳ７１０でＹｅｓ）、デバイスサーバ２００との接続が定常状態であると判断してセッションを終了し（ステップＳ７１１）、次のＳＣＳＩコマンドの受信待機状態に移る。
【０１１５】
一方、上述したステップＳ７０３の処理において、ＳＵＣＣＥＳＳカウンタの値が規定値「５」以上の場合は（ステップＳ７０３でＹｅｓ）、セッションが終了した状態、すなわち定常状態であるため、実際のネットワーク接続によるストレージ３００への問い合わせは行わず、フィルタドライバ層１１３で擬似応答情報を生成し、ＳＣＳＩコマンド層１１２に「ＳＵＣＣＥＳＳ」を返す（ステップＳ７０４）。そして、ＳＣＳＩコマンド層１１２から上位層に対して「ＳＵＣＣＥＳＳ」が通知され、次のＳＣＳＩコマンドの受信待機状態に移る。
【０１１６】
これ以降、フィルタドライバ層１１３がアクセス制御コマンドを受け取るまで、上述したステップＳ７０１〜Ｓ７０４が繰り返される。この間、ＰＣ１００の上位層（ＯＳ１１０、アプリケーションプログラム１１１）およびＳＣＳＩコマンド層１１２では、ストレージ３００が接続された状態と判断されているが、デバイスサーバ２００とのセッションが切断されている状態、いわゆる「擬似接続状態」を維持することになる。
【０１１７】
また、上述したステップＳ７０２の処理で、フィルタドライバ層１１３が解析したＳＣＳＩコマンドがアクセス制御コマンドである場合の処理について説明する。
【０１１８】
ＳＣＳＩコマンドがアクセス制御コマンドの場合（ステップＳ７０２でＮｏ）、例えば、ＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどの場合、次に、デバイスサーバ２００との間のセッションの有無を判定する（ステップＳ７１２）。
【０１１９】
デバイスサーバ２００との間で「セッションなし」の場合（ステップＳ７１２でＹｅｓ）、ＳＵＣＣＥＳＳカウンタの値が「０」の場合は、デバイスサーバ２００に対してセッション開始要求を送り、デバイスサーバ２００とセッションを開始する（ステップＳ７１３）。
【０１２０】
デバイスサーバ２００との間で「セッションあり」の場合（ステップＳ７１２でＮｏ）、即ち、ＳＵＣＣＥＳＳカウンタの値が「１」以上「５」未満の場合、ステップＳ７１３の処理はスキップされる。
【０１２１】
続いて、デバイスサーバ２００に対してＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどのＳＣＳＩコマンドを送信する。デバイスサーバ２００は、ストレージ３００に対しこのＳＣＳＩコマンドを送り、ストレージ３００でＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどに応じた処理が実行され、その応答情報がデバイスサーバ２００に返送される。デバイスサーバ２００は、この応答情報をＰＣ１００に返送する（ステップＳ７１４)。
【０１２２】
ＰＣ１００は、デバイスサーバ２００から送られてくる応答情報を受信すると、デバイスサーバ２００とのセッションを維持したまま、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし（ステップＳ７１５)、次のＳＣＳＩコマンドの受信待機状態に移る。
【０１２３】
上記のＳＵＣＣＥＳＳカウンタは、フィルタドライバ層１１３がその機能の一部として備えるものでもよく、また、別のソフトウェアとして外部記憶部１０６に記録され、ソフトウェア群１１２〜１１６同様、ＣＰＵ１０１の制御に従い、メモリ１０４上に読み出されて実行されるものでもよい。
【０１２４】
上述したように、フィルタドライバ層１１３では、ＳＵＣＣＥＳＳカウンタの値が規定値「５」となるまでの間にアクセス制御コマンドを受信した場合、又は、応答情報が「ＦＡＩＬ」である場合、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットする。
【０１２５】
本実施の形態では、ＰＣ１００とデバイスサーバ２００との接続が定常状態であるかどうかの判断基準の一例として、ＳＵＣＣＥＳＳカウンタの値を用いているが、規定値は「５」以外の値でも良く、ユーザが任意に設定できるようにしても良い。また、ＴＵＲコマンドに対する応答が一定時間ＳＵＣＣＥＳＳであることなどを条件にしても良い。
【０１２６】
図８は、図７の制御フローに基づいて動作するＰＣ１００の状態遷移を示した図である。
【０１２７】
状態８０１は、電源投入直後などＰＣ１００の初期状態である。このとき、デバイスサーバ２００との間は「セッションなし」で、ＳＵＣＣＥＳＳカウンタの値は初期値「０」である。
【０１２８】
状態８０１において、ストレージ３００に対するアクセスが発生すると、状態８０１から状態８０２に遷移する。
【０１２９】
状態８０２は、デバイスサーバ２００との接続がまだ定常状態になっていない状態である。このとき、デバイスサーバ２００との間は「セッションあり」で、ＳＵＣＣＥＳＳカウンタの値は「５」未満である。
【０１３０】
状態８０２において、ＳＣＳＩコマンドを生成してデバイスサーバ２００に送出した後、デバイスサーバ２００を介してストレージ３００からの応答情報を受信すると、次の（ａ）、（ｂ）、（ｃ）の何れかの状態となる。
【０１３１】
（ａ）ＴＵＲコマンドの要求があり、これに対する応答が「ＳＵＣＣＥＳＳ」であり、ＳＵＣＣＥＳＳカウンタの値が規定値「５」に達した場合、状態８０３に遷移する。
【０１３２】
（ｂ）ＴＵＲコマンドの要求があり、これに対する応答が「ＳＵＣＣＥＳＳ」であり、ＳＵＣＣＥＳＳカウンタの値が規定値「５」未満の場合は、状態８０２を維持する。
【０１３３】
（ｃ）アクセス制御コマンドの要求があり、これに対する応答があった場合、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし、状態８０２を維持する。
【０１３４】
このように、ＰＣ１００は、上述した（ａ）の場合のみ、状態８０２から状態８０３に遷移する。
【０１３５】
状態８０３は、デバイスサーバ２００との接続が定常状態に達した状態、即ち、擬似接続状態を示している。このとき、デバイスサーバ２００との間は「セッションなし」で、ＳＵＣＣＥＳＳカウンタの値は規定値「５」以上である。
【０１３６】
状態８０３において、ＯＳ１１０およびアプリケーションプログラム１１１からの指示によりＳＣＳＩコマンド層１１２がＳＣＳＩコマンドを生成したとき、次の（ｄ）、（ｅ）の何れかの状態となる。
【０１３７】
（ｄ）ＳＣＳＩコマンドがＴＵＲコマンドの場合、フィルタドライバ層１１３で擬似応答情報を生成し、ＳＣＳＩコマンド層１１２に対しＳＵＣＣＥＳＳを応答し、状態８０３を維持する。
【０１３８】
（ｅ）ＳＣＳＩコマンドがアクセス制御コマンドの場合、デバイスサーバ２００との間のセッションを開始し、デバイスサーバ２００に対して生成したＳＣＳＩコマンドを送る。そして、デバイスサーバ２００を介してストレージ３００からの応答情報を受信すると、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし、状態８０２へ遷移する。
【０１３９】
このように、ＰＣ１００は、ストレージ３００にアクセスが必要なときだけ、デバイスサーバ２００と間のセッションを開始してＳＣＳＩコマンドの送出を行うので、セッションの開始・切断を手動操作することなく、複数のクライアントＰＣによるストレージのアクセスを実現できる。また、クライアントＰＣからデバイスサーバ２００に対して定期的に送出するＴＵＲコマンドを抑制し、ネットワーク上の通信量（トラフィック）を低減することができる。
【０１４０】
次に、デバイスサーバ２００の制御動作について図９を参照しながら説明する。
【０１４１】
デバイスサーバ２００では、ＰＣ１００からのセッション開始要求又はセッション終了要求の受信を監視している。
【０１４２】
セッション開始要求を受信した場合（ステップＳ９０１でＹｅｓ）、他のＰＣ１００とセッション接続中か否かを確認する（ステップＳ９０２）。
【０１４３】
既にセッションが開始されている場合（ステップＳ９０２でＹｅｓ）、このＰＣ１００に対して「ＮＧ」を返す（ステップＳ９０３）。
【０１４４】
セッションが開始されていない場合（ステップＳ９０２でＮｏ）、このＰＣ１００とセッションを開始し（ステップＳ９０４）、応答情報として「ＯＫ」を返す（ステップＳ９０５）。
【０１４５】
上述したステップＳ９０１の処理において、セッション開始要求以外のパケットを受信した場合（ステップＳ９０１でＮｏ）、セッション終了要求であれば（ステップＳ９０６でＹｅｓ）、セッション接続中のＰＣ１００との間のセッションを切断し（ステップＳ９０７）、応答情報として「ＯＫ」を返す（ステップＳ９０８）。
【０１４６】
一方、上述したステップＳ９０６の処理において、セッション終了要求以外のパケットを受信した場合（ステップＳ９０６でＮｏ）、そのパケットの種類に応じた応答処理を実行する（ステップＳ９０９）。
【０１４７】
図１０は、図９の制御フローに基づいて動作するデバイスサーバ２００の状態遷移を示した図である。
【０１４８】
状態１００１は、デバイスサーバ２００の初期状態である。このとき、ＰＣ１００との間は「セッションなし」である。ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）プロトコルを用いた通信などによる外部からの要求に応答し、状態１００１を維持する。
【０１４９】
ここで、ＰＣ１００においてストレージ３００に対するアクセスが発生すると、ＰＣ１００からデバイスサーバ２００に対してセッション開始要求が送られる。デバイスサーバ２００は、セッション開始要求に応じてＰＣ１００との間のセッションを開始し、状態１００２に遷移する（図１０の（ａ））。
【０１５０】
状態１００２は、「セッションあり」の状態である。この状態では、次の（ｂ）、（ｃ）、（ｄ）の処理を行い、状態１００２を維持する。
【０１５１】
（ｂ）セッション接続中のＰＣ１００からコマンドを受信して、それをストレージ３００に送信し、ストレージ３００から受信する当該コマンドに対する応答情報をＰＣ１００に返送する。
【０１５２】
（ｃ）セッション接続中ではない他のＰＣ１００からセッション開始要求があった場合、そのＰＣ１００に対して新たにセッションを開始することができないため、「ＮＧ」を応答する。
【０１５３】
（ｄ）ＵＤＰプロトコルを用いた通信などによる外部からの要求に応答する。
【０１５４】
一方、状態１００２において、セッション接続中のＰＣ１００からセッション終了要求があった場合、当該ＰＣ１００とのセッションを切断し、状態１００１へ遷移する（図１０の（ｅ））。
【０１５５】
このように、デバイスサーバ２００では、ＰＣ１００の状態遷移に応じて、「セッションなし」の状態１００１と「セッションあり」の状態１００２との遷移を繰り返す。
【０１５６】
次に、上述したネットワークシステムにおいて、ＰＣ１００Ａからストレージ３００へアクセスするときの具体的なタイミングチャートについて説明する。
【０１５７】
簡略化して分り易く説明をするために、まず、ＰＣ１００Ａ一台だけがストレージ３００にアクセスする場合（１対１で接続する場合）について、図１１を参照しながら説明する。
【０１５８】
ここでは、他のクライアントＰＣからのセッション開始要求の有無を考慮せず、ＰＣ１００Ａからのセッション開始要求に対して、デバイスサーバ２００は常に「ＯＫ」を応答するものとする。
【０１５９】
ＰＣ１００Ａにおいてストレージ３００へのアクセスが発生した場合、ストレージドライバであるＳＣＳＩコマンド層１１２において、アクセスの種類に応じたＳＣＳＩコマンドが生成され、生成されたＳＣＳＩコマンドは、フィルタドライバ層１１３へ送信される（タイミングＴ１１０１）。
【０１６０】
フィルタドライバ層１１３は、デバイスサーバ２００に対してセッション開始要求を行う（タイミングＴ１１０２）。このとき、ＳＵＣＣＥＳＳカウンタの値は初期値の「０」である。
【０１６１】
デバイスサーバ２００は、ＰＣ１００Ａに対して「ＯＫ」を応答して、ＰＣ１００Ａとの間のセッションを開始する（タイミングＴ１１０３）。
【０１６２】
フィルタドライバ層１１３は、デバイスサーバ２００から「ＯＫ」の応答がありセッションが開始されると、ストレージ３００の状態を確認するためのＴＵＲコマンドを送信する（タイミングＴ１１０４）。
【０１６３】
デバイスサーバ２００は、ＴＵＲコマンドを受信すると、これをストレージ３００に送信する（タイミングＴ１１０５）。ストレージ３００は、ＴＵＲコマンドに応じた処理を実行し、処理が完了すると応答情報をデバイスサーバ２００に返す（タイミングＴ１１０６）。デバイスサーバ２００はストレージ３００からの応答情報をＰＣ１００Ａに送る（タイミングＴ１１０７）。
【０１６４】
フィルタドライバ層１１３は、デバイスサーバ２００から応答情報を受信し、これが「ＳＵＣＣＥＳＳ」であれば、ＳＵＣＣＥＳＳカウンタの値を１インクリメントするとともにＳＣＳＩコマンド層１１２へ応答を返す（タイミングＴ１１０８）。
【０１６５】
以後、規定値「５」になるまで定期的（例えば、１秒間隔）にＴＵＲコマンドを送出する（タイミングＴ１１０９）。そして、ＳＵＣＣＥＳＳカウンタの値が規定値「５」になると、デバイスサーバ２００に対してセッション終了要求を送り、デバイスサーバ２００とのセッションを切断する（タイミングＴ１１１０）。
【０１６６】
ＰＣ１００Ａでは、セッションが終了したあともＳＣＳＩコマンド層１１２が定期的にＴＵＲコマンドを送出するが（タイミングＴ１１１１）、フィルタドライバ層１１３はＳＵＣＣＥＳＳカウンタの値が規定値「５」以上となっているので、これ以降に送出するＳＣＳＩコマンドがＴＵＲコマンドである限り擬似応答情報をＳＣＳＩコマンド層１１２に返す（タイミングＴ１１１２）。
【０１６７】
ＰＣ１００Ａの上位層（ＯＳ１１０、アプリケーションプログラム１１１）およびＳＣＳＩコマンド層１１２は、この擬似応答情報によってストレージ３００とは接続状態であると認識する。この状態がいわゆる「擬似接続状態」である。
【０１６８】
次に、擬似接続状態のＰＣ１００Ａからストレージ３００に対してデータの書き込み／読み出しなどのアクセスを行う場合について説明する。
【０１６９】
擬似接続状態のＰＣ１００Ａからストレージ３００に対してデータの書き込み／読み出しなどのアクセスを行うときは、アクセス制御コマンド（ＲＥＡＤコマンドやＷＲＩＴＥコマンドなど）の送信に先立って、まず、フィルタドライバ層１１３がデバイスサーバ２００に対してセッション開始要求を送る（タイミングＴ１１１３）。
【０１７０】
デバイスサーバ２００は、ＰＣ１００Ａに対して「ＯＫ」を応答して、ＰＣ１００Ａとの間でセッションを開始する（タイミングＴ１１１４）。
【０１７１】
フィルタドライバ層１１３は、デバイスサーバ２００から「ＯＫ」の応答がありセッションが開始されると、デバイスサーバ２００に対してアクセス制御コマンドを送る（タイミングＴ１１１５）。
【０１７２】
デバイスサーバ２００は、ＰＣ１００Ａからアクセス制御コマンドを受信すると、ＵＳＢパケットに変換してストレージ３００へ送信する（タイミングＴ１１１６）。
【０１７３】
ストレージ３００では、デバイスサーバ２００から送られてきたアクセス制御コマンドに応じた処理を実行し（例えば、データの書き込み／読み出しなど）、処理が終了するとその結果を応答情報としてデバイスサーバ２００に送信する（タイミングＴ１１１７）。
【０１７４】
デバイスサーバ２００は、ストレージ３００からの応答情報を受信すると、この応答情報をＰＣ１００Ａに対して送信する（タイミングＴ１１１８）。
【０１７５】
フィルタドライバ層１１３は、デバイスサーバ２００から応答情報を受信すると、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットするとともにＳＣＳＩコマンド層１１２へ応答を返す（タイミングＴ１１１９）。
【０１７６】
その後は上述と同様に、フィルタドライバ層１１３からＴＵＲコマンドを定期的に送出し、ＳＵＣＣＥＳＳカウンタの値が規定値「５」になると、デバイスサーバ２００に対してセッション終了要求を送り、デバイスサーバ２００との間のセッションを切断する（タイミングＴ１１２０）。そして、再度ストレージ３００にアクセスするときまでの間、擬似接続状態を維持する。
【０１７７】
次に、実際の運用により近いケースとして、複数台のＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）がストレージ３００にアクセスする場合（Ｎ対１で接続する場合）について、図１２を参照しながら説明する。
【０１７８】
図１２は、ＰＣ１００Ａがセッション接続中、若しくは、ストレージ３００にアクセス中に、別のＰＣ１００Ｂからストレージ３００にアクセスしたときのタイミングチャートを示した説明図である。なお、ＰＣ１００Ａについては、前述した図１１と同じ動作であるため、詳細な説明は省略する。
【０１７９】
まず、ＰＣ１００Ａとデバイスサーバ２００がセッション接続中のとき、ＰＣ１００Ｂがストレージ３００にアクセスしようとした場合について説明する。
【０１８０】
ＰＣ１００Ａとデバイスサーバ２００との間でセッション接続中のとき、ＰＣ１００Ｂがデバイスサーバ２００にセッション開始要求を送る（タイミングＴ１２０１）。
【０１８１】
デバイスサーバ２００は、ＰＣ１００Ａとセッション接続中のため、ＰＣ１００Ａとの間のセッションが切断されるまで間、ＰＣ１００Ｂに対して「ＮＧ」を返す（タイミングＴ１２０２）。
【０１８２】
ＰＣ１００Ｂは、デバイスサーバ２００から「ＮＧ」の応答があると、定期的にセッション開始要求を再送する。
【０１８３】
デバイスサーバ２００は、ＰＣ１００Ａとのセッションが切断され、「セッションなし」の状態（ＰＣ１００Ａが擬似接続状態）になったとき、ＰＣ１００Ｂからの「セッション開始要求」を受信すると、ＰＣ１００Ｂとの間でセッションを開始する（タイミングＴ１２０３）。
【０１８４】
ＰＣ１００Ｂは、デバイスサーバ２００とセッションが開始されると、ストレージ３００の状態を確認するためＴＵＲコマンドを送信する（タイミングＴ１２０４）。
【０１８５】
デバイスサーバ２００は、ＴＵＲコマンドを受信すると、これをストレージ３００に送信する（タイミングＴ１２０５）。ストレージ３００は、ＴＵＲコマンドに応じた処理を実行し、処理が完了すると応答情報をデバイスサーバ２００に返す。デバイスサーバ２００はストレージ３００からの応答情報をＰＣ１００Ｂに送る（タイミングＴ１２０６）。
【０１８６】
ＰＣ１００Ｂは、デバイスサーバ２００から応答情報を受信し、これが「ＳＵＣＣＥＳＳ」であれば、ＳＵＣＣＥＳＳカウンタの規定値を判定し、規定値「５」になるまで定期的（例えば、１秒間隔）にＴＵＲコマンドを送出する（タイミングＴ１２０７）。そして、ＳＵＣＣＥＳＳカウンタの規定値「５」になると、デバイスサーバ２００に対してセッション終了要求を送り、デバイスサーバ２００とのセッションを切断する（タイミングＴ１２０８）。
【０１８７】
この時点で、ＰＣ１００Ａ及びＰＣ１００Ｂは共に擬似接続状態であり、デバイスサーバ２００は「セッションなし」の状態である（タイミングＴ１２０９）。
【０１８８】
続いて、ＰＣ１００Ａがストレージ３００にアクセス中（読出し中又は書き込み中など）に、ＰＣ１００Ｂからストレージ３００にアクセスしようとした場合について説明する。
【０１８９】
上述したように、ＰＣ１００ＡとＰＣ１００Ｂは共に擬似接続状態であり、デバイスサーバ２００は「セッションなし」の状態であるとき、擬似接続状態のＰＣ１００Ａからデバイスサーバ２００にアクセスを開始すると、ＰＣ１００Ａからデバイスサーバ２００に対してセッション開始要求が送られ、デバイスサーバ２００との間のセッションが開始される。（タイミングＴ１２１０）
【０１９０】
セッションが開始されると、ＰＣ１００Ａがデバイスサーバ２００に対してアクセス制御コマンド（ＲＥＡＤコマンドやＷＲＩＴＥコマンドなど）を送出し（タイミングＴ１２１１）、デバイスサーバ２００がストレージ３００に対してアクセス制御コマンドを送る（タイミングＴ１２１２）。
【０１９１】
ストレージ３００では、アクセス制御コマンドに応じた処理（例えば、データの書き込み／読出しなど）を実行し、その結果を応答情報としてデバイスサーバ２００を介してＰＣ１００Ａに返信する（タイミングＴ１２１３）。
【０１９２】
その後は上述と同様に、フィルタドライバ層１１３からＳＵＣＣＥＳＳカウンタの値が規定値「５」になるまで定期的に、ＴＵＲコマンドをデバイスサーバ２００に対して送出する（タイミングＴ１２１４）。
【０１９３】
ここで、ＰＣ１００Ｂがストレージ３００へのアクセスを開始し、デバイスサーバ２００にセッション開始要求を送ると、デバイスサーバ２００は、ＰＣ１００Ｂに対して「ＮＧ」を応答する（タイミングＴ１２１５）。
【０１９４】
ＰＣ１００Ｂは、デバイスサーバ２００からの「ＮＧ」応答に対して、定期的にセッション開始要求を再送するが、ＰＣ１００Ａとデバイスサーバ２００のセッションが切断されるまでは、デバイスサーバ２００からは「ＮＧ」が応答される。
【０１９５】
デバイスサーバ２００とＰＣ１００Ａとの間のセッションが終了し、デバイスサーバ２００がセッションなしの状態になると、ＰＣ１００Ｂからのセッション開始要求により、ＰＣ１００Ｂとの間でセッションを開始する（タイミングＴ１２１６）。このときＰＣ１００Ａは擬似接続状態である。
【０１９６】
これ以降のＰＣ１００Ｂの動作は、上述したＰＣ１００Ａと同様であり、セッションが開始されると、ＰＣ１００Ｂがデバイスサーバ２００を介してストレージ３００にアクセス可能になる。
【０１９７】
上述したように、第一の実施の形態におけるネットワークシステムでは、あるクライアントＰＣがストレージ３００にアクセスするときだけ、クライアントＰＣとデバイスサーバ間のセッションを接続することにより、ネットワーク上の通信量（トラフィック）を低減することが可能となる。
【０１９８】
また、高負荷な処理機能をデバイスサーバへ組み込む必要が無くなるため、安価なネットワークシステム構成で複数のクライアントＰＣからデバイスを共有することが可能となる。
【０１９９】
次に、本発明の第二の実施の形態について図面を参照して詳細に説明する。本実施の形態は、図１〜図６、図８〜図１２に図示した構成が、上記第一の実施の形態と同じであり、その説明を省略する。以下に、上記第一の実施の形態と異なる点のみを説明する。
【０２００】
第二の実施の形態におけるＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）の基本制御フローについて、図１３を参照しながら説明する。図１３は第一の実施の形態における図７と同様、ＰＣ１００がデバイスサーバ２００を介してストレージ３００にアクセスするときの制御動作の手順を示すフローチャートであるが、ステップＳ１３１０とステップＳ１３１１は、図７にはなかったステップである（詳細は後述）。
【０２０１】
ＰＣ１００において、ストレージ３００へのアクセスが発生した場合、ＳＣＳＩコマンド層１１２がアクセス要求の内容に応じたＳＣＳＩコマンド（図４参照）の生成を行い、生成されたＳＣＳＩコマンドは、フィルタドライバ層１１３へ送信される（ステップＳ１３０１）。
【０２０２】
次に、フィルタドライバ層１１３が、生成されたＳＣＳＩコマンドを解析する（ステップＳ１３０２）。
【０２０３】
ＳＣＳＩコマンドがＴＵＲコマンドである場合（ステップＳ１３０２でＹｅｓ）、フィルタドライバ層１１３では次に、ＴＵＲコマンドに対する応答が「ＳＵＣＣＥＳＳ」であるときの回数をカウントしているカウンタ（以降、ＳＵＣＣＥＳＳカウンタ）の値を判定する（ステップＳ１３０３）。この判定により、擬似接続状態であるか否かの判定が行われる。
【０２０４】
ＳＵＣＣＥＳＳカウンタの値が「５」未満の場合（ステップＳ１３０３でＮｏ）、次に、デバイスサーバ２００との間のセッションの有無を判定する（ステップＳ１３０５）。
【０２０５】
デバイスサーバ２００との間で「セッションなし」の場合（ステップＳ１３０５でＹｅｓ）、即ち、ＳＵＣＣＥＳＳカウンタの値が「０」の場合は、デバイスサーバ２００に対してセッション開始要求を送り、デバイスサーバ２００とセッションを開始する（ステップＳ１３０６)。
【０２０６】
デバイスサーバ２００との間で「セッションあり」の場合（ステップＳ１３０５でＮｏ）、即ち、ＳＵＣＣＥＳＳカウンタの値が規定値未満の場合、ステップＳ１３０６の処理はスキップされる。
【０２０７】
続いて、デバイスサーバ２００に対してＴＵＲコマンドを送信する。デバイスサーバ２００は、ストレージ３００にＴＵＲコマンドを送り、ストレージ３００で確認処理が実行され、その応答情報がデバイスサーバ２００に返送される。デバイスサーバ２００は、この応答情報をＰＣ１００に返送する。なお、このとき、デバイスサーバ２００は、他のクライアントＰＣ（例えば、ＰＣ１００Ｂ）から所定時間内に受信したセッション開始要求の有無をあわせて通知する。（ステップＳ１３０７)。
【０２０８】
ここでいう所定時間とは、セッション開始後の累計時間や、定期的に送出されるＴＵＲコマンドの送出間隔（例えば、１秒間隔）を指すが、これに限定されるものではない。
【０２０９】
ＰＣ１００Ａは、デバイスサーバ２００から送られてくる応答情報を受信すると、応答内容を確認する（ステップＳ１３０８) 。
【０２１０】
応答内容が「ＦＡＩＬ」であった場合 （ステップＳ１３０８でＮｏ)、デバイスサーバ２００との間のセッションを維持したまま、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし（ステップＳ１３１７)、次のＳＣＳＩコマンドの受信待機状態に移る。
【０２１１】
応答内容が「ＳＵＣＣＥＳＳ」であった場合(ステップＳ１３０８でＹｅｓ)、ＳＵＣＣＥＳＳカウンタの値を１つインクリメントする（ステップＳ１３０９）。
【０２１２】
次に、ＰＣ１００Ａは、デバイスサーバ２００との接続を擬似接続状態に移行するかの基準となる規定値を変更するか否かを判定する（ステップＳ１３１０）。この判定には、ステップＳ１３０７において、デバイスサーバ２００から通知された他のクライアントＰＣからのセッション開始要求の有無に関する情報が用いられる。
【０２１３】
他のクライアントＰＣからのセッション開始要求が「あり」の場合（ステップＳ１３１０でＹｅｓ）、規定値を変更する（例えば、「５」から「３」に下げる）（ステップＳ１３１１）。
【０２１４】
一方、他のクライアントＰＣからのセッション開始要求が「なし」の場合（ステップＳ１３１０でＮｏ）、ステップＳ１３１１をスキップして規定値を変更しない。
【０２１５】
続いて、ＳＵＣＣＥＳＳカウンタの値が規定値であるか否かを判定する（ステップＳ１３１０）。ステップＳ１３１１で規定値を変更した場合には、変更後の規定値に基づいて判定される。
【０２１６】
ＳＵＣＣＥＳＳカウンタの値が規定値未満の場合（ステップＳ１３１０でＮｏ）、デバイスサーバ２００との間のセッションを維持したまま、次のＳＣＳＩコマンドの受信待機状態に移る。
【０２１７】
一方、上述したステップＳ１３０３の処理において、ＳＵＣＣＥＳＳカウンタの値が規定値以上の場合は（ステップＳ１３０３でＹｅｓ）、セッションが終了した状態、すなわち定常状態であるため、実際のネットワーク接続によるストレージ３００への問い合わせは行わず、フィルタドライバ層１１３で擬似応答情報を生成し、ＳＣＳＩコマンド層１１２に「ＳＵＣＣＥＳＳ」を返す（ステップＳ１３０４）。そして、ＳＣＳＩコマンド層１１２から上位層に対して「ＳＵＣＣＥＳＳ」が通知され、次のＳＣＳＩコマンドの受信待機状態に移る。
【０２１８】
これ以降、フィルタドライバ層１１３がアクセス制御コマンドを受け取るまで、上述したステップＳ１３０１〜Ｓ１３０４が繰り返される。この間、ＰＣ１００の上位層（ＯＳ１１０、アプリケーションプログラム１１１）およびＳＣＳＩコマンド層１１２では、ストレージ３００が接続された状態と判断されているが、デバイスサーバ２００とのセッションが切断されている状態、いわゆる「擬似接続状態」を維持することになる。
【０２１９】
ＳＵＣＣＥＳＳカウンタの値が規定値を示す場合（ステップＳ１３１０でＹｅｓ）、デバイスサーバ２００との接続が定常状態であると判断してセッションを切断し（ステップＳ１３１１）、次のＳＣＳＩコマンドの受信待機状態に移る。
【０２２０】
また、上述したステップＳ１３０２の処理で、フィルタドライバ層１１３が解析したＳＣＳＩコマンドがアクセス制御コマンドである場合の処理について説明する。
【０２２１】
ＳＣＳＩコマンドがアクセス制御コマンドの場合（ステップＳ１３０２でＮｏ）、例えば、ＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどの場合、次に、デバイスサーバ２００との間のセッションの有無を判定する（ステップＳ１３１４）。
【０２２２】
デバイスサーバ２００との間で「セッションなし」の場合（ステップＳ１３１４でＹｅｓ）、ＳＵＣＣＥＳＳカウンタの値が「０」の場合は、デバイスサーバ２００に対してセッション開始要求を送り、デバイスサーバ２００とセッションを開始する（ステップＳ１３１５）。
【０２２３】
デバイスサーバ２００との間で「セッションあり」の場合（ステップＳ１３１４でＮｏ）、即ち、ＳＵＣＣＥＳＳカウンタの値が規定値未満の場合、ステップＳ１３１５の処理はスキップされる。
【０２２４】
続いて、デバイスサーバ２００に対してＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどのＳＣＳＩコマンドを送信する。デバイスサーバ２００は、ストレージ３００に対しこのＳＣＳＩコマンドを送り、ストレージ３００でＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどに応じた処理が実行され、その応答情報がデバイスサーバ２００に返送される。デバイスサーバ２００は、この応答情報をＰＣ１００に返送する（ステップＳ１３１６)。
【０２２５】
ＰＣ１００は、デバイスサーバ２００から送られてくる応答情報を受信すると、デバイスサーバ２００とのセッションを維持したまま、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし（ステップＳ１３１７)、次のＳＣＳＩコマンドの受信待機状態に移る。
【０２２６】
上述したように、フィルタドライバ層１１３では、ＳＵＣＣＥＳＳカウンタの値が規定値となるまでの間にアクセス制御コマンドを受信した場合、又は、応答情報が「ＦＡＩＬ」である場合、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットする。
【０２２７】
上述したように、第二の実施の形態におけるネットワークシステムでは、デバイスサーバ２００がＰＣ１００に対して、他のクライアントＰＣからのセッション開始要求の有無をあわせて通知することによって、ＰＣ１００がより早く擬似接続状態に移行し、デバイスサーバ２００とのセッションを開放することができる。
【０２２８】
なお、本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において適宜変更可能である。
【０２２９】
上述した実施の形態では、１台のデバイスサーバが１台のストレージを管理する構成で説明したが、１台のサーバに複数のストレージを接続する構成としても良い。また、この場合はストレージ毎にセッションを用意し制御することで、複数のクライアントＰＣから、別々のストレージであれば、同時にアクセスが可能となる。
【０２３０】
また、デバイスサーバとデバイスの接続インターフェースをＵＳＢとした場合の構成で説明したが、これらに限定されず、別の接続インターフェースを使用しても良い。具体的には、ＩＥＥＥ１３９４に対応するためには、ＰＣ１００が備えるＵＳＢドライバ層１１４とデバイスサーバ２００が備えるＵＳＢコマンド層２１２が、それぞれＩＥＥＥ１３９４ドライバ層とＩＥＥＥ１３９４コマンド層が置き換われば良い。
【０２３１】
さらにはＰＣ１００が複数の異なるドライバ層を持ち、デバイスサーバ２００がそれに対応した複数の異なるコマンド層を備えるようにすれば、様々な接続インターフェースを備えたデバイスにも柔軟に対応できる。
【０２３２】
また、本発明の目的は、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して処理を実行することによっても達成することができる。
【０２３３】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコードを記憶したコンピュータで読み取り可能な記憶媒体は本発明を構成することになる。
【０２３４】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現されるように構成しても良い。
【０２３５】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれたあと、このプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を実行し、その処理に応じて上述した実施形態が実現される場合も含んでいる。
【０２３６】
なお、プログラムコードを供給するため、例えば、フロッピー（登録商標)ディスク、ハードディスク、光磁気ディスク、ＣＤやＤＶＤに代表される光ディスク、磁気テープ、不揮発性のメモリカード、ＲＯＭ等の記憶媒体を用いることができる。または、プログラムコードは、ネットワークを介してダウンロードしてもよい。
【図面の簡単な説明】
【０２３７】
【図１】本発明の実施形態に係るネットワークシステムの概略構成を示すブロック図である。
【図２】図１のＰＣ１００Ａ，１００Ｂのハードウェアおよびハードウェアの概略構成を示すブロック図である。
【図３】図１のデバイスサーバ２００のハードウェアおよびハードウェアの概略構成を示すブロック図である。
【図４】制御コマンドとして用いられる主なＳＣＳＩコマンドの一覧表である。
【図５】各ＳＣＳＩコマンドで共通に使用されるＳＲＢ（ＳＣＳＩ  Ｒｅｑｕｅｓｔ  Ｂｌｏｃｋ）のパケットフォーマットの説明図である。
【図６】クライアントＰＣとストレージ間のデータ通信の大まかな流れの説明図である。
【図７】第一の実施の形態におけるクライアントＰＣのセッションの制御動作を示すフローチャートである。
【図８】クライアントＰＣの状態遷移図である。
【図９】第一の実施の形態におけるデバイスサーバのセッションの制御動作を示すフローチャートである。
【図１０】デバイスサーバの状態遷移図である。
【図１１】第一の実施の形態における一台のクライアントＰＣがストレージにアクセスするときの過程を示したタイミングチャートである。
【図１２】第一の実施の形態における複数台のクライアントＰＣがストレージにアクセスするときの過程を示したタイミングチャートである。
【図１３】第二の実施の形態におけるクライアントＰＣのセッションの制御動作を示すフローチャートである。
【図１４】従来技術において、ネットワーク上のストレージにアクセスするとき、クライアントＰＣのユーティリティを操作してセッションを制御するときの動作を示すフローチャートである。
【図１５】従来技術において、複数台のクライアントＰＣがストレージにアクセスする場合の過程を示すタイミングチャートである。
【符号の説明】
【０２３８】
１００Ａ，１００Ｂ：クライアントＰＣ
１０１：ＣＰＵ
１０２：入力部
１０３：表示部
１０４：メモリ
１０５：通信部
１０６：外部記憶部
１０７：内部バス
１１０：ＯＳ
１１１：アプリケーションプログラム
１１２：ＳＣＳＩコマンド層
１１３：フィルタドライバ層
１１４：ＵＳＢドライバ層
１１５：ネットワークプロトコル層
１１６：ネットワークインターフェース層
２００： デバイスサーバ
２０１：ＣＰＵ
２０２：入力部
２０３：表示部
２０４：ＲＯＭ
２０５：ＲＡＭ
２０６：通信部
２０７：ＵＳＢＩ／Ｆ（ＵＳＢインターフェース）
２０８：内部バス
２１０：ＯＳ
２１１：制御プログラム
２１２：通信層
２１３：ＵＳＢコマンド層
３００：ストレージ
４００：接続ケーブル
５００：ネットワーク
【図１】
2010097492.tif 000003
【図２】
2010097492.tif 000004
【図３】
2010097492.tif 000005
【図４】
2010097492.tif 000006
【図５】
2010097492.tif 000007
【図６】
2010097492.tif 000008
【図７】
2010097492.tif 000009
【図８】
2010097492.tif 000010
【図９】
2010097492.tif 000011
【図１０】
2010097492.tif 000012
【図１１】
2010097492.tif 000013
【図１２】
2010097492.tif 000014
【図１３】
2010097492.tif 000015
【図１４】
2010097492.tif 000016
【図１５】
2010097492.tif 000017