ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F |
---|---|
管理番号 | 1281315 |
審判番号 | 不服2011-2228 |
総通号数 | 168 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2013-12-27 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2011-01-31 |
確定日 | 2013-11-06 |
事件の表示 | 特願2001-134487「オブジェクト指向システムによるデータ処理装置」拒絶査定不服審判事件〔平成14年11月29日出願公開、特開2002-342310〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
1.手続の経緯 本願は、平成13年5月1日の出願であって、平成21年10月1日付けで拒絶理由通知がなされ、平成22年4月7日付けで手続補正がなされたが、同年9月27日付けで拒絶査定がなされ、これに対し、平成23年1月31日に拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。 2.平成23年1月31日付けの手続補正についての補正却下の決定 [補正却下の決定の結論] 平成23年1月31日付けの手続補正を却下する。 [理由] (1)本願発明 平成23年1月31日付けの手続補正(以下、「本件手続補正」という。)は、補正前の請求項1に記載された発明を、補正後の請求項1に記載された発明に補正することを含むものである。 ここで、補正前の請求項1の記載と補正後の請求項1の記載は、次のようなものである。 (補正前の請求項1の記載) 「【請求項1】 インターネット上の1つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得して統一的に表示し、再利用するためにクライアントコンピュータ上で動作するデータ処理装置であって、 前記データベース、またはマークアップ言語で記述された種々のデータをアクセスし、 取得し一時的に格納する第1のオブジェクトと、 前記取得し一時的に格納された各データを特定の構造の複数のデータ・オブジェクトに変換する第2のオブジェクトと、 前記特定の構造のデータ・オブジェクトを特定の形式で表示すると共に、ユーザの指定に従って、表示箇所を変更する機能を有する第3のオブジェクトと、 前記特定の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する第4のオブジェクトと、 からなるオブジェクト指向システムによるデータ処理装置。」 (補正後の請求項1の記載) 「【請求項1】 インターネット上の1つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得して統一的に表示し、再利用するためにクライアントコンピュータ上で動作するデータ処理装置であって、 前記データベース、またはマークアップ言語で記述された種々のデータをアクセスし、 取得し一時的に格納する第1のオブジェクトと、 前記取得し一時的に格納された各データを正規化して共通の構造の複数のデータ・オブジェクトに変換する第2のオブジェクトと、 前記共通の構造のデータ・オブジェクトを特定の形式で表示すると共に、ユーザの指定に従って、表示箇所を変更する機能を有する第3のオブジェクトと、 前記共通の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する第4のオブジェクトと、 からなるオブジェクト指向システムによるデータ処理装置。」 上記補正は、補正前の請求項1に記載された発明における「前記取得し一時的に格納された各データを特定の構造の複数のデータ・オブジェクトに変換する第2のオブジェクト」を「前記取得し一時的に格納された各データを正規化して共通の構造の複数のデータ・オブジェクトに変換する第2のオブジェクト」に、「前記特定の構造のデータ・オブジェクトを特定の形式で表示すると共に、ユーザの指定に従って、表示箇所を変更する機能を有する第3のオブジェクト」を「前記共通の構造のデータ・オブジェクトを特定の形式で表示すると共に、ユーザの指定に従って、表示箇所を変更する機能を有する第3のオブジェクト」に、「前記特定の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する第4のオブジェクト」を「前記共通の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する第4のオブジェクト」に限定するものであって、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法17条の2第4項第2号の特許請求の範囲の減縮を目的とするものに該当する。 そこで、本件手続補正後の上記請求項1に係る発明(以下、「本願補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか(平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に適合するか)について、以下に検討する。 (2)引用例 原査定の拒絶の理由に引用された、 奥井康弘 他3名,実践!XML&Javaプログラミング第5回XMLとデータベースの連携,Java WORLD,日本,株式会社IDGジャパン, 2001年 1月 1日,第5巻第1号,P.212?216(以下、「引用例」という。)、 には、図面とともに次の事項が記載されている。 a.「3層モデルとXML 商活動においては、さまざまなかたちで顧客へのデータ提供が行われる。例えばホテル業界であれば、部屋の値段や空室情報などが顧客に提供される。ホテルごとにさまざまなデータベース・システムを用いて管理されているそれらの情報を適宜整形し、Webぺージなどからユーザーへと提供するわけである。 その際、同じ系列のいくつかのホテルが同じデータベース・システムを用いて惜報を一括管理していれば、同じ形式のデータを抽出し、Webで公開することができる。しかし、ユーザーの立場からすると、ある都市の異なる系列のホテル群の中から、自分の予算などに見合ったホテルを見つけられることが望ましいはずだ。 それを実現するためには、異なるデータベース・システムから取り出したデータをどのようにして比較可能な共通形式にしてやるかが問題となる。ひとたびデータが標準形式に変換できたならば、それ以降は横断的にデータを比較することが可能になるのである。 そのデータ変換には、2つのケースが考えられる。1つは、XML以外の形式のデータからXML形式への変換が必要なケースである。これには、例えばCSV形式のデータをXML形式のデータに変換する場合などがあてはまる。 一方、データベース・システムにおいて、すでに個別のDTDに従ったXML文書としてデータが格納されていることもあるだろう。その場合には、オリジナルのXML文書を、比較用に標準化したDTDに基づくXML文書へと変換する必要がある。ここにもう1つのケース、すなわちXMLからXMLへの変換が発生するのである。 これら2つのうち、どちらかの変換を使用して、共通形式のXML文書を用意することにより、データの操作や比較などが行えるようになる。さらに、このようにして共通化したXML文書であれば、それをHTMLに変換し、Webブラウザを用いてクライアントに示すことも可能なのだ。」 (第212頁中欄第17行?第213頁左欄第2行) b.「ミドル層でのXMLからXMLへの変換 データベースから出力される非XML形式のデータをXML形式に変換する方法については、これまでの連載の中でもCSVからXMLへの変換というかたちで紹介した。それに対し、今回取り上げるのはXMLからXMLへの変換である。 ・・・ なお、XSLTでは出力形式としてXMLとHTML (XHTML)、プレーン・テキストをサポートしている。 では、XSLTの機能により、オリジナルのXML文書をミドル層で使用するために構造を標準化したXML文書(以下、「標準XML文書」と呼ぶ)に変換する仕組みを説明しよう。 あるデータベースに格納されているデータが、リスト1に示すようなXML形式で定義されていたとする。この文書のタグの意昧は表1のとおりであり、データベースのスキーマに対応する、リスト2のようなDTDに基づいているとしよう。 これに対し、標準XML文書はリスト3のようなものであり、タグの意昧、DTDはそれぞれ表2、リスト4のようなものであるとする。 リスト1のXML文書から、リスト3のような構造の”部品”となるXML文書を生成するには、リスト5のようなXSLTスタイルシートを記述すればよい。これによって得られる複数のホテルの部屋情報を表すXML文書(以下、「部品XML文書」と呼ぶ)をマージし、ルート要素「rooms」でラッピングすることにより、標準XML文書が得られるのである。・・・」 (第213頁左欄第16行?第214頁右欄第12行) c.「クライアント層でのXMLからHTMLへの変換 さて、以上のような処理で得られた標準XML文書は、どのようにすればクライアン卜サイドに表示できるのだろうか。 実はこの操作にもXSLTを利用することができる。すなわち、XSLTによって標準XML文書のデータをHTML形式に変換すればよいのである。 例えば、ホテルの部屋の情報を比較するために、リスト6のJavaプログラムを用いてリスト3の標準XML文書が得られたとしよう。これを表形式で画面に表示するにはリスト7のようなXSLTスタイルシートを作成すればよい。これをリスト3のXML文書に適用すると画面1の価格の比較表が得られる。」 (第215頁左欄第2行?第216頁左欄第5行) ここで、上記a.には、 「ホテルごとにさまざまなデータベース・システムを用いて管理されているそれらの情報を適宜整形し、Webぺージなどからユーザーへと提供するわけである。」と記載されていることから、 「Webで公開されている、ホテルごとにさまざまなデータベース・システムを用いて管理されている情報を取り出す機能」が記載されているといえる。 次に、上記a.の「そのデータ変換には、2つのケースが考えられる。1つは、XML以外の形式のデータからXML形式への変換が必要なケースである。これには、例えばCSV形式のデータをXML形式のデータに変換する場合などがあてはまる。 一方、データベース・システムにおいて、すでに個別のDTDに従ったXML文書としてデータが格納されていることもあるだろう。その場合には、オリジナルのXML文書を、比較用に標準化したDTDに基づくXML文書へと変換する必要がある。ここにもう1つのケース、すなわちXMLからXMLへの変換が発生するのである。これら2つのうち、どちらかの変換を使用して、共通形式のXML文書を用意することにより、データの操作や比較などが行えるようになる。」の記載、及び、上記b.の「データベースから出力される非XML形式のデータをXML形式に変換する方法については、これまでの連載の中でもCSVからXMLへの変換というかたちで紹介した。それに対し、今回取り上げるのはXMLからXMLへの変換である。」の記載から、 「CSV形式等のデータ、またはオリジナルのXML文書を共通形式のXML形式へ変換する機能」が記載されているといえる。 また、上記b.の「これによって得られる複数のホテルの部屋情報を表すXML文書(以下、「部品XML文書」と呼ぶ)をマージし、ルート要素「rooms」でラッピングすることにより、標準XML文書が得られるのである。」の記載、及び、上記a.の「これら2つのうち、どちらかの変換を使用して、共通形式のXML文書を用意する」の記載から、 「変換された共通形式のXML文書をマージし、ラッピングする機能」が記載されているといえる。 さらに、上記a.の「共通形式のXML文書を用意することにより、データの操作や比較などが行えるようになる。」等の記載から、「共通の形式で表示し、データの操作や比較などをする」ことが記載されている、といえる。 次に、上記c.の「さて、以上のような処理で得られた標準XML文書は、どのようにすればクライアン卜サイドに表示できるのだろうか。 実はこの操作にもXSLTを利用することができる。すなわち、XSLTによって標準XML文書のデータをHTML形式に変換すればよいのである。 例えば、ホテルの部屋の情報を比較するために、リスト6のJavaプログラムを用いてリスト3の標準XML文書が得られたとしよう。これを表形式で画面に表示するにはリスト7のようなXSLTスタイルシートを作成すればよい。これをリスト3のXML文書に適用すると画面1の価格の比較表が得られる。」という記載から、 「共通形式の標準XML文書をHTML形式で表示する機能」が記載されている、といえる。 また、上記a.ないしc.の記載より、上記各処理を行っているのは、「ミドル層又はクライアント層」であるといえる。 さらに、データを取り出しや変換を行った際、一時的にデータを格納しておくことは、通常行われていることである。 したがって、上記引用例には、次の発明(以下、「引用例記載の発明」という。)が記載されているといえる。 「Webで公開されている、ホテルごとにさまざまなデータベース・システムを用いて管理されている情報を取り出し、 共通の形式で表示し、データの操作や比較などをする、 ミドル層又はクライアント層であって、 Webで公開されている、ホテルごとにさまざまなデータベース・システムを用いて管理されている情報を取り出し一時的にデータを格納する機能と、 前記一時的にデータを格納された、CSV形式等のデータ、またはオリジナルのXML文書を共通形式のXML形式へ変換する機能と、 共通形式のXML文書をHTML形式で表示する機能と、 複数の変換された共通形式のXML文書をマージし、ラッピングする機能、 からなるミドル層又はクライアント層。」 (3).対比 本願補正発明と引用例記載の発明とを対比すると、次のことがいえる。 (ア)引用例記載の発明における「Webで公開されている、ホテルごとにさまざまなデータベース・システムを用いて管理されている情報を取り出」すことは、本願補正発明における「インターネット上の1つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得」することに相当する。 (イ)引用例記載の発明における「ミドル層又はクライアント層」と、本願補正発明における「データ処理装置」とは「データ処理を行うもの」という点で共通のものである。 (ウ)引用例記載の発明における「CSV形式等のデータ」は、本願補正発明における「データベース」の「データ」に相当する。 (エ)引用例記載の発明における「オリジナルのXML文書」は、本願補正発明における「マークアップ言語で記述された種々のデータ」に相当する。 (オ)引用例記載の発明における「共通形式のXML形式へ変換する」ことは、「共通形式」へ「変換する」ことが本願補正発明における「正規化」にほかならないことから、本願補正発明における「正規化して共通の構造の複数のデータに変換する」ことに相当するといえる。 (カ)引用例記載の発明における「共通の形式で表示し」は、本願補正発明における「統一的に表示し」に相当する。 (キ)引用例記載の発明における「データの操作や比較など」は、異なるデータベース・システムから取り出したデータを横断的にデータを比較する等、別目的で利用することであるので、本願補正発明における「再利用」に相当するといえる。 (ク)引用例記載の発明における「複数の変換された共通形式のXML文書」と、本願補正発明における「共通の構造の複数のデータ・オブジェクト」とは、「共通の構造の複数のデータ」という点で共通のものである。 (ケ)引用例記載の発明における「マージし、ラッピングする」は、本願補正発明における「データ・オブジェクト化」が新しいオブジェクトとしての体裁を整えることであることから、本願補正発明における「組み合わせてデータ化する」という点で共通のものである。 上記(ア)?(ケ)の事項を踏まえると、本願補正発明と引用例記載の発明とは、次の点で一致し、また、相違するものと認められる。 (一致点) 「インターネット上の1つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得して統一的に表示し、 再利用するためにデータ処理を行うものであって、 データベース、またはマークアップ言語で記述された種々のデータを取得し、一時的に格納する機能と、 前記データベース、またはマークアップ言語で記述された種々のデータを正規化して共通の構造の複数のデータに変換する機能と、 共通の構造のデータを特定の形式で表示する機能と、 複数の変換された共通の構造のデータを組み合わせてデータ化する機能、 からなるデータ処理を行うもの。」 (相違点) 相違点1:「データ処理を行うもの」について、本願補正発明においては「クライアントコンピュータ上で動作するデータ処理装置」であるのに対して、引用例記載の発明は「データ処理を」「ミドル層」で行うものであって「クライアントコンピュータ上で動作するデータ処理装置」で行われるとは特にされていない点。 相違点2:「共通の構造のデータ」及びこれらを「組み合わせてデータ化」したデータについて、本願補正発明においては、「データ・オブジェクト」であるのに対して、引用例記載の発明では、そのようになっていない点。 相違点3:「複数の変換された共通の構造のデータを組み合わせてデータ化する機能」について、本願補正発明においては、「共通の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する」のに対して、引用例記載の発明では、そのような構成について特定されていない点。 相違点4:「共通の構造のデータを特定の形式で表示する機能」について、本願補正発明においては「ユーザの指定に従って、表示箇所を変更する機能を有」しているのに対して、引用例記載の発明では、そのような構成について特定されていない点。 相違点5:各「機能」について、本願補正発明においては、「オブジェクト」であるのに対して、引用例記載の発明では、そのような構成について特定されていない点。 (4)当審の判断 そこで、上記相違点1?3について検討する。 (相違点1について) proxyサーバ等、Webブラウザと外部のサーバとの中間に位置するサーバ、すなわち、ミドル層で行う処理をクライアントに設けることは、広く行われていることにすぎず、引用例記載の「ミドル層」における処理を「クライアントコンピュータ上で動作するデータ処理装置」上で動作するよう構成することは、当業者が適宜になし得ることである。 よって、相違点1は、格別のものではない。 (相違点2について) データをオブジェクトとして扱うよう実装することは、当業者が適宜になし得ることである。 よって、相違点2は、格別のものではない。 (相違点3について) オブジェクトを直接操作することによって、オブジェクトどうしを関連づけることは、本願明細書において従来の技術として示されている米国特許第5754808号等に記載させているように周知の技術である。また、オブジェクト同士を組み合わせた結果が、新たなオブジェクトになることは明らかである。 してみると、表示された引用例記載の「データ」を、組み合わせて別のオブジェクトとすることは、当業者が容易に想到し得るものである。 よって、相違点3は、格別のものではない。 (相違点4について) ユーザの指定に従って、オブジェクトの表示箇所を変更するよう構成することは、当業者が適宜になし得ることである。 よって、相違点4は、格別のものではない。 (相違点5について) 機能をオブジェクトとして実装することは、当業者が適宜になし得ることである。 よって、相違点5は、特段のものではない。 (本願補正発明の作用効果について) そして、本願補正発明の構成によってもたらされる効果も、引用例記載の発明から当業者が容易に予測できるものであって、格別のものとはいえない。 したがって、本願補正発明は、引用例記載の発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許出願の際独立して特許を受けることができないものである。 (5)むすび したがって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 3.補正却下の決定を踏まえた検討 (1)本願発明 平成23年1月31日付けの手続補正は、上記のとおり却下されたので、本願の請求項1ないし8に係る発明は、平成22年4月7日付け手続補正書の特許請求の範囲の請求項1ないし8に記載された事項により特定されるものであるところ、その請求項1に係る発明は、平成22年4月7日付け手続補正書によって補正された特許請求の範囲の記載からみて、その請求項1に記載された事項により特定される、次のとおりのものと認める。(以下、「本願発明」という。) 「【請求項1】 インターネット上の1つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得して統一的に表示し、再利用するためにクライアントコンピュータ上で動作するデータ処理装置であって、 前記データベース、またはマークアップ言語で記述された種々のデータをアクセスし、 取得し一時的に格納する第1のオブジェクトと、 前記取得し一時的に格納された各データを特定の構造の複数のデータ・オブジェクトに変換する第2のオブジェクトと、 前記特定の構造のデータ・オブジェクトを特定の形式で表示すると共に、ユーザの指定に従って、表示箇所を変更する機能を有する第3のオブジェクトと、 前記特定の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する第4のオブジェクトと、 からなるオブジェクト指向システムによるデータ処理装置。」 (2)引用例及び周知例 これに対して、原査定の拒絶の理由に引用された引用例とその記載事項は、上記2.(2)に示したとおりである。 (3)本願発明は、上記2.で検討した本願補正発明における 「前記取得し一時的に格納された各データを正規化して共通の構造の複数のデータ・オブジェクトに変換する第2のオブジェクト」において「正規化して共通の構造」の限定を省き、「前記取得し一時的に格納された各データを特定の構造の複数のデータ・オブジェクトに変換する第2のオブジェクト」とし、 「前記共通の構造のデータ・オブジェクトを特定の形式で表示すると共に、ユーザの指定に従って、表示箇所を変更する機能を有する第3のオブジェクト」における「共通の構造」の限定を省き、「前記特定の構造のデータ・オブジェクトを特定の形式で表示すると共に、ユーザの指定に従って、表示箇所を変更する機能を有する第3のオブジェクト」とし、 「前記共通の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する第4のオブジェクト」における「共通の構造」の限定を省き、「前記特定の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する第4のオブジェクト」と上位概念化したものである。 そうすると、本願発明の構成要素を全て含み、さらに特定の限定を施したに相当する本願補正発明が、上記2.(4)に記載したとおり、引用例記載の発明に基いて、当業者が容易に発明することができたものであることから、上記限定を省いて上位概念化した本願発明は、同様に引用例記載の発明に基いて、当業者が容易に発明することができたものである。 4.むすび 以上のとおり、本願発明は、引用例記載の発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許を受けることができない。 したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。 よって、結論のとおり審決する。 |
審理終結日 | 2013-06-12 |
結審通知日 | 2013-06-13 |
審決日 | 2013-06-27 |
出願番号 | 特願2001-134487(P2001-134487) |
審決分類 |
P
1
8・
121-
Z
(G06F)
P 1 8・ 575- Z (G06F) |
最終処分 | 不成立 |
前審関与審査官 | 成瀬 博之 |
特許庁審判長 |
長島 孝志 |
特許庁審判官 |
酒井 伸芳 原 秀人 |
発明の名称 | オブジェクト指向システムによるデータ処理装置 |
代理人 | 上田 忠 |
代理人 | 千葉 昭男 |
代理人 | 富田 博行 |
代理人 | 小野 新次郎 |
代理人 | 小林 泰 |