IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ウイングアーク1st株式会社の特許一覧

<>
  • 特開-情報処理システム、及び情報処理装置 図1
  • 特開-情報処理システム、及び情報処理装置 図2
  • 特開-情報処理システム、及び情報処理装置 図3
  • 特開-情報処理システム、及び情報処理装置 図4
  • 特開-情報処理システム、及び情報処理装置 図5
  • 特開-情報処理システム、及び情報処理装置 図6
  • 特開-情報処理システム、及び情報処理装置 図7
  • 特開-情報処理システム、及び情報処理装置 図8
  • 特開-情報処理システム、及び情報処理装置 図9
  • 特開-情報処理システム、及び情報処理装置 図10
  • 特開-情報処理システム、及び情報処理装置 図11
  • 特開-情報処理システム、及び情報処理装置 図12
  • 特開-情報処理システム、及び情報処理装置 図13
  • 特開-情報処理システム、及び情報処理装置 図14
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023050643
(43)【公開日】2023-04-11
(54)【発明の名称】情報処理システム、及び情報処理装置
(51)【国際特許分類】
   G06Q 50/10 20120101AFI20230404BHJP
   H04L 67/02 20220101ALI20230404BHJP
【FI】
G06Q50/10
H04L67/02
【審査請求】有
【請求項の数】7
【出願形態】OL
(21)【出願番号】P 2021160847
(22)【出願日】2021-09-30
【新規性喪失の例外の表示】特許法第30条第2項適用申請有り (1)令和3年1月18日、令和3年4月15日、F-LINE株式会社の伝票電子化検討会議、及び実証実験にて、開発するシステムの仕様、及び開発したシステムを公開した。 (2)令和3年7月8日、デジタルロジスティクス推進協議会の実証実験にて、開発したシステムを公開した。
(71)【出願人】
【識別番号】504103984
【氏名又は名称】ウイングアーク1st株式会社
(74)【代理人】
【識別番号】100190621
【弁理士】
【氏名又は名称】崎間 伸洋
(74)【代理人】
【識別番号】100212510
【弁理士】
【氏名又は名称】笠原 翔
(72)【発明者】
【氏名】名護屋 豊
(72)【発明者】
【氏名】田中 陽子
(72)【発明者】
【氏名】松本 健一
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049CC11
(57)【要約】
【課題】通信により交換される、他の文書との関連性が存在し、且つ文字列の大部分が共通した文書に存在する文字列の修正が可能な情報処理システム、及び情報処理装置を提供すること。
【解決手段】サービス提供会社WAは、利用登録した事業者を対象に、事業者間の文書ファイルDの交換を中継するサービスを提供する。交換される文書ファイルDは、ストレージST上に送付先別に確保された個別保管領域SAに保管される。B社CBからの納品書の文書ファイルDは、A社CAの個別保管領域SAに保管し、A社CAへの送信は、その画像を配置させたWebページの形で行う。画像上の文字列の少なくとも一部は修正可能にさせる。それにより、A社CAでの文字列の修正を文書ファイルDに反映させたものが修正文書ファイルSDとして、B社CBの個別保管領域SAに保管される。
【選択図】図1
【特許請求の範囲】
【請求項1】
第1の事業者が使用する第1の端末、前記第1の事業者と電子化された文書ファイルの交換を行う第2の事業者が使用する第2の端末、並びに前記第1の端末、及び前記第2の端末と通信可能であり、前記通信を用いて、前記文書ファイルの交換を実現させる情報処理装置を備え、
前記情報処理装置は、
前記第1の事業者から受信された第1の文書ファイルの画像を、前記画像上に存在する文字列を修正可能な状態で配置させたWebページを作成するページ作成手段と、
前記ページ作成手段により作成された前記Webページを、前記第2の端末に送信させることが可能なページ送信制御手段と、
前記ページ送信制御手段により前記Webページが送信された前記第2の端末から、前記画像上の前記文字列に対して修正された結果を表す修正情報を受信した場合に、前記修正情報を反映させた前記第1の文書ファイルを第2の文書ファイルとして保管させる保管制御手段と、
前記第1の端末に、前記保管制御手段により保管された前記第2の文書ファイルを送信させることが可能なファイル送信制御手段と、を備え、
前記第1の端末は、
前記第1の文書ファイルの送信、及び前記第2の文書ファイルの受信が可能であり、
前記Webページを受信した前記第2の端末は、
入力装置への操作により、前記情報処理装置から受信した前記Webページの前記画像上に配置されている前記文字列が修正可能な修正手段と、
前記修正手段により前記画像上の前記文字列に対して修正された結果を表す前記修正情報を送信可能な修正情報送信手段と、を備える、
情報処理システム。
【請求項2】
前記第2の端末は、前記画像上で修正が可能な前記文字列を他の文字列と異なる形態で表示させる、
請求項1に記載の情報処理システム。
【請求項3】
前記第2の端末は、前記画像上で修正された修正文字列を更に別の形態で表示させる、
請求項2に記載の情報処理システム。
【請求項4】
前記情報処理装置は、前記第1の文書ファイル中の予め定められた第1の文字列を異なる第2の文字列に自動的に修正可能な自動修正手段、を更に備え、
前記ページ作成手段は、前記自動修正手段により修正された前記第2の文字列を前記画像の一部として配置させる、
請求項1~3の何れか1項に記載の情報処理システム。
【請求項5】
前記保管制御手段は、前記第1の文書ファイル、及び前記第2の文書ファイル以外に、前記第1の事業者と前記第2の事業者との間で交換される他の文書ファイルを保管させることが可能であり、
前記情報処理装置は、前記第1の文書ファイルの受信前に、前記第1の事業者と前記第2の事業者との間で交換された前記他の文書ファイルのうちで、前記第1の文書ファイルに対応付けられる第3の文書ファイルを特定可能なファイル特定手段、を更に備え、
前記ページ送信制御手段は、前記ファイル特定手段により特定された前記第3の文書ファイルの画像を前記第2の端末に送信させることが可能であり、
前記第2の端末は、前記第3の文書ファイルの画像を受信した場合、前記画像を前記Webページ上に表示させる、
請求項1~4の何れか1項に記載の情報処理システム。
【請求項6】
前記保管制御手段は、前記第1の事業者と前記第2の事業者との間で交換される前記文書ファイル中に存在する文字列の自動認識結果を用いて、前記第1の文書ファイル、及び前記第3の文書ファイルを含む前記文書ファイルの保管先が決定可能であり、
前記ファイル特定手段は、前記第1の文書ファイルの種類から、前記第3の文書ファイルが保管された前記保管先を特定し、特定した前記保管先から、前記自動認識結果を用いた前記第3の文書ファイルの抽出を行う、
請求項5に記載の情報処理システム。
【請求項7】
第1の事業者から受信された第1の文書ファイルの画像を、前記画像上に存在する文字列を修正可能な状態で配置させたWebページを作成するページ作成手段と、
前記ページ作成手段により作成された前記Webページを、第2の事業者で使用される第2の端末に送信させることが可能なページ送信制御手段と、
前記ページ送信制御手段により前記Webページが送信された前記第2の端末から、前記画像上の前記文字列に対して修正された結果を表す修正情報を受信した場合に、前記修正情報を反映させた前記第1の文書ファイルを第2の文書ファイルとして保管させる保管制御手段と、
前記第1の事業者で使用される第1の端末に、前記保管制御手段により保管された前記第2の文書ファイルを送信させることが可能なファイル送信制御手段と、
を備える情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理システム、及び情報処理装置に関する。
【背景技術】
【0002】
従来、商品の配送では、商品の配送者と、商品の配送先との間で納品書、及び受領書の受け渡しが行われている。納品書は、例えば商品の配送元、及び配送先の各住所、及び各名称等とともに、配送される商品、及びその数等が記載された文書である。受領書は、配送された商品、及びその個数等が適切であることを配送先が確認したことを示す文書である。以降、便宜的に、商品の配送元、及び配送先の各住所、及び各名称等の情報は「配送関係情報」、商品、及びその数等の配送される商品を表す情報は「配送商品情報」とそれぞれ総称する。多くの場合、受領書としては、納品書と内容的には同じもの、つまり同じ配送関係情報、及び同じ配送商品情報が記入されたものが用いられる。
【0003】
これまで、納品書、及び受領書は、印刷物の形で扱われている。現在では、それらの文書を電子化したファイルとして扱い、通信を用いた送受信により交換することも行われている(例えば、特許文献1参照)。それらを通信により交換する場合、それらの受け渡しにおける位置的な制約が排除される。例えば納品書では、配送者が納品書を受け取るための移動を不要にできる。一方の受領書では、配送先から受け取った後、その受領書を届けるべき場所への移動を不要にできる。このようなことから、納品書、及び受領書の電子化しての交換により、利便性も向上する。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開平09-311888号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
納品書に入力された配送商品情報の内容に誤り等がある場合がある。配送された商品の種類、或いはその数に誤りがある場合もある。配送された商品の何れかの破損等により、納品できない商品が発生する場合もある。何れの場合も、納品書の内容の一部が不適切なものとなる。そのため、内容的には同じ受領書では、その内容を修正可能なようにすることも重要と考えられる。
配送関係情報、及び配送商品情報ともに、1文字以上の文字列で表される情報である。このことから、内容の一部の修正は、修正すべき文字列の修正となる。このような文字列を修正すべき状況は、事業者間で交換される他の文書との関連性が存在し、且つ文字列の大部分が共通した文書でも生じるものと考えられる。なお、このような関係にある2つの文書は、納品書と受領書と同様に、送付先が異なるのが普通である。
【0006】
そこで、本発明は、通信により交換される、他の文書との関連性が存在し、且つ文字列の大部分が共通した文書に存在する文字列の修正が可能な情報処理システム、及びその修正を可能にさせる情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【0007】
本開示の第1の態様の情報処理システムは、第1の事業者が使用する第1の端末、前記第1の事業者と電子化された文書ファイルの交換を行う第2の事業者が使用する第2の端末、並びに前記第1の端末、及び前記第2の端末と通信可能であり、前記通信を用いて、前記文書ファイルの交換を実現させる情報処理装置を備え、前記情報処理装置は、前記第1の事業者から受信された第1の文書ファイルの画像を、前記画像上に存在する文字列を修正可能な状態で配置させたWebページを作成するページ作成手段と、前記ページ作成手段により作成された前記Webページを、前記第2の端末に送信させることが可能なページ送信制御手段と、前記ページ送信制御手段により前記Webページが送信された前記第2の端末から、前記画像上の前記文字列に対して修正された結果を表す修正情報を受信した場合に、前記修正情報を反映させた前記第1の文書ファイルを第2の文書ファイルとして保管させる保管制御手段と、前記第1の端末に、前記保管制御手段により保管された前記第2の文書ファイルを送信させることが可能なファイル送信制御手段と、を備え、前記第1の端末は、前記第1の文書ファイルの送信、及び前記第2の文書ファイルの受信が可能であり、前記Webページを受信した前記第2の端末は、入力装置への操作により、前記情報処理装置から受信した前記Webページの前記画像上に配置されている前記文字列が修正可能な修正手段と、前記修正手段により前記画像上の前記文字列に対して修正された結果を表す前記修正情報を送信可能な修正情報送信手段と、を備える。
【0008】
本開示の第1の態様の情報処理装置は、第1の事業者から受信された第1の文書ファイルの画像を、前記画像上に存在する文字列を修正可能な状態で配置させたWebページを作成するページ作成手段と、前記ページ作成手段により作成された前記Webページを、第2の事業者で使用される第2の端末に送信させることが可能なページ送信制御手段と、前記ページ送信制御手段により前記Webページが送信された前記第2の端末から、前記画像上の前記文字列に対して修正された結果を表す修正情報を受信した場合に、前記修正情報を反映させた前記第1の文書ファイルを第2の文書ファイルとして保管させる保管制御手段と、前記第1の事業者で使用される第1の端末に、前記保管制御手段により保管された前記第2の文書ファイルを送信させることが可能なファイル送信制御手段と、を備える。
【発明の効果】
【0009】
本発明は、通信により交換される、他の文書との関連性が存在し、且つ文字列の大部分が共通した文書に存在する文字列の修正を行うことができる。
【図面の簡単な説明】
【0010】
図1】本発明の情報処理装置の一実施形態に係るAPサーバによりサービス提供会社が提供するサービスの例の概要を説明する図である。
図2】本発明の情報処理装置の一実施形態に係るAPサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。
図3】本発明の情報処理装置の一実施形態に係るAPサーバのハードウェア構成の一例を示すブロック図である。
図4】本発明の情報処理装置の一実施形態に係るAPサーバ上に実現される機能的構成の一例を示す機能ブロック図である。
図5】文書処理制御部によって実現される文書ファイルの交換の仕組みの例を説明する図である。
図6】文書ファイル中で自動認識の対象となる文字列の例を説明する図である。
図7】利用依頼設定情報により利用登録を行った非契約事業者の情報を表示するWebページの例を示す図である。
図8】文書ファイルの保管に係わる情報、及びその関係の例を説明する図である。
図9】納品書の文書ファイルによって表される画像が配置されたWebページの例を示す図である。
図10】文字列の修正が可能な状態のWebページの例を示す図である。
図11】入力フィールドの選択後の表示例を示す図である。
図12】1文字列の修正後のWebページの例を示す図である。
図13】別の形式の納品書の画像例を示す図である。
図14】別の形式の納品書をベースに生成される他の文書の画像例を示す図である。
【発明を実施するための形態】
【0011】
以下、本発明を実施するための形態について、図を参照しながら説明する。なお、説明する実施形態は、あくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。本発明の技術的範囲には、様々な変形例も含まれる。
【0012】
図1は、本発明の情報処理装置の一実施形態に係るAP(APplication)サーバによりサービス提供会社が提供するサービス(以降「本サービス」と表記)の例の概要を説明する図である。
サービス提供会社WAは、文書の交換を必要とする複数の事業者のうちの少なくとも1事業者を顧客として、その複数の事業者間のネットワークを介した文書の送受信を中継する形の文書交換を実現させる本サービスを提供する。複数の事業者のうちの少なくとも1事業者が顧客、つまりサービス提供会社WAの契約者であれば良いのは、その1事業者の文書を他の全ての事業者に中継するような場合も想定されるからである。そのような場合、他の全ての事業者が顧客でなくても、契約者である1事業者の文書を他の全ての事業者が受信できるようにしなければならない。
【0013】
事業者は、個人、或いは企業等の組織である。図1では、事業者の例として、A社CA、B社CBの2つの会社を示している。図1の説明では、事業者の表記として、「A社CA」、「B社CB」を用いる。事業者を想定する必要のないような場合には、表記として「事業者」を用いる。
B社CBは、例えば製品Pを製造し、製造した製品Pを商品として販売する受注側企業である。商品である製品Pは、発注した企業に対し、配送等により納品される。B社CBが販売する商品は、他社から購入した商品であっても良い。他方のA社CAは、B社CBに対し、そのB社CBが製造し販売する製品Pを発注(購入)する側の発注側企業である。以降、混乱を避けるために、製品Pは「商品P」と表記する。また、A社CA、B社CBはともに顧客、つまりサービス提供会社WAと契約した企業と想定する。
【0014】
発注側企業と受注側企業との間で取り引きが行われる場合、その2つの企業間では各種文書交換が行われる。ここで、理解を容易とするために、従来、行われていた例を説明する。
例えば発注側企業は、受注側企業から購入する商品を決定し、決定した商品を購入するための発注書を作成して受注側企業にメール等により送付する。発注書が送付された受注側企業は、送付された発注書を受け取った旨をメール等で発注側企業に通知する一方、発注書で指定された商品を発注側企業に配送する準備を行い、数を含め指定された商品を発注側企業に配送する。配送する準備には、配送の際、発注側企業に渡すべき納品書、及び発注側企業から受け取るべき受領書の作成が含まれる。それにより、発注書の交換の後、納品書、及び受領書の交換が行われる。実際の商品の配送は、多くの場合、依頼した配送業者によって行われる。
【0015】
納品書には、例えば商品の配送元、及び配送先の各住所、各名称、及び電話番号等を表す配送関係情報、並びに商品、及びその数等の配送される商品を表す配送商品情報が印刷されている。これは、受領書でも同じである。そのため、納品書と受領書とは、関連性が存在し、且つ文字列の大部分が共通した文書(帳票)となっている。
発注側企業は、納品されるべき商品が実際に存在するか否かを確認して、商品を受け取る検収を行う。検収(検品)では、納品された商品に視認できる不具合、例えば破損等があるか否かの確認も行われる。それにより、納品書に記載されていない商品、及び許容できない不具合が確認された商品等は返品される。
【0016】
検収後、発注側企業は、受領書を配送業者に渡す。発注側企業は、納品された商品を確認したことを表すために、例えば印(受領印)を押印するか、或いはサインした受領書を配送業者に渡す。このことから、受領書は、納品された商品を発注側企業が確認したことを示す文書となる。内容的には同じ文書であっても、納品書は発注側企業宛の文書、受領書は受注側企業宛の文書である。このこともあり、それらは明確に区別される。
商品の納品後、受注側企業は、発注側企業から代金の支払いを求めるための請求書を作成し発行する。発行された請求書は、発注側企業に送付される。その請求書の送付により、発注側企業は、銀行振り込み等により、受注側企業に代金を支払う。
【0017】
このように、商品取り引きを行う2つの企業の間では、1回の取り引きにより、上記のような複数回の文書交換が行われる。文書交換は、これまで郵送、或いはメール等により行われるのが一般的である。本サービスでは、郵送、及びメール以外での各種文書交換を可能にする。
【0018】
図1に示すように、A社CAとB社CBとの間で商品Pの取り引きが行われる場合、A社CAとB社CBとの間でも、上記のような各種文書交換が行われることが想定される。本サービスは、各種文書交換の全て、或いはそのうちの一部の実現に用いることができる。本サービスでは、ネットワークを介した通信を利用しての文書の送受信により、文書交換を実現させる。ネットワークを介して文書を送受信するため、文書としては、基本的に電子化された文書ファイルD、つまりデータが対象となる。なお、文書ファイルDのファイル形式等は、特に限定されない。例えば文書ファイルDは、PDF(Portable Document Format)ファイル等であっても良い。本サービスでは、事業者間で交換されるメッセージを文書ファイルDとして扱うことにより、メッセージ交換もサポートする。
【0019】
文書ファイルDは、送付すべき事業者にのみ送付する必要がある。各事業者は、本サービスの利用のために、様々な端末(PC(Personal Computer)等の通信機能を備えた情報処理装置)を使用することができる。このことから、本サービスでは、顧客か否かに係わらず、本サービスを利用する事業者に利用登録を行わせるようにしている。それにより、本サービスの利用は、利用登録を行った事業者に限定している。利用登録を行った事業者か否かは、端末をサービス提供会社WAに接続させたユーザーにログインを求めることで確認するようになっている。ここでは、便宜的に、ログインはID(IDentifire)、及びパスワードの入力により行うものと想定する。
【0020】
サービス提供会社WAには、文書ファイルDの保管用のストレージSTが1つ以上、存在する。このストレージSTは、例えばAPサーバに搭載、若しくは接続されたものか、或いはAPサーバと通信可能な別のサーバに搭載、若しくは接続されたものである。
【0021】
このストレージSTには、事業者毎に、文書ファイルDの保管のための専用の保管領域である個別保管領域SAが確保されている。個別保管領域SAは、事業者別に用意されており、事業者に対応付けられた個別保管領域SAには、その事業者への送信を想定した文書ファイルDのみが保管される。例えばA社CA用の個別保管領域SAには、A社CAへの送信を想定した文書ファイルDのみが保管される。そのようにして、各個別保管領域SAは、対応する事業者に送付すべき文書ファイルDの保管用となっている。それにより、事業者であるB社CBから取り込まれた文書ファイルDは、A社CA用の個別保管領域SAに保管される。本サービスでは、このような個別保管領域SAを用いて、文書ファイルDの送付先を管理し、送付すべき事業者にのみ、文書ファイルDを送付させるように、事業者間の文書交換を中継する。
【0022】
個別保管領域SAに保管された文書ファイルD等の確認は、その個別保管領域SAが割り当てられた事業者が行えるだけでなく、文書ファイルD等を取り込ませた事業者も行えるようにさせている。これは、送付元の事業者が、文書ファイルDが実際に取り込まれて適切に処理されたか否かを確認できるようにするためである。必要以上の情報が得られないように、送付元の事業者が確認可能な文書ファイルDは、その事業者から取り込まれた文書ファイルDのみである。そのような文書ファイルDの確認を可能にする意味からも、本サービスの利用はログインした事業者に制限している。
【0023】
上述の文書交換では、受領書は、他の文書である納品書とは明確に区別すべき文書である。受領書は、納品書と同じく、配送、つまり納品された商品を表す文書であっても、それを受け取るべき企業が納品書とは異なる。受領書は、発注側企業が送付元となることから、受け取るべき企業である受注側企業の他に、発注側企業も受け取るべき文書となる。発注側企業にとって、実際に納品される商品は不明である。受注側企業は、何らかの理由により、指定された商品を複数回に分けて配送するようなこともあり得る。このようなことから、受領書は、基本的に、発注側企業が作成する対象ではない。
【0024】
発注側企業は、納品書に示された商品を実際に受け取れるとは限らない。受注側企業の処理の誤り、或いは配送業者の配送ミス等により、発注側企業が指定した商品が納品されない場合があり得る。単位の誤りにより、指定した数の商品が納品されない場合もあり得る。また、視認する範囲で許容できない不具合が認められる商品を発注側企業が返品するような場合もあり得る。何れの場合であっても、結果として、発注側企業には納品すべき商品が納品されないことになり、受領書の内容、つまり何れか1つ以上の商品の種類、その数、及び単位等を表す1つ以上の文字列は不適切なものとなる。そのため、受領書の内容は、適切なものに修正する必要がある。
本サービスでは、このような受領書の内容の修正をサポートする。図1には、そのための仕組みの例を表している。このことから、B社CBに用意された文書ファイルDの文書は納品書である。文書ファイルDの文書は、納品書と同じような位置付けの別の文書であっても良い。
【0025】
文書ファイルDは、例えばB社CBにより、サービス提供会社WAに送信される。この文書ファイルDは、商品Pの配送により作成され送信されることから、商品Pの配送先であるA社CA用の個別保管領域SAに保管される。なお、サービス提供会社WAは、文書ファイルDを自動的に取り込むことも可能である。
A社CA用の個別保管領域SAに保管された文書ファイルDは、A社CA側の要求により、A社CAに送信される。納品書は、配送された商品の検収のために参照される文書であり、直ちに内容の確認が行われるのが普通である。このことから、本サービスでは、文書ファイルDの画像を配置したWebページの形で文書ファイルDをA社CAに送信する。それにより、本サービスでは、納品書の文書ファイルDを要求した場合、納品書の内容を閲覧可能な状態で送信することにより、その内容をより迅速に確認できるようにさせている。
【0026】
このWebページは、図9図12を参照して詳細を後述するが、納品書の画像上で内容、つまり文字列の修正が可能なものである。文字列の修正を可能とすることにより、発注側企業であるA社CAは、実際に配送された商品の検収を行った結果に応じて、不適切な文字列を修正することができる。文字列の修正とは別に、配送先が検収したことを表す情報の入力、例えば受領印の押印が可能である。受領印の押印は、例えば電子印鑑を用いて行うものである。このことから、受領印が押印された納品書は、受領書として扱われる。納品書から受領書を生成することから、受注側企業であるB社CBは、納品書の文書ファイルDのみを用意すれば良いようになっている。ここでは、便宜的に、検収したことを表す情報の入力は、受領印の押印によって行われるもののみ想定する。入力する情報は、別のものであっても良く、特に限定されない。
【0027】
受領印の押印は、納品書の元の内容を変更させることから、納品書の内容を修正する操作と言える。このことから、納品書の内容の修正は、受領印の押印による修正と、文字列の修正と、に大別することができる。ここでは、特に断らない限り、内容の修正は文字列の修正を指す意味で用いる。なお、文字列とは、1文字以上の文字列のことであり、文字の種類としては、ひらがな、漢字、英数字、及び他の各種記号等を挙げることができる。文字列の修正には、既存の文字列の修正、つまり1文字以上の変更、追加、或いは削除だけでなく、既存の文字列が存在しない箇所への1文字以上の追加も含まれる。
【0028】
受領印の押印が必要なこともあり、Webページが送信されたA社CAは、修正内容を表す情報(以降「修正情報」と表記)をサービス提供会社WAに送信する。サービス提供会社WAは、修正情報を文書ファイルDに反映させたものを修正文書ファイルSDとしてB社CB用の個別保管領域SAに保管する。それにより、B社CBは、受領書である修正文書ファイルSDをサービス提供会社WAから受信することができる。本サービスでは、受領書は、納品書とは異なり、直ちに閲覧できるようにすることは求められていないとして、修正文書ファイルSDの送信はダウンロードにより行うようにしている。本実施形態において、修正文書ファイルSDは第2の文書ファイルに相当し、文書ファイルDは第1の文書ファイルに相当する。
なお、修正文書ファイルSDは、ベースとなる文書ファイルDの存在に着目した呼称であり、事業者間で交換の対象であることは同じである。そのため、多くの場合、文書ファイルDと区別する必要はない。このことから、特に断らない限り、「文書ファイルD」は、交換の対象となる文書ファイルの総称として用いることとする。
【0029】
このように、本サービスでは、納品書をベースに、受領印の押印に加え、文字列の修正を可能とさせ、その修正内容を反映させたものを受領書とさせる。そのため、発注側企業は、実際に受け取った商品に応じて、受領書中の文字列を任意に修正させることができる。納品書をベースにさせていることから、修正が必要な文字列のみを修正すれば良い。このことから、発注側企業は、文字列の修正は容易、且つ迅速に行うことができる。この結果、受注側企業は、検収(検品)結果により、発注側企業が必要に応じて納品書の内容が修正された内容の受領書を修正文書ファイルSDとして受信することができる。
受注側企業は、修正文書ファイルSDにより、発注側企業が実際に受け取った商品を確認できることから、発注側企業が受け取れなかった商品の有無を直ちに確認することが可能である。それにより、発注側企業が受け取れなかった商品が存在していた場合、そのことへの対応も迅速に行えることとなる。
【0030】
以降は、図2図14を参照しつつ、図1に例示する本サービスの実現方法について詳細に説明する。
図2は、本発明の情報処理装置の一実施形態に係るAPサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。ネットワーク環境として示すシステムは、本発明の情報処理システムの一実施形態に相当する。
【0031】
APサーバ1を用いて構築されたシステムは、APサーバ1にDB(Data Base)サーバ2、及び1台以上の通信機能を備えたプリンタ5を例えばLAN(Local Area Network)により接続させて構築したものであり、1つのWebサイトを実現させている。図2では、APサーバ1、DBサーバ2、及びプリンタ5がサービス提供会社WA内に設置されているが、これらはクラウドサービスにより提供されるものであっても良い。このこともあり、APサーバ1、DBサーバ2、及びプリンタ5は全て、設置場所、提供者は特に限定されない。また、APサーバ1、及びDBサーバ2は、本サービスを提供するうえで主要な情報処理装置であるが、別の情報処理装置、例えばWebサーバ、或いは/及び、ファイアウォール等が含まれていても良い。APサーバ1、及びDBサーバ2のうちの少なくとも一方が複数台、設置されていても良い。その場合、負荷分散装置(Load Balancer)を更に含めても良い。プリンタ5は、印刷物での文書交換を望む事業者に対応するためのものである。多数の印刷物の印刷に対応可能なように、プリンタ5は、複数台、設置するのが望ましい。
【0032】
APサーバ1は、ネットワークNと直接、或いは間接的に接続されている。このため、APサーバ1は、ネットワークNを介した通信が可能な情報処理装置を端末として使用するユーザーに対して本サービスを提供することができる。ユーザーは、多くの場合、利用登録を行った事業者、例えば受注側企業3、或いは発注側企業4等の従業員である。
【0033】
DBサーバ2は、APサーバ1からの要求に応じた処理を行うサーバである。APサーバ1は、取り込んだ、或いはアップロードされた文書ファイルDをDBサーバ2に送信し保管させる。文書ファイルD以外の本サービスに係わる情報は、APサーバ1に保管される。このことから、APサーバ1は、DBサーバ2を用いて、本サービスを提供する。それにより、図1に示すサービス提供会社WAのストレージSTには、APサーバ1、及びDBサーバ2がそれぞれアクセス可能なストレージがともに相当する。
【0034】
図2では、本サービスを利用する企業として、受注側企業3-1~3-L、及び発注側企業4-1~4-Kを示している。以降、便宜的に、区別する必要のないような場合、符号として受注側企業には「3」、発注側企業には「4」を付すこととする。図1において、受注側企業3にはB社CB、発注側企業4にはA社CAがそれぞれ相当する。
【0035】
このような企業の分類は便宜的なものであり、実際には、必ずしも明確に企業を分類することはできない。これは、受注側企業3であるとともに、発注側企業4である企業も少なくないからである。しかし、ここでは、説明上、便宜的に、企業は受注側企業3、及び発注側企業4のうちの何れか一方に分類されると想定する。
【0036】
受注側企業3には、図2に示すように、サーバ31と複数台の端末32とをネットワーク33に接続させた構成のシステムが構築されている。サーバ31に搭載されたストレージ35には、自動的に取り込むべき文書ファイルDを保管するための保管領域36が確保されている。その保管領域36は、文書ファイルDを自動的に取り込む場所として受注側企業3自身が指定したものである。そのような保管領域36を受注側企業3が指定したのは、サーバ31は常に動作させているものだからである。そのサーバ31上の保管領域36を指定することにより、受注側企業3は、任意のタイミングで文書ファイルDを自動的に取り込ませることができる。その利便性から、本サービスでは、文書ファイルDを自動的に取り込む場所の他に、その取り込みを行うタイミングも設定可能としている。なお、保管領域36は、常に動作させるようにした端末32に搭載のストレージ内に確保された領域であっても良い。保管領域36は、それが存在するストレージ35、及びそのストレージ35にアクセスする情報処理装置を制限するものではない。保管領域36は、他との区別を明確にするために、以降「取込保管領域36」と表記する。
【0037】
事業者間で交換される文書のうちには、定期的に交換が行われるものがあり得る。例えば取り引きを繰り返し行うような事業者間では、処理の煩雑さを抑える意味もあり、請求書を送付するタイミングを決め、決めたタイミングまでの未払い分を1つ以上の請求書で請求するようなことが行われるのが普通である。このような請求書の文書ファイルDが、取込保管領域36に保管する文書ファイルDとして考えられる。この文書ファイルDは、通常、複数の文書ファイルDが集約(結合)された集約文書ファイルDの一部である。
【0038】
一方、発注側企業4には、1台以上の端末41が設置されている。その端末41は、ネットワークNを介したAPサーバ1との通信が可能な情報処理装置である。発注側企業4の従業員は、この端末41を用いて本サービスを利用することができる。この端末41は、受注側企業3の端末32と区別するために、以降「発注側端末41」と表記する。端末32は、「受注側端末32」と表記する。そのような区別を行う必要がないような場合、つまり発注側端末41、及び受注側端末32の何れであっても良いような場合、端末は「事業者端末」と表記する。本実施形態において、受注側企業3は第1の事業者、受注側端末32は第1の端末にそれぞれ相当する。発注側企業4は第2の事業者、発注側端末41は第2の端末にそれぞれ相当する。
【0039】
図2では、受注側企業3とは異なり、発注側企業4にはサーバ等を示していない。これは、発注側企業4の大部分では、定期的に交換するような文書はあまり考えられないからである。言い換えれば、サーバ31のような情報処理装置が本サービスに係わるケースは比較的に少ないと考えられるからである。しかし、図2は、サーバを用いたシステムを発注側企業4が構築していないことを示すものではない。
また、発注側端末41、及び受注側端末32ともに、発注側企業4、及び受注側企業3でそれぞれ構築されたシステムのノードでなくとも良い。つまり、それらは、スマートフォン、或いはタブレットPC等の携帯可能であり、且つ使用場所を選ばないような端末であっても良い。このことから、受注側端末32、及び発注側端末41ともに、従業員の私物であっても良い。
【0040】
図3は、本発明の情報処理装置の一実施形態に係るAPサーバのハードウェア構成の一例を示すブロック図である。次に図3を参照し、APサーバ1のハードウェア構成例について具体的に説明する。なお、この構成例は1例であり、APサーバ1のハードウェア構成はこれに限定されない。
【0041】
APサーバ1は、CPU(Central Processing Unit)11と、ROM(Read Only Memory)12と、RAM(Random Access Memory)13と、バス14と、入出力インターフェース15と、出力部16、入力部17と、記憶部18と、2つの通信部19、20と、ドライブ21と、を備えている。
【0042】
CPU11は、ROM12に記録されているプログラム、或いは/及び記憶部18からRAM13にロードされたプログラムに従って各種の処理を実行する。APサーバ1として機能させるアプリケーション・プログラム、つまり本サービスの提供用に開発されたプログラムは、例えば記憶部18に記憶されている。そのプログラムをCPU11がRAM13に読み出して実行することにより、APサーバ1は、受注側企業3、及び発注側企業4に対し、本サービスを提供することができる。
【0043】
RAM13には、CPU11が各種の処理を実行する上において必要なデータ等も適宜記憶される。そのデータには、CPU11が実行する各種プログラムも含まれる。
CPU11、ROM12及びRAM13は、バス14を介して相互に接続されている。このバス14にはまた、入出力インターフェース15も接続されている。入出力インターフェース15には、出力部16、入力部17、記憶部18、2つの通信部19、20及びドライブ21が接続されている。
【0044】
出力部16は、例えば液晶等のディスプレイを含む構成である。出力部16は、CPU11の制御により、各種画像を表示する。出力部16は、APサーバ1に搭載されたものであっても良いが、必要に応じて接続されるものであっても良い。つまり、出力部16は、必須の構成要素ではない。
【0045】
入力部17は、例えばキーボード等の各種ハードウェア釦等を含む構成である。その構成には、マウス等のポインティングデバイスが1つ以上、含まれていても良い。操作者は、入力部17を介して各種情報を入力することができる。この入力部17も、APサーバ1に搭載されたものであっても良いが、必要に応じて接続されるものであっても良い。つまり、入力部17も、必須の構成要素ではない。
【0046】
記憶部18は、例えばハードディスク装置、或いはSSD(Solid State Drive)等の補助記憶装置である。データ量の大きいデータは、この記憶部18に記憶される。この記憶部18は、図1に示すサービス提供会社WAのストレージSTの1つに相当する。
【0047】
通信部19は、ネットワークNを介した受注側企業3、及び発注側企業4のそれぞれで使用される情報処理装置との間の通信を可能にする。図2に示すサーバ31、受注側端末32、及び発注側端末41は全て、その情報処理装置に相当する。通信部20は、DBサーバ2との間の通信を可能にする。以降、混乱を避けるために、通信部19は「端末通信部19」、通信部20は「DB通信部20」とそれぞれ表記する。
【0048】
ドライブ21は、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリカード等のリムーバブルメディア25を着脱可能な装置である。ドライブ21は、例えば装着されたリムーバブルメディア25からの情報の読み取り、及びリムーバブルメディア25への情報の書き込みが可能である。それにより、リムーバブルメディア25に記録されたプログラムは、ドライブ21を介して、記憶部18に記憶させることができる。また、ドライブ21に装着されたリムーバブルメディア25は、記憶部18に記憶されている各種データのコピー先、或いは移動先として用いることができる。
【0049】
このようなAPサーバ1が備えるハードウェア資源は、アプリケーション・プログラムを含む各種プログラムによって制御される。その結果、APサーバ1は、受注側企業3、及び発注側企業4に対して本サービスを提供することができる。各種プログラムには、OS(Operating System)が含まれる。本サービスを提供するためのアプリケーション・プログラムは、そのOS上で動作する。
【0050】
DBサーバ2としては、APサーバ1のハードウェア構成と基本的に同じものを採用することができる。そのため、ここでの詳細な説明は省略する。ただし、DBサーバ2を構成する記憶部としては、より大容量のストレージが搭載されているのが望ましい。その記憶部は、DBサーバ2に搭載されたものであっても良いが、DBサーバ2に接続されたものであっても良い。ここでは、APサーバ1、及びDBサーバ2ともに、記憶部は搭載されたもののみ想定する。
受注側端末32、及び発注側端末41も、APサーバ1のハードウェア構成と基本的に同じものを採用することができる。しかし、これら事業者端末では、出力部16、及び入力部17は搭載されているか、或いは接続させている必要がある。2つの通信部19、20のうちの一方が搭載されているか、或いは接続されていれば良い。ドライブ21は搭載されていなくとも良い。
【0051】
図4は、本発明の情報処理装置の一実施形態に係るAPサーバ上に実現される機能的構成の一例を示す機能ブロック図である。次に図4を参照しつつ、APサーバ1上に実現される機能的構成の例について詳細に説明する。
【0052】
APサーバ1のCPU11上には、機能的構成として、図4に示すように、振分制御部111、企業登録部112、認証部113、文書処理制御部114、データ管理部115、自動分割部116、設定管理部117、アクセス制御部118、通知制御部119、及び辞書登録部120が実現されている。これらは、上記アプリケーション・プログラムを含む各種プログラムをCPU11が実行することにより実現される。その結果として、記憶部18には、企業登録情報格納部181、企業マスター格納部182、パッケージ情報格納部183、操作記録情報格納部184、オブジェクトリスト格納部185、設定情報格納部186、修正設定情報格納部187、及び辞書格納部188が情報格納用に確保されている。
文書処理制御部114、データ管理部115、及び自動分割部116は、図1に示すような修正文書ファイルSDの生成、保管の実現に特に重要な構成要素である。本実施形態において、文書処理制御部114は、ページ作成手段、ページ送信制御手段、ファイル送信制御手段、及び自動修正手段に相当する。データ管理部115は、保管制御手段、及びファイル特定手段に相当する。
【0053】
振分制御部111は、端末通信部19との間でデータの授受を行い、端末通信部19から入力したデータを渡すべき出力先を特定し、特定した出力先にデータを渡す。データを渡す出力先は、ここでは企業登録部112、認証部113、文書処理制御部114、及び辞書登録部120のうちの何れかである。振分制御部111がデータを渡すべき出力先に渡す結果、そのデータの処理に必要な機能が動作する。
【0054】
企業登録部112は、本サービスを利用する事業者の情報を登録するための機能である。この情報が、企業登録情報であり、記憶部18に確保された企業登録情報格納部181に格納される。企業登録情報の大部分は、事業者によって入力される情報である。しかし、その一部は、企業登録部112により、記憶部18に確保された企業マスター格納部182に格納されている企業マスターを参照して自動的に生成される。
【0055】
上記のように、本サービスの利用には利用登録が必要である。その利用登録を求める事業者は、本サービスの契約者、つまり顧客である事業者と、何れかの顧客に本サービスを提供するために利用登録が必要になった事業者と、に分けられる。利用登録が必要になった事業者は、顧客として契約しなくとも良い。しかし、企業登録情報の内容、つまり企業登録情報を構成する主な項目の組み合わせは、事業者の分類に係わらず同じである。以降、便宜的に、顧客である事業者は「契約事業者」、顧客でない事業者は「非契約事業者」と夫々表記する。
【0056】
企業マスターは、情報が公開されている企業等毎に、その企業等についての情報がまとめられたファイルである。企業等についての情報には、例えば企業コード、法人名、住所、連絡先、及び業種の各情報が含まれる。その他に、作成日時、及び更新日時の各情報が追加されている。ここでは、これらをまとめて「企業マスター個別情報」と表記する。それにより、企業マスターは、企業マスター個別情報を集約させたものである。また、企業マスター個別情報では、それが企業マスターに格納されている企業等を指す意味で「企業」を用いる。
【0057】
企業コードは、公開されている企業を一意に識別可能な識別情報であるとともに、公開されている情報である。法人名、住所、連絡先、及び業種も、全て公開されている情報である。作成日時は、企業マスター個別情報が企業マスターに追加された日時を表し、更新日時は、企業マスター個別情報が最後に更新された日時を表す。
【0058】
一方、企業登録情報は、例えばお客様コード、利用状態、事業者名、部署名、担当者名、メールアドレス、住所、作成日時、及び更新日時等の情報を含む。
お客様コードは、利用登録した事業者を一意に識別可能な識別情報である。本サービスでは、企業マスターに企業マスター個別情報が格納されている企業の利用登録である場合、お客様コードとして、企業マスター個別情報中の企業コードを用いるようにしている。企業マスターに企業マスター個別情報が格納されていない企業の利用登録では、企業登録部112は、企業マスター個別情報、及び企業登録情報の何れにも用いられていないユニークな識別情報を自動的に生成してお客様コードとする。ここでは、お客様コードをログインのための認証用IDと想定する。
【0059】
利用状態は、本サービスの利用状態を表す情報である。具体的には、利用状態は、本サービスを利用する事業者が契約者か否か、及び本サービスを利用中か否か等を表す情報である。
事業者名、部署名、担当者名、メールアドレス、及び住所は、全て事業者が入力する情報である。事業者は、これらの情報入力を通して、送付の対象となる文書ファイルDが発生した旨を通知するメールの送信先、印刷物を郵送等で届ける場合の届け先等を任意に指定することができる。
【0060】
作成日時は、企業登録情報が企業登録情報格納部181に追加された日時を表す。更新日時は、企業登録情報が最後に更新された日時を表す。これらは全て、企業登録部112によって追加、或いは更新される。
契約事業者は主に、本サービスの利用を自ら決めた事業者である。契約を希望する事業者は、自らの意思でAPサーバ1に事業者端末を接続させ、利用登録を行うものと考えられる。
【0061】
一方、非契約事業者は、その取引先等の事業者が本サービスの導入に伴い、本サービスを利用することなった事業者である。本サービスについての情報を事前に把握している可能性は低いと考えられる。また、入力を必須とする情報も、非契約事業者と契約事業者とでは異なる部分がある。このようなことから、本サービスでは、非契約事業者を想定した利用登録用の専用サイトを用意し、その専用サイトへのリンク情報を埋め込んだメールを非契約事業者宛に送付するようにしている。そのために、契約事業者には、本サービスの利用を望む非契約事業者のメールアドレスを指定可能にさせている。そのようにして、本サービスでは、非契約事業者が本サービスをより容易に利用できるようにさせている。
【0062】
企業登録部112は、事業者を契約事業者、及び非契約事業者のうちの何れかに分類し、必要な情報を事業者に入力させるための処理を行い、企業登録情報を企業登録情報格納部181に格納する。専用サイトへのアクセスを非契約事業者に依頼するためのメールの送信は、文書処理制御部114、及び通知制御部119によって実現される。
【0063】
認証部113は、本サービスを利用する事業者が利用登録を行った事業者か否かを確認する認証を行う。また、認証に必要な情報の管理も行う。そのために、ログイン用のWebページの送信も認証部113によって行われる。このページの送信は、例えば専用サイトへのアクセス時を含む利用登録以外で事業者端末がAPサーバ1に接続された場合に行われる。
【0064】
ここでは認証用の情報として、認証用ID、及びパスワードを想定している。認証用IDとしては、お客様コードを想定している。認証部113は、パスワードの変更に対応する処理も必要に応じて行う。認証用の情報は企業登録情報と別に管理しても良いが、ここでは企業登録情報に含まれているものと想定する。その想定では、企業登録情報は認証部113による更新が行われる。
【0065】
文書処理制御部114は、本サービスを提供するための主な処理、或いは制御を行う。この文書処理制御部114により、上記専用サイトへのアクセスを求めるメールの送信に加え、事業者間での文書ファイルDの交換、その交換のための各種設定情報の登録等も可能になる。
【0066】
図5は、文書処理制御部によって実現される文書ファイルの交換の仕組みの例を説明する図である。
図5において、SSは、APサーバ1、及びDBサーバ2によって実現される、文書ファイルDを含む各種データの保管のための保管空間である。この保管空間SSは、APサーバ1が備える記憶部18、及びDBサーバ2が備える記憶部200にそれぞれ確保された保管領域により仮想的に実現される空間である。この保管空間SSには、図1に示すストレージSTに確保された個別保管領域SAの全てが含まれる。
【0067】
各個別保管領域SAは、論理的に複数の領域に分割することが可能である。事業者は、個別保管領域SA内の論理的な構造を設定可能である。図5では、その領域として、各個別保管領域SAに複数のフォルダーSB、SCが設定されていることを示している。フォルダーSBは、例えばルートフォルダーであり、フォルダーSCは、ルートフォルダーであるフォルダーSB内に含まれるサブフォルダーである。事業者は、階層構造の設定も可能である。
【0068】
請求書DS、及び契約書DKはともに、交換の対象となる文書ファイルDである。これらの文書ファイルDは、取り込まれた後、指定された、或いは自動認識された送付先に対応付けられている個別保管領域SAに保管される。請求書DS、契約書DKは、文書ファイルDとしての種類(属性)が異なる。そのため、B社CBから取り込まれたA社CA宛ての請求書DSは、A社CA用の個別保管領域SA内に作成されたサブフォルダーSCの一つである「経理部」フォルダーSCに保管される。C社CCから取り込まれたA社CA~C社CC宛ての契約書DKは、それぞれ、各個別保管領域SA内に作成された「社長」フォルダーSCに保管される。自身が送付先に含まれる場合、自身用の個別保管領域SAは、文書ファイルDの保管領域として使用することができる。
【0069】
A社CA~C社CCがそれぞれ階層構造で設定可能な各フォルダーは、文書ファイルDの保管先となる。文書ファイルDの実際の保管先は、フォルダーのうちの一つであり、文書ファイルDを実際に保管するためには、フォルダーのうちの一つを保管先として選択しなければならない。その保管先の選択に、文書ファイルDを送信させた事業者による指定、或いは文書ファイルDに存在する文字列の自動認識結果が用いられる。それにより、各フォルダーには、そのフォルダーに保管すべき文書ファイルDのみが保管される。
【0070】
図6は、文書ファイル中で自動認識の対象となる文字列の例を説明する図である。
図6には、文書ファイルDにより表される画像の例として、発注書DHの例を示している。その発注書DHでは、一点鎖線で囲った文字列領域MRを3つ示している。各文字列領域MR内に存在する文字列、つまり文字列「発注書」「0009」「1000476」は全て、自動認識の対象となる文字列の例である。
【0071】
文字列「発注書」は、文書の種類を表す文字列である。文字列「0009」は、お客様コードを表す文字列である。文字列「1000476」は、発注書DHに割り当てられた発注番号である。この発注番号は、各発注書DHで異なる。そのため、発注番号は、発注書DHを一意に識別可能な識別情報となっている。
発注書DHでは、これら文字列が抽出され、自動認識される。自動認識により特定されたお客様コードは、発注書DHの文書ファイルDを保管すべき個別保管領域SAを指定する。文書の種類は、その個別保管領域SA内に作成されたフォルダーのうちで文書ファイルDを保管すべきフォルダーを指定する。発注番号は、そのフォルダー内に作成されたフォルダーのうちで文書ファイルDを保管すべきフォルダーを指定する。最後に指定されたフォルダーが文書ファイルDの実際の保管先である。このようなことから、文書ファイルD中に存在する複数の文字列の自動認識を行うことにより、階層構造を有するように複数のフォルダーが作成されている個別保管領域SAに対応することができる。つまり、選択肢として多数の保管先が存在していたとしても、そのうちから一つの保管先を自動的に選択することができる。自動認識する対象とする文字列、及びその数等は、特に限定されない。
【0072】
文書ファイルD中から自動認識すべき文字列の抽出(特定)、及び抽出した文字列の自動認識は、自動分割部116によって行われる。図6に示すような文字列領域MRは、文書の先頭ページに存在する。このことから、自動分割部116は、文字列の自動認識を通して、集約文書ファイル中の1文書分のデータを特定し、特定した1文書分のデータを集約文書ファイルから分割する。それにより、自動分割部116は、分割した1文書分のデータは、それぞれ1文書ファイルDとして扱うのを可能とさせる。文書処理制御部114は、振分制御部111から渡された文書ファイルDにおける文字列の自動認識の必要性を判定し、自動認識が必要と判定した文書ファイルDを自動分割部116に渡す。文書ファイルDを送信させた事業者が、保管先の決定に必要な全ての情報を指定していなかった場合、その文書ファイルDは自動認識が必要とされる。
【0073】
配置される文字列の種類、及びその文字列の配置等を含む文書の形式は、それを交換する何れかの事業者の意向等によって決められる。そのため、本サービスを利用する前に各事業者が採用していた文書の形式も様々なものがあると考えられる。このことから、例えば文書の種類毎に、その文書の形式を統一させるようにする場合、大部分の事業者には、文書の形式の変更を求めることになる。これは、文書の形式を変更する必要がある事業者にとっては、大きな負担となる。なぜなら、新しい文書の形式に対応しなければならないだけでなく、既に存在する文書ファイルDも再利用できなくなるからである。
【0074】
このようなことから、本サービスでは、事業者が本サービスをより利用しやすくなるように、発注書DH、請求書DS、及び納品書を含む各種文書の形式の統一は求めないようにしている。各種文書で形式の統一を求めないことから、各種文書には様々な形式のものが存在することになる。そのため、本サービスでは、文書ファイルD中から自動認識すべき文字列の抽出(特定)を可能とさせる辞書を事業者に登録可能にさせている。
辞書は、図6に示すような各文字列領域MRの位置、各文字列領域MRに存在する文字列の種類等を指定する。辞書登録部120は、辞書の登録のための機能である。その辞書登録部120により登録された辞書は、記憶部18に確保された辞書格納部188に格納される。それにより、自動分割部116は、辞書格納部188に格納された辞書を参照し、文書ファイルD中からの文字列の抽出、及び抽出した文字列の自動認識を行う。
【0075】
本サービスでは、納品書をベースに受領書を生成する。印刷物である受領書には、受領印を押印する押印箇所が設けられているのが普通である。このことから、電子データである納品書でも、受領印を押印する押印箇所が設けられているものと想定している。その押印箇所に受領印を押印できるように、納品書の辞書では、文字列領域MRの他に、押印箇所を表す押印領域を指定させるようにしている。
【0076】
図5の説明に戻る。
各個別保管領域SAは、それが割り当てられた事業者にとって、文書ファイルDを確認するうえでの表示環境HKとなる。それにより、事業者は、個別保管領域SAで設定された論理的な構造に沿って、保管されている文書ファイルDの確認、閲覧、及び文書ファイルDのダウンロードを行うことができる。これは、自動認識により文書ファイルDの保管先が自動的に決定されたか否かには関係しない。
【0077】
A社CAの個別保管領域SAでは、「経理部」フォルダーSC、及び「社長」フォルダーSCの両方にアクセス制限の設定が行われている。それにより、「経理部」フォルダーSC、及び「社長」フォルダーSCの両方は、アクセス権限を有する従業員のみ、保管された文書ファイルDを確認できるようになっている。本サービスでは、このようなアクセス制限も可能にさせている。
【0078】
個別保管領域SAは、契約の有無に係わらず、本サービスを利用する各事業者に割り当てられる。しかし、本サービスでは、全ての非契約事業者を対象にした保管領域を確保し、各非契約事業者の個別保管領域SAは、その保管領域内に確保するようにしている。そのため、各非契約事業者の個別保管領域SAは、図5におけるA社CAの「経理部」フォルダーSC、或いは「社長」フォルダーSCのように扱われる。
このようなことから、個別保管領域SA中に存在する保管先のうちから、実際に文書ファイルDを保管させる保管先を選択することにより、部署を含む事業者間での適切な文書ファイルDの交換が実現される。
【0079】
図5に示すような文書ファイルDの交換の実現のために、各種設定情報が参照される。各種設定情報の登録は、記憶部18に確保された設定情報格納部186に格納することで行われる。
【0080】
各種設定情報としては、利用依頼設定情報、保管設定情報、取込設定情報、配信管理情報、及び通知管理情報等が存在する。全ての事業者は、全ての設定情報を登録させることが可能である。そのため、全ての設定情報は、何れかの事業者に紐付け、つまり対応付けられている。その対応付けは、事業者毎に異なる格納領域を確保することで行っても良いが、お客様コード等の事業者を一意に識別可能な情報を追加することで行っても良い。
【0081】
利用依頼設定情報は、契約事業者が本サービスの利用を依頼する非契約事業者を指定可能にする。そのために、利用依頼設定情報は、各契約事業者が必要に応じて設定することが可能になっている。利用依頼設定情報には、例えば設定する契約事業者のお客様コードの他に、本サービスの利用を望む非契約事業者の情報として、事業者名、部署名、及びメールアドレス等が含まれる。非契約事業者の情報は、複数、存在している場合がある。
【0082】
専用サイトへのリンク情報が埋め込まれたメールは、情報が入力された非契約事業者宛てに送信される。そのために、文書処理制御部114は、登録する利用依頼設定情報を参照し、利用依頼設定情報中のメールアドレスを通知制御部119に渡し、専用サイトへのリンク情報を本文に埋め込んだメールを送信させる。それにより、非契約事業者は、受信したメールを通して、専用サイトにアクセスして利用登録を行うことにより、契約をすることなく、本サービスを利用可能になる。
【0083】
図7は、利用依頼設定情報により利用登録を行った非契約事業者の情報を表示するWebページ(画面)の例を示す図である。
契約事業者には、自身が本サービスの利用を依頼した非契約事業者が実際に入力した情報を確認可能にさせている。図7は、その情報確認を要求した契約事業者に送信されるWebページの例を示している。
この要求が端末通信部19によって受信された場合、受信された要求は端末通信部19からCPU11に出力される。CPU11に入力された要求は、振分制御部111を介して文書処理制御部114に渡される。
【0084】
それにより、このWebページは、文書処理制御部114によって生成され、振分制御部111を介して端末通信部19に出力されることにより、契約事業者で使用される事業者端末に送信される。このWebページの生成には、企業登録情報、及び利用依頼設定情報が用いられる。なお、このWebページの送信を要求するための操作等についてのより詳細な説明は省略する。
【0085】
図7において、お客様コード、同意、及び受付日時の各項目の情報は、非契約事業者が入力した情報ではなく、企業登録部112、或いは文書処理制御部114により自動的に入力された情報である。受付日時は、非契約事業者が利用登録を行った日時である。例えば企業登録情報中の作成日時が受付日時として契約事業者に呈示される。同意は、非契約事業者が本サービスを利用するか否かを表す情報であり、図7中に表記の「はい」は、非契約事業者が本サービスを利用することを表している。この同意についての情報入力は、契約を望む事業者には求められない。利用依頼設定情報で利用が依頼された非契約事業者のうちで、利用登録を行っていない、或いは利用登録を行っていても、企業登録情報中の利用状態が本サービスを利用中となっていない非契約事業者は、同意の内容として「いいえ」が配置される。
【0086】
図7のようなWebページを表示させることにより、利用依頼設定情報を登録させた契約事業者は、本サービスを利用可能な非契約事業者だけでなく、本サービスの利用を望まない非契約事業者も確認することができる。それにより、契約事業者は、利用登録をしていない非契約事業者を含む各非契約事業者に対し、文書ファイルDの交換を適切に行うことができる。
【0087】
各種設定情報の説明に戻る。
保管設定情報は、文書ファイルDを個別保管領域SAに保管するうえでの図5に示すような論理的な階層構造、例えばフォルダーの階層構造を指定する。この保管設定情報は、各事業者が夫々入力する情報である、この保管設定情報により、文書ファイルDは、例えば部署別、期間別、或いは/及び文書ファイルDの種類(属性)別等により自動的に振り分けられて個別保管領域SAに保管される。
【0088】
契約事業者は、フォルダー別に、アクセス制限を設定することも可能である。アクセス制限を設定、つまりアクセスを可能にする従業員を制限するフォルダーには、例えばアクセス用ID、及びパスワードを設定することが可能となっている。このようなアクセス制限の設定も、保管設定情報により行うことができる。
【0089】
取込設定情報は、APサーバ1に文書ファイルDの取り込みを自動的に行わせることを可能にする。そのために、取込設定情報では、取込保管領域36、取り込みを行うタイミング、及び取り込んだ文書ファイルDを送付可能にするタイミング等を指定可能になっている。
【0090】
取込保管領域36に保管する文書ファイルDは、その内容の自動認識により送付先を特定するのを前提としている。そのため、取込設定情報では、文書ファイルDの送付先等の指定は想定していない。
【0091】
図5において、請求書DSはこの自動認識が利用可能である。契約書DKは、同じ契約書DKを複数の異なる送付先に送付する可能性が考えられることもあり、自動認識を利用しない想定となっている。それにより、契約書DKでは、個別保管領域SAだけでなく、階層構造で作成されたフォルダーのうちから実際に文書ファイルDを保管すべきフォルダーまで特定可能な情報を指定する必要がある。
【0092】
文書ファイルDの交換における要望は、全ての事業者で一致するとは限らない。このことから、本サービスでは、各事業者に配信管理情報を登録させ、事業者による要望の違いに対応可能にしている。そのために、配信管理情報では、対象となる事業者毎に、その事業者の要望を指定可能になっている。
【0093】
配信管理情報には、例えばお客様コード、会社名、配信種別、配信有効、及びユーザー作成済みの各情報が含まれる。
お客様コード、及び会社名は、企業登録情報から自動入力される情報である。その起業登録情報からの自動入力を可能にさせるために、本サービスでは、企業登録情報が登録された事業者の検索機能を提供している。それにより、事業者には、検索機能によりヒットした事業者のうちから配信管理情報を追加する事業者、つまり本サービスを用いた文書ファイルDの交換を新たに希望する事業者を選択可能にさせている。
【0094】
ユーザー作成済みは、事業者が契約しているか否かを示す情報である。
配信種別、及び配信有効は、文書ファイルDの交換における事業者の要望を表す。この2つの項目は、事業者が入力する対象となる項目である。
配信種別は、交換のための文書ファイルDの配信方法を指定する情報である。その内容としては、例えば「Web」及び「郵送」のうちから選択される。「Web」は、ネットワークNを介した文書ファイルDの交換を表している。「郵送」は、郵送等により印刷物の形で文書ファイルDの交換を表している。各事業者は、この情報の入力を通して、文書ファイルDの配信方法、つまり交換方法を選択することができる。
配信有効は、文書ファイルDの交換に本サービスを利用するか否かを示す情報である。利用登録を行った各事業者は、この情報により、本サービスを利用するか否かを選択することができる。
【0095】
通知管理情報は、文書ファイルDが新たに発生した旨を送付先に通知するためのものである。本サービスでは、その通知はメールを用いて行われる。それにより、通知管理情報では、メールの本文に挿入するメッセージの雛形、及びそのメールを送信するタイミング等を指定可能になっている。
【0096】
通知に用いるメッセージは、文書ファイルDの種類によって異ならせるのが望ましい。また、メールを送信すべきタイミングは、文書ファイルDの取り込み方によって異ならせるのが望ましい。メールは、自動的に取り込む場合、文書ファイルDを確認可能にするタイミングを考慮して送信させるのが望ましく、そうでない場合、文書ファイルDの緊急度に応じて送信させるのが望ましいと云える。このようなことから、本サービスでは、文書ファイルDの種類、及び取込方法別に、メッセージの雛形、及びメールを送信するタイミングを指定可能にしている。
【0097】
このメールにより、各事業者は、ログインすることなく、新たに発生した自身宛の文書ファイルDの存在を知ることができる。そのため、各事業者は、新たに発生した自身宛の文書ファイルDをより迅速、且つより容易に認識することができる。企業登録情報にメールアドレスを含め、非契約事業者にメールアドレスを登録させることには、本サービスを利用する事業者の全てに対し、このようなメールを受信可能にするという意図もある。
本サービスでは、納品書の文書ファイルDは、メールによる通知の対象外とさせている。これは、納品書は、商品Pの配送によって参照される文書だからである。つまり、各事業者にとっては、商品Pの納品により、納品書の文書ファイルDの確認、及び閲覧を行えば良いからである。
【0098】
文書処理制御部114は、上記のような各種設定情報の入力に対応するための処理を行う。事業者が登録を指示した何れの設定情報も、文書処理制御部114から設定管理部117に渡され、設定管理部117により、設定情報格納部186に格納される。設定情報格納部186に格納されている設定情報は、文書処理制御部114の指示により、設定管理部117により読み出され、文書処理制御部114に渡される。それにより、事業者は、設定情報格納部186への設定情報の追加だけでなく、設定情報格納部186に格納されている設定情報を変更(更新)させることもできる。更新可能な設定情報は、例えば通知管理情報、取込設定情報、保管設定情報、及び配信管理情報である。
【0099】
文書処理制御部114は、取込設定情報に沿って、文書ファイルDの自動的な取り込みを行う。また、事業者端末からの要求により、事業者端末からアップロードされる文書ファイルDの取り込みを行う。文書処理制御部114は、そのような取り込み方法に応じて、処理、及び制御の内容を変更する。
【0100】
保管条件としては、例えばダウンロードを可能にする期間、及びダウンロードが可能な回数等を指定することができる。それにより、送付元は、保管条件の指定を通して、文書ファイルDの望ましくない送付が行われるのを回避させることが可能となる。
【0101】
事業者は、事業者端末から文書ファイルDをアップロードさせる場合、その文書ファイルDの送付先(宛先)、及び保管条件等を指定可能な個別設定情報をともにアップロードさせることができる。そのため、文書処理制御部114は、事業者端末から文書ファイルDがアップロードされたる文書ファイルDを取り込む場合、文書処理制御部114は、個別設定情報の有無を確認し、個別設定情報があれば、その内容を更に確認する。それにより、文書処理制御部114は、個別設定情報が無いか、例え個別設定情報があっても、文書ファイルDの保管先の決定に必要な情報が不足している場合、その文書ファイルDを自動分割部116に渡し、文字列の自動認識を行わせる。
【0102】
上記のように、受領書(修正文書ファイルSD)の生成には、納品書に設けられた押印領域への受領印の押印が必要である。その押印領域を確認する必要から、納品書の文書ファイルDは、その保管先の決定に十分な情報が個別設定情報に存在していたとしても、文書処理制御部114から自動分割部116に渡される。保管先の決定に十分な情報が個別設定情報に存在していた場合、納品書の文書ファイルDであることは、個別設定情報から判定することができる。
【0103】
実際の保管先の決定は、データ管理部115によって行われる。このことから、データ管理部115には、文書処理制御部114から個別設定情報が渡され、自動分割部116から文字列の自動認識結果が渡される。保管の対象となる文書ファイルDは、文書処理制御部114、或いは自動分割部116から渡される。文書ファイルDの送付先は、個別設定情報、或いは自動認識結果から特定される。このことから、データ管理部115は、送付先の保管設定情報を参照して、文書ファイルDの保管先を決定する。
【0104】
データ管理部115は、保管先を決定した後、文書ファイルDをアクセス制御部118に渡し、決定した保管先への文書ファイルDの保管をDBサーバ2に要求させる。それにより、アクセス制御部118は、DB通信部20を介して、文書ファイルDとともに、決定した保管先に文書ファイルDを保管させるための要求をDBサーバ2に送信する。
【0105】
DBサーバ2は、文書ファイルDの保管用のストレージである記憶部200を備えている。その記憶部200には、事業者別に、文書ファイルDの格納場所となる企業別格納部201が確保されている。DBサーバ2は、受信した要求から特定される企業別格納部201に、受信した文書ファイルDを格納する。各企業別格納部201には、図5に示すように、階層構造で複数のフォルダーが作成されている。そのため、文書ファイルDが保管されるのは、複数のフォルダーのうちの1フォルダーである。
【0106】
アクセス制御部118は、データ管理部115の他に、文書処理制御部114の指示により、DB通信部20を介したDBサーバ2へのアクセスを行う。その指示によりDBサーバ2から送信された文書ファイルDは、その指示を行ったデータ管理部115、或いは文書処理制御部114に渡される。
【0107】
データ管理部115は、文書ファイルDをDBサーバ2に保管させるとともに、その文書ファイルDの管理用のパッケージ情報を生成し、生成したパッケージ情報を記憶部18に確保されたパッケージ情報格納部183に格納する。文書ファイルDの保管時に生成するパッケージ情報は、実体情報、及び保管情報である。文書ファイルDの送信時には、更に配布情報がパッケージ情報として生成され、パッケージ情報格納部183に格納される。以降、パッケージ情報は、それらの情報の総称として用いる。
【0108】
図8は、文書ファイルの保管に係わる情報、及びその関係の例を説明する図である。
図8において、実体ファイルJFは、実際に保管されるファイルであり、文書ファイルDは、実体ファイルJFの一例である。実体ファイルJFには、事業者が送信したメッセージを保存したファイルも含まれる。
【0109】
パッケージ情報は、実際には実体ファイルJFを保管する前に生成される。実体情報JIは、実体ファイルJFの直接的な管理のための情報である。この実体情報JIには、例えば実体ファイルID、管理状態、保存場所、ファイル名、ファイルタイプ、ファイルサイズ、保存日時、及び更新日時等の情報が含まれる。
【0110】
実体ファイルIDは、実体ファイルJFを一意に識別可能な識別情報である。管理状態は、実体ファイルJFが存在するか否か、その実体ファイルJFの送付が有効か否か等を表す情報である。保存場所は、実体ファイルJFが実際に保管されている保存場所を表す情報である。これらは全て、データ管理部115によって生成される。
【0111】
個別設定情報KS、或いは保管設定情報HSは、保存場所の特定のために参照される。参照されるのは、個別設定情報KSは実体ファイルJFの送付元の事業者のものであり、保管設定情報HSは、送付先の事業者のものである。自動認識により送付先を特定する場合、保管設定情報HSが参照され、送付先の特定に自動認識が用いられない場合、個別設定情報KSも併せて参照される。それにより、実体ファイルJFを保管すべき個別保管領域SA、その個別保管領域SA内の例えばフォルダーが決定される。
【0112】
ファイル名、ファイルタイプ、及びファイルサイズは全て、実体ファイルJFから取得される情報である。保存日時、及び更新日時はともに、データ管理部115によって追加される情報である。
【0113】
保管情報AIは、実体ファイルJFの保管、及び交換を管理するための情報である。この保管情報AIには、例えば保管情報ID、実体ファイルID、送付元企業コード、送付先企業コード、登録日時、登録ユーザーID、保管期間、保管期限日時、公開予定日時、公開期限日時、及び取得上限回数等の情報が含まれる。
【0114】
保管情報IDは、保管情報AIを一意に識別可能な識別情報である。実体ファイルIDは紐付けられた、つまり対応付けられた実体情報JIに格納されている実体ファイルIDである。送付元企業コードは、実体ファイルJFの送付元である事業者のお客様コードである。送付先企業コードは、実体ファイルJFをダウンロード可能にする事業者のお客様コードである。登録日時は、保管情報AIを生成した日時である。登録ユーザーIDは、実体ファイルJFを実際に取り込んだ事業者のお客様コードである。通常、登録ユーザーIDは、送付元企業コードと一致する。保管期間は、保管情報AIを保管すべき期間である。保管期限日時は、保管情報AIの廃棄が可能となる日時である。公開予定日時は、実体ファイルJFのダウンロードを可能にする予定の日時である。公開期限日時は、実体ファイルJFのダウンロードを不可にする日時である。取得上限回数は、実体ファイルJFのダウンロードが可能な回数である。
【0115】
送付元企業コード、及び登録ユーザーIDは、実体ファイルJFの取り込み時、自動的に特定される。送付先企業コードは、実体ファイルJFが事業者端末から取り込んだ場合、個別設定情報KSから特定される情報である。保管期間、保管期限日時、公開予定日時、公開期限日時等、及び取得上限回数も、個別設定情報KSにより指定可能である。
【0116】
送付元企業コード、登録ユーザーID、及び送付先企業コードは、企業マスターKM、或いは企業登録情報KTを参照して特定される。図8では、企業登録情報KTを1つのみ示しているが、実際に参照されるのは2つ以上の企業登録情報KTの場合もある。
【0117】
自動的に実体ファイルJFを取り込んだ場合、送付先企業コードは自動認識により特定可能な情報となる。保管期間、保管期限日時、公開予定日時、公開期限日時等、及び取得上限回数は、保管設定情報HSにより指定可能な情報である。そのため、それらは全て、保管設定情報HSを参照して決定される。
【0118】
保管情報AIには、上記のような情報が含まれる。それにより、紐付けられた実体情報JIが特定可能であり、その実体情報JIの参照により、紐付けられた実体ファイルJFも特定可能となっている。送付元の事業者のお客様モードが送付元企業コードとして含めることにより、送付元の事業者には、自身が送付の実体ファイルJFが実際に適切に取り込まれているか否かの確認を可能にさせている。その確認は、送付先の事業者が保管設定情報で指定の論理構造に沿って行うことも可能である。
【0119】
配布情報DIは、実体ファイルJFのダウンロードによって生成されるか、或いはそのダウンロードに備えて作成される情報であり、ダウンロードによる実体ファイルJFの配布の管理に用いられる。この配布情報DIには、例えば配布情報ID、保管情報ID、受信状態、送付元企業コード、送付先企業コード、配布日時、取得回数、登録日時、及び更新日時等の情報が含まれる。
【0120】
これらの情報において、配布情報IDは、配布情報DIを一意に識別可能な識別情報である。保管情報IDは、この配布情報DIに紐付けられた保管情報AIに格納されている保管情報IDである。配布情報DIに対応付けられた保管情報AIは、この保管情報IDによって特定可能となっている。
【0121】
受信状態は、送付先による実体ファイルJFの受信状態を表す情報であり、ダウンロードが行われたか否かは受信状態により確認することができる。配布日時は、実体ファイルJFが最後にダウンロードされた日時である。取得回数は、実体ファイルJFが実際にダウンロードされた回数である。登録日時は、配布情報DIが登録された日時である。更新日時は、配布情報DIが更新された日時である。配布情報DIでは、実体ファイルJFのダウンロードにより配布日時が更新されることから、通常、更新日時は配布日時と一致する。
【0122】
上記のように、本サービスでは、送付元が実体ファイルJFのダウンロード回数の上限を設定可能にしている。このようなダウンロードの制限は、配布情報DIを用いて実現される。ダウンロード回数の上限自体は、取込設定情報、及び個別設定情報KSの両方で指定可能である。
【0123】
操作記録情報KIは、各実体ファイルJFへのダウンロードを含む各種操作を確認可能にするために用意された情報である。この操作記録情報KIには、例えば記録ID、及び作成日時の他に、実体ファイルJFに対して行われた操作の内容を表す操作内容情報が、実体ファイルJFに対して行われた操作毎に格納される。操作内容情報としては、例えば操作日時、操作種別、及び保存情報ID等の情報が含まれる。
【0124】
操作日時は、実体ファイルJFへの管理上の操作が行われた日時である。保存情報IDは、操作が行われた実体ファイルJFを一意に識別可能にする。操作種別は、行われた操作の種類を表す情報である。操作の種類には、実体ファイルJFのダウンロードの他に、実体ファイルJFの保管等も含まれる。
【0125】
本サービスでは、実体ファイルJFの保管により、実体情報JI、保管情報AI、及び配布情報DIをパッケージ情報として生成して保管し、操作記録情報KIを更新する。配布情報DI、及び操作記録情報KIは、保管した実体ファイルJFへの操作により、必要に応じて更新する。それにより、実体ファイルJFを送付する側の要望に沿った形でダウンロードできるようにしている。
【0126】
パッケージ情報、及び操作記録情報KIの生成、及び更新も、データ管理部115によって行われる。記憶部18には、パッケージ情報の保管用のパッケージ情報格納部183の他に、操作記録情報KIの保管用の操作記録情報格納部184が確保されている。それにより、データ管理部115は、記憶部18にアクセスして、生成、若しくは更新したパッケージ情報、若しくは操作記録情報を保管する。
【0127】
データ管理部115は、事業者別、及び属性別に、ダウンロード可能な文書ファイルDを表すオブジェクトリストを生成し、記憶部18のオブジェクトリスト格納部185に保管する。そのオブジェクトリストは、例えばダウンロード可能な文書ファイルD毎に、保管情報AI中の保管情報ID、実体ファイルID、送信者企業コード、受信者企業コード、公開期限日時、及び取得上限回数等の情報がまとめられたファイルである。ダウンロード可能な文書ファイルDの保管、或いはダウンロードを不可能にした文書ファイルDの発生により、データ管理部115は、対応するオブジェクトリストを更新する。ここでの属性には、文書の種類の他に、例えば閲覧制限、緊急度、文書ファイルDの送付元のお客様コード、及び文字列の自動認識結果から特定された文書の種類以外の内容等のうちの1つ以上が含まれる。
【0128】
文書の1種類である発注書DHでは、属性に発注番号を含めるのが望ましい。これは、発注番号は発注書DHを一意に識別可能な識別情報だからである。
納品書、及び受領書にも、発注番号とは異なる識別情報が割り当てられるのが普通である。しかし、納品書、及び受領書には、発注書DHとの対応関係を特定できるように、対応関係にある発注書DHに割り当てられた発注番号が文字列、或いは図形パターン等の形で存在するのが普通である。このことから、属性としては、発注番号を含む複数の識別情報を属性に含めるのが望ましい。ここでは、発注書DH、納品書、及び受領書の全て、属性には発注番号が含まれるものと想定する。
【0129】
記憶部18に確保された修正設定情報は、図1に示すような文書ファイルDをベースに、その文書ファイルDへの修正、及び修正後の文書ファイルDの扱い等について指定するための設定情報である。各事業者は、必要に応じて、必要な数の修正設定情報を登録させることができる。文書処理制御部114は、修正設定情報の登録、削除、及び更新を可能にさせる。ここでは、混乱を避けるため、ベースとされる文書ファイルDの文書として、以降、納品書のみ想定する。
【0130】
登録すべき修正設定情報は、例えばそのための要求とともに、事業者端末からAPサーバ1に送信される。その場合、文書処理制御部114は、受信された修正設定情報を設定管理部117に渡し、その保管を指示する。この結果、設定管理部117は、渡された修正設定情報を修正設定情報格納部187に格納させる。格納される修正設定情報には、例えばその登録を要求した事業者のお客様コード、及び修正設定情報を一意に識別可能にする識別情報等が管理情報として付加される。この管理情報により、文書処理制御部114は、修正設定情報を登録させた事業者のみ、その修正設定情報の閲覧、削除、及び更新を可能とさせる。
【0131】
本サービスでは、修正設定情報を登録させる事業者として、納品書の文書ファイルDの送信元となる事業者を想定している。この想定には、事業者から納品書の文書ファイルDが送付される各事業者は、その文書ファイルDをベースに、ベースとなる文書ファイルD中の文字列の修正を行える事業者と位置付けていることも含まれる。
同じ事業者であっても、送付先によって納品書の形式等を異ならせる場合がある。つまり、納品書の種類が複数、存在する場合がある。また、納品書の文書ファイルDの送付先となる事業者のうちの一つ以上の事業者に、文字列の修正を可能とさせないようにする場合も考えられる。このようなことから、修正設定情報は、納品書の種類別に登録可能にさせることが望ましい。
【0132】
納品書の文書ファイルDは、上記のように、押印領域を特定する必要から、自動分割部116による辞書を用いた自動認識の対象となる。そのため、納品書の文書ファイルDの自動認識に実際に用いられた辞書も特定される。このことから、納品書の種類が複数、存在する場合、辞書と修正設定情報とを対応付けすることにより、納品書の形式等に応じて、適用する修正設定情報を変更させることができる。
一つ以上の事業者に、文字列の修正を選択的に不可能とさせるのは、例えば管理情報に、文字列の修正を可能とさせる、或いはその修正を不可能とさせる事業者のお客様コードを含めることにより、実現させることができる。
【0133】
ここでは、混乱を避け、理解を容易とさせるために、各事業者が作成する納品書は1種類、納品書が送付される各事業者は全て、文字列の修正が可能と想定する。
修正設定情報は、対応する納品書の文書ファイルDの送信時、参照される情報である。修正設定情報は、文書ファイルDの送信形態、文書ファイルDへの操作内容、文書ファイルDで修正可能な範囲、及び修正後の文書ファイルDの扱い等を指定する。それにより、修正設定情報は、図1に示すように、文書ファイルDをベースにしての修正文書ファイルSDの生成を可能にさせる。修正設定情報の内容についての具体例は後述する。
【0134】
文書処理制御部114は、必要な情報をデータ管理部115に渡し、パッケージ情報の生成、或いは更新を指示する。また、データ管理部115を通して、必要なパッケージ情報、保管設定情報HS、或いは修正設定情報を取得し、取得した情報を用いた制御を行う。それにより、文書処理制御部114は、実体ファイルJFの取り込み、取り込んだ実体ファイルJFの管理、ダウンロードを含む実体ファイルJFへの送付元の要望に沿った操作、等を行う。送付元の要望に沿った操作には、納品書の文書ファイルDによって表される画像を配置させたWebページの作成・送信、そのWebページを送信させた事業者端末からアップロードされる修正情報を反映させた修正文書ファイルSDの保管も含まれる。納品書の文書ファイルDによって表される画像は、受領書の画像としてWebページ上に配置される。
【0135】
パッケージ情報は、実体ファイルJFと組み合わされ、実体ファイルJFを管理するうえで必須の情報となっている。そのため、パッケージ情報の格納用のパッケージ情報格納部183は、各個別保管領域SAで共有させた保管領域となっている。つまり各個別保管領域SAは、パッケージ情報格納部183と、記憶部200に確保された各企業別格納部201とにより実現されるものとなっている。各個別保管領域SAは、論理的に分割された1つ以上の領域ではなく、物理的に分割された1つ以上の領域、或いはストレージであっても良い。
【0136】
データ管理部115は、個別設定情報KSで指定されるか、或いは文字列の自動認識結果から特定される送付先の保管設定情報HSを参照して、文書ファイルDの保管先を決定する。それにより、データ管理部115は、決定した保管先への文書ファイルDの保管を、アクセス制御部118によりDBサーバ2に行わせる。その一方、データ管理部115は、更に企業マスターKM、及び企業登録情報KTを参照し、実体情報JI、及び保管情報AIを少なくとも生成し、操作記録情報KIを更新する。
【0137】
次に、図9図12を参照し、納品書の内容の修正方法について具体的に説明する。
図9は、納品書の文書ファイルによって表される画像が配置されたWebページの例を示す図である。
このWebページは、3つの表示エリアHR1~HR3に大別することができる。
表示エリアHR1は、処理した、或いは処理すべき納品書を表す情報がリスト表示されるエリアである。ユーザーは、リスト表示された納品書のうちから、望む納品書を選択することができる。その選択は、例えば望む納品書の情報が配置された行へのクリック操作により行うことができる。
なお、リスト表示される納品書の情報には、納品日、配送業者名、受注側企業名、発注側企業名、お客様コード(企業コード)、配送日、及び伝票日時等がある。図9中、リストの左端に配置されているのは、スライドタイプのオン/オフボタンである。このボタンは、処理済みか否かをユーザーが切り換えるために用いられる。
【0138】
表示エリアHR2には、文書ファイルDから生成された受領書の画像が配置される。その画像は、内容的には納品書と同じである。そのため、ユーザーは実質的に、納品書を参照し、届いた商品の検収を行うことができる。
その画像中には、配送関係情報を表す複数の文字列、配送商品情報を表す複数の文字列、及び押印箇所(押印領域)JRが存在する。配送商品情報を表す複数の文字列は、表形式で行別に配置されている。それにより、図9は、複数の配送商品情報が納品書に存在することを示している。
【0139】
納品書には、発注番号、及び伝票番号が識別情報として存在する。発注番号は、対応する発注書DHに割り当てられた識別情報であり、伝票番号は、納品書に対して受注側企業が割り当てた識別番号である。これら識別情報は、図9に示すように、受領書の画像中にも文字列として存在している。
配送商品情報を表す複数の文字列には、商品コード、商品名、数量、及び単位を表す文字列が含まれる。文書のタイトルとして、文字列「納品書兼受領証」が画像中に配置されている。各種指示用に3つのボタンB1~B3が画像外に配置されている。
【0140】
文字列「納品書兼受領証」は、修正設定情報が指定する操作を行った結果、配置された文字列である。元は、例えば文字列「納品書」である。文書処理制御部114は、修正設定情報を参照することにより、文字列「納品書」を文字列「納品書兼受領証」に更新し、更新後の文字列「納品書兼受領証」を配置させたWebページを生成し送信する。図9に示す例では、文字列「納品書」が第1の文字列、文字列「納品書兼受領証」が第2の文字列にそれぞれ相当する。
修正設定情報は、画像中に存在する文字列のうちで修正可能な文字列を指定する。文字列「納品書」から文字列「納品書兼受領証」への自動的な修正も、修正設定情報の指定により行われる。修正設定情報には、これら修正に係わる各種情報が含まれる。「修正」ボタンB1は、文字列の修正が可能な状態にするためのボタンである。
文字列「納品書」から文字列「納品書兼受領証」へのタイトルの自動的な修正により、ユーザーにとっては、修正すべき文字列が減ることになる。また、タイトルにより、自身が修正を行っている文書の種類を適切に認識することができる。なお、自動修正の対象となる文字列は、タイトルに限定されない。また、文字列の数は2以上であっても良い。
【0141】
図10は、文字列の修正が可能な状態のWebページの例を示す図である。
ユーザーが「修正」ボタンB1をクリック操作することにより、修正可能な文字列は、図10に示すように、表示形態が変更される。修正可能な文字列毎に、その文字列がデータとして配置される表示フィールドDFが他と区別可能な表示形態で強調表示される。そのようにして、本サービスでは、修正可能な文字列、及びそれが配置された表示フィールドDFを視覚的にユーザーに確認可能にさせ、修正の対象となる文字列の特定をより容易に行えるようにさせている。
【0142】
図10では、破線の矩形で修正可能な文字列が存在する表示フィールドDFを表している。この表示フィールドDFは、文字列が入力可能な入力フィールドであり、その入力フィールド内に存在する文字列が修正可能である。また、文字列が存在しない表示フィールドDFでは、文字列の入力が可能である。それにより、ユーザーは、表示フィールドDFを入力フィールドとして選択し、修正を望む文字列の修正、或いは文字列の追加を行う。入力フィールドとしての表示フィールドDFの選択は、クリック操作等により行うことができる。以降、混乱を避けるために、表示フィールドDFは「入力フィールドDF」と表記する。
【0143】
文字列の修正が可能な状態では、「修正」ボタンB1の代わりに「キャンセル」ボタンB6が配置される。この「キャンセル」ボタンB6は、文字列の修正を行えない状態に戻すのを指示するためのボタンである。「キャンセル」ボタンB6へのクリック操作により、それ以前に行われた文字列の修正、及び受領印の押印は無効とされ、Webページは、図9に示すような状態に戻る。
「登録」ボタンB2は、例えば画像上の内容のアップロードを指示するためのボタンである。画像上の内容、つまり各種文字列、及び押印箇所JRに押印された受領印等は、修正情報として、事業者端末からAPサーバ1にアップロードされる。
「印」ボタンB3は、押印箇所JRへの受領印の押印、或いは押印された受領印の削除を指示するためのボタンである。
この「印」ボタンB3へのクリック操作により、押印箇所JRに受領印が押印(表示)される。押印された受領印は、「印」ボタンB3をクリック操作することにより、削除される。受領印が押印されていない場合、「登録」ボタンB2へのクリック操作は無効とされる。そのため、修正情報として、元の内容との差分を表す情報を採用したとしても、修正情報には受領印の画像が含まれる。それにより、修正文書ファイルSDとして保管される受領書は、受領印が押印されたものとなる。
【0144】
受領印を表示させる場合、事業者端末は、例えば受領印の画像をAPサーバ1に対して要求し、その画像をAPサーバ1から取得する。そのため、受領印の押印を行う可能性のある事業者には、受領印として用いる電子印鑑を登録させるようにしている。電子印鑑の登録等についての詳細な説明は省略する。
【0145】
表示エリアHR3には、納品書の文書ファイルDに対応する発注書DHの画像の表示用である。表示エリアHR3の上方に配置された「表示」ボタンB4は、発注書DHの画像の表示を指示するためのボタンである。「消去」ボタンB5は、表示された画像の消去を指示するためのボタンである。
発注書DHの文書ファイルDは、本実施形態における第3の文書ファイルに相当する。契約書DKの内容に沿って、納品書が作成されるような場合、第3の文書ファイルは、契約書DKの文書ファイルDであっても良い。このようなこともあり、第3の文書ファイルの選択肢は複数、存在する場合もある。
【0146】
配送すべき商品Pは、発注側企業4から注文された商品である。本サービスを利用し、発注書DHの文書ファイルDが交換されていた場合、その文書ファイルDは、受注側企業3の個別保管領域SAに保管されている。納品書には、発注書DHとの対応関係を特定可能とするために、発注書DHを一意に識別可能な識別情報、例えば発注番号が文字列として含まれているのが普通である。このことは、納品書の文書ファイルD用に登録される辞書への条件に、発注番号を表す文字列が存在する文字列領域MRの指定を含めることにより、納品書に対応する発注書DHの文書ファイルが特定できることを意味する。
その発注書DH自体は、納品書の文書ファイルDの送付先である発注側企業4で作成された文書である。そのため、発注書DHの内容を発注側企業4に提示することで問題が発生するとは考え難い。このようなことから、本サービスでは、発注書DHの画像を表示エリアHR3に表示させるのを可能とさせている。
【0147】
納品書の文書ファイルD中の発注番号は特定済みであり、その文書ファイルDの送信元の事業者のお客様コードも特定済みである。このことから、事業者端末から発注書DHの画像の表示が要求された場合、文書処理制御部114は、例えば送付元の事業者のお客様コード、発注番号、及び文書の種類の各情報をデータ管理部115に渡し、文書ファイルDの抽出を指示する。この結果、データ管理部115は、例えばオブジェクトリストを参照し、文書処理制御部114が指定のお客様コード、発注番号、及び文書の種類を属性として有する文書ファイルDを特定する。このようにして特定された文書ファイルDの文書が、納品書に対応する発注書DHである。なお、お客様コードを指定するのは、発注番号は各事業所がそれぞれ個別に割り当てることから、複数の事業者が同じ発注番号を用いる可能性があり得るからである。
【0148】
その後、データ管理部115は、アクセス制御部118を介して、それらの情報で特定される発注書DHの文書ファイルDをDBサーバ2から取得し、取得した文書ファイルDを文書処理制御部114に渡す。
それにより、文書処理制御部114は、送信すべき発注書DHの画像を事業者端末に送信することができる。一方の事業者端末は、そのようにして送信された画像を表示エリアHR3に表示させる。
【0149】
なお、発注書DHの文書ファイルDの特定は、オブジェクトリストを参照しなくとも行うことができる。
例えば個別保管領域SA内に作成されているフォルダーのうちで、対象となる文書ファイルDが保管されているフォルダーは、文書の種類、及び発注番号から特定することができる。特定したフォルダーからの対象となる文書ファイルDの抽出は、例えば文字列の自動認識を利用し、指定されたお客様コード、及び発注番号がともに文字列として存在する文書ファイルDを特定することで行うことができる。
このようなこともあり、発注書DHの文書ファイルDのような対象となる文書ファイルDを特定する方法は特に限定されない。つまり様々な変形が可能である。
【0150】
表示エリアHR3には、上記のようにして特定し抽出される文書ファイルDによって表現される発注書DHの画像が配置される。内容的には、発注書DHの内容は納品書の内容と同じか、或いは納品書の内容は発注書DHの内容の一部である。これは、発注書DHで指定された商品を複数回に分けて配送するようなケースもあり得るからである。
しかし、商品Pの配送は、発注書DHによる発注によって行われるものである。そのため、納品書に対応する発注書DHの画像を表示エリアHR3に表示させた場合、ユーザーは、突き合わせて、納品書の内容が適切か否かをより容易に確認することができる。それにより、文字列のうちで発注書DHとは不適切な内容の文字列の特定も容易となる。このことから、ユーザーは、そのような確認を通して、数を含め、納品されるべき商品が実際に納品されたか否かの確認も容易に行うことができる。従って、ユーザーにとってのより高い利便性が実現される。
【0151】
図11は、入力フィールドの選択後の表示例を示す図である。
ユーザーが何れかの入力フィールドDFを選択した場合、図11に示すように、その入力フィールドDFに存在する文字列が配置されたポップアップPUが表示される。そのポップアップPU上には、ユーザーが選択した入力フィールドDFに存在する文字列の他に、修正後の文字列を入力するための入力フィールドNF、「OK」ボタンB11、及び「キャンセル」ボタンB12が配置されている。
【0152】
このことから、ユーザーは、入力フィールドNF上に修正後の文字列を入力させた後、「OK」ボタンB11へのクリック操作により、選択した入力フィールドDF内の文字列を修正することができる。「キャンセル」ボタンB12は、文字列の修正のキャンセルを指示するためのボタンである。そのため、ユーザーが「キャンセル」ボタンB12をクリック操作した場合、ユーザーが選択した入力フィールドDF内の文字列は修正されず、元の文字列のままとなる。
【0153】
図12は、1文字列の修正後のWebページの例を示す図である。
図12では、文字列が修正された入力フィールドDFを一点鎖線の矩形で表している。これは、文字列が修正されていない入力フィールドDFとは異なる表示形態で更に強調表示させているからである。本サービスでは、文字列が修正された入力フィールドDFの表示形態を更に異ならせて強調表示させることにより、修正した文字列を視覚的に特定可能にして、その修正内容の確認を容易に行えるようにさせている。その再確認を容易とすることにより、修正ミスの発生はより抑えられると期待できる。
【0154】
文書処理制御部114は、例えば図9図12に示すような各Webページの表示を実現させる。つまり事業所端末から送信される要求を処理し、発注書DHの画像の送信、入力フィールドDFの表示形態の変更、並びにポップアップPUの作成、及び送信等を行う。この結果、ユーザーは、事実上の発注書DHと納品書の突き合わせが可能になるとともに、検収により不適切であることが確認された受領書中の文字列を修正することができる。
【0155】
Webページを受信した事業者端末は、例えばキーボードである入力装置への操作により、画像上の文字列の修正を可能にさせ、その修正結果を修正情報としてAPサーバ1に送信する。このことから、事業者端末上には、本実施形態の修正手段、及び修正情報送信手段が実現されている。これらの手段は何れも、事業者端末に搭載されたCPUが、OS上で動作するブラウザを実行することで実現される。
【0156】
なお、図9図12に示すような各Webページの表示は1例であり、表示させるWebページ、及びWebページの遷移のさせ方等は特に限定されない。例えば文字列の修正では、ポップアップPUを表示させることなく、文字列の修正を行えるようにしても良い。このことから、文字列の修正のための処理は、事業者端末に行わせるようにしても良い。しかし、受領印の押印が行われたか否かを確認できるように、言い換えれば修正文書ファイルSDの生成を行っても良いか否かを確認できるように、事業者端末は、修正情報、或いはそれに類似する情報をAPサーバ1に送信させるようにする必要がある。
本実施形態では、納品書の文書ファイルDから受領書の修正文書ファイルSDを生成するようになっているが、文書ファイルDの文書は納品書に限定されないだけでなく、修正文書ファイルSDの文書も受領書に限定されない。
【0157】
図13は、別の形式の納品書の画像例を示す図である。図14は、別の形式の納品書をベースに生成される他の文書の画像例を示す図である。
図13に画像例を示す納品書では、商品別に、数量、単価、金額、及び明細番号を含む配送商品情報が表されている。
数量は、納品する商品の数である。単価は、1商品の代金、金額は数量分の商品の代金、明細番号は商品に割り当てた番号である。
商品毎に金額を示すことで、納品書には、納品する商品全体の代金が合計として表されている。
【0158】
合計は、事業者(発注側企業4)に対して支払いを求める請求額に相当する。このことから、このような納品書の形式は、請求書DSでも採用することができる。これは、その納品書をベースにした請求書DSが生成可能であることを意味する。それにより、図14に示すように、納品書をベースにした請求書DSを生成させるようにしても良い。その請求書DSでは、タイトルを表す文字列は、文字列「納品書」から文字列「納品書兼請求書」に修正され、請求書DSであることをタイトルから確認できるようになっている。
このようなこともあり、関連性が存在し、且つ文字列の大部分が共通した2つの文書としては、納品書、受領書の組み合わせに限定されない。例えば2つの文書の組み合わせは、納品書、受領書のうちの少なくとも一方が別の種類の文書である組み合わせであっても良い。
【0159】
受領書が修正文書ファイルSDとして送信される受注側企業でも、発注側企業での発注書DHの文書ファイルDの特定と同様に、発注番号から、受領書に対応する発注書DHを特定が可能である。このことから、本サービスでは、受注側企業からの要求により、受領書、及び発注書DHの2つの画像を配置させたWebページの送信を行うようにしている。それにより、受注側企業での発注書、及び受領書を突き合わせてのその受領書の内容の確認をより容易に行うのを可能にさせている。そのWebページの送信を受注側企業からの要求により行うようにしているのは、納品書と比較し、受領書の内容を直ちに閲覧できるようにする要望は低いと考えられるからである。
【0160】
本実施形態では、事業者別に、個別保管領域SAを用意することにより、個別保管領域SAを、文書ファイルD、及び集約文書ファイルDを含む文書ファイルDの保管先を個別保管領域SA中から選択するようにしている。個別保管領域SAでは、保管設定情報HSに沿って、文書ファイルDの保管場所を必要に応じて作成できるようにさせている。しかし、保管先は、このような個別保管領域SAでなくとも良い。保管先は、例えば事業者が予め用意したストレージ中の複数の保管場所のうちから選択させる形で決定させるようにしても良い。このこともあり、保管先は特に限定されない。
【0161】
本実施形態では、事業者端末からの要求により、発注書DHの文書ファイルDを特定し、その画像を送信させるようにしている。しかし、画像の送信は、事業者端末からの要求ではなく、自動的に行うようにしても良い。例えば受領書の画像、及び発注書DHの画像をともに配置させたWebページを作成して送信するようにしても良い。受領書の画像のみを配置させたWebページを送信させた後、発注書DHの画像の送信が可能になり次第、発注書DHの画像を送信させるようにしても良い。このようなことから、発注書DHの画像を送信するタイミング、及び発注書DHの文書ファイルDを特定するタイミングはともに、特に限定されるものではない。
【0162】
受領書の内容を発注側企業(着荷主)側に修正できるようにした場合、発注側企業が不適切な内容に修正する場合が考えられる。このことから、発注側企業が受領書を登録する前に、発注側企業が登録させようとする受領書の内容を受注側企業(発荷主)側、或いは関係者が確認できるようにさせても良い。例えば発注側企業に対し、受注側企業における商品の納品に係わる担当者の連絡先(例えば電話番号)を表示するか、或いは表示可能にして、担当者への連絡をより容易に行えるようにしても良い。或いは、商品Pを配送した配送業者に、発注側企業による検収結果を確認させ、配送業者の受領書への押印を行わせるようにしても良い。その押印を可能にするために、Webページを配送業者に受信可能にさせ、そのWebページを配送業者が受信させた端末上で、発注側企業による文字列の修正、及び受領印の押印を行えるようにさせても良い。
何れを採用するとしても、受領書の内容が不適切なものになる確率は低減するものと期待できる。
【符号の説明】
【0163】
1 APサーバ、2 DBサーバ、3、3-1~L 受注側企業、4-1~K 発注側企業、11 CPU、18、200 記憶部、111 振分制御部、112 企業登録部、113 認証部、114 文書処理制御部、115 データ管理部、116 自動分割部、117 設定管理部、118 アクセス制御部、119 通知制御部、120 辞書登録部、181 企業登録情報格納部、182 企業マスター格納部、183 パッケージ情報格納部、184 操作記録情報格納部、185 オブジェクトリスト格納部、186 設定情報格納部、187 修正設定情報格納部、188 辞書格納部、201 企業別格納部、CA A社、CB B社、CC C社、D 文書ファイル、SA 個別保管領域、SD 修正文書ファイル、ST ストレージ、WA サービス提供会社
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14