知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-04-26
(45)【発行日】2023-05-09
(54)【発明の名称】祭祀方法、コンピュータプログラム、及び祭祀審査装置
(51)【国際特許分類】
G06Q 50/10 20120101AFI20230427BHJP
【ＦＩ】
G06Q50/10
【請求項の数】
11
(21)【出願番号】P 2020092402
(22)【出願日】2020-05-27
(62)【分割の表示】P 2019064335の分割
【原出願日】2019-03-28
(65)【公開番号】P2020166872
(43)【公開日】2020-10-08
【審査請求日】2022-01-21
(73)【特許権者】
【識別番号】519112368
【氏名又は名称】河合 重政
(74)【代理人】
【識別番号】100114557
【弁理士】
【氏名又は名称】河野 英仁
(74)【代理人】
【識別番号】100078868
【弁理士】
【氏名又は名称】河野 登夫
(72)【発明者】
【氏名】河合 重政
【審査官】田上 隆一
(56)【参考文献】
【文献】特開２００２－０７３７９８（ＪＰ，Ａ）
【文献】特開２００２－２０７８３５（ＪＰ，Ａ）
【文献】特開２００３－３１６９３３（ＪＰ，Ａ）
【文献】特開２０１８－０３６５３６（ＪＰ，Ａ）
【文献】特開２０１０－１６６９９０（ＪＰ，Ａ）
【文献】国際公開第２０１８／１８６３９１（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
コンピュータに、祭祀対象の情報を取得し、
祭祀者の情報を取得し、
祭祀中の前記祭祀者をカメラを通じて撮像した映像を取得し、
祭祀中の祭祀者を撮像した映像を入力した場合に、祭祀の正否の判定を示す正否情報を
出力する学習モデルに、祭祀中の前記祭祀者を前記カメラを通じて撮像した映像を入力し、
前記学習モデルから出力された正否情報、取得した前記祭祀対象の情報、及び、前記祭祀者の情報に基づいて、前記祭祀の正否を判定し、
前記学習モデルにより正と判定された場合に複数の検証者による前記祭祀の検証結果を、前記検証者の端末装置からそれぞれ受け付ける
処理を実行させる祭祀方法。
【請求項2】
正と判定した場合に、前記祭祀者に対する前記祭祀の費用の支払い処理を実行する、請求項１に記載の祭祀方法。
【請求項3】
祭祀中の前記祭祀者の音声がマイクを通じて録音された前記祭祀者の音声を取得し、前記祭祀者の音声を受け付けて、祭祀の正否を出力する学習モデルに、取得した前記音声を入力し、前記祭祀の正否を出力して、正否を判定する、請求項１に記載の祭祀方法。
【請求項4】
前記学習モデルにより正と判定された場合に検証者による前記祭祀の検証結果を、前記検証者の端末装置から受け付け、前記検証結果により正と判定された場合に、前記祭祀は正であると判定する、請求項２又は３に記載の祭祀方法。
【請求項5】
検証者によって検証された前記支払い処理を記載した明細書の確認結果を受信する、請求項２に記載の祭祀方法。
【請求項6】
祭祀が正と判定された場合に、前記祭祀者に前記祭祀の費用を支払うスマートコントラクトをブロックチェーンに記録する、請求項１から５までのいずれか１項に記載の祭祀方法。
【請求項7】
前記祭祀が正と判定された情報を前記ブロックチェーンに送信し、前記スマートコントラクトの処理を実行する、請求項６に記載の祭祀方法。
【請求項8】
前記情報は、前記支払いを記載した明細書が正と判定されたという情報を含む、請求項７に記載の祭祀方法。
【請求項9】
前記祭祀対象を管理する端末のウォレットアドレスから、スマートコントラクトアドレス宛として祭祀に対するデポジットとなる仮想通貨量を含むトランザクションをブロックチェーンへ送信し、前記祭祀が終了し、かつ、正と判定された場合に、前記スマートコントラクトの履行に伴い前記祭祀者のウォレットアドレス宛として前記デポジットとなった仮想通貨量の一部の仮想通貨量を含むトランザクションをブロックチェーンへ送信する
請求項７または８に記載の祭祀方法。
【請求項10】
コンピュータに、祭祀対象の情報を取得し、
祭祀者の情報を取得し、
祭祀中の前記祭祀者をカメラを通じて撮像した映像を取得し、
祭祀中の祭祀者を撮像した映像を入力した場合に、祭祀の正否の判定を示す正否情報を出力する学習モデルに、祭祀中の前記祭祀者を前記カメラを通じて撮像した映像を入力し、
前記学習モデルから出力された正否情報、取得した前記祭祀対象の情報、及び、前記祭祀者の情報に基づいて、前記祭祀の正否を判定し、
前記学習モデルにより正と判定された場合に複数の検証者による前記祭祀の検証結果を、前記検証者の端末装置からそれぞれ受け付ける
処理を実行させるコンピュータプログラム。
【請求項11】
祭祀対象の情報を取得する取得部と、祭祀者の情報を取得する祭祀者情報取得部と、
祭祀中の前記祭祀者をカメラを通じて撮像した映像を取得する映像取得部と、
祭祀中の祭祀者を撮像した映像を入力した場合に、祭祀の正否の判定を示す正否情報を出力する学習モデルと、
前記祭祀中の前記祭祀者を前記カメラを通じて撮像した映像を前記学習モデルに入力する入力部と、
前記学習モデルから出力された正否情報、取得した前記祭祀対象の情報、及び、前記祭祀者の情報に基づいて、前記祭祀の正否を判定する判定部と、
前記学習モデルにより正と判定された場合に複数の検証者による前記祭祀の検証結果を、前記検証者の端末装置からそれぞれ受け付ける受付部と
を備える祭祀審査装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、祭祀方法、コンピュータプログラム、及び祭祀審査装置に関する。
【背景技術】
【0002】
家族がいなかったり、子供が外国に住んでいる等して、自分の死後に供養したり墓守をする者がいないことを不安視している者は多い。
契約者の死後、葬儀までの行事を葬儀社等が執り行う契約は存在する。
そして、特許文献１には、檀家に代わって仏教行事を管理・執行し、無縁墓地化した場合に３２年後に墓地を明け渡し、無縁塔等に移して永代供養をしてもらうことを生前予約する檀家管理および墓地・墓石管理システムの発明が開示されている。
契約者の死後、葬儀までの行事を葬儀社等が執り行う契約は存在する。
そして、特許文献１には、檀家に代わって仏教行事を管理・執行し、無縁墓地化した場合に３２年後に墓地を明け渡し、無縁塔等に移して永代供養をしてもらうことを生前予約する檀家管理および墓地・墓石管理システムの発明が開示されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２００１－２３６４２５号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献１に係る発明の場合、保険会社が被供養者から保険料を受け取り、寺院等の宗教法人が檀家に代わって仏教行事を管理・執行するものであるが、「死人に口なし」であり、僧が、種類に沿った内容の供養を時間通りに、居眠り等をすることなく、正しく行ったか否かをチェックすることはできないという問題がある。
【0005】
本発明は斯かる事情に鑑みてなされたものであり、正しい祭祀者により、正しい祭祀対者に対し、正しく祭祀が行われたか否かを良好に判定できる祭祀方法、コンピュータプログラム、及び祭祀審査装置を提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明の一態様に係る祭祀方法は、コンピュータに、祭祀対象の情報を取得し、祭祀者の情報を取得し、祭祀中の前記祭祀者をカメラを通じて撮像した映像を取得し、祭祀中の祭祀者を撮像した映像を入力した場合に、祭祀の正否の判定を示す正否情報を出力する学習モデルに、祭祀中の前記祭祀者を前記カメラを通じて撮像した映像を入力し、前記学習モデルから出力された正否情報、取得した前記祭祀対象の情報、及び、前記祭祀者の情報に基づいて、前記祭祀の正否を判定し、前記学習モデルにより正と判定された場合に複数の検証者による前記祭祀の検証結果を、前記検証者の端末装置からそれぞれ受け付ける処理を実行させる。
【0007】
上記構成によれば、取得した祭祀対象（被祭祀者）及び祭祀者の情報、並びに祭祀状況に基づいて祭祀の正否を判定するので、正しい祭祀者により、正しい祭祀対象者に対し、居眠り、曖昧、でたらめ、中抜き等の異常所作がなく、正しく祭祀が行われたか否かを良好に判定できる。
【0008】
上述の祭祀方法において、正と判定した場合に、前記祭祀者に対する前記祭祀の費用の支払い処理を実行してもよい。
【0009】
上述の祭祀方法において、祭祀中の前記祭祀者の音声がマイクを通じて録音された前記祭祀者の音声を取得し、前記祭祀者の音声を受け付けて、祭祀の正否を出力する学習モデルに、取得した前記音声を入力し、前記祭祀の正否を出力して、正否を判定してもよい。
【0010】
上記構成によれば、正しく祭祀が行われたか否かを音声に基づいて自動的に精度良く判定できる。
【0011】
上述の祭祀方法において、前記学習モデルにより正と判定された場合に検証者による前記祭祀の検証結果を、前記検証者の端末装置から受け付け、前記検証結果により正と判定された場合に、前記祭祀は正であると判定してもよい。
【0012】
上記構成によれば、さらに祭祀の判定の精度が上がる。
【0013】
上述の祭祀方法において、検証者によって検証された前記支払い処理を記載した明細書の確認結果を受信してもよい。
【0014】
特許文献１においては、祭祀（供養）の終了後に、保険金から祭祀の手数料が引き落とされるが、不正なく引き落とし処理が行われたか否かを確認することはできない。
上述の祭祀方法によれば、祭祀の費用の支払いが正しいか否かを判定できる。
上述の祭祀方法によれば、祭祀の費用の支払いが正しいか否かを判定できる。
【0015】
上述の祭祀方法において、祭祀が正と判定された場合に、前記祭祀者に前記祭祀の費用を支払うスマートコントラクトをブロックチェーンに記録してもよい。
【0016】
上記構成によれば、ブロックチェーンにおいてスマートコントラクト処理を実行し、取引が承認された場合に自動的に支払い処理を実行できる。
【0017】
上述の祭祀方法において、前記祭祀が正と判定された情報を前記ブロックチェーンに送信し、前記スマートコントラクトの処理を実行してもよい。
【0018】
上記構成によれば、祭祀が終了し、かつ正と判定されたという情報の送信をトリガとして、スマートコントラクトの処理が実行される。
【0019】
上述の祭祀方法において、前記情報は、前記支払いを記載した明細書が正と判定されたという情報を含んでもよい。
【0020】
上記構成によれば、祭祀の費用の支払いが正しいか否かを検証できる。
【0021】
上述の祭祀方法において、前記祭祀対象を管理する端末のウォレットアドレスから、スマートコントラクトアドレス宛として祭祀に対するデポジットとなる仮想通貨量を含むトランザクションをブロックチェーンへ送信し、前記祭祀が終了し、かつ、正と判定された場合に、前記スマートコントラクトの履行に伴い前記祭祀者のウォレットアドレス宛として前記デポジットとなった仮想通貨量の一部の仮想通貨量を含むトランザクションをブロックチェーンへ送信してもよい。
【0022】
上記構成によれば、簡便に、祭祀の費用を送信することができる。
【0023】
本発明の一態様に係るコンピュータプログラムは、コンピュータに、祭祀対象の情報を取得し、祭祀者の情報を取得し、祭祀中の前記祭祀者をカメラを通じて撮像した映像を取得し、祭祀中の祭祀者を撮像した映像を入力した場合に、祭祀の正否の判定を示す正否情報を出力する学習モデルに、祭祀中の前記祭祀者を前記カメラを通じて撮像した映像を入力し、前記学習モデルから出力された正否情報、取得した前記祭祀対象の情報、及び、前記祭祀者の情報に基づいて、前記祭祀の正否を判定し、前記学習モデルにより正と判定された場合に複数の検証者による前記祭祀の検証結果を、前記検証者の端末装置からそれぞれ受け付ける処理を実行させる。
【0024】
上記構成によれば、供養者の携帯端末において、供養者の情報、記供養対象の情報、及び供養の映像を出力し、外部装置により供養の審査を行うことができる。
【0025】
本発明の一態様に係る祭祀審査装置は、祭祀対象の情報を取得する取得部と、祭祀者の情報を取得する祭祀者情報取得部と、祭祀中の前記祭祀者をカメラを通じて撮像した映像を取得する映像取得部と、祭祀中の祭祀者を撮像した映像を入力した場合に、祭祀の正否の判定を示す正否情報を出力する学習モデルと、前記祭祀中の前記祭祀者を前記カメラを通じて撮像した映像を前記学習モデルに入力する入力部と、前記学習モデルから出力された正否情報、取得した前記祭祀対象の情報、及び、前記祭祀者の情報に基づいて、前記祭祀の正否を判定する判定部と、前記学習モデルにより正と判定された場合に複数の検証者による前記祭祀の検証結果を、前記検証者の端末装置からそれぞれ受け付ける受付部とを備える。
【0026】
上記構成によれば、取得した祭祀対象（被祭祀者）及び祭祀者の情報、並びに祭祀状況に基づいて祭祀の正否を判定するので、正しい祭祀者により、正しい祭祀対象者に対し、居眠り等の異常所作がなく、正しく祭祀が行われたか否かを良好に判定できる。
【発明の効果】
【0027】
本発明によれば、祭祀対象及び祭祀者を特定した後、取得した祭祀状況に基づいて祭祀の正否を判定するので、正しい祭祀者により、正しい祭祀対象者に対し、居眠り等の異常所作がなく、正しく祭祀が行われたか否かを良好に判定できる。
【図面の簡単な説明】
【0028】
【図1】実施の形態１に係る供養審査システムの構成の一例を示す模式図である。
【図2】端末の構成の一例を示すブロック図である。
【図3】端末の構成の一例を示すブロック図である。
【図4】供養審査装置の構成の一例を示すブロック図である。
【図5】被供養者ＤＢのレコードレイアウトの一例を示す説明図である。
【図6】供養者ＤＢのレコードレイアウトの一例を示す説明図である。
【図7】供養ＤＢのレコードレイアウトの一例を示す説明図である。
【図8】画像ＤＢのレコードレイアウトの一例を示す説明図である。
【図9】音声ＤＢのレコードレイアウトの一例を示す説明図である。
【図10】明細書ＤＢのレコードレイアウトの一例を示す説明図である。
【図11】審査関連ＤＢのレコードレイアウトの一例を示す説明図である。
【図12】画像審査モデルの構成の一例を示す模式図である。
【図13】畳み込み層で行う処理を示す模式図である。
【図14】プーリング層で行う処理を示す模式図である。
【図15】制御部による画像審査モデルの生成処理の処理手順の一例を示すフローチャートである。
【図16】音声審査モデルの構成を示す模式図である。
【図17】制御部による画像及び音声の審査処理の手順を示すフローチャートである。
【図18】端末の表示パネルに表示される画面の一例を示す説明図である。
【図19】表示パネルに表示される表示画面の一例を示す説明図である。
【図20】表示パネルに表示される表示画面の一例を示す説明図である。
【図21】表示パネルに表示される表示画面の一例を示す説明図である。
【図22】制御部により端末から審査結果を取得する処理の手順を示すフローチャートである。
【図23】制御部により端末から審査結果を取得する処理の手順を示すフローチャートである。
【図24】審査Ａ、Ｂの手数料が追記された明細書を示す説明図である。
【図25】端末の表示パネルの表示画面の一例を示す説明図である。
【図26】実施の形態２に係る供養審査システムの構成の一例を示す模式図である。
【図27】仮想通貨量の送信の一例を示す説明図である。
【図28】スマートコントラクトの成立処理の手順を示すフローチャートである。
【図29】端末の表示パネルの表示画面の一例を示す説明図である。
【発明を実施するための形態】
【0029】
以下、本発明の実施の形態を図面に基づいて説明する。
（実施の形態１）
以下、祭祀が仏教行事の供養であり、供養者が仏僧である場合を例に挙げて説明する。被供養者のケースとしては、相続人が存在しない場合、相続人が存在しても、全員が嫁いでいる場合、海外赴任している場合、相続人に負担をかけたくない場合、配偶者と一緒に祀られるのを望まない場合等があり、遺族が供養者による供養を監視できない場合に、本実施の形態に係る祭祀方法は有用である。
図１は実施の形態１に係る供養審査システムの構成の一例を示す模式図である。供養審査システムにおいては、運営管理会社の供養審査装置１、供養者の端末２、サービス提供会社としての信託会社のスタッフＡの端末３、運営管理会社のスタッフＢの端末４、及びスタッフＡ及びスタッフＢの監視者Ｃの端末７がインターネット等のネットワークＮを介して接続されている。被供養者が生前に代理店としての信託会社と、死後の供養の契約を結び、供養審査装置１が供養者による供養の審査、供養の支払い処理を実行する。サービス提供会社とは、保険会社であってもよい。供養審査装置１は、供養の自動審査をクラウドサービスとして提供することができる。別会社に属するスタッフＡ、スタッフＢ、及び監視者Ｃが審査することで、供養の審査の公平性が保持される。スタッフの数は２である場合に限定されず、１又は３以上でもよい。監視者Ｃは省略してもよい。なお、供養者は、サービス提供会社と本実施の形態に係る契約を結ぶことは出来ない。
（実施の形態１）
以下、祭祀が仏教行事の供養であり、供養者が仏僧である場合を例に挙げて説明する。被供養者のケースとしては、相続人が存在しない場合、相続人が存在しても、全員が嫁いでいる場合、海外赴任している場合、相続人に負担をかけたくない場合、配偶者と一緒に祀られるのを望まない場合等があり、遺族が供養者による供養を監視できない場合に、本実施の形態に係る祭祀方法は有用である。
図１は実施の形態１に係る供養審査システムの構成の一例を示す模式図である。供養審査システムにおいては、運営管理会社の供養審査装置１、供養者の端末２、サービス提供会社としての信託会社のスタッフＡの端末３、運営管理会社のスタッフＢの端末４、及びスタッフＡ及びスタッフＢの監視者Ｃの端末７がインターネット等のネットワークＮを介して接続されている。被供養者が生前に代理店としての信託会社と、死後の供養の契約を結び、供養審査装置１が供養者による供養の審査、供養の支払い処理を実行する。サービス提供会社とは、保険会社であってもよい。供養審査装置１は、供養の自動審査をクラウドサービスとして提供することができる。別会社に属するスタッフＡ、スタッフＢ、及び監視者Ｃが審査することで、供養の審査の公平性が保持される。スタッフの数は２である場合に限定されず、１又は３以上でもよい。監視者Ｃは省略してもよい。なお、供養者は、サービス提供会社と本実施の形態に係る契約を結ぶことは出来ない。
【0030】
供養審査装置１は、供養者（僧）による供養の映像に基づいて供養の正否を審査し、供養が正（以下、ＯＫともいう）であると判定した場合、供養の映像、並びに供養者の手数料及び運営管理会社の運営管理の手数料についての明細書をスタッフＡ及びＢに送信し、スタッフＡ及びＢによる供養の正否の判定結果及び明細書の内容の確認結果を受信する。
さらに、スタッフＡ及びＢの判定の監視を行う。スタッフＡ及びＢの審査は、審査監視スタッフＣによる審査でもよく、供養審査装置１同様、自動審査により実施してもよい。図１においては、審査監視スタッフＣがカメラ６５により、スタッフＡが供養映像を判定している状態を取得し、スタッフＡの判定を監視している状態を示している。カメラ６５の代わりに、端末３及び４に内蔵されている自撮り（監視）カメラ３７及び４７を用いてもよい。供養審査装置１は、前記判定結果及び確認結果がＯＫである場合、供養者に手数料を送金し、スタッフＡ及びＢの手数料、並びに運営管理の手数料の支払い処理を行う。以下、審査監視スタッフＣを省略した場合につき、説明する。
供養審査装置１は、後述する画像審査モデル１５９により、取得した映像に含まれる画像の異常の有無の情報を取得し、音声審査モデル１６０により、取得した映像に含まれる音声の異常の有無の情報を取得する。
さらに、スタッフＡ及びＢの判定の監視を行う。スタッフＡ及びＢの審査は、審査監視スタッフＣによる審査でもよく、供養審査装置１同様、自動審査により実施してもよい。図１においては、審査監視スタッフＣがカメラ６５により、スタッフＡが供養映像を判定している状態を取得し、スタッフＡの判定を監視している状態を示している。カメラ６５の代わりに、端末３及び４に内蔵されている自撮り（監視）カメラ３７及び４７を用いてもよい。供養審査装置１は、前記判定結果及び確認結果がＯＫである場合、供養者に手数料を送金し、スタッフＡ及びＢの手数料、並びに運営管理の手数料の支払い処理を行う。以下、審査監視スタッフＣを省略した場合につき、説明する。
供養審査装置１は、後述する画像審査モデル１５９により、取得した映像に含まれる画像の異常の有無の情報を取得し、音声審査モデル１６０により、取得した映像に含まれる音声の異常の有無の情報を取得する。
【0031】
図２は端末２の構成の一例を示すブロック図である。端末２は、装置全体を制御する制御部２１、主記憶部２２、通信部２３、操作部２４、表示パネル２５、補助記憶部２６、マイクロフォン２７、撮像部２８、ＧＰＳ受信部２９、及び時計部３０を備える。端末２は、例えば、スマートフォン、デスクトップ型コンピュータ、ノート型パーソナルコンピュータ、タブレット等で構成することができる。制御部２１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）等で構成することができる。制御部２１はＧＰＵ（Graphics Processing Unit）を含んで構成してもよい。
【0032】
主記憶部２２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の一時記憶領域であり、制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。
通信部２３は、ネットワークＮを介して、供養審査装置１、端末３、及び端末４との間で通信を行う機能を有し、所要の情報の送受信を行うことができる。通信部２３は供養審査装置１へ供養者情報、供養対象情報、位置情報、及び供養の映像等の供養の状況を示す状況情報を送信する。
通信部２３は、ネットワークＮを介して、供養審査装置１、端末３、及び端末４との間で通信を行う機能を有し、所要の情報の送受信を行うことができる。通信部２３は供養審査装置１へ供養者情報、供養対象情報、位置情報、及び供養の映像等の供養の状況を示す状況情報を送信する。
【0033】
操作部２４は、例えば、タッチパネル、ハードウェアキーボード、マウス等で構成され、表示パネル２５に表示されたアイコン等の操作、文字等の入力等を行うことができる。
【0034】
表示パネル２５は、液晶パネル又は有機ＥＬ（Electro Luminescence）表示パネル等で構成することができる。制御部２１は、表示パネル２５に所要の情報を表示するための制御を行う。制御部２１は、例えば状況情報に基づいて供養の正否情報を表示する。この場合、供養審査装置１が所定の審査条件に合格したか否かの判定処理を自動で行う。
【0035】
補助記憶部２６は大容量メモリ、ハードディスク等であり、制御部２１が処理を実行するために必要なプログラム、及びアプリケーションプログラム（以下、アプリプログラムという）２６１を記憶している。また、補助記憶部２６は、供養者に関する情報、撮像部２８から取得した映像データ、端末３、４で行う処理に関連するデータ（例えば審査結果のデータ）、及び供養審査装置１から受信したデータ等を記憶する。
【0036】
補助記憶部２６に記憶されるアプリプログラム２６１は、アプリプログラム２６１を読み取り可能に記録した記録媒体２６２により提供されてもよい。記録媒体２６２は、例えば、ＵＳＢ（Universal Serial Bus）メモリ、ＳＤ（Secure Digital）カード、マイクロＳＤカード、コンパクトフラッシュ（登録商標）等の可搬型のメモリである。記録媒体２６２に記録されるアプリプログラム２６１は通信部２３を介した通信により提供される。
また、図に示していない読取装置を用いて記録媒体２６２から読み取られ、補助記憶部２６にインストールされてもよい。
また、図に示していない読取装置を用いて記録媒体２６２から読み取られ、補助記憶部２６にインストールされてもよい。
【0037】
マイクロフォン２７は、供養者の音声を入力して電気信号に変換する。
撮像部２８は例えばＣＣＤ（Charge Coupled Device）カメラ等を含み、画像又は映像の撮像を行う。撮像部２８により撮像された画像又は映像は図示しない処理回路によって処理され、補助記憶部２６に記憶される。
ＧＰＳ受信部２９は、複数のＧＰＳ衛星からの電波を受信し、端末２の位置を検出する
。
時計部３０は計時し、日時情報を出力する。
撮像部２８は例えばＣＣＤ（Charge Coupled Device）カメラ等を含み、画像又は映像の撮像を行う。撮像部２８により撮像された画像又は映像は図示しない処理回路によって処理され、補助記憶部２６に記憶される。
ＧＰＳ受信部２９は、複数のＧＰＳ衛星からの電波を受信し、端末２の位置を検出する
。
時計部３０は計時し、日時情報を出力する。
【0038】
図３は端末３の構成の一例を示すブロック図である。端末３は、装置全体を制御する制御部３１、主記憶部３２、通信部３３、操作部３４、表示パネル３５、補助記憶部３６、及び自撮り（監視）カメラ３７を備える。端末３は、例えば、デスクトップ型コンピュータ、ノート型パーソナルコンピュータ、タブレット、スマートフォン等で構成することができる。制御部３１は、ＣＰＵ、ＲＯＭ及びＲＡＭ等で構成することができる。主記憶部３２、通信部３３、操作部３４、表示パネル３５、及び補助記憶部３６は、端末２の主記憶部２２、通信部２３、操作部２４、表示パネル２５、及び補助記憶部２６と同様の構成を有する。
端末４は端末３と同様の構成を有し、制御部４１、主記憶部４２、通信部４３、操作部４４、表示パネル４５、補助記憶部４６及び自撮り（監視）カメラ４７を備える。
端末４は端末３と同様の構成を有し、制御部４１、主記憶部４２、通信部４３、操作部４４、表示パネル４５、補助記憶部４６及び自撮り（監視）カメラ４７を備える。
【0039】
図４は供養審査装置１の構成の一例を示すブロック図である。供養審査装置１は、装置全体を制御する制御部１１、主記憶部１２、通信部１３、言語処理部１４、補助記憶部１５及び時計部１６を備える。供養審査装置１は、１又は複数のサーバで構成することができる。
制御部１１は、ＣＰＵ、ＲＯＭ及びＲＡＭ等で構成することができる。制御部１１はＧＰＵ（Graphics Processing Unit）を含んで構成してもよい。
制御部１１は、ＣＰＵ、ＲＯＭ及びＲＡＭ等で構成することができる。制御部１１はＧＰＵ（Graphics Processing Unit）を含んで構成してもよい。
【0040】
主記憶部１２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等の一時記憶領域であり、制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。
【0041】
供養審査装置１は複数台で分散処理してもよい。
通信部１３は、ネットワークＮを介して、端末２、３、４との間で通信を行う機能を有し、所要の情報の送受信を行うことができる。具体的には、通信部１３は、端末２が送信した映像データを受信することができる。また、通信部１３は、画像又は音声の正否情報を端末２へ送信することができる。
通信部１３は、ネットワークＮを介して、端末２、３、４との間で通信を行う機能を有し、所要の情報の送受信を行うことができる。具体的には、通信部１３は、端末２が送信した映像データを受信することができる。また、通信部１３は、画像又は音声の正否情報を端末２へ送信することができる。
【0042】
言語処理部１４は、音声認識処理機能を備え、映像に含まれる音声をテキストデータ（文字列）に変換することができる。なお、通常、音声又は文字は複数のフレームに亘って出力又は表示されるので、言語処理部によるテキストデータの変換処理は、フレーム単位ではなく、複数のフレームに跨って行われる。
言語処理部１４は、形態素解析機能を備え、辞書データを用いて、変換したテキストデータから意味を持つ最小単位である単語を抽出する。
言語処理部１４は、形態素解析機能を備え、辞書データを用いて、変換したテキストデータから意味を持つ最小単位である単語を抽出する。
【0043】
補助記憶部１５は大容量メモリ、ハードディスク等であり、制御部１１が処理を実行するために必要なプログラム、後述する供養審査を行うプログラム１５１、被供養者ＤＢ１５２、供養者ＤＢ１５３、供養ＤＢ１５４、画像ＤＢ１５５、音声ＤＢ１５６、明細書ＤＢ１５７、審査関連ＤＢ１５８、画像審査モデル１５９、音声審査モデル１６０、その他のデータを記憶している。
【0044】
補助記憶部１５に記憶される供養審査プログラム（以下、プログラムという）１５１は、プログラム１５１を読み取り可能に記録した記録媒体１６１により提供されてもよい。
記録媒体１６１は、例えば、ＵＳＢメモリ、ＳＤカード、マイクロＳＤカード、コンパクトフラッシュ（登録商標）等の可搬型のメモリである。記録媒体１６１に記録されるプログラム１５１は、図に示していない読取装置を用いて記録媒体１６１から読み取られ、補助記憶部１５にインストールされる。また、補助記憶部１５に記憶されるプログラム１５１は、通信部１３を介した通信により提供されてもよい。
記録媒体１６１は、例えば、ＵＳＢメモリ、ＳＤカード、マイクロＳＤカード、コンパクトフラッシュ（登録商標）等の可搬型のメモリである。記録媒体１６１に記録されるプログラム１５１は、図に示していない読取装置を用いて記録媒体１６１から読み取られ、補助記憶部１５にインストールされる。また、補助記憶部１５に記憶されるプログラム１５１は、通信部１３を介した通信により提供されてもよい。
【0045】
被供養者ＤＢ１５２は供養対象である被供養者の情報を格納したデータベースである。
図５は、被供養者ＤＢ１５２のレコードレイアウトの一例を示す説明図である。
被供養者データは、被供養者ＩＤ列、氏名列、没日列、享年列、戒名列、位牌のＱＲコード列、代理会社列、及び遺族又は代理人列を記憶している。被供養者ＩＤ列は、被供養者を識別するための被供養者ＩＤを記憶している。氏名は被供養者の氏名であり、没日は被供養者の没日、享年は被供養者の享年、戒名は被供養者の戒名、位牌のＱＲコードは位牌６に付された被供養者のＱＲコード、代理会社は被供養者が契約した信託会社等である。遺族又は代理人列は遺族が存在する場合、遺族の氏名、住所、メールアドレス、電話番号、及び携帯電話番号であり、遺族が存在しない場合、代理人の氏名、住所、メールアドレス、電話番号、及び携帯電話番号である。
図５は、被供養者ＤＢ１５２のレコードレイアウトの一例を示す説明図である。
被供養者データは、被供養者ＩＤ列、氏名列、没日列、享年列、戒名列、位牌のＱＲコード列、代理会社列、及び遺族又は代理人列を記憶している。被供養者ＩＤ列は、被供養者を識別するための被供養者ＩＤを記憶している。氏名は被供養者の氏名であり、没日は被供養者の没日、享年は被供養者の享年、戒名は被供養者の戒名、位牌のＱＲコードは位牌６に付された被供養者のＱＲコード、代理会社は被供養者が契約した信託会社等である。遺族又は代理人列は遺族が存在する場合、遺族の氏名、住所、メールアドレス、電話番号、及び携帯電話番号であり、遺族が存在しない場合、代理人の氏名、住所、メールアドレス、電話番号、及び携帯電話番号である。
【0046】
供養者ＤＢ１５３は、供養者の情報を格納したデータベースである。
図６は、供養者ＤＢ１５３のレコードレイアウトの一例を示す説明図である。
供養者データは、供養者ＩＤ列、氏名列、寺名列、住所列、メールアドレス列、宗派列、及び被供養者ＩＤ列を記憶している。供養者ＩＤ列は、供養者を識別するための供養者ＩＤを記憶している。氏名は供養者の氏名であり、寺名は供養者が供養を行う寺の名称、住所は寺の住所、メールアドレスは供養者のメールアドレス、宗派は供養者の属する宗派、被供養者ＩＤは上記の被供養者ＩＤである。
図６は、供養者ＤＢ１５３のレコードレイアウトの一例を示す説明図である。
供養者データは、供養者ＩＤ列、氏名列、寺名列、住所列、メールアドレス列、宗派列、及び被供養者ＩＤ列を記憶している。供養者ＩＤ列は、供養者を識別するための供養者ＩＤを記憶している。氏名は供養者の氏名であり、寺名は供養者が供養を行う寺の名称、住所は寺の住所、メールアドレスは供養者のメールアドレス、宗派は供養者の属する宗派、被供養者ＩＤは上記の被供養者ＩＤである。
【0047】
供養ＤＢ１５４は、被供養者の供養の情報を格納したデータベースである。
図７は、供養ＤＢ１５４のレコードレイアウトの一例を示す説明図である。
供養データは、被供養者ＩＤ列、及び供養の内容列を記憶している。被供養者ＩＤ列は、被供養者を識別するための上記被供養者ＩＤを記憶している。供養の内容列は、各被供養者につき、契約に応じて、供養の種類と供養の年月日とが時系列に記憶されている。
供養の種類としては、初七日、…、七七日、百箇日、…、一周忌、三回忌、…、三十三回忌、五十回忌、５０年後の永代供養等が挙げられる。月命日毎に月法要を行ってもよい。供養の内容としては、墓前のお供え、墓清掃、葬儀、遺産整理、遺品整理等も含まれる。供養の内容と併せて、費用（お布施額等）も記憶されている。
図７において、ＩＤＮｏ．1の被供養者は、没後、月命日毎に月法要を行い、季節法要を行い、墓清掃も行う。
ＩＤＮｏ．２の被供養者の場合、供養は一周忌から始まり、三十三回忌、５０年後の永代供養まで回忌法要を行う。
図７は、供養ＤＢ１５４のレコードレイアウトの一例を示す説明図である。
供養データは、被供養者ＩＤ列、及び供養の内容列を記憶している。被供養者ＩＤ列は、被供養者を識別するための上記被供養者ＩＤを記憶している。供養の内容列は、各被供養者につき、契約に応じて、供養の種類と供養の年月日とが時系列に記憶されている。
供養の種類としては、初七日、…、七七日、百箇日、…、一周忌、三回忌、…、三十三回忌、五十回忌、５０年後の永代供養等が挙げられる。月命日毎に月法要を行ってもよい。供養の内容としては、墓前のお供え、墓清掃、葬儀、遺産整理、遺品整理等も含まれる。供養の内容と併せて、費用（お布施額等）も記憶されている。
図７において、ＩＤＮｏ．1の被供養者は、没後、月命日毎に月法要を行い、季節法要を行い、墓清掃も行う。
ＩＤＮｏ．２の被供養者の場合、供養は一周忌から始まり、三十三回忌、５０年後の永代供養まで回忌法要を行う。
【0048】
画像ＤＢ１５５は、映像のうちの画像の情報を供養毎に格納したデータベースである。
図８は、画像ＤＢ１５５のレコードレイアウトの一例を示す説明図である。
画像データは、画像ＩＤ列、フレームＮｏ．列、異常値列を含む。画像ＩＤ列は、各画像を識別するための画像ＩＤを記憶している。フレームＮｏ．列はＩＤを付された画像のフレームＮｏ．である。映像はフレーム単位で記憶することができる。フレームレートが、例えば、３０ｆｐｓの場合、映像には、１秒間に３０枚のフレーム（画像）が含まれる。審査のために、全てのフレームではなく、所定のフレーム間隔をおいて画像を取得する場合、そのフレームＮｏ．が記憶される。異常値は後述する異常の確率値である。
図８は、画像ＤＢ１５５のレコードレイアウトの一例を示す説明図である。
画像データは、画像ＩＤ列、フレームＮｏ．列、異常値列を含む。画像ＩＤ列は、各画像を識別するための画像ＩＤを記憶している。フレームＮｏ．列はＩＤを付された画像のフレームＮｏ．である。映像はフレーム単位で記憶することができる。フレームレートが、例えば、３０ｆｐｓの場合、映像には、１秒間に３０枚のフレーム（画像）が含まれる。審査のために、全てのフレームではなく、所定のフレーム間隔をおいて画像を取得する場合、そのフレームＮｏ．が記憶される。異常値は後述する異常の確率値である。
【0049】
音声ＤＢ１５６は、映像のうちの音声の情報を供養毎に格納したデータベースである。
図９は、音声ＤＢ１５６のレコードレイアウトの一例を示す説明図である。音及びテキストは、供養の時間を所定数に分割した、分割単位時間毎に記憶される。
音声データは、音声ＩＤ列、異常値列を含む。音声ＩＤ列は、各分割単位時間に音及びテキストを識別するための音声ＩＤを記憶している。異常値は後述する異常の確率値である。
図９は、音声ＤＢ１５６のレコードレイアウトの一例を示す説明図である。音及びテキストは、供養の時間を所定数に分割した、分割単位時間毎に記憶される。
音声データは、音声ＩＤ列、異常値列を含む。音声ＩＤ列は、各分割単位時間に音及びテキストを識別するための音声ＩＤを記憶している。異常値は後述する異常の確率値である。
【0050】
明細書ＤＢ１５７は、供養の費用の情報を被供養者毎に格納したデータベースである。
図１０は、明細書ＤＢ１５７のレコードレイアウトの一例を示す説明図である。
明細書データは、被供養者毎に、日時列、供養の内容列、供養費用列、運営管理会社手数料列、審査Ａ手数料列、審査Ｂ手数料列、及び残高列を記憶している。日時は供養の日時、供養の内容は上述の供養の内容、供養費用は供養者に支払われる供養費用、審査Ａ手数料は信託会社のスタッフＡによる審査の手数料、審査Ｂ手数料は運営管理会社のスタッフＢによる審査の手数料、残高は供養費用、及び各手数料を支払った後の残高である。図１０では、被供養者により、代理店としての信託会社に１０００万円振り込まれていたものとしている。
図１０は、明細書ＤＢ１５７のレコードレイアウトの一例を示す説明図である。
明細書データは、被供養者毎に、日時列、供養の内容列、供養費用列、運営管理会社手数料列、審査Ａ手数料列、審査Ｂ手数料列、及び残高列を記憶している。日時は供養の日時、供養の内容は上述の供養の内容、供養費用は供養者に支払われる供養費用、審査Ａ手数料は信託会社のスタッフＡによる審査の手数料、審査Ｂ手数料は運営管理会社のスタッフＢによる審査の手数料、残高は供養費用、及び各手数料を支払った後の残高である。図１０では、被供養者により、代理店としての信託会社に１０００万円振り込まれていたものとしている。
【0051】
審査関連ＤＢ１５８には、端末３、４で行う処理に関連するデータを格納したデータベースである。
図１１は、審査関連ＤＢ１５８のレコードレイアウトの一例を示す説明図である。
審査関連データは、被供養者ＩＤ列、スタッフＡのＩＤ列、スタッフＢのＩＤ列、供養審査列、及び明細書審査列を記憶している。供養審査列には、スタッフＡ、Ｂ夫々の供養についての審査結果が記憶されている。ＯＫの場合、○であり、ＮＧの場合、×が記憶される。明細書審査列には、スタッフＡ、Ｂ夫々の明細書についての審査結果が記憶されている。ＯＫの場合、○であり、ＮＧの場合、×が記憶される。
図１１は、審査関連ＤＢ１５８のレコードレイアウトの一例を示す説明図である。
審査関連データは、被供養者ＩＤ列、スタッフＡのＩＤ列、スタッフＢのＩＤ列、供養審査列、及び明細書審査列を記憶している。供養審査列には、スタッフＡ、Ｂ夫々の供養についての審査結果が記憶されている。ＯＫの場合、○であり、ＮＧの場合、×が記憶される。明細書審査列には、スタッフＡ、Ｂ夫々の明細書についての審査結果が記憶されている。ＯＫの場合、○であり、ＮＧの場合、×が記憶される。
【0052】
本実施の形態においては、制御部１１により供養者、供養対象（被供養者）、供養が行われる場所の位置情報、及び供養の日時情報を取得し、これらの情報がＯＫと判定された後、映像を取得し、映像のうちの画像、及び音声を夫々画像審査モデル１５９、及び音声審査モデル１６０に入力して、供養の異常の有無を判定する。
【0053】
画像審査モデル１５９及び音声審査モデル１６０の学習モデルは、多層のニューラルネットワーク（深層学習）を用いることができ、例えば、畳み込みニューラルネットワーク（Convolutional Neural Network）を用いることができるが、他の機械学習を用いてもよい。画像審査モデル１５９は、供養の画像が異常情報を含むか否かを自動的に判定し、正否情報を出力する。音声審査モデル１６０は、供養の音声が異常情報を含むか否かを自動的に判定し、正否情報を出力する。以下、画像審査モデル１５９及び音声審査モデル１６０の詳細について説明する。
【0054】
制御部１１は、画像審査モデル１５９として、画像内における供養の異常の画像特徴量を学習することで、画像を入力とし、供養の正否を示す情報を出力とするニューラルネットワークを構築（生成）する。
図１２は画像審査モデル１５９の構成の一例を示す模式図である。図１２に示す画像審査モデル１５９は、画像用の畳み込みニューラルネットワークであり、入力層１５３ａ、畳み込み層１５３ｂ、プーリング層１５３ｃ、畳み込み層１５３ｄ、プーリング層１５３ｅ、全結合層１５３ｆ、及び出力層１５３ｇが、この順に接続されている。なお、畳み込み層、プーリング層及び全結合層の数は便宜上のものであり、図１２に示す数に限定されない。また、便宜上、活性化関数の層は省略している。入力層１５３ａには、映像の画像がフレーム単位で入力される。画像審査モデル１５９は、フレーム単位又は複数のフレーム単位で画像が異常情報を含むか否かを判定することができる。すなわち、出力層１５３ｇは、フレーム単位で画像の正否情報を出力する。画像が異常情報を含む例として、供養者が居眠りをする、供養者が供養を行う場所から消える、よそ見をする、伸びをする等、供養の所作と異なる所作をする場合等が挙げられる。
図１２は画像審査モデル１５９の構成の一例を示す模式図である。図１２に示す画像審査モデル１５９は、画像用の畳み込みニューラルネットワークであり、入力層１５３ａ、畳み込み層１５３ｂ、プーリング層１５３ｃ、畳み込み層１５３ｄ、プーリング層１５３ｅ、全結合層１５３ｆ、及び出力層１５３ｇが、この順に接続されている。なお、畳み込み層、プーリング層及び全結合層の数は便宜上のものであり、図１２に示す数に限定されない。また、便宜上、活性化関数の層は省略している。入力層１５３ａには、映像の画像がフレーム単位で入力される。画像審査モデル１５９は、フレーム単位又は複数のフレーム単位で画像が異常情報を含むか否かを判定することができる。すなわち、出力層１５３ｇは、フレーム単位で画像の正否情報を出力する。画像が異常情報を含む例として、供養者が居眠りをする、供養者が供養を行う場所から消える、よそ見をする、伸びをする等、供養の所作と異なる所作をする場合等が挙げられる。
【0055】
出力層１５３ｇを２つの出力ノードで構成し、画像の内容が正常である確率、及び画像の内容が異常である不合格となる確率（信頼度）を出力してもよい。ソフトマックス関数を用いた場合、連続的な確率値（例えば「０」から「１」までの範囲の値）である。又は、合格又は不合格の少なくとも一方の信頼度を複数の区分（例えば、信頼度＝１００％、９５％、９０％、８５％、８０％、…、０％の如く）に分けて、区分の数だけ出力ノードを設け、各区分の確率を出力してもよい。
制御部１１は、各フレームの画像の異常の確率値を異常値とて取得し、総合的に供養画像が異常であるか否かを判定する。例えば異常の確率値が０．５以上であるフレームの数が閾値以上である場合、供養画像は異常であり、供養は不合格とする。
制御部１１は、各フレームの画像の異常の確率値を異常値とて取得し、総合的に供養画像が異常であるか否かを判定する。例えば異常の確率値が０．５以上であるフレームの数が閾値以上である場合、供養画像は異常であり、供養は不合格とする。
【0056】
また、出力層１５３ｇのＮＧの出力ノードをさらに複数の出力ノードで構成してもよい。この場合、夫々のノードを、画像がＯＫでない理由を定め、各理由の確率を出力してもよい。理由は、例えば、「居眠り」、「よそ見」、「不在」等とすることができるが、これらに限定されない。
【0057】
図１３は畳み込み層で行う処理を示す模式図である。畳み込み層の入出力データは、特徴マップとも称され、畳み込み層の入力データを入力特徴マップ、畳み込み層の出力データを出力特徴マップともいう。初段の畳み込み層の入力特徴マップは、入力されたフレーム単位の画像である。畳み込み層で行う処理（「畳み込み演算」ともいう）は、畳み込みフィルタ（「フィルタ」ともいう）によるフィルタ演算である。
【0058】
図１３に示すように、入力特徴マップを、８×８ピクセルとする。また、フィルタの大きさを３×３ピクセルとする。畳み込み演算では、入力特徴マップに対して、フィルタのウィンドウを一定の間隔でスライドさせながら、フィルタの要素と入力特徴マップの対応する要素を乗算し、その和を求め、求めた和を出力特徴マップの対応するピクセルに格納する。図１３の例では、入力特徴マップのフィルタＦ１に対応する領域Ｓの演算結果が出力特徴マップのピクセルＳ１に格納される。また、入力特徴マップのフィルタＦ２に対応する領域Ｓの演算結果が出力特徴マップのピクセルＳ２に格納される。同様に、入力特徴マップのフィルタＦ３に対応する領域Ｓの演算結果が出力特徴マップのピクセルＳ３に格納される。フィルタを１ピクセルずつ移動させて同様の演算を行うことにより、出力特徴マップは、６×６ピクセルの大きさとなる。ここで、３つのフィルタＦ１、Ｆ２、Ｆ３を用いることにより、３つの出力特徴マップが得られる。
【0059】
画像審査モデル１５９の学習では、フィルタに関するパラメータとして、例えば、フィルタの要素の値、フィルタの数（図１３の例では、３）、フィルタの大きさ（図１３の例では、３×３）、フィルタの移動幅（「スライド」ともいう、図１３の例では、１ピクセル）、入力特徴マップの周囲（端の領域）を０で埋めるパディングなどを最正化する。畳み込み層により、画像の空間的な特徴を抽出することができる。
【0060】
図１４はプーリング層で行う処理を示す模式図である。プーリング層は、畳み込み層から出力された二次元特徴マップの大きさを縮小する処理を行う。具体的には、画像の局所領域を一つの要素に集約する処理を行う。例えば、図１４に示すように、６×６ピクセルの特徴マップ（出力特徴マップ）において、２×２の局所領域（ウィンドウＷ）を、各要素のうちの最大値である「４」に集約している。なお、ウィンドウＷのスライドは、ウィンドウＷの大きさに等しく、図１４の例では、２ピクセルずつスライドするので、６×６ピクセルの特徴マップは、３×３ピクセルに縮小される。プーリング層により、画像内で、例えば、特徴部分が多少変形又は変位していても、その変形又は変位による差異を吸収して特徴部分を抽出することができる。なお、本実施の形態においては、１フレーム毎に処理したが、これに限定されるものではない。例えば１０フレーム毎に処理してもよい。
その他、連続する所定数フレーム（例えば１０フレーム）を時系列情報として入力し、出力を正否に関する情報とする（Recurrent Neural Network）を用いてもよい。
その他、連続する所定数フレーム（例えば１０フレーム）を時系列情報として入力し、出力を正否に関する情報とする（Recurrent Neural Network）を用いてもよい。
【0061】
図１５は、制御部１１による画像審査モデル１５９の生成処理の処理手順の一例を示すフローチャートである。
制御部１１は、複数の供養中の画像と、各画像の正否を示す情報とを対応付けた教師データを取得する（ステップＳ１１）。
制御部１１は、複数の供養中の画像と、各画像の正否を示す情報とを対応付けた教師データを取得する（ステップＳ１１）。
【0062】
制御部１１は教師データを用いて、供養の画像を入力した場合に画像の正否情報を出力する画像審査モデル１５９を生成する（ステップＳ１２）。具体的には、制御部１１は、教師データである複数人の画像をニューラルネットワークの入力層に入力し、画像内の異常の有無を識別した識別結果を出力層から取得する。異常の画像としては、「居眠り」、「よそ見」、「不在」等の画像が挙げられる。「居眠り」の場合、瞬きと区別するために、フレームＮｏ．が連続する複数の画像を参照する。制御部１１は、取得した識別結果を教師データの正解値（画像に対してラベル付けられた情報）と比較し、出力層から出力される識別結果が正解値に近づくよう、中間層での演算処理に用いるパラメータを最正化する。該パラメータは、例えばニューロン間の重み（結合係数）、各ニューロンで用いられる活性化関数の係数などである。パラメータの最正化の方法は特に限定されないが、例えば制御部１１は誤差逆伝播法を用いて各種パラメータの最正化を行う。制御部１１は、生成した画像審査モデル１５９を補助記憶部１５に格納し、一連の処理を終了する。
ＲＮＮの場合、所定数フレーム分の画像データを入力し、正常の確率値、及び異常の確率値を出力する。
ＲＮＮの場合、所定数フレーム分の画像データを入力し、正常の確率値、及び異常の確率値を出力する。
【0063】
図１６は音声審査モデル１６０の構成を示す模式図である。
制御部１１は、音声審査モデル１６０として、異常の特徴量を学習することで、音、及び言語処理部１４により取得したテキストを入力とし、供養の異常の有無を示す情報を出力とするニューラルネットワークを構築する。音及びテキストは所定の入力時間（前記分割単位時間）毎に入力する。例えばニューラルネットワークはＣＮＮ（Convolution Neural Network）であり、音及びテキストの入力を受け付ける入力層と、異常の有無の識別結果を出力する出力層と、特徴量を抽出する中間層とを有する。
図１６において、中間層の層数は３とされているが、これに限定されない。例えば音声審査モデル１６０がＣＮＮである場合、中間層は、コンボリューション層とプーリング層とが交互に連結された構成を有し、情報を圧縮しながら最終的に特徴量を抽出する。図１６において、コンボリューション層、及びプーリング層の記載は省略している。出力層は、供養の異常を識別した識別結果を出力する二つのニューロンを有し、中間層から出力された特徴量に基づいて供養の異常の有無を識別する。一方のニューロンは正常の確率値を出力し、他方のニューロンは異常の確率値を出力する。
制御部１１は、音声審査モデル１６０として、異常の特徴量を学習することで、音、及び言語処理部１４により取得したテキストを入力とし、供養の異常の有無を示す情報を出力とするニューラルネットワークを構築する。音及びテキストは所定の入力時間（前記分割単位時間）毎に入力する。例えばニューラルネットワークはＣＮＮ（Convolution Neural Network）であり、音及びテキストの入力を受け付ける入力層と、異常の有無の識別結果を出力する出力層と、特徴量を抽出する中間層とを有する。
図１６において、中間層の層数は３とされているが、これに限定されない。例えば音声審査モデル１６０がＣＮＮである場合、中間層は、コンボリューション層とプーリング層とが交互に連結された構成を有し、情報を圧縮しながら最終的に特徴量を抽出する。図１６において、コンボリューション層、及びプーリング層の記載は省略している。出力層は、供養の異常を識別した識別結果を出力する二つのニューロンを有し、中間層から出力された特徴量に基づいて供養の異常の有無を識別する。一方のニューロンは正常の確率値を出力し、他方のニューロンは異常の確率値を出力する。
【0064】
なお、音声審査モデル１６０がＣＮＮであるものとして説明するが、音声審査モデル１６０はＣＮＮに限定されず、例えばＲＮＮを用いることができる。ＲＮＮでは、前の時刻の中間層を次の時刻の入力層と合わせて学習に用いることで、テキスト、即ち複数の単語の時系列情報、又は音声波形の時系列情報を考慮することができる。
【0065】
また、音声審査モデル１６０を用いず、言語処理部１４により変換したテキストに対し、予め補助記憶部１５に記憶してある、所定の供養に係る経文との相関値を算出し、一致度を判定することにより、供養の異常の有無を判定してもよい。
【0066】
制御部１１は、各入力時間に入力した音及びテキストと、各音及びテキストにおける異常を示す情報（異常であるか、正常であるか）とが対応付けられた教師データ（異常データ、正常データ）を用いて学習を行う。
【0067】
制御部１１は、教師データである音及びテキストを入力層に入力し、中間層での演算処理を経て、出力層から供養の異常の有無を示す識別結果を取得する。なお、出力層から出力される識別結果は、ソフトマックス関数を用いた場合、連続的な確率値（例えば「０」から「１」までの範囲の値）である。識別結果は、異常の有無を離散的に示す値（例えば「０」又は「１」の値）であってもよい。
【0068】
制御部１１は、出力層から出力された識別結果を、教師データにおいて声紋及びテキストに対しラベル付けされた情報、すなわち正解値と比較し、出力層からの出力値が正解値に近づくように、中間層での演算処理に用いるパラメータを最正化する。該パラメータは、例えばニューロン間の重み（結合係数）、各ニューロンで用いられる活性化関数の係数などである。パラメータの最正化の方法は特に限定されないが、例えば制御部１１は誤差逆伝播法を用いて各種パラメータの最正化を行う。
【0069】
制御部１１は、教師データに含まれる音及びテキストについて上記の処理を行い、音声審査モデル１６０を生成する。制御部１１は音及びテキストを取得した場合、音声審査モデル１６０を用いて供養の異常の有無を検出する。
【0070】
音の異常としては音の声紋が供養者の声紋と一致しない、音が肉声ではなく、プレーヤーから発せられている場合等が挙げられ、テキストの異常としてはテキストが供養の経文の内容と一致しない場合等が挙げられ、音及びテキストを組み合わせて異常値が算出される。
例えば入力時間毎に入力した音及びテキストの異常の確率値が０．５以上である場合の数が閾値以上である場合、供養の音は異常であり、供養は不合格とする。
なお、音声審査モデル１６０にはテキストを入力せず、音のみを入力してもよい。
例えば入力時間毎に入力した音及びテキストの異常の確率値が０．５以上である場合の数が閾値以上である場合、供養の音は異常であり、供養は不合格とする。
なお、音声審査モデル１６０にはテキストを入力せず、音のみを入力してもよい。
【0071】
供養審査装置１の制御部１１は、供養者毎の教師データを用いて画像審査モデル１５９及び音声審査モデル１６０を学習させてもよい。画像審査モデル１５９及び音声審査モデル１６０に含まれるアルゴリズム及びパラメータ（例えば、フィルタに関するパラメータ等）が、供養者毎に特化した形で最正化された画像審査モデル１５９及び音声審査モデル１６０を得ることができる。これにより、供養の審査の精度を高めることが可能になる。
【0072】
また、制御部１１は、画像審査モデル１５９及び音声審査モデル１６０により、取得した映像が審査条件に合格しないと判定した場合、判定結果の信頼度を出力するように、画像審査モデル１５９及び音声審査モデル１６０を再学習させることができる。
【0073】
また、制御部１１は、画像審査モデル１５９が、取得した映像を構成する複数のフレームのうちＮＧのフレームを識別する識別情報を出力するように、画像審査モデル１５９を学習させてもよい。
【0074】
映像の長さ、フレームレートが予め設定されている場合、ＮＧのフレーム（連続する複数のフレームでもよい）が分かれば、例えば、映像の開始から何秒後のフレームに異常があるか容易に把握することができる。
【0075】
また、制御部１１は、画像審査モデル１５９が、取得した映像を構成する複数のフレームのうちＮＧのフレーム内の画像情報を出力するように、画像審査モデル１５９を学習させてもよい。例えば、供養者が居眠りをしている場合、当該画像のサムネイル（画像情報）を出力することができる。また、音声又はテキストが異常である場合、当該音声又はテキストを出力することができる。これにより、音声データの異常な部分を把握することができる。
【0076】
なお、画像審査モデル１５９及び音声審査モデル１６０は、供養審査装置１に記憶される代わりに、端末２に記憶され、端末２により供養を審査することにしてもよい。
また、画像の審査及び音声の審査は、二つの学習モデルにより各別に行うのではなく、一つの学習モデルにより行うことにしてもよい。この場合、画像の内容を音声と照らし合わせた上で、異常を含むか否かを判定する。
また、画像の審査及び音声の審査は、二つの学習モデルにより各別に行うのではなく、一つの学習モデルにより行うことにしてもよい。この場合、画像の内容を音声と照らし合わせた上で、異常を含むか否かを判定する。
【0077】
以下、供養審査装置１による供養の審査処理について詳述する。
供養者は端末２により供養の状況を撮像できるように、端末２を自身に向けて配置する。
図１７は、制御部１１による画像及び音声の審査処理の手順を示すフローチャートである。制御部１１は、下記の審査処理の前に、端末２に、所定の供養の時期が到来したことを報知してもよい。また、被供養者に遺族が存在する場合、遺族が、端末２に所定の供養の開始時間の指示を行ってもよい。遺族がいる場合、供養内容（一連の供養の映像、音声）が遺族へ送信される。供養は日の出から開始してもよいが、日没までに終了することとし、午前中に終了するのがより好ましい。
供養者がアプリケーションを起動することにより、制御部２１は、アプリプログラム２６１を読み出す（Ｓ２０１）。アプリケーションの起動により、図１８に示す画面が端末２の表示パネルに表示される。画面には、「供養者情報送信」、「供養対象情報送信」、「位置情報送信」、「日時情報送信」、「映像取得」、「映像送信」、及び「エラー」の
ボタンが表示される。供養者が端末２の撮像部２８により自身の写真を撮像し、又は端末
２のマイクロフォン２７に向かって名乗る等した後、「供養者情報送信」ボタンをタップすることにより、制御部２１は供養者情報を供養審査装置１へ送信する（Ｓ２０２）。
制御部１１は、供養者情報を受信する（Ｓ１０１）。
供養者は端末２により供養の状況を撮像できるように、端末２を自身に向けて配置する。
図１７は、制御部１１による画像及び音声の審査処理の手順を示すフローチャートである。制御部１１は、下記の審査処理の前に、端末２に、所定の供養の時期が到来したことを報知してもよい。また、被供養者に遺族が存在する場合、遺族が、端末２に所定の供養の開始時間の指示を行ってもよい。遺族がいる場合、供養内容（一連の供養の映像、音声）が遺族へ送信される。供養は日の出から開始してもよいが、日没までに終了することとし、午前中に終了するのがより好ましい。
供養者がアプリケーションを起動することにより、制御部２１は、アプリプログラム２６１を読み出す（Ｓ２０１）。アプリケーションの起動により、図１８に示す画面が端末２の表示パネルに表示される。画面には、「供養者情報送信」、「供養対象情報送信」、「位置情報送信」、「日時情報送信」、「映像取得」、「映像送信」、及び「エラー」の
ボタンが表示される。供養者が端末２の撮像部２８により自身の写真を撮像し、又は端末
２のマイクロフォン２７に向かって名乗る等した後、「供養者情報送信」ボタンをタップすることにより、制御部２１は供養者情報を供養審査装置１へ送信する（Ｓ２０２）。
制御部１１は、供養者情報を受信する（Ｓ１０１）。
【0078】
供養者が位牌６に付されたＱＲコードを撮像部２８により撮像して読み取り、「供養対象情報送信」ボタンをタップすることにより、制御部２１は供養対象情報を供養審査装置１へ送信する（Ｓ２０３）。
制御部１１は、供養対象情報を受信する（Ｓ１０２）。
供養者が「位置情報送信」ボタンをタップすることにより、制御部２１はＧＰＳ受信部２９から位置情報を取得し、位置情報を供養審査装置１へ送信する（Ｓ２０４）。
制御部１１は、位置情報を受信する（Ｓ１０３）。
供養者が「日時情報送信」ボタンをタップすることにより、制御部２１は時計部３０から日時情報を取得し、日時情報を供養審査装置１へ送信する（Ｓ２０５）。
制御部１１は、日時情報を受信する（Ｓ１０４）。
制御部１１は、供養対象情報を受信する（Ｓ１０２）。
供養者が「位置情報送信」ボタンをタップすることにより、制御部２１はＧＰＳ受信部２９から位置情報を取得し、位置情報を供養審査装置１へ送信する（Ｓ２０４）。
制御部１１は、位置情報を受信する（Ｓ１０３）。
供養者が「日時情報送信」ボタンをタップすることにより、制御部２１は時計部３０から日時情報を取得し、日時情報を供養審査装置１へ送信する（Ｓ２０５）。
制御部１１は、日時情報を受信する（Ｓ１０４）。
【0079】
制御部１１は、供養者情報、供養対象情報、位置情報、及び日時情報の全ての情報がＯＫであるか否かを被供養者ＤＢ１５２、供養者ＤＢ１５３、及び供養ＤＢ１５４に基づいて判定する（Ｓ１０５）。制御部１１は、供養対象に対応する被供養者が被供養者ＤＢ１５２に記憶され、供養者が供養者ＤＢ１５３に記憶されていることを確認する。そして、位置情報から得られた住所及び寺名が供養者ＤＢ１５３の内容と一致するか否かを判定し、日時が供養ＤＢ１５４の供養の内容の日時と一致するか否かを判定する。例えば月供養の場合、日時が月命日と±３日以内であるとき、回忌法要の場合、±２ヶ月以内であるとき、供養の内容の日時と一致すると判定する。数値はこの場合に限定されない。制御部１１はＯＫでないと判定した場合（Ｓ１０５：ＮＯ）、エラーメッセージを端末２へ送信し（Ｓ１０６）、処理を終了する。端末２の表示パネル２５において、「エラー」のボタンが点滅する。供養者が「エラー」のボタンをタップした場合、図１９に示すように、「供養者」、「被供養者」、「日時」、「位置」、及び「時間」のボタンが表示され、ＮＧの理由のボタンが点滅する。例えば「日時」が間違っている場合、「日時」のボタンが点滅する。
【0080】
制御部１１は、全ての情報がＯＫであると判定した場合（Ｓ１０５：ＹＥＳ）、映像送信の指示を端末２へ送信する（Ｓ１０７）。
供養者が「映像取得」ボタンをタップすることにより、撮像部２８により供養の撮像が開始され、制御部２１は映像を取得する（Ｓ２０６）。
供養者が「映像送信」ボタンをタップすることにより、制御部２１は映像を供養審査装置１へ送信する（Ｓ２０７）。供養の間、映像が送信される。供養者が「映像取得」ボタンを再度タップすることにより、撮像は終了する。供養者は供養が終了し、撮像が終了した後、映像を送信してもよい。
制御部１１は、映像を受信する（Ｓ１０８）。
供養者が「映像取得」ボタンをタップすることにより、撮像部２８により供養の撮像が開始され、制御部２１は映像を取得する（Ｓ２０６）。
供養者が「映像送信」ボタンをタップすることにより、制御部２１は映像を供養審査装置１へ送信する（Ｓ２０７）。供養の間、映像が送信される。供養者が「映像取得」ボタンを再度タップすることにより、撮像は終了する。供養者は供養が終了し、撮像が終了した後、映像を送信してもよい。
制御部１１は、映像を受信する（Ｓ１０８）。
【0081】
制御部１１は、時計部３０により計時した供養の時間が供養の内容に応じてＯＫであるか否かを判定する（Ｓ１０９）。制御部１１はＯＫでないと判定した場合（Ｓ１０９：ＮＯ）、処理をＳ１０６へ進め、処理を終了する。制御部１１は、表示パネル２５において、「エラー」を点滅させ、供養者が「エラー」のボタンをタップした場合、「時間」のボタンを点滅させる。
【0082】
制御部１１はＯＫであると判定した場合（Ｓ１０９：ＹＥＳ）、映像から取り出したフレーム単位の画像を画像審査モデル１５９に入力する（Ｓ１１０）。
制御部１１は、画像審査モデル１５９が出力した画像審査結果がＯＫであるか否かを判定する（Ｓ１１１）。制御部１１は画像審査モデル１５９が出力した異常値を閾値と比較して、審査結果がＯＫであるか否かを判定する。
制御部１１は画像審査結果がＯＫでないと判定した場合（Ｓ１１１：ＮＯ）、供養のやり直しの指示を端末２に送信し（Ｓ１１２）、ＮＧの証拠を端末２の表示パネル２５に表示し（Ｓ１１３）、処理を終了する。
制御部１１は、画像審査モデル１５９が出力した画像審査結果がＯＫであるか否かを判定する（Ｓ１１１）。制御部１１は画像審査モデル１５９が出力した異常値を閾値と比較して、審査結果がＯＫであるか否かを判定する。
制御部１１は画像審査結果がＯＫでないと判定した場合（Ｓ１１１：ＮＯ）、供養のやり直しの指示を端末２に送信し（Ｓ１１２）、ＮＧの証拠を端末２の表示パネル２５に表示し（Ｓ１１３）、処理を終了する。
【0083】
図２０は、表示パネル２５に表示される表示画面の一例を示す説明図である。制御部１１は、供養者が居眠りをしている状態を画像ＩＤ及びＮＧの理由とともに示す。制御部１１は、画像ＤＢ１５５から画像審査モデル１５９に入力したフレーム数に対応する画像を読み出し、表示パネル２５に、画像を順番に表示する。制御部１１は、供養者が居眠りしている画像（図２０においては連続する二つの画像）を経過時間とともに表示する。複数の画像に跨って目をつぶっていることから瞬きと区別される。画面には、「認める」、及び「認めない」のボタンも表示され、供養者がいずれかのボタンをタップして、入力することが可能である。
【0084】
制御部１１は画像審査結果がＯＫであると判定した場合（Ｓ１１１：ＹＥＳ）、音及びテキストを音声審査モデル１６０に入力する（Ｓ１１４）。
制御部１１は、音声審査モデル１６０が出力した音声の審査結果がＯＫであるか否かを判定する（Ｓ１１５）。制御部１１は音声審査モデル１６０が出力した異常値を閾値と比較して、審査結果がＯＫであるか否かを判定する。制御部１１は音声の審査結果がＯＫでないと判定した場合（Ｓ１１５：ＮＯ）、処理をＳ１１２へ進める。Ｓ１１３で、例えばテキストの内容が異常である場合、図２１に示すように、音声ＩＤとともに、正常のテキストと実際のテキストとが併記される。
制御部１１は音声の審査結果がＯＫであると判定した場合（Ｓ１１５：ＹＥＳ）、処理を終了する。
制御部１１は、音声審査モデル１６０が出力した音声の審査結果がＯＫであるか否かを判定する（Ｓ１１５）。制御部１１は音声審査モデル１６０が出力した異常値を閾値と比較して、審査結果がＯＫであるか否かを判定する。制御部１１は音声の審査結果がＯＫでないと判定した場合（Ｓ１１５：ＮＯ）、処理をＳ１１２へ進める。Ｓ１１３で、例えばテキストの内容が異常である場合、図２１に示すように、音声ＩＤとともに、正常のテキストと実際のテキストとが併記される。
制御部１１は音声の審査結果がＯＫであると判定した場合（Ｓ１１５：ＹＥＳ）、処理を終了する。
【0085】
なお、図１７のフローチャートでは、映像の画像を審査した後、音声の審査を行っているが、この場合に限定されず、音声を審査した後、映像の審査を行ってもよく、同時に審査を行ってもよい。
【0086】
制御部１１は、映像の審査結果及び音声の審査結果がＯＫであると判定した場合、明細書ＤＢ１５７から被供養者に対応する明細書を読み出し、図１０に示すように、今回の供養の日時、供養の内容、供養費用、運営管理会社手数料、及び残高を書き込む。そして、スタッフＡの端末３、及び運営管理会社のスタッフＢの端末４に、映像及び明細書を送信する。各スタッフは映像及び明細書の内容を人的に審査し、映像の審査結果と、審査を行った者の手数料を加えた明細書を供養審査装置１へ送信する。供養審査装置１はスタッフのＩＤを確認した後、審査がＯＫであるか否か、及び明細書がＯＫであるか否かを判定する。
【0087】
図２２及び図２３は、制御部１１により端末３及び４から審査結果を取得する処理の手順を示すフローチャートである。
制御部１１は、端末３及び４へ映像及び明細書を送信する（Ｓ１２１）。
制御部３１又は４１は映像及び明細書を受信する（Ｓ３０１、Ｓ４０１）。
制御部３１又は４１は、スタッフＡ又はＢが操作部３４又は４４により入力したスタッフＩＤを受け付ける（Ｓ３０２、Ｓ４０２）。
制御部３１又は４１は、スタッフＩＤを送信する（Ｓ３０３、Ｓ４０３）。
制御部１１は、スタッフＩＤを受信する（Ｓ１２２）。
制御部１１は、端末３及び４へ映像及び明細書を送信する（Ｓ１２１）。
制御部３１又は４１は映像及び明細書を受信する（Ｓ３０１、Ｓ４０１）。
制御部３１又は４１は、スタッフＡ又はＢが操作部３４又は４４により入力したスタッフＩＤを受け付ける（Ｓ３０２、Ｓ４０２）。
制御部３１又は４１は、スタッフＩＤを送信する（Ｓ３０３、Ｓ４０３）。
制御部１１は、スタッフＩＤを受信する（Ｓ１２２）。
【0088】
制御部１１は、審査関連ＤＢ１５８に基づいて、スタッフＡのＩＤがＯＫであるか否かを判定する（Ｓ１２３）。制御部１１は、スタッフＡのＩＤがＯＫでないと判定した場合（Ｓ１２３：ＮＯ）、端末３へエラーメッセージを送信し（Ｓ１２４）、処理を終了する。
制御部１１はスタッフＡのＩＤがＯＫであると判定した場合（Ｓ１２３：ＹＥＳ）、スタッフＢのＩＤがＯＫであるか否かを判定する（Ｓ１２５）。制御部１１は、スタッフＢのＩＤがＯＫでないと判定した場合（Ｓ１２５：ＮＯ）、端末４へエラーメッセージを送信し（Ｓ１２６）、処理を終了する。
制御部１１はスタッフＡのＩＤがＯＫであると判定した場合（Ｓ１２３：ＹＥＳ）、スタッフＢのＩＤがＯＫであるか否かを判定する（Ｓ１２５）。制御部１１は、スタッフＢのＩＤがＯＫでないと判定した場合（Ｓ１２５：ＮＯ）、端末４へエラーメッセージを送信し（Ｓ１２６）、処理を終了する。
【0089】
制御部１１は、スタッフＢのＩＤがＯＫであると判定した場合（Ｓ１２５：ＹＥＳ）、端末３及び４に、スタッフＡ又はＢによる映像の審査Ａ又はＢの結果、及び明細書の確認結果の送信を指示する（Ｓ１２７）。
制御部３１又は４１はスタッフＡ又はＢが操作部３４又は４４により入力した審査結果、及び明細書の確認結果を受け付ける（Ｓ３０４、Ｓ４０４）。スタッフＡ又はＢは審査結果がＯＫかＮＧか、明細書の確認結果がＯＫかＮＧかを入力する。審査結果又は明細書の確認結果がＮＧである場合、その理由も入力する。
制御部３１又は４１は、審査結果及び明細書の確認結果を送信する（Ｓ３０５、Ｓ４０５）。
制御部３１又は４１はスタッフＡ又はＢが操作部３４又は４４により入力した審査結果、及び明細書の確認結果を受け付ける（Ｓ３０４、Ｓ４０４）。スタッフＡ又はＢは審査結果がＯＫかＮＧか、明細書の確認結果がＯＫかＮＧかを入力する。審査結果又は明細書の確認結果がＮＧである場合、その理由も入力する。
制御部３１又は４１は、審査結果及び明細書の確認結果を送信する（Ｓ３０５、Ｓ４０５）。
【0090】
制御部１１は、端末３及び４から審査結果及び明細書の確認結果を受信する（Ｓ１２８）。
【0091】
制御部１１は、スタッフＡの審査結果がＯＫであるか否かを判定する（Ｓ１２９）。制御部１１は、スタッフＡの審査結果がＯＫでないと判定した場合（Ｓ１２９：ＮＯ）、供養のやり直しの指示を端末２へ送信し（Ｓ１３０）、ＮＧの理由を表示パネル２５に表示し（Ｓ１３１）、処理を終了する。ＮＧの理由として、供養者の居眠り等が挙げられる。
制御部１１はスタッフＡの審査結果がＯＫであると判定した場合（Ｓ１２９：ＹＥＳ）、スタッフＢの審査結果がＯＫであるか否かを判定する（Ｓ１３２）。制御部１１は、スタッフＢの審査結果がＯＫでないと判定した場合（Ｓ１３２：ＮＯ）、処理をＳ１３０へ進める。
制御部１１はスタッフＡの審査結果がＯＫであると判定した場合（Ｓ１２９：ＹＥＳ）、スタッフＢの審査結果がＯＫであるか否かを判定する（Ｓ１３２）。制御部１１は、スタッフＢの審査結果がＯＫでないと判定した場合（Ｓ１３２：ＮＯ）、処理をＳ１３０へ進める。
【0092】
制御部１１はスタッフＢの審査結果がＯＫであると判定した場合（Ｓ１３２：ＹＥＳ）、スタッフＡの明細書確認結果がＯＫであるか否かを判定する（Ｓ１３３）。制御部１１は明細書確認結果がＯＫでないと判定した場合（Ｓ１３３：ＮＯ）、ＮＧの理由に基づいて明細書を書き直し（Ｓ１３４）、処理をＳ１３６へ進める。
制御部１１は明細書確認結果がＯＫであると判定した場合（Ｓ１３３：ＹＥＳ）、スタッフＢの明細書確認結果がＯＫであるか否かを判定する（Ｓ１３５）。制御部１１は明細書確認結果がＯＫでないと判定した場合（Ｓ１３５：ＮＯ）、処理をＳ１３４へ進める。
制御部１１は明細書確認結果がＯＫであると判定した場合（Ｓ１３５：ＹＥＳ）、審査Ａ、Ｂの手数料を明細書に追記する（Ｓ１３６）。図２４は、審査Ａ、Ｂの手数料が追記された明細書を示す説明図である。
制御部１１は、審査ＯＫを端末２へ送信し（Ｓ１３７）。端末２への送金処理を行い（Ｓ１３８）、処理を終了する。
制御部１１は明細書確認結果がＯＫであると判定した場合（Ｓ１３３：ＹＥＳ）、スタッフＢの明細書確認結果がＯＫであるか否かを判定する（Ｓ１３５）。制御部１１は明細書確認結果がＯＫでないと判定した場合（Ｓ１３５：ＮＯ）、処理をＳ１３４へ進める。
制御部１１は明細書確認結果がＯＫであると判定した場合（Ｓ１３５：ＹＥＳ）、審査Ａ、Ｂの手数料を明細書に追記する（Ｓ１３６）。図２４は、審査Ａ、Ｂの手数料が追記された明細書を示す説明図である。
制御部１１は、審査ＯＫを端末２へ送信し（Ｓ１３７）。端末２への送金処理を行い（Ｓ１３８）、処理を終了する。
【0093】
図２５は、端末２の表示パネル２５の表示画面の一例を示す説明図である。
画面には、審査がＯＫであったこと、並びに供養の振り込み料の額、振り込み口座、及び日時が記載されている。供養の費用は、予め登録された金融機関口座に現金振り込みする場合に限定されず、仮想通貨により支払われてもよい。また、スマホ決済でもよい。
画面には、審査がＯＫであったこと、並びに供養の振り込み料の額、振り込み口座、及び日時が記載されている。供養の費用は、予め登録された金融機関口座に現金振り込みする場合に限定されず、仮想通貨により支払われてもよい。また、スマホ決済でもよい。
【0094】
本実施の形態によれば、被供養者及び供養者の正否を判定した後、取得した供養状況に基づいて供養の正否を判定するので、正しい供養者により、正しい供養対象者に対し、居眠り等の異常所作がなく、正しく供養が行われたか否かを良好に判定できる。
画像審査モデル１５９及び音声審査モデル１６０によりＯＫと判定された場合にスタッフＡ及びＢによる供養の審査結果を受け付け、審査結果によりＯＫと判定されたときに、供養はＯＫであると判定するので、審査の精度は良好である。
明細書を検証するので、供養の費用の支払いが正しいか否かを判定できる。
画像審査モデル１５９及び音声審査モデル１６０によりＯＫと判定された場合にスタッフＡ及びＢによる供養の審査結果を受け付け、審査結果によりＯＫと判定されたときに、供養はＯＫであると判定するので、審査の精度は良好である。
明細書を検証するので、供養の費用の支払いが正しいか否かを判定できる。
【0095】
なお、前記実施の形態においては、映像の審査及び音声の審査を行う場合につき説明しているが、これに限定されない。映像又は音声のみ審査してもよい。
また、前記実施の形態においては、撮像部２８により位牌６のＱＲコードを読み取って供養対象情報を取得する場合につき説明しているが、これに限定されない。位牌６にＩＣタグを取り付け、端末２はＩＣタグリーダを備えており、ＩＣタグリーダによりＩＣタグの情報を取得してもよい。
また、前記実施の形態においては、撮像部２８により位牌６のＱＲコードを読み取って供養対象情報を取得する場合につき説明しているが、これに限定されない。位牌６にＩＣタグを取り付け、端末２はＩＣタグリーダを備えており、ＩＣタグリーダによりＩＣタグの情報を取得してもよい。
【0096】
（実施の形態２）
図２６は、実施の形態２に係る供養審査システムの構成の一例を示す模式図である。実施の形態２に係る供養審査システムにおいては、ブロックチェーン５がさらにネットワークＮに接続されている。
ブロックチェーン５は、複数のノードにより構成され、分散型台帳技術又は分散型ネットワークの一種である。供養審査装置１もノードを構成してもよい。ブロックチェーン５は、ブロックと呼ばれるデータの単位を一定時間ごとに生成し、鎖のように連結していくことによりデータを保管する。ブロックチェーン５は、ピアツーピア（Peer to Peer）ネットワークと分散型タイムスタンプサーバの使用により自律的に管理される。鎖状に保存することによって、ブロック内のデータを一度記憶した場合、該データを遡及的に変更することができない。ブロックチェーン５は、パブリック型、プライベート型のいずれであってもよい。本実施の形態では、供養の記録と費用の支払いとをブロックチェーン５で実装する。仮想通貨としては、スマートコントラクトを実装可能なイーサリアム、Hyperledger等を用いればよい。
図２６は、実施の形態２に係る供養審査システムの構成の一例を示す模式図である。実施の形態２に係る供養審査システムにおいては、ブロックチェーン５がさらにネットワークＮに接続されている。
ブロックチェーン５は、複数のノードにより構成され、分散型台帳技術又は分散型ネットワークの一種である。供養審査装置１もノードを構成してもよい。ブロックチェーン５は、ブロックと呼ばれるデータの単位を一定時間ごとに生成し、鎖のように連結していくことによりデータを保管する。ブロックチェーン５は、ピアツーピア（Peer to Peer）ネットワークと分散型タイムスタンプサーバの使用により自律的に管理される。鎖状に保存することによって、ブロック内のデータを一度記憶した場合、該データを遡及的に変更することができない。ブロックチェーン５は、パブリック型、プライベート型のいずれであってもよい。本実施の形態では、供養の記録と費用の支払いとをブロックチェーン５で実装する。仮想通貨としては、スマートコントラクトを実装可能なイーサリアム、Hyperledger等を用いればよい。
【0097】
制御部１１が供養者情報、供養対象情報、位置情報、及び映像を端末２から受信し、画像審査モデル１５９により画像の異常値を取得し、音声審査モデル１６０により音声の異常値を取得し、画像及び音声の審査結果がＯＫである場合にスタッフＡ及びＢによる審査結果を受信するまでの処理は、実施の形態１に係る制御部１１の処理と同様である。
【0098】
制御部１１は、「画像審査モデル１５９及び音声審査モデル１６０、スタッフＡ、及びスタッフＢによる審査結果並びに明細書の確認結果がＯＫである場合、供養者、運営管理会社、スタッフＡ、及びスタッフＢに手数料として仮想通貨量を夫々のウォレットアドレスへ送信する」というスマートコントラクトのコードを作成する。スマートコントラクトの条件は、上述の場合に限定されない。例えば「画像審査モデル１５９及び音声審査モデル１６０、スタッフＡ、及びスタッフＢによる審査結果のいずれかがＯＫである場合」にしてもよく、明細書の確認結果は条件に含めないことにしてもよい。
制御部１１はブロックチェーン５にスマートコントラクトＩＤを付与してスマートコントラクトを送信し、ブロックチェーン５に記録する。
制御部１１はブロックチェーン５にスマートコントラクトＩＤを付与してスマートコントラクトを送信し、ブロックチェーン５に記録する。
【0099】
制御部１１は、図２７に示すように、被供養者に関連する代理店としての信託会社のウォレットアドレスＡＡＡから、スマートコントラクトアドレス（スマートコントラクトＩＤ「０１」）宛として、供養に対するデポジットとなる仮想通貨量（図２７では５コイン）を含むトランザクションをブロックチェーン５へ送信する。ウォレットアドレスＡＡＡは、スタッフＡの端末３又はスタッフＢの端末４のウォレットアドレスでもよい。
制御部１１は、画像審査モデル１５９及び音声審査モデル１６０、スタッフＡ、及びスタッフＢによる審査結果並びに明細書の確認結果がＯＫである場合、ブロックチェーン５によりスマートコントラクトの処理を実行する。取引が承認された場合、供養者の端末２のウォレットアドレスＢＢＢ宛として、デポジットとなった仮想通貨量の一部の仮想通貨量（図２７では５コイン）を含むトランザクションを端末２へ送信する。
同様に、端末３及び４のウォレットアドレス宛として、デポジットとなった仮想通貨量の一部の仮想通貨量を含むトランザクションをブロックチェーン５へ送信する。
ウォレットアドレスは、取引ごとに作成された仮想通貨用の口座番号であり、文字列又はＱＲコード（登録商標）として表示する。ウォレットアドレスは、ブロックチェーン５で利用されている公開鍵暗号を基にして、数学的に導出されたアドレスである。送信元と送信先のウォレットアドレスは、ブロックチェーン５に記録され、ブロックチェーン５のシステムが維持し続ける限り改ざんされない。
制御部１１は、画像審査モデル１５９及び音声審査モデル１６０、スタッフＡ、及びスタッフＢによる審査結果並びに明細書の確認結果がＯＫである場合、ブロックチェーン５によりスマートコントラクトの処理を実行する。取引が承認された場合、供養者の端末２のウォレットアドレスＢＢＢ宛として、デポジットとなった仮想通貨量の一部の仮想通貨量（図２７では５コイン）を含むトランザクションを端末２へ送信する。
同様に、端末３及び４のウォレットアドレス宛として、デポジットとなった仮想通貨量の一部の仮想通貨量を含むトランザクションをブロックチェーン５へ送信する。
ウォレットアドレスは、取引ごとに作成された仮想通貨用の口座番号であり、文字列又はＱＲコード（登録商標）として表示する。ウォレットアドレスは、ブロックチェーン５で利用されている公開鍵暗号を基にして、数学的に導出されたアドレスである。送信元と送信先のウォレットアドレスは、ブロックチェーン５に記録され、ブロックチェーン５のシステムが維持し続ける限り改ざんされない。
【0100】
図２８は、スマートコントラクトの成立処理の手順を示すフローチャートである。
制御部１１は、前記スマートコントラクトのコードを作成する（Ｓ１４１）。
制御部１１は、スマートコントラクトＩＤを付与してスマートコントラクトをブロックチェーン５に送信する（Ｓ１４２）。
ブロックチェーン５は、スマートコントラクトを受信する（Ｓ５０１）。
ブロックチェーン５は、スマートコントラクトを記録する（Ｓ５０２）。
制御部１１は、前記スマートコントラクトのコードを作成する（Ｓ１４１）。
制御部１１は、スマートコントラクトＩＤを付与してスマートコントラクトをブロックチェーン５に送信する（Ｓ１４２）。
ブロックチェーン５は、スマートコントラクトを受信する（Ｓ５０１）。
ブロックチェーン５は、スマートコントラクトを記録する（Ｓ５０２）。
【0101】
制御部１１は、被供養者に関連する信託会社のウォレットアドレスＡＡＡを取得する（Ｓ１４３）。
制御部１１は、ウォレットアドレスＡＡＡからスマートコントラクトＩＤ「０１」宛へ仮想通貨量（例えば５０コイン）を送信する（Ｓ１４６）。
ブロックチェーン５は、仮想通貨量をデポジットする（Ｓ５０３）。
制御部１１は、ウォレットアドレスＡＡＡからスマートコントラクトＩＤ「０１」宛へ仮想通貨量（例えば５０コイン）を送信する（Ｓ１４６）。
ブロックチェーン５は、仮想通貨量をデポジットする（Ｓ５０３）。
【0102】
制御部１１は、スマートコントラクトの発動トリガをブロックチェーン５へ送信する（Ｓ１４７）。発動トリガは、例えば「画像審査モデル１５９及び音声審査モデル１６０、スタッフＡ、及びスタッフＢによる審査結果並びに明細書の確認結果がＯＫである」という情報である。
ブロックチェーン５は、発動トリガを受信する（Ｓ５０４）。明細書の情報としては、図２３に示す内容が仮想通貨量に換算されている。
ブロックチェーン５は、スマートコントラクトの処理を実行する（Ｓ５０５）。
ブロックチェーン５は、取引の承認をブロックに記録する（Ｓ５０６）。これにより、公開鍵の宛先において、取引の承認の内容を確認することができる。
ブロックチェーン５は、発動トリガを受信する（Ｓ５０４）。明細書の情報としては、図２３に示す内容が仮想通貨量に換算されている。
ブロックチェーン５は、スマートコントラクトの処理を実行する（Ｓ５０５）。
ブロックチェーン５は、取引の承認をブロックに記録する（Ｓ５０６）。これにより、公開鍵の宛先において、取引の承認の内容を確認することができる。
【0103】
ブロックチェーン５は取引の承認を供養審査装置１及び端末２へ送信する（Ｓ５０７）。
制御部１１は取引の承認を受信し（Ｓ１４８）、端末２の制御部２１は取引の承認を受信する（Ｓ２１１）。
ブロックチェーン５は、デポジットとなった仮想通貨量の一部（例えば５コイン）を供養者の端末２のウォレットアドレスＢＢＢ５へ送信し（Ｓ５０８）、制御部２１は仮想通貨量を受信し（Ｓ２１２）、処理を終了する。
スタッフＡ及びＢのウォレットアドレスにも同様にして、仮想通貨量が送信される。
なお、スマートコントラクトの取引承認はマイナーによって行ってもよい。
制御部１１は取引の承認を受信し（Ｓ１４８）、端末２の制御部２１は取引の承認を受信する（Ｓ２１１）。
ブロックチェーン５は、デポジットとなった仮想通貨量の一部（例えば５コイン）を供養者の端末２のウォレットアドレスＢＢＢ５へ送信し（Ｓ５０８）、制御部２１は仮想通貨量を受信し（Ｓ２１２）、処理を終了する。
スタッフＡ及びＢのウォレットアドレスにも同様にして、仮想通貨量が送信される。
なお、スマートコントラクトの取引承認はマイナーによって行ってもよい。
【0104】
図２９は、端末２の表示パネル２５の表示画面の一例を示す説明図である。
画面には、取引が承認されたこと、及びウォレットアドレスＢＢＢに○○コイン送信されたことが記載されている。
画面には、取引が承認されたこと、及びウォレットアドレスＢＢＢに○○コイン送信されたことが記載されている。
【0105】
本実施の形態によれば、画像審査モデル１５９及び音声審査モデル１６０、並びにスタッフＡ及びＢにより正と判定された場合に、ブロックチェーン５においてスマートコントラクト処理を実行し、取引が承認された場合に支払い処理が簡便に実行される。
【0106】
上記実施の形態は、制限的なものではない。本発明の範囲は、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
実施の形態１及び２においては、祭祀が供養である場合につき説明しているがこれに限定されず、神道において、本発明の祭祀方法は神職が祝詞を唱える場合にも適用される。
また、他宗教においても、死後の祭祀において適用される。
実施の形態１及び２においては、祭祀が供養である場合につき説明しているがこれに限定されず、神道において、本発明の祭祀方法は神職が祝詞を唱える場合にも適用される。
また、他宗教においても、死後の祭祀において適用される。
【符号の説明】
【0107】
１ 供養審査装置
２、３、４ 端末
１１、２１、３１ 制御部
１２、２２、３２ 主記憶部
１３、２３、３３ 通信部
２４、３４ 操作部
１５、２６、３６ 補助記憶部
１６、３０ 時計部
１５１ プログラム
１５９ 画像審査モデル
１６０ 音声審査モデル
５ ブロックチェーン
２、３、４ 端末
１１、２１、３１ 制御部
１２、２２、３２ 主記憶部
１３、２３、３３ 通信部
２４、３４ 操作部
１５、２６、３６ 補助記憶部
１６、３０ 時計部
１５１ プログラム
１５９ 画像審査モデル
１６０ 音声審査モデル
５ ブロックチェーン
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】