【事件の表示】
　特願２００８−５３０３０５「装置管理において、スケジューリング・タスクを処理するための方法およびシステム」拒絶査定不服審判事件〔平成１９年　５月１８日国際公開、ＷＯ２００７／０５４０１３、平成２１年　２月２６日国内公表、特表２００９−５０８２４１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　
　本願は，２００６年１１月６日（パリ条約による優先権主張外国庁受理２００５年１１月１０日　中国）を国際出願日とする出願であって，
平成１９年１２月２０日付けで特許法第１８４条の５第１項の規定による書面が提出され，
平成２０年２月７日付けで特許法第１８４条の４第１項の規定による明細書，特許請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出され，
同年３月１７日付けで審査請求がなされるとともに，同日付けで手続補正がなされ，
平成２２年８月６日付けで拒絶理由通知（同年同月１７日発送）がなされ，
同年１１月２４日付けで意見書が提出されるとともに，同日付けで手続補正がなされ，
平成２３年１月５日付けで拒絶理由通知（同年同月１１日発送）がなされ，
同年４月７日付けで意見書が提出されるとともに，同日付けで手続補正がなされたが，
同年５月１８日付けで拒絶査定（同年同月２４日謄本送達）がなされ，
同年９月２６日付けで審判請求がされるとともに，同日付けで手続補正がなされ，
同年１２月５日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，
平成２４年２月２日付けで当審により特許法第１３４条第４項の規定に基づく審尋（同年同月７日発送）がなされ，
同年６月７日付けで回答書の提出があったものである。
　
　その後，当審において上記平成２５年４月１１日付けで前記平成２３年９月２６日付け手続補正を却下する旨の補正の却下の決定（平成２５年４月２３日発送）がなされるとともに，平成２５年４月１１日付けで拒絶理由通知（同年同月１６日発送）がなされ，
平成２５年７月５日付けで意見書が提出されるとともに，同日付けで手続補正がなされたのであって，
　その請求項１に係る発明は，平成２５年７月５日付け手続補正書によって補正された特許請求の範囲の請求項１に記載されたとおりの次のものと認める。
　
「装置管理において，スケジューリング・タスクを処理する方法であって，
　上記方法は，装置管理サーバから端末へ配信された装置管理の処理タスクの処理に適合するものであり，
　装置管理サーバから配信された上記装置管理のスケジューリング・タスクを端末にて受信し，
　上記端末が，上記装置管理の上記スケジューリング・タスクの実行条件および上記装置管理サーバによって配信された上記装置管理の上記スケジューリング・タスクのタスク追跡ポリシーに基づいて，上記装置管理の上記スケジューリング・タスクを追跡し，
　上記端末が，上記タスク追跡ポリシーに基づいて，追跡情報を上記装置管理サーバに報告し，
　上記タスク追跡ポリシーは，タスクの実行条件が見過ごされ，上記端末が正常実行しなかった場合，上記端末が，上記装置管理サーバに通知する処理を含むことを特徴とする方法。」
　
２．当審の拒絶理由
　当審による，平成２５年４月１１日付けの拒絶理由通知は，概略，以下のとおりである。
　
『（理由１）
　本件出願は，明細書及び特許請求の範囲の記載が下記の点で不備のため，特許法第３６条第４項第１号及び第６項第２号に規定する要件を満たしていない。
　
　１．請求項１に記載の「スケジューリング・タスクの実行条件」及び「タスク追跡ポリシー」が，具体的にどのようなものを指し，またどのような具体的態様で実現されているのか不明確であり，詳細な説明の記載を参酌しても把握できない。（第３６条第６項第２号）
　
　また，当該「スケジューリング・タスクの実行条件」及び「タスク追跡ポリシー」との記載に関し，「スケジューリング・タスクの実行条件」及び「タスク追跡ポリシー」を，具体的にどのような態様で実現しているのかについて，発明の詳細な説明には対応する明確な記載がなく，したがって発明の詳細な説明は，当業者が実施できる程度に明確かつ十分に記載したものではない。
　
・・・（中略）・・・　　
　
　同様に，「タスク追跡ポリシー」についても，発明の詳細な説明に，
　
「装置管理サーバは，上記タスク処理の特徴に基づいた
タスク追跡ポリシーを生成
タスク追跡ポリシー
　
「ステップＣ１　上記端末は，自端末のタスク処理を追跡するために，タスク処理の上記実行条件（すなわち，実行のトリガとなる条件）および上記
タスク追跡ポリシー
　
　等の記載があるが，いずれもタスク追跡ポリシーの具体的な態様についての記載はなく，タスク追跡ポリシーが具体的にどのような内容及び形態のデータであり，端末においてタスク追跡ポリシーを具体的にどのように処理することでタスクの追跡を実現しているのか，何ら記載されていない。（第３６条第４項第１号）
（当審注：上記第３６条第４項第１号として指摘している事項は，発明の詳細な説明の記載に対するものであり，特許請求の範囲の記載に対するものではない点に留意の上，意見等されたい。以下，対応する指摘箇所についても同様。）
　
　２．請求項１に記載の「タスクの実行条件が見過ごされ」は，具体的に何のどのような処理を指しているのか不明確であり，詳細な説明の記載を参酌しても把握できない。（第３６条第６項第２号）　
　
　また，当該「タスクの実行条件が見過ごされ」との記載に関し，「タスクの実行条件が見過ごされ」ているとの判断を，具体的にどのような態様で実現しているのかについて，発明の詳細な説明には対応する明確な記載がなく，したがって発明の詳細な説明は，当業者が実施できる程度に明確かつ十分に記載したものではない。
　この点に関し，発明の詳細な説明に（注：下線は参考のため当審にて付与，以下同じ），
　
「図９に，
タスクの実行条件を見過ごし
タスクの正常な実行を妨げるようなイベントが発生した場合
　
　との記載はあるが，「タスクの正常な実行を妨げるようなイベント」についての具体的事例がなく，「見過ご」すことによる不実行と，例えば，単なるエラーによる不実行との区別が理解できない。（第３６条第４項第１号）
　
　以上１〜２について，請求項２−１１についても同様である。
　
　
（理由２）
　本件出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　　　記
　
・請求項　　　　１−１３
・引用文献等　　１−３
　
［備考］
　
（１）引用発明等
　
　引用文献およびその記載事項は，前記「２．平成２３年９月２６日付けの手続補正について」「２．独立特許要件」の「（２）引用文献に記載されている技術的事項及び引用発明の認定」に記載したとおりである。
　
（２）請求項１記載の発明について
　
・・・（中略）・・・　
　
　そうすると，請求項１記載の発明の構成要件を全て含み，さらに特定の構成要件に限定要件を付加したものに相当する補正後の発明が，前記「２．平成２３年９月２６日付けの手続補正について」の「（４）当審の判断」に記載したとおり，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，請求項１記載の発明も，同様の理由により，当該引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
　
・・・（中略）・・・　
　
［引用文献等一覧］
１．特開２００５−３１８９２号公報
２．特開２００５−１３５１４７号公報
３．特開２００２−１８９５７１号公報　　　　　　　　　　　　　』
　
　
３．拒絶理由についての検討
　上記当審の拒絶理由で指摘した点について，以下に検討する。
　
３−１．（理由１）（特許法第３６条第４項第１号及び第６項第２号）について
　
（１）請求項１に記載の「タスク追跡ポリシー」に関し
　請求項１に記載の「タスク追跡ポリシー」が，どのような具体的態様で実現されているのか依然として不明確である。具体的には，当該「タスク追跡ポリシー」とは，所定の形式又は形態を備えたデータであるのか，それとも単なる情報であるのか，不明りょうであり，そして，それにより「装置管理サーバ」が上記「タスク追跡ポリシー」をどのように「配信」し，「端末」が上記「タスク追跡ポリシー」にどのように基づいて「スケジューリング・タスク」を「追跡」しているのかについても，依然として不明確である。また，上記「タスク追跡ポリシー」との記載に関連する他の請求項の記載や，同じく関連する発明の詳細な説明における記載を参酌しても，上記「タスク追跡ポリシー」が，どのような具体的態様で実現されているのかについては依然として不明確である。
　なお，上記「タスク追跡ポリシー」との記載に関し，平成２５年７月５日付けの意見書において請求人は，
　
　『タスク追跡ポリシーの例は，本願明細書の段落［0050］〜［0074］に記載されています。また，段落［0075］に「上記４つのポリシーは，端末通知機構の１つの通知法を例示したに過ぎない。ＯＭＡ　ＤＭプロトコルにおいて定義されたメッセージのAlertのタイプは，上記装置管理サーバへの通知に画一的に使用することができる。以後，このAlertタイプのメッセージを，Generic Alertメッセージと称する」と記載されています。上記「タスク追跡ポリシー」は，上記「Generic Alertメッセージ」として実装されます。段落［0076］では，ＸＭＬで記述された「Generic Alertメッセージ」の基本構造の一例が記載されています。すなわち，当該ＸＭＬに，上記タスク追跡ポリシーの基本構造の一例が示されています。
　また，上記タスク追跡ポリシーは，タスクの実行条件が見過ごされ，上記端末が正常実行しなかった場合，上記端末が，上記装置管理サーバに通知する処理を例えば含むものです。すなわち，上記端末は，上記タスク追跡ポリシーに基づいて，上記スケジューリング・タスクを追跡できます。
　したがって，「タスク追跡ポリシー」という特徴は，明確です。』
　
　と主張しており，上記主張で挙げている発明の詳細な説明の記載では，「タスク追跡ポリシー」として規定している内容，及び「タスク追跡ポリシー」がＯＭＡ　ＤＭプロトコルの「Generic Alertメッセージ」として実装されることが説明されているが，上記発明の詳細な説明の記載から，当該「Generic Alertメッセージ」をＸＭＬで記述した一例として段落【００７６】に挙げられているコード中の，いずれの記述が「タスク追跡ポリシー」の内容及び態様を示しているのか，当該「タスク追跡ポリシー」に基づくとされている具体的内容のうち「タスクの実行条件が見過ごされ」との処理のための判断内容がいずれの記述で実現されているのか，及び，上記「Generic Alertメッセージ」として実装される当該「タスク追跡ポリシー」がどのような態様で「装置管理サーバによって配信」されるのか，について理解することができず，よって，上記主張で挙げている発明の詳細な説明の記載を参酌しても，請求項１の上記「タスク追跡ポリシー」が，どのような具体的態様で実現されているのか，把握することができないので，上記意見書における主張を参照しても，請求項１の上記「タスク追跡ポリシー」との記載が不明確である点を解決するに至らず，したがって，本願の請求項１の記載は，特許法第３６条第６項第２号に規定する要件を満たしていない。
　
　また，上記で述べたとおり，請求項１の上記「タスク追跡ポリシー」との記載に関し，発明の詳細な説明には，上記「タスク追跡ポリシー」が，具体的にどのような態様で実現しているのかについて対応する明確な記載がなく，したがって発明の詳細な説明は，当業者が実施できる程度に明確かつ十分に記載したものではない。よって，本願の発明の詳細な説明は，特許法第３６条第４項第１号に規定する要件を満たしていない。
　
（２）請求項１に記載の「タスクの実行条件が見過ごされ」に関し
　請求項１に記載の「タスクの実行条件が見過ごされ」について，当該「タスクの実行条件が見過ごされ」が，具体的に何のどのような処理を指しているのか依然として不明確である。具体的には，「タスクの実行条件が見過ごされ」てその結果「記端末が正常実行しなかった場合」とは，平成２５年７月５日付けの意見書で挙げられている，発明の詳細な説明の段落【０１２１】「図９に，
タスクの実行条件を見過ごし，上記携帯電話機が上記タスクを正常に実行しなかった場合
種々の理由から上記携帯電話機がスイッチ・オフの状態である
上記携帯電話機は，上記タスク処理を正常に実行することはできない
　
　また，上記で述べたとおり，請求項１の上記「タスクの実行条件が見過ごされ」との記載に関し，発明の詳細な説明には，上記「タスクの実行条件が見過ごされ」との判断が，どのような具体的態様で実現されているのかについて対応する明確な記載がなく，したがって発明の詳細な説明は，当業者が実施できる程度に明確かつ十分に記載したものではない。よって，本願の発明の詳細な説明は，特許法第３６条第４項第１号に規定する要件を満たしていない。
　
（３）以上のとおり，本願の請求項１の記載が，特許法第３６条第６項第２号に規定する要件を満たしておらず，また，本願の発明の詳細な説明の記載は，特許法第３６条第４項第１号に規定する要件を満たしていない。
　
　
３−２．（理由２）（特許法第２９条第２項）について
　
　前記「１．手続きの経緯」で示した，本願の請求項１に係る発明（以下，「本願発明」という。）が，特許法第２９条第２項に規定する要件を満たしているかについて以下に検討する。
　
（１）引用文献に記載されている技術的事項及び引用発明の認定
　
（１−１）引用文献１
　本願の第１国出願前に既に公知であり，当審の拒絶理由通知で引用された，特開２００５−３１８９２号公報（平成１７年２月３日公開，以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
　
　Ａ「【請求項１】
スケジューリングされているジョブ群を実行するジョブ実行システムにおいて，複数種のリソースを備えてジョブの実行を行う複数のリソースマネージャホストと，ジョブ実行の管理を行う統合マネージャホストとを備え，前記リソースマネージャホストは，ジョブ実行中のリソースの状況を監視してリソースエラーを検知するリソースエラー検知手段と，リソースエラーを前記統合マネージャホストに報告するリソースエラー通知手段とを有し，前記統合マネージャホストは，リソースエラーを報告してきたリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定する手段を有することを特徴とするジョブ実行システム。
【請求項２】
スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法において，複数種のリソースを備えてジョブを実行するリソースマネージャホストからのリソースエラーの報告を受け，リソースエラーの報告を行ったリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定することを特徴とするジョブ実行制御方法
　
　Ｂ「【００２５】
リソースマネージャホストのそれぞれは，図２に示すような各種の機能部を備えて構成されており
【００２６】
リソースエラー検知部２１０は，自リソースマネージャホスト内でのリソースエラーを検知し，リソースエラー通知部２２０は，取得したリソースエラーの情報を統合マネージャホスト１０に対して通知する。
【００２７】
リソース情報通知部２３０は，自リソースマネージャホスト内でどんなリソースがどれだけ不足しているかの情報，及び，ジョブの実行に必要なＰＰ等の情報を統合マネージャホスト１０に対し通知する。
【００２８】
命令受け付け部２４０は，統合マネージャホスト１０から送信されてきた命令を受け付けて解読する。
【００２９】
リソース削除部２５０は，リソース削除依頼部１７０から通知された不要と判断された情報によりリソースを解放する。
【００３０】
インストール情報受信部２６０は，ジョブ実行に必要なインストール情報を統合マネージャホスト１０から受信し，インストール実行部２７０は，ジョブ実行に必要な情報をインストールする。」
　
　Ｃ「【００３５】
図７はリソース情報データの通信プロトコルの例を示す図である。
このリソース情報１０００は，リソースエラーを生じたリソースマネージャホストが統合マネージャホストに送信する移動したい（実行中だった）ジョブの情報やジョブ実行に必要なＰＰ情報等のリソース情報である。
【００３６】
このリソース情報１０００は，データの先頭にこのデータがリソース情報データであることを示すリソースデータ開始のフラグを設定し，それに続いて，送信元リソースマネージャホスト名，実行中であったジョブのＩＤ，送信日時が設定され，その後ろに，ジョブ実行に必要なメモリ容量，ディスク容量，推奨ＣＰＵ性能，ＰＰ数，ＰＰ名とそのバージョンを付け，最後に，このリソース情報データの後に送信するＰＰのインストールに必要なレジストリファイルのファイル数，ＰＰの緩急設定に必要な情報のファイル数を付与して構成されている。図示例では，２つのＰＰのＰＰ名１，２があり，それぞれに，バージョン，レジストリファイルのファイル数，情報のファイル数が設定されている。」　
　
　以下に，上記引用文献１の記載事項について検討する。　
　
（ア）引用文献１は，上記Ａに記載の「【請求項２】」に係る「ジョブ実行制御方法」である発明について説明するものであることから，
　引用文献１には，“スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法において，
　複数種のリソースを備えてジョブを実行するリソースマネージャホストからのリソースエラーの報告を受け，
　リソースエラーの報告を行ったリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定することを特徴とするジョブ実行制御方法”が記載されているといえる。
　
（イ）上記“リソースマネージャホスト”に関し，
　上記Ｂの「リソースマネージャホストのそれぞれは，図２に示すような各種の機能部を備えて構成されており・・・命令受け付け部２４０は，統合マネージャホスト１０から送信されてきた命令を受け付けて解読する。」との記載から，
　上記“リソースマネージャホスト”は，“統合マネージャホストから送信されてきた命令を受け付けて解読する，命令受け付け部を有”することがよみとれる。
　
（ウ）上記Ｂに「リソース情報通知部２３０は，自リソースマネージャホスト内でどんなリソースがどれだけ不足しているかの情報，及び，ジョブの実行に必要なＰＰ等の情報を統合マネージャホスト１０に対し通知する。」との記載，及び上記Ｃに「このリソース情報１０００は，リソースエラーを生じたリソースマネージャホストが統合マネージャホストに送信する移動したい（実行中だった）ジョブの情報やジョブ実行に必要なＰＰ情報等のリソース情報である。」との記載があり，上記「リソース情報通知部」から通知される「リソース情報」は，「リソースマネージャホストからのリソースエラーの報告」に当たるものであるから，
　上記“リソースマネージャホストからのリソースエラーの報告”は“実行中だったジョブの情報を含む”ことが読み取れる。
　
　以上，（ア）〜（ウ）で指摘した事項から，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
　スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法において，
　複数種のリソースを備えてジョブを実行するリソースマネージャホストからのリソースエラーの報告を受け，
　リソースエラーの報告を行ったリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定することを含み，
　前記リソースマネージャホストは，統合マネージャホストから送信されてきた命令を受け付けて解読する，命令受け付け部を有し，
　リソースマネージャホストからのリソースエラーの報告は，実行中だったジョブの情報を含む，
　こと特徴とするジョブ実行制御方法。
　
（１−２）引用文献２　
　本願の第１国出願前に既に公知であり，当審の拒絶理由通知で引用された，特開２００５−１３５１４７号公報（平成１７年５月２６日公開，以下，「引用文献２」という。）には，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
　
　Ｄ「【０００５】
　ところが，
サーバコンピュータからプログラム更新の中止やプログラム更新日時の変更が指令された際に
電源がオフであったりオフラインで動作していたりしたためにその指令を受取れなかった情報処理装置が発生すると
情報処理装置では，変更前のプログラム更新日時が経過したことに応じて自動的にプログラムが更新されてしまう
　
　Ｅ「【００１５】
　ここで，本実施の形態では，
各ＰＯＳ端末１に実装されているＰＯＳ業務プログラムＰ１が本部のホストコンピュータ４によって一元的に管理されている
同一プログラムＩＤと更新指定日時情報Ｑ２等のプログラム更新情報が格納された更新情報ファイル７と
管理情報ファイル８とが，ホストコンピュータ４上で作成される
　
（１−３）引用文献３　
　本願の第１国出願前に既に公知であり，当審の拒絶理由通知で引用された，特開２００２−１８９５７１号公報（平成１４年７月５日公開，以下，「引用文献３」という。）には，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
　
　Ｆ「【請求項１】
上位装置の命令を受けて磁気ディスク装置自体の障害を検出し報告する自己診断機能を有する磁気ディスク装置
前記上位装置からの指定によって障害検出時に自己診断を停止するか続行するかを選択することができることを特徴とする磁気ディスク装置。」　
　
（２）本願発明と引用発明との対比
　
　本願発明と引用発明とを対比する。
（２−１）引用発明の「ジョブ」，「スケジューリングされているジョブ群」は，本願発明の「タスク」，「スケジューリング・タスク」にそれぞれ相当し，
　また，引用発明の「ジョブ実行制御方法」は，「スケジューリングされているジョブ群の実行」を制御することで「リソースマネージャホスト」を管理しており，また当該「リソースマネージャホスト」は装置といえることから，上記管理は装置管理といえるものである。
　したがって，引用発明の「スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法」は，本願発明の「装置管理において，スケジューリング・タスクを処理する方法」に相当する。
　
（２−２）引用発明の「ジョブ実行制御方法」は，「統合マネージャホストから送信されてきた命令を受け付け」た「リソースマネージャホスト」が「ジョブ」を「実行」するものであり，また，上記「リソースマネージャホスト」は，本願発明の「端末」とともに，上位概念においてコンピュータ装置といえるものであることから，上記「ジョブ実行制御方法」は，統合マネージャホストからコンピュータ装置へ配信された装置管理の処理タスクの処理に適合したものであるといえる。
　ここで，引用発明が，上記コンピュータ装置に相当する「リソースマネージャホスト」が複数存在する構成を前提としている一方で，本願発明は，実施例に関する記載等を見ると，コンピュータ装置に相当する「端末」が１つのみ存在する場合が記載されている点で一応の対比が見られる。しかしながら，本願発明はそもそも「装置管理サーバ」が「端末」における「スケジューリング・タスク」の「処理」を管理するものであることから，必ずしも「装置管理サーバ」と「端末」とが１対１対応である構成にのみ限定的に適応可能なものとは解されず，また本願の請求項の記載からも，「装置管理サーバ」と「端末」との１対１対応の構成に限定的に適合可能としているものとはよみとれるものではなく，さらに，適用対象とするサーバと端末の構成関係において相違を認めたとしても，当該相違は，単にタスク管理方法の適用対象として適宜決める程度の事項であることから，いずれにしても，この点をもって実質的な差異とは認められず，また進歩性の判断にも影響を与えない。
　そして，引用発明の「統合マネージャホスト」は，本願発明の「装置管理サーバ」に相当することから，
　引用発明の「ジョブ実行制御方法」が，「統合マネージャホストから送信されてきた命令を受け付け」た「リソースマネージャホスト」が「ジョブ」を「実行」するものであることと，本願発明の「上記方法は，装置管理サーバから端末へ配信された装置管理の処理タスクの処理に適合するものであ」ることは，ともに，“上記方法は，装置管理サーバからコンピュータ装置へ配信された装置管理の処理タスクの処理に適合するものであ”る点で共通する。　
　
（２−３）引用発明の「リソースマネージャホスト」における「命令受け付け部」が，「スケジューリングされているジョブ群」に関して「統合マネージャホストから送信されてきた命令を受け付け」ることと，本願発明の「装置管理サーバから配信された上記装置管理のスケジューリング・タスクを端末にて受信」することは，ともに，“装置管理サーバから配信された上記装置管理のスケジューリング・タスクをコンピュータ装置にて受信”する点で共通する。
　
（２−４）本願発明の「追跡情報」とは，それについて具体的に記載された本願発明の詳細な説明の段落【００７８】「Ｃ）　上記携帯電話機が，タスクの実行（すなわち，追跡情報）を報告する。」等の記載を参酌すると，「端末」における「タスクの実行」に係る情報であると解されることから，上位概念においてタスクの実行情報であるといえ，
　一方，引用発明における「リソースエラーの報告」も「実行中だったジョブの情報を含む」ものであることから，タスクの実行情報であるといえる。
　したがって，引用発明の「リソースマネージャホスト」から「実行中だったジョブの情報」を含む「リソースエラーの報告」を報告することと，本願発明の「上記端末が，上記タスク追跡ポリシーに基づいて，追跡情報を上記装置管理サーバに報告」することは，ともに，“上記コンピュータ装置が，タスクの実行情報を上記装置管理サーバに報告”する点で共通する。
　
　以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
　装置管理において，スケジューリング・タスクを処理する方法であって，
　上記方法は，装置管理サーバからコンピュータ装置へ配信された装置管理の処理タスクの処理に適合するものであり，
　装置管理サーバから配信された上記装置管理のスケジューリング・タスクをコンピュータ装置にて受信し，
　上記コンピュータ装置が，タスクの実行情報を上記装置管理サーバに報告することを特徴とする方法。
　
（相違点１）
　処理タスクについて受信し処理し報告する，コンピュータ装置に関し，
　本願発明が「端末」であるのに対し，
　引用発明は，「リソースマネージャホスト」である点。
　
（相違点２）
　本願発明が，「上記端末が，上記装置管理の上記スケジューリング・タスクの実行条件および上記装置管理サーバによって配信された上記装置管理の上記スケジューリング・タスクのタスク追跡ポリシーに基づいて，上記装置管理の上記スケジューリング・タスクを追跡」する処理を行っているのに対し，
　引用発明は，そのような処理を行うことについて言及されていない点。
　
（相違点３）
　コンピュータ装置による，タスクの実行情報の報告に関し，
　本願発明が，「タスク追跡ポリシーに基づいて」，「追跡情報」を報告しているのに対し，
　引用発明は，「実行中だったジョブの情報」を含む「リソースエラーの報告」を報告しているが，それが「タスク追跡ポリシーに基づい」たものに当たるかは明りょうでない点。
　
（相違点４）
　本願発明が，「上記タスク追跡ポリシーは，タスクの実行条件が見過ごされ，上記端末が正常実行しなかった場合，上記端末が，上記装置管理サーバに通知する処理を含む」こととしているのに対し，
　引用発明は，そのような構成について言及されていない点。
　
（３）当審の判断
　上記相違点１ないし相違点４について検討する。
　
（３−１）相違点１について
　スケジューリングされたジョブの管理を，端末におけるジョブ処理を対象に行うことは，本願の第１国出願前において周知（必要であれば，引用文献２の上記Ｅの記載を参照）であり，引用発明のスケジューリングされたジョブの管理として，当該周知技術を採用し，端末を対象に行うこと，すなわち，相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点１は格別なものではない。　
　
（３−２）相違点２ないし相違点４について
　ここで，本願発明における「タスク追跡ポリシー」及び「タスクの実行条件が見過ごされ」との記載について検討する。
　まず，本願発明における「タスク追跡ポリシー」とは，上記「３−１．（理由１）（特許法第３６条第４項第１号及び第６項第２号）について」でも述べたとおり，実現されている具体的態様については不明確であるものの，発明の詳細な説明【００５０】〜【００７７】には，「タスク追跡ポリシー」として規定している内容，及び「タスク追跡ポリシー」がＯＭＡ　ＤＭプロトコルの「Generic Alertメッセージ」として実装されることが説明されており，また，平成２４年６月７日付けの回答書では『本発明における「タスク追跡ポリシー」は，スケジューリング・タスクの実行を追跡するための
メカニズム
　また，本願発明における「タスクの実行条件が見過ごされ」とは，同様に，具体的に何のどのような処理を指しているのか不明確であるものの，発明の詳細な説明の段落【０１１２】の記載等を参酌すると，端末の電源オフによりタスクの実行条件が見過ごされることを含むものに対応すると解される。
　
　それに対し，引用発明の「スケジューリングされているジョブ」に，「実行」に当たり何らかの「スケジューリング」すなわち実行時期等に係る条件が付されることは当業者にとって自明な事項であり，また，同じく引用発明において「実行中」の「ジョブ」が実行できない旨を報告するために，「実行中」の「ジョブ」と実行に必要な条件とを参照して，「ジョブ」が実行できない状態であることを所定の仕組によって判断することで，「ジョブ」の実行状態を追跡し確認することは，必然的に行う技術事項であることから，引用発明において，「実行中だったジョブの情報」を含む「リソースエラーの報告」を行うために，ジョブに係る追跡の仕組として「タスク追跡ポリシー」の如き構成を採用し，ジョブの実行条件と上記「タスク追跡ポリシー」に基づいて，ジョブの状態を「追跡」して確認し，その結果を「追跡情報」として報告することに，格別困難性は認められない。　
　
　また，ジョブ状態の確認のための仕組に関する情報を，上位装置から送信するようにすること（必要であれば，引用文献３の上記Ｆの記載を参照），及び，ジョブの実行条件が見過ごされ正常実行しなかった場合として，装置電源オフによるジョブの異常実行を含むこと（必要であれば，引用文献２の上記Ｄの記載を参照）は，いずれも本願の第１国出願前に周知であり，特に後者の周知技術である装置電源オフによるジョブの異常実行という（見過ごされ）実行不正後に把握される事象と，ジョブ実行中のリソースエラーによるジョブの実行不可という実行不正中に把握されうる事象とは，いずれもよく知られた事象であって報告対象とする点においては適宜決める程度の事項であることから，引用発明における「実行中」の「ジョブの情報」を含むエラーの報告を行う際に，確認の仕組みに関する情報として上記前者の周知技術を，また，報告する対象であるジョブの実行不正内容として上記後者の周知技術を，それぞれ適用することは，当業者であれば適宜なし得ることである。
　
　してみると，引用発明における「実行中だったジョブの情報」を含む「リソースエラーの報告」に対し，上記周知技術を適用し，「上記端末が，上記装置管理サーバによって配信された，上記装置管理の上記スケジューリング・タスクのタスク追跡ポリシー，および，上記装置管理の上記スケジューリング・タスクの実行条件に基づいて，上記装置管理の上記スケジューリング・タスクを追跡」するように行うとともに，「タスク追跡ポリシーに基づいて」，「追跡情報」を報告し，また，「上記タスク追跡ポリシーは，タスクの実行条件が見過ごされ，上記端末が正常実行しなかった場合，上記端末が，上記装置管理サーバに通知する処理を含む」こととすること，すなわち，相違点２ないし相違点４に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点２ないし相違点４は格別のものではない。　
　
（３−３）小括
　
　上記で検討したごとく，相違点１ないし相違点４は格別のものではなく，そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，上記引用発明，及び周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　
　したがって，本願発明は，上記引用発明，及び周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項に規定する要件を満たしておらず，特許を受けることができない。
　
　
４．むすび
　以上のとおり，本願の請求項１の記載は，特許法第３６条第６項第２号に規定する要件を満たしておらず，また，また，本願の発明の詳細な説明の記載は，特許法第３６条第４項第１号に規定する要件を満たしておらず，また，本願の請求項１に係る発明は，引用発明，及び周知技術に基づいて当業者が容易になし得たものであるから，他の請求項について検討するまでもなく，本願は特許法第２９条第２項に規定する要件を満たしておらず，したがって，特許を受けることができない。
　
　よって，結論のとおり審決する。