【事件の表示】
　特願２０００−　６０６７５「データ通信方法、ゲートウェイ、サービス処理装置、中継端末及びその通信プログラムを記録した記録媒体」拒絶査定不服審判事件〔平成１３年　９月１４日出願公開、特開２００１−２５１３４１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯
　本願は、平成１２年３月６日の出願であって、平成１７年２月２４日付けで拒絶査定がなされたところ、これに対して同年３月３１日に拒絶査定に対する審判請求がなされるとともに、同年４月２７日に手続補正書が提出されたものである。
　
２．補正却下の決定
　平成１７年４月２７日に提出された手続補正書による補正の却下の決定
　
（１）［補正却下の決定の結論］
　平成１７年４月２７日に提出された手続補正書による補正（以下、「本件補正」という。）を却下する。
　
（２）［補正却下の決定の理由］
（ａ）補正の内容
　本件補正によると、請求項２は、
「自己のサービス処理装置の能力を含むサービス処理能力情報を中継端末に通知し、
前記中継端末に、サービス処理装置の能力の情報を含む１又は複数のサービス処理能力情報を含むプロファイルをゲートウェイに通知させ、
前記ゲートウェイに、サーバからサービスを提供するために送信されたコンテンツを前記プロファイルに基づいて前記サービス処理装置の能力にあわせて加工させ前記中継端末に送信データとして送信させ、
前記中継端末にて、前記プロファイルに基づいて転送された前記送信データを受信することを特徴とするサービス処理装置。」
と補正されている。　
　
　上記補正は、本件補正前の請求項２に記載した発明を特定するために必要な事項である「前記ゲートウェイに、サーバからサービスを提供するために送信されたコンテンツを前記プロファイルに基づいて加工させ」に対し、「前記ゲートウェイに、サーバからサービスを提供するために送信されたコンテンツを前記プロファイルに基づいて前記サービス処理装置の能力にあわせて加工させ」と限定するものであり、本件補正は、特許法第１７条の２第４項第２号に規定する特許請求の範囲の減縮を目的とするものに該当するといえる。
　そこで、本件補正後の前記請求項２に記載された発明（以下、「本願補正発明」という。）が、特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）否かについて以下検討する。
　
（ｂ）引用例
　原査定の拒絶の理由に引用された特開平１１−１３６３９４号公報（以下、「引用例」という。）には、図とともに、以下のような記載がある。
　
（ア）「【００１７】 本実施形態のシステムでは、ネットワーク３に接続された端末からデータベース１の検索を依頼する際、検索結果の送出先の端末装置の性能および機能をサーバ２に通知する。サーバ２は、必要に応じて、その検索結果の送出先端末の性能や機能に従ってその検索結果を他の形態に変換したりあるいは編集し、その検索結果、変換された検索結果、あるいは編集された検索結果をネットワーク３に送出する。このような処理により、検索結果を受信した端末では、その検索結果を確実に出力できる。
【００１８】 また、本実施形態のシステムでは、ネットワーク３に接続された端末からデータベース１の検索を依頼する際、どのような形態でデータを転送してほしいのかをサーバ２に通知する。サーバ２は、この要求に応じて、データベースから取り出した検索結果を他形態に変換したりあるいは編集した後にそれをネットワーク３へ送出する。
【００１９】 図２(a) は、ＰＣ４またはＰＤＡ５からデータベース１の検索を依頼する際のＰＣ４またはＰＤＡ５における処理を示すフローチャートである。ここでは、検索結果を依頼元の端末に返送する場合を示す。
【００２０】 ステップＳ１において、ユーザからデータベース検索依頼が入力されると、ステップＳ２においてサーバ２との間にコネクションを確立する。 ステップＳ３では、ステップＳ２で確立したコネクションを介して、自端末の性能および自端末が備える機能をサーバ２に通知する。ここで、自端末の性能としては、画像表示機能を持っているか否か、テキスト表示機能を持っているか否か、音声再生機能を持っているか否か、データ受信用のキャパシティ等を通知する。また、自端末が備える機能としては、画像データの圧縮・解凍プログラムの種類、文書作成アプリケーションの種類などを通知する。これらの情報は、自端末が備えるメモリ内の所定領域に予め格納しておき、ステップＳ３において、その情報を取り出してサーバ２に通知する。なお、各端末の性能は、後述説明するが、端末識別コードとして表され、各端末が備える機能は、プログラム番号として表される。なお、端末に画像圧縮・解凍処理や文書作成のためのプログラムが複数インストールされている場合には、複数のプログラム番号が通知される。これらの端末識別コードおよびプログラム番号は、サーバ２にデータベース検索を依頼する全ての端末装置に対して共通に定義されて使用されるものである。
【００２１】 図２(b) は、自端末の能力等をサーバ２に通知するためのパケットの構成図である。パケットは、ヘッダ部およびデータ部から構成される。ヘッダ部は、送信元アドレスおよび着信先アドレスなどを格納する。送信元アドレスおよび着信先アドレスとしてどのようなアドレス体系のアドレスを格納するのかは、本実施形態が適用されるネットワーク構成によって決まり、たとえば、TCP/IP通信では、ＩＰアドレスが格納される。
【００２２】 データ部には、コマンド、端末ＩＤ、端末識別コード、およびプログラム番号等が格納される。コマンドは、着信先の端末（ここでは、サーバ２）において実行する処理を指定する。端末ＩＤは、自端末（検索依頼元）の識別番号である。端末識別コードおよびプログラム番号は、上述したように、それぞれ自端末の性能および自端末が備える機能を表示する。」（段落【００１７】〜【００２２】）
　
（イ）「【００３１】 アクセス端末メモリ２２は、図２および図３を参照しながら説明した端末識別コードおよびプログラム番号と、端末の性能および機能を互いに対応づけて格納する。図７(a) は、アクセス端末メモリ２２に設けられる識別コードテーブルの構成図である。識別コードテーブルは、各端末識別コードと端末の性能とを対応づけて格納したテーブルである。たとえば、端末識別コードが「１０１」である端末は、パーソナルコンピュータであり、画像表示機能、音声再生機能、テキスト表示機能を有し、さらにそのデータ受信用のキャパシティが２ＭＢであることが示されている。図７(b) は、アクセス端末メモリ２２に設けられるプログラムテーブルの構成図である。プログラムテーブルは、各プログラム番号と端末上で起動可能なプログラム（通常、その端末にインストールされているプログラム）とを対応づけて格納したテーブルである。
【００３２】 なお、図７に示す端末識別コードおよびプログラム番号は、図２または図３を参照しながら説明した端末識別コードおよびプログラム番号に対応する。すなわち、各端末（ＰＣ４またはＰＤＡ５）は、図７に示す識別コードテーブルおよびプログラムテーブルに設定されている対応関係を認識している。そして、各端末は、自端末の性能および自端末にインストールされているプログラムを認識しているので、図２のステップＳ３（または、図３のステップＳ１１）において、自端末の性能および機能を端末識別コードおよびプログラム番号を用いてサーバ２に通知する。したがって、サーバ２は、各端末から端末識別コードおよびプログラム番号を受信すると、アクセス端末メモリ２２を参照することにより、その端末の性能および機能を認識できる。
【００３３】 制御部２３は、入出力部２１を介して入力される検索依頼を解析し、データベース１にアクセスして検索結果を得る。また、制御部２３は、図８に示すデータ属性メモリ２４を参照し、検索結果としてデータベース１から取り出したデータの属性を検出する。データ属性とは、データベース１において、各データが画像データとして格納されているのか、音声データとして格納されているのか、あるいはテキストデータとして格納されているのかを表す。尚、図９に示すように、画像データとその画像データに関連するテキストデータとが１組になって格納されている場合は、データ属性は「画像＋テキスト」になる。
【００３４】 さらに、制御部２３は、必要に応じて、テキストデータ作成部２５、テキスト−音声作成部２６、および方式変換部２７との連携動作により、検索結果をその送出先の端末において出力可能なように、検索結果としてデータベース１から取り出したデータに対して所定の処理を施す。」（段落【００３１】〜【００３４】）
　
（ウ）「【００３８】 次に、サーバ２が検索依頼を受信してから検索結果を出力するまでの動作を説明する。
  図１０は、入出力部２１の動作を説明するフローチャートである。このフローチャートは、ユーザがＰＣ４、ＰＤＡ５または電話機６を使用してサーバ２に検索依頼を発行し、その依頼を受信した後の入出力部２１の動作を示す。
【００３９】 ステップＳ２１では、ネットワーク３からのアクセスがデータ用ポート３１を介して入力されたのか、電話用ポート３２を介して入力されたのかを判断する。データ用ポート３１からの入力であれば、ユーザがＰＣ４またはＰＤＡ５を使用して検索依頼を発行したものと見なしてステップＳ２２へ進み、電話用ポート３２からの入力であれば、ユーザが電話機６を使用して検索依頼を発行したものと見なしてステップＳ３１へ進む。
【００４０】 ステップＳ２２では、受信したパケットから検索結果を送出する先の端末を識別する情報を検出して保持しておく。すなわち、図２に示す場合であれば、データ部に格納されている「端末ＩＤ」を保持し、図３に示す場合であれば、「送出先端末のＩＤ」を保持する。
【００４１】 ステップＳ２３では、受信したパケットから「端末識別コード」および「プログラム番号」を抽出する。すなわち、図２のステップＳ３または図３のステップＳ１１において、ＰＣ４またはＰＤＡ５からサーバ２へ検索結果を送出する先の端末の端末識別コードおよびプログラム番号が通知されるので、サーバ２は、この通知に関する情報を格納したパケットから端末識別コードおよびプログラム番号を抽出する。
【００４２】 ステップＳ２４では、アクセス端末メモリ２２を参照して検索結果を送出する先の端末の能力情報を検出する。すなわち、抽出した端末識別コードをキーとして図７(a) に示す識別コードテーブルにアクセスして検索結果の送出先端末の性能を認識し、また、抽出したプログラム番号をキーとして図７(b) に示すプログラムテーブルにアクセスして検索結果の送出先端末にインストールされているプログラムを認識する。
【００４３】 ステップＳ２５では、ネットワーク３から受信した検索依頼とともに、ステップＳ２４で検出した送出先端末の能力情報を制御部２３へ転送する。以降、入出力制御部２１は、制御部２３から検索結果が転送されてくるのを待つ。」（段落【００３８】〜【００４３】）
　
（エ）「【００４９】 ステップＳ５４では、検索結果が画像データを含んでいるか否かを判断し、画像データを含んでいれば、ステップＳ５５において、検索結果の送出先の端末が画像データを表示できるか否かを判断する。なお、画像データは、所定の圧縮方式で圧縮されてデータベース１に格納されているものとする。検索結果の送出先端末が画像データを表示できる場合には、ステップＳ５６において、検索結果の送出先の端末の能力に応じてその画像データを編集する。たとえば、検索結果の送出先端末の画像表示能力が低ければ画素データを間引きする。あるいは、カラー表示機能を有していない場合には、色情報などを除去する。続いて、ステップＳ５７へ進み、画像データをその送出先端末において処理可能（解凍できる）かどうか調べる。処理可能であれば、ステップＳ５８においてその画像データを検索結果として入出力部２１に転送する。
【００５０】 検索結果の送出先の端末において画像データを処理できないと判断された場合には（ステップＳ５７：Ｎｏ）、ステップＳ５９において、データベース１から抽出した画像データを検索結果の送出先端末において処理可能は方式に変換（再圧縮）する。ステップＳ５９の処理は、方式変換部２７によって実行される。なお、転送先端末が画像圧縮・解凍機能を持っていないときには、解凍した状態の画像データを検索結果として入出力部２１に転送する。」（段落【００４９】、【００５０】）
　
（オ）「【００６８】 さらに、上記実施例では、サーバにデータ送出を依頼するごとにデータ送出先の端末の性能および機能をサーバに通知しているが、データ送出先の端末の性能および機能を予めサーバ側に登録しておき、サーバからデータを出力する際にその登録されている情報に従ってデータを変換・編集等して出力するようにしてもよい。
【００６９】 図１４は、本発明の他の実施形態のシステムの構成図である。この実施形態のシステムでは、ＰＣ（パーソナルコンピュータ等）４、ＰＤＡ（携帯型情報処理装置）５、または電話機（移動体電話機を含む）６などからの検索依頼に基づいて、サーバ４０が、情報公開網として、たとえば、ＷＷＷ（World Wide Web）５０から情報を取得し、その取得した情報を所定の端末（基本的には、検索依頼を出力した端末）へ送出する。このとき、サーバ４０は、必要に応じて、ＷＷＷ５０から得た情報をその送信先の端末において出力できるようなデータを変換したり、その情報に基づいてその送信先の端末において出力できるようなデータを生成したり、或いはそのデータ量を削減したりする。このデータ変換等の処理は、基本的には、図１〜図１３を参照しながら説明した通りである。
【００７０】 サーバ４０は、例えば、商用インターネット接続サービス事業者（以下、「プロバイダ」と呼ぶ）が有するコンピュータであり、多数の加入者を収容する。ＷＷＷ５０においては、クライアントとサーバとの通信プロトコルとして、基本的にＨＴＴＰ（Hypertext Transfer Protocol ）が用いられる。また、情報は、一般に、ＨＴＭＬ（Hyper Text Markup Language）により記述される。但し、３次元グラフィクスを表現できるＶＲＭＬ（Virtual Reality Modeling Language ）がＨＴＭＬと併用されることもある。そして、リンク先のデータのアドレス指定には、ＵＲＬ（Uniform Resource Locator）という表記法が用いられる。
【００７１】 ＷＷＷ５０には、不図示のサーチエンジンが設けられている。サーチエンジンは、検索エンジンとも呼ばれ、世界中に分散しているＷＷＷホームページの中から、与えられたキーワードに合致するものを検索する。そして、サーチエンジンは、収集したホームページのタイトルおよびそのホームページのＵＲＬをリストアップする。なお、ＷＷＷホームページは、サイトと呼ばれることがある。」（段落【００６８】〜【００７１】）　　
　
（カ）「【００８０】 なお、さらに他の実施形態として、送信してほしい情報のカテゴリーをユーザ毎にプロバイダ（サービス網）に登録しておき、ユーザが必要な情報のみを閲覧できるようなシステムを構築することも可能である。この場合も、各ユーザ端末の性能および機能がプロバイダに登録されている。そして、プロバイダはユーザ毎に登録されているカテゴリーに属する情報を登録されている性能および機能に適合するデータ形態で送出する。このようなシステムは、たとえば、プッシュ型サービスにおいて有用と考えられる。」（段落【００８０】）
　
　以上の記載によれば、この引用例には以下のような発明（以下、「引用例発明」という。）が開示されていると認められる。
　
「ユーザ端末の性能およびユーザ端末が備える機能をサーバ４０（プロバイダが有するコンピュータ）に通知し、
　前記サーバ４０において、各端末識別コードおよびプログラム番号と、端末の性能（画像表示機能を持っているか否か、テキスト表示機能を持っているか否か、音声再生機能を持っているか否か、データ受信用のキャパシティ等）および機能（画像データの圧縮・解凍プログラム、文書作成アプリケーション等）を互いに対応づけてアクセス端末メモリ２２に格納させ、
　前記サーバ４０は、ＷＷＷ５０に設けられているサーチエンジンからデータを取得し、前記アクセス端末メモリ２２に格納された送信先の端末の性能および機能にあわせてデータを変換・編集して送信先ユーザ端末に送信し、送信されたデータを受信するユーザ端末。」　
　
（ｃ）対　比
　本願補正発明と引用例発明とを対比する。
　引用例発明の「ユーザ端末」は、本願補正発明の「サービス処理装置」に相当し、引用例発明のサーバ４０に通知する「ユーザ端末の性能およびユーザ端末が備える機能」は本願補正発明の「自己のサービス処理装置の能力を含むサービス処理能力情報」に相当する。
　引用例発明の「サーバ４０（プロバイダが有するコンピュータ）」は、ＷＷＷ５０に設けられているサーチエンジンからデータを取得し、送信先端末に送信するから、本願補正発明の「ゲートウェイ」とは、「外部ネットワークの出入り口で処理を行うコンピュータ」である点で一致する。
　そして、引用例発明における、サーバ４０のアクセス端末メモリ２２に格納された各端末識別コードおよびプログラム番号と、端末の性能（画像表示機能を持っているか否か、テキスト表示機能を持っているか否か、音声再生機能を持っているか否か、データ受信用のキャパシティ等）および機能（画像データの圧縮・解凍プログラム、文書作成アプリケーション等）を互いに対応づけた内容は、本願補正発明の「サービス処理装置の能力の情報を含む１又は複数のサービス処理能力情報を含むプロファイル」に相当するといえる。
　そして、引用例発明の「サーバ４０は、ＷＷＷ５０に設けられているサーチエンジンからデータを取得し、前記アクセス端末メモリ２２に格納された送信先の端末の性能および機能にあわせてデータを変換・編集して送信先端末に送信させる」は、「ＷＷＷ５０に設けられているサーチエンジン」は「サーバ」といえ、取得した「データ」が「サーバからサービスを提供するために送信されたコンテンツ」といえるから、本願補正発明の「ゲートウェイに、サーバからサービスを提供するために送信されたコンテンツを前記プロファイルに基づいて前記サービス処理装置の能力にあわせて加工させ前記中継端末に送信データとして送信させ、前記中継端末にて、前記プロファイルに基づいて転送された前記送信データを受信する」と、「外部ネットワークの出入り口で処理を行うコンピュータに、サーバからサービスを提供するために送信されたコンテンツをサービス処理装置の能力の情報を含む１又は複数のサービス処理能力情報を含むプロファイルに基づいて前記サービス処理装置の能力にあわせて加工させ端末に送信データとして送信させ、前記端末にて、前記プロファイルに基づいて転送された前記送信データを受信する」する点で対応する。
　　
　そうすると、両者は、
「自己のサービス処理装置の能力を含むサービス処理能力情報を通知し、
外部ネットワークの出入り口で処理を行うコンピュータに、サーバからサービスを提供するために送信されたコンテンツを前記サービス処理装置の能力の情報を含む１又は複数のサービス処理能力情報を含むプロファイルに基づいて前記サービス処理装置の能力にあわせて加工させ端末に送信データとして送信させ、
前記端末にて、前記プロファイルに基づいて転送された前記送信データを受信することを特徴とするサービス処理装置。」
で一致するものであり、次の（１）、（２）の点で相違している。
　
（１）本願補正発明では、コンテンツをプロファイルに基づいて前記サービス処理装置の能力に合わせて加工させ端末に送信データとして送信するコンピュータが「ゲートウェイ」であるのに対し、引用例発明では「サーバ４０（プロバイダが有するコンピュータ）」である点。
　
（２）本願補正発明では、自己のサービス処理装置の能力を含むサービス処理能力情報を「中継端末」に通知し、「中継端末」にサービス処理装置の能力の情報を含む１又は複数のサービス処理能力情報を含むプロファイルを通知させるものであって、ゲートウェイが加工されたコンテンツを「中継端末」に送信データとして送信し、「中継端末」にて前記送信データを受信するのに対し、引用例発明は「ユーザ端末」がサービス処理能力情報を外部ネットワークの出入り口で処理を行うコンピュータに通知し、「ユーザ端末」に送信データが送信されるものであって、外部ネットワークの出入り口で処理を行うコンピュータにサービス処理能力情報を含むプロファイルを通知し、送信データを受信する「中継端末」は設けていない点。
　
（ｄ）当審の判断
・相違点（１）について
　ゲートウェイとは、ネットワーク間の接続を中継する機器、またはソフトウェアであって、ネットワークの出入り口で、何らかの処理を行うコンピュータもゲートウェイである。
　したがって、引用例発明の「サーバ４０（プロバイダが有するコンピュータ）」も「ゲートウェイ」ということができるから、この点は実質的な相違点ではない。
　
・相違点（２）について
　ネットワークにつながる各種機器や複数の端末についての情報を収集して格納し、該収集した情報を外部に通知する中継装置を設けることことは、本出願前周知の技術（特開平１１−１８７０６１号公報（ホームオートメーション網１２に接続されたＰＣ１０、第２のＡＶ接続装置、第１のＡＶ接続装置に関する記載参照）、特開平１１−２５２１５４号公報（ハブ装置Ｈ１〜Ｈ３、識別情報管理装置２に関する記載参照））である。
　そうすると、引用例発明に上記周知技術を適用し、ユーザ端末の能力を含むサービス処理能力情報を通知し、前記サービス処理装置の能力の情報を含む１又は複数のサービス処理能力情報を含むプロファイルを「サーバ４０（プロバイダが有するコンピュータ）」に通知するような「中継端末」を設けることは当業者が容易になし得ることである。
　そして、上記中継端末を設けることにより、「サーバ４０（プロバイダが有するコンピュータ）」が加工されたコンテンツを前記プロファイルに基づいて「中継端末」に送信データとして送信し、「中継端末」にて前記送信データを受信することになるのは明らかである。
　
　また、前記相違点により奏される効果は当業者であれば引用例発明及び周知技術から予想できる範囲内のものである。
　
（ｅ）結論
　そうすると、本願補正発明は、引用例発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
 したがって、本件補正は、特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合しないから、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下すべきものである。　
　
３．本願発明
　上記のとおり、上記本件補正は却下されたので、本願請求項２に係る発明（以下、「本願発明」という。）は、平成１６年８月２３日に提出された手続補正書における特許請求の範囲の請求項２に記載された事項により特定される、以下のとおりのものである。
　
「自己のサービス処理装置の能力を含むサービス処理能力情報を中継端末に通知し、
前記中継端末に、サービス処理装置の能力の情報を含む１又は複数のサービス処理能力情報を含むプロファイルをゲートウェイに通知させ、
前記ゲートウェイに、サーバからサービスを提供するために送信されたコンテンツを前記プロファイルに基づいて加工させ前記中継端末に送信データとして送信させ、
前記中継端末にて、前記プロファイルに基づいて転送された前記送信データを受信することを特徴とするサービス処理装置。」
　
４．引用例
　原査定の拒絶理由に引用された引用刊行物、及びその記載事項は、前記「２．（２）（ｂ）」に記載したとおりである。
　
５．対比・判断
　本願発明は、前記２．で検討した本願補正発明の「前記ゲートウェイに、サーバからサービスを提供するために送信されたコンテンツを前記プロファイルに基づいて前記サービス処理装置の能力にあわせて加工させ」から「前記サービス処理装置の能力にあわせて」という限定を省き、「前記ゲートウェイに、サーバからサービスを提供するために送信されたコンテンツを前記プロファイルに基づいて加工させ」とするものである。
　そうすると、本願発明の構成要件を全て含み、さらに限定したものに相当する本願補正発明が前記２．に記載したとおり、引用例発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用例発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
６．むすび
　以上のとおり、本願請求項２に係る発明は、引用例発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。
　よって、結論のとおり審決する。