【事件の表示】
　特願２０１３−５１３１１７「リモートユーザインターフェース連携アプリケーション」拒絶査定不服審判事件〔平成２３年１２月　８日国際公開、ＷＯ２０１１／１５２６８４、平成２５年　８月１５日国内公表、特表２０１３−５３２３２７、請求項の数（１９）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、２０１１年６月３日（優先権主張　２０１０年６月４日、米国）を国際出願日とする出願であって、平成２５年１１月２１日付けで拒絶理由が通知され、平成２６年２月２６日付けで手続補正がされ、同年７月１１日付けで拒絶理由が通知され、同年１０月２２日付けで手続補正がされ、平成２７年２月２６日付けで拒絶査定がなされ、これに対して、同年７月１日に拒絶査定不服審判が請求されるとともに手続補正がされたものである。
　
第２　平成２７年７月１日付けの手続補正（以下、「本件補正」という。）の適否
１．補正の内容
　本件補正は、補正前の特許請求の範囲の請求項１を、補正後の特許請求の範囲の請求項１に変更する補正事項（以下、「補正事項１」という。）を含むものである。
　そして、補正前の請求項１及び補正後の請求項１の各記載は、それぞれ、以下のとおりである。
　なお、〈補正後の特許請求の範囲〉における下線は補正箇所を表している。
〈補正前の特許請求の範囲〉
　「【請求項１】
　リモートユーザインターフェース（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ：ＵＩ）クライアントを操作する方法であって、
　ＵＩサーバとの第１の接続を設定するステップと、
　前記第１の接続を通じて、ユーザインターフェースを操作する方法に関する第１の命令と前記ＵＩサーバと持続的な接続を設定するための第２の命令とを含む文書を受信するステップと、
　前記第１の接続を終了するステップと、
　前記文書を実行するステップと、
　前記第２の命令に基づいて前記第１の接続を終了した状態で前記ＵＩサーバとの持続的な新たな接続である第２の接続を設定するステップと、
　前記第２の接続を設定するステップにおいて、前記ＵＩクライアントが前記ＵＩサーバに前記ＵＩクライアントの能力を伝送した場合、前記ＵＩサーバから前記ユーザインターフェースを操作する方法に対する前記第１の命令の修正を受信するステップと、を含む
　ことを特徴とする方法。」
〈補正後の特許請求の範囲〉
「【請求項１】
　リモートユーザインターフェース（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ：ＵＩ）クライアントを操作する方法であって、
　ＵＩサーバとの第１の接続を設定するステップと、
　前記第１の接続を通じて、ユーザインターフェースを操作する方法に関する第１の命令と前記ＵＩサーバと持続的な接続を設定するための第２の命令とを含む文書を受信するステップと、
　前記第１の接続を終了するステップと、
　前記文書を実行するステップと、
　前記第２の命令に基づいて前記第１の接続を終了した状態で前記ＵＩサーバとの持続的な新たな接続である第２の接続を設定するステップと、
　前記第２の接続を設定するステップにおいて、前記ＵＩクライアントが前記ＵＩサーバに前記ＵＩクライアントの能力を伝送した場合、前記ＵＩサーバから前記ユーザインターフェースを操作する方法に対する前記第１の命令の修正を受信するステップと、を含
み、
　前記第１の命令の修正は、前記ＵＩクライアントのＵＩ状態更新を実行する主体を前記ＵＩサーバと前記ＵＩクライアントのうちで選択可能な複数のオプションを含む
　ことを特徴とする方法。」
２．補正の適否
　本件補正の内の補正事項１は、請求項１に記載した発明を特定するために必要な事項である、「第１の命令の修正」について、「前記ＵＩクライアントのＵＩ状態更新を実行する主体を前記ＵＩサーバと前記ＵＩクライアントのうちで選択可能な複数のオプションを含む」ものとの限定を付加するものであって、補正前の請求項１に記載された発明と補正後の請求項１に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから、特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　また、特許法第１７条の２第３項、第４項に違反するところはない。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について、以下に検討する。
（１）引用例の記載事項と引用例記載の発明
　原査定で引用された、米国特許出願公開第２００５／００８６３４４号明細書（以下、「引用例１」という。）のABSTRACT,［0039］〜［0043］,［0058］〜［0059］，［0074］〜［0081］の記載によれば、引用例１には以下の発明（以下、「引用例１記載の発明」という。）が記載されている。
「クライアント・ベースのアプリケーションは、要求をサーバー・アプリケーションに送り、
　サーバー・アプリケーションは要求を処理し、そして、サーバー・アプリケーションに接続するための命令を含む応答を送信し、
　クライアント・アプリケーションは応答を処理し、そして、サーバー・アプリケーションとの持続的な接続を樹立するために含まれた命令を利用する、
　無制限で、対称形のリモート・スクリプトに対して提供される方法であり、
　クライアント（１０）は、usrsExecuteにコールするジャバスクリプト（１２）を実行し、それは、「data transfer」スクリプト（１２）のＳＲＣアトリビュートを正しい サーバー URLにセットし、
　「data transfer」スクリプト（１２）は、要求（HTTP GETを使う）をサーバー（２０）のダイナミック・サーバー・ページ（２１）に送信し、
　ダイナミック・サーバー・ページ（２１）は、クライアントの要求を処理し、そして、ジャバスクリプトコードとしてフォーマット化された「data script」（１２）応答を返し、
　クライアント（１０）は、サーバー（２０）の応答を受けるとただちに、それを新しいクライアント側スクリプトとしてすぐに処理し、
　サーバー（２０）の応答は、クライアント（１０）の新しい「data transfer」（１２）スクリプトとして動作するジャバスクリプトコードを含み、
　サーバー（２０）の応答は、サーバー・データ、サーバーにより生成されたジャバスクリプト関数とコール、そして、クライアント側「code」（１１）スクリプト中で、ある程度保留され続け、または、新しく処理され続ける、コールバック関数に対するコールを伴うジャバスクリプト変数の必要とされる如何なる組合せも含む得るものであり、
　リモート・スクリプトによる、データ表示のアプリケーションでの例では、
　複雑で安全な画像表示とUI（ユーザ・インタフェース）をクライアントに生成、そして送信し、
　これは、クライアント側ＤＯＭプロパティ、メソッド、及び／又は、クライアント（ブラウザ）ページ内の如何なるものも、直接セットし、生成し、及び／又は置換するイベントハンドラを用いることにより達成され、
　サーバーからクライアントに返される応答が、新しいクライアント側コード（例えば、上述の具体例の「dual script」）としてすぐに実行されるので、サーバーの応答は、クライアント・ディスプレイを修正するためにクライアントＤＯＭツリーを直接追加するＤＯＭコールを含む必要が単にあるのみであり、
　一般に、サーバーの応答は、以下の動作のいずれか一つを直接（そしてリアルタイムに）実行する命令を含むことができ、
　動作は、
　クライアントＤＯＭツリーに新しい要素を追加する
　ＤＯＭ要素アトリビュートを修正する
　ＤＯＭ要素コンテントを修正する
　ＤＯＭツリーを再構成する
　ことであり、
　リアルタイムでクライアントのＤＯＭを直接再構成そして追加する能力は、とても動的で、インタラクティブで、そして安全なビジュアル・クライアント（ブラウザ）ユーザ・インターフェースを生成させる
　リモート・スクリプトに対して提供される方法。」
（２）対比
　本願補正発明と引用例１記載の発明とを対比する。
ア．引用例１記載の発明の「リモート・スクリプトに対して提供される方法」は「複雑で安全な画像表示とUI（ユーザ・インタフェース）をクライアントに生成」するものであるから、本願補正発明の「リモートユーザインターフェース（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ：ＵＩ）クライアントを操作する方法」といい得るものである。
イ．引用例１記載の発明は、「クライアント・ベースのアプリケーションは、要求をサーバー・アプリケーションに送」るものであり、当該要求を送るためにクライアントとサーバーが接続されるのは明らかであるから、引用例１記載の発明は、本願補正発明の「ＵＩサーバとの第１の接続を設定するステップ」を有するものといえる。
ウ．引用例１記載の発明は、クライアントからサーバーへ送られた上記要求に対して、「サーバー・アプリケーションは要求を処理し、そして、サーバー・アプリケーションに接続するための命令を含む応答を送信し、」「クライアント・アプリケーションは応答を処理し、そして、サーバー・アプリケーションとの持続的な接続を樹立するために含まれた命令を利用する」ものであり、当該サーバー・アプリケーションから送信される応答は「クライアント（１０）の新しい「data transfer」（１２）スクリプトとして動作するジャバスクリプトコードを含」むものであるから、本願補正発明の「前記第１の接続を通じて、ユーザインターフェースを操作する方法に関する第１の命令と前記ＵＩサーバと持続的な接続を設定するための第２の命令とを含む文書を受信するステップ」と「前記第１の接続を通じて、前記ＵＩサーバと持続的な接続を設定するための第２の命令を含む情報を受信するステップ」を有する点で一致するといえる。
エ．引用例１記載の発明の上記「クライアント・ベースのアプリケーションは、要求をサーバー・アプリケーションに送」ることは、「要求（HTTP GETを使う）をサーバー（２０）のダイナミック・サーバー・ページ（２１）に送信」することにより行われているから、引用例１記載の発明は、上記要求に対する応答を受信すると接続を終了するものであり、本願補正発明の「前記第１の接続を終了するステップ」を有するものといえる。
オ．引用例１記載の発明は、「クライアント・アプリケーションは応答を処理し、そして、サーバー・アプリケーションとの持続的な接続を樹立するために含まれた命令を利用する」ものであり、当該利用は、「クライアント（１０）はサーバー（２０）の応答を受けるとただちに、クライアント（１０）は、それを新しいクライアント側スクリプトとしてすぐに処理し」、「サーバー（２０）の応答は、クライアント（１０）の新しい「data transfer」（１２）スクリプトとして動作するジャバスクリプトコードを含」むものであるから、引用例１記載の発明の上記利用することは、本願補正発明の「前記文書を実行するステップ」と「前記情報を実行するステップ」である点で一致するステップ及び「前記第２の命令に基づいて前記第１の接続を終了した状態で前記ＵＩサーバとの持続的な新たな接続である第２の接続を設定するステップ」に相当するといえる。
カ．引用例１記載の発明は、「サーバーからクライアントに返される応答が、新しいクライアント側コード（例えば、上述の具体例の「dual script」）としてすぐに実行され」、「サーバーの応答は、クライアント・ディスプレイを修正」し、「とても動的で、インタラクティブで、そして安全なビジュアル・クライアント（ブラウザ）ユーザ・インターフェースを生成させる」ものであることは、本願補正発明の「前記第２の接続を設定するステップにおいて、前記ＵＩクライアントが前記ＵＩサーバに前記ＵＩクライアントの能力を伝送した場合、前記ＵＩサーバから前記ユーザインターフェースを操作する方法に対する前記第１の命令の修正を受信するステップ」と「前記第２の接続を設定するステップにおいて、前記ＵＩサーバからユーザインターフェースを操作する方法に対する修正を受信するステップ」といい得る点で一致する。
　したがって、両者は以下の一致点と相違点を有する。
〈一致点〉
「リモートユーザインターフェース（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ：ＵＩ）クライアントを操作する方法であって、
　ＵＩサーバとの第１の接続を設定するステップと、
　前記第１の接続を通じて、前記ＵＩサーバと持続的な接続を設定するための第２の命令を含む情報を受信するステップと、
　前記第１の接続を終了するステップと、
　前記情報を実行するステップと、
　前記第２の命令に基づいて前記第１の接続を終了した状態で前記ＵＩサーバとの持続的な新たな接続である第２の接続を設定するステップと、
　前記第２の接続を設定するステップにおいて、前記ＵＩサーバからユーザインターフェースを操作する方法に対する修正を受信するステップと、を含む
　方法。」
〈相違点１〉
　本願補正発明は、「第１の接続を通じて、ユーザインターフェースを操作する方法に関する第１の命令と前記ＵＩサーバと持続的な接続を設定するための第２の命令とを含む文書を受信する」ものであるのに対し、引用例１記載の発明は、「第１の接続」を通じて「ユーザインターフェースを操作する方法に関する第１の命令」と「第２の命令」とを含む「文書」を受信するとはされていない点。
〈相違点２〉
　本願補正発明は、「前記ＵＩクライアントが前記ＵＩサーバに前記ＵＩクライアントの能力を伝送した場合、前記ＵＩサーバから前記ユーザインターフェースを操作する方法に対する前記第１の命令の修正を受信する」ものであるのに対して、引用例１記載の発明は、「サーバーの応答」により「クライアント・ディスプレイを修正」し、「とても動的で、インタラクティブで、そして安全なビジュアル・クライアント（ブラウザ）ユーザ・インターフェースを生成させる」ものであるが、「クライアント」が「クライアントの能力を伝送」するものではなく、また、「第１の接続」を通じて受信される「ユーザインターフェースを操作する方法に対する第１の命令」の修正を受信するものではない点。
〈相違点３〉
　本願補正発明は、「第１の命令の修正は、前記ＵＩクライアントのＵＩ状態更新を実行する主体を前記ＵＩサーバと前記ＵＩクライアントのうちで選択可能な複数のオプションを含む」ものであるのに対し、引用例１記載の発明は、そのようなものではない点。
（３）判断
〈相違点１，２についての判断〉
　引用例１自体には、引用例１記載の発明において、「第１の接続」を通じて、「ユーザインターフェースを操作する方法に関する第１の命令」を受信するようにすること、また、サーバーから当該「第１の命令」の修正を受信するようにすることを示唆する記載はない。
　また、原査定で引用された、特開２００７−１４９０５２号公報（以下、「引用例２」という。）の段落【００９４】〜【０１０８】には、サーバがクライアントから当該クライアントの能力についての情報の伝送を受け、伝送された情報に基づいてクライアントに表示させる情報を修正して送信する技術が記載されているものの、上記引用例２、原査定で引用された、米国特許出願公開第２００８／０１５５６６３号明細書（以下、「引用例３」という。）、原査定で引用された、特開２００７−２６７１０２号公報（以下、「引用例４」という。）のいずれにも、「第１の接続」を通じて「ユーザインターフェースを操作する方法に関する第１の命令」を受信すること、サーバーから当該「第１の命令」の修正を受信することは、記載されておらず、また、そのようにすることを示唆する記載も見当たらない。
　したがって、引用例１〜４によっては、上記相違点１，２の克服が容易であったとはいえない。
　よって、本願補正発明は、引用例１記載の発明及び引用例２〜４記載の技術に基づいて当業者が容易に発明をすることができたものとはいえない。
　他に、本願補正発明を、特許出願の際独立して特許を受けることができないものというべき理由も発見しない。
　よって、本件補正の補正事項１は、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合する。
　本件補正のその余の補正事項についても、特許法第１７条の２第３項ないし第６項の規定に違反するところはない。
３．むすび
　以上のとおり本件補正は、特許法第１７条の２第３項ないし第６項の規定に適合する。
第３　本願発明について
　本件補正は上記のとおり、特許法第１７条の２第３項ないし第６項の規定に適合するから、本願の請求項１〜１９に係る発明は、本件補正により補正された特許請求の範囲の請求項１〜１９に記載された事項により特定されるとおりのものである。
　そして、本願については、原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。
　また、他に本願を拒絶するべき理由を発見しない。