冠婚葬祭支援システムおよび冠婚葬祭支援方法
【課題】 様々な冠婚葬祭イベントの種類、規模によらず、主催者、代表者、参加者それぞれに必要な情報提供を行う仕組みを提供すること。
【解決手段】 管理サーバは、代表者端末から冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを受信し、イベント情報に基づいて利用者配信ページを作成し、参加者リストの宛先に配信する。利用者配信ページに参加情報を入力した利用者を参加者と特定し、その参加情報をＤＢに記録する。参加情報には祝儀等の送金を受付ける情報も付加される。参加情報には、項目ごとに開示レベル属性を付加し、開示レベル属性に基づいて、参加情報の通知先である利用者の役割に応じて、通知する情報を制限する。
【解決手段】 管理サーバは、代表者端末から冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを受信し、イベント情報に基づいて利用者配信ページを作成し、参加者リストの宛先に配信する。利用者配信ページに参加情報を入力した利用者を参加者と特定し、その参加情報をＤＢに記録する。参加情報には祝儀等の送金を受付ける情報も付加される。参加情報には、項目ごとに開示レベル属性を付加し、開示レベル属性に基づいて、参加情報の通知先である利用者の役割に応じて、通知する情報を制限する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、冠婚葬祭等の各種イベントを行う主催者、イベントの連絡通知を行う代表者、およびイベントの参加者を支援するシステムおよび支援方法に関する。
【背景技術】
【０００２】
従来から、ネットワークを用いた冠婚葬祭を支援するためのシステムまたは方法が多数知られている。その多くは、冠婚葬祭に関する金品の成就の負担を軽減することや、直接、式典等に参加することができない利用者や、イベントの連絡担当者をサポートすることを目的としている。例えば、特許文献１には、冠婚葬祭の依頼者の端末からイベント情報を入力し、入力されたイベント情報に基づいて冠婚葬祭のドキュメントを作成して利用者に配信し、そのドキョメントを表示させた利用者の端末から祝儀・香典等の金額、利用者の個人情報を入力し、依頼者の端末から謝礼返しを手配する方法が記載されている。
【０００３】
特許文献２には、参加者に対してパスワードを事前に配布し、パスワードを入力することにより式典等のインターネット放送が視聴できるようになり、その視聴画面から電子商取引が可能な画面へ移行し、視聴者が冠婚葬祭等に伴う金銭の支払いができるようにするシステムが記載されている。また、特許文献３には、冠婚葬祭イベントが発生した場合に、当該イベントに関する情報をセキュリティーンゾーンに登録しておいた連絡先に配信できる冠婚葬祭情報配信システムが記載されている。
【０００４】
特許文献１の方法では、冠婚葬祭の依頼者（主催者）がシステムのメニューページで、イベントのすべての情報および告知のために参加候補者の電子メールアドレスを入力する必要があるが、イベントによっては主催者側でこれらの情報をすべて入力することは現実には難しい。特に、イベントが葬儀である場合には緊急性を要するので、主催者である家族等が故人の属していた組織やネットワーク（会社、学校、地域、サークル、友人等）の参加候補の人間を短時間で調べることは困難である。よって、連絡先を入力できない場合は、口コミに頼らざるを得ない。葬儀の場合、主催者は、会社等の組織やグループの連絡先（多くの場合、故人の上司や同僚、組織の総務担当者である）や、たまたま関係のあった知人（以下、まとめて代表者と呼ぶ）に連絡することになるが、連絡を受けた側も、故人のすべての関係者を知っているわけではないし、仮に自分が主催者の代わりに代表者となっても、参加する人間の住所・氏名や、香典の額、謝礼返しの品物や配送先等の個別情報にまでは関知したくないものである。一方、主催者側では、謝礼返しや会場の準備等のため、参加者の必要な情報を知りたいが、事前に参加者全体の情報を得ることは困難である。また、連絡を受けてイベントに参加しようと考える利用者（以下、参加者）にとっては、イベントの種類や規模に関係なく、過去に自分が祝儀や香典等の金品を、誰といくら交わしたかをまとめて知りたいと考える。今回のイベントに対する香典や祝儀等の金額は、いざ通知を受けたその場になってはじめて考えるからである。
【０００５】
特許文献２に記載の方法は、多忙や遠隔等の理由で式典に直接参加できない利用者の冠婚葬祭等に伴う金銭集金を代行するものであり、特許文献３に記載の方法は、企業における代表者が連絡先に迅速に情報発信することを目的とするものであるが、いずれも、関係者を個別にサポートするものであっても、代表者、主催者および参加者のニーズをトータルにサポートするものではない。冠婚葬祭イベントには、結婚，葬儀を始めとして、法事，出産，初節句，七五三，入園・入学，卒業・就職,成人式，結婚記念日，栄転・昇進，新築，引越，定年退職，開店・開業、長寿祝い、病気・けが見舞い,災害見舞い等、様々なものがあり、誰もが多数のイベントの主催者、代表者、参加者になりうることを考えれば、イベントの種類や規模によらず、イベント全体をさまざまな場面で一元的に管理できる仕組みが望まれる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−２５６３１９号公報
【特許文献２】特開２００２−８３０７５号公報
【特許文献３】特開２００１−３１８９９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明では、上記のような課題に鑑み、冠婚葬祭等のイベントの種類、規模によらず、主催者、代表者、参加者それぞれに必要な情報を提供できる冠婚葬祭支援システムおよびその支援方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を達成するため、本発明の冠婚葬祭支援システムでは、以下の機能を備えている。
複数の利用者端末と、管理サーバを含む金融機関システムとがネットワークを介して接続された冠婚葬祭支援システムであって、前記管理サーバは、冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを発信する利用者端末を当該イベントの代表者端末と特定し、前記イベント情報に基づいて利用者配信ページを作成し、前記参加者リストの宛先に配信する利用者配信ページ作成部と、前記利用者配信ページに参加情報を入力した利用者を参加者と特定し、前記参加者からの祝儀または不祝儀金の送金要求情報を受付け、前記参加情報に付加して記録する参加者管理部とを備え、前記イベント情報および前記参加情報の項目ごとに開示レベル属性を付加し、前記開示レベル属性に基づいて、前記イベント情報および前記参加情報の通知先である利用者端末の役割に応じて、通知する情報を制限することを特徴とする冠婚葬祭支援システム。
【０００９】
上記発明によれば、本システムの中核である管理サーバは、代表者端末からのイベント情報に基づいてイベント配信ページを作成して参加者リストに記載された宛先に配信する。配信を通知された利用者は、イベント配信ページに参加情報を入力することによって、参加を申し込むことができるが、直接会場に行くことができない場合にも、祝儀・不祝儀の金銭の送金を参加情報に加えることができる。その際、参加情報には、住所氏名などの個人情報の他、送金金額、送金元の口座情報等、他の参加者や代表者にも知られたくない情報も含まれるため、システムでは項目ごとに開示レベルが付加され、項目ごとに開示先を制限できる。このようにすることにより利用者は安心して参加情報を入力できるし、代表者や主催者にも不必要な情報が開示されることがない。
【００１０】
上記システムは、さらに以下の機能も備えることができる。
前記管理サーバは、前記参加者ＤＢを参照して、前記参加者が金品の宅配を希望する旨の情報を抽出し、当該情報に基づいて宅配依頼データを作成し、宅配業者システムに前記宅配依頼データを送信する宅配依頼部を備える。
【００１１】
上記発明によれば、参加者が主催者に現金の振込みではなく、直接金品を届けたいと望む場合は、その金額または品物を指定し参加情報に加えることによって、主催者に直接届けるための宅配サービスを本システムから依頼することができる。このようにすることで、参加者は、いながらにしてすべての操作を一度で済ますことができる。
【００１２】
上記システムは、さらに以下の機能も備えることができる。
前記宅配依頼部は、当該イベントの主催者である主催者端末から、返礼のための金品の手配要求を受付けて宅配依頼データを作成し、前記宅配業者システムに前記宅配依頼データを送信する。
【００１３】
上記発明によれば、主催者側からイベントに参加者に対して返礼品を送る手配をすることができる。主催者側には、参加者が受け取りを拒否した場合を除いて、参加者の少なくとも住所・氏名・送金額が通知されるので、主催者が返礼を手配する手間が軽減できる。
【００１４】
上記システムにおいては、主催者端末と代表者端末は異なる利用者の端末であってもよい。これは、特にイベントが葬儀または大規模ある場合、主催者が参加候補者のすべての宛先を知ることが困難であるため、主催者とは別の代表者を立てることにより、主催者と代表者の役割を分担するようにするためである。つまり、イベントの決定とイベント情報の詳細は主催者が、イベントの概略情報と通知先は、例えば会社の代表者が、というように、それぞれのシステムへの入力負担を軽減することができる。この場合、代表者は、主催者と親しい間柄である必要はなく、会社の総務担当者のように単に事務的に通知のみを扱う人間でもよい。
【００１５】
上記システムは、さらに以下の機能も備えることができる。
前記管理サーバは、複数の代表者端末からそれぞれ別々に入力されたイベント情報を解析し、同一のイベントであると判定した場合は、当該イベント情報をマージしてひとつのイベントとして管理する。
【００１６】
上記発明によれば、大きな会社等で代表者が複数いるような場合（例えば、複数の部署に故人が在籍していたような場合）で、主催者がお互いの代表者間の関係を知らないような場合でも、別個に入力されたイベント情報の内容をシステムが解析し、同じイベントであると判断したときは、以後ひとつのイベントとして管理できる。このようにすることで、重複入力や、同じイベント情報が別のルートから複数流れるのを防止できる。
【００１７】
上記システムは、さらに以下の機能も備えることができる。
前記管理サーバは、前記利用者端末からの要求に基づいて、当該利用者のイベントに関する利用履歴を前記利用者端末に表示させる。
【００１８】
上記発明によれば、本システムの利用者は、過去に金品をやり取りした冠婚葬祭すべての情報が横断的に一覧できるので、例えば、イベントの参加依頼通知を受けた際に、過去の履歴を表示して、同一の相手先とのやりとりがあれば、今回のイベントの祝儀、不祝儀の金額を決める際の参考になる。また、冠婚葬祭の年間の支出額の管理等にも役立つ。
【００１９】
また、本発明は、別の態様として、以下のような冠婚葬祭支援方法としても捉えることもできる。
複数の利用者端末と、管理サーバを含む金融機関システムとがネットワークを介して接続されたシステムにおける冠婚葬祭支援方法であって、前記管理サーバが、冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを発信する利用者端末を当該イベントの代表者端末と特定し、前記イベント情報に基づいて利用者配信ページを作成し、前記参加者リストの宛先に配信する段階と、前記利用者配信ページに参加情報を入力した利用者を参加者と特定し、前記参加情報を記録する段階とを含み、前記イベント情報および前記参加情報の項目ごとに開示レベル属性を付加し、前記開示レベル属性に基づいて、前記イベント情報および前記参加情報の通知先である利用者端末の役割に応じて、通知する情報を制限する段階を含むことを特徴とする冠婚葬祭支援方法。
【発明の効果】
【００２０】
本発明によれば、冠婚葬祭等のイベントの種類、規模によらず、主催者、代表者、参加者それぞれに必要な情報ニーズを満たすような仕組みを提供することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態に係る冠婚葬祭支援システム１全体の概略を示す図である。
【図２】本発明の実施形態に係る冠婚葬祭支援システム中核部１０の機能構成を示す図である。
【図３】本発明の実施形態に係る利用者管理テーブルおよび参加者管理テーブルを示す図である。
【図４】本発明の実施形態に係る利用者配信ページ作成部１４の処理手順を示すフロー図である。
【図５】本発明の実施形態に係る参加者管理部１５の処理手順を示すフロー図である。
【図６】本発明の実施形態に係る宅配依頼部１６の処理手順を示すフロー図である。
【図７】本発明の実施形態に係る冠婚葬祭サービスメイン画面と、葬儀サービス依頼画面を示す図である。
【図８】本発明の実施形態に係る葬儀サービスを選んで入力完了後に利用者に通知される画面を示す図である。
【図９】本発明の実施形態に係る各種パーティサービス依頼画面を示す図である。
【図１０】本発明の実施形態に係るご祝儀お届けサービス申し込み画面を示す図である。
【図１１】本発明の実施形態に係るご祝儀受取画面を示す図である。
【図１２】本発明の実施形態に係る入出金管理画面および返礼登録画面を示す図である。
【発明を実施するための形態】
【００２２】
以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。
【００２３】
図１は、本発明の実施形態に係る冠婚葬祭支援システム１全体の概略を示す図である。本システムでは、冠婚葬祭支援システム中核部１０（または単に、システム中核部）と、銀行等の勘定系ホストコンピュータ１０Ａが接続される。両者を合わせて、広い意味で冠婚葬祭支援システム中核部２０と呼ぶことがある。
【００２４】
システム中核部１０は、ネットワーク７０を介して、利用者端末３０，３１，３２が接続され、また、宅配業者システム４０，贈答品販売業者システム５０，他金融機関システム６０とも接続されている。「利用者端末」とは、本システムが提供するサービスの利用者（ユーザ）の端末を示すが、すべての利用者は、イベントによって、代表者にも、参加者にも、主催者にもなりうるので、それぞれの役割を持った利用者の端末を他の端末と区別するときは、参加者端末３０、代表者端末３１、主催者端末３２と表すものとする。特に区別する必要がない場合は、単に利用者端末と呼ぶことにする。利用者端末は、ネットワークに接続できる一般的なＰＣ（Personal Computer）や携帯電話をはじめとする各種の移動情報端末であってよいいが、各利用者端末は、必ずしも利用者側が所有する端末でなくとも、利用者の依頼に基づきデータを入力するサービス提供者側の端末であってもよい。
【００２５】
図２は、本発明の実施形態に係る冠婚葬祭支援システム中核部１０の機能構成を示す図である。システム中核部１０は、本システムの管理サーバとして機能するコンピュータであり、主な機能部として、利用者配信ページ作成部１４，参加者管理部１５，宅配依頼部１６で構成され、関連するデータベース（ＤＢ：Data Base）として、利用者ＤＢ１１，参加者ＤＢ１３，振込金一時保管口座ＤＢ１２が存在する。ただし、振込金一時保管口座ＤＢ１２は、ホストコンピュータ１０Ａに存在してよい。図では、利用者ＤＢは便宜上参加者側のＤＢと主催者側のＤＢに分けて示しているが、実際は同じＤＢであってよく、特に両者に実装上の区別はない。
【００２６】
上記の機能構成は、あくまで一例であり、一つの機能部を更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。各機能部は、典型的には、メモリ（ＲＡＭ：Random Access Memory,ＲＯＭ：Read Only Memory）や記憶装置に格納されたコンピュータ・プログラムが読み出され、装置に内蔵されたＣＰＵ（Central Processing Unit）で実行され、実行されたプログラムが記憶装置に格納されたＤＢから必要なデータを読み書きし、場合によっては、その他関連するハードウェア（例えば、入出力装置や通信インターフェース装置）を制御することによって実現される。以下、個々の機能部の働きと、関連するデータについて説明する。
【００２７】
システム中核部１０の各機能部は、様々な入力画面を利用者端末に表示させるが、イベントごとに、各サービス要求画面に利用者が入力した段階でユーザＩＤとその役割の関連付けをするので、ユーザＩＤとイベントＩＤによって、システムは、端末の役割を検知することができる。すなわち、あるイベントでは参加者であったユーザが別のイベントでは主催者となったりする。そのため、本システムが提供する各画面には、イベントごとに主催者用，代表者用，参加者用，その他一般利用者用に分けられ、それぞれの識別子が付加されている。
【００２８】
利用者配信ページ作成部１４は、代表者端末３１からサービス依頼情報１７の入力を受け、イベント情報を作成し、サービス依頼情報１７に含まれるイベントの参加者候補となる利用者の配信先（電子メールアドレスまたは専用ＵＲＬ）にイベント情報を配信する。イベント情報は、電子メールの本文またはイベント情報が記載したＷｅｂページ、あるいはその両方であってもよい。
【００２９】
サービス依頼情報１７は、代表者端末３１からでなくとも、主催者端末３２から入力してもよいが、イベントの規模によっては、主催者よりもその組織やグループの代表者のほうが配信先の情報を得やすいので、本システムでは、イベント情報の最初の入力端末を代表者端末３１としている。ただし、イベント情報の更新は、主催者端末３２からでも可能である。このように代表者と主催者の役割を分けることにより、それぞれの入力負担を軽減する。もちろん、主催者が代表者を兼ねることも可能である。結婚式や親近者だけのパーティ等、主催者側で参加者（招待者）をすべてを把握できる場合は、代表者を立てることなく主催者側ですべての入力を行うことができるので、この場合は、代表者端末３１イコール主催者端末３２となる。
【００３０】
代表者が配信先（あるいは参加者リスト）、イベント情報を入力完了すると、利用者配信ページ１８が作成さえる。配信された利用者は、このページを参照してイベントに参加を申し込む。利用者が参加申し込みをした利用者配信ページ１８の内容（参加情報）は、後で詳しく説明するが、入力項目ごとに開示先を限定する開示レベルの属性をもち情報の開示先が項目ごとに管理される。例えば、利用者者配信ページ１８の内容中、参加者の必要な項目だけが主催者端末３２に通知されるようにする。主催者も、後に返礼をするためだけの情報を知ることができればよいからである。参加情報は、特段の指定がない限り、代表者端末３１や他の参加者端末３０からは参照できないようにする。代表者にとっても、個々の参加者の個人情報等までは知る必要がないし、参加者同士でも互いに個人情報を知る必要はないからである。なお、本システムの利用者は、自己の出金情報または入金情報の履歴の詳細は、役割を問わず、すべて参照することができる。冠婚葬祭に関する金銭等の入出金履歴は、本システムを介してやり取りする限り、すべてが利用者毎に自動的に利用者ＤＢ１１に記録される。
【００３１】
代表者端末３１は複数であってもよく、組織やグループごとに存在してよい。主催者は、代表者の連絡先だけを把握し、その代表者にイベントの情報を連絡可能とする。また、代表者が他の代表者となりうる者を知っている場合は、代表者から直接その他の代表者になりうる者に連絡し、代表者となってもらうこともできる。なお、代表者となった者は、代表者端末３１から、イベントの情報を主催者から受けてシステムにイベント情報として入力し、参加候補者の連絡先の情報を入力するが、自分自身は必ずしもイベントに参加するとは限らないので、参加者となっても、ならなくともよい。参加者となる場合は、代表者端末３１は、参加者端末３０を兼ねる。
【００３２】
参加者管理部１５は、利用者配信ページ作成部１４がイベント情報を配信した利用者の中から実際に参加意思表示をした利用者を以後「参加者」として抽出し、管理するためその参加情報を参加者ＤＢ１３に登録する機能を備える。利用者は、利用者配信ページ１８に自己の必要な情報を入力することによって参加者として認識される。もちろん、イベント開始前であれば、取り消しも可である。
【００３３】
振込金一時保管口座１２は、参加意思表示した利用者から、祝儀や香典等の金銭の送金をする場合に銀行内に一時的にそのお金を保管しておく口座である。利用者からの送金を一時的に保管しておく仕組みは、別段預金口座として銀行のシステムにすでに存在するのでこれを利用してもよい。参加者管理部１５は、この振込金一時保管口座１２から参加情報に付加された振込情報（送金情報）を取り出し、宅配依頼部１６に通知する。
【００３４】
宅配依頼部１６は、宅配業者システム４０と接続され、参加者ＤＢ１３に格納された参加情報を参照し、参加者からシステムの管理する振込金一時保管口座１２へ入金があったときに、主催者に直接祝儀等を現金または品物で届けるサービスを受付ける機能を備えている。現在、一般の宅配業者の約款では現金は宅配できないので、その場合は振り込まれた金額に相当する品物を贈ることになるが、銀行と郵便局が提携して依頼者の指定口座から依頼された金額を引き落とし、現金書留で郵送できる現金宅配サービスが既に始まっており、本システムと連携することで、現金を送ることも可能となる。
【００３５】
本サービスの主催者、代表者、参加者となるためには、本システムに登録してユーザＩＤの発行を受ける必要があるが、ユーザＩＤの発行を受けるためには、氏名、パスワード、メールアドレス程度の入力だけでよく、その後の個人情報や口座情報等は、必要な際に入力を求められるようにすることが望ましい。ユーザ数が広がれば広がるほど本システムの有用性が高まるので、イベント通知の際の画面等にユーザ登録を手軽に行えるボタンを配置しておくようにする。
【００３６】
図３は、本発明の実施形態に係る利用者管理テーブルおよび参加者管理テーブルを示す図である。利用者管理テーブルは、利用者ＤＢ１１に格納され、本システムに登録されたユーザ情報全体を管理するテーブルである。利用者テーブルには、図３（ａ）で示すように、ユーザＩＤ，氏名・住所・電話番号，メールアドレス，パスワードの他、入出金のための銀行口座番号や、必要であれば、クレジットカード情報等が含まれる。
【００３７】
テープル内の個人情報は項目ごとに「開示レベル」が定義され、利用者本人以外に開示できる範囲が限定される。例えば、開示レベル１の情報は全ユーザまたはユーザ許可した範囲のユーザに開示され、開示レベル２の情報は代表者または主催者に開示され、開示レベル３の情報は主催者のみに開示され、開示レベル４では利用者本人にしか開示されないように定義する。図の例では、開示レベル１は、メールアドレス（ユーザＩＤも含む）、開示レベル２は氏名・住所・電話番号、開示レベル３は口座番号、開示レベル４はパスワードに項目の属性として付加されている。項目ごとの開示レベルは、イベントの種類に応じてシステムがデフォルトを設定するが、利用者も変更できるものとする。もちろん、開示レベルの定義は、利用者ごとにカスタマイズできる。
【００３８】
利用者管理テーブルには、上記個人情報の他、個別の利用履歴として、利用年月日，利用サービスの種類，取引ＩＤ，取引相手の氏名とユーザＩＤ，取引金額，取引方法，本システムにおける自分および相手先の役割等、イベントにおけるすべてのやりとりが記録される。取引相手とは、祝儀や不祝儀の金品を取り交わした相手である。金額だけでなく贈答品名等も記録されてよい。システムでは把握できない手渡しでのやりとりも利用者自身が入力することで利用履歴に追加することができる。利用履歴は、利用者本人であればいつでも閲覧できるが、特に金銭を振込む画面からワンタッチで参照できるようにすることが望ましい。振込み時に過去の履歴を参照することが多いからである。
【００３９】
図３（ｂ）には、利用者配信ページ１８でイベントに参加申し込みをした利用者の情報（参加情報）が記録される。例えば、イベントＩＤ，利用サービスの種類，代表者ユーザＩＤ，主催者ユーザＩＤ等である。また参加情報（図では、＜参加者リスト＞形式で表示されている）には、個々の取引毎にその金銭のやりとりの詳細情報が記録されている。この参加情報の各項目にも開示レベルが定義される。主催者は一部を除き、ほとんどの項目が参照できるが、代表者や参加者は、参加者の氏名またはユーザＩＤまたは参加者の人数程度が開示されるが、それ以外は開示されないように開示レベルを設定して不要な情報のやりとりを防ぐ。
【００４０】
図４は、本発明の実施形態に係る利用者配信ページ作成部１４の処理手順を示すフロー図である。利用者配信ページ作成部１４は、まずステップＳ１０において、利用者端末からサービス開始要求を待つ。サービス開始要求があれば、要求されたサービスの種類によってその入力画面を送信する（ステップＳ１１）。つぎに、ステップＳ１２において、入力データが、イベント毎に定義された必要最小限の項目を満たしているかどうかチェックし、満たしていなければ修正を要求する。入力データのチェックがすべてＯＫであれば、ステップＳ１３に移り、入力された情報を基に、利用者（参加候補者）への通知メールを作成する。通知メールは、イベントにより雛形がいくつか用意されていることが望ましい。なお、このとき、利用者配信ページ作成部１４は、サービス開始要求を送信した端末（ユーザＩＤ）を代表者端末３１と認識する。
【００４１】
次に、利用者配信ページ作成部１４は、ステップＳ１４において、利用者（参加候補者）に対する利用者配信ページ１８を作成し、ステップＳ１５において、先に通知メールに、サービス申し込みページへのリンクを付加する。サービス内容あるいはイベントによって追加ページが必要な場合はそのリンク先を追加する（ステップＳ１６）。例えば、会場の場所や電話番号、アクセスが記載されたページへのリンクを追加する。最後に通知メールを入力された参加者リストの宛先に送信する（ステップＳ１７）。なお、通知メールは、電子メールで送信する他、企業によっては訃報通知専用ページ等があるので、その場合は、その専用ページからリンクされるようにしてもらい、そのＵＲＬを宛先としてもよい。
【００４２】
通知メールを受け取った利用者は、通知メールにリンクされたサービス申し込みページを開き、参加すべきイベントと判断した場合は、参加申し込み欄等をクリックする。祝儀・香典等を送金する場合は、その支払い方法（銀行振込、クレジットカード払い）や宅配サービス（後述）を指定することができる。もちろん、参加者は会場に出向き直接祝儀等を手渡してもかまわないが、その場合は、手渡しの欄をクリックするしてもらうと、参加者の人数把握に役立つ。参加者が入力した情報は参加情報として、イベントごとに管理され、利用者ＤＢ１１および参加者ＤＢ１３に保存される。なお、通知メールを受け取った利用者が、本システムのユーザでない場合は、通知画面から直ぐにユーザ登録できるようにしておくことが望ましい。ユーザ登録せずとも参加申し込みクリックはできるが、自動送金や宅配サービスを利用することはできない。
【００４３】
図５は、本発明の実施形態に係る参加者管理部１５の処理手順を示すフロー図である。参加者管理部１５は、利用者配信ページ１８から参加申し込みをした利用者を以後、参加者として扱い、イベントごとに管理する機能を持つ。
【００４４】
まず、参加者管理部１５は、ステップＳ２０において、現在時刻がサービス終了時間に達してないかチェックし、サービス終了時間に達していれば処理を終了する。サービス終了時間とは、イベントごとにあらかじめ定められたサービス受付け可能な時間である。例えば、イベント開始１時間前とかイベント終了後数日後までとかに設定される。サービス終了時間は、イベントの種類に応じてシステムによってデフォルトが設定されるが、主催者または代表者が設定することもできる。
【００４５】
サービス時間中であれば、参加者管理部１５は、ステップＳ２１において、利用者配信ページを常時参照して、参加申し込みを待つ。参加申し込みがあり、さらに自動送金の要求がある場合は（ステップＳ２２；Ｙｅｓ）、入金方法によって処理を以下のように分ける。本サービスを行っている銀行からの送金の場合は、振込依頼画面を送信して入金を依頼する（ステップＳ２３）。このとき振込先は、主催者が許可すれば主催者の銀行口座でもよいが、銀行が本サービス専用に用意した別段預金口座にしてもよい。参加者から振り込まれた入金はこの別段預金口座に一時的に保管され、その後、主催者の口座に振り込まれる。こうすることで主催者は、口座番号を参加者に知らせずとも入金を受けることができる。また、入金を他行からの振込で行う場合は、他行決済待ち処理を行う（ステップＳ２４）。クレジットカード決済の場合は、クレジットカード決済画面を送信し、決済を待つ（ステップＳ２５）。これら入金処理手順の詳細については広く行われていることであるので説明は省略する。
【００４６】
参加者管理部１５は、ステップＳ２６においてすべての入力データがＯＫであること、ステップＳ２７において決済が完了していることをチェック後、取引データを参加者ＤＢ１３に記録する（ステップＳ２８）。ただし、他行からの振込みのように決済に時間がかかる場合は、中間状況をいったん記録するようにする。なお、自動送金を参加者が利用してない場合でもそれ以外のデータは記録される。
【００４７】
図６は、本発明の実施形態に係る宅配依頼部１６の処理手順を示すフロー図である。宅配依頼部１６は、参加者の希望に応じて金銭や品物を主催者に届けるサービスを手配する機能をもつ。宅配依頼部１６は、祝儀等の金銭を主催者の口座へ振込むだけでは失礼と考える参加者、および香典返しなどお返しをする際に金品を参加者に届ける負担を減少させたい主催者のニーズを満たすため宅配業者システムと連動する機能を備えている。
【００４８】
まず宅配依頼部１６は、ステップＳ３０において、現在時刻が、申し込みページ（利用者配信ページ）閉鎖時刻になるまで待機する。申し込みページ閉鎖時刻は、図５のサービス終了時間と同じとしてよいが、宅配業者の都合も考慮して決められる。
【００４９】
次に宅配依頼部１６は、ステップＳ３１において、参加者ＤＢ１３を検索し、宅配希望の要求があるにもかかわらず未完のデータがあるかどうかをチェックする。例えば、他行からの振込が所定期間経過しても完了しないような場合である。未完データがあれば、未完データの参加者にその旨の通知メールを送信する（ステップＳ３２）。同時に担当者から電話連絡をさせるようにしてもよい。
【００５０】
その後、宅配依頼部１６は、参加者ＤＢ１３をいったんクローズする（ステップＳ３３）。そして、参加者ＤＢ１３から宅配に必要な情報（送り主、送り先、送金額または品名・商品番号、および、お届け希望日時等）を取り出し、宅配データ（宅配依頼データ）を作成する（ステップＳ３４）。これらの処理を宅配要求を持つ参加者がなくなるまで繰り返す（ステップＳ３５）。
【００５１】
そして宅配依頼部１６は、すべての参加者の宅配データをまとめて、宅配業者システム４０へ送信（ステップＳ３６）し、宅配受付完了通知を受信するまで待機する（ステップＳ３７）。宅配業者システム４０から、宅配受付完了通知を受信すると、参加者にたいして宅配の受付の完了通知を送信する（ステップＳ３８）。上記処理手順では、冠婚葬祭イベントの開催期間は通常短期間であるため処理効率をあげるためにイベントごとに閉鎖時間を定めて、閉鎖時間後にまとめて宅配データを宅配業者システム４０に送信しているが、宅配サービス要求が発生するたびに、宅配データを作成し、送信すようにしてもよい。
【００５２】
図７は、本発明の実施形態に係る冠婚葬祭サービスメイン画面と、葬儀サービス依頼画面を示す図である。イベントが発生して本システムでサービス開始を依頼しようとする利用者（主催者または代表者）は、まず、この冠婚葬祭サービスメイン画面１００でサービス名を選択してログインする。もちろん、ログインが完了してからメインメニューを表示してもよい。メインメニューには、本システムが提供するサービスのメニューが表示される。メニューには、例として、結婚式・披露宴１０１，葬儀１０２，各種お祝い１０３，法事１０４，各種パーティ１０５等イベント発生時にサービス依頼を行うものの他、入手金管理１０７のようにいつでもサービスを受けられるもの、お返し手配１０８のように、イベント終了後でも受付けられるサービスがある。特に図示していないが、他にも様々な冠婚葬祭の種類があるので、それらのメニューを個別に用意されてよい。なお、入手金管理１０７，お返し手配１０８については、各サービスの中からでも依頼できる。また、はじめての利用者は、ユーザ登録１０９を押すことによって本システムにユーザ登録する。
【００５３】
ここでは、一例として、利用者が葬儀１０２を選択した場合の葬儀サービス依頼画面１１０を図７の右側に示す。この画面では、葬儀イベント情報を登録するための各種入力項目が表示される。各入力項目には前述したような開示レベルが属性として付加されている。葬儀の場合、この画面で入力するのは、多くの場合主催者でなく組織やグループの代表者である。主催者側で組織内の故人にゆかりのあるメンバーを知ることは容易ではないからである。主催者から連絡を受けた代表者は、まずこの画面で組織等の属性（会社，学校・同窓会，友人，町内会等）を入力領域１１１で選択する。この例では「会社」を選択したものとする。代表者は、その後、自分の氏名、会社名、部署、住所等の代表者側の情報１１２および主催者側の情報１１３を入力するが、同じ葬儀ですでに代表者になっている利用者があれば、その情報も表示するようにする。すでに代表者になっている利用者がいれば、主催者情報などの重複入力が避けられ、同じ会社で別の代表者がいれば、配信先の入力などをグループごとに分担できるからである。
【００５４】
代表者は、葬儀に参加する可能性のある参加候補者を、従業員リストあるいは部署内リストをもとに入力領域１１４に参加候補者情報（参加者リスト）として入力する。ここで最低限必要な入力項目としては、メールアドレス、氏名，所属部署程度でよく、すべての項目を埋める必要はない。代表者として過去に参加者候補情報を入力したことがある場合は、それが初期画面に表示されるので必要な箇所を追加修正するだけでよい。また、参加候補者の宛先は、個々に入力してもよいが、多人数になる場合が多いので、ＣＳＶ（Comma Separated Values）ファイルや表形式ファイルなどで受付けられるようにすることが望ましい。また、社内のイントラネット等に訃報を知らせるための専用ページがあれば、そのＵＲＬを参加者のリストの代わりとしてもよい。
【００５５】
最後に、代表者は、入力領域１１５において、参加候補者に通知するメッセージを入力する。通知文の雛形はシステムからイベントに応じて数種が提供されるので、必要な箇所のみを修正すればよい。代表者は、以上のデータを入力し終わったら、送信ボタンを押してイベント登録を終了する。以後は、代表者としては特になにもする必要はない。システムは、主催者情報が一致する（完全一致でなくとも日時、場所、主催者が同じであればよい）イベントがあればそれをマージし、各代表者や主催者にその旨を通知してもよい。
【００５６】
図８は、本発明の実施形態に係る葬儀サービスを選んで入力完了後に利用者に通知される画面を示す図である。前図において、葬儀サービス依頼画面から、必要な情報を入力完了すると、図８に示すように、通知メール１２０、香典お届けサービス申し込み画面１３０が作成され、参加候補者のもとに通知される。
【００５７】
通知メール１２０を受け取った参加候補者は、通夜・葬儀の場所等を確認し、直接参列することはできないが香典を振り込みたいという場合には、「お香典お届けサービス」をクリックすることにより、お香典お届けサービス申し込み画面１３０を表示させる。参加者は、この画面から必要な個人情報を入力して、支払い方法などを選択する。さらに主催者に送るメッセージ１３３を記入することができる。個々の入力項目には、開示レベルの属性が付加されていることはいうまでもない。
【００５８】
支払い方法は、参加者が本システムを提供する銀行に口座を持っていれば、香典の金額を自分の口座から本サービス専用に設けられた銀行の別段預金口座に振り込む（後で主催者の口座に自動的に振り込まれる）ことができる。もちろん、他行からの振込みや、クレジットカードによる支払い受付も可能である。また、葬儀に直接参列する参加者も香典だけをこのシステムで振込むことが可能である。その場合、葬儀会場の受付ではその旨を申したてる。参列者にとっては、現金をのし袋に入れる手間が省け、主催者側でも葬儀の受付担当者が多額の現金を取り扱うリスクが現象するので、双方にとって有益である。
【００５９】
画面１３０において、参加者が振込む香典の金額を決める際に、利用履歴ボタン１３１を押すことによって過去の冠婚葬祭に関する自己の入出金履歴を容易に調べることができる。図８の右端の利用履歴画面１４０はこの表示例である。利用履歴は、利用者ＤＢ１１に格納された本システムを介してやりとりされた過去のすべての記録が表示できる。表示の形式は、やりとりの相手順、日付順、金額順の他、イベント別、役割別等、利用者が選択した任意の方法でソートして表示できる。なお、特に図示していないが、本システムを介さないで利用者どうしが直接やりとりしたデータもこの画面または別の入力画面から利用者が直接入力できるものとする。これらのデータも手入力であること識別情報を付加され、利用者ＤＢ１１に保存される。また、画面１３０に主催者に送るメッセージ入力欄１３３を追加してもよい。さらに文例ボタン１３４を設け、メッセージの例文を表示させてもよい。
【００６０】
図９は、本発明の実施形態に係る各種パーティサービス依頼画面を示す図である。パーティのイベントでは、葬儀と異なり、通常、主催者が参加者（招待者）を決めることが容易である。以下の例では、小規模のパーティを前提にしているが、参加者が特定できないような大規模パーティの場合は、葬儀の場合と同様に、複数の代表者が主催者に代わりイベント情報を入力することで対処できる。
【００６１】
図には、各種パーティサービス依頼画面１５０を示す。既に述べたように、本システムでは、イベント情報をサービス依頼画面で入力する利用者のユーザＩＤをそのイベントの代表者と認識する。この例では、パーティが比較的小規模で、主催者自らが代表者となってイベント情報を入力する場面を示している。代表者情報１５１、参加者リスト１５３の入力する項目については、前述の葬儀の例とほぼ同じであるが、主催者情報１５２は、代表者と同じであれば入力する必要はない。代表者は複数であってもよい。すなわち、ある利用者が入力したイベント情報を別の利用者が別途入力するとシステムにより同一性が検知された段階で両イベントはマージされて同じイベントＩＤが付加される。また、後で入力した利用者も共に代表者となる。
【００６２】
なお、本システムを利用して金品を送る相手が、主催者と異なる場合には、送付先の情報を別途入力する必要がある。図の例のように、代表者・主催者が別の人間のお祝いを開催するような場合である。ただし、このとき、送付先相手に対して、通常の主催者と異なる開示レベルを定義するようにしてもよい。例えば、開示レベル９を定義した送付先には、システムからの通知をいっさい送信せず、代表者に代わりに送付するといった工夫ができる。
【００６３】
また、図の下段に示される通知文は、用意された雛形を修正して作成する点は前図と同じであるが、雛形には、「祝儀お届けサービス」へのリンク１５５だけでなく、この例のように、出欠表１５０をリンクさせてもよい。通知文からリンクされた出欠表にメッセージ入力欄を表示してもよい。出欠表に入力した情報は、通常、まとめて代表者（主催者）に開示されるので、出欠者の管理に役立てることができる。なお、出欠表１６０を受け取った利用者が本システムのユーザでない場合を想定し、この出欠表からも直接ユーザ登録できるようにユーザ登録ボタン１６９を配置するとよい。
【００６４】
図１０は、本発明の実施形態に係るご祝儀お届けサービス申し込み画面を示す図である。基本的には、図８中央のお香典お届けサービスの画面と同じであるが、香典とは異なり、現金以外にも商品券や品物を宅配で送るサービスが追加される。品物を送る場合は、贈答品専門オンラインショップへのリンクボタン１７３が貼られているので、そこから通常のオンラインショップの画面に移行してもよい。ただし、その場合であっても、贈答品販売業者システム５０から購入情報を受信して、利用者ＤＢ１１にその取引記録を残すことができる。
【００６５】
また、図１０の右の利用履歴画面１８０で示すように、本イベントの利用履歴では、入出金方法として、現金のやりとりではなく贈答品の品名とその商品情報ページ１８２へのリンクを表示するようにしてもよい。こうすることで、贈答品販売業者にとっても商品の露出機会を増やすことになるので本システムとの連携にメリットを感じる。
【００６６】
図１１は、本発明の実施形態に係るご祝儀受取画面を示す図である。図示するうに、祝儀の受領者には、祝儀お届けメッセージ１７５が電子メール等で届けられる。祝儀お届けメッセージ１７５からは、リンクされた祝儀受取確認画面１８５を直接開くことができ、祝儀の内容（振込人、祝儀金額、メッセージ等）、および祝儀が振り込まれたことを確認することができる。
【００６７】
図１２は、本発明の実施形態に係る入出金管理画面および返礼登録画面を示す図である。図１２（ａ）の入出金管理画面１９０には、利用者ＤＢ１１に記録された冠婚葬祭に関するイベントにおけるすべての記録が表示される。前述したように、各サービスの申し込み画面からも利用履歴画面は表示できるが、本画面からは、図示していないが、利用者間で直接やりとりした手入金の情報も入力が可能とする。
【００６８】
図１２（ｂ）の返礼登録画面２００は、主催者が参加者に対して返礼を登録するための画面である。返礼は現金でなく、商品券や品物で返すことが通例である。地域によって異なるが、いただいた金額の半分（半返し）または３分の１の金額に相当する品物を送るのが一般的である。返礼登録画面２００では、図示するように、祝儀、不祝儀をいただいたすべての参加者の情報がイベントごとにリスト形式で表示される。グループ順や金額順等にソートすることもできる。本システムでは、この返礼登録画面２０１から参加者すべてに対する返礼品をまとめて登録することができる。
【００６９】
主催者が、返礼品リストボタン２０１を押すと、贈答品の商品リスト（商品券やお茶、のり、コーヒー等の食料品や生活用品等）が表示され、その中から、例えば「商品券（半返し）」を選択すると、相手先それぞれの返礼品欄にいただいた金額の半額に相当する商品券が一括で入力される。３分の１返しや他の商品を選択しても同様である。一律に同じ品物でなく金額によって品物に差をつけてもよい。例えば、「１万円以上は商品券」、「５，０００円以上はコーヒー」、「３０００円以下はお茶」というように選択することもできる。もちろん、各参加者ごとに２０２のボタンを押すことで、個別に商品を選択することもできる。選択された商品情報は、宅配依頼部１６によって宅配業者システム４０に送られ宅配サービスが実行される。
【００７０】
図９、図１０、図１１では、冠婚葬祭支援システム１のサービス内容を、葬儀と各種パーティのイベントを例にとって説明したが、他のイベントの場合であっても、イベントごとに要求される入力項目が多少異なるだけであるので、本システムは様々なイベントに対応できる。
【００７１】
冠婚葬祭イベントの種類としては、図７のメインメニューで示した結婚，葬儀，法事，各種パーティ以外にも、出産，初節句，七五三，入園・入学，卒業・就職,成人式，結婚記念日，栄転・昇進，新築，引越，定年退職，開店・開業、長寿祝い、病気・けが見舞い,災害見舞い等、じつに様々なものがあるが、利用者にとっては、本システムを利用することにより、これら冠婚葬祭に関する入出金を横断的にすべて管理でき、かつイベントが発生した場合には必要なサービスを受けることができる。特に、同じ利用者が、時にはイベント主催者になったり、時には代表者になったり、参加者になったりするが、本システムにおいては、それぞれの役割にふさわしい管理された情報が提供される。また、本システムは、サービス提供者である銀行等の金融機関も他のサービス提供者との連携が必要となるが、金融機関にとっても利用者が増えれば増えるほど本システムの有用性が高まるので、本サービスを提供することで、ユーザが自然と増えることになり、預金者の獲得にも繋がる。
【００７２】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【００７３】
１０ 冠婚葬祭支援システム中核部
１０Ａ 勘定系ホストコンピュータ
１１，１１Ａ，１１Ｂ 利用者ＤＢ
１２ 振込金一時保管口座ＤＢ
１３ 参加者ＤＢ
１４ 利用者配信ページ作成部
１５ 参加者管理部
１６ 宅配依頼部
１７ サービス依頼情報
１８ 利用者配信ページ
２０ 冠婚葬祭支援システム中核部
３０ 利用者（参加者）端末
３１ 利用者（代表者）端末
３２ 利用者（主催者）端末
４０ 宅配業者システム
５０ 贈答品販売業者システム
６０ 他金融機関システム
７０ ネットワーク
１２０ 葬儀配信メッセージ
１３０ 香典サービス申し込み画面
１４０ 利用履歴画面
１５０ 各種パーティーサービス依頼画面
１６０ 出欠表画面
１７０ 祝儀お届けサービス申し込み画面
１７５ 祝儀お届けメッセージ
１８０ 利用履歴画面
１８５ 祝儀受取確認画面
１９０ 入出金管理画面
２００ 返礼登録画面
【技術分野】
【０００１】
本発明は、冠婚葬祭等の各種イベントを行う主催者、イベントの連絡通知を行う代表者、およびイベントの参加者を支援するシステムおよび支援方法に関する。
【背景技術】
【０００２】
従来から、ネットワークを用いた冠婚葬祭を支援するためのシステムまたは方法が多数知られている。その多くは、冠婚葬祭に関する金品の成就の負担を軽減することや、直接、式典等に参加することができない利用者や、イベントの連絡担当者をサポートすることを目的としている。例えば、特許文献１には、冠婚葬祭の依頼者の端末からイベント情報を入力し、入力されたイベント情報に基づいて冠婚葬祭のドキュメントを作成して利用者に配信し、そのドキョメントを表示させた利用者の端末から祝儀・香典等の金額、利用者の個人情報を入力し、依頼者の端末から謝礼返しを手配する方法が記載されている。
【０００３】
特許文献２には、参加者に対してパスワードを事前に配布し、パスワードを入力することにより式典等のインターネット放送が視聴できるようになり、その視聴画面から電子商取引が可能な画面へ移行し、視聴者が冠婚葬祭等に伴う金銭の支払いができるようにするシステムが記載されている。また、特許文献３には、冠婚葬祭イベントが発生した場合に、当該イベントに関する情報をセキュリティーンゾーンに登録しておいた連絡先に配信できる冠婚葬祭情報配信システムが記載されている。
【０００４】
特許文献１の方法では、冠婚葬祭の依頼者（主催者）がシステムのメニューページで、イベントのすべての情報および告知のために参加候補者の電子メールアドレスを入力する必要があるが、イベントによっては主催者側でこれらの情報をすべて入力することは現実には難しい。特に、イベントが葬儀である場合には緊急性を要するので、主催者である家族等が故人の属していた組織やネットワーク（会社、学校、地域、サークル、友人等）の参加候補の人間を短時間で調べることは困難である。よって、連絡先を入力できない場合は、口コミに頼らざるを得ない。葬儀の場合、主催者は、会社等の組織やグループの連絡先（多くの場合、故人の上司や同僚、組織の総務担当者である）や、たまたま関係のあった知人（以下、まとめて代表者と呼ぶ）に連絡することになるが、連絡を受けた側も、故人のすべての関係者を知っているわけではないし、仮に自分が主催者の代わりに代表者となっても、参加する人間の住所・氏名や、香典の額、謝礼返しの品物や配送先等の個別情報にまでは関知したくないものである。一方、主催者側では、謝礼返しや会場の準備等のため、参加者の必要な情報を知りたいが、事前に参加者全体の情報を得ることは困難である。また、連絡を受けてイベントに参加しようと考える利用者（以下、参加者）にとっては、イベントの種類や規模に関係なく、過去に自分が祝儀や香典等の金品を、誰といくら交わしたかをまとめて知りたいと考える。今回のイベントに対する香典や祝儀等の金額は、いざ通知を受けたその場になってはじめて考えるからである。
【０００５】
特許文献２に記載の方法は、多忙や遠隔等の理由で式典に直接参加できない利用者の冠婚葬祭等に伴う金銭集金を代行するものであり、特許文献３に記載の方法は、企業における代表者が連絡先に迅速に情報発信することを目的とするものであるが、いずれも、関係者を個別にサポートするものであっても、代表者、主催者および参加者のニーズをトータルにサポートするものではない。冠婚葬祭イベントには、結婚，葬儀を始めとして、法事，出産，初節句，七五三，入園・入学，卒業・就職,成人式，結婚記念日，栄転・昇進，新築，引越，定年退職，開店・開業、長寿祝い、病気・けが見舞い,災害見舞い等、様々なものがあり、誰もが多数のイベントの主催者、代表者、参加者になりうることを考えれば、イベントの種類や規模によらず、イベント全体をさまざまな場面で一元的に管理できる仕組みが望まれる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−２５６３１９号公報
【特許文献２】特開２００２−８３０７５号公報
【特許文献３】特開２００１−３１８９９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明では、上記のような課題に鑑み、冠婚葬祭等のイベントの種類、規模によらず、主催者、代表者、参加者それぞれに必要な情報を提供できる冠婚葬祭支援システムおよびその支援方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を達成するため、本発明の冠婚葬祭支援システムでは、以下の機能を備えている。
複数の利用者端末と、管理サーバを含む金融機関システムとがネットワークを介して接続された冠婚葬祭支援システムであって、前記管理サーバは、冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを発信する利用者端末を当該イベントの代表者端末と特定し、前記イベント情報に基づいて利用者配信ページを作成し、前記参加者リストの宛先に配信する利用者配信ページ作成部と、前記利用者配信ページに参加情報を入力した利用者を参加者と特定し、前記参加者からの祝儀または不祝儀金の送金要求情報を受付け、前記参加情報に付加して記録する参加者管理部とを備え、前記イベント情報および前記参加情報の項目ごとに開示レベル属性を付加し、前記開示レベル属性に基づいて、前記イベント情報および前記参加情報の通知先である利用者端末の役割に応じて、通知する情報を制限することを特徴とする冠婚葬祭支援システム。
【０００９】
上記発明によれば、本システムの中核である管理サーバは、代表者端末からのイベント情報に基づいてイベント配信ページを作成して参加者リストに記載された宛先に配信する。配信を通知された利用者は、イベント配信ページに参加情報を入力することによって、参加を申し込むことができるが、直接会場に行くことができない場合にも、祝儀・不祝儀の金銭の送金を参加情報に加えることができる。その際、参加情報には、住所氏名などの個人情報の他、送金金額、送金元の口座情報等、他の参加者や代表者にも知られたくない情報も含まれるため、システムでは項目ごとに開示レベルが付加され、項目ごとに開示先を制限できる。このようにすることにより利用者は安心して参加情報を入力できるし、代表者や主催者にも不必要な情報が開示されることがない。
【００１０】
上記システムは、さらに以下の機能も備えることができる。
前記管理サーバは、前記参加者ＤＢを参照して、前記参加者が金品の宅配を希望する旨の情報を抽出し、当該情報に基づいて宅配依頼データを作成し、宅配業者システムに前記宅配依頼データを送信する宅配依頼部を備える。
【００１１】
上記発明によれば、参加者が主催者に現金の振込みではなく、直接金品を届けたいと望む場合は、その金額または品物を指定し参加情報に加えることによって、主催者に直接届けるための宅配サービスを本システムから依頼することができる。このようにすることで、参加者は、いながらにしてすべての操作を一度で済ますことができる。
【００１２】
上記システムは、さらに以下の機能も備えることができる。
前記宅配依頼部は、当該イベントの主催者である主催者端末から、返礼のための金品の手配要求を受付けて宅配依頼データを作成し、前記宅配業者システムに前記宅配依頼データを送信する。
【００１３】
上記発明によれば、主催者側からイベントに参加者に対して返礼品を送る手配をすることができる。主催者側には、参加者が受け取りを拒否した場合を除いて、参加者の少なくとも住所・氏名・送金額が通知されるので、主催者が返礼を手配する手間が軽減できる。
【００１４】
上記システムにおいては、主催者端末と代表者端末は異なる利用者の端末であってもよい。これは、特にイベントが葬儀または大規模ある場合、主催者が参加候補者のすべての宛先を知ることが困難であるため、主催者とは別の代表者を立てることにより、主催者と代表者の役割を分担するようにするためである。つまり、イベントの決定とイベント情報の詳細は主催者が、イベントの概略情報と通知先は、例えば会社の代表者が、というように、それぞれのシステムへの入力負担を軽減することができる。この場合、代表者は、主催者と親しい間柄である必要はなく、会社の総務担当者のように単に事務的に通知のみを扱う人間でもよい。
【００１５】
上記システムは、さらに以下の機能も備えることができる。
前記管理サーバは、複数の代表者端末からそれぞれ別々に入力されたイベント情報を解析し、同一のイベントであると判定した場合は、当該イベント情報をマージしてひとつのイベントとして管理する。
【００１６】
上記発明によれば、大きな会社等で代表者が複数いるような場合（例えば、複数の部署に故人が在籍していたような場合）で、主催者がお互いの代表者間の関係を知らないような場合でも、別個に入力されたイベント情報の内容をシステムが解析し、同じイベントであると判断したときは、以後ひとつのイベントとして管理できる。このようにすることで、重複入力や、同じイベント情報が別のルートから複数流れるのを防止できる。
【００１７】
上記システムは、さらに以下の機能も備えることができる。
前記管理サーバは、前記利用者端末からの要求に基づいて、当該利用者のイベントに関する利用履歴を前記利用者端末に表示させる。
【００１８】
上記発明によれば、本システムの利用者は、過去に金品をやり取りした冠婚葬祭すべての情報が横断的に一覧できるので、例えば、イベントの参加依頼通知を受けた際に、過去の履歴を表示して、同一の相手先とのやりとりがあれば、今回のイベントの祝儀、不祝儀の金額を決める際の参考になる。また、冠婚葬祭の年間の支出額の管理等にも役立つ。
【００１９】
また、本発明は、別の態様として、以下のような冠婚葬祭支援方法としても捉えることもできる。
複数の利用者端末と、管理サーバを含む金融機関システムとがネットワークを介して接続されたシステムにおける冠婚葬祭支援方法であって、前記管理サーバが、冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを発信する利用者端末を当該イベントの代表者端末と特定し、前記イベント情報に基づいて利用者配信ページを作成し、前記参加者リストの宛先に配信する段階と、前記利用者配信ページに参加情報を入力した利用者を参加者と特定し、前記参加情報を記録する段階とを含み、前記イベント情報および前記参加情報の項目ごとに開示レベル属性を付加し、前記開示レベル属性に基づいて、前記イベント情報および前記参加情報の通知先である利用者端末の役割に応じて、通知する情報を制限する段階を含むことを特徴とする冠婚葬祭支援方法。
【発明の効果】
【００２０】
本発明によれば、冠婚葬祭等のイベントの種類、規模によらず、主催者、代表者、参加者それぞれに必要な情報ニーズを満たすような仕組みを提供することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態に係る冠婚葬祭支援システム１全体の概略を示す図である。
【図２】本発明の実施形態に係る冠婚葬祭支援システム中核部１０の機能構成を示す図である。
【図３】本発明の実施形態に係る利用者管理テーブルおよび参加者管理テーブルを示す図である。
【図４】本発明の実施形態に係る利用者配信ページ作成部１４の処理手順を示すフロー図である。
【図５】本発明の実施形態に係る参加者管理部１５の処理手順を示すフロー図である。
【図６】本発明の実施形態に係る宅配依頼部１６の処理手順を示すフロー図である。
【図７】本発明の実施形態に係る冠婚葬祭サービスメイン画面と、葬儀サービス依頼画面を示す図である。
【図８】本発明の実施形態に係る葬儀サービスを選んで入力完了後に利用者に通知される画面を示す図である。
【図９】本発明の実施形態に係る各種パーティサービス依頼画面を示す図である。
【図１０】本発明の実施形態に係るご祝儀お届けサービス申し込み画面を示す図である。
【図１１】本発明の実施形態に係るご祝儀受取画面を示す図である。
【図１２】本発明の実施形態に係る入出金管理画面および返礼登録画面を示す図である。
【発明を実施するための形態】
【００２２】
以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。
【００２３】
図１は、本発明の実施形態に係る冠婚葬祭支援システム１全体の概略を示す図である。本システムでは、冠婚葬祭支援システム中核部１０（または単に、システム中核部）と、銀行等の勘定系ホストコンピュータ１０Ａが接続される。両者を合わせて、広い意味で冠婚葬祭支援システム中核部２０と呼ぶことがある。
【００２４】
システム中核部１０は、ネットワーク７０を介して、利用者端末３０，３１，３２が接続され、また、宅配業者システム４０，贈答品販売業者システム５０，他金融機関システム６０とも接続されている。「利用者端末」とは、本システムが提供するサービスの利用者（ユーザ）の端末を示すが、すべての利用者は、イベントによって、代表者にも、参加者にも、主催者にもなりうるので、それぞれの役割を持った利用者の端末を他の端末と区別するときは、参加者端末３０、代表者端末３１、主催者端末３２と表すものとする。特に区別する必要がない場合は、単に利用者端末と呼ぶことにする。利用者端末は、ネットワークに接続できる一般的なＰＣ（Personal Computer）や携帯電話をはじめとする各種の移動情報端末であってよいいが、各利用者端末は、必ずしも利用者側が所有する端末でなくとも、利用者の依頼に基づきデータを入力するサービス提供者側の端末であってもよい。
【００２５】
図２は、本発明の実施形態に係る冠婚葬祭支援システム中核部１０の機能構成を示す図である。システム中核部１０は、本システムの管理サーバとして機能するコンピュータであり、主な機能部として、利用者配信ページ作成部１４，参加者管理部１５，宅配依頼部１６で構成され、関連するデータベース（ＤＢ：Data Base）として、利用者ＤＢ１１，参加者ＤＢ１３，振込金一時保管口座ＤＢ１２が存在する。ただし、振込金一時保管口座ＤＢ１２は、ホストコンピュータ１０Ａに存在してよい。図では、利用者ＤＢは便宜上参加者側のＤＢと主催者側のＤＢに分けて示しているが、実際は同じＤＢであってよく、特に両者に実装上の区別はない。
【００２６】
上記の機能構成は、あくまで一例であり、一つの機能部を更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。各機能部は、典型的には、メモリ（ＲＡＭ：Random Access Memory,ＲＯＭ：Read Only Memory）や記憶装置に格納されたコンピュータ・プログラムが読み出され、装置に内蔵されたＣＰＵ（Central Processing Unit）で実行され、実行されたプログラムが記憶装置に格納されたＤＢから必要なデータを読み書きし、場合によっては、その他関連するハードウェア（例えば、入出力装置や通信インターフェース装置）を制御することによって実現される。以下、個々の機能部の働きと、関連するデータについて説明する。
【００２７】
システム中核部１０の各機能部は、様々な入力画面を利用者端末に表示させるが、イベントごとに、各サービス要求画面に利用者が入力した段階でユーザＩＤとその役割の関連付けをするので、ユーザＩＤとイベントＩＤによって、システムは、端末の役割を検知することができる。すなわち、あるイベントでは参加者であったユーザが別のイベントでは主催者となったりする。そのため、本システムが提供する各画面には、イベントごとに主催者用，代表者用，参加者用，その他一般利用者用に分けられ、それぞれの識別子が付加されている。
【００２８】
利用者配信ページ作成部１４は、代表者端末３１からサービス依頼情報１７の入力を受け、イベント情報を作成し、サービス依頼情報１７に含まれるイベントの参加者候補となる利用者の配信先（電子メールアドレスまたは専用ＵＲＬ）にイベント情報を配信する。イベント情報は、電子メールの本文またはイベント情報が記載したＷｅｂページ、あるいはその両方であってもよい。
【００２９】
サービス依頼情報１７は、代表者端末３１からでなくとも、主催者端末３２から入力してもよいが、イベントの規模によっては、主催者よりもその組織やグループの代表者のほうが配信先の情報を得やすいので、本システムでは、イベント情報の最初の入力端末を代表者端末３１としている。ただし、イベント情報の更新は、主催者端末３２からでも可能である。このように代表者と主催者の役割を分けることにより、それぞれの入力負担を軽減する。もちろん、主催者が代表者を兼ねることも可能である。結婚式や親近者だけのパーティ等、主催者側で参加者（招待者）をすべてを把握できる場合は、代表者を立てることなく主催者側ですべての入力を行うことができるので、この場合は、代表者端末３１イコール主催者端末３２となる。
【００３０】
代表者が配信先（あるいは参加者リスト）、イベント情報を入力完了すると、利用者配信ページ１８が作成さえる。配信された利用者は、このページを参照してイベントに参加を申し込む。利用者が参加申し込みをした利用者配信ページ１８の内容（参加情報）は、後で詳しく説明するが、入力項目ごとに開示先を限定する開示レベルの属性をもち情報の開示先が項目ごとに管理される。例えば、利用者者配信ページ１８の内容中、参加者の必要な項目だけが主催者端末３２に通知されるようにする。主催者も、後に返礼をするためだけの情報を知ることができればよいからである。参加情報は、特段の指定がない限り、代表者端末３１や他の参加者端末３０からは参照できないようにする。代表者にとっても、個々の参加者の個人情報等までは知る必要がないし、参加者同士でも互いに個人情報を知る必要はないからである。なお、本システムの利用者は、自己の出金情報または入金情報の履歴の詳細は、役割を問わず、すべて参照することができる。冠婚葬祭に関する金銭等の入出金履歴は、本システムを介してやり取りする限り、すべてが利用者毎に自動的に利用者ＤＢ１１に記録される。
【００３１】
代表者端末３１は複数であってもよく、組織やグループごとに存在してよい。主催者は、代表者の連絡先だけを把握し、その代表者にイベントの情報を連絡可能とする。また、代表者が他の代表者となりうる者を知っている場合は、代表者から直接その他の代表者になりうる者に連絡し、代表者となってもらうこともできる。なお、代表者となった者は、代表者端末３１から、イベントの情報を主催者から受けてシステムにイベント情報として入力し、参加候補者の連絡先の情報を入力するが、自分自身は必ずしもイベントに参加するとは限らないので、参加者となっても、ならなくともよい。参加者となる場合は、代表者端末３１は、参加者端末３０を兼ねる。
【００３２】
参加者管理部１５は、利用者配信ページ作成部１４がイベント情報を配信した利用者の中から実際に参加意思表示をした利用者を以後「参加者」として抽出し、管理するためその参加情報を参加者ＤＢ１３に登録する機能を備える。利用者は、利用者配信ページ１８に自己の必要な情報を入力することによって参加者として認識される。もちろん、イベント開始前であれば、取り消しも可である。
【００３３】
振込金一時保管口座１２は、参加意思表示した利用者から、祝儀や香典等の金銭の送金をする場合に銀行内に一時的にそのお金を保管しておく口座である。利用者からの送金を一時的に保管しておく仕組みは、別段預金口座として銀行のシステムにすでに存在するのでこれを利用してもよい。参加者管理部１５は、この振込金一時保管口座１２から参加情報に付加された振込情報（送金情報）を取り出し、宅配依頼部１６に通知する。
【００３４】
宅配依頼部１６は、宅配業者システム４０と接続され、参加者ＤＢ１３に格納された参加情報を参照し、参加者からシステムの管理する振込金一時保管口座１２へ入金があったときに、主催者に直接祝儀等を現金または品物で届けるサービスを受付ける機能を備えている。現在、一般の宅配業者の約款では現金は宅配できないので、その場合は振り込まれた金額に相当する品物を贈ることになるが、銀行と郵便局が提携して依頼者の指定口座から依頼された金額を引き落とし、現金書留で郵送できる現金宅配サービスが既に始まっており、本システムと連携することで、現金を送ることも可能となる。
【００３５】
本サービスの主催者、代表者、参加者となるためには、本システムに登録してユーザＩＤの発行を受ける必要があるが、ユーザＩＤの発行を受けるためには、氏名、パスワード、メールアドレス程度の入力だけでよく、その後の個人情報や口座情報等は、必要な際に入力を求められるようにすることが望ましい。ユーザ数が広がれば広がるほど本システムの有用性が高まるので、イベント通知の際の画面等にユーザ登録を手軽に行えるボタンを配置しておくようにする。
【００３６】
図３は、本発明の実施形態に係る利用者管理テーブルおよび参加者管理テーブルを示す図である。利用者管理テーブルは、利用者ＤＢ１１に格納され、本システムに登録されたユーザ情報全体を管理するテーブルである。利用者テーブルには、図３（ａ）で示すように、ユーザＩＤ，氏名・住所・電話番号，メールアドレス，パスワードの他、入出金のための銀行口座番号や、必要であれば、クレジットカード情報等が含まれる。
【００３７】
テープル内の個人情報は項目ごとに「開示レベル」が定義され、利用者本人以外に開示できる範囲が限定される。例えば、開示レベル１の情報は全ユーザまたはユーザ許可した範囲のユーザに開示され、開示レベル２の情報は代表者または主催者に開示され、開示レベル３の情報は主催者のみに開示され、開示レベル４では利用者本人にしか開示されないように定義する。図の例では、開示レベル１は、メールアドレス（ユーザＩＤも含む）、開示レベル２は氏名・住所・電話番号、開示レベル３は口座番号、開示レベル４はパスワードに項目の属性として付加されている。項目ごとの開示レベルは、イベントの種類に応じてシステムがデフォルトを設定するが、利用者も変更できるものとする。もちろん、開示レベルの定義は、利用者ごとにカスタマイズできる。
【００３８】
利用者管理テーブルには、上記個人情報の他、個別の利用履歴として、利用年月日，利用サービスの種類，取引ＩＤ，取引相手の氏名とユーザＩＤ，取引金額，取引方法，本システムにおける自分および相手先の役割等、イベントにおけるすべてのやりとりが記録される。取引相手とは、祝儀や不祝儀の金品を取り交わした相手である。金額だけでなく贈答品名等も記録されてよい。システムでは把握できない手渡しでのやりとりも利用者自身が入力することで利用履歴に追加することができる。利用履歴は、利用者本人であればいつでも閲覧できるが、特に金銭を振込む画面からワンタッチで参照できるようにすることが望ましい。振込み時に過去の履歴を参照することが多いからである。
【００３９】
図３（ｂ）には、利用者配信ページ１８でイベントに参加申し込みをした利用者の情報（参加情報）が記録される。例えば、イベントＩＤ，利用サービスの種類，代表者ユーザＩＤ，主催者ユーザＩＤ等である。また参加情報（図では、＜参加者リスト＞形式で表示されている）には、個々の取引毎にその金銭のやりとりの詳細情報が記録されている。この参加情報の各項目にも開示レベルが定義される。主催者は一部を除き、ほとんどの項目が参照できるが、代表者や参加者は、参加者の氏名またはユーザＩＤまたは参加者の人数程度が開示されるが、それ以外は開示されないように開示レベルを設定して不要な情報のやりとりを防ぐ。
【００４０】
図４は、本発明の実施形態に係る利用者配信ページ作成部１４の処理手順を示すフロー図である。利用者配信ページ作成部１４は、まずステップＳ１０において、利用者端末からサービス開始要求を待つ。サービス開始要求があれば、要求されたサービスの種類によってその入力画面を送信する（ステップＳ１１）。つぎに、ステップＳ１２において、入力データが、イベント毎に定義された必要最小限の項目を満たしているかどうかチェックし、満たしていなければ修正を要求する。入力データのチェックがすべてＯＫであれば、ステップＳ１３に移り、入力された情報を基に、利用者（参加候補者）への通知メールを作成する。通知メールは、イベントにより雛形がいくつか用意されていることが望ましい。なお、このとき、利用者配信ページ作成部１４は、サービス開始要求を送信した端末（ユーザＩＤ）を代表者端末３１と認識する。
【００４１】
次に、利用者配信ページ作成部１４は、ステップＳ１４において、利用者（参加候補者）に対する利用者配信ページ１８を作成し、ステップＳ１５において、先に通知メールに、サービス申し込みページへのリンクを付加する。サービス内容あるいはイベントによって追加ページが必要な場合はそのリンク先を追加する（ステップＳ１６）。例えば、会場の場所や電話番号、アクセスが記載されたページへのリンクを追加する。最後に通知メールを入力された参加者リストの宛先に送信する（ステップＳ１７）。なお、通知メールは、電子メールで送信する他、企業によっては訃報通知専用ページ等があるので、その場合は、その専用ページからリンクされるようにしてもらい、そのＵＲＬを宛先としてもよい。
【００４２】
通知メールを受け取った利用者は、通知メールにリンクされたサービス申し込みページを開き、参加すべきイベントと判断した場合は、参加申し込み欄等をクリックする。祝儀・香典等を送金する場合は、その支払い方法（銀行振込、クレジットカード払い）や宅配サービス（後述）を指定することができる。もちろん、参加者は会場に出向き直接祝儀等を手渡してもかまわないが、その場合は、手渡しの欄をクリックするしてもらうと、参加者の人数把握に役立つ。参加者が入力した情報は参加情報として、イベントごとに管理され、利用者ＤＢ１１および参加者ＤＢ１３に保存される。なお、通知メールを受け取った利用者が、本システムのユーザでない場合は、通知画面から直ぐにユーザ登録できるようにしておくことが望ましい。ユーザ登録せずとも参加申し込みクリックはできるが、自動送金や宅配サービスを利用することはできない。
【００４３】
図５は、本発明の実施形態に係る参加者管理部１５の処理手順を示すフロー図である。参加者管理部１５は、利用者配信ページ１８から参加申し込みをした利用者を以後、参加者として扱い、イベントごとに管理する機能を持つ。
【００４４】
まず、参加者管理部１５は、ステップＳ２０において、現在時刻がサービス終了時間に達してないかチェックし、サービス終了時間に達していれば処理を終了する。サービス終了時間とは、イベントごとにあらかじめ定められたサービス受付け可能な時間である。例えば、イベント開始１時間前とかイベント終了後数日後までとかに設定される。サービス終了時間は、イベントの種類に応じてシステムによってデフォルトが設定されるが、主催者または代表者が設定することもできる。
【００４５】
サービス時間中であれば、参加者管理部１５は、ステップＳ２１において、利用者配信ページを常時参照して、参加申し込みを待つ。参加申し込みがあり、さらに自動送金の要求がある場合は（ステップＳ２２；Ｙｅｓ）、入金方法によって処理を以下のように分ける。本サービスを行っている銀行からの送金の場合は、振込依頼画面を送信して入金を依頼する（ステップＳ２３）。このとき振込先は、主催者が許可すれば主催者の銀行口座でもよいが、銀行が本サービス専用に用意した別段預金口座にしてもよい。参加者から振り込まれた入金はこの別段預金口座に一時的に保管され、その後、主催者の口座に振り込まれる。こうすることで主催者は、口座番号を参加者に知らせずとも入金を受けることができる。また、入金を他行からの振込で行う場合は、他行決済待ち処理を行う（ステップＳ２４）。クレジットカード決済の場合は、クレジットカード決済画面を送信し、決済を待つ（ステップＳ２５）。これら入金処理手順の詳細については広く行われていることであるので説明は省略する。
【００４６】
参加者管理部１５は、ステップＳ２６においてすべての入力データがＯＫであること、ステップＳ２７において決済が完了していることをチェック後、取引データを参加者ＤＢ１３に記録する（ステップＳ２８）。ただし、他行からの振込みのように決済に時間がかかる場合は、中間状況をいったん記録するようにする。なお、自動送金を参加者が利用してない場合でもそれ以外のデータは記録される。
【００４７】
図６は、本発明の実施形態に係る宅配依頼部１６の処理手順を示すフロー図である。宅配依頼部１６は、参加者の希望に応じて金銭や品物を主催者に届けるサービスを手配する機能をもつ。宅配依頼部１６は、祝儀等の金銭を主催者の口座へ振込むだけでは失礼と考える参加者、および香典返しなどお返しをする際に金品を参加者に届ける負担を減少させたい主催者のニーズを満たすため宅配業者システムと連動する機能を備えている。
【００４８】
まず宅配依頼部１６は、ステップＳ３０において、現在時刻が、申し込みページ（利用者配信ページ）閉鎖時刻になるまで待機する。申し込みページ閉鎖時刻は、図５のサービス終了時間と同じとしてよいが、宅配業者の都合も考慮して決められる。
【００４９】
次に宅配依頼部１６は、ステップＳ３１において、参加者ＤＢ１３を検索し、宅配希望の要求があるにもかかわらず未完のデータがあるかどうかをチェックする。例えば、他行からの振込が所定期間経過しても完了しないような場合である。未完データがあれば、未完データの参加者にその旨の通知メールを送信する（ステップＳ３２）。同時に担当者から電話連絡をさせるようにしてもよい。
【００５０】
その後、宅配依頼部１６は、参加者ＤＢ１３をいったんクローズする（ステップＳ３３）。そして、参加者ＤＢ１３から宅配に必要な情報（送り主、送り先、送金額または品名・商品番号、および、お届け希望日時等）を取り出し、宅配データ（宅配依頼データ）を作成する（ステップＳ３４）。これらの処理を宅配要求を持つ参加者がなくなるまで繰り返す（ステップＳ３５）。
【００５１】
そして宅配依頼部１６は、すべての参加者の宅配データをまとめて、宅配業者システム４０へ送信（ステップＳ３６）し、宅配受付完了通知を受信するまで待機する（ステップＳ３７）。宅配業者システム４０から、宅配受付完了通知を受信すると、参加者にたいして宅配の受付の完了通知を送信する（ステップＳ３８）。上記処理手順では、冠婚葬祭イベントの開催期間は通常短期間であるため処理効率をあげるためにイベントごとに閉鎖時間を定めて、閉鎖時間後にまとめて宅配データを宅配業者システム４０に送信しているが、宅配サービス要求が発生するたびに、宅配データを作成し、送信すようにしてもよい。
【００５２】
図７は、本発明の実施形態に係る冠婚葬祭サービスメイン画面と、葬儀サービス依頼画面を示す図である。イベントが発生して本システムでサービス開始を依頼しようとする利用者（主催者または代表者）は、まず、この冠婚葬祭サービスメイン画面１００でサービス名を選択してログインする。もちろん、ログインが完了してからメインメニューを表示してもよい。メインメニューには、本システムが提供するサービスのメニューが表示される。メニューには、例として、結婚式・披露宴１０１，葬儀１０２，各種お祝い１０３，法事１０４，各種パーティ１０５等イベント発生時にサービス依頼を行うものの他、入手金管理１０７のようにいつでもサービスを受けられるもの、お返し手配１０８のように、イベント終了後でも受付けられるサービスがある。特に図示していないが、他にも様々な冠婚葬祭の種類があるので、それらのメニューを個別に用意されてよい。なお、入手金管理１０７，お返し手配１０８については、各サービスの中からでも依頼できる。また、はじめての利用者は、ユーザ登録１０９を押すことによって本システムにユーザ登録する。
【００５３】
ここでは、一例として、利用者が葬儀１０２を選択した場合の葬儀サービス依頼画面１１０を図７の右側に示す。この画面では、葬儀イベント情報を登録するための各種入力項目が表示される。各入力項目には前述したような開示レベルが属性として付加されている。葬儀の場合、この画面で入力するのは、多くの場合主催者でなく組織やグループの代表者である。主催者側で組織内の故人にゆかりのあるメンバーを知ることは容易ではないからである。主催者から連絡を受けた代表者は、まずこの画面で組織等の属性（会社，学校・同窓会，友人，町内会等）を入力領域１１１で選択する。この例では「会社」を選択したものとする。代表者は、その後、自分の氏名、会社名、部署、住所等の代表者側の情報１１２および主催者側の情報１１３を入力するが、同じ葬儀ですでに代表者になっている利用者があれば、その情報も表示するようにする。すでに代表者になっている利用者がいれば、主催者情報などの重複入力が避けられ、同じ会社で別の代表者がいれば、配信先の入力などをグループごとに分担できるからである。
【００５４】
代表者は、葬儀に参加する可能性のある参加候補者を、従業員リストあるいは部署内リストをもとに入力領域１１４に参加候補者情報（参加者リスト）として入力する。ここで最低限必要な入力項目としては、メールアドレス、氏名，所属部署程度でよく、すべての項目を埋める必要はない。代表者として過去に参加者候補情報を入力したことがある場合は、それが初期画面に表示されるので必要な箇所を追加修正するだけでよい。また、参加候補者の宛先は、個々に入力してもよいが、多人数になる場合が多いので、ＣＳＶ（Comma Separated Values）ファイルや表形式ファイルなどで受付けられるようにすることが望ましい。また、社内のイントラネット等に訃報を知らせるための専用ページがあれば、そのＵＲＬを参加者のリストの代わりとしてもよい。
【００５５】
最後に、代表者は、入力領域１１５において、参加候補者に通知するメッセージを入力する。通知文の雛形はシステムからイベントに応じて数種が提供されるので、必要な箇所のみを修正すればよい。代表者は、以上のデータを入力し終わったら、送信ボタンを押してイベント登録を終了する。以後は、代表者としては特になにもする必要はない。システムは、主催者情報が一致する（完全一致でなくとも日時、場所、主催者が同じであればよい）イベントがあればそれをマージし、各代表者や主催者にその旨を通知してもよい。
【００５６】
図８は、本発明の実施形態に係る葬儀サービスを選んで入力完了後に利用者に通知される画面を示す図である。前図において、葬儀サービス依頼画面から、必要な情報を入力完了すると、図８に示すように、通知メール１２０、香典お届けサービス申し込み画面１３０が作成され、参加候補者のもとに通知される。
【００５７】
通知メール１２０を受け取った参加候補者は、通夜・葬儀の場所等を確認し、直接参列することはできないが香典を振り込みたいという場合には、「お香典お届けサービス」をクリックすることにより、お香典お届けサービス申し込み画面１３０を表示させる。参加者は、この画面から必要な個人情報を入力して、支払い方法などを選択する。さらに主催者に送るメッセージ１３３を記入することができる。個々の入力項目には、開示レベルの属性が付加されていることはいうまでもない。
【００５８】
支払い方法は、参加者が本システムを提供する銀行に口座を持っていれば、香典の金額を自分の口座から本サービス専用に設けられた銀行の別段預金口座に振り込む（後で主催者の口座に自動的に振り込まれる）ことができる。もちろん、他行からの振込みや、クレジットカードによる支払い受付も可能である。また、葬儀に直接参列する参加者も香典だけをこのシステムで振込むことが可能である。その場合、葬儀会場の受付ではその旨を申したてる。参列者にとっては、現金をのし袋に入れる手間が省け、主催者側でも葬儀の受付担当者が多額の現金を取り扱うリスクが現象するので、双方にとって有益である。
【００５９】
画面１３０において、参加者が振込む香典の金額を決める際に、利用履歴ボタン１３１を押すことによって過去の冠婚葬祭に関する自己の入出金履歴を容易に調べることができる。図８の右端の利用履歴画面１４０はこの表示例である。利用履歴は、利用者ＤＢ１１に格納された本システムを介してやりとりされた過去のすべての記録が表示できる。表示の形式は、やりとりの相手順、日付順、金額順の他、イベント別、役割別等、利用者が選択した任意の方法でソートして表示できる。なお、特に図示していないが、本システムを介さないで利用者どうしが直接やりとりしたデータもこの画面または別の入力画面から利用者が直接入力できるものとする。これらのデータも手入力であること識別情報を付加され、利用者ＤＢ１１に保存される。また、画面１３０に主催者に送るメッセージ入力欄１３３を追加してもよい。さらに文例ボタン１３４を設け、メッセージの例文を表示させてもよい。
【００６０】
図９は、本発明の実施形態に係る各種パーティサービス依頼画面を示す図である。パーティのイベントでは、葬儀と異なり、通常、主催者が参加者（招待者）を決めることが容易である。以下の例では、小規模のパーティを前提にしているが、参加者が特定できないような大規模パーティの場合は、葬儀の場合と同様に、複数の代表者が主催者に代わりイベント情報を入力することで対処できる。
【００６１】
図には、各種パーティサービス依頼画面１５０を示す。既に述べたように、本システムでは、イベント情報をサービス依頼画面で入力する利用者のユーザＩＤをそのイベントの代表者と認識する。この例では、パーティが比較的小規模で、主催者自らが代表者となってイベント情報を入力する場面を示している。代表者情報１５１、参加者リスト１５３の入力する項目については、前述の葬儀の例とほぼ同じであるが、主催者情報１５２は、代表者と同じであれば入力する必要はない。代表者は複数であってもよい。すなわち、ある利用者が入力したイベント情報を別の利用者が別途入力するとシステムにより同一性が検知された段階で両イベントはマージされて同じイベントＩＤが付加される。また、後で入力した利用者も共に代表者となる。
【００６２】
なお、本システムを利用して金品を送る相手が、主催者と異なる場合には、送付先の情報を別途入力する必要がある。図の例のように、代表者・主催者が別の人間のお祝いを開催するような場合である。ただし、このとき、送付先相手に対して、通常の主催者と異なる開示レベルを定義するようにしてもよい。例えば、開示レベル９を定義した送付先には、システムからの通知をいっさい送信せず、代表者に代わりに送付するといった工夫ができる。
【００６３】
また、図の下段に示される通知文は、用意された雛形を修正して作成する点は前図と同じであるが、雛形には、「祝儀お届けサービス」へのリンク１５５だけでなく、この例のように、出欠表１５０をリンクさせてもよい。通知文からリンクされた出欠表にメッセージ入力欄を表示してもよい。出欠表に入力した情報は、通常、まとめて代表者（主催者）に開示されるので、出欠者の管理に役立てることができる。なお、出欠表１６０を受け取った利用者が本システムのユーザでない場合を想定し、この出欠表からも直接ユーザ登録できるようにユーザ登録ボタン１６９を配置するとよい。
【００６４】
図１０は、本発明の実施形態に係るご祝儀お届けサービス申し込み画面を示す図である。基本的には、図８中央のお香典お届けサービスの画面と同じであるが、香典とは異なり、現金以外にも商品券や品物を宅配で送るサービスが追加される。品物を送る場合は、贈答品専門オンラインショップへのリンクボタン１７３が貼られているので、そこから通常のオンラインショップの画面に移行してもよい。ただし、その場合であっても、贈答品販売業者システム５０から購入情報を受信して、利用者ＤＢ１１にその取引記録を残すことができる。
【００６５】
また、図１０の右の利用履歴画面１８０で示すように、本イベントの利用履歴では、入出金方法として、現金のやりとりではなく贈答品の品名とその商品情報ページ１８２へのリンクを表示するようにしてもよい。こうすることで、贈答品販売業者にとっても商品の露出機会を増やすことになるので本システムとの連携にメリットを感じる。
【００６６】
図１１は、本発明の実施形態に係るご祝儀受取画面を示す図である。図示するうに、祝儀の受領者には、祝儀お届けメッセージ１７５が電子メール等で届けられる。祝儀お届けメッセージ１７５からは、リンクされた祝儀受取確認画面１８５を直接開くことができ、祝儀の内容（振込人、祝儀金額、メッセージ等）、および祝儀が振り込まれたことを確認することができる。
【００６７】
図１２は、本発明の実施形態に係る入出金管理画面および返礼登録画面を示す図である。図１２（ａ）の入出金管理画面１９０には、利用者ＤＢ１１に記録された冠婚葬祭に関するイベントにおけるすべての記録が表示される。前述したように、各サービスの申し込み画面からも利用履歴画面は表示できるが、本画面からは、図示していないが、利用者間で直接やりとりした手入金の情報も入力が可能とする。
【００６８】
図１２（ｂ）の返礼登録画面２００は、主催者が参加者に対して返礼を登録するための画面である。返礼は現金でなく、商品券や品物で返すことが通例である。地域によって異なるが、いただいた金額の半分（半返し）または３分の１の金額に相当する品物を送るのが一般的である。返礼登録画面２００では、図示するように、祝儀、不祝儀をいただいたすべての参加者の情報がイベントごとにリスト形式で表示される。グループ順や金額順等にソートすることもできる。本システムでは、この返礼登録画面２０１から参加者すべてに対する返礼品をまとめて登録することができる。
【００６９】
主催者が、返礼品リストボタン２０１を押すと、贈答品の商品リスト（商品券やお茶、のり、コーヒー等の食料品や生活用品等）が表示され、その中から、例えば「商品券（半返し）」を選択すると、相手先それぞれの返礼品欄にいただいた金額の半額に相当する商品券が一括で入力される。３分の１返しや他の商品を選択しても同様である。一律に同じ品物でなく金額によって品物に差をつけてもよい。例えば、「１万円以上は商品券」、「５，０００円以上はコーヒー」、「３０００円以下はお茶」というように選択することもできる。もちろん、各参加者ごとに２０２のボタンを押すことで、個別に商品を選択することもできる。選択された商品情報は、宅配依頼部１６によって宅配業者システム４０に送られ宅配サービスが実行される。
【００７０】
図９、図１０、図１１では、冠婚葬祭支援システム１のサービス内容を、葬儀と各種パーティのイベントを例にとって説明したが、他のイベントの場合であっても、イベントごとに要求される入力項目が多少異なるだけであるので、本システムは様々なイベントに対応できる。
【００７１】
冠婚葬祭イベントの種類としては、図７のメインメニューで示した結婚，葬儀，法事，各種パーティ以外にも、出産，初節句，七五三，入園・入学，卒業・就職,成人式，結婚記念日，栄転・昇進，新築，引越，定年退職，開店・開業、長寿祝い、病気・けが見舞い,災害見舞い等、じつに様々なものがあるが、利用者にとっては、本システムを利用することにより、これら冠婚葬祭に関する入出金を横断的にすべて管理でき、かつイベントが発生した場合には必要なサービスを受けることができる。特に、同じ利用者が、時にはイベント主催者になったり、時には代表者になったり、参加者になったりするが、本システムにおいては、それぞれの役割にふさわしい管理された情報が提供される。また、本システムは、サービス提供者である銀行等の金融機関も他のサービス提供者との連携が必要となるが、金融機関にとっても利用者が増えれば増えるほど本システムの有用性が高まるので、本サービスを提供することで、ユーザが自然と増えることになり、預金者の獲得にも繋がる。
【００７２】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【００７３】
１０ 冠婚葬祭支援システム中核部
１０Ａ 勘定系ホストコンピュータ
１１，１１Ａ，１１Ｂ 利用者ＤＢ
１２ 振込金一時保管口座ＤＢ
１３ 参加者ＤＢ
１４ 利用者配信ページ作成部
１５ 参加者管理部
１６ 宅配依頼部
１７ サービス依頼情報
１８ 利用者配信ページ
２０ 冠婚葬祭支援システム中核部
３０ 利用者（参加者）端末
３１ 利用者（代表者）端末
３２ 利用者（主催者）端末
４０ 宅配業者システム
５０ 贈答品販売業者システム
６０ 他金融機関システム
７０ ネットワーク
１２０ 葬儀配信メッセージ
１３０ 香典サービス申し込み画面
１４０ 利用履歴画面
１５０ 各種パーティーサービス依頼画面
１６０ 出欠表画面
１７０ 祝儀お届けサービス申し込み画面
１７５ 祝儀お届けメッセージ
１８０ 利用履歴画面
１８５ 祝儀受取確認画面
１９０ 入出金管理画面
２００ 返礼登録画面
【特許請求の範囲】
【請求項１】
複数の利用者端末と、管理サーバを含む金融機関システムとがネットワークを介して接続された冠婚葬祭支援システムであって、
前記管理サーバは、
冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを発信した利用者端末を当該イベントの代表者端末と特定し、前記イベント情報に基づいて利用者配信ページを作成し、前記参加者リストの宛先に配信する利用者配信ページ作成部と、
前記利用者配信ページに参加情報を入力した利用者を参加者と特定し、前記参加者からの祝儀または不祝儀金の送金要求情報を受付け、前記参加情報に付加して記録する参加者管理部とを備え、
前記参加情報の項目ごとに開示レベル属性を付加し、前記開示レベル属性に基づいて、前記参加情報の通知先である利用者端末の役割に応じて、通知する情報を制限することを特徴とする冠婚葬祭支援システム。
【請求項２】
前記管理サーバは、記録された前記参加情報を参照して、前記参加者が金品の宅配を希望する旨の情報を抽出し、当該情報に基づいて宅配依頼データを作成し、宅配業者システムに前記宅配依頼データを送信する宅配依頼部を備えた、請求項1に記載の冠婚葬祭支援システム。
【請求項３】
前記宅配依頼部は、当該イベントの主催者である主催者端末から、返礼のための金品の手配要求を受付けて宅配依頼データを作成し、前記宅配業者システムに前記宅配依頼データを送信する、請求項２に記載の冠婚葬祭支援システム。
【請求項４】
前記主催者端末と前記代表者端末は異なる利用者の端末であることを特徴とする、請求項３に記載の冠婚葬祭支援システム。
【請求項５】
前記管理サーバは、複数の代表者端末からそれぞれ別々に入力されたイベント情報を解析し、同一のイベントであると判定した場合は、当該イベント情報をマージしてひとつのイベントとして管理する、請求項1乃至４に記載の冠婚葬祭支援システム。
【請求項６】
前記管理サーバは、前記利用者端末からの要求に基づいて、当該利用者のイベントに関する利用履歴を前記利用者端末に表示させる、請求項1乃至５に記載の冠婚葬祭支援システム。
【請求項７】
複数の利用者端末と、管理サーバを含む金融機関システムとがネットワークを介して接続されたシステムにおける冠婚葬祭支援方法であって、
前記管理サーバが、
冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを発信する利用者端末を当該イベントの代表者端末と特定し、前記イベント情報に基づいて利用者配信ページを作成し、前記参加者リストの宛先に配信する段階と、
前記利用者配信ページに参加情報を入力した利用者を参加者と特定し、前記参加者からの祝儀または不祝儀金の送金要求情報を受付け、前記参加情報に付加して記録する段階とを含み、
前記参加情報の項目ごとに開示レベル属性を付加し、前記開示レベル属性に基づいて、前記参加情報の通知先である利用者端末の役割に応じて、通知する情報を制限する段階を含むことを特徴とする冠婚葬祭支援方法。
【請求項１】
複数の利用者端末と、管理サーバを含む金融機関システムとがネットワークを介して接続された冠婚葬祭支援システムであって、
前記管理サーバは、
冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを発信した利用者端末を当該イベントの代表者端末と特定し、前記イベント情報に基づいて利用者配信ページを作成し、前記参加者リストの宛先に配信する利用者配信ページ作成部と、
前記利用者配信ページに参加情報を入力した利用者を参加者と特定し、前記参加者からの祝儀または不祝儀金の送金要求情報を受付け、前記参加情報に付加して記録する参加者管理部とを備え、
前記参加情報の項目ごとに開示レベル属性を付加し、前記開示レベル属性に基づいて、前記参加情報の通知先である利用者端末の役割に応じて、通知する情報を制限することを特徴とする冠婚葬祭支援システム。
【請求項２】
前記管理サーバは、記録された前記参加情報を参照して、前記参加者が金品の宅配を希望する旨の情報を抽出し、当該情報に基づいて宅配依頼データを作成し、宅配業者システムに前記宅配依頼データを送信する宅配依頼部を備えた、請求項1に記載の冠婚葬祭支援システム。
【請求項３】
前記宅配依頼部は、当該イベントの主催者である主催者端末から、返礼のための金品の手配要求を受付けて宅配依頼データを作成し、前記宅配業者システムに前記宅配依頼データを送信する、請求項２に記載の冠婚葬祭支援システム。
【請求項４】
前記主催者端末と前記代表者端末は異なる利用者の端末であることを特徴とする、請求項３に記載の冠婚葬祭支援システム。
【請求項５】
前記管理サーバは、複数の代表者端末からそれぞれ別々に入力されたイベント情報を解析し、同一のイベントであると判定した場合は、当該イベント情報をマージしてひとつのイベントとして管理する、請求項1乃至４に記載の冠婚葬祭支援システム。
【請求項６】
前記管理サーバは、前記利用者端末からの要求に基づいて、当該利用者のイベントに関する利用履歴を前記利用者端末に表示させる、請求項1乃至５に記載の冠婚葬祭支援システム。
【請求項７】
複数の利用者端末と、管理サーバを含む金融機関システムとがネットワークを介して接続されたシステムにおける冠婚葬祭支援方法であって、
前記管理サーバが、
冠婚葬祭に関するイベント情報および当該イベント情報の通知先である参加者リストを発信する利用者端末を当該イベントの代表者端末と特定し、前記イベント情報に基づいて利用者配信ページを作成し、前記参加者リストの宛先に配信する段階と、
前記利用者配信ページに参加情報を入力した利用者を参加者と特定し、前記参加者からの祝儀または不祝儀金の送金要求情報を受付け、前記参加情報に付加して記録する段階とを含み、
前記参加情報の項目ごとに開示レベル属性を付加し、前記開示レベル属性に基づいて、前記参加情報の通知先である利用者端末の役割に応じて、通知する情報を制限する段階を含むことを特徴とする冠婚葬祭支援方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−１１８６６３（Ｐ２０１２−１１８６６３Ａ）
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１０−２６６３３６（Ｐ２０１０−２６６３３６）
【出願日】平成２２年１１月３０日（２０１０．１１．３０）
【出願人】（３０２０６４７６２）株式会社日本総合研究所 (367)
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願日】平成２２年１１月３０日（２０１０．１１．３０）
【出願人】（３０２０６４７６２）株式会社日本総合研究所 (367)
[ Back to top ]