(57)【要約】【課題】  １つ以上の属性で構成されるデータを情報格納サーバから取得するときに、処理時間を容易に短くできる情報処理装置、データ検索方法およびデータ検索プログラムを提供することを目的とする。【解決手段】  外部に設置されている情報格納サーバ１０３から１つ以上の属性で構成されるデータを検索可能な情報処理装置１であって、１つ以上の属性のデータ種別を設定可能であり、情報格納サーバ１０３から取得する属性を取得属性として設定するときに、属性毎のデータ種別をユーザに提示することにより上記課題を解決する。【選択図】  図３
2005196560.tif 000002
【特許請求の範囲】
【請求項１】
外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索可能な情報処理装置であって、
前記１つ以上の属性のデータ種別を設定可能であり、前記情報格納サーバから取得する属性を取得属性として設定するときに、前記属性毎のデータ種別をユーザに提示することを特徴とする情報処理装置。
【請求項２】
前記１つ以上の属性を設定するとき、前記属性毎のデータ種別をユーザに設定させる機能を有することを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記１つ以上の属性の前検索を行い、その検索結果として前記情報格納サーバから取得した前記属性の内容に応じて前記属性のデータ種別を判定して設定する機能を有することを特徴とする請求項１記載の情報処理装置。
【請求項４】
前記情報格納サーバから取得した前記属性に所定の制御文字が含まれているときに前記属性のデータ種別をバイナリデータと判定することを特徴とする請求項３記載の情報処理装置。
【請求項５】
前記情報格納サーバから取得した前記属性のヘッダ部分にバイナリデータを表す記述が含まれているときに前記属性のデータ種別をバイナリデータと判定することを特徴とする請求項３記載の情報処理装置。
【請求項６】
前記情報格納サーバから取得した前記属性を操作パネルに表示し、前記属性毎のデータ種別をユーザに設定させることを特徴とする請求項３記載の情報処理装置。
【請求項７】
前記１つ以上の属性のうちユーザが設定する可能性の高い属性と、その属性のデータ種別との関係が予め登録されており、前記登録されている関係を用いて前記属性のデータ種別を判定して設定する機能を有することを特徴とする請求項１記載の情報処理装置。
【請求項８】
前記１つ以上の属性と、その属性のデータ種別として以前に設定されたデータ種別との関係を登録しておき、前記登録されている関係を用いて前記属性のデータ種別を判定して設定する機能を有することを特徴とする請求項１記載の情報処理装置。
【請求項９】
前記１つ以上の属性の検索を行うとき、その検索結果として前記情報格納サーバから前記属性を取得する取得順序を、前記属性のデータ種別に応じて変更する機能を有することを特徴とする請求項１記載の情報処理装置。
【請求項１０】
前記１つ以上の属性のうち、所定のデータ種別の属性を最初に取得し、その後、取得していないデータ種別の属性を取得することを特徴とする請求項９記載の情報処理装置。
【請求項１１】
前記１つ以上の属性のうち、所定のデータ種別の属性を最初に取得し、その後、取得していないデータ種別の属性の取得要求があると、取得していないデータ種別の属性を取得することを特徴とする請求項９記載の情報処理装置。
【請求項１２】
前記１つ以上の属性の検索を行うとき、その検索結果として前記情報格納サーバから前記属性を取得する取得順序をユーザに設定させることを特徴とする請求項１記載の情報処理装置。
【請求項１３】
前記情報格納サーバから取得した属性を、表示構成に基づき操作パネルに表示する機能を有することを特徴とする請求項１記載の情報処理装置。
【請求項１４】
前記表示構成を表示パネルに表示し、前記表示構成をユーザに設定させることを特徴とする請求項１３記載の情報処理装置。
【請求項１５】
前記表示構成を、検索条件として入力された属性に応じて設定することを特徴とする請求項１３記載の情報処理装置。
【請求項１６】
前記表示構成を、検索条件として入力される頻度の高い属性に応じて設定することを特徴とする請求項１３記載の情報処理装置。
【請求項１７】
前記表示構成を、検索要求を行ったアプリケーションに応じて設定することを特徴とする請求項１３記載の情報処理装置。
【請求項１８】
前記表示構成を、検索の結果に基づき、ヒット数の多い属性に応じて設定することを特徴とする請求項１３記載の情報処理装置。
【請求項１９】
外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索可能な情報処理装置のデータ検索方法であって、
前記１つ以上の属性のデータ種別をユーザに提示する段階と、
前記情報格納サーバから取得する属性を取得属性としてユーザに設定させる段階と
を有することを特徴とするデータ検索方法。
【請求項２０】
コンピュータに、外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索させるデータ検索プログラムであって、
前記１つ以上の属性のデータ種別をユーザに提示する手順と、
前記情報格納サーバから取得する属性を取得属性としてユーザに設定させる手順と
を実行させるためのデータ検索プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、データ検索方法およびデータ検索プログラムに係り、特に外部に設置されている情報格納サーバから１つ以上の属性で構成されているデータを検索する情報処理装置、データ検索方法およびデータ検索プログラムに関する。
【背景技術】
【０００２】
近年、１つ以上の情報処理装置（以下、クライアントという）と情報格納サーバとがネットワークを介して接続されたシステムにおいて、情報格納サーバに格納されている１つ以上の属性で構成されるデータをクライアントが取得することがよく行われている。例えば特許文献１には、クライアント端末とデータサーバとがネットワークを介して接続されたデータ検索システムにおいて、クライアントがデータサーバからデータを検索することが記載されている。
【０００３】
情報格納サーバは、例えばＬＤＡＰ（Lightweight Directory Access Protocol）に準拠するように構成されている。以下、ＬＤＡＰに準拠した情報処理サーバをＬＤＡＰサーバと呼ぶ。
【０００４】
ＬＤＡＰサーバで管理されているデータには、テキストデータやバイナリデータが含まれている。また、ＬＤＡＰサーバで管理されているデータは１つ以上の属性で構成されている。データを構成する属性は、ＲＦＣ（Request For Comments）で規定されているものやＬＤＡＰサーバで独自に定義しているものも含まれる。また、ＬＤＡＰサーバで管理されているデータは、データサイズもＬＤＡＰサーバによってバラツキがある。
【０００５】
ＲＦＣ２２５１で規定されたＬＤＡＰバージョン３の仕様を実装したＬＤＡＰサーバであれば、ＬＤＡＰサーバで管理している属性の説明（以下、スキーマという）のスキーマ一覧をクライアントが取得することができる。
【０００６】
クライアントの一例としての画像処理装置は、プリンタ，コピー，ファクシミリおよびスキャナなどの各装置の機能を１つの筐体内に収納している。画像処理装置は、１つの筐体内に表示部，印刷部および撮像部などを設けると共に、プリンタ，コピー，ファクシミリおよびスキャナにそれぞれ対応する４種類のソフトウェアを設け、そのソフトウェアを切り替えることより、プリンタ，コピー，ファクシミリおよびスキャナとして動作させるものである。例えば特許文献２には、クライアントの一例としての画像処理装置が記載されている。
【特許文献１】特開２００３−１０８５５８号公報
【特許文献２】特開２００２−８４３８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、クライアントはＬＤＡＰサーバのバージョンや実装形式によっては、ＬＤＡＰサーバのスキーマ一覧を必ずしも取得できるとは限らない。また、ＬＤＡＰサーバからスキーマ一覧を取得できたとしても、そのスキーマ一覧にデータを構成している属性やデータサイズが正確に規定されていないこともある。この場合、クライアントはＬＤＡＰサーバからデータを取得するまでの処理時間やデータサイズがどの程度であるかを予測することができない。
【０００８】
したがって、クライアントはＬＤＡＰサーバからデータを検索する場合に、その検索結果としてＬＤＡＰサーバから取得したデータを処理して表示するまでの処理時間が長く掛かってしまう場合があるという問題が生じていた。
【０００９】
また、クライアントは取得したデータがバイナリデータである場合に、テキストデータに対して行うエンコード処理を無駄に行うという問題が生じていた。ＬＤＡＰサーバから取得したデータのデータ種別（例えば、バイナリデータ，テキストデータなど）を予測する方法としては、例えばＲＦＣで規定されているサブスキーマエントリを取得して予測する方法、ＲＦＣで規定されている標準スキーマに従う方法などがある。
【００１０】
しかし、ＲＦＣで規定されていても、クライアントは上記のようにサブスキーマエントリを必ずしも取得できるとは限らない。サブスキーマエントリを取得してデータ種別を予測する方法は、サブスキーマエントリを取得できなけばデータ種別を予測することができないという問題があった。
【００１１】
また、ＲＦＣで規定されていても、ＬＤＡＰサーバは上記のようにＲＦＣの規定に沿った実装をしているとは限らない。また、ＬＤＡＰサーバは独自の属性を作成することができる。ＲＦＣで規定されている標準スキーマに従う方法は、ＬＤＡＰサーバがＲＦＣの規定に沿った実装をしていない場合や独自の属性を作成している場合に、データ種別を予測することができないという問題があった。
【００１２】
本発明は、上記の点に鑑みなされたもので、１つ以上の属性で構成されるデータを情報格納サーバから取得するときに、処理時間を容易に短くできる情報処理装置、データ検索方法およびデータ検索プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
そこで、上記課題を解決するため、本発明は、外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索可能な情報処理装置であって、前記１つ以上の属性のデータ種別を設定可能であり、前記情報格納サーバから取得する属性を取得属性として設定するときに、前記属性毎のデータ種別をユーザに提示することを特徴とする。
【００１４】
また、本発明は、外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索可能な情報処理装置のデータ検索方法であって、前記１つ以上の属性のデータ種別をユーザに提示する段階と、前記情報格納サーバから取得する属性を取得属性としてユーザに設定させる段階とを有することを特徴とする。
【００１５】
また、本発明は、コンピュータに、外部に設置されている情報格納サーバから１つ以上の属性で構成されるデータを検索させるデータ検索プログラムであって、前記１つ以上の属性のデータ種別をユーザに提示する手順と、前記情報格納サーバから取得する属性を取得属性としてユーザに設定させる手順とを実行させるためのデータ検索プログラムであることを特徴とする。
【００１６】
本発明は、１つ以上の属性で構成されるデータを情報格納サーバから取得する為、その情報格納サーバから取得する属性を取得属性として設定するときに、属性毎のデータ種別をユーザに提示する。即ち、情報格納サーバから取得する属性のデータ種別を設定可能である。
【００１７】
ユーザは属性毎のデータ種別を確認しつつ情報格納サーバから取得する属性を設定することができる。例えば処理時間が一般的に短いデータ種別（例えばテキストデータ）の属性を情報格納サーバから取得する取得属性として設定しておくことで、情報格納サーバからデータを取得するときの処理時間を短くできる。言い換えれば、処理時間が一般的に長いデータ種別（例えば、バイナリデータ）の属性を情報格納サーバから取得しない属性として設定しておくことで、情報格納サーバからデータを取得するときの処理時間を短くできる。
【発明の効果】
【００１８】
本発明によれば、１つ以上の属性で構成されるデータを情報格納サーバから取得するときに、処理時間を容易に短くできる情報処理装置、データ検索方法およびデータ検索プログラムを提供可能である。
【発明を実施するための最良の形態】
【００１９】
次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。本実施例では、クライアントの一例としての画像処理装置について説明する。なお、本実施例で説明する画像処理装置は、プリンタ，コピー，ファクシミリおよびスキャナなどの各装置の機能を１つの筐体内に収納している為、融合機と呼ぶ。
【００２０】
図１は、本発明による融合機のソフトウェア構成について説明するための一実施例の構成図である。融合機１は、ソフトウェア群２と，融合機起動部３と，ハードウェア資源４とを含むように構成される。
【００２１】
ハードウェア資源４は、プロッタ１１と，スキャナ１２と，ファクシミリなどのその他のハードウェアリソース１３とを含む。ソフトウェア群２は、ＵＮＩＸ（登録商標）などのオペレーティングシステム（以下、ＯＳという）上に起動されているアプリケーション層５とプラットフォーム６とを含む。
【００２２】
アプリケーション層５は、プリンタ，コピー，ファックスおよびスキャナなどの画像形成にかかるユーザサービスにそれぞれ固有の処理を行うプログラムを含む。図１のアプリケーション層５は、プリンタアプリ２１と，コピーアプリ２２と，ファックスアプリ２３と，スキャナアプリ２４と，ネットファイルアプリ２５とを含む。なお、ネットファイルアプリ２５はネットワークファイル用アプリケーションであり、融合機１にネットワークを介して接続されるネットワーク機器とのデータ通信を管理するものである。
【００２３】
プラットフォーム６は、アプリケーション層５からの処理要求を解釈してハードウェア資源４の獲得要求を発生するコントロールサービス層９と、１つ以上のハードウェア資源４の管理を行ってコントロールサービス層９からの獲得要求を調停するシステムリソースマネージャ（以下、ＳＲＭという）３９と、ＳＲＭ３９からの獲得要求に応じてハードウェア資源４の管理を行うハンドラ層１０とを含む。
【００２４】
コントロールサービス層９は、ＮＣＳ３１，ＤＣＳ３２，ＯＣＳ３３，ＦＣＳ３４，ＥＣＳ３５，ＭＣＳ３６，ＵＣＳ３７，ＳＣＳ３８など、一つ以上のサービスモジュールを含む。なお、プラットフォーム６は予め定義されている関数により、アプリケーション層５からの処理要求を受信するＡＰＩ５３を有するように構成されている。ＯＳは、アプリケーション層５およびプラットフォーム６の各ソフトウェアをプロセスとして並列実行する。
【００２５】
ＮＣＳ（ネットワークコントロールサービス）３１のプロセスは、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分ける際の仲介、又は各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。例えばＮＣＳ３１は、融合機１にネットワークを介して接続されるネットワーク機器とのデータ通信を制御する。
【００２６】
ＤＣＳ（デリバリーコントロールサービス）３２のプロセスは、融合機１に蓄積されている文書データの配送などの制御を行う。ＯＣＳ（操作パネルコントロールサービス）３３のプロセスは、後述する操作パネルの制御を行う。
【００２７】
ＦＣＳ（ファックスコントロールサービス）３４のプロセスは、アプリケーション層５からＰＳＴＮまたはＩＳＤＮ網を利用したファックスの送受信，バックアップ用のメモリで管理されている各種ファックスデータの登録又は引用，ファックスの読み取り，ファックスの受信印刷などを行うためのＡＰＩを提供する。
【００２８】
ＥＣＳ（エンジンコントロールサービス）３５のプロセスは、プロッタ１１，スキャナ１２，ハードウェアリソース１３などのエンジン部の制御を行う。ＭＣＳ（メモリコントロールサービス）３６のプロセスは、メモリの取得及び解放，ＨＤＤの利用，画像データの圧縮および伸張などの制御を行う。ＵＣＳ（ユーザ情報コントロールサービス）３７のプロセスは、ユーザ情報の管理を行うものである。
【００２９】
ＳＣＳ（システムコントロールサービス）３８のプロセスは、操作部の制御，システム画面の表示，ＬＥＤの表示，ハードウェア資源の管理，アプリケーションの管理，割り込みアプリケーションの制御などの処理を行う。
【００３０】
ＳＲＭ３９のプロセスは、ＳＣＳ３８と共にシステムの制御およびハードウェア資源４の管理を行うものである。例えばＳＲＭ３９のプロセスは、プロッタ１１やスキャナ１２などのハードウェア資源４を利用する上位層からの獲得要求に従って調停を行い、ハードウェア資源４の実行を制御する。
【００３１】
具体的に、ＳＲＭ３９のプロセスは獲得要求されたハードウェア資源４が利用可能であるか（他の獲得要求により利用されていないか）を判定し、利用可能であれば獲得要求されたハードウェア資源４が利用可能である旨を上位層に通知する。ＳＲＭ３９のプロセスは、上位層からの獲得要求に対してハードウェア資源４を利用するためのスケジューリングを行い、要求内容（プリンタエンジンによる紙搬送と作像動作，メモリの確保，ファイル生成など）を直接実施している。
【００３２】
また、ハンドラ層１０は後述するＦＣＵ（ファックスコントロールユニット）の管理を行うＦＣＵＨ（ファックスコントロールユニットハンドラ）４０と、プロセスに対するメモリの割り振り及びプロセスに割り振ったメモリの管理を行うＩＭＨ（イメージメモリハンドラ）４１とを含む。ＳＲＭ３９及びＦＣＵＨ４０は、予め定義されている関数によりハードウェア資源４に対する処理要求を送信するエンジンＩ／Ｆ５４を利用して、ハードウェア資源４に対する処理要求を行う。
【００３３】
図１の構成により、融合機１は各アプリケーションで共通的に必要な処理をプラットフォーム６で一元的に処理することができる。次に、融合機１のハードウェア構成について説明する。
【００３４】
図２は、本発明による融合機のハードウェア構成について説明するための一実施例の構成図である。図２の融合機１は、コントローラ６０，操作パネル８０，ＦＣＵ８１，エンジン部８２を有する。
【００３５】
コントローラ６０は、ＣＰＵ６１，システムメモリ６２，ＮＢ６３，ＳＢ６４，ＡＳＩＣ６６，ローカルメモリ６７，ＨＤＤ６８、ＮＩＣ６９，ＵＳＢ  Ｉ／Ｆ７０，ＩＥＥＥ１３９４  Ｉ／Ｆ７１，セントロニクス  Ｉ／Ｆ７２を有する。
【００３６】
操作パネル８０は、コントローラ６０のＡＳＩＣ６６に接続されている。また、ＦＣＵ８１およびエンジン部８２はコントローラ６０のＡＳＩＣ６６にＰＣＩバス８３を介して接続されている。
【００３７】
コントローラ６０は、ＡＳＩＣ６６にローカルメモリ６７，ＨＤＤ６８などが接続されると共に、ＣＰＵ６１とＡＳＩＣ６６とがＣＰＵチップセットのＮＢ６３を介して接続されている。なお、ＡＳＩＣ６６とＮＢ６３とはＡＧＰ（Accelerated Graphics Port）６５を介して接続されている。
【００３８】
ＣＰＵ６１は、融合機１の全体制御を行うものである。図１の融合機１では、ＣＰＵ６１がコントロールサービス層９を形成する１つ以上のサービスモジュールと、ＳＲＭ３９と、ハンドラ層１０を形成するＦＣＵＨ４０，ＩＭＨ４１とをＯＳ上に起動させた後、アプリケーション層５を形成するプリンタアプリ２１，コピーアプリ２２，ファックスアプリ２３，スキャナアプリ２４，ネットファイルアプリ２５を起動して実行させる。
【００３９】
ＮＢ（ノースブリッジ）６３は、ＣＰＵ６１，システムメモリ６２，ＳＢ６４，ＡＳＩＣ６６，ＮＩＣ６９，ＵＳＢ  Ｉ／Ｆ７０，ＩＥＥＥ１３９４  Ｉ／Ｆ７１及びセントロニクス  Ｉ／Ｆ７２を接続するためのブリッジである。ＮＢ６３は、ＳＢ６４，ＮＩＣ６９，ＵＳＢ  Ｉ／Ｆ７０，ＩＥＥＥ１３９４  Ｉ／Ｆ７１及びセントロニクス  Ｉ／Ｆ７２とＰＣＩバス７３を介して接続されている。なお、ＳＢ（サウスブリッジ）６４は、ＰＣＩバス７３とＲＯＭや周辺デバイス等とを接続するためのブリッジである。
【００４０】
システムメモリ６２は、描画用メモリ等として用いるメモリである。ローカルメモリ６７は、コピー用画像バッファ，符号バッファ等として用いるメモリである。ＡＳＩＣ６６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。また、ＨＤＤ６８は画像データの蓄積，文書データの蓄積，プログラムの蓄積，フォントデータの蓄積，フォームの蓄積などを行うストレージ（補助記憶装置）の一例である。
【００４１】
ＮＩＣ（ネットワークインターフェースカード）６９は、融合機１をインターネットやＬＡＮ等のネットワークに接続するインターフェース機器である。また、ＵＳＢ  Ｉ／Ｆ７０，ＩＥＥＥ１３９４  Ｉ／Ｆ７１およびセントロニクス  Ｉ／Ｆ７２は、夫々の規格に準じたインターフェースである。操作パネル８０は、ユーザからの入力操作を受け付けると共に、ユーザに向けた表示を行う操作部である。なお、ＦＣＵ８１はバックアップ用のメモリを有している。ＦＣＵ８１が有するメモリは、例えば融合機１の電源がＯＦＦのときに受信したファクシミリデータを一時的に格納するために利用される。
【００４２】
図３は、ＬＤＡＰサーバ情報の取得要求，追加要求，変更要求，削除要求について説明するための図である。なお、図３では説明に必要のない構成を省略している。ＵＣＳ３７は、ＬＤＡＰサーバ情報を一元管理している。ＵＣＳ３７は、例えばＬＤＡＰサーバ情報をＨＤＤ１０８に格納して管理している。
【００４３】
ＬＤＡＰサーバ情報は、サーバ名称，ホスト名（ＩＰアドレス），ポート番号，検索開始位置，認証情報，任意検索条件（複数）および文字コードなどをデータ項目として含んでいる。ＵＣＳ３７は、ファックスアプリ２３，スキャナアプリ２４又はＳＣＳ３８からの取得要求に応じて、ＬＤＡＰサーバ情報をファックスアプリ２３，スキャナアプリ２４又はＳＣＳ３８に提供する。また、ＵＣＳ３７は、ＳＣＳ３８からの追加要求，変更要求又は削除要求に応じて、ＬＤＡＰサーバ情報を追加，変更又は削除する。
【００４４】
ファックスアプリ２３は、ＵＣＳ３７にＬＤＡＰサーバ情報の取得要求を行うことで検索したいＬＤＡＰサーバ１０３のＬＤＡＰサーバ情報を取得する。ファックスアプリ２３はＬＤＡＰサーバ情報を用いてファックス機能に必要なユーザ情報を取得し、そのユーザ情報を用いて操作パネル８０に画面１１０を表示する。画面１１０には、例えばファックスデータを送信する宛先情報（例えばファックス番号など）を選択するための情報が表示される。
【００４５】
スキャナアプリ２４は、ＵＣＳ３７にＬＤＡＰサーバ情報の取得要求を行うことで検索したいＬＤＡＰサーバ１０３のＬＤＡＰサーバ情報を取得する。スキャナアプリ２４はＬＤＡＰサーバ情報を用いてスキャナ機能に必要なユーザ情報を取得し、そのユーザ情報を用いて操作パネル８０に画面１２０を表示する。画面１２０には、例えばスキャナデータを送信する宛先情報（例えば電子メールアドレスなど）を選択するための情報が表示される。
【００４６】
ＳＣＳ３８のシステム初期設定機能１０２は、ＵＣＳ３７にＬＤＡＰサーバ情報の取得要求，追加要求，変更要求，削除要求を行うことでＬＤＡＰサーバ情報の取得，追加，変更，削除を行う。なお、ＳＣＳ３８のソフトキーボード機能１０１は操作パネル８０にソフトキーボードを表示し、そのソフトキーボードの制御を行う。
【００４７】
図４は、検索機能を実現するＵＣＳのソフトウェア構成について説明するための一例の構成図である。なお、図４では説明に必要のない構成を省略している。ＵＣＳ３７は、ＡＰＩ層２１１，検索機能２１２，データベース制御機能２１３を有する。ＡＰＩ層２１１はファックスアプリ２３，スキャナアプリ２４又はＳＣＳ３８等のＵＣＳクライアント２００とのインターフェースを実現する。
【００４８】
検索機能２１２は、ＬＤＡＰ制御部２１４，ローカル制御部２１５で構成され、ＬＤＡＰライブラリ２２２，エンコードライブラリ２２３を用いてＬＤＡＰサーバに格納されているデータの検索機能を実現する。以下、ＬＤＡＰサーバに格納されているデータの検索をＬＤＡＰ検索と呼ぶ。
【００４９】
データベース制御機能２１３は、初期化部２１６，編集部２１７，取得部２１８，追加部２１９，削除部２２０およびＩ／Ｏ制御部２２１で構成され、ＨＤＤ６８等の記憶部２３０に格納されているＬＤＡＰサーバ情報２３１，ＬＤＡＰユーザ情報２３２及びローカルユーザ情報２３３を制御する。
【００５０】
上記のようなハードウェアおよびソフトウェア構成の融合機１を用いて図５のような手順でＬＤＡＰ検索が行われる。図５は、ＬＤＡＰ検索の一例のシーケンス図である。ステップＳ１０に進み、ファックスアプリ２３，スキャナアプリ２４等のＵＣＳクライアント２００は、ＵＣＳ３７に対してＬＤＡＰ検索要求を行う。なお、ＵＣＳクライアント２００はＬＤＡＰ検索要求をＵＣＳ６７に対して行うとき、サーバ名称，ホスト名（ＩＰアドレス），ポート番号などの検索対象ＬＤＡＰサーバ情報、検索フィルタ，取得属性，検索開始位置などの検索情報をＬＤＡＰ検索要求と共にＵＣＳ３７に供給する。
【００５１】
ステップＳ１１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、検索情報に応じた検索要求を行う。ステップＳ１２に進み、ＵＣＳ３７はステップＳ１１の検索要求に対する検索結果を受信する。ステップＳ１２で受信する検索結果は、例えば１エントリごとの図６のようなデータ構造の情報である。図６は、検索結果の一例のデータ構造図である。
【００５２】
ステップＳ１３に進み、ＵＣＳ３７は図６のような検索結果を図７のような融合機１用のエントリのデータ構造に１件ずつ変換し、ＬＤＡＰユーザ情報とする。図７は、ＬＤＡＰユーザ情報の一例のデータ構造図である。図７のＬＤＡＰユーザ情報は、エントリＩＤにより識別されるエントリ情報に、メール情報，ＦＡＸ情報，所属情報，付加情報などが関連付けられている。なお、付加情報はユーザが任意に設定できるＬＤＡＰサーバから取得する属性である。
【００５３】
ステップＳ１４に進み、ＵＣＳ３７は図６のような検索結果を破棄する。ステップＳ１５に進み、ＵＣＳ３７はステップＳ１３で検索結果から変換したＬＤＡＰユーザ情報をステップＳ１０のＬＤＡＰ検索要求に対する応答として、ＵＣＳクライアント２００に供給する。
【００５４】
ステップＳ１３の処理について更に説明する。図８は、検索結果を融合機用のエントリのデータ構造に１件ずつ変換する処理の一例のフローチャートである。ステップＳ２０に進み、ＵＣＳ３７は検索結果から一つ目のエントリを抽出する。ステップＳ２０に続いてステップＳ２１に進み、ＵＣＳ３７は抽出したエントリがあるか否かを判定する。
【００５５】
エントリがあれば（Ｓ２１においてＹＥＳ）、ＵＣＳ３７はステップＳ２２に進み、ＬＤＡＰユーザ情報のエントリ情報として追加する。なお、抽出したエントリがなければ（Ｓ２１においてＮＯ）、ＵＣＳ３７は図８の処理を終了する。
【００５６】
ステップＳ２２に続いてステップＳ２３に進み、ＵＣＳ３７はステップＳ２０で抽出したエントリから一つ目の属性を抽出する。例えば図６の検索結果の場合、ＵＣＳ３７は属性「ｃｎ」を抽出する。ステップＳ２４に進み、ＵＣＳ３７は抽出した属性があるか否かを判定する。
【００５７】
属性があれば（Ｓ２４においてＹＥＳ）、ＵＣＳ３７はステップＳ２５に進み、抽出した属性の属性値（実データ）を抽出する。例えば図６の検索結果の場合、ＵＣＳ３７は抽出した属性「ｃｎ」の属性値「Ｍａｓａｈｉｒｏ  Ｓｕｚｕｋｉ」を抽出する。なお、属性がなければ（Ｓ２４においてＮＯ）、ＵＣＳ３７は後述するステップＳ３４に進む。
【００５８】
ステップＳ２５に続いてステップＳ２６に進み、ＵＣＳ３７は抽出した属性値があるか否かを判定する。属性値があれば（Ｓ２６においてＹＥＳ）、ＵＣＳ３７はステップＳ２７に進み、抽出した属性値のエンコードを行う。ステップＳ２７のエンコードは、抽出した属性名を操作パネル８０に表示できる文字コードに変換する処理である。なお、属性値がなければ（Ｓ２６においてＮＯ）、ＵＣＳ３７は後述するステップＳ３２に進む。
【００５９】
ステップＳ２８に進み、ＵＣＳ３７は抽出した属性の名（以下、抽出属性名という）と融合機１用の属性の名（以下、内部属性名という）とを順番に比較していく。ステップＳ２９に進み、ＵＣＳ３７は抽出属性名と一致する内部属性名を見つけると、その内部属性名に対応するデータ項目に属性値を格納する。
【００６０】
ステップＳ３０に進み、ＵＣＳ３７は抽出した属性の次の属性値を抽出する。ステップＳ３１に進み、ＵＣＳ３７は抽出した属性値があるか否かを判定する。属性値があれば（Ｓ３１においてＹＥＳ）、ＵＣＳ３７はステップＳ２７に戻り、ステップＳ２７〜Ｓ３１の処理を繰り返す。なお、属性値がなければ（Ｓ２６においてＮＯ）、ＵＣＳ３７はステップＳ３２に進む。
【００６１】
ステップＳ３２では、ＵＣＳ３７が、ステップＳ２０で抽出したエントリから次の属性を抽出する。例えば図６の検索結果の場合、ＵＣＳ３７は属性「ｏｕ」を抽出する。ステップＳ３３に進み、ＵＣＳ３７は抽出した属性があるか否かを判定する。
【００６２】
属性があれば（Ｓ３３においてＹＥＳ）、ＵＣＳ３７はステップＳ２５に戻る。属性がなければ（Ｓ３３においてＮＯ）、ＵＣＳ３７はステップＳ３４に進む。以上で、１エントリのデータ構造が融合機１用のエントリのデータ構造に変換される。
【００６３】
ステップＳ３４では、ＵＣＳ３７が、検索結果から次のエントリを抽出する。ステップＳ３５に進み、ＵＣＳ３７は抽出したエントリがあるか否かを判定する。エントリがあれば（Ｓ３５においてＹＥＳ）、ＵＣＳ３７はステップＳ２２に戻る。なお、抽出したエントリがなければ（Ｓ３５においてＮＯ）、ＵＣＳ３７は図８の処理を終了する。
【００６４】
現状、融合機１は使用する属性をテキストデータと考えており、バイナリデータ（ｊｐｅｇＰｈｏｔｏ）のような予想外の属性を取得すると、エンコード等の処理を無駄に行って、ＵＣＳクライアント２００に検索結果を返すまでに時間が掛かる。
【００６５】
そこで、本発明では、テキストデータやバイナリデータ等のデータ種別を属性毎に設定可能とし、属性毎のデータ種別をユーザに提示するようにした。ユーザは、取得する属性を設定するときに、属性毎のデータ種別を確認しつつ融合機１で必要のない属性や処理に時間の掛かる属性を取得しないように設定できる。ただし、取得する属性は操作パネル８０からユーザが設定可能である。本発明では、必要のない属性や処理に時間の掛かる属性を取得しないような設定をユーザ主導で行うことができる。
【実施例１】
【００６６】
本発明の実施例１は、属性の設定時にユーザがデータ種別を設定し、取得する属性を取得属性として設定するときに属性毎のデータ種別を提示することで、ユーザに取得しない属性を設定させるものである。ユーザはバイナリデータなど処理時間の長いデータ種別の属性を取得しない属性として設定できる。
【００６７】
ユーザが操作パネル８０を操作して属性の設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に図９のような属性設定画面１０００を表示する。図９は、属性を設定する属性設定画面の一例のイメージ図である。図９の属性設定画面１０００は、属性を設定する欄と、キー表示名を設定する欄と、設定したいデータ種別を選択する選択ボタンとが含まれる。図９の属性設定画面１０００は、データ種別としてテキストまたは画像を選択する例である。
【００６８】
ユーザは、図９の属性設定画面１０００を利用して属性，キー表示名およびデータ種別を設定する。即ち、図９の属性設定画面を利用することにより、ユーザは属性毎にデータ種別を設定できる。属性毎にデータ種別を設定すると、図７のＬＤＡＰユーザ情報は図１０のように、名前やメールアドレスなどの属性の値（属性値）の修飾としてデータ種別が付加される。図１０は、データ種別が付加されたＬＤＡＰユーザ情報について説明するための図である。
【００６９】
ユーザが操作パネル８０を操作して取得属性の設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に図１１のような取得属性設定画面１１００，１２００を表示する。図１１は、取得属性を設定する取得属性設定画面の一例のイメージ図である。
【００７０】
図１１の取得属性設定画面１１００，１２００は、属性と、属性毎のデータ種別とが含まれている。ユーザは属性毎のデータ種別を確認することで、その属性が必要か否かを判断できる。取得属性設定画面１１００，１２００では、「名前」，「メール宛先」，「ファックス宛先」，「会社名」及び「部署名」の属性がデータ種別「テキストデータ」であり、「任意属性１」の属性がデータ種別「画像データ」である。
【００７１】
なお、ユーザは取得属性設定画面１１００，１２００の属性ボタン１１０１，１２０１を押下して属性ボタン１１０１，１２０１の非反転表示または反転表示を切り替えることで、取得する属性または取得しない属性を選択できる。
【００７２】
ユーザは、エントリを構成する属性毎にデータ種別を確認し、その属性が必要か否かを判断した上で、取得しない属性を自由に設定することができる。
【実施例２】
【００７３】
本発明の実施例２は、属性の設定時にプレ検索（前検索）の結果に基づきデータ種別を設定し、取得する属性を取得属性として設定するときに属性毎のデータ種別を提示することで、ユーザに取得しない属性を設定させるものである。ユーザはバイナリデータなど処理時間の長いデータ種別の属性を取得しない属性として設定できる。
【００７４】
ユーザが操作パネル８０を操作して属性の設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に図１２のような属性設定画面１３００を表示する。図１２は、属性を設定する属性設定画面の他の一例のイメージ図である。図１２の属性設定画面１３００は、属性を設定する欄と、キー表示名を設定する欄と、設定したいデータ種別を設定する欄と、プレ検索を実行するためのプレ検索ボタン１３０１とが含まれる。図１２の属性設定画面１３００は、属性「ｊｐｅｇＰｈｏｔｏ」をプレ検索した結果に基づき、データ種別「ｔｘｔ」が設定された例である。
【００７５】
ユーザが図１２の属性設定画面１３００に属性およびキー表示名を設定した後、プレ検索ボタン１３０１を押下すると、図１３のような処理が開始される。図１３は、設定された属性のデータ種別を取得する処理の一例のシーケンス図である。
【００７６】
ステップＳ１００に進み、ＵＣＳクライアント２００はＵＣＳ３７に対してＬＤＡＰ検索要求を行う。ＵＣＳクライアント２００はＬＤＡＰ検索要求をＵＣＳ６７に対して行うとき、ＩＰアドレス／ホスト名，ポート番号などの検索対象ＬＤＡＰサーバ情報、認証設定，認証ユーザ名，認証パスワード，データ種別を取得したい属性などの検索情報をＬＤＡＰ検索要求と共にＵＣＳ３７に供給する。
【００７７】
ステップＳ１０１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、検索情報に応じた検索要求を行う。ステップＳ１０２に進み、ＵＣＳ３７はステップＳ１０１の検索要求に対する検索結果を受信する。
【００７８】
ステップＳ１０３に進み、ＵＣＳ３７は受信した検索結果に画像でしか使用しない制御文字があるかをチェックする。ステップＳ１０４に進み、ＵＣＳ３７はステップＳ１０３のチェック結果に基づき、受信した検索結果に制御文字があるか否かを判定する。
【００７９】
制御文字があると判定すると（Ｓ１０４においてＹＥＳ）、ＵＣＳ３７は属性のデータ種別がバイナリデータであると判定したあと、ステップＳ１０６に進む。一方、制御文字がないと判定すると（Ｓ１０４においてＮＯ）、ＵＣＳ３７はステップＳ１０５に進み、受信した検索結果に含まれるデータのヘッダ部分のチェックを行うことで、属性のデータ種別を判定してステップＳ１０６に進む。
【００８０】
ステップＳ１０６では、ＵＣＳ３７が、判定したデータ種別を属性毎に保存する。ステップＳ１０７に進み、ＵＣＳ３７は判定したデータ種別がテキストデータであるか否かを判定する。
【００８１】
データ種別がテキストデータであると判定すると（Ｓ１０７においてＹＥＳ）、ＵＣＳ３７は検索結果を文字エンコードしてステップＳ１０９に進む。一方、データ種別がテキストデータでないと判定すると（Ｓ１０７においてＮＯ）、ＵＣＳ３７は検索結果を文字エンコードすることなくステップＳ１０９に進む。ステップＳ１０９では、ＵＣＳ３７が、設定された属性のデータ種別をステップＳ１００のＬＤＡＰ検索要求に対する検索結果としてＵＣＳクライアント２００に供給する。ＵＣＳクライアント２００は、図１２の属性設定画面１３００の設定したいデータ種別を設定する欄に、検索結果から読み出した属性のデータ種別を表示する。
【００８２】
したがって、ユーザは属性およびキー表示名を設定してプレ検索を行うことで、その属性のデータ種別を容易に取得できる。ユーザが操作パネル８０を操作して取得属性の設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に前述した取得属性設定画面１１００，１２００を表示する。ユーザは、属性毎のデータ種別を取得属性設定画面１１００，１２００で確認することにより、その属性が必要か否かを判断できる。
【００８３】
ユーザは、エントリを構成する属性毎にデータ種別を確認し、その属性が必要か否かを判断した上で、取得しない属性を自由に設定することができる。
【実施例３】
【００８４】
本発明の実施例３は、属性の設定時にプレ検索の結果をユーザに提示することでユーザにデータ種別を設定させ、取得する属性を取得属性として設定するときに属性毎のデータ種別を提示することで、ユーザに取得しない属性を設定させるものである。ユーザはバイナリデータなど処理時間の長いデータ種別の属性を取得しない属性として設定できる。
【００８５】
ユーザが操作パネル８０を操作して属性の設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に図１４のような属性設定画面１４００を表示する。図１４の属性設定画面１４００は、図１２の属性設定画面１３００と同様であるため説明を省略する。
【００８６】
ユーザが図１４の属性設定画面１４００に属性およびキー表示名を設定した後、プレ検索ボタン１４０１を押下すると、図１５のような処理が開始される。図１５は、設定された属性のデータ種別をユーザに判断させる処理の一例のシーケンス図である。なお、ステップＳ２００〜Ｓ２０２の処理は、図１３のステップＳ１００〜Ｓ１０２と同様であるため説明を省略する。
【００８７】
ステップＳ２０３に進み、ＵＣＳ３７は、ステップＳ２００のＬＤＡＰ検索要求に対する検索結果をＵＣＳクライアント２００に供給する。ステップＳ２０４に進み、ＵＣＳクライアント２００はステップＳ２０３で供給された検索結果を図１４のようなデータ種別設定画面１５００の検索結果表示欄１５０１に表示する。
【００８８】
図１４のデータ種別設定画面１５００は、検索結果表示欄１５０１と、ユーザにデータ種別を選択させるデータ種別選択ボタン１５０２と、文字コードを選択する文字コード選択ボタン１５０３とが含まれる。
【００８９】
検索結果表示欄１５０１は、データ種別選択ボタン１５０２で選択されたデータ種別に応じて検索結果が表示される。データ種別がテキストデータの場合、検索結果表示欄１５０１は、データ種別選択ボタン１５０２および文字コード選択ボタン１５０３とで選択された文字コードに応じて検索結果がテキストデータで表示される。
【００９０】
図１４のデータ種別設定画面１５００は、データ種別としてテキストデータ「＊．ｔｘｔ」が選択され、且つ、文字コードとして「ＵＴＦ−８」が選択された例である。図１４の検索結果表示欄１５０１は、正しいデータ種別が選択されていないため、無意味なテキストデータが表示されている。
【００９１】
ステップＳ２０５に進み、ユーザは操作パネル８０に表示されたデータ種別設定画面１５００を確認し、データ種別が正しくないと判断すれば、データ種別設定画面１５００のデータ種別選択ボタン１５０２，文字コード選択ボタン１５０３を押下してデータ種別の選択を行う。
【００９２】
ユーザがデータ種別として画像データ「＊．ｊｐｇ」を選択すると、ＵＣＳクライアント２００はステップＳ２０３で供給された検索結果を図１４のようなデータ種別設定画面１６００の検索結果表示欄１６０１に表示する。図１４の検索結果表示欄１６０１は、正しいデータ種別が選択されているため、意味のある画像が表示されている。ユーザは操作パネル８０に表示されたデータ種別設定画面１６００を確認し、データ種別が正しいと判断すれば、設定ボタン１６０２を押下する。
【００９３】
設定ボタン１６０２を押下することで、ユーザはデータ種別設定画面１６００で選択されているデータ種別を属性のデータ種別として設定できる。なお、図１４のデータ種別設定画面１５００，１６００には、検索結果表示欄１５０１，１６０１に表示される画像の拡大縮小やトリミングを可能とするため、拡大ボタン，縮小ボタン，カーソルボタンおよびトリミングボタンが設けられている。
【００９４】
設定ボタン１６０２が押下されると、ＵＣＳクライアント２００はデータ種別設定画面１６００で選択されているデータ種別を設定するためのデータ種別設定要求をＵＣＳ３７に対して行う。ステップＳ２０７〜Ｓ２０９の処理は、図１３のステップＳ１０６〜Ｓ１０８の処理と同様であるため説明を省略する。ステップＳ２１０では、ＵＣＳ３７が、ステップＳ２０６のデータ種別設定要求に対するデータ種別確定応答を供給する。
【００９５】
したがって、ユーザはデータ種別設定画面１５００，１６００に表示される検索結果のデータ種別を変化させて適切と判断したデータ種別を選択できる。また、ユーザが操作パネル８０を操作して取得属性の設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に前述した取得属性設定画面１１００，１２００を表示する。ユーザは、属性毎のデータ種別を取得属性設定画面１１００，１２００で確認することにより、その属性が必要か否かを判断できる。
【００９６】
ユーザは、エントリを構成する属性毎にデータ種別を確認し、その属性が必要か否かを判断した上で、取得しない属性を自由に設定することができる。
【００９７】
なお、データ種別を設定する方法としては、以下のようなものもある。第１に、ユーザが設定しそうな属性と、その属性のデータ種別との関係を例えば辞書として予め登録しておき、その辞書を利用して属性のデータ種別を設定できる。サブスキーマエントリやＲＦＣ規定のスキーマ一覧には、融合機１で使用しない属性についての説明が多く、無駄な情報を保持する可能性が高い。このため、ユーザが設定しそうな属性を予測し、その属性のスキーマ表を辞書として保持しておき、データ種別の設定に使用する。辞書にない属性については、サブスキーマエントリやＲＦＣ規定のスキーマ一覧からデータ種別を抽出すればよい。第２に、ユーザが以前に設定した属性とデータ種別との関係を例えば辞書として登録しておき、その辞書を利用して属性のデータ種別を設定することもできる。
【実施例４】
【００９８】
本発明の実施例４は、上記の実施例２〜３で説明した内容の組み合わせでデータ種別を設定し、取得する属性を取得属性として設定するときに属性毎のデータ種別を提示することで、ユーザに取得しない属性を設定させるものである。ユーザはバイナリデータなど処理時間の長いデータ種別の属性を取得しない属性として設定できる。
【００９９】
図１６は、設定された属性のデータ種別を複数の方法で取得する処理の一例のシーケンス図である。なお、図１６のシーケンス図は一例であって、データ種別を設定する方法の他の組み合わせも可能である。
【０１００】
ユーザが操作パネル８０を操作して属性の設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に例えば図１４の属性設定画面１４００を表示する。ユーザが属性設定画面１４００に属性およびキー表示名を設定した後、プレ検索ボタン１４０１を押下すると、図１６のような処理が開始される。
【０１０１】
ステップＳ３００では、ＵＣＳクライアント２００が、ＵＣＳ３７に対してデータ種別取得要求を行う。ＵＣＳクライアント２００はＬＤＡＰ検索要求をＵＣＳ６７に対して行うとき、ＩＰアドレス／ホスト名，ポート番号などの検索対象ＬＤＡＰサーバ情報と、認証設定，認証ユーザ名，認証パスワード，データ種別を取得したい属性などの検索情報とをデータ識別取得要求と共にＵＣＳ３７に供給する。
【０１０２】
ステップＳ３０１に進み、ＵＣＳ３７はデータ識別取得要求と共に供給された属性が上記の辞書にあるか否かをチェックする。ステップＳ３０２に進み、ＵＣＳ３７は属性が辞書にあると判定すると（Ｓ３０２においてＹＥＳ）、その辞書を利用して属性のデータ種別を設定した後、ステップＳ３１３に進む。なお、ＵＣＳ３７は属性が辞書にないと判定すると（Ｓ３０２においてＮＯ）、ステップＳ３０３に進む。
【０１０３】
ステップＳ３０３では、ＵＣＳ３７が、属性のデータ種別がサブスキーマエントリを利用して確定できるか否かをチェックする。ステップＳ３０４に進み、ＵＣＳ３７はデータ種別が確定できると判定すると（Ｓ３０４においてＹＥＳ）、サブスキーマエントリを利用して属性のデータ種別を設定した後、ステップＳ３１３に進む。ＵＣＳ３７は、データ種別が確定できないと判定すると（Ｓ３０４においてＮＯ）、ステップＳ３０５に進む。
【０１０４】
ステップＳ３０５では、ＵＣＳ３７が、属性のデータ種別がＲＦＣ規定のスキーマ一覧を利用して確定できるか否かをチェックする。ステップＳ３０６に進み、データ種別が確定できると判定すると（Ｓ３０６においてＹＥＳ）、ＵＣＳ３７はＲＦＣ規定のスキーマ一覧を利用して属性のデータ種別を設定した後、ステップＳ３１３に進む。なお、ＵＣＳ３７はデータ種別が確定できないと判定すると（Ｓ３０６においてＮＯ）、ステップＳ３０７に進む。
【０１０５】
ステップＳ３０７では、ＵＣＳ３７が、前述したようなプレ検索を実行する。ステップＳ３０８に進み、ＵＣＳ３７は検索結果に画像でしか使用しない制御文字があるかをチェックする。ステップＳ３０９に進み、ＵＣＳ３７は制御文字があると判定すると（Ｓ３０９においてＹＥＳ）、属性のデータ種別として画像データを設定した後、ステップＳ３１３に進む。なお、ＵＣＳ３７は制御文字がないと判定すると（Ｓ３０９においてＮＯ）、ステップＳ３１０に進み、ステップＳ３００のデータ種別取得要求に対する応答としてデータ種別特定ＮＧおよび検索結果をＵＣＳクライアント２００に供給する。
【０１０６】
ステップＳ３１１に進み、ＵＣＳクライアント２００は操作パネル８０に図１４のようなデータ種別設定画面１５００を表示する。ユーザは操作パネル８０に表示されたデータ種別設定画面１５００を確認し、データ種別が正しいと判断するまで、データ種別設定画面１５００のデータ種別選択ボタン１５０２，文字コード選択ボタン１５０３を押下してデータ種別の選択を行う。
【０１０７】
ユーザにより設定ボタン１６０２が押下されると、ＵＣＳクライアント２００はステップＳ３１２に進み、データ種別設定画面１６００で選択されているデータ種別を設定するためのデータ種別設定要求をＵＣＳ３７に対して行う。ステップＳ３１３では、ＵＣＳ３７が、設定されたデータ種別を属性毎に保存した後、ステップＳ３１２のデータ種別設定要求に対するデータ種別確定応答を供給する。
【０１０８】
ユーザは、エントリを構成する属性毎にデータ種別を確認し、その属性が必要か否かを判断した上で、取得しない属性を自由に設定することができる。
【実施例５】
【０１０９】
上記の実施例１〜４ではデータサイズが大きい等の理由により処理時間の掛かるデータ種別の属性をＬＤＡＰサーバ１０３から取得しないように設定することで処理時間を短くするようにしていた。実施例５では、ＬＤＡＰサーバ１０３に対する検索要求をデータ種別に応じて分けて行うことで処理時間を短くしている。
【０１１０】
図１７は、本発明によるＬＤＡＰ検索の一例のシーケンス図である。このシーケンス図は、ＬＤＡＰサーバ１０３に対する検索要求をデータ種別に応じて分けて行うことで、操作パネル８０にＬＤＡＰ検索結果画面が表示されるまでの時間を短縮する。
【０１１１】
ステップＳ４００に進み、ＵＣＳクライアント２００はＵＣＳ３７に対してＬＤＡＰ検索要求を行う。ステップＳ４０１に進み、ＵＣＳクライアント２００は検索対象となる取得属性のデータ種別を取得し、データ種別がテキストデータの取得属性を抽出する。ステップＳ４０２に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、ステップＳ４０１で抽出された取得属性の検索要求を行う。ステップＳ４０３に進み、ＵＣＳ３７はステップＳ４０２の検索要求に対する検索結果を受信する。
【０１１２】
ステップＳ４０４に進み、ＵＣＳ３７はエントリＩＤを検索結果としてＵＣＳクライアント２００に供給する。ステップＳ４０５に進み、ＵＣＳクライアント２００はＵＣＳ３７に対してエントリ情報取得要求を行う。ステップＳ４０６に進み、ＵＣＳクライアント２００はＵＣＳ３７からエントリＩＤに対応するエントリ情報を取得する。ここでＵＣＳクライアント２００が取得する属性は、データ種別がテキストデータの属性である。
【０１１３】
例えばデータ種別がテキストデータの属性でＬＤＡＰ検索結果画面を構成すれば、ＵＣＳクライアント２００はステップＳ４０６で取得した属性を用いて迅速にＬＤＡＰ検索結果画面を表示できる。
【０１１４】
ステップＳ４０７に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、ＬＤＡＰ検索要求に対する残りの検索要求を行う。ステップＳ４０７で検索対象となる取得属性は、データ種別がテキストデータ以外のバイナリデータ等である。ステップＳ４０８に進み、ＵＣＳ３７はステップＳ４０７の検索要求に対する検索結果を受信する。
【０１１５】
図１７のＬＤＡＰ検索では、処理時間の短いテキストデータ等のデータ種別の属性を最初に取得してＬＤＡＰ検索結果画面を表示する。そして、残りの属性はＬＤＡＰ検索結果画面を表示しつつ取得している。
【０１１６】
図１８は、最初に取得する検索結果と後から取得する検索結果との違いを説明するためのデータ構成図である。図１８のデータ構成図で表されたＬＤＡＰユーザ情報は、エントリＩＤにより識別されるエントリ情報，メール情報，ＦＡＸ情報，所属情報がステップＳ４０３の検索結果から取得される。また、付加情報はステップＳ４０８の検索結果から取得される。
【０１１７】
ユーザは、ＬＤＡＰサーバ１０３に対する検索要求をデータ種別に応じて分けて行うことで、検索結果画面を表示するまでの時間を短くすることができる。
【実施例６】
【０１１８】
本発明の実施例６では、ＬＤＡＰサーバ１０３に対する検索要求をデータ種別に応じて分けて行うと共に、残りの属性を要求されてから取得するものである。図１９は、本発明によるＬＤＡＰ検索の一例のシーケンス図である。このシーケンス図は、ＬＤＡＰサーバ１０３に対する検索要求をデータ種別に応じて分けて行うと共に、残りの属性を要求されてから取得することで、操作パネル８０にＬＤＡＰ検索結果画面が表示されるまでの時間を短縮する。
【０１１９】
ステップＳ５００〜Ｓ５０６の処理は、図１７のステップＳ４００〜Ｓ４０６の処理と同様であり、説明を省略する。ステップＳ５０７では、ＵＣＳクライアント２００が、ＵＣＳ３７に対して詳細データ取得要求を行う。即ち、ＵＣＳ３７はＵＣＳクライアント２００から詳細データ取得要求があるまで残りの属性をＬＤＡＰ検索しない。
【０１２０】
詳細データ取得要求が供給されると、ＵＣＳ３７はステップＳ５０８に進み、ステップＳ５００のＬＤＡＰ検索要求に対する残りの検索要求を行う。ステップＳ５０８で検索対象となる取得属性は、データ種別がテキストデータ以外のバイナリデータ等である。ステップＳ５０９に進み、ＵＣＳ３７はステップＳ５０８の検索要求に対する検索結果を受信する。ステップＳ５１０に進み、ＵＣＳ３７はステップＳ５０９で受信した検索結果を詳細データとしてＵＣＳクライアント２００に供給する。
【０１２１】
図１９のＬＤＡＰ検索では、処理時間の短いテキストデータ等のデータ種別の属性を最初に取得してＬＤＡＰ検索結果画面を表示する。そして、残りの属性はＵＣＳクライアント２００から要求されてから取得する。従って、無駄な属性を取得することを避けることができる。
【０１２２】
ユーザは、ＬＤＡＰサーバ１０３に対する検索要求をデータ種別に応じて分けて行うと共に、残りの属性を要求されてから取得することで、検索結果画面を表示するまでの時間を短くすることができる。
【実施例７】
【０１２３】
本発明の実施例７では、ＬＤＡＰサーバ１０３に対する検索要求を属性に応じて分けて行うときに、ユーザが手動で属性の取得順序を変更する。図２０は、属性の取得順序を設定する取得順序設定画面の一例のイメージ図である。
【０１２４】
ユーザが操作パネル８０を操作して属性の取得順序の設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に図２０のような取得順序設定画面１７００，１８００を表示する。図２０の取得順序設定画面１７００，１８００は、取得属性と、その取得属性のデータ種別と、取得順序と、取得順序を変更する取得順序変更ボタン１７０１とが含まれる。
【０１２５】
図２０の取得順序設定画面１７００，１８００では、取得順序として「常に取得」または「詳細表示時のみ取得」を取得属性毎に設定可能である。取得順序として「詳細表示時のみ取得」を設定した取得属性は、詳細表示を行う時にのみ取得されるため、無駄に取得することを避けることができる。図２０の取得順序設定画面１７００，１８００では、取得属性毎にデータ種別が表示されるため、ユーザがＬＤＡＰ検索結果画面を表示するまでの時間短縮を意識して、属性の取得順序を設定できる。
【０１２６】
また、図２１は属性の取得順序を設定する取得順序設定画面の他の一例のイメージ図である。ユーザが操作パネル８０を操作して属性の取得順序の設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に図２１のような取得順序設定画面１９００を表示する。図２１の取得順序設定画面１９００は、取得属性を表すボタン１９０１と、その取得属性のデータ種別とが含まれる。
【０１２７】
ユーザは取得順序設定画面１９００のボタン１９０１，１９０２を押下してボタン１９０１，１９０２の非反転表示または反転表示を切り替えることで、取得する属性を選択できる。図２１の取得順序設定画面１９００では、取得属性毎にデータ種別が表示されるため、ユーザがＬＤＡＰ検索結果画面を表示するまでの時間短縮を意識して、属性の取得順序を設定できる。図２１では、データ種別「テキストデータ」の属性「名前」，「メール宛先」が取得属性として選択されている。
【実施例８】
【０１２８】
本発明の実施例８では、ユーザが手動でＬＤＡＰ検索結果画面の表示構成（画面レイアウト）を変更する。図２２は、表示レイアウト設定画面の一例のイメージ図である。表示レイアウト設定画面２０００は、ＬＤＡＰ検索結果一覧画面の表示レイアウトを設定するために利用するものである。表示レイアウト設定画面２１００は、ＬＤＡＰ検索結果詳細画面の表示レイアウトを設定するためのものである。
【０１２９】
ユーザが操作パネル８０を操作してＬＤＡＰ検索結果一覧画面の表示レイアウトの設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に図２２のような表示レイアウト設定画面２０００を表示する。図２２の表示レイアウト設定画面２０００は、ＬＤＡＰ検索結果一覧画面に表示する属性を設定する欄が含まれる。ユーザは、表示レイアウト設定画面２０００の属性を設定する欄に属性を設定することで、ＬＤＡＰ検索結果一覧画面に表示される属性を変更できる。
【０１３０】
ユーザが操作パネル８０を操作してＬＤＡＰ検索結果詳細画面の表示レイアウトの設定を要求すると、ＵＣＳクライアント２００は操作パネル８０に図２２のような表示レイアウト設定画面２１００を表示する。図２２の表示レイアウト設定画面２１００は、ＬＤＡＰ検索結果詳細画面に表示する属性を設定する欄が含まれる。ユーザは、表示レイアウト設定画面２１００の属性を設定する欄に属性を設定することで、ＬＤＡＰ検索結果詳細画面に表示される属性を変更できる。
【０１３１】
図２２の表示レイアウト設定画面２２００は、表示レイアウト設定画面２０００，２１００の属性を設定する欄に、属性を設定するためのものである。ユーザは、表示レイアウト設定画面２２００のボタン２２０１，２２０２の非反転表示または反転表示を切り替えることで、表示レイアウト設定画面２０００，２１００の属性を設定する欄に、属性を設定できる。
【０１３２】
図２３は、ＬＤＡＰ検索結果画面の表示レイアウトを変更する処理の一例のシーケンス図である。ステップＳ６００では、ＵＣＳクライアント２００が、図２２の表示レイアウト設定画面２０００，２１００を操作パネル８０に表示する。ステップＳ６０１に進み、ユーザにより表示レイアウト設定画面２０００，２１００の属性を設定する欄に属性を設定される。
【０１３３】
ステップＳ６０２に進み、ＵＣＳクライアント２００はＬＤＡＰサーバ情報設定要求をＵＣＳ６７に対して行うとき、ＩＰアドレス／ホスト名，ポート番号などの検索対象ＬＤＡＰサーバ情報、認証設定，認証ユーザ名，認証パスワード，属性情報，表示レイアウト情報などの設定情報をＬＤＡＰサーバ情報設定要求と共にＵＣＳ３７に供給する。
【０１３４】
ＵＣＳ３７は、ステップＳ６０２で供給された設定情報に応じて、属性毎に、その属性に対応する融合機１の項目と、その属性を表示する表示レイアウト情報とを図２４のように関連付ける。図２４は、属性と、その属性に対応する融合機の項目と、その属性を表示する表示レイアウト情報との関連付ける処理を説明するための説明図である。
【０１３５】
ステップＳ６０３に進み、ＵＣＳ３７は属性に対応する融合機１の項目とその属性を表示する表示レイアウト情報との関連付けが成功したか失敗したかを、ステップＳ６０２のＬＤＡＰサーバ情報設定要求に対する応答としてＵＣＳクライアント２００に供給する。
【０１３６】
表示レイアウトが変更されたＬＤＡＰ検索結果画面は、図２５のようなシーケンス図で表されるＬＤＡＰ検索で利用される。図２５は、ＬＤＡＰ検索の一例のシーケンス図である。ステップＳ７００に進み、ＵＣＳクライアント２００は、ＵＣＳ３７に対してＬＤＡＰ検索要求を行う。なお、ＵＣＳクライアント２００はＬＤＡＰ検索要求をＵＣＳ６７に対して行うとき、検索対象ＬＤＡＰサーバ情報、検索情報をＬＤＡＰ検索要求と共にＵＣＳ３７に供給する。
【０１３７】
ステップＳ７０１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、検索情報に応じた検索要求を行う。ステップＳ７０２に進み、ＵＣＳ３７はステップＳ７０１の検索要求に対する検索結果を受信する。ステップＳ７０２で受信する検索結果は、例えば１エントリごとの図６のようなデータ構造の情報である。
【０１３８】
ステップＳ７０３に進み、ＵＣＳ３７は図６のような検索結果を図７のような融合機１用のエントリのデータ構造に１件ずつ変換し、ＬＤＡＰユーザ情報とする。即ち、ＬＤＡＰユーザ情報は、図２６のように名前やメールアドレスなどの属性の値（属性値）の修飾として表示構成情報（表示レイアウト情報）が付加される。図２６は、表示レイアウト情報が付加されたＬＤＡＰユーザ情報について説明するための図である。
【０１３９】
ステップＳ７０４に進み、ＵＣＳ３７はステップＳ７０３で検索結果から変換したＬＤＡＰユーザ情報をステップＳ７００のＬＤＡＰ検索要求に対する応答として、ＵＣＳクライアント２００に供給する。ＵＣＳクライアント２００は、ステップＳ７０４で供給されたＬＤＡＰ検索要求に対する応答に基づき、図２７のようなＬＤＡＰ検索結果詳細画面２３００を操作パネル８０に表示する。
【０１４０】
図２７は、ＬＤＡＰ検索結果詳細画面の一例のイメージ図である。図２７のＬＤＡＰ検索結果詳細画面２３００の表示レイアウトは、図２２の表示レイアウト設定画面２１００で設定された属性に対応している。
【０１４１】
ユーザは、ＬＤＡＰ検索結果画面の表示構成（表示レイアウト）を手動で変更することができる。
【実施例９】
【０１４２】
本発明の実施例９は、融合機１が自動でＬＤＡＰ検索結果画面の表示構成（表示レイアウト）を変更する。以下、ＬＤＡＰ検索結果画面の表示レイアウトを自動で行う方法について幾つか例示する。
【０１４３】
図２８は、検索条件として入力された項目に応じてＬＤＡＰ検索結果画面の表示レイアウトを変更する処理の一例のフローチャートである。図２８の処理は、例えば図５のステップＳ１３の処理の一部として行われる。
【０１４４】
ステップＳ８００に進み、ＵＣＳ３７は１エントリから一つ目の属性を抽出する。ステップＳ８０１に進み、ＵＣＳ３７は抽出した属性があるか否かを判定する。属性があると判定すると（Ｓ８０１においてＹＥＳ）、ＵＣＳ３７はステップＳ８０２に進み、抽出した属性の属性値（実データ）を抽出する。なお、属性がないと判定すると（Ｓ８０１においてＮＯ）、ＵＣＳ３７は図２８の処理を終了する。
【０１４５】
ステップＳ８０２に続いてステップＳ８０３に進み、ＵＣＳ３７は抽出した属性値があるか否かを判定する。属性値があれば（Ｓ８０３においてＹＥＳ）、ＵＣＳ３７はステップＳ８０４に進み、抽出した属性が検索項目に指定された属性であるか否かを判定する。
【０１４６】
抽出した属性が検索項目に指定された属性であれば（Ｓ８０４においてＹＥＳ）、ＵＣＳ３７はステップＳ８０５に進む。ステップＳ８０５では、ＵＣＳ３７が、抽出した属性をＬＤＡＰ検索結果一覧画面に表示する属性とした後、ステップＳ８０７に進む。抽出した属性が検索項目に指定された属性でなければ（Ｓ８０４においてＮＯ）、ＵＣＳ３７はステップＳ８０６に進む。ステップＳ８０６では、ＵＣＳ３７が、抽出した属性をＬＤＡＰ検索結果詳細画面に表示する属性とした後、ステップＳ８０７に進む。なお、属性値がなれば（Ｓ８０３においてＮＯ）、ＵＣＳ３７はステップＳ８０７に進む。
【０１４７】
ステップＳ８０７では、ＵＣＳ３７が、１エントリから次の属性を抽出する。ステップＳ８０８に進み、ＵＣＳ３７は抽出した属性があるか否かを判定する。属性があれば（Ｓ８０８においてＹＥＳ）、ＵＣＳ３７はステップＳ８０２に戻る。属性がなければ（Ｓ８０８においてＮＯ）、ＵＣＳ３７は図２８の処理を終了する。
【０１４８】
以上のように、１エントリを構成する属性を検索条件として入力された項目に応じてＬＤＡＰ検索結果一覧画面とＬＤＡＰ検索結果詳細画面とに振り分けることで、ＬＤＡＰ検索結果画面の表示レイアウトを変更できる。
【０１４９】
なお、ステップＳ８０４の判定は、抽出した属性が検索項目に指定された属性であるか否かによって、ＬＤＡＰ検索結果一覧画面とＬＤＡＰ検索結果詳細画面とに振り分けているが、抽出した属性が検索項目に指定され易い属性であるか否かによって、ＬＤＡＰ検索結果一覧画面とＬＤＡＰ検索結果詳細画面とに振り分けるようにしてもよい。
【０１５０】
抽出した属性が検索項目に指定され易い属性であるか否かの判定は、例えば図２９のように、検索項目として指定された回数（検索指定回数）を属性毎に記録しておくことで容易に行うことができる。図２９は、属性毎の検索指定回数を記録するテーブルの一例のイメージ図である。
【０１５１】
その他、ステップＳ８０４の判定は、検索要求を出したアプリケーションによって、抽出した属性をＬＤＡＰ検索結果一覧画面とＬＤＡＰ検索結果詳細画面とに振り分けるようにしてもよい。また、ステップＳ８０４の判定は、検索項目に指定された属性のうちヒット数の多い属性をＬＤＡＰ検索結果一覧画面に振り分け、その他の属性をＬＤＡＰ検索結果詳細画面に振り分けるようにしてもよい。
【０１５２】
次に、ＵＣＳ３７が表示レイアウト項目ごとに幾つかの候補属性を持ち、取得できた属性に応じてＬＤＡＰ検索結果画面の表示レイアウトを変更するようにしてもよい。図３０は、表示レイアウト項目ごとの候補属性を表した一例の構成図である。
【０１５３】
図３０に表されるように、ＵＣＳ３７は「一覧表示(1)」などの表示レイアウト項目ごとに候補属性を持っている。表示レイアウト項目は、例えば図３１，図３２の表示レイアウト設定画面２４００，２５００の「一覧表示(1)」〜「一覧表示(2)」、「詳細表示(1)」〜「詳細表示(6)」が割り当てられた欄に対応している。
【０１５４】
ＵＣＳ３７は、候補属性にある全ての属性を表示レイアウト項目ごとに取得し、優先順位の高い候補をその表示レイアウト項目に対応する欄に割り当てる。表示候補を取得する順番は、例えば「一覧表示(1)」、「一覧表示(2)」、「詳細表示(1)」〜「詳細表示(6)」とする。
【０１５５】
ここで、ＵＣＳ３７が表示レイアウト項目ごとに幾つかの候補属性を持ち、取得できた属性に応じてＬＤＡＰ検索結果画面の表示レイアウトを変更する場合の処理について図３３のシーケンス図を用いて説明する。図３３は、ＬＤＡＰ検索の他の一例のシーケンス図である。
【０１５６】
ステップＳ９００に進み、ＵＣＳクライアント２００は、ＵＣＳ３７に対してＬＤＡＰ検索要求を行う。なお、ＵＣＳクライアント２００はＬＤＡＰ検索要求をＵＣＳ６７に対して行うとき、検索対象ＬＤＡＰサーバ情報、検索情報をＬＤＡＰ検索要求と共にＵＣＳ３７に供給する。
【０１５７】
ステップＳ９０１に進み、ＵＣＳ３７はＵＣＳクライアント２００から供給された検索対象ＬＤＡＰサーバ情報で特定されるＬＤＡＰサーバ１０３に対し、検索情報に応じた検索要求を行う。ステップＳ９０２に進み、ＵＣＳ３７はステップＳ９０１の検索要求に対する検索結果を受信する。ステップＳ９０２で受信する検索結果は、例えば１エントリごとの候補属性にある全ての属性の情報である。
【０１５８】
ステップＳ９０３に進み、ＵＣＳ３７は検索結果から属性を抽出する。ステップＳ９０４に進み、ＵＣＳ３７はステップＳ３７で抽出した属性が候補属性に当てはまるか否かを検索する。ステップＳ９０５に進み、候補属性に当てはまる属性であれば（Ｓ９０５においてＹＥＳ）、ＵＣＳ３７はステップＳ９０６に進む。一方、候補属性に当てはまる属性でなければ（Ｓ９０５においてＮＯ）、ＵＣＳ３７はステップＳ９０３に戻る。ステップＳ９０６では、ＵＣＳ３７が、候補属性に当てはまる属性の属性値を保存する。即ち、ＬＤＡＰユーザ情報は、図２６のように名前やメールアドレスなどの属性の値（属性値）の修飾として表示構成情報（表示レイアウト情報）が付加される。
【０１５９】
ステップＳ９０７に進み、ＵＣＳ３７は空の表示レイアウト項目があるか否かを判定する。空の表示レイアウト項目があると判定すると（Ｓ９０７においてＹＥＳ）、ＵＣＳ３７はステップＳ９０３に戻る。
【０１６０】
一方、空の表示レイアウト項目がないと判定すると（Ｓ９０７においてＮＯ）、ＵＣＳ３７はステップＳ９０８に進み、ＬＤＡＰユーザ情報をステップＳ９００のＬＤＡＰ検索要求に対する応答として、ＵＣＳクライアント２００に供給する。ＵＣＳクライアント２００は、ステップＳ９０８で供給されたＬＤＡＰ検索要求に対する応答に基づき、図２７のようなＬＤＡＰ検索結果詳細画面２３００を操作パネル８０に表示する。
【０１６１】
したがって、ＵＣＳ３７は表示レイアウト項目ごとに幾つかの候補属性を持つことで、取得できた属性に応じてＬＤＡＰ検索結果画面の表示構成を変更できる。
【０１６２】
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求のの範囲から逸脱することなく、種々の変形や変更が可能である。
【図面の簡単な説明】
【０１６３】
【図１】本発明による融合機のソフトウェア構成について説明するための一実施例の構成図である。
【図２】本発明による融合機のハードウェア構成について説明するための一実施例の構成図である。
【図３】ＬＤＡＰサーバ情報の取得要求，追加要求，変更要求，削除要求について説明するための図である。
【図４】検索機能を実現するＵＣＳのソフトウェア構成について説明するための一例の構成図である。
【図５】ＬＤＡＰ検索の一例のシーケンス図である。
【図６】検索結果の一例のデータ構造図である。
【図７】ＬＤＡＰユーザ情報の一例のデータ構造図である。
【図８】検索結果を融合機用のエントリのデータ構造に１件ずつ変換する処理の一例のフローチャートである。
【図９】属性を設定する属性設定画面の一例のイメージ図である。
【図１０】データ種別が付加されたＬＤＡＰユーザ情報について説明するための図である。
【図１１】取得属性を設定する取得属性設定画面の一例のイメージ図である。
【図１２】属性を設定する属性設定画面の他の一例のイメージ図である。
【図１３】設定された属性のデータ種別を取得する処理の一例のシーケンス図である。
【図１４】属性を設定する属性設定画面の他の一例のイメージ図である。
【図１５】設定された属性のデータ種別をユーザに判断させる処理の一例のシーケンス図である。
【図１６】設定された属性のデータ種別を複数の方法で取得する処理の一例のシーケンス図である。
【図１７】本発明によるＬＤＡＰ検索の一例のシーケンス図である。
【図１８】最初に取得する検索結果と後から取得する検索結果との違いを説明するためのデータ構成図である。
【図１９】本発明によるＬＤＡＰ検索の一例のシーケンス図である。
【図２０】属性の取得順序を設定する取得順序設定画面の一例のイメージ図である。
【図２１】属性の取得順序を設定する取得順序設定画面の他の一例のイメージ図である。
【図２２】表示レイアウト設定画面の一例のイメージ図である。
【図２３】ＬＤＡＰ検索結果画面の表示レイアウトを変更する処理の一例のシーケンス図である。
【図２４】属性と、その属性に対応する融合機の項目と、その属性を表示する表示レイアウト情報との関連付ける処理を説明するための説明図である。
【図２５】ＬＤＡＰ検索の一例のシーケンス図である。
【図２６】表示レイアウト情報が付加されたＬＤＡＰユーザ情報について説明するための図である。
【図２７】ＬＤＡＰ検索結果詳細画面の一例のイメージ図である。
【図２８】検索条件として入力された項目に応じてＬＤＡＰ検索結果画面の表示レイアウトを変更する処理の一例のフローチャートである。
【図２９】属性毎の検索指定回数を記録するテーブルの一例のイメージ図である。
【図３０】表示レイアウト項目ごとの候補属性を表した一例の構成図である。
【図３１】表示レイアウト設定画面の一例のイメージ図である。
【図３２】表示レイアウト設定画面の一例のイメージ図である。
【図３３】ＬＤＡＰ検索の他の一例のシーケンス図である。
【符号の説明】
【０１６４】
１    融合機
２    ソフトウェア群
３    融合機起動部
４    ハードウェア資源
５    アプリケーション層
６    プラットフォーム
９    コントロールサービス層
１０    ハンドラ層
１１    プロッタ
１２    スキャナ
１３    ハードウェアリソース
２１    プリンタアプリ
２２    コピーアプリ
２３    ファックスアプリ
２４    スキャナアプリ
２５    ネットファイルアプリ
３１    ネットワークコントロールサービス（ＮＣＳ）
３２    デリバリーコントロールサービス（ＤＣＳ）
３３    オペレーションパネルコントロールサービス（ＯＣＳ）
３４    ファックスコントロールサービス（ＦＣＳ）
３５    エンジンコントロールサービス（ＥＣＳ）
３６    メモリコントロールサービス（ＭＣＳ）
３７    ユーザインフォメーションコントロールサービス（ＵＣＳ）
３８    システムコントロールサービス（ＳＣＳ）
３９    システムリソースマネージャ（ＳＲＭ）
４０    ファックスコントロールユニットハンドラ（ＦＣＵＨ）
４１    イメージメモリハンドラ（ＩＭＨ）
５３    アプリケーションプログラムインターフェース（ＡＰＩ）
５４    エンジンＩ／Ｆ
６０    コントローラ
６１    ＣＰＵ
６２    システムメモリ
６３    ノースブリッジ（ＮＢ）
６４    サウスブリッジ（ＳＢ）
６５    ＡＧＰ（Accelerated Graphics Port）
６６    ＡＳＩＣ
６７    ローカルメモリ
６８    ハードディスク装置（ＨＤＤ）
６９    ネットワークインターフェースコントローラ（ＮＩＣ）
７０    ＵＳＢ  Ｉ／Ｆ
７１    ＩＥＥＥ１３９４  Ｉ／Ｆ
７２    セントロニクス  Ｉ／Ｆ
８０    操作パネル
８１    ファックスコントロールユニット（ＦＣＵ）
８２    エンジン部
８３    ＰＣＩバス
１０３    ＬＤＡＰサーバ
２００    ＵＣＳクライアント
２１１    ＡＰＩ層
２１２    検索機能
２１３    データベース制御機能
２２２    ＬＤＡＰライブラリ
２２３    エンコードライブラリ
２３０    記憶部
【図１】
2005196560.tif 000003
【図２】
2005196560.tif 000004
【図３】
2005196560.tif 000005
【図４】
2005196560.tif 000006
【図５】
2005196560.tif 000007
【図６】
2005196560.tif 000008
【図７】
2005196560.tif 000009
【図８】
2005196560.tif 000010
【図９】
2005196560.tif 000011
【図１０】
2005196560.tif 000012
【図１１】
2005196560.tif 000013
【図１２】
2005196560.tif 000014
【図１３】
2005196560.tif 000015
【図１４】
2005196560.tif 000016
【図１５】
2005196560.tif 000017
【図１６】
2005196560.tif 000018
【図１７】
2005196560.tif 000019
【図１８】
2005196560.tif 000020
【図１９】
2005196560.tif 000021
【図２０】
2005196560.tif 000022
【図２１】
2005196560.tif 000023
【図２２】
2005196560.tif 000024
【図２３】
2005196560.tif 000025
【図２４】
2005196560.tif 000026
【図２５】
2005196560.tif 000027
【図２６】
2005196560.tif 000028
【図２７】
2005196560.tif 000029
【図２８】
2005196560.tif 000030
【図２９】
2005196560.tif 000031
【図３０】
2005196560.tif 000032
【図３１】
2005196560.tif 000033
【図３２】
2005196560.tif 000034
【図３３】
2005196560.tif 000035