JP2020115307A - 情報処理システム、およびサービスデータ提供方法 - Google Patents

Abstract

【課題】デジタルクーポンなどのサービスデータを効果的に提供する技術を実現する。【解決手段】クライアントノード１と、利用条件Ｑ１を有するクーポンを発行する発行ノード２と、を備えた情報処理システム１００であって、クライアントノード１は、クライアントノード１のユーザが有するユーザデータＤを提示して、前記クーポンの利用要求を行う利用要求部１５５と、を備え、発行ノード２は、利用要求部１５５からの利用要求に応じて、前記ユーザデータＤに含まれる情報が利用条件Ｑ１を満たしているかを検証する利用要求検証部２５３と、前記情報が利用条件Ｑ１を満たしている場合に、クライアントノード１に前記クーポンの利用を許可する利用許可部２５４と、を備えたことを特徴とする、情報処理システム１００。【選択図】図１

Description

本発明は、デジタルクーポンなどのサービスデータを効果的に提供するための情報処理システム、サービスデータ提供方法、および情報処理システムの製造方法に関する。

従来より、デジタルクーポンなどのサービスデータを不特定のユーザに提供することにより、新たな顧客を獲得するビジネスモデルが定着している。近年では、記録データが関係者全員に公開され、内容の改竄が困難であるという特徴を有するブロックチェーンを利用して、デジタルクーポンを発行・管理・売買する技術も提案されている（例えば、非特許文献１）。

"THE ROUFE PROJECT"、［online］、インターネット<URL: https://rouge.network/>

新規顧客の獲得効果を高めるためには、単にデジタルクーポンを不特定多数に提供するよりも、特定の属性（例えば、特定の居住地、性別、趣味）を有する人物（以下、特定人物）に限定して提供することが望ましい。これにより、割引率などがより高い、戦略的なクーポンを発行することも可能となる。

現状では、特定人物に限定してクーポンを発行するためには、提供対象となる人物候補の個人データを大量に確保して、その個人データを基に提供先を選別する必要がある。しかし、個人データの大量獲得・利用は、通常は高コストであり、現実的ではない。

非特許文献１の従来技術でも、特定のサイトを経由してデジタルクーポンを提供するという運用によって、上記問題点を回避しようとしている。しかし、このような運用では、特定人物に提供先を絞ることは難しい。

本発明は、上記問題を解決するためになされたものであって、デジタルクーポンなどのサービスデータを効果的に提供する技術を実現することを課題とする。

本発明に係る情報処理システムは、
クライアントノードと、利用条件を有するサービスデータを発行する発行ノードと、を備えた情報処理システムであって、
前記クライアントノードは、
前記クライアントノードのユーザが有するユーザデータを提示して、前記サービスデータの利用要求を行う利用要求部
を備え、
前記発行ノードは、
前記利用要求部からの前記利用要求に応じて、前記ユーザデータに含まれる情報が前記利用条件を満たしているかを検証する利用要求検証部と、
前記情報が前記利用条件を満たしている場合に、前記クライアントノードに前記サービスデータの利用を許可する利用許可部と、
を備える。

本発明に係るサービスデータ提供方法は、
クライアントノードと、利用条件を有するサービスデータを発行する発行ノードと、を備えた情報処理システムにおいて、前記発行ノードが前記サービスデータを提供するサービスデータ提供方法であって、
前記クライアントノードにおいて、前記クライアントノードのユーザが有するユーザデータを提示して、前記サービスデータの利用要求を行う利用要求ステップと、
前記発行ノードにおいて、前記利用要求ステップにおける前記利用要求に応じて、前記ユーザデータに含まれる情報が前記利用条件を満たしているかを検証する利用要求検証ステップと、
前記発行ノードにおいて、前記情報が前記利用条件を満たしている場合に、前記クライアントノードに前記サービスデータの利用を許可する利用許可ステップと、
を有する。

本発明に係る情報処理システムの製造方法は、
クライアントノードと、利用条件を有するサービスデータを発行する発行ノードと、を備えた情報処理システムの製造方法であって、
前記クライアントノードのユーザが有するユーザデータを提示して、前記サービスデータの利用要求を行う利用要求部、
としてコンピュータを動作させるためのプログラムを前記クライアントノードに配信するステップと、
前記利用要求部からの前記利用要求に応じて、前記ユーザデータに含まれる情報が前記利用条件を満たしているかを検証する利用要求検証部、および、
前記情報が前記利用条件を満たしている場合に、前記クライアントノードに前記サービスデータの利用を許可する利用許可部、
としてコンピュータを動作させるためのプログラムを前記発行ノードに配信するステップと、
を有する。

本発明によれば、発行ノードが利用条件を有するサービスデータを発行し、クライアントノードがユーザデータを提示して、発行ノードにサービスデータの利用要求を行い、発行ノードは、ユーザデータに含まれる情報が利用条件を満たしている場合に、サービスデータの利用を許可している。これにより、利用条件を満たすユーザに限定してサービスデータを提供することができるため、より戦略的なサービスデータを発行することも可能となる。そのため、従来技術に比べ、サービスデータをより効果的に提供することが可能となる。

第１実施形態に係る情報処理システムの概略図である。 第１実施形態に係るクライアントノードの構成を示す機能ブロックである。 第１実施形態に係る発行ノードの構成を示す機能ブロックである。 第１実施形態に係る認証ノードの構成を示す機能ブロックである。 第１実施形態に係る情報処理システムにおけるクーポン提供方法の処理を示すシーケンスチャートである。 第２実施形態に係る情報処理システムの概略図である。 第２実施形態に係るクライアントノードの構成を示す機能ブロックである。 第２実施形態に係る発行ノードの構成を示す機能ブロックである。 第２実施形態に係る認証ノードの構成を示す機能ブロックである。 第２実施形態に係る情報処理システムにおけるクーポン提供方法の処理を示すシーケンスチャートである。 第３実施形態に係る情報処理システムの概略図である。 第３実施形態に係るクライアントノードの構成を示す機能ブロックである。 第３実施形態に係る発行ノードの構成を示す機能ブロックである。 第３実施形態に係る認証ノードの構成を示す機能ブロックである。 第３実施形態に係る情報処理システムにおけるクーポン提供方法の処理を示すシーケンスチャートである。 第４実施形態に係る情報処理システムの概略図である。 第４実施形態に係るクライアントノードの構成を示す機能ブロックである。 第４実施形態に係る発行ノードの構成を示す機能ブロックである。 第４実施形態に係る情報処理システムにおけるクーポン提供方法の処理を示すシーケンスチャートである。 第５実施形態に係る情報処理システムの概略図である。 第５実施形態に係るクライアントノードの構成を示す機能ブロックである。 第５実施形態に係る発行ノードの構成を示す機能ブロックである。 第５実施形態に係る認証ノードの構成を示す機能ブロックである。 第５実施形態に係る情報処理システムにおけるクーポン提供方法の処理を示すシーケンスチャートである。 第５実施形態に係る情報処理システムにおけるクーポン提供方法の処理を示すシーケンスチャートである。

以下、本発明の実施形態について添付図面を参照して説明する。なお、本発明は、下記の実施形態に限定されるものではない。

〔第１実施形態〕
まず、簡略化した実施形態を第１実施形態として説明する。

（システム構成）
図１は、第１実施形態に係る情報処理システム１００の概略図である。情報処理システム１００は、クライアントノード１と、発行ノード２と、認証ノード３と、公開サーバ４と、を備えている。クライアントノード１、発行ノード２、認証ノード３および公開サーバ４は、例えばインターネットなどの通信ネットワークＮを介して有線または無線により通信可能に接続されている。

クライアントノード１は、デジタルクーポンを利用するユーザが管理している情報処理装置であり、クライアントノード１には、後述するクライアントプログラムＰ１がインストールされている。クライアントノード１は、デスクトップ型ＰＣ、ノート型ＰＣ、スマートフォン、タブレット端末、ＰＤＡなどの汎用のコンピュータで構成することができる。

発行ノード２は、利用条件を有するデジタルクーポンを発行する情報処理装置であり、発行ノード２には、後述する発行プログラムＰ２がインストールされている。発行ノード２も、クライアントノード１と同様に、デスクトップ型ＰＣ、ノート型ＰＣ、スマートフォン、タブレット端末、ＰＤＡなどの汎用のコンピュータで構成することができる。

認証ノード３は、デジタルクーポンの効果的な提供を可能にするためのサービス（以下、「クーポン提供サービス」と称する）を実施するサービス事業者が管理する情報処理装置であり、認証ノード３には、後述する認証プログラムＰ３がインストールされている。なお、認証ノード３は、個人が管理する端末装置であってもよい。

公開サーバ４は、発行されたクーポン等の各種データを公開するためのサーバである。本実施形態では、認証ノード３のユーザによって管理されている。

なお、情報処理システム１００は、クライアントノード１、発行ノード２および認証ノード３以外のノード、すなわち、クライアントプログラム、発行プログラムおよび認証プログラムのいずれもがインストールされていないノードを含むことができる。

（各ノードの構成）
図２は、クライアントノード１の構成を示す機能ブロックであり、図３は、発行ノード２の構成を示す機能ブロックであり、図４は、認証ノード３の構成を示す機能ブロックである。

図２に示すように、クライアントノード１は、入力部１１と、表示部１２と、通信部１３と、記憶部１４と、制御部１５と、を備えている。

入力部１１は、例えばキーボード、マウスまたはタッチパネルで構成することができ、表示部１２は、例えば液晶ディスプレイや有機ＥＬディスプレイで構成することができる。通信部１３は、クライアントノード１が通信ネットワークＮを介して他のノード等と通信を行うためのインターフェースである。

記憶部１４は、クライアントノード１で用いられる各種プログラムやデータを記憶するための不揮発性の補助記憶装置であり、例えばハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ）で構成することができる。

記憶部１４には、本実施形態に係るクライアントプログラムＰ１が記憶されている。クライアントプログラムＰ１は、情報処理システム１００においてクーポン提供サービスの処理の一部をクライアントノード１に実行させるためのプログラムである。クライアントプログラムＰ１をクライアントノード１に配信する方法は特に限定されず、通信ネットワークＮを介してクライアントプログラムＰ１をクライアントノード１にダウンロードしてもよいし、コンピュータ読み取り可能な非一時的な記録媒体にクライアントプログラムＰ１を記録しておき、当該記憶媒体を介してクライアントプログラムＰ１をクライアントノード１にインストールしてもよい。例えば、クライアントノード１がスマートフォンである場合、Ａｐｐｌｅ社のＡｐｐＳｔｏｒｅ（登録商標）やＧｏｏｇｌｅ社のＧｏｏｇｌｅＰｌａｙ（登録商標）などを介して、クライアントプログラムＰ１をクライアントノード１に配信することができる。

制御部１５は、クライアントノード１が備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部１４に記憶されているクライアントプログラムＰ１をＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部１５は、データ取得部１５１と、認証要求部１５２と、保存部１５３と、利用可否検証部１５４と、利用要求部１５５と、を備えている。これらの各部の機能については、後述する。

図３に示すように、発行ノード２は、入力部２１と、表示部２２と、通信部２３と、記憶部２４と、制御部２５と、を備えている。入力部２１、表示部２２、通信部２３および記憶部２４はそれぞれ、クライアントノード１の入力部１１、表示部１２、通信部１３および記憶部１４と同様に構成することができる。

記憶部２４には、本実施形態に係る発行プログラムＰ２が記憶されている。発行プログラムＰ２は、クーポン提供サービスの処理の一部を発行ノード２に実行させるためのプログラムである。発行プログラムＰ２を発行ノード２に配信する方法は特に限定されず、通信ネットワークＮを介して発行プログラムＰ２を発行ノード２にダウンロードしてもよいし、コンピュータ読み取り可能な非一時的な記録媒体に発行プログラムＰ２を記録しておき、当該記憶媒体を介して発行プログラムＰ２を発行ノード２にインストールしてもよい。

制御部２５は、発行ノード２が備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部２４に記憶されている発行プログラムＰ２をＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部２５は、クーポン発行部２５１と、公開依頼部２５２と、利用要求検証部２５３と、利用許可部２５４と、を備えている。これらの各部の機能については、後述する。

図４に示すように、認証ノード３は、入力部３１と、表示部３２と、通信部３３と、記憶部３４と、制御部３５と、を備えている。入力部３１、表示部３２、通信部３３および記憶部３４はそれぞれ、クライアントノード１の入力部１１、表示部１２、通信部１３および記憶部１４と同様に構成することができる。

記憶部３４には、本実施形態に係る認証プログラムＰ３が記憶されている。認証プログラムＰ３は、クーポン提供サービスの処理の一部を認証ノード３に実行させるためのプログラムである。認証プログラムＰ３を認証ノード３に配信する方法は特に限定されず、通信ネットワークＮを介して認証プログラムＰ３を認証ノード３にダウンロードしてもよいし、コンピュータ読み取り可能な非一時的な記録媒体に認証プログラムＰ３を記録しておき、当該記憶媒体を介して認証プログラムＰ３を認証ノード３にインストールしてもよい。

制御部３５は、認証ノード３が備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部３４に記憶されている認証プログラムＰ３をＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部３５は、認証付与部３５１と、返送部３５２と、クーポン検証部３５３と、クーポン公開部３５４と、を備えている。これらの各部の機能については、後述する。

（処理手順）
図５は、情報処理システム１００において、本実施形態に係るサービスデータ提供方法の処理を示すシーケンスチャートである。なお、各処理における通信の形態は特に限定されない。

本実施形態では、図２〜図４にそれぞれ示すクライアントノード１の制御部１５、発行ノード２の制御部２５および認証ノード３の制御部３５によって図５の主な処理が実行される。なお、図５の処理の一部を、ユーザがクライアントノード１の入力部１１、発行ノード２の入力部２１または認証ノード３の入力部３１を介して操作することによりマニュアルで行ってもよい。

まず、クライアントノード１において、データ取得部１５１が、ユーザデータＤを、クライアントノード１自身で作成するか、または、外部装置で作成されたものをクライアントノード１に取り込むことで、ユーザデータＤを取得する（ステップＳ１、データ取得ステップ）。ユーザデータＤは、クライアントノード１のユーザが有するデータであれば特に限定されないが、本実施形態では、クライアントノード１のユーザに関する情報を含むデータであり、典型的にはユーザの各種ライフログデータである。ユーザデータＤとしては、例えば、以下のようなものが挙げられる。
・スマートフォンやＧＰＳロガーが記録したユーザの移動履歴
・特定場所の訪問履歴（ｂｌｕｅｔｏｏｔｈビーコンの受信データ、ランドマークの撮影画像）
・ウェブ利用履歴（ウェブブラウザが保持する履歴データ）
・ウェアラブル端末が記録した運動量／心拍履歴データ
・スマートフォンやＰＣの使用履歴（ログイン／ログアウト時間、アプリ起動履歴、ファイルのアクセス履歴など）
・通話／ＳＮＳ／メールの利用履歴（利用開始／終了日時、実際の送受信データ）
・おサイフケータイの購買履歴
・風景や人物の画像／動画ファイル（撮影日時／場所などのメタデータ付き）
・商品購入履歴（レシート画像、注文確認メール）

なお、ユーザデータＤが移動履歴データである場合、ユーザデータＤは、例えば、以下のようなデータ群の一部または全部である。
・使用したＧＰＳロガー装置／ソフトウェアの製品名情報
・データのフォーマット形式情報
・権利者情報（ユーザの公開鍵など）
・一定時間間隔で作成された日時／位置情報ペア群

本実施形態では、ユーザデータＤはユーザの移動履歴であり、データ取得部１５１は、例えばＧＰＳロガーによって実現することができる。

続いて、クライアントノード１の認証要求部１５２が、ユーザデータＤを認証ノード３に送付して、ユーザデータＤの有効性の認証付与を認証ノード３に要求する（ステップＳ２、認証要求ステップ）。

続いて、認証ノード３の認証付与部３５１は、認証要求部１５２からの前記要求を受けた場合に、ユーザデータＤに有効性の認証付与を行う（ステップＳ３、認証付与ステップ）。認証付与の形態は特に限定されないが、本実施形態では、認証付与部３５１は、認証ノード３が作成した電子署名Ｓによって有効性の認証付与を行う。

続いて、認証ノード３の返送部３５２が、電子署名ＳがなされたユーザデータＤ（認証付きユーザデータＤＳ）を返送する（ステップＳ４）。これに応じて、クライアントノード１では、保存部１５３が、認証付きユーザデータＤＳを記憶部１４に保存する（ステップＳ５）。認証付きユーザデータＤＳは、例えば、以下のデータ群がセットになったものである。
・ユーザデータＤ
・認証ノード３が作成したユーザデータＤの電子署名Ｓ

なお、以下では、認証付きユーザデータＤＳを単に「データＤＳ」と称する。

その後、発行ノード２において、クーポン発行部２５１が、ユーザの操作などに応じて、利用条件Ｑ１を有するデジタルクーポン（以下、単に「クーポン」と称する）を発行する（ステップＳ６）。利用条件Ｑ１は、クーポンの有効期間、発行上限枚数、および、必要となるデータなどを含む。この必要となるデータは、本実施形態では、所定期間内（例えば、２０１９年１月１日から３日間）に特定位置（例えば、仙台市）に存在したことを示す移動履歴であるとする。

続いて、発行ノード２の公開依頼部２５２が、認証ノード３に対して、発行したクーポンの公開を依頼する（ステップＳ７）。これに対し、認証ノード３のクーポン検証部３５３は、クーポンの内容を検証し（ステップＳ８）、公序良俗性等に問題がなければ、クーポン公開部３５４が、公開サーバ４にクーポンをアップロードして、クーポンを公開する（ステップＳ９）。これにより、クライアントノード１のユーザは、クーポンの発行を確認することができる（ステップＳ１０）。

このとき、クライアントノード１の利用可否検証部１５４は、記憶部１４に保存されているデータＤＳの中に、公開されたクーポンの利用条件Ｑ１を満たすデータが存在するかどうかを検証する（ステップＳ１１）。利用条件Ｑ１を満たすデータＤＳが存在する場合は、利用可否検証部１５４は、ユーザにその旨を通知する。

利用可能なクーポンの中に、クライアントノード１のユーザが利用したいクーポンが存在する場合、ユーザの操作に応じて、利用要求部１５５が、利用要求Ｒを発行ノード２に提示して、クーポンの利用要求を行う（ステップＳ１２、利用要求ステップ）。より具体的には、利用要求Ｒは、例えば、以下のデータ群がセットになったものである。
・クライアントノード１のユーザが利用したいクーポンの識別子（ＩＤ）
・ユーザデータＤＳ
・ユーザデータＤに記載されているユーザの公開鍵に紐づく秘密鍵によって作成された「当該クーポンの識別子ＩＤ」に対する電子署名（＝ユーザデータＤの権利者（ユーザ）によるクーポン利用意思の証明）

続いて、発行ノード２では、利用要求検証部２５３が、利用要求部１５５からの利用要求Ｒに応じて、データＤＳに含まれているユーザに関する情報（ユーザの移動履歴）が利用条件Ｑ１を満たしているか、認証付与がなされているか、およびユーザデータＤに記載されているユーザの公開鍵に紐づく秘密鍵によって作成された「当該クーポンの識別子ＩＤ」に対する電子署名が正当かを検証する（ステップＳ１３、利用要求検証ステップ）。本実施形態では、利用条件Ｑ１に含まれている所定期間および特定位置と、ユーザの移動履歴とを照合し、当該所定期間内に当該特定位置に存在したか否かを検証する。

続いて、発行ノード２の利用許可部２５４は、前記情報が利用条件Ｑ１を満たしており、利用要求が正当なものであると判断された場合に、クライアントノード１にクーポンの利用を許可する（ステップＳ１４、利用許可ステップ）。これにより、クライアントノード１のユーザは、クライアントノード１にクーポンの利用権データをダウンロードして、例えば表示部１２にクーポンの利用権を証明するＱＲ画像を表示することが可能となる。なお、前記情報が利用条件Ｑ１を満たしていない場合や、認証付与がなされていない場合は、利用許可部２５４は、クーポンの利用を拒絶する旨をクライアントノード１に通知する。

（本実施形態の総括）
以上のように、情報処理システム１００では、発行ノード２が利用条件Ｑ１を有するクーポンを発行し、クライアントノード１がユーザデータＤを提示して、発行ノード２にクーポンの利用要求を行い、発行ノード２は、ユーザデータＤに含まれるユーザに関する情報が利用条件Ｑ１を満たしている場合に、クーポンの利用を許可している。これにより、利用条件Ｑ１を満たすユーザに限定してクーポンを提供することができるため、より戦略的なクーポンを発行することも可能となる。そのため、従来技術に比べ、クーポンをより効果的に提供することが可能となる。

また、認証ノード３がユーザデータＤの有効性を検証して、認証付与しているため、ユーザデータＤの偽造といった不正を防止することができる。

なお、図５では、ステップＳ１〜Ｓ５の処理をクーポン発行前に行っていたが、利用条件Ｑ１に示される所定期間がクーポン発行後の期間も含む場合、ステップＳ１〜Ｓ５の処理をクーポン発行後に行ってもよい。

また、ステップＳ７〜Ｓ９の処理の代わりに、発行ノード２が認証ノード３を介さずに公開サーバ４にクーポンをアップロードしてもよい。あるいは、ステップＳ７〜Ｓ９の処理の代わりに、発行ノード２がメールの配信等によってクーポン発行をクライアントノード１に周知してもよい。

また、ステップＳ２〜Ｓ５の処理を省略し、ステップＳ１２において、クライアントノード１の利用要求部１５５が、認証付与されていないユーザデータＤを発行ノード２に提示することにより、クーポンの利用要求を行ってもよい。ただし、電子署名Ｓの日付はクライアントノード１では変更できないため、ユーザデータＤの偽造防止の観点では、ステップＳ２〜Ｓ５の処理を行うことを利用条件Ｑ１に含めることが望ましい。

〔第２実施形態〕
第２実施形態では、ユーザのプライバシー向上等を図った形態について説明する。なお、第１実施形態におけるものと同じ機能を有する部材については、同じ符号を付し、その説明を省略する。

（システム構成）
図６は、第２実施形態に係る情報処理システム２００の概略図である。情報処理システム２００は、クライアントノード１ａと、発行ノード２ａと、認証ノード３ａと、公開サーバ４と、を備えている。クライアントノード１ａ、発行ノード２ａ、認証ノード３ａおよび公開サーバ４は、例えばインターネットなどの通信ネットワークＮを介して有線または無線により通信可能に接続されている。

クライアントノード１ａは、デジタルクーポンを利用するユーザが管理している情報処理装置である。クライアントノード１ａのハードウェア構成は、第１実施形態に係るクライアントノード１と同様である。

発行ノード２ａは、デジタルクーポンを発行する業者等が管理する情報処理装置である。発行ノード２ａのハードウェア構成は、第１実施形態に係る発行ノード２と同様である。

認証ノード３ａは、クーポン提供サービスを実施するサービス事業者が管理する情報処理装置である。認証ノード３ａのハードウェア構成は、第１実施形態に係る認証ノード３と同様である。

（各ノードの構成）
図７は、クライアントノード１ａの構成を示す機能ブロックであり、図８は、発行ノード２ａの構成を示す機能ブロックであり、図９は、認証ノード３ａの構成を示す機能ブロックである。

図７に示すように、クライアントノード１ａは、入力部１１と、表示部１２と、通信部１３と、記憶部１４と、制御部１５ａと、を備えている。すなわち、クライアントノード１ａは、図２に示すクライアントノード１において、制御部１５を制御部１５ａに置き換えた構成である。

記憶部１４には、本実施形態に係るクライアントプログラムＰ１ａが記憶されている。

制御部１５ａは、クライアントノード１ａが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部１４に記憶されているクライアントプログラムＰ１ａをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部１５ａは、データ取得部１５１と、認証要求部１５２’と、保存部１５３と、利用可否検証部１５４と、利用要求部１５５’と、カタログ作成部１５６と、を備えている。すなわち、制御部１５ａは、図２に示す制御部１５において、認証要求部１５２および利用要求部１５５をそれぞれ、認証要求部１５２’および利用要求部１５５’に置き換え、カタログ作成部１５６をさらに備えた構成である。これらの各部の機能については、後述する。

図８に示すように、発行ノード２ａは、入力部２１と、表示部２２と、通信部２３と、記憶部２４と、制御部２５ａと、を備えている。すなわち、発行ノード２ａは、図３に示す発行ノード２において、制御部２５を制御部２５ａに置き換えた構成である。

記憶部２４には、本実施形態に係る発行プログラムＰ２ａが記憶されている。

制御部２５ａは、発行ノード２ａが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部２４に記憶されている発行プログラムＰ２ａをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部２５ａは、クーポン発行部２５１と、公開依頼部２５２と、利用要求検証部２５３と、利用許可部２５４と、カタログ閲覧部２５５と、を備えている。すなわち、制御部２５ａは、図３に示す制御部２５において、カタログ閲覧部２５５をさらに備えた構成である。これらの各部の機能については、後述する。

図９に示すように、認証ノード３ａは、入力部３１と、表示部３２と、通信部３３と、記憶部３４と、制御部３５ａと、を備えている。すなわち、認証ノード３ａは、図４に示す認証ノード３において、制御部３５を制御部３５ａに置き換えた構成である。

記憶部３４には、本実施形態に係る認証プログラムＰ３ａが記憶されている。

制御部３５ａは、認証ノード３ａが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部３４に記憶されている認証プログラムＰ３ａをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部３５ａは、認証付与部３５１と、返送部３５２と、クーポン検証部３５３と、クーポン公開部３５４と、カタログ公開部３５５と、を備えている。すなわち、制御部３５ａは、図４に示す制御部３５において、カタログ公開部３５５をさらに備えた構成である。これらの各部の機能については、後述する。

（処理手順）
図１０は、情報処理システム２００において、本実施形態に係るサービスデータ提供方法の処理を示すシーケンスチャートである。なお、各処理における通信の形態は特に限定されない。また、第１実施形態に係るサービスデータ提供方法におけるものと同じ処理については、同じ符号を付す。

本実施形態では、図７〜図９にそれぞれ示すクライアントノード１ａの制御部１５ａ、発行ノード２ａの制御部２５ａおよび認証ノード３ａの制御部３５ａによって図１０の主な処理が実行される。なお、図１０の処理の一部を、ユーザがクライアントノード１ａの入力部１１、発行ノード２ａの入力部２１または認証ノード３ａの入力部３１を介して操作することによりマニュアルで行ってもよい。

まず、クライアントノード１ａにおいて、データ取得部１５１が、クライアントノード１ａのユーザに関する情報を含むユーザデータＤを、クライアントノード１自身で作成するか、または、外部装置で作成されたものをクライアントノード１に取り込むことで、ユーザデータＤを取得する（ステップＳ１、データ取得ステップ）。ユーザデータＤは、第１実施形態におけるものと同一であることができる。

続いて、カタログ作成部１５６が、ユーザデータＤからカタログデータＸを作成する（ステップＳ１−２）。カタログデータＸはユーザデータＤを匿名化・概略化・権利者情報追加等をしたものである。ユーザデータＤが移動履歴データである場合、カタログデータＸは、例えば、以下のようなデータ群の一部または全部である。
・ユーザデータＤのハッシュ値
・データのフォーマット形式情報
・権利者情報（ユーザの公開鍵など）
・ユーザ識別情報（国籍、性別、年齢、職業など）
・記録開始／終了日時
・移動距離
・記録中に移動／存在した場所の概要情報（市町村レベル）

また、ユーザデータＤがウェブ利用履歴である場合、カタログデータＸは、例えば、以下のようなデータ群の一部または全部である。
・ユーザデータＤのハッシュ値
・権利者情報（ユーザの公開鍵など）
・ユーザ識別情報（国籍、性別、年齢、職業など）
・記録開始／終了日時
・ウェブ検索回数
・訪問サイト数
・訪問サイトの言語

続いて、クライアントノード１ａの認証要求部１５２’が、カタログデータＸを認証ノード３に送付して、カタログデータＸの有効性の認証付与を認証ノード３ａに要求する（ステップＳ２’、認証要求ステップ）。

続いて、認証ノード３ａの認証付与部３５１は、認証要求部１５２’からの前記要求を受けた場合に、カタログデータＸに有効性の認証付与を行う（ステップＳ３、認証付与ステップ）。認証付与の形態は特に限定されないが、本実施形態では、認証付与部３５１は、電子署名Ｓによって有効性の認証付与を行う。

続いて、認証ノード３ａの返送部３５２が、電子署名ＳがなされたカタログデータＸ（認証付きカタログデータＸＳ）を返送する（ステップＳ４）。

また、認証ノード３ａのカタログ公開部３５５が、カタログデータＸを公開サーバ４にアップロードして、カタログデータＸを公開する（ステップＳ４−１）。これにより、発行ノード２ａのカタログ閲覧部２５５は、カタログデータＸを閲覧することができる（ステップＳ４−２）。

このようにして、公開サーバ４には、不特定多数のクライアントノード１ａから認証ノード３ａに送信されたカタログデータＸがアップロードされることにより、多数のカタログデータＸが蓄積される。発行ノード２ａは、公開サーバ４に蓄積されたカタログデータＸの情報を参考にして、クーポンの利用条件Ｑ１を検討することができる。

なお、ステップＳ４およびＳ４−１の順序は特に限定されない。

認証付きカタログデータＸＳが認証ノード３から返送されると、クライアントノード１ａでは、保存部１５３が、認証付きカタログデータＸＳをユーザデータＤと対応付けて記憶部１４に保存する（ステップＳ５’）。

なお、以下では、認証付きカタログデータＸＳを単に「データＸＳ」と称する。

その後、ステップＳ６〜Ｓ１０の処理は、第１実施形態におけるものと同様である。ステップＳ１１では、クライアントノード１ａの利用可否検証部１５４が、記憶部１４に保存されているデータＸＳおよびユーザデータＤの中に、公開されたクーポンの利用条件Ｑ１を満たすデータが存在するかどうかを検証する。利用可能なクーポンの中に、クライアントノード１ａのユーザが利用したいクーポンが存在する場合、ユーザの操作に応じて、利用要求部１５５’が、利用要求Ｒ’を発行ノード２ａに提示して、クーポンの利用要求を行う（ステップＳ１２、利用要求ステップ）。より具体的には、利用要求Ｒ’は、例えば、以下のデータ群がセットになったものである。
・クライアントノード１のユーザが利用したいクーポンの識別子（ＩＤ）
・データＸＳとユーザデータＤの一方もしくは両方
・ユーザデータＤまたはデータＸＳに記載されているユーザの公開鍵に紐づく秘密鍵によって作成された「当該クーポンの識別子ＩＤ」に対する電子署名（＝ユーザデータＤの権利者（ユーザ）によるクーポン利用意思の証明）

続いて、発行ノード２ａでは、利用要求検証部２５３が、利用要求部１５５’からの利用要求Ｒ’に応じて、提示された証拠データに含まれているユーザに関する情報（ユーザの移動履歴）が利用条件Ｑ１を満たしているか等を検証する（ステップＳ１３、利用要求検証ステップ）。

続いて、発行ノード２ａの利用許可部２５４は、前記情報が利用条件Ｑ１を満たしており、利用要求が正当なものであると判断された場合に、クライアントノード１ａにクーポンの利用を許可する（ステップＳ１４、利用許可ステップ）。これにより、クライアントノード１ａのユーザは、クライアントノード１ａにクーポンの利用券データをダウンロードして、例えば表示部１２にクーポンの利用券を証明するＱＲ画像を表示することが可能となる。なお、前記情報が利用条件Ｑ１を満たしていない場合や、認証付与がなされていない場合は、利用許可部２５４は、クーポンの利用を拒絶する旨をクライアントノード１ａに通知する。

（本実施形態の総括）
以上のように、情報処理システム２００では、発行ノード２ａは、カタログデータＸに含まれるユーザに関する情報が利用条件Ｑ１を満たしている場合に、クーポンの利用を許可しているため、第１実施形態と同様、利用条件Ｑ１を満たすユーザに限定してクーポンを提供することができる。さらに、本実施形態では、クライアントノード１ａのユーザは、認証付与の要求およびクーポン利用要求の際に、ユーザデータＤの代わりに、カタログデータＸを提示すればよいので、ユーザのプライバシーを保護することができる。

また、発行ノード２のユーザは、公開サーバ４に蓄積されたカタログデータＸを参考にしたクーポン発行が可能となり、カタログデータＸを営業ツールとして利用することができる。

なお、本実施形態においても、ステップＳ１〜Ｓ５’の処理をクーポン発行後に行ってもよい。また、ステップＳ７〜Ｓ９の処理の代わりに、発行ノード２ａが認証ノード３を介さずに公開サーバ４にクーポンをアップロードしてもよい。あるいは、ステップＳ７〜Ｓ９の処理の代わりに、発行ノード２がメールの配信等によってクーポン発行をクライアントノード１に周知してもよい。また、ステップＳ２〜Ｓ５の処理を省略し、ステップＳ１２において、クライアントノード１ａの利用要求部１５５’が、認証付与されていないカタログデータＸを発行ノード２ａに提示することにより、クーポンの利用要求を行ってもよい。

〔第３実施形態〕
第３実施形態では、ブロックチェーン技術を利用して透明性と公平性の向上を図った形態について説明する。なお、第１および第２実施形態におけるものと同じ機能を有する部材については、同じ符号を付し、その説明を省略する。

（システム構成）
図１１は、第３実施形態に係る情報処理システム３００の概略図である。情報処理システム３００は、クライアントノード１ｂと、発行ノード２ｂと、認証ノード３ｂと、ブロックチェーン５と、を備えている。クライアントノード１ｂ、発行ノード２ｂ、認証ノード３ｂおよびブロックチェーン５は、例えばインターネットなどの通信ネットワークＮを介して有線または無線により通信可能に接続されている。

クライアントノード１ｂは、デジタルクーポンを利用するユーザが管理している情報処理装置である。クライアントノード１ｂのハードウェア構成は、第１実施形態に係るクライアントノード１と同様である。

発行ノード２ｂは、利用条件を有するデジタルクーポンを発行する情報処理装置である。発行ノード２ｂのハードウェア構成は、第１実施形態に係る発行ノード２と同様である。

認証ノード３ｂは、クーポン提供サービスを実施するサービス事業者が管理する情報処理装置である。認証ノード３ｂのハードウェア構成は、第１実施形態に係る認証ノード３と同様である。

ブロックチェーン５は、情報処理システム３００に存在する全てのノード間で実施された取引や契約の情報（トランザクション）群を一定時間毎に集約してブロック化して、各ブロックが直前ブロックとの連結条件を満たしていることを示す証拠情報を各ブロックに記載して、各ブロックをチェーン状に連結させたものである。ブロックチェーン５は、これまでの全てのトランザクションを記録しており、情報処理システム３００に存在するノード群によって分散管理されている。また、情報処理システム３００では、独自の暗号通貨による取引を発生させることができる。そのような暗号通貨の例として、ビットコイン（Bitcoin）やイーサリアム（Ethereum）などが挙げられる。

（各ノードの構成）
図１２は、クライアントノード１ｂの構成を示す機能ブロックであり、図１３は、発行ノード２ｂの構成を示す機能ブロックであり、図１４は、認証ノード３ｂの構成を示す機能ブロックである。

図１２に示すように、クライアントノード１ｂは、入力部１１と、表示部１２と、通信部１３と、記憶部１４と、制御部１５ｂと、を備えている。すなわち、クライアントノード１ｂは、図２に示すクライアントノード１において、制御部１５を制御部１５ｂに置き換えた構成である。

記憶部１４には、本実施形態に係るクライアントプログラムＰ１ｂが記憶されている。

制御部１５ｂは、クライアントノード１ｂが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部１４に記憶されているクライアントプログラムＰ１ｂをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部１５ｂは、データ取得部１５１と、認証要求部１５２と、保存部１５３と、利用可否検証部１５４と、利用要求部１５５”と、獲得要求部１５７と、を備えている。すなわち、制御部１５ｂは、図２に示す制御部１５において、利用要求部１５５を利用要求部１５５”に置き換え、獲得要求部１５７をさらに備えた構成である。これらの各部の機能については、後述する。

図１３に示すように、発行ノード２ｂは、入力部２１と、表示部２２と、通信部２３と、記憶部２４と、制御部２５ｂと、を備えている。すなわち、発行ノード２ｂは、図３に示す発行ノード２において、制御部２５を制御部２５ｂに置き換えた構成である。

記憶部２４には、本実施形態に係る発行プログラムＰ２ｂが記憶されている。

制御部２５ｂは、発行ノード２ｂが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部２４に記憶されている発行プログラムＰ２ｂをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部２５ｂは、クーポン発行部２５１’と、公開依頼部２５２と、利用要求検証部２５３’と、利用許可部２５４’と、を備えている。すなわち、制御部２５ａは、図３に示す制御部２５において、クーポン発行部２５１、利用要求検証部２５３および利用許可部２５４をそれぞれ、クーポン発行部２５１’、利用要求検証部２５３’および利用許可部２５４’に置き換えた構成である。これらの各部の機能については、後述する。

図１４に示すように、認証ノード３ｂは、入力部３１と、表示部３２と、通信部３３と、記憶部３４と、制御部３５ｂと、を備えている。すなわち、認証ノード３ｂは、図４に示す認証ノード３において、制御部３５を制御部３５ｂに置き換えた構成である。

記憶部３４には、本実施形態に係る認証プログラムＰ３ｂが記憶されている。

制御部３５ｂは、認証ノード３ｂが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部３４に記憶されている認証プログラムＰ３ｂをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部３５ｂは、認証付与部３５１と、返送部３５２と、クーポン検証部３５３と、クーポン公開部３５４’と、を備えている。すなわち、制御部３５ａは、図４に示す制御部３５において、クーポン公開部３５４をクーポン公開部３５４’に置き換えた構成である。これらの各部の機能については、後述する。

（処理手順）
図１５は、情報処理システム３００において、本実施形態に係るサービスデータ提供方法の処理を示すシーケンスチャートである。なお、各処理における通信の形態は特に限定されない。また、第１および第２実施形態に係るサービスデータ提供方法におけるものと同じ処理については、同じ符号を付す。

本実施形態では、図１２〜図１４にそれぞれ示すクライアントノード１ｂの制御部１５ｂ、発行ノード２ｂの制御部２５ｂおよび認証ノード３ｂの制御部３５ｂによって図１５の主な処理が実行される。なお、図１５の処理の一部を、ユーザがクライアントノード１ｂの入力部１１、発行ノード２ｂの入力部２１または認証ノード３ｂの入力部３１を介して操作することによりマニュアルで行ってもよい。

最初のステップＳ１〜Ｓ５は、図５に示す第１実施形態におけるものと同様である。ステップＳ６’において、発行ノード２ｂのクーポン発行部２５１’は、ユーザの操作などに応じて、利用条件Ｑ１および獲得条件Ｑ２を有するクーポンを発行する。獲得条件Ｑ２は、利用条件Ｑ１と同一であることができる。

続いて、発行ノード２ｂの公開依頼部２５２が、認証ノード３ｂに対して、発行したクーポンの公開を依頼する（ステップＳ７）。これに対し、認証ノード３ｂのクーポン検証部３５３は、クーポンの内容を検証し（ステップＳ８）、内容に問題がなければ、クーポン公開部３５４’が、クーポンを公開するために、クーポンをブロックチェーン５に登録依頼する（ステップＳ９’）。クーポンが採掘者達（ブロックチェーン５にデータ登録しているユーザ）によって承認され、ブロックチェーン５に登録されると（ステップＳ９−１）、クーポンが公開され、クライアントノード１ｂのユーザは、クーポンの発行を確認することができる（ステップＳ１０）。

このとき、クライアントノード１ｂの利用可否検証部１５４は、記憶部１４に保存されているデータＤＳの中に、公開されたクーポンの利用条件Ｑ１および獲得条件Ｑ２を満たすデータが存在するかどうかを検証する（ステップＳ１１）。利用条件Ｑ１および獲得条件Ｑ２を満たすデータＤＳが存在する場合は、利用可否検証部１５４は、ユーザにその旨を通知する。

利用可能なクーポンの中に、クライアントノード１ｂのユーザが利用したいクーポンが存在する場合、ユーザの操作に応じて、獲得要求部１５７が、データＤＳをブロックチェーン５に提示して、クーポンの獲得要求Ｒ１のブロックチェーン５への登録を依頼する（ステップＳ１１−１、獲得要求ステップ）。ブロックチェーン５の採掘者達は、データＤＳに含まれる情報が獲得条件Ｑ２を満たしているかを検証し、獲得条件Ｑ２を満たしていれば、獲得要求Ｒ１をブロックチェーン５に登録する（ステップＳ１１−２）。これにより、クーポンの獲得が完了する。

獲得要求Ｒ１は、例えば、以下のデータ群がセットになったものである。
・ブロックチェーン５に登録済みかつ獲得したいクーポンの識別子（ＩＤ）
・ユーザデータＤのハッシュ
・獲得者の公開鍵
・獲得条件Ｑ２を満たすことの証拠（例：獲得条件とされているユーザデータＤとその電子署名Ｓ）

なお、獲得者の公開鍵は、ユーザの公開鍵と同一でも良い。また、ユーザの匿名性を向上させるために、獲得者の公開鍵は、同じものを使い回すのではなく、毎回作り替えても良い。

なお、獲得条件Ｑ２を満たすことの証拠は、第２実施形態のように、カタログデータＸを用いる場合、
・カタログデータＸとその電子署名Ｓ、または、
検証者（一般的にはサービス事業者またはクーポン発行者）により作成してもらった条件達成の証明書（＝検証者による電子署名）
などが挙げられる。

続いて、クライアントノード１ｂのユーザがクーポンを利用するために、クライアントノード１ｂの利用要求部１５５”が、ブロックチェーン５に登録された獲得要求Ｒ１に対応する利用要求Ｒ２を発行ノード２ｂに提示して、クーポンの利用要求を行う（ステップＳ１２’）。より具体的には、利用要求Ｒ２は、例えば、以下のデータ群がセットになったものである。
・クライアントノード１ｂのユーザが獲得済みであり、かつ利用したいクーポンの識別子（ＩＤ）
・ブロックチェーン５に登録（＝獲得完了）済みの獲得要求Ｒ１に記載されている獲得者の公開鍵に紐づく秘密鍵によって作成された「当該クーポンの識別子ＩＤ」に対する電子署名（＝クーポン獲得者によるクーポン利用意思の証明）

続いて、発行ノード２ｂでは、利用要求検証部２５３’が、ブロックチェーン５を参照して、利用要求部１５５”からの利用要求Ｒ２の有効性を検証する（ステップＳ１３’、利用要求検証ステップ）。

続いて、発行ノード２ｂの利用許可部２５４’は、獲得要求Ｒ１がブロックチェーン５に登録されていることにより、利用要求Ｒ２が適正であると判断した場合、利用許可Ａ１を作成して、利用許可Ａ１をクライアントノード１ｂのユーザに送信し、また、利用許可Ａ１のブロックチェーン５への登録を依頼することにより、クーポンの利用を許可する（ステップＳ１４’、利用許可ステップ）。

なお、利用許可Ａ１は以下のデータ群がセットになったものである。
・利用要求Ｒ２
・発行ノード２ｂの電子署名（＝発行ノード２ｂによるクーポン利用を許可する意志の証明）

ブロックチェーン５に獲得要求Ｒ１が登録されていない等、利用要求Ｒ２が適正でないと判断した場合は、利用許可部２５４’は、クーポンの利用を拒絶する旨をクライアントノード１ｂに通知する。

ブロックチェーン５の採掘者達によって利用許可Ａ１が承認され、ブロックチェーン５に登録されると（ステップＳ１５）、クライアントノード１ｂのユーザは、クーポンを利用できるようになる。なお、利用許可Ａ１がブロックチェーン５に登録される前に、クライアントノード１ｂが利用許可Ａ１を受信した時点で、クーポンを利用できるようにしてもよい。

（本実施形態の総括）
以上のように、情報処理システム３００では、ブロックチェーン５を利用して、クーポンの登録、クーポン獲得要求の有効性の検証、および、クーポンの利用許可を行っている。そのため、クーポン提供サービスの透明性と公平性を向上させることができる。

なお、本実施形態においても、ステップＳ１〜Ｓ５の処理をクーポン発行後に行ってもよい。また、ステップＳ７〜Ｓ９の処理の代わりに、発行ノード２ｂが認証ノード３を介さずにクーポンをブロックチェーン５に登録依頼してもよい。また、ステップＳ２〜Ｓ５の処理を省略し、ステップＳ１２において、クライアントノード１ｂの獲得要求部１５７が、認証付与されていないユーザデータＤをブロックチェーン５に提示することにより、クーポンの獲得要求を行ってもよい。

また、利用条件Ｑ１に、ユーザデータＤの発行ノード２ｂへの提供を含めてもよい。この場合、ステップＳ１２において、クライアントノード１ｂの利用要求部１５５”は、利用要求Ｒ２とともにユーザデータＤを送付して、クーポンの利用要求を行うことになる。このように、クーポン利用のために、クーポン発行者へのユーザデータの提供を義務付けることで、情報処理システム３００を、ユーザデータ売買のスマートコントラクトのためのプラットフォームに発展させることが可能となる。

〔第４実施形態〕
第４実施形態では、認証ノードの役割をブロックチェーンで代替する形態について説明する。なお、第１〜第３実施形態におけるものと同じ機能を有する部材については、同じ符号を付し、その説明を省略する。

（システム構成）
図１６は、第４実施形態に係る情報処理システム４００の概略図である。情報処理システム４００は、クライアントノード１ｃと、発行ノード２ｃと、ブロックチェーン５と、を備えている。クライアントノード１ｃ、発行ノード２ｃおよびブロックチェーン５は、例えばインターネットなどの通信ネットワークＮを介して有線または無線により通信可能に接続されている。

クライアントノード１ｃは、デジタルクーポンを利用するユーザが管理している情報処理装置である。クライアントノード１ｃのハードウェア構成は、第１実施形態に係るクライアントノード１と同様である。

発行ノード２ｃは、利用条件を有するデジタルクーポンを発行する情報処理装置である。発行ノード２ｃのハードウェア構成は、第１実施形態に係る発行ノード２と同様である。

（各ノードの構成）
図１７は、クライアントノード１ｃの構成を示す機能ブロックであり、図１８は、発行ノード２ｃの構成を示す機能ブロックである。

図１７に示すように、クライアントノード１ｃは、入力部１１と、表示部１２と、通信部１３と、記憶部１４と、制御部１５ｃと、を備えている。すなわち、クライアントノード１ｃは、図２に示すクライアントノード１において、制御部１５を制御部１５ｃに置き換えた構成である。

記憶部１４には、本実施形態に係るクライアントプログラムＰ１ｃが記憶されている。

制御部１５ｃは、クライアントノード１ｃが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部１４に記憶されているクライアントプログラムＰ１ｃをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部１５ｃは、データ取得部１５１と、認証要求部１５２”と、保存部１５３と、利用可否検証部１５４と、利用要求部１５５”と、獲得要求部１５７’と、ハッシュ作成部１５８と、を備えている。すなわち、制御部１５ｃは、図２に示す制御部１５において、認証要求部１５２および利用要求部１５５をそれぞれ、認証要求部１５２”および利用要求部１５５”に置き換え、獲得要求部１５７’およびハッシュ作成部１５８をさらに備えた構成である。これらの各部の機能については、後述する。

図１８に示すように、発行ノード２ｃは、入力部２１と、表示部２２と、通信部２３と、記憶部２４と、制御部２５ｃと、を備えている。すなわち、発行ノード２ｃは、図３に示す発行ノード２において、制御部２５を制御部２５ｃに置き換えた構成である。

記憶部２４には、本実施形態に係る発行プログラムＰ２ｃが記憶されている。

制御部２５ｃは、発行ノード２ｃが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部２４に記憶されている発行プログラムＰ２ｃをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部２５ｃは、クーポン発行部２５１’と、公開依頼部２５２’と、利用要求検証部２５３’と、利用許可部２５４’と、を備えている。すなわち、制御部２５ａは、図１３に示す制御部２５ｂにおいて、公開依頼部２５２を公開依頼部２５２’に置き換えた構成である。これらの各部の機能については、後述する。

（処理手順）
図１９は、情報処理システム４００において、本実施形態に係るサービスデータ提供方法の処理を示すシーケンスチャートである。なお、各処理における通信の形態は特に限定されない。また、第１〜第３実施形態に係るサービスデータ提供方法におけるものと同じ処理については、同じ符号を付す。

本実施形態では、図１７および図１８にそれぞれ示すクライアントノード１ｃの制御部１５ｃおよび発行ノード２ｃの制御部２５ｃによって図１９の主な処理が実行される。なお、図１９の処理の一部を、ユーザがクライアントノード１ｃの入力部１１または発行ノード２ｃの入力部２１を介して操作することによりマニュアルで行ってもよい。

まず、クライアントノード１ｃにおいて、データ取得部１５１が、ユーザデータＤを、クライアントノード１自身で作成するか、または、外部装置で作成されたものをクライアントノード１に取り込むことで、ユーザデータＤを取得する（ステップＳ１、データ取得ステップ）。続いて、ハッシュ作成部１５８が、ユーザデータＤのハッシュ値であるハッシュＨを作成する（ステップＳ２）。

続いて、クライアントノード１ｃの認証要求部１５２”が、ユーザデータＤの有効性の認証付与を受けるために、ハッシュＨのブロックチェーン５への登録を依頼する（ステップＳ２”、認証要求ステップ）。ハッシュＨが採掘者達によって承認され、ブロックチェーン５に登録されると（ステップＳ３’）、認証付与が完了し、クライアントノード１ｃは、 認証付与の完了を確認することができる（ステップＳ３’−１）。

その後、クライアントノード１ｃの保存部１５３は、ユーザデータＤおよびハッシュＨからなる認証付きユーザデータＤＨを記憶部１４に保存する（ステップＳ５”）。なお、以下では、認証付きユーザデータＤＨを単に「データＤＨ」と称する。

その後、発行ノード２ｃにおいて、クーポン発行部２５１’が、ユーザの操作などに応じて、利用条件Ｑ１および獲得条件Ｑ２を有するクーポンを発行する（ステップＳ６’）。続いて、公開依頼部２５２’が、発行したクーポンを公開するために、ブロックチェーン５にクーポンの登録を依頼する（ステップＳ７’）。クーポンが採掘者達によって承認され、ブロックチェーン５に登録されると（ステップＳ９−１）、クーポンが公開され、クライアントノード１ｃのユーザは、クーポンの発行を確認することができる（ステップＳ１０）。

利用可能なクーポンの中に、クライアントノード１ｃのユーザが利用したいクーポンが存在する場合、ユーザの操作に応じて、獲得要求部１５７’が、クーポンの獲得要求Ｒ３のブロックチェーン５への登録を依頼する（ステップＳ１１−１’、獲得要求ステップ）。獲得要求Ｒ３は、例えば、以下のデータ群がセットになったものである。
・ブロックチェーン５に登録済みかつ獲得したいクーポンの識別子（ＩＤ）
・ユーザデータＤのハッシュＨ
・獲得者の公開鍵
・獲得条件Ｑ２を満たすことの証拠（例：獲得条件とされているデータＤＨ）

なお、獲得者の公開鍵は、ユーザの公開鍵と同一でもよい。また、ユーザの匿名性を向上させるために、獲得者の公開鍵は、同じものを使い回すのではなく、毎回作り替えても良い。

ブロックチェーン５の採掘者達は、獲得要求Ｒ３に含まれる情報が獲得条件Ｑ２を満たしているか等を検証し、獲得要求Ｒ３が正当なものであると判断されると、獲得要求Ｒ３をブロックチェーン５に登録する（ステップＳ１１−２）。なお、ユーザの匿名性を向上させるために、ブロックチェーン５に登録する獲得要求Ｒ３から、データＤＨを省略してもよい。ここで、採掘者達が、獲得要求Ｒ３が正当なものであると判断する条件は、「ユーザデータＤが、特定期間内（通常は過去）に存在していたこと検証できること」である。本実施形態では、ステップＳ３’において、ユーザデータＤのハッシュＨがブロックチェーン５に登録済みである。そのため、発掘者達は、獲得要求Ｒ３に含まれるユーザデータＤから自分でハッシュＨ’を計算して、そのハッシュＨ’と同じハッシュ情報がブロックチェーン５の特定のブロック内に含まれるかどうかを調べることで、前述の条件が満たされるかどうかを検証できる。

なお、ステップＳ１１−１’では、獲得要求部１５７’は、ハッシュＨを除いたユーザデータＤのみを獲得条件Ｑ２を満たすことの証拠としてクーポンの獲得要求Ｒ３に含めて、ブロックチェーン５への登録を依頼してもよい。獲得要求Ｒ３がブロックチェーン５に登録されると、クーポンの獲得が完了する。

以下、ステップＳ１２’〜Ｓ１５の各処理は、図１５に示す処理と同じであり、これらの処理を経て、クライアントノード１ｃのユーザは、クーポンを利用できるようになる。なお、本実施形態においても、利用許可Ａ１がステップＳ１５においてブロックチェーン５に登録される前に、クライアントノード１ｃが利用許可Ａ１を受信した時点で、クーポンを利用できるようにしてもよい。

（本実施形態の総括）
以上のように、情報処理システム４００では、ブロックチェーン５を利用して、ユーザデータの有効性の認証付与、クーポンの登録、クーポン獲得要求の有効性の検証、および、クーポンの利用許可を行っている。すなわち、第３実施形態に係る情報処理システム３００における認証ノード３ｂが行っていた処理もブロックチェーン５を利用して実施しているため、第３実施形態よりも透明性と公平性をさらに向上させることができる。

なお、本実施形態においても、ステップＳ１〜Ｓ５”の処理をクーポン発行後に行ってもよい。また、ステップＳ１−２〜Ｓ５”の処理を省略し、ステップＳ１１−１’において、クライアントノード１ｃの獲得要求部１５７’が、認証付与されていないユーザデータＤをブロックチェーン５に提示することにより、クーポンの獲得要求を行ってもよい。

〔第５実施形態〕
前述の第４実施形態では、認証ノード（サービス事業者）の役割をブロックチェーンに代替させることで、サービス事業者のガバナンス力および収益力が低下し、不正対策（詐欺クーポン防止や特典が実施されない場合の不正裁定など）が実施困難になるという問題もあった。第５実施形態では、認証ノードを関与させることにより、これらの問題を克服した形態について説明する。なお、第１〜第４実施形態におけるものと同じ機能を有する部材については、同じ符号を付し、その説明を省略する。

（システム構成）
図２０は、第５実施形態に係る情報処理システム５００の概略図である。情報処理システム５００は、クライアントノード１ｄと、発行ノード２ｄと、認証ノード３ｄと、ブロックチェーン５と、を備えている。クライアントノード１ｄ、発行ノード２ｄ、認証ノード３ｄおよびブロックチェーン５は、例えばインターネットなどの通信ネットワークＮを介して有線または無線により通信可能に接続されている。

クライアントノード１ｄは、デジタルクーポンを利用するユーザが管理している情報処理装置である。クライアントノード１ｄのハードウェア構成は、第１実施形態に係るクライアントノード１と同様である。

発行ノード２ｄは、デジタルクーポンを発行する業者等が管理する情報処理装置である。発行ノード２ｄのハードウェア構成は、第１実施形態に係る発行ノード２と同様である。

認証ノード３ｄは、クーポン提供サービスを実施するサービス事業者が管理する情報処理装置である。認証ノード３ｄのハードウェア構成は、第１実施形態に係る認証ノード３と同様である。

（各ノードの構成）
図２１は、クライアントノード１ｄの構成を示す機能ブロックであり、図２２は、発行ノード２ｄの構成を示す機能ブロックであり、図２３は、認証ノード３ｄの構成を示す機能ブロックである。

図２１に示すように、クライアントノード１ｄは、入力部１１と、表示部１２と、通信部１３と、記憶部１４と、制御部１５ｄと、を備えている。すなわち、クライアントノード１ｄは、図２に示すクライアントノード１において、制御部１５を制御部１５ｄに置き換えた構成である。

記憶部１４には、本実施形態に係るクライアントプログラムＰ１ｄが記憶されている。

制御部１５ｄは、クライアントノード１ｄが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部１４に記憶されているクライアントプログラムＰ１ｄをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部１５ｄは、データ取得部１５１と、認証要求部１５２’と、保存部１５３と、利用可否検証部１５４と、利用要求部１５５'''と、カタログ作成部１５６と、獲得要求部１５７”と、クライアント側記名部１５９と、を備えている。すなわち、制御部１５ｄは、図２に示す制御部１５において、認証要求部１５２および利用要求部１５５をそれぞれ、認証要求部１５２’および利用要求部１５５'''に置き換え、カタログ作成部１５６、獲得要求部１５７”およびクライアント側記名部１５９をさらに備えた構成である。これらの各部の機能については、後述する。

図２２に示すように、発行ノード２ｄは、入力部２１と、表示部２２と、通信部２３と、記憶部２４と、制御部２５ｄと、を備えている。すなわち、発行ノード２ｄは、図３に示す発行ノード２において、制御部２５を制御部２５ｄに置き換えた構成である。

記憶部２４には、本実施形態に係る発行プログラムＰ２ｄが記憶されている。

制御部２５ｄは、発行ノード２ｄが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部２４に記憶されている発行プログラムＰ２ｄをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部２５ｄは、クーポン発行部２５１”と、公開依頼部２５２’と、利用要求検証部２５３’と、利用許可部２５４”と、カタログ閲覧部２５５と、発行側署名部２５６と、を備えている。すなわち、制御部２５ｄは、図３に示す制御部２５において、クーポン発行部２５１、公開依頼部２５２、利用要求検証部２５３および利用許可部２５４をそれぞれ、クーポン発行部２５１”、公開依頼部２５２’、利用要求検証部２５３’および利用許可部２５４”に置き換え、カタログ閲覧部２５５および発行側署名部２５６をさらに備えた構成である。これらの各部の機能については、後述する。

図２３に示すように、認証ノード３ｄは、入力部３１と、表示部３２と、通信部３３と、記憶部３４と、制御部３５ｄと、を備えている。すなわち、認証ノード３ｄは、図４に示す認証ノード３において、制御部３５を制御部３５ｄに置き換えた構成である。

記憶部３４には、本実施形態に係る認証プログラムＰ３ｄが記憶されている。

制御部３５ｄは、認証ノード３ｄが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部３４に記憶されている認証プログラムＰ３ｄをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部３５ｄは、認証付与部３５１と、返送部３５２と、クーポン検証部３５３と、クーポン公開部３５４”と、カタログ公開部３５５と、認証側署名部３５６と、を備えている。すなわち、制御部３５ｄは、図４に示す制御部３５において、クーポン公開部３５４をクーポン公開部３５４”に置き換え、カタログ公開部３５５および認証側署名部３５６をさらに備えた構成である。これらの各部の機能については、後述する。

（処理手順）
図２４および図２５は、情報処理システム５００において、本実施形態に係るサービスデータ提供方法の処理を示すシーケンスチャートである。なお、各処理における通信の形態は特に限定されない。また、第１〜第４実施形態に係るサービスデータ提供方法におけるものと同じ処理については、同じ符号を付す。

本実施形態では、図２１〜図２３にそれぞれ示すクライアントノード１ｄの制御部１５ｄ、発行ノード２ｄの制御部２５ｄおよび認証ノード３ｄの制御部３５ｄによって図２４および図２５の主な処理が実行される。なお、図２４および図２５の処理の一部を、ユーザがクライアントノード１ｄの入力部１１、発行ノード２ｄの入力部２１または認証ノード３ｄの入力部３１を介して操作することによりマニュアルで行ってもよい。

最初のステップＳ１〜Ｓ５’は、図１０に示す第２実施形態におけるものと同様である。ステップＳ６”において、発行ノード２ｄのクーポン発行部２５１”は、ユーザの操作などに応じて、利用条件Ｑ１および獲得条件Ｑ２を有するクーポンをクーポン契約書Ｃとして発行する。獲得条件Ｑ２は、利用条件Ｑ１と同一であることができる。クーポン契約書Ｃは、例えば、以下のデータ群がセットになったものである。
・クーポン発行責任者（企業）名
・クーポンの特典内容
・クーポン利用（＝獲得）条件

クーポンの特典内容としては、例えば、特定場所で特定日時において特定商品が半額で購入できるといったものが挙げられる。また、クーポン利用（＝獲得）条件としては、以下の例が挙げられる。
・認証付きのユーザデータＤを保持していること
・ユーザデータＤをクーポン発行者に提供できること
・所定額の仮想通貨を支払うこと
・所定の発行期限までに発行完了すること
・クーポン獲得数やクーポン利用数が発行上限に達していないこと

続いて、発行ノード２ｄの発行側署名部２５６が、クーポン契約書Ｃに署名を行う（ステップＳ６−１）。発行側署名部２５６によって署名がなされたクーポン契約書をクーポン契約書Ｃ１とする。

続いて、発行ノード２ｄの公開依頼部２５２’が、認証ノード３ｄに対して、クーポン契約書Ｃ１の公開を依頼する（ステップＳ７’）。これに対し、認証ノード３ｄのクーポン検証部３５３は、クーポンの内容を検証し（ステップＳ８）、公序良俗性等に問題がなければ、認証側署名部３５６が、クーポン契約書Ｃ１に署名を行う（ステップＳ８−１）。認証側署名部３５６によってさらに署名がなされたクーポン契約書をクーポン契約書Ｃ２とする。

続いて、クーポン公開部３５４”が、クーポンを公開するために、クーポン契約書Ｃ２をブロックチェーン５に登録依頼する（ステップＳ９”）。クーポンが採掘者達によって承認され、ブロックチェーン５に登録されると（ステップＳ９−１’）、クーポン契約書Ｃ２が公開され、クライアントノード１ｄのユーザは、クーポンの発行を確認することができる（ステップＳ１０）。なお、発行ノード２ｄおよび認証ノード３ｄのユーザも、クーポン契約書Ｃ２がブロックチェーン５に登録されたことを確認することができる。

ステップＳ１１では、クライアントノード１ｄの利用可否検証部１５４が、記憶部１４に保存されているデータＸＳおよびユーザデータＤの中に、公開されたクーポン契約書Ｃ２の利用条件Ｑ１を満たすデータが存在するかどうかを検証する。利用可能なクーポン契約書Ｃ２の中に、クライアントノード１ｄのユーザが利用したいクーポンが存在する場合、ユーザの操作に応じて、クライアント側記名部１５９がクーポン契約書Ｃ２に記名を行う（＝獲得者の公開鍵を記入する）（ステップＳ１１−３）。クライアント側記名部１５９によってさらに獲得者の公開鍵が記入されたクーポン契約書をクーポン契約書Ｃ３とする。なお、獲得者の公開鍵は、ユーザの公開鍵と同一でも良い。また、ユーザの匿名性を向上させるために、獲得者の公開鍵は、同じものを使い回すのではなく、毎回作り替えても良い。

さらに、獲得要求部１５７”が、クーポンを獲得するために、データＸＳとユーザデータＤの一方もしくは両方を証拠データとしてブロックチェーン５に提示して、クーポン契約書Ｃ３のブロックチェーン５への登録を依頼する（ステップＳ１１−４）。ブロックチェーン５の採掘者達は、提示された証拠データに含まれる情報が獲得条件Ｑ２を満たしているかを検証し、獲得条件Ｑ２を満たしていれば、クーポン契約書Ｃ３と証拠データのセット、または、クーポン契約書Ｃ３のみをブロックチェーン５に登録する（ステップＳ１１−５）。これにより、クーポンの獲得が完了する。なお、発行ノード２ｄおよび認証ノード３ｄのユーザも、クーポン契約書Ｃ３がブロックチェーン５に登録されたことを確認することができる。

続いて、クライアントノード１ｄのユーザがクーポンを利用するために、クライアントノード１ｄの利用要求部１５５'''が、ブロックチェーン５に登録されたクーポン契約書Ｃ３に対応する利用要求Ｒ４を発行ノード２ｄに提示して、クーポンの利用要求を行う（ステップＳ１２”）。より具体的には、利用要求Ｒ４は、例えば以下のデータ群がセットになったものである。
・クライアントノード１ｄのユーザが獲得済みであり、かつ利用したいクーポンの識別子（ＩＤ）
・ブロックチェーン５に登録（＝獲得完了）済みのクーポン契約書Ｃ３に記載されている獲得者の公開鍵に紐づく秘密鍵によって作成された「当該クーポンの識別子ＩＤ」に対する電子署名（＝クーポン獲得者によるクーポン利用意思の証明）

続いて、発行ノード２ｄでは、利用要求検証部２５３’が、ブロックチェーン５を参照して、利用要求部１５５'''からの利用要求Ｒ４の有効性を検証する（ステップＳ１３”、利用要求検証ステップ）。

続いて、発行ノード２ｂの利用許可部２５４”は、クーポン契約書Ｃ３がブロックチェーン５に登録されていること、および、クーポン契約書Ｃ３に記載されている獲得者の公開鍵に紐づく秘密鍵によって作成された「当該クーポンの識別子ＩＤ」に対する電子署名の検証により、利用要求Ｒ４が適正であると判断した場合、利用許可Ａ２を作成して、利用許可Ａ２をクライアントノード１ｄのユーザに送信し、また、利用許可Ａ２のブロックチェーン５への登録を依頼することにより、クーポンの利用を許可する（ステップＳ１４”、利用許可ステップ）。

なお、利用許可Ａ２は以下のデータ群がセットになったものである。
・利用要求Ｒ４
・発行ノード２ｂの電子署名（＝発行ノード２ｂによるクーポン利用を許可する意志の証明）

ブロックチェーン５にクーポン契約書Ｃ３が登録されていない等、利用要求Ｒ４が適正でないと判断した場合は、利用許可部２５４”は、クーポンの利用を拒絶する旨をクライアントノード１ｄに通知する。

ブロックチェーン５の採掘者達によって利用許可Ａ２が承認され、ブロックチェーン５に登録されると（ステップＳ１５）、クライアントノード１ｄのユーザは、クーポンを利用できるようになる。なお、本実施形態においても、利用許可Ａ２がステップＳ１５においてブロックチェーン５に登録される前に、クライアントノード１ｄが利用許可Ａ２を受信した時点で、クーポンを利用できるようにしてもよい。

（本実施形態の総括）
以上のように、情報処理システム５００では、クーポンが契約書の形式で発行され、発行ノード２ｄおよび認証ノード３ｄにおいて、クーポン契約書に署名がなされる。これにより、詐欺クーポンの発行を防止する効果を奏する。また、認証ノード３ｄ（サービス事業者）が、クーポン契約書への署名の他、ユーザデータまたはカタログデータへの認証付与も行うことにより、サービス事業者のガバナンス力および収益力の向上を図ることができる。

なお、本実施形態においても、ステップＳ１〜Ｓ５”の処理をクーポン発行後に行ってもよい。また、ステップＳ１〜Ｓ５”を、図５に示すステップＳ１〜Ｓ５、または、図１９に示すステップＳ１〜Ｓ５”に置き換えてもよい。あるいは、ステップＳ１−２〜Ｓ５”の処理を省略し、ステップＳ１１−４において、獲得要求部１５７”が、認証付与されていないユーザデータＤをブロックチェーン５に提示することにより、クーポンの獲得要求を行ってもよい。

また、クーポン契約書Ｃ２のブロックチェーン５への登録（ステップＳ９−１’）は必須ではなく、例えば、認証ノード３ｄを管理するサービス事業者が、クーポン契約書Ｃ２を公開サーバ等にアップロードすることにより、クーポン契約書Ｃ２を公開してもよい。この場合も、クーポン契約書Ｃ３のブロックチェーン５のへの登録依頼時（ステップＳ１１−４）に、クーポンの正当性が検証される。

また、サービス事業者のガバナンス力は低下するが、認証ノード３ｄによるクーポン契約書Ｃ１への署名（ステップＳ８−１）を省略してもよい。この場合、発行ノード２ｄは、クーポン契約書Ｃ１を直接ブロックチェーン５へ登録依頼してもよい。

（付記事項）
以上、本発明の５つの実施形態について説明したが、本発明はこれらの実施形態に限定されるものではなく、その趣旨を逸脱しない限りにおいて種々の変更が可能であり、例えば、各実施形態に開示された技術的手段を適宜組み合わせて得られる形態も、本発明の技術的範囲に属する。

また、上記の各実施形態では、情報処理システムがブロックチェーン技術を利用したプラットフォームであったが、本発明はこれに限定されず、通常のサーバ・クライアントシステムであってもよい。この場合、獲得要求やクーポン契約書は、ブロックチェーンの代わりに、サーバ等に設けられるデータベース（例：第３者の掲示板、サービス事業者が公開しているウェブサービス）に登録される。

また、上記の各実施形態では、サービスデータとしてデジタルクーポンを提供する形態について説明したが、本発明はこれに限定されず、サービスデータは、動画像などのコンテンツデータ、各種サービス利用権や電子マネーが紐づくシリアルコード、仮想通貨など、クライアントノードのユーザに電子的に提供されるあらゆるサービスを包含する。

１ クライアントノード
１ａ クライアントノード
１ｂ クライアントノード
１ｃ クライアントノード
１ｄ クライアントノード
２ 発行ノード
２ａ 発行ノード
２ｂ 発行ノード
２ｃ 発行ノード
２ｄ 発行ノード
３ 認証ノード
３ａ 認証ノード
３ｂ 認証ノード
３ｃ 認証ノード
３ｄ 認証ノード
４ 公開サーバ
５ ブロックチェーン
１１ 入力部
１２ 表示部
１３ 通信部
１４ 記憶部
１５ 制御部
１５ａ 制御部
１５ｂ 制御部
１５ｃ 制御部
１５ｄ 制御部
１５１ データ取得部
１５２ 認証要求部
１５２’ 認証要求部
１５２” 認証要求部
１５３ 保存部
１５４ 利用可否検証部
１５５ 利用要求部
１５５’ 利用要求部
１５５” 利用要求部
１５５''' 利用要求部
１５６ カタログ作成部
１５７ 獲得要求部
１５７’ 獲得要求部
１５７” 獲得要求部
１５８ ハッシュ作成部
１５９ クライアント側記名部
２１ 入力部
２２ 表示部
２３ 通信部
２４ 記憶部
２５ 制御部
２５ａ 制御部
２５ｂ 制御部
２５ｃ 制御部
２５ｄ 制御部
２５１ クーポン発行部
２５１’ クーポン発行部
２５１” クーポン発行部
２５２ 公開依頼部
２５２’ 公開依頼部
２５３ 利用要求検証部
２５３’ 利用要求検証部
２５４ 利用許可部
２５４’ 利用許可部
２５４” 利用許可部
２５５ カタログ閲覧部
２５６ 発行側署名部
３１ 入力部
３２ 表示部
３３ 通信部
３４ 記憶部
３５ 制御部
３５ａ 制御部
３５ｂ 制御部
３５ｄ 制御部
３５１ 認証付与部
３５２ 返送部
３５３ クーポン検証部
３５４ クーポン公開部
３５４’ クーポン公開部
３５４” クーポン公開部
３５５ カタログ公開部
３５６ 認証側署名部
１００ 情報処理システム
２００ 情報処理システム
３００ 情報処理システム
４００ 情報処理システム
５００ 情報処理システム
Ａ１ 利用許可
Ａ２ 利用許可
Ｃ クーポン契約書
Ｃ１ クーポン契約書
Ｃ２ クーポン契約書
Ｃ３ クーポン契約書
Ｄ ユーザデータ
ＤＨ 認証付きユーザデータ
ＤＳ 認証付きユーザデータ
Ｈ ハッシュ
Ｎ 通信ネットワーク
Ｑ１ 利用条件
Ｑ２ 獲得条件
Ｒ 利用要求
Ｒ’ 利用要求
Ｒ１ 獲得要求
Ｒ２ 利用要求
Ｒ３ 獲得要求
Ｒ４ 利用要求
Ｓ 電子署名
Ｘ カタログデータ
ＸＳ 認証付きカタログデータ

また、発行ノード２ａのユーザは、公開サーバ４に蓄積されたカタログデータＸを参考にしたクーポン発行が可能となり、カタログデータＸを営業ツールとして利用することができる。

なお、本実施形態においても、ステップＳ１〜Ｓ５’の処理をクーポン発行後に行ってもよい。また、ステップＳ７〜Ｓ９の処理の代わりに、発行ノード２ａが認証ノード３ａを介さずに公開サーバ４にクーポンをアップロードしてもよい。あるいは、ステップＳ７〜Ｓ９の処理の代わりに、発行ノード２ａがメールの配信等によってクーポン発行をクライアントノード１ａに周知してもよい。また、ステップＳ２〜Ｓ５’の処理を省略し、ステップＳ１２において、クライアントノード１ａの利用要求部１５５’が、認証付与されていないカタログデータＸを発行ノード２ａに提示することにより、クーポンの利用要求を行ってもよい。

制御部２５ｂは、発行ノード２ｂが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部２４に記憶されている発行プログラムＰ２ｂをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部２５ｂは、クーポン発行部２５１’と、公開依頼部２５２と、利用要求検証部２５３’と、利用許可部２５４’と、を備えている。すなわち、制御部２５ｂは、図３に示す制御部２５において、クーポン発行部２５１、利用要求検証部２５３および利用許可部２５４をそれぞれ、クーポン発行部２５１’、利用要求検証部２５３’および利用許可部２５４’に置き換えた構成である。これらの各部の機能については、後述する。

また、利用条件Ｑ１に、ユーザデータＤの発行ノード２ｂへの提供を含めてもよい。この場合、ステップＳ１２’において、クライアントノード１ｂの利用要求部１５５”は、利用要求Ｒ２とともにユーザデータＤを送付して、クーポンの利用要求を行うことになる。このように、クーポン利用のために、クーポン発行者へのユーザデータの提供を義務付けることで、情報処理システム３００を、ユーザデータ売買のスマートコントラクトのためのプラットフォームに発展させることが可能となる。

制御部２５ｃは、発行ノード２ｃが備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部２４に記憶されている発行プログラムＰ２ｃをＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部２５ｃは、クーポン発行部２５１’と、公開依頼部２５２’と、利用要求検証部２５３’と、利用許可部２５４’と、を備えている。すなわち、制御部２５ｃは、図１３に示す制御部２５ｂにおいて、公開依頼部２５２を公開依頼部２５２’に置き換えた構成である。これらの各部の機能については、後述する。

まず、クライアントノード１ｃにおいて、データ取得部１５１が、ユーザデータＤを、クライアントノード１ｃ自身で作成するか、または、外部装置で作成されたものをクライアントノード１ｃに取り込むことで、ユーザデータＤを取得する（ステップＳ１、データ取得ステップ）。続いて、ハッシュ作成部１５８が、ユーザデータＤのハッシュ値であるハッシュＨを作成する（ステップＳ１−２）。

続いて、発行ノード２ｄの利用許可部２５４”は、クーポン契約書Ｃ３がブロックチェーン５に登録されていること、および、クーポン契約書Ｃ３に記載されている獲得者の公開鍵に紐づく秘密鍵によって作成された「当該クーポンの識別子ＩＤ」に対する電子署名の検証により、利用要求Ｒ４が適正であると判断した場合、利用許可Ａ２を作成して、利用許可Ａ２をクライアントノード１ｄのユーザに送信し、また、利用許可Ａ２のブロックチェーン５への登録を依頼することにより、クーポンの利用を許可する（ステップＳ１４”、利用許可ステップ）。

なお、利用許可Ａ２は以下のデータ群がセットになったものである。
・利用要求Ｒ４
・発行ノード２ｄの電子署名（＝発行ノード２ｄによるクーポン利用を許可する意志の証明）

Claims (13)

1. クライアントノードと、利用条件を有するサービスデータを発行する発行ノードと、を備えた情報処理システムであって、
   前記クライアントノードは、
   前記クライアントノードのユーザが有するユーザデータを提示して、前記サービスデータの利用要求を行う利用要求部
   を備え、
   前記発行ノードは、
   前記利用要求部からの前記利用要求に応じて、前記ユーザデータに含まれる情報が前記利用条件を満たしているかを検証する利用要求検証部と、
   前記情報が前記利用条件を満たしている場合に、前記クライアントノードに前記サービスデータの利用を許可する利用許可部と、
   を備えたことを特徴とする、情報処理システム。
2. 認証ノードをさらに備え、
   前記クライアントノードは、
   前記ユーザデータの有効性の認証付与を前記認証ノードに要求する認証要求部
   をさらに備え、
   前記認証ノードは、
   前記認証要求部からの前記要求を受けた場合に、前記ユーザデータに前記有効性の認証付与を行う認証付与部
   を備え、
   前記利用要求部は、前記認証付与部によって認証付与された認証付きユーザデータを提示して、前記サービスデータの利用要求を行うことを特徴とする、請求項１に記載の情報処理システム。
3. 前記クライアントノードは、
   前記ユーザデータを匿名化したカタログデータを作成するカタログ作成部
   をさらに備え、
   前記利用要求部は、前記ユーザデータの代わりに前記カタログデータを提示して、前記サービスデータの利用要求を行うことを特徴とする、請求項１に記載の情報処理システム。
4. 認証ノードをさらに備え、
   前記クライアントノードは、
   前記カタログデータの有効性の認証付与を前記認証ノードに要求する認証要求部
   をさらに備え、
   前記認証ノードは、
   前記認証要求部からの前記要求を受けた場合に、前記カタログデータに前記有効性の認証付与を行う認証付与部
   を備え、
   前記利用要求部は、前記認証付与部によって認証付与された認証付きカタログデータを提示して、前記サービスデータの利用要求を行うことを特徴とする、請求項３に記載の情報処理システム。
5. データベースをさらに備え、
   前記サービスデータは、獲得条件をさらに有し、
   前記発行ノードは、
   前記サービスデータを公開するために、前記データベースに前記サービスデータの登録を依頼する公開依頼部
   をさらに備え、
   前記クライアントノードは、
   前記ユーザデータを前記データベースに提示して、前記サービスデータの獲得要求の前記データベースへの登録を依頼する獲得要求部
   をさらに備え、
   前記利用要求部は、前記ユーザデータの代わりに、前記データベースに登録された前記獲得要求に対応する利用要求を前記発行ノードに提示して、前記サービスデータの利用要求を行い、
   前記利用許可部は、前記利用要求の前記データベースへの登録を依頼することにより、前記サービスデータの利用を許可することを特徴とする、請求項１に記載の情報処理システム。
6. 認証ノードをさらに備え、
   前記クライアントノードは、
   前記ユーザデータの有効性の認証付与を前記認証ノードに要求する認証要求部
   をさらに備え、
   前記認証ノードは、
   前記認証要求部からの前記要求を受けた場合に、前記ユーザデータに前記有効性の認証付与を行う認証付与部
   を備え、
   前記獲得要求部は、前記認証付与部によって認証付与された認証付きユーザデータを提示して、前記獲得要求の前記データベースへの登録を依頼することを特徴とする、請求項５に記載の情報処理システム。
7. 前記クライアントノードは、
   前記ユーザデータのハッシュを作成するハッシュ作成部と、
   前記ユーザデータの有効性の認証付与を受けるために、前記ハッシュの前記データベースへの登録を依頼する認証要求部と、
   をさらに備え、
   前記獲得要求部は、前記認証付与された認証付きユーザデータを前記データベースに提示して、前記獲得要求の前記データベースへの登録を依頼することを特徴とする、請求項５に記載の情報処理システム。
8. データベースをさらに備え、
   前記サービスデータは、獲得条件をさらに有し、
   前記発行ノードは、
   前記サービスデータを契約書として発行し、
   前記契約書に署名を行う発行側署名部、
   を備え、
   前記クライアントノードは、
   前記発行側署名部によって署名がなされた前記契約書に記名を行うクライアント側記名部と、
   前記サービスデータを獲得するために、前記ユーザデータを前記データベースに提示して、前記クライアント側記名部によって記名がなされた前記契約書の前記データベースへの登録を依頼する獲得要求部と、
   をさらに備え、
   前記利用要求部は、前記ユーザデータの代わりに、前記データベースに登録された前記契約書に対応する利用要求を前記発行ノードに提示して、前記サービスデータの利用要求を行い、
   前記利用許可部は、前記利用要求の前記データベースへの登録を依頼することにより、前記サービスデータの利用を許可することを特徴とする、請求項１に記載の情報処理システム。
9. 認証ノードをさらに備え、
   前記認証ノードは、
   前記発行側署名部によって署名がなされた前記契約書に署名を行う認証側署名部、
   を備え、
   前記クライアント側記名部は、前記発行側署名部および前記認証側署名部によって署名がなされた前記契約書に記名を行うことを特徴とする、請求項８に記載の情報処理システム。
10. 前記クライアントノードは、
    前記ユーザデータの有効性の認証付与を前記認証ノードに要求する認証要求部、
    をさらに備え、
    前記認証ノードは、
    前記認証要求部からの前記要求を受けた場合に、前記ユーザデータに前記有効性の認証付与を行う認証付与部
    を備え、
    前記獲得要求部は、前記認証付与部によって認証付与された認証付きユーザデータを前記データベースに提示して、前記クライアント側記名部によって記名がなされた前記契約書の前記データベースへの登録を依頼することを特徴とする、請求項９に記載の情報処理システム。
11. 前記データベースは、ブロックチェーンであることを特徴とする、請求項５から１０のいずれかに記載の情報処理システム。
12. クライアントノードと、利用条件を有するサービスデータを発行する発行ノードと、を備えた情報処理システムにおいて、前記発行ノードが前記サービスデータを提供するサービスデータ提供方法であって、
    前記クライアントノードにおいて、前記クライアントノードのユーザが有するユーザデータを提示して、前記サービスデータの利用要求を行う利用要求ステップと、
    前記発行ノードにおいて、前記利用要求ステップにおける前記利用要求に応じて、前記ユーザデータに含まれる情報が前記利用条件を満たしているかを検証する利用要求検証ステップと、
    前記発行ノードにおいて、前記情報が前記利用条件を満たしている場合に、前記クライアントノードに前記サービスデータの利用を許可する利用許可ステップと、
    を有することを特徴とする、サービスデータ提供方法。
13. クライアントノードと、利用条件を有するサービスデータを発行する発行ノードと、を備えた情報処理システムの製造方法であって、
    前記クライアントノードのユーザが有するユーザデータを提示して、前記サービスデータの利用要求を行う利用要求部、
    としてコンピュータを動作させるためのプログラムを前記クライアントノードに配信するステップと、
    前記利用要求部からの前記利用要求に応じて、前記ユーザデータに含まれる情報が前記利用条件を満たしているかを検証する利用要求検証部、および、
    前記情報が前記利用条件を満たしている場合に、前記クライアントノードに前記サービスデータの利用を許可する利用許可部、
    としてコンピュータを動作させるためのプログラムを前記発行ノードに配信するステップと、
    を有することを特徴とする、情報処理システムの製造方法。

Images