ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1284913 |
| 審判番号 | 不服2012-3637 |
| 総通号数 | 172 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2014-04-25 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2012-02-24 |
| 確定日 | 2014-02-20 |
| 事件の表示 | 特願2007-527954「モジュラー型のイベントドリブン処理」拒絶査定不服審判事件〔平成18年 3月 2日国際公開、WO2006/023506、平成20年 4月 3日国内公表、特表2008-510259〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は,2004年8月17日(以下「優先日」という。)の米国への出願を基礎とするパリ条約による優先権主張をともない,2005年8月15日を国際出願日とする出願であって, 平成19年2月16日付けで特許法第184条の5第1項の規定による書面が提出され, 平成19年4月13日付けで特許法第184条の4第1項の規定による特許請求の範囲,明細書,図面(図面の中の説明に限る),要約書の日本語による翻訳文が提出され, 平成20年8月14日付けで審査請求がなされ, 平成23年6月29日付けで拒絶理由通知(同年7月4日発送)がなされ, 同年10月4日付けで意見書が提出されるとともに,同日付けで手続補正がなされたが, 同年10月21日付けで拒絶査定(同年10月25日謄本送達)がなされ, 平成24年2月24日付けで審判請求がされたものである。 第2 本願発明 本願の請求項1に係る発明は,平成23年10月4日付けの手続補正書により補正された特許請求の範囲の請求項1に記載されたとおりの次の事項により特定されるものである。(以下「本願発明」という。) 「イベントを処理する方法において, 複数のスレッド境界の中の第1スレッド境界における負荷を判定するステップであって,前記複数のスレッド境界は,1つ又は複数のイベント用のサービスを実行可能であり,前記複数のスレッド境界の中のそれぞれのスレッド境界は,少なくとも1つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも1つのタスクを含んでいる,ステップと, 前記判定された負荷に基づいて,1つ又は複数のリソースを前記第1スレッド境界に対して動的に割り当てるステップであって,前記1つ又は複数のリソースにより,前記第1スレッド境界の前記少なくとも1つのタスクは,前記少なくとも1つのタスクと関連付けられている前記サービスの少なくとも一部を実行可能である,ステップと, を有し, 前記第1のスレッド境界における負荷は,前記第1のスレッド境界に結合された第1のスレッド境界キューにおいて保持されているイベントの数と前記第1のスレッド境界と第2のスレッド境界の間に結合された第2のスレッド境界キュー内に保持されているイベントの数との比較に基づいて判定されることを特徴とする方法。」 第3 先行技術 本願の出願前の優先日よりも前に頒布又は電気通信回線を通じて公衆に利用可能となり,原審の拒絶査定の理由である上記平成23年6月29日付けの拒絶理由通知において引用された,下記引用文献には,関連する図面とともに,それぞれ下記の事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。) ＜引用文献1＞ 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,2000年,UCB/CSD-00-1108,URL,http://www.eecs.berkeley.edu/Pubs/TechRpts/2000/CSD-00-1108.pdf A「1 Introduction Large Internet services must deal with concurrency at an unprecedented scale. The number of concurrent sessions and hits per day to Internet sites translates into an even higher number of I/O and network requests, placing enormous demands on underlying resources. Microsoft's web sites receive over 300 million hits with 4.1 million users a day; Lycos has over 82 million page views and more than a million users daily. 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. In addition, our framework addresses the other requirements for these applications: high availability and maintenance of high throughput under load. The former is achieved by introducing fault boundaries between application components; the latter by conditioning the load placed on system resources.」(第1頁目左欄26行?第2頁目左欄13行,「1 Introduction」の欄) (当審訳: 「1 はじめに 大規模なインターネットサービスは,前例のない規模での並行処理に対処する必要がある。インターネットサイトに対する一日あたりの同時セッション数やヒット数は,より高いI/Oやネットワークリクエスト数に変換され,基盤となる資源への多大な要求に置き換わる。マイクロソフトのウェブサイトは,一日に410万人のユーザーによる3億ヒット以上を受け付け,ライコスは,毎日8200万以上のページビューと100万人以上のユーザを持っている。インターネットサービスの需要が拡大するにつれ,その機能性など,新たなシステム設計技術が,この負荷を管理するために用いられなければならない。 ・・・(中略)・・・ そのスレッドとイベントは,デザイン領域の両端として最善のものと見なされている:同時実行性の高いシステムを開発するための鍵は,この領域の真ん中で動作させることである。イベントドリブン技術は,高い同時実行性を得るために有用であるが,実際のシステムを構築する場合,スレッドは,マルチプロセッサの並列処理を利用したり,I/Oメカニズムのブロックに対処するために(そして必要な多くの場合)貴重なものである。ほとんどの開発者は,この領域が存在することを認識しており,それは,同時実行性のために,スレッドとイベント指向のアプローチの両方を利用するものである。しかし,この領域の広がりは,現在よく理解されていない。 我々は,同時実行性の高いシステムを構築するための,汎用設計フレームワークを提案する。我々のフレームワークの背後にある主要なアイデアは,高スループットのためにイベントドリブン型のプログラミングを用いるが,並行処理とプログラミングの容易さのために(数量が限定された)有効スレッドを活用することである。加えて,我々のフレームワークは,これらのアプリケーションのための他の要件を提示しており,それは,高可用性と,負荷の下で高スループットを維持することである。前者は,アプリケーションのコンポーネント間の障害境界を導入することによって,また後者は,システムリソースにかかる負荷を調整することによって達成される。」) B「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 goal is to obtain the benefit of threads, but to limit their number so as to prevent performance degradation. The question to be asked is how many threads are needed, and whether that number can fit within the operating range of the system. 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. Each task is handled by a single thread using standard blocking interfaces and developed using familiar tools. Excess concurrency is absorbed by the queue, and thus the response time increases with load but throughput does not degrade.」(第4頁目左欄15行?右欄7行,「2.3 The Thread and Event Spectrum」の欄) (当審訳: 「2.3 スレッド・イベント 領域 同時実行性の高いサービスは,スレッドとイベントをめぐる議論に新たに動機を与えることになるが,重要なのは,同時実行性のための設計空間がこの2点に限定されないということである。むしろ,これらの両極端の間に領域が存在し,戦略的に両方の特性を利用するハイブリッドなシステムを構築することが可能である。その目標は,スレッドの利益を得ることであり,また,パフォーマンスの低下を防ぐためにそれらの数を制限することでもある。提起されるべき問題は,スレッドがどれだけ必要であり,その数がシステムの動作範囲内に収まることができるかどうかである。 スレッドとイベントのハイブリッドなサーバとして,最も簡易な例を図6に示す。それは,システムで実行中の同時スレッドの数が,事前に割り当てられたスレッドプール内のT個のスレッドを超えないように制限し,そしてそのスレッドプールが受け入れるイベントキューへの入力タスクをバッファする。各タスクは,標準のブロッキングインターフェイスを使用する単一のスレッドによって処理され,使い慣れたツールを使用して開発される。過剰な同時実行はキューによって吸収され,これにより,応答時間は負荷と共に増加するが,スループットが低下することはない。」) C「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; each task experiences a service latency of L seconds. If the number of tasks received by the hybrid server exceeds the size of the thread pool, the excess tasks are buffered by the incoming task queue.」(「Figure 6」の説明) (当審訳: 「図6:スレッドとイベントのハイブリッドなシステム:このサーバは,入力タスクキューからの到着率に合わせて,サービスタスクへT個のスレッドからなる一定サイズのスレッドプールを使用しており,各タスクでは,L秒のサービスの待ち時間が発生する。ハイブリッドサーバによって受信されたタスク数がスレッドプールのサイズを超える場合には,過剰なタスクは入力タスクキューによってバッファされる。」) D「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. A thread pool must have at least one thread within it. 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. A queue logically consists of a list of tasks; 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. We call a thread pool coupled with its incoming task queue a task handler. 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. This is desirable for two reasons. First, it makes applications easier to debug, as the thread pool's internal state is not visible to other thread pools. Second, it can eliminate cases where threads “escape” into a piece of code where they may never return - for example, into a library that performs blocking I/O operations. In addition, queues provide a mechanism for overflow absorption, backpressure, and fairness. Queues act to buffer incoming tasks when their number outweighs the number of threads available to process them. Backpressure can be implemented by having a queue reject new entries (e.g., by raising an error condition) when it becomes full. This is 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.」(第6頁目左欄19行?第6頁目右欄17行,「3.1 Framework Componentsm」の欄) (当審訳: 「3.1.2 スレッドプール スレッドプールは,継続的にタスクを処理することで動作する同じマシン上でのスレッドの集まりである。論理的には,スレッドプールは,タスクタイプのセットと関連付けられ,プール内の各スレッドは,タスクを消費し,処理し,及び,スレッドプールに1つ以上の送出タスクをディスパッチするよう,一つのコードを実行する。スレッドプールは,その中に少なくともスレッドを1つ有していなければならない。 スレッドプールは,我々のフレームワークの中で実行コンテキストの唯一の供給源である。モジュール性は,それぞれが特定の組のタイプのタスクを処理するような複数のスレッドプールの組として,アプリケーションを構築することによって,達成される。各スレッドは,マルチプロセッサシステム内の別々のCPU上で実行することができることから,並列性が実現可能となる。 3.1.3 キュー キューは,スレッドプールの間の通信手段である。キューは,論理的にタスクのリストで構成され,スレッドプールは,入力タスクキューからタスクを抜き出すと,それらをスレッドプールの入力キューに送り込むことでタスクをディスパッチする。2つのスレッドプールの動作は,それらの間にキューを挿入し,それによってタスクを一方から他方に通過させることによって,成り立たせることができる。その入力タスクキューを伴ったスレッドプールを,タスクハンドラと呼ぶ。 キューは,複数のスレッドプール間において分離したメカニズムとして機能し,それは明示的な制御の境界を導入することでなされる。スレッドがこの境界を超えることができないので(それは,タスクをキューに入れることによってのみ,境界を越えてデータを渡すことができる。),定められたタスクハンドラだけにスレッドの実行を制限することが可能である。これは2つの理由により望ましい。まず第一に,それはスレッドプールの内部状態を他のスレッドプールから見えないよう,デバックすることを簡単にする。第二に,スレッドが一つのコード-例えば,I/O操作のブロックを実行するライブラリ-中に“逃げ込んで”決して戻ってこないかもしれないようなケース-を排除することができる。 さらに,キューはオーバーフローの吸収,バックプレッシャー,及び公平性のためのメカニズムを提供する。キューは,入力タスクの数が,それらを処理するために使用可能なスレッドの数を上回るとき,その入力タスクをバッファするように働く。バックプレッシャーは,キューが満杯になったとき,キューへの新しいエントリをリジェクトさせる(例えば,エラー状態を上げることによって)ことによって実現することができる。これは,作業の任意の量をバッファするのではなく,過剰な負荷をシステムによって拒否できることから重要である。公平性は,その入力キューの長さに基づいてスレッドプールをスケジューリングすることによって,達成することができる。」) E「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. This is illustrated in Figure 8(b). For example,if queues are introduced for each blocking I/O call, this operation makes each call appear to be non-blocking,as separate threads are responsible for processing the task on either side of the call. ・・・(後略)」(第6頁目右欄18行?第7頁目左欄21行,「3.2 Design Patterns」の欄) (当審訳: 「3.2 デザインパターン さて我々は,上記にて提示したコンポーネントを使用した実装において,如何にアプリケーションをマッピングするかの問題に取りかかる。スレッドプールとキューをどこで使用するかという決定は,成果物であるアプリケーションの,パフォーマンスとフォールト・トレラントという特性に重要な影響を持っている。 我々は,我々のフレームワークを使ったアプリケーションの構築に適用することができる,4つのデザインパターンを提案する。これらのデザインパターンは,我々のフレームワークのコンポーネントの基本的な性質をカプセル化し,それらを使用してアプリケーションを如何に構築するかについて記述している。 ・・・(中略)・・・ 3.2.2 パイプライン パイプラインのパターンは,シングルスレッドとしてのコードを取り,様々なポイントでキューとスレッドプール境界を導入することにより,それを複数のパイプラインのステージへ分割する。これは,図8(b)の図示されている。例えば,キューが各ブロッキングI/Oのコールに導入される場合,この操作により各コールが非ブロッキングとして現れ,別々のスレッドがそのコールの両側におけるタスクを処理する責任を負うことになる。」) F「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:デザインパターンを用いた結果のアプリケーション。タスクが左端のキューでアプリケーションに入力されながら,データは左から右に流れる。破線のボックスは,マシン境界を表す。各デザインパターンは,その使用の下でラベル付けされる。」) 以下に,上記引用文献1の記載事項について検討する。 (ア)引用文献1は, 上記Aに「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.(インターネットサービスの需要が拡大するにつれ,その機能性など,新たなシステム設計技術が,この負荷を管理するために用いられなければならない。)」との記載があるとおり,“大規模なインターネットサービスに対し,新たな設計技術によるシステムを用いて,負荷を管理する”こと,及びそのための方法について説明ないし示唆するものであり, また上記“新たな設計技術によるシステム”に関し,上記Aの「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.(我々は,同時実行性の高いシステムを構築するための,汎用設計フレームワークを提案する。我々のフレームワークの背後にある主要なアイデアは,高スループットのためにイベントドリブン型のプログラミングを,そして並行処理とプログラミングの容易さのために(数量が限定された)有効スレッドを使用することである。)」との記載,上記Bの「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.(同時実行性の高いサービスは,スレッドとイベントをめぐる議論に新たに動機を与えることになるが,重要なのは,同時実行性のための設計空間がこの2点に限定されないということである。むしろ,これらの両極端の間に領域が存在し,戦略的に両方の特性を利用するハイブリッドなシステムを構築することが可能である。)」,「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に示す。それは,システムで実行中の同時スレッドの数が,事前に割り当てられたスレッドプール内のT個のスレッドを超えないように制限し,そしてそのスレッドプールが受け入れるイベントキューへの入力タスクをバッファする。)」との記載から,イベントドリブン型のプログラミングとスレッドの両方の特性を利用して,スレッドプールが受け入れるイベントキューへの入力タスクをバッファリングするよう構成したシステム,を用いることが記載されているといえ, したがって,引用文献1には, “大規模なインターネットサービスに対し,イベントドリブン型のプログラミングとスレッドの両方の特性を利用して,スレッドプールが受け入れるイベントキューへの入力タスクをバッファリングするよう構成したシステムを用いて,負荷を管理する方法”が記載されているといえる。 (イ)前記「システム」に関し, 上記Bの「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に示す。それは,システムで実行中の同時スレッドの数が,事前に割り当てられたスレッドプール内のT個のスレッドを超えないように制限し,そしてそのスレッドプールが受け入れるイベントキューへの入力タスクをバッファする。)」との記載,上記Cで示した「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(このサーバは,入力タスクキューからの到着率に合わせて,サービスタスクへT個のスレッドからなる一定サイズのスレッドプールを使用しており)」との記載から, 前記“システム”は, “スレッドプール”,及び,“キュー”を備えることがよみとれる。 (ウ)上記「スレッドプール」に関し, 上記Dの「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つ以上の送出タスクをディスパッチするよう,一つのコードを実行する。)」との記載から, 前記“スレッドプール”は,“タスクを処理するスレッドの集まりであり,各スレッドは,タスクを消費し,処理し,及び,スレッドプールに1つ以上の送出タスクをディスパッチするよう,コードを実行するものである”ことがよみとれる。 また,上記「キュー」に関し, 上記Dの「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.(2つのスレッドプールの動作は,それらの間にキューを挿入し,それによってタスクを一方から他方に通過させることによって,成り立たせることができる。)」との記載から, 前記“キュー”は,“2つのスレッドプールの間をつなぐ通信手段であり,2つのスレッドプールの間にキューを挿入することによって,データを2つのスレッドプールの一方から他方に通過させて渡すことを実現する”ことがよみとれる。 してみると, 前記“システム”は, “タスクを処理するスレッドの集まりであり,各スレッドは,タスクを消費し,処理し,及び,スレッドプールに1つ以上の送出タスクをディスパッチするよう,コードを実行するものである,スレッドプールと, 2つのスレッドプールの間を接続する通信手段であり,2つのスレッドプールの間にキューを挿入することによって,データを2つのスレッドプールの一方から他方に通過させて渡すことを実現する,キュー”を備えることがよみとれる。 (エ)上記“スレッドプール”,及び,“キュー”に関し, 上記Dの「3.1.3 Queues」についての記載,上記Eの記載,及び上記Fの記載は,2つの「スレッドプール」を,「キュー」により接続するための構成について説明しているところ, 上記Dの「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.(2つのスレッドプールの動作は,それらの間にキューを挿入し,それによってタスクを一方から他方に通過させることによって,成り立たせることができる。)」,「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.(さらに,キューはオーバーフローの吸収,バックプレッシャー,及び公平性のためのメカニズムを提供する。・・・公平性は,その入力キューの長さに基づいてスレッドプールをスケジューリングすることによって,達成することができる。)」との記載,上記Eの「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.(パイプラインのパターンは,シングルスレッドとしてのコードを取り,様々なポイントでキューとスレッドプール境界を導入することにより,それを複数のパイプラインのステージへ分割する。)」との記載,及び,上記Fで示した「Figure 9」における「Pipeline」に関する態様から, 前記“システム”は, “制御の境界を導入することで,2つのスレッドプール境界と,その間に接続される分離したメカニズムとしてのキューと,により複数のパイプラインのステージを構成”することがよみとれる。 (オ)上記Dの「thread pools pull tasks from their incoming task queue, and dispatch tasks by pushing them onto the incoming queues of thread pools.(スレッドプールは,入力タスクキューからタスクを抜き出すと,それらをスレッドプールの入力キューに送り込むことでタスクをディスパッチする。)」との記載から, 前記“システム”は, “スレッドプールは,入力タスクキューからタスクを抜き出すと,それらをスレッドプールの入力キューに送り込むことでタスクをディスパッチ”することがよみとれる。 (カ)上記Dの「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.(さらに,キューはオーバーフローの吸収,バックプレッシャー,及び公平性のためのメカニズムを提供する。・・・公平性は,その入力キューの長さに基づいてスレッドプールをスケジューリングすることによって,達成することができる。)」との記載から, 前記“システム”は, “入力キューの長さに基づいてスレッドプールをスケジューリングする”ことがよみとれる。 以上,(ア)ないし(カ)を踏まえると,引用文献1には,次の発明(以下,「引用発明」という。)が記載されているものと認める。 大規模なインターネットサービスに対し,イベントドリブン型のプログラミングとスレッドの両方の特性を利用して,スレッドプールが受け入れるイベントキューへの入力タスクをバッファリングするよう構成したシステムを用いて,負荷を管理する方法であって, タスクを処理するスレッドの集まりであり,各スレッドは,タスクを消費し,処理し,及び,スレッドプールに1つ以上の送出タスクをディスパッチするよう,コードを実行するものである,スレッドプールと, 2つのスレッドプールの間を接続する通信手段であり,2つのスレッドプールの間にキューを挿入することによって,データを2つのスレッドプールの一方から他方に通過させて渡すことを実現する,キューと, を備え, 制御の境界を導入することで,2つのスレッドプール境界と,その間に接続される分離したメカニズムとしての前記キューと,により複数のパイプラインのステージを構成し, 前記スレッドプールは,入力タスクキューからタスクを抜き出すと,それらを前記スレッドプールの入力キューに送り込むことでタスクをディスパッチし, 入力キューの長さに基づいて前記スレッドプールをスケジューリングする, ことを含む方法。 ＜引用文献2＞ Welsh,M., and Culler,D.,“Adaptive Overload Control for Busy Internet Servers”,Proc. of the 4th USENIX Conf. on Internet Technologies and Systems ,2003年3月26日 G「2 The Staged Event-Driven Architecture Our overload management techniques are based on the staged event-driven architecture (or SEDA), a model for designing Internet services that are inherently scalable and robust to load. In SEDA, applications are structured as a graph of event-driven stages connected with explicit event queues, as shown in Figure 1. We provide a brief overview of the architecture here; a more complete description and extensive performance results are given in [40]. 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. Threads within a stage operate by pulling a batch of events off of the incoming event queue and invoking the application-supplied event handler. The event handler processes each batch of events, and dispatches zero or more events by enqueueing them on the event queues of other stages. The stage’s incoming event queue is guarded by an admission controller that accepts or rejects new requests for the stage. The overload control mechanisms described in this paper are based on adaptive admission control for each stage in a SEDA service. Additionally, each stage is subject to dynamic resource control, which attempts to keep each stage within its ideal operating regime by tuning parameters of the stage’s operation. For example, one such controller 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).This approach frees the application programmer from manually setting “knobs” that can have a serious impact on performance. More details on resource control in SEDA are given in [40].」(第2頁目左欄42行?第3頁目左欄3行,「2 The Staged Event-Driven Architecture」の欄) (当審訳: 「2 段階的なイベントドリブン-アーキテクチャ 我々のオーバーロード管理技術は段階的なイベントドリブン-アーキテクチャ(またはSEDA)に基づいており,負荷に対し本質的に拡張可能でかつ堅牢なインターネットサービスを設計するためのモデルである。SEDAでは,アプリケーションは,図1に示すように,明示的なイベント・キューに接続されたイベントドリブン・ステージのグラフとして構成されている。ここではアーキテクチャの概要を提供し,より完全な説明と豊富なパフォーマンス結果は[40]に記載されている。 2.1 SEDA の概要 ・・・(中略)・・・ 図2に示すように,ステージは,イベントハンドラ,入力イベントキュー,および動的にサイズ変更されるスレッドプールで構成されている。ステージ内のスレッドは,入力イベントキューのイベントのバッチを引き込み,アプリケーション提供のイベントハンドラを呼び出すことによって動作する。イベントハンドラは,イベントの各バッチを処理し,他のステージのイベント・キューにそれらをエンキューすることによって,ゼロまたはそれ以上のイベントをディスパッチする。ステージの入力イベントキューは,ステージに対する新しい要求を受け入れたり拒否する入力コントローラによって守られている。本稿で述べたオーバーロード制御メカニズムは,SEDAサービスの各ステージに適応した入力制御に基づいている。 さらに,各ステージは,動的なリソースのコントロールに従っており,それは各ステージを操作するためのチューニングパラメータにより,その理想的な操作範囲の中に保持しようとするものである。例えば,そのようなコントローラが,ステージに提供された負荷(入力キーの長さ)とパフォーマンス(スループット)の観点に基づいて,各ステージ内で実行するスレッドの数を調整する。このアプローチでは,パフォーマンスに深刻な影響を与える,手動での“摘み”の設定から,アプリケーションプログラマを解放する。SEDAにおけるリソース制御の詳細については,[40]に記載されている。」) 第4 対比・判断 1.本願発明と引用発明との対比 本願発明と引用発明とを対比する。 (ア)引用発明における「システム」は「イベントドリブン型のプログラミング」を利用するものであるから,イベント処理に関するものであることは明らかである。 したがって,引用発明の「大規模なインターネットサービスに対し,イベントドリブン型のプログラミングとスレッドの両方の特性を利用して,スレッドプールが受け入れるイベントキューへの入力タスクをバッファリングするよう構成したシステムを用いて,負荷を管理する方法」は,本願発明の「イベントを処理する方法」に相当するといえる。 (イ) ア.引用発明の「スレッドプール境界」と,本願発明の「スレッド境界」とは,ともに,“スレッド構成に係る境界”である点で共通するといえる。 イ.引用発明の「スレッドプール境界」は複数あり,また,上記Dの「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.(バックプレッシャーは,・・・これは,作業の任意の量をバッファするのではなく,過剰な負荷をシステムによって拒否できることから重要である。)」との記載からすると,入力タスクの数が使用可能なスレッドの数を上回るときにバッファするために,または,過剰な負荷を拒否するために,スレッドプール境界の負荷を判断することは,当業者にとって自明な事項であることから, 引用発明の複数の「スレッドプール境界」のうちの,所定の「スレッドプール境界」における負荷を判断することと,本願発明の「複数のスレッド境界の中の第1スレッド境界における負荷を判定するステップ」とは,ともに,“複数のスレッド構成に係る境界の中の第1のスレッド構成に係る境界における負荷を判定するステップ”である点で共通するといえる。 ウ.上記(ア),及び,上記イ.の検討内容から, 引用発明の「サービス」に関連して「スレッドプール境界」をなす「スレッドプール」の「各スレッドは,タスクを消費し,処理し,及び,スレッドプールに1つ以上の送出タスクをディスパッチするよう」実行することと,本願発明の「前記複数のスレッド境界は,1つ又は複数のイベント用のサービスを実行可能であり,前記複数のスレッド境界の中のそれぞれのスレッド境界は,少なくとも1つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも1つのタスクを含んでいる」こととは,ともに,“前記スレッド構成に係る境界は,1つ又は複数のイベント用のサービスを実行可能であり,前記スレッド構成に係る境界の中のそれぞれのスレッド構成に係る境界は,少なくとも1つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも1つのタスクを含んでいる”ことである点で共通するといえる。 エ.上記ア.?ウ.を総合すると, 引用発明の複数の「スレッドプール境界」のうちの,所定の「スレッドプール境界」における負荷を判断することであり,「サービス」に関連して「スレッドプール境界」をなす「スレッドプール」の「各スレッドは,タスクを消費し,処理し,及び,スレッドプールに1つ以上の送出タスクをディスパッチするよう」実行することであることと,本願発明の「複数のスレッド境界の中の第1スレッド境界における負荷を判定するステップであって,前記複数のスレッド境界は,1つ又は複数のイベント用のサービスを実行可能であり,前記複数のスレッド境界の中のそれぞれのスレッド境界は,少なくとも1つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも1つのタスクを含んでいる,ステップ」とは,ともに,“複数のスレッド構成に係る境界の中の第1のスレッド構成に係る境界における負荷を判定するステップであって,前記複数のスレッド構成に係る境界は,1つ又は複数のイベント用のサービスを実行可能であり,前記複数のスレッド構成に係る境界の中のそれぞれのスレッド構成に係る境界は,少なくとも1つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも1つのタスクを含んでいる,ステップ”である点で共通するといえる。 (ウ)上記(イ)イ.で検討したとおり,引用発明の「スレッドプール」よりなる「スレッドプール境界」は,“スレッド構成に係る境界”と呼び得るものであり,また,処理するタスクに合わせてスレッドを制御していることから,タスク処理のためのリソースであるスレッドを動的に制御しているといえる。 してみると,引用発明の「スレッドプール」よりなる「スレッドプール境界」に係る負荷により,タスク処理のためのリソースであるスレッドを動的に制御することと,本願発明の「前記判定された負荷に基づいて,1つ又は複数のリソースを前記第1スレッド境界に対して動的に割り当てるステップ」とは,ともに,“前記判定された負荷に基づいて,1つ又は複数のリソースを動的に制御するステップ”である点で共通するといえる。 (エ)上記(イ)イ.で検討したとおり,引用発明は,複数の「スレッドプール境界」のうちの,所定の「スレッドプール境界」における負荷を判断するものであり,また,「入力キューの長さに基づいてスレッドプールをスケジューリングする」ものであることから,上記所定の「スレッドプール境界」における負荷は,「スレッドプール境界」に結合されたキューに基づいて判定されるものであるといえる。 一方,本願発明は,第1のスレッド境界における負荷を,第1のスレッド境界に結合された第1のスレッド境界キューにおいて保持されているイベントの数を用いて判定していることから,上位概念において,第1のスレッド境界に結合された第1のスレッド境界キューに基づいて判定しているものといえる。 してみると,引用発明の所定の「スレッドプール境界」における負荷は,「スレッドプール境界」に結合されたキューに基づいて判定されることと,本願発明の「前記第1のスレッド境界における負荷は,前記第1のスレッド境界に結合された第1のスレッド境界キューにおいて保持されているイベントの数と前記第1のスレッド境界と第2のスレッド境界の間に結合された第2のスレッド境界キュー内に保持されているイベントの数との比較に基づいて判定されること」とは,ともに,“前記第1のススレッド構成に係る境界における負荷は,前記第1のスレッド構成に係る境界に結合された第1のスレッド構成に係る境界のキューに基づいて判定されること”である点で共通するといえる。 以上の対比から,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。 (一致点) イベントを処理する方法において, 複数のスレッド構成に係る境界の中の第1のスレッド構成に係る境界における負荷を判定するステップであって,前記複数のスレッド構成に係る境界は,1つ又は複数のイベント用のサービスを実行可能であり,前記複数のスレッド構成に係る境界の中のそれぞれのスレッド構成に係る境界は,少なくとも1つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも1つのタスクを含んでいる,ステップと, 前記判定された負荷に基づいて,1つ又は複数のリソースを動的に制御するステップと, を有し, 前記第1のスレッド構成に係る境界における負荷は,前記第1のスレッド構成に係る境界に結合された第1のスレッド構成に係る境界のキューに基づいて判定されることを特徴とする方法。 (相違点1) “スレッド構成に係る境界”について, 本願発明における「スレッド境界」は,スレッドが処理を実行する場であるのに対し, 引用発明における「スレッドプール境界」は,処理を実行しているスレッドの他,処理を割り当てられていない資源であるスレッドも存在しうる点。 (相違点2) “判定された負荷に基づいて,1つ又は複数のリソースを動的に制御するステップ”について, 本願発明が,「判定された負荷に基づいて,1つ又は複数のリソースを前記第1スレッド境界に対して動的に割り当てるステップ」であり,「前記1つ又は複数のリソースにより,前記第1スレッド境界の前記少なくとも1つのタスクは,前記少なくとも1つのタスクと関連付けられている前記サービスの少なくとも一部を実行可能である」のに対し, 引用発明は,そのような構成となっていない点。 (相違点3) 本願発明が,「前記第1のスレッド境界における負荷は,前記第1のスレッド境界に結合された第1のスレッド境界キューにおいて保持されているイベントの数と前記第1のスレッド境界と第2のスレッド境界の間に結合された第2のスレッド境界キュー内に保持されているイベントの数との比較に基づいて判定される」構成となっているのに対し, 引用発明は,所定の「スレッドプール境界」における負荷の判定を,「スレッドプール境界」に結合されたキューに基づいて行っているが,当該「判定」内容として,「第1のスレッド境界に結合された第1のスレッド境界キュー」と「第2のスレッド境界の間に結合された第2のスレッド境界キュー」の両方の「キューにおいて保持されているイベントの数」の「比較」に基づいて行うものとなっていない点。 2.当審判断 上記(相違点1)ないし(相違点3)について検討する。 本願発明は,スレッド境界での処理が過負荷になると,スレッド境界の外部(リソース割当モジュール)から,資源であるスレッドを当該スレッド境界に割り当てるよう構成されている。 一方,引用発明においては,1つのスレッドプールで処理できるタスクの量を超えると,新たに投入されるタスクはキューに保持され,当該スレッドプール内のスレッドを上記タスクに対し割り当て得る間は,その資源であるスレッドを割り当てるように構成されている。 しかしながら,タスク実行に際して,処理が過負荷になった場合に,外部から処理資源を投入することは,負荷分散処理の技術分野では周知の技術事項(例えば,特開平11-212929号公報(以下,「周知文献1」という。),特開2003-241980号公報(以下,「周知文献2」という。)の下記記載事項を参照されたい)であり,したがって,引用発明においても,「スレッドプール」の資源が枯渇した場合に,外部から新たに“処理資源”を投入するよう構成することは,当業者が適宜なし得る事項である。 ＜周知文献1＞(特開平11-212929号公報) 「【要約】 【課題】負荷分散されたプロセッサの有効活用を実現することを目的とする。 【解決手段】負荷分散されている処理プロセッサ20,30,,および40の内,プロセッサ20の負荷が高くなった場合,決定プロセッサ10は処理を実行させるプロセッサを選択する際,処理プロセッサ20に対する選択の割合を削減する。その後,決定プロセッサ10が処理プロセッサ20の負荷が正常に戻ったことを検出すると,処理プロセッサ20の選択の割合を他と同等なものとする。」 ＜周知文献2＞(特開2003-241980号公報) 「【0005】 【課題を解決するための手段】望ましい実施例によれば,ハードウェア・マルチスレッドをイネーブルされたマルチプロセッサ・コンピュータ・システムにおいて,スレッド・ディスパッチ機構がスレッドをディスパッチし,それによって,各プロセッサが複数のスレッドを実行することを可能にする。スレッド・ディスパッチ機構は,どのプロセッサがビジーであって更なるスレッドを実行することができないか,どのプロセッサがスレッドに作用しているか,及びどのプロセッサがアイドル状態にあるかを決定する。スレッドがディスパッチされる準備ができる時,それらは,他のスレッドに既に作用しているプロセッサの代わりに,アイドル・プロセッサに先ずディスパッチされる。アイドル・プロセッサがまったく存在しない場合,スレッドは,1つ又は複数のスレッドに作用しているが,新たなスレッドも処理することができるプロセッサにディスパッチされる。このように,本発明のスレッド・ディスパッチ機構及び方法は,スレッド間での応答時間における非常に改善された一貫性を提供し,しかもスレッドをディスパッチする従来技術の方法に比べて高いスループットを提供する。」 また,複数のステージでのイベント処理のスループットを向上させるために,前記複数のステージにおける,各イベントキューの長さによって各々の負荷を判断し,キューの長い方すなわちキューに含まれるイベント数の多い方に,より多くの資源を割り付けることは,周知慣用技術(例えば,引用文献2の上記Gの記載を参照されたい。)であり, 引用発明における,複数の「スレッドプール境界」に対し,上記周知慣用技術を適用することで,各々に結合された複数のキューの長さによって各々の負荷を判断し,キューの長い方すなわちキューに含まれるイベント数の多い方に,より多くのリソースを割り付けるという比較を伴う処理を行うようにすることは,当業者であれば容易になし得ることであると認められる。 してみると,引用発明に対し,上記周知技術及び周知慣用技術を適用することで,「スレッドプール境界」を「スレッド境界」とし,また,「判定された負荷に基づいて,1つ又は複数のリソースを前記第1スレッド境界に対して動的に割り当てるステップ」を有するようにすることで,「前記1つ又は複数のリソースにより,前記第1スレッド境界の前記少なくとも1つのタスクは,前記少なくとも1つのタスクと関連付けられている前記サービスの少なくとも一部を実行可能である,ステップ」を有するものとするとともに,「前記第1のスレッド境界における負荷は,前記第1のスレッド境界に結合された第1のスレッド境界キューにおいて保持されているイベントの数と前記第1のスレッド境界と第2のスレッド境界の間に結合された第2のスレッド境界キュー内に保持されているイベントの数との比較に基づいて判定される」こととすること,すなわち,相違点1ないし相違点3に係る構成とすることは,当業者が容易に想到し得たことである。 よって,相違点1ないし相違点3は格別なものではない。 そして,本願発明により奏する効果も,引用発明,周知技術及び周知慣用技術から当然予想される範囲内のものにすぎず,格別顕著なものとは認められない。 第5 むすび 以上のとおり,本願の請求項1に係る発明は,引用発明,周知技術及び周知慣用技術に基いて,当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができないものであり,他の請求項についての検討をするまでもなく,本願は拒絶されるべきものである。 よって,結論のとおり審決する。 |
| 審理終結日 | 2013-09-20 |
| 結審通知日 | 2013-09-24 |
| 審決日 | 2013-10-11 |
| 出願番号 | 特願2007-527954(P2007-527954) |
| 審決分類 |
P
1
8・
121-
Z
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 川崎 優 |
| 特許庁審判長 |
仲間 晃 |
| 特許庁審判官 |
辻本 泰隆 石井 茂和 |
| 発明の名称 | モジュラー型のイベントドリブン処理 |
| 代理人 | 大貫 敏史 |
| 代理人 | 稲葉 良幸 |