【事件の表示】
　特願２０００−　３４０２１「短文メッセージサービスを使用するデータ転送プロトコル」拒絶査定不服審判事件〔平成１２年　９月　８日出願公開、特開２０００−２４４５５７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年２月１０日の出願（パリ条約による優先権主張１９９９年２月１３日、（ＫＲ）大韓民国）の出願であって、平成１３年１１月１２日付けで拒絶査定がなされ、これに対し、平成１４年２月１８日に拒絶査定に対する審判請求がなされるとともに平成１４年３月２０日付けで手続補正がなされ、平成１６年７月５日付けで審尋がなされ、平成１６年１０月６日に回答書が提出されたものである。
 　　
２．平成１４年３月２０日付けの手続補正についての検討
［結論］
　　平成１４年３月２０日付けの手続補正を却下する。
　
［理由］
（２−１）補正後の本願請求項１に記載された発明
　本件補正により、特許請求の範囲の請求項１は、
「【請求項１】短文メッセージサービスを使用するデータ転送プロトコルにおいて、
　（ａ）ユーザデータフィールドにデータ連結サービス識別子を挿入する段階と、
　（ｂ）入力されたメッセージデータを複数個の短文メッセージデータフィールドに分割して、前記ユーザデータフィールドに分割された短文メッセージデータフィールドと、分割された短文メッセージの総数を表示するフィールド及び現在の短文メッセージの番号を表示するフィールドを挿入する段階と、
　（ｃ）前記ユーザデータフィールドを使用して短文メッセージフィールドを生成する段階と、
　（ｄ）前記短文メッセージフィールドを転送する段階と、
　（ｅ）前記データ連結サービス識別子の直後に、データ連結サービスの種類を参照するための番号を表示する参照番号フィールドを挿入する段階と、を含むことを特徴とするデータ転送プロトコル。」と補正された。
　上記補正は、「データ転送プロトコル」の一つの段階として、「（ｅ）前記データ連結サービス識別子の直後に、データ連結サービスの種類を参照するための番号を表示する参照番号フィールドを挿入する段階」を付加し、「データ転送プロトコル」を限定したものであり、特許請求の範囲の請求項１は、減縮を目的とするものに該当し、特許法第１７条の２第４項第２号に適合する。また、上記補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内になされたものであるから、特許法第１７条の２第３項の規定に適合している。
　
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際、独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第４項の規定に適合するか）について以下に検討する。
　
（２−２）引用例に記載された発明
　原審の拒絶の理由に引用された特開平８−７９８１５号公報（以下、「引用例」という。）には、次のような記載がある。
　
イ）「【請求項１】メッセージデータを複数回に分けて送信するメッセージデータの送信方法であって、
　最初の送信では、前記メッセージデータの先頭部のデータと続きのデータがあることを示す第１のコードとを送信し、
　第２の送信では、送信済みデータに続くデータとこのデータが先に送信されたデータからの続きのデータであることを示す第２のコードとを送信し、
　第２の送信が最後の送信であれば、送信済みデータに続くデータ、第１のコード及び第２のコードを送信することを特徴とするメッセージデータの送信方法。
　【請求項２】所定の通信システムで許容されているデータ送信量より多いメッセージを送信するメッセージデータの送信方法において、
　送信用メッセージを入力する際に、前記許容データ送信量を越える入力範囲を明示し、
　この明示した入力範囲を越えて入力されるデータからなるメッセージデータを送信する際には、前記メッセージデータを複数に分け且つその各々に連結関係を示す連結情報を付加して送信するようにしたことを特徴とするメッセージデータの送信方法。」（第２頁第１欄第２行〜第２２行）
　
ロ）「【００８３】以上のように、本実施例の電子機器２１では、データ通信システムとしてのページングシステムで許容されるデータ送信量（２０桁分）を越えるフリー伝言メッセージを送信先ページャーに送信する場合は、そのフリー伝言メッセージを入力する過程で９文字以降をマスク表示しているため、ユーザーに一回で送信されるメッセージ量を明確に指示することができる。
　【００８４】また、送信先ページャーの電話番号と送信用メッセージを連結して分割送信する際には、８文字単位での送信用メッセージの送信が終了する毎に、次のダイヤルキー３９の操作だけで送信先ページャーへの発呼を自動的に実行しているため、送信側では分割送信するフリー伝言メッセージを送信する度に、送信先の電話番号のダイヤル操作を行う必要がなくなり、フリー伝言を送信する際の操作性を改善することができる。
　【００８５】また、８文字単位で送信済みの送信用メッセージ部をマスク表示して、分割送信の状態を明確に表示するとともに、その分割送信するフリー伝言メッセージデータの連結関係を示す連結情報である続きコードや連結コードを付加して送信しているため、送信側で分割送信するメッセージを逆順に送信するといった手間を省略することができ、送信側の送信処理を簡略化することができる。
　【００８６】次に、本実施例の電子機器２１の受信装置としての動作を図１７に示すフローチャートを参照して説明する。アンテナ４１及び受信回路４２を通して受信した呼出信号のＩＤコードが自己のＩＤコードであることがデコーダ４３で検出され、その検出結果がＣＰＵ４６に通知されると、ＣＰＵ４６は、着信データ処理を開始し、デコーダ４３でデコードされて入力される着信データ（着信メッセージデータ）を取込み（ステップＳ５１）、その着信データの先頭に続きコードが有るか否かを検索する（ステップＳ５２）。すなわち、送信データの呼出ＩＤコードがＩＤ−ＲＯＭ４４に記憶の自己のＩＤコードと一致すると、この呼出ＩＤコードに続く送信データを受信バッファ５０にストアした後、上記図１５に示したフリー伝言メッセージデータ中の先頭に“　７”が有るか否かを検索する。
　【００８７】先頭に続きコードがない時は、末尾に連結コード“−”が付加されているか否かを検出する（ステップＳ５３）。連結コード“−”が付加されている時は、すなわち、受信したメッセージデータが図１６の（ａ）に示したデータである時は、ＣＰＵ４６内の連結タイマをクリアしてスタートし（ステップＳ５４）、受信したメッセージデータを、図６に示した受信メッセージメモリ５１内のデータが記憶されていないメモリバンクＭi1(ｉは１〜ｎのいずれか）に記憶する（ステップＳ５５）。次いで、連結タイマがタイムアップしたか否かを判別し（ステップＳ５６）、タイムアップしていれば、連結すべき後続するメッセージデータの受信待ち受けを中止して着信報知信号を報知信号発生部５７に出力し、スピーカ５８から報知音を出力させ（ステップＳ５７）、本処理を終了する。連結タイマがタイムアップしていない時は、さらに、着信が有るか否かを検出する（ステップＳ５８）。着信がない時は、ステップＳ５６のタイムアップ判別処理に戻り、着信が有る時は、ステップＳ５１の着信データの取り込み処理に戻る。
　【００８８】一方、ステップＳ５３で末尾に連結コード“−”が付加されていない時は、すなわち、受信したメッセージデータが図１６の（ｄ）に示したデータである時は、その受信したメッセージデータを、受信メッセージメモリ３１内のデータが記憶されていないメモリバンクＭj1（ｊは１〜ｎのいずれか）に記憶する（ステップＳ５９）。続いて、着信報知信号を報知信号発生部５７に出力し、スピーカ５８から報知音を出力させ（ステップＳ５７）、本処理を終了する。
　【００８９】また、ステップＳ５２で着信したメッセージデータの先頭に、続きコード“７”が付加されている時は、末尾に連結コード“−”が付加されているか否かを検索し（ステップＳ６０）、連結コード“−”が付加されている時は、すなわち、受信したメッセージデータが図１６の（ｂ）に示したデータである時は、連結タイマをスタートさせる（ステップＳ６１）。次に、受信メッセージメモリ５１内に連結が完了していない末尾に連結コードが付加されている連結待機データが有るか否かを判別し（ステップＳ６２）、すなわち、先に受信して受信メッセージメモリ５１内のメモリバンクＭ11〜Ｍn3のいずれかにに記憶したメッセージデータに続くメッセージデータか否かを判別する。連結待機データがない時は、ステップＳ５５で別の新たな空きメモリバンクＭk1（ｋは１〜ｎのいずれか）に記憶し、連結待機データが有る時は、先の受信でメッセージデータを記憶しているメモリバンク（例えば、Ｍi1）に続く連結メッセージ記憶用のメモリバンク（例えば、Ｍi2）に、今回の受信メッセージデータを記憶し、先の受信メッセージに連結する（ステップＳ６３）。
　【００９０】次いで、連結タイマがタイムアップしたか否かを判別し（ステップＳ５６）、タイムアップしていれば、連結すべき後続するメッセージデータの受信を待ち受け中止して着信報知信号を報知信号発生部５７に出力し、スピーカ５８から報知音を出力させ（ステップＳ５７）、本処理を終了する。連結タイマがタイムアップしていない時は、さらに、着信が有るか否かを検出する（ステップＳ５８）。着信がない時は、ステップＳ５６のタイムアップ判別処理に戻り、着信が有る時は、ステップＳ５１の着信データの取り込み処理に戻る。
　【００９１】また、ステップＳ６０で末尾に連結コード“−”が付加されていない時は、すなわち、受信したメッセ−ジデ−タが図１６の（ｃ）に示したデ−タである時は、受信メッセージメモリ５１内に連結が完了していない末尾に連結コードが付加されている連結待機データが有るか否かを判別し（ステップＳ６２）、すなわち、先に受信して受信メッセージメモリ５１内のメモリバンクＭ11〜Ｍn3のいずれかに記憶したメッセージデータに続くメッセージデータか否かを判別する。連結待機データがない時は、ステップＳ５９で別の新たな空きメモリバンクＭl1（ｌは１〜ｎのいずれか）に記憶し、連結待機データが有る時は、先の受信でメモリバンク（例えばＭi2）に続く連結メッセ−ジ記憶用のメモリバンク（例えばＭi3）に今回の受信フリー伝言メッセージデータを記憶し、先の受信メッセ−ジに連結する（ステップＳ６５）。
　【００９２】次いで、連結タイマをストップし（ステップＳ６６）、着信報知信号を報知信号発生部５７に出力し、スピーカ５８から報知音を出力させ（ステップＳ５７）、本処理を終了する。以上の着信処理により分割送信された複数のメッセ−ジデ−タは受信メッセージメモリ５１内の同一グル−プのメモリバンクＭi1，Ｍi2，Ｍi3（ｉは１〜ｎのいずれか）に記憶され、且つその付加された連結情報に基づいて連結されるため、表示部６１に表示する際には、従来のように、逆順には表示されず正順に表示される。
　【００９３】以上のように、分割送信されるメッセージの着信処理の実行においては、メッセージの着信毎に報知を行わず、全てのメッセージの着信完了後に報知を行うようにし、また、分割受信したメッセージは、連結情報により正しい順番で記憶して表示するようにしたため、着信毎の報知音が煩わしいという事態を回避することができるとともに、メッセージ内容を容易に把握することができる。
　【００９４】なお、上記実施例では、送信用メッセージがフリー伝言メッセージである場合について説明したが、数値データのみからなる通常のメッセージの場合も同様に処理できることは勿論である。この場合、連結コ−ド及び続きコ−ドは、通常、メッセ−ジとしては使用されることのない記号デ−タの組合わせで定義すればよい。例えば、図２に示した記号デ−タ［“を２個連続させたものを連続コ−ド、記号デ−タ”］”を２個連続させたものを続きコ−ドとして定義すればよい。図１８の（ａ）〜（ｃ）はそれぞれ、このように定義された連結コ−ド及び続きコ−ドを用いてメッセ−ジデ−タを分割送信する際に、最初に送信されるデ−タの構成、２番目に送信されるデ−タの構成、３番目に送られるデ−タの構成を示したものである。
　【００９５】次に、図１９〜図２３を参照して本発明の第２実施例を説明する。本実施例は、送信側がメッセ−ジを分割して送信する際、分割して送信する各メッセ−ジに送信者を識別する情報を付加して送信し、受信側では、受信したメッセ−ジが分割して送信されたメッセ−ジの１つである場合、そのメッセ−ジに付加されている送信者識別情報に基づいて、同一の送信者から分割して送信された他のメッセ−ジに連結するようにしたものである。本実施例においても、メッセ−ジを送信する装置及びメッセ−ジを受信する装置は、第１実施例と同様、ト−ンダイヤラ機能とペ−ジャ−機能とを有する電子機器を例に説明する。」（第１１頁第１９欄第１３行〜第１２頁第２２欄第１８行）
　
　上記記載を総合し、技術常識を勘案すると、引用例には、
「ページングシステムを使用して、メッセージを複数回に分けて送信するメッセージデータの送信方法であって、
最初の送信では、前記メッセージデータの中に、前記メッセージデータの先頭部のデータと続きのデータがあることを示す第１のコードとを送信し、メッセージデータが、許容データ送信量を越える場合、メッセージデータを複数に分け、且つその各々に連結関係を示す連結情報を付加して、メッセージデータを送信するメッセージデータの送信方法」の発明が記載されているものと認められる。（以下、「引用例に記載された発明」という。）
　
　例えば、原審の拒絶の理由に引用された特開平１０−２００５７１号公報（以下、「周知例１」という。）には、次のような記載がある。
　　
イ）「【請求項７】　請求項１記載のデータ通信方法において、
　前記メッセージ送信工程は、
　メッセージを所定のサイズに分割する工程を有し、分割したメッセージに分割数および分割順序を付加して送信するものであり、
　前記中継工程は、
　受信メッセージから分割数および分割順序を特定し、特定した分割数および分割順序に基づいて、分割されたメッセージを合併する工程を備えていることを特徴とするデータ通信方法。」（第２頁第２欄第１行〜第１１行）
　
　例えば、米国特許５４４６６７８号（以下、「周知例２」という。）には、次の旨の記載がある。
　
イ）「結果としてできた７ビットデータ列は、複数のメッセージブロックに分割され、ページングネットワークにより、送信される。メッセージブロックのサイズは、ページングサービス提供者が、送信できる最大のメッセージサイズよりも小さくなければならない。なぜなら、ページングネットワークは、受信される順番で、送信されることは、保証しておらず、メッセージは、７ビットデータ列のメッセージの順序を示すヘッダが必要であるから。好ましくは、各メッセージはまた、送信されるメッセージの数を示す。こうして、７つのメッセージ列の３番目のメッセージは、そのヘッダに”３／７”を意味するコードを含めることができる。これは、受信側が、もし、少なくとも一つのメッセージを受信するなら、全てのメッセージを受信したかどうか決定することを可能にする。チェックサムは、各メッセージについて行われ、その結果は、ヘッダに含まれる。最後に、ヘッダが、通信の一番始めに、受信局に、メッセージ列を再構築して、一つのメッセージとして理解するよう指示するコードを含むようにすべきである。これは、ページング受信局が、この発明で意図した全てのページング同様、典型的なアルファベットと数字のページを受信できることを可能にする。」（第５欄第３６行〜第５７行）
　
　上記周知例１、周知例２によれば、「メッセージを分割した時、メッセージの総数とメッセージの番号を挿入して、送信する」ことは、周知である。
　
　例えば、特開平１０−２１５３２１号公報（以下、「周知例３」という。）には、次の事項が記載されている。
　
イ）「【００２４】ＧＳＭシステムのショートメッセージ・サービスＳＭＳによって、一度に最大で１６０文字の長さのメッセージを送ることが可能である。文字は７ビットのＡＳＣＩＩ（American National Standard Code for Information Interchange （情報交換用米国標準コード））文字であり、従って、ビットで表したメッセージの最大の長さは１、１２０ビット、即ち１４０バイトである。図３に示されているような普通の移動局は、小さなディスプレイと進歩したキーボードとを持っており、これによってショートメッセージを書くことができる、即ち、種々の文字や数字を入力することができる。図３に示されているように、受信されたメッセージは、文字や数字を表示することを可能にする移動局のディスプレイで表示される。
【００２５】周知のように、ＧＳＭシステムでは伝送情報はいくつかのフレームに分割されている。送信されるべきメッセージの長さがフレームＦＲの許容される最大長さより長いときには、メッセージＭは図４（Ａ）に示されているように、部分Ｍ１−Ｍ４に分割されて（セグメント化されて）数個のフレームＦＲ１−ＦＲ４で送られなければならない。受信時に、移動局は、図４（Ｂ）に示されているように、数個のフレームＦＲ１−ＦＲ４に分割されているメッセージＭを再構成する。無線インターフェース（図２）では、フレームの最大長さは通常は１６８又は１８４ビットであり、従って、ショートメッセージ（その最大長さは１、１２０ビットである）は数個のフレームに分割されなければならない。図５は、無線インターフェースで伝送されるフレーム、いわゆるＬＡＰＤｍフレーム（Link Access Protocol for the Dm channel （Ｄｍチャネル用リンクアクセス・プロトコル））を示しており、それは通常は３つのフィールドに分かれている。第１フィールドはアドレス・フィールドＡＤＤであり、これは、そのメッセージの宛先の、数個のバイトで表されたアドレス（すなわち受信側の移動局識別子）を含んでいる。ＧＳＭシステムでは、シグナリングメッセージも、対応するＬＡＰＤｍフレーム内で伝送される。無線通信では、同時に２つのメッセージの流れ（すなわちシグナリングメッセージ及びショートメッセージ）が互いに無関係に存在することがあり得る。その２つの異なる流れは、アドレス・フィールドＡＤＤに付加されるべきリンク識別子、即ちいわゆるＳＡＰＩ（Service Access Point Identifier （サービスアクセスポイント識別子））、によって互いに分離される。その値は、シグナリングを意味する３、又はショートメッセージを意味する０であることができる。第２フィールドは制御フィールドＣＴＲＬであり、このフィールドは送信フレーム番号Ｎ（Ｓ）及び受信フレーム番号Ｎ（Ｆ）を含んでいる。第３フィールドは、実際の情報を包含するデータフィールドＩＮＦＯであり、これは最大で１６８ビットの情報、即ち実際のショートメッセージの内容、を包含する。」（第６頁第９欄第１８行〜第１０欄第１８行）
　
　上記周知例３によれば、「移動局間でショートメッセージサービスを使用し、ショートメッセージは、アドレスフィールド、制御フィールド、データフィールドからなり、メッセージの長さがフレームの許容される最大長さより長い時は、分割すること」は、周知である。
　
（２−３）対比
　本願補正発明と引用例に記載された発明を対比する。
ａ．引用例に記載された発明の「メッセージデータの送信方法」は、データ転送の取り決めの一つであり、取り決めは、プロトコルのことであるから、本願補正発明の「データ転送プロトコル」に相当する。
ｂ．引用例に記載された発明の「続きのデータがあることを示す第１のコード」は、データの連結を示す識別子であるので、本願補正発明の「データ連結サービス識別子」に相当する。引用例に記載された発明の「前記メッセージデータの中に、・・・続きのデータがあることを示す第１のコードを送信」は、送信するときには、メッセージデータ、すなわち、データ部分に挿入を行っており、データ部分は、ユーザデータフィールドと言えるから、本願補正発明の「ユーザデータフィールドにデータ連結サービス識別子を挿入する段階」に相当する。
ｃ．引用例に記載された発明の「メッセージデータを送信する」と本願補正発明の「ユーザデータフィールドを使用して短文メッセージフィールドを生成する段階と前記短文メッセージフィールドを転送する段階」は、メッセージを送信するためには、データ部分を使用して、メッセージデータを生成し、転送しており、データ部分は、ユーザデータフィールドと言えるから、「ユーザデータフィールドを使用してメッセージを生成する段階と前記メッセージを転送する段階」の点で、一致する。
　
　してみれば、本願補正発明と引用例に記載された発明とは、
「データ転送プロトコルにおいて、
　ユーザデータフィールドにデータ連結サービス識別子を挿入する段階と、
　前記ユーザデータフィールドを使用してメッセージを生成する段階と、
　前記メッセージを転送する段階と、を含むデータ転送プロトコル」の点で、一致し、以下の点で、相違する。
　
相違点１
　本願補正発明では、短文メッセージサービスを使用し、入力されたメッセージデータを複数個の短文メッセージデータフィールドに分割して、前記ユーザデータフィールドに分割された短文メッセージデータフィールドと、分割された短文メッセージの総数を表示するフィールド及び現在の短文メッセージの番号を表示するフィールドを挿入する段階、短文メッセージフィールドを生成する段階と、前記短文メッセージフィールドを転送する段階を有しているのに対して、引用例では、ページングシステムを使用し、最初の送信では、前記メッセージデータの中に、前記メッセージデータの先頭部のデータと続きのデータがあることを示す第１のコードとを送信し、メッセージデータが、許容データ送信量を越える場合、メッセージデータを複数に分け、且つその各々に連結関係を示す連結情報を付加して、メッセージデータを送信する点。
　
相違点２
　本願補正発明では、「データ連結サービス識別子の直後に、データ連結サービスの種類を参照するための番号を表示する参照番号フィールドを挿入する段階」を有しているのに対して、引用例では、連結情報を付加しているが、参照番号フィールドを挿入することについての記載がない点。
　
（２−４）判断
　相違点について、判断する。
　
相違点１について
　引用例では、ページングシステムを使用して、メッセージデータが長い場合、複数のデータに分け、その各々に連結関係を示す連結情報を付加して、送信しているが、「メッセージを分割した時、メッセージの総数とメッセージの番号を挿入して、送信する」ことは、周知例１、２に示されるように周知であり、「移動局間でショートメッセージサービスを使用し、ショートメッセージは、アドレスフィールド、制御フィールド、データフィールドからなり、メッセージの長さがフレームの許容される最大長さより長い時は、分割すること」は、周知例３に示されるように周知であるから、引用例に記載された発明において、短文メッセージサービスを使用し、入力されたメッセージデータを複数個の短文メッセージに分割し、分割された短文メッセージの総数、短文メッセージの番号を挿入する段階と短文メッセージを生成する段階と、前記短文メッセージを転送する段階を設けることは、当業者が容易になし得ることと認められる。
　その際、データフィールドを如何なるフレーム構成にし、各フィールドを如何なる名称で呼称することは、当業者が適宜なすべきことであるから、ユーザデータフィールドを、分割された短文メッセージデータフィールド、分割された短文メッセージの総数を表示するフィールド、現在の短文メッセージの番号を表示するフィールドからなるようにすることは、当業者が適宜設定することである。
　
相違点２について
　引用例では、連結情報を付加することにより、データが、許容データ量を越える場合に対処しているが、データの種類がいかなるものかを示す場合、何らかの情報を付加して、データの種類を認識することは、例えば、特開平５−２４４０６１号公報【０００６】、【００１１】に示される周知技術であるから、引用例に記載された発明において、データ連結サービス識別子の直後に、データ連結サービスの種類を参照するための番号を表示する参照番号フィールドを設けることに、技術的困難性は認められない。
　なお、本願補正発明の「データ連結サービスの種類を参照するための番号」とは、出願人が、平成１３年１０月３１日に提出された意見書で、「分割されたデータを連結するにあたって、分割されたデータの種類、例えば、テキストデータ、イメージデータ、グラフィックデータのようなデータの種類を示すものと」定義しており、上記相違点２の判断にあたっては、上記の定義に従った。
　
　本願補正発明の作用効果も、引用例及び周知例１〜３に示される周知技術から当業者が予測できる範囲のものである。
　
　したがって、本願補正発明は、引用例及び周知例１〜３に示される周知技術に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　　
（３）むすび
　以上のとおり、本件補正は、特許法第１７条の２第５項で準用する同法第１２６条第４項の規定に適合しないものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。
　
３．本願発明
（１）本願発明について
　平成１４年３月２０日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明は、出願日である平成１２年２月１０日付けの特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「【請求項１】　短文メッセージサービスを使用するデータ転送プロトコルにおいて、
　（ａ）ユーザデータフィールドにデータ連結サービス識別子を挿入する段階と、
　（ｂ）入力されたメッセージデータを複数個の短文メッセージデータフィールドに分割して、前記ユーザデータフィールドに分割された短文メッセージデータフィールドと、分割された短文メッセージの総数を表示するフィールド及び現在の短文メッセージの番号を表示するフィールドを挿入する段階と、
　（ｃ）前記ユーザデータフィールドを使用して短文メッセージフィールドを生成する段階と、
　（ｄ）前記短文メッセージフィールドを転送する段階とを含むことを特徴とするデータ転送プロトコル。」（以下、「本願発明」という。）
　
（２）引用例に記載された発明
　引用例に記載された発明は、前記「２．（２−２）」に記載したとおりのものである。
　
（３）対比・判断
　本願発明は、前記２．で検討した本願補正発明から、「データ転送プロトコル」の限定事項である「（ｅ）前記データ連結サービス識別子の直後に、データ連結サービスの種類を参照するための番号を表示する参照番号フィールドを挿入する段階」を省いたものである。
　そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加した構成を有する本願補正発明が、前記「２．（２−４）」に記載したとおり、引用例に記載された発明及び周知例１〜３に示される周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例に記載された発明及び周知例１〜３に示される周知技術に基いて、当業者が容易に発明をすることができたものである。
　
（４）むすび
　以上のとおり、本願発明は、引用例に記載された発明及び周知例１〜３に示される周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。