2016-008827

特願２０１４－５０９２７９「デバイス機能へのアプリケーションの結び付け」拒絶査定不服審判事件〔平成２４年１１月　８日国際公開、ＷＯ２０１２／１５０９５５、平成２６年　７月１７日国内公表、特表２０１４－５１７３８３、請求項の数（１０）〕について、次のとおり審決する。

【結　論】 原査定を取り消す。 本願の発明は、特許すべきものとする。

【理　由】 第１　手続の経緯 本件審判請求に係る出願（以下，「本願」という。）は，２０１１年１０月１０日（パリ条約による優先権主張外国庁受理２０１１年５月２日（以下，「優先日」という。），米国）を国際出願日とする出願であって，その手続の経緯は以下のとおりである。 平成２５年１０月２３日　　　：国内書面の提出 平成２６年　９月２５日　　　：出願審査請求書，手続補正書の提出 平成２７年　９月１０日付け　：拒絶理由の通知 平成２７年１２月１４日　　　：意見書，手続補正書の提出 平成２８年　３月　９日付け　：拒絶査定 平成２８年　６月１４日　　　：審判請求書，手続補正書の提出 平成２８年　７月１４日　　　：前置報告 第２　平成２８年６月１４日付けの手続補正の適否 １　補正の内容 平成２８年６月１４日付けの手続補正（以下，「本件補正」という。）は，特許請求の範囲の請求項１を， 「　コンピュータデバイスのオペレーティングシステムにおける方法であって， 前記コンピュータデバイスにインストールされているハードウェアデバイスの複数の機能のうちの第１の機能にアクセスするリクエストをアプリケーションから受け取るステップと， 前記オペレーティングシステムによって，前記アプリケーションが前記ハードウェアデバイスの前記第１の機能にアクセスすることを許可されているとデバイス許可記録において特定されるかどうかを確認するステップと， 前記アプリケーションが前記ハードウェアデバイスの前記第１の機能にアクセスすることを許可されていると前記デバイス許可記録が示す場合は，前記アプリケーションが前記ハードウェアデバイスの前記第１の機能にアクセスすることを可能にし，前記アプリケーションが前記ハードウェアデバイスの前記第１の機能にアクセスすることを許可されていると前記デバイス許可記録が示さない場合は，前記リクエストを拒絶するステップと を有し， 前記デバイス許可記録は，前記オペレーティングシステムの一部分として含まれており，前記複数の機能の夫々について機能識別子を保持し，異なる承諾タイプが異なる機能識別子と関連付けられ，夫々の機能識別子は，前記ハードウェアデバイスの機能群に対応し，夫々の機能識別子について，当該機能識別子と関連付けられている承諾タイプは，もしあれば，前記アプリケーションが前記機能群にアクセスするために必要とされる承諾のタイプを示す，方法。」 （当審注：下線は，請求人が付与したものである。以下，この特許請求の範囲に記載された請求項を「補正後の請求項１」という。） とする補正（以下，「補正事項１」という。）を含んでいる。 ２　補正の適否 本件補正の補正事項１は，補正前の請求項１に記載した発明を特定するために必要な事項である「ハードウェアデバイスの機能」について， 「複数の機能のうちの第１の」または「前記第１の」との限定を加えるものであって， また，補正前の請求項１に記載した発明を特定するために必要な事項である「デバイス許可記録」について， 「前記デバイス許可記録は，前記オペレーティングシステムの一部分として含まれており，前記複数の機能の夫々について機能識別子を保持し，異なる承諾タイプが異なる機能識別子と関連付けられ，夫々の機能識別子は，前記ハードウェアデバイスの機能群に対応し，夫々の機能識別子について，当該機能識別子と関連付けられている承諾タイプは，もしあれば，前記アプリケーションが前記機能群にアクセスするために必要とされる承諾のタイプを示す，」との限定を加えるものである。 補正前の請求項１に記載された発明と補正後の請求項１に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから，特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。 加えて，特許法第１７条の２第３項，第４項に違反するところはない。 そこで，補正事項１は特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものを含むことから，補正後の前記請求項１に記載された発明（以下，「本件補正発明」という。）が特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について以下に検討する。 （１）引用例 （１－１）引用例１に記載される技術的事項および引用発明 ア　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である平成２７年９月１０日付けの拒絶理由通知において引用された，特開２００８－３０５３３６号公報（平成２０年１２月１８日出願公開，以下，「引用例１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ａ　「【００３０】 図３は，本実施形態のホームゲートウェイ装置１が行うアクセスコントロール処理を説明するための説明図である。 【００３１】 デバイスドライバ１０３は，service.pidを指定してデバイスインスタンス１０４のインスタンスを生成する。そして，デバイスドライバ１０３は，インスタンス生成時にOSGi Frameworkに指定したservice.pidと，当該インスタンスを利用可能な所定のアプリケーション１０７の識別子とを，割当情報サービス１０６を介して割当管理１０５に登録（格納）する（Ｓ１）。なお，当該インスタンスを利用可能なアプリケーション１０７は，ユーザが指定することなどにより，あらかじめ定められているものとする。 【００３２】 OSGi Frameworkを用いる場合には，アプリケーション１０７の識別子として，BundleLOCATIONなどを用いることが可能である。また，これ以外に，電子署名を用いることも可能である。 【００３３】 割当管理１０５は，デバイスドライバ１０３により割当情報が登録されると，当該割当情報に基づいてパーミッション（Permission）１２１を生成し，当該パーミッション１２１をJava（登録商標）VMに登録する（Ｓ２）。 【００３４】 OSGi Frameworkを用いる場合の具体的な登録方法としては，割当管理１０５は，割当情報に設定されたアプリケーション１０７のBundleLOCATIONと，デバイスインスタンス１０４のservice.pidとが対になったパーミッション１２１を生成する。そして，割当管理１０５は，生成したパーミッション１２１をOSGi Frameworkの図示しないパーミッションアドミン（Permission Admin）を用いて，Java（登録商標）VMのポリシー１１３（記憶部）に登録する。 【００３５】 このようにして，Java（登録商標）VMにパーミッション１２１が登録される。」 Ｂ　「【００３６】 次に，アプリケーション１０７は，ユーザの指示を受け付けて，対象となる物理デバイス２に対応するデバイスインスタンス１０４を呼び出す（Ｓ３）。アプリケーション１０７は，デバイスインスタンス１０４を呼び出す際に，Java（登録商標）VMの機能により自身の識別子がデバイスインスタンス１０４に通知される。 【００３７】 なお，ユーザは，図示しない表示装置に表示されたＧＵＩ（Graphical User Interface）を操作することなどにより，アプリケーション１０７に対する指示を入力する。 【００３８】 アプリケーション１０７から呼び出されたデバイスインスタンス１０４は，処理を開始する前に，Java（登録商標）VMの機能であるアクセスコントローラ（AccessController）１１１に，パーミッションのチェックを要求する（Ｓ４）。すなわち，デバイスインスタンス１０４は，自身に設定されたservice.pidと，アプリケーション１０７の識別子とを含むチェック要求１２２を，アクセスコントローラ１１１に送出する。」 Ｃ　「【００３９】 アクセスコントローラ１１１は，Java（登録商標）VMの機能を用いて，要求元のデバイスインスタンス１０４を呼び出したアプリケーション１０７が，当該デバイスインスタンス１０４にアクセスする権利があるか否かのパーミッションチェックを行い，チェック結果を返す。 【００４０】 すなわち，アクセスコントローラ１１１は，ポリシー１１３の中にチェック要求１２２に含まれるデバイスインスタンス１０４のservice.pidおよびアプリケーション１０７の識別子のパーミッションが存在する場合は，呼出元のアプリケーション１０７はアクセスする権利があると判別する。一方，ポリシー１１３に存在しない場合は，呼出元のアプリケーション１０７はアクセスする権利がないと判別する。 【００４１】 要求元のデバイスインスタンス１０４は，アクセスコントローラからチェック結果を取得する。呼出元のアプリケーション１０７がアクセス権を有する（パーミッションが与えられている）チェック結果の場合，デバイスインスタンス１０４は，物理デバイス２に対して所定の処理を行う。一方，呼出元のアプリケーション１０７がアクセス権を有しない（パーミッションが与えられていない）チェック結果の場合，デバイスインスタンス１０４は，処理を中断し，エラーを呼出元のアプリケーション１０７に返す。 【００４２】 以上説明した本実施形態のホームゲートウェイ装置１では，インスタンスの生成時に，当該インスタンスを一意に識別可能な識別情報（service.pid）を付与するとともに，当該識別情報とアクセスを許可するアプリケーションとを対応付けたパーミッションを登録する。そして，アプリケーションからインスタンスが呼び出されたときに，インスタンスの識別情報を用いてパーミッションのチェックを行い，アクセスが許可されているアプリケーションから場合にのみ処理を実行する。これにより，本実施形態では，インスタンス単位でのアクセスコントロールを行うことができる。すなわち，各インスタンスを，特定のアプリケーションからのみアクセスさせることができる。」 イ　ここで，引用例１に記載されている事項を検討する。 （ア）上記Ａの段落【００３０】の「図３は，本実施形態のホームゲートウェイ装置１が行うアクセスコントロール処理を説明するための説明図である。」との記載からすると，引用例１には， “ホームゲートウェイ装置が行うアクセスコントロール処理方法” が記載されていると解される。 （イ）上記Ａの段落【００３３】の「割当管理１０５は，デバイスドライバ１０３により割当情報が登録されると，当該割当情報に基づいてパーミッション（Permission）１２１を生成し，当該パーミッション１２１をJava（登録商標）VMに登録する（Ｓ２）。」との記載，段落【００３４】の「そして，割当管理１０５は，生成したパーミッション１２１をOSGi Frameworkの図示しないパーミッションアドミン（Permission Admin）を用いて，Java（登録商標）VMのポリシー１１３（記憶部）に登録する。」との記載からすると，「割当管理」は「パーミッション」を「JavaVM」の「ポリシー（記憶部）」に登録することが読み取れるから，引用例１には， “割当管理は，デバイスドライバにより割当情報が登録されると，割当情報に基づいてパーミッションを生成し，JavaVMのポリシー（記憶部）に登録”すること が記載されていると解される。 （ウ）上記Ｂの段落【００３６】の「次に，アプリケーション１０７は，ユーザの指示を受け付けて，対象となる物理デバイス２に対応するデバイスインスタンス１０４を呼び出す（Ｓ３）。アプリケーション１０７は，デバイスインスタンス１０４を呼び出す際に，Java（登録商標）VMの機能により自身の識別子がデバイスインスタンス１０４に通知される。」との記載，上記Ｂの段落【００３８】の「アプリケーション１０７から呼び出されたデバイスインスタンス１０４は，処理を開始する前に，Java（登録商標）VMの機能であるアクセスコントローラ（AccessController）１１１に，パーミッションのチェックを要求する（Ｓ４）。」との記載からすると，「アプリケーション」は，自身の「識別子」を通知して，「デバイスインスタンス」を呼び出すことが読み取れるから，引用例１には， “アプリケーションは，ユーザの指示を受け付けて，自身の識別子を通知して，対象となる物理デバイスに対応するデバイスインスタンスを呼び出し， デバイスインスタンスは，処理を開始する前に，JavaVMの機能であるアクセスコントローラに，パーミッションのチェックを要求”すること が記載されていると解される。 （エ）上記Ｃの段落【００３９】の「アクセスコントローラ１１１は，Java（登録商標）VMの機能を用いて，要求元のデバイスインスタンス１０４を呼び出したアプリケーション１０７が，当該デバイスインスタンス１０４にアクセスする権利があるか否かのパーミッションチェックを行い，チェック結果を返す。」との記載，段落【００４０】の「すなわち，アクセスコントローラ１１１は，ポリシー１１３の中にチェック要求１２２に含まれるデバイスインスタンス１０４のservice.pidおよびアプリケーション１０７の識別子のパーミッションが存在する場合は，呼出元のアプリケーション１０７はアクセスする権利があると判別する。一方，ポリシー１１３に存在しない場合は，呼出元のアプリケーション１０７はアクセスする権利がないと判別する。」との記載からすると，「アクセスコントローラ」は，要求元の「デバイスインスタンス」を呼び出した「アプリケーション」の「パーミッションチェック」を行うことが読み取れるから，引用例１には， “アクセスコントローラは，要求元のデバイスインスタンスを呼び出したアプリケーションのパーミッションチェックを行い，ポリシーの中にチェック要求に含まれるデバイスインスタンスおよびアプリケーションの識別子のパーミッションが存在する場合は，呼出元のアプリケーションはアクセスする権利があると判別し，ポリシーに存在しない場合は，呼出元のアプリケーションはアクセスする権利がないと判別”すること が記載されていると解される。 （オ）上記Ｃの段落【００４１】の「要求元のデバイスインスタンス１０４は，アクセスコントローラからチェック結果を取得する。呼出元のアプリケーション１０７がアクセス権を有する（パーミッションが与えられている）チェック結果の場合，デバイスインスタンス１０４は，物理デバイス２に対して所定の処理を行う。一方，呼出元のアプリケーション１０７がアクセス権を有しない（パーミッションが与えられていない）チェック結果の場合，デバイスインスタンス１０４は，処理を中断し，エラーを呼出元のアプリケーション１０７に返す。」との記載からすると，要求元の「デバイスインスタンス」は，「アクセスコントローラ」からチェック結果を取得して，チェック結果に応じた処理を行うことが読み取れるから，引用例１には， “要求元のデバイスインスタンスは，アクセスコントローラからチェック結果を取得し，呼出元のアプリケーションがアクセス権を有するチェック結果の場合，デバイスインスタンスは，物理デバイスに対して所定の処理を行い，一方，呼出元のアプリケーションがアクセス権を有しないチェック結果の場合，デバイスインスタンスは，処理を中断し，エラーを呼出元のアプリケーションに返す”こと が記載されていると解される。 ウ　以上，（ア）乃至（オ）で示した事項から，引用例１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。 「ホームゲートウェイ装置が行うアクセスコントロール処理方法であって， 割当管理は，デバイスドライバにより割当情報が登録されると，割当情報に基づいてパーミッションを生成し，JavaVMのポリシー（記憶部）に登録し， アプリケーションは，ユーザの指示を受け付けて，自身の識別子を通知して，対象となる物理デバイスに対応するデバイスインスタンスを呼び出し， 前記デバイスインスタンスは，処理を開始する前に，前記JavaVMの機能であるアクセスコントローラに，パーミッションのチェックを要求し， 前記アクセスコントローラは，要求元の前記デバイスインスタンスを呼び出した前記アプリケーションのパーミッションチェックを行い，前記ポリシーの中にチェック要求に含まれる前記デバイスインスタンスおよび前記アプリケーションの識別子のパーミッションが存在する場合は，呼出元の前記アプリケーションはアクセスする権利があると判別し，前記ポリシーに存在しない場合は，呼出元の前記アプリケーションはアクセスする権利がないと判別し， 要求元の前記デバイスインスタンスは，前記アクセスコントローラからチェック結果を取得し，呼出元の前記アプリケーションがアクセス権を有するチェック結果の場合，前記デバイスインスタンスは，前記物理デバイスに対して所定の処理を行い，一方，呼出元の前記アプリケーションがアクセス権を有しないチェック結果の場合，前記デバイスインスタンスは，処理を中断し，エラーを呼出元の前記アプリケーションに返す，方法。」 （１－２）引用例２に記載される技術的事項 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である平成２７年９月１０日付けの拒絶理由通知において引用された，特開２００４－１９２１００号公報（平成１６年７月８日出願公開，以下，「引用例２」という。）には，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｄ　「【００２６】 図１に示すように，本実施形態のデバイスとしてのネットワークデバイスであるＬＡＮカード１１は，チップセット１２を有している。このチップセット１２には，ＥＥＰＲＯＭなどからなる不揮発性メモリ１３が配設されており，この不揮発性メモリ１３には，ＰＣＩ用設定値が記憶されるＰＣＩ用設定値記憶部１４，ＰＣカード用設定値が記憶されるＰＣカード用設定値記憶部１５，デバイス固有の設定値が記憶される固有情報記憶部１６，ＭＡＣアドレスが記憶されるＭＡＣアドレス記憶部１７，チェックデータ記憶部１８などが設けられている。 【００２７】 前記デバイス固有の設定値は，従来と同様に，例えばデバイスＩＤ，ベンダーＩＤ，サブシステムＩＤ，サブシステムベンダーＩＤなどにより構成されている。なお，デバイス固有の設定値は，ＯＳの種類に応じて設定すればよい。 …（中略）… 【００２９】 前記チェックデータは，不正使用の防止に用いるものであり，前記デバイス固有の設定値を基にしたチェックサム，チェックデジット，チェックビット，シフトなどを単独もしくは組み合わせて暗号化したものを用いることが好ましい。 【００３０】 前記ＰＣカード用設定値記憶部１５とＭＡＣアドレス記憶部１７との２箇所に記憶されているＭＡＣアドレスと，チェックデータ記憶部１８に記憶されているチェックデータの両者により，本実施形態の保護データが形成されている。 【００３１】 なお，保護データとしては，チェックデータと，２箇所に記憶されているＭＡＣアドレスの一方であってもよい。そして，保護データとしてチェックデータを用いると，あらゆるデバイスに用いることができる。さらに，保護データとしてＭＡＣアドレスを用いると，コンピュータネットワークに接続するネットワークデバイスに好適である。また，保護データとしてチェックデータおよびＭＡＣアドレスの両者を用いると保護データを強固なものとすることができる。」 （１－３）引用例３に記載される技術的事項 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，平成２８年３月９日付けの拒絶査定において引用された，特表２００５－５０２１２８号公報（平成１７年１月２０日出願公表，以下，「引用例３」という。）には，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｅ　「【００３０】 図３は，本発明の例示的な実施形態における無線装置の構成要素を示すブロック図である。無線装置３００は制御プログラム３０５，それぞれに許可リスト３２０とデジタル署名３２５が付いたアプリケーション３１０，及びリソース３１５を含む。アプリケーション３１０が様々なタスクを実行してよいことが当業者によって認識されるだろう。さらに，各アプリケーション１１０は，そのアプリケーションと，通常アプリケーションと許可リストごとに一意であるデジタル署名と関連付けられる別個の許可リストを有してよい。３１５に一覧表示されているリソースが多くのデバイスリソースの例であることも当業者によって認識されるだろう。デバイスがアクセスしてよいデバイスの外のリソースを含む，デバイスと関連付けられた多くのリソースがあり，そのアクセスは許可リストに基づきアプリケーションに与えられてよい。 【００３１】 一実施形態では，制御プログラム３０５はリソース３１５へのアクセスを管理するのに役立つためにデバイス上に位置している。制御プログラム３０５の機能は，無線装置のオペレーティングシステムに組み込まれてよいか，あるいはクアルコム社によって開発されたＢＲＥＷ（商標）ＡＰＩなどの別個のＡＰＩであってよい。制御プログラム３０５は，アプリケーションに授けられる特権に基づきアプリケーションへのリソースのアクセスを許可または拒絶してよい。 【００３２】 一実施形態では，これらの特権はアプリケーションに関連付けられた許可リスト３２０を介して決定される。許可リスト３２０はリソース３１５のリスティング，及びアプリケーションがデバイス上の特定のリソース３１５のどれかにアクセスする許可を有しているかどうかの表示を含む。例えば，許可リスト３２０は「マイク」及び「スピーカ」のフィールドを含んでよい。フィールドのそれぞれのフラグの設定が，アプリケーションがマイクにアクセスできるのか，あるいはスピーカにアクセスできるのかを示す。いくつかの例では，マイクフィールドにセットされたフラグは，アプリケーションがマイクにアクセスしてよいことを示している。フラグがセットされておらず，それによってアクセスを拒絶する場合もある。許可リスト内で可能な限り多くのリソースを明らかにさせ，フラグを，アプリケーションが関連リソースにアクセスできるかどうかを示すそれぞれのものと関連させることが好ましい。」 （２）対比 ア　本件補正発明と引用発明とを対比する。 （ア）引用発明の「ホームゲートウェイ装置が行うアクセスコントロール処理方法」は，「ホームゲートウェイ装置」が“コンピュータデバイス”とみることができ，「物理デバイス」に対する「アプリケーション」のアクセスをコントロールする方法であることは明らかである。 一方，本件補正発明の「コンピュータデバイスのオペレーティングシステムにおける方法」は，「ハードウェアデバイス」に対する「アプリケーション」のアクセスをコントロールする方法であることは明らかであるから，両者は“コンピュータデバイスが行うアクセスコントロール方法”である点で共通するといえる。 （イ）引用発明では，「アプリケーションは，ユーザの指示を受け付けて，自身の識別子を通知して，対象となる物理デバイスに対応するデバイスインスタンスを呼び出」すところ，上記（ア）での検討より，引用発明の「物理デバイス」は「アプリケーション」のアクセスの対象であることから，本件補正発明の「ハードウェアデバイス」に相当するといえる。 また，引用発明では，「アプリケーション」は「物理デバイス」にアクセスするために「デバイスインスタンス」を呼び出すのは明らかであるから，引用発明では，「デバイスインスタンス」は「ハードウェアデバイス」にアクセスするリクエストを「アプリケーション」から受け取るとみることができる。 （ウ）引用発明では，「デバイスインスタンスは，処理を開始する前に，前記JavaVMの機能であるアクセスコントローラに，パーミッションのチェックを要求し，前記アクセスコントローラは，要求元の前記デバイスインスタンスを呼び出した前記アプリケーションのパーミッションチェックを行い，前記ポリシーの中にチェック要求に含まれる前記デバイスインスタンスおよび前記アプリケーションの識別子のパーミッションが存在する場合は，呼出元の前記アプリケーションはアクセスする権利があると判別し，前記ポリシーに存在しない場合は，呼出元の前記アプリケーションはアクセスする権利がないと判別」するところ，引用発明の「ポリシー」は，「アプリケーション」が「物理デバイス」にアクセスすることを許可されているかどうかを特定するための情報を含むと解されるから，本件補正発明の「デバイス許可記録」に対応し，両者は“アプリケーションが前記ハードウェアデバイスにアクセスすることを許可されている”かどうかが特定されている点で共通するといえる。 （エ）引用発明では，「要求元の前記デバイスインスタンスは，前記アクセスコントローラからチェック結果を取得し，呼出元の前記アプリケーションがアクセス権を有するチェック結果の場合，前記デバイスインスタンスは，前記物理デバイスに対して所定の処理を行い，一方，呼出元の前記アプリケーションがアクセス権を有しないチェック結果の場合，前記デバイスインスタンスは，処理を中断し，エラーを呼出元の前記アプリケーションに返す」ところ，上記（ウ）での検討より，引用発明の「ポリシー」は，「アプリケーション」が「物理デバイス」にアクセスすることを許可されているかどうかを特定するための情報を含み，本件補正発明の「デバイス許可記録」に対応することから，引用発明では，「アプリケーション」が「物理デバイス」にアクセスすることを許可されていると「ポリシー」が示す場合は，「アプリケーション」が「物理デバイス」にアクセスすることを可能にし，「アプリケーション」が「物理デバイス」にアクセスすることを許可されていると「ポリシー」が示さない場合は，リクエストを拒絶するとみることができる。 イ　以上から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。 ＜一致点＞ 「　コンピュータデバイスが行うアクセスコントロール方法であって， 前記コンピュータデバイスにインストールされているハードウェアデバイスにアクセスするリクエストをアプリケーションから受け取るステップと， 前記アプリケーションが前記ハードウェアデバイスにアクセスすることを許可されているとデバイス許可記録において特定されるかどうかを確認するステップと， 前記アプリケーションが前記ハードウェアデバイスにアクセスすることを許可されていると前記デバイス許可記録が示す場合は，前記アプリケーションが前記ハードウェアデバイスにアクセスすることを可能にし，前記アプリケーションが前記ハードウェアデバイスにアクセスすることを許可されていると前記デバイス許可記録が示さない場合は，前記リクエストを拒絶するステップと を有し， 前記デバイス許可記録は，前記ハードウェアデバイスとアクセス可能な前記アプリケーションが関連付けられている，方法。」 ＜相違点１＞ ハードウェアデバイスへのアクセスのリクエストに関し，本件補正発明では，「アプリケーション」から「オペレーティングシステム」が「第１の機能」にアクセスする「リクエスト」を受け取るのに対して，引用発明では，「アプリケーション」から「対象となる物理デバイスに対応するデバイスインスタンス」が呼び出される点。 ＜相違点２＞ デバイス許可記録に基づくハードウェアデバイスへのアクセス許可の確認に関し，本件補正発明では，「オペレーティングシステム」によって，「アプリケーション」が「第１の機能」にアクセス許可されているかどうかを確認し，「デバイス許可記録は，前記オペレーティングシステムの一部分として含まれており，前記複数の機能の夫々について機能識別子を保持し，異なる承諾タイプが異なる機能識別子と関連付けられ，夫々の機能識別子は，前記ハードウェアデバイスの機能群に対応し，夫々の機能識別子について，当該機能識別子と関連付けられている承諾タイプは，もしあれば，前記アプリケーションが前記機能群にアクセスするために必要とされる承諾のタイプを示す」のに対して，引用発明では，呼出元の「アプリケーション」が「対象となる物理デバイス」にアクセスする権利があるかどうか，「アクセスコントローラ」が「ポリシー」に基づき判別するものの，「ポリシー」に如何なる情報が記憶されているか不明である点。 （３）判断 上記相違点１，２について検討する。 ア　相違点１について 引用発明では，「アプリケーションは，ユーザの指示を受け付けて，自身の識別子を通知して，対象となる物理デバイスに対応するデバイスインスタンスを呼び出」すところ，アプリケーションがハードウェアデバイス（物理デバイス）へのアクセスのリクエストをする場合に，アプリケーションからオペレーティングシステムに対して，共通の「機能」を有するハードウェアデバイスを一群とした「リクエスト」を発行することの動機付けを直ちに見い出すことはできない。 また，オペレーティングシステムによって，アプリケーションからハードウェアデバイスに対するアクセス制御を行うことは，例えば，引用例２（上記Ｄを参照），引用例３（上記Ｅを参照）に記載されるように，本願優先日前には当該技術分野における周知技術であったとしても，アプリケーションからオペレーティングシステムに対して，共通の「機能」を有するハードウェアデバイスを一群とした「リクエスト」を発行することが当該技術分野における周知技術であったとはいえない。 そうすると，引用発明において，アプリケーションからハードウェアデバイスへのアクセス要求をする時に，オペレーティングシステムが第１の機能にアクセスするリクエストを受け取ること，すなわち，上記相違点１に係る構成とすることは，当業者が適宜なし得たものであるとすることはできない。 イ　相違点２について 引用発明では，呼出元の「アプリケーション」が「対象となる物理デバイス」にアクセスする権利があるかどうか，「アクセスコントローラ」が「ポリシー」に基づき判別するところ，「オペレーティングシステム」によって，共通の「機能」を有するハードウェアデバイスを一群として，「アプリケーション」がアクセス許可されているかどうかを確認することの動機付けを直ちに見い出すことはできない。 また，オペレーティングシステムによって，アプリケーションからハードウェアデバイスに対するアクセス制御を行うことは，例えば，引用例２（上記Ｄを参照），引用例３（上記Ｅを参照）に記載されるように，本願優先日前には当該技術分野における周知技術であったとしても，オペレーティングシステムによって，共通の「機能」を有するハードウェアデバイスを一群として，各アプリケーションがアクセス許可されているかどうかを確認することが当該技術分野における周知技術であったとはいえない。 さらに，「アプリケーション」が共通の「機能」を有する「ハードウェアデバイス」にアクセス許可されているかどうかを確認するための「デバイス許可記録」について，「オペレーティングシステムの一部分として含まれており，前記複数の機能の夫々について機能識別子を保持し，異なる承諾タイプが異なる機能識別子と関連付けられ，夫々の機能識別子は，前記ハードウェアデバイスの機能群に対応し，夫々の機能識別子について，当該機能識別子と関連付けられている承諾タイプは，もしあれば，前記アプリケーションが前記機能群にアクセスするために必要とされる承諾のタイプを示す」ことが当該技術分野における周知技術であったとはいえない。 そうすると，引用発明において，オペレーティングシステムによって，アプリケーションがデバイス許可記録を用いて第１の機能にアクセス許可されているかどうかを確認し，当該デバイス許可記録は，オペレーティングシステムの一部分として含まれており，複数の機能の夫々について機能識別子を保持し，異なる承諾タイプが異なる機能識別子と関連付けられ，夫々の機能識別子は，ハードウェアデバイスの機能群に対応し，夫々の機能識別子について，当該機能識別子と関連付けられている承諾タイプは，もしあれば，アプリケーションが機能群にアクセスするために必要とされる承諾のタイプを示すこと，すなわち，上記相違点２に係る構成とすることは，当業者が適宜なし得たものであるとすることはできない。 ウ　小括 上記で検討したごとく，本件補正発明は，当業者が引用発明および引用例２，３に記載の技術に基づいて容易に発明をすることができたとはいえない。 よって，本件補正の補正事項１は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合する。 また，補正後の請求項２乃至５に係る発明は本件補正発明をさらに限定したものであり，補正後の請求項６に係る発明は，方法の発明である本件補正発明を装置（コンピュータデバイス）の発明として特定したものであり，補正後の請求項７乃至１０に係る発明は，請求項６に係る発明をさらに限定したものであるので，同様に，当業者が容易に発明をすることができたものとすることができないものである。 したがって，本件補正のその余の補正事項についても，特許法第１７条の２第３項乃至第６項に違反するところはない。 ３　むすび 以上のように，本件補正は，特許法第１７条の２第３項乃至第６項の規定に適合する。 第３　本願発明 本件補正は上記のとおり，特許法第１７条の２第３項乃至第６項の規定に適合するから，本願の請求項１乃至１０に係る発明は，本件補正により補正された平成２８年６月１４日付け手続補正書に記載の特許請求の範囲の請求項１乃至１０に記載された事項により特定されるとおりのものである。 そして，本願の請求項１乃至１０に係る発明は，当業者が引用発明および引用例２，３に記載の技術に基づいて容易に発明をすることができたものではないから，原査定の拒絶理由を検討してもその理由によって拒絶することはできない。 また，他に本願を拒絶すべき理由を発見しない。 よって，結論のとおり審決する。