【事件の表示】
　特願２０００−３１１１１５「電子メール送受信システム」拒絶査定不服審判事件〔平成１４年　４月１９日出願公開、特開２００２−１１６９９４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成１２年１０月１１日の出願であって、平成１９年１１月９日付けで手続補正がなされ、平成２１年１１月２６日付け拒絶理由通知に対して、平成２２年１月２９日付けで手続補正がなされたが、同年７月２２日付けで拒絶査定がなされ、これに対して同年１０月２６日に拒絶査定不服の審判請求がされれるとともに、同日付けで手続補正がなされたものである。
　
第２　補正の却下の決定
［補正の却下の決定の結論］
　平成２２年１０月２６日付け手続補正（以下、「本件補正」という。）を却下する。
　
［理由］
（ａ）補正の内容
　本件補正によると、その特許請求の範囲の請求項１は、
「送信側の利用者端末から受信した電子メールを受信側メールサーバーに送信する送信側メールサーバーと、前記受信側メールサーバーとは異なるファイルサーバーとが、通信回線により相互に接続され、電子メール本文と該電子メール本文に関連付けられた関連ファイルを有する電子メールを、前記送信側の利用者端末から送信し、受信側の利用者端末において受信する電子メール送受信システムにおいて、
　前記送信側の利用者端末が、
　作成された電子メール本文に関連付けられた関連ファイルがあるか否かを判断し、関連ファイルがある場合、前記ファイルサーバーに対して関連ファイルの送信要求を送信し、前記ファイルサーバーから関連ファイルの送信を受け付ける旨を受信した後に、前記関連ファイルを前記ファイルサーバーへ送信する手段と、
　前記ファイルサーバーの情報及び該ファイルサーバーにおいて前記関連ファイルを特定する情報が付加された前記電子メール本文を、送信側メールサーバーへ送信する手段とを備え、
　前記送信側メールサーバーが、
　前記送信側の利用者端末より受信した電子メール本文を前記受信側メールサーバーへ送信する手段を備え、
　前記受信側の利用者端末が、
　前記受信側メールサーバーから前記電子メール本文を受信する手段と、
　前記受信した電子メール本文を画面に表示すると共に、この画面上で、前記関連ファイルをダウンロードするか否かの選択を受け付ける手段と、
　前記関連ファイルをダウンロードすることが選択された場合に、前記電子メール本文に付加された、該ファイルサーバーの情報及び該ファイルサーバーにおいて前記関連ファイルを特定する情報に基づいて、前記ファイルサーバーへ前記関連ファイルの送信要求を送信する手段と、を備える、
　ことを特徴とする電子メール送受信システム。」
と補正されている。
　
　上記補正は、本件補正前の請求項６に記載した発明を特定するために必要な事項である「前記関連ファイルを前記ファイルサーバーへ送信する手段」に対して、「作成された電子メール本文に関連付けられた関連ファイルがあるか否かを判断し、関連ファイルがある場合、前記ファイルサーバーに対して関連ファイルの送信要求を送信し、前記ファイルサーバーから関連ファイルの送信を受け付ける旨を受信した後に、」という限定を付加する補正であり、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号に規定する特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が、特許出願の際独立して特許を受けることができるものであるか（平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）否かについて、以下検討する。
　
　
（ｂ）引用例
　原査定の拒絶の理由に引用された特開２０００−２７０００８号公報（平成１２年９月２９日公開。以下、「引用例」という。）には、図面とともに次の記載がある。
　
イ．「【０００１】
【発明の属する技術分野】本発明は、テキストデータ及び非テキストデータを含む複合メールを伝達する複合メール伝達システム及びその複合メール伝達方法並びに記録媒体に関する。」（第７頁第１２欄第２２行−同欄第２６行）
　
ロ．「【０００４】しかし、近年のインターネットの発展・普及により、不特定多数のユーザを対象とする開かれたインターネットメールの使用が急速に増加しつつまり、伝統的なユニックスメール以外にも、パーソナルコンピュータ（以下、「ＰＣ」という）上などの各種電子メールの伝達装置・ソフトが実用に供されている。一方で、各種マルチメディアの急速な発展・普及に伴い、電子メールの使用においても従来のテキストデータのみからなるメールだけではなく、複合メールを送受信したいという要求が高まっている。
【０００５】ここで、「複合メール」とは、画像データ、文字の修飾データ及びそれらの割付け情報を含む複合文書、あるいは画像・音声・プログラムといったバイナリファイル等の非テキストデータを含む電子メールをいう。」（第７頁第１２欄第３５行−同欄第４９行）
　
ハ．「【００１３】（１）送信可能なメールサイズの制限
従来の電子メール伝達装置又はソフトウエアには、送信可能なメールサイズを制限しているものがある。そのため、メールサーバの制限値以上のサイズを有する複合メールを送受信できない場合があった。」（第８頁第１３欄第５０行−同頁第１４欄第４欄）
　
ニ．「【０１４０】送信者が送信メールとして作成した電子メールは、テキストメール部と複合メール部とに分離される。
【０１４１】テキストメール部は、通常の電子メール伝達経路を介して、即ち送信側ＰＣ１１からのテキストメール部のみを受信する送信側電子メールサーバ１５から受信メールサーバ１６ａ〜ｃに至るインターネット１３上のメール伝達経路を介して、受信側ＰＣ１７ａ〜ｃ上で動作する受信側メールソフトウエア１８ｃにより受信される。複数の受信者に対して同一内容のメールを送信する同報通信時も、同様に、それぞれの受信者毎に受信側メールサーバ１６ａ〜１６ｃを経て、受信側ＰＣ１７ａ〜１７ｃ上で動作する受信側メールソフトウエア１８ａ〜１８ｃにより受信される。
【０１４２】複合メール部は、送信側ＰＣ１１から、ＷＷＷサーバ１４に対して送信され、ＷＷＷサーバ１４により受信・蓄積される。」（第１６頁第３０欄第３０行−同欄第４６行）
　
ホ．「【０１９４】図６は、本実施形態に係る本実施形態に係るメール伝達装置を用いてインターネット上で複合メールを送受信した場合の電子メールの流れを示す模式図である。同図において、第１実施形態の図１に示した構成と同一の構成要素には同一番号が付してある。本実施形態においては、送信側ＰＣ１１上で本発明に係る複合メール送信ソフトウエア６１が動作する。また、本実施形態においては、図１に示したＷＷＷサーバ１４の代わりに、ＦＴＰサーバ６２を採用する。ＦＴＰサーバの運用及び設置については、第１実施形態におけるＷＷＷサーバ１４と同様である。
【０１９５】図７は、本実施形態に係る複合メール送信手順を示すフローチャートである。
【０１９６】メール送信者により、送信側ＰＣ１１において、送信側電子メールソフトウエア１２を用いて、送信したい一つないし複数のファイルまたはディレクトリの指定、送信ファイルに関する説明などのコメント入力、受信者のメールアドレスその他の電子メールに必要な情報の設定後、完成した複合メールの送信が指示されると、本手順は開始される。」（第２０頁第３７欄第３５行−同頁第３８欄第４行）
　
ヘ．「【０２０４】そして、作成された複合メール部を送信するＦＴＰサーバ６２のＵＲＬアドレスが確定される（ステップＳ７４）。このＦＴＰサーバ６２のアドレスは、上述した第１または第２実施形態と同様の手法によって決定されるが、本実施形態においては、受信者からのファイルへのアクセスをＦＴＰプロトコルで行う必要があるため、「ｆｔｐ：」で始まるＵＲＬアドレスとして決定される。
【０２０５】つぎに、作成された複合メール部のサイズが求められる（ステップＳ７５）。ここで求めるのは、データ圧縮・変換を行わない場合は複合メール部として扱われる元の送信ファイルのサイズであり、データ圧縮・変換を行う場合はステップＳ７３でデータ圧縮・変換処理された後の複合メール部のサイズである。
【０２０６】送信するファイルに関するコメント、ステップＳ７４で決定されたＵＲＬアドレス、ステップＳ７５で求めた複合メール部のサイズ情報、及びデータ圧縮・変換形式に関する情報等から構成されるテキストメール部が作成され（ステップＳ７６）、ＦＴＰサーバ６２上に複合メール部を受信するのに十分な空き容量があるか否かが判別される（ステップＳ７７）。
【０２０７】ステップＳ７７において、十分な空き容量がある場合は、ステップＳ７６で作成されたテキストメール部が、指定された受信者のメールアドレスへ通常のメールプロトコル（例えばＳＭＴＰ）で送信され（ステップＳ７８）、複合メール部がステップＳ７４で決定されたファイル名及びアドレスを用いてＦＴＰサーバ６２の所定領域へＦＴＰ送信され（ステップＳ７９）、本手順が終了される。なお、上述した第２実施形態のように、送信側ＰＣ１１がＦＴＰサーバ６２の機能をも兼ねている場合、ステップＳ７９では、ＦＴＰサーバ６２として使用される送信側ＰＣ１１内の所定領域へ複合メール部がコピーされる。
【０２０８】また、ステップＳ７７の判別で、ＦＴＰサーバの空き容量が十分ではない場合は、送信側電子メールソフトウエア６１の処理により、警告メッセージが表示され（ステップＳ８０）、その後本手順が終了される。」（第２１頁第３９欄第１１行−同欄第４８行）
　
ト．「【０２１２】図９は、受信側ＰＣ１７において行われる複合メール受信手順を示すフローチャートである。
【０２１３】まず、受信側ＰＣ１７ｃ上の受信側電子メールソフトウエア６３ｃで受信されたテキストメール部が読まれ（ステップＳ９１）、その内容から複合メール部を受信するか否かが決定される（ステップＳ９２）。すなわち、ステップＳ９２では、元の電子メールのテキストメール部の内容に基いて、複合メール部の受信が必要であるか否かが判別され、テキストメール部中の複合メール部のサイズ情報に基いて受信側ＰＣ１７ｃの記憶容量にこの複合メール部を受信するのに十分な空き容量があるか否かが判別され、更に、テキストメール部中の複合メール部のサイズ情報と現在の受信側ＰＣ１７ｃの通信回線との接続状況等に基いて、複合メール部の受信に必要な時間が許容範囲内であるか否かが判別される。
【０２１４】ステップＳ９２の判別で、複合メール部を受信しない場合は、直ちに本手順が終了される。また、複合メール部を受信する場合は、テキストメール部に含まれている、元の送信ファイルのＵＲＬまたは圧縮・変換ファイルのＵＲＬが選択される（ステップＳ９４）。上述したように送信側ＰＣ１１において、ステップＳ８４の手順で圧縮・変換ファイルのＵＲＬ及びサイズ情報と元のファイルのＵＲＬ及びサイズ情報がテキストメール部に含まれている。例えば、図６に示したテキストメール部の拡大図６３ｃ’には、元のファイル及び圧縮変換ファイルのそれぞれについて、見出しとして「＜オリジナル＞」または「＜圧縮ファイル＞」との表示と、そのＵＲＬアドレス、及びサイズ情報とが記載されている。また、圧縮・変換ファイルのＵＲＬアドレスの最後の部分に記載されている「ｚｉｐ」から、この圧縮・変換ファイルが汎用のデータ圧縮形式であるｚｉｐ形式であることが判る。受信者は、テキストメール部の内容を見て、圧縮・変換ファイルを自己のマシン環境において扱うことが出来る場合には圧縮・変換ファイルのＵＲＬアドレスを選択し、扱えない場合には元のファイルのＵＲＬアドレスを選択することができる。
【０２１５】次に、受信側ＰＣ１７ｃ上の受信側電子メールソフトウエア６３ｃが「クリッカブルＵＲＬ」機能を有しているか否かが判別される（ステップＳ９４）。受信側電子メールソフトウエア６３ｃが「クリッカブルＵＲＬ」機能を備えている場合、テキストメール部中のＵＲＬアドレスがマウスボタンによりダブルクリックされると（ステップＳ９５）、ブラウザ６４ｃにより、指令されたＵＲＬアドレスに従って、ＦＴＰサーバ６２のディレクトリ上の複合メール部へのアクセスが行われる（ステップＳ９６）。そして、ＦＴＰサーバ６２によりこのアクセスを受けて標準規格ＦＴＰプロトコルで送信された複合メール部が、ブラウザ６４ｃによって受信され（ステップＳ９７）、受信側ＰＣ１７ｃのハードディスク（不図示）に蓄積される（ステップＳ９８）。
【０２１６】また、ステップＳ９４の判別で、受信側電子メールソフトウエア６３ｃがクリッカブルＵＲＬ機能を備えていない場合は、ブラウザ６４ｃが別途起動され（ステップＳ１０１）、テキストメール部中のＵＲＬアドレスをブラウザ６４ｃのアドレスエリアへコピー・アンド・ペースト操作で入力することにより（ステップＳ１０２）、ステップＳ９６においてＦＴＰサーバ６２の複合メール部へのアクセスが行われる。
【０２１７】蓄積された複合メール部が圧縮・変換ファイルであるか否かが判別され（ステップＳ９９）、圧縮変換ファイルでない場合はすでに元の（圧縮・変換処理前の）送信ファイルであるから、そのまま本受信手順が終了される。また、圧縮・変換ファイルであると判別された場合は、受信側ＰＣ１７ｃに備えられている、図示しない圧縮・変換ファイル解凍プログラム等の機能を用いて、ファイルの解凍または逆変換による再現が行われ（ステップＳ１００）、その後本手順が終了される。」（第２１頁第４０欄第３８行−第２２頁第４２欄第４行）
　
チ．【図６】には、受信側ＰＣ１７ｃにおいて、受信したテキストメール部のコメントを画面に表示すると共に、この画面上で、該コメントに関する複合メール部（送信ファイル）のＵＲＬアドレスを表示することが開示されている。
　
　したがって、引用例には次の発明（以下、「引用発明」という。）が開示されているものと認められる。
　
「テキストデータ及びバイナリファイル等の非テキストデータを含む複合メールを伝達する複合メール伝達システムであって、
　送信者が送信メールとして作成した電子メールは、テキストメール部と複合メール部とに分離され、
　テキストメール部は、通常の電子メール伝達経路を介して、即ち送信側ＰＣ１１からのテキストメール部のみを受信する送信側電子メールサーバ１５から受信メールサーバ１６ｃに至るインターネット１３上のメール伝達経路を介して、受信側ＰＣ１７ｃ上で動作する受信側メールソフトウエア６３ｃにより受信され、
　複合メール部は、送信側ＰＣ１１から、ＦＴＰサーバ６２に対して送信され、ＦＴＰサーバ６２により受信・蓄積され、
　メール送信者により、送信側ＰＣ１１において、送信側電子メールソフトウエアを用いて、送信したい一つないし複数のファイルの指定、送信ファイルに関する説明などのコメント入力、受信者のメールアドレスその他の電子メールに必要な情報の設定後、完成した複合メールの送信が指示されると、複合メール送信手順は開始され、
　そして、作成された複合メール部を送信するＦＴＰサーバ６２のＵＲＬアドレスが確定され、
　つぎに、作成された複合メール部のサイズが求められ、
　送信するファイルに関するコメント及びＵＲＬアドレス等から構成されるテキストメール部が作成され、ＦＴＰサーバ６２上に複合メール部を受信するのに十分な空き容量があるか否かが判別され、
　十分な空き容量がある場合は、作成されたテキストメール部が、指定された受信者のメールアドレスへ通常のメールプロトコルで送信され、複合メール部が決定されたファイル名及びアドレスを用いてＦＴＰサーバ６２の所定領域へＦＴＰ送信され、複合メール送信手順が終了され、
　受信側ＰＣ１７ｃにおいて行われる複合メール受信手順を示すと、
　受信したテキストメール部のコメントを画面に表示すると共に、この画面上で、該コメントに関する複合メール部（送信ファイル）のＵＲＬアドレスを表示し、
　受信側電子メールソフトウエア６３ｃが「クリッカブルＵＲＬ」機能を備えている場合、テキストメール部中のＵＲＬアドレスがマウスボタンによりダブルクリックされると、ブラウザ６４ｃにより、指令されたＵＲＬアドレスに従って、ＦＴＰサーバ６２のディレクトリ上の複合メール部へのアクセスが行われ、そして、ＦＴＰサーバ６２によりこのアクセスを受けて標準規格ＦＴＰプロトコルで送信された複合メール部が、ブラウザ６４ｃによって受信され、受信側ＰＣ１７ｃのハードディスクに蓄積される、
　複合メール伝達システム。」
　
　
（ｃ）対比
　本願補正発明と引用発明とを対比する。
（１）引用発明の「複合メール伝達システム」は、本願補正発明の「電子メール送受信システム」に相当する。
（２）引用発明の「送信側ＰＣ１１」、「送信側電子メールサーバ１５」、「インターネット１３」、「受信側メールサーバ１６ｃ」、「受信側ＰＣ１７ｃ」、及び「ＦＴＰサーバ６２」は、それぞれ、本願補正発明の「送信側の利用者端末」、「送信側メールサーバー」、「通信回線」、「受信側メールサーバ」、「受信側の利用者端末」、及び「受信側メールサーバーとは異なるファイルサーバー」に相当する。
（３）引用発明のテキストメール部を構成する「送信するファイルに関するコメント」は、本願補正発明の「電子メール本文」に相当する。また、「複合メール部」は、メール送信者が指定した送信ファイルであるので、本願補正発明の「電子メール本文に関連づけられた関連ファイル」に相当する。
（４）引用発明のＵＲＬアドレスは、作成された複合メール部を送信するＦＴＰサーバ６２のＵＲＬアドレスであり、指令されたＵＲＬアドレスに従って、ＦＴＰサーバ６２のディレクトリ上の複合メール部へのアクセスが行われるから、引用発明の「ＵＲＬアドレス」は、本願補正発明の「前記ファイルサーバーの情報及び該ファイルサーバーにおいて前記関連ファイルを特定する情報」に相当する。
（５）引用発明では、送信側ＰＣ１１において、作成されたテキストメール部が、指定された受信者のメールアドレスへ通常のメールプロトコルで送信され、複合メール部が決定されたファイル名及びアドレスを用いてＦＴＰサーバ６２の所定領域へＦＴＰ送信されているので、引用発明の「送信側ＰＣ１１」は、「前記関連ファイルを前記ファイルサーバーへ送信する手段」と「前記ファイルサーバーの情報及び該ファイルサーバーにおいて前記関連ファイルを特定する情報が付加された前記電子メール本文を、送信側メールサーバーへ送信する手段」とを備えているといえる。
（６）引用発明では、テキストメール部は、送信側ＰＣ１１からのテキストメール部のみを受信する送信側電子メールサーバ１５から受信メールサーバ１６ｃに至るインターネット１３上のメール伝達経路を介して、受信側ＰＣ１７ｃ上で動作する受信側メールソフトウエアにより受信されるので、引用発明の「送信側電子メールサーバ１５」は、「前記送信側の利用者端末より受信した電子メール本文を前記受信側メールサーバーへ送信する手段」を備えているといえる。また、引用発明の「受信側ＰＣ１７ｃ」は、「前記受信側メールサーバーから前記電子メール本文を受信する手段」を備えているといえる。
（７）引用発明では、受信側ＰＣ１７ｃにおいて、受信したテキストメール部を画面に表示すると共に、この画面上で、ＵＲＬアドレスを表示して、該ＵＲＬアドレスに係る送信ファイルにアクセスする選択を受け付けており、テキストメール部中のＵＲＬアドレスがマウスボタンによりダブルクリックされると、ブラウザ６４ｃにより、指令されたＵＲＬアドレスに従って、ＦＴＰサーバ６２のディレクトリ上の複合メール部へのアクセスが行われ、そして、ＦＴＰサーバ６２によりこのアクセスを受けて標準規格ＦＴＰプロトコルで送信された複合メール部が、ブラウザ６４ｃによって受信され、受信側ＰＣ１７ｃのハードディスクに蓄積される。ファイルをアクセスする選択を受け付けて、該ファイルが受信側ＰＣ１７ｃのハードディスクに蓄積されることから、受信側ＰＣ１７ｃが受け付けるのは、ファイルをダウンロードする選択であるといえる。よって、引用発明の「受信側ＰＣ１７ｃ」は、「前記受信した電子メール本文を画面に表示すると共に、この画面上で、前記関連ファイルをダウンロードするか否かの選択を受け付ける手段」と、「前記関連ファイルをダウンロードすることが選択された場合に、前記電子メール本文に付加された、該ファイルサーバーの情報及び該ファイルサーバーにおいて前記関連ファイルを特定する情報に基づいて、前記ファイルサーバーへ前記関連ファイルの送信要求を送信する手段」とを備えているといえる。
　
　したがって、両者の一致点・相違点は、次のとおりである。
　
＜一致点＞
「送信側の利用者端末から受信した電子メールを受信側メールサーバーに送信する送信側メールサーバーと、前記受信側メールサーバーとは異なるファイルサーバーとが、通信回線により相互に接続され、電子メール本文と該電子メール本文に関連付けられた関連ファイルを有する電子メールを、前記送信側の利用者端末から送信し、受信側の利用者端末において受信する電子メール送受信システムにおいて、
　前記送信側の利用者端末が、
　前記関連ファイルを前記ファイルサーバーへ送信する手段と、
　前記ファイルサーバーの情報及び該ファイルサーバーにおいて前記関連ファイルを特定する情報が付加された前記電子メール本文を、送信側メールサーバーへ送信する手段とを備え、
　前記送信側メールサーバーが、
　前記送信側の利用者端末より受信した電子メール本文を前記受信側メールサーバーへ送信する手段を備え、
　前記受信側の利用者端末が、
　前記受信側メールサーバーから前記電子メール本文を受信する手段と、
　前記受信した電子メール本文を画面に表示すると共に、この画面上で、前記関連ファイルをダウンロードする選択を受け付ける手段と、
　前記関連ファイルをダウンロードすることが選択された場合に、前記電子メール本文に付加された、該ファイルサーバーの情報及び該ファイルサーバーにおいて前記関連ファイルを特定する情報に基づいて、前記ファイルサーバーへ前記関連ファイルの送信要求を送信する手段と、を備える、
　ことを特徴とする電子メール送受信システム。」である点。
　
＜相違点１＞
　送信側の利用者端末が関連ファイルをファイルサーバへ送信するのが、本願補正発明は、「作成された電子メール本文に関連付けられた関連ファイルがあるか否かを判断し、関連ファイルがある場合、前記ファイルサーバーに対して関連ファイルの送信要求を送信し、前記ファイルサーバーから関連ファイルの送信を受け付ける旨を受信した後に」であるのに対して、引用発明は、「作成された電子メール本文に関連付けられた関連ファイルがあるか否かを判断し、関連ファイルがある場合、前記ファイルサーバーに対して関連ファイルの送信要求を送信し、前記ファイルサーバーから関連ファイルの送信を受け付ける旨を受信した後に」という限定がない点。
　
＜相違点２＞
　本願補正発明も引用発明も、受信側の利用者端末の備える「受け付ける手段」が、前記受信した電子メール本文を画面に表示すると共に、この画面上で、前記関連ファイルをダウンロードする選択を受け付ける点で一致しているが、該「受け付ける手段」が、本願補正発明は「ダウンロードする
か否かの
か否かの
　
　
（ｄ）当審の判断
　以下、相違点について検討する。
　
・相違点１について
　引用発明の電子メール送受信システムは、送信したい一つないし複数のファイルを指定するもので、作成された電子メール本文に関連付けられた関連ファイルが存在することを前提としているが、一般の電子メール送受信システムでは、作成された電子メール本文に関連付けられた関連ファイルが存在する電子メールと存在しない電子メールとが混在しているのが普通である。また、作成された電子メール本文に関連付けられた関連ファイルが存在しないときには、関連ファイルの送信処理が必要ないことは当然である。さらに、作成された電子メール本文に関連付けられた関連ファイルがあるか否かを判断してから、その後の関連ファイルの送信処理を行うことは、たとえば特開２０００−１３４３１号公報（第４頁第５欄第７行−同欄第３１行，【図５】のＳ１）にみられるように、周知な技術である。
　また、ファイルを他の装置に対して送信するに際して、まず当該他の装置に対してファイルの送信を受け付けてもらう要求を送信し、他の装置からファイルの送信を受け付ける旨を受信した後に、当該ファイルを当該他の装置に送信するように構成することは、たとえば特開２０００−１３４３１号公報（第３頁第３欄第４０行−同頁第４欄第３行，【図２】の（１）〜（３））にみられるように周知な技術である。
　したがって、引用発明において、作成された電子メール本文に関連付けられた関連ファイルがあるか否かを判断し、関連ファイルがある場合、前記ファイルサーバーに対して関連ファイルの送信要求を送信し、前記ファイルサーバーから関連ファイルの送信を受け付ける旨を受信した後に、前記関連ファイルを前記ファイルサーバーへ送信するように構成することは、当業者が容易に想到し得ることである。
　
・相違点２について
　電子メールに含まれるバイナリデータをメール本文とは別に送信する電子メール送受信システムにおいて、電子メールの受信側の利用者端末に、バイナリデータを獲得するか否かの選択を受け付ける手段を設けるように構成することは、たとえば特開平１１−３２９９号公報（段落【００３７】）や、特開平９−３１１８３１号公報（段落【００３７】−【００３９】，【図３】の３０５）にみられるように周知な技術である。
　したがって、引用発明の受信側の利用者端末おいて、関連ファイルをダウンロードするか否かの選択を受け付ける手段を設けるように構成することは、当業者が容易になし得ることである。
　
　また、本願補正発明の効果は、引用発明及び周知技術から当業者が予測し得る範囲内のものである。
　
（ｅ）結論
　そうすると、本願補正発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１号によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　
　
第３　本願発明
　上記のとおり、本件補正は却下されたので、本願の請求項６に係る発明（以下、「本願発明」という。）は、平成２２年１月２９日付け手続補正書における特許請求の範囲の請求項６に記載された事項により特定される、以下のとおりのものである。
　
「送信側の利用者端末から受信した電子メールを受信側メールサーバーに送信する送信側メールサーバーと、前記受信側メールサーバーとは異なるファイルサーバーとが、通信回線により相互に接続され、電子メール本文と該電子メール本文に関連付けられた関連ファイルを有する電子メールを、前記送信側の利用者端末から送信し、受信側の利用者端末において受信する電子メール送受信システムにおいて、
　前記送信側の利用者端末が、
　前記関連ファイルを前記ファイルサーバーへ送信する手段と、
　前記ファイルサーバーの情報及び該ファイルサーバーにおいて前記関連ファイルを特定する情報が付加された前記電子メール本文を、送信側メールサーバーへ送信する手段とを備え、
　前記送信側メールサーバーが、
　前記送信側の利用者端末より受信した電子メール本文を前記受信側メールサーバーへ送信する手段を備え、
　前記受信側の利用者端末が、
　前記受信側メールサーバーから前記電子メール本文を受信する手段と、
　前記受信した電子メール本文を画面に表示すると共に、この画面上で、前記関連ファイルをダウンロードするか否かの選択を受け付ける手段と、
　前記関連ファイルをダウンロードすることが選択された場合に、前記電子メール本文に付加された、該ファイルサーバーの情報及び該ファイルサーバーにおいて前記関連ファイルを特定する情報に基づいて、前記ファイルサーバーへ前記関連ファイルの送信要求を送信する手段と、を備える、
　ことを特徴とする電子メール送受信システム。」
　
　
第４　引用例
　原査定の拒絶の理由に引用された引用例、及びその記載事項は、前記「第２［理由］（ｂ）」に記載したとおりである。
　
　
第５　対比・判断
　本願発明は、前記「第２」で検討した本願補正発明の「前記関連ファイルを前記ファイルサーバーへ送信する手段」に対する「作成された電子メール本文に関連付けられた関連ファイルがあるか否かを判断し、関連ファイルがある場合、前記ファイルサーバーに対して関連ファイルの送信要求を送信し、前記ファイルサーバーから関連ファイルの送信を受け付ける旨を受信した後に、」という限定を省いたものである。
　そうすると、本願発明の構成要件をすべて含み、さらに限定したものに相当する本願補正発明が、前記「第２（ｄ）」に記載したとおり、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
　
第６　むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。
　よって、結論のとおり審決する。