【事件の表示】
　特願２００７−１１３４６５「既存のインテーグレイテッド・インターフェイス・バックグラウンド上への新しいユーザインターフェイスのマッピング」拒絶査定不服審判事件〔平成１９年１１月　８日出願公開、特開２００７−２９３８６０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯 
　本願は、平成１９年４月２３日を出願日（優先権主張日：２００６年４月２５日、米国）とする出願であって、平成２３年６月９日付けで拒絶理由通知がなされ、同年９月１４日付けで意見書の提出とともに手続補正がなされたが、平成２４年２月２７日付けで拒絶査定がなされ、これに対して同年７月２日付けで拒絶査定不服審判請求がなされるとともに同日付けで手続補正がなされ、原審において同年８月３１日付けで拒絶理由通知がなされ、同年１２月１１日付けで意見書の提出とともに手続補正がなされ、原審において平成２５年１月２１日付けで拒絶理由通知がなされ、同年５月２９日付けで意見書の提出とともに手続補正がなされ、当審による同年７月２２日付けの前置報告を引用した審尋に対して、同年１０月１８日に回答がなされたものである。 
 　 
２．本願発明について
（１）本願の特許請求の範囲の請求項１は、平成２５年５月２９日付けの手続補正により補正された以下のとおりのものである。
「【請求項１】
　コンピュータにおいて実装される方法であって、
　第１のユーザインターフェイスから、特定の処理プロセスに対する入力データを受け取るステップと、
　前記入力データを、マッピング情報を記憶したインターミディアリへ送信するステップと、
　前記インターミディアリが、前記マッピング情報を使用して、前記入力データを、インテグレーテッドアプリケーションの古いインターフェイスロジックによって受け入れ可能な入力に対応するデータへマッピングするステップと、
　前記マッピングされた入力データを前記古いインターフェイスロジックへ送信するステップと、
　前記古いインターフェイスロジックに統合された、前記インテグレーテッドアプリケーションのトランザクショナルロジックによって、前記マッピングされた入力データを処理して更新データを取得するステップと、
　前記マッピング情報を使用して前記更新データを前記古いインターフェイスロジックから前記インターミディアリへ送信するステップと、
　前記インテグレーテッドアプリケーションの前記古いインターフェイスロジックとは異なる新しいインターフェイスロジックを用いる新しいユーザインターフェイスを提供するステップであって、前記特定の処理プロセスに含まれる複数の段階を示すプロセスチェーンと、前記特定の処理プロセス内における現在の段階との双方を表示し、前記更新データを用いる新しいユーザインターフェイスを提供するステップと、
　を含むことを特徴とする方法。」
（２）上記請求項１における「前記マッピング情報を使用して前記更新データを前記古いインターフェイスロジックから前記インターミディアリへ送信するステップ」との記載について検討する。
　当該ステップは、「前記更新データ」を「前記古いインターフェイスロジック」から、「前記インターミディアリ」に送信する際に、「前記マッピング情報」を使用するというものである。
　ところで、当該ステップは上記平成２４年７月２日付けの手続補正により限定されたものであり、同日付けの審判請求書にはその補正の根拠について、「（２）補正の根拠の明示 　本審判請求書と同時提出の手続補正書に記載の請求項１は、平成２３年９月１４日付提出の手続補正書に記載の請求項（以下、「補正前の請求項」という）１に、補正前の請求項４、５を組み合わせて補正したものです。なお、当該補正事項は、例えば、本願明細書の段落［００１１］、［００１２］、［００１４］などの記載にも対応します。・・・」と記載されており、上記根拠として示された記載は以下のとおりである。
「【請求項４】
　前記第２のユーザインターフェイスはトランザクショナルロジックと統合されていることを特徴とする請求項１に記載の方法。」
「【請求項５】
　前記トランザクショナルロジックが、前記マッピングされた入力データを処理することを特徴とする請求項４に記載の方法。」
「【００１１】
　図４は、インターミディアリ（intermediary）プロセスを説明するために拡張されたモデル・ビュー・コントローラ・パラダイムの例を示す。図３中のモデル３０１は、トランザクショナルロジック及びコントローラからの入力のインタープリタとして動作した。図４では、インテグレーテッドアプリケーション４０７のモジュールのトランザクショナルロジック２０１は、ユーザ１００によるデータ入力について機能を実行する。インターミディアリ（intermediary）（この場合はコントローラ３００）とモデルのトランザクショナリロジック（この場合はインテグレーテッドアプリケーション４０７のモジュールのトランザクショナルロジック２０１）との間の相互作用の１つの方法は、コントローラ３０２がインターフェイスロジック２００により受け入れられる入力に対応するデータへマップするために使用するマッピング４００を有することである。コントローラ３００はデータのいくつかを記憶でき、そして、さらにデータの部分組及びコントローラ３００の他の情報を含む、データの異なる組又はデータの全体組みを、マッピング４００を介して送信３０２できる。データ及び「データの組」は送信されるデータのタイプ、データ・オブジェクトの組織、又は、送信方法に依存して交換可能に使用できる。コントローラ３００を介してインテクレーテッドアプリケーション４０７へ送られ３０２又は処理後に戻される途中のデータは記憶できる。例えば、もし、インテグレーテッドから戻って来る更新された情報はコントローラ３００を介して中継３０２され、そして新しい入力情報１０４と一緒に使用される場合、データはコントローラ３００により結合されて、新インターフェイスロジック３０４を更新するために送信３０５されることができる。
　【００１２】
　インターフェイスロジック２００がマップされたデータ３０６を受け取る時、トランザクショナルロジック２０１はもし必要ならばデータを処理しそしてデータを更新する。いずれのメッセージ、データ、又は、データの属性は、マッピング４００を介して送信３０６してコントローラ３００へ戻す３０２ことができる。コントローラ３００は、マップして戻されたデータの組を記憶する。コントローラはマップされたデータを新しいインターフェイスロジック３０４を更新するために使用できる。新しいインターフェイスロジック３０４は、ユーザ１００へ新しい表示を提供３０５するために、もし利用可能ならば、いずれの利用可能なデータ、データの属性、及びマッピング情報を取ることができる。」
「【００１４】
　図６は、インターミディアリ（intermediary）モジュールのマッピングを介して通信することにより古いインテグレーテッドアプリケーションのトランザクショナルロジックにアクセスする新しいＵＩによりユーザが持つであろう例示的な相互作用を示す。再び、時間が経過すると５０５、ユーザは入力スクリーン６００と６０１にデータを入力する。しかし、これらの入力スクリーンは、今、図５に示すようにトランザクショナルロジックと統合化されていないであろう新しいインターフェイスロジックを使用している。したがって、今、データがインターミディアリ（intermediary）、この場合はコントローラ３００、を介して送信されていて、コントローラ３００はデータを古いインターフェイスロジック２００へマッピング４００を介して送信して、トランザクショナルロジック２０１により処理されて、そして潜在的にデータ２０２を更新する。メッセージ、データ更新、及びデータ属性は、マッピングを中継して、直接的６０６又は間接的６０４のいずれかで６０５へ戻される。そして、マップされたデータは、コントローラ３００へ送信され、コントローラ３００はユーザ６０３へ新しい入力スクリーンを持つインターフェイスロジックを提供する。ユーザは動的に更新されたデータを見ることができる。なぜならば、処理はバックグランドで行われるが、「暗い」中では実行されない。」
  　
　しかしながら、上記請求項１における「前記入力データを、マッピング情報を記憶したインターミディアリへ送信するステップ」との記載、及び、上記第【００１１】段落の「インターミディアリ（intermediary）（この場合はコントローラ３００）とモデルのトランザクショナリロジック（この場合はインテグレーテッドアプリケーション４０７のモジュールのトランザクショナルロジック２０１）との間の相互作用の１つの方法は、コントローラ３０２がインターフェイスロジック２００により受け入れられる入力に対応するデータへマップするために使用するマッピング４００を有することである。」との記載によれば、「マッピング情報」（「マッピング４００」）は「インターミディアリ」（「コントローラ３００」を含む）」が有していることは明らかであり、また、上記第【００１２】段落の「いずれのメッセージ、データ、又は、データの属性は、マッピング４００を介して送信３０６してコントローラ３００へ戻す３０２ことができる。」との記載や、上記第【００１４】段落の「メッセージ、データ更新、及びデータ属性は、マッピングを中継して、直接的６０６又は間接的６０４のいずれかで６０５へ戻される。」との記載があるものの、上記請求項１における「前記マッピング情報を使用して前記更新データを前記古いインターフェイスロジックから前記インターミディアリへ送信する」との記載があるわけではないし、そもそも上記「前記更新データ」を「前記古いインターフェイスロジック」から、「前記インターミディアリ」に送信するのに、インターミディアリが有する「前記マッピング情報」を使用するというのは技術的にも意味不明である。
　よって、上記請求項１における「前記マッピング情報を使用して前記更新データを前記古いインターフェイスロジックから前記インターミディアリへ送信するステップ」における「前記マッピング情報を使用して」は誤記であると認める。
　　
　したがって、本願の請求項１に係る発明（以下、「本願発明」という。）を、以下のように認定する。
「コンピュータにおいて実装される方法であって、
　第１のユーザインターフェイスから、特定の処理プロセスに対する入力データを受け取るステップと、
　前記入力データを、マッピング情報を記憶したインターミディアリへ送信するステップと、
　前記インターミディアリが、前記マッピング情報を使用して、前記入力データを、インテグレーテッドアプリケーションの古いインターフェイスロジックによって受け入れ可能な入力に対応するデータへマッピングするステップと、
　前記マッピングされた入力データを前記古いインターフェイスロジックへ送信するステップと、
　前記古いインターフェイスロジックに統合された、前記インテグレーテッドアプリケーションのトランザクショナルロジックによって、前記マッピングされた入力データを処理して更新データを取得するステップと、
　前記更新データを前記古いインターフェイスロジックから前記インターミディアリへ送信するステップと、
　前記インテグレーテッドアプリケーションの前記古いインターフェイスロジックとは異なる新しいインターフェイスロジックを用いる新しいユーザインターフェイスを提供するステップであって、前記特定の処理プロセスに含まれる複数の段階を示すプロセスチェーンと、前記特定の処理プロセス内における現在の段階との双方を表示し、前記更新データを用いる新しいユーザインターフェイスを提供するステップと、
　を含むことを特徴とする方法。」
　
３．拒絶理由通知の概要
　原審における平成２４年８月３１日付けの拒絶理由通知の概要は以下のとおりである。
「１．・・・（省略）・・・
２．この出願の請求項１−４０に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　　　　　　記
引用例１．特開２００４−５５６８号公報
　　　２．赤間信幸，．ＮＥＴエンタープライズＷｅｂアプリケーション開発技術大全  Ｖｏｌ．２  ＡＳＰ．ＮＥＴ基礎編，日経ＢＰソフトプレス  松崎  稔，２００４年　６月　７日，P.59
　　　３．中山  秀夫，もう「使い勝手」で悩ませない  ユーザーが喜ぶ画面設計の極意，日経ＩＴプロフェッショナル，日本，日経ＢＰ社，２００５年　９月　１日，P.21-43(特にP.28)
・・・（以下、省略）・・・」
    　
４．引用例
（４−１）本願の優先日前の２００４年１月８日に出願公開された特開２００４−５５６８号公報（以下、「引用例１」という。）には、図面とともに以下の各記載がある。なお、下線は当審で付加したものである。
（ａ）「【００１９】
【発明の実施の形態】
本発明は、レガシー・アプリケーションのＧＵＩを高速に体裁更新するための方法
（ｂ）「【００２７】
図５は、本発明の構成による、レガシー・アプリケーションに高速ＧＵＩ体裁更新をもたらすように構成されたシステムの絵図である。本発明によれば、このシステムは体裁更新サービス５２０を含み、これは、ホスト・サーバ５１０内のレガシー・アプリケーションのコンテンツを、例えばウェブ・ブラウザなどのコンテンツ・ブラウザ５３０中や、そのようなマークアップ言語インタープリタ中に表示するのに適したコンテンツに変換することができる。
（ｃ）「【００３６】
図１１は、複数のコンテンツの変換および置換を示すために、テンプレート中のタグのサンプル・サブセットをリストする。タグＡ、Ｂ、Ｃは同じオリジンからコンテンツを抽出するが、タグＤはオリジン・コンテンツを異なるコンテンツ・ソースで置換している。それでもなお、すべての変換は同じ実行環境内で行われる。したがって、複数のコンテンツ・オリジンを達成することができる。図１１のリストから明らかであろうが、タグ定義をオリジン属性でさらに一般化して、各レイアウト・グリッド中により多くのフレキシビリティをもたらすことができる。タグは、オーサリング・ツールを使用してそれぞれのグリッドの外部で移動させることができる。特に、タグＥは、タグが他のカスタム・タグ定義とも共存できるという概念を示している。図８は、体裁更新サービス８１０、例えば図５の体裁更新サービス５２０の概略図である。
体裁更新サービス８１０は、制御サーブレット８１５、コンテンツ・ハンドラ８３５、テンプレート・マッチング・サブプロセス８４５、および出力変換サブプロセス８３０を備えることができる。コンテンツ・ハンドラ８３５は、コンテンツ・プラグ８７０によって指定されるコンテンツ・タイプを認識することができる。簡単に言えば、各コンテンツ・プラグ８７０は、ホスト・サーバ８６５中のレガシー・アプリケーションの表示画面中にみられるかもしれない特定のコンテンツ・タイプを指定する。コンテンツがコンテンツ・ハンドラ８３５中で受け取られると、コンテンツ・ハンドラ８３５はコンテンツ・プラグ８７０と協議して、受け取ったコンテンツが指定のコンテンツ・タイプのいずれかと合致するかどうかを決定する。
【００３７】
受け取ったコンテンツの特定タイプがコンテンツ・ハンドラ８３５によって認識されると、テンプレート・マッチング・サブプロセス８４５は視覚ターゲット８７５中に表示されるようにコンテンツのＧＵＩ変換を実施するのに適した、合致するテンプレートを突き止めることができる。これが識別されると、出力変換サブプロセス８３０は選択されたテンプレートを適用して、それがサポートするＧＵＩ変換を生み出すことができる。
【００３８】
具体的には、出発インターセプタ８２５が、テンプレート・マッチング・サブプロセス８４５を使用して、受け取られたコンテンツのためのテンプレートを選択することができる。その後、出力変換サブプロセス８３０が、このテンプレートを処理して、ＧＵＩ体裁更新を行うことができる。さらに、テンプレートに組み込まれたマッピング関係が、抽出メソッド８５５とＧＵＩ要素クラス８６０の両方において表される変換インテリジェンスの実行をトリガする。」
（ｄ）「【００３９】
体裁更新サービス８１０は往復変換を実現することができるので、ホスト・サーバ８６５からのコンテンツが視覚ターゲット８７５中に変換された後は、視覚ターゲット８７５とのユーザ対話には応答データをホスト・サーバ８６５に転送し返すことが必要になると予想され得る。これに関し、到着インターセプタ８４０は、視覚ターゲット８７５からの入力フィールドをホスト・サーバ８６５中での処理に適したオリジン・フォーマットに再変換するために、入力変換サブプロセス８２０を使用することができる。
（ｅ）【図５】には、「ホストサーバ」と「体裁更新サービス」が接続され、「体裁更新サービス」と「コンテンツブラウザ」が接続されている図が示されており、上記「体裁更新サービス」もコンピュータを表す図形で記載されている。
   　
　ここで、上記（ａ）乃至（ｅ）の記載について検討する。
（ア）上記（ａ）によると、引用例１はレガシー・アプリケーションのＧＵＩを高速に体裁更新するための方法について記載されたものであることがよみとれる。
（イ）上記（ｂ）によると、レガシー・アプリケーションに高速ＧＵＩ体裁更新をもたらすように構成されたシステムは、体裁更新サービスを含み、該体裁更新サービスがホスト・サーバ内のレガシー・アプリケーションのコンテンツを、ウェブ・ブラウザのマークアップ言語インタープリタ中に表示するのに適したコンテンツに変換するものであることがよみとれる。
　また、上記（ｅ）に示されるように、上記体裁更新サービスも、コンピュータで実現されるものであることは明らかである。
（ウ）上記（ｃ）によると、体裁更新サービスは、制御サーブレット、コンテンツ・ハンドラ、テンプレート・マッチング・サブプロセス、および出力変換サブプロセスを備えていることが記載されている。
　また、コンテンツ・プラグは、ホスト・サーバ中のレガシー・アプリケーションの表示画面中にみられるかもしれない特定のコンテンツ・タイプを指定するものであり、コンテンツがコンテンツ・ハンドラ中で受け取られると、コンテンツ・ハンドラはコンテンツ・プラグと協議して、受け取ったコンテンツが指定のコンテンツ・タイプのいずれかと合致するかどうかを決定するものであることがよみとれる。
　そして、受け取ったコンテンツの特定タイプがコンテンツ・ハンドラによって認識されると、テンプレート・マッチング・サブプロセスは視覚ターゲット中に表示されるようにコンテンツのＧＵＩ変換を実施するのに適した、合致するテンプレートを突き止め、これが識別されると、出力変換サブプロセスは選択されたテンプレートを適用して、それがサポートするＧＵＩ変換を生み出すことがよみとれる。
（エ）上記（ｄ）によると、体裁更新サービスは往復変換を実現することができ、ホスト・サーバからのコンテンツが視覚ターゲット中に変換された後は、視覚ターゲットとのユーザ対話により応答データをホスト・サーバに転送し返すことを可能としており、これに関し、到着インターセプタは、視覚ターゲットからの入力フィールドをホスト・サーバ中での処理に適したオリジン・フォーマットに再変換するために、入力変換サブプロセスを使用することがよみとれる。
　　
　以上、（ア）乃至（エ）を総合すると、引用例１には以下の発明（以下、「引用発明」という）が記載されていると認められる。
　　
「レガシー・アプリケーションのＧＵＩを高速に体裁更新するための方法であって、
　レガシー・アプリケーションに高速ＧＵＩ体裁更新をもたらすように構成されたシステムは、コンピュータで実現される体裁更新サービスを含み、該体裁更新サービスがホスト・サーバ内のレガシー・アプリケーションのコンテンツを、ウェブ・ブラウザのマークアップ言語インタープリタ中に表示するのに適したコンテンツに変換するものであり、
　体裁更新サービスは、制御サーブレット、コンテンツ・ハンドラ、テンプレート・マッチング・サブプロセス、および出力変換サブプロセスを備えており、
　コンテンツ・プラグは、ホスト・サーバ中のレガシー・アプリケーションの表示画面中にみられるかもしれない特定のコンテンツ・タイプを指定するものであり、
　コンテンツがコンテンツ・ハンドラ中で受け取られると、コンテンツ・ハンドラはコンテンツ・プラグと協議して、受け取ったコンテンツが指定のコンテンツ・タイプのいずれかと合致するかどうかを決定するものであり、受け取ったコンテンツの特定タイプがコンテンツ・ハンドラによって認識されると、テンプレート・マッチング・サブプロセスは視覚ターゲット中に表示されるようにコンテンツのＧＵＩ変換を実施するのに適した、合致するテンプレートを突き止め、これが識別されると、出力変換サブプロセスは選択されたテンプレートを適用して、それがサポートするＧＵＩ変換を生み出すものであり、
　さらに、体裁更新サービスは往復変換を実現することができ、ホスト・サーバからのコンテンツが視覚ターゲット中に変換された後は、視覚ターゲットとのユーザ対話により応答データをホスト・サーバに転送し返すことを可能としており、これに関し、到着インターセプタは、視覚ターゲットからの入力フィールドをホスト・サーバ中での処理に適したオリジン・フォーマットに再変換するために、入力変換サブプロセスを使用すること、
　を含む方法。」
  　
（４−２）本願の優先日前の２００４年６月７日に発行された「赤間信幸，．ＮＥＴエンタープライズＷｅｂアプリケーション開発技術大全  Ｖｏｌ．２  ＡＳＰ．ＮＥＴ基礎編，日経ＢＰソフトプレス  松崎  稔，２００４年６月７日，P.59」（以下、「引用例２」という。）には、図面とともに以下の記載がある。
（ｆ）「しかし、特にウィザード形式で進行するようなＷｅｂアプリケーションなどを考えると分かるように、実際のアプリケーションでは画面間で何らかの情報を引き渡したりデータを保持しながら処理を進める必要がある。例えば図３−２３のようなｅ−コマースサイトのＷｅｂアプリケーションの場合、選択したカテゴリや商品の情報、ショッピングカートの中身に関する情報を、ポストバックや画面遷移にまたがって保持しつづけなければならない。」（第５９頁第２〜６行）
（ｇ）「図３−２３　ｅ−コマースサイトのＷｅｂアプリケーションの例」には、「トップページ」、「カテゴリ表示ページ」、「商品表示ページ」、及び、「カート内容確認」の各画面が、選択情報に応じて遷移する図が示されている。
   　
（４−３）本願の優先日前の２００５年９月１日に発行された「中山秀夫，もう「使い勝手」で悩ませない  ユーザーが喜ぶ画面設計の極意，日経ＩＴプロフェッショナル，日本，日経ＢＰ社，２００５年９月１日，P.21-43」（以下、「引用例３」という。）には、図面とともに以下の記載がある。
（ｈ）特に第２８頁には、「いくつもの画面にまたがる操作をしているとき、「この画面が何の処理をするためのものか、一瞬分からなくなった」、「いつまでこの操作を続けなければならないのか分からず、不安になった」といった経験はありませんか？１つのシステムの機能や画面数が増えると、こうした事態が起きやすくなります。そこで必要なのが、ユーザーが今どこのページにいるのか、処理がどれくらい進んだのかを示すことです（図４）。
　通常、システムの機能は階層構造になっており、画面もその構造に対応しています。そこで、ユーザーが現在開いている画面（操作している機能）が、どの階層にあるのかを示します。ちなみに、深い階層はユーザーに自分の現在位置を分かりにくくさせる原因となります。１つの機能に関する操作は、できるだけ少ない画面で完結するように設計しましょう。私は、１つの機能に関する操作はできるだけ３階層（画面）以内にとどめるようにしています。
　階層と同時に、プロセスの進ちょく状況も示しましょう。「顧客新規登録」という作業を何画面にもまたがって進めなければならないシステムがあるとします。そのシステムの画面では、情報を入力・閲覧するメインの領域の上部に「顧客情報新規登録＜１／４＞」、「顧客情報新規登録＜２／４＞」といった具合に進ちょく状況を示すのです。もしくは「ＳＴＥＰ１」、「ＳＴＥＰ２」、「ＳＴＥＰ３」とボックスを並べて、現在のプロセスだけ色を変えて示す、という方法もあります。」
   　
５．対比
　そこで、本願発明と引用発明とを対比する。
（５−１）引用発明の「レガシー・アプリケーションのＧＵＩを高速に体裁更新するための方法」は、「コンピュータで実現される体裁更新サービス」、「ホスト・サーバ内のレガシー・アプリケーション」及び「ウェブ・ブラウザ」というコンピュータにおいて実装される方法であることは明らかである。
　そうすると、本願発明と引用発明は、
「コンピュータにおいて実装される方法」
である点で共通する。
（５−２）引用発明における「さらに、体裁更新サービスは往復変換を実現することができ、ホスト・サーバからのコンテンツが視覚ターゲット中に変換された後は、視覚ターゲットとのユーザ対話により応答データをホスト・サーバに転送し返すことを可能としており」は、ウェブ・ブラウザに表示された視覚ターゲットとのユーザ対話により、応答データをホスト・サーバに転送し返す処理であり、このウェブ・ブラウザに表示された「視覚ターゲット」は本願発明の「第１のユーザインターフェイス」に相当するものである。
　また、引用発明の応答データも、上記視覚ターゲットで特定される処理プロセスに対する応答であるし、また、ウェブ・ブラウザがユーザからの上記応答データを受け取っていることは明らかである。
　そうすると、本願発明と引用発明は、後記する点を除いて、
「第１のユーザインターフェイスから、特定の処理プロセスに対する入力データを受け取るステップ」
を備える点で共通する。
（５−３）引用発明における「さらに、体裁更新サービスは往復変換を実現することができ、ホスト・サーバからのコンテンツが視覚ターゲット中に変換された後は、視覚ターゲットとのユーザ対話により応答データをホスト・サーバに転送し返すことを可能としており、これに関し、到着インターセプタは、視覚ターゲットからの入力フィールドをホスト・サーバ中での処理に適したオリジン・フォーマットに再変換するために、入力変換サブプロセスを使用すること」によると、ウェブ・ブラウザは受け取った応答データを体裁更新サービスへ送信し、該体裁更新サービスでは、上記応答データをホスト・サーバ中での処理に適したオリジン・フォーマットに再変換した上で上記ホスト・サーバに転送する処理が行われるものであることから、引用発明の「体裁更新サービス」は本願発明の「インターミディアリ」に対応するものである。
　また、ここで行われる再変換処理は、上記ホスト・サーバ内のレガシー・アプリケーションで処理に適したオリジン・フォーマットに変換すること、すなわちレガシー・アプリケーションのインターフェイスが受け入れ可能なオリジン・フォーマットへ変換、つまりマッピングすることであるから、引用発明における「レガシー・アプリケーション」は本願発明の「インテグレーテッドアプリケーション」に対応するものである。
　また、本願発明でいう「インターフェイスロジック」との語は、「インテグレーテッドアプリケーション」のインターフェイス部を意味するものと解されることから、引用発明における「レガシー・アプリケーション」のインターフェイス部も「インターフェイスロジック」であるといえ、また、引用発明のウェブ・ブラウザで使用されるインターフェイスに対して、ホスト・サーバ内のレガシー・アプリケーションのインターフェイスは、“レガシー”つまり古いインターフェイスであるといえる。
　そうすると、本願発明と引用発明は、後記する点を除いて、
「前記入力データを、インターミディアリへ送信するステップと、
　前記インターミディアリが、前記入力データを、インテグレーテッドアプリケーションの古いインターフェイスロジックによって受け入れ可能な入力に対応するデータへマッピングするステップと、
　前記マッピングされた入力データを前記古いインターフェイスロジックへ送信するステップ」
を備える点で共通する。
（５−４）引用発明の「体裁更新サービスは、制御サーブレット、コンテンツ・ハンドラ、テンプレート・マッチング・サブプロセス、および出力変換サブプロセスを備えており、コンテンツ・プラグは、ホスト・サーバ中のレガシー・アプリケーションの表示画面中にみられるかもしれない特定のコンテンツ・タイプを指定するものであり、コンテンツがコンテンツ・ハンドラ中で受け取られると、コンテンツ・ハンドラはコンテンツ・プラグと協議して、受け取ったコンテンツが指定のコンテンツ・タイプのいずれかと合致するかどうかを決定するものであり、受け取ったコンテンツの特定タイプがコンテンツ・ハンドラによって認識されると、テンプレート・マッチング・サブプロセスは視覚ターゲット中に表示されるようにコンテンツのＧＵＩ変換を実施するのに適した、合致するテンプレートを突き止め、これが識別されると、出力変換サブプロセスは選択されたテンプレートを適用して、それがサポートするＧＵＩ変換を生み出すものであり」によると、体裁更新サービスは、ホスト・サーバ中のレガシー・アプリケーションの表示画面に相当するコンテンツを、テンプレートを使用してウェブ・ブラウザのマークアップ言語インタープリタ中に表示するのに適したコンテンツに変換する処理を行うものであり、このウェブ・ブラウザのマークアップ言語インタープリタ中に表示するのに適したコンテンツは、上記ホスト・サーバ中のレガシー・アプリケーションの表示画面に相当するコンテンツに対して、新しいユーザインターフェイスを提供するものである。
　そうすると、本願発明と引用発明は、後記する点を除いて、
「データを前記古いインターフェイスロジックから前記インターミディアリへ送信するステップと、
　前記インテグレーテッドアプリケーションの前記古いインターフェイスロジックとは異なる新しいインターフェイスロジックを用いる新しいユーザインターフェイスを提供するステップであって、前記データを用いる新しいユーザインターフェイスを提供するステップ」
を備える点で共通する。
（５−５）以上のことから、本願発明と引用発明とは、
　　
「コンピュータにおいて実装される方法であって、
　第１のユーザインターフェイスから、特定の処理プロセスに対する入力データを受け取るステップと、
　前記入力データを、インターミディアリへ送信するステップと、
　前記インターミディアリが、前記入力データを、インテグレーテッドアプリケーションの古いインターフェイスロジックによって受け入れ可能な入力に対応するデータへマッピングするステップと、
　前記マッピングされた入力データを前記古いインターフェイスロジックへ送信するステップと、
　データを前記古いインターフェイスロジックから前記インターミディアリへ送信するステップと、
　前記インテグレーテッドアプリケーションの前記古いインターフェイスロジックとは異なる新しいインターフェイスロジックを用いる新しいユーザインターフェイスを提供するステップであって、前記データを用いる新しいユーザインターフェイスを提供するステップと、
　を含むことを特徴とする方法。」
　である点で一致し、以下の点で相違する。  
　　
［相違点１］
　本願発明の「インターミディアリ」は「マッピング情報」を記憶しており、該「前記マッピング情報を使用して、前記入力データを、インテグレーテッドアプリケーションの古いインターフェイスロジックによって受け入れ可能な入力に対応するデータへマッピングする」のに対し、引用発明の「体裁更新サービス」ではそのようになっていない点。
　　
［相違点２］
　本願発明では、「前記古いインターフェイスロジックに統合された、前記インテグレーテッドアプリケーションのトランザクショナルロジックによって、前記マッピングされた入力データを処理して更新データを取得するステップ」と「前記更新データを前記古いインターフェイスロジックから前記インターミディアリへ送信するステップ」を備えているが、引用発明ではそのようになっていない点。
　　　
［相違点３］
　本願発明では「前記特定の処理プロセスに含まれる複数の段階を示すプロセスチェーンと、前記特定の処理プロセス内における現在の段階との双方を表示し、前記更新データを用いる新しいユーザインターフェイスを提供する」を備えているのに対し、引用発明ではそのようになっていない点。
      　
６．当審の判断
（６−１）［相違点１］について
　引用発明の「体裁更新サービス」では「視覚ターゲットからの入力フィールドをホスト・サーバ中での処理に適したオリジン・フォーマットに再変換する」処理が行われているものの、確かに本願発明の「マッピング情報」に相当する情報を使用することについての記載はない。
　しかしながら、引用発明においてもフォーマットの変換を行っているのであるから、そこには変換のための規則が存在することは明らかであり、当該変換のための規則を「マッピング情報」として記憶し、変換すなわちマッピングのために使用することは当業者であれば容易に想到しえたことである。
　よって、当該相違点１は格別なものとはいえない。
　　
（６−２）［相違点２］について
　引用発明では、該体裁更新サービスがホスト・サーバ内のレガシー・アプリケーションのコンテンツを、ウェブ・ブラウザのマークアップ言語インタープリタ中に表示するのに適したコンテンツに変換し、ユーザ対話による応答データを前記体裁更新サービスにおいてホスト・サーバ中での処理に適したオリジン・フォーマットに再変換し、ホスト・サーバに転送するまでの処理手順は特定しているが、その後の処理については記載されていない。
　しかしながら、一般にクライアントサーバシステムにおける業務処理では、クライアントからのユーザ入力に基づいて、サーバ側では情報の登録、更新、検索等の各種処理が行われ、前記処理の結果等を含む次の処理段階を提示するための画面を構成し、クライアントに送信する手順を繰り返すことにより業務を遂行することは、例えば上記引用例２に記載されているように周知の技術である。
　してみれば、引用発明においても複数の処理段階を構成する画面の遷移により業務を遂行する場合も当然考えられるのであるから、引用発明において上記周知の業務処理手順を遂行するために、オリジン・フォーマットに再変換されたユーザ対話による応答データに基づいて、ホスト・サーバ内のレガシー・アプリケーションが各種処理を行い、その処理結果等を含むレガシー・アプリケーションのコンテンツを構成し（本願発明の「前記古いインターフェイスロジックに統合された、前記インテグレーテッドアプリケーションのトランザクショナルロジックによって、前記マッピングされた入力データを処理して更新データを取得する」に相当する）、該コンテンツを体裁更新サービスに送信し（本願発明の「前記更新データを前記古いインターフェイスロジックから前記インターミディアリへ送信する」に相当する）、該体裁更新サービスにおいて、前記がホスト・サーバ内のレガシー・アプリケーションのコンテンツを、ウェブ・ブラウザのマークアップ言語インタープリタ中に表示するのに適したコンテンツに変換してウェブ・ブラウザに送信する手順を繰り返す構成とすることは、当業者であれば容易に想到しえたことである。
　よって、当該相違点２は格別なものとはいえない。
　　　
（６−３）［相違点３］について
　上記引用例３には、システムの機能が階層構造になっており、画面もその構造に対応している場合に、ユーザが現在開いている画面が、どの階層にあるのかが分からなくなるという課題を解決するために、ユーザーが現在開いている画面に、階層と同時にプロセスの進ちょく状況を示すことが記載され、その例として「ＳＴＥＰ１」、「ＳＴＥＰ２」、「ＳＴＥＰ３」とボックスを並べて、現在のプロセスだけ色を変えて示すことが示されており、また、例えば特開２００５−２４２６５７号公報（公開日：２００５年９月８日）にも画面に処理プロセスにおける複数の段階と現在の段階の双方を表示することが記載されており、画面に処理プロセスにおける複数の段階と現在の段階の双方を表示することは周知のユーザインターフェイスである。
　そして、引用発明においても、複数の処理段階を構成する画面の遷移により業務を遂行する際には、上記と同様の課題が生じることは明らかであるから、当該課題に対処するために上記周知のユーザインターフェイスを適用しようとすることは当業者ならば当然のことであるし、また、その適用に際し引用発明の体裁更新サービスでは、「コンテンツ・プラグは、ホスト・サーバ中のレガシー・アプリケーションの表示画面中にみられるかもしれない特定のコンテンツ・タイプを指定するものであり、コンテンツがコンテンツ・ハンドラ中で受け取られると、コンテンツ・ハンドラはコンテンツ・プラグと協議して、受け取ったコンテンツが指定のコンテンツ・タイプのいずれかと合致するかどうかを決定するものであり、受け取ったコンテンツの特定タイプがコンテンツ・ハンドラによって認識されると、テンプレート・マッチング・サブプロセスは視覚ターゲット中に表示されるようにコンテンツのＧＵＩ変換を実施するのに適した、合致するテンプレートを突き止め、これが識別されると、出力変換サブプロセスは選択されたテンプレートを適用して、それがサポートするＧＵＩ変換を生み出す」ものであって、上記「コンテンツ・プラグ」を用いてホスト・サーバ中のレガシー・アプリケーションの表示画面の遷移を認識可能であり、該認識した画面に応じた処理プロセスにおける複数の段階と現在の段階の双方を表示するテンプレートを選択するようにしてＧＵＩ変換を行うことが可能であるから、引用発明における体裁更新サービスに上記周知のユーザインターフェイスを適用することにより上記相違点に係る構成とすることは、当業者ならば格別の技術的困難性なく容易になしえたことである。
　よって、当該相違点３は格別なものとはいえない。
 　 
（６−４）まとめ 
　したがって、上記相違点に係る構成はいずれも格別なものとはいえず、本願発明は引用発明及び周知技術に基づいて当業者が容易に想到しえたものである。
　そして、本願発明の作用効果も、引用発明及び周知技術から当業者が予測できる範囲のものである。  
　　 　 
７．むすび 
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものであるから、その余の請求項について検討するまでもなく、本願は拒絶すべきものである。
　　
　よって、結論のとおり審決する。