JP2016129000A - 履歴管理装置、履歴解析装置、履歴管理システム、履歴管理方法、及び履歴解析方法 - Google Patents

Abstract

【課題】公的扶助の不適格受給や目的外使用を低減できる履歴管理装置を提供する。【解決手段】ポイントの処理を通知するためのポイント処理情報を受信する通信部１１０と、ポイント処理情報が受信される度に、かつ、処理された所定のポイント毎に、ポイント処理情報に応じてポイントの処理履歴を示す由来情報を生成する制御部１２０と、生成された由来情報を蓄積する由来情報データベース１００Ａと、を備える。【選択図】図２

Description

本発明は、履歴管理装置、履歴解析装置、履歴管理システム、履歴管理方法、及び履歴解析方法に関する。

従来、特定の目的や特定の地域内（例えば市町村）や特定のコミュニティ（例えば商店街、町内会、ＮＰＯ（ＮｏｎＰｒｏｆｉｔ Ｏｒｇａｎｉｚａｔｉｏｎ））において限定的に流通する地域通貨が知られている。地域通貨は、法定貨幣と同等の価値又は法定貨幣と異なる価値がある貨幣して発行され、使用される。

地域通貨を扱うシステムとして、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）カード（電子ウォレット）やカードリーダのようなハードウェアを不要とした電子地域マネーシステムが知られている（例えば特許文献１参照）。このシステムは、運用コストの低減や地域活性化を可能にする。

また、地域通貨を扱うシステムとして、電子媒体を利用した地域通貨における地域特定ポイントの付与システムが知られている（例えば特許文献２参照）。このシステムは、電子マネーの利用と、地域毎に条件が異なる地域ポイント付与システムと、の連携を可能にする。

特開２００２−２７９３２４号公報 特開２０１２−６４００５号公報

今後、地域通貨を用いて公的扶助が行われることが予想される。この場合、特許文献１，２に記載された地域通貨を扱うシステムでは、公的扶助（例えば生活保護費）の不適格受給や目的外使用を低減することが困難である。

本発明は、上記事情に鑑みてなされたものであり、公的扶助の不適格受給や目的外使用を低減できる履歴管理装置、履歴解析装置、履歴管理システム、履歴管理方法、及び履歴解析方法を提供する。

本発明の履歴管理装置は、ポイントの処理を通知するためのポイント処理情報を受信する通信部と、前記ポイント処理情報が受信される度に、かつ、処理された所定のポイント毎に、前記ポイント処理情報に応じて前記ポイントの処理履歴を示す由来情報を生成する生成部と、生成された前記由来情報を蓄積する蓄積部と、を備える。

本発明の履歴解析装置は、ポイントが処理される度に、かつ、処理された所定のポイント毎に、前記ポイントの処理履歴を示す由来情報を生成し蓄積する履歴管理装置から、前記由来情報を取得する取得部と、前記由来情報に基づいて、前記ポイントの処理に係る統計情報を導出する導出部と、を備える。

本発明の履歴管理システムは、履歴管理装置及び履歴解析装置を備え、ポイント処理装置により処理されるポイントの処理履歴を管理する履歴管理システムであって、前記履歴管理装置は、前記ポイント処理装置から、前記ポイントの処理を通知するためのポイント処理情報を受信する通信部と、前記ポイント処理情報が受信される度に、かつ、処理された所定のポイント毎に、前記ポイント処理情報に応じて前記ポイントの処理履歴を示す由来情報を生成する生成部と、生成された前記由来情報を蓄積する蓄積部と、を備え、前記履歴解析装置は、前記履歴管理装置から前記由来情報を取得する取得部と、前記由来情報に基づいて、前記ポイントの処理に係る統計情報を導出する導出部と、を備える。

本発明の履歴管理方法は、履歴管理装置における履歴管理方法であって、ポイントの処理を通知するためのポイント処理情報を受信するステップと、前記ポイント処理情報が受信される度に、かつ、処理された所定のポイント毎に、前記ポイント処理情報に応じて前記ポイントの処理履歴を示す由来情報を生成するステップと、を備える。

本発明の履歴解析方法は、履歴解析装置における履歴解析方法であって、ポイントが処理される度に、かつ、処理された所定のポイント毎に、前記ポイントの処理履歴を示す由来情報を生成し蓄積する履歴管理装置から、前記由来情報を取得するステップと、前記由来情報に基づいて、前記ポイントの処理に係る統計情報を導出するステップと、を備える。

本発明によれば、公的扶助の不適格受給や目的外使用を低減できる。

実施形態における地域通貨システムの構成例を示すブロック図 実施形態における由来情報サーバの構成例を示すブロック図 実施形態における由来情報データベースが保持する由来情報の一例を示す模式図 実施形態における集計処理サーバの構成例を示すブロック図 実施形態におけるポイント毎の由来情報の第１表示例を示す模式図 実施形態におけるオーナー毎の由来情報の第２表示例を示す模式図 実施形態におけるポイント使用者毎の由来情報をウェブにより確認するための表示例を示す模式図

以下、本発明の実施形態について、図面を用いて説明する。

（本発明の一形態を得るに至った経緯）
公的扶助として生活保護費が支給される場合、生活保護費が支給される目的は予め定められている。一方、生活保護費の申請時とは異なる目的で生活保護費が使用されることがあった。例えば、住宅補助用の生活保護費が支給されたにも関わらず、この生活保護費の受給者が所定の場所に住んでいないことがあった。つまり、公的扶助が当初の目的外に使用されることがあった。

また、特定の者が、正当な生活保護費の受給者から生活保護費を収集することで、生活保護費が正当な受給者以外の者に使用されることもあった。この場合、生活保護費を受給すべきでない者に生活保護費が支給されていることと同義となり、公的扶助の不適格受給に繋がっていた。

このような事情に対して、一律に公的扶助を削減する場合、正当な受給者に対する生活保護費も含めて削減されることになる。公的扶助は、必要な人に対して必要な量に限り支給されることが望ましい。そのため、例えば、生活保護費等の公的扶助の使用過程を追跡する仕組みが検討されることが望ましい。

以下、公的扶助の不適格受給や目的外使用を低減できる履歴管理装置、履歴解析装置、履歴管理システム、履歴管理方法、及び履歴解析方法について説明する。

（実施形態）
図１は、実施形態における地域通貨システム１０の構成例を示すブロック図である。地域通貨システム１０は、カードリーダ２０、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）３０、認証サーバ４０、ポイント処理サーバ５０、マイナンバ照合サーバ６０、由来情報サーバ１００、バックアップサーバ１５０、及び集計処理サーバ２００を備える。地域通貨システム１０における各装置は、例えばネットワークを介して接続される。

カードリーダ２０及びＰＣ３０は、例えばインターネットに接続されてもよい。また、カードリーダ２０とポイント処理サーバ５０との間は、専用回線で接続されてもよい。

地域通貨システム１０は、履歴管理システムの一例である。由来情報サーバ１００は、履歴管理装置の一例である。集計処理サーバ２００は、履歴解析装置の一例である。

本実施形態では、一例として、公的扶助としての生活保護費が、生活保護費の受給者に対して、所定の自治体により地域通貨ポイント（以下、単に「ポイント」とも称する）で支給されることを想定する。つまり、ポイントの発行元は自治体である。

また、自治体により発行されるポイントは、予め使用されるべき目的（以下、「当初目的」とも称する）が定められている。当初目的は、例えば、教育費、住宅費、医療費、介護費、出産費、生業費、葬祭費、を含む。

また、生活保護費として発行されるポイントには、有効期限（例えば１か月）の情報が付加されてもよい。この場合、有効期限を超過してからポイントが使用されることを防止でき、生活保護費の受給者は、生活保護費を各種取引処理に使用できるが、生活保護費を貯蓄できない。

ポイントは、地域通貨と同様に使用されるので、様々な取引処理において使用される。取引処理は、例えば、物品の購入、サービスの購入、公共料金の支払、上記当初目的と同様の支払、を含む。取引処理が行われると、ポイントを保持するポイント保持者（「オーナー」とも称する）が変更される。取引処理は、複数回繰り返されてもよい。

取引処理後のオーナー（例えば、サービス提供者）は、取得したポイントを用いて更に取引可能であり、これによりポイントのオーナーは更に変更される。取引処理が繰り返さえることで、ポイントは順次変更されていく。オーナーは、必要に応じて、取引処理により取得したポイントを自治体で換金できる。これにより、ポイントが消滅する。

カード２５は、不図示であるが、例えば、通信部、制御部、及びカード情報データベース２５Ａを有する。カード情報データベース２５Ａは、例えば、カード２５を識別するための「カードＩＤ」、カード２５を所有するカード所有者（例えば受給者）を識別するための「カード所有者ＩＤ」、ポイント処理（例えばポイントの発行処理、ポイントの使用処理）が行われた「取引日」及び「取引時刻」の情報を有する。

カード２５は、例えば、マイナンバカードや住民基本台帳カード（住基カード）であり、公的扶助の受給者やサービス提供者により保持される。サービス提供者は、自治体から直接にポイント発行を受けないが、サービス提供者が提供するサービス等にポイントが使用されることで、オーナーとなり、ポイントの使用が可能となる。また、カード２５には、地域通貨ポイントのポイント以外のポイント（例えば電子マネー）を合わせて保持されてもよい。

カード２５が公的扶助の詳細等が含まれないことで、例えば、カード２５を紛失した際に、カード所有者に関する個人情報の漏洩を低減できる。

カードリーダ２０は、不図示であるが、例えば、操作部、制御部、通信部、記憶部を有する。カードリーダ２０は、例えば、様々な店舗、自治体の役所に配置される。カードリーダ２０は、ポイントの処理を指示した指示装置の一例である。

カードリーダ２０の制御部は、各種取引処理の際に、様々なカード２５（例えば、接触式ＩＣカード、非接触式ＩＣカード、磁気カード）から、各種情報（例えばカードＩＤ）を読み取る。

カードリーダ２０の通信部は、例えば、必要に応じて読み取られた情報、記憶部により記憶された情報、取引処理により発行又は使用されるポイント数の情報、を他の装置へ送信する。カードリーダ２０の記憶部は、例えばカードリーダ２０を識別するための機器ＩＤを保持する。

ＰＣ３０は、不図示であるが、例えば、操作部、表示部、制御部、通信部、記憶部を有する。ＰＣ３０は、例えば、操作部により入力されたデータに対して、制御部が所定の演算を行い、演算結果を表示部に表示する。ＰＣ３０は、例えば、自治体の役所や各種店舗に設置される。ＰＣ３０は、ポイントの処理を指示した指示装置の一例である。

ＰＣ３０の操作部は、ポイントに関する入力情報（例えば、ポイントの発行又は使用、ポイント発行数又はポイント使用数、の情報）を受け付ける。例えば、操作部は、受給者から公的扶助の申請があった場合に、操作部等を用いてポイント発行のための入力情報（例えば、ポイント発行数、ポイント発行の当初目的）を受け付ける。このポイントは、例えば、申請のあった公的扶助から生活費を除いた金額に相当するポイントである。尚、ポイントの発行時の処理は、ＰＣ３０のような汎用端末でなくてもよく、例えば、ポイント発行用の専用装置が役所内に設置されてもよい。例えば、カードリーダ２０によりポイント発行されてもよい。

また、ＰＣ３０の操作部は、例えば、カードリーダ２０の代わりに、ＰＣ３０の操作部を介して、ポイントに関する入力情報を受け付けてもよい。例えば、ＰＣ３０の操作部を介して、ポイントの発行や使用に係る取引処理が行われてもよい。

認証サーバ４０は、不図示であるが、例えば、認証処理部、通信部、記憶部を有する。認証サーバ４０の認証処理部は、例えば、カードリーダ２０又はＰＣ３０からのポイントの使用に関する認証処理を行う。認証サーバ４０は、例えば、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）−ＶＰＮ（Ｖｅｒｔｉａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）を用いる。

認証サーバ４０の認証処理部は、例えば、カードリーダ２０から取得した機器ＩＤ及びカードＩＤが正当なＩＤであるか否かを判定する。機器ＩＤ及びカードＩＤが正当なＩＤである場合、認証サーバ４０の認証処理部は、カードリーダ２０又はＰＣ３０とポイント処理サーバ５０との間の通信を許可する。

尚、認証サーバ４０とカードリーダ２０及びＰＣ３０との間には、ファイアウォールが設けられてもよい。

ポイント処理サーバ５０は、不図示であるが、例えば、通信部、制御部、記憶部を有する。ポイント処理サーバ５０の制御部は、ポイント処理（例えばポイントの発行処理、ポイントの使用処理）を行う。例えば、ポイント処理サーバ５０の制御部は、カードリーダ２０又はＰＣ３０からのポイントに関する情報を、ポイント処理サーバ５０が保持するポイント情報データベース５０Ａに反映する。

ポイント情報データベース５０Ａは、例えば、ポイント識別するためのポイントＩＤ、ポイントの所有者を識別するための「ポイント所有者ＩＤ」、ポイントの処理日、ポイントの処理時刻、の情報を保持する。ポイント所有者は、例えば、公的扶助の受給者、サービス提供者である。

ポイント処理サーバ５０は、例えば、カードリーダ２０等からのカードＩＤやカード所有者ＩＤに対応するポイント所有者ＩＤに対して、ポイント処理により発行又は使用されるポイント数をポイント残高から減額又は増額する。

例えば、ポイント処理サーバ５０の通信部は、ポイントが発行された場合、カードリーダ２０又はＰＣ３０からのカード所有者ＩＤを取得する。ポイント処理サーバ５０の制御部は、ポイント情報データベース５０Ａを参照し、カード所有者が保持するポイントに、発行ポイント数分を加算する。

例えば、ポイント処理サーバ５０の通信部は、ポイントが使用された場合、カードリーダ２０又はＰＣ３０からのカード所有者ＩＤを取得する。ポイント処理サーバ５０の制御部は、ポイント情報データベース５０Ａを参照し、カード所有者が保持するポイントから、使用ポイント数分を減算する。

ポイント処理サーバ５０は、ポイント処理（例えばポイントの使用又はポイントの付与）が発生する毎に、由来情報サーバ１００へその旨を通知する。

マイナンバ照合サーバ６０は、例えば、通信部、制御部、記憶部を有し、検疫用のサーバである。マイナンバ照合サーバ６０の制御部は、例えば、カードリーダ２０又はＰＣ３０からカード所有者ＩＤ（例えばマイナンバ）を取得し、取得されたカード所有者が、カード２５の使用を許可されているか否か等を判別する。

由来情報サーバ１００は、ポイント処理サーバ５０からポイント処理の情報を取得し、所定のポイント毎（例えば１ポイント毎、１０ポイント毎、１００ポイント毎）に、ポイントに対して由来情報を付加する。由来情報は、ポイントの処理履歴を示す。

また、由来情報サーバ１００は、ポイント処理が発生する毎に、由来情報を付加する。従って、ポイントが様々な場面で発行又は使用される度に、由来情報が増加する。例えば、生活保護者が、当初目的を医療費として支給されたポイントを医療費に使用すると、由来情報サーバ１００は、そのポイントに対して１つの由来情報を付加する。また、医療費としてポイントを受けた医療機関が、病院で使用する備品の購入にそのポイントを使用すると、由来情報サーバ１００は、そのポイントに対して１つの由来情報を付加する。この時点で、ポイントに対する由来情報は２つになる。このように、ポイント処理が行われる度に、由来情報が増加する。

尚、インターネットを介して複数の取引処理が行われた場合、由来情報サーバ１００が取引処理の通知を受信した順に由来情報が生成される。つまり、インターネットを介した取引処理に対する由来情報は、インターネット以外の取引処理に対する由来情報と同様に生成される。

バックアップサーバ１５０は、例えば、通信部、制御部、記憶部、を備える。バックアップサーバ１５０は、由来情報サーバ１００から由来情報を取得し、由来情報を保持する。バックアップサーバ１５０は、例えば、ポイント消滅後のポイントに係る由来情報を蓄積し、管理する。

尚、バックアップサーバ１５０は、バックアップサーバ１５０の記憶容量の残量が所定量以下となった場合に、外部記憶媒体（例えばＳＤカード、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ）に由来情報を記憶させてもよい。

集計処理サーバ２００は、由来情報サーバ１００やバックアップサーバ１５０から由来情報を収集し、由来情報に基づいて様々な統計、解析等を行う。

図２は、由来情報サーバ１００の構成例を示すブロック図である。

由来情報サーバ１００は、由来情報データベース１００Ａ、通信部１１０、制御部１２０を備える。

通信部１１０は、例えば、通信回線を介して、ポイント処理サーバ５０、バックアップサーバ１５０、及び集計処理サーバ２００との間で通信する。通信部１１０は、例えば、ポイントの処理（例えば発行、使用、削除）を通知するためのポイント処理情報（例えば、ポイント発行情報、ポイント使用情報、ポイント削除情報）を、ポイント処理サーバ５０から受信する。

制御部１２０は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）又はＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）又はＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を有する。ＣＰＵ又はＤＳＰが、ＲＯＭ又はＲＡＭに保持されたプログラムを事項することにより、制御部１２０が有する各種機能を実現する。

制御部１２０は、ポイント処理情報を取得する度に、また、処理された所定のポイント毎に、ポイント処理情報に基づいて由来情報を生成する。例えば、１万ポイントに対して、由来情報として１万の由来情報レコードが生成される。また、制御部１２０は、由来情報データベース１００Ａを管理する。従って、制御部１２０は、由来情報を生成する生成部の一例である。

図３は、由来情報データベース１００Ａに保持される由来情報の一例を示す模式図である。由来情報は、例えば、由来ＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、ポイントＩＤ、オーナーＩＤ、取引日、取引時刻、当初目的、取引目的、発生装置、オーナー参照、レベル、親の由来ＩＤ、の各情報を含む。由来情報データベース１００Ａは、由来情報を蓄積する蓄積部の一例である。

「由来ＩＤ」は、当該由来情報を識別するための識別情報である。「ポイントＩＤ」は、例えば、当該由来情報が発生する元となった（由来情報に係る）ポイントを識別するための識別情報である。「オーナーＩＤ」は、例えば、当該由来情報に係るポイントの取引処理後のオーナーを識別するための識別情報である。従って、オーナーＩＤを確認することで、現在のポイントのオーナーを確認できる。

「取引日」は、当該由来情報に係る取引処理が行われた日付の情報である。「取引時刻」は、当該由来情報に係る取引処理が行われた時刻の情報である。「当初目的」は、ポイントが発行される原因となった目的（例えば教育費）の情報であり、例えば、自治体においてどの公的扶助の申請に基づいて発行されたかを示す情報である。「取引目的」は、当該由来情報に係る取引処理の目的（例えば、公共料金の支払、上記当初目的の支払、食料品の購入、電化製品の購入）を含む。

「発生装置」は、例えば、取引処理に用いられた装置やインターネット上のサイトを識別するための識別情報（例えば、カードリーダ２０の機器ＩＤ、ＰＣ３０を使用する際のログインＩＤ）である。「オーナー参照」は、例えば、リンク先ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）の情報（例えば図７参照）である。

「レベル」は、当該由来情報に係るポイントの発行からの分岐（例えば図５〜７参照）の回数を示す。この分岐回数は、ポイントに対する取引処理の回数に相当し、取引処理によりポイントのオーナーが移行された回数に相当する。「親の由来ＩＤ」は、当該由来情報に係るポイントに対する前回の取引処理により生成された由来情報の由来ＩＤであり、つまり、今回の由来情報の直前に同じポイントに対して付された由来情報である。

上述したように、由来情報はポイントに対して付加されるが、由来情報を中心にみると、ポイントＩＤは由来情報をまとめるためのグループコードであるとも言える。

図４は、集計処理サーバ２００の構成例を示す模式図である。

集計処理サーバ２００は、通信部２１０、制御部２２０、操作部２３０、及び表示部２４０を備える。

通信部２１０は、例えば、通信回線を介して、由来情報サーバ１００及びバックアップサーバ１５０との間で通信する。通信部２１０は、例えば、由来情報サーバ１００又はバックアップサーバ１５０から由来情報を受信する。従って、通信部２１０は、由来情報を取得する取得部の一例である。

制御部２２０は、例えば、ＣＰＵ又はＤＳＰ、ＲＯＭ又はＲＡＭを有する。ＣＰＵ又はＤＳＰが、ＲＯＭ又はＲＡＭに保持されたプログラムを事項することにより、制御部２２０が有する各種機能を実現する。制御部２２０は、１つ以上の由来情報に基づいて、由来情報が付されたポイントの処理に係る統計情報を導出し、様々な集計、解析等を行う。つまり、制御部２２０は、統計情報を導出する導出部の一例である。

制御部２２０は、例えば、由来情報に含まれる様々な情報をキーとして、由来情報に含まれる様々な情報の統計処理を行うことで、特定の情報をキーとした解析を実施する。統計処理では、ポイントの処理に係る各種統計値（例えば、由来情報に含まれる各値の加算値、減算値、乗算値、除算値、平均値、最大値、最小値、中央値、その他の統計値）が導出される。

制御部２２０は、例えば、由来情報データベース１００Ａに蓄積された由来情報から、オーナーＩＤをキーとして、由来情報に含まれる取引目的に係る統計値を導出する。を参照することで、そのオーナーＩＤにより識別されるオーナーが、どのような取引処理にポイントを使用しているかを判別する。この場合、集計処理サーバ２００は、例えば、光熱費にポイントの８割を使用している、等を確認できる。

制御部２２０は、例えば、由来情報データベース１００Ａに蓄積された由来情報から、オーナーＩＤや取引目的の情報をキーとした統計値を算出する。これにより、集計処理サーバ２００は、例えば、医療費としてのポイントを取得した医者が、そのポイントを使用して様々な物品やサービスを購入していることを確認できる。

制御部２２０は、例えば、由来情報データベース１００Ａに蓄積された由来情報から、発生装置の情報やオーナーＩＤに係る統計値を導出する。これにより、集計処理サーバ２００は、例えば、住宅費としてのポイントの使用が、１つの不動産業者に集中していることを確認できる。

操作部２３０は、例えば、キーボード、マウス、タッチパネルにより構成され、各種入力情報を受け付ける。例えば、操作部２３０は、統計情報を導出すべき由来情報に含まれるキー（例えば、ポイントＩＤ、オーナーＩＤ）の入力を受け付ける。

表示部２４０は、例えばＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）により構成され、各種情報を表示する。例えば、表示部２４０は、解析対象のキー（例えばポイントＩＤ，オーナーＩＤ）を用いて抽出された複数の由来情報を、由来情報の生成時刻等に応じて関連付けて表示する。尚、表示部２４０は、集計処理サーバ２００とは別体の表示装置として設けられてもよい。

次に、地域通貨システム１０のポイント発行時の動作例について説明する。

ポイント処理サーバ５０は、ポイントが発行された場合、例えば、ポイントデータを、１ポイントにつき１レコード生成する。ポイント処理サーバ５０は、生成された１つのレコードに対応して、ポイント発行された旨を含むポイント発行情報を、由来情報サーバ１００へ通知する。また、ポイント処理サーバ５０は、例えばＰＣ３０（又はカードリーダ２０）から、ポイント発行を実施した装置の識別情報（又は機器ＩＤ）を受信する。

ポイント発行情報は、例えば、発行されたポイントレコードを識別するためのポイントＩＤ、発行されたポイントのポイント所有者ＩＤ（例えばマイナンバ）、ポイント発行日及びポイント発行時刻、ポイントが発行された公的扶助の種別（例えば、教育費）、ポイント発行したＰＣ３０の識別情報、を含む。ポイント所有者ＩＤは、公的扶助の受給者を識別するための受給者ＩＤ、カード２５のカード所有者ＩＤに相当する。

尚、ポイント処理サーバ５０は、１つのポイントレコードにつき、１つのポイント発行情報を通知してもよいし、ポイントＩＤをポイント発行分まとめて１つのポイント発行情報に格納して、１つのポイント発行情報を通知してもよい。

由来情報サーバ１００では、通信部１１０は、ポイント発行情報の通知を受信する。制御部１２０は、ポイント発行情報に含まれるポイントＩＤに関連付けて、由来ＩＤを発行して由来情報を生成する。従って、例えば、１つのポイントレコードに対して、１つの由来情報が生成される。由来情報は、由来ＩＤにより識別され、由来情報データベース１００Ａに保持される。

制御部１２０は、ポイント発行情報に含まれるポイントＩＤを、生成された由来情報の「ポイントＩＤ」に格納する。制御部１２０は、ポイント発行情報に含まれるポイント所有者ＩＤを、生成された由来情報の「オーナーＩＤ」に格納する。制御部１２０は、ポイント発行情報に含まれるポイント発行日及びポイント発行時刻の情報を、生成された由来情報の「取引日」及び「取引時刻」に格納する。

制御部１２０は、ポイント発行情報に含まれる公的扶助の種別の情報を、生成された由来情報の「当初目的」及び「取引目的」に格納する。制御部１２０は、ポイント発行情報に含まれるポイント発行したＰＣ３０の識別情報を、生成された由来情報の「発生装置」に格納する。尚、ポイント発行時には、先に行われた取引処理が存在しないので、生成された由来情報の「親の由来ＩＤ」はブランクとなる。

このような地域通貨システム１０のポイント発行時の動作により、ポイントに使用目的を付して、公的扶助の受給者に対して生活保護費等を支給できる。

次に、地域通貨システム１０のポイント使用時の動作例について説明する。

ポイント処理サーバ５０は、ポイントが使用された場合、例えば、カードリーダ２０から、カード所有者ＩＤや機器ＩＤを取得する。ポイント処理サーバ５０は、カードリーダ２０等からポイント使用に係る情報を受信すると、マイナンバ照合サーバ６０へ、カード２５の受給者ＩＤについて照合処理するよう要求する。

マイナンバ照合サーバ６０は、ポイント処理サーバ５０からカード所有者ＩＤに対応するポイント所有者ＩＤを受信する。マイナンバ照合サーバ６０は、ポイント所有者ＩＤが、公的扶助により発行されたポイントの使用が許可された正当なＩＤであるか否かを判別する。マイナンバ照合サーバ６０は、この判別結果を照合結果としてポイント処理サーバ５０へ通知する。

これにより、例えば、公的扶助の受給者として登録されていないカード使用者によるポイントの使用が不可能となる。

ポイント処理サーバ５０は、サービス提供者を識別するためのサービス提供者ＩＤが正当なＩＤであるか否かを照合する。この場合、例えば、サービス提供者ＩＤが、提供するサービスに対して受給者によるポイントの使用が認められたサービス提供者のＩＤ（許可提供者ＩＤ）であるか否かを判別する。尚、許可提供者ＩＤは、予めポイント処理サーバ５０の記憶部へ登録されている。

これにより、例えば、極端に公的扶助により発行されたポイントの使用が多いサービス提供者（例えば特定の医療機関、不動産業者の人）によるポイントの使用が不可能となる。

ポイント処理サーバ５０は、カード所有者のポイント残高を集計する。ポイント処理サーバ５０の制御部は、例えば、ポイント情報データベース５０Ａを参照し、カード所有者ＩＤに対応するポイント所有者ＩＤのポイントレコードのレコード数を算出する。レコードの個数が、ポイントの総数となり、カード所有者のポイント残高に相当する。

ポイント処理サーバ５０は、ポイント使用数とポイント残高とを比較し、取引可能か否かを判別する。

ポイント処理サーバ５０は、使用されたポイントのレコードに対応して、ポイント使用された旨を含むポイント使用情報を、由来情報サーバ１００へ通知する。

ポイント使用情報は、例えば、使用されたポイントレコードを識別するためのポイントＩＤ、使用されたポイントのポイント所有者ＩＤ（例えばマイナンバ）、ポイント使用日及びポイント使用時刻、ポイントが使用された目的（ポイント使用目的）、ポイントの使用に利用されたカードリーダ２０の機器ＩＤ又はＰＣ３０の識別情報、を含む。ポイント所有者ＩＤは、ポイントが使用されたサービス等の提供者を識別するためのサービス提供者ＩＤに相当する。

尚、ポイント処理サーバ５０は、１つの使用されたポイントレコードにつき、１つのポイント使用情報を通知してもよいし、ポイントＩＤをポイント使用分まとめて１つのポイント発行情報に格納して、１つのポイント使用情報を通知してもよい。

由来情報サーバ１００では、通信部１１０は、ポイント使用情報の通知を受信する。制御部１２０は、ポイント使用情報に含まれるポイントＩＤに関連付けて、由来ＩＤを発行して由来情報を生成する。従って、１つのポイントレコードに対して、１つの由来情報が生成される。由来情報は、由来ＩＤにより識別され、由来情報データベース１００Ａに保持される。

制御部１２０は、ポイント使用情報に含まれるポイントＩＤを、生成された由来情報の「ポイントＩＤ」に格納する。制御部１２０は、ポイント使用情報に含まれるポイント所有者ＩＤを、生成された由来情報の「オーナーＩＤ」に格納する。制御部１２０は、ポイント使用情報に含まれるポイント使用日及びポイント使用時刻の情報を、生成された由来情報の「取引日」及び「取引時刻」に格納する。

制御部１２０は、ポイント使用情報に含まれるポイント使用目的の情報を、生成された由来情報の「取引目的」に格納する。制御部１２０は、ポイント使用情報に含まれるポイントの使用に利用された機器ＩＤ又はＰＣ３０の識別情報を、生成された由来情報の「発生装置」に格納する。

また、制御部１２０は、由来情報データベース１００Ａにおいて上記のポイントＩＤをキーに検索し、通信部１１０は、前回に生成された由来情報の由来ＩＤを取得し、制御部１２０は、今回生成された由来情報の「親の由来ＩＤ」に格納する。

このような地域通貨システム１０のポイント使用時の動作により、ポイントの使用が許諾されたカード所有者（例えば正当な公的扶助の受給者、正当なサービス提供者）に限り、ポイントを使用できる。また、ポイントの使用の度に由来情報が生成されるので、集計処理サーバ２００等により由来情報を確認することで、ポイントの使用履歴を確認でき、過去の使用状況を追跡できる。

尚、制御部１２０は、ポイント所有者ＩＤのポイントレコード、つまり、ポイント所有者が所有するポイントのうち、使用されなかった未使用のポイントに対しても、使用されたポイントに対する由来情報と同様の情報を含めて、由来情報を生成する。但し、未使用のポイントに対する由来情報では、「オーナーＩＤ」は現オーナーのＩＤがセットされ、「取引日」及び「取引時刻」には、使用されたポイントの取引日及び取引時刻の情報がセットされ、「取引目的」及び「発生装置」には、ヌルがセットされる。

未使用のポイントに対して由来情報が生成されることで、集計処理サーバ２００は、例えば、「取引目的」及び「発生装置」がヌルである由来情報を検索することで、ポイント所有者が所有する未使用のポイントを集計できる。従って、集計処理サーバ２００は、例えば、未使用のポイントが付加された当初目的を由来情報から検索することで、以降のポイント発行時に、このポイント所有者に対する上記当初目的に係るポイントの発行を抑制するような対策を行うことができる。

次に、地域通貨システム１０のポイント削除時の動作例について説明する。

ポイントの最終所有者（サービス提供者）からポイント換金の申し出があった場合、地域通貨システム１０は、換金処理を行う。例えば、自治体のＰＣ３０は、換金処理の開始指示と、課金処理を申し出たサービス提供者のサービス提供者ＩＤと、を入力する。ＰＣ３０は、この入力された情報を換金処理に係る入力情報として、ポイント処理サーバ５０へ送信する。

換金処理は、例えば、換金直前の（最終の）サービス提供者が保持するポイントの一部又は全部を換金対象として行われる。換金対象は、例えば、換金を希望するポイント数で決定されてもよいし、公的扶助の種別により決定されてもよい。

ポイント処理サーバ５０は、ＰＣ３０からの換金処理に係る入力情報を受信する。ポイント処理サーバ５０は、ポイント情報データベース５０Ａを参照し、ポイント情報データベース５０Ａに保持されたポイント所有者ＩＤと、換金処理に係る入力情報に含まれるサービス提供者ＩＤと、が対応するポイントレコードのうち、換金対象のレコードを削除する。尚、換金対象のレコードの削除は、ポイント削除情報の生成後に行われる。

ポイント処理サーバ５０は、ポイントレコードが削除された場合、削除された１つのレコードに対応して、ポイント削除された旨を含むポイント削除情報を、由来情報サーバ１００へ通知する。

ポイント削除情報は、例えば、削除されたポイントレコードを識別するためのポイントＩＤ、削除されたポイントのポイント所有者ＩＤ、ポイント削除日及びポイント削除時刻、ポイント削除したＰＣ３０の識別情報、を含む。尚、ポイント削除情報は、上記のうち、ポイントＩＤのみ含んでもよい。ポイント所有者ＩＤは、ポイントの換金処理を申し出たサービス提供者ＩＤに相当する。

尚、ポイント処理サーバ５０は、１つの削除されたポイントレコードにつき、１つのポイント削除情報を通知してもよいし、ポイントＩＤをポイント削除分まとめて１つのポイント削除情報に格納して、１つのポイント削除情報を通知してもよい。

由来情報サーバ１００では、通信部１１０は、ポイント削除情報の通知を受信する。制御部１２０は、由来情報データベース１００Ａから、ポイント削除情報に含まれるポイントＩＤを含む由来情報を抽出する。制御部１２０は、抽出された由来情報を、バックアップサーバ１５０へ送信し、この由来情報を由来情報データベース１００Ａから削除する。つまり、ポイントが削除された後は、削除されたポイントに係る由来情報は、バックアップサーバ１５０により管理される。

このような地域通貨システム１０のポイント削除時の動作により、ポイントが削除された後でも、削除されたポイントに係る由来情報を管理し、削除されたポイントの使用過程を追跡できる。また、集計処理サーバ２００は、ポイントが削除された後でも、削除されたポイントに係る統計情報を解析できる。

このように、地域通貨システム１０は、由来情報を参照することで、ポイントが発行されてから換金されるまでの一巡において、どのような取引処理の経路を辿ったかを容易に確認できる。地域通貨システム１０は、各回の取引処理において不正使用（例えば目的外使用）されていないか否かを容易に検証でき、ポイントが悪用されることを抑制できる。

また、地域通貨システムは、ポイント消滅後でも、バックアップサーバ１５０から過去のポイントの由来情報を取得することで、ポイントの使用履歴を確認でき、ポイントが目的外使用されていないかを追跡できる。

次に、集計処理サーバ２００による統計情報の導出時の表示例について説明する。

図５は、ポイント毎の由来情報の表示例を示す模式図である。図５では、表示部２４０に、画面５１が表示される。

集計処理サーバ２００では、例えば、操作部２３０は、由来情報による追跡を希望するポイント（ポイントＩＤ）を指定する。ポイントが指定されると、通信部２１０は、由来情報サーバ１００に対して、ポイントＩＤを送信する。

由来情報サーバ１００では、通信部１１０は、ポイントＩＤを集計処理サーバ２００から受信する。制御部１２０は、由来情報データベース１００Ａから、受信されたポイントＩＤを含む由来情報を抽出する。通信部１１０は、抽出された由来情報を、集計処理サーバ２００へ送信する。

集計処理サーバ２００では、通信部２１０は、由来情報サーバ１００からの由来情報を受信し、制御部２２０は、受信された由来情報を表示部２４０に表示させる。尚、由来情報は、バックアップサーバ１５０から取得されてもよい。

例えば、制御部２２０は、図５に示すように、指定されたポイントＩＤに対応する複数の由来情報を、表示部２４０にツリー化して表示させてもよい。ここでは、ツリー化として、同一のポイントに対する取引処理に対して、時間的に前後に生成された由来情報同士が紐付けされている。例えば、制御部２２０が、由来情報に含まれる取引日及び取引時刻に応じて由来情報を配列することで、集計処理サーバ２００のユーザは、同じポイントに関する取引処理の前後関係を容易に把握できる。

図５では、由来情報は、時系列に並べられている。図５では、例えば、生成された時刻がより古い由来情報は、図５の上方や右方に示され、生成された時刻がより新しい由来情報は、図５の下方や左方に示される。図５では、Ｌｉｎ１１〜Ｌｉｎ１４が由来情報として存在し、このうちＬｉｎ１１が最古であり、Ｌｉｎ１４が最新であることを例示している。

また、制御部２２０は、指定されたポイントに付加された由来情報を、由来情報サーバ１００又はバックアップサーバ１５０から取得し、由来情報に含まれる由来ＩＤを、表示部２４０に一覧表示させてもよい。

また、制御部２２０は、例えば、ツリーにより表現された由来情報（例えば由来ＩＤ）の表示位置や、一覧表示された由来情報（例えば由来ＩＤ）の表示位置を、操作部２３０により指定することで、指定された由来情報の詳細を表示部２４０に表示させてもよい。由来情報の詳細は、例えば、由来情報データベース１００Ａに保持された情報の一部又は全部である。

これにより、集計処理サーバ２００は、由来情報を段階的に表示できる。従って、集計処理サーバ２００のユーザは、例えば、表示された由来ＩＤのうち、特にユーザが確認したい由来情報の詳細を確認できる。

図５の表示例によれば、集計処理サーバ２００のユーザは、例えば、所定のポイントに由来情報が付加されていった経緯を確認でき、簡単な操作により由来情報の詳細も確認できる。

図６は、オーナーＩＤにより識別されるオーナー毎の由来情報の表示例を示す模式図である。図６では、表示部２４０に、画面６１が表示される。

集計処理サーバ２００では、例えば、操作部２３０は、由来情報による追跡を希望するオーナー（オーナーＩＤ）を指定する。オーナーＩＤが選択されると、オーナーＩＤが指定されると、通信部２１０は、由来情報サーバ１００に対して、オーナーＩＤを送信する。

由来情報サーバ１００では、通信部１１０は、オーナーＩＤを集計処理サーバ２００から受信する。制御部１２０は、由来情報データベース１００Ａから、受信されたオーナーＩＤを含む由来情報を抽出する。通信部１１０は、抽出された由来情報を、集計処理サーバ２００へ送信する。

集計処理サーバ２００では、通信部２１０は、由来情報サーバ１００からの由来情報を受信し、制御部２２０は、受信された由来情報を表示部２４０に表示させる。尚、由来情報は、バックアップサーバ１５０から取得されてもよい。つまり、表示部２４０は、指定されたオーナーＩＤによる取引処理に対して付加された由来情報を表示する。

例えば、制御部２２０は、図６に示すように、指定されたオーナーＩＤに対応する複数の由来情報を、表示部２４０にツリー化して表示してもよい。ここでは、ツリー化として、同一のオーナーの取引処理に対して、時間的に前後に生成された由来情報同士が紐付けされている。例えば、制御部２２０が、由来情報に含まれる取引日及び取引時刻に応じて由来情報を配列することで、集計処理サーバ２００のユーザは、同じオーナーによる取引処理の前後関係を容易に把握できる。

図６では、由来情報は、時系列に並べられている。図６では、例えば、より古い取引処理に対する由来情報は、図６では上方に表示され、より新しい取引処理に対する由来情報は、図６では下方に表示される。図６では、Ｌｉｎ２１〜Ｌｉｎ２５が由来情報として存在し、このうちＬｉｎ２１が最古であり、Ｌｉｎ２５が最新であることを例示している。

また、制御部２２０は、指定されたオーナーから他のオーナーに変化した取引処理に係る由来情報は、グレイアウトする。つまり、ポイントが使用された取引処理に係る由来情報は、グレイアウトされることになる。尚、グレイアウトは、図６では斜線で示されている。尚、制御部２２０は、グレイアウトされた由来情報の下位の由来情報を、表示対象から外している。

例えば、図６において、公的扶助の受給者が、支給された１０万ポイントのうち、医療費に１万ポイントを支払い、続いて住宅費に１万ポイントを支払ったとする。この場合、支給された１０万ポイントに係る由来情報がＬｉｎ２１で示され、使用された医療費の１万ポイントに係る由来情報がＬｉｎ２２で示され、使用されなかった手元の９万ポイントに係る由来情報がＬｉｎ２３で示されている。また、残りの９万ポイントのうちの、使用された住宅費の１万ポイントに係る由来情報がＬｉｎ２４で示され、使用されなかった手元の８万ポイントに係る由来情報がＬｉｎ２５で示されている。

また、図６に示すように、制御部２２０は、ツリーにより表現された由来情報（例えば由来ＩＤ）の表示位置を、操作部２３０により選択することで、指定された由来情報の詳細を表示部２４０に表示させてもよい。由来情報の詳細は、例えば、由来情報データベース１００Ａに保持された情報の一部又は全部である。

制御部２２０は、由来情報Ｌｉｎ２１〜２５として、例えば、同一オーナーＩＤかつ同一の取引日、取引時刻の情報を含む由来情報を収集するよう、由来情報サーバ１００又はバックアップサーバ１５０に指示する。通信部２１０は、由来情報Ｌｉｎ２１〜２５を、由来情報サーバ１００又はバックアップサーバ１５０から取得する。

また、制御部２２０は、由来情報の表示位置を操作部２３０により指定することで、指定された由来情報に含まれる当初目的別に支給されたポイントのうち、未使用のポイントを表示部２４０に表示させてもよい。

尚、図６に示すように、ポイント所有者が保持するポイントのうち、使用されたポイントに対して由来情報が付加されるとともに、使用されなかったポイントに対しても由来情報が付加されてよい。尚、使用されなかったポイントに係る由来情報では、例えば、取引目的及び発生装置の値がヌル（ＮＵＬＬ）に設定されている。

これにより、集計処理サーバ２００は、例えば住宅費用のポイントであるにも関わらず、住宅費に使用されなかったポイントを確認できる。また、由来情報サーバ１００は、どの当初目的のポイントがどの程度使用されずに残っているのかを、追跡可能な情報として残しておくことができる。

図６の表示例によれば、集計処理サーバ２００は、オーナーＩＤを属性として、このオーナーＩＤに係る由来情報のグループをツリー化して表示する。これにより、特定のオーナーが行った取引処理を確認し易くなり、オーナー毎に、ポイントの使用過程を容易に追跡できる。

尚、図６に示すように、集計処理サーバ２００のユーザは、グレイアウトされた取引処理に係る取引目的の情報が表示されることで、オーナーがポイントを何に使ったのかをより容易に把握できる。

図７は、使用者毎のポイントの消費（使用）をウェブにより確認するための表示例を示す模式図である。図７では、表示部２４０に画面７１，７２が表示される。図７の画面７１は、図６の画面６１と同様である。

図７では、由来情報Ｌｉｎ２１のオーナーＩＤが「１１１」であることを示している。また、由来情報Ｌｉｎ２２に係る取引処理により変更された後のオーナーＩＤが「２２２」であることを示している。また、由来情報Ｌｉｎ２４に係る取引処理により変更された後のオーナーＩＤが「３３３」であることを示している。尚、図７では、実際にはオーナーＩＤが画面７１に表示されなくてもよい。

ポイント処理サーバ５０は、例えば、使用者毎の取引処理に係る取引情報をＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で発行してもよい。この場合、ポイント処理サーバ５０は、ＨＴＭＬ形式のデータ（ＨＴＭＬデータ）を集計処理サーバ２００へ送ってもよい。

この際、由来情報サーバ１００では、制御部１２０は、ポイント毎に付加された由来情報を集約したＨＴＭＬデータを生成してもよい。通信部１１０は、このＨＴＭＬデータを集計処理サーバ２００へ送ってもよい。

集計処理サーバ２００では、通信部２１０は、由来情報サーバ１００からＨＴＭＬデータを受信し、制御部２２０が、ＵＲＬ形式でウェブ上の所定のアドレスに開示してもよい。このＨＴＭＬデータは、由来情報から統計を取るための元データとなる。同様に、通信部２１０は、ポイント処理サーバ５０からＨＴＭＬデータを受信し、制御部２２０が、ＵＲＬ形式でウェブ上の所定のアドレスに開示してもよい。例えば、操作部２３０によりＵＲＬを指定すると、制御部２２０が、集約されたＨＴＭＬ形式の取引情報と由来情報とを開示する。

また、例えば、操作部２３０は、画面７２におけるＵＲＬ１１〜１３の下部に示された「＋」部分を選択すると、制御部２２０は、ＵＲＬに対応するオーナーＩＤのオーナーが保持するポイントの当初目的の情報を、集約された由来情報の中から取得する。尚、図７では、ＵＲＬ１１とオーナーＩＤ「１１１」とが対応し、ＵＲＬ１２とオーナーＩＤ「２２２」とが対応し、ＵＲＬ３３とオーナーＩＤ「３３」とが対応する。制御部２２０は、取得された当初目的の情報に従って、ポイント発行の根拠となった条例の情報を、表示部２４０に表示させる。

このように、ＨＴＭＬデータをウェブ上に置くことで、オープンデータの風潮に沿うことができる。これにより、ＨＴＭＬデータに基づいて由来情報を用いた様々な統計や解析が可能であり、由来情報の活用効率を向上できる。

尚、集計処理サーバ２００は、ＨＴＭＬデータを用いずに、ＣＳＶデータを生成してもよい。尚、集計処理サーバ２００は、外部装置からアクセス可能とされてもよい。また、集計処理サーバ２００による集計処理の結果をウェブで公開する場合、地域通貨システム１０が別途にＷｅｂサーバを備えてもよい。

例えば、自治体毎に集計処理サーバ２００を有することで、いずれかの集計処理サーバ２００は、各自治体の由来情報をＨＴＭＬデータ等により収集し、特定の自治体では医療費の割合が極端に高い等を解析できる。つまり、集計処理サーバ２００は、例えば、生活保護費の受給者個人の単位よりも広い観点（例えば自治体単位）から、生活保護費に関する統計情報や解析情報を確認できる。

このように、地域通貨システム１０は、由来情報を用いることで、支給されたポイントとしての生活保護費が適正に使用されたか否かを容易に検証できる。つまり、由来情報を参照することで、取引処理の履歴を確認することが容易になり、当初目的外の取引処理を突き止め易くなる。

また、一度発行されたポイントを追跡することは非常に困難であったが、地域通貨システム１０によれば、由来情報を用いて、ポイントの使用過程を容易に追跡できる。よって、生活保護費を必要な人に必要な分を支給でき、当初目的に沿った使用が行われる可能性を向上できる。

また、集計処理サーバ２００は、由来情報サーバ１００やバックアップサーバ１５０からの由来情報を集計して検証することで、例えば、当初目的による使用が可能な場所で消費されているか否かを判別できる。

当初目的による使用が可能な場所か否かは、例えば、由来情報の発生装置（例えばカードリーダ２０、ＰＣ３０）のＩＤやオーナーＩＤの情報に基づいて判別される。例えば、集計処理サーバ２００は、発生装置のＩＤやオーナーＩＤが他の自治体等により管理されるＩＤである場合、生活保護の申請とは異なる地域で使用されていると判別可能である。

生活保護費や地域通貨は地域色に馴染むものあるので、例えば、九州地域で支給された生活保護費が、北海道地域で使用される可能性は少ない。集計処理サーバ２００は、このような事象を検知できる。

また、集計処理サーバ２００は、ポイントが、特定者（例えば、特定の店舗、特定の医療機関、又は特定の不動産業者）に突出して収集されているか否かを判別できる。集計処理サーバ２００は、特定者に収集されているか否かについて、例えば、由来情報に含まれる同一のオーナーＩＤで識別されるオーナーが保持するポイントが、突出して多い（例えば所定数以上）であるか否かにより判別可能である。

また、集計処理サーバ２００は、ポイントが発行された当初目的に沿って、当該ポイントが使用されたか否かを判別できる。集計処理サーバ２００は、当初目的に沿った使用か否かについて、例えば、当該ポイントに付加された各由来情報の各取引目的が、由来情報の当初目的と一致しているか否かにより判別可能である。

また、ポイント処理サーバ５０は、ポイントに対して使用期限を設けることで、例えば翌月に生活保護費を繰り越すことを防止できる。

また、集計処理サーバ２００は、例えば、特定の受給者について、生活保護費の支給の当初目的が教育費であるが、取引処理に係る取引目的が住宅費であり、且つ、この取引目的が頻発するか否かを判別可能である。これにより、集計処理サーバ２００により解析されたこの結果を確認することで、自治体は、当初目的に誤りがないかを見直す機会を与えることができる。

また、地域通貨システム１０を用いることで、公的扶助の不適格受給や目的外使用を低減できるので、例えば、生活保護費が正当に使用されているか否かを監視する監視者（例えば生活保護Ｇメン）による監視負担を軽減できる。

なお、本発明は、上記実施形態の構成に限られるものではなく、特許請求の範囲で示した機能、または本実施形態の構成が持つ機能が達成できる構成であればどのようなものであっても適用可能である。

上記実施形態では、地域通貨システム１０は、当初目的と異なる取引処理を実施することは可能であり、後から取引処理を追跡可能としていたが、ポイント処理サーバ５０は、当初目的と異なる取引処理自体を禁止するようにしてもよい。

上記実施形態では、由来情報サーバ１００と集計処理サーバ２００とが別体で設けられること例示したが、一体に設けられてもよい。

本発明は、公的扶助の不適格受給や目的外使用を低減できる履歴管理装置、履歴解析装置、履歴管理システム、履歴管理方法、及び履歴解析方法等に有用である。

１０ 地域通貨システム
２０ カードリーダ
２５ カード
２５Ａ カード情報データベース
３０ ＰＣ
４０ 認証サーバ
５０ ポイント処理サーバ
５０Ａ ポイント情報データベース
６０ マイナンバ照合サーバ
１００ 由来情報サーバ
１００Ａ 由来情報データベース
１１０ 通信部
１２０ 制御部
１５０ バックアップサーバ
２００ 集計処理サーバ
２１０ 通信部
２２０ 制御部
２３０ 操作部
２４０ 表示部

Claims (17)

1. ポイントの処理を通知するためのポイント処理情報を受信する通信部と、
   前記ポイント処理情報が受信される度に、かつ、処理された所定のポイント毎に、前記ポイント処理情報に応じて前記ポイントの処理履歴を示す由来情報を生成する生成部と、
   生成された前記由来情報を蓄積する蓄積部と、
   を備える履歴管理装置。
2. 請求項１に記載の履歴管理装置であって、
   前記ポイントは、地域通貨のポイントである、履歴管理装置。
3. 請求項２に記載の履歴管理装置であって、
   前記ポイントは、公的扶助に基づいて発行されるポイントである、履歴管理装置。
4. 請求項３に記載の履歴管理装置であって、
   前記由来情報は、前記ポイントが処理された公的扶助の種別の情報を含む、履歴管理装置。
5. 請求項１ないし４のいずれか１項に記載の履歴管理装置であって、
   前記由来情報は、前記ポイントの処理を指示した指示装置の識別情報を含む、履歴管理装置。
6. 請求項１ないし５のいずれか１項に記載の履歴管理装置であって、
   前記由来情報は、前記ポイントが処理された後のポイント所有者の識別情報を含む、履歴管理装置。
7. 請求項１ないし６のいずれか１項に記載の履歴管理装置であって、更に、
   前記蓄積部から由来情報を抽出する抽出部を備え、
   前記通信部は、前記ポイントの削除を通知するためのポイント削除情報を受信し、
   前記抽出部は、前記ポイント削除情報に含まれる前記ポイントの所有者の情報に一致する所有者情報を含む由来情報の少なくとも一部を抽出する抽出部と、
   前記通信部は、抽出された前記由来情報を外部サーバへ送信する、履歴管理装置。
8. ポイントが処理される度に、かつ、処理された所定のポイント毎に、前記ポイントの処理履歴を示す由来情報を生成し蓄積する履歴管理装置から、前記由来情報を取得する取得部と、
   前記由来情報に基づいて、前記ポイントの処理に係る統計情報を導出する導出部と、
   を備える履歴解析装置。
9. 請求項８に記載の履歴解析装置であって、
   前記ポイントは、地域通貨のポイントである、履歴解析装置。
10. 請求項９に記載の履歴解析装置であって、
    前記ポイントは、公的扶助に基づいて発行されるポイントである、履歴解析装置。
11. 請求項８ないし１０のいずれか１項に記載の履歴解析装置であって、更に、
    情報を表示する表示部と、
    解析対象のポイントを指定するための入力情報を受け付ける操作部と、
    を備え、
    前記取得部は、前記入力情報に含まれる解析対象のポイントの識別情報と一致する識別情報を含む由来情報を、前記履歴管理装置から複数取得し、
    前記表示部は、取得された複数の前記由来情報を関連付けて表示する、履歴解析装置。
12. 請求項８ないし１０のいずれか１項に記載の履歴解析装置であって、更に、
    情報を表示する表示部を備え、
    解析対象のポイント所有者を指定するための入力情報を受け付ける操作部と、
    を備え、
    前記取得部は、前記入力情報に含まれる解析対象のポイント所有者の識別情報と一致するポイント所有者の識別情報を含む由来情報を、前記履歴管理装置から複数取得し、
    前記表示部は、取得された複数の前記由来情報を関連付けて表示する、履歴解析装置。
13. 履歴管理装置及び履歴解析装置を備え、ポイント処理装置により処理されるポイントの処理履歴を管理する履歴管理システムであって、
    前記履歴管理装置は、
    前記ポイント処理装置から、前記ポイントの処理を通知するためのポイント処理情報を受信する通信部と、
    前記ポイント処理情報が受信される度に、かつ、処理された所定のポイント毎に、前記ポイント処理情報に応じて前記ポイントの処理履歴を示す由来情報を生成する生成部と、
    生成された前記由来情報を蓄積する蓄積部と、
    を備え、
    前記履歴解析装置は、
    前記履歴管理装置から前記由来情報を取得する取得部と、
    前記由来情報に基づいて、前記ポイントの処理に係る統計情報を導出する導出部と、
    を備える履歴管理システム。
14. 請求項１３に記載の履歴管理システムであって、
    前記ポイントは、地域通貨のポイントである、履歴管理システム。
15. 請求項１４に記載の履歴管理システムであって、
    前記ポイントは、公的扶助に基づいて発行されるポイントである、履歴管理システム。
16. 履歴管理装置における履歴管理方法であって、
    ポイントの処理を通知するためのポイント処理情報を受信するステップと、
    前記ポイント処理情報が受信される度に、かつ、処理された所定のポイント毎に、前記ポイント処理情報に応じて前記ポイントの処理履歴を示す由来情報を生成するステップと、
    を備える履歴管理方法。
17. 履歴解析装置における履歴解析方法であって、
    ポイントが処理される度に、かつ、処理された所定のポイント毎に、前記ポイントの処理履歴を示す由来情報を生成し蓄積する履歴管理装置から、前記由来情報を取得するステップと、
    前記由来情報に基づいて、前記ポイントの処理に係る統計情報を導出するステップと、
    を備える履歴解析方法。

Images