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