【事件の表示】
　特願２０１１−１３１１７０「バイナリパケット中継システムおよび方法」拒絶査定不服審判事件〔平成２４年　１月　５日出願公開、特開２０１２−　　３７６３、請求項の数（６）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯　
　本願は、平成２３年６月１３日（パリ条約による優先権主張２０１０年６月１６日、大韓民国）の出願であって、平成２７年１月２３日付けで拒絶理由が通知され、同年４月２７日付けで手続補正がされ、同年５月２１日付けで拒絶査定がされ、これに対し、同年９月２５日に拒絶査定不服審判が請求され、同時に、手続補正がされたものである。
第２　平成２７年９月２５日付けの手続補正（以下、「本件補正」という。）の適否
１．補正の内容
（１）請求項１について
　本件補正は、特許請求の範囲の請求項１を
「バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、
　前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、
　前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部と、
　を備え、
　前記変換部は、
　前記受信したバイナリパケットを復号化するコーディング部と、
　前記コーディング部が復号化したバイナリパケットに含まれた情報をログに管理するログ管理部と、
　前記コーディング部が復号化したバイナリパケットをＨＴＴＰパケットに変換するコンバータ部と、
　を備え、
　前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰパケットを符号化してマップタイプに変換してから、バイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする中継サーバ。」とする補正（以下、「補正事項１」という。）を含んでいる。
（２）請求項４について
　本件補正は、特許請求の範囲の請求項４を
「バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、
　前記バイナリパケットをＨＴＴＰパケットに変換するステップと、
　前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するステップと、
　を含み、
　前記変換するステップは、
　前記受信したバイナリパケットを復号化するステップと、
　復号化したバイナリパケットに含まれた情報をログに格納するステップと、
　前記復号化したバイナリパケットをＨＴＴＰパケットに変換するステップと、
　を含み、
　前記変換するステップは、前記ウェブサービスサーバから受信したＨＴＴＰパケットを符号化してマップタイプに変換してから、バイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とするパケット中継方法。」とする補正(以下、「補正事項２」という。)を含んでいる。
２．補正の適否
（１）補正事項１について
　本件補正のうち、上記補正事項１は、請求項１に記載した発明を特定するために必要な事項である「変換部」について、「前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰパケットを符号化してマップタイプに変換してから、バイナリパケットに変換して前記アプリケーションサーバに送信する」との限定を付加するものであって、補正前の請求項１に記載された発明と補正後の請求項１に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから、特許法第１７条の２第５項第２号の特許請求の範囲の限定的な減縮を目的とするものに該当する。
　また、特許法第１７条の２第３項、第４項に違反するところはない。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「補正発明１」という。）が特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について以下に検討する。
ア　引用文献の記載事項
　原査定の拒絶の理由に引用された特開２００９−１１７１２号公報（以下、「引用文献１」という。）には、次のとおりの記載がある。
あ　「【００３１】
（ウェブクライアントシステムの全体構成）
　まず、ウェブクライアントシステムの全体構成について、図１を参照しながら説明する。ウェブクライアントシステム１０は、少なくとも
ゲームサーバ１００と携帯電話３００と携帯ウェブサーバ４００と携帯プロキシサーバ５００とを有している。これらの機器は、ネットワーク６００または専用ネットワークを介して接続されている。
【００３２】
　ゲームサーバ１００は、ネットワーク６００を介してオンラインゲームの参加希望者にオンラインゲームを提供する。本システムでは、ゲームサーバ１００により実際のオンラインゲームプログラムの主な実行とデータの管理が行われるクライアント・サーバ方式が採用されている。
【００３３】
　携帯電話３００は、汎用ブラウザ機能を有する情報機器の一例であり、携帯ウェブサーバ４００により提供されるウェブ画面を用いてオンラインゲームに関するサービスを要求するためのコマンドを送信する。携帯電話３００は、ゲームクライアント機器２００のように専用アプリケーションを持たないためゲーム機としての機能を充分に有しないが、携帯ウェブサーバ４００に接続可能な機器であれば、ＰＤＡ（Ｐｅｒｓｏｎａｌ　Ｄｉｇｉｔａｌ　Ａｓｓｉｓｔａｎｔｓ））等、いかなる電子機器であってもよい。
【００３４】
　
携帯ウェブサーバ４００は、ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）システムにおいて情報送信を行うコンピュータである。携帯ウェブサーバ４００は、ＨＴＭＬ文書や画像などの情報を蓄積し、ウェブブラウザとして機能する携帯電話３００からの要求に応じて、インターネットなどのネットワーク６００を介してこれらの情報を送信する。
【００３５】
　
携帯プロキシサーバ５００は、ゲームサーバ１００と携帯電話３００とのやり取りを仲介する。すなわち、携帯プロキシサーバ５００は、携帯電話３００から送信された要求コマンドに応じてゲームサーバ１００との通信を確立し、携帯電話３００に代わってゲームサーバ１００とデータ通信する。
い　「【００６６】
　実際には、ゲームサーバ１００が送信するデータ（たとえばアイテム取得通知）は、直接携帯電話３００が携帯ウェブブラウザで読める形式にはなっていない。そのため、
携帯プロキシサーバ５００は、ゲームサーバ１００から提供されるオンラインゲームに関するサービスを携帯ウェブサーバ４００が解釈可能なテキスト形式に変換する。同様にして、携帯プロキシサーバ５００は、携帯電話３００から送信された要求コマンドをゲームサーバ１００が解釈可能な形式に変換する。
【００６７】
　より具体的には、
携帯ウェブサーバ４００が携帯電話３００とやり取りするのは通常のウェブページと同様にテキスト形式のデータである。これに対して、ゲームクライアント機器２００がゲームサーバ１００とやり取りは、バイナリ形式のデータである。よって、携帯プロキシサーバ５００は、携帯ウェブサーバ４００からのテキスト形式のコマンドデータをバイナリ形式に変換してゲームサーバ１００に専用プロトコルで送信し、専用プロトコルによってゲームサーバ１００から送信されたバイナリ形式の返信をテキスト形式のデータに変換して携帯ウェブサーバ４００に返信する。
　下線部の記載によれば、引用文献１には、
「ネットワークで接続された、バイナリ形式のデータでやりとりを行うゲームサーバ１００と、携帯電話３００と、携帯ウェブサーバ４００と、携帯プロキシサーバ５００とを有するウェブクライアントシステムにおける携帯プロキシサーバ５００であって、
携帯ウェブサーバ４００は、ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）システムにおいて情報送信を行うコンピュータであり、ＨＴＭＬ文書や画像などの情報を蓄積し、ウェブブラウザとして機能する携帯電話３００からの要求に応じて、インターネットなどのネットワーク６００を介してこれらの情報を送信するものであり、
携帯ウェブサーバ４００からのテキスト形式のコマンドデータをバイナリ形式に変換してゲームサーバ１００に専用プロトコルで送信し、専用プロトコルによってゲームサーバ１００から送信されたバイナリ形式の返信を携帯ウェブサーバ４００が解釈可能なテキスト形式のデータに変換して携帯ウェブサーバ４００に返信する、
携帯プロキシサーバ５００。」の発明（以下、「引用発明１」という。）が記載されている。
イ　原査定の拒絶の理由に引用された国際公開第２００９／１３５９９５号（以下、「引用文献２」という。）には、次のとおりの記載がある。日本語訳は，引用文献２の翻訳文である特表２０１１−５２３８０４号公報（以下、「対応公報」という。）の記載を参照した。
あ　「　　Figure 1 illustrates an example of a network to which embodiments of the invention may be applied. The example network of Figure 1 comprises a low-power wireless network 100, Internet/Intranet 102 and an IP-based network with SOAP servers 104. The low-power wireless network may be connected to the Internet/Intranet and IP-based network via an intermediate SOAP node 106, which is physically either a wireless router between the low- power wireless network and the Internet/Intranet or an edge server located in the IP network.
　　In the Internet/Intranet 102 and the IP-based network with SOAP servers 104 SOAP messaging is implemented using XML encoding and transmitted using HTTP over TCP/IP.
　　The low-power wireless network 100 may be a multihop network comprising a set of wireless low-power nodes 108A - 108G. The low-power wireless nodes 108A - 108G make up the network using wireless links 110. The wireless links 110 may be realized using IEEE 802.15.4, with Internet  Protocol v6 (6lowpan), IEEE 802.15.4 with ZigBee, Bluetooth or Bluetooth Ultra Low Power (ULP), Low Power Wireless Local Area Network, proprietary low-power radio, cellular radio system or any other system suitable for low power transmission. IEEE stands for Institute of Electrical and Electronics Engineers.
　　In an embodiment, User Datagram Protocol (UDP) is utilized in low- power networks instead of TCP/IP. UDP does not guarantee reliability or ordering in the way that TCP does. Transmitted packets may be received out of order, they may be duplicated, or go missing. However, the protocol is fast and efficient and suitable for low-power situations. Low power networks are typically utilized in wireless automation, control and sensor applications. The usability of the embodiments of the invention does not depend upon the application of the low power network.
　　The low-power wireless nodes 108A - 108G may implement SOAP messaging by using a binary encoding detailed below. These nodes can forward, use and manipulate the binary SOAP messages within the network just as servers in the IP-based network XML encoded SOAP messages without the need for transformation between XML and binary encoding. Nodes may exchange binary encoded SOAP messages without any network support, as nodes 108F and 108F in Figure 1 .
　　When SOAP messages are transmitted between the low-power network 100 and the IP-based network 104, the messages must be transformed from the binary encoding to XML encoding and vice versa. In an embodiment, the transformation is made in the intermediate node 106. 
　　Figure 2 illustrates protocol stacks in XML-based and binary-based SOAP messaging. In the figure, a SOAP server 104, the intermediate node 106 and a low power node 108A are shown. The SOAP server 104 and the intermediate node 106 are connected with each other via an IP-based network, such as the Internet/Intranet 102. The intermediate node and a low power node 108A are connected with each other via a low power wireless link 110.
　　The intermediate node 106 communicates with the IP-based network with SOAP servers by using XML encoded SOAP messaging and with  the low-power nodes by using binary encoded SOAP messaging. In XML encoded SOAP messaging, the protocol stacks 200, 202 comprise a physical layer, followed by TCP/IP and HTTP. SOAP is transported on top of HTTP by using Request/Response POST or GET. The content of the SOAP message is encoded by using XML. HTTP may be replaced with other application protocols, such as SIP.
　　The binary encoded SOAP messaging is a compressed version of the XML encoded messaging. XML tags are replaced with binary equivalents and respective binding. The binary encoded SOAP messaging carries all the functionality of the SOAP messaging but requires only a very small transmission capacity, thus making it suitable for low-power and low-capacity networks. The transformation of XML encoded SOAP not only encodes the XML tags but also takes into account the HTTP and TCP/IP binding. Thus, SOAP may be transported over unreliable networks.」(第６頁第１８行〜第８頁第６行)
（当審訳： 図１は、本発明の実施形態が適用され得るネットワークの例を示す。
図１の例示のネットワークは、低電力無線ネットワーク１００、インターネット／イントラネット１０２、及びＳＯＡＰサーバ１０４を伴うＩＰベースのネットワークを含む。低電力無線ネットワークは、中間ノード１０６を介して、インターネット／イントラネット及びＩＰベースのネットワークに接続され得るが、該中間ノード１０６は物理的に、低電力無線ネットワークとインターネット／イントラネット間の無線ルータ、若しくは、ＩＰネットワーク内に配置されるエッジサーバである。
　
インターネット／イントラネット１０２及びＳＯＡＰサーバ１０４を伴うＩＰベースのネットワークでは、ＳＯＡＰメッセージングは、ＸＭＬエンコーディングを用いてインプリメントされ、ＨＴＴＰを用いてＴＣＰ／ＩＰにおいて伝送される。
　低電力無線ネットワーク１００は、無線低電力ノード１０８Ａ−１０８Ｇのセットを含むマルチホップネットワークであってもよい。低電力無線ノード１０８Ａ−１０８Ｇは、無線リンク１１０を用いてネットワークを形成する。無線リンク１１０は、インターネットプロトコルｖ６（６ｌｏｗｐａｎ）を伴うＩＥＥＥ８０２．１５．４を用いて、ＺｉｇＢｅｅ、Ｂｌｕｅｔｏｏｔｈ若しくはＢｌｕｅｔｏｏｔｈ  Ｕｌｔｒａ  Ｌｏｗ 　Ｐｏｗｅｒ（ＵＬＰ）、低電力無線ＬＡＮ、独自低電力無線通信、セル無線システム、又は低電力伝送に適切な他のシステムを伴うＩＥＥＥ８０２．１５．４を用いて、実現され得る。なお、ＩＥＥＥは、電気電子技術者協会を表す。
　一つの実施形態では、ユーザデータグラムプロトコル（ＵＤＰ）が、ＴＣＰ／ＩＰの代わりに、低電力ネットワーク内で利用される。ＵＤＰは、ＴＣＰのようには信頼性もオーダリングも保証しない。伝送されたパケットは、順序が狂って受信されることもあり、重複することもあり、紛失することもある。しかしながら、プロトコルは高速且つ効率的であり、低電力条件に適合する。低電力ネットワークは、通常、無線オートメーション、制御、及びセンサアプリケーションで利用される。本発明の実施形態の有用性は、低電力ネットワークのアプリケーションに依存しない。
　
低電力無線ノード１０８Ａ−１０８Ｇは、後で説明するバイナリエンコーディングを用いることにより、ＳＯＡＰメッセージングをインプリメントできる。
　
ＳＯＡＰメッセージが、低電力ネットワーク１００とＩＰベースのネットワーク１０４の間で伝送されるとき、メッセージは、バイナリエンコーディングからＸＭＬエンコーディングへ、及びその逆に、変換されなければならない。一つの実施形態では、変換は中間ノード１０６内で為される。
　図２は、ＸＭＬベースとバイナリベースのＳＯＡＰメッセージング内のプロトコルスタックを示す。図では、
ＳＯＡＰサーバ１０４、中間ノード１０６及び低電力ノード１０８Ａが示されている。ＳＯＡＰサーバ１０４と中間ノード１０６は、インターネット／イントラネット１０２などの、ＩＰベースのネットワークを介して相互に接続される。中間ノードと低電力ノード１０８Ａは、低電力無線リンク１１０を介して相互に接続する。
　
中間ノード１０６は、ＸＭＬ符号化ＳＯＡＰメッセージングを用いることによりＳＯＡＰサーバで、及び、バイナリ符号化ＳＯＡＰメッセージングを用いることにより低電力ノードで、ＩＰベースのネットワークと通信する。
　
バイナリ符号化ＳＯＡＰメッセージングは、ＸＭＬ符号化メッセージングの圧縮バージョンである。ＸＭＬタグは、バイナリの同等のもの及び夫々のバインディングと、置換される。バイナリ符号化ＳＯＡＰメッセージングは、ＳＯＡＰメッセージングの機能を全て坦持するが、非常に少ない伝送キャパシティしか要求しない。
ＸＭＬ符号化ＳＯＡＰの伝送は、ＸＭＬタグを符号化するだけでなく、ＨＴＴＰ及びＴＣＰ／ＩＰバインディングを考慮に入れることもする。
い　「　　In an embodiment, the network unit configured to perform SOAP encoding transformation between XML and binary messaging comprises a processor 206 utilizing a compression/decompression algorithm used in the transformation, and a memory 208 for storing a set of lookup tables which define the transformation.
　　In an embodiment, the set of lookup tables describe how a particular binding (SOAP/HTTP e.g.) maps to the low-power binary SOAP binding. The lookup tables tell how which transport methods of the bindings correspond with  each other. This describes how reliability is dealt with and which compression technique is used to transform the SOAP header and body.」（第８頁第２４行〜第９頁第２行）
（当審訳： 一つの実施形態では、ＸＭＬとバイナリメッセージングの間でＳＯＡＰエンコーディング変換を実行するように構成されたネットワークユニットは、変換で用いられる圧縮／復元アルゴリズムを利用するプロセッサ２０６、及び、変換を規定するルックアップテーブルのセットを格納するメモリ２０８を含む。
　一つの実施形態では、
ルックアップテーブルのセットは、特定のバインディング（ＳＯＡＰ／ＨＴＴＰなど）がどのように低電力バイナリＳＯＡＰバインディングにマップするかを、記載する。ルックアップテーブルは、バインディングのどのトランスポートメソッドがどのように相互に対応するかを、示す。
う　「　　In step 312, the header of the binary SOAP message is encoded. The encoding is partly based on the header of the XML encoded message. SOAP header processing rules may be encoded into the binary header. In addition, the binary header comprises transport related information which enables transporting the message over unreliable networks where HTTP and TCP/IP methods are not available.
　　In an embodiment, the version of the encoding and the namespace are encoded as the first bytes of the binary header.
　　In an embodiment, the HTTP packet type and response code (request, response and code, ack, put etc.) are encoded into the binary header. TCP/IP reliability may be replaced with an Acknowledgement field in the binary header. The Acknowledgement field indicates whether the recipient of the message should send an acknowledgement to the originator of the message after receiving the message.」（第９頁第２４行〜第１０頁第６行）
（当審訳：ステップ３１２にて、バイナリＳＯＡＰメッセージのヘッダが符号化される。エンコーディングは部分的に、ＸＭＬ符号化メッセージのヘッダに基づく。ＳＯＡＰヘッダ処理ルールは、バイナリヘッダに符号化され得る。更に、バイナリヘッダは、ＨＴＴＰ及びＴＣＰ／ＩＰメソッドが利用可能ではない信頼性に欠けるネットワークにおいてメッセージをトランスポートできるトランスポート関連情報を含む。
　一つの実施形態では、エンコーディング及びネームスペースのバージョンは、バイナリヘッダの１番目のバイトとして、符号化される。
　一つの実施形態では、
ＨＴＴＰパケットタイプ及びレスポンスコード（リクエスト、レスポンス及びコード、アクノレッジ、プットなど）は、バイナリヘッダに符号化される。
（対応公報の段落【００４２】〜【００４４】）
え　「　　In the opposite transform direction, the process is reversed. The lookup table 208 of the message namespace is utilized to reconstruct the full XML/SOAP message along with the binding mapping to the selected application protocol, such as HTTP or SIP. Thus, the binary header comprising the application protocol packet type and response code are transformed to actual application protocol packet with correct packet type and response code.  The following is a very basic example of a SOAP message carried in HTTP.」（第１０頁第１行〜第６行）
（当審訳：反対の変換方向では、プロセスは逆である。
メッセージネームスペースのルックアップテーブル２０８は、ＨＴＴＰ若しくはＳＩＰなどの、選択されたアプリケーションプロトコルへのバインディングマッピングと共に、完全なＸＭＬ／ＳＯＡＰメッセージを再構築するのに利用される。
アプリケーションプロトコルパケットタイプ及びレスポンスコードを含むバイナリヘッダは、正確なパケットタイプ及びレスポンスコードを伴う実際のアプリケーションプロトコルパケットに変換される。
　下線部の記載によれば、引用文献２には、
「低電力無線ネットワーク１００、インターネット／イントラネット１０２、及びＳＯＡＰサーバ１０４を伴うＩＰベースのネットワークを含み、低電力無線ネットワーク１００と、インターネット／イントラネット及びＩＰベースのネットワークとの間を介して接続される中間ノードであって、
　インターネット／イントラネット１０２及びＳＯＡＰサーバ１０４を伴うＩＰベースのネットワークでは、ＳＯＡＰメッセージングは、ＸＭＬエンコーディングを用いてインプリメントされ、ＨＴＴＰを用いてＴＣＰ／ＩＰにおいて伝送され、
　低電力無線ノード１０８Ａ−１０８Ｇでは、バイナリエンコーディングを用いることにより、ＳＯＡＰメッセージングをインプリメントされ、
　ＳＯＡＰメッセージが、低電力ネットワーク１００とＩＰベースのネットワーク１０４の間で伝送されるとき、メッセージを、バイナリエンコーディングからＸＭＬエンコーディングへ、及びその逆に、特定のバインディング（ＳＯＡＰ／ＨＴＴＰなど）がどのように低電力バイナリＳＯＡＰバインディングにマップするかを記載したルックアップテーブルを用いて変換し、
　ＸＭＬエンコーディングからバイナリエンコーディングへの変換は、ＨＴＴＰパケットタイプ及びレスポンスコード（リクエスト、レスポンス及びコード、アクノレッジ、プットなど）は、バイナリヘッダに符号化され、逆に、バイナリエンコーディングからＸＭＬエンコーディングの変換は、アプリケーションプロトコルパケットタイプ及びレスポンスコードを含むバイナリヘッダは、正確なパケットタイプ及びレスポンスコードを伴う実際のアプリケーションプロトコルパケットに変換され、
　ＸＭＬ符号化ＳＯＡＰメッセージングを用いることによりＳＯＡＰサーバで、及び、バイナリ符号化ＳＯＡＰメッセージングを用いることにより低電力ノードで、ＩＰベースのネットワークと通信する
　中間ノード。」の発明（以下、「引用発明２」という。）が記載されている。
ウ　対比
　補正発明１と引用発明１とを対比する。
　引用発明１の「専用プロトコルによって」、「バイナリ形式のデータでやりとりを行うゲームサーバ１００」は、補正発明１の「バイナリプロトコルを用いるアプリケーションサーバ」に相当する。
　また、引用発明１の「携帯ウェブサーバ４００」は、ＷＷＷシステムにおいて情報送信を行い、ＨＴＭＬ文書や画像などの情報を蓄積し、ウェブブラウザとして機能する携帯電話３００からの要求に応じて、インターネットなどのネットワーク６００を介してこれらの情報を送信するから、ＨＴＴＰプロトコルを用いていることは明らかであり、引用発明１の「ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）システムにおいて情報送信を行うコンピュータであり、ＨＴＭＬ文書や画像などの情報を蓄積し、ウェブブラウザとして機能する携帯電話３００からの要求に応じて、インターネットなどのネットワーク６００を介してこれらの情報を送信する」「携帯ウェブサーバ４００」は、補正発明１の「ＨＴＴＰプロトコルを用いるウェブサービスサーバ」に相当する。　
　また、引用発明１の「専用プロトコルによってゲームサーバ１００から送信されたバイナリ形式の返信を携帯ウェブサーバ４００が解釈可能なテキストデータに変換する」ことと、補正発明１の「バイナリパケットをＨＴＴＰパケットに変換する」こととは、いずれも、「バイナリ形式のデータをＨＴＴＰ形式のデータに変換する」という点で共通し、引用発明１が「変換部」といえる構成を有することは明らかである。
　また、引用発明１の「テキスト形式」のデータを「携帯ウェブサーバ４００」に返信することと、補正発明１の「ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信する」こととは、「ＨＴＴＰ形式のデータをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信する」点で共通し、引用発明１が「ウェブ送受信部」といえる構成を有することは明らかである。
　また、引用発明１の「専用プロトコルによってゲームサーバ１００から送信されたバイナリ形式の返信を携帯ウェブサーバ４００が解釈可能なテキスト形式のデータに変換」することと、補正発明１の「前記変換部は、前記受信したバイナリパケットを復号化するコーディング部と、前記コーディング部が復号化したバイナリパケットに含まれた情報をログに管理するログ管理部と、前記コーディング部が復号化したバイナリパケットをＨＴＴＰパケットに変換するコンバータ部と、を備え」ることは、いずれも、「変換部」が、「受信したバイナリ形式のデータをＨＴＴＰ形式のデータに変換する」点で共通する。
　また、引用発明１の「携帯プロキシサーバ」が、「携帯ウェブサーバ４００からのテキスト形式のコマンドデータをバイナリ形式に変換してゲームサーバ１００に専用プロトコルで送信」することと、補正発明１の「前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰパケットを符号化してマップタイプに変換してから、バイナリパケットに変換して前記アプリケーションサーバに送信すること」とは、いずれも「変換部」は、「前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰ形式のデータをバイナリ形式のデータに変換して前記アプリケーションサーバに送信すること」である点で共通する。
　したがって、補正発明１と引用発明１とは、次の一致点、相違点を有する。
［一致点］
　バイナリプロトコルを用いるアプリケーションサーバからバイナリ形式のデータを受信するバイナリ送受信部と、
　前記バイナリ形式のデータをＨＴＴＰ形式のデータに変換する変換部と、
　前記ＨＴＴＰ形式のデータをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部と、
　を備え、
　前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰ形式のデータをバイナリ形式のデータに変換して前記アプリケーションサーバに送信する
　中継サーバ。
［相違点１］
　バイナリ送受信部が受信する「バイナリ形式のデータ」が、補正発明１では、「バイナリパケット」であるのに対し、引用発明１では、パケットであることの特定がない点。
［相違点２］
　「バイナリ形式のデータ」を「ＨＴＴＰ形式のデータ」に変換する変換部が、補正発明１では、「バイナリパケット」を「ＨＴＴＰパケット」に変換する変換部であるのに対し、引用発明１では、パケットを変換する変換部であることの特定がない点。
［相違点３］
　ウェブ送受信部が送信する「ＨＴＴＰ形式のデータ」が、補正発明１では、「ＨＴＴＰパケット」であるのに対し、引用発明１では、パケットであることの特定がない点。
［相違点４］
　「ＨＴＴＰ形式のデータ」を「バイナリ形式のデータ」に変換して前記アプリケーションサーバに送信する変換部が、補正発明１では、「ＨＴＴＰパケット」を「バイナリパケット」に変換する変換部であるのに対し、引用発明１では、パケットを変換する変換部であることの特定がない点。
［相違点５］
　変換部が、バイナリ形式のデータをＨＴＴＰ形式のデータに変換する際に、補正発明１は、コーディング部によってバイナリパケットを復号化し、コンバータ部により、復号化したバイナリパケットをＨＴＴＰパケットに変換するの対し、引用発明１では、コーディング部、コンバータ部の特定がない点。
［相違点６］
　変換部が、補正発明１では、「コーディング部が復号化したバイナリパケットに含まれた情報をログに管理するログ管理部」を備えるのに対し、引用発明１では、そのようなログの管理を行っていない点。
［相違点７］
　変換部が、ＨＴＴＰ形式のデータをバイナリ形式のデータに変換する際に、補正発明１では、ＨＴＴＰパケットを符号化してマップタイプに変換してから、バイナリパケットに変換しているのに対し、引用発明１では、マップタイプに変換していない点。
エ　判断
　上記相違点について検討する。
［相違点６］について
　引用文献２には、「コーディング部が復号化したバイナリパケットに含まれた情報をログに管理するログ管理部」は記載も示唆もされていない。
　パケットをログとして管理することは周知技術であるが、通常は、パケットをそのままログとして管理するから、引用発明１において、バイナリパケットを復号化して復号化したバイナリパケットに含まれた情報をログとして管理することが、当業者が容易に想到し得た事項であるとはいえない。
［相違点７］について
　引用文献２には、「ＨＴＴＰパケットを符号化してマップタイプに変換してから、バイナリパケットに変換」することは、記載も示唆もされていない。
　前置報告書において挙げられた「望月祐洋,ヰキφによるユビキタス複合サービス開発支援,情報処理学会論文誌,社団法人情報処理学会2008年6月15日,Vol.49,No.6,pp.1920-1931」のp.1926右欄「4.6要素サービス間通信」には、各要素サービスは必ずしもRubyで実装されるとは限らないため、要素サービスとRindaタプルスペースの間の通信では中間形式としてＪＳＯＮ形式の文字列を採用し、各言語のHashオブジェクトや辞書形オブジェクトの間で相互変換を行うことが記載され、ＪＳＯＮ形式はマップタイプともいい得るが、引用発明１においては、多対１ではなく、１対１の変換であるから、中間形式を採用する必然性はなく、引用発明１において、ＨＴＴＰパケットからバイナリパケットに変換する際にマップタイプに変換することが、当業者が容易に想到し得た事項であるとはいえない。
　したがって、相違点１〜５について判断するまでもなく、補正発明１は、引用発明１に基づいて、当業者が容易に発明をすることができたとはいえない。
　また、補正発明１と引用発明２とについても、上記の相違点６，７を有するから、補正発明１は、引用発明２に基づいて、当業者が容易に発明をすることができたとはいえない。
　よって、本件補正の補正事項１は、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合する。
（２）補正事項２について
　補正発明４は、補正事項１と同様の補正事項を含み、請求項１の「中継サーバ」を「パケット中継方法」として記載したものであるから、補正発明１と同様に、当業者が引用発明１，２に基づいて容易に発明をすることができたものではない。
　よって、本件補正の補正事項２についても、補正事項１と同様に、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合する。
３．むすび
　本件補正は、特許法第１７条の２第３項ないし第６項の規定に適合する。
第３　本願発明
　本件補正は上記のとおり、特許法第１７条の２第３項ないし第６項の規定に適合するから、本願の請求項１〜６に係る発明は、本件補正により補正された特許請求の範囲の請求項１〜６に記載された事項により特定されるとおりのものである。
　そして、補正発明１及び補正発明４は、上記第２の２．のとおり、当業者が引用発明１，２に基づいて容易に発明をすることができたものではない。
　また、補正発明１を直接又は間接的に引用する請求項２〜３は、補正発明１をさらに限定した発明であるから、当業者が引用発明１，２に基づいて容易に発明をすることができたものではない。
　また、補正発明４を直接又は間接的に引用する請求項５，６は、請求項４に係る発明をさらに限定した発明であるから、当業者が引用発明１，２に基づいて容易に発明をすることができたものではない。
　したがって、本願については、原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。