【事件の表示】
　特願２０１２−１２８１７２「第４世代プログラミングツールを用いて生成されるアプリケーションの属性の拡張」拒絶査定不服審判事件〔平成２４年１１月　１日出願公開，特開２０１２−２１２４４９，請求項の数（２）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
　
第１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，２０００年５月２５日（パリ条約による優先権主張外国庁受理１９９９年５月２５日（以下，「優先日」という。），米国）を国際出願日として出願した特願２０００−６２０４６７号の一部を，平成２０年１月２１日に新たな特許出願とした特願２００８−１０６２４号の一部を，さらに平成２４年６月５日に新たな特許出願としたものであって，その手続の経緯は以下のとおりである。
　
　　平成２５年　６月２６日付け　：拒絶理由の通知
　　平成２５年１０月　４日　　　：意見書，手続補正書の提出
　　平成２６年　２月２０日付け　：拒絶査定　
　　平成２６年　４月２３日　　　：審判請求書，手続補正書の提出
　　平成２６年　８月２８日　　　：前置報告
　　平成２７年　７月２３日付け　：拒絶理由（最後）の通知（当審）
　　平成２７年　８月　７日　　　：意見書，手続補正書の提出
　
　
第２　本願発明
　
　本願の請求項に係る発明は，上記平成２７年８月７日付け手続補正により補正された特許請求の範囲の請求項１，２に記載されたとおりのものであると認められるところ，その請求項１に係る発明（以下，「本願発明」という。）は，以下のとおりのものである。　
　
「　【請求項１】
　アプリケーション設計者が，４ＧＬプログラミングツールによって提示されるユーザインターフェイスオブジェクトおよび制御との対話により，標準インプリメンテーションが４ＧＬプログラミングツールによって与えられるコンポーネントタイプの組に属するコンポーネントを含むアプリケーションを生成することを可能にする４ＧＬプログラミングツールを含むシステムにおいて使用される方法であって，前記アプリケーションのコンポーネントのインプリメンテーション・クラスは，デフォルトのインプリメンテーション・クラス，または，前記アプリケーションの開発者によって指定される，前記デフォルトのインプリメンテーション・クラスと異なるインプリメンテーション・クラスを含み，
　前記方法は，
　４ＧＬプログラミングツールが，設定するインプリメンテーション・クラスが前記アプリケーションの開発者によって指定されるインプリメンテーション・クラスである場合に，前記４ＧＬプログラミングツールを用いて設計されるアプリケーションのコンポーネントのためのユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えるステップを含み，
　前記コンポーネントは，コンポーネントタイプの前記組に属するコンポーネントタイプのインスタンスであり，
　前記ユーザ指定のカスタムインプリメンテーションは４ＧＬプログラミングツールによって与えられる前記標準インプリメンテーションの１つではなく，さらに，
　４ＧＬプログラミングツールが，実行されると前記アプリケーションを走らせるアプリケーションコードを生成するステップを含み，前記アプリケーションコードは当該アプリケーションの開発者によって指定されたインプリメンテーション・クラスを特定するデータを含み，
　前記アプリケーションコードのある部分は，前記コンポーネントが前記ユーザ指定のカスタムインプリメンテーションを用いて実現されるべきであることを示し，
　コンポーネントタイプの組に対して４ＧＬプログラミングツールによって与えられる標準インプリメンテーションは各々共通インターフェイスをサポートし，
　ユーザ指定のカスタムインプリメンテーションは前記共通インターフェイスをサポートし，
　アプリケーションの実行中，４ＧＬプログラミングツールによって与えられる標準インプリメンテーションを用いて実現されるいずれかのコンポーネントおよび前記コンポーネントは，前記共通インターフェイスを介してなされる呼出によりインスタンスが生成される，
方法。」　
　
　
第３　原査定の理由について
　
１　原査定の理由の概要
　
　この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
＜引用文献＞
１．青木  郁代，ＰｏｗｅｒＢｕｉｌｄｅｒ／Ｐｏｗｅｒ＋＋連携の手順と効用，ネットワークコンピューティング，日本，株式会社リックテレコム，１９９８年　２月　１日，第10巻,第2号，p.104-109
２．木村  忠文，新技術を斬る第８回，日経オープンシステム，日本，日経ＢＰ社，１９９７年１２月１５日，第57号，p.274-281
　
＜周知例＞
Ａ．特開平１０−１０５３９２号公報 
Ｂ．特開平７−１８２１７２号公報 
Ｃ．特開平９−２３１０７７号公報 
　
　本願された請求項１に記載の発明は，引用文献１，２及び周知技術から，当業者が容易に発明をすることができたものである。 
　
　
２　原査定の理由の判断
　
（１）　引用例
　
＜引用例１に記載されている技術的事項および引用発明＞
　
ア　本願の優先日前に頒布され，上記平成２５年６月２６日付け拒絶理由通知において引用された，
青木  郁代，ＰｏｗｅｒＢｕｉｌｄｅｒ／Ｐｏｗｅｒ＋＋連携の手順と効用，ネットワークコンピューティング，日本，株式会社リックテレコム，１９９８年２月１日，第10巻,第2号，p.104-109（以下，「引用例１」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「
ビジュアルな開発環境と高機能４ＧＬを持ち，ＲＡＤ（Ｒａｐｉｄ Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｖｅｌｏｐｍｅｎｔ）を実現するＲＡＤ ４ＧＬツール，いわゆるビジュアル開発ツールがアプリケーション・システム構築の中心となり，一般的なものになって久しい。
　
近年はＲＡＤ ４ＧＬツール以外にも，様々な方向性をもった開発ツールがシステム構築の手段として提供されるようになった。
　
なかでも注目したいのは，Ｃ＋＋言語などの３ＧＬをべースとしつつ，ビジュアルな開発環境や高桟能ライブラリを併せ持つツールだ。ここでは「ＲＡＤ３ＧＬ」ツールと呼ぶ。
　
この２種類のツールを組み合わせれば，開発の自由度と柔軟性を高められる。
　
Ｂ　「パワーソフトのＰｏｗｅｒＢｕｉｌｄｅｒは，ＲＡＤ　４ＧＬツールの代表的製品といっていいだろう。
　
ＲＡＤ　４ＧＬツールの一般的な特長には(１)ＧＵＩ開発工数の大幅な削減，(２)ライブラリやコンポーネントによるコーディング・レスの実現，(３)習得が容易な言語の実装−−などがある
　
Ｃ　「
これらＲＡＤ　４ＧＬツールの弱点を補うのが，Ｃ＋＋言語やPascalなどの３ＧＬである。特に，Ｃ＋＋には，(１)ＥＸＥ形式だけでなくＤＬＬなども作成できる柔軟性，(２)標準規格（ＡＮＳＩＣ）による互換性などのメリットがあり，ＲＡＤ４ＧＬツールの補助言語として多く採用されている。
　
Ｄ　「近年，「ＲＡＤ ３ＧＬツール」とでもいうべき製品カテゴリが出現した。
　ＲＡＤ ４ＧＬツールと同等なビジュアル開発環境を持ちつつ，３ＧＬの柔軟性を兼ね備えたツールだ。パワーソフトのＰｏｗｅｒ＋＋はその代表的な製品である。
　
ＲＡＤ ３ＧＬツールは，３ＧＬが持つ前述のメリットに加え，（３）ＲＡＤ４ＧＬツールと共有できるコンポーネントとライブラリが活用可能，（４）３ＧＬを習得できる――などのメリットを備えていた。
　アプリ開発が多様化し，複雑化している咋今では，オブジェクト指向技術を採用し，コンポーネント化を奨め，再利用する方法が選ばれている。一旦作戊したアプリケーションに対して，柔軟な拡張や変更が可能な手段も求められている。
　ＲＡＤ３ＧＬツールは，ＲＡＤ４ＧＬツールに比べて制限の少ない開発環境を提供する。習得が困難，記述量が多いといった点で３ＧＬの採用を躊躇していた開発者にとって，これは朗報といえる。
　
もちろんＲＡＤ３ＧＬツールは，それのみでもシステム構築を完遂できる能力を持っている。しかし，ＲＡＤ４ＧＬツールの不足部分をＲＡＤ３ＧＬツールを使って補強する方法が，開発作業に与える利点は大きい。
　
たとえば，ＤＬＬの取り込みなどを，異なる言語での開発であることを意識しないでシームレスに実行できる点などだ。
　
Ｅ　「
●コンポーネント作成
　
ＲＡＤ　４ＧＬツールでは作成できないコンポーネントをＲＡＤ３ＧＬツールで作成，活用する。
　
これはツール連携による最大のメリットといっていいだろう。
　
ＲＡＤ４ＧＬツールの中には，４ＧＬによるコンポーネント作成機能を持つ製品もある。しかし，その機能の枠を超えた仕様や，コンポーネント化によって高速化を図る場合には，３ＧＬによる作成が必要になる。
　
Ｐｏｗｅｒ＋＋では，ＰｏｗｅｒＢｕｉｌｄｅｒで呼び込むＤＬＬを作成できる。
　・・・（中略）・・・　
　
次に，このＤＬＬをＰｏｗｅｒＢｕｉｌｄｅｒから利用する。
　
それには，ＰｏｗｅｒＢｕｉｌｄｅｒ上のグローバル外部関数，もしくはローカル外部関数に使用するＤＬＬと，ＤＬＬ内にある関数を定義する。
　グローバル外部関数の宣言は（画面１０）のスクリプトで記述する。
　外部関数として宣言すれば，ＰｏｗｅｒＢｕｉｌｄｅｒから普通の関数として呼び出せる。たとえば，コマンドボタンを追加し，そのクリックイベントに以下のように記述すればよい。
　Long Kingaku 
　Kingaku =Tax(100) 
　Messagebox(金額, String(Kingaku)) 
　
以上を記述したらＰｏｗｅｒ＋＋で作成したＤＬＬを，パスが通っているディレクトリ，もしくはＰｏｗｅｒＢｕｉｌｄｅｒで作成したアプリケーションのＥＸＥファイルがあるディレクトリに移動してアプリケーションを実行する。
　
イ　以上，Ａ乃至Ｅの記載事項（特に下線部分を参照）から，引用例１には次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「　４ＧＬツールであるＰｏｗｅｒＢｕｉｌｄｅｒでアプリケーションを作成し実行させる方法であって，
　前記ＰｏｗｅｒＢｕｉｌｄｅｒによるアプリケーションの作成は，ライブラリやコンポーネントを用いたコーディング・レスな実装を含み，
　Ｃ＋＋言語やPascalなどの３ＧＬによる３ＧＬツールは，それのみでもシステム構築を完遂できるとともに，アプリケーションの開発において前記４ＧＬツールの不足部分を補強するものであって，
　前記３ＧＬツールにより作成したＤＬＬの前記４ＧＬツールによる取り込みを，異なる言語での開発であることを意識しないでシームレスに実行させることができるとともに，前記４ＧＬツールでは作成できないコンポーネントを前記３ＧＬツールにより作成でき，それを前記４ＧＬツールで活用することで，ツール連携できるものであり，
　それにより，前記３ＧＬツールであるＰｏｗｅｒ＋＋において，前記４ＧＬツールであるＰｏｗｅｒＢｕｉｌｄｅｒで呼び込むＤＬＬを作成し，ＰｏｗｅｒＢｕｉｌｄｅｒで活用する際には，
　作成されたＤＬＬをＰｏｗｅｒＢｕｉｌｄｅｒから利用するために，グローバル外部関数の宣言をスクリプトで記述して，ＰｏｗｅｒＢｕｉｌｄｅｒ上の外部関数に使用するＤＬＬ，及び，ＤＬＬ内にある関数を定義し，
　作成したＤＬＬを，パスが通っているディレクトリ，もしくはＰｏｗｅｒＢｕｉｌｄｅｒで作成したアプリケーションのＥＸＥファイルがあるディレクトリに移動した上で，ＰｏｗｅｒＢｕｉｌｄｅｒで作成したアプリケーションを実行させる，方法。」　
　
　
（２）　対比
　
ア　本願発明と引用発明とを対比する。
　
（ア）引用発明の「４ＧＬツールであるＰｏｗｅｒＢｕｉｌｄｅｒ」，「ＤＬＬ」は，本願発明の「４ＧＬプログラミングツール」，「コンポーネント」にそれぞれ相当することは明らかである。
　そして，引用発明の「アプリケーション」の作成は，「ＤＬＬ」等のコンポーネントを用いた「実装」により作成されることを含み，その際当該「ＤＬＬ」として，「４ＧＬツールであるＰｏｗｅｒＢｕｉｌｄｅｒ」が元々有する標準実装の「ライブラリ」に対応する「ＤＬＬ」を用いることから，引用発明の「ライブラリ」は本願発明の「アプリケーション設計者が，４ＧＬプログラミングツールによって提示されるユーザインターフェイスオブジェクトおよび制御との対話により，標準インプリメンテーションが４ＧＬプログラミングツールによって与えられるコンポーネントタイプの組に属するコンポーネント」に対応するものである。
　そうすると，引用発明の「４ＧＬツールであるＰｏｗｅｒＢｕｉｌｄｅｒ」が有する「ライブラリ」を含む「アプリケーション」について，「４ＧＬツールであるＰｏｗｅｒＢｕｉｌｄｅｒでアプリケーションを作成し実行させる方法」は，本願発明の「アプリケーション設計者が，４ＧＬプログラミングツールによって提示されるユーザインターフェイスオブジェクトおよび制御との対話により，標準インプリメンテーションが４ＧＬプログラミングツールによって与えられるコンポーネントタイプの組に属するコンポーネントを含むアプリケーションを生成することを可能にする４ＧＬプログラミングツールを含むシステムにおいて使用される方法」に相当すると言える。
　
（イ）引用発明では，「３ＧＬツールにより作成したＤＬＬの前記４ＧＬツールによる取り込みを，異なる言語での開発であることを意識しないでシームレスに実行させることができるとともに，前記４ＧＬツールでは作成できないコンポーネントを前記３ＧＬツールにより作成でき，それを前記４ＧＬツールで活用することで，ツール連携できるものであ」るところ，「４ＧＬツール」が「４ＧＬツールでは作成できないコンポーネント」を含む「３ＧＬツールにより作成したＤＬＬ」に関するデータを取り込むと解され，ここでの「３ＧＬツールにより作成したＤＬＬ」はユーザ指定のカスタムインプリメンテーションによるものとみることができる。
　そして，引用発明の「３ＧＬツールにより作成したＤＬＬ」は，ユーザ指定のカスタムインプリメンテーションによるものであることから，「４ＧＬツールであるＰｏｗｅｒＢｕｉｌｄｅｒ」が元々有する標準実装の「ライブラリ」に対応する「ＤＬＬ」の１つではないと言える。
　そうすると，引用発明の「３ＧＬツールにより作成したＤＬＬの前記４ＧＬツールによる取り込みを，異なる言語での開発であることを意識しないでシームレスに実行させることができるとともに，前記４ＧＬツールでは作成できないコンポーネントを前記３ＧＬツールにより作成でき，それを前記４ＧＬツールで活用することで，ツール連携できるものであ」ることと，
　本願発明の「４ＧＬプログラミングツールが，設定するインプリメンテーション・クラスが前記アプリケーションの開発者によって指定されるインプリメンテーション・クラスである場合に，前記４ＧＬプログラミングツールを用いて設計されるアプリケーションのコンポーネントのためのユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えるステップを含み，前記コンポーネントは，コンポーネントタイプの前記組に属するコンポーネントタイプのインスタンスであり，前記ユーザ指定のカスタムインプリメンテーションは４ＧＬプログラミングツールによって与えられる前記標準インプリメンテーションの１つではな」いとは後記する点で相違するものの，
　両者は，“４ＧＬプログラミングツールが，前記４ＧＬプログラミングツールを用いて設計されるアプリケーションのコンポーネントのためのユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えるステップを含み，前記コンポーネントは，コンポーネントタイプの前記組に属するコンポーネントタイプのインスタンスであり，前記ユーザ指定のカスタムインプリメンテーションは４ＧＬプログラミングツールによって与えられる前記標準インプリメンテーションの１つではな”い点で共通すると言える。
　
（ウ）引用発明の「アプリケーション」は，「４ＧＬツール」が「コーディング・レスな実装」により作成するものであり，「作成したＤＬＬを，パスが通っているディレクトリ，もしくはＰｏｗｅｒＢｕｉｌｄｅｒで作成したアプリケーションのＥＸＥファイルがあるディレクトリに移動した上で，ＰｏｗｅｒＢｕｉｌｄｅｒで作成したアプリケーションを実行させる」ところ，作成された「ＤＬＬ」が「アプリケーションのＥＸＥファイル」とリンクされ，「アプリケーション」が実行されると解されることから，作成された「アプリケーション」がコードを含むこと，当該「アプリケーション」がユーザ指定のカスタムインプリメンテーションによる「３ＧＬツールにより作成したＤＬＬ」を含む場合には，作成された「アプリケーション」のコードの一部において，「３ＧＬツールにより作成したＤＬＬ」を用いることを示すことは自明であると言える。
　そうすると，引用発明の「作成したＤＬＬを，パスが通っているディレクトリ，もしくはＰｏｗｅｒＢｕｉｌｄｅｒで作成したアプリケーションのＥＸＥファイルがあるディレクトリに移動した上で，ＰｏｗｅｒＢｕｉｌｄｅｒで作成したアプリケーションを実行させる」ことと，
　本願発明の「４ＧＬプログラミングツールが，実行されると前記アプリケーションを走らせるアプリケーションコードを生成するステップを含み，前記アプリケーションコードは当該アプリケーションの開発者によって指定されたインプリメンテーション・クラスを特定するデータを含み，前記アプリケーションコードのある部分は，前記コンポーネントが前記ユーザ指定のカスタムインプリメンテーションを用いて実現されるべきであることを示」すこととは後記する点で相違するものの，
　両者は，“４ＧＬプログラミングツールが，実行されると前記アプリケーションを走らせるアプリケーションコードを生成するステップを含み，前記アプリケーションコードのある部分は，前記コンポーネントが前記ユーザ指定のカスタムインプリメンテーションを用いて実現されるべきであることを示す”点で共通すると言える。
　
イ　以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
＜一致点＞ 
　
「　アプリケーション設計者が，４ＧＬプログラミングツールによって提示されるユーザインターフェイスオブジェクトおよび制御との対話により，標準インプリメンテーションが４ＧＬプログラミングツールによって与えられるコンポーネントタイプの組に属するコンポーネントを含むアプリケーションを生成することを可能にする４ＧＬプログラミングツールによって設計されるアプリケーションを実行するための方法であって，
　前記方法は，
　４ＧＬプログラミングツールが，前記４ＧＬプログラミングツールを用いて設計されるアプリケーションのコンポーネントのためのユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えるステップを含み，
　前記コンポーネントは，コンポーネントタイプの前記組に属するコンポーネントタイプのインスタンスであり，
　前記ユーザ指定のカスタムインプリメンテーションは４ＧＬプログラミングツールによって与えられる前記標準インプリメンテーションの１つではなく，さらに，
　４ＧＬプログラミングツールが，実行されると前記アプリケーションを走らせるアプリケーションコードを生成するステップを含み，
　前記アプリケーションコードのある部分は，前記コンポーネントが前記ユーザ指定のカスタムインプリメンテーションを用いて実現されるべきであることを示す，
方法。」
　
＜相違点１＞
　本願発明は，「アプリケーションのコンポーネントのインプリメンテーション・クラス」を有し，「アプリケーションのコンポーネントのインプリメンテーション・クラスは，デフォルトのインプリメンテーション・クラス，または，前記アプリケーションの開発者によって指定される，前記デフォルトのインプリメンテーション・クラスと異なるインプリメンテーション・クラスを含」んでいるのに対して，引用発明では，「アプリケーションのコンポーネントのインプリメンテーション・クラス」について言及がない点。
　
＜相違点２＞
　本願発明では，「設定するインプリメンテーション・クラスが前記アプリケーションの開発者によって指定されるインプリメンテーション・クラスである場合に」，「ユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与える」のに対して，引用発明では，ユーザ指定のカスタムインプリメンテーションによる「３ＧＬツールにより作成したＤＬＬ」を示すデータを何を契機に受け取るか明らかでない点。
　
＜相違点３＞
　「アプリケーションコード」が含むデータに関し，本願発明では，「アプリケーションコードは当該アプリケーションの開発者によって指定されたインプリメンテーション・クラスを特定するデータを含」んでいるのに対して，引用発明では，「アプリケーションコード」が「インプリメンテーション・クラスを特定するデータ」を含むことについて特定されていない点。
　
＜相違点４＞
　本願発明では，
「コンポーネントタイプの組に対して４ＧＬプログラミングツールによって与えられる標準インプリメンテーションは各々共通インターフェイスをサポートし，
　ユーザ指定のカスタムインプリメンテーションは前記共通インターフェイスをサポートし，
　アプリケーションの実行中，４ＧＬプログラミングツールによって与えられる標準インプリメンテーションを用いて実現されるいずれかのコンポーネントおよび前記コンポーネントは，前記共通インターフェイスを介してなされる呼出によりインスタンスが生成される」のに対して，
　引用発明では，「標準インプリメンテーション」（４ＧＬツール）と「カスタムインプリメンテーション」（３ＧＬツール）の「共通インターフェイス」については，言及されていない点。
　
　
（３）　判断
　
　上記相違点１乃至４について検討する。
　
ア　相違点１及び２について
　
　引用発明では，ユーザ指定のカスタムインプリメンテーションによる「３ＧＬツールにより作成したＤＬＬの前記４ＧＬツールによる取り込み」を実行することができるものの，「異なる言語での開発であることを意識しないでシームレスに実行させることができる」ことを特定しているから，ユーザが，カスタムインプリメンテーションによる「３ＧＬツールにより作成したＤＬＬ」と，標準インプリメンテーションによる「４ＧＬツール」により作成した「コンポーネント」を意識し，指定可能とすることの動機付けを見い出すことはできない。
　また，「４ＧＬツール」と「３ＧＬツール」の利用を「インプリメンテーション・クラス」の指定により制御することも，本願優先日前に当該技術分野の周知技術であったとは言えない。
　そうすると，引用発明において，アプリケーションのコンポーネントのインプリメンテーション・クラスを指定可能とし，アプリケーションのコンポーネントのインプリメンテーション・クラスを，デフォルトのインプリメンテーション・クラス，または，アプリケーションの開発者によって指定される，前記デフォルトのインプリメンテーション・クラスと異なるインプリメンテーション・クラスを含むようにすること，また，設定するインプリメンテーション・クラスがアプリケーションの開発者によって指定されるインプリメンテーション・クラスである場合に，ユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えること，すなわち，上記相違点１及び２に係る構成とすることは，当業者が適宜なし得たものであるとすることはできない。
　
イ　相違点３について
　
　引用発明では，「３ＧＬツールであるＰｏｗｅｒ＋＋において，前記４ＧＬツールであるＰｏｗｅｒＢｕｉｌｄｅｒで呼び込むＤＬＬを作成し」，作成した「ＤＬＬ」が「アプリケーションのＥＸＥファイル」とリンクされ，「アプリケーション」が実行されると解されることから，作成された「アプリケーション」がユーザ指定のカスタムインプリメンテーションによる「３ＧＬツールにより作成したＤＬＬ」を含む場合には，作成された「アプリケーション」のコードの一部において，「３ＧＬツールにより作成したＤＬＬ」を用いることを示すことは自明であると言える。
　しかしながら，上記アでの検討の通り，ユーザが，カスタムインプリメンテーションによる「３ＧＬツールにより作成したＤＬＬ」と，標準インプリメンテーションによる「４ＧＬツール」により作成した「コンポーネント」を意識し，指定可能とすることの動機付けを見い出すことはできず，また，「４ＧＬツール」と「３ＧＬツール」の利用を「インプリメンテーション・クラス」の指定により制御することも，本願優先日前に当該技術分野の周知技術であったとは言えない。
　そうすると，引用発明において，４ＧＬツールで作成されたアプリケーションコードがインプリメンテーション・クラスを特定するデータを含むようにすること，すなわち，上記相違点３に係る構成とすることは，当業者が適宜なし得たものであるとすることはできない。
　
ウ　相違点４について
　
　引用発明では，「３ＧＬツールにより作成したＤＬＬの前記４ＧＬツールによる取り込みを，異なる言語での開発であることを意識しないでシームレスに実行させることができるとともに，前記４ＧＬツールでは作成できないコンポーネントを前記３ＧＬツールにより作成でき，それを前記４ＧＬツールで活用することで，ツール連携できるものであ」るところ，「４ＧＬツール」，「３ＧＬツール」を連携して「コンポーネント」を作成するための共通インターフェイスについては特に言及されていない。
　また，本願の優先日前に公知であり，平成２６年２月２０日付け拒絶査定において引用された，特開平１０−１０５３９２号公報，特開平７−１８２１７２号公報，特開平９−２３１０７７号公報のいずれの文献にも，「コンポーネントタイプの組に対して４ＧＬプログラミングツールによって与えられる標準インプリメンテーションは各々共通インターフェイスをサポートし，ユーザ指定のカスタムインプリメンテーションは前記共通インターフェイスをサポートし，アプリケーションの実行中，４ＧＬプログラミングツールによって与えられる標準インプリメンテーションを用いて実現されるいずれかのコンポーネントおよび前記コンポーネントは，前記共通インターフェイスを介してなされる呼出によりインスタンスが生成される」ことは記載されておらず，このような技術が本願の優先日前に周知技術であったとまでは言えない。
　そうすると，引用発明において，標準インプリメンテーションである４ＧＬツールと，カスタムインプリメンテーションである３ＧＬツールとの共通インターフェイスをサポートし，アプリケーションの実行中，４ＧＬツールによって与えられる標準インプリメンテーションを用いて実現されるいずれかのコンポーネントおよび前記コンポーネントは，前記共通インターフェイスを介してなされる呼出によりインスタンスが生成されること，すなわち，上記相違点４に係る構成とすることは，当業者が適宜なし得たものであるとすることはできない。
　
エ　小括
　
　上記で検討したごとく，本願発明は，当業者が引用発明に基づいて容易に発明をすることができたものとすることができないものである。
　
　
（４）　請求項２に係る発明について
　
　請求項２に係る発明は，本願発明をコンピュータによって読み出し可能な記録媒体の発明として記載したものであるから，上記（１）乃至（３）で示した理由により当業者が容易に発明をすることができたものとすることができないものである。
　
　
（５）　まとめ
　
　以上のとおりであるから，本願の請求項１，２に係る発明は，引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものとすることができないものである。
　よって，原査定の理由によっては，本願を拒絶することはできない。
　
　
第４　当審拒絶理由について
　
１　当審拒絶理由の概要
　
　この出願の下記の請求項に係る発明は，同日出願された下記の出願に係る発明と同一と認められ，かつ，下記の出願に係る発明は特許されており協議を行うことができないから，特許法第３９条第２項の規定により特許を受けることができない。 
　　　　　　　　　　　　　　　　　記　 
　
請求項：　１，３ 
出願１：　特願２００８−１０６２４号（特許第５５２０４４６号） 
　
 ＜備考＞
　
（１）本願の補正後の請求項１に記載された発明特定事項と，上記出願１（特願２００８−１０６２４号）の請求項１（平成２６年２月１２日付け補正書により補正され，その後に特許された時の特許請求の範囲）に記載された発明特定事項は，明らかに同一のものと認められる。 
　
（２）本願の補正後の請求項３に記載された発明特定事項と，上記出願１（特願２００８−１０６２４号）の請求項５（平成２６年２月１２日付け補正書により補正され，その後に特許された時の特許請求の範囲）に記載された発明特定事項は，明らかに同一のものと認められる。 
　
２　当審拒絶理由の判断
　
　平成２７年８月７日付け手続補正により，平成２６年２月１２日付け手続補正書に記載の特許請求の範囲の請求項１，３は削除された。
　よって，当審拒絶理由は解消した。
　
第５　むすび
　
　以上のとおり，原査定の理由によっては，本願を拒絶することはできない。
また，他に本願を拒絶すべき理由を発見しない。
　
　よって，結論のとおり審決する。