• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1283543
審判番号 不服2011-20727  
総通号数 171 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2014-03-28 
種別 拒絶査定不服の審決 
審判請求日 2011-09-26 
確定日 2014-01-06 
事件の表示 特願2008-530305「装置管理において、スケジューリング・タスクを処理するための方法およびシステム」拒絶査定不服審判事件〔平成19年 5月18日国際公開、WO2007/054013、平成21年 2月26日国内公表、特表2009-508241〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯

本願は,2006年11月6日(パリ条約による優先権主張外国庁受理2005年11月10日 中国)を国際出願日とする出願であって,
平成19年12月20日付けで特許法第184条の5第1項の規定による書面が提出され,
平成20年2月7日付けで特許法第184条の4第1項の規定による明細書,特許請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出され,
同年3月17日付けで審査請求がなされるとともに,同日付けで手続補正がなされ,
平成22年8月6日付けで拒絶理由通知(同年同月17日発送)がなされ,
同年11月24日付けで意見書が提出されるとともに,同日付けで手続補正がなされ,
平成23年1月5日付けで拒絶理由通知(同年同月11日発送)がなされ,
同年4月7日付けで意見書が提出されるとともに,同日付けで手続補正がなされたが,
同年5月18日付けで拒絶査定(同年同月24日謄本送達)がなされ,
同年9月26日付けで審判請求がされるとともに,同日付けで手続補正がなされ,
同年12月5日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ,
平成24年2月2日付けで当審により特許法第134条第4項の規定に基づく審尋(同年同月7日発送)がなされ,
同年6月7日付けで回答書の提出があったものである。

その後,当審において上記平成25年4月11日付けで前記平成23年9月26日付け手続補正を却下する旨の補正の却下の決定(平成25年4月23日発送)がなされるとともに,平成25年4月11日付けで拒絶理由通知(同年同月16日発送)がなされ,
平成25年7月5日付けで意見書が提出されるとともに,同日付けで手続補正がなされたのであって,
その請求項1に係る発明は,平成25年7月5日付け手続補正書によって補正された特許請求の範囲の請求項1に記載されたとおりの次のものと認める。

「装置管理において,スケジューリング・タスクを処理する方法であって,
上記方法は,装置管理サーバから端末へ配信された装置管理の処理タスクの処理に適合するものであり,
装置管理サーバから配信された上記装置管理のスケジューリング・タスクを端末にて受信し,
上記端末が,上記装置管理の上記スケジューリング・タスクの実行条件および上記装置管理サーバによって配信された上記装置管理の上記スケジューリング・タスクのタスク追跡ポリシーに基づいて,上記装置管理の上記スケジューリング・タスクを追跡し,
上記端末が,上記タスク追跡ポリシーに基づいて,追跡情報を上記装置管理サーバに報告し,
上記タスク追跡ポリシーは,タスクの実行条件が見過ごされ,上記端末が正常実行しなかった場合,上記端末が,上記装置管理サーバに通知する処理を含むことを特徴とする方法。」

2.当審の拒絶理由
当審による,平成25年4月11日付けの拒絶理由通知は,概略,以下のとおりである。

『(理由1)
本件出願は,明細書及び特許請求の範囲の記載が下記の点で不備のため,特許法第36条第4項第1号及び第6項第2号に規定する要件を満たしていない。

1.請求項1に記載の「スケジューリング・タスクの実行条件」及び「タスク追跡ポリシー」が,具体的にどのようなものを指し,またどのような具体的態様で実現されているのか不明確であり,詳細な説明の記載を参酌しても把握できない。(第36条第6項第2号)

また,当該「スケジューリング・タスクの実行条件」及び「タスク追跡ポリシー」との記載に関し,「スケジューリング・タスクの実行条件」及び「タスク追跡ポリシー」を,具体的にどのような態様で実現しているのかについて,発明の詳細な説明には対応する明確な記載がなく,したがって発明の詳細な説明は,当業者が実施できる程度に明確かつ十分に記載したものではない。

・・・(中略)・・・

同様に,「タスク追跡ポリシー」についても,発明の詳細な説明に,

「装置管理サーバは,上記タスク処理の特徴に基づいたタスク追跡ポリシーを生成し,上記ポリシーを,上記携帯電話機に対して配信してもよい。上記携帯電話機は,上記タスク処理の上記実行条件を監視することに加えて,上記装置管理サーバによって生成された上記タスク追跡ポリシーに基づく追跡に対応する情報(タスク処理の実行状況,タスク処理の実行に影響するイベントの発生状況等)を,上記装置管理サーバに通知しなければならない。これにより,上記装置管理サーバは,スケジューリング・タスクの実行を正常に追跡することができる。」(【0077】),

「ステップC1 上記端末は,自端末のタスク処理を追跡するために,タスク処理の上記実行条件(すなわち,実行のトリガとなる条件)および上記タスク追跡ポリシーに基づいてタスクの追跡を開始する。」(【0082】)

等の記載があるが,いずれもタスク追跡ポリシーの具体的な態様についての記載はなく,タスク追跡ポリシーが具体的にどのような内容及び形態のデータであり,端末においてタスク追跡ポリシーを具体的にどのように処理することでタスクの追跡を実現しているのか,何ら記載されていない。(第36条第4項第1号)
(当審注:上記第36条第4項第1号として指摘している事項は,発明の詳細な説明の記載に対するものであり,特許請求の範囲の記載に対するものではない点に留意の上,意見等されたい。以下,対応する指摘箇所についても同様。)

2.請求項1に記載の「タスクの実行条件が見過ごされ」は,具体的に何のどのような処理を指しているのか不明確であり,詳細な説明の記載を参酌しても把握できない。(第36条第6項第2号)

また,当該「タスクの実行条件が見過ごされ」との記載に関し,「タスクの実行条件が見過ごされ」ているとの判断を,具体的にどのような態様で実現しているのかについて,発明の詳細な説明には対応する明確な記載がなく,したがって発明の詳細な説明は,当業者が実施できる程度に明確かつ十分に記載したものではない。
この点に関し,発明の詳細な説明に(注:下線は参考のため当審にて付与,以下同じ),

「図9に,タスクの実行条件を見過ごし,上記携帯電話機が上記タスクを正常に実行しなかった場合において,上記装置管理サーバが,処理通知を配信する処理フローを示す。図4のステップ4において,タスクの正常な実行を妨げるようなイベントが発生した場合,例えば,上記装置管理サーバが,2005年8月3日午後12時にタスクを実行するように要求されているタスク処理を配信しても,種々の理由から上記携帯電話機がスイッチ・オフの状態であるかもしれず,したがって,上記携帯電話機は,上記タスク処理を正常に実行することはできない可能性がある。ステップD1’において,上記装置管理サーバは,強制実行するための命令の他に,上記タスクの実行を取り消すための命令も送信できる。ステップD2’において,上記ユーザに提示される選択肢には,(上記タスクのタイプおよびポリシーにより定まる,)タスク実行処理,タスク遅延処理,タスク拒絶処理等が含まれていてもよい。」(【0121】)

との記載はあるが,「タスクの正常な実行を妨げるようなイベント」についての具体的事例がなく,「見過ご」すことによる不実行と,例えば,単なるエラーによる不実行との区別が理解できない。(第36条第4項第1号)

以上1?2について,請求項2-11についても同様である。


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



・請求項 1-13
・引用文献等 1-3

[備考]

(1)引用発明等

引用文献およびその記載事項は,前記「2.平成23年9月26日付けの手続補正について」「2.独立特許要件」の「(2)引用文献に記載されている技術的事項及び引用発明の認定」に記載したとおりである。

(2)請求項1記載の発明について

・・・(中略)・・・

そうすると,請求項1記載の発明の構成要件を全て含み,さらに特定の構成要件に限定要件を付加したものに相当する補正後の発明が,前記「2.平成23年9月26日付けの手続補正について」の「(4)当審の判断」に記載したとおり,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであるから,請求項1記載の発明も,同様の理由により,当該引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものである。

・・・(中略)・・・

[引用文献等一覧]
1.特開2005-31892号公報
2.特開2005-135147号公報
3.特開2002-189571号公報 』


3.拒絶理由についての検討
上記当審の拒絶理由で指摘した点について,以下に検討する。

3-1.(理由1)(特許法第36条第4項第1号及び第6項第2号)について

(1)請求項1に記載の「タスク追跡ポリシー」に関し
請求項1に記載の「タスク追跡ポリシー」が,どのような具体的態様で実現されているのか依然として不明確である。具体的には,当該「タスク追跡ポリシー」とは,所定の形式又は形態を備えたデータであるのか,それとも単なる情報であるのか,不明りょうであり,そして,それにより「装置管理サーバ」が上記「タスク追跡ポリシー」をどのように「配信」し,「端末」が上記「タスク追跡ポリシー」にどのように基づいて「スケジューリング・タスク」を「追跡」しているのかについても,依然として不明確である。また,上記「タスク追跡ポリシー」との記載に関連する他の請求項の記載や,同じく関連する発明の詳細な説明における記載を参酌しても,上記「タスク追跡ポリシー」が,どのような具体的態様で実現されているのかについては依然として不明確である。
なお,上記「タスク追跡ポリシー」との記載に関し,平成25年7月5日付けの意見書において請求人は,

『タスク追跡ポリシーの例は,本願明細書の段落[0050]?[0074]に記載されています。また,段落[0075]に「上記4つのポリシーは,端末通知機構の1つの通知法を例示したに過ぎない。OMA DMプロトコルにおいて定義されたメッセージのAlertのタイプは,上記装置管理サーバへの通知に画一的に使用することができる。以後,このAlertタイプのメッセージを,Generic Alertメッセージと称する」と記載されています。上記「タスク追跡ポリシー」は,上記「Generic Alertメッセージ」として実装されます。段落[0076]では,XMLで記述された「Generic Alertメッセージ」の基本構造の一例が記載されています。すなわち,当該XMLに,上記タスク追跡ポリシーの基本構造の一例が示されています。
また,上記タスク追跡ポリシーは,タスクの実行条件が見過ごされ,上記端末が正常実行しなかった場合,上記端末が,上記装置管理サーバに通知する処理を例えば含むものです。すなわち,上記端末は,上記タスク追跡ポリシーに基づいて,上記スケジューリング・タスクを追跡できます。
したがって,「タスク追跡ポリシー」という特徴は,明確です。』

と主張しており,上記主張で挙げている発明の詳細な説明の記載では,「タスク追跡ポリシー」として規定している内容,及び「タスク追跡ポリシー」がOMA DMプロトコルの「Generic Alertメッセージ」として実装されることが説明されているが,上記発明の詳細な説明の記載から,当該「Generic Alertメッセージ」をXMLで記述した一例として段落【0076】に挙げられているコード中の,いずれの記述が「タスク追跡ポリシー」の内容及び態様を示しているのか,当該「タスク追跡ポリシー」に基づくとされている具体的内容のうち「タスクの実行条件が見過ごされ」との処理のための判断内容がいずれの記述で実現されているのか,及び,上記「Generic Alertメッセージ」として実装される当該「タスク追跡ポリシー」がどのような態様で「装置管理サーバによって配信」されるのか,について理解することができず,よって,上記主張で挙げている発明の詳細な説明の記載を参酌しても,請求項1の上記「タスク追跡ポリシー」が,どのような具体的態様で実現されているのか,把握することができないので,上記意見書における主張を参照しても,請求項1の上記「タスク追跡ポリシー」との記載が不明確である点を解決するに至らず,したがって,本願の請求項1の記載は,特許法第36条第6項第2号に規定する要件を満たしていない。

また,上記で述べたとおり,請求項1の上記「タスク追跡ポリシー」との記載に関し,発明の詳細な説明には,上記「タスク追跡ポリシー」が,具体的にどのような態様で実現しているのかについて対応する明確な記載がなく,したがって発明の詳細な説明は,当業者が実施できる程度に明確かつ十分に記載したものではない。よって,本願の発明の詳細な説明は,特許法第36条第4項第1号に規定する要件を満たしていない。

(2)請求項1に記載の「タスクの実行条件が見過ごされ」に関し
請求項1に記載の「タスクの実行条件が見過ごされ」について,当該「タスクの実行条件が見過ごされ」が,具体的に何のどのような処理を指しているのか依然として不明確である。具体的には,「タスクの実行条件が見過ごされ」てその結果「記端末が正常実行しなかった場合」とは,平成25年7月5日付けの意見書で挙げられている,発明の詳細な説明の段落【0121】「図9に,タスクの実行条件を見過ごし,上記携帯電話機が上記タスクを正常に実行しなかった場合において,上記装置管理サーバが,処理通知を配信する処理フローを示す。図4のステップ4において,タスクの正常な実行を妨げるようなイベントが発生した場合,例えば,上記装置管理サーバが,2005年8月3日午後12時にタスクを実行するように要求されているタスク処理を配信しても,種々の理由から上記携帯電話機がスイッチ・オフの状態であるかもしれず,したがって,上記携帯電話機は,上記タスク処理を正常に実行することはできない可能性がある。」(注:下線は当審付与)に記載があるような,端末が電源オフの状態であることに起因して「タスクの実行条件が見過ごされ」る場合以外に,例えば,端末エラーに起因して「タスクの実行条件が見過ごされ」る場合も一般に想定されるところ,本願発明で特に前者の場合を識別して「記端末が正常実行しなかった場合」と判断するために,具体的にどのような情報に基づき,どのような処理を行っているのか,依然として不明確であり,加えて,上記(1)で述べたとおり上記「タスク追跡ポリシー」がどのような具体的態様で実現されているのか依然として不明確であることから,請求項1の当該「タスク追跡ポリシー」に関する記載によっても,それを用いて行う上記「タスクの実行条件が見過ごされ」との判断の具体的態様について明りょうとはならない。また,上記「タスクの実行条件が見過ごされ」との記載に関連する他の請求項の記載や,同じく関連する発明の詳細な説明における記載を参酌しても,請求項1の上記「タスクの実行条件が見過ごされ」が,具体的にどのような処理を行っているのか依然として不明確である。また,上記不明確な点は,この点に関する上記意見書における主張を参酌しても解消しないことから,本願の請求項1の記載は,特許法第36条第6項第2号に規定する要件を満たしていない。

また,上記で述べたとおり,請求項1の上記「タスクの実行条件が見過ごされ」との記載に関し,発明の詳細な説明には,上記「タスクの実行条件が見過ごされ」との判断が,どのような具体的態様で実現されているのかについて対応する明確な記載がなく,したがって発明の詳細な説明は,当業者が実施できる程度に明確かつ十分に記載したものではない。よって,本願の発明の詳細な説明は,特許法第36条第4項第1号に規定する要件を満たしていない。

(3)以上のとおり,本願の請求項1の記載が,特許法第36条第6項第2号に規定する要件を満たしておらず,また,本願の発明の詳細な説明の記載は,特許法第36条第4項第1号に規定する要件を満たしていない。


3-2.(理由2)(特許法第29条第2項)について

前記「1.手続きの経緯」で示した,本願の請求項1に係る発明(以下,「本願発明」という。)が,特許法第29条第2項に規定する要件を満たしているかについて以下に検討する。

(1)引用文献に記載されている技術的事項及び引用発明の認定

(1-1)引用文献1
本願の第1国出願前に既に公知であり,当審の拒絶理由通知で引用された,特開2005-31892号公報(平成17年2月3日公開,以下,「引用文献1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

A「【請求項1】
スケジューリングされているジョブ群を実行するジョブ実行システムにおいて,複数種のリソースを備えてジョブの実行を行う複数のリソースマネージャホストと,ジョブ実行の管理を行う統合マネージャホストとを備え,前記リソースマネージャホストは,ジョブ実行中のリソースの状況を監視してリソースエラーを検知するリソースエラー検知手段と,リソースエラーを前記統合マネージャホストに報告するリソースエラー通知手段とを有し,前記統合マネージャホストは,リソースエラーを報告してきたリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定する手段を有することを特徴とするジョブ実行システム。
【請求項2】
スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法において,複数種のリソースを備えてジョブを実行するリソースマネージャホストからのリソースエラーの報告を受け,リソースエラーの報告を行ったリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定することを特徴とするジョブ実行制御方法。」

B「【0025】
リソースマネージャホストのそれぞれは,図2に示すような各種の機能部を備えて構成されており,次に,これらの機能部のそれぞれについて説明する。
【0026】
リソースエラー検知部210は,自リソースマネージャホスト内でのリソースエラーを検知し,リソースエラー通知部220は,取得したリソースエラーの情報を統合マネージャホスト10に対して通知する。
【0027】
リソース情報通知部230は,自リソースマネージャホスト内でどんなリソースがどれだけ不足しているかの情報,及び,ジョブの実行に必要なPP等の情報を統合マネージャホスト10に対し通知する。
【0028】
命令受け付け部240は,統合マネージャホスト10から送信されてきた命令を受け付けて解読する。
【0029】
リソース削除部250は,リソース削除依頼部170から通知された不要と判断された情報によりリソースを解放する。
【0030】
インストール情報受信部260は,ジョブ実行に必要なインストール情報を統合マネージャホスト10から受信し,インストール実行部270は,ジョブ実行に必要な情報をインストールする。」

C「【0035】
図7はリソース情報データの通信プロトコルの例を示す図である。このリソース情報1000は,リソースエラーを生じたリソースマネージャホストが統合マネージャホストに送信する移動したい(実行中だった)ジョブの情報やジョブ実行に必要なPP情報等のリソース情報である。
【0036】
このリソース情報1000は,データの先頭にこのデータがリソース情報データであることを示すリソースデータ開始のフラグを設定し,それに続いて,送信元リソースマネージャホスト名,実行中であったジョブのID,送信日時が設定され,その後ろに,ジョブ実行に必要なメモリ容量,ディスク容量,推奨CPU性能,PP数,PP名とそのバージョンを付け,最後に,このリソース情報データの後に送信するPPのインストールに必要なレジストリファイルのファイル数,PPの緩急設定に必要な情報のファイル数を付与して構成されている。図示例では,2つのPPのPP名1,2があり,それぞれに,バージョン,レジストリファイルのファイル数,情報のファイル数が設定されている。」

以下に,上記引用文献1の記載事項について検討する。

(ア)引用文献1は,上記Aに記載の「【請求項2】」に係る「ジョブ実行制御方法」である発明について説明するものであることから,
引用文献1には,“スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法において,
複数種のリソースを備えてジョブを実行するリソースマネージャホストからのリソースエラーの報告を受け,
リソースエラーの報告を行ったリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定することを特徴とするジョブ実行制御方法”が記載されているといえる。

(イ)上記“リソースマネージャホスト”に関し,
上記Bの「リソースマネージャホストのそれぞれは,図2に示すような各種の機能部を備えて構成されており・・・命令受け付け部240は,統合マネージャホスト10から送信されてきた命令を受け付けて解読する。」との記載から,
上記“リソースマネージャホスト”は,“統合マネージャホストから送信されてきた命令を受け付けて解読する,命令受け付け部を有”することがよみとれる。

(ウ)上記Bに「リソース情報通知部230は,自リソースマネージャホスト内でどんなリソースがどれだけ不足しているかの情報,及び,ジョブの実行に必要なPP等の情報を統合マネージャホスト10に対し通知する。」との記載,及び上記Cに「このリソース情報1000は,リソースエラーを生じたリソースマネージャホストが統合マネージャホストに送信する移動したい(実行中だった)ジョブの情報やジョブ実行に必要なPP情報等のリソース情報である。」との記載があり,上記「リソース情報通知部」から通知される「リソース情報」は,「リソースマネージャホストからのリソースエラーの報告」に当たるものであるから,
上記“リソースマネージャホストからのリソースエラーの報告”は“実行中だったジョブの情報を含む”ことが読み取れる。

以上,(ア)?(ウ)で指摘した事項から,引用文献1には,次の発明(以下,「引用発明」という。)が記載されているものと認める。

スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法において,
複数種のリソースを備えてジョブを実行するリソースマネージャホストからのリソースエラーの報告を受け,
リソースエラーの報告を行ったリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定することを含み,
前記リソースマネージャホストは,統合マネージャホストから送信されてきた命令を受け付けて解読する,命令受け付け部を有し,
リソースマネージャホストからのリソースエラーの報告は,実行中だったジョブの情報を含む,
こと特徴とするジョブ実行制御方法。

(1-2)引用文献2
本願の第1国出願前に既に公知であり,当審の拒絶理由通知で引用された,特開2005-135147号公報(平成17年5月26日公開,以下,「引用文献2」という。)には,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

D「【0005】
ところが,サーバコンピュータからプログラム更新の中止やプログラム更新日時の変更が指令された際に,例えば電源がオフであったりオフラインで動作していたりしたためにその指令を受取れなかった情報処理装置が発生すると,その情報処理装置では,変更前のプログラム更新日時が経過したことに応じて自動的にプログラムが更新されてしまうという問題があった。」

E「【0015】
ここで,本実施の形態では,各POS端末1に実装されているPOS業務プログラムP1が本部のホストコンピュータ4によって一元的に管理されている。そして,バージョンアップ等によってPOS業務プログラムP1に変更が生じた場合には,図4(a)に示すように,プログラムの種類を識別するプログラムIDと更新後のPOS業務プログラムデータQ1とが格納されたプログラムファイル6と,図4(b)に示すように,同一プログラムIDと更新指定日時情報Q2等のプログラム更新情報が格納された更新情報ファイル7と,図4(c)に示すように,同一プログラムIDとバージョンナンバーQ3等のプログラム管理情報が格納された管理情報ファイル8とが,ホストコンピュータ4上で作成される。そして,これらの情報ファイル6,7,8がネットワーク5を介して各店舗のストアコンピュータ2に送信されるものとなっている。」

(1-3)引用文献3
本願の第1国出願前に既に公知であり,当審の拒絶理由通知で引用された,特開2002-189571号公報(平成14年7月5日公開,以下,「引用文献3」という。)には,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

F「【請求項1】上位装置の命令を受けて磁気ディスク装置自体の障害を検出し報告する自己診断機能を有する磁気ディスク装置において,
前記上位装置からの指定によって障害検出時に自己診断を停止するか続行するかを選択することができることを特徴とする磁気ディスク装置。」

(2)本願発明と引用発明との対比

本願発明と引用発明とを対比する。
(2-1)引用発明の「ジョブ」,「スケジューリングされているジョブ群」は,本願発明の「タスク」,「スケジューリング・タスク」にそれぞれ相当し,
また,引用発明の「ジョブ実行制御方法」は,「スケジューリングされているジョブ群の実行」を制御することで「リソースマネージャホスト」を管理しており,また当該「リソースマネージャホスト」は装置といえることから,上記管理は装置管理といえるものである。
したがって,引用発明の「スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法」は,本願発明の「装置管理において,スケジューリング・タスクを処理する方法」に相当する。

(2-2)引用発明の「ジョブ実行制御方法」は,「統合マネージャホストから送信されてきた命令を受け付け」た「リソースマネージャホスト」が「ジョブ」を「実行」するものであり,また,上記「リソースマネージャホスト」は,本願発明の「端末」とともに,上位概念においてコンピュータ装置といえるものであることから,上記「ジョブ実行制御方法」は,統合マネージャホストからコンピュータ装置へ配信された装置管理の処理タスクの処理に適合したものであるといえる。
ここで,引用発明が,上記コンピュータ装置に相当する「リソースマネージャホスト」が複数存在する構成を前提としている一方で,本願発明は,実施例に関する記載等を見ると,コンピュータ装置に相当する「端末」が1つのみ存在する場合が記載されている点で一応の対比が見られる。しかしながら,本願発明はそもそも「装置管理サーバ」が「端末」における「スケジューリング・タスク」の「処理」を管理するものであることから,必ずしも「装置管理サーバ」と「端末」とが1対1対応である構成にのみ限定的に適応可能なものとは解されず,また本願の請求項の記載からも,「装置管理サーバ」と「端末」との1対1対応の構成に限定的に適合可能としているものとはよみとれるものではなく,さらに,適用対象とするサーバと端末の構成関係において相違を認めたとしても,当該相違は,単にタスク管理方法の適用対象として適宜決める程度の事項であることから,いずれにしても,この点をもって実質的な差異とは認められず,また進歩性の判断にも影響を与えない。
そして,引用発明の「統合マネージャホスト」は,本願発明の「装置管理サーバ」に相当することから,
引用発明の「ジョブ実行制御方法」が,「統合マネージャホストから送信されてきた命令を受け付け」た「リソースマネージャホスト」が「ジョブ」を「実行」するものであることと,本願発明の「上記方法は,装置管理サーバから端末へ配信された装置管理の処理タスクの処理に適合するものであ」ることは,ともに,“上記方法は,装置管理サーバからコンピュータ装置へ配信された装置管理の処理タスクの処理に適合するものであ”る点で共通する。

(2-3)引用発明の「リソースマネージャホスト」における「命令受け付け部」が,「スケジューリングされているジョブ群」に関して「統合マネージャホストから送信されてきた命令を受け付け」ることと,本願発明の「装置管理サーバから配信された上記装置管理のスケジューリング・タスクを端末にて受信」することは,ともに,“装置管理サーバから配信された上記装置管理のスケジューリング・タスクをコンピュータ装置にて受信”する点で共通する。

(2-4)本願発明の「追跡情報」とは,それについて具体的に記載された本願発明の詳細な説明の段落【0078】「C) 上記携帯電話機が,タスクの実行(すなわち,追跡情報)を報告する。」等の記載を参酌すると,「端末」における「タスクの実行」に係る情報であると解されることから,上位概念においてタスクの実行情報であるといえ,
一方,引用発明における「リソースエラーの報告」も「実行中だったジョブの情報を含む」ものであることから,タスクの実行情報であるといえる。
したがって,引用発明の「リソースマネージャホスト」から「実行中だったジョブの情報」を含む「リソースエラーの報告」を報告することと,本願発明の「上記端末が,上記タスク追跡ポリシーに基づいて,追跡情報を上記装置管理サーバに報告」することは,ともに,“上記コンピュータ装置が,タスクの実行情報を上記装置管理サーバに報告”する点で共通する。

以上から,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

(一致点)
装置管理において,スケジューリング・タスクを処理する方法であって,
上記方法は,装置管理サーバからコンピュータ装置へ配信された装置管理の処理タスクの処理に適合するものであり,
装置管理サーバから配信された上記装置管理のスケジューリング・タスクをコンピュータ装置にて受信し,
上記コンピュータ装置が,タスクの実行情報を上記装置管理サーバに報告することを特徴とする方法。

(相違点1)
処理タスクについて受信し処理し報告する,コンピュータ装置に関し,
本願発明が「端末」であるのに対し,
引用発明は,「リソースマネージャホスト」である点。

(相違点2)
本願発明が,「上記端末が,上記装置管理の上記スケジューリング・タスクの実行条件および上記装置管理サーバによって配信された上記装置管理の上記スケジューリング・タスクのタスク追跡ポリシーに基づいて,上記装置管理の上記スケジューリング・タスクを追跡」する処理を行っているのに対し,
引用発明は,そのような処理を行うことについて言及されていない点。

(相違点3)
コンピュータ装置による,タスクの実行情報の報告に関し,
本願発明が,「タスク追跡ポリシーに基づいて」,「追跡情報」を報告しているのに対し,
引用発明は,「実行中だったジョブの情報」を含む「リソースエラーの報告」を報告しているが,それが「タスク追跡ポリシーに基づい」たものに当たるかは明りょうでない点。

(相違点4)
本願発明が,「上記タスク追跡ポリシーは,タスクの実行条件が見過ごされ,上記端末が正常実行しなかった場合,上記端末が,上記装置管理サーバに通知する処理を含む」こととしているのに対し,
引用発明は,そのような構成について言及されていない点。

(3)当審の判断
上記相違点1ないし相違点4について検討する。

(3-1)相違点1について
スケジューリングされたジョブの管理を,端末におけるジョブ処理を対象に行うことは,本願の第1国出願前において周知(必要であれば,引用文献2の上記Eの記載を参照)であり,引用発明のスケジューリングされたジョブの管理として,当該周知技術を採用し,端末を対象に行うこと,すなわち,相違点1に係る構成とすることは,当業者が容易に想到し得たことである。
よって,相違点1は格別なものではない。

(3-2)相違点2ないし相違点4について
ここで,本願発明における「タスク追跡ポリシー」及び「タスクの実行条件が見過ごされ」との記載について検討する。
まず,本願発明における「タスク追跡ポリシー」とは,上記「3-1.(理由1)(特許法第36条第4項第1号及び第6項第2号)について」でも述べたとおり,実現されている具体的態様については不明確であるものの,発明の詳細な説明【0050】?【0077】には,「タスク追跡ポリシー」として規定している内容,及び「タスク追跡ポリシー」がOMA DMプロトコルの「Generic Alertメッセージ」として実装されることが説明されており,また,平成24年6月7日付けの回答書では『本発明における「タスク追跡ポリシー」は,スケジューリング・タスクの実行を追跡するためのメカニズムを指しています(段落[0069][0070][0077]参照)。本発明において,タスク追跡ポリシーは,タスクの実行条件が見過ごされ,端末が正常に実行しない場合,端末により装置管理サーバに通知する構成です。出願人は,タスク追跡ポリシーのこの定義は明瞭であると考えており,この用語を許容して頂きたいと考えます。』(注:下線は当審付与)と説明されていて,これらによれば,タスクの実行を追跡するためのメカニズムすなわち仕組に対応するものと解される。なお,当該「タスク追跡ポリシー」の実現手段として,上記発明の詳細な説明【0075】及び【0076】にOMA DMプロトコルの「Generic Alertメッセージ」として実装されることが記載されているが,当該「Generic Alertメッセージ」としての実装は,本願の第1国出願時において当業者に広く知られているOMA-DMのデバイス管理プロトコル中で規定されているものであり,したがって,実現手段において上記「タスク追跡ポリシー」に格別な点は認められない。
また,本願発明における「タスクの実行条件が見過ごされ」とは,同様に,具体的に何のどのような処理を指しているのか不明確であるものの,発明の詳細な説明の段落【0112】の記載等を参酌すると,端末の電源オフによりタスクの実行条件が見過ごされることを含むものに対応すると解される。

それに対し,引用発明の「スケジューリングされているジョブ」に,「実行」に当たり何らかの「スケジューリング」すなわち実行時期等に係る条件が付されることは当業者にとって自明な事項であり,また,同じく引用発明において「実行中」の「ジョブ」が実行できない旨を報告するために,「実行中」の「ジョブ」と実行に必要な条件とを参照して,「ジョブ」が実行できない状態であることを所定の仕組によって判断することで,「ジョブ」の実行状態を追跡し確認することは,必然的に行う技術事項であることから,引用発明において,「実行中だったジョブの情報」を含む「リソースエラーの報告」を行うために,ジョブに係る追跡の仕組として「タスク追跡ポリシー」の如き構成を採用し,ジョブの実行条件と上記「タスク追跡ポリシー」に基づいて,ジョブの状態を「追跡」して確認し,その結果を「追跡情報」として報告することに,格別困難性は認められない。

また,ジョブ状態の確認のための仕組に関する情報を,上位装置から送信するようにすること(必要であれば,引用文献3の上記Fの記載を参照),及び,ジョブの実行条件が見過ごされ正常実行しなかった場合として,装置電源オフによるジョブの異常実行を含むこと(必要であれば,引用文献2の上記Dの記載を参照)は,いずれも本願の第1国出願前に周知であり,特に後者の周知技術である装置電源オフによるジョブの異常実行という(見過ごされ)実行不正後に把握される事象と,ジョブ実行中のリソースエラーによるジョブの実行不可という実行不正中に把握されうる事象とは,いずれもよく知られた事象であって報告対象とする点においては適宜決める程度の事項であることから,引用発明における「実行中」の「ジョブの情報」を含むエラーの報告を行う際に,確認の仕組みに関する情報として上記前者の周知技術を,また,報告する対象であるジョブの実行不正内容として上記後者の周知技術を,それぞれ適用することは,当業者であれば適宜なし得ることである。

してみると,引用発明における「実行中だったジョブの情報」を含む「リソースエラーの報告」に対し,上記周知技術を適用し,「上記端末が,上記装置管理サーバによって配信された,上記装置管理の上記スケジューリング・タスクのタスク追跡ポリシー,および,上記装置管理の上記スケジューリング・タスクの実行条件に基づいて,上記装置管理の上記スケジューリング・タスクを追跡」するように行うとともに,「タスク追跡ポリシーに基づいて」,「追跡情報」を報告し,また,「上記タスク追跡ポリシーは,タスクの実行条件が見過ごされ,上記端末が正常実行しなかった場合,上記端末が,上記装置管理サーバに通知する処理を含む」こととすること,すなわち,相違点2ないし相違点4に係る構成とすることは,当業者が容易に想到し得たことである。
よって,相違点2ないし相違点4は格別のものではない。

(3-3)小括

上記で検討したごとく,相違点1ないし相違点4は格別のものではなく,そして,これらの相違点を総合的に勘案しても,本願発明の奏する作用効果は,上記引用発明,及び周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。

したがって,本願発明は,上記引用発明,及び周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項に規定する要件を満たしておらず,特許を受けることができない。


4.むすび
以上のとおり,本願の請求項1の記載は,特許法第36条第6項第2号に規定する要件を満たしておらず,また,また,本願の発明の詳細な説明の記載は,特許法第36条第4項第1号に規定する要件を満たしておらず,また,本願の請求項1に係る発明は,引用発明,及び周知技術に基づいて当業者が容易になし得たものであるから,他の請求項について検討するまでもなく,本願は特許法第29条第2項に規定する要件を満たしておらず,したがって,特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2013-07-31 
結審通知日 2013-08-06 
審決日 2013-08-21 
出願番号 特願2008-530305(P2008-530305)
審決分類 P 1 8・ 121- WZ (G06F)
P 1 8・ 536- WZ (G06F)
P 1 8・ 537- WZ (G06F)
最終処分 不成立  
前審関与審査官 北元 健太吉田 美彦  
特許庁審判長 仲間 晃
特許庁審判官 山崎 達也
飯田 清司
発明の名称 装置管理において、スケジューリング・タスクを処理するための方法およびシステム  
代理人 特許業務法人原謙三国際特許事務所  

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