【事件の表示】
　特願２００５−３７５５１０「単一のＨＴＴＰ要求を使用したメッセージの大量伝送」拒絶査定不服審判事件〔平成１８年　７月２０日出願公開、特開２００６−１９０２８２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２００５年１２月２７日（パリ条約による優先権主張外国庁受理２００５年１月７日、米国）の出願であって、平成２３年６月１日付けで拒絶査定がなされ（発送日：同年６月３日）、これに対して同年１０月３日に審判の請求がなされ、同時に手続補正がなされたものである。
　
第２　平成２３年１０月３日付けの手続補正についての補正却下の決定
［補正却下の結論］
　平成２３年１０月３日付けの手続補正（以下、「本件補正」という。）を却下する。
　
［理由］
１．本願補正発明
　本件補正により、特許請求の範囲の請求項１は、
「ＨＴＴＰ要求応答トランスポートを使用する分散型システムにおいて、対応するＨＴＴＰ要求の受信に応答して、複数の異なるメッセージを含むＨＴＴＰ応答を転送する方法であって、
　分散型システムの２つのエンドポイント間で通信を確立するために、ＨＴＴＰ要求応答トランザクションの一環としてＨＴＴＰ要求メッセージを送信するステップと、
　ＨＴＴＰ要求応答の一環として、第１の時間枠で、ＨＴＴＰ応答の第１のメッセージを受信するステップと、
　前記ＨＴＴＰ応答の追加のメッセージを受信するために前記ＨＴＴＰ要求応答トランザクションを、オープン状態で維持するステップと、
　他のＨＴＴＰ要求メッセージを送信することなく、前記ＨＴＴＰ要求応答トランザクションの一環として、前記第１の時間枠とは異なる第２の時間枠で、前記ＨＴＴＰ応答の第２のメッセージを受信するステップと　
　前記２つのエンドポイント間
で確立した通信とは異なる別
　を備えることを特徴とする方法。」
と補正された。（下線は、補正箇所を示す。）
　
　上記補正は、請求項１に記載した発明を特定するために必要な事項のうち、本件補正前（平成２３年３月１７日付け手続補正書参照）において、「前記２つのエンドポイント間
の別々
で確立した通信とは異なる別
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
２．引用例（欧州特許出願公開第１２４４２６９号明細書）
　原査定の拒絶の理由で引用された、本願の優先日前である２００２年９月２５日に公開された、欧州特許出願公開第１２４４２６９号明細書（審決注：以下「引用例」という。なお、拒絶理由通知等に「欧州特許第１２４４２６９号明細書」とあるのは、誤記と認める。）には、図面と共に、次の事項が記載されている（下線は当審にて付与。以下同様。）。
　
（１）　段落[0001]−[0006]
「[0001]  The invention relates in general to transmitting data in a packet data network. In particular the invention relates to transmitting data, which may be updated, from a server to a client.
[0002]  Term client refers in the specification and in the appended claims to a device or application (program) connecting to a server via a data network and typically requesting the server to send certain information. Term server refers to a device or application, which waits for connection requests from clients and responses to the requests by sending requested information. Term real-time service refers to services, where information residing in a server is updated every now and then and the updated information is delivered to a client. The server and client are connected to each other typically via a packet data network, for example via the Internet.  Information is typically transferred from a server to a client using Hypertext Transfer Protocol  (HTTP), and the client is typically a browser. Term real-time information refers to information,  which resides in a server and is updated every now and then.
[0003]  Real-time services become more and more widespread, and examples of such services are news and stock market information. There are two basic alternatives of keeping a client informed about the changes (or updates) in the information.
　
　　　・・・（中略）・・・
　
[0005]  A common protocol for transmitting data in packet data networks and especially in IP  (Internet Protocol) networks is HTTP.  HTTP uses Transfer Control Protocol (TCP), which provides reliable data transfer using acknowledgments of received data packets and, when needed, retransmission of data packets. For transmitting information using HTTP between a server and a client, a TCP connection is typically formed.  HTTP messages are then transmitted using the established TCP connection.
[0006]  A HTTP connection consists basically of a HTTP request and a HTTP response.  A client sends a HTTP request indicating typically a certain URL (Universal Resource Locator), and the server responds by sending data relating to the URL in a HTTP response. Thereafter the client, especially when it is a browser, presents the received data to a user.」
（当審訳）
【０００１】　本発明は、一般的には、
パケット・データ・ネットワークにおける
サーバからクライアントに、更新され得るデータを送信する
【０００２】　本明細書及び添付の請求項において、用語「クライアント」は、データ・ネットワークによりサーバに接続して、典型的にはサーバに存する情報を送信するように要求する、装置又はアプリケーション（プログラム）を指す。用語「サーバ」は、クライアントからの接続要求を待ち、要求された情報を送ることによって、その要求に応答する、装置又はアプリケーションを指す。用語「リアルタイムサービス」は、サーバ上に存在する情報が時々更新されて、更新された情報がクライアントに送達されるサービスを指す。典型的に、サーバとクライアント間は、例えばインターネットのような、パケット・データ・ネットワークにより接続される。典型的に、情報は、サーバからクライアントに、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いて転送され、そして、典型的に、クライアントは、ブラウザである。用語「リアルタイム情報」は、サーバに存する、時々更新される情報を指す。
【０００３】　リアルタイム・サービスは、ますます普及しつつある。また、そのようなサービスの例として、ニュースや株式市場情報がある。クライアントを、情報の変化（あるいは更新）に関する情報を知り得る状態におくために、２つの基本的な選択肢がある。
　
　　　・・・（中略）・・・
　
【０００５】　パケット・データ・ネットワークにおいて、特にＩＰ（インターネット・プロトコル）ネットワークにおいて、
データを送信するためのありふれたプロトコルは、ＨＴＴＰである
その後ＨＴＴＰメッセージは、確立されたＴＣＰコネクションを使用して送信される
【０００６】　
ＨＴＴＰコネクションは、基本的に、ＨＴＴＰ要求及びＨＴＴＰ応答からなる
　
（２）　段落[0018]
「[0018]  In some cases a client program may determine to close a packet data connection or may determine that there is no further data to be received, if no data is transmitted for a certain period of time. The latter case is true for some browsers. Therefore, in a method according to the invention, the time period between two sequential response portions is advantageously limited to a certain maximum value. This way, for example, a client, which is a browser, does not close a HTTP connection or a TCP connection relating to the transfer of the requested information entity.」
（当審訳）
【００１８】　ある場合においては、特定の期間データが送信されないならば、クライアント・プログラムは、パケット・データ・コネクションを閉じると決定するか、又は、これ以上受信すべきデータは存在しないと決定するかもしれない。後のケースは、いくつかのブラウザに該当する。したがって、本発明の方法では、２つの連続する応答部分の間の期間は、有利にはある最大値に制限される。このようにして、例えばブラウザのようなクライアントは、要求された情報エンティティの転送に関連する
ＨＴＴＰコネクションあるいはＴＣＰコネクションを閉じない
　
（３）　段落[0024]−[0031]
「[0024]  Figure 2 illustrates as an example a flowchart of a method 200 for transferring information according to a first preferred embodiment of the invention. In step 201 a request, which is according to a certain data transfer protocol and specifies a certain information entity I, is received.  In step 202, at a first time instant t1 a first response portion R1, typically comprising a first information fragment I1 relating to said information entity I is sent to said client. This first response portion R1 is such that it causes the client to expect at least a second response portion. Such a second response portion typically contains second information fragment I2 relating to said information entity I.  Examples of such response portions R1 are described in more detail below in connection with other preferred embodiments of the invention.
[0025]  After sending the first response portion R1(I1) it is checked in step 203, whether the information entity I residing typically at the server is updated. If the information entity has been updated after t1, a second response portion R2,1(I2) is sent in step 204 at time instant t2,1. This second response R2,1 comprises an information fragment I2 relating to the information entity I. This information fragment may be, for example, either the whole updated information entity I or the part of the information entity I that has been updated. The second response portion R2,1 comprises also some computer language instructions for processing the information fragment I2. It may further comprise computer language headers. A counter i is increased in step 204 for reasons of clarity. Such a counter is not necessarily used in a method according to the invention.
[0026]  If the information entity I has not been updated after t1, it is checked in step 205 whether time lapsed since t1 is equal to or greater than a certain predetermined maximum time period Tmax. A typical value for this maximum time period is 30 -120 seconds, but it may range from about a second to a few minutes. If such a period of time has not yet lapsed, steps 203 and 205 are repeated until either of the checks is true. If such a period of time has already lapsed since t1, when step 205 is performed, a third response portion R3,1 is sent in step 206 at time instant t3,1. As the information entity I has not been updated since t1, it is not necessary to send any information fragments in this response portion. The purpose of sending this response portion R3,1 is to ensure that a client stays ready to accept further second response portions R2,i. A counter k is increased in step 206 for reasons of clarity.  Such a counter is not necessarily used in a method according to the invention.
[0027]  The second response portion R2,1 is the earliest sent response of a plurality of second response portions R2,i. The number of these second response portions R2,i depends typically on the duration of the information transfer. The information transfer maybe stopped, for example, by a client closing a data transfer connection, for example a TCP connection, using which the response portions, for example, HTTP message portions, are delivered to the client.
[0028]  After sending the earliest of the second response portions R2,1 or the earliest of third response portions R3,1 it is checked in step 207, whether the information entity I residing typically at the server is updated since t2,i-1. If the information entity has been updated after t2,i-1, a further second response portion R2,i(Ij+1) is sent in step 208 at time instant t2,i. The counter i is increased in the same step. The response portion R2,i comprises an information fragment Ij+1 relating to the information entity I. If the information entity I has not been updated after t2,i-1, it is checked in step 209 whether time lapsed since t2,i-1 or t3,k-1 is equal to or greater than a certain predetermined maximum time period Tmax. If such a period of time has not yet lapsed, steps 207 and 209 are repeated until either of the checks is true. If such a period of time has already lapsed since t2,i-1 or t3,k-1, when check in step 209 is performed, a further third response portion R3,k is sent in step 210. Similarly as in step 205 for the third response portion R3,1, it is not necessary to send any information fragments in the response portion R3,k in step 210.
[0029]  After step 208 or 210 the method 200 continues in step 207. The steps 207-210 are repeated as long as method 200 is carried out. Typically, the resulting sequence of messages contains second and third response portions interleaved with each other. It is possible that the resulting sequence of messages contains, after the first response portion, only second response portions; this is the case typically, when either the information entity I is updated frequently or when there is no need to transmit messages so that the time interval between two sequential response portions has at maximum a certain value. In the latter case typically no third response portions are sent. The time intervals checks in steps 205 and 209 may use different values for the  maximum interval; Figure 2 shows a same Tmax value in both steps 205 and 209 as an example.
[0030]  The information fragment I1 in the first response portion in step 202 may be the current information entity I or a part of the current information entity I. If I1 is only part of the information entity I, it is possible that in some second response portions R2,i sent in steps 204 and 208 comprise further information fragments relating to the information entity I at time instant t1 are transmitted.  Alternatively, it is possible that the first response portion R1 contains only, for example, an identifier indicating, for example, a name of the information entity I.  Furthermore, R1 need not contain any part of the actually requested information entity I; in this case I1 refers to a non-existent information fragment or to an empty information fragment.
[0031]  In the following, when further preferred embodiments of the invention are described, HTTP is used as an example of a standard data transfer protocol and a TCP connection is used as an example of a packet data connection. The ideas presented below are, however, not restricted to use of HTTP or TCP.」
（当審訳）
【００２４】　図２は、本発明の第１の好適実施例による情報伝送の方法２００のフローチャートを例示する。ステップ２０１で、特定のデータ転送プロトコルにより、特定の情報エンティティＩを指定する、要求が受信される。ステップ２０２で、第１の時刻ｔ1において、第１の応答部分Ｒ1、典型的には前述の情報Ｉに関連する第１の情報フラグメントＩ1を含むものが、前述のクライアントに送信される。この第１の応答部分Ｒ1は、クライアントに少なくとも第２の応答部分が送信されるものと予期させる。そのような第２の応答部分は、典型的には、前述の情報エンティティＩに関連する、第２の情報フラグメントＩ2を含む。そのような応答部分Ｒ1の例が、本発明の他の好適な実施例と関連して、以下で述べられる。
【００２５】　第１の応答部分Ｒ1（Ｉ1）の送信後、ステップ２０３で、サーバに典型的には存する、情報エンティティＩが更新されたかをチェックする。情報エンティティがｔ1以降に更新されている場合、ステップ２０４で、第２の応答部分Ｒ2,1（Ｉ2）が、時刻ｔ２において送信される。この第２の応答Ｒ2,1は、情報エンティティに関連する情報フラグメントＩ2を含む。この情報フラグメントは、例えば、更新された情報エンティティＩの全てかもしれないし、更新された情報エンティティＩの一部かもしれない。この第２の応答部分Ｒ2,1は、また、情報のフラグメントＩ2を処理するための、あるコンピュータ言語による指示を含む。さらに、それは、コンピュータ言語のヘッダーを含み得る。ステップ２０４で、明確化のためにカウンタｉが増加される。このようなカウンタは、本発明による方法において、必ずしも使用する必要はない。
【００２６】　情報エンティティＩがｔ1以降、更新されていない場合、ステップ２０５で、ｔ1からの経過時間が、前もって定めた最大期間Ｔmax以上であるかがチェックされる。この最大期間の典型的な値は、３０〜１２０秒間であるが、約１秒〜数分までの範囲をとり得る。そのような期間がまだ経過していない場合、ステップ２０３と２０５とが、何れかのチェックが真となるまで反復される。そのような期間が、ｔ1以降に既に経過している場合、ステップ２０５が実行された時、ステップ２０６で、
第３の応答部分Ｒ
3,1
が、時刻ｔ
3,1
において送信される
この応答部分の中で、どのような情報フラグメントも送信する必要はない
この応答部分Ｒ
3,1
を送る目的は、クライアントが、更なる第２の応答部分Ｒ
2,i
を受領できる状態であり続けることを確実にするためであ
【００２７】　第２の応答部分Ｒ2,1は、多数の第２の応答部分Ｒ2,iのうちの、最初に送られる応答である。これら第２の応答部分Ｒ2,iの個数は、典型的には情報転送の持続期間によって左右される。情報転送は、例えば、例えばＨＴＴＰメッセージ部分のような応答部分を、クライアントに伝送するのに用いられるところの、データ転送コネクション、例えば、
ＴＣＰコネクションを、クライアントが閉じること
【００２８】　第２の応答部分の中で最初であるＲ2,1、又は、第３の応答部分の中で最初であるＲ3,1を送信後に、ステップ２０７で、典型的にはサーバに存する情報エンティティＩが、ｔ2,i-1以降に更新されたかをチェックする。情報エンティティが、ｔ2,i-1以降に更新されていた場合、ステップ２０８で、時刻ｔ2,iにおいて、更なる第２の応答部分Ｒ2,i（Ｉj+1）が送信される。同じステップにおいて、カウンタｉが増加される。応答部分Ｒ2,1には、情報エンティティＩに関連する、情報フラグメントＩj+1を含む。情報エンティティＩが、ｔ2,i-1以降に更新されていない場合、ステップ２０９で、ｔ2,i-1又はｔ3,k-1からの経過時間が、前もって定めた最大期間Ｔmax以上であるかをチェックする。そのような期間がまだ経過していない場合、ステップ２０７と２０９とが、いずれかのチェックが真となるまで反復される。ステップ２０９のチェックを行った時点で、ｔ2,i-1又はｔ3,k-1からそのような時間が経過していた場合、ステップ２１０で、更なる第３の応答部分Ｒ3,kを送信する。ステップ２０５（審決注：「２０６」の誤記と認める。）における
第３の応答部分Ｒ
3,1
と同様に、ステップ２１０で、応答部分Ｒ
3,k
の中でも、どのような情報フラグメントも送信する必要はない
【００２９】　ステップ２０８又は２１０の後、方法２００は、ステップ２０７に続く。方法２００が実行される限り、ステップ２０７〜２１０が反復される。典型的には、結果として生じるメッセージのシーケンスは、交互にちりばめられた、第２と第３の応答部分を含んでいる。結果として生じるメッセージのシーケンスが、第１の応答部分の後に、第２の応答部分だけを含んでいることが起こり得る；これは、典型的には、情報エンティティＩが頻繁に更新される場合や、２つの連続する応答部分の間の時間間隔に所定の最大の値があるために、メッセージ送信の必要がない場合が、該当する。後者の場合、典型的には、第３の応答部分は送信されない。ステップ２０５と２０９の時間間隔のチェックにおける最大の時間間隔として、互いに異なる値を使用してもよい；図２は、ステップ２０５と２０９の両方において同一のＴmaxの値である例を示す。
【００３０】　ステップ２０２で、第１の応答部分中の情報フラグメントＩ1は、現在の情報エンティティＩかもしれず、あるいは、現在の情報エンティティＩの一部であるかもしれない。Ｉ1が情報エンティティの一部に過ぎない場合、ステップ２０４と２０８で送信される第２の応答部分Ｒ2,iのあるものが、時刻ｔ1における情報エンティティＩに関連する、さらなる情報フラグメントを含むことがあり得る。あるいは、第１の応答部分Ｒ1が、例えば情報エンティティＩの名前を示すような、例えば識別子だけを含み得る。更に、Ｒ1は、実際に要求された情報エンティティＩのどのような部分も含む必要はない；この場合、Ｉ1は、情報フラグメントの非存在、あるいは、空の情報フラグメントを指す。
【００３１】　下記で、本発明の更なる好適な実施例が記述される際、ＨＴＴＰが、標準的なデータ転送プロトコルの例示として使用される。また、ＴＣＰコネクションが、パケット・データ・コネクションの例示として使用される。しかしながら、下記で提示されるアイデアは、ＨＴＴＰ又はＴＣＰの使用に限定されない。
　
（４）　段落[0036]−[0038]
「[0036]  Figure 3 illustrates as an example a message sequence between a client 110, which is a browser, and a server 300; this message sequence relates to the third preferred embodiment of the invention. Messages presented in Figure 3 are HTTP messages or portions of HTTP messages, examples of which are presented in Table 2 and which are transferred typically using a single TCP connection.
[0037]  The first initiating request 301 is a HTTP request specifying a HTML  document feedframe.htm. This HTML document is delivered to a client in the first initiating response 302, which is a HTTP response indicating two frames (feedsource, feedtarget) and sources (/feed.rtscript and /feedtarget.htm), where content for these frames can be fetched. After receiving the HTTP response 302 the client sends a second initiating request 303, which is a HTTP request specifying HTML document feedtarget.htm. As a response to the message 303, the server sends a second initiating response 304, which is a HTTP response specifying name t1 for a field of type text in a form, whose name is f1. As can be seen in Table 2, the HTTP responses 302 and 304 contain the Content-Length parameter and a value for this parameter. Figure 3 illustrates, how the message pairs 301, 302 and 303, 304 form two HTTP connections 140d, 140e.
[0038]  The request 305, which is a HTTP request specifying source feed.rtscript, starts a message sequence in accordance with the invention. As a response to this request 305, the server first sends a first response portion 306. This first response portion 306 is a beginning of a HTTP response message. It declares, with the HMTL tag, that an HTML document is being transmitted. The body of the HTML document is empty, and between the script tags value 0 is defined for the field t1 in form f1 in a frame[1] (which relates to the feedtarget.htm) in a parent window.  The second response portion R2,1 307 defines value 1 for the same input parameter, and the second response portion R2,2 308 defines value 2 for the input parameter. No further response portions are illustrated in Table 2, but Figure 3 illustrates a third response portion R3,1 309, which is typically similar to one of the alternative presented in Table 1 for third response portion R3,i. After this third response portion, a further second response portion R2,3 310 is sent to the client. It is possible that sequential third response portions are sent to a client (as is evident, for example, from Figure2), although this is not illustrated in Figure 3.」
（当審訳）
【００３６】　図３は、
ブラウザであるクライアント１１０と、サーバ３００との間のメッセージ・シーケンス
メッセージは、ＨＴＴＰメッセージ又はＨＴＴＰメッセージの部分であり
これらは、典型的には、単一のＴＣＰコネクションを用いて転送され
【００３７】　
第１の開始の要求３０１は、ＨＴＭＬドキュメントfeedframe.htmを指定するＨＴＴＰ要求であ
第１の開始の応答３０２で、クライアントに、このＨＴＭＬドキュメントが送達され、これは、ＨＴＴＰ応答であって、
ＨＴＴＰ応答３０２の受信後、クライアントは、第２の開始の要求３０３を送信
これは、ＨＴＭＬドキュメントfeedtarget.htmを指定するＨＴＴＰ要求であ
メッセージ３０３に応答して、サーバは、第２の開始の応答３０４を送信
これは、
、ＨＴＴＰ応答であ
メッセージのペア３０１と３０２、及び、３０３と３０４が
２つのＨＴＴＰコネクション１４０ｄと１４０ｅを形成
【００３８】　
ソースfeed.rtscriptを指定したＨＴＴＰ要求である、要求３０５は、本発明による、メッセージのシーケンスを開始
この要求３０５への応答として、サーバは、最初に第１の応答部分３０６を送信
この第１の応答部分３０６は、ＨＴＴＰ応答メッセージの始まり
であ
scriptタグに挟まれて、親ウインドウの（feedtarget.htmに関連する）ｆｒａｍｅ［１］におけるフォームｆ１のフィールドｔ１に対して、値０が定義され
第２の応答部分Ｒ
2,1
３０７では、同じ入力パラメータに対して、値１が定義され
第２の応答部分Ｒ
2,2
３０８では、その入力パラメータに対して、値２が定義され
更なる応答部分は
第３の応答部分Ｒ
3,1
３０９
これはテーブル１で、第３の応答部分
Ｒ
3,k
として示した選択肢の一つに典型的には類似
第３の応答部分の後、更なる第２の応答部分Ｒ
2,3
３１０が、クライアントに送信され
一連の第３の応答部分が送られ得る
　
（５）　テーブル１（８頁）の最下行
　テーブル１の最下行には、項目「third response portion Ｒ3,K（当審訳：第３の応答部分Ｒ3,K）」として、「\r\n（審決注：標準的な書式の
改行コード
又は、
SCRIPT
/SCRIPT
、又は、
SCRIPT/
　
（６）　図３
　図３の左端のＴｉｍｅ（時刻）欄より、３０６、３０７、３０８、３０９、３１０が、それぞれ、時刻ｔ1、時刻ｔ2,1、時刻ｔ2,2、時刻ｔ3,1、時刻ｔ2,3に実行されていること、時刻ｔ3,1までの、時刻ｔ2,2からの経過時間がＴmaxであると、認められる。
　また、「ＨＴＴＰ要求３０５」以降、それ以外の「要求」は送信されていないと認められる
　
　これらの記載から、引用例には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　
「パケット・データ・ネットワークにおける、サーバからクライアントに、更新され得るデータを送信する方法であって、
　ブラウザであるクライアント１１０と、サーバ３００との間のメッセージ・シーケンスにおいて、
　メッセージは、ＨＴＴＰメッセージ又はＨＴＴＰメッセージの部分であり、これらは、典型的には、単一のＴＣＰコネクションを用いて転送され、
　第１の開始の要求３０１は、ＨＴＭＬドキュメントfeedframe.htmを指定するＨＴＴＰ要求であり、
　第１の開始の応答３０２で、クライアントに、このＨＴＭＬドキュメントが送達され、これは、ＨＴＴＰ応答であって、
　ＨＴＴＰ応答３０２の受信後、クライアントは、第２の開始の要求３０３を送信し、これは、ＨＴＭＬドキュメントfeedtarget.htmを指定するＨＴＴＰ要求であり、
　メッセージ３０３に応答して、サーバは、第２の開始の応答３０４を送信し、これは、ＨＴＴＰ応答であり、
　ここで、メッセージのペア３０１と３０２、及び、３０３と３０４が、２つのＨＴＴＰコネクション１４０ｄと１４０ｅを形成しており、
　ソースfeed.rtscriptを指定したＨＴＴＰ要求である、要求３０５は、本発明による、メッセージのシーケンスを開始し、
　時刻ｔ1に、この要求３０５への応答として、サーバは、最初に第１の応答部分３０６を送信し、この第１の応答部分３０６は、ＨＴＴＰ応答メッセージの始まりであり、scriptタグに挟まれて、親ウインドウの（feedtarget.htmに関連する）ｆｒａｍｅ［１］におけるフォームｆ１のフィールドｔ１に対して、値０が定義され、
　時刻ｔ2,1に、第２の応答部分Ｒ2,1３０７では、同じ入力パラメータに対して、値１が定義され、
　時刻ｔ2,2に、第２の応答部分Ｒ2,2３０８では、その入力パラメータに対して、値２が定義され、
　時刻ｔ2,2からの経過時間がＴmaxである時刻ｔ3,1における、更なる応答部分は、第３の応答部分Ｒ3,1３０９であり、これは、第３の応答部分Ｒ3,iとして示した選択肢（改行コード、又は、SCRIPT/SCRIPT、又は、SCRIPT/）の一つに典型的には類似し、この応答部分Ｒ3,1を送る目的は、クライアントが、更なる第２の応答部分Ｒ2,iを受領できる状態であり続けることを確実にするためであり、
　時刻ｔ2,3において、この第３の応答部分の後、更なる第２の応答部分Ｒ2,3３１０が、クライアントに送信され、
　一連の第３の応答部分が送られ得る、
　方法。」
　
３．対比
　本願補正発明と引用発明とを対比する。
　
（Ａ）　引用発明の「ＨＴＴＰ要求３０５」と「第１の応答部分３０６」、「第２の応答部分Ｒ2,1３０７」、「第２の応答部分Ｒ2,2３０８」等が、「典型的には、単一のＴＣＰコネクションを用いて転送され」る、「パケット・データ・ネットワークにおける」、「クライアント１１０」と「サーバ３００」の構成は、本願補正発明の「ＨＴＴＰ要求応答トランスポートを使用する分散型システム」に相当する。
　引用発明の方法において、「ＨＴＴＰ要求３０５」に応じて、サーバがクライアントに「第１の応答部分３０６」、「第２の応答部分Ｒ2,1３０７」、「第２の応答部分Ｒ2,2３０８」等を送信していることは、本願補正発明の「対応するＨＴＴＰ要求の受信に応答して、複数の異なるメッセージを含むＨＴＴＰ応答を転送する方法」に相当する。
　
（Ｂ）　引用発明において、クライアントが「ＨＴＴＰ要求３０５」を送信することは、これによって、クライアントとサーバ間で複数のＨＴＴＰ応答部分が送信される「メッセージのシーケンスを開始」するから、本願補正発明の「分散型システムの２つのエンドポイント間で通信を確立するために、ＨＴＴＰ要求応答トランザクションの一環としてＨＴＴＰ要求メッセージを送信するステップ」に相当する。
　
（Ｃ）　引用発明において、「時刻ｔ1に、この要求３０５への応答として、サーバは、最初に第１の応答部分３０６」が伝送されることは、本願補正発明の「ＨＴＴＰ要求応答の一環として、第１の時間枠で、ＨＴＴＰ応答の第１のメッセージを受信するステップ」に相当する。
　
（Ｄ）　引用発明において、「
ＨＴＴＰ応答メッセージの始まり
部分
クライアントは、要求された情報エンティティの転送に関連するＨＴＴＰコネクション
を閉じない
　
（Ｅ）　引用発明において、「時刻ｔ2,1」の「第２の応答部分Ｒ2,1３０７」、「時刻ｔ2,2」の「第２の応答部分Ｒ2,2３０８」等の、ＨＴＴＰ応答を構成する一連の「応答部分」を、クライアントが受信することは、図３から、「ＨＴＴＰ要求３０５」以降に他の「要求」は送信されていないと認められることを考慮すると、本願補正発明の「他のＨＴＴＰ要求メッセージを送信することなく、前記ＨＴＴＰ要求応答トランザクションの一環として、前記第１の時間枠とは異なる第２の時間枠で、前記ＨＴＴＰ応答の第２のメッセージを受信するステップ」に相当する。
　
　したがって、両者の一致点、相違点は以下のとおりである。
　
［一致点］
「ＨＴＴＰ要求応答トランスポートを使用する分散型システムにおいて、対応するＨＴＴＰ要求の受信に応答して、複数の異なるメッセージを含むＨＴＴＰ応答を転送する方法であって、
　分散型システムの２つのエンドポイント間で通信を確立するために、ＨＴＴＰ要求応答トランザクションの一環としてＨＴＴＰ要求メッセージを送信するステップと、
　ＨＴＴＰ要求応答の一環として、第１の時間枠で、ＨＴＴＰ応答の第１のメッセージを受信するステップと、
　前記ＨＴＴＰ応答の追加のメッセージを受信するために前記ＨＴＴＰ要求応答トランザクションを、オープン状態で維持するステップと、
　他のＨＴＴＰ要求メッセージを送信することなく、前記ＨＴＴＰ要求応答トランザクションの一環として、前記第１の時間枠とは異なる第２の時間枠で、前記ＨＴＴＰ応答の第２のメッセージを受信するステップと
　を備えることを特徴とする方法。」
である点。
　
［相違点］
　本願補正発明の方法は、「前記２つのエンドポイント間で確立した通信とは異なる別の通信を利用して１つまたは複数の制御メッセージを送信するステップであって、前記１つまたは複数の制御メッセージは、前記２つのエンドポイントが、前記ＨＴＴＰ要求応答トランザクションをオープン状態に維持することを支援するために送信される、制御メッセージを送信するステップ」を備えるのに対して、引用発明の方法は、直前の部分応答からＴmaxが経過した時点で「この応答部分Ｒ3,1を送る目的は、クライアントが、更なる第２の応答部分Ｒ2,iを受領できる状態であり続けることを確実にするためであ」るような、「第３の応答部分Ｒ3,1」を送信することは記載があるものの、「確立した通信とは異なる別の通信を利用して」、「２つのエンドポイントが、前記ＨＴＴＰ要求応答トランザクションをオープン状態に維持することを支援するために送信される、制御メッセージを送信する」ステップについての記載がない点。
　
４．相違点についての判断
　一般に、通信において、ＨＴＴＰや、ＴＣＰコネクション、ＴＣＰポート等の「通信」リソースを、いくつ利用するかは、送信する情報の種類や、ネットワーク環境等に応じた得失を勘案して、当業者が実装において適宜選択すべきものと認められる。そして、複数種類の情報を、別々に通信することも、混在させて通信することも、周知である（＜周知文献Ａ＞渡邉利和，今さら人に聞けないネットワーク基礎知識の補習講義「脱・にわか管理者」への挑戦，ＮＥＴＷＯＲＫ　ＷＯＲＬＤ　Ｖｏｌ．９，Ｎｏ．５，（株）ＩＤＧジャパン，２００４年５月１日，ｐ．１６４−１７０。特に、１６５頁右欄「
ＦＴＰはデータ転送用と制御用の２つのセッションを使い分ける
この実装の
メリットは、データをデータとして特別な制御を行うことなく一気に送ることが可能な点だ
メッセ−ジがデータと混同されることなく確実に交換できるというメリットもある
サーバ側とソケット通信によって制御する方法が一般的である
しかしながら
ＨＴＴＰ通信用のポートとは別のポートを使用することになるため、
ファイアウォール通過等の問題（設定、セキュリティ等）があった
持続的コネクションの効果を最大限に活かすためには
ダミーの通信を行えばよいが
ダミーの通信量が増加するという問題があった
第１の実施形態では、状態通知と操作伝達に専用の通信コネクションを設けていた
　引用発明は、Ｔmax経過時点で、実質的な情報を含まない（引用例の段落【００２６】、【００２８】を参照。）「第３の応答部分Ｒ3」を伝送することで、「クライアントは、要求された情報エンティティの転送に関連するＨＴＴＰコネクションあるいはＴＣＰコネクションを閉じない」もの（引用例の段落【００１８】を参照。）、すなわち、通信コネクションを維持するように制御するための情報を、通常の情報と混在させて通信するものと認められる。
　また、「典型的には、単一のＴＣＰコネクションを用いて転送され」ると記載されることから、引用例には、「典型的な」場合以外である、複数のＴＣＰコネクションを用いることの示唆があると認められる。
　さらに、引用発明が、「ＨＴＴＰ要求３０５」と「第１の応答部分３０６」、「３０７の第２の応答部分Ｒ2,1」等からなるＨＴＴＰ要求応答コネクション以外に、「２つのＨＴＴＰコネクション１４０ｄと１４０ｅを」利用していると認められる点も考慮すると、通信コネクションを維持するように制御するための情報を、通常の情報と混在させて通信する引用発明に、複数種類の情報を、別々に通信する周知技術を適用することによって、複数の制御メッセージとして、「前記２つのエンドポイント間で確立した通信とは異なる別の通信を利用して１つまたは複数の制御メッセージを送信するステップであって、前記１つまたは複数の制御メッセージは、前記２つのエンドポイントが、前記ＨＴＴＰ要求応答トランザクションをオープン状態に維持することを支援するために送信される、制御メッセージを送信するステップを備える」、上記相違点に係る構成とすることは、当業者が容易に推考し得ることである。
　
　そして、本願補正発明のように構成したことによる効果も引用発明及び各周知技術から予測できる程度のものである。
　
５．むすび
　以上のとおり、本願補正発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　
第３　本願発明について
１．本願発明
　平成２３年１０月３日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下「本願発明」という。）は、平成２３年３月１７日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。
「ＨＴＴＰ要求応答トランスポートを使用する分散型システムにおいて、対応するＨＴＴＰ要求の受信に応答して、複数の異なるメッセージを含むＨＴＴＰ応答を転送する方法であって、
　分散型システムの２つのエンドポイント間で通信を確立するために、ＨＴＴＰ要求応答トランザクションの一環としてＨＴＴＰ要求メッセージを送信するステップと、
　ＨＴＴＰ要求応答の一環として、第１の時間枠で、ＨＴＴＰ応答の第１のメッセージを受信するステップと、
　前記ＨＴＴＰ応答の追加のメッセージを受信するために前記ＨＴＴＰ要求応答トランザクションをオープン状態で維持するステップと、
　他のＨＴＴＰ要求メッセージを送信することなく、前記ＨＴＴＰ要求応答トランザクションの一環として、前記第１の時間枠とは異なる第２の時間枠で、前記ＨＴＴＰ応答の第２のメッセージを受信するステップと　
　前記２つのエンドポイント間の別々の通信を利用して１つまたは複数の制御メッセージを送信するステップであって、前記１つまたは複数の制御メッセージは、前記２つのエンドポイントが、前記ＨＴＴＰ要求応答トランザクションをオープン状態に維持することを支援するために送信される、制御メッセージを送信するステップと
　を備えることを特徴とする方法。」
　
２．引用例
　引用例の記載については、上記「第２　」の「２．引用例」で述べたとおりである。
　
３．対比・判断
　本願発明は、前記「第２」の「１．本願補正発明」で検討した本願補正発明の「前記２つのエンドポイント間
で確立した通信とは異なる別
の別々
　そうすると、実質的に、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、上記「第２」の「４．相違点についての判断」に記載したとおり、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。　
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願は、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、他の請求項について論及するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。