JP2023050643A - 情報処理システム、及び情報処理装置 - Google Patents

Abstract

【課題】通信により交換される、他の文書との関連性が存在し、且つ文字列の大部分が共通した文書に存在する文字列の修正が可能な情報処理システム、及び情報処理装置を提供すること。【解決手段】サービス提供会社ＷＡは、利用登録した事業者を対象に、事業者間の文書ファイルＤの交換を中継するサービスを提供する。交換される文書ファイルＤは、ストレージＳＴ上に送付先別に確保された個別保管領域ＳＡに保管される。Ｂ社ＣＢからの納品書の文書ファイルＤは、Ａ社ＣＡの個別保管領域ＳＡに保管し、Ａ社ＣＡへの送信は、その画像を配置させたＷｅｂページの形で行う。画像上の文字列の少なくとも一部は修正可能にさせる。それにより、Ａ社ＣＡでの文字列の修正を文書ファイルＤに反映させたものが修正文書ファイルＳＤとして、Ｂ社ＣＢの個別保管領域ＳＡに保管される。【選択図】図１

Description

特許法第３０条第２項適用申請有り （１）令和３年１月１８日、令和３年４月１５日、Ｆ－ＬＩＮＥ株式会社の伝票電子化検討会議、及び実証実験にて、開発するシステムの仕様、及び開発したシステムを公開した。 （２）令和３年７月８日、デジタルロジスティクス推進協議会の実証実験にて、開発したシステムを公開した。

本発明は、情報処理システム、及び情報処理装置に関する。

従来、商品の配送では、商品の配送者と、商品の配送先との間で納品書、及び受領書の受け渡しが行われている。納品書は、例えば商品の配送元、及び配送先の各住所、及び各名称等とともに、配送される商品、及びその数等が記載された文書である。受領書は、配送された商品、及びその個数等が適切であることを配送先が確認したことを示す文書である。以降、便宜的に、商品の配送元、及び配送先の各住所、及び各名称等の情報は「配送関係情報」、商品、及びその数等の配送される商品を表す情報は「配送商品情報」とそれぞれ総称する。多くの場合、受領書としては、納品書と内容的には同じもの、つまり同じ配送関係情報、及び同じ配送商品情報が記入されたものが用いられる。

これまで、納品書、及び受領書は、印刷物の形で扱われている。現在では、それらの文書を電子化したファイルとして扱い、通信を用いた送受信により交換することも行われている（例えば、特許文献１参照）。それらを通信により交換する場合、それらの受け渡しにおける位置的な制約が排除される。例えば納品書では、配送者が納品書を受け取るための移動を不要にできる。一方の受領書では、配送先から受け取った後、その受領書を届けるべき場所への移動を不要にできる。このようなことから、納品書、及び受領書の電子化しての交換により、利便性も向上する。

特開平０９－３１１８８８号公報

納品書に入力された配送商品情報の内容に誤り等がある場合がある。配送された商品の種類、或いはその数に誤りがある場合もある。配送された商品の何れかの破損等により、納品できない商品が発生する場合もある。何れの場合も、納品書の内容の一部が不適切なものとなる。そのため、内容的には同じ受領書では、その内容を修正可能なようにすることも重要と考えられる。
配送関係情報、及び配送商品情報ともに、１文字以上の文字列で表される情報である。このことから、内容の一部の修正は、修正すべき文字列の修正となる。このような文字列を修正すべき状況は、事業者間で交換される他の文書との関連性が存在し、且つ文字列の大部分が共通した文書でも生じるものと考えられる。なお、このような関係にある２つの文書は、納品書と受領書と同様に、送付先が異なるのが普通である。

そこで、本発明は、通信により交換される、他の文書との関連性が存在し、且つ文字列の大部分が共通した文書に存在する文字列の修正が可能な情報処理システム、及びその修正を可能にさせる情報処理装置を提供することを目的とする。

本開示の第１の態様の情報処理システムは、第１の事業者が使用する第１の端末、前記第１の事業者と電子化された文書ファイルの交換を行う第２の事業者が使用する第２の端末、並びに前記第１の端末、及び前記第２の端末と通信可能であり、前記通信を用いて、前記文書ファイルの交換を実現させる情報処理装置を備え、前記情報処理装置は、前記第１の事業者から受信された第１の文書ファイルの画像を、前記画像上に存在する文字列を修正可能な状態で配置させたＷｅｂページを作成するページ作成手段と、前記ページ作成手段により作成された前記Ｗｅｂページを、前記第２の端末に送信させることが可能なページ送信制御手段と、前記ページ送信制御手段により前記Ｗｅｂページが送信された前記第２の端末から、前記画像上の前記文字列に対して修正された結果を表す修正情報を受信した場合に、前記修正情報を反映させた前記第１の文書ファイルを第２の文書ファイルとして保管させる保管制御手段と、前記第１の端末に、前記保管制御手段により保管された前記第２の文書ファイルを送信させることが可能なファイル送信制御手段と、を備え、前記第１の端末は、前記第１の文書ファイルの送信、及び前記第２の文書ファイルの受信が可能であり、前記Ｗｅｂページを受信した前記第２の端末は、入力装置への操作により、前記情報処理装置から受信した前記Ｗｅｂページの前記画像上に配置されている前記文字列が修正可能な修正手段と、前記修正手段により前記画像上の前記文字列に対して修正された結果を表す前記修正情報を送信可能な修正情報送信手段と、を備える。

本開示の第１の態様の情報処理装置は、第１の事業者から受信された第１の文書ファイルの画像を、前記画像上に存在する文字列を修正可能な状態で配置させたＷｅｂページを作成するページ作成手段と、前記ページ作成手段により作成された前記Ｗｅｂページを、第２の事業者で使用される第２の端末に送信させることが可能なページ送信制御手段と、前記ページ送信制御手段により前記Ｗｅｂページが送信された前記第２の端末から、前記画像上の前記文字列に対して修正された結果を表す修正情報を受信した場合に、前記修正情報を反映させた前記第１の文書ファイルを第２の文書ファイルとして保管させる保管制御手段と、前記第１の事業者で使用される第１の端末に、前記保管制御手段により保管された前記第２の文書ファイルを送信させることが可能なファイル送信制御手段と、を備える。

本発明は、通信により交換される、他の文書との関連性が存在し、且つ文字列の大部分が共通した文書に存在する文字列の修正を行うことができる。

本発明の情報処理装置の一実施形態に係るＡＰサーバによりサービス提供会社が提供するサービスの例の概要を説明する図である。 本発明の情報処理装置の一実施形態に係るＡＰサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。 本発明の情報処理装置の一実施形態に係るＡＰサーバのハードウェア構成の一例を示すブロック図である。 本発明の情報処理装置の一実施形態に係るＡＰサーバ上に実現される機能的構成の一例を示す機能ブロック図である。 文書処理制御部によって実現される文書ファイルの交換の仕組みの例を説明する図である。 文書ファイル中で自動認識の対象となる文字列の例を説明する図である。 利用依頼設定情報により利用登録を行った非契約事業者の情報を表示するＷｅｂページの例を示す図である。 文書ファイルの保管に係わる情報、及びその関係の例を説明する図である。 納品書の文書ファイルによって表される画像が配置されたＷｅｂページの例を示す図である。 文字列の修正が可能な状態のＷｅｂページの例を示す図である。 入力フィールドの選択後の表示例を示す図である。 １文字列の修正後のＷｅｂページの例を示す図である。 別の形式の納品書の画像例を示す図である。 別の形式の納品書をベースに生成される他の文書の画像例を示す図である。

以下、本発明を実施するための形態について、図を参照しながら説明する。なお、説明する実施形態は、あくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。本発明の技術的範囲には、様々な変形例も含まれる。

図１は、本発明の情報処理装置の一実施形態に係るＡＰ（APplication）サーバによりサービス提供会社が提供するサービス（以降「本サービス」と表記）の例の概要を説明する図である。
サービス提供会社ＷＡは、文書の交換を必要とする複数の事業者のうちの少なくとも１事業者を顧客として、その複数の事業者間のネットワークを介した文書の送受信を中継する形の文書交換を実現させる本サービスを提供する。複数の事業者のうちの少なくとも１事業者が顧客、つまりサービス提供会社ＷＡの契約者であれば良いのは、その１事業者の文書を他の全ての事業者に中継するような場合も想定されるからである。そのような場合、他の全ての事業者が顧客でなくても、契約者である１事業者の文書を他の全ての事業者が受信できるようにしなければならない。

事業者は、個人、或いは企業等の組織である。図１では、事業者の例として、Ａ社ＣＡ、Ｂ社ＣＢの２つの会社を示している。図１の説明では、事業者の表記として、「Ａ社ＣＡ」、「Ｂ社ＣＢ」を用いる。事業者を想定する必要のないような場合には、表記として「事業者」を用いる。
Ｂ社ＣＢは、例えば製品Ｐを製造し、製造した製品Ｐを商品として販売する受注側企業である。商品である製品Ｐは、発注した企業に対し、配送等により納品される。Ｂ社ＣＢが販売する商品は、他社から購入した商品であっても良い。他方のＡ社ＣＡは、Ｂ社ＣＢに対し、そのＢ社ＣＢが製造し販売する製品Ｐを発注（購入）する側の発注側企業である。以降、混乱を避けるために、製品Ｐは「商品Ｐ」と表記する。また、Ａ社ＣＡ、Ｂ社ＣＢはともに顧客、つまりサービス提供会社ＷＡと契約した企業と想定する。

発注側企業と受注側企業との間で取り引きが行われる場合、その２つの企業間では各種文書交換が行われる。ここで、理解を容易とするために、従来、行われていた例を説明する。
例えば発注側企業は、受注側企業から購入する商品を決定し、決定した商品を購入するための発注書を作成して受注側企業にメール等により送付する。発注書が送付された受注側企業は、送付された発注書を受け取った旨をメール等で発注側企業に通知する一方、発注書で指定された商品を発注側企業に配送する準備を行い、数を含め指定された商品を発注側企業に配送する。配送する準備には、配送の際、発注側企業に渡すべき納品書、及び発注側企業から受け取るべき受領書の作成が含まれる。それにより、発注書の交換の後、納品書、及び受領書の交換が行われる。実際の商品の配送は、多くの場合、依頼した配送業者によって行われる。

納品書には、例えば商品の配送元、及び配送先の各住所、各名称、及び電話番号等を表す配送関係情報、並びに商品、及びその数等の配送される商品を表す配送商品情報が印刷されている。これは、受領書でも同じである。そのため、納品書と受領書とは、関連性が存在し、且つ文字列の大部分が共通した文書（帳票）となっている。
発注側企業は、納品されるべき商品が実際に存在するか否かを確認して、商品を受け取る検収を行う。検収（検品）では、納品された商品に視認できる不具合、例えば破損等があるか否かの確認も行われる。それにより、納品書に記載されていない商品、及び許容できない不具合が確認された商品等は返品される。

検収後、発注側企業は、受領書を配送業者に渡す。発注側企業は、納品された商品を確認したことを表すために、例えば印（受領印）を押印するか、或いはサインした受領書を配送業者に渡す。このことから、受領書は、納品された商品を発注側企業が確認したことを示す文書となる。内容的には同じ文書であっても、納品書は発注側企業宛の文書、受領書は受注側企業宛の文書である。このこともあり、それらは明確に区別される。
商品の納品後、受注側企業は、発注側企業から代金の支払いを求めるための請求書を作成し発行する。発行された請求書は、発注側企業に送付される。その請求書の送付により、発注側企業は、銀行振り込み等により、受注側企業に代金を支払う。

このように、商品取り引きを行う２つの企業の間では、１回の取り引きにより、上記のような複数回の文書交換が行われる。文書交換は、これまで郵送、或いはメール等により行われるのが一般的である。本サービスでは、郵送、及びメール以外での各種文書交換を可能にする。

図１に示すように、Ａ社ＣＡとＢ社ＣＢとの間で商品Ｐの取り引きが行われる場合、Ａ社ＣＡとＢ社ＣＢとの間でも、上記のような各種文書交換が行われることが想定される。本サービスは、各種文書交換の全て、或いはそのうちの一部の実現に用いることができる。本サービスでは、ネットワークを介した通信を利用しての文書の送受信により、文書交換を実現させる。ネットワークを介して文書を送受信するため、文書としては、基本的に電子化された文書ファイルＤ、つまりデータが対象となる。なお、文書ファイルＤのファイル形式等は、特に限定されない。例えば文書ファイルＤは、ＰＤＦ（Portable Document Format）ファイル等であっても良い。本サービスでは、事業者間で交換されるメッセージを文書ファイルＤとして扱うことにより、メッセージ交換もサポートする。

文書ファイルＤは、送付すべき事業者にのみ送付する必要がある。各事業者は、本サービスの利用のために、様々な端末（ＰＣ（Personal Computer）等の通信機能を備えた情報処理装置）を使用することができる。このことから、本サービスでは、顧客か否かに係わらず、本サービスを利用する事業者に利用登録を行わせるようにしている。それにより、本サービスの利用は、利用登録を行った事業者に限定している。利用登録を行った事業者か否かは、端末をサービス提供会社ＷＡに接続させたユーザーにログインを求めることで確認するようになっている。ここでは、便宜的に、ログインはＩＤ（IDentifire）、及びパスワードの入力により行うものと想定する。

サービス提供会社ＷＡには、文書ファイルＤの保管用のストレージＳＴが１つ以上、存在する。このストレージＳＴは、例えばＡＰサーバに搭載、若しくは接続されたものか、或いはＡＰサーバと通信可能な別のサーバに搭載、若しくは接続されたものである。

このストレージＳＴには、事業者毎に、文書ファイルＤの保管のための専用の保管領域である個別保管領域ＳＡが確保されている。個別保管領域ＳＡは、事業者別に用意されており、事業者に対応付けられた個別保管領域ＳＡには、その事業者への送信を想定した文書ファイルＤのみが保管される。例えばＡ社ＣＡ用の個別保管領域ＳＡには、Ａ社ＣＡへの送信を想定した文書ファイルＤのみが保管される。そのようにして、各個別保管領域ＳＡは、対応する事業者に送付すべき文書ファイルＤの保管用となっている。それにより、事業者であるＢ社ＣＢから取り込まれた文書ファイルＤは、Ａ社ＣＡ用の個別保管領域ＳＡに保管される。本サービスでは、このような個別保管領域ＳＡを用いて、文書ファイルＤの送付先を管理し、送付すべき事業者にのみ、文書ファイルＤを送付させるように、事業者間の文書交換を中継する。

個別保管領域ＳＡに保管された文書ファイルＤ等の確認は、その個別保管領域ＳＡが割り当てられた事業者が行えるだけでなく、文書ファイルＤ等を取り込ませた事業者も行えるようにさせている。これは、送付元の事業者が、文書ファイルＤが実際に取り込まれて適切に処理されたか否かを確認できるようにするためである。必要以上の情報が得られないように、送付元の事業者が確認可能な文書ファイルＤは、その事業者から取り込まれた文書ファイルＤのみである。そのような文書ファイルＤの確認を可能にする意味からも、本サービスの利用はログインした事業者に制限している。

上述の文書交換では、受領書は、他の文書である納品書とは明確に区別すべき文書である。受領書は、納品書と同じく、配送、つまり納品された商品を表す文書であっても、それを受け取るべき企業が納品書とは異なる。受領書は、発注側企業が送付元となることから、受け取るべき企業である受注側企業の他に、発注側企業も受け取るべき文書となる。発注側企業にとって、実際に納品される商品は不明である。受注側企業は、何らかの理由により、指定された商品を複数回に分けて配送するようなこともあり得る。このようなことから、受領書は、基本的に、発注側企業が作成する対象ではない。

発注側企業は、納品書に示された商品を実際に受け取れるとは限らない。受注側企業の処理の誤り、或いは配送業者の配送ミス等により、発注側企業が指定した商品が納品されない場合があり得る。単位の誤りにより、指定した数の商品が納品されない場合もあり得る。また、視認する範囲で許容できない不具合が認められる商品を発注側企業が返品するような場合もあり得る。何れの場合であっても、結果として、発注側企業には納品すべき商品が納品されないことになり、受領書の内容、つまり何れか１つ以上の商品の種類、その数、及び単位等を表す１つ以上の文字列は不適切なものとなる。そのため、受領書の内容は、適切なものに修正する必要がある。
本サービスでは、このような受領書の内容の修正をサポートする。図１には、そのための仕組みの例を表している。このことから、Ｂ社ＣＢに用意された文書ファイルＤの文書は納品書である。文書ファイルＤの文書は、納品書と同じような位置付けの別の文書であっても良い。

文書ファイルＤは、例えばＢ社ＣＢにより、サービス提供会社ＷＡに送信される。この文書ファイルＤは、商品Ｐの配送により作成され送信されることから、商品Ｐの配送先であるＡ社ＣＡ用の個別保管領域ＳＡに保管される。なお、サービス提供会社ＷＡは、文書ファイルＤを自動的に取り込むことも可能である。
Ａ社ＣＡ用の個別保管領域ＳＡに保管された文書ファイルＤは、Ａ社ＣＡ側の要求により、Ａ社ＣＡに送信される。納品書は、配送された商品の検収のために参照される文書であり、直ちに内容の確認が行われるのが普通である。このことから、本サービスでは、文書ファイルＤの画像を配置したＷｅｂページの形で文書ファイルＤをＡ社ＣＡに送信する。それにより、本サービスでは、納品書の文書ファイルＤを要求した場合、納品書の内容を閲覧可能な状態で送信することにより、その内容をより迅速に確認できるようにさせている。

このＷｅｂページは、図９～図１２を参照して詳細を後述するが、納品書の画像上で内容、つまり文字列の修正が可能なものである。文字列の修正を可能とすることにより、発注側企業であるＡ社ＣＡは、実際に配送された商品の検収を行った結果に応じて、不適切な文字列を修正することができる。文字列の修正とは別に、配送先が検収したことを表す情報の入力、例えば受領印の押印が可能である。受領印の押印は、例えば電子印鑑を用いて行うものである。このことから、受領印が押印された納品書は、受領書として扱われる。納品書から受領書を生成することから、受注側企業であるＢ社ＣＢは、納品書の文書ファイルＤのみを用意すれば良いようになっている。ここでは、便宜的に、検収したことを表す情報の入力は、受領印の押印によって行われるもののみ想定する。入力する情報は、別のものであっても良く、特に限定されない。

受領印の押印は、納品書の元の内容を変更させることから、納品書の内容を修正する操作と言える。このことから、納品書の内容の修正は、受領印の押印による修正と、文字列の修正と、に大別することができる。ここでは、特に断らない限り、内容の修正は文字列の修正を指す意味で用いる。なお、文字列とは、１文字以上の文字列のことであり、文字の種類としては、ひらがな、漢字、英数字、及び他の各種記号等を挙げることができる。文字列の修正には、既存の文字列の修正、つまり１文字以上の変更、追加、或いは削除だけでなく、既存の文字列が存在しない箇所への１文字以上の追加も含まれる。

受領印の押印が必要なこともあり、Ｗｅｂページが送信されたＡ社ＣＡは、修正内容を表す情報（以降「修正情報」と表記）をサービス提供会社ＷＡに送信する。サービス提供会社ＷＡは、修正情報を文書ファイルＤに反映させたものを修正文書ファイルＳＤとしてＢ社ＣＢ用の個別保管領域ＳＡに保管する。それにより、Ｂ社ＣＢは、受領書である修正文書ファイルＳＤをサービス提供会社ＷＡから受信することができる。本サービスでは、受領書は、納品書とは異なり、直ちに閲覧できるようにすることは求められていないとして、修正文書ファイルＳＤの送信はダウンロードにより行うようにしている。本実施形態において、修正文書ファイルＳＤは第２の文書ファイルに相当し、文書ファイルＤは第１の文書ファイルに相当する。
なお、修正文書ファイルＳＤは、ベースとなる文書ファイルＤの存在に着目した呼称であり、事業者間で交換の対象であることは同じである。そのため、多くの場合、文書ファイルＤと区別する必要はない。このことから、特に断らない限り、「文書ファイルＤ」は、交換の対象となる文書ファイルの総称として用いることとする。

このように、本サービスでは、納品書をベースに、受領印の押印に加え、文字列の修正を可能とさせ、その修正内容を反映させたものを受領書とさせる。そのため、発注側企業は、実際に受け取った商品に応じて、受領書中の文字列を任意に修正させることができる。納品書をベースにさせていることから、修正が必要な文字列のみを修正すれば良い。このことから、発注側企業は、文字列の修正は容易、且つ迅速に行うことができる。この結果、受注側企業は、検収（検品）結果により、発注側企業が必要に応じて納品書の内容が修正された内容の受領書を修正文書ファイルＳＤとして受信することができる。
受注側企業は、修正文書ファイルＳＤにより、発注側企業が実際に受け取った商品を確認できることから、発注側企業が受け取れなかった商品の有無を直ちに確認することが可能である。それにより、発注側企業が受け取れなかった商品が存在していた場合、そのことへの対応も迅速に行えることとなる。

以降は、図２～図１４を参照しつつ、図１に例示する本サービスの実現方法について詳細に説明する。
図２は、本発明の情報処理装置の一実施形態に係るＡＰサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。ネットワーク環境として示すシステムは、本発明の情報処理システムの一実施形態に相当する。

ＡＰサーバ１を用いて構築されたシステムは、ＡＰサーバ１にＤＢ（Data Base）サーバ２、及び１台以上の通信機能を備えたプリンタ５を例えばＬＡＮ（Local Area Network）により接続させて構築したものであり、１つのＷｅｂサイトを実現させている。図２では、ＡＰサーバ１、ＤＢサーバ２、及びプリンタ５がサービス提供会社ＷＡ内に設置されているが、これらはクラウドサービスにより提供されるものであっても良い。このこともあり、ＡＰサーバ１、ＤＢサーバ２、及びプリンタ５は全て、設置場所、提供者は特に限定されない。また、ＡＰサーバ１、及びＤＢサーバ２は、本サービスを提供するうえで主要な情報処理装置であるが、別の情報処理装置、例えばＷｅｂサーバ、或いは／及び、ファイアウォール等が含まれていても良い。ＡＰサーバ１、及びＤＢサーバ２のうちの少なくとも一方が複数台、設置されていても良い。その場合、負荷分散装置（Load Balancer）を更に含めても良い。プリンタ５は、印刷物での文書交換を望む事業者に対応するためのものである。多数の印刷物の印刷に対応可能なように、プリンタ５は、複数台、設置するのが望ましい。

ＡＰサーバ１は、ネットワークＮと直接、或いは間接的に接続されている。このため、ＡＰサーバ１は、ネットワークＮを介した通信が可能な情報処理装置を端末として使用するユーザーに対して本サービスを提供することができる。ユーザーは、多くの場合、利用登録を行った事業者、例えば受注側企業３、或いは発注側企業４等の従業員である。

ＤＢサーバ２は、ＡＰサーバ１からの要求に応じた処理を行うサーバである。ＡＰサーバ１は、取り込んだ、或いはアップロードされた文書ファイルＤをＤＢサーバ２に送信し保管させる。文書ファイルＤ以外の本サービスに係わる情報は、ＡＰサーバ１に保管される。このことから、ＡＰサーバ１は、ＤＢサーバ２を用いて、本サービスを提供する。それにより、図１に示すサービス提供会社ＷＡのストレージＳＴには、ＡＰサーバ１、及びＤＢサーバ２がそれぞれアクセス可能なストレージがともに相当する。

図２では、本サービスを利用する企業として、受注側企業３－１～３－Ｌ、及び発注側企業４－１～４－Ｋを示している。以降、便宜的に、区別する必要のないような場合、符号として受注側企業には「３」、発注側企業には「４」を付すこととする。図１において、受注側企業３にはＢ社ＣＢ、発注側企業４にはＡ社ＣＡがそれぞれ相当する。

このような企業の分類は便宜的なものであり、実際には、必ずしも明確に企業を分類することはできない。これは、受注側企業３であるとともに、発注側企業４である企業も少なくないからである。しかし、ここでは、説明上、便宜的に、企業は受注側企業３、及び発注側企業４のうちの何れか一方に分類されると想定する。

受注側企業３には、図２に示すように、サーバ３１と複数台の端末３２とをネットワーク３３に接続させた構成のシステムが構築されている。サーバ３１に搭載されたストレージ３５には、自動的に取り込むべき文書ファイルＤを保管するための保管領域３６が確保されている。その保管領域３６は、文書ファイルＤを自動的に取り込む場所として受注側企業３自身が指定したものである。そのような保管領域３６を受注側企業３が指定したのは、サーバ３１は常に動作させているものだからである。そのサーバ３１上の保管領域３６を指定することにより、受注側企業３は、任意のタイミングで文書ファイルＤを自動的に取り込ませることができる。その利便性から、本サービスでは、文書ファイルＤを自動的に取り込む場所の他に、その取り込みを行うタイミングも設定可能としている。なお、保管領域３６は、常に動作させるようにした端末３２に搭載のストレージ内に確保された領域であっても良い。保管領域３６は、それが存在するストレージ３５、及びそのストレージ３５にアクセスする情報処理装置を制限するものではない。保管領域３６は、他との区別を明確にするために、以降「取込保管領域３６」と表記する。

事業者間で交換される文書のうちには、定期的に交換が行われるものがあり得る。例えば取り引きを繰り返し行うような事業者間では、処理の煩雑さを抑える意味もあり、請求書を送付するタイミングを決め、決めたタイミングまでの未払い分を１つ以上の請求書で請求するようなことが行われるのが普通である。このような請求書の文書ファイルＤが、取込保管領域３６に保管する文書ファイルＤとして考えられる。この文書ファイルＤは、通常、複数の文書ファイルＤが集約（結合）された集約文書ファイルＤの一部である。

一方、発注側企業４には、１台以上の端末４１が設置されている。その端末４１は、ネットワークＮを介したＡＰサーバ１との通信が可能な情報処理装置である。発注側企業４の従業員は、この端末４１を用いて本サービスを利用することができる。この端末４１は、受注側企業３の端末３２と区別するために、以降「発注側端末４１」と表記する。端末３２は、「受注側端末３２」と表記する。そのような区別を行う必要がないような場合、つまり発注側端末４１、及び受注側端末３２の何れであっても良いような場合、端末は「事業者端末」と表記する。本実施形態において、受注側企業３は第１の事業者、受注側端末３２は第１の端末にそれぞれ相当する。発注側企業４は第２の事業者、発注側端末４１は第２の端末にそれぞれ相当する。

図２では、受注側企業３とは異なり、発注側企業４にはサーバ等を示していない。これは、発注側企業４の大部分では、定期的に交換するような文書はあまり考えられないからである。言い換えれば、サーバ３１のような情報処理装置が本サービスに係わるケースは比較的に少ないと考えられるからである。しかし、図２は、サーバを用いたシステムを発注側企業４が構築していないことを示すものではない。
また、発注側端末４１、及び受注側端末３２ともに、発注側企業４、及び受注側企業３でそれぞれ構築されたシステムのノードでなくとも良い。つまり、それらは、スマートフォン、或いはタブレットＰＣ等の携帯可能であり、且つ使用場所を選ばないような端末であっても良い。このことから、受注側端末３２、及び発注側端末４１ともに、従業員の私物であっても良い。

図３は、本発明の情報処理装置の一実施形態に係るＡＰサーバのハードウェア構成の一例を示すブロック図である。次に図３を参照し、ＡＰサーバ１のハードウェア構成例について具体的に説明する。なお、この構成例は１例であり、ＡＰサーバ１のハードウェア構成はこれに限定されない。

ＡＰサーバ１は、ＣＰＵ（Central Processing Unit）１１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、バス１４と、入出力インターフェース１５と、出力部１６、入力部１７と、記憶部１８と、２つの通信部１９、２０と、ドライブ２１と、を備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、或いは／及び記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。ＡＰサーバ１として機能させるアプリケーション・プログラム、つまり本サービスの提供用に開発されたプログラムは、例えば記憶部１８に記憶されている。そのプログラムをＣＰＵ１１がＲＡＭ１３に読み出して実行することにより、ＡＰサーバ１は、受注側企業３、及び発注側企業４に対し、本サービスを提供することができる。

ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。そのデータには、ＣＰＵ１１が実行する各種プログラムも含まれる。
ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、２つの通信部１９、２０及びドライブ２１が接続されている。

出力部１６は、例えば液晶等のディスプレイを含む構成である。出力部１６は、ＣＰＵ１１の制御により、各種画像を表示する。出力部１６は、ＡＰサーバ１に搭載されたものであっても良いが、必要に応じて接続されるものであっても良い。つまり、出力部１６は、必須の構成要素ではない。

入力部１７は、例えばキーボード等の各種ハードウェア釦等を含む構成である。その構成には、マウス等のポインティングデバイスが１つ以上、含まれていても良い。操作者は、入力部１７を介して各種情報を入力することができる。この入力部１７も、ＡＰサーバ１に搭載されたものであっても良いが、必要に応じて接続されるものであっても良い。つまり、入力部１７も、必須の構成要素ではない。

記憶部１８は、例えばハードディスク装置、或いはＳＳＤ（Solid State Drive）等の補助記憶装置である。データ量の大きいデータは、この記憶部１８に記憶される。この記憶部１８は、図１に示すサービス提供会社ＷＡのストレージＳＴの１つに相当する。

通信部１９は、ネットワークＮを介した受注側企業３、及び発注側企業４のそれぞれで使用される情報処理装置との間の通信を可能にする。図２に示すサーバ３１、受注側端末３２、及び発注側端末４１は全て、その情報処理装置に相当する。通信部２０は、ＤＢサーバ２との間の通信を可能にする。以降、混乱を避けるために、通信部１９は「端末通信部１９」、通信部２０は「ＤＢ通信部２０」とそれぞれ表記する。

ドライブ２１は、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリカード等のリムーバブルメディア２５を着脱可能な装置である。ドライブ２１は、例えば装着されたリムーバブルメディア２５からの情報の読み取り、及びリムーバブルメディア２５への情報の書き込みが可能である。それにより、リムーバブルメディア２５に記録されたプログラムは、ドライブ２１を介して、記憶部１８に記憶させることができる。また、ドライブ２１に装着されたリムーバブルメディア２５は、記憶部１８に記憶されている各種データのコピー先、或いは移動先として用いることができる。

このようなＡＰサーバ１が備えるハードウェア資源は、アプリケーション・プログラムを含む各種プログラムによって制御される。その結果、ＡＰサーバ１は、受注側企業３、及び発注側企業４に対して本サービスを提供することができる。各種プログラムには、ＯＳ（Operating System）が含まれる。本サービスを提供するためのアプリケーション・プログラムは、そのＯＳ上で動作する。

ＤＢサーバ２としては、ＡＰサーバ１のハードウェア構成と基本的に同じものを採用することができる。そのため、ここでの詳細な説明は省略する。ただし、ＤＢサーバ２を構成する記憶部としては、より大容量のストレージが搭載されているのが望ましい。その記憶部は、ＤＢサーバ２に搭載されたものであっても良いが、ＤＢサーバ２に接続されたものであっても良い。ここでは、ＡＰサーバ１、及びＤＢサーバ２ともに、記憶部は搭載されたもののみ想定する。
受注側端末３２、及び発注側端末４１も、ＡＰサーバ１のハードウェア構成と基本的に同じものを採用することができる。しかし、これら事業者端末では、出力部１６、及び入力部１７は搭載されているか、或いは接続させている必要がある。２つの通信部１９、２０のうちの一方が搭載されているか、或いは接続されていれば良い。ドライブ２１は搭載されていなくとも良い。

図４は、本発明の情報処理装置の一実施形態に係るＡＰサーバ上に実現される機能的構成の一例を示す機能ブロック図である。次に図４を参照しつつ、ＡＰサーバ１上に実現される機能的構成の例について詳細に説明する。

ＡＰサーバ１のＣＰＵ１１上には、機能的構成として、図４に示すように、振分制御部１１１、企業登録部１１２、認証部１１３、文書処理制御部１１４、データ管理部１１５、自動分割部１１６、設定管理部１１７、アクセス制御部１１８、通知制御部１１９、及び辞書登録部１２０が実現されている。これらは、上記アプリケーション・プログラムを含む各種プログラムをＣＰＵ１１が実行することにより実現される。その結果として、記憶部１８には、企業登録情報格納部１８１、企業マスター格納部１８２、パッケージ情報格納部１８３、操作記録情報格納部１８４、オブジェクトリスト格納部１８５、設定情報格納部１８６、修正設定情報格納部１８７、及び辞書格納部１８８が情報格納用に確保されている。
文書処理制御部１１４、データ管理部１１５、及び自動分割部１１６は、図１に示すような修正文書ファイルＳＤの生成、保管の実現に特に重要な構成要素である。本実施形態において、文書処理制御部１１４は、ページ作成手段、ページ送信制御手段、ファイル送信制御手段、及び自動修正手段に相当する。データ管理部１１５は、保管制御手段、及びファイル特定手段に相当する。

振分制御部１１１は、端末通信部１９との間でデータの授受を行い、端末通信部１９から入力したデータを渡すべき出力先を特定し、特定した出力先にデータを渡す。データを渡す出力先は、ここでは企業登録部１１２、認証部１１３、文書処理制御部１１４、及び辞書登録部１２０のうちの何れかである。振分制御部１１１がデータを渡すべき出力先に渡す結果、そのデータの処理に必要な機能が動作する。

企業登録部１１２は、本サービスを利用する事業者の情報を登録するための機能である。この情報が、企業登録情報であり、記憶部１８に確保された企業登録情報格納部１８１に格納される。企業登録情報の大部分は、事業者によって入力される情報である。しかし、その一部は、企業登録部１１２により、記憶部１８に確保された企業マスター格納部１８２に格納されている企業マスターを参照して自動的に生成される。

上記のように、本サービスの利用には利用登録が必要である。その利用登録を求める事業者は、本サービスの契約者、つまり顧客である事業者と、何れかの顧客に本サービスを提供するために利用登録が必要になった事業者と、に分けられる。利用登録が必要になった事業者は、顧客として契約しなくとも良い。しかし、企業登録情報の内容、つまり企業登録情報を構成する主な項目の組み合わせは、事業者の分類に係わらず同じである。以降、便宜的に、顧客である事業者は「契約事業者」、顧客でない事業者は「非契約事業者」と夫々表記する。

企業マスターは、情報が公開されている企業等毎に、その企業等についての情報がまとめられたファイルである。企業等についての情報には、例えば企業コード、法人名、住所、連絡先、及び業種の各情報が含まれる。その他に、作成日時、及び更新日時の各情報が追加されている。ここでは、これらをまとめて「企業マスター個別情報」と表記する。それにより、企業マスターは、企業マスター個別情報を集約させたものである。また、企業マスター個別情報では、それが企業マスターに格納されている企業等を指す意味で「企業」を用いる。

企業コードは、公開されている企業を一意に識別可能な識別情報であるとともに、公開されている情報である。法人名、住所、連絡先、及び業種も、全て公開されている情報である。作成日時は、企業マスター個別情報が企業マスターに追加された日時を表し、更新日時は、企業マスター個別情報が最後に更新された日時を表す。

一方、企業登録情報は、例えばお客様コード、利用状態、事業者名、部署名、担当者名、メールアドレス、住所、作成日時、及び更新日時等の情報を含む。
お客様コードは、利用登録した事業者を一意に識別可能な識別情報である。本サービスでは、企業マスターに企業マスター個別情報が格納されている企業の利用登録である場合、お客様コードとして、企業マスター個別情報中の企業コードを用いるようにしている。企業マスターに企業マスター個別情報が格納されていない企業の利用登録では、企業登録部１１２は、企業マスター個別情報、及び企業登録情報の何れにも用いられていないユニークな識別情報を自動的に生成してお客様コードとする。ここでは、お客様コードをログインのための認証用ＩＤと想定する。

利用状態は、本サービスの利用状態を表す情報である。具体的には、利用状態は、本サービスを利用する事業者が契約者か否か、及び本サービスを利用中か否か等を表す情報である。
事業者名、部署名、担当者名、メールアドレス、及び住所は、全て事業者が入力する情報である。事業者は、これらの情報入力を通して、送付の対象となる文書ファイルＤが発生した旨を通知するメールの送信先、印刷物を郵送等で届ける場合の届け先等を任意に指定することができる。

作成日時は、企業登録情報が企業登録情報格納部１８１に追加された日時を表す。更新日時は、企業登録情報が最後に更新された日時を表す。これらは全て、企業登録部１１２によって追加、或いは更新される。
契約事業者は主に、本サービスの利用を自ら決めた事業者である。契約を希望する事業者は、自らの意思でＡＰサーバ１に事業者端末を接続させ、利用登録を行うものと考えられる。

一方、非契約事業者は、その取引先等の事業者が本サービスの導入に伴い、本サービスを利用することなった事業者である。本サービスについての情報を事前に把握している可能性は低いと考えられる。また、入力を必須とする情報も、非契約事業者と契約事業者とでは異なる部分がある。このようなことから、本サービスでは、非契約事業者を想定した利用登録用の専用サイトを用意し、その専用サイトへのリンク情報を埋め込んだメールを非契約事業者宛に送付するようにしている。そのために、契約事業者には、本サービスの利用を望む非契約事業者のメールアドレスを指定可能にさせている。そのようにして、本サービスでは、非契約事業者が本サービスをより容易に利用できるようにさせている。

企業登録部１１２は、事業者を契約事業者、及び非契約事業者のうちの何れかに分類し、必要な情報を事業者に入力させるための処理を行い、企業登録情報を企業登録情報格納部１８１に格納する。専用サイトへのアクセスを非契約事業者に依頼するためのメールの送信は、文書処理制御部１１４、及び通知制御部１１９によって実現される。

認証部１１３は、本サービスを利用する事業者が利用登録を行った事業者か否かを確認する認証を行う。また、認証に必要な情報の管理も行う。そのために、ログイン用のＷｅｂページの送信も認証部１１３によって行われる。このページの送信は、例えば専用サイトへのアクセス時を含む利用登録以外で事業者端末がＡＰサーバ１に接続された場合に行われる。

ここでは認証用の情報として、認証用ＩＤ、及びパスワードを想定している。認証用ＩＤとしては、お客様コードを想定している。認証部１１３は、パスワードの変更に対応する処理も必要に応じて行う。認証用の情報は企業登録情報と別に管理しても良いが、ここでは企業登録情報に含まれているものと想定する。その想定では、企業登録情報は認証部１１３による更新が行われる。

文書処理制御部１１４は、本サービスを提供するための主な処理、或いは制御を行う。この文書処理制御部１１４により、上記専用サイトへのアクセスを求めるメールの送信に加え、事業者間での文書ファイルＤの交換、その交換のための各種設定情報の登録等も可能になる。

図５は、文書処理制御部によって実現される文書ファイルの交換の仕組みの例を説明する図である。
図５において、ＳＳは、ＡＰサーバ１、及びＤＢサーバ２によって実現される、文書ファイルＤを含む各種データの保管のための保管空間である。この保管空間ＳＳは、ＡＰサーバ１が備える記憶部１８、及びＤＢサーバ２が備える記憶部２００にそれぞれ確保された保管領域により仮想的に実現される空間である。この保管空間ＳＳには、図１に示すストレージＳＴに確保された個別保管領域ＳＡの全てが含まれる。

各個別保管領域ＳＡは、論理的に複数の領域に分割することが可能である。事業者は、個別保管領域ＳＡ内の論理的な構造を設定可能である。図５では、その領域として、各個別保管領域ＳＡに複数のフォルダーＳＢ、ＳＣが設定されていることを示している。フォルダーＳＢは、例えばルートフォルダーであり、フォルダーＳＣは、ルートフォルダーであるフォルダーＳＢ内に含まれるサブフォルダーである。事業者は、階層構造の設定も可能である。

請求書ＤＳ、及び契約書ＤＫはともに、交換の対象となる文書ファイルＤである。これらの文書ファイルＤは、取り込まれた後、指定された、或いは自動認識された送付先に対応付けられている個別保管領域ＳＡに保管される。請求書ＤＳ、契約書ＤＫは、文書ファイルＤとしての種類（属性）が異なる。そのため、Ｂ社ＣＢから取り込まれたＡ社ＣＡ宛ての請求書ＤＳは、Ａ社ＣＡ用の個別保管領域ＳＡ内に作成されたサブフォルダーＳＣの一つである「経理部」フォルダーＳＣに保管される。Ｃ社ＣＣから取り込まれたＡ社ＣＡ～Ｃ社ＣＣ宛ての契約書ＤＫは、それぞれ、各個別保管領域ＳＡ内に作成された「社長」フォルダーＳＣに保管される。自身が送付先に含まれる場合、自身用の個別保管領域ＳＡは、文書ファイルＤの保管領域として使用することができる。

Ａ社ＣＡ～Ｃ社ＣＣがそれぞれ階層構造で設定可能な各フォルダーは、文書ファイルＤの保管先となる。文書ファイルＤの実際の保管先は、フォルダーのうちの一つであり、文書ファイルＤを実際に保管するためには、フォルダーのうちの一つを保管先として選択しなければならない。その保管先の選択に、文書ファイルＤを送信させた事業者による指定、或いは文書ファイルＤに存在する文字列の自動認識結果が用いられる。それにより、各フォルダーには、そのフォルダーに保管すべき文書ファイルＤのみが保管される。

図６は、文書ファイル中で自動認識の対象となる文字列の例を説明する図である。
図６には、文書ファイルＤにより表される画像の例として、発注書ＤＨの例を示している。その発注書ＤＨでは、一点鎖線で囲った文字列領域ＭＲを３つ示している。各文字列領域ＭＲ内に存在する文字列、つまり文字列「発注書」「０００９」「１０００４７６」は全て、自動認識の対象となる文字列の例である。

文字列「発注書」は、文書の種類を表す文字列である。文字列「０００９」は、お客様コードを表す文字列である。文字列「１０００４７６」は、発注書ＤＨに割り当てられた発注番号である。この発注番号は、各発注書ＤＨで異なる。そのため、発注番号は、発注書ＤＨを一意に識別可能な識別情報となっている。
発注書ＤＨでは、これら文字列が抽出され、自動認識される。自動認識により特定されたお客様コードは、発注書ＤＨの文書ファイルＤを保管すべき個別保管領域ＳＡを指定する。文書の種類は、その個別保管領域ＳＡ内に作成されたフォルダーのうちで文書ファイルＤを保管すべきフォルダーを指定する。発注番号は、そのフォルダー内に作成されたフォルダーのうちで文書ファイルＤを保管すべきフォルダーを指定する。最後に指定されたフォルダーが文書ファイルＤの実際の保管先である。このようなことから、文書ファイルＤ中に存在する複数の文字列の自動認識を行うことにより、階層構造を有するように複数のフォルダーが作成されている個別保管領域ＳＡに対応することができる。つまり、選択肢として多数の保管先が存在していたとしても、そのうちから一つの保管先を自動的に選択することができる。自動認識する対象とする文字列、及びその数等は、特に限定されない。

文書ファイルＤ中から自動認識すべき文字列の抽出（特定）、及び抽出した文字列の自動認識は、自動分割部１１６によって行われる。図６に示すような文字列領域ＭＲは、文書の先頭ページに存在する。このことから、自動分割部１１６は、文字列の自動認識を通して、集約文書ファイル中の１文書分のデータを特定し、特定した１文書分のデータを集約文書ファイルから分割する。それにより、自動分割部１１６は、分割した１文書分のデータは、それぞれ１文書ファイルＤとして扱うのを可能とさせる。文書処理制御部１１４は、振分制御部１１１から渡された文書ファイルＤにおける文字列の自動認識の必要性を判定し、自動認識が必要と判定した文書ファイルＤを自動分割部１１６に渡す。文書ファイルＤを送信させた事業者が、保管先の決定に必要な全ての情報を指定していなかった場合、その文書ファイルＤは自動認識が必要とされる。

配置される文字列の種類、及びその文字列の配置等を含む文書の形式は、それを交換する何れかの事業者の意向等によって決められる。そのため、本サービスを利用する前に各事業者が採用していた文書の形式も様々なものがあると考えられる。このことから、例えば文書の種類毎に、その文書の形式を統一させるようにする場合、大部分の事業者には、文書の形式の変更を求めることになる。これは、文書の形式を変更する必要がある事業者にとっては、大きな負担となる。なぜなら、新しい文書の形式に対応しなければならないだけでなく、既に存在する文書ファイルＤも再利用できなくなるからである。

このようなことから、本サービスでは、事業者が本サービスをより利用しやすくなるように、発注書ＤＨ、請求書ＤＳ、及び納品書を含む各種文書の形式の統一は求めないようにしている。各種文書で形式の統一を求めないことから、各種文書には様々な形式のものが存在することになる。そのため、本サービスでは、文書ファイルＤ中から自動認識すべき文字列の抽出（特定）を可能とさせる辞書を事業者に登録可能にさせている。
辞書は、図６に示すような各文字列領域ＭＲの位置、各文字列領域ＭＲに存在する文字列の種類等を指定する。辞書登録部１２０は、辞書の登録のための機能である。その辞書登録部１２０により登録された辞書は、記憶部１８に確保された辞書格納部１８８に格納される。それにより、自動分割部１１６は、辞書格納部１８８に格納された辞書を参照し、文書ファイルＤ中からの文字列の抽出、及び抽出した文字列の自動認識を行う。

本サービスでは、納品書をベースに受領書を生成する。印刷物である受領書には、受領印を押印する押印箇所が設けられているのが普通である。このことから、電子データである納品書でも、受領印を押印する押印箇所が設けられているものと想定している。その押印箇所に受領印を押印できるように、納品書の辞書では、文字列領域ＭＲの他に、押印箇所を表す押印領域を指定させるようにしている。

図５の説明に戻る。
各個別保管領域ＳＡは、それが割り当てられた事業者にとって、文書ファイルＤを確認するうえでの表示環境ＨＫとなる。それにより、事業者は、個別保管領域ＳＡで設定された論理的な構造に沿って、保管されている文書ファイルＤの確認、閲覧、及び文書ファイルＤのダウンロードを行うことができる。これは、自動認識により文書ファイルＤの保管先が自動的に決定されたか否かには関係しない。

Ａ社ＣＡの個別保管領域ＳＡでは、「経理部」フォルダーＳＣ、及び「社長」フォルダーＳＣの両方にアクセス制限の設定が行われている。それにより、「経理部」フォルダーＳＣ、及び「社長」フォルダーＳＣの両方は、アクセス権限を有する従業員のみ、保管された文書ファイルＤを確認できるようになっている。本サービスでは、このようなアクセス制限も可能にさせている。

個別保管領域ＳＡは、契約の有無に係わらず、本サービスを利用する各事業者に割り当てられる。しかし、本サービスでは、全ての非契約事業者を対象にした保管領域を確保し、各非契約事業者の個別保管領域ＳＡは、その保管領域内に確保するようにしている。そのため、各非契約事業者の個別保管領域ＳＡは、図５におけるＡ社ＣＡの「経理部」フォルダーＳＣ、或いは「社長」フォルダーＳＣのように扱われる。
このようなことから、個別保管領域ＳＡ中に存在する保管先のうちから、実際に文書ファイルＤを保管させる保管先を選択することにより、部署を含む事業者間での適切な文書ファイルＤの交換が実現される。

図５に示すような文書ファイルＤの交換の実現のために、各種設定情報が参照される。各種設定情報の登録は、記憶部１８に確保された設定情報格納部１８６に格納することで行われる。

各種設定情報としては、利用依頼設定情報、保管設定情報、取込設定情報、配信管理情報、及び通知管理情報等が存在する。全ての事業者は、全ての設定情報を登録させることが可能である。そのため、全ての設定情報は、何れかの事業者に紐付け、つまり対応付けられている。その対応付けは、事業者毎に異なる格納領域を確保することで行っても良いが、お客様コード等の事業者を一意に識別可能な情報を追加することで行っても良い。

利用依頼設定情報は、契約事業者が本サービスの利用を依頼する非契約事業者を指定可能にする。そのために、利用依頼設定情報は、各契約事業者が必要に応じて設定することが可能になっている。利用依頼設定情報には、例えば設定する契約事業者のお客様コードの他に、本サービスの利用を望む非契約事業者の情報として、事業者名、部署名、及びメールアドレス等が含まれる。非契約事業者の情報は、複数、存在している場合がある。

専用サイトへのリンク情報が埋め込まれたメールは、情報が入力された非契約事業者宛てに送信される。そのために、文書処理制御部１１４は、登録する利用依頼設定情報を参照し、利用依頼設定情報中のメールアドレスを通知制御部１１９に渡し、専用サイトへのリンク情報を本文に埋め込んだメールを送信させる。それにより、非契約事業者は、受信したメールを通して、専用サイトにアクセスして利用登録を行うことにより、契約をすることなく、本サービスを利用可能になる。

図７は、利用依頼設定情報により利用登録を行った非契約事業者の情報を表示するＷｅｂページ（画面）の例を示す図である。
契約事業者には、自身が本サービスの利用を依頼した非契約事業者が実際に入力した情報を確認可能にさせている。図７は、その情報確認を要求した契約事業者に送信されるＷｅｂページの例を示している。
この要求が端末通信部１９によって受信された場合、受信された要求は端末通信部１９からＣＰＵ１１に出力される。ＣＰＵ１１に入力された要求は、振分制御部１１１を介して文書処理制御部１１４に渡される。

それにより、このＷｅｂページは、文書処理制御部１１４によって生成され、振分制御部１１１を介して端末通信部１９に出力されることにより、契約事業者で使用される事業者端末に送信される。このＷｅｂページの生成には、企業登録情報、及び利用依頼設定情報が用いられる。なお、このＷｅｂページの送信を要求するための操作等についてのより詳細な説明は省略する。

図７において、お客様コード、同意、及び受付日時の各項目の情報は、非契約事業者が入力した情報ではなく、企業登録部１１２、或いは文書処理制御部１１４により自動的に入力された情報である。受付日時は、非契約事業者が利用登録を行った日時である。例えば企業登録情報中の作成日時が受付日時として契約事業者に呈示される。同意は、非契約事業者が本サービスを利用するか否かを表す情報であり、図７中に表記の「はい」は、非契約事業者が本サービスを利用することを表している。この同意についての情報入力は、契約を望む事業者には求められない。利用依頼設定情報で利用が依頼された非契約事業者のうちで、利用登録を行っていない、或いは利用登録を行っていても、企業登録情報中の利用状態が本サービスを利用中となっていない非契約事業者は、同意の内容として「いいえ」が配置される。

図７のようなＷｅｂページを表示させることにより、利用依頼設定情報を登録させた契約事業者は、本サービスを利用可能な非契約事業者だけでなく、本サービスの利用を望まない非契約事業者も確認することができる。それにより、契約事業者は、利用登録をしていない非契約事業者を含む各非契約事業者に対し、文書ファイルＤの交換を適切に行うことができる。

各種設定情報の説明に戻る。
保管設定情報は、文書ファイルＤを個別保管領域ＳＡに保管するうえでの図５に示すような論理的な階層構造、例えばフォルダーの階層構造を指定する。この保管設定情報は、各事業者が夫々入力する情報である、この保管設定情報により、文書ファイルＤは、例えば部署別、期間別、或いは／及び文書ファイルＤの種類（属性）別等により自動的に振り分けられて個別保管領域ＳＡに保管される。

契約事業者は、フォルダー別に、アクセス制限を設定することも可能である。アクセス制限を設定、つまりアクセスを可能にする従業員を制限するフォルダーには、例えばアクセス用ＩＤ、及びパスワードを設定することが可能となっている。このようなアクセス制限の設定も、保管設定情報により行うことができる。

取込設定情報は、ＡＰサーバ１に文書ファイルＤの取り込みを自動的に行わせることを可能にする。そのために、取込設定情報では、取込保管領域３６、取り込みを行うタイミング、及び取り込んだ文書ファイルＤを送付可能にするタイミング等を指定可能になっている。

取込保管領域３６に保管する文書ファイルＤは、その内容の自動認識により送付先を特定するのを前提としている。そのため、取込設定情報では、文書ファイルＤの送付先等の指定は想定していない。

図５において、請求書ＤＳはこの自動認識が利用可能である。契約書ＤＫは、同じ契約書ＤＫを複数の異なる送付先に送付する可能性が考えられることもあり、自動認識を利用しない想定となっている。それにより、契約書ＤＫでは、個別保管領域ＳＡだけでなく、階層構造で作成されたフォルダーのうちから実際に文書ファイルＤを保管すべきフォルダーまで特定可能な情報を指定する必要がある。

文書ファイルＤの交換における要望は、全ての事業者で一致するとは限らない。このことから、本サービスでは、各事業者に配信管理情報を登録させ、事業者による要望の違いに対応可能にしている。そのために、配信管理情報では、対象となる事業者毎に、その事業者の要望を指定可能になっている。

配信管理情報には、例えばお客様コード、会社名、配信種別、配信有効、及びユーザー作成済みの各情報が含まれる。
お客様コード、及び会社名は、企業登録情報から自動入力される情報である。その起業登録情報からの自動入力を可能にさせるために、本サービスでは、企業登録情報が登録された事業者の検索機能を提供している。それにより、事業者には、検索機能によりヒットした事業者のうちから配信管理情報を追加する事業者、つまり本サービスを用いた文書ファイルＤの交換を新たに希望する事業者を選択可能にさせている。

ユーザー作成済みは、事業者が契約しているか否かを示す情報である。
配信種別、及び配信有効は、文書ファイルＤの交換における事業者の要望を表す。この２つの項目は、事業者が入力する対象となる項目である。
配信種別は、交換のための文書ファイルＤの配信方法を指定する情報である。その内容としては、例えば「Ｗｅｂ」及び「郵送」のうちから選択される。「Ｗｅｂ」は、ネットワークＮを介した文書ファイルＤの交換を表している。「郵送」は、郵送等により印刷物の形で文書ファイルＤの交換を表している。各事業者は、この情報の入力を通して、文書ファイルＤの配信方法、つまり交換方法を選択することができる。
配信有効は、文書ファイルＤの交換に本サービスを利用するか否かを示す情報である。利用登録を行った各事業者は、この情報により、本サービスを利用するか否かを選択することができる。

通知管理情報は、文書ファイルＤが新たに発生した旨を送付先に通知するためのものである。本サービスでは、その通知はメールを用いて行われる。それにより、通知管理情報では、メールの本文に挿入するメッセージの雛形、及びそのメールを送信するタイミング等を指定可能になっている。

通知に用いるメッセージは、文書ファイルＤの種類によって異ならせるのが望ましい。また、メールを送信すべきタイミングは、文書ファイルＤの取り込み方によって異ならせるのが望ましい。メールは、自動的に取り込む場合、文書ファイルＤを確認可能にするタイミングを考慮して送信させるのが望ましく、そうでない場合、文書ファイルＤの緊急度に応じて送信させるのが望ましいと云える。このようなことから、本サービスでは、文書ファイルＤの種類、及び取込方法別に、メッセージの雛形、及びメールを送信するタイミングを指定可能にしている。

このメールにより、各事業者は、ログインすることなく、新たに発生した自身宛の文書ファイルＤの存在を知ることができる。そのため、各事業者は、新たに発生した自身宛の文書ファイルＤをより迅速、且つより容易に認識することができる。企業登録情報にメールアドレスを含め、非契約事業者にメールアドレスを登録させることには、本サービスを利用する事業者の全てに対し、このようなメールを受信可能にするという意図もある。
本サービスでは、納品書の文書ファイルＤは、メールによる通知の対象外とさせている。これは、納品書は、商品Ｐの配送によって参照される文書だからである。つまり、各事業者にとっては、商品Ｐの納品により、納品書の文書ファイルＤの確認、及び閲覧を行えば良いからである。

文書処理制御部１１４は、上記のような各種設定情報の入力に対応するための処理を行う。事業者が登録を指示した何れの設定情報も、文書処理制御部１１４から設定管理部１１７に渡され、設定管理部１１７により、設定情報格納部１８６に格納される。設定情報格納部１８６に格納されている設定情報は、文書処理制御部１１４の指示により、設定管理部１１７により読み出され、文書処理制御部１１４に渡される。それにより、事業者は、設定情報格納部１８６への設定情報の追加だけでなく、設定情報格納部１８６に格納されている設定情報を変更（更新）させることもできる。更新可能な設定情報は、例えば通知管理情報、取込設定情報、保管設定情報、及び配信管理情報である。

文書処理制御部１１４は、取込設定情報に沿って、文書ファイルＤの自動的な取り込みを行う。また、事業者端末からの要求により、事業者端末からアップロードされる文書ファイルＤの取り込みを行う。文書処理制御部１１４は、そのような取り込み方法に応じて、処理、及び制御の内容を変更する。

保管条件としては、例えばダウンロードを可能にする期間、及びダウンロードが可能な回数等を指定することができる。それにより、送付元は、保管条件の指定を通して、文書ファイルＤの望ましくない送付が行われるのを回避させることが可能となる。

事業者は、事業者端末から文書ファイルＤをアップロードさせる場合、その文書ファイルＤの送付先（宛先）、及び保管条件等を指定可能な個別設定情報をともにアップロードさせることができる。そのため、文書処理制御部１１４は、事業者端末から文書ファイルＤがアップロードされたる文書ファイルＤを取り込む場合、文書処理制御部１１４は、個別設定情報の有無を確認し、個別設定情報があれば、その内容を更に確認する。それにより、文書処理制御部１１４は、個別設定情報が無いか、例え個別設定情報があっても、文書ファイルＤの保管先の決定に必要な情報が不足している場合、その文書ファイルＤを自動分割部１１６に渡し、文字列の自動認識を行わせる。

上記のように、受領書（修正文書ファイルＳＤ）の生成には、納品書に設けられた押印領域への受領印の押印が必要である。その押印領域を確認する必要から、納品書の文書ファイルＤは、その保管先の決定に十分な情報が個別設定情報に存在していたとしても、文書処理制御部１１４から自動分割部１１６に渡される。保管先の決定に十分な情報が個別設定情報に存在していた場合、納品書の文書ファイルＤであることは、個別設定情報から判定することができる。

実際の保管先の決定は、データ管理部１１５によって行われる。このことから、データ管理部１１５には、文書処理制御部１１４から個別設定情報が渡され、自動分割部１１６から文字列の自動認識結果が渡される。保管の対象となる文書ファイルＤは、文書処理制御部１１４、或いは自動分割部１１６から渡される。文書ファイルＤの送付先は、個別設定情報、或いは自動認識結果から特定される。このことから、データ管理部１１５は、送付先の保管設定情報を参照して、文書ファイルＤの保管先を決定する。

データ管理部１１５は、保管先を決定した後、文書ファイルＤをアクセス制御部１１８に渡し、決定した保管先への文書ファイルＤの保管をＤＢサーバ２に要求させる。それにより、アクセス制御部１１８は、ＤＢ通信部２０を介して、文書ファイルＤとともに、決定した保管先に文書ファイルＤを保管させるための要求をＤＢサーバ２に送信する。

ＤＢサーバ２は、文書ファイルＤの保管用のストレージである記憶部２００を備えている。その記憶部２００には、事業者別に、文書ファイルＤの格納場所となる企業別格納部２０１が確保されている。ＤＢサーバ２は、受信した要求から特定される企業別格納部２０１に、受信した文書ファイルＤを格納する。各企業別格納部２０１には、図５に示すように、階層構造で複数のフォルダーが作成されている。そのため、文書ファイルＤが保管されるのは、複数のフォルダーのうちの１フォルダーである。

アクセス制御部１１８は、データ管理部１１５の他に、文書処理制御部１１４の指示により、ＤＢ通信部２０を介したＤＢサーバ２へのアクセスを行う。その指示によりＤＢサーバ２から送信された文書ファイルＤは、その指示を行ったデータ管理部１１５、或いは文書処理制御部１１４に渡される。

データ管理部１１５は、文書ファイルＤをＤＢサーバ２に保管させるとともに、その文書ファイルＤの管理用のパッケージ情報を生成し、生成したパッケージ情報を記憶部１８に確保されたパッケージ情報格納部１８３に格納する。文書ファイルＤの保管時に生成するパッケージ情報は、実体情報、及び保管情報である。文書ファイルＤの送信時には、更に配布情報がパッケージ情報として生成され、パッケージ情報格納部１８３に格納される。以降、パッケージ情報は、それらの情報の総称として用いる。

図８は、文書ファイルの保管に係わる情報、及びその関係の例を説明する図である。
図８において、実体ファイルＪＦは、実際に保管されるファイルであり、文書ファイルＤは、実体ファイルＪＦの一例である。実体ファイルＪＦには、事業者が送信したメッセージを保存したファイルも含まれる。

パッケージ情報は、実際には実体ファイルＪＦを保管する前に生成される。実体情報ＪＩは、実体ファイルＪＦの直接的な管理のための情報である。この実体情報ＪＩには、例えば実体ファイルＩＤ、管理状態、保存場所、ファイル名、ファイルタイプ、ファイルサイズ、保存日時、及び更新日時等の情報が含まれる。

実体ファイルＩＤは、実体ファイルＪＦを一意に識別可能な識別情報である。管理状態は、実体ファイルＪＦが存在するか否か、その実体ファイルＪＦの送付が有効か否か等を表す情報である。保存場所は、実体ファイルＪＦが実際に保管されている保存場所を表す情報である。これらは全て、データ管理部１１５によって生成される。

個別設定情報ＫＳ、或いは保管設定情報ＨＳは、保存場所の特定のために参照される。参照されるのは、個別設定情報ＫＳは実体ファイルＪＦの送付元の事業者のものであり、保管設定情報ＨＳは、送付先の事業者のものである。自動認識により送付先を特定する場合、保管設定情報ＨＳが参照され、送付先の特定に自動認識が用いられない場合、個別設定情報ＫＳも併せて参照される。それにより、実体ファイルＪＦを保管すべき個別保管領域ＳＡ、その個別保管領域ＳＡ内の例えばフォルダーが決定される。

ファイル名、ファイルタイプ、及びファイルサイズは全て、実体ファイルＪＦから取得される情報である。保存日時、及び更新日時はともに、データ管理部１１５によって追加される情報である。

保管情報ＡＩは、実体ファイルＪＦの保管、及び交換を管理するための情報である。この保管情報ＡＩには、例えば保管情報ＩＤ、実体ファイルＩＤ、送付元企業コード、送付先企業コード、登録日時、登録ユーザーＩＤ、保管期間、保管期限日時、公開予定日時、公開期限日時、及び取得上限回数等の情報が含まれる。

保管情報ＩＤは、保管情報ＡＩを一意に識別可能な識別情報である。実体ファイルＩＤは紐付けられた、つまり対応付けられた実体情報ＪＩに格納されている実体ファイルＩＤである。送付元企業コードは、実体ファイルＪＦの送付元である事業者のお客様コードである。送付先企業コードは、実体ファイルＪＦをダウンロード可能にする事業者のお客様コードである。登録日時は、保管情報ＡＩを生成した日時である。登録ユーザーＩＤは、実体ファイルＪＦを実際に取り込んだ事業者のお客様コードである。通常、登録ユーザーＩＤは、送付元企業コードと一致する。保管期間は、保管情報ＡＩを保管すべき期間である。保管期限日時は、保管情報ＡＩの廃棄が可能となる日時である。公開予定日時は、実体ファイルＪＦのダウンロードを可能にする予定の日時である。公開期限日時は、実体ファイルＪＦのダウンロードを不可にする日時である。取得上限回数は、実体ファイルＪＦのダウンロードが可能な回数である。

送付元企業コード、及び登録ユーザーＩＤは、実体ファイルＪＦの取り込み時、自動的に特定される。送付先企業コードは、実体ファイルＪＦが事業者端末から取り込んだ場合、個別設定情報ＫＳから特定される情報である。保管期間、保管期限日時、公開予定日時、公開期限日時等、及び取得上限回数も、個別設定情報ＫＳにより指定可能である。

送付元企業コード、登録ユーザーＩＤ、及び送付先企業コードは、企業マスターＫＭ、或いは企業登録情報ＫＴを参照して特定される。図８では、企業登録情報ＫＴを１つのみ示しているが、実際に参照されるのは２つ以上の企業登録情報ＫＴの場合もある。

自動的に実体ファイルＪＦを取り込んだ場合、送付先企業コードは自動認識により特定可能な情報となる。保管期間、保管期限日時、公開予定日時、公開期限日時等、及び取得上限回数は、保管設定情報ＨＳにより指定可能な情報である。そのため、それらは全て、保管設定情報ＨＳを参照して決定される。

保管情報ＡＩには、上記のような情報が含まれる。それにより、紐付けられた実体情報ＪＩが特定可能であり、その実体情報ＪＩの参照により、紐付けられた実体ファイルＪＦも特定可能となっている。送付元の事業者のお客様モードが送付元企業コードとして含めることにより、送付元の事業者には、自身が送付の実体ファイルＪＦが実際に適切に取り込まれているか否かの確認を可能にさせている。その確認は、送付先の事業者が保管設定情報で指定の論理構造に沿って行うことも可能である。

配布情報ＤＩは、実体ファイルＪＦのダウンロードによって生成されるか、或いはそのダウンロードに備えて作成される情報であり、ダウンロードによる実体ファイルＪＦの配布の管理に用いられる。この配布情報ＤＩには、例えば配布情報ＩＤ、保管情報ＩＤ、受信状態、送付元企業コード、送付先企業コード、配布日時、取得回数、登録日時、及び更新日時等の情報が含まれる。

これらの情報において、配布情報ＩＤは、配布情報ＤＩを一意に識別可能な識別情報である。保管情報ＩＤは、この配布情報ＤＩに紐付けられた保管情報ＡＩに格納されている保管情報ＩＤである。配布情報ＤＩに対応付けられた保管情報ＡＩは、この保管情報ＩＤによって特定可能となっている。

受信状態は、送付先による実体ファイルＪＦの受信状態を表す情報であり、ダウンロードが行われたか否かは受信状態により確認することができる。配布日時は、実体ファイルＪＦが最後にダウンロードされた日時である。取得回数は、実体ファイルＪＦが実際にダウンロードされた回数である。登録日時は、配布情報ＤＩが登録された日時である。更新日時は、配布情報ＤＩが更新された日時である。配布情報ＤＩでは、実体ファイルＪＦのダウンロードにより配布日時が更新されることから、通常、更新日時は配布日時と一致する。

上記のように、本サービスでは、送付元が実体ファイルＪＦのダウンロード回数の上限を設定可能にしている。このようなダウンロードの制限は、配布情報ＤＩを用いて実現される。ダウンロード回数の上限自体は、取込設定情報、及び個別設定情報ＫＳの両方で指定可能である。

操作記録情報ＫＩは、各実体ファイルＪＦへのダウンロードを含む各種操作を確認可能にするために用意された情報である。この操作記録情報ＫＩには、例えば記録ＩＤ、及び作成日時の他に、実体ファイルＪＦに対して行われた操作の内容を表す操作内容情報が、実体ファイルＪＦに対して行われた操作毎に格納される。操作内容情報としては、例えば操作日時、操作種別、及び保存情報ＩＤ等の情報が含まれる。

操作日時は、実体ファイルＪＦへの管理上の操作が行われた日時である。保存情報ＩＤは、操作が行われた実体ファイルＪＦを一意に識別可能にする。操作種別は、行われた操作の種類を表す情報である。操作の種類には、実体ファイルＪＦのダウンロードの他に、実体ファイルＪＦの保管等も含まれる。

本サービスでは、実体ファイルＪＦの保管により、実体情報ＪＩ、保管情報ＡＩ、及び配布情報ＤＩをパッケージ情報として生成して保管し、操作記録情報ＫＩを更新する。配布情報ＤＩ、及び操作記録情報ＫＩは、保管した実体ファイルＪＦへの操作により、必要に応じて更新する。それにより、実体ファイルＪＦを送付する側の要望に沿った形でダウンロードできるようにしている。

パッケージ情報、及び操作記録情報ＫＩの生成、及び更新も、データ管理部１１５によって行われる。記憶部１８には、パッケージ情報の保管用のパッケージ情報格納部１８３の他に、操作記録情報ＫＩの保管用の操作記録情報格納部１８４が確保されている。それにより、データ管理部１１５は、記憶部１８にアクセスして、生成、若しくは更新したパッケージ情報、若しくは操作記録情報を保管する。

データ管理部１１５は、事業者別、及び属性別に、ダウンロード可能な文書ファイルＤを表すオブジェクトリストを生成し、記憶部１８のオブジェクトリスト格納部１８５に保管する。そのオブジェクトリストは、例えばダウンロード可能な文書ファイルＤ毎に、保管情報ＡＩ中の保管情報ＩＤ、実体ファイルＩＤ、送信者企業コード、受信者企業コード、公開期限日時、及び取得上限回数等の情報がまとめられたファイルである。ダウンロード可能な文書ファイルＤの保管、或いはダウンロードを不可能にした文書ファイルＤの発生により、データ管理部１１５は、対応するオブジェクトリストを更新する。ここでの属性には、文書の種類の他に、例えば閲覧制限、緊急度、文書ファイルＤの送付元のお客様コード、及び文字列の自動認識結果から特定された文書の種類以外の内容等のうちの１つ以上が含まれる。

文書の１種類である発注書ＤＨでは、属性に発注番号を含めるのが望ましい。これは、発注番号は発注書ＤＨを一意に識別可能な識別情報だからである。
納品書、及び受領書にも、発注番号とは異なる識別情報が割り当てられるのが普通である。しかし、納品書、及び受領書には、発注書ＤＨとの対応関係を特定できるように、対応関係にある発注書ＤＨに割り当てられた発注番号が文字列、或いは図形パターン等の形で存在するのが普通である。このことから、属性としては、発注番号を含む複数の識別情報を属性に含めるのが望ましい。ここでは、発注書ＤＨ、納品書、及び受領書の全て、属性には発注番号が含まれるものと想定する。

記憶部１８に確保された修正設定情報は、図１に示すような文書ファイルＤをベースに、その文書ファイルＤへの修正、及び修正後の文書ファイルＤの扱い等について指定するための設定情報である。各事業者は、必要に応じて、必要な数の修正設定情報を登録させることができる。文書処理制御部１１４は、修正設定情報の登録、削除、及び更新を可能にさせる。ここでは、混乱を避けるため、ベースとされる文書ファイルＤの文書として、以降、納品書のみ想定する。

登録すべき修正設定情報は、例えばそのための要求とともに、事業者端末からＡＰサーバ１に送信される。その場合、文書処理制御部１１４は、受信された修正設定情報を設定管理部１１７に渡し、その保管を指示する。この結果、設定管理部１１７は、渡された修正設定情報を修正設定情報格納部１８７に格納させる。格納される修正設定情報には、例えばその登録を要求した事業者のお客様コード、及び修正設定情報を一意に識別可能にする識別情報等が管理情報として付加される。この管理情報により、文書処理制御部１１４は、修正設定情報を登録させた事業者のみ、その修正設定情報の閲覧、削除、及び更新を可能とさせる。

本サービスでは、修正設定情報を登録させる事業者として、納品書の文書ファイルＤの送信元となる事業者を想定している。この想定には、事業者から納品書の文書ファイルＤが送付される各事業者は、その文書ファイルＤをベースに、ベースとなる文書ファイルＤ中の文字列の修正を行える事業者と位置付けていることも含まれる。
同じ事業者であっても、送付先によって納品書の形式等を異ならせる場合がある。つまり、納品書の種類が複数、存在する場合がある。また、納品書の文書ファイルＤの送付先となる事業者のうちの一つ以上の事業者に、文字列の修正を可能とさせないようにする場合も考えられる。このようなことから、修正設定情報は、納品書の種類別に登録可能にさせることが望ましい。

納品書の文書ファイルＤは、上記のように、押印領域を特定する必要から、自動分割部１１６による辞書を用いた自動認識の対象となる。そのため、納品書の文書ファイルＤの自動認識に実際に用いられた辞書も特定される。このことから、納品書の種類が複数、存在する場合、辞書と修正設定情報とを対応付けすることにより、納品書の形式等に応じて、適用する修正設定情報を変更させることができる。
一つ以上の事業者に、文字列の修正を選択的に不可能とさせるのは、例えば管理情報に、文字列の修正を可能とさせる、或いはその修正を不可能とさせる事業者のお客様コードを含めることにより、実現させることができる。

ここでは、混乱を避け、理解を容易とさせるために、各事業者が作成する納品書は１種類、納品書が送付される各事業者は全て、文字列の修正が可能と想定する。
修正設定情報は、対応する納品書の文書ファイルＤの送信時、参照される情報である。修正設定情報は、文書ファイルＤの送信形態、文書ファイルＤへの操作内容、文書ファイルＤで修正可能な範囲、及び修正後の文書ファイルＤの扱い等を指定する。それにより、修正設定情報は、図１に示すように、文書ファイルＤをベースにしての修正文書ファイルＳＤの生成を可能にさせる。修正設定情報の内容についての具体例は後述する。

文書処理制御部１１４は、必要な情報をデータ管理部１１５に渡し、パッケージ情報の生成、或いは更新を指示する。また、データ管理部１１５を通して、必要なパッケージ情報、保管設定情報ＨＳ、或いは修正設定情報を取得し、取得した情報を用いた制御を行う。それにより、文書処理制御部１１４は、実体ファイルＪＦの取り込み、取り込んだ実体ファイルＪＦの管理、ダウンロードを含む実体ファイルＪＦへの送付元の要望に沿った操作、等を行う。送付元の要望に沿った操作には、納品書の文書ファイルＤによって表される画像を配置させたＷｅｂページの作成・送信、そのＷｅｂページを送信させた事業者端末からアップロードされる修正情報を反映させた修正文書ファイルＳＤの保管も含まれる。納品書の文書ファイルＤによって表される画像は、受領書の画像としてＷｅｂページ上に配置される。

パッケージ情報は、実体ファイルＪＦと組み合わされ、実体ファイルＪＦを管理するうえで必須の情報となっている。そのため、パッケージ情報の格納用のパッケージ情報格納部１８３は、各個別保管領域ＳＡで共有させた保管領域となっている。つまり各個別保管領域ＳＡは、パッケージ情報格納部１８３と、記憶部２００に確保された各企業別格納部２０１とにより実現されるものとなっている。各個別保管領域ＳＡは、論理的に分割された１つ以上の領域ではなく、物理的に分割された１つ以上の領域、或いはストレージであっても良い。

データ管理部１１５は、個別設定情報ＫＳで指定されるか、或いは文字列の自動認識結果から特定される送付先の保管設定情報ＨＳを参照して、文書ファイルＤの保管先を決定する。それにより、データ管理部１１５は、決定した保管先への文書ファイルＤの保管を、アクセス制御部１１８によりＤＢサーバ２に行わせる。その一方、データ管理部１１５は、更に企業マスターＫＭ、及び企業登録情報ＫＴを参照し、実体情報ＪＩ、及び保管情報ＡＩを少なくとも生成し、操作記録情報ＫＩを更新する。

次に、図９～図１２を参照し、納品書の内容の修正方法について具体的に説明する。
図９は、納品書の文書ファイルによって表される画像が配置されたＷｅｂページの例を示す図である。
このＷｅｂページは、３つの表示エリアＨＲ１～ＨＲ３に大別することができる。
表示エリアＨＲ１は、処理した、或いは処理すべき納品書を表す情報がリスト表示されるエリアである。ユーザーは、リスト表示された納品書のうちから、望む納品書を選択することができる。その選択は、例えば望む納品書の情報が配置された行へのクリック操作により行うことができる。
なお、リスト表示される納品書の情報には、納品日、配送業者名、受注側企業名、発注側企業名、お客様コード（企業コード）、配送日、及び伝票日時等がある。図９中、リストの左端に配置されているのは、スライドタイプのオン／オフボタンである。このボタンは、処理済みか否かをユーザーが切り換えるために用いられる。

表示エリアＨＲ２には、文書ファイルＤから生成された受領書の画像が配置される。その画像は、内容的には納品書と同じである。そのため、ユーザーは実質的に、納品書を参照し、届いた商品の検収を行うことができる。
その画像中には、配送関係情報を表す複数の文字列、配送商品情報を表す複数の文字列、及び押印箇所（押印領域）ＪＲが存在する。配送商品情報を表す複数の文字列は、表形式で行別に配置されている。それにより、図９は、複数の配送商品情報が納品書に存在することを示している。

納品書には、発注番号、及び伝票番号が識別情報として存在する。発注番号は、対応する発注書ＤＨに割り当てられた識別情報であり、伝票番号は、納品書に対して受注側企業が割り当てた識別番号である。これら識別情報は、図９に示すように、受領書の画像中にも文字列として存在している。
配送商品情報を表す複数の文字列には、商品コード、商品名、数量、及び単位を表す文字列が含まれる。文書のタイトルとして、文字列「納品書兼受領証」が画像中に配置されている。各種指示用に３つのボタンＢ１～Ｂ３が画像外に配置されている。

文字列「納品書兼受領証」は、修正設定情報が指定する操作を行った結果、配置された文字列である。元は、例えば文字列「納品書」である。文書処理制御部１１４は、修正設定情報を参照することにより、文字列「納品書」を文字列「納品書兼受領証」に更新し、更新後の文字列「納品書兼受領証」を配置させたＷｅｂページを生成し送信する。図９に示す例では、文字列「納品書」が第１の文字列、文字列「納品書兼受領証」が第２の文字列にそれぞれ相当する。
修正設定情報は、画像中に存在する文字列のうちで修正可能な文字列を指定する。文字列「納品書」から文字列「納品書兼受領証」への自動的な修正も、修正設定情報の指定により行われる。修正設定情報には、これら修正に係わる各種情報が含まれる。「修正」ボタンＢ１は、文字列の修正が可能な状態にするためのボタンである。
文字列「納品書」から文字列「納品書兼受領証」へのタイトルの自動的な修正により、ユーザーにとっては、修正すべき文字列が減ることになる。また、タイトルにより、自身が修正を行っている文書の種類を適切に認識することができる。なお、自動修正の対象となる文字列は、タイトルに限定されない。また、文字列の数は２以上であっても良い。

図１０は、文字列の修正が可能な状態のＷｅｂページの例を示す図である。
ユーザーが「修正」ボタンＢ１をクリック操作することにより、修正可能な文字列は、図１０に示すように、表示形態が変更される。修正可能な文字列毎に、その文字列がデータとして配置される表示フィールドＤＦが他と区別可能な表示形態で強調表示される。そのようにして、本サービスでは、修正可能な文字列、及びそれが配置された表示フィールドＤＦを視覚的にユーザーに確認可能にさせ、修正の対象となる文字列の特定をより容易に行えるようにさせている。

図１０では、破線の矩形で修正可能な文字列が存在する表示フィールドＤＦを表している。この表示フィールドＤＦは、文字列が入力可能な入力フィールドであり、その入力フィールド内に存在する文字列が修正可能である。また、文字列が存在しない表示フィールドＤＦでは、文字列の入力が可能である。それにより、ユーザーは、表示フィールドＤＦを入力フィールドとして選択し、修正を望む文字列の修正、或いは文字列の追加を行う。入力フィールドとしての表示フィールドＤＦの選択は、クリック操作等により行うことができる。以降、混乱を避けるために、表示フィールドＤＦは「入力フィールドＤＦ」と表記する。

文字列の修正が可能な状態では、「修正」ボタンＢ１の代わりに「キャンセル」ボタンＢ６が配置される。この「キャンセル」ボタンＢ６は、文字列の修正を行えない状態に戻すのを指示するためのボタンである。「キャンセル」ボタンＢ６へのクリック操作により、それ以前に行われた文字列の修正、及び受領印の押印は無効とされ、Ｗｅｂページは、図９に示すような状態に戻る。
「登録」ボタンＢ２は、例えば画像上の内容のアップロードを指示するためのボタンである。画像上の内容、つまり各種文字列、及び押印箇所ＪＲに押印された受領印等は、修正情報として、事業者端末からＡＰサーバ１にアップロードされる。
「印」ボタンＢ３は、押印箇所ＪＲへの受領印の押印、或いは押印された受領印の削除を指示するためのボタンである。
この「印」ボタンＢ３へのクリック操作により、押印箇所ＪＲに受領印が押印（表示）される。押印された受領印は、「印」ボタンＢ３をクリック操作することにより、削除される。受領印が押印されていない場合、「登録」ボタンＢ２へのクリック操作は無効とされる。そのため、修正情報として、元の内容との差分を表す情報を採用したとしても、修正情報には受領印の画像が含まれる。それにより、修正文書ファイルＳＤとして保管される受領書は、受領印が押印されたものとなる。

受領印を表示させる場合、事業者端末は、例えば受領印の画像をＡＰサーバ１に対して要求し、その画像をＡＰサーバ１から取得する。そのため、受領印の押印を行う可能性のある事業者には、受領印として用いる電子印鑑を登録させるようにしている。電子印鑑の登録等についての詳細な説明は省略する。

表示エリアＨＲ３には、納品書の文書ファイルＤに対応する発注書ＤＨの画像の表示用である。表示エリアＨＲ３の上方に配置された「表示」ボタンＢ４は、発注書ＤＨの画像の表示を指示するためのボタンである。「消去」ボタンＢ５は、表示された画像の消去を指示するためのボタンである。
発注書ＤＨの文書ファイルＤは、本実施形態における第３の文書ファイルに相当する。契約書ＤＫの内容に沿って、納品書が作成されるような場合、第３の文書ファイルは、契約書ＤＫの文書ファイルＤであっても良い。このようなこともあり、第３の文書ファイルの選択肢は複数、存在する場合もある。

配送すべき商品Ｐは、発注側企業４から注文された商品である。本サービスを利用し、発注書ＤＨの文書ファイルＤが交換されていた場合、その文書ファイルＤは、受注側企業３の個別保管領域ＳＡに保管されている。納品書には、発注書ＤＨとの対応関係を特定可能とするために、発注書ＤＨを一意に識別可能な識別情報、例えば発注番号が文字列として含まれているのが普通である。このことは、納品書の文書ファイルＤ用に登録される辞書への条件に、発注番号を表す文字列が存在する文字列領域ＭＲの指定を含めることにより、納品書に対応する発注書ＤＨの文書ファイルが特定できることを意味する。
その発注書ＤＨ自体は、納品書の文書ファイルＤの送付先である発注側企業４で作成された文書である。そのため、発注書ＤＨの内容を発注側企業４に提示することで問題が発生するとは考え難い。このようなことから、本サービスでは、発注書ＤＨの画像を表示エリアＨＲ３に表示させるのを可能とさせている。

納品書の文書ファイルＤ中の発注番号は特定済みであり、その文書ファイルＤの送信元の事業者のお客様コードも特定済みである。このことから、事業者端末から発注書ＤＨの画像の表示が要求された場合、文書処理制御部１１４は、例えば送付元の事業者のお客様コード、発注番号、及び文書の種類の各情報をデータ管理部１１５に渡し、文書ファイルＤの抽出を指示する。この結果、データ管理部１１５は、例えばオブジェクトリストを参照し、文書処理制御部１１４が指定のお客様コード、発注番号、及び文書の種類を属性として有する文書ファイルＤを特定する。このようにして特定された文書ファイルＤの文書が、納品書に対応する発注書ＤＨである。なお、お客様コードを指定するのは、発注番号は各事業所がそれぞれ個別に割り当てることから、複数の事業者が同じ発注番号を用いる可能性があり得るからである。

その後、データ管理部１１５は、アクセス制御部１１８を介して、それらの情報で特定される発注書ＤＨの文書ファイルＤをＤＢサーバ２から取得し、取得した文書ファイルＤを文書処理制御部１１４に渡す。
それにより、文書処理制御部１１４は、送信すべき発注書ＤＨの画像を事業者端末に送信することができる。一方の事業者端末は、そのようにして送信された画像を表示エリアＨＲ３に表示させる。

なお、発注書ＤＨの文書ファイルＤの特定は、オブジェクトリストを参照しなくとも行うことができる。
例えば個別保管領域ＳＡ内に作成されているフォルダーのうちで、対象となる文書ファイルＤが保管されているフォルダーは、文書の種類、及び発注番号から特定することができる。特定したフォルダーからの対象となる文書ファイルＤの抽出は、例えば文字列の自動認識を利用し、指定されたお客様コード、及び発注番号がともに文字列として存在する文書ファイルＤを特定することで行うことができる。
このようなこともあり、発注書ＤＨの文書ファイルＤのような対象となる文書ファイルＤを特定する方法は特に限定されない。つまり様々な変形が可能である。

表示エリアＨＲ３には、上記のようにして特定し抽出される文書ファイルＤによって表現される発注書ＤＨの画像が配置される。内容的には、発注書ＤＨの内容は納品書の内容と同じか、或いは納品書の内容は発注書ＤＨの内容の一部である。これは、発注書ＤＨで指定された商品を複数回に分けて配送するようなケースもあり得るからである。
しかし、商品Ｐの配送は、発注書ＤＨによる発注によって行われるものである。そのため、納品書に対応する発注書ＤＨの画像を表示エリアＨＲ３に表示させた場合、ユーザーは、突き合わせて、納品書の内容が適切か否かをより容易に確認することができる。それにより、文字列のうちで発注書ＤＨとは不適切な内容の文字列の特定も容易となる。このことから、ユーザーは、そのような確認を通して、数を含め、納品されるべき商品が実際に納品されたか否かの確認も容易に行うことができる。従って、ユーザーにとってのより高い利便性が実現される。

図１１は、入力フィールドの選択後の表示例を示す図である。
ユーザーが何れかの入力フィールドＤＦを選択した場合、図１１に示すように、その入力フィールドＤＦに存在する文字列が配置されたポップアップＰＵが表示される。そのポップアップＰＵ上には、ユーザーが選択した入力フィールドＤＦに存在する文字列の他に、修正後の文字列を入力するための入力フィールドＮＦ、「ＯＫ」ボタンＢ１１、及び「キャンセル」ボタンＢ１２が配置されている。

このことから、ユーザーは、入力フィールドＮＦ上に修正後の文字列を入力させた後、「ＯＫ」ボタンＢ１１へのクリック操作により、選択した入力フィールドＤＦ内の文字列を修正することができる。「キャンセル」ボタンＢ１２は、文字列の修正のキャンセルを指示するためのボタンである。そのため、ユーザーが「キャンセル」ボタンＢ１２をクリック操作した場合、ユーザーが選択した入力フィールドＤＦ内の文字列は修正されず、元の文字列のままとなる。

図１２は、１文字列の修正後のＷｅｂページの例を示す図である。
図１２では、文字列が修正された入力フィールドＤＦを一点鎖線の矩形で表している。これは、文字列が修正されていない入力フィールドＤＦとは異なる表示形態で更に強調表示させているからである。本サービスでは、文字列が修正された入力フィールドＤＦの表示形態を更に異ならせて強調表示させることにより、修正した文字列を視覚的に特定可能にして、その修正内容の確認を容易に行えるようにさせている。その再確認を容易とすることにより、修正ミスの発生はより抑えられると期待できる。

文書処理制御部１１４は、例えば図９～図１２に示すような各Ｗｅｂページの表示を実現させる。つまり事業所端末から送信される要求を処理し、発注書ＤＨの画像の送信、入力フィールドＤＦの表示形態の変更、並びにポップアップＰＵの作成、及び送信等を行う。この結果、ユーザーは、事実上の発注書ＤＨと納品書の突き合わせが可能になるとともに、検収により不適切であることが確認された受領書中の文字列を修正することができる。

Ｗｅｂページを受信した事業者端末は、例えばキーボードである入力装置への操作により、画像上の文字列の修正を可能にさせ、その修正結果を修正情報としてＡＰサーバ１に送信する。このことから、事業者端末上には、本実施形態の修正手段、及び修正情報送信手段が実現されている。これらの手段は何れも、事業者端末に搭載されたＣＰＵが、ＯＳ上で動作するブラウザを実行することで実現される。

なお、図９～図１２に示すような各Ｗｅｂページの表示は１例であり、表示させるＷｅｂページ、及びＷｅｂページの遷移のさせ方等は特に限定されない。例えば文字列の修正では、ポップアップＰＵを表示させることなく、文字列の修正を行えるようにしても良い。このことから、文字列の修正のための処理は、事業者端末に行わせるようにしても良い。しかし、受領印の押印が行われたか否かを確認できるように、言い換えれば修正文書ファイルＳＤの生成を行っても良いか否かを確認できるように、事業者端末は、修正情報、或いはそれに類似する情報をＡＰサーバ１に送信させるようにする必要がある。
本実施形態では、納品書の文書ファイルＤから受領書の修正文書ファイルＳＤを生成するようになっているが、文書ファイルＤの文書は納品書に限定されないだけでなく、修正文書ファイルＳＤの文書も受領書に限定されない。

図１３は、別の形式の納品書の画像例を示す図である。図１４は、別の形式の納品書をベースに生成される他の文書の画像例を示す図である。
図１３に画像例を示す納品書では、商品別に、数量、単価、金額、及び明細番号を含む配送商品情報が表されている。
数量は、納品する商品の数である。単価は、１商品の代金、金額は数量分の商品の代金、明細番号は商品に割り当てた番号である。
商品毎に金額を示すことで、納品書には、納品する商品全体の代金が合計として表されている。

合計は、事業者（発注側企業４）に対して支払いを求める請求額に相当する。このことから、このような納品書の形式は、請求書ＤＳでも採用することができる。これは、その納品書をベースにした請求書ＤＳが生成可能であることを意味する。それにより、図１４に示すように、納品書をベースにした請求書ＤＳを生成させるようにしても良い。その請求書ＤＳでは、タイトルを表す文字列は、文字列「納品書」から文字列「納品書兼請求書」に修正され、請求書ＤＳであることをタイトルから確認できるようになっている。
このようなこともあり、関連性が存在し、且つ文字列の大部分が共通した２つの文書としては、納品書、受領書の組み合わせに限定されない。例えば２つの文書の組み合わせは、納品書、受領書のうちの少なくとも一方が別の種類の文書である組み合わせであっても良い。

受領書が修正文書ファイルＳＤとして送信される受注側企業でも、発注側企業での発注書ＤＨの文書ファイルＤの特定と同様に、発注番号から、受領書に対応する発注書ＤＨを特定が可能である。このことから、本サービスでは、受注側企業からの要求により、受領書、及び発注書ＤＨの２つの画像を配置させたＷｅｂページの送信を行うようにしている。それにより、受注側企業での発注書、及び受領書を突き合わせてのその受領書の内容の確認をより容易に行うのを可能にさせている。そのＷｅｂページの送信を受注側企業からの要求により行うようにしているのは、納品書と比較し、受領書の内容を直ちに閲覧できるようにする要望は低いと考えられるからである。

本実施形態では、事業者別に、個別保管領域ＳＡを用意することにより、個別保管領域ＳＡを、文書ファイルＤ、及び集約文書ファイルＤを含む文書ファイルＤの保管先を個別保管領域ＳＡ中から選択するようにしている。個別保管領域ＳＡでは、保管設定情報ＨＳに沿って、文書ファイルＤの保管場所を必要に応じて作成できるようにさせている。しかし、保管先は、このような個別保管領域ＳＡでなくとも良い。保管先は、例えば事業者が予め用意したストレージ中の複数の保管場所のうちから選択させる形で決定させるようにしても良い。このこともあり、保管先は特に限定されない。

本実施形態では、事業者端末からの要求により、発注書ＤＨの文書ファイルＤを特定し、その画像を送信させるようにしている。しかし、画像の送信は、事業者端末からの要求ではなく、自動的に行うようにしても良い。例えば受領書の画像、及び発注書ＤＨの画像をともに配置させたＷｅｂページを作成して送信するようにしても良い。受領書の画像のみを配置させたＷｅｂページを送信させた後、発注書ＤＨの画像の送信が可能になり次第、発注書ＤＨの画像を送信させるようにしても良い。このようなことから、発注書ＤＨの画像を送信するタイミング、及び発注書ＤＨの文書ファイルＤを特定するタイミングはともに、特に限定されるものではない。

受領書の内容を発注側企業（着荷主）側に修正できるようにした場合、発注側企業が不適切な内容に修正する場合が考えられる。このことから、発注側企業が受領書を登録する前に、発注側企業が登録させようとする受領書の内容を受注側企業（発荷主）側、或いは関係者が確認できるようにさせても良い。例えば発注側企業に対し、受注側企業における商品の納品に係わる担当者の連絡先（例えば電話番号）を表示するか、或いは表示可能にして、担当者への連絡をより容易に行えるようにしても良い。或いは、商品Ｐを配送した配送業者に、発注側企業による検収結果を確認させ、配送業者の受領書への押印を行わせるようにしても良い。その押印を可能にするために、Ｗｅｂページを配送業者に受信可能にさせ、そのＷｅｂページを配送業者が受信させた端末上で、発注側企業による文字列の修正、及び受領印の押印を行えるようにさせても良い。
何れを採用するとしても、受領書の内容が不適切なものになる確率は低減するものと期待できる。

１ ＡＰサーバ、２ ＤＢサーバ、３、３－１～Ｌ 受注側企業、４－１～Ｋ 発注側企業、１１ ＣＰＵ、１８、２００ 記憶部、１１１ 振分制御部、１１２ 企業登録部、１１３ 認証部、１１４ 文書処理制御部、１１５ データ管理部、１１６ 自動分割部、１１７ 設定管理部、１１８ アクセス制御部、１１９ 通知制御部、１２０ 辞書登録部、１８１ 企業登録情報格納部、１８２ 企業マスター格納部、１８３ パッケージ情報格納部、１８４ 操作記録情報格納部、１８５ オブジェクトリスト格納部、１８６ 設定情報格納部、１８７ 修正設定情報格納部、１８８ 辞書格納部、２０１ 企業別格納部、ＣＡ Ａ社、ＣＢ Ｂ社、ＣＣ Ｃ社、Ｄ 文書ファイル、ＳＡ 個別保管領域、ＳＤ 修正文書ファイル、ＳＴ ストレージ、ＷＡ サービス提供会社

Claims (7)

1. 第１の事業者が使用する第１の端末、前記第１の事業者と電子化された文書ファイルの交換を行う第２の事業者が使用する第２の端末、並びに前記第１の端末、及び前記第２の端末と通信可能であり、前記通信を用いて、前記文書ファイルの交換を実現させる情報処理装置を備え、
   前記情報処理装置は、
   前記第１の事業者から受信された第１の文書ファイルの画像を、前記画像上に存在する文字列を修正可能な状態で配置させたＷｅｂページを作成するページ作成手段と、
   前記ページ作成手段により作成された前記Ｗｅｂページを、前記第２の端末に送信させることが可能なページ送信制御手段と、
   前記ページ送信制御手段により前記Ｗｅｂページが送信された前記第２の端末から、前記画像上の前記文字列に対して修正された結果を表す修正情報を受信した場合に、前記修正情報を反映させた前記第１の文書ファイルを第２の文書ファイルとして保管させる保管制御手段と、
   前記第１の端末に、前記保管制御手段により保管された前記第２の文書ファイルを送信させることが可能なファイル送信制御手段と、を備え、
   前記第１の端末は、
   前記第１の文書ファイルの送信、及び前記第２の文書ファイルの受信が可能であり、
   前記Ｗｅｂページを受信した前記第２の端末は、
   入力装置への操作により、前記情報処理装置から受信した前記Ｗｅｂページの前記画像上に配置されている前記文字列が修正可能な修正手段と、
   前記修正手段により前記画像上の前記文字列に対して修正された結果を表す前記修正情報を送信可能な修正情報送信手段と、を備える、
   情報処理システム。
2. 前記第２の端末は、前記画像上で修正が可能な前記文字列を他の文字列と異なる形態で表示させる、
   請求項１に記載の情報処理システム。
3. 前記第２の端末は、前記画像上で修正された修正文字列を更に別の形態で表示させる、
   請求項２に記載の情報処理システム。
4. 前記情報処理装置は、前記第１の文書ファイル中の予め定められた第１の文字列を異なる第２の文字列に自動的に修正可能な自動修正手段、を更に備え、
   前記ページ作成手段は、前記自動修正手段により修正された前記第２の文字列を前記画像の一部として配置させる、
   請求項１～３の何れか１項に記載の情報処理システム。
5. 前記保管制御手段は、前記第１の文書ファイル、及び前記第２の文書ファイル以外に、前記第１の事業者と前記第２の事業者との間で交換される他の文書ファイルを保管させることが可能であり、
   前記情報処理装置は、前記第１の文書ファイルの受信前に、前記第１の事業者と前記第２の事業者との間で交換された前記他の文書ファイルのうちで、前記第１の文書ファイルに対応付けられる第３の文書ファイルを特定可能なファイル特定手段、を更に備え、
   前記ページ送信制御手段は、前記ファイル特定手段により特定された前記第３の文書ファイルの画像を前記第２の端末に送信させることが可能であり、
   前記第２の端末は、前記第３の文書ファイルの画像を受信した場合、前記画像を前記Ｗｅｂページ上に表示させる、
   請求項１～４の何れか１項に記載の情報処理システム。
6. 前記保管制御手段は、前記第１の事業者と前記第２の事業者との間で交換される前記文書ファイル中に存在する文字列の自動認識結果を用いて、前記第１の文書ファイル、及び前記第３の文書ファイルを含む前記文書ファイルの保管先が決定可能であり、
   前記ファイル特定手段は、前記第１の文書ファイルの種類から、前記第３の文書ファイルが保管された前記保管先を特定し、特定した前記保管先から、前記自動認識結果を用いた前記第３の文書ファイルの抽出を行う、
   請求項５に記載の情報処理システム。
7. 第１の事業者から受信された第１の文書ファイルの画像を、前記画像上に存在する文字列を修正可能な状態で配置させたＷｅｂページを作成するページ作成手段と、
   前記ページ作成手段により作成された前記Ｗｅｂページを、第２の事業者で使用される第２の端末に送信させることが可能なページ送信制御手段と、
   前記ページ送信制御手段により前記Ｗｅｂページが送信された前記第２の端末から、前記画像上の前記文字列に対して修正された結果を表す修正情報を受信した場合に、前記修正情報を反映させた前記第１の文書ファイルを第２の文書ファイルとして保管させる保管制御手段と、
   前記第１の事業者で使用される第１の端末に、前記保管制御手段により保管された前記第２の文書ファイルを送信させることが可能なファイル送信制御手段と、
   を備える情報処理装置。

Images