【事件の表示】
　特願２００８−　９０４２４「コンピュータ装置、コンピュータ装置の拡張カード、負荷分散方法及びプログラム」拒絶査定不服審判事件〔平成２１年１０月２２日出願公開、特開２００９−２４５１３１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　
　本件審判請求に係る出願（以下、「本願」という。）は、平成２０年３月３１日の出願であって、平成２３年１月２１日付けで手続補正がなされ、同年２月２日付けで審査請求がなされ、平成２４年７月１７日付けで拒絶理由通知（同年７月１９日発送）がなされ、同年９月１８日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、平成２５年３月１４日付けで拒絶査定（同年３月１８日謄本送達）がなされたものである。
　これに対して、「原査定を取り消す。本願は特許をすべきものであるとの審決を求める。」ことを請求の趣旨として、平成２５年６月１８日付けで本件審判請求がなされるとともに、同日付けで手続補正がなされたものである。
　そして、平成２５年９月２７日付けで審査官により特許法第１６４条第３項に定める報告（前置報告）がなされ、同年１１月２８日付けで当審により特許法第１３４条第４項の規定に基づく審尋（同年１２月３日発送）がなされ、平成２６年１月２９日付けで回答書の提出がなされたが、同年７月９日付けで当審により前記平成２５年６月１８日付け手続補正を却下する旨の補正の却下の決定（同年７月２２日発送）がなされるとともに、同日付けで拒絶理由通知（同年７月１５日発送）がなされ、同年９月１２日付けで意見書が提出されるとともに、同日付けで手続補正がなされたものである。
　
２．本願発明
　
　本願の特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、上記平成２６年９月１２日付け手続補正書により補正された特許請求の範囲及び明細書の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
「ＰＣＩバス規格に準拠したＰＣＩバスを備えるコンピュータ装置のＩ／Ｏインタフェースに装着され、前記Ｉ／Ｏインタフェースを介して前記ＰＣＩバスと接続された拡張カードであって、
　ネットワークを介してクライアント、サーバ間でフレームの送受信を行うネットワークインタフェース部と、
　前記コンピュータ装置のプロセッサに負荷をかけることなく、前記サーバの負荷分散を行うプロセス処理部とを備え、
　前記プロセス処理部が、
　アドレスのフィルタリングを行い、自分宛のアドレスのフレームを受信するアドレスフィルタ部と、
　受信したフレームのデータフローと前記受信したフレームから抽出されたセッション毎のポート番号の識別子に基づいて、前記セッションの識別情報と前記ポート番号とを組み合わせてポート番号テーブルに登録するフレーム抽出部と、
　負荷分散の対象となるサーバのサービス中のセッション数に基づいて、前記対象となるサーバから、前記フレームの宛先となるサーバを選択する宛先判定処理部と、
　前記宛先判定処理部で選択したサーバのアドレスを、受信したフレームの宛先に付与して、ネットワークインタフェース部を介して接続先へ転送するアドレス付与部とを備える
　ことを特徴とする拡張カード。」
　
３．平成２６年７月９日付け拒絶理由の概要
　
　平成２６年７月９日付けで通知した拒絶の理由は、
　
　本願請求項１ないし１５に係る発明は、本願の出願前に頒布された、特開２００３−１７４４７３号公報、特開２００２−３５１７６０号公報、特開２００４−２９５６５６号公報、及び特開２００８−４０７１８号公報に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない、
　
というものを含むものである。
　
４．引用文献に記載されている技術的事項及び引用発明の認定
　
（１）引用文献１
　
　本願の出願前に頒布され、当審による上記平成２６年７月９日付け拒絶理由通知において引用された刊行物である、特開２００３−１７４４７３号公報（平成１５年６月２０日出願公開。以下、「引用文献１」という。）には、図面とともに、以下の技術的事項が記載されている。
（当審注：下線は、参考のために当審で付与したものである。）
　
Ａ　「【００２６】〔サーバ負荷分散システムの構成〕
図３及び図４は、本発明の一実施の形態におけるサーバ負荷分散システム１の構成
【００２７】図３及び図４を併せ参照すると、
このサーバ負荷分散システム１は、インターネットまたはイントラネットなどのＩＰネットワーク２に接続されたパーソナルコンピータなどの複数のクライアント端末３
ルータ４に接続された複数のサーバロードバランサ
ルータ４にＬＡＮ（Local Area Network）６を通して接続された負荷分散対象サーバ群としての複数のサーバ
とを備えている
　
Ｂ　「【００４９】〔サーバロードバランサ〕図３及び図４に示すサーバ負荷分散システム１において、各サーバロードバランサ５は、図８及び図９に示す詳細構成を採る。
【００５０】
サーバロードバランサ５は
サーバロードバランシング処理部５１、パケット受信部５５、パケット送信部５６
から構成されている。サーバロードバランシング処理部５１は
アドレス書換え部５３を有する。アドレス書換え部５３はセッション・テーブル５４を有する
【００５１】
サーバロードバランシング処理部５１は
宛先サーバ選択処理部５２により宛先サーバ７を決定させ、アドレス書換え部５３により転送対象パケットの宛先ＩＰアドレスを書き換えさせる
　
Ｃ　「【００５２】宛先サーバ選択処理部５２による宛先サーバ７の決定方法には、（１）ＯＳＩ参照モデルのトランスポート層以上のプロトコル（ＰＯＰ，ＳＭＴＰ，ＦＴＰ，ＨＴＴＰなど）の種別による負荷分散（Ｌ４ロードバランス）と、（２）ＯＳＩ参照モデルのアプリケーション層の情報（レスポンスタイムまたはＵＲＬなどのＬ７情報）による負荷分散（Ｌ７ロードバランス）とが基本的にある。
【００５３】また、
宛先サーバ選択処理部５２は、宛先サーバ７の決定方法として、複数のサーバ７の負荷を計測し、負荷の少ない１つを選択する方法
複数のサーバ７の１つを選択する方法
最小コネクション数
　
Ｄ　「【００５８】行きのパケットに対するサーバロードバランシング処理には、（１）宛先サーバ選択処理部５２により、そのパケットの宛先、つまり負荷分散対象サーバ７のＩＰアドレス及び負荷分散対象サーバ７のポート番号を決定する処理（Ｓ１０２）と、（２）
アドレス書換え部５３により、転送対象パケットの宛先ＩＰアドレスを決定済サーバ７のＩＰアドレスに書き換えるとともにポート番号を決定値に書き換える処理
　
Ｅ　「【０１２０】
〔変形例〕
実際にサーバロードバランサ５を構成する場合、例えば各サーバロードバランサ５の機能を複数枚のＮＩＣ（Network Interface Card）の個々に実装し、同一の装置筐体内に複数枚のＮＩＣを収容することが可能である
　
　ここで、上記引用文献１に記載されている事項を検討する。
　
（ア）上記Ａの「図３及び図４は、本発明の一実施の形態におけるサーバ負荷分散システム１の構成・・・このサーバ負荷分散システム１は、インターネットまたはイントラネットなどのＩＰネットワーク２に接続されたパーソナルコンピータなどの複数のクライアント端末３・・・ルータ４に接続された複数のサーバロードバランサ・・・ルータ４にＬＡＮ（Local Area Network）６を通して接続された負荷分散対象サーバ群としての複数のサーバ・・・とを備えている」との記載、上記Ｂの「サーバロードバランサ５は・・・サーバロードバランシング処理部５１、パケット受信部５５、パケット送信部５６・・・から構成されている。サーバロードバランシング処理部５１は・・・アドレス書換え部５３を有する。アドレス書換え部５３はセッション・テーブル５４を有する」との記載からすると、引用文献１の「サーバロードバランサ」が、
“ネットワークを介してクライアント装置、サーバ間でパケットの送受信を行うパケット受信部とパケット送信部と、
　セッション・テーブルを有するサーバロードバランシング処理部”
を備える態様が記載されている。
　
（イ）上記Ｂの「サーバロードバランシング処理部５１は・・・宛先サーバ選択処理部５２により宛先サーバ７を決定させ、アドレス書換え部５３により転送対象パケットの宛先ＩＰアドレスを書き換えさせる」との記載、上記Ｃの「宛先サーバ選択処理部５２は、宛先サーバ７の決定方法として、複数のサーバ７の負荷を計測し、負荷の少ない１つを選択する方法」との記載、上記Ｄの「アドレス書換え部５３により、転送対象パケットの宛先ＩＰアドレスを決定済サーバ７のＩＰアドレスに書き換えるとともにポート番号を決定値に書き換える処理」との記載からすると、引用文献１の「サーバロードバランシング処理部」が、
“複数の宛先サーバの負荷を計測し、負荷の少ない宛先サーバを選択する宛先サーバ選択処理部と、
　転送対象パケットの宛先ＩＰアドレスを選択した宛先サーバのＩＰアドレスに書き換えるアドレス書換え部”
を備える態様が記載されている。
　
　以上、（ア）及び（イ）で指摘した事項を踏まえると、引用文献１には、次の発明（以下、「引用発明」という。）が記載されているものと認められる。
　
「サーバロードバランサであって、
　ネットワークを介してクライアント装置、サーバ間でパケットの送受信を行うパケット受信部とパケット送信部と、
　セッション・テーブルを有するサーバロードバランシング処理部とを備え、
　前記サーバロードバランシング処理部が、
　複数の宛先サーバの負荷を計測し、負荷の少ない宛先サーバを選択する宛先サーバ選択処理部と、
　転送対象パケットの宛先ＩＰアドレスを選択した宛先サーバのＩＰアドレスに書き換えるアドレス書換え部とを備える
　ことを特徴とするサーバロードバランサ。」
　
（２）引用文献２
　
　本願の出願前に頒布され、当審による上記平成２６年７月９日付け拒絶理由通知において引用された刊行物である、特開２００２−３５１７６０号公報（平成１４年１２月６日出願公開。以下、「引用文献２」という。）には、図面とともに、以下の技術的事項が記載されている。
（当審注：下線は、参考のために当審で付与したものである。）
　
Ｆ　「【００３６】セッション管理テーブル３は、セッションに関する情報をセッションごとに管理するためのデータファイルであり、１セッションに対するセッション管理テーブルを１レコードとしたデータベース形式のセッション管理ファイルとしてハードディスク等の記憶媒体に格納されている。
図２は、実施の形態１のサーバ負荷分散装置におけるセッション管理テーブル３に登録される内容を示すデータ構造図
セッション管理テーブル３に登録される項目は、セッションＩＤ、セッション識別情報、セッション属性に大別され
セッション属性は
ポートＩＤなどから構成される
　
５．参考文献に記載されている技術的事項
　
（１）参考文献１
　
　本願の出願前に頒布された刊行物である、特開２００８−２１００６号公報（平成２０年１月３１日出願公開、以下、「参考文献１」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
（当審注：下線は、参考のために当審で付与したものである。）
　
Ｇ　「【００２３】
　デバイス状態変化検知部５６は、プリンタエンジン部５５の状態を監視する。そして、デバイス状態変化検知部５６は、プリンタエンジン部５５の状態に応じて、システムバス５４、
ＰＣＩバス５７を介して、ネットワーク・インタフェース・カード（ＮＩＣ）５８に
情報を通知する
　
（２）参考文献２
　
　本願の出願前に頒布された刊行物である、特開２００７−７６３３４号公報（平成１９年３月２９日出願公開、以下、「参考文献２」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
（当審注：下線は、参考のために当審で付与したものである。）
　
Ｈ　「【００２６】
　ＮＢ１０５の
ＰＣＩバス９ａに
ネットワーク通信を制御するＮＩＣ１０９
が接続される
　
（３）参考文献３
　
　本願の出願前に頒布された刊行物である、特開２００７−９６９０９号公報（平成１９年４月１２日出願公開、以下、「参考文献３」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
（当審注：下線は、参考のために当審で付与したものである。）
　
Ｊ　「【００３３】
　また、
ノードN1-N2間で交換される制御フレームのフォーマットを図2に示す
このフレームの名フィールドの内容は次のとおり
【００３４】
(a) UDP/IPヘッダ：既存のいわゆるTCP/IPのヘッダ
(b) フレーム種別(接続要求/接続回答):フレームが、『接続要求』か、『接続回答』か、を示すフィールド
(c) 接続OK/NGフラグ：通信先のノードが、通信元との通信を行うか、拒否するかを示すフラグ
【００３５】
(d) 
NAPT装置のIPアドレス
(e) 
NAPT装置のポート番号
(f) 
通信元ノードID
【００３６】
(g) 
通信元LAN(ローカル)ポート番号
(h) 
通信先ノードID
(i) 
通信先LANポート番号
　
Ｋ　「【００４５】
ステップS6:
　ノードN2は、上記のステップS3の処理終了後、
受信した
フレーム中のNAPT装置AC1のグローバルIPアドレス網NW2側のIPアドレスとポート番号（100.101.102.10:7800）を抽出
これによりNAPT装置AC2は、ノードN2のIPアドレス及びポート番号（192.168.20.2:300）と、NAPT装置AC1のグローバルIPアドレス網NW2側のIPアドレス及びポート番号とをバインド（関連付け）する
　
（４）参考文献４
　
　本願の出願前に頒布された刊行物である、特開２０００−１３２５２４号公報（平成１２年５月１２日出願公開、以下、「参考文献４」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
（当審注：下線は、参考のために当審で付与したものである。）
　
Ｌ　「【００５８】図５（Ａ）の
クライアントから受信したクライアントパケット６４は
送信元情報と宛先情報が格納されている
この送信元情報及び宛先情報は、それぞれのアドレスと割り当てられたポート番号で構成される
・・・（中略）・・・
【００６６】図６（Ａ）は、図４の接続情報テーブル４０の説明図である。
接続情報テーブル４０は、クライアント領域４０−１、転送元領域４０−２及びサーバ領域４０−３を備えており、それぞれアドレスとポート番号を格納する
　
６．対比
　
　本願発明と引用発明とを対比する。
　
（１）引用発明の「拡張カード」と本願発明の「サーバロードバランサ」とは、“サーバ負荷分散装置”である点で共通する。
　
（２）引用発明の「パケット」と本願発明の「フレーム」とは、“プロトコル・データ・ユニット”と呼ばれるデータの単位である点で共通することは、当業者にとって自明の事項である。
　
（３）引用発明の「パケット受信部とパケット送信部」は、本願発明の「ネットワークインタフェース部」に相当する。
　
（４）引用発明の「サーバロードバランシング処理部」は、サーバの負荷分散を行うものであることから、本願発明の「プロセス処理部」に相当する。
　
（５）引用発明の「宛先サーバ選択処理部」は、本願発明の「宛先判定処理部」に対応する。
　そうすると、引用発明の「複数の宛先サーバの負荷を計測し、負荷の少ない宛先サーバを選択する宛先サーバ選択処理部」と、本願発明の「負荷分散の対象となるサーバのサービス中のセッション数に基づいて、前記対象となるサーバから、前記フレームの宛先となるサーバを選択する宛先判定処理部」とは、“前記対象となるサーバから、前記プロトコル・データ・ユニットの宛先となるサーバを選択する宛先判定処理部”である点で共通する。
　
（６）引用発明の「アドレス書換え部」は、本願発明の「アドレス付与部」に対応する。
　また、引用発明の「アドレス書換え部」は、宛先サーバ選択処理部で選択したサーバのアドレスを、受信したパケットの宛先に付与して、パケット送信部を介して接続先へ転送しているといえるものである。
　してみると、引用発明の「転送対象パケットの宛先ＩＰアドレスを選択した宛先サーバのＩＰアドレスに書き換えるアドレス書換え部」は、本願発明の「前記宛先判定処理部で選択したサーバのアドレスを、受信したフレームの宛先に付与して、ネットワークインタフェース部を介して接続先へ転送するアドレス付与部」に相当するといえる。
　
　以上から、本願発明と引用発明とは、以下の点で一致し、また、以下の点で相違する。
　
（一致点）
　
「サーバ負荷分散装置であって、
　ネットワークを介してクライアント装置、サーバ間でプロトコル・データ・ユニットの送受信を行うネットワークインタフェース部と、
　前記サーバの負荷分散を行うプロセス処理部とを備え、
　前記プロセス処理部が、
　前記対象となるサーバから、前記プロトコル・データ・ユニットの宛先となるサーバを選択する宛先判定処理部と、
　前記宛先判定処理部で選択したサーバのアドレスを、受信したプロトコル・データ・ユニットの宛先に付与して、ネットワークインタフェース部を介して接続先へ転送するアドレス付与部とを備える
　ことを特徴とするサーバ負荷分散装置。」
　
（相違点１）
　
　サーバ負荷分散装置に関して、本願発明が、「ＰＣＩバス規格に準拠したＰＣＩバスを備えるコンピュータ装置のＩ／Ｏインタフェースに装着され、前記Ｉ／Ｏインタフェースを介して前記ＰＣＩバスと接続された拡張カード」であるのに対して、引用発明は、「サーバロードバランサ」である点。
　
（相違点２）
　
　ネットワークを流れるデータの単位であるプロトコル・データ・ユニットに関して、本願発明が、「フレーム」であるのに対して、引用発明は、「パケット」である点。
　
（相違点３）
　
　プロセス処理部に関して、本願発明が、「コンピュータ装置のプロセッサに負荷をかけることなく、前記サーバの負荷分散を行う」ものであるのに対して、引用発明は、サーバの負荷分散を行うものの、そのようなものであるか不明である点。
　
（相違点４）
　
　プロセス処理部において、本願発明が、「アドレスのフィルタリングを行い、自分宛のアドレスのフレームを受信するアドレスフィルタ部」と「受信したフレームのデータフローと前記受信したフレームから抽出されたセッション毎のポート番号の識別子に基づいて、前記セッションの識別情報と前記ポート番号とを組み合わせてポート番号テーブルに登録するフレーム抽出部」を備えているのに対して、引用発明は、これらを備えているか不明である点。
　
（相違点５）
　
　サーバの選択に関して、本願発明が、「負荷分散の対象となるサーバのサービス中のセッション数に基づいて」サーバを選択するのに対して、引用発明は、複数の宛先サーバの負荷を計測し、負荷の少ない宛先サーバを選択するものである点。
　
７．当審の判断
　
　上記相違点１ないし相違点５について検討する。
　
（１）相違点１及び相違点３について
　
（１−１）引用文献１の上記Ｅに「〔変形例〕・・・実際にサーバロードバランサ５を構成する場合、例えば各サーバロードバランサ５の機能を複数枚のＮＩＣ（Network Interface Card）の個々に実装し、同一の装置筐体内に複数枚のＮＩＣを収容することが可能である」と記載されるように、引用文献１においても、サーバ負荷分散装置である「サーバロードバランサ」の機能を、「ＮＩＣ」（ネットワーク・インタフェース・カード）上に実装する態様も提示されている。
　また、参考文献１（上記Ｇ参照）及び参考文献２（上記Ｈ参照）に記載されるように、コンピュータ装置が備えるＰＣＩバスにＮＩＣを接続する構成は、当該技術分野において、当業者が普通に採用している周知慣用技術に他ならない。
　してみると、引用発明においても、「サーバロードバランサ」を、ＰＣＩバス規格に準拠したＰＣＩバスを備えるコンピュータ装置のＩ／Ｏインタフェースに装着され、当該Ｉ／Ｏインタフェースを介して前記ＰＣＩバスと接続される拡張カードとして構成すること、すなわち、上記相違点１に係る構成とすることは、当業者が容易に想到し得たことである。
　
　よって、相違点１は格別なものではない。
　
（１−２）そして、引用発明において、拡張カードを用いて負荷分散機能を実現した場合、当該拡張カードを備えたコンピュータ装置のプロセッサに負荷をかけずに負荷分散が実現できることは、当業者にとって自明の事項である。
　してみると、引用発明において、拡張カードを用いて「サーバロードバランサ」を構成した場合には、相違点３は、必然的に採用される事項にすぎない。
　
（２）相違点２について
　
　「フレーム」や「パケット」は、ネットワーク上のデータの単位として、どちらも広く用いられているものであり、プロトコル・データ・ユニットとして、「フレーム」と「パケット」のどちらを採用するかについては、当業者が必要に応じて、適宜選択可能な設計的事項にすぎない。
　してみると、引用発明においても、ネットワークを流れるデータの単位であるプロトコル・データ・ユニットとして、「パケット」に替えて「フレーム」を採用するように構成すること、すなわち、上記相違点２に係る構成とすることは、当業者が容易に想到し得たことである。
　
　よって、相違点２は格別なものではない。
　
（３）相違点４について
　
（３−１）ネットワークに接続されている装置において、受信したデータが自分宛かどうかを、アドレスのフィルタリングを行って確認することは、当該技術分野において、通常行われていることである。
　してみると、引用発明においても、アドレスのフィルタリングを行い、自分宛のアドレスのパケットを受信するように構成することは、必要に応じて適宜なし得たことである。
　
（３−２）引用文献２の上記Ｆに「図２は、実施の形態１のサーバ負荷分散装置におけるセッション管理テーブル３に登録される内容を示すデータ構造図・・・セッション管理テーブル３に登録される項目は、セッションＩＤ、セッション識別情報、セッション属性に大別され・・・セッション属性は・・・ポートＩＤなどから構成される」と記載されるように、サーバ負荷分散装置が、テーブルを用いて、「セッション識別情報」や「ポートＩＤ」を管理する技術についても、本願出願前に周知技術であった。
　また、参考文献３（上記Ｊ参照）に記載されるように、フレームのフォーマットとして、「ＩＰアドレス」や「ポート番号」を含む構成は、当該技術分野において、普通に用いられていた周知慣用技術にすぎず、同じく参考文献３（上記Ｋ及び図１等参照）に記載されるように、受信したフレームに含まれている「ＩＰアドレス」と「ポート番号」を抽出して、当該抽出した「ＩＰアドレス」と「ポート番号」を関連付けして管理テーブルに登録して管理することも、本願出願前に周知技術であった。さらに、参考文献４（上記Ｌ及び図６等参照）においても、クライアントから受信したパケットに含まれる「アドレス」と「ポート番号」を関連付けてテーブルに格納する技術が開示されている。
　そして、引用発明のサーバロードバランシング処理部も、セッション・テーブルを有していることから、当該セッション・テーブルを用いて接続情報を管理するものであることは、当業者にとって自明の事項である。
　してみると、引用発明においても、受信したパケットに含まれる「ＩＰアドレス」（本願発明の「セッションの識別情報」に相当）と「ポート番号」を抽出し、当該抽出した「ＩＰアドレス」と「ポート番号」を組み合わせてセッション・テーブルに登録するように構成することは、必要に応じて適宜なし得たことである。
　
（３−３）以上、引用発明においても、サーバロードバランシング処理部において、アドレスのフィルタリングを行い、自分宛のアドレスのパケットを受信するように構成し、そして、前記受信したパケットに含まれる「ＩＰアドレス」と「ポート番号」を抽出し、当該抽出した「ＩＰアドレス」と「ポート番号」を組み合わせてセッション・テーブルに登録するように構成すること、すなわち、上記相違点４に係る構成とすることは、当業者が容易に想到し得たことである。
　
　よって、相違点４は格別なものではない。
　
（４）相違点５について
　
　引用文献１の上記Ｃに「複数のサーバ７の１つを選択する方法・・・最小コネクション数」と記載されるように、引用文献１においても、コネクション数（本願発明の「セッション数」に対応）に基づいてサーバを選択する技術が開示されている。
　してみると、引用発明においても、サーバの選択に際して、サーバのサービス中のセッション数に基づいて選択するように構成すること、すなわち、上記相違点５に係る構成とすることは、当業者が容易に想到し得たことである。
　
　よって、相違点５は格別なものではない。
　
（５）小括
　
　上記で検討したごとく、相違点１ないし相違点５は格別のものではなく、そして、これらの相違点を総合的に勘案しても、本願発明の奏する作用効果は、上記引用発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。
　
　したがって、本願発明は、上記引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
８．むすび 
　
　以上のとおり、本願の請求項１に係る発明は、本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、その特許出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　したがって、その余の請求項について論及するまでもなく、本願は拒絶すべきものである。
　
　よって、結論のとおり審決する。