JP2003108720A - ワークフロー支援システム、ワークフロー支援方法、ワークフロー支援プログラムおよびそのプログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 種々の業務に使用されるデータベースのデー
タの信頼性を確保しつつ、個々の業務におけるデータの
安定性を維持すること。 【解決手段】 あらかじめ設定された抽出日になると、
あらかじめ設定された抽出条件に合致する特許出願のデ
ータが、メインフレーム１０１上の国内特実マスタ１０
１ａからサーバ１０２上の審査請求ＤＢ１０２ａに読み
出される。そして、以後はもっぱら審査請求ＤＢ１０２
ａ内のデータ（上記抽出日現在のデータ）を使用して、
個々の出願につき審査請求を要するか否かが検討され、
その検討結果および検討の過程で発見・修正されたエラ
ーももっぱら審査請求ＤＢ１０２ａに蓄積される。審査
請求ＤＢ１０２ａ内のデータは、所定の時期になると国
内特実マスタ１０１ａに書き戻されるが、この読み出し
から書き戻しまでの間、国内特実マスタ１０１ａ内のデ
ータは随時更新可能である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、特許出願の価
値、特にその審査請求価値を評価するためのワークフロ
ーの支援システム、ワークフローの支援方法、ワークフ
ローの支援プログラムおよびそのプログラムを記録した
コンピュータ読み取り可能な記録媒体に関する。

【０００２】

【従来の技術】コンピュータ関連技術の急速な進歩、お
よびコンピュータ関連機器の急速な価格低下を背景に、
ＰＣやＬＡＮなどを導入する企業の数が近年飛躍的に増
大している。そして、ある程度以上の規模の企業では、
一般に「グループウェア」と呼ばれるソフトウェア（代
表的なものに米国Ｌｏｔｕｓ社の「Ｌｏｔｕｓ Ｎｏｔ
ｅｓ」がある）を使用して、複数人による情報の共有化
や意思疎通をはかることにより、業務の生産性を大きく
向上させている。

【０００３】そして、さらに電子文書を所定の宛先に順
次回付することで、ある事項についての企業としての意
思決定（稟議・決裁）、あるいは意思決定後の事務作業
などを支援するための、一般に「ワークフロー支援シス
テム」などと呼ばれるシステムも広く実用化されてい
る。たとえば特開平１１−１４３９６３号公報、特開平
１１−１４３９８０号公報、特開平１１−２１９４０１
号公報、特開平１１−２１９４０２号公報、特開平１１
−２１９３９３号公報などでは、企業による特許出願を
円滑におこなうためのワークフロー支援システムが提案
されている。

【０００４】ところでいったん出願した発明について
は、さらにその審査請求をおこなうか否かを出願後七年
以内に決定しなければならない。このように審査請求の
可能な時期には法律上の制限があるため、過誤により権
利化不能となる発明が発生しないよう、発明の価値の検
討は適切な時期に確実におこなわなければならない。そ
して、年間数千件単位の特許出願をおこなう企業では、
年に数度過去のある時期に出願した発明につき一括して
審査請求の要否を検討し、企業にとって必要な発明とそ
うでない発明とを選別するのが一般的である。

【０００５】

【発明が解決しようとする課題】ところで、このように
大量の特許出願をおこなう企業では、それらを管理した
り検索したりするための巨大なデータベースを有してい
るのが通例である。そして、各出願につき公開、拒絶、
補正、登録などのイベントが発生する都度、あるいは入
力ミスなどを発見する都度、データベースに保持された
データを随時書き換えてゆく。こうした絶え間ない更新
により、データベースのデータの正確性やリアルタイム
性の確保がはかられている。

【０００６】しかしながら、データベースのデータが刻
々と変化してゆくのではかえって不都合な場合もある。
たとえば上述の審査請求要否の検討では、対象となって
いる出願の番号が途中で変化してしまうと、発明の同一
性が不明確となり業務に支障を生ずるおそれがある。か
といって、たとえば上記検討の間中データベースの編集
や参照を一切禁止するようにすると、現状を反映しない
データしか見られなかったり、それさえも見られなかっ
たりすることになり、上記以外の業務に与える影響が大
きい。

【０００７】この発明は上記従来技術の問題点に鑑みて
なされたものであって、種々の業務に使用されるデータ
ベースのデータの信頼性を確保しつつ、個々の業務にお
けるデータの安定性を維持することが可能なワークフロ
ー支援システム、ワークフロー支援方法、ワークフロー
支援プログラムおよびそのプログラムを記録したコンピ
ュータ読み取り可能な記録媒体を提供することを目的と
する。

【０００８】

【課題を解決するための手段】上述した課題を解決し、
目的を達成するため、請求項１に記載のワークフロー支
援システムは、特許出願の価値を評価するための複数の
工程からなり、前記各工程における作業者のメールアド
レスに対して必要な情報を電子メールで送信することに
より、前記特許出願の価値の評価をおこなうワークフロ
ーの支援システムにおいて、あらかじめ定められた第１
の時期になったか否かを判定する判定手段と、前記判定
手段により前記第１の時期になったと判定された場合
に、前記特許出願のうちあらかじめ定められた条件に合
致するものを検索する検索手段と、前記検索手段により
検索された特許出願に関する情報を第１のデータベース
から読み出す読み出し手段と、前記読み出し手段により
読み出された情報を第２のデータベースに対して送信す
る送信手段と、前記送信手段により送信されてきた情報
を前記第２のデータベースに登録する登録手段と、を備
えたことを特徴とする。

【０００９】この請求項１に記載の発明によれば、個々
の出願の価値の評価は、実態を反映して随時更新されて
ゆくデータベース（第１のデータベース）でなく、もっ
ぱらその一部を過去の一点で切り出したデータベース
（第２のデータベース）にもとづいておこなわれること
になる。

【００１０】また、請求項２に記載のワークフロー支援
システムは、前記請求項１に記載の発明において、さら
に、前記特許出願の価値に関する情報を前記第２のデー
タベースに登録する第２の登録手段と、あらかじめ定め
られた第２の時期になったか否かを判定する第２の判定
手段と、前記第２の判定手段により前記第２の時期にな
ったと判定された場合に、前記登録手段および前記第２
の登録手段により前記第２のデータベースに登録された
情報を前記第１のデータベースに対して送信する第２の
送信手段と、前記第２の送信手段により送信されてきた
情報にもとづいて前記第１のデータベースに格納された
情報を更新する更新手段と、を備えたことを特徴とす
る。

【００１１】この請求項２に記載の発明によれば、個々
の出願の価値の評価は実態を反映して随時更新されてゆ
くデータベース（第１のデータベース）でなく、もっぱ
らその一部を過去の一点で切り出したデータベース（第
２のデータベース）にもとづいておこなわれるととも
に、評価完了後には第２のデータベースに蓄積されてい
た、個々の出願の評価結果がまとめて第１のデータベー
スに反映される。

【００１２】また、請求項３に記載のワークフロー支援
システムは、前記請求項２に記載の発明において、さら
に、前記登録手段により前記第２のデータベースに登録
された情報を修正する修正手段を備え、前記送信手段
は、前記修正手段により修正された情報および前記第２
の登録手段により登録された情報を送信することを特徴
とする。

【００１３】この請求項３に記載の発明によれば、個々
の出願の価値の評価は実態を反映して随時更新されてゆ
くデータベース（第１のデータベース）でなく、もっぱ
らその一部を過去の一点で切り出したデータベース（第
２のデータベース）にもとづいておこなわれるととも
に、評価完了後には第２のデータベースに蓄積されてい
た、個々の出願の評価結果や評価の過程で発見・修正さ
れたデータなどがまとめて第１のデータベースに反映さ
れる。

【００１４】また、請求項４に記載のワークフロー支援
システムは、前記請求項１〜請求項３のいずれか一つに
記載の発明において、前記送信手段および前記第２の送
信手段は、前記情報を単一のファイルに格納して送信す
ることを特徴とする。

【００１５】この請求項４に記載の発明によれば、第１
のデータベースと第２のデータベースとの間で授受され
るデータのサイズを小さくすることができる。

【００１６】また、請求項５に記載のワークフロー支援
システムは、前記請求項２〜請求項４のいずれか一つに
記載の発明において、前記第２の登録手段により登録さ
れる前記特許出願の価値に関する情報とは、前記特許出
願について審査請求をおこなう価値があるか否かを示す
情報であることを特徴とする。

【００１７】この請求項５に記載の発明によれば、個々
の出願の価値の評価は実態を反映して随時更新されてゆ
くデータベース（第１のデータベース）でなく、もっぱ
らその一部を過去の一点で切り出したデータベース（第
２のデータベース）にもとづいておこなわれるととも
に、評価完了後には第２のデータベースに蓄積されてい
た、個々の出願の審査請求価値がまとめて第１のデータ
ベースに反映される。

【００１８】また、請求項６に記載のワークフロー支援
方法は、特許出願の価値を評価するための複数の工程か
らなり、前記各工程における作業者のメールアドレスに
対して必要な情報を電子メールで送信することにより、
前記特許出願の価値の評価をおこなうワークフローの支
援方法において、あらかじめ定められた第１の時期にな
ったか否かを判定する判定ステップと、前記判定ステッ
プで前記第１の時期になったと判定された場合に、前記
特許出願のうちあらかじめ定められた条件に合致するも
のを検索する検索ステップと、前記検索ステップで検索
された特許出願に関する情報を第１のデータベースから
読み出す読み出しステップと、前記読み出しステップで
読み出された情報を第２のデータベースに対して送信す
る送信ステップと、前記送信ステップで送信されてきた
情報を前記第２のデータベースに登録する登録ステップ
と、を含んだことを特徴とする。

【００１９】この請求項６に記載の発明によれば、個々
の出願の価値の評価は、実態を反映して随時更新されて
ゆくデータベース（第１のデータベース）でなく、もっ
ぱらその一部を過去の一点で切り出したデータベース
（第２のデータベース）にもとづいておこなわれること
になる。

【００２０】また、請求項７に記載のワークフロー支援
方法は、前記請求項６に記載の発明において、さらに、
前記特許出願の価値に関する情報を前記第２のデータベ
ースに登録する第２の登録ステップと、あらかじめ定め
られた第２の時期になったか否かを判定する第２の判定
ステップと、前記第２の判定ステップで前記第２の時期
になったと判定された場合に、前記登録ステップおよび
前記第２の登録ステップで前記第２のデータベースに登
録された情報を前記第１のデータベースに対して送信す
る第２の送信ステップと、前記第２の送信ステップで送
信されてきた情報にもとづいて前記第１のデータベース
に格納された情報を更新する更新ステップと、を含んだ
ことを特徴とする。

【００２１】この請求項７に記載の発明によれば、個々
の出願の価値の評価は実態を反映して随時更新されてゆ
くデータベース（第１のデータベース）でなく、もっぱ
らその一部を過去の一点で切り出したデータベース（第
２のデータベース）にもとづいておこなわれるととも
に、評価完了後には第２のデータベースに蓄積されてい
た、個々の出願の評価結果がまとめて第１のデータベー
スに反映される。

【００２２】また、請求項８に記載のワークフロー支援
方法は、前記請求項７に記載の発明において、さらに、
前記登録ステップで前記第２のデータベースに登録され
た情報を修正する修正ステップを含み、前記送信ステッ
プでは、前記修正ステップで修正された情報および前記
第２の登録ステップで登録された情報を送信することを
特徴とする。

【００２３】この請求項８に記載の発明によれば、個々
の出願の価値の評価は実態を反映して随時更新されてゆ
くデータベース（第１のデータベース）でなく、もっぱ
らその一部を過去の一点で切り出したデータベース（第
２のデータベース）にもとづいておこなわれるととも
に、評価完了後には第２のデータベースに蓄積されてい
た、個々の出願の評価結果や評価の過程で発見・修正さ
れたデータなどがまとめて第１のデータベースに反映さ
れる。

【００２４】また、請求項９に記載のワークフロー支援
方法は、前記請求項６〜請求項８のいずれか一つに記載
の発明において、前記送信ステップおよび前記第２の送
信ステップでは、前記情報を単一のファイルに格納して
送信することを特徴とする。

【００２５】この請求項９に記載の発明によれば、第１
のデータベースと第２のデータベースとの間で授受され
るデータのサイズを小さくすることができる。

【００２６】また、請求項１０に記載のワークフロー支
援方法は、前記請求項７〜請求項９のいずれか一つに記
載の発明において、前記第２の登録ステップで登録され
る前記特許出願の価値に関する情報とは、前記特許出願
について審査請求をおこなう価値があるか否かを示す情
報であることを特徴とする。

【００２７】この請求項１０に記載の発明によれば、個
々の出願の価値の評価は実態を反映して随時更新されて
ゆくデータベース（第１のデータベース）でなく、もっ
ぱらその一部を過去の一点で切り出したデータベース
（第２のデータベース）にもとづいておこなわれるとと
もに、評価完了後には第２のデータベースに蓄積されて
いた、個々の出願の審査請求価値がまとめて第１のデー
タベースに反映される。

【００２８】また、請求項１１に記載のワークフロー支
援プログラムは、特許出願の価値を評価するための複数
の工程からなり、前記各工程における作業者のメールア
ドレスに対して必要な情報を電子メールで送信すること
により、前記特許出願の価値の評価をおこなうワークフ
ローの支援プログラムにおいて、あらかじめ定められた
第１の時期になったか否かを判定する判定ステップと、
前記判定ステップで前記第１の時期になったと判定され
た場合に、前記特許出願のうちあらかじめ定められた条
件に合致するものを検索する検索ステップと、前記検索
ステップで検索された特許出願に関する情報を第１のデ
ータベースから読み出す読み出しステップと、前記読み
出しステップで読み出された情報を第２のデータベース
に対して送信する送信ステップと、前記送信ステップで
送信されてきた情報を前記第２のデータベースに登録す
る登録ステップと、をコンピュータに実行させることを
特徴とする。

【００２９】この請求項１１に記載の発明によれば、個
々の出願の価値の評価は、実態を反映して随時更新され
てゆくデータベース（第１のデータベース）でなく、も
っぱらその一部を過去の一点で切り出したデータベース
（第２のデータベース）にもとづいておこなわれること
になる。

【００３０】また、請求項１２に記載のワークフロー支
援プログラムは、前記請求項１１に記載の発明におい
て、さらに、前記特許出願の価値に関する情報を前記第
２のデータベースに登録する第２の登録ステップと、あ
らかじめ定められた第２の時期になったか否かを判定す
る第２の判定ステップと、前記第２の判定ステップで前
記第２の時期になったと判定された場合に、前記登録ス
テップおよび前記第２の登録ステップで前記第２のデー
タベースに登録された情報を前記第１のデータベースに
対して送信する第２の送信ステップと、前記第２の送信
ステップで送信されてきた情報にもとづいて前記第１の
データベースに格納された情報を更新する更新ステップ
と、をコンピュータに実行させることを特徴とする。

【００３１】この請求項１２に記載の発明によれば、個
々の出願の価値の評価は実態を反映して随時更新されて
ゆくデータベース（第１のデータベース）でなく、もっ
ぱらその一部を過去の一点で切り出したデータベース
（第２のデータベース）にもとづいておこなわれるとと
もに、評価完了後には第２のデータベースに蓄積されて
いた、個々の出願の評価結果がまとめて第１のデータベ
ースに反映される。

【００３２】また、請求項１３に記載のワークフロー支
援プログラムは、前記請求項１２に記載の発明におい
て、前記第２の登録ステップで登録される前記特許出願
の価値に関する情報とは、前記特許出願について審査請
求をおこなう価値があるか否かを示す情報であることを
特徴とする。

【００３３】この請求項１３に記載の発明によれば、個
々の出願の価値の評価は実態を反映して随時更新されて
ゆくデータベース（第１のデータベース）でなく、もっ
ぱらその一部を過去の一点で切り出したデータベース
（第２のデータベース）にもとづいておこなわれるとと
もに、評価完了後には第２のデータベースに蓄積されて
いた、個々の出願の審査請求価値がまとめて第１のデー
タベースに反映される。

【００３４】また、請求項１４に記載の記録媒体は、前
記請求項１１〜請求項１３のいずれか一つに記載のプロ
グラムを記録したことを特徴とする。

【００３５】この請求項１４に記載の発明によれば、前
記請求項１１〜請求項１３のいずれか一つに記載のプロ
グラムがコンピュータにより読み取られて実行される。

【００３６】

【発明の実施の形態】以下に添付図面を参照して、本発
明にかかるワークフロー支援システム、ワークフロー支
援方法、ワークフロー支援プログラムおよびそのプログ
ラムを記録したコンピュータ読み取り可能な記録媒体の
好適な実施の形態を詳細に説明する。

【００３７】（システム全体の概略構成）図１は、本発
明の実施の形態によるワークフロー支援システムの概略
構成を示す説明図である。図中、メインフレーム１０１
には本出願人が出願人あるいは権利者となっている国内
の特許出願、および実用新案登録出願のデータを格納し
た「国内特実マスタ」１０１ａと、本出願人の現在雇用
する、あるいは過去に雇用していた社員に関するデータ
を格納する「人事マスタ」１０１ｂとが保持されてい
る。

【００３８】また、サーバ１０２には「審査請求ＤＢ
（データベース）」１０２ａ（正確には「審査請求要否
評価ＤＢ」であるが、以下では単に「審査請求ＤＢ」と
いう）が保持されている。

【００３９】後述のように、審査請求の要否はメインフ
レーム１０１に格納された全出願のうち、出願から一定
期間を経過したごく一部について判断されるわけである
が、一連の評価作業の間、評価対象となっている出願の
データだけを、メインフレーム１０１上の国内特実マス
タ１０１ａからサーバ１０２上の審査請求ＤＢ１０２ａ
に読み出しておく。そして要否の判断を終えた後、およ
び必要な出願についてその審査請求をおこなった後に、
審査請求ＤＢ１０２ａのデータを国内特実マスタ１０１
ａに書き戻すようにする。

【００４０】また、サーバ１０２には知財区（知財部
門）のＰＣ１０３や開発区（開発部門）のＰＣ１０４な
ど、社内の複数のＰＣがＬＡＮにより接続されている。
サーバ１０２および各ＰＣ１０３・１０４にはグループ
ウェア、具体的には上述の「Ｌｏｔｕｓ Ｎｏｔｅｓ」
がインストールされており、その提供する機能により、
ＰＣ１０３・１０４からサーバ１０２上の審査請求ＤＢ
１０２ａのデータを参照・編集することができる。な
お、知財区にはＰＣ１０３のほか、特許庁に対する各種
電子手続きをおこなうための電子申請専用端末１０５が
設置されている。

【００４１】また、サーバ１０２はファイアウォール
（図示せず）を介してネットワーク回線、さらに「事務
所ＤＢ」１０６ａを保持する所定のＳＰのサーバ１０６
に接続されている。

【００４２】後述のように、最終的に審査請求が必要と
された案件で、外部の特許事務所に審査請求の手続きを
委任するものについては、審査請求ＤＢ１０２ａから必
要事項を抜き出して事務所ＤＢ１０６ａにコピーしてお
く。これにより、代理人はその事務所内のＰＣ１０７か
ら事務所ＤＢ１０６ａの複製をおこなうことで、依頼さ
れた案件の詳細な内容を確認できるようになる。なお、
このＳＰのサーバ１０６および各事務所のＰＣ１０７に
も、上述の「Ｌｏｔｕｓ Ｎｏｔｅｓ」がインストール
されている。

【００４３】（ワークフローの概略手順）つぎに、上記
システムにより実現される審査請求要否評価ワークフロ
ー（以下単に「審査請求ワークフロー」という）の概略
手順について説明する。審査請求の要否の評価には、出
願から一定期間を経過した発明につき定期的におこなう
定期審査請求処理と、早急な権利化が要請される発明な
どにつき臨時的におこなう臨時審査請求処理とがある
が、以下ではもっぱら前者について説明する。

【００４４】定期審査請求処理（以下単に「定期評価」
という）は、通常その出願後１年半〜２年を経過した発
明についておこなう、審査請求の要否の検討とその実際
の手続きである。定期評価の概略の手順は、 （１）国内特実マスタ１０１ａから審査請求ＤＢ１０２
ａへ、今回の評価の対象となる出願のデータを読み出す
（以上、メインフレーム１０１におけるバッチ処理） （２）上記データに必要な修正を施す（以上、知財区の
事務担当者による処理） （３）各出願につき知財区の担当者や開発区の評価者を
決定する（以上、知財区の知財担当者による処理） （４）各出願につき開発区の評価者を決定するととも
に、開発区において審査請求の要否を判断する（以上、
開発区の評価者およびその上司による処理） （５）各出願につき知財区において審査請求の要否を判
断する（以上、知財区の担当者およびその上司による処
理） （６）審査請求ＤＢ１０２ａから国内特実マスタ１０１
ａへデータを書き戻す（以上、サーバ１０２におけるバ
ッチ処理） （７）審査請求要と判断された出願につき、代理人に審
査請求の依頼をし、あるいは自ら審査請求をおこなう
（以上、知財区の事務担当者による処理） のようになる。以下、各々の作業について順次説明す
る。

【００４５】（１）審査請求ＤＢ１０２ａへのデータの
読み出し 図２は、メインフレーム１０１からサーバ１０２へのデ
ータの読み出し（コピー）の手順を示すフローチャート
である。メインフレーム１０１上で動作するソフトウェ
ア（具体的には（株）ビーコンインフォメーションテク
ノロジー社の「Ａ−ＡＵＴＯ」）は、あらかじめ設定さ
れた抽出日になると（ステップＳ２０１：Ｙｅｓ）、あ
らかじめ設定された抽出条件に合致する出願のレコード
を国内特実マスタ１０１ａから検索するためのバッチプ
ログラムを起動する（ステップＳ２０２）。

【００４６】なお、この抽出日は本出願人の場合一年に
三回の頻度で設定され、また抽出条件は主として出願日
により、たとえば「１９９７年２月１日〜同年８月３１
日の期間に出願され、かつ審査請求がまだされていない
発明」のように設定される。

【００４７】そして、上記条件に合致する出願があった
場合（ステップＳ２０３：Ｙｅｓ）、現在注目している
のが何番目の出願であるかを示す変数ｎを初期化する
（ステップＳ２０４）。つぎに、抽出条件に合致した出
願のうちｎ番目のもの（もしあれば）のデータ、たとえ
ばその社内番号（ＦＮＯ：Ｆｉｌｅ Ｎｕｍｂｅｒ）、
出願日、出願番号、公開日、公開番号、発明者、発明の
名称、知財区担当者（以下単に「担当者」ともいう）、
代理人、要約文などを読み出し（ステップＳ２０５：Ｙ
ｅｓ、ステップＳ２０６）、ＣＳＶ形式の転送用ファイ
ルに順次書き込む（ステップＳ２０７）。

【００４８】その後ｎがインクリメントされて（ステッ
プＳ２０８）、後続の出願につき上記処理が繰り返され
る結果、転送用ファイルには抽出条件に合致したすべて
の出願のデータが記述されることになる。そしてこのフ
ァイルは、メインフレーム１０１とサーバ１０２の双方
で動作するソフトウェア（具体的には（株）セゾン情報
システムズ社の「ＨＵＬＦＴ」）により、所定のプロト
コルにしたがってサーバ１０２に送信される（ステップ
Ｓ２０９）。

【００４９】なお、各出願につきその発明者を抽出する
主な目的は、後述のように原則として、その出願の発明
者本人に審査請求の要否を判断させるためである。しか
し、この抽出の時点で発明者が退職後、あるいは休職中
である場合には、いずれにせよ他の発明者や発明者に代
わる他の者に判断させることになるので、抽出は無意味
である。そこで、退職後あるいは休職中の発明者は上記
の転送用ファイルに書き込まないようにすることで、審
査請求ＤＢ１０２ａに不必要なデータが渡らないように
する。

【００５０】図３は、メインフレーム１０１上の発明者
のうち、退職者でも休職者でもない者だけをサーバ１０
２に抽出するための手順を示すフローチャートである。
最初に、現在注目しているのが何番目の出願であるかを
示す変数ｎを初期化し（ステップＳ３０１）、抽出条件
に合致した出願のうちｎ番目のもの（もしあれば）のデ
ータを読み出す（ステップＳ３０２：Ｙｅｓ、ステップ
Ｓ３０３）。

【００５１】つぎに、現在注目しているのが何番目の発
明者であるかを示す変数ｍを初期化し（ステップＳ３０
４）、ｎ番目の出願のｍ番目の発明者（もしあれば）
が、人事マスタ１０１ｂ上で退職あるいは休職になって
いるかどうかを判定する（ステップＳ３０５：Ｙｅｓ、
ステップＳ３０６）。そして、当該発明者が退職者でも
休職者でもない場合に限り（ステップＳ３０６：Ｎ
ｏ）、当該発明者をｎ番目の出願の発明者として転送用
ファイルに書き込む（ステップＳ３０７）。

【００５２】その後ｍをインクリメントして（ステップ
Ｓ３０８）、ｎ番目の出願の全発明者につき同様の判定
と書き込みとを終えると（ステップＳ３０５：Ｎｏ）、
つぎにｎをインクリメントして（ステップＳ３０９）、
後続の出願につき同様の処理を繰り返す。そして、抽出
条件に合致した全出願につき上記処理を終えた時点で
（ステップＳ３０２：Ｎｏ）、本フローチャートによる
処理を終了する。

【００５３】（２）データの修正 上記のようにしてメインフレーム１０１から抽出された
各出願のデータは、サーバ１０２で個々の出願ごとに作
成される「審査請求評価表」（以下単に「評価表」とも
いう）内に格納される。そして、これらの評価表はサー
バ１０２の審査請求ＤＢ１０２ａ内に格納される。

【００５４】ただし、上記で抽出されたデータは不完全
または不適切で、そのままでは評価表への格納のできな
い場合がある。そこで、上記評価表の作成に先立ってデ
ータをチェックし、不備があれば可能な限り自動で当該
不備を補う。さらに、自動では補い切れなかった不備を
知財区の審査請求管理者（事務担当者）に通知し、手動
で補完をおこなわせる。代表的な不備と、その補完の例
を下記に示す。

【００５５】公開番号の欠落 公開番号の項目にデータがない場合である。上述のよう
に定期評価は出願後１年半〜２年で実施されるので、本
来ならば上記抽出の時点ですでに発明は公開され、公開
番号が付与されているはずである。

【００５６】唯一の例外は国内優先権主張の基礎とされ
た出願であって、これらの出願は出願後１年３ヶ月を経
過した時点で取り下げたものとみなされるため、公開番
号が付与されることはない。公開番号の欠落が単なる入
力漏れによるものか、優先権主張によるものかの見極め
は、別途管理されている紙資料などとの照合により審査
請求管理者がおこなう。

【００５７】図４は、出願データのうち特に公開番号に
ついておこなわれるエラーチェックの手順を示すフロー
チャートである。最初に、現在注目しているのが何番目
の出願であるかを示す変数ｎを初期化する（ステップＳ
４０１）。つぎに、メインフレーム１０１から受信した
転送用ファイル内のｎ番目の出願のデータ（もしあれ
ば）を読み出し（ステップＳ４０２：Ｙｅｓ、ステップ
Ｓ４０３）、公開済みの出願に限って（ステップＳ４０
４：Ｙｅｓ）、その審査請求評価表を作成する（ステッ
プＳ４０５）。

【００５８】他方、公開番号が欠落していたり、現在の
状態（ステータス）が「出願後公開前」のままになって
いたりなど、未公開の兆候のある出願のデータは審査請
求ＤＢ１０２ａ内の退避ファイルにまとめて格納する
（ステップＳ４０４：Ｎｏ、ステップＳ４０６）。さら
に、それらの出願を後述するエラー一覧に登録する（ス
テップＳ４０７）。

【００５９】その後ｎをインクリメントして（ステップ
Ｓ４０８）、後続の出願につき上記処理を繰り返し、転
送用ファイル内のすべての出願の処理を終えると（ステ
ップＳ４０２：Ｎｏ）、審査請求管理者に対して後述す
る取り込み完了通知メールを送信する（ステップＳ４０
９）。

【００６０】担当者の欠落、不在など 担当者の項目にデータがない、あるいはデータはあるも
のの、その担当者がすでに人事異動などにより当該発明
の担当を外れているような場合である。知財区の人事に
ついては審査請求管理者が把握しており、異動の都度、
任を解かれる担当者と新たに任ぜられる担当者との対照
表である「担当者移動状況マスタ」を更新している。そ
して、このマスタにもとづいて、旧担当者から新担当者
（現担当者）への差し替えを自動的におこなう。

【００６１】図５は、出願データのうち特に担当者につ
いておこなわれるエラーチェックの手順を示すフローチ
ャートである。図４と同様、転送用ファイル内のｎ番目
の出願を順次チェックしてゆき、担当者のデータがなけ
れば（ステップＳ５０４：Ｎｏ）、当該出願を後述する
エラー一覧に登録する（ステップＳ５０５）。

【００６２】また、担当者が担当者移動状況マスタに旧
担当者として登録されている場合には（ステップＳ５０
４：Ｙｅｓ、ステップＳ５０６：Ｙｅｓ）、上記マスタ
から当該旧担当者に対応する新担当者を取り出す（ステ
ップＳ５０７）。さらに、転送用ファイル内の担当者、
あるいは当該担当者に代わる新たな担当者について、
「特許共通マスタ」からその承認者、具体的には当該担
当者が所属するグループのＧＬ（Ｇｒｏｕｐ Ｌｅａｄ
ｅｒ）を取り出す（ステップＳ５０８）。

【００６３】なお、上記で承認者が取り出せなかったと
きは（ステップＳ５０８：Ｎｏ）、当該出願を担当者の
ない出願と同様にエラー一覧に登録する（ステップＳ５
０５）。そして、いずれにせよ当該出願につき審査請求
評価表を作成し、現時点での担当者および現時点でのそ
の承認者を「担当者」および「承認者」にそれぞれ設定
する（ステップＳ５０９）。

【００６４】その後ｎをインクリメントして（ステップ
Ｓ５１０）、後続の出願につき上記処理を繰り返し、転
送用ファイル内のすべての出願の処理を終えると（ステ
ップＳ５０２：Ｎｏ）、審査請求管理者に対して後述す
る取り込み完了通知メールを送信する（ステップＳ５１
１）。

【００６５】なお、旧担当者と新担当者との対応が記述
されている担当者移動状況マスタは審査請求ＤＢ１０２
ａ内に存在するが、担当者とその承認者との対応（その
他、代理人とその所属する特許事務所との対応など）が
記述されている特許共通マスタは別の場所に存在する。
もっともこれらはいずれも人事に関するデータベースで
あり、一本化することが可能である。本実施の形態にお
いてこれらを別立てとしているのは、別発明である特許
出願ワークフロー支援システム中の特許共通マスタを本
発明でも使い回しているからであって、技術的な要請に
もとづくものではない。

【００６６】発明者の欠落 発明者の項目にデータがない場合である。発明者全員が
退職者や休職者である場合にこのような欠落が生じう
る。もっとも、これを発見してももっぱら事務を担当す
る審査請求管理者には、不在の発明者に代わる他の者を
選定することは困難である。そのため、通常発明者の欠
落は審査請求管理者の段階で補完されることはなく、
（３）で後述するように、その後段の知財区担当者によ
り新たな評価者の選定がなされることで補完される。

【００６７】なお、逆に発明者が複数ある場合には、後
述のようにそのうち一人を代表として評価を依頼するこ
とになるので、評価表の作成の時点でこの代表者（開発
区評価者）を選定しておく。

【００６８】図６は、発明者が複数ある場合におこなわ
れる代表者の選定の手順を示すフローチャートである。
図４と同様、転送用ファイル内のｎ番目の出願を順次チ
ェックしてゆき、発明者のデータがあれば（ステップＳ
６０４：Ｙｅｓ）、その筆頭発明者のみを取り出す（ス
テップＳ６０５）。なお、筆頭発明者とは発明者が複数
あれば第一番目の発明者、発明者が一人のみであれば当
該発明者である。

【００６９】そして、当該出願につき審査請求評価表を
作成し、上記で取り出した筆頭発明者のみをその「評価
者」として設定する（ステップＳ６０６）。他方、発明
者のデータがなければ（ステップＳ６０４：Ｎｏ）、
「評価者」は未設定のまま同様にその評価表を作成する
（ステップＳ６０６）。なお、評価表の「発明者」とし
てはいずれにせよ、転送用ファイル内の発明者（０人〜
複数人）をそのまま設定する。

【００７０】その後ｎをインクリメントして（ステップ
Ｓ６０７）、後続の出願につき上記処理を繰り返し、転
送用ファイル内のすべての出願の処理を終えると（ステ
ップＳ６０２：Ｎｏ）、審査請求管理者に対して後述す
る取り込み完了通知メールを送信する（ステップＳ６０
８）。

【００７１】つぎに、図７は図４、図５あるいは図６に
示した手順の最後に、あらかじめ指定された任意のアド
レス、ここでは審査請求管理者に対して送信される取り
込み完了通知メールの一例を示す説明図である。この電
子メールは、メインフレーム１０１からサーバ１０２へ
のデータ取り込みの事実と、自動では補完し切れなかっ
たデータの不備とを通知して、その修正を促す目的で送
信されるものである。

【００７２】なお、図中「ＲＩＰＳ（Ｒｉｃｏｈ Ｉｎ
ｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ ｉｎｆｏｒ
ｍａｔｉｏｎ Ｓｙｓｔｅｍ）」とは、本出願人が社内
で運用している自社／他社および国内／国外の特許情報
管理システム（の全体）の名称であるが、ここでは特に
その中枢であるメインフレーム１０１を指すと考えてよ
い。

【００７３】また、同図の通知メールにはエラー詳細の
確認先として、審査請求ＤＢ１０２ａ内に作成されたエ
ラー一覧へのリンク（当該一覧のパス）が埋め込まれ、
リンクの部分がアイコンによりグラフィカルに表示され
る。図８は、上記リンクをクリックすると表示される
「取込み結果一覧」ビューの一例を示す説明図である。
同図に示すように、この画面では何らかのエラーの検出
された出願が、そのエラー種別が分かるように一覧表示
される。

【００７４】たとえば、図中「公開番号エラー」項目に
黒丸の記号の入っている案件は、公開番号の欠落などに
より未公開とみなされた出願であることを示している。
未公開案件は、審査請求の要否を検討する必要がないも
の（出願後の優先権主張によりみなし取下げとなったた
め）と仮定されて上述の退避ファイルにまとめられてお
り、いったん審査請求ワークフローの評価の対象から除
外された状態なので、これらを通常のワークフローに復
帰させるには個々にエラー解除をおこなわなければなら
ない。

【００７５】図９は、みなし取下げと同一視されたため
に審査請求ワークフローから除外された出願を、上記フ
ローに復帰させるための手順を示すフローチャートであ
る。図８に示した画面で「エラー解除」ボタンがクリッ
クされると（ステップＳ９０１：Ｙｅｓ）、その時点で
選択されている未公開案件がなければ（ステップＳ９０
２：Ｎｏ）、「エラー解除する案件を選択してくださ
い」「公開番号エラー以外の案件はエラー解除できませ
ん」などのエラーメッセージを表示する（ステップＳ９
０３）。

【００７６】また、選択されている未公開案件があれば
（ステップＳ９０２：Ｙｅｓ）、当該案件のデータを退
避ファイルから読み出す（ステップＳ９０４）。そして
当該データの修正、具体的には欠落している公開番号の
入力や、「出願後公開前」のままになっている現在の状
態（ステータス）の変更がおこなえるようなダイアログ
を表示し、審査請求管理者からの入力待ちとなる（ステ
ップＳ９０５）。

【００７７】そして、審査請求管理者により必要な修正
が施されると（ステップＳ９０５：Ｙｅｓ）、修正後の
データにもとづいて、当該案件につき審査請求評価表を
作成する（ステップＳ９０６）。さらに、当該案件のデ
ータを退避ファイルから削除する（ステップＳ９０
７）。

【００７８】（３）担当者と評価者の決定 上記のようにして、自動抽出されたデータに自動あるい
は手動による必要な修正が施されると、つぎに各出願の
知財区担当者に対して、開発区での評価に先立つ事務作
業が依頼される。そして担当者による以後の作業は、
発明内容を確認し、知財区における担当者を決定（必
要に応じて変更）し、開発区における評価者を決定
（必要に応じて変更）する、という手順で進められる。
以下、順に説明する。

【００７９】発明内容の確認 図１０は、審査請求管理者によるデータ修正後、知財区
担当者に送信される作業依頼メールの一例を示す説明図
である。図示するようにメール本文には依頼の趣旨のみ
が示され、作業に必要な情報、たとえば発明の内容など
は本文内に埋め込まれたリンクを介して参照するように
なっている。

【００８０】図１１は、上記リンク（図中アイコンで示
される）をクリックすると表示される「担当者＆評価者
変更」ビュー、また図１２は、上記ビューでいずれかの
案件をダブルクリックすると表示される審査請求評価表
の一例を示す説明図である。

【００８１】上述のように、この評価表は個々の出願ご
とに作成されてサーバ１０２の審査請求ＤＢ１０２ａに
保存されるもので、文書内のどこに何を配置するといっ
た全体のレイアウトは、文書設計情報（フォーム）とし
てあらかじめ規定されている。また、当該フォームに流
し込まれる要約文や書誌的事項、知財区担当者・開発区
評価者などは、サーバ１０２への抽出後自動もしくは手
動により上述の修正を施されたものである。

【００８２】図示するように、評価表の冒頭には発明の
名称と要約とが表示され、さらに「ＰＶ起動」ボタンを
クリックすることで、当該出願の公開公報全文を表示さ
せることができる。ここでＰＶ（Ｐａｔｅｎｔ Ｖｉｅ
ｗｅｒ）とは、本出願人が社内で運用している特許公報
検索システムの名称である。

【００８３】また、発明の名称や要約の下には複数のセ
クションが設けられている。このセクションとはＬｏｔ
ｕｓ Ｎｏｔｅｓの設計上の用語であって、文書中「セ
クションマーク（下向き矢印もしくは右向き矢印）＋セ
クション名」の直下の、任意に開閉できるようになって
いるエリアをいう。

【００８４】たとえば、図中「知財区担当者」セクショ
ンと「開発区評価者」セクションとは開いているが、セ
クションマークをクリックすることで、セクションを閉
じてその内容が表示されないようにすることができる。
なお、このときセクションマークは下向き矢印から右向
き矢印に変わる。逆に、図中「書誌的事項」セクション
は閉まっているが、同様にセクションマークをクリック
することで、セクションを開いてその内容を表示させる
ことができる。このときセクションマークは右向き矢印
から下向き矢印に変わる。

【００８５】担当者の決定 上記の評価表により発明内容を確認した担当者は、自己
が当該出願の担当者としてふさわしくないと判断したと
きは、自己に代わる担当者を自ら決定し、あるいは自己
の上司にその決定を依頼することができる。なお、自己
が当該出願の担当者として適切であれば、下記の処理は
省略して後述へ進む。

【００８６】ａ）自己に代わる担当者を自ら決定する場
合 図１３は、担当者自身による担当者の変更の手順を示す
フローチャートである。まず、上述のように作業依頼メ
ールにリンクされた一覧から、自己に割り当てられた案
件の評価表（図１２）をオープンし（ステップＳ１６０
１・Ｓ１６０２）、その「編集」ボタンをクリックする
ことにより、当該文書を編集モードすなわち編集可能な
状態にする（ステップＳ１６０３：Ｙｅｓ）。

【００８７】図１４は編集モードの評価表、特にその
「知財区担当者」セクション付近の一例を示す説明図で
ある。図中、「知財区担当者」の項目にある「アドレス
帳より選択」ボタンをクリックすると（ステップＳ１６
０４：Ｙｅｓ）、図１５に示すようなアドレス帳が表示
されるので（ステップＳ１６０５）、自己以外の適切な
担当者を選択して「ＯＫ」ボタンをクリックする（ステ
ップＳ１６０６：Ｙｅｓ）。

【００８８】この担当者の変更にともなって、変更後の
担当者の承認者（具体的にはＧＬ：Ｇｒｏｕｐ Ｌｅａ
ｄｅｒ）が特許共通マスタから取り出され（ステップＳ
１６０７）、表示中の評価表で、「知財区担当者」項目
が上記変更後の担当者、「知財区承認者」項目がその承
認者にそれぞれ置換される（ステップＳ１６０８）。

【００８９】この後「担当者変更」ボタンをクリックす
ると（ステップＳ１６０９：Ｙｅｓ）、変更後の担当者
へ図１０に示したのと同様の作業依頼メールが送信され
る（ステップＳ１６１０）。そして、評価表はその「担
当者」および「承認者」に変更後の担当者と承認者とを
設定の上クローズされる（ステップＳ１６１１・Ｓ１６
１２）。

【００９０】なお、「担当者変更」ボタンを押さずに単
に「保存して戻る」ボタンを押すのみであったときは
（ステップＳ１６０９：Ｎｏ、ステップＳ１６１３：Ｙ
ｅｓ）、評価表への設定とクローズのみが（ステップＳ
１６１１・Ｓ１６１２）、「戻る」ボタンを押すのみで
あったときは（ステップＳ１６０９：Ｎｏ、ステップＳ
１６１３：Ｎｏ、ステップＳ１６１４：Ｙｅｓ）、評価
表のクローズのみが（ステップＳ１６１２）、それぞれ
おこなわれる。

【００９１】また、「保存する」ボタンを押すのみであ
ったときは（ステップＳ１６０９：Ｎｏ、ステップＳ１
６１３：Ｎｏ、ステップＳ１６１４：Ｎｏ、ステップＳ
１６１５：Ｙｅｓ）、評価表にその時点での設定内容を
保存後（ステップＳ１６１６）、続けて編集待ちとなる
（ステップＳ１６０４）。

【００９２】なお、図１１に示した一覧画面で「担当者
変更」ボタンをクリックすることにより、その時点で選
択されている複数の案件（自己が担当者になっているも
のに限る）につき、一括して担当者を変更することもで
きる。

【００９３】ｂ）自己に代わる担当者の決定を上司に依
頼する場合 また、担当者が自己に代わる適切な担当者を選定できな
い場合には、図１４に示した評価表で「担当者変更依
頼」ボタンをクリックして、図１６に示すようなダイア
ログを表示させる。そして、担当者変更の依頼先（通常
は当該担当者の承認者）、適切と思われる担当者や発明
の概要など必要事項を記入して「ＯＫ」ボタンをクリッ
クすると、上記依頼先に図１７に示すような作業依頼メ
ールが送信される。

【００９４】図１８は上記依頼先で上記メールに埋め込
まれたリンクをクリックすると表示される「担当者変更
確定」ビューであり、いずれかの案件をダブルクリック
すれば、当該案件の審査請求評価表を表示させることが
できる。ここで表示される評価表は図１２と同様のもの
であり、依頼先では図１３に示したのと同様の手順で新
たな担当者を決定する。

【００９５】なお、担当者は図１１に示した一覧画面で
「担当者変更依頼」ボタンをクリックすることにより、
その時点で選択されている複数の案件（自己が担当者に
なっているものに限る）につき、一括して担当者の変更
を依頼することができる。また、その依頼先では図１８
に示した一覧画面で「担当者変更」ボタンをクリックす
ることにより、その時点で選択されている複数の案件
（自己が担当者変更依頼先になっているものに限る）に
つき、一括してその担当者を変更することができる。

【００９６】評価者の決定（知財区） 上記のようにして担当者が決定されると、つぎに決定さ
れた担当者は、審査請求評価表に記載されている評価者
が当該出願の審査請求要否を判断すべき者として適切で
あるかどうかを判断する。そして、適切でないと判断し
た場合には評価者の変更をおこなう。

【００９７】図１９は、担当者による評価者の変更の手
順を示すフローチャートである。まず、上述のように作
業依頼メールにリンクされた一覧から、自己に割り当て
られた案件の評価表（図１２）をオープンし（ステップ
Ｓ２２０１・Ｓ２２０２）、その「編集」ボタンをクリ
ックすることにより、当該文書を編集モードすなわち編
集可能な状態にする（ステップＳ２２０３：Ｙｅｓ）。

【００９８】図２０は編集モードの評価表、特にその
「開発区評価者」セクション付近の一例を示す説明図で
ある。図中、「開発区評価者」の項目にある「発明者リ
ストより選択」ボタンをクリックすると（ステップＳ２
２０４：Ｙｅｓ）、図２１に示すような、当該評価表に
設定された発明者のリストが表示される（ステップＳ２
２０５）。また、図２０の評価表で「アドレス帳より選
択」ボタンをクリックすると（ステップＳ２２０４：Ｎ
ｏ、ステップＳ２２０６：Ｙｅｓ）、図１５に示したの
と同様のアドレス帳が表示される（ステップＳ２２０
７）。

【００９９】この発明者リスト、あるいはアドレス帳か
ら適切な評価者を選択してＯＫすると（ステップＳ２２
０８：Ｙｅｓ）、表示中の評価表で、「開発区評価者」
項目が上記変更後の評価者に置換される（ステップＳ２
２０９）。この後「評価依頼」ボタンをクリックすると
（ステップＳ２２１０：Ｙｅｓ）、変更後の評価者へ図
２２に示すような作業依頼メールが送信される（ステッ
プＳ２２１１）。そして、評価表はその「評価者」に変
更後の評価者を設定の上クローズされる（ステップＳ２
２１２・Ｓ２２１３）。

【０１００】なお、「評価依頼」ボタンを押さずに単に
「保存して戻る」ボタンを押すのみであったときは（ス
テップＳ２２１０：Ｎｏ、ステップＳ２２１４：Ｙｅ
ｓ）、評価表への設定とクローズのみが（ステップＳ２
２１２・Ｓ２２１３）、「戻る」ボタンを押すのみであ
ったときは（ステップＳ２２１０：Ｎｏ、ステップＳ２
２１４：Ｎｏ、ステップＳ２２１５：Ｙｅｓ）、評価表
のクローズのみが（ステップＳ２２１３）、それぞれお
こなわれる。

【０１０１】また、「保存する」ボタンを押すのみであ
ったときは（ステップＳ２２１０：Ｎｏ、ステップＳ２
２１４：Ｎｏ、ステップＳ２２１５：Ｎｏ、ステップＳ
２２１６：Ｙｅｓ）、評価表にその時点での設定内容を
保存後（ステップＳ２２１７）、続けて編集待ちとなる
（ステップＳ２２０４）。

【０１０２】（４）評価者の決定と開発区評価 つぎに、図２２の作業依頼メールを受け取った開発区に
おける以後の作業は、発明内容を確認し、評価者を
決定（必要に応じて変更）し、評価者自身が評価をお
こない、さらにその承認者が評価をおこなう、という
手順で進められる。以下、順に説明する。

【０１０３】発明内容の確認 知財区により担当者と評価者とが決定されると、決定さ
れた評価者には上述のように、図２２に示したような作
業依頼メールが送信される。図示するように、上記作業
とは具体的には審査請求の要否の判断であって、メール
本文には依頼の趣旨のみが示され、作業に必要な情報は
本文内に埋め込まれたリンクを介して参照するようにな
っている。

【０１０４】図２３は、上記リンク（図中アイコンで示
される）をクリックすると表示される「開発区評価」ビ
ュー、また図２４は、上記ビューでいずれかの案件をダ
ブルクリックすると表示される審査請求評価表の一例を
示す説明図である。

【０１０５】評価者の決定（開発区） 評価者は、同図の評価表により発明内容を確認し、自己
が当該出願の審査請求要否を判断するのにふさわしくな
いと判断したときは、評価者の変更を知財区の担当者に
依頼することができる。まず、同図の評価表を編集モー
ドにするとともに、その「開発区評価者」セクションを
開く。

【０１０６】図２５は編集モードの評価表、特にその
「開発区評価者」セクション付近の一例を示す説明図で
ある。図２０に示した「開発区評価者」セクション（担
当者や評価者の変更に際して、知財区担当者に対して表
示されたもの）とは、新たに「評価者再設定依頼」ボタ
ンが設けられている点で異なっている。このボタンをク
リックすると、評価者の再設定（変更）を依頼する内容
の電子メールが担当者に送信され、これによりいったん
処理を開発区から知財区に差し戻すことができる。

【０１０７】なお、評価者は図２３に示した一覧画面で
「評価者再設定」ボタンをクリックすることにより、そ
の時点で選択されている複数の案件（自己が評価者にな
っているものに限る）につき、一括して評価者の変更を
依頼することができる。また、再設定依頼を受けた知財
区の担当者は、図１９に示したのと同様の手順で他の適
切な評価者を選定する。

【０１０８】評価者による評価 また、自己が当該出願の審査請求要否を判断するのに適
切であるときは、評価者は上記を省略して直接評価に
入る。図２６は、開発区の評価者による評価の手順を示
すフローチャートである。

【０１０９】まず、上述のように作業依頼メールにリン
クされた一覧から、自己に割り当てられた案件の評価表
（図２４）をオープンし（ステップＳ２９０１・Ｓ２９
０２）、その「編集」ボタンをクリックすることによ
り、当該文書を編集モードすなわち編集可能な状態にす
る（ステップＳ２９０３：Ｙｅｓ）。

【０１１０】そして、その「開発区審査請求要否評価」
セクション内の「評価」ボタンをクリックすると（ステ
ップ２９０４：Ｙｅｓ）、審査請求の要否を選択してそ
れぞれの理由を入力するためのダイアログが開く。この
ダイアログで必要事項を選択・入力してＯＫすると、表
示中の評価表で、「審査請求要」「審査請求否」のいず
れか選択した側に入力したその理由が表示される（ステ
ップＳ２９０５）。

【０１１１】この後「審査・承認依頼」ボタンをクリッ
クして（ステップＳ２９０６：Ｙｅｓ）、図２７に示す
ダイアログから適切な承認者を選択しＯＫすると（ステ
ップＳ２９０７）、当該承認者に図２８に示すような作
業依頼メールが送信される（ステップＳ２９０８）。そ
して、評価表はその「評価結果」に上記要否とその理
由、「承認者」に上記承認者をそれぞれ設定の上クロー
ズされる（ステップＳ２９０９・Ｓ２９１０）。

【０１１２】なお、「審査・承認依頼」ボタンを押さず
に単に「保存して戻る」ボタンを押すのみであったとき
は（ステップＳ２９０６：Ｎｏ、ステップＳ２９１１：
Ｙｅｓ）、評価表への設定とクローズのみが（ステップ
Ｓ２９０９・Ｓ２９１０）、「戻る」ボタンを押すのみ
であったときは（ステップＳ２９０６：Ｎｏ、ステップ
Ｓ２９１１：Ｎｏ、ステップＳ２９１２：Ｙｅｓ）、評
価表のクローズのみが（ステップＳ２９１０）、それぞ
れおこなわれる。

【０１１３】また、「保存する」ボタンを押すのみであ
ったときは（ステップＳ２９０６：Ｎｏ、ステップＳ２
９１１：Ｎｏ、ステップＳ２９１２：Ｎｏ、ステップＳ
２９１３：Ｙｅｓ）、評価表にその時点での設定内容を
保存後（ステップＳ２９１４）、続けて編集待ちとなる
（ステップＳ２９０４）。

【０１１４】なお、図２３に示した一覧画面で「一括審
査・承認依頼」ボタンをクリックすれば、その時点で選
択されている複数の案件（自己が評価者になっているも
のに限る）につき、一括して承認を依頼することもでき
る。ちなみに「審査」と「承認」の区別であるが、承認
とは最終の審査のことであって、同一部門内で三人以上
が順次評価に関わる場合、最初の一人が評価者、最後の
一人が承認者、他の者は審査者という関係になる。しか
しここでは説明の便宜上、開発区で評価をおこなうのは
評価者と承認者の二人のみ、すなわち審査者は存在しな
いものとする。

【０１１５】承認者による評価 上述のように、図２７に示したダイアログで選択された
承認者には、図２８に示したような作業依頼メールが送
信される。図示するように、メール本文には依頼の趣旨
のみが示され、作業に必要な情報は本文内に埋め込まれ
たリンクを介して参照するようになっている。

【０１１６】図２９は、上記リンク（図中アイコンで示
される）をクリックすると表示される「開発区審査・承
認中」ビューの一例を示す説明図である。この一覧画面
でいずれかの案件をクリックすると、図２４に示したの
と同様の評価表が表示される。ただしその「開発区審査
請求要否評価」セクションには、前段の評価者による評
価結果が記述されている（前段の評価者による評価が
「要」であれば、図中「審査請求要」以下にその理
由、「否」であれば「審査請求否」以下にその理由が
それぞれ表示される）。

【０１１７】図３０は、開発区の承認者による評価の手
順を示すフローチャートである。まず、上述のように作
業依頼メールにリンクされた一覧から、自己に割り当て
られた案件の評価表（図２４）をオープンし（ステップ
Ｓ３３０１・Ｓ３３０２）、その「編集」ボタンをクリ
ックすることにより、当該文書を編集モードすなわち編
集可能な状態にする（ステップＳ３３０３：Ｙｅｓ）。

【０１１８】そして、前段の評価をやり直させる必要が
特になければ、承認者はその「承認」ボタンをクリック
し（ステップＳ３３０４：Ｙｅｓ）、続いて表示される
図３１のようなダイアログで「要」「否」のいずれかを
選択する（ステップＳ３３０５）。

【０１１９】そして、承認者の結論が要否いずれである
にせよ、この後図３２に示すような承認通知メールが評
価者に送信されるとともに（ステップＳ３３０６）、知
財区の担当者に対して図３３に示すような作業依頼メー
ルが送信される（ステップＳ３３０７）。そして、評価
表は承認者や承認日付、および承認者の評価結果を設定
の上クローズされる（ステップＳ３３０８・Ｓ３３０
９）。

【０１２０】なお、図２９に示した一覧画面で「一括承
認」ボタンをクリックすれば、その時点で選択されてい
る複数の案件（自己が承認者になっているものに限る）
につき、一括して承認することもできる。

【０１２１】また、前段の評価をやり直させる必要があ
るときは、承認者は図２４に示した評価表で「否認」ボ
タンをクリックするので（ステップＳ３３０４：Ｎｏ、
ステップＳ３３１０：Ｙｅｓ）、評価者に対して図３４
に示すような否認通知メールを送信し（ステップＳ３３
１１）、否認者と否認日付とを設定の上（ステップＳ３
３１２）評価表をクローズする（ステップＳ３３０
９）。承認者により評価を否認された評価者は、再度評
価をやり直さなければならない。

【０１２２】（５）知財区評価 つぎに、図３３の作業依頼メールを受け取った知財区に
おける以後の作業は、担当者が評価をおこない、さ
らにその承認者が評価をおこなう、という手順で進めら
れる。この手順は基本的には開発区の評価者・承認者に
よる評価の手順と同一なので、以下では差異を中心に簡
単に説明する。

【０１２３】担当者による評価 開発区での評価が終わると、上述のように知財区の担当
者には図３３に示したような作業依頼メールが送信され
る。図示するように、メール本文には依頼の趣旨のみが
示され、作業に必要な情報は本文内に埋め込まれたリン
クを介して参照するようになっている。

【０１２４】図３５は、上記リンク（図中アイコンで示
される）をクリックすると表示される「知財区評価」ビ
ュー、また図３６は、上記ビューでいずれかの案件をダ
ブルクリックすると表示される審査請求評価表の一例を
示す説明図である。

【０１２５】同図に示す「知財区審査請求要否評価」セ
クションで「評価」ボタンをクリックすると、あらかじ
め用意された審査請求の要否とその理由の組が複数表示
されるので、いずれかを選択してＯＫする。また、「開
発区と同一評価」ボタンをクリックすると、原則として
開発区でなされた評価と同一の評価をすることができる
（すなわち、開発区での評価を踏襲することができ
る）。

【０１２６】なお、いずれにせよ結論が要となる場合に
は、審査請求に際して補正や分割、あるいは早期審査の
手続きをおこなうかどうかを上記セクションで設定す
る。なお、補正を「有り」に設定するには、「ファイル
指定」ボタンにより補正内容を記入したファイルを指定
するか、あるいは「補正連絡書添付」欄に直接補正内容
を記入するかしなければならない。また、補正があると
きはそれにより増加あるいは減少する請求項の個数も記
入しなければならない。

【０１２７】そして、「評価」「開発区と同一評価」の
いずれにより評価をおこなった場合も、また結論が
「要」「否」のいずれになった場合も、最後に「審査・
承認依頼」ボタンをクリックすることで、後段の承認者
に図３７に示すような作業依頼メールを送信した時点
で、担当者の作業は終了となる。

【０１２８】承認者による評価 このようにして担当者による評価が終わると、上述のよ
うにその上司である承認者に対し、図３７に示したよう
な作業依頼メールが送信される。図示するように、メー
ル本文には依頼の趣旨のみが示され、作業に必要な情報
は本文内に埋め込まれたリンクを介して参照するように
なっている。

【０１２９】図３８は、上記リンク（図中アイコンで示
される）をクリックすると表示される「知財区審査・承
認中」ビューの一例を示す説明図である。この一覧画面
でいずれかの案件をダブルクリックすると、図３６に示
したのと同様の評価表が表示されるので（ただしその
「評価結果」項目には前段の担当者による評価結果が表
示されている）、「承認」ボタンをクリックすれば図３
９に示すような承認通知メールが、「否認」ボタンをク
リックすれば図４０に示すような否認通知メールが、そ
れぞれ前段の担当者に送信される。承認者に否認された
場合担当者が評価をやり直さなければならないことは、
開発区で否認があった場合と同様である。

【０１３０】評価完了までのスケジュールについて なお、ここで上述（２）〜（５）の作業のスケジュール
についてまとめておく。知財区の審査請求管理者は、上
述（２）のデータの修正と平行して（あるいはそれに先
立って）、今回の定期評価における作業スケジュールを
決定する。なお、決定されたスケジュールは審査請求Ｄ
Ｂ１０２ａ内の「スケジュールマスタ」に登録され、審
査請求管理者はいつでも閲覧・変更することができる。

【０１３１】図４１は、スケジュールマスタに登録され
たスケジュールの一例を示す説明図である。同図に示す
ように、このスケジュールとは具体的には各段階におけ
る処理のデッドラインであって、たとえば知財区でのデ
ータの修正期限（上述（２））が２００１年５月２３
日、知財区での担当者と評価者の決定期限（同（３））
が同２８日、開発区での評価期限（同（４））が同６月
１１日、知財区での評価期限（同（５））が同１８日、
のように、それぞれ年月日で設定される。

【０１３２】そして、上述（２）〜（５）の各作業はこ
のスケジュールにしたがって進められ、期限になっても
なされるべき処理がなされていないときは、強制的につ
ぎの段階へ処理を移行したり、あるいは当該処理を怠っ
ている者に催促のメールを送付したりといった措置が自
動的に取られる。以下、具体例により説明する。

【０１３３】ａ）担当者や評価者の決定が遅れていると
き あらかじめ規定された決定期限になっても担当者や評価
者の決定されていない案件があるときは、当該案件はデ
フォルトの設定のまま、強制的に知財区から開発区に移
管される。

【０１３４】図４２は、知財区での決定期限を徒過した
案件についておこなわれる、開発区への移管の手順を示
すフローチャートである。知財区での決定期限を経過し
た時点で（ステップＳ５５０１：Ｙｅｓ）、まず現在注
目しているのが審査請求ＤＢ１０２ａ中何番目の評価表
であるかを示す変数ｎを初期化する（ステップＳ５５０
２）。つぎにｎ番目の評価表をチェックして、評価者が
設定されていれば（ステップＳ５５０３：Ｙｅｓ、ステ
ップＳ５５０４：Ｙｅｓ）、当該評価者に対して図２２
に示した作業依頼メールを送信する（ステップＳ５５０
５）。

【０１３５】また、評価者が設定されていなければ（ス
テップＳ５５０４：Ｎｏ）、代わりに評価表に設定され
ている知財区担当者とその承認者に対して図４３に示す
ような催促メールを送信する（ステップＳ５５０６）。
その後ｎをインクリメントして（ステップＳ５５０
７）、上記処理を終えていない評価表がある限り（ステ
ップＳ５５０３：Ｙｅｓ）、同様の処理を繰り返す。

【０１３６】ｂ）開発区での評価が遅れているとき あらかじめ規定された評価期限の数日前（具体的には３
日前）になっても開発区での評価の終わっていない案件
があるときは、その評価者および承認者に電子メールで
催促がなされ、催促にもかかわらず評価のなされない案
件については、上記期限を徒過した時点で強制的に開発
区から知財区に移管される。

【０１３７】図４４は、開発区での評価期限直前におこ
なわれる評価者および承認者への催促の手順を示すフロ
ーチャートである。開発区での評価期限まで３日となっ
た時点で（ステップＳ５７０１：Ｙｅｓ）、まず現在注
目しているのが審査請求ＤＢ１０２ａ中何番目の評価表
であるかを示す変数ｎを初期化する（ステップＳ５７０
２）。

【０１３８】つぎにｎ番目の評価表をチェックして、評
価者による評価結果が記入されていない、あるいは評価
結果は記入されているが承認者による承認がない場合に
は（ステップＳ５７０４：Ｎｏ）、評価者およびその承
認者に対して図４５に示すような催促メールを送信する
（ステップＳ５７０５）。その後ｎをインクリメントし
て（ステップＳ５７０６）、上記処理を終えていない評
価表がある限り（ステップＳ５７０３：Ｙｅｓ）、同様
の処理を繰り返す。

【０１３９】また、図４６は開発区での評価期限を徒過
した案件についておこなわれる、知財区への移管の手順
を示すフローチャートである。開発区での評価期限を経
過した時点で（ステップＳ５９０１：Ｙｅｓ）、まず現
在注目しているのが審査請求ＤＢ１０２ａ中何番目の評
価表であるかを示す変数ｎを初期化する（ステップＳ５
９０２）。

【０１４０】つぎにｎ番目の評価表をチェックして、評
価者による評価結果が記入されていれば（ステップＳ５
９０４：Ｙｅｓ）、知財区の担当者に対して図３３に示
した作業依頼メールを送信する（ステップＳ５９０
５）。

【０１４１】また、評価者による評価結果が記入されて
いなければ（ステップＳ５９０４：Ｎｏ）、その評価結
果として「仮要」を設定した後（ステップＳ５９０
６）、評価者および承認者に対して図４７に示すよう
な、仮要を自動設定した旨の通知メールを送信する（ス
テップＳ５９０７）。

【０１４２】そして、この場合も知財区の担当者に対し
て、図３３に示した作業依頼メールを送信する（ステッ
プＳ５９０５）。その後ｎをインクリメントして（ステ
ップＳ５９０８）、上記処理を終えていない評価表があ
る限り（ステップＳ５９０３：Ｙｅｓ）、同様の処理を
繰り返す。

【０１４３】ｃ）知財区での評価が遅れているとき あらかじめ規定された評価期限の数日前（具体的には３
日前）になっても知財区での評価の終わっていない案件
があるときは、その担当者および承認者に電子メールで
催促がなされ、催促にもかかわらず評価のなされない案
件については、上記期限を徒過した時点でさらに同様の
催促がなされる。

【０１４４】図４８は、知財区での評価期限直前におこ
なわれる担当者および承認者への催促の手順を示すフロ
ーチャートである。同図の手順は基本的に、図４４に示
した開発区の評価者および承認者に対する催促手順と同
一であるのでここでは繰り返さない。なお、図４９は作
業を懈怠している知財区の担当者およびその承認者に送
信される、催促メールの一例を示す説明図である。

【０１４５】また、図５０は知財区での評価期限を経過
した時点でおこなわれる、評価完了処理の手順を示すフ
ローチャートである。この評価完了処理には、以下で説
明するように評価が終わっていない案件についての催促
のほか、最終的に審査請求要とされた案件についての、
審査請求に要する費用の算出が含まれる。

【０１４６】知財区での評価期限を経過した時点で（ス
テップＳ６３０１：Ｙｅｓ）、まず現在注目しているの
が審査請求ＤＢ１０２ａ中何番目の評価表であるかを示
す変数ｎを初期化する（ステップＳ６３０２）。つぎに
ｎ番目の評価表をチェックして、担当者による評価結果
が記入されていない、あるいは評価結果は記入されてい
るが承認者による承認がない場合には（ステップＳ６３
０４：Ｎｏ）、担当者およびその承認者に対して、速や
かに処理を完了させるべき旨の催促メールを送信する
（ステップＳ６３０５）。

【０１４７】また、評価表に担当者の評価結果が記入さ
れ、かつその承認者による承認も済んでいる場合には
（ステップＳ６３０４：Ｙｅｓ）、最終的な結論が「審
査請求要」である場合に限り（ステップＳ６３０６：Ｙ
ｅｓ）、後述する手順にしたがってその審査請求にかか
る費用を算出する（ステップＳ６３０７）。その後ｎを
インクリメントして（ステップＳ６３０８）、上記処理
を終えていない評価表がある限り（ステップＳ６３０
３：Ｙｅｓ）、同様の処理を繰り返す。

【０１４８】つぎに、図５１は図５０中、審査請求費用
の算出の手順を詳細に示すフローチャートである。費用
算出の手順は、注目している案件の審査請求が自社によ
りなされるものであるか、代理人によりなされるもので
あるかにより異なる。

【０１４９】自ら審査請求をおこなう場合とは（ステッ
プＳ６４０１：Ｙｅｓ）、後述のように審査請求に際し
て補正や分割などの手続きを取らない場合であり、費用
は特許庁に支払う手数料のみとなる。

【０１５０】まず、評価表から請求項数を読み出すとと
もに（ステップＳ６４０２）、あらかじめ用意されてい
る金額テーブルから一出願あたりの基本料金と一請求項
あたりの基準金額とを読み出して（ステップＳ６４０
３）、基本料金に請求項数分の基準金額を足しあわせる
ことで、上記手数料を算出する（ステップＳ６４０
４）。そして、この金額を評価表の「予想金額」に設定
する（ステップＳ６４０５）。

【０１５１】これに対し、審査請求を自社ではおこなわ
ない場合とは（ステップＳ６４０１：Ｎｏ）、後述のよ
うに審査請求に際して補正や分割などが必要な場合で、
代理人に一切の手続きを委任する場合であるので、上記
のほか代理人に支払う手数料が必要である。

【０１５２】まず、評価表から請求項数のほか、補正に
よる請求項の増加数、明細書全文訂正の有無、誤記訂正
がある図面の数など、代理人手数料の額に影響する諸要
素を読み出す（ステップＳ６４０６）。つぎに、上記金
額テーブルから一出願あたりの基本料金と一請求項あた
りの基準金額、および上記各要素に応じた標準（代理
人）手数料額を読み出し（ステップＳ６４０７）、これ
らから特許庁に支払う手数料と代理人に支払う手数料と
を合わせた合計を算出する（ステップＳ６４０８）。そ
して、この金額を同様に評価表の「予想金額」に設定す
る（ステップＳ６４０５）。

【０１５３】（６）国内特実マスタ１０１ａへのデータ
の書き戻し 上記のようにして開発区・知財区による評価が完了する
と、つぎにサーバ１０２の審査請求ＤＢ１０２ａからメ
インフレーム１０１の国内特実マスタ１０１ａへのデー
タの書き戻しをおこなう。

【０１５４】図５２は、サーバ１０２からメインフレー
ム１０１へのデータの書き戻し（コピー）の手順を示す
フローチャートである。サーバ１０２上で動作するソフ
トウェアは、あらかじめ設定された日、具体的には知財
区における評価期限を経過すると（ステップＳ６５０
１：Ｙｅｓ）、現在注目しているのが審査請求ＤＢ１０
２ａ中何番目の評価表であるかを示す変数ｎを初期化す
る（ステップＳ６５０２）。なお、ここではデータの書
き戻しを知財区評価期限におこなうようにしているが、
当該期限以降であればどの時点であってもよい。

【０１５５】つぎに、ｎ番目の評価表（もしあれば）に
設定されたデータをＣＳＶ形式の転送用ファイルに順次
書き込み（ステップＳ６５０３：Ｙｅｓ、ステップＳ６
５０４）、ｎをインクリメントして（ステップＳ６５０
５）、すべての評価表につき上記処理を終えた時点で
（ステップＳ６５０３：Ｎｏ）、上記転送用ファイルを
所定のプロトコルにしたがってメインフレーム１０１に
送信する（ステップＳ６５０６）。そして、メインフレ
ーム１０１では受信した転送用ファイルにもとづき、国
内特実マスタ１０１ａのデータを更新する（ステップＳ
６５０７）。

【０１５６】なお、上記の処理は実際には、メインフレ
ーム１０１ともサーバ１０２とも異なる第３のコンピュ
ータ（図示せず）上で動作する、ＩＢＭ社のミドルウェ
ア「ＭＱ」によりおこなう。もっとも、サーバ１０２が
上記処理を担当しないのはもっぱらシステム構築上の都
合によるものであるので、ここでは説明の便宜上、上記
処理はサーバ１０２によりおこなうものとして説明す
る。

【０１５７】なお、基本的にメインフレーム１０１上の
国内特実マスタ１０１ａへの書き戻しは、上述（１）の
読み出しとちょうど反対に、審査請求ＤＢ１０２ａ内の
評価表から必要事項を抜き出してＣＳＶファイルを作成
・転送すればよいのであるが、特に取下げとみなされた
国内優先権主張の基礎出願については、図４で上述のよ
うにそもそも審査請求評価表が作成されないため、別途
配慮が必要である。

【０１５８】図５３は、みなし取下げとなった出願につ
きメインフレーム１０１への書き戻し時におこなわれる
データの修正の手順を示すフローチャートである。同図
に示す処理は、図５２に示した書き戻しの手順中、すべ
ての評価表のデータを転送用ファイルに記入し終えた直
後（当該ファイルをメインフレーム１０１に送信する直
前、と言ってもよい）におこなわれる。

【０１５９】まず、現在注目しているのが退避ファイル
中何番目の出願であるかを示す変数ｍを初期化する（ス
テップＳ６６０１）。そして、退避ファイルにｍ番目の
出願のデータがあれば（ステップＳ６６０２：Ｙｅ
ｓ）、当該出願の現在の状態を「出願後公開前」から
「みなし取下げ」に置換の上（ステップＳ６６０３）、
転送用ファイルに順次書き込む（ステップＳ６６０
４）。さらに、退避ファイル中のデータを削除した後
（ステップＳ６６０５）、ｍをインクリメントして（ス
テップＳ６６０６）、退避ファイル中のすべての出願に
つき上記処理を繰り返す。

【０１６０】なお、メインフレーム１０１への書き戻し
の時点でまだ退避ファイルに残っている出願は、結局開
発区・知財区による審査請求要否の検討がなされなかっ
たものなので、上記の手順で国内特実マスタ１０１ａに
「みなし取下げ」を設定するということは、それらの出
願が評価の対象から除外されていた事実を設定すること
と意味的に同じである。

【０１６１】（７）審査請求 開発区および知財区による評価を経て、最終的に審査請
求が必要と判断された出願については、この後主として
知財区の審査請求管理者のもとで、特許庁に対する審査
請求の手続きが取られる。

【０１６２】審査請求は、代理人に依頼しておこなわ
せる場合と（審査請求依頼）、特許庁と接続された専
用端末１０５により自らおこなう場合（自社審査請求）
とがある。そして、ある出願が上記いずれの扱いになる
かは、その審査請求と同時に補正・分割あるいは早期審
査の手続きを取るか否かにより機械的に決定される。

【０１６３】すなわち図３６に示した評価表において、
知財区の担当者が補正・分割あるいは早期審査のいずれ
かに「有り」を設定していた場合に、上記の扱いとな
り、いずれも「無し」に設定していた場合に、上記の
扱いとなる。以下、順に説明する。

【０１６４】審査請求依頼 図５４は、代理人に対する審査請求依頼の手順を示すフ
ローチャートである。知財区の審査請求管理者は、サー
バ１０２の審査請求ＤＢ１０２ａを開いて、審査請求依
頼の対象案件すなわち知財区により補正・分割あるいは
早期審査が必要とされた案件を表示させる（ステップＳ
６７０１）。図５５は、審査請求ＤＢ１０２ａにおいて
「事務所依頼」ボタンをクリックすると表示される、
「事務所依頼」ビューの一例を示す説明図である。

【０１６５】そして、一覧中のいずれかの案件を選択し
て「事務所依頼」ボタンをクリックすると（ステップＳ
６７０２：Ｙｅｓ、ステップＳ６７０３：Ｙｅｓ）、選
択された案件の評価表に設定されている代理人ごとに、
図５６に示すような、審査請求手続きを委任する旨の作
業依頼メールが作成・送信される（ステップＳ６７０
４）。なお、何も選択せずに上記ボタンを押すと（ステ
ップＳ６７０３：Ｎｏ）、「依頼する案件を選択してく
ださい」などのエラー表示がなされる（ステップＳ６７
０５）。

【０１６６】さらに、上記で選択された案件の代理人ご
とに、図５７に示すような手続き依頼一覧が作成され
（ステップＳ６７０６）、この依頼一覧と、各案件のデ
ータのうち代理人の作業に必要なものとが、サーバ１０
２上の審査請求ＤＢ１０２ａからＳＰのサーバ１０６上
の事務所ＤＢ１０６ａにコピーされる（ステップＳ６７
０７）。

【０１６７】なお、図５６に示した作業依頼メールに埋
め込まれたリンク（図中アイコンで示される）をクリッ
クすると、事務所ＤＢ１０６ａ上にコピーされた図５７
の依頼一覧が表示され、さらにこの依頼一覧に埋め込ま
れたリンク（図中アイコンで示される）をクリックする
と、同じく事務所ＤＢ１０６ａ上にコピーされた各案件
のデータにもとづいて、図５８に示すような個々の案件
の依頼書が作成・表示される。このように、代理人は受
信した作業依頼メールからリンクをたどってゆくこと
で、必要なデータをいつでも参照することができる。

【０１６８】自社審査請求 つぎに図５９、図６０、図６１および図６２は自社によ
る審査請求の手順を示すフローチャートである。図５９
は審査請求書の作成手順、図６０は専用端末１０５にお
ける審査請求手順、図６１は審査請求評価表への審査請
求日の設定手順、また図６２は審査請求完了後の代理人
への通知手順をそれぞれ示している。

【０１６９】まず知財区の審査請求管理者は、サーバ１
０２の審査請求ＤＢ１０２ａを開いて、自社審査請求の
対象案件すなわち知財区により補正・分割あるいは早期
審査のいずれも不要とされた案件を表示させる（図５９
ステップＳ７２０１）。図６３は、審査請求ＤＢ１０２
ａにおいて「自社手続き分」ボタンをクリックすると表
示される、「自社審査請求」ビューの一例を示す説明図
である。

【０１７０】そして、一覧中「自社審査請求待ち」以下
のいずれかの案件を選択して「ＦＤ作成」ボタンをクリ
ックすると（ステップＳ７２０２：Ｙｅｓ、ステップＳ
７２０３：Ｙｅｓ）、ＦＤのセット待ちとなる。なお、
「自社審査請求待ち」以外の案件を選択したり、あるい
は何も選択せずに上記ボタンを押すと（ステップＳ７２
０３：Ｎｏ）、「ＦＤはすでに作成されています」「Ｆ
Ｄを作成する案件を選択してください」などのエラー表
示がなされる（ステップＳ７２０４）。

【０１７１】そして、ＦＤドライブにＦＤを挿入すると
（ステップＳ７２０５：Ｙｅｓ）、現在注目しているの
が何番目の案件であるかを示す変数ｎが初期化され（ス
テップＳ７２０６）、選択されたうちｎ番目の案件の評
価表から審査請求書の作成に必要な事項、具体的には出
願番号、請求項数、請求人識別番号および代理人が読み
出される（ステップＳ７２０８）。

【０１７２】そして、これらのデータからＨＴＭＬ形式
の審査請求書が作成され（ステップＳ７２０９）、ＦＤ
に出力される（ステップＳ７２１０）。その後ｎがイン
クリメントされ（ステップＳ７２１１）、選択したすべ
ての案件につき上記処理が繰り返される。

【０１７３】この後上記ＦＤは専用端末１０５に挿入さ
れ（図６０ステップＳ７３０１：Ｙｅｓ）、ＦＤ内のす
べての審査請求書が読み出される（ステップＳ７３０
２）。そして、読み出された審査請求書のうち所望のも
のを選択して「発送」ボタンをクリックすると（ステッ
プＳ７３０３：Ｙｅｓ、ステップＳ７３０４：Ｙｅ
ｓ）、審査請求書を特許庁形式に変換の上（ステップＳ
７３０５）、特許庁に対して送信する（ステップＳ７３
０６）。

【０１７４】その後特許庁からプルーフが返信されてく
るのを待ち、プルーフを受信すると（ステップＳ７３０
８：Ｙｅｓ）、当該プルーフをＦＤに出力する（ステッ
プＳ７３０９）。なお、どの案件も選択せずに「発送」
ボタンを押すと（ステップＳ７３０４：Ｎｏ）、「審査
請求する出願を選択してください」などのエラー表示が
なされる（ステップＳ７３０７）。

【０１７５】プルーフの格納されたＦＤは、上記専用端
末１０５から再び審査請求ＤＢ１０２ａにアクセス可能
な端末に戻され（図６１ステップＳ７４０１：Ｙｅ
ｓ）、まず現在注目しているのがＦＤ内の何番目のプル
ーフであるかを示す変数ｎが初期化される（ステップＳ
７４０２）。そしてｎ番目のプルーフがあれば（ステッ
プＳ７４０３：Ｙｅｓ）、つぎに現在注目しているのが
プルーフ内の何番目の出願であるかを示す変数ｍが初期
化される（ステップＳ７４０４）。

【０１７６】そしてｎ番目のプルーフのｍ番目の出願に
ついて（なお、周知のようにプルーフには審査請求書の
提出された複数の出願が記載されている）、その評価表
を審査請求ＤＢ１０２ａから検索し（ステップＳ７４０
６）、プルーフに記述された「提出日」を当該評価表の
「審査請求日」に設定する（ステップＳ７４０７）。

【０１７７】その後ｍをインクリメントして（ステップ
Ｓ７４０８）、プルーフ内の全出願につき審査請求日を
設定し終えると（ステップＳ７４０５：Ｎｏ）、ｎをイ
ンクリメントして（ステップＳ７４０９）、ＦＤ内の全
プルーフにつき上記処理を繰り返す。

【０１７８】そして審査請求管理者は、サーバ１０２の
審査請求ＤＢ１０２ａを開いて、図６３に示したように
自社審査請求の対象案件を一覧表示させ（図６２ステッ
プＳ７５０１）、一覧中「自社ＦＤ作成済み」以下のい
ずれかの案件を選択して「審査請求完了」ボタンをクリ
ックする（ステップＳ７５０２：Ｙｅｓ、ステップＳ７
５０３：Ｙｅｓ）。

【０１７９】なお、「自社ＦＤ作成済み」以外の案件を
選択したり、あるいは何も選択せずに上記ボタンを押す
と（ステップＳ７５０３：Ｎｏ）、「まだ審査請求のな
されていない案件です」「すでに完了しています」など
のエラーメッセージが表示される（ステップＳ７５０
４）。

【０１８０】つぎに、選択された案件の評価表に、当該
出願につき審査請求がなされたことを示す情報が設定さ
れるとともに（ステップＳ７５０５）、そこに設定され
た代理人が読み出される（ステップＳ７５０６）。そし
て、当該代理人のメールアドレスが特許共通マスタから
取得され（ステップＳ７５０７）、このアドレスに対し
て図６４に示すような、審査請求の完了を通知する内容
の電子メールが送信される（ステップＳ７５０８）。

【０１８１】なお、審査請求書は作成されたものの特許
庁へのその送信がなされていなかった、という事態を避
けるため、審査請求書作成後一定期間（具体的には１０
日間）を経過してもプルーフの受信できていない案件が
あれば、審査請求管理者に警告をおこなうようにする。

【０１８２】その出願につき審査請求書が作成されてい
るかどうか、プルーフが受信できているかどうかといっ
た各出願の状態（ステータス）は、後述のように状態区
分コードとして審査請求評価表に保持されているので、
審査請求ＤＢ１０２ａ内の各評価表を定期的にチェック
して、ＦＤ作成後放置されているものがあれば審査請求
管理者にメールで通知する。

【０１８３】（８）各種文書の異同について なお、上述した審査請求ワークフローでは互いに類似し
た種々の文書が使用されるので、最後に主なものについ
て、その異同をまとめておく。上記ワークフローで使用
される文書には、大別して各作業者に送付される文書
と、サーバ１０２に存在して各作業者から参照・編集
される文書とがあり、の主なものが上述の作業依頼メ
ール、の主なものが上述の審査請求評価表である。

【０１８４】作業依頼メール 審査請求管理者や知財区の担当者・承認者、あるいは開
発区の評価者・承認者それぞれに送付される作業依頼メ
ールは、依頼内容が異なるだけで、いずれもほぼ同様の
スタイルである。メール本文の末尾には、上述のように
審査請求ＤＢ１０２ａ内の文書へのリンク（その位置情
報、と言ってもよい）が埋め込まれ、各人の作業に必要
な情報を即座に閲覧できるようになっている。

【０１８５】なお、本文中の文章はあらかじめサーバ１
０２に保持されている依頼文（定型文）の中からいずれ
かを選択の上、スケジュールマスタに設定された作業期
限をはめ込むことで作成されるが、使用する依頼文と期
限とは一連の作業がどの段階まで終了しているかにより
決定される。そして、ある出願につき処理がどこまで進
んでいるかは、その評価表内に「状態区分コード」とし
て保持されている。

【０１８６】図６５は、各々の状態区分コードとその意
味とをまとめた表である。たとえば、知財区の担当者が
図２０に示した評価表で「評価依頼」ボタンをクリック
した結果、あるいは知財区における担当者および評価者
の決定期限を徒過した結果、開発区の評価者に図２２に
示した作業依頼メールが送信された時点で、状態区分コ
ードは「２ｘ」から「３ｘ」に変更される。

【０１８７】同様に、開発区の承認者が図２４に示した
評価表で「承認」ボタンをクリックした結果、あるいは
開発区における評価期限を徒過した結果、知財区の担当
者に図３３に示した作業依頼メールが送信された時点
で、状態区分コードは「３ｘ」から「４ｘ」に変更され
る。

【０１８８】また、知財区における評価期限を経過した
時点で、審査請求要かつその請求に際して補正・分割な
どが必要と判断されたもの、すなわち審査請求を代理人
に依頼するものについては状態区分コードが「４ｘ」か
ら「６ｘ」に、審査請求要だが補正・分割などはいずれ
も不要と判断されたもの、すなわち審査請求を自社でお
こなうものについては状態区分コードが「４ｘ」から
「７ｘ」に、それぞれ変更される。

【０１８９】この状態区分コードを参照することで、つ
ぎは誰にどんな作業を依頼すべきかが分かるので、複数
の依頼文の中から当該作業を依頼する内容のものを選択
することができる。また、その作業期限はスケジュール
マスタから取得することができるので、これを上記依頼
文の適切な位置にはめ込むことで、上述した種々の作業
依頼メールを作成することができる。

【０１９０】審査請求評価表 審査請求評価表は、上述のように各出願につき作成され
てサーバ１０２で公開されるものであるが、状態区分コ
ードによってその表示形態が異なり、また参照に加えて
編集が可能であるかどうかも異なっている。

【０１９１】ａ）表示形態の差異 図１２、図２４あるいは図３６に示した評価表を比較す
れば分かるように、評価の各段階で各作業者に対して表
示される評価表は必ずしも同一ではない。もっとも、評
価表の冒頭にある発明の名称や要約などは常に（誰に対
しても）表示されており、異なるのはその下のセクショ
ン部分である。

【０１９２】図６６は、審査請求評価表中の各セクショ
ンの、各段階におけるデフォルトでの表示形態をまとめ
た表である。図中、マル印はセクションが開いた状態で
表示されることを示し、三角印はセクションが閉じた状
態で表示されることを示し、バツ印はセクションそのも
のが表示されない（「セクションマーク＋セクション
名」さえも表示されない）ことを示している。

【０１９３】たとえば図１２に示した評価表は、知財区
の担当者と開発区の評価者とを決定する局面（状態区分
コード＝２ｘ）で表示されるものであるが、図６６の通
り初期状態では「書誌的事項」セクションが閉、「知財
区担当者」「開発区評価者」セクションが開の状態で表
示され、「開発区審査請求要否評価」「知財区審査請求
要否評価」セクションはいずれも表示されていない。

【０１９４】また図２４に示した評価表は、開発区にお
ける評価の局面（状態区分コード＝３ｘ）で表示される
ものであるが、上記と異なり「知財区担当者」「開発区
評価者」セクションは閉の状態で表示されるとともに、
新たに「開発区審査請求要否評価」セクションが開の状
態で表示されている。

【０１９５】「知財区審査請求要否評価」セクション
は、図３６に示すように知財区における評価の局面（状
態区分コード＝４ｘ）で初めて開状態で表示されるが、
このとき他のセクションはいずれも閉状態である。いず
れの局面でいずれのセクションを表示し、また表示する
として開とするか閉とするかは、主としてその局面で閲
覧者にどの情報が必要かにより決定されている。

【０１９６】ｂ）権限の差異 また、評価表をどのように見せるかだけでなく、誰にそ
の参照権限や編集権限（参照権限を含む）を与えるかも
状態区分コードにより異なっている。図６７は、各段階
における審査請求評価表の参照権者および編集権者をま
とめた表である。

【０１９７】図示するように、審査請求管理者はあらゆ
る局面で評価表の編集権限を有している。これは評価表
のデータに誤りがあった場合などに、随時その修正がで
きるようにするためである。

【０１９８】また、知財区で担当者や評価者を決定する
局面（状態区分コード＝２ｘ）では、審査請求管理者の
ほか、知財区の担当者および承認者のみが評価表を見た
り書き換えたりすることができる。開発区での評価の局
面では（状態区分コード＝３ｘ）、審査請求管理者、開
発区の評価者と承認者のほか、評価者としては選定され
なかった当該出願の他の発明者（もしあれば）全員に編
集権が与えられる。

【０１９９】なお、上述のように開発区から知財区へ処
理が差し戻された場合（開発区の評価者が、自己は当該
出願の審査請求要否を判断するのに適切でないと考えた
場合）には、状態区分コードが３ｘから２ｘに戻る結
果、開発区のメンバーに付与された編集権は剥奪され、
審査請求管理者を除く知財区メンバーに、いったん剥奪
された編集権が参照権に代えて付与される。

【０２００】また、知財区での評価の局面では（状態区
分コード＝４ｘ）、知財区のメンバーに編集権を与える
のはもちろんであるが、評価の行方に利害関係を有する
開発区のメンバーにも参照権のみを与える。

【０２０１】なお、各評価表にはその参照権者や編集権
者を書き込むための欄があり、状態区分コードの変更の
都度、評価表に設定された担当者やその承認者、評価者
やその承認者、あるいは発明者などが参照されて、その
ＩＤが参照権者や編集権者の欄に書き込まれる。

【０２０２】（サーバ１０２のハードウェア構成）つぎ
に、本発明の実施の形態によるワークフロー支援システ
ムの中核をなす、サーバ１０２のハードウェア構成につ
いて説明する。図６８は、本発明の実施の形態によるサ
ーバ１０２のハードウェア構成を示す説明図である。図
中、８８０１は装置全体を制御するＣＰＵを、８８０２
は基本入出力プログラムを記憶したＲＯＭを、８８０３
はＣＰＵ８８０１のワークエリアとして使用されるＲＡ
Ｍを、それぞれ示している。

【０２０３】また、８８０４はＣＰＵ８８０１の制御に
したがってＨＤ（ハードディスク）８８０５に対するデ
ータのリード／ライトを制御するＨＤＤ（ハードディス
クドライブ）を、８８０５はＨＤＤ８８０４の制御にし
たがって書き込まれたデータを記憶するＨＤを、それぞ
れ示している。

【０２０４】また、８８０６はＣＰＵ８８０１の制御に
したがってＦＤ（フロッピー（登録商標）ディスク）８
８０７に対するデータのリード／ライトを制御するＦＤ
Ｄ（フロッピーディスクドライブ）を、８８０７はＦＤ
Ｄ８８０６の制御にしたがって書き込まれたデータを記
憶する着脱自在のＦＤを、それぞれ示している。

【０２０５】また、８８０８はカーソル、メニュー、ウ
ィンドウ、あるいは文字や画像などの各種データを表示
するディスプレイを、８８０９は通信ケーブル８８１０
を介してＬＡＮなどのネットワークに接続され、当該ネ
ットワークとＣＰＵ８８０１とのインターフェースとし
て機能するネットワークＩ／Ｆ（インターフェース）
を、それぞれ示している。

【０２０６】また、８８１１は文字、数値、各種指示な
どの入力のための複数のキーを備えたキーボードを、８
８１２は各種指示の選択や実行、処理対象の選択、カー
ソルの移動などをおこなうマウスを、それぞれ示してい
る。また、８８１３は着脱可能な記録媒体であるＣＤ−
ＲＯＭを、８８１４はＣＤ−ＲＯＭ８８１３に対するデ
ータのリードを制御するＣＤ−ＲＯＭドライブを、８８
１５は上記各部を接続するためのバスまたはケーブル
を、それぞれ示している。

【０２０７】なお、同図は図１に示したサーバ１０２の
ハードウェア構成であるが、知財区のＰＣ１０３や開発
区のＰＣ１０４、電子申請専用端末１０５、あるいはＳ
Ｐのサーバ１０６や各特許事務所のＰＣ１０７もハード
ウェアの概略は同じである。

【０２０８】（メインフレーム１０１およびサーバ１０
２の機能的構成）つぎに、本発明の実施の形態によるワ
ークフロー支援システムの中核をなす、メインフレーム
１０１およびサーバ１０２の機能的構成について説明す
る。図６９は、本発明の実施の形態によるメインフレー
ム１０１およびサーバ１０２の機能的構成を示す説明図
である。ただし、同図には請求項に記載の発明を説明す
るために必要な最小限の機能部しか示していない。

【０２０９】図中、８９０１〜８９０５はメインフレー
ム１０１の機能部である。まず、８９０１はデータベー
ス記憶部であり、具体的には上述の国内特実マスタ１０
１ａを保持している。８９０２はスケジュール管理部で
あり、あらかじめ定められた抽出日が到来したことを検
知すると、その事実を後述する検索部８９０３に通知す
る。

【０２１０】８９０３は検索部であり、スケジュール管
理部８９０２からの通知を受けると、所定の条件に合致
する特許出願、具体的にはその出願日が所定の対象期間
内にある出願をデータベース記憶部８９０１から検索す
る。そして、検索にヒットした出願を特定する情報、た
とえばそのレコードＩＤなどを、後述する読み出し／書
き込み部８９０４に引き渡す。

【０２１１】８９０４は読み出し／書き込み部であり、
検索部８９０３により検索された出願のデータをデータ
ベース記憶部８９０１から読み出して、後述する送受信
部８９０５に引き渡す。あるいは逆に、後述のように送
受信部８９０５から引き渡された出願のデータを、デー
タベース記憶部８９０１に書き込む。このように、読み
出し／書き込み部８９０４はデータベース記憶部８９０
１からの／へのデータの読み出し／書き込み全般を制御
する。

【０２１２】８９０５は送受信部であり、読み出し／書
き込み部８９０４から引き渡されたデータをＣＳＶ形式
の転送用ファイルに編成して、後述するサーバ１０２側
の送受信部８９０９に送信する。また、逆にサーバ１０
２側の送受信部８９０９から受信した転送用ファイル
を、読み出し／書き込み部８９０４に引き渡す。

【０２１３】また、図中８９０６〜８９０９はサーバ１
０２の機能部である。まず、８９０６はデータベース記
憶部であり、具体的には上述の審査請求ＤＢ１０２ａを
保持している。８９０７はスケジュール管理部であり、
あらかじめ定められた時期、具体的には知財区における
評価期限が到来したことを検知すると、その事実を後述
する読み出し／書き込み部８９０８に通知する。

【０２１４】８９０８は読み出し／書き込み部であり、
データベース記憶部８９０６からの／へのデータの読み
出し／書き込み全般を制御する。なお、後述する送受信
部８９０９から引き渡された転送用ファイル内の各出願
を、データベース記憶部８９０６に登録する際には、ま
ずその審査請求評価表を作成の上、当該評価表の所定の
箇所に上記ファイル内のデータを設定してゆく。また、
各作業者による処理結果、たとえば審査請求管理者によ
る修正後のデータや、評価者・担当者による評価結果な
ども随時この評価表に書き込んでゆく。

【０２１５】そして、スケジュール管理部８９０７から
の通知を受けると、今回の定期評価の対象となっている
全出願のデータをデータベース記憶部８９０６から読み
出して、後述する送受信部８９０９に引き渡す。

【０２１６】８９０９は送受信部であり、メインフレー
ム側の送受信部８９０５から受信した転送用ファイルを
読み出し／書き込み部８９０８に引き渡す。逆に、読み
出し／書き込み部８９０８から引き渡された出願のデー
タをＣＳＶ形式の転送用ファイルに編成して、メインフ
レーム１０１側の送受信部８９０５に送信する。

【０２１７】なお、このスケジュール管理部８９０２、
検索部８９０３、読み出し／書き込み部８９０４、送受
信部８９０５、スケジュール管理部８９０７、読み出し
／書き込み部８９０８および送受信部８９０９は、それ
ぞれＨＤ８８０５などからＲＡＭ８８０３に読み出され
たプログラムの命令にしたがって、ＣＰＵ８８０１が命
令処理を実行することにより、各部の機能を実現するも
のである。このプログラムはＨＤ８８０５のほか、ＦＤ
８８０７、ＣＤ−ＲＯＭ８８１３あるいはＭＯなどの各
種記録媒体に格納することができ、あるいはネットワー
クを介して配布することもできる。

【０２１８】また、図６９に示すスケジュール管理部８
９０２が請求項にいう「判定手段」に、そのおこなう処
理が請求項にいう「判定ステップ」に、それぞれ相当す
る。また、検索部８９０３が請求項にいう「検索手段」
に、そのおこなう処理が請求項にいう「検索ステップ」
に、それぞれ相当する。

【０２１９】また、読み出し／書き込み部８９０４が請
求項にいう「読み出し手段」および「更新手段」に、そ
のおこなう処理が請求項にいう「読み出しステップ」お
よび「更新ステップ」に、それぞれ相当する。また、送
受信部８９０５が請求項にいう「送信手段」に、そのお
こなう処理が請求項にいう「送信ステップ」に、それぞ
れ相当する。

【０２２０】また、スケジュール管理部８９０７が請求
項にいう「第２の判定手段」に、そのおこなう処理が請
求項にいう「第２の判定ステップ」に、それぞれ相当す
る。また、読み出し／書き込み部８９０８が請求項にい
う「登録手段」「第２の登録手段」および「修正手段」
に、そのおこなう処理が請求項にいう「登録ステップ」
「第２の登録ステップ」および「修正ステップ」に、そ
れぞれ相当する。また、送受信部８９０９が請求項にい
う「第２の送信手段」に、そのおこなう処理が請求項に
いう「第２の送信ステップ」に、それぞれ相当する。

【０２２１】以上説明したように本実施の形態にかかる
ワークフロー支援システムにおいては、今回の定期評価
の対象になっている出願のデータだけが国内特実マスタ
１０１ａから審査請求ＤＢ１０２ａにコピーされ、以後
の評価作業はもっぱらコピー先である審査請求ＤＢ１０
２ａのデータにもとづいておこなわれる。

【０２２２】そのためコピー元である国内特実マスタ１
０１ａのデータが変化しても、その影響が評価作業にま
で波及することはなく、逆に言えば評価作業に悪影響を
及ぼすおそれがないので、国内特実マスタ１０１ａのデ
ータはいつでも自由に書き換えることができる。また、
変更点を事後的に評価の関係者に対して通知する必要も
ない。

【０２２３】そしてこうした随時の更新により、種々の
業務において参照される国内特実マスタ１０１ａのデー
タの信頼性、たとえばその正確性やリアルタイム性など
が確保される一方で、評価作業に使用される審査請求Ｄ
Ｂ１０２ａのデータは原則として抽出日現在で固定され
たままなので（必要に応じてエラーの修正などはなされ
るが）、評価対象の出願のデータがいつの間にか変動し
て作業に混乱を生ずることもない。

【０２２４】また、審査請求ＤＢ１０２ａのデータは、
なるべく早い時期（上述の実施の形態では知財区評価期
限）に自動的に国内特実マスタ１０１ａに書き戻される
ので、コピー先に蓄積されている審査請求ワークフロー
の成果、すなわち評価結果や評価の過程で発見されたエ
ラーなどを速やかに、かつ漏れなくコピー元にも反映す
ることができる。

【０２２５】また、国内特実マスタ１０１ａと審査請求
ＤＢ１０２ａとの間のデータの授受に使用される転送用
ファイルは、多数の出願のデータを保持していながら、
ＣＳＶ形式であるためそのサイズがごく小さい。したが
って、データベース間のデータの授受が社内のネットワ
ークに与える影響も最小限に抑えることができる。

【０２２６】

【発明の効果】以上説明したように請求項１に記載の発
明は、特許出願の価値を評価するための複数の工程から
なり、前記各工程における作業者のメールアドレスに対
して必要な情報を電子メールで送信することにより、前
記特許出願の価値の評価をおこなうワークフローの支援
システムにおいて、あらかじめ定められた第１の時期に
なったか否かを判定する判定手段と、前記判定手段によ
り前記第１の時期になったと判定された場合に、前記特
許出願のうちあらかじめ定められた条件に合致するもの
を検索する検索手段と、前記検索手段により検索された
特許出願に関する情報を第１のデータベースから読み出
す読み出し手段と、前記読み出し手段により読み出され
た情報を第２のデータベースに対して送信する送信手段
と、前記送信手段により送信されてきた情報を前記第２
のデータベースに登録する登録手段と、を備えたので、
個々の出願の価値の評価は、実態を反映して随時更新さ
れてゆくデータベース（第１のデータベース）でなく、
もっぱらその一部を過去の一点で切り出したデータベー
ス（第２のデータベース）にもとづいておこなわれるこ
とになり、これによって、種々の業務に使用されるデー
タベースのデータの信頼性を確保しつつ、個々の業務に
おけるデータの安定性を維持することが可能なワークフ
ロー支援システムが得られるという効果を奏する。

【０２２７】また、請求項２に記載の発明は、前記請求
項１に記載の発明において、さらに、前記特許出願の価
値に関する情報を前記第２のデータベースに登録する第
２の登録手段と、あらかじめ定められた第２の時期にな
ったか否かを判定する第２の判定手段と、前記第２の判
定手段により前記第２の時期になったと判定された場合
に、前記登録手段および前記第２の登録手段により前記
第２のデータベースに登録された情報を前記第１のデー
タベースに対して送信する第２の送信手段と、前記第２
の送信手段により送信されてきた情報にもとづいて前記
第１のデータベースに格納された情報を更新する更新手
段と、を備えたので、個々の出願の価値の評価は実態を
反映して随時更新されてゆくデータベース（第１のデー
タベース）でなく、もっぱらその一部を過去の一点で切
り出したデータベース（第２のデータベース）にもとづ
いておこなわれるとともに、評価完了後には第２のデー
タベースに蓄積されていた、個々の出願の評価結果がま
とめて第１のデータベースに反映され、これによって、
種々の業務に使用されるデータベースのデータの信頼性
を確保しつつ、個々の業務におけるデータの安定性を維
持することが可能なワークフロー支援システムが得られ
るという効果を奏する。

【０２２８】また、請求項３に記載の発明は、前記請求
項２に記載の発明において、さらに、前記登録手段によ
り前記第２のデータベースに登録された情報を修正する
修正手段を備え、前記送信手段は、前記修正手段により
修正された情報および前記第２の登録手段により登録さ
れた情報を送信するので、個々の出願の価値の評価は実
態を反映して随時更新されてゆくデータベース（第１の
データベース）でなく、もっぱらその一部を過去の一点
で切り出したデータベース（第２のデータベース）にも
とづいておこなわれるとともに、評価完了後には第２の
データベースに蓄積されていた、個々の出願の評価結果
や評価の過程で発見・修正されたデータなどがまとめて
第１のデータベースに反映され、これによって、種々の
業務に使用されるデータベースのデータの信頼性を確保
しつつ、個々の業務におけるデータの安定性を維持する
ことが可能なワークフロー支援システムが得られるとい
う効果を奏する。

【０２２９】また、請求項４に記載の発明は、前記請求
項１〜請求項３のいずれか一つに記載の発明において、
前記送信手段および前記第２の送信手段は、前記情報を
単一のファイルに格納して送信するので、第１のデータ
ベースと第２のデータベースとの間で授受されるデータ
のサイズを小さくすることができ、これによって、種々
の業務に使用されるデータベースのデータの信頼性の確
保と、個々の業務におけるデータの安定性の維持とを、
ネットワークへの負荷を最小限に抑えて実現することが
可能なワークフロー支援システムが得られるという効果
を奏する。

【０２３０】また、請求項５に記載の発明は、前記請求
項２〜請求項４のいずれか一つに記載の発明において、
前記第２の登録手段により登録される前記特許出願の価
値に関する情報とは、前記特許出願について審査請求を
おこなう価値があるか否かを示す情報であるので、個々
の出願の価値の評価は実態を反映して随時更新されてゆ
くデータベース（第１のデータベース）でなく、もっぱ
らその一部を過去の一点で切り出したデータベース（第
２のデータベース）にもとづいておこなわれるととも
に、評価完了後には第２のデータベースに蓄積されてい
た、個々の出願の審査請求価値がまとめて第１のデータ
ベースに反映され、これによって、種々の業務に使用さ
れるデータベースのデータの信頼性を確保しつつ、個々
の業務におけるデータの安定性を維持することが可能な
ワークフロー支援システムが得られるという効果を奏す
る。

【０２３１】また、請求項６に記載の発明は、特許出願
の価値を評価するための複数の工程からなり、前記各工
程における作業者のメールアドレスに対して必要な情報
を電子メールで送信することにより、前記特許出願の価
値の評価をおこなうワークフローの支援方法において、
あらかじめ定められた第１の時期になったか否かを判定
する判定ステップと、前記判定ステップで前記第１の時
期になったと判定された場合に、前記特許出願のうちあ
らかじめ定められた条件に合致するものを検索する検索
ステップと、前記検索ステップで検索された特許出願に
関する情報を第１のデータベースから読み出す読み出し
ステップと、前記読み出しステップで読み出された情報
を第２のデータベースに対して送信する送信ステップ
と、前記送信ステップで送信されてきた情報を前記第２
のデータベースに登録する登録ステップと、を含んだの
で、個々の出願の価値の評価は、実態を反映して随時更
新されてゆくデータベース（第１のデータベース）でな
く、もっぱらその一部を過去の一点で切り出したデータ
ベース（第２のデータベース）にもとづいておこなわれ
ることになり、これによって、種々の業務に使用される
データベースのデータの信頼性を確保しつつ、個々の業
務におけるデータの安定性を維持することが可能なワー
クフロー支援方法が得られるという効果を奏する。

【０２３２】また、請求項７に記載の発明は、前記請求
項６に記載の発明において、さらに、前記特許出願の価
値に関する情報を前記第２のデータベースに登録する第
２の登録ステップと、あらかじめ定められた第２の時期
になったか否かを判定する第２の判定ステップと、前記
第２の判定ステップで前記第２の時期になったと判定さ
れた場合に、前記登録ステップおよび前記第２の登録ス
テップで前記第２のデータベースに登録された情報を前
記第１のデータベースに対して送信する第２の送信ステ
ップと、前記第２の送信ステップで送信されてきた情報
にもとづいて前記第１のデータベースに格納された情報
を更新する更新ステップと、を含んだので、個々の出願
の価値の評価は実態を反映して随時更新されてゆくデー
タベース（第１のデータベース）でなく、もっぱらその
一部を過去の一点で切り出したデータベース（第２のデ
ータベース）にもとづいておこなわれるとともに、評価
完了後には第２のデータベースに蓄積されていた、個々
の出願の評価結果がまとめて第１のデータベースに反映
され、これによって、種々の業務に使用されるデータベ
ースのデータの信頼性を確保しつつ、個々の業務におけ
るデータの安定性を維持することが可能なワークフロー
支援方法が得られるという効果を奏する。

【０２３３】また、請求項８に記載の発明は、前記請求
項７に記載の発明において、さらに、前記登録ステップ
で前記第２のデータベースに登録された情報を修正する
修正ステップを含み、前記送信ステップでは、前記修正
ステップで修正された情報および前記第２の登録ステッ
プで登録された情報を送信するので、個々の出願の価値
の評価は実態を反映して随時更新されてゆくデータベー
ス（第１のデータベース）でなく、もっぱらその一部を
過去の一点で切り出したデータベース（第２のデータベ
ース）にもとづいておこなわれるとともに、評価完了後
には第２のデータベースに蓄積されていた、個々の出願
の評価結果や評価の過程で発見・修正されたデータなど
がまとめて第１のデータベースに反映され、これによっ
て、種々の業務に使用されるデータベースのデータの信
頼性を確保しつつ、個々の業務におけるデータの安定性
を維持することが可能なワークフロー支援方法が得られ
るという効果を奏する。

【０２３４】また、請求項９に記載の発明は、前記請求
項６〜請求項８のいずれか一つに記載の発明において、
前記送信ステップおよび前記第２の送信ステップでは、
前記情報を単一のファイルに格納して送信するので、第
１のデータベースと第２のデータベースとの間で授受さ
れるデータのサイズを小さくすることができ、これによ
って、種々の業務に使用されるデータベースのデータの
信頼性の確保と、個々の業務におけるデータの安定性の
維持とを、ネットワークへの負荷を最小限に抑えて実現
することが可能なワークフロー支援方法が得られるとい
う効果を奏する。

【０２３５】また、請求項１０に記載の発明は、前記請
求項７〜請求項９のいずれか一つに記載の発明におい
て、前記第２の登録ステップで登録される前記特許出願
の価値に関する情報とは、前記特許出願について審査請
求をおこなう価値があるか否かを示す情報であるので、
個々の出願の価値の評価は実態を反映して随時更新され
てゆくデータベース（第１のデータベース）でなく、も
っぱらその一部を過去の一点で切り出したデータベース
（第２のデータベース）にもとづいておこなわれるとと
もに、評価完了後には第２のデータベースに蓄積されて
いた、個々の出願の審査請求価値がまとめて第１のデー
タベースに反映され、これによって、種々の業務に使用
されるデータベースのデータの信頼性を確保しつつ、個
々の業務におけるデータの安定性を維持することが可能
なワークフロー支援方法が得られるという効果を奏す
る。

【０２３６】また、請求項１１に記載の発明は、特許出
願の価値を評価するための複数の工程からなり、前記各
工程における作業者のメールアドレスに対して必要な情
報を電子メールで送信することにより、前記特許出願の
価値の評価をおこなうワークフローの支援プログラムに
おいて、あらかじめ定められた第１の時期になったか否
かを判定する判定ステップと、前記判定ステップで前記
第１の時期になったと判定された場合に、前記特許出願
のうちあらかじめ定められた条件に合致するものを検索
する検索ステップと、前記検索ステップで検索された特
許出願に関する情報を第１のデータベースから読み出す
読み出しステップと、前記読み出しステップで読み出さ
れた情報を第２のデータベースに対して送信する送信ス
テップと、前記送信ステップで送信されてきた情報を前
記第２のデータベースに登録する登録ステップと、をコ
ンピュータに実行させるので、個々の出願の価値の評価
は、実態を反映して随時更新されてゆくデータベース
（第１のデータベース）でなく、もっぱらその一部を過
去の一点で切り出したデータベース（第２のデータベー
ス）にもとづいておこなわれることになり、これによっ
て、種々の業務に使用されるデータベースのデータの信
頼性を確保しつつ、個々の業務におけるデータの安定性
を維持することが可能なワークフロー支援プログラムが
得られるという効果を奏する。

【０２３７】また、請求項１２に記載の発明は、前記請
求項１１に記載の発明において、さらに、前記特許出願
の価値に関する情報を前記第２のデータベースに登録す
る第２の登録ステップと、あらかじめ定められた第２の
時期になったか否かを判定する第２の判定ステップと、
前記第２の判定ステップで前記第２の時期になったと判
定された場合に、前記登録ステップおよび前記第２の登
録ステップで前記第２のデータベースに登録された情報
を前記第１のデータベースに対して送信する第２の送信
ステップと、前記第２の送信ステップで送信されてきた
情報にもとづいて前記第１のデータベースに格納された
情報を更新する更新ステップと、をコンピュータに実行
させるので、個々の出願の価値の評価は実態を反映して
随時更新されてゆくデータベース（第１のデータベー
ス）でなく、もっぱらその一部を過去の一点で切り出し
たデータベース（第２のデータベース）にもとづいてお
こなわれるとともに、評価完了後には第２のデータベー
スに蓄積されていた、個々の出願の評価結果がまとめて
第１のデータベースに反映され、これによって、種々の
業務に使用されるデータベースのデータの信頼性を確保
しつつ、個々の業務におけるデータの安定性を維持する
ことが可能なワークフロー支援プログラムが得られると
いう効果を奏する。

【０２３８】また、請求項１３に記載の発明は、前記請
求項１２に記載の発明において、前記第２の登録ステッ
プで登録される前記特許出願の価値に関する情報とは、
前記特許出願について審査請求をおこなう価値があるか
否かを示す情報であるので、個々の出願の価値の評価は
実態を反映して随時更新されてゆくデータベース（第１
のデータベース）でなく、もっぱらその一部を過去の一
点で切り出したデータベース（第２のデータベース）に
もとづいておこなわれるとともに、評価完了後には第２
のデータベースに蓄積されていた、個々の出願の審査請
求価値がまとめて第１のデータベースに反映され、これ
によって、種々の業務に使用されるデータベースのデー
タの信頼性を確保しつつ、個々の業務におけるデータの
安定性を維持することが可能なワークフロー支援プログ
ラムが得られるという効果を奏する。

【０２３９】また、請求項１４に記載の発明によれば、
前記請求項１１〜請求項１３のいずれか一つに記載のプ
ログラムをコンピュータに実行させることが可能な記録
媒体が得られるという効果を奏する。

【図面の簡単な説明】

【図１】本発明の実施の形態によるワークフロー支援シ
ステムの概略構成を示す説明図である。

【図２】メインフレーム１０１からサーバ１０２へのデ
ータの読み出し（コピー）の手順を示すフローチャート
である。

【図３】メインフレーム１０１上の発明者のうち、退職
者でも休職者でもない者だけをサーバ１０２に抽出する
ための手順を示すフローチャートである。

【図４】出願データのうち特に公開番号についておこな
われるエラーチェックの手順を示すフローチャートであ
る。

【図５】出願データのうち特に担当者についておこなわ
れるエラーチェックの手順を示すフローチャートであ
る。

【図６】発明者が複数ある場合におこなわれる代表者の
選定の手順を示すフローチャートである。

【図７】審査請求管理者に対して送信される取り込み完
了通知メールの一例を示す説明図である。

【図８】審査請求管理者に対する取り込み完了通知メー
ル中のリンクをクリックすると表示される、「取込み結
果一覧」ビューの一例を示す説明図である。

【図９】みなし取下げと同一視されたために審査請求ワ
ークフローから除外された出願を、上記フローに復帰さ
せるための手順を示すフローチャートである。

【図１０】審査請求管理者によるデータ修正後、知財区
担当者に送信される作業依頼メールの一例を示す説明図
である。

【図１１】知財区担当者に対する作業依頼メール中のリ
ンクをクリックすると表示される、「担当者＆評価者変
更」ビューの一例を示す説明図である。

【図１２】「担当者＆評価者変更」ビューでいずれかの
案件をダブルクリックすると表示される、審査請求評価
表の一例を示す説明図である。

【図１３】担当者自身による担当者の変更の手順を示す
フローチャートである。

【図１４】知財区担当者による編集中の評価表、特にそ
の「知財区担当者」セクション付近の一例を示す説明図
である。

【図１５】「アドレス帳より選択」ボタンをクリックす
ると表示されるアドレス帳の一例を示す説明図である。

【図１６】「担当者変更依頼」ボタンをクリックすると
表示されるダイアログの一例を示す説明図である。

【図１７】担当者変更依頼先に対して送信される作業依
頼メールの一例を示す説明図である。

【図１８】担当者変更依頼先に対する作業依頼メール中
のリンクをクリックすると表示される、「担当者変更確
定」ビューの一例を示す説明図である。

【図１９】担当者による評価者の変更の手順を示すフロ
ーチャートである。

【図２０】知財区担当者による編集中の評価表、特にそ
の「開発区評価者」セクション付近の一例を示す説明図
である。

【図２１】「発明者リストより選択」ボタンをクリック
すると表示される発明者リストの一例を示す説明図であ
る。

【図２２】知財区担当者による担当者および評価者の決
定後、開発区評価者に送信される作業依頼メールの一例
を示す説明図である。

【図２３】開発区評価者に対する作業依頼メール中のリ
ンクをクリックすると表示される、「開発区評価」ビュ
ーの一例を示す説明図である。

【図２４】「開発区評価」ビューでいずれかの案件をダ
ブルクリックすると表示される、審査請求評価表の一例
を示す説明図である。

【図２５】開発区担当者による編集中の評価表、特にそ
の「開発区評価者」セクション付近の一例を示す説明図
である。

【図２６】開発区評価者による評価の手順を示すフロー
チャートである。

【図２７】「審査・承認依頼」ボタンをクリックすると
表示されるダイアログの一例を示す説明図である。

【図２８】開発区評価者による評価後、開発区承認者に
送信される作業依頼メールの一例を示す説明図である。

【図２９】開発区承認者に対する作業依頼メール中のリ
ンクをクリックすると表示される、「開発区審査・承認
中」ビューの一例を示す説明図である。

【図３０】開発区承認者による評価の手順を示すフロー
チャートである。

【図３１】「承認」ボタンをクリックすると表示される
ダイアログの一例を示す説明図である。

【図３２】開発区承認者による承認後、開発区評価者に
送信される承認通知メールの一例を示す説明図である。

【図３３】開発区承認者による承認後、知財区担当者に
送信される作業依頼メールの一例を示す説明図である。

【図３４】開発区承認者による否認後、開発区評価者に
送信される否認通知メールの一例を示す説明図である。

【図３５】知財区担当者に対する作業依頼メール中のリ
ンクをクリックすると表示される、「知財区評価」ビュ
ーの一例を示す説明図である。

【図３６】「知財区評価」ビューでいずれかの案件をダ
ブルクリックすると表示される、審査請求評価表の一例
を示す説明図である。

【図３７】知財区担当者による評価後、知財区承認者に
送信される作業依頼メールの一例を示す説明図である。

【図３８】知財区承認者に対する作業依頼メール中のリ
ンクをクリックすると表示される、「知財区審査・承認
中」ビューの一例を示す説明図である。

【図３９】知財区承認者による承認後、知財区担当者に
送信される承認通知メールの一例を示す説明図である。

【図４０】知財区承認者による否認後、知財区担当者に
送信される否認通知メールの一例を示す説明図である。

【図４１】スケジュールマスタに登録されたスケジュー
ルの一例を示す説明図である。

【図４２】知財区での決定期限を徒過した案件について
おこなわれる、開発区への移管の手順を示すフローチャ
ートである。

【図４３】作業を懈怠している知財区担当者とその承認
者に送信される、催促メールの一例を示す説明図であ
る。

【図４４】開発区での評価期限直前におこなわれる評価
者および承認者への催促の手順を示すフローチャートで
ある。

【図４５】作業を懈怠している開発区評価者とその承認
者に送信される、催促メールの一例を示す説明図であ
る。

【図４６】開発区での評価期限を徒過した案件について
おこなわれる、知財区への移管の手順を示すフローチャ
ートである。

【図４７】作業を懈怠している開発区評価者とその承認
者に送信される、評価結果に「仮要」を自動設定した旨
の通知メールの一例を示す説明図である。

【図４８】知財区での評価期限直前におこなわれる担当
者および承認者への催促の手順を示すフローチャートで
ある。

【図４９】作業を懈怠している知財区担当者とその承認
者に送信される、催促メールの一例を示す説明図であ
る。

【図５０】知財区での評価期限を経過した時点でおこな
われる、評価完了処理の手順を示すフローチャートであ
る。

【図５１】審査請求費用の算出の手順を詳細に示すフロ
ーチャートである。

【図５２】サーバ１０２からメインフレーム１０１への
データの書き戻し（コピー）の手順を示すフローチャー
トである。

【図５３】みなし取下げとなった出願につきメインフレ
ーム１０１への書き戻し時におこなわれるデータの修正
の手順を示すフローチャートである。

【図５４】代理人に対する審査請求依頼の手順を示すフ
ローチャートである。

【図５５】審査請求ＤＢ１０２ａにおいて「事務所依
頼」ボタンをクリックすると表示される、「事務所依
頼」ビューの一例を示す説明図である。

【図５６】開発区および知財区による評価完了後、代理
人に対して送信される作業依頼メールの一例を示す説明
図である。

【図５７】代理人に対する作業依頼メール中のリンクを
クリックすると表示される、手続き依頼一覧の一例を示
す説明図である。

【図５８】手続き依頼一覧中のリンクをクリックすると
表示される、個々の案件の審査請求手続き依頼書の一例
を示す説明図である。

【図５９】自社による審査請求の手順（審査請求書作成
手順）を示すフローチャートである。

【図６０】自社による審査請求の手順（専用端末１０５
における審査請求手順）を示すフローチャートである。

【図６１】自社による審査請求の手順（審査請求評価表
への審査請求日の設定手順）を示すフローチャートであ
る。

【図６２】自社による審査請求の手順（審査請求完了後
の代理人への通知手順）を示すフローチャートである。

【図６３】審査請求ＤＢ１０２ａにおいて「自社手続き
分」ボタンをクリックすると表示される、「自社審査請
求」ビューの一例を示す説明図である。

【図６４】自社審査請求の完了後、各出願の代理人に対
して送信される通知メールの一例を示す説明図である。

【図６５】各々の状態区分コードとその意味とをまとめ
た表である。

【図６６】審査請求評価表中の各セクションの、各段階
におけるデフォルトでの表示形態をまとめた表である。

【図６７】各段階における審査請求評価表の参照権者お
よび編集権者をまとめた表である。

【図６８】本発明の実施の形態によるサーバ１０２のハ
ードウェア構成を示す説明図である。

【図６９】本発明の実施の形態によるメインフレーム１
０１およびサーバ１０２の機能的構成を示す説明図であ
る。

【符号の説明】

１０１ メインフレーム １０１ａ 国内特実マスタ １０１ｂ 人事マスタ １０２ サーバ １０２ａ 審査請求ＤＢ １０３ 知財区ＰＣ １０４ 開発区ＰＣ １０５ 電子申請専用端末 １０６ ＳＰのサーバ １０６ａ 事務所ＤＢ １０７ 特許事務所ＰＣ ８８０１ ＣＰＵ ８８０２ ＲＯＭ ８８０３ ＲＡＭ ８８０４ ＨＤＤ ８８０５ ＨＤ ８８０６ ＦＤＤ ８８０７ ＦＤ ８８０８ ディスプレイ ８８０９ ネットワークＩ／Ｆ ８８１０ 通信ケーブル ８８１１ キーボード ８８１２ マウス ８８１３ ＣＤ−ＲＯＭ ８８１４ ＣＤ−ＲＯＭドライブ ８８１５ バスまたはケーブル ８９０１，８９０６ データベース記憶部 ８９０２，８９０７ スケジュール管理部 ８９０３ 検索部 ８９０４，８９０８ 読み出し／書き込み部 ８９０５，８９０９ 送受信部

Claims (14)

【特許請求の範囲】
1. 【請求項１】 特許出願の価値を評価するための複数の
   工程からなり、前記各工程における作業者のメールアド
   レスに対して必要な情報を電子メールで送信することに
   より、前記特許出願の価値の評価をおこなうワークフロ
   ーの支援システムにおいて、 あらかじめ定められた第１の時期になったか否かを判定
   する判定手段と、 前記判定手段により前記第１の時期になったと判定され
   た場合に、前記特許出願のうちあらかじめ定められた条
   件に合致するものを検索する検索手段と、 前記検索手段により検索された特許出願に関する情報を
   第１のデータベースから読み出す読み出し手段と、 前記読み出し手段により読み出された情報を第２のデー
   タベースに対して送信する送信手段と、 前記送信手段により送信されてきた情報を前記第２のデ
   ータベースに登録する登録手段と、 を備えたことを特徴とするワークフロー支援システム。
2. 【請求項２】 さらに、前記特許出願の価値に関する情
   報を前記第２のデータベースに登録する第２の登録手段
   と、 あらかじめ定められた第２の時期になったか否かを判定
   する第２の判定手段と、 前記第２の判定手段により前記第２の時期になったと判
   定された場合に、前記登録手段および前記第２の登録手
   段により前記第２のデータベースに登録された情報を前
   記第１のデータベースに対して送信する第２の送信手段
   と、 前記第２の送信手段により送信されてきた情報にもとづ
   いて前記第１のデータベースに格納された情報を更新す
   る更新手段と、 を備えたことを特徴とする前記請求項１に記載のワーク
   フロー支援システム。
3. 【請求項３】 さらに、前記登録手段により前記第２の
   データベースに登録された情報を修正する修正手段を備
   え、 前記送信手段は、前記修正手段により修正された情報お
   よび前記第２の登録手段により登録された情報を送信す
   ることを特徴とする前記請求項２に記載のワークフロー
   支援システム。
4. 【請求項４】 前記送信手段および前記第２の送信手段
   は、前記情報を単一のファイルに格納して送信すること
   を特徴とする前記請求項１〜請求項３のいずれか一つに
   記載のワークフロー支援システム。
5. 【請求項５】 前記第２の登録手段により登録される前
   記特許出願の価値に関する情報とは、前記特許出願につ
   いて審査請求をおこなう価値があるか否かを示す情報で
   あることを特徴とする前記請求項２〜請求項４のいずれ
   か一つに記載のワークフロー支援システム。
6. 【請求項６】 特許出願の価値を評価するための複数の
   工程からなり、前記各工程における作業者のメールアド
   レスに対して必要な情報を電子メールで送信することに
   より、前記特許出願の価値の評価をおこなうワークフロ
   ーの支援方法において、 あらかじめ定められた第１の時期になったか否かを判定
   する判定ステップと、 前記判定ステップで前記第１の時期になったと判定され
   た場合に、前記特許出願のうちあらかじめ定められた条
   件に合致するものを検索する検索ステップと、 前記検索ステップで検索された特許出願に関する情報を
   第１のデータベースから読み出す読み出しステップと、 前記読み出しステップで読み出された情報を第２のデー
   タベースに対して送信する送信ステップと、 前記送信ステップで送信されてきた情報を前記第２のデ
   ータベースに登録する登録ステップと、 を含んだことを特徴とするワークフロー支援方法。
7. 【請求項７】 さらに、前記特許出願の価値に関する情
   報を前記第２のデータベースに登録する第２の登録ステ
   ップと、 あらかじめ定められた第２の時期になったか否かを判定
   する第２の判定ステップと、 前記第２の判定ステップで前記第２の時期になったと判
   定された場合に、前記登録ステップおよび前記第２の登
   録ステップで前記第２のデータベースに登録された情報
   を前記第１のデータベースに対して送信する第２の送信
   ステップと、 前記第２の送信ステップで送信されてきた情報にもとづ
   いて前記第１のデータベースに格納された情報を更新す
   る更新ステップと、 を含んだことを特徴とする前記請求項６に記載のワーク
   フロー支援方法。
8. 【請求項８】 さらに、前記登録ステップで前記第２の
   データベースに登録された情報を修正する修正ステップ
   を含み、 前記送信ステップでは、前記修正ステップで修正された
   情報および前記第２の登録ステップで登録された情報を
   送信することを特徴とする前記請求項７に記載のワーク
   フロー支援方法。
9. 【請求項９】 前記送信ステップおよび前記第２の送信
   ステップでは、前記情報を単一のファイルに格納して送
   信することを特徴とする前記請求項６〜請求項８のいず
   れか一つに記載のワークフロー支援方法。
10. 【請求項１０】 前記第２の登録ステップで登録される
    前記特許出願の価値に関する情報とは、前記特許出願に
    ついて審査請求をおこなう価値があるか否かを示す情報
    であることを特徴とする前記請求項７〜請求項９のいず
    れか一つに記載のワークフロー支援方法。
11. 【請求項１１】 特許出願の価値を評価するための複数
    の工程からなり、前記各工程における作業者のメールア
    ドレスに対して必要な情報を電子メールで送信すること
    により、前記特許出願の価値の評価をおこなうワークフ
    ローの支援プログラムにおいて、 あらかじめ定められた第１の時期になったか否かを判定
    する判定ステップと、 前記判定ステップで前記第１の時期になったと判定され
    た場合に、前記特許出願のうちあらかじめ定められた条
    件に合致するものを検索する検索ステップと、 前記検索ステップで検索された特許出願に関する情報を
    第１のデータベースから読み出す読み出しステップと、 前記読み出しステップで読み出された情報を第２のデー
    タベースに対して送信する送信ステップと、 前記送信ステップで送信されてきた情報を前記第２のデ
    ータベースに登録する登録ステップと、 をコンピュータに実行させることを特徴とするワークフ
    ロー支援プログラム。
12. 【請求項１２】 さらに、前記特許出願の価値に関する
    情報を前記第２のデータベースに登録する第２の登録ス
    テップと、 あらかじめ定められた第２の時期になったか否かを判定
    する第２の判定ステップと、 前記第２の判定ステップで前記第２の時期になったと判
    定された場合に、前記登録ステップおよび前記第２の登
    録ステップで前記第２のデータベースに登録された情報
    を前記第１のデータベースに対して送信する第２の送信
    ステップと、 前記第２の送信ステップで送信されてきた情報にもとづ
    いて前記第１のデータベースに格納された情報を更新す
    る更新ステップと、 をコンピュータに実行させることを特徴とする前記請求
    項１１に記載のワークフロー支援プログラム。
13. 【請求項１３】 前記第２の登録ステップで登録される
    前記特許出願の価値に関する情報とは、前記特許出願に
    ついて審査請求をおこなう価値があるか否かを示す情報
    であることを特徴とする前記請求項１２に記載のワーク
    フロー支援プログラム。
14. 【請求項１４】 前記請求項１１〜請求項１３のいずれ
    か一つに記載のプログラムを記録したコンピュータ読み
    取り可能な記録媒体。