【事件の表示】
　特願２０１３−５４４６２７「異種処理デバイスの動的ワークパーティション」拒絶査定不服審判事件〔平成２４年　６月２１日国際公開，ＷＯ２０１２／０８２５５７，平成２６年　４月１０日国内公表，特表２０１４−５０８９８２，請求項の数（２２）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願（以下，「本願」という。）は，２０１１年１２月９日（パリ条約による優先権主張外国庁受理２０１０年１２月１５日（以下，「優先日」という。），米国，２０１１年１１月２日，米国）を国際出願日として出願したものであって，その手続の経緯は以下のとおりである。
　　平成２５年　６月１４日　　　：国内書面の提出
　　平成２５年　８月１４日　　　：翻訳文の提出
　　平成２６年１２月　８日　　　：手続補正書の提出
　　平成２８年　１月１９日付け　：拒絶理由の通知
　　平成２８年　４月２５日　　　：意見書，手続補正書の提出
　　平成２８年　９月１４日付け　：拒絶査定
　　平成２９年　１月１８日　　　：審判請求書，手続補正書の提出
　　平成２９年１２月　８日付け　：拒絶理由の通知（当審）
　　平成３０年　３月　９日　　　：意見書，手続補正書の提出
第２　本願発明
　本願請求項１−２２に係る発明（以下，それぞれ「本願発明１」−「本願発明２２」という。）は，平成３０年３月９日付けの手続補正で補正された特許請求の範囲の請求項１−２２に記載された事項により特定される発明であり，本願発明１は以下のとおりの発明である。
「　　【請求項１】
　異種の処理デバイスにおいてワークロードのバランスをとるための方法であって，
　複数のタスクを，第１の種類の１つ以上の第１のプロセッサ及び第２の種類の１つ以上の第２のプロセッサと通信可能に接続された共有キューに記憶するステップであって，前記複数のタスクの各々は，前記１つ以上の第１のプロセッサ上での実行のためのマイクロコードへの第１のポインタと，前記１つ以上の第２のプロセッサ上での実行のためのコンパイルされたコードへの第２のポインタと，を含み，前記１つ以上の第１のプロセッサの各々は，第１のデキューイングモジュールと，１つ以上の第１の処理コアと，を含み，前記１つ以上の第２のプロセッサの各々は，同期化モジュールと，第２のデキューイングモジュールと，１つ以上の第２の処理コアと，を含む，ステップと，
　前記１つ以上の第２のプロセッサの少なくとも１つの同期化モジュールが，前記１つ以上の第１のプロセッサの各々の第１のデキューイングモジュール及び前記１つ以上の第２のプロセッサの各々の第２のデキューイングモジュールによる前記共有キューへのアクセスを，同期化のための不可分操作を用いて同期するステップと，
　前記１つ以上の第２のプロセッサの少なくとも１つの第２のデキューイングモジュールが，前記複数のタスクの中から特定のタスクをパラメータにより識別するステップと，
　前記１つ以上の第２のプロセッサの少なくとも１つの第２のデキューイングモジュールが，前記１つ以上の第２のプロセッサで前記特定のタスクを実行するのに適切な状態において，前記共有キューから前記特定のタスクをデキューイングするステップと，
　前記１つ以上の第２のプロセッサの少なくとも１つの第２のデキューイングモジュールが，前記第２のポインタによってポイントされた，前記コンパイルされたコードを実行するように，前記１つ以上の第２の処理コアに命令するステップと，
　を含む，方法。」
　なお，本願発明２−２２の概要は以下のとおりである。
　本願発明２−６，１６−１７は，本願発明１を減縮した発明である。
　本願発明７は，本願発明１に対応する「システム」の発明であり，本願発明１とカテゴリ表現が異なるだけの発明である。また，本願発明８−１１，１８−１９は，本願発明７を減縮した発明である。
　本願発明１２は，本願発明１に対応する「コンピュータ可読記憶媒体」の発明であり，本願発明１とカテゴリ表現が異なるだけの発明である。また，本願発明１３−１４，２０−２１は，本願発明１２を減縮した発明である。
　本願発明１５は，本願発明１に対応する「システム」の発明である。また，本願発明２２は，本願発明１５を減縮した発明である。
第３　引用文献，引用発明等
１　引用文献１について
　原査定の拒絶の理由に引用された引用文献１（特開平１０−５５２８４号公報）には，図面とともに次の事項が記載されている。
Ａ　「【００２４】
【発明の実施の形態】本発明は，マルチプロセッサ・スケジューリング・システムであり，リアル・タイム・アプリケーションについて説明する。　…（中略）…
【００２５】マルチプロセッサ・システムでは，基本的に２つの資源割振り決定が行われる。１つは，コードとデータを物理メモリ内のどこに入れるかであり，もう一つは各プロセスをどのプロセッサで実行するかである。すなわち，割当て決定またはプロセッサ管理である。これらの決定は，マルチプロセッサ・システムでは難しい決定であり，マルチプロセッサ・システムではプロセッサ管理の最適化が重要である。
…（中略）…
【００２８】本発明では，実行中のプロセスがブロックされまたは割り込まれるたびに，プロセス・スケジューラまたはディスパッチャがその機能を実行する。その目的は，実行可能キューのセットから次に実行するプロセスを選択することである。ディスパッチャはオペレーティング・システム・カーネルに常駐し，実行可能キューを監視し，要求を処理してアプリケーションをロードする。これには，アプリケーションのすべてのタスクとスレッドを作成し，メモリを確保し，コードとデータをメモリにロードする必要がある。アプリケーションが正常にロードされて実行可能になったと見なされる前に，すべての資源を確保する。したがって，ディスパッチャは，オペレーティング・システムのオーバーヘッドが最小になるようにするためにかなり効率が高くなければならない。
【００２９】マルチプロセッサ・システムでは，リアル・タイム優先度スケジューリングは１つの制約，すなわち各プロセッサに対して，そのプロセッサで実行可能なスレッドよりも優先度が高いスレッドがどのキューにもないという制約を満たさなければならない。スループットの観点から見ると，各プロセッサがそれ自体のディスパッチ・キューを持っていて，それによってプロセッサ間のロック競合が最小限になるのが最もよい。」
Ｂ　「【００３４】図４（Ａ）に，本発明の好ましい実施形態による複数ディスパッチャ・キュー・システムを示す。図４（Ａ）を参照すると，この複数ディスパッチャ・キュー・システムは，プロセッサ１，２，．．．，Ｎのための別々のディスパッチャ・キュー４０１，４０２，．．．，４０３と，その他に，高優先度リアル・タイム・スレッドを保持するために使用されるグローバル高優先度リアル・タイム・キュー４０４を備える。各ディスパッチ・キューはそれに関連づけられたそれ自体のスケジューリング・ロックを持ち，それによってすべてのスケジューリング操作を保護する。そのため，キューからスレッドをディスパッチしようとするプロセッサはそのキューからスレッドを取り出す前にそのキューのロックを獲得する必要がある。したがって，すべてのプロセッサのための単一のディスパッチ・キューに単一のスケジュール・ロックを使用する従来技術のスケジューラとは異なり，複数のディスパッチ・キューのために複数のスケジュール・ロックを使用する本発明ではロック競合が減少する。
【００３５】
図４（Ａ）の好ましい実施形態では，ディスパッチャはディスパッチ優先度によって索引づけされた１配列のディスパッチ・キューを使用する。また，スレッドが実行可能になるとそのスレッドはそのディスパッチ優先度に対応するディスパッチ・キューに（典型的には最後に）入れられる。しかし，ＦＩＦＯスレッド・キューイングの代わりに他のキューイング方法を使用することもできる。リアル・タイム・アプリケーションのスケジューリング要件に応じて，たとえばＬＩＦＯ（後入れ先出し），ＳＪＦ（最短ジョブ優先），ＳＲＴ（最短残り時間）またはその他の高度なキューイング機構を使用することができる。
【００３６】図４（Ｂ）に，図４（Ａ）のプロセッサ１のためにディスパッチ・キューを使用するディスパッチ・キュー構造の詳細を図示する。図４（Ｂ）で，何らかの優先度値を持つスレッド１，２，および３がディスパッチ・キューに入れられている。スレッド１はキューの先頭にあり，ＦＩＦＯシステムを適用する場合には，その優先度カテゴリ内で実行のためにキューからディスパッチされる最初のスレッドとなる。図４（Ｂ）のスレッドは，それらのスレッドに関連づけられたプロセッサ・アフィニティ特性も有する。
【００３７】
プロセッサ・アフィニティは，スレッドをどのプロセッサで実行することができるかを決定するために使用される。スレッドのほとんどはすべてのプロセッサで実行可能であり，したがってそのようにラベルづけされる。しかし，特定のプロセッサだけで実行可能であって，他のプロセッサでは実行することができないスレッドがある。このスレッドには，その特定の指定プロセッサに対するプロセッサ・アフィニティが与えられる。スレッドが特定のプロセッサに対するアフィニティを持っている場合，そのスレッドは他のプロセッサによって奪われたり，他のプロセッサに移行したりすることはできない。たとえば図４（Ｂ）のスレッド２はプロセッサ１に対するプロセッサアフィニティを持ち，プロセッサ１でのみ実行可能である。したがって，１つのプロセッサでのみ実行可能なスレッド，すなわち制限されたスレッドは，制限されたプロセッサのディスパッチ・キューにのみ入れられ，そのプロセッサによってのみディスパッチされる。
【００３８】プロセッサが他のプロセッサからスレッドを奪うことができるためには，そのスレッドは奪う側のプロセッサで実行可能でなければならない。たとえば，図４（Ｂ）を参照すると，スレッド１および３は，プロセッサ１以外のプロセッサが奪い，キューから取り出し，実行することができる。」
Ｃ　「【００３９】図５に，本発明の好ましい実施形態によるマルチプロセッサ・システムの構成を示す。各プロセッサ１，２，．．．，Ｎは，図５に示すようにそれ自体のスケジューラとディスパッチ・キューを持つ。たとえば，プロセッサ１はバスを介してそれに結合されたスケジューラ５０５とディスパッチ・キュー５０９を持つ。システム・プロセッサで実行するためにいつどのスレッドをディスパッチするかは，スケジューラまたはディスパッチャが決定する。スケジューラ１，２，．．．，Ｎと，したがってプロセッサ１，２，．．．Ｎは，バスを介してグローバル高優先度リアル・タイム・キュー５０１および共有メモリ５０３に結合されている。スレッドは，すべてのプロセッサによって共有される同期オブジェクトを使用して相互作用することができる。
…（中略）…
【００４２】図５のどのプロセッサも，実行のためにスレッドをシステム内のどのキューにでも入れることができる。たとえば，プロセッサ１は，新しいスレッドが特定のプロセッサ・アフィニティ特性を持っていない限り，新しいスレッドをそれ自体のキュー，グローバル高優先度リアル・タイム・キュー，または他のプロセッサのキューに入れることができる。」
Ｄ　「【００４４】プロセッサ上でスレッドをディスパッチまたはスケジュールするには，プロセッサは実行するスレッドを見つける必要がある。図６に，選択および検証方式を使用してプロセッサ上で実行するスレッドをスケジュールするディスパッチャについて説明するフローチャートを示す。
【００４５】図６を参照すると，ステップ６０１で，次のスレッドの実行が可能になったプロセッサが，高優先度リアル・タイム・キュー内に項目がないかどうかを調べることによって，実行するスレッドの選択を開始する。図７に，ステップ６０１のスレッド選択プロセスを詳述するフローチャートを示す。
…（中略）…
【００４７】次に図７を参照すると，決定ブロック７０１でリアル・タイム・キューがそれ自体のディスパッチ・キューよりも優先度の高いスレッドを持っている場合，プロセッサ・ディスパッチャはステップ７０２でリアル・タイム・キューのロックを獲得し，図４のキュー４０４のようなリアル・タイム・キューから最高の優先度のスレッドを取り出し，そのスレッドの実行に移る。
【００４８】次のスレッドを取り出せるようになったプロセッサは，それ自体のキューを調べる前にまずリアル・タイム・キューを調べ，それによってそのプロセッサ自体のキュー内のスレッドの前により優先度の高いリアル・タイム・キュー内のスレッドを処理して，リアル・タイム・スレッドに可能な最も速いサービスを提供する。決定ブロック７０１で，リアル・タイム・キューに実行可能なより優先度の高いスレッドがなくなったと判断された場合，プロセッサはステップ７０３に進んでそれ自体のディスパッチ・キューに実行可能なスレッドがないか調べる。それ自体のキューが空でない場合，プロセッサはステップ７０４に進んでそれ自体のキューのロックを獲得し，それ自体のキューから最高の優先度のスレッドを取り出す。
【００４９】プロセッサ自体のディスパッチ・キューが空の場合，プロセッサはステップ７０５に進み，他のプロセッサのディスパッチ・キューを調べて実行可能スレッドを見つける。他のいずれかのディスパッチ・キュー内に特定のプロセッサ・アフィニティを持たない実行可能スレッドがある場合，プロセッサはそのディスパッチ・キューのスケジューリング・ロックを獲得し，ステップ７０６に進んでその別のプロセッサからスレッドを奪う。」
　したがって，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。
「スレッドを処理する複数のプロセッサと，各プロセッサのための複数のディスパッチキューおよび複数のスケジューラと，共有メモリとを備えたマルチプロセッサシステムにおけるスレッドのスケジュール方法であって，
　プロセッサは，新しいスレッドをディスパッチキューに入れ，
　プロセッサは，次のスレッドの実行が可能となると，当該プロセッサのスケジューラが自身のディスパッチキューを調べ，当該ディスパッチキューが空でない場合，当該ディスパッチキューのロックを獲得し，最高の優先度のスレッドを取り出し，
　当該プロセッサ自身のディスパッチキューが空の場合，当該プロセッサのスケジューラが他のプロセッサのディスパッチキューを調べ，他のディスパッチキューに特定のプロセッサ・アフィニティを持たない実行可能なスレッドがある場合，当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し，当該ディスパッチキューから前記スレッドを取り出し，
　前記プロセッサは，取り出した前記スレッドを実行する方法。」
２　引用文献２について
　原査定の拒絶の理由に引用された引用文献２（特開２００３−１６７７２６号公報）の段落【００３６】の記載からみて，当該引用文献２には，「キューをハードウェアで構成することもソフトウェアで構成することも可能である」という技術的事項が記載されていると認められる。
３　引用文献３について
　原査定の拒絶の理由に引用された引用文献３（特表２００９−５１０６１３号公報）の段落【００２５】の記載からみて，当該引用文献３には，「アクセス同期を行う場合に，アトミック・ミューテックスを利用してロックを行う」という技術的事項（以下，「引用文献３記載技術」という。）が記載されていると認められる。
第４　対比・判断
１　本願発明１について
（１）対比
　本願発明１と引用発明とを対比すると，次のことがいえる。
ア　引用発明は，「スレッドを処理する複数のプロセッサと，各プロセッサのための複数のディスパッチキューおよび複数のスケジューラと，共有メモリとを備えたマルチプロセッサシステムにおけるスレッドのスケジュール方法」であるところ，「スレッド」は「ディスパッチキュー」で管理されるプロセッサの処理単位であって，“タスク”の態様の１つであることから，本願発明１の「タスク」に相当するといえる。
　一方，本願発明１は，「異種の処理デバイスにおいてワークロードのバランスをとるための方法」であって，「異種の処理デバイス」は，複数の「第１のプロセッサ」および「第２のプロセッサ」を含み，「ワークロードのバランスをとる」とは，「異種の処理デバイス」にける「タスク」処理による「ワークロード」がバランスするようにスケジュールすると解されるから，上位概念では“タスクをスケジュールするための方法”であるといえる。
　そうすると，引用発明の「スレッドを処理する複数のプロセッサと，各プロセッサのための複数のディスパッチキューおよび複数のスケジューラと，共有メモリとを備えたマルチプロセッサシステムにおけるスレッドのスケジュール方法」と，
　本願発明１の「異種の処理デバイスにおいてワークロードのバランスをとるための方法」とは，後記する点で相違するものの，
　“複数の処理デバイスにおいてタスクをスケジュールするための方法”である点で共通しているといえる。
イ　引用発明では，「プロセッサは，新しいスレッドをディスパッチキューに入れ」るところ，上記アでの検討より，引用発明の「スレッド」は本願発明１の「タスク」に相当し，「ディスパッチキュー」は各プロセッサに対応して設置されているものの，複数のプロセッサがアクセス可能な“キュー”であることから，“複数のタスクを，複数のプロセッサと通信可能に接続されたキューに記憶する”といえる。
　また，引用発明の各「プロセッサ」は「ディスパッチキュー」を備え，「スレッド」の格納，取り出し処理を実行することから，実質的に“デキューイングモジュール”を有しているといえ，さらに，処理を実行するためのハードウェアとして“処理コア”を有していることも明らかである。
　そうすると，引用発明の「プロセッサは，新しいスレッドをディスパッチキューに入れ」，「各プロセッサ」は「ディスパッチキュー」を備えることと，
　本願発明１の「複数のタスクを，第１の種類の１つ以上の第１のプロセッサ及び第２の種類の１つ以上の第２のプロセッサと通信可能に接続された共有キューに記憶するステップであって，前記複数のタスクの各々は，前記１つ以上の第１のプロセッサ上での実行のためのマイクロコードへの第１のポインタと，前記１つ以上の第２のプロセッサ上での実行のためのコンパイルされたコードへの第２のポインタと，を含み，前記１つ以上の第１のプロセッサの各々は，第１のデキューイングモジュールと，１つ以上の第１の処理コアと，を含み，前記１つ以上の第２のプロセッサの各々は，同期化モジュールと，第２のデキューイングモジュールと，１つ以上の第２の処理コアと，を含む，ステップ」とは，後記する点で相違するものの，
　“複数のタスクを，複数のプロセッサと通信可能に接続されたキューに記憶するステップであって，前記プロセッサの各々は，デキューイングモジュールと，１つ以上の処理コアと，を含む，ステップ”である点で共通しているといえる。
ウ　引用発明では，「当該ディスパッチキューのロックを獲得し，最高の優先度のスレッドを取り出し」，あるいは，「当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し，当該ディスパッチキューから前記スレッドを取り出」すところ，上記イでの検討より，実質的に“デキューイングモジュール”を有しているといえ，「ロック」を用いて「ディスパッチキュー」から「スレッド」を取り出すことは，上位概念では，“タスク”へのアクセスの“排他的制御”を用いた“同期”であるといえるから，“デキューイングモジュール”による“キュー”へのアクセスを“排他的制御を用いて同期する”こととみることができる。
　また，本願発明１の「前記１つ以上の第１のプロセッサの各々の第１のデキューイングモジュール及び前記１つ以上の第２のプロセッサの各々の第２のデキューイングモジュールによる前記共有キューへのアクセスを，同期化のための不可分操作を用いて同期する」ことは，「同期化のための不可分操作」が“同期”のための“排他的制御”の態様の１つであることから，“デキューイングモジュール”による“キュー”へのアクセスを“排他的制御を用いて同期する”ことといえる。
　そうすると，引用発明の「当該ディスパッチキューのロックを獲得し，最高の優先度のスレッドを取り出し」，あるいは，「当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し，当該ディスパッチキューから前記スレッドを取り出す」ことと，
　本願発明１の「前記１つ以上の第２のプロセッサの少なくとも１つの同期化モジュールが，前記１つ以上の第１のプロセッサの各々の第１のデキューイングモジュール及び前記１つ以上の第２のプロセッサの各々の第２のデキューイングモジュールによる前記共有キューへのアクセスを，同期化のための不可分操作を用いて同期するステップ」とは，後記する点で相違するものの，
　“前記プロセッサの各々のデキューイングモジュールによる前記キューへのアクセスを，同期化のための排他的制御を用いて同期するステップ”である点で共通しているといえる。
エ　引用発明では，「当該プロセッサのスケジューラが他のプロセッサのディスパッチキューを調べ，他のディスパッチキューに特定のプロセッサ・アフィニティを持たない実行可能なスレッドがある場合，当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得」するところ，引用文献１の上記Ｂの段落【００３６】−【００３７】の記載からすると，「プロセッサ・アフィニティ」は「スレッド」に対応付けられた実行可能プロセッサを決定するための特性値であり，「スレッド」を識別するための“パラメータ”といえるから，“デキューイングモジュール”が“キュー”に記憶された複数の“タスク”の中から特定の“タスク”を“パラメータ”により識別するとみることができる。
オ　引用発明では，「他のディスパッチキューに特定のプロセッサ・アフィニティを持たない実行可能なスレッドがある場合，当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し，当該ディスパッチキューから前記スレッドを取り出」すところ，「ディスパッチキュー」に記憶された「スレッド」が「特定のプロセッサ・アフィニティを持たない実行可能」であるとは，特定の「スレッド」の「プロセッサ・アフィニティ」が「当該プロセッサ」の実行に適した状態を示していると解されることから，特定の“タスク”が“実行するのに適切な状態”において，“キュー”から特定の“タスク”をデキューイングするとみることができる。
　そうすると，上記エでの検討も踏まえると，引用発明の「当該プロセッサのスケジューラが他のプロセッサのディスパッチキューを調べ，他のディスパッチキューに特定のプロセッサ・アフィニティを持たない実行可能なスレッドがある場合，当該プロセッサのスケジューラは当該ディスパッチキューのロックを獲得し，当該ディスパッチキューから前記スレッドを取り出」すことと，
　本願発明１の「前記１つ以上の第２のプロセッサの少なくとも１つの第２のデキューイングモジュールが，前記複数のタスクの中から特定のタスクをパラメータにより識別するステップ」，
　「前記１つ以上の第２のプロセッサの少なくとも１つの第２のデキューイングモジュールが，前記１つ以上の第２のプロセッサで前記特定のタスクを実行するのに適切な状態において，前記共有キューから前記特定のタスクをデキューイングするステップ」とは，後記する点で相違するものの，
　“前記プロセッサの少なくとも１つのデキューイングモジュールが，前記複数のタスクの中から特定のタスクをパラメータにより識別するステップ”，
　“前記プロセッサの少なくとも１つのデキューイングモジュールが，前記プロセッサで前記特定のタスクを実行するのに適切な状態において，前記キューから前記特定のタスクをデキューイングするステップ”である点で共通しているといえる。
カ　引用発明では，「前記プロセッサは，取り出した前記スレッドを実行する」ところ，「スレッド」を「ディスパッチキュー」からデキューイングすると解され，上記イでの検討より，「プロセッサ」は「スレッド」を実行する“処理コア”を有し，“デキューイングモジュール”が“処理コア”に「スレッド」を実行するよう命令することは明らかであることから，“デキューイングモジュール”が“キュー”からデキューイングされた特定の“タスク”を実行するように，“処理コア”に命令するといえる。
　そうすると，引用発明の「前記プロセッサは，取り出した前記スレッドを実行する」ことと，
　本願発明１の「前記１つ以上の第２のプロセッサの少なくとも１つの第２のデキューイングモジュールが，前記第２のポインタによってポイントされた，前記コンパイルされたコードを実行するように，前記１つ以上の第２の処理コアに命令するステップ」とは，後記する点で相違するものの，
　“前記プロセッサの少なくとも１つのデキューイングモジュールが，デキューイングされた前記特定のタスクを実行するように，前記１つ以上の処理コアに命令するステップ”である点で共通しているといえる。
　したがって，本願発明１と引用発明との間には，次の一致点，相違点があるといえる。
（一致点）
「　複数の処理デバイスにおいてタスクをスケジュールするための方法であって，
　複数のタスクを，複数のプロセッサと通信可能に接続されたキューに記憶するステップであって，前記プロセッサの各々は，デキューイングモジュールと，１つ以上の処理コアと，を含む，ステップと，
　前記プロセッサの各々のデキューイングモジュールによる前記キューへのアクセスを，同期化のための排他的制御を用いて同期するステップと，
　前記プロセッサの少なくとも１つのデキューイングモジュールが，前記複数のタスクの中から特定のタスクをパラメータにより識別するステップと，
　前記プロセッサの少なくとも１つのデキューイングモジュールが，前記プロセッサで前記特定のタスクを実行するのに適切な状態において，前記キューから前記特定のタスクをデキューイングするステップと，
　前記プロセッサの少なくとも１つのデキューイングモジュールが，デキューイングされた前記特定のタスクを実行するように，前記１つ以上の処理コアに命令するステップと，
　を含む，方法。」
（相違点）
（相違点１）
　本願発明１は，「異種の処理デバイスにおいてワークロードのバランスをとるための方法」であるのに対して，
　引用発明は，「スレッドを処理する複数のプロセッサと，各プロセッサのための複数のディスパッチキューおよび複数のスケジューラと，共有メモリとを備えたマルチプロセッサシステムにおけるスレッドのスケジュール方法」である点。
（相違点２）
　タスクをキューに記憶することに関し，本願発明１は，「複数のタスクを，第１の種類の１つ以上の第１のプロセッサ及び第２の種類の１つ以上の第２のプロセッサと通信可能に接続された共有キューに記憶するステップであって，前記複数のタスクの各々は，前記１つ以上の第１のプロセッサ上での実行のためのマイクロコードへの第１のポインタと，前記１つ以上の第２のプロセッサ上での実行のためのコンパイルされたコードへの第２のポインタと，を含み，前記１つ以上の第１のプロセッサの各々は，第１のデキューイングモジュールと，１つ以上の第１の処理コアと，を含み，前記１つ以上の第２のプロセッサの各々は，同期化モジュールと，第２のデキューイングモジュールと，１つ以上の第２の処理コアと，を含む，ステップ」を含むのに対して，
　引用発明では，「プロセッサは，新しいスレッドをディスパッチキューに入れ」，「各プロセッサ」は「ディスパッチキュー」を備えるものの，「第１の種類」の「第１のプロセッサ」及び「第２の種類」の「第２のプロセッサ」が１つの「共有キュー」に，「第１のプロセッサ上での実行のためのマイクロコードへの第１のポインタ」と，「第２のプロセッサ上での実行のためのコンパイルされたコードへの第２のポインタ」とを含むタスクを記憶することは特定されていない点。
（相違点３）
　キューへのアクセス同期に関し，本願発明１は，「前記１つ以上の第２のプロセッサの少なくとも１つの同期化モジュールが，前記１つ以上の第１のプロセッサの各々の第１のデキューイングモジュール及び前記１つ以上の第２のプロセッサの各々の第２のデキューイングモジュールによる前記共有キューへのアクセスを，同期化のための不可分操作を用いて同期するステップ」を含むのに対して，
　引用発明では，「ディスパッチキューのロックを獲得し，当該ディスパッチキューから前記スレッドを取り出す」ものの，「共有キュー」へのアクセスを，同期化のための「不可分操作」を用いて同期することは特定されていない点。
（相違点４）
　タスクのパラメータの識別に関し，本願発明１は，「１つ以上の第２のプロセッサの少なくとも１つの第２のデキューイングモジュールが，前記複数のタスクの中から特定のタスクをパラメータにより識別するステップ」を含むのに対して，
　引用発明では，複数の「スレッド」の中から特定の「スレッド」を「プロセッサ・アフィニティ」により識別するものの，「第２のプロセッサの少なくとも１つの第２のデキューイングモジュール」が識別することは特定されていない点。
（相違点５）
　タスクのデキューイングに関し，本願発明１は，「前記１つ以上の第２のプロセッサの少なくとも１つの第２のデキューイングモジュールが，前記１つ以上の第２のプロセッサで前記特定のタスクを実行するのに適切な状態において，前記共有キューから前記特定のタスクをデキューイングするステップ」を含むのに対して，
　引用発明では，特定の「スレッド」の「プロセッサ・アフィニティ」が適切な状態において，「ディスパッチキュー」から当該「スレッド」をデキューイングするものの，「第２のプロセッサの少なくとも１つの第２のデキューイングモジュール」が「共有キュー」からデキューイングすることは特定されていない点。
（相違点６）
　タスクの実行に関し，本願発明１は，「前記１つ以上の第２のプロセッサの少なくとも１つの第２のデキューイングモジュールが，前記第２のポインタによってポイントされた，前記コンパイルされたコードを実行するように，前記１つ以上の第２の処理コアに命令するステップ」を含むのに対して，
　引用発明は，「プロセッサは，取り出した前記スレッドを実行する」ものの，「第２のデキューイングモジュールが，前記第２のポインタによってポイントされた，前記コンパイルされたコードを実行するように，前記１つ以上の第２の処理コアに命令する」ことは特定されていない点。
（２）相違点についての判断
ア　相違点２について
　事案に鑑みて，上記相違点２を先に検討すると，引用発明では，各「プロセッサ」は「ディスパッチキュー」を備え，新しい「スレッド」は各「プロセッサ」の「ディスパッチキュー」に入れて記憶するものであるが，引用文献１の上記Ｂの段落【００３４】の「各ディスパッチ・キューはそれに関連づけられたそれ自体のスケジューリング・ロックを持ち，それによってすべてのスケジューリング操作を保護する。そのため，キューからスレッドをディスパッチしようとするプロセッサはそのキューからスレッドを取り出す前にそのキューのロックを獲得する必要がある。したがって，すべてのプロセッサのための単一のディスパッチ・キューに単一のスケジュール・ロックを使用する従来技術のスケジューラとは異なり，複数のディスパッチ・キューのために複数のスケジュール・ロックを使用する本発明ではロック競合が減少する。」との記載からすると，「単一のディスパッチ・キュー」で管理しないことを特徴としており，ＣＰＵ，ＧＰＵなど異なる種類のプロセッサの間で，特定のプロセッサに設置されたものでない共有のキューを用いてタスクを管理することについて，動機付けは認められない。
　そして，引用発明は，異なる種類のプロセッサの間で共有キューを管理するものではないから，引用文献１には，共有キューで管理されるタスクが，第１のプロセッサ上での実行のためのマイクロコードへの第１のポインタと，第２のプロセッサ上での実行のためのコンパイルされたコードへの第２のポインタと，を含むことについて記載も示唆もされていない。そのような構成は，引用文献３記載技術，引用文献２に記載の周知技術からも適宜なし得たものではない。
　加えて，複数のタスクを，第１の種類の第１のプロセッサ及び第２の種類の第２のプロセッサと通信可能に接続された共有キューに記憶し，複数のタスクの各々は，第１のプロセッサ上での実行のためのマイクロコードへの第１のポインタと，第２のプロセッサ上での実行のためのコンパイルされたコードへの第２のポインタと，を含む旨の技術が本願の優先日前に当該技術分野の周知技術であったとはいえない。
　そうすると，引用発明において，複数のタスクを，第１の種類の１つ以上の第１のプロセッサ及び第２の種類の１つ以上の第２のプロセッサと通信可能に接続された共有キューに記憶するステップであって，前記複数のタスクの各々は，前記１つ以上の第１のプロセッサ上での実行のためのマイクロコードへの第１のポインタと，前記１つ以上の第２のプロセッサ上での実行のためのコンパイルされたコードへの第２のポインタと，を含み，前記１つ以上の第１のプロセッサの各々は，第１のデキューイングモジュールと，１つ以上の第１の処理コアと，を含み，前記１つ以上の第２のプロセッサの各々は，同期化モジュールと，第２のデキューイングモジュールと，１つ以上の第２の処理コアと，を含む，ステップを構成すること，すなわち，上記相違点２に係る構成とすることは，当業者が適宜なし得たものであるとすることはできない。
イ　まとめ
　上記相違点１，３−６について判断するまでもなく，本願発明１は，当業者であっても，引用発明，引用文献３記載技術及び引用文献２に記載の周知技術に基づいて容易に発明できたものとはいえない。
２　本願発明２−６，１６−１７について
　本願発明２−６，１６−１７は，本願発明１を減縮した発明であり，本願発明１の
「複数のタスクを，第１の種類の１つ以上の第１のプロセッサ及び第２の種類の１つ以上の第２のプロセッサと通信可能に接続された共有キューに記憶するステップであって，前記複数のタスクの各々は，前記１つ以上の第１のプロセッサ上での実行のためのマイクロコードへの第１のポインタと，前記１つ以上の第２のプロセッサ上での実行のためのコンパイルされたコードへの第２のポインタと，を含み，前記１つ以上の第１のプロセッサの各々は，第１のデキューイングモジュールと，１つ以上の第１の処理コアと，を含み，前記１つ以上の第２のプロセッサの各々は，同期化モジュールと，第２のデキューイングモジュールと，１つ以上の第２の処理コアと，を含む，ステップ」（以下，「相違点２に係る構成」という。）
と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献３記載技術及び引用文献２に記載の周知技術に基づいて容易に発明できたものとはいえない。
３　本願発明７−１１，１８−１９について
　本願発明７は，本願発明１に対応する「システム」の発明であり，本願発明８−１１，１８−１９は，本願発明７を減縮した発明であり，本願発明１の「相違点２に係る構成」に対応する構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献３記載技術及び引用文献２に記載の周知技術に基づいて容易に発明できたものとはいえない。
４　本願発明１２−１４，２０−２１について
　本願発明１２は，本願発明１に対応する「コンピュータ可読記憶媒体」の発明であり，本願発明１３−１４，２０−２１は，本願発明１２を減縮した発明であり，本願発明１の「相違点２に係る構成」に対応する構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献３記載技術及び引用文献２に記載の周知技術に基づいて容易に発明できたものとはいえない。
５　本願発明１５，２２について
　本願発明１５は，本願発明１に対応する「システム」の発明であり，本願発明２２は，本願発明１５を減縮した発明であり，本願発明１の「相違点２に係る構成」に対応する構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献３記載技術及び引用文献２に記載の周知技術に基づいて容易に発明できたものとはいえない。
第５　原査定の概要及び原査定についての判断
　原査定は，請求項１−２３について上記引用文献１−３に記載された発明に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。
　しかしながら，平成３０年３月９日付け手続補正により補正された請求項１，７，１２，１５はそれぞれ，「相違点２に係る構成」という事項，前記事項に対応する構成を有するものとなっており，上記のとおり，本願発明１−２２は，引用発明，引用文献３記載技術及び引用文献２に記載の周知技術に基づいて，当業者が容易に発明できたものではない。
　したがって，原査定を維持することはできない。
第６　当審拒絶理由について
＜特許法第３６条第６項第２号について＞
（１）当審では，請求項１−６，１２−１４，１６−１７，２０−２１の「前記複数のタスクの中から特定のタスクを読み出すステップ」が特定する事項が不明確であるとの拒絶の理由を通知しているが，平成３０年３月９日付けの手続補正により，「前記複数のタスクの中から特定のタスクをパラメータにより識別するステップ」と補正された結果，この拒絶の理由は解消した。
（２）当審では，請求項７−１１，１５，１８−１９，２２の「前記複数のタスクの中から前記特定のタスクを読み出し」が特定する事項が不明確であるとの拒絶の理由を通知しているが，平成３０年３月９日付けの手続補正により，「前記複数のタスクの中から前記特定のタスクをパラメータにより識別し」と補正された結果，この拒絶の理由は解消した。
（３）当審では，請求項１６の「前記複数のタスクの中から他の特定のタスクを読み出すステップ」が特定する事項が不明確であるとの拒絶の理由を通知しているが，平成３０年３月９日付けの手続補正により，「前記複数のタスクの中から他の特定のタスクをパラメータにより識別するステップ」と補正された結果，この拒絶の理由は解消した。
（４）当審では，請求項２−４，８，１３の「前記１つ以上の第２のプロセッサは，中央処置装置（ＣＰＵ）と，アクセラレーテッドプロセッシングデバイス（ＡＰＤ）を含む前記１つ以上の第１のプロセッサと，を含む，」が特定する事項が不明確であるとの拒絶の理由を通知しているが，平成３０年３月９日付けの手続補正により，「前記１つ以上の第２のプロセッサは，中央処置装置（ＣＰＵ）を含み，前記１つ以上の第１のプロセッサは，アクセラレーテッドプロセッシングデバイス（ＡＰＤ）を含む」と補正された結果，この拒絶の理由は解消した。
（５）当審では，請求項３の「前記１つ以上の第２のプロセッサの第１のデキューイングモジュールは，ハードウェアデバイスである，請求項２に記載の方法」における「第２のプロセッサ」は誤記であるとの拒絶の理由を通知しているが，平成３０年３月９日付けの手続補正により，「第１のプロセッサ」と補正された結果，この拒絶の理由は解消した。
（６）当審では，請求項４の「前記１つ以上の第１のプロセッサの第２のデキューイングモジュールは，ソフトウェアモジュールである，請求項２に記載の方法」における「第１のプロセッサ」は誤記であるとの拒絶の理由を通知しているが，平成３０年３月９日付けの手続補正により，「第２のプロセッサ」と補正された結果，この拒絶の理由は解消した。
（７）当審では，請求項９の「前記１つ以上の第１のプロセッサの第２のデキューイングモジュールは，ハードウェアデバイスである，請求項７に記載のシステム」における「第２のデキューイングモジュール」は誤記であるとの拒絶の理由を通知しているが，平成３０年３月９日付けの手続補正により，「第１のデキューイングモジュール」と補正された結果，この拒絶の理由は解消した。
第７　むすび
　以上のとおり，本願発明１−２２は，当業者が引用発明，引用文献３記載技術及び引用文献２に記載の周知技術に基づいて容易に発明をすることができたものではない。したがって，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。