JP2002169714A - 情報制御システム及び情報制御方法 - Google Patents

Abstract

(57)【要約】 【課題】簡便且つ効率的にビジネスプロセスを実現す
る。 【解決手段】所定のデータ記述形式に基づいてデータ処
理するものであって、互いに異なる規則を有するサブシ
ステム２２，２３と、サブシステム２２，２３の一方で
処理されたデータ記述形式を他のサブシステム２２，２
３のデータ記述形式に適合させる変換処理を行うデータ
記述形式変換部２１２と、各サブシステム２２，２３に
処理命令をビジネスルールデータベース２１１ｂに格納
された処理手順に基づいて行うルーティングエンジン２
１１ａとを有する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数の情報処理手
段を用いてデータ処理を行う情報制御システム及び情報
制御方法に関する。

【０００２】

【従来の技術】従来、複数の業務の手順を有するビジネ
スプロセスをコンピュータに実行させる場合、次のよう
な論理規則を用いて実行されていた。まず、コンピュー
タに実行させるべき処理内容が記述されたシステム機能
をビジネスプロセス毎に複数設定する。そして、各シス
テム機能の処理手順を定め、その手順に従い各システム
機能を実行する。その際、あるシステム機能を実行した
後に他のシステム機能の実行に移行する場合には、ある
システム機能に対して処理手順が前後にあるシステム機
能との関連性のみが実行に際して設定されており、処理
手順が前後に位置づけられない他のシステム機能との間
での関連性はなかった。

【０００３】また、各システム機能で処理の対象とする
データの形式等はビジネスプロセスを通して一貫してい
ないのが通常である。従って、あるシステム機能を実行
した後に他のシステム機能の実行に移行する場合には、
既に終了したシステム機能のためのデータ記述形式から
次に実行されるべきシステム機能のためのデータ記述形
式に変換する必要があった。

【０００４】

【発明が解決しようとする課題】このデータ記述形式の
変換は、ビジネスプロセスの処理手順が一義的に定めら
れている場合にはその処理手順の前後のシステム機能と
の変換が可能であればよい。従って、データ記述形式の
変更のための変換機能は各システム機能に関連付けてお
けばよい。しかしながら、ビジネスプロセスの処理手順
が一義的に定まらなくなると、各処理手順毎に処理手順
の前後にあるシステム機能同士のデータ記述形式の変換
が必要になる。特に、全く新たなビジネスプロセスの処
理手順をシステムに新たに実行させる場合には、その処
理手順を導入する度にデータ記述形式の変換機能を処理
を担当する各システム機能のすべてに新たに持たせなけ
ればならない。

【０００５】このように、ビジネスプロセスの処理手順
が複雑化すると、データ記述形式の変換機能は各システ
ム機能毎に複数持たせることとなるが、その変換機能の
管理は煩雑となる。特に変換機能を各システム機能に関
連付けておく場合、同一のデータ記述形式の変換機能を
異なるシステム機能に重複して設定する必要が生じる。
もしあるシステム機能のデータ記述形式を変更する場合
には、そのシステム機能に係わるデータ変換機能を他の
関連するすべてのシステム機能に対して変更しなければ
ならない。

【０００６】また、ビジネスプロセスの処理を所定の手
順に従って実行する場合には、命令部が予め処理手順を
定め、その処理手順を実行させるための順序規則を各シ
ステム機能に関連付けておかなければならない。例えば
システム機能Ａ〜Ｄを順次実行する場合、まず命令部が
最初に実行すべきシステム機能Ａに対して処理命令を出
すと、今度はシステム機能Ａがシステム機能Ｂに対して
予め関連付けられた順序規則に基づき処理命令を行い、
同様にシステム機能Ｂが今度はシステム機能Ｃに対して
予め関連付けられた順序規則に基づき処理命令を行う。

【０００７】このように、処理手順を定める順序規則は
各システム機能Ａ〜Ｄに関連付けられていた。しかしな
がら、このような処理手順の決定方法では、途中で処理
不能なシステム機能が現れた場合等には処理が中断して
しまう。しかし、中断したシステム機能がどのシステム
機能かはビジネスプロセスの処理手順を定めた命令部に
とっては分からないことが多い。

【０００８】また、ビジネスプロセスを変更する場合に
は、各システム機能Ａ〜Ｄに対して順序規則の変更を行
う必要が生じ、システム管理者としては変更に対応する
ために煩雑かつ時間のかかる手続が必要とされていた。
新たなビジネスプロセスを実行させる場合には、各シス
テム機能Ａ〜Ｄに対して新たな順序規則を関連付ける必
要がある。

【０００９】このように、異なるデータ記述形式を持つ
複数のシステム機能によりビジネスプロセスを所定の処
理手順に従って実行する場合には、煩雑な処理が必要と
なり、効率的なシステム管理が困難であった。

【００１０】本発明は上記課題を解決するためになされ
たもので、その目的とするところは、簡便かつ効率的に
ビジネスプロセスを実現する情報制御システム及び情報
制御方法を提供することにある。

【００１１】

【課題を解決するための手段】この発明の一の観点によ
れば、所定の規則に基づいてデータ処理するものであっ
て、互いに異なる規則を有する複数の情報処理手段と、
前記情報処理手段のいずれか一つで処理されたデータの
規則を他の情報処理手段の規則に適合させる変換規則に
基づいて、各情報処理手段で処理されたデータの規則の
変換処理を行う規則変換手段とを具備してなることを特
徴とする情報制御システムが提供される。

【００１２】このような構成によれば、各情報処理手段
それぞれに固有の規則を変換する規則変換を規則変換手
段で行うことにより、各情報処理手段毎に他の規則に適
合させる処理を行うための規則変換手段を設ける必要が
無くなる。従って、重複した規則変換処理を一元的に行
うことができ、規則変換に関するシステム管理が容易に
なる。より具体的には、例えば情報処理手段が追加され
た場合には、その情報処理手段自体に他の情報処理手段
との規則変換機能を持たせることなく、規則変換手段が
追加された情報処理手段と他の情報処理手段との変換を
実行可能とすること（具体的には例えば規則変換手段の
利用する変換情報を追加する等）のみで、規則の変換が
可能となる。

【００１３】１の実施形態によれば、規則変換手段は、
各情報処理手段同士の前記変換規則を格納した変換規則
記憶手段を有し、前記変換規則記憶手段から前記変換規
則を読み出すことにより前記変換処理を行う。

【００１４】また、１の実施形態によれば、規則とは、
前記情報処理手段で処理されるデータ記述形式である。

【００１５】ここで、データ記述形式とは、データ項目
及び属性、データ項目の配列順序（レコード構造）、文
字コード体系等を含む概念であるが、これらに限定され
るものではない。

【００１６】これにより、各情報処理手段で処理される
データ記述形式がそれぞれ異なる場合であっても、情報
処理手段が処理すべき規則に沿ったデータ記述形式で情
報処理手段がデータ処理を行うことができるため、情報
処理手段自体は他の規則との変換規則を持つことなくデ
ータ処理を実行することができる。

【００１７】また、他の１の実施形態によれば、各情報
処理手段と規則変換手段はデータを送受信する送受信手
段を備え、送受信手段によるデータの送受信は前記規則
に基づいて処理される。これにより、通信規則が異なる
場合であっても規則変換手段にある情報処理手段固有の
通信規則により送信し、規則変換手段が通信規則を変換
して他の情報処理手段に適合させることができるため、
情報処理手段自体は他の通信規則との変換規則を持つこ
となくデータ処理を実行することができる。

【００１８】望ましくは、規則変換手段は、複数の情報
処理手段の規則のそれぞれと互換性を有する共通規則
と、各規則との間の変換処理を行う共通規則変換手段を
有する。このような構成によれば、共通規則変換手段
は、情報処理手段に固有の規則を一旦各規則に互換性を
有する共通規則に変換し、該共通規則からさらに別の情
報処理手段に固有の規則に変換することができる。共通
規則変換手段は各情報処理手段固有の規則と共通規則と
の互換性を持たせるのみで、各情報処理手段におけるデ
ータ処理を実行させることができる。その結果、例えば
情報処理手段が追加された場合には、追加された情報処
理手段固有の規則と他のすべての情報処理手段の規則と
の互換性を考えることなく、その情報処理手段に固有の
規則と共通規則との互換性を持たせることのみで、他の
すべての情報処理手段との間でのデータのやりとりを行
うことができる。また、情報処理手段の規則に変更があ
った場合には、その変更された規則と共通規則との互換
性を持たせることのみで、規則の変更に対応することが
できる。

【００１９】また、本発明の別の観点によれば、所定の
規則に基づいてデータ処理する複数の情報処理手段と、
前記規則のうちの一つと他の規則との変換情報に基づい
て前記複数のうちのある情報処理手段の前記規則を、前
記複数の情報処理手段の前記規則のそれぞれと互換性を
有する共通規則に変換し、かつ該共通規則を他の情報処
理手段の前記規則に変換する第１の変換規則に基づいて
変換処理を行う複数の第１の規則変換手段と、前記複数
の第１の規則変換手段それぞれの前記共通規則同士の間
の第２の変換規則に基づいて第２の変換処理を行う第２
の規則変換手段とを具備してなることを特徴とする情報
制御システムが提供される。

【００２０】このような構成によれば、情報処理手段同
士の規則の互換性、第１の規則変換手段同士の共通規則
の互換性を持たせることにより、階層的なシステムの管
理を行うことができる。

【００２１】また、本発明の別の観点によれば、データ
処理を行う複数の情報処理手段と、前記複数の情報処理
手段におけるデータ処理の処理手順を決定する処理手順
決定手段と、前記処理手順決定手段により決定された処
理手順に基づいて各情報処理手段に処理命令を行う処理
命令手段とを具備してなることを特徴とする情報制御シ
ステムが提供される。

【００２２】このような構成によれば、各情報処理手段
はその情報処理手段が行うべきデータ処理を実行するの
みで、他の情報処理手段との処理手順を考慮することな
く複数の処理手順からなる処理を行うことができる。

【００２３】望ましくは、処理命令手段は、処理命令を
行ったある前記情報処理手段の処理が終了した後、他の
前記情報処理手段に対して処理命令を行う。これによ
り、各情報処理手段による処理の終了を確認して処理手
順を踏むことができ、その結果処理プロセスの管理を処
理命令手段で行うことができる。

【００２４】望ましくは、前記情報処理手段はそれぞれ
所定の規則に基づいてデータ処理を行うものであり、各
情報処理手段は互いに異なる規則を有し、前記情報制御
システムはさらに、前記情報処理手段のいずれか一つで
処理されたデータの規則を他の情報処理手段の規則に適
合させる変換規則に基づいて、各情報処理手段で処理さ
れたデータの規則の変換処理を行う規則変換手段を備
え、前記処理命令手段は、前記処理命令を行ったある情
報処理手段の処理データの規則を他の情報処理手段の規
則に変換する規則変換命令を前記規則変換手段に対して
行い、該規則変換が終了した後に該他の情報処理手段に
対して処理命令を行う。これにより、複雑な処理手順を
踏むデータ処理を異なる規則に従った情報処理手段に順
次実行させる場合であっても、各情報処理手段による処
理プロセスを充分に把握した状態で処理を行うことがで
きる。

【００２５】また、１の実施形態によれば、情報処理手
段は、少なくとも所定のデータを処理するためのデータ
処理プログラムを格納した記憶手段を有する。

【００２６】なお、装置に係る本発明は、該装置により
実行される方法としても成立する。

【００２７】また、装置または方法に係る本発明は、コ
ンピュータに当該発明に相当する手順を実行させるため
の（あるいはコンピュータを当該発明に相当する手段と
して機能させるための、あるいはコンピュータに当該発
明に相当する機能を実現させるための）プログラム、該
プログラムを記録したコンピュータ読取り可能な記録媒
体としても成立する。

【００２８】

【発明の実施の形態】以下、図面を参照しながら本発明
の実施形態を説明する。

【００２９】（第１実施形態）図１は本発明の第１実施
形態に係る情報制御システムの概念図である。図１に示
すように、この情報制御システムは、単一のシステムク
ラスタ間ハブ１と３つのシステムクラスタ２〜４からな
る。システムクラスタとは、情報制御システムを複数の
情報処理単位に分割した場合の一情報処理単位であり、
ビジネスプロセスの処理単位毎に設定される。また、ハ
ブとは、複数の情報処理単位の管理を行う情報処理単位
であり、各情報処理単位への処理手順の決定、処理命
令、データ変換を実行する。例えばシステムクラスタ２
は株式の売買に関する処理を行う情報処理単位、システ
ムクラスタ３は営業成績を管理する情報処理単位、シス
テムクラスタ４は経理処理を行う情報処理単位というよ
うに設定される。なお、ハブ１に対応づけられるシステ
ムクラスタ数は３つに限定されず、複数であればいくつ
でもよい。また、システムクラスタ２〜４に対応づけら
れるハブ数は単一の場合に限られず、複数であってもよ
い。

【００３０】各システムクラスタ２〜４はそれぞれ単一
のハブと複数のサブシステムから構成される。サブシス
テムとは、システムクラスタをさらに複数の情報処理単
位に分割した場合の一情報処理単位であり、システムク
ラスタよりも詳細なビジネスプロセスの処理単位毎に設
定される。具体的には、システムクラスタ２はシステム
クラスタ内ハブ２１と２つのサブシステム２２及び２３
から構成される。システムクラスタ３はシステムクラス
タ内ハブ３１と３つのサブシステム３２〜３４から構成
される。システムクラスタ４はシステムクラスタ内ハブ
４１と３つのサブシステム４２〜４４から構成される。
なお、ハブ２１，３１及び４１に対応づけられたサブシ
ステムの数は２つあるいは３つに限定されるものではな
く、４つ以上であってもよい。また、複数のサブシステ
ムに対応づけられるハブ数は単一に限られず、複数であ
ってもよい。

【００３１】図２はシステムクラスタ間ハブ１の詳細な
構成を示す図である。図２に示すように、システムクラ
スタ間ハブ１は、ルーティング制御部１１と、データ記
述形式変換部１２から構成される。

【００３２】ルーティング制御部１１は、各システムク
ラスタ２〜４に対する処理命令の処理手順を複数格納す
るビジネスルールデータベース１１ｂと、このビジネス
ルールデータベース１１ｂに格納された処理手順のうち
のいずれかに基づいて各システムクラスタ２〜４に処理
命令を出すルーティングエンジン１１ａを有する。

【００３３】データ記述形式変換部１２には、各システ
ムクラスタ２〜４で使用されるデータ記述形式標準のデ
ータ記述形式との間のデータ記述形式変換を行うための
データ記述形式変換ツール１２ａが設けられている。ま
た、データ記述形式変換ルールデータベース１２ｂは、
データ記述形式変換ツール１２ａにおけるデータ記述形
式変換を行うデータ記述形式変換ルールを格納してい
る。具体的には、システムクラスタ２，３及び４それぞ
れで使用されるデータ記述形式と標準データ記述形式の
間のデータ記述形式変換ルールを格納している。従っ
て、データ記述形式変換ルールデータベース１２ｂに格
納されたデータ記述形式変換ルールはシステムクラスタ
の数だけ存在する。もちろん、不要な変換ルールは格納
しておかなくてもよい。また、データ項目情報データベ
ース１２ｃには、標準データのデータ記述形式及び副標
準データ記述形式のフォーマットが記憶されている。

【００３４】標準データ記述形式とは、各システムクラ
スタ２〜４で使用されるそれぞれのデータ記述形式と互
換性を有するデータ記述形式であり、各システムクラス
タ２〜４で使用されるそれぞれのデータ記述形式の間の
変換の際には、この標準データ記述形式を経由すること
となる。例えば、システムクラスタ２で使用されるデー
タ記述形式からシステムクラスタ３で使用されるデータ
記述形式に変換される場合、システムクラスタ２で使用
されるデータ記述形式から一旦標準データ記述形式に変
換され、その後システムクラスタ３で使用されるデータ
記述形式に変換される。

【００３５】図３は株式の売買に関する処理を行うシス
テムクラスタ２の詳細な構成の一例を示す図である。図
３に示すように、システムクラスタ内ハブ２１は、ルー
ティング制御部２１１とデータ記述形式変換部２１２を
有する。

【００３６】ルーティング制御部２１１は、ルーティン
グエンジン２１１ａと、このルーティングエンジン２１
１ａに接続されたビジネスルールデータベース２１１ｂ
から構成される。データ記述形式変換部２１２は、デー
タ記述形式変換ツール２１２ａと、このデータ記述形式
変換ツール１１２ａに接続されたデータ記述形式変換ル
ールデータベース２１２ｂとデータ項目情報データベー
ス２１２ｃから構成される。

【００３７】サブシステム２２は、株式注文約定処理を
実行する情報処理単位であり、株式注文約定処理の実行
に必要な具体的な処理を行うためのシステム機能２２ａ
及び２２ｂを有する。システム機能とは、サブシステム
をさらに複数の情報処理単位に分割した場合の一情報処
理単位であり、サブシステムよりも詳細なビジネスプロ
セスの処理単位毎に設定される。システム機能は、例え
ばデータの処理を行うプログラム、アプリケーション等
の処理機能のみならず、例えばオブジェクト指向等によ
り記述される場合の属性と操作を双方含む概念も含まれ
る。また、サブシステム２３は、株式決済処理を実行す
る情報処理単位であり、株式決済処理の実行に必要な具
体的な処理を行うためのシステム機能２３ｃ及び２３ｄ
を有する。

【００３８】ルーティングエンジン２１１ａは、ビジネ
スルールデータベース２１１ｂに格納されたビジネスル
ールに基づいて各サブシステム２２及び２３における情
報処理の手順を決定するとともに、その手順に基づいて
処理命令をサブシステム２２及び２３に出す。

【００３９】データ項目情報データベース２１２ｃに
は、副標準データのデータ記述形式及び各地方データ記
述形式のフォーマットが記憶されている。図４は副標準
データ記述形式のフォーマットの構成の一例を示す図で
ある。副標準データ記述形式の場合、ＩＳＩＮ（Intern
ational Securities Identification Number：ＩＳＯ６
１６６の推奨により規格化された有価証券等の識別コー
ド）、約定年月日、株式約定数量、株式約定単価、名義
区分という５つのデータ項目からデータが表現され、各
データ項目には、各データ項目の属性として、説明、属
性、データ長、小数点位置、不正値が対応づけられてい
る。また、地方データ記述形式のフォーマットの構成の
一例を示す図である。

【００４０】図５はデータ記述形式変換ルールデータベ
ース２１２ｂの詳細な構成の一例を示す図である。図５
に示すように、副標準データ記述形式のデータ項目と地
方データ記述形式のデータ項目が対応づけられている。
さらに、地方データ記述形式のデータ項目には、副標準
データを地方データに変換する変換手順が対応づけられ
ている。

【００４１】地方データ記述形式とは、サブシステム２
２や２３における各種データ処理の際のデータを表現す
る形式であり、副標準データ記述形式とは、各サブシス
テムで使用されるそれぞれのデータ記述形式と互換性を
有するデータ記述形式であり、各サブシステムで使用さ
れるそれぞれのデータ記述形式の間の変換の際には、こ
の副標準データ記述形式を経由することとなる。

【００４２】ビジネスルールデータベース２１１ｂに
は、以上に示されるサブシステム２２やサブシステム２
３、さらに詳細には各システム機能の処理手順が複数記
憶されている。処理手順は、例えば各システム機能での
処理を順序立てて行うための順序構造、各システム機能
でのデータ処理結果等に応じて処理手順を選択する選択
構造、各システム機能でのデータ処理結果が所定の条件
を満たすまで所定のシステム機能での処理を繰り返し行
う繰り返し構造、あるシステム機能でのデータ処理結果
により与えられる複数の値のそれぞれに応じて処理を分
岐させる多分岐構造、ある一つのシステム機能の処理終
了後、複数のシステム機能に同時に処理を実行させる同
時処理進行構造、各システム機能でのデータ処理結果等
が少なくとも一つの条件を満たした場合に次のシステム
機能での処理を開始する条件待ち構造や、これらの組み
合わせ等により構成される。

【００４３】このビジネスルールデータベース２１１ｂ
に格納された処理手順の具体例を図１３に示す。

【００４４】例えば４つの処理手順ＩＤ（１〜４）を有
する処理手順が図１３（ａ）〜（ｄ）に示されている。
処理手順ＩＤが１の図１３（ａ）は、システム機能２２
ａ，２２ｂ，２３ｃ，２３ｄの順に処理する処理手順を
示す。処理手順ＩＤが２の図１３（ｂ）は、システム機
能２２ａを処理後、システム機能２２ｂ及び２３ｃを同
時処理し、各処理が終了した後システム機能２３ｄの処
理を行う処理手順を示す。処理手順ＩＤが３の図１３
（ｃ）は、システム機能２２ａ，２２ｂを順に処理し、
その後システム機能２３ｃ及び２３ｄを同時処理する処
理手順を示す。処理手順ＩＤが４の図１３（ｄ）は、シ
ステム機能２２ａ処理後、システム機能２２ａのデータ
処理結果に示されるデータ項目のうち、約定単価の値が
５００以上か５００未満かにより枝分かれする処理手順
であり、約定単価≦５００の場合にはシステム機能２２
ｂの処理を行い、約定単価＞５００の場合にはシステム
機能２３ｃの処理を行い、いずれかの処理が終了した後
システム機能２３ｄの処理を行う。

【００４５】また、各処理手順における各システム機能
での処理開始条件を例えば図１４に示すように設定して
もよい。この処理開始条件は、図１３に示す処理手順に
関連付けられてビジネスルールデータベース２１１ｂに
格納される。図１４の例では、例えば処理手順ＩＤが１
の場合、各システム機能の処理は前のシステム機能の処
理が終了したことが処理の開始条件となっている。処理
手順ＩＤが３の場合、システム機能２２ｂの処理は、シ
ステム機能２２ａのデータ処理結果のうち、約定単価≦
５００が取得された後に開始され、システム機能２３ｃ
は約定単価＞５００のシステム機能２２ａのデータ処理
結果を取得したことを条件に処理が開始され、システム
機能２３ｄはシステム機能２２ｂ及び２３ｃ双方の処理
が終了したことを条件に処理が開始されることを示して
いる。

【００４６】以上のように構成された情報制御システム
の動作の一例を図６に示すフローチャートを用いて説明
する。

【００４７】まず、システムクラスタ間ハブ１のルーテ
ィングエンジン１１ａは、例えば本システム外部から処
理命令を受けると、その処理命令に基づいてビジネスル
ールデータベース１１ｂを参照して処理手順を決定する
（ｓ１）。例えばシステムクラスタ２での処理、システ
ムクラスタ３での処理、システムクラスタ４での処理の
順に処理手順が決定されると、ルーティングエンジン１
１ａは、まずシステムクラスタ２に対して処理命令を出
す（ｓ２）。この処理命令に基づき、システムクラスタ
２による処理が開始される（ｓ３）。

【００４８】システムクラスタ２による処理（ｓ３）の
一例を図７に示すフローチャートに沿って詳細に説明す
る。

【００４９】処理命令を受けたシステムクラスタ２のル
ーティング制御部２１１は、ビジネスルールデータベー
ス２１１ｂを参照し、システムクラスタ間ハブ１の処理
命令に基づいて処理手順を決定する（ｓ３１）。例えば
前述した処理手順ＩＤが１の図１３（ａ）に示す処理手
順、すなわちサブシステム２２でのシステム機能２２
ａ、システム機能２２ｂ、サブシステム２３でのシステ
ム機能２３ｃ、システム機能２３ｄでの処理の順に処理
手順が決定されると、ルーティングエンジン２１１ａ
は、まず、サブシステム２２に対してシステム機能２２
ａ、システム機能２２ｂの順に処理するように処理命令
を出す（ｓ３２）。

【００５０】処理命令を受けたサブシステム２２は、ま
ずシステム機能２２ａによる処理を実行した後（ｓ３
３）、システム機能２２ｂによる処理を実行する（ｓ３
４）。これら処理の結果は、サブシステム２２に固有の
データ記述形式で得られる。サブシステム２２固有のデ
ータ記述形式の一例を図８に示す。サブシステム２２
は、システム機能２２ｂによる処理が終了すると、処理
の終了をシステムクラスタ内ハブ２１に通知する（ｓ３
５）。

【００５１】システムクラスタ内ハブ２１のルーティン
グエンジン２１１ａは、処理の終了を受けて図８に示す
データ記述形式で得られたサブシステム２２固有の地方
データを、次の処理手順を実行するサブシステム２３で
用いられる地方データに変換するようデータ記述形式変
換部２１２に命令を出す。データ記述形式変換部２１２
のデータ記述形式変換ツール２１２ａは、データ記述形
式変換ルールデータベース２１２ｂを参照してサブシス
テム２２固有の地方データを一旦システムクラスタ２固
有の副標準データに変換する（ｓ３６）。さらに、得ら
れた副標準データに対してデータ記述形式変換ルールデ
ータベース２１２ｂを参照してサブシステム２３固有の
地方データに変換する（ｓ３７）。

【００５２】サブシステム２３用のデータ記述形式で得
られる地方データの一例を図９に示す。図９に示すよう
に、サブシステム２３用のデータ記述形式で得られる地
方データのデータ項目は、サブシステム２２用のそれと
一部が共通し、一部が異なる。

【００５３】このサブシステム２２からサブシステム２
３の地方データへの変換処理の一例を以下に示す。

【００５４】例えば図８に示すように、サブシステム２
２の銘柄コードというデータ項目のデータ長は５桁とな
っており、これを債券等に関する情報との識別情報も含
むサブシステム２３の９桁の銘柄コードというデータ項
目に変換する。これにより、図９に示すようなデータ記
述形式の地方データが得られる。また、副標準データ記
述形式では株式約定数量というデータ項目は１５桁のデ
ータ長を有しており、これはサブシステム２２では、９
桁のデータ長の約定済数量というデータ項目である。こ
の約定済数量というデータ項目を一旦１５桁のデータ長
の株式約定数量というデータ項目に変換する。さらに、
この１５桁のデータ長の株式約定数量を約定数量に変換
する。

【００５５】また、サブシステム２２固有のデータ記述
形式では約定済数量は不正値がnoneというように設定さ
れており、この約定済数量に対応するサブシステム２３
固有の約定数量というデータ項目では不正値は≦０（未
約定状態）というように設定されている。データ記述形
式変換部２１２はサブシステム２２固有の約定済数量と
いうデータ項目を副標準データ記述形式の株式約定数量
というデータ項目に変換する際に、不正値（≦０）か否
かを判定する。

【００５６】この不正値はデータ項目の妥当性検査に用
いられる属性で、以下のような意義を有する。

【００５７】不正値が０でない場合、すなわちnoneであ
る場合には、次の処理手順に指定されたサブシステムに
処理命令を出せるデータ記述形式に変換できるため、そ
の処理手順下流のサブシステムへのデータ記述形式変換
を実行する。不正値が≦０である場合、処理手順下流の
サブシステムでは処理不可能なデータ記述形式であると
データ記述形式変換部２１２は判定し、処理手順下流の
サブシステムへのデータ変換処理を実行しない。これに
より、処理手順上流のサブシステムで処理が確定してい
ないのに次の処理手順のサブシステムの処理に進むとい
う不都合を回避できる。

【００５８】例えば図８に示すような地方データがデー
タ記述形式変換部２１２で判定される場合、不正値がno
neであるため、サブシステム２３に処理命令を出せると
データ記述形式変換部２１２は判定し、サブシステム２
３のデータ記述形式に変換する。なお、この判定は、サ
ブシステム２３で使用される地方データのフォーマット
をデータ項目情報データベース２１２ｃから参照し、こ
の参照された不正値とサブシステム２２でのデータ処理
結果に基づいて行われる。

【００５９】次に、サブシステム２３でのデータ処理結
果が図９に示すような場合、不正値が０、すなわち≦０
であるため、次の処理プロセスに進めないデータ構造で
あるとデータ記述形式変換部２１２は判定し、副標準デ
ータへのデータ変換処理を実行しない。これにより、株
式注文約定が確定したが株式決済のプロセスが確定して
いないのに次の処理プロセスに進むという不都合を回避
できる。

【００６０】なお、サブシステム２３へのデータ変換処
理を実行しない場合には、サブシステム２２に対してデ
ータ変換処理を実行できないデータ記述形式であること
を通知してもよいし、ルーティングエンジン２１１ａに
対してデータ変換処理を実行できないデータ記述形式を
サブシステム２２から受けたことを通知してもよい。こ
の場合、ルーティングエンジン２１１ａがサブシステム
２２に対してデータ変換処理を実行できなかったデータ
の再処理命令を出してもよい。具体的には例えば、サブ
システム２３によるデータ処理を実行しない場合には、
サブシステム２２で処理されたデータ処理結果を一旦デ
ータ記述形式変換部２１２に設けられた図示しないデー
タベースに格納し、あるいはそのデータ処理結果をサブ
システム２２ａに突き返し、あるいはそのデータ処理結
果を消去する等の手法を取ることができる。

【００６１】このように、各データ項目に不正値という
属性を持たせ、データ変換可／付加の判定をシステムク
ラスタ内ハブ２１に実行させることにより、処理手順を
進められない状況を容易に把握できるとともに、データ
の浄化機能が働く。

【００６２】また、図８及び図９に示すデータ項目に対
応してデータ属性“種類”が規定されている。この“種
類”は、地方データと副標準データの種類を示すもの
で、このデータ項目が“local”に設定されている場
合、そのデータ項目は地方データ固有のデータ項目、す
なわちそのサブシステムに固有であって他のサブシステ
ムにはその概念は存在しないデータ項目であることを示
す。“dialect”に設定されている場合、その地方デー
タのみならず副標準データと共通する、すなわち他のサ
ブシステムとデータ記述形式は異なることがあるが、他
のサブシステムにも存在するデータ項目であることを示
す。“local”に設定されているデータ項目について
は、サブシステム内に隠蔽し、他のサブシステムから参
照できないように設定するのが望ましい。これにより、
サブシステムの独立性及び保守性を向上させることがで
きる。従って、この“local”に設定されているデータ
項目については本システムの管理対象外となり、本シス
テムとは無関係に自由に設定することができる。

【００６３】なお、上記サブシステム２２からサブシス
テム２３へのデータ変換処理の具体例はほんの一例にす
ぎない。

【００６４】データ記述形式の変換が終了すると、デー
タ記述形式変換部２１２はルーティングエンジン２１１
ａに対して処理の終了を通知する。データ記述形式変換
終了を受けて、ルーティングエンジン２１１ａは、サブ
システム２３に対してシステム機能２３ｃ、システム機
能２３ｄの順に処理するように処理命令を出す（ｓ３
８）。処理命令を受けたサブシステム２３は、まずシス
テム機能２３ｃによる処理を実行（ｓ３９）した後、シ
ステム機能２３ｄによる処理を実行する（ｓ４０）。こ
れら処理の結果は、図９に示されるようなサブシステム
２３に固有のデータ記述形式で得られる。サブシステム
２３は、システム機能２３ｄによる処理が終了すると、
処理の終了をシステムクラスタ内ハブ２１に通知する
（ｓ４１）。

【００６５】サブシステム２３から処理の終了を受けた
システムクラスタ内ハブ２１は、サブシステム２３固有
のデータ記述形式で取得されたデータをシステムクラス
タ２固有の副標準データ記述形式に変換するようにデー
タ記述形式変換部２１２に命令を出す。データ記述形式
変換部２１２のデータ記述形式変換ツール２１２ａは、
データ記述形式変換ルールデータベース２１２ｂを参照
してサブシステム２３固有の地方データをシステムクラ
スタ２固有の副標準データに変換する（ｓ４２）。デー
タ記述形式の変換が終了すると、処理の終了をルーティ
ング制御部２１１に通知する。

【００６６】ルーティング制御部２１１は、このデータ
記述形式変換処理の終了を受けると、そのシステムクラ
スタ２における処理が終了したと判定し、処理の終了を
システムクラスタ間ハブ１に通知する（ｓ４）。システ
ムクラスタ間ハブ１のルーティング制御部１１は、この
システムクラスタ２からの処理の終了を受けて、システ
ムクラスタ２固有の副標準データ記述形式で特定される
データを標準データ記述形式に変換するようデータ記述
形式変換部１２に命令を出す。データ記述形式変換部１
２のデータ記述形式変換ツール１２ａは、データ記述形
式変換ルールデータベース１２ｂを参照してシステムク
ラスタ２固有の副標準データを標準データに変換し（ｓ
５）、標準データからシステムクラスタ３固有の副標準
データにデータ記述形式を変換する（ｓ６）。データ記
述形式の変換が終了すると、処理の終了をルーティング
制御部１１に通知する。

【００６７】標準データへの変換処理の終了を受け、ル
ーティングエンジン１１ａは、処理開始時に決定した処
理手順に基づいて次の処理を行うべきシステムクラスタ
３に処理命令を出す（ｓ７）。システムクラスタ３はこ
の処理命令を受けて上記システムクラスタ２と同様に副
標準データ記述形式と地方データ記述形式との間のデー
タ変換を用いて処理を行い（ｓ８）、処理結果をシステ
ムクラスタ３固有の副標準データ記述形式に変換して処
理の終了をシステムクラスタ間ハブ１に通知する（ｓ
９）。

【００６８】ルーティングエンジン１１ａはこの処理終
了の通知を受けてデータ記述形式変換部１２にシステム
クラスタ３固有のデータ記述形式を標準データ記述形式
に変換させ、さらに標準データ記述形式をシステムクラ
スタ４固有のデータ記述形式に変換させる（ｓ１０，１
１）。変換が終了すると、ルーティングエンジン１１ａ
はシステムクラスタ４に処理命令を出す（ｓ１２）。シ
ステムクラスタ４はこの処理命令を受けて上記システム
クラスタ２や３と同様の処理を行い（ｓ１３）、処理結
果をシステムクラスタ４固有の副標準データ記述形式に
変換して処理の終了をシステムクラスタ間ハブ１に通知
する（ｓ１４）。

【００６９】ルーティングエンジン１１ａはこの処理終
了の通知を受けてデータ記述形式変換部１２にシステム
クラスタ４固有のデータ記述形式を標準データ記述形式
に変換させる（ｓ１５）。標準データ記述形式への変換
が終了の通知をデータ記述形式変換部１２から受けたル
ーティングエンジン１１ａは、すべての処理が終了した
と判定し、処理を終了する。

【００７０】以上説明したように本実施形態によれば、
それぞれが異なるデータ記述形式により処理される複数
のサブシステムやシステムクラスタに対して単一のハブ
を設け、各サブシステムや各システムクラスタ間のデー
タ記述形式の変換をハブで行うことにより、複数存在す
るシステムの機能それぞれにデータ記述形式の変換手段
を設ける必要がない。

【００７１】具体的には例えば、ｎ個のサブシステムが
設けられている場合、他のｎ−１個のサブシステムとの
間のデータ記述形式の変換を行うデータ記述形式変換手
段を設けることなく、ｎ個のサブシステムと副標準デー
タ記述形式とのデータ記述形式の変換を行うデータ記述
形式変換手段を設けるのみで、すべてのサブシステム間
のデータ記述形式の変換を行うことができる。

【００７２】また、これらデータ記述形式の変換をハブ
で一元的に行うことにより、各サブシステムの管理が容
易となる。

【００７３】具体的には例えば、新たにサブシステムを
設ける場合には、そのサブシステムが対応づけられるハ
ブのデータ記述形式変換ルールデータベース２１２ｂに
そのサブシステムと副標準データ記述形式との変換ファ
イルを設けるのみで、そのハブに対応づけられた他のす
べてのサブシステムとの間のデータ記述形式の変換が可
能となる。また、サブシステムを変更する場合には、ハ
ブの変換ファイルの当該サブシステムに該当する部分を
変更するのみで対応可能である。また、サブシステムを
削除する場合には、ハブの変換ファイルの当該サブシス
テムに該当する部分を削除するのみで対応可能である。

【００７４】また、ハブにルーティングエンジンを設け
ることにより、各サブシステムには処理手順を判定する
手段を設けることなく複数のサブシステムを用いた処理
を所定の処理手順に基づいて実行できる。また、ルーテ
ィングエンジンで処理手順を一元管理することにより、
各サブシステムに順序規則を関連付けて処理する必要が
なく、システム管理が容易となる。

【００７５】さらに、上記データ記述形式では、標準デ
ータ記述形式、副標準データ記述形式、地方データ記述
形式という３階層のデータ記述形式により各データ処理
を実行したが、このように複数の階層にデータ記述形式
を分割し、かつ複数の下層のデータ記述形式と単一の上
層のデータ記述形式で管理することにより、上層のデー
タ記述形式との間の一つのデータ変換手段を設けるのみ
で、データの互換性が確保されたサブシステムやシステ
ムクラスタを追加することができる。また、ルーティン
グエンジンが参照するビジネスルールデータベースに、
追加したサブシステムやシステムクラスタの処理を含む
処理手順を組み込むのみで、追加したサブシステムやシ
ステムクラスタを含む処理手順を簡便に実行可能であ
る。

【００７６】また、システム機能が増加してシステムが
複雑化すると、システム全体の把握が困難となるが、本
実施形態のように実際のビジネスプロセスの処理単位で
ある株式注文約定や株式決済等をシステム機能に対応づ
けてシステムを構築することにより、実際のビジネスプ
ロセスに沿ったシステムの把握が可能となる。従って、
ビジネスプロセスに沿って実際のビジネスを遂行する者
とシステムの設計開発者との間の情報伝達が円滑に行え
る。その結果、ビジネス変化に対する対応の迅速化が図
れる。

【００７７】また、各ハブにサブシステムやシステムク
ラスタとの間のデータ記述形式の互換性を有する共通規
則を特定するデータ項目情報データベースが対応づけて
設けられている。これにより、システムを追加する場合
や新たに変更する場合等、システム管理者は対象とする
サブシステムやシステムクラスタで用いられるデータ記
述形式を定める場合の管理が容易となる。

【００７８】本発明は上記実施形態に限定されるもので
はない。

【００７９】上記実施形態ではデータが属する領域は特
に言及していないが、各サブシステムやシステムクラス
タ、ハブ等の情報処理機能毎にそれぞれ記憶手段を対応
付け、データ処理の処理手順に従って処理すべきデータ
を処理手順に沿ってある情報処理機能の記憶手段から他
の情報処理機能の記憶手段に出力してもよい。

【００８０】また、各ハブには規則変換手段としてデー
タ記述形式変換部を備えた場合を示し、ハブでデータ記
述形式を一元的に管理する場合を示したが、これに限定
されるものではない。例えば、文字コード体系の変換や
通信プロトコルの変換、データ項目の配列順序の変換
（データの分解、選択、合成を含む）等、各システム機
能で互いに相違するデータ記述形式以外の規則の変換を
ハブで一元的に行うこともできる。なお、データの分
解、選択、合成とは、一つのレコードを２つのレコード
にする、複数のレコードを一つのレコードにする、複数
のレコードのうちの一部のみを残し、他のレコードを消
去する等、種々の形態が考えられる。また、文字コード
とは、例えばＪＩＳ（Japan Industrial Standards）、
シフト−ＪＩＳ、ＥＵＣ（Ｅｘｔｅｎｄｅｄ ＵＮＩＸ
（登録商標）Ｃｏｄｅ）、ＥＢＣＤＩＣ（Extended B
inary Coded Decimal Interchange Code）等、異なる規
格により規定された文字コードを含む概念である。

【００８１】文字コード体系の変換をハブで管理する場
合には、ハブに各サブシステムや各システムクラスタで
使用される文字コードと各文字コードとの間で互換性を
有する共通文字コードとの文字コード体系変換手段を設
けることにより本発明を適用可能である。

【００８２】また、通信プロトコルをハブで一元的に管
理する場合には、ハブに各サブシステムやシステムクラ
スタで使用される通信プロトコルと各通信プロトコルと
の間で互換性を有する共通通信プロトコルとの通信プロ
トコル変換手段を設けることにより本発明を適用可能で
ある。

【００８３】さらに、各サブシステムやシステムクラス
タで使用される文字コード体系や通信プロトコル以外の
いかなる規則であっても、各サブシステムや各システム
クラスタの規則との間で互換性を有する共通規則を定
め、各規則と共通規則との間の変換をハブで行うように
することにより本発明を適用することができる。

【００８４】また、ハブ、システムクラスタ、サブシス
テム等、本システムを構成する情報処理機能と物理的な
ハードウェア構成の対応付けは種々考えられるが、例え
ば図１０に示すように、システムクラスタ間ハブ１をサ
ーバ１００、各システムクラスタ２〜４を該サーバ１０
０にネットワーク５００を介して接続する対応付けでも
よいし、ネットワークの介在しない単一の汎用コンピュ
ータの記憶領域の各部にハブ、システムクラスタ、サブ
システムを実現するためのプログラムを格納し、各記憶
領域から各プログラムが読み出されることにより各シス
テム機能の処理やルーティング、データ記述形式変換等
が実行されるものであってもよい。より具体的には例え
ば、各クラスタをハードウェアとしてのコンピュータ１
台に対応付けてもよい。コンピュータが異なると、デー
タ保持形式、データ処理形式、通信方式等、規則が異な
る可能性が高いためである。また、このように各クラス
タをコンピュータ１台に対応づけた場合、クラスタの下
位に位置づけられるサブシステムは例えばそのコンピュ
ータ内にある複数の処理空間のそれぞれに対応づけても
よい。処理空間とは、具体的には例えば多重仮想記憶機
構のアドレス空間や、階層的に体系化されたプロセス群
の上位に位置するプロセスの個々を意味する。なお、さ
らに望ましくは、システムの処理内容をビジネス機能の
観点から区分けし、サブシステムとして整理・管理す
る。サブシステム内のシステム機能は極めて密に結合さ
れ、各サブシステム同士の結合度は疎であることが望ま
しい。これにより、各サブシステムの保守性が向上す
る。なお、結合度の疎・密は、データの授受の疎・密に
近い概念であり、例えば密結合の場合にはデータの授受
を頻繁に行う必要がある形態であり、疎結合は、ごく少
ない種類のインタフェース仕様や少量のデータ授受で成
立する形態である。もちろん、クラスタ、サブシステム
のハードウェアとの対応付けはここに示したものに限ら
れない。

【００８５】また、サブシステムのみにシステム機能を
設ける場合を示したが、システムクラスタやハブにもシ
ステム機能を設けてもよい。この場合、ビジネスルール
データベースにはシステムクラスタやハブのシステム機
能における処理も含めた処理手順を格納しておくことに
より、このようなシステム機能を含めた処理を実行する
ことができる。

【００８６】また、副標準データを介して異なるサブシ
ステムへのデータ変換処理を行う場合を示したが、これ
に限定されるものではない。例えば、データ記述形式変
換ルールデータベースには各サブシステムや各システム
クラスタ同士を直接変換する変換規則を格納しておき、
この変換規則に基づいて副標準データや標準データ等の
共通規則を介さずにデータ変換処理を行ってもよい。

【００８７】また、上記システムでは、使用するデータ
記述形式として、地方データ、副標準データ、標準デー
タの３階層のデータ記述形式を用いる場合で説明した
が、これに限定されるものではない。例えば、地方デー
タと標準データの２階層のシステムであれば、複数のサ
ブシステムとこれらサブシステムを管理する一つのハブ
を有する構成でよい。また、地方データをさらに細分化
し、４階層のデータ記述形式に本発明を適用してもよ
い。この場合、各階層にあるサブシステムを管理するハ
ブをそれぞれ設けることにより本発明を適用可能であ
る。

【００８８】４階層のデータ記述形式に本発明を適用す
る場合のサブシステム２２の構成の一例を図１１に示
す。図１１は図１〜図３におけるサブシステム２２に置
換して適用される。図１１に示すように、サブシステム
２２内にさらにハブ２２０とサブシステム２２０３，２
２０４が設けられている。このようなサブシステム２２
と同様にサブシステム２３を構成し、さらに他のシステ
ムクラスタ３，４のサブシステムもこのようにハブ及び
サブシステムから構成することにより、４階層のデータ
記述形式が適用される。

【００８９】もちろん、この図１１に示すサブシステム
２２に設けられるサブシステム２２０３及び２２０４内
にさらにハブ及びサブシステムからなるサブシステムを
設けることにより、５階層のデータ記述形式が実現され
る。もちろん、同様の手法により６階層以上のデータ記
述形式の階層化を実現することも可能である。

【００９０】逆に、２階層のデータ記述形式を適用する
場合、例えば図１２に示すように、複数のサブシステム
複数のシステムクラスタ内ハブ２１，３１，４１がそれ
ぞれ複数のサブシステム３２〜３４，２２〜２３，４２
〜４４を管理し、かつ各システムクラスタ内ハブ２１，
３１，４１がシステムクラスタ間ハブを介さずにデータ
記述形式の変換を行う形態でもよい。このように、デー
タ記述形式の階層を少なくすることにより、システムの
管理が容易となる。すなわち、より少ない数のハブを管
理することにより、すべてのシステムクラスタやサブシ
ステムのデータ記述形式、ビジネスルールを管理するこ
とが可能となる。特に、ハブとシステムクラスタがサー
バと端末というように物理的に別個のハードウェアに搭
載される場合等には、単一のサーバ（ハードウェア）を
参照することのみで他のすべての端末のデータ記述形式
等の管理が可能となる。

【００９１】また、上記実施形態ではシステムクラス
タ、サブシステム及びシステム機能をビジネスプロセス
の処理単位毎に設定する場合を示したが、他の処理単位
毎に設定してもよいことはもちろんである。

【００９２】

【発明の効果】以上詳述したように本発明によれば、簡
便且つ効率的にビジネスプロセスを実現することができ
る情報制御システム及び情報制御方法が実現できる。

【図面の簡単な説明】

【図１】本発明の第１実施形態に係る情報制御システム
の概念図。

【図２】同実施形態に係るシステムクラスタ間ハブの詳
細な構成を示す図。

【図３】同実施形態に係るシステムクラスタの詳細な構
成の一例を示す図。

【図４】同実施形態に係る副標準データ項目情報データ
ベースの構成の一例を示す図。

【図５】同実施形態に係るデータ記述形式変換ルールデ
ータベースの詳細な構成の一例を示す図。

【図６】同実施形態に係る情報制御システムの動作のフ
ローチャートの一例を示す図。

【図７】同実施形態に係る情報制御システムのシステム
クラスタの動作のフローチャートの一例を示す図。

【図８】同実施形態に係るサブシステム２２固有のデー
タ記述形式で得られる地方データの一例を示す図。

【図９】同実施形態に係るサブシステム２３固有のデー
タ記述形式で得られる地方データの一例を示す図。

【図１０】同実施形態に係る情報制御システムの変形例
を示す図。

【図１１】同実施形態に係るサブシステムの変形例を示
す図。

【図１２】同実施形態の変形例に係わる２階層のデータ
記述形式による情報制御システムの概念図。

【図１３】同実施形態に係るビジネスルールデータベー
スに格納された処理手順の具体例を示す図。

【図１４】同実施形態に係るビジネスルールデータベー
スに格納された処理手順に関連付けられた処理開始条件
の具体例を示す図。

【符号の説明】

１，１００…システムクラスタ間ハブ ２〜４…システムクラスタ １１，２１１…ルーティング制御部 １１ａ，２１１ａ…ルーティングエンジン １１ｂ，２１１ｂ…ビジネスルールデータベース １２，２１２…データ記述形式変換部 １２ａ…データ記述形式変換ツール １２ｂ…データ記述形式変換ルールデータベース １２ｃ…データ項目情報データベース ２１，３１，４１…システムクラスタ内ハブ ２２，２３，３２〜３４，４２〜４４…サブシステム ２２ａ，２２ｂ，２３ｃ，２３ｄ…システム機能 ２００，３００，４００…端末 ２１２ａ…データ記述形式変換ツール ２１２ｂ…データ記述形式変換ルールデータベース ２１２ｃ…データ項目情報データベース ５００…ネットワーク

Claims (17)

【特許請求の範囲】
1. 【請求項１】 所定の規則に基づいてデータ処理するも
   のであって、互いに異なる規則を有する複数の情報処理
   手段と、 前記情報処理手段のいずれか一つで処理されたデータの
   規則を他の情報処理手段の規則に適合させる変換規則に
   基づいて、各情報処理手段で処理されたデータの規則の
   変換処理を行う規則変換手段とを具備してなることを特
   徴とする情報制御システム。
2. 【請求項２】 前記規則変換手段は、各情報処理手段同
   士の前記変換規則を格納した変換規則記憶手段を有し、 前記変換規則記憶手段から前記変換規則を読み出すこと
   により前記変換処理を行うことを特徴とする請求項１に
   記載の情報制御システム。
3. 【請求項３】 前記規則とは、前記情報処理手段で処理
   されるデータ記述形式であることを特徴とする請求項１
   に記載の情報制御システム。
4. 【請求項４】 前記変換規則は、前記各情報処理手段で
   のデータ処理結果のフォーマットを示すデータ項目情報
   ファイルにより構成され、 前記規則変換手段は、前記データ項目情報ファイルに基
   づいて各情報処理手段でのデータ処理結果を変換するこ
   とを特徴とする請求項３に記載の情報制御システム。
5. 【請求項５】 前記データ項目情報ファイルにはデータ
   処理結果の妥当性を示す正／不正判定情報を含み、 前記規則変換手段は、前記正／不正判定情報と前記各情
   報処理手段でのデータ処理結果に含まれる正／不正判定
   情報に基づいてデータ処理結果の妥当性を判定すること
   を特徴とする請求項４に記載の情報制御システム。
6. 【請求項６】 前記各情報処理手段と前記規則変換手段
   はデータを送受信する送受信手段を備え、 前記送受信手段によるデータの送受信は前記規則に基づ
   いて処理されることを特徴とする請求項１に記載の情報
   制御システム。
7. 【請求項７】 前記規則変換手段は、前記複数の情報処
   理手段の前記規則のそれぞれと互換性を有する共通規則
   と、前記各規則との間の変換処理を行う共通規則変換手
   段を有することを特徴とする請求項１に記載の情報制御
   システム。
8. 【請求項８】 所定の規則に基づいてデータ処理する複
   数の情報処理手段と、 前記規則のうちの一つと他の規則との変換情報に基づい
   て前記複数のうちのある情報処理手段の前記規則を、前
   記複数の情報処理手段の前記規則のそれぞれと互換性を
   有する共通規則に変換し、かつ該共通規則を他の情報処
   理手段の前記規則に変換する第１の変換規則に基づいて
   変換処理を行う複数の第１の規則変換手段と、 前記複数の第１の規則変換手段それぞれの前記共通規則
   同士の間の第２の変換規則に基づいて第２の変換処理を
   行う第２の規則変換手段とを具備してなることを特徴と
   する情報制御システム。
9. 【請求項９】 データ処理を行う複数の情報処理手段
   と、 前記複数の情報処理手段におけるデータ処理の処理手順
   を少なくとも一つ記憶する処理手順記憶手段と、 前記処理手順記憶手段に記憶された処理手順に基づいて
   各情報処理手段に処理命令を行う処理命令手段とを具備
   してなることを特徴とする情報制御システム。
10. 【請求項１０】 前記処理手順は、前記情報処理手段に
    おけるデータ処理結果に応じて変更される手順を有する
    ことを特徴とする請求項９に記載の情報制御システム。
11. 【請求項１１】 前記処理手順は、少なくとも各情報処
    理手段の処理順序と、該各情報処理手段の処理開始条件
    により規定され、 前記処理命令手段は、前記処理開始条件を満たした場合
    に各情報処理手段に処理命令を行うことを特徴とする請
    求項９に記載の情報制御システム。
12. 【請求項１２】 前記処理命令手段は、処理命令を行っ
    たある前記情報処理手段の処理が終了した後、他の前記
    情報処理手段に対して処理命令を行うことを特徴とする
    請求項９に記載の情報制御システム。
13. 【請求項１３】 前記情報処理手段はそれぞれ所定の規
    則に基づいてデータ処理を行うものであり、各情報処理
    手段は互いに異なる規則を有し、 前記情報制御システムはさらに、前記情報処理手段のい
    ずれか一つで処理されたデータの規則を他の情報処理手
    段の規則に適合させる変換規則に基づいて、各情報処理
    手段で処理されたデータの規則の変換処理を行う規則変
    換手段を備え、 前記処理命令手段は、前記処理命令を行ったある情報処
    理手段の処理データの規則を他の情報処理手段の規則に
    変換する規則変換命令を前記規則変換手段に対して行
    い、該規則変換が終了した後に該他の情報処理手段に対
    して処理命令を行うことを特徴とする請求項１０に記載
    の情報制御システム。
14. 【請求項１４】 前記情報処理手段は、少なくとも所定
    のデータを処理するためのデータ処理プログラムを格納
    した記憶手段を有することを特徴とする請求項１又は９
    に記載の情報制御システム。
15. 【請求項１５】 所定の規則に基づいてデータ処理する
    複数の情報処理手段のうちの一つで処理されたデータ
    を、各情報処理手段同士の前記変換規則を格納した変換
    規則記憶手段から読み出した変換規則に基づいて他の情
    報処理手段で処理可能に変換処理することを特徴とする
    情報制御方法。
16. 【請求項１６】 所定の規則に基づいてデータ処理する
    ものであって、互いに異なる規則を有する複数の情報処
    理手段における各情報処理手段でのデータ処理手順を決
    定し、該決定された処理手順に基づいて各情報処理手段
    に対して処理命令を行うことを特徴とする情報制御方
    法。
17. 【請求項１７】 前記情報処理手段はそれぞれ所定の規
    則に基づいてデータ処理を行うものであり、 前記処理命令手段は、前記処理命令を行ったある情報処
    理手段の処理が終了した後、各情報処理手段同士の前記
    変換規則を格納した変換規則記憶手段から読み出した変
    換規則に基づいて他の情報処理手段で処理可能に変換処
    理を行うことを特徴とする請求項１６に記載の情報制御
    方法。