JP6469349B2

JP6469349B2 - 出願支援システム、出願用ファイル作成支援サーバおよび出願用ファイル作成支援プログラム

Info

Publication number: JP6469349B2
Application number: JP2014027078A
Authority: JP
Inventors: 司太田
Original assignee: Individual
Current assignee: Individual
Priority date: 2013-02-18
Filing date: 2014-02-16
Publication date: 2019-02-13
Anticipated expiration: 2034-02-16
Also published as: JP2014179068A

Description

本発明は、論文などの技術情報ファイルから簡易に特許出願書類を作成するための出願支援システムに関する。

大学等の研究機関では、その研究成果の社会還元の伝統的な手法として学会や論文による公表を行っており、また、これと同時に、特許出願による社会還元という手法も利用している。特に、大学の法人化後においては、産学連携のより一層の推進が求められ、特許をそのツールとして利用することが行われている。

論文と特許出願書類（明細書）とを比較した場合、その性格上大きく異なる点もあるが、技術を公開することを目的とした技術文献である点では共通するものであり、論文の記載を流用・利用して特許出願書類を作成することは十分可能であると考えられる（ただし、一般的に、単に論文の記載を流用するのみでは適正な権利範囲の特許を取得するのは難しいことが予想される）。このようなものに関連して、論文から特許出願書類を自動生成することに関する従来技術が特許文献１に記載されている。

特開２００２−２０７７２０

上記のごとく、特許出願を積極的に行おうとしている大学等も存在するが、このような機関の研究者の中には、論文による公表を特許出願より優先して考える研究者もまだ相当数存在している。先に論文を書いた後で、発明届等の学内処理を申請する者も多いため、論文公開までの猶予期間が短いと、特許出願書類の準備が間に合わず、公開後の出願となってしまうことも生じている。このように公開後の出願となると、新規性喪失の例外に関する規定を備えない（若しくは適用事由が限定的な）国に対しては特許を取得することができなくなるため、折角の有用な技術であってもこれをグローバルに権利化することができず、その価値を著しく低下させてしまうこととなる。これは当該機関の損失でもあると同時に国の対外的な産業競争力の損失でもあるとも言える。

このような問題を解決する唯一の完全な対策は、公知となる前に特許出願を行うことであり、これを実現するために研究者への啓蒙を徹底するのが理想的ではあるが、非常に多忙な研究者の理解を得た上でなお且つ「発明届の作成〜出願手続き」の一連の作業への協力を常に要請することは困難というべきである（現状、ゆっくりとその方向へと向かっていると言えるが、早急に大きく改善することは困難である）。従って、次善の策としては、特許出願書類としての完全性を少し犠牲にしても、公知となってしまうことを避けるために緊急退避的な出願（最低限、発表する内容を網羅したもの）を行うことが考えられるが、この場合において重要なことは、可及的に簡便な手続きで且つ迅速にこれが行えることである。特許出願書類の作成に手間がかかることを一つの要因として上記の問題が生じているものであるから、緊急退避的出願において最も重要な点は、極めて簡便且つ迅速な処理が可能なことである（特に、研究者（発明者）にとって手間がかからないものであることが必要）。

緊急退避的出願を簡便且つ迅速に行うためには、論文などの技術情報文献に基づいて特許出願書類を自動生成するシステムが有効であると考えられる。特許文献１に開示される技術はこのような趣旨に合致し得るものである。しかし、特許文献１に開示される技術は、論文等の中の所定の項目を判別して、これに対応する出願書類の項目に記載を転用して特許出願書類を作成するもの（例えば「学術論文の「考察」もしくは「緒言」に関する記載に基づいて特許明細書の「特許請求の範囲」の欄及び「課題を解決するための手段」の欄を作成する」など）であり、ある程度決まった形式の技術文献（論文）でなければ対応できないものであった。また、書類の作成にあたり、ある程度の作業を要求されているものである。（「「発明の実施の形態」をクリックすると、」などとされており、出願書類の形式に関する知識がある程度ないと、使い難いものとなるおそれがある。）

本発明は、上述した点に鑑み、論文などの技術情報ファイルを有する発明者にとって簡便な手続きで利用可能な、出願用ファイルの作成を支援するシステム等を提供することを目的とする。また、知財部などの管理者側にとって出願ソフトの利用等がスムーズに行えるようにする出願用ファイル作成支援システム等を提供することを目的とし、広範な種類の技術情報ファイルに対応可能な出願用ファイル作成支援システム等を提供することを目的とする。さらに、大学等に対して、緊急退避的出願の代理サービスを提供するためのシステム等を提供することを目的とする。（これら全ての目的が達成できなければならないという訳では必ずしもなく、何れかの目的を達することができれば、有用なものとなり得る。）

本発明に係る出願支援システムは、出願用ファイル作成支援サーバと、管理者端末装置と、発明者端末装置と、ネットワークと、によって構成される出願支援システムであって、前記出願用ファイル作成支援サーバは、前記管理者端末装置及び前記発明者端末装置と前記ネットワークを介して通信可能に接続され、前記出願用ファイル作成支援サーバは、前記発明者端末装置から前記ネットワークを介して技術情報ファイル及び発明者情報を取得する技術情報ファイル取得部と、当該取得した発明者情報と予め設定された出願人情報を使用して願書を自動生成する願書生成部と、前記取得した技術情報ファイルを各ページごとに画像ファイルへ変換し、当該各画像ファイルを自動生成した各段落番号に貼り付けることで明細書を自動生成する明細書自動生成部と、前記生成された願書と明細書とを用いて電子出願ソフトが受け付ける形式の所定形式出願ファイルを自動生成し、前記管理者端末装置がアクセス可能な記憶領域に当該所定形式出願ファイルを格納する出願ファイル生成部と、を備えることを特徴とする。

上記構成によれば、発明者は発明者端末装置を利用して技術情報ファイル（例えば論文の電子データ）をアップロードするだけで、システムで自動的に出願用のファイルを生成し、所定の領域にこれが格納されることとなる。また、出願処理を行う担当者（例えば知財部職員）にとっても所定領域に自動格納されているファイルを電子出願ソフトを利用して出願手続するだけで済む。従って、発明者及び出願事務担当者の双方にとって簡便な手続で、出願を行うことが可能となる。また、上記構成によれば、技術情報ファイルを各ページごとに画像ファイルへ変換し、当該各画像ファイルを自動生成した各段落番号に貼り付けることで明細書を自動生成する構成としているため、様々な形式のファイルに対して、画一的な処理で明細書の自動生成処理が実行可能となるため、汎用性が高い。

本発明に係る第１の出願用ファイル作成支援サーバは、特許出願又は実用新案登録出願のための出願書類の作成を支援する出願用ファイル作成支援サーバであって、装置全体の制御を行う制御部と、記憶部と、通信部と、ファイル画像化部と、前記通信部によってネットワークを介して技術情報ファイル及び発明者情報を取得しこれを対応付けて前記記憶部又は外部記憶装置に記憶させる技術情報ファイル取得部と、当該発明者情報を使用して願書を自動生成する願書生成部と、前記技術情報ファイルを前記ファイル画像化部によって画像ファイルへ変換し、当該各画像ファイルを段落番号に貼り付けることで明細書を自動生成する明細書自動生成部と、前記生成された願書と明細書とを用いて電子出願ソフトが受け付ける形式の所定形式出願ファイルを自動生成する出願ファイル生成部と、予め設定された前記記億部の記憶領域に前記所定形式出願ファイルを格納する又は予め設定された外部装置の記憶領域に前記所定形式出願ファイルを格納するために前記通信部から情報を送出するファイル格納処理部と、を備えることを特徴とする。

本発明に係る第２の出願用ファイル作成支援サーバは、第１の出願用ファイル作成支援サーバにおいて、前記ファイル画像化部は、前記技術情報ファイルに対応するアプリケーションソフトの印刷機能を利用して印刷出力データを取得し、当該印刷出力データから前記画像ファイルへの変換を実行することを特徴とする。

上記構成によれば、各ファイル形式にそれぞれ対応付けられているアプリケーションソフト（例えば拡張子がdocであるファイルに対する、Microsoft Word（登録商標））を起動し、当該ソフトの印刷機能を利用して印刷出力データを取得し、これに基づいて画像ファイルへの変換処理が実行される。通常何れのアプリケーションソフトにも印刷機能は備えられており、プリンタ（若しくはプリンタドライバ）との互換のため、その出力データの形式は規格化されている。従って、これを利用することで、技術情報ファイル（論文等の電子ファイル）が様々な形式であっても、画一的な処理で明細書の自動生成処理が実行可能となるため、汎用性が高く、利用者にとっての利便性も高い。

本発明に係る第３の出願用ファイル作成支援サーバは、第１又は第２の出願用ファイル作成支援サーバにおいて、前記技術情報ファイル及び発明者情報の送信を当該ファイル所持者から受け付けるためのサイトを提示させる技術情報ファイル受付サイト提示部を備えることにより、当該サイトを介して前記技術情報ファイル及び発明者情報を取得することを特徴とする。

上記構成によれば、発明者の作業を、技術情報ファイル受付サイトにアクセスして、必要情報の入力及び技術情報ファイルをアップロードすることのみとすることが可能となる。

本発明に係る第４の出願用ファイル作成支援サーバは、第１乃至第３の何れかの出願用ファイル作成支援サーバにおいて、前記技術情報ファイル取得部による技術情報ファイル及び発明者情報の取得処理において出願予定日情報若しくは前記技術情報ファイルの公開予定日情報もあわせて取得し、前記ファイル格納処理部による格納処理において、当該出願予定日情報若しくは公開予定日情報から直接または間接的に導出される日時に対応する日別フォルダに前記所定形式出願ファイルを格納する、日別フォルダ格納処理部を備える、又は、前記記億領域への前記所定形式出願ファイルの格納処理において前記出願予定日情報若しくは前記公開予定日情報を対応付けて保存し、日時機能部を備えることにより、前記出願予定日情報若しくは前記公開予定日情報から直接または間接的に導出される日時が当日に該当する前記所定形式出願ファイルが存在する場合に当該所定形式出願ファイルを所定フォルダへ移動させる、当日ファイル移動処理部を備えることを特徴とする。

上記構成によれば、所定形式出願ファイルが出願予定日に対応した各フォルダに格納される、又は、出願予定日となった所定形式出願ファイルが所定のフォルダ（例えば“本日出願予定フォルダ”）に移動格納されることとなる。「出願予定日情報若しくは公開予定日情報から直接または間接的に導出される日時」とは、出願予定日（若しくは出願予定日時）のことであり、出願予定日情報を取得している場合には、当該情報から直接得られる日（若しくは日時）をいい、公開予定日情報を取得している場合には、当該公開日から所定条件によって導出される日（若しくは日時）（例えば、公開予定日の1日前を出願日とする等）をいう。これにより、出願事務担当者は、出願予定日に対応した各フォルダに格納される場合には、当日に該当するフォルダを選択して当該フォルダの中のファイルに基づいて出願処理をすることで期限に応じた案件の出願処理を実行できる。一方、所定のフォルダへ当日の該当ファイルが移動される場合には、いつも同じフォルダ（所定フォルダ）の中のファイルに基づいて出願処理をすることで期限に応じた案件の出願処理を実行できる。

本発明に係る第５の出願用ファイル作成支援サーバは、第４の出願用ファイル作成支援サーバにおいて、本出願用ファイル作成支援サーバによって自動生成された出願であることを示す情報を含んだ整理番号情報を自動生成する整理番号自動生成部と、日時機能部と、を備え、前記願書生成部による願書生成処理において当該整理番号を使用して願書の自動生成を行い、前記日時機能部によって得られる日付が、前記出願予定日情報若しくは公開予定日情報から直接または間接的に導出される日時に至った若しくは経過した際に、当該出願予定日情報若しくは公開予定日情報から直接または間接的に導出される日時に対応する前記所定形式出願ファイルの前記整理番号情報を取得し、当該整理番号情報に基づいて、電子出願ソフトの出願処理によって得られる受理済みファイルが格納されるフォルダを検索して当該整理番号に対応する受理済みファイルが無かった場合、又は、電子出願ソフトから出力される一覧出力ファイルを検索して当該整理番号に対応する出願予定日情報若しくは出願番号情報が無かった場合には、予め設定されている管理者情報に基づいて管理者へ警告情報を発信する受理済みファイル確認部を備えることを特徴とする。

上記構成によれば、各案件に整理番号が自動生成して付与され、当該整理番号に基づいて、電子出願ソフトの出願処理によって得られる受理済みファイルの有無、又は、電子出願ソフトから出力される一覧出力ファイル（案件のリスト）に出願済みであることを示す情報があるか否かがシステムによって自動検索され、これらが無いと判断された場合には管理者へ警告情報が発信される。これにより、出願予定日に各案件の出願処理がなされたか否かについてシステムで自動的にチェックし、出願処理がなされたと判断できる情報がなかった場合には管理者（例えば、出願事務担当者）に警告が発せられるため、手続漏れを抑止することが可能となる。

本発明に係る第６の出願用ファイル作成支援サーバは、第１乃至第５の何れかの出願用ファイル作成支援サーバにおいて、前記発明者情報に基づいて発明者が従業者であるか否かを判別する従業者判別部と、管理者からの情報を受け付ける管理者サイトを提示させる管理者サイト提示部を備えることにより、前記従業者判別部によって従業者で無い発明者が含まれていると判断された場合には、前記管理者サイトにおいて該当する技術情報ファイルに関する情報及び前記発明者情報を表示させ、これに対する管理者からの承認情報の入力があった場合に前記所定形式出願ファイルの自動生成処理の実行を許可することを特徴とする。

上記構成によれば、従業者でない発明者（雇用関係にない者）が含まれている場合には、システムでの自動処理について、管理者の承認情報の入力を要件とすることとなる。雇用関係にない者の持分（特許を受ける権利）については、予約承継はできず、よって本システムを有する機関が勝手に単独で出願することはできないため、管理者（例えば、出願事務担当者）による相手機関等への確認を経て承認が得られたことを確認して出願ファイルの自動生成処理の実行をさせるものである。これにより冒認出願の発生を抑止することができる。

本発明に係る第７の出願用ファイル作成支援サーバは、第４又は第５の出願用ファイル作成支援サーバにおいて、日時機能部と、当該日時機能部によって得られる日付と前記出願予定日情報若しくは公開予定日情報から直接または間接的に導出される日時とを比較し、これが予め設定されている期間より短いか否かを判別し、短い場合に前記所定形式出願ファイルの自動生成処理の実行を許可する猶予期間判別部と、を備えることを特徴とする。

上記構成によれば、出願予定日までの期間が所定の期間（例えば、1ヶ月）より長い場合には、所定形式出願ファイルの自動生成処理が実行されないこととなる。本システムを論文等による公知化を緊急的に退避する出願としてのみ利用すると位置づける場合等においては、例えば、猶予期間が１月以上あるような場合には本システムで出願するのではなく、通常の出願処理（出願可否の判断や、人手による出願書類の作成）を行うべきとして、本システムによる自動生成処理が実行させないものである。

本発明に係る第８の出願用ファイル作成支援サーバは、第１乃至第７の何れかの出願用ファイル作成支援サーバにおいて、前記技術情報ファイル受付サイト提示部によって、前記技術情報ファイルがカラーであることを要するか否かの入力を求めるサイトを提示させ、前記技術情報ファイルがカラー必須である場合には、前記願書の自動生成において外国語書面として生成し、前記明細書の自動生成処理に替えて、前記技術情報ファイルがPDFファイルでなかった場合にはこれをPDFファイルに変換し「外国語書面」の項目名に対してこれを張り付ける処理を、実行することを特徴とする。

上記構成によれば、技術情報ファイルがカラー必須であるとされた場合には、外国語書面として出願ファイルが自動生成される。技術情報ファイル（論文等の電子ファイル）がカラーで作成されている場合においては、これをグレースケールとされてしまうと重要な情報の欠落が生じるような場合もあり得る。日本国の特許電子出願では2012年現在においてカラーの画像の添付が認められておらず、これに従い機械的にグレースケール化したのでは、前記のごとく重要な情報の欠落が生じ得るため、「論文等の公表による公知化を防止する」という当初の目的を満足できないおそれがある。これについて、外国語書面出願においては、カラーのＰＤＦファイルを添付することが可能であるため、外国語書面として出願をすることで、情報の欠落を抑止させるものである。

本発明に係る第９の出願用ファイル作成支援サーバは、第３乃至第８の何れかの出願用ファイル作成支援サーバにおいて、前記技術情報ファイル受付サイト提示部によって、前記技術情報ファイルに関する技術分野情報及びキーワード情報の入力を求めるサイトを提示させることにより、当該サイトを介して技術分野情報及びキーワード情報を取得し、前記技術情報ファイルに当該技術分野情報及びキーワード情報を対応付けて前記記憶部若しくは予め設定された外部装置の記憶領域に格納することを特徴とする。

上記構成によれば、技術情報ファイルに関する技術分野情報やキーワード情報が対応付けられて蓄積されていくこととなる。これにより、自己の機関内の発明者の論文等の技術情報ファイルについてのＤＢ化が同時にできることとなる。

本発明に係る第１０の出願用ファイル作成支援サーバは、第４乃至第９の何れかの出願用ファイル作成支援サーバにおいて、日時機能部と、当該日時機能部によって得られる日付と、出願日とを比較し、これが予め設定されている期間を超えたか否かを判別し、超えた場合には予め設定されている管理者情報に基づいて管理者へ所定期間経過情報を発信する期間経過確認部と、前記所定期間が経過した出願についての出願取下書を自動生成する出願取下書生成部と、を備えることを特徴とする。

上記構成によれば、所定期間が経過した案件について、取下げに関する通知と、出願取下書の自動生成処理が行われる。本システムは、論文等を機械的にコピーして出願するだけの緊急退避的な意味合いが強いものであり、後の優先権主張出願を前提としている側面があるため（本システムによる出願について補正による対応等で出願を係属させる場合を否定するものではない）、緊急退避的に出願はしたが、結局当該発明について権利化の手続を続行させない場合も多いことも考えられ、そのような出願について手続を維持するのはコスト面などから得策ではないため、管理者への通知等を行うものである。

本発明に係る第１１の出願用ファイル作成支援サーバは、特許出願又は実用新案登録出願のための出願書類の作成を支援する出願用ファイル作成支援サーバであって、装置全体の制御を行う制御部と、顧客ログイン情報と出願人情報が対応付けられて格納されている記憶部と、通信部と、ファイル画像化部と、ログイン処理を行うログイン処理部と、前記通信部によってネットワークを介して技術情報ファイル及び発明者情報を取得しこれを対応付けて前記記憶部又は外部記憶装置に記憶させる技術情報ファイル取得部と、当該発明者情報とログインによって特定される出願人情報とを使用して願書を自動生成する願書生成部と、前記技術情報ファイルを前記ファイル画像化部によって各ページごとに画像ファイルへ変換し、当該各画像ファイルを自動生成した各段落番号に貼り付けることで明細書を自動生成する明細書自動生成部と、前記生成された願書と明細書とを用いて電子出願ソフトが受け付ける形式の所定形式出願ファイルを自動生成する出願ファイル生成部と、を備えることを特徴とする。

上記構成によれば、様々な形式のファイルに対して、画一的な処理で明細書の自動生成処理が実行可能とさせるシステムにより、技術情報ファイルに基づいた所定形式出願ファイルの自動生成サービスを、各顧客に対して提供することができる。

本発明に係る第１２の出願用ファイル作成支援サーバは、第１１の出願用ファイル作成支援サーバであって、前記記憶部に代理人ログイン情報が格納されており、当該代理人からのログインがあった場合に前記技術情報ファイル又は前記所定形式出願ファイル又は前記電子ソフトから取得される出願ファイルを提示させる技術情報ファイル等提示部と、これに対応するクレーム案の入力を前記代理人に求め、これにより得られたクレーム案情報を取得するクレーム案取得部と、当該技術情報等の送信をした顧客に対して当該クレーム案を提示するクレーム案提示部と、を備えることを特徴とする。

上記構成によれば、顧客から得られた技術情報ファイル等を、代理人側に提示し、当該技術情報ファイル等の内容に応じたクレーム案の入力を受付け、得られたクレーム案を顧客（技術情報ファイルの送信主）に提示する処理がシステムによって行われる。これにより、本サービスの提供を受ける顧客は、技術情報ファイルの内容に基づき代理人によって作成されたクレーム案を確認することができる。

本発明に係る第１３の出願用ファイル作成支援サーバは、第１２の出願用ファイル作成支援サーバであって、前記顧客に対してクレーム案を提示した際に、当該クレーム案に対する評価情報の入力を求め、これにより得られた評価情報を、当該クレーム案を入力した代理人のＩＤと対応付けて前記記憶部又は外部記憶装置に格納し、顧客からの要求又は代理人からの要求に応じて、当該評価情報を提示させる代理人評価情報取得・提示部を備えることを特徴とする

上記構成によれば、技術情報ファイルの内容に基づき代理人によって作成されたクレーム案に対して、その評価情報が当該代理人に対応付けられて記憶され、顧客からの要求又は代理人からの要求に応じて、当該評価情報が提示されることになるため、実際のクレーム案を見た上でそのクレーム作成能力を評価した情報を提示するサービスを提供することができる。

本発明に係る第１４の出願用ファイル作成支援サーバは、第１３の出願用ファイル作成支援サーバであって、前記代理人評価情報取得・提示部が、代理人に対して出願の依頼を行った顧客に対し、当該出願依頼先である代理人に関する評価情報の入力を求め、これにより得られた評価情報を、当該代理人のＩＤと対応付けて前記記憶部又は外部記憶装置に格納し、顧客からの要求又は代理人からの要求に応じて、当該評価情報を提示させる処理をさらに行うことを特徴とする。

上記構成によれば、出願依頼を行った顧客から、当該依頼先である代理人に関し、実際の依頼結果に基づいた評価情報を取得することができ、当該評価情報を提示するサービスを提供することができる。

本発明に係る第１５の出願用ファイル作成支援サーバは、第１２乃至第１４の何れか一つの出願用ファイル作成支援サーバであって、前記顧客に対してクレーム案を提示した際に、当該クレーム案を入力した代理人に対する出願依頼入力手段を提示し、これに対する入力があった場合に当該代理人に対して出願依頼があったことを提示する出願依頼受付・通知処理部と、当該出願依頼情報の提供を行った際に、当該代理人に対する課金処理を行う課金処理部と、を備えることを特徴とする

上記構成によれば、代理人により作成されたクレーム案の提供サービスに基づいて、当該代理人に対して仕事の依頼が発生した場合に、当該代理人に対しての課金処理が行われるため、実際の仕事の依頼があった場合にのみ課金がなされるサービスの提供をすることができる。

本発明に係る第１の代理人評価・紹介サービス支援サーバは、装置全体の制御を行う制御部と、依頼者ログイン情報と代理人ログイン情報が格納されている記憶部と、通信部と、ログイン処理を行うログイン処理部と、ログインをしている依頼者から、前記通信部によってネットワークを介して依頼情報を取得し、これをログインによって特定される依頼者情報に対応付けて前記記憶部又は外部記憶装置に記憶させる依頼情報取得部と、代理人からのログインがあった場合に当該代理人に対して前記依頼情報を提示させる依頼情報提示部と、これに対する対応情報の入力を前記代理人に求め、これにより得られた対応情報を取得する対応情報取得部と、当該依頼情報の送信をした顧客に対して当該対応情報を提示する対応情報提示部と、を備えることを特徴とする。

上記構成によれば、依頼者から得られた依頼情報を、代理人側に提示し、依頼情報の内容に応じた対応情報（依頼内容に対するアドバイスや解決法の示唆、対応方針の示唆など）の入力を受付け、得られた対応情報を依頼者に提示する処理がシステムによって行われる。これにより、本サービスの提供を受ける依頼者は、依頼情報の内容に基づき代理人によって作成された対応情報を確認することができる。

本発明に係る第２の代理人評価・紹介サービス支援サーバは、第１の代理人評価・紹介サービス支援サーバであって、前記記憶部に、代理人ＩＤ情報と、当該代理人の対応可能条件情報又は／及び対応不能情報とが対応付けて格納されており、依頼者から前記対応可能条件情報又は／及び対応不能情報に対応する対応条件情報を前記ネットワークを介して取得する対応条件情報取得部を備えることにより、前記代理人への依頼情報の提示の際に、前記依頼人から取得した対応条件情報と前記対応可能条件情報又は／及び対応不能情報とを対比して、適合する代理人に対して依頼情報の提示を行うことを特徴とする。

代理業サービスは、一般的に専門性の高いものが多く、従って、それぞれが専門として対応できる分野には一定の範囲があるのが通常である。また、既存のクライアントとの関係で新たに代理を受けることができない顧客に該当するような場合もある。このような状況に対して、上記構成によれば、代理人ＩＤと対応可能条件情報（例えば、自己の専門分野情報や、業種、納期、金額など様々なものが考え得る）又は／及び対応不能情報（同様に分野情報や、業種、納期、金額、対応できない具体的企業名など様々なものが考え得る）とが対応付けて記憶されており、依頼時に対応条件情報（同じく分野情報や、業種、納期、金額、具体的企業名など様々なものが考え得る）を取得して、これらに基づいて、適合する代理人に対して依頼情報の提示がなされるため、効率的なサービスを提供することができる。また、不必要に依頼情報が提示されることが抑制されるため、秘密保持の観点からも優れる。

本発明に係る第３の代理人評価・紹介サービス支援サーバは、第１又は第２の代理人評価・紹介サービス支援サーバであって、前記依頼情報の取得において、依頼情報を提示させる代理人の指定を受け付ける代理人指定情報取得部を備え、前記代理人への依頼情報の提示の際に、前記指定された代理人に対して依頼情報の提示を行うことを特徴とする。

上記構成によれば、依頼者側で、依頼情報の提示をしたいと考える代理人（単数または複数）を指定することができる。

本発明に係る第４の代理人評価・紹介サービス支援サーバは、第１乃至第３の何れか一つの代理人評価・紹介サービス支援サーバであって、前記顧客に対して対応情報を提示した際に、当該対応情報に対する評価情報の入力を求め、これにより得られた評価情報を、当該対応情報を入力した代理人のＩＤと対応付けて前記記憶部又は外部記憶装置に格納し、顧客からの要求又は代理人からの要求に応じて、当該評価情報を提示させる代理人評価情報取得・提示部を備えることを特徴とする。

上記構成によれば、依頼情報の内容に基づき代理人によって作成された対応情報に対する評価情報が当該代理人に対応付けられて記憶され、依頼者からの要求又は代理人からの要求に応じて、当該評価情報が提示されることになるため、実際の対応情報（即ち代理人の提供したサービスの質）を見た上でその能力を評価した情報を提示するサービスを提供することができる。

本発明に係る第５の代理人評価・紹介サービス支援サーバは、第４の代理人評価・紹介サービス支援サーバであって、前記記憶部に、依頼者ＩＤ情報と、当該依頼者の属性情報とが対応付けて格納されており、前記評価情報の格納において、評価情報を入力した依頼者のＩＤ情報又は前記属性情報を前記評価情報に対応付けて格納することを特徴とする。

第４の代理人評価・紹介サービス支援サーバによれば、代理人のサービスに対する依頼者による評価がなされ、これが提示されるものであるが、依頼者の属性（例えば職種の相違）によってその評価の仕方の傾向が変わる事もあり得る。評価情報を利用する側としてはそのような点も考慮して情報を見ることができればより参考になる場合もある。これに対し、第５の代理人評価・紹介サービス支援サーバによれば、評価情報と依頼者の属性情報とが対応付けて記憶されるため、評価情報の提示の際に依頼者（＝評価者）の属性情報に応じた表示をさせることが可能となるものである。

本発明に係る第６の代理人評価・紹介サービス支援サーバは、第４又は第５の代理人評価・紹介サービス支援サーバであって、前記評価情報の提示において、評価情報が所定数に至るまで又は所定期間が経過するまで、前記取得した評価情報を提示対象にしないことを特徴とする。

評価情報が直ぐに反映（提示）される場合、評価された代理人に、誰かその評価情報を入力したか直ぐに察しがついてしまうことがあり得る（このシステムの利用がまだ一人しかない場合には、当然にその人物が評価したとわかる）。評価情報を入力する依頼者としては、自分が悪い評価をしたことが代理人側にわかってしまうのは避けたいと思う場合もあり得る。これに対し、上記構成によれば、評価情報が所定数に至るまで又は所定期間が経過するまでは、評価情報を提示対象にしないため、評価された代理人に、誰かその評価情報を入力したか直ぐに察しがついてしまうことが抑止される。

本発明に係る第７の代理人評価・紹介サービス支援サーバは、第６の代理人評価・紹介サービス支援サーバであって、前記所定数又は前記所定期間を依頼者に設定させることを特徴とする。

上記構成によれば、「評価情報が所定数に至るまで又は所定期間が経過するまでは、評価情報を提示対象にしない」における所定数又は所定期間を評価者が設定することができる。即ち、例えば所定数を100と設定すれば評価情報が100溜まった後に自己がした評価情報が提示対象となり、0と設定すれば直ぐに提示対象となる（自己のした評価情報の公開のタイミングをコントロールできる）、といったことが可能となる。

本発明に係る第８の代理人評価・紹介サービス支援サーバは、第４乃至第７の何れか一つの代理人評価・紹介サービス支援サーバであって、前記記憶部に、依頼者ＩＤ情報と、当該依頼者が登録した属性情報とが対応付けて格納されており、前記評価情報の入力があった場合に、当該評価情報を入力した依頼者ＩＤと、前記属性情報の登録数に応じた特定サービス情報とを対応付けて記憶することを特徴とする。

上記構成によれば、より多くの属性情報を登録した上で評価情報を入力した依頼者に対して、より多くの特定サービス情報（例えばポイントやキャッシュバック情報など）を対応付けるといったことが可能となる。即ち、本システムの価値を高めるためには評価情報の豊富化（＝ＤＢとしての価値向上）が不可欠であるため、より情報の豊富化をしてくれた依頼者に対してより優遇したサービスを提供することにより、ＤＢの価値向上につながる行動へのインセンティブを与えるものである。

本発明に係る第９の代理人評価・紹介サービス支援サーバは、第１乃至第８の何れか一つの代理人評価・紹介サービス支援サーバであって、前記顧客に対して対応情報を提示した際に、当該対応情報を入力した代理人に対する依頼入力手段を提示し、これに対する依頼入力があった場合に当該代理人に対して依頼があったことを提示する依頼受付・通知処理部と、当該依頼の提示を行った際に、当該代理人に対する課金処理を行う課金処理部と、を備えることを特徴とする。

上記構成によれば、本システムの利用に基づいて、代理人に対して仕事の依頼が発生した場合に、当該代理人に対しての課金処理が行われるため、実際の仕事の依頼があった場合にのみ課金がなされるサービスの提供をすることができる。

本発明に係る第１０の代理人評価・紹介サービス支援サーバは、第９の代理人評価・紹介サービス支援サーバであって、前記依頼があった場合に該当する代理人ＩＤに前記依頼情報及び／又は依頼者情報を対応付けて実績情報として記憶し、依頼者から対応条件情報を前記ネットワークを介して取得する対応条件情報取得部を備えることにより、前記代理人への依頼情報の提示の際に、前記依頼人から取得した対応条件情報と前記実績情報とを対比して、適合しない代理人に対しては依頼情報の提示を行わないことを特徴とする。

前述のごとく、代理業サービスは専門性が高く担当できる分野に限度があること、又、コンフリクトやその他の理由により受任できない場合もあり得るものである。これに対し、上記構成によれば、依頼時に対応条件情報（分野情報や、業種、納期、金額、具体的企業名など様々なものが考え得る）を取得して、これと本システムにおける実績情報とを対比して、これに基づいて、適合する代理人に対して依頼情報の提示がなされるため、効率的なサービスを提供することができる。また、不必要に依頼情報が提示されることが抑制されるため、秘密保持の観点からも優れる。

本発明に係る第１の代理人評価・紹介サービス支援プログラムは、装置全体の制御を行う制御部と、演算部と、記憶部と、通信部と、を備える情報処理装置に、依頼者からのログイン要求に応じてログイン処理を行うステップと、前記通信部によってネットワークを介して依頼情報を取得し、これと依頼者情報とを対応付けて前記記憶部若しくは外部記憶装置に記憶させるステップと、代理人からのログインがあった場合に前記依頼情報を提示させるステップと、これに対する対応情報の入力を前記代理人に求め、これにより得られた対応情報を取得して代理人情報と対応付けて記憶するステップと、当該対応情報を送信した顧客に対して当該対応情報を提示するステップと、を実行させることを特徴とする。

本発明に係る第２の代理人評価・紹介サービス支援プログラムは、第１の代理人評価・紹介サービス支援プログラムであって、前記記憶部に、代理人ＩＤ情報と、当該代理人の対応可能条件情報又は／及び対応不能情報とが対応付けて格納されており、依頼者から前記対応可能条件情報又は／及び対応不能情報に対応する対応条件情報を前記ネットワークを介して取得するステップと、前記代理人への依頼情報の提示処理の際に、前記依頼人から取得した対応条件情報と前記対応可能条件情報又は／及び対応不能情報とを対比して、適合する代理人に対して依頼情報の提示するステップと、を実行させることを特徴とする。

本発明に係る第３の代理人評価・紹介サービス支援プログラムは、第１又は第２の代理人評価・紹介サービス支援プログラムであって、前記依頼情報の取得において、代理人の指定を受け付けるステップと、前記代理人への依頼情報の提示処理の際に、前記指定された代理人に対して依頼情報の提示を行うステップと、を実行させることを特徴とする。

本発明に係る第４の代理人評価・紹介サービス支援プログラムは、第１乃至第３の何れか一つの代理人評価・紹介サービス支援プログラムであって、前記顧客に対して対応情報を提示した際に、当該対応情報に対する評価情報の入力を求めるステップと、これにより得られた評価情報を、当該対応情報を入力した代理人のＩＤと対応付けて記憶するステップと、顧客からの要求又は代理人からの要求に応じて、当該評価情報を提示させるステップと、を実行させることを特徴とする。

本発明に係る第５の代理人評価・紹介サービス支援プログラムは、第４の代理人評価・紹介サービス支援プログラムであって、前記記憶部に、依頼者ＩＤ情報と、当該依頼者の属性情報とが対応付けて格納されており、前記評価情報の格納において、評価情報を入力した依頼者のＩＤ情報又は前記属性情報を前記評価情報に対応付けて格納するステップを実行させることを特徴とする。

本発明に係る第６の代理人評価・紹介サービス支援プログラムは、第４又は第５の代理人評価・紹介サービス支援プログラムであって、前記評価情報の提示において、評価情報が所定数に至るまで又は所定期間が経過するまで、前記取得した評価情報を提示対象にしないステップを実行させることを特徴とする。

本発明に係る第７の代理人評価・紹介サービス支援プログラムは、第６の代理人評価・紹介サービス支援プログラムであって、前記所定数又は前記所定期間を依頼者に設定させるステップを実行させることを特徴とする。

本発明に係る第８の代理人評価・紹介サービス支援プログラムは、第４乃至第７の何れか一つの代理人評価・紹介サービス支援プログラムであって、前記記憶部に、依頼者ＩＤ情報と、当該依頼者が登録した属性情報とが対応付けて格納されており、前記評価情報の入力があった場合に、当該評価情報を入力した依頼者ＩＤと、前記属性情報の登録数に応じた特定サービス情報とを対応付けて記憶するステップを実行させることを特徴とする。

本発明に係る第９の代理人評価・紹介サービス支援プログラムは、第１乃至第８の何れか一つの代理人評価・紹介サービス支援プログラムであって、前記顧客に対して対応情報を提示した際に、当該対応情報を入力した代理人に対する依頼入力手段を提示するステップと、これに対する依頼入力があった場合に当該代理人に対して依頼があったことを提示するステップと、当該依頼の提示を行った後に、当該代理人に対する課金処理を行うステップと、を実行させることを特徴とする。

本発明に係る第１０の代理人評価・紹介サービス支援プログラムは、第９の代理人評価・紹介サービス支援プログラムであって、前記依頼があった場合に該当する代理人ＩＤに前記依頼情報及び／又は依頼者情報を対応付けて実績情報として記憶するステップと、依頼者から対応条件情報を前記ネットワークを介して取得するステップと、前記代理人への依頼情報の提示の際に、前記依頼人から取得した対応条件情報と前記実績情報とを対比して、適合しない代理人に対しては依頼情報の提示を行わないステップと、を実行させることを特徴とする。

本発明に係る出願用ファイル作成支援サーバによれば、発明者及び出願事務担当者の双方にとって簡便な手続で、出願を行うことが可能となる。また、技術情報ファイルを各ページごとに画像ファイルへ変換し、当該各画像ファイルを自動生成した各段落番号に貼り付けることで明細書を自動生成する構成としているため、様々な形式のファイルに対して、画一的な処理で明細書の自動生成処理が実行可能となるため、汎用性が高い。

また、本発明に係る代理人評価・紹介サービス支援サーバによれば、代理人と依頼者とをマッチングさせるシステムとして、依頼者から得られた依頼情報に対して、複数の代理人から対応情報（依頼内容に対するアドバイスや解決法の示唆、対応方針の示唆など）を提供することができる。通常、専門性の高い代理業サービスを利用する場合に、その対応能力を比較して最も好ましい代理人を選択するということは難しいのが現状であるが、本発明によればこれが可能となる。加えて、実際の対応能力（対応情報）に対しての評価情報が蓄積されるようにすることができるため、当該評価情報を参考にして仕事を依頼する代理人を選定するサービスを提供することができる。

実施形態１に係る出願支援システムの概略を示すブロック図実施形態１に係る出願用ファイル作成支援サーバの概略を示すブロック図実施形態１に係る出願支援システムの全体動作の概略を示すフローチャート実施形態１に係る出願用ファイル作成支援サーバの全体動作の概略を示すフローチャート実施形態１に係る研究者ＰＣの処理動作（論文緊急出願の申請時動作）を示すフローチャート実施形態１に係る論文緊急出願のための申請の受付を行う際の出願用ファイル作成支援サーバの処理動作を示すフローチャート実施形態１に係るシステムにおいて、論文緊急出願のための申請の受付を行う際に、出願用ファイル作成支援サーバがＤＢに情報を登録する際の処理動作を示すフローチャート実施形態１に係るシステムにおいて、出願用のＨＴＭＬファイルを自動生成する処理動作の全体を示すフローチャート実施形態１に係るシステムにおいて、出願用ＨＴＭＬファイル自動生成保存処理における願書部を自動生成する処理を示すフローチャート実施形態１に係るシステムにおいて、出願用ＨＴＭＬファイル自動生成保存処理における、論文などのファイルをページごとに画像化する処理を示すフローチャート実施形態１に係るシステムにおいて、出願用ＨＴＭＬファイル自動生成保存処理における明細書部を自動生成する処理を示すフローチャート実施形態１に係るシステムにおいて、外国書面出願として出願用ＨＴＭＬファイルを自動生成する処理を示すフローチャート実施形態１に係るシステムにおける即時処理ファイル移動・通知処理を示すフローチャート実施形態１に係るシステムにおける当日ファイル移動・通知処理を示すフローチャート実施形態１に係るシステムにおける取下げ確認・通知処理を示すフローチャート実施形態１に係るシステムにおける手続終了確認処理の動作を示すフローチャート実施形態１に係るシステムにおける当日出願案件、手続終了確認処理の動作を示すフローチャート実施形態１に係るシステムにおける即時出願案件、手続終了確認処理の動作を示すフローチャート実施形態１に係るシステムにおける取下出願案件、手続終了確認処理の動作を示すフローチャート実施形態１に係るシステムにおける、管理者が本システムを利用して行う処理の全体を示すフローチャート実施形態１に係るシステムにおける、管理者用のトップ画面を生成する処理の動作を示すフローチャート実施形態１に係るシステムにおける、管理者承認処理の動作を示すフローチャート実施形態１に係るシステムにおいて、管理者承認処理時において実行される処理済案件登録処理を示すフローチャート実施形態１に係るシステムにおいて、管理者承認処理時において実行される出願用ＨＴＭＬファイル自動生成保存処理における願書部を自動生成する処理を示すフローチャート実施形態１に係る申請案件テーブルの構成の一例を示す図実施形態１に係る、（ａ）職員テーブル、（ｂ）職コードテーブル、（ｃ）職コードテーブルの構成の一例をそれぞれ示す図実施形態１に係る、（ａ）仮ユーザ登録テーブル、（ｂ）言語コードテーブル、（ｃ）分野コードテーブル、（ｄ）雇用コードテーブルの構成の一例をそれぞれ示す図実施形態１に係る管理者設定情報テーブルの構成の一例を示す図実施形態１に係る出願ファイル管理テーブルの構成の一例を示す図実施形態１に係る出願申請用ページの表示画面の構成の一例を示す図実施形態１に係る入力事項確認ページの構成の一例を示す図実施形態１に係る各警告ページの構成の一例を示す図実施形態１に係る管理者トップ画面の構成の一例を示す図実施形態１に係る出願情報入力画面の構成の一例を示す図実施形態１に係る取下情報入力画面の構成の一例を示す図実施形態１に係る承認処理画面の構成の一例を示す図実施形態１に係る承認処理個別画面の構成の一例を示す図実施形態１に係る管理者設定画面の構成の一例を示す図実施形態１に係る明細書ＨＴＭＬひな形ファイルを示す図実施形態１に係るシステムによって生成される出願用のＨＴＭＬファイルの一例を示す図実施形態１に係る外国語書面ＨＴＭＬひな形ファイルを示す図実施形態１に係るシステムによって生成される出願用の外国語書面ＨＴＭＬファイルの一例を示す図実施形態１に係る、（ａ）出願取下書ＨＴＭＬひな形ファイル示す図、（ｂ）システムによって生成される手続き用の出願取下書ＨＴＭＬファイルの一例を示す図実施形態１に係る外国語書面ＨＴＭＬひな形ファイル（図４６の処理で使用する明細書部のひな形ファイル）を示す図実施形態１に係るシステムによって生成される外国語書面ＨＴＭＬファイル（図４６の処理によって自動生成されるファイル）の一例を示す図実施形態１に係るシステムにおいて、外国書面出願として出願用ＨＴＭＬファイルを自動生成する別の処理を示すフローチャート実施形態２に係る出願支援システムの概略を示すブロック図実施形態２に係る出願用ファイル作成支援サーバの全体動作の概略を示すフローチャート実施形態２に係るシステムにおける顧客対応サイト処理の動作を示すフローチャート実施形態２に係る論文緊急出願の依頼の受付を行う処理動作を示すフローチャート実施形態２に係るシステムにおいて、出願用のＨＴＭＬファイルを自動生成する処理動作の全体を示すフローチャート実施形態２に係るシステムにおける個別案件詳細情報登録処理の動作を示すフローチャート実施形態２に係る未出願案件情報修正処理の処理動作を示すフローチャート実施形態２に係るクレーム案表示処理の処理動作を示すフローチャート実施形態２に係るシステムにおける事務所対応サイト処理の動作を示すフローチャート実施形態２に係るシステムにおける当日案件出願処理の動作を示すフローチャート実施形態２に係るシステムにおける取下げ処理の動作を示すフローチャート実施形態２に係るシステムにおける手続き終了通知処理の動作を示すフローチャート実施形態２に係る、（ａ）顧客テーブル、（ｂ）事務所テーブル、（ｃ）弁理士テーブル、の構成の一例をそれぞれ示す図実施形態２に係る申請案件テーブルの構成の一例を示す図実施形態２に係る出願ファイル管理テーブルの構成の一例を示す図実施形態２に係る、（ａ）課金テーブル、（ｂ）手続きテーブルの構成の一例をそれぞれ示す図実施形態２に係る評価テーブルの構成の一例を示す図実施形態２に係るクレーム案テーブルの構成の一例を示す図実施形態２に係る顧客用サイトのトップ画面の構成の一例を示す図実施形態２に係る出願申請用ページの表示画面の構成の一例を示す図実施形態２に係る入力事項確認ページの構成の一例を示す図実施形態２に係る出願済み案件の情報修正ページの構成の一例を示す図実施形態２に係る未出願案件の情報修正ページの構成の一例を示す図実施形態２に係るクレーム案表示ページの構成の一例を示す図実施形態２に係るクレーム評価ページの構成の一例を示す図実施形態２に係る評価ページの構成の一例を示す図実施形態２に係る弁理士用サイトのトップ画面の構成の一例を示す図実施形態２に係るクレーム案入力画面の構成の一例を示す図実施形態２に係るクレーム案修正確認画面の構成の一例を示す図実施形態２に係る個人評価画面の構成の一例を示す図実施形態２に係る登録情報表示変更画面の構成の一例を示す図実施形態３に係る代理人マッチング支援システムの概略を示すブロック図実施形態３に係る代理人マッチング支援サーバの全体動作の概略を示すフローチャート実施形態３に係るシステムにおける依頼者対応サイト処理の動作を示すフローチャート実施形態３に係る依頼受付を行う処理の動作を示すフローチャート実施形態３に係るコメント表示処理の処理動作を示すフローチャート実施形態３に係るシステムにおける代理人対応サイト処理の動作を示すフローチャート実施形態３に係る、（ａ）依頼者テーブル、（ｂ）代理人テーブル、の構成の一例をそれぞれ示す図実施形態３に係る依頼案件テーブルの構成の一例を示す図実施形態３に係る評価テーブルの構成の一例を示す図実施形態３に係る依頼対応案テーブルの構成の一例を示す図実施形態３に係る依頼者用サイトのトップ画面の構成の一例を示す図実施形態３に係る依頼入力用ページの表示画面の構成の一例を示す図実施形態３に係る代理人選択用ページの表示画面の構成の一例を示す図実施形態３に係るコメント表示ページの構成の一例を示す図実施形態３に係る代理人用サイトのトップ画面の構成の一例を示す図

以下、本発明の実施態様について、図面を参照しながら具体的に説明する。なお、以下の実施態様は、本発明を具体化する際の一形態であって、本発明をその範囲内に限定するものではない。

（実施形態１）
本実施形態の出願支援システムは、例えば大学などの研究機関において、研究者が所定のサイトに論文等の技術情報ファイルをアップロードすることで、当該論文（技術情報ファイル）から特許出願用のHTMLファイル（所定形式出願ファイル）を自動生成し、所定のフォルダに保存するものである。研究者（発明者）にとっては論文を所定のサイトにアップするだけの作業であり、また、知財部等の担当者においても、所定のフォルダに保存された出願用のHTMLファイルを出願ソフトで出願するだけであるので、発明者及び知財担当者の双方にとって簡便且つ迅速な処理を可能とさせるものである。これにより、論文公表までの期間が非常に限られている中でも、発明が公知となる前に、論文に基づいた出願（緊急退避的な出願。以降便宜的に「論文緊急出願」という。）を行うことができ、グレースピリオド等の規定がない若しくは限定的な国においても、当該論文緊急出願に基づいたパリ条約上の優先権を主張して出願を行うことで、権利を取得できる可能性を得られるものである。

図１は、本実施形態１に係る出願支援システムの概略を示すブロック図である。図に示されるように、本部システム１１、部署システム１２、インターネット１３、特許庁システム１４を主な構成要素とする。本部システム１１と部署システム１２は大学内のシステムである。本部システム１１は本部内、部署システム１２は例えば各研究科ごとに設けられるネットワークステムであり、それぞれに備えられるルータ（１１５，１２２）を介して学内ネットワークで相互に接続されている。

本部システム１１内には、内部ネットワーク側には、出願用ファイル作成支援サーバ１１１と、出願用ＨＴＭＬＤＢ１１２（外部記憶装置）と、管理者ＰＣ１１３（管理者端末装置）と、申請ファイルＤＢ１１４（外部記憶装置）と、ルータ１１５などが備えられる。また、各種の業務サーバ等の内部サーバが内部ネットワークに備えられ、ＤＭＺセグメントにＷｅｂサーバ等の公開サーバなどを備える。本実施形態における管理者ＰＣ１１３とは、出願業務を行う担当者のＰＣであり、電子出願ソフトがインストールされている。管理者ＰＣ１１３は、ファイアウォール１１６及びルータ（若しくはゲートウェイ）１１７を介して、インターネット１３と接続されており（適宜インターネットサービスプロバイダ等を介してインターネットに接続される）、これにより特許庁１４のシステムに対して、インターネット出願を行うことができる。

部署システム１２は、例えば研究科ごとに設けられるネットワークステムであり、各研究者のＰＣ１２１（発明者端末装置）は、内部ネットワークを介して出願用ファイル作成支援サーバ１１１との間で情報の送受信が可能である。後に説明するごとく、出願用ファイル作成支援サーバ１１１によって提供される「論文緊急出願申請用のサイト」に、ＰＣ１２１にインストールされているブラウザを利用してアクセスして、発明者情報などの必要情報と、論文等の技術情報ファイルを送信することのみで、論文緊急出願のための研究者側の手続きは終了する。

図２は、出願用ファイル作成支援サーバ１１１の概略を示すブロック図である。出願用ファイル作成支援サーバ１１１には、本体１１１１、入力装置であるキーボードやマウス１１１３、出力装置であるモニタ１１１４、ＨＤＤなどの記憶装置１１１２（記憶部）などが備えられる。本体１１１１は、ＣＰＵ１１１１１、メモリ１１１１２、入出力制御部１１１１４、ネットワークとの情報の送受信を行う通信部１１１１３などを備える。出願用ファイル作成支援サーバ１１１は、通信部１１１１３を介して内部ネットワークへ情報を送受信することができ、これにより管理者ＰＣ１１３や研究者ＰＣ１２１等との間で情報を送受信することができる。記憶装置１１１２には、管理者設定情報テーブル１１１２２（図２８）、出願ファイル管理テーブル１１１２３（図２９）、申請案件テーブル１１１２１（図２５）などが格納される。後に詳細に説明するごとく、出願用ファイル作成支援サーバ１１１は、学内ネットワークを介して「論文緊急出願サイト」等のページを提示し、研究者や管理者から必要な情報を収集して出願用ファイルの自動生成処理などを行うものであり、サイトの各ページを生成するために必要な情報や、後に説明するＨＴＭＬひな形ファイルなども記憶装置１１１２に格納されている。出願用ファイル作成支援サーバ１１１は以降詳細に説明する各処理を実行するものであり、そのためのプログラムが記憶装置１１１２に格納され、これを随時メモリ１１１１２に読み込みつつ制御部であり且つ演算部であるＣＰＵ１１１１１にて各種演算処理などを行い、結果を記憶装置１１１２に格納若しくは他の装置に出力することなどによって各処理が実行されるものである。即ち、ＣＰＵなどの各ハードウェア資源と各プログラムによって、各機能処理部（技術情報ファイル取得部、願書生成部、明細書自動生成部、出願ファイル生成部、ファイル画像化部、ファイル格納処理部、技術情報ファイル受付サイト提示部、当日ファイル移動処理部、整理番号自動生成部、受理済みファイル確認部、従業者判別部、管理者サイト提示部、猶予期間判別部、期間経過確認部、出願取下書生成部）が構成されるものである。

＜システム全体処理概略＞
先ず、本実施形態の出願支援システムの全体的な処理の概略を概観する。図３は本実施形態の出願支援システムの全体動作の概略を示すフローチャートである。研究者（発明者）は、研究者ＰＣ１２１を使って、出願用ファイル作成支援サーバ１１１によって学内サイトとして提供される論文緊急出願申請用のサイトにアクセスし、論文等の技術情報ファイル及び必要情報（発明者の情報など）を送信し、これを受信した出願用ファイル作成支援サーバ１１１では必要情報を記憶装置１１１２や申請ファイルＤＢ１１４等に保存する（Ｓ３０１）。次に、出願用ファイル作成支援サーバ１１１では、Ｓ３０１で受信した情報を利用して出願用のＨＴＭＬファイルを自動生成する処理を実行し（Ｓ３０２）、これを所定フォルダに保存する処理を実行する（Ｓ３０３）。また、論文緊急出願案件がある場合にはこれを管理者に通知する（Ｓ３０４）。管理者（例えば知財部の出願事務担当者など）は、管理者ＰＣ１１３にインストールされている出願ソフト（特許庁が配布している電子出願ソフト）を使って、Ｓ３０３の処理によって“所定フォルダ”に格納されているＨＴＭＬファイルを出願ソフトの送信ファイル形式に変換する処理及びこれを送信する（即ち出願）処理を行う（Ｓ３０５）。このように、研究者は論文等の技術情報ファイル及び必要情報を送信するのみであり（Ｓ３０１）、管理者もシステムによって自動生成され所定フォルダに格納されている出願書類（ＨＴＭＬファイル）を、出願ソフトによって出願するだけである（Ｓ３０５）ので、発明者及び管理者（出願事務担当者）の双方にとって可及的に簡便な手続で、出願を行うことが可能となる。

＜出願用ファイル作成支援サーバ全体処理概略＞
次に、出願用ファイル作成支援サーバ１１１における処理動作の全体の概要を説明し、その後、当該全体処理を構成する各機能処理について順次詳細に説明を行う。図４は、出願用ファイル作成支援サーバ１１１の全体動作の概略を示すフローチャートであり、これに基づいて出願用ファイル作成支援サーバ１１１の処理動作の概要を説明する。

Ｓ４０１〜Ｓ４０４は、イベントの発生待ちのループとなっており、各イベントの発生に応じて、これに対応する処理が実行されることとなる。

研究者ＰＣ１２１から、論文緊急出願申請用のサイトへのアクセス要求があった場合には（Ｓ４０１）、Ｓ４０５に移行して論文緊急出願申請用のサイトによる受付処理（論文等の技術情報ファイル及び必要情報を研究者ＰＣから受信し、所定フォルダに保存する処理）を実行する。当該受付処理については後で詳述するが、当該受付処理において本システムによって受付可能な案件であるか否かが判断され、受付可能な案件である場合には受付番号が戻り値として得られる。受付処理（Ｓ４０５）に続くＳ４０６ではこの戻り値（受付番号）があるか否かが判別され、これが無かった場合（即ち、本システムでは受付不可の場合）にはＳ４０１〜Ｓ４０４のイベント発生待ちループへ戻る（当該案件についての本システムを利用した論文緊急出願は行われない）。また、Ｓ４０５の受付処理では、発明者に関する情報を取得し、当該発明者の中に雇用関係のない者が含まれている場合には、管理情報として「承認要フラグ」に１が設定され、含まれていない場合には０とされて申請案件テーブル１１１２１（図２５）に格納される（本実施形態では、申請者が雇用関係の無い者である場合も１とされる）。受付処理の後のＳ４０６に続くＳ４０７ではこの承認フラグが０であるか否かが判別され、０でなかった場合（１であった場合）は、これを管理者に通知する処理を実行する（Ｓ４０７Ｎｏ→Ｓ４１０）。後に詳細に説明するが、当該通知を受けた管理者は管理者権限でシステムにログインして当該案件についての出願の承認を行い、これによって承認された場合にシステムによるＨＴＭＬファイルの自動生成処理が実行されることになる。当該承認フラグに関する処理は、発明者に従業者でない（雇用関係にない者）が含まれている場合に、システムでの自動処理の前に管理者による承認を求めているものである。雇用関係にない者の持分（特許を受ける権利）については、予約承継はできず、よって本システムを有する機関が勝手に単独で出願することはできないため、管理者による相手機関等への確認を経て承認が得られたことを確認して出願ファイルの自動生成処理の実行をさせるものである（また、本実施形態では申請者が雇用関係の無い者である場合についても管理者の確認を要するようにしている）。なお、管理者のメールアドレスなど、管理者に対して自動的にメールを送信するために必要な情報については、予め記憶装置１１１２に設定されているものである。本実施形態では発明者（及び申請者）が全て従業者であると判断された場合には自動的に出願ファイルの自動生成処理を実行させるものを例としているが、従業者であるか否かに関わらず、管理者からの承認後に出願ファイルの自動生成処理を実行させるようなものであってもよい。

一方、受付処理後のＳ４０７における判別処理の結果、承認フラグが０であった場合には、受付処理で取得したデータに基づいて出願用のＨＴＭＬファイルを自動生成する処理を実行する（Ｓ４０８）。次にＳ４０９に移行して出願予定日が今日以前である場合や「直ちにフラグ」が１である場合には（公開予定日や直ちにフラグなどの受付処理時（Ｓ４０５）に得られる情報に基づく。詳細については後述）、即時処理ファイル移動・通知処理を実行する（Ｓ４１１）。当該処理（Ｓ４１１）は、特に急ぎの案件について、当該案件に関するＨＴＭＬファイルを即時処理用のフォルダに格納し、管理者に通知するものである。当該通知を受けた管理者は、直ぐに、当該即時処理用のフォルダに格納されている出願書類（ＨＴＭＬファイル）を出願ソフトによって出願する処理を行う。これによって、急ぎ案件の迅速な出願処理を行えるようにするものである。

Ｓ４０５〜Ｓ４１１の処理が終了したら、Ｓ４０１〜Ｓ４０４のループ処理へ戻り、次のイベントの発生を待つ。

Ｓ４０１〜Ｓ４０４のループ処理において、時刻が午前零時になった場合には、即時処理用のフォルダ、当日処理用のフォルダ、取下フォルダ、の各フォルダ内のファイルを削除する処理を実行する（Ｓ４０２Ｙｅｓ→Ｓ４１２）。後の各処理の詳細説明においても明らかにするが、各フォルダは各当日に処理を行うファイルが格納されるものであり、日付が変わった際に一度内容をクリアすることで、その日に処理すべきファイルだけが格納されるようにするものである。本実施形態では午前零時に処理するものとしているが、各機関の運用に合わせて任意の時刻に設定して、当該設定時刻に処理されるものであってよい。なお、図２では特に図示していないが、出願用ファイル作成支援サーバ１１１には、時計機能を提供する日時機能部が備えられ、当該日時機能部によって日時情報や計時機能が提供されるものである（時計機能については、ネットワーク上のタイムサーバから時刻を取得することで日時機能部を構成する等してもよい）。

Ｓ４０１〜Ｓ４０４のループ処理において、時刻が「当日ファイル移動時刻」になった場合には、当日ファイル移動・通知処理を実行する（Ｓ４０３→Ｓ４１４）。当該処理は、Ｓ４０８で自動生成されて保存されている出願用ＨＴＭＬファイルのうち、出願予定日が到来した案件について、当日処理用のフォルダにファイルをコピーするものである。本実施形態においては、Ｓ４０５で受け付けた案件についてＳ４０８の処理で出願用ＨＴＭＬファイルを自動生成して出願用ＨＴＭＬＤＢ１１２に格納し、当該ＤＢ１１２に格納されている案件の中から、Ｓ４１４の処理において、当日処理すべき案件が当日処理用のフォルダ（管理者ＰＣ１１３の記憶領域）に移動され、管理者による出願処理の終了後、日付が変わった際に当日処理用のフォルダがクリアされ（Ｓ４１２）、また当日ファイル移動時刻になった際に当日処理すべき案件のファイルが当日処理用のフォルダに移動され・・・という処理が繰り返されることになる。これにより、管理者はいつも同じフォルダ（当日処理用のフォルダ）の中にあるファイルを出願すればよく、手続きが簡便となる（手続きミスの抑止にもつながる）。なお、「当日ファイル移動時刻」は管理者によって設定され、管理者設定情報テーブル１１１２２（図２８）に格納されている情報である。

Ｓ４１４に続くＳ４１５では、取下管理フラグが１であるか否かを判別し、これが１であった場合にはＳ４１６へ移行して取下げ確認・通知処理を実行する。当該処理は、本システムで行った「論文緊急出願」について、所定期間経過後に出願取下書を自動生成して、出願の取下げを促す処理である。本システムの目的の一つは、論文などによって発明が公知となる前に「論文緊急出願」を行うことで、各国への出願を可能とさせるものであり、つまり、パリ条約上の優先権を伴った後の出願を前提としている面がある。従って、「論文緊急出願」自体をそのまま出願として存続させる必要がないと考える機関においては、当該取下管理機能を利用して「論文緊急出願」を適当な時期（例えば出願後１年３月経過時）に取下げることで、それ以降の無駄な手間やコストを省くようにすることができるものである。取下げ管理フラグ（取下管理機能の利用の有無）は管理者によって設定され、管理者設定情報テーブル１１１２２（図２８）に格納されている情報であり、取下げ管理が不要である場合にはこれが０とされ、Ｓ４１６の処理は実行されない（Ｓ４１５Ｎｏ→Ｓ４１６スキップ）。なお、本実施形態では、取下げ確認・通知処理（Ｓ４１６）が「当日ファイル移動時刻」に行われるもの（即ち、当日ファイル移動・通知処理（Ｓ４１４）と同じタイミングでの処理）を例としているが、当日ファイル移動・通知処理（Ｓ４１４）とは別の時刻に処理が行われるように設定されるものであってよい。

Ｓ４０１〜Ｓ４０４のループ処理において、時刻が「チェック時刻」になった場合には、手続終了確認処理を実行する（Ｓ４０３→Ｓ４１３）。当該処理は、処理すべき手続き（論文緊急出願の出願手続きなど）が実行されたか否かを確認する処理である。本実施形態のシステムでは、出願処理はシステムの処理とは別途の処理（管理者ＰＣ１１３にインストールされている出願ソフトによる処理）であり、本システムで直接手続済みであることの情報が得られるものではないため、出願ソフトから出力されるファイルを本システムからチェックすることで、手続きが実行済みか否かをチェックするものである。「チェック時刻」は管理者によって設定され、管理者設定情報テーブル１１１２２（図２８）に格納されている情報である。なお、本実施形態では、チェック時刻が１つだけのものを例としているが、チェック時刻が複数設定されるものであってもよい。例えばＳ４１２のフォルダのクリア処理が行われる際に手続終了確認処理が実行されるもの等であってよい。

Ｓ４０１〜Ｓ４０４のループ処理において、管理者サイトへのアクセス要求があった場合には、管理者操作処理を実行する（Ｓ４０４Ｙｅｓ→Ｓ４１７）。当該処理は、管理者権限で操作可能な管理者サイトにて、本システムに関する各種設定や、各案件の確認や情報入力などを行わせるものである（詳細は後述）。

以上が、出願用ファイル作成支援サーバ１１１における処理動作の全体の概要である。以降は、当該全体処理を構成する各機能処理について順次詳細に説明を行う。

＜＜論文緊急出願申請用のサイトによる受付処理：図４のＳ４０５の処理の詳細＞＞
図５は、研究者（発明者）が、研究者ＰＣ１２１を使って、論文緊急出願申請用のサイトにアクセスし、論文等の技術情報ファイル及び必要情報（発明者の情報など）を送信する作業時の研究者ＰＣ１２１の処理動作を示すフローチャートである（もっとも、本実施形態においては、研究者ＰＣ１２１のＷｅｂブラウザを利用して論文緊急出願申請用のサイトにアクセスし情報入力をするものであり、図５の処理を行うプログラム等が特別に別途必要になるというものではない）。図６は、当該研究者ＰＣ１２１からのアクセス要求に対応する出願用ファイル作成支援サーバ１１１の処理動作を示すフローチャートであり、図４のＳ４０５の処理に相当する。以下、図５と図６を主に参照しつつ論文緊急出願の受付処理について説明する。

研究者（発明者）は、研究者ＰＣ１２１を使って、論文緊急出願申請用のサイトへのアクセスを行う（ＵＲＬは予め学内の研究者に通知してあり、これをもってアクセスする）。これにより、研究者ＰＣ１２１から出願用ファイル作成支援サーバ１１１に対して論文緊急出願申請用ページの送信要求が発せられる（図５：Ｓ５０１）。これを受けた出願用ファイル作成支援サーバ１１１では、図６の受付処理を実行させる（図４：Ｓ４０１Ｙｅｓ→Ｓ４０５）。

本実施形態では、本システムの利用を学内からのアクセスに限定しているため、Ｓ６０１（図６）では、論文緊急出願申請用サイトへのアクセス要求が、学内ネットワーク内からの発信されたものであるか否かを要求元のＩＰアドレスによって判断し、学内からのアクセスでなかった場合には、学内からのアクセスのみ利用可能であることを通知するページを送信して処理を終了する（図６：Ｓ６０１Ｎｏ→Ｓ６１８）。これを受信した研究者ＰＣ１２１では当該使用不可ページを表示して申請処理を終了する（図５：Ｓ５０２→Ｓ５１６）。一方、学内ネットワーク内からのアクセスであった場合には、出願用ファイル作成支援サーバ１１１から論文緊急出願申請用ページが送信され（図６：Ｓ６０１Ｙｅｓ→Ｓ６０２）、これを受信した研究者ＰＣ１２１において当該ページが表示される（図５：Ｓ５０２→Ｓ５０３）。なお、ここでは学内からのアクセスに限定するものを例としているが、制限なしにしたり、他の条件でアクセス制限をするようなもの等であってもよい。

図３０に、当該論文緊急出願申請用ページの表示画面例を示した。本実施形態においては、申請時の入力情報としては図３０に示されるものとなる。このうち、申請者情報（氏名、所属職名、雇用関係、連絡先情報）、発明者情報（氏名、所属職名、発明に対する貢献度、雇用関係、連絡先情報）、公開予定日（例えば論文の公開日など）、公開予定資料（例えば論文のＷｏｒｄファイルなど）、カラー必須であるか否かの情報（資料がカラーで作成されている場合に、これを白黒にすると情報の欠落（内容が不明瞭になる等）が起こるような場合に、カラー必須とする）、資料の言語、が必須の入力項目となっている。なお、発明者が多数いる場合には「欄を追加」ボタンをクリックすることで、発明者の入力欄が追加される。技術分野（発明の技術分野）及びキーワード（発明に関するキーワード）については本実施形態では任意の入力項目となっている。また、「直ちに出願（可及的速やかな出願処理が必要な案件）」に関する情報も入力事項となっている。

申請者（研究者）は、図３０の出願申請用ページの入力事項の入力が終わったら、「入力内容を確認」ボタンを選択する。当該選択により入力情報が出願用ファイル作成支援サーバ１１１に送信される（図５：Ｓ５０４Ｙｅｓ→Ｓ５０５）。これを受信した出願用ファイル作成支援サーバ１１１では（図６：Ｓ６０３Ｙｅｓ→Ｓ６０４）、必須入力情報が入力されているか否かが判別され、入力漏れがあった場合には、図３２（ａ）に示されるような警告ページを送信する（図６：Ｓ６０４Ｎｏ→Ｓ６１３）。当該警告ページを受信した研究者ＰＣ１２１では、これを表示し（図５：Ｓ５０６→Ｓ５１２）、当該警告ページにおいて「ＯＫ」ボタンが選択された場合にはこれを出願用ファイル作成支援サーバ１１１に送信し（図５：Ｓ５１３→Ｓ５１４）、Ｓ５０２の処理に戻る。当該ＯＫ情報を受信した出願用ファイル作成支援サーバ１１１では（図６：Ｓ６１４Ｙｅｓ）、Ｓ６０２へ戻って論文緊急出願申請用ページを研究者ＰＣ１２１に送信する。なお、当該送信時には先に入力済みの内容にて送信を行う。これを受信した研究者ＰＣ１２１側では、再度必要情報の入力が行われる。

出願用ファイル作成支援サーバ１１１における判別処理で、必須の入力事項が満足されている場合には、入力事項確認ページが研究者ＰＣ１２１に送信される（図６：Ｓ６０４Ｙｅｓ→Ｓ６０５）。図３１は当該確認ページ表示例を示す図である。当該ページを受信した研究者ＰＣ１２１では、これが表示され（図５：Ｓ５０６→Ｓ５０７）、研究者は当該情報を確認し、修正が必要であれば、「入力画面に戻る」ボタンを選択する。「入力画面に戻る」の選択があった場合には当該情報を出願用ファイル作成支援サーバ１１１に送信し（図５：Ｓ５０８→Ｓ５１５）、Ｓ５０２へと戻る。「入力画面に戻る」の指示を受信した出願用ファイル作成支援サーバ１１１では（図６：Ｓ６０６）、Ｓ６０２へ戻って論文緊急出願申請用ページを研究者ＰＣ１２１に送信する（当該送信時には先に入力済みの内容にて送信を行う）。これを受信した研究者ＰＣ１２１側では、再度必要情報の入力が行われる。一方、図３１の当該確認ページで、内容に問題がなければ研究者は「入力内容を送信」ボタンを選択する。研究者ＰＣ１２１では当該「入力内容を送信」の選択があった場合にこれを出願用ファイル作成支援サーバ１１１に送信し（図５：Ｓ５０８→Ｓ５０９）、当該情報を受信した出願用ファイル作成支援サーバ１１１では、ＤＢ登録処理へ移行する（図６：Ｓ６０６→Ｓ６０７）。

＜＜＜ＤＢ登録処理：図６のＳ６０７の処理の詳細＞＞＞
図６のＳ６０７では、研究者からの申請により得られた情報、即ち、図３０の出願申請用ページへの入力によって得られる情報をファイル（論文などの技術情報ファイル）と対応付けてＤＢへ登録する処理を行う。図７は、当該図６のＳ６０７の処理を示すフローチャートである。

Ｓ７０１では、受付番号を自動生成して、出願用ファイル作成支援サーバ１１１の記憶装置１１１２の申請案件テーブル１１１２１（図２５）に、当該受付番号が主キーとなる新しいレコードを生成する。当該受付番号については所定の法則に従って自動採番されるものであり、本実施形態では、論文緊急出願であることを示す「Ｅ」という記号と、受付年月日（2013年1月1日の場合には130101）との後にハイフンを続けて、その年の通番（受付をした案件の数）を付与することで、受付番号が自動生成されるものである。申請案件テーブル１１１２１（図２５）は、研究者からの申請により得られた情報と論文などのファイルを対応付けて記憶するためのテーブルである。

続くＳ７０２では、該当レコード（Ｓ７０１で生成した受付番号に対応するレコード）の承認要フラグを０とする（承認要フラグを初期化しているものである）。

Ｓ７０２に続くループ処理（Ｓ７０３〜Ｓ７０７）は、申請者及び発明者（複数の場合
あり）について、それぞれ雇用関係の有無や、職員テーブルにデータがあるか否かなどを確認して申請案件テーブル１１１２１に登録する処理である。Ｓ７０３では、申請情報の氏名情報から職員テーブル（図２６（ａ））にデータがあるか否かを検索する処理が行われ、データがあった場合には、該当するＩＤ（処理対象が発明者である場合にはＩＤ及び貢献度）を申請案件テーブル１１１２１の該当レコードに登録する（Ｓ７０３Ｙｅｓ→Ｓ７０７）。図２６に職員テーブル及び、職コードテーブル、所属コードテーブルの構成例をそれぞれ示した。当該各テーブルは学内ネットワーク上のＤＢに登録されており、職員に関するデータが管理されているものである。（本システムに専用のＤＢであってもよいし、他の学内システムと共用するＤＢであってもよい。後者の方が効率的である。）

氏名情報で検索した結果、職員テーブルに登録情報が無いと判別された場合には、仮のＩＤを自動発行し（本実施形態においては、仮のＩＤであることを意味する“Ｔ”に続けて通し番号を付加することで生成。図２７（ａ）の例では「Ｔ００００１」）、仮ユーザ登録テーブル（図２７（ａ））に、当該ＩＤ、氏名、所属・職名、雇用情報（雇用関係有りなら１、無しなら０）、連絡先情報を登録する（Ｓ７０３Ｎｏ→Ｓ７０４）。続くＳ７０５では、雇用関係の有無（図３０の出願申請用ページへの入力によって得られる情報）を判別し、雇用関係が無い者であった場合には、申請案件テーブル１１１２１の該当レコードの承認要フラグを１にして（Ｓ７０６）、Ｓ７０７へ移行する。一方、雇用関係がある場合にはＳ７０６をスキップしてＳ７０７へ移行する。Ｓ７０７では、申請案件テーブル１１１２１の該当レコードの申請者若しくは発明者の項目にＩＤ（Ｓ７０７で発行された仮ＩＤ）を登録する（処理対象が発明者である場合にはＩＤ及び貢献度）。

上記のＳ７０３〜Ｓ７０７の処理を、申請者及び発明者の全てに実行することで、申請案件テーブル１１１２１の申請者、発明者、貢献度の項目及び、承認要フラグの項目の情報が登録される。上記から明らかなように、当該処理により、申請者、発明者の中に雇用関係の無い者がいた場合には、承認要フラグが１とされる（全員が従業者である場合はフラグが０となる）。なお、本実施形態では申請者の入力を信用している（職員テーブルに登録のない者であっても、雇用関係ありという入力である場合には、これに基づいた処理が実行されることとなる）が、Ｓ７０５の判別処理を削除することにより、職員テーブルに登録されていない者である場合には、必ず管理者の承認を必要とする（承認要フラグが１になる）ようにしてもよい。また、Ｓ７０４の仮ユーザ登録においては、氏名情報等に基づいて仮ユーザ登録テーブルを検索し、重複した登録が行われないようにするもの等であってもよい。

Ｓ７０３〜Ｓ７０７のループ処理の後の、Ｓ７０８では、添付ファイル（論文などの技術情報ファイル）を、申請ファイルＤＢ１１４に格納し、当該格納したアドレス情報を、申請案件テーブル１１１２１の該当レコードの資料アドレスの項目に登録する。さらに、公開予定日、発明の名称、カラー必須情報（カラー必須である場合に１、そうでない場合は０）、言語情報、技術分野、キーワード情報、直ちに出願情報、の各情報を申請案件テーブル１１１２１の該当レコードに登録して（Ｓ７０９）、ＤＢ登録処理を終了する。なお、言語情報、技術分野、雇用関係の有無については、各テーブル（言語コードテーブル（図２７（ｂ））、分野コードテーブル（図２７（ｃ））、雇用コードテーブル（図２７（ｄ）））に基づいてコード化した情報が申請案件テーブル１１１２１に格納される。また、必須の入力情報でないものであって、情報の入力が無かったものについては当該項目は申請案件テーブル１１１２１に格納されない。本実施形態では、添付ファイル（論文などの技術情報ファイル）の格納処理において、ファイル名を変更せずにそのまま格納するものを例としているが、ファイル名に受付番号の情報を付加するなどして書き換えることにより、ファイル名に対して、本システムのどの案件であるかの情報を対応付けるようにしてもよい。

図６（論文緊急出願申請用のサイトによる受付処理）に戻って説明を続ける。

Ｓ６０７のＤＢ登録処理（図７の処理）に続くＳ６０８では、申請情報として得られる「公開予定日」が、申請当日の日付より前であるか、又は、資料の言語がその他（＝日本語若しくは英語では無い場合）であるか否かを判別し、このいずれかに該当する場合には、図３２（ｂ）又は図３２（ｃ）に示されるような、利用不可を示すページを研究者ＰＣ１２１に送信して（Ｓ６１５）受付処理を終了する。公開日が本日より前（即ち既に公開済み）である場合には、本システムで緊急論文出願を行う意味が希薄であるため、利用不可とするものであり、また、資料が日本語か英語で作成されていない場合には、出願ができない（現在の日本の制度では、日本語か英語の出願しか認められておらず、これに反する場合には特１８条の２第１項の規定により手続き却下（いわゆる不受理処分）となる）ため、利用不可としているものである。

Ｓ６０８での判断がＮｏであった場合にはＳ６０９へと移行し、申請情報として得られる「公開予定日」までの期間が、基準期間以上であるか否かを判断し、基準値以上と判断した場合には、通常の発明届を所定部署に提出する手続きを行うように促すページを研究者ＰＣ１２１に送信して（Ｓ６１６）受付処理を終了する。本システムを、論文発表等による公知化を緊急的に退避する出願として利用する場合においては、例えば、発表予定日までの猶予期間が１月以上あるような場合には本システムで出願するのではなく、通常の出願処理（発明届を提出したうえでの出願可否の判断や、人手による出願書類の作成）を行うべきとして、本システムによる自動生成処理を実行させないものである。基準期間については、管理者によって設定され、管理者設定情報テーブル１１１２２（図２８）に格納されている情報である。設定によって当該機能をＯＦＦにできるものとしてもよい。

Ｓ６０９での判断がＮｏであった場合にはＳ６１０へと移行し、申請情報として得られる「公開予定日」までの期間が、猶予日数以下であるか否か若しくは「直ちに出願」であるか否かを判断し、これに該当すると判断した場合には、図３２（ｄ）で示されるようなページ（受付番号と担当者連絡先を表示して、担当者に連絡を促すページ）を研究者ＰＣ１２１に送信し（Ｓ６１７）、Ｓ６１２へと移行する。当該ページ（図３２（ｄ））は、図７のＳ７０１で生成された受付番号を挿入したものが自動生成される。本システムでは、申請当日（申請直後）の出願処理も可能であるが、共同出願案件のような場合には、共願相手の許諾を得るなどの調整を要する（出願準備に所定期間を要する）場合もあるため、所定の猶予日数が無いような場合は、担当者（管理者）への直接の連絡を促すものである。また、担当者へ直接連絡をさせることで、次回以降は公表まで少し余裕を持った申請を行わせるようにする効果も期待できるものである。なお、猶予日数については、管理者によって設定され、管理者設定情報テーブル１１１２２（図２８）に格納されている情報である。

Ｓ６０８、Ｓ６０９、Ｓ６１０のそれぞれの判別が全てＮｏであった場合（即ち、「公開予定日」までの期間に応じた警告の必要がない案件の場合）には、Ｓ６１１へと移行して、受付番号と受付完了を通知するページを研究者ＰＣ１２１に送信する。なお、Ｓ６１５、Ｓ６１６、Ｓ６１７、Ｓ６１１の何れかによって送信されたページを受信した研究者ＰＣ１２１では、これを表示して（図５：Ｓ５１０→Ｓ５１１）処理を終了する。

Ｓ６０８及びＳ６０９の判別がＮｏであった場合には、Ｓ６１２の処理が実行され、受付番号を戻り値として図４の処理に戻る。上述のごとく、図６の処理により、論文緊急出願のために必要な情報とファイルが研究者から取得されるものであり、既に公開済みの案件でなく、且つ、公開予定日までの期間が基準期間以上ある案件ではない場合、即ち、本システムでの出願が認められる案件である場合について受付番号が戻り値として得られることとなる。なお、本実施形態では、本システム利用の申請受付において、出願申請用ページのＵＲＬを必要な者にのみ通知しているという前提で、特にログイン処理を行っておらず、学内ネットワークからのアクセスであるか否かのみを確認する（図６：Ｓ６０１）ようにしているが、本システム利用時にログインを必要とするようにしてもよい（利用を許諾する者に対して予めＩＤとパスワードを通知しておく）。この場合、学外からのアクセスを可とする（図６のＳ６０１・６１８の処理を行わない）ようにしてもよい（これにより、極端な例としては、学会発表会場から発表直前に本システムを利用して緊急出願を申請するということも可能になる）。また、ログイン処理を前提とする場合において、ＩＤとパスワードを各職員に個別に設定することで（職員ＩＤを利用するなど）、申請者情報は当該ＩＤから取得できるため、図３０の申請画面における申請者情報の入力を省略させ、申請者に対する図７のＳ７０３〜Ｓ７０６の処理を省略することができる。発明者についても、図３０の申請画面において職員ＩＤでの入力を受け付けるようにすれば、所属や雇用関係、連絡先といった情報の入力を省略させることができる（貢献度情報は必須）。

本実施形態では論文等の技術情報に関するＤＢを構築する目的で、受付処理（図６）において技術分野やキーワードに関する情報の入力も求めるようにしている。これにより、上述のごとく、受付処理によって図２５のような申請案件テーブルが生成され、論文などの技術情報ファイルと、技術分野やキーワードに関する情報が対応付けられることになる。従って、本システムによって、キーワードなどによって論文等のファイルを検索可能なＤＢが構成されていくものである。本システムでは論文に限らず各種の発表資料が登録されることが想定されるため、当該ＤＢは大学の知財部や産学連携部署の活動にとっては有用なものとなり得るものである。このようなＤＢが特に必要なければ、受付処理時において、技術分野やキーワードの情報を取得しないシステムとしてもよい。また、本実施形態では、論文に関するＤＢを構築する目的により、Ｓ６０７の処理をＳ６０８やＳ６０９の処理より先に行うようにしている（これにより本システムでの出願が認められない案件についても、ＤＢへの登録が行われる）が、Ｓ６０７をこれらの処理よりも後に実行することで、本システムでの出願が認められる案件のみについてＤＢに登録させるような処理としてもよい。

＜＜ＨＴＭＬファイル自動生成保存処理：図４のＳ４０８の処理の詳細＞＞
図４のＳ４０８では、受付処理（Ｓ４０５＝図６）で取得したデータに基づいて出願用のＨＴＭＬファイルを自動生成する処理が実行される。図８は、当該図４のＳ４０８の処理を示すフローチャートである。

出願用ファイル作成支援サーバ１１１の記憶装置１１１２には、図３９に示されるような明細書ＨＴＭＬひな形ファイル（テキストファイル）が格納されている。ＨＴＭＬファイル自動生成保存処理は、当該ひな形ファイルに対して、受付処理で取得したデータを利用して、図４０のような出願用のＨＴＭＬファイルを自動生成するものである。本実施形態における明細書ＨＴＭＬひな形ファイル（図３９）では、出願人情報として自己の機関の識別番号、名称、代表者や予納台帳番号の情報が予め記載されている。また、発明の名称、図１についての図面の簡単な説明、特許請求の範囲の請求項１、要約書のそれぞれについて予め情報が記入されており、図面の図１についても所定の画像ファイル（ダミー.jpg）がリンクされている。当該画像ファイル（ダミー.jpg）そのものについても、明細書ＨＴＭＬひな形ファイルと同様に記憶装置１１１２に格納されている。

ＨＴＭＬファイル自動生成保存処理（図８）は、図４のＳ４０８に該当する処理であり、この前のＳ４０５の受付処理（図６）の戻り値として得られる受付番号に基づき、当該受付番号に該当する案件についての処理となる。ＨＴＭＬファイル自動生成保存処理が実行されると、先ず、出願整理番号を自動生成して、出願用ファイル作成支援サーバ１１１の記憶装置１１１２の出願ファイル管理テーブル１１１２３（図２９）に、当該出願整理番号が主キーとなる新しいレコードを生成する（図８：Ｓ８０１）。当該出願整理番号については所定の法則に従って自動採番されるものであり、本実施形態では、論文緊急出願であることを示す「Ｅ」という記号と、年情報（2013年の場合には2013）との後にハイフンを続けて、その年の通番（出願案件として出願用ファイルを自動生成した案件の数）を付与することで、出願整理番号が自動生成されるものである（本実施形態では受付した案件の全てを出願する訳ではないため、受付番号とは別に出願整理番号も付与し、当該出願整理番号を願書の整理番号として利用するものであるが、受付番号を用いるようなものであっても構わない）。出願ファイル管理テーブル１１１２３（図２９）は、本システムで自動生成する出願用のＨＴＭＬファイルに関する情報を対応付けて記憶するためのテーブルである。Ｓ８０１では、受付番号も出願ファイル管理テーブル１１１２３に登録し、即時フラグ、当日フラグ、取下フラグ、警告フラグ、終了フラグ、国内優先フラグの各フラグを０で初期化して登録する。

続くＳ８０２では、“直ちにフラグ”が１であるか否かを判別する。直ちにフラグは受付番号をキーにして申請案件テーブル１１１２１（図２５）を参照して取得する。直ちにフラグが１であった場合には、Ｓ８０９へ移行して日時機能部によって得られる今日の日付を出願予定日として、Ｓ８０１で生成した出願整理番号（以下、「処理対象出願整理番号」という）に対応付けて出願ファイル管理テーブル１１１２３（図２９）に格納する。一方、直ちにフラグが１でなかった場合には、Ｓ８０３へ移行して、公開予定日（受付番号をキーにして申請案件テーブル１１１２１から取得）から、猶予日数を引いた日付を出願予定日として、処理対象出願整理番号に対応付けて出願ファイル管理テーブル１１１２３（図２９）に格納する。猶予日数は、管理者設定情報テーブル１１１２２（図２８）に保持されている情報である。例えば、猶予日数を３日として設定してある場合には、公開予定日の３日前が出願予定日として出願ファイル管理テーブル１１１２３に格納されるものである。

続くＳ８０４では、カラーフラグが１であるか、又は言語フラグが２であるか否か（いずれも受付番号をキーにして申請案件テーブル１１１２１から取得）を判別し、カラーフラグが１又は言語フラグが２であった場合には、Ｓ８１０・８１１の処理を実行し、それ以外はＳ８０５〜Ｓ８０７の処理を実行する。Ｓ８０５〜Ｓ８０７は通常の特許出願としてＨＴＭＬファイルを自動生成する処理であり、Ｓ８１１は、外国語書面出願としてＨＴＭＬファイルを自動生成する処理である。言語フラグが２である場合は、論文等（受付処理で添付された技術情報ファイル）が英語で作成されているものであるため、外国語書面出願としてＨＴＭＬファイルを生成させる処理である。また、カラーフラグが１の場合、論文等（受付処理で添付された技術情報ファイル）がカラーで作成されており、且つ、これをグレースケールにすると意味が不明瞭になってしまうような場合には、外国語書面出願としてＨＴＭＬファイルを自動生成し、カラーのＰＤＦファイルを添付することで、情報の欠落を防ぐものである。（日本国の特許電子出願では2012年現在においてカラーの画像の添付が認められておらず、一方、外国語書面出願においては、カラーのＰＤＦファイルを添付することが可能であるため、外国語書面として出願をすることで、情報の欠落を抑止させるものである。）本システムでは、新規性喪失を防止することを第一の目的として論文緊急出願を行うものであり、公表予定の資料に対して情報が欠落した内容で論文緊急出願をしたのでは、新規性喪失の防止という目的を達し得ないおそれもあるため、このような処理としているものである。

以下、先ず通常の特許出願としてＨＴＭＬファイルを自動生成する処理（Ｓ８０５〜Ｓ８０７）について説明し、次に外国語書面出願としてＨＴＭＬファイルを生成させる処理（Ｓ８１１）を説明する。

通常の特許出願としてＨＴＭＬファイルを自動生成する処理（Ｓ８０５〜Ｓ８０７）では、明細書ＨＴＭＬひな形ファイルを利用しその願書部分を自動生成する願書部作成処理（Ｓ８０５）と、論文等（受付処理で添付された技術情報ファイル）の各ページをそれぞれ画像ファイルに変換する資料個別ページ画像化処理（Ｓ８０６）と、明細書部分を自動生成する明細書部作成処理（Ｓ８０７）とが実行される。なお、本実施形態においては、特許請求の範囲、図面、要約書の部分は、明細書ＨＴＭＬひな形ファイルにおいて予め設定されており、当該ひな形の内容のまま出願するものを例としている。

＜＜＜願書部作成処理：図８のＳ８０５の処理の詳細＞＞＞
図９は、願書部生成処理の処理動作を示すフローチャートである。まずＳ９０１で、出願用ファイル作成支援サーバ１１１の記憶装置１１１２に格納されている明細書ＨＴＭＬひな形ファイル（図３９）を取得する。図９のフローチャートの隣には、当該明細書ＨＴＭＬひな形ファイルの内容のうちの該当部分を示しており、１がひな形そのものである。当該ひな形ファイルの内容に対して、「整理番号」の項目に続く位置に処理対象出願整理番号を挿入する（Ｓ９０２）。２が挿入後の該当部分を示すものとなる。

Ｓ９０２の処理に続くループ処理は、発明者の人数分処理を繰り返すものであり、申請案件テーブル１１１２１（図２５）を参照して、受付番号をキーに該当する発明者ＩＤを順次取得し、各ＩＤに対してＳ９０３の処理を行うものである。Ｓ９０３では、申請案件テーブル１１１２１から取得した発明者ＩＤに基づいて、職員テーブル（図２６（ａ））を参照して氏名を取得し、当該氏名を、図９のＳ９０３の中の「挿入する３行」の一番下の行の“発明者”の部分におきかえて、当該３行を、明細書HTML雛形ファイル中の、「特許出願人」の項目の前の位置で改行して挿入する。当該処理後の該当部分が３である（ここの例では発明者は一人。申請案件テーブル１１１２１に発明者ＩＤが複数ある場合はＳ９０３の処理が順次繰り返され、発明者欄が人数分追加される）。なお、本処理が実行される場合、学外の発明者は含まれていないので（図４のＳ４０７を経て本処置が実行されているため）、発明者の住所については、本システムを有する機関の住所が予め設定されており、これが利用されるものである。

上述のごとく、図９の願書部作成処理により、受付処理によって得られた発明者情報と、システムによって自動生成された整理番号とを利用して、明細書ＨＴＭＬひな形ファイルの該当部分を更新することにより、願書部分の自動生成が行われる。なお、当該自動生成されたファイル（明細書ＨＴＭＬひな形ファイルの該当部分が本案件用に更新されたファイル）は、後の処理のために一時ファイルとして保持される。

＜＜＜資料個別ページ画像化処理：図８のＳ８０６の処理の詳細＞＞＞
図９の願書部作成処理（図８：Ｓ８０５）に続いて、明細書部分を作成するための前処理である、資料個別ページ画像化処理（図８：Ｓ８０６）が実行される。図１０は当該処理（論文などのファイルを、ページごとに画像化（ＪＰＥＧファイルへの変換）する処理）を示すフローチャートである。

資料個別ページ画像化処理では、まず、申請案件テーブル１１１２１から受付番号をキーに“資料アドレス”を取得し、当該アドレス情報に基づいて技術情報ファイルを取得する。次に、取得した技術情報ファイルを開き（ファイルに対応するアプリケーションプログラム（例えば、拡張子が.docxであるファイルに対する、Microsoft Word（登録商標）など）を実行し）、当該アプリケーションプログラムに印刷コマンドを実行させる。当該印刷コマンドの実行によってアプリケーションプログラムから印刷出力データが得られるため、これを取得する（Ｓ１００１）。即ち、本実施形態では、各アプリケーションソフトが出願用ファイル作成支援サーバ１１１にインストールされており、Ｓ１００１では、各ファイル形式にそれぞれ対応付けられているアプリケーションプログラムがシステムによって自動的に起動され、当該アプリケーションプログラムに対して印刷コマンドが自動的に与えられるものである。

続くＳ１００２では、Ｓ１００１の処理によって得られる印刷出力データに基づいて、そのページ数をｎに代入し、ｉに１を代入する。これにより、Ｓ１００２に続くループ処理において、Ｓ１００３〜１００６の処理が、技術情報ファイルの印刷時のページ数分だけ繰り返されることとなる。

Ｓ１００３では、印刷出力データに基づいてそのｉページ目を取得し、当該ページをJPEGファイル（グレースケール、2677×4015ドット）へ変換する処理（電子出願用のＨＴＭＬファイルに、画像として添付することが可能な（許されている）形式への変換）を実行する。

Ｓ１００４では、処理対象出願整理番号の後にアンダーバーとｉを付加することで、ファイル名を生成する。例えば、出願整理番号が「Ｅ２０１３−００１」である場合で、その１ページ目を画像化している場合は、「Ｅ２０１３−００１_０００１」というファイル名が生成され、その１００ページ目を画像化している場合は、「Ｅ２０１３−００１_０１００」というファイル名が生成されこととなる。続くＳ１００５では、当該生成したファイル名で画像ファイルを出願用ＨＴＭＬＤＢ１１２に保存し、当該アドレス情報を出願ファイル管理テーブル１１１２３（図２９）の「リンクファイルアドレス」に格納する。

Ｓ１００６ではｉをインクリメントしてループ処理を続行する。印刷出力データの全てのページに対する処理が終わった場合（即ち、ｉがｎになるまでループ処理を実行した場合）には、ループ処理を終了する。当該ループ処理により、印刷出力データのページの数だけ、画像ファイル（JPEGファイル）が生成されることとなり（７０ページなら７０ファイル）、そのファイル名として、処理対象出願整理番号にページ番号が付加されたものが付与されることとなる。なお、本実施形態では、JPEGファイルを例としたが、電子出願用のＨＴＭＬファイルに、画像として添付することが許されている形式であれば、何れのファイル形式であってもよい。

ループ処理が終了したら、ｎを戻り値として（Ｓ１００７）、資料個別ページ画像化処理を終了する。

資料個別ページ画像化処理（図８：Ｓ８０６）の実行により、技術情報ファイルがページごとに画像ファイル化されて出願用ＨＴＭＬＤＢ１１２に格納される状態となる。続くＳ８０７の明細書部作成処理では、当該画像化されたファイルと、願書部生成処理によって生成された一時ファイルとを利用して、出願用のＨＴＭＬファイルを生成する処理が実行される。なお、資料個別ページ画像化処理（図８：Ｓ８０６）の戻り値であるｎを引数として、明細書部作成処理（図８：Ｓ８０７）を実行させる。

＜＜＜明細書部生成処理：図８のＳ８０７の処理の詳細＞＞＞
図１１は、明細書部生成処理の処理動作を示すフローチャートである。Ｓ１１０１でｉに１を代入する処理を行う。続くループ処理ではＳ１１０２〜Ｓ１１０４の処理をｎ回繰り返す。当該ｎは、資料個別ページ画像化処理（図８：Ｓ８０６）の戻り値であり、技術情報ファイルの印刷時のページ数に該当する。即ち、当該ループ処理ではＳ１１０２〜Ｓ１１０４の処理をページ数分だけ繰り返すものである。

Ｓ１１０２では、願書部作成処理（図８：Ｓ８０５）によって一時ファイルとして保持されている明細書ＨＴＭＬひな形ファイル（ひな形ファイルに対して願書部分を更新したファイル）に対し、「図面の簡単な説明」の項目の前の位置で改行した上で、ｉを段落番号としたものと改行タグを挿入し、改行する。図１１のフローチャートの隣には、明細書ＨＴＭＬひな形ファイルの内容の中の該当部分を示しており、１がひな形そのものの部分である。Ｓ１１０２の処理により、１→２→３→４と内容が更新されるものである。

続くＳ１１０３では、Ｓ１１０２で挿入した段落番号の次の位置において、「処理対象出願整理番号_i」の画像ファイルに基づいて画像を表示させるタグを挿入し、改行タグを挿入する。「処理対象出願整理番号_i」とは、資料個別ページ画像化処理（図１０）のＳ１００４と同様のものであり、即ち、資料個別ページ画像化処理で付与された画像ファイルのファイル名と同じファイル名を生成しているものである。これにより、資料個別ページ画像化処理でページごとに生成された画像ファイルが挿入される。Ｓ１１０３の処理により、５の内容（図１１のフローチャートの隣の、明細書ＨＴＭＬひな形ファイルの内容）に更新される。Ｓ１１０３に続くＳ１１０４においてｉをインクリメントし、ループ処理を続行する。

上記のＳ１１０２〜Ｓ１１０４のループ処理がｎ回繰り返されることにより、資料個別ページ画像化処理によってページごとに画像ファイルにされたものを、１ページ目に該当する画像ファイルから順番に、各段落番号において１つずつ画像表示させるタグが挿入されることになる。なお、本実施形態ではｉを段落番号としており、即ち、ページ番号と段落番号が一致することとなる（段落０００１には１ページ目の画像ファイル、段落０００２には２ページ目の画像ファイル、・・・段落ｎにはｎページ目の画像ファイルに基づくimg srcタグが挿入される）。よって当該ＨＴＭＬファイルをブラウザ上で見た場合には、段落０００１に技術情報ファイルの１ページ目の画像が表示され、段落０００２に技術情報ファイルの２ページ目の画像が表示され、・・・段落ｎにｎページ目の画像ファイルが表示されることになる。なお、このようにしているのは処理の簡便のためであり、これに限るものではなく、段落番号とページ番号が異なるものであっても別に構わない。

ループ処理を抜けた後のＳ１１０５では、明細書ＨＴＭＬひな形ファイルの段落ｆｆｆｆを段落ｎ+１に置換する処理が実行される。即ち、「図面の簡単な説明」の項目の段落番号を、ｎの次の段落番号とすることで、段落番号の連続性を保つものである。Ｓ１１０５の処理により、６の内容（図１１のフローチャートの隣の、明細書ＨＴＭＬひな形ファイルの内容）に更新される（ここでは、簡便のため、技術情報ファイルが１ページしかない場合の例となる）。当該Ｓ１１０５の処理をもって明細書部生成処理を終了する。

上述のごとく、図１１の明細書部作成処理により、技術情報ファイルの全ページが明細書の各段落番号に張り付けられ、これにより明細書部分の自動生成が行われる。なお、本実施形態では特許請求の範囲、図面、要約書の部分は、明細書ＨＴＭＬひな形ファイルにおいて予め設定されており、当該ひな形の内容のまま出願するものであるので、図８のＳ８０５（願書部生成処理）〜Ｓ８０７（明細書部作成処理）によって、論文緊急出願のＨＴＭＬファイルが完成することとなる。なお、本実施形態においては、願書部作成処理を資料個別ページ画像化処理や明細書部作成処理より先に処理しているが、願書部作成処理は、他の処理との関係で任意のタイミングで構わない（ただし、上記説明から明らかなように、資料個別ページ画像化処理と明細書部作成処理との関係については、資料個別ページ画像化処理が先に実行される必要がある）。また、本実施形態では、資料個別ページ画像化処理と明細書部生成処理を別の処理として説明しているが、ループの回数は共通するものであり、資料個別ページ画像化処理と明細書部生成処理のループ処理を別々に行うのではなく、１回のループで同時に行うものであってもよい。

次に外国語書面出願としてＨＴＭＬファイルを生成させる処理（図８：Ｓ８１１）について説明する。

Ｓ８０４（図８）の判別の結果、カラーフラグが１又は言語フラグが２であった場合には、Ｓ８１０へと移行する。前述のごとく、こちらの処理ルートは外国語書面出願としてＨＴＭＬファイルを生成させる処理ルートであり、Ｓ８１０では、外国語書面出願であることを示す“Ｆ”の記号を処理対象出願整理番号の末尾に追加することで、出願整理番号を更新し、出願ファイル管理テーブル１１１２３（図２９）に登録する。例えば、Ｓ８０１で生成された出願整理番号が「Ｅ２０１３−００１」である場合には、「Ｅ２０１３−００１Ｆ」とされ、出願ファイル管理テーブル１１１２３の情報が更新される。Ｓ８１０の次は、外国書面出願ファイル生成処理（Ｓ８１１）が実行される。

＜＜＜外国書面出願ファイル生成処理：図８のＳ８１１の処理の詳細＞＞＞
図１２は外国書面出願ファイル生成処理の処理動作を示すフローチャートである。出願用ファイル作成支援サーバ１１１の記憶装置１１１２には、図４１に示されるような外国語書面ＨＴＭＬひな形ファイル（テキストファイル）が格納されており、外国書面出願ファイル生成処理は、当該ひな形ファイルに対して、受付処理で取得したデータを利用して図４２のような出願用のＨＴＭＬファイルを自動生成するものである。本実施形態における外国語書面ＨＴＭＬひな形ファイル（図４１）では、出願人情報として自己の機関の識別番号、名称、代表者や予納台帳番号の情報が予め記載されている。

Ｓ１２０１では、出願用ファイル作成支援サーバ１１１の記憶装置１１１２に格納されている外国語書面ＨＴＭＬひな形ファイル（図４１）を取得する。図１２のフローチャートの隣には、外国語書面ＨＴＭＬひな形ファイルの内容のうちの該当部分を示しており、１がひな形そのものである。当該ひな形ファイルの内容に対して、「整理番号」の項目に続く位置に出願整理番号（図８のＳ８１０で更新した出願整理番号）を挿入する（Ｓ１２０２）。２が挿入後の該当部分を示すものとなる。

Ｓ１２０２の処理に続くループ処理は、図９のループ処理と同様の処理概念であるため、ここでの説明を省略する。当該処理後の該当部分が図１２の３である

ループ処理に続くＳ１２０４では、申請案件テーブル１１１２１から受付番号をキーに“資料アドレス”を取得し、当該アドレス情報に基づいて技術情報ファイルを取得する。当該技術情報ファイルがＰＤＦファイルで無かった場合には、当該ファイルをＰＤＦファイルに変換する処理を実行する（Ｓ１２０５Ｎｏ→Ｓ１２０６）。一方技術情報ファイルがＰＤＦファイルであった場合には、Ｓ１２０６をスキップしてＳ１２０７へ移行する。なお、Ｓ１２０６のＰＤＦファイルへの変換処理では、カラーのままでＰＤＦファイルへの変換処理が実行される。

Ｓ１２０７では、当該ＰＤＦファイル（技術情報ファイル）を、出願整理番号（図８のＳ８１０で更新した出願整理番号）をファイル名として、出願用ＨＴＭＬＤＢ１１２に保存し、当該アドレス情報を出願ファイル管理テーブル１１１２３（図２９）の「リンクファイルアドレス」に追加する処理を行う。例えば、出願整理番号が「Ｅ２０１３−００１Ｆ」である場合には、「Ｅ２０１３−００１Ｆ．ｐｄｆ」というファイル名が付与されてＤＢに格納されることとなる。

Ｓ１２０８では、外国語書面ＨＴＭＬひな形ファイルの、「外国語書面」の項目の次にあるリンクタグのリンク先をＰＤＦファイル（技術情報ファイル）とし、さらに、アンカーテキストとしてＰＤＦファイル名を挿入する処理を行う。本実施形態においては、出願用ＨＴＭＬファイルと、ＰＤＦファイルは同じフォルダに格納するため、リンク先の設定としてはファイル名を記載するだけでよい。例えば、ファイル名が「Ｅ２０１３−００１Ｆ．ｐｄｆ」である場合には、ひな形の「＜ａｈｒｅｆ＝“”＞＜／ａ＞」のタグに対し、リンク先の設定としてファイル名を追加し「＜ａｈｒｅｆ＝“Ｅ２０１３−００１Ｆ．ｐｄｆ”＞＜／ａ＞」、また、アンカーテキストとしてもファイル名を挿入することで、「＜ａｈｒｅｆ＝“Ｅ２０１３−００１Ｆ．ｐｄｆ”＞Ｅ２０１３−００１Ｆ．ｐｄｆ＜／ａ＞」となる。

当該外国書面出願ファイル生成処理によって、論文緊急出願のＨＴＭＬファイル（外国語書面としての出願用ＨＴＭＬファイル）が完成することとなる。

なお、図１２の処理では、技術情報ファイルをそのまま（若しくはＰＤＦ化するのみで、書類の様式は元の技術情報ファイルのまま）願書に添付する形としているが、通常出願の出願用ＨＴＭＬ自動生成処理と同じように、技術情報ファイルの各ページを画像化してこれを張り付ける処理（図８：Ｓ８０６〜Ｓ８０７）によって明細書を作成し、当該作成した明細書をＰＤＦ化してこれを願書に添付する処理としてもよい。図４６が当該処理を示すフローチャートである（図１２と同様の処理概念となるものについては同一の符号を使用している）。図４６の処理では、ループ処理に続いて、「資料個別ページ画像化処理」を実行する。当該処理は図１０と同様の処理であるが、Ｓ１００３におけるJPEGファイルへの変換処理では、カラーでの変換を行う。「資料個別ページ画像化処理」に続く「明細書部作成処理」も図１１と同様の処理であるが、利用するひな形ファイルが、外国語書面の願書部以外の部分のＨＴＭＬひな形ファイルとなる。図４４に、当該ひな形ファイルの一例を示した。当該ひな形ファイルに対して図１１の処理が実行されることで、図４５のようなＨＴＭＬファイルが生成される。Ｓ１２０６（図４６）では、当該生成されたＨＴＭＬファイルをカラーのままＰＤＦに変換する処理を行う。当該処理により、技術情報ファイルの各ページがカラー画像で張り付けられた外国語明細書（及び外国語特許請求の範囲、外国語要約書、外国語図面）のＨＴＭＬファイルが自動生成された上で、これをカラーのままＰＤＦに変換したファイルが生成される。Ｓ１２０８では、当該ＰＤＦファイルが「外国語書面」として、願書のＨＴＭＬファイルに挿入（リンク）されることとなる。

図８に戻って説明を続ける。明細書部作成処理（Ｓ８０７）又は外国書面出願ファイル生成処理（Ｓ８１１）後の、Ｓ８０８では、上記各処理によって得られた論文緊急出願のＨＴＭＬファイルを、処理対象出願整理番号をファイル名（例えば、「Ｅ２０１３−００１Ｆ．ｈｔｍｌ」）として出願用ＨＴＭＬＤＢ１１２に保存し、当該アドレス情報を出願ファイル管理テーブル１１２３（図２９）の「出願ファイルアドレス」に追加する処理を行う。また、申請案件テーブル１１１２１の生成済フラグを１とする（ＨＴＭＬファイルの自動生成処理が行われた案件であることを示すフラグである）。これをもってＨＴＭＬファイル自動生成保存処理が終了し、当該処理により、論文緊急出願のＨＴＭＬファイル（及びこれに必要な画像ファイル若しくはＰＤＦファイル）が自動生成されて出願用ＨＴＭＬＤＢ１１２に格納され、また、当該生成したファイルに関する情報が出願ファイル管理テーブル１１２３に対応付けられて格納されることとなる。

ＨＴＭＬファイル自動生成保存処理（図４：Ｓ４０８）後のＳ４０９では、出願予定日（出願ファイル管理テーブル１１１２３を参照）が今日以前である場合や「直ちにフラグ」（申請案件テーブル１１１２１を参照）が１である場合には、即時処理ファイル移動・通知処理を実行する（Ｓ４１１）。

＜＜即時処理ファイル移動・通知処理：図４のＳ４１１の処理の詳細＞＞
即時処理ファイル移動・通知処理は、特に急ぎの案件である場合に、それ専用のフォルダに出願用のＨＴＭＬファイルを移動し、管理者に通知する処理である。特に急ぎの案件とは、出願予定日が今日以前である場合や受付処理で（申請時）「直ちに出願」とされたものである。本実施例では、受付処理において得られる公開予定日と、これに対する猶予日に基づいて出願予定日が定められる（図８：Ｓ８０３）ため、申請受付時に既に出願予定日を過ぎているような場合もあり得る。例えば、猶予日が３日に設定されている場合で公開予定日が２日後であるような場合には、申請時に出願予定日を既に１日経過していることとなり、このような案件については、即時に出願処理を行う案件として管理者に注意を促すものである。なお、猶予日数は、公開予定日に対してどの程度余裕をもって出願を行わせるかという観点等に基づいて適宜設定されるものである（本システムを利用する機関の運用の考え方による）。図１３は、即時処理ファイル移動・通知処理の処理動作を示すフローチャートである。

Ｓ１３０１では、処理対象出願整理番号をキーにして、出願ファイル管理テーブル１１１２３を検索し、出願ファイルアドレスとリンクファイルアドレス（複数ある場合には全て）を取得する。

続くＳ１３０２では、Ｓ１３０１で取得したアドレス情報に基づいて、全ての該当ファイル（出願用のＨＴＭＬファイル、及び、技術情報ファイルに基づく画像ファイル若しくはＰＤＦファイル）を出願用ＨＴＭＬＤＢ１１２から取得し、管理者ＰＣ１１３の記憶部内の即時処理用のフォルダへコピーする。また、出願ファイル管理テーブル１１１２３の即時フラグを１とする。なお、「即時処理用のフォルダ」については、管理者によって予め設定されるフォルダであり、管理者設定情報テーブル１１１２２（図２８）に設定情報が格納されている。

Ｓ１３０３では、管理者に処理対象出願整理番号をメールして、即時処理ファイル移動・通知処理を終了する。当該通知を受けた管理者は、管理者ＰＣ１１３にインストールされている出願ソフトを使って、「即時処理用のフォルダ」に格納されている出願用ＨＴＭＬファイルを利用して出願処理を行うことにより、迅速な出願手続きが可能になるものである。

以上、詳細に説明した「受付処理（図４：Ｓ４０５、図６）」、「ＨＴＭＬファイル自動生成保存処理（図４：Ｓ４０８、図８）」、「即時処理ファイル移動・通知処理（図４：Ｓ４１１、図１３）」の各処理を含む、Ｓ４０５〜Ｓ４１１の処理により、論文緊急出願の受付（受付可否の自動判別含む）と、システムでの自動処理の可否（管理者承認の必要性）の判断と、システムによる出願用ＨＴＭＬファイルの自動生成などが行われることとなる。

次に、Ｓ４０８（図４）で自動生成されて出願用ＨＴＭＬＤＢ１１２に保存されている出願用ＨＴＭＬファイルのうち、出願予定日が到来した案件について、当日処理用のフォルダにファイルをコピーする処理について説明する。

＜＜当日ファイル移動・通知処理：図４のＳ４１４の処理の詳細＞＞
管理者設定情報テーブル１１１２２（図２８）に予め設定されている時刻である「当日ファイル移動時刻」になると、当日ファイル移動・通知処理が実行される（図４：Ｓ４０３→Ｓ４１４）。「当日ファイル移動時刻」はそれぞれの機関の運用に合わせて設定されるものである（例えば、その日の分の出願処理をまとめて１７時に手続きしている場合に、１６時に設定することで、当日の１６時までに受付及びＨＴＭＬ自動生成が終わっている案件について、当日処理用のフォルダに移動されるようにすることなどが考えられる）。図１４は、当日ファイル移動・通知処理の処理動作を示すフローチャートである。

当日ファイル移動・通知処理が実行されると、初期化処理として、出願ファイル管理テーブル１１１２３（図２９）の、当日フラグを全てクリア（０にする）処理を行う。前日分のデータをクリアするものである。本実施形態では、当日ファイル移動・通知処理で行うようにしているが、図４のＳ４１２の処理（日付が変わる際の各フォルダの内容をクリアする処理）において行うもの等であってもよい。

Ｓ１４０１に続くループ処理は、出願ファイル管理テーブル１１１２３の全レコードのそれぞれに対してＳ１４０２〜Ｓ１４０５の処理を行うものである。

Ｓ１４０２では、出願完了フラグが１であるか否か、又は、終了フラグが１であるか否かを判別し、いずれかが１である場合にはＳ１４０３〜Ｓ１４０５の処理をスキップして、処理対象を次のレコードとする。既に出願済みの案件（出願完了フラグ＝１）や、本システムでの出願管理を終了した案件（終了フラグ＝１）については、処理対象から外している処理となる。Ｓ１４０２に続くＳ１４０３では、出願予定日が本日であり、且つ、即時フラグが１でない案件を判別し、これに該当しない場合は、Ｓ１４０４〜Ｓ１４０５の処理をスキップして、処理対象を次のレコードとする。出願予定日が到来した案件を判別しているものであり、また、前述したごとく、即時フラグが１であるものについては、別途「即時処理用のフォルダ」へ移動させて、特に急ぎの案件として処理されるものであるため、本処理対象から外すものである。

出願予定日が本日である案件（及び出願完了≠１、終了≠１、即時≠１）については、Ｓ１４０４に移行し、出願ファイル管理テーブル１１１２３（図２９）の出願ファイルアドレスと、リンクファイルアドレスを取得する。続くＳ１４０５では当該取得したアドレス情報に基づいて、全ての該当ファイル（出願用のＨＴＭＬファイル、及び、技術情報ファイルに基づく画像ファイル若しくはＰＤＦファイル）を出願用ＨＴＭＬＤＢ１１２から取得し、管理者ＰＣ１１３の記憶部内の当日処理用のフォルダへコピーする。なお、当該処理においては、出願用ファイル作成支援サーバ１１１の記憶装置１１１２に格納されている「ダミー.jpg」（ひな形の図１として予め設定められている画像ファイル）についても当日処理用のフォルダへコピーする。また、出願ファイル管理テーブル１１１２３の当日フラグを１とする。なお、「当日処理用のフォルダ」については、管理者によって予め設定されるフォルダであり、管理者設定情報テーブル１１１２２（図２８）に設定情報が格納されている。

出願ファイル管理テーブル１１１２３の全てのレコードに対するＳ１４０２〜Ｓ１４０５の処理の実行が終了した場合にはループ処理を終了し、管理者に当日出願案件の整理番号を（複数ある場合にはリストとして一括して）メールして、当日ファイル移動・通知処理を終了する。この当日ファイル移動・通知処理により、当日出願する予定のファイルが全て所定のフォルダ（当日処理用のフォルダ）に格納されるため、管理者（出願処理担当者）は、いつも当該フォルダに基づいて出願ソフトから手続を行うだけで済む。なお、本実施形態では、全ての案件のファイルをそのまま同一フォルダに格納するものとしているが、「当日処理用のフォルダ」の中に、例えば出願整理番号をフォルダ名とする各フォルダを自動生成し、それぞれ該当するフォルダに該当案件のファイルを格納するような処理としてもよい。また、Ｓ１４０３の判別処理において「出願日＝今日」という条件を「出願日が今日以前」という条件にすることによって、出願予定日を経過しているが、まだ出願が終了していない案件についても、「当日処理用のフォルダ」にファイルが移動されるようにしてもよい。

当日ファイル移動・通知処理（図４：Ｓ４１４）の終了後、取下げ管理の設定がされている場合には、取下げ確認・通知処理へ移行する（Ｓ４１５Ｙｅｓ→Ｓ４１６）。

＜＜取下げ確認・通知処理：図４のＳ４１６の処理の詳細＞＞
取下げ確認・通知処理は、出願後予め設定されている期間が経過した案件について、取下げ時期の到来を管理者に通知し、出願取下書を自動生成する処理である。図１５は当該処理動作を示すフローチャートである。

出願用ファイル作成支援サーバ１１１の記憶装置１１１２には、図４３（ａ）に示されるような出願取下書ＨＴＭＬひな形ファイル（テキストファイル）が格納されている。本実施形態における出願取下書ＨＴＭＬひな形ファイルでは、出願人情報として自己の機関の識別番号、名称、代表者の情報が予め記載されている。

取下げ確認・通知処理（図１５）では、出願ファイル管理テーブル１１１２３の全レコードのそれぞれに対してＳ１５０１〜Ｓ１５０５の処理を行うためのループ処理が実行される。

Ｓ１５０１では、取下フラグが１であるか否か、又は、終了フラグが１であるか否かを判別し、いずれかが１である場合にはＳ１５０２〜Ｓ１５０５の処理をスキップして、処理対象を次のレコードとする。既に取下済みの案件（取下フラグ＝１）や、出願管理を終了した案件（終了フラグ＝１）については、処理対象から外している処理となる。Ｓ１５０１に続くＳ１５０２では、出願済みの案件（出願完了フラグ＝１）であって、且つ、出願日からの所定期間が経過した日（取下げ通知時期：本実施形態では１４月を例としている）が本日である案件を判別し、これに該当しない場合は、Ｓ１５０３〜Ｓ１５０５の処理をスキップして、処理対象を次のレコードとする。なお、取下げの時期を決める「取下げ通知時期」については、管理者によって予め設定され、管理者設定情報テーブル１１１２２（図２８）に格納されている情報である。

出願日から所定期間が経過した日が本日である案件（及び出願完了＝１、終了≠１、取下≠１）については、Ｓ１５０３に移行し、出願用ファイル作成支援サーバ１１１の記憶装置１１１２から出願取下書ＨＴＭＬひな形ファイル（図４３（ａ））を取得する。図１５のフローチャートの隣には、出願取下書ＨＴＭＬひな形ファイルの内容のうちの該当部分を示しており、１がひな形そのものである。

Ｓ１５０４では、当該ひな形ファイルの内容に対して、整理番号の項目の続く位置に出願整理番号（ループ処理の中で当該処理対象となっているレコードの出願整理番号）の後に「ＷＤ」を付加したものを挿入する。例えば、出願整理番号が「Ｅ２０１３−００１」である場合には、「Ｅ２０１３−００１ＷＤ」という整理番号が付与されてこれが挿入される。また、出願番号の項目に続く位置に、出願番号（処理対象となっているレコードから取得）を挿入する。２が挿入後の該当部分を示すものとなる。

Ｓ１５０４によって自動生成された出願取下書のＨＴＭＬファイルを、出願整理番号に「ＷＤ」を付加したもの（Ｓ１５０４で付加する整理番号と同じもの）をファイル名として、管理者ＰＣ１１３の記憶部内の取下フォルダに格納し、出願ファイル管理テーブル１１１２３の取下フラグを１にする（Ｓ１５０５）。なお、「取下フォルダ」については、管理者によって予め設定され、管理者設定情報テーブル１１１２２（図２８）に設定情報が格納されている。

出願ファイル管理テーブル１１１２３の全てのレコードに対するＳ１５０１〜Ｓ１５０５の処理の実行が終了した場合にはループ処理を終了し、管理者に取下フラグ＝１＆終了フラグ≠１の案件の出願整理番号を（複数ある場合にはリストとして一括して）メールして、取下げ確認・通知処理を終了する。当該処理により、出願済みの案件であって、所定期間が経過したものについて、取下げに関する通知と、出願取下書の自動生成処理が行われる。当該通知を受けた管理者（出願処理担当者）は、必要に応じて（必ずしもすべての案件を取下げることを前提とするものではない）、取下フォルダに格納されているファイルに基づいて出願ソフトから手続を行うことができる。

次に、時刻が「チェック時刻」になった場合に実行される手続終了確認処理（図４：Ｓ４０３→Ｓ４１３）について説明する。当該処理は、処理すべき手続き（論文緊急出願の出願手続きなど）が実行されたか否かを確認する処理となる。

＜＜手続終了確認処理：図４のＳ４１３の処理の詳細＞＞
本実施形態における手続終了確認処理は、出願ソフトから出力されたリスト（ＣＳＶファイル）を検索し、手続が行われたことを示す情報の有無を確認し、手続が行われた形跡が無い場合に管理者に通知するものである。即ち、本実施形態においては、当該処理の前提として、管理者が出願ソフトによってＣＳＶファイル出力（本実施形態ではＣＳＶ形式を例としているが、これに限らない。）の操作を行い、所定の場所（管理者により設定され、管理者設定情報テーブル１１１２２（図２８）に格納されている）に所定のファイル名で保存してあるものとする（本実施形態では、出願用ファイル作成支援サーバ１１１の記憶装置１１１２に、「JPOLIST.csv」というファイル名（出願ソフトのデフォルトの出力ファイル名）で保存されるものとする）。運用上は、毎日所定の時間（例えば１７時）に出願などのその日の分の手続き処理を行い、当該処理後に、出願ソフトによってＣＳＶファイル出力の操作を行うことなどが想定される。よって、「チェック時刻」は、当該ＣＳＶファイル出力の操作が終了している時刻で設定されるものである。図１６は、本処理の動作を示すフローチャートである。

Ｓ１６０１〜Ｓ１６０４の処理は、それぞれ、当日出願すべき案件の出願手続きがされているか否かを確認する処理（Ｓ１６０１）、即時に出願すべき案件の出願手続きがされているか否かを確認する処理（Ｓ１６０２）、取下手続きがされているか否かを確認する処理（Ｓ１６０４）である。

＜＜＜当日出願案件、手続終了確認処理：図１６のＳ１６０１の処理の詳細＞＞＞
図１７は、図１６のＳ１６０１で実行される当日出願案件、手続終了確認処理の動作を示すフローチャートである。Ｓ１７０１では、初期化処理として当日未処理テーブルの内容をクリアする。当日未処理テーブルは、該当案件（当日未処理案件）の出願整理番号が格納されるテーブルである。

Ｓ１７０１に続くループ処理は、出願ファイル管理テーブル１１１２３の全レコードのそれぞれに対してＳ１７０２〜Ｓ１７０７の処理を行うものである。

Ｓ１７０２では、当日フラグが１であって、且つ、出願完了フラグが１ではない案件であるか否かを判別し、これに該当しない場合にはＳ１７０３〜Ｓ１７０７の処理をスキップして、処理対象を次のレコードとする。一方、当日フラグ＝１且つ出願完了フラグ≠１に該当する案件（即ち、当日出願案件であって、出願完了の情報が登録されていない案件）であった場合には、Ｓ１７０３に移行する。Ｓ１７０３及びＳ１７０４では、出願整理番号（ループ処理中で処理対象となっているレコードの出願整理番号）をキーとして、出願用ファイル作成支援サーバ１１１の記憶装置１１１２にある「JPOLIST.csv」ファイルの内容を検索し、該当レコードの有無及び、該当レコードがあった場合に、提出日情報があるか否かを判別する。

出願整理番号に該当するレコードが無い若しくはレコードに提出日情報が格納されていない場合には、Ｓ１７０７へと移行し、当日未処理テーブルに出願整理番号を追加して、出願ファイル管理テーブル１１１２３の警告フラグを１とし、処理対象を次のレコードとする。一方、Ｓ１７０４での判別の結果、出願整理番号に該当するレコードがあり且つ提出日情報があった場合には、Ｓ１７０５へ移行し、「JPOLIST.csv」ファイルから該当する提出日及び出願番号を取得し、これらの取得情報を出願ファイル管理テーブル１１１２３に登録し、出願完了フラグを１に更新する。続くＳ１７０６では、出願整理番号に基づいて、当日処理用フォルダ内の該当ファイルを全て削除する処理を行い、処理対象を次のレコードとする。当該削除処理により、既に出願済みであることが確認された案件については、当日処理用フォルダからファイルが削除されるため、管理者が後で手続き忘れ案件について手続きを行うために“当日フォルダ”を参照した際に、余計なファイル（処理済み案件）が表示されず、作業効率が向上されるものである。

出願ファイル管理テーブル１１１２３の全レコードのそれぞれに対してＳ１７０２〜Ｓ１７０７の処理が終了した際には、ループ処理を終了し、当日未処理テーブル（即ち、「JPOLIST.csv」ファイルに、対応するレコードが無い若しくはレコードに提出日情報が格納されていない案件の、出願整理番号のリスト）を戻り値として、当日出願案件、手続終了確認処理を終了する。

当日出願案件、手続終了確認処理（図１６：Ｓ１６０１）に続いて、即時出願案件、手続終了確認処理が実行される（Ｓ１６０２）。

＜＜＜即時出願案件、手続終了確認処理：図１６のＳ１６０２の処理の詳細＞＞＞
図１８は、図１６のＳ１６０２で実行される即時出願案件、手続終了確認処理の動作を示すフローチャートである。Ｓ１８０１では、初期化処理として即時未処理テーブルの内容をクリアする。即時未処理テーブルは、当日未処理テーブルと同様に、該当案件（未処理案件）の出願整理番号が格納されるテーブルである。

即時出願案件、手続終了確認処理（図１８）は、当日出願案件、手続終了確認処理（図１７）と同様の処理概念である（当日処理案件であるか、即時処理案件であるかの点で相違するが処理概念としては同一である）ので、ここでの説明を省略する。なお、Ｓ１８０７での処理では、警告フラグが２とされる。当日出願案件、手続終了確認処理と同様に、本処理によって、即時未処理テーブルが戻り値として得られる（Ｓ１８０８）。

即時出願案件、手続終了確認処理（図１６：Ｓ１６０２）に続いて、取下げ管理フラグが１であるか否かが判別され（Ｓ１６０３）、１である場合には取下案件、手続終了確認処理が実行され（Ｓ１６０４）、１でない場合には、Ｓ１６０４がスキップされる。取下げ管理の設定がされていない場合には、は取下案件、手続終了確認処理をスキップするものである。

＜＜＜取下案件、手続終了確認処理：図１６のＳ１６０４の処理の詳細＞＞＞
図１９は、図１６のＳ１６０４で実行される取下案件、手続終了確認処理の動作を示すフローチャートである。Ｓ１９０１では、初期化処理として取下未処理テーブルの内容をクリアする。取下未処理テーブルは、当日未処理テーブルと同様に、該当案件（未処理案件）の出願整理番号が格納されるテーブルである。

取下案件、手続終了確認処理（図１９）は、当日出願案件、手続終了確認処理（図１７）と基本的に同様の処理概念であるので、ここでの説明は相違部分のみとし、同様の処理については説明を省略する。

Ｓ１９０２では、取下フラグが１であって且つ終了フラグが１で無い案件（即ち、取下対象案件であって、終了になっていない案件）を処理対象としている。Ｓ１９０３及びＳ１９０４では、出願番号をキーに「JPOLIST.csv」ファイルを検索し、手続名が「出願取下書」であって、提出日情報があるか否かを検索する。Ｓ１９０５では、提出日を取得して、これを出願ファイル管理テーブル１１１２３の取下日に登録し、終了フラグを１とする。なお、Ｓ１９０７での処理では、警告フラグが３とされる。当日出願案件、手続終了確認処理と同様に、本処理によって、取下未処理テーブルが戻り値として得られる（Ｓ１
９０８）。

取下案件、手続終了確認処理（図１６：Ｓ１６０４）に続いて、上記の各処理（当日出願案件、手続終了確認処理（Ｓ１６０１）、即時出願案件、手続終了確認処理（Ｓ１６０２）、取下案件、手続終了確認処理（図１６：Ｓ１６０４））によって戻り値として得られる各テーブル（当日未処理テーブル、即時未処理テーブル、取下未処理テーブル）に、データがあるか否か（即ち、未処理案件があるか否か）を判別し（Ｓ１６０５）、未処理案件が無い場合には手続終了確認処理を終了する。一方、未処理案件がある場合には、全ての未処理案件をリストにしたメールを管理者に送信し、手続終了確認処理を終了する。なお、本実施形態では、即時出願案件、手続終了確認処理についても、他の処理（Ｓ１６０１、Ｓ１６０４）と同頻度で実行されるものを例として説明しているが、即時出願案件、手続終了確認処理はより高頻度で実行させるようにしてもよい。即時処理はより迅速な処理が要求されるため、手続き済みであるか否かの確認もより高頻度で行わせる趣旨による。ただし、これを有効な処理とするためには、管理者による出願ソフトのファイル出力操作もそれに応じた頻度で行われる必要がある（本実施形態では、出願ソフトとのプログラム上の連携が無いものを例としているが、プログラム上の連携がある場合にはこの限りでない）。

次に、管理者権限で操作可能な管理者サイトによる本システムに関する各種設定や、各案件の確認や情報入力などを行わせる処理について説明する。当該処理は、管理者が管理者ＰＣ１１３を利用するなどして、出願用ファイル作成支援サーバ１１１にアクセスして行われる処理（Ｗｅｂブラウザを利用して管理者サイトにアクセスし情報入力などをするもの）である。以下では、主に出願用ファイル作成支援サーバ１１１側の処理について説明する（Ｗｅｂブラウザを利用して出願用ファイル作成支援サーバ１１１と情報の送受信を行う概念は、図５、図６の処理概念と同様であるため、ここでは管理者ＰＣ側の処理説明を省略する）。

＜＜管理者操作処理：図４のＳ４１７の処理の詳細＞＞
所定の管理者権限でのログイン操作（図４：Ｓ４０４のアクセス要求）により、管理者操作処理（Ｓ４１７）が実行される。当該処理は、管理者による初期設定や、共同出願案件の承認処理、案件の削除、システムで手続済みであることを自動認識できなかった案件についての確認処理などを行うものである。図２０は、本処理の全体動作を示すフローチャートである。

先ずは、管理者サイトのトップ画面を生成するための管理者トップ画面生成処理が実行される（Ｓ２００１）。

＜＜＜管理者トップ画面生成処理：図２０のＳ２００１の処理の詳細＞＞＞
管理者トップ画面生成処理は、管理者用のトップ画面（図３３がその画面例）を生成する処理である。本実施形態のトップ画面では、手続期間が経過したが出願済みであることを示す情報が得られなかったような、警告案件（図１６の処理によって警告フラグが設定されている案件）がリスト表示されるものである。図２１は、本処理の動作を示すフローチャートである。

Ｓ２１０１では、初期化処理として警告案件テーブルの内容をクリアする。警告案件テーブルは、図３３に示されるトップ画面中における警告案件リストの情報が格納されるテーブルである。即ち、出願整理番号、受付番号、手続予定日、出願日、出願番号、警告内容の情報が対応付けられて格納されるテーブルである。

Ｓ２１０１に続くループ１は、出願ファイル管理テーブル１１１２３の全レコードのそれぞれに対してＳ２１０２〜Ｓ２１０３の処理を行うものである。Ｓ２１０２では、即時フラグが１であって、且つ、出願完了フラグが１ではない案件であるか否かを判別し、これに該当しない場合にはＳ２１０３の処理をスキップして、処理対象を次のレコードとする。一方、即時フラグ＝１且つ出願完了フラグ≠１に該当する案件（即ち、即時出願案件であって、出願完了の情報が登録されていない案件）であった場合には、Ｓ２１０３に移行する。Ｓ２１０３では、出願整理番号（ループ処理中で処理対象となっているレコードの出願整理番号）をキーとして、出願ファイル管理テーブル１１１２３から、出願整理番号、受付番号、出願予定日、出願日、出願番号、の情報を取得し、警告内容を“即時出願案件”として、これらをそれぞれ警告案件テーブルに格納する。なお、警告案件テーブルの手続予定日には、出願予定日の情報が格納される。また、必ずしも全ての情報が出願ファイル管理テーブル１１１２３に存在する訳ではないため、情報が無い場合には“−”とする。出願ファイル管理テーブル１１１２３の全レコードのそれぞれに対してＳ２１０２〜Ｓ２１０３の処理が終了した際には、ループ１の処理を終了する。ループ１の処理は、即時出願案件であるが出願完了の情報が登録されていない案件を、出願ファイル管理テーブル１１１２３から抽出し、これを警告案件テーブルに格納するものである。

続くループ２は、基本的な処理はループ１と同様のものであり、警告フラグが１で且つ出願完了フラグ≠１に該当する案件（即ち、出願予定日に出願完了が確認されなかった案件（図１７の処理による）であって、且つ、その後も出願完了の情報が登録されていない案件）を出願ファイル管理テーブル１１１２３から抽出し、これを警告案件テーブルに追加格納するものである。なお、警告内容については“出願予定日を経過”として、警告案件テーブルに格納する。

続くループ３についても、基本的な処理はループ１や２と同様のものであり、警告フラグが３で且つ終了フラグ≠１に該当する案件（即ち、取下予定日に手続完了が確認されなかった案件（図１９の処理による）であって、且つ、その後も終了の情報が登録されていない案件）を出願ファイル管理テーブル１１１２３から抽出し、これを警告案件テーブルに追加格納するものである。なお、手続予定日については「出願日に所定期間（本実施形態では１４月を例としている）を加えた日（図１５のＳ１５０２と同様）」を格納し、警告内容については“取下予定日を経過”として、警告案件テーブルに格納する。

上記のループ１〜ループ３の処理により、警告案件テーブルには、先ず「即時出願案件であるが、出願手続き完了が確認されていない案件」がリストされ、続いて、「出願予定日を経過し、出願手続き完了が確認されていない案件」、「取下げ予定日が経過し、手続き完了が確認されていない案件」がリストされることとなる。各ループ処理終了後のＳ２１０８では、当該警告案件テーブルに基づいてトップ画面（図３３）を生成し、管理者トップ画面生成処理を終了する（当該画面が管理者権限でのログイン操作が行われたＰＣ（例えば管理者ＰＣ１１３）に送信されるものである。以下においても同様である）。なお、Ｓ２１０２の判別で、警告フラグ（警告フラグが２であるか否か）を判別対象とせず、即時フラグによって判別しているのは、本実施形態では、即時出願案件に関する警告フラグの付与処理（図１８）がチェック時刻にしか実行されないため（図４：Ｓ４０３→Ｓ４１３）、警告フラグが付与されていない即時出願案件がある可能性があるためである。即時出願案件は、可及的速やかな処理が求められるものであるため、システムで受け付けた案件については、警告フラグがまだ付与されていないものについてもトップ画面の警告案件リストに上がってくるようにしているものである。

図２０に戻って説明を続ける。Ｓ２００１の管理者トップ画面生成処理（図２１）に続くＳ２００２〜Ｓ２００５は、管理者トップ画面（図３３）に対する入力待ちのループとなっており、入力（管理者の操作に基づくＰＣからの指示情報）に応じて、これに対応する処理が実行されることとなる。

管理者トップ画面（図３３）の左欄にある「承認処理」は、発明者に従業者でない（雇用関係にない者）が含まれている場合に、管理者が相手機関等への確認をして（論文緊急出願を行うことの承諾を得て）、本システムによる出願ファイルの自動生成処理の実行を承認するものである。当該「承認処理」が選択された場合には、Ｓ２００６へと移行して管理者承認処理を実行する（Ｓ２００２）。

＜＜＜管理者承認処理：図２０のＳ２００６の処理の詳細＞＞＞
図２２は、管理者承認処理の動作を示すフローチャートである。Ｓ２２０１では、初期化処理として承認案件テーブルをクリアする。承認案件テーブルは、図３６に示される承認処理画面中における承認案件リストの情報が格納されるテーブルである。即ち、受付番号、申請者、雇用関係の無い発明者の所属、公開予定日の各情報が対応付けられて格納されるテーブルである。

Ｓ２２０１に続くループ処理は、申請案件テーブル１１１２１（図２５）の全レコードのそれぞれに対してＳ２２０２〜Ｓ２２０３の処理を行うものである。Ｓ２２０２では、承認要フラグが１であって生成済フラグが１ではない案件か否かを判別し、これに該当しない場合にはＳ２２０３の処理をスキップして、処理対象を次のレコードとする。一方、承認要フラグ＝１且つ生成済フラグ≠１の案件（即ち、発明者（若しくは申請者）に雇用関係が無い者が含まれている案件であって、まだＨＴＭＬファイルの生成処理がされていない案件）であった場合には、Ｓ２２０３に移行する。Ｓ２２０３では、受付番号（ループ処理中で処理対象となっているレコードの受付番号）をキーとして、申請案件テーブル１１１２１から、受付番号、申請者ＩＤ、発明者ＩＤ、公開予定日の情報を取得する。さらに、申請者ＩＤや発明者ＩＤに基づいて、職員テーブル（図２６）若しくは仮ユーザ登録テーブル（図２７）を参照して、申請者の氏名情報と、雇用関係の無い発明者の所属情報を取得する。「雇用関係の無い発明者」は即ち、ＩＤが“Ｔ”から始まるもの（仮のユーザＩＤ）であり、雇用フラグが０である者であるので、これに該当する者の所属情報を仮ユーザ登録テーブルから取得するものである。これらにより、受付番号、申請者、雇用関係の無い発明者の所属、公開予定日の情報が取得され、これらをそれぞれ承認案件テーブルに格納する。申請案件テーブル１１１２１の全レコードのそれぞれに対してＳ２２０２〜Ｓ２２０３の処理が終了した際には、ループ処理を終了する。当該ループ処理は、発明者（若しくは申請者）に雇用関係が無い者が含まれている案件であってまだＨＴＭＬファイルの生成処理がされていない案件を、申請案件テーブル１１１２１から抽出し、これを承認案件テーブルに格納するものである。

ループ処理終了後のＳ２２０４では、当該承認案件テーブルに基づいて承認処理画面（図３６）を生成する。続くＳ２２０５・Ｓ２２１２は、承認処理画面（図３６）に対する入力待ちのループとなっており、入力（管理者の操作に基づくＰＣからの指示情報）に応じて、これに対応する処理が実行されることとなる。

承認処理画面（図３６）に対して、承認案件リストの各案件に対応する「確認ボタン」が選択された場合には、個別承認処理画面（図３７）を生成する（Ｓ２２０５→Ｓ２２０６）。当該画面構成に必要な情報は、受付番号をキーとして、申請案件テーブル１１１２１から（さらに、職員テーブル（図２６）若しくは仮ユーザ登録テーブル（図２７）を参照して）取得するものである。管理者は、当該個別承認処理画面（図３７）において、学外発明者の住所と、共同出願人（学外発明者個人若しくはこれが属する機関）に関する情報である識別番号または住所、名称、代表者名の情報（願書の記載に必要な情報）を入力し、ＯＫであれば「承認ボタン」を押す。なお、何らかの不都合があったような場合は「キャンセルボタン」を選択する。

続くＳ２２０７では、個別承認処理画面（図３７）に対する、「承認ボタン」又は「キャンセルボタン」の入力を待ち、キャンセルであった場合には、Ｓ２２０４へ戻って処理を続行する。一方、承認であった場合には、Ｓ２２０８へ移行して、ＨＴＭＬファイル自動生成保存処理を実行する。

Ｓ２２０８で実行されるＨＴＭＬファイル自動生成保存処理は図８の処理と同様のものであるが、その中の願書部作成処理（図８：Ｓ８０５）の処理では、図２４の処理が実行される。よってここでは、図２４の願書部作成処理についてのみ説明を行う。なお、図２４の処理中、図９と同様の処理については同一の符号を使用し、ここでの説明を省略する。

Ｓ９０１で、出願用ファイル作成支援サーバ１１１の記憶装置１１１２に格納されている明細書ＨＴＭＬひな形ファイル（図３９）を取得した後の、Ｓ２４０１では、個別承認処理画面（図３７）において出願人情報が得られているか否か（即ち共同出願人があるか否か）を判別し、これが無い場合には続くループ処理をスキップする。一方、共同出願人がある場合には、ループ処理を実行する。

Ｓ２４０１に続くループ処理は、共同出願人の数だけ処理を繰り返すものであり、個別承認処理画面（図３７）において得られた各共同出願人の情報に対してＳ２４０２の処理を行うものである。Ｓ２４０２では、個別承認処理画面（図３７）において得られた共同出願人の情報に基づいて、図２４のＳ２４０２の中の「挿入する３行」を生成し（“取得情報”の部分を置き換える）、当該３行を、明細書HTML雛形ファイル中の、「手数料の表示」の項目の前の位置で改行して挿入する。当該処理が、全ての共同出願人に対して処理されたらループ処理を終了する。これにより、願書の「特許出願人」の項目が完成する。

ループ処理の後は、Ｓ９０２へ移行して図９と同様の処理となるが、Ｓ９０３の発明者の項目の挿入処理では、雇用関係の無い発明者の住所については、個別承認処理画面（図３７）において得られた情報で置き換えたものも使用されることになる。

上記処理（図２２：Ｓ２２０８）により、共同出願人情報及び学外発明者情報が付加された上で、出願用のＨＴＭＬファイルが自動生成され、出願用ＨＴＭＬＤＢ１１２に格納される。当該処理後の、Ｓ２２０９〜Ｓ２２１０の処理は、図４のＳ４０９→Ｓ４１１の処理と同様であるためここでの説明を省略する。Ｓ２２０９〜Ｓ２２１０の処理後は、Ｓ２２０１に戻って処理を続ける。これにより承認案件テーブルの生成から処理が繰り返されることとなるが、一度承認された案件については、Ｓ２２０８のＨＴＭＬファイル自動生成保存処理によって生成済フラグが１とされる（図８：Ｓ８０８）ため、Ｓ２２０２の判別がＮｏとなり、次回の承認処理画面（図３６）では表示されない。

承認処理画面（図３６）に対して、承認案件リストの各案件に対応する「削除ボタン」が選択された場合には、申請案件テーブル１１１２１の承認要フラグを０にして（Ｓ２２０５→Ｓ２２１１）、Ｓ２２０１に戻って処理を続ける。削除は、外部発明者やこれが所属する機関からの論文緊急出願に対する承諾が得られなかったような場合などに、本システムでの処理を中止させるためのものである。承認要フラグが０とされてＳ２２０１に戻るため、Ｓ２２０２の判別がＮｏとなり、次回の承認処理画面（図３６）では表示されない。これにより、当該案件に対してはＨＴＭＬファイル自動生成保存処理が行われることはない。なお、本システムでの出願を行わない案件についてはデータを削除（各テーブルからのデータの削除や、技術情報ファイルの削除）を行うものであってもよいが、本実施形態では、キーワードなどによって論文等のファイルを検索可能なＤＢを構成することも一つの目的としているため、本システムへの申請があった案件については、情報を残す処理としている。

承認処理画面（図３６）に対して、同画面の左欄の「トップ」又は「設定」の選択（各ページへの移動要求）があった場合には（Ｓ２２０５・Ｓ２２１２における入力待ちループ）、Ｓ２２１３へと移行し、「トップ」又は「設定」の情報を戻り値として、管理者承認処理を終了する。

当該管理者承認処理の一連の処理から明らかなように、外部発明者がいる案件については、管理者が別途外部発明者やこれが所属する機関に対して確認を行い、当該確認結果に基づいてシステムに承認情報を入力することで、出願用ＨＴＭＬファイルの自動生成処理が実行される（若しくは実行されなくなる）ものである。なお、外部発明者がいても必ずしも共同出願人がいるとは限らない（特許を受ける権利の譲渡を受けて単独出願となることもあり得る）ため、個別承認処理画面（図３７）における出願人情報は必須の入力事項ではない。

図２０に戻って説明を続ける。管理者承認処理（Ｓ２００６）によって戻り値として、「トップ」又は「設定」が得られるため（図２２：Ｓ２２１３）、これの何れが得られたかを判別し（Ｓ２００７）、「トップ」であった場合（即ちトップページの表示要求である場合）には、Ｓ２００１へと戻って処理を継続する（即ちトップページが表示される）。一方、「設定」であった場合には、管理者設定画面を表示させる（Ｓ２００７→Ｓ２００８）。図３８は、当該管理者設定画面の一例を示す図である。当該画面は、本システムに関する各種の設定を行うための画面であり、設定事項としては、「当日ファイル移動時刻（図４：Ｓ４０３の処理に関係）」、「チェック時刻（図４：Ｓ４０３の処理に関係）」、「猶予日数（出願予定日の算出等に使用）」、「基準期間（図６：Ｓ６０９の処理に関係）」、「申請ファイル保存フォルダ（受付処理によって得られるファイルの保存場所）」、「ＨＴＭＬファイル保存フォルダ（自動生成されたＨＴＭＬファイルや画像ファイルの保存場所）」、「即時処理用フォルダ（即時処理案件の出願用のＨＴＭＬファイルや画像ファイルの一時保存場所）」、「当日処理用フォルダ（当日処理する案件の出願用のＨＴＭＬファイルや画像ファイルの一時保存場所）」、「取下管理（図４：Ｓ４１５等の処理に関係）」、「取下通知時期（図１５：Ｓ１５０２の処理に関係）」、「取下用フォルダ（取下案件の手続用のＨＴＭＬファイルの一時保存場所）」、「出願ソフトＣＳＶ出力フォルダ（出願ソフトに出力させるＣＳＶファイルの保存場所）」の各情報となる。

管理者は当該管理者設定画面に対して各種の情報を入力し、必要情報の入力が終了したら、「登録」ボタンを選択する。当該登録ボタンの選択により、入力された各情報が送信され、当該情報を受信した出願用ファイル作成支援サーバ１１１では、これを管理者設定情報テーブル１１１２２に格納する処理を行う（Ｓ２００９→Ｓ２０１０）。図２８は、管理者設定情報テーブル１１１２２の構成の一例を示す図である。Ｓ２０１０の後は、Ｓ２００２へと戻って処理を継続（管理者設定処理移行前の管理者トップ画面に戻って処理を続行）する。管理者設定画面において「キャンセル」ボタンが選択された場合には、Ｓ２０１０をスキップしてＳ２００２へと戻って処理を継続（管理者設定処理移行前の管理者トップ画面に戻って処理を続行）する。

Ｓ２００２〜Ｓ２００５の、管理者トップ画面（図３３）に対する入力待ちのループにおいて、画面の左欄の「設定」が選択された場合（Ｓ２００３）も、Ｓ２００８へと移行して、上記と同様に管理者による設定情報の入力とこれを管理者設定情報テーブル１１１２２に格納する処理が実行される。なお、管理者設定画面（図３８）の生成処理（Ｓ２００８）では、既に管理者設定情報テーブル１１１２２に設定情報がある場合には、当該情報が入力された状態の画面を生成するようにする。

Ｓ２００２〜Ｓ２００５の、管理者トップ画面（図３３）に対する入力待ちのループにおいて、表示されている案件（警告案件）に対応する「処理済」ボタンが選択された場合には、当該案件の出願整理番号を引数として処理済案件登録処理が実行される（Ｓ２００４→Ｓ２０１１）。

＜＜＜処理済案件登録処理：図２０のＳ２０１１の処理の詳細＞＞＞
処理済案件登録処理は、システムで手続済みであることを自動認識できなかった案件についての確認処理（管理者が手続き済みと確認した案件について当該情報をシステムに入力する処理）である。管理者トップ画面（図３３）で表示されている警告案件リストにおいて、手続き済みと確認した案件について「処理済」ボタンを選択し、必要情報を入力することにより、手続済みであることを登録するものである。図２３は、処理済案件登録処理の動作を示すフローチャートである。

Ｓ２３０１では、引数として得た出願整理番号に基づいて出願ファイル管理テーブル１１１２３を参照して警告フラグを取得し、これを判別する。警告フラグが１又は２（即ち、出願予定を経過している案件）であった場合には、Ｓ２３１０へ移行して、図３４に示されるような出願情報入力画面を生成する。（なお、警告フラグが無かった場合もＳ２３０１からＳ２３１０へ移行する。即時処理案件については警告フラグが付与されていない場合があるためである。）出願情報入力画面の生成は、出願ファイル管理テーブル１１１２３の情報及び、申請案件テーブル１１１２１、職員テーブル（及び仮ユーザ登録テーブル）の各テーブルから情報を所得して行う。管理者は当該出願情報入力画面（図３４）に対して、出願日と出願番号情報を入力し、「登録」ボタンを選択する。これにより、入力された出願日と出願番号情報が出願用ファイル作成支援サーバ１１１へと送信され、これを受信した出願用ファイル作成支援サーバ１１１では、これらを出願ファイル管理テーブル１１１２３に格納し、出願完了フラグを１とする（Ｓ２３１１→Ｓ２３１２）。

Ｓ２３１２の登録処理が終わったら、Ｓ２３０９へと移行して、「登録」を戻り値として処理済案件登録処理を終了する。出願情報入力画面（図３４）に対して、「キャンセル」ボタンが選択された場合は、「キャンセル」を戻り値として処理済案件登録処理を終了する（Ｓ２３１１→Ｓ２３１３）。

Ｓ２３０１における判別の結果、警告フラグが３（即ち、取下期間を経過した案件）であった場合には、Ｓ２３０２へ移行して、図３５に示されるような取下情報入力画面を生成する。取下情報入力画面の生成も、出願ファイル管理テーブル１１１２３の情報及び、申請案件テーブル１１１２１、職員テーブル（及び仮ユーザ登録テーブル）の各テーブルから情報を所得して行う。管理者は取下出願情報入力画面（図３５）に対して、取下日、又は、当該案件に基づく優先権主張出願番号情報と出願日情報を入力し、「登録」ボタンを選択する。

「登録」ボタンの選択により入力情報が出願用ファイル作成支援サーバ１１１へと送信され、これを受信した出願用ファイル作成支援サーバ１１１では、優先権出願に関する情報があるか否かを判別する（Ｓ２３０３→Ｓ２３０４）。これがあった場合には、当該優先権出願が国内優先権主張出願又はＰＣＴ出願（日本指定によるみなし国内優先出願となる案件が対象）であるか否かを判別し（Ｓ２３０５）、国内優先となる案件である場合には、国内優先権出願番号（or 日本を指定に含むＰＣＴ出願の出願番号）及び出願日情報を出願ファイル管理テーブル１１１２３に登録し（図２９では、優先権主張出願に関する情報を入力する欄を省略）、国内優先フラグ及び終了フラグを１にする（Ｓ２３１４）。国内優先権の基礎とされた出願（論文緊急出願）は１年３月経過後に自動的にみなし取下げとなるため、本システムでの管理を終了とするものである。Ｓ２３１４の後は、Ｓ２３０９へと移行して、「登録」を戻り値として処理済案件登録処理を終了する。

Ｓ２３０５の判別の結果、国内優先となる案件ではなかった場合（単なるパリ優先案件であった場合）、優先権主張出願の出願番号及び出願日情報を出願ファイル管理テーブル１１１２３に登録し（Ｓ２３０６）、取下日情報の入力の有無を判別する（Ｓ２３０７）。取下日情報があった場合には、これを出願ファイル管理テーブル１１１２３に登録し、終了フラグを１にする（Ｓ２３０８）。Ｓ２３０８の後は、Ｓ２３０９へと移行して、「登録」を戻り値として処理済案件登録処理を終了する。一方、取下日情報がなかった場合には、「キャンセル」を戻り値として処理済案件登録処理を終了する（Ｓ２３０７→Ｓ２３１３）。パリ優先では基礎出願（論文緊急出願）のみなし取下げはされないため、別途取下げがされているか否かを確認し、取下情報が無い場合には、引き続き「取下期間を経過した案件」として管理するものである。

Ｓ２３０４の判別の結果、優先権出願に関する情報がなかった場合、Ｓ２３０７へと移行して上記処理を実行する（取下日情報があれば各種情報を登録して「登録」を戻り値に、なければ「キャンセル」を戻り値として処理済案件登録処理を終了する）。また、取下出願情報入力画面（図３５）に対して、「キャンセル」ボタンが選択された場合についても、「キャンセル」を戻り値として処理済案件登録処理を終了する（Ｓ２３０３→Ｓ２３１３）。

以上の処理済案件登録処理によって、「登録」又は「キャンセル」が戻り値として取得される。図２０に戻って説明を続ける。当該処理（図２０：Ｓ２０１１）後の、Ｓ２０１２では、戻り値が「登録」であるか「キャンセル」であるかを判別し、登録であった場合には、Ｓ２００１へと戻って管理者トップ画面を再生成する。一方、キャンセルであった場合には、管理者トップ画面の再生成は行わず、処理済案件登録処理に移行する前の管理者トップ画面に戻って処理を続行する。処理済案件登録処理において、手続き済みであることを示す情報が得られた場合には、当該案件は警告対象ではなくなるため、管理者トップ画面を再生成するのに対して、手続き済み情報が得られなかった場合には、前回の警告案件リストのまま処理を続行させているものである。

管理者トップ画面（図３３）の左欄の「終了」が選択された場合には、管理者操作処理を終了する（Ｓ２００５）。承認処理画面などの他の画面においても、終了ボタンを設けて、これが選択された場合には管理者操作処理を終了するようにしてもよい。なお、管理者トップ画面（図３３）等の、各画面の上部に案件検索欄を設け、ここに入力された情報に該当する案件を、各テーブルを参照することで検索し、当該検索結果を別ウィンドウで表示させる等の案件検索機能を備えさせる等してもよい。

以上、本実施形態の出願支援システムの処理概念について説明した。これらから明らかなように、本実施形態の出願支援システムによれば、例えば大学などの研究機関において、研究者が所定のサイトに論文等の技術情報ファイルをアップロードすることで、当該論文（技術情報ファイル）から特許出願用のHTMLファイルが自動生成され、出願当日に所定のフォルダに自動的に保存されるものである。研究者（発明者）にとっては論文を所定のサイトにアップするだけの作業であり、また、知財部等の担当者においても、所定のフォルダに保存された出願用のHTMLファイルを出願ソフトで出願するだけであるので、発明者及び知財担当者の双方にとって簡便且つ迅速な処理を可能とさせるものである。

また、本実施形態の出願支援システムによれば、各ファイル形式にそれぞれ対応付けられているアプリケーションソフト（例えば拡張子が.docxであるファイルに対する、Microsoft Word（登録商標））を起動し、当該ソフトの印刷機能を利用して印刷出力データを取得し、これに基づいて画像ファイルへの変換処理を実行するため、技術情報ファイル（論文等の電子ファイル）が様々な形式であっても、画一的な処理で明細書の自動生成処理が実行可能となるため、汎用性が高く、利用者にとっての利便性も高い。

さらに、従業者でない発明者（雇用関係にない者）が含まれている場合には、システムでの自動処理について、管理者の承認情報の入力を要件としており、冒認出願の発生を抑止することができる。

さらに、受付処理において、技術情報ファイルがカラーでないと情報が正確に伝わらないものであるか否かの入力を受付け、技術情報ファイルがカラー必須である場合には、出願用ＨＴＭＬファイルの自動生成においてこれを外国語書面として自動生成し、技術情報ファイルをカラーのままＰＤＦファイルで添付するため、情報の欠落が抑止されるものである。

なお、本実施形態では、明細書の発明の名称の項目や、特許請求の範囲の請求項１の内容、要約書の解決手段の部分をひな形のままにしておくものとして説明しているが、受付処理において発明の名称が取得できている場合には、これによって、当該情報で明細書の発明の名称の項目や、特許請求の範囲の請求項１の内容、要約書の解決手段の部分をひな形に対して置き換える処理としてもよい。また、受付処理でより多くの情報（クレーム内容や、要約内容）を入力させることで、これを用いて出願用ＨＴＭＬファイルの自動生成処理に利用するようにしてもよいが、入力情報を多くさせるほど研究者の負担が多くなるため、本システムの本来の目的とのトレードオフが生じることになる。

本実施形態では、特許出願として説明したが、実用新案登録出願についても同様の処理概念にて処理することができる。また、日本の特許出願を前提に説明したが、ＰＣＴ出願として自動生成処理をすることも可能であるし、他の国においても、それぞれの出願制度に対応させて本発明の処理概念を適用することが可能である。

本実施形態では、自動生成した出願用のＨＴＭＬファイルを、一旦すべて同じ場所（出願用ＨＴＭＬＤＢ）に格納し、出願予定日に該当する案件を、当日処理用のフォルダに移動（コピー）するものを例として説明しているが、出願予定日に対応したフォルダ（例えば、日付（「20130101」など）をフォルダ名としたフォルダ）をそれぞれ自動生成又は予め用意し、当該日付フォルダに対して、該当する出願日の案件のファイルを格納するようなものとしてもよい。これにより、管理者は、当日に該当する日付フォルダの中のファイルに基づいて出願手続きを行うこととなる。

本実施形態では、ＨＴＭＬファイルを自動生成する処理（図４：Ｓ４０８）を、受付後にそれぞれ実行するものを例としているが、当該自動生成処理の実行タイミングをこれに限るものではなく、出願予定日（より正確には予定日時）までに実行されるものであればよい。例えば、受付時には当該自動生成処理は行わず、出願予定日において該当する案件のＨＴＭＬファイル自動生成処理を実行させるものや、受付日の夜に当日受付分をバッチ処理するようなものであってもよい（ただし、即時処理案件については、当然即時に処理が行われる必要がある）。

本実施形態では、各ひな形ファイルが、テキストファイルであり、これに対する一部内容の追加や置き換え処理を行った後にＨＴＭＬファイルとして保存（出願用ＨＴＭＬファイルを自動生成）する処理として説明したが、ひな形ファイルをＨＴＭＬファイルとして扱うものであってもよく、また、他の形式のファイルでひな形を用意しておいて、最終的にＨＴＭＬに変換するものであってもよい。

本実施形態では、猶予日数を設定し、公開予定日から猶予日数を引いた日付を出願予定日にするものを例としているが、公開予定日を基準とするのではなく、申請受付日を基準として、出願日を決めるものであっても構わない（ただし、当然の前提として、出願日は公開日より前になるようにする必要がある）。また、受付処理において、公開予定日ではなく、出願予定日の入力を求め、これ基づいて処理するものであってもよい（この場合も公開日より前になるように担保する処理をする必要がある）。

本実施形態では、受付処理において、カラー必須であるか否かの情報の入力を求め、当該入力情報に基づいて、外国語書面にてＨＴＭＬファイルを生成するようにしているが（図８：Ｓ８０４→Ｓ８１０・８１１）、カラー必須であるか否かの情報を申請者から求めるのではなく、技術情報ファイルがカラーであるか否かを自動的に判別し、カラーの資料であった場合には、自動的に外国語書面にてＨＴＭＬファイルを生成するような処理としてもよい。（例えば、本実施形態における「資料個別ページ画像化処理」において得られる印刷出力データに基づいてカラーか否かを判別し、カラーであった場合に、Ｓ８１０・８１１の処理へ移行するなど。）

なお、上記で説明したものと同様の処理概念となるものであれば、ハードの構成の相違等は問題にならない。例えば、ＣＰＵなどと説明しているが、同一のＣＰＵで全てのプログラムを実行することを意味するものではなく、複数のＣＰＵ（或いはＧＰＵなど）によって分散処理されるものであっても構わないし、それらが同じ筐体に入っていなければならないというものでは全くない。上記説明ではソフトウェアで実現される機能の一部若しくは全部をハード的に構成するものであっても構わないし、その逆であっても構わない。
また、各テーブルの構成は説明のための一例であり、上記説明から理解される本発明の概念に沿った形で各情報が関連付けられる（直接または間接的に関連付けられる）ものであればよい（ＤＢとして適宜正規化などがされるのは当然のことである）。以下の実施形態においても同様である。

（実施形態２）
実施形態２の出願支援システムを保有するサービス提供者は、例えば大学などの機関を顧客とし、大学から論文等の技術情報ファイルの送信を受けて、これを論文緊急出願するサービスを提供するものである（即ち、出願代理業を行うものであるので、当該出願支援システムによるサービス提供者は弁理士又は特許業務法人である）。また、同時に他の代理人（特許事務所）も顧客（サービス提供対象）としており、大学が論文緊急出願に関するクレーム案の作成を望む場合には、技術情報ファイルなどの内容を代理人側（サービス提供者ではない他の代理人）に提示し、これを受けた代理人がクレーム案を作成してシステムに登録することにより、顧客（大学等）が当該クレーム案を確認することができるサービスを提供するものである（仲介ビジネス）。論文緊急出願はあくまで新規性喪失を防止するための手続きであり、有用な権利を取るためには通常は優先権主張出願が必要となるため、その出願のための代理人の選別が可能となるものであり、一方、代理人側（サービス提供者ではない他の代理人）にとっても、新たな仕事の依頼を得る機会を取得できるものとなる。さらに、実施形態２の出願支援システムでは、弁理士（若しくは特許技術者）への評価を付与し、これを提供するサービスも可能としている。

図４７は、本実施形態２に係る出願支援システムの概略を示すブロック図である。実施形態１（図１）と同様の構成要素については実施形態１と同一の符号を使用し、ここでの説明を省略する。図に示されるように、業者システム４７０と、顧客となる者（大学等）が使用する情報処理装置である顧客ＰＣ４７９と、もう一方の顧客となる代理人が使用する情報処理装置である特許事務所ＰＣ４７８などが構成要素となる。業者システム４７０には、顧客ファイルＤＢ４７２、出願用ファイル作成支援サーバ４７１などが備えられる。出願用ファイル作成支援サーバ４７１については、ハードとしては実施形態１のものと異なる点は特にないが、機能面では上述のごとく実施形態１のものとは相違する部分があり、以下で説明するように、当該機能を実現するため実施形態１とは異なる各プログラムやテーブル等を有するものとなる。ＣＰＵなどの各ハードウェア資源と各プログラムによって、各機能処理部（ログイン処理部、技術情報ファイル取得部、願書生成部、明細書自動生成部、出願ファイル生成部、ファイル画像化部、技術情報ファイル等提示部、クレーム案取得部、クレーム案提示部、代理人評価情報取得・提示部、出願依頼受付・通知処理部、課金処理部）が構成される点については実施形態１と同様の概念である。

本実施形態においては、大学等及び代理人側の何れについても予め登録された者がサービスの提供対象であり、大学等の論文緊急出願サービスを利用する顧客については、図５９（ａ）に構成例を示したような顧客テーブル５９０１において、ログイン情報となるＩＤやパスワードのほか、機関名である名称、住所、担当者名、連絡先情報（電話番号など）、メールアドレス、口座情報（課金のための情報）、識別番号（特許庁における識別番号）、代表者名などの情報が対応付けられて格納される。代理人側については、事務所としての情報として、事務所テーブル５９０２（図５９（ｂ）に構成例を示す）に、ＩＤ、名称、住所、メールアドレス、電話番号、ＦＡＸ番号、口座情報（課金のための情報）、などの情報が対応付けられて格納される。また、代理人側については、弁理士個人としての情報も登録される。当該情報は、図５９（ｃ）に構成例を示したような弁理士テーブル５９０３において、ログイン情報となるＩＤやパスワードのほか、氏名、メールアドレス、電話番号、ＦＡＸ番号、所属する事務所のＩＤ、対応可能な技術分野に関する情報などの情報が対応付けられて格納される（なお、必ずしも弁理士に限らず、いわゆる特許技術者であってもよい）。顧客テーブル５９０１、事務所テーブル５９０２、弁理士テーブル５９０３は、顧客ファイルＤＢ４７２に格納される。

＜出願用ファイル作成支援サーバ全体処理概略＞
本実施形態の出願用ファイル作成支援サーバ４７１における処理動作の全体の概要を説明し、その後、当該全体処理を構成する各機能処理について順次詳細に説明を行う。図４８は、出願用ファイル作成支援サーバ４７１の全体動作の概略を示すフローチャートであり、これに基づいて出願用ファイル作成支援サーバ４７１の処理動作の概要を説明する。

Ｓ４８０１〜Ｓ４８０３は、イベントの発生待ちのループとなっており、各イベントの発生に応じて、これに対応する処理が実行されることとなる。

本システムによるサービスの提供を行う所定のサイトのログイン画面から本システムに対するログイン要求があった際には（Ｓ４８０１）、論文緊急出願するサービスの提供を受ける大学など（以下単に「顧客」という）からのログイン要求であるか、弁理士個人（又は特許技術者個人）のＩＤによるログイン要求であるかを判別する（Ｓ４８０４）。ログインの認証及びＳ４８０４の判別は、顧客テーブル５９０１（図５９（ａ））、弁理士テーブル５９０３（図５９（ｃ））を参照して行われる（フローチャートでは省略しているが、当然にＩＤとパスワードが合わなかった場合にはログインを拒否する処理となる）。ログイン者が顧客であった場合には、Ｓ４８０５へ移行して「顧客対応サイト処理」を実行し、一方、弁理士であった場合にはＳ４８０６へ移行して「事務所対応サイト処理」を実行する。「顧客対応サイト処理」は、論文緊急出願のサービスなどを顧客に提供するための処理であり、「事務所対応サイト処理」は、弁理士に対して、顧客からクレーム案の作成要求があった案件の提示やこれに対するクレーム案の入力などを行わせるための処理である。

Ｓ４８０１〜Ｓ４８０３のループ処理において、時刻が午前零時になった場合には、「当日案件出願処理」を実行する（Ｓ４８０２→Ｓ４８０７）。「当日案件出願処理」は、出願予定日になった案件（論文緊急出願）の出願処理を実行するものである。実施形態１では、出願ソフトによる出願処理は人手によるものを例として説明したが、本実施形態においては、システムによって自動的に出願ソフトを起動し、出願処理を自動的に行うものを例とする。

Ｓ４８０１〜Ｓ４８０３のループ処理において、時刻が午後１１時になった場合には（Ｓ４８０３）、「取下げ処理（Ｓ４８０８）」、「手続終了通知処理（Ｓ４８０９）」、「課金処理（Ｓ４８１０）」をそれぞれ実行する。「取下げ処理」は、論文緊急出願について顧客から所定期日に取り下げることを依頼されている場合において、取下げ日の到来した案件について取下げ手続きを実行するものである。「手続終了通知処理」は、その日に手続き（出願手続き、取下げ手続き）を行った案件について、手続き完了の通知や手続き書類の送付などを行う処理であり、「課金処理」は当該行った手続きに基づいて顧客又は弁理士に課金を行う処理となる。なお、ここでは、「当日案件出願処理」を午前零時（即ち日付が変わったと同時）に実行し、「取下げ処理」については２３時に実行するものを例としている（出願はなるべく早期に、取下げはなるべく最期にという趣旨による）が、当該処理のタイミングは任意に設定できるものであってよい。

以上が、出願用ファイル作成支援サーバ４７１における処理動作の全体の概要である。以降は、当該全体処理を構成する各機能処理について順次詳細に説明を行う。

＜＜顧客対応サイト処理：図４８のＳ４８０５の処理の詳細＞＞
顧客からのログイン要求があった場合には顧客対応サイト処理が実行される（図４８：Ｓ４８０４→Ｓ４８０５）。図４９は、当該顧客対応サイト処理の処理動作を示すフローチャートである。

先ず、Ｓ４９０１では、図６５に例示したような顧客用のサイト画面を生成する処理を実行する。当該顧客用サイトのトップページは、ログインした顧客から依頼を受けている論文緊急出願案件のリストを提示するものであり、リストの右側に各案件ごとに修正や評価といったボタンが割り当てられる。当該リストの生成（リスト中の「受付番号」、「出願予定日」、「出願日」、「出願番号」、「特許事務所担当者」の取得）については、先ず、申請案件テーブル６００１（図６０）から、申請者ＩＤ（＝ログインＩＤ）に基づいて該当案件（ログインした顧客から依頼を受けている論文緊急出願案件）を抽出し、当該抽出した案件の受付番号をキーにして各テーブル（申請案件テーブル６００１（図６０）、出願ファイル管理テーブル６１０１（図６１）、弁理士テーブル５９０３（図５９（ｃ）））を参照して必要情報を取得することによって行う。修正ボタンについては抽出された案件のうち、終了フラグが１でないもの（出願ファイル管理テーブル６１０１を参照）について割り当て、評価ボタンの割り当てについては、特許事務所担当者のデータがある案件（出願ファイル管理テーブル６１０１（図６１）の該当受付番号のレコードに弁理士のＩＤが対応付けられているもの）についてのみ割り当てられる。また、備考欄については、クレーム案テーブル６４０１（図６４）に該当受付番号のレコードがある場合に「クレーム案があります」という表示（申請案件テーブル６００１（図６０）のクレーム依頼フラグが２である場合には、「代理人依頼済み」の表示となる）、出願ファイル管理テーブル６１０１（図６１）の取下げフラグが１である場合には「取下げ済み」の表示、同テーブルに優先権主張出願に関する情報（願番）がある場合には、当該情報と「優先権主張出願済み」という表示をそれぞれ行う。なお、当該備考欄の表示はそれぞれが排他的に表示されるというわけではなく、複数に該当する場合には、列挙して表示されるものである。

トップ画面表示処理（Ｓ４９０１）後の、Ｓ４９０２〜Ｓ４９０５は、イベントの発生（トップ画面に対する顧客の操作）待ちのループとなっており、顧客の操作に応じて、これに対応する処理が実行されることとなる。

トップ画面（図６５）の左欄の「出願依頼」は、論文緊急出願の依頼の受付を行うものであり、当該項目が選択された場合には、受付処理を実行する（Ｓ４９０２→Ｓ４９０６）。

＜＜＜受付処理：図４９のＳ４９０６の処理の詳細＞＞＞
図５０は、本実施形態における受付処理の処理動作を示すフローチャートであり、図４９のＳ４９０６の処理に相当する。実施形態１の受付処理（図６）と同様の処理概念になるものについては同一の符号を使用し、ここでの説明を省略する。

Ｓ６０２で生成する論文緊急出願申請用ページは、本実施形態では図６６に示したようなページとなる。実施形態１と比較すると、申請者情報の入力がなく、代わりに出願人情報の入力を求めており、雇用関係に関する情報の入力がない。また、本実施形態では出願日（希望日）を入力させる点、取下げに関する情報やクレーム案作成に関する情報入力をさせている点、で実施形態１と相違する。申請者情報に関しては、本実施形態では予め登録された顧客によるログイン処理を経て当該サービスを利用しているため、申請者情報に関する入力は不要である。また、登録情報（顧客テーブル５９０１（図５９（ａ）））から出願人情報を取得できるため、対応する情報をあらかじめ入力状態にして画面を構成している（顧客は、必要に応じて当該情報の修正や出願人の追加入力等を行う）。雇用関係に関する情報については、特許を受ける権利の処理については顧客側が責任を持ち、本サービス提供側ではこれについては関与しないという立場（サービス提供のための契約条件）としているため、入力を不要としている。実施形態１では公開予定日を入力させ、その日より一定期間前に出願を行う処理としていたが、本実施形態では直接出願希望日を入力させるものとしている。また論文緊急出願について取下げ処理をするかしないか（する場合には取下げ時期の指定）や、特許事務所に対するクレーム案の作成依頼（詳細は後述）をするか否かについての入力を求めている。

論文緊急出願申請用ページ（図６６）の生成処理後のＳ５００１（図５０）では、「入力内容を確認」ボタンか「キャンセル」ボタンの選択を待ち、「入力内容を確認」ボタンの選択があった以降は、基本的に実施形態１（図６）と同様の処理となる。実施形態１（図６）との相違点としては、本実施形態のＤＢ登録処理（Ｓ５００２）においては単に受信した情報を申請案件テーブル６００１に登録するだけの処理であり、実施形態１の図７の処理のような承認フラグの設定は行わない。また、出願日（実施形態１では公開日）までの期間が所定期間以上であった場合における処理（図６のＳ６０９→Ｓ６１６）も行わない。

図４９（顧客対応サイト処理）に戻って説明を続ける。

受付処理後のＳ４９０７では、受付処理からの戻り値として受付番号があるか否かを判別し、受付番号が無かった場合（出願日が受付日以前であることによる申請不可の場合かキャンセルされた場合）には、Ｓ４９０１へと戻って処理を続行する。一方、受付番号があった場合には、ＨＴＭＬファイル自動生成保存処理を実行する（Ｓ４９０７→Ｓ４９０８）。

＜＜＜ＨＴＭＬファイル自動生成保存処理：図４９のＳ４９０８の処理の詳細＞＞＞
図４９のＳ４９０８では、受付処理で取得したデータに基づいて出願用のＨＴＭＬファイルを自動生成する処理が実行される。図５１は、当該図４９のＳ４９０８の処理を示すフローチャートである。実施形態１（図８）同様の処理概念については同一の符号を使用し、ここでの説明を省略する。

Ｓ５１０１では、受付番号により出願ファイル管理テーブル６１０１（図６１）に新しいレコードを生成する。実施形態１では出願整理番号を別途生成するもの例としたが、本実施形態では受付番号をそのまま使用するものと例としている。Ｓ８０４〜Ｓ８１１の処理は、実施形態１と同様の処理である。なお、本実施形態では生成フラグを使用しないため、Ｓ５１０２では生成フラグに関する処理を行わない。

図４９（顧客対応サイト処理）に戻って説明を続ける。

ＨＴＭＬファイル自動生成保存処理後の、Ｓ４９０９では、受付処理で受け付けた案件の出願希望日が本日であるか又は直ちに出願案件であるか否かを判別し、これに該当しなかった場合には、Ｓ４９０１へと戻って処理を続行する。一方、出願希望日が本日であるか直ちに出願案件であった場合には、出願処理を実行する（Ｓ４９０９→Ｓ４９１０）。前述のごとく、本実施形態においては、システムによって自動的に出願ソフトを起動し、出願処理を自動的に行うものである。即ち、出願ソフトのＡＰＩに基づいて、出願ソフトを制御し、Ｓ４９０８で生成・保存されている出願用ファイルを利用して出願処理を実行させるものである。またＳ４９１０では、出願処理後に得られる出願情報（出願番号、出願日）を取得し、当該情報を出願ファイル管理テーブル６１０１（図６１）の対応するレコードに記録し、出願完了フラグを１にする。また、出願ソフトに受領書及びプルーフファイルの出力（ＨＴＭＬ変換したファイルの出力）を行わせこれをＤＢに格納し当該ファイルのアドレス情報についても出願ファイル管理テーブルに記録する（図６１ではプルーフファイルのアドレス情報の項目を省略している）。さらに、課金テーブル６２０１（図６２（ａ））に受付番号をキーとしたレコードを生成し、手続き種別コードを１とし、手続日に出願日、請求先にログインしている顧客のＩＤ、決済フラグに０をそれぞれ記録する。

Ｓ４９０６〜Ｓ４９１０の処理によって、顧客からの緊急論文出願の依頼の受付け、出願用ファイルの自動生成（及び、直ちに出願であった場合の出願処理）が行われることとなる。

Ｓ４９０２〜Ｓ４９０５におけるトップ画面（図６５）に対する操作待ちのループにおいて、修正ボタンの選択があった場合には、個別案件詳細情報登録処理を実行する（Ｓ４９０３→Ｓ４９１１）。

＜＜＜個別案件詳細情報登録処理：図４９のＳ４９１１の処理の詳細＞＞＞
顧客から、依頼済み案件に対する登録内容の修正要求があった場合には個別案件詳細情報登録処理が実行される。図５２は、当該個別案件詳細情報登録処理の処理動作を示すフローチャートである。

Ｓ５２０１では、修正ボタンが押された案件の受付番号に基づいて、出願ファイル管理テーブル６１０１（図６１）を参照して出願完了フラグが1であるか否かを判別し、出願済みであった場合にはＳ５２０８〜Ｓ５２１０の処理へ、未出願であった場合にはＳ５２０２〜Ｓ５２０７の処理へと移行する。出願済みである場合には、出願のための情報（出願日などの情報）は確定している（出願人など特許庁への変更手続きを行うことで変更可能なものもあるが、本システム上において任意に変更すべき情報ではない）ため、それらの情報については修正不可とするものであり、また、未出願の場合には論文緊急出願の依頼の取下げを受け付けることができるが、出願済みであるものは依頼自体の取下げは不可であるため、出願済みであるか否かによって処理を分けるものである。なお、本実施形態では上記のような処理を例としているが、出願後の出願人情報などについても情報を修正できるようにするものであっても構わない。

Ｓ５２０１で、出願前の案件と判断された場合は、Ｓ５２０２に移行して未出願案件情報修正処理を実行する。

＜＜＜＜未出願案件情報修正処理：図５２のＳ５２０２の処理の詳細＞＞＞＞
図５２のＳ５２０２では、まだ出願していない依頼済みの案件に対する登録情報の修正を受け付ける処理である未出願案件情報修正処理が実行される。図５３は、当該処理を示すフローチャートである。なお、図５０の受付処理と同様の処理概念については同一の符号を使用し、ここでの説明を省略する。

Ｓ５３０１では、図６９に示したような情報修正ページを生成する。情報修正ページは、依頼時のページ（図６６）と基本的に同じであるが、修正ページでは公開予定資料の入力欄は無く、公開予定資料の変更を受け付けていない（本実施形態では資料の差し替えは不可のものを例としているが、差し替えを許すようにするものであっても構わない）。また、登録内容を表示した形で画面を構成している。

当該画面に対する顧客からの入力をＳ５３０２とＳ５００１で待ち、申請取消ボタンの選択がされた場合には、Ｓ５３０５へと移行して、受付番号をキーにして出願用のファイル（ひな形に基づいて生成されたＨＴＭＬファイルと、資料（技術情報ファイル）に基づいて生成された各画像ファイル）を削除し、出願ファイル管理テーブル６１０１（図６１）の終了フラグを１にする。当該処理後は未出願案件情報修正処理を終了して個別案件詳細情報登録処理へと戻る。

一方、登録ボタンが選択された場合（情報の修正を入力後に登録ボタンが押された場合）には、図５０と同様の処理にて情報を登録する（ただし、修正後の出願日情報が今日より前である場合には、修正不可とする（Ｓ５３０３→Ｓ６１５））。情報の登録処理（Ｓ５００２）後のＳ５３０４では、修正内容が「技術分野」、「キーワード」、「取下」、「クレーム依頼」の何れかであるかを判別し、これらに該当する場合には、以降の処理をスキップして未出願案件情報修正処理を終了する（受付番号が戻り値とならない）。一方、Ｓ５３０４の判別結果が否定であった場合には、Ｓ６１０以降の処理が実行され、受付番号を戻り値として、未出願案件情報修正処理を終了する。

図５２（個別案件詳細情報登録処理）に戻って説明を続ける。

未出願案件情報修正処理（Ｓ５２０２）によって受付番号が戻り値として得られた場合には、当該受付番号をキーに出願用のファイルを削除する処理を実行し（Ｓ５２０３→Ｓ５２０４）、ＨＴＭＬファイル自動生成保存処理を実行する（Ｓ５２０５）。Ｓ５２０５〜Ｓ５２０７の処理は、図４９のＳ４９０８〜Ｓ４９１０の処理と同様であるため、ここでの説明を省略する。Ｓ５２０２〜Ｓ５２０７の処理により、出願前の依頼済み案件に対する登録内容の修正が行われ、出願用ファイルに関する変更があった場合には、出願用ファイルの再生成処理が実行されることとなる（出願用ファイルに関する変更がある場合には未出願案件情報修正処理の戻り値として受付番号が得られ、ＨＴＭＬファイル自動生成保存処理が実行される）。

Ｓ５２０１の判別処理の結果、修正ボタンが押されたのが出願済み案件であった場合には、図６８に示されるような出願済み案件の修正ページを生成する（Ｓ５２０８）。前述のごとく、出願日などの情報については確定しているため、これらについては修正ができず、「技術分野」、「キーワード」、「取下げ」、「クレーム作成依頼」、「優先権主張出願の願番と出願日情報」、「担当者情報」について修正または新規登録可能な画面となる。「優先権主張出願の願番と出願日情報」とは、当該出願済みの論文緊急出願に基づく優先権主張出願（国内またはＰＣＴ、外国出願）を行った場合に、当該優先権主張出願の入力をさせるものである。担当者情報は、当該優先権主張出願を扱った弁理士情報である。

Ｓ５２０８に続くＳ５２０９では、図６８の画面に対する登録ボタンまたはキャンセルボタンの入力を待ち、登録であった場合には、得られた情報をテーブルに登録する処理を行う（Ｓ５２１０）。当該登録処理では、「技術分野」、「キーワード」、「取下げ」、「クレーム作成依頼」については、申請案件テーブル６００１の該当情報を更新し、「優先権主張出願に関する情報」、「担当者情報」については、出願ファイル管理テーブル６１０１の該当情報を更新するものとなる。当該処理において「優先権主張出願に関する情報」が得られ、これが国内優先権主張出願であった場合には、出願ファイル管理テーブル６１０１の終了フラグを１とする（国内優先権主張出願の基礎出願は見做し取り下げとなるため）。Ｓ５２０９の判別の結果、キャンセルであった場合には、Ｓ５２１０をスキップして個別案件詳細情報登録処理を終了する。

図４９（顧客対応サイト処理）に戻って説明を続ける。

Ｓ４９０２〜Ｓ４９０５におけるトップ画面（図６５）に対する操作待ちのループにおいて、評価ボタンの選択があった場合には、図７２に示すような評価画面を生成する処理を行う（Ｓ４９０３→Ｓ４９１２）。当該評価画面は、弁理士（又は特許技術者）に対する顧客の評価を入力させる画面であり、本実施形態では、「クレーム作成能力」、「明細書作成能力」、「中間処理能力」、「迅速性」、「事務対応」、「価格」、「コストパフォーマンス」の各項目を5段階で評価するものを例としている。また、コメントとしてフリーにテキスト入力させている。図６５のごとく、特許事務所担当者のデータがある案件（出願ファイル管理テーブル６１０１（図６１）の該当受付番号のレコードに弁理士のＩＤが対応付けられているもの）についてのみ評価ボタンの割り当てがされるものであり、当該弁理士に対する評価をさせるものとなる。評価画面（図７２）では、左欄に評価対象である弁理士に関する情報（弁理士テーブル５９０３（図５９（ｃ））及び事務所テーブル５９０２（図５９（ｂ））から情報取得）を表示し、上欄は当該弁理士のこれまでの評価をグラフ化したものを表示、下欄は上述の評価項目の入力欄となっている。上欄のグラフは、左側が上記各評価項目に対応したグラフであり、右側は技術分野ごとの評価グラフである。左側グラフについては、評価テーブル６３０１（図６３）から弁理士ＩＤに基づいて抽出したレコードの平均値をとることで、当該弁理士の各項目の評価値を算出し、グラフ化する。全体平均値（図中の点線）については全レコードの平均をグラフ化する。右側のグラフについては、評価テーブル６３０１（図６３）から弁理士ＩＤに基づいて抽出したレコードについて、技術分野コード別にクレーム作成能力、明細書作成能力、中間処理能力を合算して平均値をとったものにより（どの項目を評価対象にするかは適宜選択すればよい）、グラフ化する。弁理士個人で対応できる技術分野は通常限られているので、評価値もその弁理士が対応できる分野のみとなるのが通常である。なお、ここでは単純平均するものを例としているが、数値の算出は各種統計手法を適用するものであってよい。

当該評価画面に対して、評価項目を入力後に送信ボタンの選択がされた場合には、Ｓ４９１４（図４９）へと移行して、当該取得される情報を、評価テーブル６３０１（図６３）に受付番号をキーとして新しいレコード生成して登録する（既に該当する受付番号のレコードがある場合には、当該レコードの更新処理）。評価テーブル６３０１は、図６３に示されるように、受付番号と、当該受付番号をキーに申請案件テーブル６００１（図６０）から取得される技術分野コードと、評価画面を通じて取得される各評価情報とで構成される。評価テーブル６３０１への情報の登録処理（Ｓ４９１４）の終了後、又は、評価画面で戻るボタンが選択された場合には（Ｓ４９１３）、Ｓ４９０１へ戻って処理を続行する。なお、本実施形態においては、各案件と各弁理士（個人）に対する評価を対応付けて記録するものであるが、各弁理士ごとに評価を累積する（案件との紐付をなくす）ものであっても構わないし、弁理士個人ではなく事務所ごとに割り当てるようにしてもよい。さらに評価項目に応じて、個人割り当てするものと、事務所割り当てするものを分けるようにしてもよい（例えば、「事務対応」、「価格」、「コストパフォーマンス」といった情報は事務所評価として記録するなど）。

Ｓ４９０２〜Ｓ４９０５におけるトップ画面（図６５）に対する操作待ちのループにおいて、案件リストの備考欄の「クレーム案があります」が選択された場合には、クレーム案表示処理を実行する（Ｓ４９０４→Ｓ４９１５）。

＜＜＜クレーム案表示処理：図４９のＳ４９１５の処理の詳細＞＞＞
顧客が、論文緊急出願の依頼をする際（若しくは後の修正時）に、クレーム案作成依頼を選択していた場合には、該当する論文等（技術情報ファイル）がシステムによって弁理士側に提示され（本システムに登録している弁理士が閲覧可能な状態となり）、これに対する弁理士側からのクレーム案がシステムに入力されることになる（詳細は後述）。当該弁理士側からのクレーム案の登録があった場合には、顧客のトップ画面（図６５）の案件リスト中の対応する案件に「クレーム案があります」という表示がなされ、これが選択された場合に、クレーム案の表示等を行うのがクレーム案表示処理である。図５４は、当該クレーム案表示処理の処理動作を示すフローチャートである。

Ｓ５４０１では、図７０に示されるようなクレーム案表示ページを生成する。当該クレーム案表示ページでは左欄に、出願ファイル管理テーブル６１０１や申請案件テーブル６００１から受付番号をキーに取得した案件情報（出願整理番号（＝受付番号）、出願番号、発明の名称、発明者名、技術ファイルへのリンク）が表示される。また、ページ中央部には、クレーム案テーブルから受付番号をキーに取得したクレーム案情報とこれを作成した作成者（弁理士）の表示がされる（クレーム案を提示した弁理士が複数いる場合には、複数のクレーム案が表示されることとなる）。

クレーム案表示ページ（図７０）では、顧客がそれぞれのクレーム案を見て、気に入った案があった場合には、「依頼ボタン」を押すことで当該代理人に依頼（論文緊急出願に基づく優先権主張出願の代理依頼など）をすることができる。また、弁理士の名前の部分のリンクを選択すると、当該代理人の評価情報を見ることができ、依頼をするにあたりこれを参考にすることもできる。また、クレーム案に対する評価もすることができるものとなる。

Ｓ５４０１に続く、Ｓ５４０２〜Ｓ５４０６は、クレーム案表示ページに対する顧客からの操作待ちのループである。

Ｓ５４０２〜Ｓ５４０６の入力待ちループにおいて、「依頼ボタン」の選択があった場合には、依頼を本当にするか否かの確認画面を表示し（Ｓ５４０２→Ｓ５４０７）、これが確認された場合には申請案件テーブル６００１のクレーム依頼フラグを２にして、出願ファイル管理テーブル６１０１の、該当レコードに弁理士ＩＤを登録し、終了フラグを１にする（Ｓ５４０８→Ｓ５４０９）。続くＳ５４１０では、課金テーブル６２０１に受付番号をキーとしたレコードを生成し、手続きコードを３とし、手続き日に当日の日付を格納、依頼先である弁理士のＩＤを請求先として格納し（即ち、本実施形態では、依頼が成立した場合に代理を受任する弁理士に対して請求をするビジネスモデルとなる）、決済フラグは０とする。一方、確認画面でキャンセルが選択された場合には（Ｓ５４０８）、Ｓ５４０１へ戻って処理を続行する。

Ｓ５４０２〜Ｓ５４０６の入力待ちループにおいて、弁理士の名前の部分のリンクが選択された場合には、当該弁理士に関する評価画面を別ウィンドウで表示する（Ｓ５４０３→Ｓ５４１１）。弁理士に関する評価画面は、図７６にその例を示したごとく、図７２のグラフと同じものを表示させ、評価テーブル６３０１を弁理士ＩＤをキーにして検索して得られたレコードのコメントを口コミ情報として表示するものである。

Ｓ５４０２〜Ｓ５４０６の入力待ちループにおいて、公開資料のリンクが選択された場合には、申請案件テーブル６００１の資料アドレスに基づいて、該当資料を別ウィンドウで表示する（若しくはダウンロード画面の提示）（Ｓ５４０４→Ｓ５４１２）。

Ｓ５４０２〜Ｓ５４０６の入力待ちループにおいて、「評価ボタン」の選択があった場合には、図７１に示されるようなクレーム評価ページを生成する（Ｓ５４０６→Ｓ５４１３）。クレーム評価ページは、図７２の評価ページと同様のものであるが、クレーム案に対する評価のみ（及びコメントの記載）ができるものとなる。当該クレーム評価ページに対して評価を入力後に送信ボタンの選択がされた場合には、Ｓ５４１５へと移行して、当該取得される情報を、評価テーブル６３０１（図６３）に受付番号をキーとして新しいレコード生成して登録する（既に該当する受付番号のレコードがある場合には、当該レコードの更新処理）。評価テーブル６３０１への情報の登録処理（Ｓ５４１５）の終了後、又は、クレーム評価ページ（図７１）で戻るボタンが選択された場合には（Ｓ５４１４）、Ｓ５４０１へ戻って処理を続行する。

Ｓ５４０２〜Ｓ５４０６の入力待ちループにおいて（クレーム案表示ページ（図７０）に対して）、「戻るボタン」の選択があった場合には、クレーム案表示処理を終了する。

図４９（顧客対応サイト処理）に戻って説明を続ける。

クレーム案表示処理（Ｓ４９１５）の終了後は、Ｓ４９０１に戻って処理を続行する（図６５のトップページに戻る）。当該ページに対するＳ４９０２〜Ｓ４９０５の操作待ちのループにおいて、終了ボタンの選択があった場合には（Ｓ４９０５）、顧客対応サイト処理を終了する。

以上の、顧客対応サイト処理により、顧客に対して、論文緊急出願の依頼（及びその修正）、弁理士に対するクレーム案作成要求及びこれに対して提示されたクレーム案の提示、当該クレーム案や代理人評価、口コミ情報を参考にした代理の依頼、クレーム案に対する評価情報の入力や、その他代理を依頼した場合の各種評価の記載といった各種のサービスを提供することができるものである。

次に、弁理士側からの本システムの利用に関する説明を行う。

＜＜事務所対応サイト処理：図４８のＳ４８０６の処理の詳細＞＞
弁理士からのログイン要求があった場合には事務所対応サイト処理が実行される（図４８：Ｓ４８０４→Ｓ４８０６）。図５５は、当該事務所対応サイト処理の処理動作を示すフローチャートである。

先ず、Ｓ５５０１では、図７３に例示したような弁理士用のサイト画面を生成する処理を実行する。当該弁理士用サイトのトップページは、ログインした弁理士に対して適合するクレーム依頼案件のリストを表示するものである。「適合する」とは、技術分野が適合する案件であり、各弁理士の対応可能な技術分野については予め弁理士テーブル５９０３に技術分野コードとして登録されているものである。トップページのクレーム依頼案件のリスト生成（リスト中の「依頼者」、「出願予定日」、「出願日」、「出願番号」、「資料リンク情報」、「技術分野」、「キーワード」、「クレーム案を作成済みか否か」の取得）については、先ず、申請案件テーブル６００１（図６０）から、クレーム依頼フラグが１である案件を抽出し、さらに当該案件の技術分野コードが該当弁理士（ログインした弁理士）の登録されている技術分野コードと一致する案件を抽出、当該抽出された案件について、受付番号をキーにして、申請案件テーブル６００１から申請者、出願希望日、資料アドレス、技術分野、キーワードの各情報を取得し、同様に出願ファイル管理テーブル６１０１から出願日、出願番号を取得し、クレーム案テーブル６４０１に自己のＩＤ（ログインしている弁理士のＩＤ）があるか否かの情報を取得することで行う（クレーム案テーブル６４０１に、該当する受付番号に自己のＩＤが対応づけられたレコードがある場合には、クレーム案を作成済みであるので、「作成」の項目に「済」を表示し、該当するレコードがなかった場合は「未」を表示する）。また、クレーム依頼フラグが２である案件のうち、出願ファイル管理テーブル６１０１の弁理士の項目として自己のＩＤが格納されている場合には、当該案件もリストに追加し、「依頼アリ」という注意書きを付加する。これはクレーム案を作成した案件について、顧客側から代理依頼があった案件である（本実施形態では、代理依頼後については本システムでは関与しないもの例としているため、代理依頼があったことを認識した弁理士は個別に依頼者に連絡をとって仕事を受任することとなる）。リストの各案件については、作成ボタンか修正ボタンが割り当てられる。当該割り当ては、作成の項目が「未」である案件には作成ボタンを、「済」である案件については修正ボタンが割り当てられるものである。なお、画面上は表示されないが、後の処理に利用するため、各案件の整理番号情報は対応付けて保持されている。

弁理士用サイトのトップ画面表示処理（Ｓ５５０１）後の、Ｓ５５０２〜Ｓ５５０７は、イベントの発生（トップ画面に対する操作）待ちのループとなっており、ログイン者の操作に応じて、これに対応する処理が実行されることとなる。

Ｓ５５０２〜Ｓ５５０７のトップ画面に対する操作待ちのループにおいて、依頼リスト中の資料（技術情報ファイル）のリンクの選択があった場合には、受付番号をキーにして申請案件テーブル６００１から取得した資料アドレスに基づいて、該当資料を別ウィンドウで表示する（若しくはダウンロード画面の提示）（Ｓ５５０５→Ｓ５５０９）。これにより弁理士はクレーム案を作成するための基となる資料を参照することができ、当該資料に基づいて作成したクレーム案を以下の処理によって入力する。

トップ画面（図７３）に対して、「作成ボタン」の選択がされた場合には、図７４に示されるようなクレーム案入力画面を生成する（Ｓ５５０３→Ｓ５５１０）。当該クレーム案入力画面は、左欄に「依頼者（クレーム案の作成を依頼した機関）情報」、「出願番号」、「発明の名称」、「発明者」の情報が、整理番号をキーにして各テーブルから取得されて表示される。メインとなるクレーム案の入力部分については、「チャレンジクレーム」、「ターゲットクレーム」、「概算見積額」、「コメント」の入力欄があるものを例としている。即ち、ある意味ダメ元で少し広い範囲での権利取得を目指す「チャレンジクレーム」と、現実的に権利化を狙う「ターゲットクレーム」との双方を作成させることで、その代理人のクレーム作成能力を推し量ることができるようにするものである。また、仕事を依頼する側からは費用も重要な要素であるので、概算の見積もり（本実施例では形式はフリー）を提示させるものとなる。最後のコメント欄については、クレーム作成の意図など、顧客によりよく内容を理解してもらうための補助的な説明などを自由に記載できるものとなる。

クレーム案入力画面に対して、弁理士がクレーム案などを入力した上で、入力内容の確認ボタンが押された場合には、確認画面を表示して（Ｓ５５１１→Ｓ５５１２）、当該確認画面に対して登録ボタンが選択された場合には、Ｓ５５１４の処理へと移行する（一方、戻るボタンが選択された場合には、Ｓ５５１０へ戻って処理を繰り返す（Ｓ５５１３））。Ｓ５５１４では、弁理士によって入力されたクレーム案などの情報をクレーム案テーブル６４０１（図６４）に受付番号をキーとして新しいレコードを生成して登録する。当該Ｓ５５１４の処理が終わった場合、又はクレーム案入力画面（図７４）に対してキャンセルボタンの入力があった場合には（Ｓ５５１１）、Ｓ５５０１に戻って処理を繰り返す。

Ｓ５５０２〜Ｓ５５０７のトップ画面に対する操作待ちのループにおいて、修正ボタンの選択がされた場合には、クレーム案修正画面を生成する（Ｓ５５０２→Ｓ５５１５）。当該クレーム案修正画面の構成は、図７４のクレーム案入力画面と同様の構成であり、既に登録済みの内容が記入された形で表示されるものである。即ち、クレーム案テーブル６４０１から該当する受付番号と弁理士ＩＤのレコードの各情報を取得して、図７４の「チャレンジクレーム」、「ターゲットクレーム」、「概算見積額」、「コメント」の各欄にそれぞれの情報を表示させた画面である。

クレーム案修正画面に対して、弁理士が適宜修正情報を入力した上で、入力内容の確認ボタンが押された場合には、図７５に示すような確認画面を表示して（Ｓ５５１６→Ｓ５５１７）、当該確認画面に対して修正登録ボタンが選択された場合には、Ｓ５５２０の処理へと移行する（一方、戻るボタンが選択された場合には、Ｓ５５１５へ戻って処理を繰り返す（Ｓ５５１８））。Ｓ５５２０では、修正されたクレーム案などの情報をクレーム案テーブル６４０１（図６４）に反映する。当該Ｓ５５２０の処理が終わった場合、又はクレーム案修正画面に対してキャンセルボタンの入力があった場合には（Ｓ５５１６）、Ｓ５５０１に戻って処理を繰り返す。一方、確認画面（図７５）において、取消ボタンが選択された場合には、受付番号と弁理士ＩＤをキーにしてクレーム案テーブル６４０１からレコードを削除する（Ｓ５５１９→Ｓ５５２１）。

Ｓ５５０２〜Ｓ５５０７のトップ画面に対する操作待ちのループにおいて、左欄の「評価を見る」が選択された場合には、図７６に示されるような個人評価画面を生成する（Ｓ５５０４→Ｓ５５０８）。当該画面は、前述したごとく、弁理士ＩＤをキーにして評価テーブル６３０１から得られる情報によって生成されるものである。これによって、自己に対するクライアントの評価がいかなるものかを知ることができる。

Ｓ５５０２〜Ｓ５５０７のトップ画面に対する操作待ちのループにおいて、左欄の「登録情報」が選択された場合には、図７７に示されるような登録情報表示変更画面を生成する（Ｓ５５０６→Ｓ５５２２）。当該処理は、本システムによるサービスを受けるために登録されている情報の確認及び修正をさせるものであり、弁理士テーブル５９０３（図５９（ｃ））から該当する弁理士ＩＤの情報を取得してこれを表示し、これに対する修正及び確認の入力があった場合には、弁理士テーブル５９０３に対して修正情報を反映する処理となる。

トップ画面（図７３）に対して、左欄の「終了」の選択があった場合には、事務所対応サイト処理を終了する（Ｓ５５０７）。

以上の、事務所対応サイト処理により、顧客からのクレーム案作成要求が提示され、資料に基づいて作成したクレーム案を入力することにより、当該クレーム案が顧客側に伝わることとなる。また、顧客からの自己に対する評価や、代理の依頼情報を知ることができる。

＜＜当日案件出願処理：図４８のＳ４８０７の処理の詳細＞＞
図４８のＳ４８０１〜Ｓ４８０３のループ処理において、時刻が午前零時になった場合には、「当日案件出願処理」を実行する（Ｓ４８０２→Ｓ４８０７）。「当日案件出願処理」は、出願予定日になった案件（論文緊急出願）の出願処理を実行するものである。図５６は、当該処理の処理動作を示すフローチャートである。

当日案件出願処理（図５６）は、申請案件テーブル６００１（図６０）の全レコードに対してＳ５６０１〜Ｓ５６０５の処理を実行させるものである。Ｓ５６０１では、出願希望日が今日であるか否かを判別し、続くＳ５６０２では、終了フラグが１であるか否かを判別する。出願希望日が今日であり且つ終了フラグが１ではない案件については、Ｓ５６０３〜Ｓ５６０５の処理を実行し、そうでない案件についてはＳ５６０３〜Ｓ５６０５の処理をスキップして次の案件（レコード）へと移行する。

Ｓ５６０３では、システムによって自動的に出願ソフトを起動し、該当案件の整理番号に基づいて出願ファイル管理テーブル６１０１から出願ファイルアドレスとリンクファイルアドレスを取得して、これらのファイルアドレスに該当するファイルを利用して出願ソフトに出願処理（送信ファイルへの変換及びオンライン出願処理）を実行させる。

続くＳ５６０４では、出願処理後に得られる出願情報（出願番号、出願日）を取得し、当該情報を出願ファイル管理テーブル６１０１（図６１）の対応するレコードに記録し、出願完了フラグを１にする。また、出願ソフトに受領書及びプルーフファイルの出力（ＨＴＭＬ変換したファイルの出力）を行わせこれをＤＢに格納し当該ファイルのアドレス情報についても出願ファイル管理テーブル６１０１に記録する（図６１では受領書及びプルーフファイルのアドレス情報の項目を省略している）。

Ｓ５６０５では、課金テーブル６２０１（図６２（ａ））に受付番号をキーとしたレコードを生成し、手続き種別コードを１とし、手続日に出願日、請求先には受付番号をキーとして申請案件テーブル６００１から取得した申請者ＩＤ、決済フラグに０をそれぞれ記録する。

申請案件テーブル６００１の全レコードに対してＳ５６０１〜Ｓ５６０５の処理が実行されたら、当日案件出願処理を終了する。当該処理により、出願希望日が到来した案件の出願処理と、出願情報の登録及び受領書やプルーフファイル（ＨＴＭＬ変換したファイル）の取得がシステムによって自動的に行われる。

＜＜取下げ処理：図４８のＳ４８０８の処理の詳細＞＞
図４８のＳ４８０１〜Ｓ４８０３のループ処理において、時刻が午後１１時になった場合には、「取下げ処理」を実行する（Ｓ４８０３→Ｓ４８０８）。「取下げ処理」は、取下げ予定日になった案件（論文緊急出願）の取下げ処理を実行するものである。図５７は、当該処理の処理動作を示すフローチャートである。

取下げ処理（図５７）は、申請案件テーブル６００１（図６０）の全レコードに対してＳ５７０１〜Ｓ５７０６の処理を実行させるものである。Ｓ５７０１では、取下げ希望日が今日であるか否かを判別し、続くＳ５７０２では、終了フラグが１であるか否かを判別する。取下げ希望日が今日であり且つ終了フラグが１ではない案件については、Ｓ５７０３〜Ｓ５７０６の処理を実行し、そうでない案件についてはＳ５７０３〜Ｓ５７０６の処理をスキップして次の案件（レコード）へと移行する。

Ｓ５７０３では、取下げ書の自動生成を行う。当該処理は実施形態１（図１５のＳ１５０３〜Ｓ１５０５の処理）と同様であるためここでの説明を省略する。続くＳ５７０４では、システムによって自動的に出願ソフトを起動し、Ｓ５７０３で生成した取下げ書のファイルを利用して出願ソフトに取下処理（送信ファイルへの変換及びオンライン処理）を実行させる。

続くＳ５７０５では、取下日情報を出願ファイル管理テーブル６１０１（図６１）の対応するレコードに記録し、取下フラグ及び終了フラグを１にする。また、出願ソフトに受領書及びプルーフファイルの出力（ＨＴＭＬ変換したファイルの出力）を行わせこれをＤＢに格納し当該ファイルのアドレス情報についても出願ファイル管理テーブル６１０１に記録する（図６１では受領書及びプルーフファイルのアドレス情報の項目を省略している）。

Ｓ５７０６では、課金テーブル６２０１（図６２（ａ））に受付番号をキーとしたレコードを生成し、手続き種別コードを２とし、手続日、請求先には受付番号をキーとして申請案件テーブル６００１から取得した申請者ＩＤ、決済フラグに０をそれぞれ記録する。

申請案件テーブル６００１の全レコードに対してＳ５７０１〜Ｓ５７０６の処理が実行されたら、取下げ処理を終了する。当該処理により、取下げ日が到来した案件の手続きと、受領書やプルーフファイル（ＨＴＭＬ変換したファイル）の取得がシステムによって自動的に行われる。

＜＜手続き通知終了処理：図４８のＳ４８０９の処理の詳細＞＞
取下げ処理（Ｓ４８０８）に続いて、手続き終了通知処理が実行される（Ｓ４８０９）。「手続き終了通知処理」は、本システムで当日行った手続きを顧客に対して通知する処理である。図５８は、当該処理の処理動作を示すフローチャートである。

手続き終了通知処理（図５８）は、課金テーブル６２０１（図６２（ａ））の全レコードに対してＳ５８０１〜Ｓ５８０５の処理を実行させ、これによって得られた一時テーブルの情報に基づいて各顧客又は事務所に対してメールを送信するもの（Ｓ５８０６）である。Ｓ５８０１では、手続日が今日であるか否かを判別し、続くＳ５８０２では、決済フラグが１であるか否か（即ち既に課金済みであるか否か）を判別する。手続日が今日であり且つ決済フラグが１ではない案件については、Ｓ５８０３〜Ｓ５８０５の処理を実行し、そうでない案件についてはＳ５８０３〜Ｓ５８０５の処理をスキップして次の案件（レコード）へと移行する。

Ｓ５８０３では、各テーブルから情報を収集することで、請求先ごとに、受付番号、行った手続き、手続日、及び、請求金額を対応付けて一時記憶する。当該処理において、請求先情報は、課金テーブル６２０１の請求先の顧客ＩＤに基づいて顧客テーブル５９０１から取得、又は、課金テーブル６２０１の請求先の弁理士ＩＤに基づいて弁理士テーブル５９０３から事務所ＩＤを取得しこれに基づいて事務所テーブル５９０２から取得する。ここで得られる顧客ＩＤ又は事務所ＩＤごとにこの処理における一時テーブルを生成し（既に該当ＩＤでテーブルがある場合にはそれを利用）、当該テーブルに、受付番号、行った手続き（課金テーブル６２０１の手続き種別コードに基づいて手続きテーブル６２０２（図６２（ｂ））を参照して取得）、手続日、請求金額（課金テーブル６２０１の手続き種別コードに基づいて手続きテーブル６２０２（図６２（ｂ））を参照して取得）を対応付けて格納する。

Ｓ５８０４では手続き種別コードが１か２（出願ソフトを利用した手続き）であるか否かを判別し、出願ソフトを利用した手続きである場合には、出願ファイル管理テーブル６１０１を参照して受領書及びプルーフファイルの格納場所情報を取得し、これを上記一時テーブルに格納する（Ｓ５８０５）。

課金テーブル６２０１の全レコードに対してＳ５８０１〜Ｓ５８０５の処理が実行されたら、ループ処理を終了し、Ｓ５８０６へ移行する。Ｓ５８０６では、ループ処理で得られた一時テーブルによって、各請求先ごとに当日行った手続きをまとめて通知する。即ち、請求先ごとに、受付番号、行った手続き、手続日、及び、請求金額（合計金額も計算して表示）を記載したメールを生成（報告書及びプルーフファイルがある場合にはこれを添付）し送信するものである。すべての請求先にメールを送信する処理が終わったら、手続き終了通知処理を終了する。

手続き終了通知処理（図４８：Ｓ４８０９）の終了後は、Ｓ４８１０に移行して課金処理を実行する。当該課金処理は、手続き終了通知処理における一時テーブルを利用して、各請求先に対する請求金額の合計を、各請求先の口座（口座情報は顧客テーブル５９０１又は事務所テーブル５９０２から取得）から引き落とす処理を行う。引落し処理が終わったものについては、課金テーブル６２０１の決済フラグを１とする。なお、本実施形態では当日行った手続き分を1日ごとに通知し課金するものを例としているが、通知・課金をする単位期間は任意のものであって構わない（例えば１月ごとの処理であってもよいし、各手続きを行ったタイミングで毎回処理するものであってもよい）。

以上のごとく、本実施形態の出願支援システムによれば、技術情報ファイルに基づいた論文緊急出願を代行するサービスを、各顧客に対して提供することができる。また、顧客から得られた技術情報ファイル等を、代理人側に提示し、当該技術情報ファイル等の内容に応じたクレーム案の入力を受付け、得られたクレーム案を顧客（技術情報ファイルの送信主）に提示する処理がシステムによって行われため、本サービスの提供を受ける顧客は、技術情報ファイルの内容に基づき代理人によって作成されたクレーム案を確認することができる。一般的に、出願の代理依頼において、クレーム案を見てから仕事の依頼をするということはできず、ましてや複数の弁理士によるクレーム案を比較した上で、最も好ましいものに対して仕事を依頼するといったことはできないが、本システムによるサービスによれば、各クレーム案を確認・比較し、且つ、各代理人の評価情報や口コミ情報を参考にして仕事を依頼することができるため、顧客にとって有用なサービスを提供することができる。

また、技術情報ファイルの内容に基づき代理人によって作成されたクレーム案に対して、その評価情報が当該代理人に対応付けられて記憶され、顧客からの要求又は代理人からの要求に応じて、当該評価情報が提示されることになるため、実際のクレーム案を見た上でそのクレーム作成能力を評価した情報を提示するサービスを提供することができる。また、クレーム作成能力以外の評価についても、少なくとも実際に仕事の依頼をした代理人に対してのみ評価を可能とさせているため、有用な情報を提示するサービスを提供することができる。

本実施形態では、基本的に事務所単位ではなく弁理士個人に基づくサービスにしているため、クレーム案の作成者が誰かといった情報や、個人に対する評価情報を得ることができる。特許明細書の作成能力は、事務所単位というより、個人能力によるところが大きく、仕事を依頼する側としては、よい弁理士（若しくは特許技術者）に担当して欲しいという要望があるが、事務所単位ではなく個人単位でよい弁理士（若しくは特許技術者）を探すことは何か伝手でもない限り困難である。これに対し、本システムによれば、実際に仕事を依頼した者による評価情報を個人単位で蓄積しこれを提供すること、また、クレーム案の提示の際に、これを作成したものが誰であるかを提示することで、仕事を依頼する側である大学等の顧客の利便性を高めている。

本実施形態のシステムにより提供されるサービスでは、代理人側にとっても、新たな顧客を獲得し得る機会を得られるものであり、より良い仕事をしていればどんどん評価が高まりさらに仕事の依頼が増えるという好循環に至り易くなるものである。結果として、全体的な代理人のサービスの質を向上させる機能も期待できるものとなる。

本実施形態では、クレーム案の作成依頼時に代理人側へ提示する資料を論文などの技術情報ファイルとしているが、システムによって自動生成した出願用のＨＴＭＬファイルであってもよいし、出願後に出願ソフトから得られるプルーフファイルであってもよい（上記説明から明らかなように、内容的には何れも同じである）。

本実施形態では、顧客側はクレーム案を確認するときの該当弁理士や、評価を入力するときの該当弁理士に関するものしか評価情報を見ることができないようなものを例としているが、任意に検索して評価情報を表示させるものであってもよい。例えば、技術分野を特定し、当該分野で評価情報の高い者を順番に表示させるようなものや、直接弁理士名によって検索させてその評価情報を提示するような処理をしてもよい。また、同様のサービスを弁理士側にも提供するものであってもよい。

なお、本実施形態においては、基本的に実施形態１の「論文緊急出願」を行うものとして説明しているが、論文緊急出願を行わずに、単に、出願人（出願をしようとする者）と、代理人側との間を仲介するシステムとしてもよい。即ち、代理人側は、出願人側によってシステムに登録された出願資料（技術情報ファイル）を見てクレーム案の作成・システムへの登録を行い、出願人側は、これらのクレーム案等を参考にして（また、上記説明から理解できるように、各代理人に対する口コミ情報も参考とすることができる）、どの代理人に依頼するかを決めるようにすることができるサービスを提供するものである。

また、ここでは出願明細書の作成代理について説明してきたが、特許業務における中間処理においても適用できるものであるし、より一般的に、その他の代理業サービスに対しても適用可能な概念である（依頼に必要な資料のアップロード→当該資料に基づく代理人側の対応案の提示→依頼者側による代理人の選択。というものについて同様の概念として適用することができる）。即ち、上記実施形態において出願人からの技術情報ファイルとしてきたものを、依頼人からの依頼情報として考え、上記実施形態において代理人側が作成するクレーム案としたものを、依頼情報に対する対応情報として考えることで、より一般的な代理人評価・紹介サービス支援システムとして利用することができる。当該代理人評価・紹介サービス支援システムの一形態について以下の実施形態３で説明をする。

（実施形態３）
実施形態３の代理人マッチング支援システムは、代理人と依頼者とをマッチングさせるシステムとしてサービスを提供するものであり、本システムを利用することで、依頼者（代理業サービスを利用する側）にとっては、複数の代理人の実際の対応能力やいわゆる口コミ情報を比較して最も好ましい代理人を選択すること等が可能となるものである。以下、実施形態３の代理人マッチング支援システムについて、図面を参照しながら具体的に説明する。各図面において、実施形態１又は実施形態２と同様の構成要素や処理概念については各実施形態と同一の符号を使用し、ここでの説明を省略若しくは簡略化する。

図７８は、本実施形態３に係る代理人マッチング支援システムの概略を示すブロック図である。同図に示されるように、業者システム７８０と、依頼者が使用する情報処理装置である依頼者ＰＣ４７９と、代理人が使用する情報処理装置である代理人ＰＣ４７８などが構成要素となる。業者システム７８０には、代理人マッチング支援サーバ７８１（代理人評価・紹介サービス支援サーバ）、依頼者ＤＢ７８２、代理人ＤＢ７８３、依頼・評価ＤＢ７８４などが備えられる。代理人マッチング支援サーバ７８１については、ハードとしては実施形態１や２のものと異なる点は特にないが、機能面では実施形態１や２に対して相違する部分があり、以下で説明するように、当該機能を実現するため実施形態１や２とは異なる各プログラムやテーブル等を有するものとなる。ＣＰＵなどの各ハードウェア資源と各プログラムによって、各機能処理部（ログイン処理部、依頼情報取得部、依頼情報提示部、対応情報取得部、対応情報提示部、対応条件情報取得部、代理人指定情報取得部、代理人評価情報取得・提示部、依頼入力手段、依頼受付・通知処理部、課金処理部）が構成される点については実施形態１や２と同様の概念である。

本実施形態においては、依頼者及び代理人の何れについても予め登録された者がサービス提供対象であり、依頼者については、図８４（ａ）に構成例を示したような依頼者テーブル８４０１（依頼者ＤＢ７８２に格納）において、ログイン情報となるＩＤやパスワードのほか、氏名／名称、住所、法人であるか個人であるかの別、法人である場合の担当者名、連絡先情報（電話番号など）、メールアドレス、業種、職種、経験年数などの情報が、予め登録時に取得され、これらが対応付けられて格納される。なお、当該テーブルに格納されている情報（例えば、法人であるか個人であるかの別、業種、職種、経験年数などの情報）が依頼者の属性情報である。本実施形態においては、当該属性情報については登録における必須の情報という訳ではなく、登録時に依頼者が任意に入力する情報である。ここで示した属性情報は例示であって、これらに限らず、各代理業の特性などに応じて適宜定められるものである。

代理人側については、図８４（ｂ）に構成例を示したような代理人テーブル８４０２（代理人ＤＢ７８３に格納）において、ログイン情報となるＩＤやパスワードのほか、氏名、メールアドレス、電話番号、ＦＡＸ番号、対応可能な分野に関する情報、対応不能な分野に関する情報、対応不能なクライアント、経験年数などの情報が対予め登録時に取得され、これらが対応付けられて格納される。なお、対応可能な分野に関する情報、対応不能な分野に関する情報、対応不能なクライアントに関する情報、経験年数などの情報が対応可能条件情報又は／及び対応不能情報である。当該情報についても登録における必須の情報という訳ではなく、登録時に代理人が任意に入力する情報である。

＜代理人マッチング支援サーバ全体処理概略＞
本実施形態の代理人マッチング支援サーバ７８１における処理動作の全体の概要を説明し、その後、当該全体処理を構成する各機能処理について順次詳細に説明を行う。図７９は、代理人マッチング支援サーバ７８１の全体動作の概略を示すフローチャートである。

代理人マッチング支援サーバ７８１の全体動作の概略としては、実施形態２（図４８）と基本的に同様（一部機能処理がないもの）であり、ログインがあった場合に（Ｓ４８０１：Ｙｅｓ）、ログインした者が依頼者か代理人かによって、それぞれに対応する処理が実行されるものである（Ｓ４８０４→Ｓ４８０５ｏｒＳ４８０６）。

＜＜依頼者対応サイト処理：図７９のＳ４８０５の処理の詳細＞＞
依頼者からのログイン要求があった場合には依頼者対応サイト処理が実行される（図７９：Ｓ４８０４→Ｓ４８０５）。図８０は、当該依頼者対応サイト処理の処理動作を示すフローチャートである。

先ず、Ｓ８００１では、依頼案件テーブル８５０１（図８５）を参照し、ログインしている依頼者のＩＤに基づいて、当該依頼者が依頼している案件があるか否か（該当する依頼者ＩＤが対応付けられたレコードがあるか否か）を判別する。

Ｓ８００１における判別処理の結果、依頼済み案件があった場合には、Ｓ８００２へ移行して図８８に例示したような依頼者用のサイト画面を生成する処理を実行する。当該依頼者用サイトのトップページは、ログインした依頼者から依頼を受けている案件のリストを提示するものである。当該リストの生成（リスト中の「受付番号」、「依頼日」、「タイトル」、「依頼内容」の取得）については、依頼案件テーブル８５０１（図８５）から、依頼者ＩＤ（＝ログインＩＤ）に基づいて抽出したレコードから必要情報を取得することによって行う。
備考欄については、依頼対応案テーブル８７０１（図８７）に該当受付番号のレコードがある場合に「コメントがあります」という表示が行われる（依頼案件テーブル８５０１（図８５）の受任代理人に情報がある場合には、「代理人依頼済み」の表示となる）。なお、当該備考欄の表示はそれぞれが排他的に表示されるというわけではなく、双方に該当する場合には、列挙して表示されるものである。

トップ画面表示処理（Ｓ８００２）後の、Ｓ８００３〜Ｓ８００５は、イベントの発生（トップ画面に対する依頼者の操作）待ちのループとなっており、依頼者の操作に応じて、これに対応する処理が実行されることとなる。

トップ画面（図８８）の左欄の「依頼入力」は、新規の依頼の受付を行うものであり、当該項目が選択された場合には、受付処理を実行する（Ｓ８００３→Ｓ８００６）。また、Ｓ８００１における判別処理の結果、依頼済み案件がなかった場合においても、受付処理が実行される（Ｓ８００１→Ｓ８００６）。

＜＜＜受付処理：図８０のＳ８００６の処理の詳細＞＞＞
図８１は、本実施形態における受付処理の処理動作を示すフローチャートであり、図８０のＳ８００６の処理に相当する。実施形態１の受付処理（図６）または実施形態２の受付処理（図５０）と同様の処理概念になるものについては同一の符号を使用し、ここでの説明を省略する。

Ｓ８１０１では、図８９にその一例を示したような、新規依頼用ページの生成処理が行われる。同ページは、依頼のタイトルと、依頼内容と、当該依頼の分野に関する情報と、当該依頼内容を送信する代理人に関する情報などの入力を求めるものである。なお、「依頼内容を送信する代理人に関する情報」が、対応条件情報に該当する。ここの設定により、依頼内容を開示する相手（代理人）を指定することができるものである。本実施形態においては、図８９に示されるように、「分野が適合する者に限定する」という項目に対するラジオボタンと、より詳細に代理人を選択させる画面に遷移するボタンとが配されている。「分野が適合する者に限定する」が選択された場合には、その上で選択している分野に適合する代理人に対してのみ依頼内容が提示されることになる。

新規依頼用ページの生成処理後のＳ８１０２〜Ｓ８１０３のループ処理では、新規依頼用ページに対する各ボタン（「詳細に代理人を選択」、「入力内容を確認」、「キャンセル」）の選択を待つ。これに対して、「詳細に代理人を選択」の選択があった場合には、Ｓ８１０４へと移行して、図９０に示されるような代理人選択ページを生成して、代理人を選択する処理を行う。

当該処理は、図９０の代理人選択ページにおいて、各種の検索条件が指定された状態にて、「代理人を検索」ボタンが選択された際に、当該検索条件に適合する代理人を代理人テーブル８４０２から抽出し、抽出した代理人をリスト表示するなどして、これに対して依頼者が選択した（リストを全選択するものや任意の者を選択するなど。この際に代理人に対する評価情報を見ることができるようにすることで、選択の参考にさせてもよい）代理人を取得する処理である（これにより取得した代理人のＩＤ（単数または複数）が依頼案件テーブル８５０１に、指定代理人として登録される）。
より具体的には、例えば、図９０の代理人選択ページにおいて、分野が指定された場合には、代理人テーブル８４０２において、当該分野が対応可能分野として登録されている代理人が抽出される。また、実績があるものに限定が選択された場合には、依頼案件テーブル８５０１を参照し、受任代理人としてＩＤが登録されている案件の分野情報と、指定された分野が適合する代理人が抽出される（または除外される）。評価が選択された場合には、それに適合する評価情報を有する代理人（評価テーブル８６０１の情報に基づく）が抽出される。「次の者の代理実績がある代理人」について、例えば具体的な企業名などが入力された場合、依頼案件テーブル８５０１を参照し、受任代理人としてＩＤが登録されている案件の依頼者ＩＤに基づいて得られる名称と合致する場合には、当該代理人が抽出（「指定する」が選択された場合）または除外（「除外する」が選択された場合）される。当該処理は、例えば、特定の企業の代理をしている者に対しては、依頼情報を見せたくないような場合に、当該機能を実現するものである。キーワードについては任意のキーワードの入力に対して、これに合致する代理人を各テーブルの情報に基づいて判別するものである。上記各条件を複数設定することも当然可能である。

上記処理により、代理人が選択され、これにより取得した代理人のＩＤ（単数または複数）が、依頼案件テーブル８５０１（図８５）に指定代理人として登録される（なお実際のテーブルへの登録処理は、Ｓ８１０４ではなく、Ｓ５００２で実行される）ことにより、当該代理人にのみ依頼情報が開示されることとなる（即ち、依頼者が指定した条件に合致する代理人、若しくは直接指名した代理人などに対してのみ依頼情報が開示される）。なお、「依頼内容を送信する代理人に関する情報」について何の設定も行わないことも可能である、その場合には、基本的に登録されている全代理人に対して依頼情報が開示されることとなる（ただし、代理人の側で「不可企業」や「不可分野」を設定していて、依頼がこれに該当する場合のこの限りでない）。

図８９の画面に対して、「入力内容を確認」ボタンか「キャンセル」ボタンの選択を待ち（Ｓ８１０３）、これらのボタンの選択があった以降は、基本的に実施形態１（図６）又は実施形態２（図５０）と同様の処理概念となる。

図８０（依頼者対応サイト処理）に戻って説明を続ける。

トップ画面（図８８）への入力待ち（Ｓ８００３〜Ｓ８００５）において、コメントの表示が選択された場合（案件リストの備考欄の「コメントがあります」がクリックされた場合）には、コメント表示処理を実行する（Ｓ８００４→Ｓ８００７）。

＜＜＜コメント表示処理：図８０のＳ８００７の処理の詳細＞＞＞
依頼者が依頼した案件の内容は、指定条件に合致する代理人（前述の処理によって依頼案件テーブル８５０１の指定代理人にＩＤが登録されている代理人）に対して、システムによって提示され、これに対する代理人側からのコメント（依頼内容に対するアドバイスや解決法の示唆、対応方針の示唆、実際に受任する場合の見積もり情報など）がシステムに入力されることになる（処理概念としては実施形態２と同様）。当該代理人側からのコメントの登録があった場合には、トップ画面（図８８）の案件リスト中の対応する案件に「コメントがあります」という表示がなされ、これが選択された場合に、コメントの表示等を行うのがコメント表示処理である。図８２は、当該コメント表示処理の処理動作を示すフローチャートである。

Ｓ８２０１では、図９１に示されるようなコメント表示ページを生成する。当該コメント表示ページでは左欄に、依頼案件テーブル８５０１から受付番号をキーに取得したタイトル、依頼内容本文が表示され、ページ中央部には、依頼対応案テーブル８７０１（図８７）から受付番号をキーに取得したコメントや見積額とこれを作成した代理人の表示がされる（コメントを提示した代理人が複数いる場合には、複数のコメントが表示されることとなる）。

コメント表示ページ（図９１）では、依頼者がそれぞれのコメントを見て、気に入った案があった場合には、「依頼ボタン」を押すことで当該代理人に依頼をすることができる。また、代理人の名前の部分のリンクを選択すると、当該代理人の評価情報を見ることができ、依頼をするにあたりこれを参考にすることもできる。また、コメントに対する評価もすることができるものとなる。

Ｓ８２０１に続く各処理は、基本的には実施形態２（図５４）と同様の処理概念であるが、実際の依頼があった場合（Ｓ５４０２→Ｓ５４０７→Ｓ５４０８）には、Ｓ８２０２にて、依頼案件テーブル８５０１の該当レコード（受付番号をキーに抽出）の、受任代理人として、当該依頼をした代理人のＩＤを登録する。続くＳ８２０３では課金処理を実行する。本実施形態のシステムでは、システム上で実際に委任が成立した場合（即ち、依頼者と代理人とのマッチングが本システムによって行われた場合）に、代理人側に対して課金をするシステムであるため、Ｓ８２０３では代理人に対する課金処理が行われる（課金処理自体は各種の公知の方法で行うことができる）。

また、代理人のコメントに対する評価が入力をする画面においては（Ｓ５４０６→Ｓ５４１３）、本実施形態においては、当該入力した評価情報を表示（代理人の評価情報を表示させる際の表示）として反映させるタイミングについての設定ができるようにしている（反映条件情報の取得）。
例えば、評価件数が所定件数になるまで表示として反映させないようにするものであり、当該所定件数の設定などを依頼者（評価者）にさせるものである（その他、所定期間の設定をさせるようなものであってもよい）。

コメントに対する評価の入力が終わりこれを受信した際には（Ｓ５４１４）、これによって得られた評価情報と、反映条件情報、ＩＤ（代理人、評価者（依頼者）の双方）等を受付番号に対応付けて評価テーブル８６０１（図８６）に格納する（Ｓ８２０４）。
当該処理により、評価情報に依頼者ＩＤが対応付けられるため、依頼者の属性情報も対応付けられることとなる。これにより、評価情報の表示処理（例えば図８２のＳ５４１１）では、依頼者の属性情報に応じた集計処理をした評価情報の表示処理を行わせることができる。例えば、本システムが実施形態２のごとく、弁理士と依頼者のマッチングをするシステムであるとした場合、依頼者の属性（例えば個人であるのか、法人の従業者であるのかや、知財や法務職であるのか、開発職であるのか、といった情報）に基づいて、個人からはどういう評価を受けているのか？開発職からの評価はどうなっているのか？といった多様な観点からの評価情報を見ることが可能となるものである。なお、ここでは評価項目や評価画面についての具体例を示していないが、これらについては各代理業における特性を反映するなどして、適宜定められるものである。

また、Ｓ８２０４では、評価者（依頼者）の登録情報の量に応じて所定割合（適宜設定される）で付与されるポイントを、依頼者テーブル８４０１（図８４）に格納する処理が実行される。「登録情報の量」とは、依頼者テーブル８４０１（図８４）に登録されている情報（属性情報）の多さである。上記のごとく、多様な観点からの評価の表示をさせるためには、依頼者の属性情報が登録されている必要がある。しかし、当該情報の登録を必須とするのは運用上困難な面もあるため、基本的には依頼者が任意に登録するものとなり、なんらかのインセンティブがなければなかなか登録されないことが考えられる。よって、当該インセンティブとなるように、属性情報をより多く登録した上で、評価を行った者に対しては、より多くのポイントを付与するものである。なお本実施形態においては当該ポイントの具体的な利用について説明していないが、ポイントの利用方法については適宜定めればよいものである（例えば、代理人に実際に依頼を行った場合に、依頼者が代理人に支払う報酬として当該ポイントを利用できるなど）。

図８０（依頼者対応サイト処理）に戻って説明を続ける。

コメント表示処理（Ｓ８００７）の終了後は、Ｓ８００２に戻って処理を続行する（図８８のトップページに戻る）。当該ページに対するＳ８００３〜Ｓ８００５の操作待ちのループにおいて、終了ボタンの選択があった場合には（Ｓ８００５）、依頼者対応サイト処理を終了する。

以上の、依頼者対応サイト処理により、依頼者に対して、依頼の受付、これに対する代理人からのコメントの提示、当該コメントや代理人評価、口コミ情報を参考にした実際の依頼、コメントに対する評価情報の入力といった各種のサービスを提供することができるものである。

次に、代理人側からの本システムの利用に関する説明を行う。

＜＜代理人対応サイト処理：図７９のＳ４８０６の処理の詳細＞＞
代理人からのログイン要求があった場合には代理人対応サイト処理が実行される（図７９：Ｓ４８０４→Ｓ４８０６）。図８３は、当該代理人対応サイト処理の処理動作を示すフローチャートである。

Ｓ８３０１では、図９２に例示したような代理人用のサイト画面を生成する処理を実行する。当該代理人用サイトのトップページは、ログインした代理人に対して適合する依頼案件を表示するものである。
「適合する」とは、前述のごとく、依頼者側が設定した開示条件に適合しているということであり、具体的には依頼案件テーブル８５０１（図８５）の指定代理人として、自己のＩＤが登録されている案件が抽出されるものである。また、代理人が対応不可分野や、対応不可企業などの情報を登録している場合には、依頼者側の設定した開示条件に適合していても表示対象にはしない。具体的には、依頼案件テーブル８５０１の指定代理人として、自己のＩＤが登録されている案件について、当該依頼案件テーブル８５０１から取得される分野や依頼者情報が、代理人テーブル８４０１（図８４）の不可分野や不可企業の情報に対応する場合には、当該案件については、表示対象とはしないものである。これは、代理人側においてコンフリクト等の事情により、受任できない案件ことがわかっているものについては、表示対象から除外しているものである。なお、ここでは例として不可分野や不可企業を挙げているが、これに限られず、各代理業の特性などに応じて適宜定められるものである。

上記処理概念により抽出された案件について、依頼案件テーブル８５０１（図８５）から必要な情報を取得し、図９２に例示したような代理人用のサイト画面を生成し、これを表示する。なお、受付番号と自己の代理人ＩＤをキーにして依頼対応案テーブル８７０１を参照し、該当するレコードがある場合には、図９２の「作成」の欄を「済」とし、レコードが無かった場合には、「未」としたうえで作成ボタンを割り当てる。依頼の有無についての表示については、依頼案件テーブル８５０１（図８５）の該当受付番号のレコードの受任代理人として自己のＩＤがあるか否かによって判別・表示を行う。

図９２の代理人用のサイト画面の表示処理（Ｓ８３０１）の後は、基本的に実施形態２（図５５）と同様の処理概念であるので、ここでの説明を省略する。なお、Ｓ５５０８における評価の表示処理においては、前述のごとく、依頼者の属性に応じた多様な表示処理が可能となりものである。また、評価テーブル８６０１（図８６）に反映条件が設定されている場合には、当該条件に沿った評価の集計・表示処理となる。例えば、評価が１０件を超えるまで表示対象にしないように設定されている場合には、評価テーブル８６０１で代理人ＩＤをキーにして存在するレコードの数を抽出し、これが１０件なかった場合には、当該評価情報を評価の集計・表示処理対象から除外するものである。これにより、評価者（依頼者）の望むタイミングで、代理人側に評価情報が提示されることとなる。また、反映条件として所定期間が設定されている場合には、依頼案件テーブル８５０１から依頼日を取得して、当該依頼日から所定期間が経過するまでは、評価情報を評価の集計・表示処理対象から除外する処理となる。

以上のごとく、本実施形態の代理人マッチング支援システムによれば、依頼者から得られた依頼情報を、代理人側に提示し、依頼情報の内容に応じた対応情報（依頼内容に対するアドバイスや解決法の示唆、対応方針の示唆など）の入力を受付け、得られた対応情報を依頼者に提示する処理がシステムによって行われる。これにより、本サービスの提供を受ける依頼者は、依頼情報の内容に基づき代理人によって作成された対応情報を確認することができる。
また、代理人ＩＤと対応可能条件情報（例えば、自己の専門分野情報や、業種、納期、金額など様々なものが考え得る）又は／及び対応不能情報（同様に分野情報や、業種、納期、金額、対応できない具体的企業名など様々なものが考え得る）とが対応付けて記憶されており、依頼時に対応条件情報（同じく分野情報や、業種、納期、金額、具体的企業名など様々なものが考え得る）を取得して、これらに基づいて、適合する代理人に対して依頼情報の提示がなされるため、効率的なサービスを提供することができる。また、不必要に依頼情報が提示されることが抑制されるため、秘密保持の観点からも優れる。
また、依頼情報の内容に基づき代理人によって作成された対応情報に対する評価情報が当該代理人に対応付けられて記憶され、依頼者からの要求又は代理人からの要求に応じて、当該評価情報が提示されることになるため、実際の対応情報（即ち代理人の提供したサービスの質）を見た上でその能力を評価した情報を提示するサービスを提供することができる。
また、評価情報と依頼者の属性情報とが対応付けて記憶されるため、評価情報の提示の際に依頼者（＝評価者）の属性情報に応じた表示をさせることが可能となるものである。
また、評価情報が所定数に至るまで又は所定期間が経過するまでは、評価情報を提示対象にしないため、評価された代理人に、誰かその評価情報を入力したか直ぐに察しがついてしまうようなことが抑止される。
より多くの属性情報を登録した上で評価情報を入力した依頼者に対して、より多くの特定サービス情報（例えばポイントやキャッシュバック情報など）を対応付けるといったことが可能となる。即ち、本システムの価値を高めるためには評価情報の豊富化（＝ＤＢとしての価値向上）が不可欠であるため、より情報の豊富化をしてくれた依頼者に対してより優遇したサービスを提供することにより、ＤＢの価値向上につながる行動へのインセンティブを与えるものである。

なお、上述した各実施形態において、依頼者側から送信される情報（技術情報ファイルや依頼情報）は、秘密性の高い情報であるため、当該情報の送受信においては、ＳＳＬ等の暗号化をして情報を送信するプロトコルを使用することが望ましい。本発明に関するシステムでは、依頼者以外では、基本的には有資格者がログインするものを想定しているため、守秘義務を有するもののみがアクセスすることが想定されているものではあるが、誰がアクセスしたかを依頼者側が確認できるように、技術情報ファイルや依頼情報にアクセスした代理人ＩＤを記憶しておくようにしておくようにしてもよい。さらに、技術情報ファイルや依頼情報にアクセスさせる際に、守秘義務契約を締結させるものとしてもよい。当該守秘義務契約の締結には、電子署名を利用することで、当事者自身が契約したものであることを電子的に担保することができるようにしてもよい（電子署名を利用することで、システム的に処理させることができる。具体的には、例えば、システムによって定型の守秘義務契約の文面を提示し（依頼者側、及び代理人側の氏名を自動挿入する等してもよい）、これを代理人側が承諾する場合には、代理人がこれに電子署名を施して返す（システム側でこれを保持しておく）ようなもの等）。

１１１出願用ファイル作成支援サーバ、１１２出願用ＨＴＭＬＤＢ（外部記憶装置）、１１３管理者ＰＣ（管理者端末装置）、１１４申請ファイルＤＢ（外部記憶装置）、１２１研究者ＰＣ（発明者端末装置）、１１１１１ＣＰＵ（制御部、演算部）、１１１１２メモリ（記憶部）、１１１１３通信部、１１１２記憶装置（記憶部）、４７１出願用ファイル作成支援サーバ、４７２顧客ファイルＤＢ、４７８特許事務所ＰＣ（代理人端末装置）、４７９顧客ＰＣ（顧客端末装置）

Claims

特許出願又は実用新案登録出願のための出願書類の作成を支援する出願用ファイル作成支援サーバであって、制御部と、記憶部と、通信部と、ファイル画像化部と、前記通信部によってネットワークを介して技術情報ファイル及び発明者情報を取得しこれを対応付けて前記記憶部又は外部記憶装置に記憶させる技術情報ファイル取得部と、当該発明者情報を使用して願書部分を自動生成する願書生成部と、前記技術情報ファイルを前記ファイル画像化部によって画像ファイルへ変換し、当該画像ファイルを表示させるタグを、前記記憶部又は外部記憶装置に設定されているひな型ファイルの段落番号の次に挿入した明細書部分を自動生成する明細書自動生成部と、前記生成された願書部分と明細書部分とを用いて電子出願ソフトが受け付ける形式の所定形式出願ファイルを自動生成する出願ファイル生成部と、予め設定された前記記憶部の記憶領域に前記所定形式出願ファイルを格納する又は予め設定された外部装置の記憶領域に前記所定形式出願ファイルを格納するために前記通信部から情報を送出するファイル格納処理部と、を備えることを特徴とする出願用ファイル作成支援サーバ。
前記ファイル画像化部は、前記技術情報ファイルに対応するアプリケーションソフトの印刷機能を利用して印刷出力データを取得し、当該印刷出力データから前記画像ファイルへの変換を実行することを特徴とする請求項１に記載の出願用ファイル作成支援サーバ。
出願ファイルの管理情報として出願日が対応付けられた出願ファイル管理テーブルを備え、
日時機能部と、当該日時機能部によって得られる日付と、前記出願ファイルに対応付けられた出願日とを比較し、これが予め設定されている期間を超えたか否かを判別し、これを超えた前記出願ファイルについての出願取下書を自動生成する出願取下書生成部を備えることを特徴とする請求項１又は請求項２に記載の出願用ファイル作成支援サーバ。
制御部と、演算部と、記憶部と、を備える情報処理装置に、技術情報ファイル及び発明者情報を取得しこれらを対応付けて前記記憶部若しくは外部記憶装置に記憶させるステップと、当該発明者情報と予め前記記憶部又は外部記憶装置に設定されているひな形ファイルを使用して前記演算部によって願書部分を自動生成するステップと、前記演算部によって前記技術情報ファイルを画像ファイルへ変換するステップと、前記ひな形ファイルに対して前記演算部によって段落番号の次に前記画像ファイルを表示させるタグを挿入することで明細書部分を自動生成するステップと、当該自動生成されたファイルを所定のファイル形式である所定形式出願ファイルにて予め設定された前記記憶部の記憶領域又は予め設定された外部装置の記憶領域に保存させるステップと、を実行させることを特徴とする出願用ファイル作成支援プログラム。
前記技術情報ファイルを画像ファイルへ変換するステップにおいて、当該技術情報ファイルに対応するアプリケーションソフトの印刷機能を実行させて印刷出力データを取得し、当該印刷出力データから前記画像ファイルへの変換を実行する処理を行うことを特徴とする請求項４に記載の出願用ファイル作成支援プログラム。
前記技術情報ファイル及び発明者情報の取得処理において出願予定日情報若しくは前記技術情報ファイルの公開予定日情報もあわせて取得するステップと、当該出願予定日情報若しくは公開予定日情報から直接または間接的に導出される日時に対応する日別フォルダに前記所定形式出願ファイルを格納するステップと、を実行させることを特徴とする請求項４又は請求項５に記載の出願用ファイル作成支援プログラム。
前記技術情報ファイル及び発明者情報の取得処理において出願予定日情報若しくは前記技術情報ファイルの公開予定日情報もあわせて取得するステップと、
出願用ファイル作成支援プログラムによって自動生成された出願であることを示す情報を含んだ整理番号情報を自動生成するステップと、前記願書部分の自動生成処理において当該整理番号情報も使用して願書部分を生成するステップと、前記出願予定日情報若しくは公開予定日情報から直接または間接的に導出される日時に至った際に、当該日時に対応する前記所定形式出願ファイルの前記整理番号情報を取得するステップと、当該整理番号情報に基づいて、電子出願ソフトの出願処理によって得られる受理済みファイルが格納されるフォルダを検索して当該整理番号情報に対応する受理済みファイルが無かった場合、又は、電子出願ソフトから出力される一覧出力ファイルを検索して当該整理番号情報に対応する出願予定日情報若しくは出願番号情報が無かった場合に警告情報を出力するステップと、を実行させることを特徴とする請求項４乃至請求項６の何れか一つに記載の出願用ファイル作成支援プログラム。
前記発明者情報に基づいて発明者が従業者であるか否かを判別するステップと、当該判別処理によって従業者で無い発明者が含まれていると判断された場合には、管理者からの承認情報の入力があるまで前記所定形式出願ファイルの自動生成処理の実行処理を行わないことを特徴とする請求項４乃至請求項７の何れか一つに記載の出願用ファイル作成支援プログラム。
前記技術情報ファイル及び発明者情報の取得処理において出願予定日情報若しくは前記技術情報ファイルの公開予定日情報もあわせて取得するステップと、前記出願予定日情報若しくは公開予定日情報から直接または間接的に導出される日時までの期間が予め設定されている基準期間より長いか否かを判別するステップと、これが長い場合に前記所定形式出願ファイルの自動生成処理の実行をさせないステップと、を実行させることを特徴とする請求項４乃至請求項８何れか一つに記載の出願用ファイル作成支援プログラム。
前記技術情報ファイルがカラーであることを要するか否かの情報を取得するステップ若しくは前記技術情報ファイルがカラーであるか否かを自動判別するステップと、前記技術情報ファイルがカラーである場合には、前記願書部分の自動生成において外国語書面のひな形ファイルを利用し、前記明細書部分の自動生成処理に替えて、前記技術情報ファイルがPDFファイルでなかった場合にはこれをPDFファイルに変換し「外国語書面」の項目名に対してこれを張り付けるステップと、を実行させることを特徴とする請求項４乃至請求項９の何れか一つに記載の出願用ファイル作成支援プログラム。
出願ファイルの管理情報として出願日が対応付けられた出願ファイル管理テーブルから取得した、出願ファイルの出願日からの経過期間が予め設定されている取下げ通知期間に至ったか否かを判別するステップと、これに至った場合には取下げ時期を通知する情報を出力するステップ又は取下げ通知期間に至った出願についての出願取下書を自動生成するステップと、を実行させることを特徴とする請求項４乃至請求項１０の何れか一つに記載の出願用ファイル作成支援プログラム。
制御部と、演算部と、記憶部と、を備える情報処理装置に、ログイン処理を行うステップと、技術情報ファイル及び発明者情報を取得しこれらとログイン者情報とを対応付けて前記記憶部若しくは外部記憶装置に記憶させるステップと、当該発明者情報と予め前記記憶部又は外部記憶装置に設定されているひな形ファイルを使用して前記演算部によって願書部分を自動生成するステップと、前記演算部によって前記技術情報ファイルをページごとに画像ファイルへ変換するステップと、前記ひな形ファイルに対して前記演算部によって自動生成した各段落番号の次に前記各画像ファイルを表示させるタグを挿入することで明細書部分を自動生成するステップと、当該自動生成されたファイルを所定のファイル形式である所定形式出願ファイルとして保存するステップと、を実行させることを特徴とする出願用ファイル作成支援プログラム。
前記演算部によって電子出願ソフトを起動させるステップと、当該電子出願ソフトに前記所定形式出願ファイルの出願処理を実行させるステップと、を実行させることを特徴とする請求項４乃至請求項１２の何れか一つに記載の出願用ファイル作成支援プログラム。
前記記憶部に代理人のＩＤ情報を含むログイン情報が格納されており、当該代理人からのログインがあった場合に前記技術情報ファイル又は前記所定形式出願ファイル又は前記電子出願ソフトから取得される出願ファイルを提示させるステップと、これに対応するクレーム案の入力を前記代理人に求め、これにより得られたクレーム案情報を取得して前記代理人のＩＤ情報と対応付けて記憶するステップと、前記技術情報ファイルに対応付けられたログイン者に対して当該クレーム案を提示するステップと、を実行させることを特徴とする請求項１２に従属する請求項１３に記載の出願用ファイル作成支援プログラム。
前記ログイン者に対してクレーム案を提示した際に、当該クレーム案に対する評価情報の入力を求め、これにより得られた評価情報を、当該クレーム案を入力した代理人のＩＤと対応付けて記憶するステップと、顧客からの要求又は代理人からの要求に応じて、当該評価情報を提示させるステップと、を実行させることを特徴とする請求項１４に記載の出願用ファイル作成支援プログラム。