【事件の表示】
　特願２０１５−５３２３２４「システム制御」拒絶査定不服審判事件〔平成２６年　３月２７日国際公開、ＷＯ２０１４／０４４３７３、平成２７年１１月　２日国内公表、特表２０１５−５３１５１７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、２０１３年９月１３日（パリ条約による優先権主張外国庁受理　２０１２年９月２０日　欧州特許庁）を国際出願日とする出願であって、平成２８年６月１４日付けで拒絶理由が通知され、同年９月１５日付けで手続補正がなされたが、同年１０月３１日付けで拒絶査定がなされ、これに対し、平成２９年３月７日に拒絶査定不服審判の請求がなされると同時に手続補正がなされたものである。
第２．補正却下の決定
［結論］
　　平成２９年３月７日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　平成２９年３月７日付けの手続補正（以下「本件補正」という。）は、平成２８年９月１５日に提出された手続補正書の特許請求の範囲の請求項１に記載された、　
「【請求項１】
　オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御するためにオペレーティングシステムによって行われる方法であって、
システムの重要な変更を行うためのユーザからの要求をカーネル空間で受信するステップと、
前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかをカーネル空間で評価するステップと、
有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに前記受信した要求をカーネル空間で通知するステップと、
前記要求されたシステムの重要な変更を実行する前に、少なくとも１人の前記さらなるユーザから承認を待つステップと
を含む、方法。」
という発明（以下、「本願発明」という。）を、補正後の特許請求の範囲の請求項１に記載された、
「【請求項１】
　オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御するためにオペレーティングシステムによって行われる方法であって、
システムの重要な変更を行うためのユーザからの要求を
、アクセス制御リストの拡張として
前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを
、アクセス制御リストの拡張として
有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに前記受信した要求を
、アクセス制御リストの拡張として
前記要求されたシステムの重要な変更を実行する前に、少なくとも１人の前記さらなるユーザから承認を待つステップと
を含む、方法。」
という発明（以下、「補正後の発明」という。）に変更することを含むものである。（下線は、補正事項を示している。）
　
２．補正の適否
（１）補正の目的要件
　本件補正のうち上記補正事項は、本願発明の特許請求の範囲の請求項１の「カーネル空間で受信する」、「カーネル空間で評価する」、及び「カーネル空間で通知する」ことを、各々、「
アクセス制御リストの拡張として
アクセス制御リストの拡張として
アクセス制御リストの拡張として
　そして、本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてなされたものと認められ、特許法第１７条の２第３項（新規事項）の規定に適合している。
　また、特許法１７条の２第４項（シフト補正）の規定に違反するものでもない。
　
（２）独立特許要件
　本件補正は特許請求の範囲の減縮を目的とするものであるから、補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下検討する。
　　
ア．補正後の発明
 上記「１．本願発明と補正後の発明」の項で、「補正後の発明」として認定したとおりのものである。
　
イ．引用発明
（ア）引用例１
　原査定の拒絶の理由において引用された、「周展飛，他３名，管理者支援システムに関する考察，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会，２００１年１２月　７日，FACE2001-15〜19，p.5-8」（以下、「引用例１」という。）には、図面とともに以下の事項が記載されている。（下線は、当審において付加した。以下同じ。）
　　
ａ．「１．はじめに
　ＤＮＳ，ＷＷＷなどのサービスを提供している計算機ネットワークでは，オペレーティングシステム（ＯＳ）として，その信頼性からＵＮＩＸ系のＯＳが採用されている．
　
ＵＮＩＸ系ＯＳにおいて，スーパーユーザは計算機システムにおけるすべての権限を持っており，そのシステムのあらゆるファイルを変更することが可能である．そのため，管理者の故意または過失によるシステム破壊などの事故が避けられない．
　
そこで本稿では計算機システムを安全に管理するための管理支援グループウェアを提案する
　
具体的には，システムの設定を変更する際に，複数の管理者が同時に操作することにより初めて変更が可能であるように枠組みを設けることで、管理作業を単独で行うことで生じ得る事故や、悪意を持った管理者による意図的な破壊からシステムを守る
　また，管理者の認証や各管理者からの要求の調整の必要性が考えられる．本稿ではこれらの問題点の解決方法についても考察する．」（６頁左欄）
ｂ．「２．従来の管理方法
　２．１　管理者権限
  ネットワークにおけるサーバではさまざまなサービスが行われている．これらのサービスを正常に利用可能な状態に保つため，サービスの保守／管理が必要になる．
　サービスの保守／管理作業は，サービスの設定内容が記述されている設定ファイルを書き換え，それをサービスとして反映させることである．しかし，システムのセキュリティの観点から，設定ファイルは管理者以外の一般の利用者によるアクセスができてはならない．
　
そこでＵＮＩＸ系ＯＳでは，システムの設定に関する重要なファイルについて読出／書込／実行の権限（パーミッション）の制限することにより，システムを破壊から守るようにしている．逆に，管理者には制限されたファイルにアクセスできる権限が与えられている
　ここで留意すべきことは，システム管理者は，破壊することもまた可能であるということである．管理作業のみ許し，破壊行為はできないように権限を制限することはできない．したがって，管理者の故意または過失による事故を防ぐことは困難である．
　２．２　補足：ｓｕｄｏ
　管理者権限を制限するような仕組みとして，ｓｕｄｏがある．設定ファイルに制限／許可する事項を記述し，ｓｕｄｏを介して管理を行わせることで，管理者に与える権限を制限するのである．
　しかし本来ｓｕｄｏは，フロッピーディスクのマウントなど，「一般ユーザに行わせても構わないが管理者権限を必要とする操作」を一般ユーザに一部許すための仕組みであり，安全に管理を行うためのものではない．
　結局ｓｕｄｏは，単独での管理を許すのであるから，本稿で提示する問題点の解決にはならない．
　２．３　管理体制
   システムを一人で管理する場合を考える．このとき，以下のような問題点が考えられる．
・管理者の負荷が大きい
・緊急の際に管理者が不在である可能性が高い
・管理者の行動を誰も監視できない
　これらの問題点を解決するため，一般的には複数の管理者で管理業務を行う．このとき，それぞれの管理者は同等の権限を持つのが通例である．すなわち，それぞれの管理者は単独で管理を行える．
　管理者の人数が増えることにより一人当たりの負担が軽減され，また、緊急の管理業務を行う際も複数の管理者のうち一人がいれば緊急時の対応ができる．さらに管理者はそれぞれ同等の権限を持つため，お互いの行動の監視も不可能ではない．
　このように，複数の管理者で管理を行うことによってシステムの円滑な運用性を確保できる．しかし依然として管理者によるシステム破壊についての可能性は残されている．」（６頁左−右欄）
ｃ．「３．
提案手法
　
本稿では前章で提起した問題を解決し，計算機システムの安全に管理するための管理支援グループウェアを提案する
　これは，
管理用システムプロセスにより，システム管理者が単独ではシステムの設定を変更できないようにするものである
　３．１　
管理デーモンによる管理
　ここで，スーパーユーザの存在しないモデルを想定する．
　このモデルでは，制限されているファイルにアクセスできるユーザが存在しない．すなわち計算機のすべてのユーザは直接には計算機を管理する権限を持たない．
　このモデルにおける
計算機システムでの管理は，管理用システムプロセスを介して行う
このシステムプロセスを以下「管理デーモン」と呼ぶ．
　ここで，計算機システムのユーザを一般ユーザと準スーパーユーザに分ける．準スーパーユーザには，単独ではシステムに問題を引き起こさない範囲の権限のみを与える．
　
このシステムは以下のように動作する．
　（１）　管理者Ａがある操作を行いたいとき，まず管理デーモンとの通信を確立し，リクエストを送る．　
　（２）　管理デーモンはＡから送られてきたリクエストを受け取ると，リクエストの発信者がＡであることを認証する．
　（３）　Ａの認証が正しく行われると，管理デーモンは他の管理者たちにＡからのリクエストがあったことを通知する．
　（４）　他の管理者たちは通知を受け取ると管理デーモンとの通信を確立し，認証を受ける．
　（５）　そしてＡからのリクエストを確認し，それに同意するメッセージを管理デーモンに送る．
　（６）　管理デーモンは受け取ったすべてのメッセージを確認し，一定数以上の同意が得られればＡからのリクエストを実行する．
　以上により，単独のスーパーユーザによる管理システムに残るセキュリティ上の問題を除くことができる．」（６頁右欄−７頁左欄）
　上記引用例１の記載及びこの分野の技術常識を考慮すると、
　                     
（ａ）上記ａ．、及びｂ．には、従来の管理方法の問題として、ＵＮＩＸ系ＯＳでは、単独の管理者にのみ、システムの設定に関する重要なファイルについて変更できる権限が与えられているが、システム管理者は，破壊することもまた可能であるため、管理者の故意または過失による事故を防ぐことが困難である、ということが記載されている。
　また、上記ａ．及びｃ．には、前記の問題を解決するために、システムの設定を変更する際は、複数の管理者が同時に操作することにより初めて変更を可能とするシステムの管理が、さらに、上記ｃ．には、計算機システムでの該管理を、管理用システムプロセスである管理デーモンで行うための管理の手法が記載されている。
　したがって、引用例１には、、ＵＮＩＸ系ＯＳにおいて、システムの設定に関する重要なファイルの変更をする際に、故意または過失によってシステム破壊が起こることを防ぐために、システムの管理用システムプロセスである管理デーモンにより、複数の管理者が同時に操作することにより初めて変更を可能とするための方法、が記載されているといえる。
（ｂ）さらに、上記ｃ．には、計算機システムのユーザを一般ユーザと準スーパーユーザに分ける．準スーパーユーザには，単独ではシステムに問題を引き起こさない範囲の権限のみを与えること、及び、管理デーモンによる動作として、
　（１）　管理者Ａがある操作を行いたいとき，まず管理デーモンとの通信を確立し，リクエストを送る．　
　（２）　管理デーモンはＡから送られてきたリクエストを受け取ると，リクエストの発信者がＡであることを認証する．
　（３）　Ａの認証が正しく行われると，管理デーモンは他の管理者たちにＡからのリクエストがあったことを通知する．
　（４）　他の管理者たちは通知を受け取ると管理デーモンとの通信を確立し，認証を受ける．
　（５）　そしてＡからのリクエストを確認し，それに同意するメッセージを管理デーモンに送る．
　（６）　管理デーモンは受け取ったすべてのメッセージを確認し，一定数以上の同意が得られればＡからのリクエストを実行する．
　ことが記載されており、ここで、「管理者Ａ」、「他の管理者」は、「一般ユーザ」ではないので、「準スーパーユーザ」と認められる。
　したがって、引用例１には、上記方法は、
　ユーザを、一般ユーザと、単独ではシステムに問題を引き起こさない範囲の権限を有する複数の管理者と、にわけるステップと、
　管理者Ａがある操作を行いたいとき、まず管理デーモンとの通信を確立し、リクエストを送るステップと、
　管理デーモンは管理者Ａから送られてきたリクエストを受け取ると、リクエストの発信者が管理者Ａであることを認証するステップと、
　管理者Ａの認証が正しく行われると、管理デーモンは他の管理者たちに管理者Ａからのリクエストがあったことを通知するステップと、
　他の管理者たちは通知を受け取ると管理デーモンとの通信を確立し、認証を受けるステップと、
　そして管理者Ａからのリクエストを確認し、それに同意するメッセージを管理デーモンに送るステップと、
　管理デーモンは受け取ったすべてのメッセージを確認し、一定数以上の同意が得られれば管理者Ａからのリクエストを実行するステップと、からなることが、記載されているといえる。
　
　したがって、引用例１には、次の発明（以下、「引用発明」という。）が開示されていると認められる。
　
　「ＵＮＩＸ系ＯＳにおいて、システムの設定に関する重要なファイルの変更をする際に、故意または過失によってシステム破壊が起こることを防ぐために、システムの管理用システムプロセスである管理デーモンにより、複数の管理者が同時に操作することにより初めて変更を可能とするための方法であって、
　ユーザを、一般ユーザと、単独ではシステムに問題を引き起こさない範囲の権限を有する複数の管理者と、にわけるステップと、
　管理者Ａがある操作を行いたいとき、まず管理デーモンとの通信を確立し、リクエストを送るステップと、
　管理デーモンは管理者Ａから送られてきたリクエストを受け取ると、リクエストの発信者が管理者Ａであることを認証するステップと、
　管理者Ａの認証が正しく行われると、管理デーモンは他の管理者たちに管理者Ａからのリクエストがあったことを通知するステップと、
　他の管理者たちは通知を受け取ると管理デーモンとの通信を確立し、認証を受けるステップと、
　そして管理者Ａからのリクエストを確認し、それに同意するメッセージを管理デーモンに送るステップと、
　管理デーモンは受け取ったすべてのメッセージを確認し、一定数以上の同意が得られれば管理者Ａからのリクエストを実行するステップと、
　からなる方法。」
（イ）引用例２
　本願の優先日前に日本国内において頒布された刊行物である、特開２００２−２６８９４５号（以下、「引用例２」という。）には、図面とともに以下の事項が記載されている。
ａ．「【０００４】
アクセス制御の方式には、
エンティティーがアクセスを許可するためのアクセス権を保持しそのアクセス権の存在によりアクセスが制御される任意アクセス制御がある
【０００５】強制アクセス制御として、階層的セキュリティーレベルを用いる階層アクセス制御、そしてグラフ解析に基づくセキュリティーレベル設定（ＳｅｃｕｒｉｔｙＬｅｖｅｌ  Ａｓｓｉｇｎｍｅｎｔ＝ＳＬＡ）アルゴリズムによって設定される階層的セキュリティーレベルを用いる階層アクセス制御（本願では「ＳＬＡ階層アクセス制御」と略す）が従来から知られており、
任意アクセス制御として、アクセス制御リスト（Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌｉｓｔ＝ＡＣＬ）を用いたアクセス制御（本願では「ＡＣＬアクセス制御」と略す）が知られている
【０００６】
ＡＣＬアクセス制御は、各客体（ファイル）のそれぞれについて、その客体にアクセスできる主体（ユーザ）とそのアクセス権限を特定するものである
【０００７】また、
ＡＣＬアクセス制御は現在多用されている既存のコンピューターのオペレーティングシステム（ＯＳ）にも採用されており、例えばＵＮＩＸ（登録商標）系のオペレーションシステム（以下「ＵＮＩＸ系システム」と略す）には通常、ＡＣＬアクセス制御機能が標準的に備わっている
ｂ．「【００１１】
さらにＡＣＬアクセス制御手段を備えた従来の情報処理システムには、セキュリティーレベルの高い権限の強いユーザーが、セキュリティーレベルの低いユーザーの所有するファイルに対し読み出しと書き込みの両権限を有するものがあるが、この強い権限が悪用された場合に、権限の強い人物によってファイルの改竄を行うことが可能となり、サーバー情報処理システムの内部からのハッキングや誤操作により、システムに大きな損傷が生ずる恐れもある。例えばＵＮＩＸ系システムにおいてセキュリティー上の危険性が高いと考えられる作業の一つに、ルートユーザー（Ｒｏｏｔ  Ｕｓｅｒ）の業務がある。ＵＮＩＸ系システムにおいて、ルートユーザは最大権限者であるが、実務の内容によっては過大なものとなり、その過大な権限の上でシステムの誤操作が生じた場合には、サーバ情報処理システムに致命的な損傷を与える恐れがあり、その予防手段が求められる
（ウ）引用例３
　本願の優先日前に日本国内において頒布された刊行物である、「前川 守，所 真理雄，清水 謙多郎，分散オペレーティングシステム−ＵＮＩＸの次にくるもの，共立出版株式会社，１９９１年１２月２５日，pp.178-179」（以下、「引用例３」という。）には、図面とともに以下の事項が記載されている。
ａ．「１０．２  アクセス制御
１０．２．１   アクセス制御行列
　
アクセス制御において，操作が許されるか許されないかは，各サブジェクトのアクセス権（ａｃｃｅｓｓ ｒｉｇｈｔ），すなわち他のオブジェクトに対して実行可能な操作の集合を指定することによって表わされる．このモデルは，アクセス制御行列（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｍａｔｒｉｘ）と呼ばれる行列で実現することができる（図１０．１）．行列の行はサブジェクト，列はオブジェクトを表わし，各項目には，サブジェクトがオブジェクトに対して行なえる操作の集合が記載される．
　
サブジェクトとしては， プロセスが想定されるが，
一般に，保護ドメイン（ｐｒｏ−ｔｅｃｔｉｏｎ ｄｏｍａｉｎ，以下ドメインと略す）という概念を導入している．ドメインは，実行環境の一種であり，アクセス可能なオブジェクトの集合とこれらのオブジェクトに対して許される操作を規定する．
・・・（中略）・・・
１０．２．３  アクセス制御リスト
　
アクセス制御行列の各列から得られる＜ドメイン，操作＞の対からなるリストをアクセス制御リスト（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔ）という．アクセス制御リストはオブジェクトごとに定義される．
たとえば，ドメインをユーザに対応させ，各ファイルがそれぞれのユーザに許される操作のリストをアクセス制御リストとして保持するシステムが考えられる
　
ＵＮＩＸのファイルシステムは，非常に簡略化されたアクセス制御リスト方式を採用している． ＵＮＩＸ では，所有者，グループ，他のユーザに対して，ファイルの読出し，書込み，実行を指定する．保護ドメインはユーザ（ｕｉｄ）とグループ（ｇｉｄ）の組合せに対応するが，これとは別にスーパーユーザという，システム内のあらゆるオブジェクトへの特権的なアクセスが許されたドメインが存在する．
　上記引用例２、３の記載及び図面、並びにこの分野の技術常識を考慮すると、引用例２または引用例３には以下の技術（以下、「引用例２、３記載の周知の技術」という。）が開示されていると認められる。
「ＵＮＩＸにおけるファイルへのアクセスの制御として、ユーザを一般ユーザや特権ユーザに区分し、区分されたユーザ毎に権限を規定したアクセス制御リストを用いること。」
　
　
ウ．対比・判断
　補正後の発明と引用発明とを対比する。
　
ａ．引用発明の「ＵＮＩＸ系ＯＳ」は、補正後の発明の「オペレーティングシステム」に相当する。
　また、引用発明の「方法」は、「システムの設定に関する重要なファイルについての変更をする際に故意または過失によってシステム破壊が起きることを防ぐため」に「管理デーモン」によって行われるものであって、「重要なファイルについての変更」は重要な変更といえ、さらに、「管理デーモン」は、「システムの管理用システムプロセス」であり、該「管理用システムプロセス」は「ＵＮＩＸ系ＯＳ」上で動作しているものと認められることから、引用発明の「方法」は、補正後の発明の「オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御するためにオペレーティングシステムによって行われる方法」に相当する。
ｂ．引用発明の「認証するステップ」は、「管理者Ａから送られてきたリクエストを受け取る」ステップを含むものであり、「管理者Ａ」は、ユーザと認められ、さらに、「管理者Ａから送られてきたリクエスト」は、「管理者」が「管理デーモン」に送った「ある操作」に関するものであって、「ある操作」は、「システムの設定に関する重要なファイルについての変更」に関する操作であることは明らかであるから、引用発明の「認証するステップ」と、補正後の発明の「システムの重要な変更を行うためのユーザからの要求を、アクセス制御リストの拡張としてカーネル空間で受信する」ステップとは、「システムの重要な変更を行うためのユーザからの要求を、受信するステップ」である点では共通する。
ｃ．さらに、引用発明の「認証するステップ」は、「リクエストの発信者が管理者Ａであることを認証する」ものであって、「管理者」は「複数」が「同意」すれば重要な変更を行う特権を有していることから、引用発明の「認証するステップ」と、補正後の発明の「前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを、アクセス制御リストの拡張としてカーネル空間で評価するステップ」とは、「前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを、評価するステップ」である点では共通する。
ｄ．引用発明の「通知するステップ」は、「管理者Ａの認証が正しく行われると、管理デーモンは他の管理者たちに管理者Ａからのリクエストがあったことを通知する」ものであるから、引用発明の「通知するステップ」と、補正後の発明の「有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに前記受信した要求を、アクセス制御リストの拡張としてカーネル空間で通知するステップ」とは、「有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに前記受信した要求を、通知するステップ」である点では共通する。
ｅ．引用発明の「実行するステップ」は、「管理デーモンは受け取ったすべてのメッセージを確認し、一定数以上の同意が得られれば管理者Ａからのリクエストを実行する」ものであって、引用発明において「実行するステップ」の直前では、「管理デーモン」は、「他の管理者たち」からの「同意」する「メッセージ」を待っているものと認められることから、引用発明の該「待っている」ことは、補正後の発明の「前記要求されたシステムの重要な変更を実行する前に、少なくとも１人の前記さらなるユーザから承認を待つステップ」に相当する。
　
　したがって、補正後の発明と引用発明とを対比すると、両者は、以下の点で一致し、また、相違している。
　
（一致点）
　「オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御するためにオペレーティングシステムによって行われる方法であって、
　システムの重要な変更を行うためのユーザからの要求を、受信するステップと、
　前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを、評価するステップと、
　有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに前記受信した要求を、通知するステップと、
　前記要求されたシステムの重要な変更を実行する前に、少なくとも１人の前記さらなるユーザから承認を待つステップと
を含む、方法。」
 　　
（相違点１）
　一致点の「受信するステップ」、「評価するステップ」、及び「通知するステップ」の各ステップが、補正後の発明では、「アクセス制御リストの拡張としてカーネル空間」で行われるのに対して、引用発明では、そのような特定がされていない点。
　以下、上記相違点１について検討する。
　通常、オペレーティングシステムが、メモリ領域をユーザ空間とカーネル空間とに分けることは周知の事項であり、例えば、拒絶査定時に提示された特表２００９−５３６３７７号公報（段落【０４３１】参照）には「カーネル空間３２０４は、任意のデバイスドライバ、カーネル拡張、またはその他のカーネル関連ソフトウェアを含むカーネル３２３０を実行するために予約されている。当業者は周知しているように、カーネル３２３０は、オペレーティングシステムのコアであり、アプリケーション１２５０のハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理を提供する。」と記載されているように、「カーネル空間」とは、カーネル関連ソフトウェアを含むカーネルを実行するために予約されている領域であり、ハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理を提供するものである。
　また、デーモンについて、拒絶査定時に提示された特表２００９−５３６３７７号公報（段落【０４４５】参照）に「デーモンサービス３２１８は、連続的またはバックグラウンドで実行され、アプライアンス１２５０によって受信される定期的なサービス要求を処理するプログラムである。・・・（中略）・・・。当業者は周知しているように、デーモンサービス３２１８は、操作者が存在しなくても、連続的または定期的にシステム全体の機能、たとえばネットワーク制御を実行するか、または任意の所望のタスクを実行するために動作し得る。実施態様によっては、１つまたは複数のデーモンサービス３２１８はユーザ空間３２０２で実行され、他の実施態様では、１つまたは複数のデーモンサービス３２１８はカーネル空間で実行される。」と記載されているように、デーモンは、実施態様に応じて、ユーザ空間で実行されても、カーネル空間で実行されてもよいものである。
　さらに、上記引用例２、３にも記載されるように、ＵＮＩＸにおけるファイルへのアクセスの制御として、ユーザを一般ユーザや特権ユーザに区分し、区分されたユーザ毎に権限を規定したアクセス制御リストを用いることは、周知の技術である。また、アクセス制御リストにおける、具体的なユーザの区分や、権限の設定は適宜変更可能なものと認められる。
　そうすると、引用発明の管理デーモンは、「ＵＮＩＸ系ＯＳにおいて、システムの設定に関する重要なファイルにつて変更」を行うためのものであるから、重要な変更である、ハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理に関して設置を変更する場合に、「管理デーモンをカーネル空間で実行」し、また、引用発明における「重要なファイル」へのアクセスの制御に、上記周知のアクセス制御リストを適用し、ユーザーとして単独ではシステムに問題を引き起こさない範囲の権限を有する複数の管理者を設定するように拡張することで、「受信するステップ」、「評価するステップ」、及び「通知するステップ」の各ステップを、アクセス制御リストの拡張としてカーネル空間で行うことは、当業者が容易に想到し得たことである。　　　　　
　そして、補正後の発明の作用効果も、引用発明、周知の技術、及び引用例２、３記載の周知の技術に基づいて当業者が予測できる範囲のものである
　　
　したがって、補正後の発明は、引用発明、周知の技術、及び引用例２、３記載の周知の技術に基づいて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許受けることができないものである。
３．結語
　以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである
　
第３．本願発明について
１．本願発明
　平成２９年３月７日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明は上記「第２」の「１．本願発明と補正後の発明」のの項で「本願発明」として認定したとおりである。
　　
２．引用発明
　引用発明等は、上記「第２．補正却下の決定」の項中の「２．補正の適否」の項中の「（２）独立特許要件」の項中の「イ．引用発明」の項で「引用発明」として認定したとおりである。
　 　
３．対比・判断
　そこで、本願発明と引用発明を対比するに、本願発明は上記補正後の発明から当該補正に係る限定を省いたものであって、当該限定は、本願発明の「カーネル空間で受信する」、「カーネル空間で評価する」、及び「カーネル空間で通知する」ことを、各々、「
アクセス制御リストの拡張として
アクセス制御リストの拡張として
アクセス制御リストの拡張として
　したがって、本願発明と引用発明は、上記「第２．補正却下の決定」の項中の「２．補正の適否」の項中の「（２）独立特許要件」の項中の「ウ．対比・判断」の項中の「（一致点）」と同一の点で一致し、以下の点で相違する。　
　
（相違点２）
　一致点の「受信するステップ」、「評価するステップ」、及び「通知するステップ」の各ステップが、補正後の発明では、「カーネル空間」で行われるのに対して、引用発明では、そのような特定がされていない点。
　以下、上記相違点２について検討する。
　通常、オペレーティングシステムが、メモリ領域をユーザ空間とカーネル空間とに分けることは周知の事項であり、例えば、拒絶査定時に提示された特表２００９−５３６３７７号公報（段落【０４３１】参照）には「カーネル空間３２０４は、任意のデバイスドライバ、カーネル拡張、またはその他のカーネル関連ソフトウェアを含むカーネル３２３０を実行するために予約されている。当業者は周知しているように、カーネル３２３０は、オペレーティングシステムのコアであり、アプリケーション１２５０のハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理を提供する。」と記載されているように、「カーネル空間」とは、カーネル関連ソフトウェアを含むカーネルを実行するために予約されている領域であり、ハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理を提供するものである。
　また、デーモンについて、拒絶査定時に提示された特表２００９−５３６３７７号公報（段落【０４４５】参照）に「デーモンサービス３２１８は、連続的またはバックグラウンドで実行され、アプライアンス１２５０によって受信される定期的なサービス要求を処理するプログラムである。・・・（中略）・・・。当業者は周知しているように、デーモンサービス３２１８は、操作者が存在しなくても、連続的または定期的にシステム全体の機能、たとえばネットワーク制御を実行するか、または任意の所望のタスクを実行するために動作し得る。実施態様によっては、１つまたは複数のデーモンサービス３２１８はユーザ空間３２０２で実行され、他の実施態様では、１つまたは複数のデーモンサービス３２１８はカーネル空間で実行される。」と記載されているように、デーモンは、実施態様に応じて、ユーザ空間で実行されても、カーネル空間で実行されてもよいものである。
  そうすると、引用発明の管理デーモンは、「ＵＮＩＸ系ＯＳにおいて、システムの設定に関する重要なファイルについて変更」を行うためのものであるから、重要な変更である、ハードウェアリソースおよびハードウェア関連要素に対するアクセス、これらの制御および管理に関して設置を変更する場合に、「管理デーモンをカーネル空間で実行する」ことは当業者が容易に想到し得た事項である。
　　
４．むすび
　以上のとおり、本願発明は、上記引用発明、及び周知の技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるものである。
　よって、結論のとおり審決する。