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

Description

本発明は外部装置に通信する技術に関する。

インターネット技術を利用したコンテンツ管理システムが普及してきている。ユーザは、クライアントからインターネットを介してサーバが開設しているＷｅｂページ上のコンテンツを操作することができる。クライアントはサーバのリソースをアドレスで指定しアクセスする。

特許文献１は、登録済みアドレスと自分のアドレスを比較し、一致したかどうかで処理を変える技術について開示している。また、特許文献１は図５に示すようにアドレスとしてＩＰアドレスによる表記を開示している。

特開平１１−２３７９９８

登録アドレスから情報処理装置と外部情報処理装置の通信方法を特定できる環境を想定する。

ここで、アドレスの表記形式は例えば、ＩＰアドレスによる表記や名前（ドメイン名・ホスト名）による表記など複数の表記形式がある。よって単純な文字列比較だけでは、登録アドレスと入力アドレスが同一の場所を指しているのか特定できない場合がある。このような場合に先の想定した環境では通信方法を特定できない虞がある。

本発明はこのような問題点に鑑みてなされたもので、ユーザにとって通信方法をより容易に特定可能にすることを目的とする。

上記の目的を達成するための本発明に係る情報処理装置は、
通信方法を特定するための第１のアドレスをＤＮＳサーバに問い合せることで第２のアドレスを取得する取得手段と、
前記第１のアドレスと前記第２のアドレスを一覧に登録する登録手段と、
通信先としてユーザから第３のアドレスを受け付ける受付手段と、
前記第３のアドレスが前記一覧に含まれているか否かを判断する判断手段と、
前記判断手段の判断に基づいて通信方法を特定し、特定された前記通信方法を用いて外部情報処理装置と通信する通信手段と、を有することを特徴とする。

本発明によれば、ユーザにとって通信方法を容易に特定できる。

システム構成、及びハードウェア構成の一例を示す図である。 情報処理装置のソフトウェアの構成の一例を示す図である。 メインＵＩの一例を示す図である。 ライブラリ登録設定画面の一例を示す図である。 ライブラリ情報のデータ構造の一例を示す図である。 リソース特定処理の一例を示す図である。 プラグインＡのライブラリ判別処理の一例を示す図である。 プラグインＢのライブラリ判別処理の一例を示す図である。 ショートカットのデータ構造の一例を示す図である。 ライブラリ情報設定処理の一例を示す図である。 プラグインＡのライブラリ識別処理の一例を示す図である。 プラグインＢのライブラリ識別処理の一例を示す図である。 ライブラリ情報のデータ構造の一例を示す図である。 リソース特定処理の一例を示す図である。 リソース特定処理の一例を示す図である。 入力アドレスをＤＮＳ問い合せする処理の一例を示す図である。

以下、本発明の実施形態について図面に基づいて説明する。なお、実施形態は、本発明を限定するものではなく、また、実施形態で説明されている全ての構成が本発明の課題を解決するための手段に必須であるとは限らない。

なお、本明細書ではＵＲＬやファイルパスなどのファイル及びフォルダの所在を特定できる情報をまとめてアドレスと記載する。すなわち、アドレスは後述する情報処理装置１０１上のファイルパスを指すこともあれば、情報処理装置１０１がネットワーク等を介して通信可能な外部情報処理装置のファイルやフォルダの所在を特定できる（ＵＲＬを含む）情報を指すこともある。また、情報処理装置１０１上のフォルダ及び情報処理装置１０１がネットワーク等を介して通信可能な外部情報処理装置のフォルダをライブラリと呼ぶ。

また、本明細書では一例として、プラグイン構造を持ち、プラグインモジュールを追加することで、様々な文書管理サーバへ通信可能なアプリケーションを想定する。また、プラグインモジュールごとに通信方法が異なる場合を想定する。

ここで本明細書の通信方法とは情報処理装置１０１が外部情報処理装置とファイル（あるいはデータ）をやりとりするための方法を意味する。

このようなアプリケーションにおいて、サーバリソースを一意に特定可能なアドレスを用いて、文書管理サーバへアクセスしようとする。そのとき、同じアドレス（例えば：ｈｔｔｐ：／／ｘｘｘ／ｙｙｙ／ｚｚｚ）であっても、サーバが提供している通信方法がＷｅｂＤＡＶやＲＥＳＴ，ＳＯＡＰなどと異なることがある場合を想定している。

＜第１の実施形態＞
［システム構成、及びハードウェア構成］
本実施形態に係るシステムの構成、及びハードウェア構成について図１を用いて説明する。図１は、システム構成、及びハードウェア構成の一例を示す図である。図１（ａ）を用いてシステム構成を説明する。情報処理装置（コンピュータ）１０１はネットワークに接続されており、ネットワークを介してインターネットに接続されている。ネットワーク／インターネットにはＤＮＳサーバ１１０、文書管理サーバ１１１及び文書管理サーバ１１２が接続されている。また本実施形態における情報処理装置１０１は、１台のみを示しているが、複数台であってもよい。また、ネットワーク、及びインターネットは、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。

さらに情報処理装置１０１は、各種のユニット（１０２〜１０７）を含んで構成される。本明細書ではＤＮＳサーバ１１０、文書管理サーバ１１１及び文書管理サーバ１１２も情報処理装置１０１と同じ構成である。

図１（ｂ）を用いて具体的に説明する。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０２は、各種のプログラムを実行し、プログラムに従って様々な機能を実現するユニットである。ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０４は、各種のプログラムやデータ等を記憶するユニットである。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３は、各種の情報を記憶するユニットである。また、ＲＡＭ１０３は、ＣＰＵ１０２の一時的な作業記憶領域としても利用されるユニットである。例えば、ＣＰＵ１０２は、ＲＯＭ１０４に記憶されているプログラムやデータをＲＡＭ１０３にロードしてプログラムを実行する。

Ｉｎｐｕｔ／Ｏｕｔｐｕｔインターフェース１０５は、情報処理装置１０１に接続されているディスプレイ（不図示）にデータを送信する他、ポインティングデバイス（不図示）からデータを受信するユニットである。

ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１０６は、情報処理装置１０１をネットワークに接続するためのユニットである。上述したユニットは、バス１０７を介してデータの送受信を行うことが可能に構成されている。

［ソフトウェア構成（全般）］
次に、情報処理装置１０１のソフトウェアの構成について図２を用いて説明する。図２は、情報処理装置１０１のソフトウェアの構成の一例を示す図である。

図２に示されるクライアントアプリ２００における機能を実現するプログラムは、情報処理装置１０１のＲＯＭ１０４等に記憶されている。即ち、ＣＰＵ１０２がＲＡＭ１０３にプログラムをロードして実行することで、装置の機能及び後述するフローチャートに係る処理が実現される。なお、装置の機能及び後述するフローチャートに係る処理の全部又は一部については専用のハードウェアを用いて実現してもよい。

［ソフトウェア構成（ＯＳ）］
次に、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）２１２について説明する。ＯＳ２１２は公知の一般的なＯＳの機能（メモリ管理、リソース管理、アプリケーション管理等）を提供する。ＯＳ２１２は、ショートカットやメニュー画面を介してユーザからのアプリケーション起動要求を受けると、アプリケーションに対して実行要求を出す。これによりアプリケーションは起動処理を開始する。

［ソフトウェア構成（クライアントアプリ）］
次に、クライアントアプリ２００におけるソフトウェアの構成について説明する。クライアントアプリ２００は、各種のモジュール（２０１〜２１１）を含んで構成される。

メイン制御部２０１は、クライアントアプリ２００を制御し、後述する各モジュール部に対する指示、管理を行う。情報表示部２０２は、メイン制御部２０１からの指示に従い、クライアントアプリ２００のＵＩをユーザに提供する。プラグイン管理部２０３は、クライアントアプリ２００の起動時に所定のフォルダ下に配置されたプラグイン部群（ここではプラグイン部Ａ２０６とプラグイン部Ｂ２０９）を判別し、管理する。なお本例では、プラグイン部Ａ２０６とプラグイン部Ｂ２０９で説明しているが、同様の構成のプラグインを所定のフォルダ下に配置・削除すれば、プラグインを追加・削除することが出来る。

ライブラリ判別部２０５は、情報表示部（２０２）に入力された値からライブラリ判別を行う。

プラグイン部Ａ２０６は、各種のモジュール（２０７、２０８）を含んで構成される。プラグイン部Ａライブラリ判別部２０７は、プラグイン部Ａ２０６固有のライブラリ判別を行う。プラグイン部Ａライブラリアクセス部２０８は、外部文書管理システムへのアクセス部である。また各プラグインはプラグインを一意に判別のためにライブラリ種別というプロパティ値を保持する。プラグイン部Ａ２０６のライブラリ種別は“ＡＡＡ Ｌｉｂｒａｒｙ”である。

プラグイン部Ｂ２０９は、プラグイン部Ａ２０６と同じ構成で成り立ち、各種のモジュール（２１０、２１１）を含んで構成される。プラグイン部Ｂライブラリ判別部２１０は、プラグイン部Ｂ２０９固有のライブラリ判別を行う。プラグイン部Ｂライブラリアクセス部２１１は、外部文書管理システムへのアクセス部である。プラグイン部Ｂ２０９のライブラリ種別は“ＢＢＢ Ｌｉｂｒａｒｙ”である。

図３は、クライアントアプリ２００のメインＵＩ３００の一例を示す図である。メニューバー３０１は、クライアントアプリ２００における設定値の入力を行うための項目（選択肢）を表示する。なお、クライアントアプリ２００のＵＩがユーザ操作されることで、後述するライブラリ登録等が行われる。

また、クライアントアプリ２００のＵＩの形態（位置、大きさ、範囲、配置、表示内容など）は、図に示す形態に限定されるものではなく、情報処理装置１０１の機能を実現することができる適宜の構成を採用することができる。

操作情報取得部（不図示）は、情報表示部２０２により表示されたクライアントアプリ２００のＵＩがユーザ操作された情報を取得し、取得した情報をメイン制御部２０１に通知する。メイン制御部２０１は適宜後述する記憶部２０４に情報を記憶する。

記憶部２０４は、情報表示部２０２及び操作情報取得部を介して、換言するならばクライアントアプリ２００のＵＩを介して、ユーザにより入力された設定値などを格納する。

Ｍａｎａｇｅｍｅｎｔボタン３０２は、後述するライブラリ管理画面４００を表示するためのボタンである。

ナビゲーションペイン３０３は、後述するライブラリ管理画面４００で登録した登録済みライブラリをＴｒｅｅ状に表示する。本例では、登録済みライブラリ１（”Ｌｉｂｒａｒｙ１”という登録名のライブラリ）３０４と登録済みライブラリ２（”Ｍｙ Ｌｉｂｒａｒｙ”という登録名のライブラリ）３０５がライブラリとして登録され、表示されていることを表している。

アドレスバー３０６は、ユーザが選択中のオブジェクトのアドレスを表示するテキストボックスである。さらにアドレスバー３０６にユーザがアドレスを入力することにより、そのアドレスに対応したリソース（フォルダやファイルを指す）を表示することもできる。なお、この時の処理については図６を用いて説明する際に詳細に述べる。

ファイルリストペイン３０７は、アドレスバーで入力されたアドレス、またはナビゲーションペイン３０３で選択されたフォルダオブジェクト下のフォルダやファイルを表示する。

プレビューペイン３０８は、ファイルリストペイン３０７で選択されたファイルのプレビュー画像を表示する。

プロパティペイン３０９は、ファイルリストペイン３０７で選択されたフォルダやファイルのプロパティ値を表示する。

図４（ａ）は、ライブラリ管理のＵＩを提供する画面の一例を示す図である。ライブラリ管理画面４００は、ライブラリに関するシステム設定を行うための画面であり、ユーザによりＭａｎａｇｅｍｅｎｔボタン３０２が押されると表示される。

登録ライブラリ一覧４０５は登録済みライブラリを一覧で表示する。

ライブラリ登録ボタン４０１は、ライブラリを登録するためのライブラリ選択画面（後述）を表示するためのボタンである。

登録情報変更ボタン４０２は、登録済みライブラリ（後述のライブラリ情報）を変更するためのボタンである。ユーザが登録ライブラリ一覧４０５で登録済みライブラリを選択し、登録情報変更ボタン４０２を押すと、登録ライブラリ情報変更画面（不図示）を表示し、ライブラリ情報を変更する。

登録解除ボタン４０３は、登録済みライブラリの登録を削除するためのボタンである。登録ライブラリ一覧４０５で登録済みライブラリを選択し、登録解除ボタン４０３を押すことで登録を削除することができる。

ＯＫボタン４０４を押すと、ライブラリ管理画面４００を閉じることができる。

図４（ｂ）は、ライブラリ選択のＵＩを提供する画面の一例を示す図である。ライブラリ選択画面４１０は、ライブラリを登録するためにライブラリ種別を選択するための画面である。登録可能ライブラリ一覧４１１は、登録可能なライブラリ（プラグイン部群）がプラグイン管理部２０３により読み取られ、その結果が一覧で表示されている。ユーザにより登録可能ライブラリ一覧４１１でライブラリ種別を選択し、ＯＫボタン４１２が押されると後述するライブラリ通信先設定画面４２０を表示する。キャンセルボタン４１３は、ライブラリ登録をキャンセルするためのボタンであり、キャンセルボタン４１３を押すと、ライブラリ管理画面４００に戻る。

図４（ｃ ）は、ライブラリ通信先設定のＵＩを提供する画面の一例を示す図である。ライブラリ通信先設定画面４２０は、ライブラリの通信先を設定するための画面である。アドレス入力テキストボックス４２１は、登録ライブラリのアドレス（後述の５０３、５０６）を入力するためのテキストボックス（受付部分）である。登録名入力テキストボックス４２２は、ライブラリの登録名（後述の５０４、５０７）を入力するためのテキストボックスである。ＯＫボタン４２３は、設定を決定するためのボタンである。ユーザによりＯＫボタン４２３が押されると、メイン制御部２０１は後述のライブラリ情報５００として設定値を記憶部２０４に保存する。キャンセルボタン４２４は、設定をキャンセルするためのボタンである。なお、アドレスが異なれば同一のライブラリ種別を複数設定することが可能である。

［データ構造（ライブラリ情報５００）］
次に、ライブラリ登録によって登録されるライブラリ情報のデータについて図５を用いて説明する。

図５は、ライブラリ情報５００のデータの一例（ライブラリ登録情報ＸＭＬ５０１）を示す図である。ライブラリ種別５０２、５０５は、ライブラリ選択画面４１０の登録可能ライブラリ一覧４１１で選択したライブラリ種別に対応する。アドレス５０３、５０６は、ライブラリ通信先設定画面４２０のアドレス入力テキストボックスに入力した値に対応する。登録名５０４、５０７は、登録名入力テキストボックス４２２に入力した値に対応する。ライブラリ情報５００は記憶部２０４で保持される。また登録情報Ａ５０８（５０２、５０３、５０４）は、プラグイン部Ａ２０６をライブラリとして登録した場合の例である。また、登録情報Ｂ５０９（５０５、５０６、５０７）は、プラグイン部Ｂ２０９をライブラリとして登録した場合の例である。

［リソース特定処理フロー］
図６は、クライアントアプリ２００がアドレスに対応したリソースへアクセスする処理に係るフローチャートの一例を示す図である。情報処理装置１０１のクライアントアプリ２００において、アドレスバー３０６にユーザが文字列（アドレス）を入力した時に、情報処理装置１０１のクライアントアプリ２００がアドレスに対応したリソースへアクセスする処理も図６の処理に基づいて行われる。

Ｓ６０１では、ユーザによるアドレスバー３０６への文字入力をトリガーに、クライアントアプリ２００のメイン制御部２０１は、操作情報取得部でアドレスバー３０６に入力された入力文字列を取得する。

Ｓ６０２では、メイン制御部２０１は、ライブラリ判別部２０５で入力文字列とライブラリ情報５００のアドレス５０３、５０６を部分文字列比較する。ここで部分文字列比較で一致するとは、例えば、入力文字列（“ｈｔｔｐ：／／ｘｘｘ．ｙｙｙ．ｚｚｚ／ｈｏｇｅ／ｈｏｇｅ”）の場合、アドレス５０３（“ｈｔｔｐ：／／ｘｘｘ．ｙｙｙ．ｚｚｚ”）との比較結果は一致する（Ｔｒｕｅ）である。また、入力文字列（“ｈｔｔｐ：／／１９２．１６８．０．１／ｈｏｇｅ／ｈｏｇｅ”）の場合、アドレス５０３（“ｈｔｔｐ：／／ｘｘｘ．ｙｙｙ．ｚｚｚ”）との比較結果は一致しない（Ｆａｌｓｅ）である。

なお、ここで文字列比較の方法としてはプロトコル種別を除いた上で文字列比較又は部分文字列比較を行うように構成しても構わない。先の例で言えば具体的には“ｘｘｘ．ｙｙｙ．ｚｚｚ”と“ｘｘｘ．ｙｙｙ．ｚｚｚ／ｈｏｇｅ／ｈｏｇｅ”を比較したり、さらにはプロトコル種別に加えてフォルダを除いて“１９２．１６８．０．１”と“ｘｘｘ．ｙｙｙ．ｚｚｚ”を比較したりするように構成しても構わない。

Ｓ６０３では、入力文字列とアドレス５０３の比較結果が一致（Ｔｒｕｅ）の場合、Ｓ６０４に処理を進め、他方、比較結果が一致しない（Ｆａｌｓｅ）の場合、Ｓ６０７に処理を進める。

（以下、登録情報Ａ５０８が一致した例で説明する）
Ｓ６０４では、メイン制御部２０１は、ライブラリ判別部２０５で一致したアドレス５０３のライブラリ種別５０２から対応したプラグイン部を判別する。登録情報Ａ５０８の場合は、ライブラリ種別５０２は“ＡＡＡ Ｌｉｂｒａｒｙ”であり、対応したプラグイン部は、プラグイン部Ａ２０６だと判別される。

Ｓ６０５では、プラグイン部Ａ２０６のプラグイン部Ａライブラリアクセス部２０８は通信方法としてＨＴＴＰあるいはＨＴＴＰＳを用いて文書管理サーバ１１１にアクセスし、入力文字列（アドレス）のリソース情報（フォルダやファイルに関する情報）を取得する。

ここでＳ６０４において、対応したプラグイン部がプラグイン部Ｂ２０９だと判別された場合について説明する。Ｓ６０５ではプラグイン部Ｂライブラリアクセス部２１１は通信方法としてＳＭＢあるいはＣＩＦＳを用いて文書管理サーバ１１２にアクセスし、入力文字列（アドレス）のリソース情報（フォルダやファイルに関する情報）を取得する。

Ｓ６０６では、メイン制御部２０１は、取得したリソース情報をメインＵＩ３００に表示する。その際、メインＵＩ３００のナビゲーションペイン３０３では、対応した登録済みライブラリ３０４が選択状態になり、ファイルリストペイン３０７は、ツリー上の対応したリソースのオブジェクトが選択状態（強調表示）になる。さらにオブジェクトが文書ファイルの場合、プレビューペイン３０８に文書ファイルのプレビューが表示される。さらにプロパティペイン３０９では、オブジェクトのプロパティが表示される。

これにより複数のライブラリがツリー上に表示されていたとしても、入力されたアドレスからどのライブラリに対応するアドレスなのかユーザは簡単に特定できる効果がある。

Ｓ６０７では、Ｓ６０３で一致しない（Ｆａｌｓｅ）になった場合、メイン制御部２０１は、ライブラリ情報５００として登録されている数（ライブラリ登録情報ＸＭＬ５０１の場合、２回）だけ、Ｓ６０８〜６１０を繰り返し処理する。

Ｓ６０８では、メイン制御部２０１は、ライブラリ種別をライブラリ情報５００から取得する。登録情報Ａ５０８の場合は、ライブラリ種別５０２“ＡＡＡ Ｌｉｂｒａｒｙ”であり、登録情報Ｂ５０９の場合は、ライブラリ種別５０５”ＢＢＢ Ｌｉｂｒａｒｙ”である。

Ｓ６０９では、ライブラリ種別が”ＡＡＡ Ｌｉｂｒａｒｙ”の場合、対応したプラグイン部Ａ２０６が決定され、ライブラリ種別が”ＢＢＢ Ｌｉｂｒａｒｙ”の場合、対応したプラグイン部Ｂ２０９が決定される。

Ｓ６１０では、各プラグイン（２０６、２０９）のライブラリ判別部（２０７、２１０）でライブラリ判別を行う。詳細なフローは後述する。

Ｓ６１１では、Ｓ６１０の比較結果が一致（Ｔｒｕｅ）の場合、Ｓ６０４に処理を進め、他方、比較結果が一致しない（Ｆａｌｓｅ）の場合、Ｓ６１２に処理を進める。

Ｓ６１２では、メイン制御部２０１は、エラーを表示する。

なお、Ｓ６０３で一致しない（Ｆａｌｓｅ）場合でかつＳ６１１で一致と判断した場合、Ｓ６０４からＳ６０６にかけてアドレスバーに表示するアドレスを入力文字列ではなく登録されたライブラリ情報のアドレスに変更しても構わない。

［プラグイン部Ａライブラリ判別部２０７におけるライブラリ判別処理フロー］
次に、Ｓ６１０におけるプラグイン部Ａ２０６のプラグイン部Ａライブラリ判別部２０７におけるライブラリ判別処理について図７を用いて説明する。図７は、プラグイン部Ａライブラリ判別部２０７におけるライブラリ判別処理フローチャートの一例を示す図である。

Ｓ７０１では、プラグイン部Ａライブラリ判別部２０７は、入力文字列（ここでは、例として”ｈｔｔｐ：／／１９２．１６８．０．１／ｈｏｇｅ／ｈｏｇｅ”で説明する）が、プラグインＡとして許容できるかどうかを判別する。つまり、文書管理サーバ１１１にアクセスするアドレスとして適切かどうかを判別する。プラグイン部Ａライブラリ判別部２０７では、入力文字列のＰｒｅｆｉｘが”ｈｔｔｐ：／／” または”ｈｔｔｐｓ：／／”であるかを判別している。一致した場合、Ｓ７１０に処理を進め、他方、一致しなかった場合、処理を終了する。

Ｓ７１０では、プラグイン部Ａライブラリ判別部２０７は後述するＳ７１１のＤＮＳサーバ１１０の問い合わせ結果のキャッシュがあるかどうかを判断する。あると判断した場合はＳ７０３に進み、ないと判断した場合はＳ７０２に進む。

Ｓ７０２では、プラグイン部Ａライブラリ判別部２０７は、アドレス５０３（“ｈｔｔｐ：／／ｘｘｘ．ｙｙｙ．ｚｚｚ”）をＤＮＳサーバ１１０に問い合わせする。（ここで、ＤＮＳサーバ１１０問い合わせ結果として”ｘｘｘ．ｙｙｙ．ｚｚｚ”＝ ”１９２．１６８．０．１”とする） 。ＤＮＳサーバ１１０に問い合せることで異なる表記形式のアドレスを取得することが可能となる。

なお、ＤＮＳサーバ１１０に問い合わせても一定時間内に結果が返ってこない場合はタイムアウトしてＳ７０３の処理を行わずに終了する。この場合は後述するＳ７０３の判断の結果、アドレスは一致しないと判断したとみなされる。

Ｓ７１１では、プラグイン部Ａライブラリ判別部２０７は、Ｓ７０２でＤＮＳサーバ１１０に問い合せることで取得した異なる表記形式のアドレスをキャッシュする。

ここからは図７及び図８の処理で共通の事項を説明する。

本明細書ではＤＮＳサーバ１１０からアドレスを取得する際にＤＮＳサーバ１１０が一つのアドレスに対して複数の異なる表記形式のアドレスを有していても、複数の異なる表記形式のアドレスのうち情報処理装置１０１は一つのアドレスのみを取得する。これによりＤＮＳサーバ１１０に問い合わせる処理を高速に行うことができる。しかし、複数の異なる表記形式のアドレスを全て取得するように構成しても構わない。

また、ＤＮＳサーバ１１０に問合せを試みた結果、ＤＮＳサーバ１１０と通信を確立できなかった場合は当然異なる表記形式のアドレスを取得できない。よって、ＤＮＳサーバ１１０と通信を確立できなかった場合はアドレスのキャッシュを行わない。ここで、通信を確立できなかったときに問い合わせようとしたアドレスと同じアドレスをＤＮＳサーバ１１０に次回以降問合せる必要があるとする。この場合は再度ＤＮＳサーバ１１０との通信の確立を試みて、通信が確立した場合に異なる表記形式のアドレスの取得を試みることができる。すなわち、図７の処理であればＳ７１０でキャッシュがないと判断して、Ｓ７０２に進み再度ＤＮＳサーバ１１０に問合せを行う。

なお、ＤＮＳサーバ１１０に問合せを行っても異なる表記形式のアドレスが存在せず、異なる表記形式のアドレスを取得できなかった場合は異なる表記形式のアドレスを取得できなかったことを示す情報もキャッシュするように構成しても構わない。このように構成した場合では異なる表記形式のアドレスを取得できなかったことを示す情報がある場合はＤＮＳサーバ１１０への問合せを行わない。また、この場合も図７の処理であれば後述するＳ７０３の判断の結果、アドレスは一致しないと判断したとみなされる。

これで図７及び図８の処理で共通の事項の説明を終える。

Ｓ７０３では、プラグイン部Ａライブラリ判別部２０７は、入力文字列（”ｈｔｔｐ：／／１９２．１６８．０．１／ｈｏｇｅ／ｈｏｇｅ”）と、ＤＮＳサーバ１１０問い合わせ結果を加味したアドレス５０３（“ｈｔｔｐ：／／ １９２．１６８．０．１”）の部分文字列比較を行い、一致（Ｔｒｕｅ），一致しない（Ｆａｌｓｅ）を判別する。

［ライブラリ判別部２１０におけるライブラリ判別処理フロー］
次に、Ｓ６１０におけるプラグイン部Ｂ２０９のライブラリ判別部２１０におけるライブラリ判別処理について図８を用いて説明する。図８は、ライブラリ判別部２１０におけるライブラリ判別処理フローチャートの一例を示す図である。

Ｓ８０１では、プラグイン部Ｂライブラリ判別部２１０は、入力文字列（ここでは、例”￥￥１９２．１６８．０．２￥ｘｘｘ￥ｙｙｙ”で説明する）が、プラグイン部Ｂ２０９として許容できるかどうかを判別する。つまりは、文書管理サーバ１１２にアクセスするアドレスとして適切かどうかを判別する。プラグイン部Ｂライブラリ判別部２１０では、入力文字列のＰｒｅｆｉｘが”ｆｉｌｅ：／／／” または”￥￥”、”＊：／／”であるかを判別している。一致した場合、Ｓ８０２に処理を進め、他方、一致しなかった場合、処理を終了する。

Ｓ８０２では、プラグイン部Ｂライブラリ判別部２１０は、アドレス５０６（“ｆｉｌｅ：／／／ｚ：ｘｘｘ”）がネットワーク割り当て行われているかどうかを情報処理装置１０１のＯＳ２１２に確認する。すなわち、ＯＳのドライブレター（この場合はｚドライブ）に対してネットワークパスを割り振っているかどうかを確認する。ネットワーク割り当てが行われていれば、Ｓ８０３に処理をすすめ、割り当たっていなければ、Ｓ８０４に処理を進める。

Ｓ８０３では、プラグイン部Ｂライブラリ判別部２１０は、ネットワークリソース名をＯＳから取得する。（ここで、ｚドライブは”￥￥ａａａ．ｂｂｂ．ｃｃｃ”に割り当たっているとする）。

Ｓ８１０ではプラグイン部Ａライブラリ判別部２０７は後述するＳ７１１のＤＮＳサーバ１１０の問い合わせ結果のキャッシュがあるかどうかを判断する。あると判断した場合はＳ８０５に進み、ないと判断した場合はＳ８０４に進む。

Ｓ８０４では、プラグイン部Ｂライブラリ判別部２１０は、アドレス５０６（“”￥￥ａａａ．ｂｂｂ．ｃｃｃ￥ｘｘｘ”）をＤＮＳサーバ１１０に問い合わせする。（ここで、ＤＮＳサーバ１１０問い合わせ結果として”ａａａ．ｂｂｂ．ｃｃｃ”＝ ”１９２．１６８．０．２”とする。）
なお、ＤＮＳサーバ１１０に問い合わせても一定時間内に結果が返ってこない場合はタイムアウトしてＳ８０４の処理を行わずに終了する。この場合は後述するＳ８０５の判断の結果一致しないと判断したとみなされる。

Ｓ８１１では、プラグイン部Ａライブラリ判別部２０７は、Ｓ８０４でＤＮＳサーバ１１０に問い合せることで取得した異なる表記形式のアドレスをキャッシュする。

Ｓ８０５では、プラグイン部Ｂライブラリ判別部２１０は、入力文字列（”￥￥１９２．１６８．０．２￥ｘｘｘ￥ｙｙｙ”）と、ＤＮＳサーバ１１０問い合わせ結果を加味したアドレス５０３（“￥￥１９２．１６８．０．１￥ｘｘｘ”）の部分文字列比較を行い、一致（Ｔｒｕｅ），一致しない（Ｆａｌｓｅ）を判別する。

なお、ここで文字列比較の方法としてはＳ６０２で説明したように、プロトコル種別やＰｒｅｆｉｘを除いた上で文字列比較又は部分文字列比較を行うように構成しても構わない。あるいはプロトコル種別やＰｒｅｆｉｘに加えてフォルダを除いた上で文字列比較又は部分文字列比較を行うように構成しても構わない。

また、図６、７，８では、アドレスバー３０６へのユーザの文字入力をトリガーに処理が開始されたが、ユーザからのショートカットのダブルクリックをトリガーにしても同一の処理が行われる。

図９は、ショートカットファイルのデータ構造の一例を説明する図である。ショートカットファイル９０１はＸＭＬフォーマットで内容が記述されており、アドレス９０２は文書管理サーバにアクセスするアドレスである。

ユーザがショートカットファイル９０１をダブルクリックすると、ＯＳは、ショートカットファイルの拡張子を判別し、関連づけられたアプリケーション（ここではクライアントアプリ２００）を起動する。クライアントアプリ２００のメイン制御部２０１は、ショートカットファイル９０１からアドレス９０２を読み取り、Ｓ６０２へと処理を進める。以下は同様の処理が行われる。

以上のように、入力文字列とライブラリ情報５００のアドレスの単純な文字列比較（Ｓ６０３）だけでなく、各プラグイン（２０６、２０９）のライブラリ判別部（２０７、２１０）で、プラグイン固有の比較処理を行うことにより、入力文字列が適切なＵＲＩかどうかを判別することが出来る。さらにＵＲＩに対する適切な通信方法（２０８、２１１）を決定することが出来る。このような処理により、より容易に文書管理サーバへ通信可能になるため、アプリケーションをより簡易に利用可能にすることができる。

＜第２の実施形態＞
本実施形態では、第１の実施形態と同一の構成については同一の符号を用い、その説明を適宜省略する。

ライブラリ通信先設定時に、図４（ｃ）のライブラリ通信先設定画面４２０で、ユーザが登録ライブラリのアドレス、ライブラリの登録名を入力し、ＯＫボタン４２３を押されたことをトリガーとし、以下ライブラリ情報設定処理が実行される。

［ライブラリ情報設定処理フロー］
情報処理装置１０１のクライアントアプリ２００におけるライブラリ情報設定処理について図１０を用いて説明する。図１０は、クライアントアプリ２００がライブラリ情報設定処理に係るフローチャートの一例を示す図である。

Ｓ１００１では、ユーザによりＯＫボタン４２３が押されると、クライアントアプリ２００のメイン制御部２０１は、図４（ｂ）の登録可能ライブラリ一覧４１１で選択したライブラリ種別を取得する。（本例では、“ＡＡＡ Ｌｉｂｒａｒｙ”また”ＢＢＢ Ｌｉｂｒａｒｙ”である。）
Ｓ１００２では、ライブラリ識別が”ＡＡＡ Ｌｉｂｒａｒｙ”の場合、対応したプラグイン部Ａ２０６が決定され、ライブラリ識別が”ＢＢＢ Ｌｉｂｒａｒｙ”の場合、対応したプラグイン部Ｂ２０９が決定される。

Ｓ１００３では、各プラグイン（２０６、２０９）のライブラリ判別部（２０７、２１０）でライブラリ識別を行う。詳細なフローは後述する。

［ライブラリ判別部２０７におけるライブラリ識別処理フロー］
次に、Ｓ１００３におけるプラグイン部Ａ２０６のライブラリ判別部２０７におけるライブラリ識別処理について図１１を用いて説明する。図１１は、ライブラリ判別部２０７におけるライブラリ識別処理フローチャートの一例を示す図である。

Ｓ１１０１では、プラグイン部Ａライブラリ判別部２０７は、入力文字列（ここでは、”ｈｔｔｐ：／／ｘｘｘ．ｙｙｙ．ｚｚｚ”で説明する）をＤＮＳサーバ１１０に問い合わせする。（ここで、ＤＮＳサーバ１１０問い合わせ結果として”ｘｘｘ．ｙｙｙ．ｚｚｚ”＝ ”１９２．１６８．０．１”とする。）
Ｓ１１０２では、プラグイン部Ａライブラリ判別部２０７は、後述のライブラリ情報１３００（登録情報Ａ１３０７）を保存する。

［ライブラリ判別部２１０におけるライブラリ識別処理フロー］
次に、Ｓ１００３におけるプラグイン部Ｂ２０９のライブラリ判別部２１０におけるライブラリ識別処理について図１２を用いて説明する。図１２は、ライブラリ判別部２１０におけるライブラリ識別処理フローチャートの一例を示す図である。

Ｓ１２０１では、プラグイン部Ｂライブラリ判別部２１０は、入力文字列（ここでは、”ｆｉｌｅ：／／／ｚ：／ｘｘｘ”で説明する）がネットワーク割り当て行われているかどうかをＯＳに確認する。ネットワーク割り当てが行われていれば、Ｓ１２０２に処理をすすめ、割り当たっていなければ、Ｓ１２０３に処理を進める。

Ｓ１２０２では、プラグイン部Ｂライブラリ判別部２１０は、ネットワークリソース名を取得する。（ここで、ｚドライブは”￥￥ａａａ．ｂｂｂ．ｃｃｃ”に割り当たっているとする）
Ｓ１２０３では、プラグイン部Ｂライブラリ判別部２１０は、（“￥￥ａａａ．ｂｂｂ．ｃｃｃ”）をＤＮＳサーバ１１０に問い合わせする。（ここで、ＤＮＳサーバ１１０問い合わせ結果として”ａａａ．ｂｂｂ．ｃｃｃ”＝ ”１９２．１６８．０．２”とする。）
Ｓ１２０４では、プラグイン部Ｂライブラリ判別部２１０は、後述のライブラリ情報１３００（登録情報Ｂ１３０８）を保存する。

［データ構造（ライブラリ情報１３００）］
次に、ライブラリ登録によって登録されるライブラリ情報のデータについて図１３を用いて説明する。

図１３は、ライブラリ情報１３００のデータの一例（ライブラリ登録情報ＸＭＬ１３０１）を示す図である。ライブラリ種別５０２、５０５は、ライブラリ選択画面４１０の登録可能ライブラリ一覧４１１で選択したライブラリ種別に対応する。登録名５０４、５０７は、登録名入力テキストボックス４２２に入力した値に対応する。アドレス１３０２は、ライブラリ通信先設定画面４２０のアドレス入力テキストボックスに入力した値に対応する。アドレス１３０３は、Ｓ１１０１で、ＤＮＳサーバ１１０問い合わせを行った結果の値に対応する。また、アドレス１３０４は、ライブラリ通信先設定画面４２０のアドレス入力テキストボックスに入力した値に対応する。アドレス１３０５は、Ｓ１２０２で、ネットワークリソース名問い合わせを行った結果の値に対応する。アドレス１３０６は、Ｓ１２０３で、ＤＮＳサーバ１１０問い合わせを行った結果の値に対応する。

ライブラリ情報１３００は記憶部２０４で保持される。また登録情報Ａ１３０７（５０２、１３０２、１３０３、５０４）は、プラグイン部Ａ２０６をライブラリとして登録した場合の例である。また、登録情報Ｂ１３０８（５０５、１３０４、１３０５、１３０６、５０７）は、プラグイン部Ｂ２０９をライブラリとして登録した場合の例である。

［リソース特定処理フロー］
情報処理装置１０１のクライアントアプリ２００において、アドレスバー３０６にユーザが文字列（アドレス）を入力した時に、情報処理装置１０１のクライアントアプリ２００がアドレスに対応したリソースへアクセスする処理について図１４を用いて説明する。図１４は、クライアントアプリ２００がアドレスに対応したリソースへアクセスする処理に係るフローチャートの一例を示す図である。

Ｓ１４０１では、メイン制御部２０１はライブラリ情報１３００に対して見つかったアドレスの追加を行う。例えば”Ｌｉｂｒａｒｙ１”というライブラリに登録されているＵＲＬがｈｔｔｐ：／／ｘｘｘ．ｙｙｙ．ｚｚｚであり、ＤＮＳサーバ１１０からｘｘｘ．ｙｙｙ．ｚｚｚの問い合わせ結果として１９２．１６８．０．１というＩＰアドレスを取得したとする。この場合は”Ｌｉｂｒａｒｙ１”のＵＲＬの候補として１９２．１６８．０．１を追加する。これによりライブラリ情報１３００の更新が行われる。

以上のように、登録時に問い合わせを行い保持しておき、変更があった場合にライブラリ情報１３００にアドレスを追加することにより、毎回ＤＮＳサーバ１１０問い合わせを行う必要がなくなるため、問い合わせ回数を減らすことができ、パフォーマンス向上に繋がる。

なお、ライブラリ情報１３００の更新とは別に、ライブラリに登録されているＵＲＬやＤＮＳサーバ１１０の問い合わせ結果をメモリ上でキャッシュするように構成しても構わない。特にＤＮＳサーバ１１０の問い合わせ結果をメモリ上でキャッシュすることで、クライアントアプリ２００を起動している間は、ＤＮＳサーバ１１０へ何度も問い合わせることを防ぐことができる。

＜第３の実施形態＞
本実施形態では、第１の実施形態と同一の構成については同一の符号を用い、その説明を適宜省略する。

［リソース特定処理フロー］
情報処理装置１０１のクライアントアプリ２００において、アドレスバー３０６にユーザが文字列（アドレス）を入力した時に、情報処理装置１０１のクライアントアプリ２００がアドレスに対応したリソースへアクセスする処理について図１５を用いて説明する。図１５は、クライアントアプリ２００がアドレスに対応したリソースへアクセスする処理に係るフローチャートの一例を示す図である。

Ｓ１５０１では、メイン制御部２０１は、ユーザによるアドレスバー入力による入力文字列（直接入力）なのかどうかを判別する。ユーザによりアドレスバー入力が行われたと判断された場合は、Ｓ６０７へ処理を進め、その他の場合は、Ｓ１５０２に処理を進める。

Ｓ１５０２では、メイン制御部２０１は、ショートカット起動からの入力文字列判別なのかどうかを判別する。ショートカット起動からの場合は、Ｓ６０７へ処理を進め、その他の場合は、Ｓ６１２に処理を進める。

以上のように、ユーザによるアドレス入力からの問い合わせなのか、あるいはショートカット起動によるアドレス問い合わせなのかを判断し、それ以外の場合に比較処理を行わないことにより、各プラグインの比較処理を減らすことが出来るので、パフォーマンス向上に繋がる。

＜第４の実施形態＞
例えばユーザの使用方法によっては登録ライブラリに登録されたアドレスがＩＰアドレスによる表記であり、逆にアドレスバー３０６に入力されたアドレスが名前（ドメイン名・ホスト名）による表記である状況も存在しうる。本実施形態ではこのような状況でもライブラリを特定する方法について記載する。

なお、本実施形態では、第１の実施形態と同一の構成については同一の符号を用い、その説明を適宜省略する。

［リソース特定処理フロー］
図１６を用いて具体的な処理について説明する。

Ｓ１６０１でアドレスバー３０６に入力されたアドレスをＤＮＳサーバ１１０に問い合わせる。

Ｓ１６０２でアドレスバー３０６に入力されたアドレスとＳ１６０１でＤＮＳサーバ１１０に問い合わせた結果取得したアドレスの２つのアドレスと登録済みライブラリ情報に含まれているアドレスを部分文字列比較する。

Ｓ１６０３で２つのアドレスのうち少なくとも１つのアドレスが登録済みライブラリ情報のアドレスと一致するかどうかを判断する。一致すると判断した場合はＳ６０４に進み、一致しないと判断した場合はＳ１６０４に進む。

Ｓ１６０４ではＳ６１０の比較の結果、一致するかどうかを判断する。

なお、図１６による処理を行う際は図７のＳ７０３及び図８のＳ８０５の比較では２つのアドレスのうち少なくとも１つのアドレスが、Ｓ７０２又はＳ８０４のＤＮＳサーバ１１０への問い合せの結果取得したアドレスと一致するのかどうかを判断する。

なお、アドレスバー３０６に入力されたアドレスをＤＮＳサーバ１１０に問い合わせるタイミングは比較の前であればいつでも構わない。例えばＳ１６０１の代わりに図７のＳ７０２と図８のＳ８０４と同じタイミングで問い合わせても構わない。

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

上述した実施形態の構成によれば、情報処理装置をより容易に利用可能にすることができる。

Claims (11)

1. 通信方法を特定するための第１のアドレスをＤＮＳサーバに問い合せることで第２のアドレスを取得する取得手段と、
   前記第１のアドレスと前記第２のアドレスを一覧に登録する登録手段と、
   通信先としてユーザから第３のアドレスを受け付ける受付手段と、
   前記第３のアドレスが前記一覧に含まれているか否かを判断する判断手段と、
   前記判断手段の判断に基づいて通信方法を特定し、特定された前記通信方法を用いて外部情報処理装置と通信する通信手段と、を有することを特徴とする情報処理装置。
2. 前記取得手段は、前記第３のアドレスをＤＮＳサーバに問い合せることで第４のアドレスを取得し、
   前記情報処理装置はさらに、前記第１のアドレスと前記第４のアドレスが一致するかを判断する第２の判断手段を有し、
   前記通信手段は、前記第２の判断手段がアドレスは一致すると判断した場合に通信方法を特定し、特定された前記通信方法を用いて通信することを特徴とする請求項１に記載の情報処理装置。
3. 前記取得手段は、通信方法を特定するための第５のアドレスをＤＮＳサーバに問い合せることで第６のアドレスを取得し、
   前記登録手段は、前記第１のアドレス及び前記第２のアドレスを第１の一覧として登録して、前記第５のアドレス及び前記第６のアドレスを第２の一覧として登録し、
   前記判断手段は前記第３のアドレスが前記第１の一覧又は前記第２の一覧に含まれているかを判断し、前記判断手段の判断の結果、前記第３のアドレスが前記第１の一覧に含まれている場合に第１の通信方法を用いて通信して、前記第３のアドレスが前記第２の一覧に含まれている場合に第２の通信方法を用いて通信することを特徴とする請求項１又は請求項２に記載の情報処理装置。
4. 前記取得手段はアドレスのネットワークリソース名を取得して、取得したネットワークリソース名を用いてＤＮＳサーバに問い合せることで前記第２のアドレスを取得することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記取得手段が前記第２のアドレスを取得した場合に前記一覧を含む登録ライブラリ情報を更新する更新手段と、を有し、
   前記判断手段は前記登録ライブラリ情報に基づいて前記第３のアドレスが前記一覧に含まれているか否かを判断することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. コンピュータに、
   通信方法を特定するための第１のアドレスをＤＮＳサーバに問い合せることで第２のアドレスを取得する取得工程と、
   前記第１のアドレスと前記第２のアドレスを一覧に登録する登録工程と、
   通信先としてユーザから第３のアドレスを受け付ける受付工程と、
   前記第３のアドレスが前記一覧に含まれているか否かを判断する判断工程と、
   前記判断工程の判断に基づいて通信方法を特定し、特定された前記通信方法を用いて外部コンピュータと通信する通信工程と、を実行させることを特徴とするプログラム。
7. 前記取得工程は、前記第３のアドレスをＤＮＳサーバに問い合せることで第４のアドレスを取得し、
   前記コンピュータにさらに、前記第１のアドレスと前記第４のアドレスが一致するかを判断する第２の判断工程を実行させ、
   前記通信工程は、前記第２の判断工程でアドレスは一致すると判断した場合に通信方法を特定し、特定された前記通信方法を用いて通信することを特徴とする請求項６に記載のプログラム。
8. 前記取得工程は、通信方法を特定するための第５のアドレスをＤＮＳサーバに問い合せることで第６のアドレスを取得し、
   前記登録工程は、前記第１のアドレス及び前記第２のアドレスを第１の一覧として登録して、前記第５のアドレス及び前記第６のアドレスを第２の一覧として登録し、
   前記判断工程は前記第３のアドレスが前記第１の一覧又は前記第２の一覧に含まれているかを判断し、
   前記通信工程は、前記判断工程の判断の結果、前記第３のアドレスが前記第１の一覧に含まれている場合に第１の通信方法を用いて通信して、前記第３のアドレスが前記第２の一覧に含まれている場合に第２の通信方法を用いて通信することを特徴とする請求項６又は請求項７に記載のプログラム。
9. 前記取得工程はアドレスのネットワークリソース名を取得して、取得したネットワークリソース名を用いてＤＮＳサーバに問い合せることで前記第２のアドレスを取得することを特徴とする請求項６乃至８のいずれか１項に記載のプログラム。
10. 前記コンピュータにさらに、前記取得工程で前記第２のアドレスを取得した場合に前記一覧を含む登録ライブラリ情報を更新する更新工程、を実行させ、
    前記判断工程は前記登録ライブラリ情報に基づいて前記第３のアドレスが前記一覧に含まれているか否かを判断することを特徴とする請求項６乃至９のいずれか１項に記載のプログラム。
11. 通信方法を特定するための第１のアドレスをＤＮＳサーバに問い合せることで第２のアドレスを取得する取得工程と、
    前記第１のアドレスと前記第２のアドレスを一覧に登録する登録工程と、
    通信先としてユーザから第３のアドレスを受け付ける受付工程と、
    前記第３のアドレスが前記一覧に含まれているか否かを判断する判断工程と、
    前記判断工程の判断に基づいて通信方法を特定し、特定された前記通信方法を用いて外部情報処理装置と通信する通信工程と、を有することを特徴とする制御方法。

Images