WO2021049574A1

WO2021049574A1 - 葬儀自動発注サーバ

Info

Publication number: WO2021049574A1
Application number: PCT/JP2020/034307
Authority: WO
Inventors: 孝行高田
Original assignee: フューネラルサービスワーカーズアカデミー，インク．
Priority date: 2019-09-11
Filing date: 2020-09-10
Publication date: 2021-03-18

Abstract

利用者に葬儀品目を選択する機会を与え、発注した葬儀品目の仕様と実際に用いられた葬儀品目との比較評価に応じた価格の決済により、利用者の希望通りの葬儀で納得感の得られる葬儀を支援することができる葬儀自動発注システムを提供する。　葬儀に用いる品目の仕様情報と価格情報を記憶する記憶手段３１と、利用者が発注した葬儀に用いる品目の発注情報を利用者端末から受信する受信手段と、葬儀に用いられた品目の実物に関する実物情報を、前記受信手段によって受信された前記発注情報に係る品目の記憶手段３１から読み出された仕様情報と比較して評価した評価情報を得る評価手段３０６と、前記発注情報に係る品目の記憶手段３１から読み出された価格情報を、評価手段３０６によって得られた前記評価情報に基づいて変額した価格を決済額情報として前記利用者端末に送信し、提示する情報提示手段３０７とを備える。

Description

葬儀自動発注サーバ

　本発明は、利用者に葬儀品目を選択する機会を与え、発注した葬儀品目と実際に用いられた葬儀品目との比較評価に基づいて価格を変額して決済する葬儀自動発注サーバに関する。

　従来、インターネットを介して、利用者が希望する結婚式場及び衣装や引き出物等の関連商品に関する見積情報を提供し、受け付けた仮予約の内容を結婚式場に通知するとともに、関連商品を取り扱う業者に発注するブライダル情報提供システムが知られている（例えば、特許文献１参照）。
　また、葬儀等の冠婚葬祭の行事において、葬儀の進め方や葬儀会場等のレイアウトについて、利用者が選択した生花、供え物、焼香台等の商品の画像データを指定された重ね順で表示するとともに、画像データに対応する商品の単価に基づいて見積情報を提供する見積作成装置が知られている（例えば、特許文献２参照）。

　特許文献１に記載のブライダル情報提供システムは、システムが開設するＷｅｂサイトにアクセスする利用者の端末に結婚式場の情報を提供し、利用者の端末から結婚式場の選択情報を受信すると、つぎに選択された結婚式場が提供可能な披露宴会場や披露宴の料理及び衣装、引き出物等の関連商品情報を提供し、利用者の端末から選択終了情報を受信すると、費用を順次加算して行く積み上げ方式による概算見積を利用者の端末に提示し、さらに利用者の端末から仮予約情報を受信すると、仮予約の対象となった結婚式場の端末に仮予約の内容を送信するものである。そして、利用者と結婚式場の担当者が直接面談し内容を合意した段階で本予約すると、システムは結婚式場の端末から発注データを受信し、この発注データに基づいて、関連商品を取り扱う各業者に発注データを送信する。
　特許文献２に記載の見積作成装置は、生花、供え物、焼香台等の商品の画像データを格納する画像情報データベースと、商品コード、商品名、単価等の商品に関する情報を格納する商品情報データベースとを有し、利用者から葬儀会場の選択入力を受け付けると、祭壇イメージ作成処理を実行し、まず画像情報データベースを用いて表示画面左側のイメージ編集画面に葬儀会場のイメージ画像を表示するとともに、表示画面右側に選択可能な商品のイメージ部品を複数配置して表示し、利用者からの商品のイメージ部品の選択入力を受け付ける度に、当該イメージ部品を、イメージ部品に設定されているイメージ編集画面の表示階層に表示することにより、葬儀会場の祭壇全体のイメージ画像を表示するものである。そして、利用者からの祭壇全体のイメージ画像作成の終了入力を受け付けると、見積書作成処理を実行し、商品情報データベースを用いて祭壇イメージ作成処理で選択されたイメージ部品に係る商品それぞれの単価と数量から見積合計金額を算出し、見積書を印刷出力後、自動発注処理を実行する。

特開２００２－０８３０７３号公報特開２００５－０３２０１３号公報

　しかし、特許文献１、２に記載のいずれのシステムにおいても、利用者が選択した商品の見積時の仕様情報と行事の当日に用いられた商品とを客観的に比較評価し、その評価に応じて商品価格を変額した決済を提供するシステムは見当たらない。
　現代は、臨終を迎える場所の９０％以上が病院といわれ、臨終後の処置が終わると余儀なく遺体を病院から搬出することが求められる。
　多くの遺族は、突然のことで何の知識もないまま、葬儀の準備に追われる。そして、病院の看護師に紹介され、遺体の搬送を依頼した葬儀社に、その後の葬儀の手配についても他の葬儀社と比較することなく依頼する。しかし、葬儀社の提案する葬儀プランは、葬儀に対する捉え方も「家」から「個人」に代り、少子高齢化が進んで参列者が少ないことから簡素で低価格を求める遺族のニーズに十分応えておらず、葬儀社主導で等級や価格の高いものが勧められ、派手な葬儀を行わせようと仕向けられるため、希望通りの葬儀スタイルで葬儀を行えなかったとの声や、費用が予想以上に高かったなどの苦情が聞かれる。

　本発明は、このような課題を解決するためになされたものであり、利用者に葬儀品目を選択する機会を与え、発注した葬儀品目の仕様と実際に用いられた葬儀品目との比較評価に基づいて価格を変額して決済することにより、利用者の希望通りの葬儀で納得感の得られる葬儀を支援することができる葬儀自動発注サーバを提供することを目的とする。

　請求項１に記載の葬儀自動発注サーバは、葬儀に用いる品目の仕様情報及び価格情報を記憶する記憶手段と、利用者が発注した葬儀に用いる品目の発注情報を利用者端末から受信する受信手段と、葬儀当日の葬儀場に納品され葬儀に用いられた品目の実物に関する実物情報を、前記受信手段によって受信された前記発注情報に係る品目の前記記憶手段から読み出された仕様情報と比較して評価した評価情報を得る評価手段と、前記発注情報に係る品目の前記記憶手段から読み出された価格情報を、前記評価手段によって得られた前記評価情報に基づいて変額した価格を決済額情報として前記利用者端末に送信し、提示する情報提示手段とを備える。

　請求項２に記載の葬儀自動発注サーバは、前記葬儀に用いる品目には、葬儀場の会場が含まれることで、葬儀会場も客観的な比較評価の対象となって葬儀会場の価格もその評価に応じて変額して決済されることから、利用者がより納得感の得られる葬儀を支援することができる。
　請求項３に記載の葬儀自動発注サーバは、前記仕様情報には画像データが含まれ、前記実物情報は、前記受信手段によって前記利用者端末から受信された前記実物の画像データを含み、前記評価手段は、前記実物の画像データを、前記仕様情報に含まれる画像データと比較して評価した評価情報を得ることで、利用者自身が撮影した実物の画像データによって客観的に評価して決済額に反映されることから、利用者がさらに納得感の得られる葬儀を支援することができる。
　請求項４に記載の葬儀自動発注サーバは、前記仕様情報にはテキストデータが含まれ、前記実物情報は、前記受信手段によって前記利用者端末から受信された前記実物に貼付された電子タグ又は情報コードから読み出されたテキストデータを含み、前記評価手段は、前記実物に貼付された電子タグ又は情報コードから読み出されたテキストデータを、前記仕様情報に含まれるテキストデータと比較して評価した評価情報を得ることで、利用者が実物を撮影する余裕がない場合でも、利用者自身が取得した実物に貼付されたタグ情報又は情報コードから読み出したテキストデータによって客観的に評価して決済額に反映することから、利用者が納得感の得られる葬儀を支援することができる。
　請求項５に記載の葬儀自動発注サーバは、前記実物情報は、前記受信手段によって前記発注品目を取り扱う事業者端末から受信した納品情報を含み、前記評価手段は、前記納品情報を、前記仕様情報と比較して評価した評価情報を得ることで、利用者が葬儀の進行に追われ、葬儀当日の品目の撮影やタグ情報等を取得する余裕が全くない場合でも、事業者の納品情報によって客観的に評価して決済額に反映することから、利用者が納得感の得られる葬儀を支援することができる。
　請求項６に記載の葬儀自動発注サーバは、前記仕様情報に含まれる画像データには、複数の前記発注品目の仕様情報に含まれる画像データを重畳して合成した合成画像データが含まれ、前記実物の画像データには、前記受信手段によって前記利用者端末から受信された前記葬儀場の会場を含む全景画像データを含むことで、利用者が葬儀当日に用いられた葬儀品目の一つ一つを撮影する余裕がない場合でも、利用者が撮影した葬儀会場の全景画像データによって葬儀品目の一つ一つを客観的に評価して決済額に反映することから、利用者が納得感の得られる葬儀を支援することができる。

　本発明によれば、葬儀に用いる品目の仕様情報及び価格情報を記憶する記憶手段と、利用者が発注した葬儀に用いる品目の発注情報を利用者端末から受信する受信手段と、葬儀当日の葬儀場に納品され葬儀に用いられた品目の実物に関する実物情報を、前記受信手段によって受信された前記発注情報に係る品目の前記記憶手段から読み出された仕様情報と比較して評価した評価情報を得る評価手段と、前記発注情報に係る品目の前記記憶手段から読み出された価格情報を、前記評価手段によって得られた前記評価情報に基づいて変額した価格を決済額情報として前記利用者端末に送信し、提示する情報提示手段とを備える構成により、利用者の希望通りの葬儀で納得感の得られる葬儀を支援することができる。

本発明の実施例１に係る葬儀自動発注システムの全体構成例を示す図である。本発明の実施例１に係る葬儀自動発注サーバの概要構成例を示す図である。本発明の実施例１に係る葬儀自動発注システムの運用機能例を示す図である。本発明の実施例１に係る葬儀自動発注サーバの記憶部内のデータ構成例を示す図である。本発明の実施例１に係る葬儀自動発注サーバにおける事業者コード及び利用者コードの構成例である。本発明の実施例１に係る葬儀自動発注サーバにおける品目コードの構成例である。本発明の実施例１に係る葬儀自動発注サーバにおける品目設定テーブル例である。本発明の実施例１に係る葬儀自動発注サーバが生成する合成画像データの構成例を示す図である。本発明の実施例１に係る葬儀自動発注サーバの全体動作手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバの品目情報を事業者が登録・更新する手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバの利用者の葬儀希望地の受信から事業者への自動発注までの手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバへのログイン直後に未発注の利用者端末に提示する画面表示例である。本発明の実施例１に係る葬儀自動発注サーバが利用者端末に品目情報を提示する画面表示例である。本発明の実施例１に係る葬儀自動発注サーバの品目設定の読出手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバの選択候補となる品目情報を利用者端末に提示する手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバの利用者端末から受信した発注品目を書き込む手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバの利用者端末に発注品目情報及び見積額を提示する手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバの利用者端末から発注された品目を事業者に自動発注する手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバの評価・決済の全体手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバの利用者端末から受信した葬儀会場の全景画像データに基づいて各品目を評価する手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバの決済手順を示すフローチャートである。本発明の実施例１に係る葬儀自動発注サーバが利用者端末に提示する決済額を提示する画面表示例である。本発明の実施例２に係る葬儀自動発注サーバの利用者端末から受信した品目の画像データに基づいて評価する手順を示すフローチャートである。

　以下、添付図面を参照しながら本発明を実施するための形態について詳細に説明する。図１から図２３は、本発明の実施の形態を例示する図であり、これらの図において、同一の符号を付した部分は同一物を表し、基本的構成及び動作は同様であるものとする。

　図１は、本発明の実施例１に係る葬儀自動発注システムの全体構成例を示す図である。
　図１に示す葬儀自動発注システム１は、葬儀自動発注サーバ３が、事業者端末４ａ（４）～事業者端末４ｉ（４）及び利用者端末５とインターネット２を介して接続される構成である。
　図２は、本発明の実施例１に係る葬儀自動発注サーバの概要構成例を示す図である。
　図２に示す葬儀自動発注サーバ３は、システム全体を統括的に制御する制御部（ＣＰＵ）３０、各種情報を記憶する記憶部３１、キーボードやマウス等からなる入力部３３、ディスプレイ等の表示部３４、及びインターネット２に接続される通信部３５がバスライン３２を介して接続される構成である。

　制御部（ＣＰＵ）３０は、オペレーションシステム等のプログラム、葬儀自動発注システムの手順を規定したプログラム等がＲＯＭに記録又はＲＡＭにロードされることによって、認証手段３００、品目情報書込手段３０１、品目情報提示手段３０２、発注品目情報書込手段３０３、発注品目情報提示手段３０４、発注品目情報転送手段３０５、評価手段３０６、決済額情報提示手段３０７並びに各種処理手段及び判定手段等を実現している。

　記憶部３１は、ＲＡＭ、ＲＯＭ等の揮発性又は不揮発性の半導体素子や、ハードディスク、光ディスク等の補助記憶装置から構成され、プログラム３１０、各種テーブル３１１、事業者情報３１２、利用者情報３１３、品目情報３１４、発注品目情報３１５及び評価情報３１６等を記憶する。

　入力部３３は、キーボードやマウス、トラックボール等のポインティングデバイスからなり、例えば、記憶部３１に記憶されている各種テーブルや各種情報の保守や補助的入力に用いられる。表示部３４は、管理者が保守や補助的に入力する各種情報の表示や各種葬儀自動発注サーバ３の動作状況を確認するために用いられる。通信部３５は、インターネット２を介して外部との通信を可能にするためのものであり、例えばＴＣＰ／ＩＰ等のプロトコルを利用して有線又は無線により、事業者端末４ａ（４）～事業者端末４ｉ（４）や利用者端末５との情報の送受信に用いられる。

　認証手段３００は、通信部３５を通じて接続要求する外部端末からの認証情報と、事業者情報３１２又は利用者情報３１３内の認証情報とを照合する手段である。この認証手段３００は、取り扱う故人や遺族等の個人情報等の秘密保持のために必要である。

　品目情報書込手段３０１は、通信部３５を通じて接続する事業者端末４ａ～事業者端末４ｉの取り扱う品目に関する情報を、品目情報３１４として新規に登録し、また、その品目の在庫情報を随時更新書き込む手段である。

　品目情報提示手段３０２は、利用者が葬儀の執行を希望する地域の事業者が提供可能な品目について品目情報３１４を読み出し、通信部３５を通じて接続する利用者端末５の利用者に提示するために送信する手段である。

　発注品目情報書込手段３０３は、通信部３５を通じて接続する利用者端末５から受信した品目の発注情報、すなわち、品目コード、数量、提供する事業者コードを発注品目情報３１５として書き込む手段である。また、発注品目情報書込手段３０３は、利用者端末５から受信した発注情報に係る品目の単価と数量から当該品目の価格を求め、これまで受信した品目に係る見積額を算出し、発注品目情報３１５として併せて書き込む。

　発注品目情報提示手段３０４は、通信部３５を通じて接続する利用者端末５から受信した品目の発注情報に対して品目情報３１４の仕様情報に含まれる画像データを読み出し、葬儀場の会場の画像データとともに所定の重複順に表示した合成画像データを生成し、発注品目情報３１５として書き込むとともに、発注品目情報３１５の見積額情報と葬儀当日のイメージに近い当該合成画像データを読み出し、利用者端末５に通信部３５を通じて送信する手段であり、利用者端末５が当該合成画像データを利用者に提示する。なお、葬儀場の会場には、告別式・葬儀会場のほか、通夜・通夜振る舞い会場、火葬場、精進落とし会場が含まれる。また葬儀場の会場も、葬儀に用いる品目に含まれることから、葬儀場の会場の画像データも品目情報３１４の仕様情報に含まれる。

　発注品目情報転送手段３０５は、通信部３５を通じて接続する利用者端末５から受信した全ての品目に係る発注情報が記憶された発注品目情報３１５からそれぞれの品目に係る発注情報を読み出し、それぞれの品目を提供する事業者の事業者端末４ａ～事業者端末４ｉに通信部３５を通じてそれぞれの発注情報を転送する手段である。発注情報が事業者に転送されることにより、実際に発注されたことになる。

　評価手段３０６は、通信部３５を通じて接続する利用者端末５から受信した、葬儀当日の葬儀場に納品され葬儀に用いられた品目の実物に関する実物情報と、記憶部３１から読み出した当該品目に関する品目情報３１４の仕様情報とを比較評価した評価値データを評価情報３１６として書き込む手段である。なお実物情報には、利用者端末５から受信した納品された品目の画像データや納品された品目に貼付されている電子タグ又は情報コードから読み出されたテキストデータ、事業者端末４ａ～事業者端末４ｉから受信した納品情報及び葬儀の会場を含む全景画像データが含まれる。また仕様情報には、品目情報３１４から読み出された品目の仕様情報に含まれる画像データ及びテキストデータ並びに発注品目情報３１５として記憶されている合成画像データが含まれる。

　決済額情報提示手段３０７は、発注品目情報３１５として記憶されている品目コードに係る品目のそれぞれについて、品目情報３１４の価格情報及び評価情報３１６の評価値データを記憶部３１から読み出し、それらに基づいて変額した価格から決済額を算出し、通信部３５を通じて当該決済額情報を利用者に提示するために利用者端末５に送信する手段である。なお決済額情報提示手段３０７は、決済額情報が提示された利用者端末５から決済額の同意情報を受信した場合、決済を依頼するために金融決済機関サーバ６に決済処理情報を送信する。

　図３は、本発明の実施例１に係る葬儀自動発注システム１の運用機能例を示す図である。

　葬儀自動発注サーバ３は、事業者端末４ａ～事業者端末４ｉ又は利用者端末５から接続要求があった場合、当該外部端末からの認証情報と、認証手段３００により予め記憶部３１に記憶されている事業者情報３１２及び利用者情報３１３内の認証情報とを照合する。照合後は、事業者コードであるか利用者コードであるかを識別して、それぞれに対応する以下の処理を行う。

　葬儀自動発注サーバ３は、事業者端末４ａ～事業者端末４ｉから取り扱う品目情報を受信すると、品目情報書込手段３０１により、記憶部３１にすでに同一の品目に関する品目情報３１４がある場合には上書きして更新し、新たな品目に関する品目情報の場合には記憶部３１に品目情報３１４として新規に登録し、またそれら品目の在庫情報を上書きして更新する。

　葬儀自動発注サーバ３は、利用者端末５が通信部３５を通じて接続されると、見積・発注処理を実行する。見積・発注処理は、品目情報提示手段３０２、発注品目情報書込手段３０３、発注品目情報提示手段３０４及び発注品目情報転送手段３０５による一連の処理である。

　葬儀自動発注サーバ３は、まず利用者端末５から葬儀を執り行う希望地を受信すると、記憶部３１に記憶されている各種テーブル３１１に基づき、地域コード及び区域コードを特定し、事業者情報３１２、品目情報３１４及び各種テーブル３１１に基づき品目情報提示手段３０２により、利用者端末５に対して特定された区域コードに所在地がある事業者が提供可能な品目情報を利用者端末５の利用者に提示するために送信する。

　葬儀自動発注サーバ３は、利用者に提示された品目情報を見た利用者の利用者端末５から品目コード、数量及び事業者コードからなる発注情報を受信すると、発注品目情報書込手段３０３により、発注コードを付与し、見積額を計算するとともに、これら発注コード、見積額、品目コード、数量及び事業者コードを発注品目情報３１５として記憶部３１に書き込む。

　また葬儀自動発注サーバ３は、発注品目情報提示手段３０４により、記憶部３１に記憶されている品目情報３１４の仕様情報に含まれる画像データを、発注品目情報３１５の品目コードに関連付けた画像レイヤごとに表示し、葬儀場の会場の画像データとともに所定の重複順に合成することにより葬儀当日の葬儀会場をイメージする合成画像データを生成し、発注品目情報３１５として書き込むとともに、記憶部３１から読み出した発注品目情報３１５の見積額情報と当該合成画像データを利用者端末５の利用者に提示するために送信する。

　そして葬儀自動発注サーバ３は、利用者端末５から利用者が発注した品目の全てについて選択を完了する旨の情報を受信すると、発注品目情報転送手段３０５により、記憶部３１に記憶している事業者情報３１２及び発注品目情報３１５に基づき発注情報に係る品目を提供するそれぞれの事業者の事業者端末４ａ～事業者端末４ｉに対してそれぞれの発注情報を自動的に転送する。

　葬儀自動発注サーバ３は、発注処理がすでに済んでいる利用者端末５が通信部３５を通じて接続されると、評価・決算処理を実行する。評価・決算処理は、評価手段３０６及び決済額情報提示手段３０７による一連の処理である。

　葬儀自動発注サーバ３は、まず利用者端末５から葬儀当日の葬儀場に納品され葬儀に用いられた品目の実物に関する実物情報を受信すると、評価手段３０６により、記憶部３１に記憶している品目の仕様情報と比較評価して評価値データを求め、その評価値データを評価情報３１６として書き込む。

　つぎに葬儀自動発注サーバ３は、利用者端末５から評価終了の旨を受信すると、決済額情報提示手段３０７により、発注品目情報３１５として記憶している発注情報に係るそれぞれの品目について、品目情報３１４の価格（単価）情報及び評価情報３１６の評価値データを記憶部３１から読み出し、それらに基づいて変額し、さらに記憶部３１から読み出した発注品目情報３１５の数量を掛け合わせて算出した額に従い算出した決算額情報を、利用者端末５の利用者に提示するために送信する。最後に葬儀自動発注サーバ３は、利用者端末５から提示された決算額情報で利用者が同意する旨の情報を受信すると、記憶部３１から利用者情報３１３の支払い情報を読み出し、当該利用者の支払い情報とともに決済処理情報を、決済を依頼するために金融決済機関サーバ６に送信する。

　個別の手段及び記憶される各種情報の具体的構成については、以下により詳細に説明する。

　図４は、本発明の実施例１に係る葬儀自動発注サーバの記憶部内のデータ構成例を示す図である。

　事業者情報３１２は、葬儀品目を提供する葬儀関連事業者に関する情報を保持しており、具体的には、事業者を識別する事業者コード、事業者名、事業者の所在地、代表連絡先、葬儀自動発注サーバ３にログインするための認証情報、事業者のＷｅｂ－ＵＲＬ、振り込み用の口座情報、事業者が取り扱う品目の品目コード等を保持している。

　利用者情報３１３は、利用者に関する情報を保持し、具体的には、利用者を識別する利用者コード、利用者氏名、住所、連絡先、葬儀自動発注サーバ３にログインするための認証情報、利用者が支払うクレジット等の支払い情報、葬儀品目を発注した際に付与する発注コード等を保持している。

　品目情報３１４は、葬儀関連事業者が取り扱う品目に関する情報を保持し、具体的には、品目を識別する品目コード、品目名、当該品目を取り扱う事業者コード、当該品目の在庫の有無や在庫数を表す在庫情報、当該品目の仕様情報、価格（単価）等を保持している。なお、当該品目の仕様情報として、画像データ、テキストデータの双方又は一方を保持している。

　発注品目情報３１５は、利用者の利用者端末５から受信した発注情報に係る品目に関する情報を保持し、具体的には、利用者コード、葬儀に係る品目を発注した際付与する発注コード、葬儀に係る品目すべての見積額、葬儀場の会場の画像データとともに発注情報に係る品目の画像データが所定の重複順で表示した合成画像データ、発注された発注品目数ｎ、及び発注情報に係る品目それぞれについて、品目を取り扱う事業者の事業者コード、品目コード、数量等を保持している。

　評価情報３１６は、葬儀当日の葬儀場に納品され葬儀に用いられた品目に関する評価情報を保持し、具体的には、利用者コード、発注コード、発注された品目それぞれの品目コード、発注された品目それぞれの実物情報と品目情報３１４に保持されている仕様情報とを比較して評価した評価値データを保持している。

　図５から図７は、本発明の実施例１に係る葬儀自動発注サーバの記憶部内の各種テーブル構成例を示す図である。

　図５は、本発明の実施例１に係る葬儀自動発注サーバにおける事業者コード及び利用者コードの構成例である。
　図４の説明で前述した、事業者コード３１２１及び利用者コード３１３１は、例えば、数字２桁の地域コード、数字３桁の区域コード、数字２桁の業者種別コード、数字１桁の規模コード及び例えば任意の４桁の連続番号からなる、例えば１２桁の数字で構成される。

　地域テーブル３１１Ａは、地域コードと大きな行政区画、例えば都道府県で表される地域名で構成され、例えば、地域コード「０１」と地域名「北海道」が対になって記憶されている。地域コードは、利用者から葬儀を執り行う希望地を受信した際に、日本全国に所在する葬儀に用いる品目を取り扱う事業者を効率的に抽出するために用いられる。

　区域テーブル３１１Ｂは、区域コードと細分化された行政区画、例えば市区町村で表される区域名で構成され、例えば、区域コード「００３」と区域名「石狩市」が対になって記憶されている。区域コードは、事業者の営業区域に相当し、より効率的に事業者を抽出するために用いられる。

　業者種別テーブル３１１Ｃは、業者種別コードと業者種別名で構成され、例えば、業者種別コード「０６」と業者種別名「生花」が対になって記憶されている。業者種別コードは、事業者が利用者に提供する葬儀に用いる品目を特定することに用いられる。なお、業者種別コードが「９９」の場合には、利用者コードを表す。

　規模テーブル３１１Ｄは、規模コード、対応規模数及び葬儀プラン名で構成され、例えば、規模コード「３」、対応規模数「５０人～１５０人」及び葬儀プラン名「家族葬」がセットになって記憶されている。規模コードは、葬儀に参列することが予想される人数、すなわち執り行う葬儀の規模を特定することに用いられる。なお、規模コードが「９」の場合には、利用者コードを表す。
　一般に、葬儀プランが「火葬式」では、葬儀会場での通夜や葬儀・告別式を省略して火葬のみで参列者が１人～１０人のごく身内で執り行う葬儀を想定している。また「一日葬」では、通夜を省略して葬儀・告別式のみで参列者が１０人～５０人程度の近親者に限定して執り行われ、「家族葬」では、二日にわたる通夜と葬儀・告別式を参列者が５０人～１５０人程度の親族や親しい友人等に限定して執り行われる。そして「一般葬」では、二日にわたる通夜と葬儀・告別式を参列者が１５０人以上と限定せずに大規模に執り行われることから、規模コードに対応する対応規模数と、葬儀プラン名が一対一に対応する。
　このため、本発明の実施例１では、以降の説明を簡単にするため、規模テーブルに葬儀プラン名を含める構成とした。利用者の希望に応じて、葬儀の内容を表す葬儀プランと参列者の規模を細かく設定できるように、葬儀プランテーブルと規模テーブルを別々に設定できるようにしてもよい。

　図６は、本発明の実施例１に係る葬儀自動発注サーバにおける品目コードの構成例である。
　図４の説明で前述した、品目コード３１４１は、例えば、品目の種別を表す数字３桁の品目種別コード及び品目の等級を表す数字２桁のランクコードからなる、例えば数字５桁の数字で構成される。

　品目種別テーブル３１１Ｅは、品目種別コードと品目名で構成され、例えば、品目種別コード「００５」と品目名「棺」が対になって記憶されている。品目種別コードは、利用者に品目ごとに抽出して提示するために用いられる。

　ランクテーブル３１１Ｆは、ランクコードと等級で構成され、例えば、ランクコード「０２」と等級「最上級」が対になって記憶されている。ランクコードは、等級の異なる複数の同種の品目を利用者に提示する際に用いられる。

　図７は、本発明の実施例１に係る葬儀自動発注サーバにおける品目設定テーブル例である。葬儀プランに応じて執り行う葬儀の内容や規模が異なるため、葬儀プランごとに利用者が葬儀に用いる品目の選択可否を設定する必要がある。

　設定条件テーブル３１１Ｇは、設定条件コードと設定条件が対になって記憶されている。設定条件テーブル３１１Ｇは、後述する品目設定テーブル３１１Ｈで、葬儀プランによって葬儀に用いる品目を選択する必要のないもの「２（選択不可）」、オプションで選択できるもの「１（オプション）」、必ず使用するもの「０（必須）」を設定するために用いられる。

　品目設定テーブル３１１Ｈは、前述した規模テーブル３１１Ｄの規模コード、品目種別テーブル３１１Ｅの品目種別コード及び設定条件テーブル３１１Ｇの設定条件コードで構成されている。葬儀プラン名に対応した規模コードに応じて、品目種別コードごとに選択必須「０」、オプションで選択可「１」、必要なし「２」の設定条件コードが設定されている。例えば、火葬式では、規模コード「１」で品目種別コード「００１（霊柩寝台車）」は「０（必須）」、品目種別コード「００２（安置施設）」は「２（選択不可）」と設定されている。
　また、葬儀の規模に応じて、品目の大きさや必要数も異なるため、それらを提供可能とする事業者を抽出する際にも品目設定テーブル３１１Ｈは用いられる。

　この他図示していないが、葬儀に用いる品目種別をどの業者種別が取り扱うのかを特定するために用いられ、品目種別テーブル３１１Ｅの品目種別コードと業者種別テーブル３１１Ｃの業者種別コードとを対応付けて記憶した品目種別－業者種別対応テーブル、合成画像データを構成する階層状に重ねて配置された複数の画像レイヤと画像レイヤに表示すべき品目の品目種別コードとを関連付けて記憶した合成画像レイヤ設定テーブル等がある。

　つぎに、前述した合成画像レイヤ設定テーブルに従い表示された合成画像データの構成例について説明する。
　図８は、本発明の実施例１に係る葬儀自動発注サーバが生成する合成画像データの構成例を示す図である。

　図８Ａは、合成画像データ例で、図８Ｂは、図８Ａの合成画像データのレイヤ構造例を明らかにするため画像レイヤ毎に分解して表示している。
　図８Ｂでは、合成画像は、例えばレイヤ１～レイヤ６からなる６層の画像レイヤを有し、レイヤ１には焼香用具、レイヤ２には生花、レイヤ３には棺、レイヤ４には写真、レイヤ５には祭壇、そして最背面のレイヤ６には葬儀会場のそれぞれの品目の画像データが所定領域に配置されている。各品目の画像データは、発注品目情報３１５の仕様情報に含まれる画像データが用いられ、葬儀当日のイメージに近い合成画像を生成できる。
　なお、図８の合成画像データ例は、葬儀・告別式の会場例であるが、通夜・通夜振る舞い会場、火葬場、精進落とし会場についても必要に応じて合成画像データが生成される。

＜全体動作手順＞
　続いて、上述のように構成された本発明の実施例１に係る葬儀自動発注サーバ３の動作手順について図９乃至図２１を用いて説明する。
　図９は、本発明の実施例１に係る葬儀自動発注サーバの全体動作手順を示すフローチャートである。

　ステップＳ１では、制御部（ＣＰＵ）３０は、事業者端末４ａ～事業者端末４ｉ又は利用者端末５が送信する認証情報を、通信部３５を通じて受信する。認証情報は、例えばパスワードや、指紋情報、網膜情報などのパターン画像によるものでもよい。

　ステップＳ２では、制御部（ＣＰＵ）３０は、事業者情報３１２又は利用者情報３１３に予め登録されている認証情報と受信した認証情報との照合を行う。
　制御部（ＣＰＵ）３０は、照合が取れた事業者情報３１２の事業者コード又は利用者情報３１３の利用者コードから、接続する端末が事業者端末４ａ～事業者端末４ｉか利用者端末５かを判定する。例えば、図５に示す事業者コード／利用者コードの例では、制御部（ＣＰＵ）３０は、事業者コード／利用者コード「０１００２０７１０００１」の６、７桁目から抽出した業者種別コード「０７」から事業者（業者種別テーブル３１１Ｃから業者種別名「焼香用具・祭壇レンタル」）と判定する。事業者と判定した場合にはステップＳ３に進む。制御部（ＣＰＵ）３０は、事業者コード／利用者コードから業者種別コード「９９」を抽出した場合は利用者と判定し、ステップＳ４に進む。なお、照合が取れない場合は、図示していないがステップＳ１に戻る。

　ステップＳ３では、制御部（ＣＰＵ）３０は、品目情報書込手段３０１によって、品目情報の変更又は新規登録、またそれら品目の在庫情報を更新する品目情報書込の処理を実行する。
　品目情報書込の具体的な処理については、図１０を用いてサブルーチンとして後述する。品目情報書込の処理を実行後は、ステップＳ７に進む。

　ステップＳ４では、制御部（ＣＰＵ）３０は、接続している利用者端末５の利用者はすでに葬儀に用いる品目を発注済みであるか否かを判定する。制御部（ＣＰＵ）３０は、照合が取れた利用者コードに関する利用者情報３１３の発注コードが記憶されていない場合には発注なしと判定し、ステップＳ５に進む。制御部（ＣＰＵ）３０は、照合が取れた利用者コードに関する利用者情報３１３の発注コードが記憶されている場合には発注済みと判定し、ステップＳ６に進む。

　ステップＳ５では、制御部（ＣＰＵ）３０は、見積・発注処理を実行する。なお、具体的な見積・発注処理は、図３で前述したように、品目情報提示手段３０２、発注品目情報書込手段３０３、発注品目情報提示手段３０４及び発注品目情報転送手段３０５による一連の処理であり、これらの具体的な処理については、図１１から図１８を用いて一連のサブルーチンとして後述する。見積・発注処理を実行後は、ステップＳ７に進む。

　ステップＳ６では、制御部（ＣＰＵ）３０は、評価・決済処理を実行する。なお、具体的な評価・決済処理は、図３で前述したように、評価手段３０６及び決済額情報提示手段３０７による一連の処理であり、これらの具体的な処理については、図１９から図２２を用いて一連のサブルーチンとして後述する。評価・決済処理を実行後は、ステップＳ７に進む。

　ステップＳ７では、制御部（ＣＰＵ）３０は、接続している事業者端末４ａ～事業者端末４ｉ又は利用者端末５からのログアウト要求の有無を判定する。端末からログアウト要求がなければ、ステップＳ２に戻り、ログアウト要求があれば端末との接続を終了する。

＜品目情報書込＞
　以下に、品目情報書込手段３０１によるステップＳ３「品目情報書込」の具体的な処理をサブルーチンとして説明する。
　図１０は、本発明の実施例１に係る葬儀自動発注サーバの品目情報を事業者が登録・更新する手順を示すフローチャートである。
　このサブルーチンでは、事業者が取り扱う品目に係る情報を品目情報３１４として新規に登録又は既存情報を上書き更新し、また当該品目の在庫情報を品目情報３１４として書き込む処理を実行する。

　ステップＳ１１では、制御部（ＣＰＵ）３０は、接続した事業者端末４ａ～事業者端末４ｉに対して、事業者が取り扱う品目の更新か、在庫の更新かを問い合わせる。事業者端末からの受信が「品目」である場合は、制御部（ＣＰＵ）３０は、品目情報の変更又は新規登録を受信すると判定し、ステップＳ１２に進む。事業者端末からの受信が「在庫」である場合は、制御部（ＣＰＵ）３０は、在庫情報を更新すると判定し、ステップＳ１３に進む。

　ステップＳ１２では、制御部（ＣＰＵ）３０は、事業者端末４ａ～事業者端末４ｉから受信した情報を品目情報３１４として記憶部３１に書き込む。例えば、図５に示す事業者コードの例では、業者種別コード「０７」で業者種別テーブル３１１Ｃから業者種別名「焼香用具・祭壇レンタル」の事業者であるから、制御部（ＣＰＵ）３０が品目情報３１４として入力を受け付ける品目コードは、図示していない品目種別－業者種別対応テーブルに基づき、品目種別テーブル３１１Ｅの品目種別コードが「００９」の品目名「祭壇」か「０１０」の「焼香用具」に限定される。そして例えば、ランクテーブル３１１Ｆのランクコードが「０２」の等級「最上級」との組み合わせである品目コード「００９０２」で同じ事業者コードの情報が品目情報３１４にない場合は新規登録となり、すでに同じ事業者コードの情報が品目情報３１４として記憶されている場合は上書きすることで更新登録となる。その後、制御部（ＣＰＵ）３０は、図９の全体動作手順に復帰し、ステップＳ７に進む。

　ステップＳ１３では、制御部（ＣＰＵ）３０は、受信した情報を品目情報３１４の在庫情報として記憶部に書き込む。その後、制御部（ＣＰＵ）３０は、図９の全体動作手順に復帰し、ステップＳ７に進む。

＜見積・発注＞
　次に、図１１から図１８を用いて、ステップＳ５「見積・発注」の具体的な処理を一連のサブルーチンとして説明する。
　これらのサブルーチンでは、利用者端末５から葬儀希望地及び葬儀プランを受信し、これらの情報に基づき利用者端末５に品目情報を送信し、提示された品目情報を見た利用者の利用者端末５から発注情報を受信し、利用者端末５から受信した発注情報を事業者端末４ａ～事業者端末４ｉに自動転送するまでの処理を実行する。
　図１１は、本発明の実施例１に係る葬儀自動発注サーバによる利用者からの葬儀希望地の受信から事業者への自動発注までの手順を示すフローチャートである。
　図１２は、本発明の実施例１に係るログイン直後に未発注の利用者端末に提示する画面表示例である。
　図１３は、本発明の実施例１に係る葬儀自動発注サーバが利用者端末に品目情報を提示する画面表示例である。

　図９のステップＳ５で、制御部（ＣＰＵ）３０は、見積・発注処理を実行する。
　図１１のステップＳ２１では、制御部（ＣＰＵ）３０は、地図及び葬儀プラン情報を利用者端末５に送信し、利用者端末５は利用者に例えば図１２の画面表示例を提示する。

　ステップＳ２２では、制御部（ＣＰＵ）３０は、利用者端末５から葬儀を執り行う希望地を受信する。例えば利用者端末５の画面に表示されている図１２上部のような地図上を利用者がクリックすることにより得られる地図情報でもよく、また住所地をキーボード等で入力した文字情報でもよい。
　例えば図１２上部の地図上の地域名である「北海道」が選択され、さらにプルダウン方式で表示された区域名、例えば「旭川市」が選択されることにより、制御部（ＣＰＵ）３０は、葬儀執行希望地として「北海道旭川市」を利用者端末５から受信する。

　ステップＳ２３では、制御部（ＣＰＵ）３０は、例えば葬儀希望地の「北海道旭川市」に対応して、記憶部３１に記憶している地域テーブル３１１Ａから地域コード「０１」を、区域テーブル３１１Ｂから区域コード「００２」をそれぞれ読み出し設定する。

　また、ステップＳ２４では、制御部（ＣＰＵ）３０は、葬儀プランの選択情報を受信する。例えば図１２下部に表示されている「火葬式」が選択されることにより、制御部（ＣＰＵ）３０は、葬儀プランの選択情報として「火葬式」を利用者端末５から受信する。そして制御部（ＣＰＵ）３０は、記憶部３１に記憶している図５の規模テーブル３１１Ｄから対応する規模コード「１」を設定する。

　つぎにステップＳ２５では、制御部（ＣＰＵ）３０は、記憶部３１に記憶している品目設定テーブル３１１Ｈに基づき、利用者端末５に提示する設定可能な品目一覧を設定する品目設定の読出の処理を実行する。品目設定の読出の具体的処理については、図１４を用いてサブルーチンとして後述する。品目設定の読出処理を実行後は、ステップＳ２６に進む。

　ステップＳ２６では、制御部（ＣＰＵ）３０は、ステップＳ２５の品目設定の読出処理で設定され、記憶部３１のＲＡＭに一時記憶された葬儀に用いる品目として選択可能な品目一覧の情報を利用者端末５の利用者に提示するために送信する。例えば、図１３の画面右下に表示されている「寝台霊柩車（必須）」、「生花（オプション）」等の一連の品目一覧が利用者端末５に提示される。

　ステップＳ２７では、制御部（ＣＰＵ）３０は、ステップＳ２６で提示された品目一覧から選択された品目とその数量を利用者端末５から受信する。例えば、図１３の画面右下に表示されている「棺（必須）」が利用者端末５から選択されることにより、制御部（ＣＰＵ）３０は、品目として「棺（必須）」を受信し、記憶部３１に記憶している図６の品目種別テーブル３１１Ｅに従い品目種別コード「００５」を設定する。

　ステップＳ２８では、制御部（ＣＰＵ）３０は、品目情報提示手段３０２によって、ステップＳ２７で設定された品目種別コードについて、等級や事業者の異なる全ての候補品目を提示する品目情報提示の処理を実行する。品目情報提示手段３０２の具体的動作については、図１５を用いてサブルーチンとして後述する。品目情報提示の処理を実行後は、ステップＳ２９に進む。

　ステップＳ２９では、制御部（ＣＰＵ）３０は、発注品目情報書込手段３０３によって、ステップＳ２８で提示した候補品目の中から発注された品目情報を、発注コード及び見積額とともに発注品目情報３１５として記憶部３１に書き込む発注品目情報書込の処理を実行する。発注品目情報書込の具体的な処理については、図１６を用いてサブルーチンとして後述する。発注品目情報書込の処理を実行後は、ステップＳ３０に進む。

　ステップＳ３０では、制御部（ＣＰＵ）３０は、発注品目情報提示手段３０４によって、ステップＳ２９で発注品目情報３１５として記憶された発注品目に基づき図１３の画面上部に表示されるべき合成画像データを生成し、それまでの見積額とともに利用者端末５に送信する発注品目情報提示の処理を実行する。発注品目情報提示の具体的な処理については、図１７を用いてサブルーチンとして後述する。発注品目情報提示の処理を実行後は、ステップＳ３１に進む。

　ステップＳ３１では、制御部（ＣＰＵ）３０は、ステップＳ２６で提示した品目一覧のうち必須品目が全て発注されたか否かを判定する。制御部（ＣＰＵ）３０は、必須品目が全て発注されたと判定した場合（Ｙ）にはステップＳ３２に進み、まだ全ての必須品目が発注されていないと判定した場合（Ｎ）にはステップＳ２８に戻り、処理を続ける。

　ステップＳ３２では、制御部（ＣＰＵ）３０は、利用者端末５から発注品目の選択を完了する情報を受信したか否かを判定する。制御部（ＣＰＵ）３０は、例えば、図１３の画面右最下部に表示されている「選択完了」ボタンが利用者端末５で押下された情報を受信した場合（Ｙ）にはステップＳ３３に進み、利用者端末５から「選択完了」ボタンが押下された情報を受信していない場合（Ｎ）にはステップＳ２８に戻り、処理を続ける。

　ステップＳ３３では、制御部（ＣＰＵ）３０は、発注品目情報転送手段３０５によって、記憶部３１に記憶している事業者情報３１２及び発注品目情報３１５に基づき発注情報に係る品目を提供するそれぞれの事業者の事業者端末４ａ～事業者端末４ｉに対してそれぞれの発注情報を自動的に転送する、発注品目情報転送の処理を実行する。発注品目情報転送の具体的な処理については、図１８を用いてサブルーチンとして後述する。発注品目情報転送の処理を実行後は図９の全体動作手順に復帰し、ステップＳ７に進む。

＜品目設定の読出＞
　つぎに、図１４及び前述した図６、図７を用いて、ステップＳ２５「品目設定の読出」の具体的な処理をサブルーチンとして説明する。
　図１４は、本発明の実施例１に係る葬儀自動発注サーバの品目設定の読出手順を示すフローチャートである。
　このサブルーチンでは、ステップＳ２４で受信した葬儀プランの選択情報に基づき、記憶部３１に記憶されている図７の品目設定テーブル３１１Ｈに従い、利用者端末５に送信する設定可能な品目一覧を設定する処理を実行する。
　ここでは、例えばステップＳ２４で受信した葬儀プランの選択情報を「火葬式」とする。

　図１４のステップＳ５１では、制御部（ＣＰＵ）３０は、品目設定テーブル３１１Ｈに記憶されている品目種別コードの一番若い番号である「００１」ついて、品目設定テーブル３１１Ｈに記憶されている設定条件コードが「２（選択不可）」に設定されているか否かを判定し、設定条件コードが「２（選択不可）」に設定されていると判定した場合（Ｙ）には、ステップＳ５３に進み、設定条件コードが「２（選択不可）」に設定されていないと判定した場合（Ｎ）には、ステップＳ５２に進む。
　例えば、葬儀プラン「火葬式」に対応する規模コードが「１」で、設定された品目種別コードが「００１」の場合、設定条件コードは「０」であるから、ステップＳ５２に進む。

　ステップＳ５２では、制御部（ＣＰＵ）３０は、記憶部３１に記憶している図６の品目種別テーブル３１１Ｅで品目種別コードに関連付けられた品目名を読み出し、品目種別コードと品目名を記憶部３１のＲＡＭに一時記憶する。

　ステップＳ５３では、制御部（ＣＰＵ）３０は、品目設定テーブル３１１Ｈに記憶されている品目種別コードについて全て読み出したか否かを判定する。
　制御部（ＣＰＵ）３０は、全ての品目種別コードを読み出していない場合（Ｎ）には、ステップＳ５１に戻り、処理を続ける。
　制御部（ＣＰＵ）３０は、全ての品目種別コードを読み出した場合（Ｙ）には復帰し、図１１のステップＳ２６に進む。

＜品目情報提示＞
　つづいて、図１５及び前述した図４、図５、図６を用いて、品目情報提示手段３０２によるステップＳ２８「品目情報提示」の具体的な処理をサブルーチンとして説明する。
　図１５は、本発明の実施例１に係る葬儀自動発注サーバが選択候補となる品目情報を利用者端末に提示する手順を示すフローチャートである。

　このサブルーチンでは、ステップＳ２７で選択された品目（例えば、「棺（必須）」）について、等級や事業者の異なる全ての候補品目を利用者に提示するため利用者端末５に送信する処理を実行する。

　図１５のステップＳ６１では、制御部（ＣＰＵ）３０は、まず図６の品目種別コードとランクコードの一番若い番号である「０１（高級）」からなる品目コードを設定する。例えば、ステップＳ２７で設定された品目種別コードが「００５（棺）」の場合、制御部（ＣＰＵ）３０は、品目コードを「００５０１（高級棺）」の５桁の数字に設定する。

　ステップＳ６２では、制御部（ＣＰＵ）３０は、利用者の葬儀希望地で設定された品目コードに関連付けられた品目を取り扱う事業者を抽出するため、図５に示す事業者コードのうち、地域コード、区域コード、業者種別コード及び規模コードからなる事業者コードの上位８桁を設定後、連続番号まで含めた１２桁の事業者コードを初期化する。例えば、「０１（北海道）」「００２（旭川市）」「０５（棺・骨壺（箱）・消耗品）」「１（火葬式）」である場合、連続番号を除く上位８桁の事業者コードは、「０１００２０５１」となり、連続番号まで含めた１２桁の事業者コードを「０１００２０５１０００１」に設定する。

　ステップＳ６３では、制御部（ＣＰＵ）３０は、記憶部３１に記憶されている図４の品目情報３１４の中から、設定された事業者コード上位８桁を含む事業者が取り扱う設定された品目コードの品目について在庫情報があるか否かを判定する。制御部（ＣＰＵ）３０は、在庫情報がある場合（Ｙ）には、ステップＳ６６に進む。制御部（ＣＰＵ）３０は、在庫情報がない場合（Ｎ）には、ステップＳ６７に進む。

　ステップＳ６４では、制御部（ＣＰＵ）３０は、在庫情報のある品目の事業者コード、仕様情報、価格情報等を品目情報３１４から読み出し記憶部３１のＲＡＭに一時記憶する。

　ステップＳ６５では、設定された品目コードに関連付けられた品目を取り扱う全ての事業者について読み出したか否かを判定する。すなわち、制御部（ＣＰＵ）３０は、ステップＳ６２で設定された事業者コード上位８桁を含む事業者の最終番号まで全て読み出したか否かを判定する。制御部（ＣＰＵ）３０は、事業者コードの最終番号まで読み出していない場合（Ｎ）には、ステップＳ６３に戻り、処理を続ける。制御部（ＣＰＵ）３０は、事業者コードの最終番号まで読み出した場合（Ｙ）には、ステップＳ６６に進む。

　ステップＳ６６では、設定された品目種別コードを含む全ての等級について読み出したか否かを判定する。すなわち、制御部（ＣＰＵ）３０は、品目コードを構成する現在のランクコードが等級の最も高い「０３（特級）」であるか否かを判定し、現在のランクコードが「０３（特級）」でない場合（Ｎ）には、ランクコードを１大きく設定後、ステップＳ６３に戻り処理を続ける。制御部（ＣＰＵ）３０は、現在のランクコードが「０３（特級）」である場合（Ｙ）には、ステップＳ６７に進む。

　ステップＳ６７で、制御部（ＣＰＵ）３０は、ステップＳ６４で記憶部３１のＲＡＭに一時記憶された全ての事業者コード、仕様情報及び価格情報の一覧を利用者端末５に送信し、利用者端末５が利用者に提示する。利用者端末５に提示される画面は、例えば図１３の左下の左から右へランク０１（高級）、ランク０２（最上級）及びランク０３（特級）の順に、仕様情報の画像データ及びテキストデータ、価格情報、事業者コード及び数量入力欄が上から順に表示される。複数の事業者コードについての品目の情報がある場合には、画面の下方に例えばスクロールすることで表示できるようにしてもよい。
　制御部（ＣＰＵ）３０は、その後復帰し、図１１のステップＳ２９「発注品目情報書込」に進む。

＜発注品目情報書込＞
　つぎに、図１６及び前述した図４を用いて、発注品目情報書込手段３０３によるステップＳ２９「発注品目情報書込」の具体的な処理をサブルーチンとして説明する。
　図１６は、本発明の実施例１に係る葬儀自動発注サーバの利用者端末から受信した発注品目を書き込む手順を示すフローチャートである。

　このサブルーチンでは、ステップＳ２８で利用者端末５が提示した候補品目のいずれかを利用者が選択することによって、利用者端末５から発注情報を受信し、発注コードを付与し、見積額を計算するとともに、当該発注情報を発注品目情報３１５として記憶部３１に書き込む処理を実行する。

　図１６のステップＳ８１では、制御部（ＣＰＵ）３０は、ステップＳ２９で利用者端末５の画面上に提示された複数の候補品目から選択された品目の発注情報を利用者端末５から受信する。受信する発注情報には、品目コード、数量、事業者コードが少なくとも含まれる。

　ステップＳ８２では、制御部（ＣＰＵ）３０は、その利用者端末５からの発注情報の受信が初めてであるか否かを判定する。制御部（ＣＰＵ）３０は、受信した発注情報が初めてである場合（Ｙ）には、ステップＳ８３に進む。制御部（ＣＰＵ）３０は、受信した発注情報が初めてでない場合（Ｎ）には、ステップＳ８７に進む。

　ステップＳ８３では、制御部（ＣＰＵ）３０は、まず受信した利用者端末５の利用者コードを図４の発注品目情報３１５として書き込む。

　つぎにステップＳ８４では、制御部（ＣＰＵ）３０は、さらに発注に固有の発注コードを付与し、発注品目情報３１５として書き込む。

　ステップＳ８５では、制御部（ＣＰＵ）３０は、ステップＳ８１で受信したそれぞれの品目コードに従い品目情報３１４として記憶されている品目コードの価格（単価）を読み出し、この価格（単価）にステップＳ８１で受信したその品目の数量を掛け合わせて品目の価格を計算する。

　つぎにステップＳ８６では、制御部（ＣＰＵ）３０は、ステップＳ８５で計算したこれまでの品目の価格を合計することにより、合計の見積額を算出する。

　そしてステップＳ８７では、制御部（ＣＰＵ）３０は、ステップＳ８１で受信した発注情報の品目コード、数量、事業者コードを発注品目情報３１５として書き込む。

　さらにステップＳ９８では、制御部（ＣＰＵ）３０は、ステップＳ８７で算出した見積額、及び発注品目数を発注品目情報３１５として書き込んだ後、復帰し、図１１のステップＳ３０「発注品目情報提示」に進む。

＜発注品目情報提示＞
　つづいて、図１７及び前述した図８、図１３を用いて、発注品目情報提示手段３０４によるステップＳ３０「発注品目情報提示」の具体的な処理をサブルーチンとして説明する。
　図１７は、本発明の実施例１に係る葬儀自動発注サーバの利用者端末に発注品目情報及び見積額を提示する手順を示すフローチャートである。

　このサブルーチンでは、ステップＳ２９で記憶部３１に書き込んだ発注品目情報３１５に基づく品目に係る品目情報３１４の画像データを読み出して所定の重複順に表示した合成画像を生成し、葬儀当日の葬儀会場をイメージする当該合成画像を利用者に提示するため利用者端末５に送信する処理を実行する。

　図１７のステップＳ１０１では、制御部（ＣＰＵ）３０は、ステップＳ２９で利用者端末５から受信した発注情報に係る品目が表示されるべき合成画像データを決定する。すなわち制御部（ＣＰＵ）３０は、上記合成画像レイヤ設定テーブル（図示せず）に従い、受信した発注情報に係る品目の品目種別コードが関連付けられているレイヤを有する合成画像データを決定する。合成画像データは、例えば、告別式・葬儀会場、通夜・通夜振る舞い会場、火葬場、精進落とし会場などの会場ごとに、それぞれの会場の画像データを最背面のレイヤに関連付けて設定され作成される。図８Ｂの合成画像データでは、例えば、品目種別コード「００５（棺）」がレイヤ３に関連付けて記憶されている。

　ステップＳ１０２では、制御部（ＣＰＵ）３０は、記憶部３１から発注情報に係る品目の品目情報３１４の画像データを読み出し、ステップＳ１０１で決定された合成画像データに関連付けられている画像レイヤの所定領域に表示する。

　ステップＳ１０３では、制御部（ＣＰＵ）３０は、これまで受信した発注情報に係る品目の外観がそれぞれ表示された複数の画像レイヤを所定の重複順に表示した合成画像データを生成し、発注品目情報３１５に書き込む。

　ステップＳ１０４では、制御部（ＣＰＵ）３０は、記憶部３１から発注品目情報３１５の見積額情報を読み出す。
　そしてステップＳ１０５では、制御部（ＣＰＵ）３０は、生成した合成画像データ及び読み出した見積額情報を利用者端末５の利用者に提示するために送信する。
　制御部（ＣＰＵ）３０は、その後復帰し、図１１のステップＳ３１に進む。

＜発注品目情報転送＞
　つぎに、図１８を用いて、発注品目情報転送手段３０５によるステップＳ３３「発注品目情報転送」の具体的な処理をサブルーチンとして説明する。
　図１８は、本発明の実施例１に係る葬儀自動発注サーバの利用者端末から発注された品目を事業者に自動発注する手順を示すフローチャートである。

　このサブルーチンでは、ステップＳ３２で、利用者端末５から発注品目の選択完了ボタンが押下されたことを受けて、記憶部３１に記憶されている発注品目情報３１５に係るそれぞれの品目について発注情報を転送することにより、それらを取り扱う事業者に自動発注する処理を実行する。

　図１８のステップＳ１１１では、制御部（ＣＰＵ）３０は、記憶部３１から発注品目情報３１５の利用者コード、発注コード及び発注品目数ｎを読み出す。

　ステップＳ１１２では、制御部（ＣＰＵ）３０は、発注品目情報３１５として記憶されている品目コード、数量及び事業者コードを記憶部３１から順に読み出す。

　ステップＳ１１３では、制御部（ＣＰＵ）３０は、ステップＳ１１２で読み出した事業者コードに基づき、事業者情報３１２の事業者コードの代表連絡先を記憶部３１から読み出し、ステップＳ１１１で読み出した利用者コード及び発注コードとともに、品目コード及び数量からなる発注情報を当該事業者コードの代表連絡先に転送する。これにより、事業者に自動的に発注したことになる。

　ステップＳ１１４では、制御部（ＣＰＵ）３０は、全ての発注品目について発注情報を転送したか否かを判定し、全ての発注品目について処理が終了していない場合（Ｎ）には、ステップＳ１１２に戻り処理を続け、処理が終了している場合（Ｙ）には、図１１の見積・発注処理に復帰後、さらに図９の全体動作手順に復帰し、ステップＳ７に進む。

＜評価・決済＞
　つぎに、図１９から図２２を用いて、ステップＳ６「評価・決済」の具体的な処理を一連のサブルーチンとして説明する。
　図１９は、本発明の実施例１に係る葬儀自動発注サーバの評価・決済の全体手順を示すフローチャートである。
　これらのサブルーチンでは、利用者端末５から受信した葬儀に用いられた品目の実物に関する実物情報とステップＳ５の見積・発注処理で発注された葬儀品目の仕様情報とを比較評価して評価値データを求め、求めた評価値データに基づいて葬儀品目の価格を変額して決済額を算出し、算出した決算額を利用者端末５の利用者に提示するために利用者端末５に送信し、提示された決算額を見た利用者の利用者端末５から同意情報を受信すると決済を依頼するために金融決済機関サーバ６に決済額情報を送信するまでの処理を実行する。

　図１９のステップＳ１２１では、制御部（ＣＰＵ）３０は、利用者端末５から葬儀当日の葬儀場に納品され葬儀に用いられた品目の実物に関する実物情報を受信し、記憶部３１のＲＡＭに一時記憶する。実物情報は、例えば、利用者端末５で撮影した葬儀会場の全景画像データである。

　ステップＳ１２２では、制御部（ＣＰＵ）３０は、評価手段３０６によって、受信した実物情報と記憶部３１に記憶している品目の仕様情報とを比較評価して評価値データを求める、評価の処理を実行する。評価の具体的な処理については、図２０を用いてサブルーチンとして後述する。評価の処理を実行後は、ステップＳ１２３に進む。

　ステップＳ１２３では、制御部（ＣＰＵ）３０は、利用者端末５に、ステップＳ１２１で受信した実物情報に関するステップＳ１２２での評価で全ての評価を終了するか否かの問い合わせ情報を利用者端末５の利用者に提示するために送信する。

　ステップＳ１２４では、制御部（ＣＰＵ）３０は、利用者端末５から、ステップＳ１２３の評価終了の問合せに対する応答を受信する。

　つぎにステップＳ１２５では、制御部（ＣＰＵ）３０は、ステップＳ１２４で受信した利用者端末５からの応答を判定する。
　制御部（ＣＰＵ）３０は、受信した応答が「評価終了」である場合（Ｙ）には、ステップＳ１２６に進む。制御部（ＣＰＵ）３０は、受信した応答が「評価終了」でない場合（Ｎ）には、図９の全体動作手順に復帰して、ステップＳ７に進む。

　ステップＳ１２６では、制御部（ＣＰＵ）３０は、決済額情報提示手段３０７によって、これまでのステップＳ１２２において評価手段３０６が求めた発注品目に係る評価値データに基づき、記憶部３１から読み出した品目情報３１４の価格情報を変額して決済額を算出し、算出した決算額情報を利用者端末５の利用者に提示するために送信し、利用者端末５から決済額の同意情報を受信すると決済を依頼するために金融決済機関サーバ６に決済処理情報を送信する、決済額情報提示の処理を実行する。決済額情報提示の具体的な処理については、図２１を用いてサブルーチンとして後述する。決済額情報提示の処理を実行後は、図９の全体動作手順に復帰して、ステップＳ７に進む。

＜評価＞
　つぎに、図２０を用いて、評価手段３０６によるステップＳ１２２「評価」の具体的な処理をサブルーチンとして説明する。
　図２０は、本発明の実施例１に係る葬儀自動発注サーバの利用者端末から受信した葬儀会場の全景画像データに基づいて各品目を評価する手順を示すフローチャートである。

　このサブルーチンでは、ステップＳ１２１で利用者端末５から受信した実物情報、例えば利用者端末５で撮影した葬儀会場の全景画像データに基づき、当該全景画像データと、ステップＳ５の見積・発注処理で発注された葬儀品目の仕様情報として記憶部３１に記憶している発注品目情報３１５の合成画像データとを比較評価して評価値データを求める処理を実行する。

　評価値データは、発注品目情報３１５の品目コードに係る品目ごとに求める。評価値データの具体的な求め方は、図８Ｂに示すように品目に関連付けられた合成画像データのレイヤごとに、レイヤに表示されている品目の画像データを参照情報として、葬儀会場の全景画像データから当該品目の実物画像データを抽出して、参照情報の画像データと抽出された画像データとを比較評価することで求める。

　図２０のステップＳ１４１では、制御部（ＣＰＵ）３０は、図９の全体動作手順のステップＳ２で照合が取れた利用者コードに関する利用者情報３１３の発注コードを記憶部３１から読み出し、特定する。

　ステップＳ１４２では、制御部（ＣＰＵ）３０は、利用者端末５から受信した実物情報、すなわち、利用者端末５で撮影した葬儀会場の全景画像データと比較するために、発注品目情報提示手段３０４が生成し、記憶部３１に記憶されている発注品目情報３１５の合成画像データを読み出す。

　ステップＳ１４３では、制御部（ＣＰＵ）３０は、受信した全景画像データと合成画像データのサイズを合わせる。例えば、合成画像データのレイヤ６に表示されている葬儀会場の画像データ（例えば図８のカーテン）と、全景画像データに表示されている葬儀会場の画像（カーテン）の位置と大きさを合わせる。

　ステップＳ１４４では、制御部（ＣＰＵ）３０は、合成画像データの各レイヤに表示されている品目の画像データを用いて、全景画像データから当該品目の画像データを抽出して、その類似度、数量、大きさ等から評価を行うために、まず合成画像データの画像レイヤを最小値に設定し、合成画像レイヤ設定テーブルで合成画像レイヤに関連付けられた品目種別コードと、ステップＳ１４１で読み出した発注コードに基づいて、記憶部３１に記憶している発注品目情報３１５の品目コードを特定し、読み出す。例えば、図８の画像レイヤ１は焼香用具が関連付けられており、品目種別コードは品目種別テーブル３１１Ｅから「０１０」となる。したがって上位３桁が「０１０」である発注品目情報３１５の品目コードを検索し、特定すればよい。

　ステップＳ１４５では、制御部（ＣＰＵ）３０は、合成画像レイヤに表示されている品目の画像領域を抽出領域として、全景画像データの抽出領域に相当する領域から当該品目の実物画像データを抽出する。
　具体的には、例えば、一般にＣＢＩＲ（Ｃｏｎｔｅｎｔ－Ｂａｓｅｄ　Ｉｍａｇｅ　Ｒｅｔｒｉｅｖａｌ）という色、形状、テクスチャ等を特徴量として用いる類似画像検索手法を利用する。この分野の画像処理ライブラリとしては、例えば、ＯｐｅｎＣＶ（Ｏｐｅｎ　Ｓｏｕｒｃｅ　Ｃｏｍｐｕｔｅｒ　Ｖｉｓｉｏｎ　Ｌｉｂｒａｒｙ）が知られている。

　（１）まず、合成画像レイヤに表示された品目の画像データを二値化して、その輪郭線データを抽出する。例えば、ＯｐｅｎＣＶでは「ｆｉｎｄＣｏｎｔｏｕｒｓ」メソッドを用いる。そして、抽出された輪郭線データを包含する矩形領域を求める。例えば、ＯｐｅｎＣＶでは「ｂｏｕｎｄｉｎｇＲｅｃｔ」メソッドを用いる。

　（２）（１）で求めた矩形領域に対応する全景画像データの部分領域を二値化し、（１）で二値化した合成画像レイヤの画像データとテンプレートマッチング法を用いて類似度を算出し、類似度が最も大きい位置を求める。類似度の計算方法には、「画素値の差分の二乗和（ＳＳＤ；Ｓｕｍ　ｏｆ　Ｓｑｕａｒｅｄ　Ｄｉｆｆｅｒｅｎｃｅ）」、「画素値の差分の絶対値の和（ＳＡＤ；Ｓｕｍ　ｏｆ　Ａｂｓｏｌｕｔｅ　Ｄｉｆｆｅｒｅｎｃｅ）」、「正規化相互相関（ＮＣＣ；Ｎｏｒｍａｌｉｚｅｄ　Ｃｒｏｓｓ　Ｃｏｒｒｅｌａｔｉｏｎ）」等がある。例えば、ＯｐｅｎＣＶでは、「ＭａｔｃｈＴｅｍｐｌａｔｅ」メソッド、「ＭｉｎＭａｘＬｏｃ」メソッドを用いる。

　（３）（２）で二値化した全景画像データの部分領域の輪郭線を抽出し、（２）で求めた類似度の最も大きい位置を含む輪郭線を求める。
　（４）（３）で求めた輪郭線を有する品目の実物画像データを元の全景画像データから抽出する。例えば、ＯｐｅｎＣＶでは、「ｉｍｄｅｃｏｄｅ」を用いる。

　ステップＳ１４６では、制御部（ＣＰＵ）３０は、ステップＳ１４５で抽出した、合成画像レイヤの画像データと二値化された輪郭線データ、及び全景画像データから抽出された品目の実物画像データと二値化された輪郭線データに基づいて、類似度、品目の数量及び大きさの比率を計算する。

　制御部（ＣＰＵ）３０は、例えば、特徴量を形状、すなわち二値化された輪郭線データ同士の類似度を計算する。例えば、ＯｐｅｎＣＶでは「ｍａｔｃｈＳｈａｐｅｓ」メソッドを用いる。このメソッドは、０～１の出力値を算出し、０に近い値ほど２つの輪郭線データが類似していることを意味する。したがって、例えば算出した出力値を１から減算した値を類似度とすればよい。また、１／（１＋算出した出力値）を類似度として求めてもよい。

　また制御部（ＣＰＵ）３０は、例えば、特徴量を色、すなわち合成画像レイヤの画像データと全景画像データから抽出された品目の画像データとのヒストグラムの類似度を計算しても良い。例えば、ＯｐｅｎＣＶでは「ｃｏｍｐａｒｅＨｉｓｔ」メソッドを用いる。このメソッドでは、両画像を一度ＨＳＶ形式に変換後、両画像を色相（Ｈｕｅ）、彩度（Ｓａｔｕｒａｔｉｏｎ）、明度（Ｖａｌｕｅ）チャンネルごとにヒストグラムを計算し、それぞれの類似度の平均値を最終的な類似度として、０～１の値を出力する。１に近いほど両画像データが類似していることを意味する。

　なお例えば、両画像の輪郭線データを抽出する際に用いたＯｐｅｎＣＶの「ｆｉｎｄＣｏｎｔｏｕｒｓ」メソッドでは、例えば複数の輪郭線が存在する場合、ラベリング（輪郭線数）や輪郭線座標を出力する。したがって、制御部（ＣＰＵ）３０は、これらの情報から両画像データに係る品目の数量及び大きさ（輪郭線で囲まれた面積）を算出し、数量の比率及び大きさの比率を計算することができる。

　ステップＳ１４７では、制御部（ＣＰＵ）３０は、ステップＳ１４６で算出した、類似度、品目の数量や大きさの比率に基づき評価値データを決定する。そして、制御部（ＣＰＵ）３０は、ステップＳ２で照合が取れた利用者コード、ステップＳ１４１で読み出した利用者情報３１３の発注コード、ステップＳ１４５で特定した発注品目情報３１５の品目コードとともに、当該品目の評価値データを評価情報３１６として記憶部３１に書き込む。

　制御部（ＣＰＵ）３０は、具体的な評価値データの決定方法として、例えば、以下のように評価値データを決定してもよい。すなわち、品目の形状、色、数量、大きさの観点から、発注した品目の仕様と実際に用いられた品目とを比較評価する。また、決算額が見積額を越えて利用者に不測の出費を強いることがないように、評価値データは、原則０より大きく１以下とする。
　評価値データ＝形状による類似度×色による類似度
　　　　　　　　×数量の比率×大きさの比率　　　　　　　　　（１）
　０＜評価値データ≦１　　　　　　　　　　　　　　　　　　　（２）

　また、制御部（ＣＰＵ）３０は、上記４つのパラメータの最小値又は平均値を評価値データとしてもよい。形状や色による類似度は前述したように１以下であり、数量や大きさの比率が１を超えることがあっても、平均値を取れば、１を超えることはほとんどないと考えられるからである。

　ステップＳ１４８では、制御部（ＣＰＵ）３０は、合成画像の画像レイヤに表示されている全ての品目について評価値データを求めたかを判定すし、全ての画像レイヤについて処理が終了していない場合（Ｎ）には、ステップＳ１４４に戻り処理を続け、全ての画像レイヤについて処理が終了している場合（Ｙ）には、復帰し、図１９のステップＳ１２３に進む。
　なお、評価の具体的な処理の説明では、図８の葬儀・告別式会場の合成画像データに基づき説明したが、通夜・通夜振る舞い会場、火葬場、精進落とし会場の各合成画像データについても必要に応じて繰り返し同様な処理を行う。

　＜決済額情報提示＞
　つぎに、図２１及び図２２を用いて、決済額情報提示手段３０７によるステップＳ１２６「決済額情報提示」の具体的な処理をサブルーチンとして説明する。
　図２１は、本発明の実施例１に係る葬儀自動発注サーバの決済手順を示すフローチャートである。
　図２２は、本発明の実施例１に係る葬儀自動発注サーバが利用者端末に提示する決済額を提示する画面表示例である。

　このサブルーチンでは、ステップＳ１２５で利用者端末５から受信した応答が「評価終了」であると判定した場合（Ｙ）、求めた評価値データに基づいて葬儀品目の価格を変額して決済額を算出し、算出した決算額を利用者端末５の利用者に提示するために利用者端末５に送信し、提示された決算額を見た利用者の利用者端末５から同意情報を受信すると決済を依頼するために金融決済機関サーバ６に決済額情報を送信する処理を実行する。

　葬儀品目の価格の変額は、発注品目情報３１５の品目コードに係る品目ごとに求める。決算額の具体的な算出は、発注品目情報３１５の品目コードに係る品目ごとに求めた価格の変額に、当該品目コードに関連付けられている発注品目情報３１５の数量を掛け合わせた額を、発注品目情報３１５の発注品目数ｎにわたり繰り返し合算することで算出する。

　図２１のステップＳ１６１では、制御部（ＣＰＵ）３０は、図９の全体動作手順のステップＳ２で照合が取れた利用者コードに関する利用者情報３１３の発注コードを記憶部３１から読み出し、特定する。

　ステップＳ１６２では、制御部（ＣＰＵ）３０は、利用者コード及びステップＳ１６１で読み出した発注コードに基づいて、記憶部３１から発注品目情報３１５の発注品目数ｎを読み出す。

　ステップＳ１６３では、制御部（ＣＰＵ）３０は、まず発注品目数カウンタｋを「１」に設定後、記憶部３１から評価情報３１６のｋ番目の品目コードＩ（ｋ）及びその評価値データＨ（ｋ）を読み出す。

　ステップＳ１６４では、制御部（ＣＰＵ）３０は、ステップＳ１６５で読み出した品目コードＩ（ｋ）に基づき、記憶部３１から当該品目コードに関連付けられた品目情報３１４の価格（単価）Ｃ（ｋ）を読み出す。

　ステップＳ１６５では、制御部（ＣＰＵ）３０は、例えば、以下のように品目コードＩ（ｋ）の価格を変額する。
　品目コードＩ（ｋ）の変額Ｖ（ｋ）＝価格（単価）Ｃ（ｋ）
　　　　　　　　　　　　　　　　　　×評価値データＨ（ｋ）　（３）

　ステップＳ１６６では、制御部（ＣＰＵ）３０は、ステップＳ１６５で読み出した品目コードＩ（ｋ）に基づき、記憶部３１から発注品目情報３１５の当該品目コードの数量Ｑ（ｋ）を読み出す。

　ステップＳ１６７では、制御部（ＣＰＵ）３０は、ステップＳ１６７で計算した品目コードＩ（ｋ）の変額Ｖ（ｋ）及びステップＳ１６８で読み出したその数量Ｑ（ｋ）に基づいて、例えば、以下のように決済額Ｓを算出する。
　決算額Ｓ＝Ｖ（ｋ）×Ｑ（ｋ）＋これまでの決算額Ｓ　　　　　（４）

　ステップＳ１６８では、全ての品目コードＩ（ｎ）についての決算額が求められたか否かを判定し、全ての品目コードＩ（ｎ）についての決算額が求められていない場合（Ｎ）には、ステップＳ１６３に戻り処理を続け全ての品目コードＩ（ｎ）についての決算額が求められている場合（Ｙ）には、ステップＳ１６９に進む。

　ステップＳ１６９では、制御部（ＣＰＵ）３０は、例えば、決済額Ｓとその内訳である品目コードＩ（ｋ）ごとの評価値データＨ（ｋ）、変額データＶ（ｋ）及び数量データＱ（ｋ）を含む決済額情報を利用者端末５に送信し、利用者端末５は、利用者に例えば図２２の画面表示例を提示する。

　ステップＳ１７０では、制御部（ＣＰＵ）３０は、利用者端末５からステップＳ１６９で提示した決済額情報で同意する旨の情報を受信する。例えば制御部（ＣＰＵ）３０は、ステップＳ１６９で利用者端末５が利用者に提示した図２２の画面表示例において、画面下の「決済同意」ボタンを利用者がクリックすることによって利用者端末５から送信される情報を受信する。

　そしてステップＳ１７１では、制御部（ＣＰＵ）３０は、図９の全体動作手順のステップＳ２で照合が取れた利用者コードに関する利用者情報３１３の支払い情報を読み出し、ステップＳ１７２で利用者端末５に送信した決済額情報とともに金融決済機関サーバ６に送信する。その後制御部（ＣＰＵ）３０は、図１９の評価・決済処理に復帰し、さらに図９の全体動作手順に復帰して、ステップＳ７に進む。
　以上で、本発明の実施例１に係る葬儀自動発注サーバに関する一連の手順の説明を終了する。

　このように、本発明の実施例１に係る葬儀自動発注サーバでは、上記構成を採用することで、利用者の希望通りの葬儀スタイルで納得感の得られる葬儀を支援することができる。また本発明の実施例１に係る葬儀自動発注サーバでは、上記構成を採用することで、利用者が葬儀当日に用いられた葬儀品目の一つ一つを撮影する余裕がない場合でも、利用者が撮影した葬儀会場の全景画像データによって葬儀品目の一つ一つを客観的に評価して決済額に反映することから、利用者が納得感の得られる葬儀を支援することができる。

　つぎに、本発明の実施例２に係る葬儀自動発注サーバ３について、図２３を用いて説明する。なお、本実施例の葬儀自動発注サーバの基本的な機能構成及び処理手順は、第１の実施例に示されるものと同一であるため、それらについての説明は省略する。
　図２３は、本発明の実施例２に係る葬儀自動発注サーバの利用者端末から受信した個別品目の画像データに基づいて評価する手順を示すフローチャートである。
　図２３にサブルーチンとして示す「評価」は、図２０に示す「評価」が利用者端末５から受信した葬儀会場の全景画像データに基づいて各品目を評価するのに対し、利用者端末５から受信した個別の品目に関する画像データに基づいて評価する点において差異がある。

　図１９のステップＳ１２１で利用者端末５から受信した実物情報、例えば利用者端末５で撮影した個別の品目に関する画像データに基づき、ステップＳ１２２で、制御部（ＣＰＵ）３０は評価手段３０６によって、受信した実物情報と記憶部３１に記憶している品目の仕様情報とを比較評価して評価値データを求める、評価の処理を実行する。

　評価値データは、発注品目情報３１５の品目コードに係る品目ごとに求める。評価値データの具体的な求め方は、発注品目情報３１５の発注品目数ｎにわたり、発注品目情報３１５の品目コードに関連付けられた品目情報３１４の仕様情報に含まれる画像データと、受信した実物情報、すなわち個別の品目に関する画像データとを比較評価して類似度を求め、類似度の最も高いときの発注品目情報３１５の品目コードに係る品目を受信した画像データに関する品目であると特定し、特定した品目に係る品目コードについて、最も高い類似度に基づき求める。

　図２３のステップＳ１８１では、制御部（ＣＰＵ）３０は、図９の全体動作手順のステップＳ２で照合が取れた利用者コードに関する利用者情報３１３の発注コードを読み出し、特定する。

　ステップＳ１８２では、制御部（ＣＰＵ）３０は、利用者コード及びステップＳ１８１で読み出した発注コードに基づいて、記憶部３１から発注品目情報３１５の発注品目数ｎを読み出す。

　ステップＳ１８３では、制御部（ＣＰＵ）３０は、まず発注品目数カウンタを「１」に設定後、記憶部３１から発注品目情報３１５の品目コードを読み出す。そして制御部（ＣＰＵ）３０は、読み出した当該品目コードに基づいて記憶部３１から品目情報３１４の仕様情報に含まれる当該品目に関する画像データを読み出す。

　ステップＳ１８４では、制御部（ＣＰＵ）３０は、図１９のステップＳ１２１で利用者端末５から受信した利用者端末５で撮影した品目に関する画像データと、ステップＳ１８３で読み出した品目情報３１４の当該品目に関する画像データとのサイズ合わせを行う。
　具体的には、制御部（ＣＰＵ）３０は、２つの画像データを、それぞれ二値化して、その輪郭線データを抽出する。そして制御部（ＣＰＵ）３０は、それぞれの画像データについて抽出された輪郭線データを包含する矩形領域を求める。制御部（ＣＰＵ）３０は、求めた２つの矩形領域のサイズを合わせることにより、２つの画像データのサイズを合わせる。

　ステップＳ１８５では、制御部（ＣＰＵ）３０は、２つの画像データの類似度及び品目の数量を算出する。例えば、制御部（ＣＰＵ）３０は、ステップＳ１８４でサイズを補正後の２つ画像の形状を特徴量として、それぞれを二値化して抽出した輪郭線データ同士の類似度を計算する。制御部（ＣＰＵ）３０は、例えば、ステップＳ１８４でサイズを補正後の２つ画像の色を特徴量として、それぞれの画像データのヒストグラムの類似度を計算してもよい。
　また制御部（ＣＰＵ）３０は、形状を特徴量として類似度を算出するために画像を二値化して輪郭線データを抽出する際に、例えば、ＯｐｅｎＣＶの「ｆｉｎｄＣｏｎｔｏｕｒｓ」メソッドを用いることで出力されるラベリング（輪郭線数）から品目の数量を算出する。なお、品目の大きさについては、ステップＳ１８４で画像データのサイズ合わせを行っていることから考慮しないことにする。
　類似度は、ステップＳ１８３で現在の発注品目数カウンタに従って記憶部３１から読み出された発注品目情報３１５の品目コードに係る品目と、ステップＳ１２１で利用者端末５から受信した画像データに係る品目とが一致する場合に最も高くなる。

　ステップＳ１８６では、制御部（ＣＰＵ）３０は、発注品目情報３１５の全ての発注品目にわたり、比較評価を実施した否かを判定し、全ての発注品目にわたる評価を実施していない場合（Ｎ）には、ステップＳ１８３に戻り処理を続け、全ての発注品目にわたる評価を終了している場合（Ｙ）には、ステップＳ１８７に進む。

　ステップＳ１８７では、制御部（ＣＰＵ）３０は、ステップＳ１８５で算出した類似度が最も高いときの発注品目数カウンタに対応する品目コードを発注品目情報３１５から読み出し、特定する。

　ステップＳ１８８では、制御部（ＣＰＵ）３０は、ステップＳ１８５で算出した、類似度が最も高いときの類似度及び品目の数量の比率に基づき評価値データを決定する。そして、制御部（ＣＰＵ）３０は、ステップＳ２で照合が取れた利用者コード、ステップＳ１８１で読み出した利用者情報３１３の発注コード、ステップＳ１８７で特定した品目コードとともに、当該品目の評価値データを評価情報３１６として記憶部３１に書き込む。その後制御部（ＣＰＵ）３０は、復帰し、図１９のステップＳ１２３に進む。

　制御部（ＣＰＵ）３０は、具体的な評価値データの決定方法として、例えば、以下のように評価値データを決定する。
　評価値データ＝形状による類似度×色による類似度×数量の比率　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（５）
　０＜評価値データ≦１　　　　　　　　　　　　　　　　　　　（６）
　また、制御部（ＣＰＵ）３０は、上記３つのパラメータの最小値又は平均値を評価値データとしてもよい。

　このように、本発明の実施例２に係る葬儀自動発注サーバでは、上記構成を採用することにより、利用者自身が撮影した実物の画像データによって客観的に評価して決済額に反映することから、実施例１と同様に、利用者が納得感の得られる葬儀を支援することができる。

　以上、本発明の葬儀自動発注サーバについて、具体的な実施の形態を示して説明したが、本発明はこれらに限定されるものではない。当業者であれば、本発明の要旨を逸脱しない範囲内において、上記各実施形態又は他の実施形態に係る発明の構成及び機能に様々な変更・改良を加えることが可能である。

＜変形例＞
　例えば、本発明の実施例２に係る葬儀自動発注サーバでは、図１９のステップＳ１２１で利用者端末５から受信した実物情報が、個別品目の画像データの代わりに、例えば、葬儀当日に用いられた品目の実物に貼付されたＲＦＩＤ等の電子タグ又はＱＲコード（登録商標）等の情報コードから利用者端末５が読み出したテキストデータであるとし、図２３でサブルーチンとして説明した「評価」が利用者端末５から受信したテキストデータに基づき類似度を求め、それに従い評価値を決定する構成とすることもできる。
　ＱＲコード（登録商標）は、自動車部品工場や配送センタ等での利用を念頭に、バーコードより多くの情報を盛り込める情報コードとして開発され、縦横に情報を持つため格納できる情報量が多く、数字だけでなく英字や漢字など多言語のデータに対応でき、漢字やかな文字の場合、最大１８１７文字を格納できる。また、ＲＦＩＤは、メモリが内蔵されたタグで情報コード以上の情報量を格納することができ、一台のリーダで一度に複数のＲＦＩＤの情報を読み取り可能なことから、図書館の貸出管理やコンビニの物流・在庫管理に使用されつつある。
　したがって、これらの電子タグ又は情報コードに、例えば品目名、等級、品目の色、大きさ、材質、数量等の細かな仕様情報をテキストデータとして記憶しておくことができる。
　以下に、相違する手順についてのみ具体的に説明する。

　図２３のステップＳ１８３では、制御部（ＣＰＵ）３０は、発注品目数カウンタに従って記憶部３１から発注品目情報３１５の品目コードを読み出す。そして制御部（ＣＰＵ）３０は、読み出した当該品目コードに基づいて記憶部３１から品目情報３１４の仕様情報に含まれる当該品目に関するテキストデータを読み出す。

　ステップＳ１８４では、制御部（ＣＰＵ）３０は、図１９のステップＳ１２１で利用者端末５から受信した実物に貼付された電子タグ又は情報コードから利用者端末５が読み出したテキストデータと、ステップＳ１８４で読み出した品目情報３１４の品目に関するテキストデータを形態素解析により単語を抽出し、それぞれの単語の集合、例えば集合Ａと集合Ｂを求める。

　ステップＳ１８５では、制御部（ＣＰＵ）３０は、集合Ａと集合Ｂに含まれるすべての単語の数のうち、共通して含まれている単語の数の割合を類似度として算出する。例えば、以下の式で定義されるＪａｃｃａｒｄ係数Ｊ（Ａ，Ｂ）を用いる。
　Ｊ（Ａ，Ｂ）＝｜Ａ∩Ｂ｜／｜Ａ∪Ｂ｜　　　　　　　　　　　（７）
　Ｊ（Ａ，Ｂ）は、０～１の値を出力し、共通する単語の数が多いほど１に近くなる。

　ステップＳ１８８では、制御部（ＣＰＵ）３０は、例えば、Ｊａｃｃａｒｄ係数Ｊ（Ａ，Ｂ）をそのまま評価値データとして決定する。

　このように、本発明の実施例２の変形例に係る葬儀自動発注サーバでは、上記構成を採用することにより、利用者自身が取得した実物に貼付されたタグ情報又は情報コードから読み出したテキストデータによって客観的に評価して決済額に反映することから、利用者が納得感の得られる葬儀を支援することができる。

　また、本発明の実施例２に係る葬儀自動発注サーバでは、図１９のステップＳ１２１で受信した実物情報を利用者端末５からとする代わりに、例えば、発注品目を取り扱う事業者端末４からの納品情報とする構成とすることもできる。例えば、納品情報に納品した実物の画像データや納品仕様に関するテキストデータ、数量等が含まれていれば、制御部（ＣＰＵ）３０は、それらを用いて、評価の処理を実行することができる。これにより、利用者が葬儀の進行に追われ、葬儀当日の品目の撮影やタグ情報等を取得する余裕が全くない場合でも、事業者の納品情報によって客観的に評価して決済額に反映することから、利用者が納得感の得られる葬儀を支援することができる。

　加えて、本発明の実施例に係る葬儀自動発注サーバでは、前述した評価値データについて、複数の評価値データに基づき最終的な評価値データを決定してもよい。
　例えば、全景画像データから算出した評価値データと、個別品目の画像データから算出した評価値データとを用いて、両データの最小値又は平均値を評価値データとしてもよい。また、全景画像データ又は個別の画像データから算出した評価値データと、葬儀に用いられた品目の実物に貼付された電子タグ又は情報コードから読み出されたテキストデータから算出した評価値データとを用いて、両データの最小値又は平均値を評価値データとしてもよい。さらに、これらの画像データ及びテキストデータから算出した評価値データと、事業者の納品情報から算出した評価値データとの最小値又は平均値を評価値データとしてもよい。

　なお、本発明の実施例に係る葬儀自動発注サーバでは、利用者端末５に提示する画面表示例は、上下に配置された縦長な表示領域のレイアウトになっているが、左右に配置された横長な表示領域のレイアウトになってもよい。

　本発明の葬儀自動発注サーバは、コンピュータを葬儀自動発注サーバとして機能させるためのプログラムでも実現される。このプログラムは、コンピュータで読み取り可能な記録媒体に格納されていてもよい。
　このプログラムを記録した記録媒体は、図２に示される葬儀自動発注サーバのＲＯＭそのものであってもよいし、また、外部記憶装置としてＣＤ－ＲＯＭドライブ等のプログラム読取装置が設けられ、そこに記録媒体を挿入することで読み取り可能なＣＤ－ＲＯＭ等であってもよい。
　また、上記記録媒体は、磁気テープ、カセットテープ、フレキシブルディスク、ハードディスク、ＭＯ／ＭＤ／ＤＶＤ等、又は半導体メモリであってもよい。

　本明細書で引用したすべての刊行物、特許及び特許出願は、そのまま参考として、ここにとり入れるものとする。
　また、明細書、特許請求の範囲及び図面を含む２０１９年９月１１日に出願の日本国特許出願２０１９－１６５１３６の開示は、そのまま参考として、ここにとり入れるものとする。

１　　葬儀自動発注システム
２　　インターネット
３　　葬儀自動発注サーバ
４　　事業者端末
４ａ　　事業者端末
４ｂ　　事業者端末
４ｃ　　事業者端末
４ｄ　　事業者端末
４ｅ　　事業者端末
４ｆ　　事業者端末
４ｇ　　事業者端末
４ｈ　　事業者端末
４ｉ　　事業者端末
５　　利用者端末
６　　金融決済機関サーバ
３０　　制御部（ＣＰＵ）
３１　　記憶部
３２　　バスライン
３３　　入力部
３４　　表示部
３５　　通信部
３００　　認証手段
３０１　　品目情報書込手段
３０２　　品目情報提示手段
３０３　　発注品目情報書込手段
３０４　　発注品目情報提示手段
３０５　　発注品目情報転送手段
３０６　　評価手段
３０７　　決済額情報提示手段
３１０　　プログラム格納部
３１１　　各種テーブル
３１２　　事業者情報
３１３　　利用者情報
３１４　　品目情報
３１５　　発注品目情報
３１６　　評価情報
３１２１　　事業者コード
３１３１　　利用者コード
３１４１　　品目コード
３１１Ａ　　地域テーブル
３１１Ｂ　　区域テーブル
３１１Ｃ　　業者種別テーブル
３１１Ｄ　　規模テーブル
３１１Ｅ　　品目種別テーブル
３１１Ｆ　　ランクテーブル
３１１Ｇ　　設定条件テーブル
３１１Ｈ　　品目設定テーブル

Claims

　葬儀に用いる品目の仕様情報及び価格情報を記憶する記憶手段と、
　利用者が発注した葬儀に用いる品目の発注情報を利用者端末から受信する受信手段と、
　葬儀当日の葬儀場に納品され葬儀に用いられた品目の実物に関する実物情報を、前記受信手段によって受信された前記発注情報に係る品目の前記記憶手段から読み出された仕様情報と比較して評価した評価情報を得る評価手段と、
　前記発注情報に係る品目の前記記憶手段から読み出された価格情報を、前記評価手段によって得られた前記評価情報に基づいて変額した価格を決済額情報として前記利用者端末に送信し、提示する情報提示手段と、
を備えることを特徴とする葬儀自動発注サーバ。
　前記葬儀に用いる品目には、葬儀場の会場が含まれることを特徴とする請求項１記載の葬儀自動発注サーバ。
　前記仕様情報には画像データが含まれ、
　前記実物情報は、前記受信手段によって前記利用者端末から受信された前記実物の画像データを含み、
　前記評価手段は、前記実物の画像データを、前記仕様情報に含まれる画像データと比較して評価した評価情報を得ること、
を特徴とする請求項１又は２記載の葬儀自動発注サーバ。
　前記仕様情報にはテキストデータが含まれ、
　前記実物情報は、前記受信手段によって前記利用者端末から受信された前記実物に貼付された電子タグ又は情報コードから読み出されたテキストデータを含み、
　前記評価手段は、前記実物に貼付された電子タグ又は情報コードから読み出されたテキストデータを、前記仕様情報に含まれるテキストデータと比較して評価した評価情報を得ること、
を特徴とする請求項１又は２記載の葬儀自動発注サーバ。
　前記実物情報は、前記受信手段によって前記発注品目を取り扱う事業者端末から受信した納品情報を含み、
　前記評価手段は、前記納品情報を、前記仕様情報と比較して評価した評価情報を得ること、
を特徴とする請求項１又は２記載の葬儀自動発注サーバ。
　前記仕様情報に含まれる画像データには、複数の前記発注品目の仕様情報に含まれる画像データを重畳して合成した合成画像データが含まれ、
　前記実物の画像データには、前記受信手段によって前記利用者端末から受信された前記葬儀場の会場を含む全景画像データを含むこと、
を特徴とする請求項３記載の葬儀自動発注サーバ。