• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1376317
審判番号 不服2020-10551  
総通号数 261 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-09-24 
種別 拒絶査定不服の審決 
審判請求日 2020-07-29 
確定日 2021-08-03 
事件の表示 特願2019-502407「ブロックチェーン管理装置、ブロックチェーン管理方法及びプログラム」拒絶査定不服審判事件〔平成30年 9月 7日国際公開、WO2018/158936、請求項の数(8)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続きの経緯

本願は,2017年(平成29年)3月3日を国際出願日とする出願であって,令和2年3月5日付けで拒絶理由通知がされ,令和2年5月1日に意見書が提出されるとともに手続補正がなされ,令和2年5月19日付けで拒絶査定(以下,「原査定」という。)がなされたが,これに対し,令和2年7月29日に拒絶査定不服審判の請求がなされるとともに手続補正がなされ,令和3年4月28日付けで拒絶理由通知(以下,「当審拒絶理由」という。)がされ,令和3年5月27日に意見書が提出されるとともに手続補正がなされたものである。

第2 本願発明

本願請求項1-8に係る発明(以下,それぞれ「本願発明1」-「本願発明8」という。)は,令和3年5月27日付けの手続補正で補正された特許請求の範囲の請求項1-8に記載された事項により特定される発明であり,本願発明1は以下のとおりの発明である。
なお,符号A-Gは,説明のために当審で付与したものであり,以下「構成A」-「構成G」という。

「【請求項1】
A コントラクト,コントラクトへの入力及びコントラクトの実行結果のうち少なくとも1つを含むトランザクションを一つ以上含むブロックを受信するブロック受信部と,
B 前記ブロックに含まれるトランザクションが正当であることを検証するトランザクション検証部と,
C 前記ブロックに含まれるトランザクションが前記トランザクション検証部により正当であると検証された場合に,他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行う合意形成部と,
D 前記合意形成されたブロックを格納する台帳格納部と,
を備え,
E 前記トランザクション検証部は,
コントラクトの安全性を保証する保証者の公開鍵を少なくとも一つ格納する保証者情報格納部と,
前記トランザクションがコントラクトにより構成される場合にトランザクションに含まれる署名を前記保証者情報格納部に格納された保証者の公開鍵で検証するコントラクト署名検証部と,
前記トランザクションがコントラクトの実行結果により構成される場合にトランザクションに含まれるコントラクトの実行結果が対応するコントラクト及びコントラクトの入力に対して正しいことを検証するコントラクト実行結果検証部と,
を備え,
F 前記合意形成部は,
前記受信したブロックから所定のルールで算出されるハッシュ値と,システムに与えられる又は前記台帳格納部に格納された複数のブロックから算出される目標値と,を比較し,比較結果が事前に定められた条件を満たす場合に他のブロックチェーン管理装置と合意形成ができたと判断する,
G ブロックチェーン管理装置。」

なお,本願発明2-8の概要は以下のとおりである。

本願発明5は,本願発明1に対応する方法の発明であり,本願発明1とカテゴリ表現が異なるだけの発明である。
本願発明8は,本願発明1に対応するプログラムの発明であり,本願発明1とカテゴリ表現が異なるだけの発明である。
本願発明2-4及び6-7は,それぞれ本願発明1及び5をさらに減縮した発明である。

第3 引用文献,引用発明等

1.引用文献1

(1)原査定の拒絶の理由で引用された引用文献1(XU, X. et al., The Blockchain as a Software Connector, 2016 13th Working IEEE/IFIP Conference on Software Architecture, 2016年4月, pp.182-191)には,以下の事項が記載されている。

「Ethereum, as a blockchain-based platform, views smart contract as their first-class element. Ethereum has built its own blockchain from scratch with a built-in Turing-complete script language for writing smart contracts. Counterparty has recreated Ethereum smart contract platform on Bitcoin3. The smart contract has been used to enable programmable transactions and machine-to-machine communication in IoT (Internet-ofThings), for example, ADEPT (Autonomous Decentralized Peer-To-Peer Telemetry) project of IBM [10].

III. THE BLOCKCHAIN CONNECTOR

A. Software Connector
Software connectors are the fundamental building blocks of software interactions [16]. A connector is an interaction mechanism for the components. Connectors include pipes, repositories, and sockets. For example, middleware can be viewed as a connector between the components that use the middleware [6]. Connectors in distributed systems are the key elements to achieve system properties, such as performance, reliability, security, etc. Connectors provide interaction services, which are largely independent of the functionality of the interacting components [26]. The services provided by a software connector could be classified into four categories: communication, coordination, conversion and facilitation. Communication services transfer data among components while coordination transfers control among components. Conversion services adjust the interactions to allow components that have not been exactly tailored for each other to establish interactions. Facilitation services help to support and optimise components’ interactions.」(第184頁左列第16-44行)
(当審訳:
ブロックチェーンベースのプラットフォームとしてのイーサリウムはスマートコントラクトを最も重要な要素としてみます。イーサリウムはスマートコントラクトを記述するための作りつけのチューリング完全なスクリプト言語によってブロックチェーンをゼロから作りました。イーサリウムはビットコイン上のスマートコントラクトプラットフォームとして再生成もされました。スマートコントラクトは,例えばIBMのADEPT(Autonomous Decentralized Peer-To-Peer Telemetry)プロジェクトといった,プログラム可能なトランザクション及びIoTにおける装置間の通信を可能にするためにも使用されています。

III.ブロックチェーンコネクタ

A.ソフトウェアコネクタ
ソフトウェアコネクタはソフトウェアの通信の基本的な構成要素です。コネクタはコンポーネントのための通信メカニズムです。コネクタはパイプ,レポジトリ,ソケットを含みます。例えば,ミドルウェアはミドルウェアを使用するコンポーネント間のコネクタとしてみなされることができます。分散システムにおけるコネクタは性能,信頼性,安全性等のシステム特性を達成するための重要な要素です。コネクタは,通信するコンポーネントの機能からほぼ独立している,通信サービスを提供します。そのソフトウェアコネクタから提供されるサービスは4つのカテゴリに分類できます。4つのカテゴリは,通信,調整,変換及び容易化です。通信サービスはコンポ-ネント間のデータを移動する一方,調整サービスはコンポーネント間のコントロールを移動します。変換サービスは通信を確立するためにまだ正確に調整されていないコンポーネント間の通信を可能にするために調整します。容易化サービスはコンポーネントの通信をサポートし,最適化するのを助けます。)

「The data stored in contract storage can be updated through sending transactions to the corresponding contract with new value.」(第186頁左列第6-8行)
(当審訳:
コントラクトストレージに格納されているデータは,新しい値を持つ,対応するコントラクトへトランザクションを送ることによって更新されます。)

「1) Transaction validation: The mechanism to validate transactions is specific to blockchains. Generally, the transactions are validated by being re-executed by the node that receives the transactions. For example, in Bitcoin, the validation of transactions relies on two scripts, including a locking script in the output of a transaction that specifies the conditions to spend the coins referred by the transaction, and an unlocking script that satisfies the conditions placed on a transaction output by the locking script. When a transaction is validated, the unlocking script in each input is executed alongside the corresponding locking script to see if it satisfies the spending condition. The transaction is valid if the result of executing scripts is “TRUE”, which means the unlocking script has succeeded in resolving the spending condition. If the result is not “TRUE” after executing the combined script, the transaction is invalid.
2) Mining mechanism: Mining is a process, in which some nodes within the blockchain network aggregate transactions into blocks. These nodes are called miners in the blockchain network. Once a new block is generated by a miner, the miner propagates the block to the blockchain network. And the new block is included into the public blockchain after the whole network reaching consensus.
There are different mechanisms to select the miner as the next author to update the ledger (Blockchain Design Decision 2 in Table II). In Bitcoin, the miner is chosen at random through “Proof-of-work”. “Proof-of-work” is a piece of data that is very costly to produce but easy to be verified. Producing a “Proof-of-work” is a random process with low probability. Thus, the miners in Bitcoin network compete to generate the “Proof-of-work” through burning their CPU time. The first miner to find the “Proof-of-work” is the potential next author of the blockchain. The difficulty of the work is adjusted to generate a new block every 10 minutes. However, proof of work largely limits the capacity of processing transactions.」(第186頁右列第33行-第187頁左列第14行)
(当審訳:
1)トランザクションの有効化:トランザクションを有効なものとするメカニズムはブロックチェーンに特有です。一般的に,トランザクションはトランザクションを受信したノードによって再実行されることによって有効化されます。例えば,ビットコインでは,トランザクションの有効化は2つのスクリプトによって行われます。その2つのスクリプトは,トランザクションによって参照されるコインを使うための条件を特定する,トランザクションの出力に含まれるロッキングスクリプトと,ロッキングスクリプトによって出力されたトランザクションに配置された条件を満たすアンロッキングスクリプトとを含みます。トランザクションが有効化されるとき,入力に含まれるアンロッキングスクリプトは,使用条件を満たすかどうかを確認するために,対応するロッキングスクリプトと共に実行されます。もし,スクリプトの実行結果が“TRUE”である,つまり,アンロッキングスクリプトが使用条件を満たすのに成功すれば,そのトランザクションは有効なものです。もし,合体されたスクリプトを実行した後に,その結果が“TRUE”でなければ,そのトランザクションは無効なものです。
2)マイニングメカニズム:マイニングは,ブロックチェーンネットワーク内のいくつかのノードがトランザクションをブロックに集約するプロセスです。これらのノードはブロックチェーンネットワークのマイナーと呼ばれます。マイナーによって新しいブロックが生成される時,マイナーはブロックチェーンネットワークにそのブロックを伝播します。そして,新しいブロックはネットワーク全体が合意に達した後にパブリックブロックチェーンに含まれます。
台帳を更新するために次の編集者としてのマイナーを選ぶ異なるメカニズムがあります。ビットコインでは,マイナーは“Proof-of-work”を通してランダムに選ばれます。“Proof-of-work”は,確認するのは簡単だが生成するにはコストが掛かる一片のデータです。“Proof-of-work”を生成することは低い確率のランダムなプロセスです。従って,ビットコインネットワークのマイナーはCPU時間を消費することを通して“Proof-of-work”を生成する競争をします。“Proof-of-work”を見つけた最初のマイナーは潜在的な次のブロックチェーンの編集者です。この処理の困難さは10分ごとに新しいブロックが生成されるように調節されます。しかしながら,“Proof-of-work”はトランザクションを処理する能力をかなり制限します。)

(2)上記引用文献1の記載(特に下線部の記載)より,上記引用文献1には,次の発明(以下,「引用発明」という。)が記載されていると認められる。
なお,符号a-fは,説明のために当審で付与したものであり,以下「構成a」-「構成f」という。

「a スマートコントラクトを最も重要な要素としてみる,ブロックチェーンベースのプラットフォームとしてのイーサリウムのノードであって,
b トランザクションは,トランザクションを受信したノードによって再実行されることによって有効化され,ここで,トランザクションの有効化は,トランザクションに含まれるスクリプトが実行されることによって行われ,スクリプトの実行結果がTRUEであれば,そのトランザクションは有効なものであり,その結果がTRUEでなければ,そのトランザクションは無効なものであるとされ,
c マイナーと呼ばれる,ブロックチェーンネットワーク内のいくつかのノードが,トランザクションをブロックに集約し,
d マイナーは,ブロックチェーンネットワークにそのブロックを伝播し,
e 新しいブロックは,ネットワーク全体が合意に達した後にパブリックブロックチェーンに含まれ,
f “Proof-of-work”を見つけた最初のマイナーは,台帳を更新する,
a ノード。」

2.引用文献2

(1)原査定の拒絶の理由で引用された引用文献2(特表2006-520936号公報)には,以下の事項が記載されている。

「【0008】
この目的は,ソフトウエア部品(software components)の配送用の方法で達成されるが,該方法は,関連ソフトウエア部品から第1ソフトウエア部品識別子(first software components identifier)を引き出す(deriving)過程と,該ソフトウエア部品の完全性試験(integrity test)を行うことにより完全性試験データを創る過程と,証明書オリジネーター(certificate originator)により該完全性試験データを有する完全性証明書(integrity certificate)を創る過程と,該完全性証明書オリジネーターにより該完全性証明書に該第1ソフトウエア部品識別子をラベル付けする過程と,ユーザーのコンピュータにより該ソフトウエア部品を検索する過程と,ダウンロードされたソフトウエア部品から第2ソフトウエア部品識別子を該ユーザーのコンピュータにより引き出す過程と,該第2ソフトウエア部品識別子を使って該ユーザーのコンピュータにより該完全性証明書を検索する過程と,該ユーザーのコンピュータにより該完全性試験データをユーザーに開示する過程と,を具備する。」

「【0013】
もう1つの側面は証明書レジスターから要求された完全性証明書を検索することである。該証明書レジスターは該ユーザーのクライアントソフトウエア,ブラウザー,イーメールクライアント(e-mail client)他の中に定在してもよい。代替えとして,該要求された完全性証明書は,例えば,証明書オリジネーターの,レジスター(例えば,データベース)から検索可能であってもよい。該完全性証明書はソフトウエア供給者自身から受信されてもよい。該レジスターの場所がどうであろうと,該完全性証明書が常に信頼出来る,偏見のないパーテイ,すなわち信頼される証明書オリジネーター,により発行(issued){オリジネート(originated)}されねばならないことは重要である。そのため完全性証明書は常に該信頼される証明書オリジネーターの1つにより発行されるよう検証されねばならない。その目的で,該ユーザークライアントソフトウエアは信頼され得る1つ以上の証明書オリジネーターの公開鍵(public key){ピーケー(PK)}証明書を有するレジスターを備えてもよい。加えて,信頼される証明書オリジネーターのデジタル署名は(もう1つの)信頼される第3のパーテイにより検証されてもよい。
【0014】
該完全性証明書は該ソフトウエア部品の完全性をさすデータを含み,例えば,ローバストさ,信頼性,健全性,完成度他の様な項目に関するその品質の評価(rating)を含む。好ましくは共通基準(シーシー)が使われるのがよい。」

「【0030】
該完全性証明書は該証明の源を証明するデジタル署名(digital signature)を含んでもよい。例えば,デジタル署名アルゴリズム(Digital Signature Algorithm)[エフアイピーエス186-2,デジタル署名標準(FIPS 186-2, Digital Signature Standard){デーエスエス(DSS)}]を使うことによる該証明書の署名が使われてもよく,それは,つまりは該証明書上のデジタル署名をチェックすることにより,受信するユーザーに該証明書が信頼される完全性証明書オリジネーターにより発行されたかどうかを検出させる。
【0031】
幾つかのソフトウエア部品の完全性証明書を配送出来るようにするために,サーバー4はレジスター,例えば,ソフトウエア試験エイジェンシー(software testing agency)により作られた完全性証明書を含む,例えば,データベース,を保持しなければならない。該ソフトウエア試験エイジェンシーは例えば,ナショナルソフトウエア試験ラボ(National Software Testing Labs){エヌエステーエル(NSTL)}[非特許文献5]又はアイベータソフトウエア品質保証(iBeta Software Quality Assurance)[非特許文献6]又はテーエヌオー(TNO)[非特許文献7]の様な独立エイジェンシーが好ましい。該試験データは該完全性証明書オリジネーターへ送られてもよい。」

「【0037】
ソフトウエア部品配送者(サーバー2)は,例えば,該(上記例参照)INVENT.EXE(自己実行型)ZIPフアイル内に該証明書を含む様に,関連する完全性証明書を含むソフトウエアパッケージ内の彼等のソフトウエア部品を配送するサービスを提供してもよいことを注意しておく。その場合,ユーザーは該フアイルのハッシュ値のみを計算し,該完全性証明書がそのハッシュ値に実際リンクされるかどうかをチェックし,そして信頼される完全性証明書オリジネーターが該証明書を発しているかどうかをチェックすることだけが必要である。」

(2)上記引用文献2の記載(特に下線部の記載)より,上記引用文献2には,次の技術的事項が記載されていると認められる。

「ソフトウエア試験エイジェンシーによって,ソフトウエアの完全性試験を行うことにより完全性試験データを創られ,試験データは完全性証明書オリジネーターへ送られ,証明書オリジネーターによって,完全性証明書は発行され,ユーザーによって,ソフトウエアパッケージに含まれる完全性証明書が,該完全性証明書に含まれるデジタル署名をチェックされることにより,信頼される完全性証明書オリジネーターにより発行されたかどうかを検出される方法であって,該完全性証明書は該ソフトウエアのローバストさ,信頼性,健全性,完成度他の様な項目に関するその品質の評価を含む,方法。」

3.引用文献3

(1)原査定の拒絶の理由で引用された引用文献3(特開2001-216173号公報)には,以下の事項が記載されている。

「【0035】
【発明の実施の形態】図1は,本発明により開示されたアンチ・ウィルス・システムに含まれる,種々のエンティティを示す。ほとんどの場合には,クライアント・ワークステーション(100)が要求するファイルは,ウェブ/ファイル・サーバ(101)に保存される。ウェブ/ファイル・サーバ(101)のディレクトリに保存された証明書は,このファイルと関連する。その証明書は,要求に応じてウィルス・フリー認証局サーバ(102)ににより,提供される。前記要求は,ウェブ/ファイル・サーバ(101)によりインターネットを含むLAN/WAN(ローカル・エリア・ネットワーク/広域ネットワーク)(103)を介して,ウィルス・フリー認証局サーバ(102)へ送られる。クライアント・ワークステーション(100)は,それから,ファイル,及び,ディレクトリの関連した証明を両方ダウンロードし,自身のアンチ・ウィルス・プログラムにファイルをチェックするよう要求する。このチェック処理は,いかなる標準的なアンチ・ウィルス・プログラムも使用しないが,先にダウンロードされた証明に基づいて行われる。ファイルがウィルス・フリーであるか否かを決定するために要求されるのは,証明に含まれる署名の検証だけである。全ての上述した方法は,図2,3,4,5を参照するとよりよく理解される。」

4.引用文献4

(1)原査定の拒絶の理由で引用された引用文献4(特開平11-282672号公報)には,以下の事項が記載されている。

「【0013】【課題を解決するための手段】上記目的を達成するために,本発明のオンラインプログラム転送方法は,まず,プログラムの作成者とは別に,そのプログラムが危険な動作をしないことを検証できる人あるいは組織を用意する。プログラムの配布時に,この検証者によって電子署名を施す。利用者は,転送したプログラムを実行する前に電子署名を確認し,信用できる検証者によって電子署名されているプログラムであった場合は,その実行を許可する。」

5.参考文献1

(1)参考文献1(木下 学,ブロックチェーンEthereum入門 4,2016年6月24日, https://www.intellilink.co.jp/column/fintech/2016/062400.aspx)には,以下の事項が記載されている。

















(2)上記参考文献1の記載(特に下線部の記載)より,上記参考文献1には,次の事項が記載されていると認められる。
なお,符号gは,説明のために当審で付与したものであり,以下「構成g」という。

「g Ethereumにおいて,トランザクションがブロックに記録されると,コントラクトはブロックチェーン上にあるようになり,また,コントラクトを実行した後で,コントラクトを確認すると,値が変わっていること。」

6.参考文献2

(1)参考文献2(志茂 博,Keyword 13 ブロックチェーン 合意アルゴリズム,この1冊でまるごとわかるブロックチェーン&ビットコイン 入門編,2016年12月24日,pp.96-97)には,以下の事項が記載されている。





図1からは,“ビットコインネットワークが複数のビットコイン・ノードから構成される”こと,“マイニングを行うビットコイン・ノードがブロックを他のビットコイン・ノードに送信する”こと,“他のビットコイン・ノードがブロックを受信し,元帳に保存する”ことが読み取れる。

(2)上記参考文献2の記載(特に下線部の記載)より,上記参考文献2には,次の事項が記載されていると認められる。
なお,符号hは,説明のために当審で付与したものであり,以下「構成h」という。

「h ビットコインネットワークが複数のビットコイン・ノードから構成され,マイニングを行うビットコイン・ノードがブロックを他のビットコイン・ノードに送信し,他のビットコイン・ノードがブロックを受信し,元帳に保存すること。」

第4 対比・判断

1.本願発明1について

(1)対比

本願発明1と引用発明とを対比する。

ア.構成Aについて

引用発明の詳細を理解するために引用する参考文献1の構成gによれば,Ethereum(イーサリウム)では,「トランザクションがブロックに記録されると,コントラクトはブロックチェーン上にあるようにな」るから,「ブロック」が「コントラクト」を含む「トランザクション」を含んでいるといえる。
また,構成gによれば,「コントラクトを実行した後で,コントラクトを確認すると,値が変わっている」から,「ブロックに記録」される「トランザクション」は,「コントラクト」の“実行結果”を含んでいることは明らかである。
よって,構成aによれば,引用発明の「ブロック」は,「スマートコントラクトを最も重要な要素としてみる」「イーサリウム」のものであるので,コントラクト,コントラクトへの入力及びコントラクトの実行結果のうち少なくとも1つを含むトランザクションを1つ以上含むものであることは明らかである。

引用発明の詳細を理解するために引用する参考文献2の構成hによれば,ブロックチェーンにおいては,ネットワークが複数のノードから構成され,マイニングを行うノードがブロックを他のノードに送信し,他のノードがブロックを受信し,元帳に保存するので,構成dに記載された,引用発明の「マイナーと呼ばれる」「ノード」が「ブロックチェーンネットワーク」に「ブロックを伝播」することは,「マイナーと呼ばれる」「ノード」がその他の「ノード」に「ブロック」を送信することを意味し,また,その他の「ノード」が当該「ブロック」を受信していることは明らかである。

したがって,引用発明の「ノード」と,本願発明1の「ブロックチェーン管理装置」とは,「コントラクト,コントラクトへの入力及びコントラクトの実行結果のうち少なくとも1つを含むトランザクションを一つ以上含むブロックを受信するブロック受信部」を備えるものである点,で共通している。

イ.構成Bについて

構成bに記載された,引用発明の「ノード」が,「トランザクションに含まれるスクリプト」を「実行」し,「スクリプトの実行結果がTRUEであれば,そのトランザクションは有効なものであり,その結果がTRUEでなければ,そのトランザクションは無効なものである」とすることは,“トランザクションが正当であることを検証する”ことであるといえる。
イーサリウムを含むブロックチェーンにおいて,検証されるトランザクションは,ノードが受信したブロックに含まれるものであることは技術常識であるところ,構成bに記載された,引用発明の「トランザクション」は,「ブロック」に含まれるものであることは明らかである。

したがって,引用発明の「ノード」と,本願発明1の「ブロックチェーン管理装置」とは,「前記ブロックに含まれるトランザクションが正当であることを検証するトランザクション検証部」を備えるものである点,で共通している。

ウ.構成Cについて

構成eによれば,引用発明の「ノード」は,「ネットワーク全体」,つまり,「ネットワーク」に含まれる他の「ノード」と,「ブロック」を「パブリックブロックチェーンに含」むことに対して「合意」を“形成”している。
ここで,「ブロック」を「パブリックブロックチェーンに含」むことは,「ブロック」を“書き込むこと”を意味していることは,明らかである。
したがって,上記「イ.」での検討を踏まえれば,引用発明の「ノード」と,本願発明1の「ブロックチェーン管理装置」とは,「前記ブロックに含まれるトランザクションが前記トランザクション検証部により正当であると検証された場合に,他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行う合意形成部」を備えるものである点,で共通している。

エ.構成Dについて

ブロックがブロックチェーンに含まれることは,ブロックが台帳に格納されることによって行われることは,技術常識であるから,構成eに記載された「合意に達した」「ブロック」を「パブリックブロックチェーンに含ま」せることは,「合意に達した」「ブロック」を「台帳」に“格納”していることであることは明らかである。
したがって,引用発明の「ノード」と,本願発明1の「ブロックチェーン管理装置」とは,「前記合意形成されたブロックを格納する台帳格納部」を備えるものである点,で共通している。

オ.構成Eについて

構成bに記載された,引用発明の「ノード」が,「トランザクションに含まれるスクリプト」を「実行」し,「スクリプトの実行結果がTRUEであれば,そのトランザクションは有効なものであり,その結果がTRUEでなければ,そのトランザクションは無効なものである」とすることにおいて,「スクリプトの実行結果がTRUE」となる時が,“トランザクションがコントラクトの実行結果により構成される場合にトランザクションに含まれるコントラクトの実行結果が対応するコントラクト及びコントラクトの入力に対して正しい”時を含んでいることは,技術常識である。
したがって,引用発明の「ノード」と,本願発明1の「ブロックチェーン管理装置」とは,以下の点(相違点1)で相違するものの,「前記トランザクションがコントラクトの実行結果により構成される場合にトランザクションに含まれるコントラクトの実行結果が対応するコントラクト及びコントラクトの入力に対して正しいことを検証するコントラクト実行結果検証部」を備える「トランザクション検証部」を備える点で共通している。

カ.構成Fについて

上記「ウ.」での検討を踏まえると,引用発明の「ノード」と,本願発明1の「ブロックチェーン管理装置」とは,以下の点(相違点2)で相違するものの,“合意形成部”を備える点で共通している。

キ.構成Gについて

構成aによれば,引用発明の「ノード」は,「ブロックチェーン」のものであり,構成b-fによれば,引用発明1の「ノード」は,「有効化」,「集約」,「伝播」,「編集」等を行っているので,管理するものであるといえる。

したがって,引用発明の「ノード」と,本願発明1とは,「ブロックチェーン管理装置」である点,で共通している。

したがって,上記「ア.」-「キ.」の検討内容を踏まえると,本願発明1と引用発明との間には,次の一致点,相違点があるといえる。

(一致点)
「コントラクト,コントラクトへの入力及びコントラクトの実行結果のうち少なくとも1つを含むトランザクションを一つ以上含むブロックを受信するブロック受信部と,
前記ブロックに含まれるトランザクションが正当であることを検証するトランザクション検証部と,
前記ブロックに含まれるトランザクションが前記トランザクション検証部により正当であると検証された場合に,他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行う合意形成部と,
前記合意形成されたブロックを格納する台帳格納部と,
を備え
前記トランザクション検証部は,
前記トランザクションがコントラクトの実行結果により構成される場合にトランザクションに含まれるコントラクトの実行結果が対応するコントラクト及びコントラクトの入力に対して正しいことを検証するコントラクト実行結果検証部
を備える,
ブロックチェーン管理装置。」

(相違点)

(相違点1)
本願発明1の「ブロックチェーン管理装置」は,「コントラクトの安全性を保証する保証者の公開鍵を少なくとも一つ格納する保証者情報格納部と,前記トランザクションがコントラクトにより構成される場合にトランザクションに含まれる署名を前記保証者情報格納部に格納された保証者の公開鍵で検証するコントラクト署名検証部と,を備え」るものであるのに対して,引用発明の「ノード」は,そのようなものでない点。

(相違点2)
本願発明1の「合意形成部」は,「前記受信したブロックから所定のルールで算出されるハッシュ値と,システムに与えられる又は前記台帳格納部に格納された複数のブロックから算出される目標値と,を比較し,比較結果が事前に定められた条件を満たす場合に他のブロックチェーン管理装置と合意形成ができたと判断する」ものであるのに対して,引用発明は,そのようなものであるのかが明らかでない点。

(2)相違点についての判断

相違点1について検討する。

引用文献2の技術的事項の「ソフトウエア試験エイジェンシー」及び「証明書オリジネーター」は,本願発明1の「コントラクトの安全性を保証する保証者」に相当する。
また,引用文献2の技術的事項の「ソフトウェアパッケージに含まれる完全性証明書」「に含まれるデジタル署名をチェックされること」は,本願発明1の「トランザクションに含まれる署名を」「検証する」ことに相当する。
また,署名の検証に用いる公開鍵を格納すること,及び,署名を格納された公開鍵で検証することは,周知技術である。
しかしながら,引用文献1には,「個々の利用者がコントラクトの検証を行わなくともスマートコントラクトを安全に利用可能にする」という課題についての記載がなく,また,引用文献2には,スマートコントラクトについての記載がないので,引用発明に引用文献2に記載の技術的事項を組み合わせる動機がない。
また,仮に,引用発明に引用文献2に記載の技術的事項を組み合わせたとしても,「トランザクション」「に含まれるデジタル署名」の「チェック」は,「伝播し」た「ブロック」の「トランザクション」に対してなされるものとはならない。

引用文献3,4に記載の技術的事項についても,引用文献2に記載の技術的事項と同様に判断される。

したがって,他の相違点について判断するまでもなく,本願発明1は,当業者であっても,引用発明,引用文献2ないし引用文献4に記載の技術的事項,及び,参考文献1,2の記載に基づいて容易に発明できたものであるとはいえない。

2.本願発明2-4について

本願発明2-4は,本願発明1をさらに減縮した発明であり,本願発明1の上記相違点1に係る構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2ないし引用文献4に記載の技術的事項,及び,参考文献1,2の記載に基づいて容易に発明できたものとはいえない。

3.本願発明5について

本願発明5は,本願発明1に対応する方法の発明であり,本願発明1とカテゴリ表現が異なるだけの発明であるから,本願発明1と同様の理由により,当業者であっても,引用発明,引用文献2ないし引用文献4に記載の技術的事項,及び,参考文献1,2の記載に基づいて容易に発明できたものとはいえない。

4.本願発明6-7について

本願発明6-7は,本願発明5をさらに減縮した発明であり,上記相違点1に係る構成を備えるものであるから,本願発明5と同じ理由により,当業者であっても,引用発明,引用文献2ないし引用文献4に記載の技術的事項,及び,参考文献1,2の記載に基づいて容易に発明できたものとはいえない。

5.本願発明8について

本願発明8は,本願発明1に対応するプログラムの発明であり,本願発明1とカテゴリ表現が異なるだけの発明であるから,本願発明1と同様の理由により,当業者であっても,引用発明,引用文献2ないし引用文献4に記載の技術的事項,及び,参考文献1,2の記載に基づいて容易に発明できたものとはいえない。

第5 原査定の概要及び原査定についての判断

原査定は,請求項1-10について,上記引用文献1-4に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により,特許を受けることができないというものである。
しかしながら,令和3年5月27日付けの補正により,本願発明1-8は上記第3に示したとおりのものとなっているところ,上記第6で検討したとおり,本願発明1-8について,拒絶査定において引用された引用文献1-4に基づいて,当業者が容易に発明できたものとはいえない。
したがって,原査定の理由を維持することはできない。

第6 当審拒絶理由について

1.特許法第36条第6項第2号について

当審では,「請求項1には,『前記ブロックに含まれるトランザクションが正当であることを検証するトランザクション検証部と、前記ブロックに含まれるトランザクションが前記トランザクション検証部により正当であると検証された場合に、他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行う合意形成部と、』と記載されている一方,『前記合意形成部は、前記受信したブロックから所定のルールで算出されるハッシュ値と、システムに与えられる又は前記台帳格納部に格納された複数のブロックから算出される目標値と、を比較し、比較結果が事前に定められた条件を満たす場合に他のブロックチェーン管理装置と合意形成ができたと判断し、前記トランザクション検証部は、コントラクトの安全性を保証する保証者の公開鍵を少なくとも一つ格納する保証者情報格納部と、前記トランザクションがコントラクトにより構成される場合にトランザクションに含まれる署名を前記保証者情報格納部に格納された保証者の公開鍵で検証するコントラクト署名検証部と、前記トランザクションがコントラクトの実行結果により構成される場合にトランザクションに含まれるコントラクトの実行結果が対応するコントラクト及びコントラクトの入力に対して正しいことを検証するコントラクト実行結果検証部と、を備える』と記載され,両記載において,『トランザクション検証部』と『合意形成部』が記載される順序が一致していないため,日本語として不明確である。」との拒絶の理由を通知したが,令和3年5月27日付けの補正において,「前記合意形成部」が「前記受信したブロックから所定のルールで算出されるハッシュ値と,システムに与えられる又は前記台帳格納部に格納された複数のブロックから算出される目標値と,を比較し,比較結果が事前に定められた条件を満たす場合に他のブロックチェーン管理装置と合意形成ができたと判断」することが,「前記トランザクション検証部」が「コントラクトの安全性を保証する保証者の公開鍵を少なくとも一つ格納する保証者情報格納部と,前記トランザクションがコントラクトにより構成される場合にトランザクションに含まれる署名を前記保証者情報格納部に格納された保証者の公開鍵で検証するコントラクト署名検証部と,前記トランザクションがコントラクトの実行結果により構成される場合にトランザクションに含まれるコントラクトの実行結果が対応するコントラクト及びコントラクトの入力に対して正しいことを検証するコントラクト実行結果検証部と,を備える」ことよりも,後に記載されるように補正された結果,この拒絶理由は解消した。

第7 むすび

以上のとおり,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2021-07-16 
出願番号 特願2019-502407(P2019-502407)
審決分類 P 1 8・ 121- WY (H04L)
P 1 8・ 537- WY (H04L)
最終処分 成立  
前審関与審査官 中里 裕正  
特許庁審判長 石井 茂和
特許庁審判官 須田 勝巳
塚田 肇
発明の名称 ブロックチェーン管理装置、ブロックチェーン管理方法及びプログラム  
代理人 内田 潔人  
代理人 加藤 朝道  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ