【事件の表示】
　平成　９年特許願第２１８４１７号「リソース・ファイル・ビルダ・ツールプログラムを記憶したコンピュータ読み取り可能な記録媒体及びリソースファイル作成装置」拒絶査定不服審判事件〔平成１０年　５月　６日出願公開、特開平１０−１１６１８５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成９年８月１３日（パリ条約による優先権主張１９９６年８月２１日、米国）の出願であって、その請求項１に係る発明は、平成１５年５月１５日付けの手続補正書によって補正された明細書及び図面の記載からみて、本願の特許請求の範囲の請求項１に記載されたとおりの次のものと認める。
「リソース・ファイルを生成するためのリソース・ファイル・ビルダ・ツールプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
　前記リソース・ファイル・ビルダ・ツールプログラムは、ユーザーが選択可能な複数のアイコン表現を含むグラフィック・ユーザー・インターフェースをコンピュータに表示させることが可能であり、
　前記リソース・ファイル・ビルダ・ツールプログラムは、クラス・ライブラリを含み、前記クラス・ライブラリは、キーワード・クラスを含んでおり、前記キーワード・クラスにおいて、各キーワードは、各々の前記アイコン表現に対応し、リソース・ファイル内に記述可能であり、更に、前記リソース・ファイル・ビルダ・ツールプログラムは、コンピュータに、
　前記アイコン表現のうちの１つをユーザーが選択した場合、対応する前記キーワード・クラスのうちの１つを選択し、
　前記選択された前記キーワード・クラスに関連するキーワード・データを入力するよう開発者に促すための表示を、前記グラフィカル・ユーザー・インターフェース上に表示し、
　前記選択されたキーワード・クラスであって、前記入力されたキーワード・データを有する、前記キーワード・クラスのインスタンスを前記リソース・ファイル内に記述する、動作を行わせる、
　前記記録媒体。」
　
２．引用例
　これに対し、原査定の拒絶の理由で引用された、本願優先権主張の日前に頒布された日向駿馳著「入門Ｖｉｓｕａｌ　Ｃ＋＋」翔泳社発行(以下、「 引用例」という。)第１４１ページから第１５８ページ、第１９６ページから第１９８ページ内には、図面とともに次の事項が記載されている。
　
（１）「2-3-1　リソースエデイタ
　プログラムのリソースを編集するには，Visual Workbenchのエディタで.rcを開いて，テキストファイルとして編集することもできます．しかし，通常はより便利なツールであるリソースエディタApp Studioを使って作成したり変更したりします．
　App Studioは，プログラムマネージャなどから直接起動することができる独立したアプリケーションですが，Visual Workbenchでプログラミングしている際には[ツール]/[App Studio]で起動することができます．この方法を使うと， Visual Workbenchで現在開いているプロジェクトのリソーススクリプトファイルが自動的に読み込まれるので，すぐにリソースを編集することができます．Visual WorkbenchでMEditのプロジェクトを開いている状態で[ツール]/[App Studio]を選択してください． App Studioが起動して，MEdit.rcが読み込まれ，リソースブラウザウィンドウが表示されます（図2-9）．
　リソースブラウザのウィンドウの左側には，App Studioで編集できるリソースの種類 （Accelerator，Bitmapなど）が表示されています．」（第１４１ページ１行目−第１４２ページ４行目）
　
（２）「リソーススクリプトファイル（.rc）
　メニューやダイアログボックスなど，App Studioを使って編集することはプログラムのリソースの一部なので，リソーススクリプトファイル（.rc）に記述されます．.rcはテキストファイルなので,AppWizardからMEdit.rcを開くと普通のテキストとして編集することができます（ただし，これはデフォルトの設定の場合のことで，[オプション]/[エディタ]で「.RCを開くときにApp Studioを起動」をチェックしてしまうと，テキストとして開けません）．
　たとえば，MEditのメニューは,MEdit.rcの次の部分に対応します．
　
    IDR_MEDITTYPE MENU PRELOAD DISCARDABLE
    BEGIN
    （　…　中略　…　）
　　END
　
　IDR_MEDITTYPEはメニューのIDで，新規作成(\036N\037シ)\tCtrl+NやlD_FILE_NEWは，プロパティウインドウで設定するメニュー項目のプロパティです．また，プロパティウインドウの「プロンプト」で設定するステータスバーに表示する文字列は，.rcファイルの別のセクションである文字列テーブル（STRINGTABLE）のセクションに，次のように記述されます．
　
    STRINGTABLE DISCARDABLE
　　BEGIN
    （　…　中略　…　）
    END
　
 ダイアログボックスについても，.rcファイルの中でたとえば次のような形式で記述されます．
　
    IDD_ABOUTBOX DIALOG DISCARDABLE  34, 22, 217, 55
    STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
    （　…　中略　…　）
    END
　App Studioはこのような形式のリソーススクリプトファイル（.rc）を読み込んで，プログラマが操作しやすい形で提示し，プログラマが保存を選択すると再び.rcに上記の形式で保存します．」（第１４６ページ−第１４７ページの枠内、左欄１行目−右欄１９行目）
　
（３）「2-4-1　ダイアログボックスのデザイン
　ダイアログボックスもメニューと同様にプログラムのリソースです．そして，ダイアログボックスもApp Studioを使ってデザインすることができます．
　App StudioのリソースブラウザでDialogを選択すると，最初は「リソース」リストボックスにIDD_ABOUTBOXだけがあるはずです（図2-19）．これは[ヘルプ]/[バージョン情報]で表示されるダイアログボックスです．
 「タブストップの設定」ダイアログボックスを新たに作成するためには，[新規作成]を選択します．すると，「リソースの新規作成」ダイアログボックスが表示されます．「リソースの種類」でDialogが選択されているはずですから，確認してから[OK]を選択しまず（図2-20）．
　「リソースの新規作成」ダイアログボックスで[OK]を選択すると，新しいダイアログボックスが作成されます．新規作成したダイアログボックスには，初めから[OK]と[キャンセル]ボタンが付いています．
　最初に，ダイアログボックス全体のプロパティを設定します．新規作成したダイアログボックスの領域のどこか（[OK]や[キャンセル]などのコントロール上は除く）をクリックするか，[ウィンドウ]/[プロパティ]を選択すると，プロパティボックスが表示されます．メニューと同じ要領で「ID」にID_SET_TABSTOPSを，「キャプション」に「タブストップの設定」を入力します（図2-22）．
　ダイアログボックスのプロパティボックスには，図2-22に示した「一般」プロパティ以外に，「スタイル」プロパティがあります（図2-23）．一般／スタイルはプロパティウィンドウの右上隅にあるコンボボックスで選択します．一般プロパティではほとんどの場合に必要不可欠なIDやキャプションを設定するのに対して，スタイルには主に外見に関するオプション的な設定事項があります．
　ダイアログボックス全体に関するプロパティの設定が終わったら，コントロールパレットからコントロールを選んでダイアログボックスに配置します（図2-24）．
　「タブストップの設定」ダイアログボックスは，最終的に図2-25のようにしたいので，スタティックテキストとエディットボックスを図2-26のように配置します．
　コントロールにもそれぞれプロパティがあります．
　通常，IDはコントロールを識別するために使うので，ユニークな（他と違う）値を設定しなければなりません．しかし，スタティックテキストコントロールの場合に限っては，IDを使って実行時に状態を変えるなど特別なことをしない限り，IDはIDC_STATICのままで変えずにおきます．「キャプション」は入力してください（図2-27）．
　さらにエディットボックスのプロパティを図2-28のように設定します．
　「タブストップの設定」ダイアログボックスのデザインは以上で終わりです．App Studioのメニューで[ファイル]/[保存]を選択して，いったん保存してください．」（第１４９ページ１行目−第１５３ページ３行目）
　
　なお、（３）の記載において「保存」されるのは、編集の対象となっているリソーススクリプトファイルであること及び、保存されたリソーススクリプトファイルには、設定されたプロパティを有する新規作成したダイアログボックスが含まれることは自明である。
　
　これらのことから、引用例には、「リソーススクリプトファイルを編集するためのリソースエディタアプリケーションであって、
　前記リソースエディタアプリケーションは、ユーザーが選択可能な複数のリソースの種類のメニューを含むリソースの新規作成ダイアログボックスをコンピュータに表示させることが可能であり、
　更に、前記リソースエディタアプリケーションは、コンピュータに、
　前記複数のリソースの種類のうち、Dialogをユーザーが選択した場合、新しいダイアログボックスを初期状態で表示し、プロパティの設定を受け付け、
　設定されたプロパティを有する新規作成したダイアログボックスをリソーススクリプトファイル内に記述する、動作を行わせる、
　前記リソースエディタアプリケーション。」に関する発明が開示されているものと認める。（以下、これを「引用発明」という）
　
３．対比
　本願発明と引用発明を対比する。
　まず各発明における「リソース」について、本願明細書では「リソースには、アイコン、カーソル、メニュー、ダイアログ・ボックス、特定のタイプのテキスト、オーディオ・クリップ、アニメーション・クリップ、ビットマップなどを含めることができる。」（【０００２】段落）と説明しており、引用例においても、上記（２）の記載で、メニュー、あるいはダイアログボックスをリソースとして取り扱っているから、両者でいう「リソース」は一致する。したがって、本願発明の「リソース・ファイル」、「リソース・ファイル・ビルダ・ツールプログラム」は、引用発明の「リソーススクリプトファイル」、「リソースエディタアプリケーション」に対応する。
　また、本願発明の「ユーザーが選択可能な複数のアイコン表現を含むグラフィック・ユーザー・インターフェース」と、引用発明の「リソースの種類のメニューを含むリソースの新規作成ダイアログボックス」は、「リソースの種類を選択するグラフィック・ユーザー・インターフェース」である点で共通し、本願発明の「アイコン表現のうちの１つをユーザーが選択」することと、引用発明の「前記複数のリソースの種類のうち、Dialogをユーザーが選択」することは、「ユーザーがリソースの種類を選択する」点で共通する。
　さらに、本願発明の「キーワード・データ」と、引用発明における「プロパティ」は、「選択された種類のリソースに関連するデータ」である点で共通である。また、引用発明では、「新しいダイアログボックスを初期状態で表示」した後、「プロパティの設定を受け付け」るのであるから、「新しいダイアログボックスを初期状態で表示」することは、「プロパティ」の入力を促すものと解することができる。してみると、本願発明の「キーワード・データを入力するよう開発者に促すための表示を、前記グラフィカル・ユーザー・インターフェース上に表示」することは、引用発明の「新しいダイアログボックスを初期状態で表示」することに対応する。
　また、本願発明の「前記選択されたキーワード・クラスであって、前記入力されたキーワード・データを有する、前記キーワード・クラスのインスタンス」と、引用発明の「設定されたプロパティを有する新規作成したダイアログボックス」は、「ユーザーが選択した種類のリソースであって、選択した種類のリソースに関連するユーザーが入力したデータを含むリソースのデータ」である点で共通する。
　
　してみると、両者は、「リソース・ファイルを生成するためのリソース・ファイル・ビルダ・ツールプログラムであって、
　前記リソース・ファイル・ビルダ・ツールプログラムは、リソースの種類を選択するグラフィック・ユーザー・インターフェースをコンピュータに表示させることが可能であり、
　更に、前記リソース・ファイル・ビルダ・ツールプログラムは、コンピュータに、
　ユーザーがリソースの種類を選択した場合、選択された種類のリソースに関連するデータを入力するよう開発者に促すための表示を、前記グラフィカル・ユーザー・インターフェース上に表示し、
　ユーザーが選択した種類のリソースであって、選択した種類のリソースに関連するユーザーが入力したデータを含むリソースのデータを前記リソース・ファイル内に記述する、動作を行わせる。」点で一致する。
　そして、
（相違点１）本願発明は「リソース・ファイル・ビルダ・ツールプログラムを記録したコンピュータ読み取り可能な記録媒体」であるのに対し、引用発明は「アプリケーション」、すなわち「プログラム」そのものである点、
（相違点２）本願発明ではリソースの種類の選択の際、「ユーザーが選択可能な複数のアイコン表現」が表示されるのに対し、引用発明では、「複数のリソースの種類のメニュー」である点、
（相違点３）本願発明では、リソース・ファイル・ビルダ・ツールプログラムに、クラス・ライブラリを含み、前記クラス・ライブラリは、キーワード・クラスを含んでおり、前記キーワード・クラスにおいて、各キーワードは、各々の前記アイコン表現に対応し、リソース・ファイル内に記述可能であり、ユーザーがアイコン表現のうちの１つを選択すると、対応するキーワード・クラスを選択し、リソース・ファイルにキーワード・クラスのインスタンスが記述されるのに対し、引用発明ではこれに相当する開示がない点、
で相違する。
　
４．当審の判断
　上記相違点について検討する。
（相違点１）について
　プログラムをコンピュータ読み取り可能な記録媒体に記録することは、本願出願前周知慣用の技術であり、引用発明のリソースエディタアプリケーションをコンピュータ読み取り可能な記録媒体に記録することに格別の創作困難性は認めらない。
（相違点２）について
　「アイコン表現」は、ユーザーに選択を行わせるインターフェースとして本願出願前周知慣用の技術であり、引用発明において、「複数のリソースの種類のメニュー」の各選択項目をアイコン表現とすることに格別の創作困難性は認められない。
（相違点３）について
　オブジェクト指向プログラミングにおいてはプログラムの部品をクラスとして記述し、これを集めてクラスライブラリとすることは技術常識である。引用例に記載されるApp Studioはオブジェクト指向プログランミング言語であるVisualC++をベースとするものであるから、リソース・ファイルに記述されるリソースという部品のひな形をクラスとして記述し、インスタンス化したものをリソース・ファイルに記述するようにすることに格別の創作困難性は認められない。また、上記した引用例の（２）の記載を見ると、メニューのリソースには「MENU」、文字列テーブルのリソースには「STRINGTABLE」、ダイアログボックスのリソースには「DIALOG」の各文字列が含まれており、これを本願発明でいう「リソース・ファイル内に記述可能」な「キーワード」とみれば、上述のようにリソースのひな形をクラスとして記述した場合に、これらの文字列がリソースのひな形となるクラスに含まれることは自明である。さらに、引用発明は、「複数のリソースの種類のメニュー」から選択することで、選択された種類のリソースをリソーススクリプトファイルに記述するものであるから、上述のようにリソースのひな形をクラスとして記述した場合に「複数のリソースの種類のメニュー」の各選択項目がリソースのひな形であるクラスと対応づけられることは自明であり、その結果、該クラスに含まれる「キーワード」に相当する文字列とも対応付けがなされていると考えることができる。
　
　これらのことから、上記相違点１乃至３はいずれも格別のものでない。
　
　なお、請求人は審尋に対する平成１７年７月４日付回答書において「前置報告における認定では、上記（ｃ）の構成要件に関連して、審判請求書における審判請求人の主張である「キーワードを介して、リソース・ファイル内の情報をアイコン化して表示」すること、およびリソース・ファイルに記述されているキーワードが表示されることを示唆しているが、そのような事項も請求項に記載されていないと認定するものである。　しかしながら、審判請求人は、前置報告における「キーワードを介して、リソース・ファイル内の情報をアイコン化して表示」されることは当業者であれば、理解されるべきものであると反論する。」と主張し、更に「キーワード・クラスとキーワードとは上記構成要件（ｃ）において明確に区別されており、キーワード・クラスが、リソース・ファイル内に記述された各キーワードを各々の前記アイコン表現として表示させなければ、どのような対象がアイコン表現に対応されるのかを考慮すれば、アイコン表現に表示されるのはリソース・ファイル内に記述されたキーワードでしかあり得ないことは、キーワード・クラスが複数のオブジェクトから形成される構造体であり、アイコン表現とするべきキーワードとは直接関連しないものであることを考慮すれば理解されるはずのものである。」と主張するので、この点について検討する。
　まず、「キーワードを介して、リソース・ファイル内の情報をアイコン化して表示」すること、およびリソース・ファイルに記述されているキーワードが表示されることが、本願発明に直接的に記載されていないことは明らかである。
　そして、請求人は「キーワード・クラスが、リソース・ファイル内に記述された各キーワードを各々の前記アイコン表現として表示させなければ、どのような対象がアイコン表現に対応されるのかを考慮すれば、アイコン表現に表示されるのはリソース・ファイル内に記述されたキーワードでしかあり得ないことは、キーワード・クラスが複数のオブジェクトから形成される構造体であり、アイコン表現とするべきキーワードとは直接関連しないものであることを考慮すれば理解されるはずのものである。」と主張するが、本願発明では、「各キーワードは、各々の前記アイコン表現に対応し」として、キーワードとアイコン表現の対応付けを規定するものの、キーワードとアイコン表現と対応付けることは、アイコン表現にキーワードを表示することを意味するものではないから、「アイコン表現に表示されるのはリソース・ファイル内に記述されたキーワードでしかあり得ない」といった主張は根拠が無く、採用できない。
　さらに、本願明細書の実施例において、「アイコン表現」という用語は「ＧＵＩ６０には、ツール・バー６４が含まれ、ツール・バー６４には、「ＯＰＥＮ　ＮＥＷ　ＦＩＬＥ（新規ファイルを開く）」、「ＣＬＯＳＥ　ＦＩＬＥ（ファイルを閉じる）」などの一般的な機能のアイコン表現と、開発者がリソース・ファイルに含めることを所望する可能性があるリソース・データの型に対応するリソース・ファイル・キーワード要素のアイコン表現が含まれる。」（【００３０】段落）の箇所に記載されるのみであるが、この記載における「アイコン表現」は、「キーワードを介して、リソース・ファイル内の情報をアイコン化して表示」するものでもなく、リソース・ファイルに記述されているキーワードが表示されたものでもない。よって、請求人の上記主張は本願明細書の実施例とも対応しないものである。
　
５．むすび
　したがって，本願発明は，引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない。
　よって，結論のとおり審決する。