(57)【特許請求の範囲】
【請求項１】
演算装置であるＣＰＵと、プログラムが展開されるメモリと、キーボードを含む入力装置と、画面を表示する表示装置と、外部との通信回線と、を備える情報処理装置であって、
前記ＣＰＵにより前記プログラムが実行されることにより実現される機能部としての制御部であって、サーバーから前記通信回線を介して電子文書としてのフロー定義を取得し、前記フロー定義の内容に基づいて全体処理を制御する制御部と、
前記ＣＰＵにより前記プログラムが実行されることにより実現される機能部としての画面制御部であって、前記表示装置に表示される複数の構成要素のそれぞれを生成する複数の構成要素生成部に前記構成要素を生成させる画面生成部と前記表示装置に前記構成要素を表示させる画面表示部と前記表示装置における前記構成要素の表示を停止させる画面非表示部とを有し、サーバーから前記通信回線を介して前記表示装置における前記構成要素の表示を規定する電子文書としての画面定義を取得し、前記画面定義に従って前記構成要素生成部に前記構成要素を生成させ、前記画面表示部に生成された前記構成要素の表示を行わせたり前記画面非表示部に前記構成要素の表示を停止させたりする画面制御部と、
前記ＣＰＵにより前記プログラムが実行されることにより実現される機能部としてのデータアイテム管理部であって、前記複数の構成要素生成部の各々と所定の対応関係を有する複数のデータアイテムを記憶するデータアイテムテーブルを有するデータアイテム管理部と、
前記複数の構成要素生成部のそれぞれと前記データアイテムとの対応関係を設定して前記データアイテムテーブルに登録する設定部と、を備え、
前記構成要素は、ボタンや線を含む表示画面を構成する画面要素と、四則演算や前記入力装置の入力チェックを含む画面内でのデータの処理を行うロジック要素と、から構成され、
前記データアイテム管理部は、前記入力装置により前記データアイテムの値が対応する前記構成要素生成部に前記構成要素を生成させる値として予め設定された所定値に変更された場合に、前記データアイテムの値が前記所定値と等しくなったことを前記画面制御部に通知し、
前記画面制御部は、前記通知の対象の前記データアイテムと対応付けられた前記構成要素生成部に前記構成要素を生成させると共に、前記画面表示部に生成された前記構成要素を前記表示装置に表示させる、情報処理装置。
【請求項２】
演算装置であるＣＰＵと、プログラムが展開されるメモリと、キーボードを含む入力装置と、画面を表示する表示装置と、外部との通信回線と、を備える情報処理装置であって、
前記ＣＰＵにより前記プログラムが実行されることにより実現される機能部としての制御部であって、サーバーから前記通信回線を介して電子文書としてのフロー定義を取得し、前記フロー定義の内容に基づいて全体処理を制御する制御部と、
前記ＣＰＵにより前記プログラムが実行されることにより実現される機能部としての画面制御部であって、前記表示装置に表示される複数の構成要素のそれぞれを生成する複数の構成要素生成部に前記構成要素を生成させる画面生成部と前記表示装置に前記構成要素を表示させる画面表示部と前記表示装置における前記構成要素の表示を停止させる画面非表示部とを有し、サーバーから前記通信回線を介して前記表示装置における前記構成要素の表示を規定する電子文書としての画面定義を取得し、前記画面定義に従って前記構成要素生成部に前記構成要素を生成させ、前記画面表示部に生成された前記構成要素の表示を行わせたり前記画面非表示部に前記構成要素の表示を停止させたりする画面制御部と、
前記ＣＰＵにより前記プログラムが実行されることにより実現される機能部としてのデータアイテム管理部であって、前記複数の構成要素生成部の各々と所定の対応関係を有する複数のデータアイテムを記憶するデータアイテムテーブルを有するデータアイテム管理部と、
前記複数の構成要素生成部のそれぞれと前記データアイテムとの対応関係を設定して前記データアイテムテーブルに登録する設定部と、を備え、
前記構成要素は、ボタンや線を含む表示画面を構成する画面要素と、四則演算や前記入力装置の入力チェックを含む画面内でのデータの処理を行うロジック要素と、から構成され、
前記データアイテム管理部は、前記入力装置により前記データアイテムの値が対応する前記構成要素生成部に前記構成要素を生成させる値として予め設定された所定値に変更された場合に、前記データアイテムの値が前記所定値と等しくなったことを前記画面制御部に通知し、
前記画面制御部は、前記通知の対象の前記データアイテムと対応付けられた前記構成要素生成部に前記構成要素を生成させると共に、前記画面表示部に生成された前記構成要素を前記表示装置に表示させ、
前記データアイテム管理部は、前記構成要素生成部に前記構成要素を生成させるために必要な前記データアイテムが前記データアイテムテーブルに登録されているか否かの検索を行い、登録されていない場合には前記データアイテムを生成する手段を有する、情報処理装置。
【請求項３】
演算装置であるＣＰＵと、プログラムが展開されるメモリと、キーボードを含む入力装置と、画面を表示する表示装置と、外部との通信回線と、を備えるコンピュータに所定の情報処理を行わせるためのコンピュータプログラムであって、
サーバーから前記通信回線を介して電子文書としてのフロー定義を取得し、前記フロー定義の内容に基づいて全体処理を制御する制御機能と、
前記表示装置に表示される複数の構成要素のそれぞれを生成する複数の構成要素生成機能に前記構成要素を生成させる画面生成機能と前記表示装置に前記構成要素を表示させる画面表示機能と前記表示装置における前記構成要素の表示を停止させる画面非表示機能とを有し、サーバーから前記通信回線を介して前記表示装置における前記構成要素の表示を規定する電子文書としての画面定義を取得し、前記画面定義に従って前記構成要素生成機能に前記構成要素を生成させ、前記画面表示機能に生成された前記構成要素の表示を行わせたり前記画面非表示機能に前記構成要素の表示を停止させたりする画面制御機能と、
前記複数の構成要素生成機能の各々と所定の対応関係を有する複数のデータアイテムを記憶するデータアイテムテーブルを有するデータアイテム管理機能と、
前記複数の構成要素生成機能のそれぞれと前記データアイテムとの対応関係を設定して前記データアイテムテーブルに登録する設定機能と、を、前記コンピュータに実現させ、
前記構成要素は、ボタンや線を含む表示画面を構成する画面要素と、四則演算や前記入力装置の入力チェックを含む画面内でのデータの処理を行うロジック要素と、から構成され、
前記データアイテム管理機能は、前記入力装置により前記データアイテムの値が対応する前記構成要素生成機能に前記構成要素を生成させる値として予め設定された所定値に変更された場合に、前記データアイテムの値が前記所定値と等しくなったことを前記画面制御部に通知する機能であり、
前記画面制御機能は、前記通知の対象の前記データアイテムと対応付けられた前記構成要素生成機能に前記構成要素を生成させると共に、前記画面表示機能に生成された前記構成要素を前記表示装置に表示させる機能である、コンピュータプログラム。
【請求項４】
演算装置であるＣＰＵと、プログラムが展開されるメモリと、キーボードを含む入力装置と、画面を表示する表示装置と、外部との通信回線と、を備えるコンピュータに所定の情報処理を行わせるためのコンピュータプログラムであって、
サーバーから前記通信回線を介して電子文書としてのフロー定義を取得し、前記フロー定義の内容に基づいて全体処理を制御する制御機能と、
前記表示装置に表示される複数の構成要素のそれぞれを生成する複数の構成要素生成機能に前記構成要素を生成させる画面生成機能と前記表示装置に前記構成要素を表示させる画面表示機能と前記表示装置における前記構成要素の表示を停止させる画面非表示機能とを有し、サーバーから前記通信回線を介して前記表示装置における前記構成要素の表示を規定する電子文書としての画面定義を取得し、前記画面定義に従って前記構成要素生成機能に前記構成要素を生成させ、前記画面表示機能に生成された前記構成要素の表示を行わせたり前記画面非表示機能に前記構成要素の表示を停止させたりする画面制御機能と、
前記複数の構成要素生成機能の各々と所定の対応関係を有する複数のデータアイテムを記憶するデータアイテムテーブルを有するデータアイテム管理機能と、
前記複数の構成要素生成機能のそれぞれと前記データアイテムとの対応関係を設定して前記データアイテムテーブルに登録する設定機能と、を、前記コンピュータに実現させ、
前記構成要素は、ボタンや線を含む表示画面を構成する画面要素と、四則演算や前記入力装置の入力チェックを含む画面内でのデータの処理を行うロジック要素と、から構成され、
前記データアイテム管理機能は、前記入力装置により前記データアイテムの値が対応する前記構成要素生成機能に前記構成要素を生成させる値として予め設定された所定値に変更された場合に、前記データアイテムの値が前記所定値と等しくなったことを前記画面制御部に通知する機能であり、
前記画面制御機能は、前記通知の対象の前記データアイテムと対応付けられた前記構成要素生成機能に前記構成要素を生成させると共に、前記画面表示機能に生成された前記構成要素を前記表示装置に表示させる機能であり、
前記データアイテム管理機能は、前記構成要素生成機能に前記構成要素を生成させるために必要な前記データアイテムが前記データアイテムテーブルに登録されているか否かの検索を行い、登録されていない場合には前記データアイテムを生成する機能を有する、コンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータなどの情報処理装置で行われる情報処理の内容のカスタマイズを実現するための技術に関する。
【０００２】
【従来の技術】
コンピュータを用いた情報処理は、種々の分野で活用されている。一般に、情報処理の内容は、コンピュータにインストールされるソフトウェアによって決定される。かかる方法では、情報処理の内容を変更するためには、ソフトウェアの更新が必要であり、変更に要する負担が大きい。
【０００３】
コンピュータを用いた情報処理の一例として、金融機関で利用される帳票のイメージ処理システムが挙げられる。イメージ処理システムとは、振込用紙など定型的な帳票をスキャンして得られたイメージデータから、いわゆるＯＣＲ機能によって氏名、金額などのデータを取得して、取引処理に活用するためのシステムである。イメージ処理システムでは、取得したデータと、イメージデータとを比較して、オペレータがデータの修正を行うこともある。金融機関で使用される振込用紙は、多種多様であり、そこから取得されるデータの処理内容も金融機関によって多種多様である。従って、イメージ処理システムでは、類似しているソフトウェアではあるが、振込用紙の種類や金融機関などに応じた多様なソフトウェアが用いられている。
【０００４】
こうした処理の多様性に対処するため、いくつかの技術が提案されている。
第１の技術は、予めカスタマイズの余地を含んで、ソフトウェアを構築する手法である。振込用紙の種類や処理内容など、予め想定される多様性を包含するように多機能なソフトウェアを構成しておくことにより、実際に使用する機能をパラメータ等で指定するだけで、多様な処理内容を実現することが可能となる。
【０００５】
第２の技術は、いわゆるオブジェクト指向と呼ばれるプログラミング手法である。かかる手法で構成されたソフトウェアは、比較的シンプルな機能を実行するモジュールの組み合わせで全体の処理を実現しており、各モジュールの置換、追加を比較的容易に行うことができる利点がある。モジュールの置換等により、多様な処理内容を実現することが可能となる。
【０００６】
第３の技術は、インターネットで多用されているＷｅｂプログラミングと呼ばれる技術である。インターネット上のサーバから、クライアントに対し、ＨＴＭＬ（Hyper Text Markup Language）のファイルやスクリプト等を送信することにより、クライアントにおいて種々の処理を実現させることができる。例えば、ブラウザを搭載したクライアントでは、ソフトウェアの変更を伴うまでなく、ＨＴＭＬファイルを変更するだけで多種多様な表示画面が実現される。
【０００７】
【発明が解決しようとする課題】
しかし、情報処理装置において要求されるカスタマイズに十分対応するためには、これらの技術では不十分なことがあった。第１の技術では、ソフトウェアの構築時に予め考慮されている範囲を超えるカスタマイズが要求された場合には、十分に対処することができなかった。第２の技術では、新たな機能を追加する際に、追加機能に対応したモジュールを作成するとともに、追加されたモジュールを呼び出すよう、メインプログラムを改変する必要があり、結局、ソフトウェアの改修が必要とされていた。第３の技術では、ＨＴＭＬで対応可能な機能は比較的限定されており、十分な情報処理機能を提供するには適していなかった。近年、ＸＭＬ（eXtensible Markup Language）と呼ばれる技術によって、実現可能な機能の拡大が図られてはいるものの、それだけでは、十分な情報処理機能を提供するには至っていない。
【０００８】
かかる課題は、イメージ処理システムに関わらず、情報処理装置に共通する課題であった。また、情報処理機能の全てをソフトウェア的に実現する装置のみならず、その一部をハードウェア的に提供する装置においても共通の課題であった。ネットワーク等で接続された複数の情報処理装置が連動して情報処理を実現するようなシステムにおいては、アップデートまたはカスタマイズの対象となる装置が多大になるため、上記課題は、特に、深刻なものであった。
【０００９】
本発明は、これらの課題に鑑みてなされたものであり、ソフトウェアまたは回路の大幅な改変を伴わずに、機能の更新、カスタマイズが可能な情報処理装置を提供することを目的とする。
【００１０】
【課題を解決するための手段】
上記課題の少なくとも一部を解決するために、本発明では、情報処理装置において、以下に示す構成（以下、「第１の構成」と称する）を適用した。まず、予め設定された所定の基本機能を実現する複数種類の基本機能部を備える。これらの基本機能部は、ソフトウェア的に構成されていてもよいし、電子回路のようにハードウェア的に構成されていてもよいが、それぞれ個別の要素として構成されたものである。個別の要素とは、比較的容易に追加および置換が可能に構成されていることを意味する。
【００１１】
かかる情報処理装置における処理内容は、電子文書の形式で規定する。電子文書とは、上述した複数種類の基本機能部のうち、処理に使用すべき基本機能部を特定するものである。情報処理装置は、この電子文書を入力し、その内容を解析して処理を実行する。処理は、電子文書に規定された基本機能部を逐次、稼働させることによって実現される。
【００１２】
本発明によれば、情報処理装置は、単に、電子文書に従って各基本機能を呼び出すという汎用的な機能を備えていることで、種々の処理を実現することができる。基本機能の組み合わせによって実現される実質的な処理内容は、電子文書によって規定されるからである。従って、外部から与える電子文書の内容を変更するだけで、情報処理装置自体のソフトウェアまたはハードウェア構成を大幅に改変するまでなく、情報処理機能の追加、改変、カスタマイズなどを行うことができる。
【００１３】
本発明の情報処理装置では、基本機能部および電子文書の組み合わせによって、以下に例示する通り、多彩な機能を実現することができる。
【００１４】
第１の態様として、基本機能部は、表示画面を生成する画面生成部を含んでもよい。このとき、電子文書で、表示画面の内容およびその生成タイミングを規定しておくと、情報処理装置は、その生成タイミングに応じて画面生成部を稼働させて画面表示を行うことができる。こうすることで、任意のタイミングで、情報処理装置のインタフェース画面などを表示させることができる。
【００１５】
第２の態様として、電子文書には、複数の処理内容の実施順序を制御するフロー制御情報を含めてもよい。情報処理装置は、このフロー制御情報に応じた順序で、それぞれの基本機能部を稼働させる。こうすることにより、いわゆる条件分岐、ループなどの複雑なフローを伴う処理を、実現させることができる。フロー制御情報は、情報処理装置が解釈可能であるとともに、電子文書に組み込み可能な情報であれば足りる。
【００１６】
第３の態様として、基本機能部には、複数種類の要素表示部を含めることができる。要素表示部とは、例えば、線、ボタン、テキストなど表示画面を構成する表示要素を、それぞれ表示するための基本機能部を意味する。このとき、電子文書は、表示画面を構成する各表示要素の種類および位置を規定する。情報処理装置は、この電子文書に基づいて各要素表示部を稼働させると、規定された表示画面を生成することができる。電子文書の内容を変更することにより、多彩な表示画面を比較的容易に生成することが可能である。
【００１７】
第３の態様は、第１の態様と組み合わせて構成してもよい。つまり、第３の態様における電子文書を読み込んで、各要素表示部を稼働させる機能を、第１の態様における画面生成部が実現するものとしてもよい。こうすることにより、画面生成のタイミングおよび変遷を任意に制御しつつ、多彩な表示画面を実現することができる。
【００１８】
第４の態様として、基本機能部には、複数種類の要素演算部を含めることができる。要素演算部とは、例えば、四則演算など、情報処理装置に入力されたデータについて、所定の演算を実行する基本機能部を意味する。このとき、電子文書は、データに施すべき演算の種類を規定する。情報処理装置は、この電子文書に基づいて各要素演算部を稼働させることで、データの演算を実行することができる。電子文書の内容を変更することにより、多彩な演算を比較的容易に実現することが可能である。
【００１９】
本発明の情報処理装置では、先に説明した課題の少なくとも一部を解決するための別の構成として、以下に示す第２の構成を適用してもよい。第２の構成においても、複数の基本機能部を備える点は、第１の構成と共通である。第２の構成では、これらの基本機能部は、各基本機能部に予め対応づけられたオブジェクトの状態変化に基づいて起動する機能を有しているものとする。第２の構成では、情報処理装置は、これらのオブジェクト、および各オブジェクトと基本機能部との関連付けを管理し、オブジェクトに状態変化が生じた場合には、それに関連づけられた基本機能部に対して、状態変化を通知する。
【００２０】
こうすることにより、各基本機能部の稼働を比較的容易に同期させることができる。また、情報処理装置自体のソフトウェアおよびハードウェアなどに大幅な改変を伴うまでなく、基本機能部を追加、置換等することができる。追加等される基本機能部を正常に動作させるためには、関連づけられるべきオブジェクトを用意すれば足りるからである。
【００２１】
複数の基本機能部を連鎖的に稼働させるためには、それぞれの基本機能部が動作結果をいずれかのオブジェクトに反映させる機能を有することが好ましい。例えば、第１の機能部、第２の機能部をこの順序で連鎖的に稼働させる場合を考える。第１の機能部は第１のオブジェクトによって稼働し、第２の機能部は第２のオブジェクトによって稼働するものとする。このとき、第１の機能部が、動作結果を第２のオブジェクトに反映する機能を有していれば、その動作に連動して第２の機能部を容易に稼働させることが可能となる。
【００２２】
第２の構成の情報処理装置において、基本機能部に複数種類の要素表示部が含まれている場合、オブジェクトの管理は、複数の表示画面に共通するオブジェクトと、現に表示されている表示画面に関するオブジェクトとを別個に管理することが好ましい。後者のオブジェクトは、表示画面が切換えられた場合には、管理対象から外すことが可能であるが、前者のオブジェクトは、表示画面が切換えられるか否かにかかわらず保持しておく必要がある。両者を別個に管理することにより、画面の制御を円滑に行うことが可能となる。
【００２３】
第２の構成では、各基本機能部が、自己とオブジェクトとの対応関係を登録可能とすることが好ましい。こうすることにより、基本機能部の稼働状態、稼働可能性に応じて、オブジェクトとの対応関係が動的に登録されるため、基本機能部の正常な動作を確保するために要求される対応関係の管理負担を軽減することができる。
【００２４】
第２の構成の情報処理装置は、各基本機能部の稼働に呼応して、それに対応したオブジェクトを生成することも好ましい。また、稼働中のいずれの基本機能部とも対応づけられていないオブジェクトを消去することも好ましい。つまり、基本機能部の稼働状況に応じて、オブジェクトを動的に生成、消去することが好ましい。こうすることにより、メモリなどの資源を有効活用しながら、オブジェクトを管理することができる。
【００２５】
本発明の情報処理装置では、先に説明した課題の少なくとも一部を解決するための別の構成として、以下に示す第３の構成を適用してもよい。第３の構成における情報処理装置は、ネットワークに接続され、ネットワークを介した情報の授受に基づいて所定の処理を行うものとする。このとき、情報処理装置は、送受信される電文に含むべきデータ、およびフォーマットを規定する規定文書を記憶しておき、これに基づいて電文の生成または解読を行う。実質的な電文の生成方法は規定文書で定義されるため、情報処理装置は、規定文書に従って電文を生成等する汎用的な機能を有していれば足りる。第３の構成によれば、規定文書の変更により、多彩な電文を比較的容易に生成、解読することが可能となる。
【００２６】
情報処理装置において、処理に関連した複数のデータが統合的に管理されている場合、送信される電文に含むべきデータをこのデータ管理部から取得したり、受信した電文から抽出したデータをこの管理部に通知したりすることが好ましい。こうすることにより、情報処理装置と外部とのデータの授受を、電文を介して円滑に行うことが可能となる。
【００２７】
第３の構成において、規定文書は１種類に限定されるものではなく、複数種類を用いても良い。複数種類の規定文書を用いる場合、先に説明した電子文書において、所定で使用すべき規定文書を特定し、規定文書の使い分けを実現してもよい。電子文書と規定文書とは、１対１で対応している必要はなく、例えば、一つの処理において、条件分岐の結果に応じて規定文書を使い分けるものとしてもよい。
【００２８】
以上で説明した、第１〜第３の構成は、それぞれ個別の情報処理装置として適用してもよいし、適宜、組み合わせて適用してもよい。第１の構成および第２の構成は、スタンドアロンの装置に適用してもよいし、ネットワークに接続された装置に適用してもよい。
【００２９】
本発明の情報処理装置が実施する処理内容は、任意に設定可能であるが、本発明を有効に活用可能な例として、イメージ処理を行うものとしてもよい。つまり、本発明は、帳票のイメージデータに基づき所定のイメージ処理を実行するイメージ処理装置として構成することができる。
【００３０】
かかる構成では、イメージ処理装置は、イメージ処理に関し、予め設定された所定の基本機能を実現する複数種類の基本機能部を備える。電子文書は、この基本機能部を特定する形式で、イメージ処理の処理内容を規定する。イメージ処理装置は、この電子文書に基づいて、逐次、基本機能部を稼働させることによりイメージ処理を実行する。金融機関で用いられる帳票類は、非常に多彩であり、その処理内容も多様であるため、本発明を適用することにより、イメージ処理装置について金融機関ごとのカスタマイズに要する負担を軽減することができる。
【００３１】
本発明のイメージ処理装置において、例えば、基本機能部には、イメージデータに基づいて文字データまたは数値データを取得するデータ取得部を含むことができる。この場合、電子文書では、例えば、イメージデータから取得を行うべき領域、および取得するデータの属性を規定し、イメージ処理装置は、電子文書で規定されたデータの取得を実現する。こうすることで、多様な帳票に対して、データの取得を比較的容易に実現することが可能となる。
【００３２】
本発明のイメージ処理装置において、例えば、基本機能部には、イメージ表示部、データ表示部、データ修正部を含めることができる。イメージ表示部は、イメージデータを表示する基本機能部を意味する。データ表示部は、イメージデータに基づいて取得された文字データまたは数値データを表示する基本機能部を意味する。データ修正部は、文字データまたは数値データを修正する基本機能部を意味する。このとき、電子文書では、例えば、イメージデータ、文字データ等の表示態様、および外部からの入力によって文字データ等を修正する方法を規定し、イメージ処理装置は、これに基づいてイメージ等の表示およびデータの修正を実現するものとしてもよい。本発明を適用することにより、多様な帳票に対して、これらのデータ修正を比較的容易に実現することができる。
【００３３】
ここでは、イメージ処理装置としての代表的な構成例を示した。先に情報処理装置について説明した種々の構成は、そのままイメージ処理装置に適用可能である。
【００３４】
本発明の情報処理装置およびイメージ処理装置において、電子文書は、種々の形式を採ることが可能であるが、一例として、ＸＭＬで記述された文書（以下、ＸＭＬ文書と呼ぶ）とすることが好ましい。ＸＭＬ文書とは、いわゆるタグを含む、マークアップ言語で記述された文書である。タグは任意に設定可能である。従って、ＸＭＬを用いることにより、電子文書に要求される種々のコマンドを、タグの形式で比較的容易に規定することが可能となる。
【００３５】
本発明は、上述した情報処理装置およびイメージ処理装置に限らず、種々の態様で構成することが可能である。例えば、コンピュータによって上述した処理を実現する情報処理方法、またはイメージ処理方法として構成してもよい。これらの処理を実現するためのコンピュータプログラムとして構成してもよい。本発明を、コンピュータプログラムとして構成する場合には、ブラウザ上で稼働可能に構成することが好ましい。例えば、ＪＡＶＡ（登録商標）を用いて構成することが好ましい。こうすることにより、プラットフォームの区別なく稼働可能とすることができるとともに、電子文書としてＸＭＬ文書を利用しやすいという利点がある。
【００３６】
更に、これらの種々のコンピュータプログラムを記憶した記憶媒体として構成してもよい。ここで、記憶媒体としては、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク、ＩＣカード、ＩＣチップ、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置など光学的、磁気的、電気的にコンピュータが読取り可能な種々の媒体を利用できる。
【００３７】
【発明の実施の形態】
以下、本発明の実施の形態について、以下の項目に分けて説明する。
Ａ．第１実施例：
Ａ−１．システム構成：
Ａ−２．フロー定義：
Ａ−３．画面定義：
Ａ−４．部品間の連携：
Ａ−５．電文の授受：
Ａ−６．実行エンジン：
Ａ−７．アプリケーションブラウザ：
Ａ−８．メッセージバス：
Ａ−１０．起動処理：
Ａ−１１．フロー定義のコマンド処理：
Ａ−１２．画面操作処理：
Ｂ．第２実施例（イメージ処理システム）：
Ｂ−１．システム構成：
Ｂ−２．ソフトウェア構成：
Ｂ−３．イメージ処理：
Ｃ．変形例：
【００３８】
Ａ．第１実施例：
Ａ−１．システム構成：
図１は実施例としての情報処理装置のシステム構成を示す説明図である。情報処理装置１００は、汎用のパーソナルコンピュータに図示する各機能ブロックを備えるソフトウェアをインストールすることで構成される。ソフトウェアのインストールのみならず、これらの機能ブロックをハードウェア的に用意することで構成してもよい。
【００３９】
情報処理装置１００は、Ｗｅｂサーバ１０、およびＡＰサーバ２０とネットワークＩＮＴで接続されている。ネットワークは、インターネットなど広域的なネットワークとしてもよいし、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）など比較的限定的なネットワークとしてもよい。
【００４０】
Ｗｅｂサーバ１０は、情報処理装置１００からのリクエストに応じて、画面定義１２、フロー定義１４と呼ばれる電子文書を送信する。画面定義１２とは、表示画面の内容を規定する電子文書である。フロー定義１４とは、画面の遷移など処理の流れを規定する電子文書である。これらの電子文書の内容については、後述する。これらの電子文書は種々の形式を選択可能であるが、本実施例ではＸＭＬで記述されるものとした。
【００４１】
ＡＰサーバ２０は、情報処理装置１００と連携して種々の処理を実行するサーバである。例えば、端末からの入力データを受けて、ホストコンピュータが種々の処理を実行するシステムの場合、端末が情報処理装置１００に相当し、ホストコンピュータがＡＰサーバ２０に相当する。情報処理装置１００とＡＰサーバ２０との情報の授受は、電文１６によって行われる。電文１６の生成方法については後述する。電文１６は種々の形式を選択可能であるが、本実施例ではＸＭＬで記述されるものとした。
【００４２】
なお、本実施例では、情報処理装置１００とＷｅｂサーバ１０、ＡＰサーバ２０とをネットワークで接続するシステム構成を採用したが、情報処理装置１００はスタンドアロンで稼働する装置として構成してもよい。Ｗｅｂサーバ１０、ＡＰサーバ２０は必ずしも必要ではなく、実行すべき情報処理の内容に応じて、情報処理装置１００をスタンドアロンで稼働する構成を採っても良い。
【００４３】
情報処理装置１００に備えられている各機能ブロックの構成について説明する。情報処理装置１００には、所定のオペレーティングシステム上で稼働し、ＨＴＭＬ等のマークアップ言語で記述されたファイルを閲覧するためのソフトウェア、Ｗｅｂブラウザ１０２がインストールされている。各機能ブロックは、このＷｅｂブラウザ１０２上で稼働するように構成されている。本実施例では、ＪＡＶＡ（登録商標）を用いることにより、かかる構成を実現した。Ｗｅｂブラウザ１０２上で稼働可能としたのは、プラットフォーム非依存のソフトウェア構成が可能であるという利点があるからである。Ｗｅｂブラウザ１０２と無関係に稼働するよう構成しても構わない。
【００４４】
ベースアプレット１０４は、Ｗｅｂブラウザ１０２の上で稼働し、情報処理装置１００の各機能ブロック、実行エンジン１２０、アプリケーションブラウザ１３０、メッセージバス１４０などを稼働するためのプラットフォームを提供する。ベースアプレット１０４およびこれらの各機能ブロックによって情報処理を実現する全体の機構を、本明細書では、ＸＭＬアプリケーションプログラムと称するものとする。本実施例では、これらの機構は、名称の通り、ＸＭＬをベースとして構築されているが、ＸＭＬアプリケーションプログラムは、広義には、以下で説明する機構の概念を示すものであり、必ずしもＸＭＬベースで構築されているものには限られない。
【００４５】
ベースアプレット１０４は、ＪＡＶＡのアプレットとして構成されている。ベースアプレット１０４は、その上に構築される各機能ブロックの起動、終了を行う機能、およびコンピュータのキーボード、マウスなどの操作結果（以下、「キーイベント」と称する）を、ＸＭＬアプリケーションプログラムの各機能ブロックに受け渡す機能を奏する。
【００４６】
実行エンジン１２０は、フロー定義１４の内容に基づいて、全体処理を制御する機能を奏する。フロー定義１４において、画面の表示、遷移が規定されている場合には、適宜、アプリケーションブラウザ１３０を起動させる。また、ＡＰサーバ２０とのデータ授受が規定されている場合には、電文１６のやりとりを行う。電文１６の内容は、ＡＰサーバ２０によって異なるため、カスタマイズモジュール１１０によって適応させる。実行エンジン１２０は、ＡＰサーバ２０から受け取ったデータをメッセージバス１４０に展開したり、逆に、ＡＰサーバ２０に送信すべきデータをメッセージバス１４０から収集したりもする。
【００４７】
アプリケーションブラウザ１３０は、実行エンジン１２０によって起動され、画面定義１２に従って、画面を表示し、また、この表示画面を通じた操作を実現する。アプリケーションブラウザ１３０は、Ｗｅｂブラウザとは別のプログラムである。アプリケーションブラウザ１３０には、ＧＵＩ部品１３１ａ、ロジック部品１３１ｂと呼ばれる基本的な機能を実現するソフトウェアが用意されている。ＧＵＩ部品１３１ａとは、ボタン、線など表示画面を構成する表示要素を生成するためのソフトウェアであり、表示要素の種類に応じて複数用意されている。ロジック部品１３１ｂとは、四則演算、入力チェックなど、画面内でのデータに関する処理を実現するためのソフトウェアであり、処理内容に応じて複数用意されている。アプリケーションブラウザ１３０は、画面定義１２に従って、これらの部品を起動させ、表示画面に関する種々の処理を実現する。
【００４８】
メッセージバス１４０は、ＧＵＩ部品１３１ａおよびロジック部品１３１ｂの稼働制御をする。メッセージバス１４０は、ＧＵＩ部品１３１ａ、ロジック部品１３１ｂに対応づけられたデータアイテム１４１を複数保持している。各部品は、対応するデータアイテム１４１の状態変化をトリガとして起動するとともに、その処理結果をデータアイテム１４１に反映させるよう構成されている。メッセージバス１４０は、管理下にあるいずれかのデータアイテム１４１の状態変化が生じた場合には、それを部品に通知することによって、各部品を起動させる。メッセージバス１４０は、合わせて処理に必要なデータを保持する機能も奏する。先に説明した通り、実行エンジン１２０がＡＰサーバ２０との間で授受するデータは、データアイテム１４１として、メッセージバス１４０で管理される。
【００４９】
情報処理装置１００は、上述の構成によって、種々の処理を実現する。実行エンジン１２０、アプリケーションブラウザ１３０、メッセージバス１４０は、処理内容に依存したソフトウェアではなく、汎用的な機能を実現するソフトウェアである。処理内容に依存したソフトウェアは、ＧＵＩ部品１３１ａ、ロジック部品１３１ｂなどのモジュールで用意されている。実質的な処理内容は、フロー定義１４、画面定義１２などの電子文書で、これらの部品を使う順序等を規定する形式で特定される。従って、情報処理装置１００は、ソフトウェアの大幅な改変、追加を行うまでなく、電子文書の変更を行うことにより、処理内容を簡便に変更等することができる利点を有している。以下、図中に示した各構成要素について、順次、詳細に説明する。
【００５０】
Ａ−２．フロー定義：
図２はフロー定義１４の概要を示す説明図である。フロー定義１４とは、実行エンジン１２０の動作を規定する電子文書であり、本実施例では、ＸＭＬによって記述される。
【００５１】
フロー定義１４は、ＸＭＬ宣言文、ＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）、および本文から構成される。ＤＴＤとは、フロー定義内で使用されるタグを定義する部分である。ＤＴＤのみをフロー定義とは、別の文書として用意しても構わない。
【００５２】
本文は、種々のタグによって、実行エンジン１２０が実行すべき処理内容を規定している。実行エンジン１２０は、原則として、フロー定義の本文中のタグを先頭から順に解釈して、タグで規定されるコマンドを実行する。例えば、フロー定義中に、画面生成のコマンドを読み込んだ場合には、アプリケーションブラウザ１３０を起動することで、画面表示を行う。画面表示には、画面定義１２が必要であるため（図１参照）、画面生成コマンドでは、アプリケーションブラウザ１３０が参照すべき画面定義１２のパスも併せて指定される。
【００５３】
図の下方に、タグによって規定されるコマンド例を示した。コマンドは、処理コマンド、カーソル制御コマンドの２種類に大別される。処理コマンドとは、実行エンジン１２０が実質的に行う処理内容を規定するコマンドである。例えば、図示する通り、ＡＰサーバ２０への送受信、キューへの格納、取りだし、画面の退避、復帰などのコマンドが含まれる。画面の退避、復帰などが、画面生成コマンドに相当する。各コマンドの内容は、実行エンジン１２０の機能説明と併せて後述する。
【００５４】
カーソル制御コマンドとは、フロー定義におけるタグの解釈、実行順序を規定するコマンドである。先に説明した通り、実行エンジン１２０は、原則として先頭から順にタグを実行する。カーソルとは、実行エンジン１２０が処理を実行しているタグを意味する。カーソル制御コマンドとは、この原則に反して、カーソルの位置を移動させるためのコマンドである。上方の図に示す通り、カーソル移動コマンドを含めることにより、例えば、処理の異動先をタグＤ、タグＥに切り換える条件分岐を実現することができる。
【００５５】
本実施例では、カーソル制御コマンドとして、図中に示す１０種類を用意した。図３はカーソル制御コマンドの概要を示す説明図である。一般にＸＭＬのタグはツリー構造をなしていることから、フロー定義１４は、図３に示すようなツリー構造で示すことができる。
【００５６】
カーソル制御コマンド「ＦＬＯＷＤＥＦ」は、フロー定義のルートを規定するコマンドである。このコマンドに対して、実行エンジン１２０は、≡ｍａｉｎ≡という名称のサブルーチンにカーソルを移動する。
【００５７】
コマンド「ＳＵＢ」は、サブルーチン宣言のコマンドである。図３の例では、≡ｍａｉｎ≡、≡ｙｏｋｏ≡、≡ｔａｔｅ≡という３種類のサブルーチンが用意されている場合を例示した。コマンド「ＥＸＩＴＳＵＢ」は、サブルーチン終了のコマンドである。このコマンドに対して、実行エンジン１２０は、サブルーチンを抜け出し、次のタグにカーソルを進める。
【００５８】
コマンド「ＧＯＳＵＢ」は、サブルーチン呼出のコマンドである。図示する通り、「ＧＯＳＵＢ  ≡ｙｏｋｏ≡」というタグに対して、実行エンジン１２０は、カーソルをサブルーチン≡ｙｏｋｏ≡に移動させる。
【００５９】
コマンド「ＳＷＩＴＣＨ」は、条件分岐を実現するコマンド、コマンド「ＣＡＳＥ」は条件に応じたカーソルの移動先を示すコマンド、コマンド「ＤＥＦＡＵＬＴ」はデフォルトの処理内容を示すコマンドである。図３の例では、コマンドＳＷＩＴＣＨによって、≡ｃｏｎｄｉｔｉｏｎ≡と称するオブジェクトの状態に応じて条件分岐が行われる。このオブジェクト≡ｃｏｎｄｉｔｉｏｎ≡が≡ｆｉｎｅ≡の状態にある場合には、ＣＡＳＥ≡ｆｉｎｅ≡以下の処理が実行される。オブジェクト≡ｃｏｎｄｉｔｉｏｎ≡が≡ｂａｄ≡の状態にある場合には、ＣＡＳＥ≡ｂａｄ≡以下の処理が実行される。オブジェクト≡ｃｏｎｄｉｔｉｏｎ≡が、これらいずれの状態にも該当しない場合には、ＤＥＦＡＵＬＴ以下の処理が実行される。
【００６０】
コマンド「ＬＯＯＰ」は、一定範囲の処理を繰り返し実行するためのコマンドであり、コマンド「ＥＸＩＴＬＯＯＰ」はループの終端を示すコマンドである。このコマンドに対して、実行エンジン１２０は、ＬＯＯＰからＥＸＩＴＬＯＯＰの間の処理を繰り返し実行する。
【００６１】
コマンド「ＮＯＤＡＴＡ」は、参照したデータの有無に応じて処理内容を切り換えるためのコマンドである。図３の例では、参照したデータが無い場合には、タグＡ，タグＢで規定される処理を実行し、データが存在する場合には、タグＣで規定される処理を実行する。
【００６２】
このように、カーソル制御コマンドをフロー定義中に入れることにより、条件分岐、繰り返し処理などを含む、複雑な処理の記載が可能となる。なお、図２および図３で示した種々のコマンドは例示に過ぎず、コマンドの種類および多少は、これらに限定されるものではない。
【００６３】
Ａ−３．画面定義：
図４は画面定義の概要を示す説明図である。画面定義１２とは、アプリケーションブラウザ１３０の動作を規定する電子文書であり、本実施例では、ＸＭＬで記述される。
【００６４】
画面定義１２の本文は、種々のタグによって、画面の構成や画面で行われる操作内容を規定している。タグは、画面情報、部品情報の２種類に大別される。画面情報とは、画面定義１２によって定義される画面に対し、画面ＩＤを与えるタグである。画面定義１２は、情報処理装置１００で用いられる画面ごとに用意されている。画面ＩＤは、それらの画面を識別するための情報である。
【００６５】
部品情報は、ＧＵＩ部品１３１ａ、ロジック部品１３１ｂを起動するために必要な種々の情報を定義する。ＧＵＩ部品１３１ａには、文字列表示、文字列入力、画像表示、ボタンなど画面の表示要素を構成する種々のソフトウェアが含まれる。ロジック部品１３１ｂには、四則演算、入力条件チェックなど、画面上の操作に関する種々のソフトウェアが含まれる。以下の説明では、混同を回避するため、特に断らない限り、ＧＵＩ部品１３１ａ、ロジック部品１３１ｂとして用意されたソフトウェアパッケージを「部品」と称し、これらによって生成された個別の表示要素その他のオブジェクトを、「部品オブジェクト」と称するものとする。
【００６６】
部品情報は、ＧＵＩ部品１３１ａ、ロジック部品１３１ｂを用いて生成される部品に与えられる部品ＩＤ、部品のクラス、場所、大きさ、パラメータなどを、それぞれ与えるタグである。画面内には、同じ部品から生成された部品オブジェクトが複数存在する場合がある。例えば、ボタンというＧＵＩ部品１３１ａを用いて、ボタンという部品オブジェクトを複数生成させる場合がある。部品ＩＤは、こうして生成された部品オブジェクトそれぞれを個別に管理するための識別情報である。部品の場所、大きさは、例えば、画面上に定義された座標系に基づいて設定することができる。部品のパラメータとしては、例えば、ボタンの形状や表示色、文字のフォントなどの指定が挙げられる。
【００６７】
アプリケーションブラウザ１３０は、画面定義を先頭から順に読み込み、それぞれのタグに従って、処理を実行する。部品ＩＤ、部品の位置、大きさなどを指定するそれぞれのタグが見いだされると、アプリケーションブラウザ１３０は、このタグに従って、各部品を起動するための処理を実行する。この処理によって、画面には、それぞれの部品オブジェクトが表示され、画面上での操作が実現される。なお、図４に示した、タグ、ＧＵＩ部品１３１ａ、ロジック部品１３１ｂは、例示に過ぎず、その数および種類は、これらに限定されるものではない。
【００６８】
Ａ−４．部品間の連携：
図５は部品間の連携を示す説明図である。本実施例では、アプリケーションブラウザ１３０は、メッセージバス１４０を介してそれぞれの部品を起動するものとした。
【００６９】
図示する通り、メッセージバス１４０は、データアイテムを統合的に管理する。データアイテムは、固有の値を有するとともに、アプリケーションブラウザ１３０で用いられる部品と関連付けられている。この関連付けは、それぞれデータアイテムごとに登録されている。図中の例では、データアイテムＡは、値Ａを有するとともに、部品Ａと関連づけられている。データアイテムＢは、値Ｂを有するとともに、部品Ｂと関連づけられている。メッセージバス１４０は、データアイテムについて、値の変更が生じた場合には、それぞれ関連づけられた部品に、その変更を通知する機能を有している。かかる機能に基づき、本実施例では、各部品を以下に示す手順で起動させることができる。
【００７０】
一例として、画面定義１２において、部品Ａの起動が規定されている場合を考える。アプリケーションブラウザ１３０は、このタグを読み込むと、データアイテムＡが保持する値Ａを、部品Ａの起動トリガとなるべき値に変更する。メッセージバス１４０は、この変更を、データアイテムＡに関連づけられた部品Ａに通知する。部品Ａは、この通知を受けて起動する。ここで、部品Ａは、起動後に、その処理結果に応じてデータアイテムＢの値を変更するようプログラミングされているものとすると、部品Ａの起動によって、データアイテムＢの値Ｂが変更される。メッセージバス１４０は、この変更を、データアイテムＢに関連づけられた部品Ｂに通知する。部品Ｂは、この通知を受けて起動する。
【００７１】
このように、メッセージバス１４０に管理されたデータアイテムを介して、複数の部品を比較的容易に連動させることができる。例えば、ボタンが押された場合に、ボタンの表示変更と連動して文字列の表示内容を変えることが容易に実現される。
【００７２】
また、データアイテムを介して各部品を起動させることにより、新たな部品の追加、部品の置換を比較的容易に実現することも可能となる。例えば、部品Ａに連動して起動する新たな部品Ｃを追加する場合を考える。この場合には、アプリケーションブラウザ１３０に部品Ｃのソフトウェアパッケージを用意するとともに、データアイテムＢの対象部品に、部品Ｃを追加すれば足りる。部品Ａの起動によってデータアイテムＢの値が変更されると、メッセージバス１４０は、その変更を、部品Ｂ、部品Ｃに通知するため、これらの部品を起動させることができる。このように、部品Ａの内容は改変するまでなく、部品Ａに連動する部品の追加等を容易に実現することができるのである。
【００７３】
本実施例では、部品間のこうした柔軟な連携を実現するため、各部品を起動するのに、図５で示した方法を適用した。この利点を考慮しない場合、例えば、部品Ａが直接、部品Ｂ、部品Ｃなどを起動する方法を適用しても構わない。
【００７４】
Ａ−５．電文の授受：
図６は電文の生成、解読方法を示す説明図である。実行エンジン１２０は、ＡＰサーバ２０と電文１６によってデータを授受する。電文１６は、データの種類およびＡＰサーバ２０で用意されるアプリケーションソフトの内容に応じたフォーマットで構成される必要がある。実行エンジン１２０は、図６に示す構成により、こうした多種多様なフォーマットの電文１６を、比較的容易に生成することができる。
【００７５】
実行エンジン１２０は、電文１６の送受信時には、そのフォーマットを規定するための電子文書、ＲＥＬＡＸ１１２を読み込む。ＲＥＬＡＸ１１２は種々の形式を採ることができるが、本実施例では、ＸＭＬで記述されるものとした。送受信される電文１６のフォーマットは単一ではないから、ＲＥＡＬＸ１１２も複数用意されている。ＲＥＬＡＸ１１２は、予め情報処理装置１００内に保持されているものとしてもよいし、Ｗｅｂサーバ１０などから供給されるものとしてもよい。
【００７６】
データの送受信を伴う処理の実行時には、フロー定義１４において、使用すべきＲＥＬＡＸ１１２が併せて指定される。図中に一例を示した。ここでは、条件分岐における条件が”ｆｉｎｅ”に該当する場合には、使用すべきＲＥＬＡＸとしてパスＡが規定され、”ｂａｄ”に該当する場合には、パスＢが規定されている。このパス名が、実行エンジン１２０からカスタマイズモジュール１１０に受け渡されると、カスタマイズモジュール１１０がパス名に応じたＲＥＬＡＸ１１２を選択し、それに基づいて送信用の電文１６の作成、または受信した電文１６の解読を行う。送受信に伴うデータの授受は、メッセージバス１４０との間で行う。
【００７７】
実行エンジン１２０は、それぞれの電文１６に依存した生成機能は有さず、ＲＥＬＡＸ１１２に基づいた電文１６を作成するという汎用的な機能を有している。かかる汎用的な機能を実行エンジン１２０に備えることにより、実行エンジン１２０の改変を要せずに、多種多様な電文１６を生成することが可能となる。
【００７８】
Ａ−６．実行エンジン：
図７は実行エンジン１２０のモジュール構成を示す説明図である。実行エンジン１２０には、図示する機能ブロックがそれぞれソフトウェア的に構成されている。各機能ブロックは、メイン制御１２１の制御下で稼働する。
【００７９】
フロー制御１２２は、フロー定義を読み込み、その内容に応じて処理を進める機能を奏する。先に図２で説明した通り、フロー定義には、処理コマンド、カーソル制御コマンドが含まれる。フロー制御１２２は、カーソル制御コマンドの内容を解釈し、これに応じたカーソル移動を実現する。処理コマンドについては、メイン制御１２１が内容を解釈し、それに応じた機能ブロックをそれぞれ稼働させる。
【００８０】
コンテキスト制御１２３は、画面表示などの制御を実現する。「Ｐｕｓｈ」（画面の待避）、「Ｐｏｐ」（画面の復帰）などの処理コマンド（図２参照）に呼応して起動される。コンテキスト制御１２３は、アプリケーションブラウザ１３０を適宜、起動させたり停止させたりして、これらの画面表示に関する制御を実行する。
【００８１】
トランザクション制御１２５は、ＡＰサーバ２０との電文の授受に関する通信制御を実行する。「Ｕｐｌｏａｄ」（サーバへの送信）、「Ｔｒａｎｓａｃｔｉｏｎ」（サーバとの通信）などの処理コマンド（図２参照）に呼応して起動される。本実施例では、電文は、ＲＥＬＡＸに基づき生成される。トランザクション制御１２５は、ＲＥＬＡＸ選択１１６、アペンダ１１５、通信プラグイン１１７を用いて電文の処理を実行する。ＲＥＬＡＸ選択１１６は、電文の生成、解読に適用すべきＲＥＬＡＸを選択する機能を奏する。アペンダ１１５は、送信する電文に含めるべきデータについて、ヘッダその他の付加的な情報を生成する。通信プラグイン１１７は、通信プロトコルに応じて、ＡＰサーバ２０との電文の送受信を行う。これらの機能は、ＡＰサーバ２０の機能、通信プロトコルの種類などに応じてカスタマイズが必要であるため、本実施例では、実行エンジン１２０の汎用的な機能ブロックとは区分されたカスタマイズモジュール１１０として用意した。
【００８２】
キュー制御１２４は、トランザクション制御１２５、コンテキスト制御１２３などの同期を採る機能を奏する。キュー制御１２４は、「Ｑｕｅｕｅ」（キューへの格納）、「Ｄｅｑｕｅｕｅ」（キューからの取り出し）などの処理コマンド（図２参照）に応じて起動される。キュー制御１２４は、トランザクション制御１２５に受け渡すべき通信スレッド１２６を生成して、キューに格納する。トランザクション制御１２５は、適当なタイミングで、このキューに基づいてＡＰサーバ２０との通信を実行する。ＡＰサーバ２０から受信したデータに応じて画面を表示する場合、通信スレッド１２６は、結果を保持しておき、適当なタイミングで、画面表示するためのコンテキスト制御１２３を起動させる。このようにキューを用いることにより、ＡＰサーバ２０との通信およびその結果保持を事前に行っておくことが可能となり、画面の遷移等を円滑に進めることができる。
【００８３】
Ａ−７．アプリケーションブラウザ：
図８はアプリケーションブラウザ１３０のモジュール構成を示す説明図である。アプリケーションブラウザ１３０には、メイン制御１３３の制御下で稼働する各機能ブロックが用意されている。
【００８４】
画面生成部１３４は、画面定義の内容に基づいて表示画面を構成する部品オブジェクトを生成する機能を奏する。画面表示部１３５は、メイン制御１３３からの指示に応じて、生成された部品オブジェクトを順次、表示させ、画面を構成する機能を奏する。画面非表示部１３６は、逆に、それぞれの部品オブジェクトを停止させて画面を消去する。画面破棄部１３７は、部品オブジェクト自体を破棄して、画面に関する情報を削除する。パス設定部１３８は、それぞれの画面を特定するためのパス名、即ち、画面ＩＤを設定する。
【００８５】
画面で用いられる部品オブジェクトは、部品１３１によって生成され、オブジェクトテーブル１３９によって管理される。部品１３１は、先に説明したＧＵＩ部品１３１ａ、ロジック部品１３１ｂの双方が含まれ得る。アプリケーションブラウザ１３０で実現される上述の各機能は、オブジェクトテーブル１３９への各部品オブジェクトの登録、表示、停止などの作用を施すことによって実行される。
【００８６】
Ａ−８．メッセージバス：
図９はメッセージバスのモジュール構成を示す説明図である。メッセージバス１４０は、データアイテム１４１を一元的に管理する機能を奏する。本実施例では、メッセージバス１４０の内部に、複数のバス１４８を構築し、データアイテム１４１の種類に応じてバスごとに区分して管理するものとした。これらのバスは、予め固定的に用意されているものに限られず、必要に応じて動的に生成されるものも含まれる。
【００８７】
バス取得部１４６はバス１４８の生成を行う。バスクリア部１４７は、不要になったバスを消去する。本実施例では、バス１４８として８種類を用意した。同一種類のバスが複数生成される場合もある。例えば、先読画面に関するバス［６］〜［８］は、画面の内容に応じて複数生成される場合がある。
【００８８】
各バスに対応して、データアイテムを管理するための機能ブロックが設けられる。データアイテム取得部１４２は、管理対象となっているデータアイテムの状態を示す値を取得する。データアイテム取得部１４２は、データアイテムを生成する機能も奏する。先に説明した通り、データアイテムは、部品の連携を取るために活用されるオブジェクトであるから、本実施例では、部品の稼働状態に応じてデータアイテムを動的に生成するものとした。データアイテム取得部１４２は、部品の稼働等に必要なデータアイテムが管理対象に含まれているか否かの検索を行い、含まれていない場合には、適宜、データアイテムを生成するとともに、管理対象に加える。こうすることにより、データアイテムの管理に際し、ハードウェア資源を有効活用することができる。
【００８９】
データ収集部１４３は、実行エンジン１２０が電文に含めるためのデータを、データアイテムから収集する。データクリア部１４４は、データアイテムが保持するデータをクリアする。管理対象となるデータアイテムは、データアイテムテーブル１４５に登録されており、上述の機能は、このデータアイテムテーブル１４５を参照して実行される。
【００９０】
図中にデータアイテム１４１の機能を列挙した。データアイテム１４１は、図示する５つの機能を有している。値設定とは、データアイテムが保持する値を、外部から通知された値に設定し、値の変更が生じた場合には、関連づけられている部品に通知する機能である。先に図５で説明した連携を実現するための機能に相当する。値取得とは、外部からの問い合わせに対し、データアイテム１４１が保持している値を応答する機能である。部品登録・管理とは、値の変更が生じた場合に通知すべき部品を管理する機能である。部品登録解除および全部品登録解除は、部品の登録を個別またはまとめて解除する機能である。これらの機能により、データアイテム１４１は、図５で説明した通り、部品の起動、および連携を制御することができる。
【００９１】
データアイテム１４１への部品の登録は、本実施例では、各部品が能動的に行うものとした。図９中には部品１３１が有する機能を例示した。
【００９２】
部品１３１は、図示する５つの機能を有している。変更検知とは、データアイテム１４１の値に変更があった場合に、それを検知する機能である。データアイテム１４１からの変更通知を受信する機能に相当する。通知とは、部品オブジェクトの生成、表示、非表示、破棄などを外部に通知する機能である。データアイテム取得とは、部品１３１が関連づけられるべきデータアイテム１４１を検索する機能である。データアイテム監視とは、関連づけられるべきデータアイテム１４１に対し、自己の登録を行う機能である。パラメータ値取得とは、部品オブジェクトの生成時に指定されたパラメータを取得する機能である。
【００９３】
本実施例では、関連づけられるべきデータアイテム１４１への登録は、部品１３１側で行うものとした。逆に、データアイテム１４１が部品１３１を検索して、登録するものとしてもよい。また、本実施例では、値の変更を、データアイテム１４１が部品に通知するものとしたが、部品がデータアイテム１４１の値を継続的に監視して、その変化を検知するものとしてもよい。
【００９４】
以上で説明した構成により、情報処理装置１００は、フロー定義、画面定義、ＲＥＬＡＸなどの電子文書に従った柔軟な処理、電文生成および解読を実現することができる。また、これらの電子文書の改変により、ＸＭＬアプリケーションプログラムの基本的な構成の改変を行うまでなく、処理内容を比較的容易かつ柔軟に改変することが可能となる。
【００９５】
Ａ−１０．起動処理：
以下では、ＸＭＬアプリケーションプログラムを起動して、フロー定義等に応じた処理を実行するまでの各段階での手順を説明する。
【００９６】
図１０は起動処理のフローチャートである。この処理は、情報処理装置１００においてブラウザが起動している状態で、オペレータがＸＭＬアプリケーションプログラムベースページのＵＲＬを入力することにより、開始される。ＸＭＬアプリケーションプログラムベースページとは、ベースアプレット１０４を提供するＷｅｂページであり、本実施例ではＸＭＬで記述される。このＵＲＬは、情報処理装置１００の内部であってもよいし、外部のＷｅｂサーバ１０であってもよい。
【００９７】
このＵＲＬが入力されると、情報処理装置１００は、ブラウザによってＸＭＬアプリケーションプログラムベースページを読み込み（ステップＳ１０）、そこで提供されるベースアプレットを起動させる（ステップＳ１１）。ベースアプレットは、図１で説明した通り、ＸＭＬアプリケーションプログラムが稼働するためのプラットフォームを提供するソフトウェアである。
【００９８】
ベースアプレットの機能により、情報処理装置１００は、アプリケーションブラウザ１３０を生成する（ステップＳ１２）。ここで生成されるアプリケーションブラウザ１３０は、ＸＭＬアプリケーションプログラムが起動するためのプラットフォームとしてのブラウザに相当する。アプリケーションブラウザ１３０は、ベースアプレットで予め指定された初期の画面定義を読み込む（ステップＳ１３）。この初期の画面定義に基づいて生成される画面を「ベース画面」と称する。アプリケーションブラウザ１３０は、このベース画面上で、実行エンジン１２０を起動させる（ステップＳ１４）。これにより、ＸＭＬアプリケーションプログラムが稼働可能な状態が整ったことになる。
【００９９】
実行エンジン１２０は、フロー定義を読み込み（ステップＳ１５）、それに基づいてアプリケーションブラウザ１３０を呼び出し、初期画面をオペレータに提示する（ステップＳ１６）。実行エンジン１２０が読み込むべきフロー定義のＵＲＬは、予め設定されている。このＵＲＬを、ベースアプレットまたは初期の画面定義で与えるものとしてもよい。
【０１００】
図１１は起動後の画面構造を模式的に示す説明図である。ＸＭＬアプリケーションプログラムは、ＸＭＬアプリケーションプログラムベースページを読み込んだＷｅｂブラウザ１０２上で稼働する。ＸＭＬアプリケーションプログラムベースページ上では、ベースアプレット１０４が稼働している。
【０１０１】
ベースアプレット１０４は、ＸＭＬアプリケーションプログラム用のプラットフォームとしてのアプリケーションブラウザ１３０Ａを生成し、ＸＭＬアプリケーションプログラムベース画面を提供する。ＸＭＬアプリケーションプログラムベース画面上では、実行エンジン１２０が起動される。通信その他の機能を提供するためのプラグインを必要に応じて起動するものとしてもよい。実行エンジン１２０は、アプリケーションブラウザ１３０Ｂを起動する。アプリケーションブラウザ１３０Ｂは、先に説明した通り、種々の部品１３１を起動して、画面を生成する。部品１３１には、ＧＵＩ部品１３１ａ、ロジック部品１３１ｂの双方が含まれる。アプリケーションブラウザ１３０Ｂの起動は、フロー定義によって、画面表示、画面遷移が指示される度に、適宜呼び出されることになる。
【０１０２】
以上の処理によって、ＸＭＬアプリケーションプログラムの起動が完了すると、実行エンジン１２０は、以下に示す通り、フロー定義に基づいて実質的な処理を開始する。
【０１０３】
Ａ−１１．フロー定義のコマンド処理：
図１２は実行エンジンが実行する処理のフローチャートである。実行エンジン１２０は、フロー定義を読み込み（ステップＳ２０）、そこに含まれるタグの内容を解釈して（ステップＳ２１）、それに応じた処理を実行する（ステップＳ２２）。
【０１０４】
画面表示に関する処理の場合には、実行エンジン１２０は、コンテキスト制御を実行する（ステップＳ２３）。つまり、アプリケーションブラウザ１３０を起動して、画面の生成、画面上での操作を実現する。アプリケーションブラウザ１３０を起動している期間、情報処理装置１００の制御は、アプリケーションブラウザ１３０側に移行する。ステップＳ２３では、実行エンジン１２０は、アプリケーションブラウザ１３０が一連の処理を完了するのを待っている。フロー定義で規定された処理が電文処理である場合には、実行エンジン１２０は、トランザクション制御を実行する（ステップＳ２４）。つまり、ＲＥＬＡＸを参照しながら、電文の生成または解読処理を実行する。図示を省略しているが、その他、実行エンジン１２０は、タグの内容に応じて、種々の処理を実行可能である。
【０１０５】
実行エンジン１２０は、以上の処理を、フロー定義に規定された内容が完了するまで（ステップＳ２５）、繰り返し実行する。
【０１０６】
Ａ−１２．画面操作処理：
図１３は画面操作処理のフローチャートである。実行エンジン１２０からの呼び出しに応じて、アプリケーションブラウザ１３０が起動し（ステップＳ３０）、以下に示す処理によって、画面表示などの画面操作を実現する。
【０１０７】
アプリケーションブラウザ１３０は、まず、呼び出し時に指定された画面定義を読み込み（ステップＳ３１）、画面定義の内容に従って、画面表示を行う（ステップＳ３２）。画面表示は、既に説明した通り、画面定義の規定内容に基づいて各部品を呼び出すことによって実現される。
【０１０８】
この状態で、アプリケーションブラウザ１３０は、キーイベントの入力を待つ（ステップＳ３３）。キーイベントは、情報処理装置１００のキーボード、マウスなどの操作結果である。ベースアプレット１０４が、これらの操作を検知して、その操作内容を表すメッセージを、メッセージバス１４０に展開する。アプリケーションブラウザ１３０は、メッセージバス１４０を監視しているため、この展開結果に基づいてキーイベントを検知することができる。
【０１０９】
キーイベントが完了指示である場合、即ち、画面の遷移、ＡＰサーバ２０との通信、消去、ＸＭＬアプリケーションプログラムの終了などを示している場合、アプリケーションブラウザ１３０はその動作を終了し、実行エンジン１２０に制御を戻す（ステップＳ３６）。この際、完了指示が、消去、ＸＭＬアプリケーションプログラムの終了など表示画面の消去を要する指示である場合には、アプリケーションブラウザ１３０は、それまでに表示していた画面を破棄した上で、実行エンジン１２０に制御を戻す。完了指示が、画面の遷移、通信など、表示画面の消去を要しない指示である場合には、画面の破棄を伴わずに、制御を戻す。
【０１１０】
キーイベントが完了指示でない場合には、アプリケーションブラウザ１３０は、それぞれのキーイベントに応じてＧＵＩ部品、ロジック部品を動作させる（ステップＳ３５）。かかる指示には、例えば、画面上でのデータ入力、ボタン操作、範囲指定などの操作などが含まれる。各部品の動作は、図５で説明した通り、各部品に関連づけられたデータアイテムの値を変更することにより、容易に実現される。
【０１１１】
アプリケーションブラウザ１３０は、以上の処理によって、画面定義に基づく画面の表示、画面上での操作を実現する。アプリケーションブラウザ１３０は、実行エンジン１２０から重複して呼び出される可能性がある。本実施例では、複数のアプリケーションブラウザ１３０を生成し、それぞれが個別に上述の処理を実行する形で、かかる並列的な処理を実現するものとした。
【０１１２】
以上で説明した第１実施例の情報処理装置１００によれば、次に示す種々の利点が得られる。
【０１１３】
第１に、実行エンジン１２０、アプリケーションブラウザ１３０が実行すべき実質的な処理内容を、フロー定義１４、画面定義１２、ＲＥＬＡＸなどの電子文書で外部から規定することができる。従って、これらのソフトウェアの改変を行うまでなく、処理内容の変更、拡張を容易に実現することができる。
【０１１４】
第２に、アプリケーションブラウザ１３０が使用する各部品１３１は、それぞれ個別のモジュールとして構成されている。従って、新たな部品の追加、部品の置換を比較的容易に実現することができる。
【０１１５】
第３に、各部品は、直接相互に関連している訳ではなく、データアイテムを介して、連携を保っている。このように中間にオブジェクトを介在させて、部品相互の関連付けを行うことにより、各部品の置換、追加を比較的容易に実現することが可能となる。
【０１１６】
第４に、ＸＭＬアプリケーションプログラムは、Ｗｅｂブラウザ上で稼働するため、プラットフォーム非依存で、汎用性が高いという利点がある。
【０１１７】
Ｂ．第２実施例（イメージ処理システム）：
第１実施例では、情報処理システムとして汎用的な構成を例示した。第２実施例では、ＸＭＬアプリケーションプログラムの具体的な適用例として、イメージ処理システムについて説明する。
【０１１８】
Ｂ−１．システム構成：
図１４はイメージ処理システムの構成を示す説明図である。イメージ処理システムとは、金融機関で利用される振込用紙などの帳票を利用した取引を実行するシステムである。帳票に含まれる情報から得られる文字データまたは数値データ（以下、これらを「帳票データ」と総称する）と、帳票をスキャンして得られたイメージデータとを利用して取引を実行する。
【０１１９】
実施例のイメージ処理システムは、イメージワークフローシステム２００と基幹業務システム３００の２つを、ネットワークで接続して構築されている。イメージワークフローシステム２００は、帳票のイメージデータ、帳票データの登録、補正、紹介を実行する。基幹業務システム３００は、取引処理を実行する。基幹業務システム３００が実行する取引処理には、帳票を利用しない取引も含まれるが、ここでは説明の便宜上、帳票のデータを利用した取引に絞って説明する。
【０１２０】
基幹業務システム３００は、業務サーバ３２０とホストコンピュータ３３０を有している。両者を一体的に構成しても構わない。業務サーバ３２０は、取引に関する業務データを業務データベース３１０に管理する機能、クライアント２５０、３５０などの要求に応じて業務データを供給する機能を奏する。業務データには、例えば、利用者の口座情報、取引履歴などの情報が含まれる。ホストコンピュータ３３０は、業務データに基づいて、各種取引処理を実現する。
【０１２１】
イメージワークフローシステム２００は、イメージサーバ２２０を有している。イメージサーバ２２０は、帳票のイメージデータおよび帳票データをそれぞれイメージアーカイブ２１０として保管し、クライアント２５０、３５０などの要求に応じて提示する機能を奏する。
【０１２２】
イメージデータおよび帳票データは、イメージワークフローシステム２００側のクライアント２５０（以下、イメージクライアントと称する）によって入力される。イメージクライアント２５０には、スキャナ２０４によって、帳票２０２をスキャンして、イメージデータを取得する。イメージクライアント２５０は、取得したイメージデータをＯＣＲ処理して、帳票データを取得して、イメージサーバ２２０に登録する。
【０１２３】
登録された帳票データについては、別のオペレータによる確認、補正が行われる。これらの処理は、イメージサーバ２２０に接続されたいずれかのイメージクライアント２５０によって行われる。オペレータは、イメージクライアント２５０で、確認対象となるイメージデータおよび帳票データを並列的に表示させて、両者を比較することで、帳票データの誤りを確認する。誤りがある場合には、適宜、補正してイメージアーカイブ２１０の内容を更新する。
【０１２４】
Ｂ−２．ソフトウェア構成：
図１５はイメージワークフローシステム２００のソフトウェア構成を示す説明図である。本実施例では、イメージサーバ２２０、イメージクライアント２５０の双方共に、ＸＭＬアプリケーションプログラムでそれぞれの処理を実現する。従って、以下に示す通り、それぞれにＸＭＬアプリケーションプログラムを稼働させるための機能ブロックが構築されている。
【０１２５】
ＸＭＬアプリケーションプログラムは、イメージサーバ２２０およびイメージクライアント２５０のいずれか一方にのみ適用しても構わない。また、基幹業務システム３００側にＸＭＬアプリケーションプログラムを適用することも可能である。
【０１２６】
イメージサーバ２２０には、アプリケーションコア２２５、アプリケーション部品２２４が備えられている。アプリケーションコア２２５は、実行エンジン、アプリケーションブラウザ、メッセージバスの総称である。第１実施例で説明した通り、アプリケーションコア２２５は、Ｗｅｂブラウザ上で、ベースアプレットによって提供される。
【０１２７】
イメージサーバ２２０には、アプリケーションコア２２５が処理に要するアプリケーション部品２２４および業務フロー定義２２３も予め用意されている。イメージサーバ２２０では、画面の表示は行わないため、画面定義は省略しても差し支えない。
【０１２８】
業務フロー定義２２３は、イメージクライアント２５０から受け取ったイメージデータおよび帳票データをイメージアーカイブ２１０に管理するための処理、イメージクライアント２５０その他のクライアントからの要求に応じて、これらのイメージデータ等を提供するための処理を規定する。
【０１２９】
イメージサーバ２２０は、Ｗｅｂ紹介部２２１および基幹業務連携部２２２を有している。Ｗｅｂ紹介部２２１は、ＸＭＬアプリケーションプログラムに非対応のクライアントからの要求に応じて、イメージアーカイブをＨＴＭＬファイルの形式で提供する。基幹業務連携部２２２は、基幹業務システム３００との連携が必要となる処理を実現する。例えば、イメージデータと帳票データの整合だけでは、口座番号が真正なものであるか否かを確認することはできないため、基幹業務連携部２２２は、基幹業務システム３００に口座番号の真否を確認する。
【０１３０】
イメージクライアント２５０は、同じく、アプリケーションコア２５３、アプリケーション部品２５２、業務定義２５１を備えている。イメージクライアント２５０では、画面での操作も伴うため、業務定義２５１には、フロー定義、画面定義の双方が含まれる。
【０１３１】
イメージクライアント２５０は、更に、帳票認識部２５４を備えている。本実施例では、帳票認識部２５４は、ＸＭＬアプリケーションプログラムに依らずに起動するソフトウェアとして用意するものとしたが、ＸＭＬアプリケーションプログラムを利用してもよい。帳票認識部２５４は、帳票のイメージデータのＯＣＲ処理によって帳票データを取得する。ＯＣＲ処理を施す対象となる領域は、帳票ごとに帳票定義２５５によって規定されている。
【０１３２】
イメージクライアント２５０では、帳票データの取得以外の部分をＸＭＬアプリケーションプログラムで実現する。フロー定義は、例えば、帳票のイメージデータ取得、帳票認識部２５４によって得られた帳票データとの関連づけ、イメージアーカイブ２１０に格納するためのフォーマット変換などの処理を規定する。画面定義は、これらの処理に必要となる操作画面を規定する。
【０１３３】
フロー定義は、帳票データの補正に関する処理も規定する。つまり、イメージアーカイブ２１０からイメージデータ、帳票データをオペレータに提示する処理、帳票データの補正を受け付ける処理などを規定する。画面定義は、補正処理に使用される画面、例えば、イメージデータと帳票データを比較可能な状態で表示する画面、その補正を受け付ける画面などを規定する。
【０１３４】
イメージクライアント２５０とイメージサーバ２２０との通信は、本実施例では、ＨＴＴＰプロトコルによって行うものとした。両者のデータ授受は、第１実施例で説明した電文によって行われる。両者に備えられたアプリケーションコア２５３、２２５は、それぞれが有するＲＥＬＡＸによって、電文の生成、解読を実行する。
【０１３５】
Ｂ−３．イメージ処理：
図１６はイメージ処理全体のフローチャートである。イメージクライアント２５０とイメージサーバ２２０とが連携して実行するワークフロー全体を示した。イメージクライアント２５０で実行する処理は、二重枠で示した。
【０１３６】
まず、イメージクライアント２５０が、帳票イメージの読み込みを行い（ステップＳ５００）、帳票認識を行って帳票データを生成する（ステップＳ５０１）。この帳票データと、イメージデータとを関連づけてデータ登録を行う（ステップＳ５０２）。この処理では、イメージクライアント２５０は、両者を所定のフォーマットに格納して、イメージサーバ２２０に送信する。イメージサーバ２２０は、このデータをイメージアーカイブ２１０の所定領域に格納する。
【０１３７】
データは、種々の形式で格納可能であるが、本実施例では、ＸＭＬで格納するものとした。つまり、帳票データは、項目ごとに所定のタグとともにＸＭＬ形式で記録される。イメージデータは、データを保存しておくパス名が、ＸＭＬ形式で記録される。こうすることにより、帳票データとイメージデータとを容易に関連づけつつ、一元的に管理することが可能となる。本実施例では、この時点では、補正処理、検証処理が未済というステータスを付してデータを登録するものとした。
【０１３８】
イメージサーバ２２０は、データの登録に続いて、業務連携処理を実行する（ステップＳ５０３）。この処理には、例えば、先に示した通り、口座番号の真否の確認などが含まれる。
【０１３９】
こうしてイメージデータおよび帳票データの登録が完了すると、ワークフローは、これらの補正処理に移行する（ステップＳ５０４）。補正は、イメージクライアント２５０で実行するが、その端末およびオペレータは、データ登録時と異なっていても良い。オペレータが、イメージクライアント２５０に「補正処理」を指示すると、イメージクライアント２５０は、イメージアーカイブ２１０に登録されているデータのうち、補正処理、検証処理が共に未済となっているデータを提示する。オペレータは、イメージデータと帳票データとを対比しながら、適宜、帳票データの修正を実行する。こうして修正されたデータが、再び、イメージサーバ２２０に送信されると、イメージサーバ２２０は、イメージアーカイブ２１０の内容を更新する。これとともに、登録時と同様、業務連携処理を実行する（ステップＳ５０５）。この時点では、データのステータスは、検証処理が未済に変更される。
【０１４０】
次に、ワークフローは、イメージデータおよび帳票データの検証処理に移行する（ステップＳ５０６）。処理の手順は、データ補正処理（ステップＳ５０４）と同様である。検証処理は、帳票データの誤りの有無を更に確認するための処理であり、省略することも可能である。
【０１４１】
イメージクライアント２５０が、検証処理が完了したデータをイメージサーバ２２０に送信すると、イメージサーバは、検証処理済みのステータスを付して、イメージアーカイブ２１０の内容を更新することによって、このデータ紹介に許可を与える（ステップＳ５０７）。以上の処理を経て、イメージデータおよび帳票データは、以後、イメージクライアント２５０、基幹業務システム３００からの紹介が可能となる。
【０１４２】
イメージクライアント２５０は、主としてＸＭＬアプリケーションプログラムによって、上記処理を実現する。実質的な処理内容は、イメージクライアント２５０の業務定義２５１によって与えられることになる。帳票データの生成（ステップＳ５０１）については、ＸＭＬアプリケーションプログラムに非依存の帳票認識部２５４を起動する部分、および認識結果を取得する部分でＸＭＬアプリケーションプログラムが関連する。
【０１４３】
イメージサーバ２２０も同様に、主としてＸＭＬアプリケーションプログラムによって、上記処理を実現する。図１６では、図示を省略したが、実質的な処理内容は、イメージサーバ２２０側の業務フロー定義２２３によって規定される。
【０１４４】
以上で説明した第２実施例のイメージ処理システムによれば、帳票データおよびイメージデータを用いた処理に、ＸＭＬアプリケーションプログラムを適用することができる。金融機関で利用される帳票は、金融機関および取引内容によって、多種多様であり、イメージ処理も多種多様な処理が要求される。ＸＭＬアプリケーションプログラムは、第１実施例で説明した通り、実質的な処理内容を業務定義２５１、業務フロー定義２２３で規定することができる。従って、このように多種多様な処理が要求される場合でも、比較的容易に処理内容のカスタマイズ、および改変を実現することができる。
【０１４５】
第２実施例では、金融機関のイメージ処理を例にとって説明したが、これに限らず、例えば、保険会社における保険金の支払い業務など、帳票を利用した種々の業務に適用することが可能である。
【０１４６】
Ｃ．変形例：
以上の実施例では、いずれも情報処理装置１００、イメージクライアント２５０、イメージサーバ２２０などがそれぞれネットワークで接続されている構成を例示した。ＸＭＬアプリケーションプログラムは、必ずしもネットワークで接続されたコンピュータ上で起動させる必要はなく、スタンドアロンで起動させることもできる。スタンドアロンで起動させる場合には、処理に要するフロー定義、画面定義を予め装置内に記憶させておくものとしてもよいし、ＣＤ−ＲＯＭなどの記録媒体を利用して提供するものとしてもよい。
【０１４７】
以上の実施例では、ＸＭＬアプリケーションプログラムがソフトウェア的に構築されている場合を例示した。例えば、実行エンジン１２０、アプリケーションブラウザ１３０、メッセージバス１４０などの機能を実現する回路を用意することによって、ハードウェア的にＸＭＬアプリケーションプログラムを実現することも可能である。かかる場合でも、回路の大幅な変更、置換を伴わず、処理内容の改変を行うことができる利点がある。
【０１４８】
第１実施例で説明したＸＭＬアプリケーションプログラムの機能ブロックは、必ずしも全てを備えている必要はない。例えば、実行エンジン１２０の基本的な機能、即ち、フロー定義１４によって処理を進める機能のみを備え、電文１６の処理、画面表示に関する処理は、ＸＭＬアプリケーションプログラムに非依存の方法を採用してもよい。同様に、電文１６の処理、画面表示に関する処理のみをＸＭＬアプリケーションプログラム依存としてもよい。
【０１４９】
以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。例えば、以上の制御処理はソフトウェアで実現する他、ハードウェア的に実現するものとしてもよい。
【０１５０】
【発明の効果】
本発明によれば、外部から与える電子文書の内容を変更するだけで、情報処理装置自体のソフトウェアまたはハードウェア構成を大幅に改変するまでなく、情報処理機能の追加、改変、カスタマイズなどを行うことができる。
【図面の簡単な説明】
【図１】実施例としての情報処理装置のシステム構成を示す説明図である。
【図２】フロー定義１４の概要を示す説明図である。
【図３】カーソル制御コマンドの概要を示す説明図である。
【図４】画面定義の概要を示す説明図である。
【図５】部品間の連携を示す説明図である。
【図６】電文の生成、解読方法を示す説明図である。
【図７】実行エンジン１２０のモジュール構成を示す説明図である。
【図８】アプリケーションブラウザ１３０のモジュール構成を示す説明図である。
【図９】メッセージバスのモジュール構成を示す説明図である。
【図１０】起動処理のフローチャートである。
【図１１】起動後の画面構造を模式的に示す説明図である。
【図１２】実行エンジンが実行する処理のフローチャートである。
【図１３】画面操作処理のフローチャートである。
【図１４】イメージ処理システムの構成を示す説明図である。
【図１５】イメージワークフローシステム２００のソフトウェア構成を示す説明図である。
【図１６】イメージ処理全体のフローチャートである。
【符号の説明】
１０…Ｗｅｂサーバ
１２…画面定義
１４…フロー定義
１６…電文
１００…情報処理装置
１０２…Ｗｅｂブラウザ
１０４…ベースアプレット
１１０…カスタマイズモジュール
１１５…アペンダ
１１６…ＲＥＬＡＸ選択
１１７…通信プラグイン
１２０…実行エンジン
１２１…メイン制御
１２２…フロー制御
１２３…コンテキスト制御
１２４…キュー制御
１２５…トランザクション制御
１２６…通信スレッド
１３０、１３０Ａ、１３０Ｂ…アプリケーションブラウザ
１３１…部品
１３１ａ…ＧＵＩ部品
１３１ｂ…ロジック部品
１３３…メイン制御
１３４…画面生成部
１３５…画面表示部
１３６…画面非表示部
１３７…画面破棄部
１３８…パス設定部
１３９…オブジェクトテーブル
１４０…メッセージバス
１４１…データアイテム
１４２…データアイテム取得部
１４３…データ収集部
１４４…データクリア部
１４５…データアイテムテーブル
１４６…バス取得部
１４７…バスクリア部
１４８…バス
２００…イメージワークフローシステム
２０２…帳票
２０４…スキャナ
２１０…イメージアーカイブ
２２０…イメージサーバ
２２１…Ｗｅｂ紹介部
２２２…基幹業務連携部
２２３…業務フロー定義
２２４…アプリケーション部品
２２５…アプリケーションコア
２５０…イメージクライアント
２５１…業務定義
２５２…アプリケーション部品
２５３…アプリケーションコア
２５４…帳票認識部
２５５…帳票定義
３００…基幹業務システム
３１０…業務データベース
３２０…業務サーバ
３３０…ホストコンピュータ
【図１】
0004490026.tif 000002
【図２】
0004490026.tif 000003
【図３】
0004490026.tif 000004
【図４】
0004490026.tif 000005
【図５】
0004490026.tif 000006
【図６】
0004490026.tif 000007
【図７】
0004490026.tif 000008
【図８】
0004490026.tif 000009
【図９】
0004490026.tif 000010
【図１０】
0004490026.tif 000011
【図１１】
0004490026.tif 000012
【図１２】
0004490026.tif 000013
【図１３】
0004490026.tif 000014
【図１４】
0004490026.tif 000015
【図１５】
0004490026.tif 000016
【図１６】
0004490026.tif 000017