• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06F
管理番号 1343613
審判番号 不服2017-18814  
総通号数 226 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-10-26 
種別 拒絶査定不服の審決 
審判請求日 2017-12-19 
確定日 2018-09-21 
事件の表示 特願2017-505630「マルチプロセッサシステムのための指向性イベントシグナリング」拒絶査定不服審判事件〔平成28年 2月11日国際公開、WO2016/022308、平成29年 9月14日国内公表、特表2017-527025、請求項の数(12)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯

本願は,2015年7月24日(パリ条約による優先権主張外国庁受理2014年8月5日,米国)を国際出願日とする出願であって,平成29年6月22日付けで拒絶の理由が通知され,同年8月16日に手続補正書が提出され,同年10月19日付けで拒絶査定(謄本送達日同年10月30日)がなされ,これに対して同年12月19日に審判請求がなされると共に手続補正がなされ,平成30年2月19日付けで審査官により特許法164条3項の規定に基づく報告がなされ,同年4月17日に上申書が提出されたものである。


第2 原査定の概要

原査定(平成29年10月19日付け拒絶査定)の概要は次のとおりである。

(進歩性)この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

記 (引用文献等については引用文献等一覧参照)

・請求項: 1-2,4-5,7-8,10-11
・引用文献等: 1-2

・請求項: 3,6,9,12
・引用文献等: 1-3

<引用文献等一覧>
1.特開2012-138126号公報
2.特開2010-140290号公報(周知技術を示す文献)
3.特開2011-175378号公報(周知技術を示す文献)


第3 審判請求時の補正について

審判請求時の補正は,特許法17条の2第3項から第6項までの要件に違反しているものとはいえない。
審判請求時の補正によって請求項1,4,7,10に「前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する」という事項を追加する補正は,特許請求の範囲の減縮を目的とするものであるか,また,「前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する」という事項は,当初明細書の段落20に記載されているから,当該補正は新規事項を追加するものではないかについて検討すると,審判請求時の補正前に「前記リソースの可用性を示す信号に応じて、前記リソースにアクセスするための最高優先度が割り当てられたプロセッサエレメントに前記リソースにアクセスするようにシグナリングするステップ」(請求項1)において,さらに「リソースにアクセスするための最高優先度が割り当てられたプロセッサエレメント」の動作として,「前記リソースのための利用可能なロックを取得する」ことを限定するものであるから,「前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する」という事項を追加する補正は,特許請求の範囲の減縮を目的とするものである。
また,当初明細書の段落20には,「一実施形態では、プロセッサエレメントがイベントを受信するとき、プロセッサエレメントは、ウェイクアップして、ロックを捉えることを試みることができる。シグナリングイベントマネージャは、リソースに対するロックを捉えて、プロセッサエレメントからプロセッサエレメントの優先度を特定する要求を受信することができる。ロックが利用可能であり、プロセッサエレメントが最高優先度を有する場合、シグナリングイベントマネージャは、そのプロセッサエレメントが利用可能なロックを取得することを可能にし得る。…(後略)」(下線は,当審で説明のために付加。以下同様。)と記載されているから,「前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する」という事項は,当初明細書等に記載された事項であり,新規事項を追加するものではないといえる。
そして,「第4 本願発明」から「第6 対比・判断」までに示すように,補正後の請求項1乃至12に係る発明は,独立特許要件を満たすものである。


第4 本願発明

本願請求項1乃至12に係る発明(以下「本願発明1」乃至「本願発明12」という。)は,平成29年12月19日付け手続補正書によって補正された特許請求の範囲の請求項1乃至12に記載された,次のとおりのものと認める。

「 【請求項1】
複数のプロセッサエレメントを有するコンピューティングデバイス上で1つまたは複数の共通リソースを競合しているプロセッサエレメントを管理するための方法であって、
前記コンピューティングデバイスの動作状態に基づいて、リソースに対するアクセスを要求している前記複数のプロセッサエレメントに優先度を割り当てる際に使用するためのパラメータを決定するステップと、
前記リソースにアクセスするための優先度をプロセッサエレメントに割り当てるステップであって、前記優先度が、前記プロセッサエレメントに関する前記パラメータに基づいて割り当てられる、割り当てるステップと、
前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングするステップと、
前記リソースの可用性を示す信号に応じて、前記リソースにアクセスするための最高優先度が割り当てられたプロセッサエレメントに前記リソースにアクセスするようにシグナリングするステップであって、前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する、ステップと
を含む、方法。
【請求項2】
前記リソースの前記可用性を示す前記信号に応じて、前記リソースにアクセスするための前記最高優先度が割り当てられた、前記複数のプロセッサエレメントのうちの1つを特定するステップと
をさらに含む、請求項1に記載の方法。
【請求項3】
前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングするステップが、スリープ状態に入るように前記プロセッサエレメントをトリガするステップを含み、
前記プロセッサエレメントに前記リソースにアクセスするようにシグナリングするステップが、前記プロセッサエレメントにウェイクアップするようにシグナリングするステップを含む
請求項1に記載の方法。
【請求項4】
コンピューティングデバイスであって、
複数のプロセッサエレメントと、
前記複数のプロセッサエレメントに通信可能に接続され、
前記コンピューティングデバイスの動作状態に基づいて、リソースに対するアクセスを要求している前記複数のプロセッサエレメントに優先度を割り当てる際に使用するためのパラメータを決定することと、
前記リソースにアクセスするための優先度をプロセッサエレメントに割り当てることであって、前記優先度が、前記プロセッサエレメントに関する前記パラメータに基づいて割り当てられる、割り当てることと、
前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングすることと、
前記リソースの可用性を示す信号に応じて、前記リソースにアクセスするための最高優先度が割り当てられたプロセッサエレメントに前記リソースにアクセスするようにシグナリングすることであって、前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する、シグナリングすることと
を含む動作を実行するためのシグナリングイベントマネージャ実行可能命令で構成されたシグナリングイベントマネージャと
を含む、コンピューティングデバイス。
【請求項5】
前記シグナリングイベントマネージャが、
前記リソースの前記可用性を示す前記信号に応じて、前記リソースにアクセスするための前記最高優先度が割り当てられた、前記複数のプロセッサエレメントのうちの1つを特定することと
をさらに含む動作を実行するためのシグナリングイベントマネージャ実行可能命令でさらに構成される、請求項4に記載のコンピューティングデバイス。
【請求項6】
前記シグナリングイベントマネージャが、
前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングすることが、スリープ状態に入るように前記プロセッサエレメントをトリガすることを含み、
前記プロセッサエレメントに前記リソースにアクセスするようにシグナリングすることが、前記プロセッサエレメントにウェイクアップするようにシグナリングすることを含むような動作を実行するためのシグナリングイベントマネージャ実行可能命令でさらに構成される、請求項4に記載のコンピューティングデバイス。
【請求項7】
プロセッサ実行可能ソフトウェア命令を記憶したプロセッサ可読記憶媒体であって、前記プロセッサ実行可能ソフトウェア命令が、複数のプロセッサエレメントを有するコンピューティングデバイスのプロセッサに、
前記コンピューティングデバイスの動作状態に基づいて、リソースに対するアクセスを要求している前記複数のプロセッサエレメントに優先度を割り当てる際に使用するためのパラメータを決定することと、
前記リソースにアクセスするための優先度をプロセッサエレメントに割り当てることであって、前記優先度が、前記プロセッサエレメントに関する前記パラメータに基づいて割り当てられる、割り当てることと、
前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングすることであって、前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する、シグナリングすることと、
前記リソースの可用性を示す信号に応じて、前記リソースにアクセスするための最高優先度が割り当てられたプロセッサエレメントに前記リソースにアクセスするようにシグナリングすることと
を含む動作を実行させる、プロセッサ可読記憶媒体。
【請求項8】
前記記憶されたプロセッサ実行可能ソフトウェア命令が、前記プロセッサに、
前記リソースの前記可用性を示す前記信号に応じて、前記リソースにアクセスするための前記最高優先度が割り当てられた、前記複数のプロセッサエレメントのうちの1つを特定することと
をさらに含む動作を実行させるように構成される、請求項7に記載のプロセッサ可読記憶媒体。
【請求項9】
前記記憶されたプロセッサ実行可能ソフトウェア命令が、前記プロセッサに、
前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングすることが、スリープ状態に入るように前記プロセッサエレメントをトリガすることを含み、
前記プロセッサエレメントに前記リソースにアクセスするようにシグナリングすることが、前記プロセッサエレメントにウェイクアップするようにシグナリングすることを含むような動作を実行させるように構成される、請求項7に記載のプロセッサ可読記憶媒体。
【請求項10】
複数のプロセッサエレメントを有するコンピューティングデバイスであって、
前記コンピューティングデバイスの動作状態に基づいて、リソースに対するアクセスを要求している前記複数のプロセッサエレメントに優先度を割り当てる際に使用するためのパラメータを決定するための手段と、
前記リソースにアクセスするための優先度をプロセッサエレメントに割り当てるための手段であって、前記優先度が、前記プロセッサエレメントに関する前記パラメータに基づいて割り当てられる、割り当てるための手段と、
前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングするための手段と、
前記リソースの可用性を示す信号に応じて、前記リソースにアクセスするための最高優先度が割り当てられたプロセッサエレメントに前記リソースにアクセスするようにシグナリングするための手段であって、前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する、手段と
を含む、コンピューティングデバイス。
【請求項11】
前記リソースの前記可用性を示す前記信号に応じて、前記リソースにアクセスするための前記最高優先度が割り当てられた、前記複数のプロセッサエレメントのうちの1つを特定するための手段と
をさらに含む、請求項10に記載のコンピューティングデバイス。
【請求項12】
前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングするための手段が、スリープ状態に入るように前記プロセッサエレメントをトリガするための手段を含み、
前記プロセッサエレメントに前記リソースにアクセスするようにシグナリングするための手段が、前記プロセッサエレメントにウェイクアップするようにシグナリングするための手段を含む
請求項10に記載のコンピューティングデバイス。」


第5 引用例

1 引用例1に記載された事項
原審における平成29年6月22日付けの拒絶理由(以下,これを「原審拒絶理由」という。)において引用した,本願の第一国出願前に既に公知である,特開2012-138126号公報(平成24年7月19日公開。以下,これを「引用例1」という。)には,関連する図面と共に,次の事項が記載されている。

A 「【0001】
本発明はコンピュータに関し、より詳細には、コンピュータのリソースを管理するためのシステムおよび方法に関する。」

B 「【0021】
本開示は、コンピュータシステム中のリソースを管理するためのリソース管理アーキテクチャについて述べるものである。リソースは、様々なタスクまたは機能を実施するために利用される、コンピュータシステム中の限りある量のコンピューティングコンポーネントである。リソースの例には、ハードウェアデバイス、ポート、CPU処理、メモリ、USB帯域幅、ネットワーク帯域幅、ソフトウェアモジュールなどが含まれる。リソースは、物理的ハードウェア量(例えばCPU、USB帯域幅、ネットワーク帯域幅)である場合もあり、抽象的な量(例えば仮想メモリ、オーディオ音量)である場合もある。」

C 「【0027】
(例示的なシステム)
図1に、コンピューティングユニット22と、コンピューティングユニット22と接続するか他の方法でインタフェースする複数の周辺コンポーネントとを有する娯楽コンピューティングシステム20を示す。コンピューティングユニット22は、1つ以上のプロセッサ24(1)、24(2)、...、24(P)、揮発性メモリ26(例えばRAM)、および不揮発性メモリ28(例えばROM、フラッシュ、ハードディスク、CD ROMなど)を有する。
【0028】
不揮発性メモリ28には、オペレーティングシステム30が記憶されている。オペレーティングシステム30はマルチタスキングオペレーティングシステムであり、揮発性メモリ26にロードされて1つ以上のプロセッサ24上で実行されるとき、複数のアプリケーション32(1)、32(2)、...、32(A)の同時実行をサポートする。好ましいオペレーティングシステムの1つは、本出願人から発売されているWindows(登録商標)ブランドのオペレーティングシステムである。ただし、他のオペレーティングシステムを採用してもよいことに留意されたい。」

D 「【0042】
アーキテクチャ100は、リソースマネージャ102および複数のプロバイダ104(1)、104(2)、104(3)、...、104(P)を有し、プロバイダは1つ以上のリソースコンシューマをサポートする。リソースコンシューマの例には、アプリケーション32(1)、32(2)、...、32(A)などユーザレベルのリソースコンシューマと、リソースコンシューマ35などカーネルレベルのリソースコンシューマが含まれる。各プロバイダ104(1)-104(P)は、1つのリソースに関連し、リソースの可用性を追跡している。前述のようにリソースは、様々なタスクまたは機能を実施するのに利用される、コンピュータシステム中の限りある量のコンピューティングコンポーネントである。したがって、リソースプロバイダの例には、ハードウェアデバイスを所有するドライバ(例えばTVチューナのためのドライバ、バス上の帯域幅を所有するUSBドライバ、CPUタイムリソースのためのCPUスケジューラなど)、ハードウェアコンポーネント(例えばデコーダ)、およびソフトウェアモジュール(例えばソフトウェアデコーダ)が含まれる。さらに、単一のドライバが複数のリソースを提供する場合があることにも留意されたい。この場合、リソースマネージャ102はこのドライバを複数のプロバイダと見なす。リソースプロバイダをカーネルレベルに示すが、1つ以上のリソースプロバイダをユーザレベルに実装することもできる。」

E 「【0046】
リソースマネージャ102は、リソースプロバイダ104から提供されるリソース(ローカルまたはリモート)へのアクセスを調停する。アプリケーション32などのリソースコンシューマは、プロバイダ104から提供される1つ以上のリソースのセットを要求し、リソースマネージャ102は、どのアプリケーションがプロバイダのどのリソースを使用することになるかを決定する。リソースマネージャ102は、所定の競合解決機構に基づいてリソース割振り決定を行う。一実装形態では、競合解決機構は優先度ベースであり、したがってリソースマネージャ102は、優先度に基づいてリソースへのアクセスを調停する。別の実装形態では、競合解決機構は、所与の時に続行できるアクティビティの数を最大限にするように試みる負荷平衡に基づくものとすることができる。」

上記記載事項A乃至Eから,引用例1には次の発明(以下「引用発明」という。)が記載されているといえる。

「コンピュータのリソースを管理するためのシステムおよび方法に関し,
コンピュータシステム中のリソースを管理するためのリソース管理アーキテクチャであって,
様々なタスクまたは機能を実施するために利用され,コンピュータシステム中の限りある量のコンピューティングコンポーネントである,ハードウェアデバイス,ソフトウェアモジュールなどが含まれるリソースと,1つ以上のプロセッサ,揮発性メモリ,および不揮発性メモリを有するコンピューティングユニットとを有し,
前記不揮発性メモリには,オペレーティングシステムが記憶され,前記オペレーティングシステムはマルチタスキングオペレーティングシステムであり,前記揮発性メモリにロードされて1つ以上の前記プロセッサ上で実行されるとき,複数のアプリケーションの同時実行をサポートし,
前記アーキテクチャは,リソースマネージャおよび複数のプロバイダを有し,前記プロバイダは1つ以上のリソースコンシューマをサポートし,
前記リソースコンシューマには,アプリケーションなどが含まれ,
前記各プロバイダは,1つのリソースに関連し,リソースの可用性を追跡しており,
前記リソースマネージャは,プロバイダから提供されるリソースへのアクセスを調停し,
アプリケーションなどのリソースコンシューマは,前記プロバイダから提供される1つ以上のリソースのセットを要求し,
前記リソースマネージャは,どのアプリケーションがプロバイダのどのリソースを使用することになるかを決定し,所定の競合解決機構に基づいてリソース割振り決定を行い,
前記競合解決機構は優先度ベースであり,したがって前記リソースマネージャは,優先度に基づいてリソースへのアクセスを調停する,
コンピュータのリソースを管理するための方法。」

2 引用例2に記載された事項
原審拒絶理由において引用した,本願の第一国出願前に既に公知である,特開2010-140290号公報(平成22年6月24日公開。以下,これを「引用例2」という。)には,関連する図面と共に,次の事項が記載されている。

F 「【0002】
従来のマルチプロセッサシステムの排他制御の調停方法においては、排他制御を実行中であるか否かを示すリソースロックフラグが用いられていた。このリソースロックフラグは、システムにおいて排他制御を実行するプロセッサがある場合にON(‘1’)を示し、そうでない場合にOFF(‘0’)を示す。各プロセッサは、このリソースロックフラグを排他制御の実行前に必ずチェックし、排他制御中である他のプロセッサが存在しない場合、すなわち、リソースロックフラグがOFFを示す場合に限り、システムは当該プロセッサによる排他制御を許可する。一方、排他制御実行中である他のプロセッサが存在する場合、すなわち、リソースロックフラグがONを示す場合には、その時点では当該プロセッサによる排他制御が許可されず、他のプロセッサによる排他制御が終了してリソースロックフラグがOFFに変わるまで待機する。このようにして、従来のマルチプロセッサシステムでは、システムを構成する各プロセッサによる排他制御が調停されていた。
【0003】
しかし、上述したような従来のマルチプロセッサシステムでは、リソースロックフラグという単に排他制御を実行中であるか否かを示す情報のみに基づいて複数のプロセッサ間における排他制御を調停していて、排他制御実行の許可を待機中であるプロセッサを考慮していない。そのため、排他制御が許可されるプロセッサが単純に排他制御要求の受付順等により定まってしまい、排他制御が許可されるプロセッサが偏ることがある。さらに、特定のプロセッサにおいて、排他制御を実行するためにリソースロックフラグをチェックすると、その都度、他のプロセッサが排他制御中であることにより、いつまで待機しても実行が許可されずにプロセッサタイムアウトになることがある。
【0004】
このようなプロセッサタイムアウトを防止可能な従来技術として、例えば、特許文献1に記載の技術が知られている。この従来技術は、排他制御を実行中のプロセッサが存在することを示す排他制御フラグと、プロセッサ毎に、排他制御要求が失敗したことを示す失敗フラグと、再発行された排他制御要求が成功したことを示す成功フラグとを備え、各プロセッサが同一の要求処理順序を判定し実行する分散調停方式により排他制御の調停を行う。これにより、リソースロック調停部への要求受付の順序に依存することなく必ず全プロセッサのリソースロック要求を成功に導き、プロセッサタイムアウトの発生を防ぐことが可能である。
【特許文献1】特開2001-344195
【発明の開示】
【発明が解決しようとする課題】
【0005】
ところで、近年、電子機器の性能向上に伴い、特定の機能については、リアルタイム性が重視されるようになって来た。例えば、デジタルカメラのオートフォーカス機能には、連写時における高速な応答性能が要求される。また、携帯電話の各種機能は、その利用時に操作ボタンの操作に対し高速に応答することが商品価値を高める上で好ましい。
【0006】
このようなリアルタイム性という観点からは、特許文献1に記載の従来技術には以下のような問題があった。すなわち、あるプロセッサがリソースのロック(排他制御)を要求しても、その時点においてロック獲得待ち状態にある他のプロセッサが存在すると、当該他のプロセッサがロックに成功し、そのロックを解除するまでの間ロック獲得待ち状態になり、この過程が他のプロセッサの数だけ繰り返されてその間ずっとロック獲得待ち状態になる可能性がある。特に組込みシステムにおけるリアルタイムOSでは、処理の優先度に応じて実行順序が決定されるが、ロック獲得順序は処理の優先度に関係なくロック要求処理における瞬間的なFIFO(First in, First out)(先入れ先だし)によって決定されてしまう。そのため優先度の高い処理においてロック獲得待ち状態が続いてリアルタイム性の確保が困難となる可能性がある。
【0007】
本発明はこのような課題を解決するためになされたものであり、リアルタイム性を確保することが可能なマルチプロセッサシステム及びその排他制御の調停方法を提供することを目的とする。
【課題を解決するための手段】
【0008】
上記課題を解決するため、本発明に係るマルチプロセッサシステムは、各々のプロセッサが共有リソースを排他的に制御してタスクを処理する複数の前記プロセッサを備え、各々の前記プロセッサは、自身が前記共有リソースの排他制御の獲得を待機しているか否かを示す排他制御待ち情報を保存する排他制御待ち情報保存部と、前記共有リソースの排他制御を獲得する優先度を示す排他制御獲得優先度情報を保存する排他制御獲得優先度情報保持部とを備え、各々の前記プロセッサは、前記排他制御待ち情報と前記排他制御獲得優先度情報とに基づいて前記共有リソースの排他制御を獲得するよう構成されている。
【0009】
この構成によれば、あるプロセッサが共有リソースを制御する必要が生じた時点で排他制御待ち状態である他のプロセッサが存在する場合には、それらのうちで優先度の高いプロセッサが共有リソースの排他制御を獲得するよう構成することにより、リアルタイム性を確保することができる。」

3 引用例3に記載された事項
原審拒絶理由において引用した,本願の第一国出願前に既に公知である,特開2011-175378号公報(平成23年9月8日公開。以下,これを「引用例3」という。)には,関連する図面と共に,次の事項が記載されている。

G 「【0001】
本発明は、マルチプロセッサシステム、及びマルチプロセッサシステムの動作方法に関する。
【背景技術】
【0002】
共有メモリを有したマルチプロセッサシステムにおいて、排他制御のために、ロック方式が提案されている。ロック方式としては、大別して、スピンロック方式とスリープロック方式とが知られている。スピンロック方式では、プロセスがロックを取れるまで、ロック変数にアクセスをし続ける。スリープロック方式では、ロックが取得できなかった場合にプロセスがスリープし、ロックが解放された時にプロセスが起床してロックを取得する。」

H 「【0009】
また、他のスリーププロセスの数に基づいてビジーウェイトとするかスリープとするかを決定した場合、他のスリーププロセスの数が0であれば、ビジーウェイトに設定されてしまう。そのため、ロックを取得しているプロセスが長期間ロックを保持し続けた場合、ビジーウェイト状態が長期間続いてしまう。その結果、CPU資源が浪費され続けてしまう、という問題点があった。
【課題を解決するための手段】」

I 「【0011】
本発明に係るマルチプロセッサシステムの動作方法は、複数のCPUのいずれかにより実行される処理対象プロセスからロック取得要求を受け付け、前記ロック取得要求に応じて、取得対象資源に対応するロックの取得を試みるステップと、前記ロック取得手段がロックの取得に失敗した場合に、前記処理対象プロセスをスピンロック方式で待機させるか、スリープロック方式で待機させるかを決定するステップと、コンテキストスイッチ期間を示す情報を、コンテキストスイッチ期間情報として格納するステップと、前記取得対象資源に対応するロックがプロセスによって保持される期間を示す情報を、ロック保持期間情報として格納するステップと、前記コンテキストスイッチ期間と、前記ロック保持期間とを比較するステップとを具備する。前記決定するステップは、前記比較するステップにおける比較結果に基づいて、前記処理対象プロセスをスピンロック方式で待機させるか、スリープロック方式で待機させるかを決定するステップを備えている。」


第6 対比・判断

1 本願発明1について
(1)対比
本願発明1と引用発明とを対比する。

(ア)引用発明の「1つ以上のプロセッサ,揮発性メモリ,および不揮発性メモリを有するコンピューティングユニット」は,本願発明1の「複数のプロセッサエレメントを有するコンピューティングデバイス」に相当し,引用発明の「リソース」は,本願発明1の「リソース」に相当するといえる。
また引用発明の「コンピュータシステム中のリソースを管理するためのリソース管理アーキテクチャ」において,「様々なタスクまたは機能を実施するために利用され,コンピュータシステム中の限りある量のコンピューティングコンポーネントである,ハードウェアデバイス,ソフトウェアモジュールなどが含まれるリソース」を「アプリケーションなどが含まれ」る「リソースコンシューマ」に対して管理するものであるところ,引用発明の「コンピュータのリソースを管理するための方法」と本願発明1の「複数のプロセッサエレメントを有するコンピューティングデバイス上で1つまたは複数の共通リソースを競合しているプロセッサエレメントを管理するための方法」とは,下記の点で相違するものの,“複数のプロセッサエレメントを有するコンピューティングデバイス上で1つまたは複数の共通リソースを競合している状態を管理するための方法”である点で共通する。

(イ)引用発明の「リソースマネージャ」は,「どのアプリケーションがプロバイダのどのリソースを使用することになるかを決定し,所定の競合解決機構に基づいてリソース割振り決定を行い,前記競合解決機構は優先度ベースであり,したがって前記リソースマネージャは,優先度に基づいてリソースへのアクセスを調停する」ものであるから,引用発明の「リソースマネージャは,どのアプリケーションがプロバイダのどのリソースを使用することになるかを決定し,所定の競合解決機構に基づいてリソース割振り決定を行」うことと,本願発明1の「前記リソースにアクセスするための優先度をプロセッサエレメントに割り当てるステップであって、前記優先度が、前記プロセッサエレメントに関する前記パラメータに基づいて割り当てられる、割り当てるステップ」とは,下記の点で相違するものの,“前記リソースにアクセスするための優先度を割り当てるステップ”の点で一致する。

(ウ)引用発明の「アーキテクチャ」は,「リソースマネージャおよび複数のプロバイダを有し,前記プロバイダは1つ以上のリソースコンシューマをサポート」し,「前記各プロバイダは,1つのリソースに関連し,リソースの可用性を追跡して」いることから,当該「リソース」からは,何らかの「可用性」に係る信号が存在することがうかがわれ,引用発明の「前記リソースマネージャは,どのアプリケーションがプロバイダのどのリソースを使用することになるかを決定し,所定の競合解決機構に基づいてリソース割振り決定を行い,前記競合解決機構は優先度ベースであり,したがって前記リソースマネージャは,優先度に基づいてリソースへのアクセスを調停する」ことと,本願発明1の「前記リソースの可用性を示す信号に応じて、前記リソースにアクセスするための最高優先度が割り当てられたプロセッサエレメントに前記リソースにアクセスするようにシグナリングするステップであって、前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する」こととは,下記の点で相違するものの,“前記リソースの可用性を示す信号に応じて,前記リソースにアクセスするようにシグナリングするステップ”である点で一致する。

(エ)以上,(ア)乃至(ウ)の検討から,引用発明と本願発明1とは,次の一致点及び相違点を有する。

〈一致点〉
複数のプロセッサエレメントを有するコンピューティングデバイス上で1つまたは複数の共通リソースを競合している状態を管理するための方法であって,
前記リソースにアクセスするための優先度を割り当てるステップと,
前記リソースの可用性を示す信号に応じて,前記リソースにアクセスするようにシグナリングするステップとを含む,方法。

〈相違点1〉
本願発明1が,「複数のプロセッサエレメントを有するコンピューティングデバイス上で1つまたは複数の共通リソースを競合しているプロセッサエレメントを管理する」ものであるのに対し,引用発明は,「コンピュータシステム中のリソースを管理するためのリソース管理アーキテクチャ」の「リソースマネージャ」が「アプリケーションなどが含まれ」る「リソースコンシューマ」による「プロバイダから提供されるリソースへのアクセスを調停」するものであって,「1つまたは複数の共通リソースを競合しているプロセッサエレメント」を管理するものではない点。

〈相違点2〉
本願発明1が,「前記コンピューティングデバイスの動作状態に基づいて、リソースに対するアクセスを要求している前記複数のプロセッサエレメントに優先度を割り当てる際に使用するためのパラメータを決定するステップ」を有し,「前記優先度が、前記プロセッサエレメントに関する前記パラメータに基づいて割り当てられる」のに対し,引用発明はそのような構成を有しない点。

〈相違点3〉
本願発明1が,「前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングするステップ」を有するのに対し,引用発明はそのような構成を有しない点。

〈相違点4〉
本願発明1は「リソースにアクセスするようにシグナリングする」のが,「前記リソースにアクセスするための最高優先度が割り当てられたプロセッサエレメント」であり,「前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する」のに対し,引用発明は,そのような構成を有しない点。

(2) 相違点についての判断
事案に鑑み,先に相違点1及び3について検討する。
本願発明1は,マルチプロセッサシステムのための指向性イベントシグナリングに関するものであり(本願明細書段落1),マルチコアプロセッサは,並列アプリケーションの正当性を保証するためにアトミック性(atomicity)に依存し,プロセスが相互排除におけるクリティカルセクションを実行するために必要とされるリソースに対するロックを取得するといったことが従来試みられており,そのようなロックの一例はスピンロックであるが,スピンロックプロセスはアクティブな状態に留まり,有用なタスクを実行しないので,このアクティブな待機動作によってエネルギーが消費されることなどを技術的背景とし(同段落2),これを解決するために,リソースが利用可能でないとの決定に応じて,リソースに対するアクセスを要求しているプロセッサエレメントにイベントを待機するようにシグナリングし,リソースが利用可能になるのに応じて,そのプロセッサエレメントにそのリソースにアクセスするようにシグナリングする(同段落3)ことを技術的解決手段として提案するものである。また,本願明細書の段落16には,「本実施形態は一般に、複数のメモリデバイスおよび限られた電力バジェットを実装する任意の電子デバイスにおいて有用であり、プロセッサの電力消費を低減することは、モバイルコンピューティングデバイスのバッテリー動作時間を延ばすことができる。」といった,作用効果の一例を示す記述もみられる。
一方,引用発明は,「コンピュータのリソースを管理するためのシステムおよび方法」に関し,今日のパーソナルコンピュータには,従来のデスクトップアプリケーションに加えて,オーディオビデオファイルの再生,音楽CDの再生,ブロードキャスト番組の受信および表示などが求められ(引用例1の段落2),より多様なタスクを実行することがコンピュータに求められている中で,ユーザが複数タスクの同時実施を期待するのは珍しいことではなく,このユーザ需要の増加により,様々なタスクに対処するために既存のリソースに対してより多くの需要が生じ,このことにより,すべてのタスクを同時に達成するのに十分なリソースを要求時にコンピュータが備えていない(同段落4)といったことを解決しようとする課題とし,具体的な事例として,「テレビジョンアプリケーションがレコーダアプリケーションに勝ってチューナ制御権を握った場合、ユーザが第2の番組を見ることよりも第1の番組を録画することの方にずっと興味があるかもしれなくても、テレビジョンアプリケーションがリソース(すなわちチューナ)を制御することになる。アプリケーションがリソースを得ると、リソースは、アプリケーションが明示的に明け渡すまでアプリケーションによって保持される。」(同段落6)といった課題が例示されている。
してみると,引用発明は,その対象を「コンピュータシステム」として,当該「コンピュータシステム」中の「限りある量のコンピューティングコンポーネントである,ハードウェアデバイス,ソフトウェアモジュールなどが含まれるリソース」を管理するものであり,また,引用発明が,「前記不揮発性メモリには,オペレーティングシステムが記憶され,前記オペレーティングシステムはマルチタスキングオペレーティングシステムであり,前記揮発性メモリにロードされて1つ以上の前記プロセッサ上で実行されるとき,複数のアプリケーションの同時実行をサポート」するものであることを考慮すると,「アプリケーションなどが含まれ」る「リソースコンシューマ」が「プロバイダから提供される1つ以上のリソースのセットを要求」し,「リソースマネージャ」が「プロバイダから提供されるリソースへのアクセスを調停」するに際し,当該「リソースコンシューマ」を,「アプリケーション」から「プロセッサエレメント」に置き換える動機を見いだせないばかりか,当該「リソースコンシューマ」に対して,「マルチタスキングオペレーティングシステム」が「複数のアプリケーションの同時実行をサポート」しているにも関わらず,「リソースが利用可能になるのを待機するようにシグナリングする」ことに動機付けがあるとはいえない。このことは,上記引用例2乃至3における上記記載事項F乃至Iの記載をもってしても,相違点1及び3に係る本願発明1の構成を適宜になし得たとすることはできない。
したがって,上記その余の相違点について判断するまでもなく,本願発明1は,当業者であっても,引用発明及び引用例2乃至3に記載された技術的事項に基づいて容易に発明できたものとはいえない。

2 本願発明4,7及び10について
本願発明4,7及び10も,本願発明1の「前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングするステップ」と同様の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明及び引用例2乃至3に記載された技術的事項に基づいて容易に発明できたものとはいえない。

3 本願発明2乃至3,5乃至6,8乃至9及び11乃至12について
本願発明2乃至3,5乃至6,8乃至9及び11乃至12は,それぞれ本願発明1,4,7及び10を引用するものであって,本願発明1の「前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングするステップ」と同様の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明及び引用例2乃至3に記載された技術的事項に基づいて容易に発明できたものとはいえない。


第7 原査定について

<特許法29条2項について>

審判請求時の補正により,本願発明1乃至12は上記「前記リソースが利用可能でないとの決定に応じて、前記リソースに対するアクセスを要求している前記プロセッサエレメントに前記リソースが利用可能になるのを待機するようにシグナリングするステップ」に係る構成に加え,「前記リソースにアクセスするための前記最高優先度が割り当てられた前記プロセッサエレメントが、前記リソースのための利用可能なロックを取得する」という事項を有するものとなっており,当業者であっても,拒絶査定において引用された引用文献1乃至3に基づいて,容易に発明できたものとはいえない。したがって,原査定の理由を維持することはできない。


第8 むすび

以上のとおり,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2018-09-07 
出願番号 特願2017-505630(P2017-505630)
審決分類 P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 大桃 由紀雄  
特許庁審判長 辻本 泰隆
特許庁審判官 須田 勝巳
山崎 慎一
発明の名称 マルチプロセッサシステムのための指向性イベントシグナリング  
代理人 黒田 晋平  
代理人 村山 靖彦  

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