JP2007265040A - 知財業務支援装置 - Google Patents

Abstract

【課題】知財関連業務に関連した業務委託者と業務受託者の共同作業を支援する。
【解決手段】知財業務支援装置１００は、企業３００の知財部員等によって使用されるクライアント端末および特許事務所４００の弁理士等によって使用されるクライアント端末の双方と通信ネットワークを介して接続される。この装置は、知財業務案件の発注指示を受け付けると、その案件に関するデータを管理するための案件スペースを生成する。案件スペースに対してアクセス要求がなされると、要求元のユーザがこの知財業務案件の関係者であることを条件としてアクセスを許可する。また、知財業務支援装置１００は、スケジュールデータを生成し、スケジュールと比較した実際の業務の進捗状況を進捗データによって管理する。
【選択図】図２

Description

この発明は、知的財産に関連する業務を支援するための技術に関する。

近年、コンピュータの普及とネットワーク技術の進展に伴い、ネットワークを介した電子情報の交換が盛んになっている。特許をはじめとする知財関連業務についても同様である。

たとえば、特許出願までの業務（以下、単に「出願業務」とよぶ）には、発明の提案、発明資料用意、先行技術調査、出願可否の検討、弁理士との面談、明細書の作成や修正、請求書発行等、多くの作業が含まれる。こういった各作業の実行過程において、知財部員や発明者、弁理士等の間でさまざまな情報がやりとりされる。従来、こういった情報交換は郵送やファックスで行われることが多かったが、インターネットセキュリティの向上にともない、知財関連業務についてもＩＴによる省力化が提案されるようになってきた（例えば、特許文献１、特許文献２を参照）。
特開２００２−１１７２１５号公報 特開２００２−１４９８０９号公報

特許文献１は、知財関連業務の委託側となる企業内において知財関連データを管理するための技術を提案している。特許文献１に記載されている特許管理システムは、アクセス権限の管理により知財関連データのセキュリティを保証している。ただし、特許文献１に開示されている特許管理システムは、企業内の運用に限定される閉鎖系のシステムであり（たとえば、特許文献１の段落［００２３］を参照）、特許事務所等の外部リソースまでもシステムに取り込むことは想定されていないようである。

これに対し、特許文献２に記載されている特許管理システムは、特許事務所等にも開放された開放系のシステムのようである。ただし、この特許管理システムは業務委託側の企業と業務受託側の特許事務所の間で知財関連データの共有用データベースとして機能しているにすぎない。

本発明者は、知財関連業務の関係者に対して広く開放されたシステムを想定し、システムがユーザから要求されたサービスを受動的に遂行するだけでなく、システムがユーザに対して能動的にサービスを提供することで、知財関連業務の効率的な運用を実現できると想到した。

本発明の主たる目的は、知財関連業務に関連した業務委託者と業務受託者の共同作業を支援するための技術、を提供することにある。

本発明のある態様は、知財関連業務に関し、業務委託側のユーザによって使用されるクライアント端末および業務受託側のユーザによって使用されるクライアント端末の双方と通信ネットワークを介して接続される知財業務支援装置である。
この装置は、知財業務案件の発注指示を受け付けると、その案件に関するデータを管理するための案件スペースを生成する。案件スペースに対してアクセス要求がなされると、要求元のユーザがこの知財業務案件の関係者であることを条件としてアクセスを許可する。
また、この装置は、スケジュールデータを生成し、スケジュールと比較した実際の業務の進捗状況を進捗データによって管理する。

知財業務案件ごとに案件スペースを生成し、案件スペースごとにアクセス権限を有する関係者を特定することで、データ漏洩を防止しやすくなっている。知財業務案件のスケジュールと比較した業務の進捗状況を進捗データとして管理している。そのため、関係者間で業務の進捗状態を即時的に把握しやすくなる。

なお、以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。

本発明によれば、知財関連業務に関連して業務委託者と業務受託者の共同作業を効率化できる。

図１は、知財業務システム１０のハードウェア構成図である。
知財業務支援装置１００は、企業３００ａや企業３００ｂなどの複数の業務委託側の企業（以下、単に「企業３００」という）、特許事務所４００ａや特許事務所４００ｂなどの複数の業務受託側の特許事務所（以下、単に「特許事務所４００」とよぶ）とインターネット１２を介して接続される。また、知財業務支援装置１００は、インターネット１２を介して特許庁２００などの官公庁のサイトの他、無数のウェブサイトと接続されている。特許庁２００は、日本特許庁に限らず、欧州や米国の特許庁であってもよい。
インターネット１２によって接続された知財業務支援装置１００や企業３００、特許事務所４００等によって、本実施例における知財業務システム１０が構成される。

以下、本実施例においては、知財関連業務の例として、特許、実用新案、意匠、商標、著作権などのいわゆる知的財産関連法のうち、特許を題材として説明する。また、出願、拒絶理由対応、訴訟、契約、鑑定、調査等のうち、特に、発明提案から国内特許出願までを中心とした出願業務を題材として説明する。

企業３００内において発明の提案がなされ、特許出願を行う場合、出願業務の一部を特許事務所４００に委託することになる。企業３００は出願業務の業務委託主体であり、特許事務所４００は出願業務の業務受託主体となる。知財業務支援装置１００は、複数の企業３００および複数の特許事務所４００で出願業務の委託・受託を仲介・支援するための装置である。国内企業の他にも大学や個人、外国企業も業務委託主体となることができるし、国内特許事務所の他にも外国特許事務所も業務受託主体となることができる。本実施例では、国内企業から国内特許事務所に出願業務の委託がなされる場合を中心として説明する。

図２は、知財業務システム１０による業務支援内容を説明するための概念図である。
同図において、Ｓ１〜Ｓ４とあるのは案件スペースを示す。各案件スペースに特許案件のデータが蓄積される。たとえば、企業３００ｃが特許案件Ａ１を知財業務支援装置１００に発注すると、知財業務支援装置１００は特許案件Ａ１に対応した記録用の領域として案件スペースＳ１を生成する。特許案件Ａ１は、企業３００ｃが業務委託側となり、特許事務所４００ｂが業務受託側となっている。知財業務支援装置１００は特許案件ごとにアクセスを許可する企業３００や特許事務所４００を特定するための情報を保持している。企業３００ｃ以外の企業３００ａ、ｂ、ｄは、特許案件Ａ１の案件スペースＳ１にデータを書き込むことも案件スペースＳ１からデータを取得することもできない。同様に、知財業務支援装置１００は特許事務所４００ｂ以外の特許事務所４００ａや特許事務所４００ｃの案件スペースＳ１に対するデータアクセスを許可しない。特許案件Ａ１の案件スペースＳ１にアクセスできるのは、企業３００ｃと特許事務所４００ｂのみである。

特許案件Ａ２の業務委託側となっているのは企業３００ａと企業３００ｂである。これは、企業３００ａと企業３００ｂが特許案件Ａ２に関して共同出願人の関係にあることを示す。特許案件Ａ２は特許事務所４００ｂによって代理されている。

特許案件Ａ３の場合、出願業務においては特許事務所４００ｂにより代理されていたとする。そして、このあと特許案件Ａ３の代理事務所が特許事務所４００ｂから特許事務所４００ｃに変更されている。代理変更がなされると、特許事務所４００ｂは案件スペースＳ３にアクセスできなくなる。代わりに、今まで案件スペースＳ３にアクセスできなかった特許事務所４００ｃはアクセス許可されることになる。このような処理によれば、いわゆる企業３００ｃから特許事務所４００ｃに包袋自体を送り直す必要が発生しないため、関係者間の業務が省力化される。

特許案件Ａ４には、特許事務所４００ｃと特許事務所４００ａが関係している。ここで、特許事務所４００ｃは国内の特許事務所であり、特許事務所４００ａは米国の特許事務所である。したがって、企業３００ｄが米国出願時に特許事務所４００ａを特許案件Ａ４の関係者として指定すると、特許事務所４００ａは特許案件Ａ４の案件スペースＳ４にアクセス可能となる。代理人変更と同様に代理人追加が発生したときにも、同様に関係者間の業務が省力化される。また、案件スペースＳ４の内部には、国内用の案件スペースと米国用の案件スペースがそれぞれ含まれるとしてもよい。

各企業３００や特許事務所４００と知財業務支援装置１００が送受するデータは、ＳＳＬ（Secure Socket Layer）プロトコルやＴＬＳ（Transport Layer Security）プロトコルによって暗号化される。案件スペースに対するアクセス可否管理に加えて、このような暗号化通信によりデータ伝送時におけるセキュリティを確保している。

本実施例では、企業３００や特許事務所４００を単位としたアクセス権限管理ではなく、人を単位としてアクセス権限管理するとして説明する。したがって、案件スペースにアクセスできるのは、実際には、発明者や知財担当者、担当弁理士等のごく少数に限定される。

同図に示した知財業務管理方法に対して、企業３００が自ら知財管理のためのシステムを構築するというアプローチも考えられる。しかし、各企業３００がシステムを独自開発した場合には、特許事務所４００はシステムの種類だけさまざまなユーザインタフェースに対応する必要が生じる。これに対して、本実施例に示す知財業務システム１０の場合、知財業務支援装置１００が統一したユーザインタフェースを提供できる。知財業務支援装置１００はＸＨＴＭＬ（eXtensible HyperText Markup Language）ファイルやジャバアプレット（JavaApplet）を送信することで企業３００や特許事務所４００のウェブブラウザに対するユーザインタフェースを提供してもよい。企業３００や特許事務所４００は、知財業務支援装置１００に登録するだけで知財業務システム１０に参加できる。そのため、企業３００や特許事務所４００の側には知財業務システム１０を利用するにあたって特段の追加投資が発生することもないというコスト面のメリットがある。

図３は、知財業務支援装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、主として各機能ブロックの発揮すべき機能について述べ、その具体的な作用については、図５以降に関連して説明する。

知財業務支援装置１００は、ユーザインタフェース処理部１１０、通信部１２０、データ処理部１５０およびデータ保持部１８０を含む。
ユーザインタフェース処理部１１０は、知財業務支援装置１００の管理者からの入力処理や管理者に対する情報表示のようなユーザインタフェース全般に関する処理を担当する。通信部１２０は、特許庁２００や企業３００、特許事務所４００やその他のウェブサイトとの通信処理を担当する。
本実施例においては、ユーザインタフェース処理部１１０により知財業務支援装置１００の管理者に対するユーザインタフェースサービスが提供されるものとして説明する。別例として、管理者は管理者用端末からインターネット１２を介して知財業務システム１０を操作してもよい。この場合、通信部１２０は、管理者端末からの操作指示情報を受信し、またその操作指示に基づいて実行された処理結果情報を管理者端末に送信することになる。

データ処理部１５０は、ユーザインタフェース処理部１１０を介した入力操作や通信部１２０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１５０は、ユーザインタフェース処理部１１０、通信部１２０およびデータ保持部１８０の間のインタフェースの役割も果たす。
データ保持部１８０は、あらかじめ用意された各種の設定データや、データ処理部１５０から受け取った記事データをはじめとするさまざまなデータを格納する。

データ保持部１８０は、ユーザ情報保持部１８２、画像保持部１８４および案件データ保持領域１８６を含む。
知財業務支援装置１００にユーザ登録すると、ログインのためのユーザＩＤとパスワードが発行される。ユーザは、発明者や知財部員、弁理士、特許技術者、特許事務員等が想定される。ユーザ情報保持部１８２は、ユーザ名、電子メールアドレス、ユーザＩＤ、パスワード、各ユーザが所属する企業や特許事務所などの組織名を含むユーザ情報を保持する。画像保持部１８４は、ユーザの顔写真や、企業３００や特許事務所４００の商標等の画像データを保持する。

案件データ保持領域１８６は、各特許案件についてのデータを保持する。案件データ保持領域１８６はハードディスク等の記憶領域に過ぎず、特許案件が発注されるごとに案件データ保持領域１８６には案件データ保持部１８８が生成される。各案件データ保持部１８８は図２でいう案件スペースに相当し、１つの特許案件に関するデータを次の図４に示すフォーマットにて管理するための記憶領域である。特許案件の発注指示がなされるごとに、後述の案件スペース生成部１５４は案件データ保持領域１８６に案件データ保持部１８８を生成する。したがって、案件データ保持領域１８６には通常、常時複数の案件データ保持部１８８が含まれることになる。なお、各案件データ保持部１８８に保持されるデータはデータ処理部１５０の図示しない暗号処理部によって暗号化される。このため、案件データ保持部１８８に不正侵入がなされたり、あるいは、案件データ保持部１８８を含む記録装置自体が盗難にあったときにも、データ漏洩を防止しやすくなる。関係者がデータの読み出しを要求すると、暗号処理部が該当データを復号する。

通信部１２０は、クライアント端末通信部１２２と関連データ通信部１２４を含む。クライアント端末通信部１２２は、企業３００や特許事務所４００に設置されるクライアント端末との通信を担当する。関連データ通信部１２４は、特許庁２００や他のウェブサイトから特許案件の関連データを取得する。特許案件Ａ１を出願するときには、その特許案件Ａ１の先行技術文献を取得する必要があるし、特許案件Ａ１が出願された後には、拒絶理由通知において指定された引用文献を取得する必要がある。また、特許庁２００が提供する特許案件Ａ１の審査経過を示す経過情報を取り寄せる必要も生じる。関連データとは、このように、特許案件の関係者以外から取得されるデータである。関連データとその取得については、関連データ処理部１５８を説明するときに更に説明する。

クライアント端末通信部１２２は、更に、データ通信部１２６と通知部１３０を含む。
データ通信部１２６は、クライアント端末と各種データを送受する。データ通信部１２６は、ページ送信部１３４、コンテンツ通信部１３６、設定通信部１２８およびユーザコミュニケーション処理部１３２を含む。

ページ送信部１３４は、ウェブページデータを企業３００や特許事務所４００のクライアント端末に送信する。ウェブページデータは、ＸＨＴＭＬ形式のファイルであってもよいし、ＸＭＬ（eXtensible Markup Language）ファイルとＣＳＳ（Cascading Style Sheets）ファイルのセットであってもよい。また、ウェブページデータにはジャバアプレットが含まれてもよい。ウェブページデータには、画像保持部１８４に保持されている各種画像データが含まれることもある。クライアント端末はウェブページデータを受信して、図５以降に示す各種画面を表示させる。

コンテンツ通信部１３６は、データ保持部１８０に保持されている各種コンテンツデータをクライアント端末に送信する。また、クライアント端末から各種コンテンツデータを受信する。ここでいうコンテンツデータには、特許明細書原稿や意見書、手続補正書等、特許事務所４００において作成されるデータが含まれる。なお、本実施例において「特許明細書原稿」とは特許明細書自体はもちろん、願書や特許請求の範囲、図面、要約書等まで含めた意味であるとして説明する。また、発明資料や特許明細書原稿についてのコメント、特許事務所４００に対する出願指示書等、企業３００内で用意されるデータもコンテンツデータに相当する。このようにコンテンツデータとは、特許案件の内容に関連する実体的な情報を指す。

設定通信部１２８は、特許案件の管理のための書誌的事項に関連してさまざまな設定を受け付ける。設定通信部１２８は、発注受信部１４０、属性受信部１４２および関係者指定受信部１４４を含む。発注受信部１４０は、特許案件の発注指示を受け付ける。企業３００の知財部員が後に示す案件発注画面２３０にて特許案件を発注指示すると、クライアント端末から発注指示データが送信される。発注受信部１４０は、この発注指示データを受信する。属性受信部１４２は、特許案件の書誌的情報、たとえば、発明の管理番号や発明名称、出願人の名前など、特許案件の内容を識別するための属性情報を受信する。属性情報の一部は発注指示データの一部として送信される。この場合、属性受信部１４２は発注指示データの一部から属性情報を抽出することになる。図５の案件発注画面２３０や図６の関係者設定画面２５０において関係者を設定すると、クライアント端末から関係者指定データが送信される。関係者指定受信部１４４は、この関係者指定データを受信する。

ユーザコミュニケーション処理部１３２は、ユーザ間で意見交換するためのコミュニケーション処理を担当する。コミュニケーションは電子掲示板方式にてテキストデータによりなされてもよいし、ＶｏＩＰ（Voice over Internet Protocol）技術により音声データによりなされてもよい。音声方式の場合、ユーザコミュニケーション処理部１３２は、送信側ユーザが発話した音声データを受信し、受信側ユーザにその音声データを送信することにより双方のコミュニケーションを成立させる。電子掲示板方式の場合、ユーザコミュニケーション処理部１３２は、送信側ユーザが投稿したテキストデータを受信し、受信側ユーザにそのテキストデータを送信することによりコミュニケーションを成立させる。
本実施例においては、電子掲示板方式によるテキストデータの送受によりユーザ間のコミュニケーションを実現している。具体的なユーザインタフェース態様については図８に関連して詳述する。

通知部１３０は、クライアント端末に対する各種通知を行う。本実施例においては通知は電子メールによりなされる。通知部１３０は、アクセス通知部１４６と予定通知部１４８を含む。アクセス通知部１４６は、あるユーザにより所定のアクセスが発生したときに、別のユーザに対してアクセスが発生した旨を通知する。たとえば、コンテンツ通信部１３６が特許事務所４００から特許明細書原稿データを受信したときには、アクセス通知部１４６は企業３００の発明者や知財部員に対して、特許明細書原稿を受信した旨を通知する。アクセス通知部１４６の通知処理によれば、特許事務所４００から企業３００に対して、特許明細書原稿を送信した旨を別途通知する必要がなくなるため、特許事務所４００側の業務が省力化される。どのようなアクセスが発生したときに誰に、どのような内容にて通知するかは、特許案件ごとに関係者が設定できる。

予定通知部１４８は、特許案件の進捗状況に応じて、関係者に作業の催促等を行う。出願業務に含まれるさまざまな作業には予定日時や期限が設定されることが多い。また、出願期限によって、他の作業の期限が逆算的に設定されることも多い。こうしたスケジュールや進捗状況といったデータも案件データ保持部１８８によって保持されている。予定通知部１４８は、所定の作業について期限が近づいてきたときには、その作業の責任者となるユーザに期限が近づいている旨を通知する。たとえば、特許案件Ａ１の特許明細書原稿の企業３００への納品期限が２月１０日と設定されていれば、その所定日数前、たとえば、３日前の２月７日に「納品期限まであと３日です。遅れる場合は、知財担当者にご一報ください」という定型メッセージを記載した電子メールを予定通知部１４８は自動的に特許事務所４００の担当弁理士に送信する。このような予定通知によって、作業責任者となるユーザが期限を忘れないように処置できる。

データ処理部１５０は、スケジュール管理部１５２、案件スペース生成部１５４、認証処理部１５６、関連データ処理部１５８および文献検索部１６０を含む。
スケジュール管理部１５２は、特許案件ごとのスケジュール管理を担当する。スケジュール管理部１５２は、スケジュール生成部１６２、進捗データ更新部１６４および実行権管理部１６６を含む。スケジュール生成部１６２は、特許案件の業務スケジュールの内容を示すスケジュールデータを生成する。スケジュールデータは、業務発注側のユーザにより作成されてもよい。また、ユーザがスケジュールデータの一部を設定すると、半自動的に他の作業についての作業予定日時を決定してもよい。たとえば、特許出願予定日が設定されると、特許明細書原稿の納品予定日をその１０日前に自動的に設定することにより、出願業務に含まれる複数の作業についての作業予定日時を設定してもよい。スケジュールデータとその生成処理については図９に関連して説明する。

進捗データ更新部１６４は、進捗データを管理する。進捗データとは、スケジュールデータと比較した実際の作業の進捗状況を示すデータである。進捗データとその更新処理については図１０に関連して説明する。実行権管理部１６６は実行権を管理する。出願業務には、発明資料の用意や弁理士との面談、特許明細書原稿の作成や修正等、さまざまな作業が含まれる。これらの作業は、明細書作成作業のように１人のユーザ（弁理士）が作業責任者になることもあれば、明細書修正作業のような複数のユーザ（知財部員、発明者、弁理士）による共同作業もある。この共同作業においては、特許明細書原稿に対する弁理士による修正や特許明細書原稿の内容に対する発明者や知財部員のコメントなど複数のユーザによるアクセスが発生する。実行権管理部１６６は、共同作業において作業主体となるユーザを実行権の設定によって管理している。共同作業と実行権については、図１２に関連して詳述する。

案件スペース生成部１５４は、発注受信部１４０が発注指示データを受信したときに、データ保持部１８０の案件データ保持領域１８６に専用の案件スペースとして案件データ保持部１８８を生成する。案件データ保持部１８８は、ハードディスク等の読み書き可能な補助記憶装置にフォルダ（ディレクトリ）のかたちで生成されてもよい。案件スペース生成部１５４のバックアップ処理部１６８は、定期的に、たとえば、１日ごとに案件データ保持部１８８のデータを案件データ保持領域１８６とは別領域、たとえば、外部記録媒体にバックアップする。あるいは、バックアップ処理部１６８は、案件データ保持部１８８に対するデータ書き込みが発生したことを条件として、上記したようなバックアップ処理を実行してもよい。

関連データ処理部１５８は、特許庁２００の電子図書館等、外部のウェブサイトから特許案件の関連データを取得する。ここでは、例として、出願済の特許案件Ａ１について説明する。出願後１年半を経過すると、特許案件Ａ１の特許明細書の内容は特許庁２００によって電子的に公開される。関連データ処理部１５８は、この特許案件Ａ１が出願されてからの日数を計数し、１年半が経過した後に特許庁２００の電子図書館等に自動的にアクセスして、関連データ通信部１２４に特許案件Ａ１の公開公報を取得させる。取得した公開公報データは特許案件Ａ１の関連データとして、特許案件Ａ１の案件スペースＳ１に該当する案件データ保持部１８８に格納される。このほか、拒絶理由通知が特許庁２００から発送されたときには、関連データ通信部１２４はこれを受信する。関連データ処理部１５８は、拒絶理由通知に引用文献として記載されている公開公報の番号を検出し、関連データ通信部１２４に指示して、これらの引用文献データを特許庁２００の電子図書館から取得させる。こうした引用文献も関連データとして対応する案件データ保持部１８８に格納される。また、関連データ処理部１５８は、特許庁２００の電子図書館から特許案件Ａ１の出願後の経過情報を取得してもよい。関連データ処理部１５８の処理により、案件データ保持部１８８にはコンテンツデータだけでなく、それらに付随する関連データが自動的に収集されるため、特に、特許事務員の作業負荷が軽減される。

更に、関連データ処理部１５８は外部の出願端末をコントロールしてもよい。特許明細書原稿の内容が確定すると、関連データ処理部１５８は案件データ保持部１８８の特許出願原稿を出願用のフォーマットに変換し、関連データ通信部１２４は変換後の出願データを出願端末に転送する。そのあと、出願端末に出願指示コマンドを送信することにより、出願端末から特許庁２００への出願処理が実行される。あるいは、関連データ処理部１５８と関連データ通信部１２４自体が出願端末としての機能を備えてもよい。

認証処理部１５６は、案件データ保持部１８８に外部へのアクセスの可否を判定する。認証処理部１５６は、ユーザ認証部１７０とデータ認証部１７２を含む。
ユーザが知財業務支援装置１００に対してなんらかのアクセスを要求するとき、クライアント端末から知財業務支援装置１００にはアクセス要求データが送信される。このアクセス要求データにはアクセス要求元を特定するためのユーザＩＤやアクセス要求先となる特許案件を特定するためのワークスペース番号が含まれる。ワークスペース番号とは特許案件を一意に識別するためのＩＤである。ユーザはワークスペース番号を指定した上で、各種のアクセス要求を送信させることになる。

ユーザ認証部１７０は、このときアクセス権限のあるユーザからのアクセス要求であるかを判定する。たとえば、発明資料のダウンロードを要求するためのアクセス要求データにワークスペース番号「００１４」およびユーザＩＤ「１１６」が含まれていたとする。ユーザ認証部１７０はユーザＩＤ「１１６」がワークスペース番号「００１４」の特許案件の関係者のユーザＩＤとして登録されているか判定する。登録されていなければダウンロード要求は拒否される。このようにして、不正ユーザからのデータ窃取を防止している。

データ認証部１７２は、ユーザがコンテンツデータを間違えてアップロードするのを防止する。たとえば、図２の設定を再び引用すると、特許事務所４００ｃの弁理士Ｍは特許案件Ａ３と特許案件Ａ４を担当しているとする。そのため、弁理士Ｍは特許案件Ａ３の案件データ保持部１８８と特許案件Ａ４の案件データ保持部１８８の両方にアクセス可能である。ここで、特許案件Ａ３の業務委託者は企業３００ｃであり特許案件Ａ４の業務委託者は企業３００ｄである。弁理士Ｍが特許案件Ａ３の特許明細書原稿を作成して知財業務支援装置１００に送信するときに、間違えて、特許案件Ａ４のワークスペース番号を指定して送信してしまうという人的ミスが発生する可能性がある。データ認証部１７２は、このような人的ミスによる事故の発生を防ぐために機能する。

コンテンツ通信部１３６が間違ったワークスペース番号を指定して送信された特許明細書原稿を受信すると、属性受信部１４２は特許明細書原稿から案件の管理番号や出願人名等の属性情報を抽出する。たとえば、特許明細書原稿の願書部分の記載からこれらの情報を取得する。データ認証部１７２は、送信先として指定された特許案件Ａ４の属性情報を参照し、抽出された属性情報と整合していなければアップロードを許可しない。
このように、ユーザ認証部１７０およびデータ認証部１７２によって、ユーザおよびデータの両面から案件データ保持部１８８のセキュリティを確保している。

文献検索部１６０は、外部のウェブサイトを対象として文献検索処理を実行する。文献検索部１６０は、単語抽出部１７４と検索部１７６を含む。単語抽出部１７４は、コンテンツデータ、たとえば、発明資料から単語を抽出する。単語抽出部１７４は、これらの単語群のうち、技術用語としてあらかじめ登録されている単語を選択する。単語抽出部１７４は、更に、発明資料において特に頻出する単語を選抜してもよい。検索部１７６は、単語抽出部１７４により選択された単語を組合せて検索式を作り、関連データ通信部１２４に指示して電子図書館等の特許データベースから特許文献を検索させる。このような検索処理によれば、発明資料をベースとした先行技術文献の自動収集が可能となる。

更に発展的な変形例としては、単語抽出部１７４は２以上の特許明細書原稿に共通して含まれる単語を抽出し、検索部１７６はこれらの共通単語を用いて関連文献をウェブサイトから検索してもよい。このような検索処理によれば、たとえば、特許案件の変形例や複数の特許案件に関連する技術分野やアイディアなどを発見しやすくなる。また、企業内のデータベースに管理されている複数の特許案件を対象として、アイディア出しのために単語抽出を行ってもよい。たとえば、単語抽出部１７４は、特許案件Ａから抽出された単語群と、特許案件Ｂから抽出された単語群をマージした単語群から、所定数、たとえば、２０個の単語を選択してもよい。選択対象となる単語はランダムに選択されてもよいし、出現頻度が多い順に選択してもよい。このようにして抽出された単語をキーワードとして、ブレインストーミングを行うことにより、新しいアイディアを求めてもよい。より具体的な例として、特許案件Ａには、要素技術ａ、ｂ、ｃ、ｄからなる発明が開示されているとする。一方、特許案件Ｂには、要素技術ａ、ｅ、ｆ、ｇからなる発明が開示されているとする。特許案件Ａと特許案件Ｂは、技術分野的には全く異なる発明であるかもしれないが、共に要素技術ａを利用している点で共通する。このような場合、共通の要素技術ａを介して、ｂ、ｃ、ｄやｅ、ｆ、ｇを組み合わせて提示すれば、新発明の創出に資する。このような処理方法によれば、複数の技術分野に分散している知見を新しいアイディアの源泉とする効果的なアイディア創出支援が可能となる。

図４は、案件データ保持部１８８のデータ構造図である。
同図に示す案件データ保持部１８８は、特許案件Ａ１に関する案件スペースであるとして説明する。
属性情報保持部２１０は、特許案件Ａ１の属性情報を保持する。属性情報は属性受信部１４２によってクライアント端末から受信するデータである。発明資料保持部２１２は、発明者や知財部によって用意される発明資料を保持する。発明資料のデータは、コンテンツ通信部１３６によって企業３００のクライアント端末から受信する。発明資料保持部２１２には先行文献保持部２１４が含まれており、知財部員や発明者によって、または、文献検索部１６０によって自動検索された先行技術文献のデータが保持される。出願原稿保持部２１６は、弁理士によって作成された特許明細書原稿を保持する。このほかにも、意見書や補正書等、さまざまな庁手続き用のデータが保持される。出願原稿保持部２１６は、一種の作業領域であり、特許明細書に関する備忘録的なメモ等を保持する場合もある。発明資料保持部２１２や出願原稿保持部２１６に保持されるデータがコンテンツデータとなる。

関係者情報保持部２１８は、関係者指定受信部１４４によって受信した関係者指定データを保持する。ここでは、ユーザ情報保持部１８２に登録されているユーザのうち特許案件Ａ１の関係者のユーザＩＤを関係者情報として保持する。関係者は、図６の関係者設定画面２５０に対する入力操作によって指定される。
オフィシャルデータ保持部２２０は、関連データ通信部１２４が特許庁２００から受信した拒絶理由通知や特許許可通知等のデータを保持する。また、実際に特許庁２００に出願された特許明細書原稿データやプルーフ等もオフィシャルデータ保持部２２０に保持される。スケジュール保持部２２２は、後の図９に示すスケジュールデータを保持する。進捗データ保持部２２４は、後の図１０に示す進捗データを保持する。

通信領域２２６は、ユーザ間のコミュニケーションのための領域である。特許案件Ａ１の関係者として登録されているユーザが投稿用にテキストデータを送信すると、通信領域２２６にその投稿データが記録される。特許案件Ａ１の関係者は、通信領域２２６に記録されている投稿データを適宜閲覧できる。通信領域２２６には、更に、限定通信領域２２８ａや限定通信領域２２８ｂ等が含まれる。関係者間によるコミュニケーションであっても、たとえば、知財部員と発明者だけ、あるいは、複数の発明者がいるときには発明者間だけで協議したい場合もある。そのような場合、ユーザは、コミュニケーションの対象となる関係者を指定した上で限定通信領域２２８を生成させることができる。ここで、限定通信領域２２８ａが知財部員と発明者に限定した通信領域であるとする。その場合、弁理士Ｒが特許案件Ａ１の関係者であっても、限定通信領域２２８ａの投稿データの内容を閲覧することはできない。

図５は、案件発注画面２３０の画面図である。
企業３００において知財部員が特許案件を新規国内出願するときには、知財業務支援装置１００にログインして案件発注画面２３０を呼び出す。ここでは、企業３００の知財部員「瀬崎正志」（以下、単に「知財部員Ｓ」とよぶ）が知財業務支援装置１００から案件発注画面２３０を表示させた場合に、知財部員Ｓのクライアント端末で表示される画面である。案件発注画面２３０はウェブページとして表示されるので、ウェブブラウザを備えていればどのようなクライアント端末からでも閲覧できる。ワークスペース番号領域２３２は、ワークスペース番号を示す。知財担当者が案件発注画面２３０を呼び出すと、その特許案件を一意に識別するためのワークスペース番号が知財業務支援装置１００によって割り当てられる。同図においては「００１２」というワークスペース番号が割り当てられている。

案件名設定領域２３４は、特許案件の仮名称または正式名称を入力するための領域である。管理番号設定領域２３６には、知財部員Ｓの所属する企業３００が特許案件を管理するための管理番号が入力される。知財担当設定領域２３８は、特許案件を担当する知財部員を指定するための領域である。同図においては、知財部員として「瀬崎正志」だけが指定されている。ＯＫボタン２４０がクリックされると、案件発注画面２３０において設定された各データが発注指示データの一部として知財業務支援装置１００に送信される。知財業務支援装置１００の発注受信部１４０が発注指示データを受信すると、案件スペース生成部１５４は案件データ保持領域１８６にワークスペース番号「００１２」の特許案件に対応する案件データ保持部１８８を生成する。属性受信部１４２は、案件名や管理番号といった属性情報を取得し、これらの属性情報は生成されたばかりの案件データ保持部１８８の属性情報保持部２１０に記録される。更に、知財担当設定領域２３８に示される関係者指定データは関係者指定受信部１４４によって抽出され、関係者情報保持部２１８に記録される。キャンセルボタン２４２がクリックされたときには、案件発注画面２３０の入力内容はキャンセルされる。この場合、ワークスペース番号「００１２」は空き番号のままとなる。

図６は、関係者設定画面２５０の画面図である。
案件発注画面２３０により、特許案件の発注がなされた後、知財部員はその特許案件の関係者を指定する。このため知財部員Ｓは、関係者設定画面２５０を呼び出す。
出願人表示領域２５１には、知財部員Ｓが所属する企業３００の名前が自動的に表示される。知財部員Ｓが知財業務支援装置１００に対して関係者設定画面２５０の表示を要求するときには、知財部員ＳのユーザＩＤがあわせて送信される。ユーザ情報保持部１８２には知財部員Ｓとその所属する企業３００とが対応づけられている。ページ送信部１３４が関係者設定画面２５０のデータを送信するときには、知財部員Ｓが所属する企業３００である「Ｎ株式会社」という情報をウェブページの一部として送信する。図２の特許案件Ａ２のように共願の場合も想定する場合は、出願人表示領域２５１にて複数の出願人を指定できてもよい。ここでは「Ｎ株式会社」による単独出願であるとして説明する。

知財担当設定領域２５２は担当の知財部員を設定するための領域であり、案件発注画面２３０の知財担当設定領域２３８と同様である。案件を発注したあとも、知財担当者の変更・追加が可能となっている。たとえば、知財部員Ｓから知財担当が別の知財部員に変更されると、以降、知財部員Ｓは特許案件Ａ１の関係者ではなくなるので、特許案件Ａ１の案件データ保持部１８８にアクセスできなくなる。このため、知財部員Ｓが別の企業３００に転職した場合であっても、企業３００の知的財産情報の漏洩を防止できる。

発明者設定領域２５４は、発明者を設定するための領域である。ここでは、「古森純哉」（以下、「発明者Ｋ」とよぶ）と「四型雅紀」（以下、「発明者Ｓ」とよぶ）の２名が設定され、それぞれの発明に対する貢献度がパーセンテージで設定される。同図においては、貢献度は５０パーセントずつに設定されている。関係者設定画面２５０では、発明者を３名まで設定できるが、増員ボタン２５６をクリックすると更に多くの発明者を設定するためのダイアログボックス（図示せず）が表示される。

特許事務所設定領域２５８は、業務発注先となる特許事務所４００を指定する領域である。同図においては、「Ｐ特許事務所」が指定されている。また、担当弁理士設定領域２６０においては担当希望弁理士として「元永尚一」（以下、「弁理士Ｍ」とよぶ）が指定されている。ただし、この段階では担当希望にすぎず、弁理士Ｍには特に何の通知もなされない。アサインボタン２６２がクリックされると、知財部員Ｓに加えて発明者Ｋおよび発明者Ｓが関係者情報保持部２１８の関係者情報に登録される。キャンセルボタン２６４がクリックされたときには、関係者設定入力はキャンセルされる。

依頼実行となると、知財部員Ｓは図示しない依頼画面にて弁理士Ｍに特許明細書の作成依頼を発注する。通知部１３０は、Ｐ特許事務所の電子メールアドレス、または、弁理士Ｍの電子メールアドレスに、特許明細書作成依頼のための電子メールを送信する。この電子メールには、特許案件の属性情報の全部または一部が自動的に記載されてもよい。弁理士Ｍが受任の旨を返信すると、関係者情報保持部２１８の関係者情報には新たに弁理士Ｍが登録される。こうして、業務委託側である知財部員Ｓおよび発明者Ｋ、Ｓと、業務受託側である弁理士Ｍが関係者として設定される。

図７は、案件一覧画面２７０の画面図である。
関係者が決定すると、知財部員Ｓ、発明者Ｋ、Ｓおよび弁理士Ｍだけが、この特許案件の案件データ保持部１８８にアクセス可能となる。案件一覧画面２７０は弁理士Ｍが知財業務支援装置１００にログインして、自分の担当している案件の一覧を呼び出したときに表示される画面である。同図によると、弁理士Ｍは現在４件の特許案件を担当している。このうち、４件目の「ブログからの情報抽出」という案件が、図５および図６において発注・依頼された案件である。

案件名表示領域２７２は、各案件の仮名称を示す。案件名をクリックすると、その案件に関連して各種画面が表示される。たとえば、コンテンツデータのアップロードやダウンロードを行うための画面、特許案件の属性情報や関係者情報の閲覧画面、特許案件のスケジュールや進捗状況を確認するための画面、特許案件に関して関係者間で意見交換するための画面などである。

種別表示領域２７４は、各案件の種別を示す。種別とは、特許、実用新案、意匠、商標等の法域の別、国内案件または海外案件の別、出願、拒絶理由対応、審判、訴訟等の業務内容の別等を示す。たとえば、さきほどの「ブログからの情報抽出」の案件は、種別表示領域２７４によると特許案件であって、国内新規出願に関する案件であることがわかる。状態表示領域２７６は、現在の処理状態を示す。特許出願は、発明提案からさまざまな作業を経て出願に至る。状態表示領域２７６は、各特許案件がどのような処理状態にあるかを示す。更新日表示領域２７８は、案件データ保持部１８８の最新更新日時を示す。

クライアント商標表示領域２８０は、特許案件の委託側となる企業３００の商標画像が表示される。画像保持部１８４には、知財業務支援装置１００に登録されている企業３００の商標が画像データとして保持されている。案件一覧画面２７０においては、案件ごとに出願人となる企業３００の商標画像が表示される。同図によると、弁理士Ｍは、４件の特許案件を３社から受任している。同図に示す上から１件目の案件と２件目の案件は別々の企業から依頼された案件である。また、共に、特許明細書作成中という状態になっている。商標画像は、２件目「ディスプレイカバーリング」の特許明細書原稿を弁理士Ｍが誤って１件目「マニュアル提供システム」の案件データ保持部１８８に送信するという人的ミスを抑制するために表示される。商標画像のほかにも、関係者の顔写真が表示されてもよい。弁理士Ｍは、商標画像等を確認することにより、送り先ミスが生じないように注意しやすくなる。

図８は、通信画面２９０の画面図である。
通信画面２９０は、ワークスペース番号「００１２」の特許案件「ブログからの情報抽出」について、関係者間で意見交換をするための画面である。ここでは、知財部員Ｓ「瀬崎正志」と発明者Ｋ「古森純哉」がこの特許案件に関する意見交換をしている。案件情報表示領域２９２は、特許案件の属性情報を示す。通信欄領域２９４は、関係者が意見交換するための電子掲示板である。ここには、各ユーザの投稿データが一覧表示される。コメント入力ボタン２９６がクリックされると、投稿データ入力のための画面（図示せず）が表示される。同図の通信欄領域２９４は、限定通信領域２２８による知財部員Ｓと発明者Ｋだけが閲覧・入力可能な電子掲示板である。

投稿データ入力されると、ユーザコミュニケーション処理部１３２は、この投稿データを受信して、該当する限定通信領域２２８に記録する。限定通信領域２２８ａに関係するユーザは、ユーザコミュニケーション処理部１３２を介して、限定通信領域２２８ａの投稿データをクライアント端末で閲覧できる。知財部員Ｓと発明者Ｋのように、関係者の一部でなされるコミュニケーションのデータも限定通信領域２２８に記録として残すことができる。

図９は、スケジュール保持部２２２に保持されるスケジュールデータのデータ構造図である。
ここでは、さきほどのワークスペース番号「００１２」の特許案件が特許案件Ａ１であるとする。特許案件Ａ１は、案件発注画面２３０において登録されると、発明者の選定や知財部と発明者との社内面談等の各種作業を経て、最終的に特許出願に至る。作業内容欄３０２は作業内容を示す。作業予定日時欄３０４は作業予定日時を示す。作業予定日時は、関係者、たとえば、知財部員Ｓの入力操作にしたがって設定される。スケジュール生成部１６２は、作業予定日時の設定を受け付けた上でスケジュールデータを生成する。スケジュール生成部１６２は、作業予定日時の一部が設定されると、残りの作業予定日時を自動的に設定してもよい。たとえば、知財部員が出願予定日時を指定すると、発注日時と出願予定日時からその他の作業の作業予定日時を自動的に算出してもよい。

スケジュール生成部１６２は、発注日時から出願予定日時まで５０日以上あるときには特許明細書原稿納品予定日時を出願予定日時の１０日前、発注日時から出願予定日時までが４０日以上５０日未満のときには原稿納品予定日時を出願予定日時の５日前、というように所定の規則にしたがって原稿納品予定日時を自動的に設定してもよい。もちろん、知財部員は、スケジュールデータが生成された後も、その作業予定日時を調整可能である。スケジュール生成部１６２は、関係者のワークロードを加味して作業予定日時を決定してもよい。たとえば、発注日時から出願予定日時が４０日以上５０日未満のときであっても、弁理士Ｍのワークロードとして「高」、「中」、「低」のうち、「高」入力設定されたときには、原稿納品予定日時を出願予定日時の５日前ではなく、３日前に設定することとしてもよい。

実行責任者欄３０６は、各処理の実行責任者のユーザＩＤを示す。ここでは知財部員ＳのユーザＩＤが「１０１」、発明者ＫのユーザＩＤが「２０２」、発明者ＳのユーザＩＤが「２０４」、弁理士ＭのユーザＩＤが「３０６」であるとする。同図によれば、たとえば、（３）社内面談は、知財部員Ｓと発明者Ｋ、Ｓの計３名で行われる。また、（６）の原稿納品の責任者は弁理士Ｍ１名となっている。
原稿納品（６）の作業予定日時２月１３日が近づくと、予定通知部１４８は弁理士Ｍに期限が近づいている旨を通知する。また、社外面談（５）の作業予定日時１月１１日の前日の１月１０日になると、予定通知部１４８は、知財部員Ｓ、発明者Ｋ、Ｓ、弁理士Ｍに翌日が社外面談の日である旨を通知する。

図１０は、進捗データ保持部２２４の進捗データのデータ構造図である。
進捗データは、スケジュールデータと比較した業務の進捗状況を示す。作業内容欄３１２は作業内容を示す。進捗状況欄３１４は、各作業の進捗状況を示す。同図によれば、発明者選定（２）は、１２月１７日に完了している。また、発明資料の用意（４）という作業はキャンセルになっている。原稿納品（６）は、図９に示したスケジュールデータによると、２月１３日が作業予定日時となっていたが、現在、作業予定日時を３日過ぎても原稿納品がなされていない状態にあることがわかる。進捗データ更新部１６４は、１日経過するごとに進捗データを更新する。また、案件データ保持部１８８に対するデータ書き込みアクセスが発生したときにも、進捗データ更新部１６４は進捗データを更新する。

図１１は、進捗表示画面３１０の一例を示す。
知財部員や弁理士、発明者等のユーザは、知財業務支援装置１００にアクセスして、自分の関連する特許案件の進捗状況を進捗表示画面３１０にて確認できる。ここでは、弁理士Ｍの２月２６日時点における進捗表示画面３１０であるとして説明する。同図によれば、弁理士Ｍは、２月２６日の時点でワークスペース番号「００１２」の「ブログからの情報抽出」とワークスペース番号「００１３」の「投稿管理装置」という２件の特許案件を担当している。同図黒丸で示す位置は、現在の処理状態を示している。一方、同図白丸で示す位置は、スケジュールデータにより２月２６日現在において予定された処理状態を示す。

たとえば、ワークスペース番号「００１２」の案件は、特許明細書の作成依頼を受けてから原稿が未納品の状態にあることを示す。しかし、スケジュールデータによればこの特許案件は２月２６日には、原稿納品を完了して原稿修正作業に移っている予定である。したがって、この特許案件はスケジュールに比べて作業が遅れていることがわかる。ワークスペース番号「００１３」の案件は、特許明細書原稿を納品してから修正作業中の状態にある。予定では、２月２６日には明細書作成中の状態にあることになっていたので、この案件についてはスケジュールに比べて作業が進んでいることがわかる。

図１２は、進捗表示画面３１０の別例を示す。
図１１においては、２月２６日時点の現状を示す黒丸が一列に並ぶ表示態様を示したが、図１２のように、２月２６日時点の予定を示す白丸が一列に並ぶ態様にて表示されてもよい。また、複数の特許案件に関して、現状を示す黒丸を線で結ぶことにより、予定から遅れている特許案件と予定よりも進んでいる特許案件を視覚的に認識しやすくなる。

図１３は、共同作業における実行権管理を説明するためのタイムチャートである。
本実施例において、特許出願に向けた各作業のうち、特許明細書原稿が納品された後の原稿修正作業は、知財部員Ｓ、発明者Ｋおよび弁理士Ｍの共同作業となる。実行権管理部１６６は、原稿修正作業について３者の作業を協調させるために実行権を管理する。

ここでは、まず、日時ｔ１に弁理士Ｍが特許明細書原稿を送信したとする。アクセス通知部１４６は、知財部員Ｓと発明者Ｋ、Ｓに特許明細書原稿がアップロードされた旨を通知する。特許明細書原稿のアップロードがなされると、実行権管理部１６６は、知財部員Ｓに実行権を設定する。実行権の設定順序は、弁理士Ｍ→知財部員Ｓ→発明者Ｋ→弁理士Ｍという順番にあらかじめ決定されている。共同作業においては、実行権を設定されているユーザしか、案件データ保持部１８８へのコンテンツデータのアップロードができなくなる。実行権はちょうど案件スペースに対するセマフォのように機能することになる。共同作業中において、各ユーザには誰が実行権を有しているかが表示される。具体的には、実行権管理部１６６は実行権を取得しているユーザ名を各ユーザに通知する。これにより、共同作業中のユーザは、どのユーザに現在の実行権があるかを適宜把握できる。なお、実行権取得ユーザ名の通知態様として、画面への常駐表示やポップアップ表示の他、電子メールによる通知も挙げられる。また、通知先としては、実行権取得ユーザだけでなく、そうでないユーザを含めてもよい。ここでは、「ユーザ名」という用語を、そのユーザのハンドルネームや顔写真等、ユーザを他から識別できる表示全てを含む概念であるとして使用している。
また、共同作業中であろうとなかろうと、今作業すべきなのは誰であるかを、そのユーザ（他のユーザも含めてもよい）に通知するようにしてもよい。これについて、通知されたユーザは、今自分が対応しなければならない作業の一覧表示を取得できる。
たとえば、スケジュール管理部１５２は図示しないタスク管理部を含んでもよい。タスク管理部は、ユーザごとのＴＯＤＯ情報を管理する。ユーザＡが知財業務支援装置１００にログインすると、タスク管理部はユーザＡに関係する、いいかえれば、ユーザＡが関係者情報に登録されている特許案件を検索する。ここでは、特許案件ａ〜ｄの４件が検出されたとする。次に、タスク管理部は、各特許案件の進捗データを参照してそれぞれの実行責任者を特定する。仮に、特許案件ａはユーザＢの作業待ちの状態、特許案件ｂ〜ｄは、ユーザＡによる作業待ちの状態にあるとする。このような場合、タスク管理部は、ユーザＡが関連する特許案件はａ〜ｄであること、そのうち特許案件ａはユーザＢが実行責任者であり、特許案件ｃ〜ｄはユーザＡが実行責任者である旨を示す情報を一覧表示するためのＨＴＭＬファイル（以下、「タスク管理ファイル」とよぶ）を生成する。タスク管理部はクライアント端末通信部１２２に指示して、タスク管理ファイルをユーザＡのクライアント端末に送信させる。特許案件ａ〜ｄのいずれかの実行責任者が変化したときには、タスク管理部はタスク管理ファイルの内容を更新して再送する。ユーザＡのクライアント端末はタスク管理ファイルを画面表示させる。このような処理によれば、ユーザＡは、クライアント端末の表示画面にて、現在自分が関わっている案件と、それらの実行責任者を適宜把握できる。

ここで日時ｔ２において、知財部員Ｓが特許明細書原稿についての修正指示コメントを送信している。コンテンツ通信部１３６は修正指示コメントを受信し、修正指示コメントは出願原稿保持部２１６に格納される。このとき、知財部員Ｓの実行権が解除され、次に、発明者Ｋに実行権が設定される。アクセス通知部１４６は実行権が移った旨を発明者Ｋに通知する。日時ｔ３に発明者Ｋが特許明細書原稿についての修正指示コメントを送信している。発明者Ｋの実行権が解除され、弁理士Ｍに実行権が設定される。日時ｔ４において、弁理士Ｍが、知財部員Ｓと発明者Ｋの修正指示コメントにしたがって、特許明細書原稿を修正してアップロードすると、実行権は弁理士から知財部員Ｓに移る。日時ｔ５に知財部員Ｓおよび発明者Ｋが修正内容を確認した上で、知財部員Ｓが出願内容を許可したら実行権が弁理士Ｍに移る。こうして、明細書修正処理（７）が完了し、次の、出願処理（８）に移行する。

明細書修正処理のように複数のユーザによる共同作業の場合には、実行権によって各ユーザの実行責任が明確化される。また、実行権管理部１６６は、実行権の保持期間をユーザごとに算出する。このような時間管理により、明細書修正処理のような共同作業において、各関係者が要した作業時間を算出できる。

図１４は、ユーザから案件スペースにデータがアップロードされるときの処理過程を示すフローチャートである。
同フローチャートは、弁理士Ｍから特許明細書原稿等のコンテンツデータが送信された場合の処理過程を示す。まず、コンテンツ通信部１３６はこのコンテンツデータを受信する。ユーザ認証部１７０は、このコンテンツデータを送信したユーザのユーザＩＤとワークスペース番号を抽出し、ワークスペース番号によって特定される特許案件の関係者情報に送信元のユーザＩＤが登録されているか判定する（Ｓ１０）。登録されていなければ（Ｓ１０のＮ）、関係のないユーザからの送信であるため特許明細書原稿は破棄される。通知部１３０は、アップロードが許可されない旨を弁理士Ｍに通知する（Ｓ２２）。

関係者として登録されている場合（Ｓ１０のＹ）、スケジュール管理部１５２は、現在、修正作業中という処理状態にあるかを判定する（Ｓ１２）。修正作業中、すなわち、共同作業中であれば（Ｓ１２のＹ）、実行権管理部１６６は弁理士Ｍに実行権が設定されているか判定する（Ｓ１４）。実行権が設定されていなければ（Ｓ１４のＮ）、処理はＳ２２に移行する。

一方、共同作業中でないときや（Ｓ１２のＮ）、共同作業中であっても実行権が設定されていれば（Ｓ１４のＹ）、属性受信部１４２はアップロード対象となるデータから属性情報を抽出する。たとえば、特許明細書原稿であれば、願書のページに記載されている管理番号や出願人名、発明者名等の情報を属性情報として抽出する（Ｓ１６）。データ認証部１７２は、抽出された属性情報の内容が案件データ保持部１８８の属性情報保持部２１０に保持されている該当データと一致するかを判定する（Ｓ１８）。属性情報を設定するための専用の属性ファイルが用意されてもよい。コンテンツデータの送信者は、属性ファイルに管理番号や仮名称等を記入して、コンテンツデータとあわせて送信してもよい。その場合には、データ認証部１７２は、属性ファイルに記述されている属性情報と属性情報保持部２１０の該当データと一致するかを判定する。

互いに属性情報が一致すれば（Ｓ１８のＹ）、データ認証部１７２はデータのアップロードを許可する。コンテンツ通信部１３６によって受信したコンテンツデータは案件データ保持部１８８の該当箇所に記録される（Ｓ２０）。一致しなければ（Ｓ１８のＮ）、処理はＳ２２に移行し、アップロード不許可の旨が通知される。

以上、本実施例における知財業務システム１０によれば、知財関連業務において、業務委託側である知財部員と発明者、業務受託側である弁理士の業務効率を向上させることができる。

知財業務支援装置１００は、発注指示データが受け付けられると、セキュリティを保証したかたちで案件データ保持部１８８を自動的に生成する。案件データ保持部１８８ごとに関係者情報によってアクセス権限が設定されるので、知的財産という有価情報の機密性を維持することができる。また、関係者情報の登録内容を変更するだけで、関係者の追加や変更を簡易に行うことができるため、特許案件の処理状況に応じて柔軟に関係者を設定しやすくなる。

また、作業状態に応じて、適宜、関係者に電子メール等によって通知される。そのため、知財業務支援装置１００は単なるデータ保管庫ではなく、積極的に関係者の作業に干渉する。このような機能により、関係者の期限管理負担の多くを肩代わりすることができる。本実施例の知財業務支援装置１００は、特許案件ごとにスケジュールを生成すると共に、スケジュールと比較した進捗状況も管理できる。このように、知財業務支援装置１００は知財関連業務全般に関するワークフローマネジメントが可能となっている。
知財業務支援装置１００は、特許案件ごとに通信領域を生成することにより、関係者間の議論の内容もコンテンツデータの一部として管理できる。また、関係者の一部だけのコミュニケーションも可能であるため、特許案件に関連する情報を案件データ保持部１８８に集積しやすい仕組みを提供している。たとえば、中間処理時においても、出願時の打ち合わせの内容を示す投稿データを再確認するといった利用法が可能となっている。テキストや音声だけでなく、動画によるコミュニケーションも考えられる。

以上、実施の形態をもとに本発明を説明した。なお本発明はこの実施の形態に限定されることなく、そのさまざまな変形例もまた、本発明の態様として有効である。

請求項に記載のアクセス要求受信部の機能は、本実施例においてはクライアント端末通信部１２２の一部、主としてコンテンツ通信部１３６や設定通信部１２８、ユーザコミュニケーション処理部１３２によって実現される。
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

このほか、知財業務支援装置１００は以下のような機能を備えてもよい。
１．特許明細書の編集履歴、あるいは、出願後の補正履歴を管理する機能
たとえば、特許明細書が補正されたときに、補正前のデータと補正後のデータの差分を管理し、補正内容を即時に確認できるようにしてもよい。また、補正履歴を管理しておき、いつでも過去のバージョンに戻せるよう処理してもよい。
２．業務担当者の実績管理機能
知財業務支援装置１００は、弁理士ごとに担当実績のある技術分野等に関する情報を蓄積してもよい。このような情報を蓄積することにより知財業務支援装置１００が弁理士検索のためのデータベースとして機能することもできる。同様に、発明者ごとに出願実績のある技術分野や過去の出願案件等の情報が蓄積されてもよい。このような情報処理によれば、知財業務支援装置１００にアクセスすることによって、発明者の研究開発実績を検索することができる。
３．業務委託者ルールの設定
知財関連業務においては、業務委託側がさまざまな管理ルールを持つことが多い。たとえば、受任から出願までの期限であったり、特許明細書の作成方針等である。このようなルールに基づいて、スケジュールの自動生成がなされたり、特許明細書が作成方針にしたがっているかをチェックする機能を備えてもよい。

以上の実施の形態および変形例から把握される発明のいろいろな態様をすでに特許請求の範囲に記載したものも含む形にて以下に例示する。

Ａ１．知財関連業務に関し、業務委託側のユーザによって使用されるクライアント端末および業務受託側のユーザによって使用されるクライアント端末の双方と通信ネットワークを介して接続され、
業務委託側のユーザが使用するクライアント端末から、知財業務案件の発注指示を示す発注指示データを受信する発注指示受信部と、
前記発注指示データが受信されたことを契機として、前記知財業務案件に関するデータを管理するための案件スペースを記録媒体上に生成する案件スペース生成部と、
前記案件スペースに対するアクセス要求をクライアント端末から受信するアクセス要求受信部と、
業務受託側のユーザを含めて前記知財業務案件の関係者となるユーザを指定する関係者指定データをクライアント端末から受信する関係者指示受信部と、
前記関係者指定データにて指定されたユーザと前記知財業務案件を対応づけた関係者情報を保持する関係者情報保持部と、
前記アクセス要求を送信したクライアント端末のユーザが前記知財業務案件の関係者として指定されたユーザであるか前記関係者情報を参照して判定し、関係者として指定されたユーザであることを条件として前記案件スペースに対するアクセスを許可する認証部と、
前記案件スペースに対する所定タイプのアクセス要求が受信されたときには、前記知財業務案件の関係者として指定されているユーザに対して前記所定タイプのアクセス要求が受信された旨を通知するアクセス通知部と、
を備えることを特徴とする知財業務支援装置。

Ａ２．業務委託側のユーザから業務受託側のユーザに対して特許明細書の作成が依頼される場合において、
前記アクセス通知部は、前記業務受託側のユーザのクライアント端末から特許明細書の原稿データが受信されると、前記業務委託側のユーザに対してその旨を通知することを特徴とするＡ１に記載の知財業務支援装置。

Ａ３．前記案件スペース生成部は、前記関係者情報に登録されているユーザが意見交換するための通信領域を生成することを特徴とするＡ１または２に記載の知財業務支援装置。

Ａ４．前記案件スペース生成部は、前記関係者情報に登録されているユーザのうちの一部のユーザだけで意見交換するための通信領域を生成可能であることを特徴とするＡ３に記載の知財業務支援装置。

Ａ５．前記通信領域は、音声データによる意見交換可能な領域であることを特徴とするＡ３または４に記載の知財業務支援装置。

Ａ６．ユーザを示す画像データまたはユーザの所属先を示す画像データを保持する画像保持部と、
前記案件スペースに対するアクセス要求が受信されたときに、前記関係者情報に登録されているユーザに対応する画像データをアクセス要求送信元のクライアント端末に送信する画像送信部と、
を更に備えることを特徴とするＡ１から５のいずれかに記載の知財業務支援装置。

Ａ７．クライアント端末から前記案件スペースへの記録対象となるデータが受信されたとき、前記データからそのデータが対象とする知財業務案件の内容を示す属性情報を抽出する属性抽出部と、を更に備え、
前記認証部は、前記データの属性情報と前記知財業務案件の属性情報を比較して前記データが前記知財業務案件に対応したデータであるかを判定し、前記知財業務案件に対応したデータであることを条件として、前記データの前記案件スペースへの記録を許可することを特徴とするＡ１から６のいずれかに記載の知財業務支援装置。

Ａ８．前記案件スペース生成部は、所定のタイミングで前記案件スペースに含まれるデータを前記案件スペースとは異なる記憶領域に複写することを特徴とするＡ１から７のいずれかに記載の知財業務支援装置。

知財業務システムのハードウェア構成図である。 知財業務システムによる業務支援内容を説明するための概念図である。 知財業務支援装置の機能ブロック図である。 案件データ保持部のデータ構造図である。 案件発注画面の画面図である。 関係者設定画面の画面図である。 案件一覧画面の画面図である。 通信画面の画面図である。 スケジュール保持部に保持されるスケジュールデータのデータ構造図である。 進捗データ保持部の進捗データのデータ構造図である。 進捗表示画面の一例を示す図である。 進捗表示画面の別例を示す図である。 共同作業における実行権管理を説明するためのタイムチャートである。 ユーザから案件スペースにデータがアップロードされるときの処理過程を示すフローチャートである。

符号の説明

１０ 知財業務システム、 １００ 知財業務支援装置、 １１０ ユーザインタフェース処理部、 １２０ 通信部、 １２２ クライアント端末通信部、 １２４ 関連データ通信部、 １２６ データ通信部、 １２８ 設定通信部、 １３０ 通知部、 １３２ ユーザコミュニケーション処理部、 １３４ ページ送信部、 １３６ コンテンツ通信部、 １４０ 発注受信部、 １４２ 属性受信部、 １４４ 関係者指定受信部、 １４６ アクセス通知部、 １４８ 予定通知部、 １５０ データ処理部、 １５２ スケジュール管理部、 １５４ 案件スペース生成部、 １５６ 認証処理部、 １５８ 関連データ処理部、 １６０ 文献検索部、 １６２ スケジュール生成部、 １６４ 進捗データ更新部、 １６６ 実行権管理部、 １６８ バックアップ処理部、 １７０ ユーザ認証部、 １７２ データ認証部、 １７４ 単語抽出部、 １７６ 検索部、 １８０ データ保持部、 １８２ ユーザ情報保持部、 １８４ 画像保持部、 １８６ 案件データ保持領域、 １８８ 案件データ保持部、 ２００ 特許庁、 ２１０ 属性情報保持部、 ２１２ 発明資料保持部、 ２１４ 先行文献保持部、 ２１６ 出願原稿保持部、 ２１８ 関係者情報保持部、 ２２０ オフィシャルデータ保持部、 ２２２ スケジュール保持部、 ２２４ 進捗データ保持部、 ２２６ 通信領域、 ２２８ 限定通信領域、 ２３０ 案件発注画面、 ２５０ 関係者設定画面 ２７０ 案件一覧画面、 ２９０ 通信画面 ３１０ 進捗表示画面。

Claims (8)

1. 知財関連業務に関し、業務委託側のユーザによって使用されるクライアント端末および業務受託側のユーザによって使用されるクライアント端末の双方と通信ネットワークを介して接続され、
   業務委託側のユーザが使用するクライアント端末から、知財業務案件の発注指示を示す発注指示データを受信する発注指示受信部と、
   前記発注指示データを受信したことを契機として、前記知財業務案件に関するデータを管理するための案件スペースを記録媒体上に生成する案件スペース生成部と、
   前記案件スペースに対するアクセス要求をクライアント端末から受信するアクセス要求受信部と、
   業務受託側のユーザを含めて前記知財業務案件の関係者となるユーザを指定する関係者指定データをクライアント端末から受信する関係者指示受信部と、
   前記関係者指定データに指定されたユーザと前記知財業務案件を対応づけた関係者情報を保持する関係者情報保持部と、
   前記アクセス要求を送信したクライアント端末のユーザが前記知財業務案件の関係者として指定されたユーザであるか前記関係者情報を参照して判定し、関係者として指定されたユーザであることを条件として前記案件スペースに対するアクセスを許可する認証部と、
   前記知財業務案件について関係者が実行すべき複数種類の作業について、各作業の作業予定日時を示すスケジュールデータを生成するスケジュール生成部と、
   前記スケジュールデータと比較した前記知財業務案件の進捗状況を示す進捗データを保持する進捗データ保持部と、
   前記案件スペースのデータに対するアクセスによって前記知財業務案件に関するいずれかの処理が完了したときに、前記進捗データを更新する進捗データ更新部と、
   を備えることを特徴とする知財業務支援装置。
2. 前記スケジュール生成部は、ユーザにより前記知財業務案件に関する所定作業について作業予定日時が設定されたときには、その作業予定日時を変数として所定関数により他の作業の作業予定日時を特定することを特徴とする請求項１に記載の知財業務支援装置。
3. 前記スケジュールデータを参照して、前記知財業務案件に関する所定作業の作業予定日時から所定期間内に至ると、前記所定作業の実行責任者となるユーザに対してその旨を通知する予定通知部、を更に備えることを特徴とする請求項１または２に記載の知財業務支援装置。
4. 前記知財業務案件についての作業のうち複数のユーザが共同で実行する共同作業について、実行責任者を特定するための実行権を管理する実行権管理部、を更に備え、
   前記認証部は、前記共同作業中においては、前記実行権を取得したユーザからのアクセス要求であることを条件としてアクセスを許可し、
   前記実行権管理部は、前記複数のユーザのいずれかに実行権を設定し、前記実行権を設定されたユーザによるアクセスが完了したときに前記実行権を別のユーザに設定可能とすることを特徴とする請求項１から３のいずれかに記載の知財業務支援装置。
5. 前記実行権管理部は、前記共同作業中においては、前記実行権を取得したユーザを特定するための情報を他のユーザに通知することを特徴とする請求項４に記載の知財業務支援装置。
6. 前記知財業務案件の関連データを保持する所定の外部装置から前記関連データを受信して、前記案件スペースに記録する関連データ処理部、を更に備えることを特徴とする請求項１から５のいずれかに記載の知財業務支援装置。
7. 前記関連データは、官公庁がダウンロード可能に公開する前記知財業務案件の処理の経過情報を示すデータであって、
   前記関連データ処理部は、所定のタイミングで前記知財業務案件に対応した経過情報を示すデータを取得し、前記案件スペースに記録することを特徴とする請求項６に記載の知財業務支援装置。
8. 調査対象となるユーザが関係者として登録されている知財業務案件と前記知財業務案件の現時点における実行責任者とを対応づけたタスク管理情報を生成するタスク管理部を更に備え、
   前記タスク管理部は、前記調査対象となるユーザに対して前記タスク管理情報を送信することを特徴とする請求項１から７のいずれかに記載の知財業務支援装置。

Images