JP4909558B2 - プラットフォーム構想を用いた特許管理システム - Google Patents

Description

本発明は、少なくとも知的財産業務で発生する情報を蓄積して管理する特許管理データベースを具備し、所定のグループ内で知的財産業務を遂行する特許管理システムに柔軟性を持たせ、有効に活用することができるシステムの構築に関する。

近年、知的財産に対する関心が高まる情勢において、企業などの一定の人数からなる組織では、全社的に知的財産に関する情報を取り扱いながら効率的に業務を遂行することができるシステムの構築に対する要望が高まってきている。

一般に、知的財産業務は、長期間にわたり承認処理の多い、独特なワークフロー（手続きの流れ）を要するものであることが知られている。この知的財産業務は、例えば、企業などでは、知的財産グループが主体となって遂行されることが殆どであるため、知的財産業務に関連する情報などは、知的財産グループが独自で取り扱っていた。すなわち、知的財産グループ内だけで知的財産業務に関連する情報を共有することができる独立したシステムを採用して、企業内の知的財産業務が遂行されていることが殆どであった。

一方で、知的財産業務は、機密性を要する情報を取り扱っているため、情報の取り扱い範囲を拡張することによるセキュリティ上の問題点があった。すなわち、業務の特殊性から、全社員がセキュアに利用することができるシステムを構築することは困難を要していた。又、従来から知的財産グループで独自に用いているシステムを全社的に利用できるシステムとして再構築するためには、発明者を含めた全社員毎に対応したワークフローと独特なワークフローを融合させたものとする必要があるが、各々の社員レベルに対応できる柔軟性のあるシステムを構築することは容易ではなかった。

なお、知的財産業務にかかる情報を取り扱う技術として、例えば、業務の効率化を図るための装置など（特許文献１参照）が提案されているが、全社的に利用することができる効率的で柔軟性のあるシステムは未だ提案されていないといった現状である。

特開２００４−１７８４３７号公報

本発明はこのような事情に鑑み、知的財産業務にかかる情報を全社的に取り扱うことができると共に、一連の知的財産業務を社員レベルで効率的に遂行することができる柔軟性のあるプラットフォーム構想を用いた特許管理システムを提供することを課題とする。

上記課題を解決する本発明の第１の態様は、少なくとも知的財産業務で発生する情報を蓄積して管理する特許管理データベースと、知的財産業務を遂行するための基本的な業務手順を網羅したワークフローシステムとを具備し、所定のグループ内で知的財産業務を遂行する特許管理システムであって、前記ワークフローシステムは、前記業務手順に基づいて所定の処理を行うワークフロー機能モジュールと、前記ワークフロー機能モジュールで使用する入力画面の画面レイアウト及び入力項目、並びに前記入力項目と前記特許管理データベースの格納先との対応付けを定義した定義データと、前記ワークフロー機能モジュールの下で、前記定義データをウエブブラウザで解釈可能な形式に変換して入力画面を作製し、当該入力画面をウエブブラウザに送信し、ウエブブラウザで前記入力画面の前記入力項目に対応して入力された入力データを取得し、当該入力データに所定の処理を実行した処理内容をワークフローデータベースに格納するプラットフォーム部とを備え、さらに前記定義データの前記対応付けを参照しながら前記ワークフローデータベースに格納された前記処理内容を前記特許管理データベースにマッピングするマッピング手段を備えることを特徴とするプラットフォーム構想を用いた特許管理システムにある。

かかる第１の態様では、プラットフォーム部にワークフロー機能が実装されて、当該ワークフロー機能の業務手順に基づいてプラットフォーム部で実行された処理内容が、所定のルールに従って特許管理データベースにマッピングされる。これにより、ウエブブラウザ環境で知的財産業務を遂行することができるため、所定のグループ内で運用されていた従来の特許管理システムを全社的に利用することができる。また、定義データを参照することでワークフローデータベースと特許管理データベースとを容易に連携させることができる。さらに、定義データに基づいてワークフローデータベース内のデータが特許管理データベースにマッピングされると共に、画面レイアウトが変更される。これにより、例えば、定義データを変更するだけで容易に画面レイアウトを構成することができるため、社内状況や社内要望に柔軟に対応することが可能となる。

本発明の第２の態様は、第１の態様に記載するプラットフォーム構想を用いた特許管理システムにおいて、前記業務手順は、知的財産業務の出願に関し、出願にかかる案件の検索、出願提案、業務の承認、出願提案を受け付けるための提案受付、又は出願提案された案件の工程管理であり、これらの業務手順ごとに定義データが作成されていることを特徴とするプラットフォーム構想を用いた特許管理システムにある。

かかる第２の態様では、ウエブブラウザ環境で出願に関連する作業を遂行することができる。これにより、ネットワークに接続されている端末を利用して全社的に効率よく知的財産業務を遂行することが可能となる。

本発明の第３の態様は、第１の態様に記載するプラットフォーム構想を用いた特許管理システムにおいて、前記業務手順は、知的財産業務の中間に関し、中間書類の問合せを行うための中間書類問合せ機能、中間書類の回答者を選定又は変更するための中間書類回答者決定、中間書類の回答作業を管理するための中間書類回答、中間書類に関する回答の承認作業を管理するための中間書類承認、中間書類に関する所定事項を決定するための中間書類決定、又は中間書類の工程を管理するための中間書類工程管理であり、これらの業務手順ごとに定義データが作成されていることを特徴とするプラットフォーム構想を用いた特許管理システムにある。

かかる第３の態様では、ウエブブラウザ環境で中間に関連する作業を遂行することができる。これにより、ネットワークに接続されている端末を利用して全社的に効率よく知的財産業務を遂行することが可能となる。

本発明の第４の態様は、第１〜３の何れか一つの態様に記載するプラットフォーム構想を用いた特許管理システムにおいて、知的財産業務を遂行する上で各案件毎に通過する承認ルートを判定する承認ルート決定手段と、案件に示された書類名と承認ルートとの対応付けを定義した承認ルート定義テーブルとをさらに具備しており、前記承認ルート決定手段は、案件の書類名を前記承認ルート定義テーブルから検索して承認ルートを自動決定し、前記プラットフォーム部は、当該承認ルートに対応する業務手順に関する前記定義データの画面レイアウトを、ウエブブラウザで解釈可能な形式に変換して、前記入力項目に対して処理内容を入力させる入力画面を作製し、当該承認ルートに対応する入力画面をウエブブラウザに送信し、ウエブブラウザで前記入力画面の入力項目に対して入力された入力データを取得し、当該入力データに所定の処理を実行した処理内容をワークフローデータベースに格納することを特徴とするプラットフォーム構想を用いた特許管理システムにある。

かかる第４の態様では、承認ルート定義テーブルに基づいて案件毎の承認ルートが決定されると共に、その承認ルートに対応する業務手順がワークフロー上に作成される。これにより、例えば、承認ルート定義テーブルを変更するだけであらゆる業務パターンをワークフロー上に構築することができるため、社内状況や社内要望に柔軟に対応することが可能となる。

本発明の第５の態様は、第４の態様に記載するプラットフォーム構想を用いた特許管理システムにおいて、前記承認ルート定義テーブルには、業務毎の期限を算出するための式が含まれており、前記承認ルート決定手段は、前記承認ルート定義テーブルに基づいて決定した承認ルートに対応する式を前記承認ルート定義テーブルから検索し、当該式から業務上の期限を自動算出することを特徴とするプラットフォーム構想を用いた特許管理システムにある。

かかる第５の態様では、承認ルート定義テーブルに基づいて決定した承認ルートに応じた業務上の期限が自動算出される。これにより、効率的に業務を遂行することが可能となる。

本発明の第６の態様は、第１〜５の何れか一つの態様に記載するプラットフォーム構想を用いた特許管理システムにおいて、外部とのデータ授受を段階的に行う場合に、データ授受に関する状態遷移を数値化して管理するデータ授受手段を具備し、前記データ授受手段は、段階と動作との関係を、データ授受の状態を表した数値に対応付けることを特徴とするプラットフォーム構想を用いた特許管理システムにある。

かかる第６の態様では、データ授受に関する状態遷移が段階と動作との関係からなる数値の組み合わせにより管理される。これにより、例えば、データの送り手側と受け手側の双方で、処理状況や進捗状況が把握し易くなるため、効率的に業務を遂行することが可能となる。

本発明の第７の態様は、第１〜６の何れか一つの態様に記載するプラットフォーム構想を用いた特許管理システムにおいて、アクセス権限が制限されている情報へアクセスをする際に、アクセス条件の一部が暗号化されたアクセスキーを生成するアクセスキー生成手段を具備し、前記アクセスキー生成手段は、対象となる情報に付与されているユニークな書類番号に基づいて利用目的に応じたアクセスキーを生成することを特徴とするプラットフォーム構想を用いた特許管理システムにある。

かかる第７の態様では、アクセス条件の一部が暗号化されたアクセスキーが利用目的に応じて生成される。これにより、所定のアクセス権限を維持しながら、全社的に知的財産業務に関する情報を取り扱うことが可能となる。

本発明の第８の態様は、第２の態様に記載するプラットフォーム構想を用いた特許管理システムにおいて、前記ワークフロー機能モジュールで扱われる業務手順の出願に係る案件の検索は、前記特許管理データベースから出願特許を検索する処理であり、当該出願特許を検索する際には、少なくとも、前記出願にかかる案件を示す種別、出願に関連する会社を示す法人、当該法人に属する部門、当該出願にかかる案件に対する職位、及び当該出願にかかる案件に対する役割の何れかに応じて各案件に対するアクセス制限を設定することを特徴とするプラットフォーム構想を用いた特許管理システムにある。

かかる第８の態様では、少なくとも、出願にかかる案件を示す種別、出願に関連する会社を示す法人、当該法人に属する部門、当該出願にかかる案件に対する職位、及び当該出願にかかる案件に対する役割の何れかに応じて各案件に対するアクセス制限が設定される。これにより、知的財産業務にかかる特殊な情報を確実且つ効率的に全社的に管理することができると共に、利用することが可能となる。

本発明のプラットフォーム構想を用いた特許管理システムによれば、ウエブブラウザ環境からなるプラットフォーム部にワークフロー機能を実装しており、定義ファイルに基づいて、従来の特許管理システムとの連携をとっているため、知的財産業務にかかる情報を全社的に取り扱うことが可能となる。さらに、本発明の特許管理システムによれば、承認ルート定義ファイルに応じた種々の業務データをワークフロー上に作成しているため、例えば、社内状況や社内要望などに柔軟に対応することができ、一連の知的財産業務を社員レベルで効率的に遂行することが可能となる。

以下、図面を用いて本発明を実施するための最良の形態について説明する。なお、本実施形態の説明は例示であり、本発明の構成は以下の説明に限定されない。

本実施形態は、例えば、企業の知的財産に関する情報を主に取り扱う知的財産グループ（知的財産部門）と特許事務所との間で従来から運用されている特許管理システムを全社的に利用するために、プラットフォームという概念を適用して、発明者を含めた全社員レベルでの知的財産に関する情報の取り扱いを実現したものである。

図１は、本発明の一実施形態に係るプラットフォーム構想を用いた特許管理システムの概略構成を示す図であり、図２は、本発明の一実施形態に係るプラットフォーム構想を用いた特許管理システムのシステム構成を示す図である。なお、本実施形態は、企業と特許事務所との間で運用する場合を例示している。

図示するように、本実施形態のプラットフォーム構想を用いた特許管理システム１では、企業２に構築されているシステムと特許事務所３に構築されているシステムとがネットワーク４を介して接続されている。企業２側のシステムは、主に、オンライン納品サーバ１０、特許管理サーバ２０、知的財産部門２ａ，研究開発部門２ｂ，事業部門２ｃに所属する社員が個々に保持する端末３０がＬＡＮ（Local Area Network）間接続により構成されており、オンライン納品サーバ１０と特許管理サーバ２０間、及びオンライン納品サーバ１０とネットワーク４間は、それぞれファイヤーウォール（Ｆ／Ｗ）１１を介して接続されている。なお、オンライン納品サーバ１０とネットワーク４を接続するファイヤーウォール１１は、ルータ機能を兼用したものである。一方、特許事務所３側のシステムは、主に、事務所員が個々に保持する端末及び管理サーバ（図示せず）などで構成されており、ネットワーク４間とはルータ機能を備えたファイヤーウォール１１を介して接続されている。

ここで、企業２側の特許管理サーバ２０にかかるシステムについて説明する。特許管理サーバ２０は、知的財産部門２ａ内で独立して機能する従来の特許管理システム２０Ａにおいて、ウエブブラウザ環境で所定の動作を実行するプラットフォーム部２１と、知的財産業務を遂行するための基本的な業務手順を網羅したワークフロー機能モジュール２３と、プラットフォーム部２１で実行される処理内容を格納するワークフローデータベース２２とを具備している。

プラットフォーム部２１には、承認機構が組み込まれており、必要に応じて当該プラットフォーム部２１に各種モジュール２３を実装することにより、社内状況や利便性に対応した柔軟なシステムを構築することができる。ここで、各種モジュール２３としては、例えば、知的財産部門２ａからの情報発信を行うための機能、ユーザアクセス権限に基づく期限データ又は包袋データを検索するための特許検索機能、出願提案業務を遂行するための出願提案機能、中間処理業務を遂行するための中間処理機能、工程管理を実施するための工程管理機能、他社の特許を管理するための他社管理機能などが挙げられる。さらに、プラットフォーム部２１には、社員情報が取り込まれており、ユーザアクセス権限に基づく制御、組織・職位に基づく制御、セキュリティ制御などが実行される。

なお、プラットフォーム部２１は、独立した特許公報検索システム４０と連携するように構成してもよい。

また、従来の特許管理システム２０Ａは、知的財産業務で発生する情報を蓄積する特許管理データベース２４を具備しており、知的財産部門２ａに設置されている端末３０に知的財産業務を遂行する上で必要な各種プログラム２５がインストールされることにより、特許管理データベース２４を利用して業務を遂行することができるように構築されている。ここで、各種プログラム２５としては、例えば、書誌情報・国内外の期限情報などを検索・閲覧するための期限Ｗｅｂ用、研究開発部門２ｂなどから出願依頼のあった案件を受け付けてから出願決定するまでの管理を行うための受付管理用、国内出願に関する各種情報を管理するための国内期限管理用、外国出願に関する各種情報を管理するための外国期限管理用、各種経費及び補償金に関する管理を行うための経費・補償管理用、契約管理用などのプログラムが挙げられる。上述のようなプログラムの制御により、特許管理データベース２４では、電子包袋、国内外期限情報、経費・補償金情報、契約情報、製品との関係に関する情報などが格納されて管理されている。

以上から、プラットフォーム構想を用いた特許管理システム１は、図１に示すプラットフォーム部２１、ワークフローデータベース２２、及び各種モジュール２３を実装したシステムが、図２に示すワークフローシステム２０Ｂに相当し、図１に示す特許管理データベース２４が図２に示す従来の特許管理システム２０Ａに相当する構成となっている。

次に、ワークフローシステム２０Ｂの具体的なシステム構成について説明する。図３は、本発明の一実施形態に係るワークフローシステムのシステム構成を示す図である。なお、特許管理データベース２４は、従来の特許管理システム２０Ａに具備されている構成であるが、説明の便宜上例示している。

図示するように、ワークフローシステム２０Ｂは、知的財産業務の出願に関連する業務を遂行する機能として、出願にかかる案件の検索をするための出願特許検索機能２０１、出願提案をするための出願提案機能２０２、業務の承認をするための承認機能２０３、出願提案を受け付けるための提案受付機能２０４、及び出願提案された案件の工程（移行のための工程も含む）を管理するための出願工程管理機能２０５を具備している。さらに、知的財産業務の中間に関する業務を遂行する機能として、中間書類の問合せを行うための中間書類問合せ機能２０６、中間書類の回答者を選定又は変更するための中間書類回答者決定機能２０７、中間書類の回答作業を管理するための中間書類回答機能２０８、中間書類に関する回答の承認作業を管理するための承認機能２０３、中間書類に関する所定事項を決定するための中間書類決定機能２０９、及び中間書類の工程を管理するための中間書類工程管理機能２１０を具備している。

さらに、ワークフローシステム２０Ｂは、マッピング手段、承認ルート決定手段、データ授受手段、アクセスキー生成手段、及び工程管理手段を具備している（図示せず）。

マッピング手段は、プラットフォーム部２１で実行される処理内容を特許管理データベース２４にマッピングする。具体的には、定義データの一例である定義ファイル２２０を参照しながらワークフローデータベース２２に格納されている処理内容の格納先を決定して特許管理データベース２４にマッピングする。さらに、マッピング手段は、ワークフローデータベース２２と特許管理データベース２４とをマッピングした際に、定義データ２２０に基づいて入力画面３００上の画面レイアウトを変更する。

承認ルート決定手段は、知的財産業務を遂行する上で各案件毎に通過する承認ルートを判定する。具体的には、後述する承認ルート定義テーブル２３０に基づいて案件の書類名に応じた承認ルートを自動決定すると共に、当該承認ルートに対応する業務手順をワークフロー上に作成する。

データ授受手段は、データ授受に関する状態遷移を数値化して管理する。具体的には、データ授受に関する状態遷移を段階と動作との関係を数値の組み合わせにより管理する。

アクセスキー生成手段は、アクセス権限が制限されている情報へアクセスをする際に、アクセス先となるＵＲＬ（Uniform Resource Locator）の一部が暗号化されたアクセスキーを生成する。具体的には、対象となる情報に付与されているユニークな書類番号に基づいて利用目的などに応じたアクセスキーを生成する。

工程管理手段は、各案件に対する一連の工程作業を生成して、当該工程作業の目標日を設定する。具体的には、各案件毎の工程作業が定義されたテンプレートに基づいて、標準工程又は変則工程を管理する。

上述のようなシステム構成により、本実施形態では、プラットフォーム部２１で実行された処理の内容を特許管理データベース２４にマッピングさせる、又は、従来の特許管理システム２０Ａに取り込まれている案件に対する承認ルートを決定してプラットフォーム部２１のワークフロー上に作成して組み込むことで、ワークフローシステム２０Ｂと従来の特許管理システム２０Ａとを連携させている。

次に、ワークフローシステム２０Ｂと従来の特許管理システム２０Ａとの連携に関する処理、その他プラットフォーム構想を用いた特許管理システム１で実施可能な処理についてさらに詳しく説明する。

まず、ワークフローシステム２０Ｂと従来の特許管理システム２０Ａとの連携に関する処理としては、マッピング手段、承認ルート決定手段が主体となって実行する処理がある。

＜マッピング処理＞
マッピング処理は、マッピング手段が主体となって実行する処理であり、後述する定義ファイル２２０を参照しながらワークフローデータベース２２に格納されている処理内容の格納先を決定して特許管理データベース２４にマッピングする処理を実行する。

定義ファイル２２０には、処理内容が入力される入力項目と特許管理データベース２４の格納先との対応付けが定義されている。さらに、定義ファイル２２０は、入力項目と画面レイアウト上のフィールド位置との対応付けをさらに管理している。ここで、定義ファイル２２０の一例を図４に示す。図４は、出願提案機能２０２により参照される定義ファイル２２０の一例である。図４に示す例では、画面上に表示される項目名を示す表示項目名、必須項目であるか否かを示す必須の有無、表示の形式を示す基本表示タイプ、項目の意味などの各項目が対応付けられて定義されている。

図３に示す例のように、例えば、出願提案機能２０２により出願提案がされると、承認機能２０３による承認が実行される。そして、提案受付機能２０４により出願提案が受け付けられると、出願工程管理機能２０５により出願までの工程作業が管理される。このとき、各機能により実行された作業の処理内容は、その都度ワークフローデータベース２２に格納され、定義ファイル２２０に基づいて特許管理データベース２４への格納先が決定されて対象となる情報がマッピングされる。同時に、入力画面３００の画面レイアウトも変更される。

また、例えば、中間書類問合せ機能２０６により中間書類の問合せがされると、中間書類回答者決定機能２０７により回答者が決定される。そして、中間書類回答機能２０８が回答を受けると、承認機能２０３により回答が承認され、中間書類決定機能２０９により最終決定がなされて、中間書類工程管理機能２１０により中間の工程作業が管理される。このときも同様に、各機能により実行された作業の処理内容は、その都度ワークフローデータベース２２に格納され、定義ファイル２２０に基づいて特許管理データベース２４への格納先が決定されて対象となる情報がマッピングされる。同時に、入力画面３００の画面レイアウトも変更される。

上述のようなマッピング処理を簡略的に示すと、例えば、図５に示すようになる。図５に示す例では、定義ファイル２２０に基づいて、入力画面３００の画面レイアウト及び特許管理データベース２４の格納先として決定されたテーブル２４０に情報が対応付けられている。これにより、社内状況や社内要望に応じた柔軟性のあるシステムを構築することができる。また、定義ファイル２２０を変更することで容易にワークフローをカスタマイズすることができるため、業務の効率性、利便性、戦略性などを考慮した自由度のあるシステムを構築することが可能となる。

＜承認ルート決定処理＞
承認ルート決定処理は、承認ルート決定手段が主体となって実行する処理であり、後述する承認ルート定義テーブル２３０に基づいて案件の書類名に応じた承認ルートを自動決定する処理を実行する。同時に、承認ルート決定手段は、承認ルートに対応する業務手順をワークフロー上に作成する処理を実行する。さらに、承認ルート定義テーブル２３０に基づいて決定した承認ルートに応じた業務上の期限を自動算出する処理を実行する。

承認ルート定義テーブル２３０には、案件に示された書類名と承認ルートとの対応付けが定義されている。すなわち、書類とその動作との関係が定義されている。ここで、承認ルート定義テーブル２３０の一例を図６に示す。図６に示す例では、案件の内容を示す書類名、国内案件であるか外国案件であるかを示す内外、業務の処理形式を示すルート、期限を発生させる際の基準となる起算日、業務毎の期限を算出するための式などの各項目が対応付けられて定義されている。このような承認ルート定義テーブル２３０に基づいて、承認ルート決定手段は、テーブル中の書類名と一致する書類が登録された場合、又はテーブル中の書類名を利用者から指示された場合などを判断して、ワークフローシステム２０Ｂに対するデータを発生させることができる。

ここで、承認ルート決定処理について、具体的に説明する。図７は、本発明の一実施形態に係る承認ルート処理の一例を示す図である。

図示するように、従来の特許管理システム２０Ａから、電子ファイル（プルーフ）が包袋ファイル（電子書類）として登録されると（Ｓ１）、電子ファイルのファイル名または管理情報から書類名（Ｐ）を取得する（Ｓ２）。ここで、書類名（Ｐ）が特許管理データベース２４の登録書類名と一致するか否かを判断して（Ｓ３）、一致する場合には、登録されている書類区分を判断する（Ｓ４）。ここで、承認を必要とする問合せ書類である場合には、登録された書類情報から社内回答期限日を計算し、承認ルート上の問合せ書類としてワークフロー（Ｗ／Ｆ）上に作成する（Ｓ５）。一方、承認を必要としない通知書類である場合には、登録された書類情報からその旨のデータをワークフロー（Ｗ／Ｆ）上に作成する（Ｓ６）。これにより、ワークフロー上へ書類に応じた承認ルートを設定することができる。

また、ステップＳ５の社内回答期限日は、例えば、承認ルート定義テーブル２３０に定義されている起算日（Ｓ）と式（Ｅ）に基づいて、社内回答期限日（Ｄ）＝今日＋（Ｓ−今日）Ｅという算出式から自動算出される。これにより、承認ルートに応じた期限を設定することができる。

上述のように、従来の特許管理システム２０Ａから、例えば、特許庁からの中間書類のプルーフが登録された際などに、登録された書類名が承認ルート定義テーブル２３０に定義された書類名と一致する場合、包袋（電子書類）の取り込みと同時にワークフローシステム２０Ｂに対して中間書類の問合せ又は通知データなどを発生させることができる。

次に、プラットフォーム構想を用いた特許管理システム１で実施可能な処理としては、データ授受手段、アクセスキー生成手段、工程管理手段が主体となって実行する処理がある。

＜データ授受＞
データ授受は、データ授受手段が主体となって送り手側と受け手側との間で各種データを授受するためにオンライン納品サーバ１０で実行される処理である。図８は、本発明の一実施形態に係るデータ授受の処理例を示す図である。なお、本実施形態では、企業２と特許事務所３との間でデータを授受する場合を想定しており、データが授受される度にオンライン納品サーバ１０の立場が送り手側と受け手側とで入れ替わる。

本実施形態では、データ授受に関する段階と動作の関係を状態番号として例示している。状態番号は、２桁以上で示され、この状態番号を１０で割った商がフェーズ番号（Ｐ）、余りがアクション番号（Ａ）として抽出される。この場合、同じフェーズ番号（Ｐ）を持つデータは、同一段階のものとなり、アクション番号（Ａ）が“０”でフェーズの開始を示し“９”でフェーズの終了を示している。

図８に示すように、まず、データが送信されると送り手側となり、現在の状態番号（Ｎ）を取得する（Ｓ１０）。ここで、主導権が自分側（企業２側）にあるか否かが判断され（Ｓ１１）、主導権が自分側にある場合には、現在の状態番号を次の状態番号に設定する（Ｓ１２）。すなわち、状態番号が、Ｎ＝Ｎ＋１と設定される。そして、現在のフェーズ番号（Ｐ）と現在のアクション番号（Ａ）が上述のように抽出される（Ｓ１３）。そして、現在のアクション番号（Ａ）を判別してそれぞれの処理に移行させる（Ｓ１４）。まず、現在のアクション番号（Ａ）が“０”である場合には、フェーズの開始段階と判断され、現在のアクション番号（Ａ）を０として現在のフェーズ番号（Ｐ）のまま状態データを取得して（Ｓ１５）、取得した状態データの内容をリストに表示させる（Ｓ１８）。一方、現在のアクション番号（Ａ）が“９”である場合には、フェーズの終了段階と判断され、現在のアクション番号（Ａ）を９として現在のフェーズ番号（Ｐ）を超える状態番号をもつ状態データを取得する（Ｓ１６）。そして、現在のフェーズ番号（Ｐ）と等しい状態番号をもつ状態データを取得（追加）して（Ｓ１７）、取得した状態データの内容をリストに表示させる（Ｓ１８）。その他、現在のアクション番号（Ａ）が“０＜Ａ＜９”である場合には、フェーズの同一段階と判断され、ステップＳ１７−Ｓ１８という流れで処理が実行される。

一方、データが受信されると受け手側となり、現在のアクション番号（Ａ）が“１≦Ａ≦９”となる状態データが処理の対象となる。この場合、ステップＳ１４で現在のアクション番号（Ａ）が判別された後、ステップＳ１７−Ｓ１８という流れで処理が実行される。

上述のような処理が実行されたときの状態遷移が示されたリスト例を図９及び図１０に示す。図９は、本発明の一実施形態に係る出願業務時に実行されるデータ授受の状態遷移を示す図であり、図１０は、本発明の一実施形態に係る中間業務時に実行されるデータ授受の状態遷移を示す図である。

図示するように、企業２側と特許事務所３側との間で授受されるデータは、データの種別により次のアクションが随時限定されていく。このため、ある業務に対する状態の遷移を企業２と特許事務所３とでそれぞれ一意に把握することができる。また、ある案件に対して、企業２側で滞っているのか又は特許事務所３側で滞っているのかという処理状況、あるいは進捗状況などを容易に把握することもできる。さらに、容易に把握するための工夫として、例えば、色づけられたアイコンボタンを合わせて表示するようにしてもよい。

なお、本実施形態では、原則として、フェーズ（Ｐ）は企業２側で開始し企業２側で終了している。すなわち、主導権が企業２側の状態で処理が実行されている。しかし、例えば、中間業務時などに最初の依頼データを送信する際などは、例外となる。このような場合、例えば、企業２側と特許事務所３側で対象となる開始の状態番号を異ならせることで対応するようにしてもよい。

＜データ公開＞
データ公開は、アクセスキー生成手段が主体となって実行される処理である。図１１及び図１２は、本発明の一実施形態に係るデータ公開の処理の一例を示す図である。

図１１（ａ）に示すように、アクセスが制限されている案件を期限付きで公開する場合には、例えば、案件の書類番号（Ｎ）、利用者ＩＤ（Ｐ）、利用期限日（Ｄ）を組み合わせた値（Ａ）を秘密鍵（Ｓ）により暗号化する（Ｓ２０）。すなわち、値（Ａ）と秘密鍵（Ｓ）を暗号関数｛ｆ（）｝に渡してアクセスキー｛（Ｋ）＝ｆ（Ａ、Ｓ）｝を得る。アクセスキーは、一部に利用情報を含む暗号化ＵＲＬとして公開を許可する社員に対して送信される。そして、暗号化ＵＲＬを受信した社員が、そのＵＲＬにアクセスすると、ワークフローシステム２０Ｂはユーザ認証を行う。

ワークフローシステム２０Ｂでは、図１１（ｂ）に示すように、ログインユーザのＩＤを取得すると（Ｓ２１）、引数のアクセスキー（Ｋ）を復号化して利用者ＩＤ（Ｐ）、利用期限日（Ｄ）、書類番号（Ｎ）を取得する（Ｓ２２）。ここで、利用者ＩＤ（Ｐ）とログインユーザのＩＤを比較し（Ｓ２３）、一致している場合には、利用期限日（Ｄ）が今日以前であるかを判断し（Ｓ２４）、今日以前である場合には、該当する書類番号（Ｎ）の案件を表示する（Ｓ２５）。

なお、上述の暗号化には、例えば、３ＤＥＳ（Triple Data Encryption Standard）、Ｂｌｏｗｆｉｓｈなどの秘密鍵暗号アルゴリズムを適用することが考えられる。

ここで、図１１に示すデータ公開は、アクセスが制限されている案件を期限付きで公開する場合を想定しているが、例えば、図１２に示すように、特定多数に公開するようにしてもよい。

図１２（ａ）に示すように、アクセスが制限されている案件を特定多数に公開する場合には、例えば、案件の書類番号（Ｎ）と秘密鍵（Ｓ）を１方向ハッシュ関数（ｆ）で暗号化する（Ｓ３０）。すなわち、書類番号（Ｎ）に秘密鍵（Ｓ）を加えたものを１方向ハッシュ関数｛ｆ（）｝に渡してアクセスキー｛（Ｋ）＝ｆ（Ｎ＋Ｓ）｝を得る。アクセスキーは、公開を許可する社員に対して送信される。そして、アクセスキーを受信した社員が、所定のＵＲＬにアクセスすると、ワークフローシステム２０Ｂはユーザ認証を行う。

ワークフローシステム２０Ｂでは、図１２（ｂ）に示すように、引数から書類番号（Ｎ）とアクセスキー（Ｋ）を取得する（Ｓ３１）。そして、書類番号（Ｎ）に秘密鍵（Ｓ）を加えたものを１方向ハッシュ関数｛ｆ（）｝に渡した結果（Ｒ）を取得する（Ｓ３２）。ここで、結果（Ｒ）とアクセスキー（Ｋ）を比較し（Ｓ３３）、一致している場合には、該当する書類番号（Ｎ）の案件を表示する（Ｓ３４）。

なお、上述の暗号化には、例えば、ＭＤ５（Message Digest 5）、ＳＨＡ（Secure Hash Algorithm）などの１方向ハッシュ関数を適用することが考えられる。

＜工程管理＞
工程管理は、工程管理手段が主体となって実行される処理である。工程管理手段は、各案件毎の基本的な目的にあった工程作業（至急／通常、重要など）が定義されたテンプレートに基づいて一連の工程作業を生成して、ワークフロー上に各案件毎の標準的な工程を発生させている。この場合、例えば、目的が変更した工程は、適用するテンプレートを変更したり、既存工程に追加・削除を施したりすることで、変則的な工程を発生するようにしてもよい。このような工程管理では、例えば、各案件毎の工程作業におけるスケジュールや進捗状況を管理すると同時に、作業に要した日数又は作業終了日などを入力させるようにし、工程毎の入力内容から社員の評価を蓄積するようにしてもよい。

（他の実施形態）
上述した実施形態では、データ公開をする際に、アクセスキー生成手段による暗号化をすることを前提としているが、これに限定されず、例えば、図３に示す出願特許検索機能２０１を用いてデータを検索する際にアクセス制限を施すようにしてもよい。

この出願特許検索機能２０１は、少なくとも、出願にかかる案件を示す種別（例えば、四法の種類、その組み合わせ、及び四法の有無）、出願に関連する会社を示す法人、その法人に属する部門、その出願にかかる案件に対する職位、及びその出願にかかる案件に対する役割の何れかに応じて各案件に対するアクセス制限を設定する。

具体的には、アクセスしたユーザ（例えば、正社員、契約社員、関連会社社員、派遣社員）に関する条件を、アクセスしたユーザが属する会社コード、アクセスしたユーザが属する部門コード、アクセスしたユーザを識別する社員コード、アクセスしたユーザの職位、アクセスしたユーザの基本的な一般役割、アクセスしたユーザの知財部門での知財部役割という各項目に分類し、その項目を単独で指定する又は組み合わせて指定する。そして、図１３に示す許可定義テーブルに基づいて、図１４及び図１５に示すようなアクセス制御の条件が設定されることになる。

ここで、図１３（ａ）に示す許可定義テーブルには、各案件の種別を指定する際の定義がされている。すなわち、許可する各許可四法（四法、特実意、特、実、意、商）に対する条件の意味が定義されている。一方、図１３（ｂ）に示す許可定義テーブルには、アクセス条件のルールが定義されている。すなわち、許可方法（open、public、protected、private、close）に対する意味（完全開示、公開開示、限定開示、本人開示、非開示）が各々定義されている。また、ここでいう完全開示とは、すべてを公開する意であり、公開開示とは、公開後に開示する（但し、アクセスするユーザにより開示条件が異なる）意であり、限定開示とは、案件に関わる限定されたユーザ、例えば、発明者及び特許連絡者に対してのみ開示する意であり、本人開示とは、発明者本人のみに対して開示する意であり、非開示とは、一切開示しない意である。

また、アクセス制御の条件例として、図１４（ａ）には一般には公開後に開示する場合が示されており、図１４（ｂ）には役割者別に開示する場合が示されており、図１４（ｃ）には部門毎に開示する場合が示されている。すなわち、正社員に対するアクセス制限が設定されている。ここで、図中の＊は任意であることを示しており、＝はアクセスしたユーザ自身とマッチすること（同じこと）を示しており、＠はアクセスしたユーザが担当した法人又は部門を示している。

図１４（ａ）には、アクセス制限を識別して管理するＡＣＬ（Access Control List）番号に対して、法人コード、部門コード、社員コード、職位、役割、知財部、許可法人ＩＤ、許可部門ＩＤ、許可四法、及び許可方法がそれぞれ設定されている。具体的には、部門コードが９９９９（知財部）のログインユーザには、全ての案件を完全開示（open）にすること（ＡＣＬ番号；３００）、及びログインユーザ全てに、公開された案件について公開開示（public）にすること（ＡＣＬ番号；９９９）が例示されている。

また、図１４（ｂ）も図１４（ａ）と同様に、各ＡＣＬ番号に対してアクセス制限が設定されている。具体的には、図１４（ａ）に対し、知財総括という役割を持つユーザには、自社の全部門の特許、実用新案、意匠の各案件を完全開示（open）にすること（ＡＣＬ番号；２２０）、及び知財連絡という役割を持つユーザには、自社の担当部門の特許、実用新案、意匠の各案件を完全開示（open）にすること（ＡＣＬ番号；２４０）が追加されて例示されている。

また、図１４（ｃ）も図１４（ａ）と同様に、各ＡＣＬ番号に対してアクセス制限が設定されている。具体的には、図１４（ｃ）に対し、自社（法人コード０００１）の部門コード１０００に属するログインユーザには、自社の全部門の各案件を公開開示（public）にすること（ＡＣＬ番号；３１０）、自社（法人コード０００１）の部門コード１２００に属するログインユーザには、自社の全部門の商標案件のみを完全開示（open）にすること（ＡＣＬ番号；３２０）、自社（法人コード０００１）の部門コード３７００に属するログインユーザには、自社の全部門の特許、実用新案、意匠の各案件を完全開示（open）にすること（ＡＣＬ番号；３３０）、及び自社（法人コード０００１）に属するログインユーザには、自部門の特許、実用新案、意匠の各案件を公開開示（public）にすること（ＡＣＬ番号；３９０）が追加されて例示されている。

一方、図１５（ａ）には、関連会社に開示する場合が示されており、図１５（ｂ）には、派遣社員に開示する場合が示されている。すなわち、正社員以外に対するアクセス制限が設定されている。

図１５（ａ）には、図１４（ｃ）に加えて、関連会社に対するアクセス制限が設定されている。具体的には、関連会社（法人コード２０１０）の知財担当の役割を担うログインユーザには、その関連会社に属する全ての部門の各案件を完全開示（open）にすること（ＡＣＬ番号；４１０）、関連会社（法人コード２０１０）のログインユーザには、その関連会社に属する全ての部門の各案件を公開開示（public）にすること（ＡＣＬ番号；４１５）、関連会社（法人コード３０２０）で社員コード９０２１を持つログインユーザには、その関連会社に属する全ての案件を完全開示（open）にすること（ＡＣＬ番号；４２０）、及び関連会社（法人コード３０２０）のログインユーザには、その関連会社に属する全ての案件を発明者のみに本人開示（private）にすること（ＡＣＬ番号；４２５）が例示されている。

また、図１５（ｂ）には、派遣社員に対するアクセス制限が設定されている。具体的には、派遣社員（社員コードＺ０００１）のログインユーザには、全ての案件を非公開（close）にすること（ＡＣＬ番号；１０１）、及び派遣社員（社員コードＺ０００２）のログインユーザには、自社（法人コード０００１）の全ての案件を完全開示（open）にすること（ＡＣＬ番号；１０２）が例示されている。

上述した図１４及び図１５のアクセスに関する制御条件をリスト化したものが、図１６に示すような画面として表示されることになる。そして、このような画面に設定された項目に従って、データ公開又は検索処理時などのアクセス制限をすることができる。

さらに、上述した実施形態では、データ公開又は検索処理時などに表示される画面の表示については、特に言及していないが、例えば、長期的スパンに亘り情報が蓄積され、年々表示する情報量が膨大になる知的財産業務では、必要な部分を簡略化して１画面に収まるレイアウトを採用してもよい。この場合、ある箇所（情報）を具体的に表示する際には、例えば、画面上の所定の部分をクリック操作することなどにより、画面が拡大したり縮小したりすれる構成にすればよい。これにより、業務に応じて適切な情報を効率的に取り扱うことができる。

本発明の一実施形態に係るプラットフォーム構想を用いた特許管理システムの概略構成を示す図である。 本発明の一実施形態に係るプラットフォーム構想を用いた特許管理システムのシステム構成を示す図である。 本発明の一実施形態に係るワークフローシステムのシステム構成を示す図である。 本発明の一実施形態に係る定義ファイルの一例を示す図である。 本発明の一実施形態に係るマッピング処理の一例を示す図である。 本発明の一実施形態に係る承認ルート定義テーブルの一例を示す図である。 本発明の一実施形態に係る承認ルート処理の一例を示す図である。 本発明の一実施形態に係るデータ授受の処理例を示す図である。 本発明の一実施形態に係る出願業務時に実行されるデータ授受の状態遷移を示す図である。 本発明の一実施形態に係る中間業務時に実行されるデータ授受の状態遷移を示す図である。 本発明の一実施形態に係るデータ公開の処理の一例を示す図である。 本発明の一実施形態に係るデータ公開の処理の一例を示す図である。 本発明の一実施形態に係る検索定義テーブルの一例を示す図である。 本発明の一実施形態に係るアクセス制御の条件の一例を示す図である。 本発明の一実施形態に係るアクセス制御の条件の一例を示す図である。 本発明の一実施形態に係るアクセス制御の条件をリスト化した一例を示す図である。

符号の説明

２ 企業
３ 特許事務所
４ ネットワーク
１０ オンライン納品サーバ
１１ ファイヤーウォール
２０ 特許管理サーバ
２０Ａ 従来の特許管理システム
２０Ｂ ワークフローシステム
２１ プラットフォーム部
２２ ワークフローデータベース
２３ モジュール
２４ 特許管理データベース
２５ プログラム
２０１ 出願特許検索機能
２０２ 出願提案機能
２０３ 承認機能
２０４ 提案受付機能
２０５ 出願工程管理機能
２０６ 中間書類問合せ機能
２０７ 中間書類回答者決定機能
２０８ 中間書類回答機能
２０９ 中間書類決定機能
２１０ 中間書類工程管理機能
２２０ 定義ファイル
２３０ 承認ルート定義テーブル
２４０ テーブル
３００ 入力画面
４０ 特許公報検索システム
３０ 端末

Claims (8)

1. 少なくとも知的財産業務で発生する情報を蓄積して管理する特許管理データベースと、
   知的財産業務を遂行するための基本的な業務手順を網羅したワークフローシステムとを具備し、所定のグループ内で知的財産業務を遂行する特許管理システムであって、
   前記ワークフローシステムは、
   前記業務手順に基づいて所定の処理を行うワークフロー機能モジュールと、
   前記ワークフロー機能モジュールで使用する入力画面の画面レイアウト及び入力項目、並びに前記入力項目と前記特許管理データベースの格納先との対応付けを定義した定義データと、
   前記ワークフロー機能モジュールの下で、前記定義データをウエブブラウザで解釈可能な形式に変換して入力画面を作製し、当該入力画面をウエブブラウザに送信し、ウエブブラウザで前記入力画面の前記入力項目に対応して入力された入力データを取得し、当該入力データに所定の処理を実行した処理内容をワークフローデータベースに格納するプラットフォーム部とを備え、
   さらに前記定義データの前記対応付けを参照しながら前記ワークフローデータベースに格納された前記処理内容を前記特許管理データベースにマッピングするマッピング手段を備える
   ことを特徴とするプラットフォーム構想を用いた特許管理システム。
2. 請求項１に記載するプラットフォーム構想を用いた特許管理システムにおいて、
   前記業務手順は、知的財産業務の出願に関し、出願にかかる案件の検索、出願提案、業務の承認、出願提案を受け付けるための提案受付、又は出願提案された案件の工程管理であり、
   これらの業務手順ごとに定義データが作成されている
   ことを特徴とするプラットフォーム構想を用いた特許管理システム。
3. 請求項１に記載するプラットフォーム構想を用いた特許管理システムにおいて、
   前記業務手順は、知的財産業務の中間に関し、中間書類の問合せを行うための中間書類問合せ機能、中間書類の回答者を選定又は変更するための中間書類回答者決定、中間書類の回答作業を管理するための中間書類回答、中間書類に関する回答の承認作業を管理するための中間書類承認、中間書類に関する所定事項を決定するための中間書類決定、又は中間書類の工程を管理するための中間書類工程管理であり、
   これらの業務手順ごとに定義データが作成されている
   ことを特徴とするプラットフォーム構想を用いた特許管理システム。
4. 請求項１〜３の何れか一項に記載するプラットフォーム構想を用いた特許管理システムにおいて、
   知的財産業務を遂行する上で各案件毎に通過する承認ルートを判定する承認ルート決定手段と、
   案件に示された書類名と承認ルートとの対応付けを定義した承認ルート定義テーブルとをさらに具備しており、
   前記承認ルート決定手段は、案件の書類名を前記承認ルート定義テーブルから検索して承認ルートを自動決定し、
   前記プラットフォーム部は、当該承認ルートに対応する業務手順に関する前記定義データの画面レイアウトを、ウエブブラウザで解釈可能な形式に変換して、前記入力項目に対して処理内容を入力させる入力画面を作製し、当該承認ルートに対応する入力画面をウエブブラウザに送信し、ウエブブラウザで前記入力画面の入力項目に対して入力された入力データを取得し、当該入力データに所定の処理を実行した処理内容をワークフローデータベースに格納する
   ことを特徴とするプラットフォーム構想を用いた特許管理システム。
5. 請求項４に記載するプラットフォーム構想を用いた特許管理システムにおいて、
   前記承認ルート定義テーブルには、業務毎の期限を算出するための式が含まれており、前記承認ルート決定手段は、前記承認ルート定義テーブルに基づいて決定した承認ルートに対応する式を前記承認ルート定義テーブルから検索し、当該式から業務上の期限を自動算出する
   ことを特徴とするプラットフォーム構想を用いた特許管理システム。
6. 請求項１〜５の何れか一項に記載するプラットフォーム構想を用いた特許管理システムにおいて、
   外部とのデータ授受を段階的に行う場合に、データ授受に関する状態遷移を数値化して管理するデータ授受手段を具備し、
   前記データ授受手段は、段階と動作との関係を、データ授受の状態を表した数値に対応付ける
   ことを特徴とするプラットフォーム構想を用いた特許管理システム。
7. 請求項１〜６の何れか一項に記載するプラットフォーム構想を用いた特許管理システムにおいて、
   アクセス権限が制限されている情報へアクセスをする際に、アクセス条件の一部が暗号化されたアクセスキーを生成するアクセスキー生成手段を具備し、
   前記アクセスキー生成手段は、対象となる情報に付与されているユニークな書類番号に基づいて利用目的に応じたアクセスキーを生成する
   ことを特徴とするプラットフォーム構想を用いた特許管理システム。
8. 請求項２に記載するプラットフォーム構想を用いた特許管理システムにおいて、
   前記ワークフロー機能モジュールで扱われる業務手順の出願に係る案件の検索は、前記特許管理データベースから出願特許を検索する処理であり、
   当該出願特許を検索する際には、少なくとも、前記出願にかかる案件を示す種別、出願に関連する会社を示す法人、当該法人に属する部門、当該出願にかかる案件に対する職位、及び当該出願にかかる案件に対する役割の何れかに応じて各案件に対するアクセス制限を設定する
   ことを特徴とするプラットフォーム構想を用いた特許管理システム。

Images