JP2016212852A - 情報処理装置、情報処理システムおよび方法 - Google Patents

Abstract

【課題】本発明は、データのバックアップによってセッションが占有される可能性を低減する情報処理システムを提供することを目的とする。【解決手段】本発明によれば、ネットワーク上に配置され、データのバックアップ先に設定される情報処理装置であって、前記ネットワークを経由してバックアップの開始を要求されたときに、ファイル共有プロトコルの通信でバックアップを実行しているセッションの数に基づいて、バックアップを要求する要求元にバックアップ用のセッションを割り当てるセッション管理手段を含む、情報処理装置が提供される。【選択図】図２

Description

本発明は、情報処理装置、情報処理システムおよび方法に関する。

近年、複数のパーソナル・コンピュータ（ＰＣ）にネットワークを介してファイルサーバを接続し、接続したファイルサーバを複数のＰＣが外部記憶装置として共有することが広く行われている。

このようなファイルサーバを各ＰＣがデータのバックアップ先として利用するケースでは、複数のＰＣのバックアップ処理が重なった場合、ファイルサーバのセッションが長時間にわたってバックアップ処理に占有されてしまい、その間、他のユーザがファイルサーバを利用できなくなるという問題があった。

この点につき、特開２００５−６３３６３号公報（特許文献１）は、ネットワークの空き帯域を検出し、検出した空き帯域が広い場合にのみバックアップを実施するデータバックアップ装置を開示する。

特許文献１によれば、バックアップ以外の用途でファイルサーバを利用するユーザの利用機会は確保されるものの、複数のＰＣのバックアップ処理が重なった場合に、いずれかのＰＣのバックアップの実行が妨げられる可能性がある。

本発明は、上記従来技術における課題に鑑みてなされたものであり、データのバックアップによってセッションが占有される可能性を低減する情報処理装置を提供することを目的とする。

本発明者は、データのバックアップによってセッションが占有される可能性を低減する情報処理装置の構成につき鋭意検討した結果、以下の構成に想到し、本発明に至ったのである。

すなわち、本発明によれば、ネットワーク上に配置され、データのバックアップ先に設定される情報処理装置であって、前記ネットワークを経由してバックアップの開始を要求されたときに、ファイル共有プロトコルの通信でバックアップを実行しているセッションの数に基づいて、バックアップを要求する要求元にバックアップ用のセッションを割り当てるセッション管理手段を含む、情報処理装置が提供される。

上述したように、本発明によれば、データのバックアップによってセッションが占有される可能性を低減する情報処理装置が提供される。

第１実施形態の情報処理システムのネットワーク構成図。 第１実施形態の情報処理システムを構成する各装置の機能ブロック図。 バックアップの設定時に実行される処理を示すシーケンス図。 バックアップ設定画面を示す図。 バックアップ処理時にユーザ端末で実行される処理を示すシーケンス図。 バックアップ処理時にファイルサーバで実行される処理を示すシーケンス図。 セッション管理部が管理するテーブルを示す図。 予約ＩＤ発行処理を示すフローチャート。 セッションＩＤ発行処理を示すフローチャート。 第２実施形態の情報処理システムのネットワーク構成図。 第２実施形態の情報処理システムを構成する各装置の機能ブロック図。 バックアップ処理時に情報処理システムで実行される処理を示すシーケンス図。 ファイル出力時に情報処理システムで実行される処理を示すシーケンス図。 本実施形態の情報処理システムを構成する各装置のハードウェア構成図。

以下、本発明を、実施形態をもって説明するが、本発明は後述する実施形態に限定されるものではない。なお、以下に参照する各図においては、共通する要素について同じ符号を用い、適宜、その説明を省略するものとする。

（第１実施形態）
図１は、本発明の第１実施形態である情報処理システム１０００のネットワーク構成を示す。情報処理システム１０００は、複数のユーザ端末１００と、情報処理装置２００を含んで構成されている。

ユーザ端末１００は、パーソナル・コンピュータとして参照される情報処理端末である。ユーザ端末１００としては、デスクトップ型ＰＣ、ノート型ＰＣ、タブレット型ＰＣ、スマートフォンなどを例示することができる。

情報処理装置２００は、ファイルサーバの機能を備えるコンピュータ装置である。本実施形態においては、複数のユーザ端末１００がネットワークを介して接続される情報処理装置２００を外部記憶装置として共有しており、情報処理装置２００は、各ユーザ端末１００のローカルストレージに保存されたデータのバックアップ先に設定されている。なお、以下の説明においては、便宜上、情報処理装置２００をファイルサーバ２００という。

本実施形態においては、ファイルサーバ２００とユーザ端末１００（１００ａ、１００ｂ、１００ｃ…）がローカルエリアネットワークとして参照されるＬＡＮ１０を介して相互通信可能に接続されている。

さらに、本実施形態においては、ファイルサーバ２００と入出力装置４０がＬＡＮ６０を介して相互通信可能に接続されており、ファイルサーバ２００に保存されるファイルを指定し、入出力装置４０を出力先に指定した出力要求をユーザ端末１００（１００ａ、１００ｂ、１００ｃ…）からファイルサーバ２００に送信すると、ファイルサーバ２００が指定されたファイルを指定された入出力装置４０から出力するように構成されている。なお、入出力装置４０としては、ＭＦＰ(Multi Function Peripheral）、プロジェクター、電子黒板などの電子機器を例示することができる。

以上、本実施形態の情報処理システム１０００のネットワーク構成について説明してきたが、続いて、情報処理システム１０００を構成する各装置の機能構成を図２に示す機能ブロック図に基づいて説明する。

本実施形態のユーザ端末１００は、オペレーティングシステム１０８（以下、ＯＳ１０８という）に加えて、ＧＵＩ処理部１０２、ＷｅｂＡＰＩ処理部１０３、ＳＭＢ処理部１０４、バックアップ処理部１０５、設定情報管理部１０６、定期実行部１０７およびデータ記憶領域１０９を含んで構成されている。これらの各機能部は、専用アプリケーション（以下、端末用アプリという）をユーザ端末１００にインストールすることによって実現される。上述した各機能部およびＯＳ１０８は、ソフトウェア同士が通信するための仕組みである共通フレームワークを介して互いに要求やデータの送受信を行う。

ＯＳ１０８は、クライアント用の汎用オペレーティングシステムであり、このようなクライアント用ＯＳとしては、Ｗｉｎｄｏｗｓ（登録商標）８を例示することができる。

ＧＵＩ処理部１０２は、端末用アプリのユーザインターフェースを制御する機能手段である。例えば、ＧＵＩ処理部１０２は、データ記憶領域１０９に保存されるファイルの一覧を表示する。ユーザは、表示されたファイル一覧から所望のファイルを選択してダウンロードしたり、選択したファイルを入出力装置４０から出力させたりすることができる。また、ＧＵＩ処理部１０２は、バックアップ状況を表す画面やバックアップに係る条件の設定画面などを表示する。

ＷｅｂＡＰＩ処理部１０３は、ファイルサーバ２００との間にＨＴＴＰプロトコルの通信（以下、ＨＴＴＰ通信という）を確立してデータの送受信を行うための機能手段である。

ＳＭＢ処理部１０４は、ファイルサーバ２００との間にファイル共有プロトコルの通信を確立してファイルの送受信を行うための機能手段である。本実施形態においては、ファイル共有プロトコルとしてＳＭＢ（Server Message Block）プロトコルを採用する。以下、ＳＭＢプロトコルの通信をＳＭＢ通信という。なお、他の実施形態では、ＳＭＢ以外のファイル共有プロトコルを採用することができる。

バックアップ処理部１０５は、ユーザが指定したデータ（ファイル）のバックアップ処理を実行する機能手段である。

定期実行部１０７は、ユーザが設定した日時にバックアップ処理部１０５にバックアップの開始通知を出すための機能手段である。なお、定期実行部１０７は、ユーザが設定した日時に予期せぬ理由（例えば、電源断）によってバックアップを実行できなかった場合には、ユーザ端末１００の起動時に、その旨の通知をポップアップダイアログで表示したり、バックアップを再実行したりすることができる。

設定情報管理部１０６は、ユーザ情報および各種設定情報をデータ記憶領域１０９に格納し、これを管理するための機能手段である。ここでいうユーザ情報としては、ユーザがファイルサーバ２００へログインするためのアカウント情報を挙げることができる。また、ここでいう設定情報としては、バックアップに係る条件（以下、バックアップ条件という）を挙げることができる。また、バックアップ条件としては、バックアップのスケジュール、バックアップ方式、バックアップ時の通信方式、バックアップ対象のファイルなどを挙げることができる。

以上、ユーザ端末１００の機能構成について説明したが、本実施形態においては、バックアップ処理部１０５およびＳＭＢ処理部１０４がファイル共有プロトコル（例えば、ＳＭＢプロトコル）の通信でデータのバックアップを行う第１のバックアップ手段に相当し、バックアップ処理部１０５およびＷｅｂＡＰＩ処理部１０３がＨＴＴＰプロトコルの通信でデータのバックアップを行う第２のバックアップ手段に相当する。

次に、本実施形態のファイルサーバ２００の機能ブロックを説明する。

本実施形態のファイルサーバ２００は、オペレーティングシステム２１０（以下、ＯＳ２１０という）に加えて、ＷｅｂＡＰＩ処理部２０２、ＷｅｂＵＩ処理部２０３、デバイス登録処理部２０４、入出力処理部２０５、バックアップ処理部２０６、設定情報管理部２０７、ドキュメント処理部２０８、セッション管理部２０９およびデータ記憶領域２１１を含んで構成される。これらの各機能部は、専用アプリケーション（以下、サーバ用アプリという）をファイルサーバ２００にインストールすることによって実現される。上述した各機能部およびＯＳ２１０は、ソフトウェア同士が通信するための仕組みである共通フレームワークを介して互いに要求やデータの送受信を行う。

ＯＳ２１０は、クライアント用の汎用オペレーティングシステムであり、このようなクライアント用ＯＳとしては、Ｗｉｎｄｏｗｓ（登録商標）８を例示することができる。ＯＳ２１０には、許容されるセッション数の上限（以下、許容セッション数という）が設定されており、セッション数が上限に達している場合、ユーザの新規のアクセスはエラーとなる。

ＷｅｂＡＰＩ処理部２０２は、ユーザ端末１００との間にＨＴＴＰ通信を確立してデータの送受信を行うための機能手段である。

ＷｅｂＵＩ処理部２０３は、Ｗｅｂサーバの機能を果たす機能手段である。ＷｅｂＵＩ処理部２０３は、ユーザ端末１００のブラウザ（図示せず）にファイルサーバ２００が保有する各種の情報（ユーザ毎の保存データ量など）を表示させる。

バックアップ処理部２０６は、ユーザ端末１００からのバックアップ要求に応答してバックアップ処理を実行するための機能手段である。

ドキュメント処理部２０８は、データ記憶領域２１１に保存されたファイルを管理するための機能手段である。好ましい実施形態では、ドキュメント処理部２０８は、ユーザ端末１００からアップロードされたファイルをデータ記憶領域２１１に保存する際に、アップロードされたファイルのフォーマットに対応していない端末の利用に供する目的で、当該ファイルを汎用フォーマット（ＪＰＥＧ、ＴＩＦＦ、ＰＤＦなど）の画像データに変換し、元のファイルとともに保存する。

設定情報管理部２０７は、ユーザ情報およびシステム情報をデータ記憶領域２１１に格納し、これを管理するための機能手段である。ここでいうユーザ情報ととしては、ユーザ名やパスワード、アクセス権限、ワークフロー設定やＷｅｂＵＩ画面の各種設定値を挙げることができる。また、ここでいうシステム情報としては、ユーザ端末１００の機器固有情報を挙げることができる。

デバイス登録処理部２０４は、ファイルサーバ２００を利用するユーザのユーザ端末１００を登録するための機能手段である。デバイス登録処理部２０４は、ＷｅｂＵＩ処理部２０３を介して、利用登録時にユーザ端末１００にデバイス登録に必要な情報を格納したファイルを送信する。ユーザ端末１００は、当該ファイルの情報に基づいてファイルサーバ２００との間の通信を確立する。

入出力処理部２０５は、入出力装置４０との間でデータを送受信するための機能手段である。

セッション管理部２０９は、バックアップに使用されるＳＭＢ通信のセッションを管理するための機能手段である。先述したように、ＯＳ２１０に許容セッション数が設定されている前提においては、限られたセッションがデータのバックアップによって過度に占有されてしまうことを避けながら、全てのユーザ端末１００のバックアップ処理を万遍なく完了させる必要がある。この要請に鑑みれば、一旦張られると長い時間（１０〜２０分）を占有するＳＭＢ通信のセッションをバックアップ用に際限なく割り当てることはできない。

この点につき、本実施形態においては、バックアップ用に割り当てることが許容されるＳＭＢ通信のセッションの数の上限（以下、バックアップ用許容セッション数という）を設定する。例えば、ＯＳ２１０に設定された許容セッション数が「２０」であった場合、バックアップ用許容セッション数を「５」に設定する。

そして、セッション管理部２０９は、ユーザ端末１００からバックアップ要求を受けた時点で、ＳＭＢ通信でバックアップを実行しているセッションの数がバックアップ用許容セッション数に達していない場合は、ＳＭＢ通信のセッションをバックアップ用に割り当てるとともに、ユーザ端末１００からバックアップ要求を受けた時点で、ＳＭＢ通信でバックアップを実行しているセッションの数がバックアップ用許容セッション数に達している場合は、ＨＴＴＰ通信のセッションをバックアップ用に割り当てる。ＨＴＴＰプロトコルは、ＳＭＢプロトコルに比べてオーバヘッドが大きい通信方式であるが、ＨＴＴＰ通信のセッションはＳＭＢ通信のセッションと比較して占有時間が短いため、ファイルサーバ２００の帯域幅がバックアップ処理によって過度に占有されることを回避することができる。

以上、情報処理システム１０００を構成する各装置の機能構成について説明してきたが、続いて、上述した各機能手段が実行する処理の具体的な内容を説明する。なお、以下の説明においては、適宜、図２を参照するものとする。

最初に、バックアップ条件の設定を行う際にユーザ端末１００で実行される処理を図３に示すシーケンス図に基づいて説明する。

ユーザが設定画面を表示させる操作を行ったことを受けて（Ｓ１）、ＧＵＩ処理部１０２は、設定情報管理部１０６を介してデータ記憶領域１０９に保存される設定値を読み込み（Ｓ２）、当該設定値を反映させたバックアップ設定画面を表示する。

図４は、バックアップ設定画面５０を例示的に示す。図４に示す例では、バックアップ設定画面５０は、定期バックアップの有効／無効を選択するためのチェックボックス５２と、定期バックアップのスケジュールを設定するための設定欄５３と、バックアップ方式を設定するための設定欄５４と、バックアップ時の通信方式を設定するための設定欄５６と、リトライに関する条件（以下、リトライ条件という）を設定するための設定欄５８を備えている。

ユーザは、指定した日時に定期的にバックアップを行うことを希望する場合、チェックボックス５２にチェックを入れて定期バックアップを有効にし、設定欄５３に実行時刻をセットするとともに、ラジオボタンでバックアップの実行日を選択する。例えば、ユーザは、ファイルサーバ２００を介した入出力装置４０（ＭＦＰ、プロジェクター等）への入出力処理が頻繁に行われる時間帯（例えば、業務時間帯）を避けて、定期バックアップの実行日時を設定することができる。

また、ユーザは、バックアップ方式について、設定欄５４のラジオボタンで「ミラーリング方式」または「上書き方式」のいずれかを選択する。ここで、上書き式とは、ユーザ端末１００側で追加や更新を行ったファイルをファイルサーバ２００にコピーする方式を意味する。一方、ミラーリング式とは、ユーザ端末１００側で追加や更新を行ったファイルをファイルサーバ２００にコピーするとともに、ユーザ端末１００側でファイルを削除した場合には、これに対応するファイルをファイルサーバ２００側から削除する方式を意味する。

また、ユーザは、バックアップ時の通信方式について、設定欄５６のラジオボタンで「ＳＭＢまたはＨＴＴＰ」または「ＳＭＢのみ」のいずれかを選択する。「ＳＭＢのみ」を選択した場合には、ＳＭＢ通信によってのみバックアップが実行される。一方、「ＳＭＢまたはＨＴＴＰ」を選択した場合には、バックアップ時の通信方式がＳＭＢ通信またはＨＴＴＰ通信のいずれかに動的に決定される。

また、ユーザは、設定した時刻にファイルサーバ２００と接続できなった場合にリトライを実施することを希望する場合は、設定欄５８の対応するチェックボックスにチェックを入れ、リトライを実施する最大時間をセットする。また、ユーザは、設定した日時に予期せぬ理由（例えば、電源断）によってバックアップを実行できなかった場合に、準備が整い次第バックアップを再実行することを希望する場合は、対応するチェックボックスにチェックを入れる。

図３に戻って説明を続ける。ユーザがバックアップ設定画面５０を介して設定値を入力し、さらに、図示しない他の設定画面を介してバックアップの対象ファイルを指定してバックアップ条件の設定入力を終えると（Ｓ３）、ＧＵＩ処理部１０２は、入力された設定値を設定情報管理部１０６を介してデータ記憶領域１０９に保存する（Ｓ４）。このとき、定期バックアップのスケジュールに係る設定値（実行日、実行時刻）が更新された場合には、設定情報管理部１０６は、更新された設定値（実行日、実行時刻）を定期実行部１０７に登録する（Ｓ５）。これを受けて、定期実行部１０７は、ユーザ端末１００のＯＳ１０８のタスクスケジューラにタスクのスケジュール（実行日、実行時刻）を登録する（Ｓ６）。

併せて、設定情報管理部１０６は、Ｓ４で保存した設定値を含む更新要求を生成し、生成した更新要求をＷｅｂＡＰＩ処理部１０３に渡す（Ｓ７）。これを受けて、ＷｅｂＡＰＩ処理部１０３は、当該更新要求をＨＴＴＰ通信を使用してファイルサーバ２００に送信する（Ｓ８）。

上述した手順でバックアップ条件の設定が完了した後、ＯＳ１０８は、Ｓ６で登録したスケジュール（実行日、実行時刻）が到来する度に実行トリガを定期実行部１０７に送信する（Ｓ９）。定期実行部１０７は、ＯＳ１０８から送信される実行トリガに応答してバックアップ処理を開始し、処理を終えた時点で、その処理結果をファイルサーバ２００に通知する（Ｓ１０）。

以上、バックアップ条件の設定を行う際にユーザ端末１００で実行される処理について説明してきたが、続いて、バックアップ処理時にユーザ端末１００で実行される処理を図５に示すシーケンス図に基づいて説明する。

ＯＳ１０８のタスクスケジューラから実行トリガが送信されたことを受けて（Ｓ１）、定期実行部１０７は、バックアップ処理部１０５にバックアップの実行を要求する（Ｓ２）。これを受けて、バックアップ処理部１０５は、ユーザが設定したバックアップ条件（バックアップの対象ファイル、バックアップ方式、バックアップ時の通信方式、リトライ条件など）を設定情報管理部１０６を介してデータ記憶領域１０９から読み出す（Ｓ３）。

続いて、バックアップ処理部１０５は、ユーザ端末１００の個体識別情報（以下、端末ＩＤという）を含む予約ＩＤ要求を生成し、生成した予約ＩＤ要求をＷｅｂＡＰＩ処理部１０３に渡す（Ｓ４）。これを受けて、ＷｅｂＡＰＩ処理部１０３は、ＨＴＴＰ通信を使用してファイルサーバ２００に予約ＩＤ要求を送信する（Ｓ５）。送信した予約ＩＤ要求に応答してファイルサーバ２００から予約ＩＤが返ってきた場合（Ｓ６）、ＷｅｂＡＰＩ処理部１０３は、予約ＩＤを受領してバックアップ処理部１０５に渡す（Ｓ７）。

ここで、本実施形態においては、予約ＩＤの発行数に上限が設定されているため（詳細については後述する）、予約ＩＤ要求を送信した時点で予約ＩＤの発行数が上限に達している場合には、Ｓ５で送信した予約ＩＤ要求がエラーになる。この場合、バックアップ処理部１０５は、Ｓ３で読み出した「リトライ条件」がリトライを実施する設定になっているか否かを判断する。その結果、リトライを実施する設定になっていた場合には、バックアップ処理部１０５は、予約ＩＤが取得できるまで、所定の時間間隔（例えば、１時間）で予約ＩＤ要求の送信を繰り返す。その後、リトライ条件に設定された最大時間（例えば、３時間）を経過してもなお予約ＩＤが取得できない場合は、バックアップ処理部１０５は、予約ＩＤ要求の送信を中止する。

上述した手順を経て、予約ＩＤを取得したバックアップ処理部１０５は、取得した予約ＩＤを含むバックアップ開始要求を生成し、生成したバックアップ開始要求をＷｅｂＡＰＩ処理部１０３に渡す（Ｓ８）。これを受けて、ＷｅｂＡＰＩ処理部１０３は、ＨＴＴＰ通信を使用してファイルサーバ２００にバックアップ開始要求を送信する（Ｓ９）。送信したバックアップ開始要求に応答してファイルサーバ２００からセッションＩＤと通信方式（ＳＭＢ通信またはＨＴＴＰ通信）を指定する情報が返ってきた場合（Ｓ１０）、ＷｅｂＡＰＩ処理部１０３は、セッションＩＤと通信方式を受信してバックアップ処理部１０５に渡す（Ｓ１１）。

ここで、バックアップ開始要求を送信した時点で、ファイルサーバ２００のOＳ２１０に設定された許容セッション数（例えば「２０」）が全て使い果たされている場合には、Ｓ９で送信したバックアップ開始要求がエラーになる。この場合は、バックアップ処理部１０５は、セッションＩＤが取得できるまで、ＷｅｂＡＰＩ処理部１０３を介して、所定の時間間隔（例えば、１分）でバックアップ開始要求の送信を繰り返す。

上述した手順を経て、セッションＩＤを取得したバックアップ処理部１０５は、ユーザ端末１００の端末ＩＤを含むバックアップ先ファイルリスト要求を生成し、生成したバックアップ先ファイルリスト要求をＷｅｂＡＰＩ処理部１０３に渡す（Ｓ１２）。これを受けて、ＷｅｂＡＰＩ処理部１０３は、ＨＴＴＰ通信を使用してファイルサーバ２００にバックアップ先ファイルリスト要求を送信する（Ｓ１３）。送信したバックアップ先ファイルリスト要求に応答してファイルサーバ２００からバックアップ先ファイルリストが返ってきた場合（Ｓ１４）、ＷｅｂＡＰＩ処理部１０３は、バックアップ先ファイルリストを受信してバックアップ処理部１０５に渡す（Ｓ１５）。ここで、バックアップ先ファイルリストとは、ファイルサーバ２００に保存されたファイルのうち、ユーザ端末１００がバックアップ対象として設定したファイルの一覧を意味する。

続いて、バックアップ処理部１０５は、Ｓ３で読み出したバックアップの対象ファイルの一覧（以下、バックアップ元ファイルリストという）をＯＳ１０８のファイルシステムから取得する（Ｓ１６）。バックアップ処理部１０５は、ファイルサーバ２００から取得したバックアップ先ファイルリストとＯＳ１０８のファイルシステムから取得したバックアップ元ファイルリストに基づいて実行ファイルリストを作成する（Ｓ１７）。

具体的には、Ｓ３で読み出したバックアップ方式に「上書き方式」が設定されている場合は、バックアップ処理部１０５は、バックアップ元ファイルリストに挙げられたファイルのうち追加や更新が行われたファイルをコピー対象とするファイル一覧を実行ファイルリストとして作成する。一方、Ｓ３で読み出したバックアップ方式に「ミラーリング方式」が設定されている場合は、バックアップ処理部１０５は、バックアップ元ファイルリストに挙げられたファイルのうち追加や更新が行われたファイルをコピー対象とし、バックアップ先ファイルリストとバックアップ元ファイルリストの比較により検出されたユーザ端末１００側の削除ファイルを削除対象としたファイル一覧を実行ファイルリストとして作成する。

続いて、バックアップ処理部１０５は、Ｓ１１で取得したセッションＩＤを使用してファイルサーバ２００との間にセッションを確立する。具体的には、Ｓ１１で取得した情報が指定する通信方式がＳＭＢ通信であった場合は、ファイルサーバ２００との間にＳＭＢ通信のセッションを確立し、Ｓ１１で取得した情報が指定する通信方式がＨＴＴＰ通信であった場合は、ファイルサーバ２００との間にＨＴＴＰ通信のセッションを確立する。その後、バックアップ処理部１０５は、確立したセッションを使用してバックアップ処理を実行する。

Ｓ１１で取得した情報が指定する通信方式がＳＭＢ通信であった場合、バックアップ処理部１０５は、Ｓ１７で作成した実行ファイルリストにリストアップされた各ファイルにつき、そのコピーまたは削除を要求するバックアップ実行要求を生成し、生成したバックアップ実行要求をＳＭＢ処理部１０４に渡す（Ｓ１８）。これを受けて、ＳＭＢ処理部１０４は、ＳＭＢ通信を使用してファイルサーバ２００にバックアップ実行要求を送信する（Ｓ１９）。以降、Ｓ１８およびＳ１９を実行ファイルリストにリストアップされた全てのファイルについて繰り返す。

一方、Ｓ１１で取得した情報が指定する通信方式がＨＴＴＰ通信であった場合、バックアップ処理部１０５は、Ｓ１７で作成した実行ファイルリストにリストアップされた各ファイルにつき、そのコピーまたは削除を要求するバックアップ実行要求を生成し、生成したバックアップ実行要求をＷｅｂＡＰＩ処理部１０３に渡す（Ｓ２０）。これを受けて、ＷｅｂＡＰＩ処理部１０３は、ＨＴＴＰ通信を使用してファイルサーバ２００にバックアップ実行要求を送信する（Ｓ２１）。以降、Ｓ２０およびＳ２１を実行ファイルリストにリストアップされた全てのファイルについて繰り返す。

バックアップ処理部１０５は、実行ファイルリストにリストアップされた全てのファイルに係るバックアップ実行要求をファイルサーバ２００に送信して、その処理結果を受け取る。その後、バックアップ処理部１０５は、バックアップに使用したセッションのセッションＩＤとバックアップ処理の成否（成功または失敗）を含むバックアップ完了通知を生成し、生成したバックアップ完了通知をＷｅｂＡＰＩ処理部１０３に渡す（Ｓ２２）。これを受けて、ＷｅｂＡＰＩ処理部１０３は、ＨＴＴＰ通信を使用してファイルサーバ２００にバックアップ完了通知を送信する（Ｓ２３）。

なお、バックアップ処理部１０５は、先述した予約ＩＤの取得に失敗してバックアップ処理が実行できなかった場合、端末ＩＤとバックアップ処理の成否（失敗）を含むバックアップ完了通知を生成し、生成したバックアップ完了通知をＷｅｂＡＰＩ処理部１０３に渡す（Ｓ２２）。これを受けて、ＷｅｂＡＰＩ処理部１０３は、ＨＴＴＰ通信を使用してファイルサーバ２００にバックアップ完了通知を送信する（Ｓ２３）。

以上、バックアップ処理時にユーザ端末１００において実行される処理について説明してきたが、続いて、バックアップ処理時にファイルサーバ２００において実行される処理を図６に示すシーケンス図に基づいて説明する。

ＷｅｂＡＰＩ処理部２０２は、Ｓ１でユーザ端末１００から予約ＩＤ要求を受信すると、受信した予約ＩＤ要求をセッション管理部２０９に渡す（Ｓ２）。これを受けて、セッション管理部２０９は、受領した予約ＩＤ要求に含まれる端末ＩＤに紐付いたバックアップ条件を設定情報管理部２０７を介してデータ記憶領域２１１から取得する（Ｓ３）。続いて、セッション管理部２０９は、予約ＩＤを発行する（Ｓ４）。なお、予約ＩＤを発行する処理の詳細については後述する。

その後、セッション管理部２０９は、発行した予約ＩＤの送信をＷｅｂＡＰＩ処理部２０２に渡す（Ｓ５）。これを受けて、ＷｅｂＡＰＩ処理部２０２は、ＨＴＴＰ通信を使用してユーザ端末１００に予約ＩＤを送信する（Ｓ６）。

ＷｅｂＡＰＩ処理部２０２は、Ｓ７でユーザ端末１００からバックアップ開始要求を受信すると、受信したバックアップ開始要求をセッション管理部２０９に渡す（Ｓ８）。これを受けて、セッション管理部２０９は、受領したバックアップ開始要求に含まれる予約ＩＤに基づいてセッションＩＤを発行するとともに、バックアップの通信方式をＳＭＢ通信またはＨＴＴＰ通信のいずれかに決定する（Ｓ９）。なお、Ｓ９で実行される処理の詳細については後述する。

その後、セッション管理部２０９は、発行したセッションＩＤと決定した通信方式（ＳＭＢ通信またはＨＴＴＰ通信）を指定する情報をＷｅｂＡＰＩ処理部２０２に渡す（Ｓ１０）。これを受けて、ＷｅｂＡＰＩ処理部２０２は、ＨＴＴＰ通信を使用してユーザ端末１００にセッションＩＤと通信方式を指定する情報（以下、単に、通信方式という場合がある）を送信する（Ｓ１１）。

ＷｅｂＡＰＩ処理部２０２は、Ｓ１２でユーザ端末１００からバックアップ先ファイルリスト要求を受信すると、受信したファイルリスト要求をドキュメント処理部２０８に渡す（Ｓ１３）。これを受けて、ドキュメント処理部２０８は、ＯＳ２１０のファイルシステムからバックアップ元ファイルリストを取得し（Ｓ１４）、取得したバックアップ元ファイルリストをＷｅｂＡＰＩ処理部２０２に渡す（Ｓ１５）。これを受けて、ＷｅｂＡＰＩ処理部２０２は、ＨＴＴＰ通信を使用してユーザ端末１００にバックアップ元ファイルリストを送信する（Ｓ１６）。

その後、ユーザ端末１００は、ファイルサーバ２００から指定されたＳＭＢ通信またはＨＴＴＰ通信のいずれかを使用してバックアップ実行要求をファイルサーバ２００に送信する。

ユーザ端末１００からＳＭＢ通信を使用して送信されたバックアップ実行要求は、ファイルサーバ２００のＯＳ２１０のファイルシステムに受信される。ＯＳ２１０のファイルシステムは、受信したバックアップ実行要求が指定する処理（ファイルのコピーまたは削除）を実行した後、その実行結果をＳＭＢ通信を使用してユーザ端末１００に返す。

一方、ユーザ端末１００からＨＴＴＰ通信を使用して送信されたバックアップ実行要求は、ＷｅｂＡＰＩ処理部２０２に受信される（Ｓ１８）。ＷｅｂＡＰＩ処理部２０２は、受信したバックアップ実行要求をバックアップ処理部２０６に渡す（Ｓ１９）。これを受けて、バックアップ処理部２０６は、ＯＳ２１０のファイルシステムにバックアップ実行要求を渡す（Ｓ２０）。ＯＳ２１０のファイルシステムは、受領したバックアップ実行要求が指定する処理（ファイルのコピーまたは削除）を実行した後、その実行結果をバックアップ処理部２０６に返す。バックアップ処理部２０６は、受け取った実行結果の送信をＷｅｂＡＰＩ処理部２０２に渡し、ＷｅｂＡＰＩ処理部２０２は、受領した実行結果をＨＴＴＰ通信を使用してユーザ端末１００に送信する。

その後、ＷｅｂＡＰＩ処理部２０２は、Ｓ２１でユーザ端末１００からバックアップ完了通知を受信すると、受信したバックアップ完了通知をセッション管理部２０９に渡す（Ｓ２２）。これを受けて、セッション管理部２０９は、バックアップ完了通知に含まれるセッションＩＤに係るセッションの破棄をＯＳ２１０に指示する（Ｓ２３）。これを受けてＯＳ２１０は、当該セッションＩＤに係るセッションを破棄する。その結果、ＯＳ２１０に設定されたＳＭＢプロトコルのセッション保持時間が残っている場合であっても、ＳＭＢ通信が強制的に遮断され、セッションが速やかに開放されることになる。

ＳＭＢ通信のセッションをＯＳ２１０に破棄させた場合、セッション管理部２０９は、ＳＭＢ通信セッション管理テーブル（後述する）を更新するとともに（Ｓ２４）、バックアップ完了通知に含まれるバックアップ処理の成否（成功または失敗）をバックアップ結果管理テーブル（後述する）に記録する（Ｓ２５）。

以上、バックアップ処理時にファイルサーバ２００において実行される処理について説明してきたが、続いて、ファイルサーバ２００のセッション管理部２０９が管理するテーブルについて説明する。

本実施形態において、セッション管理部２０９は、図７（ａ）に示すＳＭＢ通信セッション管理テーブル５００と、図７（ｂ）に示すバックアップ結果管理テーブル６００と、図７（ｃ）に示す予約順番管理テーブル７００を管理する。

図７（ａ）に示すＳＭＢ通信セッション管理テーブル５００は、バックアップの通信方式としてＳＭＢ通信を指定したユーザ端末１００のセッションを管理するためのテーブルである。ＳＭＢ通信セッション管理テーブル５００は、バックアップ用に割り当てることが許容されるＳＭＢ通信のセッション（以下、ＳＭＢ通信セッションという）の数の上限（バックアップ用許容セッション数）と同数のレコードを有しており、図７（ａ）に示す例では、５つのレコードを有している。各レコードは、ユーザ端末１００の端末ＩＤを格納するためのフィールド５０１、当該ユーザ端末１００に割り当てたＳＭＢ通信セッションのセッションＩＤを格納するためのフィールド５０２、ＳＭＢ通信セッションを使用したバックアップの開始時刻を格納するためのフィールド５０３、当該バックアップを開始してからの経過時間を格納するためのフィールド５０４を備えている。

セッション管理部２０９は、通信方式としてＳＭＢ通信を指定したユーザ端末１００にセッションＩＤを発行する際に、当該ユーザ端末１００の端末ＩＤ、発行したセッションＩＤ、バックアップ処理の開始時刻および経過時間を、それぞれ、ＳＭＢ通信セッション管理テーブル５００のフィールド５０１〜５０４に格納する。また、セッション管理部２０９は、バックアップ用に割り当てたＳＭＢ通信セッションを破棄した場合（図６：Ｓ２３）、フィールド５０２に破棄したセッションのセッションＩＤが格納されているレコードの値をクリアする（図６：Ｓ２４）。

図７（ｂ）に示すバックアップ結果管理テーブル６００は、ユーザ端末１００バックアップ処理の実行結果を管理するためのテーブルである。バックアップ結果管理テーブル６００の各レコードは、ファイルサーバ２００に利用登録したユーザ端末１００の端末ＩＤを格納するためのフィールド６０１、当該ユーザ端末１００が設定した定期バックアップの設定内容を格納するためのフィールド６０２、当該ユーザ端末１００が設定した実行スケジュールを格納するためのフィールド６０３、当該ユーザ端末１００が前回実行したバックアップの成否（以下、前回処理結果という）を格納するためのフィールド６０４、当該ユーザ端末１００が前回実行したバックアップの開始時刻を格納するためのフィールド６０５、当該ユーザ端末１００が前回実行したバックアップの処理に要した時間（以下、前回処理時間という）を格納するためのフィールド６０６を備えている。

セッション管理部２０９は、バックアップ完了通知を受領したことに応答して（図６：Ｓ２２）、フィールド６０１に当該バックアップ完了通知に含まれるセッションＩＤに紐付いた端末ＩＤが格納されているレコードを特定し、当該レコードのフィールド６０４、６０５および６０６に、それぞれ、当該バックアップ完了通知に含まれるバックアップ処理の成否（成功または失敗）、当該バックアップ完了通知に係るバックアップの開始時刻、および、当該バックアップ完了通知に係るバックアップの処理に要した時間を格納する。

図７（ｃ）に示す予約順番管理テーブル７００は、予約ＩＤを発行したユーザ端末１００の待ち順番を管理するためのテーブルである。先述したように、本実施形態においては、予約ＩＤの発行数に上限（以下、予約ＩＤ許容発行数という）が設定されており、予約順番管理テーブル７００は、予約ＩＤ許容発行数と同数のレコードを有している。図７（ｃ）に示す例では、５つのレコードを有しており、各レコードは、ユーザ端末１００の端末ＩＤを格納するためのフィールド７０１、発行した予約ＩＤを格納するためのフィールド７０２、予約時刻を格納するためのフィールド７０３、予約ＩＤを発行したユーザ端末１００が前回実行したバックアップの処理の成否（成功または失敗）を格納するためのフィールド７０４を備えている。

本実施形態において、予約順番管理テーブル７００におけるレコードの並び順は、ユーザ端末１００の待ち順番に対応し、上位のレコードに格納されたユーザ端末１００から順番にセッションＩＤが発行される。

セッション管理部２０９は、予約ＩＤを発行する際に（図６：Ｓ４）、発行先のユーザ端末１００の端末ＩＤ、発行した予約ＩＤ、予約ＩＤの発行時刻、当該ユーザ端末１００に係る前回処理結果を、それぞれ、フィールド７０１〜７０４に格納する。また、セッション管理部２０９は、ユーザ端末１００にセッションＩＤを発行した場合、セッションＩＤを発行したユーザ端末１００のユーザＩＤが格納されているレコードの値をクリアする。

以上、セッション管理部２０９が管理するテーブルについて説明してきたが、続いて、セッション管理部２０９が実行する予約ＩＤ発行処理（図６：Ｓ４、Ｓ５）を説明する。

セッション管理部２０９は、ユーザ端末１００から予約ＩＤ要求を受領したことに応答して、図８のフローチャートに示す予約ＩＤ発行処理を開始する。なお、以下の説明においては、適宜、図７を参照するものする。

ステップＳ１０１では、予約ＩＤの空き状況を確認する。具体的には、予約順番管理テーブル７００に空きレコードがあるか否かを判断する。その結果、空きレコードがない場合（すなわち、その時点で予約ＩＤの発行数が予約ＩＤ許容発行数に達している場合）は、予約ＩＤの空きが無いと判断し（Ｓ１０２、Ｎｏ）、ユーザ端末１００にエラーを返して（Ｓ１０６）、処理を終了する。一方、空きレコードがある場合は、予約ＩＤの空きが有ると判断し（Ｓ１０２、Ｙｅｓ）、処理はステップＳ１０３に進む。

ステップＳ１０３では、予約ＩＤを発行して予約ＩＤ要求の送信元のユーザ端末１００に割り当てて、その内容を予約順番管理テーブル７００にセットする。具体的には、まず、予約ＩＤ要求に含まれる端末ＩＤ、発行した予約ＩＤおよび当該予約ＩＤの発行時刻を、それぞれ、予約順番管理テーブル７００のフィールド７０１、７０２および７０３にセットする。次に、バックアップ結果管理テーブル６００から、予約ＩＤ要求に含まれる端末ＩＤに紐付いた前回処理結果（フィールド６０４の値）を読み出し、読み出した前回処理結果を予約順番管理テーブル７００のフィールド７０４にセットする。

続くステップＳ１０４では、予約ＩＤを発行したユーザ端末１００が前回に実行したバックアップ処理の成否と予約時刻に基づいて予約の順番を並び替える。具体的には、前回処理結果（フィールド７０４の値）に「失敗」を格納するレコードが「成功」を格納するレコードよりも上位になり、且つ、予約時刻（フィールド７０３の値）により早い時刻を格納するレコードが上位になる条件で、予約順番管理テーブル７００のレコードをソートする。

最後に、ステップＳ１０３で発行した予約ＩＤを予約ＩＤ要求の送信元のユーザ端末１００に送信して（Ｓ１０５）、処理を終了する。

以上、セッション管理部２０９が実行する予約ＩＤ発行処理について説明してきたが、続いて、セッション管理部２０９が実行するセッションＩＤ発行処理（図６：Ｓ９、Ｓ１０）を説明する。なお、以下の説明においては、適宜、図７を参照するものする。

セッション管理部２０９は、ユーザ端末１００からバックアップ開始要求を受けたことに応答して、図９のフローチャートに示すセッションＩＤ発行処理を開始する。

ステップＳ２０１では、バックアップ開始要求に含まれる予約ＩＤの待ち順番が１位であるか否かを判定する。具体的には、予約順番管理テーブル７００の最上位のレコードのフィールド７０１に格納されている予約ＩＤとバックアップ開始要求に含まれる予約ＩＤが一致するか否かを判定する。その結果、予約ＩＤが一致しない場合は、待ち順番が１位でないと判定し（Ｓ２０２、Ｎｏ）、予約ＩＤ要求の送信元のユーザ端末１００にエラーを返して（Ｓ２１０）、処理を終了する。一方、予約ＩＤが一致した場合は、待ち順番が１位であると判定し（Ｓ２０２、Ｙｅｓ）、処理はステップＳ２０３に進む。

ステップＳ２０３では、ＳＭＢ通信セッションの空き状況を確認する。具体的には、ＳＭＢ通信セッション管理テーブル５００に空きレコードがあるか否かを判断する。その結果、空きレコードがある場合（すなわち、その時点でセッションＩＤの発行数がバックアップ用許容セッション数に達していない場合）は、セッションＩＤの空きが有ると判断し（Ｓ２０４、Ｙｅｓ）、処理はステップＳ２１１に進む。

ステップＳ２１１では、セッションＩＤを発行して予約ＩＤ要求の送信元のユーザ端末１００に割り当てて、その内容をＳＭＢ通信セッション管理テーブル５００にセットする。具体的には、予約ＩＤ要求に含まれる端末ＩＤおよび発行したセッションＩＤを、それぞれ、ＳＭＢ通信セッション管理テーブル５００のフィールド５０１および５０２にセットする。

続くステップＳ２１２では、発行したセッションＩＤおよび通信方式（ＳＭＢ通信）を予約ＩＤ要求の送信元のユーザ端末１００に送信して、処理を終了する。

一方、ＳＭＢ通信セッションの空きが無いと判断した場合は（Ｓ２０４、Ｎｏ）、ユーザ端末１００に係る通信方式を確認する。その結果、ユーザ端末１００に係る通信方式がＳＭＢ通信に限定する設定であった場合は（Ｓ２０５、Ｙｅｓ）、予約ＩＤ要求の送信元のユーザ端末１００にエラーを返して（Ｓ２１０）、処理を終了する。一方、ユーザ端末１００に係る通信方式がＳＭＢ通信に限定しない設定であった場合は（Ｓ２０５、Ｎｏ）、処理はステップＳ２０６に進む。

ステップＳ２０６では、セッションＩＤの空き状況を確認する（Ｓ２０７）。具体的には、ファイルサーバ２００の現在のセッション数がＯＳ２１０に設定された許容セッション数に達しているか否かを判断する。その結果、現在のセッション数が許容セッション数に達している場合は、セッションに空きがないと判断し（Ｓ２０７、Ｎｏ）、予約ＩＤ要求の送信元のユーザ端末１００にエラーを返して（Ｓ２１０）、処理を終了する。一方、現在のセッション数が許容セッション数に達していない場合は、セッションに空きがあると判断し（Ｓ２０７、Ｙｅｓ）、処理はステップＳ２０８に進む。

ステップＳ２０８では、セッションＩＤを発行して予約ＩＤ要求の送信元のユーザ端末１００に割り当てて、発行したセッションＩＤと通信方式（ＨＴＴＰ通信）を予約ＩＤ要求の送信元のユーザ端末１００に送信して（Ｓ２０９）、処理を終了する。

以上、説明したように、本実施形態によれば、バックアップ用に割り当てるＳＭＢ通信のセッション数が制限されるので、ファイルサーバ２００の帯域がデータのバックアップによって過度に占有される可能性が低減する。また、本実施形態によれば、前回のバックアップ処理に失敗したユーザ端末１００の予約の順番がより上位に並び替えられ、優先的にセッションが割り当てられるようになるので、バックアップ処理に関してユーザ間の機会の公平性が確保される。このことに相まって、本実施形態では、バックアップ用のＳＭＢ通信のセッションが使い果たされた場合に、ＳＭＢ通信よりもセッションの占有時間が短いＨＴＴＰ通信によるバックアップを実行させるので、全てのユーザ端末１００のバックアップ処理を万遍なく完了させることができる。

以上、本発明の第１実施形態を説明してきたが、続いて、本発明の第２実施形態を説明する。なお、第２実施形態の説明においては、第１実施形態の内容と共通する部分について、適宜、説明を割愛し、専ら、第１実施形態との相違点を説明するものとする。

（第２実施形態）
図１０は、本発明の第２実施形態である情報処理システム１５００のネットワーク構成を示す。情報処理システム１５００は、複数のユーザ端末１００と、情報処理装置２００（以下、ファイルサーバ２００という）と、中継装置３００（以下、中継サーバ３００という）を含んで構成されている。つまり、第２実施形態の情報処理システム１５００は、図１に示した情報処理システム１０００に対して中継サーバ３００を追加したシステムである。

ここで、中継サーバ３００は、ユーザ端末１００とファイルサーバ２００との間のデータ通信を中継する機能を備えるコンピュータ装置であり、広域ネットワーク（インターネットやＶＰＮなど）として参照されるＷＡＮ７０に接続されている。

ここで、ＷＡＮ７０とＬＡＮ６０は、ファイアーウォール３０を介して接続されており、このファイアーウォール３０は、ＬＡＮ６０の機密性を確保するためにＷＡＮ７０からＬＡＮ６０へ送信されるＨＴＴＰリクエストを遮断するので、ＬＡＮ６０の外にいるユーザ端末１００（例えば、スマートフォンとして示すユーザ端末１００ｘ）は、ＷＡＮ７０を介してＬＡＮ６０に接続されるファイルサーバ２００に直接ＨＴＴＰリクエストを送信することができない。

この点につき、第２実施形態では、中継サーバ３００がＬＡＮ６０の外にいるユーザ端末１００ｘから受信したＨＴＴＰリクエストをキューに格納し、ファイルサーバ２００からの問い合わせに応答して、キューに格納したＨＴＴＰリクエストをファイルサーバ２００に送信することにより、ＬＡＮ６０の外にいるユーザ端末１００ｘのＨＴＴＰリクエストをファイルサーバ２００に届けることができるように構成されている。

これと同様に、中継サーバ３００は、ＬＡＮ６０に接続されるユーザ端末１００（１００ａ、１００ｂ、１００ｃ…）から受信したＨＴＴＰリクエストをキューに格納し、ファイルサーバ２００からの問い合わせに応答して、キューに格納したＨＴＴＰリクエストをファイルサーバ２００に送信することにより、ＬＡＮ６０に接続されるユーザ端末１００（１００ａ、１００ｂ、１００ｃ…）のＨＴＴＰリクエストをファイルサーバ２００に届けることができる。

以上、第２実施形態の情報処理システム１５００のネットワーク構成について説明してきたが、続いて、情報処理システム１５００を構成する各装置の機能構成を図１１に示す機能ブロック図に基づいて説明する。

第２実施形態のユーザ端末１００の機能構成は、図２に示した内容と同じであるので、ここでは説明を割愛する。

第２実施形態のファイルサーバ２００は、図２に示した内容に中継サーバ処理部２１２を追加した機能構成を備える。

ここで、中継サーバ処理部２１２は、中継サーバ３００に対して定期的にＨＴＴＰ通信で問い合わせを行って、中継サーバ３００から自身に宛てたＨＴＴＰリクエストを取得するとともに、取得したＨＴＴＰリクエストを他の機能部に渡して処理を実行させ、その処理結果をＨＴＴＰ通信で中継サーバ３００に送信するための機能手段である。

一方、中継サーバ３００は、データ中継部３０２を含んで構成される。

データ中継部３０２は、ユーザ端末１００またはファイルサーバ２００との間でＨＴＴＰ通信によるデータの送受信を中継するための機能手段である。本実施形態において、データ中継部３０２は、複数のユーザ端末１００およびファイルサーバ２００のそれぞれに対するキューを備えており、各装置を宛先に指定した要求やデータを対応するキューに格納するとともに、各装置からの取得要求を受けて、対応するキューから要求やデータを取り出し、要求元の装置へ送信する。

以上、情報処理システム１５００を構成する各装置の機能構成について説明してきたが、続いて、上述した各機能手段が実行する処理の内容を説明する。なお、以下においては、専ら、第１実施形態との相違点のみを説明するものとする。

第２実施形態では、セッション管理部２０９が実行するセッションＩＤ発行処理のフロー（図９参照）のステップＳ２０９において、発行したセッションＩＤと通信方式（ＨＴＴＰ通信）を送信することに加え、バックアップ実行要求の送信先を指定する情報（以下、送信先情報という）をユーザ端末１００に送信する点が第１実施形態と相違する。以下、この点を図１２に示すシーケンス図に基づいて説明する。

最初に、ファイルサーバ２００が、セッションＩＤ、通信方式（ＨＴＴＰ通信）およびバックアップ実行要求の送信先として中継サーバ３００を指定した送信先情報をユーザ端末１００に送信した場合について説明する。この場合、ユーザ端末１００は、受信した送信先情報に指定される中継サーバ３００との間に受信したセッションＩＤを使用してＨＴＴＰ通信のセッションを確立し、確立したセッションを使用して、ファイルサーバ２００を宛先に指定したバックアップ実行要求を中継サーバ３００に送信する（Ｓ１）。これを受けて、中継サーバ３００は、ユーザ端末１００から受信したバックアップ実行要求をファイルサーバ２００のキューに格納する（Ｓ２）。

その後、中継サーバ３００は、ファイルサーバ２００からの問い合わせ（Ｓ３）に応答して、ファイルサーバ２００を宛先とするバックアップ実行要求をキューから読み出し（Ｓ４）、読み出したバックアップ実行要求をＨＴＴＰ通信でファイルサーバ２００に送信する（Ｓ５）。これを受けて、ファイルサーバ２００は、中継サーバ３００から取得したバックアップ実行要求の内容に基づいてバックアップ処理を実行する（Ｓ６）。その後、ファイルサーバ２００は、バックアップ実行要求の要求元のユーザ端末１００を宛先に指定したバックアップの実行結果を中継サーバ３００に送信する（Ｓ７）。これを受けて、中継サーバ３００は、ファイルサーバ２００から受信した実行結果を当該ユーザ端末１００のキューに格納する（Ｓ８）。

その後、中継サーバ３００は、ユーザ端末１００からの問い合わせ（Ｓ９）に応答して、当該ユーザ端末１００を宛先とするバックアップ実行結果をキューから読み出し（Ｓ１０）、読み出したバックアップ実行結果をＨＴＴＰ通信で当該ユーザ端末１００に送信する（Ｓ１１）。これを受けて、ユーザ端末１００は、ファイルサーバ２００を宛先に指定したバックアップ完了通知を中継サーバ３００に送信し（Ｓ１２）、中継サーバ３００は、ユーザ端末１００から受信したバックアップ完了通知をファイルサーバ２００のキューに格納する（Ｓ１３）。その後、中継サーバ３００は、ファイルサーバ２００からの問い合わせ（Ｓ１４）に応答して、ファイルサーバ２００を宛先とするバックアップ完了通知をキューから読み出し（Ｓ１５）、読み出したバックアップ完了通知をＨＴＴＰ通信でファイルサーバ２００に送信する（Ｓ１６）。

一方、ファイルサーバ２００が、セッションＩＤ、通信方式（ＨＴＴＰ通信）およびバックアップ実行要求の送信先としてファイルサーバ２００を指定した送信先情報をユーザ端末１００に送信した場合には、第１実施形態と同様の処理が実行される。すなわち、ユーザ端末１００がバックアップ実行要求をファイルサーバ２００に送信し（Ｓ１７）、これを受けて、ファイルサーバ２００が、受信したバックアップ実行要求の内容に基づいてバックアップ処理を実行する（Ｓ１８）。その後、ファイルサーバ２００は、バックアップの実行結果をユーザ端末１００に送信し（Ｓ１９）、これを受けて、ユーザ端末１００は、バックアップ完了通知をファイルサーバ２００に送信する（Ｓ２０）。

なお、別の実施形態では、ファイルサーバ２００の帯域の使用状況を確認し、その結果に基づいて、バックアップ実行要求の送信先を動的に決定する構成を採用してもよい。具体的には、セッション管理部２０９が実行するセッションＩＤ発行処理のフロー（図９参照）のステップＳ２０９において、ファイルサーバ２００の帯域幅の使用率を確認し、使用率が所定の閾値を超えている場合は、中継サーバ３００をバックアップ実行要求の送信先として決定し、使用率が所定の閾値を超えていない場合は、ファイルサーバ２００をバックアップ実行要求の送信先として決定する。この他にも、ファイルサーバ２００の帯域幅の使用率が所定の閾値を超える蓋然性が高い時間帯に、中継サーバ３００をバックアップ実行要求の送信先として決定するようにしてもよい。例えば、定期バックアップのスケジュールに基づいてバックアップ処理が集中する時間帯を予め特定しておき、特定した時間帯においては、一律に、中継サーバ３００をバックアップ実行要求の送信先として決定するようにしてもよい。

さらに、別の実施形態では、ファイルサーバ２００の帯域の使用状況に応じて、ファイルサーバ２００と入出力装置４０の連携の態様を動的に決定する構成を採用してもよい。この点につき、ファイルサーバ２００とプロジェクター４０ａの連携を例にとって説明する。

ここでは、本システムにおいて、図１３（ａ）に示す第１の態様と、図１３（ｂ）に示す第２の態様が選択可能に構成されていることを前提とする。すなわち、図１３（ａ）に示す第１の態様では、ユーザからページ送りの指示がある度に、Ｓ１〜Ｓ４を繰り返し実行する。すなわち、ユーザ端末１００が投影するファイルの１ページ分の出力をファイルサーバ２００に要求する（Ｓ１）。これを受けて、ファイルサーバ２００が、要求に係る１ページ分のファイルを、プロジェクター４０ａが投影可能なファイル形式の投影ファイルに変換して（Ｓ２）、プロジェクター４０ａに送信する（Ｓ３）。これを受けて、プロジェクター４０ａが受信した投影ファイル（１ページ分）を投影出力する（Ｓ４）。

上述したように、第１の態様では、投影期間中、２つのセッション（すなわち、ユーザ端末１００とファイルサーバ２００の間のセッション、および、ファイルサーバ２００とプロジェクター４０ａの間のセッション）を維持しておく必要があり、常時、２つのセッションが占有される。

一方、図１３（ｂ）に示す第２の態様では、最初に、ユーザ端末１００が全ページ分のファイルの変換をファイルサーバ２００に要求し（Ｓ１）、これを受けて、ファイルサーバ２００が、全ページ分のファイルを投影ファイルに変換して（Ｓ２）、ユーザ端末１００に提供する（Ｓ３）。その後、ユーザ端末１００は、ユーザからページ送りの指示がある度に、該当する投影ファイル（１ページ分）をプロジェクター４０ａに送信し（Ｓ４）、これを受けて、プロジェクター４０ａが受信した投影ファイル（１ページ分）を投影出力する（Ｓ５）。

上述したように、第２の態様では、ユーザ端末１００とファイルサーバ２００の間のセッションは、最初にファイルを一括変換する間だけ維持すればよく、投影期間中は、ファイルサーバ２００とプロジェクター４０ａの間の１つのセッションだけを維持すれば足りる。

上述した前提において、ファイルサーバ２００の帯域幅の使用率が所定の閾値を超えない場合には、第１の態様で、ファイルサーバ２００とプロジェクター４０ａを連携させ、ファイルサーバ２００の帯域幅の使用率が所定の閾値を超える場合（あるいはその蓋然性が高い場合）には、第２の態様で、ファイルサーバ２００とプロジェクター４０ａを連携させるようにする。これにより、ファイルサーバ２００の帯域幅の使用率が高い時間帯に、バックアップ処理にセッションが割り当てられる可能性が高くなる。

なお、投影期間中はファイルサーバ２００とプロジェクター４０ａの間のセッションを維持し続ける必要があるのに対して、印刷期間中は、ＭＦＰなどの印刷装置に対して印刷指示を送信した後に、必ずしもセッションを維持し続ける必要はなく、その都度、セッションを破棄することができる。したがって、ファイルサーバ２００と印刷装置の連携については、常時、第１の態様で行うようにしてもよい。

最後に、上述したユーザ端末１００（情報処理端末）と各サーバ（ファイルサーバ２００、中継サーバ３００）のハードウェア構成を図１４に示すハードウェア構成図に基づいて説明する。

図１４（ａ）に示すように、ユーザ端末１００（情報処理端末）を構成するコンピュータは、少なくとも、装置全体の動作を制御するプロセッサ１０と、ブートプログラムやファームウェアプログラムなどを保存するＲＯＭ１２と、プログラムを実行するための実行空間を提供するＲＡＭ１３と、オペレーティングシステム（ＯＳ１０８）や先述した「端末用アプリ」などの各種アプリケーションを保存するとともに、データ記憶領域１０９を提供する補助記憶装置１４と、操作パネルやディスプレイなどを接続する入出力インターフェース１６と、ＬＡＮ６０やＷＡＮ７０に接続するためのネットワーク・インターフェース１８とを備えている。

図１４（ｂ）に示すように、各サーバ（ファイルサーバ２００、中継サーバ３００）を構成するコンピュータは、少なくとも、装置全体の動作を制御するプロセッサ２０と、ブートプログラムやファームウェアプログラムなどを保存するＲＯＭ２２と、プログラムを実行するための実行空間を提供するＲＡＭ２３と、オペレーティングシステム（ＯＳ２１０）や先述した「サーバ用アプリ」などの各種アプリケーションを保存するとともに、データ記憶領域２１１を提供する補助記憶装置２４と、操作パネルやディスプレイなどを接続する入出力インターフェース２６と、ＬＡＮ６０やＷＡＮ７０に接続するためのネットワーク・インターフェース２８とを備えている。

なお、上述した実施形態の各機能は、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）などで記述された装置実行可能なプログラムにより実現でき、本実施形態のプログラムは、ハードディスク装置、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、フレキシブルディスク、ＥＥＰＲＯＭ、ＥＰＲＯＭなどの装置可読な記録媒体に格納して頒布することができ、また他装置が可能な形式でネットワークを介して伝送することができる。

以上、本発明について実施形態をもって説明してきたが、本発明は上述した実施形態に限定されるものではなく、当業者が推考しうる実施態様の範囲内において、本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１０…プロセッサ
１２…ＲＯＭ
１３…ＲＡＭ
１４…補助記憶装置
１６…入出力インターフェース
１８…ネットワーク・インターフェース
２０…プロセッサ
２２…ＲＯＭ
２３…ＲＡＭ
２４…補助記憶装置
２６…入出力インターフェース
２８…ネットワーク・インターフェース
３０…ファイアーウォール
４０…入出力装置
５０…バックアップ設定画面
５２…チェックボックス
５３,５４,５６,５８…設定欄
６０…ＬＡＮ
７０…ＷＡＮ
１００…ユーザ端末（情報処理端末）
１０２…ＧＵＩ処理部
１０３…ＷｅｂＡＰＩ処理部
１０４…ＳＭＢ処理部
１０５…バックアップ処理部
１０６…設定情報管理部
１０７…定期実行部
１０８…オペレーティングシステム
１０９…データ記憶領域
２００…ファイルサーバ（情報処理装置）
２０２…ＷｅｂＡＰＩ処理部
２０３…ＷｅｂＵＩ処理部
２０４…デバイス登録処理部
２０５…入出力処理部
２０６…バックアップ処理部
２０７…設定情報管理部
２０８…ドキュメント処理部
２０９…セッション管理部
２１０…オペレーティングシステム
２１１…データ記憶領域
２１２…中継サーバ処理部
３００…中継サーバ
３０２…データ中継部
５００…ＳＭＢ通信セッション管理テーブル
５０１,５０２,５０３,５０４…フィールド
６００…バックアップ結果管理テーブル
６０１,６０２,６０３,６０４,６０５,６０６…フィールド
７００…予約順番管理テーブル
７０１,７０２,７０３,７０４…フィールド
１０００…情報処理システム
１５００…情報処理システム

特開２００５−６３３６３号公報

Claims (10)

1. ネットワーク上に配置され、データのバックアップ先に設定される情報処理装置であって、
   前記ネットワークを経由してバックアップの開始を要求されたときに、ファイル共有プロトコルの通信でバックアップを実行しているセッションの数に基づいて、バックアップを要求する要求元にバックアップ用のセッションを割り当てるセッション管理手段
   を含む、
   情報処理装置。
2. 前記セッション管理手段は、
   前記ネットワークを経由してバックアップの開始を要求されたときに、前記ファイル共有プロトコルの通信でバックアップを実行しているセッションの数が所定の上限に達していない場合は、割り当てた前記セッションの通信方式として前記ファイル共有プロトコルを指定し、該セッションの数が所定の上限に達している場合は、割り当てた前記セッションの通信方式としてＨＴＴＰプロトコルを指定する、
   請求項１に記載の情報処理装置。
3. 複数の情報処理端末と該情報処理端末のデータのバックアップ先に設定された情報処理装置とがネットワークを介して接続された情報処理システムであって、
   前記情報処理端末は、
   前記情報処理装置に対してバックアップの開始を要求するバックアップ開始要求手段と、
   ファイル共有プロトコルの通信でデータのバックアップを行う第１のバックアップ手段と、
   ＨＴＴＰプロトコルの通信でデータのバックアップを行う第２のバックアップ手段と、
   を含み、
   前記情報処理装置は、
   前記情報処理端末からバックアップの開始を要求されたときに、前記ファイル共有プロトコルの通信でバックアップを実行しているセッションの数に基づいて、バックアップを要求する要求元にバックアップ用のセッションを割り当てるセッション管理手段を含む、
   情報処理システム。
4. 前記セッション管理手段は、
   前記情報処理端末からバックアップの開始を要求されたときに、前記ファイル共有プロトコルの通信でバックアップを実行しているセッションの数が所定の上限に達していない場合は、割り当てた前記セッションの通信方式として前記ファイル共有プロトコルを指定し、該セッションの数が所定の上限に達している場合は、割り当てた前記セッションの通信方式として前記ＨＴＴＰプロトコルを指定する、
   請求項３に記載の情報処理システム。
5. 前記バックアップ開始要求手段は、
   定期的に前記情報処理装置に対してバックアップの開始を要求し、
   前記情報処理端末は、
   バックアップの処理の成否を前記情報処理装置に通知する通知手段を含み、
   前記セッション管理手段は、
   前回のバックアップの処理に失敗した前記情報処理端末に対して優先的にセッションを割り当てる、
   請求項４に記載の情報処理システム。
6. 前記情報処理装置は、
   前記通知手段から通知を受けたときに、該通知に係るバックアップに使用していた通信のセッションを破棄する、
   請求項５に記載の情報処理システム。
7. 宛先が指定されたデータを受信し該データを指定された宛先に送信する中継装置が前記ネットワークに接続され、
   前記第２のバックアップ手段は、
   前記通信方式として前記ＨＴＴＰプロトコルが指定された場合に、前記情報処理装置を宛先に指定したデータを前記中継装置に送信することによってデータのバックアップを行う、
   請求項４〜６のいずれか一項に記載の情報処理システム。
8. 前記ファイル共有プロトコルは、ＳＭＢプロトコルである、
   請求項４〜７のいずれか一項に記載の情報処理システム。
9. 複数の情報処理端末と該情報処理端末のデータのバックアップ先に設定された情報処理装置とがネットワークを介して接続された情報処理システムにおいて実行される方法であって、
   前記情報処理端末が、
   前記情報処理装置に対してバックアップの開始を要求するステップ、
   ファイル共有プロトコルの通信でデータのバックアップを行うステップ、
   ＨＴＴＰプロトコルの通信でデータのバックアップを行うステップ、
   を実行し、
   前記情報処理装置が、
   前記情報処理端末からバックアップの開始を要求されたときに、前記ファイル共有プロトコルの通信でバックアップを実行しているセッションの数に基づいて、バックアップを要求する要求元にバックアップ用のセッションを割り当てるステップを実行する、
   方法。
10. 前記セッションを割り当てるステップは、
    前記情報処理端末からバックアップの開始を要求されたときに、前記ファイル共有プロトコルの通信でバックアップを実行しているセッションの数が所定の上限に達していない場合は、割り当てた前記セッションの通信方式として前記ファイル共有プロトコルを指定し、該セッションの数が所定の上限に達している場合は、割り当てた前記セッションの通信方式として前記ＨＴＴＰプロトコルを指定するステップを含む、
    請求項９に記載の方法。