【事件の表示】
　特願２０１０−２３５４９７「ユーザインタフェース操作の位置独立な実行」拒絶査定不服審判事件〔平成２３年　６月１６日出願公開、特開２０１１−１１８８７９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成２２年１０月２０日（パリ条約による優先権主張外国庁受理２００９年１２月７日（以下、「優先日」という。）、米国）を出願日とする出願であって、その後の主な手続は以下のとおりである。
審査請求（提出日）　平成２３年　８月１０日
拒絶理由（起案日）　平成２５年　１月１１日（同年１月２２日発送）
意見書（提出日）　　平成２５年　５月１６日
手続補正（提出日）　平成２５年　５月１６日
拒絶理由（起案日）　平成２５年　８月１４日（同年８月２０日発送）
意見書（提出日）　　平成２５年１１月１９日
手続補正（提出日）　平成２５年１１月１９日
拒絶査定（起案日）　平成２５年１１月２６日（同年１２月３日発送）
審判請求（提出日）　平成２６年　３月　４日
手続補正（提出日）　平成２６年　３月　４日
前置報告（作成日）　平成２６年　５月　８日
第２　平成２６年３月４日付け手続補正について補正却下の決定
［補正却下の決定の結論］
平成２６年３月４日付け手続補正を却下する。
［理由］
１　本件補正
　平成２６年３月４日付けの手続補正（以下「本件補正」という。）により、平成２５年１１月１９日付けの手続補正により補正された特許請求の範囲の記載
「　【請求項１】
　コンピュータによって実施される、ユーザインタフェース操作の位置独立な実行のための方法であって、
　１つ以上のプロセッサによって実行される、
　サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインタフェースを介してユーザ対話を識別する段階と、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階と、
　ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す段階と、
　ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する段階と
　を有し、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階は、ユーザ対話がどのように処理されるべきかを動的に表現した規則を格納した規則リポジトリを利用して、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを判断する段階を含み、
　ユーザ対話がどのように処理されるべきかを動的に表現した規則は、所定のシナリオ及び／又は環境下でのユーザ対話アクションを、クライアント側又はサーバ側での処理に関連付けることを特徴とするコンピュータ実施方法。
　　【請求項２】
　サーバ側アクションハンドラによる対話の処理を要求する段階が、
　ユーザ対話により同期的アクション又は非同期的アクションのどちらが引き起こされるかを判断する段階と、
　判断結果に基づいて、同期的サーバ側アクションハンドラ又は非同期的サーバ側アクションハンドラのいずれか一方による対話の処理を要求する段階と
　を含むことを特徴とする請求項１に記載のコンピュータ実施方法。
　　【請求項３】
　規則リポジトリが、特定の対話にマッピングされた主キーを有することを特徴とする請求項１に記載のコンピュータ実施方法。
　　【請求項４】
　サーバ側コンピュータから、ユーザインタフェースコードを備えたクライアント側アクションハンドラを受信する段階をさらに有することを特徴とする請求項１に記載のコンピュータ実施方法。
　　【請求項５】
　動的な判断の少なくとも一部分が、処理能力、ラウンドトリップ数、及び動作環境からなる複数の基準に従ってなされることを特徴とする請求項１に記載のコンピュータ実施方法。
　　【請求項６】
　ユーザインタフェース操作の位置独立な実行のためのコンピュータプログラムを格納したコンピュータ可読媒体であって、
　コンピュータプログラムは、コンピュータに、
　サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインタフェースを介してユーザ対話を識別する手順と、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順と、
　ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す手順と、
　ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する手順と
　を実行させ、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順は、ユーザ対話がどのように処理されるべきかを動的に表現した規則を格納した規則リポジトリを利用して、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを判断する手順を含み、
　ユーザ対話がどのように処理されるべきかを動的に表現した規則は、所定のシナリオ及び／又は環境下でのユーザ対話アクションを、クライアント側又はサーバ側での処理に関連付けることを特徴とするコンピュータ可読媒体。
　　【請求項７】
　サーバ側アクションハンドラによる対話の処理を要求する手順が、
　ユーザ対話により同期的アクション又は非同期的アクションのどちらが引き起こされるかを判断する手順と、
　判断結果に基づいて、同期的サーバ側アクションハンドラ又は非同期的サーバ側アクションハンドラのいずれか一方による対話の処理を要求する手順と
　を含むことを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項８】
　規則リポジトリが、特定の対話にマッピングされた主キーを有することを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項９】
　コンピュータプログラムが、コンピュータに、
　サーバ側コンピュータから、ユーザインタフェースコードを備えたクライアント側アクションハンドラを受信する手順をさらに実行させることを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項１０】
　動的な判断の少なくとも一部分が、処理能力、ラウンドトリップ数、及び動作環境からなる複数の基準に従ってなされることを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項１１】
　ユーザ対話により複数のイベントサイクルが引き起こされる場合、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順が、イベントサイクル毎に行われることを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項１２】
　アプリケーション間通信インフラストラクチャを想定した構成を介して通信を行うためのコンピュータシステムであって、
　クライアント側ユーザインタフェース及びクライアント側アクションハンドラを格納したメモリと、
　１つ以上のプロセッサと
　を具備し、
　１つ以上のプロセッサは、実行時に、
　サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインタフェースを介してユーザ対話を識別する手順と、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順と、
　ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す手順と、
　ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する手順と
　を実行し、
　メモリは、規則リポジトリをさらに格納し、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順は、ユーザ対話がどのように処理されるべきかを動的に表現した規則を格納した規則リポジトリを利用して実行され、
　ユーザ対話がどのように処理されるべきかを動的に表現した規則は、所定のシナリオ及び／又は環境下でのユーザ対話アクションを、クライアント側又はサーバ側での処理に関連付けることを特徴とするコンピュータシステム。
　　【請求項１３】
　サーバ側アクションハンドラによる対話の処理を要求する手順が、
　ユーザ対話により同期的アクション又は非同期的アクションのどちらが引き起こされるかを判断する手順と、
　判断結果に基づいて、同期的サーバ側アクションハンドラ又は非同期的サーバ側アクションハンドラのいずれか一方による対話の処理を要求する手順と
　を含むことを特徴とする請求項１２に記載のコンピュータシステム。
　　【請求項１４】
　規則リポジトリが、特定の対話にマッピングされた主キーを有することを特徴とする請求項１２に記載のコンピュータシステム。
　　【請求項１５】
　１つ以上のプロセッサが、サーバ側コンピュータから、ユーザインタフェースコードを備えたクライアント側アクションハンドラを受信する手順をさらに実行することを特徴とする請求項１２に記載のコンピュータシステム。」（以下、上記引用の請求項各項を「補正前請求項」という。）
を、
「　【請求項１】
　コンピュータによって実施される、ユーザインタフェース操作の位置独立な実行のための方法であって、
　１つ以上のプロセッサによって実行される、
　サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインタフェースを介してユーザ対話を識別する段階と、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階と、
　ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す段階と、
　ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する段階と
　を有し、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階は、ユーザ対話がどのように処理されるべきかを動的に表現した規則を格納した規則リポジトリを利用して、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを判断する段階を含み、
　ユーザ対話がどのように処理されるべきかを動的に表現した規則は、
実行中の
又はアプリケーションに従って、
、シナリオ又はアプリケーションが実行されている
に従って、
　　【請求項２】
　サーバ側アクションハンドラによる対話の処理を要求する段階が、
　ユーザ対話により同期的アクション又は非同期的アクションのどちらが引き起こされるかを判断する段階と、
　判断結果に基づいて、同期的サーバ側アクションハンドラ又は非同期的サーバ側アクションハンドラのいずれか一方による対話の処理を要求する段階と
　を含むことを特徴とする請求項１に記載のコンピュータ実施方法。
　　【請求項３】
　規則リポジトリが、特定の対話にマッピングされた主キーを有することを特徴とする請求項１に記載のコンピュータ実施方法。
　　【請求項４】
　サーバ側コンピュータから、ユーザインタフェースコードを備えたクライアント側アクションハンドラを受信する段階をさらに有することを特徴とする請求項１に記載のコンピュータ実施方法。
　　【請求項５】
　動的な判断の少なくとも一部分が、処理能力、ラウンドトリップ数、及び動作環境からなる複数の基準に従ってなされることを特徴とする請求項１に記載のコンピュータ実施方法。
　　【請求項６】
　ユーザインタフェース操作の位置独立な実行のためのコンピュータプログラムを格納したコンピュータ可読媒体であって、
　コンピュータプログラムは、コンピュータに、
　サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインタフェースを介してユーザ対話を識別する手順と、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順と、
　ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す手順と、
　ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する手順と
　を実行させ、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順は、ユーザ対話がどのように処理されるべきかを動的に表現した規則を格納した規則リポジトリを利用して、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを判断する手順を含み、
　ユーザ対話がどのように処理されるべきかを動的に表現した規則は、
実行中の
又はアプリケーションに従って、
、シナリオ又はアプリケーションが実行されている
に従って、
　　【請求項７】
　サーバ側アクションハンドラによる対話の処理を要求する手順が、
　ユーザ対話により同期的アクション又は非同期的アクションのどちらが引き起こされるかを判断する手順と、
　判断結果に基づいて、同期的サーバ側アクションハンドラ又は非同期的サーバ側アクションハンドラのいずれか一方による対話の処理を要求する手順と
　を含むことを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項８】
　規則リポジトリが、特定の対話にマッピングされた主キーを有することを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項９】
　コンピュータプログラムが、コンピュータに、
　サーバ側コンピュータから、ユーザインタフェースコードを備えたクライアント側アクションハンドラを受信する手順をさらに実行させることを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項１０】
　動的な判断の少なくとも一部分が、処理能力、ラウンドトリップ数、及び動作環境からなる複数の基準に従ってなされることを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項１１】
　ユーザ対話により複数のイベントサイクルが引き起こされる場合、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順が、イベントサイクル毎に行われることを特徴とする請求項６に記載のコンピュータ可読媒体。
　　【請求項１２】
　アプリケーション間通信インフラストラクチャを想定した構成を介して通信を行うためのコンピュータシステムであって、
　クライアント側ユーザインタフェース及びクライアント側アクションハンドラを格納したメモリと、
　１つ以上のプロセッサと
　を具備し、
　１つ以上のプロセッサは、実行時に、
　サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインタフェースを介してユーザ対話を識別する手順と、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順と、
　ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す手順と、
　ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する手順と
　を実行し、
　メモリは、規則リポジトリをさらに格納し、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する手順は、ユーザ対話がどのように処理されるべきかを動的に表現した規則を格納した規則リポジトリを利用して実行され、
　ユーザ対話がどのように処理されるべきかを動的に表現した規則は、
実行中の
又はアプリケーションに従って、
、シナリオ又はアプリケーションが実行されている
に従って、
　　【請求項１３】
　サーバ側アクションハンドラによる対話の処理を要求する手順が、
　ユーザ対話により同期的アクション又は非同期的アクションのどちらが引き起こされるかを判断する手順と、
　判断結果に基づいて、同期的サーバ側アクションハンドラ又は非同期的サーバ側アクションハンドラのいずれか一方による対話の処理を要求する手順と
　を含むことを特徴とする請求項１２に記載のコンピュータシステム。
　　【請求項１４】
　規則リポジトリが、特定の対話にマッピングされた主キーを有することを特徴とする請求項１２に記載のコンピュータシステム。
　　【請求項１５】
　１つ以上のプロセッサが、サーバ側コンピュータから、ユーザインタフェースコードを備えたクライアント側アクションハンドラを受信する手順をさらに実行することを特徴とする請求項１２に記載のコンピュータシステム。」（以下、上記引用の請求項各項を「補正後請求項」という。下線は補正事項を示すものとして出願人が付与したものである。）
　に補正するものである。
２　本件補正による補正事項
　本件補正による補正事項は以下のとおりである。
＜補正事項１＞
　補正前請求項１、６及び１２の「ユーザ対話がどのように処理されるべきかを動的に表現した規則は、所定のシナリオ及び／又は環境下でのユーザ対話アクションを、クライアント側又はサーバ側での処理に関連付ける」を、補正後請求項１、６及び１２の「ユーザ対話がどのように処理されるべきかを動的に表現した規則は、実行中のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従って、ユーザ対話アクションを、クライアント側又はサーバ側での処理に関連付ける」とする補正。
　これらは、補正前請求項１、６及び１２の「ユーザ対話がどのように処理されるべきかを動的に表現した規則」を限定する事項である「実行中のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従って」という態様を追加するものであり、補正前請求項１、６及び１２の「所定のシナリオ及び／又は環境下でのユーザ対話アクション」という態様から「ユーザ対話アクション」を限定する事項である「所定のシナリオ及び／又は環境下での」という態様を削除するものである。
３　新規事項追加禁止要件
　補正事項１は「ユーザ対話がどのように処理されるべきかを動的に表現した規則」が「実行中のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従って」という態様であることは、願書に最初に添付した明細書、特許請求の範囲又は図面（以下「当初明細書等」と記す。）には記載されておらず、また当初明細書等の記載からみて自明な事項でもない。
　本件補正発明の「ユーザ対話がどのように処理されるべきかを動的に表現した規則」について、明細書の段落【０００５】には「この例示的な規則リポジトリは、（中略）、さまざまな対話アクションの動的な表現を備えた規則を有する。」との記載、段落【００２０】には「（前略）ＣＡＤはアクションを取得（ｇｅｔ）するとともに、規則エンジンを用いてその分析を行う。（中略）規則リポジトリには、「アクション」がどのように処理されるべきかという規則が格納されている。（中略）規則を動的に表現して、アクションをどのように処理すべきかを決定してもよい。そして、ＣＡＤは、必要とされるアクションハンドラにアクションを渡す。具体的には、通常、通信線情報はサーバに格納されているものの、実行時プロセッサ（コントローラ）は、クライアント側及び／又はサーバ側に実装される可能性があり、クライアント側イベントサイクルとサーバ側イベントサイクルとの差を緩和する役目を果たす。」との記載がされているに過ぎず、「ユーザ対話がどのように処理されるべきかを動的に表現した規則」に関し、技術的な特徴となる態様を解することができない。
　例えば、補正後請求項１の「ユーザ対話がどのように処理されるべきかを動的に表現した規則」は「ＣＡＤ」が「アクション」を分析するために用いていると解せるものの、「フレームワーク」が「どちらのアプローチを実施するかを動的に決定」するためのものと、「ＣＡＤ」が「アクションをどのように処理されるべきかを決定」するためのものとの関係が不明であり、「ユーザ対話がどのように処理されるべきかを動的に表現した規則」が、「実行中のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従って」いることが自明でない。したがって、「ユーザ対話がどのように処理されるべきかを動的に表現した規則は、実行中のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従って」という記載は発明の詳細な説明に記載されたものではない。
　よって、本件補正は、当初明細書等に記載した事項の範囲内においてしたものではない。
　審判請求書において、審判請求人は、「補正事項は、出願当初の明細書の段落０００８の記載に基づきます。」と主張している。
　しかし、段落【０００８】には「（前略）対話を実行するためにどのモデルを用いるかについての決定は、フレームワークによって、開発者に意識させないように選択される（中略）実行中のシナリオ／アプリケーションに応じて、フレームワークは、どちらのアプローチを実施するかを動的に決定する。また、これは、シナリオ／アプリケーションが実行されている環境によって決まることもある（例えば、アプリケーションがポータル内で実行されている場合には違いがあってよい）。（後略）」と記載されているに過ぎず、「対話を実行するためにどのモデルを用いるかについての決定」は、「実行中のシナリオ／アプリケーション」や「シナリオ／アプリケーションが実行されている環境」に応じて、フレームワークによって選択することがあると解せるものの、補正後請求項１の「ユーザ対話がどのように処理されるべきかを動的に表現した規則」との対応が不明である。
　よって、審判請求人の主張は採用できない。
　したがって、本件補正は、当初明細書等に記載した事項の範囲内においてしたものでなく、特許法第１７条の２第３項の規定に違反する。
４　補正の目的要件
　次に、本件補正が、特許法第１７条の２第５項の規定を満たすものであるか否か、すなわち、本件補正が、特許法第１７条の２第５項に規定する請求項の削除、特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る）、誤記の訂正、或いは、明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）の何れかを目的としたものであるかについて、以下に検討する。
　補正事項１は、補正前請求項１、６及び１２の「ユーザ対話がどのように処理されるべきかを動的に表現した規則」を限定する事項である「所定のシナリオ及び／又は環境下でのユーザ対話アクションを、クライアント側又はサーバ側での処理に関連付ける」という態様から「ユーザ対話アクション」を限定する事項である「所定のシナリオ及び／又は環境下での」という態様を削除する補正を行うものであるから、限定的減縮を目的とするものとは認められない。
　また、補正事項１の目的は、請求項の削除、誤記の訂正、或いは、不明瞭な記載の釈明の何れにも該当しないことも明らかである。
　したがって、本件補正は、特許法第１７条の２第５項の各号に掲げる事項を目的とするものに限られるものではない。
５　独立特許要件についての判断
　以上のように、本件補正は、前記「３　新規事項追加禁止要件」及び「４　補正の目的要件」で指摘したとおり、特許法第１７条の２第３項及び第５項の規定に違反するものであるが、仮に本件補正が、特許法第１７条の２第３項及び第５項第２号（特許請求の範囲の減縮）に規定する要件を満たしているものと仮定した場合に、本件補正後の特許請求範囲に記載されている事項により特定される発明は、特許出願の際独立して特許を受けることができるものでなければならない（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定）ので、この規定に適合するか否かを以下に念のため検討する。
（１）本件補正発明
　補正後請求項１に記載された発明（以下「本件補正発明」という。）は、前記平成２６年３月４日付けの手続補正（本件補正）により補正された特許請求の範囲の請求項１に記載された次のとおりである。（再掲する）
　「コンピュータによって実施される、ユーザインタフェース操作の位置独立な実行のための方法であって、
　１つ以上のプロセッサによって実行される、
　サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインタフェースを介してユーザ対話を識別する段階と、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階と、
　ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す段階と、
　ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する段階と
　を有し、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階は、ユーザ対話がどのように処理されるべきかを動的に表現した規則を格納した規則リポジトリを利用して、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを判断する段階を含み、
　ユーザ対話がどのように処理されるべきかを動的に表現した規則は、実行中のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従って、ユーザ対話アクションを、クライアント側又はサーバ側での処理に関連付けることを特徴とするコンピュータ実施方法。」
（２）　引用文献に記載されている技術的事項、及び引用発明の認定
（２−１）引用文献１
　本願の優先日前に既に頒布または電気通信回線を通して公衆に利用可能とされ、原審の拒絶査定の理由である上記平成２５年１月１１日付けの拒絶理由通知において引用された文献である国際公開２００９／１３９４２６号（以下、「引用文献１」という。）には、関連図面とともに、以下の技術的事項が記載されている。（当審注；下線は、参考のために当審で付与したものである。）
Ａ「 【００１５】
　本発明の第２の観点では、情報処理方法は、クライアントデータベースを有するクライアント端末と、サーバデータベースを有するサーバ装置とを備え、前記クライアント端末と前記サーバ装置はネットワークを介して接続された環境で実行される。
情報処理方法は、前記サーバ装置の動作環境情報に基づいて、前記サーバ装置から前記クライアント端末に指示を与えるステップと、前記クライアント端末の動作環境情報と前記サーバ装置からの指示に基づいて振り分けルールを生成するステップと、前記クライアント端末内で、クライアントプロセスを実行してリクエストを発行するステップと、前記クライアント端末内で、前記振り分けルールに基づいて、前記リクエストを前記クライアント端末内で処理すべきか、前記サーバ装置で処理すべきかを決定するステップと、前記リクエストを前記クライアント端末内で処理すべきと決定されたとき、前記クライアント端末内で前記リクエストを実行して、処理結果をクライアントプロセスに返すステップと、前記サーバ装置で処理すべきと決定されたとき前記リクエストを前記サーバ装置内で処理し、処理結果を前記クライアントプロセスに返すステップとを備えている
　上記の情報処理方法を実現するための計算機実行可能なプログラムコードを格納した計算機読み取り可能な記録媒体も本発明に含まれる。
  【００１６】
　本発明に係る
クライアント／サーバシステムにおいて、通常サーバで行われるアプリケーションの情報処理をクライアントおよびサーバの動作環境に応じて、効率的にクライアント／サーバ間で移行できる。特にネットワークが切断された状態においても、クライアントのみで継続的にアプリケーションを実行できるという効果を有する
Ｂ　「 【００２７】
＜クライアント端末＞
　次に本実施形態に係るクライアント端末１００の構成について説明する。
　図１に示されるように、本実施形態にかかるクライアント端末１００は、クライアント環境情報収集部１１０と、クライアント実行制御部１２０と、振り分け部１３０と、クライアント同期モジュール１４０と、サーバアプリケーション実行プラットフォーム１５０と、クライアントプロセスを実行する実行部５００と、クライアントポリシを格納する格納部４００と、クライアント環境情報記憶部１７０とを備える。サーバアプリケーション実行プラットフォーム１５０は、サーバプロセス実行部５１０とクライアントデータベース１６０とを備える。
  【００２８】
　クライアント環境情報記憶部１７０は、動作環境情報を格納している。この動作環境情報は、例えばクライアント端末１００がＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）を実行するとき計測される。この動作環境情報はＯＳによって随時更新される。
動作環境情報は、クライアント端末１００の動作環境の状態を示す情報であり、ＣＰＵ使用率や、メモリ使用率、ハードディスク使用率、ネットワーク回線の接続状態、ネットワーク回線速度などの少なくとも一つを含む。
  【００２９】
　クライアント環境情報収集部１１０は、クライアント端末１００の動作環境情報をクライアント環境情報記憶部１７０から取得する。クライアント環境情報収集部１１０は、自らクライアント端末１００の動作環境の状態を計測することにより動作環境情報を取得してもよい。また、ＯＳによって計測できない環境情報は、クライアント環境情報収集部１１０が計測する。
  【００３０】
　サーバプロセス実行部５１０は、クライアント端末１００のサーバアプリケーション実行プラットフォーム１５０上で実行されるプログラムである。クライアント端末１００がサーバプロセスを実行することにより、サーバ装置２００がサーバプロセス５１１を実行することにより実現される情報処理の全体あるいは一部と同一の処理が実現される。
【００３１】
　クライアントプロセスは、クライアント端末１００の実行部５００により実行されるプログラムである。クライアント端末１００の実行部５００はクライアントプロセスを実行して、サーバプロセスに対して情報処理の実行要求を発行したり、サーバプロセスから情報処理の実行結果を受け取ったりする。つまり、クライアント端末１００内でサーバプロセスが実行されるとき、ネットワーク３００を介さずに、サーバプロセスとしてのスケジュールアプリケーションが実行される。なお、
クライアントプロセスは、例えばブラウザなどのフロントエンドプログラムにより構成することができる
【００３２】
　
クライアントポリシ格納部４００は、クライアントプロセスの実行部５００からリクエスト（例えばＵＲＬを指定したデータの閲覧要求など）が出力された場合に、そのリクエストをクライアント端末１００で処理すべきか、あるいはサーバ装置２００で処理すべきかをクライアント実行制御部１２０が判定するための判定基準であるクライアントポリシを格納している。また、クライアントポリシ格納部４００には、クライアント端末１００あるいはサーバ装置２００のそれぞれが上記リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等の判定基準も含まれている。
【００３３】
　
クライアント実行制御部１２０は、クライアント端末１００の動作環境情報とこの判定基準との比較の結果に応じて、リクエストをクライアント端末１００とサーバ装置２００のいずれで処理すべきかの処理主体判定や、ストレージの同期を実行すべきか否かを判定する
  【００３４】
　
振り分け部１３０は、クライアント端末１００の動作環境情報とクライアントポリシ４００との比較の結果に応じて、クライアント実行制御部１２０により判定されたリクエストの処理主体にリクエストを振り分ける
Ｃ　「【００３６】
　
クライアントポリシ４００の一例を図２に示す
「Ｒｅｑｕｅｓｔ」欄には、クライアント端末１００が上記情報処理サービスの提供を受ける際に、クライアントプロセスからサーバ装置２００に出されるリクエストを特定する情報が記載される。
クライアント実行制御部１２０は、この判定基準を動作環境情報と比較することにより、上記リクエストの処理主体を判定する
  【００３７】
　
判定基準の内容として、「標準動作」、「条件」、「同期ストレージ」、「同期タイプ」、「同期タイミング」が規定されている。「標準動作」欄にはそのリクエストの処理主体の第１次候補が記載される。「条件」欄には、処理主体の第２次候補および、第２次候補が選択されるための条件が記載される
　「同期ストレージ」欄には、サーバ装置２００のストレージと内容を一致（同期）させる必要があるクライアント端末１００のストレージを示す情報が記載される。「同期タイプ」欄には同期の方法が記載される。「ＣＯＰＹ」と記載されている場合は、クライアント端末１００のストレージに記憶されている情報の複製をサーバ装置２００のストレージに書き込むことにより同期を行うことを示している。また「ＭＯＶＥ」と記載されている場合は、クライアント端末１００のストレージに記憶されている情報の複製をサーバ装置２００のストレージに書き込んだ後、クライアント端末１００のストレージに記憶されている情報を消去する方法により同期を行うことを示す。
　「同期タイミング」欄には、同期処理を行う契機を示す情報が記載される。環境情報の内容がこの情報の内容と一致した場合には、同期処理が開始されることになる。例えば所定の時刻到来により同期処理を開始させるようにすることもできるし、クライアント端末１００とサーバ装置２００との間が通信可能になったことが検出された場合に同期処理を開始させるようにすることもできる。「その他」欄には、上記「Ｒｅｑｕｅｓｔ」欄に記載されるリクエスト以外のリクエストに対する処理主体が記載される。」
Ｄ　「【００５１】
　図６を参照して、クライアント端末１００が起動されるとき、まずクライアント実行制御部１２０は、クライアントポリシ格納部４００からポリシ情報を読み込む（ステップＳ１）。続いて、クライアント実行制御部１２０は、所定の時間が経過するまで待機する（ステップＳ２）。
所定の時間が経過したとき、クライアント環境情報収集部１１０が動作環境情報を収集する（ステップＳ３）。収集された動作環境情報はクライアント環境情報記憶部１７０に格納される。クライアント実行制御部１２０は、収集された動作環境情報とクライアントポリシとに基づいて、既存のルールのための条件と異なる条件が発生したか否かを検出する。こうして、クライアント実行制御部１２０はルールの再生成の必要性を判定する（ステップＳ４）。ルールの再生成の必要がないときは、動作フローはステップＳ２に戻る。ルール再生性の必要があると判断された場合は、クライアント実行制御部１２０は、クライアントポリシに基づいて振分けルールを生成する（ステップＳ５）
Ｅ　「【００５２】
＜振り分け処理＞
　続いて、図７を参照してクライアント端末１００における振り分け部１３０による振分け処理について説明する。振り分け処理では、
振り分け部１３０は、クライアントプロセス実行部５００からリクエストを受け付ける
クライアント端末１００で処理すべき場合は、クライアント端末１００内のサーバプロセス実行部５１０がリクエストを処理する（ステップＳ１５）。
クライアント端末１００で処理しない場合は、振り分け部１３０は、リクエストをサーバプロセス実行部５１１へ送る（ステップＳ１６）
（２−２）引用文献２
　本願の優先日前に既に頒布または電気通信回線を通して公衆に利用可能とされ、原審の拒絶の査定の理由である上記平成２５年１月１１日付けの拒絶理由通知において引用された文献である米国特許出願公開第２００３／００１４４７８号明細書（以下、「引用文献２」という。）には、関連図面とともに、以下の技術的事項が記載されている。（下線は、参考のために当審で付与したものである。）
Ｆ　「 SUMMARY 
 [0010]  In general, 
the invention concerns dynamically distributing, between client and server, the various processes carried out by software (e.g., web browsers) 
 [0011]  More specifically, the invention features, in general, a computing process wherein at least one server responds to requests from clients by returning information to clients, and wherein the computing process comprises initiating a request at a client, communicating the request to the server, responding to the request at the server by returning information to the client (wherein the information returned goes through at least parsing, layout, and rendering processes before being displayed at the client), 
configuring the software carrying out at least one of the parsing, layout, and rendering processes so that the location at which the process is performed can be changed between server and client at run time, making a load-balancing determination as to whether the process should be run at the server or client; and running the process at the chosen location. 
「（当審訳）要約
[００１０]概して、
発明は、クライアントとサーバの間で、
ソフトウエア（例えば、Ｗｅｂブラウザ）によって実行された種々のプロセスを動的に配布することに関係する。
[００１１]すなわち、一般に、発明が特徴とする、クライアントへの返信情報によってクライアントからのリクエストにレスポンスする少なくとも１つのサーバでの計算プロセス、そして計算プロセスがクライアントでリクエストを始めること、サーバへリクエストを伝えること、クライアントへの情報を返すことによってサーバでリクエストまでの反応すること（そこで、クライアントで表示される前に、少なくともパーシング、レイアプト、レンダリングプロセスを通して情報を返すこと）
プロセスが行われる場所が実行時にサーバとクライアントの間で変えられることができるため少なくとも１つのパーシング、レイアウト、レンダリングプロセスを設定しているソフトウエアを実行する、サーバあるいはクライアントでプロセスが行われるべきであるかどうかのロードバランシング決定を作成することにより、選ばれた場所でプロセスを実行する。」
Ｇ　「[0036]  
The load balancing determination may be based on one or more of the following: client computational resources, client load, server computational resources, server load, number of clients per server, network traffic between clients and server, and security. 
「（当審訳）[００３６]
ロードバランシング決定は次の１つ以上をベースにしても良い。すなわち、クライアント計算資源、クライアント負荷、サーバ計算資源、サーバ負荷、サーバ毎のクライアントの数、クライアントとサーバ間のネットワークトラフィック、及びセキュリティ。
（２−３）引用発明の認定
　引用文献１に記載されている事項を検討する。
ア　前記Ａの「情報処理方法は、前記サーバ装置の動作環境情報に基づいて、前記サーバ装置から前記クライアント端末に指示を与えるステップと、前記クライアント端末の動作環境情報と前記サーバ装置からの指示に基づいて振り分けルールを生成するステップと、前記クライアント端末内で、クライアントプロセスを実行してリクエストを発行するステップと、前記クライアント端末内で、前記振り分けルールに基づいて、前記リクエストを前記クライアント端末内で処理すべきか、前記サーバ装置で処理すべきかを決定するステップと、前記リクエストを前記クライアント端末内で処理すべきと決定されたとき、前記クライアント端末内で前記リクエストを実行して、処理結果をクライアントプロセスに返すステップと、前記サーバ装置で処理すべきと決定されたとき前記リクエストを前記サーバ装置内で処理し、処理結果を前記クライアントプロセスに返すステップとを備えている」、「クライアント／サーバシステムにおいて、通常サーバで行われるアプリケーションの情報処理をクライアント及びサーバの動作環境に応じて、効率的にクライアント／サーバ間で移行できる」との記載、前記Ｂの「【００３３】クライアント実行制御部１２０は、クライアント端末１００の動作環境情報とこの判定基準との比較の結果に応じて、リクエストをクライアント端末１００とサーバ装置２００のいずれで処理すべきかの処理主体判定や、ストレージの同期を実行すべきか否かを判定する。」との記載から、引用文献１には「クライアント端末及びサーバ装置の動作環境」に応じて、「クライアントプロセスからのリクエスト」を「クライアント／サーバ間で処理主体を移行できる情報処理方法」が記載されていると認められる。
イ　前記Ｂの「クライアントプロセスは、例えばブラウザなどのフロントエンドプログラムにより構成することができる」との記載において、「ブラウザなどのフロントエンドプログラム」には「ユーザインタフェース」や「ユーザ対話」が含まれると解せることから、前記アで検討した「クライアントプロセス」は「ブラウザなどのフロントエンドプログラムにより構成されたクライアントプロセス」といえる。
　そうすると、引用文献１には“クライアント端末及びサーバ装置の動作環境に応じて、ブラウザなどのフロントエンドプログラムにより構成されたクライアントプロセスからのリクエストをクライアント／サーバ間で処理主体を移行できる情報処理方法”が記載されていると認められる。
ウ　前記Ｃの『クライアントポリシー４００の一例を図２に示す（中略）「Ｒｅｑｕｅｓｔ」欄には、クライアント端末１００が上記情報処理サービスの提供を受ける際に、クライアントプロセスからサーバ装置２００に出されるリクエストを特定する情報が記載される。（中略）各「Ｒｅｑｕｅｓｔ」欄には、リクエストが出された場合に、そのリクエストをクライアント端末１００あるいはサーバ装置２００のどちらに処理させるかを判定するための判定基準が記載されている。（中略）クライアント実行制御部１２０は、この判定基準を動作環境情報と比較することにより、上記リクエストの処理主体を判定する』との記載、前記Ｂの「クライアント実行制御部１２０は、クライアント端末１００の動作環境情報とこの判定基準との比較の結果に応じて、リクエストをクライアント端末１００とサーバ装置２００のいずれで処理すべきかの処理主体判定や、ストレージの同期を実行すべきか否かを判定する」との記載から、引用文献１には“クライアント端末はクライアントプロセスの実行を制御するクライアント実行制御部を有し、クライアント実行制御部によりクライアントプロセスからのリクエストを特定し、判定基準と動作環境情報を比較することにより、リクエストの処理主体を判定する段階”が記載されていると認められる。
エ　前記Ｂの「振り分け部１３０は、クライアント端末１００の動作環境情報とクライアントポリシ４００との比較の結果に応じて、クライアント実行制御部１２０により判定されたリクエストの処理主体にリクエストを振り分ける。」との記載、前記Ｅの「振り分け部１３０は、クライアントプロセス実行部５００からリクエストを受け付ける（ステップＳ９）（中略）振り分け部１３０は、振分けルールに基づいて、リクエストをクライアント端末１００で処理するか、サーバ装置２００で処理するかを判定する（ステップＳ１４）。」との記載から、引用文献１には“判定されたリクエストを振分けルールに基づいて、クライアント端末で処理するか、サーバ装置で処理するかを振り分ける段階”が記載されていると認められる。
オ　前記Ｅの「振り分け部１３０は、クライアントプロセス実行部５００からリクエストを受け付ける。（中略）クライアント端末１００で処理すべき場合は、クライアント端末１００内のサーバプロセス実行部５１０がリクエストを処理する（ステップＳ１５）。」との記載から、引用文献１には“リクエストがクライアント端末で処理すべき場合、サーバプロセス実行部５１０を呼び出す段階”が記載されていると認められる。
カ　前記Ｅの「振り分け部１３０は、クライアントプロセス実行部５００からリクエストを受け付ける。（中略）クライアント端末１００で処理しない場合は、振り分け部１３０は、リクエストをサーバプロセス実行部５１１へ送る（ステップＳ１６）。」との記載から、引用文献１には“リクエストがクライアント端末で処理しない場合、サーバプロセス実行部５１１によるリクエストの処理を要求する段階”が記載されていると認められる。
キ　前記Ｂの「クライアントポリシ格納部４００は、クライアントプロセスの実行部５００からリクエスト（例えばＵＲＬを指定したデータの閲覧要求など）が出力された場合に、そのリクエストをクライアント端末１００で処理すべきか、あるいはサーバ装置２００で処理すべきかをクライアント実行制御部１２０が判定するための判定基準であるクライアントポリシを格納している。また、クライアントポリシ格納部４００には、クライアント端末１００あるいはサーバ装置２００のそれぞれが上記リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等の判定基準も含まれている。」との記載から、引用文献１の「判定基準（クライアントポリシ）」は、「リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等の判定基準」も含まれているので、「リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等を表現した規則（判定基準）」といえる。
　また、前記Ｄの「所定の時間が経過したとき、クライアント環境情報収集部１１０が動作環境情報を収集する（ステップＳ３）。収集された動作環境情報はクライアント環境情報記憶部１７０に格納される。クライアント実行制御部１２０は、収集された動作環境情報とクライアントポリシとに基づいて、既存のルールのための条件と異なる条件が発生したか否かを検出する。こうして、クライアント実行制御部１２０はルールの再生成の必要性を判定する（ステップＳ４）。ルールの再生成の必要がないときは、動作フローはステップＳ２に戻る。ルール再生性の必要があると判断された場合は、クライアント実行制御部１２０は、クライアントポリシに基づいて振分けルールを生成する（ステップＳ５）。」との記載から、引用文献１の「振分ルール」は、「収集された動作環境情報」と「判定基準（クライアントポリシ）」とに基づいて、所定の時間が経過したときに見直しを行っているので、「収集された動作環境情報と判定基準に基づいて、所定の時間が経過したときに見直す規則（振分けルール）」といえる。
　そうすると、引用文献１には“リクエストの処理主体を判定する段階及び振り分ける段階は、リクエストを処理する際に使用される各ストレージ情報や、各ストレージの同期方法、同期タイミング等を表現した規則（判定基準）を格納したクライアントポリシ格納部を利用して、収集された動作環境情報と判定基準に基づいて、所定の時間が経過したときに見直す規則（振分けルール）により、リクエストをクライアント端末又はサーバ装置のどちらで処理するかを判断する段階”が記載されていると認められる。
ク　前記Ｂの「動作環境情報は、クライアント端末１００の動作環境の状態を示す情報であり、ＣＰＵ使用率や、メモリ使用率、ハードディスク使用率、ネットワーク回線の接続状態、ネットワーク回線速度などの少なくとも一つを含む。」との記載から、引用文献１の「動作環境情報」は、アプリケーションが実行されている環境の情報であると解せる。
　前記Ｃの「クライアントポリシー４００の一例を図２に示す（中略）クライアント実行制御部１２０は、この判定基準を動作環境情報と比較することにより、上記リクエストの処理主体を判定する（中略）判定基準の内容として、「標準動作」、「条件」、「同期ストレージ」、「同期タイプ」、「同期タイミング」が規定されている。「標準動作」欄にはそのリクエストの処理主体の第１次候補が記載される。「条件」欄には、処理主体の第２次候補および、第２次候補が選択されるための条件が記載される。」との記載から、引用文献１の「判定基準」は、アプリケーションが実行される環境に従って、リクエストの処理主体の候補を定義しているので、リクエストをクライアント端末又はサーバ装置での処理に関連付けていると解せる。
　そうすると、引用文献１には“判定基準は、アプリケーションが実行される環境に従って、リクエストをクライアント端末又はサーバ装置の処理に関連付ける規則”が記載されていると認められる。
ケ　前記ア乃至前記クで検討した事項を踏まえると、引用文献１には、次の発明（以下、「引用発明」という。）が記載されているものと認められる。
「クライアント端末及びサーバ装置の動作環境に応じて、ブラウザなどのフロントエンドプログラムにより構成されたクライアントプロセスからのリクエストをクライアント／サーバ間で処理主体を移行できる情報処理方法であって、
　クライアント端末はクライアントプロセスの実行を制御するクライアント実行制御部を有し、クライアント実行制御部によりクライアントプロセスからのリクエストを特定し、
　判定基準と動作環境情報を比較することにより、リクエストの処理主体を判定する段階と、
　判定されたリクエストを振分けルールに基づいて、クライアント端末で処理するか、サーバ装置で処理するかを振り分ける段階と、
　リクエストがクライアント端末で処理すべき場合、サーバプロセス実行部５１０を呼び出す段階と、
　リクエストがクライアント端末で処理しない場合、サーバプロセス実行部５１１によるリクエストの処理を要求する段階とを有し、
　前記リクエストの処理主体を判定する段階及び前記振り分ける段階は、リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等を表現した規則（判定基準）を格納したクライアントポリシ格納部を利用して、収集された動作環境情報と判定基準に基づいて、所定の時間が経過したときに見直す規則（振分けルール）により、リクエストをクライアント端末又はサーバ装置のどちらで処理するかを判断する段階を含み、
　前記判定基準は、アプリケーションが実行される環境に従って、リクエストをクライアント端末又はサーバ装置の処理に関連付ける規則であること
を特徴とする情報処理システム及び情報処理方法。」
（３）対比
本件補正発明と引用発明を対比する。
（ア）前記イで検討したとおり引用発明の「ブラウザなどのフロントエンドプログラムにより構成されたクライアントプロセス」は「ユーザインタフェース操作」を含むものといえるから、本件補正発明の「ユーザインタフェース操作」に対応する。また、引用発明の「リクエストをクライアント／サーバ間で処理主体を移行できる」ことは、リクエストとリクエストを処理する位置（処理主体）とを独立できるといえるので、本件補正発明の「位置独立」に対応するものといえる。そして、引用発明の「クライアント端末及びサーバ装置の動作環境」は「コンピュータによって実施される」ことは自明であることから、引用発明における「クライアント端末及びサーバ装置の動作環境に応じて、ブラウザなどのフロントエンドプログラムにより構成されたクライアントプロセスからのリクエストをクライアント／サーバ間で処理主体を移行できる情報処理方法」は、本件補正発明における「コンピュータによって実施される、ユーザインタフェース操作の位置独立な実行のための方法」に相当するといえる。
（イ）引用発明の「クライアント実行制御部」は、「１つ以上のプロセッサによって実行される」ことは自明であり、「サーバ側コンピュータに通信可能に接続され」ていることも自明である。
　前記イで検討したとおり、引用発明の「クライアントプロセス」は「ユーザインタフェース」を含むものといえるから、本件補正発明の「クライアント側ユーザインタフェース」に対応し、引用発明の「クライアントプロセスからのリクエスト」は「ブラウザなどのフロントエンドプログラムから構成されたクライアントプロセス」からのものであり、「ユーザ対話」も含まれるといえるので、引用発明の「リクエスト」は本件補正発明の「ユーザ対話」に対応する。また、引用発明の「クライアントプロセスからのリクエストを特定」することは、処理主体を判定するための「リクエスト」を「識別」していることが自明であるので、本件補正発明の「クライアント側ユーザインタフェースを介してユーザ対話を識別」することに対応する。
　そうすると、引用発明における「クライアント端末はクライアントプロセスの実行を制御するクライアント実行制御部を有し、クライアント実行制御部によりクライアントプロセスからのリクエストを特定」することは、本件補正発明における「１つ以上のプロセッサによって実行される、サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインターフェースを介してユーザ対話を識別する段階」に相当するといえる。
（ウ）引用発明における「判定基準と動作環境情報を比較することにより、リクエストの処理主体を判定する段階」は、「動作環境情報」は経時的に動的に変化するものであり、動的に変化する「動作環境情報」に応じた判断は、「動的な判断」を行っているといえる。また、引用発明の「判定されたリクエストを振分けルールに基づいて、クライアント端末で処理するか、サーバで処理するかを振り分ける段階」で用いる「振分けルール」は、「収集された動作環境情報と判定基準に基づいて、所定の時間が経過したときに見直す規則」であるので、動的に変化する「動作環境情報」に基づいて所定の時間毎に見直す規則を利用しているので「動的に表現した規則」といえる。即ち、引用発明における「判定基準と動作環境情報を比較することにより、リクエストの処理主体を判定する段階と、判定されたリクエストを振分けルールに基づいて、クライアント端末で処理するか、サーバで処理するかを判定し振り分ける段階」は、動的に変化する「動作環境情報」と「動的に表現した規則」とにより「動的に判断」しているといえるので、本件補正発明における「識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階」に相当する。
（エ）引用発明の「サーバプロセス実行部５１０」は、クライアント側で処理するサーバプロセスを実行することから、本件補正発明の「クライアント側アクションハンドラ」に対応するので、引用発明における「リクエストがクライアント端末で処理すべき場合、サーバプロセス実行部５１０を呼び出す段階」は、本件補正発明における「ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す段階」に相当する。
（オ）引用発明の「サーバプロセス実行部５１１」は、サーバ側で処理するサーバプロセスを実行することから、本件補正発明の「サーバ側アクションハンドラ」に対応するので、引用発明における「リクエストがクライアント端末で処理しない場合、サーバプロセス実行部５１１によるリクエストの処理を要求する段階」は、本件補正発明における「ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する段階」に相当する。
（カ）引用発明の「リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等を表現した規則（判定基準）」及び「収集された動作環境情報と判定基準に基づいて、所定の時間が経過したときに見直す規則（振分けルール）」は、本件補正発明における「識別したユーザ対話をどのように処理すべきかを動的に表現した規則」と、「判断に用いる規則」という上位概念で一致し、引用発明の「クライアントポリシ格納部」は、本件補正発明の「規則リポジトリ」に対応するので、引用発明における「前記リクエストの処理主体を判定する段階及び前記振り分ける段階は、リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等を表現した規則（判定基準）を格納したクライアントポリシ格納部を利用して、収集された動作環境情報と判定基準に基づいて、所定の時間が経過したときに見直す規則（振分けルール）により、リクエストをクライアント側又はサーバ側のどちらで処理するかを判断する段階」は、本件補正発明における「識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階は、ユーザ対話がどのように処理されるべきかを動的に表現した規則を格納した規則リポジトリを利用して、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを判断する段階」と、後記する点で相違するものの、“識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階は、判断に用いる規則を格納した規則リポジトリを利用して、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを判断する段階”という点で一致する。
（キ）前記（カ）より引用発明の「判定基準」は、本件補正発明の「ユーザ対話がどのように処理されるべきかを動的に表現した規則」と、「判断に用いる規則」という上位概念で一致している。また、引用発明の「リクエスト」は、本件補正発明の「ユーザ対話アクション」に対応するので、引用発明における「判定基準は、アプリケーションが実行される環境に従って、リクエストをクライアント側又はサーバ側の処理に関連付ける規則であること」は、本件補正発明における「ユーザ対話がどのように処理されるべきかを動的に表現した規則は、実行中の所定のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従って、ユーザ対話アクションを、クライアント側又はサーバ側での処理に関連付けること」と、後記する点で相違するものの、“判断に用いる規則は、ユーザ対話アクションをクライアント側又はサーバ側での処理に関連付けること”という点で一致する。
　以上から、本件補正発明と引用発明とは、以下の点で一致し、また、以下の点で相違する。
＜一致点＞
コンピュータによって実施される、ユーザインターフェース操作の位置独立な実行のための方法であって、
１つ以上のプロセッサによって実行される、サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインターフェースを介してユーザ対話を識別する段階と、
識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階と、
ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す段階と、
ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する段階とを有し、
識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階は、判断に用いる規則を格納した規則リポジトリを利用して、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを判断する段階を含み、
判断に用いる規則は、ユーザ対話アクションをクライアント側又はサーバ側での処理に関連付けることを特徴とするコンピュータ実施方法。
＜相違点＞
「識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階」における「判断に用いる規則」に関し、本件補正発明では「ユーザ対話がどのように処理されるべきかを動的に表現した規則」とし、「実行中の所定のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従って」いるのに対して、引用発明では「リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等を表現した規則（判定基準）」及び「収集された動作環境情報と判定基準に基づいて、所定の時間が経過したときに見直す規則（振分けルール）」である点。
（４）当審の判断
（４−１）相違点について
　引用発明の「リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等を表現した規則（判定基準）」は、リクエストの処理主体を判定するだけでなく、リクエストを処理する際に必要な要件を表現していることから、「リクエストをどのように処理されるべきかを表現した規則」といえる。また、引用発明の「収集された動作環境情報と判定基準に基づいて、所定の時間が経過したときに見直す規則（振分けルール）」は、経時的に動的な変化をする情報である「動作環境情報」を用いて所定の時間が経過したときに見直しを行っていることから「動的に表現した規則」といえる。
　更に、クライアント側又はサーバ側のどちらで処理するかを動的に判断する場合に「判断に用いる規則」が、シナリオ又はアプリケーションが実行されている「クライアント環境」や「サーバ環境」に従うことは、引用文献２（前記Ｆ及びＧ等参照）に記載されているように、本願の優先日前において当該技術分野における常套手段であった。
　そうすると、判断に用いる規則として、「リクエストをどのように処理するかを表現した規則」及び「動的に表現した規則」といえる引用発明における「リクエストを処理する際に使用される各ストレージの特定情報や、各ストレージの同期方法、同期タイミング等を表現した規則（判定基準）」及び「収集された動作環境情報と判定基準に基づいて、所定の時間が経過したときに見直す規則（振分けルール）」を、本件補正発明の如くユーザ対話がどのように処理されるべきかを動的に表現した規則とし、実行中の所定のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従うものとすることは、当業者が適宜なし得たことである。
（４−２）小括
　上記で検討したごとく、相違点に係る構成は、引用発明から当業者であれば適宜実施し得るものであり、そして、本件補正発明の奏する作用効果は、引用発明及び当該技術分野の周知技術の奏する効果から予測される範囲内のものに過ぎず、格別顕著なものということはできない。
　したがって、本件補正発明は、上記引用発明及び周知技術に基づいて当業者が容易にすることができたものであり、特許法第２９条２項の規定により、特許出願の際独立して特許を受けることができない。
６　むすび
　以上のとおり、前記「３　新規事項追加禁止要件」及び「４　補正の目的要件」で指摘したとおり、本件補正は、特許法第１７条の２第３項及び第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　また、仮に本件補正が、特許法第１７条の２第３項及び第５項に規定する要件を満たしていたとしても、前記「５　独立特許要件についての判断」で指摘したとおり、本件補正後請求項１に記載された発明は、特許出願の際独立して特許を受けることができるものでないから、本件補正は、特許法第１７条の２第６項の規定により準用する同法第１２６条第７項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、上記補正却下の決定の結論のとおり決定する。
第３　本願発明
１　本願発明
　平成２６年３月４日付けの手続補正は、上記のとおり却下されたので、本願の請求項に係る発明は、平成２５年１１月１９日付けの手続補正書の請求の範囲の請求項１〜請求項１５に記載された事項により特定されるものである。そして、その請求項１に係る発明（以下、「本願発明」という。）は、明細書及び図面の記載からみて、請求項１に記載された事項により特定される、以下のとおりのものである。（再掲する。）
「　コンピュータによって実施される、ユーザインタフェース操作の位置独立な実行のための方法であって、
　１つ以上のプロセッサによって実行される、
　サーバ側コンピュータに通信可能に接続されたクライアント側ユーザインタフェースを介してユーザ対話を識別する段階と、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階と、
　ユーザ対話がクライアント側で処理されるものであった場合、クライアント側アクションハンドラを呼び出す段階と、
　ユーザ対話がサーバ側で処理されるものであった場合、サーバ側アクションハンドラによる対話の処理を要求する段階と
　を有し、
　識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを動的に判断する段階は、ユーザ対話がどのように処理されるべきかを動的に表現した規則を格納した規則リポジトリを利用して、識別したユーザ対話をクライアント側又はサーバ側のどちらで処理するかを判断する段階を含み、
　ユーザ対話がどのように処理されるべきかを動的に表現した規則は、所定のシナリオ及び／又は環境下でのユーザ対話アクションを、クライアント側又はサーバ側での処理に関連付けることを特徴とするコンピュータ実施方法。」
２　引用文献等に記載されている技術的事項、及び引用発明の認定
　
　原査定の拒絶の理由に引用された，引用文献及びその記載事項及び引用発明は，前記「第２　平成２６年３月４日付け手続補正について補正却下の決定」の「５　独立特許要件についての判断」の「（２）引用文献等に記載されている技術的事項、及び引用発明の認定」に記載したとおりである。
　
３　対比・判断
　
　本願発明は，前記「第２　平成２６年３月４日付け手続補正について補正却下の決定」の「５　独立特許要件についての判断」で検討した本件補正発明から、本願発明の「ユーザ対話がどのように処理されるべきかを動的に表現した規則」を限定する事項である「実行中のシナリオ又はアプリケーションに従って、及び／又は、シナリオ又はアプリケーションが実行されている環境に従って」を削除し、「ユーザ対話アクション」を限定する事項である「所定のシナリオ及び又は環境下での」を追加したものである。
　ここで、本願発明の「所定のシナリオ及び又は環境下でのユーザ対話アクション」について検討する。
　引用発明の「リクエスト」は本願発明の「ユーザ対話アクション」に相当し、クライアント端末又はサーバ装置で処理されることから、何らかのシナリオ及び又は環境下で処理されることは自明である。また、本願発明の「ユーザ対話アクション」は、コンピュータによって実施していることから、何らかのシナリオ又は環境下にあることは自明である。即ち、引用発明の「リクエスト」から、本願発明の「ユーザ対話アクション」に「所定のシナリオ又は環境下での」という限定する事項を追加して、「所定のシナリオ及び又は環境下でのユーザ対話アクション」とすることは、周知慣用手段を追加しているに過ぎず、実質的な差異はなく、例示するまでもなく当業者が適宜なし得ることである。
　そうすると，請求項１記載の発明の構成要件を全て含み、さらに特定の構成要件に限定要件を付加したものに相当する本件補正発明が、前記「第２　平成２６年３月４日付け手続補正について補正却下の決定」の「５　独立特許要件についての判断」の「（２）引用文献等に記載されている技術的事項、及び引用発明の認定」乃至「（４）当審の判断」に記載したとおり、引用発明及び引用文献２及び当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから、上記特定の限定を省き周知慣用手段を追加することは、本願発明も同様の理由により、引用発明、引用文献２及び当該技術分野の周知技術に基づいて、当業者が容易に発明することができたものである。
４　結び
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明を検討するまでもなく，本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。