【事件の表示】
　特許第６６６９３６８号発明「取引型および非取引型の商業を奨励する分散型台帳プロトコル」の特許異議申立事件について、次のとおり決定する。
【結　論】
　特許第６６６９３６８号の明細書，特許請求の範囲を訂正請求書に添付された特許請求の範囲のとおり，訂正後の請求項〔１〜１８〕について訂正することを認める。
　特許第６６６９３６８号の請求項１〜２，５〜８，１０，１７に係る特許を維持する。
　特許第６６６９３６８号の請求項３及び４に係る特許についての特許異議の申立てを却下する。
【理　由】
１　手続の経緯
　特許第６６６９３６８号の請求項１〜１８に係る特許についての出願は，２０１５年（平成２７年）７月１０日（優先権主張　２０１４年７月１１日，アメリカ合衆国）を国際出願日とする出願である特願２０１７−５２２４６６号の一部を平成３０年１０月２３日に新たな特許出願としたものであって，令和２年３月２日にその特許権の設定登録がされ，令和２年３月１８日に特許掲載公報が発行された。その後，その特許について，令和２年７月７日に特許異議申立人廣瀬敏一（以下，「申立人」という。）により特許異議の申立てがされ，当審は，令和２年１２月３日付けで取消理由を通知した。特許権者は，その指定期間内である令和３年３月５日に意見書の提出及び訂正の請求（以下，「本件訂正請求」という。）を行った。
２　訂正の適否についての判断
（１）訂正の内容
　本件訂正請求による訂正の内容は，以下のア〜ウのとおりである。
ア　訂正請求人は，特許請求の範囲の請求項１を，以下の事項により特定されるとおりに訂正することを請求する（以下，「訂正事項１」という。）。
　　少なくとも１つの奨励プロトコルネットワーク参加者の計算装置と，
　　奨励プロトコルプラットフォームをホストする第１のサーバーと，
　　前記第１のサーバーと通信し，分散型台帳をホストする少なくとも１つの第２のサーバーと，
　を有する奨励プロトコルネットワークを備え，
　前記第１のサーバーは，
　　前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に関連する奨励プロトコルネットワーク参加者のイベントに関連付けされた奨励イベントデータを受信し，
　　前記奨励イベントデータおよび少なくとも１つの奨励プロトコルシステム規則に基づいて，奨励単価の取引記録を作成し，
　　前記奨励単価の取引記録を，前記分散型台帳に取り込ませるために前記分散型台帳に同報送信し，
　　作成された前記奨励単価の取引記録に基づいて奨励単価の価値を計算し，
　　前記奨励単価の価値を前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に分配する，
　ような命令を実行
し，
　前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配が，前記奨励プロトコルネットワーク参加者のデジタルウォレットに対するものである
（下線は，訂正箇所。訂正請求人が付与した。）
イ　訂正請求人は，特許請求の範囲の請求項３，４及び，１１を削除することを請求する（以下，「訂正事項２」という。）。
ウ　特許権者は，特許請求の範囲の請求項１を上記アの事項により特定されるとおりの請求項１として訂正し，その結果として請求項１を引用する請求項２，５〜１０，１２〜１８も訂正することを請求する（以下，「訂正事項３」という。）
　よって，本件訂正請求は，一群の請求項ごとに請求されている。
（２）訂正の目的の適否，新規事項の有無，特許請求の範囲の拡張・変更の存否
ア　訂正事項１
　訂正事項１は，訂正前の請求項１に係る特許発明の「前記奨励単価の価値を前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に分配する」を，「前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配が，前記奨励プロトコルネットワーク参加者のデジタルウォレットに対するものである」との記載により，訂正後の請求項１に係る発明における「前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配」の構成を具体的に特定し，更に限定するものである。
　すなわち，訂正事項１は，特許法第１２０条の５第２項ただし書第１号に規定する特許請求の範囲の減縮を目的とするものである。
　また，訂正事項１は「奨励単価の価値の分配」の構成を具体的に特定し，更に限定するものであり，また訂正事項１は，訂正前の請求項１の記載を引用する訂正前の請求項１１の特徴を訂正前の請求項１に加入したものであるため，カテゴリーや対象，目的を変更するものではないから，実質上特許請求の範囲を拡張し，又は変更するものには該当せず，特許法第１２０条の５第９項で準用する特許法第１２６条第６項に適合するものである。
　訂正事項１は，上述したように特許請求の範囲の訂正前の請求項１１の記載であり，明細書記載の実施形態に基づいて導き出される構成である。この実施形態に係る説明として，訂正前の請求項１１には「前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配が，前記奨励プロトコルネットワーク参加者のデジタルウォレットに対するものである」との記載がなされていることから，当該訂正事項１は，願書に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内の訂正であり，特許法第１２０条の５第９項で準用する特許法１２６条第５項に適合するものである。
イ　訂正事項２
　訂正事項２は，訂正前の請求項３，４及び１１の記載を削除するものである。
　したがって，訂正事項２は特許法第１２０条の５第２項ただし書第１号に規定する特許請求の範囲の減縮を目的とするものである。
　訂正事項２は，訂正前の請求項３，４及び１１の記載を削除するのみであるから，訂正前の請求項３，４及び１１に記載された発明のカテゴリーを変更するものでもなく，かつ，訂正前の請求項３，４及び１１に記載された発明の対象や目的を変更するものとはならない。
　したがって，訂正事項２は，実質上特許請求の範囲を拡張し，又は変更するものには該当せず，特許法第１２０条の５第９項で準用する特許法第１２６条第６項に適合するものである。
　訂正事項２は，訂正前の請求項３，４及び１１の記載を削除するものであるから，願書に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内の訂正であり，特許法第１２０条の５第９項で準用する特許法１２６条第５項に適合するものである。
ウ　訂正事項３
　訂正事項３は，訂正後の請求項２，５〜１０，１２〜１８が，訂正後の請求項１の記載を引用することにより，訂正後の請求項２，５〜１０，１２〜１８に係る発明を，それぞれより具体的に特定し，更に限定するものであるため，特許法第１２０条の５第２項ただし書第１号に規定する特許請求の範囲の減縮を目的とするものである。
　訂正事項３は，上記アと同様の理由により，カテゴリーや対象，目的を変更するものではないから，実質上特許請求の範囲を拡張し，又は変更するものには該当せず，特許法第１２０条の５第９項で準用する特許法第１２６条第６項に適合するものである。
　訂正事項３は，上記アと同様の理由により，願書に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内の訂正であり，特許法第１２０条の５第９項で準用する特許法１２６条第５項に適合するものである。
　訂正事項３は，訂正後の請求項２，５〜１０，１２〜１８が，訂正後の請求項１の記載を引用するものであって，当該請求項１に係る発明は，後記「４」のとおり，特許を受けることができるものであるから，特許異議申立ての対象外である請求項９，１２〜１６，１８に係る発明についても，特許を受けることができないとする証拠は見当たらず，請求項９，１２〜１６，１８に係る発明が，特許出願の際独立して特許を受けることができないとすべき理由は存在しない。よって，訂正事項３でする請求項９，１２〜１６，１８に対する訂正は，特許法第１２０条の５第９項で準用する特許法１２６条第７項に適合するものである。
（３）小括
　したがって，上記の訂正請求による訂正事項１〜３は，特許法第１２０条の５第２項ただし書第１号に掲げる事項を目的とするものであり，かつ，同条第９項で準用する同法第１２６条第５項，第６項及び第７項の規定に適合する。
　よって，特許請求の範囲を，訂正請求書に添付された訂正特許請求の範囲のとおり，訂正後の請求項〔１〜１８〕について訂正することを認める。
３　訂正後の本件発明
　本件訂正請求により訂正された請求項１〜１８に係る発明（以下，それぞれ，「本件発明１」，「本件発明２」…「本件発明１８」といい，これらをまとめて「本件発明」という。）は，訂正特許請求の範囲の請求項１〜１８に記載された次の事項により特定されるとおりのものである。
［本件発明１］
　　少なくとも１つの奨励プロトコルネットワーク参加者の計算装置と，
　　奨励プロトコルプラットフォームをホストする第１のサーバーと，
　　前記第１のサーバーと通信し，分散型台帳をホストする少なくとも１つの第２のサーバーと，
　を有する奨励プロトコルネットワークを備え，
　前記第１のサーバーは，
　　前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に関連する奨励プロトコルネットワーク参加者のイベントに関連付けされた奨励イベントデータを受信し，
　　前記奨励イベントデータおよび少なくとも１つの奨励プロトコルシステム規則に基づいて，奨励単価の取引記録を作成し，
　　前記奨励単価の取引記録を，前記分散型台帳に取り込ませるために前記分散型台帳に同報送信し，
　　作成された前記奨励単価の取引記録に基づいて奨励単価の価値を計算し，
　　前記奨励単価の価値を前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に分配する，
　ような命令を実行し，
　前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配が，前記奨励プロトコルネットワーク参加者のデジタルウォレットに対するものであることを特徴とするシステム。
［本件発明２］
　前記分散型台帳にブロックチェーンが含まれていることを特徴とする請求項１に記載のシステム。
［本件発明３］
（削除）
［本件発明４］
（削除）
［本件発明５］
　前記第１のサーバーが，多重署名モデルを用いて奨励単価トークンを鋳造するという命令を実行することを特徴とする請求項１に記載のシステム。
［本件発明６］
　前記第１のサーバーが，多重署名モデルを用いて奨励単価トークンを鋳造するという命令を実行し，前記多重署名モデルは，少なくとも所定数の参加者鍵が提供された場合に，鋳造することを承認し，前記第１のサーバーは，前記承認に基づいて新たに鋳造された奨励単価トークンを同報送信する命令をさらに実行することを特徴とする請求項１に記載のシステム。
［本件発明７］
　前記イベントの種類が取引型であることを特徴とする請求項１に記載のシステム。
［本件発明８］
　前記イベントの種類が非取引型であることを特徴とする請求項１に記載のシステム。
［本件発明９］
　前記奨励イベントデータが，前記奨励プロトコルネットワーク参加者のデジタルウォレットから受信されることを特徴とする請求項１に記載のシステム。
［本件発明１０］
　前記奨励イベントデータが，商用プラットフォームから受信されることを特徴とする請求項１に記載のシステム。
［本件発明１１］
（削除）
［本件発明１２］
　前記第１のサーバーは，前記奨励単価の価値に関連付けられたブランド化された価値を定めている命令をさらに実行し，前記奨励単価の価値が，限られた一部の参加者に利用可能となるように構成されていることを特徴とする請求項１に記載のシステム。
［本件発明１３］
　前記奨励プロトコルネットワーク参加者を第１の奨励プロトコルネットワーク参加者とし，前記奨励単価の価値を第１の奨励単価の価値としたとき，前記第１のサーバーは，
　　第２の奨励プロトコルネットワーク参加者から通貨を受け取り，
　　前記通貨を第２の奨励単価の価値に変換する，
　ような命令をさらに実行することを特徴とする請求項１に記載のシステム。
［本件発明１４］
　前記奨励プロトコルネットワーク参加者を第１の奨励プロトコルネットワーク参加者としたとき，前記第１のサーバーは，
　　第２の奨励プロトコルネットワーク参加者から第１型の奨励単価の価値を受信し，
　　前記第１型の奨励単価の価値を第２型の奨励単価の価値に交換する，
　ような命令をさらに実行することを特徴とする請求項１に記載のシステム。
［本件発明１５］
　前記第１のサーバーは，非参加者に関連付けられた非参加者の計算装置にリンクを送信する命令をさらに実行し，前記非参加者の計算装置によりリンクが実行されると，非参加者に対する参加者アカウントが動的に作成され，前記非参加者の計算装置にデジタルウォレットがダウンロードされ，ダウンロードされた前記デジタルウォレットが，動的に作成された前記参加者アカウントに関連付けられるように構成されていることを特徴とする請求項１に記載のシステム。
［本件発明１６］
　前記第１のサーバーは，前記奨励プロトコルネットワーク参加者の生体フィードバック装置から生体データを受信するという命令をさらに実行し，前記奨励単価の取引記録の作成が前記生体データにさらに基づくものであることを特徴とする請求項１に記載のシステム。
［本件発明１７］
　前記第１のサーバーは，多重署名モデルを用いて奨励単価トークンを鋳造するという命令をさらに実行することを特徴とする請求項１に記載のシステム。
［本件発明１８］
　前記第１のサーバーは，複数の奨励単価トークンを鋳造し，前記複数の奨励単価トークンの額または種類のうち少なくとも一方を変更することで，積層化された奨励データを有する奨励単価トークンを生成する，という命令をさらに実行することを特徴とする請求項１に記載のシステム。
４　取消理由通知に記載した取消理由について
（１）取消理由の概要
　訂正前の請求項１，２〜４，７，８及び１０に係る特許に対して，当審が令和２年１２月３日付けで特許権者に通知した取消理由の要旨は，次のとおりである。
ア　請求項１，２，７，８及び１０係る発明は，本件特許出願前に日本国内又は外国において，頒布された引用文献１（甲第１号証）及び引用文献２（甲第２号証）に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，本件特許出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，請求項１，２，７，８及び１０に係る特許は，特許法第２９条第２項の規定に違反してされたものである。
イ　請求項３及び４に係る特許は，明細書又は特許請求の範囲の記載が，特許法第３６条第６項第２号に規定する要件を満たしていない特許出願に対してされたものである。
（２）甲号証の記載
ア　引用文献１（特開２０１１−５９８８４号公報，甲第１号証）には，次の事項が記載されている。
　「【請求項１】
　ユーザのコンピュータによるノード同士が通信接続されて成るネットワークを有し，
　前記ノードは，
　ハードウェア及びソフトウェアによる資源を提供することにより，クラウドコンピューティングによるサービスを提供する処理を行う提供機能と，
　前記サービスを要求して利用する処理を行う利用機能と，
　前記利用機能を用いる第１のノードと前記提供機能を用いる第３のノードとの間に介在して，前記サービスを実行する処理を行う実行機能と，
　前記提供機能を用いる第３のノードによる前記サービスの提供の行為を評価してその評価情報を保持するための評価機能と，を有し，
　前記サービスを利用する第１のノードの利用機能は，第２のノードの実行機能を経由して，当該サービスを提供する第１のグループの複数の第３のノードの提供機能にアクセスし，当該提供機能からの応答は，当該第２のノードの実行機能を経由して，当該第１のノードの利用機能へ応答され，
　上記に伴い，前記第２のノードまたは第４のノードの評価機能は，前記第１のグループの複数の第３のノードの提供機能の各々からの応答を評価処理し，その評価情報を保存し，
　前記第２のノードの実行機能または前記第４のノードの評価機能は，前記評価情報における評価の高低に基づいて，前記第３のノードが前記利用機能を用いて前記サービスを利用する際に当該サービスの実行を制御すること，を特徴とするクラウドコンピューティングシステム。
【請求項２】
　請求項１記載のクラウドコンピューティングシステムにおいて，
　前記第２のノードの評価機能は，前記第１のグループの複数の第３のノードの提供機能の各々からの応答を評価処理し，その評価情報を，第２のグループの複数の第４のノードの評価機能にアクセスして保存すること，を特徴とするクラウドコンピューティングシステム。
【請求項３】
　請求項１記載のクラウドコンピューティングシステムにおいて，
　前記第２のノードの評価機能は，前記第１のグループの複数の第３のノードの提供機能の各々からの応答の結果を含むログ情報を記録し，そのログ情報を，第２のグループの複数の第４のノードの評価機能にアクセスして保存し，
　前記第２のグループの複数の第４のノードの評価機能は，前記ログ情報に基づき，前記第１のグループの複数の第３のノードの提供機能の各々からの応答を評価処理し，その評価情報を保持すること，を特徴とするクラウドコンピューティングシステム。」
「【技術分野】
【０００１】
　本発明は，クラウドコンピューティングの技術に関する。
【背景技術】
【０００２】
　ＩＴにおける趨勢としてクラウドコンピューティングがある。本明細書では，クラウドコンピューティング（以下適宜「クラウド」等と略称する）とは，インターネット上で，記憶資源や計算資源などの資源（リソース）を，サービスとして提供ないし利用する形態を指すとする。クラウド的なサービスを実現するシステム（クラウドコンピューティングシステム）では，要素技術としては，サーバ仮想化技術（１つの物理的なサーバ上で複数の仮想サーバを稼働させる技術等）や，分散処理技術（１つの計算を複数のノード（コンピュータ）で分散させて処理する技術等）などが用いられる。
【０００３】
　クラウド的なサービス（以下単に「サービス」ともいう）の例は以下である。ユーザ（クライアント）が使用するＷｅｂブラウザ等を備えるＰＣ等のコンピュータ（端末）は，インターネット上のサービス（コンテンツ等）にアクセスする。例えばＡｍａｚｏｎ（登録商標）等による電子商取引（ＥＣ）のサービスや，Ｇｏｏｇｌｅ（登録商標）等による情報検索のサービスなどがあり，当該サービスを提供するＷｅｂサイト（サーバ）にアクセスする。当該サーバを含むノード群の中では，複数のノード間でサービスの処理（例えば分散処理等）が行われ，その結果がユーザの端末へ応答される。またユーザの端末は，当該ノード群の中でどのように処理が行われたか等について知る必要が無い。」
「【０００９】
　以上を鑑み，本発明の主な目的は，クラウドコンピューティングシステムに係わり，多数・多様なユーザが参加することができ，システム環境全体を良好に発展させることができる仕組みを提供することである。
【課題を解決するための手段】
【００１０】
　本願において開示される発明のうち，代表的なものの概要を簡単に説明すれば，次の通りである。本発明では，前述の仕組みを実現するために，クラウドコンピューティングシステムの構成のモデルとして，オープン，完全分散型のシステムを考える。即ち，通信ネットワーク上における情報処理システム（ノード（コンピュータ）群のネットワーク）において，例えば一部の企業のノードに限定されることなく，不特定多数のユーザ（参加者）のノードが自由に参加／離脱が可能であり，各ノードが，クラウド的なサービスの提供（構成）のためのコンピュータ資源を提供（供出）すると共に，当該サービスを利用可能であるような仕組みである。
【００１１】
　サービス提供側のモデルとして，各参加者のノードは，記憶資源や計算資源等を自由に提供し，それらの複数のノードの資源（その結合）により，クラウド的なサービスを構成し提供する。また，サービス利用側のモデルとして，各参加者のノードは，上記によるクラウド的なサービスにアクセス，利用することができる。
【００１２】
　ここで，上記のように各ノードがサービス（資源）の提供と利用の両方を行うようなシステムでは，上記サービス（その資源）の提供と利用のバランスが１つの問題になる。即ち，一方のユーザはサービス（資源）の利用の度合いよりも提供の度合いの方が大き過ぎるのに対し，逆に他方のユーザは利用の度合いが大き過ぎる，といった偏りや，ただ乗り等を許容する仕組みは望ましくない。
【００１３】
　この点，本システムでは，公平性などの実現のために，サービス（資源）の提供（供出）における貢献度（実績など）に応じてサービス（資源）の利用が可能になる仕組みを有する。即ち，各参加者のノードは，サービスの提供のための資源を提供（供出）する代わりに，サービス（資源）を利用する権限等を得る。言い換えれば，サービス（資源）を利用するための条件として，自らもサービス（資源）を供出しなければならない。これにより，適切なノードの参加を促し，不適切なノードの排除を促し，システム環境全体の実装などを効率化する。
【００１４】
　上記仕組みとして，本システムでは，あるノードによるサービス（資源）の提供の行為における正確性などを，別のノードにより評価し，その評価結果を，当該サービス（資源）を提供したノードによる別のサービス（資源）の利用（その権限等）に反映する仕組みを有する。
【００１５】
　例えば，上記評価処理として，評価主体のノードは，評価対象のノード毎のサービス（資源）の提供の行為における，正確な応答データの有無などを判断することにより，上記正確性を評価する。当該評価（評価情報）として，例えば，当該ノードに関する利用の権限やポイント等を増減する。そして，当該評価結果の反映として，当該評価情報に応じて，当該評価対象のノードによるサービス（資源）の利用に関する制御（許可等）を実行する。
【００１６】
　本システム形態は，例えば，ユーザのコンピュータによるノード（群）が通信接続されるネットワークを有し，前記ノードは，ハードウェア及びソフトウェアによる資源を提供することにより，クラウドコンピューティングによるサービス（各種のサービス）を提供する処理を行う提供機能と，前記サービスを要求して利用する処理を行う利用機能と，前記利用機能を用いるノード（第１のノード）と前記提供機能を用いるノード（第３のノード）との間に介在して前記サービスを実行（制御等）する処理を行う実行機能と，前記提供機能を用いるノード（第３のノード）による前記サービス（その資源）の提供の行為を評価してその評価情報を保持するための評価機能と，を有する。例えば第１のノード（ＮＡ）は利用機能，第２のノード（ＮＢ）は実行機能及び評価機能，第３のノード（ＮＣ）は提供機能，第４のノード（ＮＤ）は評価機能を用いた処理を行う。
【００１７】
　本システムでは，前記サービス（各種サービスのうちいずれのサービスでもよい）の実行（利用）時，第１のノードの利用機能は，第２のノードの実行機能を経由して，第１のグループの複数の第３のノードの提供機能にアクセスし，当該提供機能からの応答が，当該第２のノードの実行機能を経由して，当該第１のノードの利用機能へ応答される処理が行われる。また，上記処理に伴い，前記第２のノードまたは第４のノードの評価機能は，前記第１のグループの複数の第３のノードの提供機能の各々からの応答を評価処理し，その評価情報を保存する。そして，本システムでは，前記評価情報における評価の高低に基づいて，前記第３のノードが前記サービス（各種サービスのうちいずれのサービスでもよい）を利用する際における前記利用機能（即ち前記第１のノードの利用機能と同じ）からの前記サービスの利用（実行）時，当該利用の可否などを制御する（前記評価の高低を，前記サービスの利用の条件に反映する）。」
「【００２２】
　図１のように，本実施の形態のシステム（クラウドコンピューティングシステム）は，インターネットにおいて，不特定多数の参加者（ユーザＵ）によるコンピュータのノードＮ群の接続（配置）によりネットワーク１００が構成される。本システムでは，ノードＮでクラウド的なサービスＳのための資源（記憶資源や計算資源）を提供（供出）し，ノードＮ間で当該サービスＳ（資源）を相互に利用し合う，オープン（参加／離脱が自由），完全分散型のクラウドコンピューティングの情報処理システムである。完全分散型とは，集中管理ノードなどの特別なノードを持たず，各ノードが同様の機能を持つこと等を指す。
【００２３】
　本システムでは，参加者のノードによるサービス（資源）の提供の行為（貢献度）を評価し，その評価結果に応じたサービス（資源）の利用を可能にする仕組みを持つ。これにより，ノードによるサービス（資源）の提供と利用のバランスをとる。本システムでは，参加者のノードに対し，サービス（資源）の提供（供出）の対価として，サービス（資源）の利用を可能とする。逆に言えば，サービス（資源）の利用の条件として，サービス（資源）の提供（供出）を要求（強制）する。ユーザは，サービス（資源）の提供の評価に応じて，サービス（資源）を利用する権限やポイントなどを得る。」
「【００２７】
　サービスＳは，基本的な，ストレージサービスと，コンピューティングサービス（計算サービス）と，を含む。ストレージサービスは，複数のノード（それらで供出される記憶資源）に保存されるデータ（コンテンツ）に対する読み書き等の操作を行うことができるサービスである。計算サービスは，複数のノード（それらで供出される計算資源）に対して，データ（コンテンツ）と操作（オペレーション）の組を与え，当該ノードで当該データに対し当該操作を適用した結果を新しいデータとして返すことができるサービスである。
【００２８】
　評価機能（評価処理）としては，評価主体のノードは，例えばストレージサービスを提供するグループの各ノード（評価対象のノード）から，正確な応答データを正常に受信できたか否か等の判断により，当該ノードによるサービス（資源）の提供の正確性などを評価する。その評価結果（評価情報Ｐ）は，所定のノード（評価処理に係わるグループの複数のノード）に保存され，当該各ノード（評価対象のノード）におけるサービス（資源）の利用の権限やポイントなどに反映される。」
「【００３０】
　＜概念２−規約＞
　本システム環境において，ノード群のサービス（資源）の提供と利用のバランスをとり，公平性などを確保するために，参加者（ノード）が遵守すべき規約を有する。本規約の目標の１つとして，大多数の参加者のノードが本規約を遵守することにより，本規約を遵守しない参加者のノード（不適切なノード）による実装（群）が本システム環境から自動的に排除されることがある。本システムのノードは，本規約を反映（実装）した構成（図２のモジュール１０）を持つ。
【００３１】
　本システムは，参加者のノードが規約を正しく遵守していることを評価する仕組みを有する。この仕組みとして，特に，ノードによるサービス（資源）の提供による貢献を正確性などによって評価するものである。
【００３２】〜【００３８】（省略）
【００３９】
　サービス提供の評価における評価情報（ポイント）Ｐは，上記証明書に基づいて，アイデンティティ（そのノード）単位に管理される。」
「【００４１】
　＜概念４−評価方式＞
　本システムのネットワーク１００上，アイデンティティ（それに対応付けられるノード）におけるサービス（資源）の提供と利用のバランスを確保，管理するための仕組み（評価方式）及びその主体（ノードやその機能）を設ける。
【００４２】
　本システムでは，図３，図４のように，サービスＳに関する，利用（ＮＡ），実行等（ＮＢ），提供（ＮＣ），評価等（ＮＤ）といった各ノード状態（機能）のノード間で処理が行われる。各ノードは，その都度の処理・状態に応じて機能（図２の２１〜２４）を切り替える。例えばノードＮＢは，サービスの実行の制御の際にはＮＢ機能２２を用いた処理を行い，評価に係わる処理の際にはＮＤ機能２４を用いた処理を行うように切り替える。
【００４３】
　ノード（サービス提供ノードＮＣ）によるサービスＳ（資源）の提供の行為（正確性など）を正しく公平に評価するために，サービス利用ノードＮＡは，所定のアルゴリズムに従って決定されるノード（ＮＢ，ＮＤ等）を経由して，サービス提供ノードＮＣによるサービスＳを利用する。
【００４４】
　本実施の形態では，評価主体として，当該所定のノード（ＮＢ，ＮＤ等）を用いて，最終的なサービス提供ノードＮＣ（そのアイデンティティ）を評価対象として，当該サービス提供ノードＮＣによるサービス（資源）の提供に係わる評価（評価処理）を行う。特に，第１の評価方式では，サービス実行ノードＮＢにより評価処理を行い，第２の評価方式では，サービス評価ノードＮＤにより評価処理を行う。
【００４５】
　評価（評価処理）の対象は，ノード（グループの複数の各ノード）によるサービスＳ（資源）の提供の行為における正確性などである。この正確性の評価については，簡単には例えば，ノードＮＢ−ＮＣ間における正確な応答の有無を２値的に判断することによる。また２値に限らず，上記提供（応答）の品質を多値で評価してもよい。例えば，応答時間（要求−応答に要した時間）の判断や，応答データの内容を正確な応答データと比較した場合の相違の程度の判断などによる。
【００４６】
　また，評価処理としては，評価主体のノード（ＮＢ）は，サービスＳ（例えばストレージサービス）に応じたグループの複数のノードＮＣによる応答結果（例えばデータＤ）を，相互比較して，多数決的に，正確性などを判断，評価する。即ち例えば，一番多数の応答結果を正しい応答とみなし，他（少数）の応答結果を誤った応答とみなす，等である。
【００４７】〜【００４８】（省略）
【００４９】
　また，他の評価方式として，上記サービス（資源）の提供の評価によるポイント（評価値）を，サービス（資源）の利用に関するポイント（ポイントサービスのような方式）とも捉える方式としてもよい。即ち，サービス提供単位（評価の向上）毎に当該ポイントを増やし，サービス利用毎に当該ポイントを減らす（消費する）ような方式である。
【００５０】
　また，自ノード内に自ノードに関する評価情報（ポイント）Ｐを保持しない仕組みにより，例えば悪意ある参加者が当該ポイントを改ざん等してサービス利用すること等が防止される。なお，上記改ざん等の情報セキュリティ上の問題が解決できるのであれば，自ノード内に自ノードに関する評価情報Ｐを保持して参照可能にする形態としてもよい。
【００５１】
　＜ネットワーク＞
　上記に基づき，詳細な実施の形態について以下に説明する。図１において，本システムにおける，参加者（ユーザＵ−アイデンティティ）のノードＮ（群）によるネットワーク１００を示している。いくつかのノードＮ（例：Ｎ１〜Ｎ８）のみを概略的に示す。Ｎ１に限らず，各ノードＮｉ毎に，ユーザＵｉ（アイデンティティ，証明書），ＩＰアドレスＡｉ，そのハッシュ値Ｂｉ，評価情報（ポイント）Ｐｉ，管理情報Ｍｉ，等が対応付けられるとする。なおノードＮｉ毎の評価情報（ポイント）Ｐｉは，自ノードＮｉ内ではなく，他ノード（後述のＮＤ）内に保持・管理され，必要に応じてその情報が参照される。」
「【００５３】
　＜ノード，モジュール＞
　図２において，ノードＮの構成例を示す。各参加者（ユーザＵ）のノードＮは，本システムの仕組みを実現するモジュール１０がインストールされる，例えばＰＣなどのコンピュータである。モジュール１０は，プログラム等による構成であり，ノードＮにより実行される。ユーザは，ノードＮ（モジュール１０）を稼働させた状態（ネットワーク１００に接続した状態）において，外部（他ノードＮ）にクラウド的なサービス（資源）を提供し，また，外部（他ノードＮ）のクラウド的なサービス（資源）を利用する。その提供と利用は，その都度，ユーザにより選択や設定ができる。
【００５４】（省略）
【００５５】
　ノードＮは，ハードウェア１０１（ＣＰＵ，メモリ，ディスク，ＩＯ（周辺機器）など），及びソフトウェア１０２（ＯＳ，ミドルウェア，サーバ，ブラウザ，アプリケーションなど）を備える。これらが記憶資源１０３や計算資源１０４に相当する。」
「【００６４】
　＜クラウドコンピューティングサービス＞
　本システムにおいて，基本的なクラウドコンピューティングサービス（クラウド的なサービスＳ）の機能について説明する。このサービスＳ自体の仕組みは，既存技術と基本的に同様である。
【００６５】
　本サービスＳは，基本的なものとして，ストレージサービス１３ａと，コンピューティングサービス（計算サービス）１３ｂと，を含む。それぞれ識別のためのサービスタイプＴを，Ｔ１，Ｔ２とする。サービス毎に異なるサービスタイプＴ等の情報が設定され管理情報Ｍに管理される。」
「【００７１】
　＜モデル，処理の流れ＞
　図３，図４を用いて，本システム（ネットワーク１００）におけるノード群によるサービスＳの実行時（利用（要求），提供（応答），評価等）における一連の処理の流れやモデルについて説明する。図３，図４では，ユーザＵ１のノードＮ１（ＮＡ）から，サービスＳ（例えばストレージサービス（Ｔ１））を利用する場合における，各状態のノード（ＮＡ，ＮＢ，ＮＣ，ＮＤ）の接続関係の例を示している。図３は特にサービス提供ノードＮＣとなるグループＧ１を示す。図４は特にサービス評価ノードＮＤとなるグループＧ２を示す。
【００７２】
　ノードＮＡ（例えばＮ１）は，ＮＡ機能２１により，クラウド的なサービスＳを要求して利用するノードであり，「サービス利用ノード」と称する。ノードＮＣ（例えばＮ３（ＮＣ１），Ｎ４（ＮＣ２），Ｎ５（ＮＣ３））は，ＮＣ機能２３により，クラウド的なサービスＳを提供するノードであり，「サービス提供ノード」と称する。
【００７３】
　ノードＮＢ（例えばＮ２）は，ノードＮＡによるサービスＳの利用と，ノードＮＣによる当該サービスＳの提供との間に介在（経由）するノードであり，「サービス実行ノード」と称する。ノードＮＢは，ＮＢ機能２２により，サービスＳの実行を制御し，ノードＮＣによるサービスＳの提供を把握してログ情報Ｌとして記録すると共に，当該提供（応答）を評価処理して評価情報Ｐとして記録し，これらの情報をノードＮＤに送信して保存させる。
【００７４】
　ノードＮＤ（ＮＤａ，ＮＤｃ）は，ＮＤ機能２３により，サービス提供ノードＮＣに関する評価情報Ｐ等を保持し，またノードＮＢからの要求（参照）に応じて当該評価情報Ｐ等を確認または提供するノードであり，「サービス評価ノード」と称する。ノードＮＤｃ（例えばＮ６）は，図３のノードＮＣ（グループＧ１）に関するログ情報Ｌ（Ｌｃ）及び評価情報Ｐ（Ｐｃ）を保持するノードである。評価情報Ｐｃの中には，グループＧ１の各ノード（Ｎ３〜Ｎ５）の評価情報（ポイント）（Ｐ３〜Ｐ５）が含まれている。同様に，ノードＮＤａ（例えばＮ８）は，図３のノードＮＡ（Ｎ１）（当該ノードがＮＣ状態の時）に関するログ情報Ｌ（Ｌａ）及び評価情報Ｐ（Ｐａ）を保持するノードである。評価情報Ｐａの中には，当該ノードＮ１の評価情報（ポイント）Ｐ１が含まれている。」
「【００７７】
　（１）（ａ１：サービス要求）：　サービス利用ノードＮＡ（Ｎ１）（そのＮＡ機能２１）から，サービス実行ノードＮＢ（Ｎ２）（そのＮＢ機能２２）へ，サービスＳの利用要求を発行・送信する。この要求には，［サービスタイプ（Ｔ１）＋キー（Ｋａ）］等の情報（その他，適宜，書き込みデータ，操作の指示等の情報）が含まれる。例えば，ＮＡ（Ｎ１）は，管理情報Ｍ（Ｍ１）の参照に基づき，アクセス先となるＮＢを決定してアクセスする。
【００７８】
　（２）（ｂ１，ｂ２：評価情報確認）： サービス実行ノードＮＢ（Ｎ２）は，ＮＡからのアクセス（ａ１）に対し，管理情報Ｍ（Ｍ２）の参照に基づき，まず，ノードＮＤ（ＮＤａ：ＮＡ（Ｎ１）に関する評価情報Ｐａ（Ｐ１）を保持しているノード）に対して，当該ＮＡ（Ｎ１）に関する評価情報Ｐａ（Ｐ１）の確認（参照）のためのアクセス・要求（ｂ１）を行う。本実施の形態では，ノードＮＢのＮＢ機能２２（またはＮＤ機能２４）は，ノードＮＤａ（ＮＤ機能２４）にアクセスし，当該ノードＮＡの評価情報Ｐａを確認し，当該サービスＳの実行を制御する。なお当該評価情報Ｐの確認の処理についても所定のサービスとして実現され，アクセス先は所定のグループＧ３の複数のノードＮＤａとなる。
【００７９】
　上記アクセス（ｂ１）に対し，例えば，ＮＤａ（Ｎ８）は，管理情報Ｍ（Ｍ８）及び評価情報Ｐａ（Ｐ１）の参照に基づき，当該ノードＮＡ（Ｎ１）（そのアイデンティティ）が現在のポイントＰ１等に応じて当該サービスＳの利用（実行）が許可されるか否か（権限）等を確認する。あるいは，他の方式では，ＮＤａは，当該サービスＳの利用のために当該ノードＮＡ（Ｎ１）のポイントＰａ（Ｐ１）を消費（減少）する処理などを行う。
【００８０】〜【００８２】（省略）
【００８３】
　（４）（ａ２：サービス実行（要求））：　ＮＢ（ＮＢ機能２２）は，アクセス先のグループＧ１の複数（３つ）の各ノードＮＣ（ＮＣ１〜ＮＣ３）（キーＫａのデータＤａを保有するノード）に対し，並列的に，サービスＳの提供の要求を送信する（ａ２−１〜３）。当該要求には，サービスタイプＴ１，キーＫａ，操作指示等の情報が含まれる。例えばデータＤａ自体の参照（読み出し）の要求である。
【００８４】（省略）
【００８５】
　（５）（ａ３：サービス提供（応答））：　ＮＢからの要求（ａ２）を受けた各ノードＮＣ（ＮＣ機能２３）は，稼働状態の場合において，自ノードの記憶資源４３における，キーＫａにより指定されるデータＤａに対する指定の操作（例えば読み出し）を行い，その結果（例えばデータＤａ自体）をＮＢへ応答として送信する（ａ３−１〜３）。ＮＢは，各ＮＣ（ＮＣ１〜ＮＣ３）からの応答を受信する。ただし，ＮＣが非稼働状態，高負荷状態，ＮＢ−ＮＣ間の通信リンクが障害状態，などの場合には，正確で迅速な応答は得られない。また，その時点のノードＮＣの状況（例えば非稼働状態）によっては，当該対象データＤａを更新できない場合もあるが，少なくとも１つのノードＮＣで当該データを更新できれば，その後，当該グループＧ１内のノードＮＣ間で当該データを授受（コピー）することにより（２０５），各ノードＮＣで当該データＤａを保持することができる。
【００８６】（省略）
【００８７】
　（７）（評価処理）：　ノードＮＢは，上記処理（ａ３，ａ４）を行うと共に，ノードＮＤ（グループＧ２）との間で，ノードＮＣ（サービスＳの提供）に関する評価に係わる処理を行う。まず，ＮＢ（ＮＢ機能２２）は，Ｇ１の各ＮＣによる応答の状態・結果を含む，当該サービスＳ（Ｔ１）の実行（２０１，２０３）の状態・結果（実績）に関して，ログ情報Ｌ（Ｌｃ）を記録する。また，ＮＢ（ＮＤ機能２４）は，Ｇ１の各ＮＣの応答結果（ａ３−１〜３）について評価処理を行う。詳しくは例えば，ＮＢは，各ＮＣの応答結果を集計し，多数決的な判断に基づいて，各ＮＣの応答の正確性を評価する。例えば各ＮＣからの応答結果が同一であることをもって，正しい応答内容であることが確認できる。またＮＢは，例えば各ＮＣから正確な応答（そのデータ）を正常に（迅速に）受信できたか（ＯＫ）否か（ＮＧ）を２値で判断し，それにより当該ノードＮＣの評価値（ポイント）を増減する。計算サービス（Ｔ２）の場合にも，他の応用的サービス（Ｔｄ）の場合にも，同様な考え方で評価可能である。ＮＢは，上記評価処理の結果により評価情報Ｐ（Ｐｃ）を作成し，例えばログ情報Ｌ（Ｌｃ）と共に，またはその一部として，記録する。」
「【００９０】
　（ｂ３：評価情報の保存）：　ＮＢ（そのＮＤ機能２４）は，上記評価処理に基づき，上記ログ情報Ｌｃ及び評価情報Ｐｃを，所定のグループＧ２の複数の各ノードＮＤ（ＮＤｃ）（そのＮＤ機能２４）へ送信（コピー）して保存させる。なお各ＮＤはｂ３に対する応答をＮＢへ返してもよい。この評価情報Ｐ等の保存の処理についても，所定のサービスＳ（サービスタイプをＴｄとする）として実現され，当該処理の際にアクセス先となる複数のノードＮＤｃによるグループＧ２（例えば図４の３つのノードＮＤ１〜ＮＤ３）についても，前述同様に，所定のハッシュ処理（入力値：例えば［Ｔｄ］を含む）により決定される。なおＮＤとして，ＮＣとは異なるノードが選択，決定される。
【００９１】
　グループＧ２の複数の各ノードＮＤｃ（例えばＮ６）（そのＮＤ機能２４）は，内部に，ＮＣ（Ｇ１）に関するログ情報Ｌｃ及び評価情報Ｐｃを保存（登録）する。評価情報Ｐｃには，各ＮＣ（例：Ｎ３〜Ｎ５）に関するポイント（例：Ｐ３〜Ｐ５）が含まれる。なお，その時点のノードＮＤの状況（例えば非稼働状態）によっては，当該ログ情報Ｌｃ及び評価情報Ｐｃを保存できない場合もあるが，少なくとも１つのノードＮＤｃで当該情報を保存できれば，その後，当該グループＧ２内のノードＮＤｃ間で当該情報を授受（コピー）することにより（３０５），各ノードＮＤｃで当該情報を保持することができる。
【００９２】
　上記ＮＤによる評価情報Ｐは，評価方式に応じて，例えば，当該ノードＮＣの評価値（ポイント）の絶対値（現在値）であり，ＮＢからの評価情報Ｐ（増減量）を加算することにより更新される。」
　上記【００１４】【００１５】【００２３】【００２８】の「評価結果」の記載から，「評価結果」と「評価情報」は同じものである。
イ　上記アから，引用文献１には，次の発明（以下，「引用発明１」）が記載されていると認められる。
　不特定多数の参加者（ユーザＵ）によるコンピュータのノード群の接続（配置）によりネットワーク１００が構成されるクラウドコンピューティングシステムであって（【００２２】），
　ノードは，ハードウェア１０１（ＣＰＵ，メモリ，ディスク，ＩＯ（周辺機器）など），及びソフトウェア１０２（ＯＳ，ミドルウェア，サーバ，ブラウザ，アプリケーションなど）を備え（【００５５】），
　クラウド的なサービスＳを要求して利用するノードであって「サービス利用ノード」と称されるノードＮＡ，及び，クラウド的なサービスＳを提供するノードであって「サービス提供ノード」と称されるノードＮＣと（【００７２】），
　ノードＮＡによるサービスＳの利用と，ノードＮＣによる当該サービスＳの提供との間に介在（経由）するノードであり「サービス実行ノード」と称されるノードＮＢと（【００７３】），
　サービス提供ノードＮＣに関する評価情報等を保持する，必要に応じて評価情報等が参照されるノードであって「サービス評価ノード」と称されるノードＮＤと（【００５１】【００７４】），
　を有するネットワーク１００を備え（【００７１】），
　参加者（ノード）の遵守すべき規約を有し，参加者のノードが規約を正しく遵守していることを評価する仕組みを有し（【００２３】【００３０】【００３１】），
　その評価情報は，当該各ノード（評価対象のノード）におけるサービス（資源）の利用の権限やポイントなどに反映され，評価情報はノード単位で管理され（【００２８】【００３９】），このとき，評価情報は，評価による評価値（ポイント）の絶対値であって，サービスＳの提供の評価によるポイントを，サービスＳの利用に関するポイントと捉えることができ（【００４９】【００９１】【００９２】），
　ノードＮＢは，
　サービス利用ノードＮＡからのサービスＳの利用要求に対し，サービス提供ノードＮＣによるサービスＳを利用させることができ（【００４３】【００７７】），
　各ノードＮＣに対し操作指示等の情報を含むサービスＳの提供要求を送信し，各ノードＮＣから，指定の操作の結果である応答を受信し（【００８３】【００８５】），
　評価主体として，最終的なサービス提供ノードＮＣ（そのアイデンティティ）を評価対象として，当該サービス提供ノードＮＣによるサービス（資源）の提供に係わる評価（評価処理）を行うものであって，ノードＮＣからの上記応答について評価処理を行い（【００４４】【００８７】），
　上記評価処理は，サービスＳに応じたグループの複数のノードＮＣによる応答結果を，相互比較して，多数決的に，正確性などを判断，評価する処理であり（【００４６】），
　上記評価処理に基づき，評価情報を，複数の各ノードＮＤへ送信（コピー）して保存させ（【００９０】），
　ノードＮＤが評価情報を保存できない場合，少なくとも１つのノードＮＤで当該情報を保存させる（【００９１】），
　ノードＮＤは，ノードＮＢからの要求（参照）に応じて当該評価情報等を確認または提供する（【００７４】），
　クラウドコンピューティングシステム（【００２２】）。
（３）当審の判断
ア　特許法第２９条第２項について
（ア）本件発明１について
　本件発明１を次のとおり分説する。
Ａ　　少なくとも１つの奨励プロトコルネットワーク参加者の計算装置と，
Ｂ　　奨励プロトコルプラットフォームをホストする第１のサーバーと，
Ｃ　　前記第１のサーバーと通信し，分散型台帳をホストする少なくとも１つの第２のサーバーと，
Ｄ　を有する奨励プロトコルネットワークを備え，
Ｅ　前記第１のサーバーは，
Ｆ　　前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に関連する奨励プロトコルネットワーク参加者のイベントに関連付けされた奨励イベントデータを受信し，
Ｇ　　前記奨励イベントデータおよび少なくとも１つの奨励プロトコルシステム規則に基づいて，奨励単価の取引記録を作成し，
Ｈ　　前記奨励単価の取引記録を，前記分散型台帳に取り込ませるために前記分散型台帳に同報送信し，
Ｉ　　作成された前記奨励単価の取引記録に基づいて奨励単価の価値を計算し，
Ｊ　　前記奨励単価の価値を前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に分配する，
Ｋ１　ような命令を実行し，
Ｌ　前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配が，前記奨励プロトコルネットワーク参加者のデジタルウォレットに対するものである
Ｋ２　ことを特徴とするシステム。
（イ）対比
　本件発明１と引用発明１とを対比する。
あ　「奨励プロトコル」について
　引用発明１の「ポイント」は，サービスを提供するノードが規則を遵守しようとするインセンティブになる点で，本件発明１の「奨励」に相当する。そして，引用発明１には，ノードのユーザである参加者に，遵守すべき「規約」があり，参加者のノードが規約を正しく遵守することで評価されるものであって，評価情報は利用の権限やポイントに反映されることから，引用発明１の「規約」は，本件発明１の「奨励プロトコル」に相当する。
い　構成要件Ａについて
　引用発明１の「ノード」は，ハードウェア１０１（ＣＰＵ，メモリ，ディスク，ＩＯ（周辺機器）など），及びソフトウェア１０２（ＯＳ，ミドルウェア，サーバ，ブラウザ，アプリケーションなど）を備えており，その時々の利用のされ方に応じて，ノードＮＡ，ノードＮＢ，ノードＮＣ，ノードＮＤとして機能する。
　そして，これらのノードには遵守すべき規約があり，これらのノードにより構築された引用発明１の「ネットワーク１００」は，上記「あ」を踏まえると，本件発明１の「奨励プロトコルネットワーク」に相当し，引用発明１のノードのユーザは，本件発明１の「参加者」に相当し，引用発明１の，その時々の利用のされ方に応じて，ノードＮＡ，ノードＮＢ，ノードＮＣ，ノードＮＤとして機能する「ノード」は，本件発明１の「計算装置」に相当する。
　以上より，引用発明１の，「ネットワーク１００」を構成する「ユーザ」の「ノード」は，本件発明１の「少なくとも１つの奨励プロトコルネットワーク参加者の計算装置」に相当する。
う　構成要件Ｂについて
　引用発明１は，ノードが正しく「規約」を遵守しているかを評価するための環境を有しており，上記「あ」を踏まえると，引用発明１の当該「環境」は，本件発明１の「奨励プロトコルプラットフォーム」に相当する。
　そして，引用発明１の「ノードＮＢ」は，上記「環境」において，ノードＮＡとノードＮＣとの間に介在（経由）するノードであって，ノードＮＡからのサービスＳの利用要求に対して，ノードＮＣによるサービスＳを利用させるというサービスを提供する点で，「サーバー」として機能するものであり，規約が遵守されているかを評価する「評価主体」である点で，引用発明１の「ノードＮＢ」は，本件発明１の「奨励プロトコルプラットフォームをホストする第１のサーバー」に相当する。
え　構成要件Ｃについて
　引用発明１は，評価情報が複数のノードＮＤに送信（コピー）されることで，複数のノードＮＤは同じ評価情報を保持されるから，分散型ということができ，評価情報は必要に応じて参照されるように，評価情報（ポイント）の増減を記録しているものであり，台帳等の形態で管理されることは技術常識であるから，引用発明１における，ノードＮＤで保持される当該台帳等の形態は，本件発明１の「ホスト」される「分散型台帳」に相当する。
　さらに，引用発明１の「ノードＮＤ」は，ノードＮＢからの要求（参照）に応じて当該評価情報等を確認または提供する点で，ノードＮＢと通信をする「サーバー」として機能するものである。
　以上より，引用発明１の，「ノードＮＢ」と通信し，「評価情報等を保持する」「ノードＮＤ」は，本件発明１の「前記第１のサーバーと通信し，分散型台帳をホストする少なくとも１つの第２のサーバー」に相当する。
お　構成要件Ｄについて
　上記「い」のとおり，引用発明１の「ネットワーク１００」は，本件発明１の「奨励プロトコルネットワーク」に相当する。
か　構成要件Ｅについて
　後述する相違点は別にして，上記「う」のとおり，引用発明１の「ノードＮＢ」は，本件発明１の「第１のサーバー」に相当する。
き　構成要件Ｆについて
　引用発明１の，サービス利用ノードＮＡが，サービス提供ノードＮＣによるサービスＳを利用するということは，イベントということができ，本件発明１の「イベント」に相当する。そして，引用発明１の，ノードＮＢが受信するものであって，ノードＮＣに対し送信した操作指示等の情報を含むサービスＳの提供要求に対する，「所定の操作の結果である応答」は，サービスＳに関連付けられているデータであって，評価の対象となる点で，本件発明１のイベントに関連付けられた「奨励イベントデータ」に相当する。
　よって，引用発明１における「ノードＮＢ」が，サービスＳの提供要求に含まれる操作指示の「結果である応答」を受信することは，本件発明１の「前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に関連する奨励プロトコルネットワーク参加者のイベントに関連付けされた奨励イベントデータを受信」することに相当する。
く　構成要件Ｇ，Ｊについて
　引用発明１の，ノードＮＢが，複数のノードＮＣからの応答結果を，相互比較して，多数決的に，正確性などを判断，評価する評価処理を行うことは，規約に基づく評価処理であるから，引用発明１のこのような評価処理の内容及び手順は，本件発明１の「奨励プロトコルシステム規則」に相当する。そして，引用発明１の，ノードＮＢによる評価処理に基づき得られる「評価情報」は，評価情報をサービス（資源）の利用の権限やポイントなどに反映するためのものである点で，本件発明１の「奨励単価の取引記録」に相当し，引用発明１の「ポイント」は，「サービスＳの利用に関するポイント」の点において，本件発明１の「奨励単価の価値」に相当する。
　よって，引用発明１の「ノードＮＢ」が，「規約」に基づき，複数のノードＮＣからの応答結果を，相互比較して，多数決的に，正確性などを判断，評価する評価処理を行い，評価情報を得ることは，本件発明１構成要件Ｇの「前記奨励イベントデータおよび少なくとも１つの奨励プロトコルシステム規則に基づいて，奨励単価の取引記録を作成し」に相当する。
　また，引用発明１において，「評価情報」は，評価による評価値（ポイント）であって「サービスＳの提供の評価によるポイント」を，「サービスＳの利用に関するポイント」と捉えることができることから，引用発明１の「評価情報」を「ノード単位で管理」することは，「ノードＮＢ」がサービスＳを提供したノードＮＤに対して評価情報を付与する点で，本件発明１構成要件Ｊの「前記奨励単価の価値を前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に分配する」ことに相当する。
け　構成要件Ｈについて
　引用発明１における，ノードＮＢが評価処理に基づき，「評価情報」を，複数の各ノードＮＤへ送信（コピー）して保存させることは，同報送信の点が不明であるものの，本件発明１の「前記奨励単価の取引記録を，前記分散型台帳に取り込ませるために前記分散型台帳に同報送信し」と，「前記奨励単価の取引記録を，前記分散型台帳に取り込ませるために前記分散型台帳に送信し」で共通する。
こ　構成要件Ｋ１及びＫ２について
　引用発明１における，「クラウドコンピューティングシステム」は，後述する相違点は別にして，不特定多数の参加者（ユーザＵ）によるコンピュータのノード群の接続（配置）によりネットワーク１００が構成され，ノードＮＢがノードＮＡからのサービス要求に対して，ノードＮＣによるサービスＳを利用させるというサービスを提供し，ノードＮＤに評価情報を保持させる点で，本件発明１の「ような命令を実行する」「システム」に相当する。
さ　一致点及び相違点
　上記「あ」〜「こ」から，本件発明１と，引用発明１の一致点及び相違点は，次のとおりである。
＜一致点＞
　　少なくとも１つの奨励プロトコルネットワーク参加者の計算装置と，
　　奨励プロトコルプラットフォームをホストする第１のサーバーと，
　　前記第１のサーバーと通信し，分散型台帳をホストする少なくとも１つの第２のサーバーと，
　を有する奨励プロトコルネットワークを備え，
　前記第１のサーバーは，
　　前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に関連する奨励プロトコルネットワーク参加者のイベントに関連付けされた奨励イベントデータを受信し，
　　前記奨励イベントデータおよび少なくとも１つの奨励プロトコルシステム規則に基づいて，奨励単価の取引記録を作成し，
　　前記奨励単価の取引記録を，前記分散型台帳に取り込ませるために前記分散型台帳に送信し，
　　前記奨励単価の価値を前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に分配する，
　ような命令を実行することを特徴とするシステム。
＜相違点＞
（相違点１）
　本件発明１は，「作成された前記奨励単価の取引記録に基づいて奨励単価の価値を計算」する構成であるのに対し，引用発明１は，奨励単価の取引記録に相当する「評価情報」を表す「サービスＳの提供の評価によるポイント」を，奨励単価の価値に相当する「サービスＳの利用に関するポイント」と捉える点。
（相違点２）
　本件発明１は，奨励単価の取引記録を，分散型台帳に取り込ませるために分散型台帳に「同報」送信するのに対し，引用発明１は「同報」送信であるか定かではない点。
（相違点３）
　「前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配」が，本件発明１では，「前記奨励プロトコルネットワーク参加者のデジタルウォレット」に対して行われるのに対し，引用発明１では，複数の各ノードＮＤに保持・管理させ，分配対象の「前記奨励プロトコルネットワーク参加者」に対して保持させるものではない点。
（ウ）相違点の判断
あ　相違点１について
　引用発明１の「ポイント」について，「サービスＳの提供の評価によるポイント」を，「サービスＳの利用に関するポイント」と捉えることは，引用発明１においては，「サービスＳの提供の評価によるポイント」を，そのまま，「サービスＳの利用に関するポイント」として用いるものであって，２つの概念の異なるポイントを，１対１の関係で対応付けているものである。
　そうすると，引用発明１において，評価情報である「サービスＳの提供の評価によるポイント」を，「サービスＳの利用に関するポイント」と捉えることは，本件発明１の「奨励単価の取引記録」に基づいて「奨励単価の価値」を計算することと，技術的に同じ事項を意味することから，相違点１の構成は，表現上の差異にすぎない。また，表現上の差異でないとしても，引用発明１に基づき，相違点１の構成とすることに技術的困難性はなく，当業者が容易に想到することのできた事項である。
い　相違点２について
　引用発明１は，同報送信であるかは定かではないが，複数のノードＮＤに評価情報を保存させるものである。また，引用文献１【００９１】には，「ノードＮＤの状況（例えば非稼働状態）によっては，当該ログ情報Ｌｃ及び評価情報Ｐｃを保存できない場合もあるが，少なくとも１つのノードＮＤｃで当該情報を保存できれば，その後，当該グループＧ２内のノードＮＤｃ間で当該情報を授受（コピー）することにより（３０５），各ノードＮＤｃで当該情報を保持することができる。」として，評価情報を「少なくとも１つのノードＮＤ」に送信することが記載されており，複数のノードＮＤに評価情報を送信することができることが示唆されている。また，引用発明１において，ノードＮＤは，ノードＮＡ，ノードＮＢ，ノードＮＣでもないその他の不特定なノードに対してノードＮＤとして機能させることができるものである。そして，ノードＮＢは，そのようなノードＮＤに対して評価情報を送信するものであって，複数のノードＮＤに評価情報を送信する場合は，同報送信しているといえる。
　よって，引用文献１には，ノードＮＢが複数のノードＮＤに対して評価情報を送信することは示唆されており，このとき，ノードＮＢが複数のノードＮＤに対して評価情報を「同報」送信する構成とすることは，引用発明１に基づき，当業者が容易に想到することができた事項である。
う　相違点３について
　本件発明１の「デジタルウォレット」は本件特許明細書において符号２０で示され，図１〜図３，図６〜図８から，「分散型台帳／ブロックチェーン２４」とは異なるものであることは明らかである。そして，本件発明１は，「取引記録」を「分散型台帳」に取り込ませ，「奨励単価の価値」を「デジタルウォレット」に対して分配するものである。
　これに対して，引用発明１は，サービス利用ノードＮＡとは異なるサービス評価ノードＮＤで保持される台帳等の形態が，本件発明１の「分散台帳」に相当し，サービス評価ノードＮＤが評価値（ポイント）である評価情報を保持するものである。そして，引用文献１は，評価情報を自ノード内ではなく，他ノードであるサービス評価ノードＮＤが保持・管理することが記載されている（上記摘記【００５１】【００７４】参照）。これにより，「自ノード内に自ノードに関する評価情報（ポイント）Ｐを保持しない仕組みにより，例えば悪意ある参加者が当該ポイントを改ざん等してサービス利用すること等が防止される」（上記摘記【００５０】参照）もので，これにより，引用文献１には，サービス利用ノードＮＡが，ポイントを用いてサービスの提供を受けるためには，サービス評価ノードＮＤが，当該サービスの利用が許可されるか否か等を確認するものである（上記摘記【００７７】〜【００７９】参照。）。他方，引用文献１には，評価情報とポイントを分けて，ポイントをノードＮＤ（分散型台帳）以外のものに保持・管理させることは記載も示唆もされておらず，技術常識でもない。また，サービス評価ノードＮＤが評価値（ポイント）である評価情報を保持・管理する構成とすることで，上記改ざん等を防止するものであることから，引用発明１において，引用文献１の記載に基づき，ポイントをサービス評価ノードＮＤとは異なるものに保持・管理する構成とすることには阻害要因がある。
　そうすると，引用発明１において，引用文献１の記載に基づき「前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配」が「前記奨励プロトコルネットワーク参加者のデジタルウォレット」に対するものとの構成とすることは，当業者が容易になし得たものとはいえない。
　また，引用文献２（Satoshi Nakamoto，Bitcoin: A Peer-to-Peer Electronic Cash System，URL:https://bitcoin.org/bitcoin.pdf，2008年，［検索日：令和２年１１月２５日］，甲第２号証）には，「2. Transaction」，「6. Incentive」及び「9. Combination and Splitting Value」の項にコインの概念が記載されているものの，ブロックチェーンのブロックでコイン管理されるという，一般的な事項が記載されるのみである。そして，引用文献２の「5. Network」の，ブロックは各ノードが取り入れるものであって，本件発明１の「分散型台帳」が保持することに相当するものの，引用文献２には，分散型台帳とは異なる概念のものがブロックのコインを保持することは記載されていない。このため，引用発明１に引用文献２の当該技術的事項を適用したとしても，「前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配」が「前記奨励プロトコルネットワーク参加者のデジタルウォレット」に対するものとの構成には至らない。
え　よって，本件発明１は，引用発明１及び引用文献２に記載された技術的事項に基づいて，当業者が容易に発明をすることができたものではない。
（エ）本件発明２，５〜８，１０及び１７について
　本件発明２，５〜８及び１７は，本件発明１に対して，さらに「前記分散型台帳にブロックチェーンが含まれていること」（本件発明２），「前記第１のサーバーが，多重署名モデルを用いて奨励単価トークンを鋳造するという命令を実行すること」（本件発明５），「前記第１のサーバーが，多重署名モデルを用いて奨励単価トークンを鋳造するという命令を実行し，前記多重署名モデルは，少なくとも所定数の参加者鍵が提供された場合に，鋳造することを承認し，前記第１のサーバーは，前記承認に基づいて新たに鋳造された奨励単価トークンを同報送信する命令をさらに実行すること」（本件発明６），「前記イベントの種類が取引型であること」（本件発明７），「前記イベントの種類が非取引型であること」（本件発明８），「前記奨励イベントデータが，商用プラットフォームから受信されること」（本件発明１０），「前記第１のサーバーは，多重署名モデルを用いて奨励単価トークンを鋳造するという命令をさらに実行すること」（本件発明１７）という技術的事項を追加したものである。
　よって，上記に示した理由と同様の理由により，本件発明２，５〜８，１０及び１７は，上記引用発明１及び引用文献２に記載された技術的事項に基いて当業者が容易に発明をすることができたものではない。
（オ）特許法第２９条第２項のまとめ
　以上のとおり，本件発明１〜２，５〜８，１０及び１７は，引用発明１及び引用文献２に記載された技術的事項に基いて当業者が容易に発明をすることができたものではない。
イ　特許法第３６条第６項第２号について
　上記訂正事項２により，請求項３及び４は削除された。このため，当審で通知した特許法第３６条第６項第２項の取消理由は存在しない。
ウ　取消理由通知において採用しなかった特許異議申立理由について
（ア）請求項１，２，７，８，１０に対する新規性について
　申立人は，請求項１，２，７，８，１０に係る発明と，甲第１号証（引用文献１）に記載された発明との間に差異はない旨主張する。
　しかしながら，上記ア（イ）「さ」のとおり，独立形式請求項である請求項１に係る発明と，引用発明１との間には相違点があり，請求項２，７，８，１０は，請求項１を引用する引用形式請求項であるため，請求項１に係る発明と，引用発明１との間の相違点と同じ相違点が存在する。
　よって，申立人の主張を採用することはできない。
（イ）請求項２に対する記載不備（明確性）について
　申立人は，請求項２について，「ブロックチェーン」との用語は，特許発明の技術的範囲を確定するための請求項に用いる用語としては不適切である旨主張する。
　しかしながら，「ブロックチェーン」は，甲第２号証によって初めて提唱された技術であることは当業者に知られており，本件発明のブロックチェーンは，甲第２号証のものとは異なるものでないことは明らかであるから，本件発明においても，「ブロックチェーン」は甲第２号証に記載された技術的事項の範囲内であることは明らかである。
　よって，申立人の主張を採用することはできない。
（ウ）請求項１７に対する記載不備（明確性）について
　申立人は，請求項１７に係る発明と請求項５に係る発明は実質的に同一である点で記載不備がある旨主張する。
　しかしながら，特許法第３６条第５項では「一の請求項に係る発明と他の請求項に係る発明とが同一である記載となることを妨げない」と規定されていることから，申立人の当該主張は失当である。
５　むすび
　以上のとおりであるから，取消理由通知に記載した取消理由及び特許異議申立書に記載した特許異議申立理由によっては，本件請求項１〜２，５〜８，１０及び１７に係る特許を取り消すことはできない。
　また，請求項３及び４に係る特許は，上記のとおり，訂正により削除された。これにより，申立人による特許異議の申立てについて，請求項３及び４に係る申立ては，申立ての対象が存在しないものとなったため，特許法第１２０条の８第１項で準用する同法第１３５条の規定により却下する。
　よって，結論のとおり決定する。
【異議決定日】
令和３年９月２日（２０２１．９．２）
【訂正の要旨】
審決（決定）の【理由】欄参照。
（５７）【特許請求の範囲】
　【請求項１】
　少なくとも１つの奨励プロトコルネットワーク参加者の計算装置と、
　奨励プロトコルプラットフォームをホストする第１のサーバーと、
　前記第１のサーバーと通信し、分散型台帳をホストする少なくとも１つの第２のサーバーと、
　を有する奨励プロトコルネットワークを備え、
　前記第１のサーバーは、
　前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に関連する奨励プロトコルネットワーク参加者のイベントに関連付けされた奨励イベントデータを受信し、
　前記奨励イベントデータおよび少なくとも１つの奨励プロトコルシステム規則に基づいて、奨励単価の取引記録を作成し、
　前記奨励単価の取引記録を、前記分散型台帳に取り込ませるために前記分散型台帳に同報送信し、
　作成された前記奨励単価の取引記録に基づいて奨励単価の価値を計算し、
　前記奨励単価の価値を前記少なくとも１つの奨励プロトコルネットワーク参加者の計算装置に分配する、
　ような命令を実行
し、
　前記奨励プロトコルネットワーク参加者に対する前記奨励単価の価値の分配が、前記奨励プロトコルネットワーク参加者のデジタルウォレットに対するものであ
　【請求項２】
　前記分散型台帳にブロックチェーンが含まれていることを特徴とする請求項１に記載のシステム。
　【請求項３】
（削除）
　【請求項４】
（削除）
　【請求項５】
　前記第１のサーバーが、多重署名モデルを用いて奨励単価トークンを鋳造するという命令を実行することを特徴とする請求項１に記載のシステム。
　【請求項６】
　前記第１のサーバーが、多重署名モデルを用いて奨励単価トークンを鋳造するという命令を実行し、前記多重署名モデルは、少なくとも所定数の参加者鍵が提供された場合に、鋳造することを承認し、前記第１のサーバーは、前記承認に基づいて新たに鋳造された奨励単価トークンを同報送信する命令をさらに実行することを特徴とする請求項１に記載のシステム。
　【請求項７】
　前記イベントの種類が取引型であることを特徴とする請求項１に記載のシステム。
　【請求項８】
　前記イベントの種類が非取引型であることを特徴とする請求項１に記載のシステム。
　【請求項９】
　前記奨励イベントデータが、前記奨励プロトコルネットワーク参加者のデジタルウォレットから受信されることを特徴とする請求項１に記載のシステム。
　【請求項１０】
　前記奨励イベントデータが、商用プラットフォームから受信されることを特徴とする請求項１に記載のシステム。
　【請求項１１】
（削除）
　【請求項１２】
　前記第１のサーバーは、前記奨励単価の価値に関連付けられたブランド化された価値を定めている命令をさらに実行し、前記奨励単価の価値が、限られた一部の参加者に利用可能となるように構成されていることを特徴とする請求項１に記載のシステム。
　【請求項１３】
　前記奨励プロトコルネットワーク参加者を第１の奨励プロトコルネットワーク参加者とし、前記奨励単価の価値を第１の奨励単価の価値としたとき、前記第１のサーバーは、
　第２の奨励プロトコルネットワーク参加者から通貨を受け取り、
　前記通貨を第２の奨励単価の価値に変換する、
　ような命令をさらに実行することを特徴とする請求項１に記載のシステム。
　【請求項１４】
　前記奨励プロトコルネットワーク参加者を第１の奨励プロトコルネットワーク参加者としたとき、前記第１のサーバーは、
　第２の奨励プロトコルネットワーク参加者から第１型の奨励単価の価値を受信し、
　前記第１型の奨励単価の価値を第２型の奨励単価の価値に交換する、
　ような命令をさらに実行することを特徴とする請求項１に記載のシステム。
　【請求項１５】
　前記第１のサーバーは、非参加者に関連付けられた非参加者の計算装置にリンクを送信する命令をさらに実行し、前記非参加者の計算装置によりリンクが実行されると、非参加者に対する参加者アカウントが動的に作成され、前記非参加者の計算装置にデジタルウォレットがダウンロードされ、ダウンロードされた前記デジタルウォレットが、動的に作成された前記参加者アカウントに関連付けられるように構成されていることを特徴とする請求項１に記載のシステム。
　【請求項１６】
　前記第１のサーバーは、前記奨励プロトコルネットワーク参加者の生体フィードバック装置から生体データを受信するという命令をさらに実行し、前記奨励単価の取引記録の作成が前記生体データにさらに基づくものであることを特徴とする請求項１に記載のシステム。
　【請求項１７】
　前記第１のサーバーは、多重署名モデルを用いて奨励単価トークンを鋳造するという命令をさらに実行することを特徴とする請求項１に記載のシステム。
　【請求項１８】
　前記第１のサーバーは、複数の奨励単価トークンを鋳造し、前記複数の奨励単価トークンの額または種類のうち少なくとも一方を変更することで、積層化された奨励データを有する奨励単価トークンを生成する、という命令をさらに実行することを特徴とする請求項１に記載のシステム。