(57)【要約】【課題】第１のフロー（取引の詳細を通知する）に応じて、第２のフロー（通知の受領側が、通知の送付側に情報を提供する）が対応して発生する場合、および発生しない場合の重複するフローを統一し、手続きを簡略化することにより、様々なコストの削減および作業ミスの抑制を可能とする、本人確認付き申込書一体型帳票を提供する。【解決手段】葉書表面領域２４０の裏面および葉書裏面領域２５０の裏面が接着され、当該領域を一体型帳票から切り取ることによって、規格を満たした葉書を得ることができ、および接着されていない領域が、帳票として利用可能である一体型帳票に、葉書を利用する申込者の真正性を確認することができる情報を付した。【選択図】図２
2011073293.tif 000002
【特許請求の範囲】
【請求項１】
帳票内に本人確認情報付き申込書および帳票を備えた一体型帳票であって、
前記本人確認情報は、申込書を利用する申込者の真正性を確認することができる情報を示し、
申込書となる葉書表面領域および葉書裏面領域、ならびに帳票領域が帳票の片面に印字されており、
前記葉書表面領域の裏面および前記葉書裏面領域の裏面が接着され、
当該領域を前記一体型帳票から切り取ることによって、規格を満たした葉書を得ることができ、および
接着されていない前記帳票領域が、帳票として利用可能であることを特徴とする一体型帳票。
【請求項２】
前記本人確認情報はさらに、前記申込者の特定の情報を示すことを特徴とする請求項１に記載の一体型帳票。
【請求項３】
前記本人確認情報は、前記申込者が知っている情報を使用して、ある規則またはアルゴリズムなどによって作成した新たなコードであり、前記申込書は、前記申込者が知っている情報を記入する欄を備えることを特徴とする請求項１または請求請２に記載の一体型帳票。
【請求項４】
本人確認情報付き申込書一体型帳票および申込書が含まれない単独型帳票を作成する帳票作成システムであって、前記本人確認情報は、申込書を利用する申込者の真正性を確認することができる情報を示し、前記システムは、
帳票を作成する指示を受信する帳票作成指示受信部と、
少なくとも、預金に関する情報を格納する預金ＤＢ、顧客に関する情報を格納する顧客ＤＢ、および前記顧客が受けることが可能な特典を提供する提携企業に関する情報を格納する提携企業ＤＢを有する記憶部と、
所与の条件に合致するレコードを前記預金ＤＢから抽出するデータ抽出部と、
前記抽出したレコードを基に各ＤＢから情報を収集し、作成する帳票の種別に対応する予め定められたレイアウトに合わせて前記収集したデータを配置して、出力データを作成する出力データ作成部と、
前記本人確認情報を作成する本人確認情報作成部と、
出力装置に前記出力データを送信する出力データ送信部と
を備えたことを特徴する帳票作成システム。
【請求項５】
前記本人確認情報はさらに、前記申込者の特定の情報を示すことを特徴とする請求項４に記載の帳票作成システム。
【請求項６】
前記本人確認情報作成部は、前記申込者が知っている情報を使用して、ある規則またはアルゴリズムなどによって新たなコードを作成することを特徴とする請求項４または５に記載の帳票作成システム。
【請求項７】
前記提携企業ＤＢは、前記特典を付与するために満たすべき条件が格納されていることを特徴とする請求項４に記載の帳票作成システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、本人確認情報付き申込書一体型帳票に関し、より詳細には、顧客に取引などの詳細を通知する帳票と、当該取引に伴い必要となる顧客からの申込書とを一体化した申込書一体型帳票に関する。
【背景技術】
【０００２】
一般に、取引の発生、変更、解約などに伴い企業から企業へ、または企業から顧客へ取引の詳細を通知する書類が送付される。また、この取引の発生、変更、解約などの通知に応じて、書類の受領側は、何らかの情報を書類の送付側または第３者に提供することが求められる場合がある。例えば、契約書の内容を企業Ａから企業Ｂへ送付した際、契約書を受領した企業Ｂが、契約書の受領書を企業Ａに提供すること、またはセレモニーの招待状を企業Ｃから顧客へ送付した際、顧客が、出席有無や利用する交通手段の情報等を企業Ｃもしくは第３者であるセレモニー会場に提供することなどがこれに該当する。
【０００３】
このような取引の詳細を通知する書類、すなわち帳票と、書類を受領した顧客からの情報提供を可能とする申し込み葉書とを一体化し、印字コストの低減などを目的とする、一体型帳票が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２４７９７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述したような、取引の発生などに伴い取引の詳細を通知する第１のフローと、取引の発生などの通知に応じて通知の受領側から何らかの情報を、通知の送付側または第３者に提供する第２のフローとが必ず対応して発生する場合を、第１の類型と呼ぶ。第１の類型の場合、通知の送付側は、受領側への通知と受領側からの情報の提示とを可能とする送付物を準備し、受領側から提示された情報を処理するフローを整えることが可能である。しかし、取引の中には、所定の条件によっては第１のフローのみで、第２のフローが発生しない第２の類型が存在する。
【０００６】
このような第１の類型および第２の類型が混在する場合、通知の送付側では、第２のフローが発生する場合と発生しない場合の２通りの送付物を準備し、また、受領側から情報を提示される場合と提示されない場合の２通りのフローを整える必要がある。それに応じて、フローを管理するソフトウェア資源、送付物を印字するプリンタなどのハードウェア資源のコストは、２倍またはそれ以上にかかる可能性がある。作業人員などその他の資源のコストも、送付側からの通知書のみを作成して封入する人員と、送付側からの通知書および受領側から情報を提示するための返信用葉書を別々に作成して封入する人員とが必要となり、２倍またはそれ以上にかかる可能性がある。また、フローを複数管理することにより、処理が煩雑になり、各フローにおいてミスが生じる可能性はより高くなるという問題がある。
【０００７】
それに加えて、受領側からの情報の提示先が（通知の送付側ではなく）第３者となる第１の類型では、第３者側において、本人確認の困難性が生じる。本人確認は、提示された情報の送り元の真正性の確認であり、情報の送り元が、通知の送付側と一定の取引状態を有する通知の受領者であることを確認する。この本人確認より、通知の送付側と何ら関係を持たない悪意を持った者から情報の提示を受けた場合に発生し得る、第３者および／または通知の送付側の多大な損害を防ぐことが可能である。本人確認は、受領側からの情報の提示先が通知の送付側である場合は、両者は元々の取引状態を有する関係にあるため、比較的容易に行うことができる。一方、直接の取引状態を有さない第３者が情報の送り元の真正性を確認する場合は、本人確認のための情報が別途必要となり、処理はさらに煩雑になる可能性がある。
【０００８】
本発明は、このような問題に鑑みてなされたもので、その目的とするところは、重複するフローを統一し、手続きを簡略化することにより、様々なコストの削減および作業ミスの抑制を可能とする、本人確認付き申込書一体型帳票を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するため、請求項１に記載の発明は、帳票内に本人確認情報付き申込書および帳票を備えた一体型帳票であって、前記本人確認情報は、申込書を利用する申込者の真正性を確認することができる情報を示し、申込書となる葉書表面領域および葉書裏面領域、ならびに帳票領域が帳票の片面に印字されており、前記葉書表面領域の裏面および前記葉書裏面領域の裏面が接着され、当該領域を前記一体型帳票から切り取ることによって、規格を満たした葉書を得ることができ、および接着されていない前記帳票領域が、帳票として利用可能であることを特徴とする。
【００１０】
請求項２に記載の発明は、請求項１に記載の一体型帳票であって、前記本人確認情報はさらに、前記申込者の特定の情報を示すことを特徴とする。
【００１１】
請求項３に記載の発明は、請求項１または２に記載の一体型帳票であって、前記本人確認情報は、前記申込者が知っている情報を使用して、ある規則またはアルゴリズムなどによって作成した新たなコードであり、前記申込書は、前記申込者が知っている情報を記入する欄を備えることを特徴とする。
【００１２】
請求項４に記載の発明は、本人確認情報付き申込書一体型帳票および申込書が含まれない単独型帳票を作成する帳票作成システムであって、前記本人確認情報は、申込書を利用する申込者の真正性を確認することができる情報を示し、前記システムは、帳票を作成する指示を受信する帳票作成指示受信部と、少なくとも、預金に関する情報を格納する預金データベース（ＤＢ）、顧客に関する情報を格納する顧客ＤＢ、および前記顧客が受けることが可能な特典を提供する提携企業に関する情報を格納する提携企業ＤＢを有する記憶部と、所与の条件に合致するレコードを前記預金ＤＢから抽出するデータ抽出部と、前記抽出したレコードを基に各ＤＢから情報を収集し、作成する帳票の種別に対応する予め定められたレイアウトに合わせて前記収集したデータを配置して、出力データを作成する出力データ作成部と、前記本人確認情報を作成する本人確認情報作成部と、出力装置に前記出力データを送信する出力データ送信部とを備えたことを特徴する。
【００１３】
請求項５に記載の発明は、請求項４に記載の帳票作成システムであって、前記本人確認情報はさらに、前記申込者の特定の情報を示すことを特徴とする。
【００１４】
請求項６に記載の発明は、請求項４または５に記載の帳票作成システムであって、前記本人確認情報作成部は、前記申込者が知っている情報を使用して、ある規則またはアルゴリズムなどによって新たなコードを作成することを特徴とする。
【００１５】
請求項７に記載の発明は、請求項４に記載の帳票作成システムであって、前記提携企業ＤＢは、前記特典を付与するために満たすべき条件が格納されていることを特徴とする。
【発明の効果】
【００１６】
本発明の帳票作成システムは、帳票を作成する指示を受信する帳票作成指示受信部と、少なくとも、預金に関する情報を格納する預金ＤＢ、顧客に関する情報を格納する顧客ＤＢ、および前記顧客が受けることが可能な特典を提供する提携企業に関する情報を格納する提携企業ＤＢを有する記憶部と、所与の条件に合致するレコードを前記預金ＤＢから抽出するデータ抽出部と、前記抽出したレコードを基に各ＤＢから情報を収集し、作成する帳票の種別に対応する予め定められたレイアウトに合わせて前記収集したデータを配置して、出力データを作成する出力データ作成部と、前記本人確認情報を作成する本人確認情報作成部と、出力装置に前記出力データを送信する出力データ送信部とを備える。当該帳票作成システムにより、本人確認情報付き申込書一体型帳票および申込書が含まれない単独型帳票を作成することができるので、同一のソフトウェア資源、ハードウェア資源で２通りのフローに対応することが可能である。重複するフローを統一し、手続きを簡略化することにより、作業人員などその他の資源にかかるコストを抑えることが可能である。
【００１７】
さらに、本発明の本人確認情報付き申込書一体型帳票は、申込書を利用する者（以下申込者）の真正性を確認することができる情報を申込書に含むので、申込者の真正性が保障される安定した取引を、容易に行うことが可能である。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態にかかる本人確認情報付き申込書一体型帳票を示す（展開）図である。
【図２】本発明の一実施形態にかかる本人確認情報付き申込書一体型帳票の構造を示す図である。
【図３】本発明の一実施形態にかかる本人確認情報付申込書を有さない単独型帳票を示す（展開）図である。
【図４】本発明の一実施形態にかかる単独型帳票の構造を示す図である。
【図５】本発明の一実施形態にかかる通知の受領側、通知の送付側、情報の提示先の関係を示す図である。
【図６】本発明の一実施形態にかかる通知の受領側、通知の送付側、情報の提示先の別の関係を示す図である。
【図７】本発明の一実施形態にかかる本人確認情報付き申込書一体型帳票を実施するシステムのモジュール構成図である。
【図８】図７に示すシステムにおいて本人確認情報付き申込書一体型帳票を実施する処理ステップを示すフローチャートである。
【図９】本発明の一実施形態にかかる預金ＤＢに格納された情報の一例を示す図である。
【図１０】本発明の一実施形態にかかる提携企業ＤＢに格納された情報の一例を示す図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照しながら本発明の実施形態について詳細に説明する。なお、図面全体を通じて、同一の符号は、同一の構成要素を示す。
【００２０】
図１は、本発明の一実施形態にかかる本人確認情報付き申込書一体型帳票を示す（展開）図である。本実施例は、解約の際に特典を受けることができる預金の契約を例に説明する。図１の帳票は、銀行から顧客に対して送付される、解約の通知および特典の申し込みを可能とする本人確認情報付き申込書一体型帳票である。取引の類型としては、第１のフローと第２のフローとが対応して発生する、第１の類型に該当する。
【００２１】
本人確認情報付き申込書一体型帳票１００は、図１に示すように、顧客宛名１１０、挨拶文１２０、取引明細１３０、返信先宛名１４０、申込情報１５０、および葉書の使い方１６０を有する。顧客宛名１１０は、取引に関わる一方であり、その取引の発生、変更、解約などに伴い他方から通知を受ける者の住所および名称などである。本実施例では、預金の契約を行った顧客の、郵便番号、住所、および名称が含まれる。挨拶文１２０は、顧客に向けて取引の他方から発信される挨拶文などである。本実施例では、預金の契約者に向けて銀行から発信される挨拶文が含まれる。取引明細１３０は、顧客に対して通知すべき取引の発生、変更、解約などに関する詳細を記載した明細である。本実施例では、解約された預金の、取引店番号、口座番号、解約日、および受取金額などが含まれる。
【００２２】
返信先宛名１４０は、通知に応じて情報の提示を行う返信先の住所および名称などである。本実施例では、顧客が受けることが可能な特典の申込先である提携企業の、郵便番号、住所、および企業名が含まれる。申込情報１５０は、取引の発生、変更、解約などに伴い顧客に権利または義務が発生する際に、顧客が、その権利の申し込みまたは義務の履行に必要な事項を記載する欄である。本実施例では、顧客が受けることが可能な特典の申し込みに必要な、顧客情報（郵便番号、住所、電話番号、および名称）、預金情報（受取金額、解約日、および口座番号）、申し込み特典内容（申し込み金額、および提携企業名）、および顧客確認情報が含まれる。
【００２３】
葉書の使い方１６０は、申込情報１５０に記載する事項の補足および注意書き、および顧客が受領した本発明に係る一体型帳票を葉書として使用するための方法などである。本実施例では、顧客が記入すべき申込情報１５０の案内、および一体型帳票を葉書として使用するためにきりとる部分の案内などが含まれる。
【００２４】
図２は、本発明の一実施形態にかかる本人確認情報付き申込書一体型帳票の構造を示す図である。本人確認情報付き申込書一体型帳票１００を、顧客宛名領域２１０、自由領域（１）２２０、自由領域（２）２３０、葉書表面領域２４０、葉書裏面領域２５０、および自由領域（３）２６０に分けて説明する。
【００２５】
本人確認情報付き申込書一体型帳票１００は、図１に示したように、展開した状態で印刷が行われる。その後、図２に示される山折り線２７０、および谷折り線２８０に沿って折りたたまれる。さらに、折りたたんだ状態で重なる葉書表面領域２４０の裏面および葉書裏面領域２５０の裏面は、はがれないように強固に接着される。本人確認情報付き申込書一体型帳票を葉書として使用する際には、ミシン線２９０に沿って切り取ることによって、規格を満たした葉書を得ることができる。
【００２６】
なお、顧客への送付時は、本人確認情報付き申込書一体型帳票１００を折りたたみ、展開図の３分の１の幅となった状態で、封筒に封入する。当該封筒は、顧客宛名領域２１０に印字した顧客宛名１１０が見えるように、対応する領域が透明または空洞となっていることが望ましい。また、葉書の申込情報１５０には個人情報が含まれるため、葉書を投函する際にこれを保護する、隠蔽ラベルを封入しておくことが望ましい。
【００２７】
図３は、本発明の一実施形態にかかる本人確認情報付申込書を有さない単独型帳票を示す（展開）図である。本実施例は、預金の契約を例に説明する。図３の帳票は、銀行から顧客に対して送付される、解約の通知を可能とする単独型帳票である。取引の類型としては、第１のフローのみで第２のフローが発生しない、第２の類型に該当する。
【００２８】
単独型帳票３００は、図３に示すように、顧客宛名１１０、挨拶文１２０、取引明細１３０を有する。顧客宛名１１０、挨拶文１２０、および取引明細１３０は、図１の説明と重複するため、省略する。図１および図３から明らかなように、図３の実施例の各要素は図１の要素の一部と同一である。
【００２９】
図４は、本発明の一実施形態にかかる単独型帳票の構造を示す図である。単独型帳票３００を、葉書表面領域４１０、葉書中面領域（１）４２０、および葉書中面領域（２）４３０に分けて説明する。
【００３０】
単独型帳票３００は、図３において示したように、展開した状態で印刷が行われる。その後、図４に示される山折り線４４０、および谷折り線４５０に沿って折りたたまれる。さらに、折りたたんだ状態で重なる葉書表面領域４１０の裏面と葉書中面領域（１）４２０の裏面とは、はがれないように強固に接着される。葉書中面領域（１）４２０の表面と葉書中面領域（２）４３０の表面とは、圧着加工される。後に剥離可能な圧着加工を行うことにより、葉書中面領域（１）および（２）に記載された情報は、送付時に保護される。
【００３１】
図５は、本発明の一実施形態にかかる通知の受領側、通知の送付側、情報の提示先の関係を示す図である。本実施例では、通知の受領側は、預金の契約を行った顧客５０１である。通知の送付側は、預金の契約を行った相手方である銀行５０２である。情報の提示先は、顧客が受けることが可能な特典の申込先である提携企業５０３である。取引の類型としては、受領側からの情報の提示先が（通知の送付側ではなく）第３者となる、第１の類型に該当する。
【００３２】
本実施例では、顧客の申し込みおよび銀行の受付によって発生した、特典付き預金の契約を結んだという取引状態が存在する。顧客５０１および銀行５０２は、それぞれ通知の受領側・通知の送付側となる。この特典付き預金が解約になると、顧客５０１および提携企業５０３に、特典の申し込み側・提供側という新たな関係が発生する。この新たな関係は、前述のように、顧客５０１が銀行５０２と特典付き預金の契約を結んだという一定の取引状態を有する場合にのみ成り立つ必要がある。提携企業５０３は、顧客から特典の申し込みが行われた際に、本人確認を行う必要がある。受領側からの情報の提示先が第３者となる第１の類型では、本人確認の困難性が生じるため、本発明は特に有用である。なお、提携企業５０３は、複数存在するうちの１つとすることでき、解約になる前の任意の時点において、それぞれ顧客が自由に選択することもできる。
【００３３】
図６は、本発明の一実施形態にかかる通知の受領側、通知の送付側、情報の提示先の別の関係を示す図である。本実施例では、通知の受領側は、預金の契約を行った顧客５０１である。通知の送付側は、預金の契約を行った相手方である銀行５０２である。情報の提示先も、預金の契約を行った銀行５０２である。取引の類型としては、受領側からの情報の提示先が通知の送付側である、第１の類型に該当する。
【００３４】
本実施例では、顧客の申し込みおよび銀行の受付によって発生した、預金の契約を結んだという取引状態が存在する。この預金が解約になると、顧客５０１および銀行５０２に、アンケートの送付側・アンケートの受領側という新たな関係が発生する。この情報収集は、例えば、顧客が契約した店舗ごと、または顧客の年代別などに分けて統計を行いたい場合がある。この場合、銀行は、顧客からアンケートを受領した際に仕分けを行う必要がある。一方、アンケートにおける本人確認の重要性は、特典の付与と比較して低い。そのため、銀行は、本人確認を必要としないこともできる。このように、本人確認を必要としない第１の類型であっても、送付者に関連する情報を容易に得ることができるため（詳細については後述する）、本発明は有用である。
【００３５】
図７は、本発明の一実施形態にかかる本人確認情報付き申込書一体型帳票を作成するシステムのモジュール構成図である。システム７００は、入力装置（図示せず）または外部のシステムなどから帳票を作成する指示を受信する帳票作成指示受信部７０１、所与の条件に合致するレコードを記憶部から抽出するデータ抽出部７０２、マスターデータおよび条件などを格納する記憶部７０３、作成する帳票の種別に対応するレイアウトに合わせて出力データを作成する出力データ作成部７０４、本人確認情報を作成する本人確認情報作成部７０５、ならびにプリンタなどの出力装置（図示せず）に出力データを送信する出力データ送信部７０６を備える。記憶部７０３は、預金に関する情報を格納する預金ＤＢ、提携企業に関する情報を格納する提携企業ＤＢ、および顧客に関する情報を格納する顧客ＤＢを有する。
【００３６】
次に、図７に示すシステムにおいて第一の類型に対応する本人確認情報付き申込書一体型帳票を実施する処理ステップを、図８を参照して説明する。処理Ｓ８０１において、帳票作成指示受信部は、特典付き預金の契約が２００９年９月３０日に解約になった顧客に対して送付する、本人確認情報付き申込書一体型帳票を作成する指示を受信する。この指示は、入力装置を介してシステムの利用者から、または一定の周期で帳票作成の指示を行う外部のシステムなどから受信することができる。夜間の日時処理の１つとして、当該本人確認情報付き申込書一体型帳票を作成するバッチ処理が自動で実行されることにより、この指示を受信することもできる。
【００３７】
処理Ｓ８０２において、データ抽出部は、預金ＤＢから２００９年９月３０日に解約になった特典付き預金のレコードを抽出する。預金ＤＢは、図９に示すように、少なくとも預金ＩＤ、特典付きフラグ、預金口座、預金額、預入日、満期日、解約日（支払日）、顧客コードおよび提携企業コードなどの、預金に関する属性を有する。特典付きフラグ属性は、例えば、特典付きでないことを示す０、または特典付きであることを示す１のいずれかの値をとることができる。満期日は、預金の預入期間の終了日が格納される。解約日（支払日）は、解約前は、解約日（支払日）が確定していないことを示すnullなどが格納され、解約後に、元利金が支払われた日が格納される。よって、データ抽出部は、預金ＤＢから、特典付きフラグが１であり、解約日（支払日）が２００９年９月３０日であるレコードを抽出する。図９の例では、預金ＩＤが０００１、０００３、および０００５のレコードが抽出される。
【００３８】
処理Ｓ８０３において、データ抽出部は、帳票種別が本人確認情報付き申込書一体型帳票であるかどうかを判定する。本実施例では、帳票種別が本人確認情報付き申込書一体型帳票であるため、処理Ｓ８０４に進む。次に、処理Ｓ８０４において、データ抽出部は、処理Ｓ８０２で抽出したレコードが特典を付与する条件を満たしているかどうかを判定する。
【００３９】
例えば、提携企業ＤＢは、図１０に示すように、少なくとも提携企業コード、提携企業名、郵便番号、住所、案内文１、案内文２、案内文３、特典付与条件１、および特典付与条件２を有する。提携企業コードは、複数の提携企業を識別する一意な識別子であり、提携企業名、郵便番号、住所、案内文１〜３には、それぞれ特典の申込書に記載される提携企業の情報である。また、特典付与条件は、特典を付与するために満たすべき条件が格納されている。本実施例においては、特典付与条件１には最低の預金額が、および特典付与条件２には最低の預入期間が格納されている。データ抽出部は、処理Ｓ８０２で抽出した各レコードが、特典を付与する条件を満たしているかどうかを、その提携企業の最低預金額属性および最低預入期間属性に基づいて判定する。
【００４０】
図１０に示す「○×商事」は、最低預金額属性に５００，０００の値、および最低預入期間属性に５の値が格納されている。つまり、○×商事は、預金額が５００，０００円以上であり、預入期間が５年以上経過している場合に、特典を付与する。また、「株式会社□□」は、最低預金額属性に０（またはnullなど）の値、および最低預入期間に２の値が格納されている。つまり、株式会社□□は、預入期間が２年以上経過している場合に、特典を付与する。したがって、処理Ｓ８０２で抽出した各レコードのうち預金ＩＤが０００１および０００３のレコードは、特典を付与する条件を満たすので処理Ｓ８０６に進む。預金ＩＤが０００５のレコードは、預金額が５００，０００未満で最低預金額の条件を満たさないため、処理Ｓ８０５で除かれる。
【００４１】
次に、処理Ｓ８０６において、出力データ作成部は、本人確認情報付き申込書一体型帳票に対応するレイアウトに合わせた出力データを作成する。具体的には、図１に示した本人確認情報付き申込書一体型帳票を作成するため、処理Ｓ８０２、処理Ｓ８０３、処理Ｓ８０４および処理Ｓ８０５を通じて抽出したレコードを基に各ＤＢから情報を収集し、予め定められたレイアウトに合わせて収集したデータを配置する。
【００４２】
次に、処理Ｓ８０７において、出力データ作成部は本人確認情報が必要かどうかを、作成する帳票の種別に基づいて判定する。本人確認情報が必要な場合、つまり、帳票の種別が本人確認情報付き申込書一体型帳票の場合、処理Ｓ８０８において、本人確認情報作成部は本人確認情報を作成する。本実施例では、特典付き預金であることを示す情報および預金を申し込んだ本人が知っている情報を使用して、ある規則またはアルゴリズムなどによって、新たなコードを作成する。使用される規則またはアルゴリズムは、一定の規則で並び替えを行う単純な規則、またはハッシュ法など、いかなる手法を用いることも可能である。ただし、作成された情報には、保護すべき個人情報が含まれるため、容易に看破されない困難性を有することが望ましい。作成された新たなコードは、図１に示す申込情報１５０に含まれる顧客確認情報に該当する位置に配置される。本人確認情報が必要でない場合、処理Ｓ８０９に進む。
【００４３】
なお、本明細書における本人確認情報には、葉書の送付者の真正性を示す情報のほかに、葉書の送付者の特定の情報を含むことができる。例えば、本人確認情報には、葉書の送付者が契約した店舗情報、および／または送付者の年齢、などを含むこともできる。図６のケースでは、このような情報を葉書に付加しておくことにより、葉書を受領した銀行は、店舗情報、年齢などに基づいて容易に葉書の仕分けを行うことができる。
【００４４】
最後に、処理Ｓ８０９において、作成された出力データが出力データ作成部から出力データ送信部に送られ、出力データ送信部から、任意の出力装置（図示せず）に送信され、本人確認情報付き申込書一体型帳票を得ることができる。
【００４５】
なお、本人確認情報の照合は、以下の方法によって行う。まず、葉書の送付者の真正性を確認する場合には、葉書の送付者に情報の記入を求めるため、前提として図１の申込情報１５０に該当の欄を設ける。本人確認情報の照合時には、特典付き預金であることを示す情報および葉書の申込情報１５０に記入されている情報などを使用して、処理Ｓ８０８と同一の規則またはアルゴリズムなどによって、新たなコードを作成する。
【００４６】
この作成されたコードが、処理Ｓ８０８において作成され、印字された申込情報１５０の顧客確認情報と一致する場合、葉書の送付者の真正性、および葉書の送付者が契約した預金が特典付き預金であることが保証される。なお、本人確認情報付き申込書一体型帳票の送付側（図５における銀行５０２）と、本人確認の照合を行う葉書の受領側（図５における提携企業５０３）とが異なるような本実施例においては、処理Ｓ８０８で使用された規則またはアルゴリズム、および特典付き預金であることを示す情報を共有しておく必要があることに留意すべきである。
【００４７】
本実施例は、預入期間が一定の期間以上経過していることを条件に、特典を付与する例について説明したが、別の実施例では、満期解約を条件に、特典を付与することもできる。
【００４８】
次に、図７に示すシステムにおいて第２の類型に対応する単独型帳票を実施する処理ステップを、図８を参照して説明する。処理Ｓ８０１において、帳票作成指示受信部は、特典付きでない預金の契約が２００９年１０月１５日に解約になった顧客に対して送付する、単独型帳票を作成する指示を受信する。この指示は、入力装置を介してシステムの利用者から、または一定の周期で帳票作成の指示を行う外部のシステムなどから受信することができる。夜間の日時処理の１つとして、当該本単独型帳票を作成するバッチ処理が自動で実行されることにより、この指示を受信することもできる。
【００４９】
次に、処理Ｓ８０２において、データ抽出部は、預金ＤＢから２００９年１０月１５日に解約になった特典付きでない預金のレコードを抽出する。データ抽出部は、預金ＤＢから、特典付きフラグが０であり、かつ解約日（支払日）が２００９年１０月１５日であるレコードを抽出し、図９の例では、預金ＩＤが０００２、および０００６のレコードが抽出される。
【００５０】
処理Ｓ８０３において、データ抽出部は、帳票種別が本人確認情報付き申込書一体型帳票であるかどうかを判定する。本実施例では、帳票種別が単独型帳票であるため、処理Ｓ８０６に進む。次に、処理Ｓ８０６において、出力データ作成部は、単独型帳票に対応するレイアウトに合わせた出力データを作成する。具体的には、図３に示した単独型帳票を作成するため、各ＤＢから情報を収集し、予め定められたレイアウトに合わせて収集したデータを配置する。
【００５１】
次に、処理Ｓ８０７において、出力データ作成部は本人確認情報が必要かどうかを、作成する帳票の種別に基づいて判定する。本実施例では銀行から顧客へ送る一方向の単独帳票であるため、本人確認情報は必要とされず、処理Ｓ８０９に進む。最後に、作成された出力データが出力データ作成部から出力データ送信部に送られ、出力データ送信部から、任意の出力装置（図示せず）に送信され、単独型帳票を得ることができる。
【００５２】
本実施例では、解約になった顧客に対して送付する、解約を通知する単独型帳票について説明したが、別の実施例では、満期になる期日の前に、これから満期になる顧客に対して送付する、満期案内を通知する単独型帳票を作成することもできる。
【００５３】
また、本実施例では、定期性預金について説明したが、流動性預金について適用することもできる。
【００５４】
以上、本発明によれば、前述の第１の類型にて作成する本人確認情報付き申込書一体型帳票と、第２の類型にて作成する単独型帳票とを同一のシステムによって実施することが可能であり、作業人員のコストを抑えることができる。また、本発明によれば、前述の第１の類型にて作成する本人確認情報付き申込書一体型帳票と、第２の類型にて作成する単独型帳票とを同一のプリンタから実施することが可能であり、ハードウェア資源などのコストも抑えることができる。
【００５５】
さらに、本発明によれば、第１の類型において実施される本人確認情報付き申込書一体型帳票を利用した場合、本人確認情報付き申込書の情報から本人確認を行うことができ、申込者の真正性が保障される安定した取引を、容易に行うことが可能である。
【図１】
2011073293.tif 000003
【図２】
2011073293.tif 000004
【図３】
2011073293.tif 000005
【図４】
2011073293.tif 000006
【図５】
2011073293.tif 000007
【図６】
2011073293.tif 000008
【図７】
2011073293.tif 000009
【図８】
2011073293.tif 000010
【図９】
2011073293.tif 000011
【図１０】
2011073293.tif 000012