【事件の表示】
　特願２００１−１３４４８７「オブジェクト指向システムによるデータ処理装置」拒絶査定不服審判事件〔平成１４年１１月２９日出願公開、特開２００２−３４２３１０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１３年５月１日の出願であって、平成２１年１０月１日付けで拒絶理由通知がなされ、平成２２年４月７日付けで手続補正がなされたが、同年９月２７日付けで拒絶査定がなされ、これに対し、平成２３年１月３１日に拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。
　
　
２．平成２３年１月３１日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２３年１月３１日付けの手続補正を却下する。
　
［理由］
　
（１）本願発明
　平成２３年１月３１日付けの手続補正（以下、「本件手続補正」という。）は、補正前の請求項１に記載された発明を、補正後の請求項１に記載された発明に補正することを含むものである。
　ここで、補正前の請求項１の記載と補正後の請求項１の記載は、次のようなものである。
　
（補正前の請求項１の記載）
「【請求項１】　インターネット上の１つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得して統一的に表示し、再利用するためにクライアントコンピュータ上で動作するデータ処理装置であって、
　前記データベース、またはマークアップ言語で記述された種々のデータをアクセスし、
取得し一時的に格納する第１のオブジェクトと、
　前記取得し一時的に格納された各データを特定の構造の複数のデータ・オブジェクトに変換する第２のオブジェクトと、
　前記特定の構造のデータ・オブジェクトを特定の形式で表示すると共に、ユーザの指定に従って、表示箇所を変更する機能を有する第３のオブジェクトと、
　前記特定の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する第４のオブジェクトと、
からなるオブジェクト指向システムによるデータ処理装置。」
　
（補正後の請求項１の記載）
「【請求項１】　インターネット上の１つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得して統一的に表示し、再利用するためにクライアントコンピュータ上で動作するデータ処理装置であって、
　前記データベース、またはマークアップ言語で記述された種々のデータをアクセスし、
取得し一時的に格納する第１のオブジェクトと、
　前記取得し一時的に格納された各データを
正規化して共通の構造
　前記
共通の構造
　前記
共通の構造
からなるオブジェクト指向システムによるデータ処理装置。」
　
　上記補正は、補正前の請求項１に記載された発明における「前記取得し一時的に格納された各データを特定の構造の複数のデータ・オブジェクトに変換する第２のオブジェクト」を「前記取得し一時的に格納された各データを
正規化して共通の構造
共通の構造
共通の構造
　そこで、本件手続補正後の上記請求項１に係る発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について、以下に検討する。
　
　
（２）引用例
　原査定の拒絶の理由に引用された、
奥井康弘　他３名，実践！ＸＭＬ＆Ｊａｖａプログラミング第５回ＸＭＬとデータベースの連携，Ｊａｖａ  ＷＯＲＬＤ，日本，株式会社ＩＤＧジャパン，
２００１年　１月　１日，第5巻第1号，P.212〜216（以下、「引用例」という。）、
には、図面とともに次の事項が記載されている。
　
ａ．「３層モデルとＸＭＬ
　商活動においては、さまざまなかたちで顧客へのデータ提供が行われる。例えばホテル業界であれば、部屋の値段や空室情報などが顧客に提供される。ホテルごとにさまざまなデータベース・システムを用いて管理されているそれらの情報を適宜整形し、Ｗｅｂぺージなどからユーザーへと提供するわけである。
　その際、同じ系列のいくつかのホテルが同じデータベース・システムを用いて惜報を一括管理していれば、同じ形式のデータを抽出し、Ｗｅｂで公開することができる。しかし、ユーザーの立場からすると、ある都市の異なる系列のホテル群の中から、自分の予算などに見合ったホテルを見つけられることが望ましいはずだ。
　それを実現するためには、異なるデータベース・システムから取り出したデータをどのようにして比較可能な共通形式にしてやるかが問題となる。ひとたびデータが標準形式に変換できたならば、それ以降は横断的にデータを比較することが可能になるのである。
　そのデータ変換には、２つのケースが考えられる。１つは、ＸＭＬ以外の形式のデータからＸＭＬ形式への変換が必要なケースである。これには、例えばＣＳＶ形式のデータをＸＭＬ形式のデータに変換する場合などがあてはまる。
　一方、データベース・システムにおいて、すでに個別のＤＴＤに従ったＸＭＬ文書としてデータが格納されていることもあるだろう。その場合には、オリジナルのＸＭＬ文書を、比較用に標準化したＤＴＤに基づくＸＭＬ文書へと変換する必要がある。ここにもう１つのケース、すなわちＸＭＬからＸＭＬへの変換が発生するのである。
　これら２つのうち、どちらかの変換を使用して、共通形式のＸＭＬ文書を用意することにより、データの操作や比較などが行えるようになる。さらに、このようにして共通化したＸＭＬ文書であれば、それをＨＴＭＬに変換し、Ｗｅｂブラウザを用いてクライアントに示すことも可能なのだ。」
（第２１２頁中欄第１７行〜第２１３頁左欄第２行）
　
ｂ．「ミドル層でのＸＭＬからＸＭＬへの変換
　データベースから出力される非ＸＭＬ形式のデータをＸＭＬ形式に変換する方法については、これまでの連載の中でもＣＳＶからＸＭＬへの変換というかたちで紹介した。それに対し、今回取り上げるのはＸＭＬからＸＭＬへの変換である。
・・・
なお、ＸＳＬＴでは出力形式としてＸＭＬとＨＴＭＬ （ＸＨＴＭＬ）、プレーン・テキストをサポートしている。
　では、ＸＳＬＴの機能により、オリジナルのＸＭＬ文書をミドル層で使用するために構造を標準化したＸＭＬ文書（以下、「標準ＸＭＬ文書」と呼ぶ）に変換する仕組みを説明しよう。
　あるデータベースに格納されているデータが、リスト１に示すようなＸＭＬ形式で定義されていたとする。この文書のタグの意昧は表１のとおりであり、データベースのスキーマに対応する、リスト２のようなＤＴＤに基づいているとしよう。
　これに対し、標準ＸＭＬ文書はリスト３のようなものであり、タグの意昧、ＤＴＤはそれぞれ表２、リスト４のようなものであるとする。
　リスト１のＸＭＬ文書から、リスト３のような構造の”部品”となるＸＭＬ文書を生成するには、リスト５のようなＸＳＬＴスタイルシートを記述すればよい。これによって得られる複数のホテルの部屋情報を表すＸＭＬ文書（以下、「部品ＸＭＬ文書」と呼ぶ）をマージし、ルート要素「ｒｏｏｍｓ」でラッピングすることにより、標準ＸＭＬ文書が得られるのである。・・・」
（第２１３頁左欄第１６行〜第２１４頁右欄第１２行）
　
ｃ．「クライアント層でのＸＭＬからＨＴＭＬへの変換
　さて、以上のような処理で得られた標準ＸＭＬ文書は、どのようにすればクライアン卜サイドに表示できるのだろうか。
　実はこの操作にもＸＳＬＴを利用することができる。すなわち、ＸＳＬＴによって標準ＸＭＬ文書のデータをＨＴＭＬ形式に変換すればよいのである。
　例えば、ホテルの部屋の情報を比較するために、リスト６のＪａｖａプログラムを用いてリスト３の標準ＸＭＬ文書が得られたとしよう。これを表形式で画面に表示するにはリスト７のようなＸＳＬＴスタイルシートを作成すればよい。これをリスト３のＸＭＬ文書に適用すると画面１の価格の比較表が得られる。」
(第２１５頁左欄第２行〜第２１６頁左欄第５行)
　
　ここで、上記ａ．には、
「ホテルごとにさまざまなデータベース・システムを用いて管理されているそれらの情報を適宜整形し、Ｗｅｂぺージなどからユーザーへと提供するわけである。」と記載されていることから、
「Ｗｅｂで公開されている、ホテルごとにさまざまなデータベース・システムを用いて管理されている情報を取り出す機能」が記載されているといえる。
　次に、上記ａ．の「そのデータ変換には、２つのケースが考えられる。１つは、ＸＭＬ以外の形式のデータからＸＭＬ形式への変換が必要なケースである。これには、例えばＣＳＶ形式のデータをＸＭＬ形式のデータに変換する場合などがあてはまる。
　一方、データベース・システムにおいて、すでに個別のＤＴＤに従ったＸＭＬ文書としてデータが格納されていることもあるだろう。その場合には、オリジナルのＸＭＬ文書を、比較用に標準化したＤＴＤに基づくＸＭＬ文書へと変換する必要がある。ここにもう１つのケース、すなわちＸＭＬからＸＭＬへの変換が発生するのである。これら２つのうち、どちらかの変換を使用して、共通形式のＸＭＬ文書を用意することにより、データの操作や比較などが行えるようになる。」の記載、及び、上記ｂ．の「データベースから出力される非ＸＭＬ形式のデータをＸＭＬ形式に変換する方法については、これまでの連載の中でもＣＳＶからＸＭＬへの変換というかたちで紹介した。それに対し、今回取り上げるのはＸＭＬからＸＭＬへの変換である。」の記載から、
「ＣＳＶ形式等のデータ、またはオリジナルのＸＭＬ文書を共通形式のＸＭＬ形式へ変換する機能」が記載されているといえる。
　また、上記ｂ．の「これによって得られる複数のホテルの部屋情報を表すＸＭＬ文書（以下、「部品ＸＭＬ文書」と呼ぶ）をマージし、ルート要素「ｒｏｏｍｓ」でラッピングすることにより、標準ＸＭＬ文書が得られるのである。」の記載、及び、上記ａ．の「これら２つのうち、どちらかの変換を使用して、共通形式のＸＭＬ文書を用意する」の記載から、
「変換された共通形式のＸＭＬ文書をマージし、ラッピングする機能」が記載されているといえる。
　さらに、上記ａ．の「共通形式のＸＭＬ文書を用意することにより、データの操作や比較などが行えるようになる。」等の記載から、「共通の形式で表示し、データの操作や比較などをする」ことが記載されている、といえる。
　
　
　次に、上記ｃ．の「さて、以上のような処理で得られた標準ＸＭＬ文書は、どのようにすればクライアン卜サイドに表示できるのだろうか。
　実はこの操作にもＸＳＬＴを利用することができる。すなわち、ＸＳＬＴによって標準ＸＭＬ文書のデータをＨＴＭＬ形式に変換すればよいのである。
　例えば、ホテルの部屋の情報を比較するために、リスト６のＪａｖａプログラムを用いてリスト３の標準ＸＭＬ文書が得られたとしよう。これを表形式で画面に表示するにはリスト７のようなＸＳＬＴスタイルシートを作成すればよい。これをリスト３のＸＭＬ文書に適用すると画面１の価格の比較表が得られる。」という記載から、
「共通形式の標準ＸＭＬ文書をＨＴＭＬ形式で表示する機能」が記載されている、といえる。
　
　また、上記ａ．ないしｃ．の記載より、上記各処理を行っているのは、「ミドル層又はクライアント層」であるといえる。
　さらに、データを取り出しや変換を行った際、一時的にデータを格納しておくことは、通常行われていることである。
　
　したがって、上記引用例には、次の発明（以下、「引用例記載の発明」という。）が記載されているといえる。
「Ｗｅｂで公開されている、ホテルごとにさまざまなデータベース・システムを用いて管理されている情報を取り出し、
共通の形式で表示し、データの操作や比較などをする、
ミドル層又はクライアント層であって、
　Ｗｅｂで公開されている、ホテルごとにさまざまなデータベース・システムを用いて管理されている情報を取り出し一時的にデータを格納する機能と、
　前記一時的にデータを格納された、ＣＳＶ形式等のデータ、またはオリジナルのＸＭＬ文書を共通形式のＸＭＬ形式へ変換する機能と、
　共通形式のＸＭＬ文書をＨＴＭＬ形式で表示する機能と、
複数の変換された共通形式のＸＭＬ文書をマージし、ラッピングする機能、
からなるミドル層又はクライアント層。」
　
（３）．対比
　本願補正発明と引用例記載の発明とを対比すると、次のことがいえる。
　
　
（ア）引用例記載の発明における「Ｗｅｂで公開されている、ホテルごとにさまざまなデータベース・システムを用いて管理されている情報を取り出」すことは、本願補正発明における「インターネット上の１つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得」することに相当する。
　
（イ）引用例記載の発明における「ミドル層又はクライアント層」と、本願補正発明における「データ処理装置」とは「データ処理を行うもの」という点で共通のものである。
　
（ウ）引用例記載の発明における「ＣＳＶ形式等のデータ」は、本願補正発明における「データベース」の「データ」に相当する。
　
（エ）引用例記載の発明における「オリジナルのＸＭＬ文書」は、本願補正発明における「マークアップ言語で記述された種々のデータ」に相当する。
　
（オ）引用例記載の発明における「共通形式のＸＭＬ形式へ変換する」ことは、「共通形式」へ「変換する」ことが本願補正発明における「正規化」にほかならないことから、本願補正発明における「正規化して共通の構造の複数のデータに変換する」ことに相当するといえる。
　
（カ）引用例記載の発明における「共通の形式で表示し」は、本願補正発明における「統一的に表示し」に相当する。
　
（キ）引用例記載の発明における「データの操作や比較など」は、異なるデータベース・システムから取り出したデータを横断的にデータを比較する等、別目的で利用することであるので、本願補正発明における「再利用」に相当するといえる。
　
（ク）引用例記載の発明における「複数の変換された共通形式のＸＭＬ文書」と、本願補正発明における「共通の構造の複数のデータ・オブジェクト」とは、「共通の構造の複数のデータ」という点で共通のものである。
　
（ケ）引用例記載の発明における「マージし、ラッピングする」は、本願補正発明における「データ・オブジェクト化」が新しいオブジェクトとしての体裁を整えることであることから、本願補正発明における「組み合わせてデータ化する」という点で共通のものである。
　
　上記（ア）〜（ケ）の事項を踏まえると、本願補正発明と引用例記載の発明とは、次の点で一致し、また、相違するものと認められる。
　
（一致点）
「インターネット上の１つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得して統一的に表示し、
　再利用するためにデータ処理を行うものであって、
　データベース、またはマークアップ言語で記述された種々のデータを取得し、一時的に格納する機能と、
　前記データベース、またはマークアップ言語で記述された種々のデータを正規化して共通の構造の複数のデータに変換する機能と、
　共通の構造のデータを特定の形式で表示する機能と、
　複数の変換された共通の構造のデータを組み合わせてデータ化する機能、
からなるデータ処理を行うもの。」
　
（相違点）
　相違点１：「データ処理を行うもの」について、本願補正発明においては「クライアントコンピュータ上で動作するデータ処理装置」であるのに対して、引用例記載の発明は「データ処理を」「ミドル層」で行うものであって「クライアントコンピュータ上で動作するデータ処理装置」で行われるとは特にされていない点。
　
　相違点２：「共通の構造のデータ」及びこれらを「組み合わせてデータ化」したデータについて、本願補正発明においては、「データ・オブジェクト」であるのに対して、引用例記載の発明では、そのようになっていない点。
　
　相違点３：「複数の変換された共通の構造のデータを組み合わせてデータ化する機能」について、本願補正発明においては、「共通の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する」のに対して、引用例記載の発明では、そのような構成について特定されていない点。
　
　相違点４：「共通の構造のデータを特定の形式で表示する機能」について、本願補正発明においては「ユーザの指定に従って、表示箇所を変更する機能を有」しているのに対して、引用例記載の発明では、そのような構成について特定されていない点。
　
　相違点５：各「機能」について、本願補正発明においては、「オブジェクト」であるのに対して、引用例記載の発明では、そのような構成について特定されていない点。
　
（４）当審の判断
　そこで、上記相違点１〜３について検討する。
　
（相違点１について）
　ｐｒｏｘｙサーバ等、Ｗｅｂブラウザと外部のサーバとの中間に位置するサーバ、すなわち、ミドル層で行う処理をクライアントに設けることは、広く行われていることにすぎず、引用例記載の「ミドル層」における処理を「クライアントコンピュータ上で動作するデータ処理装置」上で動作するよう構成することは、当業者が適宜になし得ることである。
　よって、相違点１は、格別のものではない。
　
　（相違点２について）
　データをオブジェクトとして扱うよう実装することは、当業者が適宜になし得ることである。
　よって、相違点２は、格別のものではない。
　
（相違点３について）
　オブジェクトを直接操作することによって、オブジェクトどうしを関連づけることは、本願明細書において従来の技術として示されている米国特許第５７５４８０８号等に記載させているように周知の技術である。また、オブジェクト同士を組み合わせた結果が、新たなオブジェクトになることは明らかである。
　してみると、表示された引用例記載の「データ」を、組み合わせて別のオブジェクトとすることは、当業者が容易に想到し得るものである。
　よって、相違点３は、格別のものではない。
　
（相違点４について）
　ユーザの指定に従って、オブジェクトの表示箇所を変更するよう構成することは、当業者が適宜になし得ることである。
　よって、相違点４は、格別のものではない。
　
（相違点５について）
　機能をオブジェクトとして実装することは、当業者が適宜になし得ることである。
　よって、相違点５は、特段のものではない。
　
（本願補正発明の作用効果について）
　そして、本願補正発明の構成によってもたらされる効果も、引用例記載の発明から当業者が容易に予測できるものであって、格別のものとはいえない。
　
　したがって、本願補正発明は、引用例記載の発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
　
（５）むすび
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　
　
３．補正却下の決定を踏まえた検討
（１）本願発明
　平成２３年１月３１日付けの手続補正は、上記のとおり却下されたので、本願の請求項１ないし８に係る発明は、平成２２年４月７日付け手続補正書の特許請求の範囲の請求項１ないし８に記載された事項により特定されるものであるところ、その請求項１に係る発明は、平成２２年４月７日付け手続補正書によって補正された特許請求の範囲の記載からみて、その請求項１に記載された事項により特定される、次のとおりのものと認める。（以下、「本願発明」という。）
　
「【請求項１】　インターネット上の１つ以上のサーバー上に存在するデータベース、またはマークアップ言語で記述された種々のデータを取得して統一的に表示し、再利用するためにクライアントコンピュータ上で動作するデータ処理装置であって、
　前記データベース、またはマークアップ言語で記述された種々のデータをアクセスし、
取得し一時的に格納する第１のオブジェクトと、
　前記取得し一時的に格納された各データを特定の構造の複数のデータ・オブジェクトに変換する第２のオブジェクトと、
　前記特定の構造のデータ・オブジェクトを特定の形式で表示すると共に、ユーザの指定に従って、表示箇所を変更する機能を有する第３のオブジェクトと、
　前記特定の構造の複数のデータ・オブジェクトから表示箇所のデータを取得し、組み合わせてデータ・オブジェクト化する第４のオブジェクトと、
からなるオブジェクト指向システムによるデータ処理装置。」
　
　
（２）引用例及び周知例
　これに対して、原査定の拒絶の理由に引用された引用例とその記載事項は、上記２．（２）に示したとおりである。
　
（３）本願発明は、上記２．で検討した本願補正発明における
「前記取得し一時的に格納された各データを
正規化して共通の構造
「前記
共通の構造
「前記
共通の構造
　そうすると、本願発明の構成要素を全て含み、さらに特定の限定を施したに相当する本願補正発明が、上記２．（４）に記載したとおり、引用例記載の発明に基いて、当業者が容易に発明することができたものであることから、上記限定を省いて上位概念化した本願発明は、同様に引用例記載の発明に基いて、当業者が容易に発明することができたものである。
　
　
　
４．むすび
　以上のとおり、本願発明は、引用例記載の発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。