【事件の表示】
　特願２０１１−２３９２９５「情報処理システム、情報処理装置、クライアント端末、情報処理方法、及びプログラム」拒絶査定不服審判事件〔平成２５年　５月２０日出願公開、特開２０１３−　９７５４８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
第１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，平成２３年１０月３１日の出願であって，その手続の経緯は以下のとおりである。
　
　　平成２６年　７月　１日　　　：出願審査請求書の提出
　　平成２７年　１月２１日付け　：拒絶理由の通知
　　平成２７年　３月２３日　　　：意見書，手続補正書の提出
　　平成２７年　３月３１日付け　：拒絶査定
　　平成２７年　７月　６日　　　：審判請求書，手続補正書の提出
　　平成２７年１０月２９日　　　：前置報告　
　
　
第２　平成２７年７月６日付けの手続補正についての補正却下の決定　 
　
 ［補正却下の決定の結論］ 
　
　平成２７年７月６日付けの手続補正を却下する。
　
 ［理由］ 
　
 １　補正の内容
　
（１）平成２７年７月６日付けの手続補正（以下，「本件補正」という。）の内容は，平成２７年３月２３日付けの手続補正により補正された特許請求の範囲の請求項１乃至１９の記載
　
「　　【請求項１】
　クライアント端末と，
　このクライアント端末を管理する管理サーバと
　を含み，
　前記クライアント端末は，
　少なくとも自機の稼働状態を示す情報が含まれた通知データを，前記管理サーバに送信する送信手段と，
　前記送信手段により送信された通知データの返信情報に応じて，タスクの実行に必要な前処理を行う前処理手段と，
　前記前処理手段により前処理が行われた後に，タスクを実行する実行手段と
　を有し，
　前記管理サーバは，
　前記クライアント端末からの通知データに対して，返信情報を返信する返信手段と，
　前記返信情報に，前記クライアント端末のタスクに関するタスク情報を挿入する情報挿入手段と
　を有する情報処理システム。
　　【請求項２】
　クライアント端末からの通知データに対して，返信情報を返信する返信手段と，
　前記返信情報に，前記クライアント端末による，タスク実行の要否の判断に必要であるタスク情報を挿入する情報挿入手段と
　を有する情報処理装置。
　　【請求項３】
　前記情報挿入手段は，前記タスク情報として，タスク種別，タスクの実行に要する時間を示す情報，タスクの優先順位，関連する他のタスクを示す情報，配信ファイルの有無，配信ファイルのデータサイズ，及び，タスクに要するデータファイルの版数，の少なくとも一つを挿入する
　請求項２に記載の情報処理装置。
　　【請求項４】
　前記情報挿入手段は，前記タスク情報として，タスクの実行に必要なデータファイルを要求すべきタイミングを示す情報を挿入する
　請求項２に記載の情報処理装置。
　　【請求項５】
　クライアント端末が通知データを送信すべき間隔を示すデータ通知間隔を設定する間隔設定手段
　をさらに有し，
　前記情報挿入手段は，前記返信情報に，前記間隔設定手段により変更されたデータ通知間隔を挿入する
　請求項２に記載の情報処理装置。
　　【請求項６】
　タスクの優先順位とデータ通知間隔とに関連付けられて，タスク情報を格納するタスク情報格納手段
をさらに有し，
　前記情報挿入手段は，前記タスク情報格納手段に格納されている前記タスク情報の中から，前記優先順位に応じた順序で，タスク情報と，そのタスクに関連付けられたデータ通知間隔とを挿入する
　請求項５に記載の情報処理装置。
　　【請求項７】
　前記タスク情報格納手段は，直列的な順序で実行すべき複数のタスクを，関連タスクとして互いに関連付けて格納し，
　前記情報挿入手段は，前記タスク情報格納手段に関連タスクとして格納された複数のタスクのタスク情報を，連続する複数の通知データに対する返信情報に，順に挿入する
　請求項６に記載の情報処理装置。
　　【請求項８】
　少なくとも自機の稼働状態を示す情報が含まれた通知データを，外部装置に送信する送信手段と，
　前記送信手段により送信された通知データの返信情報に応じて，タスクの実行に必要な前処理を行う前処理手段と，
　前記前処理手段により前処理が行われた後に，タスクを実行する実行手段とを有するクライアント端末。
　　【請求項９】
　前記返信情報には，タスクの種別を示すタスク種別が含まれており，
　前記前処理手段は，前記タスク種別に基づいて，タスク実行の要否を判断し，
　前記実行手段は，前記前処理手段によりタスクの実行が必要であると判断された場合に，このタスクを実行する
　請求項８に記載のクライアント端末。
　　【請求項１０】
　前記返信情報には，データファイルを要求するタイミングを指定する情報が含まれており，
　前記前処理手段は，前記返信情報により指定されたタイミングで，データファイルを取得し，
　前記実行手段は，前記前処理手段により取得されたデータファイルを用いて，タスクを実行する
　請求項９に記載のクライアント端末。
　　【請求項１１】
　前記返信情報には，次に実行すべきタスクの存在を示す関連タスク情報が含まれており，
　前記前処理手段は，前記返信情報に含まれる関連タスク情報に応じて，タスクの実行完了を，次に実行すべきタスクの要求情報として外部装置に通知する
　請求項８に記載のクライアント端末。
　　【請求項１２】
　前記送信手段は，送信した通知データに対応する返信情報が既定の期間に受信できなかった場合，通知データの送信間隔を自機のデフォルト値に戻す
　請求項８に記載のクライアント端末。
　　【請求項１３】
　前記返信情報には，タスクの優先順位を示す情報が含まれており，
　前記前処理手段は，前記実行手段により実行されているタスクの優先順位と，前記返信情報により通知されたタスクの優先順位とを比較し，通知されたタスクの優先順位が実行中のタスクよりも高い場合に，実行中のタスクをキャンセルし，
　前記前処理手段によりタスクがキャンセルされた旨を，前記外部装置に通知するタスク制御手段
をさらに有する請求項８に記載のクライアント端末。
　　【請求項１４】
　前記タスク制御手段は，互いに関連付けられた複数のタスクのいずれかが失敗した場合に，実行済みの他の関連付けられたタスクを，実行前の状態に戻し，関連タスクをキャンセルした旨を外部装置に通知する
　請求項１３に記載のクライアント端末。
　　【請求項１５】
　前記タスク制御手段は，互いに関連付けられた複数のタスクよりも優先順位の高いタスクが前記返信情報により通知された場合に，実行済みの関連付けられたタスクを，実行前の状態に戻し，関連タスクをキャンセルした旨を外部装置に通知する
　請求項１３に記載のクライアント端末。
　　【請求項１６】
　前記送信手段は，タスクの実行中に，通知データを送信するタイミングが到来した場合，タスクの進捗情報を外部装置に通知する
　請求項８に記載のクライアント端末。
　　【請求項１７】
　クライアント端末が，少なくとも自機の稼働状態を示す情報が含まれた通知データを，
管理サーバに送信するステップと，
　前記管理サーバが，前記クライアント端末から受信した通知データに対する返信情報に，タスクに関するタスク情報を挿入するステップと，
　前記管理サーバが，前記タスク情報が挿入された返信情報を，前記クライアント端末に返信するステップと，
　前記クライアント端末が，前記返信情報に挿入されたタスク情報に応じて，タスクの前処理を行うステップと
　を有する情報処理方法。
　　【請求項１８】
　クライアント端末からのデータ通知に対して返信情報を返信するステップと，
　前記返信情報に，前記クライアント端末による，タスク実行の要否の判断に必要であるタスク情報を挿入するステップと
　をコンピュータに実行させるプログラム。
　　【請求項１９】
　少なくとも自機の稼働状態を示す情報が含まれた通知データを，送信するステップと，
　送信された前記通知データの返信情報に応じて，タスクの実行に必要な前処理を行うステップと，
　前処理後に，タスクを実行する実行ステップと
　をコンピュータに実行させるプログラム。」（以下，この特許請求の範囲に記載された請求項を「補正前の請求項」という。）
　
を，
　
「　　【請求項１】
　クライアント端末と，
　このクライアント端末を管理する管理サーバと
　を含み，
　前記クライアント端末は，
　少なくとも自機の稼働状態を示す情報が含まれた通知データを，前記管理サーバに送信する送信手段と，
　前記送信手段により送信された通知データの返信情報に応じて，タスクの実行に必要な前処理を行う前処理手段と，
　前記前処理手段により前処理が行われた後に，タスクを実行する実行手段と
　を有し，
　
前記前処理手段は，前記返信情報に基づいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し，
　
前記実行手段は，前記前処理手段により決定されたタイミングに基づいて，タスクを実行し，
　前記管理サーバは，
　前記クライアント端末からの通知データに対して，返信情報を返信する返信手段と，
　前記返信情報に，前記クライアント端末のタスクに関するタスク情報を挿入する情報挿入手段と
　を有する情報処理システム。
　　【請求項２】
　クライアント端末からの通知データに対して，返信情報を返信する返信手段と，
　前記返信情報に，前記クライアント端末
がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段と
　を有する情報処理装置。
　　【請求項３】
　前記情報挿入手段は，前記タスク情報として，タスク種別，タスクの実行に要する時間を示す情報，タスクの優先順位，関連する他のタスクを示す情報，配信ファイルの有無，配信ファイルのデータサイズ，及び，タスクに要するデータファイルの版数，の少なくとも一つを挿入する
　請求項２に記載の情報処理装置。
　　【請求項４】
　前記情報挿入手段は，前記タスク情報として，タスクの実行に必要なデータファイルを要求すべきタイミングを示す情報を挿入する
　請求項２に記載の情報処理装置。
　　【請求項５】
　クライアント端末が通知データを送信すべき間隔を示すデータ通知間隔を設定する間隔設定手段
　をさらに有し，
　前記情報挿入手段は，前記返信情報に，前記間隔設定手段により変更されたデータ通知間隔を挿入する
　請求項２に記載の情報処理装置。
　　【請求項６】
　タスクの優先順位とデータ通知間隔とに関連付けられて，タスク情報を格納するタスク情報格納手段
　をさらに有し，
　前記情報挿入手段は，前記タスク情報格納手段に格納されている前記タスク情報の中から，前記優先順位に応じた順序で，タスク情報と，そのタスクに関連付けられたデータ通知間隔とを挿入する
　請求項５に記載の情報処理装置。
　　【請求項７】
　前記タスク情報格納手段は，直列的な順序で実行すべき複数のタスクを，関連タスクとして互いに関連付けて格納し，
　前記情報挿入手段は，前記タスク情報格納手段に関連タスクとして格納された複数のタスクのタスク情報を，連続する複数の通知データに対する返信情報に，順に挿入する
　請求項６に記載の情報処理装置。
　　【請求項８】
　少なくとも自機の稼働状態を示す情報が含まれた通知データを，外部装置に送信する送信手段と，
　前記送信手段により送信された通知データの返信情報に応じて，タスクの実行に必要な前処理を行う前処理手段と，
　前記前処理手段により前処理が行われた後に，タスクを実行する実行手段と
　を有し，
　
前記前処理手段は，前記返信情報に基づいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し，
　
前記実行手段は，前記前処理手段により決定されたタイミングに基づいて，タスクを実行する
　クライアント端末。
　　【請求項９】
　前記返信情報には，タスクの種別を示すタスク種別が含まれており，
　前記前処理手段は，前記タスク種別に基づいて，タスク実行の要否を判断し，
　前記実行手段は，前記前処理手段によりタスクの実行が必要であると判断された場合に，このタスクを実行する
　請求項８に記載のクライアント端末。
　　【請求項１０】
　前記返信情報には，データファイルを要求するタイミングを指定する情報が含まれており，
　前記前処理手段は，前記返信情報により指定されたタイミングで，データファイルを取得し，
　前記実行手段は，前記前処理手段により取得されたデータファイルを用いて，タスクを実行する
　請求項９に記載のクライアント端末。
　　【請求項１１】
　前記返信情報には，次に実行すべきタスクの存在を示す関連タスク情報が含まれており，
　前記前処理手段は，前記返信情報に含まれる関連タスク情報に応じて，タスクの実行完了を，次に実行すべきタスクの要求情報として外部装置に通知する
　請求項８に記載のクライアント端末。
　　【請求項１２】
　前記送信手段は，送信した通知データに対応する返信情報が既定の期間に受信できなかった場合，通知データの送信間隔を自機のデフォルト値に戻す
　請求項８に記載のクライアント端末。
　　【請求項１３】
　前記返信情報には，タスクの優先順位を示す情報が含まれており，
　前記前処理手段は，前記実行手段により実行されているタスクの優先順位と，前記返信情報により通知されたタスクの優先順位とを比較し，通知されたタスクの優先順位が実行中のタスクよりも高い場合に，実行中のタスクをキャンセルし，
　前記前処理手段によりタスクがキャンセルされた旨を，前記外部装置に通知するタスク制御手段
をさらに有する請求項８に記載のクライアント端末。
　　【請求項１４】
　前記タスク制御手段は，互いに関連付けられた複数のタスクのいずれかが失敗した場合に，実行済みの他の関連付けられたタスクを，実行前の状態に戻し，関連タスクをキャンセルした旨を外部装置に通知する
　請求項１３に記載のクライアント端末。
　　【請求項１５】
　前記タスク制御手段は，互いに関連付けられた複数のタスクよりも優先順位の高いタスクが前記返信情報により通知された場合に，実行済みの関連付けられたタスクを，実行前の状態に戻し，関連タスクをキャンセルした旨を外部装置に通知する
　請求項１３に記載のクライアント端末。
　　【請求項１６】
　前記送信手段は，タスクの実行中に，通知データを送信するタイミングが到来した場合，タスクの進捗情報を外部装置に通知する
　請求項８に記載のクライアント端末。
　　【請求項１７】
　クライアント端末が，少なくとも自機の稼働状態を示す情報が含まれた通知データを，
管理サーバに送信するステップと，
　前記管理サーバが，前記クライアント端末から受信した通知データに対する返信情報に，タスクに関するタスク情報を挿入するステップと，
　前記管理サーバが，前記タスク情報が挿入された返信情報を，前記クライアント端末に返信するステップと，
　前記クライアント端末が，前記返信情報に挿入されたタスク情報に応じて，タスクの前処理を行うステップと
　を有
し，
　
前記タスクの前処理を行うステップにおいて，前記返信情報に基づいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定する
　情報処理方法。
　　【請求項１８】
　クライアント端末からのデータ通知に対して返信情報を返信するステップと，
　前記返信情報に，前記クライアント端末
がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための
　をコンピュータに実行させるプログラム。
　　【請求項１９】
　少なくとも自機の稼働状態を示す情報が含まれた通知データを，送信するステップと，
　送信された前記通知データの返信情報に応じて，タスクの実行に必要な前処理を行うステップと，
　前処理後に，タスクを実行する実行ステップと
　をコンピュータに実行させ，
　
前記タスクの前処理を行うステップにおいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し，
　
前記タスクを実行するステップにおいて，前記タスクの前処理を行うステップにおいて決定されたタイミングに基づいて，タスクを実行させる
　プログラム。」（当審注：下線は，請求人が付与したものである。以下，この特許請求の範囲に記載された請求項を「補正後の請求項」という。）　
　
に補正するものである。
　
（２）補正前の請求項と，補正後の請求項とを比較すると，補正後の請求項１乃至１９はそれぞれ，補正前の請求項１乃至１９に対応することは明らかである。
　
（３）本件補正は，下記の補正事項１乃至７よりなるものである。
　
＜補正事項１＞　
　補正前の請求項１，８の
「前記送信手段により送信された通知データの返信情報に応じて，タスクの実行に必要な前処理を行う前処理手段と，…（中略）…を有し，」との記載を，
　補正後の請求項１，８の
「前記送信手段により送信された通知データの返信情報に応じて，タスクの実行に必要な前処理を行う前処理手段と，…（中略）…を有し，
　前記前処理手段は，前記返信情報に基づいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し，」との記載に変更する補正。
　
＜補正事項２＞　
　補正前の請求項１，８の
「前記前処理手段により前処理が行われた後に，タスクを実行する実行手段と…（中略）…を有し，」との記載を，
　補正後の請求項１，８の
「前記前処理手段により前処理が行われた後に，タスクを実行する実行手段と…（中略）…を有し，
　前記実行手段は，前記前処理手段により決定されたタイミングに基づいて，タスクを実行し，」との記載に変更する補正。
　
＜補正事項３＞　
　補正前の請求項２の
「前記返信情報に，前記クライアント端末による，タスク実行の要否の判断に必要であるタスク情報を挿入する情報挿入手段」との記載を，
　補正後の請求項２の
「前記返信情報に，前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段」との記載に変更する補正。
　
＜補正事項４＞　
　補正前の請求項１７の
「前記クライアント端末が，前記返信情報に挿入されたタスク情報に応じて，タスクの前処理を行うステップと
　を有する」との記載を，
　補正後の請求項１７の
「前記クライアント端末が，前記返信情報に挿入されたタスク情報に応じて，タスクの前処理を行うステップと
　を有し，
　前記タスクの前処理を行うステップにおいて，前記返信情報に基づいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定する」との記載に変更する補正。
　
＜補正事項５＞　
　補正前の請求項１８の
「前記返信情報に，前記クライアント端末による，タスク実行の要否の判断に必要であるタスク情報を挿入するステップ」との記載を，
　補正後の請求項１８の
「前記返信情報に，前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入するステップ」との記載に変更する補正。
　
＜補正事項６＞　
　補正前の請求項１９の
「送信された前記通知データの返信情報に応じて，タスクの実行に必要な前処理を行うステップと，」との記載を，
　補正後の請求項１９の
「送信された前記通知データの返信情報に応じて，タスクの実行に必要な前処理を行うステップと，
…（中略）…
　前記タスクの前処理を行うステップにおいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し，」との記載に変更する補正。
　
＜補正事項７＞　
　補正前の請求項１９の
「前処理後に，タスクを実行する実行ステップと」との記載を，
　補正後の請求項１９の
「前処理後に，タスクを実行する実行ステップと
…（中略）…
　前記タスクを実行するステップにおいて，前記タスクの前処理を行うステップにおいて決定されたタイミングに基づいて，タスクを実行させる」との記載に変更する補正。
　
　
２　新規事項追加禁止要件
　
　本件補正が，特許法第１７条の２第３項の規定を満たすものであるか否か，即ち，本件補正が願書に最初に添付された明細書，特許請求の範囲又は図面（以下，これを「当初明細書等」という。）の範囲内でなされたものであるかについて，以下に検討する。
　
（１）上記「１　補正の内容　（３）」において指摘した具体的補正事項１乃至７のうち，補正事項３において指摘した，補正後の請求項２及び請求項１８の「前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」という記載は，当初明細書等には記載されていない表現である。
　そこで，上記指摘の記載が，当初明細書等に記載された内容から読み取れるかについて以下に検討する。
　当初明細書等の特許請求の範囲には，「タスク情報」について，上記指摘の補正後の請求項２及び請求項１８に記載された表現と同一のものは存在しない。また，当初明細書等の特許請求の範囲には，その請求項２に「前記クライアント端末が実行すべきタスクに関するタスク情報」，その請求項３に「前記タスク情報として，タスク種別，タスクの実行に要する時間を示す情報，タスクの優先順位，関連する他のタスクを示す情報，配信ファイルの有無，配信ファイルのデータサイズ，及び，タスクに要するデータファイルの版数，の少なくとも一つ」，その請求項４に「前記タスク情報として，タスクの実行に必要なデータファイルを要求すべきタイミングを示す情報」，その請求項１１に「次に実行すべきタスクの存在を示す関連タスク情報」，その請求項１８に「前記クライアント端末のタスクに関するタスク情報」との記載があるものの，補正後の請求項２及び請求項１８のような，「クライアント端末がタスク実行の要否を判断」することと，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とする「タスク情報」の具体的な態様については記載されていない。
　
　次に当初明細書等の発明の詳細な説明について検討すると，「タスク情報」に関して，段落【００３１】に（当審注：下線は，参考のために当審で付与したものである。），
「【００３１】
　図３は，タスク管理部５４０をより詳細に説明する図である。
…（中略）…
　タスク管理部５４０は，タスク情報の取得や更新をタスク情報ＤＢ６２０に対して行う。
ここで，タスク情報とは，タスクに関する情報であり，例えば，タスクの属性情報などである
　図４は，タスク情報管理テーブルを例示する図である。
　
図４に例示するように，タスク情報管理テーブルは，タスク情報ＩＤ，タスク種別，タスクの優先順位，関連タスクＩＤ，配信ファイルの有無，データサイズ，版数，適用所要時間を保持する。配信ファイルの有無は，タスクの実行に必要なデータファイルをクライアント端末９に送信する必要があるかどうかを示す。本例のタスク情報には，さらに，タスクに必要なデータファイルを要求すべきタイミングと，タスクに紐づくデータ通知間隔とが含まれる。タスク種別は，タスクの種別を示す。タスクの優先順位とは，タスクの実行の優先順位を示す。関連タスクＩＤとは，互いに関連付けられた他のタスクを識別するための情報であり，例えば，次に実行すべきタスクのＩＤである。データサイズとは，配信ファイル（すなわち，タスクの実行に要するデータファイル）のデータサイズである。版数とは，配信ファイルの版数である。適用所要時間とは，タスクの実行に要する目安時間である。
　と記載され，「タスク情報」の具体的態様として，「タスク情報ＩＤ」，「タスク種別」，「タスクの優先順位」，「関連タスクＩＤ」，「配信ファイルの有無」，「データサイズ」，「版数」，「適用所要時間」，「タスクに必要なデータファイルを要求すべきタイミング」，「タスクに紐づくデータ通知間隔」が読み取れる。
　そして，上記の「タスク情報」の具体的態様のうち，「タスク種別」，「タスクの優先順位」は，段落【００３８】に，
「【００３８】
　タスク制御部７２０は，タスクの実行に必要な前処理を行い，タスクを実行する。タスク制御部７２０は，図６に例示するように，タスク判断部７２２と，タスク取得通知部７２４と，タスク適用部７２６とを有する。
　
タスク判断部７２２は，管理サーバ５より通知された返信情報に含まれるタスク種別に基づいて，タスク実行の要否を判断する。例えば，タスク判断部７２２は，タスク種別に基づいて，タスクが自身に対して適用可能なタスクかどうかを判断する。さらに，タスク判断部７２２は，自身の現在の処理状態を取得し，タスク適用が可能な状態かどうかを判断する。現在処理中のタスクが存在した場合は，タスク判断部７２２は，現在処理中のタスクの優先順位と，管理サーバ５より通知されたタスクの優先順位とを比較し，優先順位によって現在のタスクについて，「続行」又は「キャンセル」をタスク適用部７２６に指示する。
　と記載され，同じく，段落【００４４】に，
「【００４４】
　図９は，クライアント端末９の優先順位に基づいたタスクの適用処理（Ｓ８０）である。
　
図９に例示するように，ステップ８００（Ｓ８００）において，ハートビート送信部７００は，管理サーバ５からハートビート通知の応答としてタスク情報を受信する。
　ステップ８０５（Ｓ８０５）において，タスク判断部７２２は，適用中のタスクが存在するか確認する。存在した場合は，優先順位に基づいたタスクの適用処理（Ｓ８０）は，Ｓ８１０へ移行し，存在しない場合は，優先順位に基づいたタスクの適用処理（Ｓ８０）は，Ｓ８３０へ移行する。
　
ステップ８１０（Ｓ８１０）において，タスク判断部７２２は，通知されたタスクと適用中のタスクの優先順位を比較する。通知タスクの優先順位が高ければ，優先順位に基づいたタスクの適用処理（Ｓ８０）は，Ｓ８１５へ移行する。通知タスクの優先順位が低ければ，優先順位に基づいたタスクの適用処理（Ｓ８０）は，Ｓ８２５へ移行する。
　ステップ８１５（Ｓ８１５）において，タスク判断部７２２は，現在実行中のタスクのキャンセルをタスク適用部７２６に通知し，タスク適用部７２６は，適用中のタスクをキャンセルする。
…（中略）…
　ステップ８３５（Ｓ８３５）において，タスク適用部７２６は，タスクを適用し，適用結果をハートビート送信部７００へ通知する。ハートビート送信部７００は，管理サーバ５にタスク適用結果を通知する。」
　と記載されるように，「クライアント端末がタスク実行の要否を判断する」ための「タスク情報」であると解されるものの，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」であることを読み取ることができない。
　一方，上記の「タスク情報」の具体的態様のうち，「タスクに必要なデータファイルを要求すべきタイミング」，「タスクに紐づくデータ通知間隔」は，段落【００４８】に，
「　【００４８】
　以上説明したように，本実施形態のデータ通信システム１において，クライアント端末９は，ハートビートを用いて，自機の稼働状況を管理サーバ５へ定期的に通知し，管理サーバ５は，ハートビートの返信情報に，タスクに要するデータファイルのデータサイズなどのタスク情報を挿入してクライアント端末９へ通知する。　…（中略）…　さらに，クライアント端末９は，タスク情報として，タスクの種別を取得するため，タスク実行の要否を独自に判断できる。
また，クライアント端末９は，タスク情報として，タスクに要する推定処理時間や，タスクに要するデータファイルの配信期間などを取得するため，自機の都合に合わせて，データファイルの取得タイミングや，タスクの実行タイミングなどを決定できる。
　と記載されるように，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」であると解されるものの，「クライアント端末がタスク実行の要否を判断する」ための「タスク情報」であることを読み取ることができない。
　すなわち，当初明細書等の発明の詳細な説明には，「クライアント端末がタスク実行の要否を判断」するための「タスク情報」と，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」を異なる態様として例示されているものの，補正後の請求項２及び請求項１８のような，「クライアント端末がタスク実行の要否を判断」することと，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とする「タスク情報」の具体的な態様については記載されていない。
　また，当初明細書等のその他の箇所を参酌しても，「前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」を直接的にも間接的にも示唆する記載は見あたらない。
　そうすると，補正前の請求項２及び請求項１８の「前記クライアント端末による，タスク実行の要否の判断に必要であるタスク情報」との記載を，補正後の請求項２及び請求項１８の「前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」との記載に変更する上記補正事項３は，当初明細書等の記載の範囲内でなされたものではない。
　
　よって，上記補正事項３を含む本件補正は，当初明細書等の記載の範囲内でなされたものではない。 
 　 
 （２）新規事項追加禁止要件のむすび 
　
　したがって，本件補正は，特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　
３　目的要件
　
　上記「２　新規事項追加禁止要件」において指摘したとおり，本件補正は，特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものであるが，
　仮に，本件補正が，当初明細書等の記載の範囲内でなされたものであるとして，特許法第１７条の２第５項の規定を満たすものであるか否か，すなわち，本件補正が，特許法第１７条の２第５項に規定する請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る），誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）の何れかを目的としたものであるかについて，以下に検討する。　
　
（１）補正事項１，２について
　
　補正事項１は，発明特定事項である「前記送信手段により送信された通知データの返信情報に応じて，タスクの実行に必要な前処理を行う前処理手段」に，「前記前処理手段は，前記返信情報に基づいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し，」の限定を加え，
　補正事項２は，発明特定事項である「前記前処理手段により前処理が行われた後に，タスクを実行する実行手段」に，「前記実行手段は，前記前処理手段により決定されたタイミングに基づいて，タスクを実行し，」の限定を加えることを目的とするものであり，本件補正によっても，補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。
　
（２）補正事項３，５について
　
　補正事項３は，「前記返信情報に，前記クライアント端末による，タスク実行の要否の判断に必要であるタスク情報を挿入する情報挿入手段」を，「前記返信情報に，前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段」に変更することは，「タスク情報」について「前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための」情報内容を追加するものであり，限定を目的とするものとは認められない。
　また，補正事項５についても，補正事項３と同様，「タスク情報」について「前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための」情報内容を追加するものであり，限定を目的とするものとは認められない。
　そして，補正事項３，５は，請求項の削除，誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）のいずれにも該当しない。
　
（３）補正事項４について
　
　補正事項４は，発明特定事項である「前記クライアント端末が，前記返信情報に挿入されたタスク情報に応じて，タスクの前処理を行うステップ」に，「前記タスクの前処理を行うステップにおいて，前記返信情報に基づいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定する」の限定を加えることを目的とするものであり，本件補正によっても，補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。
　
（４）補正事項６，７について
　
　補正事項６，７は，発明特定事項である「送信された前記通知データの返信情報に応じて，タスクの実行に必要な前処理を行うステップ」に，「前記タスクの前処理を行うステップにおいて，タスク実行の要否を判断し，タスク実行の必要がある場合に，自機のリソース状況と，返信情報に含まれるタスクのデータサイズとに基づいて，タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し，」の限定を加え，「前処理後に，タスクを実行する実行ステップ」に，「前記タスクを実行するステップにおいて，前記タスクの前処理を行うステップにおいて決定されたタイミングに基づいて，タスクを実行させる」の限定を加えることを目的とするものであり，本件補正によっても，補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。
　
（５）目的要件のむすび
　
　したがって，上記補正事項１，２，４，６，７は限定的減縮を目的とするものであるものの，上記補正事項３，５の目的は請求項の削除，限定的減縮，誤記の訂正，不明瞭な記載の釈明の何れにも該当しないものである。　
　
　してみると，本件補正は，特許法第１７条の２第５項第１号の請求項の削除，同条同項第２号の特許請求の範囲の減縮（第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。），同条同項第３項の誤記の訂正，同条同項第４項の明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）を目的とするものに限られるものではない。
　
　したがって，本件補正は，特許法第１７条の２第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。　
　
　
４　独立特許要件
　
　上記「２　新規事項追加禁止要件」において指摘したとおり，本件補正は，特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものであり，
　上記「３　目的要件」において指摘したとおり，本件補正は，特許法第１７条の２第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものであるが，
　仮に，本件補正が，当初明細書等の記載の範囲内でなされたものであるとし，特許請求の範囲の減縮（限定的減縮）を目的とする場合，限定的減縮を目的として補正された補正後の請求項２に記載された発明が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか）以下に検討する。
　
４−１　特許法第３６条（記載要件）について　
　
（１）上記「２　新規事項追加禁止要件」で指摘したとおり，当初明細書等においては，「クライアント端末がタスク実行の要否を判断」するための「タスク情報」と，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」が異なる態様として例示されているに過ぎず，補正後の請求項２で特定される「前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」が記載されていると認めることはできず，他のすべての記載を総合しても，導き出し得るものではない。
　そうすると，補正後の請求項２に係る事項は，本願明細書の発明の詳細な説明に記載されていないものである。
　よって，補正後の特許請求の範囲の記載は，特許法第３６条第６項第１号に規定する要件を満たしていない。
　
（２）上記（１）で指摘のとおり，本願明細書の発明の詳細な説明には，補正後の請求項２のような，「クライアント端末がタスク実行の要否を判断」することと，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とする「タスク情報」の具体的な態様については記載されておらず，当該技術分野の技術常識を考慮しても補正後の請求項２で特定されるような「タスク情報」を如何に実現するか不明であるから，本願明細書の発明の詳細な説明は，請求項２に係る発明について，当業者がその実施をすることができる程度に明確かつ十分に記載したものではない。
　よって，本願明細書の発明の詳細な説明の記載は，特許法第３６条第４項第１号に規定する要件を満たしていない。
　
（３）補正後の請求項２の発明特定事項である「前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」が如何なる「タスク情報」であるか不明であり，「タスク情報」に基いてどのように「クライアント端末がタスク実行の要否を判断」することと，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とするか不明であるから，補正後の請求項２の「前記返信情報に，前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段」が特定する情報処理も不明確である。
　この点に関し，本願明細書の発明の詳細な説明を参酌しても，「クライアント端末がタスク実行の要否を判断」するための「タスク情報」と，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」が異なる態様として例示されているに過ぎず，補正後の請求項２で特定される，両者を同時に可能とする「タスク情報」を具体的に把握することはできない。
　してみると，補正後の請求項２に係る発明は，明確でない。
　
（３）小括
　
　よって，補正後の発明の詳細な説明及び特許請求の範囲の記載は，特許法第３６条第４項第１号，第６項第１号および第２号に規定する要件を満たしておらず，補正後の請求項２に係る発明は，特許出願の際独立して特許を受けることができないものである。
　
　
４−２　特許法第２９条第２項（進歩性）について　
　
（１）本件補正発明
　
　上記平成２７年７月６日付けの手続補正により補正された特許請求の範囲の請求項２には，
「　クライアント端末からの通知データに対して，返信情報を返信する返信手段と，
　前記返信情報に，前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段と
　を有する情報処理装置。」　
と記載されている。
　ここで，上記「２　新規事項追加禁止要件」で指摘したとおり，当初明細書等の発明の詳細な説明には，「クライアント端末がタスク実行の要否を判断」することと，「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とする「タスク情報」の具体的な態様については記載されていないことから，以下では，補正後の請求項２の「前記クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」が，本願明細書の発明の詳細な説明に記載されるような，「前記クライアント端末がタスク実行の要否を判断」するための情報，および「前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための」情報からなる「タスク情報」を意味するものとして検討する。
　
　そこで，本件補正発明は次のとおりのものとして，以下の検討を行う。
「　クライアント端末からの通知データに対して，返信情報を返信する返信手段と，
　前記返信情報に，前記クライアント端末がタスク実行の要否を判断するための情報，および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなるタスク情報を挿入する情報挿入手段と
　を有する情報処理装置。」
　
　
（２）引用例
　
（２−１）引用例１に記載されている技術的事項および引用発明
　
ア　本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である平成２７年１月２１日付けの拒絶理由通知において引用された，特開２００７−３３４８９８号公報（平成１９年１２月２７日出願公開，以下，「引用例１」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「【０００８】
　以下本発明の実施例を，図面を参照して説明する。この実施例はクライアントがサーバに対して要求情報であるハートビート・データを定期的に送信して当該クライアントがそのサーバに現在アクセス中であることを知らせる。サーバは，その種のハートビート・データの発信に応答して新規或いは更新ソフトウエア・データや補足情報等をクライアントに定期的に送信する。より詳細に述べれば，この実施例は，定期的なハートビート・パルスの受信時にサーバが有している新規或いは更新された実行可能コードを，それを必要としているクライアントに伝達することを選択的に可能にするシステムである。
【０００９】
　
図１は本発明のデータ配信システム１００を示すブロック図である。データ配信システム１００では，サーバ１０２と，クライアントであるコンピュータからなる第１のワークステーション１０８と第２のワークステーション１１０を，分散処理環境を有するコンピュータ・ネットワーク１０４で接続している。サーバ１０２とコンピュータ・ネットワーク１０４は，通信リンク１０６を介して接続され，第1のワークステーション１０８とコンピュータ・ネットワーク１０４は，通信リンク１１２を介して接続され，第２のワークステーション１１０とコンピュータ・ネットワーク１０４は，通信リンク１１４を介して接続される。分散処理環境とは，コンピュータ・ネットワーク１０４を介して，２台以上の電子装置間でデータを交換することができる環境のことである。
　
Ｂ　「【００３４】
　次に図４及び図５のフローチャート４００及び５００を参照して，データ配信システム１００の作用を更に詳述する。図４は，サーバ１０２側の動作のフローチャートを示す。
スタート後，ステップ４０２で，サーバ１０２は，サーバ１０２が提供するサービスに関連した複数のワークステーション１０８，１１０のそれぞれからハートビート・データを受信する。
【００３５】
　
その後ステップ４０４において，サーバ１０２に関連付けされているすべてのワークステーション１０８，１１０からハートビート・データを受信しているか否かを判断する。
一方，ステップ４０４で，全てのワークステーションがハートビート・データを送信したと判断したら，ステップ４１０に進む。ステップ４１０では，受信したハートビート・データを基礎として，アクセスしたワークステーションを識別する。
【００３６】
　
次にステップ４１２で，新規の或は更新したソフトウエアがワークステーションで利用可能か否か判断する。新規の或いは更新したソフトウエア，または補足データが利用可能か否かの判断は，識別されたそれぞれのワークステーションについて行われる。
【００３７】
　
ステップ４１２で，識別された例えば第１のワークステーション１０８で，新しいソフトウエアが利用可能であると判断されると，ステップ４１４に進み，第１のワークステーション１０８のための次のハートビート・データを送信するまでの期間や，新規或いは更新されたソフトウエア，または実行可能コード等を有する応答データを生成する。この応答データは，その後ステップ４１６で，第１のワークステーション１０８に送信される。
　
Ｃ　「【００３９】
　次に図５のフローチャートを参照してデータ配信システム１００のワークステーション側の動作を詳述する。図５に示されているとおり，フローチャート５００は，ワークステーションによるハートビート・データの生成およびソフトウエアの更新，アップグレード，または補足データの受信の方法を例示している。図５に示されている方法は，サーバ１０２によって提供されるサービスに関連付けされた各ワークステーションに適用可能である。
スタート後，ステップ５０２で，ハートビート・データを生成してサーバ１０２に送信する。ハートビート・データは，各ワークステーション１０８，１１０の識別子を有し，ワークステーション１０８，１１０がサーバ１０２の提供するサービスにアクセスしていることを示す。
…（中略）…
【００４２】
　
この実施例によれば，ワークステーション１０８，１１０より，自身の識別データを有するハートビート・データを所定の期間でサーバ１０２に送信する。これに応答してサーバ１０２からワークステーション１０８，１１０に配信されるソフトウエアや補足データ等の応答データをインストールする。
　
　
イ　ここで，引用例１に記載されている事項を検討する。　
　
（ア）上記Ａの段落【０００９】の「図１は本発明のデータ配信システム１００を示すブロック図である。データ配信システム１００では，サーバ１０２と，クライアントであるコンピュータからなる第１のワークステーション１０８と第２のワークステーション１１０を，分散処理環境を有するコンピュータ・ネットワーク１０４で接続している。サーバ１０２とコンピュータ・ネットワーク１０４は，通信リンク１０６を介して接続され，第1のワークステーション１０８とコンピュータ・ネットワーク１０４は，通信リンク１１２を介して接続され，第２のワークステーション１１０とコンピュータ・ネットワーク１０４は，通信リンク１１４を介して接続される。分散処理環境とは，コンピュータ・ネットワーク１０４を介して，２台以上の電子装置間でデータを交換することができる環境のことである。」との記載からすると，「サーバ」は複数の「ワークステーション」とともに「データ配信システム」を構成することは明らかであり，「コンピュータ・ネットワーク」及び「通信リンク」を介して複数の「ワークステーション」と接続されていることが読み取れるから，引用例１には，
“データ配信システムにおいて，複数のワークステーションとコンピュータ・ネットワーク及び通信リンクを介して接続されたサーバ”
が記載されていると解される。
　
（イ）上記Ｂの段落【００３４】の「スタート後，ステップ４０２で，サーバ１０２は，サーバ１０２が提供するサービスに関連した複数のワークステーション１０８，１１０のそれぞれからハートビート・データを受信する。」との記載，上記Ｃの段落【００３９】の「スタート後，ステップ５０２で，ハートビート・データを生成してサーバ１０２に送信する。ハートビート・データは，各ワークステーション１０８，１１０の識別子を有し，ワークステーション１０８，１１０がサーバ１０２の提供するサービスにアクセスしていることを示す。」との記載からすると，「サーバ」は複数の「ワークステーション」からの識別子を有する「ハートビート・データ」を受信する手段を実質的に備えることが読み取れるから，引用例１には，
“複数のワークステーションからの識別子を有するハートビート・データを受信する受信手段”
が記載されていると解される。
　
（ウ）上記Ｂの段落【００３５】の「その後ステップ４０４において，サーバ１０２に関連付けされているすべてのワークステーション１０８，１１０からハートビート・データを受信しているか否かを判断する。」，「一方，ステップ４０４で，全てのワークステーションがハートビート・データを送信したと判断したら，ステップ４１０に進む。ステップ４１０では，受信したハートビート・データを基礎として，アクセスしたワークステーションを識別する。」との記載からすると，「サーバ」は受信した「ハートビート・データ」を基礎として，アクセスしたワークステーションを識別することが読み取れる。
　また，上記Ｂの段落【００３６】の「次にステップ４１２で，新規の或は更新したソフトウエアがワークステーションで利用可能か否か判断する。新規の或いは更新したソフトウエア，または補足データが利用可能か否かの判断は，識別されたそれぞれのワークステーションについて行われる。」，段落【００３７】の「ステップ４１２で，識別された例えば第１のワークステーション１０８で，新しいソフトウエアが利用可能であると判断されると，ステップ４１４に進み，第１のワークステーション１０８のための次のハートビート・データを送信するまでの期間や，新規或いは更新されたソフトウエア，または実行可能コード等を有する応答データを生成する。」との記載からすると，「サーバ」は，識別したそれぞれの「ワークステーション」について，新しいソフトウエアが利用可能であると判断されると，当該「ワークステーション」のための次のハートビート・データを送信するまでの期間や，新規或いは更新されたソフトウエア，または補足データ，実行可能コード等を有する応答データを生成する応答データ生成手段を実質的に備えることが読み取れるから，引用例１には，
“受信したハートビート・データを基礎として，アクセスしたワークステーションを識別し，新しいソフトウエアが利用可能であると判断されると，識別したワークステーションのための次のハートビート・データを送信するまでの期間や，新規或いは更新されたソフトウエア，または補足データ，実行可能コード等を有する応答データを生成する応答データ生成手段”
が記載されていると解される。
　
（エ）上記Ｂの段落【００３７】の「この応答データは，その後ステップ４１６で，第１のワークステーション１０８に送信される。」との記載，上記Ｃの段落【００４２】の「この実施例によれば，ワークステーション１０８，１１０より，自身の識別データを有するハートビート・データを所定の期間でサーバ１０２に送信する。これに応答してサーバ１０２からワークステーション１０８，１１０に配信されるソフトウエアや補足データ等の応答データをインストールする。」との記載からすると，「応答データ」は「ワークステーション」からの「ハートビート・データ」に対する応答であることは明らかであり，「サーバ」は「応答データ」を「ワークステーション」に送信する送信手段を実質的に備えることが読み取れるから，引用例１には，
“ハートビート・データに対する応答として，生成された応答データをワークステーションに送信する送信手段”
が記載されていると解される。
　
ウ　以上，（ア）乃至（エ）で示した事項から，引用例１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「データ配信システムにおいて，複数のワークステーションとコンピュータ・ネットワーク及び通信リンクを介して接続されたサーバであって，
　複数のワークステーションからの識別子を有するハートビート・データを受信する受信手段と，
　受信した前記ハートビート・データを基礎として，アクセスした前記ワークステーションを識別し，新しいソフトウエアが利用可能であると判断されると，識別した前記ワークステーションのための次のハートビート・データを送信するまでの期間や，新規或いは更新されたソフトウエア，または補足データ，実行可能コード等を有する応答データを生成する応答データ生成手段と，
　前記ハートビート・データに対する応答として，生成された応答データを前記ワークステーションに送信する送信手段と
　を有するサーバ。」
　
　
（２−２）引用例２に記載されている技術的事項
　
ア　本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である平成２７年１月２１日付けの拒絶理由通知において引用された，特開２００８−２４２９８３号公報（平成２０年１０月９日出願公開，以下，「引用例２」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｄ　「【００３１】
　
図９は，第２の実施の形態に係る分散処理管理装置８０の構成を示す。第２の実施の形態の分散処理管理装置８０は，図２に示した第１の実施の形態の分散処理管理装置８０の構成に比して，通信タスク生成部９４に代えてタスク情報通知部９７を備える。
【００３２】
　
タスク情報通知部９７は，タスクを分配した端末２０に，タスクが必要とするデータの入手先の装置に関する情報を通知する。これにより，端末２０は，入手先の装置からデータを入手するための送信タスクを自ら生成して入手先の装置に送信することができる。タスク情報通知部９７は，タスクが必要とするデータの内容に関する情報を更に通知してもよい。例えば，タスクの入力データのデータ型，データ長，入力タイミングに関する条件などを通知してもよい。
【００３３】
　
図１０は，第２の実施の形態に係る端末２０の構成を示す。第２の実施の形態の端末２０は，図６に示した第１の実施の形態の端末２０の構成に比して，タスク情報取得部５５及び通信タスク生成部５６を更に備える。
【００３４】
　
タスク情報取得部５５は，データを処理するタスクに関する情報を取得する。タスク情報取得部５５は，タスク取得部５１が取得するタスクが必要とするデータの入手先に関する情報を取得する。
　
イ　上記Ｄの記載からすると，引用例２には，次の技術が記載されている。
　
「分散処理管理装置から端末に送信するタスク情報として，タスクが必要とするデータの入手先やサイズ，入力タイミングを含むようにし，端末側では，受信した入力タイミングに基づきタスク実行に係るデータファイルを取得する技術。」
　
（２−３）引用例３に記載されている技術的事項
　
ア　本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の平成２７年３月３１日付けの拒絶査定において引用された，特開平８−２４９１６３号公報（平成８年９月２７日出願公開，以下，「引用例３」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｅ　「【００４８】さらに，バージョンアップの前処理に，バージョンアップ前の状態を保存等しておけば，バージョンアップされたソフトウェアにより別の障害が発生した場合にも，バージョンアップ前の状態に戻すことによりシステム全体の停止時間の短縮化を図ることができる。
＜第２の実施例＞
図２は，本発明の第２の実施例にかかるネットワークシステムのソフトウェアバージョン管理装置の構成を示す図である。
【００４９】
本実施例のネットワークシステムのソフトウェアバージョン管理装置は，ネットワーク上の１台のコンピュータをサーバとし，このサーバ上のソフトウェアをバージョンアップするとネットワーク１に組み込まれた他のコンピュータのソフトウェアもバージョンアップされるように構成されている。
【００５０】同図に示すように，サーバ側コンピュータ３２は，バージョン情報記憶機構４１，バージョンアップ機構４２，バージョン情報通知機構４３，ソフトウェア管理部４４，ソフトウェアアップロード機構４５を備えている。
【００５１】
バージョン情報記憶機構４１は，サーバ側コンピュータのソフトウェアのバージョン情報を格納するものである。このバージョン情報には，ソフトウェア名称，ソフトウェア属性（デバイスドライバ，システム用コンフィグレーションファイル，データファイル等），バージョン番号，自動バージョンアップ禁止・許可，バージョンアップ時の前処理，後処理等の操作に関する情報，バージョンアップのタイミング，バージョンアップ時にオペレータの判断が必要か等の情報を包含している。
【００５２】バージョンアップ機構４２は，外部からのバージョンアップ要求に基づいて，サーバ側のソフトウェア管理部４４に格納されたソフトウェアをバージョンアップされたソフトウェアにバージョンアップする。
【００５３】
バージョン情報通知機構４３は，クライアント側のバージョン情報受信機構と通信し，バージョンアップされたソフトウェアのバージョン情報をクライアント側に通知する。
【００５４】ソフトウェア管理部４４は，サーバ側の管理下にあり，ネットワーク３１に組み込まれているコンピュータ全てのソフトウェアの最新バージョンを格納している。
【００５５】ソフトウェアアップロード機構４５は，クライアント側のソフトウェアダウンロード機構５４と通信し，バージョンアップされたソフトウェアをクライアント側にアップロードする。
【００５６】次に，クライアント側コンピュータ３３の構成について説明する。ネットワーク３１に組み込まれている全てのクライアント側コンピュータの構成は，クライアント側コンピュータ３３と同様の構成である。
【００５７】同図に示すように，クライアント側コンピュータ３３は，バージョン情報受信機構５１，バージョン情報比較機構５２，バージョン情報記憶機構５３，ソフトウェアダウンロード機構５４，バージョンアップ機構５５，アクセス制御機構５６，自己のソフトウェア管理部５７とで構成されている。
【００５８】
バージョン情報受信機構５１は，サーバ側のコンピュータ３２のバージョン情報通知機構４３から送信されたバージョンアップされたソフトウェアのバージョン情報を受信する。
【００５９】
バージョン情報比較機構５２は，バージョン情報記憶機構５３に記憶されているクライアント側コンピュータ３３のソフトウェアのバージョン情報と，バージョン情報受信機構５１により受信したバージョンアップされたソフトウェアのバージョン情報とを比較し，バージョンアップが必要かつ許可されていればバージョンアップ機構５５にバージョン情報を含むバージョンアップ要求を出力する。
【００６０】ソ
フトウェアダウンロード機構５４は，バージョン情報比較機構５２からバージョンアップ要求が出力されるとサーバのアップロード機構４５からアップロードされたバージョンアップされたソフトウェアをダウンロードする。
【００６１】バージョンアップ機構５５は，自己のソフトウェア管理部５７に格納されているソフトウェアをソフトウェアダウンロード機構５４からダウンロードされたバージョンアップされたソフトウェアにバージョンアップする。」
　
イ　上記Ｅの記載からすると，引用例３には，次の技術が記載されている。
　
「クライアント側でソフトウェアのバージョンアップを行う時に，サーバがバージョンアップを行うタスクに関連するバージョン情報をクライアントに送信すると，クライアント側では，前処理として，当該バージョン情報に基づいてバージョンアップを行うタスクを実行するか否かを判断し，バージョンアップが必要と判断した場合にサーバから当該バージョンアップされたソフトウェアをダウンロードする技術。」
　
　
（３）対比
　
ア　本件補正発明と引用発明とを対比する。
　
（ア）引用発明の「サーバ」は「複数のワークステーションとコンピュータ・ネットワーク及び通信リンクを介して接続され」，「複数のワークステーションからの識別子を有するハートビート・データを受信する」ことから，引用発明の「サーバ」，「ワークステーション」は本件補正発明の「情報処理装置」，「クライアント端末」に相当すると言える。
　
（イ）引用発明では，「サーバ」は「複数のワークステーションからの識別子を有するハートビート・データを受信」し，「前記ハートビート・データに対する応答として，生成された応答データを前記ワークステーションに送信する送信手段」を備えるところ，「ハートビート・データ」は「ワークステーション」から「サーバ」に通知されると言えるから，引用発明の「ハートビート・データ」は本件補正発明の「通知データ」に相当すると言える。
　また，引用発明の「応答データ」は，「ワークステーション」からの「ハートビート・データ」に対して「サーバ」から返信される情報とみることができるから，引用発明の「応答データ」は情報内容が相違するものの，本件補正発明の「返信情報」に対応すると言える。
　そうすると，引用発明の「前記ハートビート・データに対する応答として，生成された応答データを前記ワークステーションに送信する送信手段」は本件補正発明の「クライアント端末からの通知データに対して，返信情報を返信する返信手段」に相当すると言える。
　
（ウ）引用発明では，「応答データ生成手段」が「受信した前記ハートビート・データを基礎として，アクセスした前記ワークステーションを識別し，」「応答データを生成する」ところ，「応答データ」は「識別した前記ワークステーションのための次のハートビート・データを送信するまでの期間や，新規或いは更新されたソフトウエア，または補足データ，実行可能コード等」を有し，その中で「新規或いは更新されたソフトウエア」は「ワークステーション」で実行されるのタスク実行に要するデータファイルであることは明らかであるから，「新規或いは更新されたソフトウエア，または補足データ，実行可能コード等」は，タスク実行に要するデータファイルに係る情報を含むタスク関連情報とみることができる。
　一方，本件補正発明の「情報挿入手段」が「返信情報」に挿入する「タスク情報」は，「クライアント端末がタスク実行の要否を判断するための情報，および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からな」り，「クライアント端末がタスク実行に要するデータファイル」に係る情報を含むとみることができる。
　そうすると，引用発明の「応答データ」が有する「識別した前記ワークステーションのための次のハートビート・データを送信するまでの期間や，新規或いは更新されたソフトウエア，または補足データ，実行可能コード等」と，本件補正発明の「クライアント端末がタスク実行の要否を判断するための情報，および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなるタスク情報」とは，“クライアント端末がタスク実行に要するデータファイルに係る情報を含むタスク関連情報”である点で一致すると言える。
　
（エ）引用発明の「応答データ生成手段」は「応答データ」を生成するところ，上記（ウ）の検討より，本件補正発明においては，「返信情報」に「クライアント端末がタスク実行に要するデータファイル」に係る情報を含む「タスク関連情報」を挿入するとみることができるから，引用発明の「応答データ生成手段」と本件補正発明の「情報挿入手段」とは，“返信情報に，”“タスク関連情報を挿入する情報挿入手段”である点で一致していると言える。
　そうすると，引用発明の「受信した前記ハートビート・データを基礎として，アクセスした前記ワークステーションを識別し，新しいソフトウエアが利用可能であると判断されると，識別した前記ワークステーションのための次のハートビート・データを送信するまでの期間や，新規或いは更新されたソフトウエア，または補足データ，実行可能コード等を有する応答データを生成する応答データ生成手段」と，
　本件補正発明の「前記返信情報に，前記クライアント端末がタスク実行の要否を判断するための情報，および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなるタスク情報を挿入する情報挿入手段」とは，後記する点で相違するものの，
　“返信情報に，前記クライアント端末がタスク実行に要するデータファイルに係る情報を含むタスク関連情報を挿入する情報挿入手段”である点で共通していると言える。
　
イ　以上から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
＜一致点＞ 
　
「　クライアント端末からの通知データに対して，返信情報を返信する返信手段と，
　前記返信情報に，前記クライアント端末がタスク実行に要するデータファイルに係る情報を含むタスク関連情報を挿入する情報挿入手段と
　を有する情報処理装置。」
　
＜相違点＞
　
　返信情報に挿入するタスク関連情報に関し，本件補正発明では，「クライアント端末がタスク実行の要否を判断し，前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」であるのに対して，引用発明では，「新規或いは更新されたソフトウエア，または補足データ，実行可能コード等」を含む情報である点。
　
　
（４）当審の判断
　
　　上記相違点について検討する。
　
　引用発明では，「サーバ」は，「新規或いは更新されたソフトウエア，または補足データ，実行可能コード等」を含む情報を，「ワークステーション」で実行するタスクに関連する情報として「応答データ」に挿入するところ，クライアント側でソフトウェアのバージョンアップを行う時に，サーバがバージョンアップを行うタスクに関連するバージョン情報をクライアントに送信すると，クライアント側では，前処理として，当該バージョン情報に基づいてバージョンアップを行うタスクを実行するか否かを判断し，バージョンアップが必要と判断した場合にサーバから当該バージョンアップされたソフトウェアをダウンロードすることは，例えば引用例３（上記Ｅを参照）に記載されるように，本願出願前には当該技術分野において普通に用いられていた周知技術であった。
　また，サーバから端末に送信するタスク関連情報として，タスクが必要とするデータの入力タイミングを含むようにし，端末側では，受信した入力タイミングに基づきタスク実行に係るデータファイルを取得することも，例えば引用例２（上記Ｄを参照）に記載されるように，本願出願前には周知技術であった。
　そして，クライアント端末におけるタスク実行に係るタスク関連情報として，サーバからタスク実行の要否を判断するための情報，あるいは，タスク実行に係るデータファイルの入力タイミングの情報を送信するかどうかは，必要に応じて適宜選択し得た設計的事項である。
　そうすると，引用発明において，上記周知技術を適用し，適宜，ワークステーションからのハートビート・データに対する応答データに，ワークステーションが前処理としてタスク実行の要否を判断するための情報，および，タスク実行に係るデータファイルを入力するタイミングを決定するための情報を，タスク情報として挿入して送信すること，すなわち，上記相違点に係る構成とすることは，当業者が容易に想到し得たことである。
　
　上記で検討したごとく，相違点に係る構成は当業者が容易に想到し得たものであり，そして，本件補正発明の奏する作用効果は，上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本件補正発明は，上記引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。
　
　
４−３　独立特許要件のむすび
　
　上記４−１のとおり，補正後の発明の詳細な説明及び特許請求の範囲の記載は，特許法第３６条第４項第１号，同条第６項第１号および第２号に規定する要件を満たしておらず，補正後の請求項２に係る発明は，この理由によって特許出願の際独立して特許を受けることができないものである。
　
　また，上記４−２のとおり，本件補正発明は，その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
　したがって，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反する。
　
　
５　補正却下の決定のむすび
　
　上記「２　新規事項追加禁止要件」で指摘したとおり，本件補正は，特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　また，上記「３　目的要件」で指摘したとおり，本件補正は，特許法第１７条の２第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　加えて，仮に本件補正が，当初明細書等の記載の範囲内でなされたものであるとし，特許請求の範囲の減縮（限定的減縮）を目的とする場合でも，「４　独立特許要件」で指摘したとおり，補正後の請求項２に記載された発明（本件補正発明）は，特許出願の際独立して特許を受けることができるものではないから，本件補正は特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　よって，上記補正却下の決定の結論のとおり決定する。
　
　
第３　本願発明について
　
１　本願発明 
  
　平成２７年７月６日付けの手続補正は上記のとおり却下されたので，補正後の請求項２に対応する補正前の請求項２に係る発明（以下，「本願発明」という。）は，平成２７年３月２３日付けの手続補正により補正された特許請求の範囲の請求項２に記載された事項により特定される，以下のとおりのものである。
　
「　クライアント端末からの通知データに対して，返信情報を返信する返信手段と，
　前記返信情報に，前記クライアント端末による，タスク実行の要否の判断に必要であるタスク情報を挿入する情報挿入手段と
　を有する情報処理装置。」
　
２　引用例に記載されている技術的事項及び引用発明 
　
　原査定の拒絶の理由に引用された，引用発明は，前記「第２　平成２７年７月６日付けの手続補正についての補正却下の決定」の「４　独立特許要件」「４−２　特許法第２９条第２項（進歩性）について」の「（２）引用例」に記載したとおりである。
　
３　対比・判断  
　
　本願発明は，前記「第２　平成２７年７月６日付けの手続補正についての補正却下の決定」の「４　独立特許要件」「４−２　特許法第２９条第２項（進歩性）について」で検討した本件補正発明の発明特定事項である「前記クライアント端末がタスク実行の要否を判断するための情報，および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなるタスク情報」から，「および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなる」との事項を削除したものである。
　
　そうすると，本願発明の発明特定事項を全て含む本件補正発明が，前記「第２　平成２７年７月６日付けの手続補正についての補正却下の決定」の「４　独立特許要件」「４−２　特許法第２９条第２項（進歩性）について」の「（２）引用例」乃至「（４）当審の判断」に記載したとおり，引用発明及び当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから，上記特定の限定を省いた本願発明も同様の理由により，引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものである。 
　
　
第４　むすび 
　
　以上のとおり，本願の請求項２に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　
　よって，結論のとおり審決する。