(57)【要約】      （修正有）【課題】電子データのステータス、種別、関係者の種別によりメールによる通知を行うか否かの判定を行い、通知する場合は複数の内容から適切な通知内容を選択する仕組みを提供する。【解決手段】電子データ記憶手段に登録された電子データのステータスと関係者データベースと通知メール情報データベースとに基づいて関係者にメールによる通知を行う電子データ管理サーバであって、前記ステータスを条件として検索する通知メール情報データベース検索手段と、前記関係者データベースに基づいて関係者種別を取得する関係者種別取得手段と、前記検索した通知メール情報に含まれる通知内容に基づいて通知メールを生成する通知メール生成手段と、前記関係者に対して通知をするか否かを判定する通知判定手段と、前記通知判定手段により通知するとされた関係者に生成された前記通知メールを配信する通知メール配信手段と、を有する。【選択図】図１１
2012118702.tif 000002
【特許請求の範囲】
【請求項１】
電子データ記憶手段に登録された電子データのステータスと、前記電子データの関係者を登録する関係者データベースと、通知する内容および通知先となる関係者種別の情報を管理する通知メール情報データベースと、に基づいて関係者にメールによる通知を行う電子データ管理サーバであって、
前記電子データのステータスを条件として通知メール情報データベースを検索する通知メール情報データベース検索手段と、
前記関係者データベースに基づいて関係者種別を取得する関係者種別取得手段と、
前記通知メール情報データベース検索手段により検索した通知メール情報に含まれる通知内容に基づいて、通知メールを生成する通知メール生成手段と、
前記電子データの関係者に対して、前記関係者種別取得手段により取得された関係者種別と、通知メール情報に含まれる関係者種別と、に基づき通知をするか否かを判定する通知判定手段と、
前記通知判定手段により通知するとされた関係者に、生成された前記通知メールを配信する通知メール配信手段と、
を有することを特徴とする電子データ管理サーバ。
【請求項２】
前記電子データ記憶手段に新たに電子データを登録する電子データ登録手段を更に備え、
前記関係者種別には社外関係者を含み、
前記電子データ登録手段で登録される新たな電子データに含まれる関係者の所属情報に基づき、前記関係者が社外関係者か否か判定する社外関係者判定手段と、
前記関係者が社外関係者である場合に、社外関係者としての情報を社外関係者データベースに格納するための社外関係者データベース登録手段と、
を有することを特徴とする請求項１に記載の電子データ管理サーバ。
【請求項３】
前記電子データの要素にはデータの内容を表すデータ種別を含み、
前記通知メール情報データベース検索手段の検索条件には、前記データ種別をも指定することを特徴とする請求項１または請求項２に記載の電子データ管理サーバ。
【請求項４】
前記電子データ記憶手段の管理者が、少なくともステータスによる前記電子データ記憶手段の検索条件を指定する電子データ検索条件指定手段と、
前記検索条件に基づき電子データ記憶手段を検索する電子データ検索手段と、
前記電子データ検索手段による検索結果を一覧する電子データ検索結果表示手段と、
前記検索結果のうち、指定した電子データの詳細を表示、修正、電子データ記憶手段への更新をする電子データ詳細内容表示手段と、
を有することを特徴とする請求項１乃至請求項３のいずれか１項に記載の電子データ管理サーバ。
【請求項５】
前記電子データ記憶手段の管理者が、少なくともステータスによる前記電子データ記憶手段の検索条件を指定する電子データ検索条件指定手段と、
前記検索条件に基づき電子データ記憶手段を検索する電子データ検索手段と、
前記検索条件により前記電子データ検索手段を、指定の時刻あるいは一定期間毎に実行し、前記通知メールを配信する自動通知手段と、
を有することを特徴とする請求項１乃至請求項３のいずれか１項に記載の電子データ管理サーバ。
【請求項６】
電子データ記憶手段に登録された電子データのステータスと、前記電子データの関係者を登録する関係者データベースと、通知する内容および通知先となる関係者種別の情報を管理する通知メール情報データベースと、に基づいて関係者にメールによる通知を行う電子データ管理方法であって、
通知メール情報データベース検索手段が、前記電子データのステータスを条件として通知メール情報データベースを検索する通知メール情報データベース検索工程と、
関係者種別取得手段が、前記関係者データベースに基づいて関係者種別を取得する関係者種別取得工程と、
前記通知メール情報データベース検索工程により検索した通知メール情報に含まれる通知内容に基づいて、通知メール生成手段が、通知メールを生成する通知メール生成工程と、
前記電子データの関係者に対して、前記関係者種別取得工程により取得された関係者種別と、通知メール情報に含まれる関係者種別と、に基づき通知判定手段が、通知をするか否かを判定する通知判定工程と、
通知メール配信手段が、前記通知判定工程により通知するとされた関係者に、生成された前記通知メールを配信する通知メール配信工程と、
を有することを特徴とする電子データ管理方法。
【請求項７】
請求項６に記載された電子データ管理方法を実行するためのプログラム。
【請求項８】
請求項６に記載された電子データ管理方法を実行するためのプログラムをコンピュータが読み取り可能に記憶した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理される電子データのステータスによって、該電子データの関係者にメール通知を行う電子データ管理システムに関する。
【背景技術】
【０００２】
従来、電子文書管理システムやワークフローシステムにおいて、ある条件を満たすデータの関係者に通知メールを送信する作業があるが、この作業は膨大な場合もあり、ミスの防止や効率化のため、作業担当者に対する様々な支援技術が提供されている。
【０００３】
特許文献１では、特許出願書類を管理する文書管理システムにおいて、出願審査の請求をすることができる最終期限よりも前の一定期間に、発明者に対して、当該発明について出願審査の請求を要望するかどうか確認する技術を提供している。確認は一定期間毎にまとめてメールで行うため、大量のメール送信が必要だが、特許出願書類を管理する文書管理システムに記録された発明者情報と、人事マスタを連携させて自動化し、省力化している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１０８７２１号広報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１では、出願審査の請求について発明者に確認をする際に、発明者が退職者や休職者である場合にはメールを送信しないように制御している。
【０００６】
しかしながら、一般的に電子データ管理システムにおいて、電子データのステータスには様々なものがあり、各ステータスに従って、その関係者が例え在職する社員ではなくても通知が必要な場合がある。さらに、通知するか否かの判定条件はステータスにより異なり、通知する場合であっても通知内容も一意的なものではなく、ステータスが異なれば内容も異なり、特許文献１における発明では、前述の状況には対応できないという問題点があった。
【０００７】
本発明は、上記の問題点を解決するためになされたものであり、電子データのステータス、種別、関係者の種別により、メールによる通知を行うか否かの判定を関係者毎に行い、通知する場合、複数の内容から適切な通知内容を選択する仕組みを提供することを課題とする。
【課題を解決するための手段】
【０００８】
本発明は、電子データ記憶手段に登録された電子データのステータスと、前記電子データの関係者を登録する関係者データベースと、通知する内容および通知先となる関係者種別の情報を管理する通知メール情報データベースと、に基づいて関係者にメールによる通知を行う電子データ管理サーバであって、前記電子データのステータスを条件として通知メール情報データベースを検索する通知メール情報データベース検索手段と、前記関係者データベースに基づいて関係者種別を取得する関係者種別取得手段と、前記通知メール情報データベース検索手段により検索した通知メール情報に含まれる通知内容に基づいて、通知メールを生成する通知メール生成手段と、前記電子データの関係者に対して、前記関係者種別取得手段により取得された関係者種別と、通知メール情報に含まれる関係者種別と、に基づき通知をするか否かを判定する通知判定手段と、前記通知判定手段により通知するとされた関係者に、生成された前記通知メールを配信する通知メール配信手段と、を有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、電子データのステータス、種類、関係者を条件として、メールによる通知を行うか否かの判定を行い、通知する場合には複数の内容から適切な通知内容を選択することで、状況に応じて、適切な関係者に適切な内容のメールを送信することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態に関わる電子データ管理サーバ、人事ＤＢサーバ、電子データ管理者クライアントＰＣ、データ関係者クライアントＰＣのシステム構成の一例を示す図である。
【図２】電子データ管理サーバ、人事ＤＢサーバ、電子データ管理者クライアントＰＣ、データ関係者クライアントＰＣの各ハード構成の一例を示すブロック図である。
【図３】電子データ管理サーバの機能ブロックの一例を示す図である。
【図４】電子データ記憶手段のデータ構造の一例を示す図である。
【図５】電子データ記憶手段に登録されている１つの電子データと該データの関係者のうち社員（退職者等含む）を関連付けるデータベースの一例を示す図である。
【図６】社外関係者を管理するデータベースのデータ構造の一例を示す図である。
【図７】電子データ記憶手段に登録されている１つの電子データと該データの社外関係者を関連付けるデータベースの一例を示す図である。
【図８】通知メールに関する情報を管理するデータベースのデータ構造の一例を示す図である。
【図９】人事データベースのデータ構造の一例を示す図である。
【図１０】電子データの登録処理を説明するフローチャートの一例である。
【図１１】電子データの関係者に通知メールを送信する処理を説明するフローチャートの一例である。
【図１２】通知対象とする電子データを検索し、一覧表示するＧＵＩの一例を示す図である。
【図１３】電子データの登録時、編集時のＧＵＩの一例を示す図である。
【図１４】通知メールの一例である。
【図１５】通知メールの一例である。
【図１６】通知メールの一例である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態を、図面を参照して詳細に説明する。
【００１２】
図１は、本発明の実施形態に関わる電子データ管理サーバ、人事ＤＢサーバ、電子データ管理者クライアントＰＣ、データ関係者サーバＰＣのシステム構成の一例を示す図である。電子データ管理サーバ１０１、人事データサーバ１０２（人事ＤＢサーバ）、電子データ管理者クライアントＰＣ１０３、データ関係者クライアントＰＣ１０４は、ネットワーク１０５を介して相互に接続される。
【００１３】
図２は、電子データ管理サーバ、人事ＤＢサーバ、電子データ管理者クライアントＰＣ、データ関係者クライアントＰＣの各ハード構成の一例を示すブロック図である。ＣＲＴ２０１と、入力デバイス２０２と、ＣＰＵ２０３と、ＲＡＭ２０４と、ＲＯＭ２０５と、外部記憶装置２０６と、ネットワーク・インタフェース２０７とを備える。
【００１４】
ＣＰＵ２０３は、ＲＯＭ２０５に記憶された制御プログラムを読み出して実行すると共に、情報処理装置を制御する。ＲＡＭ２０４は、データ等を一時記憶するためのバッファやワークエリア等として機能し、またＯＳを含む各種プログラムを実行する作業領域として使用される。
【００１５】
外部記憶装置２０６はハードディスクドライブ等の記憶装置であり、ＯＳやファイル管理システムのプログラムを含む各種プログラム及び各種データの短期的、永続的な記憶装置として使用される。
【００１６】
入力デバイス２０２は、キーボード、マウス等に代表されるユーザ入力機器であり、ＣＲＴ２０１は情報処理装置の処理結果等を表示するための機器である。バス２０８は、上述した各部を互いに接続するシステムバスである。なお、電子データ管理サーバ１０１、人事データサーバ１０２においては、ＣＲＴ２０１および入力デバイス２０２は、必須なものではない。
【００１７】
図３は、電子データ管理サーバの機能ブロックの一例を示す図である。３０１〜３０９は、電子データ管理サーバの中心となる機能であり、電子データを管理する機能群と他の機能を管理する機能群からなる。
【００１８】
電子データを管理する機能群の詳細としては、電子データを記憶する電子データ記憶手段３２３（図４に対応）に電子データを登録する電子データ登録手段３０１、電子データ記憶手段３２３の電子データを更新する電子データ更新手段３０２、電子データ記憶手段３２３から電子データを検索するための条件を指定する電子データ検索条件指定手段３０３（詳細は図１２の検索条件指定部分）、前記条件を元に電子データを検索する電子データ検索手段３０４、前記検索結果である電子データを表示する電子データ検索結果表示手段３０５、登録時や前記検索結果の中の１電子データを詳細に表示する電子データ詳細内容表示手段３０６（詳細は図１３。図１３では更新も可能）である。
【００１９】
他の機能を管理する機能群の詳細としては、後述する通知メールＤＢ管理と連携して、電子データの関係者にメールによる通知を行う自動通知手段３０７、人事ＤＢや社外関係者ＤＢ（社外関係者データベース）と関連する機能と連携して、電子データの関係者の種別を取得する関係者種別取得手段３０８や関係者の種別を判定する関係者種別判定手段３０９がある。ここで、本明細書の例としては、関係者として社員（在職者、退職者、休職者など）および社外関係者という種別にて説明を行うが、実際には社員の役職や所属組織、また社外関係者であっても例えばグループ会社の社員と、取引先の関係者など自由に構成して良い。その場合、関係者種別取得手段３０８および関係者種別判定手段３０９は、後述する社外関係者や人事ＤＢに所属する社員の種類に柔軟に対応するため、外部プログラムと連携したり、外部設定ファイルにより関係者の種類を変更できるようにしたりといった構成であっても良い。あくまで本構成は例の１つに過ぎない。
【００２０】
次に電子データ関係者ＤＢ管理について説明する。電子データ関係者ＤＢ３２４（図５に対応）により、電子データ記憶手段３２３で管理されている電子データと、各電子データの関係者のうち社員（在職者、退職者、休職者など）が関係づけて記憶されている。電子データ関係者ＤＢ登録手段３１０は、電子データが電子データ記憶手段３２３に登録される際に、関係者のうち社員（在職者、退職者、休職者など）を電子データ関係者ＤＢ３２４に登録する。一方、電子データ関係者ＤＢ検索手段３１１は、電子データ記憶手段３２３に登録された電子データが参照される際に、関係者のうち社員（在職者、退職者、休職者など）を電子データ関係者ＤＢ３２４から取得する。
【００２１】
次に社外関係者ＤＢ管理について説明する。社外関係者ＤＢ３２５（図６に対応）は、電子データ記憶手段３２３に登録される関係者について、社外関係者であると判定された場合に、社員が人事ＤＢで管理される代替として、登録し管理するデータベースである。まず、社外関係者であるかどうかを社外関係者判定手段３１２により判定し、社外関係者である場合には社外関係者ＤＢ登録手段（社外関係者データベース登録手段）３１３により社外関係者ＤＢ３２５に登録する。ここで社外関係者であるかどうかは、例えば電子データに記載されている企業名などにより判定することができるが、これはあくまで一例であり、もともと電子データに社外関係者であることを明示的に記載しておいても良い。一方、社外関係者ＤＢ検索手段３１４は、電子データ記憶手段３２３に登録された電子データが参照される際に、関係者のうち社外関係者を社外関係者ＤＢ３２５から取得する。
【００２２】
次に電子データ社外関係者ＤＢ管理について説明する。電子データ社外関係者ＤＢ３２６（図７に対応）により、電子データ記憶手段３２３で管理されている電子データと、各電子データの関係者のうち社外関係者が関係づけて記憶されている。電子データ社外関係者ＤＢ登録手段３１５は、電子データが電子データ記憶手段３２３に登録される際に、関係者のうち社外関係者を電子データ社外関係者ＤＢ３２６に登録する。一方、電子データ社外関係者ＤＢ検索手段３１６は、電子データ記憶手段３２３に登録された電子データが参照される際に、関係者のうち社外関係者を電子データ社外関係者ＤＢ３２６から取得する。
【００２３】
なお、社員を管理するための電子データ関係者ＤＢおよび人事ＤＢと、社外関係者を管理する電子データ社外関係者ＤＢおよび社外関係者ＤＢと分けた構成は、詳細説明を行うための便宜上のものであり、実際には統合した関係者ＤＢ（関係者データベース）であってもよく、内部的に社員と社外関係者の区別がつくものであればよい。更に前述の通り、本願発明の詳細説明における関係者の分類はあくまで一例であり、如何なる分類であっても同様の処理を実現してもよい。
【００２４】
次に通知メール情報ＤＢ（通知メール情報データベース）管理について説明する。通知メール情報ＤＢ３２７（図８に対応）により、如何なる条件の下に、関係者のうちの誰に、どのようなメールが配信されるかが決定する。通知メール情報ＤＢ検索手段３１７は、特定の条件の下で通知するメールに関する情報を通知メール情報ＤＢ３２７から検索する。通知判定手段３１８は、メール通知時に指定された条件の下、通知する関係者と通知しない関係者を関係者の種別により判定する。通知判定手段３１８は、前述の社外関係者判定手段３１２や後述する退職者等判定手段３２２と連携しても良い。通知メール生成手段３１９は、通知するメールの見出しや本文を生成し、通知メール配信手段３２０は、通知判定手段３１８により通知すると判定された関係者に、実際にメールを配信する。
【００２５】
次に、人事ＤＢ管理について説明する。人事ＤＢ３２８（図９に対応）は、例えば人事部が管理する人事情報が格納されたデータベースである。人事ＤＢ検索手段は、社員の個人ＩＤなどをキーとして人事ＤＢ３２８から、対応する社員（在職者、退職者、休職者など）を検索する。また、退職者等判定手段３２２は、社員のうち、在職者と既に退職した社員、あるいは休職者など、本願発明で使用する社員の種別を判定する。
【００２６】
以上、管理を６つのカテゴリに区分して説明してきたが、本説明及び図３の区分は、あくまで便宜上のものであり、機能がこれらの記述に従ってグループとして管理される必要はない。またデータベースは５つ（人事ＤＢも含めると６つ）に分割されているが、これは説明の便宜上のものであり、実際の構成は必ずしも５つ（あるいは６つ）である必要性はなく、自由である。更に人事ＤＢは、本願発明の詳細説明においては、人事部が管理しているサーバにアクセスするように構成しているが、例えば随時、前記人事部のサーバからデータをダウンロードし、本願発明のサーバ内で管理しても良い。
【００２７】
図４〜図９は、各種情報を管理するデータベースである。データベースとは便宜上の表現であり、１つのデータベースの異なるテーブルとして実現しても良いし、またいわゆるＲＤＢなどの使用を必要とするものではない。
【００２８】
図４は、電子データ記憶手段のデータ構造の一例を示す図である。すなわち本願発明で中心的な電子データを管理するためのデータベースである。ここで電子データとは、構造化されたドキュメントを指しているが、もとの入力データは非構造化文書ファイルなどであっても自動的に情報を抽出し、抽出できない項目の情報は必要に応じて人手により追加、修正して整備した電子データ化したもの、ワークフローの帳票データようにＰＣ上から起票されるため、実質的に前述のように当初から構造化されたものなど任意である。
【００２９】
電子データ記憶手段には、文書の種類毎に異なるテーブルを持つ構成として、例えばテーブル４０１は特許出願した電子データ専用としてもよいし、テーブル４０２のように様々なデータを同一テーブルに格納し、アプリケーション側で使い分けるようにしても良い。
【００３０】
本願発明では、図４のテーブル４０１を用いて、特許出願したデータを管理することを例として説明をすすめる。例えば特許庁の提出形式のデータである特許出願の書類は、データの構造化がされているため、後述する図１３のようなＧＵＩ上に表示可能である。誤りがあっても訂正し、電子データで登録しても良い。
【００３１】
データＩＤ４０３には、各電子データにユニークに付与されたＩＤである。
【００３２】
データ種別４０４には、電子データの種別を表している。テーブル４０１は、特許出願した電子データ専用であるので、全て“Ａ０１：特許”と記載されている。
【００３３】
ステータス４０５には、管理者の立場から見た電子データの位置づけが記載される。特許出願データの例であれば、知財担当者が出願手続きを完了したことを示す“出願完了”、審査請求をするかどうか判断中であることを示す“審査請求確認”、登録査定がなされ登録が完了したことを示す“登録”などが考えられる。
【００３４】
前ステータス４０６は、ステータスが変化する場合に前のステータスを記載するものであり、またステータスが変更された日時は、ステータス更新日４０７に記載されている。例えばデータＩＤ“１０００−０００３”は、「“２０１０年１１月３０日”に“明細書作成中”であった発明が“出願完了”となった」ことを表している。
【００３５】
発明の名称４０８には出願した発明の名称が、要約４０９には要約、請求の範囲４１０には特許請求の範囲、出願日４１１には出願日が記載されている。
【００３６】
以上が、電子データを管理する電子データ記憶手段の、構造の一例である。実際には、１レコード（テーブル４０１の１行）に、出願人に関する情報、特許出願の番号など特許出願した際のデータの他の全ての要素が格納されてもよいし、「明細書」など長文となる部分はファイルに格納され、そのファイルを参照する項目があってもよい。また、本発明の例として示す図５〜図７のように発明者については、別途管理してもよい。すなわち前述したとおり、テーブル４０１における出願特許データの管理はあくまで一例に過ぎない。
【００３７】
図５〜図９の概略は、前述の図３の中で記載しているので、詳細は、図１０以降の動作に基づいて説明していく。
【００３８】
図１０は電子データの登録処理を説明するフローチャートの一例である。
【００３９】
ステップＳ１００１では、電子データの元となるデータを取得する。例えば特許庁提出形式のデータを指定のファイルサーバ上のフォルダに格納し、一定期間毎に読み込む、あるいは１件ごとに人手による操作により、本登録処理の入力とする、などがある。
【００４０】
ステップＳ１００２では、ステップＳ１００１で取得したデータから、電子データとして必要な項目、すなわち本例では、図４のテーブル４０１における発明の名称４０８、要約４０９、請求の範囲４１０、出願日４１１、当電子データの関係者、すなわち発明者となる社員や社外関係者（共同発明者となる他社の社員）、関係者の所属する企業名、企業の居所などを抽出する。
【００４１】
ステップＳ１００３からステップ１０１１では、関係者（すなわち発明者）の情報を１人ずつ処理する。まず、ステップＳ１００４では、処理する関係者１名分のデータに着目する。
【００４２】
ステップＳ１００５では、着目中の関係者データが、社員のものであるか社外関係者のものであるかを判定する。図１０のフローチャートでは、関係者種別判定（図３の関係者種別判定手段３０９）を用いているが、関係者種別判定手段から社外関係者判定手段（図３の社外関係者判定手段３１２）を呼び出しても良いし、ステップＳ１００５の処理を社外関係者判定手段で置き換えてもよい。社外関係者判定手段では、着目中のデータを判定するために、例えば出願書類において発明者の覧には発明者の名前と会社名（所属情報）が並んでいるため、会社名を用いることができる。
【００４３】
ステップＳ１００６では、ステップＳ１００５の判定結果により、社内関係者と社外関係者で処理を分岐する。社員の場合にはステップＳ１００７に進む。
【００４４】
ステップＳ１００７では、社員であるため人事ＤＢを検索し、個人ＩＤを取得する。ここで個人ＩＤを取得する目的は、姓名は結婚などにより変わる可能性があるからである。前述の電子データに社員名だけではなく個人ＩＤを登録することで、姓名が変わった場合でも対応できる。さらに、例えば同姓同名の社員がいるような場合には、後述の登録前確認のステップＳ１０１０（図１３のＧＵＩ１３０１に対応）で警告を出し、正しい発明者を選択させ、将来的な処理を適切に行うように対応することができる。
【００４５】
一方、社員ではない場合はステップＳ１００８に進む。ステップＳ１００８では、社外関係者ＤＢ検索手段３１４により、社外関係者ＤＢ３２５（図６）から着目中の関係者を検索する。
【００４６】
ここで社外関係者ＤＢ（図６）について説明する。本説明では、社外関係者ＤＢには、個人ＩＤ６０１、氏名６０２、会社名６０３、申請人識別番号６０４、メールアドレス６０５が格納されている。すなわち社外関係者ＤＢ検索手段３１４の検索結果としては、これらの情報が含まれるが、これらはあくまで例である。
【００４７】
社外関係者ＤＢ検索手段３１４での同姓同名の異なる人物の検索をできるかぎり避けるため、検索条件には関係者の姓名の他、会社名や申請者識別番号を用いてもよい。ただしこの場合でも、姓名の変更により検索できない可能性や、同姓同名が区別できない複数人物が検索される可能性があれば（いずれもこの段階では着目中の社外関係者の個人ＩＤは不明なために発生する）検索結果はあくまで「候補」とし、後で人手による確認が必要であるとしてもよい。この確認も後述の登録前確認のステップＳ１０１０（図１３のＧＵＩ１３０１）で実施することとしてもよい。
【００４８】
以上、ステップＳ１００４からステップＳ１００８までの処理により、前述の電子データの元となるデータから抽出した関係者１名分の処理が完了する。
【００４９】
全ての関係者に対して前述の処理が完了すると、ステップＳ１００３からステップＳ１００９までのループが完了し、ステップＳ１０１０に進む。
【００５０】
ステップＳ１０１０では、例えば図１３のＧＵＩ１３０１により、電子データ記憶手段に登録する電子データの内容が正しいことを事前に確認する。図１３の１３０２は発明者（電子データの関係者）に関する情報であり、前述のように同姓同名の社員がいるため誤って取得する、結婚などで姓が変更されたりして取得できない、というケースが、社員の場合でも社外関係者の場合でも起こりえる。そのため氏名１３０３の修正が必要な場合がある。また、社外関係者の場合には、初めて共同発明者になる場合など社外関係者ＤＢに登録されていない場合もあり、新たに管理対象とするため一意的な個人ＩＤ１３０５の付与、電子データの元データからは抽出できない情報（例えばメールアドレス１３０６）などの記載をする。さらに必要なデータがあればファイルとして添付してもよい（１３０７）。
【００５１】
ＧＵＩ１３０１での確認および必要があれば修正をした後の電子データを、保存ボタン１３０８を押下することで登録する。
【００５２】
ステップＳ１０１１では、まず新しい社外関係者を社外関係者ＤＢ（図６）に登録する。
【００５３】
ステップＳ１０１２では、電子データに一意的なデータＩＤ、例えば“１０００−００１”を発行する。
【００５４】
ステップＳ１０１３では、電子データに関連する情報を登録する。まず、ステップＳ１０１２で発行したデータＩＤと関連付けて、関係者（発明者）のうち社員を電子データ関係者ＤＢ登録手段により電子データ関係者ＤＢ（図５）に登録する。図１３の例では、社員としての発明者は“安藤太郎”
、“佐々木次郎”、“金子花子”の３名なので（図９の人事ＤＢの社員ＩＤから）“１０００１”、“１０００２”、“２００１０”が取得され、図５のデータＩＤ５０１に取得したデータＩＤ“１０００−００１”と、個人ＩＤ５０２に“１０００１”、“１０００２”、“２００１０”の３レコードが登録される。
【００５５】
同様に電子データ社外関係者ＤＢに、データＩＤ７０１に“１０００−００１”、個人ＩＤ７０２に“Ｚ１０００”（田中一郎さんの社外関係者ＤＢに登録されている個人ＩＤ）が対応付けで登録される。
【００５６】
最後に電子データの本体が図４のテーブル４０１に登録される。テーブル４０１の最初のレコードが対応するデータＩＤを持つが、当初のステータス４０５は“出願完了”などとなる。以上により、電子データの登録処理についての説明を完了する。
【００５７】
次に図１１のフローチャートを用いて電子データの関係者に通知メールを送信する処理を説明する。本フローチャートは、人手の操作により、特定の条件の電子データを検索し、その検索結果である電子データを対象として通知メール送信する処理を示す。
【００５８】
例えば特許出願後３年以内に審査請求する必要があるので、２０１０年終わり頃に、２年〜２年半前に出願した特許出願データを、知財担当者が発明者に通知する処理を説明する。
【００５９】
ステップＳ１１０１では、通知対象の電子データを検索するための条件を指定する（図３の電子データ検索条件指定手段３０３）。例えば、図１２のＧＵＩ１２０１を表示し、検索条件１２０２を入力する。図１２の検索条件の例としては、データ種別１２０３が“Ａ０１：特許”の電子データであること、ステータス１２０４が“審査請求確認”であること（このステータスの例は、発明者に「審査請求をすることを要望するか」確認するステータスであることを意味している）が指定されている。
【００６０】
また出願期間１２０５として、開始１２０６が“２００８年７月１日”から終了１２０７“２００８年１２月３１日”の特許出願を対象としている。
【００６１】
その他、ＧＵＩ１２０１では条件としてステータスの変更を利用することも可能である。すなわち前ステータス１２０８が何であったか、前ステータスから現在のステータスへの更新期間１２０９がいつであったか（開始１２１０、終了１２１１で指定）を利用する。これらの条件はあくまで例であり、電子データに格納されている任意のデータを検索条件としてもよい。またＧＵＩ１２０１は、例を特許出願書類のデータとしているが、他の種別のデータであれば変更してもよい。例えばワークフローの電子データを確認するものであれば、金額、起票者、承認者のような項目を検索条件としてもよい。
【００６２】
ＧＵＩ１２０１で検索条件１２０２を設定したら、検索ボタン１２１２を押下する。これにより、ステップＳ１１０２が実行される。
【００６３】
ステップＳ１１０２では図３の電子データ検索手段３０４が呼び出され、検索条件１２０２で設定した条件に基づき、電子データが収集される。
【００６４】
ステップＳ１１０３では、ステップＳ１１０２で収集したデータの確認をする。例えば、前述のＧＵＩ１２０１（図１２）の検索条件１２０２の下に結果一覧１２１３が表示される。本例では２件の結果、“１０００−０００１”、“１０００−０００４”が表示されている。詳細を確認したい場合には、確認したいデータをマウスまたはカーソルで選択し、マウスのダブルクリックやキーボードのエンターキーにより、例えば図１３のＧＵＩ１３０１を表示する。これは登録時の確認画面と同じであるが、異なるＧＵＩを用意してもよい。登録してから時間が経過しているため、姓名、メールアドレスなど変更があればここで修正し、保存ボタン１３０８で保存してもよい。詳細の確認が終わったら、閉じるボタン１３０９でＧＵＩ１３０１を閉じる。
【００６５】
以下、ステップＳ１１０４からステップＳ１１２２で構成するループで、検索された電子データ１件ずつに通知処理を実行する。
【００６６】
ステップＳ１１０５では、検索された電子データの１件に着目する。以下、前述の２件のうちの１件目、データＩＤ“１０００−０００１”を例として説明する。
【００６７】
ステップＳ１１０６では、着目中の電子データから“データ種別”、“ステータス”を取得する。なお、電子データ記憶手段に格納されているデータが１種類である場合には、“ステータス”のみの取得でもよいが、以下の例では両方を使用する。
【００６８】
ステップＳ１１０７では、図８の通知メールに関する情報を管理するデータベースから通知メール情報ＤＢ検索手段（通知メール情報データベース検索手段）３１７（図３）を用いて１つの通知メール情報を検索する。ここで図８について説明する。
【００６９】
データ種別８０１は、図４のデータ種別４０４に対応する値であり、通知メール情報がいずれの電子データに対する処理に使用されるのかを指定するものである。本例では、“Ａ０１：特許”などの値が格納される。ステータス８０２は、図４のステータス４０５に対応する値であり、通知メール情報がいずれのステータスに対応して使用されるのかを指定するものである。本例では、“審査請求確認”などの値が格納される。送信先種別８０３は、電子データの特定のステータスについて通知する際、必ずしも電子データの関係者（特許の例では発明者）の全員に通知するのではなく、誰に通知するかを指定するものである。この値は、後述するステップＳ１１１１、ステップＳ１１１５の条件分岐において使用される。さらにメール件名８０４は、通知するメールの件名、メール本文８０５は通知内容のうち中心となるメッセージであり、本メッセージに特許の例でいえば、発明の名称や発明者などの情報を加えて、メールの本文を生成する。
【００７０】
説明をステップＳ１１０７に戻す。着目中の電子データは（検索条件１２０２の指定により）データ種別が“Ａ０１：特許”、ステータスが“審査請求確認”であるので、これを検索条件とし、通知メール情報ＤＢ検索手段３１７（図３）は、図８の１行目の通知メール情報８０６を取得する。
【００７１】
ステップＳ１１０８では、着目中の電子データの関係者のうち社員（退職者などを含む）を取得する。本フローチャートの例では、ステップＳ１１０３で収集した電子データをＧＵＩ１３０１で確認するため、既に社外関係者ＤＢ（図６）および人事ＤＢ（図９）から関係者の詳細情報を収集しているが、そうでない場合には、本ステップおよび後述のステップＳ１１１５で詳細データを収集してもよい。本発明の例としては、着目中のデータは“１０００−０００１”を例としているため、社員（退職者などなどを含む）として“安藤太郎”、“佐々木次郎”、“金子花子”の３人が取得される。
【００７２】
ステップＳ１１０９からステップＳ１１１３のループでは、関係者のうち、社員（退職者などを含む）に対して通知メールの送信先とするか判定する処理を実行する。
【００７３】
ステップＳ１１１０では、社員（退職者などを含む）の情報１名分に着目する。ステップＳ１１１１では、着目した社員（退職者などを含む）のうちいずれのものにメールを送信するか判断する条件である。現在の条件で取り出した通知メール情報は、送信先種別８０３が“社員のみ”である。社員“安藤太郎”に着目したときは、人事ＤＢ（図９）により在職中の社員であるため、ステップＳ１１１２に進み、通知メール送信先として“安藤太郎”のメールアドレス９０４が追加される。“金子花子”についても同様であるが、“佐々木次郎”については、退職社員であるため（図９の“佐々木次郎”のデータ退職年月日９０６の記載より判断）、ステップＳ１１１２をスキップし、通知メール送信先には追加されない。ただし、送信先種別が、通知メール情報８０７の場合は“社員（退職者等含む）”、または通知メール情報８０８の場合は“全員”（社員（退職者等含）の他、社外関係者も含む、の意味）であるため、ステップＳ１１１１の判定からステップＳ１１１２に進み、“佐々木次郎”も通知メール送信先に追加される。
【００７４】
ステップＳ１１１４では、メールの通知先として社外関係者かどうか判断する。現在の例、即ち通知メール情報８０６では、送信先種別８０３が“社員のみ”であるため、ステップ１１２０に進む。本実施例では、特許出願の審査請求をするかどうかの判断は、在職中の社員に限定して通知し確認したい、ということから、通知先を“社員のみ”に限定した例としている。
【００７５】
通知メール情報８０７の場合でも送信先種別８０３は“社員（退職者等含む）”なので同様である。通知メール情報８０８の場合は“全員”であるため、退職者である“佐々木次郎”のメールアドレスも通知メール送信先に追加される。前者の例としては、図４の電子データ“１０００−０００２”において、特許出願が、“登録”ステータスになったときには、登録報奨金が支払われる旨を“社員（退職者等含）”に通知する。後者の例としては、図４の電子データ“１０００−０００３”において、特許出願が、“出願完了”ステータスになったときには、
“全員”（“社員（退職者等含）”と“社外関係者”を意味する）に通知する。どういう状況（ステータス）で、誰に通知するのが適切かは、共同出願者の会社としての契約などにもよるので、本説明での設定はあくまで例である。
【００７６】
さて、前述の通り図４の電子データＩＤ“１０００−０００３”を例にとれば、上述の通り通知メール情報８０８が選択されるため、社外関係者にも通知メール送信の設定がされる。この処理を図１１のフローチャートのステップＳ１１１５からステップＳ１１１９で説明する。
【００７７】
ステップＳ１１１５では、電子データＩＤ“１０００−０００３”の社外関係者の一覧を取得する。本例では、田中一郎”の１名が取得される。
【００７８】
ステップＳ１１１６からステップＳ１１１９のループで、社外関係者のアドレスを送信先として設定する。ステップＳ１１１７では、ステップＳ１１１５で取り出した社外関係者のデータのうち、１名分のデータに着目する。ステップＳ１１１８では、着目中の社外関係者のメールアドレスを取得し、送信先として追加する。
【００７９】
全ての社外関係者に対して処理を完了するとステップＳ１１１６からステップＳ１１１９のループを抜け、ステップＳ１１２０に進む。
【００８０】
Ｓ１１２０は、Ｓ１１０７において電子データのデータ種別とステータスから取得された通知メール情報により、通知メールの件名と本文を生成する。電子データが“１０００−０００１”であれば通知メール情報８０６により、“審査請求確認”の通知を“社員のみ”用に生成する。同様に電子データ“１０００−０００２”であれば通知メール情報８０７により、“登録”の通知を“社員（退職者等含）”用に生成する。電子データ“１０００−０００３”であれば通知メール情報８０８により、“出願完了”の通知を“全員”（“社員（退職者等含）”と“社外関係者”を意味する）用に生成する。
【００８１】
ステップＳ１１２１では、ステップＳ１１１２で通知先に追加した社員（条件によって退職者等も含む）、ステップＳ１１１８で通知先に追加した社外関係者を送信先として、ステップＳ１１２０で生成したメールを配信する。配信したメールの例を図１４、図１５、図１６に示す。
【００８２】
ステップＳ１１０４からステップＳ１１２２のループで、検索結果の全ての電子データに対して通知処理を完了する。以上で、電子データの関係者に通知メールを送信する処理の説明を完了する。
【００８３】
なお、図１１のフローチャート実行時には、電子データの登録処理（図１０）と同様に、通知する関係者の情報を図１３のＧＵＩ１３０１で確認可能なステップＳ１１０２がある。本処理では関係者（発明者）は既に個人ＩＤとして管理されているため、例え姓が変更になっていても特定できるが、通知前に必要な確認、更新をするためである。ただし、本フローチャートを特定の日付や時刻に自動的に起動し、メールによる通知を自動化する場合などには、ステップＳ１１０２による確認をスキップしてもよい。
【００８４】
さらに、関係者を通知メールの送信先に追加するかどうかの判断を、社員の場合には“Ｓ１１０９からＳ１１１３のループと、社外関係者の場合には、”Ｓ１１１４の分岐とでプログラムにハードコーディングしてしまっているが、プログラムとしては任意の条件を判断できる汎用的な実装にしておき、送信先種別８０３の記載をより詳しいルールなど設定する、あるいは外部設定ファイルに記載にしておくことで、図１１のフローチャートを変えずに社員、退職者など、社外関係者以外の判定をしてもよい。本フローチャートはあくまで例であり、説明を簡単にするために、図１１の通りにした。
【００８５】
また、本発明の目的は、以下の処理を実行することによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。
【００８６】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００８７】
また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等である。または、プログラムコードを、ネットワークを介してダウンロードしてもよい。
【００８８】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【００８９】
更に、前述した実施形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行う場合である。
【００９０】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した各実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳなどが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現する場合も含まれる。
【００９１】
この場合、上記プログラムは、該プログラムを記憶した記憶媒体から直接、またはインターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続された不図示の他のコンピュータやデータベースなどからダウンロードすることにより供給される。
【００９２】
上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。
【符号の説明】
【００９３】
１０１  電子データ管理サーバ
１０２  人事ＤＢサーバ
１０３  データ管理者クライアントＰＣ
１０４  データ関係者クライアントＰＣ
１０５  ネットワーク
２０１  ＣＲＴ
２０２  入力デバイス
２０３  ＣＰＵ
２０４  ＲＡＭ
２０５  ＲＯＭ
２０６  外部記憶装置
２０７  ネットワーク・インタフェース
２０８  バス
３０１  電子データ登録手段
３０２  電子データ更新手段
３０３  電子データ検索条件指定手段
３０４  電子データ検索手段
３０５  電子データ検索結果表示手段
３０６  電子データ詳細内容表示手段
３０７  自動通知手段
３０８  関係者種別取得手段
３０９  関係者種別判定手段
３１０  電子データ関係者ＤＢ登録手段
３１１  電子データ関係者ＤＢ検索手段
３１２  社外関係者判定手段
３１３  社外関係者ＤＢ登録手段
３１４  社外関係者ＤＢ検索手段
３１５  電子データ社外関係者ＤＢ登録手段
３１６  電子データ社外関係者ＤＢ検索手段
３１７  通知メール情報ＤＢ検索手段
３１８  通知判定手段
３１９  通知メール生成手段
３２０  通知メール配信手段
３２１  人事ＤＢ検索手段
３２２  退職者等判定手段
３２３  電子データ記憶手段
３２４  電子データ関係者ＤＢ
３２５  社外関係者ＤＢ
３２６  電子データ社外関係者ＤＢ
３２７  通知メール情報ＤＢ
３２８  人事ＤＢ
【図１】
2012118702.tif 000003
【図２】
2012118702.tif 000004
【図３】
2012118702.tif 000005
【図４】
2012118702.tif 000006
【図５】
2012118702.tif 000007
【図６】
2012118702.tif 000008
【図７】
2012118702.tif 000009
【図８】
2012118702.tif 000010
【図９】
2012118702.tif 000011
【図１０】
2012118702.tif 000012
【図１１】
2012118702.tif 000013
【図１２】
2012118702.tif 000014
【図１３】
2012118702.tif 000015
【図１４】
2012118702.tif 000016
【図１５】
2012118702.tif 000017
【図１６】
2012118702.tif 000018