拒絶査定不服の審決｜不服2012-8746 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない(前置又は当審拒絶理由) G06F
管理番号	1301182
審判番号	不服2012-8746
総通号数	187
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2015-07-31
種別	拒絶査定不服の審決
審判請求日	2012-05-14
確定日	2015-05-20
事件の表示	特願2005-327699「特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース(GUI)モデルを生成するための方法、システム、およびプログラム」拒絶査定不服審判事件〔平成18年 6月22日出願公開、特開2006-164258〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	1.手続の経緯 (1)本件審判請求に係る出願(以下「本願」と記す。)は、 2004年12月6日(以下「優先日」と記す。)のアメリカ合衆国における出願を基礎とするパリ条約に基づく優先権主張を伴って、平成17年11月11日付けで出願されたものであって、平成20年8月13日付けで審査請求がなされ、同日付けで手続補正書が提出され、平成23年8月15日付けで拒絶理由通知(平成23年8月23日発送)がなされ、平成23年12月21日付けで意見書が提出されるとともに、同日付けで手続補正書が提出され、平成24年1月11日付けで拒絶査定(平成24年1月17日謄本発送、送達)がなされたものである。 (2)本件審判請求は「原査定を取り消す、本願は特許をすべきものとする、との審決を求める。」との趣旨で、平成24年5月14日付けでなされたものであり、同日付けで手続補正書が提出され、特許法第162条の規定により前置審査に付され、平成24年8月2日付けで拒絶理由通知(平成24年8月7日発送)がなされ、平成24年11月2日付けで意見書が提出されるとともに、同日付けで手続補正書が提出され、平成25年2月15日付けで最後の拒絶理由通知(平成25年2月19日発送)がなされ、平成25年5月15日付けで意見書が提出されるとともに、同日付けで手続補正書が提出され、平成25年5月30日付けで特許法第164条第3項に定める報告(前置報告)がなされ、平成25年7月22日付けで当該報告に対する意見を求める旨の審尋(平成25年7月23日発送)がなされ、平成25年10月21日付けで回答書が提出され、平成26年3月27日付けで審尋(平成26年4月1日発送)がなされ、平成26年7月1日付けで回答書が提出され、平成26年8月18日付けで上記平成25年5月15日付けの手続補正書による補正を却下する旨の補正の却下の決定(平成26年9月2日謄本発送・送達)がなされるとともに、同日付けで拒絶理由通知(平成26年8月19日発送。以下「当審拒絶理由通知」と記す。)がなされ、平成26年11月19日付けで意見書が提出されるとともに、同日付けで手続補正書が提出されたものである。 2.本願発明の認定本願の請求項1に係る発明(以下「本願発明」と記す。)は、上記平成26年11月19日付けの手続補正書により補正された特許請求の範囲、明細書及び図面の記載からみて、本願の特許請求の範囲の請求項1に記載されたとおりの次の事項により特定されるものと認める。＜本願発明＞「第1の特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース(GUI)を生成するための方法において、少なくとも1つの第2の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトから複数のマークアップ言語ベースのプラットフォーム非依存のGUIフォーマットのGUIオブジェクトに変換するステップと、前記プラットフォーム非依存のGUIフォーマットのGUIオブジェクトを前記第1の特定のプラットフォームによって生成するための前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトに変換するステップとを含み、前記変換するステップは、プラットフォーム非依存マークアップ言語ベースのGUIオブジェクトに関する見出しおよび関連値と、前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトに関する見出しおよび関連値とが関連付けて登録された変換マップを使用して、前記プラットフォーム非依存のGUIフォーマットのGUIオブジェクトを、前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトに変換するステップを含む、方法。」 3.先行技術 (1)引用文献本願の出願前である上記優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり、原審の拒絶査定の理由である上記当審拒絶理由通知において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。(下線は当審付与。) ＜引用文献1＞特開平10-40087号公報(平成10年2月13日出願公開) ＜引用文献記載事項1-1＞「【0004】この欠点を少なくとも部分的に解消するため、やはり固有ではあるが、交換のコアとなる中立的なピボット情報モデルをつくることにより、あるツールのフォーマットを中立かつ単一の共通中間フォーマットを経由して別のツールのフォーマットに変換することができるようにしたブリッジを開発するということからなる解決方法が考案された。全てのブリッジがこの交換コアを通過するこのピボット情報モデルを使用する中立的表現という考え方により、ブリッジを著しく減らすことが可能であり、しかもやりとりを行うべきツール数が多ければ多いほどそのことが言える。従って前記のように4個、5個または6個のツール間で相互に対話を行うとする場合、それぞれ4個、5個または6個のブリッジを開発するだけでよい、すなわち一つのツールあたり一つのブリッジにより前記交換コアにアクセスし、前記ツールのフォーマットを共有中間フォーマットに変換する。この種の解決方法の場合、すぐれた移植性を確保するため、この機能を果たすための固有言語が開発され書き込まれインタープリットされる、コンパクトで管理が簡単で機能的な調節がなされたプロプリエタリアプローチが採用された。事実、唯一つのプログラムをインタープリットするだけでよいので、この閉じた世界では移植はかなり顕著に簡単になる。この解決方法は有利ではあるが、欠点も有する。第一の欠点は、インタープリットされる言語が高速ではなく、インタープリターは前記言語を分析してから記載した動作を実行するという事実に本質的に関わる。このようなプロプリエタリ言語を使用する際の第二の大きな欠点は、その言語では再使用可能要素の概念を利用することができないことである。実際、新しいブリッジを開発しようとする場合、この固有言語で全コードを再度書き込む必要がある。さらにこのような言語は通常、開発環境が非常に悪い(再利用可能機能のライブラリがない、デバッガツールがない等)。」＜引用文献記載事項1-2＞「【0020】【発明の実施の形態】図1は、本発明による、ソフトウェア工学ツールTa、Tb、Tc、Td、...、の集合体の中での有利なインタオペラビリティーを示す。前記ツールは、例えばアプリケーションの開発に関する情報をデータモデルの形態で交換する。ツールTa、Tb、Tc、Tdは、それぞれ独自の環境下で独自の辞書とともに使用される異種開発ツールである。これら四つのツール間のデータモデルの変換は、ツールTa、Tb、Tc、Tdのうちの一つの独自のフォーマットを中立かつ単一の中間フォーマット、中立情報モデルNIM、を経由してツールのうちの別のツールの独自のフォーマットに変換することができるBa、Bb、Bc、Bdなどのブリッジを使用して行われる。より正確には、交換される情報は、結果的にピボットモデルとなるモデルNIMとの間でデータを送受信する前記ツールのエキスポートファイルを経由する。中立情報モデルNIMをインスタンスするデータはリファレンシャルと呼ばれるオブジェクトデータベース内に保存される。」＜引用文献2＞特開平5-150941号公報(平成5年6月18日出願公開) ＜引用文献記載事項2-1＞「【0004】【発明が解決しようとする課題】従来は上述したようにしてデータ形式の異なるプログラム間でデータの共有を可能にしているが、以下のような問題点がある。【0005】他のプログラムに利用させるデータの形式をそのプログラム固有のデータ形式に変換するために利用者自身がコンバータを起動しなければならない。【0006】更新等が行われた変換後のデータを再度元のプログラムで利用する場合、データ形式を逆変換するために利用者自身が再度コンバータを起動しなければならない。この再変換を忘れると、更新等が行われる前のデータが利用されることになり、矛盾が生じる。【0007】複数のプログラム間で共有されるデータがデータ53,54の如く各々独立して作成されるため、管理が面倒になる。【0008】本発明はこのような従来の問題点を解決したもので、その目的は、扱うデータ形式が異なる複数のプログラム間のデータの共有を利用者の介在無しに可能にすると共にその管理も容易にすることにある。」＜引用文献記載事項2-2＞「【0010】【作用】本発明のデータ共有方式においては、或るプログラムAがそれ固有のデータ形式で作成したデータaの書き込みを要求すると、データ共有管理部が、その書き込みデータaの形式を必要に応じそのプログラム固有のデータ形式から所定のデータ形式に変換して記憶装置に格納する。【0011】具体的には例えば以下のような動作を行う。【0012】・前記所定のデータ形式として処理装置で実行される複数のプログラムのいずれのデータ形式とも相違するデータ形式(以下中間形式と称す)を採用する場合データ共有管理部は、書き込みにかかるデータaの形式を中間形式に変換して記憶装置に格納する。【0013】・前記所定のデータ形式として前記複数のプログラムのうちの予め定められた特定のプログラム(以下特定プログラムと称す)のデータ形式(以下特定形式と称す)を採用する場合データ共有管理部は、書き込みを要求したプログラムAが特定プログラムであればその書き込みデータaをそのまま記憶装置に格納し、特定プログラム以外のプログラムであれば、その書き込みデータaの形式を特定形式に変換して記憶装置に格納する。【0014】・前記所定のデータ形式として前記複数のプログラムの各々のデータ形式を採用する場合データ共有管理部は、書き込みデータaの形式を書き込み要求したプログラムA以外のプログラムのデータ形式に変換し、元の書き込みデータaおよびデータ形式変換後の書き込みデータを各々のプログラム対応に記憶装置に格納する。【0015】その後、データ形式の異なるプログラムBが、プログラムAが書き込んだ上記のデータaを利用したいことからその読み出しを要求すると、データ共有管理部は、記憶装置に格納されている該当データの形式を必要に応じそのプログラム固有のデータ形式に変換して通知する。【0016】具体的には例えば以下のような動作を行う。【0017】・前記所定のデータ形式として中間形式を採用する場合データ共有管理部は、記憶装置に格納されているデータaを読み出し、その形式を中間形式からプログラムB固有のデータ形式に変換して通知する。【0018】・前記所定のデータ形式として特定形式を採用する場合データ共有管理部は、読み出しを要求したプログラムBが特定プログラムであれば記憶装置に格納されているデータaを読み出してそのままの形式で通知し、特定プログラム以外のプログラムであれば、記憶装置に格納されているデータaを読み出し、その形式を特定形式からプログラムB固有のデータ形式に変換して通知する。【0019】・前記所定のデータ形式として前記複数のプログラムの各々のデータ形式を採用する場合データ共有管理部は、プログラムBに対応して記憶装置に格納されているプログラムB固有のデータ形式に変換されたデータaを読み出して通知する。」＜引用文献3＞特開2004-226743号公報(平成16年8月12日出願公開) ＜引用文献記載事項3-1＞「【0014】【発明が解決しようとする課題】しかしながら、視覚障害者においては、全盲をはじめ、弱視者では視力の程度や見え方の特性が多岐にわたることや、障害の進み方などによる個人差などから、個々のユーザが最適な環境でGUI画面の情報を取得するには、個々に呈示形式が異なる複数の出力装置と多様な呈示の方法が必要である。これには、音声と点字、拡大文字と点字に加え、2次元触覚呈示との併用など、同時にマルチ形態的な感覚で情報を呈示することが情報の理解や取得に有利となることが考えられる。【0015】一方で、多様化する情報社会では、GUI画面をHTMLやXML(Eｘｔenｓible Maｒkｕｐ Langｕage)など、標準化されたマークアップ言語で記述し、呈示形式の異なる複数の出力装置(呈示手段)で共通に情報を呈示することができるようにする必要性が高まっている。」＜引用文献記載事項3-2＞「【0016】このような背景の中で、前記した従来の技術のように、GUIを視覚障害者に伝えるために音声や点字、拡大表示など、それぞれの機能に対応した出力技術があるが、これらはアプリケーションに応じて、独自のプログラムなどが組み込まれている。また、全盲者に対しては音声や点字の他に、2次元オブジェクトの触覚呈示や振動呈示、弱視者に対しては拡大、反転表示などの複数の出力呈示を併用したり、あるいは、弱視者の見やすい画面表示や触覚でわかりやすい画面に呈示したり、個々のユーザに最適となるような、多様な呈示方法に対応する有効な手段はなかった。【0017】また、図5に示す出力呈示装置では、それぞれのアプリケーションごとに個々の表示変換プログラムを開発することが必要となるため、開発の労力やコストが高くなるなどの問題があった。【0018】本発明は前記の問題点に鑑み創案されたものであり、GUI環境で表示される画面情報を、リソースおよび呈示形式がそれぞれ異なる複数の呈示手段に依存しないデータとして提供し、ユーザが自分に最適なGUI環境で情報を得ることが可能なマルチ形態出力呈示装置、および、その出力呈示プログラムを提供することにある。」＜引用文献記載事項3-3＞「【0019】【課題を解決するための手段】本発明は前記の目的を達成するために、本発明にかかるマルチ形態出力呈示装置では、GUI環境で表示される画面情報を、呈示形式がそれぞれ異なる複数の呈示手段で使用可能な共通の情報に変換して出力するマルチ形態出力呈示装置であって、前記画面情報が有する属性データおよび属性内容データを検出して、前記属性データおよび属性内容データを、データベースにあらかじめ前記属性データおよび前記属性内容データと対応づけて記憶され、前記呈示手段のそれぞれで共通に使用可能な形式に変換して共通画面情報として作成する共通画面情報作成手段と、前記共通画面情報作成手段により作成された前記共通画面情報のなかから、前記呈示手段の呈示に必要な情報を抽出し、かつ前記呈示手段で呈示するために必要な情報に変換して出力するデータ抽出表示出力変換手段と、を備えた構成とした(請求項1)。【0020】かかる構成によれば、マルチ形態出力呈示装置は、GUI環境で表示される画面情報が有する属性データおよび属性内容データについて、共通画面情報作成手段が検出し、かつ、あらかじめデータベースに記憶されており、属性データおよび属性内容データに対応づけられている形式に変換して共通画面情報として作成される。この共通画面情報としては、例えば、属性データおよび属性内容データを、各呈示手段で共通となる表形式に置き換えており、データ抽出表示出力変換手段が、その共通画面情報から各呈示手段に対応する情報として、その表形式から抽出すると共に変換してそれぞれの呈示手段のいずれかに出力している。」＜引用文献記載事項3-4＞「【0067】次に、このように構成されたマルチ形態出力呈示システムの動作を説明する。はじめに、図2に示すように、データ再編成/タグ情報変換手段11には、リソース2から、情報リソースの種類(バイナリ、BML、HTML、CSV)によって各種形式のデータのいずれかが送られてくる。それぞれの選択オブジェクト(図4で示す▲1▼、▲2▼…参照)の有する画面呈示情報やテキスト情報、あるいはリンク情報などの属性情報を、データ再編成/タグ情報変換手段11により検出し、あらかじめデータベース14(図2参照)に記憶されているタグ情報変換則を参照して再編成すると共に、そのデータをタグ情報Aa(図3(c)参照)に変換する。」＜引用文献4＞特開2002-149418号公報(平成14年5月24日出願公開) ＜引用文献記載事項4-1＞「【0007】【発明が解決しようとしている課題】近年のアプリケーションは、ユーザーが利用しやすいように、GUI(グラフィカルユーザーインタフェイス)を持つ。GUIは、GUI定義により、所望のメニューを表示する。GUI定義の内容は、使用しているGUIツールにより、その内容が異なるため、移植元と移植先で使用するGUIツールが異なる場合には、メニューを作成する時に、必要となる情報に過不足が生じ、移植先で正しいメニューの作成が困難となるという問題がある。【0008】例えば、UNIX上で、X11/Mｏｔif(第1のプラットフォーム)120を使用して作成したUNIXアプリケーションプログラム100を、WindｏｗｓNT(第2のプラットフォーム)に移植する場合には、X11/MｏｔifのGUI定義では、メニューの外枠の位置とサイズが定義されているだけであり、メニューを構成する各部品1つ1つの位置とサイズは定義されていない。しかし、WindｏｗｓNTでは、メニューの中に配置された各部品を作成する場合は、部品の位置と大きさが必要となる。【0009】部品の位置とサイズ以外に、GUIを定義する情報としては、色、フォント名、描画方向、配列、陰影、ピクスマップ名、部品の親子関係(階層関係)、部品の配置方法とサイズ変更時の振る舞い、部品の状態(On/Off),スケール、テキスト部品等の部品自身が持つ値、文字列等がある。【0010】従来技術では、移植先でGUI定義情報が不足する場合には、人手で入力する必要があり、その作業には、多大な工数を必要とするという問題があった。【0011】従って、本発明の目的は、移植元で作成されたアプリケーションプログラムのGUI定義を移植先で利用して、同一メニューを生成するためのアプリケーションの移植方法、そのシステム、記憶媒体及びプログラムを提供するにある。【0012】又、本発明の他の目的は、少ない工数でアプリケーションプログラムを移植するためのアプリケーションの移植方法、そのシステム、記憶媒体及びプログラムを提供するにある。」＜引用文献記載事項4-2＞「【0031】図5は、本発明の一実施の形態のGUI変換ツールの構成図、図6は、図5の変換プログラムの処理フロー図、図7は、その変換動作説明図、図8は、変換メニュー例の説明図、図9は、X11/MｏｔifでのGUI定義の説明図、図10は、これを変換したWindｏｗｓNTでのGUI定義の説明図である。【0032】図5に示すように、UNIX環境における入出力関係は、X11/MｏｔifのGUI定義35を用いて、UNIXアプリケーション10が表示装置1に、メニュー、図形を表示する。WindｏｗｓNT環境における入出力関係は、GUI定義34を用いて、WindｏｗｓNTアプリケーション10が表示装置2に、メニュー、図形を表示する。【0033】GUI定義変換プログラム4は、UNIX環境において、X11/MｏｔifのGUI定義35を用いて、X11/MｏｔifのGUI定義に不足している部品(メニューのリスト等)の位置、サイズを追加し、GUI定義ファイル34を作成する。【0034】具体的には、GUI定義35を読み込んで作成したメニューは、親ウィンドウを頂点にして、子ウィンドウが階層的に順次配置されているため、一番上の親ウィンドウから順次子ウィンドウを辿ることができる。そこで、全てのウィンドウを辿っていき、それぞれのウィンドウの表示状態における位置とサイズを取り出し、GUI定義の記述形式に従って出力することにより、位置とサイズが入ったGUI定義ファイル34を生成する。・・・中略・・・【0046】このようにして、X11/MｏｔifのGUI定義35を用いて、X11/MｏｔifのGUI定義に不足している部品(メニューのリスト等)の位置、サイズを追加し、GUI定義ファイル34を作成することができる。【0047】又、GUI定義35を読み込んで作成したメニューが、親ウィンドウを頂点にして、子ウィンドウが階層的に順次配置されているため、一番上の親ウィンドウから順次子ウィンドウを辿り、それぞれのウィンドウの表示状態における位置とサイズを取り出し、GUI定義の記述形式に従って出力することにより、位置とサイズが入ったGUI定義ファイル34を自動生成できる。【0048】上述した実施の形態では、X11/Mｏｔifを使用したUNIXアプリケーションから、WIN32APIを使用したWindｏｗｓアプリケーションへの移植を例に説明したが、GUI定義情報を表示した状態から取得できる他のGUIツール及び各種OSの組み合わせの相互間での移植に適用できる。例えば、GUIツールとして、X11/Mｏｔif、WIN32APIの他に、X/Vieｗ(OｐenWindｏｗ),SｕnVieｗ,Jaｖa等にも適用でき、移植の対象となるOSとして、UNIX(Sｏlaｒiｓ,FｒeeBSD,Linｕｘ),Windｏｗｓ(NT/95/98/2000),MacOS,OS/2等にも適用できる。」＜引用文献5＞特開2003-330712号公報(平成15年11月21日出願公開) ＜引用文献記載事項5-1＞「【0004】【発明が解決しようとする課題】携帯装置のアプリケーションの開発が困難な1つの理由は、携帯装置の異質性である。多種多様なディスプレイのサイズ、解像度、コマンドの入力方法、そしてGUIライブラリがあるため、アプリケーションの開発者は、各装置プラットフォームのグラフィカルユーザインターフェイス(GUI)用に、アプリケーションを再設計及び再実装する必要がある。たくさんの異なる携帯装置が利用され、または市場に参入しているので、再設計と再実装に、たくさんの労働力と生産コストを要する努力が現在もなされている。【0005】1つの解決策は、モデルベース技術による開発である。1つの例が、ユーザインターフェイスモデリングである。一般的に、ユーザインターフェイスモデリングは、プラットフォームモデル、プレゼンテーションモデル、そしてタスクモデルを含む。プラットフォームモデルでは、サポートされる装置用のユーザインターフェイスを形成する操作機能が示される。プレゼンテーションモデルでは、サポートされる装置に関連したユーザインターフェイスの外観に関する階層、及び様式の選択と配置が示される。タスクモデルでは、サポートされる装置のユーザが実行するタスクが示される。この技術を使用することにより、特定の装置用のインターフェイスの生成のため、異なるモデル間におけるマッピングが開発されると思われる。【0006】モデルベース型アプローチの実装は、モデルを実装するためのハイレベル言語の開発を含んでいる。さらに開発者は、装置をサポートするためにモデルの重要な部分を設定し、かつ特定する。ハイレベル言語は非常に複雑なので、モデルベース型アプローチを実行する前に、開発者は、実行メカニズムの知識とハイレベル言語を共に学ぶ必要がある。さらにモデルベース型アプローチは、開発者が作った異なるモデルに基づくコードを作成する。装置のユーザインターフェイス要求においては小さな差異でも、2つの似たタイプの装置用に生成されたコードにおいては大きな差異になることもある。従って開発者に求められるプログラミング技能のレベルは、とても重要になってくる。」＜引用文献記載事項5-2＞「【0032】図1は、拡張性のあるグラフィカルユーザインターフェイス(SGUI)システム10のある実施形態のブロック図である。SGUIシステム10は、拡張性のあるGUIライブラリモジュール12、カスタマイズモジュール14、そしてレンダーマネージャモジュール16を持っている。図に描かれた実施形態は、本発明の理解を助けるためのものであり、これらの装置は個々に独立したものではなく、同図より少ないまたは多い装置が、SGUIシステム10を説明している様々な実施形態で利用されてもよい。【0033】拡張性のあるGUIライブラリモジュール12は、拡張性のあるアプリケーションの開発中において、アプリケーションの開発者が使用するツールであってもよい。さらに、拡張性のあるGUIライブラリモジュール12は、SGUIシステム10による中間表現と共に使用するため、GUIコンポーネントのライブラリを提供してもよい。ある実施形態において、装置プラットフォーム独立型APIは、拡張性のあるアプリケーションの開発中において使用されてもよい。また中間表現を作るため、装置プラットフォーム独立型APIは、装置プラットフォーム独立型のアプリケーションGUI内に、アプリケーション開発者により実装されてもよい。したがって、装置プラットフォーム独立型のアプリケーションGUIを使用して中間表現のインスタンス化には、拡張性のあるGUIライブラリモジュール12内において、装置プラットフォーム独立型のAPIを実行することが含まれる。中間表現のインスタンス化は、中間表現は装置プラットフォーム独立型のプレゼンテーションモデルということを表している図1において、「装置独立型中間表現」となっている。・・・中略・・・【0038】変換マネージャモジュール20は、中間表現を装置プラットフォーム依存型のプレゼンテーションに変換するように動く。装置プラットフォーム依存型のプレゼンテーションは、ターゲット装置プラットフォーム内で、特定のユーザインターフェイスに適合してもよい。中間表現の変換は、タスクマネージャモジュール18が不要なタスクを取り除くことにより始まる。中間表現の変換には、ターゲット装置プラットフォームの機能ベースの中間表現、中間表現の論理構造、及び/またはアプリケーションGUIが特定したプロパティを動的に変更することが含まれる。以下における変換マネージャモジュール20による変換において、中間表現は装置プラットフォーム依存型の中間表現であり、この装置プラットフォーム依存型の中間表現は、プラットフォーム特定のプレゼンテーション方式における特定のある異種装置プラットフォーム(ターゲット装置プラットフォーム)に対するカスタマイズを示すために「装置依存型中間表現」として図1に表されている。・・・中略・・・【0041】SGUIシステム10の好ましい実施形態において、SGUIシステム10は、ターゲット装置プラットフォームに対しアプリケーションGUIの継ぎ目のないスケーリングを提供するため、拡張性のあるアプリケーションと連動して動いてもよい。アプリケーション開発者は、アプリケーションGUIから装置プラットフォーム独立型の中間表現を作るためのツールとして、拡張性のあるGUIライブラリモジュール12を使うことができる。図1に示すように、SGUIシステム10の稼動中、アプリケーションGUIは、拡張性のあるGUIライブラリモジュール12を使う装置プラットフォーム独立型の中間表現をインスタンス化してもよい。カスタマイズモジュール14は、拡張性のあるアプリケーションが動いているターゲット装置プラットフォームに基づく装置プラットフォーム依存型の中間表現に対し、中間表現をカスタマイズしてもよい。レンダーマネージャモジュール16は、ターゲット装置プラットフォームのユーザインターフェイス用にカスタマイズされたプレゼンテーションを取り出すため、装置プラットフォーム依存型の中間表現を使用してもよい。そしてプレゼンテーションは、レンダーマネージャモジュール16により、ターゲット装置プラットフォームの表示画面上に表示されてもよい。」＜引用文献6＞特開2004-5568号公報(平成16年1月8日出願公開) ＜引用文献記載事項6-1＞「【特許請求の範囲】【請求項1】レガシー・アプリケーションを高速に体裁更新する方法であって、レガシー・アプリケーションの表示画面内の表示要素をターゲット視覚表示内のGUI要素に変換するように構成されたグラフィカル・ユーザ・インターフェース(GUI)変換テンプレートに合致させるステップと、前記合致するGUI変換テンプレート中に指定された変換を行うステップとを含み、前記変換によって前記レガシー・アプリケーションに対する体裁更新済みGUIが生み出される、方法。」＜引用文献記載事項6-2＞「【0007】【発明が解決しようとする課題】本発明は、レガシー・アプリケーションのGUIを高速かつ効率的に体裁更新するためのシステムおよび方法である。」＜引用文献記載事項6-3＞「【0022】図1?4は一括して、本発明によるレガシー・アプリケーション画面のGUI体裁更新を示す際に有用なものである。具体的には、図1は、例示的なレガシー・アプリケーション表示画面の画像であり、図2、3、4は、図1のレガシー・アプリケーション表示画面に対する例示的な体裁更新済みGUIの画像である。例えば、図2は図1のレガシー・アプリケーションの表示画面をプレーンなHTMLで表現したものを示し、図3は図1のレガシー・アプリケーションの表示画面をハイパーリンクおよびボタン・パッドで表現したものを示し、図4は図1のレガシー・アプリケーションの表示画面をドロップダウン・リストおよびボタン・パッドで表現したものを示す。」＜引用文献7＞米国特許第6342907号明細書(2002年1月29日発行) ＜引用文献記載事項7-1＞「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), that allow a user to specify the exact location of components displayed in the panel.」(ABSTRACT 第3?8行) (当審訳:記述言語が複雑なコンピュータプログラム言語の詳細な知識なしでプラットホームに依存しないユーザインタフェースパネルをユーザが定義することを可能にする。その記述言語は、パネル定義マークアップ言語(PDML)として、ここで参照され、それはハイパーテキスト・マークアップ言語(HTML)で定義されたそれらに類似の様式で使われるタグを定義し、ユーザがパネルに表示されたコンポーネントの正確な位置を指定することを可能にする。) ＜引用文献記載事項7-2＞「Panel conversion tool 128 allows for automatically converting a platform-specific user interface panel to an equivalent PDML representation of the panel.」(第7欄第38?40行) (当審訳:パネルコンバージョンツール128がプラットホームに特定されたユーザインタフェースパネルをそのパネルと同等のPDML表示に自動的に換えることを可能にする。) ＜引用文献8＞米国特許出願公開第2002/191018号明細書(2002年12月19日出願公開) ＜引用文献記載事項8-1＞「[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.The toolkit defines the platform specific implementation objects that comprise the GUI for use by a software application.」 (当審訳:Jaｖa JVMはトランスレーターであるツールキットを持っている。そのツールキットはAPIを経由したJVMによる実行のためにJaｖaで書かれ得る。トランスレータツールキット20は多数のOSプラットホームにわたって移植性があり、そして、標準的なプラットホームに依存しないjaｖaコードをネイティブのjaｖaコードに翻訳あるいは改変する。ツールキットはソフトウェアアプリケーションによる使用のためのGUIを構成するプラットホームスペシフィックインプリメンテイションオブジェクトを定義する。) (2)参考文献本願の出願前である上記優先日前に頒布又は電気通信回線を通じて公衆に利用可能となされた下記参考文献には、それぞれ、下記参考文献記載事項が記載されている。(下線は当審付与。) ＜参考文献9＞特開平5-27959号公報(平成5年2月5日出願公開) ＜参考文献記載事項9-1＞「【特許請求の範囲】【請求項1】ディスプレイ画面上に複数のウィンドウを表示し、位置指示装置とキーボードとをもって行う操作者に対する会話を管理するウィンドウ制御機構と、ウィンドウに配置する各種の部品の集合であるツールキットと、該ツールキットを用いて業務処理を行うアプリケーション・プログラムとから構成される対話型システムにおいて、複数の異なる種類のツールキットで共通的に実現される共通部品と該共通部品の操作方法とを定義する情報を格納する共通操作定義テーブルと、ツールキットの個々の部品を、上記共通操作定義テーブルに格納されている共通部品に対応させる部品対応テーブルと、ツールキットで定義されている個々の部品の操作方法を、上記部品対応テーブルと共通操作定義テーブルとを参照し、該共通操作定義テーブルで定義されている操作方法に変換する操作変換手段とを有し、アプリケーション・プログラムは、ツールキットの代わりに上記操作変換手段を呼び出し、アプリケーション・プログラムで個々に指定した操作方法やツールキットで予め設定されている操作方法を、共通操作定義テーブルで定義した操作方法に変換することによって、アプリケーション・プログラムやツールキットによって異なる操作方法を共通操作定義テーブルで定義される操作方法に一元的に変換することを特徴とする操作方法を共通化した対話型システム。」＜参考文献10＞特開2001-217850号公報(平成13年8月10日出願公開) ＜参考文献記載事項10-1＞「【0173】図11を参照して、まずステップS201において論理UI要素と具象UI要素との対応づけが行なわれる。S201は図8のUI管理部8101がUI要素対応表8110を参照しながら行なう。UI要素対応表の一例を図9に示す。【0174】図9のUI要素対応表において、論理UI要素に関する情報は、論理UI要素の種類を表わす名義と、必要に応じて機能属性に関する属性値を記載した属性情報とを含む。具象UI要素に関する情報は、UI装置で実現可能な具象UI要素と、それに必要なパラメータ(属性)とを含む。」 4.引用発明の認定 (1)上記引用文献記載事項1-1、1-2等において「あるツールのフォーマット」「独自のフォーマット」と表現されるフォーマットは「ある特定のフォーマット」とも言えるものであり、また、同記載事項における「中立かつ単一の共通中間フォーマット」「中立かつ単一の中間フォーマット」と表現されるフォーマットは「共通のフォーマット」とも言えるものであり、さらに、同記載事項における「別のツールのフォーマット」「別のツールの独自のフォーマット」と表現されるフォーマットは「他の特定のフォーマット」とも言えるものである。したがって、引用文献1には「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」が記載されていると言える。 (2)上記引用文献記載事項2-2等において「プログラムAが」「作成したデータa」の「それ固有のデータ形式」、「書き込みにかかるデータaの形式」等と表現される形式は「ある特定のフォーマット」とも言えるものであり、また、同記載事項における「中間形式」と表現される形式は「共通のフォーマット」とも言えるものであり、さらに、同記載事項における「プログラムB固有のデータ形式」と表現される形式は「他の特定のフォーマット」とも言えるものである。したがって、引用文献2にも「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」が記載されていると言える。 (3)上記引用文献記載事項3-3において「前記呈示手段のそれぞれで共通に使用可能な形式」と表現される形式は「共通のフォーマット」とも言えるものであり、同記載事項における当該形式に変換される前の「画面情報」の形式は「ある特定のフォーマット」とも言えるものであり、また、さらに、同記載事項における共通に使用可能な形式から変換される「呈示手段で呈示するために必要な情報」の形式は「他の特定のフォーマット」とも言えるものである。したがって、引用文献3にも「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」が記載されていると言える。 (4) そして、上記引用文献記載事項1-1の「従って前記のように4個、5個または6個のツール間で相互に対話を行うとする場合、それぞれ4個、5個または6個のブリッジを開発するだけでよい、すなわち一つのツールあたり一つのブリッジにより前記交換コアにアクセスし、前記ツールのフォーマットを共有中間フォーマットに変換する。・・・中略・・・事実、唯一つのプログラムをインタープリットするだけでよいので、この閉じた世界では移植はかなり顕著に簡単になる。」との記載、引用文献記載事項2-1の記載、及び、引用文献記載事項3-3の記載等からみて、これらの「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」は「移植性の確保や開発負担の削減を図ること」を目的としたものであると言える。 (5)よって、移植性の確保や開発負担の削減を図ることを目的とした下記の事項によって特定される発明(以下「引用発明」と記す。)が、本願の出願日前である上記優先日前に頒布または電気通信回線を通じて公衆に利用可能となった相当数の文献に記載され、その結果当業者にとっては周知慣用技術となっていたものと認められる。＜引用発明＞「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」 5.対比以下、本願発明と引用発明とを比較する。 (1)引用発明は「ある特定のフォーマットのデータを共通のフォーマットのデータに変換し、さらに、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する方法。」であり、本願発明は「第1の特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース(GUI)を生成するための方法」であるから、引用発明と本願発明とは「データを生成するための方法」である点で共通する。 (2)引用発明における「ある特定のフォーマットのデータを共通のフォーマットのデータに変換」するステップは、本願発明における「少なくとも1つの第2の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトから複数のマークアップ言語ベースのプラットフォーム非依存のGUIフォーマットのGUIオブジェクトに変換するステップ」に対応付けられるものであるところ、両者は「ある特定のフォーマットのデータから共通のフォーマットのデータに変換するステップ」である点で共通すると言える。 (3)引用発明における「該共通のフォーマットのデータを他の特定のフォーマットのデータに変換する」ステップは、本願発明における「前記プラットフォーム非依存のGUIフォーマットのGUIオブジェクトを前記第1の特定のプラットフォームによって生成するための前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトに変換するステップ」に対応付けられるものであるところ、両者は「該共通のフォーマットのデータを他の特定のフォーマットのデータに変換するステップ」である点で共通すると言える。 (4)よって、本願発明は、下記一致点で引用発明と一致し、下記相違点で引用発明と相違する。＜一致点＞「データを生成するための方法において、ある特定のフォーマットのデータから共通のフォーマットのデータに変換するステップと、該共通のフォーマットのデータを他の特定のフォーマットのデータに変換するステップとを含む方法。」＜相違点1＞本願発明においては、生成される「データ」は「第1の特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース(GUI)」であり、「ある特定のフォーマットのデータ」は「少なくとも1つの第2の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクト」であり、「共通のフォーマットのデータ」は「複数のマークアップ言語ベースのプラットフォーム非依存のGUIフォーマットのGUIオブジェクト」であり、「他の特定のフォーマットのデータ」は「前記第1の特定のプラットフォームによって生成するための前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクト」である。 (これに対し、引用発明はデータの種類を特定するものではない。) ＜相違点2＞本願発明においては「前記変換するステップは、プラットフォーム非依存マークアップ言語ベースのGUIオブジェクトに関する見出しおよび関連値と、前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトに関する見出しおよび関連値とが関連付けて登録された変換マップを使用して、前記プラットフォーム非依存のGUIフォーマットのGUIオブジェクトを、前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトに変換するステップを含む」ものである。 (これに対し、引用発明は変換の具体的手順を特定するものではない。) 6.判断以下、上記相違点について検討する。 (1)相違点1について GUIの移植や開発のために、異なるプラットフォーム間でのGUIの変換をすることも、従来から適宜に開発・実施されていた周知慣用の技術思想であり、かかる分野においてもその移植性の確保や開発負担の削減は当然に追求される課題にほかならない(必要があれば引用文献記載事項4-1、4-2、5-1、5-2、6-1、6-2、7-2、8-1等参照)。してみると、引用発明におけるデータを特定のGUIフォーマットのGUIオブジェクトとすることで、異なるプラットフォーム間でのGUIの変換を行おうとすることは、当業者であれば容易に着想し得たことである。そして、この場合には、生成される「データ」が「第1の特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース(GUI)」となり、「ある特定のフォーマットのデータ」が「少なくとも1つの第2の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクト」となり、「共通のフォーマットのデータ」が「複数のマークアップ言語ベースのプラットフォーム非依存のGUIフォーマットのGUIオブジェクト」となり、「他の特定のフォーマットのデータ」が「前記第1の特定のプラットフォームによって生成するための前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクト」となることは、必然的に満たされる事項にほかならず、上記相違点1に係る事項を採用することは、当業者であれば、容易に想到し得たことにほかならないものと言える。 (2)相違点2について情報の変換に際し変換前後の対応関係を示す情報を用いることは証拠を挙げるまでもない常套手段にすぎないものである(必要があれば引用文献記載事項3-4、参考文献記載事項9-1、10-1等参照)。そして、GUIオブジェクトを見出しと関連値で表記されるマークアップ言語ベースで記述することも当業者の技術常識にほかならないものである(必要があれば、引用文献記載事項3-1、6-3、7-1等参照)。してみると、上記(1)で言及した引用発明における「データ」を特定のGUIフォーマットのGUIオブジェクトとした場合の「変換」を、「プラットフォーム非依存マークアップ言語ベースのGUIオブジェクトに関する見出しおよび関連値と、前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトに関する見出しおよび関連値とが関連付けて登録された変換マップを使用して、前記プラットフォーム非依存のGUIフォーマットのGUIオブジェクトを、前記第1の特定のプラットフォーム固有のGUIフォーマットのGUIオブジェクトに変換するステップを含む」ステップで実現すること、すなわち上記相違点2に係る事項を採用することも、上記相違点1に係る事項の実現に際して、当業者が適宜に選択し得た設計的事項にすぎないものである。 (3)したがって、本願発明の構成は引用発明に基づいて、当業者が容易に想到し得たものである。そして、当該構成の採用によって奏される作用効果も、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。よって、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものである。 (4)なお、引用文献4?8等からは、GUIの移植や開発のために、「異なるプラットフォーム間でのGUIの変換をする方法」(以下「引用発明2」と記す)も、当業者にとっては周知慣用技術となっていたものと認められるところ、当該引用発明2に上記4.(5)で引用発明として認定した周知慣用技術、及び上記(2)で言及した常套手段、技術常識を適用することによっても、本願発明は当業者が容易に発明し得たものであるとも言える。 7.むすび以上のとおり、本願請求項1に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができないものであり、他の請求項についての検討をするまでもなく、本願を拒絶すべきものとした原審の拒絶査定はその結論において誤りはない。したがって、原査定を取り消し、本願を特許をすべきものとすることはできない。よって、上記結論のとおり審決する。
審理終結日	2014-12-18
結審通知日	2014-12-24
審決日	2015-01-06
出願番号	特願2005-327699(P2005-327699)
審決分類	P 1 8・ 121- WZ (G06F)
最終処分	不成立
前審関与審査官	川崎優
特許庁審判長	辻本泰隆
特許庁審判官	小林大介山崎達也
発明の名称	特定のプラットフォームによって使用するためのグラフィカル・ユーザ・インターフェース(GUI)モデルを生成するための方法、システム、およびプログラム
代理人	太佐種一
代理人	市位嘉宏
復代理人	間山進也
代理人	上野剛史

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