• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 G06F
管理番号 1318846
審判番号 不服2015-12871  
総通号数 202 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-10-28 
種別 拒絶査定不服の審決 
審判請求日 2015-07-06 
確定日 2016-08-29 
事件の表示 特願2011-239295「情報処理システム、情報処理装置、クライアント端末、情報処理方法、及びプログラム」拒絶査定不服審判事件〔平成25年 5月20日出願公開、特開2013- 97548〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由
第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,平成23年10月31日の出願であって,その手続の経緯は以下のとおりである。

平成26年 7月 1日 :出願審査請求書の提出
平成27年 1月21日付け :拒絶理由の通知
平成27年 3月23日 :意見書,手続補正書の提出
平成27年 3月31日付け :拒絶査定
平成27年 7月 6日 :審判請求書,手続補正書の提出
平成27年10月29日 :前置報告


第2 平成27年7月6日付けの手続補正についての補正却下の決定

[補正却下の決定の結論]

平成27年7月6日付けの手続補正を却下する。

[理由]

1 補正の内容

(1)平成27年7月6日付けの手続補正(以下,「本件補正」という。)の内容は,平成27年3月23日付けの手続補正により補正された特許請求の範囲の請求項1乃至19の記載

「 【請求項1】
クライアント端末と,
このクライアント端末を管理する管理サーバと
を含み,
前記クライアント端末は,
少なくとも自機の稼働状態を示す情報が含まれた通知データを,前記管理サーバに送信する送信手段と,
前記送信手段により送信された通知データの返信情報に応じて,タスクの実行に必要な前処理を行う前処理手段と,
前記前処理手段により前処理が行われた後に,タスクを実行する実行手段と
を有し,
前記管理サーバは,
前記クライアント端末からの通知データに対して,返信情報を返信する返信手段と,
前記返信情報に,前記クライアント端末のタスクに関するタスク情報を挿入する情報挿入手段と
を有する情報処理システム。
【請求項2】
クライアント端末からの通知データに対して,返信情報を返信する返信手段と,
前記返信情報に,前記クライアント端末による,タスク実行の要否の判断に必要であるタスク情報を挿入する情報挿入手段と
を有する情報処理装置。
【請求項3】
前記情報挿入手段は,前記タスク情報として,タスク種別,タスクの実行に要する時間を示す情報,タスクの優先順位,関連する他のタスクを示す情報,配信ファイルの有無,配信ファイルのデータサイズ,及び,タスクに要するデータファイルの版数,の少なくとも一つを挿入する
請求項2に記載の情報処理装置。
【請求項4】
前記情報挿入手段は,前記タスク情報として,タスクの実行に必要なデータファイルを要求すべきタイミングを示す情報を挿入する
請求項2に記載の情報処理装置。
【請求項5】
クライアント端末が通知データを送信すべき間隔を示すデータ通知間隔を設定する間隔設定手段
をさらに有し,
前記情報挿入手段は,前記返信情報に,前記間隔設定手段により変更されたデータ通知間隔を挿入する
請求項2に記載の情報処理装置。
【請求項6】
タスクの優先順位とデータ通知間隔とに関連付けられて,タスク情報を格納するタスク情報格納手段
をさらに有し,
前記情報挿入手段は,前記タスク情報格納手段に格納されている前記タスク情報の中から,前記優先順位に応じた順序で,タスク情報と,そのタスクに関連付けられたデータ通知間隔とを挿入する
請求項5に記載の情報処理装置。
【請求項7】
前記タスク情報格納手段は,直列的な順序で実行すべき複数のタスクを,関連タスクとして互いに関連付けて格納し,
前記情報挿入手段は,前記タスク情報格納手段に関連タスクとして格納された複数のタスクのタスク情報を,連続する複数の通知データに対する返信情報に,順に挿入する
請求項6に記載の情報処理装置。
【請求項8】
少なくとも自機の稼働状態を示す情報が含まれた通知データを,外部装置に送信する送信手段と,
前記送信手段により送信された通知データの返信情報に応じて,タスクの実行に必要な前処理を行う前処理手段と,
前記前処理手段により前処理が行われた後に,タスクを実行する実行手段とを有するクライアント端末。
【請求項9】
前記返信情報には,タスクの種別を示すタスク種別が含まれており,
前記前処理手段は,前記タスク種別に基づいて,タスク実行の要否を判断し,
前記実行手段は,前記前処理手段によりタスクの実行が必要であると判断された場合に,このタスクを実行する
請求項8に記載のクライアント端末。
【請求項10】
前記返信情報には,データファイルを要求するタイミングを指定する情報が含まれており,
前記前処理手段は,前記返信情報により指定されたタイミングで,データファイルを取得し,
前記実行手段は,前記前処理手段により取得されたデータファイルを用いて,タスクを実行する
請求項9に記載のクライアント端末。
【請求項11】
前記返信情報には,次に実行すべきタスクの存在を示す関連タスク情報が含まれており,
前記前処理手段は,前記返信情報に含まれる関連タスク情報に応じて,タスクの実行完了を,次に実行すべきタスクの要求情報として外部装置に通知する
請求項8に記載のクライアント端末。
【請求項12】
前記送信手段は,送信した通知データに対応する返信情報が既定の期間に受信できなかった場合,通知データの送信間隔を自機のデフォルト値に戻す
請求項8に記載のクライアント端末。
【請求項13】
前記返信情報には,タスクの優先順位を示す情報が含まれており,
前記前処理手段は,前記実行手段により実行されているタスクの優先順位と,前記返信情報により通知されたタスクの優先順位とを比較し,通知されたタスクの優先順位が実行中のタスクよりも高い場合に,実行中のタスクをキャンセルし,
前記前処理手段によりタスクがキャンセルされた旨を,前記外部装置に通知するタスク制御手段
をさらに有する請求項8に記載のクライアント端末。
【請求項14】
前記タスク制御手段は,互いに関連付けられた複数のタスクのいずれかが失敗した場合に,実行済みの他の関連付けられたタスクを,実行前の状態に戻し,関連タスクをキャンセルした旨を外部装置に通知する
請求項13に記載のクライアント端末。
【請求項15】
前記タスク制御手段は,互いに関連付けられた複数のタスクよりも優先順位の高いタスクが前記返信情報により通知された場合に,実行済みの関連付けられたタスクを,実行前の状態に戻し,関連タスクをキャンセルした旨を外部装置に通知する
請求項13に記載のクライアント端末。
【請求項16】
前記送信手段は,タスクの実行中に,通知データを送信するタイミングが到来した場合,タスクの進捗情報を外部装置に通知する
請求項8に記載のクライアント端末。
【請求項17】
クライアント端末が,少なくとも自機の稼働状態を示す情報が含まれた通知データを,
管理サーバに送信するステップと,
前記管理サーバが,前記クライアント端末から受信した通知データに対する返信情報に,タスクに関するタスク情報を挿入するステップと,
前記管理サーバが,前記タスク情報が挿入された返信情報を,前記クライアント端末に返信するステップと,
前記クライアント端末が,前記返信情報に挿入されたタスク情報に応じて,タスクの前処理を行うステップと
を有する情報処理方法。
【請求項18】
クライアント端末からのデータ通知に対して返信情報を返信するステップと,
前記返信情報に,前記クライアント端末による,タスク実行の要否の判断に必要であるタスク情報を挿入するステップと
をコンピュータに実行させるプログラム。
【請求項19】
少なくとも自機の稼働状態を示す情報が含まれた通知データを,送信するステップと,
送信された前記通知データの返信情報に応じて,タスクの実行に必要な前処理を行うステップと,
前処理後に,タスクを実行する実行ステップと
をコンピュータに実行させるプログラム。」(以下,この特許請求の範囲に記載された請求項を「補正前の請求項」という。)

を,

「 【請求項1】
クライアント端末と,
このクライアント端末を管理する管理サーバと
を含み,
前記クライアント端末は,
少なくとも自機の稼働状態を示す情報が含まれた通知データを,前記管理サーバに送信する送信手段と,
前記送信手段により送信された通知データの返信情報に応じて,タスクの実行に必要な前処理を行う前処理手段と,
前記前処理手段により前処理が行われた後に,タスクを実行する実行手段と
を有し,
前記前処理手段は,前記返信情報に基づいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し,
前記実行手段は,前記前処理手段により決定されたタイミングに基づいて,タスクを実行し,
前記管理サーバは,
前記クライアント端末からの通知データに対して,返信情報を返信する返信手段と,
前記返信情報に,前記クライアント端末のタスクに関するタスク情報を挿入する情報挿入手段と
を有する情報処理システム。
【請求項2】
クライアント端末からの通知データに対して,返信情報を返信する返信手段と,
前記返信情報に,前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段と
を有する情報処理装置。
【請求項3】
前記情報挿入手段は,前記タスク情報として,タスク種別,タスクの実行に要する時間を示す情報,タスクの優先順位,関連する他のタスクを示す情報,配信ファイルの有無,配信ファイルのデータサイズ,及び,タスクに要するデータファイルの版数,の少なくとも一つを挿入する
請求項2に記載の情報処理装置。
【請求項4】
前記情報挿入手段は,前記タスク情報として,タスクの実行に必要なデータファイルを要求すべきタイミングを示す情報を挿入する
請求項2に記載の情報処理装置。
【請求項5】
クライアント端末が通知データを送信すべき間隔を示すデータ通知間隔を設定する間隔設定手段
をさらに有し,
前記情報挿入手段は,前記返信情報に,前記間隔設定手段により変更されたデータ通知間隔を挿入する
請求項2に記載の情報処理装置。
【請求項6】
タスクの優先順位とデータ通知間隔とに関連付けられて,タスク情報を格納するタスク情報格納手段
をさらに有し,
前記情報挿入手段は,前記タスク情報格納手段に格納されている前記タスク情報の中から,前記優先順位に応じた順序で,タスク情報と,そのタスクに関連付けられたデータ通知間隔とを挿入する
請求項5に記載の情報処理装置。
【請求項7】
前記タスク情報格納手段は,直列的な順序で実行すべき複数のタスクを,関連タスクとして互いに関連付けて格納し,
前記情報挿入手段は,前記タスク情報格納手段に関連タスクとして格納された複数のタスクのタスク情報を,連続する複数の通知データに対する返信情報に,順に挿入する
請求項6に記載の情報処理装置。
【請求項8】
少なくとも自機の稼働状態を示す情報が含まれた通知データを,外部装置に送信する送信手段と,
前記送信手段により送信された通知データの返信情報に応じて,タスクの実行に必要な前処理を行う前処理手段と,
前記前処理手段により前処理が行われた後に,タスクを実行する実行手段と
を有し,
前記前処理手段は,前記返信情報に基づいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し,
前記実行手段は,前記前処理手段により決定されたタイミングに基づいて,タスクを実行する
クライアント端末。
【請求項9】
前記返信情報には,タスクの種別を示すタスク種別が含まれており,
前記前処理手段は,前記タスク種別に基づいて,タスク実行の要否を判断し,
前記実行手段は,前記前処理手段によりタスクの実行が必要であると判断された場合に,このタスクを実行する
請求項8に記載のクライアント端末。
【請求項10】
前記返信情報には,データファイルを要求するタイミングを指定する情報が含まれており,
前記前処理手段は,前記返信情報により指定されたタイミングで,データファイルを取得し,
前記実行手段は,前記前処理手段により取得されたデータファイルを用いて,タスクを実行する
請求項9に記載のクライアント端末。
【請求項11】
前記返信情報には,次に実行すべきタスクの存在を示す関連タスク情報が含まれており,
前記前処理手段は,前記返信情報に含まれる関連タスク情報に応じて,タスクの実行完了を,次に実行すべきタスクの要求情報として外部装置に通知する
請求項8に記載のクライアント端末。
【請求項12】
前記送信手段は,送信した通知データに対応する返信情報が既定の期間に受信できなかった場合,通知データの送信間隔を自機のデフォルト値に戻す
請求項8に記載のクライアント端末。
【請求項13】
前記返信情報には,タスクの優先順位を示す情報が含まれており,
前記前処理手段は,前記実行手段により実行されているタスクの優先順位と,前記返信情報により通知されたタスクの優先順位とを比較し,通知されたタスクの優先順位が実行中のタスクよりも高い場合に,実行中のタスクをキャンセルし,
前記前処理手段によりタスクがキャンセルされた旨を,前記外部装置に通知するタスク制御手段
をさらに有する請求項8に記載のクライアント端末。
【請求項14】
前記タスク制御手段は,互いに関連付けられた複数のタスクのいずれかが失敗した場合に,実行済みの他の関連付けられたタスクを,実行前の状態に戻し,関連タスクをキャンセルした旨を外部装置に通知する
請求項13に記載のクライアント端末。
【請求項15】
前記タスク制御手段は,互いに関連付けられた複数のタスクよりも優先順位の高いタスクが前記返信情報により通知された場合に,実行済みの関連付けられたタスクを,実行前の状態に戻し,関連タスクをキャンセルした旨を外部装置に通知する
請求項13に記載のクライアント端末。
【請求項16】
前記送信手段は,タスクの実行中に,通知データを送信するタイミングが到来した場合,タスクの進捗情報を外部装置に通知する
請求項8に記載のクライアント端末。
【請求項17】
クライアント端末が,少なくとも自機の稼働状態を示す情報が含まれた通知データを,
管理サーバに送信するステップと,
前記管理サーバが,前記クライアント端末から受信した通知データに対する返信情報に,タスクに関するタスク情報を挿入するステップと,
前記管理サーバが,前記タスク情報が挿入された返信情報を,前記クライアント端末に返信するステップと,
前記クライアント端末が,前記返信情報に挿入されたタスク情報に応じて,タスクの前処理を行うステップと
を有し,
前記タスクの前処理を行うステップにおいて,前記返信情報に基づいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定する
情報処理方法。
【請求項18】
クライアント端末からのデータ通知に対して返信情報を返信するステップと,
前記返信情報に,前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入するステップと
をコンピュータに実行させるプログラム。
【請求項19】
少なくとも自機の稼働状態を示す情報が含まれた通知データを,送信するステップと,
送信された前記通知データの返信情報に応じて,タスクの実行に必要な前処理を行うステップと,
前処理後に,タスクを実行する実行ステップと
をコンピュータに実行させ,
前記タスクの前処理を行うステップにおいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し,
前記タスクを実行するステップにおいて,前記タスクの前処理を行うステップにおいて決定されたタイミングに基づいて,タスクを実行させる
プログラム。」(当審注:下線は,請求人が付与したものである。以下,この特許請求の範囲に記載された請求項を「補正後の請求項」という。)

に補正するものである。

(2)補正前の請求項と,補正後の請求項とを比較すると,補正後の請求項1乃至19はそれぞれ,補正前の請求項1乃至19に対応することは明らかである。

(3)本件補正は,下記の補正事項1乃至7よりなるものである。

<補正事項1>
補正前の請求項1,8の
「前記送信手段により送信された通知データの返信情報に応じて,タスクの実行に必要な前処理を行う前処理手段と,…(中略)…を有し,」との記載を,
補正後の請求項1,8の
「前記送信手段により送信された通知データの返信情報に応じて,タスクの実行に必要な前処理を行う前処理手段と,…(中略)…を有し,
前記前処理手段は,前記返信情報に基づいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し,」との記載に変更する補正。

<補正事項2>
補正前の請求項1,8の
「前記前処理手段により前処理が行われた後に,タスクを実行する実行手段と…(中略)…を有し,」との記載を,
補正後の請求項1,8の
「前記前処理手段により前処理が行われた後に,タスクを実行する実行手段と…(中略)…を有し,
前記実行手段は,前記前処理手段により決定されたタイミングに基づいて,タスクを実行し,」との記載に変更する補正。

<補正事項3>
補正前の請求項2の
「前記返信情報に,前記クライアント端末による,タスク実行の要否の判断に必要であるタスク情報を挿入する情報挿入手段」との記載を,
補正後の請求項2の
「前記返信情報に,前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段」との記載に変更する補正。

<補正事項4>
補正前の請求項17の
「前記クライアント端末が,前記返信情報に挿入されたタスク情報に応じて,タスクの前処理を行うステップと
を有する」との記載を,
補正後の請求項17の
「前記クライアント端末が,前記返信情報に挿入されたタスク情報に応じて,タスクの前処理を行うステップと
を有し,
前記タスクの前処理を行うステップにおいて,前記返信情報に基づいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定する」との記載に変更する補正。

<補正事項5>
補正前の請求項18の
「前記返信情報に,前記クライアント端末による,タスク実行の要否の判断に必要であるタスク情報を挿入するステップ」との記載を,
補正後の請求項18の
「前記返信情報に,前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入するステップ」との記載に変更する補正。

<補正事項6>
補正前の請求項19の
「送信された前記通知データの返信情報に応じて,タスクの実行に必要な前処理を行うステップと,」との記載を,
補正後の請求項19の
「送信された前記通知データの返信情報に応じて,タスクの実行に必要な前処理を行うステップと,
…(中略)…
前記タスクの前処理を行うステップにおいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し,」との記載に変更する補正。

<補正事項7>
補正前の請求項19の
「前処理後に,タスクを実行する実行ステップと」との記載を,
補正後の請求項19の
「前処理後に,タスクを実行する実行ステップと
…(中略)…
前記タスクを実行するステップにおいて,前記タスクの前処理を行うステップにおいて決定されたタイミングに基づいて,タスクを実行させる」との記載に変更する補正。


2 新規事項追加禁止要件

本件補正が,特許法第17条の2第3項の規定を満たすものであるか否か,即ち,本件補正が願書に最初に添付された明細書,特許請求の範囲又は図面(以下,これを「当初明細書等」という。)の範囲内でなされたものであるかについて,以下に検討する。

(1)上記「1 補正の内容 (3)」において指摘した具体的補正事項1乃至7のうち,補正事項3において指摘した,補正後の請求項2及び請求項18の「前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」という記載は,当初明細書等には記載されていない表現である。
そこで,上記指摘の記載が,当初明細書等に記載された内容から読み取れるかについて以下に検討する。
当初明細書等の特許請求の範囲には,「タスク情報」について,上記指摘の補正後の請求項2及び請求項18に記載された表現と同一のものは存在しない。また,当初明細書等の特許請求の範囲には,その請求項2に「前記クライアント端末が実行すべきタスクに関するタスク情報」,その請求項3に「前記タスク情報として,タスク種別,タスクの実行に要する時間を示す情報,タスクの優先順位,関連する他のタスクを示す情報,配信ファイルの有無,配信ファイルのデータサイズ,及び,タスクに要するデータファイルの版数,の少なくとも一つ」,その請求項4に「前記タスク情報として,タスクの実行に必要なデータファイルを要求すべきタイミングを示す情報」,その請求項11に「次に実行すべきタスクの存在を示す関連タスク情報」,その請求項18に「前記クライアント端末のタスクに関するタスク情報」との記載があるものの,補正後の請求項2及び請求項18のような,「クライアント端末がタスク実行の要否を判断」することと,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とする「タスク情報」の具体的な態様については記載されていない。

次に当初明細書等の発明の詳細な説明について検討すると,「タスク情報」に関して,段落【0031】に(当審注:下線は,参考のために当審で付与したものである。),
「【0031】
図3は,タスク管理部540をより詳細に説明する図である。
…(中略)…
タスク管理部540は,タスク情報の取得や更新をタスク情報DB620に対して行う。ここで,タスク情報とは,タスクに関する情報であり,例えば,タスクの属性情報などである。情報の取得及び更新対象は,タスク情報DB620が保持する,タスク情報管理テーブルである。
図4は,タスク情報管理テーブルを例示する図である。
図4に例示するように,タスク情報管理テーブルは,タスク情報ID,タスク種別,タスクの優先順位,関連タスクID,配信ファイルの有無,データサイズ,版数,適用所要時間を保持する。配信ファイルの有無は,タスクの実行に必要なデータファイルをクライアント端末9に送信する必要があるかどうかを示す。本例のタスク情報には,さらに,タスクに必要なデータファイルを要求すべきタイミングと,タスクに紐づくデータ通知間隔とが含まれる。タスク種別は,タスクの種別を示す。タスクの優先順位とは,タスクの実行の優先順位を示す。関連タスクIDとは,互いに関連付けられた他のタスクを識別するための情報であり,例えば,次に実行すべきタスクのIDである。データサイズとは,配信ファイル(すなわち,タスクの実行に要するデータファイル)のデータサイズである。版数とは,配信ファイルの版数である。適用所要時間とは,タスクの実行に要する目安時間である。」
と記載され,「タスク情報」の具体的態様として,「タスク情報ID」,「タスク種別」,「タスクの優先順位」,「関連タスクID」,「配信ファイルの有無」,「データサイズ」,「版数」,「適用所要時間」,「タスクに必要なデータファイルを要求すべきタイミング」,「タスクに紐づくデータ通知間隔」が読み取れる。
そして,上記の「タスク情報」の具体的態様のうち,「タスク種別」,「タスクの優先順位」は,段落【0038】に,
「【0038】
タスク制御部720は,タスクの実行に必要な前処理を行い,タスクを実行する。タスク制御部720は,図6に例示するように,タスク判断部722と,タスク取得通知部724と,タスク適用部726とを有する。
タスク判断部722は,管理サーバ5より通知された返信情報に含まれるタスク種別に基づいて,タスク実行の要否を判断する。例えば,タスク判断部722は,タスク種別に基づいて,タスクが自身に対して適用可能なタスクかどうかを判断する。さらに,タスク判断部722は,自身の現在の処理状態を取得し,タスク適用が可能な状態かどうかを判断する。現在処理中のタスクが存在した場合は,タスク判断部722は,現在処理中のタスクの優先順位と,管理サーバ5より通知されたタスクの優先順位とを比較し,優先順位によって現在のタスクについて,「続行」又は「キャンセル」をタスク適用部726に指示する。」
と記載され,同じく,段落【0044】に,
「【0044】
図9は,クライアント端末9の優先順位に基づいたタスクの適用処理(S80)である。
図9に例示するように,ステップ800(S800)において,ハートビート送信部700は,管理サーバ5からハートビート通知の応答としてタスク情報を受信する。
ステップ805(S805)において,タスク判断部722は,適用中のタスクが存在するか確認する。存在した場合は,優先順位に基づいたタスクの適用処理(S80)は,S810へ移行し,存在しない場合は,優先順位に基づいたタスクの適用処理(S80)は,S830へ移行する。
ステップ810(S810)において,タスク判断部722は,通知されたタスクと適用中のタスクの優先順位を比較する。通知タスクの優先順位が高ければ,優先順位に基づいたタスクの適用処理(S80)は,S815へ移行する。通知タスクの優先順位が低ければ,優先順位に基づいたタスクの適用処理(S80)は,S825へ移行する。
ステップ815(S815)において,タスク判断部722は,現在実行中のタスクのキャンセルをタスク適用部726に通知し,タスク適用部726は,適用中のタスクをキャンセルする。
…(中略)…
ステップ835(S835)において,タスク適用部726は,タスクを適用し,適用結果をハートビート送信部700へ通知する。ハートビート送信部700は,管理サーバ5にタスク適用結果を通知する。」
と記載されるように,「クライアント端末がタスク実行の要否を判断する」ための「タスク情報」であると解されるものの,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」であることを読み取ることができない。
一方,上記の「タスク情報」の具体的態様のうち,「タスクに必要なデータファイルを要求すべきタイミング」,「タスクに紐づくデータ通知間隔」は,段落【0048】に,
「 【0048】
以上説明したように,本実施形態のデータ通信システム1において,クライアント端末9は,ハートビートを用いて,自機の稼働状況を管理サーバ5へ定期的に通知し,管理サーバ5は,ハートビートの返信情報に,タスクに要するデータファイルのデータサイズなどのタスク情報を挿入してクライアント端末9へ通知する。 …(中略)… さらに,クライアント端末9は,タスク情報として,タスクの種別を取得するため,タスク実行の要否を独自に判断できる。また,クライアント端末9は,タスク情報として,タスクに要する推定処理時間や,タスクに要するデータファイルの配信期間などを取得するため,自機の都合に合わせて,データファイルの取得タイミングや,タスクの実行タイミングなどを決定できる。これらはまた,クライアント端末9と管理サーバ5との間の不要なデータ通信を省き,ネットワーク負荷の軽減に資する。さらに,クライアント端末9は,自機の処理状況に応じてタスクの取得・実行するため,自機によるサービスレベルの向上が期待できる。」
と記載されるように,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」であると解されるものの,「クライアント端末がタスク実行の要否を判断する」ための「タスク情報」であることを読み取ることができない。
すなわち,当初明細書等の発明の詳細な説明には,「クライアント端末がタスク実行の要否を判断」するための「タスク情報」と,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」を異なる態様として例示されているものの,補正後の請求項2及び請求項18のような,「クライアント端末がタスク実行の要否を判断」することと,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とする「タスク情報」の具体的な態様については記載されていない。
また,当初明細書等のその他の箇所を参酌しても,「前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」を直接的にも間接的にも示唆する記載は見あたらない。
そうすると,補正前の請求項2及び請求項18の「前記クライアント端末による,タスク実行の要否の判断に必要であるタスク情報」との記載を,補正後の請求項2及び請求項18の「前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」との記載に変更する上記補正事項3は,当初明細書等の記載の範囲内でなされたものではない。

よって,上記補正事項3を含む本件補正は,当初明細書等の記載の範囲内でなされたものではない。

(2)新規事項追加禁止要件のむすび

したがって,本件補正は,特許法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。


3 目的要件

上記「2 新規事項追加禁止要件」において指摘したとおり,本件補正は,特許法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものであるが,
仮に,本件補正が,当初明細書等の記載の範囲内でなされたものであるとして,特許法第17条の2第5項の規定を満たすものであるか否か,すなわち,本件補正が,特許法第17条の2第5項に規定する請求項の削除,特許請求の範囲の減縮(特許法第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る),誤記の訂正,或いは,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る)の何れかを目的としたものであるかについて,以下に検討する。

(1)補正事項1,2について

補正事項1は,発明特定事項である「前記送信手段により送信された通知データの返信情報に応じて,タスクの実行に必要な前処理を行う前処理手段」に,「前記前処理手段は,前記返信情報に基づいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し,」の限定を加え,
補正事項2は,発明特定事項である「前記前処理手段により前処理が行われた後に,タスクを実行する実行手段」に,「前記実行手段は,前記前処理手段により決定されたタイミングに基づいて,タスクを実行し,」の限定を加えることを目的とするものであり,本件補正によっても,補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。

(2)補正事項3,5について

補正事項3は,「前記返信情報に,前記クライアント端末による,タスク実行の要否の判断に必要であるタスク情報を挿入する情報挿入手段」を,「前記返信情報に,前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段」に変更することは,「タスク情報」について「前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための」情報内容を追加するものであり,限定を目的とするものとは認められない。
また,補正事項5についても,補正事項3と同様,「タスク情報」について「前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための」情報内容を追加するものであり,限定を目的とするものとは認められない。
そして,補正事項3,5は,請求項の削除,誤記の訂正,或いは,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る)のいずれにも該当しない。

(3)補正事項4について

補正事項4は,発明特定事項である「前記クライアント端末が,前記返信情報に挿入されたタスク情報に応じて,タスクの前処理を行うステップ」に,「前記タスクの前処理を行うステップにおいて,前記返信情報に基づいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定する」の限定を加えることを目的とするものであり,本件補正によっても,補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。

(4)補正事項6,7について

補正事項6,7は,発明特定事項である「送信された前記通知データの返信情報に応じて,タスクの実行に必要な前処理を行うステップ」に,「前記タスクの前処理を行うステップにおいて,タスク実行の要否を判断し,タスク実行の必要がある場合に,自機のリソース状況と,返信情報に含まれるタスクのデータサイズとに基づいて,タスク実行に要するデータファイルの取得のタイミングとタスク実行のタイミングとを決定し,」の限定を加え,「前処理後に,タスクを実行する実行ステップ」に,「前記タスクを実行するステップにおいて,前記タスクの前処理を行うステップにおいて決定されたタイミングに基づいて,タスクを実行させる」の限定を加えることを目的とするものであり,本件補正によっても,補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。

(5)目的要件のむすび

したがって,上記補正事項1,2,4,6,7は限定的減縮を目的とするものであるものの,上記補正事項3,5の目的は請求項の削除,限定的減縮,誤記の訂正,不明瞭な記載の釈明の何れにも該当しないものである。

してみると,本件補正は,特許法第17条の2第5項第1号の請求項の削除,同条同項第2号の特許請求の範囲の減縮(第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。),同条同項第3項の誤記の訂正,同条同項第4項の明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)を目的とするものに限られるものではない。

したがって,本件補正は,特許法第17条の2第5項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。


4 独立特許要件

上記「2 新規事項追加禁止要件」において指摘したとおり,本件補正は,特許法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものであり,
上記「3 目的要件」において指摘したとおり,本件補正は,特許法第17条の2第5項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものであるが,
仮に,本件補正が,当初明細書等の記載の範囲内でなされたものであるとし,特許請求の範囲の減縮(限定的減縮)を目的とする場合,限定的減縮を目的として補正された補正後の請求項2に記載された発明が特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか)以下に検討する。

4-1 特許法第36条(記載要件)について

(1)上記「2 新規事項追加禁止要件」で指摘したとおり,当初明細書等においては,「クライアント端末がタスク実行の要否を判断」するための「タスク情報」と,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」が異なる態様として例示されているに過ぎず,補正後の請求項2で特定される「前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」が記載されていると認めることはできず,他のすべての記載を総合しても,導き出し得るものではない。
そうすると,補正後の請求項2に係る事項は,本願明細書の発明の詳細な説明に記載されていないものである。
よって,補正後の特許請求の範囲の記載は,特許法第36条第6項第1号に規定する要件を満たしていない。

(2)上記(1)で指摘のとおり,本願明細書の発明の詳細な説明には,補正後の請求項2のような,「クライアント端末がタスク実行の要否を判断」することと,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とする「タスク情報」の具体的な態様については記載されておらず,当該技術分野の技術常識を考慮しても補正後の請求項2で特定されるような「タスク情報」を如何に実現するか不明であるから,本願明細書の発明の詳細な説明は,請求項2に係る発明について,当業者がその実施をすることができる程度に明確かつ十分に記載したものではない。
よって,本願明細書の発明の詳細な説明の記載は,特許法第36条第4項第1号に規定する要件を満たしていない。

(3)補正後の請求項2の発明特定事項である「前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」が如何なる「タスク情報」であるか不明であり,「タスク情報」に基いてどのように「クライアント端末がタスク実行の要否を判断」することと,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とするか不明であるから,補正後の請求項2の「前記返信情報に,前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段」が特定する情報処理も不明確である。
この点に関し,本願明細書の発明の詳細な説明を参酌しても,「クライアント端末がタスク実行の要否を判断」するための「タスク情報」と,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」ための「タスク情報」が異なる態様として例示されているに過ぎず,補正後の請求項2で特定される,両者を同時に可能とする「タスク情報」を具体的に把握することはできない。
してみると,補正後の請求項2に係る発明は,明確でない。

(3)小括

よって,補正後の発明の詳細な説明及び特許請求の範囲の記載は,特許法第36条第4項第1号,第6項第1号および第2号に規定する要件を満たしておらず,補正後の請求項2に係る発明は,特許出願の際独立して特許を受けることができないものである。


4-2 特許法第29条第2項(進歩性)について

(1)本件補正発明

上記平成27年7月6日付けの手続補正により補正された特許請求の範囲の請求項2には,
「 クライアント端末からの通知データに対して,返信情報を返信する返信手段と,
前記返信情報に,前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報を挿入する情報挿入手段と
を有する情報処理装置。」
と記載されている。
ここで,上記「2 新規事項追加禁止要件」で指摘したとおり,当初明細書等の発明の詳細な説明には,「クライアント端末がタスク実行の要否を判断」することと,「クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定する」こととを同時に可能とする「タスク情報」の具体的な態様については記載されていないことから,以下では,補正後の請求項2の「前記クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」が,本願明細書の発明の詳細な説明に記載されるような,「前記クライアント端末がタスク実行の要否を判断」するための情報,および「前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための」情報からなる「タスク情報」を意味するものとして検討する。

そこで,本件補正発明は次のとおりのものとして,以下の検討を行う。
「 クライアント端末からの通知データに対して,返信情報を返信する返信手段と,
前記返信情報に,前記クライアント端末がタスク実行の要否を判断するための情報,および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなるタスク情報を挿入する情報挿入手段と
を有する情報処理装置。」


(2)引用例

(2-1)引用例1に記載されている技術的事項および引用発明

ア 本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり,原審の拒絶査定の理由である平成27年1月21日付けの拒絶理由通知において引用された,特開2007-334898号公報(平成19年12月27日出願公開,以下,「引用例1」という。)には,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「【0008】
以下本発明の実施例を,図面を参照して説明する。この実施例はクライアントがサーバに対して要求情報であるハートビート・データを定期的に送信して当該クライアントがそのサーバに現在アクセス中であることを知らせる。サーバは,その種のハートビート・データの発信に応答して新規或いは更新ソフトウエア・データや補足情報等をクライアントに定期的に送信する。より詳細に述べれば,この実施例は,定期的なハートビート・パルスの受信時にサーバが有している新規或いは更新された実行可能コードを,それを必要としているクライアントに伝達することを選択的に可能にするシステムである。
【0009】
図1は本発明のデータ配信システム100を示すブロック図である。データ配信システム100では,サーバ102と,クライアントであるコンピュータからなる第1のワークステーション108と第2のワークステーション110を,分散処理環境を有するコンピュータ・ネットワーク104で接続している。サーバ102とコンピュータ・ネットワーク104は,通信リンク106を介して接続され,第1のワークステーション108とコンピュータ・ネットワーク104は,通信リンク112を介して接続され,第2のワークステーション110とコンピュータ・ネットワーク104は,通信リンク114を介して接続される。分散処理環境とは,コンピュータ・ネットワーク104を介して,2台以上の電子装置間でデータを交換することができる環境のことである。」

B 「【0034】
次に図4及び図5のフローチャート400及び500を参照して,データ配信システム100の作用を更に詳述する。図4は,サーバ102側の動作のフローチャートを示す。スタート後,ステップ402で,サーバ102は,サーバ102が提供するサービスに関連した複数のワークステーション108,110のそれぞれからハートビート・データを受信する。サーバ102によって提供されるサービスは,ウェブ‐ベースのサービスを含み,リモート・アクセス,セキュリティ検証サービス,割り当て管理,リモート・ストレージ,ドキュメント処理操作,プリント・ジョブ生成,電子メール,ドキュメント管理サービス等が含まれる。本実施例では各ワークステーション108,110は,各ワークステーション108,110が,サーバ102にアクセスしていることを示すハートビート・データを,サーバ102に対して所定の間隔で送信することを指示される。ハートビート・データを送信する間隔は,サーバ102に対する各ワークステーション108,110の初期接続の間にあらかじめ設定されるか,或いは,サーバ102がハートビート・データに応答して,所定の間隔を設定する。
【0035】
その後ステップ404において,サーバ102に関連付けされているすべてのワークステーション108,110からハートビート・データを受信しているか否かを判断する。1ないしは複数のワークステーションが無応答である場合,即ち,あらかじめ設定された時間内にハートビート・データの受信に失敗していると判断すると,ステップ406で,無応答のワークステーションを識別して,ステップ408で,無応答のワークステーションに対応するアラーム信号を生成し,ステップ410に進む。一方,ステップ404で,全てのワークステーションがハートビート・データを送信したと判断したら,ステップ410に進む。ステップ410では,受信したハートビート・データを基礎として,アクセスしたワークステーションを識別する。
【0036】
次にステップ412で,新規の或は更新したソフトウエアがワークステーションで利用可能か否か判断する。新規の或いは更新したソフトウエア,または補足データが利用可能か否かの判断は,識別されたそれぞれのワークステーションについて行われる。識別されたワークステーションのために利用可能な新規の又は更新したソフトウエアが無いときは,ステップ420に進み,次のハートビート・データの送信までの期間が設定され,ワークステーションに送信される。その後ステップ418で,新規の或いは更新したソフトウエア,または補足データが利用可能か否かの判断すべき別のワークステーションが残っているか否か判断される。アップグレードを判断すべきワークステーションが残っていなければ,操作を終了する。
【0037】
ステップ412で,識別された例えば第1のワークステーション108で,新しいソフトウエアが利用可能であると判断されると,ステップ414に進み,第1のワークステーション108のための次のハートビート・データを送信するまでの期間や,新規或いは更新されたソフトウエア,または実行可能コード等を有する応答データを生成する。この応答データは,その後ステップ416で,第1のワークステーション108に送信される。ソフトウエアが単一の『ピギーバック』送信,すなわちハートビート・データ送信に対する応答として大きすぎる場合に,サーバ102は,そのソフトウエアをより小さいコンポーネントに分割して,複数のセグメントからなる応答データ・セットとすることが可能であり,その後それが個別に,またはグループとして,その後に続くハートビート・データの間隔で対応するワークステーションに送信され,それによってワークステーション108では,全ての更新を受信し,最後のセグメントを受信したら,インストール可能となる。」

C 「【0039】
次に図5のフローチャートを参照してデータ配信システム100のワークステーション側の動作を詳述する。図5に示されているとおり,フローチャート500は,ワークステーションによるハートビート・データの生成およびソフトウエアの更新,アップグレード,または補足データの受信の方法を例示している。図5に示されている方法は,サーバ102によって提供されるサービスに関連付けされた各ワークステーションに適用可能である。スタート後,ステップ502で,ハートビート・データを生成してサーバ102に送信する。ハートビート・データは,各ワークステーション108,110の識別子を有し,ワークステーション108,110がサーバ102の提供するサービスにアクセスしていることを示す。
…(中略)…
【0042】
この実施例によれば,ワークステーション108,110より,自身の識別データを有するハートビート・データを所定の期間でサーバ102に送信する。これに応答してサーバ102からワークステーション108,110に配信されるソフトウエアや補足データ等の応答データをインストールする。これにより,ワークステーション108,110は,ユーザや管理者等によるインストールの指示を全く必要とすることなく,新たなソフトウエアや補足データを定期的にインストールする。又,サーバ102による応答データが大きい場合でも,応答データを複数のセグメントからなる応答データ・セットに分割することが出来る。従って,前のハートビート・データから,次のハートビート・データまでの所定の期間内に,応答データが,収まらない場合でも,次のハートビート・データに応答する形で,残りのセグメントを応答可能となる。」


イ ここで,引用例1に記載されている事項を検討する。

(ア)上記Aの段落【0009】の「図1は本発明のデータ配信システム100を示すブロック図である。データ配信システム100では,サーバ102と,クライアントであるコンピュータからなる第1のワークステーション108と第2のワークステーション110を,分散処理環境を有するコンピュータ・ネットワーク104で接続している。サーバ102とコンピュータ・ネットワーク104は,通信リンク106を介して接続され,第1のワークステーション108とコンピュータ・ネットワーク104は,通信リンク112を介して接続され,第2のワークステーション110とコンピュータ・ネットワーク104は,通信リンク114を介して接続される。分散処理環境とは,コンピュータ・ネットワーク104を介して,2台以上の電子装置間でデータを交換することができる環境のことである。」との記載からすると,「サーバ」は複数の「ワークステーション」とともに「データ配信システム」を構成することは明らかであり,「コンピュータ・ネットワーク」及び「通信リンク」を介して複数の「ワークステーション」と接続されていることが読み取れるから,引用例1には,
“データ配信システムにおいて,複数のワークステーションとコンピュータ・ネットワーク及び通信リンクを介して接続されたサーバ”
が記載されていると解される。

(イ)上記Bの段落【0034】の「スタート後,ステップ402で,サーバ102は,サーバ102が提供するサービスに関連した複数のワークステーション108,110のそれぞれからハートビート・データを受信する。」との記載,上記Cの段落【0039】の「スタート後,ステップ502で,ハートビート・データを生成してサーバ102に送信する。ハートビート・データは,各ワークステーション108,110の識別子を有し,ワークステーション108,110がサーバ102の提供するサービスにアクセスしていることを示す。」との記載からすると,「サーバ」は複数の「ワークステーション」からの識別子を有する「ハートビート・データ」を受信する手段を実質的に備えることが読み取れるから,引用例1には,
“複数のワークステーションからの識別子を有するハートビート・データを受信する受信手段”
が記載されていると解される。

(ウ)上記Bの段落【0035】の「その後ステップ404において,サーバ102に関連付けされているすべてのワークステーション108,110からハートビート・データを受信しているか否かを判断する。」,「一方,ステップ404で,全てのワークステーションがハートビート・データを送信したと判断したら,ステップ410に進む。ステップ410では,受信したハートビート・データを基礎として,アクセスしたワークステーションを識別する。」との記載からすると,「サーバ」は受信した「ハートビート・データ」を基礎として,アクセスしたワークステーションを識別することが読み取れる。
また,上記Bの段落【0036】の「次にステップ412で,新規の或は更新したソフトウエアがワークステーションで利用可能か否か判断する。新規の或いは更新したソフトウエア,または補足データが利用可能か否かの判断は,識別されたそれぞれのワークステーションについて行われる。」,段落【0037】の「ステップ412で,識別された例えば第1のワークステーション108で,新しいソフトウエアが利用可能であると判断されると,ステップ414に進み,第1のワークステーション108のための次のハートビート・データを送信するまでの期間や,新規或いは更新されたソフトウエア,または実行可能コード等を有する応答データを生成する。」との記載からすると,「サーバ」は,識別したそれぞれの「ワークステーション」について,新しいソフトウエアが利用可能であると判断されると,当該「ワークステーション」のための次のハートビート・データを送信するまでの期間や,新規或いは更新されたソフトウエア,または補足データ,実行可能コード等を有する応答データを生成する応答データ生成手段を実質的に備えることが読み取れるから,引用例1には,
“受信したハートビート・データを基礎として,アクセスしたワークステーションを識別し,新しいソフトウエアが利用可能であると判断されると,識別したワークステーションのための次のハートビート・データを送信するまでの期間や,新規或いは更新されたソフトウエア,または補足データ,実行可能コード等を有する応答データを生成する応答データ生成手段”
が記載されていると解される。

(エ)上記Bの段落【0037】の「この応答データは,その後ステップ416で,第1のワークステーション108に送信される。」との記載,上記Cの段落【0042】の「この実施例によれば,ワークステーション108,110より,自身の識別データを有するハートビート・データを所定の期間でサーバ102に送信する。これに応答してサーバ102からワークステーション108,110に配信されるソフトウエアや補足データ等の応答データをインストールする。」との記載からすると,「応答データ」は「ワークステーション」からの「ハートビート・データ」に対する応答であることは明らかであり,「サーバ」は「応答データ」を「ワークステーション」に送信する送信手段を実質的に備えることが読み取れるから,引用例1には,
“ハートビート・データに対する応答として,生成された応答データをワークステーションに送信する送信手段”
が記載されていると解される。

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

「データ配信システムにおいて,複数のワークステーションとコンピュータ・ネットワーク及び通信リンクを介して接続されたサーバであって,
複数のワークステーションからの識別子を有するハートビート・データを受信する受信手段と,
受信した前記ハートビート・データを基礎として,アクセスした前記ワークステーションを識別し,新しいソフトウエアが利用可能であると判断されると,識別した前記ワークステーションのための次のハートビート・データを送信するまでの期間や,新規或いは更新されたソフトウエア,または補足データ,実行可能コード等を有する応答データを生成する応答データ生成手段と,
前記ハートビート・データに対する応答として,生成された応答データを前記ワークステーションに送信する送信手段と
を有するサーバ。」


(2-2)引用例2に記載されている技術的事項

ア 本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり,原審の拒絶査定の理由である平成27年1月21日付けの拒絶理由通知において引用された,特開2008-242983号公報(平成20年10月9日出願公開,以下,「引用例2」という。)には,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

D 「【0031】
図9は,第2の実施の形態に係る分散処理管理装置80の構成を示す。第2の実施の形態の分散処理管理装置80は,図2に示した第1の実施の形態の分散処理管理装置80の構成に比して,通信タスク生成部94に代えてタスク情報通知部97を備える。その他の構成及び動作は第1の実施の形態と同様である。
【0032】
タスク情報通知部97は,タスクを分配した端末20に,タスクが必要とするデータの入手先の装置に関する情報を通知する。これにより,端末20は,入手先の装置からデータを入手するための送信タスクを自ら生成して入手先の装置に送信することができる。タスク情報通知部97は,タスクが必要とするデータの内容に関する情報を更に通知してもよい。例えば,タスクの入力データのデータ型,データ長,入力タイミングに関する条件などを通知してもよい。
【0033】
図10は,第2の実施の形態に係る端末20の構成を示す。第2の実施の形態の端末20は,図6に示した第1の実施の形態の端末20の構成に比して,タスク情報取得部55及び通信タスク生成部56を更に備える。その他の構成及び動作は第1の実施の形態と同様である。
【0034】
タスク情報取得部55は,データを処理するタスクに関する情報を取得する。タスク情報取得部55は,タスク取得部51が取得するタスクが必要とするデータの入手先に関する情報を取得する。通信タスク生成部56は,取得したタスクが必要とするデータの入手先が,自端末にネットワークを介して接続された別の端末である場合に,入手先の端末が自端末へ,タスクが必要とするデータを送信するための送信タスクを生成して入手先の端末へ送信する。また,通信タスク生成部56は,入手先の端末からデータを受信してタスクの入力データを生成するための受信タスクを生成して受信タスク実行部53へ送る。」

イ 上記Dの記載からすると,引用例2には,次の技術が記載されている。

「分散処理管理装置から端末に送信するタスク情報として,タスクが必要とするデータの入手先やサイズ,入力タイミングを含むようにし,端末側では,受信した入力タイミングに基づきタスク実行に係るデータファイルを取得する技術。」

(2-3)引用例3に記載されている技術的事項

ア 本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり,原審の平成27年3月31日付けの拒絶査定において引用された,特開平8-249163号公報(平成8年9月27日出願公開,以下,「引用例3」という。)には,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

E 「【0048】さらに,バージョンアップの前処理に,バージョンアップ前の状態を保存等しておけば,バージョンアップされたソフトウェアにより別の障害が発生した場合にも,バージョンアップ前の状態に戻すことによりシステム全体の停止時間の短縮化を図ることができる。
<第2の実施例>
図2は,本発明の第2の実施例にかかるネットワークシステムのソフトウェアバージョン管理装置の構成を示す図である。
【0049】本実施例のネットワークシステムのソフトウェアバージョン管理装置は,ネットワーク上の1台のコンピュータをサーバとし,このサーバ上のソフトウェアをバージョンアップするとネットワーク1に組み込まれた他のコンピュータのソフトウェアもバージョンアップされるように構成されている。
【0050】同図に示すように,サーバ側コンピュータ32は,バージョン情報記憶機構41,バージョンアップ機構42,バージョン情報通知機構43,ソフトウェア管理部44,ソフトウェアアップロード機構45を備えている。
【0051】バージョン情報記憶機構41は,サーバ側コンピュータのソフトウェアのバージョン情報を格納するものである。このバージョン情報には,ソフトウェア名称,ソフトウェア属性(デバイスドライバ,システム用コンフィグレーションファイル,データファイル等),バージョン番号,自動バージョンアップ禁止・許可,バージョンアップ時の前処理,後処理等の操作に関する情報,バージョンアップのタイミング,バージョンアップ時にオペレータの判断が必要か等の情報を包含している。
【0052】バージョンアップ機構42は,外部からのバージョンアップ要求に基づいて,サーバ側のソフトウェア管理部44に格納されたソフトウェアをバージョンアップされたソフトウェアにバージョンアップする。
【0053】バージョン情報通知機構43は,クライアント側のバージョン情報受信機構と通信し,バージョンアップされたソフトウェアのバージョン情報をクライアント側に通知する。
【0054】ソフトウェア管理部44は,サーバ側の管理下にあり,ネットワーク31に組み込まれているコンピュータ全てのソフトウェアの最新バージョンを格納している。
【0055】ソフトウェアアップロード機構45は,クライアント側のソフトウェアダウンロード機構54と通信し,バージョンアップされたソフトウェアをクライアント側にアップロードする。
【0056】次に,クライアント側コンピュータ33の構成について説明する。ネットワーク31に組み込まれている全てのクライアント側コンピュータの構成は,クライアント側コンピュータ33と同様の構成である。
【0057】同図に示すように,クライアント側コンピュータ33は,バージョン情報受信機構51,バージョン情報比較機構52,バージョン情報記憶機構53,ソフトウェアダウンロード機構54,バージョンアップ機構55,アクセス制御機構56,自己のソフトウェア管理部57とで構成されている。
【0058】バージョン情報受信機構51は,サーバ側のコンピュータ32のバージョン情報通知機構43から送信されたバージョンアップされたソフトウェアのバージョン情報を受信する。
【0059】バージョン情報比較機構52は,バージョン情報記憶機構53に記憶されているクライアント側コンピュータ33のソフトウェアのバージョン情報と,バージョン情報受信機構51により受信したバージョンアップされたソフトウェアのバージョン情報とを比較し,バージョンアップが必要かつ許可されていればバージョンアップ機構55にバージョン情報を含むバージョンアップ要求を出力する。
【0060】ソフトウェアダウンロード機構54は,バージョン情報比較機構52からバージョンアップ要求が出力されるとサーバのアップロード機構45からアップロードされたバージョンアップされたソフトウェアをダウンロードする。
【0061】バージョンアップ機構55は,自己のソフトウェア管理部57に格納されているソフトウェアをソフトウェアダウンロード機構54からダウンロードされたバージョンアップされたソフトウェアにバージョンアップする。」

イ 上記Eの記載からすると,引用例3には,次の技術が記載されている。

「クライアント側でソフトウェアのバージョンアップを行う時に,サーバがバージョンアップを行うタスクに関連するバージョン情報をクライアントに送信すると,クライアント側では,前処理として,当該バージョン情報に基づいてバージョンアップを行うタスクを実行するか否かを判断し,バージョンアップが必要と判断した場合にサーバから当該バージョンアップされたソフトウェアをダウンロードする技術。」


(3)対比

ア 本件補正発明と引用発明とを対比する。

(ア)引用発明の「サーバ」は「複数のワークステーションとコンピュータ・ネットワーク及び通信リンクを介して接続され」,「複数のワークステーションからの識別子を有するハートビート・データを受信する」ことから,引用発明の「サーバ」,「ワークステーション」は本件補正発明の「情報処理装置」,「クライアント端末」に相当すると言える。

(イ)引用発明では,「サーバ」は「複数のワークステーションからの識別子を有するハートビート・データを受信」し,「前記ハートビート・データに対する応答として,生成された応答データを前記ワークステーションに送信する送信手段」を備えるところ,「ハートビート・データ」は「ワークステーション」から「サーバ」に通知されると言えるから,引用発明の「ハートビート・データ」は本件補正発明の「通知データ」に相当すると言える。
また,引用発明の「応答データ」は,「ワークステーション」からの「ハートビート・データ」に対して「サーバ」から返信される情報とみることができるから,引用発明の「応答データ」は情報内容が相違するものの,本件補正発明の「返信情報」に対応すると言える。
そうすると,引用発明の「前記ハートビート・データに対する応答として,生成された応答データを前記ワークステーションに送信する送信手段」は本件補正発明の「クライアント端末からの通知データに対して,返信情報を返信する返信手段」に相当すると言える。

(ウ)引用発明では,「応答データ生成手段」が「受信した前記ハートビート・データを基礎として,アクセスした前記ワークステーションを識別し,」「応答データを生成する」ところ,「応答データ」は「識別した前記ワークステーションのための次のハートビート・データを送信するまでの期間や,新規或いは更新されたソフトウエア,または補足データ,実行可能コード等」を有し,その中で「新規或いは更新されたソフトウエア」は「ワークステーション」で実行されるのタスク実行に要するデータファイルであることは明らかであるから,「新規或いは更新されたソフトウエア,または補足データ,実行可能コード等」は,タスク実行に要するデータファイルに係る情報を含むタスク関連情報とみることができる。
一方,本件補正発明の「情報挿入手段」が「返信情報」に挿入する「タスク情報」は,「クライアント端末がタスク実行の要否を判断するための情報,および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からな」り,「クライアント端末がタスク実行に要するデータファイル」に係る情報を含むとみることができる。
そうすると,引用発明の「応答データ」が有する「識別した前記ワークステーションのための次のハートビート・データを送信するまでの期間や,新規或いは更新されたソフトウエア,または補足データ,実行可能コード等」と,本件補正発明の「クライアント端末がタスク実行の要否を判断するための情報,および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなるタスク情報」とは,“クライアント端末がタスク実行に要するデータファイルに係る情報を含むタスク関連情報”である点で一致すると言える。

(エ)引用発明の「応答データ生成手段」は「応答データ」を生成するところ,上記(ウ)の検討より,本件補正発明においては,「返信情報」に「クライアント端末がタスク実行に要するデータファイル」に係る情報を含む「タスク関連情報」を挿入するとみることができるから,引用発明の「応答データ生成手段」と本件補正発明の「情報挿入手段」とは,“返信情報に,”“タスク関連情報を挿入する情報挿入手段”である点で一致していると言える。
そうすると,引用発明の「受信した前記ハートビート・データを基礎として,アクセスした前記ワークステーションを識別し,新しいソフトウエアが利用可能であると判断されると,識別した前記ワークステーションのための次のハートビート・データを送信するまでの期間や,新規或いは更新されたソフトウエア,または補足データ,実行可能コード等を有する応答データを生成する応答データ生成手段」と,
本件補正発明の「前記返信情報に,前記クライアント端末がタスク実行の要否を判断するための情報,および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなるタスク情報を挿入する情報挿入手段」とは,後記する点で相違するものの,
“返信情報に,前記クライアント端末がタスク実行に要するデータファイルに係る情報を含むタスク関連情報を挿入する情報挿入手段”である点で共通していると言える。

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

<一致点>

「 クライアント端末からの通知データに対して,返信情報を返信する返信手段と,
前記返信情報に,前記クライアント端末がタスク実行に要するデータファイルに係る情報を含むタスク関連情報を挿入する情報挿入手段と
を有する情報処理装置。」

<相違点>

返信情報に挿入するタスク関連情報に関し,本件補正発明では,「クライアント端末がタスク実行の要否を判断し,前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するためのタスク情報」であるのに対して,引用発明では,「新規或いは更新されたソフトウエア,または補足データ,実行可能コード等」を含む情報である点。


(4)当審の判断

上記相違点について検討する。

引用発明では,「サーバ」は,「新規或いは更新されたソフトウエア,または補足データ,実行可能コード等」を含む情報を,「ワークステーション」で実行するタスクに関連する情報として「応答データ」に挿入するところ,クライアント側でソフトウェアのバージョンアップを行う時に,サーバがバージョンアップを行うタスクに関連するバージョン情報をクライアントに送信すると,クライアント側では,前処理として,当該バージョン情報に基づいてバージョンアップを行うタスクを実行するか否かを判断し,バージョンアップが必要と判断した場合にサーバから当該バージョンアップされたソフトウェアをダウンロードすることは,例えば引用例3(上記Eを参照)に記載されるように,本願出願前には当該技術分野において普通に用いられていた周知技術であった。
また,サーバから端末に送信するタスク関連情報として,タスクが必要とするデータの入力タイミングを含むようにし,端末側では,受信した入力タイミングに基づきタスク実行に係るデータファイルを取得することも,例えば引用例2(上記Dを参照)に記載されるように,本願出願前には周知技術であった。
そして,クライアント端末におけるタスク実行に係るタスク関連情報として,サーバからタスク実行の要否を判断するための情報,あるいは,タスク実行に係るデータファイルの入力タイミングの情報を送信するかどうかは,必要に応じて適宜選択し得た設計的事項である。
そうすると,引用発明において,上記周知技術を適用し,適宜,ワークステーションからのハートビート・データに対する応答データに,ワークステーションが前処理としてタスク実行の要否を判断するための情報,および,タスク実行に係るデータファイルを入力するタイミングを決定するための情報を,タスク情報として挿入して送信すること,すなわち,上記相違点に係る構成とすることは,当業者が容易に想到し得たことである。

上記で検討したごとく,相違点に係る構成は当業者が容易に想到し得たものであり,そして,本件補正発明の奏する作用効果は,上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。
したがって,本件補正発明は,上記引用発明及び当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許出願の際独立して特許を受けることができない。


4-3 独立特許要件のむすび

上記4-1のとおり,補正後の発明の詳細な説明及び特許請求の範囲の記載は,特許法第36条第4項第1号,同条第6項第1号および第2号に規定する要件を満たしておらず,補正後の請求項2に係る発明は,この理由によって特許出願の際独立して特許を受けることができないものである。

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

したがって,本件補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反する。


5 補正却下の決定のむすび

上記「2 新規事項追加禁止要件」で指摘したとおり,本件補正は,特許法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
また,上記「3 目的要件」で指摘したとおり,本件補正は,特許法第17条の2第5項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
加えて,仮に本件補正が,当初明細書等の記載の範囲内でなされたものであるとし,特許請求の範囲の減縮(限定的減縮)を目的とする場合でも,「4 独立特許要件」で指摘したとおり,補正後の請求項2に記載された発明(本件補正発明)は,特許出願の際独立して特許を受けることができるものではないから,本件補正は特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,上記補正却下の決定の結論のとおり決定する。


第3 本願発明について

1 本願発明

平成27年7月6日付けの手続補正は上記のとおり却下されたので,補正後の請求項2に対応する補正前の請求項2に係る発明(以下,「本願発明」という。)は,平成27年3月23日付けの手続補正により補正された特許請求の範囲の請求項2に記載された事項により特定される,以下のとおりのものである。

「 クライアント端末からの通知データに対して,返信情報を返信する返信手段と,
前記返信情報に,前記クライアント端末による,タスク実行の要否の判断に必要であるタスク情報を挿入する情報挿入手段と
を有する情報処理装置。」

2 引用例に記載されている技術的事項及び引用発明

原査定の拒絶の理由に引用された,引用発明は,前記「第2 平成27年7月6日付けの手続補正についての補正却下の決定」の「4 独立特許要件」「4-2 特許法第29条第2項(進歩性)について」の「(2)引用例」に記載したとおりである。

3 対比・判断

本願発明は,前記「第2 平成27年7月6日付けの手続補正についての補正却下の決定」の「4 独立特許要件」「4-2 特許法第29条第2項(進歩性)について」で検討した本件補正発明の発明特定事項である「前記クライアント端末がタスク実行の要否を判断するための情報,および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなるタスク情報」から,「および前記クライアント端末がタスク実行に要するデータファイルの取得のタイミングを決定するための情報からなる」との事項を削除したものである。

そうすると,本願発明の発明特定事項を全て含む本件補正発明が,前記「第2 平成27年7月6日付けの手続補正についての補正却下の決定」の「4 独立特許要件」「4-2 特許法第29条第2項(進歩性)について」の「(2)引用例」乃至「(4)当審の判断」に記載したとおり,引用発明及び当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから,上記特定の限定を省いた本願発明も同様の理由により,引用発明及び当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものである。


第4 むすび

以上のとおり,本願の請求項2に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2016-06-21 
結審通知日 2016-06-29 
審決日 2016-07-15 
出願番号 特願2011-239295(P2011-239295)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 575- Z (G06F)
P 1 8・ 561- Z (G06F)
最終処分 不成立  
前審関与審査官 漆原 孝治  
特許庁審判長 高木 進
特許庁審判官 石井 茂和
辻本 泰隆
発明の名称 情報処理システム、情報処理装置、クライアント端末、情報処理方法、及びプログラム  
代理人 横井 敏弘  
  • この表をプリントする

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