JP2009211366A - データベースシステム - Google Patents

Abstract

【課題】データベースのシステム開発効率およびメンテナンス性を向上する。
【解決手段】このデータベースシステムは、複数の適用先から共通にアクセスされ、外部からは項目の追加／削除が不可能な共通情報と、適用先毎にアクセス可能であり、適用先毎に設定された独自情報とが格納されたデータベース５０に対して共通エンジン１０がアクセスするものであり、データベース５０の管理項目マスタ５４の対応情報を参照し拡張案件データテーブル４４ｂに新たな項目が追加または削除された場合、該当項目については、拡張案件データテーブル４４ｂを参照して該当する案件データの照会と登録を行うためのＳＱＬ文と、案件データと項目とを対応付けるマッピング設定ファイルを生成するシステム構築支援部１２ｃを備える。
【選択図】図１

Description

本発明は、特許、実用新案、意匠、商標などの知的財産権に関する情報をデータベースで管理するデータベースシステムに関する。

近年、内外の特許、実用新案、意匠、商標などの出願、審査請求、中間処理などの期限管理、登録後の年金管理などを行うためのデータベースシステムとして知的財産管理システムの有用性が高まってきている。

この知的財産管理システムは、例えば特許事務所や、特許事務所へ特許出願を依頼する企業などの適用先にそれぞれ導入されている。

特許事務所および企業などでは、知的財産管理システムにそれぞれ独自の情報を溜め込んでおり、必要に応じて互いの間で情報を送受信している。

例えば特許事務所から見た企業の情報は、客先であり、企業から見た特許事務所は、依頼先であり、それぞれの側で、管理用画面などのユーザーインターフェースやデータベースの対応付けが異なるものの、特許事務所では、客先の案件番号と自事務所で付与した独自の管理番号とを対応付けて管理している一方、企業でも自社の提案番号と事務所の管理番号とを対応付けて管理しているため、管理項目名は異なるものの提案番号と管理番号との対応関係で見た場合、データ構成自体は同じものとなっている場合が多い。

また、インターネットなどのネットワーク環境の充実により、インターネット上のApplication Service Provider（以下「ＡＳＰ」と称す）として、複数のクライアントに対してインターネットを介して知的財産権の管理業務を提供するシステムも提案されている（例えば特許文献１参照）。
特開２００２−７３８３８公報

企業や特許事務所がＡＳＰサービス等を利用する場合、同一のＡＳＰサービスを利用するもの同士であっても、企業間または事務所と企業間は、それぞれの知的財産権の情報を各自で独自に保有するため、情報共有は原則的に行われない。

企業間で情報を共有する場合であっても、情報を処理するアプリケーションは、予め決められた固定企業間でしかも同一ビジネスロジック上でしか動作しないように制限されており、例えば特許出願などの場合、案件単位に共願者が変わるなど、共有企業が変化するような場合は、情報の共有化が実現できないのが現状である。

一方、ＡＳＰサービス事業者にとっては、企業や事務所では、独自性の強いＧＵＩやアプリケーション機能のニーズが高まっており、プログラムを個別に作成するしかなく、システムの開発負荷が大きいという問題があった。

また、法律改正などが行われる際、または業務内容に変更が生じた際に、ＡＳＰサービス事業者にとっては、メンテナンス作業で、システム全体（ソフトウェアおよびハードウェア）を見直すことになるため、そのときにメンテナンス作業者の負荷が急に大きくなる。これら２つの課題を同時に解決できる仕組みが求められている。

本発明はこのような課題を解決するためになされたもので、企業間および企業と事務所間で知的財産権の情報を共有可能にすると共に、システム開発効率およびメンテナンス性を向上することのできるデータベースシステムを提供することを目的とする。

上記の課題を解決するために、本発明のデータベースシステムは、複数の適用先から共通にアクセスされ、外部からは項目の追加／削除が不可能な共通情報と、適用先毎にアクセス可能であり、適用先毎に設定された独自情報とが格納されたデータベースに対してデータ処理エンジンがアクセスするデータベースシステムにおいて、前記データ処理エンジンが、前記データベースの各案件のデータへアクセスするために定義されたアクセス情報と、前記データ処理エンジン以外のアプリケーションにより前記アクセス情報を拡張して定義された拡張アクセス情報と、前記アクセス情報と前記データベースの案件データテーブルとの対応関係、前記拡張アクセス情報と前記データベースの前記拡張案件データテーブルとの対応関係が設定されたアクセス情報対応情報とが記憶された記憶部を備え、前記データベースが、前記データ処理エンジンにより定義され、前記共通情報および独自情報それぞれ１つにつき１レコードとなるように作成された案件データテーブルと、前記案件データテーブルを継承して生成され、前記データ処理エンジン以外のアプリケーションにより定義され、前記独自情報に新たな項目を追加または削除するための拡張案件データテーブルと、前記案件データテーブルおよび前記拡張案件データテーブルの各データと前記データ処理エンジンの側に設定されたアクセス情報および拡張アクセス情報との対応情報が記憶される管理項目マスタとを備え、前記管理項目マスタの対応情報を参照して前記拡張案件データテーブルに新たな項目が追加または削除された場合、該当項目については、前記拡張案件データテーブルを参照して該当する案件データの照会と登録を行うための命令文と、前記案件データと項目とを対応付けるマッピング情報を生成するシステム構築支援部を具備したことを特徴とする。

本発明によれば、企業および事務所相互に知的財産権の情報が共有可能になると共に、システム開発効率およびメンテナンス性を向上することができる。

以下、本発明の実施の形態について図面を参照しながら説明する。図１は本発明の一つの実施の形態に係る知的財産管理システムの構成を示すブロック図、図２は図１の知的財産管理システムのデータベースの構成を示す図である。

図１に示すように、この知的財産管理システムは、Application Service Provider（以下「ＡＳＰ」と称す）事業者のデータセンターに設置されたサーバコンピュータ１、特許の出願人または中間処理の手続き人である企業Ｂに設置されるクライアントコンピュータシステム８、個別企業のために情報システムを構築するSystem Integrator（以下「ＳＩｅｒ」と称す）の会社Ｃに設置されるクライアントコンピュータシステム７、特許事務所など、企業Ｂの代理業務を行う事務所Ａに設置されるクライアントコンピュータシステム９、手続き対象機関（日本では特許庁など）に設置されるクライアントコンピュータシステム６などを、ネットワーク５を介して接続して構成されている。

事務所Ａのクライアントコンピュータシステム９は、クライアントコンピュータ９２と通信部９１とを有している。

通信部９１は、クライアントコンピュータ９２とサーバコンピュータ１とをネットワーク５を介して接続するＬＡＮ、ハブ、ルータなどの機器である。

会社Ｃのクライアントコンピュータシステム７は、クライアントコンピュータ７２と通信部７１とを有している。

通信部７１は、クライアントコンピュータ７２とサーバコンピュータ１とをネットワーク５を介して接続するルータなどの通信機器である。

企業Ｂのクライアントコンピュータシステム８は、クライアントコンピュータ８２と通信部８１とを有している。通信部８１は、クライアントコンピュータ８２とサーバコンピュータ１とをネットワーク５を介して接続するルータなどの通信機器である。

サーバコンピュータ１およびクライアントコンピュータ７２，８２，９２は、プログラムを実行するＣＰＵ（Central Processing Unit）などの制御装置、実行中のプログラムやデータなどを記憶すると共にデータ処理における作業領域となるメインメモリであるＲＡＭ（Random Access Memory）などの主記憶装置、記憶手段としてのデータベース（以下ＤＢと称す）、プログラムやデータを蓄積するハードディスクドライブなどの補助記憶装置、キーボードやマウスなどの入力装置、および表示装置などで構成されている。

クライアントコンピュータ７２，８２，９２のハードディスクドライブには、ウェブブラウザなどの汎用のウェブ閲覧ソフトウェアがインストールされている。利用者は、ウェブブラウザからサーバコンピュータ１へアクセスしログインする。

サーバコンピュータ１は、単体のコンピュータで構成してもよく、機能ごとの複数のコンピュータをネットワークで接続したネットワークシステムなどで構成してもよい。

ネットワーク５としては、例えばインターネット環境を実現するためのネットワークであり、物理的な通信ケーブルとしては、例えばメタル回線などの電話回線、ＩＳDＮ回線、光回線、１０／１００ＢＡＳＥ−Ｔなどのローカルエリアネットワークケーブル（以下ＬＡＮケーブルと称す）およびこれらのケーブルをインターネットに接続する通信ユニット（光モデム、ターミナルアダプタ）などで実現される。

サーバコンピュータ１のハードディスク装置には、共通エンジン１０などと呼ばれる処理モジュール群と、企業Ｂ毎または会社Ｃ毎に設計されたアプリケーションソフトウェア１１，１２と、事務所Ａに向けて設計されたアプリケーションソフトウェア１３とがインストール、つまり業務アプリケーションが実行可能に記憶されている。アプリケーションソフトウェア１１，１２，１３を業務処理要求部という。

企業Ｂは、例えばある特許出願案件についての出願人である。企業Ｂ向けのアプリケーションソフトウェア１１は、企業向けワークフロー・ビジネスロジック（以下「企業向けＷＢＬ」と称す）１１ａと、企業向けグラフィック・ユーザ・インターフェース（以下「企業向けＧＵＩ」と称す）１１ｂとを有している。

ＳＩｅｒ向けのアプリケーションソフトウェア１２は、ＳＩｅｒ向けワークフロー・ビジネスロジック（以下「ＳＩｅｒ向けＷＢＬ」と称す）１２ａと、ＳＩｅｒ向けグラフィック・ユーザー・インターフェース（以下「ＳＩｅｒ向けＧＵＩ」と称す）１２ｂとを有している。

事務所Ａ向けのアプリケーションソフトウェア１３は、事務所向けワークフロー・ビジネスロジック（以下「事務所向けＷＢＬ」と称す）１３ａと、事務所向けグラフィック・ユーザ・インターフェース（以下「事務所向けＧＵＩ」と称す）１３ｂとを有している。企業向けＧＵＩ１１ａ，ＳＩｅｒ向けＧＵＩ１２ｂおよび事務所向けＧＵＩ１３ｂは、事務所Ａ、企業Ｂ、会社Ｃおよび手続き対象機関６毎に設けられたユーザーインターフェース部である。

企業向けＷＢＬ１１ａ，ＳＩｅｒ向けＷＢＬ１２ａ、事務所向けＷＢＬ１３ａは、事務所Ａ、企業Ｂ，会社Ｃおよび手続き対象機関６毎に設けられたビジネスロジック部である。

企業向けＷＢＬ１１ａ，ＳＩｅｒ向けＷＢＬ１２ａ，事務所向けＷＢＬ１３ａは、ユーザからの指示で処理要求を共通エンジン１０へ発行する。

具体的には、企業向けＷＢＬ１１ａ，ＳＩｅｒ向けＷＢＬ１２ａ，事務所向けＷＢＬ１３ａは、企業向けＧＵＩ１１ｂ，ＳＩｅｒ向けＧＵＩ１２ｂおよび事務所向けＧＵＩ１３ｂから入力された指示に従って業務実行要求を共通エンジン１０へ発行すると共に、業務実行要求により共通エンジン１０が業務処理を実行した結果を要求元の企業向けＧＵＩ１１ｂ，ＳＩｅｒ向けＧＵＩ１２ｂおよび事務所向けＧＵＩ１３ｂへ出力する。

企業向けＷＢＬ１１ａおよび事務所向けＷＢＬ１３ａは、受任管理、請求管理、発明提案、出願、中間処理、無効審判対応、審査状況調査、契約管理、発明届出、審査請求、登録、年金納付、補償金管理、予実管理などの業務に特化したアプリケーション群のうち、事務所または企業に適したそれぞれのアプリケーションを有している。予実管理とは、予算と実際にかかった金額とを対応させて管理することである。

企業向けＧＵＩ１１ａおよび事務所向けＧＵＩ１３ｂは、オペレータによるサーバ１のデータの閲覧、および業務処理の指示入力、処理結果の印刷を行うための指示を受け付ける受付手段およびデータ表示手段として機能する。

通信部１４は、ネットワーク５を通じて各クライアントコンピュータシステム６，７，８，９から受信された業務実行指示を企業向けＷＢＬ１１ａ，ＳＩｅｒ向けＷＢＬ１２ａおよび事務所向けＷＢＬ１３ａに渡す。

また、通信部１４は、企業向けＷＢＬ１１ａ，ＳＩｅｒ向けＷＢＬ１２ａおよび事務所向けＷＢＬ１３ａから渡された処理結果の通知を各クライアントコンピュータシステム６，７，８，９へ返信する。

データ処理エンジンとしての共通エンジン１０は、データ処理部２０、データ管理部３０、データ出力部４０およびデータ制御部１５を有している。

共通エンジン１０は、業務処理実行部として機能する。共通エンジン１０は、各企業向けＷＢＬ１１ａ，ＳＩｅｒ向けＷＢＬ１２ａ，事務所向けＷＢＬ１３ａから発行された要求に対してデータベース５０から該当情報を読み出して該当処理を実行する。

共通エンジン１０は、処理を実行した結果として変更が生じた情報を、データ同期マスタ５７の項目対応情報に従ってデータベース５０の共通情報と独自情報にそれぞれ反映しつつ処理結果を要求元へ通知する。

データ処理部２０は、採番部２１、導出部２２を有している。

採番部２１は、新規手続きおよび新規案件の発生に伴い、予め設定された採番ルールで該当案件に整理番号を付与する。

ＡＳＰサービスの場合、多数の顧客（事務所Ａ、企業Ｂ、会社Ｃなど）がアクセスするため、採番部２１は、重複しない一意の整理番号を採番する必要がある。

つまり採番部２１は、企業Ｂまたは事務所Ａで付与された案件番号（案件Ｎｏ．）が入力されたことをトリガーにして、その案件をシステムで一意に特定可能な整理番号を所定の採番ルールで付与する。

整理番号としては、個々の企業で付与された案件Ｎｏ．とは別の、システムで案件を識別するための番号である。本システムでは、ＡＳＰサービスなどを通じて契約している複数の特許事務所などの手続き対象機関が同じ整理番号を付与しても、システム的な一意の整理番号を画面等では見えないシステム内部の処理において持っている。そのため、本システムの採番機能では、見かけの重複採番を許容できるとともに、一つの案件を拒絶理由その他の手続に係るステージ単位に整理番号を変更しても“ひとつの案件である”とリンクさせることができる。

導出部２２は、導出制御機能、期限導出機能、作業工程導出機能、料金導出機能、通知書導出機能等を有している。期限導出機能は、案件マネージャー３１からの指示でデータベース５０の案件ＤＢ５８（図２参照）に登録された案件情報から期限日を算出する機能である。

作業工程導出機能は、期限導出機能により算出された期限日から該当案件を処理するための作業工程を導出する機能である。導出制御機能は、期限導出機能および作業工程導出機能を制御して該当案件の一連の処理日程を生成する機能である。

料金導出機能は、手続きを行った結果のデータの内容と料金テーブルを参照して手続き費用を自動算出する機能である。通知書導出機能は、アクション毎にどういった通知をするかというルールが予め設定されており、アクションが生じた場合に、通知タイミングを該当ＷＢＬなどのアプリケーションへ通知する機能である。

これらの機能を有する導出部２２は、案件が、例えば新規出願された特許案件の場合、案件ＤＢ５８から該当案件の出願日のデータを読み出して法定期限マスタ５５を参照して当該案件の審査請求の法定期間が出願日に応じて変わることを（３年以内か７年以内か）を判定した上で、該当法定期間での審査請求期限日（年月日）を算出し、業務休止日（休日）を考慮した上で、案件ＤＢ５８に登録する。

導出部２２は、期間算出にあたり、データベース５０のカレンダーマスタ（図示せず）を用いて計算した期限日が手続き対象機関の休日に該当した場合に、期限日を休日の前または後の稼働日にずらす処理（日程切り上げまたは日程繰り下げの機能）を行う。

データ管理部３０は、案件マネージャー３１、期限マネージャー３２などを有している。

案件マネージャー３１は、書誌情報蓄積管理機能、更新履歴管理機能、一次情報取込機能、提出書類作成機能、電子出願端末連携機能などを有している。案件マネージャー３１は、項目毎に案件データの照会要求を受け付ける。

書誌情報蓄積管理機能は、システムが管理する書誌情報に適切な権利でアクセスを可能にする。

更新履歴管理機能は、書誌情報の更新履歴を蓄積および検索する機能である。提出書類作成機能は、提出書類マスタ（図示せず）の定義に従い、案件ＤＢ５８から各種提出書類を取り込む機能である。

電子出願端末連携機能は、事務所または企業などの電子出願端末と連携する機能である。電子出願端末連携機能は、一次情報取込機能および提出書類作成機能と連携して動作する。なお、電子出願端末とは、旧来の電子出願専用の端末装置の他、パソコン電子出願ソフトウェアまたはインターネット出願ソフトウェアをインストールしたコンピュータ等をいう。

一次情報取込機能は、手続き対象機関より受信された共通情報をＤＢ５０へ取込む機能である。共通情報とは、図２のデータベース５０の書誌情報、経過情報、包袋情報の他に、このような出願完了通知、拒絶理由通知、特許査定通知などの通知情報も含まれる。

案件マネージャー３１は、手続き対象機関のクライアントコンピュータシステム６から発行された案件に関する受信情報（出願完了通知、拒絶理由通知、特許査定通知など）を一次情報取込機能によりデータベース５０の案件ＤＢ５８（図２参照）へ記憶および読み出す。

また、案件マネージャー３１は、案件が例えば特許の新規出願の場合、その特許案件が出願された日を案件ＤＢ５８へ登録する。

期限マネージャー３２は、案件毎および作業毎に期限内容と期限日、完了条件、およびアラーム日を与え、ＴｏＤｏリストとして管理するＴｏＤｏリスト管理機能を有している。

期限マネージャー３２は、案件ＤＢ５８内の任意の案件にイベントが発生したことで、導出部２２にベントに応じた期限を算出させる。

期限マネージャー３２は、導出部２２により算出された期限を期限管理ＤＢの該当案件の欄（レコード）へ登録する。

イベントとは、例えば新規案件の登録、既存案件について手続き対象機関より受信された通知の情報を追加したとき、案件ＤＢ５８に登録された情報の変更が発生したときなどである。

期限マネージャー３２は、導出部２２が生成した案件の処理に関する個々の作業工程に完了イベントが発生した場合、案件ＤＢ５８の該当案件の作業工程のレコードに完了ステータスを立てて作業状況を管理する。

データ管理部３０は、上記案件マネージャー３１および期限マネージャー３２の他に、例えば作業マネージャー、法律マネージャー、コストマネージャーなどを有している。

作業マネージャーは、送受信管理機能、問い合わせ管理機能、発注管理機能、ステージ管理機能を有している。送受信管理機能は、作業開始から完了を一連のトランザクションとして管理する機能である。

問い合わせ管理機能は、審査請求の有無の決定、および権利維持の必要性について問い合わせを行う機能である。発注管理機能は、企業から事務所への案件の発注があった場合に、その案件の発注を事務所側で受け付ける機能である。

ステージ管理機能は、受任から出願、中間、登録、権利維持、放棄までの案件のステージを管理する。法律マネージャーは、法律マスタと法律ロジックを有しており、法律ロジックが法律マスタを参照することで、法制度に基づく情報制御を行う法制度管理機能である。

コストマネージャーは、請求管理、債権債務管理、実績管理、予実管理を行う。データ出力部４０は、帳票出力部４１、汎用検索部４２を有している。

汎用検索部４２は、ＧＵＩなどから指定されたデータ（受任された案件情報など）をデータベース５０から読み出して帳票出力部４１へ渡し、帳票出力部４１は、渡されたデータを各納品先に適した出力形態に加工して出力する。

帳票出力部４１は、汎用検索部４２によりデータベース５０より抽出された案件に対しＧＵＩなどから所望のデータ項目が指定されることで、書誌情報を例えばＣＳＶ形式などで出力する。

帳票出力部４１は、共通エンジン１０で管理されているデータについて、指示された納品先の納品形態に加工して出力する。

帳票出力部４１は、包袋マネージャー１９により納品が指示された、例えばデータベース５０に共通情報として蓄積されている拒絶理由通知などの帳票と他の連絡ファイル、請求書データなどとを一つにまとめて納品ファイル６０として出力する。

納品ファイル６０には、例えば手続き対象機関から受信された案件のデータ（拒絶理由通知など）の他に、特許事務所から企業へ、または企業から特許事務所への連絡事項のデータ（拒絶理由のお知らせ等）、請求書データなども含まれる。

手続き対象機関から受信された案件のデータが例えば拒絶理由通知の場合、連絡事項のデータに条文コードが挿入可能である。条文コードは、プルダウンメニューで選択して入力する。条文コードを入力する手段としては、この例のようなプルダウンメニューの他、テキスト入力欄からのキー入力、またはラジオボタンのチェックなどでも良い。

帳票出力部４１は、予め定義されたトリガー要件、帳票の出力項目などによって、例えばトリガー要件が発生したときに、それをトリガーにして自動的に帳票を出力したり、利用者の操作による各クライアントコンピュータシステム６〜９からの要求で任意のタイミングで帳票を出力する。

データ制御部１５は、アクセスコントローラ１６、データ同期コントローラ１７、排他コントローラ１８、包袋マネージャー１９などを有している。

データ制御部１５は、共通エンジン１０への利用者のアクセス制御およびデータの排他制御を行う。つまりデータ制御部１５は、外部から共通エンジン１０へのフィルタリング制御を行う。

アクセスコントローラ１６は、各クライアントコンピュータシステム６〜９からサーバコンピュータ１に利用者がログイン要求をしてきたときに各クライアントコンピュータシステム６〜９から通知されたログイン情報に含まれるユーザＩＤをキーに、データベース５０のＩＤマスタ（図示せず）に記憶されているユーザＩＤ毎のアクセス権限に従ってデータベース５０の各マスタおよびＤＢのデータにアクセスさせる。
項目毎に案件データの照会要求を受け付ける案件管理部と、

アクセスコントローラ１６は、案件マネージャー３１により受け付けられた照会要求の項目をキーに記憶部４４に記憶されたアクセス情報対応テーブル４３を参照して既定案件アクセス情報４４ａに存在しない項目を拡張案件アクセス情報４４ｂから取得してデータベース５０の拡張案件データテーブル５３ｂにアクセスし該当する案件データを取得する。

排他コントローラ１８は、複数の利用者がデータベース５０に格納されているあるデータにアクセスしようとしたときに、そのデータがある利用者に先にアクセス（参照または編集）されていた場合に後からそのデータにアクセスを試みた利用者にアクセスさせなくする。

すなわち、排他コントローラ１８は、データベース５０のデータが利用者によってアクセスされていた場合、他の利用者から前記データへのアクセスを制限するアクセス制限部として機能する。

包袋マネージャー１９は、案件の電子包袋、添付ファイルを書誌情報と連携して管理する。包袋マネージャー１９は、納品元から納品先に対する案件処理結果の納品要求を受けて、納品先へ選定すると共に、案件ＤＢ５８より納品用の案件情報を読み出し、該当納品先のＤＢ（事務所Ａ独自情報、企業Ｂ独自情報、企業Ｃ独自情報など）に納品ファイルを納品するようデータ同期コントローラ１７に指示する。

データ同期コントローラ１７は、包袋マネージャー１９から指示された納品ファイルのデータを、それぞれの納品先のＤＢ、つまり事務所または企業の独自情報が格納されているＤＢの対応する項目とデータを同期させる。

つまりデータ同期コントローラ１７は、項目対応テーブルに従って納品ファイルのデータを他の独自情報の項目へデータ変換を行い、各ＤＢを更新する。項目対応テーブルには、事務所の独自情報と各企業の独自情報との項目の対応関係を示す情報が格納されている。

包袋マネージャー１９は、納品元から納品先に対する案件処理結果（納品ファイル）の納品要求を受けて、案件ＤＢから納品先を抽出し、該当納品先のＤＢ（事務所Ａ独自情報、企業Ｂ独自情報、企業Ｃ独自情報など）に案件処理結果の情報（納品ファイル）を格納する。

データ制御部１５は、上記各機能の他、グループ管理部、アクセスログ部、認証部などを有している。

グループ管理部は、企業グループ間の案件を共有する。アクセスログ部は、更新履歴だけでなく、それ以外の検索機能の呼び出し、その他各種機能の呼び出しのアクセスログを記憶および読み出す。

認証部は、入力されたログイン情報とデータベース５０に登録された認証情報とを比較してユーザ認証を行う。

具体的に、認証部は、ネットワーク５を通じて受信されたログイン要求に含まれるログイン情報（ユーザＩＤおよびパスワード）をキーワードにして、予めデータベース５０のＩＤマスタ（図示せず）に登録された認証用の登録データ(ユーザＩＤおよびパスワード)を検索して、ログイン情報が登録データと一致するか否かによってログイン要求に対するログインの可否を判定する。

サーバコンピュータ１には、図２に示すように、データベース５０が設けられている。データベース５０には、手続き対象機関から得られた共通情報と、事務所および企業共通独自情報と、各事務所および企業などの独自情報と、システム情報が蓄積されている。つまりデータベース５０には、複数の適用先から共通にアクセスされ、外部からは項目の追加／削除が不可能な共通情報と、適用先毎にアクセス可能であり、適用先毎に設定された独自情報とが項目毎にまとめて格納および管理されている。

手続き対象機関から得られた共通情報としては、例えば書誌情報、経過情報、包袋情報（実体データ）などである。

データベース５０には、事務所Ａ独自情報ＤＢ５１、企業Ｂ独自情報ＤＢ５２などのように、個々のＤＢが設けられており、それぞれのＤＢに事務所Ａおよび企業Ｂの独自情報が記憶されている。

すなわち、データベース５０には、手続き対象機関、企業Ｂおよび事務所Ａ相互の間でやりとりされる知的財産権の共通情報と、手続き対象機関、企業Ｂおよび事務所Ａが個別に管理する独自情報と、システム情報としての共通エンジン１０の制御用データが記憶されている。

図３に示すように、事務所Ａ独自情報ＤＢ５１には、案件番号（案件Ｎｏ．）に、発明名称、出願日、出願番号、審査請求の有無（「未」または「済」）、審査請求期限日、審査請求要否回答依頼、出願人情報、出願人情報、技術担当、事務担当などが対応して一つのレコードとして記憶されている。

なお、このＤＢの例は、案件（案件番号「１２３４５６」）がＢ社の特許出願の場合の例である。

すなわち、事務所Ａ独自情報ＤＢ５１には、このシステムが導入されている特許事務所で出願したすべての知的財産権の案件の情報が蓄積されている。

図４に示すように、企業Ｂ独自情報ＤＢ５２には、案件番号（案件Ｎｏ．）に、発明名称、出願日、出願番号、審査請求の有無（「未」または「済」）、審査請求期限日、審査請求回答受け、発明者、発明者、共願企業、特許事務所などが対応して一つのレコードとして記憶されている。

このＤＢはＢ社のＤＢなので、自社の発明者として、「東 太郎」、「東 花子」などが登録され、共願企業として「Ｙ社」が登録されている。

すなわち、企業Ｂ独自情報ＤＢ５２には、このシステムが導入されている企業Ｂで出願したすべての知的財産権の案件情報が蓄積されている。

データベース５０には、法定期限マスタ５５ａ、指令応答マスタ５５ｂ、作業期限マスタ５６、データ同期マスタ５７、案件ＤＢ５８、期限管理ＤＢ５９などが設けられている。

各ＤＢには、事務所および企業がそれぞれ入力した独自情報が記憶されている。各マスタには、事務所および企業が共通に利用する共通情報が記憶されている。データ同期マスタ５７は、データベース５０に、システム情報として記憶されている。

図５に示すように、法定期限マスタ５５ａには、手続き毎に法定期限が記憶されている。法定期限としては、例えば優先権証明書提出の期限、審査請求の期限、特許料納付期限や国内優先権主張出願の期限などの情報がある。審査請求は、例えば２００１年９月３０日までに出願された特許についての審査請求期限は、出願日から７年以内であり、２００１年１０月１日以降に出願された特許についての審査請求期限は、出願日から３年以内である、と記憶がなされている。

また、図６に示すように、指令応答マスタ５５ｂでも同様に手続き対象機関からの指令に対する期限が記憶されている。このマスタの期限は任意に設定できる。例えば「意見書・補正書提出」については、例えば拒絶理由通知の場合、手続き対象機関からの通知日から６０日（２カ月）以内等と設定されている。

図７に示すように、作業期限マスタ５６は、作業毎に期限が記憶されている。例えば審査請求要否の回答は、審査請求期限より１ヶ月前などである。この期限は、法定期限ではないため任意に設定できる。

図８に示すように、データ同期マスタ５７には、案件Ｎｏ毎に、関係のある事務所と企業間の項目同士がどう対応するかといった紐づけがなされている、項目対応情報が記憶されている。

そして、データ同期マスタ５７は、データ同期コントローラ１７がデータ同期を行う際に参照される。

この例では、例えば「審査請求要否回答期限日」について、事務所Ａの項目は「審査請求要否回答依頼」であるのに対して、出願人のＢ社の項目は「審査請求要否回答依頼受け」である。

また、「審査請求要否判定」について、事務所Ａの項目は「審査請求要否判定結果」であるのに対して、出願人のＢ社の項目は「審査請求有無」である。

すなわち、このデータ同期マスタ５７には、データベース５０において企業毎および事務所毎に別個に管理される独自情報を項目単位に他へ変換するための対応情報が記憶されている。

案件ＤＢ５８には、新規案件発生時に採番された案件の整理番号（案件番号）に対応させて案件を処理する、または処理した各種付随情報が登録されている。

具体的には、案件ＤＢ５８には、例えば知的財産権のカテゴリー（特許、実用新案、意匠、商標などのうちのいずれか一つ）、出願日、審査請求日、拒絶理由通知の有無、登録日、発注企業番号または発注企業名、発注企業の案件番号、企業側技術担当者、受任事務所番号、受任事務所名、事務所側技術担当者などの案件情報が記憶されている。

ここで、この知的財産管理システムにおける案件管理機能及び案件登録機能について説明する。

知的財産管理システムが扱う「案件データ」は、特許出願に関わるデータの集合を表している。案件データに含まれるデータ項目には、特許事務所向けや企業向け、さらには個別の適用先企業・特許事務所毎に、全ての知的財産管理システムを通じて共通的に存在する項目と、それぞれの要件の違いにより独自に存在する項目がある。

全てを通じて共通的に存在するデータ項目を、「共通情報」と呼び、それ以外の適用先要件により異なるデータ項目を「独自情報」と呼ぶ。案件データは、これら項目データの集合により成り立っている。

知的財産管理システムで扱うデータには、上記データ項目に加えて、共通エンジン１０自体を制御するために必要な「共通エンジン制御用データ」がある。

独自情報は、共通情報に該当しないが、特許の手続きにおいて管理しなければならない情報（手続き対象機関との手続には直接必要ではない情報）である。

共通エンジン１０では、共通情報および共通エンジン制御用データを管理する。独自情報は、共通エンジン１０を利用して構築されるアプリケーション側で管理することになる。

このように責任範囲を分割したのは、アプリケーション毎に異なる要件を排除することにより、共通エンジン１０を独立性の高いコンポーネントとするためである。

事務所向けや企業向けのアプリケーションは、共通エンジン１０が提供するテーブルとコードを基盤とし、それぞれで必要な独自情報を管理するテーブルと、独自のＷＢＬを追加することにより開発されることになる。

一方、エンティティとしての案件データは、期限管理情報や法定期限情報、作業期限情報などのエンティティの集合となっているが、この期限管理情報や法定期限情報などのエンティティにも、共通情報／独自情報の複数のデータ項目が混在している。この様子のイメージを図９に示す。

共通エンジン１０として管理しているデータは共通情報だけであるが、アプリケーション側から見れば、案件データは独自情報を含んだエンティティでなければならない。アプリケーションは、案件データの登録や参照、期限や工程導出のため案件データへのアクセス等の処理一切を共通エンジン１０に委譲する。このため共通エンジン１０は、案件データに含まれるデータ項目を共通情報と独自情報を区別せずに登録、照会、アクセスを行うことができる必要がある。

案件データを構成するデータ項目のうち共通情報は、共通エンジン１０で定義するが、独自情報についてはアプリケーション側で自由に定義できるようにしたい。

そこで、本実施形態では、以下のようにする。
１）案件データは、共通エンジン１０が定義するエンティティに独自の項目を追加できるようにする。
２）エンティティとしての案件データは、共通情報・独自情報が混在されたものとして定義される必要がある。共通エンジン１０の各機能においては、案件データ内の拡張された項目を、共通エンジン１０が定義する項目と区別無く扱えること（保存／照会／スナップショット作成など）。
３）共通エンジン１０は、原則ｊａｒファイルとしてＳＩｅｒに提供する。案件データの拡張が、共通エンジン１０のソースコードに影響しない仕組みとする。

なお、Ｊａｒは、Ｊａｖａ（登録商標）プログラムの実行に必要なクラスファイルやデータファイルを一つにまとめたファイルフォーマットであり、Ｊａｖａで作成したソフトウェアを配布する際に関連するファイルが１つのＪａｒとしてパッケージングされる。

上記の内容を実現するために、案件管理機能・案件登録照会機能は、図９に示すような構成をとる。

すなわち、図１０に示すように、ＳＩｅｒ向けのアプリケーションソフトウェア１２のＳＩｅｒ向けＷＢＬ１２ａの機能の一つとして、システム構築支援部１２ｃを設ける。

データベース５０には、既定の案件データテーブル５３ａと管理項目マスタ５４の他に、共通エンジン１０を利用して知的財産管理システムを構築するＳＩｅｒのために、予め独自情報を管理するための拡張案件データテーブル５３ｂを用意しておく。

既定案件データテーブル５３ａは、共通エンジン１０により定義されるものであり、共通情報および独自情報それぞれ１つにつき１レコードとなるように作成されている。

拡張案件データテーブル５３ｂは、既定案件データテーブル５３ａを継承して生成されるものであり、共通エンジン１０以外のアプリケーション、この例では、システム構築支援部１２ｃにより定義されるものであり、独自情報に新たな項目を追加または削除するためのテーブルである。

管理項目マスタ５４は、既定案件データテーブル５３ａおよび拡張案件データテーブル５３ｂの各データと共通エンジン１０の側に設定された既定案件アクセス情報４４ａおよび拡張案件アクセス情報４４ｂとの対応情報が記憶されている。

システム構築支援部１２ｃは、管理項目マスタ５４の対応情報を参照して拡張案件データテーブル５３ｂに新たな項目が追加または削除された場合、該当項目については、拡張案件データテーブル５３ｂを参照して該当する案件データの照会と登録を行うための命令文であるＳＱＬ文を生成すると共に、案件データと新規項目とを対応付けるＯ−Ｒマッピング情報設定ファイルを生成しメモリ１２ｄに記憶する。

また、共通エンジン１０には、記憶部４４を設ける。この記憶部４４には、共通エンジン１０が定義した既定案件データアクセス情報４４ａと、この既定案件アクセス情報４４ａを拡張した独自の拡張案件データアクセス情報４４ｂと、これらアクセス情報とデータベース５０のテーブル５３ａ，５３ｂとの対応情報が設定されたアクセス情報対応情報としてのアクセス情報対応テーブル４３とを記憶しておく。

つまり、共通エンジン１０には、コアとなる共通情報およびエンジン制御用データについてのアクセス情報対応テーブル４３と案件データアクセス情報４４ａおよび拡張案件データアクセス情報４４ｂを定義しておく。

すなわち、共通エンジン１０が定義した既定案件データアクセス情報４４ａと、この既定案件アクセス情報４４ａを拡張した独自の拡張案件データアクセス情報４４ｂと、既定案件データアクセス情報４４ａと既定案件データテーブル５３ａとの対応関係、および拡張案件データアクセス情報４４ｂと拡張案件データテーブル５３ｂとの対応関係が設定されたアクセス情報対応テーブル４３とを共通エンジン１０の記憶部４４に記憶しておく。

システム構築支援部１２ｃは、管理項目マスタ５４を参照して案件データテーブル５３ａと既定案件データアクセス情報４４ａとの対応情報、拡張案件データテーブル５３ｂと拡張案件データアクセス情報４４ｂとの対応情報を基に、案件データの照会と登録を行うためのＳＱＬ文の作成と、マッピング設定ファイル（マッピング情報）の作成を行う。

既定案件データアクセス情報４４ａおよび拡張案件データアクセス情報４４ｂは、例えばデータトランスファオブジェクト（以下「ＤＴＯ」と称す）などで実現される。

アクセスコントローラ１６は、生成されたＳＱＬ文を用いて案件データの照会と登録を実行する。またアクセスコントローラ１６は、システム構築支援部１２ｃにより生成されたマッピング設定ファイル（マッピング情報）を用いて既定案件データアクセス情報４４ａおよび拡張案件データアクセス情報４４ｂからのデータ取得や既定案件データアクセス情報４４ａおよび拡張案件データアクセス情報４４ｂへのデータ登録を行う。

アクセスコントローラ１６は、管理項目マスタ５４で管理されているマッピング設定に従いマッピング設定ファイルを参照して各案件データをアクセスする。アクセスコントローラ１６は、例えばデータアクセスオブジェクト（以下「ＤＡＯ」と称す）などで実現される。

アクセスコントローラ１６によるデータの登録／照会は、独自情報を含んだ状態で行われる必要がある。

そこで、図１１に示すように、共通エンジン１０では、案件データの基礎となるクラス構造を既定案件アクセス情報４４ａにより定義する。またシステム構築支援部１２ｃを含むＳＩｅｒ向けＷＢＬ１２ａの側でも、拡張案件アクセス情報４４ｂを設け、これにより共通エンジン１０の定義を拡張することで、独自の要件を満たす案件データを構築する。

この際、共通エンジン１０の定義する範囲に存在しないエンティティについては既定案件アクセス情報４４ａを拡張することなく、拡張案件アクセス情報４４ｂにより独自のクラスを定義するものとする。例えば「メモ」等の項目４５を追加する場合は、拡張案件アクセス情報４４ｂにその定義を追加することで、アプリケーションから共通エンジン１０への独自情報の実質的な追加が可能になる。

共通エンジン１０より取得される案件データは、拡張した案件データをダウンキャストしたものとする。ＳＩｅｒ向けＷＢＬ１２ａは、案件データ取得後に拡張したクラスにキャストした後に拡張した案件データを利用することとする。

既定案件データアクセス情報４４ａは、アクセス情報対応情報４３によりデータベース５０の既定案件データテーブル５３ａと対応づけられる。拡張案件データアクセス情報４４ｂは、アクセス情報対応情報４３によりデータベース５０の拡張案件データテーブル５３ｂと対応づけられる。これにより、新規に項目が追加される案件データのアクセス情報に関しては拡張案件データアクセス情報４４ｂに登録することで自由に追加可能となる。

共通エンジン１０では、コアとなる共通情報、共通エンジン制御用データについての案件データテーブル５３ａをデータベース５０に設定する。この案件データテーブル５３ａへのＳＩｅｒによるカラムの追加は不可とされる。独自情報は、ＳＩｅｒが構築する独自のテーブルである拡張案件データテーブル５３ｂを設定しこのテーブルで独自情報を管理する。

但し、ＳＩｅｒ向けＷＢＬ１２ａからは、データベース５０のデータは、共通情報と独自情報とは一体となったエンティティとして扱われる必要がある。このため、データベース５０に管理項目マスタ５４を設定し、システム構築支援部１２ｃは、管理項目マスタ５４を利用してＯ−Ｒマッピングを行う。

このようにこの実施の形態の知的財産管理システムによれば、ＳＩｅｒ向けＷＢＬ１２ａの一つの機能として、独自情報にデータ項目の追加を行うツールであるシステム構築支援部１２ｃを設けたことで、このシステムを構築するＳＩｅｒが、構築するアプリケーションの要件に合わせて、共通エンジン１０が管理するデータベース５０に新たなデータ項目を追加または削除することができる。

アクセスコントローラ１６は、管理項目ＩＤをキーとして、管理項目マスタ５４にて管理されているクラス名、プロパティ名からリフレクションを利用することで、拡張案件データテーブル５３ｂへアクセスし、独自情報として新たに追加したデータ項目へアクセスすることができる。

本発明の一実施形態の知的財産管理システムの構成を示す図である。 知的財産管理システムのデータベースを示す図である。 事務所Ａ独自情報ＤＢを示す図である。 企業Ｂ独自情報ＤＢを示す図である。 法定期限マスタを示す図である。 指令応答マスタを示す図である。 作業期限マスタを示す図である。 データ同期マスタを示す図である。 案件データがエンティティの集合体になっていることを示す図である。 案件管理機能及び案件登録機能の構成を示す図である。 図９の機能構成のうち共通エンジン側の構成を詳細に示す図である。

符号の説明

１…サーバコンピュータ、１０…共通エンジン、１１，１２，１３…アプリケーションソフトウェア、１１ａ，１２ａ，１３ａ…ワークフロー・ビジネスロジック（ＷＢＬ）、１１ｂ，１２ｂ，１３ｂ…グラフィック・ユーザ・インターフェース（ＧＵＩ）、１２ｃ…システム構築支援部、１２ｄ…メモリ、１５…データ制御部、１６…アクセスコントローラ、１７…データ同期コントローラ、１８…排他コントローラ、１９…包袋マネージャー、２０…データ処理部、２１…採番部、２２…導出部、３０…データ管理部、３１…案件マネージャー、３２…期限マネージャー、４０…データ出力部、４１…帳票出力部、４２…汎用検索部、４３…アクセス情報対応テーブル、４４ａ…既定案件アクセス情報、４４ｂ…拡張案件アクセス情報、５０…データベース、５３ａ…既定案件データテーブル、５３ｂ…拡張案件データテーブル、５４…管理項目マスタ、５５ａ…法定期限マスタ、５５ｂ…指令応答マスタ、５６…作業期限マスタ、５７…データ同期マスタ、６０…納品ファイル、７２，８２，９２…クライアントコンピュータ、１４，７１，８１，９１…通信部。

Claims (1)

1. 複数の適用先から共通にアクセスされ、外部からは項目の追加／削除が不可能な共通情報と、適用先毎にアクセス可能であり、適用先毎に設定された独自情報とが格納されたデータベースに対してデータ処理エンジンがアクセスするデータベースシステムにおいて、
   前記データ処理エンジンが、
   前記データベースの各案件のデータへアクセスするために定義されたアクセス情報と、前記データ処理エンジン以外のアプリケーションにより前記アクセス情報を拡張して定義された拡張アクセス情報と、前記アクセス情報と前記データベースの案件データテーブルとの対応関係、前記拡張アクセス情報と前記データベースの前記拡張案件データテーブルとの対応関係が設定されたアクセス情報対応情報とが記憶された記憶部を備え、
   前記データベースが、
   前記データ処理エンジンにより定義され、前記共通情報および独自情報それぞれ１つにつき１レコードとなるように作成された案件データテーブルと、
   前記案件データテーブルを継承して生成され、前記データ処理エンジン以外のアプリケーションにより定義され、前記独自情報に新たな項目を追加または削除するための拡張案件データテーブルと、
   前記案件データテーブルおよび前記拡張案件データテーブルの各データと前記データ処理エンジンの側に設定されたアクセス情報および拡張アクセス情報との対応情報が記憶される管理項目マスタとを備え、
   前記管理項目マスタの対応情報を参照して前記拡張案件データテーブルに新たな項目が追加または削除された場合、該当項目については、前記拡張案件データテーブルを参照して該当する案件データの照会と登録を行うための命令文と、前記案件データと項目とを対応付けるマッピング情報を生成するシステム構築支援部を具備したことを特徴とするデータベースシステム。

Images