(57)【特許請求の範囲】
【請求項１】
メッセージを保管し、前記保管するメッセージについてのメッセージ保管料金の徴収を支援するメッセージ保管装置であって、
保険契約者ごとに、前記メッセージ保管料金のうち、請求すべき時期が到来している金額である請求金額が記憶される請求金額情報と、
前記保険契約者ごとに、前記メッセージ保管料金を引き落とす引き落とし口座、前記引き落とし口座の残高、前記メッセージ保管料金を引き落とすことができない場合に自由な資金化を禁止することが可能な担保口座、前記担保口座の残高、及び、前記担保口座の残高のうち実際に資金化を禁止する残高が記憶される担保設定金額情報と、
が格納される記憶部と、
前記請求すべき時期が到来すると、
前記請求金額情報を参照して、前記請求金額を徴収すべき前記保険契約者を特定し、
前記担保設定金額情報を参照して、前記特定した保険契約者の引き落とし口座を特定し、
前記特定した引き落とし口座の残高から、前記請求金額を控除したうえで記憶し、
前記特定した引き落とし口座の残高から、前記請求金額を控除することができない場合は、
前記担保設定金額情報を参照して、前記特定した保険契約者の担保口座を特定し、
前記特定した担保口座の残高の一部又は全部を、前記担保口座の残高のうち実際に資金化を禁止する残高として記憶する制御部と、
を有することを特徴とするメッセージ保管装置。
【請求項２】
前記担保設定金額情報は、
前記保険契約者ごとに、さらに、前記引き落とし口座の優先順位、及び、前記担保口座の優先順位を記憶しており、
前記制御部は、
前記引き落とし口座の優先順位に基づいて、前記特定した引き落とし口座の残高から、前記請求金額を控除したうえで記憶し、
前記担保口座の優先順位に基づいて、前記特定した担保口座の残高の一部又は全部を、前記担保口座の残高のうち実際に資金化を禁止する残高として記憶すること、
を特徴とする請求項１に記載のメッセージ保管装置。
【請求項３】
メッセージを保管し、前記保管するメッセージについてのメッセージ保管料金の徴収を支援するメッセージ保管装置であって、
保険契約者ごとに、前記メッセージ保管料金を引き落とすことができない場合に自由な資金化を禁止することが可能な担保口座、前記担保口座の残高、及び、前記担保口座の残高のうち実際に資金化を禁止する残高が記憶される担保設定金額情報が格納される記憶部と、
前記保険契約者が死亡した旨の情報を検知すると、
前記メッセージ保管料金のうち請求すべき時期が到来している金額である請求金額が所定の閾値以上である場合は、
前記担保設定金額情報を参照して、前記死亡した保険契約者の担保口座を特定し、
前記特定した担保口座の残高の一部又は全部を、前記担保口座の残高のうち実際に資金化を禁止する残高として記憶する制御部と、
を有することを特徴とするメッセージ保管装置。
【請求項４】
前記担保設定金額情報は、
前記保険契約者ごとに、さらに、前記担保口座の優先順位を記憶しており、
前記制御部は、
前記担保口座の優先順位に基づいて、前記特定した担保口座の残高の一部又は全部を、前記担保口座の残高のうち実際に資金化を禁止する残高として記憶すること、
を特徴とする請求項３に記載のメッセージ保管装置。
【請求項５】
前記制御部は、
前記担保口座において保管する資産の、ある期間における市場価格の変化に関する情報を入手し、
前記市場価格の変化に関する情報に基づいて、前記担保口座において保管する資産ごとに、前記担保口座の残高のうち実際に資金化を禁止する残高を決定すること、
を特徴とする請求項１又は３に記載のメッセージ保管装置。
【請求項６】
前記自由な資金化を禁止することが可能な担保口座は、
保険金受取人に対して支払われる保険金に関する口座であり、
前記担保口座の残高のうち実際に資金化を禁止する残高は、
前記保険金の支払時において、保険金受取人に対する支払いが禁止される金額であること、
を特徴とする請求項１又は３に記載のメッセージ保管装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージ保管装置に関する。
【背景技術】
【０００２】
近年、生命保険会社等の金融機関が、顧客のメッセージを預かるサービスを行うことが多くなると予想される。例えば、夫を被保険者兼保険契約者とし、妻を保険金受取人とする生命保険契約において、夫が生前、妻あてのメッセージを作成し、保険者である生命保険会社に預ける。夫が生存している期間は、夫以外の者がこのメッセージを視聴・更新することができない。そして、夫が死亡したという情報を生命保険会社が入手すると、生命保険会社は、このメッセージを妻に対して開示する。このようなメッセージは、情愛あふれる家族間のコミュニケーションに資することはもちろんである。しかしながら、それだけでなく、速やかな保険金受け取り手続、円満な相続手続に繋がり、生命保険会社等の営業面にもメリットがある。
特許文献１が開示するメッセージ保管システムは、このようなメッセージを保険契約者（被保険者を兼ねることが多い）から預かる。そして、生命保険会社等から入手される情報の種類に応じてメッセージに対して行う様々な処理（変更不可能に固定する、消去する、開示する）を予め記憶しておく。そして、例えば死亡情報を受信すると、メッセージ保管システムは、メッセージの固定、開示等の処理を実際に行う。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第４４２７０９１号公報（請求項１）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
生命保険会社等がメッセージを保管するには、当然のことながらコストがかかる。そして、通常、保険料金にはそのコストが含まれている。ただし、保険契約者が高齢になると、保険契約上、保険料金の徴収は行われなくなる場合が多い。そこで、生命保険会社等は、メッセージ保管に係るコストを、保険契約者から別途徴収することになる。
しかしながら、例えば、メッセージである映像の情報量が多くなり、保管料金が情報量に比例して高額になった場合は当該別途徴収を行うことは実際には難しい。また、例えば高齢者から、当該別途徴収を行うことも実際には難しい。相続が発生し、金融機関における自動引き落としが不可能になった場合、未収金の保全は特に困難となる。特許文献１の発明は、このようなコストの回収を全く想定していない。
そこで、本発明は、生命保険会社等のメッセージ保管に関する未収金の保全を、簡便かつ確実に行うことを目的とする。
【課題を解決するための手段】
【０００５】
本発明のメッセージ保管装置は、メッセージを保管し、保管するメッセージについてのメッセージ保管料金の徴収を支援するメッセージ保管装置であって、保険契約者ごとに、メッセージ保管料金のうち、請求すべき時期が到来している金額である請求金額が記憶される請求金額情報と、保険契約者ごとに、メッセージ保管料金を引き落とす引き落とし口座、引き落とし口座の残高、メッセージ保管料金を引き落とすことができない場合に自由な資金化を禁止することが可能な担保口座、担保口座の残高、及び、担保口座の残高のうち実際に資金化を禁止する残高が記憶される担保設定金額情報と、が格納される記憶部と、請求すべき時期が到来すると、請求金額情報を参照して、請求金額を徴収すべき保険契約者を特定し、担保設定金額情報を参照して、特定した保険契約者の引き落とし口座を特定し、特定した引き落とし口座の残高から、請求金額を控除したうえで記憶し、特定した引き落とし口座の残高から、請求金額を控除することができない場合は、担保設定金額情報を参照して、特定した保険契約者の担保口座を特定し、特定した担保口座の残高の一部又は全部を、担保口座の残高のうち実際に資金化を禁止する残高として記憶する制御部と、を有することを特徴とする。
その他の手段については、発明を実施するための形態において詳述する。
【発明の効果】
【０００６】
本発明によれば、生命保険会社等のメッセージ保管に関する未収金の保全を、簡便かつ確実に行うことができる。
【図面の簡単な説明】
【０００７】
【図１】本実施形態に係るメッセージ保管システムの構成を説明する図である。
【図２】本実施形態に係るメッセージを説明する図である。
【図３】本実施形態に係る請求金額情報の一例を示す図である。
【図４】本実施形態に係る担保設定金額情報の一例を示す図である。
【図５】本実施形態に係る金融機関提供情報の一例を示す図である。
【図６】本実施形態に係る市場情報の一例を示す図である。
【図７】本実施形態に係る支払方法入力画面の一例を示す図である。
【図８】本実施形態に係るメッセージ受信処理手順のフローチャートである。
【図９】本実施形態に係る支払方法入力処理手順のフローチャートである。
【図１０】本実施形態に係る引き落とし・担保設定処理手順のフローチャートである。
【図１１】本実施形態に係る即時担保設定処理手順のフローチャートである。
【図１２】本実施形態に係る担保評価替え処理手順のフローチャートである。
【発明を実施するための形態】
【０００８】
以下、本発明を実施するための形態（「本実施形態」という）を、図等を参照しながら詳細に説明する。
【０００９】
（用語）
生命保険契約は、ある人間の死亡を停止条件として保険金を支払うことを内容とする契約である。生命保険契約は、共済契約（主として生命共済）も含む概念である。生命保険契約には２人の契約当事者が存在する。保険契約者は、契約当事者のうち、保険金の原資となる保険料を他の保険当事者に支払う者である。保険者は、契約当事者のうち、保険金の原資となる保険料を他の保険当事者から受け取り、保険料を市場等で運用するとともに、ある人間の死亡を停止条件として保険金を支払う者である。被保険者は、その死亡が前記停止条件となる者（「ある人間」）である。保険金受取人は、保険金を受け取る者である。メッセージ受取人は、メッセージを受け取る者である。そして、多くの場合、保険契約者兼被保険者がメッセージを作成する。
【００１０】
典型的な生命保険契約においては、保険契約者は支払能力を有する個人であり、保険者は生命保険会社等の法人である。被保険者は、個人であれば誰でもよい。そして、多くの場合、保険契約者が被保険者を兼ねている。保険金受取人は、個人であっても法人（慈善活動団体等）であってもよい。多くの場合、保険金受取人は、被保険者によって扶養されている者である。メッセージ受取人もまた、個人であっても法人（慈善活動団体等）であってもよい。多くの場合、メッセージ受取人は、保険金受取人と同一である。
以下の説明では、単純化のために、保険契約者は被保険者と同一であり、保険金受取人はメッセージ受取人と同一であるものとする。さらに、保険契約者がメッセージを作成し、保険者にメッセージの保管を依頼するものとする。
【００１１】
図１に沿って、メッセージ保管システムの構成を説明する。メッセージ保管システムは、メッセージ保管装置１、金融機関サーバ２、取引所サーバ３及び顧客端末装置４を有する。これらは、ネットワーク５を介して相互に通信可能である。
【００１２】
メッセージ保管装置１は、一般的なコンピュータであり、メッセージ保管料金の徴収及び担保の設定を行う（詳細後記）。メッセージ保管装置１は、通常、保険者（生命保険会社等）によって、又は、保険者に対してメッセージ保管サービスを提供する主体（保険代理店等）によって管理され、その数は１台である。
金融機関サーバ２もまた、一般的なコンピュータであり、メッセージ保管装置１に対して、メッセージ保管料金を引き落とす口座残高等の情報を提供し、実際に引き落としを実行する。金融機関サーバ２は通常、金融機関の数だけ存在する。
取引所サーバ３は、メッセージ保管装置１に対して、凍結可能資産（詳細後記）の市場価格を提供する。取引所サーバ３は通常、市場の数だけ存在する。
顧客端末装置４は、保険契約者が操作する一般的なコンピュータである。
【００１３】
（メッセージ保管装置）
メッセージ保管装置１は、中央制御装置１１、主記憶装置１２、補助記憶装置１３、入力装置１４、出力装置１５及び通信インタフェース（ＩＦ）１６を有する。これらは、相互にバスで接続されている。補助記憶装置１３は、請求金額情報３１、担保設定金額情報３２、金融機関提供情報３３、市場情報３４及びメッセージ３５を格納する（詳細後記）。請求金額管理部２１及び担保管理部２２は、プログラムである。以降において、「○○○部は、」と動作の主体を記した場合は、中央制御装置１１が、プログラムとしての○○○部を補助記憶装置１３から読み出し、主記憶装置１２にロードしたうえで、当該プログラムの機能（詳細後記）を実行するものとする。
【００１４】
金融機関サーバ２、取引所サーバ３及び顧客端末装置４のそれぞれは、相互にバスで接続された、中央制御装置、主記憶装置、補助記憶装置、入力装置、出力装置及び通信インタフェースを有する（図示せず）。
【００１５】
（メッセージ）
図２に沿って、メッセージ３５を説明する。メッセージ３５は、保険契約者が死亡した後、保険金受取人が視聴するメッセージの例である。メッセージ３５は、補助記憶装置１３に格納可能な電子データであり、顧客ＩＤ４１、メッセージＩＤ４２、預かり期間４３、メッセージ本文４４、添付画像データ４５及び添付音声データ４６を含む。
【００１６】
顧客ＩＤ４１は、保険契約者を一意に特定する識別子である。
メッセージＩＤ４２は、保険契約者が保険者に預けているメッセージ３５を一意に特定する識別子である。
預かり期間４３は、保険者がメッセージ３５を預かる期間であり、期間の始期を示す年月日及び期間の終期を示す年月日を有する。
メッセージ本文４４は、メッセージ受取人が読む文字データである。
添付画像データ４５は、メッセージ受取人が見る画像データ（連続画像データであってもよい）である。
添付音声データ４６は、メッセージ受取人が聴く音声データである。添付画像データ４５と添付音声データ４６が一体になっていてもよい。
【００１７】
（請求金額情報）
図３に沿って、請求金額情報３１を説明する。請求金額情報３１においては、顧客ＩＤ欄１０１に記憶された顧客ＩＤに関連付けて、メッセージＩＤ欄１０２にはメッセージＩＤが、預かり期間欄１０３には預かり期間が、メッセージ保管料金欄１０４にはメッセージ保管料金が、請求パタン欄１０５には請求パタンが、請求金額欄１０６には請求金額が記憶されている。
【００１８】
顧客ＩＤ欄１０１の顧客ＩＤは、前記した顧客ＩＤである。
メッセージＩＤ欄１０２のメッセージＩＤは、前記したメッセージＩＤである。
預かり期間欄１０３の預かり期間は、前記した預かり期間である。
メッセージ保管料金欄１０４のメッセージ保管料金は、預かり期間においてメッセージを預かることに対する報酬金額である。
請求パタン欄１０５の請求パタンは、メッセージ保管料金を徴収する方法である。ここでは、預かり期間の毎月末日に分割して徴収する「毎月末」、預かり期間の終期に一括して徴収する「一括後払」の２種があるものとする。
請求金額欄１０６の請求金額は、メッセージ保管料金のうち、現在時点において徴収すべき時期が到来しており、かつ、未収である金額である。
【００１９】
（担保設定金額情報）
図４に沿って、担保設定金額情報３２を説明する。担保設定金額情報３２においては、顧客ＩＤ欄１１１に記憶された顧客ＩＤに関連付けて、引き落とし口座ＩＤ欄１１２には引き落とし口座ＩＤが、引き落とし口座残高欄１１３には引き落とし口座残高が、支払優先順位欄１１４には支払優先順位が、担保口座ＩＤ欄１１５には担保口座ＩＤが、凍結可能資産種類欄１１６には凍結可能資産種類が、担保口座残高欄１１７には担保口座残高が、担保設定優先順位欄１１８には担保設定優先順位が、担保設定金額欄１１９には担保設定金額が記憶されている。
【００２０】
顧客ＩＤ欄１１１の顧客ＩＤは、前記した顧客ＩＤである。
引き落とし口座ＩＤ欄１１２の引き落とし口座ＩＤは、メッセージ保管料金を引き落とすことが可能な要求払性預金口座（以降「引き落とし口座」とも呼ぶ）を一意に特定する識別子であり、金融機関名、支店名及び口座番号の組合せを、文字、数字等で表記したものである。図４においては「Ｂ０００１」等のように単純化して記載する。金融機関としては、保険者である生命保険会社そのもの、銀行、証券会社等を想定している。
引き落とし口座残高欄１１３の引き落とし口座残高は、引き落とし口座の残高である。
支払優先順位欄１１４の支払優先順位は、１又は複数の引き落とし口座間において、保険契約者がメッセージ保管料金の支払いに充当することを希望する優先順位である。
【００２１】
担保口座ＩＤ欄１１５の担保口座ＩＤは、保険者がメッセージ保管料金の未収金を保全するために凍結することが可能な資産であって保険契約者が保有する資産を受託（保護預かり）している口座を一意に特定する識別子である。当該資産を、以降「凍結可能資産」とも呼び、当該口座を、以降「担保口座」とも呼ぶ。担保口座ＩＤは、金融機関名、支店名及び口座番号の組合せを、文字、数字等で表記したものである。当該金融機関としては、保険者である生命保険会社そのもの、銀行、証券会社等を想定している。ここでの「凍結する」という語の意味は、「保険契約者又はその相続人による自由な資金化を不可能にする」という意味である。よって、「凍結」は、資産に対する質権の設定、譲渡担保の設定のような法的手段も含み、単に「支払停止のフラグを立てる」のようなコンピュータ操作上の簡便な手段も含む。
【００２２】
凍結可能資産種類欄１１６の凍結可能資産種類は、凍結可能資産のカテゴリである。凍結可能資産種類は、例えば、「定期預金」、「日本国債」、「○社株式」、「終身生命保険」等が想定される。さらに、凍結可能資産種類として、保険契約に係る「満期金」、「解約払戻金」、「保険金」等を想定してもかまわない。例えば、保険契約においては、保険期間の終期に保険契約を終了すると、保険契約期間中の保険金の運用益等を原資とする「解約払戻金」が保険契約者に対して支払われる場合がある（終身型ではない、掛け捨て型の有期契約等）。したがって、「解約払戻金」も凍結可能資産となり得る。同様に、定期型や終身型を含む保険契約全般において、被保険者の死亡時に保険金受取人が受け取る「保険金」そのもの又はその一部、及び、保険契約者が受け取る「満期金」も凍結可能資産となり得る。
【００２３】
なお、当該「保険金」そのもの又はその一部（まとめて単に「保険金」と呼ぶ）は、他の凍結可能資産とは、以下の点において性質が異なる。すなわち、（１）「保険金」は、「保険金」が担保であると決定された時点では、未だ支払われていない。（２）被保険者が死亡し「保険金」が実際に支払われた場合であっても、当該「保険金」は、保険契約者に属する財産ではなく、保険金受取人に属する財産である。
【００２４】
担保口座残高欄１１７の担保口座残高は、凍結可能資産の額面金額である（市場価格ではない）。
担保設定優先順位欄１１８の担保設定優先順位は、１又は複数の担保口座間において、保険契約者が担保に提供することを希望する（「凍結」されることを許容する）優先順位である。なお、保険契約者が優先順位を定めない場合は、「ｆｒｅｅ」が記憶される。
担保設定金額欄１１９の担保設定金額は、担保口座残高のうち、保険者が「凍結」した額面金額である。凍結可能資産種類が「保険金」である場合、担保設定金額は、保険金の支払時において、保険金受取人に対する保険金の支払いを禁止する金額となる。
なお、「−」は、その欄に値が存在しないことを示す。欄１１２〜欄１１４に値が記憶されているレコードの欄１１５〜欄１１９には「−」が記憶されている。欄１１５〜欄１１９に値が記憶されているレコードの欄１１２〜欄１１４には「−」が記憶されている。「・・・」は、何らかの値が記憶されていることを省略的に示している。
【００２５】
図４の１〜６行目のレコードに注目すると、以下のことがらがわかる。
（１）保険契約者「Ｃ０００１」は、引き落とし口座として、「Ｂ０００１」、「Ｂ０００２」及び「Ｂ０００３」を指定している。
（２）まず「Ｂ０００１」からメッセージ保管料金を引き落とし、「Ｂ０００１」から引き落とすことができない場合は「Ｂ０００２」から引き落とし、「Ｂ０００２」からも引き落とすことができない場合は「Ｂ０００３」から引き落とす、ということを保険契約者は希望している。
（３）現在、引き落とし口座の残高は、「Ｂ０００１」が「２５００円」であり、「Ｂ０００２」が「２０００円」であり「Ｂ０００３」が「３０００円」である。
【００２６】
（４）保険契約者「Ｃ０００１」は、凍結可能資産として、担保口座「Ｂ０００４」に定期預金を、担保口座「Ｂ０００５」に日本国債を、担保口座「Ｂ０００６」にＡ社株式を預託している。そして、それらの残高は、それぞれ、「１００００００円」、「５０００００円」及び「５０００００円」である。
（５）引き落とし口座のいずれからも引き落としができない場合、まず担保口座「Ｂ０００４」の凍結可能資産が凍結される。担保口座「Ｂ０００４」の凍結可能資産が全額凍結されただけでは不充分である場合、担保口座「Ｂ０００５」の凍結可能資産が凍結される。担保口座「Ｂ０００５」の凍結可能資産が全額凍結されてもなお不充分である場合、担保口座「Ｂ０００６」の凍結可能資産が凍結される、ということを保険契約者は希望（許容）している。
（６）担保口座「Ｂ０００４」の担保口座残高「１００００００円」のうち、「９６０円」が凍結されている。
【００２７】
（金融機関提供情報）
図５に沿って、金融機関提供情報３３を説明する。金融機関提供情報３３においては、顧客ＩＤ欄１２１に記憶された顧客ＩＤに関連付けて、金融機関ＩＤ欄１２２には金融機関ＩＤが、情報種類欄１２３には情報種類が、年月日欄１１４には年月日が記憶されている。
【００２８】
顧客ＩＤ欄１２１の顧客ＩＤは、前記した顧客ＩＤである。
金融機関ＩＤ欄１２２の金融機関ＩＤは、金融機関を一意に特定する識別子である。ここでは、保険契約者に関する情報を保険者に提供した金融機関を特定する。
情報種類欄１２３の情報種類は、保険者が他の金融機関（又は金融機関である自分自身）から提供を受ける、保険契約者に関する情報のカテゴリである。情報種類としては、例えば、「相続開始」、「死亡」、「生命保険金支払い」、「住所変更」等があってよい。「相続開始」は、保険契約者と取引があった銀行が、保険契約者の死亡を相続人から知らされた際に、その旨を保険者に通知することを示す。「死亡」は、（他の）生命保険会社が、保険契約者の死亡を保険金受取人から知らされた際に、その旨を保険者に通知することを示す。「生命保険金支払い」は、（他の）生命保険会社が、保険金を支払った際に、その旨を保険者に通知することを示す。「住所変更」は、保険契約者と取引があった銀行又は（他の）生命保険会社が、保険契約者から住所を変更する届出を受けた際に、その旨を保険者に通知することを示す。
年月日欄１２４の年月日は、保険者が、金融機関から保険契約者に関する情報を受け取った年月日である。
【００２９】
（市場情報）
図６に沿って、市場情報３４を説明する。市場情報３４においては、凍結可能資産種類欄１３１に記憶された凍結可能資産種類に関連付けて、市場名称欄１３２には市場名称が、格付欄１３３には格付けが、期間欄１３４には期間が、最高値欄１３５には最高値が、最安値欄１３６には最安値が、平均欄１３７には平均値が、標準偏差欄１３８には標準偏差が、担保掛目欄１３９には担保掛目が記憶されている。
【００３０】
凍結可能資産種類欄１３１の凍結可能資産種類は、前記した凍結可能資産種類と同じである。
市場名称欄１３２の市場名称は、凍結可能資産が取引される市場の名称である。
格付欄１３３の格付は、凍結可能資産（有価証券等）の発行体の支払能力を示す指標である。ここでは、格付は、「ａａａ」、「ａａ」、「ａ」、「ｂｂｂ」、「ｂｂ」及び「ｂ」の何れかであるものとし、この順番にしたがって徐々に支払能力が落ちていく。
期間欄１３４の期間は、凍結可能資産の市場価格が取得できる期間であり、その期間の始期の年月日及び終期の年月日を有する。
最高値欄１３５の最高値は、期間における凍結可能資産の市場価格の最高値である。
最安値欄１３６の最安値は、期間における凍結可能資産の市場価格の最低値である。
なお、最高値及び最安値は、国債のような有価証券については、額面１万円当たりの市場価格で示し、株式のような有価証券については、１取引単位当たりの市場価格で示す。
【００３１】
平均欄１３７の平均値は、期間における凍結可能資産の市場価格（例えば毎日の終値）の平均値である。
標準偏差欄１３８の標準偏差は、期間における凍結可能資産の市場価格（例えば毎日の終値）の標準偏差（ばらつきの度合い）である。
担保掛目欄１３９の担保掛目は、担保設定金額（図４欄１１９）の、その凍結可能資産によって担保される債権額（メッセージ保管料金の未収金額）に対する比率（百分率）であり、いわば安全率である。凍結可能資産の値動きが大きいほど、担保掛目は大きい。
【００３２】
（メッセージ受信処理手順）
図７は後回しにし、図８に沿ってメッセージ受け入れ処理手順を説明する。
ステップＳ２０１において、請求金額管理部２１は、メッセージ３５（図２）を受信する。具体的には、請求金額管理部２１は、保険契約者が、顧客端末装置４の入力装置を介して、メッセージ３５を入力するのを受け付ける。当該メッセージはネットワーク５を介してメッセージ保管装置１に送信され、請求金額管理部２１は、このメッセージ３５を補助記憶装置１３に記憶する。
【００３３】
保険契約者は、メッセージ３５に対して、自らの顧客ＩＤ４１、メッセージＩＤ４２、預かり期間４３を記載するものとする。メッセージＩＤは、保険契約者からの要求に応じて、請求金額管理部２１が採番することとしてもよい。さらに、保険契約者は、メッセージ本文４４、添付画像データ４５及び添付音声データ４６を作成し、メッセージ３５に添付するものとする。
【００３４】
ステップＳ２０２において、請求金額管理部２１は、メッセージ保管料金を算出する。具体的には、請求金額管理部２１は、第１に、受信したメッセージ３５に含まれるメッセージ本文４４の文字数をカウントし、文字数に対して、１文字あたりかつ１日あたりの所定の単価を乗算して、メッセージ本文４４についての１日分の部分請求金額とする。保険契約者が、「ラストメッセージ特約」（保険契約者が死亡する前にメッセージ受取人に開示することがない旨の特約）を希望する場合は、所定の料金を追加してもよい。
【００３５】
請求金額管理部２１は、第２に、受信したメッセージ３５に含まれる添付画像データ４５の情報量及び／又は再生時間をカウントし、情報量及び／又は再生時間に対して、情報量及び／又は再生時間１単位あたりかつ１日あたりの所定の単価を乗算して、添付画像データ４５についての１日分の部分請求金額とする。保険契約者が、「ラストメッセージ特約」を希望する場合は、所定の料金を追加してもよい。
【００３６】
請求金額管理部２１は、第３に、受信したメッセージ３５に含まれる添付音声データ４６の情報量及び／又は再生時間をカウントし、情報量及び／又は再生時間に対して、情報量及び／又は再生時間１単位あたりかつ１日あたりの所定の単価を乗算して、添付音声データ４６についての１日分の部分請求金額とする。保険契約者が、「ラストメッセージ特約」を希望する場合は、所定の料金を追加してもよい。
【００３７】
請求金額管理部２１は、第４に、算出した３つの１日分の部分請求金額を合計し、その合計額に、受信したメッセージ３５に含まれる預かり期間４３の日数を乗算し、メッセージ保管料金とする。
【００３８】
ステップＳ２０３において、請求金額管理部２１は、請求金額情報３１（図３）のレコードを作成する。具体的には、請求金額管理部２１は、第１に、請求金額情報３１の新たなレコードを作成する。
請求金額管理部２１は、第２に、新たなレコードの顧客ＩＤ欄１０１、メッセージＩＤ欄１０２及び預かり期間欄１０３に、受信したメッセージ３５に含まれる、それぞれ、顧客ＩＤ４１、メッセージＩＤ４２及び預かり期間４３を記憶する。
請求金額管理部２１は、第３に、新たなレコードのメッセージ保管料金欄１０４に、ステップＳ２０２の「第４」において算出したメッセージ保管料金を記憶する。
請求金額管理部２１は、第４に、新たなレコードのメッセージ請求パタン欄１０５に、請求パタンとして、「毎月末」又は「一括後払」の何れかを記憶する。請求金額管理部２１は、保険契約者が指定する請求パタンを記憶してもよいし、預かり期間が所定の長さ未満であれば「一括後払」を記憶し、預かり期間が所定の長さ以上であれば「毎月末」を記憶することとしてもよい。
なお、新たなレコードの請求金額欄１０６は空欄にしておく。
その後、メッセージ受信処理手順を終了する。
【００３９】
（支払方法入力処理手順）
図９に沿って支払方法入力処理手順を説明する。
ステップＳ３０１において、請求金額管理部２１は、初期情報を受け付ける。具体的には、請求金額管理部２１は、第１に、顧客端末装置４の出力装置に、支払方法入力画面５１（図７）を表示する。
請求金額管理部２１は、第２に、保険契約者が、支払方法入力画面５１の顧客ＩＤ欄５２に顧客ＩＤを入力するのを受け付ける。
請求金額管理部２１は、第３に、保険契約者が、支払方法入力画面５１の欄５３及び欄５４に対してデータを入力するのを受け付ける。欄５３に入力されるデータは、引き落とし口座ごとの、優先順位、金融機関名、支店名、種類及び口座番号の組合せである。欄５４に入力されるデータは、担保口座ごとの、優先順位、金融機関名、支店名、資産種類及び口座番号の組合せである。
【００４０】
ステップＳ３０２において、請求金額管理部２１は、引き落とし口座についてのレコードを作成する。具体的には、請求金額管理部２１は、第１に、担保設定金額情報３２（図４）の新たなレコードを作成する。作成するレコードの数は、ステップＳ３０１の「第３」において欄５３に入力された組合せの数に等しい。
請求金額管理部２１は、第２に、すべての新たなレコードの顧客ＩＤ欄１１１に、ステップＳ３０１の「第２」において受け付けた顧客ＩＤを記憶する。
【００４１】
請求金額管理部２１は、第３に、ステップＳ３０１の「第３」において欄５３に入力された組合せごとに、金融機関名、支店名及び口座番号名に基づいて引き落とし口座ＩＤを生成する。そして、それぞれの新たなレコードの引き落とし口座欄１１２に、生成した引き落とし口座ＩＤを記憶する。なお、補助記憶装置１３には、金融機関名とそのコードの対照表、支店名とそのコードの対照表が記憶されており、請求金額管理部２１は、これらの対照表及び口座番号に基づいて引き落とし口座ＩＤを生成するものとする。
請求金額管理部２１は、第４に、ステップＳ３０１の「第３」において欄５３に入力された優先順位を、それぞれの新たなレコードの支払優先順位欄１１４に記憶する。
新たなレコードの引き落とし口座残高欄１１３は、空欄としておく（「−」を記憶するのではない）。
【００４２】
ステップＳ３０３において、請求金額管理部２１は、担保口座についてのレコードを作成する。具体的には、請求金額管理部２１は、第１に、担保設定金額情報３２（図４）の新たなレコードを作成する。作成するレコードの数は、ステップＳ３０１の「第３」において欄５４に入力された組合せの数に等しい。
請求金管理部２１は、第２に、すべての新たなレコードの顧客ＩＤ欄１１１に、ステップＳ３０１の「第２」において受け付けた顧客ＩＤを記憶する。
【００４３】
請求金管理部２１は、第３に、ステップＳ３０１の「第３」において欄５４に入力された組合せごとに、金融機関名、支店名及び口座番号名に基づいて担保口座ＩＤを生成する。そして、それぞれの新たなレコードの担保口座欄１１５に、生成した担保口座ＩＤを記憶する。
請求金額管理部２１は、第４に、ステップＳ３０１の「第３」において欄５４に入力され資産種類を、それぞれの新たなレコードの凍結可能資産種類欄１１６に記憶する。
請求金額管理部２１は、第５に、ステップＳ３０１の「第３」において欄５４に入力された優先順位を、それぞれの新たなレコードの担保設定優先順位欄１１８に記憶する。
新たなレコードの担保口座残高欄１１７及び担保設定金額欄１１９は、空欄としておく（「−」を記憶するのではない）。
その後、支払方法入力処理手順を終了する。
【００４４】
（金融機関サーバからの情報入手）
請求金額管理部２１は、適宜のタイミングで（例えば毎日夜間のバッチ処理で）、以下のように、金融機関サーバ２から情報を入手し、担保設定金額情報３２（図４）を最新の状態に維持する。
（１）請求金額管理部２１は、金融機関サーバ２に「情報提供要求」を送信する。「情報提供要求」は、引き落とし口座ＩＤ及び／又は担保口座ＩＤを含む。引き落とし口座ＩＤ及び／又は担保口座ＩＤには金融機関名が含まれているので、請求金額管理部２１は、どの引き落とし口座及び／又は担保口座についての「情報提供要求」を、どの金融機関サーバ２に対して送信すればよいかを決定できる。
【００４５】
（２）金融機関サーバ２は、引き落とし口座残高及び／又は担保口座残高を取得し、メッセージ保管装置１に送信する。引き落とし口座ＩＤ及び／又は担保口座ＩＤには口座番号が含まれているので、金融機関サーバ２は、どの引き落とし口座及び／又は担保口座についての残高を、メッセージ保管装置１に対して返信すればよいかを決定できる。
なお、当然のことであるが、金融機関が口座残高を保険者に知らせることについて、口座名義人（保険契約者）の承諾が必要である。
【００４６】
これらの処理を実行することによって、請求金額管理部２１は、担保設定金額情報３２の、引き落とし口座残高欄１１３及び担保口座残高欄１１７において、最新の値を維持する。
【００４７】
請求金額管理部２１は、適宜のタイミングで、金融機関サーバ２から、保険契約者に関する情報を受信する。例えば、金融機関「Ｆ０００２」の金融機関サーバ２から、『顧客ＩＤが「Ｃ０００１」である保険契約者が死亡した』旨の情報を、２０１１年１０月２０日に受信すると、請求金額管理部２１は、金融機関提供情報３３（図５）の２行目のレコードを作成する。
この処理を実行することによって、請求金額管理部２１は、金融機関提供情報３３のレコードを蓄積して行くことができる。
【００４８】
（取引所サーバからの情報入手）
請求金額管理部２１は、適宜のタイミングで、以下のように、取引所サーバ３から情報を入手し、市場情報３４（図６）を最新の状態に維持する。
（１）請求金額管理部２１は、取引所サーバ３に「市場情報提供要求」を送信する。「市場情報提供要求」は、担保設定金額情報３２（図４）に記憶されているすべての凍結可能資産種類を含む。
（２）取引所サーバ３は、「市場情報提供要求」に含まれる凍結可能資産種類のうち、自らが取引を仲介しているものについての、格付、期間、最高値及び最安値、並びに、市場名称を、メッセージ保管装置１に返信する。
（３）請求金額管理部２１は、市場情報３４の新たなレコードを作成し、凍結可能資産種類欄１３１、市場名称欄１３２、格付欄１３３、期間欄１３４、最高値欄１３５及び最安値欄１３６に、それぞれ、「市場情報提供要求」に含まれる凍結可能資産種類、返信された市場名称、格付、期間、最高値及び最安値を記憶する。
【００４９】
（４）請求金額管理部２１は、作成した新たなレコードごとに、平均値、標準偏差を算出する。
（５）請求金額管理部２１は、作成した新たなレコードごとに、担保掛目を算出する。請求金額管理部２１は、例えば、「標準偏差／（最高値−最安値）」の値を算出し、以下のルールで担保掛目を百分率として決定する。
（ルール）
０＜「標準偏差／（最高値−最安値）」≦Ｐ１であれば、担保掛目をＱ１とする。
Ｐ１＜「標準偏差／（最高値−最安値）」≦Ｐ２であれば、担保掛目をＱ２とする。
Ｐ２＜「標準偏差／（最高値−最安値）」≦Ｐ３であれば、担保掛目をＱ３とする。・・・
但し、０＜Ｐ１＜Ｐ２＜Ｐ３＜・・・かつ０＜Ｑ１＜Ｑ２＜Ｑ３＜・・・である。
【００５０】
なお、「最高値＝最安値＝平均値」である場合（市場価格に変化がない場合）、標準偏差／（最高値−最安値）の値は算出できない。そこで、この場合は、一律的に、担保掛目を所定の値、例えば「１００％」としてもよい。さらに、通常「定期預金」は、譲渡性預金である場合を除いて市場では流通しない。また、「終身生命保険」も市場では流通しない。よって、凍結可能資産種類が「定期預金」、「終身生命保険」等である場合は、請求金額管理部２１は、取引所サーバ３から情報を入手するまでもなく、（１）〜（５）の処理を省略する。そして、新たに作成したレコードの、凍結可能資産種類欄１３１に「定期預金」、「終身生命保険」等を記憶し、担保掛目欄１３９に、一律に例えば「１２０％」を記憶し、他の欄については空欄のままとしてもよい。
これらの処理を実行することによって、請求金額管理部２１は、市場情報３４のレコードを蓄積して行くことができる。
【００５１】
（引き落とし・担保設定処理手順）
図１０に沿って引き落とし・担保設定処理手順を説明する。
ステップＳ４０１において、担保管理部２２は、メッセージ保管料金を請求すべき時期が到来したことを検知する。担保管理部２２は、常時、請求金額情報３１（図３）のすべてのレコードについての預かり期間及び請求パタン、並びに現在時刻を監視しておく。そして、請求すべき時点が到来する都度、請求金額を算出する。
【００５２】
例えば、図３の１行目のレコードの預かり期間は「２０１１１００１−２０１２０９３０」であり、請求パタンは「毎月末」である。したがって、２０１１年１０月３１日、２０１１年１１月３０日、・・・の１２の時点が請求すべき時点となる。
【００５３】
他の例として、図３の２行目のレコードの預かり期間は「２０１１０６０１−２０１２０５３１」であり、請求パタンは「一括後払」である。したがって、２０１２年５月３１日が請求すべき時点となる。
【００５４】
現在の時点が、２０１１年１０月３１日であるとして以降の説明を続ける。具体的には、担保管理部２２は、第１に、図３の１行目のレコードについて、メッセージ保管料金の（一部）を請求すべき時点が到来したことを検知する。このレコードを以降、「請求対象レコード」と呼ぶことがある。
担保管理部２２は、第２に、請求金額を算出する。図３の１行目は、担保管理部２２が、２０１１年１０月３１日、２０１１年１１月３０日、・・・の１２の時点のそれぞれにおいてメッセージ保管料金を徴収すべきことを示している。よって、担保管理部２２は、「１２０００円」を１２で除算した「１０００円」を請求金額として請求金額欄１０６に記憶する。
【００５５】
ステップＳ４０２において、担保管理部２２は、引き落とし口座を特定し、引き落とし指示を送信する。具体的には、担保管理部２２は、第１に、請求対象レコードの顧客ＩＤを検索キーとして、担保設定金額情報３２（図４）のうち引き落とし口座ＩＤ欄１１２に値が記憶されているレコードを検索し、該当したレコードを取得する。ここでは「Ｃ０００１」を検索キーとした結果、図４の１〜３行目のレコードが取得される。
【００５６】
担保管理部２２は、第２に、取得されたレコードの支払優先順位に従って、請求対象レコードの請求金額「１０００円」を、引き落とし口座残高から減算して行く。
いま、引き落とし口座「Ｂ０００１」の優先順位が「１」であり、その残高は「２５００円」である。よって、担保管理部２２は、当該残高「２５００円」から請求金額「１０００円」を減算した結果である「１５００円」を、引き落とし口座残高欄１１３に上書きして記憶する。
担保管理部２２は、第３に、引き落とし口座ＩＤ「Ｂ０００１」に含まれる金融機関名の金融機関サーバ２に対して、『引き落とし口座ＩＤに含まれる口座番号の口座の残高から「１０００円」を減算し、同額を保険者の所定の口座の残高に対して加算する』旨の指示（引き落とし指示）を送信する。
担保管理部２２は、第４に、「請求残額」を算出する。請求残額は、請求対象レコードの請求金額から、送信した引き落とし指示の金額の合計を減算した値であり、この場合は「０円」となる。そして、担保管理部２２は、請求残額「０円」を、請求対象レコードの請求金額欄１０６に記憶する。
【００５７】
他の例として、いま、請求対象レコードの請求金額が「１０００円」であり、引き落とし口座「Ｂ０００１」の優先順位が「１」であり、その残高は「４００円」であり、引き落とし口座「Ｂ０００２」の優先順位が「２」であり、その残高は「１３００円」であるとする。この場合、担保管理部２２は、「Ｂ０００１」の残高「４００円」から「４００円」を減算した「０」を引き落とし口座残高欄１１３に上書きして記憶する。そして、「Ｂ０００２」の残高「１３００円」から「１０００−４００＝６００円」を減算した「７００円」を引き落とし口座残高欄１１３に上書きして記憶する。この場合は、担保管理部２２は、引き落とし口座ＩＤ「Ｂ０００１」に含まれる金融機関名の金融機関サーバ２に対して、『引き落とし口座ＩＤに含まれる口座番号の口座の残高から「４００円」を減算し、同額を保険者の所定の口座の残高に対して加算する』旨の指示を送信する。さらに、引き落とし口座ＩＤ「Ｂ０００２」に含まれる金融機関名の金融機関サーバ２に対して、『引き落とし口座ＩＤに含まれる口座番号の口座の残高から「６００円」を減算し、同額を保険者の所定の口座の残高に対して加算する』旨の指示を送信する。
この場合の請求残額も、「０円」となる。そして、担保管理部２２は、請求残額「０円」を、請求対象レコードの請求金額欄１０６に記憶する。
【００５８】
さらに他の例として、いま、請求対象レコードの請求金額が「１０００円」であり、引き落とし口座「Ｂ０００１」の優先順位が「１」であり、その残高は「０円」であり、引き落とし口座「Ｂ０００２」の優先順位が「２」であり、その残高は「０円」であり、引き落とし口座「Ｂ０００３」の優先順位が「３」であり、その残高は「２００円」であるとする。この場合、引き落とし口座「Ｂ０００１」及び「Ｂ０００２」からは引き落としができない。担保管理部２２は、「Ｂ０００３」の残高「２００円」から「２００円」を減算した「０」を引き落とし口座残高欄１１３に上書きして記憶する。そして、担保管理部２２は、引き落とし口座ＩＤ「Ｂ０００３」に含まれる金融機関名の金融機関サーバ２に対して、『引き落とし口座ＩＤに含まれる口座番号の口座の残高から「２００円」を減算し、同額を保険者の所定の口座の残高に対して加算する』旨の指示を送信する。この場合の請求残額は、「１０００−２００＝８００円」となる。そして、担保管理部２２は、請求残額「８００円」を、請求対象レコードの請求金額欄１０６に記憶する。このように、請求金額（図３の欄１０６）は、記憶された後直ちに、全額徴収されて「０円」が残る場合と、記憶された後直ちに全額徴収されることができず、「０円」以外の何らかの値（＝請求残額）が残る場合がある。この請求残額が、保険者にとって保全すべき未収金にほかならない。
【００５９】
ステップＳ４０３において、担保管理部２２は、請求残額が閾値以上であるか否かを判断する。具体的には、担保管理部２２は、ステップＳ４０２の「第４」において算出した請求残額が所定の閾値以上である場合（ステップＳ４０３“ＹＥＳ”）は、ステップＳ４０４に進み、所定の閾値未満である場合（ステップＳ４０３“ＮＯ”）は、引き落とし・担保設定処理手順を終了する。以降においては、請求残額が「８００円」であり、この請求残額は所定の閾値以上であるものとして説明を続ける。
【００６０】
ステップＳ４０４において、担保管理部２２は、凍結候補の担保口座のレコードを取得する。具体的には、担保管理部２２は、請求対象レコードの顧客ＩＤを検索キーとして、担保設定金額情報３２（図４）のうち担保口座ＩＤ欄１１５に値が記憶されているレコードを検索し、該当したレコードを取得する。ここでは「Ｃ０００１」を検索キーとした結果、図４の４〜６行目のレコードが取得される。
【００６１】
ステップＳ４０５において、担保管理部２２は、担保掛目を取得する。具体的には、担保管理部２２は、ステップＳ４０４において取得したレコードの凍結可能資産種類を検索キーとして、市場情報３４（図６）を検索し、該当したレコードの担保掛目を取得する。この場合、「定期預金」、「日本国債」及び「Ａ社株式」についての担保掛目をそれぞれ取得することになる。
【００６２】
ステップＳ４０６において、担保管理部２２は、凍結指示を送信する。具体的には、担保管理部２２は、第１に、ステップＳ４０４において取得されたレコードの担保設定優先順位に従って、担保口座残高の範囲内で、請求残額に担保掛目を乗算した金額について担保を設定する。いま、ステップＳ４０５において取得された担保掛目が、定期預金については「１２０％」であり、日本国債については「１００％」であり、Ａ社株式については「２５０％」であったとする。そして、ステップＳ４０４において取得されたレコードの担保口座残高が、定期預金については「１００００００円」であり、日本国債については「５０００００円」であり、Ａ社株式については「５０００００円」であったとする。さらに、ステップＳ４０４において取得されたレコードの担保優先順位が、定期預金については「１」であり、日本国債については「２」であり、Ａ社株式については「３」であったとする。
【００６３】
この場合、担保管理部２２は、請求残額に対し「定期預金」についての担保掛目「１２０％」を乗算した値である「８００×１２０％＝９６０円」を、図４の４行目のレコードの担保設定金額欄１１９に既に記憶されている金額（例えば「０円」）に対し加算する。そして加算した結果である「９６０円」を、担保設定金額欄１１９に上書きして記憶する。
【００６４】
担保管理部２２は、第２に、担保口座ＩＤ「Ｂ０００４」に含まれる金融機関名の金融機関サーバ２に対して、『担保口座ＩＤに含まれる口座番号の口座に対し「９６０円」を凍結する』旨の指示を送信する。
【００６５】
他の例として、いま、請求残額が「１０００００円」であったとする。担保掛目が、定期預金については「１２０％」であり、日本国債については「１００％」であり、Ａ社株式については「２５０％」であったとする。そして、担保口座残高が、定期預金については「５００００円」であり、日本国債については「３００００円」であり、Ａ社株式については「８００００円」であったとする。担保設定金額の現在の値が、定期預金については「１００００円」であり、日本国債については「０円」であり、Ａ社株式については「０円」であったとする。さらに、担保優先順位が、定期預金については「１」であり、日本国債については「２」であり、Ａ社株式については「３」であったとする。
【００６６】
この場合、担保管理部２２は、１０００００円×１２０％＝１２００００円のうち、「５００００円−１００００円＝４００００円」を、図４の４行目のレコードの担保設定金額欄１１９の既存の値（「１００００円」である）に加算して記憶する。そして、（１０００００円−４００００円）×１００％＝６００００円のうち、「３００００円」を、図４の５行目のレコードの担保設定金額欄１１９の既存の値（「０円」である）に加算して記憶する。さらに、（６００００円−３００００円）×２５０％＝７５０００円の全額を、図４の５行目のレコードの担保設定金額欄１１９の既存の値（「０円」である）に加算して記憶する。
【００６７】
この場合、担保管理部２２は、担保口座ＩＤ「Ｂ０００４」に含まれる金融機関名の金融機関サーバ２に対して、『担保口座ＩＤに含まれる口座番号の口座に対し「４００００円」を凍結する』旨の指示を送信する。そして、担保口座ＩＤ「Ｂ０００５」に含まれる金融機関名の金融機関サーバ２に対して、『担保口座ＩＤに含まれる口座番号の口座に対し「３００００円」を凍結する』旨の指示を送信する。さらに、担保口座ＩＤ「Ｂ０００６」に含まれる金融機関名の金融機関サーバ２に対して、『担保口座ＩＤに含まれる口座番号の口座に対し「７５０００円」を凍結する』旨の指示を送信する。
その後、引き落とし・担保設定処理手順を終了する。
【００６８】
（変形例１）
担保管理部２２は、定期的に又は周期的に、任意の顧客ＩＤが特定する保険契約者について、請求金額情報３１（図３）の請求金額欄１０６の請求残額を担保設定金額情報３２（図４）の引き落とし口座残高（欄１１３）の合計と比較し、比較した結果が「請求残額＜引き落とし口座残高の合計」である場合は、以下の「即時引き落とし・担保解除処理」を実行する。
（１）優先順位に従って、引き落とし口座残高から請求残額を減算して記憶する。
（２）請求残額を「０」に変更して記憶する。
（３）担保設定金額を「０」に変更して記憶する。
（４）（１）に対応し、金融機関サーバ２に対し、引き落とし指示を送信する。
（５）（３）に対応し、金融機関サーバ２に対し、担保口座の凍結を解除する指示を送信する。
【００６９】
（変形例２）
担保設定金額情報３２（図４）の担保設定優先順位欄１１８の値が「ｆｒｅｅ」である場合があり得る。この場合、請求金額管理部２１は、任意の顧客ＩＤが特定する保険契約者について適宜のタイミングにおいて、担保設定優先順位欄１１８の値が「ｆｒｅｅ」である凍結可能資産種類に対応する担保掛目を、市場情報３４（図６）を参照し取得する。そして、担保掛目の小さい順（市場価格の変動が小さい順）に、担保設定優先順位「１」、「２」、「３」、・・・を、担保設定金額情報３２（図４）の担保設定優先順位欄１１８に記憶することとしてもよい。
【００７０】
（即時担保設定処理手順）
図１１に沿って、即時担保設定処理手順を説明する。
ステップＳ５０１において、担保管理部２２は、金融機関提供情報３３（図５）の新たなレコードが作成されたことを検知する。具体的には、担保管理部２２は、常時、金融機関提供情報３３のレコードが新たに作成されるのを監視しておく。そして、新たなレコード（以降「新情報提供レコード」と呼ぶことがある）が作成された時点でステップＳ５０２に進む。
【００７１】
ステップＳ５０２において、担保管理部２２は、即時に担保を設定する必要があるか否かを判断する。具体的には、担保管理部２２は、第１に、新情報提供レコードの顧客ＩＤ及び情報種類を取得し、取得した顧客ＩＤを検索キーとして、請求金額情報３１（図３）を検索し、該当したすべてのレコードの請求金額の合計を取得する。
担保管理部２２は、第２に、取得した情報種類が「相続開始」、「死亡」及び「生命保険金支払い」のうちの何れかであり、かつ、取得した請求金額の合計が所定の閾値以上である場合（ステップＳ５０２“ＹＥＳ”）は、ステップＳ５０３に進む。それ以外の場合（ステップＳ５０２“ＮＯ”）は、即時担保設定処理手順を終了する。
【００７２】
ステップＳ５０３において、担保管理部２２は、凍結候補の担保口座のレコードを取得する。ステップＳ５０３の処理内容は、ステップＳ４０４の処理内容と同じである。ただし、ステップＳ４０４において、「請求対象レコードの顧客ＩＤを検索キーとして」とある箇所は、「新情報提供レコードの顧客ＩＤを検索キーとして」と読み替える。
【００７３】
ステップＳ５０４において、担保管理部２２は、担保掛目を取得する。ステップＳ５０４の処理内容は、ステップＳ４０５の処理内容と同じである。ただし、ステップＳ４０５において、「ステップＳ４０４において取得したレコードの凍結可能資産種類を検索キーとして」とある箇所は、「ステップＳ５０３において取得したレコードの凍結可能資産種類を検索キーとして」と読み替える。
【００７４】
ステップＳ５０５において、担保管理部２２は、凍結指示を送信する。ステップＳ５０５の処理内容は、ステップＳ４０６の処理内容と同じである。ただし、ステップＳ４０６において、「ステップＳ４０４において取得されたレコードの担保設定優先順位に従って、」とある箇所は、「ステップＳ５０３において取得されたレコードの担保設定優先順位に従って、」と読み替える。「いま、ステップＳ４０５において取得された担保掛目が、」とある箇所は、「いま、ステップＳ５０４において取得された担保掛目が、」と読み替える。「そして、ステップＳ４０４において取得されたレコードの担保口座残高」とある箇所は、「そして、ステップＳ５０３において取得されたレコードの担保口座残高」と読み替える。
その後、即時担保設定処理手順を終了する。
【００７５】
（担保評価替え処理手順）
図１２に沿って、担保評価替え処理手順を説明する。
ステップＳ６０１において、担保管理部２２は、市場情報３４（図６）の新たなレコードが作成されたことを検知する。具体的には、担保管理部２２は、常時、市場情報３４のレコードが新たに作成されるのを監視しておく。そして、新たなレコード（以降「新市場情報レコード」と呼ぶことがある）が作成された時点で、前記のように、平均値、標準偏差及び担保掛目を算出したうえで、ステップＳ６０２に進む。
【００７６】
ステップＳ６０２において、担保管理部２２は、担保評価替えの対象顧客を特定する。具体的には、担保管理部２２は、新市場情報レコードの凍結可能資産種類を検索キーとして、担保設定金額情報３２（図４）を検索し、該当したレコードの顧客ＩＤを取得する。
【００７７】
ステップＳ６０３において、担保管理部２２は、凍結候補の担保口座のレコードを取得する。ステップＳ６０３の処理内容は、ステップＳ４０４の処理内容と同じである。ただし、ステップＳ４０４において、「請求対象レコードの顧客ＩＤを検索キーとして」とある箇所は、「ステップＳ６０２において取得した顧客ＩＤを検索キーとして」と読み替える。
【００７８】
ステップＳ６０４において、担保管理部２２は、担保掛目を取得する。ステップＳ６０４の処理内容は、ステップＳ４０５の処理内容と同じである。ただし、ステップＳ４０５において、「ステップＳ４０４において取得したレコードの凍結可能資産種類を検索キーとして」とある箇所は、「ステップＳ６０３において取得したレコードの凍結可能資産種類を検索キーとして」と読み替える。
【００７９】
ステップＳ６０５において、担保管理部２２は、凍結指示を送信する。ステップＳ６０５の処理内容は、ステップＳ４０６の処理内容と同じである。ただし、ステップＳ４０６において、「ステップＳ４０４において取得されたレコードの担保設定優先順位に従って、」とある箇所は、「ステップＳ６０３において取得されたレコードの担保設定優先順位に従って、」と読み替える。「いま、ステップＳ４０５において取得された担保掛目が、」とある箇所は、「いま、ステップＳ６０４において取得された担保掛目が、」と読み替える。「そして、ステップＳ４０４において取得されたレコードの担保口座残高」とある箇所は、「そして、ステップＳ６０３において取得されたレコードの担保口座残高」と読み替える。
なお、ステップＳ６０３〜Ｓ６０５の処理は、ステップＳ６０２において取得した顧客ＩＤごとに繰り返すものとする。その後、担保評価替え処理手順を終了する。
【００８０】
（本実施形態の効果）
本実施形態によれば、複数の引き落とし口座を有する保険契約者から、保険契約者が希望する順に、メッセージ保管料金の徴収を確実に行うことができる。また、メッセージ保管料金の全額徴収が不可能である場合でも、複数の担保口座を設定し、保険契約者が希望する順に、又は担保の価格変動が小さい順に担保を確保し、未収金を保全することができる。
さらに、保険契約者が死亡した後、速やかに未収金の保全が可能となり、担保の市場価格の変動を反映した最適な担保設定及び設定変更も可能になる。
【００８１】
本発明は、前記した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能である。
【符号の説明】
【００８２】
１      メッセージ保管装置
２      金融機関サーバ
３      取引所サーバ
４      顧客端末装置
５      ネットワーク
１１    中央制御装置（制御部）
１２    主記憶装置（記憶部）
１３    補助記憶装置（記憶部）
１４    入力装置
１５    出力装置
１６    通信インタフェース（ＩＦ）
２１    請求金額管理部
２２    担保管理部
３１    請求金額情報
３２    担保設定金額情報
３３    金融機関提供情報
３４    市場情報
３５    メッセージ
５１    支払方法入力画面
【図１】
0005845075.tif 000002
【図２】
0005845075.tif 000003
【図３】
0005845075.tif 000004
【図４】
0005845075.tif 000005
【図５】
0005845075.tif 000006
【図６】
0005845075.tif 000007
【図７】
0005845075.tif 000008
【図８】
0005845075.tif 000009
【図９】
0005845075.tif 000010
【図１０】
0005845075.tif 000011
【図１１】
0005845075.tif 000012
【図１２】
0005845075.tif 000013