• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
管理番号 1336812
審判番号 不服2017-3360  
総通号数 219 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-03-30 
種別 拒絶査定不服の審決 
審判請求日 2017-03-07 
確定日 2018-01-24 
事件の表示 特願2015-532324「システム制御」拒絶査定不服審判事件〔平成26年 3月27日国際公開、WO2014/044373、平成27年11月 2日国内公表、特表2015-531517〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯
本願は、2013年9月13日(パリ条約による優先権主張外国庁受理 2012年9月20日 欧州特許庁)を国際出願日とする出願であって、平成28年6月14日付けで拒絶理由が通知され、同年9月15日付けで手続補正がなされたが、同年10月31日付けで拒絶査定がなされ、これに対し、平成29年3月7日に拒絶査定不服審判の請求がなされると同時に手続補正がなされたものである。

第2.補正却下の決定
[結論]
平成29年3月7日付けの手続補正を却下する。

[理由]
1.本願発明と補正後の発明
平成29年3月7日付けの手続補正(以下「本件補正」という。)は、平成28年9月15日に提出された手続補正書の特許請求の範囲の請求項1に記載された、

「【請求項1】
オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御するためにオペレーティングシステムによって行われる方法であって、
システムの重要な変更を行うためのユーザからの要求をカーネル空間で受信するステップと、
前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかをカーネル空間で評価するステップと、
有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも1人のさらなるユーザに前記受信した要求をカーネル空間で通知するステップと、
前記要求されたシステムの重要な変更を実行する前に、少なくとも1人の前記さらなるユーザから承認を待つステップと
を含む、方法。」

という発明(以下、「本願発明」という。)を、補正後の特許請求の範囲の請求項1に記載された、

「【請求項1】
オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御するためにオペレーティングシステムによって行われる方法であって、
システムの重要な変更を行うためのユーザからの要求を、アクセス制御リストの拡張としてカーネル空間で受信するステップと、
前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを、アクセス制御リストの拡張としてカーネル空間で評価するステップと、
有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも1人のさらなるユーザに前記受信した要求を、アクセス制御リストの拡張としてカーネル空間で通知するステップと、
前記要求されたシステムの重要な変更を実行する前に、少なくとも1人の前記さらなるユーザから承認を待つステップと
を含む、方法。」

という発明(以下、「補正後の発明」という。)に変更することを含むものである。(下線は、補正事項を示している。)

2.補正の適否
(1)補正の目的要件
本件補正のうち上記補正事項は、本願発明の特許請求の範囲の請求項1の「カーネル空間で受信する」、「カーネル空間で評価する」、及び「カーネル空間で通知する」ことを、各々、「アクセス制御リストの拡張としてカーネル空間で受信する」、「アクセス制御リストの拡張としてカーネル空間で評価する」、及び「アクセス制御リストの拡張としてカーネル空間で通知する」として限定したものであり、特許法第17条の2第5項第2号にいう特許請求の範囲の減縮を目的とするものに該当する。
そして、本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてなされたものと認められ、特許法第17条の2第3項(新規事項)の規定に適合している。
また、特許法17条の2第4項(シフト補正)の規定に違反するものでもない。

(2)独立特許要件
本件補正は特許請求の範囲の減縮を目的とするものであるから、補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下検討する。

ア.補正後の発明
上記「1.本願発明と補正後の発明」の項で、「補正後の発明」として認定したとおりのものである。

イ.引用発明
(ア)引用例1
原査定の拒絶の理由において引用された、「周展飛,他3名,管理者支援システムに関する考察,電子情報通信学会技術研究報告,日本,社団法人電子情報通信学会,2001年12月 7日,FACE2001-15?19,p.5-8」(以下、「引用例1」という。)には、図面とともに以下の事項が記載されている。(下線は、当審において付加した。以下同じ。)

a.「1.はじめに
DNS,WWWなどのサービスを提供している計算機ネットワークでは,オペレーティングシステム(OS)として,その信頼性からUNIX系のOSが採用されている.
UNIX系OSにおいて,スーパーユーザは計算機システムにおけるすべての権限を持っており,そのシステムのあらゆるファイルを変更することが可能である.そのため,管理者の故意または過失によるシステム破壊などの事故が避けられない.
そこで本稿では計算機システムを安全に管理するための管理支援グループウェアを提案する.
具体的には,システムの設定を変更する際に,複数の管理者が同時に操作することにより初めて変更が可能であるように枠組みを設けることで、管理作業を単独で行うことで生じ得る事故や、悪意を持った管理者による意図的な破壊からシステムを守る.
また,管理者の認証や各管理者からの要求の調整の必要性が考えられる.本稿ではこれらの問題点の解決方法についても考察する.」(6頁左欄)

b.「2.従来の管理方法
2.1 管理者権限
ネットワークにおけるサーバではさまざまなサービスが行われている.これらのサービスを正常に利用可能な状態に保つため,サービスの保守/管理が必要になる.
サービスの保守/管理作業は,サービスの設定内容が記述されている設定ファイルを書き換え,それをサービスとして反映させることである.しかし,システムのセキュリティの観点から,設定ファイルは管理者以外の一般の利用者によるアクセスができてはならない.
そこでUNIX系OSでは,システムの設定に関する重要なファイルについて読出/書込/実行の権限(パーミッション)の制限することにより,システムを破壊から守るようにしている.逆に,管理者には制限されたファイルにアクセスできる権限が与えられている.
ここで留意すべきことは,システム管理者は,破壊することもまた可能であるということである.管理作業のみ許し,破壊行為はできないように権限を制限することはできない.したがって,管理者の故意または過失による事故を防ぐことは困難である.
2.2 補足:sudo
管理者権限を制限するような仕組みとして,sudoがある.設定ファイルに制限/許可する事項を記述し,sudoを介して管理を行わせることで,管理者に与える権限を制限するのである.
しかし本来sudoは,フロッピーディスクのマウントなど,「一般ユーザに行わせても構わないが管理者権限を必要とする操作」を一般ユーザに一部許すための仕組みであり,安全に管理を行うためのものではない.
結局sudoは,単独での管理を許すのであるから,本稿で提示する問題点の解決にはならない.
2.3 管理体制
システムを一人で管理する場合を考える.このとき,以下のような問題点が考えられる.
・管理者の負荷が大きい
・緊急の際に管理者が不在である可能性が高い
・管理者の行動を誰も監視できない
これらの問題点を解決するため,一般的には複数の管理者で管理業務を行う.このとき,それぞれの管理者は同等の権限を持つのが通例である.すなわち,それぞれの管理者は単独で管理を行える.
管理者の人数が増えることにより一人当たりの負担が軽減され,また、緊急の管理業務を行う際も複数の管理者のうち一人がいれば緊急時の対応ができる.さらに管理者はそれぞれ同等の権限を持つため,お互いの行動の監視も不可能ではない.
このように,複数の管理者で管理を行うことによってシステムの円滑な運用性を確保できる.しかし依然として管理者によるシステム破壊についての可能性は残されている.」(6頁左-右欄)

c.「3.提案手法
本稿では前章で提起した問題を解決し,計算機システムの安全に管理するための管理支援グループウェアを提案する.
これは,管理用システムプロセスにより,システム管理者が単独ではシステムの設定を変更できないようにするものである.
3.1 管理デーモンによる管理
ここで,スーパーユーザの存在しないモデルを想定する.
このモデルでは,制限されているファイルにアクセスできるユーザが存在しない.すなわち計算機のすべてのユーザは直接には計算機を管理する権限を持たない.
このモデルにおける計算機システムでの管理は,管理用システムプロセスを介して行う.このプロセスはスーパーユーザの権限で実行される.このシステムプロセスを以下「管理デーモン」と呼ぶ.
ここで,計算機システムのユーザを一般ユーザと準スーパーユーザに分ける.準スーパーユーザには,単独ではシステムに問題を引き起こさない範囲の権限のみを与える.
このシステムは以下のように動作する.
(1) 管理者Aがある操作を行いたいとき,まず管理デーモンとの通信を確立し,リクエストを送る.
(2) 管理デーモンはAから送られてきたリクエストを受け取ると,リクエストの発信者がAであることを認証する.
(3) Aの認証が正しく行われると,管理デーモンは他の管理者たちにAからのリクエストがあったことを通知する.
(4) 他の管理者たちは通知を受け取ると管理デーモンとの通信を確立し,認証を受ける.
(5) そしてAからのリクエストを確認し,それに同意するメッセージを管理デーモンに送る.
(6) 管理デーモンは受け取ったすべてのメッセージを確認し,一定数以上の同意が得られればAからのリクエストを実行する.
以上により,単独のスーパーユーザによる管理システムに残るセキュリティ上の問題を除くことができる.」(6頁右欄-7頁左欄)

上記引用例1の記載及びこの分野の技術常識を考慮すると、

(a)上記a.、及びb.には、従来の管理方法の問題として、UNIX系OSでは、単独の管理者にのみ、システムの設定に関する重要なファイルについて変更できる権限が与えられているが、システム管理者は,破壊することもまた可能であるため、管理者の故意または過失による事故を防ぐことが困難である、ということが記載されている。
また、上記a.及びc.には、前記の問題を解決するために、システムの設定を変更する際は、複数の管理者が同時に操作することにより初めて変更を可能とするシステムの管理が、さらに、上記c.には、計算機システムでの該管理を、管理用システムプロセスである管理デーモンで行うための管理の手法が記載されている。
したがって、引用例1には、、UNIX系OSにおいて、システムの設定に関する重要なファイルの変更をする際に、故意または過失によってシステム破壊が起こることを防ぐために、システムの管理用システムプロセスである管理デーモンにより、複数の管理者が同時に操作することにより初めて変更を可能とするための方法、が記載されているといえる。
(b)さらに、上記c.には、計算機システムのユーザを一般ユーザと準スーパーユーザに分ける.準スーパーユーザには,単独ではシステムに問題を引き起こさない範囲の権限のみを与えること、及び、管理デーモンによる動作として、
(1) 管理者Aがある操作を行いたいとき,まず管理デーモンとの通信を確立し,リクエストを送る.
(2) 管理デーモンはAから送られてきたリクエストを受け取ると,リクエストの発信者がAであることを認証する.
(3) Aの認証が正しく行われると,管理デーモンは他の管理者たちにAからのリクエストがあったことを通知する.
(4) 他の管理者たちは通知を受け取ると管理デーモンとの通信を確立し,認証を受ける.
(5) そしてAからのリクエストを確認し,それに同意するメッセージを管理デーモンに送る.
(6) 管理デーモンは受け取ったすべてのメッセージを確認し,一定数以上の同意が得られればAからのリクエストを実行する.
ことが記載されており、ここで、「管理者A」、「他の管理者」は、「一般ユーザ」ではないので、「準スーパーユーザ」と認められる。
したがって、引用例1には、上記方法は、
ユーザを、一般ユーザと、単独ではシステムに問題を引き起こさない範囲の権限を有する複数の管理者と、にわけるステップと、
管理者Aがある操作を行いたいとき、まず管理デーモンとの通信を確立し、リクエストを送るステップと、
管理デーモンは管理者Aから送られてきたリクエストを受け取ると、リクエストの発信者が管理者Aであることを認証するステップと、
管理者Aの認証が正しく行われると、管理デーモンは他の管理者たちに管理者Aからのリクエストがあったことを通知するステップと、
他の管理者たちは通知を受け取ると管理デーモンとの通信を確立し、認証を受けるステップと、
そして管理者Aからのリクエストを確認し、それに同意するメッセージを管理デーモンに送るステップと、
管理デーモンは受け取ったすべてのメッセージを確認し、一定数以上の同意が得られれば管理者Aからのリクエストを実行するステップと、からなることが、記載されているといえる。

したがって、引用例1には、次の発明(以下、「引用発明」という。)が開示されていると認められる。

「UNIX系OSにおいて、システムの設定に関する重要なファイルの変更をする際に、故意または過失によってシステム破壊が起こることを防ぐために、システムの管理用システムプロセスである管理デーモンにより、複数の管理者が同時に操作することにより初めて変更を可能とするための方法であって、
ユーザを、一般ユーザと、単独ではシステムに問題を引き起こさない範囲の権限を有する複数の管理者と、にわけるステップと、
管理者Aがある操作を行いたいとき、まず管理デーモンとの通信を確立し、リクエストを送るステップと、
管理デーモンは管理者Aから送られてきたリクエストを受け取ると、リクエストの発信者が管理者Aであることを認証するステップと、
管理者Aの認証が正しく行われると、管理デーモンは他の管理者たちに管理者Aからのリクエストがあったことを通知するステップと、
他の管理者たちは通知を受け取ると管理デーモンとの通信を確立し、認証を受けるステップと、
そして管理者Aからのリクエストを確認し、それに同意するメッセージを管理デーモンに送るステップと、
管理デーモンは受け取ったすべてのメッセージを確認し、一定数以上の同意が得られれば管理者Aからのリクエストを実行するステップと、
からなる方法。」

(イ)引用例2
本願の優先日前に日本国内において頒布された刊行物である、特開2002-268945号(以下、「引用例2」という。)には、図面とともに以下の事項が記載されている。

a.「【0004】アクセス制御の方式には、エンティティーの全てにセキュリティーレベルを割り当てこのセキュリティーレベルに対応したアクセスが実行される強制アクセス制御と、エンティティーがアクセスを許可するためのアクセス権を保持しそのアクセス権の存在によりアクセスが制御される任意アクセス制御がある。
【0005】強制アクセス制御として、階層的セキュリティーレベルを用いる階層アクセス制御、そしてグラフ解析に基づくセキュリティーレベル設定(SecurityLevel Assignment=SLA)アルゴリズムによって設定される階層的セキュリティーレベルを用いる階層アクセス制御(本願では「SLA階層アクセス制御」と略す)が従来から知られており、任意アクセス制御として、アクセス制御リスト(Access Control List=ACL)を用いたアクセス制御(本願では「ACLアクセス制御」と略す)が知られている。
【0006】ACLアクセス制御は、各客体(ファイル)のそれぞれについて、その客体にアクセスできる主体(ユーザ)とそのアクセス権限を特定するものである。したがって、ACLアクセス制御はファイル単位の細かなアクセス制御指定が可能である反面、アクセス権の設定量はファイル数に比例して増加するため、アクセス権の設定作業は容易ではない。
【0007】また、ACLアクセス制御は現在多用されている既存のコンピューターのオペレーティングシステム(OS)にも採用されており、例えばUNIX(登録商標)系のオペレーションシステム(以下「UNIX系システム」と略す)には通常、ACLアクセス制御機能が標準的に備わっている。」

b.「【0011】さらにACLアクセス制御手段を備えた従来の情報処理システムには、セキュリティーレベルの高い権限の強いユーザーが、セキュリティーレベルの低いユーザーの所有するファイルに対し読み出しと書き込みの両権限を有するものがあるが、この強い権限が悪用された場合に、権限の強い人物によってファイルの改竄を行うことが可能となり、サーバー情報処理システムの内部からのハッキングや誤操作により、システムに大きな損傷が生ずる恐れもある。例えばUNIX系システムにおいてセキュリティー上の危険性が高いと考えられる作業の一つに、ルートユーザー(Root User)の業務がある。UNIX系システムにおいて、ルートユーザは最大権限者であるが、実務の内容によっては過大なものとなり、その過大な権限の上でシステムの誤操作が生じた場合には、サーバ情報処理システムに致命的な損傷を与える恐れがあり、その予防手段が求められる。」

(ウ)引用例3
本願の優先日前に日本国内において頒布された刊行物である、「前川 守,所 真理雄,清水 謙多郎,分散オペレーティングシステム-UNIXの次にくるもの,共立出版株式会社,1991年12月25日,pp.178-179」(以下、「引用例3」という。)には、図面とともに以下の事項が記載されている。

a.「10.2 アクセス制御
10.2.1 アクセス制御行列
アクセス制御において,操作が許されるか許されないかは,各サブジェクトのアクセス権(access right),すなわち他のオブジェクトに対して実行可能な操作の集合を指定することによって表わされる.このモデルは,アクセス制御行列(access control matrix)と呼ばれる行列で実現することができる(図10.1).行列の行はサブジェクト,列はオブジェクトを表わし,各項目には,サブジェクトがオブジェクトに対して行なえる操作の集合が記載される.
サブジェクトとしては, プロセスが想定されるが,(1)プロセスのアクセス権は動的に変わりうる,(2)複数のプロセスが同一のアクセス権をもつことがある,などの局面を考えて,一般に,保護ドメイン(pro-tection domain,以下ドメインと略す)という概念を導入している.ドメインは,実行環境の一種であり,アクセス可能なオブジェクトの集合とこれらのオブジェクトに対して許される操作を規定する.命令の実行モード(特権モードと非特権モード)は非常に簡単なドメインの例である.これは,ユーザプログラム(非特権モードで実行される)からカーネル(特権モードで実行される)を保護する.現実には,さらに細かいドメインの指定が行なわれることがある.Hydra [Wulf 81]では手続きがドメインに対応しており,この場合は手続き呼出しによってドメインの切替えが生じる.
・・・(中略)・・・
10.2.3 アクセス制御リスト
アクセス制御行列の各列から得られる<ドメイン,操作>の対からなるリストをアクセス制御リスト(access control list)という.アクセス制御リストはオブジェクトごとに定義される.ドメインDに存在するプロセスがオブジェクトOに操作Pを実行しようとするときは,オブジェクトOのアクセス制御リスト<D,P_(k)>を探索する.もし,P∈P_(k)を満足する項目が見つかるとアクセスは許可され,そうでなければアクセスは拒否される.たとえば,ドメインをユーザに対応させ,各ファイルがそれぞれのユーザに許される操作のリストをアクセス制御リストとして保持するシステムが考えられる.
UNIXのファイルシステムは,非常に簡略化されたアクセス制御リスト方式を採用している. UNIX では,所有者,グループ,他のユーザに対して,ファイルの読出し,書込み,実行を指定する.保護ドメインはユーザ(uid)とグループ(gid)の組合せに対応するが,これとは別にスーパーユーザという,システム内のあらゆるオブジェクトへの特権的なアクセスが許されたドメインが存在する.ドメインの切替えは,ログイン/ログアウトが基本である.ただし,セットID機構によって,ファイルの実行プロセスのユーザもしくはグループが一時的にファイルの所有者に切り替わることができる.アクセス制御リストを用いた分散オペレーティングシステムとしてSpriteやV-System, LOCUSがあるが,これらのシステムはUNIXとほぼ同様の機構を実現している.」(178-179頁)

上記引用例2、3の記載及び図面、並びにこの分野の技術常識を考慮すると、引用例2または引用例3には以下の技術(以下、「引用例2、3記載の周知の技術」という。)が開示されていると認められる。

「UNIXにおけるファイルへのアクセスの制御として、ユーザを一般ユーザや特権ユーザに区分し、区分されたユーザ毎に権限を規定したアクセス制御リストを用いること。」


ウ.対比・判断
補正後の発明と引用発明とを対比する。

a.引用発明の「UNIX系OS」は、補正後の発明の「オペレーティングシステム」に相当する。
また、引用発明の「方法」は、「システムの設定に関する重要なファイルについての変更をする際に故意または過失によってシステム破壊が起きることを防ぐため」に「管理デーモン」によって行われるものであって、「重要なファイルについての変更」は重要な変更といえ、さらに、「管理デーモン」は、「システムの管理用システムプロセス」であり、該「管理用システムプロセス」は「UNIX系OS」上で動作しているものと認められることから、引用発明の「方法」は、補正後の発明の「オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御するためにオペレーティングシステムによって行われる方法」に相当する。
b.引用発明の「認証するステップ」は、「管理者Aから送られてきたリクエストを受け取る」ステップを含むものであり、「管理者A」は、ユーザと認められ、さらに、「管理者Aから送られてきたリクエスト」は、「管理者」が「管理デーモン」に送った「ある操作」に関するものであって、「ある操作」は、「システムの設定に関する重要なファイルについての変更」に関する操作であることは明らかであるから、引用発明の「認証するステップ」と、補正後の発明の「システムの重要な変更を行うためのユーザからの要求を、アクセス制御リストの拡張としてカーネル空間で受信する」ステップとは、「システムの重要な変更を行うためのユーザからの要求を、受信するステップ」である点では共通する。
c.さらに、引用発明の「認証するステップ」は、「リクエストの発信者が管理者Aであることを認証する」ものであって、「管理者」は「複数」が「同意」すれば重要な変更を行う特権を有していることから、引用発明の「認証するステップ」と、補正後の発明の「前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを、アクセス制御リストの拡張としてカーネル空間で評価するステップ」とは、「前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを、評価するステップ」である点では共通する。
d.引用発明の「通知するステップ」は、「管理者Aの認証が正しく行われると、管理デーモンは他の管理者たちに管理者Aからのリクエストがあったことを通知する」ものであるから、引用発明の「通知するステップ」と、補正後の発明の「有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも1人のさらなるユーザに前記受信した要求を、アクセス制御リストの拡張としてカーネル空間で通知するステップ」とは、「有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも1人のさらなるユーザに前記受信した要求を、通知するステップ」である点では共通する。
e.引用発明の「実行するステップ」は、「管理デーモンは受け取ったすべてのメッセージを確認し、一定数以上の同意が得られれば管理者Aからのリクエストを実行する」ものであって、引用発明において「実行するステップ」の直前では、「管理デーモン」は、「他の管理者たち」からの「同意」する「メッセージ」を待っているものと認められることから、引用発明の該「待っている」ことは、補正後の発明の「前記要求されたシステムの重要な変更を実行する前に、少なくとも1人の前記さらなるユーザから承認を待つステップ」に相当する。

したがって、補正後の発明と引用発明とを対比すると、両者は、以下の点で一致し、また、相違している。

(一致点)
「オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御するためにオペレーティングシステムによって行われる方法であって、
システムの重要な変更を行うためのユーザからの要求を、受信するステップと、
前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを、評価するステップと、
有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも1人のさらなるユーザに前記受信した要求を、通知するステップと、
前記要求されたシステムの重要な変更を実行する前に、少なくとも1人の前記さらなるユーザから承認を待つステップと
を含む、方法。」

(相違点1)
一致点の「受信するステップ」、「評価するステップ」、及び「通知するステップ」の各ステップが、補正後の発明では、「アクセス制御リストの拡張としてカーネル空間」で行われるのに対して、引用発明では、そのような特定がされていない点。

以下、上記相違点1について検討する。
通常、オペレーティングシステムが、メモリ領域をユーザ空間とカーネル空間とに分けることは周知の事項であり、例えば、拒絶査定時に提示された特表2009-536377号公報(段落【0431】参照)には「カーネル空間3204は、任意のデバイスドライバ、カーネル拡張、またはその他のカーネル関連ソフトウェアを含むカーネル3230を実行するために予約されている。当業者は周知しているように、カーネル3230は、オペレーティングシステムのコアであり、アプリケーション1250のハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理を提供する。」と記載されているように、「カーネル空間」とは、カーネル関連ソフトウェアを含むカーネルを実行するために予約されている領域であり、ハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理を提供するものである。
また、デーモンについて、拒絶査定時に提示された特表2009-536377号公報(段落【0445】参照)に「デーモンサービス3218は、連続的またはバックグラウンドで実行され、アプライアンス1250によって受信される定期的なサービス要求を処理するプログラムである。・・・(中略)・・・。当業者は周知しているように、デーモンサービス3218は、操作者が存在しなくても、連続的または定期的にシステム全体の機能、たとえばネットワーク制御を実行するか、または任意の所望のタスクを実行するために動作し得る。実施態様によっては、1つまたは複数のデーモンサービス3218はユーザ空間3202で実行され、他の実施態様では、1つまたは複数のデーモンサービス3218はカーネル空間で実行される。」と記載されているように、デーモンは、実施態様に応じて、ユーザ空間で実行されても、カーネル空間で実行されてもよいものである。
さらに、上記引用例2、3にも記載されるように、UNIXにおけるファイルへのアクセスの制御として、ユーザを一般ユーザや特権ユーザに区分し、区分されたユーザ毎に権限を規定したアクセス制御リストを用いることは、周知の技術である。また、アクセス制御リストにおける、具体的なユーザの区分や、権限の設定は適宜変更可能なものと認められる。
そうすると、引用発明の管理デーモンは、「UNIX系OSにおいて、システムの設定に関する重要なファイルにつて変更」を行うためのものであるから、重要な変更である、ハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理に関して設置を変更する場合に、「管理デーモンをカーネル空間で実行」し、また、引用発明における「重要なファイル」へのアクセスの制御に、上記周知のアクセス制御リストを適用し、ユーザーとして単独ではシステムに問題を引き起こさない範囲の権限を有する複数の管理者を設定するように拡張することで、「受信するステップ」、「評価するステップ」、及び「通知するステップ」の各ステップを、アクセス制御リストの拡張としてカーネル空間で行うことは、当業者が容易に想到し得たことである。
そして、補正後の発明の作用効果も、引用発明、周知の技術、及び引用例2、3記載の周知の技術に基づいて当業者が予測できる範囲のものである

したがって、補正後の発明は、引用発明、周知の技術、及び引用例2、3記載の周知の技術に基づいて、当業者が容易に発明することができたものであるから、特許法第29条第2項の規定により、特許出願の際独立して特許受けることができないものである。

3.結語
以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので、同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである


第3.本願発明について
1.本願発明
平成29年3月7日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明は上記「第2」の「1.本願発明と補正後の発明」のの項で「本願発明」として認定したとおりである。

2.引用発明
引用発明等は、上記「第2.補正却下の決定」の項中の「2.補正の適否」の項中の「(2)独立特許要件」の項中の「イ.引用発明」の項で「引用発明」として認定したとおりである。

3.対比・判断
そこで、本願発明と引用発明を対比するに、本願発明は上記補正後の発明から当該補正に係る限定を省いたものであって、当該限定は、本願発明の「カーネル空間で受信する」、「カーネル空間で評価する」、及び「カーネル空間で通知する」ことを、各々、「アクセス制御リストの拡張としてカーネル空間で受信する」、「アクセス制御リストの拡張としてカーネル空間で評価する」、及び「アクセス制御リストの拡張としてカーネル空間で通知する」として限定したものであって、上記「第2.補正却下の決定」の項中の「2.補正の適否」の項中の「(2)独立特許要件」の項中の「ウ.対比・判断」の項で検討した「(相違点1)」に含まれるものである。
したがって、本願発明と引用発明は、上記「第2.補正却下の決定」の項中の「2.補正の適否」の項中の「(2)独立特許要件」の項中の「ウ.対比・判断」の項中の「(一致点)」と同一の点で一致し、以下の点で相違する。

(相違点2)
一致点の「受信するステップ」、「評価するステップ」、及び「通知するステップ」の各ステップが、補正後の発明では、「カーネル空間」で行われるのに対して、引用発明では、そのような特定がされていない点。

以下、上記相違点2について検討する。
通常、オペレーティングシステムが、メモリ領域をユーザ空間とカーネル空間とに分けることは周知の事項であり、例えば、拒絶査定時に提示された特表2009-536377号公報(段落【0431】参照)には「カーネル空間3204は、任意のデバイスドライバ、カーネル拡張、またはその他のカーネル関連ソフトウェアを含むカーネル3230を実行するために予約されている。当業者は周知しているように、カーネル3230は、オペレーティングシステムのコアであり、アプリケーション1250のハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理を提供する。」と記載されているように、「カーネル空間」とは、カーネル関連ソフトウェアを含むカーネルを実行するために予約されている領域であり、ハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理を提供するものである。
また、デーモンについて、拒絶査定時に提示された特表2009-536377号公報(段落【0445】参照)に「デーモンサービス3218は、連続的またはバックグラウンドで実行され、アプライアンス1250によって受信される定期的なサービス要求を処理するプログラムである。・・・(中略)・・・。当業者は周知しているように、デーモンサービス3218は、操作者が存在しなくても、連続的または定期的にシステム全体の機能、たとえばネットワーク制御を実行するか、または任意の所望のタスクを実行するために動作し得る。実施態様によっては、1つまたは複数のデーモンサービス3218はユーザ空間3202で実行され、他の実施態様では、1つまたは複数のデーモンサービス3218はカーネル空間で実行される。」と記載されているように、デーモンは、実施態様に応じて、ユーザ空間で実行されても、カーネル空間で実行されてもよいものである。
そうすると、引用発明の管理デーモンは、「UNIX系OSにおいて、システムの設定に関する重要なファイルについて変更」を行うためのものであるから、重要な変更である、ハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理に関して設置を変更する場合に、「管理デーモンをカーネル空間で実行する」ことは当業者が容易に想到し得た事項である。

4.むすび
以上のとおり、本願発明は、上記引用発明、及び周知の技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条2項の規定により特許を受けることができない。

したがって、本願は、他の請求項について検討するまでもなく、拒絶されるものである。

よって、結論のとおり審決する。
 
審理終結日 2017-08-24 
結審通知日 2017-08-29 
審決日 2017-09-12 
出願番号 特願2015-532324(P2015-532324)
審決分類 P 1 8・ 575- Z (G06F)
P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 小林 義晴  
特許庁審判長 高瀬 勤
特許庁審判官 千葉 輝久
山澤 宏
発明の名称 システム制御  
代理人 特許業務法人川口國際特許事務所  

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