【事件の表示】
　特願２００５−３２７６９９「特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）モデルを生成するための方法、システム、およびプログラム」拒絶査定不服審判事件〔平成１８年　６月２２日出願公開、特開２００６−１６４２５８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
（１）本件審判請求に係る出願（以下「本願」と記す。）は、
２００４年１２月６日（以下「優先日」と記す。）のアメリカ合衆国における出願を基礎とするパリ条約に基づく優先権主張を伴って、
平成１７年１１月１１日付けで出願されたものであって、
平成２０年８月１３日付けで審査請求がなされ、
同日付けで手続補正書が提出され、
平成２３年８月１５日付けで拒絶理由通知（平成２３年８月２３日発送）がなされ、
平成２３年１２月２１日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出され、
平成２４年１月１１日付けで拒絶査定（平成２４年１月１７日謄本発送、送達）がなされたものである。
　
（２）本件審判請求は
「原査定を取り消す、本願は特許をすべきものとする、との審決を求める。」との趣旨で、
平成２４年５月１４日付けでなされたものであり、
同日付けで手続補正書が提出され、特許法第１６２条の規定により前置審査に付され、
平成２４年８月２日付けで拒絶理由通知（平成２４年８月７日発送）がなされ、
平成２４年１１月２日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出され、
平成２５年２月１５日付けで最後の拒絶理由通知（平成２５年２月１９日発送）がなされ、
平成２５年５月１５日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出され、
平成２５年５月３０日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ、
平成２５年７月２２日付けで当該報告に対する意見を求める旨の審尋（平成２５年７月２３日発送）がなされ、
平成２５年１０月２１日付けで回答書が提出され、
平成２６年３月２７日付けで審尋（平成２６年４月１日発送）がなされ、
平成２６年７月１日付けで回答書が提出され、
平成２６年８月１８日付けで上記平成２５年５月１５日付けの手続補正書による補正を却下する旨の補正の却下の決定（平成２６年９月２日謄本発送・送達）がなされるとともに、
同日付けで拒絶理由通知（平成２６年８月１９日発送。以下「当審拒絶理由通知」と記す。）がなされ、
平成２６年１１月１９日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出されたものである。
　
　
２．本願発明の認定
　本願の請求項１に係る発明（以下「本願発明」と記す。）は、上記平成２６年１１月１９日付けの手続補正書により補正された特許請求の範囲、明細書及び図面の記載からみて、本願の特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものと認める。
　
＜本願発明＞
「第１の特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）を生成するための方法において、
　少なくとも１つの第２の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトから複数のマークアップ言語ベースのプラットフォーム非依存のＧＵＩフォーマットのＧＵＩオブジェクトに変換するステップと、
　前記プラットフォーム非依存のＧＵＩフォーマットのＧＵＩオブジェクトを前記第１の特定のプラットフォームによって生成するための前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトに変換するステップと
を含み、
　前記変換するステップは、プラットフォーム非依存マークアップ言語ベースのＧＵＩオブジェクトに関する見出しおよび関連値と、前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトに関する見出しおよび関連値とが関連付けて登録された変換マップを使用して、前記プラットフォーム非依存のＧＵＩフォーマットのＧＵＩオブジェクトを、前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトに変換するステップを含む、方法。」
　
　
３．先行技術
（１）引用文献
　本願の出願前である上記優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり、原審の拒絶査定の理由である上記当審拒絶理由通知において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。（下線は当審付与。）
　
＜引用文献１＞
特開平１０−４００８７号公報（平成１０年２月１３日出願公開）
　
　＜引用文献記載事項１−１＞
「【０００４】
この欠点を少なくとも部分的に解消するため、やはり固有ではあるが、交換のコアとなる中立的なピボット情報モデルをつくることにより、あるツールのフォーマットを中立かつ単一の共通中間フォーマットを経由して別のツールのフォーマットに変換することができるようにしたブリッジを開発するということからなる解決方法が考案された。
従って前記のように４個、５個または６個のツール間で相互に対話を行うとする場合、それぞれ４個、５個または６個のブリッジを開発するだけでよい、すなわち一つのツールあたり一つのブリッジにより前記交換コアにアクセスし、前記ツールのフォーマットを共有中間フォーマットに変換する。この種の解決方法の場合、すぐれた移植性を確保するため、この機能を果たすための固有言語が開発され書き込まれインタープリットされる、コンパクトで管理が簡単で機能的な調節がなされたプロプリエタリアプローチが採用された。事実、唯一つのプログラムをインタープリットするだけでよいので、この閉じた世界では移植はかなり顕著に簡単になる。
　
　＜引用文献記載事項１−２＞
「【００２０】
【発明の実施の形態】図１は、本発明による、ソフトウェア工学ツールＴａ、Ｔｂ、Ｔｃ、Ｔｄ、．．．、の集合体の中での有利なインタオペラビリティーを示す。前記ツールは、例えばアプリケーションの開発に関する情報をデータモデルの形態で交換する。ツールＴａ、Ｔｂ、Ｔｃ、Ｔｄは、それぞれ独自の環境下で独自の辞書とともに使用される異種開発ツールである。
これら四つのツール間のデータモデルの変換は、ツールＴａ、Ｔｂ、Ｔｃ、Ｔｄのうちの一つの独自のフォーマットを中立かつ単一の中間フォーマット、中立情報モデルＮＩＭ、を経由してツールのうちの別のツールの独自のフォーマットに変換することができるＢａ、Ｂｂ、Ｂｃ、Ｂｄなどのブリッジを使用して行われる。
　
　
＜引用文献２＞
特開平５−１５０９４１号公報（平成５年６月１８日出願公開）
　
　＜引用文献記載事項２−１＞
「【０００４】
【発明が解決しようとする課題】従来は上述したようにしてデータ形式の異なるプログラム間でデータの共有を可能にしているが、以下のような問題点がある。
【０００５】
他のプログラムに利用させるデータの形式をそのプログラム固有のデータ形式に変換するために利用者自身がコンバータを起動しなければならない
【０００６】
更新等が行われた変換後のデータを再度元のプログラムで利用する場合、データ形式を逆変換するために利用者自身が再度コンバータを起動しなければならない。この再変換を忘れると、更新等が行われる前のデータが利用されることになり、矛盾が生じる
【０００７】
複数のプログラム間で共有されるデータがデータ５３，５４の如く各々独立して作成されるため、管理が面倒になる
【０００８】
本発明はこのような従来の問題点を解決したもので、その目的は、扱うデータ形式が異なる複数のプログラム間のデータの共有を利用者の介在無しに可能にすると共にその管理も容易にすることにある
　
　＜引用文献記載事項２−２＞
「【００１０】
【作用】本発明のデータ共有方式においては、
或るプログラムＡがそれ固有のデータ形式で作成したデータａの書き込みを要求する
【００１１】具体的には例えば以下のような動作を行う。
【００１２】・前記所定のデータ形式として処理装置で実行される複数のプログラムのいずれのデータ形式とも相違するデータ形式（以下中間形式と称す）を採用する場合
データ共有管理部は、書き込みにかかるデータａの形式を中間形式に変換して記憶装置に格納する
【００１３】・前記所定のデータ形式として前記複数のプログラムのうちの予め定められた特定のプログラム（以下特定プログラムと称す）のデータ形式（以下特定形式と称す）を採用する場合
データ共有管理部は、書き込みを要求したプログラムＡが特定プログラムであればその書き込みデータａをそのまま記憶装置に格納し、特定プログラム以外のプログラムであれば、その書き込みデータａの形式を特定形式に変換して記憶装置に格納する。
【００１４】・前記所定のデータ形式として前記複数のプログラムの各々のデータ形式を採用する場合
データ共有管理部は、書き込みデータａの形式を書き込み要求したプログラムＡ以外のプログラムのデータ形式に変換し、元の書き込みデータａおよびデータ形式変換後の書き込みデータを各々のプログラム対応に記憶装置に格納する。
【００１５】その後、データ形式の異なるプログラムＢが、プログラムＡが書き込んだ上記のデータａを利用したいことからその読み出しを要求すると、データ共有管理部は、記憶装置に格納されている該当データの形式を必要に応じそのプログラム固有のデータ形式に変換して通知する。
【００１６】具体的には例えば以下のような動作を行う。
【００１７】・前記所定のデータ形式として中間形式を採用する場合
データ共有管理部は、記憶装置に格納されているデータａを読み出し、その形式を中間形式からプログラムＢ固有のデータ形式に変換して通知する
【００１８】・前記所定のデータ形式として特定形式を採用する場合
データ共有管理部は、読み出しを要求したプログラムＢが特定プログラムであれば記憶装置に格納されているデータａを読み出してそのままの形式で通知し、特定プログラム以外のプログラムであれば、記憶装置に格納されているデータａを読み出し、その形式を特定形式からプログラムＢ固有のデータ形式に変換して通知する。
【００１９】・前記所定のデータ形式として前記複数のプログラムの各々のデータ形式を採用する場合
データ共有管理部は、プログラムＢに対応して記憶装置に格納されているプログラムＢ固有のデータ形式に変換されたデータａを読み出して通知する。」
　
　
＜引用文献３＞
特開２００４−２２６７４３号公報（平成１６年８月１２日出願公開）
　
　＜引用文献記載事項３−１＞
「【００１４】
【発明が解決しようとする課題】
しかしながら、視覚障害者においては、全盲をはじめ、弱視者では視力の程度や見え方の特性が多岐にわたることや、障害の進み方などによる個人差などから、個々のユーザが最適な環境でＧＵＩ画面の情報を取得するには、個々に呈示形式が異なる複数の出力装置と多様な呈示の方法が必要である。これには、音声と点字、拡大文字と点字に加え、２次元触覚呈示との併用など、同時にマルチ形態的な感覚で情報を呈示することが情報の理解や取得に有利となることが考えられる。
【００１５】
一方で、多様化する情報社会では、
ＧＵＩ画面をＨＴＭＬやＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）など、標準化されたマークアップ言語で記述し、呈示形式の異なる複数の出力装置（呈示手段）で共通に情報を呈示することができるようにする必要性が高まっている
　
　＜引用文献記載事項３−２＞
「【００１６】
このような背景の中で、前記した従来の技術のように、ＧＵＩを視覚障害者に伝えるために音声や点字、拡大表示など、それぞれの機能に対応した出力技術があるが、これらはアプリケーションに応じて、独自のプログラムなどが組み込まれている。また、全盲者に対しては音声や点字の他に、２次元オブジェクトの触覚呈示や振動呈示、弱視者に対しては拡大、反転表示などの複数の出力呈示を併用したり、あるいは、弱視者の見やすい画面表示や触覚でわかりやすい画面に呈示したり、個々のユーザに最適となるような、多様な呈示方法に対応する有効な手段はなかった。
【００１７】
また、図５に示す出力呈示装置では、
それぞれのアプリケーションごとに個々の表示変換プログラムを開発することが必要となるため、開発の労力やコストが高くなるなどの問題があった
【００１８】
本発明は前記の問題点に鑑み創案されたものであり、ＧＵＩ環境で表示される画面情報を、リソースおよび呈示形式がそれぞれ異なる複数の呈示手段に依存しないデータとして提供し、ユーザが自分に最適なＧＵＩ環境で情報を得ることが可能なマルチ形態出力呈示装置、および、その出力呈示プログラムを提供することにある。」
　
　＜引用文献記載事項３−３＞
「【００１９】
【課題を解決するための手段】
本発明は前記の目的を達成するために、本発明にかかるマルチ形態出力呈示装置では、
ＧＵＩ環境で表示される画面情報を
前記呈示手段のそれぞれで共通に使用可能な形式に変換
呈示手段で呈示するために必要な情報に変換
【００２０】
かかる構成によれば、マルチ形態出力呈示装置は、ＧＵＩ環境で表示される画面情報が有する属性データおよび属性内容データについて、共通画面情報作成手段が検出し、かつ、あらかじめデータベースに記憶されており、属性データおよび属性内容データに対応づけられている形式に変換して共通画面情報として作成される。この共通画面情報としては、例えば、属性データおよび属性内容データを、各呈示手段で共通となる表形式に置き換えており、データ抽出表示出力変換手段が、その共通画面情報から各呈示手段に対応する情報として、その表形式から抽出すると共に変換してそれぞれの呈示手段のいずれかに出力している。」
　
　＜引用文献記載事項３−４＞
「【００６７】
次に、このように構成されたマルチ形態出力呈示システムの動作を説明する。はじめに、図２に示すように、データ再編成／タグ情報変換手段１１には、リソース２から、情報リソースの種類（バイナリ、ＢＭＬ、ＨＴＭＬ、ＣＳＶ）によって各種形式のデータのいずれかが送られてくる。それぞれの選択オブジェクト（図４で示す▲１▼、▲２▼…参照）の有する画面呈示情報やテキスト情報、あるいはリンク情報などの属性情報を、データ再編成／タグ情報変換手段１１により検出し、
あらかじめデータベース１４（図２参照）に記憶されているタグ情報変換則
　
　
＜引用文献４＞
特開２００２−１４９４１８号公報（平成１４年５月２４日出願公開）
　
　＜引用文献記載事項４−１＞
「【０００７】
【発明が解決しようとしている課題】近年のアプリケーションは、ユーザーが利用しやすいように、ＧＵＩ（グラフィカルユーザーインタフェイス）を持つ。ＧＵＩは、ＧＵＩ定義により、所望のメニューを表示する。ＧＵＩ定義の内容は、使用しているＧＵＩツールにより、その内容が異なるため、移植元と移植先で使用するＧＵＩツールが異なる場合には、メニューを作成する時に、必要となる情報に過不足が生じ、移植先で正しいメニューの作成が困難となるという問題がある。
【０００８】例えば、ＵＮＩＸ上で、Ｘ１１／Ｍｏｔｉｆ（第１のプラットフォーム）１２０を使用して作成したＵＮＩＸアプリケーションプログラム１００を、ＷｉｎｄｏｗｓＮＴ（第２のプラットフォーム）に移植する場合には、Ｘ１１／ＭｏｔｉｆのＧＵＩ定義では、メニューの外枠の位置とサイズが定義されているだけであり、メニューを構成する各部品１つ１つの位置とサイズは定義されていない。しかし、ＷｉｎｄｏｗｓNTでは、メニューの中に配置された各部品を作成する場合は、部品の位置と大きさが必要となる。
【０００９】部品の位置とサイズ以外に、ＧＵＩを定義する情報としては、色、フォント名、描画方向、配列、陰影、ピクスマップ名、部品の親子関係（階層関係）、部品の配置方法とサイズ変更時の振る舞い、部品の状態（Ｏｎ／Ｏｆｆ），スケール、テキスト部品等の部品自身が持つ値、文字列等がある。
【００１０】従
来技術では、移植先でＧＵＩ定義情報が不足する場合には、人手で入力する必要があり、その作業には、多大な工数を必要とするという問題があった
【００１１】従って、
本発明の目的は、移植元で作成されたアプリケーションプログラムのＧＵＩ定義を移植先で利用して、同一メニューを生成するためのアプリケーションの移植方法、そのシステム、記憶媒体及びプログラムを提供するにある
【００１２】又、本発明の他の目的は、
少ない工数でアプリケーションプログラムを移植するためのアプリケーションの移植方法、そのシステム、記憶媒体及びプログラムを提供するにある
　
　＜引用文献記載事項４−２＞
「【００３１】
図５は、本発明の一実施の形態のＧＵＩ変換ツールの構成図、図６は、図５の変換プログラムの処理フロー図、図７は、その変換動作説明図、図８は、変換メニュー例の説明図、
【００３２】図５に示すように、ＵＮＩＸ環境における入出力関係は、Ｘ１１／ＭｏｔｉｆのＧＵＩ定義３５を用いて、ＵＮＩＸアプリケーション１０が表示装置１に、メニュー、図形を表示する。ＷｉｎｄｏｗｓＮＴ環境における入出力関係は、ＧＵＩ定義３４を用いて、ＷｉｎｄｏｗｓNＴアプリケーション１０が表示装置２に、メニュー、図形を表示する。
【００３３】
ＧＵＩ定義変換プログラム４は、ＵＮＩＸ環境において、Ｘ１１／ＭｏｔｉｆのＧＵＩ定義３５を用いて、Ｘ１１／ＭｏｔｉｆのＧＵＩ定義に不足している部品（メニューのリスト等）の位置、サイズを追加し、ＧＵＩ定義ファイル３４を作成する
【００３４】具体的には、ＧＵＩ定義３５を読み込んで作成したメニューは、親ウィンドウを頂点にして、子ウィンドウが階層的に順次配置されているため、一番上の親ウィンドウから順次子ウィンドウを辿ることができる。そこで、全てのウィンドウを辿っていき、それぞれのウィンドウの表示状態における位置とサイズを取り出し、ＧＵＩ定義の記述形式に従って出力することにより、位置とサイズが入ったＧＵＩ定義ファイル３４を生成する。
・・・中略・・・
【００４６】このようにして、Ｘ１１／ＭｏｔｉｆのＧＵＩ定義３５を用いて、Ｘ１１／ＭｏｔｉｆのＧＵＩ定義に不足している部品（メニューのリスト等）の位置、サイズを追加し、ＧＵＩ定義ファイル３４を作成することができる。
【００４７】又、ＧＵＩ定義３５を読み込んで作成したメニューが、親ウィンドウを頂点にして、子ウィンドウが階層的に順次配置されているため、一番上の親ウィンドウから順次子ウィンドウを辿り、それぞれのウィンドウの表示状態における位置とサイズを取り出し、ＧＵＩ定義の記述形式に従って出力することにより、位置とサイズが入ったＧＵＩ定義ファイル３４を自動生成できる。
【００４８】上述した実施の形態では、Ｘ１１／Ｍｏｔｉｆを使用したＵＮＩＸアプリケーションから、ＷＩＮ３２ＡＰＩを使用したＷｉｎｄｏｗｓアプリケーションへの移植を例に説明したが、ＧＵＩ定義情報を表示した状態から取得できる他のＧＵＩツール及び各種ＯＳの組み合わせの相互間での移植に適用できる。例えば、ＧＵＩツールとして、Ｘ１１／Ｍｏｔｉｆ、ＷＩＮ３２ＡＰＩの他に、Ｘ／Ｖｉｅｗ（ＯｐｅｎＷｉｎｄｏｗ），ＳｕｎＶｉｅｗ，Ｊａｖａ等にも適用でき、移植の対象となるＯＳとして、ＵＮＩＸ（Ｓｏｌａｒｉｓ，ＦｒｅｅＢＳＤ，Ｌｉｎｕｘ），Ｗｉｎｄｏｗｓ（ＮＴ／９５／９８／２０００），ＭａｃＯＳ，ＯＳ／２等にも適用できる。」
　
　
＜引用文献５＞
特開２００３−３３０７１２号公報（平成１５年１１月２１日出願公開）
　
　＜引用文献記載事項５−１＞
「【０００４】
【発明が解決しようとする課題】携帯装置のアプリケーションの開発が困難な1つの理由は、携帯装置の異質性である。多種多様なディスプレイのサイズ、解像度、コマンドの入力方法、そしてGUIライブラリがあるため、アプリケーションの開発者は、各装置プラットフォームのグラフィカルユーザインターフェイス(GUI)用に、アプリケーションを再設計及び再実装する必要がある。たくさんの異なる携帯装置が利用され、または市場に参入しているので、
再設計と再実装に、たくさんの労働力と生産コストを要する努力が現在もなされている
【０００５】１つの解決策は、モデルベース技術による開発である。１つの例が、ユーザインターフェイスモデリングである。一般的に、ユーザインターフェイスモデリングは、プラットフォームモデル、プレゼンテーションモデル、そしてタスクモデルを含む。プラットフォームモデルでは、サポートされる装置用のユーザインターフェイスを形成する操作機能が示される。プレゼンテーションモデルでは、サポートされる装置に関連したユーザインターフェイスの外観に関する階層、及び様式の選択と配置が示される。タスクモデルでは、サポートされる装置のユーザが実行するタスクが示される。この技術を使用することにより、特定の装置用のインターフェイスの生成のため、異なるモデル間におけるマッピングが開発されると思われる。
【０００６】モデルベース型アプローチの実装は、モデルを実装するためのハイレベル言語の開発を含んでいる。さらに開発者は、装置をサポートするためにモデルの重要な部分を設定し、かつ特定する。ハイレベル言語は非常に複雑なので、モデルベース型アプローチを実行する前に、開発者は、実行メカニズムの知識とハイレベル言語を共に学ぶ必要がある。さらにモデルベース型アプローチは、開発者が作った異なるモデルに基づくコードを作成する。装置のユーザインターフェイス要求においては小さな差異でも、２つの似たタイプの装置用に生成されたコードにおいては大きな差異になることもある。
従って開発者に求められるプログラミング技能のレベルは、とても重要になってくる
　
　＜引用文献記載事項５−２＞
「【００３２】図１は、拡張性のあるグラフィカルユーザインターフェイス(SGUI)システム１０のある実施形態のブロック図である。SGUIシステム１０は、拡張性のあるGUIライブラリモジュール１２、カスタマイズモジュール１４、そしてレンダーマネージャモジュール１６を持っている。図に描かれた実施形態は、本発明の理解を助けるためのものであり、これらの装置は個々に独立したものではなく、同図より少ないまたは多い装置が、SGUIシステム１０を説明している様々な実施形態で利用されてもよい。
【００３３】拡張性のあるGUIライブラリモジュール１２は、拡張性のあるアプリケーションの開発中において、アプリケーションの開発者が使用するツールであってもよい。さらに、拡張性のあるGUIライブラリモジュール１２は、SGUIシステム１０による中間表現と共に使用するため、GUIコンポーネントのライブラリを提供してもよい。ある実施形態において、装置プラットフォーム独立型APIは、拡張性のあるアプリケーションの開発中において使用されてもよい。また中間表現を作るため、装置プラットフォーム独立型APIは、装置プラットフォーム独立型のアプリケーションGUI内に、アプリケーション開発者により実装されてもよい。したがって、装置プラットフォーム独立型のアプリケーションGUIを使用して中間表現のインスタンス化には、拡張性のあるGUIライブラリモジュール１２内において、装置プラットフォーム独立型のAPIを実行することが含まれる。中間表現のインスタンス化は、中間表現は装置プラットフォーム独立型のプレゼンテーションモデルということを表している図１において、「装置独立型中間表現」となっている。
・・・中略・・・
【００３８】
変換マネージャモジュール２０は、中間表現を装置プラットフォーム依存型のプレゼンテーションに変換するように動く。
・・・中略・・・
【００４１】SGUIシステム１０の好ましい実施形態において、SGUIシステム１０は、ターゲット装置プラットフォームに対しアプリケーションGUIの継ぎ目のないスケーリングを提供するため、拡張性のあるアプリケーションと連動して動いてもよい。アプリケーション開発者は、アプリケーションGUIから装置プラットフォーム独立型の中間表現を作るためのツールとして、拡張性のあるGUIライブラリモジュール１２を使うことができる。図１に示すように、SGUIシステム１０の稼動中、アプリケーションGUIは、拡張性のあるGUIライブラリモジュール１２を使う装置プラットフォーム独立型の中間表現をインスタンス化してもよい。カスタマイズモジュール１４は、拡張性のあるアプリケーションが動いているターゲット装置プラットフォームに基づく装置プラットフォーム依存型の中間表現に対し、中間表現をカスタマイズしてもよい。レンダーマネージャモジュール１６は、ターゲット装置プラットフォームのユーザインターフェイス用にカスタマイズされたプレゼンテーションを取り出すため、装置プラットフォーム依存型の中間表現を使用してもよい。そしてプレゼンテーションは、レンダーマネージャモジュール１６により、ターゲット装置プラットフォームの表示画面上に表示されてもよい。」
　
　
＜引用文献６＞
特開２００４−５５６８号公報（平成１６年１月８日出願公開）
　
　＜引用文献記載事項６−１＞
「【特許請求の範囲】
【請求項１】
レガシー・アプリケーションを高速に体裁更新する方法であって、レガシー・アプリケーションの表示画面内の表示要素をターゲット視覚表示内のＧＵＩ要素に変換するように構成されたグラフィカル・ユーザ・インターフェース（ＧＵＩ）変換テンプレートに合致させるステップと、
前記合致するＧＵＩ変換テンプレート中に指定された変換を行うステップ
を含み、
前記変換によって前記レガシー・アプリケーションに対する体裁更新済みＧＵＩが生み出される、
方法。」
　
　＜引用文献記載事項６−２＞
「【０００７】
【発明が解決しようとする課題】
本発明は、
レガシー・アプリケーションのＧＵＩを高速かつ効率的に体裁更新する
　
　＜引用文献記載事項６−３＞
「【００２２】
図１〜４は一括して、本発明によるレガシー・アプリケーション画面のＧＵＩ体裁更新を示す際に有用なものである。具体的には、図１は、例示的なレガシー・アプリケーション表示画面の画像であり、図２、３、４は、図１のレガシー・アプリケーション表示画面に対する例示的な体裁更新済みＧＵＩの画像である。例えば、
図２は図１のレガシー・アプリケーションの表示画面をプレーンなＨＴＭＬで表現したものを示し
　
　
＜引用文献７＞
米国特許第６３４２９０７号明細書（２００２年１月２９日発行）
　
　＜引用文献記載事項７−１＞
「A specification language allows a user to define platform-independent user interface panels without detailed knowledge of complex computer programming languages. 
The specification language is referred to herein as a Panel Definition Markup Language (PDML), which defines tags that are used in similar fashion to those defined in Hypertext Markup Language (HTML)
（当審訳：記述言語が複雑なコンピュータプログラム言語の詳細な知識なしでプラットホームに依存しないユーザインタフェースパネルをユーザが定義することを可能にする。
その記述言語は、パネル定義マークアップ言語（ＰＤＭＬ）として、ここで参照され、それはハイパーテキスト・マークアップ言語（ＨＴＭＬ）で定義されたそれらに類似の様式で使われるタグを定義し
　
　＜引用文献記載事項７−２＞
「
Panel conversion tool　128　allows for automatically converting a platform-specific user interface panel to an equivalent PDML representation of the panel.
（当審訳：
パネルコンバージョンツール１２８がプラットホームに特定されたユーザインタフェースパネルをそのパネルと同等のＰＤＭＬ表示に自動的に換えることを可能にする。
　
　
＜引用文献８＞
米国特許出願公開第２００２／１９１０１８号明細書（２００２年１２月１９日出願公開）
　
　＜引用文献記載事項８−１＞
「[0059]The Java JVM contains a toolkit, which is a translator. The toolkit can be written in Java for execution by the JVM via the API.
Translator toolkit 20 is portable across multiple OS platforms, and, translates or adapts standard platform-independent java code to native java code.
（当審訳：Jａｖａ　ＪＶＭはトランスレーターであるツールキットを持っている。そのツールキットはＡＰＩを経由したＪＶＭによる実行のためにＪａｖａで書かれ得る。
トランスレータツールキット２０は多数のＯＳプラットホームにわたって移植性があり、そして、標準的なプラットホームに依存しないｊａｖａコードをネイティブのｊａｖａコードに翻訳あるいは改変する。
　
　
（２）参考文献
　本願の出願前である上記優先日前に頒布又は電気通信回線を通じて公衆に利用可能となされた下記参考文献には、それぞれ、下記参考文献記載事項が記載されている。（下線は当審付与。）
　
　
＜参考文献９＞
特開平５−２７９５９号公報（平成５年２月５日出願公開）
　
　＜参考文献記載事項９−１＞
「【特許請求の範囲】
【請求項１】　ディスプレイ画面上に複数のウィンドウを表示し、位置指示装置とキーボードとをもって行う操作者に対する会話を管理するウィンドウ制御機構と、ウィンドウに配置する各種の部品の集合であるツールキットと、該ツールキットを用いて業務処理を行うアプリケーション・プログラムとから構成される対話型システムにおいて、
複数の異なる種類のツールキットで共通的に実現される共通部品と該共通部品の操作方法とを定義する情報を格納する共通操作定義テーブル
ツールキットの個々の部品を、上記共通操作定義テーブルに格納されている共通部品に対応させる部品対応テーブル
ツールキットで定義されている個々の部品の操作方法を、上記部品対応テーブルと共通操作定義テーブルとを参照し、該共通操作定義テーブルで定義されている操作方法に変換する操作変換手段とを有し、
アプリケーション・プログラムは、ツールキットの代わりに上記操作変換手段を呼び出し、アプリケーション・プログラムで個々に指定した操作方法やツールキットで予め設定されている操作方法を、共通操作定義テーブルで定義した操作方法に変換することによって、アプリケーション・プログラムやツールキットによって異なる操作方法を共通操作定義テーブルで定義される操作方法に一元的に変換することを特徴とする操作方法を共通化した対話型システム。」
　
　
＜参考文献１０＞
特開２００１−２１７８５０号公報（平成１３年８月１０日出願公開）
　
　＜参考文献記載事項１０−１＞
「【０１７３】図１１を参照して、まずステップＳ２０１において論理ＵＩ要素と具象ＵＩ要素との対応づけが行なわれる。Ｓ２０１は図８のＵＩ管理部８１０１がＵＩ要素対応表８１１０を参照しながら行なう。ＵＩ要素対応表の一例を図９に示す。
【０１７４】
図９のＵＩ要素対応表において、論理ＵＩ要素に関する情報は、論理ＵＩ要素の種類を表わす名義と、必要に応じて機能属性に関する属性値を記載した属性情報とを含む。具象ＵＩ要素に関する情報は、ＵＩ装置で実現可能な具象ＵＩ要素と、それに必要なパラメータ（属性）とを含む。
　
　
４．引用発明の認定
　
（１）上記引用文献記載事項１−１、１−２等において「
あるツールのフォーマット
独自のフォーマット
中立かつ単一の共通中間フォーマット
中立かつ単一の中間フォーマット
別のツールのフォーマット
別のツールの独自のフォーマット
　したがって、引用文献１には
「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」
が記載されていると言える。
　
（２）上記引用文献記載事項２−２等において「
プログラムＡが
作成したデータａ
それ固有のデータ形式
書き込みにかかるデータａの形式
中間形式
プログラムＢ固有のデータ形式
　したがって、引用文献２にも
「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」
が記載されていると言える。
　
（３）上記引用文献記載事項３−３において「
前記呈示手段のそれぞれで共通に使用可能な形式
画面情報
共通に使用可能な形式
呈示手段で呈示するために必要な情報
　したがって、引用文献３にも
「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」
が記載されていると言える。
　
　
（４）　そして、上記引用文献記載事項１−１の「
従って前記のように４個、５個または６個のツール間で相互に対話を行うとする場合、それぞれ４個、５個または６個のブリッジを開発するだけでよい、すなわち一つのツールあたり一つのブリッジにより前記交換コアにアクセスし、前記ツールのフォーマットを共有中間フォーマットに変換する。
事実、唯一つのプログラムをインタープリットするだけでよいので、この閉じた世界では移植はかなり顕著に簡単になる。
　
（５）よって、移植性の確保や開発負担の削減を図ることを目的とした下記の事項によって特定される発明（以下「引用発明」と記す。）が、本願の出願日前である上記優先日前に頒布または電気通信回線を通じて公衆に利用可能となった相当数の文献に記載され、その結果当業者にとっては周知慣用技術となっていたものと認められる。
　
＜引用発明＞
「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」
　
　
５．対比
　以下、本願発明と引用発明とを比較する。
　
（１）引用発明は「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」であり、本願発明は「第１の特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）を生成するための方法」であるから、引用発明と本願発明とは「データを生成するための方法」である点で共通する。
　
（２）引用発明における「ある特定のフォーマットのデータを共通のフォーマットのデータに変換」するステップは、本願発明における「少なくとも１つの第２の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトから複数のマークアップ言語ベースのプラットフォーム非依存のＧＵＩフォーマットのＧＵＩオブジェクトに変換するステップ」に対応付けられるものであるところ、両者は「ある特定のフォーマットのデータから共通のフォーマットのデータに変換するステップ」である点で共通すると言える。
　
（３）引用発明における「該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する」ステップは、本願発明における「前記プラットフォーム非依存のＧＵＩフォーマットのＧＵＩオブジェクトを前記第１の特定のプラットフォームによって生成するための前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトに変換するステップ」に対応付けられるものであるところ、両者は「該共通のフォーマットのデータを他の特定のフォーマットのデータに変換するステップ」である点で共通すると言える。
　
（４）よって、本願発明は、下記一致点で引用発明と一致し、下記相違点で引用発明と相違する。
　
＜一致点＞
「データを生成するための方法において、
　ある特定のフォーマットのデータから共通のフォーマットのデータに変換するステップと、
　該共通のフォーマットのデータを他の特定のフォーマットのデータに変換するステップと
を含む方法。」
　
＜相違点１＞
　本願発明においては、
生成される「データ」は「第１の特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）」であり、
「ある特定のフォーマットのデータ」は「少なくとも１つの第２の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクト」であり、
「共通のフォーマットのデータ」は「複数のマークアップ言語ベースのプラットフォーム非依存のＧＵＩフォーマットのＧＵＩオブジェクト」であり、
「他の特定のフォーマットのデータ」は「前記第１の特定のプラットフォームによって生成するための前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクト」である。
（これに対し、引用発明はデータの種類を特定するものではない。）
　
＜相違点２＞
　本願発明においては「前記変換するステップは、プラットフォーム非依存マークアップ言語ベースのＧＵＩオブジェクトに関する見出しおよび関連値と、前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトに関する見出しおよび関連値とが関連付けて登録された変換マップを使用して、前記プラットフォーム非依存のＧＵＩフォーマットのＧＵＩオブジェクトを、前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトに変換するステップを含む」ものである。
（これに対し、引用発明は変換の具体的手順を特定するものではない。）
　
　
６．判断
　以下、上記相違点について検討する。
　
（１）相違点１について
　ＧＵＩの移植や開発のために、異なるプラットフォーム間でのＧＵＩの変換をすることも、従来から適宜に開発・実施されていた周知慣用の技術思想であり、かかる分野においてもその移植性の確保や開発負担の削減は当然に追求される課題にほかならない（必要があれば引用文献記載事項４−１、４−２、５−１、５−２、６−１、６−２、７−２、８−１等参照）。
　してみると、引用発明におけるデータを特定のＧＵＩフォーマットのＧＵＩオブジェクトとすることで、異なるプラットフォーム間でのＧＵＩの変換を行おうとすることは、当業者であれば容易に着想し得たことである。
　そして、この場合には、生成される「データ」が「第１の特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）」となり、「ある特定のフォーマットのデータ」が「少なくとも１つの第２の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクト」となり、「共通のフォーマットのデータ」が「複数のマークアップ言語ベースのプラットフォーム非依存のＧＵＩフォーマットのＧＵＩオブジェクト」となり、「他の特定のフォーマットのデータ」が「前記第１の特定のプラットフォームによって生成するための前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクト」となることは、必然的に満たされる事項にほかならず、上記相違点１に係る事項を採用することは、当業者であれば、容易に想到し得たことにほかならないものと言える。
　
（２）相違点２について
　情報の変換に際し変換前後の対応関係を示す情報を用いることは証拠を挙げるまでもない常套手段にすぎないものである（必要があれば引用文献記載事項３−４、参考文献記載事項９−１、１０−１等参照）。
　そして、ＧＵＩオブジェクトを見出しと関連値で表記されるマークアップ言語ベースで記述することも当業者の技術常識にほかならないものである（必要があれば、引用文献記載事項３−１、６−３、７−１等参照）。
　してみると、上記（１）で言及した引用発明における「データ」を特定のＧＵＩフォーマットのＧＵＩオブジェクトとした場合の「変換」を、「プラットフォーム非依存マークアップ言語ベースのＧＵＩオブジェクトに関する見出しおよび関連値と、前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトに関する見出しおよび関連値とが関連付けて登録された変換マップを使用して、前記プラットフォーム非依存のＧＵＩフォーマットのＧＵＩオブジェクトを、前記第１の特定のプラットフォーム固有のＧＵＩフォーマットのＧＵＩオブジェクトに変換するステップを含む」ステップで実現すること、すなわち上記相違点２に係る事項を採用することも、上記相違点１に係る事項の実現に際して、当業者が適宜に選択し得た設計的事項にすぎないものである。
　
（３）したがって、本願発明の構成は引用発明に基づいて、当業者が容易に想到し得たものである。
　そして、当該構成の採用によって奏される作用効果も、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　よって、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものである。
　
（４）なお、引用文献４〜８等からは、ＧＵＩの移植や開発のために、「異なるプラットフォーム間でのＧＵＩの変換をする方法」（以下「引用発明２」と記す）も、当業者にとっては周知慣用技術となっていたものと認められるところ、当該引用発明２に上記４．（５）で引用発明として認定した周知慣用技術、及び上記（２）で言及した常套手段、技術常識を適用することによっても、本願発明は当業者が容易に発明し得たものであるとも言える。
　
　
７．むすび
　以上のとおり、本願請求項１に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものであり、他の請求項についての検討をするまでもなく、本願を拒絶すべきものとした原審の拒絶査定はその結論において誤りはない。
　したがって、原査定を取り消し、本願を特許をすべきものとすることはできない。
　
　よって、上記結論のとおり審決する。