• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06F
審判 査定不服 特39条先願 取り消して特許、登録 G06F
管理番号 1305546
審判番号 不服2014-7518  
総通号数 191 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-11-27 
種別 拒絶査定不服の審決 
審判請求日 2014-04-23 
確定日 2015-09-29 
事件の表示 特願2012-128172「第4世代プログラミングツールを用いて生成されるアプリケーションの属性の拡張」拒絶査定不服審判事件〔平成24年11月 1日出願公開,特開2012-212449,請求項の数(2)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由
第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,2000年5月25日(パリ条約による優先権主張外国庁受理1999年5月25日(以下,「優先日」という。),米国)を国際出願日として出願した特願2000-620467号の一部を,平成20年1月21日に新たな特許出願とした特願2008-10624号の一部を,さらに平成24年6月5日に新たな特許出願としたものであって,その手続の経緯は以下のとおりである。

平成25年 6月26日付け :拒絶理由の通知
平成25年10月 4日 :意見書,手続補正書の提出
平成26年 2月20日付け :拒絶査定
平成26年 4月23日 :審判請求書,手続補正書の提出
平成26年 8月28日 :前置報告
平成27年 7月23日付け :拒絶理由(最後)の通知(当審)
平成27年 8月 7日 :意見書,手続補正書の提出


第2 本願発明

本願の請求項に係る発明は,上記平成27年8月7日付け手続補正により補正された特許請求の範囲の請求項1,2に記載されたとおりのものであると認められるところ,その請求項1に係る発明(以下,「本願発明」という。)は,以下のとおりのものである。

「 【請求項1】
アプリケーション設計者が,4GLプログラミングツールによって提示されるユーザインターフェイスオブジェクトおよび制御との対話により,標準インプリメンテーションが4GLプログラミングツールによって与えられるコンポーネントタイプの組に属するコンポーネントを含むアプリケーションを生成することを可能にする4GLプログラミングツールを含むシステムにおいて使用される方法であって,前記アプリケーションのコンポーネントのインプリメンテーション・クラスは,デフォルトのインプリメンテーション・クラス,または,前記アプリケーションの開発者によって指定される,前記デフォルトのインプリメンテーション・クラスと異なるインプリメンテーション・クラスを含み,
前記方法は,
4GLプログラミングツールが,設定するインプリメンテーション・クラスが前記アプリケーションの開発者によって指定されるインプリメンテーション・クラスである場合に,前記4GLプログラミングツールを用いて設計されるアプリケーションのコンポーネントのためのユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えるステップを含み,
前記コンポーネントは,コンポーネントタイプの前記組に属するコンポーネントタイプのインスタンスであり,
前記ユーザ指定のカスタムインプリメンテーションは4GLプログラミングツールによって与えられる前記標準インプリメンテーションの1つではなく,さらに,
4GLプログラミングツールが,実行されると前記アプリケーションを走らせるアプリケーションコードを生成するステップを含み,前記アプリケーションコードは当該アプリケーションの開発者によって指定されたインプリメンテーション・クラスを特定するデータを含み,
前記アプリケーションコードのある部分は,前記コンポーネントが前記ユーザ指定のカスタムインプリメンテーションを用いて実現されるべきであることを示し,
コンポーネントタイプの組に対して4GLプログラミングツールによって与えられる標準インプリメンテーションは各々共通インターフェイスをサポートし,
ユーザ指定のカスタムインプリメンテーションは前記共通インターフェイスをサポートし,
アプリケーションの実行中,4GLプログラミングツールによって与えられる標準インプリメンテーションを用いて実現されるいずれかのコンポーネントおよび前記コンポーネントは,前記共通インターフェイスを介してなされる呼出によりインスタンスが生成される,
方法。」


第3 原査定の理由について

1 原査定の理由の概要

この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。

＜引用文献＞
1.青木 郁代,PｏｗeｒBｕildeｒ/Pｏｗeｒ++連携の手順と効用,ネットワークコンピューティング,日本,株式会社リックテレコム,1998年 2月 1日,第10巻,第2号,p.104-109
2.木村 忠文,新技術を斬る第8回,日経オープンシステム,日本,日経BP社,1997年12月15日,第57号,p.274-281

＜周知例＞
A.特開平10-105392号公報
B.特開平7-182172号公報
C.特開平9-231077号公報

本願された請求項1に記載の発明は,引用文献1,2及び周知技術から,当業者が容易に発明をすることができたものである。


2 原査定の理由の判断

(1) 引用例

＜引用例1に記載されている技術的事項および引用発明＞

ア 本願の優先日前に頒布され,上記平成25年6月26日付け拒絶理由通知において引用された,
青木 郁代,PｏｗeｒBｕildeｒ/Pｏｗeｒ++連携の手順と効用,ネットワークコンピューティング,日本,株式会社リックテレコム,1998年2月1日,第10巻,第2号,p.104-109(以下,「引用例1」という。)には,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「ビジュアルな開発環境と高機能4GLを持ち,RAD(Raｐid Aｐｐlicaｔiｏn Deｖelｏｐmenｔ)を実現するRAD 4GLツール,いわゆるビジュアル開発ツールがアプリケーション・システム構築の中心となり,一般的なものになって久しい。
近年はRAD 4GLツール以外にも,様々な方向性をもった開発ツールがシステム構築の手段として提供されるようになった。
なかでも注目したいのは,C++言語などの3GLをべースとしつつ,ビジュアルな開発環境や高桟能ライブラリを併せ持つツールだ。ここでは「RAD3GL」ツールと呼ぶ。
この2種類のツールを組み合わせれば,開発の自由度と柔軟性を高められる。代表的なRAD 4GLツールであるパワーソフトの「PｏｗeｒBｕildeｒ」と,同社のRAD 3GLツール「PｏｗeｒSｏfｔ Pｏｗeｒ++(以下Pｏｗeｒ++)」を取り上げ,組み合わせによる開発手法の詳細を追っていく。」(104頁左欄1行?右欄8行)

B 「パワーソフトのPｏｗeｒBｕildeｒは,RAD 4GLツールの代表的製品といっていいだろう。
RAD 4GLツールの一般的な特長には(1)GUI開発工数の大幅な削減,(2)ライブラリやコンポーネントによるコーディング・レスの実現,(3)習得が容易な言語の実装--などがあるが,PｏｗeｒBｕildeｒはそれに加え,次のような特色を持っている。」(104頁右欄11行?18行,注:○数字を(数字)で代用,以下同じ。)

C 「これらRAD 4GLツールの弱点を補うのが,C++言語やPascalなどの3GLである。特に,C++には,(1)EXE形式だけでなくDLLなども作成できる柔軟性,(2)標準規格(ANSIC)による互換性などのメリットがあり,RAD4GLツールの補助言語として多く採用されている。」(105頁左欄14行?20行)

D 「近年,「RAD 3GLツール」とでもいうべき製品カテゴリが出現した。
RAD 4GLツールと同等なビジュアル開発環境を持ちつつ,3GLの柔軟性を兼ね備えたツールだ。パワーソフトのPｏｗeｒ++はその代表的な製品である。
RAD 3GLツールは,3GLが持つ前述のメリットに加え,(3)RAD4GLツールと共有できるコンポーネントとライブラリが活用可能,(4)3GLを習得できる??などのメリットを備えていた。
アプリ開発が多様化し,複雑化している咋今では,オブジェクト指向技術を採用し,コンポーネント化を奨め,再利用する方法が選ばれている。一旦作戊したアプリケーションに対して,柔軟な拡張や変更が可能な手段も求められている。
RAD3GLツールは,RAD4GLツールに比べて制限の少ない開発環境を提供する。習得が困難,記述量が多いといった点で3GLの採用を躊躇していた開発者にとって,これは朗報といえる。
もちろんRAD3GLツールは,それのみでもシステム構築を完遂できる能力を持っている。しかし,RAD4GLツールの不足部分をRAD3GLツールを使って補強する方法が,開発作業に与える利点は大きい。
たとえば,DLLの取り込みなどを,異なる言語での開発であることを意識しないでシームレスに実行できる点などだ。」(105頁左欄23行?右欄13行)

E 「●コンポーネント作成
RAD 4GLツールでは作成できないコンポーネントをRAD3GLツールで作成,活用する。
これはツール連携による最大のメリットといっていいだろう。
RAD4GLツールの中には,4GLによるコンポーネント作成機能を持つ製品もある。しかし,その機能の枠を超えた仕様や,コンポーネント化によって高速化を図る場合には,3GLによる作成が必要になる。
Pｏｗeｒ++では,PｏｗeｒBｕildeｒで呼び込むDLLを作成できる。
・・・(中略)・・・
次に,このDLLをPｏｗeｒBｕildeｒから利用する。
それには,PｏｗeｒBｕildeｒ上のグローバル外部関数,もしくはローカル外部関数に使用するDLLと,DLL内にある関数を定義する。
グローバル外部関数の宣言は(画面10)のスクリプトで記述する。
外部関数として宣言すれば,PｏｗeｒBｕildeｒから普通の関数として呼び出せる。たとえば,コマンドボタンを追加し,そのクリックイベントに以下のように記述すればよい。
Long Kingaku
Kingaku =Tax(100)
Messagebox("金額", String(Kingaku))
以上を記述したらPｏｗeｒ++で作成したDLLを,パスが通っているディレクトリ,もしくはPｏｗeｒBｕildeｒで作成したアプリケーションのEXEファイルがあるディレクトリに移動してアプリケーションを実行する。」(105頁右欄20行?107頁23行)

イ 以上,A乃至Eの記載事項(特に下線部分を参照)から,引用例1には次の発明(以下,「引用発明」という。)が記載されているものと認める。

「 4GLツールであるPｏｗeｒBｕildeｒでアプリケーションを作成し実行させる方法であって,
前記PｏｗeｒBｕildeｒによるアプリケーションの作成は,ライブラリやコンポーネントを用いたコーディング・レスな実装を含み,
C++言語やPascalなどの3GLによる3GLツールは,それのみでもシステム構築を完遂できるとともに,アプリケーションの開発において前記4GLツールの不足部分を補強するものであって,
前記3GLツールにより作成したDLLの前記4GLツールによる取り込みを,異なる言語での開発であることを意識しないでシームレスに実行させることができるとともに,前記4GLツールでは作成できないコンポーネントを前記3GLツールにより作成でき,それを前記4GLツールで活用することで,ツール連携できるものであり,
それにより,前記3GLツールであるPｏｗeｒ++において,前記4GLツールであるPｏｗeｒBｕildeｒで呼び込むDLLを作成し,PｏｗeｒBｕildeｒで活用する際には,
作成されたDLLをPｏｗeｒBｕildeｒから利用するために,グローバル外部関数の宣言をスクリプトで記述して,PｏｗeｒBｕildeｒ上の外部関数に使用するDLL,及び,DLL内にある関数を定義し,
作成したDLLを,パスが通っているディレクトリ,もしくはPｏｗeｒBｕildeｒで作成したアプリケーションのEXEファイルがあるディレクトリに移動した上で,PｏｗeｒBｕildeｒで作成したアプリケーションを実行させる,方法。」


(2) 対比

ア 本願発明と引用発明とを対比する。

(ア)引用発明の「4GLツールであるPｏｗeｒBｕildeｒ」,「DLL」は,本願発明の「4GLプログラミングツール」,「コンポーネント」にそれぞれ相当することは明らかである。
そして,引用発明の「アプリケーション」の作成は,「DLL」等のコンポーネントを用いた「実装」により作成されることを含み,その際当該「DLL」として,「4GLツールであるPｏｗeｒBｕildeｒ」が元々有する標準実装の「ライブラリ」に対応する「DLL」を用いることから,引用発明の「ライブラリ」は本願発明の「アプリケーション設計者が,4GLプログラミングツールによって提示されるユーザインターフェイスオブジェクトおよび制御との対話により,標準インプリメンテーションが4GLプログラミングツールによって与えられるコンポーネントタイプの組に属するコンポーネント」に対応するものである。
そうすると,引用発明の「4GLツールであるPｏｗeｒBｕildeｒ」が有する「ライブラリ」を含む「アプリケーション」について,「4GLツールであるPｏｗeｒBｕildeｒでアプリケーションを作成し実行させる方法」は,本願発明の「アプリケーション設計者が,4GLプログラミングツールによって提示されるユーザインターフェイスオブジェクトおよび制御との対話により,標準インプリメンテーションが4GLプログラミングツールによって与えられるコンポーネントタイプの組に属するコンポーネントを含むアプリケーションを生成することを可能にする4GLプログラミングツールを含むシステムにおいて使用される方法」に相当すると言える。

(イ)引用発明では,「3GLツールにより作成したDLLの前記4GLツールによる取り込みを,異なる言語での開発であることを意識しないでシームレスに実行させることができるとともに,前記4GLツールでは作成できないコンポーネントを前記3GLツールにより作成でき,それを前記4GLツールで活用することで,ツール連携できるものであ」るところ,「4GLツール」が「4GLツールでは作成できないコンポーネント」を含む「3GLツールにより作成したDLL」に関するデータを取り込むと解され,ここでの「3GLツールにより作成したDLL」はユーザ指定のカスタムインプリメンテーションによるものとみることができる。
そして,引用発明の「3GLツールにより作成したDLL」は,ユーザ指定のカスタムインプリメンテーションによるものであることから,「4GLツールであるPｏｗeｒBｕildeｒ」が元々有する標準実装の「ライブラリ」に対応する「DLL」の1つではないと言える。
そうすると,引用発明の「3GLツールにより作成したDLLの前記4GLツールによる取り込みを,異なる言語での開発であることを意識しないでシームレスに実行させることができるとともに,前記4GLツールでは作成できないコンポーネントを前記3GLツールにより作成でき,それを前記4GLツールで活用することで,ツール連携できるものであ」ることと,
本願発明の「4GLプログラミングツールが,設定するインプリメンテーション・クラスが前記アプリケーションの開発者によって指定されるインプリメンテーション・クラスである場合に,前記4GLプログラミングツールを用いて設計されるアプリケーションのコンポーネントのためのユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えるステップを含み,前記コンポーネントは,コンポーネントタイプの前記組に属するコンポーネントタイプのインスタンスであり,前記ユーザ指定のカスタムインプリメンテーションは4GLプログラミングツールによって与えられる前記標準インプリメンテーションの1つではな」いとは後記する点で相違するものの,
両者は,“4GLプログラミングツールが,前記4GLプログラミングツールを用いて設計されるアプリケーションのコンポーネントのためのユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えるステップを含み,前記コンポーネントは,コンポーネントタイプの前記組に属するコンポーネントタイプのインスタンスであり,前記ユーザ指定のカスタムインプリメンテーションは4GLプログラミングツールによって与えられる前記標準インプリメンテーションの1つではな”い点で共通すると言える。

(ウ)引用発明の「アプリケーション」は,「4GLツール」が「コーディング・レスな実装」により作成するものであり,「作成したDLLを,パスが通っているディレクトリ,もしくはPｏｗeｒBｕildeｒで作成したアプリケーションのEXEファイルがあるディレクトリに移動した上で,PｏｗeｒBｕildeｒで作成したアプリケーションを実行させる」ところ,作成された「DLL」が「アプリケーションのEXEファイル」とリンクされ,「アプリケーション」が実行されると解されることから,作成された「アプリケーション」がコードを含むこと,当該「アプリケーション」がユーザ指定のカスタムインプリメンテーションによる「3GLツールにより作成したDLL」を含む場合には,作成された「アプリケーション」のコードの一部において,「3GLツールにより作成したDLL」を用いることを示すことは自明であると言える。
そうすると,引用発明の「作成したDLLを,パスが通っているディレクトリ,もしくはPｏｗeｒBｕildeｒで作成したアプリケーションのEXEファイルがあるディレクトリに移動した上で,PｏｗeｒBｕildeｒで作成したアプリケーションを実行させる」ことと,
本願発明の「4GLプログラミングツールが,実行されると前記アプリケーションを走らせるアプリケーションコードを生成するステップを含み,前記アプリケーションコードは当該アプリケーションの開発者によって指定されたインプリメンテーション・クラスを特定するデータを含み,前記アプリケーションコードのある部分は,前記コンポーネントが前記ユーザ指定のカスタムインプリメンテーションを用いて実現されるべきであることを示」すこととは後記する点で相違するものの,
両者は,“4GLプログラミングツールが,実行されると前記アプリケーションを走らせるアプリケーションコードを生成するステップを含み,前記アプリケーションコードのある部分は,前記コンポーネントが前記ユーザ指定のカスタムインプリメンテーションを用いて実現されるべきであることを示す”点で共通すると言える。

イ 以上から,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

＜一致点＞

「 アプリケーション設計者が,4GLプログラミングツールによって提示されるユーザインターフェイスオブジェクトおよび制御との対話により,標準インプリメンテーションが4GLプログラミングツールによって与えられるコンポーネントタイプの組に属するコンポーネントを含むアプリケーションを生成することを可能にする4GLプログラミングツールによって設計されるアプリケーションを実行するための方法であって,
前記方法は,
4GLプログラミングツールが,前記4GLプログラミングツールを用いて設計されるアプリケーションのコンポーネントのためのユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えるステップを含み,
前記コンポーネントは,コンポーネントタイプの前記組に属するコンポーネントタイプのインスタンスであり,
前記ユーザ指定のカスタムインプリメンテーションは4GLプログラミングツールによって与えられる前記標準インプリメンテーションの1つではなく,さらに,
4GLプログラミングツールが,実行されると前記アプリケーションを走らせるアプリケーションコードを生成するステップを含み,
前記アプリケーションコードのある部分は,前記コンポーネントが前記ユーザ指定のカスタムインプリメンテーションを用いて実現されるべきであることを示す,
方法。」

＜相違点1＞
本願発明は,「アプリケーションのコンポーネントのインプリメンテーション・クラス」を有し,「アプリケーションのコンポーネントのインプリメンテーション・クラスは,デフォルトのインプリメンテーション・クラス,または,前記アプリケーションの開発者によって指定される,前記デフォルトのインプリメンテーション・クラスと異なるインプリメンテーション・クラスを含」んでいるのに対して,引用発明では,「アプリケーションのコンポーネントのインプリメンテーション・クラス」について言及がない点。

＜相違点2＞
本願発明では,「設定するインプリメンテーション・クラスが前記アプリケーションの開発者によって指定されるインプリメンテーション・クラスである場合に」,「ユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与える」のに対して,引用発明では,ユーザ指定のカスタムインプリメンテーションによる「3GLツールにより作成したDLL」を示すデータを何を契機に受け取るか明らかでない点。

＜相違点3＞
「アプリケーションコード」が含むデータに関し,本願発明では,「アプリケーションコードは当該アプリケーションの開発者によって指定されたインプリメンテーション・クラスを特定するデータを含」んでいるのに対して,引用発明では,「アプリケーションコード」が「インプリメンテーション・クラスを特定するデータ」を含むことについて特定されていない点。

＜相違点4＞
本願発明では,
「コンポーネントタイプの組に対して4GLプログラミングツールによって与えられる標準インプリメンテーションは各々共通インターフェイスをサポートし,
ユーザ指定のカスタムインプリメンテーションは前記共通インターフェイスをサポートし,
アプリケーションの実行中,4GLプログラミングツールによって与えられる標準インプリメンテーションを用いて実現されるいずれかのコンポーネントおよび前記コンポーネントは,前記共通インターフェイスを介してなされる呼出によりインスタンスが生成される」のに対して,
引用発明では,「標準インプリメンテーション」(4GLツール)と「カスタムインプリメンテーション」(3GLツール)の「共通インターフェイス」については,言及されていない点。


(3) 判断

上記相違点1乃至4について検討する。

ア 相違点1及び2について

引用発明では,ユーザ指定のカスタムインプリメンテーションによる「3GLツールにより作成したDLLの前記4GLツールによる取り込み」を実行することができるものの,「異なる言語での開発であることを意識しないでシームレスに実行させることができる」ことを特定しているから,ユーザが,カスタムインプリメンテーションによる「3GLツールにより作成したDLL」と,標準インプリメンテーションによる「4GLツール」により作成した「コンポーネント」を意識し,指定可能とすることの動機付けを見い出すことはできない。
また,「4GLツール」と「3GLツール」の利用を「インプリメンテーション・クラス」の指定により制御することも,本願優先日前に当該技術分野の周知技術であったとは言えない。
そうすると,引用発明において,アプリケーションのコンポーネントのインプリメンテーション・クラスを指定可能とし,アプリケーションのコンポーネントのインプリメンテーション・クラスを,デフォルトのインプリメンテーション・クラス,または,アプリケーションの開発者によって指定される,前記デフォルトのインプリメンテーション・クラスと異なるインプリメンテーション・クラスを含むようにすること,また,設定するインプリメンテーション・クラスがアプリケーションの開発者によって指定されるインプリメンテーション・クラスである場合に,ユーザ指定のカスタムインプリメンテーションを示すデータを受取るための制御を与えること,すなわち,上記相違点1及び2に係る構成とすることは,当業者が適宜なし得たものであるとすることはできない。

イ 相違点3について

引用発明では,「3GLツールであるPｏｗeｒ++において,前記4GLツールであるPｏｗeｒBｕildeｒで呼び込むDLLを作成し」,作成した「DLL」が「アプリケーションのEXEファイル」とリンクされ,「アプリケーション」が実行されると解されることから,作成された「アプリケーション」がユーザ指定のカスタムインプリメンテーションによる「3GLツールにより作成したDLL」を含む場合には,作成された「アプリケーション」のコードの一部において,「3GLツールにより作成したDLL」を用いることを示すことは自明であると言える。
しかしながら,上記アでの検討の通り,ユーザが,カスタムインプリメンテーションによる「3GLツールにより作成したDLL」と,標準インプリメンテーションによる「4GLツール」により作成した「コンポーネント」を意識し,指定可能とすることの動機付けを見い出すことはできず,また,「4GLツール」と「3GLツール」の利用を「インプリメンテーション・クラス」の指定により制御することも,本願優先日前に当該技術分野の周知技術であったとは言えない。
そうすると,引用発明において,4GLツールで作成されたアプリケーションコードがインプリメンテーション・クラスを特定するデータを含むようにすること,すなわち,上記相違点3に係る構成とすることは,当業者が適宜なし得たものであるとすることはできない。

ウ 相違点4について

引用発明では,「3GLツールにより作成したDLLの前記4GLツールによる取り込みを,異なる言語での開発であることを意識しないでシームレスに実行させることができるとともに,前記4GLツールでは作成できないコンポーネントを前記3GLツールにより作成でき,それを前記4GLツールで活用することで,ツール連携できるものであ」るところ,「4GLツール」,「3GLツール」を連携して「コンポーネント」を作成するための共通インターフェイスについては特に言及されていない。
また,本願の優先日前に公知であり,平成26年2月20日付け拒絶査定において引用された,特開平10-105392号公報,特開平7-182172号公報,特開平9-231077号公報のいずれの文献にも,「コンポーネントタイプの組に対して4GLプログラミングツールによって与えられる標準インプリメンテーションは各々共通インターフェイスをサポートし,ユーザ指定のカスタムインプリメンテーションは前記共通インターフェイスをサポートし,アプリケーションの実行中,4GLプログラミングツールによって与えられる標準インプリメンテーションを用いて実現されるいずれかのコンポーネントおよび前記コンポーネントは,前記共通インターフェイスを介してなされる呼出によりインスタンスが生成される」ことは記載されておらず,このような技術が本願の優先日前に周知技術であったとまでは言えない。
そうすると,引用発明において,標準インプリメンテーションである4GLツールと,カスタムインプリメンテーションである3GLツールとの共通インターフェイスをサポートし,アプリケーションの実行中,4GLツールによって与えられる標準インプリメンテーションを用いて実現されるいずれかのコンポーネントおよび前記コンポーネントは,前記共通インターフェイスを介してなされる呼出によりインスタンスが生成されること,すなわち,上記相違点4に係る構成とすることは,当業者が適宜なし得たものであるとすることはできない。

エ 小括

上記で検討したごとく,本願発明は,当業者が引用発明に基づいて容易に発明をすることができたものとすることができないものである。


(4) 請求項2に係る発明について

請求項2に係る発明は,本願発明をコンピュータによって読み出し可能な記録媒体の発明として記載したものであるから,上記(1)乃至(3)で示した理由により当業者が容易に発明をすることができたものとすることができないものである。


(5) まとめ

以上のとおりであるから,本願の請求項1,2に係る発明は,引用発明及び当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものとすることができないものである。
よって,原査定の理由によっては,本願を拒絶することはできない。


第4 当審拒絶理由について

1 当審拒絶理由の概要

この出願の下記の請求項に係る発明は,同日出願された下記の出願に係る発明と同一と認められ,かつ,下記の出願に係る発明は特許されており協議を行うことができないから,特許法第39条第2項の規定により特許を受けることができない。
記

請求項: 1,3
出願1: 特願2008-10624号(特許第5520446号)

＜備考＞

(1)本願の補正後の請求項1に記載された発明特定事項と,上記出願1(特願2008-10624号)の請求項1(平成26年2月12日付け補正書により補正され,その後に特許された時の特許請求の範囲)に記載された発明特定事項は,明らかに同一のものと認められる。

(2)本願の補正後の請求項3に記載された発明特定事項と,上記出願1(特願2008-10624号)の請求項5(平成26年2月12日付け補正書により補正され,その後に特許された時の特許請求の範囲)に記載された発明特定事項は,明らかに同一のものと認められる。

2 当審拒絶理由の判断

平成27年8月7日付け手続補正により,平成26年2月12日付け手続補正書に記載の特許請求の範囲の請求項1,3は削除された。
よって,当審拒絶理由は解消した。

第5 むすび

以上のとおり,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2015-09-07 
出願番号 特願2012-128172(P2012-128172)
審決分類 P 1 8・ 121- WY (G06F)
P 1 8・ 4- WY (G06F)
最終処分 成立  
前審関与審査官 漆原 孝治  
特許庁審判長 高木 進
特許庁審判官 辻本 泰隆
須田 勝巳
発明の名称 第4世代プログラミングツールを用いて生成されるアプリケーションの属性の拡張  
代理人 野田 久登  
代理人 仲村 義平  
代理人 堀井 豊  
代理人 深見 久郎  
代理人 森田 俊雄  

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