【事件の表示】
　特願２００３−５２１５４６「伝送装置および伝送方法」拒絶査定不服審判事件〔平成１５年　２月２７日国際公開、ＷＯ０３／１７５７７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、２００２年８月６日（優先権主張２００１年８月９日、日本国）を国際出願日とする出願であって、平成２０年８月１３日付けで拒絶査定がなされ、これに対し、平成２０年９月１８日に拒絶査定に対する審判請求がなされるとともに、平成２０年１０月２０日付けで手続補正がなされたものである。
　
　本願の請求項７に係る発明（以下、「本願発明」という。）は、平成２０年１０月２０日付けの手続補正により補正された請求項７に記載された以下のとおりのものである。
　「優先して処理される優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットからなる受信パケットを受信する受信ステップと、
　前記受信パケットに格納されている異なるレイヤで生成された複数の通信プロトコルヘッダを同時に検査することにより前記優先パケットと前記非優先パケットとを選別する選別ステップと、
　前記選別された優先パケットと前記非優先パケットとをそれぞれ独立して処理するステップと、を有することを特徴とする伝送方法。」
　
２．引用例
　原査定の拒絶の理由に引用された特開平７−２７３７８９号公報（以下、「引用例」という。）には、図面とともに以下の記載がある。
　
　「【０００１】
【産業上の利用分野】本発明は、通信システム及び通信方法に関する。具体的には、特に音声，画像データなどのマルチメディア用データ及び緊急を要するプラント用データなどの遅延の許されない通信に好適なリアルタイム性が要求されるデータとその他の遅延がある程度許されるデータが混在する通信システム及び通信方法に関する。」（４頁５欄）
　
　「【００２４】〔実施例１〕
＜構成＞以下、第１の実施例について説明する。
【００２５】本発明の通信システムの優先通信制御方式の構成を図１に示す。通信システム内の各端末１４０等、通信システム内の業務処理を行う通信プログラム処理部１２０，プロトコル送信処理部１４１，プロトコル受信処理部１４３，通信装置１１１を介し通信網へのデータ送信処理部１２６，通信網からのデータ受信処理部（データ受信手段とも称す）１３０，送受信データの処理待ちキュー制御部１４２，１４４を有する。プロトコル送信処理部１４１は、ＴＣＰ／ＩＰプロトコル送信処理部１２１〜１２２から成り、プロトコル受信処理部１４３は、TCP／ＩＰプロトコル受信処理部１３４〜１３５から成る。送受信データの処理待ちキュー制御部１４２，１４４は、データを優先的に処理するか否かを決定するデータの優先判定手段１２３，１３１と、送受信処理待ちキュー１２７，１３６へ接続する手段１２４，１３２と、送受信処理待ちキュー１２４，１３２からデータを取り出す手段１２５，１３３から成る。更に、補助記憶装置１００に優先データ情報を記憶する優先データ情報登録ファイル１０１が設けられ、主記憶上に優先データ情報登録メモリ１０２，送信・受信処理上限登録ファイル１０３を配置し優先的に送受信するデータの優先データ情報をデータの優先判定手段１２３，１３１に知らせる。」（６頁１０欄）
　
　「【００３１】＜送信処理＞図１を用いて、通信プログラムから通信網へデータ送信するまでの処理を示す。通信プログラム処理部１２０から送信されたデータは、プロトコル送信処理部１４１のＴＣＰプロトコル処理部１２１でＴＣＰヘッダを付加し、次にＩＰプロトコル送信処理部１２２でＩＰヘッダが付加される。そして、送信データの優先判定手段１２３にてデータ内のプロトコルヘッダ内の情報をチェックし優先送信するか非優先送信かを判定し、送信処理待ちキュー１２７の優先データ処理待ちキューか非優先データ処理待ちキューのいずれかに送信データの接続手段１２４にて接続する。送信データの接続手段１２４にて、送信処理待ちキュー１２７に一つもデータが接続されていない場合、かつデータ送信手段１２６にて通信装置１１１へデータの送信要求を発行していない場合は、送信処理待ちキュー１２７にデータを接続せずに直接データ送信手段１２６へデータを渡す。データ送信手段１２６で送信データにデータリンク層ヘッダ（ＬＡＮへの送信時はＭＡＣヘッダ）を付加し、通信装置１１１を送信起動し通信網１１０へデータ送信する。
【００３２】データ送信手段１２６にて通信装置１１１へデータを送信要求を発行し、かつ送信処理待ちキュー１２７に一つもデータが接続されていない場合、あるいはデータ送信手段１２６にて通信装置１１１へデータを送信要求を発行し、かつ送信処理待ちキュー１２７にデータが接続されている場合は、送信処理待ちキュー１２７にデータを接続する。このキューに接続されたデータは、データ送信手段１２６が現在通信装置１１１へ送信要求している処理が終了し、通信装置１１１から終了割り込みを受けた時点で送信処理待ちキュー１２７より次に送信すべきデータを送信データの取り出し手段１２５により取り出し通信装置１１１へ送信要求する。送信データの取り出し手段１２５により取り出されるデータ数は、次に通信装置１１１が受付可能なデータ数である。つまり、通信装置１１１がデータ送信手段１２６から要求されたデータを通信網１１０へ送信し終了するまでの間送信処理待ちキュー１２７に溜め込まれる。そして次に通信網へのデータ送信手段１２６が動作するときに送信データの取り出し手段１２５にて優先データから順にデータを取り出し送信処理を行う。
【００３３】＜受信処理＞図１により、通信網からデータを受信し通信プログラムへ渡すまでの処理を説明する。通信装置１１１が通信網１１０からデータを受信すると通信装置１１１からデータ受信手段１３０に割り込みで報告され、データ受信手段１３０が通信装置１１１からデータを取り込む。受信データの優先判定手段１３１にて受信データ内のプロトコルヘッダ内の情報をチェックし優先受信するか非優先受信かを判定し、受信処理待ちキュー１３６の優先データ処理待ちキューか非優先データ処理待ちキューのいずれかに受信データの接続手段１３２にて接続する。受信処理待ちキュー１３６に一つもデータが接続されていない場合は、プロトコル受信処理部１４３を起動し、一連の割り込み報告による受信処理を終了する。データが接続されている場合は、受信処理を即終了する。プロトコル受信処理部１４３が起動されると受信データの取り出し手段１３３により受信処理待ちキュー136から次に処理すべき優先度の高いデータを一つ取り出し、ＩＰプロトコル受信処理部１３４へデータを渡し、自端末宛てのデータであれば上位のＴＣＰプロトコル受信処理部１３５経由で通信プログラム処理部１２０へデータを渡す。
【００３４】ＩＰプロトコル受信処理部１３４にて自端末宛てでないデータでかつ中継すべきデータと判断した場合は、受信データをプロトコル送信処理部１４１のＩＰプロトコル送信処理部１２２へ渡し、送信データの優先判定手段１２３，送信データの接続手段１２４，送信データの取り出し手段１２５，データ送信手段１２６を経由し送信する。
【００３５】プロトコル受信処理部１４３は、受信処理待ちキュー１３６にデータが接続されている限り上記のプロトコル受信処理を繰り返す。プロトコル受信処理部143が動作中であっても通信網からのデータ受信手段１３０は、割り込み動作する。このため通信装置１１１から受信したデータは、受信処理待ちキュー１３６に接続され溜め込まれる。この溜め込まれたデータをプロトコル受信処理部１４３への受信データの取り出し手段１３３にてデータを取り出しプロトコルの受信処理を行う。
【００３６】＜優先判定情報＞受信，送信データが優先すべきデータか非優先データかを判定するために参照するプロトコルヘッダ内の優先判定情報について説明する。
【００３７】図３に、通信網を流れるデータフレーム３００の構成例を示す。データフレーム３００は、データリンク層としてＩＥＥＥ８０２.３ を用いた場合のＴＣＰ／ＩＰのフレーム構成例である。この他、イーサネットフレームやＩＥＥＥ８０２フレームがある。ＴＣＰ／ＩＰプロトコルを用いた場合の優先判定情報は、データのプロトコル種別，ＴＣＰヘッダ３３０内の宛先ポート番号３３２，送信元ポート番号３３１、およびＩＰヘッダ３２０内の宛先インターネットアドレス322,送信元インターネットアドレス（ＩＮＡ）３２１である。
【００３８】プロトコル種別は、ＩＥＥＥ８０２.３ のＭＡＣヘッダ，ＬＬＣ（LogicalLink Control），ＳＮＡＰ（Sub Network Access Point）から成る物理ヘッダ３１０内のＳＮＡＰヘッダ内のプロトコルタイプ３１１を用いる。プロトコルタイプ３１１は、ＤＡＲＰＡプロトコルとしてリクエスト・フォー・コメンツ（ＲＦＣ）内にタイプ番号とプロトコル名が記載されており１６進数表記でＩＰプロトコルが８００，ＡＲＰが８０６と決められている。更にプロトコル種別を限定するために、プロトコルタイプ３１１がＩＰのとき、ＩＰヘッダ３１２内のプロトコル３２６（ＩＰの上位プロトコル）を用いる。プロトコル３２６としては、ＴＣＰ，ＵＤＰ、およびＩＣＭＰなどのプロトコルがＲＦＣで定義されている。インターネットアドレスは、ＩＰヘッダ３２０の送信元ＩＮＡ（インターネットアドレス）３２１，宛先ＩＮＡ３２２を用いる。ポート番号は、ＴＣＰあるいはＵＤＰヘッダ３３０内の送信元ポート番号３３１，宛先ポート番号３３２を用いる。
【００３９】図４に示す形式により、図１の優先データ情報登録メモリ１０２に、上記優先判定情報の内どの組み合わせを優先的に送受信するかが格納されている。すなわち、データの物理ヘッダ３１０内のプロトコルタイプ４０１，ＩＰヘッダ内のプロトコルタイプ４０２，送信元のＩＮＡ４０３，宛先のＩＮＡ４０４，送信元ポート番号４０５，宛先ポート番号４０６が、それぞれの対応する部分に格納されている。プロトコルには、直接、通信プログラム処理部１２０において通信プログラムの処理に使用するＴＣＰ，ＵＤＰプロトコルとＡＲＰ，ＩＣＭＰのようなシステム内のプロトコル処理から使用され通信プログラムからは直接使用されないプロトコルがある。全てのプロトコルを優先データ情報として登録すると優先データ情報登録メモリを検索するオーバーヘッドが大きくなり通信性能が遅延するため、ＡＲＰ，ＩＣＭＰのような直接通信プログラムから使用されないプロトコルは、予め優先データとして処理しても良い。優先データ情報登録メモリを検索するオーバーヘッドを高速化するためのハッシュ化等の処理も組み込む。また、優先判定する情報全てを比較しなくても良いように優先データ情報登録メモリに格納される値が０の場合、その項目の比較を行わない。この値は０でも−１でも構わないが優先判定情報内で用いられない値である必要がある。
【００４０】＜優先判定＞図５に、送受信データの優先判定手段の一例のフローチャートを示す。この例では、処理５００，５０５にて送受信するデータのプロトコル種別をチェックし、ＡＲＰ，ＩＣＭＰである場合無条件に優先データとし、ＡＲＰ，ＩＣＭＰ，ＴＣＰ，ＵＤＰ以外のプロトコルである場合非優先データとして扱う。データがＴＣＰ，ＵＤＰプロトコルならば処理５１０〜５５０にてデータと優先データ情報登録メモリ内全ての宛先，送信元ポート番号、および宛先，送信元インターネットアドレスを比較する。優先データ情報が０の場合は比較せずに次の優先データ情報の比較を行う。登録されている場合、優先データとし、登録されていない場合には、非優先データとする。」（７頁１１欄〜８頁１４欄）
　　
　引用例の段落【００３１】、【００３２】の記載を参照すると、送信データは優先データと非優先データとに分けられ、優先データは、非優先データより優先して送信処理されるものである。
　端末は、送信されたデータを受信データとして受信するものであるから、「優先して送信処理される優先データと、前記優先データよりも送信処理の優先度が低い非優先データからなる受信データを受信する受信ステップ」を有するものであるといえる。
　引用例の段落【００３６】〜【００４０】の記載を参照すると、端末の優先判定手段は受信データに格納されている物理ヘッダ、ＩＰヘッダ、ＴＣＰ／ＵＤＰヘッダを検査することにより、優先データと非優先データとを判定するものであるので、「前記受信データに格納されている異なるレイヤで生成された複数の通信プロトコルヘッダを検査することにより前記優先データと前記非優先データとを判定する優先判定ステップ」を有するものであるといえる。
　また、端末の通信プログラムは判定された優先データと非優先データとを処理するものであるから、「前記判定された優先データと前記非優先データとを処理するステップ」を有するものであるといえる。
　
　したがって、引用例には、技術常識を考慮すると、
　「優先して送信処理される優先データと、前記優先データよりも送信処理の優先度が低い非優先データからなる受信データを受信する受信ステップと、
　前記受信データに格納されている異なるレイヤで生成された複数の通信プロトコルヘッダを検査することにより前記優先データと前記非優先データとを判定する優先判定ステップと、
　前記判定された優先データと前記非優先データとを処理するステップと、を有する通信方法。」
の発明（以下、「引用例発明」という。）が開示されていると認めることができる。
　
３．対比
　本願発明と引用例発明とを対比する。
　引用例発明の「優先して送信処理される優先データ」は、本願発明の「優先して処理される優先パケット」に相当する。
　引用例発明の「優先データよりも送信処理の優先度が低い非優先データ」は、本願発明の「優先パケットよりも処理優先度が低い非優先パケット」に相当する。
　引用例発明の「受信データ」は、本願発明の「受信パケット」に相当する。
　引用例発明の「前記優先データと前記非優先データとを判定する優先判定ステップ」は、本願発明の「前記優先パケットと前記非優先パケットとを選別する選別ステップ」に相当する。
　引用例発明の「通信方法」は、本願発明の「伝送方法」に相当する。
　　　
　したがって、本願発明と引用例発明とは、
　「優先して処理される優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットからなる受信パケットを受信する受信ステップと、
　前記受信パケットに格納されている異なるレイヤで生成された複数の通信プロトコルヘッダを検査することにより前記優先パケットと前記非優先パケットとを選別する選別ステップと、
　前記選別された優先パケットと前記非優先パケットとを処理するステップと、を有する伝送方法。」
の点で一致し、以下の点で相違している。
　　
［相違点１］
　「前記受信パケットに格納されている異なるレイヤで生成された複数の通信プロトコルヘッダ」の検査について、本願発明は、検査を同時に行うのに対して、引用例発明は、検査を同時に行うものではない点。
［相違点２］
　「前記選別された優先パケットと前記非優先パケットとを処理するステップ」について、本願発明では、前記選別された優先パケットと前記非優先パケットとをそれぞれ独立して処理するものであるのに対して、引用例発明では、どのように処理するのか明らかでない点。
　
４．当審の判断
　まず、相違点１について検討する。
　通信に用いられるパケットは、通常「異なるレイヤで生成された複数の通信プロトコルヘッダ」を有しており、その複数の通信プロトコルヘッダを解析する場合に、複数の通信プロトコルヘッダについて同時に解析して高速化を図ることは、例えば特開２０００−９２１１０号公報の段落【００１９】〜【００２０】、特開平１１−８８４０４号公報の段落【００１２】に示されるように、周知事項である。
　当該周知事項を引用例発明に適用して、相違点１に係る構成とすることに困難性は認められない。
　次に相違点２について検討する。
　パケットを受信する装置において、受信したパケットの種別によりそれぞれ独立して処理することは、例えば特開平９−３０７８６５号公報の段落【００２３】〜【００３３】及び図１、特開平２−１４２２３８号公報の第２図に示されるように、周知事項である。
　当該周知事項を引用例発明に適用して、相違点２に係る構成とすることに困難性は認められない。
　
　そして、本願発明の作用効果も、引用例発明から当業者が予測できる範囲のものである。
　　　
５．むすび
　以上のとおり、本願発明は、引用例発明及び周知事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。