JP2003216427A - カスタマイズ可能な情報処理装置 - Google Patents

Abstract

(57)【要約】 【課題】 ソフトウェアの改変を伴わずに、情報処理
装置における処理内容の更新、カスタマイズを実現す
る。 【解決手段】 ブラウザ上で起動する実行エンジン１２
０、アプリケーションブラウザ１３０、部品１３１ａ、
１３１ｂを用意する。実行エンジン１２０は、ＸＭＬで
記述されたフロー定義１４を読み込み、タグで規定され
たコマンドを順次実行する。画面表示が要求されている
場合には、アプリケーションブラウザ１３０を呼び出
す。アプリケーションブラウザ１３０は、画面定義を読
み込み、各部品を起動して表示画面を生成する。このよ
うに、それぞれ基本的、汎用的な機能のみを備えるソフ
トウェアを用意し、実質的な処理内容をＸＭＬの電子文
書で与えることにより、ソフトウェアの改変を伴うこと
なく、処理内容の改変を実現することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータなど
の情報処理装置で行われる情報処理の内容のカスタマイ
ズを実現するための技術に関する。

【０００２】

【従来の技術】コンピュータを用いた情報処理は、種々
の分野で活用されている。一般に、情報処理の内容は、
コンピュータにインストールされるソフトウェアによっ
て決定される。かかる方法では、情報処理の内容を変更
するためには、ソフトウェアの更新が必要であり、変更
に要する負担が大きい。

【０００３】コンピュータを用いた情報処理の一例とし
て、金融機関で利用される帳票のイメージ処理システム
が挙げられる。イメージ処理システムとは、振込用紙な
ど定型的な帳票をスキャンして得られたイメージデータ
から、いわゆるＯＣＲ機能によって氏名、金額などのデ
ータを取得して、取引処理に活用するためのシステムで
ある。イメージ処理システムでは、取得したデータと、
イメージデータとを比較して、オペレータがデータの修
正を行うこともある。金融機関で使用される振込用紙
は、多種多様であり、そこから取得されるデータの処理
内容も金融機関によって多種多様である。従って、イメ
ージ処理システムでは、類似しているソフトウェアでは
あるが、振込用紙の種類や金融機関などに応じた多様な
ソフトウェアが用いられている。

【０００４】こうした処理の多様性に対処するため、い
くつかの技術が提案されている。第１の技術は、予めカ
スタマイズの余地を含んで、ソフトウェアを構築する手
法である。振込用紙の種類や処理内容など、予め想定さ
れる多様性を包含するように多機能なソフトウェアを構
成しておくことにより、実際に使用する機能をパラメー
タ等で指定するだけで、多様な処理内容を実現すること
が可能となる。

【０００５】第２の技術は、いわゆるオブジェクト指向
と呼ばれるプログラミング手法である。かかる手法で構
成されたソフトウェアは、比較的シンプルな機能を実行
するモジュールの組み合わせで全体の処理を実現してお
り、各モジュールの置換、追加を比較的容易に行うこと
ができる利点がある。モジュールの置換等により、多様
な処理内容を実現することが可能となる。

【０００６】第３の技術は、インターネットで多用され
ているＷｅｂプログラミングと呼ばれる技術である。イ
ンターネット上のサーバから、クライアントに対し、Ｈ
ＴＭＬ（Hyper Text Markup Language）のファイルやス
クリプト等を送信することにより、クライアントにおい
て種々の処理を実現させることができる。例えば、ブラ
ウザを搭載したクライアントでは、ソフトウェアの変更
を伴うまでなく、ＨＴＭＬファイルを変更するだけで多
種多様な表示画面が実現される。

【０００７】

【発明が解決しようとする課題】しかし、情報処理装置
において要求されるカスタマイズに十分対応するために
は、これらの技術では不十分なことがあった。第１の技
術では、ソフトウェアの構築時に予め考慮されている範
囲を超えるカスタマイズが要求された場合には、十分に
対処することができなかった。第２の技術では、新たな
機能を追加する際に、追加機能に対応したモジュールを
作成するとともに、追加されたモジュールを呼び出すよ
う、メインプログラムを改変する必要があり、結局、ソ
フトウェアの改修が必要とされていた。第３の技術で
は、ＨＴＭＬで対応可能な機能は比較的限定されてお
り、十分な情報処理機能を提供するには適していなかっ
た。近年、ＸＭＬ（eXtensible Markup Language）と呼
ばれる技術によって、実現可能な機能の拡大が図られて
はいるものの、それだけでは、十分な情報処理機能を提
供するには至っていない。

【０００８】かかる課題は、イメージ処理システムに関
わらず、情報処理装置に共通する課題であった。また、
情報処理機能の全てをソフトウェア的に実現する装置の
みならず、その一部をハードウェア的に提供する装置に
おいても共通の課題であった。ネットワーク等で接続さ
れた複数の情報処理装置が連動して情報処理を実現する
ようなシステムにおいては、アップデートまたはカスタ
マイズの対象となる装置が多大になるため、上記課題
は、特に、深刻なものであった。

【０００９】本発明は、これらの課題に鑑みてなされた
ものであり、ソフトウェアまたは回路の大幅な改変を伴
わずに、機能の更新、カスタマイズが可能な情報処理装
置を提供することを目的とする。

【００１０】

【課題を解決するための手段】上記課題の少なくとも一
部を解決するために、本発明では、情報処理装置におい
て、以下に示す構成（以下、「第１の構成」と称する）
を適用した。まず、予め設定された所定の基本機能を実
現する複数種類の基本機能部を備える。これらの基本機
能部は、ソフトウェア的に構成されていてもよいし、電
子回路のようにハードウェア的に構成されていてもよい
が、それぞれ個別の要素として構成されたものである。
個別の要素とは、比較的容易に追加および置換が可能に
構成されていることを意味する。

【００１１】かかる情報処理装置における処理内容は、
電子文書の形式で規定する。電子文書とは、上述した複
数種類の基本機能部のうち、処理に使用すべき基本機能
部を特定するものである。情報処理装置は、この電子文
書を入力し、その内容を解析して処理を実行する。処理
は、電子文書に規定された基本機能部を逐次、稼働させ
ることによって実現される。

【００１２】本発明によれば、情報処理装置は、単に、
電子文書に従って各基本機能を呼び出すという汎用的な
機能を備えていることで、種々の処理を実現することが
できる。基本機能の組み合わせによって実現される実質
的な処理内容は、電子文書によって規定されるからであ
る。従って、外部から与える電子文書の内容を変更する
だけで、情報処理装置自体のソフトウェアまたはハード
ウェア構成を大幅に改変するまでなく、情報処理機能の
追加、改変、カスタマイズなどを行うことができる。

【００１３】本発明の情報処理装置では、基本機能部お
よび電子文書の組み合わせによって、以下に例示する通
り、多彩な機能を実現することができる。

【００１４】第１の態様として、基本機能部は、表示画
面を生成する画面生成部を含んでもよい。このとき、電
子文書で、表示画面の内容およびその生成タイミングを
規定しておくと、情報処理装置は、その生成タイミング
に応じて画面生成部を稼働させて画面表示を行うことが
できる。こうすることで、任意のタイミングで、情報処
理装置のインタフェース画面などを表示させることがで
きる。

【００１５】第２の態様として、電子文書には、複数の
処理内容の実施順序を制御するフロー制御情報を含めて
もよい。情報処理装置は、このフロー制御情報に応じた
順序で、それぞれの基本機能部を稼働させる。こうする
ことにより、いわゆる条件分岐、ループなどの複雑なフ
ローを伴う処理を、実現させることができる。フロー制
御情報は、情報処理装置が解釈可能であるとともに、電
子文書に組み込み可能な情報であれば足りる。

【００１６】第３の態様として、基本機能部には、複数
種類の要素表示部を含めることができる。要素表示部と
は、例えば、線、ボタン、テキストなど表示画面を構成
する表示要素を、それぞれ表示するための基本機能部を
意味する。このとき、電子文書は、表示画面を構成する
各表示要素の種類および位置を規定する。情報処理装置
は、この電子文書に基づいて各要素表示部を稼働させる
と、規定された表示画面を生成することができる。電子
文書の内容を変更することにより、多彩な表示画面を比
較的容易に生成することが可能である。

【００１７】第３の態様は、第１の態様と組み合わせて
構成してもよい。つまり、第３の態様における電子文書
を読み込んで、各要素表示部を稼働させる機能を、第１
の態様における画面生成部が実現するものとしてもよ
い。こうすることにより、画面生成のタイミングおよび
変遷を任意に制御しつつ、多彩な表示画面を実現するこ
とができる。

【００１８】第４の態様として、基本機能部には、複数
種類の要素演算部を含めることができる。要素演算部と
は、例えば、四則演算など、情報処理装置に入力された
データについて、所定の演算を実行する基本機能部を意
味する。このとき、電子文書は、データに施すべき演算
の種類を規定する。情報処理装置は、この電子文書に基
づいて各要素演算部を稼働させることで、データの演算
を実行することができる。電子文書の内容を変更するこ
とにより、多彩な演算を比較的容易に実現することが可
能である。

【００１９】本発明の情報処理装置では、先に説明した
課題の少なくとも一部を解決するための別の構成とし
て、以下に示す第２の構成を適用してもよい。第２の構
成においても、複数の基本機能部を備える点は、第１の
構成と共通である。第２の構成では、これらの基本機能
部は、各基本機能部に予め対応づけられたオブジェクト
の状態変化に基づいて起動する機能を有しているものと
する。第２の構成では、情報処理装置は、これらのオブ
ジェクト、および各オブジェクトと基本機能部との関連
付けを管理し、オブジェクトに状態変化が生じた場合に
は、それに関連づけられた基本機能部に対して、状態変
化を通知する。

【００２０】こうすることにより、各基本機能部の稼働
を比較的容易に同期させることができる。また、情報処
理装置自体のソフトウェアおよびハードウェアなどに大
幅な改変を伴うまでなく、基本機能部を追加、置換等す
ることができる。追加等される基本機能部を正常に動作
させるためには、関連づけられるべきオブジェクトを用
意すれば足りるからである。

【００２１】複数の基本機能部を連鎖的に稼働させるた
めには、それぞれの基本機能部が動作結果をいずれかの
オブジェクトに反映させる機能を有することが好まし
い。例えば、第１の機能部、第２の機能部をこの順序で
連鎖的に稼働させる場合を考える。第１の機能部は第１
のオブジェクトによって稼働し、第２の機能部は第２の
オブジェクトによって稼働するものとする。このとき、
第１の機能部が、動作結果を第２のオブジェクトに反映
する機能を有していれば、その動作に連動して第２の機
能部を容易に稼働させることが可能となる。

【００２２】第２の構成の情報処理装置において、基本
機能部に複数種類の要素表示部が含まれている場合、オ
ブジェクトの管理は、複数の表示画面に共通するオブジ
ェクトと、現に表示されている表示画面に関するオブジ
ェクトとを別個に管理することが好ましい。後者のオブ
ジェクトは、表示画面が切換えられた場合には、管理対
象から外すことが可能であるが、前者のオブジェクト
は、表示画面が切換えられるか否かにかかわらず保持し
ておく必要がある。両者を別個に管理することにより、
画面の制御を円滑に行うことが可能となる。

【００２３】第２の構成では、各基本機能部が、自己と
オブジェクトとの対応関係を登録可能とすることが好ま
しい。こうすることにより、基本機能部の稼働状態、稼
働可能性に応じて、オブジェクトとの対応関係が動的に
登録されるため、基本機能部の正常な動作を確保するた
めに要求される対応関係の管理負担を軽減することがで
きる。

【００２４】第２の構成の情報処理装置は、各基本機能
部の稼働に呼応して、それに対応したオブジェクトを生
成することも好ましい。また、稼働中のいずれの基本機
能部とも対応づけられていないオブジェクトを消去する
ことも好ましい。つまり、基本機能部の稼働状況に応じ
て、オブジェクトを動的に生成、消去することが好まし
い。こうすることにより、メモリなどの資源を有効活用
しながら、オブジェクトを管理することができる。

【００２５】本発明の情報処理装置では、先に説明した
課題の少なくとも一部を解決するための別の構成とし
て、以下に示す第３の構成を適用してもよい。第３の構
成における情報処理装置は、ネットワークに接続され、
ネットワークを介した情報の授受に基づいて所定の処理
を行うものとする。このとき、情報処理装置は、送受信
される電文に含むべきデータ、およびフォーマットを規
定する規定文書を記憶しておき、これに基づいて電文の
生成または解読を行う。実質的な電文の生成方法は規定
文書で定義されるため、情報処理装置は、規定文書に従
って電文を生成等する汎用的な機能を有していれば足り
る。第３の構成によれば、規定文書の変更により、多彩
な電文を比較的容易に生成、解読することが可能とな
る。

【００２６】情報処理装置において、処理に関連した複
数のデータが統合的に管理されている場合、送信される
電文に含むべきデータをこのデータ管理部から取得した
り、受信した電文から抽出したデータをこの管理部に通
知したりすることが好ましい。こうすることにより、情
報処理装置と外部とのデータの授受を、電文を介して円
滑に行うことが可能となる。

【００２７】第３の構成において、規定文書は１種類に
限定されるものではなく、複数種類を用いても良い。複
数種類の規定文書を用いる場合、先に説明した電子文書
において、所定で使用すべき規定文書を特定し、規定文
書の使い分けを実現してもよい。電子文書と規定文書と
は、１対１で対応している必要はなく、例えば、一つの
処理において、条件分岐の結果に応じて規定文書を使い
分けるものとしてもよい。

【００２８】以上で説明した、第１〜第３の構成は、そ
れぞれ個別の情報処理装置として適用してもよいし、適
宜、組み合わせて適用してもよい。第１の構成および第
２の構成は、スタンドアロンの装置に適用してもよい
し、ネットワークに接続された装置に適用してもよい。

【００２９】本発明の情報処理装置が実施する処理内容
は、任意に設定可能であるが、本発明を有効に活用可能
な例として、イメージ処理を行うものとしてもよい。つ
まり、本発明は、帳票のイメージデータに基づき所定の
イメージ処理を実行するイメージ処理装置として構成す
ることができる。

【００３０】かかる構成では、イメージ処理装置は、イ
メージ処理に関し、予め設定された所定の基本機能を実
現する複数種類の基本機能部を備える。電子文書は、こ
の基本機能部を特定する形式で、イメージ処理の処理内
容を規定する。イメージ処理装置は、この電子文書に基
づいて、逐次、基本機能部を稼働させることによりイメ
ージ処理を実行する。金融機関で用いられる帳票類は、
非常に多彩であり、その処理内容も多様であるため、本
発明を適用することにより、イメージ処理装置について
金融機関ごとのカスタマイズに要する負担を軽減するこ
とができる。

【００３１】本発明のイメージ処理装置において、例え
ば、基本機能部には、イメージデータに基づいて文字デ
ータまたは数値データを取得するデータ取得部を含むこ
とができる。この場合、電子文書では、例えば、イメー
ジデータから取得を行うべき領域、および取得するデー
タの属性を規定し、イメージ処理装置は、電子文書で規
定されたデータの取得を実現する。こうすることで、多
様な帳票に対して、データの取得を比較的容易に実現す
ることが可能となる。

【００３２】本発明のイメージ処理装置において、例え
ば、基本機能部には、イメージ表示部、データ表示部、
データ修正部を含めることができる。イメージ表示部
は、イメージデータを表示する基本機能部を意味する。
データ表示部は、イメージデータに基づいて取得された
文字データまたは数値データを表示する基本機能部を意
味する。データ修正部は、文字データまたは数値データ
を修正する基本機能部を意味する。このとき、電子文書
では、例えば、イメージデータ、文字データ等の表示態
様、および外部からの入力によって文字データ等を修正
する方法を規定し、イメージ処理装置は、これに基づい
てイメージ等の表示およびデータの修正を実現するもの
としてもよい。本発明を適用することにより、多様な帳
票に対して、これらのデータ修正を比較的容易に実現す
ることができる。

【００３３】ここでは、イメージ処理装置としての代表
的な構成例を示した。先に情報処理装置について説明し
た種々の構成は、そのままイメージ処理装置に適用可能
である。

【００３４】本発明の情報処理装置およびイメージ処理
装置において、電子文書は、種々の形式を採ることが可
能であるが、一例として、ＸＭＬで記述された文書（以
下、ＸＭＬ文書と呼ぶ）とすることが好ましい。ＸＭＬ
文書とは、いわゆるタグを含む、マークアップ言語で記
述された文書である。タグは任意に設定可能である。従
って、ＸＭＬを用いることにより、電子文書に要求され
る種々のコマンドを、タグの形式で比較的容易に規定す
ることが可能となる。

【００３５】本発明は、上述した情報処理装置およびイ
メージ処理装置に限らず、種々の態様で構成することが
可能である。例えば、コンピュータによって上述した処
理を実現する情報処理方法、またはイメージ処理方法と
して構成してもよい。これらの処理を実現するためのコ
ンピュータプログラムとして構成してもよい。本発明
を、コンピュータプログラムとして構成する場合には、
ブラウザ上で稼働可能に構成することが好ましい。例え
ば、ＪＡＶＡ（登録商標）を用いて構成することが好ま
しい。こうすることにより、プラットフォームの区別な
く稼働可能とすることができるとともに、電子文書とし
てＸＭＬ文書を利用しやすいという利点がある。

【００３６】更に、これらの種々のコンピュータプログ
ラムを記憶した記憶媒体として構成してもよい。ここ
で、記憶媒体としては、フレキシブルディスク、ＣＤ−
ＲＯＭ、ＤＶＤ、光磁気ディスク、ＩＣカード、ＩＣチ
ップ、ＲＯＭカートリッジ、パンチカード、バーコード
などの符号が印刷された印刷物、コンピュータの内部記
憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶
装置など光学的、磁気的、電気的にコンピュータが読取
り可能な種々の媒体を利用できる。

【００３７】

【発明の実施の形態】以下、本発明の実施の形態につい
て、以下の項目に分けて説明する。 Ａ．第１実施例： Ａ−１．システム構成： Ａ−２．フロー定義： Ａ−３．画面定義： Ａ−４．部品間の連携： Ａ−５．電文の授受： Ａ−６．実行エンジン： Ａ−７．アプリケーションブラウザ： Ａ−８．メッセージバス： Ａ−１０．起動処理： Ａ−１１．フロー定義のコマンド処理： Ａ−１２．画面操作処理： Ｂ．第２実施例（イメージ処理システム）： Ｂ−１．システム構成： Ｂ−２．ソフトウェア構成： Ｂ−３．イメージ処理： Ｃ．変形例：

【００３８】Ａ．第１実施例： Ａ−１．システム構成：図１は実施例としての情報処理
装置のシステム構成を示す説明図である。情報処理装置
１００は、汎用のパーソナルコンピュータに図示する各
機能ブロックを備えるソフトウェアをインストールする
ことで構成される。ソフトウェアのインストールのみな
らず、これらの機能ブロックをハードウェア的に用意す
ることで構成してもよい。

【００３９】情報処理装置１００は、Ｗｅｂサーバ１
０、およびＡＰサーバ２０とネットワークＩＮＴで接続
されている。ネットワークは、インターネットなど広域
的なネットワークとしてもよいし、ＬＡＮ（Ｌｏｃａｌ
Ａｒｅａ Ｎｅｔｗｏｒｋ）など比較的限定的なネッ
トワークとしてもよい。

【００４０】Ｗｅｂサーバ１０は、情報処理装置１００
からのリクエストに応じて、画面定義１２、フロー定義
１４と呼ばれる電子文書を送信する。画面定義１２と
は、表示画面の内容を規定する電子文書である。フロー
定義１４とは、画面の遷移など処理の流れを規定する電
子文書である。これらの電子文書の内容については、後
述する。これらの電子文書は種々の形式を選択可能であ
るが、本実施例ではＸＭＬで記述されるものとした。

【００４１】ＡＰサーバ２０は、情報処理装置１００と
連携して種々の処理を実行するサーバである。例えば、
端末からの入力データを受けて、ホストコンピュータが
種々の処理を実行するシステムの場合、端末が情報処理
装置１００に相当し、ホストコンピュータがＡＰサーバ
２０に相当する。情報処理装置１００とＡＰサーバ２０
との情報の授受は、電文１６によって行われる。電文１
６の生成方法については後述する。電文１６は種々の形
式を選択可能であるが、本実施例ではＸＭＬで記述され
るものとした。

【００４２】なお、本実施例では、情報処理装置１００
とＷｅｂサーバ１０、ＡＰサーバ２０とをネットワーク
で接続するシステム構成を採用したが、情報処理装置１
００はスタンドアロンで稼働する装置として構成しても
よい。Ｗｅｂサーバ１０、ＡＰサーバ２０は必ずしも必
要ではなく、実行すべき情報処理の内容に応じて、情報
処理装置１００をスタンドアロンで稼働する構成を採っ
ても良い。

【００４３】情報処理装置１００に備えられている各機
能ブロックの構成について説明する。情報処理装置１０
０には、所定のオペレーティングシステム上で稼働し、
ＨＴＭＬ等のマークアップ言語で記述されたファイルを
閲覧するためのソフトウェア、Ｗｅｂブラウザ１０２が
インストールされている。各機能ブロックは、このＷｅ
ｂブラウザ１０２上で稼働するように構成されている。
本実施例では、ＪＡＶＡ（登録商標）を用いることによ
り、かかる構成を実現した。Ｗｅｂブラウザ１０２上で
稼働可能としたのは、プラットフォーム非依存のソフト
ウェア構成が可能であるという利点があるからである。
Ｗｅｂブラウザ１０２と無関係に稼働するよう構成して
も構わない。

【００４４】ベースアプレット１０４は、Ｗｅｂブラウ
ザ１０２の上で稼働し、情報処理装置１００の各機能ブ
ロック、実行エンジン１２０、アプリケーションブラウ
ザ１３０、メッセージバス１４０などを稼働するための
プラットフォームを提供する。ベースアプレット１０４
およびこれらの各機能ブロックによって情報処理を実現
する全体の機構を、本明細書では、ＸＭＬアプリケーシ
ョンプログラムと称するものとする。本実施例では、こ
れらの機構は、名称の通り、ＸＭＬをベースとして構築
されているが、ＸＭＬアプリケーションプログラムは、
広義には、以下で説明する機構の概念を示すものであ
り、必ずしもＸＭＬベースで構築されているものには限
られない。

【００４５】ベースアプレット１０４は、ＪＡＶＡのア
プレットとして構成されている。ベースアプレット１０
４は、その上に構築される各機能ブロックの起動、終了
を行う機能、およびコンピュータのキーボード、マウス
などの操作結果（以下、「キーイベント」と称する）
を、ＸＭＬアプリケーションプログラムの各機能ブロッ
クに受け渡す機能を奏する。

【００４６】実行エンジン１２０は、フロー定義１４の
内容に基づいて、全体処理を制御する機能を奏する。フ
ロー定義１４において、画面の表示、遷移が規定されて
いる場合には、適宜、アプリケーションブラウザ１３０
を起動させる。また、ＡＰサーバ２０とのデータ授受が
規定されている場合には、電文１６のやりとりを行う。
電文１６の内容は、ＡＰサーバ２０によって異なるた
め、カスタマイズモジュール１１０によって適応させ
る。実行エンジン１２０は、ＡＰサーバ２０から受け取
ったデータをメッセージバス１４０に展開したり、逆
に、ＡＰサーバ２０に送信すべきデータをメッセージバ
ス１４０から収集したりもする。

【００４７】アプリケーションブラウザ１３０は、実行
エンジン１２０によって起動され、画面定義１２に従っ
て、画面を表示し、また、この表示画面を通じた操作を
実現する。アプリケーションブラウザ１３０は、Ｗｅｂ
ブラウザとは別のプログラムである。アプリケーション
ブラウザ１３０には、ＧＵＩ部品１３１ａ、ロジック部
品１３１ｂと呼ばれる基本的な機能を実現するソフトウ
ェアが用意されている。ＧＵＩ部品１３１ａとは、ボタ
ン、線など表示画面を構成する表示要素を生成するため
のソフトウェアであり、表示要素の種類に応じて複数用
意されている。ロジック部品１３１ｂとは、四則演算、
入力チェックなど、画面内でのデータに関する処理を実
現するためのソフトウェアであり、処理内容に応じて複
数用意されている。アプリケーションブラウザ１３０
は、画面定義１２に従って、これらの部品を起動させ、
表示画面に関する種々の処理を実現する。

【００４８】メッセージバス１４０は、ＧＵＩ部品１３
１ａおよびロジック部品１３１ｂの稼働制御をする。メ
ッセージバス１４０は、ＧＵＩ部品１３１ａ、ロジック
部品１３１ｂに対応づけられたデータアイテム１４１を
複数保持している。各部品は、対応するデータアイテム
１４１の状態変化をトリガとして起動するとともに、そ
の処理結果をデータアイテム１４１に反映させるよう構
成されている。メッセージバス１４０は、管理下にある
いずれかのデータアイテム１４１の状態変化が生じた場
合には、それを部品に通知することによって、各部品を
起動させる。メッセージバス１４０は、合わせて処理に
必要なデータを保持する機能も奏する。先に説明した通
り、実行エンジン１２０がＡＰサーバ２０との間で授受
するデータは、データアイテム１４１として、メッセー
ジバス１４０で管理される。

【００４９】情報処理装置１００は、上述の構成によっ
て、種々の処理を実現する。実行エンジン１２０、アプ
リケーションブラウザ１３０、メッセージバス１４０
は、処理内容に依存したソフトウェアではなく、汎用的
な機能を実現するソフトウェアである。処理内容に依存
したソフトウェアは、ＧＵＩ部品１３１ａ、ロジック部
品１３１ｂなどのモジュールで用意されている。実質的
な処理内容は、フロー定義１４、画面定義１２などの電
子文書で、これらの部品を使う順序等を規定する形式で
特定される。従って、情報処理装置１００は、ソフトウ
ェアの大幅な改変、追加を行うまでなく、電子文書の変
更を行うことにより、処理内容を簡便に変更等すること
ができる利点を有している。以下、図中に示した各構成
要素について、順次、詳細に説明する。

【００５０】Ａ−２．フロー定義：図２はフロー定義１
４の概要を示す説明図である。フロー定義１４とは、実
行エンジン１２０の動作を規定する電子文書であり、本
実施例では、ＸＭＬによって記述される。

【００５１】フロー定義１４は、ＸＭＬ宣言文、ＤＴＤ
（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏ
ｎ）、および本文から構成される。ＤＴＤとは、フロー
定義内で使用されるタグを定義する部分である。ＤＴＤ
のみをフロー定義とは、別の文書として用意しても構わ
ない。

【００５２】本文は、種々のタグによって、実行エンジ
ン１２０が実行すべき処理内容を規定している。実行エ
ンジン１２０は、原則として、フロー定義の本文中のタ
グを先頭から順に解釈して、タグで規定されるコマンド
を実行する。例えば、フロー定義中に、画面生成のコマ
ンドを読み込んだ場合には、アプリケーションブラウザ
１３０を起動することで、画面表示を行う。画面表示に
は、画面定義１２が必要であるため（図１参照）、画面
生成コマンドでは、アプリケーションブラウザ１３０が
参照すべき画面定義１２のパスも併せて指定される。

【００５３】図の下方に、タグによって規定されるコマ
ンド例を示した。コマンドは、処理コマンド、カーソル
制御コマンドの２種類に大別される。処理コマンドと
は、実行エンジン１２０が実質的に行う処理内容を規定
するコマンドである。例えば、図示する通り、ＡＰサー
バ２０への送受信、キューへの格納、取りだし、画面の
退避、復帰などのコマンドが含まれる。画面の退避、復
帰などが、画面生成コマンドに相当する。各コマンドの
内容は、実行エンジン１２０の機能説明と併せて後述す
る。

【００５４】カーソル制御コマンドとは、フロー定義に
おけるタグの解釈、実行順序を規定するコマンドであ
る。先に説明した通り、実行エンジン１２０は、原則と
して先頭から順にタグを実行する。カーソルとは、実行
エンジン１２０が処理を実行しているタグを意味する。
カーソル制御コマンドとは、この原則に反して、カーソ
ルの位置を移動させるためのコマンドである。上方の図
に示す通り、カーソル移動コマンドを含めることによ
り、例えば、処理の異動先をタグＤ、タグＥに切り換え
る条件分岐を実現することができる。

【００５５】本実施例では、カーソル制御コマンドとし
て、図中に示す１０種類を用意した。図３はカーソル制
御コマンドの概要を示す説明図である。一般にＸＭＬの
タグはツリー構造をなしていることから、フロー定義１
４は、図３に示すようなツリー構造で示すことができ
る。

【００５６】カーソル制御コマンド「ＦＬＯＷＤＥＦ」
は、フロー定義のルートを規定するコマンドである。こ
のコマンドに対して、実行エンジン１２０は、≡ｍａｉ
ｎ≡という名称のサブルーチンにカーソルを移動する。

【００５７】コマンド「ＳＵＢ」は、サブルーチン宣言
のコマンドである。図３の例では、≡ｍａｉｎ≡、≡ｙ
ｏｋｏ≡、≡ｔａｔｅ≡という３種類のサブルーチンが
用意されている場合を例示した。コマンド「ＥＸＩＴＳ
ＵＢ」は、サブルーチン終了のコマンドである。このコ
マンドに対して、実行エンジン１２０は、サブルーチン
を抜け出し、次のタグにカーソルを進める。

【００５８】コマンド「ＧＯＳＵＢ」は、サブルーチン
呼出のコマンドである。図示する通り、「ＧＯＳＵＢ
≡ｙｏｋｏ≡」というタグに対して、実行エンジン１２
０は、カーソルをサブルーチン≡ｙｏｋｏ≡に移動させ
る。

【００５９】コマンド「ＳＷＩＴＣＨ」は、条件分岐を
実現するコマンド、コマンド「ＣＡＳＥ」は条件に応じ
たカーソルの移動先を示すコマンド、コマンド「ＤＥＦ
ＡＵＬＴ」はデフォルトの処理内容を示すコマンドであ
る。図３の例では、コマンドＳＷＩＴＣＨによって、≡
ｃｏｎｄｉｔｉｏｎ≡と称するオブジェクトの状態に応
じて条件分岐が行われる。このオブジェクト≡ｃｏｎｄ
ｉｔｉｏｎ≡が≡ｆｉｎｅ≡の状態にある場合には、Ｃ
ＡＳＥ≡ｆｉｎｅ≡以下の処理が実行される。オブジェ
クト≡ｃｏｎｄｉｔｉｏｎ≡が≡ｂａｄ≡の状態にある
場合には、ＣＡＳＥ≡ｂａｄ≡以下の処理が実行され
る。オブジェクト≡ｃｏｎｄｉｔｉｏｎ≡が、これらい
ずれの状態にも該当しない場合には、ＤＥＦＡＵＬＴ以
下の処理が実行される。

【００６０】コマンド「ＬＯＯＰ」は、一定範囲の処理
を繰り返し実行するためのコマンドであり、コマンド
「ＥＸＩＴＬＯＯＰ」はループの終端を示すコマンドで
ある。このコマンドに対して、実行エンジン１２０は、
ＬＯＯＰからＥＸＩＴＬＯＯＰの間の処理を繰り返し実
行する。

【００６１】コマンド「ＮＯＤＡＴＡ」は、参照したデ
ータの有無に応じて処理内容を切り換えるためのコマン
ドである。図３の例では、参照したデータが無い場合に
は、タグＡ，タグＢで規定される処理を実行し、データ
が存在する場合には、タグＣで規定される処理を実行す
る。

【００６２】このように、カーソル制御コマンドをフロ
ー定義中に入れることにより、条件分岐、繰り返し処理
などを含む、複雑な処理の記載が可能となる。なお、図
２および図３で示した種々のコマンドは例示に過ぎず、
コマンドの種類および多少は、これらに限定されるもの
ではない。

【００６３】Ａ−３．画面定義：図４は画面定義の概要
を示す説明図である。画面定義１２とは、アプリケーシ
ョンブラウザ１３０の動作を規定する電子文書であり、
本実施例では、ＸＭＬで記述される。

【００６４】画面定義１２の本文は、種々のタグによっ
て、画面の構成や画面で行われる操作内容を規定してい
る。タグは、画面情報、部品情報の２種類に大別され
る。画面情報とは、画面定義１２によって定義される画
面に対し、画面ＩＤを与えるタグである。画面定義１２
は、情報処理装置１００で用いられる画面ごとに用意さ
れている。画面ＩＤは、それらの画面を識別するための
情報である。

【００６５】部品情報は、ＧＵＩ部品１３１ａ、ロジッ
ク部品１３１ｂを起動するために必要な種々の情報を定
義する。ＧＵＩ部品１３１ａには、文字列表示、文字列
入力、画像表示、ボタンなど画面の表示要素を構成する
種々のソフトウェアが含まれる。ロジック部品１３１ｂ
には、四則演算、入力条件チェックなど、画面上の操作
に関する種々のソフトウェアが含まれる。以下の説明で
は、混同を回避するため、特に断らない限り、ＧＵＩ部
品１３１ａ、ロジック部品１３１ｂとして用意されたソ
フトウェアパッケージを「部品」と称し、これらによっ
て生成された個別の表示要素その他のオブジェクトを、
「部品オブジェクト」と称するものとする。

【００６６】部品情報は、ＧＵＩ部品１３１ａ、ロジッ
ク部品１３１ｂを用いて生成される部品に与えられる部
品ＩＤ、部品のクラス、場所、大きさ、パラメータなど
を、それぞれ与えるタグである。画面内には、同じ部品
から生成された部品オブジェクトが複数存在する場合が
ある。例えば、ボタンというＧＵＩ部品１３１ａを用い
て、ボタンという部品オブジェクトを複数生成させる場
合がある。部品ＩＤは、こうして生成された部品オブジ
ェクトそれぞれを個別に管理するための識別情報であ
る。部品の場所、大きさは、例えば、画面上に定義され
た座標系に基づいて設定することができる。部品のパラ
メータとしては、例えば、ボタンの形状や表示色、文字
のフォントなどの指定が挙げられる。

【００６７】アプリケーションブラウザ１３０は、画面
定義を先頭から順に読み込み、それぞれのタグに従っ
て、処理を実行する。部品ＩＤ、部品の位置、大きさな
どを指定するそれぞれのタグが見いだされると、アプリ
ケーションブラウザ１３０は、このタグに従って、各部
品を起動するための処理を実行する。この処理によっ
て、画面には、それぞれの部品オブジェクトが表示さ
れ、画面上での操作が実現される。なお、図４に示し
た、タグ、ＧＵＩ部品１３１ａ、ロジック部品１３１ｂ
は、例示に過ぎず、その数および種類は、これらに限定
されるものではない。

【００６８】Ａ−４．部品間の連携：図５は部品間の連
携を示す説明図である。本実施例では、アプリケーショ
ンブラウザ１３０は、メッセージバス１４０を介してそ
れぞれの部品を起動するものとした。

【００６９】図示する通り、メッセージバス１４０は、
データアイテムを統合的に管理する。データアイテム
は、固有の値を有するとともに、アプリケーションブラ
ウザ１３０で用いられる部品と関連付けられている。こ
の関連付けは、それぞれデータアイテムごとに登録され
ている。図中の例では、データアイテムＡは、値Ａを有
するとともに、部品Ａと関連づけられている。データア
イテムＢは、値Ｂを有するとともに、部品Ｂと関連づけ
られている。メッセージバス１４０は、データアイテム
について、値の変更が生じた場合には、それぞれ関連づ
けられた部品に、その変更を通知する機能を有してい
る。かかる機能に基づき、本実施例では、各部品を以下
に示す手順で起動させることができる。

【００７０】一例として、画面定義１２において、部品
Ａの起動が規定されている場合を考える。アプリケーシ
ョンブラウザ１３０は、このタグを読み込むと、データ
アイテムＡが保持する値Ａを、部品Ａの起動トリガとな
るべき値に変更する。メッセージバス１４０は、この変
更を、データアイテムＡに関連づけられた部品Ａに通知
する。部品Ａは、この通知を受けて起動する。ここで、
部品Ａは、起動後に、その処理結果に応じてデータアイ
テムＢの値を変更するようプログラミングされているも
のとすると、部品Ａの起動によって、データアイテムＢ
の値Ｂが変更される。メッセージバス１４０は、この変
更を、データアイテムＢに関連づけられた部品Ｂに通知
する。部品Ｂは、この通知を受けて起動する。

【００７１】このように、メッセージバス１４０に管理
されたデータアイテムを介して、複数の部品を比較的容
易に連動させることができる。例えば、ボタンが押され
た場合に、ボタンの表示変更と連動して文字列の表示内
容を変えることが容易に実現される。

【００７２】また、データアイテムを介して各部品を起
動させることにより、新たな部品の追加、部品の置換を
比較的容易に実現することも可能となる。例えば、部品
Ａに連動して起動する新たな部品Ｃを追加する場合を考
える。この場合には、アプリケーションブラウザ１３０
に部品Ｃのソフトウェアパッケージを用意するととも
に、データアイテムＢの対象部品に、部品Ｃを追加すれ
ば足りる。部品Ａの起動によってデータアイテムＢの値
が変更されると、メッセージバス１４０は、その変更
を、部品Ｂ、部品Ｃに通知するため、これらの部品を起
動させることができる。このように、部品Ａの内容は改
変するまでなく、部品Ａに連動する部品の追加等を容易
に実現することができるのである。

【００７３】本実施例では、部品間のこうした柔軟な連
携を実現するため、各部品を起動するのに、図５で示し
た方法を適用した。この利点を考慮しない場合、例え
ば、部品Ａが直接、部品Ｂ、部品Ｃなどを起動する方法
を適用しても構わない。

【００７４】Ａ−５．電文の授受：図６は電文の生成、
解読方法を示す説明図である。実行エンジン１２０は、
ＡＰサーバ２０と電文１６によってデータを授受する。
電文１６は、データの種類およびＡＰサーバ２０で用意
されるアプリケーションソフトの内容に応じたフォーマ
ットで構成される必要がある。実行エンジン１２０は、
図６に示す構成により、こうした多種多様なフォーマッ
トの電文１６を、比較的容易に生成することができる。

【００７５】実行エンジン１２０は、電文１６の送受信
時には、そのフォーマットを規定するための電子文書、
ＲＥＬＡＸ１１２を読み込む。ＲＥＬＡＸ１１２は種々
の形式を採ることができるが、本実施例では、ＸＭＬで
記述されるものとした。送受信される電文１６のフォー
マットは単一ではないから、ＲＥＡＬＸ１１２も複数用
意されている。ＲＥＬＡＸ１１２は、予め情報処理装置
１００内に保持されているものとしてもよいし、Ｗｅｂ
サーバ１０などから供給されるものとしてもよい。

【００７６】データの送受信を伴う処理の実行時には、
フロー定義１４において、使用すべきＲＥＬＡＸ１１２
が併せて指定される。図中に一例を示した。ここでは、
条件分岐における条件が”ｆｉｎｅ”に該当する場合に
は、使用すべきＲＥＬＡＸとしてパスＡが規定され、”
ｂａｄ”に該当する場合には、パスＢが規定されてい
る。このパス名が、実行エンジン１２０からカスタマイ
ズモジュール１１０に受け渡されると、カスタマイズモ
ジュール１１０がパス名に応じたＲＥＬＡＸ１１２を選
択し、それに基づいて送信用の電文１６の作成、または
受信した電文１６の解読を行う。送受信に伴うデータの
授受は、メッセージバス１４０との間で行う。

【００７７】実行エンジン１２０は、それぞれの電文１
６に依存した生成機能は有さず、ＲＥＬＡＸ１１２に基
づいた電文１６を作成するという汎用的な機能を有して
いる。かかる汎用的な機能を実行エンジン１２０に備え
ることにより、実行エンジン１２０の改変を要せずに、
多種多様な電文１６を生成することが可能となる。

【００７８】Ａ−６．実行エンジン：図７は実行エンジ
ン１２０のモジュール構成を示す説明図である。実行エ
ンジン１２０には、図示する機能ブロックがそれぞれソ
フトウェア的に構成されている。各機能ブロックは、メ
イン制御１２１の制御下で稼働する。

【００７９】フロー制御１２２は、フロー定義を読み込
み、その内容に応じて処理を進める機能を奏する。先に
図２で説明した通り、フロー定義には、処理コマンド、
カーソル制御コマンドが含まれる。フロー制御１２２
は、カーソル制御コマンドの内容を解釈し、これに応じ
たカーソル移動を実現する。処理コマンドについては、
メイン制御１２１が内容を解釈し、それに応じた機能ブ
ロックをそれぞれ稼働させる。

【００８０】コンテキスト制御１２３は、画面表示など
の制御を実現する。「Ｐｕｓｈ」（画面の待避）、「Ｐ
ｏｐ」（画面の復帰）などの処理コマンド（図２参照）
に呼応して起動される。コンテキスト制御１２３は、ア
プリケーションブラウザ１３０を適宜、起動させたり停
止させたりして、これらの画面表示に関する制御を実行
する。

【００８１】トランザクション制御１２５は、ＡＰサー
バ２０との電文の授受に関する通信制御を実行する。
「Ｕｐｌｏａｄ」（サーバへの送信）、「Ｔｒａｎｓａ
ｃｔｉｏｎ」（サーバとの通信）などの処理コマンド
（図２参照）に呼応して起動される。本実施例では、電
文は、ＲＥＬＡＸに基づき生成される。トランザクショ
ン制御１２５は、ＲＥＬＡＸ選択１１６、アペンダ１１
５、通信プラグイン１１７を用いて電文の処理を実行す
る。ＲＥＬＡＸ選択１１６は、電文の生成、解読に適用
すべきＲＥＬＡＸを選択する機能を奏する。アペンダ１
１５は、送信する電文に含めるべきデータについて、ヘ
ッダその他の付加的な情報を生成する。通信プラグイン
１１７は、通信プロトコルに応じて、ＡＰサーバ２０と
の電文の送受信を行う。これらの機能は、ＡＰサーバ２
０の機能、通信プロトコルの種類などに応じてカスタマ
イズが必要であるため、本実施例では、実行エンジン１
２０の汎用的な機能ブロックとは区分されたカスタマイ
ズモジュール１１０として用意した。

【００８２】キュー制御１２４は、トランザクション制
御１２５、コンテキスト制御１２３などの同期を採る機
能を奏する。キュー制御１２４は、「Ｑｕｅｕｅ」（キ
ューへの格納）、「Ｄｅｑｕｅｕｅ」（キューからの取
り出し）などの処理コマンド（図２参照）に応じて起動
される。キュー制御１２４は、トランザクション制御１
２５に受け渡すべき通信スレッド１２６を生成して、キ
ューに格納する。トランザクション制御１２５は、適当
なタイミングで、このキューに基づいてＡＰサーバ２０
との通信を実行する。ＡＰサーバ２０から受信したデー
タに応じて画面を表示する場合、通信スレッド１２６
は、結果を保持しておき、適当なタイミングで、画面表
示するためのコンテキスト制御１２３を起動させる。こ
のようにキューを用いることにより、ＡＰサーバ２０と
の通信およびその結果保持を事前に行っておくことが可
能となり、画面の遷移等を円滑に進めることができる。

【００８３】Ａ−７．アプリケーションブラウザ：図８
はアプリケーションブラウザ１３０のモジュール構成を
示す説明図である。アプリケーションブラウザ１３０に
は、メイン制御１３３の制御下で稼働する各機能ブロッ
クが用意されている。

【００８４】画面生成部１３４は、画面定義の内容に基
づいて表示画面を構成する部品オブジェクトを生成する
機能を奏する。画面表示部１３５は、メイン制御１３３
からの指示に応じて、生成された部品オブジェクトを順
次、表示させ、画面を構成する機能を奏する。画面非表
示部１３６は、逆に、それぞれの部品オブジェクトを停
止させて画面を消去する。画面破棄部１３７は、部品オ
ブジェクト自体を破棄して、画面に関する情報を削除す
る。パス設定部１３８は、それぞれの画面を特定するた
めのパス名、即ち、画面ＩＤを設定する。

【００８５】画面で用いられる部品オブジェクトは、部
品１３１によって生成され、オブジェクトテーブル１３
９によって管理される。部品１３１は、先に説明したＧ
ＵＩ部品１３１ａ、ロジック部品１３１ｂの双方が含ま
れ得る。アプリケーションブラウザ１３０で実現される
上述の各機能は、オブジェクトテーブル１３９への各部
品オブジェクトの登録、表示、停止などの作用を施すこ
とによって実行される。

【００８６】Ａ−８．メッセージバス：図９はメッセー
ジバスのモジュール構成を示す説明図である。メッセー
ジバス１４０は、データアイテム１４１を一元的に管理
する機能を奏する。本実施例では、メッセージバス１４
０の内部に、複数のバス１４８を構築し、データアイテ
ム１４１の種類に応じてバスごとに区分して管理するも
のとした。これらのバスは、予め固定的に用意されてい
るものに限られず、必要に応じて動的に生成されるもの
も含まれる。

【００８７】バス取得部１４６はバス１４８の生成を行
う。バスクリア部１４７は、不要になったバスを消去す
る。本実施例では、バス１４８として８種類を用意し
た。同一種類のバスが複数生成される場合もある。例え
ば、先読画面に関するバス［６］〜［８］は、画面の内
容に応じて複数生成される場合がある。

【００８８】各バスに対応して、データアイテムを管理
するための機能ブロックが設けられる。データアイテム
取得部１４２は、管理対象となっているデータアイテム
の状態を示す値を取得する。データアイテム取得部１４
２は、データアイテムを生成する機能も奏する。先に説
明した通り、データアイテムは、部品の連携を取るため
に活用されるオブジェクトであるから、本実施例では、
部品の稼働状態に応じてデータアイテムを動的に生成す
るものとした。データアイテム取得部１４２は、部品の
稼働等に必要なデータアイテムが管理対象に含まれてい
るか否かの検索を行い、含まれていない場合には、適
宜、データアイテムを生成するとともに、管理対象に加
える。こうすることにより、データアイテムの管理に際
し、ハードウェア資源を有効活用することができる。

【００８９】データ収集部１４３は、実行エンジン１２
０が電文に含めるためのデータを、データアイテムから
収集する。データクリア部１４４は、データアイテムが
保持するデータをクリアする。管理対象となるデータア
イテムは、データアイテムテーブル１４５に登録されて
おり、上述の機能は、このデータアイテムテーブル１４
５を参照して実行される。

【００９０】図中にデータアイテム１４１の機能を列挙
した。データアイテム１４１は、図示する５つの機能を
有している。値設定とは、データアイテムが保持する値
を、外部から通知された値に設定し、値の変更が生じた
場合には、関連づけられている部品に通知する機能であ
る。先に図５で説明した連携を実現するための機能に相
当する。値取得とは、外部からの問い合わせに対し、デ
ータアイテム１４１が保持している値を応答する機能で
ある。部品登録・管理とは、値の変更が生じた場合に通
知すべき部品を管理する機能である。部品登録解除およ
び全部品登録解除は、部品の登録を個別またはまとめて
解除する機能である。これらの機能により、データアイ
テム１４１は、図５で説明した通り、部品の起動、およ
び連携を制御することができる。

【００９１】データアイテム１４１への部品の登録は、
本実施例では、各部品が能動的に行うものとした。図９
中には部品１３１が有する機能を例示した。

【００９２】部品１３１は、図示する５つの機能を有し
ている。変更検知とは、データアイテム１４１の値に変
更があった場合に、それを検知する機能である。データ
アイテム１４１からの変更通知を受信する機能に相当す
る。通知とは、部品オブジェクトの生成、表示、非表
示、破棄などを外部に通知する機能である。データアイ
テム取得とは、部品１３１が関連づけられるべきデータ
アイテム１４１を検索する機能である。データアイテム
監視とは、関連づけられるべきデータアイテム１４１に
対し、自己の登録を行う機能である。パラメータ値取得
とは、部品オブジェクトの生成時に指定されたパラメー
タを取得する機能である。

【００９３】本実施例では、関連づけられるべきデータ
アイテム１４１への登録は、部品１３１側で行うものと
した。逆に、データアイテム１４１が部品１３１を検索
して、登録するものとしてもよい。また、本実施例で
は、値の変更を、データアイテム１４１が部品に通知す
るものとしたが、部品がデータアイテム１４１の値を継
続的に監視して、その変化を検知するものとしてもよ
い。

【００９４】以上で説明した構成により、情報処理装置
１００は、フロー定義、画面定義、ＲＥＬＡＸなどの電
子文書に従った柔軟な処理、電文生成および解読を実現
することができる。また、これらの電子文書の改変によ
り、ＸＭＬアプリケーションプログラムの基本的な構成
の改変を行うまでなく、処理内容を比較的容易かつ柔軟
に改変することが可能となる。

【００９５】Ａ−１０．起動処理：以下では、ＸＭＬア
プリケーションプログラムを起動して、フロー定義等に
応じた処理を実行するまでの各段階での手順を説明す
る。

【００９６】図１０は起動処理のフローチャートであ
る。この処理は、情報処理装置１００においてブラウザ
が起動している状態で、オペレータがＸＭＬアプリケー
ションプログラムベースページのＵＲＬを入力すること
により、開始される。ＸＭＬアプリケーションプログラ
ムベースページとは、ベースアプレット１０４を提供す
るＷｅｂページであり、本実施例ではＸＭＬで記述され
る。このＵＲＬは、情報処理装置１００の内部であって
もよいし、外部のＷｅｂサーバ１０であってもよい。

【００９７】このＵＲＬが入力されると、情報処理装置
１００は、ブラウザによってＸＭＬアプリケーションプ
ログラムベースページを読み込み（ステップＳ１０）、
そこで提供されるベースアプレットを起動させる（ステ
ップＳ１１）。ベースアプレットは、図１で説明した通
り、ＸＭＬアプリケーションプログラムが稼働するため
のプラットフォームを提供するソフトウェアである。

【００９８】ベースアプレットの機能により、情報処理
装置１００は、アプリケーションブラウザ１３０を生成
する（ステップＳ１２）。ここで生成されるアプリケー
ションブラウザ１３０は、ＸＭＬアプリケーションプロ
グラムが起動するためのプラットフォームとしてのブラ
ウザに相当する。アプリケーションブラウザ１３０は、
ベースアプレットで予め指定された初期の画面定義を読
み込む（ステップＳ１３）。この初期の画面定義に基づ
いて生成される画面を「ベース画面」と称する。アプリ
ケーションブラウザ１３０は、このベース画面上で、実
行エンジン１２０を起動させる（ステップＳ１４）。こ
れにより、ＸＭＬアプリケーションプログラムが稼働可
能な状態が整ったことになる。

【００９９】実行エンジン１２０は、フロー定義を読み
込み（ステップＳ１５）、それに基づいてアプリケーシ
ョンブラウザ１３０を呼び出し、初期画面をオペレータ
に提示する（ステップＳ１６）。実行エンジン１２０が
読み込むべきフロー定義のＵＲＬは、予め設定されてい
る。このＵＲＬを、ベースアプレットまたは初期の画面
定義で与えるものとしてもよい。

【０１００】図１１は起動後の画面構造を模式的に示す
説明図である。ＸＭＬアプリケーションプログラムは、
ＸＭＬアプリケーションプログラムベースページを読み
込んだＷｅｂブラウザ１０２上で稼働する。ＸＭＬアプ
リケーションプログラムベースページ上では、ベースア
プレット１０４が稼働している。

【０１０１】ベースアプレット１０４は、ＸＭＬアプリ
ケーションプログラム用のプラットフォームとしてのア
プリケーションブラウザ１３０Ａを生成し、ＸＭＬアプ
リケーションプログラムベース画面を提供する。ＸＭＬ
アプリケーションプログラムベース画面上では、実行エ
ンジン１２０が起動される。通信その他の機能を提供す
るためのプラグインを必要に応じて起動するものとして
もよい。実行エンジン１２０は、アプリケーションブラ
ウザ１３０Ｂを起動する。アプリケーションブラウザ１
３０Ｂは、先に説明した通り、種々の部品１３１を起動
して、画面を生成する。部品１３１には、ＧＵＩ部品１
３１ａ、ロジック部品１３１ｂの双方が含まれる。アプ
リケーションブラウザ１３０Ｂの起動は、フロー定義に
よって、画面表示、画面遷移が指示される度に、適宜呼
び出されることになる。

【０１０２】以上の処理によって、ＸＭＬアプリケーシ
ョンプログラムの起動が完了すると、実行エンジン１２
０は、以下に示す通り、フロー定義に基づいて実質的な
処理を開始する。

【０１０３】Ａ−１１．フロー定義のコマンド処理：図
１２は実行エンジンが実行する処理のフローチャートで
ある。実行エンジン１２０は、フロー定義を読み込み
（ステップＳ２０）、そこに含まれるタグの内容を解釈
して（ステップＳ２１）、それに応じた処理を実行する
（ステップＳ２２）。

【０１０４】画面表示に関する処理の場合には、実行エ
ンジン１２０は、コンテキスト制御を実行する（ステッ
プＳ２３）。つまり、アプリケーションブラウザ１３０
を起動して、画面の生成、画面上での操作を実現する。
アプリケーションブラウザ１３０を起動している期間、
情報処理装置１００の制御は、アプリケーションブラウ
ザ１３０側に移行する。ステップＳ２３では、実行エン
ジン１２０は、アプリケーションブラウザ１３０が一連
の処理を完了するのを待っている。フロー定義で規定さ
れた処理が電文処理である場合には、実行エンジン１２
０は、トランザクション制御を実行する（ステップＳ２
４）。つまり、ＲＥＬＡＸを参照しながら、電文の生成
または解読処理を実行する。図示を省略しているが、そ
の他、実行エンジン１２０は、タグの内容に応じて、種
々の処理を実行可能である。

【０１０５】実行エンジン１２０は、以上の処理を、フ
ロー定義に規定された内容が完了するまで（ステップＳ
２５）、繰り返し実行する。

【０１０６】Ａ−１２．画面操作処理：図１３は画面操
作処理のフローチャートである。実行エンジン１２０か
らの呼び出しに応じて、アプリケーションブラウザ１３
０が起動し（ステップＳ３０）、以下に示す処理によっ
て、画面表示などの画面操作を実現する。

【０１０７】アプリケーションブラウザ１３０は、ま
ず、呼び出し時に指定された画面定義を読み込み（ステ
ップＳ３１）、画面定義の内容に従って、画面表示を行
う（ステップＳ３２）。画面表示は、既に説明した通
り、画面定義の規定内容に基づいて各部品を呼び出すこ
とによって実現される。

【０１０８】この状態で、アプリケーションブラウザ１
３０は、キーイベントの入力を待つ（ステップＳ３
３）。キーイベントは、情報処理装置１００のキーボー
ド、マウスなどの操作結果である。ベースアプレット１
０４が、これらの操作を検知して、その操作内容を表す
メッセージを、メッセージバス１４０に展開する。アプ
リケーションブラウザ１３０は、メッセージバス１４０
を監視しているため、この展開結果に基づいてキーイベ
ントを検知することができる。

【０１０９】キーイベントが完了指示である場合、即
ち、画面の遷移、ＡＰサーバ２０との通信、消去、ＸＭ
Ｌアプリケーションプログラムの終了などを示している
場合、アプリケーションブラウザ１３０はその動作を終
了し、実行エンジン１２０に制御を戻す（ステップＳ３
６）。この際、完了指示が、消去、ＸＭＬアプリケーシ
ョンプログラムの終了など表示画面の消去を要する指示
である場合には、アプリケーションブラウザ１３０は、
それまでに表示していた画面を破棄した上で、実行エン
ジン１２０に制御を戻す。完了指示が、画面の遷移、通
信など、表示画面の消去を要しない指示である場合に
は、画面の破棄を伴わずに、制御を戻す。

【０１１０】キーイベントが完了指示でない場合には、
アプリケーションブラウザ１３０は、それぞれのキーイ
ベントに応じてＧＵＩ部品、ロジック部品を動作させる
（ステップＳ３５）。かかる指示には、例えば、画面上
でのデータ入力、ボタン操作、範囲指定などの操作など
が含まれる。各部品の動作は、図５で説明した通り、各
部品に関連づけられたデータアイテムの値を変更するこ
とにより、容易に実現される。

【０１１１】アプリケーションブラウザ１３０は、以上
の処理によって、画面定義に基づく画面の表示、画面上
での操作を実現する。アプリケーションブラウザ１３０
は、実行エンジン１２０から重複して呼び出される可能
性がある。本実施例では、複数のアプリケーションブラ
ウザ１３０を生成し、それぞれが個別に上述の処理を実
行する形で、かかる並列的な処理を実現するものとし
た。

【０１１２】以上で説明した第１実施例の情報処理装置
１００によれば、次に示す種々の利点が得られる。

【０１１３】第１に、実行エンジン１２０、アプリケー
ションブラウザ１３０が実行すべき実質的な処理内容
を、フロー定義１４、画面定義１２、ＲＥＬＡＸなどの
電子文書で外部から規定することができる。従って、こ
れらのソフトウェアの改変を行うまでなく、処理内容の
変更、拡張を容易に実現することができる。

【０１１４】第２に、アプリケーションブラウザ１３０
が使用する各部品１３１は、それぞれ個別のモジュール
として構成されている。従って、新たな部品の追加、部
品の置換を比較的容易に実現することができる。

【０１１５】第３に、各部品は、直接相互に関連してい
る訳ではなく、データアイテムを介して、連携を保って
いる。このように中間にオブジェクトを介在させて、部
品相互の関連付けを行うことにより、各部品の置換、追
加を比較的容易に実現することが可能となる。

【０１１６】第４に、ＸＭＬアプリケーションプログラ
ムは、Ｗｅｂブラウザ上で稼働するため、プラットフォ
ーム非依存で、汎用性が高いという利点がある。

【０１１７】Ｂ．第２実施例（イメージ処理システ
ム）：第１実施例では、情報処理システムとして汎用的
な構成を例示した。第２実施例では、ＸＭＬアプリケー
ションプログラムの具体的な適用例として、イメージ処
理システムについて説明する。

【０１１８】Ｂ−１．システム構成：図１４はイメージ
処理システムの構成を示す説明図である。イメージ処理
システムとは、金融機関で利用される振込用紙などの帳
票を利用した取引を実行するシステムである。帳票に含
まれる情報から得られる文字データまたは数値データ
（以下、これらを「帳票データ」と総称する）と、帳票
をスキャンして得られたイメージデータとを利用して取
引を実行する。

【０１１９】実施例のイメージ処理システムは、イメー
ジワークフローシステム２００と基幹業務システム３０
０の２つを、ネットワークで接続して構築されている。
イメージワークフローシステム２００は、帳票のイメー
ジデータ、帳票データの登録、補正、紹介を実行する。
基幹業務システム３００は、取引処理を実行する。基幹
業務システム３００が実行する取引処理には、帳票を利
用しない取引も含まれるが、ここでは説明の便宜上、帳
票のデータを利用した取引に絞って説明する。

【０１２０】基幹業務システム３００は、業務サーバ３
２０とホストコンピュータ３３０を有している。両者を
一体的に構成しても構わない。業務サーバ３２０は、取
引に関する業務データを業務データベース３１０に管理
する機能、クライアント２５０、３５０などの要求に応
じて業務データを供給する機能を奏する。業務データに
は、例えば、利用者の口座情報、取引履歴などの情報が
含まれる。ホストコンピュータ３３０は、業務データに
基づいて、各種取引処理を実現する。

【０１２１】イメージワークフローシステム２００は、
イメージサーバ２２０を有している。イメージサーバ２
２０は、帳票のイメージデータおよび帳票データをそれ
ぞれイメージアーカイブ２１０として保管し、クライア
ント２５０、３５０などの要求に応じて提示する機能を
奏する。

【０１２２】イメージデータおよび帳票データは、イメ
ージワークフローシステム２００側のクライアント２５
０（以下、イメージクライアントと称する）によって入
力される。イメージクライアント２５０には、スキャナ
２０４によって、帳票２０２をスキャンして、イメージ
データを取得する。イメージクライアント２５０は、取
得したイメージデータをＯＣＲ処理して、帳票データを
取得して、イメージサーバ２２０に登録する。

【０１２３】登録された帳票データについては、別のオ
ペレータによる確認、補正が行われる。これらの処理
は、イメージサーバ２２０に接続されたいずれかのイメ
ージクライアント２５０によって行われる。オペレータ
は、イメージクライアント２５０で、確認対象となるイ
メージデータおよび帳票データを並列的に表示させて、
両者を比較することで、帳票データの誤りを確認する。
誤りがある場合には、適宜、補正してイメージアーカイ
ブ２１０の内容を更新する。

【０１２４】Ｂ−２．ソフトウェア構成：図１５はイメ
ージワークフローシステム２００のソフトウェア構成を
示す説明図である。本実施例では、イメージサーバ２２
０、イメージクライアント２５０の双方共に、ＸＭＬア
プリケーションプログラムでそれぞれの処理を実現す
る。従って、以下に示す通り、それぞれにＸＭＬアプリ
ケーションプログラムを稼働させるための機能ブロック
が構築されている。

【０１２５】ＸＭＬアプリケーションプログラムは、イ
メージサーバ２２０およびイメージクライアント２５０
のいずれか一方にのみ適用しても構わない。また、基幹
業務システム３００側にＸＭＬアプリケーションプログ
ラムを適用することも可能である。

【０１２６】イメージサーバ２２０には、アプリケーシ
ョンコア２２５、アプリケーション部品２２４が備えら
れている。アプリケーションコア２２５は、実行エンジ
ン、アプリケーションブラウザ、メッセージバスの総称
である。第１実施例で説明した通り、アプリケーション
コア２２５は、Ｗｅｂブラウザ上で、ベースアプレット
によって提供される。

【０１２７】イメージサーバ２２０には、アプリケーシ
ョンコア２２５が処理に要するアプリケーション部品２
２４および業務フロー定義２２３も予め用意されてい
る。イメージサーバ２２０では、画面の表示は行わない
ため、画面定義は省略しても差し支えない。

【０１２８】業務フロー定義２２３は、イメージクライ
アント２５０から受け取ったイメージデータおよび帳票
データをイメージアーカイブ２１０に管理するための処
理、イメージクライアント２５０その他のクライアント
からの要求に応じて、これらのイメージデータ等を提供
するための処理を規定する。

【０１２９】イメージサーバ２２０は、Ｗｅｂ紹介部２
２１および基幹業務連携部２２２を有している。Ｗｅｂ
紹介部２２１は、ＸＭＬアプリケーションプログラムに
非対応のクライアントからの要求に応じて、イメージア
ーカイブをＨＴＭＬファイルの形式で提供する。基幹業
務連携部２２２は、基幹業務システム３００との連携が
必要となる処理を実現する。例えば、イメージデータと
帳票データの整合だけでは、口座番号が真正なものであ
るか否かを確認することはできないため、基幹業務連携
部２２２は、基幹業務システム３００に口座番号の真否
を確認する。

【０１３０】イメージクライアント２５０は、同じく、
アプリケーションコア２５３、アプリケーション部品２
５２、業務定義２５１を備えている。イメージクライア
ント２５０では、画面での操作も伴うため、業務定義２
５１には、フロー定義、画面定義の双方が含まれる。

【０１３１】イメージクライアント２５０は、更に、帳
票認識部２５４を備えている。本実施例では、帳票認識
部２５４は、ＸＭＬアプリケーションプログラムに依ら
ずに起動するソフトウェアとして用意するものとした
が、ＸＭＬアプリケーションプログラムを利用してもよ
い。帳票認識部２５４は、帳票のイメージデータのＯＣ
Ｒ処理によって帳票データを取得する。ＯＣＲ処理を施
す対象となる領域は、帳票ごとに帳票定義２５５によっ
て規定されている。

【０１３２】イメージクライアント２５０では、帳票デ
ータの取得以外の部分をＸＭＬアプリケーションプログ
ラムで実現する。フロー定義は、例えば、帳票のイメー
ジデータ取得、帳票認識部２５４によって得られた帳票
データとの関連づけ、イメージアーカイブ２１０に格納
するためのフォーマット変換などの処理を規定する。画
面定義は、これらの処理に必要となる操作画面を規定す
る。

【０１３３】フロー定義は、帳票データの補正に関する
処理も規定する。つまり、イメージアーカイブ２１０か
らイメージデータ、帳票データをオペレータに提示する
処理、帳票データの補正を受け付ける処理などを規定す
る。画面定義は、補正処理に使用される画面、例えば、
イメージデータと帳票データを比較可能な状態で表示す
る画面、その補正を受け付ける画面などを規定する。

【０１３４】イメージクライアント２５０とイメージサ
ーバ２２０との通信は、本実施例では、ＨＴＴＰプロト
コルによって行うものとした。両者のデータ授受は、第
１実施例で説明した電文によって行われる。両者に備え
られたアプリケーションコア２５３、２２５は、それぞ
れが有するＲＥＬＡＸによって、電文の生成、解読を実
行する。

【０１３５】Ｂ−３．イメージ処理：図１６はイメージ
処理全体のフローチャートである。イメージクライアン
ト２５０とイメージサーバ２２０とが連携して実行する
ワークフロー全体を示した。イメージクライアント２５
０で実行する処理は、二重枠で示した。

【０１３６】まず、イメージクライアント２５０が、帳
票イメージの読み込みを行い（ステップＳ５００）、帳
票認識を行って帳票データを生成する（ステップＳ５０
１）。この帳票データと、イメージデータとを関連づけ
てデータ登録を行う（ステップＳ５０２）。この処理で
は、イメージクライアント２５０は、両者を所定のフォ
ーマットに格納して、イメージサーバ２２０に送信す
る。イメージサーバ２２０は、このデータをイメージア
ーカイブ２１０の所定領域に格納する。

【０１３７】データは、種々の形式で格納可能である
が、本実施例では、ＸＭＬで格納するものとした。つま
り、帳票データは、項目ごとに所定のタグとともにＸＭ
Ｌ形式で記録される。イメージデータは、データを保存
しておくパス名が、ＸＭＬ形式で記録される。こうする
ことにより、帳票データとイメージデータとを容易に関
連づけつつ、一元的に管理することが可能となる。本実
施例では、この時点では、補正処理、検証処理が未済と
いうステータスを付してデータを登録するものとした。

【０１３８】イメージサーバ２２０は、データの登録に
続いて、業務連携処理を実行する（ステップＳ５０
３）。この処理には、例えば、先に示した通り、口座番
号の真否の確認などが含まれる。

【０１３９】こうしてイメージデータおよび帳票データ
の登録が完了すると、ワークフローは、これらの補正処
理に移行する（ステップＳ５０４）。補正は、イメージ
クライアント２５０で実行するが、その端末およびオペ
レータは、データ登録時と異なっていても良い。オペレ
ータが、イメージクライアント２５０に「補正処理」を
指示すると、イメージクライアント２５０は、イメージ
アーカイブ２１０に登録されているデータのうち、補正
処理、検証処理が共に未済となっているデータを提示す
る。オペレータは、イメージデータと帳票データとを対
比しながら、適宜、帳票データの修正を実行する。こう
して修正されたデータが、再び、イメージサーバ２２０
に送信されると、イメージサーバ２２０は、イメージア
ーカイブ２１０の内容を更新する。これとともに、登録
時と同様、業務連携処理を実行する（ステップＳ５０
５）。この時点では、データのステータスは、検証処理
が未済に変更される。

【０１４０】次に、ワークフローは、イメージデータお
よび帳票データの検証処理に移行する（ステップＳ５０
６）。処理の手順は、データ補正処理（ステップＳ５０
４）と同様である。検証処理は、帳票データの誤りの有
無を更に確認するための処理であり、省略することも可
能である。

【０１４１】イメージクライアント２５０が、検証処理
が完了したデータをイメージサーバ２２０に送信する
と、イメージサーバは、検証処理済みのステータスを付
して、イメージアーカイブ２１０の内容を更新すること
によって、このデータ紹介に許可を与える（ステップＳ
５０７）。以上の処理を経て、イメージデータおよび帳
票データは、以後、イメージクライアント２５０、基幹
業務システム３００からの紹介が可能となる。

【０１４２】イメージクライアント２５０は、主として
ＸＭＬアプリケーションプログラムによって、上記処理
を実現する。実質的な処理内容は、イメージクライアン
ト２５０の業務定義２５１によって与えられることにな
る。帳票データの生成（ステップＳ５０１）について
は、ＸＭＬアプリケーションプログラムに非依存の帳票
認識部２５４を起動する部分、および認識結果を取得す
る部分でＸＭＬアプリケーションプログラムが関連す
る。

【０１４３】イメージサーバ２２０も同様に、主として
ＸＭＬアプリケーションプログラムによって、上記処理
を実現する。図１６では、図示を省略したが、実質的な
処理内容は、イメージサーバ２２０側の業務フロー定義
２２３によって規定される。

【０１４４】以上で説明した第２実施例のイメージ処理
システムによれば、帳票データおよびイメージデータを
用いた処理に、ＸＭＬアプリケーションプログラムを適
用することができる。金融機関で利用される帳票は、金
融機関および取引内容によって、多種多様であり、イメ
ージ処理も多種多様な処理が要求される。ＸＭＬアプリ
ケーションプログラムは、第１実施例で説明した通り、
実質的な処理内容を業務定義２５１、業務フロー定義２
２３で規定することができる。従って、このように多種
多様な処理が要求される場合でも、比較的容易に処理内
容のカスタマイズ、および改変を実現することができ
る。

【０１４５】第２実施例では、金融機関のイメージ処理
を例にとって説明したが、これに限らず、例えば、保険
会社における保険金の支払い業務など、帳票を利用した
種々の業務に適用することが可能である。

【０１４６】Ｃ．変形例：以上の実施例では、いずれも
情報処理装置１００、イメージクライアント２５０、イ
メージサーバ２２０などがそれぞれネットワークで接続
されている構成を例示した。ＸＭＬアプリケーションプ
ログラムは、必ずしもネットワークで接続されたコンピ
ュータ上で起動させる必要はなく、スタンドアロンで起
動させることもできる。スタンドアロンで起動させる場
合には、処理に要するフロー定義、画面定義を予め装置
内に記憶させておくものとしてもよいし、ＣＤ−ＲＯＭ
などの記録媒体を利用して提供するものとしてもよい。

【０１４７】以上の実施例では、ＸＭＬアプリケーショ
ンプログラムがソフトウェア的に構築されている場合を
例示した。例えば、実行エンジン１２０、アプリケーシ
ョンブラウザ１３０、メッセージバス１４０などの機能
を実現する回路を用意することによって、ハードウェア
的にＸＭＬアプリケーションプログラムを実現すること
も可能である。かかる場合でも、回路の大幅な変更、置
換を伴わず、処理内容の改変を行うことができる利点が
ある。

【０１４８】第１実施例で説明したＸＭＬアプリケーシ
ョンプログラムの機能ブロックは、必ずしも全てを備え
ている必要はない。例えば、実行エンジン１２０の基本
的な機能、即ち、フロー定義１４によって処理を進める
機能のみを備え、電文１６の処理、画面表示に関する処
理は、ＸＭＬアプリケーションプログラムに非依存の方
法を採用してもよい。同様に、電文１６の処理、画面表
示に関する処理のみをＸＭＬアプリケーションプログラ
ム依存としてもよい。

【０１４９】以上、本発明の種々の実施例について説明
したが、本発明はこれらの実施例に限定されず、その趣
旨を逸脱しない範囲で種々の構成を採ることができるこ
とはいうまでもない。例えば、以上の制御処理はソフト
ウェアで実現する他、ハードウェア的に実現するものと
してもよい。

【０１５０】

【発明の効果】本発明によれば、外部から与える電子文
書の内容を変更するだけで、情報処理装置自体のソフト
ウェアまたはハードウェア構成を大幅に改変するまでな
く、情報処理機能の追加、改変、カスタマイズなどを行
うことができる。

【図面の簡単な説明】

【図１】実施例としての情報処理装置のシステム構成を
示す説明図である。

【図２】フロー定義１４の概要を示す説明図である。

【図３】カーソル制御コマンドの概要を示す説明図であ
る。

【図４】画面定義の概要を示す説明図である。

【図５】部品間の連携を示す説明図である。

【図６】電文の生成、解読方法を示す説明図である。

【図７】実行エンジン１２０のモジュール構成を示す説
明図である。

【図８】アプリケーションブラウザ１３０のモジュール
構成を示す説明図である。

【図９】メッセージバスのモジュール構成を示す説明図
である。

【図１０】起動処理のフローチャートである。

【図１１】起動後の画面構造を模式的に示す説明図であ
る。

【図１２】実行エンジンが実行する処理のフローチャー
トである。

【図１３】画面操作処理のフローチャートである。

【図１４】イメージ処理システムの構成を示す説明図で
ある。

【図１５】イメージワークフローシステム２００のソフ
トウェア構成を示す説明図である。

【図１６】イメージ処理全体のフローチャートである。

【符号の説明】

１０…Ｗｅｂサーバ １２…画面定義 １４…フロー定義 １６…電文 １００…情報処理装置 １０２…Ｗｅｂブラウザ １０４…ベースアプレット １１０…カスタマイズモジュール １１５…アペンダ １１６…ＲＥＬＡＸ選択 １１７…通信プラグイン １２０…実行エンジン １２１…メイン制御 １２２…フロー制御 １２３…コンテキスト制御 １２４…キュー制御 １２５…トランザクション制御 １２６…通信スレッド １３０、１３０Ａ、１３０Ｂ…アプリケーションブラウ
ザ １３１…部品 １３１ａ…ＧＵＩ部品 １３１ｂ…ロジック部品 １３３…メイン制御 １３４…画面生成部 １３５…画面表示部 １３６…画面非表示部 １３７…画面破棄部 １３８…パス設定部 １３９…オブジェクトテーブル １４０…メッセージバス １４１…データアイテム １４２…データアイテム取得部 １４３…データ収集部 １４４…データクリア部 １４５…データアイテムテーブル １４６…バス取得部 １４７…バスクリア部 １４８…バス ２００…イメージワークフローシステム ２０２…帳票 ２０４…スキャナ ２１０…イメージアーカイブ ２２０…イメージサーバ ２２１…Ｗｅｂ紹介部 ２２２…基幹業務連携部 ２２３…業務フロー定義 ２２４…アプリケーション部品 ２２５…アプリケーションコア ２５０…イメージクライアント ２５１…業務定義 ２５２…アプリケーション部品 ２５３…アプリケーションコア ２５４…帳票認識部 ２５５…帳票定義 ３００…基幹業務システム ３１０…業務データベース ３２０…業務サーバ ３３０…ホストコンピュータ

Claims (33)

【特許請求の範囲】
1. 【請求項１】 情報処理装置であって、 個別の要素として構成され、予め設定された所定の基本
   機能を実現する複数種類の基本機能部と、 処理に使用すべき基本機能部を特定する形式で、処理内
   容を規定する電子文書を入力する文書入力部と、 該電子文書を解析し、該電子文書に基づいて、逐次、前
   記基本機能部を稼働させる稼働制御部とを備える情報処
   理装置。
2. 【請求項２】 請求項１記載の情報処理装置であって、 前記基本機能部には、前記情報処理装置に表示されるべ
   き表示画面を生成する画面生成部が含まれ、 前記電子文書は、前記表示画面の内容およびその生成タ
   イミングを規定し、 前記稼働制御部は、該生成タイミングに応じて前記画面
   生成部を稼働させる情報処理装置。
3. 【請求項３】 請求項１記載の情報処理装置であって、 前記電子文書は、複数の処理内容を規定するとともに、
   その実施順序を制御するフロー制御情報を含んでおり、 前記稼働制御部は、該フロー制御情報に応じた順序で、
   前記電子文書に規定された基本機能部を稼働させる情報
   処理装置。
4. 【請求項４】 請求項１記載の情報処理装置であって、 前記基本機能部には、前記情報処理装置の表示画面を構
   成する表示要素を表示するための複数種類の要素表示部
   が含まれ、 前記電子文書は、前記表示画面を構成する各表示要素の
   種類および位置を規定し、 前記稼働制御部は、前記電子文書に基づいて前記要素表
   示部を稼働させることで前記表示画面を生成する情報処
   理装置。
5. 【請求項５】 請求項１記載の情報処理装置であって、 前記複数の基本機能部には、前記情報処理装置に入力さ
   れたデータについて、所定の演算を実行する複数種類の
   要素演算部が含まれ、 前記電子文書は、前記データに施すべき演算の種類を規
   定し、 前記稼働制御部は、前記電子文書に基づいて前記要素演
   算部を稼働させることで前記データの演算を実行する情
   報処理装置。
6. 【請求項６】 情報処理装置であって、 個別の要素として構成され、予め設定された所定の基本
   機能を実現する複数種類の基本機能部と、 前記基本機能部の少なくとも一部に対応づけられた所定
   のオブジェクトを、該対応関係とともに管理するオブジ
   ェクト管理部とを備え、 前記基本機能部は、前記対応づけられたオブジェクトの
   状態変化に基づいて起動する機能を有しており、 該オブジェクト管理部は、少なくとも一部のオブジェク
   トに状態変化が生じた場合に、該オブジェクトに関連づ
   けられた前記基本機能部に対して、該状態変化を通知す
   る情報処理装置。
7. 【請求項７】 請求項６記載の情報処理装置であって、 前記基本機能部には、前記情報処理装置の表示画面を構
   成する表示要素を表示するための複数種類の要素表示部
   が含まれ、 前記オブジェクト管理部は、 複数の表示画面に共通するオブジェクトを管理する共有
   オブジェクト管理部と、 現に表示されている表示画面に関するオブジェクトを管
   理する個別オブジェクト管理部とを備える情報処理装
   置。
8. 【請求項８】 請求項６記載の情報処理装置であって、 前記基本機能部は、前記基本機能部とオブジェクトとの
   対応関係を前記オブジェクト管理部に対し登録可能であ
   る情報処理装置。
9. 【請求項９】 請求項６記載の情報処理装置であって、 前記オブジェクト管理部は、 前記基本機能部の稼働に呼応して、該基本機能部に対応
   したオブジェクトを生成するオブジェクト生成部と、 稼働しているいずれの基本機能部とも対応づけられてい
   ないオブジェクトを消去するオブジェクト消去部とを備
   える情報処理装置。
10. 【請求項１０】 ネットワークに接続され、該ネットワ
    ークを介した情報の授受に基づいて所定の処理を行う情
    報処理装置であって、 前記ネットワークを介して送受信される電文に含むべき
    データ、および該データのフォーマットを規定する規定
    文書を記憶する文書記憶部と、 前記規定文書を解析し、該規定文書の規定内容に基づい
    て前記電文の生成または解読を行う電文処理部とを備え
    る情報処理装置。
11. 【請求項１１】 請求項１０記載の情報処理装置であっ
    て、 前記所定の処理に関連した複数のデータを統合的に管理
    するデータ管理部を備え、 前記電文処理部は、該情報処理装置から送信される前記
    電文に含むべきデータを、前記データ管理部から取得す
    る情報処理装置。
12. 【請求項１２】 請求項１０記載の情報処理装置であっ
    て、 前記所定の処理に関連した複数のデータを統合的に管理
    するデータ管理部を備え、 前記電文処理部は、前記ネットワークを介して受信した
    前記電文から抽出したデータを、前記データ管理部に通
    知する情報処理装置。
13. 【請求項１３】 請求項１０記載の情報処理装置であっ
    て、 前記文書記憶部は、複数種類の前記規定文書を記憶して
    おり、 前記ネットワークを介した情報の授受を伴う複数の処理
    について、各処理で使用すべき前記規定文書を特定した
    電子文書を入力する文書入力部と、 前記電文処理部は、前記電子文書で特定される規定文書
    を、現に実行中の処理に応じて、使い分ける情報処理装
    置。
14. 【請求項１４】 コンピュータによって所定の情報処理
    を行うためのコンピュータプログラムであって、 個別のモジュールとして構成され、予め設定された所定
    の基本機能を実現する複数種類の基本機能モジュール
    と、 処理に使用すべき基本機能モジュールを特定する形式
    で、処理内容を規定する電子文書を入力する文書入力機
    能と、 該電子文書を解析し、該電子文書に基づいて、逐次、前
    記基本機能モジュールを稼働させる稼働制御機能とをコ
    ンピュータによって実現するためのコンピュータプログ
    ラム。
15. 【請求項１５】 請求項１４記載のコンピュータプログ
    ラムであって、 前記基本機能モジュールには、前記コンピュータに表示
    されるべき表示画面を生成する画面生成モジュールが含
    まれ、 前記電子文書は、前記表示画面の内容およびその生成タ
    イミングを規定し、 前記稼働制御モジュールは、該生成タイミングに応じて
    前記画面生成モジュールを稼働させるコンピュータプロ
    グラム。
16. 【請求項１６】 請求項１４記載のコンピュータプログ
    ラムであって、 前記電子文書は、複数の処理内容を規定するとともに、
    その実施順序を制御するフロー制御情報を含んでおり、 前記稼働制御モジュールは、該フロー制御情報に応じた
    順序で、前記電子文書に規定された基本機能モジュール
    を稼働させるコンピュータプログラム。
17. 【請求項１７】 請求項１４記載のコンピュータプログ
    ラムであって、 前記基本機能モジュールには、前記コンピュータプログ
    ラムの表示画面を構成する表示要素を表示するための複
    数種類の要素表示モジュールが含まれ、 前記電子文書は、前記表示画面を構成する各表示要素の
    種類および位置を規定し、 前記稼働制御モジュールは、前記電子文書に基づいて前
    記要素表示モジュールを稼働させることで前記表示画面
    を生成するコンピュータプログラム。
18. 【請求項１８】 請求項１４記載のコンピュータプログ
    ラムであって、 前記複数の基本機能モジュールには、前記コンピュータ
    プログラムに入力されたデータについて、所定の演算を
    実行する複数種類の要素演算モジュールが含まれ、 前記電子文書は、前記データに施すべき演算の種類を規
    定し、 前記稼働制御モジュールは、前記電子文書に基づいて前
    記要素演算モジュールを稼働させることで前記データの
    演算を実行するコンピュータプログラム。
19. 【請求項１９】 コンピュータによって所定の情報処理
    を行うためのコンピュータプログラムであって、 個別のモジュールとして構成され、予め設定された所定
    の基本機能を実現する複数種類の基本機能モジュール
    と、 前記基本機能モジュールの少なくとも一部に対応づけら
    れた所定のオブジェクトを、該対応関係とともに管理す
    るオブジェクト管理モジュールとを備え、 前記基本機能モジュールは、前記対応づけられたオブジ
    ェクトの状態変化に基づいて起動可能であり、 該オブジェクト管理モジュールは、少なくとも一部のオ
    ブジェクトに状態変化が生じた場合に、該オブジェクト
    に関連づけられた前記基本機能モジュールに対して、該
    状態変化を通知する機能を有するコンピュータプログラ
    ム。
20. 【請求項２０】 請求項１９記載のコンピュータプログ
    ラムであって、 前記基本機能モジュールには、前記コンピュータの表示
    画面を構成する表示要素を表示するための複数種類の要
    素表示モジュールが含まれ、 前記オブジェクト管理モジュールは、 複数の表示画面に共通するオブジェクトを管理する共有
    オブジェクト管理モジュールと、 現に表示されている表示画面に関するオブジェクトを管
    理する個別オブジェクト管理モジュールとを備えるコン
    ピュータプログラム。
21. 【請求項２１】 請求項１９記載のコンピュータプログ
    ラムであって、 前記基本機能モジュールは、前記基本機能モジュールと
    オブジェクトとの対応関係を前記オブジェクト管理モジ
    ュールに対し登録する機能を備えるコンピュータプログ
    ラム。
22. 【請求項２２】 請求項１９記載のコンピュータプログ
    ラムであって、 前記オブジェクト管理モジュールは、 前記基本機能モジュールの稼働に呼応して、該基本機能
    モジュールに対応したオブジェクトを生成する機能と、 稼働しているいずれの基本機能モジュールとも対応づけ
    られていないオブジェクトを消去する機能とを有するコ
    ンピュータプログラム。
23. 【請求項２３】 ネットワークに接続されたコンピュー
    タにおいて、該ネットワークを介した情報の授受に基づ
    いて所定の処理を実現するためのコンピュータプログラ
    ムであって、 前記ネットワークを介して送受信される電文に含むべき
    データ、および該データのフォーマットを規定する規定
    文書を管理する文書管理機能と、 前記規定文書を解析し、該規定文書の規定内容に基づい
    て前記電文の生成または解読を行う電文処理機能とを、
    コンピュータによって実現するためのコンピュータプロ
    グラム。
24. 【請求項２４】 請求項２３記載のコンピュータプログ
    ラムであって、 前記所定の処理に関連した複数のデータを統合的に管理
    するデータ管理モジュールを備え、 前記電文処理機能は、送信される前記電文に含むべきデ
    ータを、前記データ管理モジュールから取得する機能を
    含むコンピュータプログラム。
25. 【請求項２５】 請求項２３記載のコンピュータプログ
    ラムであって、 前記所定の処理に関連した複数のデータを統合的に管理
    するデータ管理モジュールを備え、 前記電文処理機能は、前記ネットワークを介して受信し
    た前記電文から抽出したデータを、前記データ管理モジ
    ュールに通知する機能を含むコンピュータプログラム。
26. 【請求項２６】 請求項２３記載のコンピュータプログ
    ラムであって、 前記文書管理機能は、複数種類の前記規定文書を管理可
    能であり、 前記ネットワークを介した情報の授受を伴う複数の処理
    について、各処理で使用すべき前記規定文書を特定した
    電子文書を入力する機能と、 前記電文処理機能は、前記電子文書で特定される規定文
    書を、現に実行中の処理に応じて使い分ける機能を有す
    るコンピュータプログラム。
27. 【請求項２７】 請求項１４〜２６いずれか記載のコン
    ピュータプログラムであって、 前記コンピュータにインストールされたブラウザ上で稼
    働可能に構成されたコンピュータプログラム。
28. 【請求項２８】 コンピュータによって所定の情報処理
    を実現する情報処理方法であって、 個別のモジュールとして構成され、予め設定された所定
    の基本機能を実現する複数種類の基本機能モジュールを
    用意する工程と、 処理に使用すべき基本機能モジュールを特定する形式
    で、処理内容を規定する電子文書を入力する工程と、 コンピュータによって該電子文書を解析させ、該電子文
    書に基づいて、逐次、前記基本機能モジュールを稼働さ
    せる工程とを備える情報処理方法。
29. 【請求項２９】 コンピュータによって所定の情報処理
    を実現する情報処理方法であって、 個別のモジュールとして構成され、予め設定された所定
    の基本機能を実現する複数種類の基本機能モジュールを
    用意する工程と、 前記基本機能モジュールの少なくとも一部に対応づけら
    れた所定のオブジェクトを、該対応関係とともに管理す
    る工程と、 少なくとも一部のオブジェクトに状態変化が生じた場合
    に、該オブジェクトに関連づけられた前記基本機能モジ
    ュールに対して、該状態変化を通知することにより該基
    本機能モジュールを起動させる工程とを備える情報処理
    方法。
30. 【請求項３０】 ネットワークに接続されたコンピュー
    タにおいて、該ネットワークを介した情報の授受に基づ
    いて所定の情報処理を実現する情報処理方法であって、 前記ネットワークを介して送受信される電文に含むべき
    データ、および該データのフォーマットを規定する規定
    文書を管理する工程と、 前記規定文書を解析し、該規定文書の規定内容に基づい
    て前記電文の生成または解読を行う工程とを備える情報
    処理方法。
31. 【請求項３１】 帳票のイメージデータに基づき所定の
    イメージ処理を実行するイメージ処理装置であって、 前記イメージ処理に関し、予め設定された所定の基本機
    能を実現する複数種類の基本機能部と、 使用すべき基本機能部を特定する形式で、前記イメージ
    処理の処理内容を規定する電子文書を入力する文書入力
    部と、 該電子文書を解析し、該電子文書に基づいて、逐次、前
    記基本機能部を稼働させる稼働制御部とを備えるイメー
    ジ処理装置。
32. 【請求項３２】 請求項３１記載のイメージ処理装置で
    あって、 前記基本機能部には、前記イメージデータに基づいて文
    字データまたは数値データを取得するデータ取得部が含
    まれ、 前記電子文書は、前記イメージデータから前記取得を行
    うべき領域、および取得するデータの属性を規定してお
    り、 前記稼働制御部は、該電子文書に基づいて前記データ取
    得部を稼働することにより、該電子文書で規定されたデ
    ータの取得を実現するイメージ処理装置。
33. 【請求項３３】 請求項３１記載のイメージ処理装置で
    あって、 前記基本機能部には、 前記イメージデータを表示するイメージ表示部、 前記イメージデータに基づいて取得された文字データま
    たは数値データを表示するデータ表示部、 前記文字データまたは数値データを修正するデータ修正
    部が含まれ、 前記電子文書は、前記イメージデータと、文字データま
    たは数値データとの表示態様を規定する表示指示、およ
    び外部からの入力に基づき前記文字データまたは数値デ
    ータの修正方法を規定する修正指示を含み、 前記稼働制御部は、前記表示指示に基づいて前記イメー
    ジ表示部およびデータ表示部を稼働することによって前
    記表示態様を実現するとともに、前記修正指示に基づい
    て前記データ修正部を稼働することにより前記修正を実
    現するイメージ処理装置。