• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
管理番号 1326713
審判番号 不服2015-21221  
総通号数 209 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-05-26 
種別 拒絶査定不服の審決 
審判請求日 2015-11-30 
確定日 2017-04-18 
事件の表示 特願2014-513492「隔離されたアプリケーションのためのブローカードアイテムアクセス」拒絶査定不服審判事件〔平成24年12月 6日国際公開、WO2012/166187、平成26年 6月30日国内公表、特表2014-515528、請求項の数(8)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は,2011年10月9日(パリ条約による優先権主張外国庁受理2011年5月27日,米国)を国際出願日とする出願であって,平成27年3月26日付けで拒絶理由が通知され,平成27年6月30日付けで手続補正がされ,平成27年7月21日付けで拒絶査定(以下,「原査定」という)がされ,これに対し,平成27年11月30日に拒絶査定不服審判が請求されるとともに手続補正がされ,その後,当審において平成28年10月27日付けで最後の拒絶理由(以下,「当審拒絶理由」という)が通知され,平成29年2月1日付けで手続補正がされたものである。

第2 平成29年2月1日付けの手続補正(以下,「本件補正」という。)の適否
1.補正の内容
(1)補正事項1
本件補正は,特許請求の範囲の請求項1の「前記フィルタされる一または複数の記憶アイテムオブジェクト」を「前記フィルタされた一または複数の記憶アイテムオブジェクト」とする補正(以下,「補正事項1」という。)を含んでいる。
(2)補正事項2
本件補正は,特許請求の範囲の請求項1の「前記隔離されたアプリケーションに前記一または複数の記憶アイテムオブジェクトを返すステップ」を「前記隔離されたアプリケーションに前記フィルタされた一または複数の記憶アイテムオブジェクトを返すステップ」とする補正(以下,「補正事項2」という。)を含んでいる。

2.補正の適否
補正事項1及び補正事項2は,いずれも,平成28年10月27日付けの当審拒絶理由の通知に対応して記載を明確にしたものであり,特許法第17条の2第5項第4号の「明りょうでない記載の釈明」を目的とするものに該当する。
また,特許法第17条の2第3項,第4項に違反するところはない。
したがって,本件補正は適法になされたものである。

第3 本願発明
上記「第2 平成29年2月1日付けの手続補正(以下,「本件補正」という。)の適否」のとおり,本件補正は適法になされたものであるので,本願の請求項1-8に係る発明(以下,それぞれ「本願発明1」-「本願発明8」という。)は,本件補正により補正された特許請求の範囲の請求項1-8に記載された事項により特定されるものと認められるところ,本願の請求項1に係る発明(以下,「本願発明1」という。)は以下のとおりである。

「 【請求項1】
コンピューティングデバイスにおける方法であって,
前記コンピューティングデバイスのブローカーモジュールにおいて,前記コンピューティングデバイスの隔離されたアプリケーションに一または複数のアプリケーションプログラミングインタフェース(API)をエクスポーズするステップであって,前記一または複数のAPIは,アイテムへの異なるタイプのアクセスのために前記隔離されたアプリケーションにより起動され得る一または複数のインタフェースをサポートするステップと,
前記ブローカーモジュールにおいて,前記一または複数のAPIを介して,前記隔離されたアプリケーションからの,アイテムソースの一または複数のアイテムにアクセスする要求を受け取るステップと,
前記コンピューティングデバイスにおいて,前記隔離されたアプリケーションが前記一または複数のアイテムのどれにアクセスする許可を受けているかチェックするステップと,
前記隔離されたアプリケーションが前記一または複数のアイテムのうちどれにもアクセスする許可を受けていないとき,前記要求を拒絶するステップと,
許可を受けているとき,
前記隔離されたアプリケーションがアクセスする許可を受けている前記一または複数のアイテムのうちのアイテムを表す一または複数の記憶アイテムオブジェクトを生成するステップと,
前記一または複数のアイテムのうちの,前記隔離されたアプリケーションがアクセスする許可を受けているアイテムを表す前記生成された一または複数の記憶アイテムオブジェクトをフィルタするステップであって,あるファイルタイプに対応する一または複数の記憶アイテムオブジェクトを排除して,前記フィルタされた一または複数の記憶アイテムオブジェクトが前記ファイルタイプに対応する記憶アイテムオブジェクトを含まないようにするステップと,
前記隔離されたアプリケーションに前記フィルタされた一または複数の記憶アイテムオブジェクトを返すステップとを有する,方法。」

なお,本願発明2-8は,本願発明1を減縮した発明である。

第4 原査定の理由について
1.原査定の理由の概要

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

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

●理由1(省略)
●理由2(新規性),理由3(進歩性)について

・請求項:1,2,10
・引用文献等:1
・備考:
引用文献1(特に段落[0008][0037],[0042]?[0044],[0050]?[0059],図3参照)には,オペレーティングシステム上で動作するアプリケーション(本願の「隔離されたアプリケーション」に相当)がファイルに対する動作を実行するコンピュータにより実行される方法であって,
インターセプタモジュール(「ブローカモジュール」に相当)において,前記アプリケーションからシステムコール(「API」に相当)を介して前記ファイルへアクセスする要求を,インターセプトするステップと,
前記アプリケーションが,前記ファイルへのアクセスを許可されているのか拒否されているのかを判断するステップと,
システムコールを拒否すべきであるという判断が行われた場合には,システムコールの実行を拒否するステップと,
実行が許可されているという判断がされた場合には,暗号化されたファイル(「アイテム」に相当)に対してシステムコールを実行する,ステップと,
前記暗号化されたファイルを復号してファイル(「記憶アイテムオブジェクト」に相当)を生成するステップと,
前記ファイルをアプリケーションへ返すステップと,
を有する方法の発明が記載されている。

よって,前記請求項に係る発明は,引用文献1に記載の発明である。
また,前記請求項に係る発明は,引用文献1に記載の発明に基いて,当業者が容易に発明をすることができたものである。

●理由3(進歩性)について
・請求項:3?9
・引用文献:1
・備考:
オペレーティングシステムのシステムコールにおいて,
アクセスするアイテムの特性を読み出すこと,
生成したファイルを記憶させておくこと,
アイテムをフィルタして,特定のアイテムを排除すること,
アイテムを特定の順序で編成すること,
アイテムを特定のグルーピングで編成すること,
アイテムに検索基準を満たすアイテムを含めること等は,当業者が通常行う常套手段である。

よって,前記請求項に係る発明は,引用文献1に記載の発明に基いて,当業者が容易に発明をすることができたものである。

＜引用文献等一覧＞
1.特開2010-134935号公報』

2.原査定の理由の判断

(1)引用文献1について
原査定の拒絶の理由に引用された引用文献1(特開2010-134935号公報)には,図面とともに次の事項が記載されている。(下線は,当審で付したものである。)

(ア)「【請求項1】
オペレーティングシステム上で動作するアプリケーションプログラムがファイルに対する操作を実行するコンピュータにより実行される方法であって,該ファイルは,メタ情報が格納されたヘッダと実ファイルコンテンツとを含むものであり,
前記ファイルにアクセスするために前記アプリケーションプログラムが前記オペレーティングシステムのシステムコールを呼び出すステップと,
インターセプトモジュールが前記システムコールをインターセプトするステップと,
前記インターセプトモジュールが前記ヘッダに格納されたメタ情報を読み出すステップと,
前記メタ情報に基づいて,前記ファイルに対して前記システムコールの実行が許可されるか拒否されるかを判断するステップと,
前記システムコールが許可されると判断された場合には,アクセスされるファイルのファイルポインタを前記ヘッダに相当する量だけ移動させて,前記システムコールが前記実ファイルコンテンツに対して実行されるようにするステップと
を含む方法。」

(イ)「【0056】
実行が許可されているという判断された場合には,処理手順は「ｙeｓ」に導かれる次のステップに進み,ファイルポインタをヘッダの量だけ前進させてから,ヘッダの後に続くファイルデータに対して,変更された方法又は変更されていない方法でシステムコールを実行する。設定されたポリシに基づいて,システムコールの実行を拒否すべきであるという判断が行われた場合には,処理手順は「nｏ」に導かれる次のステップに進み,システムコールの実行を拒否する。この場合には,エラーメッセージが表示されたり,あるいはエラーメッセージのない「サイレント拒否」が行われたりする場合がある。」

(ウ)「【0059】
実施の一形態によれば,当該システムはデータの自動暗号化及び自動復号化を提供する。実施の一形態において,データ記憶媒体に書き込まれるファイルは自動的に暗号化される。つまり,書き込み操作の場合にインターセプタモジュールによって実行されるシステムコールの変更は,実ファイルデータ(actual file data)が書き込まれる前にそれを暗号化することを含むものであり,データが記憶媒体に書き込まれるときにそのデータはヘッダとともに暗号化された形で書き込まれる。実ファイルコンテンツの自動暗号化は,許可されていないアクセスからその実ファイルコンテンツを保護する。ヘッダに定義されたメタ情報又はポリシは,ファイルの復号化が許可される条件を定めることができる。例えば,ある特定のタイプのアプリケーションプログラムが復号化の後のファイルへアクセスできるということを定める場合があり,この場合,そのアプリケーションを発行元とするシステムコールは,実データがそのアプリケーションプログラムへ返される前にその実データが復号化されるように,変更される。他方,呼び出し元のアプリケーションプログラムがメタ情報内にアクセスが許可されているとして定義されていない場合には,復号化は行われず,復号化された形でデータへアクセスすることができない。」

したがって,上記引用文献1には次の発明(以下,「引用発明」という。)が記載されていると認められる。

「オペレーティングシステム上で動作するアプリケーションプログラムがファイルに対する操作を実行するコンピュータにより実行される方法であって,該ファイルは,メタ情報が格納されたヘッダと実ファイルコンテンツとを含むものであり,
前記ファイルにアクセスするために前記アプリケーションプログラムが前記オペレーティングシステムのシステムコールを呼び出すステップと,
インターセプトモジュールが前記システムコールをインターセプトするステップと,
前記インターセプトモジュールが前記ヘッダに格納されたメタ情報を読み出すステップと,
前記メタ情報に基づいて,前記ファイルに対して前記システムコールの実行が許可されるか拒否されるかを判断するステップと,
システムコールの実行を拒否すべきであるという判断が行われた場合には,システムコールの実行を拒否するステップと,
前記システムコールが許可されると判断された場合には,前記システムコールが前記実ファイルコンテンツに対して実行されるようにするステップと
を含み,
実ファイルコンテンツの自動暗号化が行われていて,ヘッダに定義されたメタ情報が,復号化の後のファイルへアクセスできるということを定める場合には,システムコールは,実データがアプリケーションプログラムへ返される前にその実データが復号化されるように,変更されるステップとを有する
方法。」

(2)対比
本願発明1と引用発明とを対比する。

(ア)引用発明の「オペレーティングシステム上で動作するアプリケーションプログラムがファイルに対する操作を実行するコンピュータにより実行される方法」が本願発明1の「コンピューティングデバイスにおける方法」に相当する。

(イ)引用発明の「前記ファイルにアクセスするために前記アプリケーションプログラムが前記オペレーティングシステムのシステムコールを呼び出すステップと,インターセプトモジュールが前記システムコールをインターセプトするステップ」と
本願発明1の「前記ブローカーモジュールにおいて,前記一または複数のAPIを介して,前記隔離されたアプリケーションからの,アイテムソースの一または複数のアイテムにアクセスする要求を受け取るステップ」
とを対比すると,
引用発明の「インターセプトモジュール」「ファイル」が本願発明1の「ブローカーモジュール」「アイテム」に相当し,
また,引用発明の「アプリケーションプログラム」は,インターセプトモジュールを介してのみファイルへアクセスすることができる点で,「隔離されたアプリケーション」であるといえるから,
両者は,後記する点で相違するものの
「前記ブローカーモジュールにおいて,前記隔離されたアプリケーションからの,アイテムソースの一のアイテムにアクセスする要求を受け取るステップ」
である点で共通する。

(ウ)引用発明の「前記インターセプトモジュールが前記ヘッダに格納されたメタ情報を読み出すステップと,前記メタ情報に基づいて,前記ファイルに対して前記システムコールの実行が許可されるか拒否されるかを判断するステップ」と
本願発明1の「前記コンピューティングデバイスにおいて,前記隔離されたアプリケーションが前記一または複数のアイテムのどれにアクセスする許可を受けているかチェックするステップ」
とを対比すると,
両者は,後記する点で相違するものの
「前記コンピューティングデバイスにおいて,前記隔離されたアプリケーションが前記一のアイテムにアクセスする許可を受けているかチェックするステップ」
である点で共通する。

(エ)引用発明の「システムコールの実行を拒否すべきであるという判断が行われた場合には,システムコールの実行を拒否するステップ」と
本願発明1の「前記隔離されたアプリケーションが前記一または複数のアイテムのうちどれにもアクセスする許可を受けていないとき,前記要求を拒絶するステップ」
とを対比すると,
両者は,後記する点で相違するものの
「前記隔離されたアプリケーションが前記一のアイテムにアクセスする許可を受けていないとき,前記要求を拒絶するステップ」
である点で共通する。

(オ)引用発明の「前記システムコールが許可されると判断された場合には,前記システムコールが前記実ファイルコンテンツに対して実行されるようにするステップと
を含み,
実ファイルコンテンツの自動暗号化が行われていて,ヘッダに定義されたメタ情報が,復号化の後のファイルへアクセスできるということを定める場合には,システムコールは,実データがアプリケーションプログラムへ返される前にその実データが復号化されるように,変更されるステップとを有する」と
本願発明1の「許可を受けているとき,
前記隔離されたアプリケーションがアクセスする許可を受けている前記一または複数のアイテムのうちのアイテムを表す一または複数の記憶アイテムオブジェクトを生成するステップと,・・・
前記隔離されたアプリケーションに前記フィルタされた一または複数の記憶アイテムオブジェクトを返すステップとを有する」
とを対比すると,
引用発明の「復号化されたファイル」は実ファイルコンテンツのデータであるから,本願発明1の「記憶アイテムオブジェクト」に相当するといえるので,
両者は,後記する点で相違するものの
「許可を受けているとき,
前記隔離されたアプリケーションがアクセスする許可を受けている前記一のアイテムのうちのアイテムを表す一の記憶アイテムオブジェクトを生成するステップと,前記隔離されたアプリケーションに前記一の記憶アイテムオブジェクトを返すステップとを有する」
点で共通する。

そうすると,本願発明1と引用発明とは,

「コンピューティングデバイスにおける方法であって,
前記ブローカーモジュールにおいて,前記隔離されたアプリケーションからの,アイテムソースの一のアイテムにアクセスする要求を受け取るステップと,
前記コンピューティングデバイスにおいて,前記隔離されたアプリケーションが前記一のアイテムにアクセスする許可を受けているかチェックするステップと,
前記隔離されたアプリケーションが前記一のアイテムにアクセスする許可を受けていないとき,前記要求を拒絶するステップと,
許可を受けているとき,
前記隔離されたアプリケーションがアクセスする許可を受けている前記一のアイテムのうちのアイテムを表す一の記憶アイテムオブジェクトを生成するステップと,前記隔離されたアプリケーションに前記一の記憶アイテムオブジェクトを返すステップとを有する方法。」

の点で一致し,以下の点で相違する。

[相違点1]
アプリケーションがファイルへアクセスする要求を受け取ることに関し,
本願発明1は,「前記コンピューティングデバイスのブローカーモジュールにおいて,前記コンピューティングデバイスの隔離されたアプリケーションに一または複数のアプリケーションプログラミングインタフェース(API)をエクスポーズするステップであって,前記一または複数のAPIは,アイテムへの異なるタイプのアクセスのために前記隔離されたアプリケーションにより起動され得る一または複数のインタフェースをサポートするステップ」を有し,「前記一または複数のAPIを介して」,アプリケーションからの,アイテムソースの一または複数のアイテムにアクセスする要求を受け取るのに対して,引用発明は,そのようなステップが特定されていない点。

[相違点2]
本願発明1では,アプリケーションが複数のアイテムにアクセスすることが想定されており,チェックするステップが,複数のアイテムの「どれ」にアクセスする許可を受けているかをチェックするのに対して,引用発明では,アプリケーションが特定の1つのファイルにアクセスし,判断するステップが,前記特定の1つのファイルに対してシステムコールの実行が許可されるか否かを判断している点。

[相違点3]
本願発明1では,「前記一または複数のアイテムのうちの,前記隔離されたアプリケーションがアクセスする許可を受けているアイテムを表す前記生成された一または複数の記憶アイテムオブジェクトをフィルタするステップであって,あるファイルタイプに対応する一または複数の記憶アイテムオブジェクトを排除して,前記フィルタされた一または複数の記憶アイテムオブジェクトが前記ファイルタイプに対応する記憶アイテムオブジェクトを含まないようにするステップ」を有しており,アプリケーションには,「フィルタされた記憶アイテムオブジェクト」を返すのに対して,引用発明では,そのようなステップは特定されていない点。

(3)判断
上記相違点について検討する。

[相違点1]について
システムコールは,通常,APIを呼び出すことで実行されるものであるから,引用発明において,アプリケーションプログラムがシステムコールに際してAPIを呼び出すようにするために,「前記コンピューティングデバイスのブローカーモジュールにおいて,前記コンピューティングデバイスの隔離されたアプリケーションに一または複数のアプリケーションプログラミングインタフェース(API)をエクスポーズするステップであって,前記一または複数のAPIは,アイテムへの異なるタイプのアクセスのために前記隔離されたアプリケーションにより起動され得る一または複数のインタフェースをサポートするステップ」を設け,「前記一または複数のAPIを介して」,アプリケーションからアイテムにアクセスする要求を受け取るように構成すること,すなわち,上記相違点1に係る構成とすることは当業者が容易に想到し得たことである。

[相違点2]について
引用発明は,アプリケーションが特定の1つのファイルにアクセスする要求を出すと,当該ファイルのヘッダに格納されたメタ情報を参照して,前記アプリケーションが,当該ファイルにアクセスすることを許容するか否かを判断するものであり,引用発明には,アプリケーションが一度に複数のファイルにアクセスすることは想定されていないから,チェックするステップにおいて,複数のファイルの「どれ」にアクセスする許可を受けているかをチェックするように構成する動機付けがなく,そのように構成することが適宜なし得ることであるともいえない。
してみれば,引用発明において,上記相違点2に係る構成とすることは当業者が容易になし得たことであるということはできない。

[相違点3]について
引用発明は,
「前記システムコールが許可されると判断された場合には,前記システムコールが前記実ファイルコンテンツに対して実行されるようにする」ものであり,
さらに,
「実ファイルコンテンツの自動暗号化が行われていて,ヘッダに定義されたメタ情報が,復号化の後のファイルへアクセスできるということを定める場合には,システムコールは,実データがアプリケーションプログラムへ返される前にその実データが復号化されるように,変更される」ものであるから,一旦,システムコールが許可されると判断されれば,自動的に復号化の処理も実行されるものであり,引用発明において,システムコールが許可されると判断され,復号化の処理が実行された後で,さらに,何らか基準に基づいて,ファイルをフィルタする処理が行われるとの記載はない。
また,引用発明において,復号化の処理を行った後に,さらに,「あるファイルタイプに対応する一または複数の記憶アイテムオブジェクトを排除」するための「フィルタするステップ」を設けることが,周知技術であるということもできない。
してみれば,引用発明において,
許可を受けているとき,前記隔離されたアプリケーションがアクセスする許可を受けている前記一または複数のアイテムのうちのアイテムを表す一または複数の記憶アイテムオブジェクトを生成した上で,さらに,前記一または複数のアイテムのうちの,前記隔離されたアプリケーションがアクセスする許可を受けているアイテムを表す前記生成された一または複数の記憶アイテムオブジェクトをフィルタするように構成すること,すなわち,上記相違点3に係る構成とすることは当業者が容易になし得たことであるということはできない。

(4)小括
したがって,本願発明1は,当業者が引用発明に基づいて容易に発明をすることができたとはいえない。

また,本願発明2-8は,本願発明1をさらに減縮したものであるので,同様に,当業者が引用発明に基づいて容易に発明をすることができたとはいえない。

よって,原査定の理由によっては,本願を拒絶することはできない。

第5 当審拒絶理由について
1.当審拒絶理由の概要
『この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第2号に規定する要件を満たしていない。

記

(1)請求項1には,「前記一または複数のアイテムのうちの,前記隔離されたアプリケーションがアクセスする許可を受けているアイテムを表す前記生成された一または複数の記憶アイテムオブジェクトをフィルタするステップであって,あるファイルタイプに対応する一または複数の記憶アイテムオブジェクトを排除して,前記フィルタされる一または複数の記憶アイテムオブジェクトが前記ファイルタイプに対応する記憶アイテムオブジェクトを含まないようにするステップ」と記載されているが,上記記載では,「前記フィルタされる一または複数の記憶アイテムオブジェクト」が,フィルタ動作が行われる前の「フィルタされる一または複数の記憶アイテムオブジェクト」のことであるのか,あるいはフィルタ動作が行われた後の「フィルタされた一または複数の記憶アイテムオブジェクト」であるのかが不明確である。
請求項1の文脈からすると,フィルタ動作が行われた後の「フィルタされた一または複数の記憶アイテムオブジェクト」のことであると認められるので,この点が明確となるように補正されたい。

(2)請求項1には,「前記隔離されたアプリケーションに前記一または複数の記憶アイテムオブジェクトを返すステップ」と記載されているが,審判請求時の補正により,当該ステップの前段に,「前記生成された一または複数の記憶アイテムオブジェクトをフィルタするステップ」が挿入されたので,隔離されたアプリケーションに「返す」記憶アイテムオブジェクトは,「フィルタされた」「一または複数の記憶アイテムオブジェクト」とするべきであると思われる。
この点が明確となるように補正されたい。

拒絶の理由が新たに発見された場合には拒絶の理由が通知される。』

2.当審拒絶理由の判断
(1)平成29年2月1日付け手続補正によって,本願の請求項1は「前記フィルタされた一または複数の記憶アイテムオブジェクト」と補正された。
このことにより,請求項1,及びこれを引用する請求項2-8に係る発明は明確となった。
よって,当審拒絶理由(1)は解消した。

(2)平成29年2月1日付け手続補正によって,本願の請求項1は「前記隔離されたアプリケーションに前記フィルタされた一または複数の記憶アイテムオブジェクトを返すステップ」と補正された。
このことにより,請求項1,及びこれを引用する請求項2-8に係る発明は明確となった。
よって,当審拒絶理由(2)は解消した。

第6 むすび
以上のとおり,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2017-04-04 
出願番号 特願2014-513492(P2014-513492)
審決分類 P 1 8・ 121- WY (G06F)
P 1 8・ 537- WY (G06F)
最終処分 成立  
前審関与審査官 石坂 知樹、脇岡 剛  
特許庁審判長 辻本 泰隆
特許庁審判官 須田 勝巳
高木 進
発明の名称 隔離されたアプリケーションのためのブローカードアイテムアクセス  
代理人 伊東 忠彦  
代理人 伊東 忠重  
代理人 大貫 進介  

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