2017-016839

特願２０１７－　５０９９７「データ管理装置、データ管理方法、およびプログラム」拒絶査定不服審判事件〔平成３０年１０月　４日出願公開、特開２０１８－１５６２３３、請求項の数（７）〕について、次のとおり審決する。

【結　論】 原査定を取り消す。 本願の発明は、特許すべきものとする。

【理　由】 第１　手続の経緯 本願は，平成２９年３月１６日を出願日とする出願であって，平成２９年５月２５日付けで拒絶理由通知がされ，平成２９年７月３１日に意見書が提出されるとともに手続補正がされ，平成２９年８月８日付けで拒絶査定（原査定）がされ，これに対し，平成２９年１１月１３日に拒絶査定不服審判の請求がされると同時に手続補正がされ，平成３０年８月１０日付けで当審より拒絶理由通知（以下，「当審拒絶理由通知１」という。）がされ，平成３０年１０月３日に意見書が提出されるとともに手続補正がされ，平成３０年１１月１４日付けで当審より拒絶理由通知（以下，「当審拒絶理由通知２」という。）がされ，平成３０年１１月２８日に意見書が提出されるとともに手続補正がされたものである。 第２　原査定の概要 原査定（平成２９年８月８日付け拒絶査定）の概要は次のとおりである。 本願請求項１－８に係る発明は，以下の引用文献１ないし５に基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 引用文献等一覧 １．加藤 慶信　外４名，軽い！速い！ビッグデータ　分析システムの作り方，日経ＳＹＳＴＥＭＳ，日本，日経ＢＰ社 Nikkei Business Publications,Inc．，２０１３年９月２６日，第246号／2013年10月号，p.42-p.59 ２．杉山 暢彦　外５名，ＮｏＳＱＬデータベースＣａｓｓａｎｄｒａのＸＭＬ仮想化システム，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，２０１３年２月２８日，第112巻／第466号，p.17-p.22 ３．特開２０１４－１９１５９３号公報 ４．特表２０１６－５１９８１０号公報 ５．特開２０１５－１８５１０４号公報 第３　当審拒絶理由の概要 当審でなされた拒絶理由の概要は次のとおりである。 １．当審拒絶理由通知１ （１）本願出願は，請求項１－７に係る特許請求の範囲の記載が，特許法第３６条第６項第２号に規定する要件を満たしていない。 （２）本願請求項１－７に係る発明は，以下の引用文献ＡないしＤに基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 引用文献等一覧 Ａ．特開２０１４－１９１５９３号公報（原査定時の引用文献３） Ｂ．特開２００５－７１０５０号公報 Ｃ．杉山　暢彦　外５名，ＮｏＳＱＬデータベースＣａｓｓａｎｄｒａのＸＭＬ仮想化システム，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，２０１３年２月２８日，第112巻／第466号，p.17-p.22（原査定時の引用文献２） Ｄ．特表２０１６－５１９８１０号公報（原査定時の引用文献４） ２．当審拒絶理由通知２ （１）本願出願は，請求項１－７に係る特許請求の範囲の記載が，特許法第３６条第６項第２号に規定する要件を満たしていない。 第４　本願発明 本願請求項１－７に係る発明（以下，それぞれ「本願発明１」－「本願発明７」という。）は，平成３０年１１月２８日付けの手続補正で補正された特許請求の範囲の請求項１－７に記載された事項により特定される発明であり，以下のとおりの発明である。 「　【請求項１】 入力されたデータ格納要求を解釈し，多次元空間での木構造を，json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式のオブジェクトに変換する解釈部と， 前記オブジェクトに変換されたデータを，前記変換されたデータとは別のデータ構造であって，予め配列が確保されていない列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させると共に，前記オブジェクトに含まれる，前記列指向型のデータ構造で管理されるデータを行方向に読み出し可能にするための参照情報を前記記憶部に記憶させる変換部と， を備えるデータ管理装置。 【請求項２】 前記列指向型のデータ構造は，前記データ格納要求に含まれるレコードに含まれるデータが，データ項目ごとにひとまとまりの論理構造でまとめられたデータ構造であり， 前記変換部は，前記データ格納要求に含まれるデータ項目が，前記列指向型のデータ構造に設定されていないデータ項目である場合，新たな列を追加する， 請求項１記載のデータ管理装置。 【請求項３】 前記列指向型のデータ構造で管理されるデータを，入力されたデータ要求に含まれるデータ項目ごとに前記記憶部から読み出して出力するデータ利用者インターフェースを更に備える， 請求項１または２記載のデータ管理装置。 【請求項４】 前記データ利用者インターフェースは，指定されたデータ項目を含まないレコードに関しては，当該データ項目に対応するデータを，該当するデータが存在しないことを示す任意の形態のデータで埋める， 請求項３記載のデータ管理装置。 【請求項５】 前記データ利用者インターフェースは，指定されたデータ項目が，前記列指向型のデータ構造に設定されていないデータ項目である場合，当該データ項目についてのデータを全て，該当するデータが存在しないことを示す任意の形態のデータで埋める， 請求項３または４記載のデータ管理装置。 【請求項６】 コンピュータが， 入力されたデータ格納要求を解釈し，多次元空間での木構造を，json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式のオブジェクトに変換し， 前記オブジェクトに変換されたデータを，前記変換されたデータとは別のデータ構造であって，予め配列が確保されていない列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させると共に，前記オブジェクトに含まれる，前記列指向型のデータ構造で管理されるデータを行方向に読み出し可能にするための参照情報を前記記憶部に記憶させる， データ管理方法。 【請求項７】 コンピュータに， 入力されたデータ格納要求を解釈し，多次元空間での木構造を，json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式のオブジェクトに変換させ， 前記オブジェクトに変換されたデータを，前記変換されたデータとは別のデータ構造であって，予め配列が確保されていない列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させると共に，前記オブジェクトに含まれる，前記列指向型のデータ構造で管理されるデータを行方向に読み出し可能にするための参照情報を前記記憶部に記憶させる処理を行わせる， プログラム。」 第５　引用文献，引用発明等 １．引用文献１について 原査定の拒絶の理由に引用された引用文献１（加藤 慶信　外４名，軽い！速い！ビッグデータ　分析システムの作り方，日経ＳＹＳＴＥＭＳ，日本，日経ＢＰ社 Nikkei Business Publications,Inc．，２０１３年９月２６日，第246号／2013年10月号，p.42-p.59）には，図面とともに次の事項が記載されている。（下線は当審により付与。以下同様。） Ａ　「Ｔｒｅａｓｕｒｅ Ｄａｔａやｓｐｌｕｎｋにログを送るのは専用ソフト「Ｆｌｕｅｎｔｄ」である。」（第４５頁中欄２～３行） Ｂ　「吉田氏らは代替案を探し，ログ収集専用ソフト（ＦｌｕｅｎｔｄやＦｌｕｍｅ ＮＧなどがある）に注目した。選んだのは「Ｆｌｕｅｎｔｄ」である。Ｗｅｂシステムから出力されるログを非同期で集めるので，Ｗｅｂシステム側への性能面での影響がなくなる。それだけでなく，オープンソースで，かつ，プラグイン形式で機能拡張できる点を高く評価した。これは二つめログの特性「形式がバラバラ」への対策として重要である。 Ｆｌｕｅｎｔｄのプラグインサイト（http://fluentd.org/plugin/)を見ると，さまざまなプラグインが公開されていることが分かる。ログの読み込みに役立つプラグインがあるほか，例えばログをドキュメント指向データベースのＭｏｎｇｏＤＢに保管したい場合，ＭｏｎｇｏＤＢに書き込むモジュールが必要になるが，そうしたモジュールはプラグインとして公開されている。自社で使いたいプラグインがあれば，既に開発されている可能性が高い。そうしたプラグインを利用できるのが，Ｆｌｕｅｎｔｄの最大のメリットだ。吉田氏らはＦｌｕｅｎｔｄでログ収集基盤を構築し，以前よりも詳細なデータ収集が可能になったという。」（第４９頁左欄１７行～中欄１７行） Ｃ　「Ｔｒｅａｓｕｒｅ Ｄａｔａ Ｐｌａｔｆｏｒｍはビックデータの分析基盤を提供するクラウドサービスである。大量データを収集して保管し，そのデータに対してクエリー処理を行う機能を備える。目指しているのは，エンジニアがより効果的に時間を使えるようにすることだ。 ビックデータ分析では膨大なデータを管理するだけでも手間がかかる。また，膨大なデータを短時間で分析する方法の一つとしてＨａｄｏｏｐがよく利用されるが，Ｈａｄｏｏｐの運用・保守は容易ではない。つまり，本来やりたい「データ分析」以外に多くの時間が必要なのだ。Ｔｒｅａｓｕｒｅ Ｄａｔａのサービスを使えば，そうした手間を減らせる。」（第５２頁左欄１～１６行） Ｄ　「Ｔｒｅａｓｕｒｅ Ｄａｔａの三つの特徴 Ｔｒｅａｓｕｒｅ Ｄａｔａの特徴は，「スキーマレスなデータモデル」「Ｈａｄｏｏｐのスペシャリスト不要」「スモールスタートが可能で，月ごとの課金」の３点にまとめられる（図１）。順番に説明する。 スキーマレスなデータモデル 一つめの特徴は，データモデルがスキーマレスであることだ。Ｔｒｅａｓｕｒｅ Ｄａｔａは基本的なデータ構造としてＪＳＯＮ（Ｊａｖａｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式を採用している。データ型をあらかじめ設定する必要がなく，任意のカラムを加えたり削ったりできる。 ・・・（中略）・・・ Ｈａｄｏｏｐのスペシャリスト不要 Ｔｒｅａｓｕｒｅ Ｄａｔａを利用するエンジニアに求められる基本的な知識は，ＪＳＯＮとＳＱＬである。Ｔｒｅａｓｕｒｅ ＤａｔａにアップロードするデータはＪＳＯＮ形式なので，アプリケーションログなどをＪＳＯＮ形式に変換する必要があり，ＪＳＯＮの知識は欠かせない。 ＪＳＯＮ形式でアップロードしたデータはＴｒｅａｓｕｒｅ Ｄａｔａ内部ではカラム型データストアに格納される。そのデータ量は膨大なので，データを取り出す処理はＨａｄｏｏｐを使って実行している。ただし，Ｔｒｅａｓｕｒｅ Ｄａｔａを利用するエンジニアはＨａｄｏｏｐ処理を意識する必要はない。ＨｉｖｅやＰｉｇなどのフレームワークを利用できるからだ。この「Ｈａｄｏｏｐのスペシャリスト不要」というのは，Ｔｒｅａｓｕｒｅ Ｄａｔａの二つめの特徴である。」（第５２頁左欄１７行～第５３頁左欄１７行） Ｅ　「スモールスタートが可能で，月ごとの課金 オンプレミスでビックデータ分析システムを構築しようとすると，大規模な初期投資をすることが前提となってしまう。数千万円～数億円規模の予算を要することも少なくない。Ｈａｄｏｏｐのようなオープンソースソフトを使えばハードウェア以外の初期投資を抑えることができるが，エンジニアの工数を数週間から数ヶ月にわたって使うことになり，費用対効果の観点から望ましい選択とはいえない。 Ｔｒｅａｓｕｒｅ Ｄａｔａはクラウドサービスで，一ヵ月単位の定額サブスクリプションモデルを採用している。無料プランがあるので小規模データで一定期間試した後，本番で有料プランにアップグレードすることが可能だ。月ごとの課金モデルであるため，長期間の契約に縛られることも，巨額の初期投資に頭を抱える必要もない。データ基盤の監視・運用はＴｒｅａｓｕｒｅ Ｄａｔａの専門技術者が行うので，ユーザー企業のエンジニアはデータ分析に集中できる。 ＲＥＳＴ ＡＰＩを備える Ｔｒｅａｓｕｒｅ Ｄａｔａの基盤を構成する主要な要素は，データを保管する「カラム型データストア」と，クエリー処理を実行するＨａｄｏｏｐベースの「クエリー処理エンジン」である（図２）。さらにユーザーであるエンジニア側にインストールされる要素として，ＪＳＯＮ形式のログを収集する「ｔｄ－ａｇｅｎｔ」，クエリーを送信する「ｔｄ－ｃｏｍｍａｎｄ」などがある。 ｔｄ－ａｇｅｎｔの実体はログ収集ソフトＦｌｕｅｎｔｄである。クエリーとその結果はｔｄ－ｃｏｍｍａｎｄからだけではなく，ＢＩソフトなどからＲＥＳＴ ＡＰＩ経由で送受信できる。カラム型データストアは，一般的なＲＤＢＭＳ（行指向データベース）より分析処理に向いている。特定のカラムを集計する際，一般的なＲＤＢＭＳはレコードすべてをメモリーに読み込んで計算する必要があるが，カラム型なら特定のカラムだけをメモリーに読み込めばよく，その分，高速に計算できるのだ。」（第５３頁左欄１８行～右欄２行） Ｆ　「 図２」 Ｇ　上記Ｃ及びＦの記載から，引用文献１には，「ビックデータの分析基盤を提供するクラウドサービスであるＴｒｅａｓｕｒｅ Ｄａｔａ Ｐｌａｔｆｏｒｍを用いたビックデータ分析システム」を構築する，ことが記載されているといえ， 上記「Ｔｒｅａｓｕｒｅ Ｄａｔａ」について，上記Ｄの「Ｔｒｅａｓｕｒｅ Ｄａｔａは基本的なデータ構造としてＪＳＯＮ（Ｊａｖａｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式を採用している。データ型をあらかじめ設定する必要がなく」との記載，上記Ｅの「Ｔｒｅａｓｕｒｅ Ｄａｔａの基盤を構成する主要な要素は，データを保管する「カラム型データストア」と，クエリー処理を実行するＨａｄｏｏｐベースの「クエリー処理エンジン」である（図２）。さらにユーザーであるエンジニア側にインストールされる要素として，ＪＳＯＮ形式のログを収集する「ｔｄ－ａｇｅｎｔ」，クエリーを送信する「ｔｄ－ｃｏｍｍａｎｄ」などがある。ｔｄ－ａｇｅｎｔの実体はログ収集ソフトＦｌｕｅｎｔｄである。」との記載から，「Ｔｒｅａｓｕｒｅ Ｄａｔａは，基本的なデータ構造としてデータ型をあらかじめ設定する必要がないＪＳＯＮ（Ｊａｖａｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式を採用しており，Ｔｒｅａｓｕｒｅ Ｄａｔａの基盤を構成する主要な要素は，データを保管するカラム型データストアと，クエリー処理を実行するＨａｄｏｏｐベースのクエリー処理エンジン，であり，さらに，ユーザーであるエンジニア側にインストールされる要素として，ＪＳＯＮ形式のログを収集するログ収集ソフトＦｌｕｅｎｔｄである「ｔｄ－ａｇｅｎｔ」，クエリーを送信する「ｔｄ－ｃｏｍｍａｎｄ」があ」ることが読み取れ， また，上記「ＪＳＯＮ形式のログを収集するログ収集ソフトＦｌｕｅｎｔｄ」について，上記Ａの「Ｔｒｅａｓｕｒｅ Ｄａｔａやｓｐｌｕｎｋにログを送るのは専用ソフト「Ｆｌｕｅｎｔｄ」である。」との記載，上記Ｂの「選んだのは「Ｆｌｕｅｎｔｄ」である。・・・それだけでなく，オープンソースで，かつ，プラグイン形式で機能拡張できる点を高く評価した。これは二つめログの特性「形式がバラバラ」への対策として重要である。」との記載から，「上記ログ収集ソフトＦｌｕｅｎｔｄは，オープンソースで，かつ，プラグイン形式で機能拡張できることから，形式がバラバラのログデータに対応できるものであ」ることが読み取れ， また，上記収集するログデータについて，上記Ｄの「Ｔｒｅａｓｕｒｅ ＤａｔａにアップロードするデータはＪＳＯＮ形式なので，アプリケーションログなどをＪＳＯＮ形式に変換する必要があり」との記載から，「収集したログデータを，Ｔｒｅａｓｕｒｅ ＤａｔａにアップロードするためにＪＳＯＮ形式に変換」することが読み取れ， また，上記「ＪＳＯＮ形式」でのデータの「カラム型データストア」への保管及び取り出しについて，上記Ｄの「ＪＳＯＮ形式でアップロードしたデータはＴｒｅａｓｕｒｅ Ｄａｔａ内部ではカラム型データストアに格納される。そのデータ量は膨大なので，データを取り出す処理はＨａｄｏｏｐを使って実行している。」との記載から，「ＪＳＯＮ形式でアップロードしたデータはＴｒｅａｓｕｒｅ Ｄａｔａ内部ではカラム型データストアに格納され，データを取り出す処理はＨａｄｏｏｐを使って実行して」いることが読み取れ， また，上記「カラム型データストア」について，上記Ｅの「カラム型データストアは，一般的なＲＤＢＭＳ（行指向データベース）より分析処理に向いている。特定のカラムを集計する際，一般的なＲＤＢＭＳはレコードすべてをメモリーに読み込んで計算する必要があるが，カラム型なら特定のカラムだけをメモリーに読み込めばよく，その分，高速に計算できるのだ。」との記載から，「カラム型データストアは，一般的なＲＤＢＭＳ（行指向データベース）より分析処理に向いており，特定のカラムを集計する際，一般的なＲＤＢＭＳはレコードすべてをメモリーに読み込んで計算する必要があるが，カラム型なら特定のカラムだけをメモリーに読み込めばよく，その分，高速に計算できる」ことが読み取れる。 以上，上記Ａ～Ｇの記載から，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。 「ビックデータの分析基盤を提供するクラウドサービスであるＴｒｅａｓｕｒｅ Ｄａｔａ Ｐｌａｔｆｏｒｍを用いたビックデータ分析システムであって， 上記Ｔｒｅａｓｕｒｅ Ｄａｔａは，基本的なデータ構造として，データ型をあらかじめ設定する必要がないＪＳＯＮ（Ｊａｖａｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式を採用しており， Ｔｒｅａｓｕｒｅ Ｄａｔａの基盤を構成する主要な要素は，データを保管するカラム型データストアと，クエリー処理を実行するＨａｄｏｏｐベースのクエリー処理エンジン，であり，さらに，ユーザーであるエンジニア側にインストールされる要素として，ＪＳＯＮ形式のログを収集するログ収集ソフトＦｌｕｅｎｔｄである「ｔｄ－ａｇｅｎｔ」，クエリーを送信する「ｔｄ－ｃｏｍｍａｎｄ」があり， 上記ログ収集ソフトＦｌｕｅｎｔｄは，オープンソースで，かつ，プラグイン形式で機能拡張できることから，形式がバラバラのログデータに対応できるものであり， 収集したログデータを，Ｔｒｅａｓｕｒｅ ＤａｔａにアップロードするためにＪＳＯＮ形式に変換し， ＪＳＯＮ形式でアップロードしたデータはＴｒｅａｓｕｒｅ Ｄａｔａ内部ではカラム型データストアに格納され， データを取り出す処理はＨａｄｏｏｐを使って実行しており， 上記カラム型データストアは，一般的なＲＤＢＭＳ（行指向データベース）より分析処理に向いており，特定のカラムを集計する際，一般的なＲＤＢＭＳはレコードすべてをメモリーに読み込んで計算する必要があるが，カラム型なら特定のカラムだけをメモリーに読み込めばよく，その分，高速に計算できる， ビックデータ分析システム。」 ２．引用文献２について 原査定の拒絶の理由に引用され，当審拒絶理由通知１にも引用された引用文献２（杉山 暢彦　外５名，ＮｏＳＱＬデータベースＣａｓｓａｎｄｒａのＸＭＬ仮想化システム，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，２０１３年２月２８日，第112巻／第466号，p.17-p.22）には，列指向データベースであるＣａｓｓａｎｄｒａに動的に列を追加する，という技術的事項（特に，ｐ．１８　「３．２　スキーマの変換」，右欄下から６～同４行参照）が記載されている。 ３．引用文献３について 原査定の拒絶の理由に引用され，当審拒絶理由通知１にも引用された引用文献３（特開２０１４－１９１５９３号公報）には，図面とともに次の事項が記載されている。 Ｈ　「【００３９】 本実施形態は，以上の問題点を解決するカラムストア型データベース管理システムにおけるデータ圧縮方式を提供する。 【００４０】 [解決しようとする課題] カラムストア型のデータベースでは，同一列内に同じデータが複数の件数が格納されている場合は重複を排除することでデータを圧縮し，検索やデータ格納に必要なデータ量を削減することで参照処理性能が向上させている。しかし，この同一の列のデータは完全に一致している必要があり，データ内の一部が重複している場合でも，全体としてデータが異なればデータの圧縮効果を出すことはできなかった。この問題に対して，２つの解決のアプローチがある。 【００４１】 １つ目は，データベースの利用者側がある一つの列を２つ以上の列に定義し，データを分割して格納し，一部の重複を有効活用する方法がある。しかしながら，この手法では，アプリケーション側に大きく影響があり，たとえばリレーショナルデータベースからカラムストア型データベース移行した場合などでは列定義を変更するといった場合に，アプリケーション改修のコストの問題から採用が難しい場合がある。 【００４２】 ２つ目は，列の格納データ自体を圧縮する手法である。この手法はディスクのＩ／Ｏがネックになりやすいディスクベースのデータ管理システムでは特に有効だが，Ｉ／Ｏ性能が高いメモリ上にデータを構築するメモリデータベース管理システムでは，相対的にＣＰＵに十分負荷がかかりやすく，通常の圧縮アルゴリズムにてデータ圧縮や伸長を行うと全体のデータベース管理システムへの性能の影響を与えやすいという問題点がある。」 Ｉ　「【００４８】 [構成] 図３を参照すると，本実施形態は，データベースクライアント１と，データベースクライアント１が接続するカラムストア型データベース管理システム２とを含む。本実施形態ではカラムストア型データベース管理システムは１台のマシンを例にしているが，分散データベース管理システムのように複数のマシン台数のデータベース管理システムでもよい。また，データベースクライアント１とカラムストア型データベース管理システム２はネットワークによって接続されていても，同一マシン内でも構わない。 【００４９】 カラムストア型データベース管理システム２は，クエリ解析部２１と実行計画部２２とクエリ実行部２３とテーブルデータ保存領域２４とスキーマ管理データ保存領域２５とを備えており，データベースクライアント１からの問い合わせを受け付け，データの挿入や検索，更新結果をデータベースクライアントに返却をするシステムである。図１に示した第１の実施形態との関係では，テーブルデータ保存領域２４が表領域１４０Ａに相当し，スキーマ管理データ保存領域２５がスキーマ領域１４０Ｂに相当し，クエリ解析部２１と実行計画部２２とクエリ実行部２３とがデータベース管理部１５０Ａに相当する。 【００５０】 クエリ解析部２１は，データベースクライアントから発行されたＳＱＬといった問い合わせ言語の内容を確認し，構文解析を実行する。 【００５１】 実行計画部２２は，クエリ解析部２１で解析した問合せをどのような順番や方法で行えば最も効率的であるかを判定し，その実行計画を作成する。なお，クエリがＳＱＬ言語ではなく，データベースクライアント１からの操作をＡＰＩ等で直接クエリ実行部の動作を指定する場合は，クエリ解析部２１や実行計画部２２は通過しない。 【００５２】 クエリ実行部２３は，実行計画部２２で解析した実行計画によるデータ操作命令，またはデータベースクライアント１から直接受けたデータ操作命令を受けて，テーブルデータ保存領域２４やスキーマ管理データ保存領域２５に向けてクエリを実行する。いわゆるデータベースのエグゼキュータと呼ばれる部分に相当する。 【００５３】 テーブルデータ保存領域２４は，スキーマ管理データ保存領域２５に格納された定義に基づいたデータベースの実データやインデックスデータなどを格納している。このデータ保存領域は，メモリまたはディスク，その他のストレージであるかについては問わない。 【００５４】 スキーマ管理データ保存領域２５は，データベースのスキーマの定義情報を記憶・管理している。スキーマ情報には一般的に保持されるリレーショナルデータモデルでの表やインデックスなどの定義やそれらのデータがどのデバイスのどの位置に格納されているかといった情報が表定義領域２５１に格納されている。またこの表定義の中に，本実施形態で特徴的である論理的な表の中のどの列に対して分割したデータがテーブルデータ保存領域２４のどの列に対応するかの情報も格納されているものとする。列分割文字テーブル２５２は，実際に列データを分割をする基準の文字と分割する最大の列数などの簡単なルールを格納している。」 Ｊ　「【００５５】 [動作] 次に，図３乃至図６を参照して本実施形態の動作について詳細に説明する。 【００５６】 まず，データベース管理者やユーザなどがデータベースクライアント１からデータベース管理システム２に，ユーザの必要なデータベースのスキーマ定義作成と実データの格納を実施する。なお，本実施形態ではテーブル定義上の１つの列を複数の列に分割して格納する方式を用いるが，その列を「分割圧縮列」と定義する。 【００５７】 スキーマ定義について述べる。データベースクライアント１からコマンド等により，通常のカラムストア型データベースと同様にリレーショナルデータモデルの表定義やインデックス定義を行う。定義方法については一般的に，ＳＱＬ言語によって行われる場合が多いが，その手法を限定するものではない。ＳＱＬ言語を用いる場合はクエリ解析部２１，実行計画部２２を通じてクエリ実行部２３で定義データを生成し，その結果をスキーマ管理データ保存領域２５にある表定義領域２５１に格納する。なお，ＡＰＩ等でデータベース管理システム独自の方法をとる場合は直接クエリ実行部２３に命令し同様にデータを格納する。この時，表定義領域２５１の表定義には本実施形態の特徴である，各列に対して「分割圧縮列」であるか「通常」の列であるかを格納している。また，列分割文字テーブル２５２に格納されたどの分割ルールを使用するかの対応関係と分割後の複数の列データの対応関係も同様に各列に格納する領域を確保しており，これらの情報が表定義領域２５１に格納されている。 【００５８】 列分割文字テーブル２５２には，分割する際の識別子や分割を行う列数などのルールが格納されている。これらの定義についても同様にデータベースクライアント１からＳＱＬ等を用いて定義をする。この時，分割された列のデータで完全一致する重複データができるように分割の列の定義を行うことが本実施形態を効果的に利用する方法である。アプリケーション開発者やデータベース管理者はデータの特性を理解し，分割列の実施有無とルールを判断する必要がある。 【００５９】 これ以降，今回の説明のためのカラムストアデータモデルの例として，同じ列の中で実データの重複を排除してソートした形で格納する「実データ領域」をその列単位に作成・格納した上で，該当のデータ列を参照するインデックスを並べた「インデックス領域」に格納することで，カラム単位の列データを表現させている方式で説明する。「実データ領域」と「インデックス領域」はテーブルデータ保存領域２４の内部に格納されている。具体的な例については後程図４以降の例で述べる。 【００６０】 このデータ領域で重複を排除している機構については，一般的なカラムストア型データベースの特徴になり，それ以外のカラムストア型のデータモデルを利用している場合でも，同様に重複排除の効果を利用している。この重複排除の効果があれば本実施形態の「分割圧縮列」の手法は採用可能である。 【００６１】 次に分割圧縮列を含めた表定義が完了したらデータベースクライアント１から表定義に対応した表データをカラムストア型データベース２にロードする。クエリ実行部２３は，クライアント１から渡されたデータをテーブルデータ保存領域２４に格納する。「分割圧縮列」以外の列については，通常の通り重複を排除した形でデータを格納する。また，本実施形態での特徴である「分割圧縮列」に指定されている列については，列のデータを列分割文字テーブル２５２にある指定された分割文字によって複数の列に分割したうえで，通常の列と同様に重複を排除した形で「実データ領域」にデータを作成する。「分割圧縮列」の「インデックス領域」については分割された実データ領域を分割した列分インデックスが配列と同様の形で保有しており，その配列に書かれているインデックスと対応している実データ領域のデータを順番に結合することで元データを復元することを可能としている。 【００６２】 なお，すでに表にデータが存在している場合には，データベースクライアント１からのデータ定義操作によって分割圧縮列と分割ルールの関係性を該当する列に定義することで，クエリ実行部２５は同様に内部的な列データの分割を行えるものとし，反対に内部列分割を解除して１つの列としてデータを再構成する機能も保有している。」 Ｋ　「【００６３】 ここで具体的に図４のように顧客テーブルというテーブルを定義し，一般的なカラムストア型データモデルの場合と，本実施形態の場合の違いを述べる。 【００６４】 顧客テーブルは，”顧客id“，”性”，”名”，”メールアドレス”，”性別”という列を持っている。この顧客テーブルを既存のカラムストア型データベースモデルにロードした例が図５のようになる。テーブルデータ保存領域２４にある「実データ領域」には実データの重複が排除されて配置されており，インデックス領域には列の位置に該当する実データと対応した「実データ領域」へのインデックス番号が記載されている。このことにより論理的な顧客テーブルを格納している。例えば，顧客テーブルの２列目の“姓”を参照する時は，顧客テーブルのインデックス列の２列目の姓を確認する。この“１”をもとに実データ列の姓の１番目にある値を確認すれば「鈴木」であることがわかる。」 以上，上記ＨないしＫの記載から，上記引用文献３には次の発明（以下，「引用文献３記載事項」という。）が記載されていると認められる。 「カラムストア型データベース管理システムであって， カラムストア型のデータベースでは，同一列内に同じデータが複数の件数が格納されている場合は重複を排除することでデータを圧縮し，検索やデータ格納に必要なデータ量を削減することで参照処理性能が向上させるものであり， 上記カラムストア型データベース管理システムは，クエリ解析部と，実行計画部と，クエリ実行部と，テーブルデータ保存領域と，スキーマ管理データ保存領域と，を備えており， 上記クエリ解析部は，データベースクライアントから発行されたＳＱＬといった問い合わせ言語の内容を確認し，構文解析を実行し， 上記実行計画部は，上記クエリ解析部で解析した問合せをどのような順番や方法で行えば最も効率的であるかを判定し，その実行計画を作成し， 上記クエリ実行部は，上記実行計画部で解析した実行計画によるデータ操作命令，またはデータベースクライアントから直接受けたデータ操作命令を受けて，テーブルデータ保存領域やスキーマ管理データ保存領域に向けてクエリを実行し， 上記テーブルデータ保存領域は，スキーマ管理データ保存領域に格納された定義に基づいたデータベースの実データやインデックスデータなどを格納し， 上記スキーマ管理データ保存領域は，データベースのスキーマの定義情報を記憶・管理するものであり， データベース管理者やユーザなどがデータベースクライアントからデータベース管理システムに，ユーザの必要なデータベースのスキーマ定義作成と実データの格納を実施し，その際に，テーブル定義上の１つの列を複数の列に分割して格納する方式を用い，その列を「分割圧縮列」と定義するものであり， 上記「分割圧縮列」を含めた表定義が完了したら，データベースクライアントから表定義に対応した表データをカラムストア型データベースにロードし，その際，上記クエリ実行部は，クライアントから渡されたデータを上記テーブルデータ保存領域に格納するものであり，「分割圧縮列」以外の列については，重複を排除した形でデータを格納し，「分割圧縮列」に指定されている列については，列のデータを列分割文字テーブルにある指定された分割文字によって複数の列に分割したうえで，通常の列と同様に重複を排除した形で「実データ領域」にデータを作成し，「分割圧縮列」の「インデックス領域」については分割された実データ領域を分割した列分インデックスが配列と同様の形で保有しており，その配列に書かれているインデックスと対応している実データ領域のデータを順番に結合することで元データを復元することを可能としており， テーブルデータ保存領域にある「実データ領域」には実データの重複が排除されて配置されており，インデックス領域には列の位置に該当する実データと対応した「実データ領域」へのインデックス番号が記載されている， カラムストア型データベース管理システム。」 ４．引用文献４について 原査定の拒絶の理由に引用され，当審拒絶理由通知１にも引用された引用文献４（特表２０１６－５１９８１０号公報）の段落【０２２９】，【０３１０】には，カラム型ストレージにおいて，インポートされたローに存在しない新しいテーブルのカラムについては，ヌル値を用いる，という技術的事項が記載されている。 ５．引用文献５について 原査定で引用された引用文献５（特開２０１５－１８５１０４号公報）の段落【００２４】には，カラム型データベース管理システムにおいてスキーマ管理データを格納する，という技術的事項が記載されている。 ６．引用文献Ｂについて 当審拒絶理由通知１に引用された引用文献Ｂ（特開２００５－７１０５０号公報）の段落【００３２】ないし【００４１】には，データベースに対する要求を，木構造形式の抽象化した態様として構成する，という技術的事項が記載されている。 第６　対比・判断 １．本願発明１について （１）対比 本願発明１と引用発明とを対比する。 ア　引用発明である「ビックデータ分析システム」は，「ＪＳＯＮ形式でアップロードしたデータ」を「カラム型データストアに格納」するために，「ログ収集ソフトＦｌｕｅｎｔｄ」が「形式がバラバラのログデータ」を収集し，「収集したログデータを，Ｔｒｅａｓｕｒｅ ＤａｔａにアップロードするためにＪＳＯＮ形式に変換」するものであり，データを「ビックデータ分析システム」にアップロードするための要求が当然に入力されているものと解されることから，当該アップロードのための要求は，データ格納要求といいうるものである。 そして，引用発明である上記「ビックデータ分析システム」による，上記「ＪＳＯＮ形式」への「変換」は，「アップロード」のための上記要求を受けて，「収集したログデータ」に対し，「形式がバラバラのログデータに対応」して行うものであるから，ログデータのバラバラな形式から「ＪＳＯＮ形式」に変更するための所定の解釈を行っていると解され，よって，引用発明である「ビックデータ分析システム」は，「アップロード」のための要求内容を解釈し，その結果，「収集したログデータ」を，「Ｔｒｅａｓｕｒｅ Ｄａｔａにアップロード」するためのデータに変換しているものと認められる。 以上を踏まえると，引用発明の上記「アップロード」のための要求は本願発明１の「データ格納要求」に相当する。 また，引用発明の上記「収集したログデータ」は，「形式がバラバラ」であることからして木構造を含む所定の構造のものであるかは特定されていないものの，本願発明１の「多次元空間での木構造」が，多階層の木構造形式のデータ，を意味するものと文言上解されることを踏まえると，両者は，“データ”である点で共通する。 また，引用発明の上記「Ｔｒｅａｓｕｒｅ ＤａｔａにアップロードするためにＪＳＯＮ形式に変換」されるデータは，json等のデータフォーマットから切り離した上で抽象化されたものではないものの，「カラム型データストア」への「格納」対象のデータであることから，「オブジェクト」といいうるものであり，また，本願発明１の「json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式のオブジェクト」が，json等の具体的なデータフォーマットにより規定されない，配列において次元を拡張可能な形式の抽象化されたオブジェクト，を意味するものと文言上解されることを踏まえると，両者は，“オブジェクト”である点で共通する。 そして，引用発明である「ビックデータ分析システム」における，上記「アップロード」のための要求内容を解釈し，上記「収集したログデータ」を，「Ｔｒｅａｓｕｒｅ ＤａｔａにアップロードするためにＪＳＯＮ形式」のデータに「変換」するための構成は，解釈部といいうるものである。 イ　上記アを踏まえると，後記する点で相違するものの，本願発明１の「入力されたデータ格納要求を解釈し，多次元空間での木構造を，json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式のオブジェクトに変換する解釈部」と，引用発明の「アップロード」のための要求に応じて，「収集したログデータを，Ｔｒｅａｓｕｒｅ ＤａｔａにアップロードするためにＪＳＯＮ形式に変換」するための構成とは，“入力されたデータ格納要求を解釈し，データを，オブジェクトに変換する解釈部”である点で共通する。 ウ　引用発明である上記「ビックデータ分析システム」では，「ＪＳＯＮ形式でアップロードしたデータはＴｒｅａｓｕｒｅ Ｄａｔａ内部ではカラム型データストアに格納され」るものであり，「上記カラム型データストアは，一般的なＲＤＢＭＳ（行指向データベース）より分析処理に向いており，特定のカラムを集計する際，一般的なＲＤＢＭＳはレコードすべてをメモリーに読み込んで計算する必要があるが，カラム型なら特定のカラムだけをメモリーに読み込めばよく，その分，高速に計算できる」ものであることから，「カラム型データストア」に格納される際のデータは，特定のカラムについて集計する等，カラムすなわち列方向の処理を指向して格納されるものであって，列指向型のデータ構造で管理されるデータあるといえ，また，当該データはユーザに係るログデータに基づくものであることから，クライアントデータといいうるものであり，さらに，「ＪＳＯＮ形式でアップロードしたデータ」は，「データ型をあらかじめ設定する必要がない」ものであり，列指向型のデータ構造とは異なるデータ構造のものといえることから，引用発明である上記「ビックデータ分析システム」は，列指向型のデータ構造とは異なるデータ構造の「ＪＳＯＮ形式でアップロードしたデータ」を，「カラム型データストアに格納」するために，列指向型のデータ構造で管理されるクライアントデータに変換するものであるといえ，そのための構成を有するものと解される。 そうすると，後記する点で相違するものの，本願発明１の「前記オブジェクトに変換されたデータを，前記変換されたデータとは別のデータ構造であって，予め配列が確保されていない列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させると共に，前記オブジェクトに含まれる，前記列指向型のデータ構造で管理されるデータを行方向に読み出し可能にするための参照情報を前記記憶部に記憶させる変換部」と，引用発明の「ＪＳＯＮ形式でアップロードしたデータ」を「Ｔｒｅａｓｕｒｅ Ｄａｔａ内部ではカラム型データストアに格納」するために，「カラム型データストアは，一般的なＲＤＢＭＳ（行指向データベース）より分析処理に向いており，特定のカラムを集計する際，一般的なＲＤＢＭＳはレコードすべてをメモリーに読み込んで計算する必要があるが，カラム型なら特定のカラムだけをメモリーに読み込めばよく，その分，高速に計算できる」ようにするための構成は，“前記オブジェクトに変換されたデータを，前記変換されたデータとは別のデータ構造であって，予め配列が確保されていない列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させる変換部”である点で共通する。 エ　上記アないしウを総合すると，引用発明である「ビックデータ分析システム」は，本願発明１である「データ管理装置」に対応するといえる。 上記アないしエの対比によれば，本願発明１と引用発明とは，次の点で一致し，そして相違する。 （一致点） 入力されたデータ格納要求を解釈し，データを，オブジェクトに変換する解釈部と， 前記オブジェクトに変換されたデータを，前記変換されたデータとは別のデータ構造であって，予め配列が確保されていない列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させる変換部と， を備えるデータ管理装置。 （相違点１） 解釈部に関し， 本願発明１は，「多次元空間での木構造を，json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式」のオブジェクトに変換するのに対して， 引用発明は，そのように特定されていない点。 （相違点２） 変換部に関し， 本願発明１は，前記オブジェクトに変換されたデータを，「予め配列が確保されていない」列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させるのに対して， 引用発明は，そのように特定されていない点。 （相違点３） 変換部に関し， 本願発明１は，「オブジェクトに含まれる，前記列指向型のデータ構造で管理されるデータを行方向に読み出し可能にするための参照情報を前記記憶部に記憶させる」のに対して， 引用発明は，そのように特定されていない点。 （２）相違点についての判断 事案に鑑みて，「多次元空間での木構造を，json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式」のオブジェクトに関連する，上記相違点１及び２について，先に検討する。 上記相違点１及び２に係る本願発明１の構成である，「多次元空間での木構造を，json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式」のオブジェクトに変換し，前記オブジェクトに変換されたデータを，「予め配列が確保されていない」列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させることは，上記引用文献２ないし５，及び，Ｂのいずれにも記載されておらず，また，本願出願前において周知技術であるともいえない。 特に，引用文献３（当審拒絶理由通知１における引用文献Ａ）には，上記第５の３．に示した引用文献３記載事項が記載されており，テーブルデータ保存領域に格納される，実データやインデックスデータの具体的なデータ構造について何ら規定されていないことから，相違点１及び２に係る本願発明１の構成について開示しているとはいえない。 そうすると，引用発明に基づいて，相違点１及び２に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。 したがって，本願発明１は，相違点３を検討するまでもなく，当業者であっても引用発明，引用文献２ないし５，及び，Ｂに記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。 ２．本願発明２－７について 本願発明６，７は，本願発明１とカテゴリーが異なるだけであるから，本願発明１と同様の理由により，引用発明，引用文献２ないし５，及び，Ｂに記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。 本願発明２－５は，本願発明１を更に限定したものであるので，本願発明１と同様の理由により，引用発明，引用文献２ないし５，及び，Ｂに記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。 第７　原査定についての判断 （特許法第２９条第２項について） 平成３０年１１月２８日付けの手続補正により，補正後の請求項１は，「入力されたデータ格納要求を解釈し，多次元空間での木構造を，json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式のオブジェクトに変換する解釈部」と，「前記オブジェクトに変換されたデータを，前記変換されたデータとは別のデータ構造であって，予め配列が確保されていない列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させる」「変換部」という技術的事項を有するものとなった。当該技術的事項は，上記第６の１．（２）でも示したとおり，原査定における引用文献１ないし５には記載されておらず，本願出願前における周知技術でもないので，本願発明１は，当業者であっても，原査定における引用文献１ないし５に基づいて容易に発明できたものではない。本願発明２－７は，本願発明１とカテゴリーが異なるだけ，または，更に限定したものであるので，同様に，当業者であっても，原査定における引用文献１ないし５に基づいて容易に発明できたものではない。 したがって，原査定を維持することはできない。 第８　当審拒絶理由について １．特許法第３６条第６項第２号について （１）当審拒絶理由通知１では，請求項１の「多次元空間での木構造をデータフォーマットから切り離して抽象化したオブジェクトに変換する解釈部」との記載は，「多次元空間での木構造」を「抽象化したオブジェクト」に「変換する」という「解釈部」の処理が具体的にどのような処理であり，また，当該処理の結果得られる「抽象化したオブジェクト」が，具体的にどのような内容及び形態のものであるのか，不明りょうであるとの拒絶の理由を通知しているが，平成３０年１１月２８日付けの手続補正において，「多次元空間での木構造を，json, xml, avro, 又はmessage packを含むデータフォーマットから切り離して抽象化し，配列に対して次元を拡張可能な形式のオブジェクトに変換する解釈部」と補正された結果，この拒絶の理由は解消した。 （２）当審拒絶理由通知１では，請求項１の「前記解釈部により抽象表現に変換されたデータを，前記変換されたデータとは別のデータ構造であって，予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させる」との記載は，まず，「解釈部により抽象表現に変換されたデータ」との表現が，「解釈部」により「変換」された「抽象化したオブジェクト」自体を意味するのか，当該「抽象化したオブジェクト」からさらに変換された別の「データ」を意味するのか，不明であり，そして，上記「記憶部」に「記憶」する対象が，上記「抽象化したオブジェクト」自体であるのか，当該「抽象化したオブジェクト」から「列指向型のデータ構造」にさらに「変換」した「列指向型のデータ構造で管理されるデータ」であるのか，不明りょうであるとの拒絶の理由を通知しているが，平成３０年１０月３日付けの手続補正において，「前記オブジェクトに変換されたデータを，前記変換されたデータとは別のデータ構造であって，予め配列が確保されていない列指向型のデータ構造で管理されるクライアントデータに変換して記憶部に記憶させる」と補正された結果，この拒絶の理由は解消した。 （３）当審拒絶理由通知１では，請求項１の「前記抽象化したオブジェクトに基づいて，前記列指向型のデータ構造で管理されるデータを，行方向に読み出し可能にするための参照情報を生成し」との記載は，「抽象化したオブジェクト」から「参照情報」を「生成」するとの処理が，具体的に，どのような処理を意味するのか，不明りょうであるとの拒絶の理由を通知しているが，平成３０年１１月２８日付けの手続補正において，「前記オブジェクトに含まれる，前記列指向型のデータ構造で管理されるデータを行方向に読み出し可能にするための参照情報を」と補正された結果，この拒絶の理由は解消した。 （４）当審拒絶理由通知２では，請求項１の「行列に対して次元を追加可能な形式のオブジェクト」における「行列に対して次元を追加可能な」との記載は，「オブジェクト」のどのような形式の態様について記載しているのか，明確でなく，また，請求項１の「前記オブジェクトを，前記列指向型のデータ構造で管理されるデータを行方向に読み出し可能にするための参照情報として前記記憶部に記憶させる」との記載は，「オブジェクト」と「参照情報」とがどのような関係にあるのか，明確でないとの拒絶の理由を通知しているが，平成３０年１１月２８日付けの手続補正において，「配列に対して次元を拡張可能な」，「前記オブジェクトに含まれる，前記列指向型のデータ構造で管理されるデータを行方向に読み出し可能にするための参照情報を前記記憶部に記憶させる」と補正された結果，この拒絶の理由は解消した。 ２．特許法第２９条第２項について 上記「第６　対比・判断」で検討のとおり，平成３０年１１月２８日付けの手続補正により，この拒絶の理由は解消した。 第９　むすび 以上のとおり，本願発明１－７は，当業者が引用発明，引用文献２ないし５，及び，Ｂに記載された技術的事項に基づいて容易に発明することができたものではない。 したがって，原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。 また，他に本願を拒絶すべき理由を発見しない。 よって，結論のとおり審決する。