【事件の表示】
　特願２００７−　２９７６８「電子帳票作成管理システム及び電子帳票作成管理プログラム及びこのプログラムを記憶した記録媒体」拒絶査定不服審判事件〔平成２０年　８月２８日出願公開、特開２００８−１９７７５１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１９年２月８日の出願であって、平成２３年１０月１７日付けの拒絶理由通知に応答して、平成２３年１２月１４日付けで意見書、手続補正書が提出されたが、平成２４年６月７日付けで拒絶査定がなされた。これに対して、平成２４年９月１１日に拒絶査定不服審判が請求されるとともに、同日付けで手続補正書が提出されたものである。
　そして、当審から平成２５年３月７日付けで審尋がなされ、平成２５年５月１０日付けで回答書が提出され、更に、当審から平成２５年７月３日付けで拒絶理由が通知され、平成２５年９月６日付けで意見書、手続補正書が提出されたものである。
　
２．本願発明
　本願請求項１に係る発明は、平成２５年９月６日付けで手続補正された特許請求の範囲の請求項１に記載された次のとおりのものと認める。（以下、「本願発明」という。なお、下線は、補正箇所を示す。）
「【請求項１】
コンピュータの記憶手段に記憶されている帳票用のデータを抽出し、この抽出されたデータを用いて任意の形式の電子帳票を作成して、前記コンピュータの表示装置に表示可能な電子帳票作成管理システムであって、
　前記任意の形式の電子帳票上のデータを、個別に変更可能なオブジェクト形式で生成するデータ生成手段と、
　生成されたオブジェクト形式のデータに対して、
オブジェクトの集合で生成されるオブジェクト型ファイル単位で、ユーザーによって指示された場合にはさらにオブジェクト単位で、
　前記電子帳票上の前記オブジェクト形式のデータが、前記アクセス権限の範囲に応じて前記電子帳票上において直接変更可能であり、前記電子帳票上におけるオブジェクトに対する編集に応じて、前記記憶手段に記憶されている前記帳票用のデータが書き換えられることを特徴とする電子帳票作成管理システム。」
　
３．引用例
１）引用例１
　これに対して、当審の拒絶の理由に引用された、本願の出願日前である平成１７年５月１２日に頒布された「特開２００５−１２２７５８号公報」（以下、「引用例１」という。）には、図面とともに次の事項が記載されている。
（１）「【０００８】
  一方、手書きの取引先要項等では、記載内容を組織内で共有するためには複写機等で複写して郵送等する必要がある。また、取引先の最新の状態を把握するためには、取引先要項等を一定期間毎に再作成する必要がある。すなわち、
取引先の役職者等や製商品等は変化するため、この部分を書き直す必要がある。しかし、更改時には、新たな帳票に記入するため、変更のない項目を書き写すなど、無駄な作業が発生してしまう。
【０００９】
  また、
手書きの取引先要項では、営業日誌、各種稟議、信用リスク管理等を行う毎に、ほぼ同一の内容を重複して他の帳票に記載する必要があり、事務負担が大きくなっていた。
【００１０】
  そして、手書きの取引先要項では、取引先の状況を文章表現する際の熟練度や個性などから、必ずしも均質で粒度のそろった情報とならない場合もあった。従って、手書きの取引先要項では、ある状況又は属性の取引先を抽出するために取引先要項の帳票等を利用するのが難しく、さらに、取引先数が多いと、紙の帳票から一定の状況にある取引先を抽出するには多大な労力を要することから、その活用には限界があった。従って、
取引先要項に記載の内容を、組織で共有することが難しかった。
（２）「【００１９】
  
本発明では、ネットワークを介して端末及び他システムと接続されたサーバーと、このサーバーによって処理されるデータを格納するデータ格納部とを備えている。
【００２０】
  取得制御部は、取引先の組織及び事業と、当該取引先についての時系列での主要な動向等についての文字データを他システムから取得する。また、表示編集制御部は、予め定められたユーザーインタフェース定義（例えば、ＧＵＩ）に基づいて他システムから取得した文字データを端末に表示させる。従って、種々の他システムから自動的に収集した文字データを一定のＧＵＩを用いてユーザーに表示する。さらに、表示編集制御部は、取引先の組織の内容を示す組織データと、事業の内容を示す事業データと、当該取引先の主要動向を示す動向コメントデータ等の入力及び編集を制御する。
取得したデータの編集を許可するか否かは、業務内容や各種の権限等に応じて定める。
  
本発明ではさらに、格納制御部が、取得制御部によって他システムから取得した文字データと、表示編集制御部による制御に応じて入力及び編集された文字データとを一体の体系での要項データとしてデータ格納部等に格納する。従って、他システムから自動的に取得できるデータは取得し、取引先の担当者等のユーザーの日々の活動に応じて得た情報については、予め定められたユーザーインタフェースに応じて入力及び編集し、これを一体的な体系での要項データとして格納する。一体的というのは、例えばＸＭＬ等のマークアップランゲージで一定の構造化がなされた状態である
  すると、
本発明による取引先要項システムは、種々の他システムを用いた業務の結果の要点を示す重要な文字データを集約し、取引先要項として不足する部分については入力を促すものとなる。そして、取得した文字データ及び入力された文字データは、予め定められた一体的な体系で格納される。従って、集約された文字データを、他システムへ送信することが容易である。このように、本発明による取引先要項システムは、取引先に関する文字データの最上位のＤＢと位置付けられる。すなわち、本発明によると、文字データを他システムから集約し、一体的な体系で構造化したデータを随時端末に表示又は他システムへ送信することができる。他システムへの「送信」は、他システムに対して、本発明によるデータ格納部へのアクセス（検索）を許可する処理としてもよい。
（３）「【００６５】
  ＸＭＬデータを取り扱うソフトウエア・モジュールをＸＭＬパーサー（ＸＭＬプロセッサ）という。ＸＭＬパーサーは、ＸＭＬデータを構文解析し、妥当性の検証等を行う。妥当性が検証されたＸＭＬデータは、予め定められたタグ体系に従っている。ＸＭＬデータの内部構造にアクセスするためのＡＰＩ（Application Programming Interface）としては、ＤＯＭ（Document Object Model）やＳＡＸ（Simple API for XML）等がある。ＤＯＭは、ＸＭＬデータを要素や文字データというノードからなるツリー（ＤＯＭツリー）として表現する。妥当なＸＭＬデータのＤＯＭツリーは、ＤＴＤによる階層定義に従っている。ＸＭＬ文書の要素をある順序でソートしたり、別の場所に移したり、新たな要素を挿入したりする処理には、ＤＯＭ  ＡＰＩが適している。
【００６６】
  
ＸＭＬはサーバーと端末間でデータ及びプログラムを送受信しつつ一定の機能を実現するＷｅｂアプリケーションによって利用されることが多く、このため、妥当性の検証を行う機能を持ったＸＭＬパーサー等は、オブジェクト指向言語であるＪａｖａ（登録商標）向けに開発されたものが多い。
【００６７】
  Ｊ２ＥＥでは、端末は、Ｗｅｂブラウザか、ＧＵＩを装備したＪａｖａアプリケーションを用いる例が多い。Ｊａｖａアプリケーションを利用する場合には、ＧＵＩとしてＳｗｉｎｇ又はこれを利用した画面設計ツールを用いると、ＧＵＩの定義が容易となる。ＥＪＢは、端末１のＪａｖａアプリケーションとセッションを維持し、ボタン押下等のイベントを直接に又はプレゼンテーション層を介して受信することができる。ＥＪＢは、イベントに応じて、表示モードの変更を指示したり、要素間での構成比率の算出を行ったり、導出元の入力を検索キーとしてＲＤＢから検索し、ＤＯＭツリーを操作して検索結果を導出先の要素として追加したり、要素のソートを行うことができる。要素のソートをプレゼンテーションの問題と捉える場合には、このソートをプレゼンテーション層に実装する。
【００６８】
  ＸＭＬデータのデータベースへの格納には、種々の方式が提案されている。ＸＭＬのタグをＲＤＢのテーブルにマッピングし、ＲＤＢに格納する方式や、ＸＭＬデータを巨大なテキストデータとして格納し、検索用のインデックスをサイド表として生成する方式や、オブジェクト指向データベースでのクラス階層にＸＭＬデータをマッピングする方式などである。
【００６９】
  ＸＭＬデータの操作では、ＤＯＭツリーを用いるのではなく、コンプレックスレコードのスキーマ定義を行い、ＸＭＬデータのタグと、Ｊａｖａのオブジェクトと、データベースのレコードとを任意のタイミングで相互に変換可能とする開発・実行環境も提供されている。また、文書型定義をよりＸＭＬ関連技術で使用しやすくするための手法として、ＸＭＬＳｃｈｅｍａが定められている。ＸＭＬＳｃｈｅｍａを用いる場合には、ＸＭＬデータの妥当性検証にてデータ型等の検証を行うことができる。
【００７０】
  本実施形態では、ＤＴＤ、ＤＯＭツリー、ＸＭＬデータをテキストとして格納しサイド表を用いてＳＱＬでの検索を可能とするデータベース、Ｊ２ＥＥによるＥＪＢ、さらに、ＳｗｉｎｇによるＧＵＩ、Ｗｅｂブラウザで実行されるアプレット、ＥＪＢやサーブレットやアプレットを使用した型チェックや表示編集制御、ＲＤＢを用いた他システムからのデータの取込等の技術を利用する。ＤＴＤや、ＤＯＭツリーや、ＳＱＬによる検索や、アプレット及びＷｅｂブラウザに代えて、ＸＭＬＳｃｈｅｍａや、コンプレックスレコードや、ＸＱｕｅｒｙや、ＷｅｂブラウザとＸＳＬＴの組み合わせ等を用いるようにしてもよい。端末をＰＤＡや携帯電話等の携帯端末とする場合、例えば表示のみを提供するために、ＸＭＬデータをＸＳＬＴでＨＴＭＬに変換し、送信する仕組みとしてもよい。
【００７１】
  
図８は、第２実施形態の構成例を示すブロック図である。本実施形態による取引先要項システムは、ＲＤＢと連携するマークアップランゲージ（ＭＬ）のタグの体系を定義したタグ体系定義ファイル５０と、端末での表示及び入力について予め定められたＧＵＩ定義ファイル５２と、前記ＭＬのタグ付けされた取引先毎のタグ付きデータを格納するＭＬデータＤＢ（図８に示す例では、ＸＭＬデータＤＢ）５４と、他システム４０にて一定期間毎に更新されるデータを格納したＲＤＢ５６とを格納するデータ格納部３とを備えている。
【００７２】
  タグ体系定義ファイル５０は、例えばＤＴＤファイルである。ＧＵＩ定義は、Ｓｗｉｎｇ等による画面のレイアウト定義と、各画面で使用するテーブルの項目（フィールド）と関連して定義したデータ型等と、項目間の導出関係の定義と、表示のプロパティデータと表示するボタン等の関係等である。ＸＭＬデータＤＢ５４は、例えば、ＸＭＬを巨大なテキストファイルとして格納し、検索用のサイド表を作成するＲＤＢの拡張を用いると、項目数の増減について比較的柔軟な取扱が可能となる。ＲＤＢは、ＩＭＳ等の階層型データ構造を使用するオンラインシステムのデータを取り込む機能を有するＲＤＢを用いるとよい。
【００７３】
  
図８に示す例では、サーバーは、取引先の組織及び事業並びに主要な動向等についてのデータの端末での表示及び入力を前記ＧＵＩ定義に従って制御する表示編集制御部８と、他システム４０から取り込んだデータ及び端末１から入力されたデータをＲＤＢ５６でのデータ項目名若しくは前記ＧＵＩ定義に関連した前記タグ体系定義に基づいてタグ付きデータに変換すると共に、当該タグ付きデータを一体的な要項データとして前記ＭＬデータＤＢに格納する格納制御部１０とを備えている。
（４）「【０１０４】
  図２４はユーザーのログインから端末への要項データの表示までの概要を示すフローチャートである。取引先要項システムは、取引先要項システムにログインした作業者をユーザーＩＤに基づいて識別する（ステップＳ１１）。ユーザーは、ＣＩＦ番号を入力し、且つ要項Ｉ又はＩＩを選択して開くボタンを押し下げる（ステップＳ１２）。
ユーザーＩＤ等から取引先要項の参照権限を確認し（ステップＳ１３）、権限がある場合には、当該ＣＩＦ番号の取引先について、ＲＤＢ５６から取引先の基本属性等のデータを取得し（ステップＳ１４）、これに前後して、ＸＭＬデータＤＢからＸＭＬデータを取り込む（ステップＳ１５）。さらに、ユーザーの権限に応じたボタンの表示制御を行い（ステップＳ１６）、ＧＵＩ定義による画面定義ファイルと取り込んだデータとを合成して端末１に表示する（ステップＳ１７）。
　
　これらの記載事項によると、引用例１には、
「取引先要項の帳票に記載する重複するデータ項目の入力を軽減することを目的としたものであり、ネットワークを介して端末及び他システムと接続されたサーバーと、このサーバーによって処理されるデータを格納するデータ格納部とを備え、サーバーは、取得制御部によって他システムから取得した文字データと前記表示編集制御部による制御に応じて入力及び編集された文字データとを一体の体系での要項データとしてデータ格納部等に格納する格納制御部とを備え、データ項目は、タグ付きデータに変換して、オブジェクト指向型のＭＬデータベースに格納し、アクセス権限に応じて、取引先要項の参照を許可し、取得したデータの編集を許可するか否かは、業務内容や各種の権限等に応じて定める取引先要項システム」
　の発明（以下、「引用例１記載の発明」という。）が記載されているものと認められる。
　
２）引用例２
　当審の拒絶の理由に引用された、本願の出願日前である平成１８年６月２２日に頒布された「特開２００６−１６３７８２号公報」（以下、「引用例２」という。）には、図面とともに次の事項が記載されている。
（１）「【請求項１】
  記憶手段に所定の形式で記憶されている帳票用のデータを抽出して、この抽出されたデータを用いて前記所定の形式と異なる任意の形式の帳票データを作成してサーバーのデータファイル内に記憶するシステムであって、
  前記サーバーにアクセス可能なユーザーに対して、
前記帳票データ及び／または前記データファイルへのアクセス権を階層的に設定する
（以下、「引用例２の記載事項」という。下線は、当審による。）
　
４．対比
　引用例１記載の発明の「取引先要項の帳票に記載する重複するデータ項目の入力を軽減することを目的としたものであり、ネットワークを介して端末及び他システムと接続されたサーバーと、このサーバーによって処理されるデータを格納するデータ格納部とを備え、サーバーは、取得制御部によって他システムから取得した文字データと前記表示編集制御部による制御に応じて入力及び編集された文字データとを一体の体系での要項データとしてデータ格納部等に格納する格納制御部とを備え、」で、サーバは、帳票を作成するために他システムから文字データを取得していること、他システムからデータを取得する場合、他システムの記憶手段から取得していることが明らかなことから、本願発明の「コンピュータの記憶手段に記憶されている帳票用のデータを抽出し、この抽出されたデータを用いて任意の形式の電子帳票を作成して」に相当する。
　引用例１記載の発明は、「取引先要項の参照を許可する」構成であるから、本願発明の「表示装置に表示可能な」構成を有している。
　引用例１記載の発明の「取得したデータの編集を許可するか否かは、業務内容や各種の権限等に応じて定める」は、オブジェクト指向のＭＬデータベースで管理されている文字データが編集可能であることを表しているから、本願発明の「前記任意の形式の電子帳票上のデータを、個別に変更可能なオブジェクト形式で生成するデータ生成手段」に相当する構成を有している。
　引用例１記載の発明の「アクセス権限に応じて、取引先要項の参照を許可し、取得したデータの編集を許可するか否かは、業務内容や各種の権限等に応じて定める」は、オブジェクト形式のデータに対してアクセス権限を設定していることであるから、本願発明の「生成されたオブジェクト形式のデータに対して、」「アクセス権限を設定する設定手段」に相当する構成を有していて、「電子帳票上のオブジェクト形式のデータが、アクセス権限の範囲に応じて電子帳票上において直接変更可能であり、電子帳票上におけるオブジェクトに対する編集に応じて、記憶手段に記憶されている帳票用のデータが書き換えられる」ことも意味している。
　引用例１記載の発明の「取引先要項システム」は、帳票の管理、作成を目的とすることから、本願発明の「電子帳票作成管理システム」に相当する。
　
　してみると、両発明の一致点、相違点は以下のとおりである。
　
［一致点］
「コンピュータの記憶手段に記憶されている帳票用のデータを抽出し、この抽出されたデータを用いて任意の形式の電子帳票を作成して、前記コンピュータの表示装置に表示可能な電子帳票作成管理システムであって、
　前記任意の形式の電子帳票上のデータを、個別に変更可能なオブジェクト形式で生成するデータ生成手段と、
　生成されたオブジェクト形式のデータに対して、アクセス権限を設定する設定手段とを有し、
　前記電子帳票上の前記オブジェクト形式のデータが、前記アクセス権限の範囲に応じて前記電子帳票上において直接変更可能であり、前記電子帳票上におけるオブジェクトに対する編集に応じて、前記記憶手段に記憶されている前記帳票用のデータが書き換えられる電子帳票作成管理システム。」
　
［相違点］
　本願発明のアクセス権限は「階層化した」アクセス権限であって、「オブジェクトの集合で生成されるオブジェクト型ファイル単位で、ユーザーによって指示された場合にはさらにオブジェクト単位で」設定しているのに対して、引用例１記載の発明の「アクセス権限」は、階層化したものではなく、「オブジェクトの集合で生成されるオブジェクト型ファイル単位で、ユーザーによって指示された場合にはさらにオブジェクト単位で」設定したものかどうかは明記されていない点。
　
５． 当審の判断
　相違点について
　オブジェクトに対するアクセス権限の設定で、「オブジェクトの集合で生成されるオブジェクト型ファイル単位で」設定することは、例えば、特開２００５−２８４８８３号公報の段落番号００３４、特開２００７−４５４９号公報の請求項３に記載されているように周知事項であり、「オブジェクト単位で」設定することも、例えば、特開２００６−１２００１３号公報の段落番号０００３〜０００５、特開２００５−１４９３７７号公報の段落番号００３５に記載されているように周知事項であり、「ユーザーによって指示された場合には」「オブジェクト単位で」設定することも、周知事項である設定方法の二者択一的選択であって、任意の事項である。
　引用例２の記載事項にあるように階層化したアクセス権限を設定することが、出願前公知であり、引用例１記載の発明においても、アクセス権限をどの様にするかは任意の事項であるから、上記の事項を考慮して、さらに、引用例２の記載事項を引用例１記載の発明に適用し、相違点の構成とすることは当業者が容易になし得たことである。
　
　以上のとおりであるから、相違点にかかる発明の構成は、引用例１記載の発明、引用例２の記載事項及び周知事項から当業者が容易に想到することができたものである。
　そして本願発明の効果も引用例記載の発明、引用例２の記載事項及び周知事項から当業者が推測できる範囲のものである。
　
６．むすび
　本願発明は引用例１記載の発明、引用例２の記載事項および周知事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その他の請求項について検討するまでもなく、拒絶すべきものである。
　よって、結論のとおり審決する。