運営：アスタミューゼ株式会社
パナソニックで一緒に知財の仕事しませんか？
  • ポートフォリオ機能


追加

関連審決 不服2020-12543
元本PDF 裁判所収録の全文PDFを見る pdf
元本PDF 裁判所収録の別紙1PDFを見る pdf
元本PDF 裁判所収録の別紙2PDFを見る pdf
元本PDF 裁判所収録の別紙3PDFを見る pdf
事件 令和 3年 (行ケ) 10060号 審決取消請求事件
5
原告 株式会社三菱ＵＦＪ銀行
同訴訟代理人弁護士 高橋雄一郎
同 阿部実佑季 10 同訴訟代理人弁理士 林佳輔
同 荒尾達也
被告特許庁長官
同指定代理人 須田勝巳 15 同田中秀人
同 梶尾誠哉
同 金子秀彦
裁判所 知的財産高等裁判所
判決言渡日 2021/12/20
権利種別 特許権
訴訟類型 行政訴訟
主文 １ 原告の請求を棄却する。
20 ２ 訴訟費用は原告の負担とする。
事実及び理由
請求
特許庁が不服2020-12543号事件について令和3年3月19日に した審決を取り消す。
25 第2 事案の概要 本件は,特許拒絶査定の不服審判請求を不成立とした審決の取消訴訟である。
1 1 特許庁における手続の経緯等(当事者間に争いがない。) ? 原告は,令和元年7月9日,名称を「システムおよび処理方法」とする発 明について,特許出願(特願2019-127894号。以下「本件出願」 という。)をしたが,令和2年6月22日付けの拒絶査定を受けた。
5 ? 原告は,令和2年9月8日,同日付け手続補正書を提出するとともに(以 下,この手続補正書による補正を「本件補正」という。 ,拒絶査定不服審判 ) を請求した。
特許庁は,上記請求を不服2020-12543号事件として審理を行い, 令和3年3月19日,本件補正を却下した上で, 「本件審判の請求は,成り立10 たない。」との審決(以下「本件審決」という。)をし,その謄本は,同年4 月6日,原告に送達された ? 原告は,令和3年4月28日,本件審決の取消しを求める本件訴訟を提起 した。
2 特許請求の範囲の記載15 本件補正前の特許請求の範囲の記載は,請求項1ないし10からなり,その 請求項の記載は下記?のとおりであり(以下,請求項1に係る発明を「本願発 明」という。 ,本件補正後の特許請求の範囲の記載は,請求項1ないし8から ) なり(特許請求の範囲は全文変更) その請求項の記載は下記?のとおりである , (以下,本件補正後の請求項1に係る発明を「本件補正発明」という。下線部20 は,本件補正による補正箇所である。 。
) ? 本件補正前の特許請求の範囲の記載 ア 請求項1(本願発明) 台帳を分散して記録する複数のノードの少なくとも1つに対し,トラン ザクションのリクエストを送信する複数のプロセスを生成する生成部と,25 トランザクションの指示を受け付け,前記複数のプロセスのいずれかに 当該トランザクションのリクエスト送信を割り当てる割当部と,を備える 2 システム。
イ 請求項2 前記複数のプロセスは,第1プロセスおよび第2プロセスを含み, 前記第1プロセスが前記リクエストを送信するノードは,前記第2プロ 5 セスが前記リクエストを送信するノードと同一である,請求項1に記載の システム。
ウ 請求項3 前記割当部は,ラウンドロビン方式により前記トランザクションのリク エスト送信を割り当てる,請求項1または請求項2に記載のシステム。
10 エ 請求項4 前記複数のノードで形成されるネットワークにおける所定のトランザク ションのリクエストに対する平均スループットとプロセス多重度との関 係において,プロセス多重度の増加に対する平均スループットの増加の割 合が,プロセス多重度が第1値のときに第1割合であり,当該第1値より15 大きい第2値以上であるときに前記第1割合より小さい第2割合であり, 前記複数のプロセスの数は,前記第2値よりも小さい数で設定される, 請求項1から請求項3のいずれかに記載のシステム。
オ 請求項5 前記複数のノードで形成されるネットワークは,コンソーシアム型であ20 る,請求項1から請求項4のいずれかに記載のシステム。
カ 請求項6 コンピュータが実行する処理方法であって, トランザクションの指示を受け付け, 台帳を分散して記録する複数のノードの少なくとも1つに対し,トラン25 ザクションのリクエストを送信する複数のプロセスのいずれかに,前記指 示に基づくトランザクションのリクエスト送信を割り当てる,処理方法。
3 キ 請求項7 前記複数のプロセスは,第1プロセスおよび第2プロセスを含み, 前記第1プロセスが前記リクエストを送信するノードは,前記第2プロ セスが前記リクエストを送信するノードと同一である,請求項6に記載の 5 処理方法。
ク 請求項8 前記トランザクションのリクエスト送信を割り当てるときには,ラウン ドロビン方式を用いる,請求項6または請求項7に記載の処理方法。
ケ 請求項910 前記複数のノードで形成されるネットワークにおける所定のトランザク ションのリクエストに対する平均スループットとプロセス多重度との関 係において,プロセス多重度の増加に対する平均スループットの増加の割 合が,プロセス多重度が第1値のときに第1割合であり,当該第1値より 大きい第2値以上であるときに前記第1割合より小さい第2割合であり,15 前記複数のプロセスの数は,前記第2値よりも小さい数で設定される, 請求項6から請求項8のいずれかに記載の処理方法。
コ 請求項10 前記複数のノードで形成されるネットワークは,コンソーシアム型であ る,請求項6から請求項9のいずれかに記載の処理方法。
20 ? 本件補正後の特許請求の範囲の記載 ア 請求項1(本件補正発明) 管理主体が存在しないパブリック型ネットワークにおいて台帳を分散して 記録する複数のノードの少なくとも1つに対し,トランザクションのリクエ ストを送信する複数のプロセスであって,設定されるプロセス多重度に応じ25 た複数のプロセスを生成する生成部と, トランザクションの指示を受け付け,前記複数のプロセスのいずれかに当 4 該トランザクションのリクエスト送信を割り当てる割当部と,を備えるシス テム。
イ 請求項2 前記複数のプロセスは,第1プロセスおよび第2プロセスを含み, 5 前記第1プロセスが前記リクエストを送信するノードは,前記第2プロ セスが前記リクエストを送信するノードと同一である,請求項1に記載の システム。
ウ 請求項3 前記割当部は,ラウンドロビン方式により前記トランザクションのリク10 エスト送信を割り当てる,請求項1または請求項2に記載のシステム。
エ 請求項4 前記複数のノードで形成されるネットワークにおける所定のトランザク ションのリクエストに対する平均スループットと前記プロセス多重度と の関係において,当該プロセス多重度の増加に対する平均スループットの15 増加の割合が,プロセス多重度が第1値のときに第1割合であり,当該第 1値より大きい第2値以上であるときに前記第1割合より小さい第2割 合であり, 前記複数のプロセスの数は,前記第2値よりも小さい数で設定される, 請求項1から請求項3のいずれかに記載のシステム。
20 オ 請求項5 コンピュータが実行する処理方法であって, トランザクションの指示を受け付け, 管理主体が存在しないパブリック型ネットワークにおいて台帳を分散し て記録する複数のノードの少なくとも1つに対し,トランザクションのリ25 クエストを送信する複数のプロセスであって,設定されるプロセス多重度 に応じた複数のプロセスのいずれかに,前記指示に基づくトランザクショ 5 ンのリクエスト送信を割り当てる,処理方法。
カ 請求項6 前記複数のプロセスは,第1プロセスおよび第2プロセスを含み, 前記第1プロセスが前記リクエストを送信するノードは,前記第2プロ 5 セスが前記リクエストを送信するノードと同一である,請求項5に記載の 処理方法。
キ 請求項7 前記トランザクションのリクエスト送信を割り当てるときには,ラウン ドロビン方式を用いる,請求項5または請求項6に記載の処理方法。
10 ク 請求項8 前記複数のノードで形成されるネットワークにおける所定のトランザク ションのリクエストに対する平均スループットと前記プロセス多重度と の関係において,当該プロセス多重度の増加に対する平均スループットの 増加の割合が,プロセス多重度が第1値のときに第1割合であり,当該第15 1値より大きい第2値以上であるときに前記第1割合より小さい第2割 合であり, 前記複数のプロセスの数は,前記第2値よりも小さい数で設定される, 請求項5から請求項7のいずれかに記載の処理方法。
3 本件審決の理由の要旨20 本件審決は,本件補正発明は甲第1号証「佐藤竜也ほか,ブロックチェーン 基盤Hｙｐeｒledgeｒ Fabｒicの性能評価と課題整理,電子情報通信学会技術研究 報告,一般社団法人電子情報通信学会,2017年2月24日,第116巻, 第491号,ｐ.167-174」 (以下「引用文献1」という。)に記載の発明 (以下「引用発明」という。 と甲第2号証 ) 「特開2019-14135号公報」25 (平成31年1月31日出願公開。以下「引用文献2」という。)及び甲第3号 証「特開2010-278639号公報」(以下「引用文献3」という。)に記 6 載の周知技術に基づいて当業者が容易に発明することができたものであるから, 本件補正は独立特許要件(特許法17条の2第6項で準用する同法126条7 項)を満たさないので却下すべきものであり(同法159条1項の規定におい て読み替えて準用する同法53条1項),本願発明も引用発明と引用文献2及 5 び3に記載の周知技術に基づいて当業者が容易に発明できたものであるから, 本件出願は拒絶すべきものと判断した(以下,本件出願に係る願書に添付した 明細書を,図面を含めて「本願明細書」という。別紙1参照)。その判断の要旨 は以下のとおりである。
? 本件補正発明について10 ア 引用発明の認定 ブロックチェーン(Blｏckchain,BC)基盤のOSSプロジェクトである Hｙｐeｒledgeｒの基盤実装の一つであるFabｒicについて性能を中心とした評 価を行うものであって, Fabｒicは,コンソーシアムあるいはプライベート型での利用を想定した15 BC基盤であり, マルチホスト上にまたがった環境上にFabｒicによるBCネットワーク を構築し,その上で性能測定を行うものであって, クライアントからREST経由でBCネットワークにアクセスし,チェ ーンコードを実行して負荷をかけることで性能測定を行うものであり,20 負荷をかける際には,複数のクライアントからの同時アクセスを模擬す るため,マルチスレッドでトランザクションを並列実行するものであって, クライアントによる負荷生成ツールプログラムの処理の流れは,スレッ ド毎に実行トランザクション(inｖｏke)を指定した回数繰り返す(並列実 行)ことを含むものであり,25 スループット測定結果は,並列スレッド数を増やしていくとスループッ トも増加する傾向にあるが,ある程度並列度を増やすとスループットは頭 7 打ちとなり,スループットが頭打ちになった後も,それ以上に並列度を増 やしていくと,挙動が安定しなくなる場合があるため,フロント側でリク エストの流量制御を行う等の対策が必要となり得る, BC基盤Hｙｐeｒledgeｒ Fabｒicの性能評価。
5 イ 本件補正発明と引用発明との一致点 ネットワークにおいて台帳を分散して記録する複数のノードの少なくと も1つに対し,トランザクションのリクエストを送信する複数の処理単位 であって,複数の処理単位を生成する生成部と, 前記複数の処理単位のいずれかに当該トランザクションのリクエスト送10 信を割り当てる割当部と,を備えるシステム。
ウ 本件補正発明と引用発明との相違点 (ア) 相違点1 本件補正発明は, 「管理主体が存在しないパブリック型」ネットワーク であるのに対して,引用発明の,ブロックチェーン基盤実装の一つであ15 る「Fabｒic」は, 「コンソーシアムあるいはプライベート型での利用を想 定したBC基盤」である点。
(イ) 相違点2 本件補正発明は,処理単位が「プロセス」であって,生成部が複数の 「プロセス」を生成し,割当部が前記複数の「プロセス」のいずれかに20 トランザクションのリクエスト送信を割り当てるものであるのに対して, 引用発明は,処理単位が「スレッド」である点。
(ウ) 相違点3 本件補正発明は,生成部が「設定されるプロセス多重度に応じた」複 数のプロセスを生成するものであるのに対して,引用発明は,そのよう25 な特定がなされていない点。
(エ) 相違点4 8 本件補正発明は,割当部が「トランザクションの指示を受け付け」,複 数のプロセスのいずれかにトランザクションのリクエスト送信を割り当 てるのに対して,引用発明は,そのような特定がなされていない点。
エ 相違点の容易想到性 5 (ア) 相違点1 引用発明は,コンソーシアムあるいはプライベート型での利用を想定 しているとはいえ,引用発明を管理主体が存在しないパブリック型のブ ロックチェーンには適用できないとする技術的根拠は何ら認められない ところ,引用発明を管理主体が存在しないパブリック型のネットワーク10 に適用することには何ら技術的創意は見出せず,当業者であれば適宜実 施し得る事項にすぎない。
(イ) 相違点2 引用発明において,マルチプロセスを採用して処理単位をプロセスと することは,引用文献2及び3に示される周知技術に基づいて当業者が15 適宜なし得るものであり,さらに,甲第4号証「特開2015-881 76号公報」(以下「甲4文献」という。)に示されるように,プログラ ムを実行する単位である複数のプロセスを生成し,クライアント端末か ら受け取ったリクエストを,前記複数のプロセスのうちの何れかのプロ セスに割り当てることが,複数のプロセスを用いたプログラム実行にお20 ける極めて一般的な処理であることも踏まえれば,引用発明にマルチプ ロセスを採用した際に,生成部が複数の「プロセス」を生成し,割当部 が前記複数の「プロセス」のいずれかにトランザクションのリクエスト 送信を割り当てるとすることも,当業者であれば当然になし得るものと 認められる。
25 (ウ) 相違点3 引用発明では,「スループットが頭打ちになった後も,それ以上に並 9 列度を増やしていくと,挙動が安定しなくなる場合があるため,フロン ト側でリクエストの流量制御を行う等の対策が必要となり得る」として おり,これはフロント側でリクエスト送信を割り当てるスレッドの数を 制限することを示唆するものであって,スレッドの多重度を制限するこ 5 とを示唆するものである。
上記(イ)のとおり,引用発明において,マルチスレッドに換えて「マ ルチプロセス」を採用することは,当業者であれば適宜なし得る事項に すぎないと認められるところ,かかるマルチプロセスを採用した場合に, プロセス多重度を制限するため「プロセス多重度に応じた」複数のプロ10 セスを生成することは,リクエスト送信を割り当てるスレッドの数を制 限するという上記示唆に基づいて,当業者であれば容易に想到し得るも のである。
(エ) 相違点4 上記(イ)のとおり,引用発明において,マルチプロセスを採用するこ15 とは当業者が適宜なし得る事項と認められるところ,引用発明の「BC 基盤 Hｙｐeｒledgeｒ Fabｒic」を実際のトランザクション処理に用いる 場合, 「トランザクションの指示を受け付け」て,複数のプロセスのいず れかにトランザクションのリクエスト送信を割り当てることは,当業者 であれば当然になし得るものである。
20 ? 本願発明について ア 本願発明と引用発明との一致点 台帳を分散して記録する複数のノードの少なくとも1つに対し,トラン ザクションのリクエストを送信する複数の処理単位を生成する生成部と, 前記複数の処理単位のいずれかに当該トランザクションのリクエスト送25 信を割り当てる割当部と,を備えるシステム。
イ 本願発明と引用発明との相違点 10 (ア) 相違点a(相違点2と同じ) 本願発明は,処理単位が「プロセス」であって,生成部が複数の「プ ロセス」を生成し,割当部が前記複数の「プロセス」のいずれかにトラ ンザクションのリクエスト送信を割り当てるものであるのに対して,引 5 用発明は,処理単位が「スレッド」である点。
(イ) 相違点b(相違点4と同じ) 本願発明は,割当部が「トランザクションの指示を受け付け」,複数の プロセスのいずれかにトランザクションのリクエスト送信を割り当てる のに対して,引用発明は,そのような特定がなされていない点。
10 ウ 相違点の容易想到性 前記?エ(イ)及び(エ)のとおり,相違点a及び相違点bは,いずれも格 別のものではない。
4 取消事由 本件補正発明の進歩性に関する判断(相違点3の容易想到性の有無)の誤り15 第3 当事者の主張 1 原告 ? 相違点3の容易想到性の有無について ア 引用文献1の記載事項に関して (ア) 本件審決は,引用発明では,スループットが頭打ちになった後も, 「 『20 それ以上に並列度を増やしていくと,挙動が安定しなくなる場合がある ため,フロント側でリクエストの流量制御を行う等の対策が必要となり 得る』としており,これはフロント側でリクエスト送信を割り当てるス レッドの数を制限することを示唆するものであって,スレッドの多重度 を制限することを示唆するものである。 (19頁16ないし21行目) 」25 とするが,誤りであり,その結果,相違点3に係る容易想到性の判断に も誤りがある。
11 引用文献1の「BCサービス:P2Pプロトコル,分散台帳,コンセ ンサスマネージャといった要素によって構成される。P2Pプロトコル により,P2Pでの双方向ストリーミング,フロー制御,リクエストの 多重化といった機能を提供する。既存ネットワークと連携して動作する。」 5 (168頁右欄36行ないし169頁左欄4行目)との記載によると, 引用文献1では, 「フロー制御」と「リクエストの多重化」とは異なる機 能としており,この記載から想定される構成は別紙6「参考図1」のと おりである。同図に示されるように,上記「リクエストの多重化」は, 1つのプロセスに流入するリクエストを複数のスレッドで多重化するこ10 とによってBCネットワークに出力するものであり,その1つのプロセ スに流入するリクエストの流量(フロー)を制御するのが上記「フロー 制御」である。したがって,引用発明において, 「挙動が安定しなくなる 場合があるため,フロント側でリクエストの流量制御を行う等の対策」 をとるのは,「フロー制御」(流量制御)であり,「リクエストの多重化」15 ではない。
ここで,挙動の不安定を回避するための「フロー制御」は,技術常識 上, 「流量制御」と同じであるから(甲21ないし25)「リクエストの , 流量制御」は,技術常識上,@キュー長の調整又はAリクエスト送信頻 度の低下のいずれかである(甲19)。
20 したがって,引用文献1に「挙動が安定しなくなる場合があるため, フロント側でリクエストの流量制御を行う等の対策が必要となり得る」 旨の記載があるからといって,引用文献1に「スレッドの数を制限する ことを示唆する」記載があるとはいえず, 「スレッドの多重度を制限する ことを示唆する」記載があるともいえない。
25 (イ) 被告は,引用文献1における「リクエストの流量制御」とは,単位 時間当たりの「リクエスト総数」,すなわち,「スレッド当たりのリクエ 12 スト数×スレッド数」を制御するものであって, 「流量制御」を行うため に,スレッド数とリクエスト数の双方が制御の対象となっている旨主張 するが,引用文献1には, 「リクエストの流量制御」が単位時間当たりの リクエスト総数の制御であるとの記載はないし,仮に, 「リクエスト流量 5 制御」をすることが単位時間当たりの「リクエスト総数」を制御するこ とであったとしても,それが「スレッド当たりのリクエスト数×スレッ ド数」を制御することに等しいということを引用文献1の開示事項から 読み取ることはできない。
また,引用文献1においては, 「負荷が大きすぎること」 すなわち , 「単10 位時間当たりのリクエスト数が大きすぎること」しか課題として認識で きておらず, 「並列度が高すぎること」を課題として認識しているのでは ないから,上記課題を認識するための手段としてスレッドの数を増加さ せてみた測定結果にすぎない記載をもって, 「スレッド数(並列度)の制 御」を, 「リクエストの流量制御」における課題解決手段として用いるこ15 とができると読み取ることはできない。
イ スレッドとプロセスの置換に関して (ア) 被告は,生成部においてプロセス多重度を制限することは本件補正 発明の発明特定事項に基づくものではない旨主張するが,本願明細書に は, 閾値Thnよりも小さいプロセス多重度をプロセス110の数とし 「20 てプロセス生成装置11に設定する」ことにより, 「ブロックチェーンネ ットワーク5における演算処理能力にボトルネックを発生させずに,リ クエストの送信側においてボトルネックを発生させることでき」 「プロ , セス生成装置11において不要なプロセス110を生成しないようにし て,リクエスト制御システム1のリソースを効率的に用いることができ25 る」 (以上,本願明細書【0046】,図1)との記載があるから, 「設定 されるプロセス多重度に応じた複数のプロセスを生成する生成部」とい 13 う発明特定事項によれば,リクエストの多重化を実現するプロセス数を 「 必要な数に制御すること」や「不要なプロセスを生成せずにリソースを 効率的に用いること」といった具体的な効果まで発明特定事項において 特定されなくとも,本件補正発明がプロセス多重度を制限する構成とし 5 て特定されたものといえるのは明らかである。
(イ) 本件審決は, 「マルチプロセスを採用した場合に,プロセスの多重度 を制限するため『プロセスの多重度に応じた』複数のプロセスを生成す ることは,リクエスト送信を割り当てるスレッドの数を制限するという 上記示唆に基づいて,当業者であれば容易に想到し得るものである。」10 (19頁24ないし28行目)とするが,誤りである。
仮に,引用文献1に「スレッドの数を制限することを示唆するのであ って,スレッドの多重度を制限することを示唆する」旨の記載があると しても,マルチプロセスではない引用発明からは,1つのプロセスにお いてスレッドの多重度を制限することが示唆されるだけであって,プロ15 セス多重度を制限することまで示唆されることはない。
また,プロセスは1個のメモリ空間が割り当てられた実行プログラム であるのに対して,スレッドはプロセス内に所在してCPUコアに対す る命令を実行する単位をいい,この両者はハードウェア資源の利用態様 が相違するため,これらを相互に置換することはできない。すなわち,20 別紙6「参考図1」に示すように,引用発明は1つのプロセスにおいて マルチスレッドを実現するものであるから,プロセスがスレッドの多重 度の制限をするが,一方,別紙7「参考図2」に示すように,本件補正 発明におけるマルチプロセスの多重度は,各プロセスの生成を制御する 生成部が制限する。このように,引用発明におけるスレッドとプロセス25 との関係は,本件補正発明におけるプロセスと生成部との関係に対応す る。参考図1のような引用発明におけるスレッドとプロセスとの関係を, 14 参考図2のような本件補正発明におけるプロセスと生成部との関係に置 換することが容易想到であるという根拠は存在しない。
ウ 顕著な効果に関して 本願明細書の記載(【0046】,図1)によると,本件補正発明は,プ 5 ロセス生成装置において不要なプロセスを生成しないようにして,リクエ スト制御システムのリソースを効率的に用いることができるとの顕著な 効果を奏する。
一方,引用発明においては,別紙6「参考図1」に示すように,リクエ ストの流量制御がリクエストの多重化の前段階のフロー制御で行われ,ス10 レッドの数は変わることがなく,不要なスレッドが残ったままであるから, リソースを効率的に用いることができない。
エ まとめ 以上のとおり,相違点3を容易想到と判断した本件審決の判断には誤り がある。
15 ? 小括 前記?からすれば,本件補正が独立特許要件を充足しないとした本件審決 の判断には誤りがあり,本件補正を却下して本願発明が進歩性を欠如すると して本件出願を拒絶すべきものと判断した本件審決の判断にも,誤りがある。
2 被告20 ? 相違点3の容易想到性の有無について ア 引用文献1の記載事項に関して (ア) 引用文献1には,スループットの計算方法を, 「全スレッドによる合 計リクエスト数/(全レスポンスが返ってきた時刻-リクエスト処理を 開始した時刻) とし, 」 1スレッドあたりのリクエスト数を1000ある25 いは200に固定して(171頁左欄24行ないし右欄7行目,171 頁表3),スレッド数を変えながら測定した結果から,「ある程度並列度 15 を増やすとスループットは頭打ちになった. ,スループットが頭打ちに 」「 なった後も,それ以上に並列度を増やしていくと,内部的にエラーが発 生する等,安定稼働が困難となる場合が見受けられた. との評価が行わ 」 れたことが開示されている(171頁右欄27ないし39行目,172 5 頁図3及び172頁図4)。
そうすると,引用文献1における, 「高負荷を与えた場合には,挙動が 安定しなくなる場合があるため,フロント側でリクエストの流量制御を 行う等の対策が必要となり得る。 (171頁右欄27ないし39行目) 」 との記載における「リクエストの流量制御」とは,単位時間当たりの「リ10 クエスト総数」,すなわち,「スレッド当たりのリクエスト数×スレッド 数」を制御するものであって, 「流量制御」を行うために,スレッド数と リクエスト数の双方が制御の対象となっていると解されるから,スレッ ド数を制限することも示唆されているというべきである。
さらに,引用文献1には「2.3 本研究の課題 BCの実適用に向け15 ては,BC基盤およびその実装における現時点での技術課題の明確化が 必要である.特に,金融業務への適用に向けては,一般的にトランザク ションのスループットが性能面の最重要指標である. (169頁左欄2 」 9ないし33行目) 「図3にセキュリティ機能OFF時の,図4にセキ , ュリティ機能ON時のinｖｏke/ｑｕeｒｙスループット測定結果を示す.図20 に示す通り,セキュリティ機能OFF/ON時ともに,inｖｏkeとｑｕeｒｙ の両方で,並列スレッド数を増やしていくとスループットも増加する傾 向にあった.ただし,ある程度並列度を増やすとスループットは頭打ち となった.また,スループットが頭打ちになった後も,それ以上に並列 度を増やしていくと,内部的にエラーが発生する等,安定稼働が困難と25 なる場合が見受けられた.つまり,高負荷を与えた場合には,挙動が安 定しなくなる場合があるため,フロント側でリクエストの流量制御を行 16 う等の対策が必要となり得る. (171頁右欄27ないし39行目)と 」 の記載があるところ,これらの記載から,引用文献1には,トランザク ションのスループットが性能面の最重要指標であり,並列スレッド数(並 列度)を増やしていくとスループットが増加する傾向にあるが,ある程 5 度並列度を増やしていくとスループットは頭打ちになり,さらに並列度 を増やしていくと,高負荷が与えられて挙動が安定しなくなる場合があ るため,フロント側でリクエストの流量制御を行う等の対策が必要とな り得ることが開示されているといえる。
そうすると,引用文献1には,並列度を増加させると高負荷となるの10 で,この高負荷を抑制するために流量制御を行う必要があるところ,こ の流量制御を行うための一つの手段として並列度を制限することが示唆 されている。そして,上記流量制御を行うためには, 「並列度」を増やし ていって「挙動が安定しなくなる」手前の「並列度」,つまり,「挙動が 不安定にならない最大の並列度」 (適切な並列度)に制限する必要がある15 ことが理解できる。
したがって,引用文献1には,並列スレッド数を制限することを示唆 する記載があるといえる。
(イ) 原告が引用する引用文献1の「BCサービス:P2Pプロトコル, 分散台帳,コンセンサスマネージャといった要素によって構成される.20 P2Pプロトコルにより,P2Pでの双方向ストリーミング,フロー制 御,リクエストの多重化といった機能を提供する.既存ネットワークと 連携して動作する.」との記載における「フロー制御」や「リクエストの 多重化」は, 「BCサービス」の要素である「P2Pプロトコル」による 機能として紹介されているのであるから,ここでいう「フロー制御」及25 び「リクエストの多重化」は,ブロックチェーンネットワークを構成す るノード同士の通信に関して説明したものであり,参考図1でいえば, 17 最下部の「BCネットワーク」の内部で行われる通信におけるものを指 すにすぎない。
イ スレッドとプロセスの置換に関して (ア) 引用発明のマルチスレッドと本件補正発明の複数のプロセスは,と 5 もに,トランザクションのリクエストを送信する複数の処理単位である 点で共通しており,引用文献2及び3に記載される周知技術によれば, 並列処理を実行するマルチスレッドとマルチプロセスは,相互に置き換 え可能なものである。
そして,引用発明のマルチスレッドは本件補正発明の複数のプロセス10 に対応付けられるから,マルチスレッドを生成する生成部が,複数のプ ロセスを生成する生成部に対応付けられることは自明である。
したがって,本件審決が,引用発明において,プロセス多重度に応じ た複数のプロセスを生成することを容易想到であると判断した点に誤り はない。
15 (イ) 原告は,本件補正発明では,生成部においてリクエストの多重化を 実現するプロセスの数を必要な数に制御することによって,不要なプロ セスを生成せずにリソースを効率的に用いることができると主張するが, 相違点3に係る本件補正発明の発明特定事項は「設定されるプロセス多 重度に応じた複数のプロセスを生成する生成部」であって,単に「プロ20 セス多重度」が「設定される」だけであって, 「閾値Thnよりも小さい プロセス多重度」が「設定される」ことは特定されていない。原告の主 張は,本件補正発明の発明特定事項に基づくものではなく,失当である。
ウ 顕著な効果に関する主張について 前記イ(イ)のとおり,原告の主張は,本件補正発明の発明特定事項に基25 づくものではなく,失当である。
また,本件補正発明のようにプロセス多重度を設定するものではない引 18 用発明との対比によって,プロセス多重度に基づく本件補正発明が顕著な 効果を奏すると主張することも失当である。
? 小括 相違点3を容易に想到できるとした本件審決の判断に誤りはないから,本 5 件補正を却下すべきであるとした本件審決の判断にも誤りはなく,本願発明 を審理の対象として進歩性を欠如するとして本件出願を拒絶すべきものと判 断した本件審決の判断にも,誤りはない。
当裁判所の判断
1 認定事実10 ? 本願発明について 本願明細書には,別紙1「本願明細書の記載事項(抜粋)」のとおりの記載 があり,この記載によると,本件出願に係る発明について,次のような開示 があると認められる。
ア 技術分野15 本件出願に係る発明は,トランザクションをブロックチェーンネットワ ークにリクエストするための技術に関する(【0001】 。
) イ 背景技術 ブロックチェーンを用いた分散型台帳技術が,ビットコイン等の暗号資 産(仮想通貨)を管理する方法として用いられているが,近年では,これ20 らの技術は,このような暗号資産だけではなく,様々な資産を管理したり 移動したりする方法として用いることも検討されている(【0002】 。
) ウ 発明が解決しようとする課題 分散型台帳技術では,P2P(Peeｒ ｔｏ Peeｒ)によって接続された複数 のノードによってネットワークが形成され,そのネットワークにおける複25 数のノードによって台帳が分散して記録されるところ,分散型台帳技術に おいては,ほとんどの場合,ブロックチェーンが台帳に記録され,台帳に 19 直接記録されない場合でも何らかの形態で用いられる(【0004】 。
) ブロックチェーンネットワークを構成する各ノードによれば,互いが保 持するデータの正当性を高めるために,所定のアルゴリズムによって合意 形成が行われるが,これによって,データの改ざんが難しくなり,取引の 5 信頼性が保たれるものの,一般的には合意形成の処理には多くの時間を要 すると考えられているため,大量のトランザクションが発生するような処 理に適用することは難しいと考えられている(【0005】 。
) 本件出願に係る発明の目的の一つは,分散型台帳技術を用いた場合でも, 多くのトランザクションを効率よく処理することにある(【0006】 。
)10 エ 課題を解決するための手段 本件出願に係る発明の一実施形態によれば,台帳を分散して記録する複 数のノードの少なくとも1つに対し,トランザクションのリクエストを送 信する複数のプロセスを生成する生成部と,トランザクションの指示を受 け付け,前記複数のプロセスのいずれかに当該トランザクションのリクエ15 スト送信を割り当てる割当部と,を備えるシステムが提供される 【000 ( 7】 。
) 前記複数のノードで形成されるネットワークにおける所定のトランザク ションのリクエストに対する平均スループットとプロセス多重度との関 係において,プロセス多重度の増加に対する平均スループットの増加の割20 合が,プロセス多重度が第1値のときに第1割合であり,当該第1値より 大きい第2値以上であるときに前記第1割合より小さい第2割合であり, 前記複数のプロセスの数は,前記第2値よりも小さい数で設定されてもよ い(【0010】 。
) 前記複数のノードで形成されるネットワークは,コンソーシアム型であ25 ってもよい(【0011】 。
) 本件出願に係る発明の一実施形態によれば,トランザクションの指示を 20 受け付け,台帳を分散して記録する複数のノードの少なくとも1つに対し, トランザクションのリクエストを送信する複数のプロセスのいずれかに, 前記指示に基づくトランザクションのリクエスト送信を割り当てる,処理 方法が提供される(【0012】 。
) 5 オ 発明の効果 本件出願に係る発明の一実施形態によれば,分散型台帳技術を用いた場 合でも,多くのトランザクションを効率よく処理することができる(【00 17】 。
) カ 発明を実施するための形態10 (ア) ブロックチェーンネットワーク5における演算処理能力にボトルネ ックが存在する状況は,極めて多くの処理が集中した場合であって,実 際には,その前の段階,すなわちトランザクションのリクエストを送信 する側においてボトルネックが存在する場合が多いとの知見に基づき, リクエスト制御システム1では,ブロックチェーンネットワーク5にお15 ける演算処理能力にボトルネックが存在する段階までリクエストを送信 するためのプロセスを多重化することで,処理量を向上させることがで きる(【0022】 。
) (イ) 実施形態のブロックチェーンネットワークは,管理主体が存在する コンソーシアム型(例えば,Qｕｏｒｕm,Hｙｐeｒledgeｒ Fabｒic等)を想定20 しているが,管理主体が存在しないパブリック型(例えば,Eｔheｒeｕm 等)であっても適用可能である。 【0026】 。
( ) (ウ) プロセス生成装置11Aは,設定装置39から指定された数のプロ セス110を起動するとともに,各プロセス110においてトランザク ションのリクエストを送信してから,ブロックチェーンネットワーク525 においてトランザクションが分散型台帳に記録されたことを検出するま での時間(以下「スループット」という。)を測定する。この測定したス 21 ループットを設定装置39に送信する(【0040】 。
) 設定装置39は,プロセス生成装置11A及び指示生成装置38を制 御して,プロセス多重度(プロセス110の数:m個)を変更しつつ, 1プロセス当たりの平均スループットを測定する。これによって,設定 5 装置39は,プロセス多重度と平均スループットとの関係を取得し,こ の関係を用いて,利用するブロックチェーンネットワーク5における最 適なプロセス110の数を算出するが,この数は,上述したn個に相当 するものとして,リクエスト制御システム1におけるプロセス生成装置 11に設定される(【0042】 。
)10 図6は,本発明の一実施形態におけるプロセス多重度と平均スループ ットとの関係を説明する図であるところ,プロセス多重度が低い場合, プロセス多重度の増加に伴い平均スループットは増加していくが,プロ セス多重度が大きくなると,プロセス多重度が増加しても,平均スルー プットは増加しなくなっていくように,プロセス多重度が大きい値N215 である場合の平均スループットの増加の割合は,プロセス多重度が小さ い値N1(第1値)である場合の平均スループットの増加の割合(第1 割合)よりも小さい(【0044】 。特定のプロセス多重度における平均 ) スループットの増加の割合は,図6に示すグラフにおいて,そのプロセ ス多重度における傾き(微分値)に相当するところ,この増加の割合(増20 加率)がプロセス多重度の増加に対して大きく減少し始めるとき(第2 割合)のプロセス多重度が,図6に示す閾値Thn(第2値)に対応す る(【0044】 。
) このように,閾値Thnよりもプロセス多重度が小さい領域A1にお いては,ブロックチェーンネットワーク5における演算処理能力にボト25 ルネックがあるのではなく,リクエストを送信する側の処理にボトルネ ックがあり,一方,閾値Thnよりもプロセス多重度が大きい領域(判 22 決注・前後の文脈から「量器」は「領域」の誤記と認める。)A2におい ては,プロセス多重度を増加させても,平均スループットがほとんど増 加しないことから,ブロックチェーンネットワーク5における演算処理 能力にボトルネックがあることが分かる(【0045】 。
) 5 設定装置39が,閾値Thnよりも小さいプロセス多重度をプロセス 110の数としてプロセス生成装置11に設定することにより,ブロッ クチェーンネットワーク5における演算処理能力にボトルネックを発生 させずに,リクエストの送信側においてボトルネックを発生させること ができ,プロセス生成装置11において不要なプロセス110を生成し10 ないようにして,リクエスト制御システム1のリソースを効率的に用い ることができる(【0046】 。
) ? 引用発明1について 引用文献1には,別紙2「引用文献1の記載事項(抜粋)」のとおりの記 載があり,この記載によると,引用発明として,本件審決が認定するとおり15 のものを認定することができ,この点は,当事者間にも争いがない。
2 取消事由(本件補正発明の進歩性に関する判断の誤り)の有無について ? 相違点3の容易想到性の有無について ア 引用文献1の記載事項に関して 引用文献1には,@課題として,「2.3 本研究の課題 BCの実適用20 に向けては,BC基盤およびその実装における現時点での技術課題の明確 化が必要である.特に,金融業務への適用に向けては,一般的にトランザ クションのスループットが性能面の最重要指標である. (169頁左欄2 」 9ないし33行目)を掲げ,A課題抽出に向けての目的として, 「目的2: Fabｒic/BC基盤の性能ボトルネック抽出方法の検討 性能限界や傾向25 を把握するためには,そのボトルネック箇所を特定することが重要であ る. (169頁右欄9ないし38行目)とし,B測定方法として,マルチ 」 23 スレッドでトランザクションを並列実行して負荷をかけるものとし,その 方法として,スレッドごとにトランザクションを指定した回数繰り返し, 全スレッドのトランザクションが完了するまでの時間を測定することと し(171頁左欄3ないし23行目) Cトランザクションのスループット , 5 の計算方法を, 「全スレッドによる合計リクエスト件数/(全レスポンスが 返ってきた時刻-リクエスト処理を開始した時刻) とし, 」 1スレッドあた りのリクエスト数を1000あるいは200に固定し,並列スレッド数を 変える等の条件で実験したところ(171頁左欄24行ないし右欄7行目, 171頁表3),D結果として,「並列スレッド数を増やしていくとスルー10 プットも増加する傾向にあった.ただし,ある程度並列度を増やすとスル ープットは頭打ちとなった.また,スループットが頭打ちになった後も, それ以上に並列度を増やしていくと,内部的にエラーが発生する等,安定 稼働が困難となる場合が見受けられた.つまり,高負荷を与えた場合には, 挙動が安定しなくなる場合があるため,フロント側でリクエストの流量制15 御を行う等の対策が必要となり得る. (171頁右欄27ないし39行目, 」 172頁図3,172頁図4)との知見が得られたとの記載がある。
これらの記載によると,引用文献1の実験においては,スレッド当たり のリクエスト数をセキュリティ機能のOFF又はONの相違に従って固 定し,並列スレッド数を変化させてスループット(1秒当たりのリクエス20 ト処理量)を測定しているのであり, 「全スレッドによる合計リクエスト件 数」は並列スレッド数にのみ左右されるから,引用文献1は,専ら並列ス レッド数とスループットとの関係を測定したものであり,その測定結果と して,並列スレッド数の増加に対するスループットは,ある程度までは増 加し,一定程度で頭打ちとなり,その後は挙動不安定になるというものが25 得られたとするものである。そうすると,引用文献1は,並列スレッド数 を増加させていけばスループットは増加するが,ある程度以降は挙動が安 24 定しなくなるので,その場合には並列スレッド数の増加による効果がなく なり, 「リクエストの流量制限」で対応しなければならないと理解すべきも のであるから,その記載内容は,スレッド数の増加による効果には一定の 最大限度があることを含意するものというべきである。
5 以上のとおりであるから 原告の前記第3の1?アの主張は採用する ことができない。なお,原告は,引用文献1においては, 「負荷が大きすぎ ること」,すなわち「単位時間当たりのリクエスト数が大きすぎること」を 認識するための手段としてスレッドの数を増加させてみた測定結果が記 載されているのにすぎず,このような記載をもって, 「スレッド数(並列度)10 の制御」を, 「リクエストの流量制御」における課題解決手段として読み取 ることはできないない旨主張するが,前述のとおり,引用文献1の該当部 分の記載は,単に課題認識手段としての測定結果を表示したものとはいえ ず,スレッドの数を増加させた場合の結果に応じて,課題解決に向けた対 応策の示唆等にも及ぶものであるから,原告の前記主張は前提を欠くもの15 というべきである。
したがって,引用文献1には,引用発明がスレッド数を制御すること, 少なくとも,スレッドの多重度を設定し,これより,設定されるスレッド 多重度に応じた複数のスレッドを生成するものであるとの記載があると 認められる。
20 イ スレッドとプロセスの置換について (ア) 相違点3は, 「本件補正発明は,生成部が『設定されるプロセス多重 度に応じた』複数のプロセスを生成するものであるのに対して,引用発 明は,そのような特定がなされていない点」というものである。
(イ) 引用文献2の記載事項は別紙3「引用文献2の記載事項(抜粋)」の25 とおりであり,引用文献3の記載事項は別紙4「引用文献3の記載事項 (抜粋)」のとおりであり,甲4文献の記載事項は別紙5「甲4文献の記 25 載事項(抜粋)」のとおりであり,これらの記載事項からすると,並列処 理を実現するに当たり,マルチプロセス及びマルチスレッドはどちらも 周知の技術であり,どちらを用いて並列処理を実現するかは,当業者が 技術的要件等に基づき適宜設計的に決定し得た事項であることが認めら 5 れる。
(ウ) ここで,本件補正発明についてみると,本件補正発明は「トランザ クションのリクエストを送信する複数のプロセスであって,設定される プロセス多重度に応じた複数のプロセスを生成する生成部」を備えると のみ特定され, 「プロセス多重度」はプロセスの数である(本願明細書【010 031】, 【0038】 。
) そして, 「プロセス多重度」は単に「設定される」 と特定されているだけであり,また,設定される「プロセス多重度」と 生成されるプロセスとがどのような関係において対応するのかは何ら特 定されていない。これに対し,本件補正後の請求項4に係る発明は, 「当 該プロセス多重度の増加に対する平均スループットの増加の割合が,プ15 ロセス多重度が第1値のときに第1割合であり,当該第1値より大きい 第2値以上であるときに前記第1割合より小さい第2割合であり,前記 複数のプロセスの数は,前記第2値よりも小さい数で設定される」と, 同請求項8に係る発明は,当該プロセス多重度の増加に対する平均スル 「 ープットの増加の割合が,プロセス多重度が第1値のときに第1割合で20 あり,当該第1値より大きい第2値以上であるときに前記第1割合より 小さい第2割合であり,前記複数のプロセスの数は,前記第2値よりも 小さい数で設定される」とされており,これら発明との対比からして, 本件補正発明は,これらプロセス数を所定の数に制限する特定がされて いないものと理解できる。したがって,本件補正発明は,プロセス数が25 制御されるものであればこれらを全て含むものと認められる。
(エ) 前記アのとおり,引用発明の構成は,スレッドの多重度を設定し, 26 設定されるスレッドの多重度に応じた複数のスレッドを生成するもので あるところ,前記(イ)のとおり,マルチスレッドとマルチプロセスのい ずれの並列処理を実現するかは,当業者が技術的要件等に基づき適宜設 計的に決定し得た事項であることからすれば,引用発明のスレッドの構 5 成を適宜プロセスに代え,相違点3に係る,生成部が「設定されるプロ セスの多重度に応じた複数のプロセスを生成する」ものに置換すること は当業者にとって極めて容易なことであり,これにより引用発明は,前 記(ウ)のとおり,本件補正発明に至ることとなる。
ウ 効果について10 発明の効果が予測できない顕著なものであるかについては,当該発明の 特許要件判断の基準日当時,当該発明の構成が奏するものとして当業者が 予測することのできなかったものか否か,当該構成から当業者が予測する ことのできた範囲の効果を超える顕著なものであるか否かという観点か ら検討する必要があるところ,前記イ(ウ)のとおりの構成とみるべき本件15 補正発明の効果は,その構成から当然に当業者が予想し得る範囲内のもの にすぎない。
エ 原告の主張について 前記第3の1?記載の原告の主張については,前記認定の中で適宜判断 済みであるが,特に補足すべき点については以下のとおりである。
20 (ア) 原告は,前記第3の1?イ(ア)のとおり,本願明細書の記載を併せ 考慮すれば, 設定されるプロセス多重度に応じた複数のプロセスを生成 「 する生成部」という本件補正発明の発明特定事項によって,プロセス多 重度に応じてプロセス数を制限するとの構成が特定されている旨主張す る。
25 しかしながら,前記イ(ウ)のとおり,特許請求の範囲の記載自体から, プロセス多重度に応じてプロセス数を制限するとの構成は読み取れない 27 し,原告が主張する本願明細書の記載及びプロセス多重度に応じてプロ セス数を制限するとの発明特定事項は,本件補正発明とは異なる別の請 求項に係るものであるというべきである。
したがって,原告の上記主張を採用することはできない。
5 (イ) 原告は,前記第3の1?イ(イ)のとおり,@マルチプロセスではな い引用発明からはスレッド数を制限することが示唆されるだけであって, プロセス数を制限することまで示唆されることはない,Aプロセスは1 個のメモリ空間が割り当てられた実行プログラムであるのに対して,ス レッドはプロセス内に所在してCPUコアに対する命令を実行する単位10 をいい,この両者はハードウェア資源の利用態様が相違するため,これ らを相互に置換することはできない旨主張する。
上記@の主張についてみると,確かに,並列スレッド数増加によるス ループット増加に頭打ちの効果があり,更なる増加はむしろ挙動を安定 させなくなることから,スレッド数を制限することが示唆されたとして15 も,マルチスレッドの構成をマルチプロセスの構成に置換する際に,プ ロセス数を制限することまでもが直ちに動機付けられるとはいい難い。
なぜならば,トランザクションのリクエストを送信する際に,マルチプ ロセスにもマルチスレッドと同様の頭打ち効果や挙動不安定があるとの 知見を前提としていなければ,スレッド数を制限するマルチスレッドの20 構成を,プロセスを制限するマルチプロセスの構成に置換する動機付け はないからである。この点,「かかるマルチプロセスを採用した場合に, プロセスの多重度を制限するため『プロセスの多重度に応じた』複数の プロセスを生成することは,リクエスト送信を割り当てるスレッドの数 を制限するという上記示唆に基づいて,当業者であれば容易に想到し得25 る」とした本件審決の説示は当を得たものとはいい難い。
しかしながら,前記(ア)のとおり,プロセス数を制限することは本件 28 補正発明の発明特定事項には含まれず, 「プロセス多重度」に対応するプ ロセス数が設定されるものであればよいものと認められるから,引用発 明のマルチスレッドの構成をマルチプロセスの構成に置換すれば本件補 正発明に至るのであり,本件審決の判断は結論においては正当であり, 5 原告の上記主張は,本件の結論を左右するものとはいえない。
次に,上記Aの主張についてみると,マルチスレッドとマルチプロセ スとがそれぞれハードウェア資源の利用態様が相違するとしても,マル チスレッド及びマルチプロセスが並列処理を行うための手法として周知 であることから,格別な困難でもない限り,マルチスレッドとして構成10 されたものをマルチプロセスとして構成されたものに転用することは, 当業者が適宜なし得る事項である。この転用の際,スレッドからプロセ スへ置換する場合に両立しない部分があれば,当業者は技術常識に従い 所要の変更を加えることができるのであって,本件補正発明について, それが困難であるとは認められない。
15 したがって,原告の上記主張を採用することはできない。
(ウ) そのほか原告がるる主張するところも前記アの認定判断を左右しな い。
? 小括 前記?の認定判断によると,相違点3は容易想到であるとした本件審決の20 判断は結論において相当であり,そうすると,本件補正発明は引用発明及び 周知技術に基づいて当業者が容易に発明をすることができたものであるから, 本件補正発明は独立特許要件を欠くものであり,本件補正は特許法17条の 2第6項で準用する同法126条7項の規定に違反するので,同法159条 1項において読み替えて準用する同法53条1項の規定により却下すべきも25 のであって,本件補正を却下した本件審決の判断に誤りがあるとはいえず, また,本願発明についても,当業者が容易に発明をすることができたものと 29 いうことになるから,本件出願を拒絶すべきとした本件審決の判断にも誤り はない。
3 結論 よって,取消事由は理由がないから,原告の請求を棄却することとして,主 5 文のとおり判決する。
追加
10裁判長裁判官菅野雅之15裁判官本吉弘行20裁判官中村恭30 (別紙1)本願明細書の記載事項(抜粋)【発明の詳細な説明】5【技術分野】【0001】本発明は,トランザクションをブロックチェーンネットワークにリクエストするための技術に関する。
【背景技術】10【0002】ブロックチェーンを用いた分散型台帳技術が,ビットコイン等の暗号資産(仮想通貨)を管理する方法として用いられている。近年では,これらの技術は,このような暗号資産だけではなく,様々な資産を管理したり移動したりする方法として用いることも検討されている・・・。
15【発明の概要】【発明が解決しようとする課題】【0004】分散型台帳技術では,P2P(PeeｒｔｏPeeｒ)によって接続された複数のノードによってネットワークが形成され,そのネットワークにおける複数のノードによ20って台帳が分散して記録される。分散型台帳技術においては,ほとんどの場合,ブロックチェーンが台帳に記録され,台帳に直接記録されない場合でも何らかの形態で用いられる。以下の説明では,台帳を分散して記録する複数のノードによって形成されるネットワークであって,ブロックチェーンを扱うネットワークを,ブロックチェーンネットワークという。なお,本明細書でいうブロックチェーンネットワ25ークは,必ずしもビザンチン耐性を備えた構成であることを必須としないが,ビザンチン耐性を備えた構成であってもよい。
31 【0005】ブロックチェーンネットワークを構成する各ノードによれば,互いが保持するデータの正当性を高めるために,所定のアルゴリズムによって合意形成が行われる。
これによって,データの改ざんが難しくなり,取引の信頼性が保たれる。一方,一5般的には合意形成の処理には多くの時間を要すると考えられているため,大量のトランザクションが発生するような処理に適用することは難しいと考えられている。
【0006】本発明の目的の一つは,分散型台帳技術を用いた場合でも,多くのトランザクションを効率よく処理することにある。
10【課題を解決するための手段】【0007】本発明の一実施形態によれば,台帳を分散して記録する複数のノードの少なくとも1つに対し,トランザクションのリクエストを送信する複数のプロセスを生成する生成部と,トランザクションの指示を受け付け,前記複数のプロセスのいずれか15に当該トランザクションのリクエスト送信を割り当てる割当部と,を備えるシステムが提供される。
【0008】前記複数のプロセスは,第1プロセスおよび第2プロセスを含み,前記第1プロセスが前記リクエストを送信するノードは,前記第2プロセスが前記リクエストを20送信するノードと同一であってもよい。
【0009】前記割当部は,ラウンドロビン方式により前記トランザクションのリクエスト送信を割り当ててもよい。
【0010】25前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットとプロセス多重度との関係において,プロセ32 ス多重度の増加に対する平均スループットの増加の割合が,プロセス多重度が第1値のときに第1割合であり,当該第1値より大きい第2値以上であるときに前記第1割合より小さい第2割合であり,前記複数のプロセスの数は,前記第2値よりも小さい数で設定されてもよい。
5【0012】本発明の一実施形態によれば,トランザクションの指示を受け付け,台帳を分散して記録する複数のノードの少なくとも1つに対し,トランザクションのリクエストを送信する複数のプロセスのいずれかに,前記指示に基づくトランザクションのリクエスト送信を割り当てる,処理方法が提供される。
10【0013】前記複数のプロセスは,第1プロセスおよび第2プロセスを含み,前記第1プロセスが前記リクエストを送信するノードは,前記第2プロセスが前記リクエストを送信するノードと同一であってもよい。
【0014】15前記トランザクションのリクエスト送信を割り当てるときには,ラウンドロビン方式を用いてもよい。
【0015】前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットとプロセス多重度との関係において,プロセ20ス多重度の増加に対する平均スループットの増加の割合が,プロセス多重度が第1値のときに第1割合であり,当該第1値より大きい第2値以上であるときに前記第1割合より小さい第2割合であり,前記複数のプロセスの数は,前記第2値よりも小さい数で設定されてもよい。
【0016】25前記複数のノードで形成されるネットワークは,コンソーシアム型であってもよい。
33 【発明の効果】【0017】本発明の一実施形態によれば,分散型台帳技術を用いた場合でも,多くのトランザクションを効率よく処理することができる。
5【図面の簡単な説明】【0018】【図1】本発明の一実施形態におけるリクエスト制御システムの構成を示すブロック図である。
【図2】本発明の一実施形態におけるリクエスト制御システムが実行する割当処理10を示すフローチャートである。
【図3】本発明の一実施形態におけるプロセスが実行する送信処理を示すフローチャートである。
【図4】本発明の一実施形態におけるリクエスト制御システムが事前設定をする場合の構成を示すブロック図である。
15【図5】本発明の一実施形態におけるリクエスト制御システムが実行する設定処理を示すフローチャートである。
【図6】本発明の一実施形態におけるプロセス多重度と平均スループットとの関係を説明する図である。
【発明を実施するための形態】20【0019】以下,本発明の一実施形態について,図面を参照しながら詳細に説明する。以下に示す実施形態は本発明の実施形態の一例であって,本発明はこの実施形態に限定して解釈されるものではない。すなわち,以下に説明する複数の実施形態に公知の技術を適用して変形をして,様々な態様で実施をすることが可能である。
25【0020】<実施形態>34 [1.システムの概要]図1は,本発明の一実施形態におけるリクエスト制御システムの構成を示すブロック図である。リクエスト制御システム1は,ユーザ端末80からネットワークNWを介して電文を受信し,その電文に対応したトランザクションのリクエストをブ5ロックチェーンネットワーク5に送信する。このリクエストは,ブロックチェーンネットワーク5における分散型台帳にそのトランザクションを記録させるための指示である。
【0021】一般的には,ブロックチェーンネットワーク5において分散型台帳への記録は,10多くの時間を要する。したがって処理のボトルネックはブロックチェーンネットワーク5における演算処理能力に存在すると考えられていた。ビザンチン耐性を備える構成である場合には,より多くの時間を要するため,このような傾向が顕著に現れる。一方,ビザンチン耐性を備えていない構成であっても,ビザンチン耐性を備える構成よりも処理時間を要しないものの,分散型台帳への記録という観点では,15同様な傾向を有している。
【0022】発明者は,様々な検証により,ブロックチェーンネットワーク5における演算処理能力にボトルネックが存在する状況は,極めて多くの処理が集中した場合であって,実際には,その前の段階,すなわちトランザクションのリクエストを送信する20側においてボトルネックが存在する場合が多いことの知見を得た。この知見に基づき,本発明の一実施形態におけるリクエスト制御システム1では,ブロックチェーンネットワーク5における演算処理能力にボトルネックが存在する段階までリクエストを送信するためのプロセスを多重化することで,処理量を向上させることができることがわかった。このようにして処理量を向上させるための構成および処理方25法について,順に説明する。
【0023】35 [2.ユーザ端末]ユーザ端末80は,一般ユーザが利用するスマートフォン,パーソナルコンピュータなどの端末である。この例では,ユーザ端末80において金融機関が提供するアプリケーションプログラムが起動されると,ユーザの指示によって自身の口座か5ら他の口座への振込処理等の手続が可能になっている。ユーザによって手続の指示がされると,ユーザ端末80は,その手続に応じたトランザクションの指示内容を含む電文を送信する。
【0024】[3.ブロックチェーンネットワーク]10ブロックチェーンネットワーク5は,P2P接続PPによって複数のノードが接続されている。図1においては,4つのノード510-1,510-2,510-3,510-4によってブロックチェーンネットワーク5が構成されているが,ノードの数は4つより少なくても多くてもよい。以下の説明において,それぞれのノードを区別せずに説明する場合には,単にノード510という。
15【0025】ノード510-1は,コンピュータ51-1と台帳53-1とを含む。台帳53-1は,各ノード510に分散される台帳のデータが記録される記録媒体である。
コンピュータ51-1では,分散型台帳技術を実現するためのプログラムがCPUによって実行される。コンピュータ51-1は,台帳53-1へのデータの記録処20理および読み出し処理を実行し,また,他のノード510-2,510-3,510-4において台帳のデータを分散して記録するための処理を実行する。この処理には,分散したデータの正当性を高めるための合意形成処理も含まれる。ここでは,ノード510-1を例として,その構成を説明したが,他のノード510-2,510-3,510-4においても,それぞれの構成は同様である。すなわち,いず25れかのノード510に対してトランザクションのリクエストがされると,そのトランザクションの内容が各ノード510における台帳にも記録される。
36 【0026】ブロックチェーンネットワーク5においては,上述のように台帳を分散して各ノード510で記録する方式が用いられているが,その過程における具体的な処理は,仕様(基盤ソフトウェア:上述したCPUによって実行されるプログラムに対応)5によって様々であって,公知の処理が適用されればよい。したがって,ブロックチェーンネットワーク5における各ノード510の処理の詳細は説明を省略する。この例では,ブロックチェーンネットワークは,管理主体が存在するコンソーシアム型(例えば,Qｕｏｒｕm,HｙｐeｒledgeｒFabｒic等)を想定しているが,管理主体が存在しないパブリック型(例えば,Eｔheｒeｕm等)であっても適用可能である。
10【0027】[4.リクエスト制御システム]リクエスト制御システム1は,プロセス生成装置11(生成部),負荷分散装置15(割当部)および通信装置18を含む。これらの装置は,いずれもCPUによってプログラムを実行することによって,以下に説明する機能をそれぞれ実現してい15る。これらの装置のうち,一部または全部は一体の装置として実現されてもよい。
【0028】[4-1.プロセス生成装置]プロセス生成装置11は,複数(この例では,予め設定されたn個)のプロセス110-1,110-2,・・・,110-nを生成する。以下の説明において,そ20れぞれのプロセスを区別せずに説明する場合には,単にプロセス110という。各プロセス110は,負荷分散装置15からトランザクションのリクエスト送信を割り当てられると,そのトランザクションについてのリクエストをノード510-1に対して送信する。この例では,いずれのプロセス110においても,リクエストの送信先は同一のノード(この例ではノード510-1)として決められている。
25なお,上述したように,ブロックチェーンネットワーク5において使用される仕様によって,リクエストの送信先として,複数のノード510が指定されてもよいし,37 プロセス110によって異なるノード510が指定されてもよいし,リクエスト毎に異なるノード510が指定されてもよい。
【0029】プロセス110は,リクエストの送信の結果,ブロックチェーンネットワーク55においてトランザクションが分散型台帳に記録されたことを検出すると,キューに入っている次に処理すべきトランザクションのリクエストを送信する。キューは,各プロセス110に割り当てられている。プロセス110は,分散型台帳に記録されたことを,ブロックチェーンネットワーク5からの通知により検出してもよいし,ブロックチェーンネットワーク5にアクセスすることによって検出してもよい。
10【0030】[4-2.通信装置]通信装置18は,ネットワークNWを介してユーザ端末80から電文を受信し,この電文に含まれるトランザクションの指示内容を負荷分散装置15へ送信する。
【0031】15[4-3.負荷分散装置]負荷分散装置15は,通信装置18からトランザクションの指示内容を受信すると,複数のプロセス110のいずれかに,そのトランザクションのリクエスト送信を割り当てる。負荷分散装置15は,割り当てたプロセス110のキューに,トランザクションの指示内容を登録する。上述したように,キューに登録されたトラン20ザクションは,そのキューに対応したプロセス110からブロックチェーンネットワーク5に対して,リクエストとして送信される。この例では,n個のプロセス110が生成されているため,プロセス多重度はn個となる。n個の具体的な値は,事前の設定処理によって予め設定される。設定処理については,後述する。
【0032】25[4-4.システムの動作]続いて,リクエスト制御システム1の動作について説明する。リクエスト制御シ38 ステム1の動作としては,主として,複数のプロセス110のいずれかにトランザクションを割り当てるための割当処理,および割り当てられたトランザクションのリクエストを送信するための送信処理を含む。
【0033】5[4-4-1.割当処理]図2は,本発明の一実施形態におけるリクエスト制御システムが実行する割当処理を示すフローチャートである。システムの管理者等によりリクエスト制御システム1における処理を開始する指示が入力されると,以下に説明する割当処理が実行される。プロセス生成装置11は,予め設定された数のプロセス110を起動(生10成)する(ステップS101)。通信装置18による電文の受信を待機する(ステップS103;Nｏ)。通信装置18により電文が受信される(ステップS103;Yeｓ)と,負荷分散装置15は,電文に含まれるトランザクションの指示内容を受け付ける(ステップS105)。負荷分散装置15は,複数のプロセス110から割り当ての対象となるプロセス110を特定し(ステップS107)そのプロセス1,1510にトランザクションのリクエストをする指示をする(ステップS109)この。
指示は,例えば,トランザクションの内容等を含む指示信号によって実現される。
ここで,負荷分散装置15は,例えば,ラウンドロビン方式により,複数のプロセス110から割り当ての対象となるプロセス110を特定する。なお,この方式はラウンドロビン方式に限らず,別のアルゴリズムを用いた方式であってもよい。
20【0034】システムの管理者等によりリクエスト制御システム1の処理を終了する指示がなければ(ステップS111;Nｏ),再びステップS103に戻って処理を続ける。一方,この処理を終了する指示があれば(ステップS111;Yeｓ),プロセス生成装置11がプロセス110を終了させ(ステップS113),割当処理が25終了される。
【0035】39 [4-4-2.送信処理]図3は,本発明の一実施形態におけるプロセスが実行する送信処理を示すフローチャートである。プロセス生成装置11によりプロセス110が起動されると,それぞれのプロセス110において,図3に示す送信処理が実行される。まず,プロ5セス110は,プロセス生成装置11によるプロセス終了の指示,または負荷分散装置15からトランザクションのリクエストを送信する指示を待機する(ステップS201;Nｏ,ステップS203;Nｏ)。プロセス終了の指示があった場合(ステップS201;Yeｓ)には,送信処理が終了される。
【0036】10一方,リクエストを送信する指示を受信した場合(ステップS203;Yeｓ),プロセス110は,送信するリクエストに電子署名の付加等の認証処理を行い(ステップS211),認証処理が施されたリクエストをブロックチェーンネットワーク5に送信する(ステップS213)。その後,プロセス110は,リクエストの送信の結果,ブロックチェーンネットワーク5においてトランザクションが分散型台15帳に記録されたことを検出することによって,処理の完了を確認するまで待機し(ステップS215;Nｏ),処理の完了を確認すると(ステップS215;Yeｓ),ステップS201に戻って処理を続ける。
【0037】以上のように,リクエスト制御システム1が動作することによって,プロセス12010の数に対応したリクエスト処理の多重化が実現される。後述のようにプロセス110の数が設定されているため,ブロックチェーンネットワーク5における演算処理能力がボトルネックになる前にリクエストの送信が制限され,効率的な分散型台帳の運用が可能となる。仮に,不安定要因により,ブロックチェーンネットワーク5における演算処理能力がボトルネックになる状態に移行したとしても,大きな25影響を生じないようにすることもできる。
【0038】40 [5.設定処理]続いて,プロセス生成装置11において生成されるプロセス110の数(プロセス多重度)を設定する処理について説明する。
【0039】図4は,本発明の一実施形態におけるリクエスト制御システムが事前設定をする5場合の構成を示すブロック図である。設定処理を行う場合におけるリクエスト制御システム1Aとしては,リクエスト制御システム1に対して,プロセス生成装置11A,指示生成装置38および設定装置39を含み,通信装置18を含まない構成が例示される。ここでは,プロセス生成装置11A,指示生成装置38および設定装置39について説明し,他の構成については,その説明を省略する。
10【0040】プロセス生成装置11Aは,設定装置39から指定された数のプロセス110を起動するとともに,各プロセス110においてトランザクションのリクエストを送信してから,ブロックチェーンネットワーク5においてトランザクションが分散型台帳に記録されたことを検出するまでの時間(以下,スループットという)を測定15する。この測定したスループットを設定装置39に送信する。
【0041】指示生成装置38は,設定装置39からの制御に基づいて,所定のトランザクションの指示を生成して,指示の内容を負荷分散装置15に送信する。この指示の内容は,通信装置18を介して受信する電文に基づくトランザクションの指示内容の20代わりとなるものである。
【0042】設定装置39は,プロセス生成装置11Aおよび指示生成装置38を制御して,プロセス多重度(プロセス110の数:m個)を変更しつつ,1プロセス当たりの平均スループットを測定する。これによって,設定装置39は,プロセス多重度と25平均スループットとの関係を取得する。設定装置39は,この関係を用いて,利用するブロックチェーンネットワーク5における最適なプロセス110の数を算出す41 る。この数は,上述したn個に相当するものとして,リクエスト制御システム1におけるプロセス生成装置11に設定される。
【0043】図5は,本発明の一実施形態におけるリクエスト制御システムが実行する設定処5理を示すフローチャートである。最初にブロックチェーンネットワーク5に接続する場合,ブロックチェーンネットワーク5における設定の変更(ソフトウェアのバージョンアップ等)があった場合等において,管理者等の指示により設定処理が実行される。まず,リクエスト制御システム1Aは,設定装置39の制御により,プロセス多重度を変化させながら(例えば徐々に増加させながら)平均スループット,10を測定する(ステップS501)。
【0044】図6は,本発明の一実施形態におけるプロセス多重度と平均スループットとの関係を説明する図である。プロセス多重度および平均スループットの絶対値については様々であるものの,多くのブロックチェーンネットワーク5において,このよう15な結果が得られることは,発明者による検証から得られた知見である。すなわち,プロセス多重度が低い場合,プロセス多重度の増加に伴い平均スループットは増加していく。一方,プロセス多重度が大きくなると,プロセス多重度が増加しても,平均スループットは増加しなくなっていく。すなわち,プロセス多重度が大きい値N2である場合の平均スループットの増加の割合は,プロセス多重度が小さい値N201(第1値)である場合の平均スループットの増加の割合(第1割合)よりも小さい。特定のプロセス多重度における平均スループットの増加の割合は,図6に示すグラフにおいて,そのプロセス多重度における傾き(微分値)に相当する。この増加の割合を,以下,増加率という。プロセス多重度の増加に対して,増加率が大きく減少し始めるとき(第2割合)のプロセス多重度が,図6に示す閾値Thn(第252値)に対応する。
【0045】42 このように,閾値Thnよりもプロセス多重度が小さい領域A1においては,ブロックチェーンネットワーク5における演算処理能力にボトルネックがあるのではなく,リクエストを送信する側の処理にボトルネックがある。一方,閾値Thnよりもプロセス多重度が大きい量器A2においては,プロセス多重度を増加させても,5平均スループットがほとんど増加しないことから,ブロックチェーンネットワーク5における演算処理能力にボトルネックがあることがわかる。
【0046】図5に戻って説明をつづける。リクエスト制御システム1A(設定装置39)は,プロセス多重度に対する平均スループットを測定した後に,各プロセス多重度にお10ける平均スループットの増加率を算出する(ステップS503)。この増加率は,図6に示すグラフにおいて,各プロセス多重度における傾きに相当する。そして,さらに,増加率の変化に基づく所定の演算式によって,閾値Thnが特定される(ステップS505)設定装置39は,。この閾値Thnよりも小さいプロセス多重度をプロセス110の数としてプロセス生成装置11に設定する。このようにプロセス15110の数を設定することにより,ブロックチェーンネットワーク5における演算処理能力にボトルネックを発生させずに,リクエストの送信側においてボトルネックを発生させることできる。したがって,プロセス生成装置11において不要なプロセス110を生成しないようにして,リクエスト制御システム1のリソースを効率的に用いることができる。
20【符号の説明】【0047】1,1A…リクエスト制御システム,5…ブロックチェーンネットワーク,11,11A…プロセス生成装置,15…負荷分散装置,18…通信装置,38…指示生成装置,39…設定装置,51…コンピュータ,53…台帳,80…ユーザ端末,25110…プロセス,510…ノード43 【図1】44 【図2】45 【図3】46 【図4】47 【図5】【図6】48 (別紙2)引用文献1の記載事項(抜粋)[167頁左欄1行ないし右欄5行目]51.はじめにブロックチェーン(Blｏckchain,BC)技術は,破壊的イノベーションとして金融やInｔeｒneｔｏfThingｓ(IｏT)等の非常に幅広い分野への応用が期待され,注目を集めている.例えば,金融分野では,従来は第三者機関を経由して実施されてきた取引を,BC技術を用いて利用者間(P2P)の直接取引で代替することで,取引コ10ストの削減ができると期待されている.文献[1]では,様々な分野にBC技術を応用することで,将来的に日本国内の67兆円もの市場が影響を受ける可能性があるという試算結果が示されている.BC技術に大きな期待が集まっている一方で,現状ではセキュリティ面やシステム性能面をはじめ,エンタープライズでの実適用には課題が多いといわれている.15そのため,BCの実適用に向けては,BC基盤やそのオープンソースソフトウェア(OｐenSｏｕｒceSｏfｔｗaｒe,OSS)実装における現時点での技術課題の明確化が必要である.そこで本研究では,BC基盤のOSSプロジェクトであるHｙｐeｒledgeｒ[8]の基盤実装の一つであるFabｒic[11]について性能を中心とした評価を行い,BC基盤お20よびFabｒicの現時点での実力を明らかにするとともに,技術的な課題を抽出にすることを目的とする.[168頁右欄5ないし26行目]2.2BC基盤HｙｐeｒledgeｒFabｒic25Hｙｐeｒledgeｒプロジェクトは,LinｕｘFｏｕndaｔiｏnが設立したエンタープライズで利用可能なOSSのBC基盤の開発を目的としたプロジェクトである[8].同プ49 ロジェクトは,2016年2月に設立され,金融機関をはじめとしたユーザ企業やITベンダー等,計100社以上が参画している.弊社も,同プロジェクトの設立時からプレミアメンバーとして参画し,コミュニティ活動に参加している.Hｙｐeｒledgeｒプロジェクトでは,BCのユースケース,基盤の機能要件およびア5ーキテクチャがホワイトペーパーにまとめられている[9].また,その実現に向けて,複数のベンダーから基盤実装が提案されている.IBM社とDAH(DigiｔalAｓｓeｔHｏldingｓ)社の共同提案であるFabｒic[11]はその基盤実装の一つである.Fabｒicは2016年4月に公開され,2017年1月現在で開発者プレビュー版ｖ0.6までリリースされている.Fabｒicは前述のホワイトペーパーに対応したアーキテ10クチャを実装している.Fabｒicは,様々な分野でのユースケースに対応可能とするために汎用性の高いBC基盤機能を提供する.また,現在は,コンソーシアムあるいはプライベート型での利用を想定したBC基盤となっている.Fabｒicの主な機能的特徴として,具体的には以下が挙げられる.15[168頁右欄36行ないし169頁左欄4行目]図1は,公式ドキュメントに示されるFabｒicのアーキテクチャである.公式ドキュメントの記載内容に従って,Fabｒicの主要な構成要素を説明する。
・メンバーシップサービス:BCネットワークへの参加者,スマートコントラクト,20合意形成を行う検証ノード等,ネットワーク上の全オブジェクトのIDを管理する.・BCサービス:P2Pプロトコル,分散台帳,コンセンサスマネージャといった要素によって構成される.P2Pプロトコルにより,P2Pでの双方向ストリーミング,フロー制御,リクエストの多重化といった機能を提供する。既存ネット25ワークと連携して動作する。分散台帳により,BCと,台帳の(最新)状態を管理する。コンセンサスマネージャにより,プラグイン可能な合意形成アルゴリズ50 ム用のインタフェースを提供する。
・チェーンコードサービス:スマートコントラクトを実行する軽量でセキュアな実行環境を提供する。
5[169頁左欄29ないし33行目]2.3本研究の課題BCの実適用に向けては,BC基盤およびその実装における現時点での技術課題の明確化が必要である.特に,金融業務への適用に向けては,一般的にトランザクションのスループットが性能面の最重要指標である.10[169頁右欄9ないし38行目]3.HｙｐeｒledgeｒFabｒicの評価3.1評価の目的FabｒicおよびBC基盤の課題抽出に向けて,以下を主な目的として評価を行う.15目的1:Fabｒicの現実装における実力(主に性能)の把握Fabｒicは公開されて間もないため,その品質(特に非機能面)が未知数であった.そのため,実機上に環境を構築して動作検証を行い,さらには性能を測定することで,Fabｒicの現実装における実力を把握する必要がある.性能評価においては,より本格的なBCネットワークを構築することが望ましい.20目的2:Fabｒic/BC基盤の性能ボトルネック抽出方法の検討性能限界や傾向を把握するためには,そのボトルネック箇所を特定することが重要である.しかし,Fabｒicでは,そのような調査や分析を行う手段が整備されていない.そのため,性能ボトルネックの抽出方法の検討が必要である.Fabｒic自体のバージョンアップ時等には,再度性能評価を行うことが予想されるため,ボトルネ25ック抽出は繰り返し実行できるようにシステム化することが望ましい.3.2評価方法51 3.2.1概要先に示した評価の目的1と2を達成するために,以下の評価方針を採用した.目的1の達成に向けた方針性能評価に適した本格的な評価環境として,マルチホスト上にまたがった環境上5にFabｒicによるBCネットワークを構築し,その上で性能測定を行う.目的2の達成に向けた方針Fabｒic(およびBC基盤)の性能ボトルネックを容易に抽出可能とするためのモニタリング環境も合わせて整備する.10[171頁左欄3ないし23行目]3.2.3測定方法クライアントからREST経由でBCネットワークにアクセスし,チェーンコードを実行して負荷をかけることで性能測定を行った.チェーンコードには,Fabｒicの公式プロジェクトに付属のサンプルチェーンコード「maｐ」を利用する.本サ15ンプルチェーンコードは簡易キーバリューストアとして動作する.なお,負荷をかける際には,複数のクライアントからの同時アクセスを模擬するため,マルチスレッドでトランザクションを並列実行した.クライアントによる負荷生成ツールプログラムの処理の流れは以下のとおりである.201.ユーザログイン(セキュリティ機能ON時のみ)2.maｐチェーンコードをBC上にデプロイ3.スレッド毎に実行トランザクション(inｖｏke)を指定した回数繰り返す(並列実行)4.全スレッドの実行トランザクションが完了するまで(レスポンスがかえって25くるまで)待つ5.スレッド毎に参照トランザクション(ｑｕeｒｙ)を指定した回数繰り返す(並52 列実行)6.全スレッドの参照トランザクションが完了するまで(レスポンスがかえってくるまで)待つ5[171頁左欄24行ないし右欄7行目]ここで,今回の測定におけるトランザクションのスループット計算方法は以下のとおりである.スループット(tx/s)全スレッドによる合計リクエスト件数10=――――――――――――――――――――――――――――全レスポンスが返ってきた時刻-リクエスト処理を開始した時刻3.2.4実験パラメータ今回の測定で利用した実験パラメータ表3のとおりである.これらは性能に与える影響が特に大きいと想定したパラメータである.セキュリティ機能OFFとON15時のそれぞれの場合で測定した。ON時には,メンバーシップサービスを利用して,ネットワークへの参加ノードの認証やトランザクションの秘匿化が行われる.一方,OFF時にはメンバーシップサービスは利用されず,認証や秘匿化は行われない.[171頁右欄27ないし39行目]203.3結果と考察図3にセキュリティ機能OFF時の,図4にセキュリティ機能ON時のinｖｏke/ｑｕeｒｙスループット測定結果を示す.図に示す通り,セキュリティ機能OFF/ON時ともに,inｖｏkeとｑｕeｒｙの両方で,並列スレッド数を増やしていくとスループットも増加する傾向にあった.ただし,ある程度並列度を増やすとスループット25は頭打ちとなった.また,スループットが頭打ちになった後も,それ以上に並列度を増やしていくと,53 内部的にエラーが発生する等,安定稼働が困難となる場合が見受けられた.つまり,高負荷を与えた場合には,挙動が安定しなくなる場合があるため,フロント側でリクエストの流量制御を行う等の対策が必要となり得る.54 [170頁図2]55 [171頁表3]表3実験パラメータTable3Paｒameｔeｒｓｏfeｘｐeｒimenｔｓパラメータ設定値のパターンセキュリティ機能OFF,ON合意形成アルゴリズムBaｔchPBFT(バッチサイズ=2)クライアントのスレッド数1,2,4,6,8,10,12,･･･スレッドあたりの1000(セキュリティ機能OFF)リクエスト数200(セキュリティ機能ON)56 [172頁図3]及び[172頁図4]57 (別紙3)引用文献2の記載事項(抜粋)5【0008】プロセッサー11は,画像形成装置10の動作に必要な演算及び制御などの処理を行うコンピューターの中枢部分に相当する。プロセッサー11は,ROM12又は補助記憶デバイス14などに記憶されたシステムソフトウェア,アプリケーションソフトウェア又はファームウェアなどのプログラムに基づいて,画像形成装置1100の各種の機能を実現するべく各部を制御する。プロセッサー11は,例えば,CPU(cenｔｒalｐｒｏceｓｓingｕniｔ),MPU(micｒｏｐｒｏceｓｓingｕniｔ),SｏC(ｓｙｓｔemｏnachiｐ),DSP(digiｔalｓignalｐｒｏceｓｓｏｒ)又はGPU(gｒaｐhicｓｐｒｏceｓｓingｕniｔ)などである。あるいは,プロセッサー11は,これらの組み合わせである。プロセッサー11は,好ましくは,マルチコアCPU,又はGPUとC15PUとを備えるプロセッサーである。複数のコアを備えるプロセッサーは,マルチスレッド又はマルチプロセスなどの並行処理を並列処理することで高速に処理することが可能なためである。なお,並行処理とは,複数のスレッド又はプロセスなどを,時分割などによって切り替えながら同時的に処理すること,あるいは並列処理することなどである。また,並列処理とは,複数のスレッド又はプロセスなどを,20複数のコアで同時に処理することなどである。
【0067】プロセッサー11は,上記の実施形態においてマルチスレッドで行っている処理をマルチプロセスで行っても良い。
58 (別紙4)引用文献3の記載事項(抜粋)【0045】5並列処理の手法としては,マルチスレッドやマルチプロセスを用い,又はプログラム内での繰返し処理によって行うことができる。図9は,経路多重度3の場合の疎通確認をマルチスレッドで行う一例を示している。このスレッドは,経路多重度数だけ起動され,第1の多重経路のスレッドと第2の多重経路のスレッドと第3の多重経路のスレッドとで,それぞれ異なる疎通経路について同時に疎通確認を行う。
59 (別紙5)甲4文献の記載事項(抜粋)【0002】5情報処理装置(コンピュータ)は,例えば,コンピュータプログラム(略してプログラムとも記す)を実行する際に,プログラムを実行する単位である複数のプロセスを生成する。さらに,このような場合には,情報処理装置は,プロセス内に,処理を実行する単位である複数のスレッドを生成する。
【0018】10<第1実施形態>図1は,本発明に係る第1実施形態の情報処理装置の構成を簡略化して表すブロック図である。第1実施形態の情報処理装置101は,例えばCPU(CenｔｒalPｒｏceｓｓingUniｔ)102を備えたコンピュータである。CPU102は,記憶装置(図示せず)に格納されているコンピュータプログラム(プログラム)を読み出し15当該プログラムを実行することによって,情報処理装置101の全体的な動作を制御する。
【0019】この第1実施形態では,情報処理装置101(CPU102)は,プログラムを実行する単位である複数のプロセスを生成する。プロセスは,CPU102の機能20部の一つであり,当該プロセスの動作(処理)を管理する機能を備えている。例えば,プロセス(CPU102)は,当該プロセスが受けたリクエストに応じた処理を実行する単位であるスレッドを生成(設定)する。プロセスは,通常,複数の処理を実行することから,複数のスレッドを生成可能となっている。当該プロセスが持つことができるスレッドの上限数は予め設定されている。
25【0064】図3は,第4実施形態の情報処理装置の構成を簡略化して表すブロック図である。
60 この第4実施形態の情報処理装置は,サーバ装置(コンピュータ)10であり,情報通信網(ネットワーク)70を介して複数のクライアント端末30に接続されている。また,サーバ装置10はデータベース60に接続されている。
【0065】5クライアント端末30は,利用者が情報を入力するためのキーボード等の入力手段と,各種の情報を表示するためのディスプレイ等の出力手段とを備える。ここで,クライアント端末30としては,例えば,パーソナルコンピュータ(パソコン),タブレット型端末またはPDA(PeｒｓｏnalDigiｔalAｓｓiｓｔanｔ)端末が考えられるが,これらに限定されない。
10【0066】サーバ装置10は通信部40を備えており,当該通信部40によって,サーバ装置10は,クライアント端末30とデータの送受信を行う。
【0067】サーバ装置10は,さらに,例えばCPUを有し,当該CPUにより実現される15機能部として,プロセス11と,障害対策部100とを備えている。さらに,サーバ装置10は,記憶媒体であるメモリ50を備えている。
【0068】プロセス11は,コンピュータプログラム(プログラム)の実行単位であり,プログラムを実行する際に生成される。この生成されるプロセス11には,メモリ5200内に,専用の記憶領域が割り当てられる。なお,サーバ装置10には,通常,複数のプロセス11が生成されるが,ここでは,図示の簡略化のために,一つのプロセス11のみ表すこととする。
【0069】プロセス11は,管理部13を備えている。この管理部13は,プロセス11の25動作を管理する機能を備えている。例えば,管理部13は,プロセス起動時に,予め初期値として定められた複数の待機状態のスレッド12を生成する。また,管理61 部13は,各スレッド12に,各スレッド12を識別するスレッド識別情報を付与する。さらに,管理部13は,プロセス11に対して割り当てられたメモリ50内の記憶領域から,それら生成した各スレッド12に,予め定められた容量を持つ記憶領域を割り当てる。
5【0072】通信部40は,クライアント端末30から受け取ったリクエストを,複数のプロセス11のうちの何れのプロセスに渡すかを判断する機能を備えている。リクエストとは,例えば,データベース60内のデータを検索する要求や,データを更新する要求である。
1062 【図3】63 (別紙6)参考図164 (別紙7)参考図265
すごい知財EXPO'22