• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06F
管理番号 1320120
審判番号 不服2015-17462  
総通号数 203 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-11-25 
種別 拒絶査定不服の審決 
審判請求日 2015-09-25 
確定日 2016-10-25 
事件の表示 特願2011-131170「バイナリパケット中継システムおよび方法」拒絶査定不服審判事件〔平成24年 1月 5日出願公開、特開2012- 3763、請求項の数(6)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成23年6月13日(パリ条約による優先権主張2010年6月16日、大韓民国)の出願であって、平成27年1月23日付けで拒絶理由が通知され、同年4月27日付けで手続補正がされ、同年5月21日付けで拒絶査定がされ、これに対し、同年9月25日に拒絶査定不服審判が請求され、同時に、手続補正がされたものである。

第2 平成27年9月25日付けの手続補正(以下、「本件補正」という。)の適否
1.補正の内容
(1)請求項1について
本件補正は、特許請求の範囲の請求項1を
「バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、
前記バイナリパケットをHTTPパケットに変換する変換部と、
前記HTTPパケットをHTTPプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部と、
を備え、
前記変換部は、
前記受信したバイナリパケットを復号化するコーディング部と、
前記コーディング部が復号化したバイナリパケットに含まれた情報をログに管理するログ管理部と、
前記コーディング部が復号化したバイナリパケットをHTTPパケットに変換するコンバータ部と、
を備え、
前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したHTTPパケットを符号化してマップタイプに変換してから、バイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする中継サーバ。」とする補正(以下、「補正事項1」という。)を含んでいる。

(2)請求項4について
本件補正は、特許請求の範囲の請求項4を
「バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、
前記バイナリパケットをHTTPパケットに変換するステップと、
前記HTTPパケットをHTTPプロトコルを用いるウェブサービスサーバに送信するステップと、
を含み、
前記変換するステップは、
前記受信したバイナリパケットを復号化するステップと、
復号化したバイナリパケットに含まれた情報をログに格納するステップと、
前記復号化したバイナリパケットをHTTPパケットに変換するステップと、
を含み、
前記変換するステップは、前記ウェブサービスサーバから受信したHTTPパケットを符号化してマップタイプに変換してから、バイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とするパケット中継方法。」とする補正(以下、「補正事項2」という。)を含んでいる。

2.補正の適否
(1)補正事項1について
本件補正のうち、上記補正事項1は、請求項1に記載した発明を特定するために必要な事項である「変換部」について、「前記ウェブ送受信部が前記ウェブサービスサーバから受信したHTTPパケットを符号化してマップタイプに変換してから、バイナリパケットに変換して前記アプリケーションサーバに送信する」との限定を付加するものであって、補正前の請求項1に記載された発明と補正後の請求項1に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから、特許法第17条の2第5項第2号の特許請求の範囲の限定的な減縮を目的とするものに該当する。
また、特許法第17条の2第3項、第4項に違反するところはない。
そこで、本件補正後の前記請求項1に記載された発明(以下、「補正発明1」という。)が特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について以下に検討する。

ア 引用文献の記載事項
原査定の拒絶の理由に引用された特開2009-11712号公報(以下、「引用文献1」という。)には、次のとおりの記載がある。

あ 「【0031】
(ウェブクライアントシステムの全体構成)
まず、ウェブクライアントシステムの全体構成について、図1を参照しながら説明する。ウェブクライアントシステム10は、少なくともゲームサーバ100と携帯電話300と携帯ウェブサーバ400と携帯プロキシサーバ500とを有している。これらの機器は、ネットワーク600または専用ネットワークを介して接続されている。ウェブクライアントシステム10は、ネットワーク600を介してゲームサーバ100から直接オンラインゲームのサービスを受けることができる専用アプリケーションを持ったゲームクライアント機器200a?200cを含んでいてもよい。
【0032】
ゲームサーバ100は、ネットワーク600を介してオンラインゲームの参加希望者にオンラインゲームを提供する。本システムでは、ゲームサーバ100により実際のオンラインゲームプログラムの主な実行とデータの管理が行われるクライアント・サーバ方式が採用されている。
【0033】
携帯電話300は、汎用ブラウザ機能を有する情報機器の一例であり、携帯ウェブサーバ400により提供されるウェブ画面を用いてオンラインゲームに関するサービスを要求するためのコマンドを送信する。携帯電話300は、ゲームクライアント機器200のように専用アプリケーションを持たないためゲーム機としての機能を充分に有しないが、携帯ウェブサーバ400に接続可能な機器であれば、PDA(Personal Digital Assistants))等、いかなる電子機器であってもよい。
【0034】
携帯ウェブサーバ400は、WWW(World Wide Web)システムにおいて情報送信を行うコンピュータである。携帯ウェブサーバ400は、HTML文書や画像などの情報を蓄積し、ウェブブラウザとして機能する携帯電話300からの要求に応じて、インターネットなどのネットワーク600を介してこれらの情報を送信する。
【0035】
携帯プロキシサーバ500は、ゲームサーバ100と携帯電話300とのやり取りを仲介する。すなわち、携帯プロキシサーバ500は、携帯電話300から送信された要求コマンドに応じてゲームサーバ100との通信を確立し、携帯電話300に代わってゲームサーバ100とデータ通信する。これにより取得したオンラインゲームに関するサービス情報は携帯電話300に伝達される。」(下線は、当審が付した。以下、同様。)

い 「【0066】
実際には、ゲームサーバ100が送信するデータ(たとえばアイテム取得通知)は、直接携帯電話300が携帯ウェブブラウザで読める形式にはなっていない。そのため、携帯プロキシサーバ500は、ゲームサーバ100から提供されるオンラインゲームに関するサービスを携帯ウェブサーバ400が解釈可能なテキスト形式に変換する。同様にして、携帯プロキシサーバ500は、携帯電話300から送信された要求コマンドをゲームサーバ100が解釈可能な形式に変換する。
【0067】
より具体的には、携帯ウェブサーバ400が携帯電話300とやり取りするのは通常のウェブページと同様にテキスト形式のデータである。これに対して、ゲームクライアント機器200がゲームサーバ100とやり取りは、バイナリ形式のデータである。よって、携帯プロキシサーバ500は、携帯ウェブサーバ400からのテキスト形式のコマンドデータをバイナリ形式に変換してゲームサーバ100に専用プロトコルで送信し、専用プロトコルによってゲームサーバ100から送信されたバイナリ形式の返信をテキスト形式のデータに変換して携帯ウェブサーバ400に返信する。」

下線部の記載によれば、引用文献1には、
「ネットワークで接続された、バイナリ形式のデータでやりとりを行うゲームサーバ100と、携帯電話300と、携帯ウェブサーバ400と、携帯プロキシサーバ500とを有するウェブクライアントシステムにおける携帯プロキシサーバ500であって、
携帯ウェブサーバ400は、WWW(World Wide Web)システムにおいて情報送信を行うコンピュータであり、HTML文書や画像などの情報を蓄積し、ウェブブラウザとして機能する携帯電話300からの要求に応じて、インターネットなどのネットワーク600を介してこれらの情報を送信するものであり、
携帯ウェブサーバ400からのテキスト形式のコマンドデータをバイナリ形式に変換してゲームサーバ100に専用プロトコルで送信し、専用プロトコルによってゲームサーバ100から送信されたバイナリ形式の返信を携帯ウェブサーバ400が解釈可能なテキスト形式のデータに変換して携帯ウェブサーバ400に返信する、
携帯プロキシサーバ500。」の発明(以下、「引用発明1」という。)が記載されている。

イ 原査定の拒絶の理由に引用された国際公開第2009/135995号(以下、「引用文献2」という。)には、次のとおりの記載がある。日本語訳は,引用文献2の翻訳文である特表2011-523804号公報(以下、「対応公報」という。)の記載を参照した。

あ 「 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.」(第6頁第18行?第8頁第6行)
(当審訳: 図1は、本発明の実施形態が適用され得るネットワークの例を示す。図1の例示のネットワークは、低電力無線ネットワーク100、インターネット/イントラネット102、及びSOAPサーバ104を伴うIPベースのネットワークを含む。低電力無線ネットワークは、中間ノード106を介して、インターネット/イントラネット及びIPベースのネットワークに接続され得るが、該中間ノード106は物理的に、低電力無線ネットワークとインターネット/イントラネット間の無線ルータ、若しくは、IPネットワーク内に配置されるエッジサーバである。
インターネット/イントラネット102及びSOAPサーバ104を伴うIPベースのネットワークでは、SOAPメッセージングは、XMLエンコーディングを用いてインプリメントされ、HTTPを用いてTCP/IPにおいて伝送される。
低電力無線ネットワーク100は、無線低電力ノード108A-108Gのセットを含むマルチホップネットワークであってもよい。低電力無線ノード108A-108Gは、無線リンク110を用いてネットワークを形成する。無線リンク110は、インターネットプロトコルv6(6lowpan)を伴うIEEE802.15.4を用いて、ZigBee、Bluetooth若しくはBluetooth Ultra Low Power(ULP)、低電力無線LAN、独自低電力無線通信、セル無線システム、又は低電力伝送に適切な他のシステムを伴うIEEE802.15.4を用いて、実現され得る。なお、IEEEは、電気電子技術者協会を表す。
一つの実施形態では、ユーザデータグラムプロトコル(UDP)が、TCP/IPの代わりに、低電力ネットワーク内で利用される。UDPは、TCPのようには信頼性もオーダリングも保証しない。伝送されたパケットは、順序が狂って受信されることもあり、重複することもあり、紛失することもある。しかしながら、プロトコルは高速且つ効率的であり、低電力条件に適合する。低電力ネットワークは、通常、無線オートメーション、制御、及びセンサアプリケーションで利用される。本発明の実施形態の有用性は、低電力ネットワークのアプリケーションに依存しない。
低電力無線ノード108A-108Gは、後で説明するバイナリエンコーディングを用いることにより、SOAPメッセージングをインプリメントできる。IPベースのネットワーク内のサーバが、XMLとバイナリエンコーディングの間の伝送を必要としないで、XML符号化SOAPメッセージを進め、利用し操作するように、これらのノードは、ネットワーク内でバイナリSOAPメッセージを進め、利用し操作することができる。ノードは、図1のノード108Fとノード108Gのように、ネットワークのサポート無しで、バイナリ符号化SOAPメッセージを交換することができる。
SOAPメッセージが、低電力ネットワーク100とIPベースのネットワーク104の間で伝送されるとき、メッセージは、バイナリエンコーディングからXMLエンコーディングへ、及びその逆に、変換されなければならない。一つの実施形態では、変換は中間ノード106内で為される。
図2は、XMLベースとバイナリベースのSOAPメッセージング内のプロトコルスタックを示す。図では、SOAPサーバ104、中間ノード106及び低電力ノード108Aが示されている。SOAPサーバ104と中間ノード106は、インターネット/イントラネット102などの、IPベースのネットワークを介して相互に接続される。中間ノードと低電力ノード108Aは、低電力無線リンク110を介して相互に接続する。
中間ノード106は、XML符号化SOAPメッセージングを用いることによりSOAPサーバで、及び、バイナリ符号化SOAPメッセージングを用いることにより低電力ノードで、IPベースのネットワークと通信する。XML符号化SOAPメッセージングでは、プロトコルスタック200、202は、物理層を含み、続いてTCP/IP及びHTTPがある。SOAPは、リクエスト/レスポンスPOST若しくはGETを用いることにより、HTTPの上にトランスポートされる。SOAPメッセージのコンテンツは、XMLを用いることにより符号化される。HTTPは、SIPなどの、他のアプリケーションプロトコルと置換され得る。
バイナリ符号化SOAPメッセージングは、XML符号化メッセージングの圧縮バージョンである。XMLタグは、バイナリの同等のもの及び夫々のバインディングと、置換される。バイナリ符号化SOAPメッセージングは、SOAPメッセージングの機能を全て坦持するが、非常に少ない伝送キャパシティしか要求しない。よって、低電力及び低キャパシティネットワークには適切である。XML符号化SOAPの伝送は、XMLタグを符号化するだけでなく、HTTP及びTCP/IPバインディングを考慮に入れることもする。よって、SOAPは、信頼性に欠けるネットワークにおいても伝送され得る。)(対応公報の段落【0024】?【0032】)(下線は、当審が付した。以下、同様。)

い 「 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.」(第8頁第24行?第9頁第2行)
(当審訳: 一つの実施形態では、XMLとバイナリメッセージングの間でSOAPエンコーディング変換を実行するように構成されたネットワークユニットは、変換で用いられる圧縮/復元アルゴリズムを利用するプロセッサ206、及び、変換を規定するルックアップテーブルのセットを格納するメモリ208を含む。
一つの実施形態では、ルックアップテーブルのセットは、特定のバインディング(SOAP/HTTPなど)がどのように低電力バイナリSOAPバインディングにマップするかを、記載する。ルックアップテーブルは、バインディングのどのトランスポートメソッドがどのように相互に対応するかを、示す。これは、信頼性がどのように処理されるか、SOAPヘッダ及びボディを変換するのにどの圧縮技術が用いられるかを、記載する。)(対応公報の段落【0034】,【0035】)

う 「 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.」(第9頁第24行?第10頁第6行)
(当審訳:ステップ312にて、バイナリSOAPメッセージのヘッダが符号化される。エンコーディングは部分的に、XML符号化メッセージのヘッダに基づく。SOAPヘッダ処理ルールは、バイナリヘッダに符号化され得る。更に、バイナリヘッダは、HTTP及びTCP/IPメソッドが利用可能ではない信頼性に欠けるネットワークにおいてメッセージをトランスポートできるトランスポート関連情報を含む。
一つの実施形態では、エンコーディング及びネームスペースのバージョンは、バイナリヘッダの1番目のバイトとして、符号化される。
一つの実施形態では、HTTPパケットタイプ及びレスポンスコード(リクエスト、レスポンス及びコード、アクノレッジ、プットなど)は、バイナリヘッダに符号化される。TCP/IPの信頼性は、バイナリヘッダ内のアクノレッジメントフィールドで置換され得る。アクノレッジメントフィールドは、メッセージを受信した後、メッセージの受信者がアクノレッジメントをメッセージの発信元に送信すべきかどうかを示す。
(対応公報の段落【0042】?【0044】)

え 「 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.」(第10頁第1行?第6行)
(当審訳:反対の変換方向では、プロセスは逆である。メッセージネームスペースのルックアップテーブル208は、HTTP若しくはSIPなどの、選択されたアプリケーションプロトコルへのバインディングマッピングと共に、完全なXML/SOAPメッセージを再構築するのに利用される。よって、アプリケーションプロトコルパケットタイプ及びレスポンスコードを含むバイナリヘッダは、正確なパケットタイプ及びレスポンスコードを伴う実際のアプリケーションプロトコルパケットに変換される。)(対応公報の段落【0057】)

下線部の記載によれば、引用文献2には、
「低電力無線ネットワーク100、インターネット/イントラネット102、及びSOAPサーバ104を伴うIPベースのネットワークを含み、低電力無線ネットワーク100と、インターネット/イントラネット及びIPベースのネットワークとの間を介して接続される中間ノードであって、
インターネット/イントラネット102及びSOAPサーバ104を伴うIPベースのネットワークでは、SOAPメッセージングは、XMLエンコーディングを用いてインプリメントされ、HTTPを用いてTCP/IPにおいて伝送され、
低電力無線ノード108A-108Gでは、バイナリエンコーディングを用いることにより、SOAPメッセージングをインプリメントされ、
SOAPメッセージが、低電力ネットワーク100とIPベースのネットワーク104の間で伝送されるとき、メッセージを、バイナリエンコーディングからXMLエンコーディングへ、及びその逆に、特定のバインディング(SOAP/HTTPなど)がどのように低電力バイナリSOAPバインディングにマップするかを記載したルックアップテーブルを用いて変換し、
XMLエンコーディングからバイナリエンコーディングへの変換は、HTTPパケットタイプ及びレスポンスコード(リクエスト、レスポンス及びコード、アクノレッジ、プットなど)は、バイナリヘッダに符号化され、逆に、バイナリエンコーディングからXMLエンコーディングの変換は、アプリケーションプロトコルパケットタイプ及びレスポンスコードを含むバイナリヘッダは、正確なパケットタイプ及びレスポンスコードを伴う実際のアプリケーションプロトコルパケットに変換され、
XML符号化SOAPメッセージングを用いることによりSOAPサーバで、及び、バイナリ符号化SOAPメッセージングを用いることにより低電力ノードで、IPベースのネットワークと通信する
中間ノード。」の発明(以下、「引用発明2」という。)が記載されている。

ウ 対比
補正発明1と引用発明1とを対比する。
引用発明1の「専用プロトコルによって」、「バイナリ形式のデータでやりとりを行うゲームサーバ100」は、補正発明1の「バイナリプロトコルを用いるアプリケーションサーバ」に相当する。
また、引用発明1の「携帯ウェブサーバ400」は、WWWシステムにおいて情報送信を行い、HTML文書や画像などの情報を蓄積し、ウェブブラウザとして機能する携帯電話300からの要求に応じて、インターネットなどのネットワーク600を介してこれらの情報を送信するから、HTTPプロトコルを用いていることは明らかであり、引用発明1の「WWW(World Wide Web)システムにおいて情報送信を行うコンピュータであり、HTML文書や画像などの情報を蓄積し、ウェブブラウザとして機能する携帯電話300からの要求に応じて、インターネットなどのネットワーク600を介してこれらの情報を送信する」「携帯ウェブサーバ400」は、補正発明1の「HTTPプロトコルを用いるウェブサービスサーバ」に相当する。
また、引用発明1の「専用プロトコルによってゲームサーバ100から送信されたバイナリ形式の返信を携帯ウェブサーバ400が解釈可能なテキストデータに変換する」ことと、補正発明1の「バイナリパケットをHTTPパケットに変換する」こととは、いずれも、「バイナリ形式のデータをHTTP形式のデータに変換する」という点で共通し、引用発明1が「変換部」といえる構成を有することは明らかである。
また、引用発明1の「テキスト形式」のデータを「携帯ウェブサーバ400」に返信することと、補正発明1の「HTTPパケットをHTTPプロトコルを用いるウェブサービスサーバに送信する」こととは、「HTTP形式のデータをHTTPプロトコルを用いるウェブサービスサーバに送信する」点で共通し、引用発明1が「ウェブ送受信部」といえる構成を有することは明らかである。
また、引用発明1の「専用プロトコルによってゲームサーバ100から送信されたバイナリ形式の返信を携帯ウェブサーバ400が解釈可能なテキスト形式のデータに変換」することと、補正発明1の「前記変換部は、前記受信したバイナリパケットを復号化するコーディング部と、前記コーディング部が復号化したバイナリパケットに含まれた情報をログに管理するログ管理部と、前記コーディング部が復号化したバイナリパケットをHTTPパケットに変換するコンバータ部と、を備え」ることは、いずれも、「変換部」が、「受信したバイナリ形式のデータをHTTP形式のデータに変換する」点で共通する。
また、引用発明1の「携帯プロキシサーバ」が、「携帯ウェブサーバ400からのテキスト形式のコマンドデータをバイナリ形式に変換してゲームサーバ100に専用プロトコルで送信」することと、補正発明1の「前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したHTTPパケットを符号化してマップタイプに変換してから、バイナリパケットに変換して前記アプリケーションサーバに送信すること」とは、いずれも「変換部」は、「前記ウェブ送受信部が前記ウェブサービスサーバから受信したHTTP形式のデータをバイナリ形式のデータに変換して前記アプリケーションサーバに送信すること」である点で共通する。

したがって、補正発明1と引用発明1とは、次の一致点、相違点を有する。
[一致点]
バイナリプロトコルを用いるアプリケーションサーバからバイナリ形式のデータを受信するバイナリ送受信部と、
前記バイナリ形式のデータをHTTP形式のデータに変換する変換部と、
前記HTTP形式のデータをHTTPプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部と、
を備え、
前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したHTTP形式のデータをバイナリ形式のデータに変換して前記アプリケーションサーバに送信する
中継サーバ。

[相違点1]
バイナリ送受信部が受信する「バイナリ形式のデータ」が、補正発明1では、「バイナリパケット」であるのに対し、引用発明1では、パケットであることの特定がない点。
[相違点2]
「バイナリ形式のデータ」を「HTTP形式のデータ」に変換する変換部が、補正発明1では、「バイナリパケット」を「HTTPパケット」に変換する変換部であるのに対し、引用発明1では、パケットを変換する変換部であることの特定がない点。
[相違点3]
ウェブ送受信部が送信する「HTTP形式のデータ」が、補正発明1では、「HTTPパケット」であるのに対し、引用発明1では、パケットであることの特定がない点。
[相違点4]
「HTTP形式のデータ」を「バイナリ形式のデータ」に変換して前記アプリケーションサーバに送信する変換部が、補正発明1では、「HTTPパケット」を「バイナリパケット」に変換する変換部であるのに対し、引用発明1では、パケットを変換する変換部であることの特定がない点。
[相違点5]
変換部が、バイナリ形式のデータをHTTP形式のデータに変換する際に、補正発明1は、コーディング部によってバイナリパケットを復号化し、コンバータ部により、復号化したバイナリパケットをHTTPパケットに変換するの対し、引用発明1では、コーディング部、コンバータ部の特定がない点。
[相違点6]
変換部が、補正発明1では、「コーディング部が復号化したバイナリパケットに含まれた情報をログに管理するログ管理部」を備えるのに対し、引用発明1では、そのようなログの管理を行っていない点。
[相違点7]
変換部が、HTTP形式のデータをバイナリ形式のデータに変換する際に、補正発明1では、HTTPパケットを符号化してマップタイプに変換してから、バイナリパケットに変換しているのに対し、引用発明1では、マップタイプに変換していない点。

エ 判断
上記相違点について検討する。
[相違点6]について
引用文献2には、「コーディング部が復号化したバイナリパケットに含まれた情報をログに管理するログ管理部」は記載も示唆もされていない。
パケットをログとして管理することは周知技術であるが、通常は、パケットをそのままログとして管理するから、引用発明1において、バイナリパケットを復号化して復号化したバイナリパケットに含まれた情報をログとして管理することが、当業者が容易に想到し得た事項であるとはいえない。
[相違点7]について
引用文献2には、「HTTPパケットを符号化してマップタイプに変換してから、バイナリパケットに変換」することは、記載も示唆もされていない。
前置報告書において挙げられた「望月祐洋,ヰキ_(φ)によるユビキタス複合サービス開発支援,情報処理学会論文誌,社団法人情報処理学会2008年6月15日,Vol.49,No.6,pp.1920-1931」のp.1926右欄「4.6要素サービス間通信」には、各要素サービスは必ずしもRubyで実装されるとは限らないため、要素サービスとRindaタプルスペースの間の通信では中間形式としてJSON形式の文字列を採用し、各言語のHashオブジェクトや辞書形オブジェクトの間で相互変換を行うことが記載され、JSON形式はマップタイプともいい得るが、引用発明1においては、多対1ではなく、1対1の変換であるから、中間形式を採用する必然性はなく、引用発明1において、HTTPパケットからバイナリパケットに変換する際にマップタイプに変換することが、当業者が容易に想到し得た事項であるとはいえない。

したがって、相違点1?5について判断するまでもなく、補正発明1は、引用発明1に基づいて、当業者が容易に発明をすることができたとはいえない。
また、補正発明1と引用発明2とについても、上記の相違点6,7を有するから、補正発明1は、引用発明2に基づいて、当業者が容易に発明をすることができたとはいえない。
よって、本件補正の補正事項1は、特許法第17条の2第6項において準用する同法第126条第7項の規定に適合する。

(2)補正事項2について
補正発明4は、補正事項1と同様の補正事項を含み、請求項1の「中継サーバ」を「パケット中継方法」として記載したものであるから、補正発明1と同様に、当業者が引用発明1,2に基づいて容易に発明をすることができたものではない。
よって、本件補正の補正事項2についても、補正事項1と同様に、特許法第17条の2第6項において準用する同法第126条第7項の規定に適合する。

3.むすび
本件補正は、特許法第17条の2第3項ないし第6項の規定に適合する。

第3 本願発明
本件補正は上記のとおり、特許法第17条の2第3項ないし第6項の規定に適合するから、本願の請求項1?6に係る発明は、本件補正により補正された特許請求の範囲の請求項1?6に記載された事項により特定されるとおりのものである。

そして、補正発明1及び補正発明4は、上記第2の2.のとおり、当業者が引用発明1,2に基づいて容易に発明をすることができたものではない。
また、補正発明1を直接又は間接的に引用する請求項2?3は、補正発明1をさらに限定した発明であるから、当業者が引用発明1,2に基づいて容易に発明をすることができたものではない。
また、補正発明4を直接又は間接的に引用する請求項5,6は、請求項4に係る発明をさらに限定した発明であるから、当業者が引用発明1,2に基づいて容易に発明をすることができたものではない。
したがって、本願については、原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2016-10-11 
出願番号 特願2011-131170(P2011-131170)
審決分類 P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 ▲はま▼中 信行小林 義晴  
特許庁審判長 和田 志郎
特許庁審判官 稲葉 和生
高瀬 勤
発明の名称 バイナリパケット中継システムおよび方法  
代理人 特許業務法人高橋・林アンドパートナーズ  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ