【事件の表示】
　特願２０１４−１８０３０６「アプリケーションインターフェイスを将来のアプリケーション用に拡張するための方法」拒絶査定不服審判事件〔平成２７年５月１１日出願公開，特開２０１５−９１１２５，請求項の数（８）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１　本願は，平成２６年９月４日の出願（優先権主張外国庁受理　２０１３年１１月５日　米国，２０１４年８月３日　米国）であって，平成２７年８月２７日付けで拒絶理由が通知され，同年１１月２５日付けで手続補正がされ，平成２８年３月１０日付けで拒絶査定（以下，「原査定」という。）がされ，これに対し，同年６月８日付けで拒絶査定不服審判が請求されると同時に手続補正がされ，前置審査により同年８月２４日付けで最後の拒絶理由が通知されたものである。
第２　原査定の概要
　原査定（平成２８年３月１０日付け拒絶査定）の概要は，以下のとおりである。
１．本願請求項１，５，６に係る発明は，引用文献１に記載された発明であるから，特許法第２９条第１項第３号に該当し，特許を受けることができない。
２．本願請求項１，２，３，５，６，８，９，１１，１２，１４，１５，１７，１８に係る発明は，引用文献１に基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
＜引用文献等一覧＞
１.米国特許出願公開第２０１２／０２２１７２５号明細書
第３　本願発明
　本願請求項１−８に係る発明（以下，それぞれ「本願発明１」−「本願発明８」という。）は，平成２８年６月８日付けの手続補正で補正された特許請求の範囲の請求項１−８に記載された事項により特定される発明であり，以下のとおりの発明である。
「【請求項１】
　異なるユーザ端末間で第１のアプリケーションを共有しているときに，セッション・イニシエーション・プロトコル（ＳＩＰ）メッセージを，前記異なるユーザ端末上で実行される第２のアプリケーションと関連付ける方法であって，
　第１のユーザ端末によって，第１のアプリケーションに使用されたＳＩＰセッションを第２のアプリケーションに関連付けるように前記ＳＩＰセッションにタグ付けするタグ付けステップと，
　第２のユーザ端末によって，前記タグに従って，前記ＳＩＰセッションのためのＳＩＰメッセージを第２のアプリケーションに関連付ける関連付けステップと，
　ユーザ端末間で同じＳＩＰ接続を共有する複数のアプリケーションがあるとき，第１のユーザ端末によって，複数のアプリケーション間の通信を管理するコンジットマネージャを活用して，ＳＩＰセッションと第２アプリケーションとをマッチングする，活用ステップと，
　レガシー・リッチ・通信サービス（ＲＣＳ）アプリケーションを修正する修正ステップであり，第２のユーザ端末によって，前記ＳＩＰメッセージが前記レガシーＲＣＳアプリケーションを意図するか否かを判定するために各ＳＩＰセッションをチェックするＳＩＰセッションマネージャを第２のユーザ端末に追加し，そして，前記ＳＩＰセッションマネージャが，前記レガシーＲＣＳアプリケーションを意図する前記ＳＩＰメッセージを当該レガシーＲＣＳアプリケーションにルーティングし，且つすべての残りのＳＩＰメッセージを前記コンジットマネージャにルーティングすることにより，前記レガシーＲＣＳアプリケーションを修正する修正ステップと，を含む，
　方法。
　　【請求項２】
　請求項１に記載の方法であって，第１のユーザ端末によって，前記ＳＩＰのヘッダ内の既存の要素を修正することにより，前記ＳＩＰセッションを第２のアプリケーションに関連付けるように前記ＳＩＰセッションにタグ付けするタグ付けステップをさらに含む，
　方法。
　　【請求項３】
　請求項１に記載の方法であって，第１のユーザ端末によって，前記ＳＩＰのヘッダに第１のアプリケーションで用いた要素とは異なる要素を追加することにより，前記ＳＩＰセッションを第２のアプリケーションに関連付けるように前記ＳＩＰセッションにタグ付けするタグ付けステップをさらに含む，
　方法。
　　【請求項４】
　請求項１に記載の方法であって，第１のユーザ端末により，前記ＳＩＰによってネゴーシエイトされるセッション記述プロトコル（ＳＤＰ）パラメータに第１のアプリケーションで用いた要素とは異なる要素を追加することにより，前記ＳＩＰセッションを第２のアプリケーションに関連付けるように前記ＳＩＰセッションにタグ付けするタグ付けステップをさらに含む，
　方法。
　　【請求項５】
　請求項１に記載の方法であって，ＳＩＰセッションの前記ＳＤＰパラメータをネゴーシエイトするときに，第１のユーザ端末によって，セッション記述プロトコル（ＳＤＰ）パラメータの既存の要素を修正することにより，前記ＳＩＰセッションを第２のアプリケーションに関連付けるように前記ＳＩＰセッションにタグ付けするタグ付けステップをさらに含む，
　方法。
　　【請求項６】
　請求項５に記載の方法であって，前記ＳＩＰによってネゴーシエイトされる前記ＳＤＰパラメータの前記既存の要素を修正する修正ステップは，前記ＳＩＰセッションの前記ＳＤＰパラメータをネゴーシエイトするときに，第１のユーザ端末によって，第２のアプリケーションをセッション名として特定する特定ステップを含む，
　方法。
　　【請求項７】
　請求項１に記載の方法であって，事前に定義されたリッチ通信サービス（ＲＣＳ）データトランザクションの１つではない新しいデータまたはメディアタイプを追加する追加ステップをさらに含み，新しいコンジットを開始するとき，または，前記新しいメディアデータタイプを既存のコンジットに追加するときに，第１のユーザ端末により，セッション記述プロトコル（ＳＤＰ）パラメータにおいて前記新しいデータまたはメディアタイプを記述する追加のパラメータを供給することにより，前記新しいデータまたはメディアタイプを追加する，
　方法。
　　【請求項８】
　請求項１に記載の方法であって，不要なリッチ通信サービス（ＲＣＳ）アプリケーションからユーザ端末を守るステップであり，ＲＣＳサービスにアクセスするための有効な許可を各アプリケーションが持つことにより，ユーザ端末を守るステップをさらに備える，
　方法。」
　請求項５の「前記ＳＤＰパラメータ」について，請求項１には「ＳＤＰパラメータ」が記載されていないが，請求項５の「前記ＳＤＰパラメータ」の後に「セッション記述プロトコル（ＳＤＰ）パラメータ」との記載があり，当初明細書の記載（【０００５】等）との対応関係からみても，「前記」が後述の「セッション記述プロトコル（ＳＤＰ）パラメータ」を指すことは明らかである
　請求項５を引用する請求項６についても同様である。
第４　引用文献，引用発明
１．引用文献１について
　原査定の拒絶の理由に引用された引用文献１には，図面とともに次の事項が記載されている。（下線は強調のため当審で付与した。）
ア　「[0020] FIG. 1A  is an illustrative drawing showing a system  100  in accordance with some embodiments. The system  100  includes a first endpoint device  202-1  and a second endpoint device  202-2  that communicate over a multimedia service delivery network architecture  208 . The endpoint devices may comprise mobile cellular wireless devices, set top boxes, tablet computers, automotive navigation/entertainment systems, gaming consoles, personal computers or some combination of these. In some embodiments, the network architecture  208 , comprises the IMS architecture.
[0021] The first and second endpoint devices  202-1 ,  202-2  are configured for application-to-application (hereinafter ”A2A”) communication. That is, an application operative on the first device  202-1  can communicate with an application operative on the second device  202-2 . For example, multiuser A2A communication game applications may exchange game data as well as in-game audio and video allowing users to talk and see each other while playing. As another example, multimedia A2A communication messaging applications may provide text based chat, photo/video/music/file transfer, live video sharing, group chat, location sharing or any kind of 2-way or group communications. As yet another example, a multiplayer A2A communication game application may include low latency, peer to peer data exchange between two or more parties, and/or including other multimedia features such as audio, video or text based chat. Other examples of applications involving A2A communication may involve unified communications applications, customer care applications, social/dating apps, enterprise apps. These example A2A communication applications may utilize the same features such as peer to peer data exchange, multimedia message exchange (text-based, video, audio, photo or other multimedia types). Other A2A communication applications might include audio/video conferencing applications. As explained more fully below, the devices establish one or more media sessions on which applications may communicate media data with other applications.
[0022] An A2A application manager server  102  is in a control path during creation of media session between A2A enabled applications. The server  102  manages authorization of media connections between A2A applications. More particularly, a multiplicity of different A2A applications may run on a variety of different endpoint devices. The application manager server  102  manages authorization of media connections between applications that runn on endpoint devices and that are enabled for A2A communication (hereinafter ”A2A enabled applications”)
[0023] Management authorization involves identifying the A2A enable application. Also, management authorization involves validating that a request ostensibly received from an identified A2A enabled application to establish A2A communication with another A2A enabled application actually was sent by the A2A enabled application that purports to have sent it. In addition, in some embodiments, management authorization involves applying one or more policies to determine whether an application is authorized for a user identified in a request.
[0024] In some embodiments, the application management server includes an application registration interface  112 , which may be implemented as a web server, database, remote process or other means of making centrally managed data available to distributed clients and other systems for use to designate Application Identifier (”AppID”) and application secret information, i.e. non-public, information that is to be associated with the A2A enabled applications. In some embodiments, a developer uses the application registration interface  112  to register an A2A enabled application. In a pre-registration scenario, a developer registers an application within the application registry  104 . An AppID and an application secret are returned and indexed to the application. The AppID is used to route all messages between applications through matching of AppIDs in messages to AppIDs of applications. This registration is a one-time event and happens once for the application deployment. The application secret is used to dynamically create the application token. In a dynamic registration scenario, the developer does not register the application in advance but has a developer key or token that allows dynamic registration of multiple applications. This is a ”trusted developer” that has been authorized on the platform. A developer key would be passed during the application registration at runtime, and validated against a list of white-listed developer keys in the backend registry database. Characteristics can be associated with each developer key that limit dynamic registrations, or the number of distinct applications that can be registered, or by mobile operator, as an example. Other characteristics are possible. During dynamic registration, the developer key is passed on startup or installation of the application, in order to retrieve an AppId and application secret. The application secret could be valid for that session, or longer period as defined by the platform.
[0025] （略）
[0026] AppIDs are identifiers that uniquely identify A2A enabled applications within the system  100 . In other words, each different kind of A2A application may be associated with its own unique AppID. AppIDs can be generated using different approaches and can have different formats including but not limited to numeric identifiers (e.g. 1234), alphanumeric identifiers (e.g. acme-application-1), host/domain/package names (e.g. com.acme.xyz) and random values.」
（仮訳：
[0020] 
図１Ａはいくつかの実施形態におけるシステム１００を例示する図である。システム１００は，マルチメディアサービス配信ネットワークアーキテクチャ２０８を介して通信する第１端末装置２０２−１と第２端末装置２０２−２を備える
[0021]
第１および第２端末装置２０２−１，２０２−２はアプリケーション間（以下，Ａ２Ａ）通信用に構成されている。すなわち，第１装置２０２−１で動いているアプリケーションは，第２装置２０２−２で動いているアプリケーションと通信することができる
装置はアプリケーションが他のアプリケーションとメディアデータを通信できる１以上のメディアセッションを確立する
[0022]Ａ２Ａアプリケーションマネージャサーバ１０２は，Ａ２Ａ対応アプリケーション間のメディアセッションの確立中は制御パスに配置される。サーバ１０２は，Ａ２Ａアプリケーション間のメディア接続の承認を管理する。さらに詳細には，様々な異なるＡ２Ａアプリケーションが様々な異なる端末装置で動いていてもよい。アプリケーションマネージャサーバ１０２は，端末装置で動くとともにＡ２Ａ通信に対応可能なアプリケーション（以下，Ａ２Ａ対応アプリケーション）間のメディア接続の承認を管理する。
[0023]管理承認は，Ａ２Ａ対応アプリケーションを識別することを含む。また，管理承認は，他のＡ２Ａ対応アプリケーションとの間でＡ２Ａ通信を確立するために，表面上は識別されたＡ２Ａ対応アプリケーションから受領した要求が，その要求を送信したとされるＡ２Ａ対応アプリケーションによって実際に送信されたと確認することも含む。さらに，いくつかの実施形態では，管理承認は，要求内で特定されたユーザにアプリケーションが承認されるか否か判定するための１つ以上の規定を適用することを含む。
[0024]いくつかの実施形態では，アプリケーションマネージャサーバはアプリケーション登録インターフェース１１２を含み，Ａ２Ａ対応アプリケーションに関連付けられたアプリケーション識別子（ＡｐｐＩＤ）やアプリケーション秘密情報（アプリケーション秘密）などの非公開情報を指定するために使用するように，ウェブサーバ，データベース，遠隔プロセス，または分散クライアントや他のシステムに中央管理されたデータを利用可能にする他の手段として機能する。いくつかの実施形態では，開発者は，Ａ２Ａ対応アプリケーションを登録するために，アプリケーション登録インターフェース１１２を使用する。予備登録段階では，開発者は，アプリケーションをアプリケーションレジストリ１０４に登録する。ＡｐｐＩＤとアプリケーション秘密が返送されて，アプリケーションにインデックスを付ける。ＡｐｐＩＤは，メッセージ中のＡｐｐＩＤとアプリケーションのＡｐｐＩＤとの一致によってすべてのメッセージの経路を決めるために使用される。この登録は，一回限りのイベントであり，アプリケーション配備のために一回発生する。アプリケーション秘密は，動的にアプリケーショントークンを作成するために使用される。動的登録段階では，開発者は事前にアプリケーションを登録することはせず，複数のアプリケーションの動的な登録を可能にする開発者キーまたはトークンを有する。これは，プラットフォームで承認された「信任開発者」である。開発者キーは，動作中のアプリケーション登録中にパスし，バックエンドレジストリデータベース内の開発者キーのホワイトリストに対して確認される。それぞれの開発者キーには特性が関連付けられ，たとえば，動的登録または携帯電話会社により登録される個別のアプリケーションの数を制限する。他の特性も可能である。動的登録の間に，ＡｐｐＩＤおよびアプリケーション秘密を引き出すために，開発者キーはアプリケーションのスタートアップまたはインストールに進む。セッションの間またはプラットフォームにより定義される長い期間，アプリケーション秘密は有効となっている。
[0025]（略）
[0026]
ＡｐｐＩＤは，システム１００内においてＡ２Ａ対応アプリケーションを固有に識別する識別子である。言い換えれば，それぞれの異なる種類のＡ２Ａアプリケーションは，自身の固有なＡｐｐＩＤに関連付けられている
イ　「[0045] FIG. 2A  shows multiple communication stages, S0 -S5 , of communication among components of the system  100  involved with setting up a communication session between the first and second instances of A2A application  204-1 ,  204-2 . Setting up communication between the first endpoint device  202-1  and the second endpoint device  202-2  involves sending signals over the network  208 . As explained above, a SIP proxy server  210  is used to route session invitations from an inviter endpoint device to an invitee endpoint devices. In the example signal flow of  FIG. 2A , the first endpoint device  202-1  is assumed to be the inviter device and the second endpoint device  202-2  is assumed to be the invitee device. It will be appreciated that additional messaging may be involved in setting up a session. However, details of such possible additional messaging are unimportant to the present invention and will be readily understood by persons skilled in the art, and therefore, will are not discussed herein.
[0046] During stage S0 , the first instance of A2A enabled application  204-1  on the first endpoint device  202-1  configures the device  202-2  to send a request  212  to a first instance of the A2A communications engine  206-1  to establish a media session with a second instance of the A2A enabled application  204-2  on the second endpoint device  202-2 . The A2A engine  206-1  and the A2A engine  206-2  act as interfaces between the A2A enabled application instances  204-1  and  204-2  and respective communication protocol stacks as described more fully below. In some embodiments, the request  212  involves a method call to the first instance of the A2A communications engine  206-1  running within the first device  202-1 . In some embodiments, a method call may involve a procedure call in C, C++, Java or other common programming or scripting languages. A method call also may involve a message using available mechanisms such as pipes, queues or sockets or a remote procedure call to a separate process using AIDL, RMI, CORBA or other mechanisms.
[0047] FIG. 3  is an illustrative drawing showing certain fields within the data structure of an example method call request  212 . A SIP URI (Uniform Resource Identifier) field identifies the invitee device  202-2 . An AppID field uniquely identifies the requesting application. Depending upon the implementation, security information field may include token information used for security or secret information used to generate a token. The requested request also may include additional information such as thte type of media session requested, which may involve one or more types of media such as voice, video, file transfer, chat, group chat, real time peer-to-peer data transfer or application presence, for example.
[0048] During stage S1 , the first instance of the A2A communications engine  206-1  configures the first endpoint device  202-1  to act as an interface that converts the request  212  to a SIP invite message  214  suitable for transmission to the SIP proxy  210  within the endpoint network  208 . As explained above, actual transmission may involve traversal of several different proxies, and possibly, the use of a registrar server (not shown) and a redirect server (not shown) within the network  208 , for example. The example SIP message  214  comprises an invitation from the first endpoint device  202-1  having a first identifier (e.g., a first SIP URI) to the second endpoint device  202-2  having a second identifier (e.g., a second SIP URI).
[0049] FIG. 4  is an illustrative drawing showing certain header fields within the structure of an example SIP message  214 . ”From” and ”To” address fields indicate the first SIP URI and the second SIP URI, respectively. A service tag field indicates the communication type as being ”App2App” (i.e. application-to-application). An AppID field provides a globally unique identifier that acts as a parameter to identify and track the unique type of application throughout the communication session. In some embodiments, an optional security information field includes a security token used to authenticate the message. An SDP field provides information used to negotiation media transmission during the session. In this example, the media includes video media using H 264  format and having a specified bitrate (not shown), for example.
[0050] During stage S2 , in response to the service tag which indicates that the message contains a request by an A2A enabled application associated with an AppID, the SIP proxy  210  sends a message  216  to the A2A application manager  102  which evaluates the media session request. More particularly, in some embodiments, the service tag acts as an instruction to the proxy server  210  to send an authorization request  216  to the application manager server  102  prior to forwarding the request to the second endpoint device  202-2 . Thus, request  214  encapsulates instructions to make request  216 . In some embodiments, the message  216  includes the header information shown in and described with reference to  FIG. 4 . In response to the message  216 , the A2A application manager  102  employs the first and second processes described with reference to  FIGS. 1B-1E  to perform one or more functions such as validating the security information, generating usage statistics, triggering charges for the media session and determining whether a media session request should be rejected due to failure of security or due to blacklisting of the AppID for a particular device or user, for example. It will be appreciated that the inclusion of the service tag indicating an A2A enabled message in effect acts to direct the proxy server  210  to request authorization from the application manager to make the media connection. Thus, the SIP invite  214  encapsulates both a request to create a media connection with a second instance of the A2A enabled application  204-2  running on the second endpoint device  202-2  and a request to the application manager server  102  for authorization of the A2A application having the AppID contained within the SIP message.
[0051] During stage S3 , in response to message  216  and upon completion of such A2A application manager functions the, A2A application manager  102  sends a message  218  to the proxy server  210  that identifies the sending and receiving endpoint devices  202-1 ,  202-2 , the requested service, App2App service and the AppID and that indicates whether the requested media session should be accepted or rejected. In some embodiments, the A2A application manager  102  forwards SIP messages/requests that are determined to be authorized over the network  208  on to the second endpoint device  202-2 . If the request is rejected the The A2A application manager  102  sends a notification of the rejection to the first endpoint device  202-1  that originated the request. During stage S4 , the proxy server  210  sends message  220  including information within the structure of  FIG. 4  to the second instance of the A2A communications engine  206-2  running on the second endpoint device  202 - 2 . The A2A communications engine  206-2  determines whether an instance of the application corresponding to the AppID in the message  220  has been installed and is running on the second endpoint device  202-2 . If an instance of the application  204-2  has been installed but is not yet running, then in some embodiments, the A2A communications engine  206-2  wakes up the application.
[0052] If an instance of the application  204-2  has not been installed, then the A2A communications engine  206-2  In general, the A2A communications engine  206-2  will have prior knowledge as to whether the endpoint device  202-2  has installed an instance of the requested application  204-2 . However, in some embodiments, if the application has not been installed then the A2A communications engine  206-2  automatically declines the invitation. In some embodiments, the A2A communications engine  206-2  also prompts the second endpoint device  202-2  to download the missing application by using the AppId from the missed invitation to look up the application in the application registry  104  where metadata such as the download link for the missing application can be obtained. In some embodiments, a user interface on the second endpoint device  202-2  indicates the missed invitation to the device user and provides information concerning how to obtain the missing application. For example, such message may in provide a message such as ”missed invitation/challenge to play application named ”abc”. (The name of the application may differ from its AppID) Click here to download”.
[0053] During stage S5 , assuming that the application is installed and is running (or awakens), the A2A communications engine  206-2  sends message  222 , which includes information within the structure of  FIG. 4  to the second instance of the application  204-2  running on the second endpoint device  202-2 . In some embodiments, depending upon the second endpoint device platform and/or programming language, delivery of the message  222  may occur through a callback/event mechanism, procedure call or other platform specific means for inter-process communication (e.g. ”intents” on the Android platform) for example. In general, in some embodiments, messages are acknowledged at the SIP protocol level (ACK and OK messages). Where applicable, timeouts are also associated with the messages (e.g. the INVITE). With the SIP protocol, for example, a ”VIA” header may be used to indicate which network nodes to traverse to arrive at the inviter endpoint device  202-1 . With a timeout, the inviter device  202-1  would observe that the invitee device  202-2  failed to accept the invitation as opposed to the invitee device  202-2  affirmatively rejecting the invitation.
[0054] FIG. 2B  is an illustrative drawing of an alternative system  260  in accordance with some embodiments. Components of the alternative system  160  are substantially the same as those described with reference to  FIGS. 1A-2A . Thus, the differences between the system  100  and the system  160  are described. Specifically, the A2A engine  206-1' is configured to periodically request indication of AppIDs for A2A enabled applications that are currently authorized. Specifically, the A2A engine  206-1' periodically requests AppID authorization for applications currently registered on the device  202-1'. The A2A engine  206-1' maintains a local endpoint device application registry  162  that indicates authorized A2A enabled applications. In response to a request from the A2A enabled application having an associated AppID to set up a media session, the A2A engine makes a determination based upon contents of the registry  162  of whether the A2A enabled application  204-1' is authorized based upon its AppID. Thus, stages S2 , S3  of the signal flow of  FIG. 2  can be avoided. The first endpoint device  202-1' can send a SIP invite  164  over the network (not shown), and the second endpoint device  202-2' can send a SIP reply  166  over the network without the need to inquire with the manager  102  in the course of setting up a communication session.
[0055] FIG. 5  is an illustrative drawing of the system  100  of  FIG. 2A  in which media communication has been successfully initiated and in which communication protocol stacks  530-1 ,  530-2  are used to transmit media data between the first and second endpoint devices  202-1 ,  202-2 . Both the first and second communication protocol stacks  530-1 ,  530 - 2  are layered protocol stacks. In general, network protocols are layered in that network functionality is divided into layers, each layer performing a well-defined service relying on the services of the layer below it in a protocol stack and providing services to the layer above in the stack. In general, a communication protocol is used to define a software based system that provides communication services at one layer in the stack. The resulting layered protocol is referred to as a protocol stack. A protocol stack defines network communication functionality that involves multiple protocols. More particularly, the protocol stack layers comprise instructions encoded in non-transitory media to cause the endpoint devices  202-1 ,  202-2  and machines within the network  208  to implement network functionality defined by the protocol layers.
[0056] In some embodiments, the first and second communication protocol stacks  530-1 ,  530-2  are compliant with the IMS network architecture. An IMS protocol stack includes different protocols defined by different standards or RFCs (Request for Comments) at different layers. In the IMS network architecture, SIP typically is used in conjunction with several other protocols that are part of an IMS compliant communication protocol stack including: ”RTP” (real-time transport protocol) and ”SDP” (session description protocol). RTP typically is used to encode and split the real-time multimedia data (e.g., audio, video share, chat, file share, XMPP based protocols and extensions (e.g., ”Jingle” service for voice over IP) and other peer-to-peer real-time communication mechanisms) into packets and transport such packets over the Internet. SDP typically is used to describe and encode capabilities of session participants. Such a description can be used to negotiate the characteristics of the session, such as codecs used to encode media and transport protocol to use, so that all the devices can participate in a session. It will be appreciated that the IMS network architecture may specify the use of different protocol options for different specific uses.
[0057] FIG. 5  shows that one or more communication sessions  532  are established between the first and second endpoint devices  202-1 ,  202-2  following successful initiation pursuant to the signaling protocol of  FIG. 2A .  FIG. 5  also shows that the communication sessions  532  transfer data across the network  208  pursuant to protocols specified by the identical protocol stack instances  530-1 ,  530-2 . As explained more fully below, the A2A engine instances  206-1 ,  206-2  act as interfaces: (1) to convert method calls requests or messages received from the A2A enabled application instances  204-1 ,  204-2  to a form useable over the network  208 ; (2) to convert network packets or frames received from the network  208  to a form useable by the A2A enabled application instances  204-1 ,  204-2 ; and (3) to route control data and media data communicated across the network  208  during the sessions  532  between the respective application instances  204-1 ,  204-2  and the protocol stack instances  530-1 ,  530-2 .」
（仮訳：
[0045] 
図２Ａは，Ａ２Ａアプリケーション２０４−１，２０４−２の第１および第２インスタンス間の通信セッションの確立に含まれるシステム１００の機器間の通信の複数の通信ステージＳ０−Ｓ５を示す。第１端末装置２０２−１と第２端末装置２０２−２間の通信の確立には，ネットワーク２０８を介して信号を送信することが含まれる。上述のように，ＳＩＰプロキシサーバ２１０は，招待端末機器から被招待端末機器にセッション招待案内を送るために使用される。図２Ａの信号フローの例において，第１端末装置２０２−１を招待装置とし，第２端末装置２０２−２を被招待装置とする
[0046] ステージＳ０において，第２端末装置２０２−２のＡ２Ａ対応アプリケーション２０４−２の第２インスタンスとのメディアセッションを確立するために，第１端末装置２０２−１のＡ２Ａ対応アプリケーション２０４−１の第１インスタンスは装置２０２−１が要求２１２をＡ２Ａ通信エンジン２０６−１の第１インスタンスに送信するように構成する。以下に詳細に説明するように，Ａ２Ａエンジン２０６−１とＡ２Ａエンジン２０６−２はＡ２Ａ対応アプリケーションインスタンス２０４−１，２０４−２，および各通信プロトコルスタックの間のインターフェースとして動作する。いくつかの実施形態では，要求２１２は，第１装置２０２−１で動いているＡ２Ａ通信エンジン２０６−１の第１インスタンスへのメソッド呼出しを含む。いくつかの実施形態では，メソッド呼出しは，Ｃ，Ｃ＋＋，Ｊａｖａ，または他の一般的なプログラム言語またはスクリプト言語による手続き呼出しを含んでもよい。また，メソッド呼出しは，ＡＩＤＬ，ＲＭＩ，ＣＯＲＢＡ，または他の仕組みを使用した別のプロセスに対する，パイプ，キュー，ソケット，または他の遠隔手続き呼出しなどの利用可能な仕組みを使用したメッセージを含んでもよい。
[0047] 図３は，メソッド呼出し要求２１２の例のデータ構成内のフィールドを例示する図である。ＳＩＰユーアールアイ（ＵＲＩ）フィールドは，被招待装置２０２−２を特定する。ＡｐｐＩＤフィールドは，要求アプリケーションを特定する。構成によっては，セキュリティ情報フィールドは，セキュリティのために使用されるトークン情報やトークンを生成するために使用される秘密情報を含んでもよい。また，発せられた要求は，たとえば，音声，映像，ファイル転送，チャット，グループチャット，リアルタイムピアツーピアデータ転送，アプリケーション配置などの１種類以上のメディアを含む，要求されたメディアセッションなどの追加情報を含んでもよい。
[0048] ステージＳ１において，Ａ２Ａ通信エンジン２０６−１の第１インスタンスは，要求２１２を端末ネットワーク２０８内でＳＩＰプロキシサーバ２１０への送信に適したＳＩＰ招待メッセージ２１４に変換するインターフェースとして動作するように，第１端末装置２０２−１を構成する。上述のように，実際の送信は，たとえば，いくつかの異なるプロキシ間の往来，また場合によっては，ネットワーク２０８内のレジストラサーバ（不図示）やリダイレクトサーバ（不図示）の使用を含んでもよい。ＳＩＰメッセージ２１４の例は，第１識別子（たとえば，第１ＳＩＰ−ＵＲＩ）を有する第１端末装置から第２識別子（たとえば，第２ＳＩＰ−ＵＲＩ）を有する第２端末装置への招待を含む。
[0049]
 図４は，ＳＩＰメッセージ２１４の例の構成内のヘッダフィールドを例示する図である
ＡｐｐＩＤフィールドは，通信セッションを介してアプリケーションの固有なタイプを特定し追跡するパラメータとして動作するグローバルに固有な識別子を提供する。
[0050] ステージＳ２において，メッセージがＡｐｐＩＤに関連付けられたＡ２Ａ対応アプリケーションによる要求を含むことを示すサービスタグに応じて，ＳＩＰプロキシサーバ２１０はメディアセッション要求を評価するＡ２Ａアプリケーションマネージャ１０２にメッセージ２１６を送信する。さらに詳しくは，いくつかの実施形態では，サービスタグは，プロキシサーバ２１０に対する，要求を第２端末装置２０２−２に転送する前に承認要求２１６をアプリケーションマネージャサーバ１０２に送信する命令として動作する。このように，要求２１４には，要求２１６を生成する命令が埋め込まれている。いくつかの実施形態では，メッセージ２１６は，図４に示され参照して説明されるヘッダ情報を含む。たとえば，特定の装置やユーザに対する，セキュリティ情報の確認，使用統計の生成，メディアセッション課金のトリガー，またはセキュリティエラーまたはＡｐｐＩＤのブラックリストによりメディアセッション要求が拒絶されるべきか否かの判定などの１つ以上の機能を実行するために，メッセージ２１６に応じて，Ａ２Ａアプリケーションマネージャ１０２は，図１Ｂから図１Ｅにより説明した第１および第２のプロセスを実行する。Ａ２Ａ対応メッセージを示すサービスタグが実質的に含まれることにより，プロキシサーバ２１０がメディア接続を確立するためにアプリケーションマネージャに対して承認を要求することになる。このように，第２端末装置２０２−２で動いているＡ２Ａ対応アプリケーション２０４−２の第２インスタンスとのメディア接続を確立する要求と，アプリケーションマネージャサーバ１０２に対するＳＩＰメッセージに含まれたＡｐｐＩＤを有するＡ２Ａアプリケーションの承認の要求とが，両者ともＳＩＰ招待２１４に埋め込まれている。
[0051] ステージＳ３において，メッセージ２１６および上述のＡ２Ａアプリケーションマネージャ動作の完了に応じて，Ａ２Ａアプリケーションマネージャ１０２は，要求されたサービス，Ａ２Ａサービス，およびＡｐｐＩＤの端末装置２０２−１，２０２−２に対する送受信を特定するとともに要求されたメディアセッションが受諾されるべきか拒絶されるべきかを示すメッセージ２１８を，プロキシサーバ２１０に送信する。いくつかの実施形態では，Ａ２Ａアプリケーションマネージャ１０２は，承認と判定されるＳＩＰメッセージ／要求をネットワーク２０８を介して第２端末装置２０２−２に転送する。要求が拒絶された場合には，Ａ２Ａアプリケーションマネージャ１０２は，要求を発した第１端末装置２０２−１に拒絶通知を送信する。
ステージＳ４において，プロキシサーバ２１０は，図４の構成中の情報を含むメッセージ２２０を第２端末装置２０２−２で動いているＡ２Ａ通信エンジン２０６−２の第２インスタンスに送信する
[0052] アプリケーション２０４−２のインスタンスがインストールされていない場合，一般的には，Ａ２Ａ通信エンジン２０６−２は，端末装置２０２−２が要求されたアプリケーション２０４−２のインスタンスをインストールしたか否かについての事前情報を得ることになる。しかし，いくつかの実施形態では，アプリケーションがインストールされていない場合には，Ａ２Ａ通信エンジン２０６−２は自動的に招待を拒絶する。また，いくつかの実施形態では，Ａ２Ａ通信エンジン２０６−２は，第２端末装置２０２−２に対して，失敗した招待のＡｐｐＩＤを使用して，不足しているアプリケーションのダウンロードリンクなどのメタデータが得られるアプリケーションレジストリ１０４でアプリケーションを検索して，不足しているアプリケーションをダウンロードするように促す。いくつかの実施形態では，第２端末装置２０２−２のユーザインターフェースが，装置のユーザに対して失敗した招待を示し，不足しているアプリケーションの取得方法についての情報を提供する。たとえば，「「ａｂｃ」という名称（ＡｐｐＩＤとは異なってもよい）のアプリケーションの実施の招待／申込みに失敗しました。ここをクリックしてダウンロードしてください。」のようなメッセージが提供されてもよい。
[0053] ステージＳ５において，アプリケーションがインストール済で動いている（起動している）と仮定すると，Ａ２Ａ通信エンジン２０６−２は，図４の構成内の情報を含むメッセージ２２２を第２端末装置２０２−２で動いているアプリケーション２０４−２の第２インスタンスに送信する。いくつかの実施形態では，第２端末装置のプラットフォームおよび／またはプログラム言語によっては，メッセージ２２２は，たとえば，コールバック／イベント装置，手続き呼出し，またはプロセス間通信のための他のプラットフォームに特定の手段（たとえば，アンドロイドプラットフォームの「インテント」）を介して配信されてもよい。一般的には，いくつかの実施形態では，メッセージはＳＩＰプロトコルレベルで認識される（ＡＣＫおよびＯＫメッセージ）。適用可能な場合には，タイムアウトもメッセージに関連付けられる（たとえば，ＩＮＶＩＴＥ）。ＳＩＰプロトコルによって，たとえば，「ＶＩＡ」ヘッダが，招待端末装置２０２−１にたどり着くために往来するネットワークノードを示すために使用されてもよい。タイムアウトの場合には，被招待装置２０２−２による積極的な招待拒絶とは対照的に，招待装置２０２−１は，被招待装置２０２−２が招待の受諾に失敗したと認識する。
[0054] 図２Ｂは，いくつかの実施形態における代替システム１６０の例示的な図である。代替システム１６０の機器は，図１Ａから図２Ａを用いて説明したものと実質的に同一である。以下，システム１００とシステム１６０の違いを説明する。具体的には，Ａ２Ａエンジン２０６−１’は，現在承認済のＡ２Ａ対応アプリケーションのＡｐｐＩＤの表示を周期的に要求するように構成される。具体的には，Ａ２Ａエンジン２０６−１’は，装置２０２−１’の現在登録済のアプリケーションのＡｐｐＩＤ承認を周期的に要求する。Ａ２Ａエンジン２０６−１’は，承認済Ａ２Ａ対応アプリケーションを示すローカル端末装置アプリケーションレジストリ１６２を維持する。関連付けられたＡｐｐＩＤを有するＡ２Ａ対応アプリケーションからの，メディアセッション確立の要求に応じて，Ａ２Ａエンジンが，レジストリ１６２の内容に基づいてＡ２Ａ対応アプリケーション２０４−１’がそのＡｐｐＩＤに基づいて承認されるか否かを決定する。このように，図２の信号フローにおけるステージＳ２とＳ３を回避することができる。第１端末装置２０２−１’は，ネットワーク（不図示）を介してＳＩＰ招待１６４を送信することができる。また，第２端末装置２０２−２’は，通信セッション確立の過程でマネージャ１０２に問い合わせる必要なしに，ネットワークを介してＳＩＰ応答１６６を送信ことができる。
[0055] 図５は，メディア通信の初期化が成功し，第１および第２の端末装置２０１−１，２０２−２の間でメディアデータを送信するために通信プロトコルスタック５３０−１，５３０−２が使用される，図２Ａのシステム１００の例示的な図である。通信プロトコルスタック５３０−１，５３０−２はいずれも階層プロトコルスタックである。一般的に，ネットワークプロトコルは，ネットワーク機能が層に分割されるように階層化されている。プロトコルスタックにおいて，各層は，下層のサービスに依存する明確なサービスを実行し，上層にサービスを提供する。一般に，通信プロトコルは，スタック内の１つの層で通信サービスを提供するソフトウェアシステムを規定するために使用される。結果として生じる階層化プロトコルは，プロトコルスタックと呼ばれる。プロトコルスタックは，複数のプロトコルを含むネットワーク機能を規定する。さらに詳細には，プロトコルスタック層は，持続性媒体にコード化された命令を有し，端末装置２０２−１，２０２−２およびネットワーク２０８の機器にプロトコル層によって規定されたネットワーク機構を実行させる。
[0056] ワークアーキテクチャに準拠する。ＩＭＳプロトコルスタックは，異なる標準またはＲＦＣ（コメント要求）によって規定された異なるプロトコルを異なる層に有している。ＩＭＳネットワークアーキテクチャにおいて，典型的には，ＳＩＰは，ＲＴＰ（リアルタイム転送プロトコル）とＳＤＰ（セッション記述プロトコル）を含んで，ＩＭＳ準拠の通信プロトコルスタックの一部である他のいくつかのプロトコルと連動して使用される。典型的には，ＲＴＰは，リアルタイムマルチメディアデータ（たとえば，音声，映像共有，チャット，ファイル共有，ＸＭＰＰ準拠プロトコルおよび拡張（たとえば，ＩＰを介した音声サービスのジングル），およびその他ピアツーピアリアルタイム通信の仕組み）をコード化してパケットに分割し，パケットをインターネットを介して転送するように使用される。典型的には，ＳＤＰは，セッション参加メンバーの能力を記述しコード化するように使用される。このような記述は，メディアをコード化するコーデックや使用する転送プロトコルなど，セッションの特徴を取り決めるために使用できる。その結果，すべての装置がセッションに参加できるようになる。もちろん，異なる特定の使用のために異なるプロトコルのオプションを使用することをＩＭＳネットワークアーキテクチャが指定してもよい。
[0057] 図５は，図２Ａの通信プロトコルに従ってセッションの初期化成功後に第１および第２の端末装置２０２−１，２０２−２の間に１つ以上の通信セッション５３２が確立されていることを示す。また，図５は，通信セッション５３２が同一のプロトコルスタックインスタンス５３０−１，５３０−２によって特定されたプロトコルに従ってネットワーク２０８を介してデータを転送することも示す。以下の詳細に説明するように，Ａ２Ａエンジンインスタンス２０６−１，２０６−２は，インターフェースとして動作し，（１）Ａ２Ａ対応アプリケーションインスタンス２０４−１，２０４−２から受信したメソッド呼出し要求やメッセージを，ネットワーク２０８で使用可能な形式に変換し，（２）ネットワーク２０８から受信したネットワークパケットやフレームをＡ２Ａ対応アプリケーションインスタンス２０４−１，２０４−２が使用可能な形式に変換し，（３）各アプリケーションインスタンス２０４−１，２０４−２およびプロトコルスタックインスタンス５３０−１，５３０−２の間のセッション５３２中に，制御データとメディアデータをネットワーク２０８を介して送信する。）
ウ　「[0067] It will be appreciated that although only a single A2A enabled application is running on each endpoint device in the illustrated example, it is possible to run multiple A2A enabled applications on each endpoint device. Each A2A enabled application will have a unique AppID. The A2A engine routes control messages from a communications stack and different A2A enabled applications based upon the AppIDs. Also, it will be understood that a single control session may control media sessions for multiple different A2A enabled applications. For each different A2A enabled application, the control session may set up one or more media sessions that are dedicated to that A2A enabled application. Frames or packets of information communicated over the control session are routed to the different A2A applications based upon AppIDs contained within the frames or packets. Moreover, although the illustrative example herein describes communication between two A2A applications that have the same AppIDs, communication also may be established between two A2A enabled applications having different AppIDs.」
（仮訳：
[0067]　図示された例においては，各端末装置では単一のＡ２Ａ対応アプリケーションのみが動いている。しかし，
当然ながら，各端末装置で複数のＡ２Ａ対応アプリケーションが動くことも可能である。各Ａ２Ａ対応アプリケーションは，固有のＡｐｐＩＤを有している。Ａ２Ａエンジンは，通信スタックからＡｐｐＩＤに基づいて異なるＡ２Ａ対応アプリケーション制御メッセージを送信する。
単一の制御セッションにより複数の異なるＡ２Ａ対応アプリケーションのためのメディアセッションが制御可能である
制御セッションを介して通信された情報のフレームまたはパケットは，フレームまたはパケット内に含まれたＡｐｐＩＤに基づいて異なるＡ２Ａ対応アプリケーションに送信される。
　上記アより，引用文献１のＦＩＧ．１Ａに記載されたシステム１００は，アプリケーション間通信（以下，「Ａ２Ａ」という。）用に構成された第１端末装置２０２−１および第２端末装置２０２−２と，端末装置で動くとともにＡ２Ａ通信に対応可能なアプリケーション（以下，「Ａ２Ａ対応アプリケーション」という。）間のメディア接続の承認を管理するアプリケーションマネージャサーバ１０２とを備えている。そして，具体的には，上記イより前記端末装置間において，ＦＩＧ．２Ａ−１ないしＦＩＧ．２Ａ−４の通信ステージＳ０ないしＳ５により，通信セッションが確立するものであるところ，前記第１の端末装置は，通信ステージＳ０，Ｓ１，図４に関連して，ヘッダーのＡｐｐＩＰフィールドにＡ２Ａ対応アプリケーションを固有に識別する識別子であるＡｐｐＩＤを示したＳＩＰメッセージを構成し，前記第２の端末装置は，通信ステージＳ４，Ｓ５，図４に関連して，前記ＳＩＰメッセージのＡｐｐＩＤに対応するＡ２Ａ対応アプリケーションが起動していると前記ＳＩＰメッセージが認識され（ＡＣＫおよびＯＫメッセージ）て，前記Ａ２Ａ対応アプリケーションに関連付けされたセッションが確立するものである。
　さらに，上記ウより，引用文献１には，各端末装置で複数のＡ２Ａ対応アプリケーションが動くことも可能であり，この場合，単一の制御セッションにより複数の異なるＡ２Ａ対応アプリケーションのためのメディアセッションが制御可能であり，制御セッションを介して通信された情報のフレームまたはパケットは，フレームまたはパケット内に含まれたＡｐｐＩＤに基づいて異なるＡ２Ａ対応アプリケーションに送信されることが記載されている。
　ここで，単一の制御セッションを用いる前記複数の異なるＡ２Ａ対応アプリケーションを，そのセッションの開始順に「第１のＡ２Ａ対応アプリケーション」，「第２のＡ２Ａ対応アプリケーション」，・・・と称することは任意であり，この場合，「第２のＡ２Ａ対応アプリケーション」とＳＩＰメッセージとを関連付ける時点で，すでに「第１のＡ２Ａ対応アプリケーション」は，第１および第２の端末装置で起動されている，すなわち「共有されていること」は明らかであり，第１の端末装置は，「第１のＡ２Ａ対応アプリケーション」で使用する「制御セッション」を，「第２のＡ２Ａ対応アプリケーション」でも使用するようにＳＩＰメッセージを構成すること，及び第２の端末装置は，前記ＡｐｐＩＤにより，前記「制御セッション」を使用するため当該「ＳＩＰメッセージ」を「第２のＡ２Ａ対応アプリケーション」に関連付けることは，明らかである。
　また，引用文献１の「方法」の各手順を「〜ステップ」と称することは任意である。
　以上を総合すると，引用文献１には，「ＳＩＰメッセージを第２のＡ２Ａ対応アプリケーションと関連付ける方法」について，次の発明（以下，「引用発明」という。）が記載されていると認める。
「第１の端末装置と第２の端末装置で第１のＡ２Ａ対応アプリケーションを共有しているとき，ＳＩＰメッセージを第２のＡ２Ａアプリケーションと関連付ける方法であって，
　第１の端末装置によって，前記第１のＡ２Ａ対応アプリケーションと同じ制御セッションを前記第２のＡ２Ａアプリケーションにも使用するため，ヘッダーのＡｐｐＩＰフィールドに前記第２のＡ２Ａ対応アプリケーションを固有に識別する識別子であるＡｐｐＩＤを示したＳＩＰメッセージを構成するステップと，
　第２の端末装置によって，前記ＡｐｐＩＤにより，前記制御セッションを使用するため当該ＳＩＰメッセージを第２のＡ２Ａ対応アプリケーションに関連付けるステップと，
　単一の制御セッションを用いる複数の異なるＡ２Ａ対応アプリケーションがあるとき，第１の端末装置によって，ヘッダーのＡｐｐＩＰフィールドに前記第２のＡ２Ａ対応アプリケーションを固有に識別する識別子であるＡｐｐＩＤを示したＳＩＰメッセージを構成するステップと，を含む，
　方法。」
第５　対比・判断
１．本願発明１について
（１）対比
　本願発明１と引用発明とを技術常識を踏まえて対比する。
ａ　引用発明の「第１の端末装置」，「第２の端末装置」，「第１のＡ２Ａ対応アプリケーション」及び「第２のＡ２Ａ対応アプリケーション」は，それぞれ本願発明１の「第１のユーザ端末」，「第２のユーザ端末」，「第１のアプリケーション」及び「第２のアプリケーション」に相当する。
ｂ　引用発明の「ＳＩＰメッセージ」は，本願発明１の「セッション・イニシエーション・プロトコル（ＳＩＰ）メッセージ」及び「ＳＩＰメッセージ」と同義である。
ｃ　そうすると，引用発明の「第１の端末装置と第２の端末装置で第１のＡ２Ａ対応アプリケーションを共有しているとき，ＳＩＰメッセージを第２のＡ２Ａアプリケーションと関連付ける方法」は，以下の各相違点を除き，本願発明１の「異なるユーザ端末間で第１のアプリケーションを共有しているときに，セッション・イニシエーション・プロトコル（ＳＩＰ）メッセージを，前記異なるユーザ端末上で実行される第２のアプリケーションと関連付ける方法」に相当する。
ｄ　本願発明１の「ＳＩＰセッションにタグ付けする」ことは，本願明細書【００９５】より，ＳＩＰヘッダの既存の要素を修正すること，ＳＩＰヘッダに新しい要素を追加することを含むから，引用発明の「ヘッダーのＡｐｐＩＰフィールドに前記第２のＡ２Ａ対応アプリケーションを固有に識別する識別子であるＡｐｐＩＤを示したＳＩＰメッセージを構成する」ことは，「ＳＩＰセッションにタグ付けする」ことに含まれ，引用発明の「ＡｐｐＩＤ」は，本願発明１の「タグ」に含まれる。そうすると，引用発明の「第１の端末装置によって，前記第１のＡ２Ａ対応アプリケーションと同じ制御セッションを前記第２のＡ２Ａアプリケーションにも使用するため，ヘッダーのＡｐｐＩＰフィールドに前記第２のＡ２Ａ対応アプリケーションを固有に識別する識別子であるＡｐｐＩＤを示したＳＩＰメッセージを構成するステップ」は，本願発明１の「第１のユーザ端末によって，第１のアプリケーションに使用されたＳＩＰセッションを第２のアプリケーションに関連付けるように前記ＳＩＰセッションにタグ付けするタグ付けステップ」に含まれるといえる。
ｅ　上記ｄより，引用発明の「第２の端末装置によって，前記ＡｐｐＩＤにより，前記制御セッションを使用するため当該ＳＩＰメッセージを第２のＡ２Ａ対応アプリケーションに関連付けるステップ」は，本願発明１の「第２のユーザ端末によって，前記タグに従って，前記ＳＩＰセッションのためのＳＩＰメッセージを第２のアプリケーションに関連付ける関連付けステップ」に含まれるといえる。
ｆ　引用発明の「単一の制御セッションを用いる複数の異なるＡ２Ａ対応アプリケーションがあるとき，第１の端末装置によって，ヘッダーのＡｐｐＩＰフィールドに前記第２のＡ２Ａ対応アプリケーションを固有に識別する識別子であるＡｐｐＩＤを示したＳＩＰメッセージを構成するステップ」は，ＳＩＰメッセージにおいて第２のＡ２Ａ対応アプリケーションとをマッチングすることに含まれるから，本願発明１の「ユーザ端末間で同じＳＩＰ接続を共有する複数のアプリケーションがあるとき，第１のユーザ端末によって，複数のアプリケーション間の通信を管理するコンジットマネージャを活用して，ＳＩＰセッションと第２アプリケーションとをマッチングする，活用ステップ」とは，下記相違点１を除き，「ユーザ端末間で同じＳＩＰ接続を共有する複数のアプリケーションがあるとき，第１のユーザ端末によって，ＳＩＰセッションと第２アプリケーションとをマッチングする，ステップ」である点で，共通する。
　以上を総合すると，本願発明１と引用発明とは以下の点で一致し，また相違する。
＜一致点＞
「異なるユーザ端末間で第１のアプリケーションを共有しているときに，セッション・イニシエーション・プロトコル（ＳＩＰ）メッセージを，前記異なるユーザ端末上で実行される第２のアプリケーションと関連付ける方法であって，
　第１のユーザ端末によって，第１のアプリケーションに使用されたＳＩＰセッションを第２のアプリケーションに関連付けるように前記ＳＩＰセッションにタグ付けするタグ付けステップと，
　第２のユーザ端末によって，前記タグに従って，前記ＳＩＰセッションのためのＳＩＰメッセージを第２のアプリケーションに関連付ける関連付けステップと，
　ユーザ端末間で同じＳＩＰ接続を共有する複数のアプリケーションがあるとき，第１のユーザ端末によって，ＳＩＰセッションと第２のアプリケーションとをマッチングする，ステップと，を含む
　方法。」　
＜相違点１＞
　一致点である「ユーザ端末間で同じＳＩＰ接続を共有する複数のアプリケーションがあるとき，第１のユーザ端末によって，ＳＩＰセッションと第２のアプリケーションとをマッチングする，ステップ」について，本願発明１では，「複数のアプリケーション間の通信を管理するコンジットマネージャを活用」している「活用ステップ」であるのに対し，引用発明ではこのような限定がない点。
＜相違点２＞
　本願発明１では，「レガシー・リッチ・通信サービス（ＲＣＳ）アプリケーションを修正する修正ステップであり，第２のユーザ端末によって，前記ＳＩＰメッセージが前記レガシーＲＣＳアプリケーションを意図するか否かを判定するために各ＳＩＰセッションをチェックするＳＩＰセッションマネージャを第２のユーザ端末に追加し，そして，前記ＳＩＰセッションマネージャが，前記レガシーＲＣＳアプリケーションを意図する前記ＳＩＰメッセージを当該レガシーＲＣＳアプリケーションにルーティングし，且つすべての残りのＳＩＰメッセージを前記コンジットマネージャにルーティングすることにより，前記レガシーＲＣＳアプリケーションを修正する修正ステップ」を含むのに対し，引用発明では，当該「修正ステップ」を含むことが記載されていない点。
（２）判断
　事案に鑑み，まず相違点２について検討する。
　本願発明１は，（コンジットを使用しない）レガシーＲＣＳ及びＳＩＰアプリケーションがコンジットをサポートするアプリケーションと相互運用すること（明細書【００７３】）を課題として，相違点２に係る構成を有することで，既存のＲＣＳアプリケーションは，いかなる変更もなく動作し続けることができ，新しいアプリケーションは，レガシーアプリケーションと同じＳＩＰスタックと登録を共有することが許されるという効果（明細書【００７８】）を奏するものである。
　一方，引用文献１には，上記課題について記載も示唆もされておらず，また，相違点２に係る構成は自明なものでもないので，当該構成は，引用発明から容易に想到し得たとはいえない。
（３）小括
　したがって，相違点１について検討するまでもなく，本願発明１は，引用発明と同一ではなく，引用発明に基づいて当業者が容易に発明することができたものでもない。
２．本願発明２−７について
　本願発明２−７は，本願発明１の構成を全て含みさらに他の構成で特定した発明であるから，本願発明１と同様の理由により，引用発明と同一ではなく，引用発明に基づいて当業者が容易に発明できたものでもない。
第６　最後の拒絶理由について
１．特許法第３６条第６項第２号について
　平成２８年８月２４日付けの最後の拒絶理由の概要は，以下のとおりである。
「請求項５には，「ＳＩＰセッションの前記ＳＤＰパラメータを…」と記載されているが，この記載以前に，「ＳＤＰパラメータ」についての記載がないため，「前記」が何を指すものであるのか不明確である。
　請求項５を引用する請求項６についても同様である。」
　そこで検討するに，請求項５の「前記ＳＤＰパラメータ」について，請求項１には「ＳＤＰパラメータ」が記載されていないが，請求項５の「前記ＳＤＰパラメータ」の後に「セッション記述プロトコル（ＳＤＰ）パラメータ」との記載があり，当初明細書の記載（【０００５】等）との対応関係からみても，「前記」が後述の「セッション記述プロトコル（ＳＤＰ）パラメータ」を指すことは明らかである
　そうすると，「ＳＤＰパラメータ」は記載上では「前記」されていないものの，当該記載があることで請求項５に係る発明が不明確であるとまではいえない。
　請求項５を引用する請求項６についても同様である。
第７　むすび
　以上のとおり，本願発明１−７は，引用発明と同一ではなく，当業者が引用発明に基づいて容易に発明をすることができたものでもない。したがって，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。