【事件の表示】
　特願２００７−５２７９５４「モジュラー型のイベントドリブン処理」拒絶査定不服審判事件〔平成１８年　３月　２日国際公開、ＷＯ２００６／０２３５０６、平成２０年　４月　３日国内公表、特表２００８−５１０２５９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　
　本願は，２００４年８月１７日（以下「優先日」という。）の米国への出願を基礎とするパリ条約による優先権主張をともない，２００５年８月１５日を国際出願日とする出願であって，
平成１９年２月１６日付けで特許法第１８４条の５第１項の規定による書面が提出され，
平成１９年４月１３日付けで特許法第１８４条の４第１項の規定による特許請求の範囲，明細書，図面（図面の中の説明に限る），要約書の日本語による翻訳文が提出され，
平成２０年８月１４日付けで審査請求がなされ，
平成２３年６月２９日付けで拒絶理由通知（同年７月４日発送）がなされ，
同年１０月４日付けで意見書が提出されるとともに，同日付けで手続補正がなされたが，
同年１０月２１日付けで拒絶査定（同年１０月２５日謄本送達）がなされ，
平成２４年２月２４日付けで審判請求がされたものである。
　
　
第２　本願発明
　
　本願の請求項１に係る発明は，平成２３年１０月４日付けの手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。（以下「本願発明」という。）
　
　「イベントを処理する方法において，
　複数のスレッド境界の中の第１スレッド境界における負荷を判定するステップであって，前記複数のスレッド境界は，１つ又は複数のイベント用のサービスを実行可能であり，前記複数のスレッド境界の中のそれぞれのスレッド境界は，少なくとも１つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも１つのタスクを含んでいる，ステップと，
　前記判定された負荷に基づいて，１つ又は複数のリソースを前記第１スレッド境界に対して動的に割り当てるステップであって，前記１つ又は複数のリソースにより，前記第１スレッド境界の前記少なくとも１つのタスクは，前記少なくとも１つのタスクと関連付けられている前記サービスの少なくとも一部を実行可能である，ステップと，
を有し，
　前記第１のスレッド境界における負荷は，前記第１のスレッド境界に結合された第１のスレッド境界キューにおいて保持されているイベントの数と前記第１のスレッド境界と第２のスレッド境界の間に結合された第２のスレッド境界キュー内に保持されているイベントの数との比較に基づいて判定されることを特徴とする方法。」
　
第３　先行技術
　本願の出願前の優先日よりも前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である上記平成２３年６月２９日付けの拒絶理由通知において引用された，下記引用文献には，関連する図面とともに，それぞれ下記の事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
　
＜引用文献１＞
　Welsh,M.,Gribble,S.D.,Brewre,E.A., and Culler,D.，“A Design Framework for Highly Concurrent Systems”，Technical Report，EECS Department， Univ. of California，Berkeley，２０００年，UCB/CSD-00-1108，ＵＲＬ，http://www.eecs.berkeley.edu/Pubs/TechRpts/2000/CSD-00-1108.pdf
　　　
　Ａ「1 Introduction
　
Large Internet services must deal with concurrency at an unprecedented scale.
As the demand for Internet services grows, as does their functionality, new system design techniques must be used to manage this load.
・・・（中略）・・・
　That threads and events are best viewed as the opposite ends of a design spectrum; the key to developing highly concurrent systems is to operate in the middle of this spectrum. Event-driven techniques are useful for obtaining high concurrency, but when building real systems, threads are valuable (and in many cases required) for exploiting multiprocessor parallelism and dealing with blocking I/O mechanisms. Most developers are aware that this spectrum exists, by utilizing both thread and event-oriented approaches for concurrency. However, the dimensions of this spectrum are not currently well understood.
　
We propose a general-purpose design framework for building highly concurrent systems. The key idea behind our framework is to use event-driven programming for high throughput, but leverage threads (in limited quantities) for parallelism and ease of programming.
（当審訳：
「1　はじめに
　
大規模なインターネットサービスは，前例のない規模での並行処理に対処する必要がある。
インターネットサービスの需要が拡大するにつれ，その機能性など，新たなシステム設計技術が，この負荷を管理するために用いられなければならない。
・・・（中略）・・・
　そのスレッドとイベントは，デザイン領域の両端として最善のものと見なされている：同時実行性の高いシステムを開発するための鍵は，この領域の真ん中で動作させることである。イベントドリブン技術は，高い同時実行性を得るために有用であるが，実際のシステムを構築する場合，スレッドは，マルチプロセッサの並列処理を利用したり，I/Oメカニズムのブロックに対処するために（そして必要な多くの場合）貴重なものである。ほとんどの開発者は，この領域が存在することを認識しており，それは，同時実行性のために，スレッドとイベント指向のアプローチの両方を利用するものである。しかし，この領域の広がりは，現在よく理解されていない。
　
我々は，同時実行性の高いシステムを構築するための，汎用設計フレームワークを提案する。我々のフレームワークの背後にある主要なアイデアは，高スループットのためにイベントドリブン型のプログラミングを用いるが，並行処理とプログラミングの容易さのために（数量が限定された）有効スレッドを活用することである。
　
　Ｂ「2.3 The Thread and Event Spectrum
　
Although highly concurrent services provide new fuel for the debate over threads and events, a key observation is that the design space for concurrency isn't limited to these two points. Rather, there is a spectrum between these extremes and it is possible to build hybrid systems that strategically exploit properties of both.
　
The simplest example of a hybrid thread and event server is shown in Figure 6. It limits the number of concurrent threads running in the system to no more than T threads in a preallocated thread pool, and buffers incoming tasks in an event queue from which the thread pool feeds.
（当審訳：
「2.3　スレッド・イベント　領域
　
同時実行性の高いサービスは，スレッドとイベントをめぐる議論に新たに動機を与えることになるが，重要なのは，同時実行性のための設計空間がこの２点に限定されないということである。むしろ，これらの両極端の間に領域が存在し，戦略的に両方の特性を利用するハイブリッドなシステムを構築することが可能である。
　
スレッドとイベントのハイブリッドなサーバとして，最も簡易な例を図６に示す。それは，システムで実行中の同時スレッドの数が，事前に割り当てられたスレッドプール内のＴ個のスレッドを超えないように制限し，そしてそのスレッドプールが受け入れるイベントキューへの入力タスクをバッファする。
　　
　Ｃ「Figure 6」として以下の図，及びその説明が示されている。
　
　
「Figure 6: A hybrid thread and event system: 
This server uses a constant-size thread pool of T threads to service tasks with an arrival rate of A from an incoming task queue
（当審訳：
「図６：スレッドとイベントのハイブリッドなシステム：
このサーバは，入力タスクキューからの到着率に合わせて，サービスタスクへＴ個のスレッドからなる一定サイズのスレッドプールを使用しており，
　
　Ｄ「3.1.2 Thread pools
　
A thread pool is a collection of threads on the same machine that operate by continually processing tasks. Logically, a thread pool is associated with a set of task types, and each thread in the pool executes a piece of code that consumes a task, processes it, and dispatches one or more outgoing tasks to a thread pool.
　Thread pools are the only source of execution contexts within our framework. Modularity is accomplished by structuring applications as a set of thread pools each processing a particular set of task types. Parallelism can be exploited since each thread can run on a separate CPU in a multiprocessor system.
3.1.3 Queues
　
Queues are the means of communication between thread pools.
thread pools pull tasks from their incoming task queue, and dispatch tasks by pushing them onto the incoming queues of thread pools.
The operation of two thread pools can be composed by inserting a queue between them, thereby allowing tasks to pass from one to the another.
　
Queues act as the separation mechanism between thread pools, by introducing an explicit control boundary. Because a thread cannot cross over this boundary(it can only pass data across the boundary by enqueuing a task), it is possible to constrain the execution of threads to a given task handler.
　
In addition, queues provide a mechanism for overflow absorption, backpressure, and fairness.
ueues act to buffer incoming tasks when their number outweighs the number of threads available to process them.
Backpressure
important as it allows excess load to be rejected by the system, rather than buffering an arbitrary amount of work.
Fairness can be accomplished by scheduling thread pools based on their incoming queue length.
（当審訳：
「3.1.2　スレッドプール
　
スレッドプールは，継続的にタスクを処理することで動作する同じマシン上でのスレッドの集まりである。論理的には，スレッドプールは，タスクタイプのセットと関連付けられ，プール内の各スレッドは，タスクを消費し，処理し，及び，スレッドプールに１つ以上の送出タスクをディスパッチするよう，一つのコードを実行する。
　スレッドプールは，我々のフレームワークの中で実行コンテキストの唯一の供給源である。モジュール性は，それぞれが特定の組のタイプのタスクを処理するような複数のスレッドプールの組として，アプリケーションを構築することによって，達成される。各スレッドは，マルチプロセッサシステム内の別々のＣＰＵ上で実行することができることから，並列性が実現可能となる。
3.1.3　キュー
　
キューは，スレッドプールの間の通信手段である。
スレッドプールは，入力タスクキューからタスクを抜き出すと，それらをスレッドプールの入力キューに送り込むことでタスクをディスパッチする。２つのスレッドプールの動作は，それらの間にキューを挿入し，それによってタスクを一方から他方に通過させることによって，成り立たせることができる。
　
キューは，複数のスレッドプール間において分離したメカニズムとして機能し，それは明示的な制御の境界を導入することでなされる。スレッドがこの境界を超えることができないので（それは，タスクをキューに入れることによってのみ，境界を越えてデータを渡すことができる。），
　
さらに，キューはオーバーフローの吸収，バックプレッシャー，及び公平性のためのメカニズムを提供する。キューは，入力タスクの数が，それらを処理するために使用可能なスレッドの数を上回るとき，その入力タスクをバッファするように働く。バックプレッシャーは，
作業の任意の量をバッファするのではなく，過剰な負荷をシステムによって拒否できることから重要である。公平性は，その入力キューの長さに基づいてスレッドプールをスケジューリングすることによって，達成することができる。
　
　Ｅ「3.2 Design Patterns
　We turn now to the question of how to map an application onto an implementation using the components presented above. The decision of where thread pools and queues are used has an important impact on the performance and fault-tolerance properties of the resulting application.
　We propose four design patterns that can be applied to construct an application using our framework.These patterns encapsulate fundamental properties of our framework components and describe how to build up an application using them.
・・・（中略）・・・
3.2.2 Pipeline
　
The Pipeline pattern takes a single-threaded piece of code and splits it into multiple pipeline stages by introducing a queue and thread pool boundary at various points.
・・・（後略）」（第６頁目右欄１８行〜第７頁目左欄２１行，「3.2 Design Patterns」の欄）
（当審訳：
「3.2　デザインパターン
　さて我々は，上記にて提示したコンポーネントを使用した実装において，如何にアプリケーションをマッピングするかの問題に取りかかる。スレッドプールとキューをどこで使用するかという決定は，成果物であるアプリケーションの，パフォーマンスとフォールト・トレラントという特性に重要な影響を持っている。
　我々は，我々のフレームワークを使ったアプリケーションの構築に適用することができる，４つのデザインパターンを提案する。これらのデザインパターンは，我々のフレームワークのコンポーネントの基本的な性質をカプセル化し，それらを使用してアプリケーションを如何に構築するかについて記述している。
・・・（中略）・・・
3.2.2　パイプライン
　
パイプラインのパターンは，シングルスレッドとしてのコードを取り，様々なポイントでキューとスレッドプール境界を導入することにより，それを複数のパイプラインのステージへ分割する。
　
　Ｆ「Figure 9」として以下の図，及びその説明が示されている。　
　
　
「Figure 9: An application resulting from the use of the design patterns. Data flows from left to right, with tasks entering the application at the leftmost queue. Dashed boxes represent machine boundaries. Each design pattern is labelled below its use.」（「Figure 9」の説明）
（当審訳：
「図9：デザインパターンを用いた結果のアプリケーション。タスクが左端のキューでアプリケーションに入力されながら，データは左から右に流れる。破線のボックスは，マシン境界を表す。各デザインパターンは，その使用の下でラベル付けされる。」）
　
　以下に，上記引用文献１の記載事項について検討する。
　
（ア）引用文献１は，
　上記Ａに「Large Internet services must deal with concurrency at an unprecedented scale.（大規模なインターネットサービスは，前例のない規模での並行処理に対処する必要がある。）」，「As the demand for Internet services grows, as does their functionality, new system design techniques must be used to manage this load.（インターネットサービスの需要が拡大するにつれ，その機能性など，新たなシステム設計技術が，この負荷を管理するために用いられなければならない。）」との記載があるとおり，“大規模なインターネットサービスに対し，新たな設計技術によるシステムを用いて，負荷を管理する”こと，及びそのための方法について説明ないし示唆するものであり，
　また上記“新たな設計技術によるシステム”に関し，上記Ａの「We propose a general-purpose design framework for building highly concurrent systems. The key idea behind our framework is to use event-driven programming for high throughput, but leverage threads (in limited quantities) for parallelism and ease of programming.（我々は，同時実行性の高いシステムを構築するための，汎用設計フレームワークを提案する。我々のフレームワークの背後にある主要なアイデアは，高スループットのためにイベントドリブン型のプログラミングを，そして並行処理とプログラミングの容易さのために（数量が限定された）有効スレッドを使用することである。）」との記載，上記Ｂの「Although highly concurrent services provide new fuel for the debate over threads and events, a key observation is that the design space for concurrency isn't limited to these two points. Rather,there is a spectrum between these extremes and it is possible to build hybrid systems that strategically exploit properties of both.（同時実行性の高いサービスは，スレッドとイベントをめぐる議論に新たに動機を与えることになるが，重要なのは，同時実行性のための設計空間がこの２点に限定されないということである。むしろ，これらの両極端の間に領域が存在し，戦略的に両方の特性を利用するハイブリッドなシステムを構築することが可能である。）」，「The simplest example of a hybrid thread and event server is shown in Figure 6. It limits the number of concurrent threads running in the system to no more than T threads in a preallocated thread pool, and buffers incoming tasks in an event queue from which the thread pool feeds.（スレッドとイベントのハイブリッドなサーバとして，最も簡易な例を図6に示す。それは，システムで実行中の同時スレッドの数が，事前に割り当てられたスレッドプール内のＴ個のスレッドを超えないように制限し，そしてそのスレッドプールが受け入れるイベントキューへの入力タスクをバッファする。）」との記載から，イベントドリブン型のプログラミングとスレッドの両方の特性を利用して，スレッドプールが受け入れるイベントキューへの入力タスクをバッファリングするよう構成したシステム，を用いることが記載されているといえ，
　したがって，引用文献１には，
　“大規模なインターネットサービスに対し，イベントドリブン型のプログラミングとスレッドの両方の特性を利用して，スレッドプールが受け入れるイベントキューへの入力タスクをバッファリングするよう構成したシステムを用いて，負荷を管理する方法”が記載されているといえる。
　
（イ）前記「システム」に関し，
　上記Ｂの「The simplest example of a hybrid thread and event server is shown in Figure 6. It limits the number of concurrent threads running in the system to no more than T threads in a preallocated thread pool, and buffers incoming tasks in an event queue from which the thread pool feeds.（スレッドとイベントのハイブリッドなサーバとして，最も簡易な例を図6に示す。それは，システムで実行中の同時スレッドの数が，事前に割り当てられたスレッドプール内のＴ個のスレッドを超えないように制限し，そしてそのスレッドプールが受け入れるイベントキューへの入力タスクをバッファする。）」との記載，上記Ｃで示した「Figure 6」の態様，及び同「Figure 6」の説明として「This server uses a constant-size thread pool of T threads to service tasks with an arrival rate of A from an incoming task queue（このサーバは，入力タスクキューからの到着率に合わせて，サービスタスクへＴ個のスレッドからなる一定サイズのスレッドプールを使用しており）」との記載から，
　前記“システム”は，
“スレッドプール”，及び，“キュー”を備えることがよみとれる。
　
（ウ）上記「スレッドプール」に関し，
　上記Ｄの「A thread pool is a collection of threads on the same machine that operate by continually processing tasks. Logically, a thread pool is associated with a set of task types, and each thread in the pool executes a piece of code that consumes a task, processes it, and dispatches one or more outgoing tasks to a thread pool.（スレッドプールは，継続的にタスクを処理することで動作する同じマシン上でのスレッドの集まりである。論理的には，スレッドプールは，タスクタイプのセットと関連付けられ，プール内の各スレッドは，タスクを消費し，処理し，及び，スレッドプールに１つ以上の送出タスクをディスパッチするよう，一つのコードを実行する。）」との記載から，
　前記“スレッドプール”は，“タスクを処理するスレッドの集まりであり，各スレッドは，タスクを消費し，処理し，及び，スレッドプールに1つ以上の送出タスクをディスパッチするよう，コードを実行するものである”ことがよみとれる。
　また，上記「キュー」に関し，
　上記Ｄの「Queues are the means of communication between thread pools.（キューは，スレッドプールの間の通信手段である。）」，「The operation of two thread pools can be composed by inserting a queue between them, thereby allowing tasks to pass from one to the another.（２つのスレッドプールの動作は，それらの間にキューを挿入し，それによってタスクを一方から他方に通過させることによって，成り立たせることができる。）」との記載から，
　前記“キュー”は，“２つのスレッドプールの間をつなぐ通信手段であり，２つのスレッドプールの間にキューを挿入することによって，データを２つのスレッドプールの一方から他方に通過させて渡すことを実現する”ことがよみとれる。
　してみると，
　前記“システム”は，
“タスクを処理するスレッドの集まりであり，各スレッドは，タスクを消費し，処理し，及び，スレッドプールに１つ以上の送出タスクをディスパッチするよう，コードを実行するものである，スレッドプールと，
　２つのスレッドプールの間を接続する通信手段であり，２つのスレッドプールの間にキューを挿入することによって，データを２つのスレッドプールの一方から他方に通過させて渡すことを実現する，キュー”を備えることがよみとれる。
　
（エ）上記“スレッドプール”，及び，“キュー”に関し，
　上記Ｄの「3.1.3 Queues」についての記載，上記Ｅの記載，及び上記Ｆの記載は，２つの「スレッドプール」を，「キュー」により接続するための構成について説明しているところ，
　上記Ｄの「The operation of two thread pools can be composed by inserting a queue between them, thereby allowing tasks to pass from one to the another.（２つのスレッドプールの動作は，それらの間にキューを挿入し，それによってタスクを一方から他方に通過させることによって，成り立たせることができる。）」，「Queues act as the separation mechanism between thread pools, by introducing an explicit control boundary. Because a thread cannot cross over this boundary(it can only pass data across the boundary by enqueuing a task)，（キューは，複数のスレッドプール間において分離したメカニズムとして機能し，それは明示的な制御の境界を導入することでなされる。スレッドがこの境界を超えることができないので（それは，タスクをキューに入れることによってのみ，境界を越えてデータを渡すことができる。），）」，「In addition, queues provide a mechanism for overflow absorption, backpressure, and fairness. ・・・Fairness can be accomplished by scheduling thread pools based on their incoming queue length.（さらに，キューはオーバーフローの吸収，バックプレッシャー，及び公平性のためのメカニズムを提供する。・・・公平性は，その入力キューの長さに基づいてスレッドプールをスケジューリングすることによって，達成することができる。）」との記載，上記Ｅの「The Pipeline pattern takes a single-threaded piece of code and splits it into multiple pipeline stages by introducing a queue and thread pool boundary at various points.（パイプラインのパターンは，シングルスレッドとしてのコードを取り，様々なポイントでキューとスレッドプール境界を導入することにより，それを複数のパイプラインのステージへ分割する。）」との記載，及び，上記Ｆで示した「Figure 9」における「Pipeline」に関する態様から，
　前記“システム”は，
　“制御の境界を導入することで，２つのスレッドプール境界と，その間に接続される分離したメカニズムとしてのキューと，により複数のパイプラインのステージを構成”することがよみとれる。
　
（オ）上記Ｄの「thread pools pull tasks from their incoming task queue, and dispatch tasks by pushing them onto the incoming queues of thread pools.（スレッドプールは，入力タスクキューからタスクを抜き出すと，それらをスレッドプールの入力キューに送り込むことでタスクをディスパッチする。）」との記載から，
　前記“システム”は，
　“スレッドプールは，入力タスクキューからタスクを抜き出すと，それらをスレッドプールの入力キューに送り込むことでタスクをディスパッチ”することがよみとれる。
　
（カ）上記Ｄの「In addition, queues provide a mechanism for overflow absorption, backpressure, and fairness.・・・Fairness can be accomplished by scheduling thread pools based on their incoming queue length.（さらに，キューはオーバーフローの吸収，バックプレッシャー，及び公平性のためのメカニズムを提供する。・・・公平性は，その入力キューの長さに基づいてスレッドプールをスケジューリングすることによって，達成することができる。）」との記載から，
　前記“システム”は，
　“入力キューの長さに基づいてスレッドプールをスケジューリングする”ことがよみとれる。
　
　以上，（ア）ないし（カ）を踏まえると，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
　大規模なインターネットサービスに対し，イベントドリブン型のプログラミングとスレッドの両方の特性を利用して，スレッドプールが受け入れるイベントキューへの入力タスクをバッファリングするよう構成したシステムを用いて，負荷を管理する方法であって，
　タスクを処理するスレッドの集まりであり，各スレッドは，タスクを消費し，処理し，及び，スレッドプールに１つ以上の送出タスクをディスパッチするよう，コードを実行するものである，スレッドプールと，
　２つのスレッドプールの間を接続する通信手段であり，２つのスレッドプールの間にキューを挿入することによって，データを２つのスレッドプールの一方から他方に通過させて渡すことを実現する，キューと，
　を備え，
　制御の境界を導入することで，２つのスレッドプール境界と，その間に接続される分離したメカニズムとしての前記キューと，により複数のパイプラインのステージを構成し，
　前記スレッドプールは，入力タスクキューからタスクを抜き出すと，それらを前記スレッドプールの入力キューに送り込むことでタスクをディスパッチし，
　入力キューの長さに基づいて前記スレッドプールをスケジューリングする，
　ことを含む方法。
　
＜引用文献２＞
　Welsh,M., and Culler,D.，“Adaptive Overload Control for Busy Internet Servers”，Proc. of the 4th USENIX Conf. on Internet Technologies and Systems ，２００３年３月２６日
　
　Ｇ「2 The Staged Event-Driven Architecture
Our overload management techniques are based on the 
staged event-driven architecture (or SEDA)
2.1 SEDA Overview
・・・（中略）・・・
　As shown in Figure 2, 
a stage consists of an event handler,an incoming event queue, and a dynamically-sized thread pool.
　Additionally, 
each stage is subject to dynamic resource control
adjusts the number of threads executing within each stage based on an observation of the stage’s offered load (incoming queue length) and performance (throughput).
（当審訳：
「２　段階的なイベントドリブン−アーキテクチャ
我々のオーバーロード管理技術は
段階的なイベントドリブン−アーキテクチャ（またはSEDA）
2.1　SEDA の概要
・・・（中略）・・・
　図2に示すように，
ステージは，イベントハンドラ，入力イベントキュー，および動的にサイズ変更されるスレッドプールで構成されている
　さらに，
各ステージは，動的なリソースのコントロールに従っており
ステージに提供された負荷（入力キーの長さ）とパフォーマンス（スループット）の観点に基づいて，各ステージ内で実行するスレッドの数を調整する。
　
第４　対比・判断
　
１．本願発明と引用発明との対比
　本願発明と引用発明とを対比する。
　
（ア）引用発明における「システム」は「イベントドリブン型のプログラミング」を利用するものであるから，イベント処理に関するものであることは明らかである。
　したがって，引用発明の「大規模なインターネットサービスに対し，イベントドリブン型のプログラミングとスレッドの両方の特性を利用して，スレッドプールが受け入れるイベントキューへの入力タスクをバッファリングするよう構成したシステムを用いて，負荷を管理する方法」は，本願発明の「イベントを処理する方法」に相当するといえる。
　
（イ）
　ア．引用発明の「スレッドプール境界」と，本願発明の「スレッド境界」とは，ともに，“スレッド構成に係る境界”である点で共通するといえる。
　
　イ．引用発明の「スレッドプール境界」は複数あり，また，上記Ｄの「Queues act to buffer incoming tasks when their number outweighs the number of threads available to process them.（キューは，入力タスクの数が，それらを処理するために使用可能なスレッドの数を上回るとき，その入力タスクをバッファするように働く。）」，「Backpressure ・・・This is important as it allows excess load to be rejected by the system, rather than buffering an arbitrary amount of work.（バックプレッシャーは，・・・これは，作業の任意の量をバッファするのではなく，過剰な負荷をシステムによって拒否できることから重要である。）」との記載からすると，入力タスクの数が使用可能なスレッドの数を上回るときにバッファするために，または，過剰な負荷を拒否するために，スレッドプール境界の負荷を判断することは，当業者にとって自明な事項であることから，
　引用発明の複数の「スレッドプール境界」のうちの，所定の「スレッドプール境界」における負荷を判断することと，本願発明の「複数のスレッド境界の中の第１スレッド境界における負荷を判定するステップ」とは，ともに，“複数のスレッド構成に係る境界の中の第１のスレッド構成に係る境界における負荷を判定するステップ”である点で共通するといえる。　
　
　ウ．上記（ア），及び，上記イ．の検討内容から，
　引用発明の「サービス」に関連して「スレッドプール境界」をなす「スレッドプール」の「各スレッドは，タスクを消費し，処理し，及び，スレッドプールに１つ以上の送出タスクをディスパッチするよう」実行することと，本願発明の「前記複数のスレッド境界は，１つ又は複数のイベント用のサービスを実行可能であり，前記複数のスレッド境界の中のそれぞれのスレッド境界は，少なくとも１つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも１つのタスクを含んでいる」こととは，ともに，“前記スレッド構成に係る境界は，１つ又は複数のイベント用のサービスを実行可能であり，前記スレッド構成に係る境界の中のそれぞれのスレッド構成に係る境界は，少なくとも１つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも１つのタスクを含んでいる”ことである点で共通するといえる。
　
　エ．上記ア．〜ウ．を総合すると，
　引用発明の複数の「スレッドプール境界」のうちの，所定の「スレッドプール境界」における負荷を判断することであり，「サービス」に関連して「スレッドプール境界」をなす「スレッドプール」の「各スレッドは，タスクを消費し，処理し，及び，スレッドプールに１つ以上の送出タスクをディスパッチするよう」実行することであることと，本願発明の「複数のスレッド境界の中の第１スレッド境界における負荷を判定するステップであって，前記複数のスレッド境界は，１つ又は複数のイベント用のサービスを実行可能であり，前記複数のスレッド境界の中のそれぞれのスレッド境界は，少なくとも１つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも１つのタスクを含んでいる，ステップ」とは，ともに，“複数のスレッド構成に係る境界の中の第１のスレッド構成に係る境界における負荷を判定するステップであって，前記複数のスレッド構成に係る境界は，１つ又は複数のイベント用のサービスを実行可能であり，前記複数のスレッド構成に係る境界の中のそれぞれのスレッド構成に係る境界は，少なくとも１つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも１つのタスクを含んでいる，ステップ”である点で共通するといえる。
　
（ウ）上記（イ）イ．で検討したとおり，引用発明の「スレッドプール」よりなる「スレッドプール境界」は，“スレッド構成に係る境界”と呼び得るものであり，また，処理するタスクに合わせてスレッドを制御していることから，タスク処理のためのリソースであるスレッドを動的に制御しているといえる。
　してみると，引用発明の「スレッドプール」よりなる「スレッドプール境界」に係る負荷により，タスク処理のためのリソースであるスレッドを動的に制御することと，本願発明の「前記判定された負荷に基づいて，１つ又は複数のリソースを前記第１スレッド境界に対して動的に割り当てるステップ」とは，ともに，“前記判定された負荷に基づいて，１つ又は複数のリソースを動的に制御するステップ”である点で共通するといえる。
　
（エ）上記（イ）イ．で検討したとおり，引用発明は，複数の「スレッドプール境界」のうちの，所定の「スレッドプール境界」における負荷を判断するものであり，また，「入力キューの長さに基づいてスレッドプールをスケジューリングする」ものであることから，上記所定の「スレッドプール境界」における負荷は，「スレッドプール境界」に結合されたキューに基づいて判定されるものであるといえる。
　一方，本願発明は，第１のスレッド境界における負荷を，第１のスレッド境界に結合された第１のスレッド境界キューにおいて保持されているイベントの数を用いて判定していることから，上位概念において，第１のスレッド境界に結合された第１のスレッド境界キューに基づいて判定しているものといえる。
　してみると，引用発明の所定の「スレッドプール境界」における負荷は，「スレッドプール境界」に結合されたキューに基づいて判定されることと，本願発明の「前記第１のスレッド境界における負荷は，前記第１のスレッド境界に結合された第１のスレッド境界キューにおいて保持されているイベントの数と前記第１のスレッド境界と第２のスレッド境界の間に結合された第２のスレッド境界キュー内に保持されているイベントの数との比較に基づいて判定されること」とは，ともに，“前記第１のススレッド構成に係る境界における負荷は，前記第１のスレッド構成に係る境界に結合された第１のスレッド構成に係る境界のキューに基づいて判定されること”である点で共通するといえる。
　
　以上の対比から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
　イベントを処理する方法において，
　複数のスレッド構成に係る境界の中の第１のスレッド構成に係る境界における負荷を判定するステップであって，前記複数のスレッド構成に係る境界は，１つ又は複数のイベント用のサービスを実行可能であり，前記複数のスレッド構成に係る境界の中のそれぞれのスレッド構成に係る境界は，少なくとも１つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも１つのタスクを含んでいる，ステップと，
　前記判定された負荷に基づいて，１つ又は複数のリソースを動的に制御するステップと，
を有し，
　前記第１のスレッド構成に係る境界における負荷は，前記第１のスレッド構成に係る境界に結合された第１のスレッド構成に係る境界のキューに基づいて判定されることを特徴とする方法。　
　
（相違点１）　
　“スレッド構成に係る境界”について，
　本願発明における「スレッド境界」は，スレッドが処理を実行する場であるのに対し，
　引用発明における「スレッドプール境界」は，処理を実行しているスレッドの他，処理を割り当てられていない資源であるスレッドも存在しうる点。
　
（相違点２）　
　“判定された負荷に基づいて，１つ又は複数のリソースを動的に制御するステップ”について，
　本願発明が，「判定された負荷に基づいて，１つ又は複数のリソースを前記第１スレッド境界に対して動的に割り当てるステップ」であり，「前記１つ又は複数のリソースにより，前記第１スレッド境界の前記少なくとも１つのタスクは，前記少なくとも１つのタスクと関連付けられている前記サービスの少なくとも一部を実行可能である」のに対し，
　引用発明は，そのような構成となっていない点。
　
（相違点３）　
　本願発明が，「前記第１のスレッド境界における負荷は，前記第１のスレッド境界に結合された第１のスレッド境界キューにおいて保持されているイベントの数と前記第１のスレッド境界と第２のスレッド境界の間に結合された第２のスレッド境界キュー内に保持されているイベントの数との比較に基づいて判定される」構成となっているのに対し，
　引用発明は，所定の「スレッドプール境界」における負荷の判定を，「スレッドプール境界」に結合されたキューに基づいて行っているが，当該「判定」内容として，「第１のスレッド境界に結合された第１のスレッド境界キュー」と「第２のスレッド境界の間に結合された第２のスレッド境界キュー」の両方の「キューにおいて保持されているイベントの数」の「比較」に基づいて行うものとなっていない点。
　
　
２．当審判断
　
　上記（相違点１）ないし（相違点３）について検討する。
　
　本願発明は，スレッド境界での処理が過負荷になると，スレッド境界の外部（リソース割当モジュール）から，資源であるスレッドを当該スレッド境界に割り当てるよう構成されている。
　一方，引用発明においては，１つのスレッドプールで処理できるタスクの量を超えると，新たに投入されるタスクはキューに保持され，当該スレッドプール内のスレッドを上記タスクに対し割り当て得る間は，その資源であるスレッドを割り当てるように構成されている。
　しかしながら，タスク実行に際して，処理が過負荷になった場合に，外部から処理資源を投入することは，負荷分散処理の技術分野では周知の技術事項（例えば，特開平１１−２１２９２９号公報（以下，「周知文献１」という。），特開２００３−２４１９８０号公報（以下，「周知文献２」という。）の下記記載事項を参照されたい）であり，したがって，引用発明においても，「スレッドプール」の資源が枯渇した場合に，外部から新たに“処理資源”を投入するよう構成することは，当業者が適宜なし得る事項である。
　
　＜周知文献１＞（特開平１１−２１２９２９号公報）
　「【要約】
【課題】負荷分散されたプロセッサの有効活用を実現することを目的とする。
【解決手段】負荷分散されている処理プロセッサ２０，３０，，および４０の内，プロセッサ２０の負荷が高くなった場合，決定プロセッサ１０は処理を実行させるプロセッサを選択する際，処理プロセッサ２０に対する選択の割合を削減する。その後，決定プロセッサ１０が処理プロセッサ２０の負荷が正常に戻ったことを検出すると，処理プロセッサ２０の選択の割合を他と同等なものとする。」
　
　＜周知文献２＞（特開２００３−２４１９８０号公報）
「【０００５】
【課題を解決するための手段】望ましい実施例によれば，ハードウェア・マルチスレッドをイネーブルされたマルチプロセッサ・コンピュータ・システムにおいて，スレッド・ディスパッチ機構がスレッドをディスパッチし，それによって，各プロセッサが複数のスレッドを実行することを可能にする。スレッド・ディスパッチ機構は，どのプロセッサがビジーであって更なるスレッドを実行することができないか，どのプロセッサがスレッドに作用しているか，及びどのプロセッサがアイドル状態にあるかを決定する。スレッドがディスパッチされる準備ができる時，それらは，他のスレッドに既に作用しているプロセッサの代わりに，アイドル・プロセッサに先ずディスパッチされる。アイドル・プロセッサがまったく存在しない場合，スレッドは，１つ又は複数のスレッドに作用しているが，新たなスレッドも処理することができるプロセッサにディスパッチされる。このように，本発明のスレッド・ディスパッチ機構及び方法は，スレッド間での応答時間における非常に改善された一貫性を提供し，しかもスレッドをディスパッチする従来技術の方法に比べて高いスループットを提供する。」
　
　また，複数のステージでのイベント処理のスループットを向上させるために，前記複数のステージにおける，各イベントキューの長さによって各々の負荷を判断し，キューの長い方すなわちキューに含まれるイベント数の多い方に，より多くの資源を割り付けることは，周知慣用技術（例えば，引用文献２の上記Ｇの記載を参照されたい。）であり，
　引用発明における，複数の「スレッドプール境界」に対し，上記周知慣用技術を適用することで，各々に結合された複数のキューの長さによって各々の負荷を判断し，キューの長い方すなわちキューに含まれるイベント数の多い方に，より多くのリソースを割り付けるという比較を伴う処理を行うようにすることは，当業者であれば容易になし得ることであると認められる。
　
　してみると，引用発明に対し，上記周知技術及び周知慣用技術を適用することで，「スレッドプール境界」を「スレッド境界」とし，また，「判定された負荷に基づいて，１つ又は複数のリソースを前記第１スレッド境界に対して動的に割り当てるステップ」を有するようにすることで，「前記１つ又は複数のリソースにより，前記第１スレッド境界の前記少なくとも１つのタスクは，前記少なくとも１つのタスクと関連付けられている前記サービスの少なくとも一部を実行可能である，ステップ」を有するものとするとともに，「前記第１のスレッド境界における負荷は，前記第１のスレッド境界に結合された第１のスレッド境界キューにおいて保持されているイベントの数と前記第１のスレッド境界と第２のスレッド境界の間に結合された第２のスレッド境界キュー内に保持されているイベントの数との比較に基づいて判定される」こととすること，すなわち，相違点１ないし相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点１ないし相違点３は格別なものではない。
　
　そして，本願発明により奏する効果も，引用発明，周知技術及び周知慣用技術から当然予想される範囲内のものにすぎず，格別顕著なものとは認められない。
　
　
第５　むすび
　
　以上のとおり，本願の請求項１に係る発明は，引用発明，周知技術及び周知慣用技術に基いて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができないものであり，他の請求項についての検討をするまでもなく，本願は拒絶されるべきものである。
　
　よって，結論のとおり審決する。