JP6157143B2 - 情報処理装置、制御方法、及びプログラム - Google Patents

Description

本発明は、文書管理アプリケーションにおける表示処理を制御するための情報処理装置、制御方法及びプログラムに関する。

ファイルサーバーのフォルダーを複数の情報処理装置が参照している場合、ある１つの情報処理装置が、そのフォルダーに対して実行したファイルの追加、編集、削除の結果が、他の情報処理装置上の画面に反映されないことがある。例えば、ユーザーが１つのフォルダーを見続けた場合、ユーザーは上記フォルダー内の状態変化に気付けない可能性がある。これを解決する手段として指定されたフォルダーを監視し、監視しているフォルダーにファイルが追加された場合、ファイルの追加をポップアップメッセージにてユーザーに通知する方法が特許文献１に開示されている。

特開２０１２−４３１１９号公報

しかしながら従来技術では、例えば、ユーザーがあるフォルダーを見ながら作業をしている場合、ポップアップメッセージが表示される位置によっては、ユーザーがポップアップメッセージに気づけない可能性がある。そこで、本発明では、ユーザーが監視対象のフォルダー内の変化を容易に認識できるようにすることを目的としている。

上記課題を解決するために、本発明は、外部装置と接続可能な情報処理装置であって、前記外部装置のフォルダー内の既存ファイルが指定されたソート方法の順序で並べられた画面を表示する表示手段と、前記外部装置から前記フォルダー内の変更を示す情報を受信する受信手段と、前記受信手段により受信された情報に従って前記画面の表示内容を更新する更新手段を有し、前記更新手段は、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示す場合、前記既存ファイルが前記指定されたソート方法の順序で並べられ、かつ、前記指定されたソートの方法の順序で並べられた前記既存ファイルの一覧の先頭または末尾に前記新規ファイルが追加されるように前記画面を更新することを特徴とする。

本発明により、ユーザーが監視対象のフォルダー内の変化を容易に認識できる

実施形態の全体構成図を示す図である。 情報処理装置のハードウェア構成を示すブロック図である。 文書管理アプリケーションのソフトウェア構成図の一例である。 ファイルサーバーのソフトウェア構成図の一例である。 文書管理アプリケーションのＵＩの一例である。 ファイル一覧を更新する処理を示すフロー図である。 イベント種別、ファイル一覧の存在有無、表示更新方法、対応表の一例を示す図である。 ＯｎＣｒｅａｔｅｄとＯｎＣｈａｎｇｅｄによりファイル一覧を更新する処理を示すフロー図である。 ＯｎＤｅｌｅｔｅｄによりファイル一覧を更新する処理を示すフロー図である。 ＯｎＲｅｎａｍｅｄによりファイル一覧を更新する処理を示すフロー図である。 ファイルサーバーの種別を判定する処理を示すフロー図である。 ファイル一覧を更新する処理を示すフロー図である。 イベント種別変更処理の詳細を示すフロー図である。 イベントに応じてファイル一覧を更新する処理を示すフロー図である。 イベント待機処理の詳細を示すフロー図である。 文書管理アプリケーションにおけるＵＩの一例である。 文書管理アプリケーションにおけるＵＩの一例である。 文書管理アプリケーションにおけるＵＩの一例である。 文書管理アプリケーションにおけるＵＩの一例である。 文書管理アプリケーションにおけるＵＩの一例である。 ファイル一覧を更新する処理を示すフロー図である。

以下、本発明を実施するための最良の形態について図面を用いて説明する。

図１は、本発明に好適な実施形態の全体構成図を示す図である。図１において、情報処理装置０１０１は、ファイルサーバー０１０３とコマンド通信可能なネットワーク０１０２で接続されている。

図２は、図１に示した情報処理装置０１０１、ファイルサーバー０１０３のハードウェアー構成を説明するブロック図である。なお、ファイルサーバー０１０３は、情報処理装置と接続可能な外部装置であり、ＰＣであっても良い。

ＣＰＵ０２０１は情報処理装置の制御手段である中央演算処理装置である。ＣＰＵ０２０１は、ＨＤＤ０２０７に格納されているアプリケーションプログラム、オペレーティングシステム（ＯＳ）や本発明の文書管理アプリケーション等を実行し、ＲＡＭ０２０６にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。

ＲＯＭ０２０２は記憶手段である読み出し専用メモリであり、内部には、基本Ｉ／Ｏプログラム等のプログラム、ファイル処理の際に使用するフォントデータ、テンプレート用データ等の各種データを記憶する。

ＮＩＣ０２０３はネットワークインタフェースであり、当該インタフェース０２０３を介して情報処理装置は外部装置とのデータのやり取りを行う。

キーボード０２０４は指示入力手段である入力装置であり、ユーザーが本発明の描画プログラムに対する制御コマンドの命令やテキスト入力などを入力指示するものである。

ＲＡＭ０２０６は一時記憶手段である随時アクセスメモリであり、ＣＰＵ０２０１の主メモリやワークエリア等として機能する。

ＨＤＤ０２０７は外部記憶手段の一つであり、大容量メモリとして機能するハードディスク（ＨＤ）であり、アプリケーションプログラム、ＯＳ、及び関係プログラム等を格納している。

ディスプレイ０２０８は表示手段である出力装置であり、キーボード０２０４から入力したコマンドや、本発明の文書管理アプリケーションの状態等を表示したりするものである。

システムバス０２０９は情報処理装置０１０１、ファイルサーバー０１０３内の各コンポーネントを接続するバスであり、情報処理装置０１０１、ファイルサーバー０１０３内のデータの流れを司るものである。

図３は、本発明を実施するための文書管理アプリケーションを示すソフトウェア構成図である。アプリケーション０３００は、情報処理装置０１０１内で動作し、実行される場合にＲＡＭ０２０６にロードされ、ＣＰＵ０２０１により実行されるプログラムモジュールである。ライブラリー管理部０３０１は、文書管理アプリケーション０３００が参照可能なファイルサーバーの位置を管理する。文書管理アプリケーション０３００は、ライブラリー管理部０３０１で管理されているファイルサーバーを参照し、ファイルへの操作を実行する。表示部０３０２は、キーボード０２０４から入力を受け、本アプリケーションにより処理された結果をディスプレイ０２０８に表示する。ファイル操作部０３０３は、ファイルに対する操作を実行する。そのため、ファイル操作部０３０３は、ファイルサーバー０１０３内のファイルに対してファイルの移動、コピー、削除をキーボード０２０４からの入力に応じて実行する。ファイル一覧取得部０３０４は、ファイルサーバー０１０３に格納されているファイルにおいて、現在参照しているフォルダー内のファイルの一覧を取得する。ファイル一覧更新部０３０５は、現在表示しているファイルの一覧とファイル一覧取得部０３０４で取得したファイルの情報をもとに表示部０３０２で表示しているファイル一覧画面の表示内容を更新する。もしくは、ファイル一覧更新部０３０５は、イベント受信部０３０７から受信したイベントのファイル情報をもとに表示部０３０２で表示しているファイル一覧画面の表示内容を更新する。イベント監視指定部０３０６は、ファイルサーバー０１０３に対して、現在表示部０３０２で表示している位置のファイルに関する変更を監視することを指定するための指定部である。イベント監視指定部０３０６で指定された監視対象フォルダーにおいてファイルに変更があった場合、ファイルサーバー０１０３がイベントを送信し、イベント受信部０３０７は、そのイベントを受信する。イベントを受信するとイベント受信部０３０７は、ファイル一覧更新部０３０５に対して、どのファイルに何が起きたかを通知する。

図４は、本発明を実施するためのファイルサーバー０１０３を示すシステム構成図である。ファイル保存部０４０１は、ファイルを格納するための領域である。文書管理アプリケーション０３００のみでなく、様々なアプリケーションからファイルを保存することを可能とする。ファイル監視部０４０２は、文書管理アプリケーション０３００のイベント監視指定部０３０６より指定されたファイル保存部０４０１内の指定フォルダーの変更を監視する。イベント通知部０４０３は、指定されたフォルダー内のファイルに変更があった場合に、変更されたファイルの情報をイベント受信部０３０７に通知する。通知するイベントとしては、ファイルが新規に作成されたことを示す”ＯｎＣｒｅａｔｅｄ”イベント、既存のファイルに対して変更が行われたことを示す”ＯｎＣｈａｎｇｅｄ”イベントがある。その他にも、既存のファイルが削除されたことを示す”ＯｎＤｅｌｅｔｅｄ”イベント、既存のファイルの名称が変わったことを示す”ＯｎＲｅｎａｍｅｄ”イベントがある。”ＯｎＣｒｅａｔｅｄ”，”ＯｎＣｈａｎｇｅｄ”，”ＯｎＤｅｌｅｔｅｄ”イベントが通知される場合、イベント通知部０４０３は、どのファイルに対して変更があったかをファイル名と共に通知する。”ＯｎＲｅｎａｍｅｄ”イベントが通知される場合、イベント通知部０４０３は、元ファイルの名前と新規のファイルの名前の両方の名前を共に通知する。

図５は、文書管理アプリケーションのＵＩの一例を示す。メニュー０５０１は、ファイルに対する操作の実行コマンドを一覧表示し、実行することを可能とするものである。
アドレスバー０５０２は、現在参照しているフォルダーのパスを表示する。直接フォルダーのパスをアドレスバー０５０２に入力することで、指定されたパスのフォルダーに含まれる既存ファイルがファイルリストビュー０５０５に一覧表示される。なお、本願では、監視対象のフォルダーを選択した段階で監視対象のフォルダーに含まれるファイルを既存ファイルと呼称し、新規に追加されたファイルを新規ファイルと呼称する。なお、既存ファイルと新規ファイルを明確に区別する必要がないときは、単にファイルと呼ぶこともある。

簡易検索バー０５０８に検索キーワードが入力された場合、検索キーワードを含むファイルがファイルリストビュー０５０５に一覧表示される。ツールバー０５０３には、メニュー０５０１で実行可能な操作に対応するショートカットボタンが表示される。ファイルリストビューの表示の切り替えもツールバーのボタンで行われる。本実施例では、サムネイル表示、リスト表示といった表示の切り替えが可能である。ナビゲーションペイン０５０４は、登録しているライブラリーの一覧と現在参照中のフォルダーの位置を表示する。なお、ライブラリーとフォルダーの関係は、ライブラリーが上位の階層で、そのライブラリー階層の下の階層にフォルダーが存在する。また、ライブラリーに対して設定された内容は、フォルダーにも適用される。ファイルリストビュー０５０５は、アドレスバー０５０２に表示されているフォルダーパスに含まれるフォルダー及びファイルを一覧表示する。

ツールバー０５０３で指定された表示の切り替えにより、表示方法が変わる。本図示例では、サムネイル表示の例を記述している。プレビューペイン０５０６は、ファイルリストビュー０５０５で選択されているファイルの内容をプレビューして表示する。次のページを表示することを指定することで複数ページのファイルでも表示できる。アウトプットバー０５０７は、アウトプットバーに登録されているボタンを押下することで、ボタンに関連付けられているアクションをファイルリストビューで選択されているファイルに対して実行可能である。本実施例では、印刷とメール添付とフォルダーへ移動のアクションをアウトプットバー０５０７に登録可能としている。文書管理アプリケーションは、印刷アクションが押下された場合、印刷アクションの押下時に選択されていたファイルを印刷する。メール添付アクションが押下された場合、文書管理アプリケーションは、ＯＳに関連付けられているメールクライアントの新規メールに対して、メール添付アクションが押下された時に選択されていたファイルを添付する。フォルダーへ移動のアクションが押下された場合、文書管理アプリケーションは、フォルダーへ移動のアクションが押下された時に選択されていたファイルを登録されているフォルダーパスに対して移動する。

次に本実施形態における文書管理アプリケーション０３００が、監視対象のフォルダー内に変化があった場合にその変化を即時にファイルリストビュー０５０５に反映する手段について図６のフローチャートを用いて説明する。なお本願のフローチャートの各ステップは、フローチャートに関連するプログラムがＲＡＭ０２０６に読み出され、ＣＰＵ０２０１によって実行されることで実現される。

文書管理アプリケーション０３００は、ライブラリーとして登録されているファイルサーバーからユーザーにより選択された任意のフォルダーを開く（Ｓ０６０１）。

文書管理アプリケーション０３００は、開いたフォルダーに格納されているファイルの一覧を取得し（Ｓ０６０２）、取得した既存ファイルの一覧をファイルリストビュー０５０５に表示する。文書管理アプリケーション０３００は、開いているフォルダーを監視対象のフォルダーとして監視する（Ｓ０６０３）。ファイルサーバー０１０３は、監視対象のフォルダー内のファイルに変化があった場合、フォルダー内の変更を示す情報を通知する。 なお、本願では、ファイル内の変更を示す情報をイベントとして説明する。文書管理アプリケーション０３００は、ファイルサーバー０１０３により通知されたイベントを受信する（Ｓ０６０４）。

受信したイベントが”ＯｎＣｒｅａｔｅｄ”の場合、文書管理アプリケーション０３００は、ＯｎＣｒｅａｔｅｄ追加／変更／削除処理を実行する（Ｓ０６０５）。受信したイベントが”ＯｎＣｈａｎｇｅｄ”の場合、文書管理アプリケーション０３００は、ＯｎＣｈａｎｇｅｄ追加／変更／削除処理を実行する（Ｓ０６０６）。受信したイベントが”ＯｎＤｅｌｅｔｅｄ”の場合、文書管理アプリケーション０３００は、ＯｎＤｅｌｅｔｅｄ追加／変更／削除処理を実行する（Ｓ０６０７）。受信したイベントが”ＯｎＲｅｎａｍｅｄ”の場合、文書管理アプリケーション０３００は、ＯｎＲｅｎａｍｅｄ追加／変更／削除処理を実行する（Ｓ０６０８）。

図７は、各イベントと取得したファイル一覧にイベントで通知されたファイルが存在するかとイベントで通知されたファイルの実体を取得した時に実体の存在が確認できるかによってファイル一覧の更新手段を変更するための動作を規定した一覧である。本一覧は、フロー図６のＳ０６０５，Ｓ０６０６，Ｓ０６０７，Ｓ０６０８の動作を一覧にしたものである。

図８は、”ＯｎＣｒｅａｔｅｄ”イベント及び”ＯｎＣｈａｎｇｅｄ”イベントを受信した場合のＳ０６０５、Ｓ０６０６の詳細フローである。

文書管理アプリケーション０３００は、イベントで受信したファイル名を取得する（Ｓ０８０１）。文書管理アプリケーション０３００は、Ｓ０８０１において取得したファイル名と同名のファイル名が、監視対象のフォルダーから取得したファイル一覧に存在するかどうかを確認する（Ｓ０８０２）。イベントに含まれるファイル名が監視対象のフォルダーから取得したファイル一覧に存在する場合、イベントで受信したファイルが実在するかどうかを確認する（Ｓ０８０３）。具体的には、文書管理アプリケーション０３００は、監視対象のフォルダーにイベントで受信したファイルがあるかどうかを判断することでＳ０８０３が実現される。

イベントで受信したファイル名が、監視対象のフォルダーから取得したファイル一覧に存在し、かつ、監視対象のフォルダーに実在する場合、文書管理アプリケーション０３００は、ファイルが更新されたと判断し、ファイル一覧に表示されている位置でファイルの更新を行う（Ｓ０８０４）。イベントで受信したファイル名が、監視対象のフォルダーから取得したファイル一覧に存在し、かつ、監視対象のフォルダーに実在しない場合、文書管理アプリケーション０３００は、ファイルが無くなったと判断する。そして、文書管理アプリケーション０３００は、ファイル一覧からファイルを削除する（Ｓ０８０５）。

イベントで受信したファイル名が、監視対象のフォルダーから取得したファイル一覧に存在しない場合、文書管理アプリケーション０３００は、Ｓ０８０３と同様にイベントで受信したファイルが監視対象のフォルダーに実在するかどうかを確認する（Ｓ０８０６）。

イベントで受信したファイル名が、監視対象のフォルダーから取得したファイル一覧に存在せず、かつ、監視対象のフォルダーに実在する場合、文書管理アプリケーション０３００は、新規ファイルが追加されたと判断する。そして、文書管理アプリケーション０３００は、ファイルの表示状態やソート状態に依存せず、ファイル一覧の末尾に新規ファイルを追加する（Ｓ０８０７）。なお、本実施形態では、ユーザーが認識しやすい位置としてファイル一覧の末尾に新規ファイルを追加する例を記載した。しかしながら、ユーザーが追加されたファイルを認識しやすい位置であれば良く、例えば、既存ファイルの一覧の先頭に新規ファイルを追加しても良い。

イベントで受信したファイル名が、監視対象のフォルダーから取得したファイル一覧に存在せず、かつ、監視対象のフォルダーに実在しない場合、文書管理アプリケーション０３００は、変化がないと判断し、なにもしない（Ｓ０８０８）。

図９は、”ＯｎＤｅｌｅｔｅｄ”イベントを受信した場合のＳ０６０７の詳細フローである。

文書管理アプリケーション０３００は、イベントで受信したファイル名を取得する（Ｓ０９０１）。文書管理アプリケーション０３００は、イベントで受信したファイル名と同名のファイル名が、監視対象のフォルダーから取得したファイル一覧に存在するかどうかを確認する（Ｓ０９０２）。イベントで受信したファイル名と同名のファイル名が、監視対象のフォルダーから取得したファイル一覧に存在する場合、文書管理アプリケーション０３００は、イベントで受信したファイルが、監視対象のフォルダーに実在するかどうかを確認する（Ｓ０９０３）。

イベントで受信したファイル名と同名のファイル名が、監視対象のフォルダーから取得したファイル一覧に存在し、かつ、監視対象のフォルダーに実在する場合、文書管理アプリケーション０３００は、ファイルが更新されたと判断する。そして、文書管理アプリケーション０３００は、Ｓ０８０４と同様にファイル一覧に表示されている位置でファイルの更新を行う（Ｓ０９０４）。

イベントで受信したファイル名と同名のファイル名が、監視対象のフォルダーから取得したファイル一覧に存在し、かつ、監視対象のフォルダーに実在しない場合、文書管理アプリケーション０３００は、ファイルが削除されたと判断する。そして、文書管理アプリケーション０３００は、Ｓ０８０５と同様にファイル一覧からファイルを削除する（Ｓ０９０５）。

イベントで受信したファイル名と同名のファイル名が、監視対象のフォルダーから取得したファイル一覧に存在しない場合、文書管理アプリケーション０３００は、Ｓ０８０８と同様に変化がないと判断し、なにもしない（Ｓ０９０６）。

図１０Ａ、図１０Ｂは、”ＯｎＲｅｎａｍｅｄ”イベントを受信した場合のＳ０６０８の詳細フローである。

文書管理アプリケーション０３００は、イベントで受信した元ファイル名と変更後のファイル名を取得する（Ｓ１００１）。文書管理アプリケーション０３００は、監視対象のフォルダーのファイル一覧に同名の元ファイルが存在するかどうかを確認する（Ｓ１００２）。元ファイル名が監視対象のフォルダーのファイル一覧に存在する場合、文書管理アプリケーション０３００は、Ａ＝Ｔｒｕｅと記憶し（Ｓ１００３）、存在しない場合は、Ａ＝ｆａｌｓｅと記憶する（Ｓ１００４）。

次に文書管理アプリケーション０３００は、イベントで受信した元ファイルが監視対象のフォルダーに実在するかどうかを確認する（Ｓ１００５）。イベントで受信した元ファイルが監視対象のフォルダーに実在する場合、文書管理アプリケーション０３００は、Ｂ＝Ｔｒｕｅと記憶し（Ｓ１００６）、実在しない場合は、Ｂ＝ｆａｌｓｅと記憶する（Ｓ１００７）。

次に文書管理アプリケーション０３００は、監視対象のフォルダーのファイル一覧にイベントで受信した変更後のファイル名のファイルが存在するかどうかを確認する（Ｓ１００８）。監視対象のフォルダーのファイル一覧にイベントで受信した変更後のファイル名のファイルが存在する場合、文書管理アプリケーション０３００は、Ｃ＝Ｔｒｕｅと記憶し（Ｓ１００９）、存在しない場合、Ｃ＝ｆａｌｓｅと記憶する（Ｓ１０１０）。次に文書管理アプリケーション０３００は、イベントで受信した変更後のファイル名のファイルが監視対象のフォルダーに実在するかどうかを確認する（Ｓ１０１１）。

イベントで受信した変更後のファイル名のファイルが監視対象のフォルダーに実在する場合、文書管理アプリケーション０３００は、Ｄ＝Ｔｒｕｅと記憶し（Ｓ１０１２）、実在しない場合は、Ｄ＝ｆａｌｓｅと記憶する（Ｓ１０１３）。次に、文書管理アプリケーション０３００は、これらＡ，Ｂ，Ｃ，Ｄの値を参照し、それぞれの値によりファイル一覧へのファイルの追加方法を変更する。ＡからＤが全てＴｒｕｅもしくはＡ＝Ｔｒｕｅ Ｂ＝Ｔｒｕｅ Ｃ＝Ｆａｌｓｅ Ｄ＝ＴｒｕｅもしくはＡ＝Ｔｒｕｅ Ｂ＝Ｔｒｕｅ Ｃ＝Ｆａｌｓｅ Ｄ＝Ｆａｌｓｅの場合、文書管理アプリケーション０３００は、変更後のファイル名のファイルを更新する。そして、変更後のファイル名は、ファイル一覧上の同じ位置で表示される（Ｓ１０１５）。Ａ＝Ｔｒｕｅ Ｂ＝Ｔｒｕｅ Ｃ＝ Ｔｒｕｅ Ｄ＝Ｆａｌｓｅの場合、文書管理アプリケーション０３００は、変更後のファイル名のファイルを更新してファイル一覧上の同じ位置で表示し、変更前のファイル名を一覧から削除する（Ｓ１０１６）。

Ａ＝Ｔｒｕｅ Ｂ＝Ｆａｌｓｅ Ｃ＝ Ｔｒｕｅ Ｄ＝ＴｒｕｅもしくはＡ＝ＴｒｕｅＢ＝Ｆａｌｓｅ Ｃ＝ Ｆａｌｓｅ Ｄ＝ＴｒｕｅもしくはＡ＝Ｔｒｕｅ Ｂ＝Ｆａｌｓｅ Ｃ＝ Ｆａｌｓｅ Ｄ＝Ｆａｌｓｅの場合、文書管理アプリケーション０３００は、変更後のファイル名のファイルをファイル一覧から削除する（Ｓ１０１７）。

Ａ＝Ｆａｌｓｅ Ｂ＝Ｔｒｕｅ Ｃ＝ Ｔｒｕｅ Ｄ＝ＴｒｕｅもしくはＡ＝Ｆａｌｓｅ Ｂ＝Ｔｒｕｅ Ｃ＝ Ｔｒｕｅ Ｄ＝Ｆａｌｓｅの場合、文書管理アプリケーション０３００は、元となる変更前のファイル名を変更後のファイル名に更新し、ファイル一覧上では位置の移動は行わない（Ｓ１０１８）。Ａ＝Ｔｒｕｅ Ｂ＝Ｆａｌｓｅ Ｃ＝Ｔｒｕｅ Ｄ＝Ｆａｌｓｅの場合、文書管理アプリケーションは、変更後のファイル名のファイルをファイル一覧上から削除し、さらに元となる変更前のファイル名のファイルも削除する（Ｓ１０１９）。

Ａ＝Ｆａｌｓｅ Ｂ＝Ｔｒｕｅ Ｃ＝ Ｆａｌｓｅ Ｄ＝Ｔｒｕｅもしくは、Ａ＝Ｆａｌｓｅ Ｂ＝Ｔｒｕｅ Ｃ＝ Ｆａｌｓｅ Ｄ＝Ｆａｌｓｅの場合、文書管理アプリケーション０３００は、変更後のファイル名のファイルをファイル一覧の末尾に追加する（Ｓ１０２０）。Ａ＝Ｆａｌｓｅ Ｂ＝Ｆａｌｓｅ Ｃ＝ Ｔｒｕｅ Ｄ＝Ｆａｌｓｅの場合、文書管理アプリケーション０３００は、元となる変更前のファイル名のファイルをファイル一覧から削除する（Ｓ１０２１）。

Ａ＝Ｆａｌｓｅ Ｂ＝Ｆａｌｓｅ Ｃ＝ Ｔｒｕｅ Ｄ＝ＴｒｕｅもしくはＡ＝Ｆａｌｓｅ Ｂ＝Ｆａｌｓｅ Ｃ＝Ｆａｌｓｅ Ｄ＝ＴｒｕｅもしくはＡ＝Ｆａｌｓｅ Ｂ＝Ｆａｌｓｅ Ｃ＝Ｆａｌｓｅ Ｄ＝Ｆａｌｓｅの場合、文書管理アプリケーション０３００は、変化がなかったとして、特になにもしない（Ｓ１０２２）。

以上により、追加された新規ファイルは、末尾に追加され、更新されたファイルは、同位置にて更新される。

以下に本実施例を実現することで得られる画面について説明する。

まず、図５は、文書管理アプリケーション０３００が、アドレスバー０５０２で指定されているフォルダーに記憶されている既存ファイルの一覧を、ファイル名でソートした状態で表示しているＵＩの一例である。

そして、アドレスバー０３０２で指定されているフォルダーに新規ファイルが追加された場合、文書管理アプリケーションは、ファイルサーバーからイベントを受信して、図５の画面をファイル一覧の図１８の画面へ更新する。新規ファイル１８０１のファイル名がＡｄｄ．ｐｄｆである場合、ソート規則に従うとファイルリストビュー０５０５上では、Ａ．ｐｄｆとＢ．ｐｄｆの間に追加されてしまう。

しかし、本実施例を適用することにより、監視対象のフォルダーに新しく追加された新規ファイルは、ファイル１８０１のように末尾に追加される。これにより、ユーザーがソート順で上から順にファイルを参照している場合、ファイルが新規に追加されてもソートによってファイルの間に挿入されず、末尾に追加されるためユーザーが新規に追加された新規ファイルに容易に気づくことができる。

なお、新規ファイルは、末尾以外にもリストの下端や上端、先頭に表示されるように画面が更新されても良い。また、データの種類やデータサイズでソートした状態で既存ファイルがファイルリストビュー０５０５に表示されている場合も、文書管理アプリケーション０３００が本実施例の処理を実行することで、ユーザーが監視対象のフォルダー内の変化を容易に認識できる。

上記実施例１では、イベント受信によりファイル一覧の更新を行っているが、ファイルサーバーの能力により、イベントを送信できないファイルサーバーもある。実施例２では、文書管理アプリケーション０３００が、ファイルサーバーがイベント送信できるか否かを判断する。そして、文書管理アプリケーション０３００が、ファイルサーバーがイベント送信できないと判断した場合、周期監視により新規追加されたファイルを追加する方法について説明する。なお、実施例２の説明において、実施例１と重複する点は省略する。

文書管理アプリケーション０３００は、ライブラリーを登録する際、ライブラリー管理部０３０１に対して、登録種別を指定する。登録された種別が直接参照可であれば、参照先のファイルサーバーは、ファイルサーバー上でファイルの編集が実行可能であり、直接参照不可とあれば、参照先のファイルサーバー上ではファイルの編集が不可となる。

直接参照可のファイルサーバーとしては、例えばＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）サーバ等がある。直接参照不可には、例えばＷｅｂＤＡＶ（Ｗｅｂ−ｂａｓｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ａｕｔｈｏｒｉｎｇ ａｎｄ Ｖｅｒｓｉｏｎｉｎｇ）サーバ等がある。

直接参照可能か否かは、ユーザーが文書管理アプリケーション０３００のライブラリー管理部０３０１にファイルサーバーをライブラリーとして登録する際に指定する。文書管理アプリケーション０３００で、ライブラリーを登録する際のＵＩの一例を図１９（Ａ）、（Ｂ）に示す。

図１９（Ａ）は、ライブラリー選択画面の一例である。メニュー０５０１で図１９（Ａ）の画面を表示するための実行コマンドを実行することで、図１９（Ａ）の画面が表示される。ライブラリー選択画面１９０１内のライブラリーの種類選択リスト１９０２に登録可能なライブラリーの一覧を表示する。本ライブラリーの種類は文書管理アプリケーションにて規定されているものである。

このライブラリーの種類を選択し、ＯＫボタン１９０３を選択することでライブラリー登録画面を表示する。図１９（Ｂ）は、ネットワークライブラリー登録画面の一例である。ネットワークライブラリー登録画面１９０４は、ライブラリーの種類選択リスト１９０２でネットワークライブラリーを選択した場合に表示される画面である。ユーザーは、図１９（Ｂ）の画面にてフォルダーパス指定テキストボックスに登録するフォルダーのパスを指定する。そして、ユーザーは、登録対象のフォルダーのライブラリー名を指定し、ＯＫボタン１９０６を押下することで、文書管理アプリケーション０３００にライブラリーとして登録され、ナビゲーションペイン０５０４に表示される。図１１は、上述のようにライブラリーが登録された後、文書管理アプリケーション０３００がイベントによるファイル一覧の更新を行うか周期監視によるファイル一覧の更新を行うかを決定する処理についての詳細フローである。

文書管理アプリケーション０３００は、登録されているライブラリーからユーザーにより選択されたライブラリーを選択する（Ｓ１１０１）。

文書管理アプリケーション０３００は、選択されたライブラリーに登録されているライブラリー情報を確認する（Ｓ１１０２）。そして、ライブラリー情報が直接参照可を示す場合、文書管理アプリケーション０３００は、登録されているライブラリー情報のパスから、ファイルサーバーの情報を取得する（Ｓ１１０３）。

文書管理アプリケーション０３００は、ファイルサーバーがＮＴ Ｆｉｌｅ Ｓｙｓｔｅｍか否かを判別する（Ｓ１１０４）。ＮＴ Ｆｉｌｅ Ｓｙｓｔｅｍである場合は、イベント送信可能なファイルサーバーであると判断し、イベント監視を行う（Ｓ１１０５）。

一方、文書管理アプリケーション０３００が、選択されたライブラリーに登録されている登録情報が直接参照不可である、または、Ｓ１１０３で取得されたファイルサーバーの情報がＮＴ Ｆｉｌｅ Ｓｙｓｔｅｍでない場合、文書管理アプリケーション０３００は、選択されているライブラリーに対応するファイルサーバーはイベント監視できないファイルサーバーであると判断する。そして、文書管理アプリケーション０３００は、そのファイルサーバーについて周期監視を行う（Ｓ１１０６）。

周期監視を行う場合、文書管理アプリケーション０３００は、一定期間毎に関し対象のフォルダーのファイル一覧を取得し、文書管理アプリケーション０３００上に表示しているファイル一覧と取得したファイル一覧を比較する。比較した結果、取得したファイル一覧にのみ存在するファイルは末尾に追加し、取得したファイル一覧から表示しているファイル一覧に存在しないものは、削除する。

これにより、イベント監視と周期監視を切り替えることを可能としている。

実施例１では、イベント受信によりファイル一覧の更新を行っているが、ファイル操作によっては、固有の動作を行う特定のアプリケーションも存在する。例えば、特定のアプリケーションは上書き保存が指示された場合、ファイルを直接更新するのではなく、以下のような処理を行う。なお、実施例３の説明において、実施例１および実施例２と重複する点は省略する。

まず、特定のアプリケーションは、上書き保存が指示された場合、上書き対象の元ファイルとは別のファイルとして拡張子．ｔｍｐを新規に作成する。この作成処理により、ファイルサーバーは文書管理アプリケーション０３００にＯｎＣｒｅａｔｅｄイベントを発行する。なお、上書き保存が指定された際に新規に作られる拡張子．ｔｍｐは隠しファイル属性を持つ可能性が高く、拡張子が、．ｔｍｐである可能性が高く、ファイル名が「＄Ｒｅｃｙｃｌｅｒ．ＤＴ，〜＄」である可能性が高い。

続いて、特定のアプリケーションは、上書き対象の元ファイルを拡張子．ｔｍｐにファイル名を変更する。この変更処理により、ファイルサーバーは文書管理アプリケーション０３００にＯｎＲｅｎａｍｅｄイベントを発行する。

そして、特定のアプリケーションは、別のファイルとして作成した拡張子．ｔｍｐファイルを元ファイル名に変更して保存することで上書き保存を実現する。この保存処理の際にファイル名が変更されているので、ファイルサーバーは文書管理アプリケーション０３００にＯｎＲｅｎａｍｅｄイベントを発行する。

その後、特定のアプリケーションは、別名変更した拡張子．ｔｍｐファイルを削除するこの削除処理により、ファイルサーバーは文書管理アプリケーション０３００にＯｎＤｅｌｅｔｅｄイベントを発行する。

実施例３では、このような特定のアプリケーションが存在する場合でも、文書管理アプリケーション０３００が、実施例１と同様に新規追加ファイルを末尾に追加し、更新ファイルを同位置で更新する方法について説明する。

図１２は、文書管理アプリケーション０３００が、受信したイベントに応じてファイル一覧の更新を行うフローである。図６と同じ箇所の説明は割愛する。

Ｓ０６０４でイベントを受信した場合、文書管理アプリケーション０３００は、イベント種別変更処理を実施する（Ｓ１２０１）。このイベント種別変更処理により、受信したイベントを必要に応じて変更し、変更されたイベントでＳ０６０５、Ｓ０６０６、Ｓ０６０７、Ｓ０６０８を実行する。

図１３は、イベント種別変更処理（Ｓ１２０１）の詳細フローである。なお、図１３の処理は基本的に文書管理アプリケーション０３００のイベント受信部０３０７の処理である。

イベント受信部０３０７は、イベントを受信し（Ｓ１３０１）、受信したイベントが何かを判断する（Ｓ１３０２）。

Ｓ１３０２の判断の結果、Ｓ１３０１で受信したイベントがＯｎＣｒｅａｔｅｄもしくはＯｎＣｈａｎｇｅｄであると判断された場合、イベント受信部０３０７は、イベントで受信したファイルの属性を取得する（Ｓ１３０３）。

そして、イベント受信部０３０７は、取得した属性が隠し属性かどうかを判断する（Ｓ１３０４）。そして、取得した属性が隠し属性である、もしくは、ファイル自体がファイルサーバーの監視対象のフォルダーに存在しないなどの理由により属性を取得できない場合、イベント受信部０３０７は、ファイル一覧更新部０３０５にイベントを通知しない（Ｓ１３１０）。つまり、ＯｎＣｒｅａｔｅｄイベントを受信したにも関わらず、そのイベントに対応するファイルが隠し属性を持つということは、上述した上書き保存用に別のファイルとして作成されるファイル用のイベントである可能性が高い。

このようなイベントに対応するファイルを使ってファイルリストビューを更新する必要はない。よって、イベント受信部０３０７は、ファイル一覧更新部０３０５にイベントを通知しない。なお、イベント受信部０３０７は、Ｓ１３１０でイベントを通知しない場合、受信したイベントを削除する。

Ｓ１３０４において取得した属性が隠し属性ではないと判断された場合、イベント受信部０３０７は、Ｓ０６０４で受信したイベントに対応するファイルが特定の拡張子であるかどうかを判別する（Ｓ１３０５）。本実施例では、．ｔｍｐ，．ｉｗｘ，．ｉｗｎ，．ｉｗｕ，．ｄｂであるかどうかを判別しているが、拡張子の種別はこれに限らない。
また、判別方法は、文書管理アプリケーション０３００が監視対象のファイルサーバーのフォルダー内のイベントに対応するファイルの拡張子を参照することでＳ１３０５の処理が実現される。

上書き保存用に別のファイルとして作成されるファイルは、必ずしも隠し属性を持つとは限らない。よって、Ｓ１３０５の処理を実行することで、例えば、上書き保存用に別のファイルとして作成されるファイルが隠し属性を持たない場合であっても、イベント受信部０３０７がファイル一覧更新部０３０５にイベントを通知するか否かを適切に決定できる。

イベントに対応するファイルの拡張子が特定の拡張子であると判定された場合、イベント受信部０３０７は、ファイル一覧更新部０３０５にイベントを通知しない（Ｓ１３１０）。

イベントに対応するファイルの拡張子が特定の拡張子でないと判定された場合、イベント受信部０３０７は、イベントに対応するファイルのファイル名が特定の名称から始まるかどうかを判別する（Ｓ１３０６）。本実施例では、＄Ｒｅｃｙｃｌｅｒ．ＤＴ，〜＄から始まるかどうかを判別しているが、これに限らない。

上書き保存用に別のファイルとして作成されるファイルは、必ずしも隠し属性を持ち、かつ、拡張した上述した特定の拡張子であるとは限らない。よって、例えば、上書き保存用に別のファイルとして作成されるファイルが隠し属性を持たず、かつ、上書き保存用に作成されたファイルの拡張子が特定の拡張子でない場合も、イベント受信部０３０７がイベントを通知するか否かを適切に決定できる。

イベントに対応するファイルが特定の名称から始まると判定された場合、イベント受信部０３０７は、ファイル一覧更新部０３０５にイベントを通知しない（Ｓ１３１０）。イベントに対応するファイルが特定の名称から始まらない場合、イベント受信部０３０７は、イベント変更フラグを持っているかどうかを判別する（Ｓ１３０７）。Ｓ１３０７によりイベント変更フラグがない場合、イベント受信部０３０７は、そのままのイベントをファイル一覧更新部０３０５に通知する（Ｓ１３０９）。

一方、イベント変更フラグがある場合、イベント受信部０３０７は、ＯｎＲｅｎａｍｅｄイベントをＯｎＣｈａｎｇｅｄイベントに変更して（Ｓ１３０８）、ファイル一覧更新部０３０５にイベントを通知する（Ｓ１３０９）。

Ｓ１３０２において受信したイベントがＯｎＤｅｌｅｔｅｄイベントである場合、イベント受信部０３０７は、Ｓ１３０５まで処理を進める。Ｓ１３０２において受信したイベントがＯｎＲｅｎａｍｅｄイベントである場合、イベント受信部０３０７は、リネームする前の拡張子が．ｔｍｐであるかどうかを判別する。（Ｓ１３１１）。イベント通知部０４０３は、ＯｎＲｅｎａｍｅｄイベントを通知する場合、元ファイルの名前と新規のファイルの名前の両方の名前を共に通知する。そのため、イベント受信部０３０７は、元のファイルの名前を参照することでＳ１３１１を実現できる。

リネームされる前の拡張子が．ｔｍｐであった場合、イベント受信部０３０７は、イベント変更フラグを持ち（Ｓ１３１２）、その後の確認においては、リネームした後のファイル名を判別処理に使用し、Ｓ１３０３へと進む。リネームされる前の拡張子が．ｔｍｐでない場合、リネームした後の拡張子が．ｔｍｐであるかどうかを判別する（Ｓ１３１３）。イベント受信部０３０７は、イベント通知部０４０３によりＯｎＲｅｎａｍｅｄイベントにて通知される新規のファイルの名前を参照することでＳ１３１３の処理を実現できる。リネームした後の拡張子が、．ｔｍｐである場合、イベント受信部０３０７はファイル一覧更新部０３０５にイベントを通知しない（Ｓ１３１０）。拡張子が．ｔｍｐでない場合、イベント受信部０３０７の処理はＳ１３１４に進む。

これにより、イベントの種別を変更することで、アプリケーション固有の動作による上書き処理などが実行された場合でも期待した通りに上書き時は上書きの動作となる。つまり、上書き保存されたファイルは、ファイルリストビューにおける位置が変わらない。

また、図１３のＳ１３０４からＳ１３０６の判定処理順序は、図１３の順番で実行する必要はない。例えば、Ｓ１３０５→Ｓ１３０４→Ｓ１３０６のような順番で実行しても構わない。また、必ずしも全ての判定処理を実行する必要はなく、Ｓ１３０４からＳ１３０６の少なくとも１つの判定処理を実行しても良い。

実施例１では、イベント受信によりファイル一覧の更新を行っているが、ファイルサーバー０１０３と情報処理装置０１０１のＯＳの違いによって想定と異なるイベントが発生してしまうことがある。例えば、監視対象のフォルダーにおいて任意のファイルに上書き保存が指示された場合、任意のファイルの変更である。そのため、文書管理アプリケーションはＯｎＣｈａｎｇｅｄイベントの受信を期待するが、ＯＳの違いにより、ＯｎＤｅｌｅｔｅｄとＯｎＣｒｅａｔｅｄのイベントを連続して受信することがある。ファイルサーバー０１０３と情報処理装置０１０１のＯＳの違いの例としてＯＳのバージョンの差異などが挙げられる。

実施例４では、このようなＯＳによる発生イベントの違いがある場合でも更新ファイルは同位置で更新する方法について説明する。なお、実施例４の説明において、実施例１乃至３と重複する点は省略する。

図１４は、受信したイベントに応じてファイル一覧の更新を行うフローである。

図６と同じ箇所の説明は割愛する。Ｓ０６０４でイベントを受信した場合、文書管理アプリケーション０３００は、イベント待機処理を実施する（Ｓ１４０１）。このイベント待機処理により、受信したイベントを必要に応じて変更し、変更されたイベントでＳ０６０５、Ｓ０６０６、Ｓ０６０７、Ｓ０６０８を実行する。

図１５は、イベント待機処理（Ｓ１４０１）の詳細フローである。

イベント受信部０３０７は、受信したイベントがＯｎＤｅｌｅｔｅｄである場合、新たなイベントを受信するために一定期間待機する。そして、一定期間内に同ファイル名へのＯｎＲｅｎａｍｅｄイベントを受信した場合、イベント受信部０３０７は、ＯｎＤｅｌｅｔｅｄイベントとＯｎＲｅｎａｍｅｄイベントをＯｎＣｈａｎｇｅｄイベントに変更する。一定期間待機しても次のイベントを受信しない、もしくは異なるファイルへのイベントのみを受信した場合、イベント受信部０３０７は、受信したイベントをそのままファイル一覧更新部０３０５に通知する。その結果、イベントに対応した処理が実行される。

イベント受信部０３０７は、イベントを受信し（Ｓ１５０１）、受信したイベントがＯｎＤｅｌｅｔｅｄイベントかどうかを判断する（Ｓ１５０２）。受信したイベントがＯｎＤｅｌｅｔｅｄイベントでない場合、イベント受信部０３０７は、受信したイベントをそのままファイル一覧更新部０３０５に通知する（Ｓ１５０６）。一方、受信したイベントがＯｎＤｅｌｅｔｅｄイベントである場合、イベント受信部０３０７は、すぐにイベントをファイル一覧更新部０３０５に通知せずに一定期間待機する（Ｓ１５０３）。この待機期間は任意とする。

イベント受信部０３０７は、待機している間に別のイベントが発生したかどうかを確認し（Ｓ１５０４）、発生していない場合は、一定期間経過したかどうかを確認する（Ｓ１５０５）。一定期間経過した場合、イベント受信部０３０７は、ＯｎＤｅｌｅｔｅｄイベントをそのままファイル一覧更新部０３０５に通知する（Ｓ１５０６）。一方、待機している間にイベント受信部が別のイベントを受信した場合、イベント受信部０３０７は、受信したイベントの種類を確認する（Ｓ１５０７）。

Ｓ１５０７の確認の結果、受信したイベントがＯｎＣｒｅａｔｅｄイベントである場合、イベント受信部０３０７は、ＯｎＤｅｌｅｔｅｄイベントとＯｎＣｒｅａｔｅｄイベントを削除し、ＯｎＣｈａｎｇｅｄイベントに変更する。（Ｓ１５０９）。発生したイベントがＯｎＲｅｎａｍｅｄイベントだった場合、イベント受信部０３０７は、ＯｎＲｅｎａｍｅｄイベントに記述されている新しいファイル名がＯｎＤｅｌｅｔｅｄイベントと同じであるかどうかを判断する（Ｓ１５０８）。Ｓ１５０８の結果、両者が同じである場合、イベント受信部０３０７は、ＯｎＤｅｌｅｔｅｄイベントとＯｎＲｅｎａｍｅｄイベントを削除し、ＯｎＣｈａｎｇｅｄイベントに変更する。（Ｓ１５０９）。

これにより、ファイルサーバー０１０３のＯＳが情報処理装置０１０１のＯＳと異なることにより、想定と異なるイベントが発生しても、文書管理アプリケーション０３００は期待した通りに上書き時は上書きの動作を実行できる。つまり、上書き保存されたファイルは、ファイルリストビューにおける位置が変わらない。

また、ファイルサーバー０１０３からＯｎＤｅｌｅｔｅｄイベントを受信した場合でも、文書管理アプリケーション０３００は、本実施形態の処理を実行することでＯｎＤｅｌｅｔｅｄイベントに対応するファイルを表示するか非表示にするかを適切に決定できる。

イベント受信によりファイル一覧の更新を行っているが上記実施例１乃至４では、新規ファイルを末尾に追加する一例について説明している。しかし、大量のファイルが監視対象のフォルダー内に格納されている場合、ファイルリストビュー上で表示しきれないため、スクロール表示となり、末尾に追加されてもユーザーが新規ファイルの追加に気づけないということがある。実施例５では、これを防ぐ方法について説明する。なお、実施例５の説明において、実施例１乃至４と重複する点は省略する。

図１６は、文書管理アプリケーション０３００のファイルリストビューのＵＩ例を示す。図５と同じものの説明は割愛する。スクロールバー１６０１は、ファイルリストビュー０５０５の表示領域にファイル一覧が収まりきれない場合に表示される。スクロールバー１６０１を上下移動させることで、フォルダー内に格納されたファイルが表示される。このような状態において、図１６のＵＩ例にあるようにＡからＧまでのファイルが表示されている状態で、新規ファイルが追加された場合、表示領域の末尾にファイルを挿入する。図１６のＵＩ例は図１７のようなＵＩ例に変更される。ファイルＨが新規追加された場合、ファイル１７０１がファイルリストビュー０５０５の表示領域の末尾に追加され、ファイルＧがさらに後ろへ移動している。

これにより、現在見えている位置の末尾に追加することで、ファイル追加時の検索性を向上させている。なお、その他にも単純に一番最後に新規ファイルを追加するとともに、文書管理アプリケーション０３００が、末尾に追加された新規ファイルが表示されるように自動的にスクロールバーを移動しても良い。

また、その他にも本願の図２０のように後半の既存ファイル２００１−２００２の一部がファイルリストビューに表示されている場合、ユーザーの見易さを考慮して、図２０の１８０１の位置に新規ファイルが追加されても良い。

上記実施例１乃至５では、イベント受信によりファイル一覧の更新を行っているが、同一フォルダー内で複数のファイルが追加、更新された場合、大量のイベントを受信する。その結果、文書管理アプリケーション０３００が、イベントそれぞれに対してファイルに関する情報の取得処理を実行してしまい、アプリケーションの処理負荷が高くなってしまう。負荷が高くなるとイベントの送信ができずに追加されたファイルが確認できないということが発生してしまうこともある。大量のイベントが送信されるケースは、例えば監視対象フォルダーに複数のファイルを一括でコピーしたり、複数のファイルに対して、一括でファイル名を変更したりする場合である。実施例６では、大量のイベントが発生した場合にファイルが確認できないということがないようにするための手段について説明する。なお実施例６の説明において、実施例１乃至５と重複する点は省略する。

図２１は、大量にイベントが来た場合のファイル一覧を更新するための処理フローである。図６と同じ箇所の説明は割愛する。

文書管理アプリケーション０３００は、Ｓ０６０４で受信したイベントがＯＳからイベント送信の許容を超えたエラーを示すイベントか否かを確認する（Ｓ２１０１）。許容を超えたエラーが来た場合、文書管理アプリケーション０３００は、一定期間待機し（Ｓ２１０５）、待機期間内に新規に受信するイベントの数がしきい値以下になったかどうかを判断する（Ｓ２１０６）。待機期間内に新規に受信するイベントの数がしきい値以下であれば、フォルダー内のファイル一覧取得処理（Ｓ２１０７）に進む。待機期間内に新規に受信するイベントの数がしきい値以上である場合、文書管理アプリケーション０３００は、再度一定期間待機し、また待機期間に受信したイベントの数がしきい値以下かどうかを確認する。

文書管理アプリケーション０３００が、許容を超えたエラーを示すイベントを受信していない場合、イベントを受信してから一定期間待機する（Ｓ２０１２）。その後、文書管理アプリケーション０３００は、一定期間内に再度異なるファイルに対するイベントを受信したかどうかを判断し（Ｓ２１０３）、受信しない場合はイベント種別変更処理（Ｓ１２０１）へ進む。一定期間内に再度異なるファイルに対するイベントを受信した場合、文書管理アプリケーション０３００は、受信したイベントの数がしきい値を超えたかどうかを判断し、超えない場合はイベント種別変更処理（Ｓ１２０１）へ進む。受信したイベントの数がしきい値を超えた場合、文書管理アプリケーション０３００は、許容を超えたエラーが来た場合と同様に一定期間待機し（Ｓ２１０５）、待機期間内に新規に受信するイベントの数がしきい値以下になったかどうかを判断する（Ｓ２１０６）。待機期間内に新規に受信するイベントの数がしきい値以下であれば、次のフォルダー内のファイル一覧取得処理（Ｓ２１０７）に進む。待機期間内に新規に受信するイベントの数がしきい値以上である場合、文書管理アプリケーション０３００は、再度一定期間待機し、また待機期間に受信したイベントの数がしきい値以下かどうかを確認する。フォルダー内のファイル一覧を取得処理（Ｓ２１０７）では、文書管理アプリケーション０３００は、フォルダー内のファイル一覧を取得する。そして、文書管理アプリケーション０３００は、取得したファイル一覧と表示しているファイルの一覧を比較し（Ｓ２１０８）、差分をファイル一覧の末尾に追加して表示する（Ｓ２１０９）。

これにより、大量のイベントが送信されるケースにおいても、大量のイベントの全てに対してファイルに関する情報の取得処理を繰り返すわけではなく、大量のイベントに対するファイルに関する情報の取得処理を１回にまとめることができる。その結果、文書管理アプリケーションのファイル情報の取得処理における負荷を軽減することが可能となる。

［その他の実施例］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である

Claims (13)

1. 外部装置と接続可能な情報処理装置であって、
   前記外部装置のフォルダー内の既存ファイルが指定されたソート方法の順序で並べられた画面を表示する表示手段と、
   前記外部装置から前記フォルダー内の変更を示す情報を受信する受信手段と、
   前記受信手段により受信された情報に従って前記画面の表示内容を更新する更新手段と、を有し、
   前記更新手段は、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示す場合、前記既存ファイルが前記指定されたソート方法の順序で並べられ、かつ、前記指定されたソート方法の順序で並べられた前記既存ファイルの一覧の先頭または末尾に前記新規ファイルが追加されるように前記画面を更新することを特徴とする情報処理装置。
2. 前記フォルダー内の変更を示す情報であるイベントを削除する削除手段を更に備え、
   前記削除手段により前記イベントが削除された場合、該イベントに従う前記画面の表示内容の更新は行われないことを特徴とする請求項１に記載の情報処理装置。
3. 前記削除手段は、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示すイベントであり、かつ、前記イベントに対応する前記新規ファイルが隠し属性を備える場合、前記イベントを削除することを特徴とする請求項２に記載の情報処理装置。
4. 前記削除手段は、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示すイベントであり、かつ、前記イベントに対応する前記新規ファイルの拡張子が特定の拡張子である場合、前記イベントを削除することを特徴とする請求項２に記載の情報処理装置。
5. 前記削除手段は、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示すイベントであり、かつ、前記イベントに対応する前記新規ファイルが特定の名称を含む場合、前記イベントを削除することを特徴とする請求項２に記載の情報処理装置。
6. 前記更新手段は、前記受信手段が、前記外部装置から前記フォルダー内の既存ファイルを削除することを示す第１のイベントを受信し、かつ、該第１のイベントの受信から一定期間内に前記第１のイベントに対応する既存ファイルと同じ名称の別のファイルが新規に作成されたことを示す第２イベントを更に受信した場合、前記第１のイベントに対応する既存ファイルに対して変更が行われたことを示す第３のイベントに従って前記画面の表示内容を更新することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 外部装置と接続可能な情報処理装置における制御方法であって、
   前記外部装置のフォルダー内の既存ファイルが指定されたソート方法の順序で並べられた画面を表示する表示工程と、
   前記外部装置から前記フォルダー内の変更を示す情報を受信する受信工程と、
   前記受信工程により受信された情報に従って前記画面の表示内容を更新する更新工程と、を有し、
   前記更新工程では、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示す場合、前記既存ファイルが前記指定されたソート方法の順序で並べられ、かつ、前記指定されたソート方法の順序で並べられた前記既存ファイルの一覧の先頭または末尾に前記新規ファイルが追加されるように前記画面が更新されることを特徴とする制御方法。
8. 外部装置と接続可能なコンピュータを、
   前記外部装置のフォルダー内の既存ファイルが指定されたソート方法の順序で並べられた画面を表示する表示手段と、
   前記外部装置から前記フォルダー内の変更を示す情報を受信する受信手段と、
   前記受信手段により受信された情報に従って前記画面の表示内容を更新する更新手段として機能させ、
   前記更新手段は、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示す場合、前記既存ファイルが前記指定されたソート方法の順序で並べられ、かつ、前記指定されたソート方法の順序で並べられた前記既存ファイルの一覧の先頭または末尾に前記新規ファイルが追加されるように前記画面を更新することを特徴とするプログラム。
9. 前記フォルダー内の変更を示す情報であるイベントを削除する削除手段を更に備え、
   前記削除手段により前記イベントが削除された場合、該イベントに従う前記画面の表示内容の更新は行われないことを特徴とする請求項８に記載のプログラム。
10. 前記削除手段は、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示すイベントであり、かつ、前記イベントに対応する前記新規ファイルが隠し属性を備える場合、前記イベントを削除することを特徴とする請求項９に記載のプログラム。
11. 前記削除手段は、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示すイベントであり、かつ、前記イベントに対応する前記新規ファイルの拡張子が特定の拡張子である場合、前記イベントを削除することを特徴とする請求項９に記載のプログラム。
12. 前記削除手段は、前記フォルダー内の変更を示す情報が前記フォルダーへの新規ファイルの追加を示すイベントであり、かつ、前記イベントに対応する前記新規ファイルが特定の名称を含む場合、前記イベントを削除することを特徴とする請求項９に記載のプログラム。
13. 前記更新手段は、前記受信手段が、前記外部装置から前記フォルダー内の既存ファイルを削除することを示す第１のイベントを受信し、かつ、該第１のイベントの受信から一定期間内に前記第１のイベントに対応する既存ファイルと同じ名称の別のファイルが新規に作成されたことを示す第２イベントを更に受信した場合、前記第１のイベントに対応する既存ファイルに対して変更が行われたことを示す第３のイベントに従って前記画面の表示内容を更新することを特徴とする請求項９乃至１２のいずれか１項に記載のプログラム。

Images