JP2010015593A - データ管理装置およびその方法 - Google Patents

データ管理装置およびその方法 Download PDF

Info

Publication number
JP2010015593A
JP2010015593A JP2009203139A JP2009203139A JP2010015593A JP 2010015593 A JP2010015593 A JP 2010015593A JP 2009203139 A JP2009203139 A JP 2009203139A JP 2009203139 A JP2009203139 A JP 2009203139A JP 2010015593 A JP2010015593 A JP 2010015593A
Authority
JP
Japan
Prior art keywords
data
processing
content
contract
program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2009203139A
Other languages
English (en)
Other versions
JP5039760B2 (ja
JP2010015593A5 (ja
Inventor
Mitsuyuki Ikeda
光之 池田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nissay Information Technology Co Ltd
Original Assignee
Nissay Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nissay Information Technology Co Ltd filed Critical Nissay Information Technology Co Ltd
Priority to JP2009203139A priority Critical patent/JP5039760B2/ja
Publication of JP2010015593A publication Critical patent/JP2010015593A/ja
Publication of JP2010015593A5 publication Critical patent/JP2010015593A5/ja
Application granted granted Critical
Publication of JP5039760B2 publication Critical patent/JP5039760B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q90/00—Systems or methods specially adapted for administrative, commercial, financial, managerial or supervisory purposes, not involving significant data processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Computational Linguistics (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】取り扱うデータ項目に差異のある商品データを管理する場合において、各商品データを含むデータを一元化して管理するとともに、システムやプログラムのメンテナンス性を向上させたデータ管理装置を提供する。
【解決手段】データ記録部１３は、種類ＩＤ（論理キー）とデータ内容ＩＤ（変数）を含むトランザクションデータ（契約データ）を記録する。データ定義部１７は、種類ＩＤごとに、データ内容ＩＤおよびデータ内容（約款データ）を記録する。データ処理手段１５は、データ記録部１３に記録された種類ＩＤに基づいてデータ定義部１７（定義体）からデータ内容ＩＤおよびデータ内容の組合せデータを取得し、所定のデータ項目（契約条件）のデータ内容に関する処理を実行する。これにより、約款や目論見書等によってその性格が異なる複数の商品データを一元的に管理することができる。
【選択図】図１

Description

関連出願の参照
日本国特許出願特願２００４−２９９０５５号（平成１６年１０月１３日出願）の明細書、請求の範囲、図面および要約を含む全開示内容は、これら全開示内容を参照することによって本出願に合体される。
この発明は、管理対象となるデータ項目がそれぞれ異なる複数のデータを管理するデータ管理装置およびその方法に関する。
一般にデータ管理の分野において、取り扱うデータの種類が多様化すると、データ種類毎に管理するデータ項目に差異が生じることがある。例えば、商品データを管理する場合において商品の種類が多様化すると、これに伴って管理する商品のデータ項目が多様化するため、商品種類ごとに様々なデータ項目を管理する必要がある。
このように管理するデータ項目に差異があり、多様な商品特性を有する複数の種類の商品データをコンピュータ装置を利用して取り扱う場合、トランザクション中に発生するすべての種類の商品データを、１つのレコードフォーマットを用いて管理する方法がある。この場合、すべての商品に必要なデータ項目を予め設定しているため、商品データを処理する業務プログラムは１つのデータベースのみを参照すればよい。
しかしながら、すべての種類の商品データを１つのレコードフォーマットを用いて管理すると、商品種類やデータ項目に変更が生じる度に、データ項目を定義するレコードフォーマットを変更しなければならず、変更作業が繁雑になるといった問題が生じる。また、特定の商品にのみ使用するデータ項目であっても、他のすべての商品のデータ項目として領域を確保しなければならず、全体として記憶領域を有効に使用することができないといった問題がある。
このような問題点を解決するため、以下のような従来技術（１）および（２）が存在する。なお、多様な商品特性を有する複数種類の商品を取り扱うものとして下記従来技術（３）が存在する。
（１）トランザクションデータ中に、商品種類を特定するための商品種類コードと、商品の内容を特定するための商品内容コードを記録しておき、商品種類ごとに、商品内容コードに対応する商品内容を複数のデータ項目に分けて記録した商品管理テーブルを作成しておく。トランザクションデータを処理する業務プログラムは、商品種類コードに基づいて商品管理テーブルを特定し、さらに商品内容コードに基づいて商品内容としての各データ項目を取得する。
したがって、商品種類に変更が生じた場合であっても、商品管理テーブルのみを変更すればよい。また、商品管理テーブルのデータ項目に変更が生じた場合であっても、商品管理テーブルのみを変更すればよい。これにより、トランザクションデータのレコードフォーマットを変更する必要がなくなる。
図１８に、上記従来技術（１）の例を示す。Ａは、保険契約を管理するトランザクションデータであり、証券番号１８０１、保険料１８０２、保険期間１８０３、約款コード１８０４、タイプ１８０５等のデータを管理するものである。この場合において、約款コード１８０４とは保険商品についての商品種類を特定するものである。Ｂは、約款コード１８０４が「０００１」である保険商品に対応する商品内容である「終身保険」のデータ項目を管理するテーブル（終身保険テーブル）であり、タイプ１８０６ごとにステップ払込年数１８０７およびステップ払込倍率１８０８のデータを管理するものである。Ｃは、約款コード１８０４が「０００２」である保険商品に対応する商品内容である「年金保険」のデータ項目を管理するテーブル（年金保険テーブル）であり、タイプ１８０９ごとに年金種類１８１１および年金支払期間１８１２のデータを管理するものである。
このように、商品種類である約款コード１８０４ごとに独立した管理テーブルを設け、タイプ１８０５に基づいて管理テーブルの商品内容を特定できるように構成することにより、新たな保険商品が追加された場合であっても、これに対応する商品管理テーブルを追加作成して、トランザクションデータのレコードフォーマットの変更を回避することができる。
なお、保険商品管理システムとして、商品情報テーブルに、商品ごとに共通な基本キーと商品ごとに意味が異なる副次キーを記録しておき、商品を取り扱うプログラムにおいて副次キーに基づいて商品情報テーブルを検索することにより、所望の商品情報を取得するものもある（例えば、特許文献２参照。）。
（２）トランザクションデータの中に自由定義項目を設けておき、自由定義項目内のフォーマットを商品種類毎に再定義することによって、所望の商品種類に対応したデータ項目にかかるデータを取得することができる。
したがって、商品種類に変更が生じた場合であっても、自由定義項目の再定義方法を変更するだけでシステム変更に対応することができる。これにより、トランザクションデータのレコードフォーマットを変更する必要がなくなる。
図１９に、上記従来技術（２）の例を示す。Ａは、保険契約を管理するトランザクションデータであり、証券番号１９０１、保険料１９０２、保険期間１９０３、約款コード１９０４、自由定義項目１９０５等のデータを管理するものである。この場合において、自由定義項目１９０５とは、約款コード１９０４によって特定される保険商品にかかる商品内容を再定義して使用するものである。Ｂは、自由定義項目１９０５を再定義して使用するＣＯＢＯＬ（Common Business Oriented Language）プログラムの一部である。すなわち、自由定義項目１９０５を、Ｘ（１００）のＦＩＬＬＥＲ項目として定義しておき、当該ＦＩＬＬＥＲ項目を商品種類ごとにＲＥＤＥＦＩＮＥＳ句を用いて再定義することにより、所望の約款コードに対応する商品種類に応じたデータを取り扱うことができる（例えば、非特許文献１参照。）。なお、再定義記述１９１１は商品種類が「終身保険」であるデータを再定義するものであり、同様に再定義記述１９１２は「年金保険」であるデータを再定義するものである。
このように、商品種類である約款コード１９０４ごとに自由定義項目を再定義するように構成することにより、新たな保険商品が追加された場合であっても、これに対応する再定義記述を追加して、トランザクションデータのレコードフォーマットの変更を回避することができる。
（３）商品種類ごとに、取り扱うデータ項目を構成要素としてそれぞれ規定した商品データベースを作成しておき、商品データを処理する業務プログラム中において使用する商品データベースおよび構成要素にかかるデータを記録するデータベースを切り替えること等によって、所望の商品種類における所望のデータ項目のデータ値を取得するシステムが知られている（例えば、特許文献１参照。）。
特開平１０−３３４１６０号公報
特開平０８−３２９１４２号公報
西村恕彦／植村俊亮 共著、「入門ＣＯＢＯＬ」、オーム社、平成５年４月１日、ｐ１４３−１４５
しかしながら、上記従来技術（１）では、商品種類を追加する場合には管理テーブルを新設し、商品種類のデータ項目を変更する場合には管理テーブルのフォーマットを変更しなければならない。この場合において、作業者は、商品種類ごとに管理テーブルに管理する各データ項目間の各データ内容についての整合性を図りつつ、各タイプを設定しなければならない。
例えば、図１８に示すＤは、約款コード１８０４が「０００３」である保険商品に対応する商品内容である「予定利率変動型年金保険」のデータ項目を管理するテーブル（予定利率変動型年金保険テーブル）であり、タイプ１８１３ごとに年金種類１８１４、年金支払期間１８１５および利率見直期間１８１６のデータを管理するものである。予定利率変動型年金保険テーブルを追加する場合、作業者は、類似するデータ項目を有するＣの年金保険テーブルに基づいて作業を行う。具体的には、複製したＣの年金保険テーブルに対して利率見直期間１８１６の列を追加することによって、Ｄの予定利率変動型年金保険テーブルを得ることができる。
利率見直期間１８１６のデータ内容としては、「５年ごと見直」と「１０年ごと見直」の２種類のデータが存在するとする。この場合、Ｃの年金保険テーブルの各行レコードに対して上記利率見直期間１８１６が設定できることになる。したがって、作業者は、年金種類１８１４、年金支払期間１８１５および利率見直期間１８１６の各組合せについての整合性を図りつつ、各行レコードに対応するタイプ１８１３を設定する必要がある。このような管理テーブルの追加作業は、作業者に多大の注意力や労力を費やすことを要求するため作業が繁雑となる。
また、上記従来技術（２）では、トランザクションデータを扱う業務プログラムにおいて、商品種類の違いに基づく業務プログラムの変更作業が多大となり、商品種類の追加変更する場合における業務プログラムのメンテナンス性が低下するという問題がある。
例えば、図１９に示すように、予定利率変動型年金保険に関する再定義記述１９１３を追加するとともに、約款コード１９０４が予定利率変動型年金保険を示す場合の判断ロジックを追加する必要がある。また、予定利率変動型年金保険を取り扱う場合の商品特性に関する処理ロジックを追加する必要がある。さらに、これらの作業後のＣＯＢＯＬプログラムを再コンパイルしてシステムテストを行う必要がある。このような業務プログラムの変更作業が要求されることにより、業務プログラムのメンテナンス性が低下する。
さらに、上記従来技術（３）の場合、商品種類ごとに使用する構成要素の組合せが異なるため、商品種類ごとにトランザクション中のフォーマットを変更しなければならない。このためトランザクションデータの一元化が困難となり、システム構成が複雑化するという問題がある。
この発明は、取り扱う商品またはサービスの種類に追加や変更が発生した場合であっても、（１）作業者に多大の負担を強いることなくシステム変更を可能とし、（２）業務プログラムのメンテナンス性の低下を防ぎ、（３）複数のデータ項目を有するデータを含むトランザクションデータを一元化してシステム構成を簡単にすることのできるデータ管理装置を提供することを目的とする。
(1)(2)(57)この発明にかかるデータ管理装置は、
管理対象となるデータ項目がそれぞれ異なるデータを管理するためのデータ管理装置であって、
少なくとも、データＩＤ、種類ＩＤおよびデータ内容ＩＤを含むデータ記録部と、
データ項目ごとに、データ内容ＩＤに対応するデータ内容を記録したデータ定義部と、
前記データ記録部に記録されたデータ内容ＩＤと一致する、前記データ定義部に記録されたデータ内容ＩＤに基づいて、前記データＩＤによって特定されるデータの種類を示す種類ＩＤの所定のデータ項目に対応するデータ内容を決定する処理を行うデータ処理手段と、
を備えたことを特徴としている。
したがって、管理対象となるデータ項目におけるデータ内容をデータ内容ＩＤによって記録することができる。このため、データ項目が異なるデータであっても同一フォーマットを用いて一元的に管理することができ、システム構成を簡単にすることができる。
(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)この発明にかかるデータ管理装置において、
データ記録部は、データＩＤによって特定されるデータの属性を示す属性ＩＤを記録しており、
データ定義部は、属性ＩＤごとに、データ項目ＩＤとデータ内容ＩＤの組合せを記録しており、
データ処理手段は、属性ＩＤごとに、データ項目およびこれに対応するデータ内容を決定する処理を行うことを特徴としている。
したがって、異なる属性ＩＤを有するデータレコードについて、同一のデータベース上において管理することができる。例えば、属性ＩＤによって企業を識別する場合には、１つのデータ管理装置において複数の企業のデータレコードを管理することができる。
(34)この発明にかかるデータ管理装置において、
データ記録部は、データ項目に対応するデータ項目ＩＤとデータ内容の組合せを記録しており、
データ定義部は、データ項目ＩＤとデータ項目の組合せを記録しており、
データ処理手段は、前記データ記録部に記録されたデータ項目ＩＤと一致する、前記データ定義部に記録されたデータ項目ＩＤに基づいて、前記データ記録部に記録されたデータ内容に対応するデータ項目を決定する処理を行うことを特徴としている。
したがって、データ記録部に記録したデータ内容に対応するデータ項目をデータ定義部によって指定することができ、データ記録部に記録するデータの汎用性を高めることができる。
(35)この発明にかかるデータ管理装置において、
データ記録部は、データ項目ＩＤとデータ内容の組合せを複数記録していることを特徴としている。
したがって、管理対象とするデータ項目を多様に定義することができる。
(36)この発明にかかるデータ管理装置において、
データ定義部は、データ項目ＩＤとデータ項目の組合せを、データ記録部に記録されるデータ内容におけるデータ型ごとに記録していることを特徴としている。
したがって、予めデータベースに指定されるデータ型が同一のデータであってデータ項目が異なるデータを、データベース上において効率よく管理することができる。
(37)この発明にかかるデータ管理装置において、
データ型は、日付型、数値型、文字型またはバイナリ型のいずれかを含むものであることを特徴としている。
したがって、データ項目が異なるデータをデータ型によらず管理することができる。
(38)この発明にかかるデータ管理装置において、
データ記録部は、データＩＤによって特定されるデータの属性を示す属性ＩＤを記録しており、
データ定義部は、属性ＩＤごとに、データ項目ＩＤとデータ項目の組合せを記録しており、
データ処理手段は、属性ＩＤごとにデータ項目を決定する処理を行うことを特徴としている。
したがって、異なる属性ＩＤを有するデータレコードについて、同一のデータベース上において管理することができる。例えば、属性ＩＤによって企業を識別する場合には、１つのデータ管理装置において複数の企業のデータレコードを管理することができる。
(39)この発明にかかるデータ管理装置において、
データ処理手段は、後記計算処理部において使用する計算条件を設定するための条件設定部と、前記計算条件に基づいて所定の計算処理を行うための計算処理部を含んで構成されており、前記条件設定部においてのみデータ定義部またはグループ定義部へのアクセスを行うことを特徴としている。
したがって、共通の入出力項目を用いる普遍的な計算処理を計算処理部に記述しておき、条件設定部において前記入出力項目を適切にハンドリングすることにより、取扱データ間における計算条件の差異を吸収することができる。また、条件設定と計算処理にかかるプログラムを分離して構成することにより、各プログラムのメンテナンス性を高めることができる。
(40)この発明にかかるデータ管理装置において、
データ処理手段は、条件設定部および計算処理部の組合せを、計算処理単位ごとに備えていることを特徴としている。
したがって、各計算処理の内容変更に迅速に対応することができ、メンテナンス性を高めることができる。
(41)この発明にかかるデータ管理装置において、
取り扱う可能性のあるすべてのデータを包含した処理データ格納部をさらに備えており、
データ処理手段における条件設定部は、前記処理データ格納部に対してデータの入出力を行うことを特徴としている。
したがって、各プログラムごとに共通のインターフェイスを使用することができる。これにより、インターフェースの設計工数を削減して、システムの開発コストを抑えることができる。
(42)この発明にかかるデータ管理装置において、
処理データ格納部は、トランザクションデータ、画面入力データおよび計算結果データから構成されることを特徴としている。
したがって、各プログラムにおいて、インターフェイスを統一しつつ、データ処理における処理状態を把握することができる。
(43)(44)(58)この発明にかかるデータ管理装置は、
管理対象となる契約条件が約款によってそれぞれ異なる保険契約データを管理するための保険契約データ管理装置であって、
少なくとも、保険契約を特定するための証券ＩＤ、前記保険契約における約款を特定するための約款ＩＤおよび前記約款における契約内容を特定するための契約内容ＩＤを含むデータ記録部と、
契約条件ごとに、契約内容ＩＤに対応する契約内容を記録したデータ定義部と、
前記データ記録部に記録された契約内容ＩＤと一致する、前記データ定義部に記録された契約内容ＩＤに基づいて、前記証券ＩＤによって特定される保険契約データにおける、所定の契約条件に対応する契約内容を決定する処理を行うデータ処理手段と、
を備えたことを特徴としている。
したがって、管理対象となる契約条件における契約内容を契約内容ＩＤによって記録することができる。このため、契約条件が異なるデータであっても同一フォーマットを用いて一元的に管理することができ、システム構成を簡単にすることができる。
(45)この発明にかかるデータ構造は、
管理対象となるデータ項目がそれぞれ異なるデータを管理するためのデータ構造であって、
少なくとも、データを識別するためのデータＩＤ、前記データＩＤによって特定されるデータ内容の種類を示す種類ＩＤおよび前記種類ＩＤにかかるデータ項目のデータ内容に対応するデータ内容ＩＤを含むデータ記録部と、
データ項目ごとに、データ内容ＩＤに対応するデータ内容を記録したデータ定義部と、
を備えたことを特徴としている。
したがって、管理対象となるデータ項目におけるデータ内容をデータ内容ＩＤによって記録することができる。このため、データ項目が異なるデータであっても同一フォーマットを用いて一元的に管理することができ、システム構成を簡単にすることができる。
(46)この発明にかかるデータ構造において、データ定義部は、種類ＩＤごとに、管理対象としているデータ項目を記録していることを特徴としている。したがって、記録したデータのデータ内容ＩＤに対応するデータ項目を容易に特定することができる。
(47)この発明にかかるデータ構造において、データ記録部は、データＩＤおよび種類ＩＤの組合せごとに、複数のデータ内容ＩＤを、各組合せに共通な複数のデータ項目番号にそれぞれ対応させて記録しており、データ定義部は、前記種類ＩＤごとに、複数のデータ項目番号にそれぞれ対応するデータ項目を記録したことを特徴としている。したがって、複数のデータ項目にかかるデータ内容を管理することができる。
(48)この発明にかかるデータ構造は、
管理対象となる契約条件が約款によってそれぞれ異なる保険契約を管理するためのデータ構造であって、
少なくとも、保険契約を特定するための証券ＩＤ、前記保険契約における約款を特定するための約款ＩＤおよび前記約款における契約内容を特定するための契約内容ＩＤを含むデータ記録部と、
約款ＩＤごとかつ契約条件ごとに、契約内容ＩＤに対応する契約内容を記録したデータ定義部と、
を備えたことを特徴としている。
したがって、管理対象となる契約条件における契約内容を契約内容ＩＤによって記録することができる。このため、契約条件が異なるデータであっても同一フォーマットを用いて一元的に管理することができ、システム構成を簡単にすることができる。
(49)この発明にかかるデータ構造において、データ記録部は、証券ＩＤおよび約款ＩＤの組合せごとに、複数の契約内容ＩＤを、各組合せに共通な複数の契約条件番号にそれぞれ対応させて記録しており、データ定義部は、前記約款ＩＤごとに、複数の契約条件番号にそれぞれ対応する契約条件を記録したことを特徴としている。したがって、複数の契約条件にかかる契約内容を管理することができる。
(50)(51)(59)この発明にかかるプログラム生成装置は、
指定データに対しての指定処理を行うプログラムを生成するプログラム生成装置であって、
データ項目ごとに、データ内容ＩＤとデータ内容の対応表を記録したデータ定義部と、
処理に対する処理コードを記録した処理定義部と、
指定データに含まれる種類ＩＤおよび指定処理の内容によって特定されるデータ項目についての対応表を、前記データ定義部から取得する対応表取得手段と、
前記指定処理に関する処理コードを、前記処理定義部から取得する処理コード取得手段と、
取得した前記対応表および取得した前記処理コードに基づいてプログラムを生成するプログラム生成手段と、
を備えたことを特徴としている。
したがって、種類ＩＤごとに設定された、処理に対する処理コードおよびデータ内容ＩＤとデータ内容の対応表に基づいて、選択的にデータ内容ＩＤまたはデータ内容を決定するためのプログラムを生成することができる。これにより、データ項目に関する情報とデータ処理を分けて構成することができる。
(52)(53)この発明にかかるプログラム生成装置において、
指定データに含まれる種類ＩＤは、管理対象となるデータ項目が種類ＩＤによってそれぞれ異なるデータを管理するデータ記録部であって、少なくとも、データを識別するためのデータＩＤ、前記データＩＤによって特定される種類ＩＤおよび前記種類ＩＤにおけるデータ内容を特定するためのデータ内容ＩＤを含むデータ記録部から抽出されたものであることを特徴としている。
したがって、管理対象となるデータ項目におけるデータ内容をデータ内容ＩＤによって記録しておくとともに、当該データ内容ＩＤに関するデータ内容を決定するプログラムを提供することができる。このため、データ項目が異なるデータであっても同一フォーマットを用いて一元的に管理しておくことができ、システム構成を簡単にすることができる。
(54)(55)この発明にかかる画面生成装置は、
所定の種類ＩＤにかかる指定処理を行うための表示画面を生成する画面生成装置であって、
データ項目ごとに、データ内容ＩＤとデータ内容の対応表を記録したデータ定義部と、
処理に対する処理コードを記録した処理定義部と、
指定データに含まれる種類ＩＤおよび指定処理の内容によって特定されるデータ項目についての対応表を、前記データ定義部から取得する対応表取得手段と、
前記指定処理に関する処理コードを、前記処理定義部から取得する処理コード取得手段と、
取得した前記対応表および取得した前記処理コードに基づいてプログラムを生成するプログラム生成手段とを備え、
前記データ処理手段は、前記データ定義部が所定の種類ＩＤについて記録しているすべてのデータ項目におけるすべてのデータ内容ＩＤおよびデータ内容の組合せを取得し、取得した前記データ内容ＩＤおよびデータ内容の組合せに基づいて、前記所定の種類ＩＤにかかる各データ項目について選択可能なデータ内容ＩＤまたはデータ内容を出力することによって表示画面を生成することを特徴としている。
したがって、契約ごとの商品特性・約定内容に応じた画面に応じた画面を自動的に生成することができる。これにより、商品ごとに画面を作成しておく必要がなくなり、ソフトウェアの開発コストを抑えることができる。また、パッケージソフトの分野においては、導入時のカスタマイズコストおよび変更時のメンテナンスコストを抑えることができる。
(56)この発明にかかる画面生成装置においては、
データ項目ごとに、データ内容ＩＤまたはデータ内容についての表示形式を記録した表示形式定義部またはこれにアクセスする手段をさらに備え、
データ処理手段は、前記表示形式定義部から取得した表示形式に基づいて、選択可能なデータ内容ＩＤまたはデータ内容を出力することを特徴としている。
したがって、データの表示形式を任意の条件で指定することができる。これにより、企業やユーザの利用環境や趣向に応じて変更ができる柔軟性の高い画面設計が実現可能となる。
［実施形態との対応］：
「少なくとも、データＩＤ、種類ＩＤおよびデータ内容ＩＤを含むデータ記録部」は、実施形態においては、証券番号、約款ＩＤおよび変数１、変数２、…等を記録したトランザクションデータベース２０９３がこれに該当する。「データ項目ごとに、データ内容ＩＤに対応するデータ内容を記録したデータ定義部」は、実施形態においては、契約条件ごとに、契約内容ＩＤに対応する契約内容を記録した、処理コード記録部、組合せデータ記録部またはこれらの組合せがこれに該当する。
「データ記録部に記録されたデータ内容ＩＤと一致する、データ定義部に記録されたデータ内容ＩＤに基づいて、前記データＩＤによって特定されるデータの種類を示す種類ＩＤの所定のデータ項目に対応するデータ内容を決定する処理を行うデータ処理手段」は、第１および第３の実施形態における処理プログラム要求・実行部７１３、第２の実施形態における処理プログラム実行部９３１ｂまたは処理プログラム要求・実行部９３１、第４の実施形態における処理プログラム要求・実行部２１３１、第５の実施形態における処理プログラム実行部３３２３、第６の実施形態における処理プログラム生成・実行部３９２７、第７の実施形態における処理プログラム生成・実行部４６２７、第８の実施形態における処理プログラム要求・実行部５３２７、第９の実施形態における処理プログラム要求・実行部６４２３等がこれに該当する。
「管理対象としているデータ項目」または「種類ＩＤに対応するデータ項目」は、実施形態においては、約款ＩＤごとに定義体プログラムに記録された、変数１、変数２、…等に対応する契約条件がこれに該当する。「各組合せに共通な複数のデータ項目番号」は、実施形態においては、変数１、２、…等における「１」、「２」、…がこれに該当する。
データ処理手段が取得する、「データ定義部がデータ項目番号に対応するデータ項目について記録しているすべてのデータ内容ＩＤおよびデータ内容の組合せ」は、実施形態においては、組合せデータ記録部において契約条件について記録しているすべての契約内容ＩＤおよび契約内容の組合せ」がこれに該当する。「データ内容ＩＤおよびデータ内容の組合せ」は、実施形態においては、組合せデータ記録部において契約条件ごとに記録した契約内容ＩＤおよび契約内容の組合せがこれに該当する。
「データ内容ＩＤまたはデータ内容を取り扱う処理を行うための処理コード」は、実施形態においては、処理名ごとに契約条件にかかる処理を行うための処理コード記録部に記録された処理コードがこれに該当する。「２種類以上のデータ項目にそれぞれ対応するデータ内容の組合せをチェックするための処理コード」は、実施形態においては、相関チェックの処理コード１７０５およびチェックデータ１７０６がこれに該当する。
「メイン処理部、処理プログラム要求・実行部、処理プログラム生成部」は、実施形態においては、例えば図７に示す、業務プログラム２０９１のメイン処理部７１１、処理プログラム要求・実行部７１３および商品定義体プログラム２０９４の処理プログラム生成部７３１がこれに該当する。所定の種類ＩＤにかかる各データ項目について選択可能なデータ内容ＩＤまたはデータ内容」は、実施形態においては、例えば図６８に示す、年金種類のドロップダウンメニューの選択可能データである「確定年金」または「保証期間付終身年金」等がこれに該当する。
「種類ＩＤにかかるすべてのデータ項目について選択可能なデータ内容ＩＤまたはデータ内容を取得する処理を行うための処理コード」は、実施形態においては、例えば図６４に示す、処理コード記録部における処理名「データ項目取得」にかかる処理コードがこれに該当する。「データ内容ＩＤまたはデータ内容についての表示形式を記録した表示形式定義部」は、実施形態においては、例えば図６４に示す、契約条件についての表示形式を記録した表示形式テーブルがこれに該当する。「処理コードを種類ＩＤに基づく階層に分けて記録している」とは、実施形態においては、例えば図１１に示す、第１階層「商品カテゴリー」、第２階層「約款種類」および第３階層「約款バージョン」に分散して記録されている処理コード記録部がこれに該当する。
「複数の種類ＩＤを組合せたグループごとに、所定データの設定条件を記録したグループ定義部」は、実施形態においては、例えば図２２に示す、契約リバンドル定義体プログラム２０９５に記録した処理コード記録部、チェックデータ記録部またはこれらの組合せがこれに該当する。「グループ定義部に記録された所定データの設定条件」は、実施形態においては、例えば図２２に示す処理コード「年金種類−支払期間の契約リバンドルチェック」およびチェックデータ「年金種類−支払期間の契約リバンドルチェックデータ」がこれに該当する。
「データ記録部に記録されようとしているデータ値が記録可能であるか否かを判断する処理」とは、実施形態においては、例えば図２２ａに示した、「最低保険料チェック」にかかる処理がこれに該当する。「グループにかかる名称」は、実施形態においては、例えば図２２ｂに示す、「保険名称（Ａ年金）」にかかる処理がこれに該当する。「データＩＤに基づく固有データ値」は、実施形態においては、例えば図３５に示す、ワークレコードの契約年月日３５９がこれに該当する。
「固有データ値の設定方法を記述した処理コード」は、実施形態においては、例えば図３７に示す、処理コード「契約年月日計算」がこれに該当する。「データ記録部に記録されようとしている第１の種類ＩＤ」は、実施形態においては、例えば図３３に示す、約款ＩＤ「５５５５５」がこれに該当する。「第１の種類ＩＤに関連する第２の種類ＩＤ」は、実施形態においては、例えば図３３に示す、約款ＩＤ「００００５」がこれに該当する。
「所定のデータ項目に対応するデータ項目ＩＤ」は、実施形態においては、例えば図４０に示す、パターン変数１＿６３１、パターン変数２＿６３３、…等がこれに該当する。「データ項目ＩＤとデータ内容ＩＤの組合せ」は、実施形態においては、例えば図３９に示す、パターン変数記録部に記録された「パターン変数」と「変数」の組合せデータがこれに該当する。「データ項目およびこれに対応するデータ内容を決定する処理」は、実施形態においては、例えば図３９に示す、処理コード記録部に記録された処理コード「保全要注意区分設定」３９２８ａに基づく処理がこれに該当する。
「データＩＤによって特定されるデータの属性を示す属性ＩＤ」は、実施形態においては、例えば図４０に示す、企業ＩＤ６３０がこれに該当する。データ記録部が記録する「所定のデータ項目に対応するデータ項目ＩＤとデータ内容の組合せ」とは、実施形態においては、例えば図４７に示す、パターン変数１＿６５１「００２」と変数１＿６５２「２００５／０９／０１」の組合せがこれに該当する。
データ定義部が記録する「データ項目ＩＤとデータ項目の組合せ」とは、実施形態においては、例えば図４６に示す、パターン変数データ記録部に記録されたパターン変数「００２」およびパターン変数名「利率基準日」がこれに該当する。「データ内容におけるデータ型ごとに記録する」とは、実施形態においては、７−５に示したように、データ形式ごとにパターン変数のカラムインデックスを設定することがこれに該当する。
「計算処理部において使用する計算条件を設定するための条件設定部」は、実施形態においては、例えば図５３に示す、業務プログラム５３０１にかかるＩ／Ｆ編集クラス５３２３がこれに該当する。「計算条件に基づいて所定の計算処理を行うための計算処理部」は、実施形態においては、例えば図５３に示す、業務プログラム５３０１にかかる計算モデル５３２５がこれに該当する。「計算処理単位」における「計算処理」とは、実施形態においては、例えば図５３に示す、「源泉徴収税額計算」または「円転計算」等がこれに該当する。「取り扱う可能性のあるすべてのデータを包含した処理データ格納部」とは、実施形態においては、例えば図５３に示す、ワーク領域５３０７がこれに該当する。
「データ項目ごとに、データ内容ＩＤとデータ内容の対応表を記録したデータ定義部」は、実施形態においては、例えば図７に示す、契約条件ごとに、契約内容ＩＤに対応する契約内容を記録した組合せデータ記録部７３５がこれに該当する。「処理に対する処理コードを記録した処理定義部」実施形態においては、例えば図７に示す、契約条件ごとに、処理コードを記録した処理コード記録部７３３がこれに該当する。
「指定データに含まれる種類ＩＤおよび指定処理の内容によって特定されるデータ項目についての対応表を、前記データ定義部から取得する対応表取得手段」は、実施形態においては、例えば図１３に示す、ステップＳ１３２３の機能がこれに該当する。「指定処理に関する処理コードを、前記処理定義部から取得する処理コード取得手段」は、実施形態においては、例えば図１３に示す、ステップＳ１３２１の機能がこれに該当する。「取得した対応表および取得した処理コードに基づいてプログラムを生成するプログラム生成手段」は、実施形態においては、例えば図１３に示す、ステップＳ１３２５の機能がこれに該当する。
この発明において、「〜手段」とは、プログラムによって実現されるＣＰＵの機能を含む概念である。ここで、「プログラム」とは、ＣＰＵにより直接実行可能なプログラムだけでなく、ソース形式のプログラム、圧縮処理がされたプログラム、暗号化されたプログラム等を含む概念である。
本発明の特徴は、上記のように広く示すことができるが、その構成や内容は、それらの特徴および効果とともに、図面を考慮に入れた上で以下の開示によりさらに明らかになるであろう。
この発明のデータ管理装置の機能ブロック図の例を示す図である。 この発明のデータ管理装置の機能ブロック図の例を示す図である。 この発明のデータ管理装置のハードウェア構成図の例を示す図である。 この発明のデータ管理装置のハードウェア構成図の例を示す図である。 この発明の業務プログラムと商品定義体プログラムにおけるフローチャートの例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明の年金種類設定画面の例を示す図である。 この発明のトランザクションデータベースの例を示す図である。 この発明の業務プログラムと商品定義体プログラムにおける機能ブロック図の例を示す図である。 この発明の業務プログラムと商品定義体プログラムにおける機能ブロック図の例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の業務プログラムとラッパープログラムと商品定義体プログラムにおける機能ブロック図の例を示す図である。 この発明の業務プログラムとラッパープログラムと商品定義体プログラムにおける機能ブロック図の例を示す図である。 この発明の業務プログラムとラッパープログラムと商品定義体プログラムにおけるフローチャートの例を示す図である。 この発明の業務プログラムとラッパープログラムと商品定義体プログラムにおけるフローチャートの例を示す図である。 この発明の商品定義体プログラムにおける機能ブロック図の例を示す図である。 この発明の他業界ヘの適用の例を示す図である。 この発明の業務プログラムと商品定義体プログラムにおけるフローチャートの例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明の年金種類設定画面の例を示す図である。 この発明のトランザクションデータベースの例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の従来技術（１）を示す図である。 この発明の従来技術（２）を示す図である。 この発明のデータ管理装置の機能ブロック図の例を示す図である。 この発明のデータ管理装置のハードウェア構成図の例を示す図である。 この発明の業務プログラム、ラッパープログラムＡ、契約リバンドル定義体プログラム、ラッパープログラムＢおよび約款定義体プログラムにおける機能ブロック図の例を示す図である。 この発明の業務プログラム、ラッパープログラムＡおよび契約リバンドル定義体プログラムにおける機能ブロック図の例を示す図である。 この発明の業務プログラム、ラッパープログラムＡおよび契約リバンドル定義体プログラムにおける機能ブロック図の例を示す図である。 この発明の業務プログラム、ラッパープログラムＢおよび約款定義体プログラムにおけるフローチャートの例を示す図である。 この発明の業務プログラムにおけるフローチャートの例を示す図である。 この発明の業務プログラムにおけるフローチャートの例を示す図である。 この発明の契約リバンドルチェック処理におけるフローチャートの例を示す図である。 この発明の契約リバンドルチェック処理におけるフローチャートの例を示す図である。 この発明の契約リバンドルチェック処理におけるフローチャートの例を示す図である。 この発明の契約内容取得処理におけるフローチャートの例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明のトランザクションデータベースの例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の保険金額変更画面の例を示す図である。 この発明のトランザクションデータベースの例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の業務プログラム、ラッパープログラムＡ、約款定義体プログラム（特約約款）、ラッパープログラムＢおよび約款定義体プログラム（主契約約款）における機能ブロック図の例を示す図である。 この発明のワークレコードの例を示す図である。 この発明の保険契約変更画面の例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明の業務プログラム、ラッパープログラム、処理ステータス定義体プログラムにおける機能ブロック図の例を示す図である。 この発明のワークレコードの例を示す図である。 この発明の業務プログラムにおけるフローチャートの例を示す図である。 この発明の業務プログラムにおけるフローチャートの例を示す図である。 この発明のパターン変数設定処理におけるフローチャートの例を示す図である。 この発明のパターン変数取得処理におけるフローチャートの例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明の保全要注意区分設定画面の例を示す図である。 この発明の保険契約解約画面の例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の業務プログラム、ラッパープログラム、データ項目定義体プログラムにおける機能ブロック図の例を示す図である。 この発明のワークレコードの例を示す図である。 この発明の業務プログラムにおけるフローチャートの例を示す図である。 この発明のパターン変数名取得処理におけるフローチャートの例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明の解約返戻金計算画面の例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の業務プログラム、ラッパープログラム、約款定義体プログラムおよびワーク領域における機能ブロック図の例を示す図である。 この発明の業務プログラムにおけるフローチャートの例を示す図である。 この発明の業務プログラムにおけるフローチャートの例を示す図である。 この発明の業務プログラムにおけるフローチャートの例を示す図である。 この発明の源泉徴収税額計算処理におけるフローチャートの例を示す図である。 この発明の源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）におけるフローチャートの例を示す図である。 この発明の源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）におけるフローチャートの例を示す図である。 この発明の源泉徴収税額計算処理（計算モデル）におけるフローチャートの例を示す図である。 この発明のワーク領域の例を示す図である。 この発明のワーク領域の例を示す図である。 この発明の解約返戻金計算画面の例を示す図である。 この発明の解約返戻金計算画面の例を示す図である。 この発明の外貨年金解約返戻金計算画面の例を示す図である。 この発明の円転計算処理におけるフローチャートの例を示す図である。 この発明の円転計算処理（Ｉ／Ｆ編集クラス）におけるフローチャートの例を示す図である。 この発明の円転計算処理（計算モデル）におけるフローチャートの例を示す図である。 この発明の業務プログラム、ラッパープログラムＡならびにＢ、約款定義体プログラムおよび表示形式テーブルにおける機能ブロック図の例を示す図である。 この発明の業務プログラム、ラッパープログラムＡおよび約款定義体プログラムにおけるフローチャートの例を示す図である。 この発明の業務プログラムおよびラッパープログラムＢにおけるフローチャートの例を示す図である。 この発明の処理プログラムにおけるフローチャートの例を示す図である。 この発明の個別修正画面の例を示す図である。 この発明の個別修正画面の例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の処理プログラムにおける構成例を示す図である。 この発明の関係テーブルの作成の例を示す図である。 この発明のワークレコードの例を示す図である。 この発明のＵＩ画面生成処理におけるフローチャートの例を示す図である。
１３ データ記録部
１５ データ処理手段
１７ データ定義部
１８ グループ定義部
以下、本発明における実施形態について、図面を参照して説明する。
１．第１の実施形態
本実施形態においては、生命保険の契約管理に関するトランザクションデータおよび生命保険商品に関する商品定義データを管理するデータ管理装置の例について説明する。
１−１．機能ブロック図
図１に、本発明にかかるデータ管理装置１の機能ブロック図を示す。この図において、データ管理装置１は、入力手段１１、データ記録部１３、データ処理手段１５、データ定義部１７および表示手段１９を備えている。データ記録部１３はトランザクションデータを記録する。データ定義部１７は、商品の種類を示す種類ＩＤごとに、データ内容ＩＤおよびデータ内容を記録する。例えば、保険商品の場合には、保険商品の種類を示す約款ＩＤごとに、契約内容ＩＤおよび契約内容とを記録する。データ処理手段１５は、データ記録部１３に記録された種類ＩＤ（約款ＩＤ）に基づいて、データ定義部１７からデータ内容ＩＤ（契約内容ＩＤ）およびデータ内容（契約内容）を取得してデータ内容（契約内容）に関する処理を実行する。
なお、入力手段１１は、ユーザからの操作を受け付けて業務プログラムのデータ内容（契約内容）に関する処理を起動させるものであり、表示手段１９は、業務プログラムによって所定のデータ処理を行った結果をユーザに提示するものである。
１−２．ハードウェア構成
図１に示したデータ管理装置１を、ＣＰＵを用いて実現したコンピュータ装置のハードウェア構成の一例を図２に示す。図２に示すように、データ管理装置１は、ディスプレイ２０１、ＣＰＵ２０３、メモリ２０５、キーボード／マウス２０７、ハードディスク２０９、ＣＤ−ＲＯＭドライブ２１１および通信回路２１５を備えている。
ハードディスク２０９は、業務アプリケーションプログラム（以下、業務プログラムと呼称する。）２０９１、トランザクションデータベース２０９３および商品定義体プログラム２０９４を記録している。業務プログラム２０９１は、ＣＤ−ＲＯＭドライブ２１１を介してＣＤ−ＲＯＭ２１２に記録されたデータを読み出してインストールされたものである。なお、上記インストールは、通信回路２１５を用いてネットワーク０等からダウンロードしたデータを使用して行うようにしてもよい。
データ記録部１３はトランザクションデータベース２０９３によって実現され、データ処理手段１５はＣＰＵ２０３がメモリ２０５を用いて実行する業務プログラム２０９１によって実現され、データ定義部１７はＣＰＵ２０３がメモリ２０５を用いて実行する商品定義体２０９４プログラムによって実現される。なお、入力手段１１は主にキーボード／マウス２０７によって実現され、表示手段１９は主にディスプレイ２０１によって実現される。
１−３．処理詳細
図３〜８を用いて、本実施形態における処理の詳細を説明する。なお、本実施形態において、業務プログラム２０９１は、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。図７に、業務プログラム２０９１および商品定義体プログラム２０９４における機能ブロック図を示す。業務プログラム２０９１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部７１１と、商品定義体プログラム２０９４に処理プログラムを要求してこれを実行するための処理プログラム要求・実行部７１３から構成される。
また、商品定義体プログラム２０９４は、業務プログラム２０９１からの要求を受けて処理プログラムを生成するための処理プログラム生成部７３１と、処理名ごとに処理コードを記録した処理コード記録部７３３と、処理名ごとに契約内容ＩＤおよび契約内容の組合せデータを記録した組合せデータ記録部７３５から構成される（例えば、約款ＩＤが「１１１１１」の場合。）。
本実施形態においては、証券番号によって特定されるトランザクションデータにおける年金種類を、「確定年金」から「保証期間付終身年金」に変更する指示をユーザが行う場合について説明する。図３は、上記の場合においてデータ管理装置１で実行される業務プログラム２０９１および商品定義体プログラム２０９４のフローチャートの例である。
１−３−１．画面データの取得
図５に、業務プログラム２０９１におけるメイン処理部７１１の実行によってディスプレイ２０１に表示される年金種類設定画面５０１の例を示す。この画面においては、証券番号の入力欄５０３、年金種類の設定用のラジオボタン５０４および５０５が表示されており、データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、年金種類の変更を指示することができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄５０３に「００００１」を入力し、保証期間付終身年金のラジオボタン５０５を選択して、設定ボタン５０７を押下することによって、データ管理装置１に対して年金種類の変更を指示する。
設定ボタン５０７の押下を受けて、メイン処理部７１１を実行するＣＰＵ２０３は画面データを取得する（ステップＳ３０１）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００１」および年金種類「保証期間付終身年金」を取得する。
１−３−２．レコードの取得
メイン処理部７１１を実行するＣＰＵ２０３は、画面データとして入力された証券番号に基づいてトランザクションデータベース２０９３にアクセスして検索し、当該証券番号によって特定されるトランザクションレコードをメモリ２０５に作成されたワーク領域に取得する（ステップＳ３０３）。
図６にトランザクションデータベース２０９３の例を示す。このデータベースには、生命保険の契約管理に関するトランザクションデータとして、証券番号６０１、約款ＩＤ６０３、変数１＿６０５、変数２＿６０７、変数３＿６０９…等が記録されている。なお、上記ワーク領域のレコードフォーマットは、トランザクションデータベースのレコードフォーマットと同一である。ここで、証券番号６０１はトランザクションレコードを特定するためのデータＩＤであり、約款ＩＤ６０３は保険商品を特定するための識別ＩＤであり、変数１＿６０５、変数２＿６０７、変数３＿６０９…はそれぞれの契約内容を特定するための契約内容ＩＤである。
例えば、ＣＰＵ２０３は、証券番号「００００１」によって特定されるトランザクションレコード６１をトランザクションデータベース２０９３から取得する。
１−３−３．処理プログラムの要求
処理プログラム要求・実行部７１３を実行するＣＰＵ２０３は、メイン処理部７１１の実行において取得したトランザクションレコードに記録されている約款ＩＤに基づいて、商品定義体プログラム２０９４を特定し、処理名をアクセスした当該商品定義体プログラムに引き渡す（ステップＳ３０５）。
例えば、商品定義体プログラム２０９４をＪａｖａ（商標）言語で作成している場合には、約款ＩＤ（１１１１１）と同一名称で記録されたクラスファイル（１１１１１．ｃｌａｓｓ）等によって商品定義体プログラム２０９４を特定すればよい。なお、約款ＩＤと商品定義体プログラム２０９４の対応表を用いて商品定義体プログラムを特定するように構成してもよい。
また、商品定義体プログラム２０９４に引き渡される処理名は、オペレータからの指示に基づいて決定する。例えば、上記においては、年金種類設定画面において年金種類を設定する指示がなされているため、ＣＰＵ２０３はメイン処理部７１１の実行によって取得した処理名である「年金種類設定」を引き渡す。
１−３−４．処理データおよび組合せデータの取得
以下、約款ＩＤが「１１１１１」の商品定義体プログラム２０９４に処理コードを引き渡した場合について説明する。引き渡しを受けてＣＰＵ２０３は、商品定義体プログラム２０９４の処理プログラム生成部７３１を実行し、処理コード記録部７３３を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ３２１）。処理コード記録部７３３には、処理名ごとに処理コードが記録されている。例えば、ＣＰＵ２０３は処理名が「年金種類設定」の処理コード７３３１をサーチ処理等により取得する。
ＣＰＵ２０３は、組合せデータ記録部を検索して受け継いだ処理名に対応した契約内容および契約内容ＩＤの組合せデータを取得する（ステップＳ３２３）。組合せデータ記録部７３５には、契約条件（データ項目）ごとに組合せデータが記録されている。例えば、ＣＰＵ２０３は契約条件が「年金種類」である組合せデータ７３５１を取得する。
なお、図７ａに示すように、処理プログラム生成部７３１の機能の一部を処理コード記録部７３３に設けておき、処理コード記録部７３３から組合せデータ記録部７３５を検索し、処理名に対応した契約内容および契約内容ＩＤの組合せデータを取得するように構成してもよい。
１−３−５．処理プログラムの生成
ＣＰＵ２０３は、処理コード記録部から取得した処理コードと、組合せデータ記録部から取得した組合せデータに基づいて処理プログラムを生成する（ステップＳ３２５）。図８に、生成した処理プログラムの構成例を示す。処理プログラム８０は、処理コード８０１および組合せデータ８０３から構成されている。例えば、処理コード８０１には、「年金種類設定」を処理するためのプログラムコードが記述されている。なお、このプログラムコードの表現形式は、ソースコードまたはオブジェクトコードのいずれであってもよい。
また、組合せデータ８０３には、「年金種類設定」を処理するためのプログラムコードが使用する契約内容ＩＤおよび契約内容の組合せデータが記述されている。なお、この組合せデータの表現形式は、契約内容ＩＤに対応する契約内容が上記プログラムコードの実行時において判断できるものであればよい。例えば、配列形式やテーブル形式等の表現形式がこれに該当する。
１−３−６．処理プログラムの引き渡し
商品定義体プログラム２０９４を実行するＣＰＵ２０３は、生成した処理プログラム８０を業務プログラム２０９１に引き渡す（ステップＳ３２７）。例えば、ＣＰＵ２０３は、リダイレクト機能やパイプ機能等を用いて処理プログラム８０を引き渡す処理を行う。
１−３−７．処理プログラムの実行
業務プログラム２０９１においてＣＰＵ２０３は、商品定義体プログラム２０９４から受け継いだ処理プログラム８０を実行し、画面データから取得した契約内容に対応する契約内容ＩＤを取得する（ステップＳ３０７）。このとき実行される処理プログラム８０のフローチャートを図４に示す。処理プログラム８０の実行においてＣＰＵ２０３は、業務プログラム２０９１のフローチャートステップＳ３０１において取得した画面データから契約内容を入力する（ステップＳ４０１）。例えば、契約内容として「保証期間付終身年金」を入力する。
ＣＰＵ２０３は、処理プログラム８０に格納されている組合せデータ８０３から、契約内容ＩＤおよび契約内容の組合せデータを１件読み込む（ステップＳ４０３）。例えば、図８に示した処理プログラム８０の組合せデータから、契約内容ＩＤ「０１」および契約内容「確定年金」の組合せデータ８０３１を読み込む。
ＣＰＵ２０３は、入力した契約内容と、読み込んだ組合せデータにおける契約内容が一致するか否かを判断する（ステップＳ４０５）。例えば、入力した契約内容「保証期間付終身年金」と、最初に読み込んだ組合せデータにおける契約内容「確定年金」が一致するか否かを判断する。
ステップＳ４０５において、契約内容が一致しなければステップＳ４０３に戻って次の組合せデータを読み込み、ステップＳ４０５を再実行する（ステップＳ４０５、ＮＯ）。一致していれば、ステップＳ４０７に進み、組合せデータの契約内容に対応づけて記録されている契約内容ＩＤを取得する（ステップＳ４０７）。例えば、契約内容「保証期間付終身年金」は、２番目に読み込んだ組合せデータ８０３２（契約内容ＩＤ「０２」と契約内容「保証期間付終身年金」）の契約内容と一致するので、これに対応する契約内容ＩＤ「０２」を取得する。
ＣＰＵ２０３は、取得した契約内容ＩＤを、トランザクションレコードから取得したワーク領域の所定の変数位置に記録する（ステップＳ４０９）。例えば、年金種類の変数位置を示すワーク領域の変数１に契約内容「０２」を記録する。ここで、契約内容を記録する対象となる変数位置の情報は、処理プログラムの元となる処理コード内に予め設定されている。
なお、変数位置を処理コード以外に設定してもよい。例えば、上記組合せデータや独立した変数位置データ等に設定しておき、生成時において処理プログラムに組み込むように構成してもよい。
なお、処理プログラムをＪａｖａ（商標）で作成している場合には、契約内容ＩＤおよび契約内容の組合せデータを、ＪａｖａＡＰＩにおけるＨａｓｈＭａｐクラスのＫｅｙおよびＶａｌｕｅにセットされるように処理プログラムを生成するように構成しておき、処理プログラム内でデータ取得メソッドを指定することによって契約内容等を取り扱うようにすればよい。
１−３−８．レコードの更新
処理プログラムの実行を終えると、ＣＰＵ２０３は、ワーク領域に記録されたデータに基づいてトランザクションデータベース２０９３のレコードを更新する（ステップＳ３０９）。例えば、図６に示すトランザクションレコード６１が、更新されてトランザクションレコード６５のようになる。図６に示すように、レコード６１の変数１「０１」が、レコード６５の変数１「０２」に更新されている。
１−４．まとめ
以上説明したように、この発明によれば、トランザクションデータにおける１つの項目を使用して、複数の契約条件にかかる契約内容を管理することができる。このため、トランザクションデータベースにおいて保険商品データにかかる契約条件ごとに契約内容を管理しなくても、所望の契約条件における契約内容を取得して、これにかかる処理を実行することができる。これにより、複数のデータ項目を有するデータを含むトランザクションデータを取り扱う場合であっても、フォーマットを一元化してシステム構成を簡単にすることができる。
また、商品の種類を示す種類ＩＤ（約款ＩＤ）に基づいて商品定義体プログラムを特定し、特定した商品定義体プログラム内において所定の処理コードと組合せデータを用いて生成した処理プログラムを用いてデータ処理を行うように構成することにより、商品に基づく特性を業務プログラムに記述する必要がなくなる。これにより、業務プログラムのメンテナンス性を向上させることができる。
さらに、新たな商品の追加があった場合であっても、これに対応する商品定義体プログラムを追加して、必要な処理コードおよび必要な組合せデータを設定するだけで対応することができる。これにより、システム開発者に多大の負担を強いることなく、システム変更に柔軟に対応することができる。
本発明は、商品データの内容に基づいて定まる判断ロジックと、当該判断ロジックを呼び出す業務プログラムとをそれぞれ独立して構成することにより、業務プログラムの汎用性を高めたソフトウェアを構成することができる。したがって、導入各社の業務体系にあわせてカスタマイズを行うようなパッケージソフトに対して本発明を適用した場合には、商品定義体プログラムにおける処理コードおよび組合せデータのみを、各社の業務に沿うように設計するだけでよい。これにより、業務プログラムのカスタマイズ作業を不要とし、開発コストや導入コストを低減させることができる。
２．第２の実施形態
第１の実施形態においては、図７に示したように、業務プログラム２０９１をメイン処理部７１１と処理プログラム要求・実行部７１３によって構成し、商品定義体プログラム２０９４を処理プログラム生成部７３１、処理コード記録部７３３および組合せデータ記録部７３５によって構成する例について説明したが、本実施形態においては、処理プログラム要求・実行部７１３における処理プログラムの要求にかかる処理を、業務プログラムから独立したラッパープログラムを用いて構成する例について説明する。なお、ラッパープログラムとは、外部からの要求に応じて、所定の処理を集中して実行するものである。
図９に、業務プログラム２０９１、ラッパープログラム２０９２および商品定義体プログラム２０９４における機能ブロック図を示す。業務プログラム２０９１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部９１１および処理プログラムを実行する処理プログラム実行部９３１ｂから構成される。ラッパープログラム２０９２は、商品定義体プログラム２０９４等に処理プログラムを要求するための処理プログラム要求部９３１ａから構成される。商品定義体プログラム２０９４は、要求を受けて処理プログラムを生成するための処理プログラム生成部９３３ａ、ｂ、ｃ、…等と、処理名ごとに処理コードを記録した処理コード記録部９５１と、処理名ごとに契約内容ＩＤおよび契約内容の組合せデータを記録した組合せデータ記録部９５２から構成される（例えば、約款ＩＤが「１１１１１」の場合。）。
本実施形態においても第１の実施形態と同様に、生命保険の契約管理に関するトランザクションデータおよび生命保険商品に関する商品定義データを管理するデータ管理装置の例について説明する。
２−１．機能ブロック図
本発明にかかるデータ管理装置１の機能ブロック図は、第１の実施形態の図１に示したものと同様である。
２−２．ハードウェア構成
本発明にかかるデータ管理装置１を、ＣＰＵを用いて実現したコンピュータ装置のハードウェア構成の一例は、基本的には第１の実施形態の図２に示したものと同様であるが、ハードディスク２０９にラッパープログラムが記録されている点が異なる。
２−３．処理詳細
図１０を用いて、本実施形態における処理の詳細を説明する。なお、本実施形態において、業務プログラム２０９１は、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。
本実施形態においても、第１の実施形態と同様に、証券番号によって特定されるトランザクションデータにおける年金種類を、「確定年金」から「保証期間付終身年金」に変更する指示をユーザが行う場合について説明する。図１０は、上記の場合においてデータ管理装置１で実行される業務プログラム２０９１、ラッパープログラム２０９２および商品定義体プログラム２０９４のフローチャートの例である。
２−３−１．画面データの取得
第１の実施形態と同様に、図５に示した年金種類設定画面５０１において、オペレータが証券番号の入力欄５０３に「００００１」を入力し、保証期間付終身年金のラジオボタン５０５を選択して、設定ボタン５０７を押下した場合について説明する。
設定ボタン５０７の押下を受けて、メイン処理部９１１を実行するＣＰＵ２０３は画面データを取得する（ステップＳ１００１）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００１」および年金種類「保証期間付終身年金」を取得する。
２−３−２．レコードの取得
メイン処理部９１１を実行するＣＰＵ２０３は、画面データとして入力された証券番号に基づいてトランザクションデータベース２０９３にアクセスして検索し、当該証券番号によって特定されるトランザクションレコードをメモリ２０５に作成されたワーク領域に取得する（ステップＳ１００３）。なお、トランザクションデータベース２０９３およびワーク領域の例は、第１の実施形態の図６に示したものと同様である。例えば、ＣＰＵ２０３は、証券番号「００００１」によって特定されるトランザクションレコード６１をトランザクションデータベース２０９３から取得する。
業務プログラム２０９１を実行するＣＰＵ２０３は、トランザクションレコード６１に記録されている約款ＩＤおよび、オペレータ指示に基づいて特定された処理名を、ラッパープログラム２０９２に引き渡す（ステップＳ１００５）。例えば、上記においては、年金種類設定画面において年金種類を設定する指示がなされているため、ＣＰＵ２０３はメイン処理部９１１の実行によって取得した処理名である「年金種類設定」を引き渡す。
なお、上記ステップＳ１００５において、トランザクションレコード６１の契約内容ＩＤである変数１、２、３…を、ラッパープログラム２０９２に同時に引き渡すように構成してもよい。これにより、ラッパープログラム２０９２または商品定義体プログラム２０９４において、契約内容ＩＤに基づく処理を行うことが可能となる。
２−３−３．ラッパープログラムの実行
ラッパープログラム２０９２を実行するＣＰＵ２０３は、処理プログラム要求部９３１ａにおいて、業務プログラム２０９１から受け継いだ約款ＩＤに基づいて商品定義体プログラムを特定し、特定した商品定義体プログラム２０９４にアクセスして処理名を引き渡す（ステップＳ１０２１）。
２−３−４．処理データおよび組合せデータの取得
引き渡しを受けてＣＰＵ２０３は、商品定義体プログラム２０９４の処理プログラム生成部９３３ａを実行し、受け継いだ処理名に対応する処理コードを処理コード記録部９５１から取得する（ステップＳ１０４１）。処理コード記録部９５１には、処理名ごとに処理コードが記録されている。例えば、ＣＰＵ２０３は処理名が「年金種類設定」の処理コードを取得する。
ＣＰＵ２０３は、受け継いだ処理名に対応する契約内容および契約内容ＩＤの組合せデータを組合せデータ記録部９５２から取得する（ステップ１０４３）。組合せデータ記録部９５２には、契約条件ごとに組合せデータが記録されている。例えば、ＣＰＵ２０３は契約条件が「年金種類」である組合せデータを取得する。
２−３−５．処理プログラムの生成・実行
商品定義体プログラム２０９４を実行するＣＰＵ２０３は、取得した処理コードおよび組合せデータに基づいて処理プログラムを生成する（ステップＳ１０４５）。生成した処理プログラムの例は、第１の実施形態の図８に示したものと同様である。
商品定義体プログラム２０９４を実行するＣＰＵ２０３は、生成した処理プログラム８０をラッパープログラム２０９２に引き渡す（ステップＳ１０４７）。これを受けて、ラッパープログラム２０９２を実行するＣＰＵ２０３は、さらに処理プログラムを業務プログラム２０９１に引き渡す（ステップＳ１０２３）。
業務プログラム２０９１を実行するＣＰＵ２０３は、受け継いだ処理プログラム８０を実行し、画面データから取得した契約内容に対応する契約内容ＩＤを取得する（ステップＳ１００７）。このとき実行される処理プログラム８０のフローチャートは、第１の実施形態の図４に示したものと同様である。
図４に示したように、例えば、契約内容「保証期間付終身年金」に対応する契約内容ＩＤ「０２」を取得し、取得した契約内容ＩＤをトランザクションレコードのワーク領域における変数１に記録する。
２−３−６．レコードの更新
処理プログラムの実行を終えると、ＣＰＵ２０３は、ワーク領域に記録されたデータに基づいてトランザクションデータベース２０９３のレコードを更新する（ステップＳ１００９）。例えば、第１の実施形態の図６に示したように、トランザクションレコード６１が、更新されてトランザクションレコード６５のようになる。図６に示すように、レコード６１の変数１「０１」が、レコード６５の変数１「０２」に更新されている。
２−４．まとめ
以上説明したように、この発明によれば、約款ＩＤに対応する商品定義体プログラムを決定し、所望の処理プログラムを要求するための処理を１つのプログラムに集約することができる。すなわち、商品定義体の特定処理と実行すべき処理プログラムの要求処理を、業務プログラムと独立した構成とすることができる。このため、ラッパープログラムをすべての指示に対して汎用的に使用することができる。これにより、業務プログラムにおいて、オペレータの指示ごとに、商品定義体の特定処理と処理プログラムの要求処理を行うプログラムを作成する必要がなくなり、システム構成を簡単にして業務プログラムのメンテナンス性を向上させることができる。
なお、図９ａに、ラッパープログラムを用いる場合における別の実施形態を示す。この実施形態においては、処理プログラム要求・実行部９３１と処理プログラム生成部９３３をラッパープログラムによって構成している。また、図１０ａは、上記の場合においてデータ管理装置１で実行される業務プログラム２０９１、ラッパープログラム２０９２および商品定義体プログラム２０９４のフローチャートの例である。業務プログラム２０９１における処理ステップＳ１００１〜Ｓ１００３、Ｓ１００９およびラッパープログラム２０９２における処理ステップＳ１０２１は、図１０に示したもの同様である。
図１０ａに示すステップＳ１００４において、業務プログラム２０９１を実行するＣＰＵ２０３は、トランザクションレコード６１に記録されている約款ＩＤ、オペレータ指示に基づいて特定された処理名および画面データから取得した契約内容を、ラッパープログラム２０９２に引き渡す。
ラッパープログラム２０９２を実行するＣＰＵ２０３は、処理プログラム要求・実行部９３１において、業務プログラム２０９１から受け継いだ約款ＩＤに基づいて商品定義体プログラム２０９４を特定し、特定した商品定義体プログラム２０９４の名称と、同時に受け継いだ処理名を処理プログラム生成部９３３に引き渡す。さらに、処理プログラム生成部９３３は、その名称を受け継いだ商品定義体プログラム２０９４に対して処理名を引き渡す（ステップＳ１０２１）。
引き渡しを受けてＣＰＵ２０３は、商品定義体プログラム２０９４を実行して処理コード記録部９５１から受け継いだ処理名に対応する処理コードを取得してラッパープログラム２０９２に引き渡す（ステップＳ１０５１）。処理コード記録部９５１には、処理名ごとに処理コードが記録されている。例えば、ＣＰＵ２０３は処理名が「年金種類設定」の処理コードを取得する。
ＣＰＵ２０３は、組合せデータ記録部から受け継いだ処理名に対応する契約内容および契約内容ＩＤの組合せデータを取得してラッパープログラム２０９２に引き渡す（ステップ１０５３）。組合せデータ記録部９５２には、契約条件ごとに組合せデータが記録されている。例えば、ＣＰＵ２０３は契約条件が「年金種類」である組合せデータを取得する。
ラッパープログラム２０９２を実行するＣＰＵ２０３は、商品定義体プログラム２０９４から受け継いだ処理コードおよび、組合せデータに基づいて処理プログラムを生成する（ステップＳ１０２２）。生成した処理プログラムの例は、第１の実施形態の図８に示したものと同様である。
ラッパープログラム２０９２を実行するＣＰＵ２０３は、処理プログラム生成部９３３において生成した処理プログラム８０を実行し、画面データから取得した契約内容に対応する契約内容ＩＤを取得する（ステップＳ１０２４）。このとき実行される処理プログラム８０のフローチャートは、第１の実施形態の図４に示したものと同様である。
図４に示したように、例えば、契約内容「保証期間付終身年金」に対応する契約内容ＩＤ「０２」を取得し、取得した契約内容ＩＤをトランザクションレコードのワーク領域における変数１に記録する。
以上説明したように、この発明によれば、契約内容ＩＤまたは契約内容を決定するための処理を１つのプログラムに集約することができる。すなわち、所定の指示を受けて実行すべき処理プログラムの生成処理と実行処理を行うプログラムを、業務プログラムと独立した構成とすることができる。このため、ラッパープログラムをすべての指示に対して汎用的に使用することができる。これにより、オペレータの指示ごとに、処理プログラムの生成処理と実行処理を行うプログラムを作成する必要がなくなり、システム構成を簡単にして業務プログラムのメンテナンス性を向上させることができる。
３．第３の実施形態
第１の実施形態においては、画面データに入力された１つの契約内容（データ内容）に対応する契約内容ＩＤ（データ内容ＩＤ）を取得した後、当該契約内容ＩＤをトランザクションに格納する例について説明したが、本実施形態においては、２以上の契約内容（データ内容）に対応する契約内容ＩＤを取得して、これらの契約内容ＩＤの組合せが正しいか否かをチェックする処理を行った後、当該２以上の契約内容ＩＤをトランザクションに格納する例について説明する。なお、本実施形態においても第１の実施形態と同様に、生命保険の契約管理に関するトランザクションデータおよび生命保険商品に関する商品定義データを管理するデータ管理装置の例について説明する。
３−１．機能ブロック図
本発明にかかるデータ管理装置１の機能ブロック図は、第１の実施形態の図１に示したものと同様である。
３−２．ハードウェア構成
本発明にかかるデータ管理装置１を、ＣＰＵを用いて実現したコンピュータ装置のハードウェア構成の一例は、基本的には第１の実施形態の図２に示したものと同様である。
３−３．処理詳細
図１３〜１７を用いて、本実施形態における処理の詳細を説明する。なお、業務プログラム２０９１および商品定義体プログラム２０９４における機能ブロック図は、第１の実施形態の図７に示したものと同様である。本実施形態においては、証券番号によって特定されるトランザクションデータにおける年金種類を、「確定年金」から「保証期間付終身年金」に、年金支払期間を「５年」から「終身」に、それぞれ変更する指示をユーザが行う場合について説明する。図１３は、上記の場合においてデータ管理装置１で実行される業務プログラム２０９１および商品定義体プログラム２０９４のフローチャートの例である。
３−３−１．画面データの取得
図１５に、業務プログラム２０９１におけるメイン処理部７１１（図７）の実行によってディスプレイ２０１に表示される年金種類設定画面１５０１の例を示す。この画面においては、証券番号の入力欄１５０３、年金種類の設定用のラジオボタン１５０４および１５０５、年金支払期間の設定用のラジオボタン１５０６等が表示されており、データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、年金種類および年金支払期間の変更を指示することができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄１５０３に「００００１」を入力し、年金種類に「保証期間付終身年金」を設定するためのラジオボタン１５０５および年金支払期間に「終身」を設定するためのラジオボタン１５０６を選択して、設定ボタン１５０７を押下することによって、データ管理装置１に対して年金種類および年金支払期間の変更を指示する。
設定ボタン１５０７の押下を受けて、メイン処理部７１１を実行するＣＰＵ２０３は画面データを取得する（ステップＳ１３０１）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００１」、年金種類「保証期間付終身年金」および年金支払期間「終身」を取得する。
３−３−２．レコードの取得
メイン処理部７１１を実行するＣＰＵ２０３は、画面データとして入力された証券番号に基づいてトランザクションデータベース２０９３にアクセスして検索し、当該証券番号によって特定されるトランザクションレコードをメモリ２０５に作成されたワーク領域に取得する（ステップＳ１３０３）。
図１６にトランザクションデータベース２０９３の例を示す。このデータベースには、第１の実施形態の図６と同様に、生命保険の契約管理に関するトランザクションデータが管理されている。なお、上記ワーク領域のレコードフォーマットは、トランザクションデータベースのレコードフォーマットと同一である。 例えば、ＣＰＵ２０３は、証券番号「００００１」によって特定されるトランザクションレコード１６１をトランザクションデータベース２０９３から取得する。
３−３−３．処理プログラムの要求
処理プログラム要求・実行部７１３を実行するＣＰＵ２０３は、メイン処理部７１１の実行において取得したトランザクションレコードに記録されている約款ＩＤに基づいて、商品定義体プログラム２０９４を特定し、処理名をアクセスした当該商品定義体プログラムに引き渡す（ステップＳ１３０５）。
例えば、Ｊａｖａ（商標）言語で作成された商品定義体プログラム２０９４のクラスファイル（１１１１１．ｃｌａｓｓ）等によって商品定義体プログラム２０９４を特定する。また、商品定義体プログラム２０９４に引き渡される処理名は、オペレータからの指示に基づいて決定する。例えば、上記においては、年金種類設定画面において年金種類を設定する指示がなされているため、ＣＰＵ２０３はメイン処理部７１１の実行によって取得した処理名である「年金種類設定」、「支払期間設定」および、「相関チェック」を引き渡す。すなわち、本実施形態においては、複数の処理コードが引き渡される。
３−３−４．処理データおよび組合せデータの取得
以下、約款ＩＤが「１１１１１」の商品定義体プログラム２０９４に処理名を引き渡した場合について説明する。引き渡しを受けてＣＰＵ２０３は、商品定義体プログラム２０９４の処理プログラム生成部７３１を実行し、処理コード記録部７３３を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ１３２１）。処理コード記録部７３３には、処理名ごとに処理コードが記録されている。例えば、ＣＰＵ２０３は処理名が「年金種類設定」の処理コード７３３１、「支払期間設定」の処理コード７３３２および「相関チェック」の処理コード７３３３を取得する。
ＣＰＵ２０３は、組合せデータ記録部を検索して受け継いだ処理名に対応した契約内容および契約内容ＩＤの組合せデータを取得する（ステップＳ１３２３）。組合せデータ記録部７３５には、契約条件ごとに組合せデータが記録されている。例えば、ＣＰＵ２０３は契約条件が「年金種類」である組合せデータ７３５１および「支払期間」である組合せデータ７３５２を取得する。
３−３−５．処理プログラムの生成
ＣＰＵ２０３は、処理コード記録部から取得した処理コードと、組合せデータ記録部から取得した組合せデータに基づいて処理プログラムを生成する（ステップＳ１３２５）。図１７に、生成した処理プログラムの構成例を示す。処理プログラム１７０は、「年金種類設定」の処理コード１７０１および組合せデータ１７０２、「支払期間設定」の処理コード１７０３および組合せデータ１７０４、「相関チェック」の処理コード１７０５およびチェックデータ１７０６から構成されている。
この場合において、チェックデータ１７０６は商品定義体プログラム２０９４において処理コード１７０５と同一領域に記録されているものとする。チェックデータは、設定可能な年金種類と支払期間の組合せをすべて記録したものであり、このデータの表現形式は、処理コードの実行時において判断できるものであればよい。例えば、配列形式やテーブル形式等の表現形式がこれに該当する。チェックデータに記録されるデータは契約内容ＩＤまたは契約内容のいずれであってもよい。
なお、図１７ａに示すように、処理コードごとに処理プログラムを生成するように構成してもよい。例えば、「年金種類設定」の処理コードおよび組合せデータから生成される「年金種類設定」処理プログラム１７１、「支払期間設定」の処理コードおよび組合せデータから生成される「支払期間設定」処理プログラム１７３、「相関チェック」の処理コードおよびチェックデータから生成される「相関チェック」処理プログラム１７５をそれぞれ生成してもよい。
３−３−６．処理プログラムの引き渡し
商品定義体プログラム２０９４を実行するＣＰＵ２０３は、生成した処理プログラム８０を業務プログラム２０９１に引き渡す（ステップＳ１３２７）。例えば、ＣＰＵ２０３は、リダイレクト機能やパイプ機能等を用いて処理プログラム１７０を引き渡す処理を行う。
３−３−７．処理プログラムの実行
業務プログラム２０９１においてＣＰＵ２０３は、商品定義体プログラム２０９４から受け継いだ処理プログラム１７０を実行する（ステップＳ１３０７）。このとき実行される処理プログラム１７０のフローチャートを図１４に示す。
処理プログラム１７０の実行においてＣＰＵ２０３は、処理コード１７０１と組合せデータ１７０２を用いて、年金種類設定処理を実行し、ワーク領域の所定変数位置の契約内容ＩＤを更新する（ステップＳ１４０１）。例えば、変数１を「０１」から「０２」に更新する。なお、年金種類設定処理のフローチャートは、第１の実施形態の図４に示したものと同様である。
ステップＳ１４０１と同様に、ＣＰＵ２０３は、処理コード１７０３と組合せデータ１７０４を用いて、支払期間設定処理を実行し、ワーク領域の所定変数位置の契約内容ＩＤを更新する（ステップＳ１４０３）。例えば、変数２を「０２」から「０１」に更新する。
ＣＰＵ２０３は、処理コード１７０５とチェックデータ１７０６を用いて、年金種類と支払期間の設定値が正しいか否かを判定するために相関チェック処理を実行する（ステップＳ１４０５〜）。ＣＰＵ２０３は、ワーク領域から年金種類と支払期間に設定された契約内容ＩＤを入力する（ステップＳ１４０５）。例えば、上記ステップＳ１４０１において設定した変数１から「保証期間付終身年金」を示す契約内容ＩＤ「０２」と、変数２から「終身」を示す契約内容ＩＤ「０１」をそれぞれ入力する。
ＣＰＵ２０３は、チェックデータの読み込みを判断し（ステップＳ１４０７、ＮＯ）、チェックデータ１７０６から、年金種類および支払期間の組合せデータを１件読み込む（ステップＳ１４０９）。例えば、図１７に示した処理プログラム１７０におけるチェックデータ１７０６の組合せデータから、年金種類「０２（保証期間付終身年金）」および支払期間「０１（終身）」の組合せデータ１７０６１を読み込む。
ＣＰＵ２０３は、ワーク領域から入力した契約内容ＩＤの組合せと、チェックデータ１７０６から読み込んだ組合せデータが、一致するか否かを判断する（ステップＳ１４１１）。例えば、入力した「保証期間付終身年金」を示す契約内容ＩＤ「０２」および「終身」を示す契約内容ＩＤ「０１」の組合せと、チェックデータ１７０６の１件目の年金種類「０２（保証期間付終身年金）」および支払期間「０１（終身）」の組合せデータ１７０６１が、一致するか否かを判断する。
ステップＳ１４１１において、契約内容ＩＤの組合せが一致しなければステップＳ１４０７に戻って同様の処理を繰り返す（ステップＳ１４１１、ＮＯ）。一方、契約内容ＩＤの組合せが一致していれば、ステップＳ１４１３に進み、更新可能フラグを立てる（ステップＳ１４１３）。例えば、上記の入力した「保証期間付終身年金」を示す契約内容ＩＤ「０２」および「終身」を示す契約内容ＩＤ「０１」の組合せは、１番目に読み込んだ組合せデータ１７０６１と一致するので、更新可能フラグをＯＮにして当該処理を終了する。
なお、ステップＳ１４０７において、すべてのチェックデータ１７０６の組合せを読み込んだと判断した場合には、ＣＰＵ２０３は更新可能フラグをＯＦＦにする（ステップＳ１４１５）。すなわち、この場合には入力した契約内容ＩＤの組合せに一致するチェックデータが存在せず、ワーク領域に設定された年金種類と支払期間の契約内容ＩＤの組合せが設定不可能であると判断する。
なお、上述したように処理コードごとの複数の処理プログラムを生成する構成とした場合には、上記ステップＳ１３０７において各処理プログラムを順次実行すればよい。この場合において、「年金種類設定」処理プログラム１７１における処理は、ステップＳ１４０１（図１４）と同様であり、「支払期間設定」処理プログラム１７３における処理は、ステップＳ１４０３と同様であり、「相関チェック」処理プログラム１７５における処理は、ステップＳ１４０５〜Ｓ１４１５と同様である。
３−３−８．レコードの更新
処理プログラムの実行を終えると、ＣＰＵ２０３は、更新可能フラグに基づいて、ワーク領域に記録されているデータに基づいてトランザクションレコードの更新が可能であるか否かを判断する（ステップＳ１３０９）。ＣＰＵ２０３は、更新可能フラグがＯＮであれば、更新可能であると判断してトランザクションデータベース２０９３のトランザクションレコードを更新する（ステップＳ１３１３）。例えば、図１６に示すトランザクションレコード１６１が、更新されてトランザクションレコード１６５のようになる。図１６に示すように、レコード１６１の変数１「０１」および変数２「０２」が、レコード１６５の変数１「０２」および変数２「０１」に更新されている。
また、ＣＰＵ２０３は、更新可能フラグがＯＦＦであれば、更新不可能であると判断してディスプレイ２０１に更新が不可能である旨を示すエラーメッセージを出力し、オペレータにデータ入力値の変更を促す（ステップＳ１３１１）。
３−４．まとめ
以上説明したように、この発明によれば、２以上の契約内容（データ内容）に対応する契約内容ＩＤを取得して、これらの契約内容ＩＤの組合せが正しいか否かをチェックする処理を行うことができる。このため、トランザクションデータベースにおいて保険商品データにかかる契約条件ごとに契約内容を管理しなくても、所望の契約条件における契約内容のチェックプログラムを取得して、これにかかるチェック処理を実行することができる。
また、商品の種類を示す種類ＩＤ（約款ＩＤ）に基づいて商品定義体プログラムを特定し、特定した商品定義体プログラム内においてチェックプログラムの処理コードとチェックリストを用いて生成した処理プログラムによってチェック処理を行うように構成することにより、商品に基づく特性を業務プログラムに記述する必要がなくなる。これにより、業務プログラムのメンテナンス性を向上させることができる。
４．第４の実施形態
第１〜３の実施形態においては、１つのトランザクションにおけるデータを取り扱う場合について説明したが、本実施形態においては、互いに関連する複数のトランザクションにおけるデータを取り扱う場合について説明する。
生命保険の分野においては、１の主契約に対して複数の特約が付加されたものを１つの保険商品として販売することが一般的である。主契約トランザクションと特約トランザクションを同一のデータベース上で管理する場合、あるトランザクションに契約内容データを格納するときには、同一保険商品に含まれる他のトランザクションにおける契約内容データとの整合性をとる必要がある。
（１）例えば、主契約が「定額年金」である場合において、「定期保険特約」を付加するときには、主契約に設定可能な年金種類は「確定年金」に限定され、同じく主契約に設定可能な年金支払期間は「１０年」に取扱範囲が限定されることがある。
（２）例えば、主契約が「定額年金」である場合において、「３大疾病定期保険特約」を付加するときには、月額の合計保険料が「３０００円」以上であることが条件とされることがある。
（３）例えば、主契約が「定額年金」である場合において、「定期保険特約」を付加するときには、保険商品名が「Ａ年金」として取り扱われ、同じく「３大疾病定期保険特約」を付加するときには、保険商品名が「Ｂ年金」として取り扱われることがある。
本実施形態においても第１〜３の実施形態と同様に、生命保険の契約管理に関するトランザクションデータおよび生命保険商品に関するデータを管理するデータ管理装置の例について説明する。
なお、第１〜３の実施形態において説明した「商品定義データ」については、本実施形態においては「約款定義データ」と読み替えて説明する。すなわち、「約款定義体プログラム」がこれに該当する。生命保険商品についての商品特性は、約款によって定まるものであり、約款を定義することは商品の内容を定義することと同義であるためである。また、１つの主契約に対して複数の特約が付加された保険商品を定義するためのデータを「契約リバンドル定義データ」として説明する。すなわち、「契約リバンドル定義体プログラム」がこれに該当する。
したがって、本実施形態のデータ管理装置は、「約款定義データ」および「契約リバンドル定義データ」を管理するデータ管理装置である。
４−１．機能ブロック図
本発明にかかるデータ管理装置１の機能ブロック図を、図２０に示す。この図は、第１の実施形態の図１に示したものにグループ定義部１８を追加したものである。グループ定義部１８は、複数の種類ＩＤの組合せごとに、データ記録部に記録可能なデータ内容ＩＤの組合せまたはデータ内容の組合せを記録する。例えば、保険商品の場合には、主契約に対する特約の組み合せパターンごとに、取扱可能な契約内容ＩＤの組合せまたは契約内容の組合せを記録する。
４−２．ハードウェア構成
本発明にかかるデータ管理装置１を、ＣＰＵを用いて実現したコンピュータ装置のハードウェア構成の一例を図２１に示す。この図は、基本的には第１の実施形態の図２に示したものと同様であるが、ハードディスク２０９は、業務プログラム２０９１、ラッパープログラムＡ２０９２ａ、ラッパープログラムＢ２０９２ｂ、トランザクションデータベース２０９３、契約リバンドル定義体プログラム２０９５および約款定義体プログラム２０９６を記録している点が異なる。
４−３．処理詳細（１）
図２２〜３０を用いて、本実施形態における処理の詳細（１）を説明する。なお、本実施形態においても、業務プログラム２０９１は、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。図２２に、業務プログラム２０９１、ラッパープログラムＡ２０９２ａ、ラッパープログラムＢ２０９２ｂ、契約リバンドル定義体プログラム２０９５および約款定義体プログラム２０９６における機能ブロック図を示す。
業務プログラム２０９１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部２１１１を備えている。
ラッパープログラムＡ２０９２ａは、契約リバンドル定義体プログラム２０９５に処理プログラムを要求してこれを実行するための処理プログラム要求・実行部２１３１を備えている。
契約リバンドル定義体プログラム２０９５は、ラッパープログラムＡ２０９２ａからの要求を受けて処理プログラムを生成するための処理プログラム生成部２１５１と、処理名ごとに処理コードを記録した処理コード記録部２１５３と、処理名ごとに所定のチェックデータを記録したチェックデータ記録部２１５５と、ラッパープログラムＢ２０９２ｂを介して約款定義体プログラム２０９６に記録されたデータを取得するためのデータ取得部２１５７を備えている（例えば、主たる約款ＩＤが「１１１１１」の場合。）。
本実施形態においては、第３の実施形態と同様に、証券番号によって特定されるトランザクションデータにおける年金種類を、「確定年金」から「保証期間付終身年金」に、年金支払期間を「５年」から「終身」に、それぞれ変更する指示をユーザが行う場合について説明する。図２３は、上記の場合においてデータ管理装置１で実行される業務プログラム２０９１、ラッパープログラムＢ２０９２ｂおよび約款定義体プログラム２０９６のフローチャートの例である。
４−３−１．画面データの取得
図１５に、業務プログラム２０９１におけるメイン処理部２１１１（図２２）の実行によってディスプレイ２０１に表示される年金種類設定画面１５０１の例を示す。この画面においては、証券番号の入力欄１５０３、年金種類の設定用のラジオボタン１５０４および１５０５、年金支払期間の設定用のラジオボタン１５０６等が表示されており、データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、年金種類および年金支払期間の変更を指示することができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄１５０３に「００００１」を入力し、年金種類に「保証期間付終身年金」を設定するためのラジオボタン１５０５および年金支払期間に「終身」を設定するためのラジオボタン１５０６を選択して、設定ボタン１５０７を押下することによって、データ管理装置１に対して年金種類および年金支払期間の変更を指示する。
設定ボタン１５０７の押下を受けて、メイン処理部２１１１を実行するＣＰＵ２０３は画面データを取得する（ステップＳ２２０１、図２３）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００１」、年金種類「保証期間付終身年金」および年金支払期間「終身」を取得する。
４−３−２．レコードの取得
メイン処理部２１１１を実行するＣＰＵ２０３は、画面データとして入力された証券番号に基づいてトランザクションデータベース２０９３にアクセスして検索し、当該証券番号によって特定されるトランザクションレコードをメモリ２０５に作成されたワーク領域に取得する（ステップＳ２２０３）。
図２８にトランザクションデータベース２０９３の例を示す。このデータベースには、生命保険の契約管理に関するトランザクションデータとして、証券番号６０１、枝番６１１、主特区分６１３、約款ＩＤ６０３、変数１＿６０５、変数２＿６０７、変数３＿６０９、保険料６１５…等が記録されている。なお、上記ワーク領域のレコードフォーマットは、トランザクションデータベースのレコードフォーマットと同一である。
ここで、証券番号６０１はトランザクションレコードを特定するためのデータＩＤであり、枝番６１１は同一の証券番号によって管理される複数の約款を一意に特定するためのデータＩＤであり、主特区分６１３は保険契約が「主契約」であるか「特約」であるかを示すための区分データである。なお、ここでは、「主契約」を「１」、「特約」を「２」としている。また、同一の証券番号ごとに「主契約」は１つのみしか存在しないが、「特約」は複数存在してもよい。約款ＩＤ６０３は保険商品を特定するための識別ＩＤであり、変数１＿６０５、変数２＿６０７、変数３＿６０９…はそれぞれの契約内容を特定するための契約内容ＩＤである。
例えば、ＣＰＵ２０３は、証券番号「００００１」によって特定されるトランザクションレコード２８１をトランザクションデータベース２０９３からワーク領域に取得する。
４−３−３．処理プログラムの要求
業務プログラム２０９１を実行するＣＰＵ２０３は、トランザクションレコード２８１に記録されている約款ＩＤおよび、オペレータ指示に基づいて特定された処理名を、ラッパープログラムＢ２０９２ｂに引き渡す（ステップＳ２２０５）。例えば、上記においては、年金種類設定画面において年金種類を設定する指示がなされているため、ＣＰＵ２０３はメイン処理部２１１１の実行によって取得した処理名である「年金種類設定」、「支払期間設定」および、「相関チェック」を引き渡す。すなわち、本実施形態においては、複数の処理コードが引き渡される。
４−３−４．ラッパープログラムの実行
ラッパープログラムＢ２０９２ｂを実行するＣＰＵ２０３は、処理プログラム要求・実行部２１３１において、業務プログラム２０９１から受け継いだ約款ＩＤに基づいて約款定義体プログラムを特定し、特定した約款定義体プログラム２０９６にアクセスして処理名を引き渡す（ステップＳ２２２１）。
４−３−５．処理データおよび組合せデータの取得
以下、約款ＩＤが「１１１１１」の約款定義体プログラム２０９６に処理コードを引き渡した場合について説明する。引き渡しを受けてＣＰＵ２０３は、約款定義体プログラム２０９６の処理プログラム生成部２１９１を実行し、処理コード記録部２１９３を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ２２４１）。処理コード記録部２１９３には、処理名ごとに処理コードが記録されている。例えば、図７に示したように、ＣＰＵ２０３は処理名が「年金種類設定」の処理コード７３３１、「支払期間設定」の処理コード７３３２および「相関チェック」の処理コード７３３３を取得する。
ＣＰＵ２０３は、組合せデータ記録部を検索して受け継いだ処理名に対応した契約内容および契約内容ＩＤの組合せデータを取得する（ステップＳ２２４３）。組合せデータ記録部２１９５には、契約条件ごとに組合せデータが記録されている。例えば、図７に示したように、ＣＰＵ２０３は契約条件が「年金種類」である組合せデータ７３５１および「支払期間」である組合せデータ７３５２を取得する。
４−３−６．処理プログラムの生成
ＣＰＵ２０３は、処理コード記録部から取得した処理コードと、組合せデータ記録部から取得した組合せデータに基づいて処理プログラムを生成する（ステップＳ２２４５）。図１７に、生成した処理プログラムの構成例を示す。処理プログラム１７０は、「年金種類設定」の処理コード１７０１および組合せデータ１７０２、「支払期間設定」の処理コード１７０３および組合せデータ１７０４、「相関チェック」の処理コード１７０５およびチェックデータ１７０６から構成されている。
この場合において、チェックデータ１７０６は約款定義体プログラム２０９６において処理コード１７０５と同一領域に記録されているものとする。チェックデータは、設定可能な年金種類と支払期間の組合せをすべて記録したものであり、このデータの表現形式は、処理コードの実行時において判断できるものであればよい。例えば、配列形式やテーブル形式等の表現形式がこれに該当する。チェックデータに記録されるデータは契約内容ＩＤまたは契約内容のいずれであってもよい。
なお、図１７ａに示すように、処理コードごとに処理プログラムを生成するように構成してもよい。例えば、「年金種類設定」の処理コードおよび組合せデータから生成される「年金種類設定」処理プログラム１７１、「支払期間設定」の処理コードおよび組合せデータから生成される「支払期間設定」処理プログラム１７３、「相関チェック」の処理コードおよびチェックデータから生成される「相関チェック」処理プログラム１７５をそれぞれ生成してもよい。
４−３−７．処理プログラムの引き渡し
約款定義体プログラム２０９６を実行するＣＰＵ２０３は、生成した処理プログラム１７０をラッパープログラムＢ２０９２ｂに引き渡す（ステップＳ２２４７）。これを受けて、ラッパープログラムＢ２０９２ｂを実行するＣＰＵ２０３は、さらに処理プログラム１７０を業務プログラム２０９１に引き渡す（ステップＳ２２２３）。
４−３−８．処理プログラムの実行
業務プログラム２０９１においてＣＰＵ２０３は、約款定義体プログラム２０９６から受け継いだ処理プログラム１７０を実行する（ステップＳ２２０７）。このとき実行される処理プログラム１７０のフローチャートは図１４に示したものと同様である。
４−３−９．契約リバンドルチェック処理
処理プログラムの実行を終えると、ＣＰＵ２０３は、更新可能フラグに基づいて、ワーク領域に記録されているデータに基づいてトランザクションレコードの更新が可能であるか否かを判断する（ステップＳ２２０９）。ＣＰＵ２０３は、更新可能フラグがＯＮであれば、更新可能であると判断して契約リバンドルチェック処理を実行する（ステップＳ２２１１）。
また、ＣＰＵ２０３は、更新可能フラグがＯＦＦであれば、更新不可能であると判断してディスプレイ２０１に更新が不可能である旨を示すエラーメッセージを出力し、オペレータにデータ入力値の変更を促す（ステップＳ２２１４）。
４−３−９−１．レコードの取得と引き渡し（業務プログラム）
図２３のステップＳ２２１１に示す契約リバンドルチェック処理について、図２４を用いて説明する。
業務プログラム２０９１においてＣＰＵ２０３は、同一契約のトランザクションレコードをすべて取得する（ステップＳ２４０１）。例えば、図２８に示すトランザクションデータベース２０９３において、同一契約を示す、証券番号が「００００１」であるレコード２８１およびレコード２８３をそれぞれ抽出する。ここで、レコード２８１とレコード２８３は、証券番号６０１が同一で枝番６１１が異なるレコードである。
すべてのレコードを取得すると、ＣＰＵ２０３は、取得した全レコードデータおよび所定の処理名をラッパープログラムＡ２０９２ａに引き渡す（ステップＳ２４０３）。例えば、上記においては、「年金種類設定」と「支払期間設定」についての処理がなされていることにより、これらの処理に対応した契約リバンドルチェック処理を実行するため、ＣＰＵ２０３は「年金種類−支払期間の契約リバンドルチェック」を処理名として引き渡す。
４−３−９−２．契約リバンドル定義体の特定（ラッパープログラムＡ）
引き渡しを受けてラッパープログラムＡ２０９２ａは、全レコードの主特区分６１３に基づいて主契約レコードを特定し、当該主契約レコードにかかる約款ＩＤに基づいて特定した契約リバンドル定義体プログラム２０９５に、前記全レコードおよび処理名を引き渡す（ステップＳ２４２１）。
例えば、図２８に示すレコード２８１においては、主特区分６１３が主契約（「１」）を示していることにより、当該レコード２８１にかかる約款ＩＤ６０３「１１１１１」に基づいて、契約リバンドル定義体プログラム２０９５を特定する。また、ＣＰＵ２０３は、上記「年金種類−支払期間の契約リバンドルチェック」を処理名として引き渡す。
４−３−９−３．処理プログラムの生成（契約リバンドル定義体プログラム）
契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、処理プログラム生成部２１５１を実行し、処理コード記録部２１５３を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ２４４１）。処理コード記録部２１５３には、約款ＩＤの組合せグループごとかつ処理名ごとに処理コードが記録されている。例えば、契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、約款ＩＤの組合せグループが「１１１１１」と「２２２２２」の組合せである処理コード群の中から、処理名が「年金種類−支払期間の契約リバンドルチェック」の処理コードを取得する。
次に、ＣＰＵ２０３は、チェックデータ記録部２１５５を検索して受け継いだ処理名に対応したチェックデータを取得する（ステップＳ２４４３）。チェックデータ記録部２１５５には、処理名ごとかつ約款ＩＤの組合せグループごとにチェックデータが記録されている。例えば、ＣＰＵ２０３は、約款ＩＤの組合せグループが「１１１１１」と「２２２２２」の組合せであるチェックデータ群の中から、「年金種類−支払期間の契約リバンドルチェックデータ」を取得する。
ＣＰＵ２０３は、処理コード記録部２１５３から取得した処理コードと、チェックデータ記録部２１５５から取得したチェックデータに基づいて処理プログラムを生成する（ステップＳ２４４５）。
図２９ａに、生成した処理プログラムの構成例を示す。処理プログラム２９１は、約款ＩＤの組合せグループが「１１１１１−２２２２２」の場合において、「年金種類−支払期間の契約リバンドルチェック」を行うための処理プログラムである。また、チェックデータは、年金種類が「保証期間付終身年金」、支払期間が「終身」であるデータに限り記録可能であることを意味している。つまり、約款ＩＤ「１１１１１」と約款ＩＤ「２２２２２」との関係においては、トランザクションデータベース２０９３に記録可能な年金種類および支払期間の組合せを、「保証期間付終身年金」および「終身」の組合せに制限されていることを表している。これにより、同一の保険商品として販売された他の契約（主契約または特約）との関係を考慮して、販売・保全取扱条件を適切に設定することができる。
４−３−９−４．チェック対象の契約内容の取得（契約リバンドル定義体プログラム）
契約リバンドル定義体プログラム２０９５を実行するＣＰＵ３０３は、データ取得部２１５７を実行することにより、ワーク領域に記録されているデータにおいて、チェック対象データとされている契約内容ＩＤに対応する契約内容を取得する（ステップＳ２４４７）。例えば、上記ステップＳ２２０７においては、「年金種類」および「支払期間」についての設定処理を行っているため、「年金種類」および「支払期間」がチェック対象データとして認識され、これらが示す契約内容ＩＤに基づいて契約内容を取得する処理が行われる。図２５に契約内容取得処理のフローチャートの例を示す。
契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、チェック対象の契約内容ＩＤが含まれるレコードに記録された約款ＩＤ、処理名および契約内容ＩＤをラッパープログラムＢに引き渡す（ステップＳ２５０１）。例えば、約款ＩＤ「１１１１１」、処理名「年金種類取得」および「支払期間取得」、契約内容ＩＤ「０２（年金種類）」および「０１（支払期間）」が引き渡される。
ラッパープログラムＢ２０９２ｂを実行するＣＰＵ２０３は、処理プログラム要求・実行部２１７１において、契約リバンドル定義体プログラム２０９５から受け継いだ約款ＩＤに基づいて約款定義体プログラムを特定し、特定した約款定義体プログラム２０９６に対して処理名を引き渡す（ステップＳ２５２１）。例えば、約款ＩＤ「１１１１１」に基づいて約款定義体プログラム２０９６を特定し、当該約款定義体プログラム２０９６に処理名「年金種類取得」および「支払期間取得」を引き渡す。
４−３−９−５．チェック対象の契約内容の取得（約款定義体プログラム）
引き渡しを受けてＣＰＵ２０３は、約款定義体プログラム２０９６の処理プログラム生成部２１９１を実行し、受け継いだ処理名に対応する処理コードを処理コード記録部２１９３から取得する（ステップＳ２５４１）。処理コード記録部２１９３には、処理名ごとに処理コードが記録されている。例えば、ＣＰＵ２０３は処理名が「年金種類取得」の処理コードを取得する。
ＣＰＵ２０３は、受け継いだ処理名に対応する契約内容および契約内容ＩＤの組合せデータを組合せデータ記録部２１９５から取得する（ステップ２５４３）。組合せデータ記録部２１９５には、契約条件ごとに組合せデータが記録されている。例えば、ＣＰＵ２０３は契約条件が「年金種類」である組合せデータを取得する。
４−３−９−６．処理プログラムの生成（約款定義体プログラム）
約款定義体プログラム２０９６を実行するＣＰＵ２０３は、取得した処理コードおよび組合せデータに基づいて処理プログラムを生成する（ステップＳ２５４５）。図３０に、生成した処理プログラムの構成例を示す。処理プログラム３００は、処理コード３０１および組合せデータ３０３から構成されている。例えば、処理コード３０１には、「年金種類取得」を処理するためのプログラムコードが記述されている。なお、このプログラムコードの表現形式は、ソースコードまたはオブジェクトコードのいずれであってもよい。
また、組合せデータ３０３には、「年金種類取得」を処理するためのプログラムコードが使用する契約内容ＩＤおよび契約内容の組合せデータが記述されている。なお、この組合せデータの表現形式は、契約内容ＩＤに対応する契約内容が上記プログラムコードの実行時において判断できるものであればよい。例えば、配列形式やテーブル形式等の表現形式がこれに該当する。
同様に、ＣＰＵ２０３は、「支払期間取得」についても処理プログラムを生成する。
約款定義体プログラム２０９６を実行するＣＰＵ２０３は、生成した処理プログラム３００をラッパープログラムＢ２０９２ｂに引き渡す（ステップＳ２５４７）。例えば、ＣＰＵ２０３は、リダイレクト機能やパイプ機能等を用いて処理プログラム３００を引き渡す処理を行う。
４−３−９−７．処理プログラムの実行（ラッパープログラムＢ）
ラッパープログラムＢ２０９２ｂにおいてＣＰＵ２０３は、約款定義体プログラム２０９６から受け継いだ処理プログラム３００を実行し、ワーク領域から取得した契約内容ＩＤに対応する契約内容を取得する（ステップＳ２５２３）。このとき実行される処理プログラム３００のフローチャートを図２６に示す。処理プログラム３００の実行においてＣＰＵ２０３は、ワーク領域から契約内容ＩＤを入力する（ステップＳ２６０１）。例えば、契約内容ＩＤとして「０２」を入力する。
ＣＰＵ２０３は、処理プログラム３００に格納されている組合せデータ３０３から、契約内容ＩＤおよび契約内容の組合せデータを１件読み込む（ステップＳ２６０３）。例えば、図３０に示した処理プログラム３００の組合せデータから、契約内容ＩＤ「０１」および契約内容「確定年金」の組合せデータ３０３１を読み込む。
ＣＰＵ２０３は、入力した契約内容と、読み込んだ組合せデータにおける契約内容が一致するか否かを判断する（ステップＳ２６０５）。例えば、入力した契約内容ＩＤ「０２」と、最初に読み込んだ組合せデータにおける契約内容ＩＤ「０１」が一致するか否かを判断する。
ステップＳ２６０５において、契約内容ＩＤが一致しなければステップＳ２６０３に戻って次の組合せデータを読み込み、ステップＳ２６０５を再実行する（ステップＳ２６０５、ＮＯ）。一致していれば、ステップＳ２６０７に進み、組合せデータの契約内容ＩＤに対応づけて記録されている契約内容を取得する（ステップＳ２６０７）。例えば、契約内容ＩＤ「０２」は、２番目に読み込んだ組合せデータ３０３２（契約内容ＩＤ「０２」と契約内容「保証期間付終身年金」）の契約内容ＩＤと一致するので、これに対応する契約内容「保証期間付終身年金」を取得する。
図２５において、ラッパープログラムＢを実行するＣＰＵ２０３は、取得した契約内容を、契約リバンドル定義体プログラム２０９５に引き渡す（ステップＳ２５２５）。例えば、年金種類の契約内容ＩＤ「０２」に対して契約内容「保証期間付終身年金」を引き渡し、支払期間の契約内容ＩＤ「０１」に対して契約内容「終身」を引き渡す。
図２４において、契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、上記契約内容を処理プログラムの一部としてに組み込むように設定する（ステップＳ２４４９）。例えば、図２９ａに示した処理プログラム２９１にチェック対象データにかかる契約内容を組み込み、図２９ｂに示す処理プログラム２９３のようにする。これにより、処理プログラム２９３の実行時においてＣＰＵ２０３は、チェック対象データ２９３１を読み込んで、チェックデータ２９３３に一致するか否かを判断する処理を行うことができる。
契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、生成した処理プログラム２９３をラッパープログラムＡ２０９２ａに引き渡す（ステップＳ２４５１）。
４−３−９−８．処理プログラムの実行（ラッパープログラムＡ）
ラッパープログラムＡ２０９２ａにおいてＣＰＵ２０３は、契約リバンドル定義体プログラム２０９５から受け継いだ処理プログラム２９３を実行し、ワーク領域のチェック対象データである契約内容ＩＤに対応する契約内容が、チェックデータの契約内容に一致するか否かを判断する（ステップＳ２４２３、図２４）。このとき実行される処理プログラム２９３のフローチャートの例を図２７に示す。
処理プログラム２９３の実行においてＣＰＵ２０３は、処理プログラム内に組み込まれて設定されている年金種類と支払期間のチェック対象データを読み込む（ステップＳ２７０１）。例えば、年金種類「保証期間付終身年金」と支払期間「終身」の組合せデータ２９３１（図２９ｂ）を読み込む。
ＣＰＵ２０３は、チェックデータの読み込みを判断し（ステップＳ２７０３、ＮＯ）、チェックデータ２９３３から、年金種類および支払期間の組合せデータを１件読み込む（ステップＳ２７０５）。例えば、図２９ｂに示した処理プログラム２９３におけるチェックデータ２９３３から、年金種類「保証期間付終身年金」および支払期間「終身」の組合せデータ２９３３を読み込む。
ＣＰＵ２０３は、チェック対象データから読み込んだ契約内容の組合せデータと、チェックデータ２９３１から読み込んだ契約内容の組合せデータが、一致するか否かを判断する（ステップＳ２７０７）。例えば、ステップＳ２７０１において読み込んだ契約内容の組合せデータ２９３１（年金種類「保証期間付終身年金」、支払期間「終身」）と、チェックデータの１件目の契約内容の組合せデータ２９３３（年金種類「保証期間付終身年金」、支払期間「終身」）が、一致するか否かを判断する。
ステップＳ２７０７において、契約内容の組合せデータが一致しなければステップＳ２７０３に戻って同様の処理を繰り返す（ステップＳ２７０７、ＮＯ）。一方、契約内容ＩＤの組合せデータが一致していれば、ステップＳ２７０９に進み、更新可能フラグを立てる（ステップＳ２７０９）。例えば、上記チェック対象データにおける契約内容「保証期間付終身年金」および契約内容「終身」を示す契約内容の組合せデータ２９３１は、１番目に読み込んだ組合せデータ２９３３と一致するので、更新可能フラグをＯＮにして当該処理を終了する。なお、実施形態においてはチェックデータとしての契約内容の組合せデータは１件しか存在していないが、複数存在する場合もあり得る。
なお、ステップＳ２７０３において、すべてのチェックデータ２９３３の組合せデータを読み込んだと判断した場合には、ＣＰＵ２０３は更新可能フラグをＯＦＦにする（ステップＳ２７１１）。すなわち、この場合にはチェック対象データにおける契約内容の組合せデータが、チェックデータにおける契約内容の組合せデータに存在しないため、ワーク領域に設定された年金種類と支払期間の契約内容ＩＤの組合せが設定不可能であると判断する。
ラッパープログラムＡ２０９２ａを実行するＣＰＵ２０３は、実行結果を業務プログラム２０９１に通知する（ステップＳ２４２５、図２４）。例えば、更新可能フラグ「１（ＯＮ）」を、戻り値として業務プログラム２０９１のプログラムスレッドに返す処理を行う。
４−３−９−９．レコードの更新
図２３において、契約リバンドルチェック処理（ステップＳ２２１１）の実行を終えると、業務プログラム２０９１を実行するＣＰＵ２０３は、更新可能フラグに基づいて、ワーク領域に記録されているデータに基づいてトランザクションレコードの更新が可能であるか否かを判断する（ステップＳ２２１３）。ＣＰＵ２０３は、更新可能フラグがＯＮであれば、更新可能であると判断してトランザクションデータベース２０９３のトランザクションレコードを更新する（ステップＳ２２１５）。
例えば、図２８に示すトランザクションレコード２８１が、更新されてトランザクションレコード２８５のようになる。図２８に示すように、レコード２８１の変数１＿６０５「０１」および変数２＿６０７「０２」が、レコード２８５の変数１＿６０５「０２」および変数２＿６０７「０１」に更新されている。
また、ＣＰＵ２０３は、更新可能フラグがＯＦＦであれば、更新不可能であると判断してディスプレイ２０１に更新が不可能である旨を示すエラーメッセージを出力し、オペレータにデータ入力値の変更を促す（ステップＳ２２１４）。
４−４．処理詳細（２）
上記処理詳細（１）においては、同一保険商品の他の契約との関係で設定可能な契約内容ＩＤが限定される例について説明したが、処理詳細（２）においては、同一保険商品の他の契約との関係で設定可能なデータ値の範囲が限定される例について説明する。
図２２ａ、図２３ａ、図２４ａ、図２７ａ、図３１および図３２等を用いて、本実施形態における処理の詳細（２）を説明する。なお、本実施形態においても、業務プログラム２０９１は、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。図２２ａに、業務プログラム２０９１、ラッパープログラムＡ２０９２ａおよび契約リバンドル定義体プログラム２０９５における機能ブロック図を示す。
業務プログラム２０９１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部２１１１を備えている。
ラッパープログラムＡ２０９２ａは、契約リバンドル定義体プログラム２０９５に処理プログラムを要求してこれを実行するための処理プログラム要求・実行部２１３１を備えている。
契約リバンドル定義体プログラム２０９５は、ラッパープログラムＡ２０９２ａからの要求を受けて処理プログラムを生成するための処理プログラム生成部２１５１と、処理名ごとに処理コードを記録した処理コード記録部２１５３と、処理名ごとに所定のチェックデータを記録したチェックデータ記録部２１５５を備えている（例えば、主たる約款ＩＤが「１１１１１」の場合。）。
本実施形態においては、保険商品の保険金額を減額する指示をユーザが行った場合において、トランザクションデータ２０９３に記録されようとしているデータの保険料データが、所定のデータ範囲にあるか否かについてのチェックを行う例について説明する。
図２３ａは、上記の場合においてデータ管理装置１で実行される業務プログラム２０９１のフローチャートの例である。
４−４−１．画面データの取得
図３１に、業務プログラム２０９１におけるメイン処理部２１１１（図２２ａ）の実行によってディスプレイ２０１に表示される保険金額変更画面３１０の例を示す。この画面においては、証券番号の入力欄３１０１、保険名称表示欄３１０３、保険金額入力欄３１０５、月額保険料表示欄３１０７および合計保険料表示欄３１０９等が表示される。
データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、保険金額の変更を指示することができる。例えば、オペレータが、キーボード／マウス２０７を用いて証券番号の入力欄３１０１に「００００２」を入力すると、業務プログラム２０９１を実行するＣＰＵ２０３は、トランザクションデータベース２０９３にアクセスして検索し、当該保険契約にかかる保険名称、保険金額、保険料および合計保険料等を保険金額変更画面３１０に表示させる。ここで、合計保険料は、ＣＰＵ２０３が各保険契約の月額保険料を合算することによって算出したものである。
さらに、オペレータが、保険金額を変更する操作を行うと、業務プログラム２０９１を実行するＣＰＵ２０３は、これを検知して、月額保険料表示欄３１０７の保険料および合計保険料表示欄３１０９の合計保険料を自動的に再表示する。オペレータは、再表示された保険料を確認すると、設定ボタン３１１１を押下してトランザクションデータベース２０９３への更新を指示する。
設定ボタン３１１１の押下を受けると、メイン処理部２１１１を実行するＣＰＵ２０３は、画面データを所定のワーク領域に取得する（ステップＳ２３０１、図２３ａ）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００２」、合計保険料「４５００円」等を取得する。
４−４−２．契約リバンドルチェック処理
画面データを取得したＣＰＵ２０３は、契約リバンドルチェック処理を実行する（ステップＳ２３０３）。図２３ａのステップＳ２３０３に示す契約リバンドルチェック処理について、図２４ａを用いて説明する。図２４ａは、上記において説明した図２４からステップＳ２４４７を除いたものであり、基本的には図２４と同様の処理を行う。以下、図２４と図２４ａの相違点について説明する。
４−４−２−１．ラッパープログラムの起動（業務プログラム）
業務プログラム２０９１においてＣＰＵ２０３は、同一契約のトランザクションレコードをすべて取得する（ステップＳ２４０１）。例えば、図３２に示すトランザクションデータベース２０９３において、同一契約を示す、証券番号が「００００２」であるレコード３２１およびレコード３２３をそれぞれ抽出する。ここで、レコード３２１とレコード３２３は、証券番号６０１が同一で枝番６１１が異なるレコードである。
すべてのレコードを取得すると、ＣＰＵ２０３は、取得した全レコードデータおよび所定の処理名をラッパープログラムＡ２０９２ａに引き渡す（ステップＳ２４０３）。例えば、上記においては、保険金額を変更する処理がなされており、これに連動して設定されるべき月額保険料が所定の条件に合致しているか否かをチェックするための契約リバンドルチェック処理を実行する。このため、ＣＰＵ２０３は、ラッパープログラムＡ２０９２ａに「保険料の契約リバンドルチェック」を処理名として引き渡す。
４−４−２−２．契約リバンドル定義体の特定（ラッパープログラムＡ）
引き渡しを受けてラッパープログラムＡ２０９２ａは、全レコードの主特区分６１３に基づいて主契約レコードを特定し、当該主契約レコードにかかる約款ＩＤに基づいて特定した契約リバンドル定義体プログラム２０９５に、前記全レコードおよび処理名を引き渡す（ステップＳ２４２１）。
例えば、図３２に示すレコード３２１においては、主特区分６１３が主契約（「１」）を示していることにより、当該レコード３２１にかかる約款ＩＤ６０３「１１１１１」に基づいて、契約リバンドル定義体プログラム２０９５を特定する。また、ＣＰＵ２０３は、上記「保険料の契約リバンドルチェック」を処理名として引き渡す。
４−４−２−３．処理プログラムの生成（契約リバンドル定義体プログラム）
契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、処理プログラム生成部２１５１を実行し、処理コード記録部２１５３を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ２４４１）。処理コード記録部２１５３には、約款ＩＤの組合せグループごとかつ処理名ごとに処理コードが記録されている。例えば、契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、約款ＩＤの組合せグループが「１１１１１」と「３３３３３」の組合せである処理コード群の中から、処理名が「保険料の契約リバンドルチェック」の処理コードを取得する。
次に、ＣＰＵ２０３は、チェックデータ記録部２１５５を検索して受け継いだ処理名に対応したチェックデータを取得する（ステップＳ２４４３）。チェックデータ記録部２１５５には、処理名ごとかつ約款ＩＤの組合せグループごとにチェックデータが記録されている。例えば、ＣＰＵ２０３は、約款ＩＤの組合せグループが「１１１１１」と「３３３３３」の組合せであるチェックデータ群の中から、「保険料の契約リバンドルチェックデータ」を取得する。
ＣＰＵ２０３は、処理コード記録部２１５３から取得した処理コードと、チェックデータ記録部２１５５から取得したチェックデータに基づいて処理プログラムを生成する（ステップＳ２４４５）。
図２９ｃに、生成した処理プログラムの構成例を示す。処理プログラム２９５は、約款ＩＤの組合せグループが「１１１１１−３３３３３」の場合において、「保険料の契約リバンドルチェック」を行うための処理プログラムである。また、チェックデータは、月額の合計保険料が「４０００円」以上である保険料データに限り記録可能であることを意味している。これにより、同一の保険商品として販売された他の契約（主契約または特約）との関係を考慮して、販売・保全取扱条件の一部としての合計保険料を適切に設定することができる。
契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、生成した処理プログラム２９５をラッパープログラムＡ２０９２ａに引き渡す（ステップＳ２４５１）。
４−４−２−４．処理プログラムの実行（ラッパープログラムＡ）
ラッパープログラムＡ２０９２ａにおいてＣＰＵ２０３は、契約リバンドル定義体プログラム２０９５から受け継いだ処理プログラム２９５を実行し、ワーク領域の保険料における月額の合計保険料が、所定の範囲内にあるか否かを判断する（ステップＳ２４２３、図２４ａ）。このとき実行される処理プログラム２９５のフローチャートの例を図２７ａに示す。
処理プログラム２９５の実行においてＣＰＵ２０３は、処理プログラム内に組み込まれて設定されているチェックデータである「保険料≧４０００円」を示すデータを読み込み（ステップＳ２７２１）。さらに、チェック対象のデータ値である合計保険料をワーク領域から読み込む（ステップＳ２７２３）。例えば、変更操作後の合計保険料「４５００円」を読み込む。
ＣＰＵ２０３は、チェックデータから読み込んだデータ範囲条件に基づいて、読み込んだチェック対象データがデータ範囲内にあるか否かを判断する（ステップＳ２７２５）。例えば、チェックデータから読み込んだデータ範囲条件である「保険料≧４０００円」に基づいて、上記合計保険料「４５００円」がデータ範囲にあるか否かを判断する。
ステップＳ２７２５において、チェック対象データが所定のデータ範囲内にあれば、ステップＳ２７２７に進み更新可能フラグを立てる（ステップＳ２７２７）。例えば、上記チェック対象データにおける合計保険料「４５００円」は、読み込んだチェックデータ２９５１に示されたデータ範囲条件「保険料≧４０００円」に合致するので、更新可能フラグをＯＮにして当該処理を終了する。
なお、ステップＳ２７２５において、チェック対象データが所定のデータ範囲内になければ、ステップＳ２７２９に進み更新不可能フラグを立てる（ステップＳ２７２９）。例えば、合計保険料が「４０００円」に満たない場合には、更新不可能フラグが立てられる。
図２４ａのステップＳ２４２３において、ラッパープログラムＡ２０９２ａを実行するＣＰＵ２０３は、ステップＳ２４２３の実行結果を業務プログラム２０９１に通知する（ステップＳ２４２５、図２４ａ）。例えば、更新可能フラグ「１（ＯＮ）」を、戻り値として業務プログラム２０９１のプログラムスレッドに返す処理を行う。
４−４−２−５．レコードの更新
図２３ａにおいて、契約リバンドルチェック処理（ステップＳ２３０３）の実行を終えると、業務プログラム２０９１を実行するＣＰＵ２０３は、更新可能フラグに基づいて、ワーク領域に記録されているデータに基づいてトランザクションレコードの更新が可能であるか否かを判断する（ステップＳ２３０５）。ＣＰＵ２０３は、更新可能フラグがＯＮであれば、更新可能であると判断してトランザクションデータベース２０９３のトランザクションレコードを更新する（ステップＳ２３０７）。
例えば、図３２に示すトランザクションレコード３２１が、更新されてトランザクションレコード３２５のようになる。図３２に示すように、レコード３２１の保険料６１５「４０００円」が、レコード３２５の保険料６１５「３０００円」に更新されている。
また、ＣＰＵ２０３は、更新可能フラグがＯＦＦであれば、更新不可能であると判断してディスプレイ２０１に更新が不可能である旨を示すエラーメッセージを出力し、オペレータにデータ入力値の変更を促す（ステップＳ２３０６）。
４−５．処理詳細（３）
上記処理詳細（１）においては、同一保険商品の他の契約との関係で設定可能な契約内容ＩＤが限定される例について説明し、上記処理詳細（２）においては、同一保険商品の他の契約との関係で設定可能なデータ値の範囲が限定される例について説明したが、処理詳細（３）においては、同一保険商品の他の契約との関係で保険商品名を特定する例について説明する。
図２２ｂ、図２３ｂ、図２４ｂおよび図３１等を用いて、本実施形態における処理の詳細（３）を説明する。なお、本実施形態においても、業務プログラム２０９１は、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。図２２ｂに、業務プログラム２０９１、ラッパープログラムＡ２０９２ａおよび契約リバンドル定義体プログラム２０９５における機能ブロック図を示す。
業務プログラム２０９１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部２１１１を備えている。
ラッパープログラムＡ２０９２ａは、契約リバンドル定義体プログラム２０９５に処理プログラムを要求してこれを実行するための処理プログラム要求・実行部２１３１を備えている。
契約リバンドル定義体プログラム２０９５は、ラッパープログラムＡ２０９２ａからの要求を受けて処理プログラムを生成するための処理プログラム生成部２１５１と、処理名ごとに所定の名称データを記録した名称データ記録部２１５７を備えている（例えば、主たる約款ＩＤが「１１１１１」の場合。）。
本実施形態においては、保険商品のディスプレイ表示を行う場合において、入力された証券番号によって関連付けられた契約データに基づいて特定される所定の保険商品名を示す名称データを、契約リバンドル定義体プログラムから取得する例について説明する。
図２３ｂは、上記の場合においてデータ管理装置１で実行される業務プログラム２０９１のフローチャートの例である。
４−５−１．画面データの取得
図３１に、業務プログラム２０９１におけるメイン処理部２１１１（図２２ｂ）の実行によってディスプレイ２０１に表示される保険金額変更画面３１０の例を示す。この画面においては、証券番号の入力欄３１０１、保険名称表示欄３１０３、保険金額入力欄３１０５、月額保険料表示欄３１０７および合計保険料表示欄３１０９等が表示される。
データ管理装置１のオペレータは、上記処理詳細（２）において説明した「保険金額の変更」を指示する前段階においては、証券番号の入力欄３１０１に所定の証券番号を入力して、当該生命保険契約にかかるトランザクションデータ等をディスプレイ表示させる。本実施形態においては、このとき同時に保険金額変更画面３１０の保険名称表示欄３１０３に表示される保険名称を取得する例について説明する。
例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄３１０１に「００００２」を入力すると、業務プログラム２０９１を実行するＣＰＵ２０３は、これを検知して証券番号の入力欄３１０１から証券番号データを取得する（ステップＳ２３０１）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００２」を取得する。
４−５−２．契約リバンドルチェック処理
画面データを取得したＣＰＵ２０３は、契約リバンドルチェック処理を実行する（ステップＳ２３０３）。図２３ｂのステップＳ２３０３に示す契約リバンドルチェック処理について、図２４ｂを用いて説明する。
４−５−２−１．ラッパープログラムの起動（業務プログラム）
業務プログラム２０９１においてＣＰＵ２０３は、同一契約のトランザクションレコードをすべて取得する（ステップＳ２４０１）。例えば、図３２に示すトランザクションデータベース２０９３において、同一契約を示す、証券番号が「００００２」であるレコード３２１およびレコード３２３をそれぞれ抽出する。ここで、レコード３２１とレコード３２３は、証券番号６０１が同一で枝番６１１が異なるレコードである。
すべてのレコードを取得すると、ＣＰＵ２０３は、取得した全レコードデータおよび所定の処理名をラッパープログラムＡ２０９２ａに引き渡す（ステップＳ２４０３）。例えば、上記においては、証券番号に基づく保険商品情報をディスプレイ表示するための処理がなされており、これに連動して表示されるべき保険名称を取得するための契約リバンドルチェック処理を実行する。このため、ＣＰＵ２０３は、ラッパープログラムＡ２０９２ａに「保険名称」を処理名として引き渡す。
４−５−２−２．契約リバンドル定義体の特定（ラッパープログラムＡ）
引き渡しを受けてラッパープログラムＡ２０９２ａは、全レコードの主特区分６１３に基づいて主契約レコードを特定し、当該主契約レコードにかかる約款ＩＤに基づいて特定した契約リバンドル定義体プログラム２０９５に、前記全レコードおよび処理名を引き渡す（ステップＳ２４２１）。
例えば、図３２に示すレコード３２１においては、主特区分６１３が主契約（「１」）を示していることにより、当該レコード３２１にかかる約款ＩＤ６０３「１１１１１」に基づいて、契約リバンドル定義体プログラム２０９５を特定する。また、ＣＰＵ２０３は、上記「保険名称」を処理名として引き渡す。
４−５−２−３．名称データの取得（契約リバンドル定義体プログラム）
契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、処理プログラム生成部２１５１を実行し、名称データ記録部２１５７を検索して受け継いだ処理名に対応する名称データを取得する（ステップＳ２４４１）。名称データ記録部２１５７には、約款ＩＤの組合せグループごとかつ処理名ごとに名称データが記録されている。
例えば、契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、約款ＩＤの組合せグループが「１１１１１」と「３３３３３」の組合せである名称データ群の中から、処理名が「保険名称」の名称データを取得する。なお、「保険名称」には、実データとして「Ｂ年金」という保険商品名が記録されている。
契約リバンドル定義体プログラム２０９５を実行するＣＰＵ２０３は、名称データ記録部２１５７から取得した名称データをラッパープログラムＡ２０９２ａに引き渡す（ステップＳ２４５２）。さらに、ラッパープログラムＡ２０９２ａを実行するＣＰＵ２０３は、契約リバンドル定義体プログラム２０９５から取得した名称データを業務プログラム２０９１に引き渡す（ステップＳ２４２６）。
４−５−２−４．名称データの表示
図２３ｂにおいて、契約リバンドルチェック処理（ステップＳ２３０３）の実行を終えると、業務プログラム２０９１を実行するＣＰＵ２０３は、取得した名称データを、ステップＳ２３０１において取得した証券番号に対応する保険商品名としてディスプレイ２０１に表示する（ステップＳ２３０９）。
例えば、図３１の保険金額変更画面３１０の保険名称表示欄３１０３に、保険商品名として「Ｂ年金」を表示する。
４−６．まとめ
以上説明したように、この発明によれば、互いに関連する複数のトランザクションにおけるデータを取り扱う場合において、当該データが所定の取り扱い条件に合致するか否かを判断することができる。また、互いに関連する複数のトランザクションにおけるデータを取り扱う場合において、当該データの組合せごとに保険名称などの所定データを設定して利用することができる。
したがって、特に、生命保険の分野において、１の主契約に対して複数の特約が付加されている場合であっても、主契約トランザクションと特約トランザクションとの整合性を考慮しながらトランザクションデータを取り扱うことができる。
さらに、保険契約の主契約レコードの約款ＩＤに基づいて契約リバンドル定義体プログラムを特定し、さらに特定した約款定義体プログラム内においてチェックプログラムの処理コードとチェックデータを用いて生成した処理プログラムによってチェック対象データのチェック処理を行うように構成することにより、保険契約の商品性に基づくチェックロジックを業務プログラム側に記述する必要がなくなる。これにより、業務プログラムのメンテナンス性を向上させることができる。
なお、上記処理詳細（１）においては、契約リバンドル定義体プログラムに設定可能な契約内容ＩＤ（データ内容ＩＤ）に対応する契約内容（データ内容）を記録する構成としたが、設定可能な契約内容ＩＤを記録する構成としてもよい。この場合、ワーク領域に記録した契約内容ＩＤに基づいて、約款定義体プログラムから契約内容を取得する必要はなく、契約内容ＩＤを直接比較することにより、ワーク領域のトランザクションデータの記録可否を判断することができる。
５．第５の実施形態
上述したように、生命保険の分野においては、１の主契約に対して複数の特約が付加されたものを１つの保険商品として販売することが一般的である。主契約トランザクションと特約トランザクションを同一のデータベース上で管理する場合において、主契約トランザクションが存在して、新たな特約トランザクションを付加するときには、データベースに記録するデータ項目によっては主契約トランザクションにかかる商品データの影響を受けることがある。
例えば、主契約が「終身保険」である場合において、「定期保険特約」を付加するときには、「定期保険特約」の契約年月日は、「責任開始年月日と同一」に設定しなければならない。また、主契約が「個人年金」である場合において、同じく「定期保険特約」を付加するときには、「定期保険特約」の契約年月日は、「責任開始年月日の４日後」に設定しなければならない。ここで、「契約年月日」とは、契約年齢や保険期間などの計算の基準日である。また、「責任開始年月日」とは、申し込まれた契約の保障が開始される日である。
このような状況において、「定期保険特約」を付加する処理について考えると、新商品の主契約が追加されるたびに、特約の約款定義体プログラムに主契約に基づいて契約年月日を設定する判断ロジックを組み込むことによって対応可能ではある。しかしながら、新商品の販売時の様に、主契約の種類が増加するケースが発生した場合は、新商品の主契約に付加可能な特約の約款定義体プログラムすべてに変更が生じるため、保守性が著しく低下する。
そこで、本実施形態においては、主契約を追加する場合であっても、判断ロジックを組み込むことを要せず、保守性を高めたデータ管理装置について説明する。
なお、第４の実施形態と同様に、第１〜３の実施形態において説明した「商品定義データ」については、本実施形態においては「約款定義データ」と読み替えて説明する。
５−１．機能ブロック図
本発明にかかるデータ管理装置１の機能ブロック図は、図１または図２０に示したものと同様である。
５−２．ハードウェア構成
本発明にかかるデータ管理装置１を、ＣＰＵを用いて実現したコンピュータ装置のハードウェア構成の一例は、基本的には図２または図２１に示したものと同様である。
５−３．処理詳細
図３３〜３８を用いて、本実施形態における処理の詳細を説明する。なお、本実施形態においても、業務プログラム３３０１は、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。図３３に、業務プログラム３３０１、ラッパープログラムＡ３３０３、特約の約款定義体プログラム３３０５、…、ラッパープログラムＢ３３０７および主契約の約款定義体プログラム３３０９または３３１１、…における機能ブロック図を示す。
業務プログラム３３０１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部３３２１および処理プログラムを実行する処理プログラム実行部３３２３を備えている。
ラッパープログラムＡ３３０３は、特約の約款定義体プログラム３３０５に処理プログラムを要求するための処理プログラム要求部３３２５を備えている。
約款定義体プログラム３３０５は、ラッパープログラムＡ３３０３からの要求を受けて処理プログラムを生成するための処理プログラム生成部３３２６と、処理名ごとに処理コードを記録した処理コード記録部３３２７と、ラッパープログラムＢ３３０７を介して他の約款ＩＤにかかる約款定義体プログラム３３０９または３３１１等から処理プログラムを取得するための他約款定義体参照部３３２９を備えている（例えば、主たる約款ＩＤが「５５５５５」の場合。）。
本実施形態においては、証券番号によって特定される主契約「個人年金」に対して、特約「定期保険特約」を付加する指示をユーザが行う場合について説明する。図３４は、上記の場合においてデータ管理装置１で実行される業務プログラム３３０１、ラッパープログラムＡ３３０３、特約の約款定義体プログラム３３０５、ラッパープログラムＢ３３０７および主契約の約款定義体プログラム３３１１のフローチャートの例である。
５−３−１．画面データの取得
図３６に、業務プログラム３３０１におけるメイン処理部３３２１（図３３）の実行によってディスプレイ２０１に表示される保険契約変更画面３６０の例を示す。この画面においては、証券番号の入力欄３６１、日付表示欄３６８、契約者名表示欄３６２、主契約表示欄３６３、特約１表示欄３６４、特約２表示欄３６５および特約３表示欄３６６および設定ボタン３６７等が表示されており、データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、特約を付加して保険契約の変更を指示することができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄３６１に「００００３」を入力し、主契約表示欄３６３に「個人年金」を、特約１表示欄３６４に「災害入院特約」をそれぞれ表示させる。すなわち、この段階において、証券番号「００００３」の保険契約は、主契約「個人年金」に対して、特約「災害入院特約」が付加されていることを示している。
その後、オペレータは、特約２表示欄３６５のドロップダウンリストから「定期保険特約」を選択入力して、設定ボタン３６７を押下することにより、証券番号「００００３」の主契約に対して、特約「定期保険特約」を付加する処理の実行を指示する。
設定ボタン３６７の押下を受けて、メイン処理部３３２１を実行するＣＰＵ２０３は画面データを取得する（ステップＳ３４０１、図３４）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００３」、特約「定期保険特約」を取得する。
５−３−２．ワークレコードの作成
メイン処理部３３２１を実行するＣＰＵ２０３は、画面データとして入力された証券番号や特約情報等に基づいて、トランザクションデータベース２０９３に特約レコードとして記録するためのワークレコードを作成する（ステップＳ３４０３）。
図３５にワークレコードの例を示す。このワークレコードは、トランザクションデータベース２０９３と同一のレコードフォーマットから構成されており、証券番号３５１、枝番３５２、約款ＩＤ３５３、変数１〜３＿３５５、主約款ＩＤ３５７、契約年月日３５９および責任開始年月日３１１…等が記録される。
ここで、証券番号３５１はトランザクションレコードを特定するためのデータＩＤであり、枝番３５２は同一の証券番号によって管理される同一の保険契約を特定するためのデータＩＤであり、変数１〜３＿３５５はそれぞれの契約内容を特定するための契約内容ＩＤであり、主約款ＩＤ３５７は証券番号によって管理される同一の保険契約における主契約に記録された約款ＩＤであり、契約年月日３５９は上述した「契約年月日」を記録するためのものであり、責任開始年月日３１１は上述した「責任開始年月日」を記録するためのものである。
例えば、ＣＰＵ２０３は、証券番号「００００３」によって特定されるトランザクションレコードを記録するため、画面プログラム等から取得したデータに基づいて図３５に示すようなワークレコード３５０１を作成する。図３５において、証券番号３５１として「００００３」が記録され、その枝番３５２として「００３」が記録され、特約「定期保険特約」に対応する約款ＩＤ３５３として「５５５５５」が記録され、データ内容ＩＤを示す変数１〜３＿３５５として「０１」、「０１」、「０５」がそれぞれ記録され、主契約である「個人年金」を示す主約款ＩＤとして「００００５」が記録され、責任開始年月日３１１として日付表示欄３６８に基づいて「２００５年９月２７日」が記録される。
ここで、契約年月日３５９については、当該特約が付加される主契約の約款によってその設定条件が異なるため、約款定義体プログラム３３０５を参照してデータを設定する。例えば、約款ＩＤ「５５５５５」の約款定義体プログラム３３０５を参照する。
５−３−３．処理プログラムの要求
業務プログラム３３０１を実行するＣＰＵ２０３は、約款ＩＤを含むワークレコード３５０１および、オペレータ指示に基づいて特定された処理名を、ラッパープログラムＡ３３０３に引き渡す（ステップＳ３４０５）。例えば、上述したように、保険契約変更画面３６０において特約「定期保険特約」を付加する処理が指示されている場合、作成したワークレコード３５０１をトランザクションデータベース２０９３に書き込む処理を行わなければならない。したがって、ＣＰＵ２０３は、ワークレコード３５０１の必要なすべてのデータ項目を設定するため、契約年月日３５９に記録するデータを取得する動作を行う。
例えば、ＣＰＵ２０３は、ワークレコード３５０１およびメイン処理部３３２１の実行によって取得した処理名である「契約年月日計算」を引き渡す。
５−３−４．ラッパープログラムＡの実行
ラッパープログラムＡ３３０３を実行するＣＰＵ２０３は、処理プログラム要求部３３２５において、業務プログラム３３０１から受け継いだワークレコード３５０１の約款ＩＤ３５３に基づいて約款定義体プログラムを特定し、特定した約款定義体プログラムに対して処理名を引き渡す（ステップＳ３４２１）。
例えば、約款ＩＤ３５３「５５５５５」に基づいて約款定義体プログラム３３０５が特定され、処理名「契約年月日計算」が引き渡される。
５−３−５．約款定義プログラム（特約）の実行
以下、約款ＩＤが「５５５５５」の約款定義体プログラム３３０５に処理コードを引き渡した場合について説明する。引き渡しを受けてＣＰＵ２０３は、約款定義体プログラム３３０５の処理コード記録部３３２７を検索し、受け継いだ処理名に対応する処理コードがあるか否かを判断する（ステップＳ３４４１）。
約款定義体プログラム３３０５の処理コード記録部３３２７に受け継いだ処理名に対応する処理コードが存在せず主約款を参照する旨の記述がある場合には（ステップＳ３４４１、ＮＯ）、ＣＰＵ２０３は他約款定義体参照部３３２９を実行し、ワークレコードの主約款ＩＤおよび処理名をラッパープログラムＢ３３０７に引き渡す（ステップＳ３４４３）。例えば、図３３に示すように、処理コード記録部３３２７に「主約款の規定に準ずる」記述がある場合には、主約款ＩＤ３５７「００００５」および処理名「契約年月日計算」がラッパープログラムＢ３３０７に引き渡される。
なお、受け継いだ処理名に対応する処理コードがあれば（ステップＳ３４４１、ＹＥＳ）、処理プログラム生成部３３２６において処理プログラムを生成する（ステップＳ３４４５）。
５−３−６．ラッパープログラムＢの実行
ラッパープログラムＢ３３０７を実行するＣＰＵ２０３は、処理プログラム要求部３３３１において、約款定義体プログラム３３０５から受け継いだ主約款ＩＤに基づいて他の約款定義体プログラムを特定し、特定した約款定義体プログラムに対して処理名を引き渡す（ステップＳ３４６１）。
例えば、主約款ＩＤ３５７「００００５」に基づいて約款定義体プログラム３３１１が特定され、処理名「契約年月日計算」が引き渡される。
５−３−７．約款定義プログラム（主契約）の実行
引き渡しを受けてＣＰＵ２０３は、約款定義体プログラムの処理プログラム生成部を実行し、処理コード記録部を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ３４８１）。例えば、約款定義体プログラム３３１１の処理コード記録部３３３５においては、契約年月日の計算方法を示す処理コードとして「責任開始年月日の４日後」から計算する旨が記述されている。
処理プログラム生成部３３３３を実行するＣＰＵ２０３は、処理コード記録部から取得した処理コードに基づいて処理プログラムを生成する（ステップＳ３４８３）。
図３７に、生成した処理プログラムの構成例を示す。例えば、処理コード３７３には、「契約年月日計算」を処理するためのプログラムコードが記述されている。なお、このプログラムコードの表現形式は、ソースコードまたはオブジェクトコードのいずれであってもよい。
５−３−８．処理プログラムの引き渡し
約款定義体プログラムを実行するＣＰＵ２０３は、生成した処理プログラムをラッパープログラムＢ３３０７に引き渡す（ステップＳ３４８５）。例えば、約款定義体プログラム３３１１を実行するＣＰＵ２０３は、リダイレクト機能やパイプ機能等を用いて処理プログラム３７０（図３７）を引き渡す処理を行う。
引き渡しを受けて、ラッパープログラムＢ３３０７を実行するＣＰＵ２０３は、受け継いだ処理プログラムを約款定義体プログラム３３０５に引き渡す（ステップＳ３４６３）。引き渡しを受けて、約款定義体プログラム３３０５を実行するＣＰＵ２０３は、受け継いだ処理プログラムをラッパープログラムＡ３３０３に引き渡す（ステップＳ３４４７）。引き渡しを受けて、ラッパープログラムＡ３３０３を実行するＣＰＵ２０３は、受け継いだ処理プログラムを業務プログラム３３０１に引き渡す（ステップＳ３４２３）。
５−３−９．処理プログラムの実行
業務プログラム３３０１においてＣＰＵ２０３は、ラッパープログラムＡ３３０３から受け継いだ処理プログラム３７０を実行し、画面データから取得した特約にかかるトランザクションデータを設定するための契約年月日を取得する（ステップＳ３４０７）。
このとき実行される処理プログラム３７０のフローチャートを図３８に示す。処理プログラム３７０の実行においてＣＰＵ２０３は、業務プログラム３３０１において取得した画面データから責任開始年月日を読み込む（ステップＳ３７０１）。
例えば、図３６の保険契約変更画面３６０における日付表示欄３６８の当日日付データ「２００５年９月２７日」を責任開始年月日として読み込む。次に、ＣＰＵ２０３は、所定のカレンダー計算プログラムにより責任開始年月日の４日後の日付を算出する（ステップＳ３７０３）。例えば、「２００５年９月２７日」の４日後を算出して、「２００５年１０月０１日」を取得する。さらに、ＣＰＵ２０３は、算出した責任開始年月日の４日後の日付を出力する（ステップＳ３７０５）。例えば、「２００５年１０月０１日」をワークエリア３５０１の契約年月日３５９に出力し、図３５のワークレコード３５０３のようにする。
５−３−１０．レコードの更新
処理プログラムの実行を終えると、ＣＰＵ２０３は、ワークレコードに記録されたデータに基づいてトランザクションデータベース２０９３へレコードを追加する（ステップＳ３４０９）。例えば、図３５に示すワークレコード３５０３が、追加される。
５−３−１１．まとめ
以上説明したように、この発明によれば、特約を示す約款定義体プログラムにおいて、主契約の種類に基づいて設定データを判断するロジックを予め組み込んでおく必要がなくなる。このため、主契約の種類が追加された場合であっても、参照先の主契約を指定するだけで、特約のデータを適切に設定ことができる。これにより、保守性を高めたデータ管理装置を提供することができる。
なお、本実施形態の図３３においては、処理プログラム実行部３３２３を業務プログラム３３０１内に位置付けた構成を説明したが、処理プログラム実行部３３２３は、ラッパープログラムＡ３３０３、約款定義体プログラム３３０５、ラッパープログラムＢ３３０７または約款定義体プログラム３３１１のいずれのプログラムに位置付けてもよい。すなわち、実行結果としての契約年月日を業務プログラム３３０１において取得することができれば、処理プログラムはいずれのプログラム内において実行されてもよい。
６．第６の実施形態
上記実施形態においては、トランザクションデータに記録するデータ項目を商品ごとに定義しておき、複数の契約条件にかかる契約内容を、すべての商品に共通なレコードフォーマットを用いて管理する例について説明したが、本実施形態においては、レコードフォーマットの汎用性をさらに高め、記録対象の各データごとにトランザクションデータに記録するデータ項目を任意に設定することのできるデータ管理システムについて説明する。
例えば、従来のデータ管理システムにおいては、保険契約の解約処理の可否を管理する場合には、トランザクションデータ中に解約処理のステータスを管理するデータ項目を設けておき、業務プログラムが当該データを直接参照することによって解約の可否を判断していた。
しかしながら、複数のステータスを管理する場合、トランザクションデータのデータ項目を設定する際には、すべてのステータスを網羅できるように設計しておかなければならない。このため、企業によって使用するステータスが異なることが前提のパッケージソフトの分野においては、汎用性の高いデータ管理の手法が求められていた。本実施形態では、上記の点に鑑みて、データの冗長性を排除した汎用性の高いデータ管理システムについて説明する。
６−１．機能ブロック図
本発明にかかるデータ管理装置１の機能ブロック図は、図１または図２０に示したものと同様である。
６−２．ハードウェア構成
本発明にかかるデータ管理装置１を、ＣＰＵを用いて実現したコンピュータ装置のハードウェア構成の一例は、基本的には図２または図２１に示したものと同様である。
６−３．処理詳細（１）
図３９〜４５を用いて、本実施形態における処理の詳細を説明する。なお、本実施形態においても、業務プログラムは、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。
図３９に、業務プログラム３９０１、ラッパープログラム３９０３および処理ステータス定義体プログラム３９０５、…における機能ブロック図を示す。
業務プログラム３９０１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部３９２１を備えている。
ラッパープログラム３９０３は、処理ステータス定義体プログラム３９０５において生成した処理プログラムの実行結果を取得するための処理プログラム実行結果取得部３９２５を備えている。
処理ステータス定義体プログラム３９０５は、ラッパープログラム３９０３からの要求を受けて処理プログラムを生成して実行するための処理プログラム生成・実行部３９２７と、処理名ごとに処理コードを記録した処理コード記録部３９２８と、処理コードに設定するために用いられるパターン変数データを記録したパターン変数データ記録部３９２９を備えている（例えば、企業ＩＤが「０１」の場合。）。ここで、パターン変数データとは、トランザクションデータに設定可能なパターン変数と変数の組合せを定義したものである。例えば、パターン変数「００２（保全要注意区分）」と組合せ可能な変数は、「０１（保全エラー）」、「０２（保全ウォーニング）」または「９９（要注意解決）」であることを示している。
本実施形態においては、保険証券の紛失によりシステム上において保険契約データの取扱注意を喚起するため、データ項目「保全要注意区分」にデータ内容「保全ウォーニング」を設定する指示をユーザが行う場合について説明する。
図４１〜４３は、上記の場合においてデータ管理装置１で実行される業務プログラム３９０１、ラッパープログラム３９０３および処理ステータス定義体プログラム３９０５のフローチャートの例である。
６−３−１．画面データの取得
図４４に、業務プログラム３９０１におけるメイン処理部３９２１（図３９）の実行によってディスプレイ２０１に表示される保全要注意区分設定画面４４０の例を示す。この画面においては、証券番号の入力欄４４１、契約者名表示欄４４３、…、「保全エラー」設定ラジオボタン４４４、「保全ウォーニング」設定ラジオボタン４４５、「要注意解決」設定ラジオボタン４４６および設定ボタン４４７等が表示される。
データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、「保全エラー」、「保全ウォーニング」または「要注意解決」等によって示される保全要注意区分の設定を指示することができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄４４１に「００００１」を入力し、契約者名や保全要注意区分の設定状況を表示させる。トランザクションデータに何らの保全要注意区分も設定されていなければ、「保全エラー」設定ラジオボタン４４４、「保全ウォーニング」設定ラジオボタン４４５、「要注意解決」設定ラジオボタン４４６はすべて未選択である。
その後、オペレータは、「保全ウォーニング」設定ラジオボタン４４５を選択入力して、設定ボタン４４７を押下することにより、証券番号「００００１」のトランザクションデータの保全要注意区分に「保全ウォーニング」を設定する処理の実行を指示する。
設定ボタン４４７の押下を受けて、メイン処理部３９２１を実行するＣＰＵ２０３は画面データを取得する（ステップＳ４１０１、図４１）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００１」、処理名「保全要注意区分設定」および変数名「保全ウォーニング」を取得する。
６−３−２．パターン変数設定処理
画面データを取得したＣＰＵ２０３は、パターン変数設定処理を実行する（ステップＳ４１０３）。図４１のステップＳ４１０３に示すパターン変数設定処理について、図４２を用いて説明する。
６−３−２−１．ラッパープログラムの起動（業務プログラム）
業務プログラム３９０１においてＣＰＵ２０３は、保険契約のトランザクションレコードを取得し、所定のワークレコードに格納する（ステップＳ４２０１）。例えば、トランザクションデータベース２０９３から証券番号が「００００１」であるレコードを抽出し、図４０に示すワークレコード４００１として取得する。
レコードを取得すると、ＣＰＵ２０３は、取得したワークレコード、所定の処理名および所定の変数名をラッパープログラム３９０３に引き渡す（ステップＳ４２０３）。例えば、上記においては、「保全要注意区分」を設定する処理がなされており、これに連動して設定されるべきデータ内容「保全ウォーニング」に対応する変数をトランザクションデータに設定するためのパターン変数設定処理を実行する。このため、ＣＰＵ２０３は、ラッパープログラム３９０３に「保全要注意区分設定」を処理名として、「保全ウォーニング」を変数名として引き渡す。
６−３−２−２．処理ステータス定義体の特定（ラッパープログラム）
引き渡しを受けてラッパープログラム３９０３は、レコードの企業ＩＤに基づいて特定した処理ステータス定義体プログラム３９０５に、前記レコード、処理名および変数名を引き渡す（ステップＳ４２２１）。
例えば、図４０に示すレコード４００１においては、企業ＩＤ６３０「０１」に基づいて、処理ステータス定義体プログラム３９０５を特定する。また、ＣＰＵ２０３は、上記「保全要注意区分設定」を処理名として、「保全ウォーニング」を変数名として引き渡す。
６−３−２−３．処理プログラムの生成（処理ステータス定義体プログラム）
処理ステータス定義体プログラム３９０５を実行するＣＰＵ２０３は、処理プログラム生成・実行部３９２７において、パターン変数データ記録部３９２９を検索して受け継いだ処理名に対応するパターン変数を取得する（ステップＳ４２４１）。例えば、処理名「保全要注意区分設定」に基づくパターン変数名「保全要注意区分」に対応するパターン変数「００２」３９２９ａを取得する。
次に、ＣＰＵ２０３は、パターン変数データ記録部３９２９を検索して受け継いだ変数名に対応する変数を取得する（ステップＳ４２４３）。例えば、パターン変数名「保全要注意区分」における変数名「保全ウォーニング」に対応する変数「０２」３９２９ｂを取得する。
さらに、ＣＰＵ２０３は、処理コード記録部３９２８を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ４２４４）。処理コード記録部３９２８には、企業ＩＤごとに処理コードが記録されている。例えば、処理ステータス定義体プログラム３９０５を実行するＣＰＵ２０３は、処理名が「保全要注意区分設定」の処理コード３９２８ａを取得する。
処理プログラム生成・実行部３９２７を実行するＣＰＵ２０３は、処理コード記録部３９２８から取得した処理コードと、パターン変数データ記録部３９２９から取得したパターン変数データに基づいて処理プログラムを生成する（ステップＳ４２４５）。
図４５に、生成した処理プログラムの構成例を示す。処理プログラム４５１は、「保全要注意区分設定」を行うための処理プログラムである。また、パターン変数データ４５３は、このときトランザクションデータに設定されるべきパターン変数および変数の組合せデータである。すなわち、この処理プログラムを実行することにより、ワークレコード４００１の所定位置にパターン変数名「保全要注意区分」および変数名「保全ウォーニング」に対応するパターン変数「００２」および変数「０２」を設定することができる。
６−３−２−４．処理プログラムの実行（処理ステータス定義体プログラム）
ＣＰＵ２０３は、生成した処理プログラム４５１を実行する（ステップＳ４２４７）。このとき実行される処理プログラム４５１のフローチャートの例を図４３に示す。
処理プログラム４５１の実行においてＣＰＵ２０３は、処理プログラム内に組み込まれて設定されているパターン変数データからパターン変数および変数を示すデータを読み込む（ステップＳ４３０１）。さらに、メモリ２０５に記憶しているワークレコードを読み込む（ステップＳ４３０３）。例えば、パターン変数「００２」および変数「０２」を読み込み、ワークレコード４００１（図４０）を読み込む。
ＣＰＵ２０３は、パターン変数データから読み込んだパターン変数がワークレコードに存在するか否かを判断する（ステップＳ４３０５）。例えば、パターン変数「００２」に基づいて、ワークレコードのパターン変数１、パターン変数２、パターン変数３…を順次検索し、同一のパターン変数が記録されているか否かを判断する。
ステップＳ４３０７において、ワークレコードのいずれのパターン変数にも読み込んだパターン変数と同一のデータが記録されていなければ、ＣＰＵ２０３は、
パターン変数が未設定である最小のカラムインデックスを有するパターン変数のカラムに、上記において読み込んだパターン変数を設定する（ステップＳ４３０７）。ここで、カラムインデックスとは、ワークレコードのデータ項目であって、「パターン変数ｎ」または「変数ｎ」で示されるカラムｎを特定するものであり、「パターン変数１」または「変数１」のカラムインデックスはそれぞれ「１」で表される。
例えば、ワークレコード４００１において未設定のパターン変数は「０００」で示されており、この場合の変数は「００」である。よって、ＣＰＵ２０３は、ワークレコード４００１において、「パターン変数１」６３１の位置に、読み込んだパターン変数「００２」を設定する。
パターン変数を設定すると、ＣＰＵ２０３は、設定したパターン変数と同一のカラムインデックスを有する変数カラムの位置に、上記において読み込んだ変数を設定する（ステップＳ４３０９）。
例えば、パターン変数１＿６３１にパターン変数「００２」を設定しているため、同一のカラムインデックス「１」を有する変数１＿６３２に、変数「０２」を設定し、ワークレコード４００３のようにする。
なお、上記ステップＳ４３０５において、ワークレコードのいずれかのパターン変数に読み込んだパターン変数と同一のデータが記録されていれば、ＣＰＵ２０３は、当該パターン変数と同一のカラムインデックスを有する変数カラムの位置に、上記において読み込んだ変数を設定する（ステップＳ４３０９）。
図４２のステップＳ４２４９において、処理ステータス定義体プログラム３９０５を実行するＣＰＵ２０３は、上記ステップＳ４２４７の実行結果をラッパープログラム３９０３に通知する（ステップＳ４２４９、図４２）。図４２のステップＳ４２２３において、ラッパープログラム３９０３を実行するＣＰＵ２０３は、受け継いだ上記ステップＳ４２４７の実行結果を業務プログラム３９０１に通知する（ステップＳ４２２３、図４２）。例えば、更新可能フラグ「１（ＯＮ）」を、戻り値として業務プログラム３９０１のプログラムスレッドに返す処理を行う。なお、処理プログラムの実行においてエラーが発生した場合には、更新可能フラグとして戻り値「０（ＯＦＦ）」が返される。
６−３−２−５．レコードの更新
図４１において、パターン変数設定処理（ステップＳ４１０３）の実行を終えると、業務プログラム３９０１を実行するＣＰＵ２０３は、更新可能フラグに基づいて、ワーク領域に記録されているデータに基づいてトランザクションレコードの更新が可能であるか否かを判断する（ステップＳ４１０５）。ＣＰＵ２０３は、更新可能フラグがＯＮであれば、更新可能であると判断してトランザクションデータベース２０９３のトランザクションレコードを更新する（ステップＳ４１０７）。
また、ＣＰＵ２０３は、更新可能フラグがＯＦＦであれば、更新不可能であると判断してディスプレイ２０１に更新が不可能である旨を示すエラーメッセージを出力する（ステップＳ４１０６）。
６−４．処理詳細（２）
上記処理詳細（１）においては、トランザクションデータにパターン変数および変数を設定する例について説明したが、処理詳細（２）においては、予めパターン変数および変数が設定されたトランザクションデータを取り扱う場合について説明する。
図４１ａ、図４２ａ、図４３ａ、図４４ａ、図４５ａ、図３９および図４０等を用いて、本実施形態における処理の詳細（２）を説明する。なお、本実施形態においても、業務プログラムは、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。
本実施形態においては、保険契約の解約処理業務を行う際に、保全要注意区分を参照して、当該保険契約の解約処理が可能であるか否かをチェックする例について説明する。すなわち、証券番号によって特定されるトランザクションデータに設定されたパターン変数および変数に基づいて、パターン変数名「保全要注意区分」における変数名を取得する例について説明する。
図４１ａ〜４３ａは、上記の場合においてデータ管理装置１で実行される業務プログラム３９０１、ラッパープログラム３９０３および処理ステータス定義体プログラム３９０５のフローチャートの例である。
６−４−１．画面データの取得
図４４ａに、業務プログラム３９０１におけるメイン処理部３９２１（図３９）の実行によってディスプレイ２０１に表示される保険契約解約画面４４０ａの例を示す。この画面においては、証券番号の入力欄４４１ａ、契約者名表示欄４４３ａ、…、および解約ボタン４４７ａ等が表示されており、データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、解約処理を指示することができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄４４１ａに「００００１」を入力し、契約者名等を表示させる。
その後、オペレータは、解約ボタン４４７ａを押下することにより、証券番号「００００１」のトランザクションデータに記録されたパターン変数および変数に基づいて保全要注意区分として設定されているデータを取得する。
解約ボタン４４７ａの押下を受けて、メイン処理部３９２１を実行するＣＰＵ２０３は画面データを取得する（ステップＳ４１２１、図４１ａ）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００１」を取得する。
６−４−２．パターン変数取得処理
画面データを取得したＣＰＵ２０３は、パターン変数取得処理を実行する（ステップＳ４１２３）。図４１ａのステップＳ４１２３に示すパターン変数取得処理について、図４２ａを用いて説明する。
６−４−２−１．ラッパープログラムの起動（業務プログラム）
業務プログラム３９０１においてＣＰＵ２０３は、保険契約のトランザクションレコードを取得し、所定のワークレコードに格納する（ステップＳ４２１１）。例えば、トランザクションデータベース２０９３から証券番号が「００００１」であるレコードを抽出し、図４０に示すワークレコード４００３として取得する。
レコードを取得すると、ＣＰＵ２０３は、取得したワークレコード、所定の処理名をラッパープログラム３９０３に引き渡す（ステップＳ４２１３）。例えば、上記においては、トランザクションデータに記録されたパターン変数および変数に基づいて「保全要注意区分」を取得するためのパターン変数取得処理を実行する。このため、ＣＰＵ２０３は、ラッパープログラム３９０３に「保全要注意区分取得」を処理名として引き渡す。
６−４−２−２．処理ステータス定義体の特定（ラッパープログラム）
引き渡しを受けてラッパープログラム３９０３は、レコードの企業ＩＤに基づいて特定した処理ステータス定義体プログラム３９０５に、前記レコードを引き渡す（ステップＳ４２３１）。
例えば、図４０に示すレコード４００３においては、企業ＩＤ６３０「０１」に基づいて、処理ステータス定義体プログラム３９０５を特定する。また、ＣＰＵ２０３は、上記「保全要注意区分取得」を処理名として引き渡す。
６−４−２−３．処理プログラムの生成（処理ステータス定義体プログラム）
処理ステータス定義体プログラム３９０５を実行するＣＰＵ２０３は、処理プログラム生成・実行部３９２７において、パターン変数データ記録部３９２９を検索して受け継いだ処理名に対応するパターン変数にかかるパターン変数データを取得する（ステップＳ４２５１）。例えば、処理名「保全要注意区分取得」に基づくパターン変数名「保全要注意区分」に対応するパターン変数「００２」３９２９ａにかかるパターン変数データを取得する。
次に、ＣＰＵ２０３は、処理コード記録部３９２８を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ４２５４）。処理コード記録部３９２８には、企業ＩＤごとに処理コードが記録されている。例えば、処理ステータス定義体プログラム３９０５を実行するＣＰＵ２０３は、処理名が「保全要注意区分取得」の処理コード３９２８ｂを取得する。
処理プログラム生成・実行部３９２７を実行するＣＰＵ２０３は、処理コード記録部３９２８から取得した処理コードと、パターン変数データ記録部３９２９から取得したパターン変数データに基づいて処理プログラムを生成する（ステップＳ４２５５）。
図４５ａに、生成した処理プログラムの構成例を示す。処理プログラム４５１ａは、「保全要注意区分取得」を行うための処理プログラムである。また、パターン変数データ４５３ａは、このときトランザクションデータに記録されたパターン変数および変数に基づいて取得されるべきパターン変数および変数の組合せデータである。すなわち、この処理プログラムを実行することにより、ワークレコード４００３にパターン変数名「保全要注意区分」が記録されているか否か、および、記録されている場合には、これに対応する変数名を取得することができる。
６−４−２−４．処理プログラムの実行（処理ステータス定義体プログラム）
ＣＰＵ２０３は、生成した処理プログラム４５１ａを実行する（ステップＳ４２５７）。このとき実行される処理プログラム４５１ａのフローチャートの例を図４３ａに示す。
処理プログラム４５１ａの実行においてＣＰＵ２０３は、処理プログラム内に組み込まれて設定されているパターン変数データからパターン変数を示すデータを読み込む（ステップＳ４３２１）。さらに、メモリ２０５に記憶しているワークレコードを読み込む（ステップＳ４３２３）。例えば、パターン変数「００２」を読み込み、ワークレコード４００３（図４０）を読み込む。
ＣＰＵ２０３は、パターン変数データから読み込んだパターン変数と同一のパターン変数をワークレコードから探し当て、当該パターン変数のカラムインデックスと同一のカラムインデックスを有する変数を当該ワークレコードから取得する（ステップＳ４３２５）。
例えば、パターン変数「００２」に基づいて、ワークレコードのパターン変数１、パターン変数２、パターン変数３…を順次検索し、同一のパターン変数が記録されているか否かを判断し、記録されている場合にはこのパターン変数のカラムインデックスを取得する。ワークレコード４００３において、パターン変数１は「００２」であることにより、カラムインデックス１を有する変数１「０２」を取得する。
ＣＰＵ２０３は、ワークレコードから取得した変数に基づいて、処理プログラムのパターン変数データ４５３ａを検索してこれに対応する変数名を取得する（ステップＳ４３２７）。例えば、ワークレコードから変数１「０２」を取得している場合には、パターン変数データ４５３ａから変数「０２」に対応する変数名「保全ウォーニング」４５５ａを取得する。
図４２ａのステップＳ４２５９において、処理ステータス定義体プログラム３９０５を実行するＣＰＵ２０３は、上記ステップＳ４２５７の実行結果をラッパープログラム３９０３に通知する（ステップＳ４２５９、図４２ａ）。図４２ａのステップＳ４２３３において、ラッパープログラム３９０３を実行するＣＰＵ２０３は、受け継いだ上記ステップＳ４２５７の実行結果を業務プログラム３９０１に通知する（ステップＳ４２３３）。
例えば、上記ステップＳ４２５７において取得した変数名「保全ウォーニング」を、戻り値として業務プログラム３９０１のプログラムスレッドに返す処理を行う。なお、処理プログラムの実行において保全要注意区分がトランザクションデータに設定されていないと判断された場合には、例外処理により戻り値「未設定」が返される。
６−４−２−５．レコードの更新
図４１ａにおいて、パターン変数取得処理（ステップＳ４１２３）の実行を終えると、業務プログラム３９０１を実行するＣＰＵ２０３は、戻り値に基づいて、トランザクションレコードについての解約処理が可能であるか否かを判断する（ステップＳ４１２５）。
例えば、ＣＰＵ２０３は、戻り値が「未設定」または「要注意解決」であれば、解約処理が可能であると判断して解約処理を開始する（ステップＳ４１２７）。
一方、戻り値が「保全エラー」または「保全ウォーニング」であれば、エラーメッセージをディスプレイ２０１上に表示して処理を終了する（ステップＳ４１２６）。上記の場合、戻り値が「保全ウォーニング」であることにより、解約処理を行うことができないため、ＣＰＵ２０３はその旨をオペレータに提示する。
６−５．まとめ
以上説明したように、この発明によれば、記録対象の各データごとにトランザクションデータに記録するデータ項目を任意に設定してデータ管理を行うことができる。これにより、トランザクションデータにおけるレコードフォーマットの汎用性をさらに高めることができるとともに、業務プログラムからデータ特性に基づく業務ロジックを排除してメンテナンス性をより一層向上させることができる。特に、パッケージソフトの分野において、業務プログラムのカスタマイズ作業を不要とし、レコードフォーマットのカスタマイズ作業だけでパッケージソフトを複数の企業について適用することができる。このため、開発コストや導入コストを大幅に低減することができる。
なお、上記においては、企業ＩＤごとに処理ステータス定義体プログラムを作成する例について説明したが、他の要件に基づいて処理ステータス定義体プログラムを作成してもよい。例えば、商品コードや企業グループ単位に処理ステータス定義体プログラムを作成してもよい。
７．第７の実施形態
上記第６の実施形態においては、トランザクションデータにデータ項目ＩＤおよびデータ内容ＩＤを記録しておき、これに対応するデータ項目またはデータ内容を取得する例について説明したが、本実施形態においては、データ内容ＩＤに代えてデータ内容をトランザクションデータに記録しておき、データ内容に対するデータ項目を任意に設定することのできるデータ管理システムについて説明する。
例えば、従来のデータ管理システムにおいては、複数種類の所定データ（例えば、金額データ、日付データ等。）を管理する場合、各データ項目をすべてトランザクションデータベースを構成するスキーマに定義しておく必要があった。しかしながら、必要と思われるすべてのデータ項目をスキーマに定義しておくことは、汎用性は高いが冗長なデータ構造となり、データベースの利用効率を低下させる原因となっていた。
このため、企業によって使用するデータ項目の種類が異なることが前提のパッケージソフトの分野においては、汎用性が高くかつ利用効率のよいデータ管理の手法が求められていた。本実施形態では、上記の点に鑑みて、データの冗長性を排除した汎用性の高いデータ管理システムについて説明する。
７−１．機能ブロック図
本発明にかかるデータ管理装置１の機能ブロック図は、図１または図２０に示したものと同様である。
７−２．ハードウェア構成
本発明にかかるデータ管理装置１を、ＣＰＵを用いて実現したコンピュータ装置のハードウェア構成の一例は、基本的には図２または図２１に示したものと同様である。
７−３．処理詳細（１）
図４６〜５２を用いて、本実施形態における処理の詳細を説明する。なお、本実施形態においても、業務プログラムは、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。
図４６に、業務プログラム４６０１、ラッパープログラム４６０３およびデータ項目定義体プログラム４６０５、…における機能ブロック図を示す。
業務プログラム４６０１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部４６２１を備えている。
ラッパープログラム４６０３は、データ項目定義体プログラム４６０５において生成した処理プログラムの実行結果を取得するための処理プログラム実行結果取得部４６２５を備えている。
データ項目定義体プログラム４６０５は、ラッパープログラム４６０３からの要求を受けて処理プログラムを生成して実行するための処理プログラム生成・実行部４６２７と、処理名ごとに処理コードを記録した処理コード記録部４６２８と、処理コードに設定するために用いられるパターン変数データを記録したパターン変数データ記録部４６２９を備えている（例えば、企業ＩＤが「０１」の場合。）。ここで、パターン変数データとは、トランザクションデータにおけるデータ項目を、パターン変数とこれに対応するパターン変数名を用いて定義するものである。例えば、パターン変数「００２」に対応するデータ項目は、パターン変数名「利率基準日」に基づいて定義される。
本実施形態においては、保険契約の解約返戻金を計算する指示をユーザが行う場合について説明する。図４８〜５０は、上記の場合においてデータ管理装置１で実行される業務プログラム４６０１、ラッパープログラム４６０３およびデータ項目定義体プログラム４６０５のフローチャートの例である。
７−３−１．画面データの取得
図５１に、業務プログラム４６０１におけるメイン処理部４６２１（図４６）の実行によってディスプレイ２０１に表示される解約返戻金計算画面５１０の例を示す。この画面においては、証券番号の入力欄５１１、契約者名表示欄５１３、…、解約返戻金表示欄５１５および計算ボタン５１７等が表示される。
データ管理装置１のオペレータは、解約返戻金の計算対象となる証券番号を入力欄５１１に入力して計算ボタン５１７を押下することにより、解約返戻金の計算結果を解約返戻金表示欄５１５に表示させるための指示を行うことができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄５１１に「００００１」を入力し、契約者名等を表示させる。
その後、オペレータは、計算ボタン５１７を押下することにより、証券番号「００００１」についての解約返戻金計算の実行を指示する。
計算ボタン５１７の押下を受けて、メイン処理部４６２１を実行するＣＰＵ２０３は画面データを取得する（ステップＳ４８０１、図４８）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００１」を取得する。
７−３−２．パターン変数名取得処理
画面データを取得したＣＰＵ２０３は、パターン変数名取得処理を実行する（ステップＳ４８０３）。図４８のステップＳ４８０３に示すパターン変数名取得処理について、図４９を用いて説明する。
７−３−２−１．ラッパープログラムの起動（業務プログラム）
業務プログラム４６０１においてＣＰＵ２０３は、保険契約のトランザクションレコードを取得し、所定のワークレコードに格納する（ステップＳ４９０１）。例えば、トランザクションデータベース２０９３から証券番号が「００００１」であるレコードを抽出し、図４７に示すワークレコード４７０１として取得する。
レコードを取得すると、ＣＰＵ２０３は、取得したワークレコード、所定の処理名をラッパープログラム４６０３に引き渡す（ステップＳ４９０３）。例えば、上記においては、トランザクションデータに記録されたパターン変数およびデータに基づいて、解約返戻金計算処理に用いるデータである「利率基準日」および「積立金額」を特定するためのパターン変数名取得処理を実行する。このため、ＣＰＵ２０３は、ラッパープログラム４６０３に「利率基準日取得」および「積立金額取得」を処理名としてそれぞれ引き渡す。
７−３−２−２．データ項目定義体の特定（ラッパープログラム）
引き渡しを受けてラッパープログラム４６０３は、レコードの企業ＩＤに基づいて特定したデータ項目定義体プログラム４６０５に、前記レコードを引き渡す（ステップＳ４９２１）。
例えば、図４７に示すレコード４７０１においては、企業ＩＤ６３０「０１」に基づいて、データ項目定義体プログラム４６０５を特定する。また、ＣＰＵ２０３は、上記「利率基準日取得」および「積立金額取得」を処理名として引き渡す。
７−３−２−３．処理プログラムの生成（データ項目定義体プログラム）
データ項目定義体プログラム４６０５を実行するＣＰＵ２０３は、処理プログラム生成・実行部４６２７において、パターン変数データ記録部４６２９を検索して受け継いだ処理名に対応するパターン変数にかかるパターン変数データを取得する（ステップＳ４９４１）。例えば、処理名「利率基準日取得」に基づくパターン変数名「利率基準日」に対応するパターン変数「００２」４６２９ａおよび、処理名「積立金額取得」に基づくパターン変数名「積立金額」に対応するパターン変数「０１０」４６２９ｂを取得する。
次に、ＣＰＵ２０３は、処理コード記録部４６２８を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ４９４３）。処理コード記録部４６２８には、企業ＩＤごとに処理コードが記録されている。例えば、データ項目定義体プログラム４６０５を実行するＣＰＵ２０３は、処理名が「利率基準日取得」の処理コード４６２８ｂおよび、処理名が「積立金額取得」の処理コード４６２８ａを取得する。
処理プログラム生成・実行部４６２７を実行するＣＰＵ２０３は、処理コード記録部４６２８から取得した処理コードと、パターン変数データ記録部４６２９から取得したパターン変数データに基づいて処理プログラムを生成する（ステップＳ４９４５）。
図５２に、生成した処理プログラムの構成例を示す。処理プログラム５２１は、「利率基準日取得」処理および「積立金額取得」処理を行うための処理プログラムから構成される。また、パターン変数データ５２３および５２５は、このときトランザクションデータに記録されたパターン変数に基づいて取得されるべきパターン変数およびパターン変数名の組合せデータである。すなわち、この処理プログラムを実行することにより、ワークレコード４７０１にパターン変数名「利率基準日」および「積立金額」が記録されているか否か、記録されている場合には、これらに対応するデータ自体を特定して取得することができる。
７−３−２−４．処理プログラムの実行（データ項目定義体プログラム）
ＣＰＵ２０３は、生成した処理プログラム５２１を実行する（ステップＳ４９４７）。このとき実行される処理プログラム５２１のフローチャートの例を図５０に示す。
処理プログラム５２１の実行においてＣＰＵ２０３は、処理プログラム内に組み込まれて設定されているパターン変数データからパターン変数を示すデータを読み込む（ステップＳ５０２１）。さらに、メモリ２０５に記憶しているワークレコードを読み込む（ステップＳ５０２３）。例えば、パターン変数１「００２」を読み込み、ワークレコード４７０１（図４７）を読み込む。
ＣＰＵ２０３は、パターン変数データから読み込んだパターン変数と同一のパターン変数をワークレコードから探し当て、当該パターン変数のカラムインデックスを取得する（ステップＳ５０２５）。例えば、「利率基準日取得」にかかる処理プログラムを実行した場合、パターン変数「００２」に基づいて、ワークレコードのパターン変数１、パターン変数２、パターン変数３…を順次検索し、同一のパターン変数が記録されているか否かを判断し、記録されている場合にはこのパターン変数のカラムインデックスを取得する。ワークレコード４７０１において、パターン変数１は「００２」であることにより、カラムインデックス「１」を取得する。
さらに、ＣＰＵ２０３は、取得したカラムインデックスを有するデータを当該ワークレコードから取得する（ステップＳ５０２７）。例えば、カラムインデックス１を有するデータ１「２００５／０９／０１」を取得する。
同様に、「積立金額取得」にかかる処理プログラムを実行した場合、パターン変数「０１０」に基づいて、ワークレコードのパターン変数１、パターン変数２、パターン変数３…を順次検索し、同一のパターン変数が記録されているか否かを判断し、記録されている場合にはこのパターン変数のカラムインデックスを取得する。ワークレコード４７０１において、パターン変数２は「０１０」であることにより、カラムインデックス「２」を取得する。さらに、ＣＰＵ２０３は、カラムインデックス２を有するデータ２「￥１００，０００」を取得する。
図４９のステップＳ４９４９において、データ項目定義体プログラム４６０５を実行するＣＰＵ２０３は、上記ステップＳ４９４７の実行結果をラッパープログラム４６０３に通知する（ステップＳ４９４９）。図４９のステップＳ４９２３において、ラッパープログラム４６０３を実行するＣＰＵ２０３は、受け継いだ上記ステップＳ４９４７の実行結果を業務プログラム４６０１に通知する（ステップＳ４９２３）。
例えば、上記ステップＳ４９４７において取得したデータ１「２００５／０９／０１」を「利率基準日」として、また、データ２「￥１００，０００」を「積立金額」として、業務プログラム４６０１のプログラムスレッドに返す処理を行う。なお、処理プログラムの実行においてパターン変数がトランザクションデータに設定されていないと判断された場合には、例外処理により戻り値「未設定」が返される。
７−３−２−５．解約返戻金の計算
図４８において、パターン変数名取得処理（ステップＳ４８０３）の実行を終えると、業務プログラム４６０１を実行するＣＰＵ２０３は、戻り値に基づいて、解約返戻金計算処理に必要なデータが取得できたか否かを判断し（ステップＳ４８０５）、取得できれば、当該データに基づいて解約返戻金計算処理を開始する（ステップＳ４８０７）。
例えば、ＣＰＵ２０３は、戻り値として「利率基準日」および「積立金額」にかかるデータが取得できれば、上記データ１「２００５／０９／０１」およびデータ２「￥１００，０００」に基づいて、証券番号「００００１」の保険契約にかかる解約返戻金を計算し、その計算結果を解約返戻金計算画面５１０（図５１）の解約返戻金表示欄５１５に表示する。
一方、ＣＰＵ２０３は、戻り値が「未設定」であれば、解約処理が可能でないと判断して、エラーメッセージをディスプレイ２０１上に表示して処理を終了する（ステップＳ４８０６）。この場合、解約返戻金を計算する処理ができないため、その旨をオペレータに提示して当該処理を終了する。
７−４．その他
上記においては、トランザクションデータに記録された日付形式データ（利率基準日）または金額形式データ（積立金額）を例にして説明したが、他のデータ形式のデータに対しても本発明を適用することができる。例えば、テキスト形式データやバイナリ形式データであってもよい。図４７においては、テキスト形式のデータ３「大阪市中央区…」のデータが記録されており、データ３はパターン変数３「１００」に基づいて、データ項目を「住所」として取り扱われる。
７−５．まとめ
以上説明したように、この発明によれば、記録対象の各データごとにトランザクションデータに記録するデータ項目を任意に設定してデータ管理を行うことができる。これにより、トランザクションデータにおけるレコードフォーマットの冗長性を排除し、汎用性が高くかつ利用効率のよいデータ管理システムを提供することができる。
また、業務プログラムからデータ特性に基づく業務ロジックを排除して、メンテナンス性をより一層向上させることができる。特に、パッケージソフトの分野において、業務プログラムのカスタマイズ作業を不要とし、レコードフォーマットのカスタマイズ作業だけでパッケージソフトを複数の企業について適用することができる。このため、開発コストや導入コストを大幅に低減することができる。
なお、上記においては、企業ＩＤごとにデータ項目定義体プログラムを作成する例について説明したが、他の要件に基づいてデータ項目定義体プログラムを作成してもよい。例えば、商品コードや企業グループ単位にデータ項目定義体プログラムを作成してもよい。
さらに、データ形式ごとにパターン変数のカラムインデックスを設定するようにしてもよい。これにより、同一のデータ形式をデータ項目をグループ化してスキーマ設計を行い、処理速度または処理効率をより向上させることができる。
８．第８の実施形態
上記実施形態においては、所定のデータ項目の所定のデータ内容に対応するデータ内容ＩＤをトランザクションデータに設定する例について説明したが、本実施形態においては、トランザクションデータに記録されたデータ内容ＩＤに基づいてデータ内容を取得し、これに基づいて所定の処理を行う例について説明する。
例えば、従来技術（１）に示したデータ管理システムにおいては、保険商品の解約時における源泉徴収税額を計算する場合、トランザクションデータが示す保険契約が「所定の年金保険」であるか否か、「所定の年金保険」である場合には年金種類が「確定年金」であるか否かを少なくとも判断する必要があった。
しかしながら、上記のような判断ロジックを各業務プログラム内に組み込んだ構成を採用している場合、計算対象となる年金保険の種類が追加されると、判断ロジックを修正する必要が生じ、修正にともなうシステムの動作確認作業が必要となる。このため、システム変更に対するメンテナンスコストが多大に発生することになる。特に、企業によって使用する保険商品や機能要件の異なることを前提とされる業務用パッケージソフト業界においては、運用時のメンテナンスコストのみならず、導入時におけるカスタマイズコストも抑えることのできる汎用性の高いデータ管理手法の採用が求められていた。
本実施形態では、上記の点に鑑みて、商品特性の違うデータを取り扱う場合であっても、判断ロジックの修正に対する影響範囲を最小限に抑えつつ汎用性や可用性を維持することのできるデータ管理システムについて説明する。
８−１．機能ブロック図
本発明にかかるデータ管理装置１の機能ブロック図は、図１または図２０に示したものと同様である。
８−２．ハードウェア構成
本発明にかかるデータ管理装置１を、ＣＰＵを用いて実現したコンピュータ装置のハードウェア構成の一例は、基本的には図２または図２１に示したものと同様である。
８−３．処理詳細（１）
図５３〜５９を用いて、本実施形態における処理の詳細を説明する。なお、本実施形態においても、業務プログラムは、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。
図５３に、業務プログラム５３０１、ラッパープログラム５３０３、約款定義体プログラム５３０５、…およびワーク領域５３０７における機能ブロック図を示す。
業務プログラム５３０１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部５３２１、所定計算処理ごとの計算条件を設定するための条件設定部であるＩ／Ｆ編集クラス５３２３および前記計算条件に基づいて所定の計算処理を行うための計算処理部である計算モデル５３２５を少なくとも１組備えている。なお、Ｉ／Ｆ編集クラスおよび計算モデルの組合せは、処理ごとに１つ作成されており、例えば、当該処理としては、源泉徴収税額計算処理、円転計算処理、遅延利息計算処理または支払額計算処理等が存在する。
ラッパープログラム５３０３は、約款定義体プログラム５３０５に処理プログラムを要求し、これを実行するための処理プログラム要求・実行部５３２７を備えている。
約款定義体プログラム５３０５は、ラッパープログラム５３０３からの要求を受けて処理プログラムを生成するための処理プログラム生成部５３２９と、処理名ごとに処理コードを記録した処理コード記録部５３３１と、処理コードに設定するために用いられる組合せデータを記録した組合せデータ記録部５３３３を備えている（例えば、約款ＩＤが「５５５５５」の場合。）。
ワーク領域５３０７は、各プログラムが取り扱う可能性のあるすべてのデータを包含したデータ格納オブジェクトであって、トランザクションレコードを格納するためのワークレコード５３５１、ユーザインタフェース画面において入力または表示されるデータを格納するための画面入力データ５３５３および各プログラムにおいて出力されたデータを格納するための計算結果データ５３５５から構成される。
本実施形態においては、年金に関する保険商品の解約返戻金額の計算処理時に、同時に処理される源泉徴収税額計算処理について説明する。
図５４〜５７は、上記の場合においてデータ管理装置１で実行される業務プログラム５３０１、ラッパープログラム５３０３および約款定義体プログラム５３０５のフローチャートの例である。
８−３−１．画面データの取得
図５９に、業務プログラム５３０１におけるメイン処理部５３２１（図５３）の実行によってディスプレイ２０１に表示される解約返戻金計算画面５７０の例を示す。この画面においては、日付表示欄５７８、証券番号の入力欄５７１、契約者名表示欄５７３、…、解約返戻金額表示欄５７４、既払い保険料表示欄５７５、源泉領収税額表示欄５７６および計算ボタン５７７等が表示される。
データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、解約返戻金額、既払い保険料および源泉徴収税額の計算を指示することができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄５７１に「００００１」を入力し、契約者名等を表示させる。
その後、オペレータは、計算ボタン５７７を押下することにより、証券番号「００００１」のトランザクションデータについての解約返戻金、既払い保険料および源泉徴収税額を計算する処理の実行を指示する。
計算ボタン５７７の押下を受けて、メイン処理部５３２１を実行するＣＰＵ２０３は画面入力データ５３５３を取得する（ステップＳ５４０１、図５４）。上述したように、解約返戻金計算画面５７０に表示されるデータはすべてワーク領域５３０７の画面入力データ５３５３に格納される。
図５８に、ワーク領域５３０７の構成例を示す。ワークレコード５３５１は、証券番号５８１１、約款ＩＤ５８１３、変数１＿５８１５、…等から構成される。画面入力データ５３５３は、証券番号５８２１、解約年月日５８２３、…等から構成される。計算結果データ５３５５は、解約返戻金額５８３１、既払い保険料５８３３、源泉徴収税額５８３９、…等から構成される。
例えば、ＣＰＵ２０３は、図５８に示すワーク領域のレコード５８０１から証券番号５８２１「００００１」および解約年月日５８２３「２００５年１０月１日」を取得する。なお、解約年月日５８２３「２００５年１０月１日」は、解約返戻金計算画面５７０の日付表示欄５７８から取得されたデータである。
８−３−２．解約返戻金計算処理および既払い保険料計算処理
画面入力データを取得したＣＰＵ２０３は、解約返戻金計算処理および既払い保険料計算処理を実行する（ステップＳ５４０３〜５４０５）。ＣＰＵ２０３は、解約返戻金計算処理によって取得した解約返戻金額をワーク領域５３０７の計算結果データ５３５５に格納する。例えば、図５８のレコード５８０１における解約返戻金額５８３１に「￥１００，０００」を格納する。
また、ＣＰＵ２０３は、既払い保険料計算処理によって取得した既払い保険料をワーク領域５３０７の計算結果データ５３５５に格納する。例えば、図５８のレコード５８０１における既払い保険料５８３３に「￥８０，０００」を格納する。
８−３−３．源泉徴収税額計算処理
解約返戻金計算処理および既払い保険料計算処理を終えると、業務プログラムを実行するＣＰＵ２０３は、源泉徴収税額計算処理を行う（ステップＳ５４０７）。この処理は、源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）および源泉徴収税額計算処理（計算モデル）を順次実行することによって行われる（図５５、Ｓ５４２１〜Ｓ５４２５）。
８−３−３−１．源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）
図５６に、源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）のフローチャートを示す。
８−３−３−１−１．ワーク領域への設定
ＣＰＵ２０３は、ワーク領域５３０７の計算結果データ５３５５から解約返戻金額５８３１を読み込み、モデル用ワーク領域５８９１における入力データの総所得額５８３５に設定する（ステップＳ５５０１、図５６）。例えば、図５８のレコード５８０３に示すように、解約返戻金５８３１「￥１００，０００」を総所得額５８３５「￥１００，０００」に設定する。
ＣＰＵ２０３は、ワーク領域５３０７の計算結果データ５３５５から既払い保険料５８３３を読み込み、モデル用ワーク領域５８９１における入力データの必要経費５８３７に設定する（ステップＳ５５０３）。例えば、図５８のレコード５８０３に示すように、払い保険料５８３３「￥８０，０００」を必要経費５８３７「￥８０，０００」に設定する。
８−３−３−１−２．ラッパープログラムの起動（業務プログラム）
ＣＰＵ２０３は、ワーク領域５３０７のワークレコード５３５１を読み込んで当該保険契約にかかるトランザクションレコードを取得し、当該保険契約が「一時払いである」および「契約後５年以内の解約である」という条件を満たすか否かを判断する（ステップＳ５５０５〜５５０７）。上記条件を満たしていれば、Ｉ／Ｆ編集クラス５３２３を実行するＣＰＵ２０３は、ワーク領域５３０７に記録されている約款ＩＤおよび所定の処理名を、ラッパープログラム５３０３に引き渡す（ステップＳ５５０９）。例えば、上記においては、解約返戻金計算処理にともなう源泉徴収税額を計算するため、ＣＰＵ２０３は、ワーク領域５３０７の約款ＩＤ５８１３「５５５５５」とともに、Ｉ／Ｆ編集クラス５３２３において設定された処理名である「年金種類取得」を引き渡す。
８−３−３−１−３．ラッパープログラム
ラッパープログラム５３０３を実行するＣＰＵ２０３は、処理プログラム要求・実行部５３２７において、業務プログラム５３０１から受け継いだ約款ＩＤに基づいて約款定義体プログラム５３０５を特定し、特定した約款定義体プログラム５３０５にアクセスして処理名を引き渡す（ステップＳ５５２１）。
８−３−３−１−４．約款定義体プログラム
引き渡しを受けてＣＰＵ２０３は、約款定義体プログラム５３０５の処理プログラム生成部５３２９を実行し、受け継いだ処理名に対応する処理コードを処理コード記録部５３３１から取得するとともに、受け継いだ処理名に対応する契約内容および契約内容ＩＤの組合せデータを組合せデータ記録部５３３３から取得する。さらに、約款定義体プログラム５３０５を実行するＣＰＵ２０３は、取得した処理コードおよび組合せデータに基づいて処理プログラムを生成し、生成した処理プログラムをラッパープログラム５３０３に引き渡す（ステップＳ５５４１）。なお、ステップＳ５５４１における処理は、図２５に示した契約内容取得処理のフローチャートのステップＳ２５４１〜Ｓ２５４７の処理と同様である。
８−３−３−１−５．処理プログラムの実行（ラッパープログラム）
ラッパープログラム５３０３においてＣＰＵ２０３は、約款定義体プログラム２０９６から受け継いだ処理プログラムを実行する（ステップＳ５５２３）。このとき実行される処理プログラムのフローチャートは、図２６に示したものと同様である。処理プログラムの実行によって、ＣＰＵ２０３は、ワーク領域５３０７から入力した契約内容ＩＤに対応する契約内容を取得する。例えば、図３０に示した処理プログラムの組合せデータから、契約内容ＩＤ「０１」に対応する契約内容「確定年金」を取得する。
ラッパープログラム５５０３を実行するＣＰＵ２０３は、実行結果を業務プログラム５３０１に通知する（ステップＳ５５２５、図５５）。例えば、「年金種類＝確定年金」を、戻り値として業務プログラム５３０１のＩ／Ｆ編集クラス５３２３にかかるプログラムスレッドに返す処理を行う。これにより、当該保険契約にかかる「年金種類」は「確定年金」であることが認識される。
８−３−３−１−６．源泉分離課税対象フラグの設定（Ｉ／Ｆ編集クラス）
Ｉ／Ｆ編集クラス５３２３を実行するＣＰＵ２０３は、ラッパープログラム５３０３からの通知を受けて、年金種類が確定年金であるか否かを判断する（ステップＳ５５１１）。上述したように、「年金種類＝確定年金」が戻り値として返されている場合には、モデル用ワーク領域５８９１における入力データの源泉分離課税対象フラグ５８４１をＯＮに設定する（ステップＳ５５１３）。
なお、年金種類が、「終身年金」等のように確定年金以外であった場合には、源泉分離課税対象フラグ５８４１は、初期値としてのＯＦＦが設定されている状態となる。
８−３−３−２．源泉徴収税額計算処理（計算モデル）
解約返戻金計算処理（Ｉ／Ｆ編集クラス）の実行を終えると、業務プログラムを実行するＣＰＵ２０３は、源泉徴収税額計算処理（計算モデル）を実行する（図５５、Ｓ５４２３）。図５７において、ＣＰＵ２０３は、モデル用ワーク領域５８９１から源泉分離課税対象フラグ５８４１を読み込み、源泉分離課税対象フラグがＯＮであるか否かを判断し、ＯＮであれば、ワーク領域５３０７から総所得額および必要経費を読み込む（ステップＳ５６００〜Ｓ５６０３）。例えば、図５８に示したレコード５８０３の総所得額５８３５「￥１００，０００」および必要経費５８３７「￥８０，０００」を読み込む。
総所得額および必要経費を読み込むと、ＣＰＵ２０３は、所定の計算式に基づいて源泉徴収税額を計算する（ステップＳ５６０５）。例えば、計算式「 源泉徴収税額 ＝ （総所得額−必要経費） × ０．２ 」に基づいて、源泉分離課税対象の解約返戻金に対する税額を計算する。
ＣＰＵ２０３は、算出した源泉徴収税額を、モデル用ワーク領域５８９１における出力データの源泉徴収税額５８４３に出力する（ステップＳ５６０７）。例えば、図５８のレコード５８０３に示すように、算出した源泉徴収税額「￥４，０００」を、源泉徴収税額５８４３に格納する。
なお、ステップＳ５６０１において、源泉分離課税対象フラグ５８４１がＯＦＦに設定されている場合には、上記処理をスキップして当該処理を終了する。
８−３−３−３．源泉徴収税額の出力
源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）および源泉徴収税額計算処理（計算モデル）を順次実行すると、ＣＰＵ２０３は、モデル用ワーク領域５８９１に出力した源泉徴収税額５８４３を、ワーク領域５３０７における計算結果データ５３５５の源泉徴収税額５８３９に出力する（ステップＳ５４２５）。例えば、図５８のレコード５８０１に示すように、源泉徴収税額５８３９に、レコード５８０３から読み込んだ源泉徴収税額５８４３「￥４，０００」を格納する。
８−３−４．画面表示（業務プログラム）
業務プログラム５３０１のメイン処理部５３２１を実行するＣＰＵ２０３は、ワーク領域５３０７に格納した解約返戻金額、既払い保険料および源泉徴収税額を、解約返戻金計算画面５７０に表示する（ステップＳ５４１１）。例えば、図５８に示すレコード５８０１の約返戻金額５８３１「￥１００，０００」、既払い保険料５８３３「￥８０，０００」および源泉徴収税額５８３９「￥４，０００」を、図５９に示す解約返戻金計算画面５７０の解約返戻金額表示欄５７４、既払い保険料表示欄５７５、源泉領収税額表示欄５７６にそれぞれ表示する。
８−３−５．まとめ
このように、Ｉ／Ｆ編集クラス５３２３において約款定義体プログラム５３０５にアクセスし、所望の約款ＩＤにかかる所望の契約内容を取得することにより、業務アプリケーションのメイン処理部側で保険商品を判断する必要がなくなる。これにより、商品の契約条件の差異に影響を受けることなく、システムの可用性および汎用性を維持することができる。すなわち、保険商品が追加された場合であっても、判断ロジックの修正を行わずにシステムを利用し続けることができ、メンテナンスコストやカスタマイズコストを抑制することができる。
８−４．処理詳細（２）
上記処理詳細（１）においては、１つの計算処理について、条件設定を行う「Ｉ／Ｆ編集クラス」と計算処理を行う「計算モデル」を用いて構造的な処理を行うように構成している。これにより、「計算モデル」を普遍的な計算式のみで構成することができる。例えば、上記においては、源泉徴収税額計算についての「計算モデル」として、計算式「源泉徴収税額＝（総所得額−必要経費）×０．２」を用いている。このような計算式は、法令等によって定められるものであって、いずれの企業においても普遍的に使用されるものである。
処理詳細（２）においては、異なる業務アプリケーション間において、上記源泉徴収税額計算に代表されるＩ／Ｆ編集クラスおよび計算モデルを共用する例について説明する。例えば、保険業界においては、支払開始日前に積立金の一部を引き出すことによって、一部のみを解約として取り扱う「減額」という処理が存在する。このような「減額」の場合にも、減額部分に対しての解約返戻金額が発生するため、源泉徴収税額計算が行われる。以下、減額処理にかかる業務アプリケーションを実行する例について説明する。
図５４ａおよび図５９ａをさらに用いて、本実施形態における処理の詳細を説明する。なお、本実施形態においても、業務プログラムは、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。図５４ａは、上述した減額の場合における業務プログラム５３０１のフローチャートの例である。
８−４−１．画面データの取得
図５９ａに、業務プログラム５３０１におけるメイン処理部５３２１（図５３）の実行によってディスプレイ２０１に表示される減額分解約返戻金計算画面５９０の例を示す。この画面においては、日付表示欄５９８、証券番号の入力欄５９１、契約者名表示欄５９３、減額後積立金額表示欄５９８、…、減額分解約返戻金額表示欄５９４、減額分既払い保険料表示欄５９５、源泉領収税額表示欄５９６および計算ボタン５９７等が表示される。
データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、解約返戻金額、既払い保険料および源泉徴収税額の計算を指示することができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄５９１に「００００１」を入力し、契約者名等を表示させる。
その後、オペレータは、計算ボタン５９７を押下することにより、証券番号「００００１」のトランザクションデータについての減額分解約返戻金、減額分の既払い保険料および源泉徴収税額を計算する処理の実行を指示する。
計算ボタン５９７の押下を受けて、メイン処理部５３２１を実行するＣＰＵ２０３は画面入力データ５３５３を取得する（ステップＳ５４０１、図５４ａ）。上述したように、減額分解約返戻金計算画面５９０に表示されるデータはすべてワーク領域５３０７の画面入力データ５３５３に格納される。
図５８に、ワーク領域５３０７の構成例を示す。ワークレコード５３５１は、証券番号５８１１、約款ＩＤ５８１３、変数１＿５８１５、…等から構成される。画面入力データ５３５３は、証券番号５８２１、解約年月日５８２３、…等から構成される。計算結果データ５３５５は、解約返戻金額５８３１、既払い保険料５８３３、源泉徴収税額５８３９…等から構成される。
例えば、ＣＰＵ２０３は、図５８に示すワーク領域のレコード５８０１から証券番号５８２１「００００１」および解約年月日５８２３「２００５年１０月１日」を取得する。なお、解約年月日５８２３「２００５年１０月１日」は、解約返戻金計算画面５９０の日付表示欄５９８から取得されたデータである。
８−４−２．減額分解約返戻金計算処理および減額分既払い保険料計算処理
画面入力データを取得したＣＰＵ２０３は、減額後積立金額表示欄５９８に入力された減額後積立金額に基づいて、減額分解約返戻金計算処理および減額分既払い保険料計算処理を実行する（ステップＳ５４０４〜５４０６）。ＣＰＵ２０３は、減額分解約返戻金計算処理によって取得した減額分解約返戻金額をワーク領域５３０７の計算結果データ５３５５に格納する。例えば、図５８のレコード５８０１における解約返戻金額５８３１に「￥１００，０００」を格納する。
また、ＣＰＵ２０３は、減額分既払い保険料計算処理によって取得した減額分既払い保険料をワーク領域５３０７の計算結果データ５３５５に格納する。例えば、図５８のレコード５８０１における既払い保険料５８３３に「￥８０，０００」を格納する。
８−４−３．源泉徴収税額計算処理
解約返戻金計算処理および既払い保険料計算処理を終えると、業務プログラムを実行するＣＰＵ２０３は、源泉徴収税額計算処理を行う（ステップＳ５４０７、図５４ａ）。この処理は、源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）および源泉徴収税額計算処理（計算モデル）を順次実行することによって行われる（図５５、Ｓ５４２１〜Ｓ５４２５）。ここで、源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）および源泉徴収税額計算処理（計算モデル）を含む源泉徴収税額計算処理のフローチャートは、処理詳細（１）の図５５〜５７に示したものと同様である。
８−４−４．画面表示（業務プログラム）
業務プログラム５３０１のメイン処理部５３２１を実行するＣＰＵ２０３は、ワーク領域５３０７に格納した解約返戻金額、既払い保険料および源泉徴収税額を、減額分解約返戻金計算画面５９０に表示する（ステップＳ５４１１）。例えば、図５８に示すレコード５８０１の約返戻金額５８３１「￥１００，０００」、既払い保険料５８３３「￥８０，０００」および源泉徴収税額５８３９「￥４，０００」を、図５９に示す減額分解約返戻金計算画面５９０の減額分解約返戻金額表示欄５９４、減額分既払い保険料表示欄５９５、源泉領収税額表示欄５９６にそれぞれ表示する。
８−４−５．まとめ
このように、通常の解約処理と上記減額処理においては、処理内容が異なるものであるが、各処理に共通して使用されるデータ格納オブジェクトであるワーク領域の計算結果データを使用することにより、解約処理と減額処理の計算処理を共通化することができる。すなわち、異なる業務アプリケーション間において、上記源泉徴収税額計算に代表されるＩ／Ｆ編集クラスおよび計算モデルを共用することができる。
これにより、業務アプリケーションのメイン処理部側で保険商品を判断する必要がなくなるとともに、処理機能部品の共通化を図ることができる。したがって、商品特性の差異のみならず、業務アプリケーションの機能要件の差異についての修正を行った場合であっても、修正に対する影響範囲を最小限に抑えることができ、汎用性や可用性を維持することのできるデータ管理システムを提供することができる。
８−５．処理詳細（３）
上記処理詳細（２）においては、１つの計算処理について、条件設定を行う「Ｉ／Ｆ編集クラス」と計算処理を行う「計算モデル」を用いて構造的な処理を行うように構成するとともに、データ格納オブジェクトであるワーク領域の同一エリアにＩ／Ｆ編集クラスおよび計算モデルの入出力データをセットすることにより、業務アプリケーションの機能要件の差異を吸収し、可用性および汎用性を維持している。
処理詳細（３）においては、さらにＩ／Ｆ編集クラスにおいても業務アプリケーションの機能要件の差異を吸収させる構成を採用して、より可用性および汎用性を高めることのできるデータ管理システムについて説明する。
図５４ｂ、図５６ａ、図５８ａおよび図６０〜図６３をさらに用いて、本実施形態における処理の詳細を説明する。なお、本実施形態においても、業務プログラムは、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。
図５４ｂは、「外貨年金保険」を取り扱う場合における業務プログラム５３０１のフローチャートの例である。なお、「外貨年金保険」とは、資金を米国債などで運用する外貨建ての個人年金保険等である。この場合の解約返戻金額や既払い保険料は外貨建てで計算されるが、源泉徴収税額は円転された解約返戻金額および既払い保険料に基づいて邦貨建てで計算される。
８−５−１．画面データの取得
図６０に、業務プログラム５３０１におけるメイン処理部５３２１（図５３）の実行によってディスプレイ２０１に表示される外貨年金解約返戻金計算画面６００の例を示す。この画面においては、日付表示欄６０８、証券番号の入力欄６０１、契約者名表示欄６０３、…、解約返戻金額表示欄６０４、既払い保険料表示欄６０５、源泉領収税額表示欄６０６および計算ボタン６０７等が表示される。
データ管理装置１のオペレータは、所定の証券番号によって特定される生命保険契約にかかるトランザクションデータについて、外貨建ての解約返戻金額、外貨建ての既払い保険料および邦貨建ての源泉徴収税額の計算を指示することができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄６０１に「００００１」を入力し、契約者名等を表示させる。
その後、オペレータは、計算ボタン６０７を押下することにより、証券番号「００００１」のトランザクションデータについての解約返戻金、既払い保険料および源泉徴収税額を計算する処理の実行を指示する。
計算ボタン６０７の押下を受けて、メイン処理部５３２１を実行するＣＰＵ２０３は画面入力データ５３５３を取得する（ステップＳ５４０１、図５４ｂ）。上述したように、外貨年金解約返戻金計算画面６００に表示されるデータはすべてワーク領域５３０７の画面入力データ５３５３に格納される。
図５８ａに、ワーク領域５３０７の構成例を示す。ワークレコード５３５１は、証券番号５８１１、約款ＩＤ５８１３、変数１＿５８１５、…等から構成される。画面入力データ５３５３は、証券番号５８２１、解約年月日５８２３、…等から構成される。計算結果データ５３５５は、解約返戻金額５８３１、解約返戻金額（円相当額）５８３２、既払い保険料５８３３、既払い保険料（円相当額）５８３４、源泉徴収税額５８３９…等から構成される。
例えば、ＣＰＵ２０３は、図５８ａに示すワーク領域のレコード５８０５から証券番号５８２１「００００１」および解約年月日５８２３「２００５年１０月１日」を取得する。なお、解約年月日５８２３「２００５年１０月１日」は、外貨年金解約返戻金計算画面６００の日付表示欄６０８から取得されたデータである。
８−５−２．解約返戻金計算処理および既払い保険料計算処理
画面入力データを取得したＣＰＵ２０３は、解約返戻金計算処理および既払い保険料計算処理を実行する（ステップＳ５４０３〜５４０５、図５４ｂ）。ＣＰＵ２０３は、解約返戻金計算処理によって取得した解約返戻金額をワーク領域５３０７の計算結果データ５３５５に格納する。例えば、図５８ａのレコード５８０５における解約返戻金額５８３１に「＄９０４」を格納する。
また、ＣＰＵ２０３は、既払い保険料計算処理によって取得した既払い保険料をワーク領域５３０７の計算結果データ５３５５に格納する。例えば、図５８ａのレコード５８０５における既払い保険料５８３３に「＄７２３」を格納する。
このように、米国ドル（＄）建てで運用を行う外貨年金の場合には、解約返戻金額および既払い保険料は、米国ドル（＄）で計算される。
８−５−３．円転計算処理
解約返戻金計算処理および既払い保険料計算処理を終えると、業務プログラムを実行するＣＰＵ２０３は、円転計算処理を行う（ステップＳ５４０８、図５４ｂ）。この処理は、円転計算処理（Ｉ／Ｆ編集クラス）および円転計算処理（計算モデル）を順次実行することによって行われる（図６１、Ｓ６１０１〜Ｓ６１０５）。これらの処理は、上記において計算した外貨建ての解約返戻金額および既払い保険料を邦貨（円）に転換するための計算処理である。
８−５−３−１．円転計算処理（Ｉ／Ｆ編集クラス）
図６２に、円転計算処理（Ｉ／Ｆ編集クラス）におけるフローチャートを示す。
８−５−３−１−１．ラッパープログラムの起動（業務プログラム）
円転計算処理を実行するＣＰＵ２０３は、ワーク領域５３０７のワークレコード５３５１を読み込んで当該保険契約にかかるトランザクションレコードを取得し、約款ＩＤおよび所定の処理名を、ラッパープログラム５３０３に引き渡す（ステップＳ６２０１）。例えば、上記においては、円転計算処理にともなう約定通貨を判断するため、ＣＰＵ２０３は、ワーク領域５３０７の約款ＩＤ５８１３「５５５５５」とともに、円転計算処理にかかるＩ／Ｆ編集クラスにおいて設定された処理名である「約定通貨取得」を引き渡す。
８−５−３−１−２．ラッパープログラム
ラッパープログラム５３０３を実行するＣＰＵ２０３は、処理プログラム要求・実行部５３２７において、業務プログラム５３０１から受け継いだ約款ＩＤに基づいて約款定義体プログラム５３０５を特定し、特定した約款定義体プログラム５３０５にアクセスして処理名を引き渡す（ステップＳ６２２１）。
８−５−３−１−３．約款定義体プログラム
引き渡しを受けてＣＰＵ２０３は、約款定義体プログラム５３０５の処理プログラム生成部５３２９を実行し、受け継いだ処理名に対応する処理コードを処理コード記録部５３３１から取得するとともに、受け継いだ処理名に対応する契約内容および契約内容ＩＤの組合せデータを組合せデータ記録部５３３３から取得する。さらに、約款定義体プログラム５３０５を実行するＣＰＵ２０３は、取得した処理コードおよび組合せデータに基づいて処理プログラムを生成し、生成した処理プログラムをラッパープログラム５３０３に引き渡す（ステップＳ６２４１）。なお、ステップＳ６２４１における処理は、図２５に示した契約内容取得処理のフローチャートのステップＳ２５４１〜Ｓ２５４７の処理と基本的に同様であるが、上記ステップＳ６２４１では契約内容として所定の約定通貨を記録している点が異なる。
８−５−３−１−４．処理プログラムの実行（ラッパープログラム）
ラッパープログラム５３０３においてＣＰＵ２０３は、約款定義体プログラム２０９６から受け継いだ処理プログラムを実行する（ステップＳ６２２３）。このとき実行される処理プログラムのフローチャートは、図２６に示したものと基本的に同様である。
処理プログラムの実行によって、ＣＰＵ２０３は、ワーク領域５３０７から入力した契約内容ＩＤに対応する契約内容を取得する。例えば、処理プログラムの組合せデータから、契約内容ＩＤ「０２」に対応する契約内容「米国ドル（ＵＳＤ）」を取得する。
ラッパープログラム５３０３を実行するＣＰＵ２０３は、実行結果を業務プログラム５３０１に通知する（ステップＳ６２２５）。例えば、「約定通貨＝米国ドル（ＵＳＤ）」を、戻り値として業務プログラム５３０１のＩ／Ｆ編集クラス５３２３にかかるプログラムスレッドに返す処理を行う。これにより、当該保険契約にかかる「約定通貨」は「米国ドル（ＵＳＤ）」であることが認識される。
８−５−３−１−５．モデル用ワーク領域への設定
ＣＰＵ２０３は、上記においてラッパープログラムから取得した約定通貨を、モデル用ワーク領域２＿５８９２に設定する（ステップＳ６２０４、図６２）。例えば、図５８ａのレコード５８０７に示すように、約定通貨５８５１に「米国ドル（ＵＳＤ）を設定する。
ＣＰＵ２０３は、ワーク領域５３０７の計算結果データ５３５５から解約返戻金額５８３１を読み込み、モデル用ワーク領域２＿５８９２における入力データの外貨金額１＿５８５３に設定する（ステップＳ６２０５）。例えば、図５８ａのレコード５８０７に示すように、解約返戻金額５８３１「９０４」を外貨金額１＿５８５３「９０４」に設定する。
ＣＰＵ２０３は、ワーク領域５３０７の計算結果データ５３５５から既払い保険料５８３３を読み込み、モデル用ワーク領域２＿５８９２における入力データの外貨金額２＿５８５５に設定する（ステップＳ６２０７）。例えば、図５８ａのレコード５８０７に示すように、既払い保険料５８３３「７２３」を外貨金額２＿５８５５「７２３」に設定する。
ＣＰＵ２０３は、モデル用ワーク領域２＿５８９２における入力データの円転対象フラグ５８５７をＯＮに設定する（ステップＳ６２０９）。
なお、約定通貨が、「円」のように外貨でない場合には、円転対象フラグ５８５７は、初期値としてのＯＦＦが設定されている状態となる。
８−５−３−２．円転計算処理（計算モデル）
円転計算処理（Ｉ／Ｆ編集クラス）の実行を終えると、業務プログラムを実行するＣＰＵ２０３は、円転計算処理（計算モデル）を実行する（図６１、Ｓ６１０３）。図６３に円転計算処理（計算モデル）のフローチャートを示す。この図において、ＣＰＵ２０３は、モデル用ワーク領域２＿５８９２から円転対象フラグを読み込み、円転対象フラグがＯＮであるか否かを判断し、ＯＮであれば、ワーク領域５３０７から外貨金額１および外貨金額２、…を読み込む（ステップＳ６３０１〜Ｓ６３０５）。例えば、図５８ａに示したレコード５８０７の外貨金額１＿５８５３「９０４」および外貨金額２＿５８５５「７２３」、…を読み込む。
外貨金額を読み込むと、ＣＰＵ２０３は、さらにモデル用ワーク領域２＿５８９２から約定通貨５８５１を読み込み、所定のテーブルから円換算レートを取得する（ステップＳ６３０７）。例えば、「米国ドル（ＵＳＤ）」に対応する円換算レートを読み込む。
次に、ＣＰＵ２０３は、読み込んだ各外貨金額についての円相当額を計算し、モデル用ワーク領域に出力する（ステップＳ６３０９〜Ｓ６３１１）。例えば、外貨金額１にステップＳ６３０７で取得した円換算レートを乗じることにより、外貨金額１に対応する円相当額１を計算する。このように、ＣＰＵ２０３は、解約返戻金額（外貨金額１）および既払い保険料（外貨金額２）に対する円相当額（円相当額１または円相当額２）を計算することができる。
なお、ステップＳ６３０３において、円転対象フラグ５８５７がＯＦＦに設定されている場合には、上記処理をスキップして当該処理を終了する。
８−５−４．源泉徴収税額計算処理（円転対応）
円転計算処理を終えると、業務プログラムを実行するＣＰＵ２０３は、源泉徴収税額計算処理（円転対応）を行う（ステップＳ５４０９、図５４ｂ）。この処理は、処理詳細（１）の場合と同様に、源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）および源泉徴収税額計算処理（計算モデル）を順次実行することによって行われる（図５５、Ｓ５４２１〜Ｓ５４２５）。
８−５−４−１．源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）
図５６ａに、処理詳細（３）における源泉徴収税額計算処理（Ｉ／Ｆ編集クラス）のフローチャートを示す。
８−５−４−１−１．約定通貨の取得
ＣＰＵ２０３は、ワーク領域５３０７のワークレコード５３５１を読み込んで当該保険契約にかかるトランザクションレコードを取得し、約款ＩＤおよび所定の処理名を、ラッパープログラム５３０３に引き渡すことにより、約定通貨を取得する処理を行う（ステップＳ５７０１、Ｓ５７２１〜Ｓ５７２５、Ｓ５７４１）。なお、これらの処理は、上記円転計算処理におけるステップＳ６２０１、Ｓ６２２１〜Ｓ６２２５、Ｓ６２４１（図６２）に示したものと同様である。
例えば、円転計算処理（Ｉ／Ｆ編集クラス）を実行するＣＰＵ２０３は、約款ＩＤ５８１３「５５５５５」および処理名である「約定通貨取得」をラッパープログラム５３０３に引き渡すことにより、「約定通貨＝米国ドル（ＵＳＤ）」を、戻り値として取得する。
８−５−４−１−２．ワーク領域への設定
ＣＰＵ２０３は、ラッパープログラム５３０３から取得した戻り値に基づいて、当該ワークレコード５３５１にかかる保険契約の約定通貨が外貨であるか否かを判定する（ステップＳ５７０３）。
Ｓ５７０３において、約定通貨が外貨であると判定した場合には、ワーク領域５３０７における計算結果データ５３５５の解約返戻金額（円相当額）５８３２を読み込み、モデル用ワーク領域５８９１における入力データの総所得額５８３５に設定する（ステップＳ５７０５、図５６ａ）。例えば、図５８ａのレコード５８０３に示すように、解約返戻金（円相当額）５８３２「￥１００，０００」を総所得額５８３５「￥１００，０００」に設定する。
ＣＰＵ２０３は、ワーク領域５３０７の計算結果データ５３５５から既払い保険料（円相当額）５８３４を読み込み、モデル用ワーク領域５８９１における入力データの必要経費５８３７に設定する（ステップＳ５７０７）。例えば、図５８ａのレコード５８０３に示すように、既払い保険料５８３３（円相当額）「￥８，０００」を必要経費５８３７「￥８，０００」に設定する。
一方、Ｓ５７０３において、約定通貨が外貨でないと判定した場合には、処理詳細（１）と同様に、ワーク領域５３０７における計算結果データ５３５５の解約返戻金額５８３１を読み込み、モデル用ワーク領域５８９１における入力データの総所得額５８３５に設定し、既払い保険料５８３３を読み込み、モデル用ワーク領域５８９１における入力データの必要経費５８３７に設定する（ステップＳ５７０６、Ｓ５７０８）。
８−５−４−１−３．ステップＳ５７０９〜Ｓ５７１７（図５６ａ）
ステップＳ５７０９〜Ｓ５７１７の処理は、処理詳細（１）において説明した図５６のＳ５５０５〜Ｓ５５１３の処理と同様である。すなわち、ＣＰＵ２０３は、当該保険契約が「一時払いである」および「契約後５年以内の解約である」という条件を満たす場合には、さらに約款ＩＤにかかる年金種類を取得して、年金種類が確定年金であれば、モデル用ワーク領域５８９１の源泉分離課税対象フラグ５８４１をＯＮに設定する。
８−５−４−２．源泉徴収税額計算処理（計算モデル）
解約返戻金計算処理（Ｉ／Ｆ編集クラス）の実行を終えると、処理詳細（１）と同様に、業務プログラムを実行するＣＰＵ２０３は、源泉徴収税額計算処理（計算モデル）を実行する（図６１、Ｓ６１０３）。
なお、源泉徴収税額計算処理（計算モデル）は、処理詳細（１）の図５７に示したものと同様である。よって、ＣＰＵ２０３は、算出した源泉徴収税額を、モデル用ワーク領域５８９１における出力データの源泉徴収税額５８４３に出力する（ステップＳ６１０５）。
８−５−５．画面表示（業務プログラム）
業務プログラム５３０１のメイン処理部５３２１を実行するＣＰＵ２０３は、ワーク領域５３０７に格納した解約返戻金額、既払い保険料および源泉徴収税額を、外貨年金解約返戻金計算画面６００に表示する（ステップＳ５４１１、図５４ｂ）。例えば、図５８ａに示すレコード５８０５の約返戻金額５８３１「＄９０４」、既払い保険料５８３３「＄７２３」および源泉徴収税額５８３９「￥４，０００」を、図６０に示す解約返戻金計算画面６００の解約返戻金額表示欄６０４、既払い保険料表示欄６０５、源泉領収税額表示欄６０６にそれぞれ表示する。
８−５−６．まとめ
このように、業務アプリケーションにおいて、特定の計算を行う処理機能をメイン処理部から独立させ、「Ｉ／Ｆ編集クラス」および「計算モデル」として構成することにより、商品特性の差異の吸収と機能要件の差異の吸収を局所化することができる。
これにより、商品特性の異なる商品を追加した場合であっても、また機能要件の異なる機能を追加した場合であっても、業務アプリケーション全体に影響を与えることなく修正作業を行うことができる。したがって、可用性および汎用性を高めることのできるデータ管理システムを提供することができる。
また、データ格納オブジェクトを用いて各業務アプリケーション間のインターフェイスを統一することにより、商品特性の差異の吸収と機能要件の差異の吸収をより階層的に制御することを可能としている。
９．第９の実施形態
上記第１〜８の実施形態においては、取り扱うデータ項目が互いに異なる複数の商品を含むトランザクションデータを管理する例について説明したが、本実施形態においては、このようなトランザクションデータを取り扱うアプリケーションプログラムについて説明する。
例えば、各トランザクションデータを個別に修正するための修正画面アプリケーションについて考える。上述したように、各トランザクションデータに記録される保険商品は約款ＩＤによってその商品特性が決定付けられるものであるため、約款ＩＤが異なると修正対象として画面表示させるべきデータ項目が異なる。このため、修正画面アプリケーションを作成する場合においては、各約款ＩＤごとに修正画面を作成しておくか、すべての約款ＩＤに共通して対応できるような修正画面を作成しておくといった方策が考えられる。
しかしながら、このような方策を採用した場合、取り扱う保険商品やそのデータ項目が変動すると、同時に修正画面の修正作業を行わなければならず煩雑である。このため、システム変更に対するメンテナンスコストが多大に発生する要因となり得る。特に、企業によって使用する保険商品や機能要件の異なることが前提のパッケージソフトの分野においては、運用時のメンテナンスコストのみならず、導入時におけるカスタマイズコストも抑えることのできる汎用性の高いデータ管理手法の採用が求められていた。
本実施形態では、上記の点に鑑みて、商品特性が異なる複数の保険商品やそのデータ項目の変動について容易に対応することのできるアプリケーションプログラムを備えたデータ管理装置について説明する。
なお、第４の実施形態と同様に、第１〜３の実施形態において説明した「商品定義データ」については、本実施形態においては「約款定義データ」と読み替えて説明する。
９−１．機能ブロック図
本発明にかかるデータ管理装置１の機能ブロック図を図１ａに示す。この図において、データ管理装置１は、図１に示した入力手段１１、データ記録部１３、データ処理手段１５、データ定義部１７および表示手段１９に加えて、表示形式定義部２０を備えている。
表示形式定義部２０は、データ処理手段１５における処理結果であるデータ内容またはデータ内容ＩＤについての表示形式を記録する。表示手段１９は、表示形式定義部２０に記録された表示形式に基づいてデータ内容またはデータ内容ＩＤを表示する。
９−２．ハードウェア構成
本発明にかかるデータ管理装置１を、ＣＰＵを用いて実現したコンピュータ装置のハードウェア構成の一例を図２ａに示す。この図において、データ管理装置１は、図２と同様に、ディスプレイ２０１、ＣＰＵ２０３、メモリ２０５、キーボード／マウス２０７、ハードディスク２０９、ＣＤ−ＲＯＭドライブ２１１および通信回路２１５を備えている。
ハードディスク２０９は、図２に示した業務アプリケーションプログラム２０９１、トランザクションデータベース２０９３、約款定義体プログラム２０９４に加えて、表示形式テーブル２０９８を記録している。
９−３．処理詳細（１）
図６４〜７２を用いて、本実施形態における処理の詳細を説明する。なお、本実施形態においても、業務プログラムは、生命保険の契約データおよび商品データを管理するためのアプリケーションプログラムである。
図６４に、業務プログラム６４０１、ラッパープログラムＡ６４０３、ラッパープログラムＢ６４０４、約款定義体プログラム６４０５、…および表示形式テーブル６４０７における機能ブロック図を示す。
業務プログラム６４０１は、画面処理などのユーザインタフェースやデータベースに関する処理を実行するためのメイン処理部６４２１を備えている。
ラッパープログラムＡ６４０３は、約款定義体プログラム６４０５に処理プログラムを要求し、これを実行するための処理プログラム要求・実行部６４２３を備えている。
約款定義体プログラム６４０５は、ラッパープログラムＡ６４０３からの要求を受けて処理プログラムを生成するための処理プログラム生成部６４２７と、処理名ごとに処理コードを記録した処理コード記録部６４２９と、処理コードに設定するために用いられる組合せデータを記録した組合せデータ記録部６４３０を備えている（例えば、約款ＩＤが「１１１１１」の場合。）。
ラッパープログラムＢ６４０４は、所定の契約条件を画面に表示させるための表示形式６４２３を表示形式テーブル６４０７から取得するための表示形式取得部６４２５を備えている。
本実施形態においては、所定の保険契約のトランザクションデータについて記録されている任意の契約条件をダイレクトに修正することのできる個別修正アプリケーションの画面表示処理について説明する。
図６５〜図６７および図７２は、上記の場合においてデータ管理装置１で実行される業務プログラム６４０１、ラッパープログラムＡ６４０３、ラッパープログラムＢ６４０４または約款定義体プログラム６４０５のフローチャートの例である。
９−３−１．画面データの取得
図６８に、業務プログラム６４０１におけるメイン処理部６４２１（図６４）の実行によってディスプレイ２０１に表示される個別修正画面６８０の例を示す。この画面においては、第１エリア６８０１に証券番号の入力欄６８１が表示され、第２エリア６８０２に契約年月日表示欄６８３、年金種類表示欄６８４、年金支払期間表示欄６８５および告知年月日表示欄６８６、…等が表示される。なお、個別修正画面６８０の初期画面においては、第１エリア６８０１のみにデータが表示され、第２エリアにはいずれのデータも表示されない。
データ管理装置１のオペレータは、個別修正の対象となる証券番号を入力欄６８１に入力してデータ呼出ボタン６８２を押下することにより、入力した証券番号にかかるトランザクションデータに基づく個別修正データを表示させるための指示を行うことができる。例えば、オペレータはキーボード／マウス２０７を用いて、証券番号の入力欄６８１に「００００１」を入力し、データ呼出ボタン６８２を押下することにより、証券番号「００００１」についての個別修正データを呼び出すための処理の実行を指示する。
データ呼出ボタン６８２の押下を受けて、メイン処理部６４２１を実行するＣＰＵ２０３は画面データを取得する（ステップＳ６５０１、図６５）。例えば、ＣＰＵ２０３は画面データとして、証券番号「００００１」を取得する。
９−３−２．ラッパープログラムＡの起動（業務プログラム）
業務プログラム６４０１においてＣＰＵ２０３は、保険契約のトランザクションレコードを取得し、所定のワークレコードに格納する（ステップＳ６５０３）。例えば、トランザクションデータベース２０９３から証券番号が「００００１」であるレコードを抽出し、図７１に示すワークレコード７１０１として取得する。
レコードを取得すると、ＣＰＵ２０３は、取得したワークレコードおよび所定の処理名をラッパープログラムＡ６４０３に引き渡す（ステップＳ６５０５）。例えば、上記においては、証券番号にかかる保険契約のトランザクションデータにおいて記録されたデータ項目（契約条件）についてのデータ（契約内容）の個別修正処理を実行する。このため、ＣＰＵ２０３は、ラッパープログラムＡ６４０３に「データ項目取得」を処理名として引き渡す。
９−３−３．約款定義体の特定（ラッパープログラムＡ）
引き渡しを受けてラッパープログラムＡ６４０３は、約款ＩＤに基づいて特定した約款定義体プログラムに、業務プログラム６４０１から取得した処理名を引き渡す（ステップＳ６５２１）。
例えば、図７１に示すレコード７１０１においては、約款ＩＤ７１３「１１１１１」に基づいて、約款定義体プログラム６４０５を特定する。また、ＣＰＵ２０３は、上記「データ項目取得」を処理名として引き渡す。
９−３−４．処理コードおよび組合せデータの取得（約款定義体プログラム）
以下、約款ＩＤが「１１１１１」の約款定義体プログラム６４０５に処理コードを引き渡した場合について説明する。引き渡しを受けてＣＰＵ２０３は、約款定義体プログラム６４０５の処理プログラム生成部６４２７を実行し、処理コード記録部を検索して受け継いだ処理名に対応する処理コードを取得する（ステップＳ６５４１）。処理コード記録部６４２９には、処理名ごとに処理コードが記録されている。例えば、ＣＰＵ２０３は処理名が「データ項目取得」の処理コード６４２９ａをサーチ処理等により取得する。
ＣＰＵ２０３は、処理コード６４２９内に記録されている「変数ｎと契約条件の関係テーブル」６９１ａ（図６９）を参照して、当該処理コードの実行時に用いるすべての契約条件を取得し、取得した各契約条件にかかる契約内容および契約内容ＩＤの組合せデータを、組合せデータ記録部６４３０から取得する（ステップＳ６５４３）。
組合せデータ記録部６４３０には、契約条件（データ項目）ごとに組合せデータが記録されている。例えば、ＣＰＵ２０３は、当該約款ＩＤにおいて設定可能なすべての契約条件（データ項目）についての組合せデータ「年金種類」６４３０ａ、「支払期間」６４３０ｂ、…を取得する。
９−３−５．処理プログラムの生成（約款定義体プログラム）
ＣＰＵ２０３は、処理コード記録部から取得した処理コードと、組合せデータ記録部から取得した組合せデータに基づいて処理プログラムを生成する（ステップＳ６５４５）。図６９に、生成した処理プログラムの構成例を示す。処理プログラム６９０は、処理コード６９１、組合せデータ６９２および組合せデータ６９３、…から構成されている。例えば、処理コード６９１には、すべての契約条件（データ項目）について選択可能なすべての契約内容を取得するためのプログラムコードが記述されている。なお、このプログラムコードの表現形式は、ソースコードまたはオブジェクトコードのいずれであってもよい。
また、組合せデータ６９２および組合せデータ６９３、…には、すべての契約条件（データ項目）について選択可能なすべての契約内容を取得するためのプログラムコードが使用する契約内容ＩＤおよび契約内容の組合せデータが記述されている。なお、この組合せデータの表現形式は、契約内容ＩＤに対応する契約内容が上記プログラムコードの実行時において判断できるものであればよい。例えば、配列形式やテーブル形式等の表現形式がこれに該当する。
９−３−６．処理プログラムの引き渡し
約款定義体プログラム６４０５を実行するＣＰＵ２０３は、生成した処理プログラム６９０をラッパープログラムＡ６４０３に引き渡す（ステップＳ６５４７）。例えば、ＣＰＵ２０３は、リダイレクト機能やパイプ機能等を用いて処理プログラム６９０を引き渡す処理を行う。
９−３−７．処理プログラムの実行
ラッパープログラムＡ６４０３の実行においてＣＰＵ２０３は、約款定義体プログラム６４０５から受け継いだ処理プログラム６９０を実行し、画面データから取得した証券番号によって特定される約款ＩＤに設定可能なすべての契約条件および、当該契約条件において選択可能なすべての契約内容を取得する（ステップＳ６５２３）。
このとき実行される処理プログラム６９０のフローチャートを図６７に示す。処理プログラム５９０の実行においてＣＰＵ２０３は、ローカル変数ｎに１を代入する（ステップＳ６７０１）。ここで、ローカル変数ｎとは、「変数ｎ」というトランザクションデータのデータ項目を特定するための変数値である。例えば、ローカル変数ｎが１の場合には、「変数ｎ」は「変数１」として取り扱われる。
ＣＰＵ２０３は、処理プログラム６９０に格納されている「変数ｎと契約条件の関係テーブル」６９１ａから「変数ｎ」に対応する「契約条件」を読み込む（ステップＳ６７０３）。例えば、図６９における処理コード６９１の関係テーブル６９１ａの「変数１」に対応して記録されている「年金種類」を読み込む。
ＣＰＵ２０３は、上記において読み込んだ契約条件にかかる組合せデータをすべて読み込む（ステップＳ６７０５）。例えば、図６９における組合せデータ６９２の「年金種類」について記録されている契約内容ＩＤと契約内容の組合せをすべて読み込む。
ＣＰＵ２０３は、読み込んだ契約条件と契約内容を、「契約条件と契約内容の関係テーブル」に出力する。例えば、図６７の「契約条件と契約内容の関係テーブル」６７０に示すように、契約条件が「年金種類」の場合には、契約内容として「確定年金」および「保証期間付終身年金」が出力される。
ＣＰＵ２０３は、個別修正画面６８０の初期値を設定するため、ワークレコードにおける変数ｎに記録された契約内容ＩＤに対応する契約内容を判断し、判断した契約内容と同一の契約内容を「契約条件と契約内容の関係テーブル」６７０上において検索し、当該契約内容に対応させて選択フラグを記録する。
例えば、図７１に示したワークレコードのレコード７１０１において、「年金種類」の契約内容ＩＤを記録する変数１＿７１９は「０１」であり、図６９に示した「年金種類」の組合せデータ６９２において、契約内容ＩＤが「０１」の契約内容は「確定年金」であることにより、ＣＰＵ２０３は、「契約条件と契約内容の関係テーブル」６７０において、契約内容「確定年金」に対応させて選択フラグを記録する。これにより、個別修正画面６８０における「年金種類」の初期値を「確定年金」として表示させることができる。
ＣＰＵ２０３は、ローカル変数ｎにｎ＋１を代入する（ステップＳ６７１１）。例えば、代入により「変数１」を「変数２」とする。
ＣＰＵ２０３は、変数ｎについての契約条件が「変数ｎと契約条件の関係テーブル」６９１ａに存在するか否かを判断し、存在すればステップＳ６７０３に戻って上記処理を繰り返す（ステップＳ６７１３、ＹＥＳ）。例えば、「変数２」は、「変数ｎと契約条件の関係テーブル」６９１ａに存在しているため、「変数２」に対応する契約条件「支払期間」についてステップＳ６７０３から処理を行う。
契約条件「支払期間」についてステップＳ６７０７を行うことにより、図６７の「契約条件と契約内容の関係テーブル」６７０に示すように、契約条件に「支払期間」が出力され、契約内容に「終身」、「５年」、「１０年」、「１５年」および「２０年」が出力される。
契約条件「支払期間」についてステップＳ６７０９を行うことにより、図７１に示したワークレコードのレコード７１０１において、「支払期間」の契約内容ＩＤを記録する変数２＿７２１は「０２」であり、図６９に示した「支払期間」の組合せデータ６９２３おいて、契約内容ＩＤが「０２」の契約内容は「５年」であることにより、ＣＰＵ２０３は、「契約条件と契約内容の関係テーブル」６７０において、契約内容「５年」に対応させて選択フラグを記録する。
なお、変数ｎについての契約条件が存在しなくなれば、当該処理を終了する（ステップＳ６７１３、ＮＯ）。
９−３−８．実行結果の通知
ラッパープログラムＡ６４０３を実行するＣＰＵ２０３は、実行結果を業務プログラム６４０１に通知する（ステップＳ６５２５、図６５）。例えば、上述した「契約条件と契約内容の関係テーブル」６７０を、戻り値として業務プログラム６４０１のプログラムスレッドに返す処理を行う。
９−３−９．表示形式の取得
「契約条件と契約内容の関係テーブル」６７０を受けて、メイン処理部６４２１を実行するＣＰＵ２０３は、ラッパープログラムＢ６４０４に「契約条件と契約内容の関係テーブル」６７０を引き渡す（ステップＳ６６０１、図６６）。例えば、図７０に示す「契約条件と契約内容の関係テーブル」６７０が引き渡される。
ラッパープログラムＢ６４０４を実行するＣＰＵ２０３は、受け継いだ「契約条件と契約内容の関係テーブル」６７０における各契約条件に基づいて、表示形式テーブル６４０７を参照し、当該契約条件に対応付けて記録されている表示形式を取得する（ステップＳ６６２１）。ここで、表示形式テーブル６４０７は、所定の契約条件についての契約内容を示すデータを画面に表示させるための表示形式を定義したテーブルである。
例えば、図７０に示す「契約条件と契約内容の関係テーブル」６７０における契約条件「年金種類」７０１に基づいて、同表示形式テーブル６４０７を参照し、契約条件「年金種類」の契約内容を示すデータを表示させるための表示形式として「ドロップダウンメニュー」７０５を取得する。
ＣＰＵ２０３は、受け継いだ「契約条件と契約内容の関係テーブル」６７０におけるすべての契約条件について表示形式を取得し、取得した各表示形式をデータ列として、「契約条件と契約内容の関係テーブル」６７０における各契約条件に対応させて追加する。例えば、図７０のテーブル７００に示すように、「契約条件と契約内容の関係テーブル」６７０の各契約条件ごとの表示形式を追加する。
ラッパープログラムＢ６４０４を実行するＣＰＵ２０３は、表示形式を追加した「契約条件と契約内容の関係テーブル」を、業務プログラム６４０１のメイン処理部６４２１に引き渡す（ステップＳ６６２３）。例えば、図７０に示した「表示形式を追加した契約条件と契約内容の関係テーブル」７００を、戻り値として業務プログラム６４０１のプログラムスレッドに返す処理を行う。
９−３−１０．ＵＩ（User Interface）画面の生成
「表示形式を追加した契約条件と契約内容の関係テーブル」７００を受けて、ＣＰＵ２０３は、トランザクションデータにかかるＵＩ画面を生成する（ステップＳ６６０３）。例えば、「表示形式を追加した契約条件と契約内容の関係テーブル」７００に基づいて、個別修正画面の第２エリア６８０２を生成する。
ＵＩ画面の生成において、ＣＰＵ２０３は、図７１のトランザクションデータに示した変数ｎ（ｎ＝１，２，…）のデータ項目については、下記に示すＵＩ画面生成処理を実行することにより、画面生成を行う。なお、契約年月日７１５および告知年月日７２３等については、トランザクションデータのデータ項目名に基づいて表示形式テーブル６４０７から取得した表示形式に基づいて、データ値の画面出力を行う。例えば、契約年月日７１５（図７１）のデータ値「２００５／０７／１５」は、契約年月日の表示形式「ＹＹＹＹ年ＭＭ月ＤＤ」に基づいて編集され「２００５年７月１５日」として出力される。
図７２に、ステップＳ６６０３におけるＵＩ画面生成処理の詳細フローチャートを示す。ＣＰＵ２０３は、「表示形式を追加した契約条件と契約内容の関係テーブル」７００から契約条件を１件読み込む（ステップＳ７２０１）。例えば、契約条件「年金種類」を読み込む。
ＣＰＵ２０３は、「表示形式を追加した契約条件と契約内容の関係テーブル」７００から読み込んだ契約条件に対応して記録された表示形式を読み込む（ステップＳ７２０３）。例えば、「年金種類」にかかる表示形式「ドロップダウンメニュー」を読み込む。
ＣＰＵ２０３は、「表示形式を追加した契約条件と契約内容の関係テーブル」７００から読み込んだ契約条件にかかる契約内容をすべて読み込む（ステップＳ７２０５）。例えば、「年金種類」にかかる契約内容「確定年金」および「保証期間付終身年金」を読み込む。
ＣＰＵ２０３は、読み込んだ契約条件および契約内容を、上記ステップＳ７２０３において読み込んだ表示形式に基づいて編集する（ステップＳ７２０７）。例えば、契約条件「年金種類」にかかる契約内容「確定年金」および「保証期間付終身年金」を、表示形式「ドロップダウンメニュー」に基づいて編集する。すなわち、「年金種類」を選択するためのドロップダウンメニューに、「確定年金」および「保証期間付終身年金」を選択項目としてセットする。
ＣＰＵ２０３は、「表示形式を追加した契約条件と契約内容の関係テーブル」７００から読み込んだ契約内容にかかる選択フラグを読み込み、選択フラグがセットされている契約内容を、表示形式に基づいて編集した選択項目の初期値としてセットする（ステップＳ７２０９）。例えば、「年金種類」にかかる契約内容「確定年金」に選択フラグがセットされていることにより、「年金種類」を選択するためのドロップダウンメニューにおける契約内容の初期値を「確定年金」とする。
ＣＰＵ２０３は、上記において編集した契約条件および契約内容をＵＩ生成画面にデータ出力する（ステップＳ７２１１）。例えば、図６８の個別修正画面６８０の第２エリア６８０２の年金種類表示欄６８４に示すように、年金種類にかかるドロップダウンメニューの初期値を「確定年金」として出力する。
ＣＰＵ２０３は、「表示形式を追加した契約条件と契約内容の関係テーブル」７００に記録されたすべての契約条件について上記ステップＳ７２０１〜Ｓ７２１１を繰り返す（ステップＳ７２１３）。これにより、トランザクションデータにおける変数ｎにかかるすべてのデータ項目についてＵＩ画面を生成する。
ＣＰＵ２０３は、トランザクションデータのすべてのデータ項目についてのＵＩ画面生成処理を終えると、生成したＵＩ画面を個別修正画面としてディスプレイ２０１に出力する（図６６、ステップＳ６６０５）。例えば、図６８の個別修正画面６８０に示すように、契約年月日、年金種類、年金支払期間、告知年月日等を表示する。
９−４．処理詳細（２）
上記処理詳細（１）においては、証券番号「００００１」のトランザクションデータに記録された約款ＩＤ「１１１１１」にかかる保険商品（例えば、年金保険。）についての個別修正画面を生成する例について説明した。
処理詳細（２）においては、証券番号「００００９」のトランザクションデータに記録された約款ＩＤ「９９９９９」にかかる別の保険商品（例えば、終身保険。）についての個別修正画面を生成する例について説明する。なお、処理詳細（２）においては、基本的には処理詳細（１）と同様のプログラムを用いて処理を行うため、以下、処理詳細（１）と相違する点を明確にする意図をもって説明する。
９−４−１．画面データの取得
図６８ａに、業務プログラム６４０１におけるメイン処理部６４２１（図６４）の実行によってディスプレイ２０１に表示される個別修正画面６８０の例を示す。この画面においては、第１エリア６８０１に証券番号の入力欄６８１が表示され、第２エリア６８０２に契約年月日表示欄６８３、リビングニーズ特約表示欄６８７、長期入院特約表示欄６８８および告知年月日表示欄６８６、…等が表示される。
データ管理装置１のオペレータは、キーボード／マウス２０７を用いて、証券番号の入力欄６８１に「００００９」を入力し、データ呼出ボタン６８２を押下することにより、証券番号「００００９」についての個別修正データを呼び出すための処理の実行を指示する。
９−４−２．ラッパープログラムＡの起動（業務プログラム）
業務プログラム６４０１においてＣＰＵ２０３は、トランザクションデータベース２０９３から証券番号が「００００９」であるレコードを抽出し、図７１に示すワークレコード７１０２として取得し、ラッパープログラムＡ６４０３に、取得したワークレコード７１０２と処理名「データ項目取得」を引き渡す。
９−４−３．約款定義体の特定（ラッパープログラムＡ）
引き渡しを受けてラッパープログラムＡ６４０３は、レコード７１０２の約款ＩＤ７１３「９９９９９」に基づいて、約款定義体プログラムを特定し、約款ＩＤ「９９９９９」と処理名「データ項目取得」を特定した約款定義体プログラムに引き渡す。
９−４−４．処理コードおよび組合せデータの取得（約款定義体プログラム）
引き渡しを受けてＣＰＵ２０３は、約款ＩＤ「９９９９９」にかかる約款定義体プログラムの処理プログラム生成部を実行し、処理コード記録部を検索して受け継いだ処理名「データ項目取得」に対応する処理コードを取得する。
ＣＰＵ２０３は、処理コード内に記録されている「変数ｎと契約条件の関係テーブル」６９１ｂ（図６９ａ）を参照して、当該処理コードの実行時に用いるすべての契約条件を取得し、取得した各契約条件にかかる契約内容および契約内容ＩＤの組合せデータを、組合せデータ記録部から取得する。例えば、ＣＰＵ２０３は、当該約款ＩＤにおいて設定可能なすべての契約条件（データ項目）についての組合せデータ「リビングニーズ特約」、「長期入院特約」、…を取得する。
９−４−５．処理プログラムの生成
ＣＰＵ２０３は、処理コード記録部から取得した処理コードと、組合せデータ記録部から取得した組合せデータに基づいて、図６９ａにその構成を示す、処理プログラムを生成する。当該処理プログラムは、処理コード６９１と「リビングニーズ特約」の組合せデータ６９４および「長期入院特約」の組合せデータ６９５、…から構成される。
９−４−６．処理プログラムの引き渡し
約款定義体プログラムを実行するＣＰＵ２０３は、生成した処理プログラム６９０をラッパープログラムＡ６４０３に引き渡す。
９−４−７．処理プログラムの実行
ラッパープログラムＡ６４０３の実行においてＣＰＵ２０３は、約款定義体プログラムから受け継いだ処理プログラム６９０を実行し、画面データから取得した証券番号「００００９」によって特定される約款ＩＤ「９９９９９」に設定可能なすべての契約条件（「リビングニーズ特約」、「長期入院特約」、…）および、当該各契約条件において選択可能なすべての契約内容（「あり」、「なし」または「なし」、「５０日以上」、「１００日以上」）を取得する。
９−４−８．実行結果の通知
ラッパープログラムＡ６４０３を実行するＣＰＵ２０３は、「契約条件と契約内容の関係テーブル」を、戻り値として業務プログラム６４０１のプログラムスレッドに返す処理を行う。
９−４−９．表示形式の取得
「契約条件と契約内容の関係テーブル」を受けて、メイン処理部６４２１を実行するＣＰＵ２０３は、ラッパープログラムＢ６４０４に「契約条件と契約内容の関係テーブル」を引き渡し、各契約条件に基づいて、表示形式テーブル６４０７を参照し、当該契約条件に対応付けて記録されている表示形式を取得する。
例えば、「契約条件と契約内容の関係テーブル」における契約条件「リビングニーズ特約」に基づいて、表示形式テーブル６４０７を参照し、契約条件「リビングニーズ特約」の契約内容を示すデータを表示させるための表示形式として「ドロップダウンメニュー」を取得する。
ラッパープログラムＢ６４０４を実行するＣＰＵ２０３は、表示形式を追加した「契約条件と契約内容の関係テーブル」を、業務プログラム６４０１のメイン処理部６４２１に引き渡す。
９−４−１０．ＵＩ（User Interface）画面の生成
「表示形式を追加した契約条件と契約内容の関係テーブル」を受けて、ＣＰＵ２０３は、図６８ａに示す個別修正画面６８０の第２エリア６８０２を生成する。
ＵＩ画面の生成において、ＣＰＵ２０３は、図７１のトランザクションデータに示した変数ｎ（ｎ＝１，２，…）のデータ項目については、処理詳細（１）において示したＵＩ画面生成処理を実行することにより、画面生成を行う。
ＣＰＵ２０３は、トランザクションデータのすべてのデータ項目についてのＵＩ画面生成処理を終えると、生成したＵＩ画面を個別修正画面としてディスプレイ２０１に出力し、図６８ａの個別修正画面６８０に示すように、契約年月日、リビングニーズ特約、長期入院特約、告知年月日等を表示する。
このように、証券番号によって特定される約款ＩＤが異なる場合であっても、約款定義体において管理されている各契約条件（データ項目）についてのみを個別修正画面の表示データとして設定することができる。
９−５．まとめ
以上説明したように、この発明によれば、約款定義体プログラムに基づいたデータ主導型のＵＩ画面生成処理が可能となる。これにより、取り扱う保険商品やそのデータ項目が変動する場合にあっても、修正画面アプリケーションに変更を加えることなく利用することができ、システム変更に対するメンテナンスコストを大幅に抑制することができる。
また、企業によって使用する保険商品や機能要件の異なることが前提のパッケージソフトの分野においても、運用時のメンテナンスコストのみならず、導入時におけるカスタマイズコストも抑えることのできる汎用性の高いデータ管理手法を提供することができる。
９−６．その他
上記においては、約款ＩＤにかかるすべての契約条件を画面に表示するように構成したが、業務プログラム側で表示させるべき契約条件を取捨選択するようにしてもよい。
上記においては、約款ＩＤにかかる契約条件についての選択可能な契約内容の初期値を、トランザクションデータに記録された変数データに基づいて設定するように構成したが、トランザクションデータが存在しない場合には、契約内容を表示せず契約条件のみを表示するようにしてもよい。例えば、データの新規登録時における入力画面がこれに該当する。なお、この場合、業務プログラムにおいて指定された所定の契約内容を初期値として採用してもよい。
上記においては、約款ＩＤにかかる契約条件についての契約内容を画面に表示するように構成したが、契約内容ＩＤのみ、または、契約内容ＩＤと契約内容とを同時に表示するようにしてもよい。
上記においては、約款ＩＤにかかる契約条件についての契約内容を画面に表示する例として、ドロップダウンメニューおよびラジオボタンを提示したが、他の入力表示フォームを用いてもよい。例えば、テキストボックス、チェックボックス等を用いてもよい。
上記においては、約款ＩＤにかかる契約条件についての契約内容を画面に表示する例として、表示形式としてドロップダウンメニューまたはラジオボタン等を指定するように構成したが、表示形式の中に表示色、表示サイズ、表示桁数または表示位置等を含めてもよい。
上記においては、システム全体で１つの表示形式テーブルを用いる構成を示したが、企業ＩＤごとに表示形式テーブルを作成しておき、トランザクションデータに記録された企業ＩＤに基づいて表示形式を選択して使用するようにしてもよい。また、企業ＩＤに代えて約款ＩＤ、ユーザＩＤまたはその他のＩＤを用いてもよい。
１０．その他の実施形態
１０−１．処理コードの共通化
上記第１の実施形態においては、データ項目ごとに作成された処理コードと組合せデータに基づいて処理プログラムを作成するように構成したが、処理コードを共通化して作成しておき、種類ＩＤに対応するデータ項目および変数位置を処理コードに組み込んで、データ項目に対応する処理コードを生成するようにしてもよい。例えば、「年金種類設定」を行う場合には、処理名からデータ項目「年金種類」を特定するとともに変数位置「変数１」を特定し、これらの情報を設定用の処理コードに組み込むようにすればよい。
１０−２．装置構成の分散化
上記第１の実施形態においては、データ管理装置１の内部においてインストールされた業務プログラム２０９１および商品定義体プログラム２０９４を用いて装置を構成したが、それぞれのプログラムを別のコンピュータ装置にインストールして構成してもよい。この場合、業務プログラム２０９１を実行するコンピュータ装置からの要求を受けて、商品定義体プログラム２０９４を実行するコンピュータ装置が処理プログラムを生成する。これにより、商品管理と処理プログラムの生成を行うコンピュータ装置によって分散処理を図ることができ、各コンピュータ装置における処理負荷を減らすことができる。
なお、商品定義体プログラム２０９４を実行するコンピュータ装置を構成する場合、データ内容ＩＤとデータ内容の対応表を記録したデータ定義部は組合せデータ記録部７３５（図７）により、処理コードを記録した処理定義部は処理コード記録部７３３（図７）によりそれぞれ実現可能である。また、指定処理によって特定される対応表取得手段、処理コードを取得する処理コード取得手段および対応表と処理コードに基づいてプログラムを生成するプログラム生成手段は、処理プログラム生成部７３１（図７）によりそれぞれ実現可能である。
１０−３．商品定義の階層化
上記第１の実施形態の図７および上記第２の実施形態の図９においては、約款ＩＤ（種類ＩＤ）ごとに作成された商品定義体プログラムを用いて装置を構成したが、すべての約款ＩＤ（種類ＩＤ）に共通する１つの商品定義体プログラムを用いてもよい。
この場合における商品定義体プログラムの機能ブロック図の例を図１１に示す。図１１に示すように、本発明の商品定義体プログラムは、処理プログラム生成部１１０および、第１階層１１１、第２階層１１２、第３階層１１３から構成される。第１階層は、商品カテゴリーごとに、処理コード記録部および組合せデータ記録部が記録され、第２階層は、約款種類ごとに、処理コード記録部および組合せデータ記録部が記録され、第３階層は、約款バージョンごとに、処理コード記録部および組合せデータ記録部が記録されている。
ここで、商品カテゴリー、約款種類および約款バージョンとは、約款ＩＤに基づいて定まるものである。例えば、約款ＩＤの上１桁目と２桁目は商品カテゴリーを示し、同上３桁目と４桁目は約款種類を示し、同５桁目と６桁目は約款バージョンを示す場合、約款ＩＤ「０１０１０１」は、商品カテゴリー「０１」１１１１、約款種類「０１」１１２１、約款バージョン「０１」１１３１をそれぞれ特定することができる。
上記のような構成において、第３階層は第２階層を、第２階層は第１階層をそれぞれ継承できるようにオブジェクト指向言語を用いて作成しておく。すなわち、第１階層は第２階層の親オブジェクトであり、第２階層は第３階層の親オブジェクトとする。したがって、処理プログラム生成部１１０は、約款ＩＤに基づいて、第３階層にアクセスすることにより、第２階層および第１階層のオブジェクトに定義されている処理コード記録部および組合せデータ記録部を取得することができる。
これにより、商品定義体プログラムにおいて記録する処理コードや組合せデータを各種類ＩＤ間で共通して記録することができ、商品定義体の構成を簡素化することができる。また、新たな商品を追加する場合であっても、既存商品との差異のみを所定階層に作成するだけでよいので、装置のメンテナンス性を向上させることができる。
特に、生命保険業界等においては、商品性格に僅かな差異しかない商品であっても、それぞれ別個の契約商品として取り扱わなければならず、しかもこのような契約商品を長期に亘って正確に管理する必要がある。このような状況において、契約商品の管理に本発明のデータ管理装置を適用することにより、約款の改定時には第３階層に約款バージョンを追加し、新商品の追加時には第１階層の商品カテゴリーや第２階層の約款種類を追加することで、商品データの管理のメンテナンス性を高めることができる。また商品を定義するための商品定義体プログラムと、業務アプリケーションを実行するための業務プログラムとを別々に構成しているため、商品の追加変更にともなって業務プログラムを修正する必要がない。
また、１つのシステム内において複数の企業（生命保険会社）についての保険商品を取り扱う場合には、所定の階層における処理コードおよび組合せデータを各企業ごとに作成しておけばよい。例えば、第２階層において各企業ごとに約款種類を設定する場合には、約款種類に企業の識別を示す情報を加えればよい。具体的には、約款種類（２桁）を企業コード（２桁）と約款コード（２桁）で構成し、それぞれに応じた処理コードおよび組合せデータを商品定義体に作成しておけばよい。
これにより、約款における契約条件や契約内容がそれぞれ異なる複数の企業データであっても、同一システム内にてデータ管理を行うことができる。特に、上記のように構成することにより、複数企業のデータ管理処理を一括して行うようなアウトソーシング業務やＡＳＰ業務等に適している。
なお、本発明において「企業」とは、営利の目的で継続的・計画的に同種の経済行為を行う組織体としての企業だけでなく、複数の企業によって構成され共同して経済行為を行う企業グループおよび、１つの企業内において同種の経済行為を行う所定集団から形成された企業内グループを含む概念である。
１０−４．他業界への応用例
上記実施形態においては、主に生命保険業界における保険商品のデータ管理に本発明を適用した場合について説明したが、データ管理項目に差異がある複数の種類のデータを管理する場合であれば、他業界におけるデータ管理にも適用可能である。図１２に、生命保険業界における管理データ、データ種類およびデータ項目を他業界へ応用する場合の対応表を示す。
例えば、図１２の１２１に示す生命保険業界では、管理データとして「保険契約」にかかるデータを管理し、データ種類として「年金保険」と「終身保険」に関するデータ項目を取り扱い、「年金保険」のデータ項目として「年金種類」「年金支払期間」にかかるデータ内容を記録し、「終身保険」のデータ項目として「ステップ払込年数、ステップ払込倍率」にかかるデータ内容を記録することができる。
同様に、１２４に示す銀行業界では、管理データとして「デリバティブ契約」にかかるデータを管理し、データ種類として「金利スワップ」と「オプション」に関するデータ項目を取り扱い、「金利スワップ」のデータ項目として「適用金利種類」「対象適用金利種類」にかかるデータ内容を記録し、「オプション」のデータ項目として「ストライクレート」にかかるデータ内容を記録することができる。
その他の業界および管理データについて本発明に適用する場合におけるデータ種類とデータ項目の例を、上記と同様に図１２の１２２、１２３，１２５〜１２７に示す。このように本発明は、データ管理項目に差異がある複数の種類のデータを管理するあらゆる業界またはデータ管理業務において適用可能である。
１０−５．実施形態の組合せ
上記第１〜９の実施形態をそれぞれ選択的に組み合わせてデータ管理装置１を構成してもよい。また、上記第１〜９の実施形態またはこれらの組合せと、上記「１０−１．処理コードの共通化」、「１０−２．装置構成の分散化」および「１０−３．商品定義の階層化」をそれぞれ選択的に組み合わせた構成としてもよい。
例えば、アプリケーションプログラムからの契約内容の更新指示を受けると、保険契約データに記録された約款ＩＤに基づいて、指示に対応した所定契約条件の契約内容ＩＤおよび契約内容の組合せと更新処理プログラムを取得して、契約内容の更新処理をおこなうとともに（第１の実施形態）、２以上の契約内容についての論理チェックを行うためのチェックリストとチェック処理プログラムを取得して、チェック処理を行うよう（第３の実施形態）に構成してもよい。
また、この場合において、業務アプリケーションからの要求に応じて、上記更新処理およびチェック処理にかかるプログラムの生成とプログラムの実行を集中して実行するラッパープログラムを使用して構成してもよい（第２の実施形態）。
さらに、種類ＩＤに対応するデータ項目および変数位置を処理コードに組み込んで更新処理を行うためのプログラム生成する構成（１０−１．処理コードの共通化）、商品定義体プログラムを実行するコンピュータ装置を独立して構成（１０−２．装置構成の分散化）または１つの商品定義体プログラムの中に階層構造を作成して商品定義を継承させる構成（１０−３．商品定義の階層化）をそれぞれ選択的に組み合わせて構成してもよい。
１０−６．その他
上記実施形態においては、商品定義体プログラムの中に処理コード記録部と組合せデータ記録部を設け、処理名に応じた処理コードおよび組合せデータを取得して処理プログラムを生成する構成を説明したが、商品定義体プログラムの中に組合せデータのみを記録しておき、業務プログラムまたはその他外部プログラムから処理コードを取得し、これらのプログラムにおいて所望の処理を実行するようにしてもよい。すなわち、商品定義体プログラムは、データ内容ＩＤおよびデータ内容のみを、処理を実行するプログラムに引き渡すようにしてもよい。
上記実施形態においては、商品定義体プログラムまたは約款定義体プログラムにおいて生成した処理プログラムを外部プログラムに引き渡し、当該外部プログラムの処理プログラム実行部において処理プログラムを実行するように構成したが、商品定義体プログラムまたは約款定義体プログラムの中に設けた処理プログラム実行部において処理プログラムを実行するようにしてもよい。この場合、商品定義体プログラムまたは約款定義体プログラムは、外部プログラムからの要求に対して、処理プログラムの実行結果を戻り値として返すように構成することができる。例えば、商品定義体プログラムまたは約款定義体プログラムにおいて処理プログラムを実行させる構成は、比較的処理負荷の低い処理プログラムを実行する場合に有効である。
上記実施形態においては、図１に示す各機能を実現する為に、ＣＰＵを用いソフトウェアによってこれを実現している。しかし、その一部もしくは全てを、ロジック回路等のハードウェアによって実現してもよい。なお、プログラムの一部の処理をさらに、オペレーティングシステム（ＯＳ）にさせるようにしてもよい。
以上、本発明の概要および本発明の好適な実施形態を説明したが、各用語は、限定のために用いたのではなく説明のために用いたのであって、本発明に関連する技術分野の当業者は、本発明の説明の範囲内でのシステム、装置、及び方法のその他の変形を認め実行することができる。したがって、そのような変形は、本発明の範囲内に入るものとみなされる。

Claims (60)

  1. 管理対象となるデータ項目がそれぞれ異なるデータを管理するためのデータ管理装置であって、
    少なくとも、データＩＤ、種類ＩＤおよびデータ内容ＩＤを含むデータ記録部と、
    データ項目ごとに、データ内容ＩＤに対応するデータ内容を記録したデータ定義部と、
    前記データ記録部に記録されたデータ内容ＩＤと一致する、前記データ定義部に記録されたデータ内容ＩＤに基づいて、前記データＩＤによって特定されるデータの種類を示す種類ＩＤの所定のデータ項目に対応するデータ内容を決定する処理を行うデータ処理手段と、
    を備えたことを特徴とするデータ管理装置。
  2. 管理対象となるデータ項目がそれぞれ異なるデータを管理するためのデータ管理装置をコンピュータを用いて実現するためのプログラムであって、コンピュータに以下の手段(a)〜(c)を構成させることを特徴とするプログラム：
    (a)少なくとも、データＩＤ、種類ＩＤおよびデータ内容ＩＤを含むデータ記録部にアクセスする手段、
    (b)データ項目ごとに、データ内容ＩＤに対応するデータ内容を記録したデータ定義部にアクセスする手段、
    (c)前記データ記録部に記録されたデータ内容ＩＤと一致する、前記データ定義部に記録されたデータ内容ＩＤに基づいて、前記データＩＤによって特定されるデータの種類を示す種類ＩＤの所定のデータ項目に対応するデータ内容を決定する処理を行うデータ処理手段。
  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. 請求項３０〜３２のデータ管理装置またはプログラムにおいて、
    前記データ記録部は、データＩＤによって特定されるデータの属性を示す属性ＩＤを記録しており、
    前記データ定義部は、属性ＩＤごとに、データ項目ＩＤとデータ内容ＩＤの組合せを記録しており、
    前記データ処理手段は、属性ＩＤごとに、データ項目およびこれに対応するデータ内容を決定する処理を行うことを特徴とするもの。
  34. 請求項１〜３３のデータ管理装置またはプログラムにおいて、
    前記データ記録部は、所定のデータ項目に対応するデータ項目ＩＤとデータ内容の組合せを記録しており、
    前記データ定義部は、データ項目ＩＤとデータ項目の組合せを記録しており、
    前記データ処理手段は、前記データ記録部に記録されたデータ項目ＩＤと一致する、前記データ定義部に記録されたデータ項目ＩＤに基づいて、前記データ記録部に記録されたデータ内容に対応するデータ項目を決定する処理を行うことを特徴とするもの。
  35. 請求項３４のデータ管理装置またはプログラムにおいて、
    前記データ記録部は、データ項目ＩＤとデータ内容の組合せを複数記録していることを特徴とするもの。
  36. 請求項３５のデータ管理装置またはプログラムにおいて、
    前記データ定義部は、データ項目ＩＤとデータ項目の組合せを、前記データ記録部に記録されるデータ内容におけるデータ型ごとに記録していることを特徴とするもの。
  37. 請求項３６のデータ管理装置またはプログラムにおいて、
    前記データ型は、日付型、数値型、文字型またはバイナリ型のいずれかを含むものであることを特徴とするもの。
  38. 請求項３４〜３７のデータ管理装置またはプログラムにおいて、
    前記データ記録部は、データＩＤによって特定されるデータの属性を示す属性ＩＤを記録しており、
    前記データ定義部は、属性ＩＤごとに、データ項目ＩＤとデータ項目の組合せを記録しており、
    前記データ処理手段は、属性ＩＤごとに、データ項目を決定する処理を行うことを特徴とするもの。
  39. 請求項１〜３８のデータ管理装置またはプログラムにおいて、
    前記データ処理手段は、後記計算処理部において使用する計算条件を設定するための条件設定部と、前記計算条件に基づいて所定の計算処理を行うための計算処理部を含んで構成されており、前記条件設定部においてのみデータ定義部またはグループ定義部へのアクセスを行うことを特徴とするもの。
  40. 請求項３９のデータ管理装置またはプログラムにおいて、
    前記データ処理手段は、前記条件設定部および前記計算処理部の組合せを、計算処理単位ごとに備えていることを特徴とするもの。
  41. 請求項３９〜４０のデータ管理装置またはプログラムにおいて、
    取り扱う可能性のあるすべてのデータを包含した処理データ格納部をさらに備えており、
    前記データ処理手段における条件設定部は、前記処理データ格納部に対してデータの入出力を行うことを特徴とするもの。
  42. 請求項４１のデータ管理装置またはプログラムにおいて、
    前記処理データ格納部は、トランザクションデータ、画面入力データおよび計算結果データから構成されることを特徴とするもの。
  43. 管理対象となる契約条件が約款によってそれぞれ異なる保険契約データを管理するための保険契約データ管理装置であって、
    少なくとも、保険契約を特定するための証券ＩＤ、前記保険契約における約款を特定するための約款ＩＤおよび前記約款における契約内容を特定するための契約内容ＩＤを含むデータ記録部と、
    契約条件ごとに、契約内容ＩＤに対応する契約内容を記録したデータ定義部と、
    前記データ記録部に記録された契約内容ＩＤと一致する、前記データ定義部に記録された契約内容ＩＤに基づいて、前記証券ＩＤによって特定される保険契約データにおける、所定の契約条件に対応する契約内容を決定する処理を行うデータ処理手段と、
    を備えたことを特徴とするもの。
  44. 管理対象となる契約条件が約款によってそれぞれ異なる保険契約データを管理するための保険契約データ管理装置をコンピュータを用いて実現するためのプログラムであって、コンピュータに以下の手段(a)〜(c)を構成させることを特徴とするもの：
    (a)少なくとも、保険契約を特定するための証券ＩＤ、前記保険契約における約款を特定するための約款ＩＤおよび前記約款における契約内容を特定するための契約内容ＩＤを含むデータ記録部にアクセスする手段、
    (b)契約条件ごとに、契約内容ＩＤに対応する契約内容を記録したデータ定義部にアクセスする手段、
    (c)前記データ記録部に記録された契約内容ＩＤと一致する、前記データ定義部に記録された契約内容ＩＤに基づいて、前記証券ＩＤによって特定される保険契約データにおける、所定の契約条件に対応する契約内容を決定する処理を行うデータ処理手段。
  45. 管理対象となるデータ項目がそれぞれ異なるデータを管理するためのデータ構造であって、
    少なくとも、データを識別するためのデータＩＤ、前記データＩＤによって特定されるデータ内容の種類を示す種類ＩＤおよび前記種類ＩＤにかかるデータ項目のデータ内容に対応するデータ内容ＩＤを含むデータ記録部と、
    データ項目ごとに、データ内容ＩＤに対応するデータ内容を記録したデータ定義部と、
    を備えたことを特徴とするもの。
  46. 請求項４５のデータ構造において、
    前記データ定義部は、種類ＩＤごとに、管理対象としているデータ項目を記録していることを特徴とするもの。
  47. 請求項４６のデータ構造において、
    前記データ記録部は、データＩＤおよび種類ＩＤの組合せごとに、複数のデータ内容ＩＤを、各組合せに共通な複数のデータ項目番号にそれぞれ対応させて記録しており、
    前記データ定義部は、前記種類ＩＤごとに、複数のデータ項目番号にそれぞれ対応するデータ項目を記録したことを特徴とするもの。
  48. 管理対象となる契約条件が約款によってそれぞれ異なる保険契約を管理するためのデータ構造であって、
    少なくとも、保険契約を特定するための証券ＩＤ、前記保険契約における約款を特定するための約款ＩＤおよび前記約款における契約内容を特定するための契約内容ＩＤを含むデータ記録部と、
    約款ＩＤごとかつ契約条件ごとに、契約内容ＩＤに対応する契約内容を記録したデータ定義部と、
    を備えたことを特徴とするもの。
  49. 請求項４８のデータ構造において、
    前記データ記録部は、証券ＩＤおよび約款ＩＤの組合せごとに、複数の契約内容ＩＤを、各組合せに共通な複数の契約条件番号にそれぞれ対応させて記録しており、
    前記データ定義部は、前記約款ＩＤごとに、複数の契約条件番号にそれぞれ対応する契約条件を記録したことを特徴とするもの。
  50. 指定データに対しての指定処理を行うプログラムを生成するプログラム生成装置であって、
    データ項目ごとに、データ内容ＩＤとデータ内容の対応表を記録したデータ定義部と、
    処理に対する処理コードを記録した処理定義部と、
    指定データに含まれる種類ＩＤおよび指定処理の内容によって特定されるデータ項目についての対応表を、前記データ定義部から取得する対応表取得手段と、
    前記指定処理に関する処理コードを、前記処理定義部から取得する処理コード取得手段と、
    取得した前記対応表および取得した前記処理コードに基づいてプログラムを生成するプログラム生成手段と、
    を備えたことを特徴とするプログラム生成装置。
  51. 指定データに対しての指定処理を行うプログラムを生成するプログラム生成装置をコンピュータを用いて実現するためのプログラムであって、コンピュータに以下の手段(a)〜(e)を構成させることを特徴とするもの：
    (a)データ項目ごとに、データ内容ＩＤとデータ内容の対応表を記録したデータ定義部にアクセスする手段、
    (b)処理に対する処理コードを記録した処理定義部にアクセスする手段、
    (c)指定データに含まれる種類ＩＤおよび指定処理の内容によって特定されるデータ項目についての対応表を、前記データ定義部から取得する対応表取得手段、
    (d)前記指定処理に関する処理コードを、前記処理定義部から取得する処理コード取得手段、
    (e)取得した前記対応表および取得した前記処理コードに基づいてプログラムを生成するプログラム生成手段。
  52. 請求項５０または５１のプログラム生成装置またはプログラムにおいて、
    前記指定データに含まれる種類ＩＤは、管理対象となるデータ項目が種類ＩＤによってそれぞれ異なるデータを管理するデータ記録部であって、少なくとも、データを識別するためのデータＩＤ、前記データＩＤによって特定される種類ＩＤおよび前記種類ＩＤにおけるデータ内容を特定するためのデータ内容ＩＤを含むデータ記録部から抽出されたものであることを特徴とするもの。
  53. 請求項５０〜５２のいずれかのプログラム生成装置またはプログラムにおいて、
    前記データ定義部は、種類ＩＤごとかつデータ項目ごとに、前記対応表を記録したことを特徴とするもの。
  54. 所定の種類ＩＤにかかる指定処理を行うための表示画面を生成する画面生成装置であって、
    データ項目ごとに、データ内容ＩＤとデータ内容の対応表を記録したデータ定義部と、
    処理に対する処理コードを記録した処理定義部と、
    指定データに含まれる種類ＩＤおよび指定処理の内容によって特定されるデータ項目についての対応表を、前記データ定義部から取得する対応表取得手段と、
    前記指定処理に関する処理コードを、前記処理定義部から取得する処理コード取得手段と、
    取得した前記対応表および取得した前記処理コードに基づいてプログラムを生成するプログラム生成手段とを備え、
    前記データ処理手段は、前記データ定義部が所定の種類ＩＤについて記録しているすべてのデータ項目におけるすべてのデータ内容ＩＤおよびデータ内容の組合せを取得し、取得した前記データ内容ＩＤおよびデータ内容の組合せに基づいて、前記所定の種類ＩＤにかかる各データ項目について選択可能なデータ内容ＩＤまたはデータ内容を出力することによって表示画面を生成することを特徴とする画面生成装置。
  55. 所定の種類ＩＤにかかる指定処理を行うための表示画面を生成する画面生成装置をコンピュータを用いて実現するためのプログラムであって、コンピュータに以下の手段(a)〜(d)を構成させ、：
    (a)データ項目ごとに、データ内容ＩＤとデータ内容の対応表を記録したデータ定義部にアクセスする手段、
    (b)処理に対する処理コードを記録した処理定義部にアクセスする手段、
    (c)指定データに含まれる種類ＩＤおよび指定処理の内容によって特定されるデータ項目についての対応表を、前記データ定義部から取得する対応表取得手段と、
    前記指定処理に関する処理コードを、前記処理定義部から取得する処理コード取得手段、
    (d)取得した前記対応表および取得した前記処理コードに基づいてプログラムを生成するプログラム生成手段、
    前記データ処理手段は、前記データ定義部が所定の種類ＩＤについて記録しているすべてのデータ項目におけるすべてのデータ内容ＩＤおよびデータ内容の組合せを取得し、取得した前記データ内容ＩＤおよびデータ内容の組合せに基づいて、前記所定の種類ＩＤにかかる各データ項目について選択可能なデータ内容ＩＤまたはデータ内容を出力することによって表示画面を生成することを特徴とするもの。
  56. 請求項５４または５５の画面生成装置またはプログラムにおいて、
    データ項目ごとに、データ内容ＩＤまたはデータ内容についての表示形式を記録した表示形式定義部またはこれにアクセスする手段をさらに備え、
    前記データ処理手段は、前記表示形式定義部から取得した表示形式に基づいて、選択可能なデータ内容ＩＤまたはデータ内容を出力することを特徴とするもの。
  57. 管理対象となるデータ項目がそれぞれ異なるデータを管理するためのデータ管理方法であって、
    少なくとも、データＩＤ、種類ＩＤおよびデータ内容ＩＤをデータ記録部に記録しておき、
    データ項目ごとに、データ内容ＩＤに対応するデータ内容をデータ定義部に記録しておき、
    前記データ記録部に記録されたデータ内容ＩＤと一致する、前記データ定義部に記録されたデータ内容ＩＤに基づいて、前記データＩＤによって特定されるデータの種類を示す種類ＩＤの所定のデータ項目に対応するデータ内容を決定することを特徴とするデータ管理方法。
  58. 管理対象となる契約条件が約款によってそれぞれ異なる保険契約データを管理するための保険契約データ管理方法であって、
    少なくとも、保険契約を特定するための証券ＩＤ、前記保険契約における約款を特定するための約款ＩＤおよび前記約款における契約内容を特定するための契約内容ＩＤをデータ記録部に記録しておき、
    契約条件ごとに、契約内容ＩＤに対応する契約内容を記録したデータ定義部に記録しておき、
    前記データ記録部に記録された契約内容ＩＤと一致する、前記データ定義部に記録された契約内容ＩＤに基づいて、前記証券ＩＤによって特定される保険契約データにおける、所定の契約条件に対応する契約内容を決定することを特徴とする保険契約データ管理方法。
  59. 指定データに対しての指定処理を行うプログラムを生成するプログラム生成方法であって、
    データ項目ごとに、データ内容ＩＤとデータ内容の対応表をデータ定義部に記録しておき、
    処理に対する処理コードを処理定義部に記録しておき、
    指定データに含まれる種類ＩＤおよび指定処理の内容によって特定されるデータ項目についての対応表を、前記データ定義部から取得し、
    前記指定処理に関する処理コードを、前記処理定義部から取得し、
    取得した前記対応表および取得した前記処理コードに基づいてプログラムを生成することを特徴とするプログラム生成方法。
  60. 所定の種類ＩＤにかかる指定処理を行うための表示画面を生成する画面生成方法であって、
    データ項目ごとに、データ内容ＩＤとデータ内容の対応表をデータ定義部に記録しておき、
    処理に対する処理コードを処理定義部に記録しておき、
    指定データに含まれる種類ＩＤおよび指定処理の内容によって特定されるデータ項目についての対応表を、前記データ定義部から取得する対応表取得手段と、
    前記指定処理に関する処理コードを、前記処理定義部から取得し、
    取得した前記対応表および取得した前記処理コードに基づいてプログラムを生成し、
    前記データ定義部が所定の種類ＩＤについて記録しているすべてのデータ項目におけるすべてのデータ内容ＩＤおよびデータ内容の組合せを取得し、取得した前記データ内容ＩＤおよびデータ内容の組合せに基づいて、前記所定の種類ＩＤにかかる各データ項目について選択可能なデータ内容ＩＤまたはデータ内容を出力することによって表示画面を生成することを特徴とする画面生成方法。
JP2009203139A 2004-10-13 2009-09-02 データ管理装置およびその方法 Active JP5039760B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009203139A JP5039760B2 (ja) 2004-10-13 2009-09-02 データ管理装置およびその方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2004299055 2004-10-13
JP2004299055 2004-10-13
JP2009203139A JP5039760B2 (ja) 2004-10-13 2009-09-02 データ管理装置およびその方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2006540955A Division JP4516084B2 (ja) 2004-10-13 2005-10-12 データ管理装置およびその方法

Publications (3)

Publication Number Publication Date
JP2010015593A true JP2010015593A (ja) 2010-01-21
JP2010015593A5 JP2010015593A5 (ja) 2011-06-16
JP5039760B2 JP5039760B2 (ja) 2012-10-03

Family

ID=36148391

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2006540955A Active JP4516084B2 (ja) 2004-10-13 2005-10-12 データ管理装置およびその方法
JP2009203138A Active JP5039759B2 (ja) 2004-10-13 2009-09-02 データ管理装置およびその方法
JP2009203139A Active JP5039760B2 (ja) 2004-10-13 2009-09-02 データ管理装置およびその方法

Family Applications Before (2)

Application Number Title Priority Date Filing Date
JP2006540955A Active JP4516084B2 (ja) 2004-10-13 2005-10-12 データ管理装置およびその方法
JP2009203138A Active JP5039759B2 (ja) 2004-10-13 2009-09-02 データ管理装置およびその方法

Country Status (4)

Country Link
US (4) US8554582B2 (ja)
JP (3) JP4516084B2 (ja)
CN (2) CN101040292A (ja)
WO (1) WO2006041104A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100318713A1 (en) * 2009-06-16 2010-12-16 Freescale Semiconductor, Inc. Flow Control Mechanisms for Avoidance of Retries and/or Deadlocks in an Interconnect
JP2019125107A (ja) * 2018-01-15 2019-07-25 株式会社オービック 源泉税関連業務支援装置、源泉税関連業務支援方法、および源泉税関連業務支援プログラム

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4516084B2 (ja) 2004-10-13 2010-08-04 ニッセイ情報テクノロジー株式会社 データ管理装置およびその方法
US8036979B1 (en) 2006-10-05 2011-10-11 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US8606626B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US8606666B1 (en) * 2007-01-31 2013-12-10 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US8316318B2 (en) * 2007-03-30 2012-11-20 Oracle International Corporation Named calculations and configured columns
US8719119B1 (en) 2008-09-30 2014-05-06 Accenture Global Services Limited Post deployment query system
US8788295B1 (en) 2008-09-30 2014-07-22 Accenture Global Services Limited Reusable product system
US8595103B1 (en) 2008-09-30 2013-11-26 Accenture Global Services Limited Deployment and release component system
US8175900B2 (en) * 2009-03-02 2012-05-08 The Trustee and Successor Trustees of RGD 2006 Trust Life insurance strategic value
US8832144B2 (en) 2011-07-11 2014-09-09 International Business Machines Corporation Search optimization in a computing environment
US9043866B2 (en) 2011-11-14 2015-05-26 Wave Systems Corp. Security systems and methods for encoding and decoding digital content
US9015857B2 (en) 2011-11-14 2015-04-21 Wave Systems Corp. Security systems and methods for encoding and decoding digital content
US9047489B2 (en) * 2011-11-14 2015-06-02 Wave Systems Corp. Security systems and methods for social networking
US9122740B2 (en) * 2012-03-13 2015-09-01 Siemens Product Lifecycle Management Software Inc. Bulk traversal of large data structures
US8990205B2 (en) * 2013-01-28 2015-03-24 International Business Machines Corporation Data caveats for database tables
US8719063B1 (en) * 2013-05-07 2014-05-06 Marsh USA Inc. System and method for comparing information in a process for issuing insurance policies
JP5753217B2 (ja) * 2013-05-17 2015-07-22 株式会社アイディーズ 商品コード分析システム及び商品コード分析プログラム
CN104679443A (zh) * 2013-12-03 2015-06-03 昆达电脑科技(昆山)有限公司 数据自动写入装置及方法
JP6173896B2 (ja) * 2013-12-10 2017-08-02 株式会社日立製作所 データ処理方法およびデータ処理サーバ
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US10445152B1 (en) 2014-12-19 2019-10-15 Experian Information Solutions, Inc. Systems and methods for dynamic report generation based on automatic modeling of complex data structures
US10698671B2 (en) 2015-03-30 2020-06-30 Arxan Technologies, Inc. Processing, modification, distribution of custom software installation packages
JP6674092B2 (ja) * 2016-02-10 2020-04-01 富士通株式会社 データ管理プログラム、データ管理装置、及びデータ管理方法
CN107103539A (zh) * 2016-02-22 2017-08-29 易保网络技术(上海)有限公司 一种计算机执行的计算保费的方法和系统
CN107861963B (zh) * 2017-02-20 2020-08-04 平安科技（深圳）有限公司 险种合约的生成方法和装置
CN109272226A (zh) * 2018-09-10 2019-01-25 上海嘉实（集团）有限公司 一种基于大数据和云平台的智能化安装工程质量检查系统
US11120894B2 (en) * 2018-10-17 2021-09-14 Accenture Global Solutions Limited Medical concierge
US12079851B2 (en) 2019-01-02 2024-09-03 Allstate Insurance Company Onboarding platform for performing dynamic mitigation analysis
US20220027380A1 (en) * 2020-07-21 2022-01-27 Berkley Insurance Company Data management system and method for general ledger
CN117252716B (zh) * 2023-09-11 2024-07-16 广东源恒软件科技有限公司 一种税务数据储存管理方法及系统

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06139130A (ja) * 1992-10-23 1994-05-20 Fujitsu Ltd オブジェクト指向データベースにおける問い合わせ処理方式
JPH09185542A (ja) * 1995-12-28 1997-07-15 Hitachi Ltd オブジェクト管理方法
JPH10301911A (ja) * 1997-04-30 1998-11-13 Fujitsu Ltd クライアント主導のネットワーク・コンピューティングシステムおよび方法
JP2000215063A (ja) * 1999-01-22 2000-08-04 Pfu Ltd 単一継承によるサブクラスを含むオブジェクトデ―タ格納方法および記録媒体
JP2000322463A (ja) * 1999-05-13 2000-11-24 Zuken:Kk 回路シンボル自動生成システム
WO2002097694A1 (en) * 2001-05-29 2002-12-05 Matsushita Electric Industrial Co., Ltd. Insurance system
JP2004185270A (ja) * 2002-12-03 2004-07-02 Fujitsu Ltd アンロードプログラム，ロードプログラム及びデータ移行方法
US20050203777A1 (en) * 1999-06-23 2005-09-15 Rosenfeld Brian A. System and method for accounting and billing patients in a hospital environment

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6429928A (en) 1987-07-24 1989-01-31 Nippon Telegraph & Telephone Knowledge base constituting method
JPS6464044A (en) 1987-09-04 1989-03-09 Fujitsu Ltd Logical file processing system
JP3144022B2 (ja) 1992-01-22 2001-03-07 富士ゼロックス株式会社 プログラムデータベースシステム
JPH06236315A (ja) 1992-10-07 1994-08-23 Akifumi Makinouchi オブジェクト指向データベース管理システム
JPH08272804A (ja) 1995-03-29 1996-10-18 Mitsubishi Electric Corp 情報表示システムにおける項目データ照会方式
JPH08329142A (ja) 1995-05-30 1996-12-13 Fujitsu Ltd 保険商品管理システム
JPH1029928A (ja) 1995-07-13 1998-02-03 Shiseido Co Ltd 皮膚外用剤
JP3489326B2 (ja) 1996-04-10 2004-01-19 株式会社日立製作所 テーブル生成方法
JP3552003B2 (ja) 1996-08-19 2004-08-11 戸田工業株式会社 磁気記録媒体
EP0863469A3 (en) 1997-02-10 2002-01-09 Nippon Telegraph And Telephone Corporation Scheme for automatic data conversion definition generation according to data feature in visual multidimensional data analysis tool
JPH1173431A (ja) 1997-02-10 1999-03-16 Nippon Telegr & Teleph Corp <Ntt> データの特徴に基づく定義生成支援装置、方法およびそのプログラムを格納した記憶媒体
JPH10283248A (ja) 1997-04-09 1998-10-23 Meidensha Corp 設備情報の管理システム
JPH10334160A (ja) 1997-06-02 1998-12-18 N T T Data:Kk 金融処理システム及び同システム用のプログラム記録媒体
JPH11143749A (ja) 1997-11-06 1999-05-28 Nec Miyagi Ltd リレーショナルデータベースマネジメントシステムおよびデータ管理方法
JPH11249952A (ja) 1998-03-05 1999-09-17 Nippon Telegr & Teleph Corp <Ntt> データ入出力方法および装置とデータ入出力プログラムを記録した記録媒体
JPH11265395A (ja) 1998-03-18 1999-09-28 Hitachi Ltd データベースアクセスシステム
JP2000123038A (ja) 1998-10-15 2000-04-28 Mitsubishi Materials Corp データベース装置、データベースアクセス方法及びデータベースアクセスプログラムを記録した記録媒体
JP2000137735A (ja) 1998-10-29 2000-05-16 Casio Comput Co Ltd アクセス制御装置およびそのプログラム記録媒体
JP2000271826A (ja) 1999-03-24 2000-10-03 Mitsubishi Electric Corp 製品の構成要素組合せ判定装置
JP2001195297A (ja) 2000-01-17 2001-07-19 Pfu Ltd オブジェクト管理装置およびその制御プログラムを記録した記録媒体
JP2002163134A (ja) 2000-11-28 2002-06-07 Nec Corp データ管理方法
JP3730156B2 (ja) 2001-11-09 2005-12-21 有限会社築城ソフト研究所 関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体
KR20020061119A (ko) 2001-01-12 2002-07-22 유겐가이샤 츠유키 소프트 겐큐쇼 관계 설정 정보 관리 시스템, 관계 설정 정보 관리용프로그램 및 기록 매체
JP2003108429A (ja) 2001-09-28 2003-04-11 Nec System Technologies Ltd Ｗｅｂシステムにおけるマスタ参照方式
JP2003228686A (ja) 2002-02-04 2003-08-15 Seiko Epson Corp 表形式データファイルの参照処理システムと表形式データファイルの参照処理方法と表形式データファイルの参照処理プログラム
JP4516084B2 (ja) 2004-10-13 2010-08-04 ニッセイ情報テクノロジー株式会社 データ管理装置およびその方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06139130A (ja) * 1992-10-23 1994-05-20 Fujitsu Ltd オブジェクト指向データベースにおける問い合わせ処理方式
JPH09185542A (ja) * 1995-12-28 1997-07-15 Hitachi Ltd オブジェクト管理方法
JPH10301911A (ja) * 1997-04-30 1998-11-13 Fujitsu Ltd クライアント主導のネットワーク・コンピューティングシステムおよび方法
JP2000215063A (ja) * 1999-01-22 2000-08-04 Pfu Ltd 単一継承によるサブクラスを含むオブジェクトデ―タ格納方法および記録媒体
JP2000322463A (ja) * 1999-05-13 2000-11-24 Zuken:Kk 回路シンボル自動生成システム
US20050203777A1 (en) * 1999-06-23 2005-09-15 Rosenfeld Brian A. System and method for accounting and billing patients in a hospital environment
WO2002097694A1 (en) * 2001-05-29 2002-12-05 Matsushita Electric Industrial Co., Ltd. Insurance system
JP2004185270A (ja) * 2002-12-03 2004-07-02 Fujitsu Ltd アンロードプログラム，ロードプログラム及びデータ移行方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100318713A1 (en) * 2009-06-16 2010-12-16 Freescale Semiconductor, Inc. Flow Control Mechanisms for Avoidance of Retries and/or Deadlocks in an Interconnect
US8554967B2 (en) * 2009-06-16 2013-10-08 Freescale Semiconductor, Inc. Flow control mechanisms for avoidance of retries and/or deadlocks in an interconnect
JP2019125107A (ja) * 2018-01-15 2019-07-25 株式会社オービック 源泉税関連業務支援装置、源泉税関連業務支援方法、および源泉税関連業務支援プログラム

Also Published As

Publication number Publication date
US20140012845A1 (en) 2014-01-09
CN103258291A (zh) 2013-08-21
US20140012838A1 (en) 2014-01-09
US8694344B2 (en) 2014-04-08
US8554582B2 (en) 2013-10-08
JP5039759B2 (ja) 2012-10-03
WO2006041104A1 (ja) 2006-04-20
JP2010015592A (ja) 2010-01-21
JP4516084B2 (ja) 2010-08-04
US20080016099A1 (en) 2008-01-17
JP5039760B2 (ja) 2012-10-03
JPWO2006041104A1 (ja) 2008-05-15
US20140012844A1 (en) 2014-01-09
CN101040292A (zh) 2007-09-19

Similar Documents

Publication Publication Date Title
JP5039760B2 (ja) データ管理装置およびその方法
Ahmad et al. Banking sector performance, profitability, and efficiency: a citation‐based systematic literature review
Alt et al. The rise of customer-oriented banking-electronic markets are paving the way for change in the financial industry
AU2012200992B2 (en) Page designer with customization constraints
US20150154696A1 (en) Municipal bond tracking and evaluation system
US7680708B1 (en) Method and user interface for assigning a tax line item to a user transaction
Meyer et al. Activity-centric and artifact-centric process model roundtrip
Ergüven The political economy of housing financialization in Turkey: links with and contradictions to the accumulation model
US20150178851A1 (en) Insurance product model relationships
CN108256113A (zh) 数据血缘关系的挖掘方法及装置
US20130198109A1 (en) Municipal bond tracking and evaluation system
WO2015166973A1 (ja) 企業財務データを集約する集約サーバ、方法及びコンピュータプログラム
US7318200B2 (en) Master data framework
US11544266B1 (en) Methods and systems for efficiently and rapidly generating highly customized cloud-based enterprise software applications
Milberg Export processing zones, industrial upgrading and economic development: A survey
WO2005010658A2 (en) Logistics management method and system
JP7212511B2 (ja) 融資管理装置、融資管理方法、及び融資管理プログラム
US7467105B2 (en) Price calculator
Ryan et al. Package ‘quantmod’
CN114418444A (zh) 信用评级系统的生成方法、信用评级方法
Ullah et al. Government Accounting in Pakistan: transition from a Legacy system to the New Accounting Model
Liu et al. Business entities: An SOA approach to progressive core banking renovation
US20110196770A1 (en) System and Method for Visual and Interactive Determination of Optimal Financing and Refinancing Solutions
Rolli et al. Improvement of the compilation process of the Italian income certifications: an application on the tax model of the year 2016 (Part 2)
Arachchi et al. Comprehensive Marketplace and Factors Affecting the Budget of Enterprise Resource Planning (ERP) in Sri Lanka

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110427

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120611

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120709

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150713

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5039760

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250