【事件の表示】
　特願２００３−５５３７７１「時間予約制でのサービス品質の設定」拒絶査定不服審判事件〔平成１５年　６月２６日国際公開、ＷＯ０３／５２９９３、平成１７年　５月１２日国内公表、特表２００５−５１３８６５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、２００２年１２月１１日（パリ条約による優先権主張外国庁受理２００１年１２月１５日、米国）を国際出願日とする出願であって、平成２０年１０月２日付けで拒絶査定がなされ、これに対し、平成２１年１月１３日に拒絶査定に対する審判請求がなされるとともに、平成２１年２月１２日付けで手続補正がなされ、平成２２年７月５日付けで審尋がなされ、平成２２年１２月２１日に回答書が提出されたものである。
　
２．平成２１年２月１２日付けの手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　平成２１年２月１２日付けの手続補正を却下する。
　
［理由］
（１）補正後の本願発明
　本件補正により、特許請求の範囲の請求項２３は、
　「ネットワークにおいて、クライアント間でのセッションに対するサービス品質（ＱｏＳ）契約を設定することができることを設ける方法であって、該ネットワークは該ネットワークを通じて情報を送るルーティング・エレメントを有し：
　該セッションに対する予約を送信する工程であって、該予約は該セッションについての時間帯を特定するので、クライアントが、該特定時間帯中に、保証されたサービス・レベルの該セッションに参加し得る工程；及び
　前記セッションがいつ終了したかの通知を送信する工程；
を含むことを特徴とする方法。」
と補正された。  
　
　上記補正は、願書に最初に添付した明細書または図面に記載した事項の範囲内において、補正前の特許請求の範囲の請求項２３に記載された「ネットワークにおいて、クライアント間でのセッションに対するサービス品質（ＱｏＳ）契約を設定することができることを設ける方法」が「前記セッションがいつ終了したかの通知を送信する工程；を含む」ことを限定するものであり、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の請求項２３に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
（２）引用例
　原査定の拒絶の理由に引用された特開２０００−２５３０５３号公報（以下、「引用例」という。）には、図面とともに以下の記載がある。
　
　イ．「【請求項１】ネットワークドメインは、ＩＰパケットの転送とデータ処理が可能な通信ノードと、ネットワーク管理システムと、制御サーバとエンドシステム（ＥＳ）と、それらの間を接続する回線から構成され、前記ネットワークドメインが複数個接続されたネットワークシステムにおいて、ネットワークドメイン間の通信パスの設定交渉手段により、ネットワークドメインに跨る通信品質保証された通信パスを設定することを特徴とするネットワークシステム。」
　
　ロ．「【００１３】
【発明の実施の形態】本発明の第一の実施の形態を図１から図３２を参照して説明する。図１は本発明を適用するネットワークシステムの一構成例を示す図である。本システムは，ネットワークドメイン１０を複数個含むものである。一つのネットワークドメイン１０は、ＮＭＳ（Network Management System）１１、制御サーバ１２、通信ノード１３、ＰＣ端末あるいはサーバ装置のごときＥＳ（End System）１４、および、ＮＭＳ１１と制御サーバ１２と通信ノード１３を接続し該ネットワークドメイン１０内のネットワーク制御・管理のために使用する制御ネットワーク１６、通信ノード１３間を接続する中継ネットワーク回線１７、通信ノード１３とＥＳ１４間のアクセスネットワーク回線１８から構成される。制御サーバ１２、通信ノード１３、ＥＳ１４はそれぞれ複数個存在してよい。
【００１４】ネットワークドメイン１０の間は、制御ネットワーク１６間を接続する回線Ｌ１６と通信ノード１３間を接続する回線Ｌ１３により接続される。制御ネットワーク１６、中継ネットワーク回線１７、アクセスネットワーク回線１８、回線Ｌ１６、回線Ｌ１３は、例えばIEEE802 CSMA/CD、ATM、SONET/SDHのごときＬＡＮ(Local Area Network)およびＷＡＮ(Wide Area Network)であり、LANスイッチ、ＡＴＭスイッチ、SONET/SDH伝送装置と回線メディア（メタルケーブル、光ファイバー等）で実現される。以上で説明した構成要素は全てＩＰ(Internet Protocol)に基づく通信を行い、例えば、IPv4まはたIPv6に準拠したIPアドレスを持ち、相互にＩＰパケットによる通信が可能である。
【００１５】［ハードウェアの構成例と動作例説明]図２は本発明を適用する通信ノード１３の構成例を示す図である。通信ノード１３は、管理部１３１、サービス処理部１３２、転送処理部１３３、内部スイッチ部１３５、外部サービス処理部１３４から構成される。管理部１３１、サービス処理部１３２、転送処理部１３３は、内部スイッチ部１３５と接続されており、接続には内部スイッチポート１３９と内部スイッチパス１３６が使われ、内部スイッチポート１３９には、ユニークな番号（内部スイッチポート番号）が付与されている。管理部１３１、サービス処理部１３２、転送処理部１３３間には、ＣＰＵ間通信パス１３７が設けられている。転送処理部１３３と外部サービス処理部１３４との間は、処理部間ネットワーク回線１３８で接続されている。サービス処理部１３２、転送処理部１３３、外部サービス処理部１３４は複数個存在して良い。内部スイッチ部１３５は、例えば、クロスバースイッチ等で実現される。」
　
　ハ．「【００２８】図１３は、通信ノードの経路制御表１３３４３の構成例を示す図である。経路制御表１３３４３は、マスク１３３４３１、ＩＰアドレス１３３４３２、次ホップＩＰアドレス１３３４３３、出力先転送処理部（内部スイッチポート）アドレス１３３４３４の欄からなるエントリ１３３４３５が複数個により構成される。経路制御表１３３４３は、上り制御エンジン１３３４１が入力したパケット１９を対象に、マッチするエントリ１３３４３５を検索するための表である。検索時には、マスク１３３４３１の値と入力パケット１９のＩＰヘッダ部２０１の中にある宛先ＩＰアドレス部分とＡＮＤを取り、その後、ＩＰアドレス１３３４３２の値と比較をする。一致した場合、次ホップＩＰアドレス１３３４３３と出力先転送処理部（内部スイッチポート）アドレス１３３４３４の値が得られる。これらの値の使い方は、一般のＩＰルータの上り転送処理と同一で公知なので説明は省略する。
【００２９】図１４は、通信ノードのアドレス変換表１３３Ｄ３の構成例を示した図である。アドレス変換表１３３Ｄ３は、ＩＰアドレス１３３Ｄ３１、物理アドレス１３３Ｄ３２、エージングタイマ１３３Ｄ３３の欄からなるエントリ１３３Ｄ３４が複数個から構成される。アドレス変換表１３３Ｄ３は、下り制御エンジン１３３Ｄ１が入力したタグ付パケット２１のパケット内容部２１６に格納されているＩＰパケット２０を対象に、マッチするエントリ１３３Ｄ３４を検索するための表である。検索時には、ＩＰパケット２０のＩＰヘッダ部２０１の中にある宛先ＩＰアドレス部分とＩＰアドレス１３３Ｄ３１の値とを比較する。一致した場合、物理アドレス１３３Ｄ３２の値が、該タグ付きパケットの物理アドレス２１７に格納される。このようなアドレス変換表を用いた処理については、一般のＩＰルータの下り転送処理と同一で公知のため、詳細説明は省略する。
【００３０】以上の説明で出てきた、経路制御表１３３４３、アドレス変換表１３３Ｄ３の値は、それぞれ、いわゆるOSPF(Open Shortest Path First)等の経路制御プロトコル、ARP(Address Resolution Protocol)等のプロトコル制御ソフトウェアを実行させることにより得ることができる。実現方式などは、公知であるので詳細説明は省略する。」
  　
　ニ．「【００４９】［ソフトウェア機能実施例の説明]図２１は、ネットワークシステム・ソフトウェアの一構成例を示す図である。本システムは，管理ドメイン機能５０を複数個含むものである。一つの管理ドメイン機能５０は、システム運用管理機能５１、サービス管理機能５２、ネットワーク制御機能５３、ＥＳアプリ機能５４、通信ノード制御機能５５から構成される。これら機能間の接続関係、つまり情報の授受関係は、図の中で矢線により示している。複数の管理ドメイン機能５０の間は、図に示したようにネットワーク制御機能５３の間の接続６４と、通信ノード制御機能５５の間の接続６８とによって実現されるが、一般には、4個以上の管理ドメイン機能間をメッシュ状の接続を行うことができることは自明である。
【００５０】図１との対応では、システム運用管理機能５１はＮＭＳ１１の上で、ＥＳアプリ機能５４はＥＳ１４の上で、サービス管理機能５２およびネットワーク制御機能５３は制御サーバ１２の上で、通信ノード制御機能５５は、通信ノード１３の上で実行される。サービス管理機能５２およびネットワーク制御機能５３は、一台以上、複数個の制御サーバ１２の上で実行されても良い。次に、情報の授受関係を示す矢線と、図１との対応を説明する。５６は、一般に、アクセスネットワーク回線１８、通信ノード１３、制御ネットワーク回線１５、制御ネットワーク１６を経由して、ＥＳ１４とＮＭＳ１１が情報を授受する。
【００５１】５７、５８は、同様にアクセスネットワーク回線１８、通信ノード１３、制御ネットワーク回線１５、制御ネットワーク１６を経由して、ＥＳ１４と制御サーバ１２が情報を授受する。６０は制御ネットワーク回線１５、制御ネットワーク１６を経由して、ＮＭＳ１１と制御サーバ１２が情報を授受する。６１は、制御ネットワーク回線１５、制御ネットワーク１６を経由してＮＭＳ１１と通信ノード１３が情報を授受する。６２は制御ネットワーク回線１５、制御ネットワーク１６を経由して、制御サーバ１２間で情報を授受しても良い。６３は、制御ネットワーク回線１５、制御ネットワーク１６を経由して制御サーバ１２と通信ノード１３が情報を授受する。６４は、Ｌ１６を経由して制御サーバ１２間で情報を授受する。」
　
　ホ．「【００５４】図２７は、サービス管理機能５２およびネットワーク制御機能５３の一構成例を示す図である。サービス管理機能５２は、ソフト基盤機能５２２、サービス要求振分け機能５２１、サービス対応に存在するサービス管理機能５２３（図２７では、Ａ，Ｂ，Ｃのサービス管理機能として図示している）から構成される。次に、ネットワーク制御機能５３は、予約系資源管理機能５３１、即時系資源管理機能５３２、資源報告受信機能５３３、資源指示送信機能５３４、組織間調停機能５３５、ソフト基盤機能５３６から構成される。
【００５５】サービス要求振分け機能５２１は、５７経由、ＥＳアプリ機能５４からのサービス要求、例えばビデオ会議開催要求を受付けると、要求されたサービス種別毎に振り分けて、複数存在するサービス管理機能５２３の何れか、例えばビデオ会議サービス管理機能に相当するサービス管理機能５２３に転送する。サービス管理機能５２３は、サービス提供に必要なネットワーク資源、例えば、ビデオ会議の場合、参加者Ｘ，Ｙ，Ｚに相当する３箇所のＥＳ１４と、これら３箇所からの動画情報をミキシングして一つの動画情報にするデータ処理機能との間を接続する「ＱｏＳ保証されたパスの集合」と「該動画情報ミキシング機能」とから構成されるネットワーク資源を決定し、予約系資源管理機能５３１および即時系資源管理機能５３２にネットワーク資源を要求する。
【００５６】ここで、ネットワーク資源とは、上記説明のように、例えば、ＥＳ１４間の通信品質保証された通信パスであったり、通信ノード５５上で動作するデータ処理機能、つまり、Ｗｅｂキャッシング・プロキシ機能やビデオ会議用符号則変換機能、Ｎ個の動画ストリーム情報のミキシング機能であったり、さらに通信品質保証された通信パスと該データ処理機能を組み合わせたものである。
【００５７】予約系資源管理機能５３１および即時系資源管理機能５３２は、システム運用管理機能５１および組織間調停機能と連携し、ネットワーク資源を予約あるいは即時に獲得し、通信ノード１３への資源指示情報に変換する。資源指示送信機能５３４は、資源指示情報を送信すべき通信ノード１３を判断し、対応する一つ以上の通信ノード制御機能５５に送信する。各通信ノード制御機能５５からは資源報告情報が送信されてくるので、資源報告受信機能５３３が受信したのち、資源報告情報の種別を判定して、システム運用管理機能５１、予約系資源管理機能５３１および即時系資源管理機能５３２に通知する。」
　
　ヘ．「【００８１】［ＱｏＳ保証型多地点ビデオ会議サービスの予約と実行の実施例説明]次に、ＱｏＳ保証パス設定とデータ処理機能を組み合わせたサービスの例としてＱｏＳ保証型多地点ビデオ会議予約を例に実施例を説明する。会議主催者の（Ｘ）から、例えば、「３個所のＥＳ１４（Ｘ、Ｙ、Ｚと表記）の間で、開始時刻（Ｖ）から終了時刻（Ｗ）までの間、ビデオ品質（Ｑ）のビデオ会議を開催する。主催者は（Ｘ）」といった要求がサービス管理機能５２のサービス要求振分け機能５２１に入力され、該要求に対応するサービス管理機能５２３に該要求が転送される。
【００８２】サービス管理機能５２３は、主催者（Ｘ）が該要求を発行可能か否かの判定をＵＤＢ５１８並びにＰＤＢ５１９をアクセスし（Ｘ）の資格情報ならびに予約受付けポリシー情報基づいて行う。更に、「ビデオ品質（Ｑ）のビデオ会議」なる要求条件を確保すべきネットワーク資源の要求情報、すなわち、「多地点からの動画情報をミキシングして１つの共通動画情報に変換するデータ処理ソフトウェア（Ｓ）」、「（Ｓ）実行に必要なコンピューティング資源（ＣＰＵ性能、メモリ量等）」、（Ｘ−Ｓ間、Ｙ−Ｓ間、Ｚ―Ｓ間）の３つの「ＱｏＳ保証パス設定要求」に分解する。
【００８３】ここで、該「ＱｏＳ保証パス設定要求」を詳細に説明すると、「ＸとＳとの間に、開始時刻（Ｖ）から終了時刻（Ｗ）までの間、帯域（Ｚ）を確保する。確保する帯域は、ビデオ会議アプリに対応するＩＰパケット・フロー（Ｆ）に対し適用する。」要求であるが、（Ｓ）の位置は、予約系資源管理機能５３１において最適選択するために、この段階では確定していない。尚、帯域（Ｚ）の量は、ビデオ品質（Ｑ）およびビデオ会議アプリ、データ処理ソフトウェア（Ｓ）が使用する符号則等から決定される。以上、確保すべきネットワーク資源の要求情報を完成させ、予約系資源管理機能５３１へ要求情報を送信する。
【００８４】予約系資源管理機能５３１の処理は、上記[ＱｏＳ保証パスの予約と設定の実施例説明]と同様であるが、異なる点は以下である。（１）ＳＲＤＢ５３１５には、（通信ノード１３の番号、転送処理部１３３の番号、開始時刻（Ｖ）、終了時刻（Ｗ）、帯域（Ｚ）、ＩＰパケット・フロー（Ｆ）識別情報）に加え、（「多地点からの動画情報をミキシングして１つの共通動画情報に変換するデータ処理ソフトウェア（Ｓ）、（Ｓ）実行に必要なコンピューティング資源情報（通信ノード１３の番号、サービス処理部１３２または外部サービス処理部１３４の番号、割当てＣＰＵ性能値、割当てメモリ量等）」、）等の情報も登録されている。同様に、ＣＤＢ５１Ｂおよび現在＆将来資源情報管理機能５１ＣもＳＲＤＢ５３１５と同種の情報を持ち、ＣＤＢ５１Ｂは、運用管理者が計画しているネットワーク資源の構成情報と将来の利用計画（利用可能時間帯等）が格納されている。
【００８５】現在＆将来資源情報管理機能５１Ｃは、ＣＤＢ５１Ｂの内容と、各通信ノード制御機能５５の資源報告実行機能５５２２および通信ノード管理情報中継機能５５１２から定期的に報告される資源利用状況情報、および回線管理機能５１６からの情報を入力することにより、６０４経由の情報問合わせに対し、現在から将来に渡るネットワーク資源エレメント情報を応答する。該ネットワーク資源エレメント情報とは、各通信ノードで利用可能なデータ処理ソフトウェア（Ｓ）サービス処理部１３２または外部サービス処理部１３４のＣＰＵ性能値、メモリ量等である。
【００８６】予約系資源管理機能５３１は、上記の情報を入力し、「多地点からの動画情報をミキシングして１つの共通動画情報に変換するデータ処理ソフトウェア（Ｓ）」の実行位置（ある通信ノード内のサービス処理部１３２または外部サービス処理部１３４）候補を選択し、（Ｘ−Ｓ間、Ｙ−Ｓ間、Ｚ―Ｓ間）の３つの「ＱｏＳ保証パス設定要求」に変換した後、上記[ＱｏＳ保証パスの予約と設定の実施例説明]と同様の処理を実行する。全ての選択肢の中から、ＰＤＢ５１９の値、例えば、通過する通信ノード数が最小のケースを選択する、あるいは、使用する回線の帯域あるいはサービス処理部１３２または外部サービス処理部１３４の資源の利用率が平均化するケースを選択する、等の運用ポリシーに基づき、割当てるべき資源を決定する。
【００８７】予約資源登録機能５３１４は、割当て決定された（通信ノード１３の番号、転送処理部１３３の番号、開始時刻（Ｖ）、終了時刻（Ｗ）、帯域（Ｚ）、ＩＰパケット・フロー（Ｆ）識別情報）、（「多地点からの動画情報をミキシングして１つの共通動画情報に変換するデータ処理ソフトウェア（Ｓ）、（Ｓ）実行に必要なコンピューティング資源情報（通信ノード１３の番号、サービス処理部１３２または外部サービス処理部１３４の番号、割当てＣＰＵ性能値、割当てメモリ量等）」、）等の情報をＳＲＤＢに登録する。
【００８８】予約資源ディスパッチ機能５３４１は、ＳＲＤＢ５３１５をアクセスし、利用開始時刻になったネットワーク資源エレメントに対応する情報を入力し、通信ノード振分け機能５３４４に対応する通信ノード制御機能５５への送信を要求する。更に、ソフトウェアダウンロード機能５３４３に対し、「多地点からの動画情報をミキシングして１つの共通動画情報に変換するデータ処理ソフトウェア（Ｓ）、（Ｓ）実行に必要なコンピューティング資源情報（通信ノード１３の番号、サービス処理部１３２または外部サービス処理部１３４の番号、割当てＣＰＵ性能値、割当てメモリ量等）」等の情報を通知し、（Ｓ）のダウンロードを依頼する。
【００８９】ソフトウェアダウンロード機能５３４３は、ＳＤＢ６０３から（Ｓ）を入手し、通信ノード振分け機能５３４４に対し、「多地点からの動画情報をミキシングして１つの共通動画情報に変換するデータ処理ソフトウェア（Ｓ）、（Ｓ）実行に必要なコンピューティング資源情報（通信ノード１３の番号、サービス処理部１３２または外部サービス処理部１３４の番号、割当てＣＰＵ性能値、割当てメモリ量等）」からなる情報を通知し、該当通信ノードへの送信を要求する。通信ノード振分け機能５３４４は、予約資源ディスパッチ機能５３４１、およびソフトウェアダウンロード機能５３４３からの要求により、通信ノード制御機能の資源指示中継機能５５１４に対し、ＱｏＳ保証型多地点ビデオ会議サービスに必要な指示情報を送信する。
【００９０】同様に、予約資源ディスパッチ機能５３４１は、ＳＲＤＢ５３１５をアクセスし、利用終了時刻になったネットワーク資源エレメントに対応する情報を入力し、通信ノード振分け機能５３４４に対応する通信ノード制御機能５５への送信を要求すると通信ノード振分け機能５３４４は、通信ノード制御機能の資源指示中継機能５５１４に対し、ＱｏＳ保証パス解放、データ処理ソフトウェア（Ｓ）および（Ｓ）実行に必要なコンピューティング資源解放に必要な指示情報を送信する。通信ノード制御機能の資源指示中継機能５５１４は、該指示情報を資源指示実行機能５５２３に通知し、資源指示実行機能は、該指示に基づき必要なハードウェア等５５２４への設定を実行する。資源指示実行機能５５２３からサービス処理部１３２または外部サービス処理部１３４への（Ｓ）の転送は、既に説明した。
【００９１】以上、（Ｘ−Ｓ間、Ｙ−Ｓ間、Ｚ―Ｓ間）の３つの「ＱｏＳ保証パス設定要求」、「多地点からの動画情報をミキシングして１つの共通動画情報に変換するデータ処理ソフトウェア（Ｓ）」、「（Ｓ）実行に必要なコンピューティング資源（ＣＰＵ性能、メモリ量等）」、がネットワーク全体で確保・設定・起動され、または解放されることにより、「３個所のＥＳ１４（Ｘ、Ｙ、Ｚと表記）の間で、開始時刻（Ｖ）から終了時刻（Ｗ）までの間、ビデオ品質（Ｑ）のビデオ会議を開催する。主催者は（Ｘ）」といったサービスが動的に提供できるばかりでなく、この種の、通信とデータ処理の異なる種類の資源を必要とするサービス要求に対し、運用ポリシーに基づき、最適な資源管理（ＱｏＳ保証パスの確保、ビデオ会議支援機能の確保、等）を行うことが可能である。」
　
　摘記事項ヘ．には、ＱｏＳ保証型多地点ビデオ会議予約について記載されており、エンドシステム間でのビデオ会議に対するＱｏＳ保証を設定するものであるといえる。
　摘記事項ロ．、ハ．によれば、ネットワークシステムは、ＩＰパケットの経路制御を行う通信ノードを有するものである。
　
　引用例の上記記載及び技術常識からすると、引用例には、
「ネットワークシステムにおいて、エンドシステム間でのビデオ会議に対するＱｏＳ保証を設定することができることを設ける方法であって、該ネットワークシステムは該ネットワークシステムを通じてＩＰパケットの経路制御を行う通信ノードを有し、
　該ビデオ会議に対する予約を送信する工程であって、該予約は該ビデオ会議の開始時刻と終了時刻を特定するので、エンドシステムが、開始時間から終了時刻までの間、保証されたＱｏＳの該ビデオ会議に参加し得る工程を含む方法。」 
の発明（以下、「引用例発明」という。）が開示されていると認めることができる。
 　
 （３）対比  
　本願補正発明と引用例発明を対比する。
　引用例発明の「ネットワークシステム」、「エンドシステム」、「ビデオ会議」、「経路制御を行う通信ノード」は、本願補正発明の「ネットワーク」、「クライアント」、「セッション」、「ルーティング・エレメント」にそれぞれ相当する。
　引用例発明の「ＱｏＳ保証を設定する」ことは、本願補正発明の「サービス品質（ＱｏＳ）契約を設定する」ことに含まれており、引用例発明の「ＱｏＳ」は、本願補正発明の「サービス・レベル」に含まれるものであるといえる。
　引用例発明の「ＩＰパケットの経路制御を行う」ことは、本願補正発明の「情報を送る」ことに含まれている。
　引用例発明の「開始時刻と終了時刻を特定する」ことは、「時間帯を特定する」ことであるといえる。
　
　したがって、両者は、
「ネットワークにおいて、クライアント間でのセッションに対するサービス品質（ＱｏＳ）契約を設定することができることを設ける方法であって、該ネットワークは該ネットワークを通じて情報を送るルーティング・エレメントを有し、
　該セッションに対する予約を送信する工程であって、該予約は該セッションについての時間帯を特定するので、クライアントが、該特定時間帯中に、保証されたサービス・レベルの該セッションに参加し得る工程を含む方法。」
である点で一致し、以下の点で相違している。
　
［相違点］
　本願補正発明は、「前記セッションがいつ終了したかの通知を送信する工程」を含むのに対して、引用例発明は、そのような工程を含まない点。
　
（４）判断
　上記相違点について検討する。
　ネットワークを用いてセッションを行う場合に、セッションの終了を通知することは、例えば、特開平１０−３２６５２号公報の【００８０】〜【００８４】、特開平１１−２７２８３号公報の【００１０】〜【００１１】に示されるように、通信分野における周知事項であることを考慮すれば、引用例発明において、セッション（ビデオ会議）を終了する場合に、セッションがいつ終了したかの通知を送信するようにすることは、当業者が格別の困難無くなし得ることである。
　
　そして、本願補正発明の作用効果も、引用例発明及び周知事項から当業者が予測できる範囲のものである。
　したがって、本願補正発明は、引用例発明及び周知事項に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　平成２１年２月１２日付けの手続補正は上記のとおり却下されたので、本願の請求項２３に係る発明（以下、「本願発明」という。）は、平成２０年８月８日付けの手続補正書の特許請求の範囲の請求項２３に記載された事項により特定される、以下のとおりのものである。
 「ネットワークにおいて、クライアント間でのセッションに対するサービス品質（ＱｏＳ）契約を設定することができることを設ける方法であって、該ネットワークは該ネットワークを通じて情報を送るルーティング・エレメントを有し：
　該セッションに対する予約を送信することができることを設ける工程；
　を有し、該予約は該セッションについての時間帯を特定するので、クライアントが、該特定時間帯中に、保証されたサービス・レベルの該セッションに参加し得ることを特徴とする方法。」
　
（１）引用例
　原査定の拒絶の理由に引用された引用例、及びその記載事項は、前記「２．（２）」に記載したとおりである。
　
（２）対比・判断
　本願発明は、前記「２．（１）」で検討した本願補正発明において付加された限定を省いたものである。
　そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記「２．（４）」に記載したとおり、引用例発明及び周知事項に基づいて当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用例発明及び周知事項に基づいて、当業者が容易に発明をすることができたものである。
　
（３）むすび
　以上のとおり、本願発明は、引用例発明及び周知事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。