【事件の表示】
　特願２００５−５０９０９７「アプリケーションプログラムをアイテムベースのストレージプラットフォームとインターフェースするためのシステムおよび方法」拒絶査定不服審判事件〔平成１７年　３月３１日国際公開、ＷＯ２００５／０２９３６３、平成１９年　８月　２日国内公表、特表２００７−５２１５３３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯の概要 
　本願は、平成１５年８月２１日を国際出願日とする出願であって、平成２１年９月１０日付けで拒絶査定がなされ、平成２２年１月１５日に拒絶査定不服審判の請求がなされるとともに手続補正書が提出されたものである。
　また、その後、当審から平成２４年１月１９日付けで拒絶理由を通知し（以下、この通知を「当審拒絶理由通知」という。）、同年４月２３日付けで意見書と手続補正書が提出されたものである。 
　
　なお、上記当審拒絶理由通知は、以下のような事情（平成２４年１月１９日作成の応対記録参照）の下にしたものである。
（１）本願には、明細書の記載が全７３３段落と大部に及んでいる上、特許請求の範囲に記載された発明の理解には不必要と思われる事項も多数混在している、難解な記載も多い、といった事情があり、当審には本願発明の正確な理解が困難であったため、当審は、代理人に対し、面談による技術説明を要請した。
（２）しかしながら、代理人からは、「面談による技術説明の要請には応じられない。疑問点があれば、書面による拒絶理由通知で指摘して欲しい。」旨の回答があった。
　
２．当審拒絶理由通知の対象となった特許請求の範囲の請求項１の記載
　当審拒絶理由通知の対象となった特許請求の範囲の請求項１の記載は、平成２２年１月１５日付けの手続補正書の【補正の内容】の【請求項１】の欄に記載された以下のとおりのものである。
「　　【請求項１】
　コンピュータプログラムが格納されたメモリに結合されたプロセッサを含むコンピュータシステムであって、前記コンピュータプログラムが前記プロセッサによって実行されると、
　アイテム、要素、および関係に関して定義するデータであって、前記アイテムは、前記コンピュータシステム内に格納可能なデータのユニットであり、１つまたは複数の要素を含み、前記要素は、１つまたは複数のフィールドを含む型のインスタンスであり、前記関係は、少なくとも２つのアイテムの間のリンクであるデータを格納し、
　異なる型のアイテム、要素、および関係を定義するスキーマの集合を供給し、
　前記スキーマの集合で定義されている前記異なる型のアイテム、要素、および関係のそれぞれに対するクラスを生成する
ように構成されたことを特徴とするコンピュータシステム。」
　
３．当審拒絶理由通知で通知した、上記請求項１の記載に関する拒絶理由は、以下のとおりである。
「　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
 　 
 　　　　　　　　　　　　　　　　　記 
 　 
（１）以下の理由で、請求項１でいう「アイテム、要素、および関係に関して定義するデータであって、前記アイテムは、前記コンピュータシステム内に格納可能なデータのユニットであり、１つまたは複数の要素を含み、前記要素は、１つまたは複数のフィールドを含む型のインスタンスであり、前記関係は、少なくとも２つのアイテムの間のリンクであるデータ」に包含される具体的事物の範囲が不明確である。 
 ア．上記記載中の「アイテム」が具合的にどのようにして得られるどのようなものを指しているのかが不明確である。すなわち、上記「アイテム」は、上記記載や本願明細書の段落【００４１】の記載等を参酌すると、「コンピュータシステム内に存在する多様なデータを格納手段に格納する際の格納単位」といった程度の意味であろうと解され、本願明細書で言及されている従来の「ファイル」自体も、該ファイル内の「１まとまりのデータ」も、共に該「アイテム」に含まれるのではないかと思われるが、もしそうだとすると、その格納単位ともいうべきアイテムが、コンピュータシステム内に存在する多様なデータからどのようにして定められるものなのか（人やアプリケーションプログラムがコンピュータシステム内に存在する多様なデータの中から特定の部分を範囲指定すること等により定められるものなのか、それ以外の何らかの方法で定められるものなのか）が不明である。該「アイテム」が上記のようなものではないとすると、具体的にどのようなものが該「アイテム」の概念に含まれ、それはどのようにして得られるものなのか、が不明確である。 
 イ．上記記載中の「アイテム、要素、および関係に関して定義する」なる記載が、「アイテム」、「要素」、「関係」のそれぞれに関して具体的にどのような事項を定義することを意味しているのか、また、それらを定義するデータは、どのようにして得られるデータなのか、が不明である。 
 ウ．上記記載中の「１つまたは複数のフィールドを含む型のインスタンス」が具体的にどのような事物を表しているのかが不明確である。 
 　 
（２）以下の理由で、請求項１でいう「異なる型のアイテム、要素、および関係を定義するスキーマの集合」に包含される具体的事物の範囲が不明確である。 
ア．上記記載中の「異なる」が、何と何が異なることを意味しているのかが不明である。 
イ．上記記載中の「スキーマの集合」が具体的にどのような事物を表しているのかが不明確である。また、該「スキーマの集合」は「異なる型のアイテム、要素、および関係を定義する」ものとされているが、それと上記（１）で指摘した「アイテム、要素、および関係に関して定義するデータ」との異同も不明である。
　
（３）請求項１でいう「供給し」が、どこからどこに供給することを意味しているのかが不明である。 
　
（４）請求項１でいう「前記スキーマの集合で定義されている前記異なる型のアイテム、要素、および関係のそれぞれ」とそれに対するものとされている「クラス」とが相互にどのような関係にあり、該「クラス」が具体的にどのような事物を表しているのかが不明確である。 
 　 
 　よって、請求項１に係る発明は明確でない。」
　
４．当審拒絶理由通知を受けて補正された請求項１の記載とそれに対応する意見書の主張
（１）補正された請求項１の記載（平成２４年１月２４日付けの手続補正書の【補正の内容】の【請求項１】の欄の記載）は、以下のとおりである。
「　　【請求項１】
　コンピュータプログラムが格納されたメモリに結合されたプロセッサを含むコンピュータシステムであって、前記コンピュータプログラムが前記プロセッサによって実行されると、
　
それぞれが、型の異なる
を
スキーマの集合
基本
スキーマの集合
　
アプリケーションプログラミングインターフェースの一部として、
し、アプリケーションが、前記スキーマの集合で定義される前記アイテム、要素、および関係にアクセスすることを可能に
ように構成されたことを特徴とするコンピュータシステム。」
　
（２）上記補正された請求項１の記載に対応する意見書（平成２４年１月２４日付けの意見書）の主張は以下のとおりである。
「【意見の内容】
１．はじめに
　審判官殿は、本出願の特許請求の範囲の記載が、特許法第３６条第６項第２号に規定する要件を満たしていないと認定されました。
　そこで、審判請求人は、かかる拒絶理由に鑑み、別途提出の手続補正書により特許請求の範囲を補正するとともに、以下に拒絶理由が解消する理由を申し述べる次第です。
２．補正後の本願発明について
　補正後の請求項１に係る発明は、本意見書と同日付けで提出した手続補正書に記載されているように、
「　コンピュータプログラムが格納されたメモリに結合されたプロセッサを含むコンピュータシステムであって、前記コンピュータプログラムが前記プロセッサによって実行されると、
　
それぞれが、型の異なる
を
スキーマの集合
基本
スキーマの集合
　
アプリケーションプログラミングインターフェースの一部として、
し、アプリケーションが、前記スキーマの集合で定義される前記アイテム、要素、および関係にアクセスすることを可能に
ように構成されたことを特徴とするコンピュータシステム。」です。
　上記補正は、明細書段落番号［００４５］−［００４７］、［００６０］、［００６１］等の記載に基づくものです。
３．拒絶理由の解消について
　１．請求項１について
　（１）請求項１の「アイテム、要素、および関係に関して定義するデータであって、前記アイテムは、前記コンピュータシステム内に格納可能なデータのユニットであり、１つまたは複数の要素を含み、前記要素は、１つまたは複数のフィールドを含む型のインスタンスであり、前記関係は、少なくとも２つのアイテムの間のリンクであるデータ」は、「
それぞれが、型の異なる
を
スキーマの集合
基本
スキーマの集合
　ア．上記記載の「アイテム」とは、明細書段落番号［００４１］、［００５９］に記載されているように、単純ファイルとは異なり、ハードウェア／ソフトウェアインターフェースシステムシェルによりエンドユーザに対し公開されるすべてのオブジェクトにわたって一般的にサポートされるプロパティの基本集合を持つオブジェクトであるハードウェア／ソフトウェアインターフェースシステムにアクセスできる格納可能情報のユニットです。よって、該「アイテム」という記載は明確であるものと思量いたします。
　イ．上記記載の「アイテム、要素、および関係を定義する」とは、「アイテム」、「要素」、「関係」のそれぞれに関して「型」などを定義することを意味し、それらは、スキーマによって定義されることを明確にしました。
　ウ．上記記載中の「１つまたは複数のフィールドを含む型のインスタンス」という記載は削除いたしました。
　（２）請求項１の「異なる型のアイテム、要素、および関係を定義するスキーマの集合を供給し」という記載は削除し、「アイテム、要素、および関係に関して定義するデータ」という記載を、「
それぞれが、型の異なる
を
スキーマの集合
　（３）請求項１の「供給し」という記載は削除いたしました。
　よって、請求項１に係る発明は明確であると思量いたします。」
　
５．上記１．〜４．の経緯を踏まえた、補正後の請求項１の記載についての当審の判断
　当審は、上記補正後の請求項１の記載は、依然として特許法第３６条第６項第２号に規定する要件を満たしているとはいえないと判断する。理由は以下のとおりである。
（１）特許請求の範囲の記載は、これに基づいて新規性・進歩性等の特許要件の判断がなされ、これに基づいて特許発明の技術的範囲が定められるという点において重要な意義を有するものであり、一の請求項から発明が明確に把握されること、換言すれば、一の請求項から技術的課題を解決するために必要な事項を明確に特定できること、が必要であるというべきである。
（２）これを本願の請求項１についてみると、本願明細書の【発明が解決しようとする課題】の欄（段落【０００９】）等の記載によれば、本願の請求項１に係る発明（以下、「本願発明」という。）は、「コンピュータシステム内のデータの全ての型を編成し、検索し、共有する能力を高めたストレージプラットフォーム」を実現することを技術的課題としているものと解され、これを技術常識に照らしてさらに善解すれば、「コンピュータシステム内の複数のデータの型が相互に異なっていても、アプリケーション等が該複数のデータにアクセスできるようなストレージプラットフォーム」（以下、「課題解決プラットフォーム」と呼ぶ。）を実現することといった程度のことを技術的課題としているものと解される。したがって、本願の請求項１においては、その記載から、上記課題解決プラットフォームを実現するために必要な事項を明確に特定できる必要があるというべきである。
（３）そこで、上記補正後の請求項１の記載が、上記課題解決プラットフォームを実現するために必要な事項を明確に特定し得ているか否かについて検討するに、以下の事情に鑑みると、上記補正後の請求項１の記載は、上記課題解決プラットフォームを実現するために必要な事項を明確に特定し得ているとはいえないというべきである。
ア．上記補正後の請求項１の「アプリケーションプログラミングインターフェースの一部として、前記スキーマの集合で定義されている前記異なる型のアイテム、要素、および関係のそれぞれに対するクラスを生成し、アプリケーションが、前記スキーマの集合で定義される前記アイテム、要素、および関係にアクセスすることを可能にする」という記載（以下、「記載Ａ」という。）は、そこに「アプリケーションプログラミングインターフェースの一部として」という記載があることと、そこでいう「前記スキーマの集合」が同請求項１中で「それぞれが、型の異なるアイテム、要素、および関係を定義するスキーマの集合」とされていること、等の事情に鑑みると、本願発明のコンピュータシステムが、「前記スキーマの集合で定義されている前記異なる型のアイテム、要素、および関係のそれぞれに対するクラスを生成」することで、上記課題解決プラットフォームを実現するものであることを規定しているものと推察される。
イ．そして、上記記載Ａと上記補正後の請求項１のそれ以外の記載内容に照らせば、上記「前記スキーマの集合で定義されている前記異なる型のアイテム、要素、および関係のそれぞれに対するクラスを生成」することが、上記課題解決プラットフォームを実現するために必要な事項の核心であると考えられるが、上記補正後の請求項１には、該「前記スキーマの集合で定義されている前記異なる型のアイテム、要素、および関係のそれぞれに対するクラスを生成」することに関しては、単に「前記スキーマの集合で定義されている前記異なる型のアイテム、要素、および関係のそれぞれに対するクラスを生成」という記載があるだけで、その内容をより具体的に規定する記載はない。
ウ．したがって、上記記載Ａ中の上記「前記スキーマの集合で定義されている前記異なる型のアイテム、要素、および関係のそれぞれに対するクラスを生成」という記載（以下、「記載Ｂ」という。）をもって、「上記課題解決プラットフォームを実現するために必要な事項を明確に特定するもの」ということができなければ、上記補正後の請求項１の記載は、上記課題解決プラットフォームを実現するために必要な事項を明確に特定し得ているとはいえない。
エ．そこで、上記記載Ｂについて検討するに、以下の事情を勘案すると、該記載Ｂをもって「上記課題解決プラットフォームを実現するために必要な事項を明確に特定するもの」ということはできないというべきである。
（ア）「クラス」という語は、本願発明が属すると思われる技術分野の技術常識に照らせば、「オブジェクト指向プログラミング言語における、特定の機能や役割をもたせたプログラム。」ないしは「オブジェクト指向プログラミングにおいて、データとその操作手順であるメソッドをまとめたオブジェクトの雛型を定義したもの。」といった程度の意味に解されるので、上記記載Ｂは、「前記スキーマの集合で定義されている前記異なる型のアイテム、要素、および関係のそれぞれに対する特定の機能や役割をもったプログラムを生成」といった程度の事項を規定した記載と解されるが、そこでいう「対する」がどのような意味における「対する」で、どのような技術的事項を表しているのかは、その文言のみからは不明であり、上記記載Ｂのみからは、上記課題解決プラットフォームを実現するために必要な事項が何なのかを理解することはできない。
（イ）発明の詳細な説明の記載、特に上記記載Ｂでいう「クラスを生成」に関する記載箇所であろうと推察される明細書の段落【０４６３】〜【０４８１】の記載や、それに関連すると思われる箇所の記載を参酌しても、それらの箇所の記載から「クラスがそれぞれのスキーマについて生成される」ことや「スキーマ内の型の階層がクラスの階層に反映される」といった程度のことまでは、読み取ることができるものの、上記記載Ｂでいう「対する」がどのような意味における「対する」で、どのような技術的事項を表しているのかや、上記課題解決プラットフォームを実現するために必要な事項が何なのか、といった事項までを理解することはできない。
　
　なお、上記記載Ｂが表す技術的事項が不明確であることは、上記「３．」に転記した当審拒絶理由通知の「記」の「（４）」で指摘したことであり、審判請求人には釈明の機会が十分に与えられていたにもかかわらず、上記補正後の請求項１の記載や上記「４．」に転記した意見書の内容から明らかなように、審判請求人は何らの釈明も行っていないものである。
　
５．むすび 
　以上のとおり、上記補正後の請求項１の記載は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　したがって、本願は、他の拒絶の理由について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。