【事件の表示】
　特願２００１−２１８４５２「会計処理のシステム、方法およびプログラム」拒絶査定不服審判事件〔平成１５年　１月３１日出願公開、特開２００３−　３０５７４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１３年７月１８日の出願であって、平成１５年１１月２１日付けで拒絶査定がなされ、これに対し、平成１６年１月７日に拒絶査定不服審判の請求がなされ、その後当審において平成２０年１月２２日付けで拒絶の理由が通知され、同年３月３１日付けで手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明は、平成２０年３月３１日付けの手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された次のとおりのものと認める。（以下、「本願発明」という。）
　
「　【請求項１】
　決算の単位である部門単位と対応する、全社においてユニークな部門単位番号を含む電子伝票を起票する伝票起票手段と、
　起票された電子伝票の内容を、部門単位番号と関連付けて記憶する伝票データベースと、
　各部門単位の決算の区分を部門単位番号と関連付けて記憶する部門マスター・データベースと、
　前記伝票データベースの内容と前記部門マスター・データベースの内容を部門単位番号によって組み合わせて、他のデータベースを使用せずに会計帳簿を作成する会計帳簿作成手段であって、前記部門マスター・データベースを検索して、決算の区分ごとにその対象となる部門単位番号を求め、さらに前記伝票データベースを検索して、該部門単位番号から決算の対象となる電子伝票を収集し、さらに該収集された電子伝票に基いて会計帳簿を作成する会計帳簿作成手段とを含む会計処理システム。」
　
３．当審の拒絶理由
　一方、当審において平成２０年１月２２日付けで通知した拒絶の理由の概要は、
「本願の請求項１〜９に係る発明は、引用例１〜４記載の発明、及び、周知事項に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　（引用例１）田宮治雄著、「会計情報システムの機能と構造」、初版、株式会社中央経済社、平成６年１１月３０日、ｐ．８９−１２９
　（引用例２）福田剛志　外２名、「データベース最前線　第１０回　データマイニング−巨大データからの知識発見（１）」、ｂｉｔ、共立出版株式会社、２０００年１０月１日、第３２巻、第１０号、ｐ．７７〜８３
　（引用例３）向山秀人、「リレーショナルデータベース　第２回　ＳＱＬによるデータ操作」、アスキーＮＴ、株式会社アスキー、１９９９年３月１日、第４巻、第３号、ｐ．１６４〜１６７
　（引用例４）特開平１０−２９３７９８号公報　」
というものである。
　
４．引用例
　［引用例１］
　そこで、前記拒絶の理由に引用された、田宮治雄著、「会計情報システムの機能と構造」、初版、株式会社中央経済社、平成６年１１月３０日、ｐ．８９−１２９（以下、「引用例１」という。）の記載を検討するに、引用例１には、図面と共に次の事項が記載されている。
　
（ア）「業務統合型会計情報システムの構造」（第８９頁第２行目）
　
（イ）「３　取引データベースの確立
　取引入力システムから入力された取引データは，業務システム全体の共有の資源であり，どの業務システムからも必要に応じて等しく利用できる形にしておかなければならない。そのためには入力されたすべての取引データをひとつのデータベースに納め，どの業務システムからも容易にアクセスできるようにしておくことが望ましい。」（第９１頁第６〜１１行目）
　
（ウ）「４　業務システムによる取引データの受け入れ
　取引データの入力を取引データ入力システムに任せた業務システムでは，情報を生成するために必要となる取引データを取引データベースから識別し，それを抽出して自らのシステム領域に受け入れることとなる。」（第９２頁第１〜４行目）
　
（エ）「（１）帳簿管理・会計報告システム
　まず，帳簿管理については，作成される帳簿が経営資源を管理，保全するうえで重要な役割を果たすとともに，会計報告の基礎となる情報を管理するという役割をも合わせ持つのであった。また，商法や税法などの法規を遵守する立場からも，財務会計報告書は帳簿に基づき作成されなければならない。
　そこで，会計情報システムでは，帳簿管理を行う業務システムで管理する業務データベース（以下，このデータベースを帳簿データベースと呼ぶ）の取引データに基づき損益計算書や貸借対照表などの財務会計報告書を作成することで帳簿と財務会計報告との首尾一貫性をシステム的に保証することが望まれる。」（第９４頁第１９行目〜第９５頁第４行目）
　
（オ）「１　帳簿管理モジュールの対象
　帳簿管理は，企業活動の結果である取引などの中から会計処理の対象とする取引を識別し，それをもとに帳簿を作成して経営資源の管理保全に役立てるとともに，財務会計報告，業績評価会計報告において，法規に定められた，あるいは利用者に求められた情報を生成するためにデータを適切に管理しておくことを主要な任務とする仕事であった。帳簿管理モジュールはこの仕事を円滑に行うための図５−８のような情報システムの機能のグループである。具体的には，取引データベースの中から会計取引に該当するデータを識別し，それを抽出した上で，会計帳簿を作成し，同時に会計報告を行うときの基礎データとなる帳簿データベースに登録し，管理をするのである。」（第１０４頁第３〜１２行目）
　
（カ）「６　部門間付替取引に対する考慮
　さらに，ひとつの取引データから複数の会計取引データを生成することもある。典型的な例は，部門間で付替を行う取引である。つまり，内部の商品の移動や経費の付替など，取引自体はひとつであっても，業績評価のためには送り出す部門と受け入れる部門と双方で会計取引として認識しなければならないからである。これを両方の部門でそれぞれ入力する方法をとる場合，決算などにあたりいずれかの部門に未達の取引が生じ，調整のために本来は必要のない煩雑な仕事を行わなければならず，迅速な決算を行ううえでの障害となってしまう。帳簿管理モジュールでこうした内部取引に関する取引データからそれぞれの部門に対し適切な会計取引データを同時に生成することにより，この調整は不要となるのである。」（第１０６頁第１６〜２６行目）
　
（キ）「７　帳簿データベース
　手作業の会計処理であれば，会計取引は仕訳帳から元帳に転記され，定期的に試算表が作成される。帳簿管理モジュールでは，情報システムの内部に手書きの帳簿の役割を果たすデータベースを作成し，会計取引データを蓄積，管理する。この帳簿データベースには，財務会計上会計取引とされる取引データはもちろんのこと，当該企業が業績評価に必要と判断して会計取引として識別し，抽出を行った取引データすべてを登録し，利用しやすいように管理するのである。
　この帳簿データベースの特徴は，設計次第で会計取引データの多様な検索が可能となることである。すなわち，勘定科目をキーとして検索すれば元帳となり，日付をキーとすれば仕訳帳として利用できるのである。それだけではなく，取引データベースから適切なデータを抽出して帳簿データベースの会計取引データに加えておけば，特定の部門，地域，あるいはプロジェクトなどに限定した取引の抽出が可能であり，あたかもそれらの切り口で元帳を用意しているかのごとく取引データを利用できるのである。データベース管理ソフトウェアの充実によって可能となった多元的な「元帳」をいかに利用するかが，会計情報システム全体の有効性を向上させる鍵である。
　ただし，この帳簿データベースで管理される取引データが財務会計報告，業績評価会計報告のいずれの報告書を作成する場合にもその基礎データとなるので，不足があったり，法規や利用者が求める分類表示が不可能とならないよう十分に詳細に分類された勘定科目を付したうえで管理されなければならない４）。」（第１０７頁第１〜２０行目）
　
（ク）「１０　会計処理の基礎となるデータベース
　帳簿管理モジュールでは，帳簿データベースのほかにも，会計情報システムの運用上欠くことのできない基礎的なデータベースの管理を行う。主なものをあげると，次のとおりである。
　・・・中略・・・
（２）部門体系
　部門別の業績評価会計報告あるいはセグメント別の会計報告を行うためには，その企業の部門および部門間の関係を管理するとともに，ほかの業務サイクルの情報システムと整合性を持たせる必要がある。なお，原価計算もしくは業績評価のための配賦計算を行う場合には，この部門体系を管理するデータベースが部門に関連する配賦計算の基礎データをも合わせて管理することになろう。」（第１０８頁第１５行目〜第１０９頁第２０行目）
　
（ケ）「第６節　帳簿管理・会計報告システム
　　−財務会計報告モジュール−
　・・・中略・・・
１．帳簿データベースの利用
　帳簿管理モジュールにおいて取引情報がもれなく正確に把握されており，会計報告に必要なそのほかの基礎的な情報も適切に管理されていることを前提にすれば，財務会計報告モジュールは，図５−１０に示すように基本的には帳簿データベースより必要なデータを抽出し，定められたルールに従って会計報告書を作成する役割を果たすことになる。」（第１１１頁第３行目〜第１１２頁第１行目）
　
（コ）「６　作成する財務会計報告書
　財務会計報告モジュールにおいては，以上のような枠組みで企業外部の利害関係者に報告するための会計報告書を作成するが，第３章で述べたとおり，わが国の企業は３種類の法規に従った会計報告書を作成して開示しなければならない。これらの法規に基づく会計情報の開示要求の詳細は，財務会計報告モジュールにおいては帳簿データベースで管理されている仕訳データとそれぞれの会計報告書に表示される項目の間の関係すなわち報告書作成ルールとして登録され，会計情報システムがそれぞれの会計報告書を作成するときに機能することになる。以下こうして作成される会計報告書について概観することにする。」
　・・・中略・・・
　賃借対照表と損益計算書は商法会計の代表的な計算書類であり，帳簿管理モジュールにおいて作成する会計帳簿に基づいて作成されなければならないので，当然会計情報システムにおいて作成されることとなる。」（第１１８頁第９行目〜第１１９頁第１４行目）
　
（サ）「多角化した企業の業績を事業分野別，地域別，市場別に開示し，会計報告書の利用者である投資家が当該企業の収益構造をより明確に把握できるようにすることをねらったセグメント別会計情報も，今後充実されるであろう。このセグメント別会計に必要な取引データは，原則として取引データベースにおいて管理されているはずであるので，帳簿管理モジュールの抽出処理を経て財務会計報告モジュールで作成が可能である。」（第１２６頁第２２〜２７行目）
　
　上記摘記事項（ア）〜（サ）、及び、図面によれば、引用例１には次の発明（以下、「引用発明１」という。）が記載されている。
　
「　取引データを入力する取引入力システムと、
　入力された取引データを納める取引データベースと、
　セグメント別の会計報告を行うために用いられ、企業の部門および部門間の関係を管理する部門管理データベースと、
　取引データベースの中から抽出した取引データを蓄積する帳簿データベースと、
　前記取引データベース、部門管理データベース、及び、帳簿データベースを使用して会計報告を作成するモジュールであって、取引データベースの中からセグメント別会計に必要な取引データを識別し、それを抽出して帳簿データベースに蓄積し、帳簿データベースに蓄積された取引データを利用して会計報告を作成する、帳簿管理モジュール及び財務会計報告モジュールからなるモジュールと、
を含む会計情報システム。」
　
［引用例２］
　前記拒絶の理由に引用された、福田剛志　外２名、「データベース最前線　第１０回　データマイニング−巨大データからの知識発見（１）」、ｂｉｔ、共立出版株式会社、２０００年１０月１日、第３２巻、第１０号、ｐ．７７〜８３（以下、「引用例２」という。）には、表や図面とともに次の事項が記載されている。
　
（シ）「３　データウェアハウスとＯＬＡＰ
　例えばある企業の売り上げデータとして，「いつどの店舗でどの商品を誰にいくらでどれだけの量販売した」という事実がデータベースの表１のようなテーブルに登録されているとする．この会社の販売したものをすべてこのテーブルに記録しておけば，それを集計することによって，この会社がどの商品でどの顧客からいくら収益を上げているかといったことをいつでも調べることができる．このような事実を集めた表をファクトテーブル（ｆａｃｔ ｔａｂｌｅ）と呼ぶ．
　このファクトテーブルをユーザの興味に従っていろいろな角度から集計するために，店舗，商品，顧客の分類や時間の階層（週，月，四半期，年度など）を表す別のテーブルを用意する．例えば，表２のような店舗を分類するリレーションがあれば，表１のファクトテーブルとジョインすることにより，店舗形態ごと，地域ごと，県ごとの売り上げを集計することができる．図１と表３は地域ごとの第２四半期の売上高を集計する問い合わせとその結果の例である．
　この店舗データのように集計の軸となる値を保持するリレーションを次元テーブル（ｄｉｍｅｎｓｉｏｎ ｔａｂｌｅ）と呼ぶ．このようにファクトテーブルの周りに次元テーブルをいくつか持つようなスキーマをスタースキーマ（ｓｔａｒ ｓｃｈｅｍａ）という（図２）．」（第７８頁中央欄第２行目〜右欄第１６行目）
　
　引用例２において、地域ごとの売り上げを集計して表３の結果を得る際には、地域が「東北」、「関東」、「九州」である店舗の売り上げを集計する過程で、第７８頁＜表１＞のテーブルに登録されている販売データのうち、店舗が「東北」、「関東」、「九州」に属する販売データがそれぞれ抽出されることは自明である。
　
　上記摘記事項（シ）、表１〜３、及び、図１〜２によれば、引用例２には次の発明が記載されている。
　「ある企業の売り上げデータとして、いつどの商品を誰にいくらでどれだけ販売したという事実を、店舗キー（商店１、商店２、商店３等）と関連付けて登録したファクトテーブルと、
　各店舗の店舗形態，地域，都道府県の分類を、店舗キー（商店１、商店２、商店３等）と関連付けて記憶する次元テーブルとを備え、
　ファクトテーブルと次元テーブルとをジョインすることにより、店舗の所定の分類毎に、当該分類に属する販売データを抽出する装置。」
　
［引用例３］
　前記拒絶の理由に引用された、向山秀人、「リレーショナルデータベース　第２回　ＳＱＬによるデータ操作」、アスキーＮＴ、株式会社アスキー、１９９９年３月１日、第４巻、第３号、ｐ．１６４〜１６７（以下、「引用例３」という。）には、表や図面とともに次の事項が記載されている。
　
（ス）「複数テーブルの結合
　１つのテーブルだけでなく、複数のテーブルを組み合わせて必要な情報を抜き出す「結合（ジョイン）」は、リレーショナルデータベースではよく行われる操作であり、リレーショナルデータベースならではの処理である。」（第１６６頁第８〜１４行目）
　
（セ）「副問い合わせ−入れ子のＳＥＬＥＣＴ文
　問い合わせの種類にはもう１つある。それが副問い合わせ（サブクエリー）である。ＳＱＬでは、ＷＨＥＲＥ句の中にＳＥＬＥＣＴ文を入れ子（ネスト）にすることができる。たとえば、表３と表４の２つのテーブルから、勤務地が虎ノ門である社員の社員番号と氏名を検索するＳＥＬＥＣＴ文は次のようになる。
　
ＳＥＬＥＣＴ　社員番号，氏名
ＦＲＯＭ　社員テーブル
ＷＨＥＲＥ　部署コード　ＩＮ　（ＳＥＬＥＣＴ　部署コード　ＦＲＯＭ　部署テーブル　ＷＨＥＲＥ　勤務地＝’虎ノ門’）
　
検索結果：
社員番号　氏名
−−−−−−−−−−−−−−−
１００１０　佐藤　浩二
１００３０　加納　貴子
２０００１　菅野　洋美
２０００２　安藤　栄
　
　このＳＥＬＥＣＴ文の検索条件は、ＩＮ以下のＳＥＬＥＣＴ文によって得られる検索結果、つまり「部署テーブルから抜き出した、勤務地が虎ノ門である部署コードの集合に、社員テーブルの部署コードが含まれること」である。その条件にあてはまる社員番号と氏名を、社員テーブルから抜き出すことになる。言葉にすると少々複雑だが、検索結果を見れば容易に理解できるだろう。ところで、このＳＥＬＥＣＴ文は結合を使って次のように書き換えることもできる。
　
ＳＥＬＥＣＴ　社員番号，氏名
ＦＲＯＭ　社員テーブル，部署テーブル
ＷＨＥＲＥ　社員テーブル．部署コード＝部署テーブル．部署コード
ＡＮＤ　部署テーブル．勤務地＝’虎ノ門’
　
　もちろん上記のＳＥＬＥＣＴ文も、サブクエリーを使用した場合と同じ検索結果を返す。
サブクエリーか結合かはＲＤＢＭＳや個々の実装によってバフォーマンスが得られるほうを選択すればよいだろう。」（第１６６頁中央欄第１３行目〜右欄第２０行目）
　
　上記摘記事項（ス）〜（セ）、表３、表４によれば、引用例３には次の事項が記載されている。
　「社員番号、氏名、入社年度を部署コードと関連付けて格納した社員テーブルと、
　部署名、及び、勤務地を、部署コードと関連付けて格納した部署テーブルとを備え、
　前記社員テーブル及び部署テーブルを基に、勤務地が所定地（虎ノ門）である社員の社員番号と氏名を求める方法として、
　１）結合（ジョイン）、
　２）「『部署テーブルから抜き出した、勤務地が所定地（虎ノ門）である部署コードの集合に、社員テーブルの部署コードが含まれる』という条件にあてはまる社員番号と氏名を、社員テーブルから抜き出す」というサブクエリー、
の２つがあり、サブクエリーか結合かはＲＤＢＭＳや個々の実装によってバフォーマンスが得られるほうを選択すればよいこと」
　
［引用例４］
　前記拒絶の理由に引用された、特開平１０−２９３７９８号公報には、図面とともに次の事項が記載されている。
　
（ソ）「【特許請求の範囲】
【請求項１】 部門ごとに発生する数値情報を集計する単位として、複数の部門パターンごとに部門コードを集計する装置において、部門パターン別に集計部門情報を入力する部門パターン入力部と、前記部門パターン情報を表示する部門パターン表示部と、前記部門パターン情報を保存する部門パターン格納部と、前記部門パターンを情報を解析する部門パターン解析部と、前記部門パターンごとに帳票を出力するための部門パターンを入力する部門パターン別帳票指定入力部と、前記部門パターンごとに数値情報を集計する部門パターン別実績集計部と、部門パターン別帳票出力部とを備えることを特徴とする部門パターン集計装置。
【請求項２】 帳票出力前に、部門コード単位で科目ごとの実績データが実績ファイルに蓄積されるとともに、帳票として集計して数値を確認したい部門パターンを部門パターン格納部に設定し、それぞれの部門パターンには部門コードを集計する集計部門コードを設定し、その中に前記実績ファイルに存在する部門コードを設定し、帳票出力時には前記部門パターン別帳票指定入力部より、帳票出力すべき部門パターンを指定し、前記部門パターン別実績集計部は、前記部門パターン別帳票指定入力部にて指定されて前記部門パターン格納部に設定された前記集計部門コード別に、前記実績ファイルの部門コード別実績を集計し、前記部門パターン別帳票出力部は、前記部門パターン別実績集計部にて集計された結果を出力することを特徴とする請求項１記載の部門パターン集計装置。」
　
（タ）「【００１７】
【発明の効果】本発明によれば、組織単位、プロジェクト単位等の複数のグループ情報が部門パターンとして登録することができ、帳票出力順は、部門パターン表の集計部門順に出力されるので、部門コードづけが一意であればシステムのコード付けルールに縛られることがないため、コード管理が単純になる。
【００１８】又、本発明によれば、部門パターンごとの実績が帳票出力時に集計されるためディスク用量が節約される。
【００１９】又、本発明によれば、必要な管理体系が部門パターン表に設定され、伝票入力時は部門コードが１種類であるため、日々の運用において伝票入力者への負荷が軽減される。
【００２０】又、本発明によれば、組織体系の変更、プロジェクトの新規発足等、集計単位の変更が発生しても、実績ファイルを変更することなく、部門パターン表を変更するだけで済むため、集計単位の変更の際の作業が容易になり、戦略的な実績把握が可能になる。」
　
（チ）図２には、部門コードとして、本社管理に“００１”、本社営業に“００２”、本社企画に“００３”、Ａ支店管理に“００４”、Ａ支店営業に“００５”、Ａ支店企画に“００６”、Ｄ支社管理に“０１３”、Ｄ支店営業に“０１４”、Ｄ支店企画に“０１５”が、それぞれ割り当てられることが図示されている。
　
　上記摘記事項（ソ）〜（チ）、及び、図面によれば、引用例４には次の事項が記載されている。
　「部門に対応して付与する部門コードを、本店・支店からなる会社全体において１種類のコードとし、伝票を当該１種類の部門コードとともに入力すること」
　
　
５．対比
　本願発明と引用発明１とを対比する。
ａ）引用発明１において、作成する会計報告として決算書が想定されていることは、上記摘記事項（カ）の「迅速な決算」との記載や、摘記事項（コ）の「賃借対照表と損益計算書」との記載、摘記事項（サ）の「会計報告書の利用者である投資家が当該企業の収益構造をより明確に把握できるようにする」という会計報告の目的等から明らかである。したがって、引用発明１における「セグメント」は、本願発明における「決算の区分」に相当し、引用発明１における「セグメント別会計に必要な取引データ」は、本願発明において、決算の対象となる電子伝票に対応する。
ｂ）引用発明１における「部門」は、本願発明における「部門単位」に相当する。
ｃ）電子伝票は、会社・商店などにおける、金銭の出入や取引内容などを記入したデータであるから、「取引データ」の一種であるといえる。そして、本願発明における「伝票起票手段」と、引用発明１における「取引入力システム」とは、ともに取引データを入力する手段（以下、「取引データ入力手段」という。）である点で共通する。
ｄ）本願発明における「伝票データベース」と引用発明１における「取引データベース」とは、ともに、入力された取引データを記憶するデータベース（以下、「取引データ・データベース」という。）である点で共通する。
ｅ）本願明細書第【０００４】段落には「本支店ごとの損益計算書、貸借対照表、債権債務内訳一覧表、科目内訳明細票などの会計帳簿を作成する。」と記載されており、会計帳簿を作成することの具体例として決算書を作成することが記載されている。一方、上記ａ）に前記したとおり、引用発明１では、作成する会計報告として決算書が想定されている。したがって、引用発明１における、会計報告を作成することは、本願発明における、会計帳簿を作成することに相当する。
ｆ）本願発明における「部門マスター・データベース」と引用発明１における「部門管理データベース」とは、ともに、部門に関する情報を提供するデータベース（以下、「部門情報提供データベース」という。）である点で共通する。
ｇ）本願発明における「会計帳簿作成手段」と引用発明１における「帳簿管理モジュール及び財務会計報告モジュールからなるモジュール」とは、ともに、取引データ・データベースの内容と部門情報提供データベースの内容を利用して会計帳簿を作成する手段であって、取引データ・データベースを検索して、決算の対象となる取引データを収集し、さらに該収集された取引データに基いて会計帳簿を作成する会計帳簿作成手段である点で共通する。
ｈ）引用発明１の「会計情報システム」も会計処理システムの一種である。
　
　したがって、本願発明と引用発明１とは、
　「取引データを入力する取引データ入力手段と、
　入力された取引データを記憶する取引データ・データベースと、
　部門に関する情報を提供する部門情報提供データベースと、
　取引データ・データベースの内容と部門情報提供データベースの内容を利用して会計帳簿を作成する会計帳簿作成手段であって、取引データ・データベースを検索して、決算の対象となる取引データを収集し、さらに該収集された取引データに基いて会計帳簿を作成する会計帳簿作成手段とを含む会計処理システム。」
の点で一致し、以下の点で相違する。
　
（相違点１）
　本願発明では、取引データが、部門単位番号を含む電子伝票であり、取引データ入力手段が、当該電子伝票を起票するものであるのに対し、引用発明１の取引データは、部門単位番号を含む電子伝票ではなく、取引データ入力システムは、電子伝票を起票するものではない点。
　
（相違点２）
　取引データ・データベースが、本願発明では、起票された電子伝票の内容を部門単位番号と関連付けて記憶する伝票データベースであるのに対し、引用発明１の取引データベースは、取引データを記憶するものの、部門単位番号と関連付けて記憶するものではない点。
　
（相違点３）
　部門情報提供データベースが、本願発明では、各部門単位の決算の区分を部門単位番号と関連付けて記憶する部門マスター・データベースであるのに対し、引用発明１の部門管理データベースは、各部門単位の決算の区分を部門単位番号と関連付けて記憶するものではない点。
　
（相違点４）
　会計帳簿作成手段における、取引データ・データベースから決算の対象となる取引データを収集するための処理が、本願発明では、部門マスター・データベースを検索して、決算の区分ごとにその対象となる部門単位番号を求め、さらに伝票データベースを検索して、該部門単位番号から決算の対象となる電子伝票を収集するものであるのに対し、引用発明１は、そうではない点。
　
（相違点５）
　会計帳簿作成手段において、本願発明では、伝票データベースの内容と部門マスター・データベースの内容を部門単位番号によって組み合わせるのに対し、引用発明１では、取引データベースの内容と部門管理データベースの内容を部門単位番号によって組み合わせるとはされていない点。
　
（相違点６）
　本願発明は、他のデータベースを使用せずに会計帳簿を作成するのに対し、引用発明１は帳簿データベースを使用して会計帳簿を作成する点。
　
（相違点７）
　本願発明では、部門単位番号が決算の単位と対応し、かつ、全社においてユニークな番号であるのに対し、引用発明１はそうではない点。
　
６．判断
　そこで、上記相違点について判断する。
　
（相違点１について）
　企業における取引データの入力を電子伝票の起票により行うことは、本願出願前より広く行われていることである。また、どの部門で生じた伝票かを計算機上で識別できるよう、伝票が部門単位番号（部門コード）を含むことも、引用例４に記載されているように一般的なことである。
　したがって、引用発明１において、取引データを、部門単位番号を含む電子伝票とし、取引データ入力手段を、電子伝票の起票を行うものとすることは、当業者が普通に考えることである。
　
（相違点２〜４について）
　引用例１の摘記事項（キ）の「取引データベースから適切なデータを抽出して帳簿データベースの会計取引データに加えておけば，特定の部門，地域，あるいはプロジェクトなどに限定した取引の抽出が可能であり，あたかもそれらの切り口で元帳を用意しているかのごとく取引データを利用できるのである。」や「この帳簿データベースで管理される取引データが財務会計報告，業績評価会計報告のいずれの報告書を作成する場合にもその基礎データとなる」との記載から、引用発明１は、取引データベースにある取引データの中から特定の部門、地域あるいはプロジェクトなどに限定した取引を抽出して会計報告を作成するものといえる。また、引用例１の摘記事項（サ）にあるように、セグメント別の会計報告は、多角化した企業の業績を事業分野別や地域別に開示するものであるから、引用発明１は、例えば、事業分野別の会計報告を作成する時は取引データベースの中から所定の事業分野で発生した取引データを抽出し、地域別の会計報告を作成する時は取引データベースの中から所定の地域で発生した取引データを抽出して、それぞれの会計報告を作成するものといえる。
　そこで、このようなデータ抽出を実現するための計算機システムの構成として本願発明と同様の構成が容易に想到し得たかの検討を通じて、相違点２〜４について判断する。
　
　引用例２には、
「ある企業の売り上げデータとして、いつどの商品を誰にいくらでどれだけ販売したという事実を、店舗キー（商店１、商店２、商店３等）と関連付けて登録したファクトテーブルと、
　各店舗の店舗形態，地域，都道府県の分類を、店舗キー（商店１、商店２、商店３等）と関連付けて記憶する次元テーブルとを備え、
　ファクトテーブルと次元テーブルとをジョインすることにより、店舗の所定の分類毎に、当該分類に属する販売データを抽出する装置」の発明（以下、「引用発明２」という。）が記載されている。
　引用発明１と引用発明２とは、ともに企業業績を分析するための装置である点で技術分野が一致し、取引実績を表すデータを蓄積したデータベースをいろいろな角度から分析可能とする課題も共通している。また、引用発明１と引用発明２の各構成要素が、
１）引用発明２における「売り上げデータ」が、引用発明１における「取引データ」と対応し、
２）引用発明２における「店舗」が、引用発明１における「部門」と対応し、
３）引用発明２における「各店舗の店舗形態，地域，都道府県の分類」が、引用発明１における「セグメント」と対応し、
４）引用発明２における「ファクトテーブル」が、引用発明１における「取引データベース」と対応し、
５）引用発明２の「次元テーブル」が、引用発明１における「部門管理データベース」と対応する、
という対応関係にあることも、当業者が容易に理解できることである。
　さらに、キーの値として数字（番号）を用いることは、引用例３の「部署コード」がそうであるように、データベースの技術分野における技術常識である。また、（相違点１について）に記載したとおり、取引データの入力を、部門単位番号を含む電子伝票の起票により行うことは、当業者が普通に考えることである。
　そうすると、引用発明１において引用発明２を参酌し、取引データ・データベースを、起票された電子伝票の内容を部門単位番号と関連付けて記憶する伝票データベースとし、部門情報提供データベースを、各部門単位の決算の区分（セグメント）を部門単位番号と関連付けて記憶する部門マスター・データベースとすることは、当業者が容易に想到し得たことといえる。
　よって、相違点２，３は格別なものではない。
　
　次に、上記したとおり、引用発明１において引用発明２を参酌し、取引データ・データベースおよび部門情報提供データベースを、本願同様の伝票データベースおよび部門マスター・データベースとすることは、当業者が容易に想到し得たことであるが、当該引用発明２には、販売データが所定の分類（「東北」、「関東」、「九州」）に属するデータを抽出するためにジョイン（結合）演算を使用したものが記載されているから、引用発明１において、所定のセグメントに属する取引データを抽出するデータベース演算としてジョイン演算を用いることは容易である。ここで、引用例３に、
「社員番号、氏名、入社年度を部署コードと関連付けて格納した社員テーブルと、
　部署名、及び、勤務地を、部署コードと関連付けて格納した部署テーブルとを備え、
　前記社員テーブル及び部署テーブルを基に、勤務地が所定地（虎ノ門）である社員の社員番号と氏名を求める方法として、
　１）結合（ジョイン）、
　２）「『部署テーブルから抜き出した、勤務地が所定地（虎ノ門）である部署コードの集合に、社員テーブルの部署コードが含まれる』という条件にあてはまる社員番号と氏名を、社員テーブルから抜き出す」というサブクエリー、
の２つがあり、サブクエリーか結合かはＲＤＢＭＳや個々の実装によってバフォーマンスが得られるほうを選択すればよいこと」
が記載されているように、ジョインを用いた場合と同じ演算結果を得るデータベース演算としてサブクエリー演算があり、ジョイン／サブクエリーのいずれの演算を用いるかは当業者が適宜選択し得る設計的事項であることは、データベースの技術分野における技術常識であるから、引用発明１において、所定のセグメントに属する取引データを抽出するデータベース演算としてサブクエリー演算を用いることも、引用発明２及びデータベースの技術分野における技術常識に基いて当業者が容易に想到し得たことである。
　さらに、（相違点１について）に記載したとおり、取引データを、部門単位番号を含む電子伝票とすることは、当業者が普通に考えることである。
　したがって、引用発明１において、決算の対象となる取引データを抽出するための処理として、会計帳簿作成手段が、部門マスター・データベースを検索して、決算の区分ごとにその対象となる部門単位番号を求め、さらに伝票データベースを検索して、前記部門単位番号から決算の対象となる電子伝票を収集することは、引用発明２及びデータベースの技術分野における技術常識に基いて、当業者が容易に想到し得たことである。
　よって、相違点４は格別なものではない。
　
（相違点５について）
　（相違点２〜４について）で検討したとおり、決算の対象となる取引データを収集するための構成として、
「起票された電子伝票の内容を、部門単位番号と関連付けて記憶する伝票データベースと、
　各部門単位の決算の区分（セグメント）を、部門単位番号と関連付けて記憶する部門マスター・データベースとを備え、
　会計帳簿作成手段が、部門マスター・データベースを検索して、決算の区分ごとにその対象となる部門単位番号を求め、さらに伝票データベースを検索して、前記部門単位番号から決算の対象となる電子伝票を収集する」
構成は、引用発明２及びデータベースの技術分野における技術常識に基いて、当業者が容易に想到し得たことといえる。そして、当該構成では、会計帳簿作成手段が伝票データベースの内容と部門マスター・データベースの内容を部門単位番号によって組み合わせているから、引用発明１において、会計帳簿作成手段が伝票データベースの内容と部門マスター・データベースの内容を部門単位番号によって組み合わせることは、引用発明２及びデータベースの技術分野における技術常識に基いて、当業者が容易に想到し得たことである。
　
（相違点６について）
　引用発明１においては、取引データベースから抽出された取引データを帳簿データベースに蓄積しているが、抽出された取引データが帳簿管理モジュールあるいは財務会計報告モジュールにより情報処理可能に保持されていれば、その記憶態様はデータベースに限らず作業用ファイル等でもよいことは当業者に明らかであり、如何なる記憶態様を用いるかは当業者が適宜設計し得る事項である。また、取引データベースや部門管理データベースを除くその他のデータベースの使用／不使用についても、データベースを利用することによる得失を考慮の上、当業者が適宜選択し得る設計的事項である。したがって、引用発明１において、他のデータベースを用いずに会計帳簿を作成することは、当業者が容易に想到し得たことである。
　
（相違点７について）
　部門番号をユニークな番号とすることは、引用例４に記載されているように周知である。また、上記摘記事項（サ）にあるように、セグメント別の会計報告は、多角化した企業の業績を事業分野別や地域別に開示するものであるから、引用発明１において、多角化した企業を種々の観点から分析できるよう、取引データベースに多角化した企業全体の取引データを蓄積することは容易に想到し得ることである。その際、各取引データの発生部門を示す部門単位番号が多角化した企業全体に亘って付与される必要があることは明らかである。つまり、部門単位番号を「全社において」ユニークな番号とすることは容易である。
　また、会計報告に必要な取引データをデータベースから抽出する際に、検索キーとして部門単位番号を用いる構成においては、部門単位番号は、会計報告を得たい最小の企業組織単位毎に別々の番号を付与する必要があることは明らかである。つまり、部門単位番号を決算の単位に対応した番号とすることは容易である。
　したがって、引用発明１において、部門単位番号を、決算の単位と対応し、かつ、全社においてユニークな番号とすることは、当業者が容易に想到し得たことである。
　
　そして、本願発明の作用効果も、引用例１〜４の記載事項から当業者が予測できる範囲のものである。
　したがって、本願発明は、引用例１，２記載の発明、データベースの技術分野における技術常識、及び、周知事項に基いて、当業者が容易に発明をすることができたものである。
　
７．むすび
　以上のとおり、本願発明は、引用例１，２記載の発明、データベースの技術分野における技術常識、及び、周知事項に基いて、当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。