【事件の表示】
　平成　７年特許願第　３５１５３号「データ処理方法および装置」拒絶査定不服審判事件〔平成　８年　９月１３日出願公開、特開平　８−２３４９７６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
１．手続の経緯と本願発明
　本願は、平成７年２月２３日の出願であって、原審において平成１６年１１月１５日付けで拒絶理由通知がなされ、平成１７年１月１７日付けで意見書が提出されるとともに手続補正がなされ、同年７月１２日付けで拒絶査定がなされた。
　それに対して、平成１７年８月１５日付け拒絶査定不服の審判請求がなされ、当審において、平成１９年４月１７日付けで拒絶理由通知がなされ、同年６月１５日付けで意見書が提出されるとともに手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１７年１月１７日付け、及び平成１９年６月１５日付けの手続補正書により補正された明細書及び図面の記載から見て、特許請求の範囲の請求項１に記載されたとおりの次のものと認める。
　
　入力された入力データを所定のプロトコルを用いて送信するとともに、伝送されてきたデータを前記所定のプロトコルを用いて受信する基本的機能を有する基本機能プログラムにしたがって処理を行うデータ処理装置で、伝送されてきた所定のデータに対して所定の処理を実行するデータ処理方法において、
　データを伝送する前記データ処理装置の通信手段が、前記基本機能プログラムにしたがって、前記所定のプロトコルを用いて伝送されてきたデータを受信する受信ステップと、　前記データ処理装置が、前記基本機能プログラムから取り込んだデータに対して所定の処理を行う拡張機能を有する拡張機能プログラムを有している場合、前記拡張機能プログラムにしたがって、前記受信ステップで受信されたデータ中に特定のデータが含まれているかを検出する検出ステップと、
　前記受信ステップで受信されたデータ中に前記特定のデータが検出されたとき、前記データ処理装置が、前記拡張機能プログラムにしたがって、前記特定のデータに対応する処理を実行する実行ステップと、
　前記データ処理装置が、前記拡張機能プログラムにしたがって、前記特定のデータに対応する処理を実行して得られた結果を、前記基本機能プログラムの入力データに変換する変換ステップと、
　前記データ処理装置が、前記拡張機能プログラムにしたがって、前記基本機能プログラムの入力データに変換されたデータを前記拡張機能プログラムから前記基本機能プログラムに渡す処理ステップと、
　前記データ処理装置の前記通信手段が、前記基本機能プログラムにしたがって、前記拡張機能プログラムから前記基本機能プログラムに渡されたデータを前記所定のプロトコルで伝送する伝送ステップと、
　前記データ処理装置が、前記拡張機能プログラムを有していない場合、前記基本機能プログラムから取り込んだデータに対して、前記基本機能プログラムにしたがって、所定の処理を実行する実行ステップと、
　前記データ処理装置の前記通信手段が、前記基本機能プログラムにしたがって、所定の処理を実行して得られた結果を、前記所定のプロトコルで伝送する伝送ステップと
　を具備することを特徴とするデータ処理方法。
　
３．引用例の発明
（１）当審の平成１９年４月１７日付けの拒絶理由に引用された、本願出願日前に頒布された刊行物である“ユーザーが作るＬＡＮアプリケーション教室第７回　稟議書メールの試み”、コンピュータ＆ネットワークＬＡＮ、第１２巻　第７号、株式会社オーム社、１９９４年７月、ｐ．１２３−１２８（以下、「引用例１」という。）には次の事項が記載されている。
　
ａ．「あくまでも，ＡＶＥ−ＭＡＩＬのクライアント・アプリケーションが処理を一手に引き受ける，という前提がありますから，これまでに見てきたメッセージあるいはデータのやり取りの仕方から逸脱することはできません。さて，ここでも選択肢がいくつかでてきます。まず一番簡単な方法は，従来の電子メールの授受の機構をそのまま使うというものです。もう少し凝ったことをするならば，パック（添付ファイル）を使うという方法もあります。ここでは，もっともシンプルに，電子メールのメッセージとしてあつかうことを考えてみましょう。」（第１２５頁右欄２５行〜第１２６頁左欄９行）
　
ｂ．「ＡＶＥ−ＭＡＩＬのメールのメッセージの形式は，ＵＮＩＸメールのものを踏襲していて図４のようになっています。このメッセージ・ボディの部分に稟議書の内容を盛り込めば一応使えるようになるわけですが，一般の電子メールと区別して読書きできれば効率がよいので，ヘッダのほうにちょっとした仕掛けがあります。“Ｘ−Ｆｏｒｍ”という拡張キーワードをヘッダに追加してあり，これによってメッセージの種類を識別できるようになっています。」（第１２６頁左欄１０行〜１８行）
　
ｃ．「（４）稟議受信・回覧
　起案者から送られたメッセージは，通常のメールと同じように着信処理をします。着信メールー覧への表示方法などは，メッセージ・ヘッダの“Ｘ−Ｆｏｒｍ”の記述をチェックすることにより，いろいろ工夫することが可能です。メールを読む処理のところで稟議書メールであることが判明したならば，通常のメール内容表示から分岐して稟議受信フォームを表示するようにします。
　稟議受信フォームへの内容表示は，先述のフォーマット化されたメッセージからの項目の拾い出しとテキスト・ボックスなどへの反映ということになります。メッセージ・ボディはテキストのブロックになっていますので，拾い出しはＢａｓｉｃで容易に行えます。
　参照表示された内容に対しては，決裁者は変更を加えることができないようにしておきます。図８のようにして書き換えられたくないコントロールへの入力を無視して，不用意に表示内容が変わらないようにします。表示されている稟議内容に対する決裁者のアクションは，「決裁」，「保留」，「否決」のいずれかを選択することと「意見」を書き込むことです。また，それまでに回覧がすんでいる人が記入した意見を参照することができるようになっています。」（第１２７頁左欄１行〜第１２８頁左欄３行）
　
ｄ．「決裁者が入力した情報は，起案者からのメッセージと合わせて再びフォーマット化して，「次」のメンバーに転送することになります。この部分は起案者からの送信のときと同様に，ルーティング・パスを記述した配列を参照して，現在ログインしているユーザーＩＤをもとに，次の送付先を割り出して送信構造体にセットして送信します（図９）。ただし，一番最初の起案者のときと異なり，決裁者が「否決」した場合の処理も考えておく必要があります。ルーテイング・パスの設定の仕方は，導入したサイトの状況か業務の内容によっても大きく異なりますが，このシステムでは単純に起案者に「否決」された旨のメッセージを返送するようにします。また決裁者がルーティング・パスの最後の最終決定者だった場合の処理ですが，これもいろいろなケースが考えられ，たとえば購入担当や経理に通知を送るなどという処理も必要でしよう。ここではこの件についても，シンプルに起案者に決裁がおりたことを知らせるという形をとっています。」（第１２８頁左欄１３行〜右欄１２行）
　
　上記ａ．における「あくまでも，ＡＶＥ−ＭＡＩＬのクライアント・アプリケーションが処理を一手に引き受ける，という前提がありますから，これまでに見てきたメッセージあるいはデータのやり取りの仕方から逸脱することはできません。　・・・（中　略）・・・　まず一番簡単な方法は，従来の電子メールの授受の機構をそのまま使うというものです。もう少し凝ったことをするならば，パック（添付ファイル）を使うという方法もあります。ここでは，もっともシンプルに，電子メールのメッセージとしてあつかうことを考えてみましょう。」の記載、並びに、上記ｃ．における「起案者から送られたメッセージは，通常のメールと同じように着信処理をします。　・・・（中　略）・・・　メールを読む処理のところで稟議書メールであることが判明したならば，通常のメール内容表示から分岐して稟議受信フォームを表示するようにします。」の記載、及び、上記ｄ．における「決裁者が入力した情報は，起案者からのメッセージと合わせて再びフォーマット化して，「次」のメンバーに転送することになります。この部分は起案者からの送信のときと同様に，ルーティング・パスを記述した配列を参照して，現在ログインしているユーザーＩＤをもとに，次の送付先を割り出して送信構造体にセットして送信します（図９）。」の記載から、引用例１に記載されたものは、入力したメッセージをフォーマット化し送信するとともに、送られてきたメッセージを電子メールのメッセージとしてあつかう、従来の電子メール授受の機構を有するＡＶＥ−ＭＡＩＬのクライアントで、送られてきたメッセージに対して所定の処理を実行するクライアント・アプリケーションであることがわかる。
　
　また、上記ａ．における「あくまでも，ＡＶＥ−ＭＡＩＬのクライアント・アプリケーションが処理を一手に引き受ける，という前提がありますから，これまでに見てきたメッセージあるいはデータのやり取りの仕方から逸脱することはできません。　・・・（中　略）・・・　まず一番簡単な方法は，従来の電子メールの授受の機構をそのまま使うというものです。もう少し凝ったことをするならば，パック（添付ファイル）を使うという方法もあります。ここでは，もっともシンプルに，電子メールのメッセージとしてあつかうことを考えてみましょう。」の記載、及び、上記ｃ．における「起案者から送られたメッセージは，通常のメールと同じように着信処理をします。」の記載から、引用例１に記載されたものは、メッセージをあつかうＡＶＥ−ＭＡＩＬのクライアントの授受の機構が、従来の電子メールの授受の機構をそのまま使い、電子メールのメッセージとして着信処理を行うステップを有することがわかる。
　
　さらに、上記ｂ．における「一般の電子メールと区別して読書きできれば効率がよいので，ヘッダのほうにちょっとした仕掛けがあります。“Ｘ−Ｆｏｒｍ”という拡張キーワードをヘッダに追加してあり，これによってメッセージの種類を識別できるようになっています。」の記載、及び、上記ｃ．における「着信メールー覧への表示方法などは，メッセージ・ヘッダの“Ｘ−Ｆｏｒｍ”の記述をチェックすることにより，いろいろ工夫することが可能です。メールを読む処理のところで稟議書メールであることが判明したならば，通常のメール内容表示から分岐して稟議受信フォームを表示するようにします。」の記載から、引用例１に記載されたものは、ＡＶＥ−ＭＡＩＬのクライアントが、送られてきたメッセージに“Ｘ−Ｆｏｒｍ”という拡張キーワードがヘッダに追加されているかどうかチェックするステップを有することがわかる。また、このステップは、従来の電子メールの送受機構が備えていないことは明らかであるから、新たに作成されたプログラムにより行われるステップである。
　
　そして、上記ｃ．における「着信メールー覧への表示方法などは，メッセージ・ヘッダの“Ｘ−Ｆｏｒｍ”の記述をチェックすることにより，いろいろ工夫することが可能です。メールを読む処理のところで稟議書メールであることが判明したならば，通常のメール内容表示から分岐して稟議受信フォームを表示するようにします。
　稟議受信フォームへの内容表示は，先述のフォーマット化されたメッセージからの項目の拾い出しとテキスト・ボックスなどへの反映ということになります。メッセージ・ボディはテキストのブロックになっていますので，拾い出しはＢａｓｉｃで容易に行えます。
　参照表示された内容に対しては，決裁者は変更を加えることができないようにしておきます。図８のようにして書き換えられたくないコントロールへの入力を無視して，不用意に表示内容が変わらないようにします。表示されている稟議内容に対する決裁者のアクションは，「決裁」，「保留」，「否決」のいずれかを選択することと「意見」を書き込むことです。また，それまでに回覧がすんでいる人が記入した意見を参照することができるようになっています。」の記載にあるように、引用例１に記載されたものは、送られてきたメッセージに“Ｘ−Ｆｏｒｍ”という拡張キーワードがヘッダに追加されているときに、ＡＶＥ−ＭＡＩＬのクライアントが、その拡張キーワードにしたがった処理を行うステップを有していることがわかる。またこの処理は、従来の電子メールの送受機構が備えていないことは明らかであるから、新たに作成されたプログラムにより行われている処理であると認められる。
　
　加えて、上記ｄ．における「決裁者が入力した情報は，起案者からのメッセージと合わせて再びフォーマット化して，「次」のメンバーに転送することになります。この部分は起案者からの送信のときと同様に，ルーティング・パスを記述した配列を参照して，現在ログインしているユーザーＩＤをもとに，次の送付先を割り出して送信構造体にセットして送信します（図９）。」の記載から、引用例１に記載されたものは、送られてきたメッセージに“Ｘ−Ｆｏｒｍ”という拡張キーワードがヘッダに追加されているときに、その拡張キーワードにしたがった処理を実行した後、その実行結果を起案者からのメッセージと合わせて再びフォーマット化を行っていることがわかる。そして、このフォーマット化は、起案者から送られたメッセージのメッセージ・ヘッダに“Ｘ−Ｆｏｒｍ”が記載されている場合、その記載にしたがった処理の結果を、電子メールの送受機構を使って送るためのフォーマット化であることは明らかであるし、また、このフォーマット化の処理を、電子メールの送受機構が備えているとは認められないから、この処理は、新たに作成されたプログラムにより行われている処理であると認められる。
　
　そして、このフォーマット化したメッセージは、送信されているが、この送信は従来の電子メールの送受機構が行っていることは明らかであり、また、そのためには、新たに作成されたプログラムから、このフォーマット化した情報を従来の電子メールの送受機構に渡さなければならないことも明らかである。
　
　以上ａ．〜ｄ．の記載から、引用例１には以下の発明（以下、「引用例１発明」という。）が記載されている。
　
　入力したメッセージをフォーマット化し送信するとともに、送られてきたメッセージを電子メールのメッセージとしてあつかう、従来の電子メール授受の機構を有するＡＶＥ−ＭＡＩＬのクライアントで、送られてきたメッセージに対して所定の処理を実行するクライアント・アプリケーションにおいて、
　メッセージをあつかうＡＶＥ−ＭＡＩＬのクライアントの授受の機構が、従来の電子メールの授受の機構をそのまま使い、電子メールのメッセージとして着信処理を行うステップと
　ＡＶＥ−ＭＡＩＬのクライアントが、新たに作成されたプログラムにしたがって、送られてきたメッセージに“Ｘ−Ｆｏｒｍ”という拡張キーワードがヘッダに追加されているかどうかチェックするステップと、
　送られてきたメッセージに“Ｘ−Ｆｏｒｍ”という拡張キーワードがヘッダに追加されているときに、新たに作成されたプログラムにしたがって、ＡＶＥ−ＭＡＩＬのクライアントが、その拡張キーワードにしたがった処理を行うステップ
　その処理の実行結果を、新たに作成されたプログラムにしたがって、従来の電子メールの授受機構を使って送るためのフォーマット化を行うステップと、
　フォーマット化された結果を、新たに作成されたプログラムから従来の電子メールの授受機構に渡すステップと、
　従来の電子メールの送受信機構が渡された結果を送信するステップ
　を備えた、クライアント・アプリケーション。
　
（２）本願出願日前に頒布された刊行物である“ＮＥＴ　ＷＯＲＴＨ（１５）　メールヘッダ”、ＵＮＩＸ　ＭＡＧＡＺＩＮＥ、第９巻　第３号、株式会社アスキー、１９９４年３月、ｐ．１５０−１５７（以下、「引用例２」という。）には次の事項が記載されている。
　
ｅ．「メッセージ内容の構造またはフォーマットが明確に定義されていないと、メールプログラム（ＵＡ）はメッセージの中身を正しく認識できない。フォーマットの統一しようがなければ、メールプログラムはほかのメールプログラムが生成したメールを正しく読み込んだり、転送したりできないからだ。インターネットの標隼は、ＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｆｏｒ−ｍａｔｉｏｎ　Ｃｅｎｔｅｒ）が発行している各種のＲＦＣ（Ｒｅｑｕｅｓｔ　Ｆｏｒ　Ｃｏｍｍｅｎｔｓ）にまとめられている。インターネットのメールメッセージのフォーマットはＲＦＣ８２２［１］に、ＳＭＴＰ自体はＲＦＣ８２１［２］で規定されている。この２つのＲＦＣか発行されたのは１９８２年である。
　・・・　（中　略）　・・・
　転送プロトコル（ＳＭＴＰ）とメッセージ・フォーマット（ＲＦＣ８２２）の分離には、いくつかの利点がある。明らかな利点は、メッセージの内容を拡張／変更しても、転送メカニズム自体に影響をおよぼさないことである。」（第１５１頁右欄５行〜２４行）
　
ｆ．「標準で定義されているフィールドのほかに、ユーザーが定義したフィールド名も利用できる。これは、ＲＦＣ８２２やこれを拡張するその他のＲＦＣのなかで定義されているもの（たとえば、ＲＦＣ１０４９［５］では“Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：”というヘッダが追加されている）と重複しないかぎり、どのような名前でもよい。注意が必要なのは、これらのフイールド名に重複があってはならないことと、現時点では重複がなくても新たな拡張が正式に採用されたとき、その名前が規定されるおそれがあることだ。したがって、ユーザーがフィールド名を定義する場合は、名前を“Ｘ−”で始めるほうがよい。Ｘ−で始まる名前はユーザー定義のフィールド名として予約されているため、将来にわたって重複するようなことはない。図３は、Ｍｉｃｒｏｓｏｆｔ　Ｍａｉｌプログラムがユーザー定義の“Ｘ−Ｍｓｍａｉｌ”というフィールドをメールメッセージに挿入しだ列である。」（第１５５頁左欄２５行〜右欄１３行）
　
　上記ｅ．にあるように、インターネットのメールメッセージのフォーマットはＲＦＣ８２１で規定されており、メッセージの内容を拡張／変更しても転送メカニズム自体に影響をおよぼさないことは、周知技術（以下、「周知技術１」という。）である。
　
　さらに、上記ｆ．にあるように、ＲＦＣ８２１では、メッセージフィールドの拡張を“Ｘ−”で行うことにより、ユーザ定義のフィールド名とすることも、周知技術（以下、「周知技術２」という。）である。
　
（３）また、本願出願日前に頒布された刊行物である　吉村伸、“インターネットの利用と仕組み５　電子メール（その２）”、ＵＮＩＸ　ＭＡＧＡＺＩＮＥ、第８巻　第９号、株式会社アスキー、１９９３年９月、ｐ．４９−５７（以下、「引用例３」という。）には次の事項が記載されている。
　
ｇ．「今回のもっともホットな話題は、ＲＦＣ１３４２に記述されている方法がヘッダに日本語を用いるのに使われはじめたことでしょう。７月１日から、ＮＩＦＴＹ−ＳｅｒｖｅとＷＩＤＥとのゲートウェイで、この方式によるエンコーティングが使われるようになり、ＮＩＦＴＹ−Ｓｅｒｖｅからの電子メールのＳｕｂｊｅｃｔやＦｒｏｍ行に、日本語が正しく入るようになりました１。ただし、これをサポートしていないメールシステムでは暗号のような文字列が現れます。」（第４９頁左欄２行〜９行）
　
ｈ．「ＲＦＣ１３４２による電子メールヘッダの多国語化
　まずは、地味なほうからさきにとりあげます。
　ＲＦＣ８２２とＲＦＣ１３４２で電子メールのヘッダに関する規定がおこなわれていて、ヘッダにはＵＳ−ＡＳＣＩＩしか使えないことになっています。ＵＳ−ＡＳＣＩＩ５は、いわゆるＡＳＣＩＩコードのうちの、７ビットで表現できる印字可能な部分です。
　題名に相当するＳｕｂｊｅｃｔや人名には自国語を用いたいと思うのは、日本以外でもアジアの多くの国々やヨーロッパ各国でも同じでしょう。これを解決する方法がＲＦＣ１３４２６によって提案されています。
　ヘッダのエンコーディングには“Ｑ−ｅｎｃｏｄｉｎｇ”と“Ｂ−ｅｎｃｏｄｉｎｇ”の２通りがあります。メールのボディパートを規定する、ＲＦＣ１３４１（ＭＩＭＥ）の“ｃｏｎｔｅｎｔ−ｔｒａｎｓｆｅｒ−ｅｎｃｏｄｉｎｇ”の“Ｑｕｏｔｅｄ−Ｐｒｉｎｔａｂｌｅ”とＢＡＳＥ６４をそれぞれのヘッダに適用したものです。
　Ｑｕｏｔｅｄは、ほとんどがＵＳ−ＡＳＣＩＩで表せるがほんのすこし違う文字がある場合に使うもので、ＩＳＯ−８８５９−＊シリーズのコードセットで使うことを目的にしています。
　これに対し、Ｂ−ｅｎｃｏｄｉｎｇはビット列とみなして６ビット単位でエンコードするもので、ＵＳ−ＡＳＣＩＩとかけ離れたコードセットで用います。したがって、日本語の場合はＢ−ｅｎｃｏｄｉｎｇを使うことになります。
　エンコードされた文字列は次のように表記します。
　
＝？ｃｈａｒｓｅｔ？Ｂｅｎｃｏｄｅｄ−ｓｔｒｉｎｇｓ？＝
　
　最初の“＝？”に続けて、ｃｈａｒｓｅｔ名がきます。ここにくるｃｈａｒｓｅｔ名はＩＡＮＡ７に登録されてあるもので、ＵＳ−ＡＳＣＩＩ、ＩＳＯ−８８５９−１、−２、・・・・・・、ＩＳＯ−２０２２−ＪＰ８などです。次の“？”の後ろにエンコーディング形式（ＱまたはＢ）、エンコード文字列が続き、“？＝”がエンコード文字列の終りを示します。たとえば、
　
＝？ＩＳＯ−２０２２−ＪＰ？Ｂ？ＧｙＲＡＲｎｘＬＸＤｈｓＧｙｈＫ？＝
　
というエンコード文字列があり、これをテコードすると、
　
日本語
　
のようになります。
　ＷＩＤＥプロジェクトの実験であるＮＩＦＴＹ−Ｓｅｒｖｅとの電子メールの交換でも、７月１日よりＢ−ｅｎｃｏｄｉｎｇを使い始めました。現在ＮＩＦＴＹ−Ｓｅｒｖｅから送られてくる電子メールは、図２のようになっています。
　この日本語ヘッダを利用できるメールプログラムは、現在ＭＨ−６．８−ＪＰ．２ｂとｍｅｔａｍａｉｌがあります。両方ともＭＩＭＥに対応するためのプログラムてす（詳細は後述）。」（第５２頁左欄２６行〜右欄３３行）
　
　上記ｇ．には、日本語のヘッダを用いた電子メールが日本語のヘッダに対応していないメールシステムに送られると、メールシステムは日本語のヘッダを処理することにより、暗号のような文字列として表示することが示されている。
　さらに、上記ｈ．及び第５３頁の図２には、前記暗号のような文字列（具体的には、「＝？ＩＳＯ−２０２２−ＪＰ？Ｂ？ＧｙＲＡＲｎｘＬＸＤｈｓＧｙｈＫ？＝」）を処理可能なメールプログラムでは「日本語」と表示され、処理ができないメールプログラムでは「＝？ＩＳＯ−２０２２−ＪＰ？Ｂ？ＧｙＲＡＲｎｘＬＸＤｈｓＧｙｈＫ？＝」と表示されることが示されている。
　
　また、この電子メールはＲＦＣにより規定されている規定にのっとっていることからインターネットのメールということができる。
　
　そうすると、メッセージの拡張を行ったインターネットのメールを受け取ったときに、その拡張に対応していないメールプログラムは、メッセージの拡張を従来のメールとして処理することは周知技術（以下、「周知技術３」という。）であることがわかる。
　
４．対比
　本願発明と引用例１発明を対比すると、
　
　引用例１発明の「入力したメッセージ」は、データの一種であり、入力されていることには変わりないことから、本願発明の「入力されたデータ」に相当する。
　また、引用例１発明の「フォーマット化」とは、従来の電子メールの授受機構が扱えるようにすることであるから、授受のためのプロトコルに変換することであり、してみると、本願発明の「所定のプロトコル」を用いることに相当する。
　そして、引用例１発明の「従来の電子メールの授受機構」とは、ＡＶＥ−ＭＡＩＬのクライアント・アプリケーションが従来から備えているプログラムにより実現された機構であるから、本願発明の「基本的機能を有する基本機能プログラム」に相当する。
　加えて、引用例１発明の「ＡＶＥ−ＭＡＩＬのクライアント」は、データ処理を行う装置であることには変わりないことから、本願発明の「データ処理装置」に相当する。
　さらに、引用例１発明の「クライアント・アプリケーション」は、送られてきたメッセージに対して所定の処理を実行していることから、本願発明の「伝送されてきた所定のデータに対して所定の処理を実行するデータ処理方法」と同様の処理を行っていると認められる。
　そうすると、引用例１発明の「入力したメッセージをフォーマット化し送信するとともに、送られてきたメッセージを電子メールのメッセージとしてあつかう、従来の電子メール授受の機構を有するＡＶＥ−ＭＡＩＬのクライアントで、送られてきたメッセージに対して所定の処理を実行するクライアント・アプリケーション」は、本願発明の「入力された入力データを所定のプロトコルを用いて送信するとともに、伝送されてきたデータを前記所定のプロトコルを用いて受信する基本的機能を有する基本機能プログラムにしたがって処理を行うデータ処理装置で、伝送されてきた所定のデータに対して所定の処理を実行するデータ処理方法」に相当する。
　
　そして、引用例１発明の「メッセージをあつかうＡＶＥ−ＭＡＩＬのクライアントの授受の機構が、従来の電子メールの授受の機構をそのまま使い、電子メールのメッセージとして着信処理を行うステップ」は、本願発明の「データを伝送する前記データ処理装置の通信手段が、前記基本機能プログラムにしたがって、前記所定のプロトコルを用いて伝送されてきたデータを受信する受信ステップ」に相当する。
　
　加えて、引用例の１発明の「新たに作成されたプログラム」は、従来の電子メールの授受機構が受けたメッセージを従来の電子メールの授受機構が備えていない処理を行うためのものであるから、本願発明の「前記基本機能プログラムから取り込んだデータに対して所定の処理を行う拡張機能を有する拡張機能プログラム」に相当する。
　また、引用例１発明の「送られてきたメッセージに“Ｘ−Ｆｏｒｍ”という拡張キーワードがヘッダに追加されているかどうかチェックする」ことは、「“Ｘ−Ｆｏｒｍ”という拡張キーワードが」が、本願発明の「特定のデータ」に相当することから、本願発明の「前記受信ステップで受信されたデータ中に特定のデータが含まれているかを検出する」ことに相当する。
　そうすると、引用例１発明の「ＡＶＥ−ＭＡＩＬのクライアントが、新たに作成されたプログラムにしたがって、送られてきたメッセージに“Ｘ−Ｆｏｒｍ”という拡張キーワードがヘッダに追加されているかどうかチェックするステップ」を行うためには、「ＡＶＥ−ＭＡＩＬのクライアントが」「新たに作成されたプログラム」を有していることが必要なことは当業者であれば明らかであるから、引用例１発明の「ＡＶＥ−ＭＡＩＬのクライアントが、新たに作成されたプログラムにしたがって、送られてきたメッセージに“Ｘ−Ｆｏｒｍ”という拡張キーワードがヘッダに追加されているかどうかチェックするステップ」は、本願発明の「前記データ処理装置が、前記基本機能プログラムから取り込んだデータに対して所定の処理を行う拡張機能を有する拡張機能プログラムを有している場合、前記拡張機能プログラムにしたがって、前記受信ステップで受信されたデータ中に特定のデータが含まれているかを検出する検出ステップ」に相当する。
　
　さらに、引用例１発明の「送られてきたメッセージに“Ｘ−Ｆｏｒｍ”という拡張キーワードがヘッダに追加されているときに、新たに作成されたプログラムにしたがって、ＡＶＥ−ＭＡＩＬのクライアントが、その拡張キーワードにしたがった処理を行うステップ」は、本願発明の「前記受信ステップで受信されたデータ中に前記特定のデータが検出されたとき、前記データ処理装置が、前記拡張機能プログラムにしたがって、前記特定のデータに対応する処理を実行する実行ステップ」に相当する。
　
　そして、引用例１発明の「その処理の実行結果を、新たに作成されたプログラムにしたがって、従来の電子メールの授受機構を使って送るためのフォーマット化を行うステップ」は、本願発明の「前記データ処理装置が、前記拡張機能プログラムにしたがって、前記特定のデータに対応する処理を実行して得られた結果を、前記基本機能プログラムの入力データに変換する変換ステップ」に相当する。
　
　また、引用例１発明の「フォーマット化された結果を、新たに作成されたプログラムから従来の電子メールの授受機構に渡すステップ」は、本願発明の「前記データ処理装置が、前記拡張機能プログラムにしたがって、前記基本機能プログラムの入力データに変換されたデータを前記拡張機能プログラムから前記基本機能プログラムに渡す処理ステップ」に相当する。
　
　さらに、引用例１発明の「従来の電子メールの送受信機構が渡された結果を送信するステップ」の、「結果を送信する」ことは、送信するためにはフォーマット化を行う必要があることから、本願補正発明の「所定のプロトコルで伝送する」ことに相当し、さらに、引用例１発明では、送受信には「従来の電子メールの授受機構」が使われていることから、引用例１発明の「従来の電子メールの送受信機構が渡された結果を送信するステップ」は、本願補正発明の「前記データ処理装置の前記通信手段が、前記基本機能プログラムにしたがって、前記拡張機能プログラムから前記基本機能プログラムに渡されたデータを前記所定のプロトコルで伝送する伝送ステップ」に相当する。
　
　してみると両者は次の点で一致する。
　
（一致点）
　入力された入力データを所定のプロトコルを用いて送信するとともに、伝送されてきたデータを前記所定のプロトコルを用いて受信する基本的機能を有する基本機能プログラムにしたがって処理を行うデータ処理装置で、伝送されてきた所定のデータに対して所定の処理を実行するデータ処理方法において、
　データを伝送する前記データ処理装置の通信手段が、前記基本機能プログラムにしたがって、前記所定のプロトコルを用いて伝送されてきたデータを受信する受信ステップと、　前記データ処理装置が、前記基本機能プログラムから取り込んだデータに対して所定の処理を行う拡張機能を有する拡張機能プログラムを有している場合、前記拡張機能プログラムにしたがって、前記受信ステップで受信されたデータ中に特定のデータが含まれているかを検出する検出ステップと、
　前記受信ステップで受信されたデータ中に前記特定のデータが検出されたとき、前記データ処理装置が、前記拡張機能プログラムにしたがって、前記特定のデータに対応する処理を実行する実行ステップと、
　前記データ処理装置が、前記拡張機能プログラムにしたがって、前記特定のデータに対応する処理を実行して得られた結果を、前記基本機能プログラムの入力データに変換する変換ステップと、
　前記データ処理装置が、前記拡張機能プログラムにしたがって、前記基本機能プログラムの入力データに変換されたデータを前記拡張機能プログラムから前記基本機能プログラムに渡す処理ステップと、
　前記データ処理装置の前記通信手段が、前記基本機能プログラムにしたがって、前記拡張機能プログラムから前記基本機能プログラムに渡されたデータを前記所定のプロトコルで伝送する伝送ステップと、
　を具備することを特徴とするデータ処理方法。
　
　一方、両者次の点で相違する。
　
（相違点１）
　本願補正発明は、「前記データ処理装置が、前記拡張機能プログラムを有していない場合、前記基本機能プログラムから取り込んだデータに対して、前記基本機能プログラムにしたがって、所定の処理を実行する実行ステップ」を具備しているのに対して、引用例１発明では「前記データ処理装置が、前記拡張機能プログラムを有していない場合」についての記載がない点。
　
（相違点２）
　本願補正発明は、「前記データ処理装置の前記通信手段が、前記基本機能プログラムにしたがって、所定の処理を実行して得られた結果を、前記所定のプロトコルで伝送する伝送ステップ」を具備しているのに対して、引用例１発明では「前記基本機能プログラムにしたがって、所定の処理を実行して得られた結果」についての明示がない点。
　
５．相違点に関する当審判断
（相違点１）に関して
　引用例１　ｂ．における「ＡＶＥ−ＭＡＩＬのメールのメッセージの形式は，ＵＮＩＸメールのものを踏襲していて図４のようになっています。このメッセージ・ボディの部分に稟議書の内容を盛り込めば一応使えるようになるわけですが，一般の電子メールと区別して読書きできれば効率がよいので，ヘッダのほうにちょっとした仕掛けがあります。“Ｘ−Ｆｏｒｍ”という拡張キーワードをヘッダに追加してあり，これによってメッセージの種類を識別できるようになっています。」の記載にあるように、引用例１発明のＡＶＥ−ＭＡＩＬは、ＲＦＣ８２１にしたがったＵＮＩＸメールの形式を踏襲しており、さらに、拡張キーワード“Ｘ−Ｆｏｒｍ”はＸ−から始まることから、周知技術２に基づく拡張であることがわかる。
　そのとき、周知技術３にあるように、引用例１発明においても、メッセージの拡張を行ったインターネットのメールを受け取ったときに、その拡張に対応していない場合は、メッセージの拡張を従来のメールとして処理することは、当然行われているから、引用例発明も「前記データ処理装置が、前記拡張機能プログラムを有していない場合、前記基本機能プログラムから取り込んだデータに対して、前記基本機能プログラムにしたがって、所定の処理を実行する実行ステップ」を有していると認められる。
　
（相違点２）に関して
　周知技術１にあるように、メッセージの内容を拡張／変更しても転送メカニズム自体に影響をおよぼさないことから、引用例１発明においても「前記データ処理装置の前記通信手段が、前記基本機能プログラムにしたがって、所定の処理を実行して得られた結果を、前記所定のプロトコルで伝送する伝送ステップ」を有することは当業者が適宜行っていると認められる。
　
　そして、本願発明の作用効果は、引用例１及び周知技術から当業者が予測できる範囲のものである。
　
　したがって、本願発明は、引用例１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
６．むすび
　以上のとおり、本願発明は、引用例１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。