【事件の表示】
　特願２０１３−５５６９５５「無線端末及びホストデバイスのための通信方法、無線端末、及びホストデバイス」拒絶査定不服審判事件〔平成２４年　９月１３日国際公開、ＷＯ２０１２／１１９５４３、平成２６年　５月２９日国内公表、特表２０１４−５１３４５３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１２年（平成２４年）３月６日（パリ条約による優先権主張外国庁受理　２０１１年３月９日　中華人民共和国）を国際出願日とする特願２０１３−５５６９５５号であって、その手続の経緯は以下のとおりである。 
　平成２６年　９月２４日付け　拒絶理由の通知
　平成２６年１２月２５日　　　意見書、手続補正書の提出
　平成２７年　３月　５日付け　拒絶理由の通知
　平成２７年　６月　３日　　　意見書、手続補正書の提出
　平成２７年　７月　２日付け　平成２７年６月３日付け手続補正書による
　　　　　　　　　　　　　　　補正の却下、拒絶査定
　平成２７年１０月２０日　　　審判請求書、手続補正書の提出
　平成２７年１１月１９日　　　前置報告書
　平成２８年　７月２２日付け　当審による拒絶理由の通知
　平成２８年１０月２６日　　　意見書、手続補正書の提出
　平成２８年１２月２０日付け　当審による拒絶理由の通知
　平成２９年　４月　３日　　　意見書の提出
第２　本件発明
　本願の請求項に係る発明は、平成２８年１０月２６日付け手続補正書の特許請求の範囲の請求項１から１４までに記載された事項により特定されるものであると認められるところ、その請求項１に係る発明（以下、「本願発明」という。）は、その請求項１に記載された、次の事項により特定されるものである。
「【請求項１】
　無線端末のための通信方法であって、
　無線端末によって、前記無線端末のＵＳＢポートのポートタイプをホストデバイスに通知するステップであって、前記ポートタイプはネットワーク層データ転送プロトコルに基づき、その結果、前記ポートタイプに対応するポートドライバを使用することによって、ホストデバイスが前記ＵＳＢポートを駆動するステップと、
　前記無線端末によって、前記ＵＳＢポートを経由した前記ホストデバイスとのインタラクションを介して、前記無線端末と前記ホストデバイスとの間のネットワーク層データ転送プロトコルに基づく通信リンクを確立するステップと、
　前記無線端末によって、ネットワーク層データ転送プロトコルに基づく通信リンクを経由して、１又は２以上のサービスについてのサービスパケット及び前記サービスパケットのタイプを送信するステップと、
　を含み、
　前記無線端末によって、前記ＵＳＢポートを経由した前記ホストデバイスとのインタラクションを介して、前記無線端末と前記ホストデバイスとの間の前記ネットワーク層データ転送プロトコルに基づく通信リンクを確立するステップは、特に、
　前記無線端末によって、ＤＨＣＰを使用することによって、前記無線端末及び前記ホストデバイスにＩＰアドレスを割り当てるとともに、前記無線端末と前記ホストデバイスとの間の前記ネットワーク層データ転送プロトコルに基づく前記通信リンクを確立するステップを含む、無線端末のための通信方法。」
第３　当審の平成２８年１２月２０日付け拒絶理由の概要
　当審が平成２８年１２月２０日付けで通知した拒絶理由の概要は、次のとおりである。
理由１．（明確性）本件出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。 
理由２．（実施可能要件）本件出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項第１号に規定する要件を満たしていない。 
理由３．（進歩性）本件出願の請求項１−１４に係る発明は、その出願前日本国内または外国において頒布された刊行物１に記載された発明及び周知技術に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
＜引用刊行物＞
１．特表２００８−５３８６９０号公報
２．桑野雅彦“第２章　コミュニケーション・クラスでシリアル・ポート接続機器を作る　ＵＳＢ仮想ＣＯＭポート・デバイスの設計事例”、Ｉｎｔｅｒｆａｃｅ、ＣＱ出版株式会社、２００７年１月１日、第３３巻、第１号、ｐ６４−７３（周知技術として例示）
３．細川達己“何でも接続！ＵＳＢ活用術　Ｐａｒｔ４　ＵＳＢネットワークの利用形態”、ＵＮＩＸ　ＵＳＥＲ、ソフトバンク　クリエイティブ株式会社、２００５年１１月１日、第１４巻、第１１号、ｐ６４−６９（周知技術として例示） 
４．特表２００７−５３５２００号公報（周知技術として例示）
＜参考文献＞（技術常識の裏付けとして例示）
１．三木昭一郎“ファームウェアとアプリケーションの働きがイメージで分かる 今さら聞けないＵＳＢ通信のしくみ”、トランジスタ技術、ＣＱ出版株式会社、２０１０年１月１日、第４７巻、第１号、ｐ１１２−１２２
２．桑野雅彦、藤原尚伸“ＵＳＢシステムを理解するために必要なポイントを整理 今さら聞けないＵＳＢの基礎知識”、Ｉｎｔｅｒｆａｃｅ、ＣＱ出版株式会社、２０１０年３月１日、第３６巻、第３号、ｐ５４−６５
第４　当審の判断
　理由３について検討する。
１．特表２００８−５３８６９０号公報に記載された発明
　特表２００８−５３８６９０号公報（当審が平成２８年１２月２０日付けで通知した拒絶理由の引用文献１）には、以下の記載がある（なお、下線は、当審において付したものである。）。
（１）「【０００３】
　ワイヤレスデバイスは、ＴＥ２デバイス(TE2 device)に結合され、ＴＥ２デバイスのためのワイヤレスデータサービスを提供し、またはサポートするために使用されることができる。
ワイヤレスデバイスは、ワイヤレスデータネットワークに対してアクセスを提供することができるセルラ電話(cellular telephone)、ユーザ端末、データカード、または他の何らかのデバイスとすることができる。ＴＥ２デバイスは、ラップトップコンピュータ、携帯型個人情報端末(personal digital assistant)（ＰＤＡ）、または他の何らかのコンピューティングデバイス(computing device)とすることができる。
（２）「【００１５】
　
ワイヤレスデバイス１２０は、ワイヤライン接続（図１に示されるような）またはワイヤレス接続を経由してＴＥ２デバイス１１０に結合されることができる。ワイヤライン接続は、ユニバーサルシリアルバス(Universal Serial Bus)（ＵＳＢ）
を経由したものとすることができる
　【００１６】
　
ワイヤレスデバイス１２０に結合されるＴＥ２デバイス１１０が「取り付けられた」コンフィギュレーション(“attached” configuration)においては、モバイルユーザは、ＴＥ２デバイス１１０を経由して様々なサービス（例えば、ＩＰ接続性サービスおよび／またはワイヤレスデータサービス）を得ることができる。これらのサービスを得るために、ＴＥ２デバイス１１０は、ワイヤレスデバイス１２０と通信し
　【００１７】
　図２は、ワイヤレスデバイス１２０およびワイヤレスネットワーク１３０を経由しての、ＴＥ２デバイス１１０とリモートホスト１７０との間のデータ通信についての例示のプロトコルスタック２００を、示している。そのプロトコルスタックは、トランスポート層、ネットワーク層、リンク層、および物理層を含む。
　【００１８】
　ＴＥ２デバイス１１０とリモートホスト１７０とは、トランスポート層にある伝送制御プロトコル(Transmission Control Protocol)（ＴＣＰ）、ユーザデータグラムプロトコル(User Datagram Protocol)（ＵＤＰ）、または他の何らかのプロトコル、を使用して通信することができる。ＴＣＰおよびＵＤＰは、一般的に、ネットワーク層にあるインターネットプロトコル（ＩＰ）の上部で動作する。
トランスポート層データ（例えば、ＴＣＰおよび／またはＵＤＰについての）は、ＩＰパケットの形でカプセル化され(encapsulated)、これらのＩＰパケットは、ワイヤレスデバイス１２０、無線ネットワーク１４０、およびＩＰゲートウェイ１５０を経由してＴＥ２デバイス１１０とリモートホスト１７０との間で交換される
　【００１９】
　
ＴＥ２デバイス１１０とワイヤレスデバイス１２０との間のリンク層は、イーサネット（登録商標）(Ethernet（登録商標）)または他の何らかのプロトコルとすることができる
（３）「【００２１】
　図４は、ワイヤレスデバイス１２０ａを経由してＴＥ２デバイス１１０ａに対してデータ／ＩＰ接続性を提供するためのコンフィギュレーション４００を示しており、これらは、図１におけるそれぞれＴＥ２デバイス１１０とワイヤレスデバイス１２０の一実施形態である。
ＴＥ２デバイス１１０ａにおいて、アプリケーション４１０とソケット４１２は、データプロトコルスタック４１４上で実行する。ソケットは、ネットワーク上で実行される２つのアプリケーションの間の双方向の通信経路の１つのエンドポイント(endpoint)であり、ポート番号にバインドされ(bound)、その結果、ＴＣＰなどのトランスポート層プロトコルは、送信されるべきデータについてのアプリケーションを識別することができる。ＴＥ２デバイス１１０ａは、インターフェース４１８を経由してワイヤレスデバイス１２０ａと通信する
（４）「【００５７】
　ワイヤレスデータサービス
　図８は、ＴＥ２デバイス１１０ｅとワイヤレスデバイス１２０ｅとを有するコンフィギュレーション８００を示しており、これらは、それぞれ、ＴＥ２デバイス１１０ｂとワイヤレスデバイス１２０ｂの要素のすべてを含んでいる。
ワイヤレスデバイス１２０ｅはさらに
動的ホストコンフィギュレーションプロトコル(Dynamic Host Configuration Protocol)（ＤＨＣＰ）サーバ８２４と、をさらにインプリメントする
ＤＨＣＰサーバ８２４は、ＴＥ２デバイス１１０ｅについての動的ＩＰコンフィギュレーションをサポートする。
（５）「【００６５】
　
ＤＨＣＰを使用した動的アドレス割当て。ＴＥ２デバイス１１０ｅは、データセッションをセットアップし、ワイヤレスデバイス１２０ｅからＩＰアドレスおよび他のコンフィギュレーション情報を取得するために、ＡＴコマンドおよびＰＰＰを使用することができる
もしこの情報が、ＬＡＮ環境において一般的に使用されるＤＨＣＰまたは他の標準プロトコルを使用して、ＩＰコンフィギュレーションを動的に取得することができる場合には、インターフェース５１８は、ＩＰベースのインターフェースのように機能することができる。
この機能は、ワイヤレスデバイス１２０ｅによってサポートされることができる
　【００６６】
　
ＤＨＣＰを伴う動的ＩＰコンフィギュレーションの場合、ＴＥ２デバイス１１０ｅは、インターフェース５１８からのＤＨＣＰＤＩＳＣＯＶＥＲメッセージを最初にブロードキャストする。このメッセージは、ワイヤレスデバイス１２０ｅにおけるＲｍインターフェース５２８ａを経由して受信され、ＤＨＣＰサーバ８２４に対して転送される
次いでＤＨＣＰサーバ８２４は、ＴＥ２デバイス１１０ｅに対してＤＨＣＰＯＦＦＥＲメッセージを送信する。この応答メッセージは、（１）ＴＥ２デバイス１１０ｅがそのＩＰアドレスとして使用することができるＩＰアドレスａ．ｂ．ｃ．ｄ 、（２）図１中のＩＰゲートウェイ１５０のＩＰアドレスであり得る、ＴＥ２デバイス１１０ｅがそのサブネットの外側のＩＰパケットを送信するために使用することができるＩＰアドレス、および（３）ワイヤレスデバイス１２０ｅによってスプーフィングされあるいはそのふりをされるＩＰアドレスであり得る、ＤＨＣＰサーバ８２４のＩＰアドレス、を含むことができる。ＴＥ２デバイス１１０ｅは、その後にＤＨＣＰＯＦＦＥＲメッセージ中において通知される(advertised)ような、スプーフィングされたＩＰアドレスを使用して、ＤＨＣＰメッセージをＤＨＣＰサーバ８２４に対して送信することができる。これらのＤＨＣＰメッセージは、Ｒｍインターフェース５２８ａを経由して受信され、経路指定またはパケットフィルタリングを使用してＤＨＣＰサーバ８２４に対して供給される
　【００６７】
　一般に、ここにおいて説明される技法およびコンフィギュレーションにより、ＴＥ２デバイスは、ＩＰベースのインターフェースを使用して取り付けられたワイヤレスデバイスを経由してワイヤレスデータサービスを得ることができるようになる。いくつかの例示のワイヤレスデータサービスが、特定のコンフィギュレーション８００について、上記に説明されている。他のサービスもまた、ＴＥ２デバイスに対して提供されることができる。
　【００６８】
　ワイヤレスデータサービスは、ワイヤレスデバイス中心であるかもしれないし、ワイヤレスネットワーク経由で取得するために特別な手段および／またはプロトコルを必要とするかもしれない。ここにおいて説明される技法は、ＴＥ２デバイスからこれらの複雑さ(intricacy)を隠すことができる。
ＴＥ２デバイス中において実行されるエンドアプリケーションは、ＩＰベースのインターフェースを使用してワイヤレスデバイスを経由してこれらのワイヤレスデータサービスを取得することができる。これらのエンドアプリケーションは、ＩＰベースのフレームワーク上で動作する、ウェブブラウザなど、標準のＩＰベースのプロトコルを使用することができる
　　・ＴＥ２デバイス中におけるエンドアプリケーションは、データアプリケーション開発業者によってよく理解され、非常に安定しており、立証された機能を有するＩＰベースのプロトコルを使用することができる。
　　・エンドアプリケーションは、標準のＩＰプロトコルに基づいた多数の既存のアプリケーションを再使用することができる。
　　・エンドアプリケーションは、ユーザによって一般に使用され非常に人気のある、ウェブベースのユーザインターフェースなど、標準化され、よく知られているユーザインターフェースを使用することができる。これらのユーザインターフェースは、ユーザに対してコンテンツを提供するためにＩＰベースのフレームワークを必要とする。
　ＩＰベースのインターフェースは、一様(uniform)であり、（１）ワイヤレスデバイスのタイプ、アーキテクチャ、および製造業者、（２）望ましいワイヤレスデータサービスにアクセスするワイヤレスデバイスによって、サポートされ使用されるワイヤレス技術、（３）ＴＥ２デバイスについての環境またはオペレーティングシステム、および（４）ＴＥ２デバイスとワイヤレスデバイスとの間の物理的相互接続、から独立している。」
（６）「【００７０】
　その後に、ワイヤレスデバイス１２０は、通信経路１についてＩＰアドレスａ．ｂ．ｃ．ｄ を使用してＴＥ２デバイス１１０とワイヤレスネットワーク１３０との間で交換されるデータを転送する（ブロック９１４）。このデータは、このデータが、Ｕｍインターフェース上にインストールされるパケットフィルタのどれともマッチングしないので、ワイヤレスデバイス１２０を対象としない。
ワイヤレスデバイス１２０はまた、（１）ＴＥ２デバイス１１０に送信されるアウトバウンドパケットについてＩＰアドレスｗ．ｘ．ｙ．ｚ を使用すること、および（２）ＴＥ２デバイス１１０から受信されるインバウンドパケットに対してアドレスベースの経路指定またはパケットフィルタリングを実行すること、によって、通信経路２についてＲｍインターフェースを経由してＴＥ２デバイスとデータを交換することもできる（ブロック９１６）
（７）図８
  
（８）そうすると、引用文献１に記載された発明（以下、「引用発明」という。）は、以下のとおりのものである。
「ワイヤレスデバイスは、ワイヤレスデータネットワークに対してアクセスを提供することができるセルラ電話、ユーザ端末、データカード、または他の何らかのデバイスとすることができ、
　ワイヤレスデバイス１２０は、ワイヤライン接続を経由してＴＥ２デバイス１１０に結合されることができ、ワイヤライン接続は、ユニバーサルシリアルバス（ＵＳＢ）を経由したものとすることができ、
　ワイヤレスデバイス１２０に結合されるＴＥ２デバイス１１０が「取り付けられた」コンフィギュレーションにおいては、モバイルユーザは、ＴＥ２デバイス１１０を経由して様々なサービス（例えば、ＩＰ接続性サービスおよび／またはワイヤレスデータサービス）を得ることができ、これらのサービスを得るために、ＴＥ２デバイス１１０は、ワイヤレスデバイス１２０と通信し、
　トランスポート層データ（例えば、ＴＣＰおよび／またはＵＤＰについての）は、ＩＰパケットの形でカプセル化され、これらのＩＰパケットは、ワイヤレスデバイス１２０、無線ネットワーク１４０、およびＩＰゲートウェイ１５０を経由してＴＥ２デバイス１１０とリモートホスト１７０との間で交換され、
　ＴＥ２デバイス１１０とワイヤレスデバイス１２０との間のリンク層は、イーサネット（登録商標）または他の何らかのプロトコルとすることができ、
　ＴＥ２デバイス１１０ａにおいて、アプリケーション４１０とソケット４１２は、データプロトコルスタック４１４上で実行し、ソケットは、ネットワーク上で実行される２つのアプリケーションの間の双方向の通信経路の１つのエンドポイントであり、ポート番号にバインドされ、その結果、ＴＣＰなどのトランスポート層プロトコルは、送信されるべきデータについてのアプリケーションを識別することができ、ＴＥ２デバイス１１０ａは、インターフェース４１８を経由してワイヤレスデバイス１２０ａと通信し、
　ワイヤレスデバイス１２０ｅはさらに、動的ホストコンフィギュレーションプロトコル（ＤＨＣＰ）サーバ８２４をインプリメントし、
　ＤＨＣＰサーバ８２４は、ＴＥ２デバイス１１０ｅについての動的ＩＰコンフィギュレーションをサポートし、
　ＴＥ２デバイス１１０ｅは、データセッションをセットアップし、ワイヤレスデバイス１２０ｅからＩＰアドレスおよび他のコンフィギュレーション情報を取得するために、ＡＴコマンドおよびＰＰＰを使用することができ、
　もしこの情報が、ＬＡＮ環境において一般的に使用されるＤＨＣＰまたは他の標準プロトコルを使用して、ＩＰコンフィギュレーションを動的に取得することができる場合には、インターフェース５１８は、ＩＰベースのインターフェースのように機能することができ、この機能は、ワイヤレスデバイス１２０ｅによってサポートされ、
　ＤＨＣＰを伴う動的ＩＰコンフィギュレーションの場合、ＴＥ２デバイス１１０ｅは、インターフェース５１８からのＤＨＣＰＤＩＳＣＯＶＥＲメッセージを最初にブロードキャストし、このメッセージは、ワイヤレスデバイス１２０ｅにおけるＲｍインターフェース５２８ａを経由して受信され、ＤＨＣＰサーバ８２４に対して転送され、
　次いでＤＨＣＰサーバ８２４は、ＴＥ２デバイス１１０ｅに対してＤＨＣＰＯＦＦＥＲメッセージを送信し、この応答メッセージは、（１）ＴＥ２デバイス１１０ｅがそのＩＰアドレスとして使用することができるＩＰアドレスａ．ｂ．ｃ．ｄ 、（２）図１中のＩＰゲートウェイ１５０のＩＰアドレスであり得る、ＴＥ２デバイス１１０ｅがそのサブネットの外側のＩＰパケットを送信するために使用することができるＩＰアドレス、および（３）ワイヤレスデバイス１２０ｅによってスプーフィングされあるいはそのふりをされるＩＰアドレスであり得る、ＤＨＣＰサーバ８２４のＩＰアドレス、を含むことができ、
　ＴＥ２デバイス１１０ｅは、その後にＤＨＣＰＯＦＦＥＲメッセージ中において通知されるような、スプーフィングされたＩＰアドレスを使用して、ＤＨＣＰメッセージをＤＨＣＰサーバ８２４に対して送信することができ、これらのＤＨＣＰメッセージは、Ｒｍインターフェース５２８ａを経由して受信され、経路指定またはパケットフィルタリングを使用してＤＨＣＰサーバ８２４に対して供給され、
　ＴＥ２デバイス中において実行されるエンドアプリケーションは、ＩＰベースのインターフェースを使用してワイヤレスデバイスを経由してこれらのワイヤレスデータサービスを取得することができ、これらのエンドアプリケーションは、ＩＰベースのフレームワーク上で動作する、ウェブブラウザなど、標準のＩＰベースのプロトコルを使用することができ、
　ワイヤレスデバイス１２０はまた、（１）ＴＥ２デバイス１１０に送信されるアウトバウンドパケットについてＩＰアドレスｗ．ｘ．ｙ．ｚ を使用すること、および（２）ＴＥ２デバイス１１０から受信されるインバウンドパケットに対してアドレスベースの経路指定またはパケットフィルタリングを実行すること、によって、通信経路２についてＲｍインターフェースを経由してＴＥ２デバイスとデータを交換することもできる、
　方法。」
２．技術常識について
（１）当審の平成２８年１２月２０日付け拒絶理由で例示した参考文献１（上記第３参照）には、次の記載がある（当審注：「マル１」〜「マル６」は、丸印が付された数字の１〜６を示す。）。
「接続時の自動認識処理（プラグ・アンド・プレイ）
　ＵＳＢの一番の特徴は接続時の自動認識（プラグ・アンド・プレイ）に対応していることです．ＵＳＢホストの電源を落とすことなく、周辺機器（ＵＳＢデバイス）をパソコン（ＵＳＢホスト）に接続して使用できます．ＵＳＢデバイスを接続してから使用可能になるまでの間に行われる一連の処理を「エニュメレーション」と呼びます．
　図６はＵＳＢデバイス（例として、マス・ストレージ・クラスのＵＳＢハード・ディスク）が接続されたときのＵＳＢホスト内の処理をイメージ化したものです．
マル１　パソコン側のハブ・ドライバがＵＳＢデバイスの接続を認識
　ＵＳＢホストのＵＳＢコネクタにＵＳＢデバイスが接続されると、ホスト・コントローラ・ドライバがハブ・ドライバに対して、ＵＳＢデバイスが接続されたことを通知します．
マル２　ＵＳＢホストがＵＳＢデバイスを管理するための番号（デバイス・アドレス）を割り当て
（中略）
マル３　ＵＳＢデバイスの正体（デバイス・ディスクリプタ）を取得
　次に、接続されたＵＳＢデバイスからディスクリプタ（表３）と呼ばれる情報を取得します．まずＵＳＢデバイスがどのクラスに属するのかを知るために、デバイス・ディスクリプタを取得します．ディスクリプタ情報の取得にはＧＥＴ＿ＤＥＳＣＲＩＰＴＯＲリクエストを使用します．
マル４　クラスを判別してホストの通信の準備
　ＵＳＢホストは、取得したデバイス・ディスクリプタ内のｂＤｅｖｉｃｅＣｌａｓｓに設定されているクラス・コード（表５）からデバイス・クラスを判別します．クラス・コードが００（ｈ）の場合、インターフェース・ディスクリプタ内のｂＩｎｔｅｒｆａｃｅＣｌａｓｓを参照し、デバイス・クラスを判別します．
（中略）
　クラス・コードから判別したクラスからＵＳＢデバイスに合わせてデータ通信路（図３のベルト・コンベア）を構築していきます．ＵＳＢでは４種類のデータ通信路が用意されており、用途に合わせて通信路を使い分けます．
マル５　デバイスの通信の準備（コンフィグレーション設定）
　ＵＳＢホストからのデータ通信路（ベルト・コンベア）をＵＳＢデバイス側のエンドポイントに適切に割り当ててもらうために、ＵＳＢデバイスに対して通知を出します．通知にはＳＥＴ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮリクエストを使用します．
マル６　データ転送の準備完了
　コンフィグレーション設定が完了すると、クラス内で定義された転送プロトコル（図３のクラス・レイヤ間で使用する箱）にのっとってデータ送受信が可能となります．
●自作ＵＳＢデバイスを使用するには…
　ＵＳＢデバイスを接続し、データ転送可能状態になるということはＵＳＢホストにおいてクラス・ドライバのロードが完了したことを意味します．ＵＳＢホスト側で使用しているＯＳがＷｉｎｄｏｗｓ系ＯＳ（ＷｉｎｄｏｗｓＸＰ／Ｖｉｓｔａ／７など）やＬｉｎｕｘ系ＯＳの場合は、ほとんどの標準クラスのクラス・ドライバがデフォルトでインストールされています．そのため標準クラスに属するＵＳＢデバイスを開発した場合は、ＵＳＢデバイスをＵＳＢホストに接続するだけでクラス・ドライバが自動でロードされ、使用することが可能になります．」（ｐ１１７右欄下から１２行目−ｐ１２０左欄第７行の抜粋）
（２）同じく、参考文献２（上記第３参照）には、次の記載がある（当審注：「マル３」は、丸印が付された数字の３を示す。）。
「●コントロール転送の実際
　より具体的に、ＵＳＢではどのようにデータ転送が行われるのかを見てみましょう．
　まずＵＳＢケーブルを接続した直後に行われる、最初のコントロール転送のようすを図６に示します．
(中略）
●ディスクリプタとは
　図６のコントロール転送で、ターゲットからホストに対して転送される具体的なデータとして、各種ディスクリプタ（表５）があります．コラムにより接続されたターゲットの通信速度は判定できますが、さらに詳しい種類まではわかりません．そこでコントロール転送を使って、まず表５（ａ）の標準デバイス・ディスクリプタを取得します．この中に、ベンダＩＤやプロダクトＩＤ、ＵＳＢ周辺機器としての大まかな分類を示すクラス・コードなどが格納されています．表６にクラス・コードを示します．
　また図１（ｂ）に示したように、ターゲットごとにエンドポイントの個数も異なります．エンドポイントの個数やどのエンドポイントをどの転送モードで使うかなどは、インターフェース・ディスクリプタ内に記述されています．つまり、ターゲットとしてのさまざまな仕様は、これらのディスクリプタの内容を調べればすべてわかるようになっています．
●ＵＳＢの状態管理
（中略）
　最終的にＵＳＢ機器として動作可能状態になるには、デバイス・リクエストとしてＳＥＴ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮリクエストを発行して、ターゲットをマル３の状態にしてからです．」（ｐ５８右欄第４行−ｐ６２右欄第５行から抜粋。）
「２．ＵＳＢホストとＵＳＢドライバ
　ＵＳＢシステムの全体像がわかったところで、次はＵＳＢホストには何が必要かを整理しましょう．今回はホストとしてＷｉｎｄｏｗｓパソコンを想定しています．
●ＵＳＢ機器を接続するにはドライバが必要
　先月号（２０１０年２月号）の本誌特集でも詳しく解説されていたように、周辺機器を制御するには、ハードウェアとアプリケーションをつなぐ架け橋となるデバイス・ドライバ（以下ドライバ）が必要です．図９にＷｉｎｄｏｗｓにおけるＵＳＢホストのソフトウェア構成を示します．ＵＳＢホスト・コントローラを制御するホスト・コントローラ・ドライバや、ＵＳＢハブを制御するハブ・ドライバ、そしてＵＳＢターゲットの種類ごとに用意されている各種クラス・ドライバなどが階層化された構造となっています．
●Ｗｉｎｄｏｗｓに標準で用意されているドライバ
　たとえば、ＷｉｎｄｏｗｓパソコンにＵＳＢキーボードを差し込んだら、ドライバのインストーラは起動せずに自動的にドライバが読み込まれ、キーボードが使えるようになります．これはＷｉｎｄｏｗｓが標準でＵＳＢキーボード用のドライバを持っているからです．ＵＳＢキーボードには各社からいろいろな種類（フル・キーボード、１０キーなし小型キーボード、１０キーのみ）が発売されていますが、これらはすべて同じクラスで管理され、ドライバを用意せずともそのまま使えます．
　Ｗｉｎｄｏｗｓが標準でドライバを持っているデバイスには次のようなものがあります．
　・ＵＳＢハブ…ハブ・クラス
　・キーボードやマウス…ＨＩＤ（ＨｕｍａｎＩｎｔｅｒｆａｃｅＤｅｖｉｃｅ）クラス
　・ハード・ディスクやＵＳＢフラッシュ・メモリ…マスストレージ・クラス
　・ＵＳＢ接続仮想シリアル・ポート…コミュニケーション・デバイス・クラス
●ＵＳＢ標準クラスはドライバ要らず
　これらの標準クラスにはＯＳに初めからドライバが用意されているので、新規にドライバを用意する必要がありません．必要に応じてアプリケーションを作成するだけですぐにＵＳＢターゲットと通信が行えます．標準クラスを採用すれば、それだけ開発負荷を減らせるわけで、手軽にＵＳＢ周辺機器を開発するなら、既存の標準クラスに対応させるのが得策です．本特集では、第４章でマスストレージ・クラスに、第５章と第６章ではコミュニケーション・デバイス・クラスに対応させたＵＳＢターゲットを作成しています．」（ｐ６２右欄下から１１行目−ｐ６４左欄第２６行）
（３）上記（１）、（２）に例示されるように、ＵＳＢ機器の分野において、以下（ｉ）及び（ｉｉ）は、技術常識（以下、「技術常識Ａ」という。）である。
（ｉ）ＵＳＢホスト（ＰＣ等）にＵＳＢデバイスを接続した場合、プラグアンドプレイにより、接続されたＵＳＢデバイスのクラス等の情報を記述したディスクリプタがＵＳＢホストに送られ、ＵＳＢホストでは、該ディスクリプタの記述内容に対応するドライバが使用され、ＵＳＢポートを介したデータ転送が可能になること。
（ｉｉ）ＯＳによっては、標準クラスのドライバが予め用意されており、該標準クラスのドライバが使用できる場合には、新規にドライバを用意する必要はないこと。
３．対比
　本願発明と引用発明とを対比する。
（１）引用発明の「ワイヤレスデバイス１２０」、「ＴＥ２デバイス１１０」、及び「動的ホストコンフィギュレーションプロトコル（ＤＨＣＰ）」はそれぞれ本願発明の「無線端末」、「ホストデバイス」及び「ＤＨＣＰ」に相当する。
（２）引用発明では、「ワイヤレスデバイス１２０」は、「ＵＳＢを経由」して「ＴＥ２デバイス１１０」に接続される。
　そして、上記技術常識Ａに鑑みれば、引用発明においても、「ワイヤレスデバイス１２０」を「ＵＳＢを経由」して「ＴＥ２デバイス１１０」に接続し、プラグアンドプレイによって、「ワイヤレスデバイス１２０」と「ＴＥ２デバイス１１０」との間でデータ転送を可能な状態にしているといえるから、本願発明と引用発明とは、「無線端末を、無線端末のＵＳＢポートを介してホストデバイスに接続し、データ転送を可能な状態にするステップ」を有する点で共通するといえる。
（３）引用発明では、「ワイヤレスデバイス１２０」は、「動的ホストコンフィギュレーションプロトコル（ＤＨＣＰ）サーバ８２４をインプリメントし」、「ＤＨＣＰサーバ８２４は、ＴＥ２デバイス１１０ｅについての動的ＩＰコンフィギュレーションをサポート」するとしている。
　そして、引用発明では、「ワイヤレスデバイス１２０」と「ＴＥ２デバイス１１０」とが、「ＤＨＣＰを伴う動的ＩＰコンフィギュレーション」によって割り当てられたＩＰアドレスを用いて通信することにより、「ＴＥ２デバイス中において実行されるエンドアプリケーションは、ＩＰベースのインターフェースを使用してワイヤレスデバイスを経由してこれらのワイヤレスデータサービスを取得することができ、これらのエンドアプリケーションは、ＩＰベースのフレームワーク上で動作する、ウェブブラウザなど、標準のＩＰベースのプロトコルを使用することができ」るのである。
　ここで、動的ホストコンフィギュレーションプロトコル（ＤＨＣＰ）サーバとは、予めＤＨＣＰクライアント用にいくつかのＩＰアドレスを用意しておき、ＤＨＣＰクライアントの要求に応じて、この中から１つのアドレスを割り当てるものであることは、当業者に自明である。
　また、「ＩＰベースのプロトコル」がネットワーク層データ転送プロトコルであることも自明である。
　そうすると、引用発明の「ワイヤレスデバイス１２０」と「ＴＥ２デバイス１１０」との間には、ネットワーク層データ転送プロトコルに基づく通信リンクが確立しているといえ、引用発明も、本願発明にいう「前記無線端末によって、前記ＵＳＢポートを経由した前記ホストデバイスとのインタラクションを介して、前記無線端末と前記ホストデバイスとの間の前記ネットワーク層データ転送プロトコルに基づく通信リンクを確立するステップ」であって、「前記無線端末によって、ＤＨＣＰを使用することによって、前記無線端末及び前記ホストデバイスにＩＰアドレスを割り当てるとともに、前記無線端末と前記ホストデバイスとの間の前記ネットワーク層データ転送プロトコルに基づく前記通信リンクを確立するステップ」を有するものといえる。
（４）引用発明においても、「トランスポート層データ」は、「ＩＰパケットの形でカプセル化」され、これらの「ＩＰパケット」は、ワイヤレスデバイス１２０とＴＥ２デバイス１１０との間で交換されるから、本願発明にいう「前記無線端末によって、ネットワーク層データ転送プロトコルに基づく通信リンクを経由して、１又は２以上のサービスについてのサービスパケット及び前記サービスパケットのタイプを送信するステップ」を有するものといえる。
（５）よって、本願発明と引用発明とは、以下の点で一致し、相違する。
（一致点）
「無線端末のための通信方法であって、
　無線端末を、無線端末のＵＳＢポートを介してホストデバイスに接続し、データ転送を可能な状態にするステップと、
　前記無線端末によって、前記ＵＳＢポートを経由した前記ホストデバイスとのインタラクションを介して、前記無線端末と前記ホストデバイスとの間のネットワーク層データ転送プロトコルに基づく通信リンクを確立するステップと、
　前記無線端末によって、ネットワーク層データ転送プロトコルに基づく通信リンクを経由して、１又は２以上のサービスについてのサービスパケット及び前記サービスパケットのタイプを送信するステップと、
　を含み、
　前記無線端末によって、前記ＵＳＢポートを経由した前記ホストデバイスとのインタラクションを介して、前記無線端末と前記ホストデバイスとの間の前記ネットワーク層データ転送プロトコルに基づく通信リンクを確立するステップは、特に、
　前記無線端末によって、ＤＨＣＰを使用することによって、前記無線端末及び前記ホストデバイスにＩＰアドレスを割り当てるとともに、前記無線端末と前記ホストデバイスとの間の前記ネットワーク層データ転送プロトコルに基づく前記通信リンクを確立するステップを含む、無線端末のための通信方法。」
（相違点）
　無線端末を、無線端末のＵＳＢポートを介してホストデバイスに接続し、データ転送を可能な状態にするステップが、本願発明では、「無線端末によって、前記無線端末のＵＳＢポートのポートタイプをホストデバイスに通知するステップであって、前記ポートタイプはネットワーク層データ転送プロトコルに基づき、その結果、前記ポートタイプに対応するポートドライバを使用することによって、ホストデバイスが前記ＵＳＢポートを駆動するステップ」であるのに対し、引用発明では、そのような特定がない点。
４．判断
　本願発明は、「無線端末」と「ホストデバイス」とをＵＳＢ接続するものであるから、上記技術常識Ａに鑑みれば、本願発明の「無線端末によって、前記無線端末のＵＳＢポートのポートタイプをホストデバイスに通知するステップ」とは、無線端末とホストデバイスとをＵＳＢ接続する際に、プラグアンドプレイによって、特定の情報を記述したディスクリプタをホストデバイスに通知するステップであると解することができる。なお、このように解することは、平成２９年４月３日付け意見書の１（２）の審判請求人の主張とも整合する。
　そして、本願発明の「前記ポートタイプはネットワーク層データ転送プロトコルに基づき、その結果、前記ポートタイプに対応するポートドライバを使用することによって、ホストデバイスが前記ＵＳＢポートを駆動する」とは、上記ディスクリプタを通知した結果、ホストデバイスがネットワーク層データ転送プロトコルに基づく通信リンクに用いるポートドライバを使用してＵＳＢポートを駆動することを意味すると解することができる。
　一方、引用発明は、「ワイヤレスデバイス１２０」と「ＴＥデバイス１１０」とをＵＳＢ接続してデータ転送を可能な状態にした後、「ＤＨＣＰを伴う動的ＩＰコンフィギュレーション」によってネットワーク層データ転送プロトコルに基づく通信リンクを確立し、ＩＰパケットを交換するものであるところ、上記技術常識Ａに鑑みれば、引用発明において、「ワイヤレスデバイス１２０」と「ＴＥデバイス１１０」とをＵＳＢ接続する際に、「ＴＥデバイス１１０」が「ネットワーク層データ転送プロトコルに基づく通信リンク」に用いる「ポートドライバ」を使用してＵＳＢポートを駆動するよう、ＵＳＢデバイスである「ワイヤレスデバイス１２０」のクラス等の情報を記述したディスクリプタを「ＴＥデバイス１１０」に通知することは、当業者が容易になし得ることであるから、上記相違点に係る構成を想到することに格別の困難はない。
　なお、請求項１に係る発明は、「無線端末」がコミュニケーションクラスに準拠した機器であることを示す「ディスクリプタ」を通知することや、「ホストデバイス」のＯＳに予め用意された「ポートドライバ」を使用することについて限定するものではないが、仮にそのように限定的に解釈したとしても、ＵＳＢデバイスをコミュニケーションクラスに準拠した機器に見せかけることにより、ＵＳＢホストのＯＳに予め用意された標準クラスのポートドライバを使用することは、周知技術であるし（例えば、当審が平成２８年１２月２０日付けで通知した拒絶理由の引用文献２（特に、編集部による要約部分（ｐ６４第５−８行）及び「●ＵＳＢ仮想シリアル・ポートの仕組み」の欄（左欄下から３行目〜右欄第１０行）参照）又は同拒絶理由の引用文献３（特に、「ネットワークにおけるＵＳＢ機器の利用」の欄（ｐ６４）及び「ＵＳＢ接続のＰＤＡ」の欄（ｐ６５）参照。また、ｐ６７の左欄第１行−第６行及び※印の解説欄には、Ｌｉｎｕｘザウルス側のＤＨＣＰサーバにより、ＩＰアドレスを割り当てることも記載されている。）参照）、
　「無線端末」をＵＳＢデバイスとしてＵＳＢホストに接続し、ＵＳＢコミュニケーションデバイスクラス（ＣＤＣ）に対応したドライバを使用することも周知（例えば、当審が平成２８年１２月２０日付けで通知した拒絶理由の上記引用文献３又は同拒絶理由の引用文献４（特に、段落１７、段落２０、段落３４、図４Ｂ参照）。）であるから、「無線端末」が、コミュニケーションクラスに準拠した機器であることを示す「ディスクリプタ」を通知し、「ホストデバイス」のＯＳに予め用意された「ポートドライバ」を使用することも、当業者が容易になし得ることである。
　したがって、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
第５　むすび
　以上のとおり、本願の請求項１に係る発明は、引用文献１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願の他の請求項について検討するまでもなく、また、他の理由について検討するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。