JP2001325389A - 情報処理装置及び方法並びにプログラム記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、知財情報を効率よく管理すること
ができる情報処理装置、情報処理方法およびプログラム
記憶媒体を提供することを目的とする。 【解決手段】 ネットワークを介して情報を通信するこ
とにより、単一の案件を複数人が検討する検討システム
において用いられる情報処理装置であって、１の検討者
から第２の検討者に対して第１の情報を添付して所定の
案件の検討を依頼する第１の通信手段と、前記第１の通
信手段による検討の依頼時に前記第１の情報に含まれて
いなかった第２の情報を前記所定の案件の検討のために
前記第２の検討者に対して送付する第２の通信手段とを
有することを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理装置、情
報処理方法、およびプログラム記憶媒体、詳しくは、文
書管理機能を有する情報処理装置、情報処理方法および
プログラム記憶媒体に関するものである。

【０００２】

【従来の技術】近年、特許関連の文書の電子化は急速に
進んできており、ＣＤ−ＲＯＭを媒体とした特許庁発行
の公開、登録公報の電子化を始め、ネットワーク接続に
よる特許庁への出願、特許庁からの発送書類の受け取り
等、いわゆるＩＴ技術を利用したデータのやり取りが一
般的になってきた。

【０００３】また、最近ではインターネットを利用した
検索システムや各種情報の公開などが盛んに行われてい
る。

【０００４】一方、各企業では以前より、自社で出願し
た特許・実用新案などの知的財産を管理するためのコン
ピュータシステムが構築されてきたが、そのほとんどの
システムは、主に、たとえば特許等の出願日や出願番号
といったような、書誌情報のデータをデータベース等で
管理し、それを検索・表示しながら必要な期限管理等を
行うものであった。

【０００５】

【発明が解決しようとする課題】しかしながら、前述し
た文書の電子化、ネットワーク環境の進歩により、文書
形式で構成される、いわゆる特許出願の文書部分につい
ても、電子的に管理し、通常の期限管理のみでなく、発
明者からの提案管理、また特許事務所とネットワークを
結んで、出願書類や特許庁とのやりとりで使用する書類
そのものも管理する必要性が生じてきている。

【０００６】特に、ある書類を作成するためにネットワ
ークを用いて、その案件を複数人が順次検討する場合
に、その検討の材料がすべて揃わないと次の検討者が検
討できないとすると、書類がすべて揃うまで次の検討者
に検討を回せず、トータルでの検討時間が増大するとい
う問題が考えられる。

【０００７】そこで本願は、かかる必要性に鑑み、ネッ
トワークにおける効率的な検討システムを構築できる情
報処理装置、情報処理方法およびプログラム記憶媒体を
提供することを目的とする。

【０００８】

【課題を解決するための手段】上記課題を解決するた
め、本願の情報処理装置は、ネットワークを介して情報
を通信することにより、単一の案件を複数人が検討する
検討システムにおいて用いられる情報処理装置であっ
て、第１の検討者から第２の検討者に対して第１の情報
を添付して所定の案件の検討を依頼する第１の通信手段
と、前記第１の通信手段による検討の依頼時に前記第１
の情報に含まれていなかった第２の情報を前記所定の案
件の検討のために前記第２の検討者に対して送付する第
２の通信手段とを有することを特徴とする。

【０００９】本願の他の発明の態様は、以下の詳細な説
明及び特許請求の範囲の記載から明らかになるであろ
う。

【００１０】

【発明の実施の形態】（第１の実施の形態）以下に添付
の図面を参照して、本発明の第１の実施の形態について
説明する。

【００１１】（知的財産管理システム全体構成）図１は
本実施の形態の知的財産管理システムの代表的な構成を
示す図である。

【００１２】図１において、１０７は研究・開発・製造
・販売などの経済活動を営む企業の本社であり、特許な
どの知的財産を管理する部門を含む。

【００１３】１０４は知的財産管理部門であり、文書サ
ーバ１１６、管理サーバ１１７、サーバ１１８、１１
９、１２０などを保有する。

【００１４】文書サーバ１１６は、電子的に作成された
文書そのものや特許庁とのやりとりで生じる一連の文書
からなる包袋などを管理するための文書ＤＢ（データベ
ース）を含む。管理サーバ１１は、出願番号、特許番
号、出願日、登録日その他の書誌的情報や特許庁のオフ
ィスアクションの期限、管理するＤＢを含む。サーバ１
１８は、日本特許や米国特許など特定の公報を記憶する
汎用ＤＢを含む。サーバ１１９は、後述のワークフロー
などを管理するアプリケーションシステムやその他のデ
ータベース（例えば引用文献データベース）を構成す
る。サーバ１２０は、サーバ１１６〜１１９を統合管理
し、知財情報管理システム全体を制御する。以下本実施
の形態で「システム」というときは、サーバ１２０によ
って管理されるシステムを指すものとする。

【００１５】これらの構成要素は全て基幹のネットワー
ク１２７に接続されている。ただし、この部門の上の構
成要素は同一のコンピュータマシンで実現されていても
かまわない。

【００１６】文書サーバ１１６に格納されうる文書とし
ては、通常のテキスト文書や通常イメージ情報として格
納される図面など、さらにテキストとイメージが混在し
たミックスモード文書、ワープロ固有のフォーマットの
文書などがある。電子的に作成された、特許庁とのやり
取りで使う書類や社内書類は、サーバ１１９のアプリケ
ーションシステムにより文書サーバ１１６のもつ文書デ
ータベースに格納される。通常、この文書データベース
には、その文書を特定するための番号が付与されてお
り、管理サーバ１１７にもつ書誌的項目の管理データベ
ースとリンクされている。

【００１７】１０５は知的財産（知財）権利化部門であ
り、特許庁と直接・間接に文書のやり取りすることで知
的財産の権利を取得する部門である。

【００１８】１０６は知財権利化支援部門であり、例え
ば、特許出願原稿の電子化や期限管理など権利化の支援
を行う部門である。

【００１９】１０１は研究・開発を行う部門であり、実
際の研究・開発部門１０２と開発における知的財産の権
利化を支援する開発権利化支援部門１０３を含む。

【００２０】知財権利化部門１０５、知財権利化支援部
門１０６は通常業務として、知財関係の情報入力、文書
作成などの作業を行うことを前提としており、原則とし
てクライアントＰＣの専用アプリケーション画面で作業
する事ができる。一方、研究・開発部門１０２は、通常
は研究開発を業務としており、知財関係の作業は付随的
に発生するものであることから、社内知財情報管理部門
１０７のサーバ１１６〜１１９を社内ネットワークを通
じてアクセスし、Ｗｅｂ画面として表示させ、処理する
ことができる。Ｗｅｂ画面を開くべきタイミングは社内
電子メールを対象者に送ることによりその対象者に知ら
せることができる。

【００２１】１０８は、日本国内に存在する複数の国内
関係会社、１０９は日本国外に存在する複数の海外関係
会社である。これらは、専用回線（送信側、受信側およ
びデータの伝送経路が特定されている電子メール、ファ
クシミリ通信など）によりセキュリティが保証された状
態での通信が可能な状態となっている。

【００２２】１１０は、本社１０７、国内関係会社１０
８、海外関係会社１０９から構成される企業グループで
ある。

【００２３】一方１１１は企業グループ１１０と共同研
究・開発を行う複数の外部会社である。両者は相互の契
約に基づき共同研究・開発の成果物を管理し、特許権利
化などの作業を行う。上記システムに対しては、インタ
ーネットによりデータの送受信が可能である。

【００２４】１１２は、日本国内に存在する複数の知財
関連事務所であり、１１３は日本国外に存在する複数の
知財関連事務所である。これらは、上記システムに対し
て、上述のような専用線あるいはインターネットによ
り、データの送受信が可能である。

【００２５】１１４は日本国特許庁であり、上記システ
ムとの間ではオンライン端末で結ばれている。

【００２６】１１５は、複数の外国の特許庁であり、グ
ループ会社１１０との間では、海外事務所１１３を介し
て主として書面により手続きを行う。

【００２７】以上の各部門は、それぞれ情報の入出力等
に用いられる複数の端末ＰＣなどを有する。各部門の構
成員はそれぞれＩＤとパスワードを有し、上述のシステ
ムに対して直接・間接にアクセスすることができる。

【００２８】各部門にはそれぞれネットワーク接続され
たクライアントコンピュータが複数存在し、サーバ１１
６〜１２０の持つデータを表示させたり、サーバ１１６
〜１２０の持つデータを特定のフォーマットでプリンタ
により印刷したりすることができる。また、必要に応じ
て、イメージ入力のためのスキャナを有する。

【００２９】情報の流出の度合いは複数段階に管理され
る。例えば、１２３と１２４の間すなわち知財情報管理
部門内は、高度な情報がすべて集中し、自由に流通する
ことから、ここから出て行く情報の量的（情報の量）、
質的（情報の種類）双方について、厳しい規制をかける
必要がある。

【００３０】また、１２２から１２５の間すなわち本社
内では、情報の流通範囲が広くなるので、部門外閲覧禁
止など情報の流れに制限をつけ、特定の部門に高度な情
報が大量に流通しないようにする。１２１と１２６の
間、すなわちグループ会社内は、情報の流通範囲がより
広くなるので、各部門に流出する情報の量および質を更
に規制する。

【００３１】一方セキュリティチェック度合いとして
は、および,流通する情報の量と質、および、情報流出
のリスクの大きさに応じて、セキュリティチェックの度
合いを決定する。

【００３２】（知的財産管理システムでの情報の流れ）
図２は、上記知的財産管理システムにおける情報の流通
経路を示す図である。

【００３３】日本国特許庁１１４との間では、国内事務
所１１２または知財権利化支援部門が書面やデータのや
り取りを行う。外国特許庁１１5との間では、海外事務
所１１3が書面やデータのやり取りを行う。海外事務所
１１３は国内事務所１１２または知財権利化支援部門１
０６を介して書面やデータのやり取りを行う。国内に入
った電子化情報は必要に応じて知財情報管理部門１０４
のシステムに登録される。知財情報管理部門１０４は必
要に応じて、知財権利化支援部門１０６、知財権利化部
門１０５、開発権利化支援部門１０３、研究・開発部門
１０２に対して情報を供給したり、情報のシステム登録
を行う。外部会社１１１、国内関係会社１０８、海外関
係会社１０９は、本社１０７の各部門との間で、必要に
応じて書類、データのやり取りを行う。

【００３４】図３は、知財権利化部門１０５、開発権利
化支援部門１０３、研究・開発部門１０２における組織
図の例である。

【００３５】例えば、知財権利化部門１０５は、担当者
Ａ・Ｂの上司として課長Ａ、担当者Ｃの上司として課長
Ｂ、担当者Ｄ・Ｅの上司として課長Ｃ、課長Ａ・Ｂの上
司として部長Ａ、課長Ｃの上司として部長Ｂ、部長Ａ・
Ｂの上司として所長Ａという組織を構成している。

【００３６】また、開発権利化支援部門１０３は、担当
者Ｆ・Ｇの上司として課長Ｄ、担当者Ｈの上司として課
長Ｅ、担当者Ｉ・Ｊの上司として課長Ｆ、課長Ｄ・Ｅの
上司として部長Ｃ、課長Ｆの上司として部長Ｄ、部長Ｃ
・Ｄの上司として所長Ｂという組織を構成している。

【００３７】また、研究・開発部門１０２は、発明者Ａ
・Ｂの上司として課長Ｇ、発明者Ｃの上司として課長
Ｈ、発明者Ｄ・Ｅの上司として課長Ｉ、課長Ｇの上司と
して部長Ｅ、課長Ｈの上司として部長Ｄ、部長Ｃ・Ｄの
上司として所長Ｂという組織を表している。このシステ
ムにおいては、組織の構成とともに、その組織を構成す
る人物を対応付けて人名コード（従業者のＩＤ番号）を
テーブル化してサーバ１１９に記憶させておく。

【００３８】このような組織情報をテーブルとしてシス
テムに記憶させておくことにより、例えば、上司の承認
のために自動的に書類（メール）の送り先を自動設定す
ることができたり、順序の違う書類転送に対してエラー
チェックをかけることができるなど、システムの機能を
より使用者にとって使いやすくすることができる。反
面、このような組織情報は、定期的に更新し、正確な情
報を保たなければならず、そのメンテナンスは大きな負
荷となりうる。このような組織情報をシステムに記憶さ
せるかどうかは、例えば部門ごとに決めることもでき、
変更の少ない部門やメンテナンスの負荷を考慮してもシ
ステムを使いやすくなる部門については、システムに記
憶させておくことが好ましい。

【００３９】図４は、本実施の形態におけるデータベー
ス管理の方法を説明する図である。

【００４０】図４において、４０１は管理サーバ１１７
に含まれる管理ＤＢを表す。ここには各種管理項目４０
２が案件単位で記憶される。そして,管理項目はクライ
アントＰＣ上の画面４０３から設定することができる。

【００４１】４０４から４０６は、各案件についての書
類作成の単位となるユニットを表す。このユニットを本
実施の形態では「アクション」と呼び、この書類作成の
ために「アクションケース」というシステム上の仮想の
ファイルケースを定義する。

【００４２】例えば、管理番号１２３４５６７の出願と
いう「アクション」４０４に対しては既に社内の発明提
案のための書類である提案書、願書、明細書、図面、要
約書等の文書４０７が作成されており、クライアントＰ
Ｃ上の画面４０８において、出願日、発明者などの出願
に付随する管理データが確定されている。前者の文書４
０７については、文書サーバ１１６に形成される後述の
電子包袋４１２に登録され、後者の管理データについて
は、管理項目４０２としてＤＢ４０１に登録される。こ
のアクションケースをユーザが表示させたい場合には、
管理項目については管理ＤＢ４０１をアクセスすること
により、また文書４０７については、電子包袋４１２と
リンクを張ることにより、実現することができる。

【００４３】管理番号１２３４５７８の出願という「ア
クション」４０５に対しては、出願書類が現在まだ作成
されていない状態なので、提案書４０９のみがシステム
に登録されている。

【００４４】また、特願平１０−１０１号の拒絶理由通
知という「アクション」４０６に対しては手続補正書４
１１が登録されている。

【００４５】その他アクションとしては、拒絶査定、補
正却下、異議申し立て、審査請求、手続補正指令応答等
の法上の手続に対する対処が考えられる。

【００４６】また、文書サーバ１１６内に形成される電
子包袋４１２の内容としては、案件ごとの書類４１３の
他に第三者の特許情報などの閲覧書類４１４や、その案
件について特許庁による審査の引用文献（引例）４１５
などが考えられるが、引例４１５は上述のように、別の
サーバ１１９にＤＢを構成してもよく、ＨＴＭＬのリン
クによって案件のアクセスから容易に情報が引き出せる
ようにすることができる。

【００４７】ＤＢ４０１から電子包袋４１２へはリンク
が張られているとともに、電子包袋４１２に登録された
文書から必要なデータを抽出して、ＤＢ４０１登録する
こともできる。また、ＤＢ４０１及び電子包袋４１２か
らサーバ１１８が形成する特許検索システム４１６へは
リンクが張られており、電子包袋４１２の書類から特許
検索システム４１６内の案件４１７に簡単にアクセスで
きるようになっている。

【００４８】特許検索システム４１６の情報は、たとえ
ば、ＣＤ−ＲＯＭなどの媒体４１８を介してＤＢ更新で
きるようになっている。

【００４９】（アクションケース）図５は、上述のアク
ションケースの概念を説明するための図である。

【００５０】図５において、５０１はあるアクションケ
ースを表しており、その内容である５０２、５０３は上
述の図４の出願アクション４０４、書類４０７にそれぞ
れ対応する。また、５０４、５０５、５０６、５０７は
それぞれ４０５、４０９、４０６、４１１に対応する。

【００５１】上述のように、このアクションケースは、
５０８に示されるようなシステム上の仮想のファイルで
あり、その中には、記載項目として出願、拒絶理由など
のアクションの単位を示す種類、アクションケースの発
生日、終了日、アクションケースの名称（一連のアクシ
ョンに複数の文書が入る場合にはこのケースを表す代表
のもの）、法定期限日、アクションケースの希望返却日
（次にケースを処理する人に対する処理の期限日）、次
の人へのコメント、関連する案件番号、アクションケー
スの回覧履歴情報（どのような人を経由して自分の所へ
ケースがきたかを示す）等が記載された表紙５１２が挿
入される。また、その処理に必要な書類５０９や、画面
入力（表示）されるＤＢ項目５１０が挿入され、更に、
処理結果５１１、例えば、補正書案を作成した場合に
は、その補正書案が処理者によって挿入される。処理結
果５１１は、アクションケースを受けた人が、自分の処
理内容をシステムに対してアップロードし、電子包袋４
１２に登録されることで、挿入が完了する。

【００５２】なお、アクションケースの概念は変形が可
能であり、例えば、もっと短い単位、例えば、提案書作
成、原稿チェックなどに区切ることも可能である。ま
た、複数の特許庁提出書類をまとめて一つのアクション
ケースとして移動・処理させることもできる。

【００５３】アクションケースの例を図６〜図８に示
す。

【００５４】図６は出願書類を作成する出願ケース、図
７は拒絶理由に応答するための拒絶理由応答ケース、図
８は拒絶査定に対して応答するための拒絶査定応答ケー
スである。

【００５５】それぞれの工程（アクション）に対して、
アクションケース発生のタイミング、発生時の処理、消
滅のタイミング、消滅時の処理、その処理に関連する書
類などが定義されている。審査請求など、他の工程に関
しても同様に定義をすることができる。

【００５６】図９は、図３に示されるような組織構成に
おける、アクションの検討経路の例を説明する図であ
る。例えば、（１）は検討依頼形態の例１であり、担当
者Ａから担当者Ｆ、部長Ｅ、課長Ｇを経由して発明者Ａ
へアクションケースが渡るという経路を示している。例
えば拒絶理由の検討などがこのパターンに該当する。
（２）は検討依頼形態の例２であり、担当者Ａから自動
的にダイレクトに発明者Ａにアクションケースが渡る例
である。例えば出願原稿のチェックなどがこのパターン
に該当する。（３）は検討依頼形態の例３であり、担当
者Ａから順に任意の相手先を指定して、アクションケー
スを検討者まで回していくケースである。

【００５７】（１）、（２）はシステムがワークフロー
を管理して自動的にケースが回っていくのに対して、
（３）はケースを受けた人が社内ルールに従い自分の判
断でケースを目的の人物に回していくものである。処理
の自動化という点からは前者が優れる反面、前者は組織
内における処理の柔軟性にかけるという欠点がある。本
実施の形態では、双方をサポートするシステムとするこ
とにより、アクションの種類、部門毎の状況などに応じ
て、柔軟にシステム運用ができるようにしている。

【００５８】同様に、図１０はアクション検討結果の承
認の経路の例を説明する図である。例えば、（１）は承
認形態の例１であり、発明者Ａから課長Ｇ、部長Ｅ、所
長Ｃ、担当者Ｆ、課長Ｄ、部長Ｃ、所長Ｂ、担当者Ａ、
課長Ａ、部長Ａを経由して所長Ａへアクションケースが
渡るという経路を示している。例えば発明提案書の承認
・受け入れなどがこのパターンに該当する。（２）は承
認形態の例２であり、発明者Ａから自動的にダイレクト
に担当者Ａにアクションケースが渡る例である。例えば
出願原稿のチェックや緊急時の回答などがこのパターン
に該当する。（３）は検討依頼形態の例３であり、発明
者Ａから順に任意の相手先を指定して、アクションケー
スを最終承認者まで回していくケースである。

【００５９】承認の場合についても、上述の検討依頼と
同様の理由で、（３）の形態を設けている。

【００６０】図１１は、図９、図１０に示されるアクシ
ョンの検討および承認の経路パターンを示すテーブルを
表している。（１）は検討経路パターンであり、Ａ００
１からＡ００５までのパターンを例として記載してい
る。例えば、Ａ００１は、アクションケースをシステム
が自動発生させ、知財権利化部門の課長から担当者、開
発権利化支援部門の課長から担当者、研究・開発部門の
課長から担当者へアクションケースが回るパターンであ
る。また、（２）は検討結果承認経路パターンであり、
Ｂ００１からＢ００５までのパターンを例として記載し
ている。例えば、Ｂ００２は研究・開発部門の担当者か
ら知財権利化部門の担当者にアクションケースが回った
あとシステムが検討結果を自動登録する。

【００６１】このような経路パターンをサーバ１１９に
複数予め登録しておくことにより、ワークフロー管理を
円滑に制御することができる。また、経路パターンをテ
ーブル化しておくことにより、テーブルの書き換えだけ
で、アクションケースのワークフローを容易に変更可能
となる。また、このテーブルにＡ０００、Ｂ０００とし
て、相手先指定の任意経路をというパターンを定義する
こともできる。

【００６２】図1２は、図１１のパターンテーブルを用
いて部門別（３）、知財権利化担当者別（４）にワーク
フローを自由に組み立てるためのパターン選択テーブル
を示す。例えば、開発部門Ａは、アクション検討経路パ
ターンとしてはＡ００１を、検討承認経路パターンとし
てはＢ００１を選択する。あるいは、担当者Ａはアクシ
ョン検討経路パターンとしてはＡ００１を、検討承認経
路パターンとしてはＢ００５を選択する。このようなパ
ターン選択テーブルを持つことにより、部門ごと担当者
ごとのカスタマイズが可能になる。また、アクションケ
ースの種類ごとにパターンテーブルを持ったり、選択テ
ーブルを持ったりしてもよい。

【００６３】図１３は、アクションケースのフロー設定
を示すフローチャートである。

【００６４】まず、Ｓ１３００で図３に示されるような
組織情報がシステムに登録されているかどうかを判断
し、Ｓ１３０１で、図１２（３）の部門別経路パターン
テーブルを適用するように設定されているか判断する。
適用される場合には、Ｓ１３０２で、部門別経路パター
ンテーブルを検索し、Ｓ１３０３で、当該アクションケ
ースに対して検討依頼・承認経路をシステムが自動設定
し、Ｓ１３０４で、実際のアクションケース処理を行
う。一方、部門別経路パターンテーブルを適用しない場
合には、Ｓ１３０５で、知財権利化担当者別経路パター
ンテーブルを適用するよう設定されているかどうかを判
断し、適用される場合には、Ｓ１３０６で、担当者別経
路パターンテーブルを検索し、Ｓ１３０７で、当該アク
ションケースに対して検討依頼・承認経路をシステムが
自動設定し、Ｓ１３０４で、実際のアクションケース処
理を行う。一方、担当者別経路パターンテーブルを適用
しない場合には、Ｓ１３０８で、当該アクションケース
に対して検討依頼・承認経路をシステムが予め定めたデ
フォルトモード自動設定する。

【００６５】また、組織情報がない場合には、Ｓ１３０
９で相手先をマニュアルで入力するモードを設定する。

【００６６】以上のように、組織情報と経路テーブル、
選択テーブルの組み合わせにより、アクションケースの
移動を効率よく管理することができる。

【００６７】（アクションケースの後追い機能）図１４
はアクションケースに入るべき書類の後追い機能につい
て説明する図である。

【００６８】この例では、システム１４０１が自動発生
させたアクションケースを担当者Ａ（１４０３）、担当
者Ｆ（１４０４）、部長Ｅ（１４０５）、課長Ｇ（１４
０６）、発明者Ａ（１４０７）の順に検討依頼が回って
いくとする。この場合に、システム１４０１がアクショ
ンケースを発生した時点で、拒絶理由通知に記載された
引用文献のうち、一部が入手に時間がかかるときに、ア
クションケースをこの引用文献入手までシステムに保持
していると、実質的な検討のための時間が無駄に失わ
れ、効率が悪くなる。

【００６９】一方、実際に拒絶理由通知に対する応答を
考える検討者に渡るまでは、引用文献の一部はなくても
検討者を決める処理などについては適切な判断を下せる
場合も多い。

【００７０】そこで、本実施の形態においては、このよ
うな場合に、アクションケースに一部未入手の書類があ
る状態で、回覧を開始し、後から必要な書類が入手され
た時点で、システム１４０１がアクションケースの保持
者のケースに例えば資料部門など他の部門１４０２で入
手した文献を後追いで挿入し、その文献が挿入されたこ
とを知らせるためのメールをそのアクションケースを既
に回覧した人に対して送るようにする。

【００７１】なお、後追いの書類は、上述のようにもと
の検討依頼を発生した部門（人）ではない部門（人）か
ら発送してもよいし、同じ部門（人）でもよい。

【００７２】図１５は、書類後追い処理を示すフローチ
ャートである。

【００７３】まず、Ｓ１５０１で、システムが書類を受
理すると、Ｓ１５０２で、その書類に関連書類のフラッ
グ（関連書類を識別するための識別コード）がついてい
るかどうかを判断し、関連書類のフラッグがついている
場合にはＳ１５０３で、関連書類のアクションケースを
検出する。そして、Ｓ１５０４で、アクションケースが
既に発送済みで、システムの手を離れているかどうかを
判断し、まだの場合にはＳ１５０５で、関連書類のアク
ションケースに新たに受理した書類を追加して発送し、
Ｓ１５０７のアクションケースの処理に移る。一方、既
にアクションケースを発送済みの場合には、現在関連書
類のアクションケースを保持している人のアクションケ
ースに新たな書類を追加するとともに、そのアクション
ケースを保持している人以前の人、即ち、既に回覧履歴
に載っている人に対して書類追加の旨を知らせるメール
を発送する。このメールを受け取った人は、新たに追加
された書類の閲覧をすることができる。メールにはその
追加の書類そのものを添付してもよいし、追加書類のＤ
Ｂ上のアドレスを記載することにより、アクセス可能に
してもよい。この場合、既にアクションケースを回して
しまった人はそのアクションケースに対して補正書案な
どの書類の登録をすることはできないが、仮に重要な処
理をそのアクションケースに対して行う必要がある場合
には、そのアクションケースを戻してもらったり、検討
結果が返ってくるときに、必要な書類の登録を行うこと
ができる。

【００７４】また、関連書類のフラッグがない場合に
は、Ｓ１５０９で、新規アクションケースの発生など、
通常の処理を行うことになる。

【００７５】以上のような、書類後追いの機能により、
限られた検討時間を有効に利用して、効率よく検討を行
うことができる。以上のような書類の後追い機能は、上
述のような特許のアクション（拒絶理由通知など）の検
討に限らず、ネットワーク上で何らかの検討（転送・承
認を含む）を複数人で行ういかなる検討にも適用でき、
ネットワーク上での検討の効率化を図ることができる。

【００７６】（アクションケースのコピー機能）図１６
は、アクションケースのコピー機能を説明する図であ
る。

【００７７】上述のアクションケースの使用方法として
は、図１６ののように、アクションケース１６０１を
受けた人がそのまま１６０２として次の人に１６０３と
して回すのが典型的である。これに対して、に示すよ
うに、アクションケース１６０４を受けた人が、１６０
５として自分が処理する一方で、次の人にも並行して検
討してもらいたい場合もありうる。このような場合に
は、本実施の形態のシステムでは、アクションケース１
６０５のコピーケース１６０７を作成し、自分が１６０
５を所有しつつ、コピーケース１６０７を別の人の検討
に出すことができる。ただし、この場合の規則として、
コピーケースを作成した人が、必ず、コピーされ、検討
の結果戻ってきたケース１６０８を統合することとす
る。即ち、依頼されたアクションケースを分割してもと
の人に返すのは原則として禁止する。

【００７８】コピーケースの使用形態としては、上述の
ものに限らず、依頼元からきたケース１６０９に対し
て、１６１０の所有者が、コピーし１６１１、１６１２
に分割して並行した検討に回すことが考えられるが、戻
ってきた１６１３、１６１４をそのままばらばらで、依
頼元に返送するのではなく、コピーを作成した人が責任
をもってまとめて、依頼者に返送することとする。

【００７９】図１７は、コピーケースの使用方法をより
具体的にあらわす図である。

【００８０】知財権利化支援部門からきたアクションケ
ース１７０１は、知財権利化部門において検討依頼書を
作成され、１７０２として開発権利化支援部門に送られ
るとともに、コピーケース１７０９を作成され、その他
の部門に送られる。開発権利化支援部門では、ケース１
７０３の検討依頼書を電子メールの添付書類として、開
発部門に送る一方、コピーケースを作成し、コピーケー
ス１７０５の検討依頼書を電子メールの添付書類とし
て、別の開発部門に送る。開発部門では、それぞれ１７
０４，１７０６という検討結果を編集し、それぞれ１７
０８１７０７として開発権利化支援部門に返送する。こ
こで両者が合体、統合され、依頼元である知財権利化部
門に返送される。ここでは、他部門に検討に回されてい
た検討結果１７１０が１７１１に合体、統合され、必要
な書類を作成・追加した後、知財権利化支援部門でのタ
イプ依頼処理などに回される。

【００８１】以上のような、アクションケースのコピー
機能を用いることにより、短期間で複数の人が効率よく
依頼事項を検討することができる。

【００８２】図１８は、開発部門内での情報伝達方法の
一例（検討者が順次次の検討者を指定する場合）を示す
図である。

【００８３】まず、知財部門から検討依頼書１８０４が
メールでくると、代表発明者や担当者１８０１は、自分
のＰＣ端末上で必要な検討項目、次の検討者を書類１８
０４に記入の上、その書類上にマクロとして埋め込まれ
た送信ボタンにより送信を指示する。この送信ボタンに
より、システムに書類１８０４が登録され、文書サーバ
１１６に記憶されるとともに、次の検討者（承認者）に
メール１８０５が送信される。そして次の上司１８０２
の同様に書類１８０６上に項目を記入し、システムに登
録するとともに、上司１８０３にメール１８０７を送信
する。

【００８４】以上のワークフローは、システムにより管
理されており、検討者は次の検討者（承認者）を入力
し、送信ボタンを押すだけで、システム登録、メール送
信が行われるようにする。

【００８５】図１９は、本システムにおける知財関連事
務所からの請求書処理を示すフローチャートである。Ｓ
１９０１で、特許庁以外の機関（例えば、特許事務所、
翻訳事務所など）から書類（例えば、拒絶理由通知、意
見書・補正書案、出願原稿、外国出願用原稿など）を受
理すると、Ｓ１９０２で、サービス依頼時のＩＤ番号が
添付されているかどうかを確認する。ＩＤ番号がついて
いれば、Ｓ１９０６に移り、ついていない場合には、Ｓ
１９０３でＤＢに書類を入力し、Ｓ１９０４でＩＤ番号
を発行し、Ｓ１９０５でＩＤ番号を知財関連事務所に送
付する。Ｓ１９０６では、請求書を受理し、ＩＤ番号と
書類の項目（種類など）を確認する。例えば、出願原稿
の作成依頼という項目でのＩＤ番号に対して、請求書の
内容が拒絶理由通知応答という項目での請求であれば、
エラーとなる。また、例えば、各サービスの種類に対し
て、予めシステムに設定した一定額以上の請求があった
場合には、社内のクライアントＰＣ上でその旨表示さ
せ、間違いでないことがオフライン（例えば、電話やＦ
ＡＸなど）により確認できない場合にマニュアルでエラ
ー通知を行うようにすることもできる。

【００８６】Ｓ１９０７で、項目とＩＤ番号が一致して
いれば、Ｓ１９１０で支払を行い、一致して異なようで
あれば、Ｓ１９０８でエラー表示を行うとともに、知財
関連事務所にその旨通知する。そして、Ｓ１９０９で、
請求書の再送があるかどうかを確認する。

【００８７】以上のように、依頼したサービスに対して
ＩＤをつけ、サービスの納入時に内容と照合・確認する
ことにより、システム上でサービス内容と請求書をリン
クさせやすくなる。

【００８８】（第２の実施の形態） （知的財産管理システム全体構成）図２０は本願の第２
の実施の形態の知的財産管理システムの代表的な構成を
示す図である。

【００８９】基本的な構成・機能は、図１と同様である
が、図１のシステムは国内外を問わず、ネットワークに
よるオンライン化を前提としているが、本実施の形態は
以下の点で、第１の実施の形態と異なる。

【００９０】１２８、１２９は公衆回線であり、この回
線を通じてファクシミリデータを通信することができ
る。知財権利化支援部門１０６、海外事務所１１３、国
内事務所１１２その他は、少なくとも１台ファクシミリ
装置を備えている。システム全体の理想形としては、上
述の第１の実施の形態にような完全なオンラインである
が、過渡的には電子メール、Webが使用できない環境が
生じうる。

【００９１】そこで本実施例では、補助的な通信手段と
して、紙媒体やファクシミリ通信を使用するものであ
る。

【００９２】図２１は、知財権利化支援部門１０６に設
置されているＯＡ機器の例を示す図である。

【００９３】基幹ネットワーク１２７に対して、クライ
アント２１０１、２１０２、２１０４、高速スキャナ・
プリンタ２１０３、高速スキャナ・プリンタ・ＦＡＸ複
合機２１０５が接続されている。また、ＰＣ２１０２は
スキャナ・プリンタ２１０３のサーバの機能を有し、Ｐ
Ｃ２１０４は、複合機２１０５のサーバの機能を有す
る。２１０９アナログまたはデジタルの公衆回線であ
り、複合機２１０５が、ファクシミリデータの送受信の
ために用いる。２１０６、２１０７、２１０８はスタン
ドアローンのファクシミリ装置であり、それぞれ公衆回
線２１１０、２１１１、２１１２を介してファクシミリ
通信を行う。

【００９４】知財権利化支援部門１０６へは海外事務所
１１３、国内事務所１１２など、外部機関からファクシ
ミリによる情報の受信が行われる。

【００９５】このとき、緊急の場合（回答期限が迫って
いるものなど）には、送付元は複数の回線の中で緊急専
用の回線２１０９の番号に対してＦＡＸ送信を行い、フ
ァクシミリのカバーページとして、図２２に示されるよ
うなシートを用いる。

【００９６】図２２において、カバーシート２２０１に
は、ケース番号とそのＯＣＲ用バーコード２２０６、法
定期限日とそのＯＣＲ用バーコード２２０７、送付書類
名とそのＯＣＲ用バーコード２２０８、引用例番号とそ
のＯＣＲ用バーコード２２０９、その他の書誌情報とそ
のＯＣＲ用バーコード２２１０が記載され、送信側で読
み込まれる。２２０２は例えばオフィスアクション（拒
絶理由通知）であり、２２０３は１件目の引用文献、２
２０４は２件目の引用文献、２２０５は３件目の引用文
献である。

【００９７】このように、フロントページにＯＣＲ用の
コードとともに書誌情報を記載したものを受信すること
により、複合機２１０５を介して取り込まれたファクシ
ミリデータから、サーバ２１０４が処理情報を認識し、
システムに対して書誌情報の電子データを提供すること
ができる。また、オフィスアクション２２０２、引用文
献２２０３〜２２０５もファクスミリデータ（電子デー
タ）としてシステムに取り込むことができる。フロント
ページから抽出された書誌情報は管理サーバ１１7に登
録され、サーバ１１９により、その法定期限や事務所へ
の指定回答期限に応じて、上述のアクションケースが自
動発生する。一方、２２０２〜２２０５のファクシミリ
データは、文書サーバ１１６に登録される。ファクシミ
リデータは、Ｇ３方式でもＧ４方式でもよく、また、Ｊ
ＢＩＧなどの圧縮データであってもよい。特に、本実施
例のシステムのように、ファクシミリデータを直接デー
タベースに取り込むようにできるシステムにおいては、
ＪＢＩＧのような階層符号化方式のデータとすること
は、データベース入力後、ユーザが使用する際に有効で
ある。

【００９８】以上の処理の流れを表すフローチャートを
図２３、図２４に示す。

【００９９】Ｓ２３０１でＦＡＸの受信を待ち、受信し
た場合にＳ２３０２で、ＦＡＸサーバ２１０４が上述の
カバーレター上の情報ＯＣＲにより認識する。本実施の
形態においては、ファクシミリデータ中には、サーバ１
１７が管理する案件を特定するための項目情報（ケース
番号）、今回のアクションの期限情報、送付される書類
の書類名情報、添付される特許庁発送の引用文献情報な
どが含まれる。そして、Ｓ２３０２で管理情報がサーバ
１１７に登録され、２２０２〜２２０５の文書データが
文書サーバ１１６に登録されるとともに、サーバ１１９
がケース番号を特定し、アクションケースを自動発生さ
れる。Ｓ２３０５で期限日を設定し（法定期限の管理で
よい場合は法定期限、事務所の指定期限がある場合は双
方の期限を設定する）する。そして、Ｓ２３０６で、サ
ーバ１１９が知財権利化部門担当者へアクションケース
を送信するとともに、知財権利化支援部門担当者および
知財権利化部門担当者上司に緊急のアクションケースが
入ったことを知らせるメールを送信する。

【０１００】次に、Ｓ２３０７で、所定時間（例えば３
時間）経過後アクションケースが知財権利化部門担当者
によりアクセスされたか（開封されたか）どうかをシス
テムがチェックし、されていればＳ２３１０で担当者は
そのアクションの検討にうつる。一方、アクションケー
スが開封されていない場合には、Ｓ２３０８で、知財権
利化支援部門担当者及び知財権利化部門担当者上司へリ
マインドメールを送信し、Ｓ２３０９で知財権利化支援
部門担当者または知財権利化部門担当者上司がアクショ
ンケースを強制的に引き上げ、アクションケースを他の
担当者当てに送りなおすか、自らで処理を行う。

【０１０１】アクション検討後は、Ｓ２４０１で、アク
ション回答をシステム経由またはＦＡＸで送付し、Ｓ２
４０２でアクションに回答の書誌情報を管理サーバ２４
０２のＤＢに登録する。そして、サーバ１１９はＳ２４
０３でアクション回答（回答依頼）に対するＩＤ番号を
発行し、Ｓ２４０４でＩＤ番号をアクション回答の送付
先に対して送付する。その後、Ｓ２４０５でアクション
回答の送付先からの請求書を受理し、Ｓ２４０６で請求
書の項目その他が一致していれば、Ｓ２４０９で請求額
を支払い、一致していなければ、Ｓ２４０７でエラー表
示・相手先への通知をおこない、Ｓ２４０８で再送があ
れば上記チェックを繰り返す。

【０１０２】なお、上記ＩＤ番号は緊急のファックス受
信の時、あるいはアクションケースの発生時に発行する
ようにしてもよい。

【０１０３】また、請求の支払いはオンラインで行って
もよく、オフラインで行ってもよい。

【０１０４】図２５は、アクションケースの処理状況を
ユーザが確認するための表示画面の構成を説明する図で
ある。

【０１０５】図２５（１）は知財権利化部門担当者がク
ライアントＰＣ上でアクションケース処理状況を確認す
る場合に表示画面の例を示す図である。

【０１０６】表示項目としては、アクションケースを送
った先の人が、そのアクションケースにアクセスしたか
どうかを表示する「開封」、そのアクションケースの返
送を受領したかどうかを示す「返送」、アクションケー
スの種類を表す「アクションケース名」、アクションケ
ースを送付した日付を示す「送付日」、送付先を示す
「送付先」、アクションケースの送付者が設定し、アク
ション検討の期限を示す「指定期限」、特許庁などへの
書類の提出期限を示す「法定期限」が順に表示される。

【０１０７】表示の方法のルールの一例を以下に説明す
る。 送付先でアクションケースにアクセスがあったことを
ネットワークを介してシステムが検出し、「開封」のボ
ックスにマーキングする。 送付日から起算してN日（例えば３日）経過後に「開
封」されていなければ、そのアクションケースに対して
必要な表示（例えば黄色でペイントする）で知財権利化
部門担当者に対して視覚的にリマインドする。 指定期限を過ぎると「開封」されているか否かにかか
わらず、そのアクションケースに対してとは異なる色
（例えば青）でペイントし、知財権利化部門担当者に対
して視覚的にリマインドする（ただしすでに返送が済ん
でいるものについては、ペイントは行わない）。 法定期限のM日前（例えば７日前）になると「開封」
されているか否か、指定期間を過ぎているか否かにかか
わらず、そのアクションケースに対して、とは異な
る色（例えば赤）でペイントし、知財権利化部門担当者
に対して視覚的にリマインドする。 緊急FAXにより発生したアクションケースについて
は、「開封」されているか否かにかかわらず、と同じ
色でペイントし、知財権利化部門担当者に対して視覚的
にリマインドする。 上記表示パラメータ（N,Mの数値、ペイントの色など
のりマインドの条件）は知財権利化部門担当者がクライ
アントPC上で条件を設定し、そのクライアントPC内の不
揮発性メモリに記憶させることにより、カスタマイズ可
能とする。

【０１０８】次図２６は、アクションケースの処理状況
をユーザが確認するための表示画面の構成を説明する図
である。

【０１０９】図２６（２）は知財権利化部門担当者上司
または知財権利化支援部門担当者がクライアントＰＣ上
で知財権利化部門担当者のアクションケース処理状況を
確認する場合に表示画面の例を示す図である。

【０１１０】表示項目としては、アクションケースを担
当する知財権利化部門担当者が、そのアクションケース
にアクセスしたかどうかを表示する「開封」、そのアク
ションケースを検討依頼に回したかどうかを示す「依
頼」、アクションケースの種類を表す「アクションケー
ス名」、アクションケースを知財権利化部門担当者が受
信した日付を示す「受信日」、知財権利化部門担当者名
を示す「担当者名」、アクションケースの送付者が設定
し、アクション検討の期限を示す「指定期限」、特許庁
などへの書類の提出期限を示す「法定期限」が順に表示
される。

【０１１１】表示の方法のルールの一例を以下に説明す
る。 知財権利化部門担当者によりアクションケースにアク
セスがあったことをネットワークを介してシステムが検
出し、「開封」のボックスにマーキングする。 知財権利化部門担当者がアクションケースを検討依頼
に出したことをネットワークを介してシステムが検出
し、「依頼」のボックスにマーキングする。 担当者受信日から起算してＰ日（例えば７日）経過後
に「開封」されていなければ、そのアクションケースに
対して必要な表示（例えば赤でペイントする）で知財権
利化部門担当者の上司に対して視覚的にリマインドす
る。 担当者受信日から起算してＱ日（例えば10日）経過後
に「依頼」されていなければ、そのアクションケースに
対して必要な表示（例えば黄色でペイントする）で知財
権利化部門担当者の上司に対して視覚的にリマインドす
る。 緊急FAXにより発生したアクションケースについて
は、「開封」されているか否かにかかわらず、と同じ
色でペイントし、知財権利化部門担当者の上司に対して
視覚的にリマインドする。 上記表示パラメータ（Ｐ,Ｑの数値、ペイントの色な
どのりマインドの条件）は知財権利化部門担当者の上司
がクライアントPC上で条件を設定し、そのクライアント
PC内の不揮発性メモリに記憶させることにより、カスタ
マイズ可能とする。

【０１１２】アクションケースにアクセスしたかどうか
は、例えば、アクションケースの添付書類として文書サ
ーバ１１６に保持されている検討依頼書に対するアクセ
スがあったかどうかをサーバ１１９が定期的にチェック
することにより、実現することができる。

【０１１３】以上のような、アクセスチェックツールを
設けることにより、ネットワーク環境下でメールの不調
や本人のメール見落としなどの場合に第３者がリマイン
ドあるいは代わりに処理することが可能となる。

【０１１４】（アクションケースの強制引きあげについ
て）上述のように、所定の権限を持つ人（例えば、アク
ションケース保持者の上司や、管理部門の責任者、その
保持者にアクションケースを送った人）は、アクション
ケースを自分の手元に強制的に引きあげることができ
る。

【０１１５】これは例えば、サーバ１１９のワークフロ
ー管理テーブルの情報を書き換えて、アクションケース
の保持者を変更することにより実現できる。このような
機能は、例えばアクションケースの保持者が出張で不在
の場合など、アクションケースの処理が滞りそうな場合
に、特に有効である。

【０１１６】このとき、現在のアクションケースの保持
者に、強制引きあげがあった旨、及び、引きあげした人
の情報、引き上げ日時などの情報を含むメールを現在の
アクションケースの保持者に送る。これにより、アクシ
ョンケース所持者は自分が所持していたアクションケー
スが引き上げられたことを認識することができる。

【０１１７】また、引き上げ後は、自らが検討・承認な
どのの処理を行ってもよいし、別のものに検討依頼・承
認依頼を行ってもよい。

【０１１８】以上のツールは第1の実施の形態のシステ
ムにも用いることができる。

【０１１９】図２７は、上述のファックスで送付される
書類が紙媒体で送付される場合のシステムへの入力の方
法を示すフローチャートである。

【０１２０】まず、Ｓ２７０１で、知財権利化支援部門
が紙の書類を受領する。この書類のカバーレターとして
は、図２２の２２０１と同様のものを用いる。

【０１２１】Ｓ２７０２で、カバーレターを知財権利化
支援部門担当者に２１０３のイメージスキャナで読み取
らせる。Ｓ２７０３でスキャナサーバ２１０２がカバー
レター上の情報を認識する。Ｓ２７０４で、ケース番号
を特定し、Ｓ２７０５で、システムの管理サーバ１１７
にアクセスし、当該ケースの書誌情報画面をクライアン
トＰＣである２１０２のディスプレイ上に表示させる。

【０１２２】次にＳ２７０６で添付書類（例えば拒絶理
由通知）２２０２を入力する。Ｓ２７０７で引用文献の
添付があるかどうか判断し、ある場合には、その引用文
献が引用文献のＤＢを構成するサーバ１１８に記憶され
ているどうかを判断し、すでに記憶されている場合には
その引用文献のスキャナ入力を行わない。一方、引用文
献ＤＢにその文献がない場合には、Ｓ２７０９で知財権
利化支援部門担当者に対応番号の引用文献をスキャナ入
力するようＰＣの画面上で促し他の引用文献がある場合
には上記Ｓ２７０８からＳ２７０９の処理を繰り返す。
以降、図２８のＳ２８０１からＳ２８０６の処理は図２
３のＳ２３０５からＳ２３１０と同様なのでその説明を
省略する。また図２４の処理も同様である。

【０１２３】（文献データベースについて）図２９〜図
３３は、サーバ１１８に構築される引用文献データベー
スの使用方法を説明するためのクライアントＰＣの表示
画面の図である。

【０１２４】図２９は、ケース番号（案件）ごとの関連
資料を一覧表示したものである。２９０１は、ケース番
号であり、その会社の各国ごとの出願のリファレンス番
号である。この例では５桁の数字の後ろに国識別の英字
を組み合わせている。２９０２は、ファミリー番号であ
り、出願内容が実質的に等価である出願群を表す。２９
０３は、出願国名であり、このケースでは、ＵＳ（米
国）、ＥＰ（ヨーロッパ）、ＡＵ（オーストラリア）、
ＪＰ（日本）の出願が存在することを表す。２９０４
は、ケース番号１２３４５ＵＳという米国出願に関連す
る文献リストであり、主として、米国特許庁による審査
で引用されたものである。この例では、文献番号「１２
０００（自社ファミリー番号）」、「特開平０５−１２
３４５」、「ＵＳＰ１２３４５６」の３件がリスティン
グされている。各文献番号ごとに、入手先、入手日、概
要、拒絶理由対象個所、本願における差別化ポイントな
どの項目が表示される。２９０５は、そのケースのファ
ミリー（この場合ＵＳ、ＥＰ、ＡＵ、ＪＰ）すべての関
連文献を表示する。即ち、この例では、ＵＳ以外で、Ｅ
Ｐケースでは「ＤＥ１２００００１」、ＡＵケースでは
「ＵＳＰ１２３４５６」、ＣＡケースでは「ＵＳＰ１２
３４５６」、ＪＰケースでは「特開平０６−１２３４
５」の４件が引用されており、それぞれ、その入手先
（例えばサーチレポート（ＳＲ））、入手日、概要など
が表示される。さらに、米国（ＵＳ）、中国（ＣＮ）で
ＩＤＳ（情報開示手続）が完了したか、していないか、
或いはする必要がないかを示すＩＤＳ情報もあわせて表
示される。このＩＤＳ情報は図２９のようにＵＳとＣＮ
をあわせて１つのフラッグで表示してもよく、ＵＳ，Ｃ
Ｎそれぞれ分けて情報を持ち、複数独立して表示させて
もよい。

【０１２５】このように、関連文献をファミリーで表示
できるようにし、しかも関連文献のＩＤＳの状態を示す
表示を行うことにより、ＩＤＳ漏れを防止することがで
きるとともに、各国の権利化の際に、他の国での審査引
用例を考慮しやすくなり、効率よく有効な権利の取得を
行うことができる。

【０１２６】図３０は、文献逆引き表示画面(タイプ1)
であり、３００１は文献番号を表す。３００２はその書
誌情報であり、例えば現状、出願番号と出願日、優先権
基礎出願番号と優先日、公開番号と公開日、公告番号と
公告日、登録番号と登録日を表示する。３００３、３０
０５はガイド表示であり、マウスのカーソルをあわせる
ことで、その部分の機能説明を表示する。３００４はこ
の文献の概要である。３００６はこの文献が引用された
自社の案件（ケース番号）をリスティングしたものであ
る。ここで、ケース番号をクリックすると、サーバ１１
６に登録された自社出願情報にアクセスすることができ
る。また、ここでは、ケース番号ごとに、項目（オフィ
スアクションなど経歴単位）、その日付、拒絶理由個
所、本願との差別化のポイントなどの項目が表示され
る。

【０１２７】このように、文献をキーにしてその文献が
引用された自社のケース番号を抽出・表示することで他
のケースでその文献との差別化を行った際のポイントを
即座に見出すことができ、オフィスアクションの検討を
効率よく行うことができるなどの効果がある。

【０１２８】図３１は、文献逆引き表示画面（タイプ
２）であり、３１０１は文献番号を表す。３１０２は対
応外国出願検索ボタンであり、このボタンを押すと、サ
ーバ１１８の特許検索ＤＢとのリンクがとられ、ファミ
リー（例えば米国出願、日本出願など）の文書をみるこ
とができる。３１０３はこの文献の状況（登録、消滅な
ど）を自動的にウオッチする社内手続を依頼するための
ボタンである。３１０４はいずれかのケースで引用され
たこの文献のファミリーの書誌情報を一覧表示したもの
である。３１０５は文献が引用されたケースの番号を逆
引きしてケース一覧として表示したものである。たとえ
ば、「ＵＳＰ１２３４５」はケース番号「１２３４５Ｕ
Ｓ」、「１２３４５ＡＵ」、「０９８７６５ＪＰ」で引
用された文献であることが一目でわかるようになる。

【０１２９】図３２はアクションケースでやり取りされ
る、オフィスアクション検討の結果（１案件の１経歴単
位）を表示したものである。３２０１は、本件のケース
番号、３２０２は開発権利化支援部門担当者、知財権利
担当者の名前、連絡先、３２０３は本件の概要、３２０
４は承認印、３２０５はオフィスアクションの種類を示
す。３２０６はこのケースの発明が実施される自社製
品、自社実施予定、他社製品を表示する。３２０７は開
発部門・開発権利化支援部門検討者のコメントである。
３２０８はそのケースで引用された文献のリストであ
り、その文献がUS,CNで先行技術開示されたか否かを示
すフラッグ、引例の概要、拒絶理由対応個所、本件発明
における差別化のポイントの項目が表示される。

【０１３０】図３３は、各案件（ケース）単位での関連
文献の表示画面である。３３０１はケース番号、３３０
２はこのケース番号の現状や、出願・公開・登録番号な
どの書誌的事項、３３０３は関連文献の書誌的事項、３
３０４はその文献の概要、３３０５は、その文献の入手
日付、入手方法、拒絶理由対応個所、差別化のポイント
などのリストである。

【０１３１】以上のように、出願案件、経歴ごとに、関
連文献情報を持つことにより、案件・経歴単位での文献
検索・表示、更に文献単位の案件検索・表示が可能とな
り、拒絶理由通知の検討など、権利化処理を行なう上で
の効率を大幅に向上させることができる。特に、ネット
ワーク環境下で、書類のペーパーレスを行なう場合に
は、このような各案件・各経歴単位での文献のデータベ
ースが有効となる。

【０１３２】図３４〜３６は、上述のようなデータベー
スを構築するためのＤＢ管理項目の定義を説明するため
の表である。

【０１３３】図３４は、1文献単位にもつ情報であり、
国、引例番号、文献番号、公開番号、公開日、遡及日、
出願番号、出願日、公告番号、公告日、登録番号、登録
日、キーワード、概要、メモ、ファミリーの項目を定義する
表である。それぞれの項目に対して、概要、長さ、属
性、入力者、チェック者、備考が定められている。

【０１３４】例えば、「国」という項目名はその文献の
発行国を意味し、長さは英数の2文字、入力者・チェッ
ク者は事務部門（知財権利化支援部門）、備考として入
力が必須であることを定義している。このようなルール
に従い、文献データベースが構築される。

【０１３５】図３５は、1案件（ケース番号に対応）単
位に持つ情報であり、File No、引例番号、IDS有無、ID
S種類、入手日、入手先の項目を定義する表である。そ
れぞれの項目に対して、図３５と同様の定義の仕方であ
る。

【０１３６】例えば、「FileNo．」という項目に対して
は、国まで指定する旨か定められ、属性は英数字、入力
者はシステム自動入力、チェック者なし、備考としてこ
の項目が先行技術とこの案件とを結びつけるものである
ことを定義している。

【０１３７】図３６は、1案件（ケース番号に対応）の1
経歴（例えば上述のアクションケースに対応）の1引例
単位にもつ情報であり、経歴番号、引例番号、拒絶理由
対象個所、差別化ポイントの項目を定義している。それ
ぞれの項目に対して、図３５と同様の定義の仕方であ
る。

【０１３８】例えば、「引例番号」という項目に対して
は、属性が英数字、入力者・チェック者が事務部門、備
考として、入力が必須であると定義している。

【０１３９】以上のように定義した項目を入力すること
により、上述のようなDB管理、検索、表示が可能とな
る。

【０１４０】本願の発明は、前述した実施形態の機能を
実現するソフトウェアのプログラムコードを記録した記
憶媒体を、システムあるいは装置に供給し、そのシステ
ムあるいは装置のコンピュータ（またはＣＰＵやＭＰ
Ｕ）が記憶媒体に格納されたプログラムコードを読み出
し実行することによっても達成できる。

【０１４１】この場合、記憶媒体から読み出されたプロ
グラムコード自体が前述した実施形態の機能を実現する
ことになり、そのプログラムコードを記憶した記憶媒体
は本発明を構成することになる。プログラムコードを供
給するための記憶媒体としては、例えばフロッピー（登
録商標）ディスク、ハードディスク、光ディスク、光磁
気ディスク、ＣＤ―ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不
揮発性のメモリカード、ＲＯＭ等を用いることができ
る。

【０１４２】また、コンピュータが読み出したプログラ
ムコードを実行することにより、前述した実施形態の機
能が実現されるだけでなく、そのプログラムコードの指
示に基づき、コンピュータ上で稼動しているＯＳ（オペ
レーティングシステム）などが実際の処理の一部または
全部を行い、その処理によって前述した実施形態の機能
が実現される場合も含まれる。

【０１４３】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された拡張ボードや
機能拡張ユニットに備わるメモリに書き込まれた後、そ
のプログラムコードの指示に基づき、その機能拡張ボー
ドや機能拡張ユニットに備わるＣＰＵ等が実際の処理の
一部または全部を行い、その処理によって前述した実施
形態の機能が実現される。

【０１４４】また、以上の実施の形態におけるワークフ
ロー、データベース作成、システム構成などの考え方は
任意に変形、組み合わせてもよい。

【０１４５】

【発明の効果】以上のように、本発明によれば、ネット
ワークを介して情報を通信することにより、単一の案件
を複数人が検討する検討システムにおいて用いられる情
報処理装置において、例えば、第１の検討者から第２の
検討者に対して第１の情報を添付して所定の案件の検討
を依頼する際に、第１の情報に含まれていなかった情報
であって、その案件の検討に必要な情報を後から送付す
ることができ、一部の材料で検討を早めに開始すること
ができ、ネットワークによる効率のよい検討を行うこと
ができる。

【図面の簡単な説明】

【図１】本実施の形態の知的財産管理システムの代表的
な構成を示す図

【図２】知的財産管理システムにおける情報の流通経路
を示す図

【図３】知財権利化部門１０５、開発権利化支援部門１
０３、研究・開発部門１０２における組織図の例

【図４】本実施の形態におけるデータベース管理の方法
を説明する図

【図５】アクションケースの概念を説明するための図

【図６】出願書類を作成する出願ケースを示す図

【図７】拒絶理由に応答するための拒絶理由応答ケース
を示す図

【図８】拒絶査定に対して応答するための拒絶査定応答
ケースを示す図

【図９】図３に示されるような組織構成における、アク
ションの検討経路の例を説明する図

【図１０】アクション検討結果の承認の経路の例を説明
する図

【図１１】図９、図１０に示されるアクションの検討お
よび承認の経路パターンを示すテーブル

【図１２】図１１のパターンテーブルを用いて部門別
（３）、知財権利化担当者別（４）にワークフローを自
由に組み立てるためのパターン選択テーブル

【図１３】アクションケースのフロー設定を示すフロー
チャート

【図１４】アクションケースに入るべき書類の後追い機
能について説明する図

【図１５】書類後追い処理を示すフローチャート

【図１６】アクションケースのコピー機能を説明する図

【図１７】コピーケースの使用方法をより具体的にあら
わす図

【図１８】開発部門内での情報伝達方法の一例を示す図

【図１９】本システムにおける知財関連事務所からの請
求書処理を示すフローチャート

【図２０】第２の実施の形態の知的財産管理システムの
代表的な構成を示す図

【図２１】知財権利化支援部門１０６に設置されている
ＯＡ機器の例を示す図

【図２２】ファクシミリのカバーページを示す図

【図２３】ＦＡＸ受信の処理の流れを表すフローチャー
ト

【図２４】ＦＡＸ受信の処理の流れを表すフローチャー
ト

【図２５】アクションケースの処理状況をユーザが確認
するための表示画面の構成を説明する図

【図２６】アクションケースの処理状況をユーザが確認
するための表示画面の構成を説明する図

【図２７】ファックスで送付される書類が紙媒体で送付
される場合のシステムへの入力の方法を示すフローチャ
ート

【図２８】ファックスで送付される書類が紙媒体で送付
される場合のシステムへの入力の方法を示すフローチャ
ート

【図２９】サーバ１１８に構築される引用文献データベ
ースの使用方法を説明するためのクライアントＰＣの表
示画面の図

【図３０】サーバ１１８に構築される引用文献データベ
ースの使用方法を説明するためのクライアントＰＣの表
示画面の図

【図３１】サーバ１１８に構築される引用文献データベ
ースの使用方法を説明するためのクライアントＰＣの表
示画面の図

【図３２】サーバ１１８に構築される引用文献データベ
ースの使用方法を説明するためのクライアントＰＣの表
示画面の図

【図３３】サーバ１１８に構築される引用文献データベ
ースの使用方法を説明するためのクライアントＰＣの表
示画面の図

【図３４】データベースを構築するためのＤＢ管理項目
の定義を説明するための図

【図３５】データベースを構築するためのＤＢ管理項目
の定義を説明するための図

【図３６】データベースを構築するためのＤＢ管理項目
の定義を説明するための図

【符号の説明】

１１４ 日本国特許庁 １１５ 外国特許庁 １０４ 知財情報管理部門

Claims (6)

【特許請求の範囲】
1. 【請求項１】 ネットワークを介して情報を通信するこ
   とにより、単一の案件を複数人が検討する検討システム
   において用いられる情報処理装置であって、 第１の検討者から第２の検討者に対して第１の情報を添
   付して所定の案件の検討を依頼する第１の通信手段と、 前記第１の通信手段による検討の依頼時に前記第１の情
   報に含まれていなかった第２の情報を前記所定の案件の
   検討のために前記第２の検討者に対して送付する第２の
   通信手段とを有することを特徴とする情報処理装置。
2. 【請求項２】 更に、前記第２の検討者が既に第３の検
   討者に検討を依頼している場合に、該第３の検討者に対
   して前記第２の情報を送付する第３の通信手段とを有す
   ることを特徴とする請求項1に記載の情報処理装置。
3. 【請求項３】 更に、前記第３の通信手段により、前記
   第２の情報が前記第３の検討者に送付された場合に、前
   記第２の検討者が前記第２の情報にアクセス可能とする
   ための第３の情報を送付する第４の通信手段を有するこ
   とを特徴とする請求項２に記載の情報処理装置。
4. 【請求項４】 更に、前記検討依頼の所持者を検出する
   検出手段を有することを特徴とする請求項1に記載の情
   報処理装置。
5. 【請求項５】 ネットワークを介して情報を通信するこ
   とにより、単一の案件を複数人が検討する検討システム
   において用いられる情報処理方法であって、 第１の検討者から第２の検討者に対して第１の情報を添
   付して所定の案件の検討を依頼する第１の通信工程と、 前記第１の通信工程における検討の依頼時に前記第１の
   情報に含まれていなかった第２の情報を前記所定の案件
   の検討のために前記第２の検討者に対して送付する第２
   の通信工程とを有することを特徴とする情報処理方法。
6. 【請求項６】 ネットワークを介して情報を通信するこ
   とにより、単一の案件を複数人が検討する検討システム
   において用いられる情報処理方法を実行するためのプロ
   グラムを記憶したプログラム記憶媒体であって、 第１の検討者から第２の検討者に対して第１の情報を添
   付して所定の案件の検討を依頼する第１の通信工程を実
   行するためのコードと、 前記第１の通信工程における検討の依頼時に前記第１の
   情報に含まれていなかった第２の情報を前記所定の案件
   の検討のために前記第２の検討者に対して送付する第２
   の通信工程を実行ためのコードとを有することを特徴と
   するプログラム記憶媒体。