ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F 審判 査定不服 特174条1項 特許、登録しない(前置又は当審拒絶理由) G06F |
|---|---|
| 管理番号 | 1312326 |
| 審判番号 | 不服2014-18781 |
| 総通号数 | 197 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2016-05-27 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2014-09-19 |
| 確定日 | 2016-03-09 |
| 事件の表示 | 特願2011-512507「ユーザ・インターフェースの前景アクセスの決定論的制御を行う無線通信デバイス」拒絶査定不服審判事件〔平成21年12月10日国際公開、WO2009/148776、平成23年 9月29日国内公表、特表2011-526012〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は、2009年5月12日(パリ条約による優先権主張外国庁受理2008年6月5日、米国)を国際出願日とする出願であって、平成24年10月5日付けで拒絶理由通知がなされ、平成25年3月18日付けで手続補正がなされ、同年9月26日付けで拒絶理由通知がなされ、平成26年5月13日付けで拒絶査定がなされ、これに対し、平成26年9月19日に拒絶査定不服審判の請求がなされると同時に手続補正がなされ、平成27年7月23日付けで拒絶理由通知がなされ、同年9月9日に手続補正がなされたものである。(以下、平成27年9月9日付けの手続補正を「本件補正」という。) 第2 本件補正について 1.当審が通知した拒絶理由通知 平成27年7月23日付けで当審が通知した拒絶理由のうち、特許法第17条の2第3項に規定する要件を満たしていないことを理由とするものは、次のとおりである。 「[A] 平成26年9月19日付けでした手続補正は、下記の点で願書に最初に添付した明細書、特許請求の範囲又は図面(以下、「当初明細書等」という。)に記載した事項の範囲内においてしたものでないから、特許法第17条の2第3項に規定する要件を満たしていない。 記 請求項1には「該複数の常駐アプリケーションに含まれる優先度データと所定の基準に基づいて決定するように構成されたアービタ」と記載されているが、当初明細書等には、アービタが複数の常駐アプリケーションに含まれる優先度データに基づいて決定することは記載されていない(請求人は審判請求書で補正の根拠として段落【0007】を挙げているが、当該段落には、「1つの実施形態において、該無線通信デバイスの該コンピュータ・プラットフォーム上の該複数の常駐アプリケーションのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する方法であって、・・・(略)・・・、該方法は、該無線通信デバイスの該ディスプレイ上に該ユーザ・インターフェースを表示し、ここで、該ディスプレイは、該コンピュータ・プラットフォーム上に常駐する1またはそれより多くのアプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成され、その後、該ディスプレイを制御せよというリクエストを該複数の常駐アプリケーションのうちの1またはそれより多くのものからアービタにおいて受信し、該アービタは該コンピュータ・プラットフォーム上に常駐し、及び該1またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを所定の基準に基づいて該アービタで決定し、あるいは該1またはそれより多くの常駐アプリケーションが、該ディスプレイの制御の優先度を示す優先度データを含む場合、該1またはそれより多くの常駐アプリケーションは、いずれのアプリケーションの1つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する、複数のステップを含む。」と記載されているだけで、アービタが複数の常駐アプリケーションに含まれる優先度データに基づいて決定することは記載されていない)。 ・・・(略)・・・ 請求項26には「アービタが、該複数の常駐アプリケーションのうちのいずれのアプリケーションが、各呼び出されたアプリケション内の該優先度データに基づいて該ディスプレイを制御するかを決定する」と記載されているが、当初明細書等には、アービタが優先度データに基づいて決定することは記載されていない。 ・・・(略)・・・ よって、請求項1?29に記載した事項は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内にない。」 2.当審の判断 当審は、本件補正は、当初明細書等に記載した事項の範囲内においてされたものでなく、特許法第17条の2第3項に規定する要件を満たしていないことを理由とする拒絶理由は、解消していないと判断する。 理由は次のとおりである。 本件補正後の特許請求の範囲の請求項26の記載は、以下の＜本件補正後の請求項26＞の欄に転記するとおりであるが、そのうちの下線を施した「(f5)該コンピュータ・プラットフオーム上に常駐するアービタが、該複数の常駐アプリケーションのうちのいずれのアプリケーションが、各呼び出されたアプリケーション内の該優先度データに基づいて該ディスプレイを制御するかを決定すること」という発明特定事項は、本願の出願当初の明細書、特許請求の範囲又は図面(以下「当初明細書等」という。)等の全ての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項に該当するものといわざるを得ず、このことは、本件補正が当初明細書等に記載した事項の範囲内でされたものでないことを意味し、上記平成27年7月23日付けで当審が通知した拒絶理由であって、特許法第17条の2第3項に規定する要件を満たしていないことを理由とする拒絶理由が解消していないことを意味する。 ＜本件補正後の請求項26＞ 「 【請求項26】 (f1)下記を具備する、無線通信デバイスのコンピュータ・プラットフォーム上の常駐アプリケーションのいずれのユーザ・インターフェースがそのディスプレイを制御するかを決定する方法、 (f2)該ユーザ・インターフェースは、少なくとも、該無線通信デバイスの該ディスプレイ上に現れ、それを通じて該無線通信デバイスのユーザが該コンピュータ・プラットフォームと対話する、 (f3)該無線通信デバイスの該ディスプレイ上に該ユーザ・インターフェースを表示すること、該ディスプレイは該コンピュータ・プラットフォーム上に常駐しておりその上で選択され呼び出される複数の常駐アプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成され、該複数の常駐アプリケーションの各々は、該アプリケーションが該ディスプレイを制御する優先度を決定する優先度データを含む、 (f4)事象を該複数の常駐アプリケーションのうちの複数のものに通知すること、 (f5)該コンピュータ・プラットフオーム上に常駐するアービタが、該複数の常駐アプリケーションのうちのいずれのアプリケーションが、各呼び出されたアプリケーション内の該優先度データに基づいて該ディスプレイを制御するかを決定すること。」 審判請求人は、この点につき、平成27年9月9日付けの意見書において、次のとおり主張している。 「本願明細書の段落[0006]に、「・・・該コンピュータ・プラットフォーム上に常駐するアービタ・アプリケーション・・・」と説明されているように、常駐するアービタは、常駐するアービタ・アプリケーションとも表現されています。 本願明細書の段落[0007]には、下記記載があります。 「・・・該アービタは該コンピュータ・プラットフォーム上に常駐し、・・・あるいは該1またはそれより多くの常駐アプリケーションが、該ディスプレイの制御の優先度を示す優先度データを含む場合、該1またはそれより多くの常駐アプリケーションは、いずれのアプリケーションの1つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する、複数のステップを含む。」(参照のために、強調線が付されています。) 上記記載の下線を付記した「該1またはそれより多くの常駐アプリケーション」は、いずれのユーザ・インターフェースが該ディスプレイを制御するかを決定することから、上記段落[0006]に記載された常駐するアービタ・アプリケーションであることが理解できます。 従って、該段落[0007]の記載に基づいても、平成26年9月19日付けの補正で、請求項1などに追加した「該複数の常駐アプリケーションに含まれる優先度データ」は、新規事項ではありません。」 そこで、審判請求人の主張について検討するに、出願当初の明細書の段落【0006】及び段落【0007】には、次のとおり記載されている。 「【0006】 簡単に述べると、ローカルのコンピュータ・プラットフォーム上に常駐する1またはそれより多くのアプリケーションを有し、さらに少なくとも1つの無線通信インターフェース、及びディスプレイを含む無線通信デハイスがここにおいて提供される。各アプリケーションは、それがユーザと対話するために使用するユーザ・インターフェースを有する。該コンピュータ・プラットフォーム上に常駐するアービタ・アプリケーションは、マルチプル・アプリケーションを呼出した事象の特性(nature)に基づいて、あるいは最も最近用いられたアルゴリズム、優先順位付け(prioritization) 方式のような、所定の基準に基づいて、いずれのアプリケーションがそのユーザ・インターフェースを該前景にもっていく(bring)ことができるかを制御する。 【0007】 ・・・(略)・・・該方法は、該無線通信デバイスの該ディスプレイ上に該ユーザ・インターフェースを表示し、ここで、該ディスプレイは、該コンピュータ・プラットフォーム上に常駐する1またはそれより多くのアプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成され、その後、該ディスプレイを制御せよというリクエストを該複数の常駐アプリケーションのうちの1またはそれより多くのものからアービタにおいて受信し、該アービタは該コンピュータ・プラットフォーム上に常駐し、及び該1またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを所定の基準に基づいて該アービタで決定し、あるいは該1またはそれより多くの常駐アプリケーションが、該ディスプレイの制御の優先度を示す優先度データを含む場合、該1またはそれより多くの常駐アプリケーションは、いずれのアプリケーションの1つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する、複数のステップを含む。」 出願当初の明細書の段落【0006】の「ローカルのコンピュータ・プラットフォーム上に常駐する1またはそれより多くのアプリケーションを有し、・・・(略)・・・各アプリケーションは、それがユーザと対話するために使用するユーザ・インターフェースを有する。」及び同段落【0007】の「該ディスプレイは、該コンピュータ・プラットフォーム上に常駐する1またはそれより多くのアプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成され」という記載から、本願における「1またはそれより多くのアプリケーション」は、ユーザ・インタフェースを有し、ディスプレイを選択的に制御するものと認められる。 一方、同段落【0006】の「アービタ・アプリケーションは、・・・(略)・・・、所定の基準に基づいて、いずれのアプリケーションがそのユーザ・インターフェースを該前景にもっていく(bring)ことができるかを制御する。」及び同段落【0007】の「該ディスプレイを制御せよというリクエストを該複数の常駐アプリケーションのうちの1またはそれより多くのものからアービタにおいて受信し・・・(略)・・・該1またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを所定の基準に基づいて該アービタで決定し、」という記載から、本願におけるアービタ・アプリケーションは、1またはそれより多くのアプリケーションからディスプレイを制御せよというリクエストを受信し、所定の基準に基づいて、いずれのアプリケーションがそのユーザ・インターフェースを前景にもっていく(bring)ことができるかを制御するものと認められる。 ここで、当初明細書等には、アービタ・アプリケーションがユーザ・インタフェースを有すること及びディスプレイを選択的に制御することは記載されておらず、また、このことは、当業者に自明な事項であるとも認められない。 したがって、出願当初の明細書の段落【0006】及び段落【0007】の上記記載等から、1またはそれより多くのアプリケーションとアービタ・アプリケーションとは異なる機能のアプリケーションであると認められる。 また、同段落【0007】の「あるいは」という記載より前には、「該ディスプレイを制御せよというリクエストを該複数の常駐アプリケーションのうちの1またはそれより多くのものからアービタにおいて受信し、該アービタは該コンピュータ・プラットフォーム上に常駐し、及び該1またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを所定の基準に基づいて該アービタで決定し、」と記載されており、「あるいは」という記載より後には、「該1またはそれより多くの常駐アプリケーションが、該ディスプレイの制御の優先度を示す優先度データを含む場合、該1またはそれより多くの常駐アプリケーションは、いずれのアプリケーションの1つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する」と記載されている。 ここで、「あるいは」という、複数の異なるもののうち一つを選択するときに用いる接続詞が用いられていることから、当該接続詞の前に記載されている、「ディスプレイを制御せよというリクエストを複数の常駐アプリケーションのうちの1またはそれより多くのものからアービタにおいて受信し、該アービタは該コンピュータ・プラットフォーム上に常駐し、及び該1またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを所定の基準に基づいて該アービタで決定し、」という実施態様と、当該接続詞の後に記載されている、「該1またはそれより多くの常駐アプリケーションが、該ディスプレイの制御の優先度を示す優先度データを含む場合、いずれのアプリケーションの1つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する」という実施態様とは、別異の実施態様と認められる。 したがって、「あるいは」という記載より前に記載されている「該アービタは該コンピュータ・プラットフォーム上に常駐し」という記載及び「あるいは」という記載より後に記載されている「1またはそれより多くの常駐アプリケーションは、・・・(略)・・・いずれのアプリケーションの1つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する」という記載をもって、「1またはそれより多くの常駐アプリケーション」がアービタ・アプリケーションであると認めることはできない。 そして、1またはそれより多くの常駐アプリケーションがディスプレイの制御の優先度を示す優先度データを含む場合に、アービタが、いずれのアプリケーションの1つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定するということは、当初明細書等には記載されておらず、当業者に当業者に自明な事項であるとも認められない。 したがって、審判請求人の主張は採用することができない。 3.小括 以上のとおり、本件補正は、特許法第17条の2第3項の要件を満たさないものである。 第3 本願発明について 1.本願発明 本願請求項22に係る発明(以下「本願発明」という。)は、平成27年9月9日付け手続補正書の請求項22に記載された、以下のとおりのものである。 「(d1)下記を具備する、無線通信デバイス、 (d2)該無線通信デバイスのユーザにユーザ・インターフェースを表示するための手段、 (d3)該表示するための手段は該無線通信デバイス上に常駐する複数の常駐アプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成される、 (d4)コンピュータのプラットフォーム上に常駐する該複数の常駐アプリケーションのうちのいずれのユーザ・インターフェースが該表示するための手段を制御するかを所定の基準に基づいて決定するように構成された、該コンピュータ・プラットフォーム上に常駐するアービタ。」 2.引用発明 平成27年7月23日付けの当審の拒絶の理由で引用された特開2004-78936号公報(以下「引用例」という。)には、次の記載がある。 「【0015】 以上のように本発明によれば、リソースアクセス部により優先度に基づきリソースのアクセス制御を行うことで、個々のソフトウェア作成時に、特定のソフトウェア(例えば携帯電話の場合には電話機能)を優先することを考慮しなくてよくなり、ソフトウェア作成者の負担が減少し、ソフトウェアの構成もより単純になる。また、特定の機能(例えば電話機能)を優先するという特別なルールが不要になるため、サードパーティがソフトウェアを作成する敷居が低くなり、より多くのソフトウェアが作成されることが期待される。また、各ソフトウェアの優先度を任意に設定しなおしたい場合には、テーブル等で規定されたルールを変更するだけでよく、ソフトウェアの再利用性が向上する。さらに、リソース部16のプログラムとしては、本発明の競合解決の枠組みに合う関数を作成してリソースアクセス部11に登録するだけでよく、リソース部16の再利用性が高まる。 ・・・(略)・・・ 【0017】 (第1の実施形態) 図1に、本発明の第1の実施形態に係る情報処理端末の構成を示す。図1において、情報処理端末は、リソースアクセス部11と、使用状態判定部12と、競合判定部13と、使用中ソフトウェア優先度管理部14と、要求ソフトウェア優先度取得部15と、リソース部16と、実行部17とから構成される。 【0018】 リソース部16は、携帯端末などにおけるデバイスであって、例えばスピーカや液晶ディスプレイなどである。実行部17はプログラムであって、より具体的には、アプリケーション、あるいはアプリケーションにくみ込み可能なライブラリやその他のミドルウェア、あるいはドライバである。 【0019】 次に、上記構成を有する情報処理端末の動作を、図2のシーケンスチャートを参照して説明する。この図のシーケンスチャートを説明するにあたり、実行部17はアプリケーションであると仮定する。・・・(略)・・・ 【0020】 まず、ユーザの操作を契機として、アプリケーションAよりも優先度が高いアプリケーションBが、リソース部16を使用するためにリソースアクセス部11に対してアクセス要求を行う(S1)。 【0021】 次に、リソースアクセス部11は、アプリケーションBの要求を解析し、アプリケーションBがアクセスしようとしているリソースを認識し、そのリソースを他のアプリケーションが現在使用中かどうか、使用状態判定部12に対して問い合わせを行う。使用状態判定部12は、指定されたリソースにアクセスしているアプリケーションがあるかどうかを判定し、リソースアクセス部11にこの判定結果を返す(S2)。リソースアクセス部11はこの判定結果を受けて、リソースを現在使用中のアプリケーションがなければ(S2でNO)、アプリケーションBが要求したコマンドをリソース部16に伝える(S8)。このとき、予めリソースアクセス部11に登録しておいた関数が使用される。 【0022】 ステップS2で、リソースを現在使用中のアプリケーション(アプリケーションA)があると判定された場合は(S2でYES)、リソースアクセス部11は競合を解決するために競合判定部13にアプリケーションBの情報を渡し、判定を要求する。競合判定部13は、まず現在使用中のアプリケーションAの優先度を使用中ソフトウェア優先度管理部14に問い合わせ、アプリケーションAのリソースに対する優先度を得る(S3)。なお、使用中ソフトウェア優先度管理部14は、あるアプリケーションがあるリソースを使用したときに、例えば図3に示すような優先度管理テーブルを参照してこのアプリケーションの優先度を取得し、管理する。 【0023】 次に、競合判定部13は、要求ソフトウェア優先度取得部15に問い合わせて、アプリケーションBのリソースに対する優先度を得る(S4)。なお、要求ソフトウェア優先度取得部15は、例えば図3に示すような優先度管理テーブルを参照して、アプリケーションBの優先度を取得する。このテーブルにおいて、アプリケーションの種類としては、例えば、図3に示すようにアプリケーションの名前を使用してもよいし、アプリケーション毎に振られるアプリケーションIDを使用してもよいし、アプリケーションをグループ化した場合にアプリケーショングループ毎に振られるアプリケーショングループIDを使用してもよいし、アプリケーションを実行しているプロセスやスレッドのIDを使用してもよい。このようにテーブルで優先度を管理することで、簡単に優先度の設定を変更ができ、将来優先度が変更した場合にもアプリケーションを変更しなくてもよい。 【0024】 そして、競合判定部13は、使用中ソフトウェア優先度管理部14から得られたアプリケーションAの優先度と、要求ソフトウェア優先度取得部15から得られたアプリケーションBの優先度とを比較し、その比較結果をリソースアクセス部11に返す。(ステップS5)。 【0025】 リソースアクセス部11は、競合判定部13の比較結果を基に、アプリケーションBの優先度がアプリケーションAよりも低ければ、リソースへのアクセスを拒否すべくアプリケーションBに対してアクセスエラーを返す(S6)。一方、アプリケーションBの優先度がアプリケーションAよりも高ければ、予め登録されている関数をコールすることによってリソース部16に対してアプリケーションAの処理をキャンセルするよう要求する(S7)。例えばアプリケーションAがスピーカから音楽を出力させていた場合には、スピーカに音楽の出力を中止させる。つづいてアプリケーションBの要求にしたがってリソースにアクセスする(S8)。このときリソースアクセス部11は、リソース競合が発生してリソースが奪われたことをアプリケーションAに対してエラーとして通知する。同時にどのアプリケーションとリソースの競合が発生しているのか通知することも可能である。 ・・・(略)・・・ 【0028】 なお、本実施形態では、実行部17がアプリケーションであると仮定したが、実行部17はアプリケーションに限らず、単にアプリケーションから要求を受けたミドルウェアや、ドライバなどのソフトウェアであってもよい。 【0029】 また本実施形態では、使用中ソフトウェア優先度管理部14および要求ソフトウェア優先度取得部15は、図3に示すような単にアプリケーション毎に優先度が設定されているような優先度管理テーブルに基づいて優先度を取得するとしたが、本発明はこれに限らない。例えば、図4に示すように、アプリケーションの種類とリソースの種類との組み合わせ毎に優先度が設定されているような優先度管理テーブルに基づいて優先度を取得してもよい。 ・・・(略)・・・ 【0031】 また、リソースの一例としてスピーカをあげたが、リソースはスピーカに限らず、例えばLEDやディスプレイであってもよいし、さらには具体的なデバイスに限らず、通信コネクションのような抽象的なリソースであってもよい。 ・・・(略)・・・」 ここで、上記記載を関連図面及び本願優先日前からの技術常識に照らせば、以下のことがいえる。 (1)段落【0017】、【0018】等の記載から明らかなように、引用例の情報処理端末には、リソースとして液晶ディスプレイを備えた携帯端末が含まれるものである。 (2)ブラウザ、メール、電話等のアプリケーションのユーザ・インタフェースがディスプレイに表示されることは、本願優先日前から技術常識であり、段落【0023】、【0029】等の記載及び図3に示されている「ブラウザ」「メール」「電話」といったアプリケーション名並びに上記技術常識から、引用例のアプリケーションは、液晶ディスプレイに表示されるユーザ・インタフェースを有し、該ユーザ・インタフェースによって液晶ディスプレイの表示を制御するものである。 (3)段落【0019】から【0026】まで、【0029】等の記載及び図3の記載から、引用例の情報処理端末は、アプリケーションがリソースを使用しようとした場合に、リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部、要求ソフトウェア優先度取得部が、アプリケーション毎に設定された優先度に基づいて、リソースを使用するアプリケーションを判定するものである。 そして、リソースは、複数のアプリケーションのうち、上記判定によって選択されたアプリケーションによって選択的に制御されるものである。 したがって、引用例には次の発明(以下「引用発明」という。)が記載されているといえる。 「(d1)下記を具備する携帯端末、 (d2)該携帯端末のユーザに、アプリケーションのユーザ・インタフェースを表示するための液晶ディスプレイ、 (d3)該液晶ディスプレイは複数のアプリケーションの該ユーザ・インタフェースにより選択的に制御されるように構成される、 (d4)該複数のアプリケーションのうちのいずれのユーザ・インタフェースが該液晶ディスプレイを制御するかをアプリケーション毎に設定された優先度に基づいて決定する、リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部及び要求ソフトウェア優先度取得部。」 3.対比 本願発明と引用発明とを対比すると、次のことがいえる。 (1)引用発明でいう「携帯端末」「液晶ディスプレイ」はそれぞれ、本願発明でいう「無線通信デバイス」「表示するための手段」に相当する。 (2)引用発明でいう「アプリケーション毎に設定された優先度」は、本願発明でいう「所定の基準」に相当する。 (3)引用発明でいう「リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部及び要求ソフトウェア優先度取得部」は、アプリケーション毎に設定された優先度に基づいて、液晶ディスプレイを使用するアプリケーションを判定するものであるから、本願発明でいう「アービタ」に相当する。 したがって、本願発明と引用発明との間には、次の一致点、相違点があるといえる。 (一致点) 「(d1)下記を具備する、無線通信デバイス、 (d2)該無線通信デバイスのユーザにユーザ・インターフェースを表示するための手段、 (d3)該表示するための手段は複数のアプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成される、 (d4)該複数のアプリケーションのうちのいずれのユーザ・インターフェースが該表示するための手段を制御するかを、所定の基準に基づいて決定するように構成された、アービタ。」 (相違点) 本願発明では、「複数のアプリケーション」が「無線通信デバイス上に常駐する複数の常駐アプリケーション」及び「コンピュータのプラットフォーム上に常駐する複数の常駐アプリケーション」とされ、「アービタ」が「コンピュータ・プラットフォーム上に常駐するアービタ」とされるのに対し、引用発明では、「複数のアプリケーション」及び「アービタ」が常駐とはされていない点 4.判断 (1)上記相違点について 一般に、常時使用されるアプリケーションを、コンピュータ・プラットフォーム上に常駐させることは、当業者に慣用される事項である。 一方、引用例の図3等から明らかなように引用発明の複数のアプリケーションとしては、メールアプリケーションや電話アプリケーションが想定されており、それらのメールアプリケーション及び電話アプリケーションは、メール及び電話の受信、着信等の事象の有無を確認するために、引用発明の携帯端末において常時使用されるのが普通である。 以上を踏まえると、引用発明において複数のアプリケーションをコンピュータ・プラットフォーム上及び無線通信デバイス上に常駐させることは、当業者であれば容易に想到し得たことである。 また、コンピュータに特定の機能を実装する場合に、ソフトウェア(アプリケーション)として実装すること及びハードウェアとして実装することは、いずれも当業者に慣用される事項であり、いずれによって実装するかは、製造コスト等の事情に応じて決定され得るものであるから、引用発明のアービタ(リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部及び要求ソフトウェア優先度取得部)の機能をソフトウェア(アプリケーション)として実装することも、当業者であれば容易に想到し得たことである。 そして、引用発明の上記アービタ(リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部及び要求ソフトウェア優先度取得部)は、どのアプリケーションのユーザ・インタフェースをディスプレイに表示させるかを判定するために、アプリケーションの起動等の事象の有無を確認するものであり、その機能は、常時使用される機能であるといえ、そのような機能をソフトウェア(アプリケーション)として実装する際、そのソフトウェア(アプリケーション)をコンピュータ・プラットフォーム上に常駐させることも、当業者であれば容易に想到し得たことである(このことは、原審の拒絶査定において示された特開2004-5213号公報の段落【0023】にも、使用権調停プログラムが常駐されることが記載されているという事実によっても裏付けられる。)。 したがって、引用発明におけるアービタ(リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部、要求ソフトウェア優先度取得部)の機能を、コンピュータ・プラットフォーム上に常駐するアプリケーションとして実装することも、当業者であれば容易に想到し得たものである。 (2)本願発明の効果について 本願発明の構成によってもたらされる効果は、引用発明から容易に想到し得た構成のものが奏するであろうと当業者が予測する範囲内のものであり、本願発明の進歩性を肯定する根拠となり得るようなものではない。 5.小括 以上のとおり、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 第4 むすび 以上のとおり、本件補正は、特許法第17条の2第3項の要件を満たさないものである。 また、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものであるから、同法第29条第2項の規定により特許を受けることができない。 したがって、本願は、他の拒絶の理由について検討するまでもなく、同法第49条第1号ないし同条第2号の規定により拒絶されるべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2015-10-09 |
| 結審通知日 | 2015-10-13 |
| 審決日 | 2015-10-26 |
| 出願番号 | 特願2011-512507(P2011-512507) |
| 審決分類 |
P
1
8・
121-
WZ
(G06F)
P 1 8・ 55- WZ (G06F) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 中田 剛史 |
| 特許庁審判長 |
小曳 満昭 |
| 特許庁審判官 |
千葉 輝久 玉木 宏治 |
| 発明の名称 | ユーザ・インターフェースの前景アクセスの決定論的制御を行う無線通信デバイス |
| 代理人 | 蔵田 昌俊 |
| 代理人 | 井上 正 |
| 代理人 | 峰 隆司 |
| 代理人 | 佐藤 立志 |
| 代理人 | 岡田 貴志 |
| 代理人 | 砂川 克 |
| 代理人 | 堀内 美保子 |
| 代理人 | 井関 守三 |
| 代理人 | 河野 直樹 |
| 代理人 | 福原 淑弘 |
| 代理人 | 野河 信久 |