【事件の表示】
　平成　４年特許願第２１６４００号「情報処理方法および情報処理装置」拒絶査定に対する審判事件［平成　６年　２月１８日出願公開、特開平　６−　４４０６１］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明　
　本願は、平成４年７月２２日の出願であって、その請求項１に係る発明は、平成１４年７月１５日付で補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載されたとおりの次のもの（以下、本願発明という。）である。
　
「【請求項１】　
　プログラム内の描画命令および前記描画命令に対応するパラメータに基づいて複数の図形を画像表示する処理を行う情報処理装置が行う情報処理方法であって、　
　前記画像表示された前記複数の図形のうち第１の図形を画面上で行われた操作に応じて指定する指定指示情報を受ける第１のステップと、　
　前記指定指示情報によって指定された前記第１の図形の種類の変更を画面上で行われた操作に応じて指示する第１の変更指示情報を受ける第２のステップと、　
　前記指定指示情報によって指定された前記第１の図形の変更および移動の少なくとも一方を画面上で行われた操作に応じて指示する第２の変更指示情報を受ける第３のステップと、　
　前記指定指示情報によって指定された前記第１の図形を複写して第２の図形を表示することを指示する第３の変更指示情報を受ける第４のステップと、　
　前記第２の変更指示情報に基づき、前記指定指示情報によって指定された前記第１の図形の変形および移動の少なくとも一方の処理を行う第５のステップと、　
　前記第３の変更指示情報に基づいて、前記指定指示情報によって指定された前記第１の図形を複写して前記第２の図形を表示する処理を行う第６のステップと、　
　前記プログラム内のパラメータの内容を、前記第２の変更指示情報に基づいて変更する第７のステップと、　
　前記プログラム内の前記描画命令を前記第１の変更指示情報に対応する種類の図形を画像表示する描画命令に変更する第８のステップと、　
　前記第３の変更指示情報に基づいて、前記第２の図形を表示するための描画命令を前記プログラム内に追加する第９のステップと　
　を有する情報処理方法。」　
　
２．刊行物　
　これに対して、原査定の拒絶の理由に引用された刊行物である　
　中村正弘著、「続々登場するウインドウ画面の対話式設計ツール」、日経コンピュータ　第２１７号、日経ＢＰ社、１９９０年１月１５日　発行、ｐ．１０９〜１１５（以下、引用刊行物という。）　
には、以下のことが記載されている。　
　
（Ａ）「ウインドウ，アイコン，プルダウン・メニューなどを駆使した，操作しやすく見た目も美しいユーザー・インタフェース。これをパソコンやワークステーションの画面上で，マウスを利用してビジュアルに作成する「ユーザー・インタフェース構築ツール」が続々と登場してきた。」（１０９頁左欄１行〜８行）　
　
（Ｂ）「画面上の道具箱からボタンやテキスト入力フィールドなどの部品をマウスでつまみ出し，ウインドウの上に置いて位置と大きさを調整。見出し文字を書き込めば，ウインドウ・アプリケーションの画面ができあがる。」（１０９頁左欄１９行〜中欄４行）　
　
（Ｃ）「主要機能の第１は，ウインドウ・アプリケーションの画面デザインをマウスを使い，ビジュアルに行えること。ウインドウ上のボタンの配置や大きさのバランスを開発者が目で確かめながら作っていける。　
　第２は，そうして決めた画面表示仕様をもとにユーザー・インタフェースの定義の記述文（ソース・コード），あるいは実行時に使用できる形式のコード（オブジェクト・コード）を自動生成すること。製品によっては，アプリケーション・プログラム本体のプロトタイプ（ソース・コード）を生成する機能を備えるものもある。」（１１０頁右欄１０行〜１１１頁左欄１１行）　
　
（Ｄ）「マウスを使い画面上での部品の位置と大きさを決めたら，・・・」（・・・は引用箇所の省略を意味し、以下、同様とする。）（１１３頁中欄７行〜８行）　
　
（Ｅ）「ひととおり画面の設計ができあがったユーザー・インタフェースはシステムに登録（Ｓａｖｅ）する。このときインタフェース・ビルダーは次のものを自動的に生成する。・・・オブジェクト指向プログラミング言語のＯｂｊｅｃｔｉｖｅ−Ｃで記述したプログラム（ソース・ファイル），・・・」（右欄１１４頁１行〜９行）　
　
　上記（Ａ）〜（Ｅ）及び図面を勘案すると、引用刊行物には、　
　
　パソコンやワークステーションにおいて、　
　画面上でマウスを使って開発者が目で確かめながら、　
　部品をつまみ出し、　
　位置を調整し、　
　大きさを調整し、　
　プログラムを自動的に生成する　
　ユーザー・インタフェース構築方法（以下、刊行物発明という。）　
　
が記載されているものと認められる。　
　
３．対比　
　本願発明と刊行物発明を対比する。　
（１）刊行物発明の「部品」は、ボタンやテキスト入力フィールドであって、それぞれの形状により画面上に表示されるものであるから、本願発明の「図形」に対応する。　
　
（２）刊行物発明のプログラムも部品をユーザー・インタフェースとして画面上で表示するものであるから、当該部品を描画するための命令を有していることは明らかであり、当該部品を描画するための命令は、本願発明の「描画命令」に対応し、又、描画命令を有し図形であるところの部品を表示する刊行物発明の「プログラム」は、その点で本願発明の「プログラム」に対応する。　
　
　してみれば、刊行物発明の「パソコンやワークステーション」と本願発明の「情報処理装置」は、プログラム内の描画命令に基づいて図形を画像表示する処理を行うものである点で対応する。　
　
（３）刊行物発明の画面上でマウスを使って開発者が目で確かめながら、部品をつまみ出すことは、本願発明の画像表示された第１の図形を画面上で行われた操作に応じて指定することに対応し、さらに、刊行物発明において、その際にユーザー・インタフェース構築ツールが、第１の図形を指示したことを示す情報を受けることは明らかであるから、刊行物発明の「部品をつまみ出し、」は、本願発明の「前記画像表示された前記複数の図形のうち第１の図形を画面上で行われた操作に応じて指定する指定指示情報を受ける第１のステップ」に対応する。　
　
（４）同様に、刊行物発明の画面上でマウスを使って開発者が目で確かめながら、「位置を調整」すること及び「大きさを調整」することは、図形の移動又は変形を指示する情報を受けて、図形の移動又は変形処理を行うことであることは明らかであるから、本願発明の「前記指定指示情報によって指定された前記第１の図形の変更および移動の少なくとも一方を画面上で行われた操作に応じて指示する第２の変更指示情報を受ける第３のステップ」及び「前記第２の変更指示情報に基づき、前記指定指示情報によって指定された前記第１の図形の変形および移動の少なくとも一方の処理を行う第５のステップ」に対応する。　
　
（５）刊行物発明の「プログラムを自動的に生成する」は、本願発明の「第７のステップ」、「第８のステップ」、「第９のステップ」は、プログラム内に変更指示に基づいて変更後の描画命令を生成するという点では対応する。　
　
　　したがって、本願発明と刊行物発明は、　
　
　プログラム内の描画命令に基づいて複数の図形を画像表示する処理を行う情報処理装置が行う情報処理方法であって、　
　前記画像表示された前記複数の図形のうち第１の図形を画面上で行われた操作に応じて指定する指定指示情報を受ける第１のステップと、　
　前記指定指示情報によって指定された前記第１の図形の変更および移動の少なくとも一方を画面上で行われた操作に応じて指示する第２の変更指示情報を受ける第３のステップと、　
　前記第２の変更指示情報に基づき、前記指定指示情報によって指定された前記第１の図形の変形および移動の少なくとも一方の処理を行う第５のステップと、　
　前記プログラム内に前記変更指示情報に基づいて描画命令を生成するステップと　
　を有する情報処理方法　
　
である点で一致し、次の点で相違する。　
　
［相違点１］　
　本願発明では、描画命令に対応するパラメータという構成を採用しているのに対して、　刊行物発明のものには、その点明記されていない点。　
　
［相違点２］　
　本願発明では、前記指定指示情報によって指定された前記第１の図形の種類の変更を画面上で行われた操作に応じて指示する第１の変更指示情報を受ける第２のステップ、前記指定指示情報によって指定された前記第１の図形を複写して第２の図形を表示することを指示する第３の変更指示情報を受ける第４のステップ及びそれに対応する前記第３の変更指示情報に基づいて、前記指定指示情報によって指定された前記第１の図形を複写して前記第２の図形を表示する処理を行う第６のステップという構成を採用しているのに対して、　
　刊行物発明のものには、その点明記されていない点。　
　
［相違点３］　
　本願発明では、前記プログラム内のパラメータの内容を、前記第２の変更指示情報に基づいて変更する第７のステップ、前記プログラム内の前記描画命令を前記第１の変更指示情報に対応する種類の図形を画像表示する描画命令に変更する第８のステップ、前記第３の変更指示情報に基づいて、前記第２の図形を表示するための描画命令を前記プログラム内に追加する第９のステップという構成を採用しているのに対して、　
　刊行物発明では、プログラムを自動的に生成するとだけされている点。　
　
４．相違点についての判断　
　上記相違点について検討する。　
　
［相違点１について］　
　図形の描画命令が、描画命令に対応するパラメータを有することは、本願出願前周知の技術であり、相違点１は格別の差異ではない。　
　
［相違点２について］　
　例えば、毎日Ｍａｃ研究会著、「マッキントッシュ・ガイドブックＩＩ」、１９８８年８月１０日、（株）毎日コミュニケーションズ　発行の１４７〜１４９頁、１７２〜１７４頁に、図形を指定し、指定した図形のタイプを変更すること、例えば当該タイプを四角形から円に変えることで、四角形だった図形が円に変わることが記載されていることからも明らかなように、指定された図形の種類の変更を指示し、当該指示に基づき図形の変更処理を行うことは、本願出願前周知の技術である。　
　
　又、例えば、「ＵＸ　ソフトウェア　ゆず利用の手引　初版」、日本電気（株）、１９９１年１０月３１日　発行の１−４頁、３−３頁に、図形をコピーすることが記載されていることからも明らかなように、指定された図形を複写する指示を受け、当該複写処理を行うことは、本願出願前周知の技術である。　
　
　さらに、例えば特開昭６１−１９４５７７号公報、特開平２−２７７１２７号公報に記載されているように、図形の指示、複写などの指示を、刊行物発明と同様に画面上でマウスを使って開発者が目で確かめながら行うことも本願出願前周知の技術である。　
　
　してみれば、刊行物発明において、上記周知の技術を参酌して、前記指定指示情報によって指定された前記第１の図形の種類の変更を画面上で行われた操作に応じて指示する第１の変更指示情報を受ける第２のステップ、前記指定指示情報によって指定された前記第１の図形を複写して第２の図形を表示することを指示する第３の変更指示情報を受ける第４のステップ及びそれに対応する前記第３の変更指示情報に基づいて、前記指定指示情報によって指定された前記第１の図形を複写して前記第２の図形を表示する処理を行う第６のステップという構成を採用するようにすることは、当業者が容易になし得るものである。　
　
［相違点３について］　
　刊行物発明においても１度作成したプログラムに修正を施すことは当然考えられる。　
　そして、プログラムの修正を行う場合に、修正個所のみを変更することは本願出願前周知の技術である。　
　
　してみれば、刊行物発明において、修正個所のみを変更するようにして、前記プログラム内のパラメータの内容を、前記第２の変更指示情報に基づいて変更する第７のステップ、前記プログラム内の前記描画命令を前記第１の変更指示情報に対応する種類の図形を画像表示する描画命令に変更する第８のステップ、前記第３の変更指示情報に基づいて、前記第２の図形を表示するための描画命令を前記プログラム内に追加する第９のステップという構成を採用するようにすることは、当業者が容易になし得るものである。　
　
［審判請求書における請求人の主張について］　
　平成１４年７月１５日付で補正された審判請求書において、請求人は、　
「１．３．２　引用文献２：　
　当該引用文献２には、Ｐ１１３，Ｐ１１４に記載されているように、画面部品を組み合わせて画面設計を行い、そのコードを生成する技術が開示されています。当該技術では、ユーザ機能は、そのコードの一部にコールバック・ルーチンとして組み込むかたちで行われます。　
　すなわち、当該引用文献２のＰ１１４の下から１２行目〜１５行目に記載されているように、当該技術は、「プログラム（コード）の自動生成を狙うようなものではなく、プログラムを書く際の手掛かりを与える程度のもの」であります。　
　当該引用文献２の発明も、上述した引用文献１の発明と同様に、ユーザによるコーディングを必要とします。　
　これにより、上述した本願の請求項１の発明の効果は得られません。　
　また、当該引用文献２には、上述した項目「１．２」で記載した本願の請求項１の発明の構成を示唆する記述はありません。」　
と主張している。　
　
　しかしながら、上記引用文献２であるところの引用刊行物の１１４頁には、　
「アプリケーション・プログラムの本体となる（２）（使用可能な文字コードの制限上丸付数字をこのように表す。）のソース・コードは未完成品である。アプリケーションの開発者が，Ｏｂｊｅｃｔｉｖｅ−Ｃ言語を使い必要な処理内容を書き込んで完成させる必要がある。・・・一方、既成の動作オブジェクトを選んだところは，その処理内容がソース・コードとして展開される。必要なら手を加えてもいい。このＯｂｊｅｃｔｉｖｅ−Ｃのソース・コードを生成する機能は，プログラムの自動生成を狙うようなものではなく，プログラムを書く際の手掛かりを与える程度のものだ。」　
と記載されているのであって、上記「このＯｂｊｅｃｔｉｖｅ−Ｃのソース・コードを生成する機能は，プログラムの自動生成を狙うようなものではなく，プログラムを書く際の手掛かりを与える程度のもの」との記載は、「既成の動作オブジェクトを選んだところは，その処理内容がソース・コードとして展開される」ので開発者が手を加える必要なく、逆に既成の動作オブジェクトでないオブジェクトについては、未完成であってアプリケーションの開発者が，Ｏｂｊｅｃｔｉｖｅ−Ｃ言語を使い必要な処理内容を書き込んで完成させる必要があることを言っているのであって、本願発明においてもＧＵＩにおける部品であるところの図形の編集をしただけでは、既成の動作オブジェクトでないオブジェクトについては当該図形の動作について「アプリケーションの開発者が，Ｏｂｊｅｃｔｉｖｅ−Ｃ言語を使い必要な処理内容を書き込んで完成させる必要がある」ことは変わりがない。　
　
　又、上記２．（Ｅ）の記載、及び、Ｂ．Ｆ．ウェブスター　著、竹内清隆　外３名　訳、「Ｔｈｅ　ＮｅＸＴTM　ＢＯＯＫ」、（株）トッパン、１９９０年６月５日　発行の１１９頁、１２１頁、２６５〜２６６頁、２９１頁の、Ｃプログラムの本体が生成される旨の記載から、刊行物発明においても、少なくともオブジェクト指向プログラミング言語のＯｂｊｅｃｔｉｖｅ−Ｃで記述したプログラムが自動的に生成されることは明らかであり、一方、本願請求項１には、「プログラム」が描画命令を有するものであるという以上の記載はないから、刊行物発明の「プログラム」に対応するものであると言える。　
　
５．むすび　
　以上のとおり、本願発明は、引用刊行物に記載された発明及び周知の技術に基いて、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。　
　
　よって、結論のとおり審決する。