【事件の表示】
　特願２０１３−５１４２２０「ネットワークベースのピアトゥピアトラフィック最適化」拒絶査定不服審判事件〔平成２３年１２月１５日国際公開、ＷＯ２０１１／１５６１９０、平成２５年　９月　９日国内公表、特表２０１３−５３５１３３、請求項の数（１０）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、２０１１年６月１日（パリ条約による優先権主張外国庁受理２０１０年６月１０日　米国）を国際出願日とする出願であって、平成２６年２月１４日付けで拒絶理由が通知され、同年５月１３日付けで手続補正がされ、同年１０月２８日付けで拒絶査定（以下、「原査定」という。）がされ、これに対し、平成２７年２月２５日に拒絶査定不服審判が請求されるとともに、同日付けで手続補正がされ、その後、当審において同年９月２５日付けで拒絶理由（以下、「当審拒絶理由」という。）が通知され、平成２８年３月２４日付けで手続補正がされたものである。
第２　本願発明
　本願の請求項１〜１０に係る発明は、平成２８年３月２４日付けの手続補正で補正された特許請求の範囲の請求項１〜１０に記載された事項により特定されるものと認められる。
　本願の請求項１に係る発明（以下、「本願発明」という。）は以下のとおりである。
「【請求項１】
　報復プロトコルを使用するピアトゥピアネットワークにおける逆方向リンクの帯域幅の消費を減少させるためのシステムであって、
　データネットワークと、
　前記データネットワークと関連して動作するピアトゥピアネットワークと、
　前記データネットワークからの順方向リンクの帯域幅が前記データネットワークへの逆方向リンクの帯域幅よりも大きい非対称接続を有するクライアントと、
　前記データネットワークの中に配置されたピアトゥピアプロキシサーバとを備え、
　前記ピアトゥピアプロキシサーバが前記ピアトゥピアネットワークに対してクライアントであるかのように動作し、逆方向リンクでのクライアントからピアトゥピアプロキシサーバへのファイルコンテンツの転送を要求することを回避するように、ピアトゥピアプロキシサーバが前記クライアントと前記ピアトゥピアネットワークとの間を透過的にインターフェースする専用の機能を有する、システム。」　
第３　原査定の理由について
１．原審の拒絶理由の概要
　この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　記
刊行物１：欧州特許出願公開第２１１２７８８号明細書
　刊行物１には、Ｐ２Ｐネットワークにおいて、アップリンクとダウンリンクとが非対称なレートを有している場合に、アップリンクのレートの不十分な帯域幅が消費されて競合が起こることを回避するために、スーパーノード（本願の「ピアトゥピアプロキシサーバ」に相当）が、ユーザノードと中継する役割を担うことの記載がなされている。（[0002]-[0007],[0029],[0056],FIG.2等）
　したがって、刊行物１に基づいて、請求項１に係る発明は進歩性を有しない。
　[原査定の理由の概要]
　刊行物１記載のスーパーノードは、段落[0007],[0056]等に記載されるように、ＴＵＲＮサーバとして、ＮＡＴ越えを実現するプライベートネットワーク内のユーザノードの通信を中継しているものである。すなわち、本来のＰ２Ｐ通信であればお互いのユーザノードが直接通信を行うところ、相手ユーザノードとの直接通信に換えてＴＵＲＮサーバと直接通信を行うことにより、結果的に両ユーザノードのＰ２Ｐ通信が確立されるというものである。
　してみれば、直接通信が前提のＰ２Ｐネットワークにおいて、送信側のユーザノードから見た場合に、直接通信の相手をスーパーノードとしている刊行物１のシステムは、スーパーノードを従来のＰ２Ｐネットワークにおける受信側のユーザノード（クライアント）であるかのように動作させているものとなるため、出願人の主張は採用できず、本願請求項１に係る発明は、依然として刊行物１の記載に基づいて当業者が容易に想到し得たものである。
２．原査定の理由の判断
（１）刊行物の記載事項
　原査定の拒絶の理由に引用された欧州特許出願公開第２１１２７８８号明細書（刊行物１）には、図面とともに以下の事項が記載されている。
イ．「Field of the Technology
 [0001] The present invention relates to the field of Internet technologies, and more particularly to a content sharing technique in the Internet. 
 Background of the Invention
 [0002] The conventional Internet adopts a client/server mode, and uses a centralized server on the website. However, the development trend of the Internet is from centralization to decentralization, and the centralized server is turned into distributed servers, for example, the peer-to-peer (P2P) technology. 
 [0003] The P2P technology integrates multiple users into a network, so as to share the bandwidth and co-process the information in the network. Different from the conventional client/server mode, in the P2P working mode, each client terminal functions as both the client and the server. 
 [0004] P2P sharing download is a common download mode. Hundreds of thousands of network users worldwide use bit torrent (BT) software to download entire movies, MP3, and large-scale software everyday, and the data traffic is above 70% of the world's total Internet data traffic. In the process of sharing download, each user terminal among multiple users that need to download the same file is only required to download a segment of the file and then exchanges with one another, so that each user may get the complete file eventually. 
 [0005] In the current P2P sharing download mode, BT is widely applied. As shown in FIG. 1, the network model of BT includes: a Webserver for placing files with suffix .torrent, a Tracker in charge of users finding each other, and common users. 
 [0006] The process of realizing BT sharing download specifically includes the following steps. 
1. Users that intend to share the content publish a file with suffix .torrent on a common Webserver, in which the file contains the length, name, and hash information about the shared file, Universal Resource Locator (URL) of the Tracker, and the like.
2. Users that want to get the shared content download the .torrent file from the common website Webserver and obtain the URL of the Tracker.
3. The users (including those intending to share the content and those wanting to get the shared content) communicate with the Tracker, and report to the Tracker that they are online and acquire the list of other peers (referring to the users that intend to share the content and those that want to get the shared content) from the Tracker.
4. A peer having the complete file is called a seed, and the users that intend to share the file divide the file into a plurality of fragments which are suitable for fragment sharing.
5. All the peers are in communication with each other to share the file, in which each peer requests its desired fragments from the other peers, and meanwhile distributes its own fragments to those requesting them.
6. After all the file content has been downloaded, exit the entire sharing process.」
訳文（イ．）「技術分野
［０００１］
　本発明は、インターネット技術の分野に関し、特に、インターネットにおけるコンテンツ共有技術に関する。
　背景技術
［０００２］
　従来のインターネットでは、クライアント／サーバモードが採用され、Ｗｅｂサイト上の集中型サーバが使用されている。しかし、インターネットの発展は集中化から分散化へ向かっており、集中型サーバは分散型サーバに、例えば、ＰｅｅｒツーＰｅｅｒ（Ｐ２Ｐ）技術に変化している。
［０００３］
　Ｐ２Ｐ技術では、複数のユーザをネットワーク内に統合して、帯域幅を共有し、ネットワーク内の情報を共同処理する。従来のクライアント／サーバモードとは異なり、Ｐ２Ｐ動作モードでは、各クライアント端末がクライアント及びサーバの両方として機能する。
［０００４］
　Ｐ２Ｐ共有ダウンロードは、一般的なダウンロードモードである。毎日、世界中の何十万ものネットワークユーザが、ビットトレント（ＢＴ）ソフトウェアを使用して、映画全体、ＭＰ３、及び大規模ソフトウェアをダウンロードしており、データトラフィックは、世界の総インターネットデータトラフィックの７０％を超えている。共有ダウンロードのプロセスにおいて、同じファイルをダウンロードする必要がある複数のユーザのうちの各ユーザ端末は、ファイルのセグメントをダウンロードする必要があるのみであり、次に、お互いに交換して、それにより、各ユーザは最終的に完全なファイルを得ることができる。
［０００５］
　現在のＰ２Ｐ共有ダウンロードモードでは、ＢＴが広く利用されている。図１に示すように、ＢＴのネットワークモデルは、接尾部．ｔｏｒｒｅｎｔを有するファイルを配置するためのＷｅｂサーバと、ユーザがお互いを見つけるのを管理するトラッカと、一般ユーザとを含む。
［０００６］
　ＢＴ共有ダウンロードを実現するプロセスは、具体的には以下のステップを含む。
　１．コンテンツを共有することを意図するユーザは、接尾部．ｔｏｒｒｅｎｔを有するファイルを一般的なＷｅｂサーバ上に発行し、そのファイルは、共有ファイルに関する長さと名前とハッシュ情報、及びトラッカのユニバーサルリソースロケータ（ＵＲＬ）などを含む。
　２．共有コンテンツを入手したいユーザは、一般的なＷｅｂサイトのＷｅｂサーバから．ｔｏｒｒｅｎｔファイルをダウンロードして、トラッカのＵＲＬを取得する。
　３．ユーザ（コンテンツを共有することを意図するユーザと、共有コンテンツを入手したいユーザとを含む）は、トラッカと通信を行い、それらのユーザがオンラインであることをトラッカに報告し、その他のｐｅｅｒｓ（コンテンツを共有することを意図するユーザと、共有コンテンツを入手したいユーザとを意味する）のリストをトラッカから取得する。
　４．完全なファイルを有するＰｅｅｒはシードと呼ばれ、ファイルを共有することを意図するユーザは、ファイルを、フラグメント共有に適した複数のフラグメントに分割する。
　５．全てのＰｅｅｒｓはファイルを共有するために相互に通信を行い、その通信の中で、各Ｐｅｅｒは、そのＰｅｅｒの所望するフラグメントをその他のＰｅｅｒに要求し、一方で、そのＰｅｅｒ自体のフラグメントを、それらのフラグメントを要求しているＰｅｅｒに分配する。
　６．全てのファイルコンテンツがダウンロードされた後で、共有プロセス全体を終了する。」
（当審注：訳文は、本願のパテントファミリーである特表２０１０−５２２３８６号公報の記載に基づいて合議体が作成した。以下同様。）
ロ．「[0007] It can be seen from the above BT sharing process that, the P2P network for BT sharing is a typical all for one, and one for all network, through which the resources of each user are fully shared. However, in this network, due to the true equality, no one wants to do any additional work voluntarily, so that the network has certain limitations which mainly lie in the following two points. 
1. When two users are behind network address translation (NAT), the addresses of the users are private network addresses, and the private network addresses cannot be directly accessed from the outside. In order to directly access the equipment in the private network, a mechanism of Simple Traversal of UDP Through Network Address Translators (STUN) or Traversal Using Relay NAT (TURN) is needed. However, in the current BT network, no corresponding unit can be adopted to coordinate and complete the work, so that the direct access of P2P cannot be realized.
2. When the network is an asymmetrical network, the overall sharing access rate is limited by the minimum rate, for example, in an asymmetrical digital subscriber line (ADSL) network, a typical down-rate is 8 M and a typical up-rate is 512 K. Simply from one user's point of view, as a plurality of other users may provide upload services for the user simultaneously, even if the up-rate of each user is not high enough, the total rate of the plurality of users may satisfy the requirement of one user for high-speed download. However, taking the situation of the whole network into account, under complete P2P, the total up-rate is definitely equal to the total down-rate. Therefore, even if the downlink bandwidth is wide enough, due to the limitation of the up-rate, the average down-rate of the users can only be the average up-rate of the network.
 SUMMARY OF THE INVENTION
 [0008] Accordingly, the present invention is directed to a method, system, and nodes for peer-to-peer (P2P) content sharing, which are capable of solving the problem in the prior art that the private network user node cannot realize P2P sharing and the P2P sharing access rate is limited by the lower rate in the up-rate and the down-rate. 
 [0009] In order to achieve the above objectives, the present invention provides the following technical solutions. 
 [0010] A method for P2P content sharing, in which a super node is selected from user nodes, includes the following steps. 
 [0011] The super node receives a request for fragments from a common user node, and checks itself to see whether the fragments requested by the common user node are stored therein or not. If yes, the super node uploads its stored fragments to be shared by the common user node; otherwise, the super node requests the fragments desired by the common user node from other super nodes or common user nodes, and uploads the obtained fragments to be shared by the common user node. 
 [0012] A system for P2P content sharing includes a tracker and a common user node, and further includes a super node. When having no download requirements, the super node uploads fragments stored by itself or fragments obtained from other super nodes or common user nodes according to a request for fragments from a common user node so as to be shared by the common user node. 
 [0013] A user node capable of serving as a super node includes a super node registration module and a fragment request processing module. 
 [0014] The super node registration module is adapted to register a user node to a tracker as a super node when detecting that the user node satisfies the conditions to be a super node. 
 [0015] The fragment request processing module is adapted to receive a request for fragments from a common user node, and check itself to see whether the fragments requested by the common user node are stored therein or not. If yes, the processing module uploads its stored fragments to be shared by the common user node; otherwise, the processing module requests the fragments desired by the common user node from other super nodes or common user nodes and uploads the obtained fragments to be shared by the common user node. 
 [0016] A method for P2P content sharing, in which a super node is selected from user nodes, includes the following steps. 
 [0017] A private network user node uploads its own fragments through a public IP address and a port number allocated by the super node or with the super node as an agent, so as to be shared by other user nodes or to download fragments from other user nodes. 
 [0018] A system for P2P content sharing includes a tracker and a common user node, and further includes a super node. The super node is adapted to assist a private network user node to traverse network address translation (NAT), so as to achieve P2P transmission. 
 [0019] A private network user node includes an NAT-type determining module and a registration module. 
 [0020] The NAT-type determining module is adapted to detect that the user node is a private network user node, then determine whether the NAT type of the user node is a cone NAT or a symmetrical NAT, and send the determination result to the registration module. 
 [0021] The registration module is adapted to receive the determination result sent by the NAT-type determining module. If the result is a cone NAT, the registration module requests a super node to allocate a public IP address and a port number to the user node, and registers to a tracker with the public IP address and the port number; and if the result is a symmetrical NAT, the registration module registers to at least one super node, and requests the super node to register to the tracker as an agent of the user node. 
 [0022] A super node includes: a Simple Traversal of UDP Through Network Address Translators (STUN) server function module, adapted to allocate a public IP address and a port number to a cone NAT private network user node, so that the private network user node registers to a tracker with the public IP address and the port number. 
 [0023] A super node includes: a Traversal Using Relay NAT (TURN) server function module, adapted to register to a tracker as an agent of a symmetrical NAT private network user node. 
 [0024] According to the present invention, in order to overcome the disadvantages of the prior art, a user node satisfying certain conditions serves as a super node, which plays a coordinating and relaying role for a private network user node in traversing NAT. Furthermore, when having no download requirements, the super node provides upload services voluntarily to compensate for an excessively low up-rate, so as to make the up-rate meet the requirements of the down-rate, thereby assisting the private network user node behind NAT to traverse NAT and achieving P2P transmission. Meanwhile, the problem that the overall sharing rate is limited by the minimum rate in the network where the up-rate and down-rate are unsymmetrical is resolved, and thus real-time P2P business applications with high requirements for bandwidth are made possible. 
 BRIEF DESCRIPTION OF THE DRAWINGS
 [0025] 
FIG. 1 is a BT network architecture diagram in the prior art;
FIG. 2 is a BT network architecture diagram according to an embodiment of the present invention;
FIG. 3 is a flow chart of a super node providing upload services according to an embodiment of the present invention; and
FIG. 4 is a flow chart of a super node assisting a private network user node to traverse NAT according to an embodiment of the present invention.
 DETAILED DESCRIPTION OF THE EMBODIMENTS
 [0026] Hereinafter, the present invention is further described in detail below through the embodiments with reference to the accompanying drawings. 
 [0027] According to the technical solutions provided in the embodiments of the present invention, in an existing BT network architecture, a user node satisfying certain conditions serves as a super node, which plays a coordinating and relaying role as an STUN Server or a TURN Server for a private network user node in traversing NAT. Moreover, when having no download requirements, the super node provides upload services voluntarily to compensate for an excessively low up-rate, so as to make the up-rate meet the requirements of the down-rate. 
 [0028] In order to make the objectives, technical solutions, and advantages of the present invention comprehensible, embodiments are described in detail below with the accompanying drawings. It should be understood that, the embodiments described herein are only intended to explain the present invention, instead of limiting the same. 
 [0029] The network architecture according to an embodiment of the present invention is shown in FIG. 2, in which a super node is introduced into the existing BT network architecture. The super node can be replaced by a common user node satisfying the following conditions: having a public IP address, capable of being directly accessed by other user nodes; having sufficient processing capability; having enough storage space for storing shared content; and having enough bandwidth. 
 [0030] Besides following all the processes of the common user node, the super node also needs to identify that it is a super node when registering to a Tracker, so that the Tracker and other user nodes may be notified which nodes are super nodes during information interaction. 
 [0031] With no download requirements, the super node does not care about the specific content of the downloaded file, and may not actively download .torrent file from the Webserver. Thereby, the discovery mechanism of the Tracker needs to be modified accordingly, so that the IP address or domain name of the Tracker is no longer obtained from the .torrent file, but pre-set in each user node. The specific process of a common user node registering to the Tracker as a super node is provided below. 
1. The user node finds the Tracker through the pre-set Tracker IP address or domain name.
2. The user node acquires a super node list from the Tracker.
3. The super node integrates the functions of an STUN Server, and the common user node integrates the functions of an STUN Client. The STUN Client communicates with the STUN Server, and determines whether the IP address of the user node is a public IP address or a private IP address. Specifically, the STUN Client first sends a probe packet to the STUN Server, and the packet payload (except the IP header) contains the IP address of its own. When the packet traverses NAT, the IP address of the header is changed into the public IP address of the NAT, but the IP address in the payload stays the same. Therefore, when receiving the probe packet, the STUN Server compares to see whether the source IP of the packet header is identical to the IP address of the payload, so as to determine whether the STUN Client has traversed NAT, and then returns a response packet to the STUN Client. The packet payload carries the public IP address therein, and the STUN Client compares the header destination IP address of the response packet with the payload IP address to see whether it has traversed NAT.
 [0032] If the STUN Client is behind NAT, the STUN Server notifies other users about the IP address and the port number of the STUN Client after traversing NAT, and thus the other users can access the STUN Client. 
4. When finding that its own IP address is a public IP address, the user node checks itself to see whether the processing capability, storage space, and bandwidth satisfy the conditions of the super node, and if yes, registers to the Tracker as the super node.
 [0033] After the user node satisfying the conditions has registered to be the super node, the super node achieves two functions in the BT network architecture: one is to provide upload services when not downloading any files itself; and the other is to assist users with private network addresses to traverse NAT. 
 [0034] The process of the super node providing upload services when not downloading any files itself is shown in FIG. 3. 
 [0035] In Step 301, the super node receives a request for fragments from the common user node. 
 [0036] In Step 302, the super node analyzes the request for fragments from the common user node, and checks itself to see whether the fragments exist or not. If not, proceed to Step 3; otherwise, proceed to Step 5. 
 [0037] In Step 303, the super node randomly selects a part of the fragments desired by the common user node, and requests other nodes (including super nodes and common user nodes) for the selected part. 
 [0038] In Step 304, the super node obtains the fragments from the other nodes, and temporarily stores the obtained fragments in its storage space. 
 [0039] After Step 304, the process proceeds to Step 305, or returns to Step 301. 
 [0040] In Step 305, the super node uploads the stored fragments to be shared by the common user node that requests for the fragments. 
 [0041] In the above process, the most important point is that the super node does not download all the fragments, but randomly downloads a part of the fragments, so as to avoid the competition for bandwidth between the super node and the common user node. Although the super node only has a part of the fragments, if the number of the super nodes is sufficient, all the super nodes can be integrated to obtain the complete fragments, and each super node repeatedly uploads to share the part owned by itself, so that the problem of insufficient upload bandwidth can be effectively solved. 
 [0042] The specific process of the super node assisting a common user node merely having a private network address to traverse NAT is shown in FIG. 4, which includes the following steps. 
 [0043] In Step 401, when finding that its own IP address is a private IP address, the common user node exchanges information with the STUN Server of the super node. 
 [0044] In Step 402, the common user node determines whether the NAT type of itself is a cone NAT or a symmetrical NAT according to the exchanged information. If the result is a cone NAT, proceed to Step 403; and if the result is a symmetrical NAT, proceed to Step 404. 
 [0045] In Step 403, if the result is a cone NAT, the common user node acquires its own public IP address and port number from the STUN Server of the super node, and registers to the Tracker with the public IP address and the port number, so that other user nodes (including common user nodes and super nodes) may access the common user node through the public IP address and the port number issued by the common user node, and directly perform P2P transmission. Then, the process ends. 
 [0046] In Step 404, if the result is a symmetrical NAT, the common user node selects one or more super nodes and registers thereto, so as to request the selected super node to register to the Tracker as an agent. The super node registers with its own public IP address, and subsequently the common user node uploads and downloads files through the super node as an agent for forwarding. The super node serves as the TURN Server for NAT traversal. 
 [0047] According to an embodiment of the present invention, the structure of a user node capable of serving as a super node mainly includes a super node registration module and a fragment request processing module. 
 [0048] The super node registration module is adapted to register a user node to a tracker as a super node when detecting that the user node satisfies the conditions to be a super node. 
 [0049] The fragment request processing module is adapted to receive a request for fragments from a common user node, and check itself to see whether the fragments requested by the common user node are stored therein or not. If yes, the processing module uploads its stored fragments to be shared by the common user node; otherwise, the processing module requests the fragments desired by the common user node from other super nodes or common user nodes, and uploads the obtained fragments to be shared by the common user node. 
 [0050] According to an embodiment of the present invention, the structure of a private network user node mainly includes an NAT-type determining module and a registration module. 
 [0051] The NAT-type determining module is adapted to detect that the user node is a private network user node, then determine whether the NAT type of the user node is a cone NAT or a symmetrical NAT, and send the determination result to the registration module. 
 [0052] The registration module is adapted to receive the determination result sent by the NAT-type determining module. If the result is a cone NAT, the registration module requests a super node to allocate a public IP address and a port number to the user node, and registers to a tracker with the public IP address and the port number; and if the result is a symmetrical NAT, the registration module registers to at least one super node, and requests the super node to register to the tracker as an agent of the user node. 
 [0053] According to an embodiment of the present invention, the structure of the super node capable of assisting the private network user node to traverse NAT mainly includes a STUN server function module and a TURN server function module. 
 [0054] The STUN server function module is adapted to allocate a public IP address and a port number to a cone NAT private network user node, so that the private network user node registers to a tracker with the public IP address and the port number. 
 [0055] The TURN server function module is adapted to register to a tracker as an agent of a symmetrical NAT private network user node. 
 [0056] As described above, in the embodiments of the present invention, a user node satisfying certain conditions serves as a super node, which plays a coordinating and relaying role as an STUN Server or a TURN Server for a private network user node in traversing NAT. Moreover, when having no download requirements, the super node provides upload services voluntarily to compensate for an excessively low up-rate, so as to make the up-rate meet the requirements of the down-rate, thereby assisting the private network user node behind NAT to traverse NAT and achieving P2P transmission. Meanwhile, the problem that the overall sharing rate is limited by the minimum rate in the network where the up-rate and down-rate are unsymmetrical is resolved, and thus real-time P2P business applications with high requirements for bandwidth are made possible.」
訳文（ロ．）「［０００７］
　ＢＴ共有のためのＰ２Ｐネットワークは典型的な「皆は一人のために、一人は皆のために」のネットワークであり、そのネットワークを介して各ユーザのリソースが完全に共有されるということが、上記のＢＴ共有プロセスから分かる。しかし、このネットワークでは、真の「平等」の故に、いかなる追加の動作でも「自発的に」行うことを希望するユーザはなく、それによりネットワークは、主として次の２点における特定の制限を有する。
　１．２つのユーザがネットワークアドレス変換（ＮＡＴ）の背後にある場合、それらのユーザのアドレスはプライベートネットワークアドレスであり、プライベートネットワークアドレスは外部から直接アクセスされることができない。プライベートネットワーク内の装置に直接アクセスするためには、ＳＴＵＮ（Ｓｉｍｐｌｅ  Ｔｒａｖｅｒｓａｌ  ｏｆ  ＵＤＰ  Ｔｈｒｏｕｇｈ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒｓ）又はＴＵＲＮ（Ｔｒａｖｅｒｓａｌ  Ｕｓｉｎｇ  Ｒｅｌａｙ  ＮＡＴ）のメカニズムが必要とされる。しかし、現在のＢＴネットワークでは、その動作を調整及び完了するための対応するユニットを採用することができず、そのため、Ｐ２Ｐの直接アクセスは実現不可能である。
　２．ネットワークが非対称ネットワークである場合、全体的な共有アクセスレートは最小レートによって制限され、例えば、非対称型デジタル加入者線（ＡＤＳＬ）ネットワークでは、代表的な下りレートは８Ｍであり、代表的な上りレートは５１２Ｋである。単に１つのユーザの観点からは、そのユーザのために複数のその他のユーザが、各ユーザの上りレートは十分に高くなくても、同時にアップロードサービスを提供してもよく、複数のユーザの合計レートが、高速ダウンロードに対する１つのユーザの要求を満たすかもしれない。しかし、ネットワーク全体の状況を考慮に入れると、完全なＰ２Ｐの下では、合計の上りレートは、合計の下りレートと正確に等しい。従って、下りリンクの帯域幅がたとえ十分に広くても、上りレートの制限の故に、ユーザの平均下りレートは、ネットワークの平均上りレートであることのみが可能である。
　発明の要約
［０００８］
　従って、本発明は、プライベートネットワークユーザノードがＰ２Ｐ共有を実現できず、Ｐ２Ｐ共有アクセスレートが上りレートと下りレートのうちのより低いレートによって制限されるという、従来技術における問題を解決することが可能な、Ｐ２Ｐコンテンツ共有のための方法、システム、及びノードに関する。
［０００９］
　上記の目的を達成するために、本発明は以下の技術的解決法を提供する。
［００１０］
　スーパーノードがユーザノードから選択される、Ｐ２Ｐコンテンツ共有のための方法は、以下のステップを含む。
［００１１］
　スーパーノードは、一般ユーザノードから、フラグメントを求める要求を受信し、そのスーパーノード自体を調べて、一般ユーザノードによって要求されたフラグメントがそのスーパーノード内に記憶されているかどうかを確認する。記憶されている場合、スーパーノードは、そのスーパーノードの記憶されているフラグメントを一般ユーザノードによって共有されるようにアップロードし、記憶されていない場合、スーパーノードは、一般ユーザノードによって所望されるフラグメントをその他のスーパーノード又は一般ユーザノードに要求し、取得したフラグメントを一般ユーザノードによって共有されるようにアップロードする。
［００１２］
　Ｐ２Ｐコンテンツ共有のためのシステムは、トラッカと、一般ユーザノードとを含み、スーパーノードを更に含む。ダウンロード要求がない場合、スーパーノードは、一般ユーザノードからの、フラグメントを求める要求に従って、そのスーパーノード自体によって記憶されたフラグメント、あるいは、その他のスーパーノード又は一般ユーザノードから取得したフラグメントを、一般ユーザノードによって共有されるようにアップロードする。
［００１３］
　スーパーノードとして働くことが可能なユーザノードは、スーパーノード登録モジュールと、フラグメント要求処理モジュールとを含む。
［００１４］
　スーパーノード登録モジュールは、ユーザノードがスーパーノードであるための条件を満たすことを検出した場合に、ユーザノードをスーパーノードとしてトラッカに登録するように適合される。
［００１５］
　フラグメント要求処理モジュールは、一般ユーザノードから、フラグメントを求める要求を受信し、そのモジュール自体を調べて、一般ユーザノードによって要求されたフラグメントがそのモジュール内に記憶されているかどうかを確認するように適合される。記憶されている場合、処理モジュールは、そのモジュールの記憶されているフラグメントを、一般ユーザノードによって共有されるようにアップロードし、記憶されていない場合、処理モジュールは、一般ユーザノードによって所望されるフラグメントをその他のスーパーノード又は一般ユーザノードに要求し、取得したフラグメントを、一般ユーザノードによって共有されるようにアップロードする。
［００１６］
　スーパーノードがユーザノードから選択される、Ｐ２Ｐコンテンツ共有のための方法は、以下のステップを含む。
［００１７］
　プライベートネットワークユーザノードは、そのプライベートネットワークユーザノード自体のフラグメントを、スーパーノードによって割り当てられたパブリックＩＰアドレスとポート番号とを介して、又はエージェントとしてのスーパーノードを使用してアップロードして、その他のユーザノードによって共有されるようにするか、又はその他のユーザノードからフラグメントをダウンロードする。
［００１８］
　Ｐ２Ｐコンテンツ共有のためのシステムは、トラッカと、一般ユーザノードとを含み、スーパーノードを更に含む。スーパーノードは、Ｐ２Ｐ伝送を達成するように、プライベートネットワークユーザノードがネットワークアドレス変換（ＮＡＴ）を越えることを支援するように適合される。
［００１９］
　プライベートネットワークユーザノードは、ＮＡＴタイプ判定モジュールと、登録モジュールとを含む。
［００２０］
　ＮＡＴタイプ判定モジュールは、ユーザノードがプライベートネットワークユーザノードであることを検出し、次に、ユーザノードのＮＡＴタイプがコーン型ＮＡＴであるか対称型ＮＡＴであるかを判定し、そして、判定結果を登録モジュールに送信するように適合される。
［００２１］
　登録モジュールは、ＮＡＴタイプ判定モジュールによって送信された判定結果を受信するように適合される。結果がコーン型ＮＡＴである場合、登録モジュールは、パブリックＩＰアドレスとポート番号とをユーザノードに割り当てるようスーパーノードに要求し、パブリックＩＰアドレスとポート番号とをトラッカに登録する。結果が対称型ＮＡＴである場合、登録モジュールは、少なくとも１つのスーパーノードに登録し、スーパーノードに、ユーザノードのエージェントとしてトラッカに登録するよう要求する。
［００２２］
　スーパーノードは、コーン型ＮＡＴプライベートネットワークユーザノードがパブリックＩＰアドレスとポート番号とをトラッカに登録するように、パブリックＩＰアドレスとポート番号とをコーン型ＮＡＴプライベートネットワークユーザノードに割り当てるように適合された、ＳＴＵＮ（Ｓｉｍｐｌｅ  Ｔｒａｖｅｒｓａｌ  ｏｆ  ＵＤＰ  Ｔｈｒｏｕｇｈ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒｓ）サーバ機能モジュールを含む。
［００２３］
　スーパーノードは、対称型ＮＡＴプライベートネットワークユーザノードのエージェントとしてトラッカに登録するように適合された、ＴＵＲＮ（Ｔｒａｖｅｒｓａｌ  Ｕｓｉｎｇ  Ｒｅｌａｙ  ＮＡＴ）サーバ機能モジュールを含む。
［００２４］
　本発明の実施形態によれば、従来技術の欠点を克服するために、一定の条件を満たすユーザノードをスーパーノードとし、スーパーノードは、ＮＡＴを越える際のプライベートネットワークユーザノードのために、調整及び中継の役割を果たす。更に、ダウンロード要求を有さない場合、スーパーノードは、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償し、それにより、ＮＡＴの背後のプライベートネットワークユーザノードがＮＡＴを越えるのを支援して、Ｐ２Ｐ伝送を達成する。同時に、上りレートと下りレートとが非対称である場合に全体的な共有レートはネットワーク内の最小レートによって制限されるという問題が解決され、従って、高い帯域幅要求を有するリアルタイムＰ２Ｐビジネスアプリケーションが可能となる。
図面の簡単な説明
［００３３］
　図１は、従来技術における、ＢＴネットワークのアーキテクチャ図である。
　図２は、本発明の一実施形態による、ＢＴネットワークのアーキテクチャ図である。
　図３は、本発明の一実施形態による、アップロードサービスを提供しているスーパーノードのフローチャートである。
　図４は、本発明の一実施形態による、プライベートネットワークユーザノードがＮＡＴを越えるのを支援しているスーパーノードのフローチャートである。
　発明を実施するための形態
［００２６］
　以下、本発明について、添付の図面を参照して、実施形態を介して更に詳細に説明する。
［００２７］
　本発明の実施形態で提供される技術的解決法によれば、既存のＢＴネットワークアーキテクチャにおいて、一定の条件を満たすユーザノードをスーパーノードとし、スーパーノードは、ＮＡＴを越える際のプライベートネットワークユーザノードのために、ＳＴＵＮサーバ又はＴＵＲＮサーバとして、調整及び中継の役割を果たす。更に、ダウンロード要求がない場合、スーパーノードは、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償する。
［００２８］
　本発明の目的、技術的解決法、及び利点を分かりやすくするために、添付の図面を使用して、実施形態について以下で詳細に説明する。本明細書に記載する実施形態は、本発明を限定することを意図するものではなく、本発明を説明することのみを意図するものであるということが理解されるべきである。
［００２９］
　本発明の一実施形態によるネットワークアーキテクチャを図２に示す。図２では、既存のＢＴネットワークアーキテクチャ内にスーパーノードが導入されている。スーパーノードは、以下の条件を満たす一般ユーザノードによって置き換えられてもよい。パブリックＩＰアドレスを有する。その他のユーザノードによって直接アクセスされることが可能である。十分な処理能力を有する。共有コンテンツを記憶するための十分な記憶空間を有する。十分な帯域幅を有する。
［００３０］
　一般ユーザノードの全ての処理に従うことに加えて、スーパーノードは、更に、トラッカに登録する際にそのノードがスーパーノードであることを明らかにする必要があり、それにより、トラッカ及びその他のユーザノードは、どのノードがスーパーノードであるかを情報のやりとりの間に知らされてもよい。
［００３１］
　ダウンロードの要求がない場合、スーパーノードは、ダウンロードファイルの特定のコンテンツに関心がなく、Ｗｅｂサーバから．ｔｏｒｒｅｎｔファイルを能動的にダウンロードしなくてもよい。従って、トラッカの発見メカニズムはそれに応じて修正される必要があり、そのため、トラッカのＩＰアドレス又はドメイン名は．ｔｏｒｒｅｎｔファイルからはもはや取得されず、各ユーザノード内に予め設定される。一般ユーザノードがスーパーノードとしてトラッカに登録する際の特定のプロセスを、以下に示す。
　１．ユーザノードは、予め設定されたトラッカのＩＰアドレス又はドメイン名を介してトラッカを見つける。
　２．ユーザノードは、トラッカから、スーパーノードのリストを取得する。
　３．スーパーノードはＳＴＵＮサーバの機能を統合し、一般ユーザノードはＳＴＵＮクライアントの機能を統合する。ＳＴＵＮクライアントは、ＳＴＵＮサーバと通信して、ユーザノードのＩＰアドレスがパブリックＩＰアドレスであるかプライベートＩＰアドレスであるかを判定する。具体的には、ＳＴＵＮクライアントはＳＴＵＮサーバにプローブパケットを最初に送信し、（ＩＰヘッダを除く）パケットペイロードは、ＳＴＵＮクライアント自体のＩＰアドレスを含む。パケットがＮＡＴを越える場合、ヘッダのＩＰアドレスはＮＡＴのパブリックＩＰアドレスに変更されるが、ペイロード内のＩＰアドレスは変わらない。それ故、プローブパケットを受信した場合、ＳＴＵＮサーバは、ＳＴＵＮクライアントがＮＡＴを越えたかどうかを判定するために、パケットヘッダのソースＩＰがペイロードのＩＰアドレスと同一であるかどうかを比較して確認し、次に、ＳＴＵＮクライアントに応答パケットを返す。パケットペイロードは、その中でパブリックＩＰアドレスを運び、ＳＴＵＮクライアントは、応答パケットのヘッダ宛先ＩＰアドレスを、ペイロードＩＰアドレスと比較して、そのパケットがＮＡＴを越えたかどうかを確認する。
［００３２］
　ＳＴＵＮクライアントがＮＡＴの背後にある場合、ＳＴＵＮサーバは、ＮＡＴを越えた後のＳＴＵＮクライアントのＩＰアドレスとポート番号とについて、その他のユーザに通知し、従って、その他のユーザはＳＴＵＮクライアントにアクセスできる。
　４．ユーザノードは、そのユーザノード自体のＩＰアドレスがパブリックＩＰアドレスであることを見出した場合、そのユーザノード自体を調べて、処理能力、記憶容量、及び帯域幅がスーパーノードの条件を満たすかどうかを確認し、満たすならば、スーパーノードとしてトラッカに登録する。
［００３３］
　条件を満たすユーザノードがスーパーノードとして登録された後で、スーパーノードは、ＢＴネットワークアーキテクチャ内で２つの機能を達成する。１つは、そのスーパーノード自体がいかなるファイルもダウンロードしていない場合にアップロードサービスを提供することであり、もう１つは、プライベートネットワークアドレスを有するユーザがＮＡＴを越えるのを支援することである。
［００３４］
　スーパーノードの、そのスーパーノード自体がいかなるファイルもダウンロードしていない場合にアップロードサービスを提供するプロセスを、図３に示す。
［００３５］
　ステップ３０１で、スーパーノードは、一般ユーザノードから、フラグメントを求める要求を受信する。
［００３６］
　ステップ３０２で、スーパーノードは、一般ユーザノードからの、フラグメントを求める要求を解析し、そのスーパーノード自体を調べて、そのフラグメントが存在するかどうかを確認する。存在しない場合はステップ３に進み、存在する場合はステップ５に進む。
［００３７］
　ステップ３０３で、スーパーノードは、一般ユーザノードによって所望されるフラグメントのうちの一部のフラグメントをランダムに選択し、選択された一部をその他のノード（スーパーノード及び一般ユーザノードを含む）に要求する。
［００３８］
　ステップ３０４で、スーパーノードは、その他のノードからフラグメントを取得し、取得したフラグメントを、そのスーパーノード自体の記憶空間内に一時的に記憶する。
［００３９］
　ステップ３０４の後で、プロセスは、ステップ３０５に進むか、又はステップ３０１に戻る。
［００４０］
　ステップ３０５で、スーパーノードは、記憶されたフラグメントを、フラグメントを要求する一般ユーザノードによって共有されるようにアップロードする。
［００４１］
　上記のプロセスにおいて最も重要な点は、スーパーノードは、全てのフラグメントをダウンロードするのではなく、一部のフラグメントをランダムにダウンロードして、スーパーノードと一般ユーザノードとの間での帯域幅をめぐる競合を回避するということである。スーパーノードは一部のフラグメントのみを有するが、スーパーノードの数が十分である場合、全部のフラグメントを取得するために全てのスーパーノードが統合されてもよく、そして、各スーパーノードはそのスーパーノード自体によって所有される部分を共有するために繰り返しアップロードし、それにより、不十分なアップロード帯域幅の問題は有効に解決されうる。
［００４２］
　プライベートネットワークアドレスを有するにすぎない一般ユーザノードがＮＡＴを越えるのを支援する、スーパーノードの具体的なプロセスを図４に示す。このプロセスは以下のステップを含む。
［００４３］
　ステップ４０１で、一般ユーザノードは、その一般ユーザノード自体のＩＰアドレスがプライベートＩＰアドレスであることを見出した場合、スーパーノードのＳＴＵＮサーバと情報を交換する。
［００４４］
　ステップ４０２で、一般ユーザノードは、その一般ユーザノード自体のＮＡＴタイプがコーン型ＮＡＴであるか対称型ＮＡＴであるかを、交換された情報に従って判定する。結果がコーン型ＮＡＴである場合はステップ４０３に進み、結果が対称型ＮＡＴである場合はステップ４０４に進む。
［００４５］
　ステップ４０３で、結果がコーン型ＮＡＴである場合、一般ユーザノードは、その一般ユーザノード自体のパブリックＩＰアドレスとポート番号とをスーパーノードのＳＴＵＮサーバから取得し、パブリックＩＰアドレスとポート番号とをトラッカに登録し、それにより、その他のユーザノード（一般ユーザノード及びスーパーノードを含む）は、一般ユーザノードによって発行されたパブリックＩＰアドレスとポート番号とを介して一般ユーザノードにアクセスして、Ｐ２Ｐ伝送を直接実行してもよい。その後、プロセスは終了する。
［００４６］
　ステップ４０４で、結果が対称型ＮＡＴである場合、一般ユーザノードは、１つ以上のスーパーノードを選択してそのスーパーノードに登録し、選択されたスーパーノードに、エージェントとしてトラッカに登録するよう要求する。スーパーノードは、そのスーパーノード自体のパブリックＩＰアドレスを登録し、その後、一般ユーザノードは、転送のためのエージェントとしてのスーパーノードを介してファイルをアップロード及びダウンロードする。スーパーノードは、ＮＡＴ越えのためのＴＵＲＮサーバとして働く。
［００４７］
　本発明の一実施形態によれば、スーパーノードとして働くことが可能なユーザノードの構成は主として、スーパーノード登録モジュールと、フラグメント要求処理モジュールとを含む。
［００４８］
　スーパーノード登録モジュールは、ユーザノードがスーパーノードであるための条件を満たすことを検出した場合に、ユーザノードをスーパーノードとしてトラッカに登録するように適合される。
［００４９］
　フラグメント要求処理モジュールは、一般ユーザノードから、フラグメントを求める要求を受信し、そのスーパーノード自体を調べて、一般ユーザノードによって要求されたフラグメントがそのスーパーノード内に記憶されているかどうかを確認するように適合される。記憶されている場合、処理モジュールは、記憶されているフラグメントを、一般ユーザノードによって共有されるようにアップロードし、記憶されていない場合、処理モジュールは、一般ユーザノードによって所望されるフラグメントをその他のスーパーノード又は一般ユーザノードに要求し、取得したフラグメントを、一般ユーザノードによって共有されるようにアップロードする。
［００５０］
　本発明の一実施形態によれば、プライベートネットワークユーザノードの構成は主として、ＮＡＴタイプ判定モジュールと、登録モジュールとを含む。
［００５１］
　ＮＡＴタイプ判定モジュールは、ユーザノードがプライベートネットワークユーザノードであることを検出し、次に、ユーザノードのＮＡＴタイプがコーン型ＮＡＴであるか対称型ＮＡＴであるかを判定し、そして、判定結果を登録モジュールに送信するように適合される。
［００５２］
　登録モジュールは、ＮＡＴタイプ判定モジュールによって送信された判定結果を受信するように適合される。結果がコーン型ＮＡＴである場合、登録モジュールは、パブリックＩＰアドレスとポート番号とをユーザノードに割り当てるようスーパーノードに要求し、パブリックＩＰアドレスとポート番号とをトラッカに登録する。結果が対称型ＮＡＴである場合、登録モジュールは、少なくとも１つのスーパーノードに登録し、スーパーノードに、ユーザノードのエージェントとしてトラッカに登録するよう要求する。
［００５３］
　本発明の一実施形態によれば、プライベートネットワークユーザノードがＮＡＴを越えるのを支援することが可能なスーパーノードの構成は主として、ＳＴＵＮサーバ機能モジュールと、ＴＵＲＮサーバ機能モジュールとを含む。
［００５４］
　ＳＴＵＮサーバ機能モジュールは、パブリックＩＰアドレスとポート番号とをコーン型ＮＡＴプライベートネットワークユーザノードに割り当てるように適合され、それにより、プライベートネットワークユーザノードは、パブリックＩＰアドレスとポート番号とをトラッカに登録する。
［００５５］
　ＴＵＲＮサーバ機能モジュールは、対称型ＮＡＴプライベートネットワークユーザノードのエージェントとしてトラッカに登録するように適合される。
［００５６］
　上述のように、本発明の実施形態では、一定の条件を満たすユーザノードをスーパーノードとし、スーパーノードは、ＮＡＴを越える際のプライベートネットワークユーザノードのために、ＳＴＵＮサーバ又はＴＵＲＮサーバとして、調整及び中継の役割を果たす。更に、ダウンロード要求がない場合、スーパーノードは、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償し、それにより、ＮＡＴの背後のプライベートネットワークユーザノードがＮＡＴを越えてＰ２Ｐ伝送を達成するのを支援する。同時に、上りレートと下りレートとが非対称である場合に全体的な共有レートはネットワーク内の最小レートによって制限されるという問題が解決され、従って、高い帯域幅要求を有するリアルタイムＰ２Ｐビジネスアプリケーションが可能となる。」
　上記刊行物１の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ．の［０００８］における「本発明は、プライベートネットワークユーザノードがＰ２Ｐ共有を実現できず、Ｐ２Ｐ共有アクセスレートが上りレートと下りレートのうちのより低いレートによって制限されるという、従来技術における問題を解決することが可能な、Ｐ２Ｐコンテンツ共有のための方法、システム、及びノードに関する。」との記載、同ロ．の［００２７］における「本発明の実施形態で提供される技術的解決法によれば、既存のＢＴネットワークアーキテクチャにおいて、一定の条件を満たすユーザノードをスーパーノードとし、スーパーノードは、ＮＡＴを越える際のプライベートネットワークユーザノードのために、ＳＴＵＮサーバ又はＴＵＲＮサーバとして、調整及び中継の役割を果たす。更に、ダウンロード要求がない場合、スーパーノードは、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償する。」との記載、及び図２によれば、刊行物１のコンテンツ共有システムは、ビットトレント（ＢＴ）を使用するＰ２Ｐネットワークにおける上りレートを補償するためのシステムである。
　また、上記ロ．の［００２７］における「本発明の実施形態で提供される技術的解決法によれば、既存のＢＴネットワークアーキテクチャにおいて、一定の条件を満たすユーザノードをスーパーノードとし、スーパーノードは、ＮＡＴを越える際のプライベートネットワークユーザノードのために、ＳＴＵＮサーバ又はＴＵＲＮサーバとして、調整及び中継の役割を果たす。」との記載、同ロ．の［００２９］における「本発明の一実施形態によるネットワークアーキテクチャを図２に示す。図２では、既存のＢＴネットワークアーキテクチャ内にスーパーノードが導入されている。」との記載、及び図２によれば、刊行物１のコンテンツ共有システムは、ユーザノードと、スーパーノードとを備えている。
　また、上記ロ．の［００２４］における「本発明の実施形態によれば、従来技術の欠点を克服するために、一定の条件を満たすユーザノードをスーパーノードとし、スーパーノードは、ＮＡＴを越える際のプライベートネットワークユーザノードのために、調整及び中継の役割を果たす。更に、ダウンロード要求を有さない場合、スーパーノードは、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償し、それにより、ＮＡＴの背後のプライベートネットワークユーザノードがＮＡＴを越えるのを支援して、Ｐ２Ｐ伝送を達成する。同時に、上りレートと下りレートとが非対称である場合に全体的な共有レートはネットワーク内の最小レートによって制限されるという問題が解決され、従って、高い帯域幅要求を有するリアルタイムＰ２Ｐビジネスアプリケーションが可能となる。」との記載、及び図２によれば、刊行物１のコンテンツ共有システムは、スーパーノードが、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償することができるものである。
　したがって、上記刊行物１には、以下の発明（以下、「引用発明１」という。）が記載されているものと認められる。
　「ビットトレント（ＢＴ）を使用するＰ２Ｐネットワークにおける上りレートを補償するためのコンテンツ共有システムであって、
　Ｐ２Ｐネットワークと、
　ユーザノードと、
　スーパーノードとを備え、
　前記スーパーノードが、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償する、コンテンツ共有システム。」
　
（２）　対比
　本願発明と引用発明１とを対比する。 
ａ．引用発明１の「ビットトレント（ＢＴ）ソフトウェア」は、相手（ピア）からファイルの一部を受け取るには、自分もファイルの一部を渡さなければならい規則を有するから、「報復プロトコル」ということができる。
ｂ．本願発明の「逆方向リンクの帯域幅の消費を減少させる」と、引用発明１の「上りレートを補償する」とは、後述する相違点を除いて、「逆方法リンクの帯域幅を改善する」という点で一致する。
ｃ．本願発明の「前記データネットワークからの順方向リンクの帯域幅が前記データネットワークへの逆方向リンクの帯域幅よりも大きい非対称接続を有するクライアント」と、引用発明１の「ユーザノード」とは、後述する相違点を除いて、「ユーザノード」いう点で一致する。
ｄ．本願発明の「ピアトゥピアプロキシサーバ」と、引用発明１の「スーパーノード」とは、「中継ノード」という点で一致する。
ｅ．本願発明の「前記ピアトゥピアプロキシサーバが前記ピアトゥピアネットワークに対してクライアントであるかのように動作し、逆方向リンクでのクライアントからピアトゥピアプロキシサーバへのファイルコンテンツの転送を要求することを回避するように、ピアトゥピアプロキシサーバが前記クライアントと前記ピアトゥピアネットワークとの間を透過的にインターフェースする専用の機能を有する」と、引用発明１の「前記スーパーノードが、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償する」とは、後述する相違点を除いて、「前記中継ノードが、逆方向リンクでのユーザノードから中継ノードへのコンテンツの転送要求することを回避する」という点で一致する。
　したがって、本願発明と引用発明１は、以下の点で一致ないし相違している。 
＜一致点＞
　「報復プロトコルを使用するピアトゥピアネットワークにおける逆方向リンクの帯域幅を改善するためのシステムであって、
　ピアトゥピアネットワークと、
　ユーザノードと、
　中継ノードとを備え、
　前記中継ノードが、逆方向リンクでのユーザノードから中継ノードへのコンテンツの転送要求することを回避する、システム。」
＜相違点１＞
　一致点の「逆方向リンクの帯域幅を改善するためのシステム」に関し、
　本願発明は、「逆方向リンクの帯域幅の消費を減少させるためのシステム」であるのに対し、引用発明１は、「上りレートを補償するためのシステム」である点。
＜相違点２＞
　本願発明は、「データネットワーク」を備えるのに対し、引用発明１は、その様な構成を備えるか明らかでない点。
　これに伴って、
　一致点の「ピアトゥピアネットワーク」に関し、本願発明の「ピアトゥピアネットワーク」は、「前記データネットワークと関連して動作する」ものであるのに対し、引用発明１の「Ｐ２Ｐネットワーク」は、「前記データネットワークと関連して動作する」ものでない点。
＜相違点３＞
　一致点の「ユーザノード」に関し、
　本願発明は、「前記データネットワークからの順方向リンクの帯域幅が前記データネットワークへの逆方向リンクの帯域幅よりも大きい非対称接続を有するクライアント」であるのに対し、引用発明１は、「前記データネットワークからの順方向リンクの帯域幅が前記データネットワークへの逆方向リンクの帯域幅よりも大きい非対称接続を有して」おらず、また、「クライアント」であるか明らかでない点。
＜相違点４＞
　一致点の「中継ノード」に関し、
　本願発明は、「前記データネットワークの中に配置されたピアトゥピアプロキシサーバ」であるのに対し、引用発明１は、「スーパーノード」であってピアトゥピアプロキシサーバであるかどうか明らかでない点。
＜相違点５＞
　一致点の「前記中継ノードが、逆方向リンクでのユーザノードから中継ノードへのコンテンツの転送要求することを回避する」に関し、
　本願発明は、「前記ピアトゥピアプロキシサーバが前記ピアトゥピアネットワークに対してクライアントであるかのように動作し、逆方向リンクでのクライアントからピアトゥピアプロキシサーバへのファイルコンテンツの転送を要求することを回避するように、ピアトゥピアプロキシサーバが前記クライアントと前記ピアトゥピアネットワークとの間を透過的にインターフェースする専用の機能を有する」のに対し、引用発明１は、「前記スーパーノードが、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償する」点。
（３）判断
　そこで、まず、上記相違点５について検討する。
　引用発明１は、「前記スーパーノードが、下りレートの要求を上りレートが満たすようにするために、自発的にアップロードサービスを提供して過度に低い上りレートを補償する」にすぎず、そもそも、本願発明のように「ピアトゥピアプロキシサーバがピアトゥピアネットワークに対してクライアントであるかのように動作す」るものではないから、上記相違点である本願発明の発明特定事項である「ピアトゥピアプロキシサーバがピアトゥピアネットワークに対してクライアントであるかのように動作す」る点を、引用発明１から導き出すことはできない。
　そして、本願発明は、上記発明特定事項を備えることにより、本願明細書段落【００１２】に記載されたように、クライアント側のピアトゥピアソフトウエアを見直すことの費用、およびその複雑な事態が生じないという作用効果を奏するものである。
　よって、本願発明は、上記相違点１〜４について検討するまでもなく、引用発明１に基づいて、当業者が容易に発明をすることができたとはいえない。
（４）小括
　したがって、本願発明は、引用発明１に基いて、当業者が容易に発明をすることができたとはいえない。
　請求項２〜６は、請求項１を直接又は間接的に引用する従属項であり、本願発明の発明特定事項をすべて含みさらに発明特定事項を追加して限定したものであるから、上記（３）と同じ理由により、引用発明１に基づいて当業者が容易に発明をすることができたとはいえない。
　請求項７は、請求項１に係る発明のカテゴリーを「方法」とした発明であるから、上記（３）と同じ理由により、引用発明１に基づいて当業者が容易に発明をすることができたとはいえない。
　請求項８〜１０は、請求項７を直接的に引用する従属項であり、本願発明の発明特定事項をすべて含みさらに発明特定事項を追加して限定したものであるから、上記（３）と同じ理由により、引用発明１に基づいて当業者が容易に発明をすることができたとはいえない。
　よって、原査定の理由によっては、本願を拒絶することはできない。
第４　当審拒絶理由について
１．当審拒絶理由の概要
「理　由 
１）本件出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第２９条第１項第３号に該当し、特許を受けることができない。
２）本件出願の下記の請求項に係る発明は、その出願前日本国内または外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
３）本件出願は、特許請求の範囲の記載が下記の点で不備のため、特許法第３６条第６項第１号及び第２号に規定する要件を満たしていない。  
　　　　　　　　　　　　　　　　　記  
理由１及び２について  
請求項１〜１０に対して刊行物Ａ。 
刊行物Ａ：特開２００９−１０４３７７号公報 
備考：刊行物Ａ（段落【０００６】〜【００４８】、図１〜９）には、無線リンクと、無線リンクに接続するインターネット（１）と、無線リンクの上りリング速度が遅い携帯電話（２）と、携帯ＩＰネットワークの中に配置されたゲートウエイ（ＧＷ）とを備えた、無線リンクの上りリンク速度が遅い端末でも高速なファイル交換を可能にするＰ２Ｐ通信システムが記載されている。ここで、ゲートウエイ（ＧＷ）は、プロシキ機能部（４）を備え、プロシキ機能部（４）が、Ｐ２Ｐネットワークに対してBitTorrentのクライアントであるかのように動作し、上りリンクでのゲートウエイ（ＧＷ）へのコンテンツファイルの転送を要求することを回避するように携帯電話（２）とＰ２Ｐネットワークとの間をインターフェースする機能を有しているということができる。 
　したがって、請求項１〜１０に係る発明は、刊行物Ａに記載された発明と差異はない。  
　仮に、差異があったとしても、請求項１〜１０に係る発明は、刊行物Ａに記載された発明に基づいて、当業者が容易に想到し得るものである。  
理由３について  
１．請求項１、７には、「ピアトゥピアネットワーク」及び「データネットワーク」との記載がある。一方、発明の詳細な説明及び図４には、ＩＰネットワーク、モバイルネットワーク、Ｐ２Ｐオーバーレイネットワークの記載があり、「ピアトゥピアネットワーク」及び「データネットワーク」が、これらネットワークのいずれの部分に対応するのか、「ピアトゥピアネットワーク」及び「データネットワーク」について用語の定義又は説明がされていないから、技術的意味が不明瞭である。また、同様に、「Ｐ２Ｐオーバーレイネットワーク」についても用語の定義又は説明がされていないから、技術的意味が不明瞭である。
２．本願発明は、ＢｉｔＴｏｒｒｅｎｔの「ピアトゥピアユーザのアップリンク共有率が低い場合」（段落【０００３】）の特徴に起因して、段落【０００４】の動作によって生じる段落【００１２】の課題を解決するために、段落【００３０】のとおり、「エージェントはまた本来の非対称クライアントとのメッセージ交換も実行し、非対称クライアントにデータをアップロードするが、非対称クライアントから（すなわち逆方向リンク上で）コンテンツの一部を要求することはない」ことを解決手段とするものである。しかしながら、請求項１、７には、ＢｉｔＴｏｒｒｅｎｔに係る内容は明らかにされていないため、「前記ピアトゥピアプロキシサーバが前記ピアトゥピアネットワークに対してクライアントであるかのように動作し」及び「エージェントがピアトゥピアネットワークに対してクライアントであるかのように前記エージェントから他のピアへのピアトゥピアのメッセージ交換を実行する」との記載では、上記解決手段は読み取れない。このため、請求項１及び７に記載された事項により、課題解決手段が反映されているとはいえず、請求項１及び７に係る発明の範囲まで、発明の詳細な説明に開示された内容を拡張ないし一般化できるとはいえない。また、請求項２〜５、８、９も同様である。」
２．当審拒絶理由の判断
（１）理由１及び２について
ア．刊行物の記載事項
　当審の拒絶の理由に引用された特開２００９−１０４３７７号公報（刊行物Ａ）には、図面とともに以下の事項が記載されている。
イ．「【技術分野】
【０００１】
　本発明は、ピア・ツー・ピア通信方法およびシステムに係り、特に、リンク速度が遅い端末でも高速なファイル交換を可能にするピア・ツー・ピア通信方法およびシステムに関するものである。」（３頁）
ロ．「【発明が解決しようとする課題】
【０００６】
　従来のP2P通信によるファイル交換では、ピア同士が上り速度および下り速度のいずれもが高速のADSLやFTTHのアクセス回線を使用していれば効率的かつ高速なファイル交換を実現できる。しかしながら、無線リンクを使用した接続では、ピアとなる端末の送信信号が基地局からの送信信号より一般に微弱であるため、下りリンク速度に較べて上りリンク速度が遅くなる。このため、ADSLやFTTHリンクに接続されたピア端末と無線リンクに接続されたピア端末との間でP2P通信する場合、無線リンクの上りリンクがボトルネックとなって効率の良い高速なファイル交換が難しくなる。
【０００７】
　特に、BitTorrentのファイル交換アルゴリズムは、ファイル供給に寄与しないピアには、ピースをダウンロードさせない仕組みになっている。このため、無線リンクに接続されたピアのダウンロード速度は益々遅くなる。
【０００８】
　本発明の目的は、上記した従来技術の課題を解決し、リンク速度が遅い端末でも高速なファイル交換を可能にするピア・ツー・ピア通信方法およびシステムを提供することにある。
【課題を解決するための手段】
【０００９】
　上記した目的を達成するために、本発明は、ファイルがメタ情報ファイルおよび複数のピースに分割されてネットワーク上に分散配置され、一のピアが前記メタ情報ファイルを取得し、このメタ情報ファイルに基づいて、ネットワーク上の各ピアからP2P通信でピースを収集し、前記ファイルを再構築するP2P通信方法において、ピアに参加しない非ピア端末、および非ピア端末の代理でピアに参加するプロキシ端末を配置し、この非ピア端末およびプロキシ端末が以下のような手順を実行することを特徴とする。
【００１０】
　(1)非ピア端末が、メタ情報ファイルを取得する手順と、前記メタ情報ファイルを含むプロキシ要求を前記プロキシ端末へ送信する手順とを含み、
【００１１】
　前記プロキシ端末が、前記プロキシ要求のメタ情報ファイルに基づいてトラッカーからピア情報を取得する手順と、前記ピア情報に基づいてネットワーク上の各ピアからピースをダウンロードする手順と、前記収集したピースを非ピア端末へ送信する手順とを含み、
【００１２】
　前記非ピア端末がさらに、前記メタ情報ファイルおよび受信したピースを合成してファイルを再構築する手順を含むことを特徴とする。
【００１３】
　(2)非ピア端末が、メタ情報ファイルを取得する手順と、前記メタ情報ファイルを含むプロキシ要求を前記プロキシ端末へ送信する手順とを含み、
【００１４】
　前記プロキシ端末が、前記プロキシ要求のメタ情報ファイルに基づいてトラッカーからピア情報を取得する手順と、前記ピア情報に基づいてネットワーク上の各ピアからピースをダウンロードする手順と、前記メタ情報ファイルおよび収集したピースを合成してファイルを再構築する手順と、前記再構築されたファイルを非ピア端末へ送信する手順とを含むことを特徴とする。
【００１５】
　(3)プロキシ端末がさらに、各ピアから収集したピースを認証する手順を含むことを特徴とする。
【００１６】
　(4)プロキシ端末がさらに、ダウンロードしたピースをアップロードする手順を含むことを特徴とする。
【発明の効果】
【００１７】
　本発明によれば以下のような効果が達成される。
【００１８】
　(1)非ピア端末が、自身の代わりにプロキシ端末をピアに参加させ、このプロキシ端末がP2P通信で各ピアからダウンロードしたピースを、当該プロキシ端末から直接ダウンロードするので、非ピア端末のリンク速度が低速であったり、非ピア端末の処理能力が低い場合でも、高速なファイル交換が可能になる。
【００１９】
　(2)P2P通信でダウンロードしたピースの認証をプロキシ端末で行うようにしたので、非ピア端末の処理負荷を低減できる。
【００２０】
　(3)各ピアからダウンロードしたピースおよびトレントファイルを合成してコンテンツファイルを再構築する処理をプロキシ端末で行い、プロキシ端末から非ピア端末へコンテンツファイルが転送されるようにすれば、非ピア端末の処理負荷を更に低減できる。
【００２１】
　(4)ダウンロードしたピースを、プロキシ端末が非ピア端末に代わってアップロードするようにしたので、非ピア端末の上りリンク速度が低速であり、かつピースのダウンロード速度がアップロード速度に依存する、BitTorrentのようはファイル交換アルゴリズムでも、高速なダウンロードが可能になる。」（４〜６頁）
ハ．「【発明を実施するための最良の形態】
【００２２】
　以下、図面を参照して本発明の最良の実施の形態について詳細に説明する。図１は、本発明のP2P通信方法およびシステムが適用されるネットワーク構成の一例を示した図であり、ここでは、低速の無線リンクでゲートウエイ(GW)を介してインターネット１に接続できる携帯電話２が、インターネット１上の各ピア３から所望のコンテンツファイルを収集する場合を例にして説明する。
【００２３】
　本実施形態では、前記携帯電話２がピアに参加しない非ピア端末であり、この携帯電話２にピア機能部５を設け、インターネット１と高速リンクで接続されたGWにプロキシ機能部４を設けてピアに参加させ、このプロキシ機能部４が、携帯電話２のピア機能部５から送信されるプロキシ要求に応答して各ピアからファイルのピースを代理で収集し、収集したピースを低速の無線リンク経由で携帯電話２のピア機能部５へ転送する。
【００２４】
　図２は、前記非ピア端末としての携帯電話２に実装されるピア機能部５の主要部の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００２５】
　メタ情報取得部２１は、ダウンロードするコンテンツファイルのメタ情報ファイルを管理するWebサーバにアクセスしてメタ情報ファイルを取得する。本実施形態では、メタ情報ファイルとしてトレントファイル(.torrent)が取得され、記憶部２０に記憶される。プロキシ要求部２２は、前記取得したトレントファイルを含むプロキシ要求をGWのプロキシ機能部４へ送信する。
【００２６】
　ダウンロード部２３は、GWのプロキシ機能部４が各ピアから収集したピースを当該プロキシ機能部４からダウンロードして記憶部２０に記憶する。コンテンツファイル生成部２４は、記憶部２０に記憶されている全てのピースおよびトレントファイルを合成してコンテンツファイルを再構築し、これを記憶部２０に記憶する。コンテンツファイル再生部２５は、前記再構築されたコンテンツファイルを適宜に再生する。
【００２７】
　図３は、前記GWに実装されるプロキシ機能部４の主要部の構成を示した機能ブロック図であり、ここでも、本発明の説明に不要な構成は図示が省略されている。
【００２８】
　プロキシ要求受付部４１は、携帯電話２のピア機能部５から送信されたプロキシ要求を受信し、当該プロキシ要求に登録されているトレントファイル（メタ情報ファイル）を抽出し、これを記憶部４０へ記憶する。ピア情報取得部４２は、前記抽出されたトレントファイルを含むピア情報要求をトラッカーへ送信してピア情報リストを取得し、これを記憶部４０に記憶する。ダウンロード部４３は、前記取得されたピア情報リストに登録されている各ピアとの間にP2P接続を確立してピースをダウンロードする。
【００２９】
　ピース認証部４４は、ダウンロードされたピースから計算されるハッシュ値とトレントファイルに予め登録されている当該ピースのハッシュ値とを比較し、両者が一致すれば正規のピースとして記憶部４０に保存する一方、不一致であれば不正ファイルとして破棄する。ピース転送部４５は、認証に成功したピースを携帯電話２のピア機能部５へ転送する。アップロード部４６は、ダウンロードしたピースを適宜にアップロードする。
【００３０】
　前記ピア情報取得部４２、ダウンロード部４３、ピース認証部４４およびアップロード部４６は、従来のピアが備える機能と同一または同等であり、既知のBitTorrentクライアントなどで実現できる。
【００３１】
　次いで、本実施形態の動作を図４，５のフローチャートおよび図６のシーケンスフローを参照して説明する。図４は、前記携帯電話２のピア機能部５の動作を示し、図５は、前記GWのプロキシ機能部４の動作を示している。
【００３２】
　携帯電話２のピア機能部５では、図４のステップＳ１１において、ユーザによりトレントファイルおよびその保存先が指定されると、ステップＳ１２では、トレントファイルの識別子を含むトレントファイル要求が、前記メタ情報取得部２１から、その保存先のWebサーバへ送信される。Webサーバからトレントファイルが送信され、これがステップＳ１３で受信されると、ステップＳ１４では、GWのプロキシ機能部４との間で接続・認証処理が実行される。
【００３３】
　プロキシ機能部４では、図５のステップＳ３１において、携帯電話２のピア機能部５からの接続・認証要求が前記プロキシ要求受付部４１で受信されると、ステップＳ３２で接続・認証処理が実行される。ステップＳ３３において、接続・認証に成功したと判定されると、ステップＳ３４ではBitTorrentクライアントが起動される。その結果、前記ピア情報取得部４２、ダウンロード部４３、ピース認証部４４およびアップロード部４６が仮想的に実装され、携帯電話２に対してクライアント起動通知が送信される。なお、前記ステップＳ３３において、接続・認証に失敗すると、ステップＳ４７へ進んで接続が切断される。
【００３４】
　図４へ戻り、携帯電話２のピア機能部５では、ステップＳ１５において前記クライアント起動通知を受信すると、ステップＳ１６では、前記Webサーバから取得したトレントファイルが、前記プロキシ要求部２２によってGWのプロキシ機能部４へ送信される。
【００３５】
　図５へ戻り、プロキシ機能部４では、このトレントファイルがステップＳ３５で前記プロキシ要求受付部４１において受信されると、ステップＳ３６では、当該トレントファイルを含むピア情報要求が、前記ピア情報取得部４２からトラッカーへ送信される。ステップＳ３７において、トラッカーから返信されたピア情報リストが受信されると、ステップＳ３８では、当該リストに登録されている各ピアからP2P通信によりピースを収集するピース受信処理が、前記ダウンロード部４３において実行される。
【００３６】
　本実施形態では、ステップＳ３９においてピースが受信されるごとにステップＳ４０へ進み、前記ピース認証部４４において、当該受信されたピースから計算されるハッシュ値と、当該受信したピースに対応付けられてトレントファイルに登録されているハッシュ値とに基づいてファイル認証が実行される。ステップＳ４１において、認証に成功したと判定されたピースは一時記憶されると共に、ステップＳ４２において、前記ピース転送部４５により携帯電話２へ転送される。認証に失敗したと判定されたピースは、ステップＳ４８で破棄される。
【００３７】
　上記したピース受信処理は、全てのピースの受信が完了するまで繰り返され、ステップＳ４３において、全てのピースの受信を完了すると、ステップＳ４４において携帯電話２へ終了通知が送信される。
【００３８】
　図４へ戻り、携帯電話２のピア機能部５では、GWのプロキシ機能部４が前記ステップＳ４２で転送したピースが、ステップＳ１７においてダウンロード部２３において受信されると、ステップＳ２１へ進んで当該ピースが記憶される。その後、全ピースの転送・蓄積が完了し、プロキシ機能部４が前記ステップＳ４４で送信した終了通知がステップ１８で受信されると、ステップＳ１９でACKが返信される。ステップＳ２０では、前記コンテンツファイル生成部２４において、全てのピースとトレントファイルとが合成されてコンテンツファイルが生成される。
【００３９】
　図５へ戻り、GWのプロキシ機能部４では、前記ACKがステップＳ４５で受信されると、ステップＳ４６では、ダウンロードしたピースのアップロードが開始される。」（４〜８頁）
　上記刊行物Ａの記載及び図面並びにこの分野における技術常識を考慮すると、上記イ．の【０００１】における「本発明は、ピア・ツー・ピア通信方法およびシステムに係り、特に、リンク速度が遅い端末でも高速なファイル交換を可能にするピア・ツー・ピア通信方法およびシステムに関するものである。」との記載、及び図１によれば、刊行物Ａのピア・ツー・ピア通信システムは、携帯ＩＰネットワークと、インターネット（１）とを有している。
　また、上記ハ．の【００２２】における「図１は、本発明のP2P通信方法およびシステムが適用されるネットワーク構成の一例を示した図であり、ここでは、低速の無線リンクでゲートウエイ(GW)を介してインターネット１に接続できる携帯電話２が、インターネット１上の各ピア３から所望のコンテンツファイルを収集する場合を例にして説明する。」との記載、及び図１によれば、刊行物Ａのピア・ツー・ピア通信システムは、前述の携帯ＩＰネットワークの中に配置されたゲートウエイ（ＧＷ）を有している。そして、ピア・ツー・ピア通信システムは、インターネット（１）に接続できる携帯電話（２）が、インターネット（１）上の各ピア（３）から所望のコンテンツファイルを収集するから、前述の携帯ＩＰネットワークと関連して動作するＰ２Ｐネットワークを有することは明らかである。
　また、上記ロ．の【０００６】における「無線リンクを使用した接続では、ピアとなる端末の送信信号が基地局からの送信信号より一般に微弱であるため、下りリンク速度に較べて上りリンク速度が遅くなる。このため、ADSLやFTTHリンクに接続されたピア端末と無線リンクに接続されたピア端末との間でP2P通信する場合、無線リンクの上りリンクがボトルネックとなって効率の良い高速なファイル交換が難しくなる。」との記載、及び図１によれば、前述の携帯電話（２）は、前述の携帯ＩＰネットワークからの下りリンクの帯域幅が前述の携帯ＩＰネットワークへの上りリンクの帯域幅よりも大きい非対称接続を有していることが読み取れる。
　また、上記ハ．の【００２３】における「前記携帯電話２がピアに参加しない非ピア端末であり、この携帯電話２にピア機能部５を設け、インターネット１と高速リンクで接続されたGWにプロキシ機能部４を設けてピアに参加させ、このプロキシ機能部４が、携帯電話２のピア機能部５から送信されるプロキシ要求に応答して各ピアからファイルのピースを代理で収集し、収集したピースを低速の無線リンク経由で携帯電話２のピア機能部５へ転送する。」との記載、上記ロ．の【００１８】における「非ピア端末が、自身の代わりにプロキシ端末をピアに参加させ、このプロキシ端末がP2P通信で各ピアからダウンロードしたピースを、当該プロキシ端末から直接ダウンロードするので、非ピア端末のリンク速度が低速であったり、非ピア端末の処理能力が低い場合でも、高速なファイル交換が可能になる。」との記載、同ロ．の【００２１】における「ダウンロードしたピースを、プロキシ端末が非ピア端末に代わってアップロードするようにしたので、非ピア端末の上りリンク速度が低速であり、かつピースのダウンロード速度がアップロード速度に依存する、BitTorrentのようはファイル交換アルゴリズムでも、高速なダウンロードが可能になる。」との記載、及び図１によれば、前述のゲートウエイ（ＧＷ）は、プロキシ機能部（４）を備え、プロキシ機能部（４）がＰ２Ｐネットワークに対してBitTorrentのクライアントであるかのように動作し、上りリンクでのゲートウエイ（ＧＷ）へのコンテンツファイルの転送を要求することを回避するように携帯電話（２）とＰ２Ｐネットワークとの間をインターフェースする機能を有しているということができる。
　そして、上記ロ．の【００２１】における「ダウンロードしたピースを、プロキシ端末が非ピア端末に代わってアップロードするようにしたので、非ピア端末の上りリンク速度が低速であり、かつピースのダウンロード速度がアップロード速度に依存する、BitTorrentのようなファイル交換アルゴリズムでも、高速なダウンロードが可能になる。」との記載によれば、刊行物Ａのピア・ツー・ピア通信システムは、BitTorrentを使用するＰ２Ｐネットワークにおける上りリンクの帯域幅の消費を減少させるためのピア・ツー・ピア通信システムということができる。
　したがって、上記刊行物Ａには、以下の発明（以下、「引用発明Ａ」という。）が記載されているものと認められる。
　「BitTorrentを使用するＰ２Ｐネットワークにおける上りリンクの帯域幅の消費を減少させるためのピア・ツー・ピア通信システムであって、
　携帯ＩＰネットワークと、
　前記携帯ＩＰネットワークと関連して動作するＰ２Ｐネットワークと、
　前記携帯ＩＰネットワークからの下りリンクの帯域幅が前記携帯ＩＰネットワークへの上りリンクの帯域幅よりも大きい非対称接続を有する携帯電話（２）と、
　前記携帯ＩＰネットワークの中に配置されたゲートウエイ（ＧＷ）とを備え、
　前記ゲートウエイ（ＧＷ）が前記Ｐ２Ｐネットワークに対してクライアントであるかのように動作し、上りリンクでの携帯電話（２）からゲートウエイ（ＧＷ）へのファイルコンテンツの転送を要求することを回避するように、ゲートウエイ（ＧＷ）が前記携帯電話（２）と前記Ｐ２Ｐネットワークとの間をインターフェースする機能を有する、ピア・ツー・ピア通信システム。」
イ．対比
　本願発明と引用発明Ａとを対比する。
ａ．引用発明Ａの「BitTorrent」は、相手（ピア）からファイルの一部を受け取るには、自分もファイルの一部を渡さなければならい規則を有するから、「報復プロトコル」ということができる。
ｂ．引用発明Ａの「上りリンク」及び「下りリンク」は、それぞれ、本願発明の「逆方向リンク」及び「順方向リンク」に相当する。
ｃ．引用発明Ａの「携帯ＩＰネットワーク」は、本願発明の「データネットワーク」ということができる。
ｄ．本願発明の「クライアント」と、引用発明Ａの「携帯電話（２）」とは、後述する相違点を除いて、「端末」という点で一致する。
ｅ．上記ハ．の【００２３】における「携帯電話２がピアに参加しない非ピア端末であり、この携帯電話２にピア機能部５を設け、インターネット１と高速リンクで接続されたGWにプロキシ機能部４を設けてピアに参加させ、このプロキシ機能部４が、携帯電話２のピア機能部５から送信されるプロキシ要求に応答して各ピアからファイルのピースを代理で収集し、収集したピースを低速の無線リンク経由で携帯電話２のピア機能部５へ転送する。」との記載によれば、引用発明Ａの「ゲートウエイ（ＧＷ）」は、「ピアトゥピアプロキシサーバ」ということができる。
　したがって、本願発明と引用発明Ａは、以下の点で一致ないし相違している。
＜一致点＞
　「報復プロトコルを使用するピアトゥピアネットワークにおける逆方向リンクの帯域幅の消費を減少させるためのシステムであって、
　データネットワークと、
　前記データネットワークと関連して動作するピアトゥピアネットワークと、
　前記データネットワークからの順方向リンクの帯域幅が前記データネットワークへの逆方向リンクの帯域幅よりも大きい非対称接続を有する端末と、
　前記データネットワークの中に配置されたピアトゥピアプロキシサーバとを備え、
　前記ピアトゥピアプロキシサーバが前記ピアトゥピアネットワークに対してクライアントであるかのように動作し、逆方向リンクでの端末からピアトゥピアプロキシサーバへのファイルコンテンツの転送を要求することを回避するように、ピアトゥピアプロキシサーバが前記端末と前記ピアトゥピアネットワークとの間をインターフェースする専用の機能を有する、システム。」
＜相違点１＞
一致点の「端末」に関し、
　本願発明の「クライアント」は、ピアトゥピアネットワークのクライアントといえるのに対し、引用発明Ａの「携帯電話」は、非ピア端末である点。
＜相違点２＞
一致点の「ピアトゥピアプロキシサーバが前記クライアントと前記ピアトゥピアネットワークとの間をインターフェースする」に関し、
　本願発明は、ピアトゥピアプロキシサーバが前記クライアントと前記ピアトゥピアネットワークとの間を「透過的に」インターフェースするのに対し、引用発明Ａは、ゲートウエイ（ＧＷ）が前記携帯電話（２）と前記Ｐ２Ｐネットワークとの間をインターフェースするものの、「透過的に」インターフェースしない点。
ウ．判断
　上記相違点１及び２について検討する。
　引用発明Ａの「携帯電話（２）」は非ピア端末であり、このため、ピア端末ならば、ピア情報要求をトラッカーへ送信するところ、上記刊行物Ａの上記ハ．の【００３４】、図６のとおり、Webサーバから取得したトレントファイルを、ゲートウエイ（ＧＷ）へ送信し、ゲートウエイ（ＧＷ）が、トレントファイルをピア情報要求に換えて、トラッカーへ送信するものである。したがって、携帯電話（２）から見れば、ゲートウエイ（ＧＷ）は、携帯電話（２）とＰ２Ｐネットワークとの間を「透過的に」インターフェースするものではない。よって、上記相違点である本願発明の発明特定事項である「透過的に」インターフェースする点を、引用発明Ａから導き出すことはできない。
　そして、本願発明は、上記発明特定事項を備えることにより、本願明細書段落【００１２】に記載されたように、クライアント側のピアトゥピアソフトウエアを見直すことの費用、およびその複雑な事態が生じないという作用効果を奏するものである。
エ．小括
　よって、本願発明は、刊行物Ａに記載された発明とはいえなくなり、また、引用発明Ａに基づいて、当業者が容易に発明をすることができたとはいえなくなった。
　請求項２〜６は、請求項１を直接又は間接的に引用する従属項であり、本願発明の発明特定事項をすべて含みさらに発明特定事項を追加して限定したものであるから、上記（３）と同じ理由により、刊行物Ａに記載された発明とはいえなくなり、また、引用発明Ａに基づいて当業者が容易に発明をすることができたとはいえなくなった。
　請求項７は、請求項１に係る発明のカテゴリーを「方法」とした発明であるから、上記（３）と同じ理由により、刊行物Ａに記載された発明とはいえなくなり、また、引用発明Ａに基づいて当業者が容易に発明をすることができたとはいえなくなった。
　請求項８〜１０は、請求項７を直接的に引用する従属項であり、本願発明の発明特定事項をすべて含みさらに発明特定事項を追加して限定したものであるから、上記（３）と同じ理由により、刊行物Ａに記載された発明とはいえなくなり、また、引用発明Ａに基づいて当業者が容易に発明をすることができたとはいえなくなった。
　したがって、当審拒絶理由１及び２は解消した。
（２）理由３について
イ．平成２８年３月２４日付け意見書により、「ピアトゥピアネットワーク」及び「データネットワーク」の用語の技術的意味が釈明された。このことにより、請求項１、７に記載された「ピアトゥピアネットワーク」及び「データネットワーク」が、それぞれ、本願明細書及び図面における「Ｐ２Ｐオーバーレイネットワーク」及び「ＩＰネットワークおよび／またはモバイルネットワーク」に対応することが明らかになった。
ロ．平成２８年３月２４日付け手続補正により、請求項１、７に「報復プロトコルを使用する」を追加された。このことにより、ピアトゥピアネットワークが報復プロトコルを使用すること、データネットワークからクライアントへの順方向リンクの帯域幅がクライアントからデータネットワークへの逆方リンクの帯域幅よりも大きいことを明らかになり、請求項１〜７に係る発明は、発明の詳細な説明に記載したものとなった。
　よって、当審拒絶理由３は解消した。
第５　むすび
　以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。