• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
管理番号 1340807
審判番号 不服2017-700  
総通号数 223 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-07-27 
種別 拒絶査定不服の審決 
審判請求日 2017-01-18 
確定日 2018-06-19 
事件の表示 特願2013-544627「異種処理デバイスの動的ワークパーティション」拒絶査定不服審判事件〔平成24年 6月21日国際公開,WO2012/082557,平成26年 4月10日国内公表,特表2014-508982,請求項の数(22)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由 第1 手続の経緯
本件審判請求に係る出願(以下,「本願」という。)は,2011年12月9日(パリ条約による優先権主張外国庁受理2010年12月15日(以下,「優先日」という。),米国,2011年11月2日,米国)を国際出願日として出願したものであって,その手続の経緯は以下のとおりである。

平成25年 6月14日 :国内書面の提出
平成25年 8月14日 :翻訳文の提出
平成26年12月 8日 :手続補正書の提出
平成28年 1月19日付け :拒絶理由の通知
平成28年 4月25日 :意見書,手続補正書の提出
平成28年 9月14日付け :拒絶査定
平成29年 1月18日 :審判請求書,手続補正書の提出
平成29年12月 8日付け :拒絶理由の通知(当審)
平成30年 3月 9日 :意見書,手続補正書の提出

第2 本願発明
本願請求項1-22に係る発明(以下,それぞれ「本願発明1」-「本願発明22」という。)は,平成30年3月9日付けの手続補正で補正された特許請求の範囲の請求項1-22に記載された事項により特定される発明であり,本願発明1は以下のとおりの発明である。

「 【請求項1】
異種の処理デバイスにおいてワークロードのバランスをとるための方法であって,
複数のタスクを,第1の種類の1つ以上の第1のプロセッサ及び第2の種類の1つ以上の第2のプロセッサと通信可能に接続された共有キューに記憶するステップであって,前記複数のタスクの各々は,前記1つ以上の第1のプロセッサ上での実行のためのマイクロコードへの第1のポインタと,前記1つ以上の第2のプロセッサ上での実行のためのコンパイルされたコードへの第2のポインタと,を含み,前記1つ以上の第1のプロセッサの各々は,第1のデキューイングモジュールと,1つ以上の第1の処理コアと,を含み,前記1つ以上の第2のプロセッサの各々は,同期化モジュールと,第2のデキューイングモジュールと,1つ以上の第2の処理コアと,を含む,ステップと,
前記1つ以上の第2のプロセッサの少なくとも1つの同期化モジュールが,前記1つ以上の第1のプロセッサの各々の第1のデキューイングモジュール及び前記1つ以上の第2のプロセッサの各々の第2のデキューイングモジュールによる前記共有キューへのアクセスを,同期化のための不可分操作を用いて同期するステップと,
前記1つ以上の第2のプロセッサの少なくとも1つの第2のデキューイングモジュールが,前記複数のタスクの中から特定のタスクをパラメータにより識別するステップと,
前記1つ以上の第2のプロセッサの少なくとも1つの第2のデキューイングモジュールが,前記1つ以上の第2のプロセッサで前記特定のタスクを実行するのに適切な状態において,前記共有キューから前記特定のタスクをデキューイングするステップと,
前記1つ以上の第2のプロセッサの少なくとも1つの第2のデキューイングモジュールが,前記第2のポインタによってポイントされた,前記コンパイルされたコードを実行するように,前記1つ以上の第2の処理コアに命令するステップと,
を含む,方法。」

なお,本願発明2-22の概要は以下のとおりである。

本願発明2-6,16-17は,本願発明1を減縮した発明である。

本願発明7は,本願発明1に対応する「システム」の発明であり,本願発明1とカテゴリ表現が異なるだけの発明である。また,本願発明8-11,18-19は,本願発明7を減縮した発明である。

本願発明12は,本願発明1に対応する「コンピュータ可読記憶媒体」の発明であり,本願発明1とカテゴリ表現が異なるだけの発明である。また,本願発明13-14,20-21は,本願発明12を減縮した発明である。

本願発明15は,本願発明1に対応する「システム」の発明である。また,本願発明22は,本願発明15を減縮した発明である。

第3 引用文献,引用発明等
1 引用文献1について
原査定の拒絶の理由に引用された引用文献1(特開平10-55284号公報)には,図面とともに次の事項が記載されている。

A 「【0024】
【発明の実施の形態】本発明は,マルチプロセッサ・スケジューリング・システムであり,リアル・タイム・アプリケーションについて説明する。 …(中略)…
【0025】マルチプロセッサ・システムでは,基本的に2つの資源割振り決定が行われる。1つは,コードとデータを物理メモリ内のどこに入れるかであり,もう一つは各プロセスをどのプロセッサで実行するかである。すなわち,割当て決定またはプロセッサ管理である。これらの決定は,マルチプロセッサ・システムでは難しい決定であり,マルチプロセッサ・システムではプロセッサ管理の最適化が重要である。
…(中略)…
【0028】本発明では,実行中のプロセスがブロックされまたは割り込まれるたびに,プロセス・スケジューラまたはディスパッチャがその機能を実行する。その目的は,実行可能キューのセットから次に実行するプロセスを選択することである。ディスパッチャはオペレーティング・システム・カーネルに常駐し,実行可能キューを監視し,要求を処理してアプリケーションをロードする。これには,アプリケーションのすべてのタスクとスレッドを作成し,メモリを確保し,コードとデータをメモリにロードする必要がある。アプリケーションが正常にロードされて実行可能になったと見なされる前に,すべての資源を確保する。したがって,ディスパッチャは,オペレーティング・システムのオーバーヘッドが最小になるようにするためにかなり効率が高くなければならない。
【0029】マルチプロセッサ・システムでは,リアル・タイム優先度スケジューリングは1つの制約,すなわち各プロセッサに対して,そのプロセッサで実行可能なスレッドよりも優先度が高いスレッドがどのキューにもないという制約を満たさなければならない。スループットの観点から見ると,各プロセッサがそれ自体のディスパッチ・キューを持っていて,それによってプロセッサ間のロック競合が最小限になるのが最もよい。」

B 「【0034】図4(A)に,本発明の好ましい実施形態による複数ディスパッチャ・キュー・システムを示す。図4(A)を参照すると,この複数ディスパッチャ・キュー・システムは,プロセッサ1,2,...,Nのための別々のディスパッチャ・キュー401,402,...,403と,その他に,高優先度リアル・タイム・スレッドを保持するために使用されるグローバル高優先度リアル・タイム・キュー404を備える。各ディスパッチ・キューはそれに関連づけられたそれ自体のスケジューリング・ロックを持ち,それによってすべてのスケジューリング操作を保護する。そのため,キューからスレッドをディスパッチしようとするプロセッサはそのキューからスレッドを取り出す前にそのキューのロックを獲得する必要がある。したがって,すべてのプロセッサのための単一のディスパッチ・キューに単一のスケジュール・ロックを使用する従来技術のスケジューラとは異なり,複数のディスパッチ・キューのために複数のスケジュール・ロックを使用する本発明ではロック競合が減少する。
【0035】
図4(A)の好ましい実施形態では,ディスパッチャはディスパッチ優先度によって索引づけされた1配列のディスパッチ・キューを使用する。また,スレッドが実行可能になるとそのスレッドはそのディスパッチ優先度に対応するディスパッチ・キューに(典型的には最後に)入れられる。しかし,FIFOスレッド・キューイングの代わりに他のキューイング方法を使用することもできる。リアル・タイム・アプリケーションのスケジューリング要件に応じて,たとえばLIFO(後入れ先出し),SJF(最短ジョブ優先),SRT(最短残り時間)またはその他の高度なキューイング機構を使用することができる。
【0036】図4(B)に,図4(A)のプロセッサ1のためにディスパッチ・キューを使用するディスパッチ・キュー構造の詳細を図示する。図4(B)で,何らかの優先度値を持つスレッド1,2,および3がディスパッチ・キューに入れられている。スレッド1はキューの先頭にあり,FIFOシステムを適用する場合には,その優先度カテゴリ内で実行のためにキューからディスパッチされる最初のスレッドとなる。図4(B)のスレッドは,それらのスレッドに関連づけられたプロセッサ・アフィニティ特性も有する。
【0037】
プロセッサ・アフィニティは,スレッドをどのプロセッサで実行することができるかを決定するために使用される。スレッドのほとんどはすべてのプロセッサで実行可能であり,したがってそのようにラベルづけされる。しかし,特定のプロセッサだけで実行可能であって,他のプロセッサでは実行することができないスレッドがある。このスレッドには,その特定の指定プロセッサに対するプロセッサ・アフィニティが与えられる。スレッドが特定のプロセッサに対するアフィニティを持っている場合,そのスレッドは他のプロセッサによって奪われたり,他のプロセッサに移行したりすることはできない。たとえば図4(B)のスレッド2はプロセッサ1に対するプロセッサアフィニティを持ち,プロセッサ1でのみ実行可能である。したがって,1つのプロセッサでのみ実行可能なスレッド,すなわち制限されたスレッドは,制限されたプロセッサのディスパッチ・キューにのみ入れられ,そのプロセッサによってのみディスパッチされる。
【0038】プロセッサが他のプロセッサからスレッドを奪うことができるためには,そのスレッドは奪う側のプロセッサで実行可能でなければならない。たとえば,図4(B)を参照すると,スレッド1および3は,プロセッサ1以外のプロセッサが奪い,キューから取り出し,実行することができる。」

C 「【0039】図5に,本発明の好ましい実施形態によるマルチプロセッサ・システムの構成を示す。各プロセッサ1,2,...,Nは,図5に示すようにそれ自体のスケジューラとディスパッチ・キューを持つ。たとえば,プロセッサ1はバスを介してそれに結合されたスケジューラ505とディスパッチ・キュー509を持つ。システム・プロセッサで実行するためにいつどのスレッドをディスパッチするかは,スケジューラまたはディスパッチャが決定する。スケジューラ1,2,...,Nと,したがってプロセッサ1,2,...Nは,バスを介してグローバル高優先度リアル・タイム・キュー501および共有メモリ503に結合されている。スレッドは,すべてのプロセッサによって共有される同期オブジェクトを使用して相互作用することができる。
…(中略)…
【0042】図5のどのプロセッサも,実行のためにスレッドをシステム内のどのキューにでも入れることができる。たとえば,プロセッサ1は,新しいスレッドが特定のプロセッサ・アフィニティ特性を持っていない限り,新しいスレッドをそれ自体のキュー,グローバル高優先度リアル・タイム・キュー,または他のプロセッサのキューに入れることができる。」

D 「【0044】プロセッサ上でスレッドをディスパッチまたはスケジュールするには,プロセッサは実行するスレッドを見つける必要がある。図6に,選択および検証方式を使用してプロセッサ上で実行するスレッドをスケジュールするディスパッチャについて説明するフローチャートを示す。
【0045】図6を参照すると,ステップ601で,次のスレッドの実行が可能になったプロセッサが,高優先度リアル・タイム・キュー内に項目がないかどうかを調べることによって,実行するスレッドの選択を開始する。図7に,ステップ601のスレッド選択プロセスを詳述するフローチャートを示す。
…(中略)…
【0047】次に図7を参照すると,決定ブロック701でリアル・タイム・キューがそれ自体のディスパッチ・キューよりも優先度の高いスレッドを持っている場合,プロセッサ・ディスパッチャはステップ702でリアル・タイム・キューのロックを獲得し,図4のキュー404のようなリアル・タイム・キューから最高の優先度のスレッドを取り出し,そのスレッドの実行に移る。
【0048】次のスレッドを取り出せるようになったプロセッサは,それ自体のキューを調べる前にまずリアル・タイム・キューを調べ,それによってそのプロセッサ自体のキュー内のスレッドの前により優先度の高いリアル・タイム・キュー内のスレッドを処理して,リアル・タイム・スレッドに可能な最も速いサービスを提供する。決定ブロック701で,リアル・タイム・キューに実行可能なより優先度の高いスレッドがなくなったと判断された場合,プロセッサはステップ703に進んでそれ自体のディスパッチ・キューに実行可能なスレッドがないか調べる。それ自体のキューが空でない場合,プロセッサはステップ704に進んでそれ自体のキューのロックを獲得し,それ自体のキューから最高の優先度のスレッドを取り出す。
【0049】プロセッサ自体のディスパッチ・キューが空の場合,プロセッサはステップ705に進み,他のプロセッサのディスパッチ・キューを調べて実行可能スレッドを見つける。他のいずれかのディスパッチ・キュー内に特定のプロセッサ・アフィニティを持たない実行可能スレッドがある場合,プロセッサはそのディスパッチ・キューのスケジューリング・ロックを獲得し,ステップ706に進んでその別のプロセッサからスレッドを奪う。」

したがって,上記引用文献1には次の発明(以下,「引用発明」という。)が記載されていると認められる。

「スレッドを処理する複数のプロセッサと,各プロセッサのための複数のディスパッチキューおよび複数のスケジューラと,共有メモリとを備えたマルチプロセッサシステムにおけるスレッドのスケジュール方法であって,
プロセッサは,新しいスレッドをディスパッチキューに入れ,
プロセッサは,次のスレッドの実行が可能となると,当該プロセッサのスケジューラが自身のディスパッチキューを調べ,当該ディスパッチキューが空でない場合,当該ディスパッチキューのロックを獲得し,最高の優先度のスレッドを取り出し,
当該プロセッサ自身のディスパッチキューが空の場合,当該プロセッサのスケジューラが他のプロセッサのディスパッチキューを調べ,他のディスパッチキューに特定のプロセッサ・アフィニティを持たない実行可能なスレッドがある場合,当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し,当該ディスパッチキューから前記スレッドを取り出し,
前記プロセッサは,取り出した前記スレッドを実行する方法。」

2 引用文献2について
原査定の拒絶の理由に引用された引用文献2(特開2003-167726号公報)の段落【0036】の記載からみて,当該引用文献2には,「キューをハードウェアで構成することもソフトウェアで構成することも可能である」という技術的事項が記載されていると認められる。

3 引用文献3について
原査定の拒絶の理由に引用された引用文献3(特表2009-510613号公報)の段落【0025】の記載からみて,当該引用文献3には,「アクセス同期を行う場合に,アトミック・ミューテックスを利用してロックを行う」という技術的事項(以下,「引用文献3記載技術」という。)が記載されていると認められる。

第4 対比・判断
1 本願発明1について
(1)対比
本願発明1と引用発明とを対比すると,次のことがいえる。
ア 引用発明は,「スレッドを処理する複数のプロセッサと,各プロセッサのための複数のディスパッチキューおよび複数のスケジューラと,共有メモリとを備えたマルチプロセッサシステムにおけるスレッドのスケジュール方法」であるところ,「スレッド」は「ディスパッチキュー」で管理されるプロセッサの処理単位であって,“タスク”の態様の1つであることから,本願発明1の「タスク」に相当するといえる。
一方,本願発明1は,「異種の処理デバイスにおいてワークロードのバランスをとるための方法」であって,「異種の処理デバイス」は,複数の「第1のプロセッサ」および「第2のプロセッサ」を含み,「ワークロードのバランスをとる」とは,「異種の処理デバイス」にける「タスク」処理による「ワークロード」がバランスするようにスケジュールすると解されるから,上位概念では“タスクをスケジュールするための方法”であるといえる。
そうすると,引用発明の「スレッドを処理する複数のプロセッサと,各プロセッサのための複数のディスパッチキューおよび複数のスケジューラと,共有メモリとを備えたマルチプロセッサシステムにおけるスレッドのスケジュール方法」と,
本願発明1の「異種の処理デバイスにおいてワークロードのバランスをとるための方法」とは,後記する点で相違するものの,
“複数の処理デバイスにおいてタスクをスケジュールするための方法”である点で共通しているといえる。

イ 引用発明では,「プロセッサは,新しいスレッドをディスパッチキューに入れ」るところ,上記アでの検討より,引用発明の「スレッド」は本願発明1の「タスク」に相当し,「ディスパッチキュー」は各プロセッサに対応して設置されているものの,複数のプロセッサがアクセス可能な“キュー”であることから,“複数のタスクを,複数のプロセッサと通信可能に接続されたキューに記憶する”といえる。
また,引用発明の各「プロセッサ」は「ディスパッチキュー」を備え,「スレッド」の格納,取り出し処理を実行することから,実質的に“デキューイングモジュール”を有しているといえ,さらに,処理を実行するためのハードウェアとして“処理コア”を有していることも明らかである。
そうすると,引用発明の「プロセッサは,新しいスレッドをディスパッチキューに入れ」,「各プロセッサ」は「ディスパッチキュー」を備えることと,
本願発明1の「複数のタスクを,第1の種類の1つ以上の第1のプロセッサ及び第2の種類の1つ以上の第2のプロセッサと通信可能に接続された共有キューに記憶するステップであって,前記複数のタスクの各々は,前記1つ以上の第1のプロセッサ上での実行のためのマイクロコードへの第1のポインタと,前記1つ以上の第2のプロセッサ上での実行のためのコンパイルされたコードへの第2のポインタと,を含み,前記1つ以上の第1のプロセッサの各々は,第1のデキューイングモジュールと,1つ以上の第1の処理コアと,を含み,前記1つ以上の第2のプロセッサの各々は,同期化モジュールと,第2のデキューイングモジュールと,1つ以上の第2の処理コアと,を含む,ステップ」とは,後記する点で相違するものの,
“複数のタスクを,複数のプロセッサと通信可能に接続されたキューに記憶するステップであって,前記プロセッサの各々は,デキューイングモジュールと,1つ以上の処理コアと,を含む,ステップ”である点で共通しているといえる。

ウ 引用発明では,「当該ディスパッチキューのロックを獲得し,最高の優先度のスレッドを取り出し」,あるいは,「当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し,当該ディスパッチキューから前記スレッドを取り出」すところ,上記イでの検討より,実質的に“デキューイングモジュール”を有しているといえ,「ロック」を用いて「ディスパッチキュー」から「スレッド」を取り出すことは,上位概念では,“タスク”へのアクセスの“排他的制御”を用いた“同期”であるといえるから,“デキューイングモジュール”による“キュー”へのアクセスを“排他的制御を用いて同期する”こととみることができる。
また,本願発明1の「前記1つ以上の第1のプロセッサの各々の第1のデキューイングモジュール及び前記1つ以上の第2のプロセッサの各々の第2のデキューイングモジュールによる前記共有キューへのアクセスを,同期化のための不可分操作を用いて同期する」ことは,「同期化のための不可分操作」が“同期”のための“排他的制御”の態様の1つであることから,“デキューイングモジュール”による“キュー”へのアクセスを“排他的制御を用いて同期する”ことといえる。
そうすると,引用発明の「当該ディスパッチキューのロックを獲得し,最高の優先度のスレッドを取り出し」,あるいは,「当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し,当該ディスパッチキューから前記スレッドを取り出す」ことと,
本願発明1の「前記1つ以上の第2のプロセッサの少なくとも1つの同期化モジュールが,前記1つ以上の第1のプロセッサの各々の第1のデキューイングモジュール及び前記1つ以上の第2のプロセッサの各々の第2のデキューイングモジュールによる前記共有キューへのアクセスを,同期化のための不可分操作を用いて同期するステップ」とは,後記する点で相違するものの,
“前記プロセッサの各々のデキューイングモジュールによる前記キューへのアクセスを,同期化のための排他的制御を用いて同期するステップ”である点で共通しているといえる。

エ 引用発明では,「当該プロセッサのスケジューラが他のプロセッサのディスパッチキューを調べ,他のディスパッチキューに特定のプロセッサ・アフィニティを持たない実行可能なスレッドがある場合,当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得」するところ,引用文献1の上記Bの段落【0036】-【0037】の記載からすると,「プロセッサ・アフィニティ」は「スレッド」に対応付けられた実行可能プロセッサを決定するための特性値であり,「スレッド」を識別するための“パラメータ”といえるから,“デキューイングモジュール”が“キュー”に記憶された複数の“タスク”の中から特定の“タスク”を“パラメータ”により識別するとみることができる。

オ 引用発明では,「他のディスパッチキューに特定のプロセッサ・アフィニティを持たない実行可能なスレッドがある場合,当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し,当該ディスパッチキューから前記スレッドを取り出」すところ,「ディスパッチキュー」に記憶された「スレッド」が「特定のプロセッサ・アフィニティを持たない実行可能」であるとは,特定の「スレッド」の「プロセッサ・アフィニティ」が「当該プロセッサ」の実行に適した状態を示していると解されることから,特定の“タスク”が“実行するのに適切な状態”において,“キュー”から特定の“タスク”をデキューイングするとみることができる。
そうすると,上記エでの検討も踏まえると,引用発明の「当該プロセッサのスケジューラが他のプロセッサのディスパッチキューを調べ,他のディスパッチキューに特定のプロセッサ・アフィニティを持たない実行可能なスレッドがある場合,当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し,当該ディスパッチキューから前記スレッドを取り出」すことと,
本願発明1の「前記1つ以上の第2のプロセッサの少なくとも1つの第2のデキューイングモジュールが,前記複数のタスクの中から特定のタスクをパラメータにより識別するステップ」,
「前記1つ以上の第2のプロセッサの少なくとも1つの第2のデキューイングモジュールが,前記1つ以上の第2のプロセッサで前記特定のタスクを実行するのに適切な状態において,前記共有キューから前記特定のタスクをデキューイングするステップ」とは,後記する点で相違するものの,
“前記プロセッサの少なくとも1つのデキューイングモジュールが,前記複数のタスクの中から特定のタスクをパラメータにより識別するステップ”,
“前記プロセッサの少なくとも1つのデキューイングモジュールが,前記プロセッサで前記特定のタスクを実行するのに適切な状態において,前記キューから前記特定のタスクをデキューイングするステップ”である点で共通しているといえる。

カ 引用発明では,「前記プロセッサは,取り出した前記スレッドを実行する」ところ,「スレッド」を「ディスパッチキュー」からデキューイングすると解され,上記イでの検討より,「プロセッサ」は「スレッド」を実行する“処理コア”を有し,“デキューイングモジュール”が“処理コア”に「スレッド」を実行するよう命令することは明らかであることから,“デキューイングモジュール”が“キュー”からデキューイングされた特定の“タスク”を実行するように,“処理コア”に命令するといえる。
そうすると,引用発明の「前記プロセッサは,取り出した前記スレッドを実行する」ことと,
本願発明1の「前記1つ以上の第2のプロセッサの少なくとも1つの第2のデキューイングモジュールが,前記第2のポインタによってポイントされた,前記コンパイルされたコードを実行するように,前記1つ以上の第2の処理コアに命令するステップ」とは,後記する点で相違するものの,
“前記プロセッサの少なくとも1つのデキューイングモジュールが,デキューイングされた前記特定のタスクを実行するように,前記1つ以上の処理コアに命令するステップ”である点で共通しているといえる。

したがって,本願発明1と引用発明との間には,次の一致点,相違点があるといえる。

(一致点)
「 複数の処理デバイスにおいてタスクをスケジュールするための方法であって,
複数のタスクを,複数のプロセッサと通信可能に接続されたキューに記憶するステップであって,前記プロセッサの各々は,デキューイングモジュールと,1つ以上の処理コアと,を含む,ステップと,
前記プロセッサの各々のデキューイングモジュールによる前記キューへのアクセスを,同期化のための排他的制御を用いて同期するステップと,
前記プロセッサの少なくとも1つのデキューイングモジュールが,前記複数のタスクの中から特定のタスクをパラメータにより識別するステップと,
前記プロセッサの少なくとも1つのデキューイングモジュールが,前記プロセッサで前記特定のタスクを実行するのに適切な状態において,前記キューから前記特定のタスクをデキューイングするステップと,
前記プロセッサの少なくとも1つのデキューイングモジュールが,デキューイングされた前記特定のタスクを実行するように,前記1つ以上の処理コアに命令するステップと,
を含む,方法。」

(相違点)
(相違点1)
本願発明1は,「異種の処理デバイスにおいてワークロードのバランスをとるための方法」であるのに対して,
引用発明は,「スレッドを処理する複数のプロセッサと,各プロセッサのための複数のディスパッチキューおよび複数のスケジューラと,共有メモリとを備えたマルチプロセッサシステムにおけるスレッドのスケジュール方法」である点。

(相違点2)
タスクをキューに記憶することに関し,本願発明1は,「複数のタスクを,第1の種類の1つ以上の第1のプロセッサ及び第2の種類の1つ以上の第2のプロセッサと通信可能に接続された共有キューに記憶するステップであって,前記複数のタスクの各々は,前記1つ以上の第1のプロセッサ上での実行のためのマイクロコードへの第1のポインタと,前記1つ以上の第2のプロセッサ上での実行のためのコンパイルされたコードへの第2のポインタと,を含み,前記1つ以上の第1のプロセッサの各々は,第1のデキューイングモジュールと,1つ以上の第1の処理コアと,を含み,前記1つ以上の第2のプロセッサの各々は,同期化モジュールと,第2のデキューイングモジュールと,1つ以上の第2の処理コアと,を含む,ステップ」を含むのに対して,
引用発明では,「プロセッサは,新しいスレッドをディスパッチキューに入れ」,「各プロセッサ」は「ディスパッチキュー」を備えるものの,「第1の種類」の「第1のプロセッサ」及び「第2の種類」の「第2のプロセッサ」が1つの「共有キュー」に,「第1のプロセッサ上での実行のためのマイクロコードへの第1のポインタ」と,「第2のプロセッサ上での実行のためのコンパイルされたコードへの第2のポインタ」とを含むタスクを記憶することは特定されていない点。

(相違点3)
キューへのアクセス同期に関し,本願発明1は,「前記1つ以上の第2のプロセッサの少なくとも1つの同期化モジュールが,前記1つ以上の第1のプロセッサの各々の第1のデキューイングモジュール及び前記1つ以上の第2のプロセッサの各々の第2のデキューイングモジュールによる前記共有キューへのアクセスを,同期化のための不可分操作を用いて同期するステップ」を含むのに対して,
引用発明では,「ディスパッチキューのロックを獲得し,当該ディスパッチキューから前記スレッドを取り出す」ものの,「共有キュー」へのアクセスを,同期化のための「不可分操作」を用いて同期することは特定されていない点。

(相違点4)
タスクのパラメータの識別に関し,本願発明1は,「1つ以上の第2のプロセッサの少なくとも1つの第2のデキューイングモジュールが,前記複数のタスクの中から特定のタスクをパラメータにより識別するステップ」を含むのに対して,
引用発明では,複数の「スレッド」の中から特定の「スレッド」を「プロセッサ・アフィニティ」により識別するものの,「第2のプロセッサの少なくとも1つの第2のデキューイングモジュール」が識別することは特定されていない点。

(相違点5)
タスクのデキューイングに関し,本願発明1は,「前記1つ以上の第2のプロセッサの少なくとも1つの第2のデキューイングモジュールが,前記1つ以上の第2のプロセッサで前記特定のタスクを実行するのに適切な状態において,前記共有キューから前記特定のタスクをデキューイングするステップ」を含むのに対して,
引用発明では,特定の「スレッド」の「プロセッサ・アフィニティ」が適切な状態において,「ディスパッチキュー」から当該「スレッド」をデキューイングするものの,「第2のプロセッサの少なくとも1つの第2のデキューイングモジュール」が「共有キュー」からデキューイングすることは特定されていない点。

(相違点6)
タスクの実行に関し,本願発明1は,「前記1つ以上の第2のプロセッサの少なくとも1つの第2のデキューイングモジュールが,前記第2のポインタによってポイントされた,前記コンパイルされたコードを実行するように,前記1つ以上の第2の処理コアに命令するステップ」を含むのに対して,
引用発明は,「プロセッサは,取り出した前記スレッドを実行する」ものの,「第2のデキューイングモジュールが,前記第2のポインタによってポイントされた,前記コンパイルされたコードを実行するように,前記1つ以上の第2の処理コアに命令する」ことは特定されていない点。

(2)相違点についての判断
ア 相違点2について
事案に鑑みて,上記相違点2を先に検討すると,引用発明では,各「プロセッサ」は「ディスパッチキュー」を備え,新しい「スレッド」は各「プロセッサ」の「ディスパッチキュー」に入れて記憶するものであるが,引用文献1の上記Bの段落【0034】の「各ディスパッチ・キューはそれに関連づけられたそれ自体のスケジューリング・ロックを持ち,それによってすべてのスケジューリング操作を保護する。そのため,キューからスレッドをディスパッチしようとするプロセッサはそのキューからスレッドを取り出す前にそのキューのロックを獲得する必要がある。したがって,すべてのプロセッサのための単一のディスパッチ・キューに単一のスケジュール・ロックを使用する従来技術のスケジューラとは異なり,複数のディスパッチ・キューのために複数のスケジュール・ロックを使用する本発明ではロック競合が減少する。」との記載からすると,「単一のディスパッチ・キュー」で管理しないことを特徴としており,CPU,GPUなど異なる種類のプロセッサの間で,特定のプロセッサに設置されたものでない共有のキューを用いてタスクを管理することについて,動機付けは認められない。
そして,引用発明は,異なる種類のプロセッサの間で共有キューを管理するものではないから,引用文献1には,共有キューで管理されるタスクが,第1のプロセッサ上での実行のためのマイクロコードへの第1のポインタと,第2のプロセッサ上での実行のためのコンパイルされたコードへの第2のポインタと,を含むことについて記載も示唆もされていない。そのような構成は,引用文献3記載技術,引用文献2に記載の周知技術からも適宜なし得たものではない。
加えて,複数のタスクを,第1の種類の第1のプロセッサ及び第2の種類の第2のプロセッサと通信可能に接続された共有キューに記憶し,複数のタスクの各々は,第1のプロセッサ上での実行のためのマイクロコードへの第1のポインタと,第2のプロセッサ上での実行のためのコンパイルされたコードへの第2のポインタと,を含む旨の技術が本願の優先日前に当該技術分野の周知技術であったとはいえない。
そうすると,引用発明において,複数のタスクを,第1の種類の1つ以上の第1のプロセッサ及び第2の種類の1つ以上の第2のプロセッサと通信可能に接続された共有キューに記憶するステップであって,前記複数のタスクの各々は,前記1つ以上の第1のプロセッサ上での実行のためのマイクロコードへの第1のポインタと,前記1つ以上の第2のプロセッサ上での実行のためのコンパイルされたコードへの第2のポインタと,を含み,前記1つ以上の第1のプロセッサの各々は,第1のデキューイングモジュールと,1つ以上の第1の処理コアと,を含み,前記1つ以上の第2のプロセッサの各々は,同期化モジュールと,第2のデキューイングモジュールと,1つ以上の第2の処理コアと,を含む,ステップを構成すること,すなわち,上記相違点2に係る構成とすることは,当業者が適宜なし得たものであるとすることはできない。

イ まとめ
上記相違点1,3-6について判断するまでもなく,本願発明1は,当業者であっても,引用発明,引用文献3記載技術及び引用文献2に記載の周知技術に基づいて容易に発明できたものとはいえない。

2 本願発明2-6,16-17について
本願発明2-6,16-17は,本願発明1を減縮した発明であり,本願発明1の
「複数のタスクを,第1の種類の1つ以上の第1のプロセッサ及び第2の種類の1つ以上の第2のプロセッサと通信可能に接続された共有キューに記憶するステップであって,前記複数のタスクの各々は,前記1つ以上の第1のプロセッサ上での実行のためのマイクロコードへの第1のポインタと,前記1つ以上の第2のプロセッサ上での実行のためのコンパイルされたコードへの第2のポインタと,を含み,前記1つ以上の第1のプロセッサの各々は,第1のデキューイングモジュールと,1つ以上の第1の処理コアと,を含み,前記1つ以上の第2のプロセッサの各々は,同期化モジュールと,第2のデキューイングモジュールと,1つ以上の第2の処理コアと,を含む,ステップ」(以下,「相違点2に係る構成」という。)
と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献3記載技術及び引用文献2に記載の周知技術に基づいて容易に発明できたものとはいえない。

3 本願発明7-11,18-19について
本願発明7は,本願発明1に対応する「システム」の発明であり,本願発明8-11,18-19は,本願発明7を減縮した発明であり,本願発明1の「相違点2に係る構成」に対応する構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献3記載技術及び引用文献2に記載の周知技術に基づいて容易に発明できたものとはいえない。

4 本願発明12-14,20-21について
本願発明12は,本願発明1に対応する「コンピュータ可読記憶媒体」の発明であり,本願発明13-14,20-21は,本願発明12を減縮した発明であり,本願発明1の「相違点2に係る構成」に対応する構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献3記載技術及び引用文献2に記載の周知技術に基づいて容易に発明できたものとはいえない。

5 本願発明15,22について
本願発明15は,本願発明1に対応する「システム」の発明であり,本願発明22は,本願発明15を減縮した発明であり,本願発明1の「相違点2に係る構成」に対応する構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献3記載技術及び引用文献2に記載の周知技術に基づいて容易に発明できたものとはいえない。

第5 原査定の概要及び原査定についての判断
原査定は,請求項1-23について上記引用文献1-3に記載された発明に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができない,というものである。
しかしながら,平成30年3月9日付け手続補正により補正された請求項1,7,12,15はそれぞれ,「相違点2に係る構成」という事項,前記事項に対応する構成を有するものとなっており,上記のとおり,本願発明1-22は,引用発明,引用文献3記載技術及び引用文献2に記載の周知技術に基づいて,当業者が容易に発明できたものではない。
したがって,原査定を維持することはできない。

第6 当審拒絶理由について
<特許法第36条第6項第2号について>
(1)当審では,請求項1-6,12-14,16-17,20-21の「前記複数のタスクの中から特定のタスクを読み出すステップ」が特定する事項が不明確であるとの拒絶の理由を通知しているが,平成30年3月9日付けの手続補正により,「前記複数のタスクの中から特定のタスクをパラメータにより識別するステップ」と補正された結果,この拒絶の理由は解消した。

(2)当審では,請求項7-11,15,18-19,22の「前記複数のタスクの中から前記特定のタスクを読み出し」が特定する事項が不明確であるとの拒絶の理由を通知しているが,平成30年3月9日付けの手続補正により,「前記複数のタスクの中から前記特定のタスクをパラメータにより識別し」と補正された結果,この拒絶の理由は解消した。

(3)当審では,請求項16の「前記複数のタスクの中から他の特定のタスクを読み出すステップ」が特定する事項が不明確であるとの拒絶の理由を通知しているが,平成30年3月9日付けの手続補正により,「前記複数のタスクの中から他の特定のタスクをパラメータにより識別するステップ」と補正された結果,この拒絶の理由は解消した。

(4)当審では,請求項2-4,8,13の「前記1つ以上の第2のプロセッサは,中央処置装置(CPU)と,アクセラレーテッドプロセッシングデバイス(APD)を含む前記1つ以上の第1のプロセッサと,を含む,」が特定する事項が不明確であるとの拒絶の理由を通知しているが,平成30年3月9日付けの手続補正により,「前記1つ以上の第2のプロセッサは,中央処置装置(CPU)を含み,前記1つ以上の第1のプロセッサは,アクセラレーテッドプロセッシングデバイス(APD)を含む」と補正された結果,この拒絶の理由は解消した。

(5)当審では,請求項3の「前記1つ以上の第2のプロセッサの第1のデキューイングモジュールは,ハードウェアデバイスである,請求項2に記載の方法」における「第2のプロセッサ」は誤記であるとの拒絶の理由を通知しているが,平成30年3月9日付けの手続補正により,「第1のプロセッサ」と補正された結果,この拒絶の理由は解消した。

(6)当審では,請求項4の「前記1つ以上の第1のプロセッサの第2のデキューイングモジュールは,ソフトウェアモジュールである,請求項2に記載の方法」における「第1のプロセッサ」は誤記であるとの拒絶の理由を通知しているが,平成30年3月9日付けの手続補正により,「第2のプロセッサ」と補正された結果,この拒絶の理由は解消した。

(7)当審では,請求項9の「前記1つ以上の第1のプロセッサの第2のデキューイングモジュールは,ハードウェアデバイスである,請求項7に記載のシステム」における「第2のデキューイングモジュール」は誤記であるとの拒絶の理由を通知しているが,平成30年3月9日付けの手続補正により,「第1のデキューイングモジュール」と補正された結果,この拒絶の理由は解消した。

第7 むすび
以上のとおり,本願発明1-22は,当業者が引用発明,引用文献3記載技術及び引用文献2に記載の周知技術に基づいて容易に発明をすることができたものではない。したがって,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2018-06-06 
出願番号 特願2013-544627(P2013-544627)
審決分類 P 1 8・ 537- WY (G06F)
P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 漆原 孝治  
特許庁審判長 仲間 晃
特許庁審判官 須田 勝巳
辻本 泰隆
発明の名称 異種処理デバイスの動的ワークパーティション  
代理人 早川 裕司  
代理人 佐野 良太  
代理人 村雨 圭介  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ