JP5651795B1 - 知的財産情報管理システム - Google Patents

Abstract

【課題】ユーザ企業毎に案件に係る各種業務をワークフロー処理により管理することを可能とする知的財産情報管理システムを提供する。【解決手段】各組織体がそれぞれ保有する知的財産に係る１つ以上の案件の情報を保持する案件ＤＢ２７と、知的財産権の取得手続における法定期限管理に係るワークフローの定義情報であるルートマスタの情報を保持するルートマスタＤＢ２８と、ルートマスタの定義内容に基づいて各組織体において各案件についての管理業務をワークフローにより制御するワークフロー処理部１３と、各ワークフローに係る実績情報を保持するワークフローＤＢ２９とを有し、ルートマスタは、知的財産情報管理システム１の運用事業者により定義された第１のルートマスタと、組織体毎に第１のルートマスタに基づいて定義された、もしくは独自に定義された第２のルートマスタとを含む。【選択図】図１

Description

本発明は、知的財産に係る情報を管理する技術に関し、特に、発明等の案件に係る各種業務をワークフロー処理によって管理する知的財産情報管理システムに適用して有効な技術に関するものである。

企業では、業務の中から発明などの知的財産が創出され、これを適切に知的財産権として保護し、事業への活用を図るために特許出願等が行われる場合がある。ここで、企業の規模等が大きくなってくると、創出される発明等の知的財産の数や、特許出願等の件数、特許権等の知的財産権の数も多くなり、例えば、案件毎のステータスの管理や、案件に係る情報へのアクセス権限の管理、期限の管理等、各種の管理の負担が大きくなってくる。そこで、これらの管理を情報処理システムにて行うことが検討されている。

例えば、特許第５２１２５１４号公報（特許文献１）には、知的財産情報を一元的に管理している知的財産情報管理装置と、複数の利用者端末と、知的財産情報管理装置と利用者端末とを接続するコンピュータネットワーク（イントラネット）とを備えており、自己が所有する知的財産の期限管理及び包袋管理を行うとともに、発明部門及び知的財産部門の知的財産業務に関する回覧・検討・承認をワークフロー化した知的財産情報管理システムが記載されている。

特許第５２１２５１４号公報

特許文献１に記載されたような技術を用いることで、例えば、発明等の案件に係る各種業務について、関連する部門や社員、関連会社などに対して案件情報へのアクセス権を制御しつつ、ワークフロー処理によって管理することが可能となる。

しかしながら、特許文献１に記載されたような技術では、単一のユーザ企業が管理システムを所有して、関連会社や特許事務所のユーザのアクセス権限を制御したり、ワークフロー処理を実現したりするものである。すなわち、知的財産を創出し取り扱うユーザ企業自身がシステムを所有して運用する形態を前提としており、当該ユーザ企業の社員や、取引等の関係がある他の関連会社や特許事務所等に所属する者がシステムのユーザとなるものであり、例えば、サービス提供事業者によりシステムが運用され、複数の異なるユーザ企業毎に、それぞれが独立した形で共同利用可能なサービスとして知的財産情報の管理機能を提供するような構成での適用については考慮されていない。

そこで本発明の目的は、サービス提供事業者によりシステムが運用され、複数の異なるユーザ企業毎に、それぞれが独立した形で共同利用可能なサービスとして知的財産情報の管理機能を提供する構成において、ユーザ企業毎に案件に係る各種業務をワークフロー処理により管理することを可能とする知的財産情報管理システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による知的財産情報管理システムは、複数のユーザを有する複数の組織体に知的財産管理サービスを提供するサービス提供事業者により管理され、ネットワークを介して前記複数の組織体に属するユーザが使用するユーザ端末からアクセスされることにより前記知的財産管理サービスを提供する知的財産情報管理システムであって、以下の特徴を有するものである。

すなわち、前記各組織体がそれぞれ保有する知的財産に係る１つ以上の案件の情報を保持する案件情報保持部と、知的財産権の取得手続における法定期限管理に係るワークフローの定義情報であるルートマスタの情報を保持するルートマスタ情報保持部と、前記ルートマスタの定義内容に基づいて前記各組織体において前記各案件についての管理業務をワークフローにより制御するワークフロー処理部と、前記各ワークフローに係る実績情報を保持するワークフロー情報保持部と、を有し、前記ルートマスタ情報保持部に保持されている前記ルートマスタは、前記サービス提供事業者により定義された１つ以上の第１のルートマスタと、前記組織体毎に前記第１のルートマスタに基づいて定義された、もしくは独自に定義された１つ以上の第２のルートマスタと、を含むものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、サービス提供事業者によりシステムが運用され、複数の異なるユーザ企業毎に、それぞれが独立した形で共同利用可能なサービスとして知的財産情報の管理機能を提供する構成において、ユーザ企業毎に案件に係る各種業務をワークフロー処理により管理することが可能となる。

本発明の一実施の形態である知的財産情報管理システムの構成例について概要を示した図である。 本発明の一実施の形態における案件に対するアクセス権限を設定する場合の例について概要を示した図である。 本発明の一実施の形態における案件のステータスによってアクセス権限を有するグループを変動させる場合の例について概要を示した図である。 本発明の一実施の形態における各機能や操作に対するアクセス権限を設定する場合の例について概要を示した図である。 本発明の一実施の形態におけるユーザインタフェース部により提供される案件の管理画面の例について概要を示した図である。 本発明の一実施の形態におけるワークフローのルート情報を設定する画面の例について概要を示した図である。 本発明の一実施の形態における修飾語の内容を設定する画面の例について概要を示した図である。 本発明の一実施の形態における実行中のワークフローのルートを変更する画面の例について概要を示した図である。 本発明の一実施の形態における修飾語マスタにおける修飾語の設定内容を変更する画面の例について概要を示した図である。 本発明の一実施の形態における案件の詳細画面からワークフローを開始する場合の例について概要を示した図である。 本発明の一実施の形態におけるワークフローの選択画面からワークフローを開始する場合の例について概要を示した図である。 本発明の一実施の形態におけるルートマスタの階層構造の例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態におけるワークフローを案件毎に束として管理する場合の例について概要を示した図である。 本発明の一実施の形態における束に係る案件のフロー制御の例について概要を説明する図である。 （ａ）、（ｂ）は、本発明の一実施の形態における束に案件を後から追加する場合の例について概要を示した図である。 本発明の一実施の形態における案件の担当者を変更した場合の束の制御の例について概要を示した図である。 （ａ）〜（ｃ）は、本発明の一実施の形態におけるユーザＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態におけるグループＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における案件制御ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における役割ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における機能制御ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における契約ＤＢのデータ構成の例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態における案件ＤＢのデータ構成の例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態におけるルートマスタＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態におけるワークフローＤＢのデータ構成の例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

本発明の一実施の形態である知的財産情報管理システムは、創出された発明等の知的財産（知的財産権の対象となる知的財産）について、そのライフサイクルにわたって案件としてステータスや情報の管理を行うための機能やサービスを提供する情報処理システムである。当該知的財産情報管理システムは、例えば、ＩＴベンダー等の事業者により運営され、ＡＳＰ（Application Service Provider）として複数の企業が共同利用する形で利用者にネットワークを介してサービスを提供するよう実装される。利用者としては、企業等において発明等の知的財産を創出する発明者や関連部門のユーザ、知財部員等と、当該企業等からの依頼により知的財産権取得のための出願手続等を行う特許事務所等の代理人や事務職員等のユーザが想定される。

本実施の形態では、例えば、企業等がこれらのユーザについて１つ以上のグループを構成し、案件毎にアクセス可能なグループを設定することで、代理人に開示・依頼する前の段階から、そのライフサイクルにわたって案件の特性や状況に応じたアクセス制御を可能とする。さらに、各案件について、ユーザの役割毎にアクセス可能な機能・操作を設定することで、より柔軟できめ細かいアクセス制御を可能とする。

本実施の形態では、さらに、知的財産に係る案件についての管理業務を対象として、１案件のライフサイクルが数年〜十数年という長いものとなり得るなどの知的財産管理の特性を考慮しつつ、ユーザ企業間でのアクセス制御がされている状態で、それぞれの企業が企業毎の実情に応じた形で独自にワークフロー化することを可能とする。

＜システム構成＞
図１は、本発明の一実施の形態である知的財産情報管理システムの構成例について概要を示した図である。知的財産情報管理システム１は、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバなどにより実装される情報処理システムであり、上述したように、インターネット等のネットワーク２を介して、企業３や特許事務所４等のユーザに対してＡＳＰとして知的財産に係る情報を管理する機能・サービスを提供する。

知的財産情報管理システム１は、例えば、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアプログラムとして実装されるアクセス制御部１１、管理機能群１２、ワークフロー処理部１３、およびユーザインタフェース部１４などの各部を有する。また、データベース等により実装されるユーザデータベース（ＤＢ）２１、グループＤＢ２２、案件制御ＤＢ２３、役割ＤＢ２４、機能制御ＤＢ２５、契約ＤＢ２６、案件ＤＢ２７、ルートマスタＤＢ２８、およびワークフローＤＢ２９などの各テーブルを有する。

アクセス制御部１１は、ユーザの認証を行うとともに、知的財産情報管理システム１が案件ＤＢ２７に保持する案件の情報および当該案件に関連する図示しない各種ファイル等の情報に対して、上述したようなユーザが属するグループによるアクセス制御およびユーザの役割によるアクセス制御を行う機能を有する。このとき、例えば、ユーザＤＢ２１、グループＤＢ２２、案件制御ＤＢ２３、役割ＤＢ２４、機能制御ＤＢ２５、および契約ＤＢ２６などの各テーブルを参照する。アクセス制御の内容については後述する。

管理機能群１２は、案件ＤＢ２７に保持する案件の情報および当該案件に関連する各種情報に対して実際にアクセスするための各種機能を提供するモジュール群である。案件に対するアクセスの内容としては、例えば、特定の案件についてのステータスや各種関連情報、データ等の管理、期限管理、各種の検索、企業３と特許事務所４との間での出願手続等の実行指示や各種連絡、関連する他社の知的財産権情報の取得やウォッチなどの機能が含まれる。さらに、これらの各機能や対象の情報について、その種類や特性等に応じて、作成、表示、更新、削除、実行、承認などの各操作を行うことが含まれる。

各案件に係るステータス等の情報の管理として、例えば、出願手続を行っている特許事務所４の代理人や事務職員等が、後述するユーザインタフェース部１４を介して管理機能群１２にアクセスし、特許庁から送付・送達された書面に係る情報（例えば、拒絶理由通知や査定などの情報）を入力できるようにすることで、個別の出願の状況の変化を把握することができる。

一方で、知的財産情報管理システム１が特許庁から複数の案件について一括して取得した情報を取り込んで、バッチ処理的に案件ＤＢ２７に反映させることも可能である。この場合、一括で取り込んだデータと、個別に手動で入力したデータとが矛盾する場合が生じ得るが、その場合は、その旨を通知していずれのデータを用いるかをユーザに選択させるようにしてもよい。このように、案件に係る情報を２つのルートから入力可能とすることで、タイムリーな入力と、入力負荷の低減とを両立させることができる。

また、本実施の形態では、管理機能群１２の１つとして、ワークフロー機能を有するワークフロー処理部１３を有している。例えば、ユーザが知的財産情報管理システム１にログインすると、当該ユーザに割り当てられた処理や通知等を表示するよう制御する。一般的な承認ワークフロー等に加えて、案件の状況や内容に応じて、知財部門の担当者が発明部門等に対して問い合わせをして返答を得る、というような知財管理に固有のワークフローを実装することもできる。

具体的な処理としては、例えば、トークンを発行してこれを予め定められたルートに従ってユーザ間で授受し、トークンを有するユーザに対して一定の処理を割り当てる。当該ユーザによる処理が完了すると、ルート上の次の対象ユーザに対してトークンが送付されるよう制御する。具体的には、例えば、知財部門の担当者が発明部門に対して出願審査請求の要否や登録特許に対する年金支払の要否等を問い合わせて回答を得るというような場面が想定される。

また、トークンが手許にないと何もできないことを回避するため、掲示板という案件とは別の権限制御の仕組みを設けてもよい。案件と掲示板を１対１で紐づけ、利用権限を持つ者同士は、トークンの所在にかかわらず、ワークフロー管理の外で自由に書き込みやファイルの受け渡しができる。例えば、明細書案を関係者で非同期にやりとりする場合に有効である。なお、ワークフロー機能の内容については後述する。

ユーザインタフェース部１４は、例えば、図示しないＷｅｂサーバプログラムを利用して、ユーザに対する画面インタフェースを提供する機能を有する。例えば、ログイン認証を行った各ユーザについてアクセス制御部１１によってアクセス可能な案件や管理機能を判別して、その内容に応じてアクセス可能な機能を表示する画面を生成して、ユーザに応答する。また、当該画面を介してユーザからのアクセス要求を受け付けて、対応する管理機能群１２やワークフロー処理部１３を呼び出すことにより、案件に対する各種機能や操作を実行し、結果を表示する画面を生成してユーザに応答する。

企業３における発明者や関連部門、知財部員などのユーザは、各ユーザが利用するＰＣ（Personal Computer）等の情報処理端末である企業端末３１上の図示しないＷｅｂブラウザ等を利用して、ネットワーク２を介して知的財産情報管理システム１のユーザインタフェース部１４にアクセスし、案件に対する各種機能や操作を実行する。

同様に、特許事務所４における代理人や事務職員などのユーザは、各ユーザが利用するＰＣ等の情報処理端末である事務所端末４１上の図示しないＷｅｂブラウザ等を利用して、ネットワーク２を介して知的財産情報管理システム１のユーザインタフェース部１４にアクセスし、案件に対する各種機能や操作を実行する。企業３と特許事務所４とは、知的財産情報管理システム１を介して相互に連携することができる。従って、企業３と特許事務所４とを跨ったワークフローを実現することも可能である。

なお、本実施の形態では、知的財産に係る情報を管理する機能をＡＳＰにより提供する形態としており、複数の企業３について管理を併存し、共同利用させることができる。これらの企業間では、当然ながら、案件に係る情報を相互に参照できないようアクセス制御を行う。本実施の形態では、各企業３は、当該知的財産情報管理システム１を運営してサービスを提供する事業者との間でそれぞれ契約を締結し、その情報は契約ＤＢ２６に保持される。各案件の情報はそれぞれ契約に関連付けられており、異なる契約に服するユーザ間では案件の情報を相互に共有することができないようアクセス制御部１１等により制御される。

具体的には、例えば、各企業３におけるユーザに設定されるユーザＩＤについて、上位数桁を契約毎に割り当てられるコード値により固定することで、ユーザＩＤと契約の関係を把握し、対象の契約に係る案件以外は参照できないよう制御する。また、セキュリティを高めるため、契約毎にユーザインタフェース部１４により提供される画面のＵＲＬ（Uniform Resource Locator）を異なるものとして入口から分離したり、ユーザのアクセス元のＩＰアドレスに基づいてドメイン認証などを行ったりして、契約外のユーザがアクセスできないよう制御してもよい。

＜同一契約内での案件に対するアクセス制御＞
図２は、同一の契約内、すなわち特定の企業３において、案件に対するアクセス権限を設定する場合の例について概要を示した図である。本実施の形態では、上述したように、１人以上のユーザを含むグループを構成し、各案件についてアクセス可能なグループを設定することで、案件毎にグループ単位でアクセス権限を設定する。当該設定は、例えば、図２に示すように、各案件（図中の各列）とグループ（図中の各行）からなるマトリクスに対してアクセス権（図中の“○”印）を設定する形で行われる。

各ユーザは、原則として１つ以上の何らかのグループにそれぞれ属するものとし、各案件に対してアクセス権を有するものとして設定されたグループに属するユーザが対象案件にアクセスすることが可能となる。グループとしては、例えば、“知財部門”や“経理部門”、“事業部Ａ”や“事業部Ｂ”などの各事業部等、契約している企業３において知的財産の管理に関わり得る部門や組織を設定することができる。このとき、例えば、企業３における人事情報データやユーザ管理データ等を取り込んで反映させることで、最新の人事異動や組織変更等の情報を反映させることができる。

また、企業３の部門に限らず、“特許事務所ａ”や“特許事務所ｂ”など、対象の企業３から依頼を受けて出願等の手続を代理する代理人や事務職員が属する特許事務所等の外部組織をグループとして設定することもできる。代理人等については、このように固有のグループを構成するのではなく、案件を担当する事業部のグループにユーザとして属するよう設定してもよい。また、企業３における組織上の構成単位をグループとするのに限らず、例えば、“事業部Ａ管理職”や“事業部Ｂ主任”など、対象組織において静的に有する職位（職務権限）をサブグループの単位としてもよい。

このように、特許事務所４における代理人や事務職員などのユーザは、各契約の主体となる企業３により当該企業３のユーザとして、知的財産情報管理システム１にアクセスするアクセス権限が付与されるように設定される。よって、当該知的財産情報管理システム１の契約主体である複数の企業３（例えば“企業a”と“企業ｂ”）の代理をする特許事務所４（例えば“特許事務所ａ”）の代理人や事務職員は、企業３毎に設定されたアクセス権限に基づいて当該知的財産情報管理システム１にアクセスするため、複数の企業３をまたいで情報が混同されることがないようにセキュリティが確保され、例えば自らが代理する代理案件を一覧することはできない。

すなわち、“特許事務所ａ”の代理人や事務職員は、“企業a”の代理案件と“企業ｂ”の代理案件とを同一アクセス内で参照することはできない。“企業a”の案件を参照するためには、“企業a”のユーザに対して認められた権限によるアクセスで参照し、“企業ｂ”の案件を参照するためには、“企業a”のユーザに対して認められた権限によるアクセスを出て、“企業ｂ”のユーザに対して認められた権限によるアクセスで参照する必要がある。

グループの単位を上記のような部門や組織、職位などの組織上の構成要素とした場合、人事異動等によって対象のグループに属するユーザが変動する結果として、案件に対するアクセス権の得喪が生じる場合がある。本実施の形態では、基本的には当該アクセス権の得喪に従うものとするが、例えば、当該案件における発明者など、人事異動等に関わらず対象の案件に対するアクセス権を維持したいという場合がある。

このような状況に対応するため、例えば、図中の“発明者α”のグループのように、組織の構成とは関わらない、各案件についての論理的なグループを構成することもできる。図２の例の場合、人事上の組織として“事業部Ｂ”のグループに属するユーザは“案件Ｂ”に対してアクセス権を有しているが、人事異動により“事業部Ｃ”のグループに移った場合にアクセス権を失う。しかしながら、当該ユーザが発明者であり、“発明者α”のグループにも属している場合は、人事異動によっても継続して“案件Ｂ”に対するアクセス権を維持することができる。

また、例えば、図中の“ユーザ１”のように、個別のユーザに対して、例外的に案件へのアクセス権を直接的に割り当てられるようにして柔軟な対応を可能としてもよい（メンバーが１人だけのグループとして他のグループと同様に取り扱うようにしてもよい）。

なお、図２に示したアクセス権の設定情報は、案件制御ＤＢ２３に登録される。また、各ユーザのマスタ情報はユーザＤＢ２１に登録され、各グループのマスタ情報はグループＤＢ２２に、各案件の情報は案件ＤＢ２７にそれぞれ登録されている。上述したように、ユーザＤＢ２１やグループＤＢ２２の情報は、例えば、企業３における人事情報データやユーザ管理データ等を取り込んで反映させるようにしてもよい。

本実施の形態では、知的財産情報管理システム１は、ＩＴベンダー等の事業者により運用され、ＡＳＰによるサービスとして提供されるが、上記のようなアクセス権限の設定・管理や各種データの登録等は、契約により当該サービスを利用する企業３等の担当者や管理者が設定するものとし、事業者はこれに関知しないものとしてもよい。

図３は、案件のステータスによってアクセス権限を有するグループを変動させる場合の例について概要を示した図である。案件は、例えば、発明等の知的財産が創出された状態から、知的財産権を取得するために出願手続を行い、特許庁によって公開公報等の公報が発行されて公知となり、特許権等の知的財産権が成立し、年金を納付して知的財産権を維持し、存続期間の満了で知的財産権が消滅して自由技術となる、というような典型的なライフサイクルの中で、ステータス等の変化に応じてその位置付けが変動し得る。

図３の例では、案件のステータスとして、まず、知的財産（例えば、発明）が発明部門により創出されて、これに対する案件が形成され、当該発明についてどのように保護・活用を図っていくかを検討する「検討中」（Ｓ０１ａ）のステータスとなる。図中では、このとき、関係者として“Ａ（知財部門）”と“Ｂ（発明部門）”、および“発（発明者）”が当該案件にアクセス可能であることを示している。なお、アクセス権の設定は、例えば、上記の図２に示したようなマトリクスの内容を後述する案件制御ＤＢ２３などに登録することにより設定される。

このステータスで、検討の結果、特許出願等の出願手続を行わないことになった場合は、「不出願」（Ｓ０２）のステータスとなって管理の対象から除外される。一方で、「検討中」（Ｓ０１ａ）のステータスで出願手続を行うことになった場合は、明細書等の書面を作成して出願手続を行うことによって「出願済」（Ｓ０３）のステータスに遷移する。

このとき、企業３自身が書面を作成して出願するいわゆる内作の場合と、特許事務所４等の代理人に委任して出願手続をする場合とがある。特許事務所４等に依頼した場合としなかった場合とでは、案件のその後のステータスにおいても、特許事務所４にアクセス権を付与するか否かが影響を受ける。本実施の形態では、特許事務所４等に依頼したというイベントは、当該案件についてのフラグ情報として別途保持することによりステータスとして把握するものとする。図３の例では、「検討中」（Ｓ０１ａ）のステータスにおいて特許事務所４に出願手続を依頼すると、「検討中」（Ｓ０１ｂ）のステータスにおいて、“代（代理人）”が新たに当該案件に対してアクセス可能となることを示している。

出願手続を行うと、当該案件のステータスは「出願済」（Ｓ０３）となり、“Ｃ（関連部門）”が新たに当該案件に対してアクセス可能となることを示している。このステータスで、例えば、出願審査請求手続を行わずに請求期限を経過した場合などでは、出願が取下げたものとみなされ、「取下」（Ｓ０４）のステータスとなって管理の対象から除外される。一方で、出願審査請求手続を行うと特許庁での審査に付され、「審査中」（Ｓ０５ａ）のステータスとなる。

「出願済」（Ｓ０３）もしくは「審査中」（Ｓ０５ａ）のステータスで、特許庁から公開公報が発行されると、当該案件に係る発明は公知となり、位置付けは大きく変わる。ただし、公開公報が発行される前に特許査定や拒絶査定が確定してしまう場合もある。本実施の形態では、公開公報が発行されたというイベントは、当該案件についてのフラグ情報として別途保持することによりステータスとして把握するものとする（図中の各ステータスの網掛けで示す）。図３の例では、「審査中」（Ｓ０５ａ）のステータスにおいて公開公報が発行されると、「審査中」（Ｓ０５ｂ）のステータスにおいて“全（全員）”がアクセス可能となることを示している。

「審査中」（Ｓ０５ｂ）のステータスで、例えば、拒絶理由通知を受領すると、「中間対応」（Ｓ０６）のステータスに遷移し、その後拒絶査定等が確定すると「拒絶」（Ｓ０７）のステータスとなって管理の対象から除外される。「審査中」（Ｓ０５ｂ）もしくは「中間対応」（Ｓ０６）のステータスで特許査定を受けると、「登録」（Ｓ０８）のステータスとなる。その後の年金管理等については“発（発明者）”や“Ｂ（発明部門）”、“Ｃ（関連部門）”等は原則として関与しないため、“Ａ（知財部門）”および“代（代理人）”（特許事務所に出願手続を依頼していた場合）のみがアクセス可能であることを示している。その後、特許権等の存続期間の満了や年金の不納付等により特許権等が消滅すると、「満了」（Ｓ０９）のステータスとなって管理の対象から除外される。

このように、案件のステータスの変動をトラッキングし、ステータスに応じてアクセス可能なグループの設定を変更する、すなわち、図２に示したような案件とアクセス可能なグループとの対応関係の情報を、案件制御ＤＢ２３に案件のステータス毎に設定できるようにすることで、よりきめ細かく柔軟なアクセス制御を実現することができる。

ここで、案件の情報に対するアクセス制御、および情報の秘密管理の観点からは、知的財産権法における先願主義のもと、出願手続をすることにより出願日の利益を確保したこと、および、公開公報（もしくは登録公報）が発行されて発明等の内容が公知となったこと、の２つのイベントが大きな意味を有する。従って、本実施の形態では、少なくとも、“出願手続を行ったこと”（もしくは「出願済」（Ｓ０３）のステータスに遷移したこと）、および“公開公報（もしくは登録公報）が発行されたこと”の２つのイベントおよび状態について把握し、これに基づいて、案件にアクセス可能なグループの設定を変更する等の制御を行うものとする。

なお、図３に示した状態遷移はあくまで一例であり、少なくとも上記２つのイベントおよび状態について把握することが可能なものであれば、より詳細化／簡略化したり、他のステータスを管理したりなど、適宜変更することができる。

＜同一案件内での機能・操作に対するアクセス制御＞
図４は、同一の案件内において、知的財産情報管理システム１の管理機能群１２の各機能や操作に対するアクセス権限を設定する場合の例について概要を示した図である。本実施の形態では、上述したように、各案件について、さらにユーザの役割毎にアクセス可能な機能・操作やデータを設定することで、より柔軟できめ細かいアクセス制御を可能とする。当該設定は、例えば、図４に示すように、ユーザの役割（図中の各列）と機能・操作等（図中の各行）からなるマトリクスに対してアクセス権（図中の“○”印や“×”印）を設定する形で行われる。

各ユーザには、原則として１つ以上の何らかの役割が設定されるものとし、各機能・操作等に対してアクセス権を有する役割が割り当てられたユーザが、対象の機能・操作等にアクセスすることが可能となる。アクセス権を有さない機能・操作等については、画面上隠蔽して見せないようにしてもよいし、網掛けやグレーアウト、色分けなどにより利用できないことが認識できるように表示してもよい。

役割としては、例えば、“知財部管理職”や“年金担当”、“研究者”、“明細書作成担当”などの役割、ロールを設定することができる。このとき、可能な場合には、グループと同様に、企業３における人事情報データやユーザ管理データ等を取り込んで反映させることで、最新の役割の情報を反映させることができる。

上記の各役割について、機能・操作等毎にそれぞれ、情報の“Ｃ（作成：Create）”、“Ｒ（表示：Read）”、“Ｕ（更新：Update）”、“Ｄ（削除：Delete）”などの操作毎の権限を設定することができる。図４の例では、“○”印は許可、“ד印は権限なし、“−“印は権限の設定が不可であることをそれぞれ示している。このようなアクセス権の設定により、ある案件に対してアクセス可能なグループに属しているユーザ間であっても、その役割に応じてアクセスできる機能・操作等を詳細に制御することができる。例えば、特許事務所４の代理人を、独立したグループではなく企業３のユーザと同じグループに属するよう設定した場合であっても、代理人の役割を限定することで、担当外の公開前の情報を閲覧できないようにする、などのアクセス制御を行うことも可能である。

なお、役割毎にアクセスできる機能・操作等を各案件について個別に設定できるようにしてもよいが、図２に示したように、各案件にアクセスできるグループが設定されていることから、各ユーザが属するグループと割り当てられた役割の組み合わせを調整することにより、同様のアクセス制御を容易に実現することができる。また、このような役割に応じた機能・操作等のアクセス制御に加えて、例えば、上述したワークフロー機能においてトークンを保有しているユーザがアクセス可能な機能・操作等を独自に設定できるようにしてもよい。これにより、例えば、発明者は通常アクセスできないが、知財部門から問い合わせを受けて確認や判断を求められている場合にのみ、特定の操作ができるようアクセス制御することも可能である。

なお、本実施の形態では、図２に示した案件に対するグループ単位でのアクセス制御と、ユーザの役割による機能・操作等に対するアクセス制御とをＡＮＤ条件で判断することで、各案件における各ユーザの機能・操作等に対するアクセス制御を行っているが、これに限らず、ＯＲ条件やＮＯＴ条件も含めた組み合わせでアクセス制御を行うようにすることも可能である。例えば、対象の案件にアクセス可能なグループに属するか、特定の機能・操作等に対するアクセス権を有しているかのいずれかを満たせば、所定の条件で案件にアクセス可能とするようにしてもよい。また、特定のグループに属さないユーザについてのみアクセス可能な機能・操作等を利用させるというような制御も可能である。

＜ワークフローを用いた案件管理＞
図５は、本実施の形態の知的財産情報管理システム１のユーザインタフェース部１４により提供される案件の管理画面の例について概要を示した図である。ここでは、特定の案件についての詳細情報を表示する画面の例を示している。画面左部のパネルでは案件の基本情報を表示しており、右部のパネルでは案件の詳細情報をタブに区分して表示している。なお、対象のユーザがどの案件にアクセスすることができて、どの機能・操作を使用することができ、どのデータを参照することができるか、というアクセス制御については、上述した手法により、ユーザが属するグループや案件のステータス等によって決定される。

各案件に対して、１つ以上のワークフローを発生させることができ、対象のユーザに現在ステップが割り当てられているワークフローがある場合には、その情報が基本情報のパネルにリスト表示される（図５の例では“国内出願検討案件１”および“国内出願検討案件２”の２件）。

ここで、対象のワークフローが選択されると（図５の例では“国内出願検討案件１”）、例えば、ユーザインタフェース部１４により、当該ワークフローのステップにおいて当該ユーザが参照すべきパネルやタブ（図５の例では“発明情報”タブ）に表示を自動的に切り替え、入力すべき項目を強調表示し（図５の例では“受付日”、“外国出願検討”など）する。また、当該ステップでの操作等に対するナビゲーションメッセージ（図５の例では“入力エラーがあります。”等）を表示し、また、ワークフロー処理として次に採ることが可能なアクション（図５の例では画面下部のドロップダウンリストの“応答案検討依頼”）の内容を切り替える。当該ワークフローの全体の設定内容（以降の処理の流れや承認者、担当者等）を確認できるようにしてもよい。

このようなガイド機能により、例えば、発明部門など知的財産権に係る管理情報の詳細に精通していないユーザであっても、知的財産情報管理システム１にアクセスして自立的にワークフローのステップの処理を行うことが可能となる。

図６は、ワークフローのルート情報を設定する画面の例について概要を示した図である。ルートマスタの設定は、知的財産情報管理システム１を運営するサービス提供事業者もしくは契約によりサービスを利用している各企業の管理者や担当者が行う。ルートマスタでは、ルートの各ステップ（明細）において誰が（どのユーザが）どういう役割として担当するのかの割り当て情報を設定・定義する。このとき、例えば、ユーザＩＤ等により具体的なユーザを特定して割り当てることも可能であるが、案件毎に発明部門や関連部門は異なり得ることや、同じ案件内でも、知的財産の長いライフサイクルの間での組織変更や人事異動等により、担当者が代わることが多々ある。

従って、本実施の形態では、ステップを割り当てる担当者を変数（以下では“修飾語”と記載する場合がある）により設定し、ステップの実行時に動的に具体的な担当者に変換して割り当てるものとする。図６の例では、“ルート明細”の表中の“担当者”カラムにおいて、当該案件の知的財産部門の担当者を示す修飾語およびそのコード（変数）として、“案件知財担当者”および“＠ＣＨＩＺＡ”という文字列を設定している。

図７は、修飾語の内容を設定する画面の例について概要を示した図である。一覧表示されたルートマスタで用いられる修飾語のリストのうち、例えば、“案件知財担当者”（コードは“＠ＣＨＩＺＡ”）という修飾語について、修飾語を具体的な値に変換するための参照先のテーブルおよびカラムの情報（図７の例では“修飾語内容”）を１０種類定義していることを示している。ここでのテーブルは、例えば、人事関連の社内データベースなどが対象となる。１０種類の参照先の定義には優先度が設定されており、変換時には、優先度の高い順に各テーブルおよびカラムを順次参照し、最初に取得できた値によって修飾語を変換する。このように優先度によって複数の参照先を定義しておくことで、空白値に変換されてしまい担当者がいない、という事態を可能な限り防止することができる。

図８は、実行中のワークフローのルートを変更する画面の例について概要を示した図である。ここでは、上記の図６の例に示したルートマスタの設定において各ステップの担当者として設定した修飾語が、図７の例に示した修飾語の内容の設定に基づいて具体的なユーザの値に変換されている（図８の例では、修飾語コードの“＠ＣＨＩＺＡ”が本社の知財担当者の具体的なユーザを示す“＿ＨＯＴＡＮＴＯＵ”に変換されている）状態を示している。ここで、現在実行中もしくはこの先実行されるステップが割り当てられるグループや役割、担当者の情報を変更することができる。

図９は、修飾語マスタにおける修飾語の設定内容を変更する画面の例について概要を示した図である。ここでは、対象の修飾語を具体的な値に変換するために、図７の例に示した参照先のテーブルおよびカラムのリストのそれぞれについて、値を抽出して適用する条件式を図９に示す画面により予め設定しておくことができる。図９の例では、修飾語コードの“＠ＣＨＩＺＡ”について、図７の例における優先度が２の参照先（テーブルが“ＴＢＬ＿Ｂ”、カラムが“ＣＯＬ＿Ａ”）から値を抽出する条件式を指定している。これにより、対象のテーブルの対象のカラムから、条件式に合致する値を抽出して、これにより修飾語を変換することで、動的に具体的な担当者の値を設定することができる。

なお、上記のような修飾語の変換手法は、他のテーブルから間接的に値を取得して設定する点で“間接指定”とされるが、これに対して、修飾語に担当者となるユーザのＩＤ等を直接設定する“直接指定”とすることもできる。例えば、案件のライフサイクルによって各種の組織変更や人事異動などが生じる結果、担当者や承認者などは変わり得ても、知的財産の場合には“発明者”は人事異動等に関わらず不変である。ただ、“発明者”も人事異動等により所属組織は変わり得ることから、人事関連の社内データベースなどを参照する“間接指定”では適切に“発明者”を抽出できない場合が生じ得る。従って、“直接指定”によりユーザや部署を直接に指定する方法も設けている。

また、図示しないが、上記のような画面を介したワークフローの設定機能から、例えば、ワークフローの各ステップにおいて、処理の開始指示や次ステップへの依頼等の通知メールを送信する際の宛先についても、“直接指定”もしくは“間接指定”によりそれぞれ個別に指定することも可能である。

図１０は、案件の詳細画面からワークフローを開始する場合の例について概要を示した図である。図１０の例では、例えば、図５の例に示したような案件詳細画面において“案件Ａ”の情報が表示されており、そのステータスが“審査請求済”であった場合を示している。この状態で、新たに案件の管理業務に係るワークフローの開始を要求した場合、例えば、ワークフロー処理部１３がルートマスタＤＢ２８を参照し、ステータスが“審査請求済”の場合に開始可能なワークフローのルートマスタ（図１０の例では“中間処理”カテゴリのルートマスタ）を取得して、これを一覧表示する。

後述するように、ルートマスタＤＢ２８には、実行が可能な案件のステータスに応じてルートマスタの情報がカテゴリ分けされて登録されている。本実施の形態では、少なくとも、案件が出願前の場合に実行可能な出願処理に係る“出願”カテゴリ、出願審査請求前の場合に実行可能な出願審査請求処理に係る“審査請求”カテゴリ、拒絶理由通知や拒絶査定を受領している状態の場合に実行可能な中間処理に係る“中間処理”カテゴリ、および設定登録後の場合に実行可能な年金管理処理に係る“年金管理”カテゴリの４種類のカテゴリを有するものとする。これらのカテゴリに区分されるルートマスタは、主に、知的財産権の取得・維持手続における法定期限の管理に係るものである。

ユーザは、開始可能なワークフローとして表示されている“中間処理”カテゴリのルートマスタから、処理対象のルートマスタを選択して開始を指示することで、当該案件について当該ルートマスタに係るワークフローのインスタンス（以下ではこれを単に「ワークフロー」と記載する場合がある）を開始することができる。このように、予めカテゴリに分けて必要な処理に係るルートマスタを設定しておくことで、案件のステータスに応じて実行が可能もしくは必要なルートマスタのみをユーザに提示し、利便性を向上させることができる。

図１１は、ワークフローの選択画面からワークフローを開始する場合の例について概要を示した図である。図１１の例では、例えば、ユーザが図示しないメイン画面等からワークフローの開始を選択すると、ワークフロー処理部１３がルートマスタＤＢ２８を参照し、全てのルートマスタをカテゴリ別に一覧表示する。そこから、ユーザが開始したいワークフローに係るルートマスタを選択すると（図１１の例では“中間処理”カテゴリのルートマスタを選択）、当該ルートマスタに係るワークフローを開始することができるステータスを有する案件の情報を案件ＤＢ２７から抽出して（図１１の例ではステータスが“審査請求済”である“案件Ａ”〜“案件Ｄ”の４つ）、これらを一覧表示する。

ユーザは、この中から対象の案件を選択して（図１１の例では“案件Ｃ”）開始を指示することで、当該案件について当該ルートマスタに係るワークフローを開始することができる。このように、カテゴリ分けされたルートマスタの中から対象のルートマスタを先に選択し、ステータスが該当する案件についてワークフローを開始することも可能である。

図１２は、ルートマスタの階層構造の例について概要を示した図である。ワークフローの定義情報であるルートマスタは、階層構造を有する形でルートマスタＤＢ２８に登録される。ルートマスタは、知的財産情報管理システム１により提供されるＡＳＰサービスを契約している企業３毎に個別独自に設定・定義することが可能であるが、各企業３での設定・定義の負荷などを考慮して、ＡＳＰサービスを提供しているサービス提供事業者において雛形となるルートマスタを設定・定義しておくことが望ましい。

図１２の例では、サービス提供事業者は、複数のルートマスタの雛形（図中では“ルートマスタＡ”〜“ルートマスタＣ”の３つのみ示している）を設定・定義していることを示している。ここで、例えば、“契約企業１”は、サービス提供事業者が定義した“ルートマスタＡ”および“ルートマスタＢ”をベースに、これらをそれぞれ自社向けにカスタマイズして“ルートマスタＡ１”および“ルートマスタＢ１”を独自に定義していることを示している。“契約企業１”は、これらのルートマスタに基づいて、“ワークフローＡ１”や“ワークフローＡ２”を開始することができる。

同様に、“契約企業２”は、サービス提供事業者が定義した“ルートマスタＢ”をベースに、“契約企業１”とは異なる形で独自に自社向けにカスタマイズして“ルートマスタＢ２”を定義していることを示している。“契約企業２”は、このルートマスタに基づいて、“ワークフローＢ２”を開始することができる。なお、サービス提供事業者が定義したルートマスタは、必要に応じてカスタマイズ不可としてもよい。

また、“契約企業３”は、サービス提供事業者が定義した“ルートマスタＣ”をそのまま自社向けに用いることを示している。さらに、サービス提供事業者が定義したルートマスタの雛形をベースにせず、自社で新たに“ルートマスタＤ”を独自に定義していることを示している。“契約企業３”は、これらのルートマスタに基づいて、“ワークフローＣ”や“ワークフローＤ”を開始することができる。

このように、ルートマスタについては、階層構造を有する形で企業３毎に個別に設定・定義することが可能であるが、これに伴い、上述した修飾語のマスタ情報についても、企業３毎に個別独自に設定・定義することが可能である。

上述したように、企業３における複数の案件のそれぞれについて１つ以上のワークフローを実行することができるが、これらは、各ユーザや管理者等が自身のアクセス権限に応じて各種の条件で検索することができる。例えば、ワークフローの種別や、現状のステータス等を条件として検索することができる。また、ワークフローの情報と案件の情報とを組み合わせて検索することも可能である。例えば、案件の発明者と、当該案件に係るワークフローの承認者や知財担当者等との組み合わせなどにより、該当するワークフローを抽出することができる。

また、複数の案件に係る多数のワークフローを効率的に処理できるようにするため、同種のワークフローの複数のインスタンスについて、１つ以上の案件毎に“束”としてまとめ、これらに対するワークフローでの処理を一括的に行うようにすることも可能である。

図１３は、ワークフローを案件毎に束として管理する場合の例について概要を示した図である。図１３（ａ）は、ワークフローの例を視覚的に表現した図であり、役割が“事務“の担当者から開始して、役割が“特許担当”、“承認者”、“発明部門特許管理者”の各担当者の処理を経て“事務”の担当者でワークフローが終了することを示している。

図１３（ｂ）は、案件に係るワークフローを発生させる際に、複数の案件を含めて束を生成する場合の例を示している。ここでは、図１３（ａ）の例に示したワークフローについて、“事務”の担当者において案件を発生させる際に、７つの案件５１を含めることを示している。例えば、図１３（ａ）に示したような図等によってワークフローを視覚的に表示した設定画面において、案件を検索等して候補案件を抽出し、その中から管理者等が束に含める案件を選択することができる。

ここで、本実施の形態では、ワークフロー処理部１３は、複数の案件５１を束にまとめる際に、処理を担当する担当者が最も多くなるステップにおいて、担当者毎に１つの束を生成する。図１３（ｂ）の例では、担当者が最も多くなるのは、“発明部門特許管理者”が実施するステップであり、４人の担当者が処理を行う予定となっている。従って、ワークフロー処理部１３は、“発明部門特許管理者”の各担当者が処理を行う予定の各案件をそれぞれまとめて４つの束５０（図中の点線枠）を生成する。

なお、束５０の生成はワークフローを発生させる際に行う。生成された束５０に含まれる案件５１の数には特に制限はなく、また、担当者やステップによって束５０に含まれる案件５１の内訳が変わることはない。図１３（ｂ）の例では、“発明部門特許管理者”の各担当者が処理を行う予定の案件毎に４つの束５０が生成されるが、他の“事務”や“特許担当”などの担当者も、それぞれ束５０の単位で案件が割り当てられることになる。各担当者は、ワークフロー上において、束５０の単位で案件を処理することもでき、また、個別の案件毎に処理することもできる。

図１４は、束に係る案件のフロー制御の例について概要を説明する図である。ここでは、束５０に含まれる案件を個別に処理した結果、それぞれの進捗に差異が生じた場合に、担当者が処理すべき案件が全て揃う（処理可能となる）まで先に進めない（処理を行えない）ように制御する合流制御の例を示している。図中で、束の合流の制御を行った後のステップを行う“担当者Ａ”には、割り当てられた４つの案件のうち３つまでは現状で割り当てられているが、残り１つについては未だ“担当者Ｄ”に割り当てられている状態である。従って、“担当者Ａ”は当該ステップに係る処理を開始することができない。すなわち、“担当者Ｄ”が案件の処理を完了するのを待つことになる。

一方で、“担当者Ｂ”は、自身に割り当てられた案件１つが既に割り当てられているため、当該ステップに係る処理を開始することができる。なお、束５０の合流制御は、必要なステップにおいて適宜設定することができるものとする。

図１５は、束５０に案件５１を後から追加する場合の例について概要を示した図である。図１５（ａ）に示すように、束５０内の２つの案件５１が既に“担当者Ｂ”に割り当てられている状態で、新たに案件５１を追加すると、当該案件５１は、ワークフローの最初から行われる。すなわち、“担当者Ａ”に対して割り当てられる。このとき、上記の図１３（ｂ）の例において示した判定基準に基づいて、当該案件５１を既存の束５０に含めることができる場合は、当該束５０に含めて追加する。なお、束５０に対して案件５１を追加できるのに対応して、束５０から案件５１を分離・削除することも可能である。

一方、図１５（ｂ）に示すように、束の合流制御が設定されている場合において、案件５１の少なくとも一部が合流点より先のステップに進んでしまっている（先の担当者に割り当てられている）場合は、合流制御が複雑になってしまうことから、案件５１を新たに追加することはできないものとする。

図１６は、案件５１の担当者を変更した場合の束５０の制御の例について概要を示した図である。例えば、“担当者Ｂ”に割り当てられている束５０内の案件５１の１つにおいて、担当者が“担当者Ｂ”から“担当者Ｄ”に変更された場合、“担当者Ｂ”に割り当てられた当該案件５１は束５０から除外され、新たに“担当者Ｄ”に割り当てられた当該案件５１に基づいて束５０が生成される。このとき、新たに生成された束５０について、担当者が異なる新たなワークフローが生成される。

なお、例えば、承認者が変更された場合には、上記のように担当者が変更されたものとは取り扱わず、新たな束５０の生成を行わないよう制御してもよい。また、担当者の変更ではなく、業務（ステップ）をスキップするようにワークフローの設定を変更した場合も、担当者が変更されたものとは取り扱わず、新たな束５０の生成を行わないよう制御する。また、担当者の変更ではなく、代理者・代行者の設定を行えるようにしてもよい（同一人が複数の担当者の代理者・代行者となることも可能）が、このときも、新たな束５０の生成を行わないように制御する。

上記のように、同種のワークフローの複数のインスタンスについて、案件５１毎に束５０としてまとめて管理することで、例えば、これらに対するワークフローでの処理（例えば、担当者の変更など）を一括的に行うことが可能となり、管理を効率化することが可能となる。

＜データ構成＞
以下では、上述したようなアクセス制御やワークフロー管理を行うための各テーブルのデータ構成について説明する。

図１７は、ユーザＤＢ２１のデータ構成の例について概要を示した図である。ユーザＤＢ２１は、知的財産情報管理システム１により提供されるサービスを利用できる各ユーザのマスタ情報を保持するテーブルであり、例えば、図１７（ａ）に示すユーザマスタＤＢ２１ａ、図１７（ｂ）に示すユーザグループＤＢ２１ｂ、および図１７（ｃ）に示すユーザ役割ＤＢ２１ｃの各テーブルからなる。

図１７（ａ）のユーザマスタＤＢ２１ａは、ユーザのマスタ情報を保持するテーブルであり、例えば、ユーザＩＤ、契約ＩＤ、ユーザ名称、および連絡先などの各項目を有する。ユーザＩＤの項目は、各ユーザを一意に識別するためのＩＤ情報を保持する。上述したように、例えば、上位数桁を契約毎に割り当てられるコード値により固定することで、ユーザＩＤと契約の関係を把握し、対象の契約に係る案件以外は参照できないよう制御する。契約ＩＤの項目は、対象のユーザがサービスを利用する基礎となる契約を特定するＩＤ情報を保持する。当該ＩＤの情報は、後述する図２２の契約ＤＢ２６に定義されている。ユーザ名称および連絡先の各項目は、それぞれ、対象のユーザの氏名や名称等の情報、および電子メールアドレスや電話番号等の連絡先の情報を保持する。

図１７（ｂ）のユーザグループＤＢ２１ｂは、各ユーザが所属するグループの情報を保持するテーブルであり、例えば、ユーザＩＤ、所属グループＩＤ、所属開始、および所属終了の各項目を有する。ユーザＩＤの項目は、対象のユーザを特定するＩＤ情報を保持する。当該ＩＤ情報は、上記のユーザマスタＤＢ２１ａに定義されている。所属グループＩＤの項目は、対象のユーザが所属するグループを特定するＩＤ情報を保持する。当該ＩＤ情報は、後述する図１８のグループＤＢ２２に定義されている。所属開始および所属終了の各項目は、それぞれ、対象のユーザが対象のグループ（すなわち、組織や職位）に所属する始期および終期の情報を保持する。将来の所属グループを予め登録しておくことも可能である。なお、同一ユーザについてレコードを複数登録することで複数のグループに所属するよう設定することも可能である。

図１７（ｃ）のユーザ役割ＤＢ２１ｃは、各ユーザに割り当てられた役割の情報を保持するテーブルであり、例えば、ユーザＩＤ、割り当て役割ＩＤ、割り当て開始、および割り当て終了の各項目を有する。ユーザＩＤの項目は、対象のユーザを特定するＩＤ情報を保持する。当該ＩＤ情報は、上記のユーザマスタＤＢ２１ａに定義されている。割り当て役割ＩＤの項目は、対象のユーザに割り当てられた役割を特定するＩＤ情報を保持する。当該ＩＤ情報は、後述する図２０の役割ＤＢ２４に定義されている。割り当て開始および割り当て終了の各項目は、それぞれ、対象のユーザに対象の役割が割り当てられた始期および終期の情報を保持する。将来割り当てられる役割を予め登録しておくことも可能である。なお、同一ユーザについてレコードを複数登録することで複数の役割が割り当てられるよう設定することも可能である。

図１８は、グループＤＢ２２のデータ構成の例について概要を示した図である。グループＤＢ２２は、各グループのマスタ情報を保持するテーブルであり、例えば、グループＩＤ、グループ名、およびグループ区分などの各項目を有する。グループＩＤの項目は、対象のグループを一意に識別するためのＩＤ情報を保持する。グループ名の項目は、対象のグループの表示名の情報を保持する。グループ区分の項目は、対象のグループの区分を示すコード値等の情報を保持する。区分としては、例えば、対象のグループが組織に基づくグループであるのか、職位に基づくグループであるのか、などを識別する情報が含まれる。

図１９は、案件制御ＤＢ２３のデータ構成の例について概要を示した図である。案件制御ＤＢ２３は、案件とアクセス可能なグループとの対応関係の情報を保持するテーブルであり、例えば、案件ＩＤ、案件ステータス、アクセス可能者ＩＤ、およびグループ／ユーザ区分などの各項目を有する。

案件ＩＤの項目は、対象の案件を特定するＩＤ情報を保持する。当該ＩＤ情報は、後述する図２３の案件ＤＢ２７に定義されている。案件ステータスの項目は、対象の案件のステータスを区分するコード値等の情報を保持する。例えば、図３に示したような状態遷移における各ステータスを識別できるコード値を設定することができる。特許事務所４の代理人に依頼したというイベントや、公開公報が発行された等のイベントが発生したことをフラグとして別途保持するようにしてもよい。これにより、案件のステータスに応じてアクセス権の設定を変更することができる。

アクセス可能者ＩＤおよびグループ／ユーザ区分の項目は、それぞれ、対象の案件に対してアクセス権を有するグループもしくはユーザを特定するＩＤ情報、および当該ＩＤ情報の対象がグループかユーザかを区分するコード値等の情報を保持する。当該ＩＤ情報は、上記の図１８のグループＤＢ２２もしくは図１７のユーザＤＢ２１に定義されている。上述の図２に示したように、案件に対するアクセス権は、原則としてグループを単位として設定されるが、例外的に個別のユーザに対して直接設定することも可能である。

図２０は、役割ＤＢ２４のデータ構成の例について概要を示した図である。役割ＤＢ２４は、各ユーザに対して割り当てることができる役割のマスタ情報を保持するテーブルであり、例えば、役割ＩＤ、役割名、説明、およびランクなどの各項目を有する。役割ＩＤの項目は、各役割を一意に識別するためのＩＤ情報を保持する。役割名の項目は、対象の役割の表示名の情報を保持する。説明の項目は、対象の役割の意味や内容等について説明するテキスト等の情報を保持する。ランクの項目は、対象の役割に対して設定されるランクやレベルを示す情報を保持する。役割をランクによって区分し、例えば、ユーザのスキルレベル等に応じて該当するものを割り当てることによって、機能・操作に対するアクセス制御をより詳細に行うことも可能である。

図２１は、機能制御ＤＢ２５のデータ構成の例について概要を示した図である。機能制御ＤＢ２５は、知的財産情報管理システム１の管理機能群１２により提供される機能・操作とアクセス可能な役割との対応関係の情報を保持するテーブルであり、例えば、役割ＩＤ、および機能コードなどの各項目を有する。役割ＩＤの項目は、対象の役割を特定するＩＤ情報を保持する。機能コードの項目は、対象の役割が割り当てられたユーザがアクセス可能な機能・操作を識別するコード値等の情報を保持する。

図２２は、契約ＤＢ２６のデータ構成の例について概要を示した図である。契約ＤＢ２６は、知的財産情報管理システム１を運営してサービスを提供する事業者と各企業３との間でそれぞれ締結されているサービスの利用契約の情報を保持するテーブルであり、例えば、契約ＩＤ、顧客名、契約区分、ＵＲＬ、契約開始日、および契約終了日などの各項目を有する。

契約ＩＤの項目は、対象の契約を一意に識別するためのＩＤ情報を保持する。顧客名の項目は、事業者との間で対象の契約を締結した顧客（図１における企業３）の表示名の情報を保持する。契約区分の項目は、対象の契約の種類や区分を特定するためのコード値等の情報を保持する。サービスの提供内容、提供レベルやオプションなどにより契約の種別等が複数存在する場合に、これを特定するための区分情報である。ＵＲＬの項目は、対象の契約の顧客（企業３）に対して割り当てられた、知的財産情報管理システム１のユーザインタフェース部１４により提供されるアクセス用ポータル画面のＵＲＬの情報を保持する。契約開始日および契約終了日の各項目は、それぞれ、対象の契約の開始日および終了日の情報を保持する。

図２３は、案件ＤＢ２７のデータ構成の例について概要を示した図であり、例えば、図２３（ａ）に示す案件マスタＤＢ２７ａ、および図２３（ｂ）に示す案件ステータスＤＢ２７ｂの各テーブルからなる。

図２３（ａ）の案件マスタＤＢ２７ａは、知的財産情報管理システム１による管理対象となる案件のマスタ情報を保持するテーブルであり、例えば、案件ＩＤ、契約ＩＤ、案件管理者、出願番号、元案件ＩＤ、案件開始日、および案件終了日などの各項目を有する。案件ＩＤの項目は、対象の案件を一意に識別するためのＩＤ情報を保持する。契約ＩＤの項目は、対象の案件を保有し管理する企業３との間の契約を特定するＩＤ情報を保持する。案件管理者の項目は、対象の案件の管理者となる企業３の担当者を特定するＩＤ情報等を保持する。

出願番号の項目は、対象の案件に係る知的財産権について出願手続がされた場合に、その出願番号の情報を保持する。公開公報が発行された場合の公報の番号や、特許権の設定登録等がされた場合の登録番号などの情報を合わせて保持するようにしてもよい。元案件ＩＤの項目は、対象の案件に対して親子関係を有する親案件がある場合は、当該親案件を特定するＩＤ情報を保持する。例えば、分割出願や海外出願などに対して元の出願に係る案件を把握し、ファミリーの情報として管理するようにしてもよい。案件開始日および案件終了日の各項目は、それぞれ、対象の案件の開始日および終了日の情報を保持する。当該開始日と終了日により規定される期間外の場合は、対象の案件は管理の対象外となる。

図２３（ｂ）の案件ステータスＤＢ２７ｂは、各案件のステータスに係る情報を管理するテーブルであり、例えば、案件ＩＤ、および案件ステータスなどの各項目を有する。案件ＩＤの項目は、対象の案件を一意に特定するためのＩＤ情報を保持する。当該ＩＤ情報は上記の図２３（ａ）の案件マスタＤＢ２７ａに定義されている。案件ステータスの項目は、対象の案件のステータスを区分するコード値等の情報を保持する。上述したように、例えば、図３に示したような状態遷移における各ステータスを識別できるコード値を設定することができる。特許事務所４の代理人に依頼したというイベントや、公開公報が発行された等のイベントが発生したことをフラグとして別途保持するようにしてもよい。

図２４は、ルートマスタＤＢ２８のデータ構成の例について概要を示した図であり、例えば、図２４（ａ）に示すルートマスタ管理ＤＢ２８ａ、および図２４（ｂ）に示す修飾語マスタＤＢ２８ｂの各テーブルからなる。

図２４（ａ）のルートマスタ管理ＤＢ２８ａは、各企業３のユーザが案件に対して実行することができるワークフローに係るルートマスタの設定・定義情報を保持するテーブルであり、例えば、ルートマスタＩＤ、ルートカテゴリ、ルート名、契約ＩＤ、親ルートマスタＩＤ、ルート明細ＩＤ、グループ、役割、担当者、作業期日、初期表示画面、必須入力項目、ナビゲーションメッセージ、可能アクション、前ルート明細ＩＤ、および次ルート明細などの各項目を有する。

ルートマスタＩＤの項目は、対象のルートマスタを一意に識別するためのＩＤやシーケンス番号の情報を保持する。ルートカテゴリの項目は、対象のルートマスタが分類されるカテゴリを特定するためのコード値等の情報を保持する。カテゴリとしては、例えば、上述の図１０、図１１の例における“出願”、“審査請求”、“中間処理”、“年金管理”などが含まれる。ルート名の項目は、対象のルートマスタに係るルートの表示名称やタイトルの情報を保持する。

契約ＩＤの項目は、対象のルートマスタが企業３によりカスタマイズされて作成されたものである場合に、当該企業３を特定する情報として、当該企業３との間の契約を特定するＩＤ情報を保持する。また、親ルートマスタＩＤの項目は、対象のルートマスタが企業３によりカスタマイズされて作成されたものである場合に、そのベースとなった雛形のルートマスタを特定するＩＤ情報を保持する。従って、対象のルートマスタが知的財産情報管理システム１を運営するサービス提供事業者により定義された雛形である場合には、契約ＩＤおよび親ルートマスタＩＤの項目には値が設定されない、もしくは固有の特殊な値が設定される。

ルート明細ＩＤの項目は、対象のルートマスタにおける各ステップ（明細）を一意に識別するためのＩＤやシーケンス番号の情報を保持する。なお、ルート明細ＩＤ以降の各項目は、対象のルートマスタを構成するステップ毎にそれぞれ保持されるものである。別テーブルに保持されていてもよい。グループ、役割、担当者の各項目は、それぞれ、対象のステップが割り当てられるグループ、役割、担当者を指定する情報を保持する。ここでは、上述した修飾語を用いて変数として指定することができる。作業期日の項目は、対象のステップを実行するに際しての開始期限および完了期限の情報を保持する。

初期表示画面の項目は、対象のステップを実行するためにユーザが知的財産情報管理システム１にアクセスした際に、ユーザインタフェース部１４により表示させる初期画面もしくはパネル、タブなどを特定する情報を保持する。必須入力項目の項目は、対象のステップにおいて、ユーザが案件に係る情報として入力しなければならない必須項目を特定する情報を保持する。当該項目は、例えば、図５の例に示す画面において強調表示される。ナビゲーションメッセージの項目は、対象のステップにおける入力項目や処理内容などをガイドするナビゲーションメッセージの情報を保持する。当該メッセージは、例えば、図５の例に示す画面において表示される。

可能アクションの項目は、対象のステップにおいてユーザがワークフローの進行に係る処理として実行が可能なアクションを特定する情報を保持する。当該内容は、例えば、図５の例に示す画面において選択可能なように表示される。前ルート明細ＩＤおよび次ルート明細の各項目は、それぞれ、対象のステップの前に実行されるステップおよび対象のステップの次に実行されるステップを特定するＩＤ情報を保持する。この情報により、各ステップが連続するワークフローとして把握することができる。

図２４（ｂ）の修飾語マスタＤＢ２８ｂは、各企業３のユーザがルートマスタの設定・定義の際に用いることができる修飾語の設定・定義情報を保持するテーブルであり、例えば、修飾語ＩＤ、修飾語、修飾語区分、契約ＩＤ、参照先テーブル、参照先カラム、指定区分、および指定内容などの各項目を有する。

修飾語ＩＤの項目は、対象の修飾語を一意に識別するためのＩＤやシーケンス番号の情報を保持する。修飾語の項目は、対象の修飾語の表示名称の情報を保持する。修飾語区分の項目は、対象の修飾語の区分を特定するためのコード値等の情報を保持する。区分には、例えば、担当者を指定する修飾語か、部署を指定する修飾語かを分類する区分などが含まれる。契約ＩＤの項目は、対象の修飾語を設定・定義した企業３を特定する情報として、当該企業３との間の契約を特定するＩＤ情報を保持する。

参照先テーブルおよび参照先カラムの各項目は、それぞれ、対象の修飾語が間接指定である場合に、当該修飾語を変換するデータの参照先となるデータベースのテーブルおよびカラムを特定する情報を保持する。指定区分の項目は、対象の修飾語が直接指定か間接指定かを特定するためのコード値等の情報を保持する。指定内容の項目は、対象の修飾語を変換する内容や、変換の際の条件式の情報を保持する。例えば、対象の修飾語が直接指定の場合は、変換する値が直接指定され、間接指定の場合は、上記の参照先テーブルおよび参照先カラムについて、変換する値を抽出するレコードを特定するための条件式が指定される。

図２５は、ワークフローＤＢ２９のデータ構成の例について概要を示した図である。ワークフローＤＢ２９は、各企業３のユーザが案件に対して実行しているワークフローに係る実績情報を保持するテーブルであり、例えば、ワークフローＩＤ、ルートマスタＩＤ、契約ＩＤ、案件ＩＤ、束ＩＤ、ルート明細ＩＤ、最新・実績担当者、作業開始日、作業終了日、前ルート明細ＩＤ、および次ルート明細などの各項目を有する。

ワークフローＩＤの項目は、対象のワークフローを一意に識別するためのＩＤやシーケンス番号の情報を保持する。ルートマスタＩＤの項目は、対象のワークフローの元となったルートマスタを特定するＩＤ情報を保持する。契約ＩＤの項目は、対象のワークフローを実行している企業３を特定する情報として、当該企業３との間の契約を特定するＩＤ情報を保持する。

案件ＩＤの項目は、対象のワークフローに対応する案件を特定するＩＤ情報を保持する。これにより、ワークフローと案件とが関連付けられ、上述したように、ワークフローの情報と案件の情報との組み合わせにより検索を行うことが可能となる。束ＩＤの項目は、対象のワークフローが含まれる束がある場合に、これを特定するＩＤやシーケンス番号の情報を保持する。これらの情報により、上述したように、ワークフローに係る案件を束により処理し管理することが可能となる。

ルート明細ＩＤの項目は、対象のワークフローにおいて実行中もしくは実行済みのステップ（明細）を特定するＩＤ等の情報を保持する。なお、ルート明細ＩＤ以降の各項目は、対象のワークフローにおいて実行中もしくは実行済みのステップ毎にそれぞれ実績情報、履歴情報として保持されるものである。別テーブルに保持されていてもよい。最新・実績担当者の項目は、対象のステップにおいてルートマスタ上設定されていた修飾語が実際に変換されて実際の担当者等に割り当てられた際の当該担当者等を特定するためのＩＤ等の情報を保持する。作業開始日および作業終了日の各項目は、それぞれ、対象のステップの実際の開始日および終了日の情報を保持する。前ルート明細ＩＤおよび次ルート明細の各項目は、それぞれ、対象のステップの前に実行されたステップおよび対象のステップの次に実行されるステップを特定するＩＤ情報を保持する。

なお、上述の図１７〜図２５で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。

以上に説明したように、本発明の一実施の形態である知的財産情報管理システムによれば、創出された発明等の知的財産について、そのライフサイクルにわたって案件としてステータスや情報の管理を行うための機能やサービスを提供することができる。例えば、知的財産情報管理システムは、ＩＴベンダー等の事業者により運営され、ＡＳＰとして複数の企業が契約に基づいて共同利用する形で利用者にネットワークを介してサービスを提供するよう実装される。従って、契約が異なる企業等のユーザ間で案件に係る情報が共有されないようアクセス制御することができる。

また、例えば、企業等がこれらのユーザについて１つ以上のグループを構成し、案件毎にアクセス可能なグループを設定することで、そのライフサイクルにわたって案件の特性やステータス等に応じたアクセス制御が可能となる。さらに、各案件について、ユーザの役割毎にアクセス可能な機能・操作を設定することで、機能・操作単位でのより柔軟できめ細かいアクセス制御が可能となる。

また、代理人を１つのユーザとして管理し、代理人や特許事務所の事務員等からなる外部の関与者のグループを作成するか、代理人に対して所定の役割を設定することで、代理人も企業のユーザと同様に扱うことができる。これにより、企業としては、代理人や特許事務所が複数ある場合や、逆に、代理人が不在・未定もしくは依頼前や出願前の状態であっても適切に案件の情報を管理してアクセス制御を行うことができる。

さらに、本発明の一実施の形態である知的財産情報管理システムによれば、知的財産に係る案件についての管理業務を対象として、１案件のライフサイクルが数年〜十数年という長いものとなり得るなどの知的財産管理の特性を考慮しつつ、ユーザ企業間でのアクセス制御がされている状態で、それぞれの企業が企業毎の実情に応じた形で独自にワークフロー化することが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

本発明は、発明等の案件に係る各種業務をワークフロー処理によって管理する知的財産情報管理システムに利用可能である。

１…知的財産情報管理システム、２…ネットワーク、３…企業、４…特許事務所、
１１…アクセス制御部、１２…管理機能群、１３…ワークフロー処理部、１４…ユーザインタフェース部、
２１…ユーザデータベース（ＤＢ）、２１ａ…ユーザマスタＤＢ、２１ｂ…ユーザグループＤＢ、２１ｃ…ユーザ役割ＤＢ、２２…グループＤＢ、２３…案件制御ＤＢ、２４…役割ＤＢ、２５…機能制御ＤＢ、２６…契約ＤＢ、２７…案件ＤＢ、２７ａ…案件マスタＤＢ、２７ｂ…案件ステータスＤＢ、２８…ルートマスタＤＢ、２８ａ…ルートマスタ管理ＤＢ、２８ｂ…修飾語マスタＤＢ、２９…ワークフローＤＢ、
３１…企業端末、４１…事務所端末、
５０…束、５１…案件。

Claims (9)

1. 複数のユーザを有する複数の組織体に対し、前記各組織体がそれぞれ独立した形で共同利用可能なように、前記組織体毎にそれぞれ個別に知的財産管理サービスを提供するサービス提供事業者により管理され、ネットワークを介して前記各組織体に属するユーザが使用するユーザ端末からアクセスされることにより前記知的財産管理サービスを提供する知的財産情報管理システムであって、
   複数の前記各組織体がそれぞれ保有する知的財産に係る１つ以上の案件の情報を保持する案件情報保持部と、
   知的財産権の取得手続における法定期限管理に係るワークフローの定義情報であるルートマスタの情報を保持するルートマスタ情報保持部と、
   前記ルートマスタの定義内容に基づいて複数の前記組織体毎にそれぞれの前記各案件についての管理業務をワークフローにより個別に制御するワークフロー処理部と、
   前記各ワークフローに係る実績情報を保持するワークフロー情報保持部と、を有し、
   前記ルートマスタ情報保持部に保持されている前記ルートマスタは、前記サービス提供事業者により定義された、複数の前記各組織体に共通の１つ以上の第１のルートマスタと、前記第１のルートマスタを複数の前記組織体毎に個別にカスタマイズすることにより複数の前記組織体毎に作成されたルートマスタであって、前記組織体毎の個別のカスタマイズを行う権限を有するユーザが使用する前記ユーザ端末からの指示により作成された１つ以上の第２のルートマスタと、を含む階層構造を有する、知的財産情報管理システム。
2. 請求項１に記載の知的財産情報管理システムにおいて、
   前記各組織体をサービス提供の単位として、前記サービス提供事業者と前記各組織体との契約に基づいて、前記組織体毎に個別に知的財産管理サービスを提供する、知的財産情報管理システム。
3. 請求項１または２に記載の知的財産情報管理システムにおいて、
   前記ルートマスタは、少なくとも、知的財産権の出願処理に係るもの、出願審査請求処理に係るもの、中間処理に係るもの、および年金管理処理に係るもの、をそれぞれ有する、知的財産情報管理システム。
4. 請求項１〜３のいずれか１項に記載の知的財産情報管理システムにおいて、
   さらに、１つ以上の修飾語および当該修飾語を担当者の情報に変換するための条件の情報を保持する修飾語マスタ保持部を有し、
   前記ルートマスタは、当該ルートマスタに含まれる各ステップの実行を割り当てる担当者について、前記修飾語により指定されており、
   前記ワークフロー処理部は、前記ルートマスタに基づいて実行されている前記ワークフローにおける各ステップの実行を、対応する前記ルートマスタにおいて指定されている前記修飾語を前記条件に従って変換して得られる担当者に対して割り当てる、知的財産情報管理システム。
5. 請求項１〜４のいずれか１項に記載の知的財産情報管理システムにおいて、
   前記ルートマスタにおいて、当該ルートマスタに含まれる各ステップの実行を割り当てる担当者のうち、前記知的財産に係る発明者については、当該発明者を特定する情報により直接指定されている、知的財産情報管理システム。
6. 請求項１〜５のいずれか１項に記載の知的財産情報管理システムにおいて、
   同一の前記ルートマスタに基づいて個別に実行されている前記ワークフローに係る前記案件を１つ以上まとめた束の情報を保持し、
   ユーザからの指示に基づいて、前記束の単位で前記案件の情報を一括して設定もしくは変更することが可能である、知的財産情報管理システム。
7. 請求項６に記載の知的財産情報管理システムにおいて、
   前記束には、前記束に含まれるいずれかの前記案件に係る前記ワークフローが開始した後にも、他の前記案件を追加し、もしくは前記束に含まれるいずれかの前記案件を分離することが可能である、知的財産情報管理システム。
8. 請求項６に記載の知的財産情報管理システムにおいて、
   前記ワークフロー処理部は、前記ワークフロー内の所定のステップについて、当該ステップにおいて処理すべき前記束に含まれる前記案件の全てが、当該ステップを実行する担当者に割り当てられて処理可能となるまで、当該担当者が当該ステップの処理を行えないよう制御する、知的財産情報管理システム。
9. 請求項１〜８のいずれか１項に記載の知的財産情報管理システムにおいて、
   前記各ワークフローと前記案件との関連付けに係る情報を保持し、
   ユーザにより指定された前記ワークフローに係る情報と前記案件に係る情報とに基づいて、前記案件を検索することが可能な、知的財産情報管理システム。