【事件の表示】
　特願２００８−５３４６３４「異種のサービスプロバイダ間における、インスタントメッセージングの相互運用性」拒絶査定不服審判事件〔平成１９年　４月１９日国際公開、ＷＯ２００７／０４４３７１、平成２１年　３月１９日国内公表、特表２００９−５１２０１６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２００６年１０月３日を国際出願日とする出願（パリ条約による優先権主張外国庁受理２００５年１０月７日、米国、同２００６年９月２７日、米国）であって、平成２４年２月１５日付けで拒絶査定がなされ（発送日：同月２７日）、これに対して同年６月２７日に審判の請求がなされ、同時に手続補正がなされたものである。
　
第２　平成２４年６月２７日付けの手続補正についての補正却下の決定
［補正却下の結論］
　平成２４年６月２７日付けの手続補正（以下、「本件補正」という。）を却下する。
　
［理由］
１．本願補正発明
　本件補正により、特許請求の範囲の請求項１は、以下のとおりに補正された。
「異なるインスタントメッセージングサービスプロバイダネットワークのクライアント間におけるインスタントメッセージング通信を容易にするための装置であって、前記装置は、
　インスタントメッセージングに関する通信を受信するプライマリサービスプロバイダのクライアントが属していないネットワークである外部のインスタントメッセージングサービスプロバイダネットワーク群の一つから送信された前記インスタントメッセージングに関する通信を、前記プライマリサービスプロバイダネットワーク内に含まれるステートレスなゲートウェイサーバで受信するためのインターフェースロジックと、
　受信された通信を、第２のプロトコルから、前記プライマリサービスプロバイダネットワークに固有なプライマリプロトコルへ変換するための変換ロジックと、
　
前記クライアントと、
うちの対応する各
の複数個分
　を含む装置。」（審決注：下線は当審付与。以下同様。）
　
　なお、請求項１末尾付近の「…前記
クライント
クライアント
　
　上記補正は、請求項１に記載した発明を特定するために必要な事項のうち、本件補正前（平成２３年１２月２日付け手続補正書参照）において、「前記複数の外部のインスタントメッセージングサービスプロバイダネットワークの複数のユーザと前記クライアントとの間の通信を容易にする論理的な各終端点を前記クライ（ア）ントのために作成するプレゼンスデータ管理ロジックと」とあったものを、「
前記クライアントと、
うちの対応する各
の複数個分
　そこで、本願補正発明が特許出願の際独立して特許を受けることができるものであるか（平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
　
２．引用例（米国特許出願公開第２００５／０２１３５３７号明細書）
　原査定の拒絶の理由で引用された、米国特許出願公開第２００５／０２１３５３７号明細書（以下「引用例」という。）には、図面と共に、次の事項が記載されている（訳は当審訳。）。
　
（１）　段落【０００２】〜【０００３】前半
「FIELD OF THE INVENTION  
　　　The present invention relates to an interworking gateway. In particular, the present invention relates to a device and method for bridging together an Open Mobile Alliance (OMA) Instant Message and Presence Service (IMPS) infrastructure and a SIP Instant Messaging and Presence Leveraging Extensions (SIMPLE) IMPS based infrastructure. 
BACKGROUND 
　　　Instant Messaging (IM) is one of the easiest and most cost effective ways of communicating interactively over a network such as the Internet. 」
（「発明の分野」
　本発明は、相互接続ゲートウェイに関する。特に、本発明は、
オープン・モバイル・アライアンス（ＯＭＡ）のインスタント・メッセージ及びプレゼンス・サービス（ＩＭＰＳ）インフラストラクチャと、ＳＩＰインスタント・メッセージ及びプレゼンス・レバレッジ拡張（ＳＩＭＰＬＥ）のＩＭＰＳに基づくインフラストラクチャとを、一緒に接続する装置
「背景」
　
インスタント・メッセージ（ＩＭ）
　
（２）　段落【０００８】前半
「One drawback of existing IM systems is that they are proprietary in nature and interoperability between the IM products of one supplier or operator are typically unable to operate with the products of another supplier or operator. 」
（
既存のＩＭシステムの欠点の一つは、それらが本質的に専有的で、一つのサプライヤ又はオペレータのＩＭ製品との間の相互運用性は、概して他のサプライヤ又はオペレータの製品と運用できないものであ
　
（３）　段落【００１０】前半
「SUMMARY OF THE INVENTION  
　　　The present invention address the above and other drawbacks by providing an interworking gateway for interworking at least one OMA IMPS domain and a SIP infrastructure comprising at least one SIMPLE domain.」
（「発明の要約」
　本発明は、少なくとも１つの ＯＭＡのＩＭＰＳドメインと、少なくとも１つのＳＩＭＰＬＥドメインを含むＳＩＰインフラストラクチャとを相互接続するための、相互接続ゲートウェイを提供することによって、
上記及びその他の欠点に対処する
　
（４）　段落【００５６】
「DETAILED DESCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS  
　　　Referring now to FIG. 1, an interworking gateway, generally referred to using the reference numeral 10, in accordance with an illustrative embodiment of the present invention will now be described. The interworking gateway 10 interconnects a first OMA IMPS 1.x infrastructure (or domain) 12 with a SIMPLE infrastructure (or domain) 14. In this regard, Of course, as will be apparent to a person of ordinary skill in the art, in an actual implementation a plurality of interworking gateways 10 would typically be provided between the OMA IMPS 1.x and SIMPLE infrastructures (or domains) 12, 14.   In particular, and as will be seen below, the interworking gateway 10 provides a path and those translation functions necessary to allow participants (clients) in a first IMPS domain such as an OMA IMPS domain to communicate with clients in a second different IMPS domain such as a SIMPLE (IMPS) domain. 」
（「説明的な実施例の詳細な説明」
 図１を次に参照して、一般に参照番号１０を用いて参照される、本発明の説明的な実施例に従う、相互接続ゲートウエイを次に説明する。
相互接続ゲートウェイ１０は
第１のＯＭＡのＩＭＰＳ　１．ｘインフラストラクチャ（又はドメイン）１２を、ＳＩＭＰＬＥインフラストラクチャ（又はドメイン）１４.と相互接続
例えばＯＭＡのＩＭＰＳドメインである、第１のＩＭＰＳドメインの参加者（クライアント）に、例えばＳＩＭＰＬＥの（ＩＭＰＳ）ドメインである、第２の異なるＩＭＰＳドメインのクライアントとの通信を可能にするために必要とされる、経路とそれらの変換機能を提供する
　
（５）　段落【００７３】〜【００７４】
「Transaction Mapping 
　　　Referring now to FIG. 5, in order to provide for the transfer of instant messages and presence between SIMPLE and OMA IMPS domains, the interworking gateway 10 comprises a SIMPLE interface 38 for communications with the SIMPLE domain(s) 22 and an OMA IMPS interface 40 for communication with the OMA IMPS domain(s) 24.  Additionally, the gateway  10 comprises an interworking function 42 which links the SIMPLE and OMA IMPS interfaces 38, 40.  The interworking function 42 comprises a transaction mapping module 44 which maps or converts protocol (or transactions) between the OMA IMPS domain 24 and the SIMPLE domain 22 and vice versa.」
（「トランザクション・マッピング」
　図５を次に参照して、ＳＩＭＰＬＥとＯＭＡのＩＭＰＳドメイン間での、インスタント・メッセージ及びプレゼンスの転送を提供するために、相互接続ゲートウエイ１０は、
ＳＩＭＰＬＥドメイン２２と通信するためのＳＩＭＰＬＥインタフェース３８と
ＯＭＡのＩＭＰＳドメイン２４と通信するためのＯＭＡのＩＭＰＳインタフェース４０とを含んで
さらに、
相互接続機能４２を含み、これは、ＳＩＭＰＬＥとＯＭＡのＩＭＰＳのインタフェース３８、４０をリンク
相互接続機能４２は、トランザクション・マッピング・モジュール４４を含み、これは、ＯＭＡのＩＭＰＳドメイン２４とＳＩＭＰＬＥドメイン２２間でプロトコル（又はトランザクション）をマッピング又は変換
　
（６）　段落【０１０２】〜【０１０４】
「Invitations 
　　　The interworking gateway 10 complies to the requirements for a SIP User Agent Server and Client as defined in as described in SIP--Session Initiation Protocol--RFC-3261. It also complies to the Static Conformance Requirements for the Invitation related transactions of the OMA IMPS 1.2 SSP Common Service Element as defined in OMA IMPS 1.2--Server to Server Protocol Static Conformance Requirement v1.2--WV-035. 
　　　Transactions used in the OMA IMPS domain and SIMPLE domain for inviting remote entities to a session contain very similar semantics.  A primary difference is that invitations in the in OMA IMPS domain are stateless, and as a result there is no need to explicitly tear down the session.  This introduces complications for the interworking gateway 10 as without using a group there is no way for the interworking gateway 10 to be aware of when an OMA IMPS client has decided to stop a session-mode conversation that was setup.  The interworking gateway 10 therefore maintains state and a keep alive timer for the session-mode conversation.  If no messages have been received from the OMA IMPS side before the keep alive timer expires, the interworking gateway 10 closes the SIMPLE based session by sending a BYE to the associated SIP proxy.」
（「招待（Invitations）」
　相互接続ゲートウェイ１０は、ＳＩＰ−−セッション開始
プロトコル
プロトコル
　
遠隔エンティティをセッションに招待するために、ＯＭＡのＩＭＰＳドメインとＳＩＭＰＬＥドメインで利用されるトランザクションは、極めて類似したセマンティクスを含
主要な相違点は、ＯＭＡのＩＭＰＳドメインの招待がステートレスであって、その結果として、セッションを明示的に終了することが必要とされないことであ
ＯＭＡのＩＭＰＳクライアントがセットアップされたセッション・モードの会話を停止すると決めたことを、相互接続ゲートウェイ１０が知るための方法が存在しないから
したがって、相互接続ゲートウェイ１０は、ステートを維持し、そしてセッション・モードの会話の「キープ・アライブ」タイマを維持
もしも、キープ・アライブ・タイマが満了する前にＯＭＡのＩＭＰＳ側からのメッセージが受信されなかった場合、相互接続ゲートウェイ１０は、関連するＳＩＰプロキシにＢＹＥメッセージを送信することで、ＳＩＭＰＬＥに基づくセッションを閉じる
　
（７）　段落【０１６５】〜【０１６９】
「Referring back to FIG. 5, in its basic form, the interworking gateway 10 enables a single OMA IMPS domain 24 to interwork with a single SIMPLE domain 22.  However, referring to  FIG. 14, the scope of the interworking gateway 10 can be expanded to enable multiple OMA IMPS domains as in 241,  242, . . . ,  24N to interwork with multiple SIMPLE domains as in 221,  222, . . . ,  22M. Additionally, the interworking gateway 10 can also be used to interconnect the multiple OMA IMPS domains as in 241,  242, . . . ,  24N. In this regard, each OMA IMPS domain as in 241,  242, . . . ,  24N, is interconnected with the interworking gateway 10 via an OMA IMPS server as in 36 and at least one SSP connection as in 46. In turn, the OMA IMPS servers as in 36 service a number of clients as in 34. 
　　　 The manner of operation will be described using an example.  A request originates, for example, from a SIP client 26 in a first SIMPLE Domain 221.  If the destination of the request is a SIP client (not shown) in another SIMPLE domain, for example one of SIMPLE domain 222 to SIMPLE Domain 22M, the request is routed directly to the destination SIMPLE domain by the SIP Infrastructure 48.  In this regard, routing across SIMPLE domains is 
a service provided by
　　　At the interworking gateway 10, the address of the destination OMA IMPS client 34 identified in the incoming SIP request is mapped into its OMA IMPS UserID by the interworking gateway 10 (see the discussion hereinabove under Routing and Addressing). The OMA IMPS UserID identifies the OMA IMPS domain 241,  242, . . . ,  24N serving the destination OMA IMPS client 34.  The interworking gateway 10 retrieves this serving OMA IMPS domain from entries in the routing table (as discussed hereinabove) as the OMA IMPS domain which corresponds to the OMA IMPS UserID.  The interworking gateway 10 performs any transaction mapping (also as described hereinabove) required for the request.  Following these mappings (or conversions), the interworking gateway 10 then relays the mapped request to the serving OMA IMPS domain 241,  242, . . . ,  24N by transmitting the request via an SSP connection associated with that particular OMA IMPS domain.
　　　In the case of a request originating from, for example, an OMA IMPS client 34 in OMA IMPS domain 242 and destined for another OMA IMPS client in a different OMA IMPS domain, the request is first relayed to the interworking gateway 10 via an SSP connection as in 46.  The interworking gateway 10 identifies the serving OMA IMPS domain of the OMA IMPS client identified by the destination OMA IMPS UserID contained within the request.  As the serving OMA IMPS domain of the OMA IMPS client identified by the destination OMA IMPS UserID is another OMA IMPS domain, the interworking gateway 10 relays the request to the serving OMA IMPS domain over the SSP connection as in 46 associated with the serving OMA IMPS domain. It will be apparent now to a person of ordinary skill in the art that in such a case the interworking gateway 10 carries out no protocol conversion (as the domains of the originator and the destination are both OMA IMPS domains).  On the other hand, for requests originating at an OMA IMPS client 34 within an OMA IMPS domain 36 and destined for a SIP client 26 in a SIMPLE domain as in 22, the request are first relayed to the interworking gateway 10 via an SSP connection as in 46. As the domain servicing the destination SIP client 26 is a SIMPLE domain as in 22, the interworking gateway 10 performs transaction mapping on the request to convert it from an OMA IMPS transaction to SIMPLE transaction (as discussed hereinabove under Transaction Mapping).  The interworking gateway 10 then relays the request via the SIMPLE interface (reference 38 in  FIG. 5) to the SIP Infrastructure 48 following which the SIP Infrastructure 48 routes the message to the specific SIMPLE domain as in 221,  222, . . . ,  22M, serving the destination SIMPLE client 26. 
　　　Note that the SSP protocol currently requires a connection to be established between any two interconnected OMA IMPS domains.  As a result, interconnecting together N OMA IMPS domains with direct SSP connections require a total number of N*(N-1)/2 connections.  As the number of OMA IMPS domains increases, the total number of connections thus grows exponentially (as a square of the number of OMA IMPS domains).  One advantage of interposing the interworking gateway 10, therefore, is that it allows each OMA IMPS domain to be interconnected with a plurality of other OMA IMPS domains with provision of a single SSP connection between each of the OMA IMPS domains and the interworking gateway 10, which in turn reduces the number of SSP interconnections required to provide total interconnectivity.  As a result, as the number of interconnected OMA IMPS domains grows large, the related management burden is significantly reduced vis-a-vis an implementation where direct SSP connections between OMA IMPS domains is used.」
（図５に戻って参照すると、
相互接続ゲートウェイ１０は、基本形としては、単一のＯＭＡのＩＭＰＳドメイン２４が、単一のＳＩＭＰＬＥドメイン２２と相互接続することを可能にする
多数のＯＭＡのＩＭＰＳドメイン、例えば２４
１
，２４
２
，．．．，２４
Ｎ
と、多数のＳＩＭＰＬＥドメイン、例えば２２
１
、２２
２
，．．．，２２
Ｎ
とを相互接続するように、相互接続ゲートウェイの範囲を拡張でき
　オペレーション方法を、例を用いて記述する。 リクエストが、例えば、第１のＳＩＭＰＬＥドメイン２２１のクライアント２６から発信される。 リクエストの宛先が、もし他のＳＩＭＰＬＥドメイン、例えばＳＩＭＰＬＥドメイン２２２からＳＩＭＰＬＥドメイン２２Ｍの一つ、におけるＳＩＰクライアント（非図示）であれば、リクエストは、ＳＩＰインフラストラクチャ４８によって、直接宛先ＳＩＭＰＬＥへと送られる。これに関して、ＳＩＭＰＬＥドメインを横切る送信は、ＳＩＰインフラストラクチャ４８が
提供（provide）するサービス
　相互接続ゲートウェイ１０において、入来ＳＩＰリクエストで識別された、宛先ＯＭＡのＩＭＰＳクライアント３４のアドレスは、相互接続ゲートウェイ１０によって、ＯＭＡのＩＭＰＳユーザＩＤにマッピングされる（上記記載の「ルーティングとアドレッシング」の議論を参照。）。ＯＭＡのＩＭＰＳユーザＩＤは、宛先ＯＭＡのＩＭＰＳクライアント３４にサービスを供する、ＯＭＡのＩＭＰＳドメイン２４１，２４２，．．．，２４Ｎを識別する。相互接続ゲートウェイ１０は、このサービスを供するＯＭＡのＩＭＰＳドメインを、ＯＭＡのＩＭＰＳユーザＩＤに対応するＯＭＡのＩＭＰＳドメインとして、（上記記載の議論のように）ルーティングテーブルのエントリから検索する。相互接続ゲートウェイ１０が、リクエストに対して必要とされる、（同じく上記記載の議論のような）どのようなトランザクションのマッピングをも行なう。これらのマッピング（あるいは変換）の後に、それから、相互接続ゲートウェイ１０は、その特定のＯＭＡのＩＭＰＳドメインと関連付けられたＳＳＰ接続を介してリクエストを転送することによって、サービスを供するＯＭＡのＩＭＰＳドメイン２４１，２４２，．．．，２４Ｎに対して、マッピングがなされたリクエストを中継する。
　リクエストが、例えばＯＭＡのＩＭＰＳドメイン２４２のＯＭＡのＩＭＰＳクライアント３４から発信されて、そして、異なったＯＭＡのＩＭＰＳドメインの異なったＯＭＡのＩＭＰＳクライアントに向けられている場合、リクエストは、４６のようなＳＳＰコネクションを介して、まず相互接続ゲートウェイ１０へと中継される。相互接続ゲートウェイ１０は、リクエストに含まれる宛先ＯＭＡのＩＭＰＳユーザＩＤによって識別されるＯＭＡのＩＭＰＳクライアントにサービスを供する、ＯＭＡのＩＭＰＳドメインを識別する。宛先ＯＭＡのＩＭＰＳユーザＩＤで識別される、ＯＭＡのＩＭＰＳクライアントに、サービスを供するＯＭＡのＩＭＰＳドメインは、別のＯＭＡのＩＭＰＳドメインであるから、相互接続ゲートウェイ１０は、サービスを供するＯＭＡのＩＭＰＳドメインに関連する、４６のようなＳＳＰコネクション上で、サービスを供するＯＭＡのＩＭＰＳドメインに、リクエストを中継する。このような場合、（発信者と宛先のドメインはどちらもＯＭＡのＩＭＰＳドメインであるから）、相互接続ゲートウェイ１０は、プロトコル変換をしないことは、当業者にとり明らかであろう。他方、ＯＭＡのＩＭＰＳドメイン３６内のＯＭＡのＩＭＰＳクライアント３４から発生して、２２のようなＳＩＭＰＬＥドメインのＳＩＰクライアント２６に宛てられているリクエストに対しては、リクエストは最初に４６のようなＳＳＰコネクションを介して、相互接続ゲートウェイ１０に中継される。宛先ＳＩＰクライアント２６にサービスを供するドメインは、２２のようなＳＩＭＰＬＥドメインであるから、相互接続ゲートウェイ１０は、リクエストについて、トランザクション・マッピングを行って、ＯＭＡのＩＭＰＳトランザクションを、ＳＩＭＰＬＥトランザクションに変換する（上記記載の「トランザクション・マッピング」の議論を参照。）。相互接続ゲートウェイ１０は、それから、ＳＩＭＰＬＥインタフェース（図５における参照番号３８）を経由して、リクエストをＳＩＰインフラストラクチャ４８に転送し、それに引き続いて、ＳＩＰインフラストラクチャ４８は、２２１、２２２，．．．，２２Ｎのような、宛先ＳＩＭＰＬＥクライアント２６にサービスを供する特定のＳＩＭＰＬＥドメインにメッセージを送信する。
　現時点では、ＳＳＰプロトコルでは、任意の２つの相互接続されたＯＭＡのＩＭＰＳドメイン間で、コネクションの確立が必要なことに注意されたい。その結果として、Ｎ個のＯＭＡのＩＭＰＳドメイン間を、ＳＳＰコネクションで直接的に一緒に接続するには、合計でＮ×（Ｎ−１）／２個のコネクションが必要になる。ＯＭＡのＩＭＰＳドメインの数が増加するにつれて、コネクションの総数は、このように（ＯＭＡのＩＭＰＳドメインの数の自乗として）急激に増大する。相互接続ゲートウェイ１０を介挿することの利点の一つは、それゆえ、それぞれの ＯＭＡのＩＭＰＳドメインと相互接続ゲートウェイ１０間に単一のＳＳＰコネクションを提供することで、各々のＯＭＡのＩＭＰＳドメインを、他の複数のＯＭＡのＩＭＰＳドメインと相互接続することを可能にして、これによって、全体の相互接続に必要とされるＳＳＰ相互接続の数を削減することにある。その結果として、相互接続されるＯＭＡのＩＭＰＳドメインの数が増大するにつれて、ＯＭＡのＩＭＰＳドメイン間のダイレクトなＳＳＰコネクションを利用する実装と比較して、関連する管理負担が、際立って削減される。）
　
　これらの記載から、引用例には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　
「オープン・モバイル・アライアンス（ＯＭＡ）のインスタント・メッセージ及びプレゼンス・サービス（ＩＭＰＳ）インフラストラクチャと、ＳＩＰインスタント・メッセージ及びプレゼンス・レバレッジ拡張（ＳＩＭＰＬＥ）のＩＭＰＳに基づくインフラストラクチャとを、一緒に接続する装置であって、
　既存のインスタント・メッセージ（ＩＭ）システムの欠点の一つは、それらが本質的に専有的で、一つのサプライヤ又はオペレータのＩＭ製品との間の相互運用性は、概して他のサプライヤ又はオペレータの製品と運用できないものであり、上記及びその他の欠点に対処するために、
　相互接続ゲートウェイ１０は、
　第１のＯＭＡのＩＭＰＳ　１．ｘインフラストラクチャ（又はドメイン）１２を、ＳＩＭＰＬＥインフラストラクチャ（又はドメイン）１４.と相互接続し、例えばＯＭＡのＩＭＰＳドメインである、第１のＩＭＰＳドメインの参加者（クライアント）に、例えばＳＩＭＰＬＥの（ＩＭＰＳ）ドメインである、第２の異なるＩＭＰＳドメインのクライアントとの通信を可能にするために必要とされる、経路とそれらの変換機能を提供するものであり、　
　ＳＩＭＰＬＥドメイン２２と通信するためのＳＩＭＰＬＥインタフェース３８と、
　ＯＭＡのＩＭＰＳドメイン２４と通信するためのＯＭＡのＩＭＰＳインタフェース４０とを含んでおり、
　さらに、相互接続機能４２を含み、これは、ＳＩＭＰＬＥとＯＭＡのＩＭＰＳのインタフェース３８、４０をリンクし、
　相互接続機能４２は、トランザクション・マッピング・モジュール４４を含み、これは、ＯＭＡのＩＭＰＳドメイン２４とＳＩＭＰＬＥドメイン２２間でプロトコル（又はトランザクション）をマッピング又は変換し、
　遠隔エンティティをセッションに招待するために、ＯＭＡのＩＭＰＳドメインとＳＩＭＰＬＥドメインで利用されるトランザクションは、極めて類似したセマンティクスを含み、主要な相違点は、ＯＭＡのＩＭＰＳドメインの招待がステートレスであって、その結果として、セッションを明示的に終了することが必要とされないことであり、ＯＭＡのＩＭＰＳクライアントがセットアップされたセッション・モードの会話を停止すると決めたことを、相互接続ゲートウェイ１０が知るための方法が存在しないから、したがって、相互接続ゲートウェイ１０は、ステートを維持し、そしてセッション・モードの会話の「キープ・アライブ」タイマを維持し、もしも、キープ・アライブ・タイマが満了する前にＯＭＡのＩＭＰＳ側からのメッセージが受信されなかった場合、相互接続ゲートウェイ１０は、関連するＳＩＰプロキシにＢＹＥメッセージを送信することで、ＳＩＭＰＬＥに基づくセッションを閉じる、相互接続ゲートウェイ１０であって、
　相互接続ゲートウェイ１０は、基本形としては、単一のＯＭＡのＩＭＰＳドメイン２４が、単一のＳＩＭＰＬＥドメイン２２と相互接続することを可能にするが、多数のＯＭＡのＩＭＰＳドメイン、例えば２４１，２４２，．．．，２４Ｎと、多数のＳＩＭＰＬＥドメイン、例えば２２１、２２２，．．．，２２Ｎとを相互接続するように、相互接続ゲートウェイの範囲を拡張できる、相互接続ゲートウェイ１０。」
　
　
３．対比
　本願補正発明と引用発明とを対比する。
　
（１）　引用発明における「第１のＯＭＡのＩＭＰＳ　１．ｘインフラストラクチャ（又はドメイン）１２」及び「ＳＩＭＰＬＥインフラストラクチャ（又はドメイン）１４」は、収容したクライアントに対して、「ＩＭＰ
Ｓ
インスタント・メッセージ
サービス
　引用発明の「相互接続ゲートウェイ１０」は、既存のＩＭシステムの欠点を解消し、「第１のＯＭＡのＩＭＰＳ　１．ｘインフラストラクチャ（又はドメイン）１２を、ＳＩＭＰＬＥインフラストラクチャ（又はドメイン）１４.と相互接続し、例えばＯＭＡの
ＩＭＰＳ
クライアント
ＩＭＰＳ
クライアント
通信を可能にする
　
（２）　引用発明の「例えばＯＭＡのＩＭＰＳドメインである、
第１の
クライアント
　引用発明において特に「多数のＯＭＡのＩＭＰＳドメイン、例えば２４１，２４２，．．．，２４Ｎと、多数のＳＩＭＰＬＥドメイン、例えば２２１、２２２，．．．，２２Ｎとを相互接続するように、相互接続ゲートウェイの範囲を拡張」した場合に、「多数のＳＩＭＰＬＥドメイン、例えば２２１、２２２，．．．，２２Ｎ」の一つ（例えば２２１）は、本願補正発明の「インスタントメッセージングに関する通信を受信するプライマリサービスプロバイダのクライアントが属していないネットワークである外部のインスタントメッセージングサービスプロバイダネットワーク群の一つ」に相当するといえる。
　よって、引用発明の「相互接続ゲートウェイ１０」において、上記「相互接続ゲートウェイの範囲の拡張」をした場合における、「ＳＩＭＰＬＥドメイン２２と通信するためのＳＩＭＰＬＥインタフェース３８」は、本願補正発明の「インスタントメッセージングに関する通信を受信するプライマリサービスプロバイダのクライアントが属していないネットワークである外部のインスタントメッセージングサービスプロバイダネットワーク群の一つから送信された前記インスタントメッセージングに関する通信を、
前記プライマリサービスプロバイダネットワーク内に含まれるステートレスなゲートウェイサーバで
　
（３）　引用発明の「相互接続ゲートウェイ１０」における「トランザクション・マッピング・モジュール４４」は、「ＯＭＡのＩＭＰＳドメイン２４とＳＩＭＰＬＥドメイン２２間で
プロトコル
変換
前記プライマリサービスプロバイダネットワークに固有な
　
　したがって、両者の一致点、相違点は以下のとおりである。
　
［一致点］
「異なるインスタントメッセージングサービスプロバイダネットワークのクライアント間におけるインスタントメッセージング通信を容易にするための装置であって、前記装置は、
　インスタントメッセージングに関する通信を受信するプライマリサービスプロバイダのクライアントが属していないネットワークである外部のインスタントメッセージングサービスプロバイダネットワーク群の一つから送信された前記インスタントメッセージングに関する通信を、受信するためのインターフェースロジックと、
　受信された通信を、第２のプロトコルから、プライマリプロトコルへ変換するための変換ロジックと、
　を含む装置。」
である点。
　
［相違点１］
　本願補正発明の「インターフェースロジック」は、「インスタントメッセージングに関する通信を受信するプライマリサービスプロバイダのクライアントが属していないネットワークである外部のインスタントメッセージングサービスプロバイダネットワーク群の一つから送信された前記インスタントメッセージングに関する通信を、
前記プライマリサービスプロバイダネットワーク内に含まれるステートレスなゲートウェイサーバで
　
［相違点２］
　本願補正発明の「変換ロジック」は、「受信された通信を、第２のプロトコルから、
前記プライマリサービスプロバイダネットワークに固有な
例えば
例えば
　
［相違点３］
　本願補正発明の「装置」は、「前記クライアントと、前記複数の外部のインスタントメッセージングサービスプロバイダネットワークのうちの対応する各ユーザとの間の通信を容易にする論理的な各終端点の複数個分を前記クライアントのために作成するプレゼンスデータ管理ロジック」を備えるのに対して、引用発明の「相互接続ゲートウェイ１０」は、論理的な終端点を作成するプレゼンスデータ管理ロジックについて記載されていない点。
　
　
４．相違点についての判断
（１）　［相違点１］について
　一般に、複数のネットワークをつなぐ際、ゲートウエイ等の網間接続設備を、接続されるネットワーク内に設けるか否かなど、事業者間の責任分界点をどのように設定するかは、設備の運用及び保守の容易性等を考慮して、当業者が適宜選択すべき設計的事項である。また、ゲートウエイ等の網間接続設備を、少なくとも一方のネットワーク内に含ませることは、普通に行われている（＜周知文献１＞原査定の拒絶の理由で引用された引用文献２である、菅野博靖、岩山登、「インスタントメッセージ技術の最新動向とその応用−ＣＰＩＭによる相互接続性へのアプローチ」、情報処理学会研究報告、Ｖｏｌ．２００２、Ｎｏ．５８、社団法人情報処理学会、２００２年６月２６日、ｐ．４７−５４、特に図５のＧＷ（ゲートウエイ）を参照、＜周知文献２＞原査定の拒絶の理由で引用された引用文献３である、特開２００３−３２３１０号公報、特に図１，図８のゲートウエイ１３等を参照。）。
　一般に、プロトコル処理を行う際、サーバ等の処理装置において、トランザクションや呼の進行等の各種状態を保存するか（ステートフル）、保存しないか（ステートレス）は、使用されるプロトコルの種別や、処理量等を考慮して、当業者が当業者が適宜選択すべき設計的事項である。また、プロトコル処理を行うサーバ等の処理装置として、ステートレス、ステートフルいずれの態様も、普通に用いられている（＜周知文献３＞Ｍｉｃｒｏｓｏｆｔ　Ｃｏｒｐｏｒａｔｉｏｎ著、「Ｍｉｃｒｏｓｏｆｔ　Ａｐｐｌｉｃａｔｉｏｎ　Ｃｅｎｔｅｒ　２０００　リソースキット」、日経ＢＰソフトプレス、２００１年１２月１０日、初版、ｐ．１０−１４、１２５−１２８、４８７−４９７。特に、１１頁１７行−１２頁１行「通常、フロントエンドシステムはセッション間でクライアント情報を保持しないため、
ステートレス
フロントエンドシステムでクライアント状態を維持することは望ましくありません
１つの方法は、分割したバックエンドサーバーにクライアント状態を保存することです
ステートフル
ステートレス
要求の悪意ある洪水
これを避けるため、ステートレスＵＡを使用し
「ステートレス」な方法で動作する
ステートレスであり得る
　よって、引用発明において、ネットワーク間を接続するためのゲートウエイとして、少なくとも一方のネットワーク内に、ステートレスなものを設けることによって、「インスタントメッセージングに関する通信を受信するプライマリサービスプロバイダのクライアントが属していないネットワークである外部のインスタントメッセージングサービスプロバイダネットワーク群の一つから送信された前記インスタントメッセージングに関する通信を、
前記プライマリサービスプロバイダネットワーク内に含まれるステートレスなゲートウェイサーバで
　
（２）　［相違点２］について
　一般に、インスタント・メッセージ用のプロトコルとして、事業者（サービスプロバイダ）に固有のものは、普通に用いられている（＜周知文献７＞国際公開第２００４／２７５６２号、２頁２〜４行「For example, while vendors such as Microsoft, Yahoo, and America On-Line (AOL) provide relatively similar instant messaging (IM) services, the underlying protocols employed by the various vendors differ vastly.」（訳：例えば、マイクロソフト、 ヤフーとアメリカオンライン（ＡＯＬ）のようなベンダが比較的類似のインスタント・メッセージ（ＩＭ）サービスを提供するが、
種々のベンダによって使われているプロトコル
非常に異なる
固有の（native）プロトコルで
各々のインターネット接続サービスプロバイダ（ＩＳＰ）が
技術のブランドを開発した
各々のＩＳＰが
異なった方法を選択した
　よって、引用発明の「
例えば
前記プライマリサービスプロバイダネットワークに固有な
　
（３）　［相違点３］について
　一般に、通信とは、相対する終端点間で情報を送受信することにほかならず、通信に論理的な終端点をいくつ用いるかは、通信の相手先の数や、各相手先との通信に用いるプロトコルの種類、終端点を複数の通信で共用するか専用とするか等を考慮して、当業者が適宜選択すべき設計的事項である。
　また、複数の相手先の端末との間の通信に、相手先毎に複数の接続を用いることは、周知技術である（上記＜周知文献２＞原査定の拒絶の理由で引用された引用文献３である、特開２００３−３２３１０号公報、特に図１，図２を参照。上記＜周知文献７＞国際公開第２００４／２７５６２号、図６の仮想化サーバ１２４とＡＯＬサーバ、ＹＡＨＯＯサーバ、ＭＳＮサーバ、ベルサウスサーバ間の接続、及び、３頁１１−２４行「Briefly described, in architecture, one embodiment of the system comprises a server, and a plurality of transport protocol objects (TPOs) instantiated at the server. In one embodiment, each of the plurality of TPOs is adapted to provide a translation between a first IM protocol and a different IM protocol. The present disclosure also provides methods for providing interoperability between various Internet protocols. In this regard, one embodiment of the method comprises the steps of instantiating a plurality of transport protocol objects (TPOs) at a server, establishing a plurality of connections between the plurality of TPOs and a plurality of servers, and providing a communication pathway between an IM client and the plurality of servers through the plurality of instantiated TPOs. In one embodiment, each of the plurality of TPOs is adapted to provide a translation between a first IM protocol and a different IM protocol. The IM client transmits and receives IM messages using the first IM protocol, while each of the plurality of servers transmits and receives IM messages using one of the different IM protocols.」（訳：簡潔に記述すれば、アーキテクチャにおいて、システムの１つの実施例は、サーバと、サーバでインスタンスが生成された複数の転送プロトコルオブジェクト（ＴＰＯ）を含む。１つの実施例では、複数のＴＰＯのそれぞれは、第１のＩＭプロトコルと、異なるプロトコル間の変換を提供するために適合される。本開示はまた、種々のインターネットのプロトコル間に互換性を供給するための方法を提供する。この点に関して、１つの実施例の方法は、サーバにおいて複数の転送プロトコルオブジェクト（ＴＰＯ）のインスタンスを生成し、複数のＴＰＯと複数のサーバ間に複数のコネクションを設立するステップと、一つのＩＭクライアントと複数のサーバ間に、複数のインスタンスを生成したＴＰＯを介して、通信の経路を提供するステップを含む。１つの実施例で、複数のＴＰＯのそれぞれは、第１のＩＭプロトコルと異なるＩＭプロトコル間の変換を提供するように適合される。ＩＭクライアントは、第１のＩＭプロトコルを使って、ＩＭメッセージを送信して受信し、他方、複数のサーバのそれぞれは、異なるＩＭプロトコルの１つを使ってＩＭメッセージを送信して受信する。）、１６頁１４〜１７行「FIGS. 5 and 6 show another embodiment of a system, wherein the TPOs 221, 223, 225, 227 are located at the abstraction server 124. By having the TPOs 221 , 223, 225 at the abstraction server 124, rather than at a client location, a single TPO may be used by multiple IM users, thereby reducing the number of instantiated TPOs.」（訳：図５、６に、システムの他の実施例を示す。、ここでＴＰＯ２２１、２２３、２２５、２２７はサーバ１２４に位置する。サーバ１２４にＴＰＯ２２１、２２３、２２５を備えることで、クライアントの位置よりむしろ、単一のＴＰＯを複数のユーザが使用することができ、それによって、インスタンスを生成するＴＰＯの数を減らせるかもしれない。）、上記＜周知文献８＞ 国際公開第２０���３／９４０１１号、図２を参照。）。
　よって、引用発明において特に「多数のＯＭＡのＩＭＰＳドメイン、例えば２４１，２４２，．．．，２４Ｎと、多数のＳＩＭＰＬＥドメイン、例えば２２１、２２２，．．．，２２Ｎとを相互接続するように、相互接続ゲートウェイの範囲を拡張」した場合に、複数の相手先の端末毎に設けた複数の接続を用いると共に、通信を行う個々のクライアント毎に、さらに、各クライアントの個々の相手先のユーザ毎に、論理的な終端点をそれぞれ別個に設けることによって、「前記クライアントと、前記複数の外部のインスタントメッセージングサービスプロバイダネットワークのうちの対応する各ユーザとの間の通信を容易にする論理的な各終端点の複数個分を前記クライアントのために作成するプレゼンスデータ管理ロジック」を備える、上記［相違点３］に係る構成とすることは、引用発明に接した当業者が適宜に採用すべき設計的事項である。
　
　そして、本願補正発明のように構成したことによる効果も引用発明及び周知技術から予測できる程度のものである。
　
　
５．むすび
　以上のとおり、本願補正発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
１．本願発明
　平成２４年６月２７日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下「本願発明」という。）は、平成２３年１２月２日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。
「異なるインスタントメッセージングサービスプロバイダネットワークのクライアント間におけるインスタントメッセージング通信を容易にするための装置であって、前記装置は、
　インスタントメッセージングに関する通信を受信するプライマリサービスプロバイダのクライアントが属していないネットワークである外部のインスタントメッセージングサービスプロバイダネットワーク群の一つから送信された前記インスタントメッセージングに関する通信を、前記プライマリサービスプロバイダネットワーク内に含まれるステートレスなゲートウェイサーバで受信するためのインターフェースロジックと、
　受信された通信を、第２のプロトコルから、前記プライマリサービスプロバイダネットワークに固有なプライマリプロトコルへ変換するための変換ロジックと、
　前記複数の外部のインスタントメッセージングサービスプロバイダネットワークの複数のユーザと前記クライアントとの間の通信を容易にする論理的な各終端点を前記クライアントのために作成するプレゼンスデータ管理ロジックと、
　を含む装置。」
　
　なお、請求項１末尾付近の「…前記
クライント
クライアント
　
２．引用例
　引用例の記載については、上記「第２　」の「２．引用例」で述べたとおりである。
　
３．対比・判断
　本願発明は、前記「第２」の「１．本願補正発明」で検討した本願補正発明において、「前記複数の外部のインスタントメッセージングサービスプロバイダネットワークの複数のユーザと前記クライアントとの間の通信を容易にする論理的な各終端点を前記クライ（ア）ントのために作成するプレゼンスデータ管理ロジックと」とあったものを、「
前記クライアントと、
うちの対応する各
の複数個分
　そうすると、実質的に、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、上記「第２」の「４．相違点についての判断」に記載したとおり、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。　
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願は、特許法第２９条第２項の規定により特許を受けることができない。したがって、本願は拒絶すべきものである。
　よって、結論のとおり審決する。