(57)【要約】【課題】ホットフォルダに投入されたデータの投入順序を維持して処理することを目的とする。【解決手段】ホットフォルダへのファイルの投入に係るファイル操作イベントを受け取ると、ファイルの妥当性を判定する判定手段と、判定手段によりファイルの妥当性が確認された場合、ファイルのファイル情報をファイルのホットフォルダへの投入順序を維持したままファイル情報を記憶領域に記憶する記憶手段と、記憶領域に未送信のファイル情報が存在するか否かを判定する未送信判定手段と、未送信判定手段で未送信のファイル情報が存在すると判定された場合、未送信のファイル情報を送信する送信手段と、を有することによって課題を解決する。【選択図】図８
2014219920.tif 000002
【特許請求の範囲】
【請求項１】
ホットフォルダへのファイルの投入に係るファイル操作イベントを受け取ると、前記ファイルの妥当性を判定する判定手段と、
前記判定手段により前記ファイルの妥当性が確認された場合、前記ファイルのファイル情報を前記ファイルのホットフォルダへの投入順序を維持したままファイル情報を記憶領域に記憶する記憶手段と、
前記記憶領域に未送信のファイル情報が存在するか否かを判定する未送信判定手段と、
前記未送信判定手段で未送信のファイル情報が存在すると判定された場合、前記未送信のファイル情報を送信する送信手段と、
を有する情報処理装置。
【請求項２】
前記送信手段は、前記未送信判定手段で未送信のファイル情報が存在すると判定された場合、サーバとの通信に係るネットワーク状態を確認し、前記サーバと通信可能な場合は、前記未送信のファイル情報を前記サーバに送信する請求項１記載の情報処理装置。
【請求項３】
前記送信手段は、前記未送信のファイル情報をファイルシステム上のフォルダに送信する請求項１記載の情報処理装置。
【請求項４】
前記未送信判定手段は、前記記憶手段によって前記ファイル情報が記憶領域に保存されると、前記判定を行う請求項１乃至３何れか１項記載の情報処理装置。
【請求項５】
前記未送信判定手段は、設定された時間になると、前記判定を行う請求項１乃至３何れか１項記載の情報処理装置。
【請求項６】
画面を介した監視対象のフォルダの追加要求に基づき、ファイルシステム上に指定されたフォルダが存在する場合は、前記フォルダを監視対象のホットフォルダとし、ファイルシステム上に指定されたフォルダが存在しない場合は、前記フォルダを作成し、監視対象のホットフォルダとする追加手段を更に有する請求項１乃至５何れか１項記載の情報処理装置。
【請求項７】
ホットフォルダへのファイルの投入に係るファイル操作イベントを受け取ると、前記ファイルの妥当性を判定する判定手段と、
前記判定手段により前記ファイルの妥当性が確認された場合、前記ファイルのファイル情報を前記ファイルのホットフォルダへの投入順序を維持したままファイル情報を記憶領域に記憶する記憶手段と、
前記記憶領域に未送信のファイル情報が存在するか否かを判定する未送信判定手段と、
前記未送信判定手段で未送信のファイル情報が存在すると判定された場合、前記未送信のファイル情報を送信する送信手段と、
を有するシステム。
【請求項８】
クライアント装置と、サーバ装置と、を含むシステムであって、
前記クライアント装置は、ホットフォルダクライアント手段を有し、
前記ホットフォルダクライアント手段は、
ホットフォルダへのファイルの投入に係るファイル操作イベントを受け取ると、前記ファイルの妥当性を判定する判定手段と、
前記判定手段により前記ファイルの妥当性が確認された場合、前記ファイルのファイル情報を前記ファイルのホットフォルダへの投入順序を維持したままファイル情報を記憶領域に記憶する記憶手段と、
前記記憶領域に未送信のファイル情報が存在するか否かを判定する未送信判定手段と、
前記未送信判定手段で未送信のファイル情報が存在すると判定された場合、前記未送信のファイル情報を送信する送信手段と、
を有し、
前記サーバ装置は、ホットフォルダサーバ手段を有し、
前記ホットフォルダサーバ手段は、
複数のホットフォルダクライアント手段を管理するホットフォルダ管理手段を有し、
前記ホットフォルダ管理手段は、前記送信手段により送信されたファイル情報を、投入順序を維持したまま管理するシステム。
【請求項９】
情報処理装置が実行する情報処理方法であって、
ホットフォルダへのファイルの投入に係るファイル操作イベントを受け取ると、前記ファイルの妥当性を判定する判定ステップと、
前記判定ステップにより前記ファイルの妥当性が確認された場合、前記ファイルのファイル情報を前記ファイルのホットフォルダへの投入順序を維持したままファイル情報を記憶領域に記憶する記憶ステップと、
前記記憶領域に未送信のファイル情報が存在するか否かを判定する未送信判定ステップと、
前記未送信判定ステップで未送信のファイル情報が存在すると判定された場合、前記未送信のファイル情報を送信する送信ステップと、
を含む情報処理方法。
【請求項１０】
システムが実行する情報処理方法であって、
ホットフォルダへのファイルの投入に係るファイル操作イベントを受け取ると、前記ファイルの妥当性を判定する判定ステップと、
前記判定ステップにより前記ファイルの妥当性が確認された場合、前記ファイルのファイル情報を前記ファイルのホットフォルダへの投入順序を維持したままファイル情報を記憶領域に記憶する記憶ステップと、
前記記憶領域に未送信のファイル情報が存在するか否かを判定する未送信判定ステップと、
前記未送信判定ステップで未送信のファイル情報が存在すると判定された場合、前記未送信のファイル情報を送信する送信ステップと、
を含む情報処理方法。
【請求項１１】
クライアント装置と、サーバ装置と、を含むシステムが実行する情報処理方法であって、
前記クライアント装置は、ホットフォルダクライアント手段を有し、
前記サーバ装置は、ホットフォルダサーバ手段を有し、
前記ホットフォルダクライアント手段が、
ホットフォルダへのファイルの投入に係るファイル操作イベントを受け取ると、前記ファイルの妥当性を判定する判定ステップと、
前記判定ステップにより前記ファイルの妥当性が確認された場合、前記ファイルのファイル情報を前記ファイルのホットフォルダへの投入順序を維持したままファイル情報を記憶領域に記憶する記憶ステップと、
前記記憶領域に未送信のファイル情報が存在するか否かを判定する未送信判定ステップと、
前記未送信判定ステップで未送信のファイル情報が存在すると判定された場合、前記未送信のファイル情報を送信する送信ステップと、
前記ホットフォルダサーバ手段が、
複数のホットフォルダクライアントステップを管理するホットフォルダ管理ステップを含み、
前記ホットフォルダ管理ステップでは、前記送信ステップにより送信されたファイル情報を、投入順序を維持したまま管理する情報処理方法。
【請求項１２】
コンピュータに、
ホットフォルダへのファイルの投入に係るファイル操作イベントを受け取ると、前記ファイルの妥当性を判定する判定ステップと、
前記判定ステップにより前記ファイルの妥当性が確認された場合、前記ファイルのファイル情報を前記ファイルのホットフォルダへの投入順序を維持したままファイル情報を記憶領域に記憶する記憶ステップと、
前記記憶領域に未送信のファイル情報が存在するか否かを判定する未送信判定ステップと、
前記未送信判定ステップで未送信のファイル情報が存在すると判定された場合、前記未送信のファイル情報を送信する送信ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、システム、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
フォルダにデータが投入されたことを検知することで、そのフォルダに指定された処理を実行するホットフォルダ機能がある（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２２７９９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１の技術では、ホットフォルダに設定されたフォルダを有するＰＣと、前記フォルダを監視するＰＣとが異なる際に、ＰＣのＯＳが異なる可能性があることが考慮されていなかった。ＰＣのＯＳが互いに異なる場合等、ホットフォルダに投入されたデータの投入順序を維持することができない場合があった。
【０００５】
本発明は、ホットフォルダに投入されたデータの投入順序を維持して処理することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明は、ホットフォルダへのファイルの投入に係るファイル操作イベントを受け取ると、前記ファイルの妥当性を判定する判定手段と、前記判定手段により前記ファイルの妥当性が確認された場合、前記ファイルのファイル情報を前記ファイルのホットフォルダへの投入順序を維持したままファイル情報を記憶領域に記憶する記憶手段と、前記記憶領域に未送信のファイル情報が存在するか否かを判定する未送信判定手段と、前記未送信判定手段で未送信のファイル情報が存在すると判定された場合、前記未送信のファイル情報を送信する送信手段と、を有する。
【発明の効果】
【０００７】
本発明によれば、ホットフォルダに投入されたデータの投入順序を維持して処理することができる。
【図面の簡単な説明】
【０００８】
【図１】ホットフォルダシステムのシステム構成の一例を示す図である。
【図２】ホットフォルダクライアントのハードウェア構成の一例を示す図である。
【図３】ホットフォルダシステムのソフトウェア構成の一例を示す図である。
【図４】ホットフォルダ管理部とやり取りするホットフォルダ管理ＧＵＩの一例を示す図である。
【図５】監視対象フォルダ新規追加ダイアログの一例を示す図である。
【図６】クライアント管理テーブルの一例を示す図である。
【図７】監視対象フォルダテーブルの一例を示す図である。
【図８】ホットフォルダクライアントにおけるジョブ投入動作における内部処理の一例を示すフローチャートである。
【図９】ファイル投入の順序性を維持しながら通信のオーバーヘッドを低くするための処理の一例を示すフローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
はじめに、課題の一例について説明する。
ホットフォルダに設定されたフォルダを有するＰＣが、前記フォルダを監視する場合、フォルダにファイル等が置かれたことを検知すると、このファイルをロックするか、又は自身のワークフォルダ等に移動させる。これは、ホットフォルダに投入されたファイル等に設定された処理（例えば、印刷処理）等を実行しようとしている際に、他のシステム等が前記ファイル等にアクセスしてきた場合、前記処理が正常に行われない場合があるからである。
しかし、ホットフォルダに設定されたフォルダを有するＰＣと、前記フォルダを監視する機能が実装されたＰＣと、が異なる場合がある。この場合において、それぞれのＰＣのＯＳが、例えば、Ｗｉｎｄｏｗｓ（登録商標）ＯＳとＭａｃｈｉｎｔｏｓｈ（登録商標）ＯＳとだとする。この場合、ホットフォルダへのファイル等が投入されることに伴うファイルの複製が終了する前に、ロックされたり、ワークフォルダ等への移動がなされたりする場合がある。その結果、ホットフォルダへのファイルの複製は完了していないため、中途半端なデータで印刷処理等がなされてしまう場合がある。
このような状況を避ける方法の一つとして、定期監視、即ち、一定時間の経過毎にファイルのサイズを検知する方法がある。しかし、この様な方法の場合、一定期間の監視で複数のファイルを同時に検出した場合、ファイルの投入に係る順序性を保証することができなかった。
【００１１】
＜実施形態１＞
（システム構成）
図１は、ホットフォルダシステムのシステム構成の一例を示す図である。図１に示されるように、ホットフォルダシステムは、複数のホットフォルダクライアント１０１と、ホットフォルダサーバ１０２と、１つ以上のデバイス１０３と、を含む。
ホットフォルダクライアントは情報処理装置の一例である。
【００１２】
（ハードウェア構成）
図２は、ホットフォルダクライアントのハードウェア構成の一例を示す図である。
図２に示されるように、ホットフォルダクライアントは、ＣＰＵ１１と、ＲＡＭ１３と、ＲＯＭ１４と、ＨＤやＦＤ等の外部メモリ１６と、Ｉ／Ｏ１７と、を含む。
ＣＰＵ１１は、ＲＯＭ１４又は外部メモリ１６に記憶されているプログラムをＲＡＭ１３に読み出し、ＲＡＭ１３を使用しながらプログラムを実行する。ＣＰＵ１１がプログラムに基づき処理を実行することによって、ホットフォルダクライアントのソフトウェア構成及びホットフォルダクライアントのフローチャートの処理が実現される。
Ｉ／Ｏ１７は、ホットフォルダクライアントのインターフェースである。ホットフォルダクライアントは、Ｉ／Ｏ１７を介して、ホットフォルダサーバ１０２と接続される。
ホットフォルダサーバ１０２もホットフォルダクライアントと同様のハードウェア構成を有する。ホットフォルダサーバ１０２のＣＰＵがホットフォルダサーバ１０２のＲＯＭ又は外部メモリに記憶されているプログラムに基づき処理を実行する。このことによってホットフォルダサーバ１０２のソフトウェア構成等が実現される。デバイスも同様である。
【００１３】
（ソフトウェア構成）
図３は、ホットフォルダシステムのソフトウェア構成の一例を示す図である。
クライアントモジュール２０１、２０２、２０３は、それぞれホットフォルダのクライアントモジュールである。サーバモジュール２０４は、ホットフォルダのサーバモジュールである。デバイス２０５、２０６、２０７は、それぞれ画像処理装置等のデバイスを指す。
本実施形態では、図１に示したように、複数のホットフォルダクライアント１０１にクライアントモジュール２０１、２０２、２０３が別々に実装され、ホットフォルダサーバ１０２にサーバモジュール２０４が実装されているものとして説明を行う。但し、同じＰＣ上に一つのクライアントモジュール（例えば、クライアントモジュール２０３）とサーバモジュール２０４とが実装されていてもよい。また、１つのＰＣ上に複数の仮想環境が構築されている場合、各仮想環境にクライアントモジュールが実装されていてもよい。
クライアントモジュール２０１を例に説明を行う。
クライアントモジュール２０１は、フォルダ監視部２０１１、情報送信部２０１２、制御受信部２０１３を含む。フォルダ監視部２０１１は、ホットフォルダとして設定されたフォルダを監視する。情報送信部２０１２は、サーバモジュールに情報を送信する。制御受信部２０１３は、サーバモジュールからホットフォルダの追加、削除等の制御に係る情報を受信する。
【００１４】
サーバモジュール２０４は、クライアント管理部２０４１と、ジョブ管理部２０４２と、イベント管理部２０４３と、ホットフォルダ管理部２０４４と、デバイス管理部２０４５と、を含む。
クライアント管理部２０４１は、１以上のクライアントモジュールと接続しそれらを管理する。ジョブ管理部２０４２は、ジョブを管理する。イベント管理部２０４３は、イベントを管理する。ホットフォルダ管理部２０４４は、ホットフォルダを管理する。デバイス管理部２０４５は、１以上のデバイスと接続しそれらを管理する。
クライアント管理部２０４１の管理するクライアントモジュールは１つ以上のクライアントモジュールである。また、デバイス管理部２０４５の管理するデバイスは１つ以上のデバイスである。
また、クライアント管理部２０４１には、クライアントを制御するクライアント制御部とクライアントからの情報を受信するクライアント情報受信部とが含まれている。
ホットフォルダサーバとホットフォルダクライアントとの通信方式として、本実施形態ではＬＡＮを使用したネットワーク通信を使用するものとして説明するが、その他の通信方式であってもよい。
【００１５】
（ホットフォルダ管理ＧＵＩ）
図４は、ホットフォルダ管理部とやり取りするホットフォルダ管理ＧＵＩの一例を示す図である。ホットフォルダ管理ＧＵＩ３００は、サーバモジュールが実装されたＰＣ上でサーバモジュールと通信するサーバのアプリケーションであってもよい。また、ホットフォルダ管理ＧＵＩ３００は、クライアントモジュールが実装されたＰＣ上で情報送信部２０１２を介してサーバモジュールと通信するクライアントのアプリケーションであってもよい。
ホットフォルダ管理ＧＵＩ３００は、フォルダリスト３０１を表示し、３０２〜３０６のホットフォルダ操作ボタンを有する。
ホットフォルダ管理ＧＵＩは画面の一例である。
【００１６】
（監視対象フォルダ新規追加、削除）
監視対象のフォルダ新規追加について説明する。
オペレータは、監視対象フォルダを新規追加するに当たり、フォルダ操作ボタンであるＮｅｗボタン３０２を押下する。ボタンの押下によって、図５に示す監視対象フォルダ新規追加ダイアログ４００がポップアップする。
オペレータは、監視対象フォルダ名４０１、フォルダ追加先となるＰＣ名４０２、ジョブ出力先となるデバイス名４０３等を監視対象フォルダ新規追加ダイアログに入力した後、ＯＫボタン４０４を押下する。この操作により、ホットフォルダ管理部２０４４に、新規追加する監視対象フォルダの情報が伝えられる。
ホットフォルダ管理部２０４４は、クライアント管理部２０４１に対してＰＣ名４０２が管理対象かどうかを問い合わせる。クライアント管理部２０４１は、図６に示すクライアント管理テーブル５００を検索し、問い合わせのあったＰＣ名が、クライアント管理テーブル５００に存在するかどうかを確認し、確認した結果をホットフォルダ管理部２０４４に返信する。
クライアント管理テーブル５００は、クライアントＩＤ（ＣｌｉｅｎｔＩＤ）５０１、クライアントＰＣ名（ＰＣ  Ｎａｍｅ（ＩＰ  Ａｄｄｒｅｓｓ））５０２等からなり、ホットフォルダクライアントに関する情報が管理されている。
【００１７】
問い合わせたＰＣがクライアント管理テーブル５００に存在しなかった場合は、ホットフォルダクライアントが立ち上がっていない場合や、ホットフォルダクライアントが未インストール状態である可能性がある。したがって、ホットフォルダ管理部２０４４は、オペレータにその旨を通知して、ホットフォルダの新規追加情報をクライアント管理テーブル５００に保存するかどうかを確認する。
問い合わせたＰＣがクライアント管理テーブル５００に存在した場合、ホットフォルダ管理部２０４４は、クライアント管理部２０４１を経由して、ＰＣ上のホットフォルダクライアント、若しくはその制御受信部に対して監視対象フォルダの新規追加を依頼する。つまり、ホットフォルダ管理部２０４４は、追加要求を送信する。
ホットフォルダクライアントは、依頼された監視対象フォルダ名が自身の配置されたＰＣ上のファイルシステム上に存在するかどうかを確認し、存在した場合は同フォルダを監視対象とする。存在しなかった場合は、ホットフォルダクライアントは、新規のフォルダを作成し、同フォルダを監視対象とした後にホットフォルダ管理部２０４４に成功を返す。
【００１８】
ホットフォルダ管理部２０４４は、前記応答を受信した後に図７に示す監視対象フォルダテーブル６００に新規の監視対象フォルダを追加する。
監視対象フォルダテーブル６００は、ホットフォルダＩＤ（ＨｏｔＦｏｌｄｅｒ  ＩＤ）６０１、監視先クライアントＩＤ（Ｃｌｉｎｅｔ  ＩＤ）６０２、フォルダパス（Ｆｏｌｄｅｒ  Ｐａｔｈ）６０３等の情報を含む。また、監視対象フォルダテーブル６００は、フォルダ名（Ｆｌｏｌｄｅｒ  Ｎａｍｅ）６０４等の情報を含む。ホットフォルダ管理部２０４４は、監視対象フォルダテーブル６００を用いてホットフォルダシステムの監視対象であるフォルダを管理する。
【００１９】
監視対象フォルダの新規追加に続いて、監視対象フォルダの削除について説明する。
オペレータは、フォルダリスト３０１から任意の行を選択しホットフォルダ削除ボタン３０４を押下する。意思確認ダイアログ等によって操作が確定すると、オペレータの操作情報がホットフォルダ管理部２０４４に通知される。
ホットフォルダ管理部２０４４は、監視対象フォルダリストの情報を基にして、対象のホットフォルダクライアントに対し、クライアント管理部２０４１を経由して監視対象フォルダの削除を依頼する。ホットフォルダクライアントは、依頼を受信後、ホットフォルダの監視を停止し、その応答をホットフォルダ管理部２０４４に返す。ホットフォルダ管理部２０４４は、監視対象フォルダテーブル６００から、依頼のあったフォルダの情報を削除して、その後、監視対象フォルダテーブル６００の更新イベントを、クライアント管理部２０４１経由で各ホットフォルダクライアントに送信する。
【００２０】
（フォルダ監視開始、フォルダ監視停止）
フォルダ監視開始、フォルダ監視停止について説明する。
オペレータは、フォルダリスト３０１からＭｏｎｉｔｏｒステータス（Ｓｔａｔｕｓ）がＯｆｆとなっている任意の行を選択しフォルダ監視開始ボタン（Ｓｔａｒｔボタン）３０５を押下する。意思確認ダイアログによって操作が確定すると、操作情報はホットフォルダ管理部２０４４に通知される。
ホットフォルダ管理部２０４４は、監視対象フォルダリストの情報を基にして、対象のホットフォルダクライアントに対し、クライアント管理部２０４１を経由して監視対象フォルダの監視開始を依頼する。ホットフォルダクライアントは、依頼を受信後、ホットフォルダの監視を開始し、その応答をホットフォルダ管理部２０４４に返す。ホットフォルダ管理部２０４４は、監視対象フォルダテーブル６００から、オペレータより依頼のあったフォルダのＭｏｎｉｔｏｒステータス情報を更新する。その後、ホットフォルダ管理部２０４４は、監視対象フォルダテーブル６００の更新イベントを、クライアント管理部２０４１経由で各ホットフォルダクライアントに送信する。
【００２１】
フォルダ監視停止について説明する。
オペレータは、フォルダリスト３０１からＭｏｎｉｔｏｒステータスがＯｎとなっている任意の行を選択しフォルダ監視停止ボタン（Ｓｔｏｐボタン）３０６を押下する。意思確認ダイアログによって操作が確定すると、操作情報はホットフォルダ管理部２０４４に通知される。
ホットフォルダ管理部２０４４は、監視対象フォルダリストの情報を基にして、対象のホットフォルダクライアントに対し、クライアント管理部２０４１を経由して監視対象フォルダの監視の停止を依頼する。ホットフォルダクライアントは、依頼を受信後、ホットフォルダの監視を停止し、その応答をホットフォルダ管理部２０４４に返す。ホットフォルダ管理部２０４４は、監視対象フォルダテーブル６００から、オペレータより依頼のあったフォルダのＭｏｎｉｔｏｒステータス情報を更新する。その後、ホットフォルダ管理部２０４４は、監視対象フォルダテーブル６００の更新イベントを、クライアント管理部２０４１経由で各ホットフォルダクライアントに送信する。
【００２２】
前述の（フォルダ監視開始、フォルダ監視停止）で説明した手段の代わりに、全フォルダの一括監視停止ボタンのような一括操作ボタンを用意してもよい。同ボタンが押下されると、ホットフォルダ管理部２０４４の管理する監視対象フォルダテーブル６００にある全ての監視対象フォルダに対して一括で監視を停止する事が可能となる。また一括監視開始ボタンを用意する事で、全ての監視対象フォルダに対して一括で監視を停止させる事が可能となる。
この際、ホットフォルダクライアントとホットフォルダ管理部２０４４との間で、一括命令、若しくは一度の依頼で複数の対象フォルダを指定可能とする方法を用意しておく。このようにすることによって、例えば一つ以上の監視対象フォルダが同一ホットフォルダクライアントに属していた場合にもフォルダ毎に複数回、命令を発行しなくてすむようになる。
以上の（ホットフォルダの新規追加、削除）並びに（ホットフォルダの監視、監視停止）で説明したように、ホットフォルダサーバは、複数のホットフォルダクライアントを集中管理する事ができる。本実施形態ではホットフォルダ管理ＧＵＩを用いた例を説明しているが、ＧＵＩの代わりにＡＰＩを用意し、他のアプリケーション等から管理を行ってもよい。
【００２３】
（ホットフォルダへのジョブ投入）
図３のホットフォルダのクライアントモジュール２０１を例として、ホットフォルダへのジョブ投入処理の一例を説明する。
クライアントモジュール２０１におけるフォルダ監視部２０１１は、サーバモジュール２０４から指定された一つ以上のフォルダを監視する。
フォルダの監視方法はその代表的な手段として、一定の間隔で監視対象フォルダの状態を監視する定期監視と、監視対象フォルダに対するファイル操作をイベントとしてＯＳから受信するイベント監視と、の２種類があり、それらを組み合せる事も可能である。本実施形態は監視方法としてイベント監視方法について説明する。イベント監視方法はファイル投入順序を取得できるため、順序性の確保に好適だからである。
【００２４】
図８は、ホットフォルダクライアントにおけるジョブ投入動作における内部処理の一例を示すフローチャートである。本フローチャートにおいては、ＯＳからのファイル操作イベントをトリガとして処理が開始される。
Ｓ７０１では、クライアントモジュールは、ファイルの妥当性チェックとしてファイル名、拡張子、ファイルヘッダ等をチェックし、検出したファイルがホットフォルダの処理対象かどうかをチェック（判定）する。ここで監視対象外のファイルを検出した場合、クライアントモジュール２０１同ファイルを監視対象フォルダから削除移動してもよい。
Ｓ７０２では、クライアントモジュールは、監視対象ファイルの情報をファイル情報記憶部に保存する。クライアントモジュールは、ファイル情報記憶部に、ファイル毎にファイル名、フォルダ名、ファイル状態、等の情報を記憶する。また、ファイル情報記憶部は少なくとも一つ以上のファイル情報を保持する事ができる。クライアントモジュールは、この一つ以上のファイル情報をファイル情報記憶部に記憶する際、その順序性を維持したまま記憶する。ファイル情報記憶部は、ホットフォルダクライアント１０１の単一の記憶領域でもよいし、例えばフォルダ毎や処理対象デバイス毎に記憶領域を分けておいてもよい。
ファイル情報記憶部は、記憶領域の一例である。
【００２５】
Ｓ７０３では、クライアントモジュールは、ファイル情報記憶部に未送信のファイル情報が存在するかどうかをチェック（未送信判定）する。
Ｓ７０４では、クライアントモジュールは、ネットワーク状態を確認する。より具体的にはホットフォルダクライアントからホットフォルダサーバへの通信可能かどうかをチェックする。
Ｓ７０５では、クライアントモジュールは、ファイル情報記憶部に記憶しているファイル情報をホットフォルダサーバに送信する。記憶領域にファイル情報が複数有る場合、クライアントモジュールは、それらをまとめて送信する事ができる。この際、クライアントモジュールは、例えばファイル情報を監視対象のフォルダ毎にまとめたり、処理対象デバイス毎にまとめたりして送信してもよい。それによりファイル情報をホットフォルダサーバが利用する際の利便性が向上する。
【００２６】
Ｓ７０６では、クライアントモジュールは、ホットフォルダサーバに送信し終えたファイル情報をファイル情報記憶部から一部又は全て削除する。
図７のフローチャートの処理によれば、ＯＳから受信するファイル操作イベント毎に、ホットフォルダクライアントからホットフォルダサーバにファイル情報を送信可能となり、ファイル投入順序に則ったジョブ処理が可能となる。
また、サブフローの処理中にホットフォルダクライアントとホットフォルダサーバとの間のネットワークが切断されたとしても、ホットフォルダクライアントでフォルダ監視が続行されるため、ネットワーク接続状態がジョブ処理順序に対して与える影響を低減できる。
【００２７】
これまでに説明した通り、図７のフローチャートの処理によりファイル投入の順序性に則った処理が可能となる。しかし、ホットフォルダクライアントの数や監視対象のフォルダ数が増えたり、フォルダに投入されるファイルの投入頻度が高かったりする場合、ホットフォルダクライアントとホットフォルダサーバとの間の通信のオーバーヘッドが問題となる場合がある。
そこで、図９の（ａ）はこれらの問題を鑑み、ファイル投入の順序性を維持しながら通信のオーバーヘッドを低くするための処理の一例を示すフローチャートである。以下、フローチャートの処理を説明する。
図９の（ａ）は、ＯＳからのファイル操作イベントをトリガとして開始するサブのフローチャートである。
Ｓ８０１では、クライアントモジュールは、ファイルの妥当性チェックとしてファイル名、拡張子、ファイルヘッダ等をチェックし、検出したファイルがホットフォルダの処理対象かどうかをチェックする。ここで、クライアントモジュールは、監視対象外のファイルを検出した場合は、同ファイルを監視対象フォルダから削除、又は移動してもよい。
Ｓ８０２では、クライアントモジュールは、監視対象ファイルの情報をファイル情報記憶部に保存する。ファイル情報記憶部は、ファイル毎にファイル名、フォルダ名、ファイル状態、等の情報を記憶する。また、ファイル情報記憶部は、少なくとも一つ以上のファイル情報を保持する事ができる。ファイル情報記憶部は単一の記憶領域でもよいし、例えばフォルダ毎や処理対象デバイス毎に記憶領域を分けておいてもよい。
以上でサブのフローチャートの処理は終了となり、フォルダ監視部２０１１は、再度ＯＳからのファイル操作イベントを待つ。
【００２８】
さて、ホットフォルダクライアントでは上記サブのフローチャートとは別の図９の（ｂ）に示すサブのフローチャートを実行する。図９の（ｂ）サブのフローチャートは、予め設定した時間が経過した後のタイムアウトイベントをトリガとして動作する。
予め設定した時間としてはホットフォルダクライアントやホットフォルダサーバ上のファイル等に予め保存された時間を使用してもよいし、使用者が任意の値を与える事ができてもよい。ファイルの投入頻度やデバイスの処理能力を鑑み、監視対象フォルダ毎や、処理対象のデバイス毎に時間を設定可能とする事ができてもよい。
Ｓ８０３では、クライアントモジュールは、ファイル情報記憶部に未送信のファイル情報が存在するかどうかをチェックする。
Ｓ８０４では、クライアントモジュールは、ネットワーク状態を確認する。より具体的には、クライアントモジュールは、ホットフォルダクライアントからホットフォルダサーバへの通信が可能かどうかをチェックする。
【００２９】
Ｓ８０５では、クライアントモジュールは、ファイル情報記憶部に記憶しているファイル情報をホットフォルダサーバに送信する。記憶領域にファイル情報が複数有る場合、クライアントモジュールは、それらをまとめて送信する事ができる。この際、クライアントモジュールは、例えばファイル情報を監視対象のフォルダ毎にまとめたり、処理対象デバイス毎にまとめたりして送信してもよい。それによりファイル情報をホットフォルダサーバが利用する際の利便性が向上する。
Ｓ８０６では、クライアントモジュールは、ホットフォルダサーバに送信し終えたファイル情報をファイル情報記憶部から一部又は全て削除する。
このフローチャートの処理によれば、ホットフォルダクライアントとホットフォルダサーバとの間の通信の頻度を減らしつつ、ファイル投入順序に則ったジョブ処理が可能となる。
本実施形態においては、通信部に関しては、通信自体が可能であればどのような通信部を用いてもよい。ＴＣＰ／ＩＰ以外にもシリアル通信やＷｅｂＡＰＩ等であってもよい。
また監視対象はファイルに限らず、フォルダであってもよい。
【００３０】
＜実施形態２＞
実施形態１では、ホットフォルダクライアントがホットフォルダサーバに対してファイル情報を送信した。本実施形態のクライアントモジュールは、ホットフォルダクライアントを配置したＰＣ筺体のファイルシステム上のフォルダ、又はホットフォルダサーバを配置したＰＣ筺体のファイルシステム上のフォルダに対し、ファイル情報をファイルとして出力する。
フォルダを共有フォルダとする事で、フォルダを監視し、フォルダ上に出力されたファイル情報をホットフォルダサーバから取得する事が可能となる。
本実施形態によれば、ファイルシステム上のフォルダを介在させた情報共有が可能となる。
【００３１】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００３２】
以上、上述した各実施形態によれば、ホットフォルダに投入されたデータの投入順序を維持して処理することができる。
上述した各実施形態の様な構成とすることによって、仮にサーバとクライアントとのＯＳが異なる場合であっても、ファイルの投入の順序を保って管理、監視等することができる。また、仮にサーバとクライアントとの通信が切断された場合にも、ファイル投入の順序を管理、監視等することができる。また、Ｗｅｂ入稿による印刷ワークフローシステムの様なシステムの場合、印刷所で１日に印刷可能な印刷ジョブの処理には限度があり、２４時間操業でもない限り、所部処理が翌日に持ち越されることもある。したがって、順序を厳守し、処理することができる上述したシステムの効果は有効である。
【００３３】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図１】
2014219920.tif 000003
【図２】
2014219920.tif 000004
【図３】
2014219920.tif 000005
【図４】
2014219920.tif 000006
【図５】
2014219920.tif 000007
【図６】
2014219920.tif 000008
【図７】
2014219920.tif 000009
【図８】
2014219920.tif 000010
【図９】
2014219920.tif 000011