• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04M
審判 査定不服 1項3号刊行物記載 取り消して特許、登録 H04M
管理番号 1330692
審判番号 不服2016-8432  
総通号数 213 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-09-29 
種別 拒絶査定不服の審決 
審判請求日 2016-06-08 
確定日 2017-08-08 
事件の表示 特願2014-180306「アプリケーションインターフェイスを将来のアプリケーション用に拡張するための方法」拒絶査定不服審判事件〔平成27年5月11日出願公開,特開2015-91125,請求項の数(8)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由 第1 本願は,平成26年9月4日の出願(優先権主張外国庁受理 2013年11月5日 米国,2014年8月3日 米国)であって,平成27年8月27日付けで拒絶理由が通知され,同年11月25日付けで手続補正がされ,平成28年3月10日付けで拒絶査定(以下,「原査定」という。)がされ,これに対し,同年6月8日付けで拒絶査定不服審判が請求されると同時に手続補正がされ,前置審査により同年8月24日付けで最後の拒絶理由が通知されたものである。

第2 原査定の概要
原査定(平成28年3月10日付け拒絶査定)の概要は,以下のとおりである。

1.本願請求項1,5,6に係る発明は,引用文献1に記載された発明であるから,特許法第29条第1項第3号に該当し,特許を受けることができない。
2.本願請求項1,2,3,5,6,8,9,11,12,14,15,17,18に係る発明は,引用文献1に基づいて,その発明の属する技術の分野における通常の知識を有する者(以下,「当業者」という。)が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができない。

＜引用文献等一覧＞
1.米国特許出願公開第2012/0221725号明細書

第3 本願発明
本願請求項1-8に係る発明(以下,それぞれ「本願発明1」-「本願発明8」という。)は,平成28年6月8日付けの手続補正で補正された特許請求の範囲の請求項1-8に記載された事項により特定される発明であり,以下のとおりの発明である。

「【請求項1】
異なるユーザ端末間で第1のアプリケーションを共有しているときに,セッション・イニシエーション・プロトコル(SIP)メッセージを,前記異なるユーザ端末上で実行される第2のアプリケーションと関連付ける方法であって,
第1のユーザ端末によって,第1のアプリケーションに使用されたSIPセッションを第2のアプリケーションに関連付けるように前記SIPセッションにタグ付けするタグ付けステップと,
第2のユーザ端末によって,前記タグに従って,前記SIPセッションのためのSIPメッセージを第2のアプリケーションに関連付ける関連付けステップと,
ユーザ端末間で同じSIP接続を共有する複数のアプリケーションがあるとき,第1のユーザ端末によって,複数のアプリケーション間の通信を管理するコンジットマネージャを活用して,SIPセッションと第2アプリケーションとをマッチングする,活用ステップと,
レガシー・リッチ・通信サービス(RCS)アプリケーションを修正する修正ステップであり,第2のユーザ端末によって,前記SIPメッセージが前記レガシーRCSアプリケーションを意図するか否かを判定するために各SIPセッションをチェックするSIPセッションマネージャを第2のユーザ端末に追加し,そして,前記SIPセッションマネージャが,前記レガシーRCSアプリケーションを意図する前記SIPメッセージを当該レガシーRCSアプリケーションにルーティングし,且つすべての残りのSIPメッセージを前記コンジットマネージャにルーティングすることにより,前記レガシーRCSアプリケーションを修正する修正ステップと,を含む,
方法。
【請求項2】
請求項1に記載の方法であって,第1のユーザ端末によって,前記SIPのヘッダ内の既存の要素を修正することにより,前記SIPセッションを第2のアプリケーションに関連付けるように前記SIPセッションにタグ付けするタグ付けステップをさらに含む,
方法。
【請求項3】
請求項1に記載の方法であって,第1のユーザ端末によって,前記SIPのヘッダに第1のアプリケーションで用いた要素とは異なる要素を追加することにより,前記SIPセッションを第2のアプリケーションに関連付けるように前記SIPセッションにタグ付けするタグ付けステップをさらに含む,
方法。
【請求項4】
請求項1に記載の方法であって,第1のユーザ端末により,前記SIPによってネゴーシエイトされるセッション記述プロトコル(SDP)パラメータに第1のアプリケーションで用いた要素とは異なる要素を追加することにより,前記SIPセッションを第2のアプリケーションに関連付けるように前記SIPセッションにタグ付けするタグ付けステップをさらに含む,
方法。
【請求項5】
請求項1に記載の方法であって,SIPセッションの前記SDPパラメータをネゴーシエイトするときに,第1のユーザ端末によって,セッション記述プロトコル(SDP)パラメータの既存の要素を修正することにより,前記SIPセッションを第2のアプリケーションに関連付けるように前記SIPセッションにタグ付けするタグ付けステップをさらに含む,
方法。
【請求項6】
請求項5に記載の方法であって,前記SIPによってネゴーシエイトされる前記SDPパラメータの前記既存の要素を修正する修正ステップは,前記SIPセッションの前記SDPパラメータをネゴーシエイトするときに,第1のユーザ端末によって,第2のアプリケーションをセッション名として特定する特定ステップを含む,
方法。
【請求項7】
請求項1に記載の方法であって,事前に定義されたリッチ通信サービス(RCS)データトランザクションの1つではない新しいデータまたはメディアタイプを追加する追加ステップをさらに含み,新しいコンジットを開始するとき,または,前記新しいメディアデータタイプを既存のコンジットに追加するときに,第1のユーザ端末により,セッション記述プロトコル(SDP)パラメータにおいて前記新しいデータまたはメディアタイプを記述する追加のパラメータを供給することにより,前記新しいデータまたはメディアタイプを追加する,
方法。
【請求項8】
請求項1に記載の方法であって,不要なリッチ通信サービス(RCS)アプリケーションからユーザ端末を守るステップであり,RCSサービスにアクセスするための有効な許可を各アプリケーションが持つことにより,ユーザ端末を守るステップをさらに備える,
方法。」

請求項5の「前記SDPパラメータ」について,請求項1には「SDPパラメータ」が記載されていないが,請求項5の「前記SDPパラメータ」の後に「セッション記述プロトコル(SDP)パラメータ」との記載があり,当初明細書の記載(【0005】等)との対応関係からみても,「前記」が後述の「セッション記述プロトコル(SDP)パラメータ」を指すことは明らかである
請求項5を引用する請求項6についても同様である。

第4 引用文献,引用発明
1.引用文献1について
原査定の拒絶の理由に引用された引用文献1には,図面とともに次の事項が記載されている。(下線は強調のため当審で付与した。)

ア 「[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] 図1Aはいくつかの実施形態におけるシステム100を例示する図である。システム100は,マルチメディアサービス配信ネットワークアーキテクチャ208を介して通信する第1端末装置202-1と第2端末装置202-2を備える。端末装置は,移動電話無線装置,セットトップボックス,タブレットコンピュータ,自動車ナビゲーション/娯楽システム,ゲームコンソール,パーソナルコンピュータ,またはこれらの組合せを備える。いくつかの実施形態では,ネットワークアーキテクチャ208はIMSアーキテクチャを備える。
[0021]第1および第2端末装置202-1,202-2はアプリケーション間(以下,A2A)通信用に構成されている。すなわち,第1装置202-1で動いているアプリケーションは,第2装置202-2で動いているアプリケーションと通信することができる。たとえば,マルチユーザA2A通信ゲームアプリケーションによれば,ゲームの音声や映像とともにゲームデータを交換することができ,ゲーム中にユーザがお互いに話したり見たりすることができる。別の例として,マルチメディアA2A通信メッセージングアプリケーションによれば,テキストによるチャット,写真/映像/音楽/ファイルの転送,ライブ映像の共有,グループチャット,位置の共有,またはあらゆる種類の双方向またはグループの通信を行うことができる。さらに別の例として,マルチプレーヤA2A通信ゲームアプリケーションによれば,短い待ち時間,2者以上の間でのピアツーピアのデータ交換,および/または音声・映像またはテキストによるチャットなどの他のマルチメディア機能を含むことができる。A2A通信を含むアプリケーションの他の例としては,統合通信アプリケーション,顧客ケアアプリケーション,社交/交際アプリケーション,企業アプリケーションが挙げられる。これらの例示されたA2A通信アプリケーションは,ピアツーピアのデータ交換やマルチメディアメッセージ交換(テキスト,映像,音声,写真,または他のマルチメディアタイプ)など,同様な機能を利用することができる。他のA2A通信アプリケーションは,音声/映像会議アプリケーションを含んでいてもよい。以下に詳細に説明されるように,装置はアプリケーションが他のアプリケーションとメディアデータを通信できる1以上のメディアセッションを確立する。
[0022]A2Aアプリケーションマネージャサーバ102は,A2A対応アプリケーション間のメディアセッションの確立中は制御パスに配置される。サーバ102は,A2Aアプリケーション間のメディア接続の承認を管理する。さらに詳細には,様々な異なるA2Aアプリケーションが様々な異なる端末装置で動いていてもよい。アプリケーションマネージャサーバ102は,端末装置で動くとともにA2A通信に対応可能なアプリケーション(以下,A2A対応アプリケーション)間のメディア接続の承認を管理する。
[0023]管理承認は,A2A対応アプリケーションを識別することを含む。また,管理承認は,他のA2A対応アプリケーションとの間でA2A通信を確立するために,表面上は識別されたA2A対応アプリケーションから受領した要求が,その要求を送信したとされるA2A対応アプリケーションによって実際に送信されたと確認することも含む。さらに,いくつかの実施形態では,管理承認は,要求内で特定されたユーザにアプリケーションが承認されるか否か判定するための1つ以上の規定を適用することを含む。
[0024]いくつかの実施形態では,アプリケーションマネージャサーバはアプリケーション登録インターフェース112を含み,A2A対応アプリケーションに関連付けられたアプリケーション識別子(AｐｐID)やアプリケーション秘密情報(アプリケーション秘密)などの非公開情報を指定するために使用するように,ウェブサーバ,データベース,遠隔プロセス,または分散クライアントや他のシステムに中央管理されたデータを利用可能にする他の手段として機能する。いくつかの実施形態では,開発者は,A2A対応アプリケーションを登録するために,アプリケーション登録インターフェース112を使用する。予備登録段階では,開発者は,アプリケーションをアプリケーションレジストリ104に登録する。AｐｐIDとアプリケーション秘密が返送されて,アプリケーションにインデックスを付ける。AｐｐIDは,メッセージ中のAｐｐIDとアプリケーションのAｐｐIDとの一致によってすべてのメッセージの経路を決めるために使用される。この登録は,一回限りのイベントであり,アプリケーション配備のために一回発生する。アプリケーション秘密は,動的にアプリケーショントークンを作成するために使用される。動的登録段階では,開発者は事前にアプリケーションを登録することはせず,複数のアプリケーションの動的な登録を可能にする開発者キーまたはトークンを有する。これは,プラットフォームで承認された「信任開発者」である。開発者キーは,動作中のアプリケーション登録中にパスし,バックエンドレジストリデータベース内の開発者キーのホワイトリストに対して確認される。それぞれの開発者キーには特性が関連付けられ,たとえば,動的登録または携帯電話会社により登録される個別のアプリケーションの数を制限する。他の特性も可能である。動的登録の間に,AｐｐIDおよびアプリケーション秘密を引き出すために,開発者キーはアプリケーションのスタートアップまたはインストールに進む。セッションの間またはプラットフォームにより定義される長い期間,アプリケーション秘密は有効となっている。
[0025](略)
[0026]AｐｐIDは,システム100内においてA2A対応アプリケーションを固有に識別する識別子である。言い換えれば,それぞれの異なる種類のA2Aアプリケーションは,自身の固有なAｐｐIDに関連付けられている。AｐｐIDは,異なる方法により生成することができ,異なるフォーマットを有することができる。異なるフォーマットには,数字の識別子(たとえば,1234),英数字の識別子(たとえば,acme?aｐｐlicaｔiｏn?1),ホスト/ドメイン/パッケージの名称(たとえば,cｏm.acme.ｘｙｚ)やランダムな値が含まれるがこれらには限定されない。

イ 「[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] 図2Aは,A2Aアプリケーション204-1,204-2の第1および第2インスタンス間の通信セッションの確立に含まれるシステム100の機器間の通信の複数の通信ステージS0-S5を示す。第1端末装置202-1と第2端末装置202-2間の通信の確立には,ネットワーク208を介して信号を送信することが含まれる。上述のように,SIPプロキシサーバ210は,招待端末機器から被招待端末機器にセッション招待案内を送るために使用される。図2Aの信号フローの例において,第1端末装置202-1を招待装置とし,第2端末装置202-2を被招待装置とする。セッションの確立には,他のメッセージ伝達が追加されてもよい。しかし,そのような追加可能なメッセージ伝達の詳細は,本発明において重要ではなく当業者には容易に理解されるものである。したがって,本明細書での説明は省略する。
[0046] ステージS0において,第2端末装置202-2のA2A対応アプリケーション204-2の第2インスタンスとのメディアセッションを確立するために,第1端末装置202-1のA2A対応アプリケーション204-1の第1インスタンスは装置202-1が要求212をA2A通信エンジン206-1の第1インスタンスに送信するように構成する。以下に詳細に説明するように,A2Aエンジン206-1とA2Aエンジン206-2はA2A対応アプリケーションインスタンス204-1,204-2,および各通信プロトコルスタックの間のインターフェースとして動作する。いくつかの実施形態では,要求212は,第1装置202-1で動いているA2A通信エンジン206-1の第1インスタンスへのメソッド呼出しを含む。いくつかの実施形態では,メソッド呼出しは,C,C++,Jaｖa,または他の一般的なプログラム言語またはスクリプト言語による手続き呼出しを含んでもよい。また,メソッド呼出しは,AIDL,RMI,CORBA,または他の仕組みを使用した別のプロセスに対する,パイプ,キュー,ソケット,または他の遠隔手続き呼出しなどの利用可能な仕組みを使用したメッセージを含んでもよい。
[0047] 図3は,メソッド呼出し要求212の例のデータ構成内のフィールドを例示する図である。SIPユーアールアイ(URI)フィールドは,被招待装置202-2を特定する。AｐｐIDフィールドは,要求アプリケーションを特定する。構成によっては,セキュリティ情報フィールドは,セキュリティのために使用されるトークン情報やトークンを生成するために使用される秘密情報を含んでもよい。また,発せられた要求は,たとえば,音声,映像,ファイル転送,チャット,グループチャット,リアルタイムピアツーピアデータ転送,アプリケーション配置などの1種類以上のメディアを含む,要求されたメディアセッションなどの追加情報を含んでもよい。
[0048] ステージS1において,A2A通信エンジン206-1の第1インスタンスは,要求212を端末ネットワーク208内でSIPプロキシサーバ210への送信に適したSIP招待メッセージ214に変換するインターフェースとして動作するように,第1端末装置202-1を構成する。上述のように,実際の送信は,たとえば,いくつかの異なるプロキシ間の往来,また場合によっては,ネットワーク208内のレジストラサーバ(不図示)やリダイレクトサーバ(不図示)の使用を含んでもよい。SIPメッセージ214の例は,第1識別子(たとえば,第1SIP-URI)を有する第1端末装置から第2識別子(たとえば,第2SIP-URI)を有する第2端末装置への招待を含む。
[0049] 図4は,SIPメッセージ214の例の構成内のヘッダフィールドを例示する図である。「発信元」および「宛先」のアドレスフィールドは,それぞれ第1SIP-URIおよび第2SIP-URIを示す。サービスタグのフィールドは,通信タイプを「Aｐｐ2Aｐｐ(すなわち,アプリケーション間)」として示す。AｐｐIDフィールドは,通信セッションを介してアプリケーションの固有なタイプを特定し追跡するパラメータとして動作するグローバルに固有な識別子を提供する。いくつかの実施形態では,オプションセキュリティ情報フィールドは,メッセージを認証するために使用されるセキュリティトークンを含む。SDPフィールドは,セッション中のネゴシエーションメディア送信に使用される情報を提供する。この例では,メディアは,たとえばH264フォーマットを使用し特定のビットレート(不図示)を有する映像メディアを含む。
[0050] ステージS2において,メッセージがAｐｐIDに関連付けられたA2A対応アプリケーションによる要求を含むことを示すサービスタグに応じて,SIPプロキシサーバ210はメディアセッション要求を評価するA2Aアプリケーションマネージャ102にメッセージ216を送信する。さらに詳しくは,いくつかの実施形態では,サービスタグは,プロキシサーバ210に対する,要求を第2端末装置202-2に転送する前に承認要求216をアプリケーションマネージャサーバ102に送信する命令として動作する。このように,要求214には,要求216を生成する命令が埋め込まれている。いくつかの実施形態では,メッセージ216は,図4に示され参照して説明されるヘッダ情報を含む。たとえば,特定の装置やユーザに対する,セキュリティ情報の確認,使用統計の生成,メディアセッション課金のトリガー,またはセキュリティエラーまたはAｐｐIDのブラックリストによりメディアセッション要求が拒絶されるべきか否かの判定などの1つ以上の機能を実行するために,メッセージ216に応じて,A2Aアプリケーションマネージャ102は,図1Bから図1Eにより説明した第1および第2のプロセスを実行する。A2A対応メッセージを示すサービスタグが実質的に含まれることにより,プロキシサーバ210がメディア接続を確立するためにアプリケーションマネージャに対して承認を要求することになる。このように,第2端末装置202-2で動いているA2A対応アプリケーション204-2の第2インスタンスとのメディア接続を確立する要求と,アプリケーションマネージャサーバ102に対するSIPメッセージに含まれたAｐｐIDを有するA2Aアプリケーションの承認の要求とが,両者ともSIP招待214に埋め込まれている。
[0051] ステージS3において,メッセージ216および上述のA2Aアプリケーションマネージャ動作の完了に応じて,A2Aアプリケーションマネージャ102は,要求されたサービス,A2Aサービス,およびAｐｐIDの端末装置202-1,202-2に対する送受信を特定するとともに要求されたメディアセッションが受諾されるべきか拒絶されるべきかを示すメッセージ218を,プロキシサーバ210に送信する。いくつかの実施形態では,A2Aアプリケーションマネージャ102は,承認と判定されるSIPメッセージ/要求をネットワーク208を介して第2端末装置202-2に転送する。要求が拒絶された場合には,A2Aアプリケーションマネージャ102は,要求を発した第1端末装置202-1に拒絶通知を送信する。ステージS4において,プロキシサーバ210は,図4の構成中の情報を含むメッセージ220を第2端末装置202-2で動いているA2A通信エンジン206-2の第2インスタンスに送信する。A2A通信エンジン206-2は,メッセージ220中のAｐｐIDに対応するアプリケーションのインスタンスが第2端末装置202-2にインストール済で動いているかどうかを判定する。いくつかの実施形態では,アプリケーション204-2のインスタンスがすでにインストール済であるが動いていない場合には,A2A通信エンジン206-2はアプリケーションを起動する。
[0052] アプリケーション204-2のインスタンスがインストールされていない場合,一般的には,A2A通信エンジン206-2は,端末装置202-2が要求されたアプリケーション204-2のインスタンスをインストールしたか否かについての事前情報を得ることになる。しかし,いくつかの実施形態では,アプリケーションがインストールされていない場合には,A2A通信エンジン206-2は自動的に招待を拒絶する。また,いくつかの実施形態では,A2A通信エンジン206-2は,第2端末装置202-2に対して,失敗した招待のAｐｐIDを使用して,不足しているアプリケーションのダウンロードリンクなどのメタデータが得られるアプリケーションレジストリ104でアプリケーションを検索して,不足しているアプリケーションをダウンロードするように促す。いくつかの実施形態では,第2端末装置202-2のユーザインターフェースが,装置のユーザに対して失敗した招待を示し,不足しているアプリケーションの取得方法についての情報を提供する。たとえば,「「abc」という名称(AｐｐIDとは異なってもよい)のアプリケーションの実施の招待/申込みに失敗しました。ここをクリックしてダウンロードしてください。」のようなメッセージが提供されてもよい。
[0053] ステージS5において,アプリケーションがインストール済で動いている(起動している)と仮定すると,A2A通信エンジン206-2は,図4の構成内の情報を含むメッセージ222を第2端末装置202-2で動いているアプリケーション204-2の第2インスタンスに送信する。いくつかの実施形態では,第2端末装置のプラットフォームおよび/またはプログラム言語によっては,メッセージ222は,たとえば,コールバック/イベント装置,手続き呼出し,またはプロセス間通信のための他のプラットフォームに特定の手段(たとえば,アンドロイドプラットフォームの「インテント」)を介して配信されてもよい。一般的には,いくつかの実施形態では,メッセージはSIPプロトコルレベルで認識される(ACKおよびOKメッセージ)。適用可能な場合には,タイムアウトもメッセージに関連付けられる(たとえば,INVITE)。SIPプロトコルによって,たとえば,「VIA」ヘッダが,招待端末装置202-1にたどり着くために往来するネットワークノードを示すために使用されてもよい。タイムアウトの場合には,被招待装置202-2による積極的な招待拒絶とは対照的に,招待装置202-1は,被招待装置202-2が招待の受諾に失敗したと認識する。
[0054] 図2Bは,いくつかの実施形態における代替システム160の例示的な図である。代替システム160の機器は,図1Aから図2Aを用いて説明したものと実質的に同一である。以下,システム100とシステム160の違いを説明する。具体的には,A2Aエンジン206-1’は,現在承認済のA2A対応アプリケーションのAｐｐIDの表示を周期的に要求するように構成される。具体的には,A2Aエンジン206-1’は,装置202-1’の現在登録済のアプリケーションのAｐｐID承認を周期的に要求する。A2Aエンジン206-1’は,承認済A2A対応アプリケーションを示すローカル端末装置アプリケーションレジストリ162を維持する。関連付けられたAｐｐIDを有するA2A対応アプリケーションからの,メディアセッション確立の要求に応じて,A2Aエンジンが,レジストリ162の内容に基づいてA2A対応アプリケーション204-1’がそのAｐｐIDに基づいて承認されるか否かを決定する。このように,図2の信号フローにおけるステージS2とS3を回避することができる。第1端末装置202-1’は,ネットワーク(不図示)を介してSIP招待164を送信することができる。また,第2端末装置202-2’は,通信セッション確立の過程でマネージャ102に問い合わせる必要なしに,ネットワークを介してSIP応答166を送信ことができる。
[0055] 図5は,メディア通信の初期化が成功し,第1および第2の端末装置201-1,202-2の間でメディアデータを送信するために通信プロトコルスタック530-1,530-2が使用される,図2Aのシステム100の例示的な図である。通信プロトコルスタック530-1,530-2はいずれも階層プロトコルスタックである。一般的に,ネットワークプロトコルは,ネットワーク機能が層に分割されるように階層化されている。プロトコルスタックにおいて,各層は,下層のサービスに依存する明確なサービスを実行し,上層にサービスを提供する。一般に,通信プロトコルは,スタック内の1つの層で通信サービスを提供するソフトウェアシステムを規定するために使用される。結果として生じる階層化プロトコルは,プロトコルスタックと呼ばれる。プロトコルスタックは,複数のプロトコルを含むネットワーク機能を規定する。さらに詳細には,プロトコルスタック層は,持続性媒体にコード化された命令を有し,端末装置202-1,202-2およびネットワーク208の機器にプロトコル層によって規定されたネットワーク機構を実行させる。
[0056] ワークアーキテクチャに準拠する。IMSプロトコルスタックは,異なる標準またはRFC(コメント要求)によって規定された異なるプロトコルを異なる層に有している。IMSネットワークアーキテクチャにおいて,典型的には,SIPは,RTP(リアルタイム転送プロトコル)とSDP(セッション記述プロトコル)を含んで,IMS準拠の通信プロトコルスタックの一部である他のいくつかのプロトコルと連動して使用される。典型的には,RTPは,リアルタイムマルチメディアデータ(たとえば,音声,映像共有,チャット,ファイル共有,XMPP準拠プロトコルおよび拡張(たとえば,IPを介した音声サービスのジングル),およびその他ピアツーピアリアルタイム通信の仕組み)をコード化してパケットに分割し,パケットをインターネットを介して転送するように使用される。典型的には,SDPは,セッション参加メンバーの能力を記述しコード化するように使用される。このような記述は,メディアをコード化するコーデックや使用する転送プロトコルなど,セッションの特徴を取り決めるために使用できる。その結果,すべての装置がセッションに参加できるようになる。もちろん,異なる特定の使用のために異なるプロトコルのオプションを使用することをIMSネットワークアーキテクチャが指定してもよい。
[0057] 図5は,図2Aの通信プロトコルに従ってセッションの初期化成功後に第1および第2の端末装置202-1,202-2の間に1つ以上の通信セッション532が確立されていることを示す。また,図5は,通信セッション532が同一のプロトコルスタックインスタンス530-1,530-2によって特定されたプロトコルに従ってネットワーク208を介してデータを転送することも示す。以下の詳細に説明するように,A2Aエンジンインスタンス206-1,206-2は,インターフェースとして動作し,(1)A2A対応アプリケーションインスタンス204-1,204-2から受信したメソッド呼出し要求やメッセージを,ネットワーク208で使用可能な形式に変換し,(2)ネットワーク208から受信したネットワークパケットやフレームをA2A対応アプリケーションインスタンス204-1,204-2が使用可能な形式に変換し,(3)各アプリケーションインスタンス204-1,204-2およびプロトコルスタックインスタンス530-1,530-2の間のセッション532中に,制御データとメディアデータをネットワーク208を介して送信する。)

ウ 「[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] 図示された例においては,各端末装置では単一のA2A対応アプリケーションのみが動いている。しかし,当然ながら,各端末装置で複数のA2A対応アプリケーションが動くことも可能である。各A2A対応アプリケーションは,固有のAｐｐIDを有している。A2Aエンジンは,通信スタックからAｐｐIDに基づいて異なるA2A対応アプリケーション制御メッセージを送信する。また,単一の制御セッションにより複数の異なるA2A対応アプリケーションのためのメディアセッションが制御可能であることも理解される。それぞれの異なるA2A対応アプリケーションのために,制御セッションがそのA2A対応アプリケーション専用の1つ以上のメディアセッションを確立する。制御セッションを介して通信された情報のフレームまたはパケットは,フレームまたはパケット内に含まれたAｐｐIDに基づいて異なるA2A対応アプリケーションに送信される。さらに,本明細書における例では,同一のAｐｐIDを有する2つのA2Aアプリケーション間での通信について説明しているが,異なるAｐｐIDを有する2つのA2A対応アプリケーション間で通信を確立してもよい。)

上記アより,引用文献1のFIG.1Aに記載されたシステム100は,アプリケーション間通信(以下,「A2A」という。)用に構成された第1端末装置202-1および第2端末装置202-2と,端末装置で動くとともにA2A通信に対応可能なアプリケーション(以下,「A2A対応アプリケーション」という。)間のメディア接続の承認を管理するアプリケーションマネージャサーバ102とを備えている。そして,具体的には,上記イより前記端末装置間において,FIG.2A-1ないしFIG.2A-4の通信ステージS0ないしS5により,通信セッションが確立するものであるところ,前記第1の端末装置は,通信ステージS0,S1,図4に関連して,ヘッダーのAｐｐIPフィールドにA2A対応アプリケーションを固有に識別する識別子であるAｐｐIDを示したSIPメッセージを構成し,前記第2の端末装置は,通信ステージS4,S5,図4に関連して,前記SIPメッセージのAｐｐIDに対応するA2A対応アプリケーションが起動していると前記SIPメッセージが認識され(ACKおよびOKメッセージ)て,前記A2A対応アプリケーションに関連付けされたセッションが確立するものである。
さらに,上記ウより,引用文献1には,各端末装置で複数のA2A対応アプリケーションが動くことも可能であり,この場合,単一の制御セッションにより複数の異なるA2A対応アプリケーションのためのメディアセッションが制御可能であり,制御セッションを介して通信された情報のフレームまたはパケットは,フレームまたはパケット内に含まれたAｐｐIDに基づいて異なるA2A対応アプリケーションに送信されることが記載されている。
ここで,単一の制御セッションを用いる前記複数の異なるA2A対応アプリケーションを,そのセッションの開始順に「第1のA2A対応アプリケーション」,「第2のA2A対応アプリケーション」,・・・と称することは任意であり,この場合,「第2のA2A対応アプリケーション」とSIPメッセージとを関連付ける時点で,すでに「第1のA2A対応アプリケーション」は,第1および第2の端末装置で起動されている,すなわち「共有されていること」は明らかであり,第1の端末装置は,「第1のA2A対応アプリケーション」で使用する「制御セッション」を,「第2のA2A対応アプリケーション」でも使用するようにSIPメッセージを構成すること,及び第2の端末装置は,前記AｐｐIDにより,前記「制御セッション」を使用するため当該「SIPメッセージ」を「第2のA2A対応アプリケーション」に関連付けることは,明らかである。
また,引用文献1の「方法」の各手順を「?ステップ」と称することは任意である。
以上を総合すると,引用文献1には,「SIPメッセージを第2のA2A対応アプリケーションと関連付ける方法」について,次の発明(以下,「引用発明」という。)が記載されていると認める。

「第1の端末装置と第2の端末装置で第1のA2A対応アプリケーションを共有しているとき,SIPメッセージを第2のA2Aアプリケーションと関連付ける方法であって,
第1の端末装置によって,前記第1のA2A対応アプリケーションと同じ制御セッションを前記第2のA2Aアプリケーションにも使用するため,ヘッダーのAｐｐIPフィールドに前記第2のA2A対応アプリケーションを固有に識別する識別子であるAｐｐIDを示したSIPメッセージを構成するステップと,
第2の端末装置によって,前記AｐｐIDにより,前記制御セッションを使用するため当該SIPメッセージを第2のA2A対応アプリケーションに関連付けるステップと,
単一の制御セッションを用いる複数の異なるA2A対応アプリケーションがあるとき,第1の端末装置によって,ヘッダーのAｐｐIPフィールドに前記第2のA2A対応アプリケーションを固有に識別する識別子であるAｐｐIDを示したSIPメッセージを構成するステップと,を含む,
方法。」

第5 対比・判断
1.本願発明1について
(1)対比
本願発明1と引用発明とを技術常識を踏まえて対比する。
a 引用発明の「第1の端末装置」,「第2の端末装置」,「第1のA2A対応アプリケーション」及び「第2のA2A対応アプリケーション」は,それぞれ本願発明1の「第1のユーザ端末」,「第2のユーザ端末」,「第1のアプリケーション」及び「第2のアプリケーション」に相当する。
b 引用発明の「SIPメッセージ」は,本願発明1の「セッション・イニシエーション・プロトコル(SIP)メッセージ」及び「SIPメッセージ」と同義である。
c そうすると,引用発明の「第1の端末装置と第2の端末装置で第1のA2A対応アプリケーションを共有しているとき,SIPメッセージを第2のA2Aアプリケーションと関連付ける方法」は,以下の各相違点を除き,本願発明1の「異なるユーザ端末間で第1のアプリケーションを共有しているときに,セッション・イニシエーション・プロトコル(SIP)メッセージを,前記異なるユーザ端末上で実行される第2のアプリケーションと関連付ける方法」に相当する。
d 本願発明1の「SIPセッションにタグ付けする」ことは,本願明細書【0095】より,SIPヘッダの既存の要素を修正すること,SIPヘッダに新しい要素を追加することを含むから,引用発明の「ヘッダーのAｐｐIPフィールドに前記第2のA2A対応アプリケーションを固有に識別する識別子であるAｐｐIDを示したSIPメッセージを構成する」ことは,「SIPセッションにタグ付けする」ことに含まれ,引用発明の「AｐｐID」は,本願発明1の「タグ」に含まれる。そうすると,引用発明の「第1の端末装置によって,前記第1のA2A対応アプリケーションと同じ制御セッションを前記第2のA2Aアプリケーションにも使用するため,ヘッダーのAｐｐIPフィールドに前記第2のA2A対応アプリケーションを固有に識別する識別子であるAｐｐIDを示したSIPメッセージを構成するステップ」は,本願発明1の「第1のユーザ端末によって,第1のアプリケーションに使用されたSIPセッションを第2のアプリケーションに関連付けるように前記SIPセッションにタグ付けするタグ付けステップ」に含まれるといえる。
e 上記dより,引用発明の「第2の端末装置によって,前記AｐｐIDにより,前記制御セッションを使用するため当該SIPメッセージを第2のA2A対応アプリケーションに関連付けるステップ」は,本願発明1の「第2のユーザ端末によって,前記タグに従って,前記SIPセッションのためのSIPメッセージを第2のアプリケーションに関連付ける関連付けステップ」に含まれるといえる。
f 引用発明の「単一の制御セッションを用いる複数の異なるA2A対応アプリケーションがあるとき,第1の端末装置によって,ヘッダーのAｐｐIPフィールドに前記第2のA2A対応アプリケーションを固有に識別する識別子であるAｐｐIDを示したSIPメッセージを構成するステップ」は,SIPメッセージにおいて第2のA2A対応アプリケーションとをマッチングすることに含まれるから,本願発明1の「ユーザ端末間で同じSIP接続を共有する複数のアプリケーションがあるとき,第1のユーザ端末によって,複数のアプリケーション間の通信を管理するコンジットマネージャを活用して,SIPセッションと第2アプリケーションとをマッチングする,活用ステップ」とは,下記相違点1を除き,「ユーザ端末間で同じSIP接続を共有する複数のアプリケーションがあるとき,第1のユーザ端末によって,SIPセッションと第2アプリケーションとをマッチングする,ステップ」である点で,共通する。
以上を総合すると,本願発明1と引用発明とは以下の点で一致し,また相違する。

＜一致点＞
「異なるユーザ端末間で第1のアプリケーションを共有しているときに,セッション・イニシエーション・プロトコル(SIP)メッセージを,前記異なるユーザ端末上で実行される第2のアプリケーションと関連付ける方法であって,
第1のユーザ端末によって,第1のアプリケーションに使用されたSIPセッションを第2のアプリケーションに関連付けるように前記SIPセッションにタグ付けするタグ付けステップと,
第2のユーザ端末によって,前記タグに従って,前記SIPセッションのためのSIPメッセージを第2のアプリケーションに関連付ける関連付けステップと,
ユーザ端末間で同じSIP接続を共有する複数のアプリケーションがあるとき,第1のユーザ端末によって,SIPセッションと第2のアプリケーションとをマッチングする,ステップと,を含む
方法。」

＜相違点1＞
一致点である「ユーザ端末間で同じSIP接続を共有する複数のアプリケーションがあるとき,第1のユーザ端末によって,SIPセッションと第2のアプリケーションとをマッチングする,ステップ」について,本願発明1では,「複数のアプリケーション間の通信を管理するコンジットマネージャを活用」している「活用ステップ」であるのに対し,引用発明ではこのような限定がない点。

＜相違点2＞
本願発明1では,「レガシー・リッチ・通信サービス(RCS)アプリケーションを修正する修正ステップであり,第2のユーザ端末によって,前記SIPメッセージが前記レガシーRCSアプリケーションを意図するか否かを判定するために各SIPセッションをチェックするSIPセッションマネージャを第2のユーザ端末に追加し,そして,前記SIPセッションマネージャが,前記レガシーRCSアプリケーションを意図する前記SIPメッセージを当該レガシーRCSアプリケーションにルーティングし,且つすべての残りのSIPメッセージを前記コンジットマネージャにルーティングすることにより,前記レガシーRCSアプリケーションを修正する修正ステップ」を含むのに対し,引用発明では,当該「修正ステップ」を含むことが記載されていない点。

(2)判断
事案に鑑み,まず相違点2について検討する。
本願発明1は,(コンジットを使用しない)レガシーRCS及びSIPアプリケーションがコンジットをサポートするアプリケーションと相互運用すること(明細書【0073】)を課題として,相違点2に係る構成を有することで,既存のRCSアプリケーションは,いかなる変更もなく動作し続けることができ,新しいアプリケーションは,レガシーアプリケーションと同じSIPスタックと登録を共有することが許されるという効果(明細書【0078】)を奏するものである。
一方,引用文献1には,上記課題について記載も示唆もされておらず,また,相違点2に係る構成は自明なものでもないので,当該構成は,引用発明から容易に想到し得たとはいえない。

(3)小括
したがって,相違点1について検討するまでもなく,本願発明1は,引用発明と同一ではなく,引用発明に基づいて当業者が容易に発明することができたものでもない。

2.本願発明2-7について
本願発明2-7は,本願発明1の構成を全て含みさらに他の構成で特定した発明であるから,本願発明1と同様の理由により,引用発明と同一ではなく,引用発明に基づいて当業者が容易に発明できたものでもない。

第6 最後の拒絶理由について
1.特許法第36条第6項第2号について
平成28年8月24日付けの最後の拒絶理由の概要は,以下のとおりである。
「請求項5には,「SIPセッションの前記SDPパラメータを…」と記載されているが,この記載以前に,「SDPパラメータ」についての記載がないため,「前記」が何を指すものであるのか不明確である。
請求項5を引用する請求項6についても同様である。」

そこで検討するに,請求項5の「前記SDPパラメータ」について,請求項1には「SDPパラメータ」が記載されていないが,請求項5の「前記SDPパラメータ」の後に「セッション記述プロトコル(SDP)パラメータ」との記載があり,当初明細書の記載(【0005】等)との対応関係からみても,「前記」が後述の「セッション記述プロトコル(SDP)パラメータ」を指すことは明らかである
そうすると,「SDPパラメータ」は記載上では「前記」されていないものの,当該記載があることで請求項5に係る発明が不明確であるとまではいえない。
請求項5を引用する請求項6についても同様である。

第7 むすび
以上のとおり,本願発明1-7は,引用発明と同一ではなく,当業者が引用発明に基づいて容易に発明をすることができたものでもない。したがって,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2017-07-25 
出願番号 特願2014-180306(P2014-180306)
審決分類 P 1 8・ 121- WY (H04M)
P 1 8・ 113- WY (H04M)
最終処分 成立  
前審関与審査官 永井 啓司  
特許庁審判長 大塚 良平
特許庁審判官 吉田 隆之
中野 浩昌
発明の名称 アプリケーションインターフェイスを将来のアプリケーション用に拡張するための方法  
代理人 伊東 忠彦  
代理人 大貫 進介  
代理人 伊東 忠重  

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