JP2005196337A - 情報処理装置、データ検索方法およびデータ検索プログラム - Google Patents

Abstract

【課題】 １つ以上の属性で構成されるデータを情報格納サーバから取得するときに、処理時間を容易に短くできる情報処理装置、データ検索方法およびデータ検索プログラムを提供することを目的とする。
【解決手段】 外部に設置されている情報格納サーバ１０３から１つ以上の属性で構成されるデータを検索可能な情報処理装置１であって、データを構成する１つ以上の属性のうち情報格納サーバ１０３から取得する属性を取得属性として設定可能であり、検索結果として情報格納サーバ１０３から取得するデータが取得属性に応じた属性で構成されることを特徴とすることにより上記課題を解決する。
【選択図】 図３

Description

本発明は、情報処理装置、データ検索方法およびデータ検索プログラムに係り、特に外部に設置されている情報格納サーバから１つ以上の属性で構成されているデータを検索する情報処理装置、データ検索方法およびデータ検索プログラムに関する。

近年、１つ以上の情報処理装置（以下、クライアントという）と情報格納サーバとがネットワークを介して接続されたシステムにおいて、情報格納サーバに格納されている１つ以上の属性で構成されるデータをクライアントが取得することがよく行われている。例えば特許文献１には、クライアント端末とデータサーバーとがネットワークを介して接続されたデータ検索システムにおいて、クライアントがデータサーバからデータを検索することが記載されている。

情報格納サーバは、例えばＬＤＡＰ（Lightweight Directory Access Protocol）に準拠するように構成されている。以下、ＬＤＡＰに準拠した情報処理サーバをＬＤＡＰサーバと呼ぶ。

ＬＤＡＰサーバで管理されているデータには、テキストデータやバイナリデータが含まれている。また、ＬＤＡＰサーバで管理されているデータは１つ以上の属性で構成されている。データを構成する属性は、ＲＦＣ（Request For Comments）で規定されているものやＬＤＡＰサーバで独自に定義しているものも含まれる。また、ＬＤＡＰサーバで管理されているデータは、データサイズもＬＤＡＰサーバによってバラツキがある。

ＲＦＣ２２５１で規定されたＬＤＡＰバージョン３の仕様を実装したＬＤＡＰサーバであれば、ＬＤＡＰサーバで管理している属性の説明（以下、スキーマという）のスキーマ一覧をクライアントが取得することができる。

クライアントの一例としての画像処理装置は、プリンタ，コピー，ファクシミリおよびスキャナなどの各装置の機能を１つの筐体内に収納している。画像処理装置は、１つの筐体内に表示部，印刷部および撮像部などを設けると共に、プリンタ，コピー，ファクシミリおよびスキャナにそれぞれ対応する４種類のソフトウェアを設け、そのソフトウェアを切り替えることより、プリンタ，コピー，ファクシミリおよびスキャナとして動作させるものである。例えば特許文献２には、クライアントの一例としての画像処理装置が記載されている。
特開２００３−１０８５５８号公報 特開２００２−８４３８３号公報

しかしながら、クライアントはＬＤＡＰサーバのバージョンや実装形式によっては、ＬＤＡＰサーバのスキーマ一覧を必ずしも取得できるとは限らない。また、ＬＤＡＰサーバからスキーマ一覧を取得できたとしても、そのスキーマ一覧にデータを構成している属性やデータサイズが正確に規定されていないこともある。この場合、クライアントはＬＤＡＰサーバからデータを取得するまでの処理時間やデータサイズがどの程度であるかを予測することができない。

したがって、クライアントはＬＤＡＰサーバからデータを検索する場合に、その検索結果としてＬＤＡＰサーバから取得したデータを処理して表示するまでの処理時間が長く掛かってしまう場合があるという問題が生じていた。また、クライアントは取得したデータがバイナリデータである場合に、テキストデータに対して行うエンコード処理を無駄に行うという問題が生じていた。

本発明は、上記の点に鑑みなされたもので、１つ以上の属性で構成されるデータを情報格納サーバから取得するときに、処理時間を容易に短くできる情報処理装置、データ検索方法およびデータ検索プログラムを提供することを目的とする。

そこで、上記課題を解決するため、本発明は、外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索可能な情報処理装置であって、前記データを構成する１つ以上の属性のうち前記情報格納サーバから取得する属性を取得属性として設定可能であり、検索結果として前記情報格納サーバから取得するデータが前記取得属性に応じた属性で構成されることを特徴とする。

また、本発明は、外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索可能な情報処理装置のデータ検索方法であって、前記データを構成する１つ以上の属性のうち前記情報格納サーバから取得する属性を取得属性として設定させる段階と、前記取得属性に応じた属性で構成されるデータを含む検索結果を前記情報格納サーバから取得する段階とを有することを特徴とする。

また、本発明は、コンピュータに、外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索させるデータ検索プログラムであって、前記データを構成する１つ以上の属性のうち前記情報格納サーバから取得する属性を取得属性として設定させる手順と、前記取得属性に応じた属性で構成されるデータを含む検索結果を前記情報格納サーバから取得する手順とを実行させるためのデータ検索プログラムであることを特徴とする。

本発明は、１つ以上の属性で構成されるデータを情報格納サーバから取得する為、その情報格納サーバから取得する属性を取得属性として設定し、その取得属性に応じた属性で構成されるデータを情報格納サーバから取得する。即ち、情報格納サーバから取得する属性を設定可能である。言い換えれば、情報格納サーバから取得しない属性を設定することができる。

例えば処理時間が短い属性を情報格納サーバから取得する取得属性として設定しておくことで、情報格納サーバからデータを取得するときの処理時間を短くできる。言い換えれば、処理時間が長い属性を情報格納サーバから取得しない属性として設定することで、情報格納サーバからデータを取得するときの処理時間を短くできる。

本発明によれば、１つ以上の属性で構成されるデータを情報格納サーバから取得するときに、処理時間を容易に短くできる情報処理装置、データ検索方法およびデータ検索プログラムを提供可能である。

次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。本実施例では、クライアントの一例としての画像処理装置について説明する。なお、本実施例で説明する画像処理装置は、プリンタ，コピー，ファクシミリおよびスキャナなどの各装置の機能を１つの筐体内に収納している為、融合機と呼ぶ。

図１は、本発明による融合機のソフトウェア構成について説明するための一実施例の構成図である。融合機１は、ソフトウェア群２と，融合機起動部３と，ハードウェア資源４とを含むように構成される。

ハードウェア資源４は、プロッタ１１と，スキャナ１２と，ファクシミリなどのその他のハードウェアリソース１３とを含む。ソフトウェア群２は、ＵＮＩＸ（登録商標）などのオペレーティングシステム（以下、ＯＳという）上に起動されているアプリケーション層５とプラットフォーム６とを含む。

アプリケーション層５は、プリンタ，コピー，ファックスおよびスキャナなどの画像形成にかかるユーザサービスにそれぞれ固有の処理を行うプログラムを含む。図１のアプリケーション層５は、プリンタアプリ２１と，コピーアプリ２２と，ファックスアプリ２３と，スキャナアプリ２４と，ネットファイルアプリ２５とを含む。なお、ネットファイルアプリ２５はネットワークファイル用アプリケーションであり、融合機１にネットワークを介して接続されるネットワーク機器とのデータ通信を管理するものである。

プラットフォーム６は、アプリケーション層５からの処理要求を解釈してハードウェア資源４の獲得要求を発生するコントロールサービス層９と、１つ以上のハードウェア資源４の管理を行ってコントロールサービス層９からの獲得要求を調停するシステムリソースマネージャ（以下、ＳＲＭという）３９と、ＳＲＭ３９からの獲得要求に応じてハードウェア資源４の管理を行うハンドラ層１０とを含む。

コントロールサービス層９は、ＮＣＳ３１，ＤＣＳ３２，ＯＣＳ３３，ＦＣＳ３４，ＥＣＳ３５，ＭＣＳ３６，ＵＣＳ３７，ＳＣＳ３８など、一つ以上のサービスモジュールを含む。なお、プラットフォーム６は予め定義されている関数により、アプリケーション層５からの処理要求を受信するＡＰＩ５３を有するように構成されている。ＯＳは、アプリケーション層５およびプラットフォーム６の各ソフトウェアをプロセスとして並列実行する。

ＮＣＳ（ネットワークコントロールサービス）３１のプロセスは、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分ける際の仲介、又は各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。例えばＮＣＳ３１は、融合機１にネットワークを介して接続されるネットワーク機器とのデータ通信を制御する。

ＤＣＳ（デリバリーコントロールサービス）３２のプロセスは、融合機１に蓄積されている文書データの配送などの制御を行う。ＯＣＳ（操作パネルコントロールサービス）３３のプロセスは、後述する操作パネルの制御を行う。

ＦＣＳ（ファックスコントロールサービス）３４のプロセスは、アプリケーション層５からＰＳＴＮまたはＩＳＤＮ網を利用したファックスの送受信，バックアップ用のメモリで管理されている各種ファックスデータの登録又は引用，ファックスの読み取り，ファックスの受信印刷などを行うためのＡＰＩを提供する。

ＥＣＳ（エンジンコントロールサービス）３５のプロセスは、プロッタ１１，スキャナ１２，ハードウェアリソース１３などのエンジン部の制御を行う。ＭＣＳ（メモリコントロールサービス）３６のプロセスは、メモリの取得及び解放，ＨＤＤの利用，画像データの圧縮および伸張などの制御を行う。ＵＣＳ（ユーザ情報コントロールサービス）３７のプロセスは、ユーザ情報の管理を行うものである。

ＳＣＳ（システムコントロールサービス）３８のプロセスは、操作部の制御，システム画面の表示，ＬＥＤの表示，ハードウェア資源の管理，アプリケーションの管理，割り込みアプリケーションの制御などの処理を行う。

ＳＲＭ３９のプロセスは、ＳＣＳ３８と共にシステムの制御およびハードウェア資源４の管理を行うものである。例えばＳＲＭ３９のプロセスは、プロッタ１１やスキャナ１２などのハードウェア資源４を利用する上位層からの獲得要求に従って調停を行い、ハードウェア資源４の実行を制御する。

具体的に、ＳＲＭ３９のプロセスは獲得要求されたハードウェア資源４が利用可能であるか（他の獲得要求により利用されていないか）を判定し、利用可能であれば獲得要求されたハードウェア資源４が利用可能である旨を上位層に通知する。ＳＲＭ３９のプロセスは、上位層からの獲得要求に対してハードウェア資源４を利用するためのスケジューリングを行い、要求内容（プリンタエンジンによる紙搬送と作像動作，メモリの確保，ファイル生成など）を直接実施している。

また、ハンドラ層１０は後述するＦＣＵ（ファックスコントロールユニット）の管理を行うＦＣＵＨ（ファックスコントロールユニットハンドラ）４０と、プロセスに対するメモリの割り振り及びプロセスに割り振ったメモリの管理を行うＩＭＨ（イメージメモリハンドラ）４１とを含む。ＳＲＭ３９及びＦＣＵＨ４０は、予め定義されている関数によりハードウェア資源４に対する処理要求を送信するエンジンＩ／Ｆ５４を利用して、ハードウェア資源４に対する処理要求を行う。

図１の構成により、融合機１は各アプリケーションで共通的に必要な処理をプラットフォーム６で一元的に処理することができる。次に、融合機１のハードウェア構成について説明する。

図２は、本発明による融合機のハードウェア構成について説明するための一実施例の構成図である。図２の融合機１は、コントローラ６０，操作パネル８０，ＦＣＵ８１，エンジン部８２を有する。

コントローラ６０は、ＣＰＵ６１，システムメモリ６２，ＮＢ６３，ＳＢ６４，ＡＳＩＣ６６，ローカルメモリ６７，ＨＤＤ６８、ＮＩＣ６９，ＵＳＢ Ｉ／Ｆ７０，ＩＥＥＥ１３９４ Ｉ／Ｆ７１，セントロニクス Ｉ／Ｆ７２を有する。

操作パネル８０は、コントローラ６０のＡＳＩＣ６６に接続されている。また、ＦＣＵ８１およびエンジン部８２はコントローラ６０のＡＳＩＣ６６にＰＣＩバス８３を介して接続されている。

コントローラ６０は、ＡＳＩＣ６６にローカルメモリ６７，ＨＤＤ６８などが接続されると共に、ＣＰＵ６１とＡＳＩＣ６６とがＣＰＵチップセットのＮＢ６３を介して接続されている。なお、ＡＳＩＣ６６とＮＢ６３とはＡＧＰ（Accelerated Graphics Port）６５を介して接続されている。

ＣＰＵ６１は、融合機１の全体制御を行うものである。図１の融合機１では、ＣＰＵ６１がコントロールサービス層９を形成する１つ以上のサービスモジュールと、ＳＲＭ３９と、ハンドラ層１０を形成するＦＣＵＨ４０，ＩＭＨ４１とをＯＳ上に起動させた後、アプリケーション層５を形成するプリンタアプリ２１，コピーアプリ２２，ファックスアプリ２３，スキャナアプリ２４，ネットファイルアプリ２５を起動して実行させる。

ＮＢ（ノースブリッジ）６３は、ＣＰＵ６１，システムメモリ６２，ＳＢ６４，ＡＳＩＣ６６，ＮＩＣ６９，ＵＳＢ Ｉ／Ｆ７０，ＩＥＥＥ１３９４ Ｉ／Ｆ７１及びセントロニクス Ｉ／Ｆ７２を接続するためのブリッジである。ＮＢ６３は、ＳＢ６４，ＮＩＣ６９，ＵＳＢ Ｉ／Ｆ７０，ＩＥＥＥ１３９４ Ｉ／Ｆ７１及びセントロニクス Ｉ／Ｆ７２とＰＣＩバス７３を介して接続されている。なお、ＳＢ（サウスブリッジ）６４は、ＰＣＩバス７３とＲＯＭや周辺デバイス等とを接続するためのブリッジである。

システムメモリ６２は、描画用メモリ等として用いるメモリである。ローカルメモリ６７は、コピー用画像バッファ，符号バッファ等として用いるメモリである。ＡＳＩＣ６６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。また、ＨＤＤ６８は画像データの蓄積，文書データの蓄積，プログラムの蓄積，フォントデータの蓄積，フォームの蓄積などを行うストレージ（補助記憶装置）の一例である。

ＮＩＣ（ネットワークインターフェースカード）６９は、融合機１をインターネットやＬＡＮ等のネットワークに接続するインターフェース機器である。また、ＵＳＢ Ｉ／Ｆ７０，ＩＥＥＥ１３９４ Ｉ／Ｆ７１およびセントロニクス Ｉ／Ｆ７２は、夫々の規格に準じたインターフェースである。操作パネル８０は、ユーザからの入力操作を受け付けると共に、ユーザに向けた表示を行う操作部である。なお、ＦＣＵ８１はバックアップ用のメモリを有している。ＦＣＵ８１が有するメモリは、例えば融合機１の電源がＯＦＦのときに受信したファクシミリデータを一時的に格納するために利用される。

図３は、ＬＤＡＰサーバ情報の取得要求，追加要求，変更要求，削除要求について説明するための図である。なお、図３では説明に必要のない構成を省略している。ＵＣＳ３７は、ＬＤＡＰサーバ情報を一元管理している。ＵＣＳ３７は、例えばＬＤＡＰサーバ情報をＨＤＤ１０８に格納して管理している。

ＬＤＡＰサーバ情報は、サーバ名称，ホスト名（ＩＰアドレス），ポート番号，検索開始位置，認証情報，任意検索条件（複数）および文字コードなどをデータ項目として含んでいる。ＵＣＳ３７は、ファックスアプリ２３，スキャナアプリ２４又はＳＣＳ３８からの取得要求に応じて、ＬＤＡＰサーバ情報をファックスアプリ２３，スキャナアプリ２４又はＳＣＳ３８に提供する。また、ＵＣＳ３７は、ＳＣＳ３８からの追加要求，変更要求又は削除要求に応じて、ＬＤＡＰサーバ情報を追加，変更又は削除する。

ファックスアプリ２３は、ＵＣＳ３７にＬＤＡＰサーバ情報の取得要求を行うことで検索したいＬＤＡＰサーバ１０３のＬＤＡＰサーバ情報を取得する。ファックスアプリ２３はＬＤＡＰサーバ情報を用いてファックス機能に必要なユーザ情報を取得し、そのユーザ情報を用いて操作パネル８０に画面１１０を表示する。画面１１０には、例えばファックスデータを送信する宛先情報（例えばファックス番号など）を選択するための情報が表示される。

スキャナアプリ２４は、ＵＣＳ３７にＬＤＡＰサーバ情報の取得要求を行うことで検索したいＬＤＡＰサーバ１０３のＬＤＡＰサーバ情報を取得する。スキャナアプリ２４はＬＤＡＰサーバ情報を用いてスキャナ機能に必要なユーザ情報を取得し、そのユーザ情報を用いて操作パネル８０に画面１２０を表示する。画面１２０には、例えばスキャナデータを送信する宛先情報（例えば電子メールアドレスなど）を選択するための情報が表示される。

ＳＣＳ３８のシステム初期設定機能１０２は、ＵＣＳ３７にＬＤＡＰサーバ情報の取得要求，追加要求，変更要求，削除要求を行うことでＬＤＡＰサーバ情報の取得，追加，変更，削除を行う。なお、ＳＣＳ３８のソフトキーボード機能１０１は操作パネル８０にソフトキーボードを表示し、そのソフトキーボードの制御を行う。

図４は、検索機能を実現するＵＣＳのソフトウェア構成について説明するための一例の構成図である。なお、図４では説明に必要のない構成を省略している。ＵＣＳ３７は、ＡＰＩ層２１１，検索機能２１２，データベース制御機能２１３を有する。ＡＰＩ層２１１はファックスアプリ２３，スキャナアプリ２４又はＳＣＳ３８等のＵＣＳクライアント２００とのインターフェースを実現する。

検索機能２１２は、ＬＤＡＰ制御部２１４，ローカル制御部２１５で構成され、ＬＤＡＰライブラリ２２２，エンコードライブラリ２２３を用いてＬＤＡＰサーバに格納されているデータの検索機能を実現する。以下、ＬＤＡＰサーバに格納されているデータの検索をＬＤＡＰ検索と呼ぶ。

データベース制御機能２１３は、初期化部２１６，編集部２１７，取得部２１８，追加部２１９，削除部２２０およびＩ／Ｏ制御部２２１で構成され、ＨＤＤ６８等の記憶部２３０に格納されているＬＤＡＰサーバ情報２３１，ＬＤＡＰユーザ情報２３２及びローカルユーザ情報２３３を制御する。

上記のようなハードウェアおよびソフトウェア構成の融合機１を用いて図５のような手順でＬＤＡＰ検索が行われる。図５は、ＬＤＡＰ検索の一例のシーケンス図である。ステップＳ１０に進み、ファックスアプリ２３，スキャナアプリ２４等のＵＣＳクライアント２００は、ＵＣＳ３７に対してＬＤＡＰ検索要求を行う。なお、ＵＣＳクライアント２００はＬＤＡＰ検索要求をＵＣＳ６７に対して行うとき、サーバ名称，ホスト名（ＩＰアドレス），ポート番号などの検索対象ＬＤＡＰサーバ情報、検索フィルタ，取得属性，検索開始位置などの検索情報をＬＤＡＰ検索要求と共にＵＣＳ３７に供給する。

ステップＳ１１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、検索情報に応じた検索要求を行う。ステップＳ１２に進み、ＵＣＳ３７はステップＳ１１の検索要求に対する検索結果を受信する。ステップＳ１２で受信する検索結果は、例えば１エントリごとの図６のようなデータ構造の情報である。図６は、検索結果の一例のデータ構造図である。

ステップＳ１３に進み、ＵＣＳ３７は図６のような検索結果を図７のような融合機１用のエントリのデータ構造に１件ずつ変換し、ＬＤＡＰユーザ情報とする。図７は、ＬＤＡＰユーザ情報の一例のデータ構造図である。図７のＬＤＡＰユーザ情報は、エントリＩＤにより識別されるエントリ情報に、メール情報，ＦＡＸ情報，所属情報，付加情報などが関連付けられている。なお、付加情報はユーザが任意に設定できるＬＤＡＰサーバから取得する属性である。

ステップＳ１４に進み、ＵＣＳ３７は図６のような検索結果を破棄する。ステップＳ１５に進み、ＵＣＳ３７はステップＳ１３で検索結果から変換したＬＤＡＰユーザ情報をステップＳ１０のＬＤＡＰ検索要求に対する応答として、ＵＣＳクライアント２００に供給する。

ステップＳ１３の処理について更に説明する。図８は、検索結果を融合機用のエントリのデータ構造に１件ずつ変換する処理の一例のフローチャートである。ステップＳ２０に進み、ＵＣＳ３７は検索結果から一つ目のエントリを抽出する。ステップＳ２０に続いてステップＳ２１に進み、ＵＣＳ３７は抽出したエントリがあるか否かを判定する。

エントリがあれば（Ｓ２１においてＹＥＳ）、ＵＣＳ３７はステップＳ２２に進み、ＬＤＡＰユーザ情報のエントリ情報として追加する。なお、抽出したエントリがなければ（Ｓ２１においてＮＯ）、ＵＣＳ３７は図８の処理を終了する。

ステップＳ２２に続いてステップＳ２３に進み、ＵＣＳ３７はステップＳ２０で抽出したエントリから一つ目の属性を抽出する。例えば図６の検索結果の場合、ＵＣＳ３７は属性「ｃｎ」を抽出する。ステップＳ２４に進み、ＵＣＳ３７は抽出した属性があるか否かを判定する。

属性があれば（Ｓ２４においてＹＥＳ）、ＵＣＳ３７はステップＳ２５に進み、抽出した属性の属性値（実データ）を抽出する。例えば図６の検索結果の場合、ＵＣＳ３７は抽出した属性「ｃｎ」の属性値「Ｍａｓａｈｉｒｏ Ｓｕｚｕｋｉ」を抽出する。なお、属性がなければ（Ｓ２４においてＮＯ）、ＵＣＳ３７は後述するステップＳ３４に進む。

ステップＳ２５に続いてステップＳ２６に進み、ＵＣＳ３７は抽出した属性値があるか否かを判定する。属性値があれば（Ｓ２６においてＹＥＳ）、ＵＣＳ３７はステップＳ２７に進み、抽出した属性値のエンコードを行う。ステップＳ２７のエンコードは、抽出した属性名を操作パネル８０に表示できる文字コードに変換する処理である。なお、属性値がなければ（Ｓ２６においてＮＯ）、ＵＣＳ３７は後述するステップＳ３２に進む。

ステップＳ２８に進み、ＵＣＳ３７は抽出した属性の名（以下、抽出属性名という）と融合機１用の属性の名（以下、内部属性名という）とを順番に比較していく。ステップＳ２９に進み、ＵＣＳ３７は抽出属性名と一致する内部属性名を見つけると、その内部属性名に対応するデータ項目に属性値を格納する。

ステップＳ３０に進み、ＵＣＳ３７は抽出した属性の次の属性値を抽出する。ステップＳ３１に進み、ＵＣＳ３７は抽出した属性値があるか否かを判定する。属性値があれば（Ｓ３１においてＹＥＳ）、ＵＣＳ３７はステップＳ２７に戻り、ステップＳ２７〜Ｓ３１の処理を繰り返す。なお、属性値がなければ（Ｓ２６においてＮＯ）、ＵＣＳ３７はステップＳ３２に進む。

ステップＳ３２では、ＵＣＳ３７が、ステップＳ２０で抽出したエントリから次の属性を抽出する。例えば図６の検索結果の場合、ＵＣＳ３７は属性「ｏｕ」を抽出する。ステップＳ３３に進み、ＵＣＳ３７は抽出した属性があるか否かを判定する。

属性があれば（Ｓ３３においてＹＥＳ）、ＵＣＳ３７はステップＳ２５に戻る。属性がなければ（Ｓ３３においてＮＯ）、ＵＣＳ３７はステップＳ３４に進む。以上で、１エントリのデータ構造が融合機１用のエントリのデータ構造に変換される。

ステップＳ３４では、ＵＣＳ３７が、検索結果から次のエントリを抽出する。ステップＳ３５に進み、ＵＣＳ３７は抽出したエントリがあるか否かを判定する。エントリがあれば（Ｓ３５においてＹＥＳ）、ＵＣＳ３７はステップＳ２２に戻る。なお、抽出したエントリがなければ（Ｓ３５においてＮＯ）、ＵＣＳ３７は図８の処理を終了する。

現状、融合機１は使用する属性をテキストデータと考えており、バイナリデータ（ｊｐｅｇＰｈｏｔｏ）のような予想外の属性を取得すると、エンコード等の処理を無駄に行って、ＵＣＳクライアント２００に検索結果を返すまでに時間が掛かる。そこで、本発明では以下の実施例で説明するように、融合機１で必要のない属性や処理に時間の掛かる属性を取得しないようにする。ただし、取得する属性は操作パネル８０からユーザが設定可能である。そこで、本発明では必要のない属性や処理に時間の掛かる属性を取得しないような設定をユーザ主導で行うようにしている。

本発明の実施例１は、エントリを構成する属性ごとに処理時間を提示することで、今後取得しない属性をユーザに設定させるものである。ユーザは処理時間の長い属性を今後取得しない属性として設定することができる。実施例１を実現するためのＵＣＳ３７は、図９のように構成される。

図９は、本発明による検索機能を実現するＵＣＳのソフトウェア構成について説明するための一例の構成図である。図９の構成図は、タイマ機能２２４を有していることが図４の構成図と異なっている。タイマ機能２２４は、エントリを構成する属性ごとに処理時間を計測する。図９のタイマ機能２２４以外の構成は、図４の構成と同様であるため、説明を省略する。

図１０は、検索結果を融合機用のエントリのデータ構造に１件ずつ変換するとき、エントリを構成する属性ごとの処理時間を計測する処理の一例のフローチャートである。図１０のフローチャートは、ステップＳ４８のタイマを開始する処理とステップＳ５２のタイマを終了する処理とを有していることが図８のフローチャートと異なっている。

ステップＳ４１〜Ｓ４７は、図８のステップＳ２０〜Ｓ２６の処理と同様であるため説明を省略する。ＵＣＳ３７は抽出した属性値があれば（Ｓ４７においてＹＥＳ）、ステップＳ４８に進み、タイマ機能２２４のタイマを開始する。ステップＳ４９に進み、ＵＣＳ３７は抽出した属性値のエンコードを行う。ステップＳ５０に進み、ＵＣＳ３７は抽出属性名と内部属性名とを順番に比較していく。ステップＳ５１に進み、ＵＣＳ３７は抽出属性名と一致する内部属性名を見つけると、その内部属性名に対応するデータ項目に属性値を格納する。

ステップＳ５２に進み、ＵＣＳ３７はタイマ機能２２４のタイマを終了する。ステップＳ４９〜Ｓ５１の処理は、エントリを構成する１つの属性を融合機１のＬＤＡＰユーザ情報として格納し、ＵＣＳクライアント２００が使える状態とするまでの処理である。したがって、ステップＳ４８のタイマの開始およびステップＳ５２のタイマの終了により、エントリを構成する１つの属性を融合機１のＬＤＡＰユーザ情報として格納し、ＵＣＳクライアント２００が使える状態とするまでの処理時間が計測される。なお、計測された処理時間はＬＤＡＰサーバ情報２３１に処理時間情報として格納される。

また、１エントリを構成する全ての属性の処理時間を加算することで、１エントリを融合機１のＬＤＡＰユーザ情報として格納し、ＵＣＳクライアント２００が使える状態とするまでの処理時間も算出できる。なお、ステップＳ５３〜Ｓ５８は、図８のステップＳ３０〜Ｓ３５の処理と同様であるため説明を省略する。

図１１は、本発明によるＬＤＡＰ検索の第１実施例のシーケンス図である。このシーケンス図は、全ての属性を処理した後、エントリを構成する属性ごとに処理時間を提示することで、今後取得しない属性をユーザに設定させるものである。

ステップＳ１００に進み、ＵＣＳクライアント２００はＵＣＳ３７に対してＬＤＡＰ検索要求を行う。なお、ＵＣＳクライアント２００はＬＤＡＰ検索要求をＵＣＳ６７に対して行うとき、サーバ名称，ホスト名（ＩＰアドレス），ポート番号などの検索対象ＬＤＡＰサーバ情報、検索フィルタ，取得属性，検索開始位置などの検索情報をＬＤＡＰ検索要求と共にＵＣＳ３７に供給する。ここでは、取得属性として「ｃｎ」，「ｍａｉｌ」，「ｏ」が含まれている例を説明する。

ステップＳ１０１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、検索情報に応じた検索要求を行う。ステップＳ１０２に進み、ＵＣＳ３７はステップＳ１０１の検索要求に対する検索結果を受信する。

ステップＳ１０３に進み、ＵＣＳ３７は検索結果を図１０のようなフローチャートの手順で融合機１用のエントリのデータ構造に変換し、ＬＤＡＰユーザ情報とする。ステップＳ１０３では、エントリを構成する属性ごとの処理時間が計測され、処理時間情報としてＬＤＡＰサーバ情報２３１に格納される。ステップＳ１０３の処理後、ＵＣＳ３７は検索結果を破棄する。

ステップＳ１０４に進み、ＵＣＳ３７はステップＳ１０３で検索結果から変換したＬＤＡＰユーザ情報をステップＳ１００のＬＤＡＰ検索要求に対する応答として、ＵＣＳクライアント２００に供給する。ステップＳ１０５に進み、ＵＣＳクライアント２００はＵＣＳ３７に対して処理時間の問い合わせを行う。ステップＳ１０６に進み、ＵＣＳ３７はＬＤＡＰサーバ情報２３１から処理時間情報を読み出し、その処理時間情報２４０をＵＣＳクライアント２００に供給する。

処理時間情報２４０はＬＤＡＰサーバ１０３ごとに管理されている情報であり、ＬＤＡＰサーバを識別するＬＤＡＰサーバＩＤ，属性ごとの処理時間の平均およびピークが含まれている。ステップＳ１０７に進み、ＵＣＳクライアント２００は閾値よりも処理時間の掛かった属性があるか否かを判定し、閾値よりも処理時間の掛かった属性があれば図１２のような処理時間確認画面１０００を操作パネル８０に表示する。

図１２は、処理時間確認画面の一例のイメージ図である。図１２の処理時間確認画面１０００は、属性と、属性ごとの処理時間の平均，最大，所定件数（例えば１００件）の合計と、取得しない属性と、取得しない属性の有効期限とが含まれている。

ユーザは処理時間確認画面１０００の属性ボタン１００１を押下して属性ボタン１００１の非反転表示または反転表示を切り替えることで、取得しない属性を選択できる。図１２の例では、属性「会社名」の処理時間が他の属性と比べて長いため、取得しない属性として選択されている。なお、取得しない属性の有効期限は有効期限ボタン１００２で切り替えることができる。

取得しない属性の有効期限を「時間のみ」に切り替えると、取得しない属性の有効期限はＬＤＡＰ検索画面を抜けるまでとなる。取得しない属性の有効期限を「以降継続」に切り替えると、取得しない属性の有効期限は以降のＬＤＡＰ検索に有効となる。なお、取得しない属性の有効期限は「時間のみ」又は「以降継続」が固定されていてもよいし、一度設定した取得しない属性の有効期限を変更できるようにしてもよい。取得しない属性の有効期限は、例えばＵＣＳクライアント２００がＬＤＡＰサーバ１０３ごとに保持する。

なお、ＵＣＳクライアント２００はステップＳ１０７の処理前またはステップＳ１０８の処理後に図１３のようなＬＤＡＰ検索結果画面１１００を操作パネル８０に表示することで、ＬＤＡＰ検索結果をユーザに確認させる。図１３は、ＬＤＡＰ検索結果画面の一例のイメージ図である。

そして、ステップＳ１０９に進み、ＵＣＳクライアント２００はＵＣＳ３７に対して次のＬＤＡＰ検索要求を行う。ステップＳ１０８で取得しない属性として「ｏ」が選択されたとすると、ＬＤＡＰ検索要求と共にＵＣＳ３７に供給される検索情報の取得属性は、取得属性「ｏ」が削除され、「ｃｎ」，「ｍａｉｌ」となる。

なお、図１１のシーケンス図では閾値よりも処理時間の掛かった属性があるか否かを判定し、閾値よりも処理時間の掛かった属性があったときに図１２のような処理時間確認画面１０００を操作パネル８０に表示しているが、閾値よりも処理時間の掛かった属性があるか否かをＵＣＳクライアント２００で判定しないような仕組みも考えられる。

例えば図１１のシーケンス図において、ステップＳ１０７の処理に代えて図１３のＬＤＡＰ検索結果画面１１００を操作パネル８０に表示し、処理時間確認ボタン１１０１が押下されたときにステップＳ１０８に進むようにしてもよい。

ユーザは、エントリを構成する属性ごとに処理時間を確認し、今後取得しない属性を自由に設定することができる。

本発明の実施例２は、処理時間が基準時間より掛かる属性があった時点で、その属性および処理時間を提示し、今後取得しない属性をユーザに設定させるものである。ユーザは処理時間の長い属性を今後取得しない属性として設定することができる。なお、ＵＣＳ３７の構成は図９の構成と同様である。

図１４は、本発明によるＬＤＡＰ検索の第２実施例のシーケンス図である。このシーケンス図は、処理時間が基準時間より掛かる属性があった時点で、その属性および処理時間を提示することで、今後取得しない属性をユーザに設定させるものである。

ステップＳ２００に進み、ＵＣＳクライアント２００はＵＣＳ３７に対してＬＤＡＰ検索要求を行う。なお、ＵＣＳクライアント２００はＬＤＡＰ検索要求をＵＣＳ６７に対して行うとき、サーバ名称，ホスト名（ＩＰアドレス），ポート番号などの検索対象ＬＤＡＰサーバ情報、検索フィルタ，取得属性，検索開始位置，基準時間などの検索情報をＬＤＡＰ検索要求と共にＵＣＳ３７に供給する。ステップＳ２００のあと、ＵＣＳクライアント２００は操作パネル８０に図１５のような画面１２００を表示する。図１５は、実施例２における一例の画面遷移図である。

ステップＳ２０１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、検索情報に応じた検索要求を行う。ステップＳ２０２に進み、ＵＣＳ３７はステップＳ１０１の検索要求に対する検索結果を受信する。

ステップＳ２０３に進み、ＵＣＳ３７は検索結果に含まれる１エントリを図１０のようなフローチャートの手順で融合機１用のエントリのデータ構造に変換し、ＬＤＡＰユーザ情報とする。ステップＳ２０３では、１エントリを構成する属性ごとの処理時間が計測され、処理時間情報としてＬＤＡＰサーバ情報２３１に格納される。ステップＳ２０３の処理後、ＵＣＳ３７は検索結果を破棄する。

ステップＳ２０４に進み、ＵＣＳ３７はＬＤＡＰサーバ情報２３１から処理時間情報を読み出し、基準時間よりも処理時間の掛かった属性があるか否かを判定する。なお、ＵＣＳ３７はステップＳ２００でＵＣＳクライアント２００から供給された検索情報に含まれている基準時間を利用する。

基準時間よりも処理時間の掛かった属性があれば（Ｓ２０４においてＹＥＳ）、ＵＣＳ３７はステップＳ２０５に進み、処理時間オーバー通知をＵＣＳクライアント２００に供給する。基準時間よりも処理時間の掛かった属性がなければ（Ｓ２０４においてＮＯ）、ＵＣＳ３７はステップＳ２１１に進む。

ステップＳ２０６では、ＵＣＳクライアント２００が、ＵＣＳ３７に対して基準時間よりも処理時間の掛かった属性の問い合わせを行う。ステップＳ２０７に進み、ＵＣＳ３７は基準時間よりも処理時間の掛かった属性と、その属性の処理時間とをＵＣＳクライアント２００に供給する。

ステップＳ２０８に進み、ＵＣＳクライアント２００は図１５のような注意画面１３００を操作パネル８０に表示する。注意画面１３００は、基準時間よりも処理時間の掛かった属性と、その属性の１件あたりの処理時間と、全件の処理時間とが含まれている。

ユーザは注意画面１３００の「表示しない」ボタン１３０３を押下することで、基準時間よりも処理時間の掛かった属性を、取得しない属性として選択できる。なお、ユーザは注意画面１３００の「表示する」ボタン１３０３を押下することで、基準時間よりも処理時間の掛かった属性であっても、取得する属性のままにしておくことができる。なお、注意画面１３００の「詳細設定」ボタン１３０１が押下されると、ＵＣＳクライアント２００は詳細設定画面１４００を操作パネル８０に表示する。

詳細設定画面１４００は、属性と、属性ごとの処理時間の平均，最大，所定件数（例えば１００件）の合計と、取得する全ての属性の合計処理時間と、取得しない属性と、取得しない属性の有効期限とが含まれている。なお、ユーザは詳細設定画面１４００の属性ボタン１４０１を押下して属性ボタン１４０１の非反転表示または反転表示を切り替えることで、取得しない属性を選択できる。詳細設定画面１４００における取得しない属性の有効期限は、図１２の処理時間確認画面１０００と同様である。

また、詳細設定画面１４００は属性を処理時間順にソートして表示してもよい。取得する全ての属性の合計処理時間は、詳細設定画面１４００で選択されている取得属性に連動して変化する。

注意画面１３００の「表示しない」ボタン１３０３が押下されると、ＵＣＳクライアント２００はステップＳ２０９に進み、基準時間よりも処理時間の掛かった属性を取得しない属性として選択するための取得属性変更要求をＵＣＳ３７に対して行う。なお、詳細設定画面１４００において取得しない属性が選択された場合、ＵＣＳクライアント２００はステップＳ２０９に進み、その属性を取得しない属性として選択するための取得属性変更要求をＵＣＳ３７に対して行う。

ステップＳ２１０に進み、ＵＣＳ３７はステップＳ２０９に応じて取得しない属性の設定が成功すれば、ステップＳ２１０に進み、成功した旨をＵＣＳクライアント２００に通知する。ステップＳ２１１に進み、ＵＣＳ３７は融合機１用のエントリのデータ構造に変換するエントリが検索結果にあるか否かを判定する。融合機１用のエントリのデータ構造に変換するエントリが検索結果にあると判定すると（Ｓ２１１においてＹＥＳ）、ＵＣＳ３７はステップＳ２０３に戻る。なお、融合機１用のエントリのデータ構造に変換するエントリが検索結果になおと判定すると（Ｓ２１１においてＮＯ）、ＵＣＳ３７はステップＳ２０３で検索結果から変換したＬＤＡＰユーザ情報をステップＳ２００のＬＤＡＰ検索要求に対する応答として、ＵＣＳクライアント２００に供給する。この後、ＵＣＳクライアント２００は図１５のようなＬＤＡＰ検索結果画面１５００を操作パネル８０に表示することで、ＬＤＡＰ検索結果をユーザに確認させる。

ユーザは、処理時間が基準時間より掛かる属性があった時点で、その属性および処理時間を確認し、今後取得しない属性を自由に設定することができる。

本発明の実施例３は、ＬＤＡＰサーバ１０３ごとに属性の処理時間を格納しておき、ＬＤＡＰサーバ情報の設定時に、処理時間が基準時間より掛かる属性およびその属性の処理時間を提示してユーザに確認させるものである。なお、ＵＣＳ３７の構成は図９の構成と同様である。

図１６は、本発明によるＬＤＡＰサーバ情報設定の一実施例のシーケンス図である。このシーケンス図は、ＬＤＡＰサーバ情報の設定時に、処理時間が基準時間より掛かる属性およびその属性の処理時間を提示して、ユーザに確認させるものである。

まず、ユーザは融合機１の操作パネル８０に図１７のＬＤＡＰ登録／変更／削除画面１６００を表示させる。図１７は、実施例３における一例の画面遷移図である。ユーザはＬＤＡＰサーバ情報の設定を行うＬＤＡＰサーバ１０３を、ＬＤＡＰ登録／変更／削除画面１６００から選択する。なお、未登録のＬＤＡＰサーバ１０３のＬＤＡＰサーバ情報を設定する場合、「※未登録※」ボタンを選択する。

ＬＤＡＰサーバ１０３が選択されると、操作パネル８０には図１７のＬＤＡＰサーバ情報設定画面１７００が表示される。ユーザは、取得属性をＬＤＡＰサーバ情報設定画面１７００に設定する。ＬＤＡＰサーバ情報設定画面１７００に属性が設定されると、ＵＣＳクライアント２００はステップＳ３００に進み、ＬＤＡＰサーバ情報設定要求をＵＣＳ３７に対して行う。なお、ＵＣＳクライアント２００はＬＤＡＰサーバ情報設定要求をＵＣＳ６７に対して行うとき、サーバ名称，ホスト名（ＩＰアドレス）又はポート番号などの検索対象ＬＤＡＰサーバ情報、検索フィルタ，取得属性，検索開始位置，基準時間又は基準時間のチェック有無などの検索情報をＬＤＡＰサーバ情報設定要求と共にＵＣＳ３７に供給する。

ステップＳ３０１に進み、ＵＣＳ３７は検索条件に含まれる基準時間のチェック有無を確認し、基準時間のチェックを行うか否かを判定する。基準時間のチェックを行うと判定すると（Ｓ３０２においてＹＥＳ）、ＵＣＳ３７はステップＳ３０２に進む。なお、基準時間のチェックを行わないと判定すると（Ｓ３０２においてＮＯ）、ＵＣＳ３７はステップＳ３０７に進む。

ステップＳ３０２では、ＵＣＳ３７が、設定する取得属性に基準時間より処理時間の掛かったことのある属性が含まれているか否かを判定する。設定する取得属性に基準時間より処理時間の掛かったことのある属性が含まれていると判定すると（Ｓ３０２においてＹＥＳ）、ＵＣＳ３７はステップＳ３０３に進み、設定する取得属性に基準時間より処理時間の掛かったことのある属性が含まれていることを表す失敗をＵＣＳクライアント２００に通知する。なお、設定する取得属性に基準時間より処理時間の掛かったことのある属性が含まれていないと判定すると（Ｓ３０２においてＮＯ）、ＵＣＳ３７はステップＳ３０７に進む。

ステップＳ３０４では、ＵＣＳクライアント２００が、ＵＣＳ３７に対して基準時間よりも処理時間の掛かった属性の問い合わせを行う。ステップＳ３０５に進み、ＵＣＳ３７は基準時間よりも処理時間の掛かったことのある属性と、その属性の処理時間とをＵＣＳクライアント２００に供給する。

ステップＳ３０６に進み、ＵＣＳクライアント２００は図１７のような注意画面１８００を操作パネル８０に表示する。注意画面１８００は、基準時間よりも処理時間の掛かったことのある属性と、その属性の１件あたりの処理時間とが含まれている。

ユーザは注意画面１８００の「変更しない」ボタン１８０２を押下することで、基準時間よりも処理時間の掛かったことのある属性を設定しない。なお、ユーザは注意画面１８００の「変更する」ボタン１８０１を押下することで、基準時間よりも処理時間の掛かったことのある属性であっても、取得する属性として設定できる。注意画面１８００の「変更しない」ボタン１８０２が押下されると、ＵＣＳクライアント２００は再びＬＤＡＰ登録／変更／削除画面１６００を操作パネル８０に表示する。

ステップＳ３０７では、ＵＣＳ３７が、設定する取得属性に基準時間より処理時間の掛かったことのある属性が含まれていないことを表す成功をＵＣＳクライアント２００に通知する。設定する取得属性に基準時間より処理時間の掛かったことのある属性が含まれていない場合、ＵＣＳクライアント２００は図１７のような注意画面１８００を操作パネル８０に表示せず、ＬＤＡＰ登録／変更／削除画面１６００を表示する。

ユーザは、ＬＤＡＰサーバ情報の設定時に、処理時間が基準時間より掛かったことのある属性を確認した上で、その属性を設定することができる。

本発明の実施例４は、ＬＤＡＰサーバ１０３ごとに属性の処理時間を格納しておき、取得する属性の設定時に、処理時間が基準時間より掛かる属性およびその属性の処理時間を提示してユーザに確認させるものである。なお、ＵＣＳ３７の構成は図９の構成と同様である。

図１８は、本発明による属性設定の一実施例のシーケンス図である。このシーケンス図は、属性の設定時に、処理時間が基準時間より掛かる属性およびその属性の処理時間を提示して、ユーザに確認させるものである。

まず、ユーザは融合機１の操作パネル８０に図１７のＬＤＡＰサーバ情報設定画面１７００を表示させる。ユーザは、取得する属性をＬＤＡＰサーバ情報設定画面１７００に設定する。ＬＤＡＰサーバ情報設定画面１７００に属性が設定されると、ＵＣＳクライアント２００はステップＳ４００に進み、属性問い合わせをＵＣＳ３７に対して行う。ＵＣＳクライアント２００は属性問い合わせをＵＣＳ６７に対して行うとき、ＬＤＡＰサーバＩＤ，属性名および基準時間を属性問い合わせと共にＵＣＳ３７に供給する。

ステップＳ４０１では、ＵＣＳ３７が、基準時間と処理時間情報とを比較する。ステップＳ４０２に進み、ＵＣＳ３７はステップＳ４０１の比較結果をＵＣＳクライアント２００に送信する。なお、比較結果には基準時間オーバー，基準時間内，処理時間の平均および最大が含まれている。

ステップＳ４０３に進み、ＵＣＳクライアント２００は設定する取得属性に基準時間より処理時間の掛かったことのある基準時間オーバーの属性が含まれているか否かを判定する。設定する取得属性に基準時間より処理時間の掛かったことのある基準時間オーバーの属性が含まれていると判定すると（Ｓ４０３においてＹＥＳ）、ＵＣＳクライアント２００は図１７のような注意画面１８００を操作パネル８０に表示する。

ユーザは注意画面１８００の「変更しない」ボタン１８０２を押下することで、基準時間よりも処理時間の掛かったことのある属性を設定しない。また、ユーザは注意画面１８００の「変更する」ボタン１８０１を押下することで、基準時間よりも処理時間の掛かったことのある属性であっても、取得する属性として設定できる。注意画面１８００の「変更する」ボタン１８０１又は「変更しない」ボタン１８０２が押下されると、ＵＣＳクライアント２００はステップＳ４０５に進む。なお、設定する取得属性に基準時間より処理時間の掛かったことのある基準時間オーバーの属性が含まれていないと判定すると（Ｓ４０３においてＹＥＳ）、ＵＣＳクライアント２００はステップＳ４０５に進む。

ステップＳ４０５では、ＵＣＳクライアント２００が、属性問い合わせを行う属性があるか否かを判定する。属性問い合わせを行う属性があると判定すると（Ｓ４０５においてＹＥＳ）、ＵＣＳクライアント２００はステップＳ４００に戻る。なお、属性問い合わせを行う属性がないと判定すると（Ｓ４０５においてＮＯ）、ＵＣＳクライアント２００はステップＳ４０６に進み、ＬＤＡＰサーバ情報設定要求をＵＣＳ３７に対して行う。ＵＣＳ３７はステップＳ４０７に進み、ＬＤＡＰサーバ情報設定要求に対する処理の成功又は失敗をＵＣＳクライアント２００に通知する。

ユーザは、属性の設定時に、処理時間が基準時間より掛かったことのある属性を確認した上で、その属性を設定することができる。

本発明の実施例５は、ＬＤＡＰサーバ情報の設定時に、プレ検索（前検索）を行って処理時間が基準時間より掛かる属性およびその属性の処理時間を提示してユーザに確認させるものである。なお、ＵＣＳ３７の構成は図９の構成と同様である。

図１９は、本発明によるＬＤＡＰサーバ情報設定の一実施例のシーケンス図である。このシーケンス図は、ＬＤＡＰサーバ情報の設定時にプレ検索を行い、処理時間が基準時間より掛かる属性およびその属性の処理時間を提示してユーザに確認させるものである。

まず、ユーザは融合機１の操作パネル８０に図１７のＬＤＡＰサーバ情報設定画面１７００を表示させる。ユーザは、取得する属性をＬＤＡＰサーバ情報設定画面１７００に設定する。ＬＤＡＰサーバ情報設定画面１７００に属性が設定されると、ＵＣＳクライアント２００はステップＳ５００に進み、属性問い合わせをＵＣＳ３７に対して行う。ＵＣＳクライアント２００は属性問い合わせをＵＣＳ６７に対して行うとき、サーバ名称，ホスト名（ＩＰアドレス）又はポート番号などの検索対象ＬＤＡＰサーバ情報と、検索フィルタ，取得属性，検索開始位置，基準時間などの検索情報を属性問い合わせと共にＵＣＳ３７に供給する。

ステップＳ５０１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、属性問い合わせに応じた検索要求を行う。ステップＳ５０２に進み、ＵＣＳ３７はステップＳ５０１の検索要求に対する検索結果を受信する。

ステップＳ５０３に進み、タイマ機能２２４はタイマを開始する。ステップＳ５０４に進み、ＵＣＳ３７は検索結果を図１０のようなフローチャートの手順で融合機１用のエントリのデータ構造に変換し、ＬＤＡＰユーザ情報とする。ステップＳ５０５に進み、ＵＣＳ３７はタイマ機能２２４のタイマを終了する。

ステップＳ５０６に進み、ＵＣＳ３７は属性問い合わせに応じた検索要求の属性ごとの処理時間の平均値を算出する。ステップＳ５０７に進み、ＵＣＳ３７はステップＳ５０６で算出した属性ごとの処理時間の平均値と基準時間とを比較する。そして、ステップＳ５０８に進み、ＵＣＳ３７はステップＳ５０７の比較結果をＵＣＳクライアント２００に送信する。なお、ステップＳ５０９〜Ｓ５１３の処理は図１８のステップＳ４０３〜Ｓ４０７と同様であり、説明を省略する。

ユーザは、ＬＤＡＰサーバ情報の設定時に取得属性のプレ検索を行い、処理時間が基準時間より掛かる属性およびその属性の処理時間を確認した上で、その属性を設定することができる。

上記の実施例１〜５では属性の処理時間を提示して、その属性を取得属性として設定するかをユーザに確認させていたが、処理時間に代えてデータサイズを提示して、その属性を取得属性として設定するかをユーザに確認させてもよい。そこで、実施例６では実施例５の処理時間に代えてデータサイズを利用する例を説明する。

図２０は、本発明によるＬＤＡＰサーバ情報設定の一実施例のシーケンス図である。このシーケンス図は、ＬＤＡＰサーバ情報の設定時に、プレ検索を行ってデータサイズが基準データサイズより大きい属性およびその属性のデータサイズを提示してユーザに確認させるものである。実施例６を実現するためのＵＣＳ３７は、例えば図２１のように構成される。

図２１は、本発明による検索機能を実現するＵＣＳのソフトウェア構成について説明するための一例の構成図である。図２１の構成図は、データサイズ計数機能２２５を有していることが図４の構成図と異なっている。データサイズ計数機能２２５は、エントリを構成する属性ごとにデータサイズを計数する。図２１のデータサイズ計数機能２２５以外の構成は、図４の構成と同様であるため、説明を省略する。

まず、ユーザは融合機１の操作パネル８０に図１７のＬＤＡＰサーバ情報設定画面１７００を表示させる。ユーザは、取得する属性をＬＤＡＰサーバ情報設定画面１７００に設定する。ＬＤＡＰサーバ情報設定画面１７００に属性が設定されると、ＵＣＳクライアント２００はステップＳ６００に進み、データサイズ情報取得要求をＵＣＳ３７に対して行う。ＵＣＳクライアント２００はデータサイズ情報取得要求をＵＣＳ６７に対して行うとき、サーバ名称，ホスト名（ＩＰアドレス），ポート番号，ＳＳＬ設定などの検索対象ＬＤＡＰサーバ情報と、検索フィルタ，取得属性，検索開始位置，基準データサイズなどの検索情報をデータサイズ情報取得要求と共にＵＣＳ３７に供給する。

ステップＳ６０１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、データサイズ情報取得要求に応じた検索要求を行う。なお、検索要求にはＭＡＸエントリ数、取得属性、検索フィルタ、タイムアウト等が検索条件として含まれている。ステップＳ６０２に進み、ＵＣＳ３７はステップＳ６０１の検索要求に対する検索結果を受信する。

ステップＳ６０３に進み、データサイズ計数機能２２５はデータサイズの計数を開始する。ステップＳ６０４に進み、ＵＣＳ３７は検索結果を図１０のようなフローチャートの手順で融合機１用のエントリのデータ構造に変換し、ＬＤＡＰユーザ情報とする。ステップＳ６０５に進み、ＵＣＳ３７はデータサイズの計数を開始する。

ステップＳ６０６に進み、ＵＣＳ３７はデータサイズ情報取得要求に応じた検索要求の属性ごとのデータサイズの平均値を算出する。ステップＳ６０７に進み、ＵＣＳ３７はステップＳ６０６で算出した属性ごとのデータサイズの平均値と基準データサイズとを比較する。そして、ステップＳ６０８に進み、ＵＣＳ３７はデータサイズ情報のほしい属性があるか否かを判定する。データサイズ情報のほしい属性があると判定すると（Ｓ６０８においてＹＥＳ）、ＵＣＳ３７はステップＳ６０１に戻る。

なお、データサイズ情報のほしい属性がないと判定すると（Ｓ６０８においてＮＯ）、ＵＣＳ３７はステップＳ６０９に進み、データサイズ情報２５０をＵＣＳクライアント２００に供給する。ステップＳ６１０に進み、ＵＣＳクライアント２００は図２２のような画面２０００，２１００を操作パネル８０に表示する。図２２は、実施例６における一例の画面遷移図である。

図１２の画面２０００，２１００は、属性と、属性ごとのデータサイズの平均値および最大値とが含まれている。ユーザは画面２０００，２１００の属性ボタン２００１，２１０１を押下して属性ボタン２００１，２１０１の非反転表示または反転表示を切り替えることで、取得する属性または取得しない属性を選択できる。

ステップＳ６１１に進み、ＵＣＳクライアント２００は取得する属性または取得しない属性の変更があったか否かを判定する。取得する属性または取得しない属性の変更があったと判定すると（Ｓ６１１においてＹＥＳ）、ＵＣＳクライアント２００はステップＳ６００に戻る。

取得する属性または取得しない属性の変更がなかったと判定すると（Ｓ６１１においてＮＯ）、ＵＣＳクライアント２００はステップＳ６１２に進み、ＬＤＡＰサーバ情報設定要求をＵＣＳ３７に対して行う。そして、ＵＣＳ３７はステップＳ６１３に進み、ＬＤＡＰサーバ情報設定要求に対する処理の成功または失敗をＵＣＳクライアント２００に通知する。

ユーザは、ＬＤＡＰサーバ情報の設定時に取得属性のプレ検索を行い、データサイズが基準データサイズより大きい属性およびその属性のデータサイズを確認した上で、その属性を設定することができる。

上記の実施例１〜６ではデータサイズが大きい等の理由により処理時間の掛かる属性をＬＤＡＰサーバ１０３から取得しないように設定することで処理時間を短くするようにしていた。そこで、実施例７ではＬＤＡＰサーバ１０３から取得する属性の順番を変更すると共に、ＬＤＡＰサーバ１０３に対する検索要求を分けて行うことで処理時間を短くしている。

図２３は、本発明によるＬＤＡＰ検索の第７実施例のシーケンス図である。このシーケンス図は、ＬＤＡＰサーバから属性を取得する順番を変更すると共に、ＬＤＡＰサーバ１０３に対する検索要求を分けて行うことで、操作パネル８０にＬＤＡＰ検索結果画面が表示されるまでの時間を短縮する。

ステップＳ７００に進み、ＵＣＳクライアント２００はＵＣＳ３７に対してＬＤＡＰ検索要求を行う。ステップＳ７０１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、検索情報に応じた検索要求を行う。なお、ステップＳ７０１で検索対象となる取得属性は、ＬＤＡＰ検索結果画面に必要な属性と、所定のデータサイズ以下の属性である。ステップＳ７０２に進み、ＵＣＳ３７はステップＳ７０１の検索要求に対する検索結果を受信する。

ステップＳ７０３に進み、ＵＣＳ３７は検索結果を図１０のようなフローチャートの手順で融合機１用のエントリのデータ構造に変換したあと、そのエントリのエントリＩＤを検索結果としてＵＣＳクライアント２００に供給する。ステップＳ７０４に進み、ＵＣＳクライアント２００はＵＣＳ３７に対してエントリ情報取得要求を行う。ステップＳ７０５に進み、ＵＣＳクライアント２００はＵＣＳ３７からエントリＩＤに対応するエントリ情報を取得する。ここでＵＣＳクライアント２００が取得する属性は、ＬＤＡＰ検索結果画面に必要な属性と、所定のデータサイズ以下の属性である。ＵＣＳクライアント２００はステップＳ７０５で取得した属性を用いて操作パネル８０にＬＤＡＰ検索結果画面を表示する。

ステップＳ７０６に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、ＬＤＡＰ検索要求に対する残りの検索要求を行う。なお、ステップＳ７０６で検索対象となる取得属性は、所定のデータサイズ以上の属性である。ステップＳ７０７に進み、ＵＣＳ３７はステップＳ７０６の検索要求に対する検索結果を受信する。

図２３のＬＤＡＰ検索では、ＬＤＡＰ検索結果画面に必要な属性と、処理時間の短い属性とを最初に取得してＬＤＡＰ検索結果画面を表示する。そして、残りの属性はＬＤＡＰ検索結果画面を表示しつつ処理時間の長い属性を取得している。図２４は、最初に取得する検索結果と後から取得する検索結果との違いを説明するためのデータ構成図である。

例えば図２４のデータ構成図で表されたＬＤＡＰユーザ情報は、エントリＩＤにより識別されるエントリ情報，メール情報，ＦＡＸ情報，所属情報がステップＳ７０２の検索結果から取得される。また、付加情報はステップＳ７０７の検索結果から取得される。

ユーザは、ＬＤＡＰサーバ１０３から取得する属性の順番を変更すると共に、ＬＤＡＰサーバ１０３に対する検索要求を分けて行うことで、検索結果画面を表示するまでの時間を短くすることができる。

本発明の実施例８では、ＬＤＡＰサーバ１０３から取得する属性の順番を変更すると共に、残りの属性を要求されてから取得するものである。図２５は、本発明によるＬＤＡＰ検索の第８実施例のシーケンス図である。このシーケンス図は、ＬＤＡＰサーバから属性を取得する順番を変更すると共に、残りの属性を要求されてから取得することで、操作パネル８０にＬＤＡＰ検索結果画面が表示されるまでの時間を短縮する。

ステップＳ８００〜Ｓ８０５の処理は、図２３のステップＳ７００〜Ｓ７０５の処理と同様であり、説明を省略する。ステップＳ８０６では、ＵＣＳクライアント２００が、ＵＣＳ３７に対して詳細データ取得要求を行う。即ち、ＵＣＳ３７はＵＣＳクライアント２００から詳細データ取得要求があるまで残りの属性をＬＤＡＰ検索しない。

詳細データ取得要求が供給されると、ＵＣＳ３７はステップＳ８０７に進み、ステップＳ８００のＬＤＡＰ検索要求に対する残りの検索要求を行う。なお、ステップＳ８０７で検索対象となる取得属性は、所定のデータサイズ以上の属性である。ステップＳ８０８に進み、ＵＣＳ３７はステップＳ８０７の検索要求に対する検索結果を受信する。ステップＳ８０９に進み、ＵＣＳ３７はステップＳ８０８で受信した検索結果を図１０のようなフローチャートの手順で融合機１用のエントリのデータ構造に変換したあと、詳細データとしてＵＣＳクライアント２００に供給する。

図２５のＬＤＡＰ検索では、ＬＤＡＰ検索結果画面に必要な属性と、処理時間の短い属性とを最初に取得してＬＤＡＰ検索結果画面を表示する。そして、残りの属性はＵＣＳクライアント２００から要求されてから取得する。従って、無駄な属性を取得することを避けることができる。

ユーザは、ＬＤＡＰサーバ１０３から取得する属性の順番を変更すると共に、ＬＤＡＰサーバ１０３に対する検索要求を分けて行うことで、検索結果画面を表示するまでの時間を短くすることができる。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求のの範囲から逸脱することなく、種々の変形や変更が可能である。

本発明による融合機のソフトウェア構成について説明するための一実施例の構成図である。 本発明による融合機のハードウェア構成について説明するための一実施例の構成図である。 ＬＤＡＰサーバ情報の取得要求，追加要求，変更要求，削除要求について説明するための図である。 検索機能を実現するＵＣＳのソフトウェア構成について説明するための一例の構成図である。 ＬＤＡＰ検索の一例のシーケンス図である。 検索結果の一例のデータ構造図である。 ＬＤＡＰユーザ情報の一例のデータ構造図である。 検索結果を融合機用のエントリのデータ構造に１件ずつ変換する処理の一例のフローチャートである。 本発明による検索機能を実現するＵＣＳのソフトウェア構成について説明するための一例の構成図である。 検索結果を融合機用のエントリのデータ構造に１件ずつ変換するとき、エントリを構成する属性ごとの処理時間を計測する処理の一例のフローチャートである。 本発明によるＬＤＡＰ検索の第１実施例のシーケンス図である。 処理時間確認画面の一例のイメージ図である。 ＬＤＡＰ検索結果画面の一例のイメージ図である。 本発明によるＬＤＡＰ検索の第２実施例のシーケンス図である。 実施例２における一例の画面遷移図である。 本発明によるＬＤＡＰサーバ情報設定の一実施例のシーケンス図である。 実施例３における一例の画面遷移図である。 本発明による属性設定の一実施例のシーケンス図である。 本発明によるＬＤＡＰサーバ情報設定の一実施例のシーケンス図である。 本発明によるＬＤＡＰサーバ情報設定の一実施例のシーケンス図である。 本発明による検索機能を実現するＵＣＳのソフトウェア構成について説明するための一例の構成図である。 実施例６における一例の画面遷移図である。 本発明によるＬＤＡＰ検索の第７実施例のシーケンス図である。 最初に取得する検索結果と後から取得する検索結果との違いを説明するためのデータ構成図である。 本発明によるＬＤＡＰ検索の第８実施例のシーケンス図である。

符号の説明

１ 融合機
２ ソフトウェア群
３ 融合機起動部
４ ハードウェア資源
５ アプリケーション層
６ プラットフォーム
９ コントロールサービス層
１０ ハンドラ層
１１ プロッタ
１２ スキャナ
１３ ハードウェアリソース
２１ プリンタアプリ
２２ コピーアプリ
２３ ファックスアプリ
２４ スキャナアプリ
２５ ネットファイルアプリ
３１ ネットワークコントロールサービス（ＮＣＳ）
３２ デリバリーコントロールサービス（ＤＣＳ）
３３ オペレーションパネルコントロールサービス（ＯＣＳ）
３４ ファックスコントロールサービス（ＦＣＳ）
３５ エンジンコントロールサービス（ＥＣＳ）
３６ メモリコントロールサービス（ＭＣＳ）
３７ ユーザインフォメーションコントロールサービス（ＵＣＳ）
３８ システムコントロールサービス（ＳＣＳ）
３９ システムリソースマネージャ（ＳＲＭ）
４０ ファックスコントロールユニットハンドラ（ＦＣＵＨ）
４１ イメージメモリハンドラ（ＩＭＨ）
５３ アプリケーションプログラムインターフェース（ＡＰＩ）
５４ エンジンＩ／Ｆ
６０ コントローラ
６１ ＣＰＵ
６２ システムメモリ
６３ ノースブリッジ（ＮＢ）
６４ サウスブリッジ（ＳＢ）
６５ ＡＧＰ（Accelerated Graphics Port）
６６ ＡＳＩＣ
６７ ローカルメモリ
６８ ハードディスク装置（ＨＤＤ）
６９ ネットワークインターフェースコントローラ（ＮＩＣ）
７０ ＵＳＢ Ｉ／Ｆ
７１ ＩＥＥＥ１３９４ Ｉ／Ｆ
７２ セントロニクス Ｉ／Ｆ
８０ 操作パネル
８１ ファックスコントロールユニット（ＦＣＵ）
８２ エンジン部
８３ ＰＣＩバス
１０３ ＬＤＡＰサーバ
２００ ＵＣＳクライアント
２１１ ＡＰＩ層
２１２ 検索機能
２１３ データベース制御機能
２２２ ＬＤＡＰライブラリ
２２３ エンコードライブラリ
２３０ 記憶部
２２４ タイマ機能
２２５ データサイズ計数機能

Claims (20)

1. 外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索可能な情報処理装置であって、
   前記データを構成する１つ以上の属性のうち前記情報格納サーバから取得する属性を取得属性として設定可能であり、検索結果として前記情報格納サーバから取得するデータが前記取得属性に応じた属性で構成されることを特徴とする情報処理装置。
2. 前記検索結果として前記情報格納サーバから取得したデータのうち、処理時間および処理時間に影響する情報のうちの少なくとも一方をユーザに提示し、前記情報格納サーバから取得しない属性をユーザに設定させる機能を有することを特徴とする請求項１記載の情報処理装置。
3. 前記検索結果として前記情報格納サーバからデータを取得したあと、そのデータに含まれる取得属性ごとに処理時間および処理時間に影響する情報のうちの少なくとも一方を提示し、前記情報格納サーバから取得しない属性をユーザに設定させる機能を有することを特徴とする請求項２記載の情報処理装置。
4. 前記検索結果として前記情報格納サーバからデータを取得している途中で、そのデータに含まれる一つの取得属性の処理時間および処理時間に影響する情報のうちの少なくとも一方が閾値を超えると、前記取得属性の処理時間および処理時間に影響する情報のうちの少なくとも一方をユーザに提示し、その取得属性を前記情報格納サーバから取得しない属性とするか否かをユーザに設定させる機能を有することを特徴とする請求項２記載の情報処理装置。
5. 前記検索結果として前記情報サーバから以前に取得したデータの取得属性ごとに処理時間および処理時間に影響する情報を保持しておき、前記処理時間および処理時間に影響する情報のうちの少なくとも一方が閾値を超える取得属性を前記情報格納サーバ情報登録時にユーザにより設定されたとき、注意画面を表示する機能を有することを特徴とする請求項２記載の情報処理装置。
6. 前記検索結果として前記情報サーバから以前に取得したデータの取得属性ごとに処理時間および処理時間に影響する情報を保持しておき、前記処理時間および処理時間に影響する情報のうちの少なくとも一方が閾値を超える取得属性を前記取得属性設定時に設定されたとき、注意画面を表示する機能を有することを特徴とする請求項２記載の情報処理装置。
7. 前記情報格納サーバ情報登録時に取得属性が設定されると、設定された取得属性で構成されるデータの前検索を行い、前記処理時間および処理時間に影響する情報のうちの少なくとも一方が閾値を超える取得属性があれば注意画面を表示する機能を有することを特徴とする請求項２記載の情報処理装置。
8. 前記処理時間に影響する情報は、データサイズであることを特徴とする請求項２乃至７何れか一項記載の情報処理装置。
9. 前記処理時間は、１件あたりの平均処理時間，１件あたりの最大処理時間および所定件数の合計処理時間のうちの少なくとも１つを含むことを特徴とする請求項２乃至８何れか一項記載の情報処理装置。
10. 前記処理時間に影響する情報は、１件あたりのデータサイズ，１件あたりの最大データサイズおよび所定件数の合計データサイズのうちの少なくとも１つを含むことを特徴とする請求項２乃至８何れか一項記載の情報処理装置。
11. 前記注意画面は、前記処理時間および処理時間に影響する情報のうちの少なくとも一方が閾値を超える取得属性と、その取得属性の処理時間および処理時間に影響する情報のうちの少なくとも一方とを含むことを特徴とする請求項４乃至７何れか一項記載の情報処理装置。
12. 前記注意画面は、前記処理時間および処理時間に影響する情報のうちの少なくとも一方が閾値を超える取得属性を、前記情報格納サーバから取得しない属性としてユーザに設定させる設定手段が設けられていることを特徴とする請求項１１記載の情報処理装置。
13. 前記データを構成する１つ以上の属性のうち、閾値より処理時間が短い又はデータサイズが小さい属性を検索した検索結果を最初に取得し、その後、取得していない属性を検索結果として取得することを特徴とする請求項１記載の情報処理装置。
14. 前記データを構成する１つ以上の属性のうち、閾値より処理時間が短い又はデータサイズが小さい属性を検索した検索結果を最初に取得し、その後、取得していない属性の取得要求があると、取得していない属性を検索結果として取得することを特徴とする請求項１記載の情報処理装置。
15. 前記情報格納サーバから取得しない属性の設定は、その検索時のみ有効であることを特徴とする請求項２乃至１０何れか一項記載の情報処理装置。
16. 前記情報格納サーバから取得しない属性の設定は、以降の検索時でも有効であることを特徴とする請求項２乃至１０何れか一項記載の情報処理装置。
17. 前記情報格納サーバから取得しない属性の設定は、その検索時のみ有効または以降の検索時でも有効のうちの何れかをユーザに選択させることを特徴とする請求項２乃至１０何れか一項記載の情報処理装置。
18. 前記情報格納サーバから取得しない属性の設定は、その検索時のみ有効または以降の検索時でも有効のうちの何れかをユーザに選択させたあと、その検索時のみ有効または以降の検索時でも有効のうちの何れかを再選択させることを特徴とする請求項１７記載の情報処理装置。
19. 外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索可能な情報処理装置のデータ検索方法であって、
    前記データを構成する１つ以上の属性のうち前記情報格納サーバから取得する属性を取得属性として設定させる段階と、
    前記取得属性に応じた属性で構成されるデータを含む検索結果を前記情報格納サーバから取得する段階と
    を有することを特徴とするデータ検索方法。
20. コンピュータに、外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索させるデータ検索プログラムであって、
    前記データを構成する１つ以上の属性のうち前記情報格納サーバから取得する属性を取得属性として設定させる手順と、
    前記取得属性に応じた属性で構成されるデータを含む検索結果を前記情報格納サーバから取得する手順と
    を実行させるためのデータ検索プログラム。

Images