【事件の表示】
　特願２０１１−５１２５０７「ユーザ・インターフェースの前景アクセスの決定論的制御を行う無線通信デバイス」拒絶査定不服審判事件〔平成２１年１２月１０日国際公開、ＷＯ２００９／１４８７７６、平成２３年　９月２９日国内公表、特表２０１１−５２６０１２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２００９年５月１２日（パリ条約による優先権主張外国庁受理２００８年６月５日、米国）を国際出願日とする出願であって、平成２４年１０月５日付けで拒絶理由通知がなされ、平成２５年３月１８日付けで手続補正がなされ、同年９月２６日付けで拒絶理由通知がなされ、平成２６年５月１３日付けで拒絶査定がなされ、これに対し、平成２６年９月１９日に拒絶査定不服審判の請求がなされると同時に手続補正がなされ、平成２７年７月２３日付けで拒絶理由通知がなされ、同年９月９日に手続補正がなされたものである。（以下、平成２７年９月９日付けの手続補正を「本件補正」という。）
第２　本件補正について
１．当審が通知した拒絶理由通知
　平成２７年７月２３日付けで当審が通知した拒絶理由のうち、特許法第１７条の２第３項に規定する要件を満たしていないことを理由とするものは、次のとおりである。
「［Ａ］　平成２６年９月１９日付けでした手続補正は、下記の点で願書に最初に添付した明細書、特許請求の範囲又は図面（以下、「当初明細書等」という。）に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
 　　　　　　　　　　　　　　　　　記 
　請求項１には「該複数の常駐アプリケーションに含まれる優先度データと所定の基準に基づいて決定するように構成されたアービタ」と記載されているが、当初明細書等には、アービタが複数の常駐アプリケーションに含まれる優先度データに基づいて決定することは記載されていない（請求人は審判請求書で補正の根拠として段落【０００７】を挙げているが、当該段落には、「１つの実施形態において、該無線通信デバイスの該コンピュータ・プラットフォーム上の該複数の常駐アプリケーションのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する方法であって、・・・（略）・・・、該方法は、該無線通信デバイスの該ディスプレイ上に該ユーザ・インターフェースを表示し、ここで、該ディスプレイは、該コンピュータ・プラットフォーム上に常駐する１またはそれより多くのアプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成され、その後、該ディスプレイを制御せよというリクエストを該複数の常駐アプリケーションのうちの１またはそれより多くのものからアービタにおいて受信し、該アービタは該コンピュータ・プラットフォーム上に常駐し、及び該１またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを
所定の基準に基づいて該アービタで決定し
あるいは
該１またはそれより多くの常駐アプリケーションは
決定する
・・・（略）・・・
　請求項２６には「アービタが、該複数の常駐アプリケーションのうちのいずれのアプリケーションが、各呼び出されたアプリケション内の該優先度データに基づいて該ディスプレイを制御するかを決定する」と記載されているが、当初明細書等には、アービタが優先度データに基づいて決定することは記載されていない。
・・・（略）・・・
　よって、請求項１〜２９に記載した事項は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内にない。」
２．当審の判断
　当審は、本件補正は、当初明細書等に記載した事項の範囲内においてされたものでなく、特許法第１７条の２第３項に規定する要件を満たしていないことを理由とする拒絶理由は、解消していないと判断する。
　理由は次のとおりである。
　本件補正後の特許請求の範囲の請求項２６の記載は、以下の＜本件補正後の請求項２６＞の欄に転記するとおりであるが、そのうちの下線を施した「(f5)該コンピュータ・プラットフオーム上に常駐するアービタが、該複数の常駐アプリケーションのうちのいずれのアプリケーションが、各呼び出されたアプリケーション内の該優先度データに基づいて該ディスプレイを制御するかを決定すること」という発明特定事項は、本願の出願当初の明細書、特許請求の範囲又は図面（以下「当初明細書等」という。）等の全ての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項に該当するものといわざるを得ず、このことは、本件補正が当初明細書等に記載した事項の範囲内でされたものでないことを意味し、上記平成２７年７月２３日付けで当審が通知した拒絶理由であって、特許法第１７条の２第３項に規定する要件を満たしていないことを理由とする拒絶理由が解消していないことを意味する。
＜本件補正後の請求項２６＞
「　　【請求項２６】
　(f1)下記を具備する、無線通信デバイスのコンピュータ・プラットフォーム上の常駐アプリケーションのいずれのユーザ・インターフェースがそのディスプレイを制御するかを決定する方法、
　(f2)該ユーザ・インターフェースは、少なくとも、該無線通信デバイスの該ディスプレイ上に現れ、それを通じて該無線通信デバイスのユーザが該コンピュータ・プラットフォームと対話する、
　(f3)該無線通信デバイスの該ディスプレイ上に該ユーザ・インターフェースを表示すること、該ディスプレイは該コンピュータ・プラットフォーム上に常駐しておりその上で選択され呼び出される複数の常駐アプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成され、該複数の常駐アプリケーションの各々は、該アプリケーションが該ディスプレイを制御する優先度を決定する優先度データを含む、
　(f4)事象を該複数の常駐アプリケーションのうちの複数のものに通知すること、
　
(f5)該コンピュータ・プラットフオーム上に常駐するアービタが、該複数の常駐アプリケーションのうちのいずれのアプリケーションが、各呼び出されたアプリケーション内の該優先度データに基づいて該ディスプレイを制御するかを決定すること
　審判請求人は、この点につき、平成２７年９月９日付けの意見書において、次のとおり主張している。
「本願明細書の段落［０００６］に、「・・・該コンピュータ・プラットフォーム上に常駐するアービタ・アプリケーション・・・」と説明されているように、常駐するアービタは、常駐するアービタ・アプリケーションとも表現されています。
　本願明細書の段落［０００７］には、下記記載があります。
　「・・・該アービタは該コンピュータ・プラットフォーム上に常駐し、・・・あるいは該１またはそれより多くの常駐アプリケーションが、該ディスプレイの制御の優先度を示す優先度データを含む場合、
該１またはそれより多くの常駐アプリケーション
　上記記載の下線を付記した「
該１またはそれより多くの常駐アプリケーション」
従って、該段落［０００７］の記載に基づいても、平成２６年９月１９日付けの補正で、請求項１などに追加した「該複数の常駐アプリケーションに含まれる優先度データ」は、新規事項ではありません。」
　そこで、審判請求人の主張について検討するに、出願当初の明細書の段落【０００６】及び段落【０００７】には、次のとおり記載されている。
「【０００６】
　簡単に述べると、
ローカルのコンピュータ・プラットフォーム上に常駐する１またはそれより多くのアプリケーションを有し
各アプリケーションは、それがユーザと対話するために使用するユーザ・インターフェースを有する。該コンピュータ・プラットフォーム上に常駐するアービタ・アプリケーションは、
所定の基準に基づいて、いずれのアプリケーションがそのユーザ・インターフェースを該前景にもっていく(bring)ことができるかを制御する。
　【０００７】
　・・・（略）・・・該方法は、該無線通信デバイスの該ディスプレイ上に該ユーザ・インターフェースを表示し、ここで、
該ディスプレイは、該コンピュータ・プラットフォーム上に常駐する１またはそれより多くのアプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成され
該ディスプレイを制御せよというリクエストを該複数の常駐アプリケーションのうちの１またはそれより多くのものからアービタにおいて受信し、該アービタは該コンピュータ・プラットフォーム上に常駐し、及び該１またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを所定の基準に基づいて該アービタで決定し
あるいは該１またはそれより多くの常駐アプリケーションが、該ディスプレイの制御の優先度を示す優先度データを含む場合、該１またはそれより多くの常駐アプリケーションは、いずれのアプリケーションの１つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する
　出願当初の明細書の段落【０００６】の「ローカルのコンピュータ・プラットフォーム上に常駐する１またはそれより多くのアプリケーションを有し、・・・（略）・・・各アプリケーションは、それがユーザと対話するために使用するユーザ・インターフェースを有する。」及び同段落【０００７】の「該ディスプレイは、該コンピュータ・プラットフォーム上に常駐する１またはそれより多くのアプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成され」という記載から、本願における「１またはそれより多くのアプリケーション」は、ユーザ・インタフェースを有し、ディスプレイを選択的に制御するものと認められる。
　一方、同段落【０００６】の「アービタ・アプリケーションは、・・・（略）・・・、所定の基準に基づいて、いずれのアプリケーションがそのユーザ・インターフェースを該前景にもっていく(bring)ことができるかを制御する。」及び同段落【０００７】の「該ディスプレイを制御せよというリクエストを該複数の常駐アプリケーションのうちの１またはそれより多くのものからアービタにおいて受信し・・・（略）・・・該１またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを所定の基準に基づいて該アービタで決定し、」という記載から、本願におけるアービタ・アプリケーションは、１またはそれより多くのアプリケーションからディスプレイを制御せよというリクエストを受信し、所定の基準に基づいて、いずれのアプリケーションがそのユーザ・インターフェースを前景にもっていく(bring)ことができるかを制御するものと認められる。
　ここで、当初明細書等には、アービタ・アプリケーションがユーザ・インタフェースを有すること及びディスプレイを選択的に制御することは記載されておらず、また、このことは、当業者に自明な事項であるとも認められない。
　したがって、出願当初の明細書の段落【０００６】及び段落【０００７】の上記記載等から、１またはそれより多くのアプリケーションとアービタ・アプリケーションとは異なる機能のアプリケーションであると認められる。
　また、同段落【０００７】の「あるいは」という記載より前には、「該ディスプレイを制御せよというリクエストを該複数の常駐アプリケーションのうちの１またはそれより多くのものからアービタにおいて受信し、該アービタは該コンピュータ・プラットフォーム上に常駐し、及び該１またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを所定の基準に基づいて該アービタで決定し、」と記載されており、「あるいは」という記載より後には、「該１またはそれより多くの常駐アプリケーションが、該ディスプレイの制御の優先度を示す優先度データを含む場合、該１またはそれより多くの常駐アプリケーションは、いずれのアプリケーションの１つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する」と記載されている。
　ここで、「あるいは」という、複数の異なるもののうち一つを選択するときに用いる接続詞が用いられていることから、当該接続詞の前に記載されている、「ディスプレイを制御せよというリクエストを複数の常駐アプリケーションのうちの１またはそれより多くのものからアービタにおいて受信し、該アービタは該コンピュータ・プラットフォーム上に常駐し、及び該１またはそれより多くの常駐アプリケーションの該複数のユーザ・インターフェースのうちのいずれのアプリケーションが該ユーザ・インターフェースを制御するかを所定の基準に基づいて該アービタで決定し、」という実施態様と、当該接続詞の後に記載されている、「該１またはそれより多くの常駐アプリケーションが、該ディスプレイの制御の優先度を示す優先度データを含む場合、いずれのアプリケーションの１つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する」という実施態様とは、別異の実施態様と認められる。
　したがって、「あるいは」という記載より前に記載されている「該アービタは該コンピュータ・プラットフォーム上に常駐し」という記載及び「あるいは」という記載より後に記載されている「１またはそれより多くの常駐アプリケーションは、・・・（略）・・・いずれのアプリケーションの１つのいずれのユーザ・インターフェースが該ディスプレイを制御するかを決定する」という記載をもって、「１またはそれより多くの常駐アプリケーション」がアービタ・アプリケーションであると認めることはできない。
　そして、１またはそれより多くの常駐アプリケーションがディスプレイの制御の優先度を示す優先度データを含む場合に、
アービタ
　したがって、審判請求人の主張は採用することができない。
３．小括
　以上のとおり、本件補正は、特許法第１７条の２第３項の要件を満たさないものである。
第３　本願発明について
１．本願発明
　本願請求項２２に係る発明（以下「本願発明」という。）は、平成２７年９月９日付け手続補正書の請求項２２に記載された、以下のとおりのものである。
「(d1)下記を具備する、無線通信デバイス、
　(d2)該無線通信デバイスのユーザにユーザ・インターフェースを表示するための手段、
　(d3)該表示するための手段は該無線通信デバイス上に常駐する複数の常駐アプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成される、
　(d4)コンピュータのプラットフォーム上に常駐する該複数の常駐アプリケーションのうちのいずれのユーザ・インターフェースが該表示するための手段を制御するかを所定の基準に基づいて決定するように構成された、該コンピュータ・プラットフォーム上に常駐するアービタ。」
２．引用発明
　平成２７年７月２３日付けの当審の拒絶の理由で引用された特開２００４−７８９３６号公報（以下「引用例」という。）には、次の記載がある。
「【００１５】
　以上のように本発明によれば、リソースアクセス部により優先度に基づきリソースのアクセス制御を行うことで、個々のソフトウェア作成時に、特定のソフトウェア（例えば携帯電話の場合には電話機能）を優先することを考慮しなくてよくなり、ソフトウェア作成者の負担が減少し、ソフトウェアの構成もより単純になる。また、特定の機能（例えば電話機能）を優先するという特別なルールが不要になるため、サードパーティがソフトウェアを作成する敷居が低くなり、より多くのソフトウェアが作成されることが期待される。また、各ソフトウェアの優先度を任意に設定しなおしたい場合には、テーブル等で規定されたルールを変更するだけでよく、ソフトウェアの再利用性が向上する。さらに、リソース部１６のプログラムとしては、本発明の競合解決の枠組みに合う関数を作成してリソースアクセス部１１に登録するだけでよく、リソース部１６の再利用性が高まる。
・・・（略）・・・
【００１７】
　（第１の実施形態）
　図１に、本発明の第１の実施形態に係る情報処理端末の構成を示す。図１において、情報処理端末は、リソースアクセス部１１と、使用状態判定部１２と、競合判定部１３と、使用中ソフトウェア優先度管理部１４と、要求ソフトウェア優先度取得部１５と、リソース部１６と、実行部１７とから構成される。
【００１８】
　リソース部１６は、携帯端末などにおけるデバイスであって、例えばスピーカや液晶ディスプレイなどである。実行部１７はプログラムであって、より具体的には、アプリケーション、あるいはアプリケーションにくみ込み可能なライブラリやその他のミドルウェア、あるいはドライバである。
【００１９】
　次に、上記構成を有する情報処理端末の動作を、図２のシーケンスチャートを参照して説明する。この図のシーケンスチャートを説明するにあたり、実行部１７はアプリケーションであると仮定する。・・・（略）・・・
【００２０】
　まず、ユーザの操作を契機として、アプリケーションＡよりも優先度が高いアプリケーションＢが、リソース部１６を使用するためにリソースアクセス部１１に対してアクセス要求を行う（Ｓ１）。
【００２１】
　次に、リソースアクセス部１１は、アプリケーションＢの要求を解析し、アプリケーションＢがアクセスしようとしているリソースを認識し、そのリソースを他のアプリケーションが現在使用中かどうか、使用状態判定部１２に対して問い合わせを行う。使用状態判定部１２は、指定されたリソースにアクセスしているアプリケーションがあるかどうかを判定し、リソースアクセス部１１にこの判定結果を返す（Ｓ２）。リソースアクセス部１１はこの判定結果を受けて、リソースを現在使用中のアプリケーションがなければ（Ｓ２でＮＯ）、アプリケーションＢが要求したコマンドをリソース部１６に伝える（Ｓ８）。このとき、予めリソースアクセス部１１に登録しておいた関数が使用される。
【００２２】
　ステップＳ２で、リソースを現在使用中のアプリケーション（アプリケーションＡ）があると判定された場合は（Ｓ２でＹＥＳ）、リソースアクセス部１１は競合を解決するために競合判定部１３にアプリケーションＢの情報を渡し、判定を要求する。競合判定部１３は、まず現在使用中のアプリケーションＡの優先度を使用中ソフトウェア優先度管理部１４に問い合わせ、アプリケーションＡのリソースに対する優先度を得る（Ｓ３）。なお、使用中ソフトウェア優先度管理部１４は、あるアプリケーションがあるリソースを使用したときに、例えば図３に示すような優先度管理テーブルを参照してこのアプリケーションの優先度を取得し、管理する。
【００２３】
　次に、競合判定部１３は、要求ソフトウェア優先度取得部１５に問い合わせて、アプリケーションＢのリソースに対する優先度を得る（Ｓ４）。なお、要求ソフトウェア優先度取得部１５は、例えば図３に示すような優先度管理テーブルを参照して、アプリケーションＢの優先度を取得する。このテーブルにおいて、アプリケーションの種類としては、例えば、図３に示すようにアプリケーションの名前を使用してもよいし、アプリケーション毎に振られるアプリケーションＩＤを使用してもよいし、アプリケーションをグループ化した場合にアプリケーショングループ毎に振られるアプリケーショングループＩＤを使用してもよいし、アプリケーションを実行しているプロセスやスレッドのＩＤを使用してもよい。このようにテーブルで優先度を管理することで、簡単に優先度の設定を変更ができ、将来優先度が変更した場合にもアプリケーションを変更しなくてもよい。
【００２４】
　そして、競合判定部１３は、使用中ソフトウェア優先度管理部１４から得られたアプリケーションＡの優先度と、要求ソフトウェア優先度取得部１５から得られたアプリケーションＢの優先度とを比較し、その比較結果をリソースアクセス部１１に返す。（ステップＳ５）。
【００２５】
　リソースアクセス部１１は、競合判定部１３の比較結果を基に、アプリケーションＢの優先度がアプリケーションＡよりも低ければ、リソースへのアクセスを拒否すべくアプリケーションＢに対してアクセスエラーを返す（Ｓ６）。一方、アプリケーションＢの優先度がアプリケーションＡよりも高ければ、予め登録されている関数をコールすることによってリソース部１６に対してアプリケーションＡの処理をキャンセルするよう要求する（Ｓ７）。例えばアプリケーションＡがスピーカから音楽を出力させていた場合には、スピーカに音楽の出力を中止させる。つづいてアプリケーションＢの要求にしたがってリソースにアクセスする（Ｓ８）。このときリソースアクセス部１１は、リソース競合が発生してリソースが奪われたことをアプリケーションＡに対してエラーとして通知する。同時にどのアプリケーションとリソースの競合が発生しているのか通知することも可能である。
・・・（略）・・・
【００２８】
　なお、本実施形態では、実行部１７がアプリケーションであると仮定したが、実行部１７はアプリケーションに限らず、単にアプリケーションから要求を受けたミドルウェアや、ドライバなどのソフトウェアであってもよい。
【００２９】
　また本実施形態では、使用中ソフトウェア優先度管理部１４および要求ソフトウェア優先度取得部１５は、図３に示すような単にアプリケーション毎に優先度が設定されているような優先度管理テーブルに基づいて優先度を取得するとしたが、本発明はこれに限らない。例えば、図４に示すように、アプリケーションの種類とリソースの種類との組み合わせ毎に優先度が設定されているような優先度管理テーブルに基づいて優先度を取得してもよい。
・・・（略）・・・
【００３１】
　また、リソースの一例としてスピーカをあげたが、リソースはスピーカに限らず、例えばＬＥＤやディスプレイであってもよいし、さらには具体的なデバイスに限らず、通信コネクションのような抽象的なリソースであってもよい。
・・・（略）・・・」
　ここで、上記記載を関連図面及び本願優先日前からの技術常識に照らせば、以下のことがいえる。
（１）段落【００１７】、【００１８】等の記載から明らかなように、引用例の情報処理端末には、リソースとして液晶ディスプレイを備えた携帯端末が含まれるものである。
（２）ブラウザ、メール、電話等のアプリケーションのユーザ・インタフェースがディスプレイに表示されることは、本願優先日前から技術常識であり、段落【００２３】、【００２９】等の記載及び図３に示されている「ブラウザ」「メール」「電話」といったアプリケーション名並びに上記技術常識から、引用例のアプリケーションは、液晶ディスプレイに表示されるユーザ・インタフェースを有し、該ユーザ・インタフェースによって液晶ディスプレイの表示を制御するものである。
（３）段落【００１９】から【００２６】まで、【００２９】等の記載及び図３の記載から、引用例の情報処理端末は、アプリケーションがリソースを使用しようとした場合に、リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部、要求ソフトウェア優先度取得部が、アプリケーション毎に設定された優先度に基づいて、リソースを使用するアプリケーションを判定するものである。
　そして、リソースは、複数のアプリケーションのうち、上記判定によって選択されたアプリケーションによって選択的に制御されるものである。
　したがって、引用例には次の発明（以下「引用発明」という。）が記載されているといえる。
「(d1)下記を具備する携帯端末、
　(d2)該携帯端末のユーザに、アプリケーションのユーザ・インタフェースを表示するための液晶ディスプレイ、
　(d3)該液晶ディスプレイは複数のアプリケーションの該ユーザ・インタフェースにより選択的に制御されるように構成される、
　(d4)該複数のアプリケーションのうちのいずれのユーザ・インタフェースが該液晶ディスプレイを制御するかをアプリケーション毎に設定された優先度に基づいて決定する、リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部及び要求ソフトウェア優先度取得部。」
３．対比
　本願発明と引用発明とを対比すると、次のことがいえる。
（１）引用発明でいう「携帯端末」「液晶ディスプレイ」はそれぞれ、本願発明でいう「無線通信デバイス」「表示するための手段」に相当する。
（２）引用発明でいう「アプリケーション毎に設定された優先度」は、本願発明でいう「所定の基準」に相当する。
（３）引用発明でいう「リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部及び要求ソフトウェア優先度取得部」は、アプリケーション毎に設定された優先度に基づいて、液晶ディスプレイを使用するアプリケーションを判定するものであるから、本願発明でいう「アービタ」に相当する。
　したがって、本願発明と引用発明との間には、次の一致点、相違点があるといえる。
（一致点）
「(d1)下記を具備する、無線通信デバイス、
　(d2)該無線通信デバイスのユーザにユーザ・インターフェースを表示するための手段、
　(d3)該表示するための手段は複数のアプリケーションの該ユーザ・インターフェースにより選択的に制御されるように構成される、
　(d4)該複数のアプリケーションのうちのいずれのユーザ・インターフェースが該表示するための手段を制御するかを、所定の基準に基づいて決定するように構成された、アービタ。」
（相違点）
　本願発明では、「複数のアプリケーション」が「無線通信デバイス上に常駐する複数の常駐アプリケーション」及び「コンピュータのプラットフォーム上に常駐する複数の常駐アプリケーション」とされ、「アービタ」が「コンピュータ・プラットフォーム上に常駐するアービタ」とされるのに対し、引用発明では、「複数のアプリケーション」及び「アービタ」が常駐とはされていない点
４．判断
（１）上記相違点について
　一般に、常時使用されるアプリケーションを、コンピュータ・プラットフォーム上に常駐させることは、当業者に慣用される事項である。
　一方、引用例の図３等から明らかなように引用発明の複数のアプリケーションとしては、メールアプリケーションや電話アプリケーションが想定されており、それらのメールアプリケーション及び電話アプリケーションは、メール及び電話の受信、着信等の事象の有無を確認するために、引用発明の携帯端末において常時使用されるのが普通である。
　以上を踏まえると、引用発明において複数のアプリケーションをコンピュータ・プラットフォーム上及び無線通信デバイス上に常駐させることは、当業者であれば容易に想到し得たことである。
　また、コンピュータに特定の機能を実装する場合に、ソフトウェア（アプリケーション）として実装すること及びハードウェアとして実装することは、いずれも当業者に慣用される事項であり、いずれによって実装するかは、製造コスト等の事情に応じて決定され得るものであるから、引用発明のアービタ（リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部及び要求ソフトウェア優先度取得部）の機能をソフトウェア（アプリケーション）として実装することも、当業者であれば容易に想到し得たことである。
　そして、引用発明の上記アービタ（リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部及び要求ソフトウェア優先度取得部）は、どのアプリケーションのユーザ・インタフェースをディスプレイに表示させるかを判定するために、アプリケーションの起動等の事象の有無を確認するものであり、その機能は、常時使用される機能であるといえ、そのような機能をソフトウェア（アプリケーション）として実装する際、そのソフトウェア（アプリケーション）をコンピュータ・プラットフォーム上に常駐させることも、当業者であれば容易に想到し得たことである（このことは、原審の拒絶査定において示された特開２００４−５２１３号公報の段落【００２３】にも、使用権調停プログラムが常駐されることが記載されているという事実によっても裏付けられる。）。
　したがって、引用発明におけるアービタ（リソースアクセス部、使用状態判定部、競合判定部、使用中ソフトウェア優先度管理部、要求ソフトウェア優先度取得部）の機能を、コンピュータ・プラットフォーム上に常駐するアプリケーションとして実装することも、当業者であれば容易に想到し得たものである。
（２）本願発明の効果について
　本願発明の構成によってもたらされる効果は、引用発明から容易に想到し得た構成のものが奏するであろうと当業者が予測する範囲内のものであり、本願発明の進歩性を肯定する根拠となり得るようなものではない。
５．小括
　以上のとおり、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
第４　むすび
　以上のとおり、本件補正は、特許法第１７条の２第３項の要件を満たさないものである。
　また、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものであるから、同法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の拒絶の理由について検討するまでもなく、同法第４９条第１号ないし同条第２号の規定により拒絶されるべきものである。
　よって、結論のとおり審決する。