【事件の表示】
　平成　６年特許願第１９３０６９号「多重言語標準リソースの使用方法およびデータ処理方法」拒絶査定不服審判事件〔平成　７年　３月３１日出願公開、特開平　７−　８４９５６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
１．手続の経緯 
　本願は、平成６年８月１７日の出願（パリ条約による優先権主張　１９９３年８月２４日　米国）であって、平成１５年５月１９日付けで拒絶理由が通知され、これに対し、同年１１月２６日付けで意見書が提出されるとともに手続補正がなされたが、平成１６年２月１６日付けで拒絶査定がなされ、これに対し、同年５月２４日に審判請求がなされたものである。 
　
２．本願発明 
　本願の請求項１及び請求項２に係る発明は（以下、それぞれ「本願発明１」及び「本願発明２」という。）、平成１５年３月１０日付け及び同年１１月２６日付けの手続補正書により補正された明細書及び図面の記載から見て、特許請求の範囲の請求項１及び請求項２に記載されたとおりの次のものと認める。
　
「【請求項１】　処理手段、記憶手段およびビデオ・ディスプレイを備えたデータ処理システムにおける標準リソースの使用方法において、
　ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第１の自然言語によるものであることを特定する第１の標準リソースを、上記記憶手段に記憶する段階と、
　上記第１の標準リソースによって特定されるものと同じ上記ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第２の自然言語によるものであることを特定する第２の標準リソースを、上記記憶手段に記憶する段階と、
　上記処理手段においてプログラムを実行する段階とから成り、
　上記プログラムは親ウィンドウおよび子ウィンドウを定義し、上記親ウィンドウの定義は、親ウィンドウのウィンドウ・エレメントが上記プログラムで使用される標準リソースによって特定される非テキスト形式の表示形態を有するように、上記第１および第２の標準リソースのいずれか一方に対する参照を含むとともに、上記プログラムで使用される標準リソースによって特定される自然言語のテキストを含むものであり、かつ、上記子ウィンドウは、子ウィンドウの定義に上記第１および第２の標準リソースのいずれか一方に対する直接の参照を含むことなく、親ウィンドウについて上記プログラムで使用される標準リソースによって特定される自然言語を承継する方法。
　
【請求項２】　上記プログラムがオペレーティング・システムであり、
　上記処理手段においてプログラムを実行する段階が、上記処理手段においてオペレーティング・システムを実行する段階から成る請求項１に記載の方法。」
　
３．引用例の発明
（１）原審の平成１５年５月１９日付けの拒絶理由に引用された、本願優先権主張日前に頒布された刊行物である特開平１−１４０２３８号公報（以下、「引用例１」という。）には次の事項が記載されている。
　
ａ．「
実施例
　以下の説明は、本発明の現在の好適な実施例を組み入れたコンピュータシステムの構成とオペレーションとに関するものである。」（第３頁左下欄１６行〜１９行）
　
ｂ．「
１．５．　オペレーティングシステムとルーチンパック
　コンピュータシステムは典型的には、オペレーティングシステムと称されるプログラムのグループを含む。オペレーティングシステムは、システムの全体オペレーションを制御し、かつ促進し、該システムのユーザに対して選定した基本的で一般的なサービスオペレーションを提供するプログラムのコレクションと見做すことができる。オペレーティングシステムのそのようなサービスやオペレーションの例としてはプロセス管理、イベント管理、記憶管理、入出力操作、物理的アドレス変換論理、図形／テキストおよびディスプレィ（表示）操作、ファイルアクセスおよび管理オペレーションおよび数学的演算を含む。
　オペレーティングシステムの従来からの見解では特定のアプリケーションプログラムに対して特定的あるいは一意的でない全ての機能やオペレーションはオペレーティングシステムにより実行されるべきである。さらに、伝統的な見方ではオペレーティングシステムを緊密に集積化し、かつプログラムの相互依存グループと見做しており、オペレーティングシステムは一般的に、アプリケーションプログラマが現在および将来にわたって希望する全ての機能を設計者が想定するプログラムの一体構造として設計されている。オペレーティングシステムが相対的にモノリシック的で、かつ複雑であり、その結果オペレーティングシステムを構成するプログラムと相互関係があるため、オペレーティングシステムを修正したり、変更したり、更新したり別の特徴を追加することは相対的に困難である。
　本発明によるオペレーティングシステムは、まずオペレーティングシステムにより実行される実際の機能とサービスとが最小に低減されるという点で従来のオペレーティングシステムと相違する。後述のように、本発明によるオペレーティングシステムは基本的にはプロセス、イベントおよび記憶管理機能と、物理的アドレス変換論理のみを実行する。
　第２に、通常オペレーティングシステムにより実行されるその他の機能やサービスはアプリケーションプログラム自体で通常実行される多くの機能やオペレーションと共にルーチンのライブラリによって実行される。「パック」と本明細書で称するルーチンのライブラリはオペレーティングシステムとアプリケーションプログラムの双方から独立して存在している。以下の説明で述べるように、パック内に含まれたルーチンは全体的な広範の適用性を有し、かつオペレーティングシステムとアプリケーションプログラムのサポート機能の双方に対して有用なるよう構成した、短くて、一般的で、単一目的のルーチンから構成されている。パックルーチンにより実行されるサービスと機能とは限定的ではないが、入出力操作、図形／テキストおよびデイスプレィ操作、ファイルアクセスおよび管理オペレーションおよび数学的演算を含む。
　また後述のように、各パックは、それらが実行するタイプあるいはそれらがオペレートするオブジェクトのタイプとにより関係づけられる一組のルーチン即ち機能を含んでいる。さらに、所定のパックの全てのルーチンには均一なインタフェースあるいは呼び出しおよび復帰シーケンスを備えており、かつパックは特にパックヘッダファイルと制御ブロック即ちパックが制御するオブジェクトに関する情報のブロックに関して一定のフォーマットに合致する必要がある。
　オペレーティングシステムの多様なサービスや機能およびアプリケーションプログラム内で通常提供される多くのオペレーションに対してルーチンのパックを用いることによりシステムのアーキテクチャと構成のフレキシビリティを大きく向上させる。機能およびサービスは容易かつ迅速に、さらにシステムのその他の機能を阻害するか、さもなければ圧迫することなく追加あるいは変更ができる。さらに、パックを使用することにより、通常側々の各アプリケーションプログラムに組み入れられる多くのオペレーションや機能が多くのアプリケーションプログラムにより共用されうるという点でアプリケーションプログラムのサイズや複雑さを低減させる。また標準化したインタフェースを備えたルーチンパックを使用することにより、多くのオペレーション、およびシステム、ユーザおよび他のアプリケーションプログラムに対するインタフェースが定義され、標準化されたルーチンパックインタフェースにより定義され、かつ該インタフェースに合致するようにされる点で種々のアプリケーションの統合を促進させる。
　好適な実施例においては、これらのルーチンは共用されたサブルーチンライブラリに記憶され、実行時間に必要に応じ動的（ダイナミック）にリンクされる。ある場合には、パックライブラリからのルーチンのコピイをプログラムの実行可能コードに含めることが望ましいが、この方法はアプリケーションプログラムの物理的サイズを増大させる。」（第１０頁左下欄１行〜１１頁左下欄１６行）
　
ｃ．「各オブジェクトタイプが別のタイプをその親として識別しうるさらに一般的なインへリタンスを実行しうる。そのような状況においては、子供のタイプに対して特に定義されていないオペレーションは親のタイプのオブジェクトマネージャにより子供タイプのオブジェクトに対して実行しうる。」（第１４頁右上欄１２行〜１８行）
　
ｄ．「
１．４．　資源
　「資源」とは、プログラムが使用するが、プログラムで実行可能のコードの一部としては記憶されないデータである。そのようなデータの例はアイコン、言語依存のテキスト、メツセージ、テキストフォント、フォーム、日付および時間並びにプレゼンテーションフォーマットを含む。したがって、資源はそのようなプログラムデータを、それが関連したプログラムから分離し、かつ独立して記憶する手段である。
　プログラムデータを資源に入れることにより、その中の情報をプログラムが実行可能のコードに影響を与えることなくカストマイズ即ち変更することができるようにする。例えば、ワードプロセッシングデータベースおよびスプレッドシートプログラムの英語、仏語および独語バージョンは単に、対応する資源の英語、仏語および独語バージョンを提供することにより生成することができる。プログラムの各バージョンにおいては、関連した資源に常駐するプログラムデータのみを変えればよく、プログラムの実行可能のコードは不変のままである。さらに、資源を使用することによりオブジェクトマネージャとその他のプログラムが共通のプログラムデータを共用できるようにし、そのため個々のオブジェクトマネージャとその他のプログラムのサイズと記憶要件を減少させる。
　また資源にデータを記憶することにより個々のユーザに対してプログラムの外観とオペレーションを容易にカストマイゼーションできるようにする。資源のユーザ特定のカストマイズしたバージョンをユーザのユーザプロファイルに記憶することができる。ユーザプロファイルに介在するいずれかのカストマイズした資源を自動的にそれらの標準的なカウンタパート（相当物）と必要に応じて自動的に（かつ資源を用いてプログラムに見えないようにして）代替させる機構が提供される。」（第１０頁左上欄５行〜右上欄２０行）
　
ｅ．「タイプフィールド７０６は、例えば資源がフォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいは例えばテキストあるいはデータのバイトストリングであろうと、特定の資源７００に含まれた資源のタイプの識別子を含む。この点に関し、フォームとは典型的にはスクリーンの表示、即ち、有益で明確なテキストフィールドおよび多くの場合ユーザにより埋めることの可能なフィールドを含むＣＲＴディスプレイである。メッセージの方は、例えばイベントあるいはユーザが実施すべき行動の通知のような情報をユーザに提供する手段であって、グラフィック、テキストあるいはオーディオでよい。周知のようにメニューとは、有限の複数の可能な行動あるいは事象の間でユーザが選択できるようにする手段である。プルダウンメニューは、そのメニューが必要なときのみ、即ちユーザの選択あるいはメニュー表示が適当であるとオブジェクトマネージャが検出すると実行されるものである。「プルダウン」とは単に、ニューが明らかにスクリーンの上部から引き下げることを意味する。アイコンはテキストストリングの代りにグラフ表示するものであって、テキストがメッセージを提供したり、行動あるいは選択を表示し、あるいは何かを識別するために使用されるほとんどの何処の場所においても使用しうる。ウインドウ資源は、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックであり、ユーザに表示すべき対応の窓を発生させる「パック」により使用される。
　その他の定義された資源タイプはタイプフォントを定義するフォント資源、特定の言語の統語および文法上のルールを定義する言語ルール資源と、キーボードの各種のキーの機能と用途とを定義するキーボード変換テーブルとを含みうる。最後に、バイトストリング資源は前述の定義したタイプの中の１個の範囲内にない何らかの資源を記憶するための自由にフォーマット化されるバイトストリングである。このタイプの資源において、情報の内部構造は資源を作成するエディタにより完全に検出される。」（第５３頁左上欄１７行〜左下欄１７行）
　
ｆ．「
１７．１．　資源ファイル
　資源は典型的には多く資源ファイルに記憶される。資源は所期の関連に基き資源ファイルにグループ化される。資源を用いたプログラムは、一時に開放されている複数の資源ファイルを有する。資源がリクエストされるとそのプログラムの現在開放している資源ファイルが、リクエストされた資源ＩＤを有する資源に対して検索される。このようにどの資源ファイルをプログラムが開放するか否かにより種々の資源を使用できる。
　以下の例はファイルに資源をグループ化することに係る事象のあるものを示す。１個の資源ファイルは、英語でスプレッドシートオペレーションに特に向けられるユーザのプロンプトの全てを含みうる。第２の資源ファイルは仏語におけるプロンプトを含む、第３と第４の資源ファイルはそれぞれ英語と仏語の一般的なプロンプトを含む。スプレッドシートオブジェクトマネージャは典型的にこれら資源ファイルの２個を開放している。第１と第３のファイルは英語を話すユーザ用であり、第２と第４のファイルは仏語を話すユーザ用である。また、ドキュメントオブジェクトマネージャはドキュメントオペレーションに特有の資源を含む資源ファイルと共に第３または第４の資源ファイルのいずれかを開放する。」（第５１頁右下欄１６行〜第５２頁左上欄２０行）
　
　上記ａ．〜ｆ．の記載によると、引用例１は、コンピュータシステムを対象としたものであり、コンピュータシステムは、処理手段、記憶手段およびビデオ・ディスプレイを備えている。さらに、上記ｄ．〜ｆ．の記載からみて、引用例１は、コンピュータシステムの「資源」の使用方法について記載されたものである。
　
　また、上記ｅ．における「タイプフィールド７０６は、例えば資源がフオーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいは例えばテキストあるいはデータのバイトストリングであろうと、特定の資源７００に含まれた資源のタイプの識別子を含む。」、及び、「ウインドウ資源は、ウィンドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックであり、ユーザに表示すべき対応の窓を発生させる「パック」により使用される。」という記載から、引用例１における「資源」は、フオーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックを含んでいる。
　
　さらに、上記ｄ．における「「資源」とは、プログラムが使用するが、プログラムで実行可能のコードの一部としては記憶されないデータである。そのようなデータの例はアイコン、言語依存のテキスト、メツセージ、テキストフォント、フォーム、日付および時間並びにプレゼンテーションフォーマットを含む。」や、上記ｃ．における「その他の定義された資源タイプはタイプフォントを定義するフォント資源、特定の言語の統語および文法上のルールを定義する言語ルール資源と、キーボードの各種のキーの機能と用途とを定義するキーボード変換テーブルとを含みうる。」の記載から、「資源」は言語に依存するデータを含んでいる。
　
　また、上記ｂ．における「第２に、通常オペレーティングシステムにより実行されるその他の機能やサービスはアプリケーションプログラム自体で通常実行される多くの機能やオペレーションと共にルーチンのライブラリによって実行される。「パック」と本明細書で称するルーチンのライブラリはオペレーティングシステムとアプリケーションプログラムの双方から独立して存在している。以下の説明で述べるように、パック内に含まれたルーチンは全体的な広範の適用性を有し、かつオペレーティングシステムとアプリケーションプログラムのサポート機能の双方に対して有用なるよう構成した、短くて、一般的で、単一目的のルーチンから構成されている。パックルーチンにより実行されるサービスと機能とは限定的ではないが、入出力操作、図形／テキストおよびデイスプレィ操作、ファイルアクセスおよび管理オペレーションおよび数学的演算を含む。」という記載や、上記ｅ．における「ウインドウ資源は、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックであり、ユーザに表示すべき対応の窓を発生させる「パック」により使用される。」の記載から、「資源」は、オペレーティングシステムとアプリケーションプログラムの双方から独立して存在する「パック」と称するルーチンのライブラリを介して使用している。
　
　加えて、上記ｆ．における「以下の例はファイルに資源をグループ化することに係る事象のあるものを示す。１個の資源ファイルは、英語でスプレッドシートオペレーションに特に向けられるユーザのプロンプトの全てを含みうる。第２の資源ファイルは仏語におけるプロンプトを含む、第３と第４の資源ファイルはそれぞれ英語と仏語の一般的なプロンプトを含む。スプレッドシートオブジェクトマネージャは典型的にこれら資源ファイルの２個を開放している。第１と第３のファイルは英語を話すユーザ用であり、第２と第４のファイルは仏語を話すユーザ用である。」の記載から、スプレッドシートは、「パック」と称するルーチンのライブラリを介して「資源」を使用し、あるスプレッドシートが英語もしくは仏語によるものであることを特定していることが示されているとともに、「英語でスプレッドシートオペレーションに特に向けられるユーザのプロンプトの全てを含みうる。」の記載から、英語でスプレッドシートオペレーションを行うためには、「パック」と称するルーチンのライブラリを介して「資源」を使用する必要があり、その際、ライブラリである「パック」と称するルーチンのライブラリを実行する段階を備えていると認められる。
　
　また、上記ｄ．における「したがって、資源はそのようなプログラムデータを、それが関連したプログラムから分離し、かつ独立して記憶する手段である。」の記載では、「資源」である「そのようなプログラムデータ」は、プログラムから分離しかつ独立して記憶されているから、このことは、コンピュータシステムにおいて、「資源」をコンピュータシステムに記憶する段階を含んでいると認められる。
　
　さらに、上記ｅ．における「ウインドウ資源は、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックであり、ユーザに表示すべき対応の窓を発生させる「パック」により使用される。」の記載から、引用例１に示されたものはウインドウを備えている。そして、スプレッドシートを実行する際には、スプレッドシートの内容を表示するためのウインドウ作成するためにウインドウを定義する必要があり、そのために必要な「資源」、すなわち、英語の「資源」や仏語の「資源」の一方を「パック」と称するルーチンのライブラリが使用していると認められる。また、対象とするウィンドウは、英語の「資源」を用いる場合は英語のテキストを、仏語の「資源」を用いる場合は仏語のテキストを含んでいると認められる。
　
　以上の記載から、引用例１には以下の発明（以下、「引用例１発明」という。）が記載されている。
　
　処理手段、記憶手段およびビデオ・ディスプレイを備えたコンピュータシステムにおける資源の使用方法において、
　フォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータを含み、かつ、英語によるものであることを特定する資源を記憶する段階と、
　フォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータを含み、かつ、仏語によるものであることを特定する資源を記憶する段階と、
　上記処理手段において「パック」と称するルーチンのライブラリを実行する段階とからなり、
　上記「パック」と称するルーチンのライブラリは、ウインドウを定義し、
　上記ウインドウの定義は、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータである英語の資源および仏語の資源のいずれか一方を使用するとともに、
　上記「パック」と称するルーチンのライブラリで使用される資源で特定される英語もしくは仏語のテキストを含む
方法。
　
（２）原審の平成１５年５月１９日付けの拒絶理由で引用例として、また、平成１６年２月１６日付けの拒絶査定で周知の技術を開示するものとして示された、本願優先権主張日前に頒布された刊行物である「UXソフトウェア　Ｘツールキット　プログラミングの手引　ＷＫＺ　４２−３」、日本電気株式会社、１９９３年６月、第３版　（以下、「引用例２」という。）には次の事項が記載されている。
　
（い）「第２章　ウィジットのインスタンス化
　ウィジットのインスタンスがあつまるとウィジットツリーが構成されます。ＸｔＡｐｐＣｒｅａｔｅＳｈｅｌｌによって返されるシェルウィジットがウィジットツリーのルートになります。子を持っているウィジットは木（ツリー）の節に相当し，子を持たないウィジットは木（ツリー）の葉に相当します。ポップアップ（第５章参照）の子を除けば，ウィジットツリーは関連しているＸのウィンドウツリーを定義します。
　ウィジットにはコンポジットとプリミティブがあります。両ウィジットとも子を持つことができますが、Ｘツ−ルキットはコンポジットウィジットやその子と他のクライアント間のインタフェ−スを構成するための管理機構を用意しています。コンポジットウィジットのサブクラスのウィジットはコンテナのようなものでコンポジットウィジット自身または他のクライアントやその両方によってインスタンス化された子ウィジットの集まりです。コンポジットウィジットは子のジオメトリを管理する機能を持っています。コンポジットウィジットは子を持たないことも稀にありますが，普通は少なくとも１つの子を持っています。それに対して子を持つプリミティブウィジットはクラスのわかっている子をインスタンス化し，外部のクライアントが子をインスタンス化することはありません。プリミティブウィジットはジオメトリを管理する機能を持っていません。
　Ｘツールキットはコンポジットウィジットとそのすべての子に対して，いろいろなオペレーション（リアライズ，破壊など）を再帰的に実行します。子を持ったプリミティブウィジットは子に代わって再帰的なオペレーションを実行する準備をしなければなりません。
　Ｘツールキットにはウィジットツリーを操作する関数がいくつかあります。例えば， ＸｔＲｅａｌｉｚｅＷｉｄｇｅｔは，ツリーを下方にたどってコンポジットウィジットの子ウィジットとポップアップウィジットを再帰的にリアライズします。
　ＸｔＤｅｓｔｒｏｙＷｅｄｇｅｔは，ツリーを下方へたどってすべてのコンポジットウィジットの子とポップアップウィジットを破壊します。リソースを参照したり変更したりする関数は，ツリーを上方にたどって，ウィジットの祖先からリソースを継承して決定します。ＸｔＭａｋｅＧｅｏｍｅｔｒｙＲｅｑｕｅｓｔは，ツリーを一段上方にたどって，通常の子ウィジットのジオメトリを管理するジオメトリマネージャを呼び出します。」（第３０頁１行〜２６行）
　
（ろ）「２．２ 　国際語対応（ローケール）
　リソースデータベースはプロセスの現在のローケールをもとにして生成されます。イントリンシックは，ディスプレイの初期化の中でスクリーンごとのデータベースを生成する前に，アプリケーションが指定した手続きを呼び出すことによってコマンド行オプションやディスプレイごとのリソースデータベースをもとにしてローケールを設定します。
　アプリケーションが指定する言語手続きはＸｔＬａｎｇｕａｇｅＰｒｏｃ型です。
　
　ｔｙｐｅｄｅｆ Ｓｔｒｉｎｇ（＊ＸｔＬａｎｇｕａｇｅＰｒｏｃ）（）；
　Ｓｔｒｉｎｇ　ＬａｎｇｕａｇｅＰｒｏｃ（ｄｉｓｐｌａｙ，ｌａｎｇｕａｇｅ，ｃｌｉｅｎｔ＿ｄａｔａ）
　　　　Ｄｉｓｐｌａｙ　＊ｄｉｓｐｌａｙ；
　　　　Ｓｔｒｉｎｇ　ｌａｎｇｕａｇｅ；
　　　　ＸｔＰｏｉｎｔｅｒ　ｃｌｉｎｅｔ＿ｄａｔａ；
　
　ｄｉｓｐｌａｙ　　　　　　ディスプレイが渡されます。
　ｌａｎｇｕａｇｅ　　　　　コマンド行オプションやディスプレイごとのリソースデータベースから得られた言語が渡されます。
　ｃｌｉｅｎｔ＿ｄａｔａ　　ＸｔＳｅｔＬａｎｇｕａｇｅＰｒｏｃ関数の呼び出し時に指定した追加情報が渡されます。
　
　言語手続きによって，ＸｔＤｉｓｐｌａｙＩｎｉｔｉａｌｉｚｅ関数によって決定された言語をアプリケーションから変更することができます。この関数は新しい言語を返し，後にＸｔＤｉｓｐｌｙＩｎｉｔｉａｌｉｚｅ関数がリソースファイルをロードするときにその言語を使用してパスを作成します。返された言語はイントリンシック内のメモリにコピーされます。
　
　ＸｔＤｉｓｐｌａｙＩｎｉｔｉａｌｉｚｅ関数から呼び出される言語手続きを設定する場合は，ＸｔＳｅｔＬａｎｇｕａｇｅＰｒｏｃ関数を使用します。
　
　ＸｔＬａｎｇｕａｇｅＰｒｏｃ　ＸｔＳｅｔＬａｎｇｕａｇｅＰｒｏｃ（ａｐｐ＿ｃｏｎｔｅｘｔ，ｐｒｏｃ，ｃｌｉｅｎｔ＿ｄａｔａ）
　　　　ＸｔＡｐｐＣｏｎｔｅｘｔ　ａｐｐ＿ｃｏｎｔｅｘｔ；
　　　　ＸｔｌａｎｇｕａｇｅＰｒｏｃ　ｐｒｏｃ；
　　　　ＸｔＰｏｉｎｔｅｒ　ｃｌｉｅｎｔ＿ｄａｔａ；
　
　ａｐｐ＿ｃｏｎｔｅｘｔ　　アプリケーションコンテキスト，またはＮＵＬＬを指定します。
　ｐｒｏｃ　　　　　　　　　言語手続きを指定します。
　ｃｌｉｅｎｔ＿ｄａｔａ　　言語手続きが呼び出されるときに渡す追加情報を指定します。
　ＸｔＳｅｔＬａｎｇｕａｇｅＰｒｏｃ関数はＸｔＤｉｓｐｌａｙＩｎｉｔｉａｌｉｚｅ関数から呼び出される言語手続きを設定します。言語手続きは指定したアプリケーションコンテキスト内のディスプレイに関連した情報をすべて初期化したあとに呼び出されます。ａｐｐ＿ｃｏｎｔｅｘｔにＮＵＬＬを指定した場合はそのプロセス内で生成されるすべてのアプリケーションコンテキストに対して設定されます。ｐｒｏｃにＮＵＬＬを指定した場合はデフォルトの言語手続きが設定されます。ＸｔＳｅｔＬａｎｇｕａｇｅＰｒｏｃ関数は以前に設定されていた言語手続きを返します。言語手続きが設定されていない場合は返り値は不定ですが，ＸｔＳｅｔＬａｎｇｕａｇｅＰｒｏｃ関数を呼び出した後であれば設定されている言語手続きを返します。」（第３６頁１行〜３７頁１行）
　
（は）「２．３　リソースデータベースのロード
　ＸｔＤｉｓｐｌａｙＩｎｉｔｉａｌｉｚｅ関数はまず指定したディスプレイで使用される言語を決定し，次に示すリソースの順番でスクリーンごとに必要なリソースデータベースを作成します。同じリソースが見つかった場合は最初のものが優先されます。
・アプリケーションのコマンド行（ａｒｇｖ）
・ローカルホスト上のホストごとのユーザ環境リソースファイル
　（環境変数ＸＥＮＶＩＲＯＮＭＥＮＴに設定されているファイルまたは〜／．Ｘｄｅｆａｕｌｔｓ−ｈｏｓｔｎａｍｅ）
・サーバ上のスクリーンごとのリソースプロパティ（ＳＣＲＥＥＮ＿ＲＥＳＯＵＲＣＥＳプロパティ）
・サーバ上のリソースプロパティ（ＲＥＳＯＵＲＣＥ＿ＭＡＮＡＧＥＲプロパティ）または，ローカルホスト上のユーザリソースファイル（〜／．Ｘｄｅｆａｕｌｔｓ）
・ローカルホスト上のアプリケーション固有のユーザリソースファイル
　環境変数（ＸＵＳＥＲＦＩＬＥＳＥＡＲＣＨＰＡＴＨに設定されているディレクトリ配下のファイル）
・ローカルホスト上のアプリケーション固有のクラスリソースファイル
　（／ｕｓｒ／ｌｉｂ／Ｘ１１／ａｐｐ−ｄｅｆｕａｌｔｓディレクトリ配下のファイル）
　ディスプレイ上の特定のスクリーンのリソースデータベースが必要になった場合（内部的にあるいはＸｔＳｃｒｅｅｎＤａｔａｂａｓｅ関数を呼び出すとき），ＸｔＤｉｓｐｌａｙＩｎｉｔｉａｌｉｚｅ関数は次のような方法でスクリーンのリソースデータベースを作成します。
・ＸＲｅｓｏｕｒｃｅＭａｎａｇｅｒＳｔｒｉｎｇ関数から返された文字列から一時的なデータベース（サーバリソースデータベース）を作成します。ＸＲｅｓｏｕｒｃｅＭａｎａｇｅｒＳｔｒｉｎｇ関数の返り値がＮＵＬＬの場合はユーザのホームディレクトリにあるリソースファイルの内容を使用します。ＵＮＩＸベースのシステムでは通常＄ＨＯＭＥ／．Ｘｄｅｆａｕｌｔｓです。
・言語手続きが設定されていれば，ＸｔＤｉｓｐｌａｙＩｎｉｔｉａｌｉｚｅ関数はまずコマンド行オプションの“−ｘｎｌＬａｎｇｕａｇｅ”かまたはｘｎｌＬａｎｇｕａｇｅ／ＸｎｌＬａｎｇｕａｇｅリソースが指定されている“−ｘｒｍ”オプションを検索します（２．４参照）。リソースが見つかった場合はそのリソースの値はＸＰＣＳ（Ｘ　Ｐｏｒｔａｂｌｅ　Ｃｈａｒａｃｔｅｒ　ｓｅｔ）であるとみなされます。見つからなかった場合ＸｔＤｉｓｐｌａｙＩｎｉｔｉａｌｉｚｅ関数はサーバリソースデータベース（ＸＰＣＳ）からリソース名がｎａｍｅ．ｘｎｌＬａｎｇｕａｇｅ，リソースクラスがＣｌａｓｓ．ＸｎｌＬａｎｇｕａｇｅのリソースを検索します。ｎａｍｅとＣｌａｓｓはそれぞれＸｔＤｉｓｐｌａｙＩｎｉｔｉａｌｉｚｅ関数に指定するａｐｐｌｃａｔｉｏｎ＿ｎａｍｅとａｐｐｌｉｃａｔｉｏｎ＿ｃｌａｓｓです。言語手続きは，リソースが見つかった場合そのリソースを，見つからなかった場合ＮＵＬＬ文字列を引き数に指定され呼び出されます。言語手続きから返される文字列（言語）はアプリケーション内で複数回参照されるのでイントリンシック内のメモリにセーブされます。
・コマンド行を解析することによってスクリーンリソースデータベースを初期化します（２．４参照）。
・言語手続きが設定されていなければ，最初のデータベースからリソース名がｎａｍｅ．ｘｎｌＬａｎｇｕａｇｅ，リソースクラスがＣｌａｓｓ．ＸｎｌＬａｎｇｕａｇｅのリソースを検索します。検索に失敗した場合はサーバリソースデータベースから検索します。さらに検索に失敗した場合は，言語は環境変数から決められます。ＰＯＳＩＸベースのシステムでは，環境変数ＬＡＮＧの値になります。言語がなければＮＵＬＬ文字列が使用されます。文字列（言語）はアプリケーション内で複数回参照されるのでイントリンシック内のメモリにセーブされます。
・言語を決定したあと，ユーザ環境リソースファイルがあれば最初のデータベースにマージされます。このファイルはユーザ，ホスト，プロセス固有で，ディスプレイごとやスクリーンごとのリソースにユーザが自由に上書きできます。ＰＯＳＩＸベースのシステムではユーザ環境リソースファイルのファイル名は環境変数ＸＥＮＶＩＲＯＮＭＥＮＴに設定します。この環境変数が設定されていなければユーザのホームディレクトリ配下の．Ｘｄｅｆａｕｌｔｓ−ｈｏｓｔファイルを探します。ｈｏｓｔはアプリケーションが実行されるマシンのホスト名です。
・スクリーンごとのリソースの指定がある場合はスクリーンリソースデータベースにマージされます。このリソースは，それぞれのスクリーンでＸＳｃｒｅｅｎＲｅｓｏｕｒｃｅＤａｔａｂａｓｅ関数から返される文字列を指定します。
・次に，先に生成されているサーバリソースデータベースをスクリーンリソースデータベースにマージします。サーバリソースデータベースのもととなる，サーバのプロパティやユーザリソースファイルはそのユーザによって所有され，ユーザによって作成されます。
・そのあと，ローカルホスト上のアプリケーション固有のリソースファイルはスクリーンリソースデータベースにマージされます。このファイルはアプリケーションによって所有され，ユーザの所有するディレクトリに置かれます。そのディレクトリパス名は，現在のディスプレイに関連したデータベースをセーブした後カレントなスクリーンデータベースを引数を指定してＸｒｍＳｅｔＤａｔａｂａｓｅ関数を呼び出し，次に引数に（ｄｉｓｐｌａｙ，ＮＵＬＬ，ＮＵＬＬ，ＮＵＬＬ，ｐａｔｈ，ＮＵＬＬ，０，ＮＵＬＬ）を指定してＸｔＲｅｓｏｌｖｅＰａｔｈｎａｍｅ関数を呼び出すことによって探します。ｐａｔｈはオペレーティングシステム固有の方法で指定します。ＵＮＩＸベースシステムでは環境変数ＸＵＳＥＲＦＩＬＥＳＥＡＲＣＨＰＡＴＨの値になります。環境変数ＸＵＳＥＲＦＩＬＥＳＥＡＲＣＨＰＡＴＨが設定されていなければ，開発者に依存したデフォルト値が使用されます。
（・・・　中　略　・・・）
・最後にローカルホスト上のアプリケーション固有のクラスリソースファイルをスクリーンデータベースにマージします。このファイルはアプリケーションによって所有され，通常はアプリケーションがインストールされるときにシステムのディレクトリにインストールされます。それはシステム管理者によって指定されるサイトワイドカスタマイゼイションに含まれます。アプリケーションのクラスリソースファイルの名前は，引数に（ｄｉｓｐｌａｙ，“ａｐｐ−ｄｅｆｕａｌｔｓ”，ＮＵＬＬ，ＮＵＬＬ，ＮＵＬＬ，ＮＵＬＬ，０，ＮＵＬＬ）を指定しＸｔＲｅｓｏｌｖｅＰａｔｈｎａｍｅ関数を呼び出すことによって探します。このファイルはアプリケーションの開発者によって用意されるもので，アプリケーションが正常に動作することが要求されます。クラスリソースファイルがない場合に最低限のリソースを必要とするアプリケーションはＸｔＡｐｐＳｅｔＦａｌｌｂａｃｋＲｅｓｏｕｒｃｅｓ関数によってフォールバックリソースを宣言することができます。カスタマイゼイションの変換文字列はＸｔＲｅｓｏｌｖｅｐａｔｈｎａｍｅによって直接検索されます。アプリケーションクラスリソースファイルの分解されたファイル名が，クラスリソースファイルの内容が最も優先度が低いものでもスクリーンリソースデータベースの元のリソースの値に影響を与えることができるようになっています。ＸｔＲｅｓｏｌｖｅＰａｔｈｎａｍｅを呼び出した後，ディスプレイに関連した元のオリジナルのデータベースがもどされます。」（第３８頁１行〜４０頁２９行）
　
（に）「２．５　ウィジットの生成
　ウィジットインスタンスを生成するプロセスは次の３つのフェーズからなります。
　　１．ウィジットの割り当てとリソースによる初期化が行われ，親の管理下へ任意に置かれる。
　　２．コンポジットウィジットには，ウィジットツリーの下から上への順に管理された子の通知が送られる。
　　３．ウィジットがＸのウィンドウを生成し，ウィンドウがマップされる。
　第１のフェーズを開始するため，アプリケーションはそのすべてのウィジットについてＸｔＣｒｅａｔｅＷｉｄｇｅｔを呼びます。それから，ＸｔＭａｎａｇｅＣｈｉｌｄを呼び出しそれぞれの親が管理しているセットにＸｔＣｒｅａｔＷｉｄｇｅｔされたウィジット（通常はほとんどあるいは全部）を追加します。ウィジットが生成，管理されるたびに各コンポジットウィジットが自分自身を配置するプロセスの生成を避けるため，このフェーズ中は，親ウィジットには管理されているセットの場合は知らされません。
　全ウィジットが生成されると，アプリケーションは最上位ウィジットにＸｔＲｅａｌｉｚｅＷｉｄｇｅｔを呼び出して第２，第３のフェーズを開始します。ＸｔＲｅａｌｉｚｅＷｉｄｇｅｔは，最初にウィジットツリーを再帰的に降順に（下から上へ）たどり，１つ以上の管理されている子を持った各コンポジットウィジットにｃｈａｎｇｅ＿ｍａｎａｇｅｄを使用して通知します。
　親に対するその管理されているセットの通知には，ジオメトリ配置やあるいはジオメトリの交渉が含まれます。親は，上から課されたサイズの制約（ユーザがアプリケーションのウィンドウサイズを指定した場合など）と，下からの示唆（プリミティブの子が望ましいサイズを計算した場合など）との調整を計ります。２つの間で調整が取れない場合は，ジオメトリの変更が起こり，ウィジットツリーを両方向に伝わって行きます。親は，いくつかの子にサイズと位置の変更を強制し，すべての子の収容状況をよくするために，自分の親にジオメトリ要求を発します。このプロセスが安定するまでは，スクリーン上で何がどこかへ行くかはわかりません。
　したがって，第１と第２のフェーズでは生成後に移動を繰り返す確率が高いので，Ｘのウィンドウは実際には生成されません。これによりＸサーバに不必要な要求を送るのを避けることができます。最後に，ＸｔＲｅａｌｉｚｅＷｉｄｇｅｔは第３のフェーズを開始します。すなわち，ウィジットツリーを昇順に（上から下へ）たどり，ｒｅａｌｉｚｅ手続きを使用して各ウィジットにＸのウィンドウを割り当て，管理されているウィジットをマップします。」（第４４頁１行〜２７行）
　
（ほ）「２．５．３　アプリケーションシェルのインスタンス生成
　アプリケーションは最上位ウィジットを複数持つことができ，異ったスクリーン上に持つことが可能です。依存しない複数のウィンドウを持つためには，ＸｔＡｐｐＣｒｅａｔｅＳｈｅｌｌを使用します。ＸｔＡｐｐＣｒｅａｔｅＳｈｅｌｌ関数はウィジットツリーのルートとなる最上位ウィジットを作成します。
　Ｗｉｄｇｅｔ　ＸｔＡｐｐＣｒｅａｔｅＳｈｅｌｌ（ａｐｐｌｉｃａｔｉｏｎ＿ｎａｍｅ，ａｐｐｌｉｃａｔｉｏｎ＿ｃｌａｓｓ，ｗｉｄｇｅｔ＿ｃｌａｓｓ，ｄｉｓｐｌａｙ，ａｒｇｓ，ｎｕｍ＿ａｒｇｓ）；
　　　　Ｓｔｒｉｎｇ　ａｐｐｌｉｃａｔｉｏｎ＿ｎａｍｅ；
　　　　Ｓｔｒｉｎｇ　ａｐｐｌｉｃａｔｉｏｎ＿ｃｌａｓｓ；
　　　　ＷｉｄｇｅｔＣｌａｓｓ　ｗｉｄｇｅｔ＿ｃｌａｓｓ；
　　　　Ｄｉｓｐｌａｙ　＊ｄｉｓｐｌａｙ；
　　　　ＡｒｇＬｉｓｔ　ａｒｇｓ；
　　　　Ｃａｒｄｉｎａｌ　ｎｕｍ＿ａｒｇｓ；
　
　ａｐｐｌｉｃａｔｉｏｎ＿ｎａｍｅ
　　　　　　　　　　　　　　　アプリケーションのインスタンスの名前を指定します。ａｐｐｌｉｃａｔｉｏｎ＿ｎａｍｅがＮＵＬＬの場合は，ＸｔＤｉｓｐｌａｙＩｎｉｔｉａｌｉｚｅで指定された名前を渡します。
　ａｐｐｌｉｃａｔｉｏｎ＿ｃｌａｓｓ
　　　　　　　　　　　　　　　ウィジットの代わりに使われているリソースクラスの文字列を指定します。ｗｉｄｇｅｔ＿ｃｌａｓｓがａｐｐｌｉｃａｔｉｏｎＳｈｅｌｌＷｉｄｇｅｔＣｌａｓｓかそのサブクラスであるときのｃｌａｓｓ＿ｎａｍｅ文字列です。
　ｗｉｄｇｅｔ＿ｃｌａｓｓ　　アプリケーションの最上位ウィジットとなるウィジットクラス（通常はａｐｐｌｉｃａｔｉｏｎＳｈｅｌｌＷｉｄｇｅｔＣｌａｓｓ）を指定します。
　ｄｉｓｐｌａｙ　　　　　　　リソースを得るためのディスプレイを指定します。
　ａｒｇｓ　　　　　　　　　　ＷＭ＿ＣＯＭＭＡＮＤプロパティに設定する引数リストを指定します。
　ｎｕｍ＿ａｒｇｓ　　　　　　引数リストの要素数を指定します。
　
　ＸｔＡｐｐＣｒｅａｔｅＳｈｅｌｌ関数はウィジットツリーのルートに対して新しいシェルウィジットインスタンスを生成します。このウィジットに対するスクリーンは，ＸｔＮｓｃｒｅｅｎの引数に対する最初に見に行ったａｒｇｓによって決定されます。ＸｔＮｓｃｒｅｅｎの引数でないものが，みつけられた場合，ディスプレイで指定されたｄｅｆａｕｌｔ ｓｃｒｅｅｎに関連されたリソースデータベースはｎａｍｅ．ｓｃｒｅｅｎのリソースやウィジットクラスがａｐｐｌｉｃａｔｉｏｎＳｈｅｌｌＷｉｄｇｅｔＣｌａｓｓか，そのサブクラスである場合のａｐｐｌｉｃａｔｉｏｎ＿ｃｌａｓｓに指定されているＣｌａｓｓ．Ｓｃｒｅｅｎのクラスに対して要求されます。
　ｗｉｄｇｅｔ＿ｃｌａｓｓがａｐｐｌｉｃａｔｉｏｎＳｈｅｌｌＷｉｄｇｅｔＣｌａｓｓかそのサブクラスでない場合，クラスは，ｗｉｄｇｅｔ＿ｃｌａｓｓに指定されたＣｏｒｅＣｌａｓｓＰａｒｔのｃｌａｓｓ＿ｎａｍｅフィールドです。これが，失敗である疑いがある場合，ディスプレイに指定されたｄｅｆａｕｌｔｓｃｒｅｅｎが使用されます。一度，ｓｃｒｅｅｎが決定されると，そのｓｃｒｅｅｎに関連されたリソースデータベースはａｒｇｓにある指定されていないシェルウィジットに全ての残りのリソースを検索するために使用されます。以前に決定されているウィジット名やクラスはこのウィジットツリーに含むオブジェクトにリソース名を全て十分に与えられた最も基本的な成分が使用されます。」（第４８頁２６行〜４９頁２５行）
　
　上記（ろ）及び（は）の記載から、スクリーンごとに作成されるリソースデータベースは、言語手続を含んだリソースであることがわかる。
　
　さらに、上記（い）における「ウィジットのインスタンスがあつまるとウィジットツリーが構成されます。ＸｔＡｐｐＣｒｅａｔｅＳｈｅｌｌによって返されるシェルウィジットがウィジットツリーのルートになります。子を持っているウィジットは木（ツリー）の節に相当し，子を持たないウィジットは木（ツリー）の葉に相当します。ポップアップ（第５章参照）の子を除けば，ウィジットツリーは関連しているＸのウィンドウツリーを定義します。」の記載や、上記（ほ）における「ＸｔＡｐｐＣｒｅａｔｅＳｈｅｌｌ関数はウィジットツリーのルートとなる最上位ウィジットを作成します。
（・・・　中　略　・・・）
一度，ｓｃｒｅｅｎが決定されると，そのｓｃｒｅｅｎに関連されたリソースデータベースはａｒｇｓにある指定されていないシェルウィジットに全ての残りのリソースを検索するために使用されます。」の記載によると、ウィジットツリーのルートとなる最上位ウィジットを作成するＸｔＡｐｐＣｒｅａｔｅＳｈｅｌｌ関数は、ｓｃｒｅｅｎを決定しており、このｓｃｒｅｅｎに関連したリソースデータベース、具体的には前記「言語手続を含んだリソース」を用い、ａｒｇｓで指定されていないリソースは、このリソースデータベースを検索することが示されているから、ウィジットツリーのルートとなる最上位のウィジットであるシェルウィジットは、言語手続を含んだリソースを持っていることがわかる。
　
　加えて、上記（い）における「リソースを参照したり変更したりする関数は，ツリーを上方にたどって，ウィジットの祖先からリソースを継承して決定します。」の記載から、上記ウィジットツリーで示される関係において、子に相当するウィジットは、祖先、即ち、親のリソースを継承していることが示されている。
　
　また、上記（に）における「ウィジットインスタンスを生成するプロセスは次の３つのフェーズからなります。
　　１．ウィジットの割り当てとリソースによる初期化が行われ，親の管理下へ任意に置かれる。
　　２．コンポジットウィジットには，ウィジットツリーの下から上への順に管理された子の通知が送られる。
　　３．ウィジットがＸのウィンドウを生成し，ウィンドウがマップされる。
　第１のフェーズを開始するため，アプリケーションはそのすべてのウィジットについてＸｔＣｒｅａｔｅＷｉｄｇｅｔを呼びます。
（・・・　中　略　・・・）
最後に，ＸｔＲｅａｌｉｚｅＷｉｄｇｅｔは第３のフェーズを開始します。すなわち，ウィジットツリーを昇順に（上から下へ）たどり，ｒｅａｌｉｚｅ手続きを使用して各ウィジットにＸのウィンドウを割り当て，管理されているウィジットをマップします。」の記載から、アプリケーションは全てのウィジット、即ち、親のウィジット及び子のウィジットをＸｔＣｒｅａｔｅＷｉｄｇｅｔを用いて定義しており、また、ウィジットツリーで表される各ウィジットはウィンドウであることがわかる。このことから、上記記載は、アプリケーションはＸｔＣｒｅａｔｅＷｉｄｇｅｔを用いて、親ウィンドウおよび子ウィンドウを定義していることが示されている。
　
　以上の記載から、引用例２には以下の周知技術が記載されている。
　
　周知のオペレーティング・システムであるＵＮＩＸのウィンドウシステムであるＸウィンドウの、グラフィカルユーザインターフェースを構成する部品要素、およびその集まりであるウィジットについて、
　アプリケーションはＸｔＣｒｅａｔｅＷｉｄｇｅｔを用いて、親ウィンドウおよび子ウィンドウを定義し、ＸｔＡｐｐＣｒｅａｔｅＳｈｅｌｌを用いて定義されたウィジットツリーのルートとなる最上位のウィンドウであるシェルウィジットは言語手続を含んだリソースを持っており、また、子ウィンドウは親ウィンドウのリソースを継承する技術。
　
４．本願発明１について
（１）対比
　本願発明１と引用例１発明とを対比すると、
　
　引用例１発明の「コンピュータ処理システム」は、本願発明１の「データ処理システム」に相当する。
　
　また、引用例１発明の「資源」のうち、「フォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータ」は、ウィンドウの表示形態を特定していることから、本願発明１の「ウィンドウ・エレメントの非テキスト形式の表示形態を特定し」ているものに相当し、さらにその「資源」を使用し英語（本願発明１の「自然言語」に相当する。）によるものか仏語（本願発明１の「自然言語」に相当する。）によるものか特定していることから、引用例１発明の「フォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータを含み、かつ、英語によるものであることを特定する資源」および「フォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータを含み、かつ、仏語によるものであることを特定する資源」は、本願発明１の「ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第１の自然言語によるものであることを特定する第１の標準リソース」および「上記第１の標準リソースによって特定されるものと同じ上記ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第２の自然言語によるものであることを特定する第２の標準リソース」に相当する。
　
　してみると、引用例１発明の「資源」は、「フォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータを含み、かつ、英語によるものであることを特定する」もの、もしくは、「フォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータを含み、かつ、仏語によるものであることを特定する」ものであるから、本願発明１の「ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第１の自然言語によるものであることを特定する第１の標準リソース」、もしくは、「上記第１の標準リソースによって特定されるものと同じ上記ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第２の自然言語によるものであることを特定する第２の標準リソース」を含むものである、「標準リソース」に相当する。
　
　さらに、引用例１発明では、「パック」と称するルーチンのライブラリを介して「資源」を用いているが、「パック」と称するルーチンのライブラリもプログラムであることには変わりないことから、引用例１発明の「「パック」と称するルーチンのライブラリ」は、本願発明１の「プログラム」に相当する。
　
　してみると、本願発明１と引用例１発明は次の点で一致する。
　
（一致点）
　処理手段、記憶手段およびビデオ・ディスプレイを備えたデータ処理システムにおける標準リソースの使用方法において、
　ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第１の自然言語によるものであることを特定する第１の標準リソースを、上記記憶手段に記憶する段階と、
　上記第１の標準リソースによって特定されるものと同じ上記ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第２の自然言語によるものであることを特定する第２の標準リソースを、上記記憶手段に記憶する段階と、
　上記処理手段においてプログラムを実行する段階とから成り、
　上記プログラムはウィンドウを定義し、上記ウィンドウの定義は、ウィンドウのウィンドウ・エレメントが上記プログラムで使用される標準リソースによって特定される非テキスト形式の表示形態を有するように、上記第１および第２の標準リソースのいずれか一方に対する参照を含むとともに、上記プログラムで使用される標準リソースによって特定される自然言語のテキストを含むものである方法。
　
　一方、以下の点で相違している。
　
（相違点）
　本願発明１は、プログラムが親ウィンドウおよび子ウィンドウ定義し、子ウィンドウについて「子ウィンドウは、子ウィンドウの定義に上記第１および第２の標準リソースのいずれか一方に対する直接の参照を含むことなく、親ウィンドウについて上記プログラムで使用される標準リソースによって特定される自然言語を承継する」としているのに対して、引用例１発明では、ウィンドウについての構成はあるものの、親ウィンドウおよび子ウィンドウについての構成や子ウィンドウの承継についての構成がない点。
　
（２）相違点についての当審判断
　引用例２に記載された周知技術の、「アプリケーション」「言語手続を含んだリソース」「親ウィンドウ」「子ウィンドウ」「継承」は、本願発明１の「プログラム」「第１および第２の標準リソース」「親ウィンドウ」「子ウィンドウ」「承継」に相当する。
　
　さらに、引用例２に記載された周知技術では、アプリケーションにより定義されたウィジットツリーのルートとなる最上位のウィンドウであるシェルウィジットは言語手続を含んだリソースを持っており、加えて、子ウィンドウは親ウィンドウのリソースを承継していることから、シェルウィジットの子ウィンドウは、親ウィンドウについて上記プログラムで使用される標準リソースによって特定される言語手続を承継している。このことは、本願発明１の「親ウィンドウについて上記プログラムで使用される標準リソースによって特定される自然言語を承継する」に相当するものである。
　
　また、引用例２に記載された周知技術の子ウィンドウが上記承継を行っているので、子ウィンドウのリソースによる定義を行う際には、親ウィンドウのリソースを直接参照する必要がなく、上記直接の参照は行っていないと認められる。このことは、本願発明１の「子ウィンドウの定義に上記第１および第２の標準リソースのいずれか一方に対する直接の参照を含むことなく」に相当する。
　
　してみると、引用例２には「プログラムは親ウィンドウおよび子ウィンドウを定義し、子ウィンドウは、子ウィンドウの定義に上記第１および第２の標準リソースのいずれか一方に対する直接の参照を含むことなく、親ウィンドウについて上記プログラムで使用される標準リソースによって特定される自然言語を承継する」という周知技術が開示されていることになる。
　
　そして、引用例１発明と上記周知技術とは共にオブジェクト指向のプログラムに関するものであり、さらに、引用例１の上記ｃ．において「各オブジェクトタイプが別のタイプをその親として識別しうるさらに一般的なインへリタンスを実行しうる。」という記載があるように、引用例１においても、親子関係にあるオブジェクト間ではインヘリタンス（承継）を行うことが示されており、また、引用例１発明においてウィンドウを複数持つことは可能であることから、引用例１発明のプログラムを作成する際に上記周知技術を適用し、「プログラムは親ウィンドウおよび子ウィンドウを定義し、子ウィンドウは、子ウィンドウの定義に上記第１および第２の標準リソースのいずれか一方に対する直接の参照を含むことなく、親ウィンドウについて上記プログラムで使用される標準リソースによって特定される自然言語を承継する」ようにすることは、当業者が容易に想到し得る事項である。
　
　そして、本願発明１の作用効果は、引用例１及び周知技術から当業者が予測できる範囲のものである。
　
　したがって、本願発明１は、引用例１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
５．本願発明２について
（１）対比
　本願発明２と引用例１発明とを対比すると、
　本願発明２は、本願発明１の「プログラム」を「オペレーティング・システム」とし、「上記処理手段においてプログラムを実行する段階」を「上記処理手段においてオペレーティング・システムを実行する段階」としたものであるから、上記「４．（１）対比」で検討したように、引用例１発明の「コンピュータ処理システム」，「資源」，「フォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータを含み、かつ、英語によるものであることを特定する資源」および「フォーム、メッセージ、プルダウンメニュー、アイコン、ウインドウ構造、あるいはテキストあるいはデータのバイトストリングや、ウインドウ、即ちユーザへの可視表示を含むスクリーンの有限の部分を説明するパラメータブロックや言語に依存するデータを含み、かつ、仏語によるものであることを特定する資源」は、本願発明２の「データ処理システム」，「標準リソース」，「ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第１の自然言語によるものであることを特定する第１の標準リソース」および「上記第１の標準リソースによって特定されるものと同じ上記ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第２の自然言語によるものであることを特定する第２の標準リソース」に相当する。
　
　さらに、引用例１発明では、「パック」と称するルーチンのライブラリを介して「資源」を用いているが、「パック」と称するルーチンのライブラリはプログラムであり、また、本願発明２の「オペレーティング・システム」もプログラムのひとつであるから、両者は共に、プログラムという点で一致している。
　
　してみると、本願発明２と引用例１発明は次の点で一致する。
　
（一致点）
　処理手段、記憶手段およびビデオ・ディスプレイを備えたデータ処理システムにおける標準リソースの使用方法において、
　ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第１の自然言語によるものであることを特定する第１の標準リソースを、上記記憶手段に記憶する段階と、
　上記第１の標準リソースによって特定されるものと同じ上記ウィンドウ・エレメントの非テキスト形式の表示形態を特定し、かつ、上記ウィンドウ・エレメント内のテキストが第２の自然言語によるものであることを特定する第２の標準リソースを、上記記憶手段に記憶する段階と、
　上記処理手段においてプログラムを実行する段階とから成り、
　上記プログラムはウィンドウを定義し、上記ウィンドウの定義は、ウィンドウのウィンドウ・エレメントが上記プログラムで使用される標準リソースによって特定される非テキスト形式の表示形態を有するように、上記第１および第２の標準リソースのいずれか一方に対する参照を含むとともに、上記プログラムで使用される標準リソースによって特定される自然言語のテキストを含むものである方法。
　
　一方、以下の点で相違している。
　
（相違点１）
　本願発明２においては、プログラムは「オペレーティング・システム」であるのに対して、引用例１発明においては、プログラムは「「パック」と称するルーチンのライブラリ」である点。
　
（相違点２）
　本願発明２では、「オペレーティング・システム」が親ウィンドウおよび子ウィンドウ定義し、子ウィンドウについて「子ウィンドウは、子ウィンドウの定義に上記第１および第２の標準リソースのいずれか一方に対する直接の参照を含むことなく、親ウィンドウについて上記オペレーティング・システムで使用される標準リソースによって特定される自然言語を承継する」としているのに対して、引用例１発明では、ウィンドウについての構成はあるものの、親ウィンドウおよび子ウィンドウに関する構成や子ウィンドウについての承継に関する構成がない点。
　
（２）相違点についての当審判断
　
（相違点１）に関して
　引用例１発明では「パック」と称するルーチンのライブラリは、オペレーティングシステムとアプリケーションプログラムの双方から独立して存在しているが、引用例１に従来のオペレーティングシステムとして記載されている、上記ｂ．における「オペレーティングシステムの従来からの見解では特定のアプリケーションプログラムに対して特定的あるいは一意的でない全ての機能やオペレーションはオペレーティングシステムにより実行されるべきである。さらに、伝統的な見方ではオペレーティングシステムを緊密に集積化し、かつプログラムの相互依存グループと見做しており、オペレーティングシステムは一般的に、アプリケーションプログラマが現在および将来にわたって希望する全ての機能を設計者が想定するプログラムの一体構造として設計されている。」と同様に、「パック」と称するルーチンのライブラリをオペレーティングシステムと一体構造とし、「オペレーティング・システム」内に統合することは、当業者が容易に想到し得る事項である。
　
（相違点２）に関して
　上記「４．（２）相違点についての当審判断」で検討したように、引用例２には、本願発明１の「プログラムは親ウィンドウおよび子ウィンドウを定義し、子ウィンドウは、子ウィンドウの定義に上記第１および第２の標準リソースのいずれか一方に対する直接の参照を含むことなく、親ウィンドウについて上記プログラムで使用される標準リソースによって特定される自然言語を承継する」に相当する周知技術が記載されている。
　
　そして、引用例１発明と上記周知技術とは共にオブジェクト指向のプログラムに関するものであり、さらに、引用例１の上記ｃ．において「各オブジェクトタイプが別のタイプをその親として識別しうるさらに一般的なインへリタンスを実行しうる。」という記載があるように、引用例１においても、親子関係にあるオブジェクト間ではインヘリタンス（承継）を行うことが示されており、また、引用例１発明においてウィンドウを複数持つことは可能であること、さらに、上記「（相違点１）に関して」で検討したように、引用例１発明の「「パック」と称するルーチンのライブラリ」を「オペレーティング・システム」とし、「オペレーティング・システム」により「資源」が提供される際に、上記周知技術を適用し、「オペレーティング・システムは親ウィンドウおよび子ウィンドウを定義し、子ウィンドウは、子ウィンドウの定義に上記第１および第２の標準リソースのいずれか一方に対する直接の参照を含むことなく、親ウィンドウについて上記オペレーティング・システムで使用される標準リソースによって特定される自然言語を承継する」ようにすることは、当業者が容易に想到し得る事項である。
　
　そして、本願発明２の作用効果は、引用例１及び周知技術から当業者が予測できる範囲のものである。
　
　したがって、本願発明２は、引用例１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
６．請求人が提出した上申書について
　請求人は平成１９年１月３１日付けで上申書を提出し、「本出願は、平成１６年２月１６日付起案の拒絶査定において、「標準リソース」の解釈につき、「オペレーティング・システムによって提供されるもの」という前提がまったく考慮されないまま、本件発明の「標準リソース」の認定が行われている。
　したがって、「標準リソース」という用語の意味が明確となるよう、特許法３６条６項２号の拒絶理由を通知されるよう、上申する。」と主張している。
　しかしながら、請求項１には「標準リソース」について「上記親ウィンドウの定義は、親ウィンドウのウィンドウ・エレメントが上記プログラムで使用される標準リソースによって特定される非テキスト形式の表示形態を有するように、上記第１および第２の標準リソースのいずれか一方に対する参照を含むとともに、上記プログラムで使用される標準リソースによって特定される自然言語のテキストを含むものであり、かつ、上記子ウィンドウは、子ウィンドウの定義に上記第１および第２の標準リソースのいずれか一方に対する直接の参照を含むことなく、親ウィンドウについて上記プログラムで使用される標準リソースによって特定される自然言語を承継する」と記載されているように、「標準リソース」が「プログラム」によって提供されていることは明確であり、請求人の上記主張は採用することができない。
　
７．むすび
　以上のとおり、本願の請求項１及び請求項２に係る発明は、引用例１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。