• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1376421
審判番号 不服2020-10442  
総通号数 261 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-09-24 
種別 拒絶査定不服の審決 
審判請求日 2020-07-27 
確定日 2021-07-28 
事件の表示 特願2018-233478「マルチプロセッサ組込みシステム上でのアプリケーションの動的再構成」拒絶査定不服審判事件〔平成31年 4月11日出願公開,特開2019- 57321〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1 手続の経緯

本願は,2013年5月21日(パリ条約による優先権主張外国庁受理2013年5月17日(以下,「優先日」という。),米国)を国際出願日とする特願2016-513913号の一部を,平成29年10月12日に新たな特許出願とした特願2017-198250号について,さらにその一部を平成30年12月13日に新たな特許出願としたものであって,その手続の経緯は以下のとおりである。

平成30年12月19日 :出願審査請求書,手続補正書の提出
令和 1年11月 1日付け:拒絶理由通知
令和 2年 2月19日 :意見書,手続補正書の提出
令和 2年 3月11日付け:拒絶査定
令和 2年 7月27日 :審判請求書,手続補正書の提出
令和 2年10月13日 :前置報告

第2 令和2年7月27日にされた手続補正についての補正の却下の決定

[補正の却下の決定の結論]

令和2年7月27日にされた手続補正(以下,「本件補正」という。)を却下する。

[理由]

1 本件補正について(補正の内容)

(1)本件補正後の特許請求の範囲の記載

本件補正により,特許請求の範囲の請求項1の記載は,次のとおり補正された。(下線部は,補正箇所である。以下,この特許請求の範囲に記載された請求項1を「補正後の請求項1」という。)

「 【請求項1】 複数のプロセッサと、前記プロセッサに分散された複数のメモリとを含むマルチプロセッサシステムにおいて、アプリケーションスワップを実施するための方法であって、 前記方法は、前記複数のプロセッサによって実施される、 複数のアプリケーションを前記マルチプロセッサシステムのそれぞれの領域に展開するステップを含み、前記複数のアプリケーションは、第1のリーガル構成の互いに干渉していないアプリケーションの第1のセットに含まれ、 前記複数のアプリケーションでスワップ手順を実施するステップ、 前記スワップ手順の実施に応答して、前記第1のリーガル構成から第2のリーガル構成に遷移するステップを含み、前記第2のリーガル構成は、前記互いに干渉していないアプリケーションの第1のセットとは異なる互いに干渉していないアプリケーションの第2のセットを含み、 前記マルチプロセッサシステムの外部からのコマンドの受信に応答して、前記マルチプロセッサシステムの親タスクによって、前記スワップ手順を開始するステップ、 前記親タスクによって、前記スワップ手順を管理するステップを含み、 前記スワップ手順を管理するステップは、 前記複数のアプリケーションの特定のアプリケーションに対して、スワップされる状態となるように要求し、 前記特定のアプリケーションから、前記特定のアプリケーションがスワップされる準備ができていることを示す通知を受信すること を含む方法。」

(2)本件補正前の特許請求の範囲

本件補正前の,令和2年2月19日にされた手続補正により補正された特許請求の範囲の請求項1の記載は,次のとおりである。(以下,この特許請求の範囲に記載された請求項1を「補正前の請求項1」という。)

「 【請求項1】
複数のプロセッサと、前記プロセッサに分散された複数のメモリとを含むマルチプロセッサシステムにおいて、アプリケーションスワップを実施するための方法であって、
複数のアプリケーションを前記マルチプロセッサシステムのそれぞれの領域に展開するステップを含み、前記複数のアプリケーションは、第1のリーガル構成の互いに干渉していないアプリケーションの第1のセットに含まれ、
前記複数のアプリケーションでスワップ手順を実施するステップ、
前記スワップ手順の実施に応答して、前記第1のリーガル構成から第2のリーガル構成に遷移するステップを含み、前記第2のリーガル構成は、前記互いに干渉していないアプリケーションの第1のセットとは異なる互いに干渉していないアプリケーションの第2のセットを含み、
前記マルチプロセッサシステムの外部からのコマンドの受信に応答して、前記マルチプロセッサシステムの親タスクによって、前記スワップ手順を開始するステップ、
前記親タスクによって、前記スワップ手順を管理するステップ
を含む方法。」

2 補正の適否

本件補正は,補正前の請求項1に記載された発明を特定するために必要な事項である,「アプリケーションスワップを実施するための方法」について,「前記方法は、前記複数のプロセッサによって実施される」との限定を付加するとともに,同じく補正前の請求項1に記載された発明を特定するために必要な事項である,「スワップ手順を管理するステップ」について,「前記複数のアプリケーションの特定のアプリケーションに対して、スワップされる状態となるように要求し、前記特定のアプリケーションから、前記特定のアプリケーションがスワップされる準備ができていることを示す通知を受信すること」との限定を付加するものである。
そして,補正前の請求項1に記載された発明と補正後の請求項1に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから,本件補正は,特許法17条の2第5項2号の特許請求の範囲の減縮を目的とするものに該当する。
そこで,本件補正後の請求項1に記載される発明(以下「本件補正発明」という。)が同条第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について,以下,検討する。

(1)本件補正発明

本件補正発明は,上記「1(1)」に記載された下記のとおりのものである(再掲)。

「 複数のプロセッサと、前記プロセッサに分散された複数のメモリとを含むマルチプロセッサシステムにおいて、アプリケーションスワップを実施するための方法であって、
前記方法は、前記複数のプロセッサによって実施される、
複数のアプリケーションを前記マルチプロセッサシステムのそれぞれの領域に展開するステップを含み、前記複数のアプリケーションは、第1のリーガル構成の互いに干渉していないアプリケーションの第1のセットに含まれ、
前記複数のアプリケーションでスワップ手順を実施するステップ、
前記スワップ手順の実施に応答して、前記第1のリーガル構成から第2のリーガル構成に遷移するステップを含み、前記第2のリーガル構成は、前記互いに干渉していないアプリケーションの第1のセットとは異なる互いに干渉していないアプリケーションの第2のセットを含み、
前記マルチプロセッサシステムの外部からのコマンドの受信に応答して、前記マルチプロセッサシステムの親タスクによって、前記スワップ手順を開始するステップ、
前記親タスクによって、前記スワップ手順を管理するステップ
を含み、
前記スワップ手順を管理するステップは、
前記複数のアプリケーションの特定のアプリケーションに対して、スワップされる状態となるように要求し、
前記特定のアプリケーションから、前記特定のアプリケーションがスワップされる準備ができていることを示す通知を受信すること
を含む方法。」

(2)引用文献等の記載事項

(2-1)引用文献1に記載されている技術的事項及び引用発明

ア 原査定の拒絶の理由で引用された,本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である,米国特許出願公開第2013/0081044号公報(2013年3月28日出願公開。以下,「引用文献1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。以下同様。)

A 「[0030] As illustrated in FIG. 1, the invention provides a data processing system 100 comprising an array 115 of processing cores 120, which are dynamically shared by a set of application programs configured to run on the system. In an embodiment of the invention, the individual application programs running on the system maintain at specified addresses within the system 100 memories their processing capacity demand indicators signaling 130 to the controller 140 a level of demand of the system processing capacity by the individual applications. In a particular implementation, each of these indicators 130, referred to herein as core-demand-figures (CDFs), express how many cores 120 their associated application program is presently able utilize for its data processing tasks. Moreover, in certain embodiments, the individual applications maintain their CDFs at specified registers within the system, e.g. in known addresses within the memory space of their root processes (i.e. task ID#0 of each application), with such application CDF registers being accessible by hardware logic of the controller module 140. For instance, in an embodiment, the CDF 130 of a given application program is a function of the number of its schedulable tasks, such as processes, threads or functions (referred to collectively as tasks) that are ready to execute at a given time. In a particular embodiment of the invention, CDF of an application program expresses on how many processing cores the program is presently able to execute in parallel. Moreover, in certain embodiments, these capacity demand indicators, for any given application, include a list 135 identifying its ready tasks in a priority order.」
(当審訳;「[0030] 図1に示されるように,本発明は,システム上で実行されるように構成されたアプリケーションプログラムのセットによって動的に共有される処理コア120のアレイ115を含むデータ処理システム100を提供する。本発明の一実施形態では,システム上で実行される個々のアプリケーションプログラムは,システム100内の指定されたアドレスに,個々のアプリケーションによるシステム処理能力の要求のレベルをコントローラ140に信号130で伝える処理能力要求インジケータを維持する。特定の実装形態では,本明細書でコアデマンドフィギュア(CDFs)と呼ばれるこれらのインジケータ130のそれぞれは,それらの関連するアプリケーションプログラムがそのデータ処理タスクに現在利用できるコア120の数を表す。さらに,いくつかの実施形態では,個々のアプリケーションは,システム内の指定されたレジスタで,例えば,それらのルートプロセス(すなわち,各アプリケーションのタスクID#0)のメモリ空間内の既知のアドレスにおいて,それらのCDFを維持し,そのようなアプリケーションのCDFレジスタは,コントローラモジュール140のハードウェアロジックによってアクセス可能である。例えば,一実施形態では,所定のアプリケーションプログラムのCDF130は,所定の時間に実行する準備ができているプロセス,スレッド,関数(まとめてタスクと呼ばれる)など,スケジュール可能なタスクの数の関数である。本発明の特定の実施形態では,アプリケーションプログラムのCDFは,プログラムが現在並行して実行することができる処理コアの数を表す。さらに,いくつかの実施形態では,これらの能力要求インジケータは,任意の所与のアプリケーションについて,その準備ができたタスクを優先順位で識別するリスト135を含む。」)

B 「[0033] FIG. 2 illustrates context for the process 300 performed by the controller logic 140 of the system 100, repeatedly mapping the to-be-executing tasks 240 of the set of application programs 210 to their target cores 120 within the array 115. In an embodiment, each individual application 220 configured for a system 100 provides a (potentially updating) collection 230 of its tasks 240, even though for clarity of illustration in FIG. 2 this set of applications tasks is shown only for one of the applications within the set 210 of applications configured for a given instance of system 100.」
(当審訳;「[0033] 図2は,システム100のコントローラロジック140によって実行されるプロセス300のコンテキストを示しており,アプリケーションプログラムのセット210が実行されるタスク240を,アレイ115内のそれらのターゲットコア120に繰り返しマッピングする。一実施形態では,システム100のために構成され,個々のアプリケーション220がそのタスク240の(潜在的に更新する)集合230を提供するが,図2では説明の明確化のため,この一組のアプリケーションのタスクは,システム100の任意のインスタンス用に構成されたアプリケーションのセット210内のアプリケーションのうちの1つだけが示されている。」)

C 「[0037] FIG. 3 presents, according to an aspect of the invention, conceptual major phases of the task-to-core mapping process 300, used for maximizing the application program processing throughput of a data processing system hardware shared among a number of software programs. Such process 300, repeatedly mapping the to-be-executing tasks of a set of applications to the array of processing cores within the system, involves series of steps as follows:
[0038] (1) allocating 310 the array of cores among the set of programs on the system, at least in part based on CDFs 130 by the programs, to produce for each program 220 a number of cores 220 allocated to it 315 (for the time period in between the current and the next run of the process 300); and
[0039] (2) based at least in part on the allocating 310, for each given application that was allocated at least one core: (a) selecting 320, according to the task priority list 135, the highest priority tasks within the given application for execution corresponding to the number of cores allocated to the given application, and (b) mapping 330 each selected task to one of the available cores of the array 115, to produce, i) for each core of the array, an identification 460 of an application and a task within the application that the given core was assigned to, as well as ii) for each application task selected for execution on the fabric 115, identification 420 of its assigned core.」
(当審訳;「[0037] 図3は,本発明の一態様によれば,多数のソフトウェアプログラム間で共有されるデータ処理システムハードウェアのアプリケーションプログラム処理スループットを最大化するために使用される,タスクからコアへのマッピングプロセス300の概念的で主要な段階を示す。そのようなプロセス300は,アプリケーションのセットが実行されるタスクをシステム内の処理コアのアレイに繰り返しマッピングし,以下のような一連のステップを含む。
[0038] (1)システム上のプログラムのセットの間にコアのアレイを割り当て310,少なくとも部分的にはプログラムによるCDF130に基づいて,各プログラム220に対して,それに割り当てられた数のコア220を生成する315(プロセス300の現在と次の実行の間の期間);そして,
[0039] (2)少なくとも割り当て310の部分に基づいて,少なくとも1つのコアが割り当てられた所与のアプリケーションごとに:(a)選択320では,タスク優先度リスト135に従って,所定のアプリケーションに割り当てられたコアの数に応じて,所定のアプリケーション内で最も優先度の高いタスクを選択し,(b)選択された各タスクをアレイ115の利用可能なコアの1つにマッピングして,i)アレイの各コアについて,アプリケーションの識別コード460および所与のコアが割り当てられたアプリケーション内のタスク,およびii)ファブリック115で実行するために選択された各アプリケーションタスクについて,割り当てられたコアの識別コード420を生成する。」)

D 「[0047] In a particular operating scenario, at end of any given core to task allocation period or after the set of tasks of any given application selected for execution chances (even within a core allocation period), for each such core within the system that got assigned a different next task to process (with such cores referred to as cores subject to task switchover), the updated processing image of its latest task is backed up 410 to a memory 450 that provides a dedicated memory segment 550 and related access logic (FIGS. 5-7) per each application task configured for the system 100. Specifically, in an embodiment, controller 140 through logic with core-specific multiplexers at XC 470 provides, at least conceptually as part of the bus 480, indications to the cores 120 regarding task switchovers, in response to which system software at the cores subject to a switchover causes the existing task to be backed up 410 to its segment 550 at memory array 450 and, following that, to retrieve 480 the next task's image from its segment 550 at memory array 450. Moreover, in a particular embodiment, after a core subject to task switchover has backed up 410 its outgoing task, the core will signal back to its multiplexer (element 620 in FIG. 6) at XC 470 to apply the provided new configuration 460, to cause the incoming application's image to be transferred 480 (under control of the core's system software) to the working memory of the core, and so that the incoming task assigned to execute on the core will be connected (in read mode) 480 to its segment 550 at memories 450.
・・・(後略)・・・」
(当審訳;「[0047] 特定の動作シナリオでは,所定のコアからタスクへの割り当て期間の終了時,または実行機会のために選択された所定のアプリケーションのタスクのセットの後(コア割り当て期間内であっても),割り当てられたシステム内のそのようなコアごとに処理する異なる次のタスク(タスク切り替えの対象となるコアと呼ばれるコアを含む)では,最新のタスクの更新された処理イメージが,専用メモリセグメント550および関連するアクセスロジックを提供するメモリ450に,システム100に構成された各アプリケーションタスクごとにバックアップされる(図5-7)。具体的には,一実施形態では,XC470にコア固有マルチプレクサを備えたロジックを介したコントローラ140は,少なくとも概念的にはバス480の一部として,タスク切り替えに関する指示をコア120に提供し,コアのどのシステムソフトウェアをスイッチオーバーするかに応じて,既存のタスクがメモリアレイ450でそのセグメント550にバックアップされ410,その後,メモリアレイ450でそのセグメント550から次のタスクのイメージを取得する480。さらに,特定の実施形態では,タスク切り替えの対象となるコアがその発信タスクをバックアップした後,コアは,XC470でそのマルチプレクサ(図6の要素620)に信号を送り返し,提供された新しい構成460を適用し,着信アプリケーションのイメージを(コアのシステムソフトウェアの制御下で)コアの作業メモリに転送し,コアで実行するように割り当てられた着信タスクが(読み取りモードで)メモリ450のセグメント550に接続されるようにする480。
・・・(後略)・・・」)

E 「図1


上記図1及び上記Aの記載から,“複数の処理コア120が配列されたコアアレイ115とコントローラ140とを備えるデータ処理システム100”が読み取れる。

F 「図2



G 「図3



H 「図4



イ 上記A?Hの,特に下線部の記載に注目すると,引用文献1には次の発明(以下,「引用発明」という。)が記載されているといえる。

「複数の処理コアが配列されたコアアレイとコントローラとを備えるデータ処理システムであって,
アプリケーションプログラムのコアデマンドフィギュア(CDF)は,プログラムが現在並行して実行することができる処理コアの数を表すものであって,
システムのコントローラロジックによって実行されるプロセスは,アプリケーションプログラムのセットが実行されるタスクを,アレイ内のそれらのターゲットコアに繰り返しマッピングするものであり,
前記コントローラは,タスク切り替えに関する指示をコアに提供し,既存のタスクがメモリアレイでそのセグメントにバックアップされ,その後,メモリアレイでそのセグメントから次のタスクのイメージを取得する,
データ処理システム。」

(2-2)引用文献2に記載されている技術的事項

原査定の拒絶の理由で引用された,本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である,藤倉俊幸,「組み込みプログラミングノウハウ入門 第1回 マルチタスクシステムとは」,インターフェース,日本,CQ出版株式会社,2002年3月1日,第28巻, 第3号,pp.132-140 (以下,「引用文献2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。

I 「3 機能分割と時間分割
・・・(中略)・・・
ところが,組み込み系ソフトの場合は,さらにタイミングの問題がある。タイミング制御の部分を解決するのがマルチタスク方式である。そして,独立する機能ごとにモジュール分割したように,タイミング制御が相互に干渉しないように分割されたタスクを並行に動作させるのがマルチタスクリアルタイムオペレーティングシステム(以下,マルチタスクRTOSと略記)である。
機能分割(あるいはモジュール分割)と時間分割(あるいはタスク分割),この二つを設計時にバランスよく行うことで,組み込み系ソフトの開発効率が向上する。RTOSのシステムコールの使い方以前に,タスク分割が重要である。
・・・(中略)・・・
時間分割のポイントは,要求仕様に含まれる並行性と時間制約の抽出と,待ち構造導入の仕方にある。」
(第134頁右欄第1行?第135頁左欄第2行)

(2-3)引用文献3に記載されている技術的事項

原査定の拒絶の理由で引用された,本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である,国際公開第2012/051577号(2012年4月19日国際公開,以下「引用文献3」という。)には,関連する図面とともに,以下の技術的事項が記載されている。

J 「[0040] Figure 2 illustrates an exemplary embodiment of a multiprocessor system, which may be referred to as the "HyperX architecture". A multi-processor system or fabric is a parallel computational platform comprising multiple processors, memories (unified and/or distributed), and communication (or communication network) resources. An exemplary multi-processor system comprises a plurality of processors, where each of the processors is coupled to at least one other processor, and where there are multiple communication mechanisms between the respective processors. The multi-processor system may include a plurality of memories coupled to the processors. For example, the memories may be interspersed among the processors. More specifically, the multi-processor system may comprise a plurality of communication units interspersed among the processors, wherein each of the communication units comprises a memory and routing logic. As used herein, the term "coupled" means directly or indirectly connected. The multi-processor system may or may not be embodied on a single integrated circuit, a single printed circuit board, or a single system. For example, the multi-processor system may be embodied as a plurality of integrated circuits, a plurality of printed circuit boards, a plurality of systems, or some combination thereof.」
(当審訳;「[0040] 図2は,「HyperXアーキテクチャ」と呼ばれるマルチプロセッサシステムの例示的な実施形態を示す。マルチプロセッサシステムまたはファブリックは,複数のプロセッサ,メモリ(統合および/または分散),および通信(または通信ネットワーク)リソースで構成される並列計算プラットフォームである。例示的なマルチプロセッサシステムは,複数のプロセッサを含み,各プロセッサは,少なくとも1つの他のプロセッサに結合され,それぞれのプロセッサ間に複数の通信メカニズムが存在する。マルチプロセッサシステムは,プロセッサに結合された複数のメモリを含み得る。たとえば,メモリをプロセッサ間に分散させることができる。より具体的には,マルチプロセッサシステムは,プロセッサ間に散在する複数の通信ユニットを含むことができ,通信ユニットのそれぞれは,メモリおよびルーティングロジックを含む。本明細書で使用される場合,「結合された」という用語は,直接的または間接的に接続されていることを意味する。マルチプロセッサシステムは,単一の集積回路,単一のプリント回路基板,または単一のシステムで具体化されてもされなくてもよい。例えば,マルチプロセッサシステムは,複数の集積回路,複数のプリント回路基板,複数のシステム,またはそれらのいくつかの組み合わせとして具体化することができる。」)

K 「[0047] Figures 4, 5, 6A, and 6B illustrate another view of the HW / SW operating stack of the multiprocessor architecture. The memory-network (DMRs) may provide autonomous and instantaneous bandwidth on demand which in turn may provide the execution model two features. First, the memory-network may enable a mixed memory programming model. Historically, programming models were restricted to a fully distributed or fully shared execution memory model due to hardware and programming model restrictions. This leads to inefficiencies in hardware adaptability and reconfigurability. The mixed-memory model may react in real-time to changing dynamics and requirements of the software running. Second, the communication network may be logically topology independent, e.g., adaptable and reconfigurable in real-time. This independence may allow the appropriate hardware topology to be created to support the natural parallelism of the algorithm / system, thus not constraining the algorithm / system to a particular topology. These features may enable realization of the natural efficiencies of any system. Further, the multiprocessor system may be inherently scalable, self synchronized, and may effectively support autonomous memory coherence if required by the system. In one embodiment, this system may be distributed across many die/chips supporting hundreds to thousands of processors in both hardware and software.」
(当審訳;「[0047] 図4,5,6A,及び6Bは,マルチプロセッサアーキテクチャのHW/SWオペレーティングスタックの別の例を示している。メモリネットワーク(DMR)は,オンデマンドで自律的かつ瞬時の処理能力を提供し,実行モデルに2つの機能を提供する。第一に,メモリネットワークは,混合メモリプログラミングモデルを可能にできる。これまで,プログラミングモデルは,ハードウェアとプログラミングモデルの制限により,完全に分散または完全に共有された実行メモリモデルに制限されていた。これにより,ハードウェアの適応性と再構成性が非効率になる。混合メモリモデルは,ソフトウェア実行中のダイナミクスと要件の変化にリアルタイムで反応することができる。第2に,通信ネットワークは,論理的にトポロジーに依存しない,例えば,リアルタイムで適応可能かつ再構成可能であり得る。この独立性により,アルゴリズム/システムの自然な並列処理をサポートする適切なハードウェアトポロジを作成できるため,アルゴリズム/システムを特定のトポロジに制約することはない。これらの機能により,あらゆるシステムの自然な効率を実現できる可能性がある。さらに,マルチプロセッサシステムは,本質的にスケーラブルで自己同期化され,システムで必要とされる場合,自律メモリコヒーレンスを効果的にサポートすることができる。一実施形態では,このシステムは,ハードウェアとソフトウェアの両方で数百から数千のプロセッサをサポートする多くのダイ/チップに分散させることができる。」)

L「図2


上記図2から,“複数のプロセッサがアレイ状に配置されている”ことが読み取れる。

M 「図4



(2-4)参考文献に記載されている技術的事項
本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である,米国特許出願公開第2004/0088711号明細書(2004年5月6日出願公開,以下「参考文献」という。)には,関連する図面とともに,以下の技術的事項が記載されている。

O 「[0053] Task Swap Out
[0054] The processor scheduler of the operating system coordinates the allocation of the processor to the various tasks that are currently ready to be executed. As described above, each processor has 16 protection domains and can thus be simultaneously executing up to 15 tasks with the operating system being executed in the other domain. The processor scheduler allows each task to execute for a certain time quantum. When the time quantum expires for a task, the processor scheduler raises the domain_signal for the protection domain of that task to initiate a swap out for that task. The swapping in and swapping out of tasks requires cooperation on the part of the task. To swap out a task, the operating system asks the task to save its state and quit all its streams, but one. The one remaining stream then notifies the operating system that the state of the task has been saved and that another task can be swapped into that protection domain. If the task ignores the notification, then the operating system can abort the task.」
(当審訳;「[0053] タスクスワップアウト
[0054] オペレーティングシステムのプロセッサスケジューラは,現在実行の準備ができているさまざまなタスクへのプロセッサの割り当てを調整する。上記のように,各プロセッサには16の保護ドメインがあるため,他のドメインで実行されているオペレーティングシステムと同時に最大15のタスクを実行できる。プロセッサスケジューラを使用すると,各タスクを所定の時間量で実行できる。タスクの時間量が期限切れになると,プロセッサスケジューラは,そのタスクの保護ドメインのドメイン信号を発生させて,そのタスクのスワップアウトを開始する。タスクのスワップインとスワップアウトには,タスク側の協力が必要である。タスクをスワップアウトするために,オペレーティングシステムは,タスクに状態を保存し,1つを除くすべてのストリームを終了するように要求する。次に,残りの1つのストリームは,タスクの状態が保存され,別のタスクをその保護ドメインにスワップできることをオペレーティングシステムに通知する。タスクが通知を無視した場合,オペレーティングシステムはタスクを中止できる。」)

(3)対比

ア 本件補正発明と引用発明とを対比する。

(ア)引用発明は,「複数の処理コアが配列されたコアアレイとコントローラとを備えるデータ処理システム」であるところ,前記「処理コア」は,情報を処理するものであるから“プロセッサ”であるといえ,「複数の処理コアが配列されたコアアレイ」は,複数の処理コア,すなわち“複数のプロセッサ”を含む“マルチプロセッサシステム”であるといえる。
よって,本件補正発明と引用発明とは,後記の点で相違するものの,“複数のプロセッサを含むマルチプロセッサシステム”である点で一致する。

(イ)引用発明は,「システムのコントローラロジックによって実行されるプロセスは,アプリケーションプログラムのセットが実行されるタスクを,アレイ内のそれらのターゲットコアに繰り返しマッピングするもの」であって,「前記コントローラは,タスク切り替えに関する指示をコアに提供」するものである。
ここで,「タスク切り替え」とは,「アプリケーションプログラムのセットが実行されるタスク」を切り替えることであるから,アプリケーションを切り替えることに他ならず,“アプリケーションスワップ”といえるものであり,かかるタスクの切り替えを行う「システムのコントローラロジックによって実行されるプロセス」は“アプリケーションスワップを実施するための方法”であるといえる。
そして,引用発明は,「アプリケーションプログラムのセットが実行されるタスクを,アレイ内のそれらのターゲットコアに繰り返しマッピングする」ところ,前記「アプリケーションプログラムのセット」が“複数のアプリケーション”からなるセットであることは明らかであるから,「アプリケーションプログラムのセットが実行されるタスクを,アレイ内のそれらのターゲットコアに繰り返しマッピングする」ことは,“複数のアプリケーション”をコアアレイ内のターゲットコアの“それぞれの領域に展開する”ことに他ならない。
よって,上記(ア)の検討も踏まえると,本件補正発明と引用発明とは,“アプリケーションスワップを実施するための方法であって”,“前記方法は,前記複数のプロセッサによって実施される”ものであり,“複数のアプリケーションを前記マルチプロセッサシステムのそれぞれの領域に展開するステップ”を含む点で一致する。

(ウ)引用発明は,「前記コントローラは,タスク切り替えに関する指示をコアに提供し,既存のタスクがメモリアレイでそのセグメントにバックアップされ,その後,メモリアレイでそのセグメントから次のタスクのイメージを取得する」ものである。
ここで,「コントローラ」は,コアアレイの“外部”に存在するものであって,「タスク切り替えに関する指示」は,タスク切り替えを指示する“コマンド”に他ならないから,引用発明は,コアアレイの“外部”から,タスク切り替えの“コマンド”を“受信”して,「既存のタスクがメモリアレイでそのセグメントにバックアップされ,その後,メモリアレイでそのセグメントから次のタスクのイメージを取得する」というタスク切り替えを“開始”しているといえ,かかるタスクの切り替えが実施されるものである以上、タスクの切り替えの実施が何らかの形で“管理”されているといえる。してみると,引用発明の「システムのコントローラロジックによって実行されるプロセス」は,タスクの切り替えを“開始するステップ”とタスクの切り替えを“管理するステップ”を含むといえる。
よって,上記(ア)及び(イ)の検討も踏まえると,本件補正発明と引用発明とは,後記の点で相違するものの,“複数のアプリケーションでスワップ手順を実施するステップ”を含み,“前記マルチプロセッサシステムの外部からのコマンドの受信に応答して,前記スワップ手順を開始するステップ”,及び“スワップ手順を管理するステップ”を含む点で一致する。

イ 上記(ア)?(ウ)の検討から,本件補正発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

<一致点>
「 複数のプロセッサを含むマルチプロセッサシステムにおいて,アプリケーションスワップを実施するための方法であって,
前記方法は,前記複数のプロセッサによって実施されるものであり,
複数のアプリケーションを前記マルチプロセッサシステムのそれぞれの領域に展開するステップを含み,
前記複数のアプリケーションでスワップ手順を実施するステップ,
前記マルチプロセッサシステムの外部からのコマンドの受信に応答して,前記スワップ手順を開始するステップ,
前記スワップ手順を管理するステップ
を含む方法。」

<相違点1>
本件補正発明は,マルチプロセッサシステムが「プロセッサに分散された複数のメモリ」を含むのに対して,引用発明は,そのような特定がなされていない点。

<相違点2>
本件補正発明は,「前記複数のアプリケーションは、第1のリーガル構成の互いに干渉していないアプリケーションの第1のセットに含まれ」,「前記スワップ手順の実施に応答して、前記第1のリーガル構成から第2のリーガル構成に遷移するステップを含み,前記第2のリーガル構成は、前記互いに干渉していないアプリケーションの第1のセットとは異なる互いに干渉していないアプリケーションの第2のセットを含」むものであるのに対して,引用発明は,アプリケーションのタスクを切り替えるものの,そのような特定がなされていない点。

<相違点3>
本件補正発明は,スワップ手順を開始するステップとスワップ手順を管理するステップが,「マルチプロセッサシステムの親タスクによって」行われるものであるのに対して,引用発明は,そのような特定がなされていない点。

<相違点4>
本件補正発明は,スワップ手順を管理するステップが,「複数のアプリケーションの特定のアプリケーションに対して、スワップされる状態となるように要求し、前記特定のアプリケーションから、前記特定のアプリケーションがスワップされる準備ができていることを示す通知を受信すること」であるのに対して,引用発明は,そのような特定がなされていない点。

(4)当審の判断

上記相違点について検討する。

ア <相違点1>について
上記引用文献3には,上記「(2)(2-3)」に示されるように,複数のプロセッサと,前記プロセッサに分散された複数のメモリとを含むマルチプロセッサシステムが開示されている。さらに,上記引用文献3に記載のマルチプロセッサシステムは,「メモリネットワークは混合メモリプログラミングモデルを可能にできる」ものであるから,プログラム可能なマルチプロセッサシステムである。
引用発明と引用文献3に記載の技術は,ともに,プログラム可能なマルチプロセッサシステムという共通の技術分野に属するものであって,複数のプロセッサがアレイ状に配置されている点において,プロセッサの配置構造も共通するものであるから,引用発明に引用文献3に記載のマルチプロセッサシステムの構造を適用し,マルチプロセッサシステムが「プロセッサに分散された複数のメモリ」を含むようにすることは,当業者であれば容易になし得たものである。

イ <相違点2>について
上記引用文献2には,上記「(2)(2-2)」に示されるように,「タイミング制御が相互に干渉しないように分割されたタスクを並行に動作させるのがマルチタスクリアルタイムオペレーティングシステム」が開示されており,分散されたタスクを並行に動作させるマルチタスクオペレーションにおいて,並行に動作させるタスクを相互に干渉しないタスクとすることは,当然に行われている技術にすぎない。
してみると,引用発明は,複数のアプリケーションのタスクを「並行して実行する」マルチプロセッサであるところ,かかる並行に実行されるタスクを“互いに干渉しないタスク”とすること,すなわち,「複数のアプリケーションは,互いに干渉していないアプリケーションのセットに含まれ」るとすることは,当業者であれば当然になし得る事項である。

さらに,引用発明は,「アプリケーションプログラムのセットが実行されるタスクを,アレイ内のそれらのターゲットコアに繰り返しマッピングする」ものであるから,マッピングの前後では,マッピングされている複数のアプリケーションが異なっていることは自明であり,マッピングされる前の複数のアプリケーションの互いに干渉していないタスクが,「第1のリーガル構成のアプリケーションの第1のセット」に含まれるとすると,マッピングされた後の複数のアプリケーションの互いに干渉していないタスクは,「前記第1のリーガル構成とは異なる第2のリーガル構成のアプリケーションの第2のセット」に含まれるといえ、新たにタスクがマッピングされてタスクが切り替えられることは、「第1のリーガル構成から第2のリーガル構成に遷移する」といえる。

以上の検討から,引用発明において,「前記複数のアプリケーションは,第1のリーガル構成の互いに干渉していないアプリケーションの第1のセットに含まれ」,「前記スワップ手順の実施に応答して,前記第1のリーガル構成から第2のリーガル構成に遷移するステップを含み,前記第2のリーガル構成は,前記互いに干渉していないアプリケーションの第1のセットとは異なる互いに干渉していないアプリケーションの第2のセットを含」むものとすることは,引用発明及び引用文献2に記載の上記技術に基づいて,当業者であれば容易に想到し得たものである。

ウ <相違点3>について
引用発明は,「コントローラは,タスク切り替えに関する指示をコアに提供し,既存のタスクがメモリアレイでそのセグメントにバックアップされ,その後,メモリアレイでそのセグメントから次のタスクのイメージを取得する」ものであるから,「タスクの切り替えに関する指示」を提供された「コア」が,既存のタスクをバックアップし,次のタスクのイメージを取得するというタスクの切り替えの手順を開始して管理しているといえる。

一方,この出願の明細書には,「親タスク」について,例えば,段落【0087】に,
「いくつかの実施形態では、アプリケーションスワップを、本出願では親タスク又は管理タスクと呼ばれる特別なタスク又はアプリケーションによって管理してよい。親タスクはMPSの内側又は外側からトリガされて、アプリケーションスワップを開始できる。」と記載され,
段落【0090】に,
「親タスクのデフォルトの挙動は、システムコントローラ262が指示したようにアプリケーションを開始及び停止することであってよい。いくつかの状況では、親タスク55は、スワップ可能なアプリケーションと通信して、その実行状態を管理してよい。例えば親タスク55は、あるスワップ可能なアプリケーションに、上記アプリケーションをスワップアウトできるように、安定状態となるよう要求してよく、又は親タスク55は上記スワップ可能なアプリケーションによって、このアプリケーションが安定状態であり、スワップアウトされる準備ができていることを通知されてよい。この通信は、スワップ可能なアプリケーションが親タスク55と通信するために、又はその逆のために、呼び出すことができるAPIによって実装できる。」
と記載されているものの,明細書の前記記載は,親タスクがスワップ手順を開始して管理するという,親タスクの機能を開示するものにすぎず,マルチプロセッサシステム上の親タスクの物理的な構成が他のタスクとは異なることを開示するものではない。

してみると,引用発明も,前述したように,「タスクの切り替えに関する指示」を提供された「コア」が,タスクの切り替えの手順を開始して管理しているといえるところ,かかる「コア」で実行されているタスクは,タスクの切り替えの手順を開始して管理する機能を有している点において,実質的に「親タスク」であるといえる。
よって,上記<相違点3>は,実質的な相違点であるとは認められない。

エ <相違点4>について
上記参考文献には,上記「(2)(2-4)」に示されるように,
「タスクをスワップアウトするために,オペレーティングシステムは,タスクに状態を保存し,1つを除くすべてのストリームを終了するように要求する。次に,残りの1つのストリームは,タスクの状態が保存され,別のタスクをその保護ドメインにスワップできることをオペレーティングシステムに通知する」
という技術が開示されている。
ここで,「タスクをスワップアウトするために,オペレーティングシステムは,タスクに状態を保存し,1つを除くすべてのストリームを終了するように要求する」ことは,タスクにスワップされる状態になるように要求することといえ,「別のタスクをその保護ドメインにスワップできることをオペレーティングシステムに通知する」ことは,スワップされる準備ができていることを通知することといえる。
してみると,上記参考文献には,タスクをスワップアウトする際に,タスクにスワップされる状態になるように要求し,当該タスクがスワップされる状態になると,当該タスクがスワップされる準備ができていることを通知する技術が開示されているといえる。

引用発明と参考文献に記載の上記技術とは,ともに,タスクの切り替えを行う技術であって,かつ,切り替え対象となる既存のタスクの状態をバックアップ保存するという切り替え手順においても共通するものであるから,引用発明に参考文献に記載の上記技術を適用し,スワップ手順を管理するステップが,「複数のアプリケーションの特定のアプリケーションに対して、スワップされる状態となるように要求し、前記特定のアプリケーションから、前記特定のアプリケーションがスワップされる準備ができていることを示す通知を受信すること」とすることは,当業者であれば容易になし得たものである。

オ 小括
上記ア?エで検討したとおり,<相違点1>?<相違点4>に係る構成は,引用発明,引用文献2?3に記載の技術,及び参考文献に記載の技術に基づいて,当業者が容易に想到し得たものであり,そして,これらの相違点を総合的に勘案しても,本件補正発明の奏する作用効果は,引用発明,引用文献2?3に記載の技術,及び参考文献に記載の技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。
したがって,本件補正発明は,引用発明,引用文献2?3に記載の技術,及び参考文献に記載の技術に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許出願の際独立して特許を受けることができない。

3 本件補正についてのむすび

よって,本件補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
よって,上記補正の却下の決定の結論のとおり決定する。

第3 本願発明について

1 本願発明の認定

令和2年7月27日にされた手続補正は,上記のとおり却下されたので,本願の請求項に係る発明は,令和2年2月19日にされた手続補正により補正された特許請求の範囲の請求項1?10に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,その請求項1に記載された事項により特定される,上記「第2[理由]1(2)」に記載された下記のとおりのものである(再掲)。

「 複数のプロセッサと、前記プロセッサに分散された複数のメモリとを含むマルチプロセッサシステムにおいて、アプリケーションスワップを実施するための方法であって、
複数のアプリケーションを前記マルチプロセッサシステムのそれぞれの領域に展開するステップを含み、前記複数のアプリケーションは、第1のリーガル構成の互いに干渉していないアプリケーションの第1のセットに含まれ、
前記複数のアプリケーションでスワップ手順を実施するステップ、
前記スワップ手順の実施に応答して、前記第1のリーガル構成から第2のリーガル構成に遷移するステップを含み、前記第2のリーガル構成は、前記互いに干渉していないアプリケーションの第1のセットとは異なる互いに干渉していないアプリケーションの第2のセットを含み、
前記マルチプロセッサシステムの外部からのコマンドの受信に応答して、前記マルチプロセッサシステムの親タスクによって、前記スワップ手順を開始するステップ、
前記親タスクによって、前記スワップ手順を管理するステップ
を含む方法。」

2 原査定の拒絶の理由

原査定の拒絶の理由は,この出願の請求項1?10に係る発明は,本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献1?引用文献3に記載された技術に基づいて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない,というものである。

引用文献1.米国特許出願公開第2013/0081044号明細書
引用文献2.藤倉俊幸,「組み込みプログラミングノウハウ入門 第1回 マルチタスクシステムとは」,インターフェース,日本,CQ出版株式会社,2002年3月1日,第28巻,第3号,pp.132-140
引用文献3.国際公開第2012/051577号

3 引用文献

原査定の拒絶の理由に引用された,引用文献1?引用文献3,及びその記載事項は,上記「第2[理由]2(2)(2-1)?(2-3)」に記載したとおりである。

4 対比・判断

(1)本願発明は,上記「第2[理由]2(1)」で検討した本件補正発明の,アプリケーションスワップを実施するための方法について,「前記方法は、前記複数のプロセッサによって実施される」との限定を削除し,スワップ手順を管理するステップについて,「前記複数のアプリケーションの特定のアプリケーションに対して、スワップされる状態となるように要求し、前記特定のアプリケーションから、前記特定のアプリケーションがスワップされる準備ができていることを示す通知を受信すること」との限定を削除したものである。

(2)そうすると,上記「第2[理由]2(3)」における検討内容を踏まえると,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

<一致点>
「 複数のプロセッサを含むマルチプロセッサシステムにおいて、アプリケーションスワップを実施するための方法であって、
複数のアプリケーションを前記マルチプロセッサシステムのそれぞれの領域に展開するステップを含み、
前記複数のアプリケーションでスワップ手順を実施するステップ、
前記マルチプロセッサシステムの外部からのコマンドの受信に応答して、前記スワップ手順を開始するステップ、
前記スワップ手順を管理するステップ
を含む方法。」

<相違点a>
本願発明は,マルチプロセッサシステムが「プロセッサに分散された複数のメモリ」を含むのに対して,引用発明は,そのような特定がなされていない点。

<相違点b>
本願発明は,「前記複数のアプリケーションは、第1のリーガル構成の互いに干渉していないアプリケーションの第1のセットに含まれ」,「前記スワップ手順の実施に応答して、前記第1のリーガル構成から第2のリーガル構成に遷移するステップを含み,前記第2のリーガル構成は、前記互いに干渉していないアプリケーションの第1のセットとは異なる互いに干渉していないアプリケーションの第2のセットを含」むものであるのに対して,引用発明は,アプリケーションのタスクを切り替えるものの,そのような特定がなされていない点。

<相違点c>
本願発明は,スワップ手順を開始するステップとスワップ手順を管理するステップが,「マルチプロセッサシステムの親タスクによって」行われるものであるのに対して,引用発明は,そのような特定がなされていない点。

(3)そして,上記<相違点a>?<相違点c>は,それぞれ,上記「第2[理由]2(3)」における,上記<相違点1>?<相違点3>と同じであることから,上記「第2[理由]2(4)」で検討したように,<相違点a>?<相違点c>は,いずれも格別のではなく,本願発明は,上記引用発明,及び上記引用文献2?3に記載の技術に基づいて,当業者が容易に発明をすることができたものである。

第4 むすび

以上のとおり,本願の請求項1に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。
よって,結論のとおり審決する。

 
別掲
 
審理終結日 2021-02-05 
結審通知日 2021-02-16 
審決日 2021-03-05 
出願番号 特願2018-233478(P2018-233478)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 575- Z (G06F)
最終処分 不成立  
前審関与審査官 北元 健太  
特許庁審判長 田中 秀人
特許庁審判官 小林 秀和
月野 洋一郎
発明の名称 マルチプロセッサ組込みシステム上でのアプリケーションの動的再構成  
代理人 山川 政樹  
代理人 山川 茂樹  

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