特許 6873380 データ管理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6873380

(24)【登録日】2021年4月23日

(45)【発行日】2021年5月19日

(54)【発明の名称】データ管理装置

(51)【国際特許分類】

   G06Q 40/08 20120101AFI20210510BHJP

【ＦＩ】

   G06Q40/08

【請求項の数】5

【全頁数】18

(21)【出願番号】特願2020-115553(P2020-115553)

(22)【出願日】2020年7月3日

【審査請求日】2020年8月28日

【早期審査対象出願】

(73)【特許権者】

【識別番号】520244245

【氏名又は名称】ａｘｅｌａ株式会社

(74)【代理人】

【識別番号】100086863

【弁理士】

【氏名又は名称】佐藤 英世

(72)【発明者】

【氏名】清水 達紀

(72)【発明者】

【氏名】佐藤 由紀彦

【審査官】 大野 朋也

(56)【参考文献】

【文献】 特開２０１０−０１５５９２（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００８／００１６０９９（ＵＳ，Ａ１）

【文献】 中国特許出願公開第１０１０４０２９２（ＣＮ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００−９９／００

(57)【特許請求の範囲】

【請求項1】

サービス利用に係るイベントの内容及び結果と、少なくともオープン又はクローズのステータスとを保持するデータ群であり、そのデータ群をスライス型データとして記憶する第１の記憶手段と、
そのデータ内容に異動が生じた時は、異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する処理手段と
を有するデータ管理装置であって、
一つの契約の情報は、上記スライス型データの集合体で表現されることを特徴とするデータ管理装置。

【請求項2】

サービス利用に係るイベントの内容及び結果と、少なくともオープン又はクローズのステータスとを保持するデータ群であり、そのデータ群をスライス型データとして記憶する第１の記憶手段と、
そのデータ内容に異動が生じた時は、異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する処理手段と
を有すると共に、
一つの契約の情報は、上記スライス型データの集合体で表現されるデータ管理装置であって、
上記スライス型データの別レイヤーに、サービスの提供における顧客との接点に関する情報を保持するエンゲージメント情報があり、その中には少なくともエンゲージメントＩＤ、エンゲージメント期間を含み、該エンゲージメント情報の異動は、そのエンゲージメント情報とは別レイヤーのスライス型データのステータスの変更を伴わないことを特徴とするデータ管理装置。

【請求項3】

上記スライス型データは、新規保険契約も異動も全てイベントとして上記処理手段によって処理されて生成され、且つそれらのデータのステータスとして、少なくともオープン及びクローズに相当する処理がなされて、該データの集合体として表現されることになり、さらに、有効開始日時を示すｆｒｏｍ情報と有効終了日時を示すｔｏ情報が該データに含まれていて、同一エンティティのスライス型データは、少なくとも新規や異動のどの時点でも全て同一データ構造であり、同一の第１の記憶手段に格納されて、同一のアプリケーション・インターフェースで処理が可能であるため、異動のデータを、異動後の内容が反映された新規データ相当として取り扱うことができ、また複数の異動を同時に行う場合は、すべての異動を反映した新規データ相当として取り扱うことにより、複数の異動内容を１つの履歴にまとめて処理することができ、且つ、データの照会時にもこのｆｒｏｍ情報とｔｏ情報を検索することで直ぐにできることを特徴とする請求項１乃至２記載のデータ管理装置。

【請求項4】

上記第１の記憶手段に記憶されるスライス型データのステータスに、さらにインバリッドのステータスを含んでおり、上記処理手段で、異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する際に、該処理手段により、クローズ直前のスライス型データのイメージをバックアップとして記憶する第２の記憶手段を有することを特徴とする請求項１〜３いずれか１つに記載のデータ管理装置。

【請求項5】

異動後のスライス型データのステータスをオープンして追加した際に、そのステータスが取り消しになった場合に、上記処理手段により、該スライス型データのステータスをインバリッドとし、上記第２の記憶手段に記憶された異動対象となってクローズされたスライス型データを、上記第１の記憶手段に、そのステータスをオープンにして記憶させる復元処理が行われることを特徴とする請求項４記載のデータ管理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データ管理装置に関する。

【背景技術】

【0002】

大概の保険会社では、メインフレーム上に構築されたレガシーシステムから、現代のＩｏＴ時代に相応しい先進技術の導入されたシステムへの移行が遅れているのが現状である。

【0003】

また、１９９０年代以降、子会社形式による生損保兼営が始まり、２０００年代以降は保険業界以外へのビジネス拡大の動きもみられるが、それらの基幹システムは事業会社単位にほぼ独立して構築されており、親会社やグループ内で一体的にシステム構築された事例はほとんどない。

【0004】

他方、保険契約締結の後、保険契約者の請求により、現存契約の契約条件を変更する処理（以下、異動と言う）に関わる割合は、保険においてなされる全手続の中で極めて少数である。ところが、この異動という処理を上記システムで行わせようとすると大変な手間・時間の掛かる処理になる。そのため、保険会社における保険商品の開発・保全に伴う管理運用システムの開発において、この異動処理のために係るコスト・工数・期間等は、一般的に過半を占めると言われており、システム構築上大きな問題となっている。

【0005】

現在保険会社が採用している契約データモデルは、保険期間が短く且つ異動の頻度が多い損害保険分野で一般的である、図１０に示されるような差分履歴型契約データモデルと、保険期間が長く生命保険で一般的である、図１１に示されるようなイベントヒストリ型契約データモデルとがある。

【0006】

図１０の差分履歴型契約データモデルにおいては、新規の保険契約（図中Ｎ）があると、契約データベース（図中契約ＤＢ）に、まず契約内容の全項目を全項目データとして記録する。その契約に対し、上記異動が発生すると、その変更差分（Ｃ１、Ｃ２）毎に忠実に記録していくことになる。すなわち、上記異動に伴う変更はデータ項目の変更差分（変更差分Ｃ１、変更差分Ｃ２）のみを履歴として登録することになる。そして、該図面における内容照会（図中右側の点線で示す部分が行われる際）に相当する最新状態を参照するときは、その都度ベースとなる新規契約内容全項目のデータに、変更差分の夫々の履歴を合成したイメージを作成し（保険内容Ｎ＋変更差分Ｃ１＋変更差分Ｃ２）、提示することになる。

【0007】

また、図１１のイベントヒストリ型契約データモデルでは、イベントヒストリデータベース（図中イベントヒストリＤＢ）と契約データベース（図中契約ＤＢ）との二つのデータベースがあり、これらのデータベースのうちで、契約データベースでは、新規の保険契約に係る新規契約内容のデータ（Ｎ）と上記異動（Ｃ１、Ｃ２）のデータとを区別せず、異動の都度、契約データベース（図中契約ＤＢ）に記録されるデータを最新状態に更新する（（Ｎ）−（Ｎ＋Ｃ１）−（Ｎ＋Ｃ１＋Ｃ２））。従って契約内容の照会においては、そのまま最新状態が参照されることになる。他方異動内容は、イベントヒストリとして、そのサマリがイベントヒストリＤＢに別記録される（（新規契約内容）、（変更内容Ｃ１サマリ）、（変更内容Ｃ２サマリ））ことになる。

【発明の概要】

【発明が解決しようとする課題】

【0008】

上記２つの契約データモデルには、次のような問題がある。
まず、差分履歴型契約データモデルでは、新規や異動の内容を忠実に記録し、リソース（データ容量）を合理的に抑えることが可能であるが、異動内容毎に異動保険料を計算し、データの妥当性、異動前後の整合性等を確保するシステム設計が必要であり、内容照会の度に、新規と差分履歴のデータ合成が必要となって、システムに負荷が掛かりやすく、またその機能の特殊性からシステムがブラックボックス化しているという問題がある。

【0009】

また、上記イベントヒストリ型契約データモデルでは、契約内容の照会にあっては、契約データベースにおいてそのまま最新状態が参照されることになると共に、異動内容は、イベントヒストリとして、そのサマリがイベントヒストリＤＢに別記録されるため、演算処理装置の負荷やデータ容量等のリソースを合理的に抑えることが可能である。しかし、保険会社が将来の保険金給付や解約返戻金支払い等に充てるために保険料や運用収益を財源として積み立てておく必要のある責任準備金や保険料を、異動内容毎に再計算し、データの妥当性、異動前後の整合性等を確保するシステム設計が必要と言う上記システムと共通する問題がある。さらに上記異動による契約条件の変更を取り消す際には、契約単位にイベントヒストリデータベースの更新をロールバック（該データベースの更新ログデータを使用して異動前の元の状態に戻す）する機能が必要となり、この取り消しのためだけに、そのようなシステム設計を必要とすると、異動処理のために係るコスト・工数・期間において、またその機能の特殊性からシステムがブラックボックス化していることにより、システム構築上大きな問題となる。

【0010】

いずれも変更差分のデータを起点とし、異動内容別にシステム機能が構築され、複雑かつ大規模な異動固有の機能を持っている、さらにその点が基幹システムの円滑な刷新の阻害要因となっている、という共通した問題点がある。

【0011】

本発明は、従来技術の以上のような問題に鑑み創案されたもので、契約条件の異動のデータを、異動後の内容が反映された新規データ相当として取り扱うことができ、また複数の異動を同時に行う場合は、すべての異動を反映した新規データ相当として取り扱うことができる構成を提案し、それによって、異動内容毎の機能を個別に実装する必要のない（異動固有の機能の大幅な簡素化・圧縮を実現する）データ管理装置を提供せんとするものである。

【0012】

またこのデータ管理装置では、契約条件の変更を更に取り消す際に、システム上大掛かりな仕組みが必要となる契約単位のロールバックをせずに、その取り消しが行える構成についても併せて提案する。

【課題を解決するための手段】

【0013】

本発明の構成を説明する前に、その創案に至った経緯からまず先に、その開発の「切っ掛け」となった新たな構成（以下切掛構成と言う）について説明する。但し、この以下に示す構成はあくまで本発明構成を創案する「切っ掛け」となったのもので、この構成によって、本発明の全ての前提構成とするものではない。

【0014】

現在の保険会社は、一般的に基幹システムのすべてを自社で運営しているが、上記切掛構成では、図７に示すように、「顧客情報」に関わる機能および金銭の「請求・収納」に関わる機能などの事業会社間で共有可能な情報は、「顧客層」・「ビリング層」に分けて疎結合化して構築する（顧客層には顧客の情報を、又ビリング層には保険料請求・収納状況を手数料支払い状況と共に管理する）。

【0015】

さらに、ビジネス取引が無ければ存在し得ず、かつ異なる事業会社間でも共通性の高い契約番号、サービス期間などの情報やペイメント情報などを「エンゲージメント層」として定義する（図中エンゲージメント情報に、上記契約（証券）番号や保険期間等のつながり情報が格納され、またペイメント情報に顧客の支払い手段情報、口座・クレジットカード情報などが格納される）。このような構成により、エンゲージメント層により、事業者は顧客エンゲージメントを基準化して事業会社間を跨って把握することが可能となり、顧客情報を合理的に管理・活用することができる。

【0016】

さらに、事業固有のサービスにかかるシステムやデータベースは、「サービス層」に構築する（このサービス情報に、保険の対象、補償、保険料、手数料などの情報が格納される。他にこの層には保険金支払い管理情報がエンゲージメント層とビリング層に紐付けられている）。

【0017】

これらの構成は、１乃至複数のサーバで構成されたり、クラウド側に構築されても良い。重要なことは、これまでのメインフレーム中心のブラックボックス化したレガシーシステムの状態から、どの種の事業サービスにも共通な機能と、特定の事業サービスに必須な機能とを分け、前者は一つ構築してしまえば共通に使え、後者のみ特定の事業サービス用に開発すれば良くなる。即ち、このような構成によってグループ企業全体でのシステム規模を圧縮するのが狙いである。

【0018】

以上の様な「切掛構成」は、保険などに限らず、様々なサービスに適応可能なアイデアであり、以下に説明する本発明の構成は、上記特定のサービスに必須な機能を、具体化して規定するものである。上述のように、本発明は、この切掛構成を元に創案されたものであるが、限定された機能を取り出して開発されたもの故、取り出し後の該構成は、上記のような切掛構成に限定されることはない。

【0019】

以上の様な考え方を元に、本発明の構成を説明する。
まず、本発明の基本となる構成について説明する。
即ち、１つ目の本発明に係るデータ管理装置の構成は、後述する図８に示されるように、
サービス利用に係るイベントの内容及び結果と、少なくともオープン又はクローズのステータスとを保持するデータ群であり、そのデータ群をスライス型データとして記憶する第１の記憶手段１と、
そのデータ内容に異動が生じた時は、異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する処理手段２と
を有するデータ管理装置であって、
一つの契約の情報は、上記スライス型データの集合体で表現されることを基本的特徴としている。

【0020】

この構成は、上述のように、取り出されて開発された限定機能に必須な構成について規定したもので、図１は、上記スライス型データが、処理手段２によりどのように処理されるのかを模したデータ処理説明図である。

【0021】

これを仮に保険契約用に使用した場合について説明する（尚、保険契約だけに適用されるものでないことは始めに述べておく）。

【0022】

ここで、円筒型に示したものがスライス型データのイメージである。そして新規の保険契約があると、処理手段２は、該保険契約を最初のイベント１として、保険内容００１のスライスを新規に生成し、そのステータスをオープンとする。

【0023】

次にその契約に対し、上記異動イベント２が発生したとすると、上記処理手段２は、上記保険内容００１のスライスのステータスをクローズ（中止）に変更すると共に、該異動イベント２を反映する新保険内容００２のスライスを生成し、該スライスのステータスをオープンする。ここでの保険内容００２は、最初に契約された保険内容００１に上記異動イベント２の内容が反映されたものである。

【0024】

さらに、別の異動イベント３が発生したとすると、上記処理手段２は、上記保険内容００２のスライスのステータスをクローズ（中止）に変更すると共に、該異動イベント３を反映する新保険内容００３のスライスを生成し、該スライスのステータスをオープンする。ここでの保険内容００３は、保険内容００２に上記異動イベント３の内容が反映されたものである。

【0025】

以下新たな異動イベントが生じる度に上記処理手段２は、スライス型データを上述のように処理し、新たな保険内容のスライスが追加されていくことになる。

【0026】

このように、本発明の構成では、新規保険契約も異動も全てイベントとして上記処理手段２によって処理され、スライス型データが生成され、且つそれらのスライス型データのステータスとして、少なくともオープン及びクローズに相当する処理がなされて、スライス型データの集合体として表現されることになる。ここで、スライス型データとは、どのようなものかを詳述する。該スライス型データとは、上述のように、新規保険契約も異動も全てイベントとして上記処理手段２によって処理されて生成され、且つそれらのデータのステータスとして、少なくともオープン及びクローズに相当する処理がなされて（後述するように、ステータスにインバリッドのステータスを含むようにすることもできる）、該データの集合体として表現されることになる。さらに、有効開始日時を示すｆｒｏｍ情報と有効終了日時を示すｔｏ情報が該データに含まれており、同一エンティティのスライス型データは、少なくとも新規や異動のどの時点でも全て同一データ構造であり、同一の第１の記憶手段１に格納されて、同一のアプリケーション・インターフェースで処理が可能であることが特徴となる。そのため、異動のデータを、異動後の内容が反映された新規データ相当として取り扱うことができ、また複数の異動を同時に行う場合は、すべての異動を反映した新規データ相当として取り扱うことにより、複数の異動内容を１つの履歴にまとめて処理することができる。またデータの照会時にもこのｆｒｏｍ情報とｔｏ情報を検索することで直ぐにでき、わざわざデータ合成処理を行う必要がなくなるという性質を有する。

【0027】

この構成を従来技術として示した差分履歴型契約データモデルの場合と比較してみると、図１０に示される差分履歴型契約データモデルでは、複数の異動内容を１つの履歴にまとめて処理することができないため、有効開始日時（ｆｒｏｍ）のみを保持し、同一日時の複数の履歴を重ねるのが一般的である。それに対し、本構成では、図１、上記［００２６］の説明及び後述する説明（[００３４]［００３５］［００８３］［００８５］に記載する説明）に示すように、有効開始日時（ｆｒｏｍ）と有効終了日時（ｔｏ）を保持し、複数の異動内容を１つの履歴にまとめて処理することができることになる。即ち、異動のデータを、異動後の内容が反映された新規データ相当として取り扱うことができ、また複数の異動を同時に行う場合は、すべての異動を反映した新規データ相当として取り扱うことができるようになる。またデータの照会時にもわざわざデータ合成処理が必要ではなくなる。

【0028】

他方、本構成を従来技術として示したイベントヒストリ型契約データモデルの場合と比較してみると、図１１に示されるイベントヒストリ型契約データモデルでは、イベントヒストリデータベースと契約データベースに分かれており、データ構造も同一でないのが一般的である。これに対し、本構成では、データベース及びデータ構造が１つの構成で済み、保険会社が将来の保険金給付や解約返戻金支払い等に充てるために保険料や運用収益を財源として積み立てておく必要のある責任準備金や保険料を、異動内容毎に再計算し、データの妥当性、異動前後の整合性等を確保するシステム設計が別途必要になると言うことはない。データベースの簡略化と保険料などの再計算やデータの妥当性・整合性を検証する別途のシステムの開発が不要となる。

【0030】

本発明の２つ目の構成は、基本的に１つ目の発明の構成と同じであるが、さらに、原則的に同時に異動する必然性のないデータ項目の内容を、スライス型データの別エンティティに保持する構成のものである。

【0031】

即ち、この２つ目の構成は、図２に示されるように、
サービス利用に係るイベントの内容及び結果と、少なくともオープン又はクローズのステータスとを保持するデータ群であり、そのデータ群をスライス型データとして記憶する第１の記憶手段１と、
そのデータ内容に異動が生じた時は、異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する処理手段２と
を有すると共に、
一つの契約の情報は、上記スライス型データの集合体で表現されるデータ管理装置であって、
上記スライス型データの別レイヤーに、サービスの提供における顧客との接点に関する情報を保持するエンゲージメント情報があり、その中には少なくともエンゲージメントＩＤ、エンゲージメント期間を含み、該エンゲージメント情報の異動は、そのエンゲージメント情報とは別レイヤーのスライス型データのステータスの変更を伴わないことを特徴としている。

【0032】

原則的に同時に異動する必然性のないデータ項目の内容とは、例えば保険期間等のエンゲージメント期間を、サービスの提供における顧客との接点に関する情報を保持するエンゲージメント情報として含むことを言い、これらの情報は上記スライス型データとは別レイヤーに備えられており、仮に上記保険期間に当たるエンゲージメント期間の異動を行う場合はエンゲージメント情報の異動により行われて、そのエンゲージメント情報とは別レイヤーのスライス型データのステータスの変更を伴わないものとするものである。

【0033】

上述した１つ目及び２つ目の発明の構成において、既に説明したとおり、上記スライス型データには、有効開始日時を示すｆｒｏｍ情報と、有効終了日時を示すｔｏ情報とを含んでいる。

【0034】

２つの発明の構成では、新規保険契約も異動も全てイベントとして上記処理手段２によって処理され、スライス型データが生成され、且つそれらのデータのステータスとして、少なくともオープン及びクローズに相当する処理がなされて、スライス型データの集合体として表現されることになる。上述のように、該スライス型データには、有効開始日時を示すｆｒｏｍ情報と有効終了日時を示すｔｏ情報が該データに含まれており、同一エンティティのスライス型データは、少なくとも新規や異動のどの時点でも全て同一データ構造であり、同一の第１の記憶手段１に格納されて、同一のアプリケーション・インターフェースで処理が可能であることが特徴となる。そのため、異動のデータを、異動後の内容が反映された新規データ相当として取り扱うことができ、また複数の異動を同時に行う場合は、すべての異動を反映した新規データ相当として取り扱うことにより、複数の異動内容を１つの履歴にまとめて処理することができる。またデータの照会時にもこのｆｒｏｍ情報とｔｏ情報を検索することで直ぐにでき、わざわざデータ合成処理を行う必要がなくなるという性質を有する。

【0035】

また、上述のように、スライス型データには、有効開始日時を示すｆｒｏｍ情報と有効終了日時を示すｔｏ情報を含んでいるので、同一エンティティのスライス型データは、少なくとも新規や異動のどの時点でも全て同一データ構造であり、同一の第１の記憶手段１に格納されて、同一のアプリケーション・インターフェースで処理が可能である。

【0036】

現状の個人向けの金融商品の中では、保険商品は特に内容が複雑であるため、従来から一定の頻度で誤認や錯誤により、やむを得ない取り消し手続きが存在する。これまでは、代理店や営業職員など一定水準の資格を持つ人員を介して内容説明と手続きを行ってきたが、今後デジタル化が進み、または新型コロナウイルスの影響などで非接触型のビジネススタイルが指向され、顧客が直接手続きを行うケースが増えていった場合、消費者保護の観点から手続き取り消しのニーズは拡大する可能性がある。

【0037】

上述のように、上記２つの発明構成の場合、新規の保険契約や異動などのイベントが発生する毎に、処理手段は、新たな保険内容のスライスを新規に生成し、そのステータスをオープンとすると共に、その直前のスライスをクローズすることになる。こうした場合に、このイベント自身を取り消ししたい等の時（異動の取り消しをしたい場合）は、以上の構成のままでは簡単にその取り消しが出来ないことになる。

【0038】

そのため、本構成では、上記スライス型データのステータスとして少なくともオープン、クローズ及びインバリッドのステータスを含むものとするが、このような異動の取り消しを行う際は、上記スライス型データ取り消しするスライス型データのステータスをオープンからインバリッド（無効）とし、さらにその異動前のスライス型データのステータスをクローズからオープンにする必要があるが、この異動前のスライス型データのステータスがクローズされる際にはステータス以外にも精算保険料額などのデータ項目が同時に更新されている。このため、すべてのデータ項目内容を復元することができない。

【0039】

そのため本発明の上記構成に加えて、上記処理手段で、異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する際に、上記図９に示されるように、該処理手段２により、クローズ直前のスライス型データのイメージをバックアップとして記憶する第２の記憶手段３を有する構成を提案する。

【0040】

上記の３つ目の発明の構成を実際に稼働させるなら、上記スライス型データのステータスとして少なくともオープン、クローズ及びインバリッドのステータスを含むものとし、異動後のスライス型データのステータスをオープンして追加した際に、そのステータスが取り消しになった場合、上記処理手段２により、該スライス型データのステータスをインバリッドとし、上記第２の記憶手段３に記憶された異動対象となってクローズされたスライス型データを、上記第１の記憶手段１に、そのステータスをオープンにして記憶させる復元処理が行われるようにする構成とする必要があり、このため、図５に示されるように、異動前のスライス型データのステータスをクローズする際に、クローズ直前のスライス型データのイメージのバックアップを確保する必要があることから、上記第２の記憶手段３の構成を有することとした。

【0041】

原則として、クローズされたスライス型データおよびバックアップを取る第２の記憶手段３には「異動の取り消し」以外の更新は行われない。つまり、「異動の取り消し」が発生するまでデータの整合性が理論上確保されていることになる。このため、この状態が変化しない限り、第２の記憶手段３の実装方法には構造上の制約が無く、バックアップの圧縮要否やストレージの冗長化などの非機能的な要求に対する自由度が高い。

【発明の効果】

【0042】

本発明のデータ管理装置によれば、どの種の事業サービスにも共通な機能と、特定の事業サービスに必須な機能とを分け、前者は一つ構築して共通に使えるようにすると共に、後者のみ特定の事業サービス用に開発することが可能となり、これまでのメインフレーム中心のブラックボックス化したレガシーシステムの状態ではそれを作り直すのに手間暇の掛かるものが一気に解消できるようになって、グループ企業全体でのシステム規模を圧縮することが可能となるというと言う優れた効果を奏し得る。

【0043】

また、本発明の構成では、新規保険契約も異動も全てイベントとして上記処理手段によって処理され、スライス型データが生成され、且つそれらのスライス型データの少なくともオープン及びクローズ処理がなされて、スライス型データの集合体として表現されることになり、異動のデータを、異動後の内容が反映された新規データ相当として取り扱うことができ、また複数の異動を同時に行う場合は、すべての異動を反映した新規データ相当として取り扱うことができるようになるため、従来の差分履歴型契約データモデルの場合に比べ、複数の異動内容を１つの履歴にまとめて処理することができることになる。さらに、データの照会時にもわざわざデータ合成処理が必要ではなくなる。

【0044】

他方、従来のイベントヒストリ型契約データモデルの場合に比べ、データベース及びデータ構造が１つの構成で済み、データベースの簡略化と保険料などの再計算やデータの妥当性・整合性を検証する別途のシステムの開発が不要となる。

【0045】

加えて、２つ目の発明の構成は、原則的に同時に異動する必然性のないデータ項目の内容を、スライス型データの別エンティティに保持する構成とすることで、スライス型データとは別エンティティのエンゲージメント情報として含まれ、且つこれらの情報は上記スライス型データとは別レイヤーに備えられているため、仮にエンゲージメント期間の異動を行う場合はエンゲージメント情報の異動により行われるので、そのエンゲージメント情報とは別レイヤーのスライス型データのステータスの変更を伴うことはない。これによりその処理負荷が軽くなるだけではなく、システム全体の構成を疎結合化して他のシステムと連携しやすくなると言う効果もある。

【0046】

さらに、３つ目の発明の構成は、上記の第２の記憶手段を有し、異動後のスライス型データのステータスをオープンして追加した後に、その異動が取り消しになった場合であっても、上記処理手段により、該スライス型データのステータスをインバリッドとし、上記第２の記憶手段に記憶された異動対象となってクローズされた異動前のスライス型データのクローズ前のバックアップデータを、上記第１の記憶手段に、そのステータスをオープンにして復元することで異動の取り消しを簡便に行うことを可能とする構成としたため、システム上大掛かり仕組みが必要となる、契約単位のロールバックをしないで、その取り消しが行えることになるといった優れた効果もある。

【0047】

また、このクローズされたスライス型データとそのクローズ前のバックアップデータは異動の取り消しが発生するまでデータの整合性が理論上確保されていることになり、この状態が例外的に変化しない限り、第２の記憶手段の実装方法には構造上の制約が無く、バックアップの圧縮要否やストレージの冗長化などの非機能的な要求に対する自由度が高い。

【図面の簡単な説明】

【0048】

【図1】スライス型データに対し、保険契約管理業務において、新規契約イベントや異動イベントなどがあった場合の、サービス層のサービス情報における処理手段２によるトランザクションを模した実施例１に係るデータ処理説明図である。

【図2】実施例２における図１と同様な処理手段２によるトランザクションを模した実施例２に係るデータ処理説明図である。

【図3】特定日時を指定して保険内容を照会する場合の保険内容の照会をする際の上記実施例２の構成においての照会例を示す説明図である。

【図4】保険契約履歴及び履歴内容の照会をする場合の上記実施例２の構成においての照会例を示す説明図である。

【図5】異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する際に、該処理手段２により、クローズ直前のスライス型データのイメージをバックアップとして記憶すると共に、異動の取り消しが行われた場合に、元のスライス型データがサービス情報として復元される状態を示す実施例３の説明図である。

【図6】実施例１〜実施例３までの構成が実施された場合の、契約データのイベント毎にこのデータ管理装置においてなされた処理毎の細かな内容を、各項目毎に、夫々のイベントで処理手段２が行った処理の内容、各データのステータスの動き、及びそれらの補足内容を示す一覧表である。

【図7】事業固有のサービスにかかるシステムやデータベースは、「サービス層」に構築し、事業会社間で共有可能な情報は、「顧客層」・「ビリング層」に分けて疎結合化して構築する本発明の事業会社間のシステム共有状態を示す説明図である。

【図8】実施例１が適用される保険契約管理システム構成の全体を示す説明図である。

【図9】実施例３が適用される保険契約管理システム構成の全体を示す説明図である。

【図10】保険期間が短く且つ異動の頻度が多い損害保険分野で一般的である差分履歴型契約データモデルの構成を簡単に示す模式図である。

【図11】保険期間が長く生命保険で一般的であるイベントヒストリ型契約データモデルの構成を簡単に示す模式図である。

【発明を実施するための形態】

【0049】

以下、本発明の実施の形態を図示例と共に説明する。

【実施例1】

【0050】

図８は、本発明に係るデータ管理装置の一実施例が適用される保険契約管理システム構成の全体を示す説明図である。本実施例構成では、クラウドに備えられたサーバ群により、後述する第１の記憶手段１及び処理手段２が構成されている。

【0051】

これらのサーバによって構成される保険契約管理システムにあって、上記図７に示されるように、「顧客情報」に関わる機能および金銭の「請求・収納」に関わる機能などの事業会社間で共有可能な情報は、「顧客層」・「ビリング層」に分けて疎結合化して構築されている（顧客層には顧客の情報が、又ビリング層には保険料請求・収納状況が手数料支払い状況と共に管理される）。

【0052】

さらに、ビジネス取引が無ければ存在し得ず、かつ異なる事業会社間でも共通性の高い契約番号、サービス期間などの情報やペイメント情報などを「エンゲージメント層」として定義されている（図中エンゲージメント情報に、上記契約（証券）番号や保険期間等のつながり情報が格納され、またペイメント情報に顧客の支払い手段情報、口座・クレジットカード情報などが格納される）。このような構成により、エンゲージメント層により、事業者は顧客エンゲージメントを基準化して事業会社間を跨って把握することが可能となり、顧客情報を合理的に管理・活用することができるようになっている。

【0053】

さらに、事業固有のサービスにかかるシステムやデータベースは、「サービス層」に構築されている（このサービス情報に、保険の対象、補償、保険料、手数料などの情報が格納される。他にこの層には保険金支払い管理情報がエンゲージメント層とビリング層に紐付けられている）。

【0054】

本実施例構成では、メインフレームに代わって上記クラウドを構成するサーバ群に構成されており、上記サービス層も該サーバ群の１乃至複数のサーバで構成されている。以上の様な構成により、これまでのメインフレーム中心のブラックボックス化したレガシーシステムの状態から、保険契約管理サービスにおける以外のどの種の事業サービスにも共通な機能（図７に示される構成では顧客層、エンゲージメント層及びビリング層における各種情報を記憶及び管理する機能）と、保険契約締結の後保険契約者の請求により現存契約の契約条件の異動処理用に、最適化された本実施例構成が適用される事業サービスに必須な機能とに分けられており、前者は一つ構築してしまうことで共通に使えるようになると共に、後者（図７ではサービス層）のみ、保険契約管理サービス用に開発すれば良くなる。即ち、このような構成によってグループ企業全体でのシステム規模を圧縮することが可能になる。

【0055】

上述のように、本発明構成自身は保険契約管理業務に関わるものだけに適用されるものではないが、本実施例構成では、保険契約管理サービス用に、このサービス層に構築されるものとなる。

【0056】

以上の様なシステム構成において、本実施例に係るデータ管理装置の構成は、図８に示されるように、サービス利用に係るイベント（新規契約イベントや異動イベントなど）の内容及び結果と、少なくともオープン又はクローズのステータスとを保持するデータ群であり、そのデータ群をスライス型データとして記憶する第１の記憶手段１と、そのデータ内容に異動が生じた時は、異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する処理手段２とを備えている。

【0057】

上記図１は、上記スライス型データが、保険契約管理業務において、新規契約イベントや異動イベントなどにより、上記処理手段２によりどのように処理されるのか、図７のサービス層のサービス情報におけるそのトランザクションを模したデータ処理説明図である。

【0058】

ここで、円筒型に示したものがスライス型データのイメージである。そして新規の保険契約があると、処理手段２は、図１の上段右側に示す該保険契約を最初のイベント１として、保険内容００１のスライスを新規に生成し、そのステータスをオープンとし、上記第１の記憶手段に記憶させる。

【0059】

次にその契約に対し、上記異動イベント２が発生したとすると、上記処理手段２は、同図中段に示すように、上記保険内容００１のスライスのステータスをクローズ（中止）に変更すると共に、該異動イベント２を反映する新保険内容００２のスライスを生成し、該スライスのステータスをオープンする。ここでの保険内容００２は、最初に契約された保険内容００１に上記異動イベント２の内容が反映されたものである。これらのスライス型データは、上記処理手段２により、ステータスがクローズされた従前のスライス型データ（保険内容００１）と共に、第１の記憶手段１に記憶される。

【0060】

さらに、別の異動イベント３が発生したとすると、上記処理手段２は、上記保険内容００２のスライスのステータスをクローズ（中止）に変更すると共に、該異動イベント３を反映する新保険内容００３のスライスを生成し、該スライスのステータスをオープンする。ここでの保険内容００３は、保険内容００２に上記異動イベント３の内容が反映されたものである。これらのスライス型データも、上記処理手段２により、第１の記憶手段１に記憶される。

【0061】

このように、本実施例構成では、一つのイベント情報が発生する度に、新たなスライスが生成され、それがオープンの状態に保たれつつ、従前のスライス型データがクローズされ、これらのスライス型データの集合体で表現されると共に、現在どのスライス型データがオープンにされているかを確認することで、現在の契約内容がどのようになっているかを確認できる。また、このスライス型データを辿ることで、過去にどのようなイベントが生じたかも簡単に分かるようになる。即ち、本実施例構成では、同一エンティティのスライス型データは、新規、異動等のどの時点でも全て同一のデータ構造であり、同一のデータベースに格納され、同一のアプリケーション・インタフェースで処理が可能である。

【0062】

これらは、処理手段２を構成するプロセッサの格段の性能アップと第１の記憶手段１を構成する各種ストレージの大幅な性能アップと記憶単価が安くなったことで達成可能となった。

【実施例2】

【0063】

図２に本発明の２つ目の実施例構成が示されている。同図では、上記実施例１の構成が実施されるサービス層の上位層に、この契約の保険期間（この図では保険期間１年）が、図７に示すようなエンゲージメント層にエンゲージメント情報として格納されている状態が示されている。原則的に同時に異動する必然性のないデータ項目の内容（ここでは上記保険期間）は、スライス型データの別エンティティ（エンゲージメント層のエンゲージメント情報）に保持されることになる。仮に、上記保険期間に当たるエンゲージメント期間の異動を行う場合はエンゲージメント情報の異動により行われて、そのエンゲージメント情報とは別レイヤーのスライス型データのステータスの変更を伴わないことになる。

【0064】

この図における、基本的なサービス層のサービス情報におけるそのトランザクションは、図１と同様であり、その詳細は省略する。

【0065】

図３は、第１の記憶手段１に記憶されたスライス型データの最新状態のイメージ図であり、過去又は未来の特定日時を指定して保険内容を照会する場合の保険内容の照会をする際の上記実施例２の構成においての照会例を示す説明図である。

【0066】

スライス型データは、有効開始日時（ｆｒｏｍ）と有効終了日時（ｔｏ）を保持しているので、同図に示すように指定された日付時点で有効なスライス型データ（ステータスを問わない）をすべて抽出して表示すればよい。

【0067】

指定された日付が新規契約（保険内容００１）当初の時点１であった場合、その時点で有効な、第１の記憶手段１に記憶されたスライス型データである保険内容００１が読み出され提示される。

【0068】

さらに指定された日付が時点２では、その時点で有効な、第１の記憶手段１に記憶された次のスライス型データである保険内容００２が読み出され提示される。

【0069】

このように、本実施例構成では、特定の証券番号の指定された日付時点の保険内容を照会する際に、関連するスライス型データのステータスを問わず、保険内容を第１の記憶手段１から読み出して提示するのみで良く、上記差分履歴型契約データモデルの場合と比べ、本実施例構成では、わざわざデータ合成処理が必要なくなる。

【0070】

図４は、保険契約内容の異動履歴及び履歴内容の照会をする場合の上記実施例２の構成においての照会例を示す説明図である。

【0071】

保険契約の履歴照会を行う場合は、全てのスライス型データ、即ちステータスがオープンかクローズかに拘わらず全ての保険内容が処理手段２により抽出され、一覧表示されることになる。他方保険契約の履歴の内容の照会を行う場合は、一連のスライス型データのうち一つを指定して実施することになる。

【実施例3】

【0072】

上記２つの実施例構成では、新規の保険契約や異動などのイベントが発生する毎に、処理手段は、新たな保険内容のスライスを新規に生成し、そのステータスをオープンとすると共に、その直前に前のスライスをクローズすることになる。こうした場合に、このイベント自身を取り消ししたい等の時（異動の取り消しをしたい場合）は、以上の構成のままでは簡単にその取り消しが出来ない。

【0073】

そのため、本実施例構成では、上記スライス型データのステータスとして少なくともオープン、クローズ及びインバリッドのステータスを含むものとするが、このような異動の取り消しを行う際は、取り消しするスライス型データのステータスをオープンからインバリッド（無効）とし、さらにその異動前のスライス型データのステータスをクローズからオープンにする必要があるが、この異動前のスライス型データのステータスがクローズされる際にはステータス以外にも精算保険料額などのデータ項目が同時に更新されている。このため、すべてのデータ項目内容を復元することができない。

【0074】

本発明の３つ目の実施例構成は、上記２つの実施例構成に加え、図９に示すように、処理手段２で、異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する際に、該処理手段２により、クローズ直前のスライス型データのイメージをバックアップとして記憶する第２の記憶手段３を有する構成である。

【0075】

本実施例で行われるトランザクションにつき、図５を用いて説明する。ここでは、既にある（第１の記憶手段１に記憶されている）保険内容００１のスライス型データに対し、異動となるイベント（図中変更イベント）があるので、上記処理手段２は、異動前のスライス型データ（保険内容００１）のステータスをクローズし（図中中止；Slice000のステータスをCloseに変更）、異動後のスライス型データ（保険内容００２）のステータスをオープンして追加する（図中新規；新規Slice001を生成）が、その際に、該処理手段２は、クローズ直前のスライス型データ（保険内容００１）のイメージをバックアップとして第２の記憶手段３に記憶させる（Slice000の直前の内容を第２の記憶手段３にバックアップ）。

【0076】

他方、異動後のスライス型データ（保険内容００２）のステータスをオープンして追加した際に、この異動イベント自身を取り消ししたい事態が生じた時（異動の取り消しをしたい時；図中変更の取消）、即ち、異動後のスライス型データ（保険内容００２）のステータスをオープンして追加した際に、そのステータスが取り消しになった場合（図中取消；Slice001の取消）、上記処理手段２は、同図に示すように、該スライス型データのステータスをインバリッド（図中Ｉｎｖａｌｉｄ）とし、上記第２の記憶手段３に記憶された異動対象となってクローズされたスライス型データを、上記第１の記憶手段１に対して、そのステータスをオープンにして記憶させる復元処理を行わしめる（図中復元；第２の記憶手段３からSlice000をステータスオープンにして復元）。

【0077】

原則として、クローズされたスライス型データおよびバックアップされた第２の記憶手段３には「異動の取り消し」以外の更新は行われない。つまり、「異動の取り消し」が発生するまでこれらのデータ間の整合性が理論上確保されていることになる。このため、この状態が変化しない限り、第２の記憶手段３の実装方法には構造上の制約が無く、バックアップの圧縮要否やストレージの冗長化などの非機能的な要求に対する自由度が高い。つまり、上記第１の記憶手段１と第２の記憶手段３とは物理的に別個のものであっても同じものであっても良い。

【0078】

図６は、実施例１〜実施例３までの構成が実施された場合の、契約データのイベント毎にこのデータ管理装置においてなされた処理内容を細分化し、開始型・終了型の分類、新規・更改・解約・中止・復元・取消（取り消し）・満期・取消の取消（取り消しの取り消し）・確定精算の「サブ・イベント名」、前記各サブ・イベントで処理手段２が行った処理の内容（機能内容）、各データのステータスの動き、及びそれらの補足内容を示す一覧表である。尚、下段の表は、ステータスの内容（意味）を示している。

【0079】

同表（同図）において、契約内容の「異動」を１つのイベントとしたとき、異動前「新規」の「中止」と異動後「新規」のサブ・イベントの組み合わせで表現される。サブ・イベントは、大きく「開始型」と「終了型」に分類される。（契約番号と保険期間は元のままとする。）

【0080】

このような契約管理を行うデータ管理装置では、この「サブ・イベント名」単位で機能が構築されることになり、契約内容を変更する機能は大幅に簡素化されることになることが分かる。

【0081】

従って、現在の多くのシステムのように異動内容毎に機能を構築する必要はなくなり、システム開発コスト、開発期間が大幅に削減される。

【0082】

以上詳述したように、上記実施例構成によれば、「顧客情報」に関わる機能および金銭の「請求・収納」に関わる機能などの事業会社間で共有可能な情報は、「顧客層」・「ビリング層」に分けて疎結合化して構築する（顧客層には顧客の情報を、又ビリング層には保険料請求・収納状況を手数料支払い状況と共に管理する）と共に、ビジネス取引が無ければ存在し得ず、かつ異なる事業会社間でも共通性の高い契約番号、サービス期間などの情報やペイメント情報などを「エンゲージメント層」として定義（図中エンゲージメント情報に、上記契約（証券）番号や保険期間等のつながり情報が格納され、またペイメント情報に顧客の支払い手段情報、口座・クレジットカード情報などが格納される）しており、このような事業会社間で共有可能な情報は、一つ作ってしまえば、後に再構築する必要はなく、事業固有のサービスにかかるシステムやデータベースは、「サービス層」として別途構築すれば良い。従って、本実施例構成では、どの種の事業サービスにも共通な機能と、特定の事業サービスに必須な機能とを分けることが出来るようになり、前者は一つ構築してしまえば共通に使え、後者のみ特定の事業サービス用に開発すれば足り、グループ企業全体でのシステム規模を圧縮することが可能となる。

【0083】

また上記実施例１の構成と差分履歴型契約データモデルの場合とを比べると、実施例１の構成では、有効開始日時（ｆｒｏｍ）と有効終了日時（ｔｏ）を保持し、複数の異動内容を１つの履歴にまとめて処理することができる、即ち、異動のデータを、異動後の内容が反映された新規データ相当として取り扱うことができると共に、複数の異動を同時に行う場合は、すべての異動を反映した新規データ相当として取り扱うことができるようになるようになる。またデータの照会時にもわざわざデータ合成処理が必要ではなくなる。

【0084】

上記実施例１の構成とイベントヒストリ型契約データモデルの場合と比べると、本実施例構成では、データベース及びデータ構造が１つの構成で済み、保険会社が将来の保険金給付や解約返戻金支払い等に充てるために保険料や運用収益を財源として積み立てておく必要のある責任準備金や保険料を、異動内容毎に再計算し、データの妥当性、異動前後の整合性等を確保するシステム設計が別途必要になると言うことはなく、データベースの簡略化と保険料などの再計算やデータの妥当性・整合性を検証する別途のシステムの開発が不要となる。

【0085】

また、本実施例構成では、同一エンティティのスライス型データは、新規、異動等のどの時点でも全て同一のデータ構造であり、同一のデータベース（第１の記憶手段１）に格納され、同一のアプリケーション・インタフェースで処理が可能であると言う特性を有することになる。

【0086】

次に実施例２の構成によれば、原則的に同時に異動する必然性のないデータ項目の内容、サービスの提供における顧客との接点に関する情報を保持するエンゲージメント情報として含む場合、該エンゲージメント情報の異動は、そのエンゲージメント情報とは別レイヤーのサービス層にあるスライス型データのステータスの変更を伴わないことになる。これによりその処理負荷が軽くなるだけではなく、システム全体の構成を疎結合化して他のシステムと連携しやすくなると言う効果もある。

【0087】

加えて異動を取り消す際には、従来構成では、契約単位にイベントヒストリデータベースの更新をロールバックする機能が必要となり、この取り消しのためだけに、そのようなシステム設計を必要として、異動処理のために係るコスト・工数・期間において、システム構築上大きな問題となっていたが、上記実施例３の構成によれば、システム上大掛かり仕組みが必要となる、契約単位のロールバックをせずに、その取り消しが行えるようになり、システム構築が簡単にできるようになる。

【0088】

ここで、実施例３のより詳細な効果につき補足しておくと、原則として、クローズされたスライス型データおよびバックアップを取る第２の記憶手段３には「異動の取り消し」以外の更新は行われない。つまり、「異動の取り消し」が発生するまでデータの整合性が理論上確保されていることになる。このため、この状態が変化しない限り、第２の記憶手段３の実装方法には構造上の制約が無く、バックアップの圧縮要否やストレージの冗長化などの非機能的な要求に対する自由度が高いと言う効果もある。

【0089】

尚、本発明のデータ管理装置は、上述の実施例１〜３にのみ限定されるものではなく、例えば保険契約等に限らず、金融や証券など、他のあらゆる種類の契約におけるデータ管理において、本発明の要旨を逸脱しない限り、種々変更を加え得ることは勿論である。

【産業上の利用可能性】

【0090】

本発明のデータ管理装置は、保険、金融、証券や他のサービス分野の契約における、種々のデータ管理に利用可能である。

【符号の説明】

【0091】

１ 第１の記憶手段
２ 処理装置
３ 第２の記憶手段

【要約】

【課題】 契約条件の異動のデータを、異動後の内容が反映された新規データ相当として取り扱うことができ、また複数の異動を同時に行う場合は、すべての異動を反映した新規データ相当として取り扱うことができるデータ管理装置を提供する。
【解決手段】 サービス利用に係るイベント（新規契約イベントや異動イベントなど）の内容及び結果と、オープン又はクローズのステータスとを保持するデータ群であり、そのデータ群をスライス型データとして記憶する第１の記憶手段１と、そのデータ内容に異動が生じた時は、異動前のスライス型データのステータスをクローズし、異動後のスライス型データのステータスをオープンして追加する処理手段２とを備えている。
【選択図】 図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】