2020-012543

第２ 令和２年９月８日にされた手続補正についての補正の却下の決定

［補正の却下の決定の結論］

令和２年９月８日にされた手続補正（以下，「本件補正」という。）を却下する。

［理由］

１ 本件補正について（補正の内容）

（１）本件補正後の特許請求の範囲の記載

本件補正により，特許請求の範囲の請求項の記載は，次のとおり補正された。（下線部は，補正箇所である。以下，この特許請求の範囲に記載された請求項を「補正後の請求項」という。）

「 【請求項１】

管理主体が存在しないパブリック型ネットワークにおいて台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスであって、設定されるプロセス多重度に応じた複数のプロセスを生成する生成部と、

トランザクションの指示を受け付け、前記複数のプロセスのいずれかに当該トランザクションのリクエスト送信を割り当てる割当部と、を備えるシステム。

【請求項２】

続きを表示（全23行）

前記複数のプロセスは、第１プロセスおよび第２プロセスを含み、

前記第１プロセスが前記リクエストを送信するノードは、前記第２プロセスが前記リクエストを送信するノードと同一である、請求項１に記載のシステム。

【請求項３】

前記割当部は、ラウンドロビン方式により前記トランザクションのリクエスト送信を割り当てる、請求項１または請求項２に記載のシステム。

【請求項４】

前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットと前記プロセス多重度との関係において、当該プロセス多重度の増加に対する平均スループットの増加の割合が、プロセス多重度が第１値のときに第１割合であり、当該第１値より大きい第２値以上であるときに前記第１割合より小さい第２割合であり、

前記複数のプロセスの数は、前記第２値よりも小さい数で設定される、請求項１から請求項３のいずれかに記載のシステム。

【請求項５】

コンピュータが実行する処理方法であって、

トランザクションの指示を受け付け、

管理主体が存在しないパブリック型ネットワークにおいて台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスであって、設定されるプロセス多重度に応じた複数のプロセスのいずれかに、前記指示に基づくトランザクションのリクエスト送信を割り当てる、処理方法。

【請求項６】

前記複数のプロセスは、第１プロセスおよび第２プロセスを含み、

前記第１プロセスが前記リクエストを送信するノードは、前記第２プロセスが前記リクエストを送信するノードと同一である、請求項５に記載の処理方法。

【請求項７】

前記トランザクションのリクエスト送信を割り当てるときには、ラウンドロビン方式を用いる、請求項５または請求項６に記載の処理方法。

【請求項８】

前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットと前記プロセス多重度との関係において、当該プロセス多重度の増加に対する平均スループットの増加の割合が、プロセス多重度が第１値のときに第１割合であり、当該第１値より大きい第２値以上であるときに前記第１割合より小さい第２割合であり、

前記複数のプロセスの数は、前記第２値よりも小さい数で設定される、請求項５から請求項７のいずれかに記載の処理方法。」

（２）本件補正前の特許請求の範囲

本件補正前の，令和２年１月６日にされた手続補正により補正された特許請求の範囲の請求項の記載は次のとおりである。（以下，この特許請求の範囲に記載された請求項を「補正前の請求項」という。）

「 【請求項１】

台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスを生成する生成部と、

トランザクションの指示を受け付け、前記複数のプロセスのいずれかに当該トランザクションのリクエスト送信を割り当てる割当部と、を備えるシステム。

【請求項２】

続きを表示（全27行）

前記複数のプロセスは、第１プロセスおよび第２プロセスを含み、

前記第１プロセスが前記リクエストを送信するノードは、前記第２プロセスが前記リクエストを送信するノードと同一である、請求項１に記載のシステム。

【請求項３】

前記割当部は、ラウンドロビン方式により前記トランザクションのリクエスト送信を割り当てる、請求項１または請求項２に記載のシステム。

【請求項４】

前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットとプロセス多重度との関係において、プロセス多重度の増加に対する平均スループットの増加の割合が、プロセス多重度が第１値のときに第１割合であり、当該第１値より大きい第２値以上であるときに前記第１割合より小さい第２割合であり、

前記複数のプロセスの数は、前記第２値よりも小さい数で設定される、請求項１から請求項３のいずれかに記載のシステム。

【請求項５】

前記複数のノードで形成されるネットワークは、コンソーシアム型である、請求項１から請求項４のいずれかに記載のシステム。

【請求項６】

コンピュータが実行する処理方法であって、

トランザクションの指示を受け付け、

台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスのいずれかに、前記指示に基づくトランザクションのリクエスト送信を割り当てる、処理方法。

【請求項７】

前記複数のプロセスは、第１プロセスおよび第２プロセスを含み、

前記第１プロセスが前記リクエストを送信するノードは、前記第２プロセスが前記リクエストを送信するノードと同一である、請求項６に記載の処理方法。

【請求項８】

前記トランザクションのリクエスト送信を割り当てるときには、ラウンドロビン方式を用いる、請求項６または請求項７に記載の処理方法。

【請求項９】

前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットとプロセス多重度との関係において、プロセス多重度の増加に対する平均スループットの増加の割合が、プロセス多重度が第１値のときに第１割合であり、当該第１値より大きい第２値以上であるときに前記第１割合より小さい第２割合であり、

前記複数のプロセスの数は、前記第２値よりも小さい数で設定される、請求項６から請求項８のいずれかに記載の処理方法。

【請求項１０】

前記複数のノードで形成されるネットワークは、コンソーシアム型である、請求項６から請求項９のいずれかに記載の処理方法。」

２ 補正の適否

本件補正は，補正前の請求項５及び請求項１０を削除するとともに，補正前の請求項１及び請求項６に記載された発明を特定するために必要な事項である，「台帳を分散して記録する複数のノード」について，「管理主体が存在しないパブリック型ネットワークにおいて」との限定を付加し，同じく補正前の請求項１及び請求項６に記載された発明を特定するために必要な事項である，「複数のプロセス」について，「設定される多重度に応じた」との限定を付加して，それぞれ補正後の請求項１及び請求項５としたものである。

そして，補正前の請求項１及び請求項６に記載された発明と，補正後の請求項１及び請求項５に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから，本件補正は，特許法第１７条の２第５項２号の特許請求の範囲の減縮を目的とするものに該当する。

そこで，本件補正後の請求項１に記載される発明（以下「本件補正発明」という。）が同条第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について，以下，検討する。

（１）本件補正発明

本件補正発明は，上記「１（１）」に記載された下記のとおりのものである（再掲）。

「 管理主体が存在しないパブリック型ネットワークにおいて台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスであって、設定されるプロセス多重度に応じた複数のプロセスを生成する生成部と、

トランザクションの指示を受け付け、前記複数のプロセスのいずれかに当該トランザクションのリクエスト送信を割り当てる割当部と、を備えるシステム。」

（３）対比

ア 本件補正発明と引用発明とを対比する。

（ア）引用発明の「ブロックチェーン（Blockchain, BC）基盤のOSSプロジェクトであるHyperledgerの基盤実装の一つであるFabric」は，ブロックチェーン基盤実装の一つであるところ，ブロックチェーンは，分散型台帳技術の一つであり，ネットワークにおいて台帳を分散して記録する複数のノードを備えるものであるから，引用発明の，ブロックチェーン基盤実装である前記「Fabric」も，ネットワークにおいて台帳を分散して記録する複数のノードを備えるものであることは明らかである。

そして，引用発明は，「クライアントからREST経由でBCネットワークにアクセスし，チェーンコードを実行して負荷をかけることで性能測定を行うものであり，負荷をかける際には，複数のクライアントからの同時アクセスを模擬するため，マルチスレッドでトランザクションを並列実行する」ものであって，「ある程度並列度を増やすとスループットは頭打ちとなり，スループットが頭打ちになった後も，それ以上に並列度を増やしていくと，挙動が安定しなくなる場合があるため，フロント側でリクエストの流量制御を行う等の対策が必要となり得る」ものである。

すなわち，引用発明は，「クライアントから」「BCネットワークにアクセスし」て，負荷をかけるために「マルチスレッドでトランザクションを並列実行する」ものであって，さらに，スループットが頭打ちになった後も，それ以上に並列度を増やしていくと，挙動が安定しなくなる場合があるため，「フロント側でリクエストの流量制御を行う」等の対策が必要となり得るものである。

してみると，引用発明において，クライアントからBCネットワークにアクセスして「マルチスレッドでトランザクションを並列実行する」際には，フロント側であるクライアントから，当該トランザクションを並列実行するためのトランザクションのリクエストを，BCネットワーク，すなわち，ブロックチェーンに対して送信していることは明らかであり，これはブロックチェーンを構成する複数のノードの少なくとも一つに対して，前記リクエストを送信することに他ならない。ここで，「マルチスレッド」とは，CPU利用の処理単位であるスレッドを複数生成して並列実行する技術であるから，「マルチスレッドでトランザクションを並列実行する」際には，複数の処理単位を生成し，生成した複数の処理単位を，前述したように，トランザクションを並列実行するためのリクエストとしてブロックチェーンを構成する複数のノードの少なくとも一つに送信することは明らかであり，引用発明は，トランザクションのリクエストを送信する複数の処理単位を生成するための生成部を実質的に備えているといえる。

以上の検討を踏まえると，本件補正発明と引用発明とは，“ネットワークにおいて台帳を分散して記録する複数のノードの少なくとも１つに対し，トランザクションのリクエストを送信する複数の処理単位であって，複数の処理単位を生成する生成部”を備える点で一致している。

（イ）上記（ア）で検討したように，引用発明において，「マルチスレッドでトランザクションを並列実行する」際には，当該トランザクションを並列実行するためのトランザクションのリクエストを，ブロックチェーンのノードの少なくとも一つに対して送信していることは明らかなところ，かかる送信を行うためには，前記マルチスレッドに前記トランザクションのリクエスト送信を割り当てて送信していることも明らかであり，引用発明は，マルチスレッドのいずれかにトランザクションのリクエスト送信を割り当てる割当部を実質的に備えているといえる。

よって，上記（ア）の検討も踏まえると，本件補正発明と引用発明とは，“複数の処理単位のいずれかにトランザクションのリクエスト送信を割り当てる割当部”を備える点で一致している。

（ウ）引用発明は，「クライアントによる負荷生成ツールプログラムの処理の流れは，スレッド毎に実行トランザクション(invoke)を指定した回数繰り返す（並列実行）こと含む」ものであるから，前記「クライアントによる負荷生成ツールプログラム」が負荷を生成することによって「BC基盤 Hyperledger Fabricの性能評価」を行うものである。

そして，「クライアントによる負荷生成ツールプログラム」は，クライアントで実行されるプログラムであるから，かかるプログラムが実行される「クライアント」が，上記（ア）及び（イ）で検討した“生成部”，“割当部”を実質的に備える“システム”であるといえる。

イ 上記（ア）～（ウ）の検討から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。

＜一致点＞

「 ネットワークにおいて台帳を分散して記録する複数のノードの少なくとも１つに対し，トランザクションのリクエストを送信する複数の処理単位であって，複数の処理単位を生成する生成部と，

前記複数の処理単位のいずれかに当該トランザクションのリクエスト送信を割り当てる割当部と，を備えるシステム。」

＜相違点１＞

本件補正発明は，「管理主体が存在しないパブリック型」ネットワークであるのに対して，引用発明の，ブロックチェーン基盤実装の一つである「Fabric」は，「コンソーシアムあるいはプライベート型での利用を想定したBC基盤」である点。

＜相違点２＞

本件補正発明は，処理単位が「プロセス」であって，生成部が複数の「プロセス」を生成し，割当部が前記複数の「プロセス」のいずれかにトランザクションのリクエスト送信を割り当てるものであるのに対して，引用発明は，処理単位が「スレッド」である点。

＜相違点３＞

本件補正発明は，生成部が「設定されるプロセス多重度に応じた」複数のプロセスを生成するものであるのに対して，引用発明は，そのような特定がなされていない点。

＜相違点４＞

本件補正発明は，割当部が「トランザクションの指示を受け付け」，複数のプロセスのいずれかにトランザクションのリクエスト送信を割り当てるのに対して，引用発明は，そのような特定がなされていない点。

（４）当審の判断

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

ア ＜相違点１＞について

ブロックチェーンネットワークには，「コンソーシアムあるいはプライベート型」の他に，「管理主体が存在しないパブリック型」があることは，本願出願時おける技術常識であるところ，引用発明の，マルチスレッドでトランザクションを並列実行するブロックチェーン基盤が，「コンソーシアムあるいはプライベート型」のブロックチェーンにのみ適用可能であって，「管理主体が存在しないパブリック型」のブロックチェーンには適用できないとする技術的根拠は何ら認められない。

また，本件補正発明が「管理主体が存在しないパブリック型」のネットワークである点に関して，本願明細書には，【００２６】に，

「ブロックチェーンネットワーク５においては、上述のように台帳を分散して各ノード５１０で記録する方式が用いられているが、その過程における具体的な処理は、仕様（基盤ソフトウェア：上述したＣＰＵによって実行されるプログラムに対応）によって様々であって、公知の処理が適用されればよい。したがって、ブロックチェーンネットワーク５における各ノード５１０の処理の詳細は説明を省略する。この例では、ブロックチェーンネットワークは、管理主体が存在するコンソーシアム型（例えば、Ｑｕｏｒｕｍ、Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃ等）を想定しているが、管理主体が存在しないパブリック型（例えば、Ｅｔｈｅｒｅｕｍ等）であっても適用可能である。」（当審注：下線は，参考のために当審で付与したものである。）

と記載されているのみである。

本願明細書の上記記載によれば，本願明細書に記載された実施形態は，「管理主体が存在するコンソーシアム型」を「想定している」ところ，「管理主体が存在しないパブリック型」にも「適用可能」であるとしているものにすぎず，本件補正発明において，ネットワークが「管理主体が存在しないパブリック型」であることに，なんら格別の技術的特徴を認めることはできない。

してみると，引用発明は，「コンソーシアムあるいはプライベート型での利用を想定」しているとはいえ，前述したように，引用発明を「管理主体が存在しないパブリック型」のブロックチェーンには適用できないとする技術的根拠は何ら認められないところ，引用発明を「管理主体が存在しないパブリック型」のネットワークに適用することにも何ら技術的創意は見出せず，当業者であれば適宜実施し得る事項に過ぎないといえる。

イ ＜相違点２＞について

情報処理の技術分野において，並列処理をマルチスレッドやマルチプロセスで実行することは，引用文献２～３に示されるように周知技術である。

してみると，引用発明は，「マルチスレッドでトランザクションを並列実行」しているところ，かかる並列処理を実行する手段として，マルチスレッドに換えて，同じく並列処理の周知技術である「マルチプロセス」を採用することは，当業者が通常の創作活動の範囲内において適宜なし得る事項に過ぎないと認められる。

よって，引用発明において，マルチプロセスを採用して処理単位を「プロセス」とすることは，上記周知技術に基づいて当業者が適宜なし得るものであり，さらに，参考文献に示されるように，プログラムを実行する単位である複数のプロセスを生成し，クライアント端末から受け取ったリクエストを，前記複数のプロセスのうちの何れかのプロセスに割り当てることが，複数のプロセスを用いたプログラム実行における極めて一般的な処理であることも踏まえれば，引用発明にマルチプロセスを採用した際に，生成部が複数の「プロセス」を生成し，割当部が前記複数の「プロセス」のいずれかにトランザクションのリクエスト送信を割り当てるとすることも，当業者であれば当然になし得るものと認められる。

ウ ＜相違点３＞について

引用発明では，「スループットが頭打ちになった後も，それ以上に並列度を増やしていくと，挙動が安定しなくなる場合があるため，フロント側でリクエストの流量制御を行う等の対策が必要となり得る」としており，これはフロント側でリクエスト送信を割り当てるスレッドの数を制限することを示唆するものであって，スレッドの多重度を制限することを示唆するものである。

そして，上記イで検討したとおり，引用発明において，マルチスレッドに換えて「マルチプロセス」を採用することは，当業者であれば適宜なし得る事項に過ぎないと認められるところ，かかるマルチプロセスを採用した場合に，プロセスの多重度を制限するため「プロセスの多重度に応じた」複数のプロセスを生成することは，リクエスト送信を割り当てるスレッドの数を制限するという上記示唆に基づいて，当業者であれば容易に想到し得るものである。

よって，上記イの検討も踏まえると，引用発明において，生成部が「設定されるプロセスの多重度に応じた」複数のプロセスを生成することは，引用文献２～３に記載の上記周知技術，及び引用発明の上記示唆に基づいて，当業者であれば容易になし得るものである。

エ ＜相違点４＞について

引用発明は，「BC基盤 Hyperledger Fabricの性能評価」を行うものであって，「クライアントからREST経由でBCネットワークにアクセスし，チェーンコードを実行して負荷をかけることで性能測定を行うものであり，負荷をかける際には，複数のクライアントからの同時アクセスを模擬するため，マルチスレッドでトランザクションを並列実行する」ものである。

してみると，このように「複数のクライアントからの同時アクセスを模擬するため，マルチスレッドでトランザクションを並列実行する」ことで性能評価がなされた「BC基盤 Hyperledger Fabric」は，かかる性能評価が行われた後，実際のトランザクション処理を実行する際には，クライアントから，実際の「トランザクションの指示を受け付け」て実行するとすることは，当業者であれば当然に行い得るものである。

そして，上記イで検討したように，引用発明において，マルチプロセスを採用することは当業者が適宜なし得る事項と認められるところ，引用発明の「BC基盤 Hyperledger Fabric」を実際のトランザクション処理に用いる場合，「トランザクションの指示を受け付け」て，複数のプロセスのいずれかにトランザクションのリクエスト送信を割り当てることも，当業者であれば当然になし得るものである。

オ 小括

上記ア～エで検討したとおり，＜相違点１＞～＜相違点４＞に係る構成は，引用発明，及び引用文献２～３に記載の周知技術に基づいて，当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，引用発明，及び引用文献２～３に記載の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。

したがって，本件補正発明は，引用発明，及び引用文献２～３に記載の周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。

３ 本件補正についてのむすび

本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。

よって，上記補正の却下の決定の結論のとおり決定する。

第３ 本願発明について

１ 本願発明の認定

令和２年９月８日にされた手続補正は，上記のとおり却下されたので，本願の請求項に係る発明は，令和２年１月６日にされた手続補正により補正された特許請求の範囲の請求項１～１０に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下，「本願発明」という。）は，その請求項１に記載された事項により特定される，上記「第２[理由]１（２）」に記載された下記のとおりのものである（再掲）。

「 台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスを生成する生成部と、

トランザクションの指示を受け付け、前記複数のプロセスのいずれかに当該トランザクションのリクエスト送信を割り当てる割当部と、を備えるシステム。」

２ 原査定の拒絶の理由

原査定の拒絶の理由は，本願発明は，本願の出願日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献Ａ～引用文献Ｃ（それぞれ，上記「引用文献１」～「引用文献３」に対応）に記載された技術に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。

引用文献Ａ．佐藤 竜也，ブロックチェーン基盤Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃの性能評価と課題整理，電子情報通信学会技術研究報告，一般社団法人電子情報通信学会，２０１７年 ２月２４日，第１１６巻，第４９１号，ｐ．１６７－１７４

引用文献Ｂ．特開２０１９－０１４１３５号公報（周知技術を示す文献）

引用文献Ｃ．特開２０１０－２７８６３９号公報（周知技術を示す文献）

３ 引用文献

原査定の拒絶の理由に引用された，引用文献Ａ～引用文献Ｃ，及びその記載事項は，上記「第２[理由]２（２）（２－１）～（２－３）」に記載したとおりである。

４ 対比・判断

（１）本願発明は，上記「第２[理由]２（１）」で検討した本件補正発明の，「台帳を分散して記録する複数のノード」について，「管理主体が存在しないパブリック型ネットワークにおいて」との限定を削除するとともに，本件補正発明の「複数のプロセス」について，「設定される多重度に応じた」との限定を削除したものである。

（２）そうすると，上記「第２[理由]２（３）」における検討内容を踏まえると，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。

＜一致点＞

「 台帳を分散して記録する複数のノードの少なくとも１つに対し，トランザクションのリクエストを送信する複数の処理単位を生成する生成部と，

前記複数の処理単位のいずれかに当該トランザクションのリクエスト送信を割り当てる割当部と，を備えるシステム。」

＜相違点ａ＞

本願発明は，処理単位が「プロセス」であって，生成部が複数の「プロセス」を生成し，割当部が前記複数の「プロセス」のいずれかにトランザクションのリクエスト送信を割り当てるものであるのに対して，引用発明は，処理単位が「スレッド」である点。

＜相違点ｂ＞

本願発明は，割当部が「トランザクションの指示を受け付け」，複数のプロセスのいずれかにトランザクションのリクエスト送信を割り当てるのに対して，引用発明は，そのような特定がなされていない点。

（３）そして，上記＜相違点ａ＞及び＜相違点ｂ＞は，それぞれ上記「第２[理由]２（３）」における＜相違点２＞及び＜相違点４＞と同じであることから，上記「第２[理由]２（４）」で検討したように，上記＜相違点ａ＞及び＜相違点ｂ＞は，いずれも格別のものではなく，本願発明は，上記引用発明，及び上記引用文献２～３に記載の周知技術に基づいて，当業者が容易に発明をすることができたものである。

第４ むすび

以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。

よって，結論のとおり審決する。