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

Abstract

(57)【要約】 【課題】 過去のある時期にした特許出願につき一括し
てその審査請求の要否を検討する場合などに、個々の出
願の公開公報全文を容易に閲覧できるようにすること。 【解決手段】 個々の出願について作成され、ワークフ
ロー内の各作業者（開発区評価者や知財区担当者など）
に回覧されて順次評価を書き込まれる電子書類には、上
記出願の要約文のほか、上記出願の公開番号を埋め込ん
だボタンを配置する。このボタンはクリックされると、
上記公開番号を公報データベースの検索モジュールに出
力する。そして、上記公開番号により特定される公報の
全文がデータベースから取り出され、ディスプレイに表
示される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、電子文書に記述
された情報の価値を評価するためのワークフローの支援
システム、ワークフローの支援方法、ワークフローの支
援プログラムおよびそのプログラムを記録したコンピュ
ータ読み取り可能な記録媒体に関する。

【０００２】

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

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

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

【０００５】

【発明が解決しようとする課題】この検討は個々の発明
の詳細な内容を理解してはじめて可能となるものであ
り、出願時に作成された資料、当該発明が掲載された特
許公開公報など、種々の関連資料を精読の上で結論が下
される。特に、現在出願中の発明を特定するために、公
開公報の閲覧は欠かすことのできないものである。

【０００６】ただ、大企業ともなると一回の検討の対象
となる出願の数が数百件〜数千件というレベルであり、
しかも個々の発明についての検討は通常は複数人により
なされるので（本出願人の場合は少なくとも四人）、紙
公報であれ電子公報であれ、誰にどの公報が必要かを特
定して逐一配布することは現実的ではない。そこで、通
常個々の作業者には各人に割り当てられた出願の公開番
号のみが通知され、公報は必要に応じて、たとえば企業
内で運用されている、あるいは外部の事業者により提供
されている特許公報のオンライン検索システムから取得
するよう指示される。

【０００７】そして、各作業者は上記システムで公開番
号などを入力して必要な公報を検索するのであるが、上
記のような大企業では一人あたりに割り当てられる出願
の件数も多数にのぼるため、それらにつき逐一公開番号
などの検索条件を入力するのは煩雑であり、また入力ミ
スも多くなってしまうという問題点があった。

【０００８】この発明は上記従来技術の問題点に鑑みて
なされたものであって、大量の電子文書に記述された情
報の詳細を容易に確認することが可能なワークフロー支
援システム、ワークフロー支援方法、ワークフロー支援
プログラムおよびそのプログラムを記録したコンピュー
タ読み取り可能な記録媒体を提供することを目的とす
る。

【０００９】

【課題を解決するための手段】上述した課題を解決し、
目的を達成するため、請求項１に記載のワークフロー支
援システムは、電子文書に記述された情報の価値を評価
するための複数の工程からなり、前記電子文書に記述さ
れた情報または当該電子文書に記述された情報の格納先
に関する情報を前記各工程における作業者のメールアド
レスに対して電子メールで送信することにより、前記電
子文書に記述された情報の価値の評価をおこなうワーク
フローの支援システムにおいて、前記電子文書に記述さ
れた情報の要約文を読み出す第１の読み出し手段と、前
記電子文書に記述された情報を特定するための情報を読
み出す第２の読み出し手段と、あらかじめ定められた文
書設計情報にもとづいて、前記第１の読み出し手段によ
り読み出された要約文を前記電子文書内の所定の位置に
配置する第１の配置手段と、あらかじめ定められた文書
設計情報にもとづいて、前記第２の読み出し手段により
読み出された情報を保持する操作ボタンを前記電子文書
内の所定の位置に配置する第２の配置手段と、前記第１
の配置手段および第２の配置手段により前記要約文およ
び前記操作ボタンを配置された前記電子文書を表示する
第１の表示手段と、を備えたことを特徴とする。

【００１０】また、請求項２に記載のワークフロー支援
システムは、前記請求項１に記載の発明において、さら
に、前記第１の表示手段により表示された前記電子文書
内に配置された前記操作ボタンが押下されたことを検知
する検知手段と、前記検知手段により前記操作ボタンが
押下されたことを検知した場合に、前記操作ボタンに保
持されている前記第２の読み出し手段により読み出され
た情報にもとづいて、前記電子文書に記述された情報の
全文を読み出す第３の読み出し手段と、前記第３の読み
出し手段により読み出された全文を表示する第２の表示
手段と、を備えたことを特徴とする。

【００１１】また、請求項３に記載のワークフロー支援
システムは、前記請求項２に記載の発明において、前記
第３の読み出し手段が、さらに、操作者から入力された
任意の情報で特定される情報の全文を読み出すことを特
徴とする。

【００１２】また、請求項４に記載のワークフロー支援
システムは、前記請求項１〜請求項３のいずれか一つに
記載の発明において、前記電子文書に記述された情報と
は特許出願中の発明に関する情報であり、前記評価とは
前記発明について審査請求をおこなう価値があるか否か
の評価であることを特徴とする。

【００１３】また、請求項５に記載のワークフロー支援
方法は、電子文書に記述された情報の価値を評価するた
めの複数の工程からなり、前記電子文書に記述された情
報または当該電子文書に記述された情報の格納先に関す
る情報を前記各工程における作業者のメールアドレスに
対して電子メールで送信することにより、前記電子文書
に記述された情報の価値の評価をおこなうワークフロー
の支援方法において、前記電子文書に記述された情報の
要約文を読み出す第１の読み出しステップと、前記電子
文書に記述された情報を特定するための情報を読み出す
第２の読み出しステップと、あらかじめ定められた文書
設計情報にもとづいて、前記第１の読み出しステップで
読み出された要約文を前記電子文書内の所定の位置に配
置する第１の配置ステップと、あらかじめ定められた文
書設計情報にもとづいて、前記第２の読み出しステップ
で読み出された情報を保持する操作ボタンを前記電子文
書内の所定の位置に配置する第２の配置ステップと、前
記第１の配置ステップおよび第２の配置ステップで前記
要約文および前記操作ボタンを配置された前記電子文書
を表示する第１の表示ステップと、を含んだことを特徴
とする。

【００１４】また、請求項６に記載のワークフロー支援
方法は、前記請求項５に記載の発明において、さらに、
前記第１の表示ステップで表示された前記電子文書内に
配置された前記操作ボタンが押下されたことを検知する
検知ステップと、前記検知ステップで前記操作ボタンが
押下されたことを検知した場合に、前記操作ボタンに保
持されている前記第２の読み出しステップで読み出され
た情報にもとづいて、前記電子文書に記述された情報の
全文を読み出す第３の読み出しステップと、前記第３の
読み出しステップで読み出された全文を表示する第２の
表示ステップと、を含んだことを特徴とする。

【００１５】また、請求項７に記載のワークフロー支援
方法は、前記請求項６に記載の発明において、前記第３
の読み出しステップでは、さらに、操作者から入力され
た任意の情報で特定される情報の全文を読み出すことを
特徴とする。

【００１６】また、請求項８に記載のワークフロー支援
方法は、前記請求項５〜請求項７のいずれか一つに記載
の発明において、前記電子文書に記述された情報とは特
許出願中の発明に関する情報であり、前記評価とは前記
発明について審査請求をおこなう価値があるか否かの評
価であることを特徴とする。

【００１７】また、請求項９に記載のワークフロー支援
プログラムは、電子文書に記述された情報の価値を評価
するための複数の工程からなり、前記電子文書に記述さ
れた情報または当該電子文書に記述された情報の格納先
に関する情報を前記各工程における作業者のメールアド
レスに対して電子メールで送信することにより、前記電
子文書に記述された情報の価値の評価をおこなうワーク
フローの支援プログラムにおいて、前記電子文書に記述
された情報の要約文を読み出す第１の読み出しステップ
と、前記電子文書に記述された情報を特定するための情
報を読み出す第２の読み出しステップと、あらかじめ定
められた文書設計情報にもとづいて、前記第１の読み出
しステップで読み出された要約文を前記電子文書内の所
定の位置に配置する第１の配置ステップと、あらかじめ
定められた文書設計情報にもとづいて、前記第２の読み
出しステップで読み出された情報を保持する操作ボタン
を前記電子文書内の所定の位置に配置する第２の配置ス
テップと、前記第１の配置ステップおよび第２の配置ス
テップで前記要約文および前記操作ボタンを配置された
前記電子文書を表示する第１の表示ステップと、をコン
ピュータに実行させることを特徴とする。

【００１８】また、請求項１０に記載のワークフロー支
援プログラムは、前記請求項９に記載の発明において、
さらに、前記第１の表示ステップで表示された前記電子
文書内に配置された前記操作ボタンが押下されたことを
検知する検知ステップと、前記検知ステップで前記操作
ボタンが押下されたことを検知した場合に、前記操作ボ
タンに保持されている前記第２の読み出しステップで読
み出された情報にもとづいて、前記電子文書に記述され
た情報の全文を読み出す第３の読み出しステップと、前
記第３の読み出しステップで読み出された全文を表示す
る第２の表示ステップと、をコンピュータに実行させる
ことを特徴とする。

【００１９】また、請求項１１に記載の記録媒体は、前
記請求項９または請求項１０に記載のプログラムを記録
したことで、そのプログラムをコンピュータ読み取り可
能とすることができ、これによって、前記請求項９また
は請求項１０に記載の処理をコンピュータによって実現
することができる。

【００２０】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００３５】公開番号の欠落 公開番号の項目にデータがない場合である。上述のよう
に定期評価は出願後１年半〜２年で実施されるので、本
来ならば上記抽出の時点ですでに発明は公開され、公開
番号が付与されているはずである。唯一の例外は国内優
先権主張の基礎とされた出願であって、これらの出願は
出願後１年３ヶ月を経過した時点で取り下げたものとみ
なされるため、公開番号が付与されることはない。

【００３６】そこで、上記転送用ファイルの各出願のデ
ータを自動でチェックし、公開番号の欠落した出願は一
律にエラー一覧に拾い出してゆく。そして、審査請求管
理者はこのエラー一覧と、別途管理されている紙資料な
どとを照合して、各出願の公開番号の欠落が単なる入力
漏れによるものか、優先権主張によるものかの見極めを
おこなう。その結果、前者の出願については漏れた公開
番号を入力するが、後者の出願についてはそもそも評価
をおこなう実益がない（みなし取下げにより、もはや審
査請求による権利化の余地がない）ため、当該出願を評
価の対象から除外する。

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

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

【００３９】なお、逆に発明者が複数ある場合には、後
述のようにそのうち一人を代表として評価を依頼するこ
とになるので、評価表の作成の時点でこの代表者（開発
区評価者）を選定しておく。この代表としては、発明者
中の筆頭発明者、すなわち発明者が複数あれば第一番目
の発明者、発明者が一人のみであれば当該発明者が機械
的に任命される。

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

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

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

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

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

【００４５】図６は、ＰＶのクライアントで表示される
公報検索用画面の一例を示す説明図である。この画面で
検索条件を入力して「検索」ボタンをクリックすると、
検索結果が新たな検索履歴として画面下方に表示され、
履歴のうちいずれかを選択して「一覧表示」ボタンをク
リックすることで、図７に示すようにヒットした公報の
一覧を表示させることができる。

【００４６】図５に示した評価表の閲覧中にも、ＰＶの
クライアントモジュールを別途起動すれば、ＰＶサーバ
から所望の公報を検索して表示させることは可能であ
る。しかし、特に全文を確認したい出願が多数ある場合
には、検索条件（公開番号など）を上記画面で逐一入力
しなければならず作業が煩雑となってしまう。

【００４７】ところでＰＶでは、どの公報を閲覧したい
かは、まずクライアントにその公開番号を列挙したＰＶ
起動ファイル（ｃ：￥ｔｅｍｐ．ｐａｔ）を作成し、つ
ぎに当該ファイルを実行することでサーバに通知する仕
様になっている。そこで各出願の評価表には、クリック
されるとＰＶのクライアントモジュールを呼び出して、
当該出願の公開番号をパラメータとして渡すようなボタ
ン（図５の「ＰＶ起動」ボタン）を配置するよう、上述
の文書設計情報であらかじめ定義しておく。

【００４８】図８は、「ＰＶ起動」ボタンによる公報全
文表示の手順を示すフローチャートである。「ＰＶ起
動」ボタンがクリックされると（ステップＳ１５０１：
Ｙｅｓ）、当該ボタンに埋め込まれたスクリプトが実行
される結果、この評価表の対象となっている出願の公開
番号（のみ）を記述したＰＶ起動ファイルが作成（ステ
ップＳ１５０２）・実行（ステップＳ１５０３）され
て、図７に示した検索結果画面になる（ステップＳ１５
０４）。この画面で公報をダブルクリックすれば（ステ
ップＳ１５０５：Ｙｅｓ）、その全文を表示させること
ができる（ステップＳ１５０６）。

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

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

【００５１】なお、初期状態すなわち評価表を開いた直
後の時点でどのセクションが表示されているか、そして
表示されているセクションのうちどのセクションが開き
どのセクションが閉じているかは、評価がどの段階まで
進んでいるかによって異なるが、この点については後述
する。

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

【００５３】ａ）自己に代わる担当者を自ら決定する場
合 まず、図５に示した評価表の「編集」ボタンをクリック
して、当該文書を編集モード（編集可能な状態）にす
る。図９は編集モードの評価表、特にその「知財区担当
者」セクション付近の一例を示す説明図である。

【００５４】図中、「知財区担当者」の項目にある「ア
ドレス帳より選択」ボタンをクリックすると、図１０に
示すようなアドレス帳が表示されるので、自己以外の適
切な担当者を選択して「ＯＫ」ボタンをクリックする。
この後「担当者変更」ボタンをクリックすると、変更後
の担当者へ図３に示したのと同様の作業依頼メールが送
信される。

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

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

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

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

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

【００６０】まず、図５に示した評価表の「編集」ボタ
ンをクリックして、当該文書を編集モードにする。図１
４は編集モードの評価表、特にその「開発区評価者」セ
クション付近の一例を示す説明図である。

【００６１】図中、「開発区評価者」の項目にある「発
明者リストより選択」ボタンをクリックすると、図１５
に示すような、当該評価表に設定された発明者のリスト
が表示される。また、図１４の評価表で「アドレス帳よ
り選択」ボタンをクリックすると、図１０に示したのと
同様のアドレス帳が表示される。この発明者リスト、あ
るいはアドレス帳から適切な評価者を選択してＯＫした
後、「評価依頼」ボタンをクリックすると、変更後の評
価者へ図１６に示すような作業依頼メールが送信され
る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１０２】そして、本システムにおいてはの扱いに
なった場合の代理人への依頼作業や、の扱いになった
場合の代理人への通知作業（自社により審査請求をおこ
なった旨の）についても種々の支援をおこなっている
が、本発明とは直接の関係がないので、ここでは説明を
省略する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１２０】（サーバ１０２およびそのクライアントの
ハードウェア構成）つぎに、本発明の実施の形態による
ワークフロー支援システムの中核をなす、サーバ１０
２、知財区ＰＣ１０３および開発区ＰＣ１０４のハード
ウェア構成について説明する。説明の便宜上、これらの
コンピュータ（および電子申請専用端末１０５、ＳＰの
サーバ１０６あるいは各特許事務所のＰＣ１０７も）は
同一のハードウェア構成を有するものとする。

【０１２１】図４０は、本発明の実施の形態によるサー
バ１０２およびそのクライアントであるＰＣ１０３・Ｐ
Ｃ１０４のハードウェア構成を示す説明図である。図
中、８８０１は装置全体を制御するＣＰＵを、８８０２
は基本入出力プログラムを記憶したＲＯＭを、８８０３
はＣＰＵ８８０１のワークエリアとして使用されるＲＡ
Ｍを、それぞれ示している。

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

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

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

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

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

【０１２７】図中、８９０１〜８９０３はサーバ１０２
の機能部である。８９０１は評価表データ記憶部であ
り、上述の審査請求評価表を構成する（評価表に流し込
まれる、と言ってもよい）各種のデータを保持してい
る。このデータには発明の名称や要約などのほか、その
知財区担当者・承認者、開発区評価者・承認者、各人に
よる評価結果などがある。

【０１２８】８９０２は評価表作成部であり、任意の出
願につきその評価表のオープン指示が入力されると、評
価表データ記憶部８９０１に保持された各種データか
ら、当該出願の評価表を作成する。まず、評価表作成部
８９０２はその要約文読み出し部８９０２ａおよび公開
番号読み出し部８９０２ｂにより、少なくとも上記出願
の要約文と公開番号とを読み出す。なお、評価表作成部
８９０２は上記のほかにも、評価表に流し込むための多
数のデータを読み出すが、そのための各機能部は同図で
は省略している。

【０１２９】そして、読み出したデータをその文書設計
情報記憶部８９０２ｃに保持された文書設計情報（フォ
ーム）にしたがって配置することで、図５、図１８ある
いは図３０に示したような文書を生成する。なお、図中
「ＰＶ起動」ボタンには、上述のようにこの評価表の作
成対象である出願の公開番号が埋め込まれている。そし
て、評価表作成部８９０２は上記文書を、後述するＰＣ
１０３・１０４側の評価表表示部８９０４に対して送信
する。

【０１３０】８９０３は公報検索部であり、後述するＰ
Ｃ１０３・１０４側の公報検索指示部８９０５ａから検
索条件（手入力されたものであると、「ＰＶ起動」ボタ
ンから吐き出されたものであるとを問わない）を示して
公報の検索が指示された場合に、当該条件に合致する公
報を検索して、ヒットした公報の公開番号を要求元に送
信する。そしてＰＣ１０３・１０４側の公報表示指示部
８９０５ｂから、さらに上記番号で特定される公報の表
示が指示された場合に、上記公報の全文を要求元に送信
する。

【０１３１】なお実際のシステムでは、公報データはサ
ーバ１０２とは別のＰＶサーバ（図示せず）により管理
され、その検索などはサーバ１０２からさらにＰＶサー
バに依頼しておこなわせることになる。もっともこれは
既存のシステム（ＰＶ）を使い回すという、主として経
済的な事情によるものであるので、サーバ１０２自身で
公報データを管理するように構成してもなんら差し支え
ない。

【０１３２】つぎに、８９０４および８９０５はサーバ
１０２のクライアントであるＰＣ１０３・１０４の機能
部である。まず、８９０４は評価表表示部であり、評価
表作成部８９０２から送信されてきた評価表をディスプ
レイ８８０８上に表示する。

【０１３３】８９０５は公報検索・表示部であり、公報
検索指示部８９０５ａおよび公報表示指示部８９０５ｂ
を含む構成である。公報検索指示部８９０５ａは、評価
表表示部８９０４により表示中の評価表で「ＰＶ起動」
ボタンがクリックされたことを検知すると、当該ボタン
に埋め込まれている公開番号を検索条件として、サーバ
１０２側の公報検索部８９０３に送信する。

【０１３４】そして公報検索・表示部８９０５は、公報
検索部８９０３から返信されてきた、上記検索条件に合
致する出願の公開番号（この場合は一つのみであるが）
をディスプレイ８８０８上に表示する。このときの画面
が図７に示したものである。

【０１３５】そしてその公報表示指示部８９０５ｂは、
上記画面でいずれかの項目（といっても一つしかない
が）がダブルクリックされたことを検知すると、公報全
文の取得要求をサーバ１０２側の公報検索部８９０３に
送信する。これを受けて公報検索部８９０３から返信さ
れてきた全文は、公報検索・表示部８９０５によりＰＣ
１０３・１０４のディスプレイ８８０８上に表示され
る。

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

【０１３７】また、図４１に示す評価表作成部８９０２
が、請求項にいう「第１の配置手段」および「第２の配
置手段」を兼ね、そのおこなう処理の中に請求項にいう
「第１の配置ステップ」および「第２の配置ステップ」
が含まれる。また、特にその要約文読み出し部８９０２
ａが請求項にいう「第１の読み出し手段」に、そのおこ
なう処理が請求項にいう「第１の読み出しステップ」
に、それぞれ相当する。また、特にその公開番号読み出
し部８９０２ｂが請求項にいう「第２の読み出し手段」
に、そのおこなう処理が請求項にいう「第２の読み出し
ステップ」に、それぞれ相当する。

【０１３８】また、公報検索部８９０３が請求項にいう
「第３の読み出し手段」に相当し、そのおこなう処理の
中に請求項にいう「第３の読み出しステップ」が含まれ
る。また、評価表表示部８９０４が請求項にいう「第１
の表示手段」に相当し、そのおこなう処理の中に請求項
にいう「第１の表示ステップ」が含まれる。

【０１３９】また、公報検索・表示部８９０５が請求項
にいう「第２の表示手段」に相当し、そのおこなう処理
の中に請求項にいう「第２の表示ステップ」が含まれ
る。また、特にその公報検索指示部８９０５ａが請求項
にいう「検知手段」に相当し、そのおこなう処理の中に
請求項にいう「検知ステップ」が含まれる。

【０１４０】以上説明したように本実施の形態にかかる
ワークフロー支援システムによれば、ワークフロー内の
各作業者は、評価表に配置された「ＰＶ起動」ボタンを
クリックするだけで所望の公報の全文を閲覧することが
でき、逐一その公開番号を入力してサーチをかけるな
ど、煩雑な作業は一切不要である。そのため各人の扱う
出願件数が多数にのぼっても、各発明の詳細な内容をス
ムーズに確認することができる。

【０１４１】なお、上述した実施の形態では「ＰＶ起
動」ボタンをクリックすると、図７に示した検索結果画
面でいわば一息おいてから、その全文の表示に移行する
ようにしたが、これは既存のシステム（ＰＶ）を流用す
ることにともなう制限であって本質的なものではない。
したがって、「ＰＶ起動」ボタンをクリックすると直接
その公報の全文が表示されるようにしてもなんら差し支
えない（むしろそのほうが便宜である）。

【０１４２】また、上述した実施の形態では「ＰＶ起
動」ボタンに埋め込まれるのは公開番号であるものとし
たが、これも特に公開番号である必要はなく、どの公報
かを特定できる情報であれば何であってもよい。また、
その埋め込み先はボタンでなくともよく、たとえばメニ
ュー内の文字列などであってもよい。

【０１４３】

【発明の効果】以上説明したように本発明によれば、電
子文書に記述された情報の価値を評価するための複数の
工程からなり、前記電子文書に記述された情報または当
該電子文書に記述された情報の格納先に関する情報を前
記各工程における作業者のメールアドレスに対して電子
メールで送信することにより、前記電子文書に記述され
た情報の価値の評価をおこなうワークフローの支援シス
テムにおいて、前記電子文書に記述された情報の要約文
を読み出す第１の読み出し手段と、前記電子文書に記述
された情報を特定するための情報を読み出す第２の読み
出し手段と、あらかじめ定められた文書設計情報にもと
づいて、前記第１の読み出し手段により読み出された要
約文を前記電子文書内の所定の位置に配置する第１の配
置手段と、あらかじめ定められた文書設計情報にもとづ
いて、前記第２の読み出し手段により読み出された情報
を保持する操作ボタンを前記電子文書内の所定の位置に
配置する第２の配置手段と、前記第１の配置手段および
第２の配置手段により前記要約文および前記操作ボタン
を配置された前記電子文書を表示する第１の表示手段
と、前記第１の表示手段により表示された前記電子文書
内に配置された前記操作ボタンが押下されたことを検知
する検知手段と、前記検知手段により前記操作ボタンが
押下されたことを検知した場合に、前記操作ボタンに保
持されている前記第２の読み出し手段により読み出され
た情報にもとづいて、前記電子文書に記述された情報の
全文を読み出す第３の読み出し手段と、前記第３の読み
出し手段により読み出された全文を表示する第２の表示
手段と、を備えたので、電子文書内に配置された操作ボ
タンを押下するだけで、そこに表示された要約文の原文
（要約文の元となった全文）を表示させることができ、
これによって、大量の電子文書に記述された情報の詳細
を容易に確認することが可能なワークフロー支援システ
ムが得られるという効果を奏する。

【０１４４】また、別の発明によれば、電子文書に記述
された情報の価値を評価するための複数の工程からな
り、前記電子文書に記述された情報または当該電子文書
に記述された情報の格納先に関する情報を前記各工程に
おける作業者のメールアドレスに対して電子メールで送
信することにより、前記電子文書に記述された情報の価
値の評価をおこなうワークフローの支援方法において、
前記電子文書に記述された情報の要約文を読み出す第１
の読み出しステップと、前記電子文書に記述された情報
を特定するための情報を読み出す第２の読み出しステッ
プと、あらかじめ定められた文書設計情報にもとづい
て、前記第１の読み出しステップで読み出された要約文
を前記電子文書内の所定の位置に配置する第１の配置ス
テップと、あらかじめ定められた文書設計情報にもとづ
いて、前記第２の読み出しステップで読み出された情報
を保持する操作ボタンを前記電子文書内の所定の位置に
配置する第２の配置ステップと、前記第１の配置ステッ
プおよび第２の配置ステップで前記要約文および前記操
作ボタンを配置された前記電子文書を表示する第１の表
示ステップと、前記第１の表示ステップで表示された前
記電子文書内に配置された前記操作ボタンが押下された
ことを検知する検知ステップと、前記検知ステップで前
記操作ボタンが押下されたことを検知した場合に、前記
操作ボタンに保持されている前記第２の読み出しステッ
プで読み出された情報にもとづいて、前記電子文書に記
述された情報の全文を読み出す第３の読み出しステップ
と、前記第３の読み出しステップで読み出された全文を
表示する第２の表示ステップと、を含んだので、電子文
書内に配置された操作ボタンを押下するだけで、そこに
表示された要約文の原文（要約文の元となった全文）を
表示させることができ、これによって、大量の電子文書
に記述された情報の詳細を容易に確認することが可能な
ワークフロー支援方法が得られるという効果を奏する。

【０１４５】また、別の発明によれば、電子文書に記述
された情報の価値を評価するための複数の工程からな
り、前記電子文書に記述された情報または当該電子文書
に記述された情報の格納先に関する情報を前記各工程に
おける作業者のメールアドレスに対して電子メールで送
信することにより、前記電子文書に記述された情報の価
値の評価をおこなうワークフローの支援プログラムにお
いて、前記電子文書に記述された情報の要約文を読み出
す第１の読み出しステップと、前記電子文書に記述され
た情報を特定するための情報を読み出す第２の読み出し
ステップと、あらかじめ定められた文書設計情報にもと
づいて、前記第１の読み出しステップで読み出された要
約文を前記電子文書内の所定の位置に配置する第１の配
置ステップと、あらかじめ定められた文書設計情報にも
とづいて、前記第２の読み出しステップで読み出された
情報を保持する操作ボタンを前記電子文書内の所定の位
置に配置する第２の配置ステップと、前記第１の配置ス
テップおよび第２の配置ステップで前記要約文および前
記操作ボタンを配置された前記電子文書を表示する第１
の表示ステップと、前記第１の表示ステップで表示され
た前記電子文書内に配置された前記操作ボタンが押下さ
れたことを検知する検知ステップと、前記検知ステップ
で前記操作ボタンが押下されたことを検知した場合に、
前記操作ボタンに保持されている前記第２の読み出しス
テップで読み出された情報にもとづいて、前記電子文書
に記述された情報の全文を読み出す第３の読み出しステ
ップと、前記第３の読み出しステップで読み出された全
文を表示する第２の表示ステップと、をコンピュータに
実行させるので、電子文書内に配置された操作ボタンを
押下するだけで、そこに表示された要約文の原文（要約
文の元となった全文）を表示させることができ、これに
よって、大量の電子文書に記述された情報の詳細を容易
に確認することが可能なワークフロー支援プログラムが
得られるという効果を奏する。

【０１４６】また、別の発明によれば、上記発明にかか
るプログラムを記録したことで、そのプログラムをコン
ピュータ読み取り可能とすることができ、これによっ
て、上記発明の処理をコンピュータによって実現するこ
とが可能な記録媒体が得られるという効果を奏する。

【図面の簡単な説明】

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

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

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

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

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

【図６】ＰＶ（Ｐａｔｅｎｔ Ｖｉｅｗｅｒ）のクライ
アントで表示される公報検索用画面の一例を示す説明図
である。

【図７】ＰＶのクライアントで表示される検索結果画面
の一例を示す説明図である。

【図８】「ＰＶ起動」ボタンによる公報全文表示の手順
を示すフローチャートである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図４０】本発明の実施の形態によるサーバ１０２およ
びそのクライアントであるＰＣ１０３・１０４のハード
ウェア構成を示す説明図である。

【図４１】本発明の実施の形態によるサーバ１０２およ
びそのクライアントであるＰＣ１０３・１０４の機能的
構成を示す説明図である。

【符号の説明】

１０１ メインフレーム １０１ａ 国内特実マスタ １０１ｂ 人事マスタ １０２ サーバ １０２ａ 審査請求ＤＢ １０３ 知財区ＰＣ １０４ 開発区ＰＣ １０５ 電子申請専用端末 １０６ ＳＰのサーバ １０６ａ 事務所ＤＢ １０７ 特許事務所ＰＣ ８８０１ ＣＰＵ ８８０２ ＲＯＭ ８８０３ ＲＡＭ ８８０４ ＨＤＤ ８８０５ ＨＤ ８８０６ ＦＤＤ ８８０７ ＦＤ ８８０８ ディスプレイ ８８０９ ネットワークＩ／Ｆ ８８１０ 通信ケーブル ８８１１ キーボード ８８１２ マウス ８８１３ ＣＤ−ＲＯＭ ８８１４ ＣＤ−ＲＯＭドライブ ８８１５ バスまたはケーブル ８９０１ 評価表データ記憶部 ８９０２ 評価表作成部 ８９０２ａ 要約文読み出し部 ８９０２ｂ 公開番号読み出し部 ８９０２ｃ 文書設計情報記憶部 ８９０３ 公報検索部 ８９０４ 評価表表示部 ８９０５ 公報検索・表示部 ８９０５ａ 公報検索指示部 ８９０５ｂ 公報表示指示部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 深作 千恵子 東京都大田区中馬込１丁目３番６号 株式 会社リコー内 (72)発明者 野村 延史 東京都大田区中馬込１丁目３番６号 株式 会社リコー内 (72)発明者 鈴木 康志 東京都大田区中馬込１丁目３番６号 株式 会社リコー内 (72)発明者 森木 俊晴 東京都大田区中馬込１丁目３番６号 株式 会社リコー内 (72)発明者 高橋 勝彦 東京都台東区東上野２−１−11 Ｆターム(参考） 5B075 KK07 ND02 ND36 PP12 PQ02 PQ40 UU05 5E501 AA30 BA20 CA01 EA10

Claims (11)

【特許請求の範囲】
1. 【請求項１】 電子文書に記述された情報の価値を評価
   するための複数の工程からなり、前記電子文書に記述さ
   れた情報または当該電子文書に記述された情報の格納先
   に関する情報を前記各工程における作業者のメールアド
   レスに対して電子メールで送信することにより、前記電
   子文書に記述された情報の価値の評価をおこなうワーク
   フローの支援システムにおいて、 前記電子文書に記述された情報の要約文を読み出す第１
   の読み出し手段と、 前記電子文書に記述された情報を特定するための情報を
   読み出す第２の読み出し手段と、 あらかじめ定められた文書設計情報にもとづいて、前記
   第１の読み出し手段により読み出された要約文を前記電
   子文書内の所定の位置に配置する第１の配置手段と、 あらかじめ定められた文書設計情報にもとづいて、前記
   第２の読み出し手段により読み出された情報を保持する
   操作ボタンを前記電子文書内の所定の位置に配置する第
   ２の配置手段と、 前記第１の配置手段および第２の配置手段により前記要
   約文および前記操作ボタンを配置された前記電子文書を
   表示する第１の表示手段と、 を備えたことを特徴とするワークフロー支援システム。
2. 【請求項２】 さらに、前記第１の表示手段により表示
   された前記電子文書内に配置された前記操作ボタンが押
   下されたことを検知する検知手段と、 前記検知手段により前記操作ボタンが押下されたことを
   検知した場合に、前記操作ボタンに保持されている前記
   第２の読み出し手段により読み出された情報にもとづい
   て、前記電子文書に記述された情報の全文を読み出す第
   ３の読み出し手段と、 前記第３の読み出し手段により読み出された全文を表示
   する第２の表示手段と、 を備えたことを特徴とする前記請求項１に記載のワーク
   フロー支援システム。
3. 【請求項３】 前記第３の読み出し手段は、さらに、操
   作者から入力された任意の情報で特定される情報の全文
   を読み出すことを特徴とする前記請求項２に記載のワー
   クフロー支援システム。
4. 【請求項４】 前記電子文書に記述された情報とは特許
   出願中の発明に関する情報であり、前記評価とは前記発
   明について審査請求をおこなう価値があるか否かの評価
   であることを特徴とする前記前記請求項１〜請求項３の
   いずれか一つに記載のワークフロー支援システム。
5. 【請求項５】 電子文書に記述された情報の価値を評価
   するための複数の工程からなり、前記電子文書に記述さ
   れた情報または当該電子文書に記述された情報の格納先
   に関する情報を前記各工程における作業者のメールアド
   レスに対して電子メールで送信することにより、前記電
   子文書に記述された情報の価値の評価をおこなうワーク
   フローの支援方法において、 前記電子文書に記述された情報の要約文を読み出す第１
   の読み出しステップと、 前記電子文書に記述された情報を特定するための情報を
   読み出す第２の読み出しステップと、 あらかじめ定められた文書設計情報にもとづいて、前記
   第１の読み出しステップで読み出された要約文を前記電
   子文書内の所定の位置に配置する第１の配置ステップ
   と、 あらかじめ定められた文書設計情報にもとづいて、前記
   第２の読み出しステップで読み出された情報を保持する
   操作ボタンを前記電子文書内の所定の位置に配置する第
   ２の配置ステップと、 前記第１の配置ステップおよび第２の配置ステップで前
   記要約文および前記操作ボタンを配置された前記電子文
   書を表示する第１の表示ステップと、 を含んだことを特徴とするワークフロー支援方法。
6. 【請求項６】 さらに、前記第１の表示ステップで表示
   された前記電子文書内に配置された前記操作ボタンが押
   下されたことを検知する検知ステップと、 前記検知ステップで前記操作ボタンが押下されたことを
   検知した場合に、前記操作ボタンに保持されている前記
   第２の読み出しステップで読み出された情報にもとづい
   て、前記電子文書に記述された情報の全文を読み出す第
   ３の読み出しステップと、 前記第３の読み出しステップで読み出された全文を表示
   する第２の表示ステップと、 を含んだことを特徴とする前記請求項５に記載のワーク
   フロー支援方法。
7. 【請求項７】 前記第３の読み出しステップでは、さら
   に、操作者から入力された任意の情報で特定される情報
   の全文を読み出すことを特徴とする前記請求項６に記載
   のワークフロー支援方法。
8. 【請求項８】 前記電子文書に記述された情報とは特許
   出願中の発明に関する情報であり、前記評価とは前記発
   明について審査請求をおこなう価値があるか否かの評価
   であることを特徴とする前記請求項５〜請求項７のいず
   れか一つに記載のワークフロー支援方法。
9. 【請求項９】 電子文書に記述された情報の価値を評価
   するための複数の工程からなり、前記電子文書に記述さ
   れた情報または当該電子文書に記述された情報の格納先
   に関する情報を前記各工程における作業者のメールアド
   レスに対して電子メールで送信することにより、前記電
   子文書に記述された情報の価値の評価をおこなうワーク
   フローの支援プログラムにおいて、 前記電子文書に記述された情報の要約文を読み出す第１
   の読み出しステップと、 前記電子文書に記述された情報を特定するための情報を
   読み出す第２の読み出しステップと、 あらかじめ定められた文書設計情報にもとづいて、前記
   第１の読み出しステップで読み出された要約文を前記電
   子文書内の所定の位置に配置する第１の配置ステップ
   と、 あらかじめ定められた文書設計情報にもとづいて、前記
   第２の読み出しステップで読み出された情報を保持する
   操作ボタンを前記電子文書内の所定の位置に配置する第
   ２の配置ステップと、 前記第１の配置ステップおよび第２の配置ステップで前
   記要約文および前記操作ボタンを配置された前記電子文
   書を表示する第１の表示ステップと、 をコンピュータに実行させることを特徴とするワークフ
   ロー支援プログラム。
10. 【請求項１０】 さらに、前記第１の表示ステップで表
    示された前記電子文書内に配置された前記操作ボタンが
    押下されたことを検知する検知ステップと、 前記検知ステップで前記操作ボタンが押下されたことを
    検知した場合に、前記操作ボタンに保持されている前記
    第２の読み出しステップで読み出された情報にもとづい
    て、前記電子文書に記述された情報の全文を読み出す第
    ３の読み出しステップと、 前記第３の読み出しステップで読み出された全文を表示
    する第２の表示ステップと、 をコンピュータに実行させることを特徴とする前記請求
    項９に記載のワークフロー支援プログラム。
11. 【請求項１１】 前記請求項９または請求項１０に記載
    のプログラムを記録したコンピュータ読み取り可能な記
    録媒体。