ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 G06F |
---|---|
管理番号 | 1326714 |
審判番号 | 不服2016-8827 |
総通号数 | 209 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2017-05-26 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2016-06-14 |
確定日 | 2017-04-18 |
事件の表示 | 特願2014-509279「デバイス機能へのアプリケーションの結び付け」拒絶査定不服審判事件〔平成24年11月 8日国際公開、WO2012/150955、平成26年 7月17日国内公表、特表2014-517383、請求項の数(10)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
第1 手続の経緯 本件審判請求に係る出願(以下,「本願」という。)は,2011年10月10日(パリ条約による優先権主張外国庁受理2011年5月2日(以下,「優先日」という。),米国)を国際出願日とする出願であって,その手続の経緯は以下のとおりである。 平成25年10月23日 :国内書面の提出 平成26年 9月25日 :出願審査請求書,手続補正書の提出 平成27年 9月10日付け :拒絶理由の通知 平成27年12月14日 :意見書,手続補正書の提出 平成28年 3月 9日付け :拒絶査定 平成28年 6月14日 :審判請求書,手続補正書の提出 平成28年 7月14日 :前置報告 第2 平成28年6月14日付けの手続補正の適否 1 補正の内容 平成28年6月14日付けの手続補正(以下,「本件補正」という。)は,特許請求の範囲の請求項1を, 「 コンピュータデバイスのオペレーティングシステムにおける方法であって, 前記コンピュータデバイスにインストールされているハードウェアデバイスの複数の機能のうちの第1の機能にアクセスするリクエストをアプリケーションから受け取るステップと, 前記オペレーティングシステムによって,前記アプリケーションが前記ハードウェアデバイスの前記第1の機能にアクセスすることを許可されているとデバイス許可記録において特定されるかどうかを確認するステップと, 前記アプリケーションが前記ハードウェアデバイスの前記第1の機能にアクセスすることを許可されていると前記デバイス許可記録が示す場合は,前記アプリケーションが前記ハードウェアデバイスの前記第1の機能にアクセスすることを可能にし,前記アプリケーションが前記ハードウェアデバイスの前記第1の機能にアクセスすることを許可されていると前記デバイス許可記録が示さない場合は,前記リクエストを拒絶するステップと を有し, 前記デバイス許可記録は,前記オペレーティングシステムの一部分として含まれており,前記複数の機能の夫々について機能識別子を保持し,異なる承諾タイプが異なる機能識別子と関連付けられ,夫々の機能識別子は,前記ハードウェアデバイスの機能群に対応し,夫々の機能識別子について,当該機能識別子と関連付けられている承諾タイプは,もしあれば,前記アプリケーションが前記機能群にアクセスするために必要とされる承諾のタイプを示す,方法。」 (当審注:下線は,請求人が付与したものである。以下,この特許請求の範囲に記載された請求項を「補正後の請求項1」という。) とする補正(以下,「補正事項1」という。)を含んでいる。 2 補正の適否 本件補正の補正事項1は,補正前の請求項1に記載した発明を特定するために必要な事項である「ハードウェアデバイスの機能」について, 「複数の機能のうちの第1の」または「前記第1の」との限定を加えるものであって, また,補正前の請求項1に記載した発明を特定するために必要な事項である「デバイス許可記録」について, 「前記デバイス許可記録は,前記オペレーティングシステムの一部分として含まれており,前記複数の機能の夫々について機能識別子を保持し,異なる承諾タイプが異なる機能識別子と関連付けられ,夫々の機能識別子は,前記ハードウェアデバイスの機能群に対応し,夫々の機能識別子について,当該機能識別子と関連付けられている承諾タイプは,もしあれば,前記アプリケーションが前記機能群にアクセスするために必要とされる承諾のタイプを示す,」との限定を加えるものである。 補正前の請求項1に記載された発明と補正後の請求項1に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから,特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。 加えて,特許法第17条の2第3項,第4項に違反するところはない。 そこで,補正事項1は特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものを含むことから,補正後の前記請求項1に記載された発明(以下,「本件補正発明」という。)が特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について以下に検討する。 (1)引用例 (1-1)引用例1に記載される技術的事項および引用発明 ア 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,原審の拒絶査定の理由である平成27年9月10日付けの拒絶理由通知において引用された,特開2008-305336号公報(平成20年12月18日出願公開,以下,「引用例1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。 (当審注:下線は,参考のために当審で付与したものである。) A 「【0030】 図3は,本実施形態のホームゲートウェイ装置1が行うアクセスコントロール処理を説明するための説明図である。 【0031】 デバイスドライバ103は,service.pidを指定してデバイスインスタンス104のインスタンスを生成する。そして,デバイスドライバ103は,インスタンス生成時にOSGi Frameworkに指定したservice.pidと,当該インスタンスを利用可能な所定のアプリケーション107の識別子とを,割当情報サービス106を介して割当管理105に登録(格納)する(S1)。なお,当該インスタンスを利用可能なアプリケーション107は,ユーザが指定することなどにより,あらかじめ定められているものとする。 【0032】 OSGi Frameworkを用いる場合には,アプリケーション107の識別子として,BundleLOCATIONなどを用いることが可能である。また,これ以外に,電子署名を用いることも可能である。 【0033】 割当管理105は,デバイスドライバ103により割当情報が登録されると,当該割当情報に基づいてパーミッション(Permission)121を生成し,当該パーミッション121をJava(登録商標)VMに登録する(S2)。 【0034】 OSGi Frameworkを用いる場合の具体的な登録方法としては,割当管理105は,割当情報に設定されたアプリケーション107のBundleLOCATIONと,デバイスインスタンス104のservice.pidとが対になったパーミッション121を生成する。そして,割当管理105は,生成したパーミッション121をOSGi Frameworkの図示しないパーミッションアドミン(Permission Admin)を用いて,Java(登録商標)VMのポリシー113(記憶部)に登録する。 【0035】 このようにして,Java(登録商標)VMにパーミッション121が登録される。」 B 「【0036】 次に,アプリケーション107は,ユーザの指示を受け付けて,対象となる物理デバイス2に対応するデバイスインスタンス104を呼び出す(S3)。アプリケーション107は,デバイスインスタンス104を呼び出す際に,Java(登録商標)VMの機能により自身の識別子がデバイスインスタンス104に通知される。 【0037】 なお,ユーザは,図示しない表示装置に表示されたGUI(Graphical User Interface)を操作することなどにより,アプリケーション107に対する指示を入力する。 【0038】 アプリケーション107から呼び出されたデバイスインスタンス104は,処理を開始する前に,Java(登録商標)VMの機能であるアクセスコントローラ(AccessController)111に,パーミッションのチェックを要求する(S4)。すなわち,デバイスインスタンス104は,自身に設定されたservice.pidと,アプリケーション107の識別子とを含むチェック要求122を,アクセスコントローラ111に送出する。」 C 「【0039】 アクセスコントローラ111は,Java(登録商標)VMの機能を用いて,要求元のデバイスインスタンス104を呼び出したアプリケーション107が,当該デバイスインスタンス104にアクセスする権利があるか否かのパーミッションチェックを行い,チェック結果を返す。 【0040】 すなわち,アクセスコントローラ111は,ポリシー113の中にチェック要求122に含まれるデバイスインスタンス104のservice.pidおよびアプリケーション107の識別子のパーミッションが存在する場合は,呼出元のアプリケーション107はアクセスする権利があると判別する。一方,ポリシー113に存在しない場合は,呼出元のアプリケーション107はアクセスする権利がないと判別する。 【0041】 要求元のデバイスインスタンス104は,アクセスコントローラからチェック結果を取得する。呼出元のアプリケーション107がアクセス権を有する(パーミッションが与えられている)チェック結果の場合,デバイスインスタンス104は,物理デバイス2に対して所定の処理を行う。一方,呼出元のアプリケーション107がアクセス権を有しない(パーミッションが与えられていない)チェック結果の場合,デバイスインスタンス104は,処理を中断し,エラーを呼出元のアプリケーション107に返す。 【0042】 以上説明した本実施形態のホームゲートウェイ装置1では,インスタンスの生成時に,当該インスタンスを一意に識別可能な識別情報(service.pid)を付与するとともに,当該識別情報とアクセスを許可するアプリケーションとを対応付けたパーミッションを登録する。そして,アプリケーションからインスタンスが呼び出されたときに,インスタンスの識別情報を用いてパーミッションのチェックを行い,アクセスが許可されているアプリケーションから場合にのみ処理を実行する。これにより,本実施形態では,インスタンス単位でのアクセスコントロールを行うことができる。すなわち,各インスタンスを,特定のアプリケーションからのみアクセスさせることができる。」 イ ここで,引用例1に記載されている事項を検討する。 (ア)上記Aの段落【0030】の「図3は,本実施形態のホームゲートウェイ装置1が行うアクセスコントロール処理を説明するための説明図である。」との記載からすると,引用例1には, “ホームゲートウェイ装置が行うアクセスコントロール処理方法” が記載されていると解される。 (イ)上記Aの段落【0033】の「割当管理105は,デバイスドライバ103により割当情報が登録されると,当該割当情報に基づいてパーミッション(Permission)121を生成し,当該パーミッション121をJava(登録商標)VMに登録する(S2)。」との記載,段落【0034】の「そして,割当管理105は,生成したパーミッション121をOSGi Frameworkの図示しないパーミッションアドミン(Permission Admin)を用いて,Java(登録商標)VMのポリシー113(記憶部)に登録する。」との記載からすると,「割当管理」は「パーミッション」を「JavaVM」の「ポリシー(記憶部)」に登録することが読み取れるから,引用例1には, “割当管理は,デバイスドライバにより割当情報が登録されると,割当情報に基づいてパーミッションを生成し,JavaVMのポリシー(記憶部)に登録”すること が記載されていると解される。 (ウ)上記Bの段落【0036】の「次に,アプリケーション107は,ユーザの指示を受け付けて,対象となる物理デバイス2に対応するデバイスインスタンス104を呼び出す(S3)。アプリケーション107は,デバイスインスタンス104を呼び出す際に,Java(登録商標)VMの機能により自身の識別子がデバイスインスタンス104に通知される。」との記載,上記Bの段落【0038】の「アプリケーション107から呼び出されたデバイスインスタンス104は,処理を開始する前に,Java(登録商標)VMの機能であるアクセスコントローラ(AccessController)111に,パーミッションのチェックを要求する(S4)。」との記載からすると,「アプリケーション」は,自身の「識別子」を通知して,「デバイスインスタンス」を呼び出すことが読み取れるから,引用例1には, “アプリケーションは,ユーザの指示を受け付けて,自身の識別子を通知して,対象となる物理デバイスに対応するデバイスインスタンスを呼び出し, デバイスインスタンスは,処理を開始する前に,JavaVMの機能であるアクセスコントローラに,パーミッションのチェックを要求”すること が記載されていると解される。 (エ)上記Cの段落【0039】の「アクセスコントローラ111は,Java(登録商標)VMの機能を用いて,要求元のデバイスインスタンス104を呼び出したアプリケーション107が,当該デバイスインスタンス104にアクセスする権利があるか否かのパーミッションチェックを行い,チェック結果を返す。」との記載,段落【0040】の「すなわち,アクセスコントローラ111は,ポリシー113の中にチェック要求122に含まれるデバイスインスタンス104のservice.pidおよびアプリケーション107の識別子のパーミッションが存在する場合は,呼出元のアプリケーション107はアクセスする権利があると判別する。一方,ポリシー113に存在しない場合は,呼出元のアプリケーション107はアクセスする権利がないと判別する。」との記載からすると,「アクセスコントローラ」は,要求元の「デバイスインスタンス」を呼び出した「アプリケーション」の「パーミッションチェック」を行うことが読み取れるから,引用例1には, “アクセスコントローラは,要求元のデバイスインスタンスを呼び出したアプリケーションのパーミッションチェックを行い,ポリシーの中にチェック要求に含まれるデバイスインスタンスおよびアプリケーションの識別子のパーミッションが存在する場合は,呼出元のアプリケーションはアクセスする権利があると判別し,ポリシーに存在しない場合は,呼出元のアプリケーションはアクセスする権利がないと判別”すること が記載されていると解される。 (オ)上記Cの段落【0041】の「要求元のデバイスインスタンス104は,アクセスコントローラからチェック結果を取得する。呼出元のアプリケーション107がアクセス権を有する(パーミッションが与えられている)チェック結果の場合,デバイスインスタンス104は,物理デバイス2に対して所定の処理を行う。一方,呼出元のアプリケーション107がアクセス権を有しない(パーミッションが与えられていない)チェック結果の場合,デバイスインスタンス104は,処理を中断し,エラーを呼出元のアプリケーション107に返す。」との記載からすると,要求元の「デバイスインスタンス」は,「アクセスコントローラ」からチェック結果を取得して,チェック結果に応じた処理を行うことが読み取れるから,引用例1には, “要求元のデバイスインスタンスは,アクセスコントローラからチェック結果を取得し,呼出元のアプリケーションがアクセス権を有するチェック結果の場合,デバイスインスタンスは,物理デバイスに対して所定の処理を行い,一方,呼出元のアプリケーションがアクセス権を有しないチェック結果の場合,デバイスインスタンスは,処理を中断し,エラーを呼出元のアプリケーションに返す”こと が記載されていると解される。 ウ 以上,(ア)乃至(オ)で示した事項から,引用例1には,次の発明(以下,「引用発明」という。)が記載されているものと認める。 「ホームゲートウェイ装置が行うアクセスコントロール処理方法であって, 割当管理は,デバイスドライバにより割当情報が登録されると,割当情報に基づいてパーミッションを生成し,JavaVMのポリシー(記憶部)に登録し, アプリケーションは,ユーザの指示を受け付けて,自身の識別子を通知して,対象となる物理デバイスに対応するデバイスインスタンスを呼び出し, 前記デバイスインスタンスは,処理を開始する前に,前記JavaVMの機能であるアクセスコントローラに,パーミッションのチェックを要求し, 前記アクセスコントローラは,要求元の前記デバイスインスタンスを呼び出した前記アプリケーションのパーミッションチェックを行い,前記ポリシーの中にチェック要求に含まれる前記デバイスインスタンスおよび前記アプリケーションの識別子のパーミッションが存在する場合は,呼出元の前記アプリケーションはアクセスする権利があると判別し,前記ポリシーに存在しない場合は,呼出元の前記アプリケーションはアクセスする権利がないと判別し, 要求元の前記デバイスインスタンスは,前記アクセスコントローラからチェック結果を取得し,呼出元の前記アプリケーションがアクセス権を有するチェック結果の場合,前記デバイスインスタンスは,前記物理デバイスに対して所定の処理を行い,一方,呼出元の前記アプリケーションがアクセス権を有しないチェック結果の場合,前記デバイスインスタンスは,処理を中断し,エラーを呼出元の前記アプリケーションに返す,方法。」 (1-2)引用例2に記載される技術的事項 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,原審の拒絶査定の理由である平成27年9月10日付けの拒絶理由通知において引用された,特開2004-192100号公報(平成16年7月8日出願公開,以下,「引用例2」という。)には,以下の技術的事項が記載されている。 (当審注:下線は,参考のために当審で付与したものである。) D 「【0026】 図1に示すように,本実施形態のデバイスとしてのネットワークデバイスであるLANカード11は,チップセット12を有している。このチップセット12には,EEPROMなどからなる不揮発性メモリ13が配設されており,この不揮発性メモリ13には,PCI用設定値が記憶されるPCI用設定値記憶部14,PCカード用設定値が記憶されるPCカード用設定値記憶部15,デバイス固有の設定値が記憶される固有情報記憶部16,MACアドレスが記憶されるMACアドレス記憶部17,チェックデータ記憶部18などが設けられている。 【0027】 前記デバイス固有の設定値は,従来と同様に,例えばデバイスID,ベンダーID,サブシステムID,サブシステムベンダーIDなどにより構成されている。なお,デバイス固有の設定値は,OSの種類に応じて設定すればよい。 …(中略)… 【0029】 前記チェックデータは,不正使用の防止に用いるものであり,前記デバイス固有の設定値を基にしたチェックサム,チェックデジット,チェックビット,シフトなどを単独もしくは組み合わせて暗号化したものを用いることが好ましい。 【0030】 前記PCカード用設定値記憶部15とMACアドレス記憶部17との2箇所に記憶されているMACアドレスと,チェックデータ記憶部18に記憶されているチェックデータの両者により,本実施形態の保護データが形成されている。 【0031】 なお,保護データとしては,チェックデータと,2箇所に記憶されているMACアドレスの一方であってもよい。そして,保護データとしてチェックデータを用いると,あらゆるデバイスに用いることができる。さらに,保護データとしてMACアドレスを用いると,コンピュータネットワークに接続するネットワークデバイスに好適である。また,保護データとしてチェックデータおよびMACアドレスの両者を用いると保護データを強固なものとすることができる。」 (1-3)引用例3に記載される技術的事項 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,平成28年3月9日付けの拒絶査定において引用された,特表2005-502128号公報(平成17年1月20日出願公表,以下,「引用例3」という。)には,以下の技術的事項が記載されている。 (当審注:下線は,参考のために当審で付与したものである。) E 「【0030】 図3は,本発明の例示的な実施形態における無線装置の構成要素を示すブロック図である。無線装置300は制御プログラム305,それぞれに許可リスト320とデジタル署名325が付いたアプリケーション310,及びリソース315を含む。アプリケーション310が様々なタスクを実行してよいことが当業者によって認識されるだろう。さらに,各アプリケーション110は,そのアプリケーションと,通常アプリケーションと許可リストごとに一意であるデジタル署名と関連付けられる別個の許可リストを有してよい。315に一覧表示されているリソースが多くのデバイスリソースの例であることも当業者によって認識されるだろう。デバイスがアクセスしてよいデバイスの外のリソースを含む,デバイスと関連付けられた多くのリソースがあり,そのアクセスは許可リストに基づきアプリケーションに与えられてよい。 【0031】 一実施形態では,制御プログラム305はリソース315へのアクセスを管理するのに役立つためにデバイス上に位置している。制御プログラム305の機能は,無線装置のオペレーティングシステムに組み込まれてよいか,あるいはクアルコム社によって開発されたBREW(商標)APIなどの別個のAPIであってよい。制御プログラム305は,アプリケーションに授けられる特権に基づきアプリケーションへのリソースのアクセスを許可または拒絶してよい。 【0032】 一実施形態では,これらの特権はアプリケーションに関連付けられた許可リスト320を介して決定される。許可リスト320はリソース315のリスティング,及びアプリケーションがデバイス上の特定のリソース315のどれかにアクセスする許可を有しているかどうかの表示を含む。例えば,許可リスト320は「マイク」及び「スピーカ」のフィールドを含んでよい。フィールドのそれぞれのフラグの設定が,アプリケーションがマイクにアクセスできるのか,あるいはスピーカにアクセスできるのかを示す。いくつかの例では,マイクフィールドにセットされたフラグは,アプリケーションがマイクにアクセスしてよいことを示している。フラグがセットされておらず,それによってアクセスを拒絶する場合もある。許可リスト内で可能な限り多くのリソースを明らかにさせ,フラグを,アプリケーションが関連リソースにアクセスできるかどうかを示すそれぞれのものと関連させることが好ましい。」 (2)対比 ア 本件補正発明と引用発明とを対比する。 (ア)引用発明の「ホームゲートウェイ装置が行うアクセスコントロール処理方法」は,「ホームゲートウェイ装置」が“コンピュータデバイス”とみることができ,「物理デバイス」に対する「アプリケーション」のアクセスをコントロールする方法であることは明らかである。 一方,本件補正発明の「コンピュータデバイスのオペレーティングシステムにおける方法」は,「ハードウェアデバイス」に対する「アプリケーション」のアクセスをコントロールする方法であることは明らかであるから,両者は“コンピュータデバイスが行うアクセスコントロール方法”である点で共通するといえる。 (イ)引用発明では,「アプリケーションは,ユーザの指示を受け付けて,自身の識別子を通知して,対象となる物理デバイスに対応するデバイスインスタンスを呼び出」すところ,上記(ア)での検討より,引用発明の「物理デバイス」は「アプリケーション」のアクセスの対象であることから,本件補正発明の「ハードウェアデバイス」に相当するといえる。 また,引用発明では,「アプリケーション」は「物理デバイス」にアクセスするために「デバイスインスタンス」を呼び出すのは明らかであるから,引用発明では,「デバイスインスタンス」は「ハードウェアデバイス」にアクセスするリクエストを「アプリケーション」から受け取るとみることができる。 (ウ)引用発明では,「デバイスインスタンスは,処理を開始する前に,前記JavaVMの機能であるアクセスコントローラに,パーミッションのチェックを要求し,前記アクセスコントローラは,要求元の前記デバイスインスタンスを呼び出した前記アプリケーションのパーミッションチェックを行い,前記ポリシーの中にチェック要求に含まれる前記デバイスインスタンスおよび前記アプリケーションの識別子のパーミッションが存在する場合は,呼出元の前記アプリケーションはアクセスする権利があると判別し,前記ポリシーに存在しない場合は,呼出元の前記アプリケーションはアクセスする権利がないと判別」するところ,引用発明の「ポリシー」は,「アプリケーション」が「物理デバイス」にアクセスすることを許可されているかどうかを特定するための情報を含むと解されるから,本件補正発明の「デバイス許可記録」に対応し,両者は“アプリケーションが前記ハードウェアデバイスにアクセスすることを許可されている”かどうかが特定されている点で共通するといえる。 (エ)引用発明では,「要求元の前記デバイスインスタンスは,前記アクセスコントローラからチェック結果を取得し,呼出元の前記アプリケーションがアクセス権を有するチェック結果の場合,前記デバイスインスタンスは,前記物理デバイスに対して所定の処理を行い,一方,呼出元の前記アプリケーションがアクセス権を有しないチェック結果の場合,前記デバイスインスタンスは,処理を中断し,エラーを呼出元の前記アプリケーションに返す」ところ,上記(ウ)での検討より,引用発明の「ポリシー」は,「アプリケーション」が「物理デバイス」にアクセスすることを許可されているかどうかを特定するための情報を含み,本件補正発明の「デバイス許可記録」に対応することから,引用発明では,「アプリケーション」が「物理デバイス」にアクセスすることを許可されていると「ポリシー」が示す場合は,「アプリケーション」が「物理デバイス」にアクセスすることを可能にし,「アプリケーション」が「物理デバイス」にアクセスすることを許可されていると「ポリシー」が示さない場合は,リクエストを拒絶するとみることができる。 イ 以上から,本件補正発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。 <一致点> 「 コンピュータデバイスが行うアクセスコントロール方法であって, 前記コンピュータデバイスにインストールされているハードウェアデバイスにアクセスするリクエストをアプリケーションから受け取るステップと, 前記アプリケーションが前記ハードウェアデバイスにアクセスすることを許可されているとデバイス許可記録において特定されるかどうかを確認するステップと, 前記アプリケーションが前記ハードウェアデバイスにアクセスすることを許可されていると前記デバイス許可記録が示す場合は,前記アプリケーションが前記ハードウェアデバイスにアクセスすることを可能にし,前記アプリケーションが前記ハードウェアデバイスにアクセスすることを許可されていると前記デバイス許可記録が示さない場合は,前記リクエストを拒絶するステップと を有し, 前記デバイス許可記録は,前記ハードウェアデバイスとアクセス可能な前記アプリケーションが関連付けられている,方法。」 <相違点1> ハードウェアデバイスへのアクセスのリクエストに関し,本件補正発明では,「アプリケーション」から「オペレーティングシステム」が「第1の機能」にアクセスする「リクエスト」を受け取るのに対して,引用発明では,「アプリケーション」から「対象となる物理デバイスに対応するデバイスインスタンス」が呼び出される点。 <相違点2> デバイス許可記録に基づくハードウェアデバイスへのアクセス許可の確認に関し,本件補正発明では,「オペレーティングシステム」によって,「アプリケーション」が「第1の機能」にアクセス許可されているかどうかを確認し,「デバイス許可記録は,前記オペレーティングシステムの一部分として含まれており,前記複数の機能の夫々について機能識別子を保持し,異なる承諾タイプが異なる機能識別子と関連付けられ,夫々の機能識別子は,前記ハードウェアデバイスの機能群に対応し,夫々の機能識別子について,当該機能識別子と関連付けられている承諾タイプは,もしあれば,前記アプリケーションが前記機能群にアクセスするために必要とされる承諾のタイプを示す」のに対して,引用発明では,呼出元の「アプリケーション」が「対象となる物理デバイス」にアクセスする権利があるかどうか,「アクセスコントローラ」が「ポリシー」に基づき判別するものの,「ポリシー」に如何なる情報が記憶されているか不明である点。 (3)判断 上記相違点1,2について検討する。 ア 相違点1について 引用発明では,「アプリケーションは,ユーザの指示を受け付けて,自身の識別子を通知して,対象となる物理デバイスに対応するデバイスインスタンスを呼び出」すところ,アプリケーションがハードウェアデバイス(物理デバイス)へのアクセスのリクエストをする場合に,アプリケーションからオペレーティングシステムに対して,共通の「機能」を有するハードウェアデバイスを一群とした「リクエスト」を発行することの動機付けを直ちに見い出すことはできない。 また,オペレーティングシステムによって,アプリケーションからハードウェアデバイスに対するアクセス制御を行うことは,例えば,引用例2(上記Dを参照),引用例3(上記Eを参照)に記載されるように,本願優先日前には当該技術分野における周知技術であったとしても,アプリケーションからオペレーティングシステムに対して,共通の「機能」を有するハードウェアデバイスを一群とした「リクエスト」を発行することが当該技術分野における周知技術であったとはいえない。 そうすると,引用発明において,アプリケーションからハードウェアデバイスへのアクセス要求をする時に,オペレーティングシステムが第1の機能にアクセスするリクエストを受け取ること,すなわち,上記相違点1に係る構成とすることは,当業者が適宜なし得たものであるとすることはできない。 イ 相違点2について 引用発明では,呼出元の「アプリケーション」が「対象となる物理デバイス」にアクセスする権利があるかどうか,「アクセスコントローラ」が「ポリシー」に基づき判別するところ,「オペレーティングシステム」によって,共通の「機能」を有するハードウェアデバイスを一群として,「アプリケーション」がアクセス許可されているかどうかを確認することの動機付けを直ちに見い出すことはできない。 また,オペレーティングシステムによって,アプリケーションからハードウェアデバイスに対するアクセス制御を行うことは,例えば,引用例2(上記Dを参照),引用例3(上記Eを参照)に記載されるように,本願優先日前には当該技術分野における周知技術であったとしても,オペレーティングシステムによって,共通の「機能」を有するハードウェアデバイスを一群として,各アプリケーションがアクセス許可されているかどうかを確認することが当該技術分野における周知技術であったとはいえない。 さらに,「アプリケーション」が共通の「機能」を有する「ハードウェアデバイス」にアクセス許可されているかどうかを確認するための「デバイス許可記録」について,「オペレーティングシステムの一部分として含まれており,前記複数の機能の夫々について機能識別子を保持し,異なる承諾タイプが異なる機能識別子と関連付けられ,夫々の機能識別子は,前記ハードウェアデバイスの機能群に対応し,夫々の機能識別子について,当該機能識別子と関連付けられている承諾タイプは,もしあれば,前記アプリケーションが前記機能群にアクセスするために必要とされる承諾のタイプを示す」ことが当該技術分野における周知技術であったとはいえない。 そうすると,引用発明において,オペレーティングシステムによって,アプリケーションがデバイス許可記録を用いて第1の機能にアクセス許可されているかどうかを確認し,当該デバイス許可記録は,オペレーティングシステムの一部分として含まれており,複数の機能の夫々について機能識別子を保持し,異なる承諾タイプが異なる機能識別子と関連付けられ,夫々の機能識別子は,ハードウェアデバイスの機能群に対応し,夫々の機能識別子について,当該機能識別子と関連付けられている承諾タイプは,もしあれば,アプリケーションが機能群にアクセスするために必要とされる承諾のタイプを示すこと,すなわち,上記相違点2に係る構成とすることは,当業者が適宜なし得たものであるとすることはできない。 ウ 小括 上記で検討したごとく,本件補正発明は,当業者が引用発明および引用例2,3に記載の技術に基づいて容易に発明をすることができたとはいえない。 よって,本件補正の補正事項1は,特許法第17条の2第6項において準用する同法第126条第7項の規定に適合する。 また,補正後の請求項2乃至5に係る発明は本件補正発明をさらに限定したものであり,補正後の請求項6に係る発明は,方法の発明である本件補正発明を装置(コンピュータデバイス)の発明として特定したものであり,補正後の請求項7乃至10に係る発明は,請求項6に係る発明をさらに限定したものであるので,同様に,当業者が容易に発明をすることができたものとすることができないものである。 したがって,本件補正のその余の補正事項についても,特許法第17条の2第3項乃至第6項に違反するところはない。 3 むすび 以上のように,本件補正は,特許法第17条の2第3項乃至第6項の規定に適合する。 第3 本願発明 本件補正は上記のとおり,特許法第17条の2第3項乃至第6項の規定に適合するから,本願の請求項1乃至10に係る発明は,本件補正により補正された平成28年6月14日付け手続補正書に記載の特許請求の範囲の請求項1乃至10に記載された事項により特定されるとおりのものである。 そして,本願の請求項1乃至10に係る発明は,当業者が引用発明および引用例2,3に記載の技術に基づいて容易に発明をすることができたものではないから,原査定の拒絶理由を検討してもその理由によって拒絶することはできない。 また,他に本願を拒絶すべき理由を発見しない。 よって,結論のとおり審決する。 |
審決日 | 2017-04-04 |
出願番号 | 特願2014-509279(P2014-509279) |
審決分類 |
P
1
8・
121-
WY
(G06F)
|
最終処分 | 成立 |
前審関与審査官 | 脇岡 剛 |
特許庁審判長 |
高木 進 |
特許庁審判官 |
須田 勝巳 辻本 泰隆 |
発明の名称 | デバイス機能へのアプリケーションの結び付け |
代理人 | 大貫 進介 |
代理人 | 伊東 忠彦 |
代理人 | 伊東 忠重 |