特開 2024-168265 情報処理システム、情報処理システムの制御方法、プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024168265

(43)【公開日】2024-12-05

(54)【発明の名称】情報処理システム、情報処理システムの制御方法、プログラム

(51)【国際特許分類】

   G06Q 30/04 20120101AFI20241128BHJP

【ＦＩ】

G06Q30/04

【審査請求】未請求

【請求項の数】15

【出願形態】ＯＬ

(21)【出願番号】P 2023084780

(22)【出願日】2023-05-23

(71)【出願人】

【識別番号】390002761

【氏名又は名称】キヤノンマーケティングジャパン株式会社

(74)【代理人】

【識別番号】100189751

【弁理士】

【氏名又は名称】木村 友輔

(74)【代理人】

【識別番号】100227857

【弁理士】

【氏名又は名称】中山 圭

(72)【発明者】

【氏名】山田 幹規

(72)【発明者】

【氏名】宇田 祐一郎

【テーマコード（参考）】

5L030

5L049

【Ｆターム（参考）】

5L030BB11

5L049BB11

(57)【要約】

【課題】 請求書発行者側の請求書発行システムの構築を必要とせずに、請求書受領者がインデックスデータを取得できること
【解決手段】
複数の端末と通信可能な情報処理システムであって、電子帳簿の添付と電子帳簿のインデックスデータを受け付ける帳票画面情報を生成する生成手段と、前記生成手段で生成される帳票画面情報への電子帳簿の添付と電子帳簿のインデックスデータの入力を促すメールを送信制御する送信制御手段と、前記送信制御手段により送信制御されたメールの宛先に前記帳票画面情報を送信し、電子帳簿の添付と電子帳簿のインデックスデータを受け付ける受付手段と、を有することを特徴とする。
【選択図】 図６

【特許請求の範囲】

【請求項1】

複数の端末と通信可能な情報処理システムであって、
電子帳簿の添付と電子帳簿のインデックスデータを受け付ける帳票画面情報を生成する生成手段と、
前記生成手段で生成される帳票画面情報への電子帳簿の添付と電子帳簿のインデックスデータの入力を促すメールを送信制御する送信制御手段と、
前記送信制御手段により送信制御されたメールの宛先に前記帳票画面情報を送信し、電子帳簿の添付と電子帳簿のインデックスデータを受け付ける受付手段と、
を有することを特徴とする情報処理システム。

【請求項2】

前記生成手段は、前記電子帳簿の添付と前記電子帳簿のインデックスデータを受け付ける請求書ごとの個別の帳票画面情報を生成することを特徴とする請求項１に記載の情報処理システム。

【請求項3】

前記受付手段で受け付けた添付の電子帳簿と該電子帳簿のインデックスデータを表示制御する表示制御手段をさらに有することを特徴とする請求項１又は２に記載の情報処理システム。

【請求項4】

前記生成手段は、前記個別の帳票画面情報を所定の識別位置に生成することを特徴とする請求項２に記載の情報処理システム。

【請求項5】

前記送信制御手段により送信制御されるメールは、前記個別の帳票画面情報への電子帳簿の添付と電子帳簿のインデックスデータの入力を促すメールであることを特徴とする請求項２に記載の情報処理システム。

【請求項6】

前記生成手段は、前記送信制御手段によりメールを送信制御する直前もしくはメールを送信する当日に前記個別の帳票画面情報を生成することを特徴とする請求項２に記載の情報処理システム。

【請求項7】

前記送信制御手段により送信制御されるメールには、前記個別の帳票画面情報の所定の識別位置の情報を含むことを特徴とする請求項４に記載の情報処理システム。

【請求項8】

前記送信制御手段により送信制御するメールは、所定の日時に送信制御されることを特徴とする請求項１または２に記載の情報処理システム。

【請求項9】

前記送信制御手段は、前記所定の日時を定期的日付とするか特定日付とするかを選択可能とすることを特徴とする請求項８に記載の情報処理システム。

【請求項10】

前記送信制御手段は、前記特定日付に送信制御するメールを識別可能に設定して送信制御することを特徴とする請求項９に記載の情報処理システム。

【請求項11】

前記受付手段により受け付ける電子帳簿のインデックスデータは、前記生成手段により生成される帳票画面情報において表示される入力部に入力されるデータであることを特徴とする請求項１又は２に記載の情報処理システム。

【請求項12】

前記受付手段により受け付ける電子帳簿のインデックスデータは、デリミタにより区切られた複数項目からなる複数のレコードを有するテキストデータであることを特徴とする請求項１又は２に記載の情報処理システム。

【請求項13】

前記受付手段は、取引日と請求金額との入力を促す警告表示を行うことを特徴とする請求項１又は２に記載の情報処理システム。

【請求項14】

複数の端末と通信可能な情報処理システムの制御方法であって、
電子帳簿の添付と電子帳簿のインデックスデータを受け付ける帳票画面情報を生成する生成ステップと、
前記生成ステップで生成される帳票画面情報への電子帳簿の添付と電子帳簿のインデックスデータの入力を促すメールを送信制御する送信制御ステップと、
前記送信制御ステップにより送信制御されたメールの宛先に前記帳票画面情報を送信し、電子帳簿の添付と電子帳簿のインデックスデータを受け付ける受付ステップと、
を有することを特徴とする制御方法。

【請求項15】

少なくとも１つのコンピュータを請求項１又は１３に記載の情報処理システムの各手段として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、請求書の発行を依頼するシステムに関する。

【背景技術】

【0002】

請求書発行者は、各顧客への取引情報を電子データ化して一括管理し、その取引情報を基に、自動的に請求書を作成するシステムを導入していることが多い。このシステムにより定期的な請求書の自動生成を行うことができる。

【0003】

しかし、顧客から臨時に請求書の発行依頼があった場合はシステムを介して請求書を作成することができないという課題があった。

【0004】

特許文献１は、上記課題を解決するため、請求書の臨時発行要求を受け付けると、顧客データベースと取引データベースに記憶されている取引情報とを基に、臨時発行要求に係る取引についての請求書を作成し、該請求書が発行済みであることを示すように、取引データベースに記憶されている取引情報を更新する請求書発行システムが記載されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２００８－２１０１４４

【発明の開示】

【発明が解決しようとする課題】

【0006】

電子帳簿保存法に対応して、請求書受領者は請求書を電磁的記録で保存時に、帳簿の「取引年月日その他の日付」、「取引金額」及び「取引先」を検索条件として設定できることが求められている。

【0007】

電磁的記録で保存される帳簿（以後、電子帳簿）を検索できるようにするため、電子帳簿に紐付くデータとして、請求書発行者からインデックスデータ（「取引年月日その他の日付」、「取引金額」及び「取引先」など）を受理し、電子帳簿とインデックスデータを紐付ける方法がある。この紐付けにより、インデックスデータの検索結果から紐付く電子帳簿を検索することができる。前記請求書発行システムを構築している請求書発行者からの請求書であれば、電子帳簿と関連する請求情報（インデックスデータ）を受信し紐付けることが容易に可能となる。

【0008】

しかしながら、上記構成は請求書発行者が前記請求書発行システムを構築していることが前提であり、請求書発行者が前記請求書発行システムを構築していない場合、請求書受領者は、手動で電子帳簿のインデックスデータの入力や紐付けを行わなければならない。

【0009】

本願発明は、請求書発行者側の請求書発行システムの構築を必要とせずに、請求書受領者がインデックスデータを取得できることを目的とする

【課題を解決するための手段】

【0010】

上記課題を解決するための本発明は、複数の端末と通信可能な情報処理システムであって、電子帳簿の添付と電子帳簿のインデックスデータを受け付ける帳票画面情報を生成する生成手段と、前記生成手段で生成される帳票画面情報への電子帳簿の添付と電子帳簿のインデックスデータの入力を促すメールを送信制御する送信制御手段と、前記送信制御手段により送信制御されたメールの宛先に前記帳票画面情報を送信し、電子帳簿の添付と電子帳簿のインデックスデータを受け付ける受付手段と、を有することを特徴とする。

【発明の効果】

【0011】

本願発明により、請求書発行者側の請求書発行システムの構築を必要とせずに、請求書受領者がインデックスデータを取得することができる。

【図面の簡単な説明】

【0012】

【図1】情報処理システムの概略構成の一例を示す構成図である。

【図2】担当者端末、管理者端末、及びサーバのハードウェア構成の一例を示すブロック図である。

【図3】印刷装置のハードウェア構成の一例を示すブロック図である。

【図4】請求書発行依頼生成処理の一例を示すフローチャートである。

【図5】請求書発行依頼処理の一例を示すフローチャートである。

【図6】請求書発行依頼処理の大まかな流れを説明するシーケンス図である。

【図7】請求書登録情報入力Ｗｅｂページの画面の一例である。

【図8】請求書登録Ｗｅｂページの画面の一例である。

【図9】請求書登録Ｗｅｂページの画面の一例である。

【図10】本実施形態で登録されるｃｓｖデータの一例、ならびにデータベースに登録される顧客データの一例を示す模式図である。

【図11】請求書発行依頼メール文面の一例を示す模式図である。

【図12】画面に表示される請求書画面の一例を示す模式図である。

【図13】請求書検索結果画面の一例を示す模式図である。

【発明を実施するための形態】

【0013】

以下、図面を参照して、本発明の実施形態を詳細に説明する。

【0014】

図１は、本発明の実施形態における情報処理システムのシステム構成の一例を示す図である。

【0015】

情報処理システム１００は、請求書発行者側のスキャナ装置１０２、請求書発行者用端末１０４、ＭＦＰ（ＭｕｌｔｉＦｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）１０８と、請求書管理クラウド１１４上に配置するＷｅｂサーバ兼バッチサーバ１０５、データベースサーバ１０６，及び請求書受領者側の請求書受領者用端末１１０を備えており、それらは、ネットワーク１１２を介して通信可能に接続されている。

【0016】

本願発明では、Ｗｅｂサーバ兼バッチサーバ１０５、データベースサーバ１０６は請求書管理クラウド１１４上に配置する仮想サーバとする。なお、各サーバはクラウド１１４上に配置しなくてもよく、それぞれ一つの筐体で配置しても良いし、それぞれの機能をまとめて１つあるいは複数の筐体に配置しても良い。

【0017】

本願発明の処理の概要を図６を参照して簡単に説明する。

【0018】

図６は、本願発明の処理の大まかな流れを説明する模式図である。

【0019】

図６の処理の流れの前に、まず請求書受領者は、請求書発行者から製品もしくはサービスの提供を受ける。

【0020】

製品もしくはサービスの提供を受けることで請求書受領者は、請求書発行者に請求書を発行してもらうための準備６０１を開始する。

【0021】

６０１において、請求書受領者は、請求書を発行してもらうためのＷｅｂページ（請求書登録Ｗｅｂページ）を生成するための情報（請求書の書類名や請求書発行者の特定など）をバッチサーバ１０５に入力し、請求書発行者に請求書発行を依頼するメールの送信日も入力する。

【0022】

６０２において、バッチサーバ１０５は、メール送信直前もしくはメール送信当日に、請求書登録Ｗｅｂページを作成し、６０３において、メール送信日に、請求書登録ＷｅｂページのＵＲＩ付のメール（請求書発行依頼メール）を請求書発行者に送信する。

【0023】

請求書発行者は、メールを受け取ると書類名などから提供した製品やサービスに対応する請求書を任意のフォーマットで作成する（６０４）。作成した請求書が電子ファイルであればそのままファイルとして管理し、書面であればスキャナ装置１０２などでＰＤＦファイル化する。

【0024】

６０５において、請求書発行者は、受信したメールに記載されている請求書登録ＷｅｂページのＵＲＩを開き、ＷｅｂＤＡＶにより、請求書ファイルをＷｅｂサーバ１０５にアップロードする。また、同じ請求書登録Ｗｅｂページのインデックスデータ入力項目へデータを入力する。

【0025】

Ｗｅｂサーバ１０５に請求書ファイルが登録されると、請求書受領者は、６０６において、請求書ファイルをダウンロードし、６０７において、請求書登録Ｗｅｂページに登録されているインデックスデータと請求書ファイルとの整合性チェックなどを行い、支払依頼書の作成などの以降の支払処理へと進める。

【0026】

以上の大まかな流れで請求書受領者は、請求書ファイルとインデックスデータを取得することができる。図６での概要説明を終え、図１の説明に戻る。

【0027】

図１の請求書受領者用端末１１０は、請求書受領者が使用する端末で、請求書登録Ｗｅｂページ作成のための情報入力やメール送信日をＷｅｂサーバ１０５に送信し、請求書発行者から送信された請求書をＷｅｂサーバ１０５からダウンロードするもしくは閲覧するなどの処理を行う。

【0028】

請求書発行者用端末１０４は、請求書発行者が使用する端末で、請求書の生成やＷｅｂサーバ１０５へのアクセスにより請求書ファイルをアップロードするなどの処理を行う。

【0029】

スキャナ装置１０２やＭＦＰ１０８は、書面で作成された請求書をスキャンすることで請求書発行者用端末にＰＤＦファイルとして取り込む処理などを行う。

【0030】

Ｗｅｂサーバ兼バッチサーバ１０５は、請求書受領者用端末１１０からの入力により、請求書登録Ｗｅｂページを作成し、請求書受領者用端末１１０からの設定されたメール送信日にメールを作成、送信する。また請求書発行者用端末１０４から登録された請求書ファイルと入力されたインデックスデータをデータベースサーバ１０６に登録する。

【0031】

請求書発行者用端末１０４では、データベースサーバ１０６に記憶されている請求書ファイルをＷｅｂサーバ１０５を介して検索表示することが可能であり、さらに、請求書ファイルに対する変更（例えば、ページの差替え、削除、ページの順序の入れ替え等）を行うことを可能としてもよい。なお、請求書受領者用端末１１０も同様に請求書ファイルの検索表示を行うことが可能である。

【0032】

図２は、本発明の実施形態における請求書発行者用端末１０４、Ｗｅｂサーバ１０５、データベースサーバ１０６，及び請求書受領者用端末１１０、これらの情報処理装置のハードウェア構成の一例を示すブロック図である。

【0033】

図２に示すように、これらの情報処理装置は、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、よび通信Ｉ／Ｆコントローラ２０８が接続される。

【0034】

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

【0035】

ＲＯＭ２０２あるいは外部メモリ２１１は、ＣＰＵ２０１が実行する制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や、本情報処理装置で読み取り実行可能なプログラムおよび必要な各種データ（データテーブルを含む）を保持している。

【0036】

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。

【0037】

入力コントローラ２０５は、キーボード２０９や不図示のマウス等のポインティングデバイス等の入力装置からの入力を制御する。入力装置がタッチパネルの場合、ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができることとする。

【0038】

また、タッチパネルは、マルチタッチスクリーンなどの、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。

【0039】

ビデオコントローラ２０６は、ディスプレイ２１０などの外部出力装置への表示を制御する。ディスプレイは本体と一体になったノート型パソコンのディスプレイも含まれるものとする。なお、外部出力装置はディスプレイに限ったものははく、例えばプロジェクタであってもよい。また、前述のタッチ操作を受け付け可能な装置については、入力装置も提供する。

【0040】

なおビデオコントローラ２０６は、表示制御を行うためのビデオメモリ（ＶＲＡＭ）を制御することが可能で、ビデオメモリ領域としてＲＡＭ２０３の一部を利用することもできるし、別途専用のビデオメモリを設けることも可能である。

【0041】

メモリコントローラ２０７は、外部メモリ２１１へのアクセスを制御する。外部メモリとしては、ブートプログラム、各種アプリケーション、フォントデータ、ユーザファイル、編集ファイル、および各種データ等を記憶する外部記憶装置（ハードディスク）、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等を利用可能である。

【0042】

通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信やＩＳＤＮなどの電話回線、および携帯電話の３Ｇ回線を用いた通信が可能である。

【0043】

尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

【0044】

次に、図３を用いて、図１に示した印刷装置１０８のハードウェア構成について説明する。

【0045】

図３は、図１に示した印刷装置１０８のハードウェア構成の一例を示すブロック図である。

【0046】

図３において、３１６はコントローラユニットで、画像入力デバイスとして機能するスキャナ部３１４や、画像出力デバイスとして機能するプリンタ部３１２と接続する一方、ＬＡＮ（例えば、図１に示したＬＡＮ１１２）や公衆回線（ＷＡＮ）（例えば、ＰＳＴＮまたはＩＳＤＮ等）と接続することで、画像データやデバイス情報の入出力を行う。

【0047】

コントローラユニット３１６において、３０１はＣＰＵで、システム全体を制御するプロセッサである。３０２はＲＡＭで、ＣＰＵ３０１が動作するためのシステムワークメモリであり、プログラムを記録するためのプログラムメモリや、画像データを一時記録するための画像メモリでもある。

【0048】

３０３はＲＯＭで、システムのブートプログラムや各種制御プログラムが格納されている。３０４はハードディスクドライブ（ＨＤＤ）で、システムを制御するための各種プログラム，画像データ等を格納する。

【0049】

３０７は操作部インタフェース（操作部Ｉ／Ｆ）で、操作部（キーボード）３０８とのインタフェース部である。また、操作部Ｉ／Ｆ３０７は、操作部３０８から入力したキー情報（例えば、スタートボタンの押下）をＣＰＵ３０１に伝える役割をする。

【0050】

３０５はネットワークインタフェース（Ｎｅｔｗｏｒｋ Ｉ／Ｆ）で、ネットワーク（ＬＡＮ）１１２に接続する。また、無線通信も可能な構成となっており、赤外線やＢｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ（登録商標）を用いた通信にて他の装置と接続し、データの入出力を行う。３０６はモデム（ＭＯＤＥＭ）で、公衆回線に接続し、ＦＡＸの送受信等のデータの入出力を行う。

【0051】

３１８は外部インタフェース（外部Ｉ／Ｆ）で、ＵＳＢ、ＩＥＥＥ１３９４，プリンタポート，ＲＳ－２３２Ｃ等の外部入力を受け付けるＩ／Ｆ部であり、本実施形態においては認証で必要となる携帯端末のＩＣカード（記憶媒体）の読み取り用のカードリーダ３１９が外部Ｉ／Ｆ３１８に接続されている。そして、ＣＰＵ３０１は、この外部Ｉ／Ｆ３１８を介してカードリーダ３１９による携帯端末のＩＣカードからの情報読み取りを制御し、該携帯端末のＩＣカードから読み取られた情報を取得可能である。以上のデバイスがシステムバス３０９上に配置される。

【0052】

３２０はイメージバスインタフェース（ＩＭＡＧＥ ＢＵＳ Ｉ／Ｆ）であり、システムバス３０９と画像データを高速で転送する画像バス３１５とを接続し、データ構造を変換するバスブリッジである。

【0053】

画像バス３１５は、ＰＣＩバスまたはＩＥＥＥ１３９４で構成される。画像バス３１５上には以下のデバイスが配置される。

【0054】

３１０はラスタイメージプロセッサ（ＲＩＰ）で、例えば、ＰＤＬコード等のベクトルデータをビットマップイメージに展開する。３１１はプリンタインタフェース（プリンタＩ／Ｆ）で、プリンタ部３１２とコントローラユニット３１６を接続し、画像データの同期系／非同期系の変換を行う。また、３１３はスキャナインタフェース（スキャナＩ／Ｆ）で、スキャナ部３１４とコントローラユニット３１６を接続し、画像データの同期系／非同期系の変換を行う。

【0055】

３１７は画像処理部で、入力画像データに対し補正、加工、編集を行ったり、プリント出力画像データに対して、プリンタの補正、解像度変換等を行う。また、これに加えて、画像処理部３１７は、画像データの回転や、多値画像データに対してはＪＰＥＧ、２値画像データはＪＢＩＧ、ＭＭＲ、ＭＨ等の圧縮伸張処理を行う。

【0056】

スキャナ部３１４は、原稿となる紙上の画像を照明し、ＣＣＤラインセンサで走査することで、ラスタイメージデータとして電気信号に変換する。原稿用紙は原稿フィーダのトレイにセットし、装置使用者が操作部３０８から読み取り起動指示することにより、ＣＰＵ３０１がスキャナ部３１４に指示を与え、フィーダは原稿用紙を１枚ずつフィードし原稿画像の読み取り動作を行う。

【0057】

プリンタ部３１２は、ラスタイメージデータを用紙上の画像に変換する部分であり、その方式は感光体ドラムや感光体ベルトを用いた電子写真方式、微少ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式等があるが、どの方式でも構わない。プリント動作の起動は、ＣＰＵ３０１からの指示によって開始する。なお、プリンタ部３１２には、異なる用紙サイズまたは異なる用紙向きを選択できるように複数の給紙段を持ち、それに対応した用紙カセットがある。

【0058】

操作部３０８は、ＬＣＤ表示部を有し、ＬＣＤ上にタッチパネルシートが貼られており、システムの操作画面を表示するとともに、表示してあるキーが押されるとその位置情報を操作部Ｉ／Ｆ３０７を介してＣＰＵ３０１に伝える。また、操作部３０８は、各種操作キーとして、例えば、スタートキー、ストップキー、ＩＤキー、リセットキー等を備える。

【0059】

尚、表示部は印刷装置によって表示性能が異なり、タッチパネルを介して操作をできる印刷装置、単に液晶画面を備え文字列を表示（印刷状態や印刷している文書名の表示）させるだけの印刷装置によって本発明は構成されている。

【0060】

ここで、操作部３０８のスタートキーは、原稿画像の読み取り動作を開始する時などに用いる。スタートキーの中央部には、緑と赤の２色ＬＥＤがあり、その色によってスタートキーが使える状態にあるかどうかを示す。また、操作部３０８のストップキーは、稼働中の動作を止める働きをする。また、操作部３０８のＩＤキーは、使用者のユーザＩＤを入力する時に用いる。リセットキーは、操作部からの設定を初期化する時に用いる。

【0061】

カードリーダ３１９は、ＣＰＵ３０１からの制御により、ＩＣカード（ＩＣチップとして携帯端末内に備えられていてもよい）に記憶されている情報を読み取り、該読み取った情報を外部Ｉ／Ｆ３１８を介してＣＰＵ３０１へ通知する。

【0062】

また、カードリーダ３１９はＮＦＣの通信規格に対応しており、ＩＣカードや携帯端末のＩＣチップへの読み書きを行うことが可能な構成となっている。なお、ＮＦＣ規格対応のカードリーダに、ＮＦＣ規格対応の携帯端末をかざすと、認証を行い、携帯端末と印刷装置とのペアリングを行う。

【0063】

そして、かざされた携帯端末と印刷装置で通信（Ｐ２Ｐ）を確立してデータの通信を行うことが可能である。その他、高速通信規格である、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＷｉ－Ｆｉ（登録商標）に通信を引き継ぎ（ハンドオーバー）、携帯端末と印刷装置間で通信を行わせることも可能である。

【0064】

例えば、携帯端末をカードリーダにかざすことで、携帯端末に記憶されている画像を印刷装置へ送信することが可能となる。なお、ＮＦＣの通信規格の詳細は、従来技術であるため、説明を省略するものとする。

【0065】

上述した印刷装置１０８では、印刷装置１０８を制御するためのプラットフォームが存在し、このプラットフォーム上で、認証サーバ（サーバ１０６でも良い）と通信するための認証アプリケーションが動作している。認証アプリケーションはＨＤＤ３０４に記憶されている。プラットフォームが管理する、ログイン時にユーザ情報を格納するログインコンテキストや、各種設定情報は、ＨＤＤ３０４上に領域が確保されている。

【0066】

また、プラットフォーム上には、印刷装置１０８の本体機能を拡張したアプリケーションがインストールされ、動作している。これらアプリケーションは、プラットフォームのＡＰＩを用いて実行される。

【0067】

このプラットフォームを介して、印刷装置１０８の各機能を制御することが可能な構成となっている。

【0068】

また、印刷装置１０８には、Ｗｅｂブラウザも記憶されており、Ｗｅｂシステムと連携することも可能である。この場合、Ｗｅｂアプリケーションサーバから受信した画面を、Ｗｅｂブラウザを用いて表示する。Ｗｅｂブラウザ上で指示した命令は、Ｗｅｂアプリケーションサーバへ要求がなされ、Ｗｅｂアプリケーションサーバからの命令を受け付けることによって、印刷装置１０８により動作（スキャンやプリント処理）を実行することが可能である。

【0069】

以上のような構成によって、印刷装置１０８は、スキャナ部３１４から読み込んだ画像データをＬＡＮ１１２上に送信したり、ＬＡＮ１１２から受信した印刷データをプリンタ部３１２により印刷出力することができる。

【0070】

また、スキャナ部３１４から読み込んだ画像データをモデム３０６により、公衆回線上にＦＡＸ送信したり、公衆回線からＦＡＸ受信した画像データをプリンタ部３１２により出力することできる。

【0071】

次に、図４に示すフローチャートを参照して、請求書発行依頼を生成する処理について説明する。なお、本実施例では請求書発行依頼として説明するが、インデックスデータを有する電子帳簿の発行依頼であれば、領収書や見積書、納品書であっても良い。

【0072】

図４の各ステップは、それぞれ請求書受領者用端末１１０とＷｅｂサーバ兼バッチサーバ１０５のそれぞれのＣＰＵ２０１が実行する処理ステップである。

【0073】

図４のフローチャートの前に請求書受領者用端末１１０において、ブラウザもしくはアプリケーションを立ち上げて、Ｗｅｂサーバ兼バッチサーバ１０５と通信を開始する。図４はＷｅｂサーバ１０５と通信する例である。なお、図示しないが、請求書受領者用端末１１０において、Ｓ４０１の処理の前に、Ｗｅｂサーバ１０５にログインするための認証操作などを行うものとする。

【0074】

図４の（ａ）のＳ４０１において、請求書受領者用端末１１０は、Ｗｅｂサーバ１０５から請求書の情報を入力する請求書登録情報入力Ｗｅｂページの表示命令を送信する。

【0075】

Ｓ４０２において、表示命令を受けたＷｅｂサーバ１０５は、請求書登録情報入力Ｗｅｂページを請求書受領者用端末１１０へ送信する。送信される請求書登録情報入力Ｗｅｂページの例を図７を参照して説明する。

【0076】

図７は、本願発明における請求書登録情報入力Ｗｅｂページの一例である。

【0077】

図７のＷｅｂページ７００は、Ｗｅｂサーバが生成する請求書登録情報入力Ｗｅｂページの例であり、受取側入力欄７２０の入力欄に請求書受領者が受領する請求書に関する情報を登録する。

【0078】

書類名入力欄７０１には請求書の書類名を請求書受領者が登録し、何の請求書かを特定する情報を入力する。取引先入力欄７０２は、複数の取引先のＩＤから請求書の発行を依頼する取引先のＩＤを入力もしくは選択する。また、図示しない担当者入力欄などから、請求書発行依頼メールを送る宛先を特定する。ファイルアップロード領域７０３は、請求書発行者が発行する請求書ファイルをアップロードするための領域である。ファイルアップロード領域７０３については、図８、図９を参照して後述する。

【0079】

受取企業情報入力欄７１０の入力欄では、請求書を受け取る企業が設定する入力情報で請求書発行者に開示する必要がない入力項目の入力を受け付ける。たとえば、請求書の保存する期間を入力する保存期限日７０７や、請求書発行者にメールを送信（通知）する日を入力するメール通知日入力欄７０５、メールの通知区分として、定期通知をするか、１度のみ通知するか、通知しないかを選択する通知区分選択欄７０６などを有する。メール通知日入力欄７０５、通知区分選択欄７０６については、次のＳ４０３、Ｓ４０４のステップにおいて説明する。

【0080】

インデックスデータ入力欄７３０は、請求書発行者が請求書ファイルを添付時に入力する入力欄である。図９を参照して後述する。図４の（ａ）のフローチャートの説明に戻る。

【0081】

図４の（ａ）のＳ４０１において、請求書受領者用端末１１０は、Ｗｅｂサーバ１０５から請求書登録情報入力Ｗｅｂページの情報を受信し、請求書受領者用端末１１０のディスプレイ２１０に表示する。次にＳ４０３において、請求書受領者用端末１１０は、表示された請求書登録情報入力Ｗｅｂページのメール送信日設定項目へユーザからの入力を受け付ける。メール送信日設定項目とは、図７の受取企業情報入力欄７１０のメール通知日入力欄７０５、通知区分選択欄７０６である。図４の（ｂ）のフローチャートを参照して説明する。

【0082】

図４の（ｂ）は、請求書受領者用端末１１０において、請求書発行依頼メールを送信する日の設定入力を受け付ける処理の流れを説明するフローチャートである。

【0083】

図４のＳ４１１において、請求書受領者用端末１１０は、ユーザからメールの通知区分選択欄７０６の入力を受け付ける。メール通知区分が「定期通知」であった場合は、Ｓ４１２へと遷移し、メール通知区分が「１度のみ」であった場合は、Ｓ４１４へと処理を進める。メール通知区分が「通知しない」であった場合は、メール通知の設定をせず、図４の（ｂ）の処理を終了する。

【0084】

Ｓ４１２へと処理を遷移すると、請求書受領者用端末１１０は、ユーザからのメール通知日入力欄７０５の入力により、所定日（たとえば月の２５日など）と定期間隔（毎月）などの入力を受け付ける。

【0085】

次にＳ４１３において、請求書受領者用端末１１０は、メールを送信する日を定期間隔で送信する設定として取得する（前記例では、毎月２５日）。

【0086】

一方、Ｓ４１４へと処理を遷移すると、請求書受領者用端末１１０は、ユーザからのメール通知日入力欄７０５の入力により、特定日の入力を受け付ける（たとえば、２０２３年４月２０日など）。

【0087】

次にＳ４１５において、請求書受領者用端末１１０は、メールを送信する日を特定日（前記例では２０２３年４月２０日）として１度のみ送信する設定とする。また送信するメールを識別可能にするため、１度のみ送信するメールに識別情報を付けるフラグを付しても良い。１度のみ送信するメールに識別情報を付与する例は、図１１で後述する。

【0088】

なお、Ｓ４１１において、メール通知しない設定の場合は、請求書発行者は所定の請求書登録ＷｅｂページのＵＲＩが分からないが、図７の所定の請求書登録情報入力Ｗｅｂページの親階層のＷｅｂページから、図７の検索ボタン７４０を押下することにより、図１３のような請求書検索結果を表示することができる。たとえば、図１３の「ＢＢＢＢプロジェクト請求書」１３０４のような書類名がリンクボタン（青字のアンダーライン）となっていない請求書検索結果は、たとえばインフォメーションボタン「ｉ」１３０５を押下することにより、図８のような請求書登録Ｗｅｂページ画面に遷移することができる。図８のような画面に遷移した後、後述するＳ５０５と同様に請求書ファイルとインデックスデータの入力を受け付ける。メール通知しない例は、たとえば、請求書発行業務が定例化しており、メールを受信することが煩わしい請求書発行者に対してメールを通知しない処理を行う。なお、図１３は請求書受領者用端末１１０でも請求書発行者用端末１０４でも確認することができる。画面例１３００の場合は請求書受領者用端末１１０に表示される一例（担当者欄１３０９が観音販売の「武田信玄」）であるが、請求書発行者用端末１０４でこの画面を開くと、当然担当者欄１３０９には請求書発行担当者が表示される。図４の（ａ）のフローチャートの説明に戻る。

【0089】

図４の（ａ）のＳ４０３において、メール送信日の設定をユーザから受け付けると、Ｓ４０４において、Ｗｅｂサーバ１０５はメール送信日の設定情報を受信し記憶する。

【0090】

次に、Ｓ４０５において、請求書受領者用端末１１０は、ユーザから受け取りたい請求書の情報の入力を受け付けます。ユーザから請求書情報の入力を受け付ける例を図７を参照して説明する。

【0091】

図７の書類名入力欄７０１にたとえば請求書受領者が「ＡＡＡＡプロジェクト請求書」と入力し、取引先（＝請求書発行者）ＩＤ入力欄７０２において「００００００００００５」（「カノン 株式会社」のＩＤ）をサジェスト機能などにより選択すると、請求書発行者用端末１０４のディスプレイ２１０には、図８のように、書類名入力欄８０１に「ＡＡＡＡプロジェクト請求書」と表示され、取引先ＩＤ入力欄の右側８０２には、データベースサーバ１０６から取得した請求書発行者名である「カノン 株式会社」が表示されている（図１０の顧客データ１０２０参照）。以上のように、請求書受領者用端末１１０は、Ｓ４０５において請求書発行者と請求書の書類名（共に請求書登録情報）を送信するための情報の入力を受け付ける。

【0092】

Ｓ４０６において、Ｗｅｂサーバ１０５は、請求書受領者用端末１１０から送信された請求書登録情報を受信し、Ｗｅｂサーバ１０５に記録する。以上で請求書発行依頼メールを送信する以前の処理の流れの説明を終了する。

【0093】

図５に示すフローチャートを参照して、請求書発行依頼メールを送信する処理の流れを説明する。

【0094】

図５の各ステップは、それぞれＷｅｂサーバ兼バッチサーバ１０５と請求書発行者用端末１０４、請求書受領者用端末１１０のそれぞれのＣＰＵ２０１が実行する処理ステップである。

【0095】

図５の（ａ）は、Ｗｅｂサーバ兼バッチサーバ１０５から請求書発行者用端末１０４に請求書発行依頼メールを送信し、請求書発行者用端末１０４から請求書ファイルと請求書ファイルに関するインデックスデータの入力を受け付ける処理の流れを説明するフローチャートである。なお、図示しないが、請求書発行者用端末１０４において、Ｓ５０５の処理の前に、Ｗｅｂサーバ１０５にログインするための認証操作などを行うものとする。

【0096】

図５の（ａ）のフローチャートは、図４のＳ４０４において記録されたメール送信日に開始される処理である。

【0097】

図５の（ａ）のＳ５０１において、Ｗｅｂサーバ１０５は、Ｓ４０６において記録した請求書登録情報から、請求書登録Ｗｅｂページを生成する。生成される請求書登録Ｗｅｂページの画面表示例が図８である。

【0098】

図８は、請求書発行者用端末１０４のディスプレイ２１０に表示される画面表示例であり、図５のフローチャートのＳ５０１において、生成される請求書登録Ｗｅｂページの一例である。

【0099】

図８の請求書登録Ｗｅｂページには、書類名入力欄８０１に「ＡＡＡＡプロジェクト請求書」取引先ＩＤ入力欄の右側８０２に「カノン 株式会社」が表示されており、「カノン 株式会社」の担当者である「上杉謙信」（８０９）へ請求書の登録を依頼するＷｅｂページである。なお、８０４には入力必須項目である発行日８１１と請求金額欄８１２との入力を促す注意書きを表示する。

【0100】

請求書登録Ｗｅｂページはメール送信直前もしくはメール送信当日に生成し、メール送信日より前に請求書登録Ｗｅｂページを生成しない仕様にしてもよい。この仕様は、請求書登録Ｗｅｂページがメールに記載のＵＲＩ以外からもアクセス可能なための対策である。請求書登録Ｗｅｂページは親階層のＵＲＩから図８の検索ボタン８０８を用いて請求書発行者が請求書登録Ｗｅｂページを検索できる。メール送信当日より前に請求書登録Ｗｅｂページを事前に生成していると、たとえば請求書発行者が発行の遅れている請求書（前月の請求書など）を登録する際に、誤って異なる請求書登録Ｗｅｂページに請求書ファイルをアップロードしてしまう可能性がある。このミスを防ぐために請求書発行依頼メールを送信する以前にはメールに記載するＵＲＩの請求書登録Ｗｅｂページは生成しない仕様としてもよい。図５のフローチャートの説明に戻る。

【0101】

図５の（ａ）のＳ５０１において、図８のような請求書登録Ｗｅｂページを生成し、請求書登録Ｗｅｂページの所定のＵＲＩ（識別位置）に配置する。その後、バッチサーバ１０５は、Ｓ５０２において、請求書発行者用端末１０４に請求書発行の依頼メールを送信する。送信するメール文面の一例を図１１を参照して説明する。

【0102】

図１１は、請求書発行依頼メール文面の一例を示す図である。

【0103】

１１００には、Ｓ５０１で設定された請求書登録ＷｅｂページのＵＲＩを示す登録ＵＲＬ欄１１０１と何の請求書かを特定する請求書の文書名１１０２が表示されている。請求書発行担当者が登録ＵＲＬ欄１１０１のＵＲＩ部分を押下すると、Ｓ５０１で生成された請求書登録Ｗｅｂページを表示する。

【0104】

帳票一覧ＵＲＬ欄１１０３は、請求書発行者側（図１１の例では「カノン株式会社」）がこれまでに発行した帳票（請求書）を一覧で表示させるためのＵＲＩであり、ログインＵＲＩ１１０４は、上記２つのＵＲＩに入るためのログイン認証を行うためのＵＲＩである。

【0105】

図１１は、図４のＳ４１１において１度のみ通知を選択した場合のメールの例である。１度のみ通知の場合、メールに重要フラグである「Ｉｍｐｏｔｅｎｃｅ：ｈｉｇｈ」１１１０などを付与して他のメールに埋もれることがないように識別可能にして送信してもよい。１度のみの請求書発行依頼メールの場合、所定の日に定期的に発行を依頼する請求書と異なり、請求書発行者がメールを見落とすと催促メールを送るまで気付かれない可能性が高い。そのため、１度のみの請求書の場合、重要フラグを付けるなどにより他のメールと識別可能にして送信してもよい。なお、重要フラグの他にもメールの件名に黒四角（■）を付けたり、件名を墨つき括弧で括るなどにより請求書発行担当者が識別し易い方式ならば、どのような形でもよい。図５のフローチャートの説明に戻る。

【0106】

図５の（ａ）のＳ５０３において、請求書発行者用端末１０４は、バッチサーバ１０５より送信されたメールを受信し、請求書発行担当者（図８の場合は、「上杉謙信」）の指示によりメール文面を請求書発行者用端末１０４のディスプレイ２１０に表示する。

【0107】

請求書発行担当者は、受信したメールを表示させ、メールに記載の請求書書類名８０１などから、該当の製品もしくはサービスなどの請求書を作成する。Ｓ５０４において、請求書発行者用端末１０４は、作成された請求書を情報処置装置上のファイルとして記憶する。記憶する請求書は情報処理装置上で生成されたファイルであっても良いし、紙面であってもよい。紙面の請求書の場合は、スキャナ装置１０２やＭＦＰ１０８などによりＰＤＦ化してファイル形式に変換し、請求書発行者用端末１０４に記憶する。作成された請求書の例を図１２を参照して説明する。

【0108】

図１２は、生成された請求書の一例であり、図９～図１１の図面と関連付く請求書の例である。

【0109】

１２００は、「カノン 株式会社」から「観音販売株式会社」に発行された請求書の例である。請求書の記載事項の中で電子帳簿保存法の検索項目として指定されている項目は、「取引年月日その他の日付」、「取引金額」及び「取引先」であり、取引年月日（請求日１２０２）は「２０２３／４／２０」、取引金額１２０１は「３２，８００円」、取引先１２０３は「カノン 株式会社」である。これらのインデックスデータをこの請求書と紐付けて記憶しておき、後日容易に検索できるようにする必要がある。図１２の説明を終え、図５のフローチャートの説明に戻る。

【0110】

図５の（ａ）のＳ５０５において、請求書発行者用端末１０４は、ディスプレイ２１０に表示された請求書発行依頼メールの登録ＵＲＬ欄１１０１が請求書発行者により押下され、請求書登録Ｗｅｂページを表示する命令をＷｅｂサーバ１０５に送信する。

【0111】

Ｓ５０６において、Ｗｅｂサーバ１０５は、請求書登録Ｗｅｂページ表示命令を受信すると、Ｓ５０１で生成した請求書登録Ｗｅｂページを請求書発行者用端末１０４に送信する。送信された請求書登録Ｗｅｂページを請求書発行者用端末１０４のディスプレイ２１０に表示し、請求書発行者用端末１０４は、Ｓ５０５において、請求書発行者により、インデックスデータの入力を受け付ける。なお、インデックスデータの入力方法は請求書発行者による入力の他に、複数の請求書のデータをまとめてｃｓｖ（Ｃｏｍｍａ Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅ）ファイルとして請求書ファイルとともにアップロードしてもよい。

【0112】

Ｓ５０６において、Ｗｅｂサーバ１０５は、請求書登録Ｗｅｂページに入力されたインデックスデータを受け付ける。図８と図９を参照してインデックスデータの入力受付処理を説明する。

【0113】

図８と図９は、請求書発行者用端末１０４のディスプレイ２１０に表示される画面表示例である。

【0114】

図８は、Ｓ５０１により生成された請求書登録Ｗｅｂページであり、インデックスデータ入力領域８３０の必須項目（発行日と請求金額）の入力を促す（８０４）
発行日欄８１１と請求額欄８１２に値が入力された例が図９の９３０である。

【0115】

図９は、Ｓ５０５及びＳ５０７において請求書発行者からインデックスデータが入力され、請求書ファイルがアップロードされた後の請求書登録Ｗｅｂページの画面の一例である。

【0116】

図９の９３０の発行日欄９１１に「２０２３／４／２０」が請求書発行者により入力されており、請求額欄９１２に「３２，８００」円が請求書発行者により入力されている。取引先情報は、請求書登録Ｗｅｂページ生成時に９１３のように設定されている。図５のフローチャートの説明に戻る。

【0117】

図５の（ａ）のＳ５０５において、請求書登録Ｗｅｂページへのインデックスデータの入力を受け付けると、Ｓ５０７において、請求書発行者用端末１０４は、請求書登録Ｗｅｂページにより請求書ファイルのアップロードを受け付ける。図８のファイルアップロード欄８０３にファイルをドラッグアンドドロップするか、もしくは参照ボタン押下後に出力されるファイル指定ポップアップウィンドウよりファイルを指定し、請求書ファイルをアップロードする。アップロードされた後の画面例が図９のファイルアップロード欄９０３である。ファイルアップロード欄９０３には、ファイル名「ＡＡＡＡプロジェクト請求書．ｐｄｆ」というファイルが設定されている。なお、ファイルアップロード欄９０３には複数のファイルをアップロードすることができ、複数の請求書ファイルをアップロードする際は、このＵＩではインデックスデータの紐付けができないので、複数の請求書ファイルと並行してアップロードされたインデックスデータのｃｓｖファイルをアップロードする。請求書登録ＷｅｂページからのＵＩによる入力ではなく、アップロードするファイル名と紐付けたｃｓｖファイル（たとえば、一行に１つのファイル名と１つの請求書のインデックスデータが入力された複数行のｃｓｖデータなど）により、インデックスデータを紐付けしてもよい。その場合、Ｓ５０５において、インデックスデータは入力せず、Ｓ５０７において、請求書ファイルと一緒にｃｓｖファイルをアップロードする。

【0118】

Ｓ５０８において、Ｗｅｂサーバ１０５は、Ｓ５０７において、請求書発行者用端末１０４から請求書登録Ｗｅｂページにアップロードされた請求書ファイルをデータベースサーバ１０６に記録し、Ｓ５０６で入力を受け付けたインデックスデータ、もしくはＳ５０７で請求書ファイルと一緒にアップロードされたｃｓｖファイルから、インデックスデータを請求書ファイルと紐付け、データベースサーバ１０６に記録する。以上で図５の（ａ）のフローチャートの説明を終える。

【0119】

図５（ｂ）のフローチャートは、Ｗｅｂサーバ１０５にアップロードされた請求書ファイルを請求書受領者用端末１１０にダウンロードし、インデックスデータと請求書ファイルの整合性のチェックなどを行うために請求書ファイルとインデックスデータを表示する処理の流れである。

【0120】

図５のＳ５１１において、請求書受領者用端末１１０は、Ｗｅｂサーバ１０５に請求書ファイルと請求書ファイルに紐付くインデックスデータを取得する依頼を送信する。

【0121】

Ｓ５１２において、Ｗｅｂサーバ１０５は表示要求された請求書ファイル及びインデックスデータをデータベースサーバ１０６から取得して、請求書受領者用端末１１０に送信する。

【0122】

Ｓ５１３において、請求書発行者用端末１１０は、Ｗｅｂサーバ１０５から受信した請求書ファイルとインデックスデータとをディスプレイ２１０に表示する。請求書ファイルとインデックスデータを表示した画面例を図１３を参照して説明する。

【0123】

図１３は、請求書ファイル検索結果画面を示す表示例である。

【0124】

図１３の１３００は、請求書受領者（１３００の場合、観音販売の担当者欄１３０９は武田信玄）が検索ボタン１３０８により検索した結果の請求書一覧画面の例である。

【0125】

１３００内の書類名にリンクボタンとして登録されている「ＡＡＡＡプロジェクト請求書」リンクボタン１３０１を請求書受領者がクリックすると、図１２の請求書画面１２００を表示する。表示された請求書画面１２００と、１３００の「ＡＡＡＡプロジェクト請求書」の行のインデックスデータとを請求書受領者がチェック（整合性チェック）を行い、整合していれば、請求書受領者が、チェックボックス１３０２をクリックする。チェックボックスが１３０２のようにエクスプラネーションマーク「！」である請求書は、整合性チェックが済んでいない請求書を示し、チェックボックス１３０３のようにチェックマークが付与された請求書は請求書受領者によるチェックが終了している請求書を示す。図１３の説明を終える。

【0126】

図５のＳ５１３による請求書ファイルとインデックスデータの表示処理の終了後、請求書受領者は、請求書のインデックスデータなどから経理部門などに支払依頼書を作成して提出し、請求書発行者に請求金額の支払を行ってもらう手続きを進める処理を行う。経理部門に送るデータは、Ｓ５１３で請求書ファイルと整合性チェックを行っているインデックスデータを送信すれば良いので、支払依頼書の作成も容易にでき、会計システムへの入力業務も削減できる。Ｓ５１３以降の処理は、本発明の内容とは無関係のため、説明を省略する。

【0127】

以上のように、本願発明により、請求書受領者は、請求書発行者側の請求書発行システムの構築を必要とせずに、請求書受領者がインデックスデータを取得することができる。また、請求書発行者も個人宛に請求書を送付した際などに起こる送付先の漏れや紛失リスクを防止でき、図１３の画面例のように請求書を一覧で確認することができるので、請求書発行者側が送付漏れを防ぐことができる。また、請求書受領者側での確認有無（図１３の１３０３）が分かるので、請求書受領の確認の手間を低減できる。

【0128】

なお、ステップＳ５０７で請求書発行者からインデックスデータをｃｓｖファイルで送信する場合、送信されるｃｓｖファイルのフォーマット（データ順の定義など）は、予め請求書受領者が定義しておくことが望ましい。このフォーマットのファイルはＳ５０２においてｃｓｖファイルとして請求書発行者にメールと共に送付する方法でもよいし、事前に請求書発行者に送付しておいて、請求書発行者がＳ５０７によるｃｓｖファイル送付の際に入力する方法でも良い。

【0129】

Ｓ５０２において、ｃｓｖファイルのフォーマットを請求書発行者にメールと共に送付する方法の場合の、請求書発行者に送付するｃｓｖファイルの例を図１０を参照して説明する。なお、図１０のデータ例１０００，１０１０では、データを見やすくするために、カンマセパレートの形式ではなく表形式で表示している。

【0130】

図１０のデータ例１０００は、請求書受領者から請求書発行者に請求書発行依頼メールが送信された直後の添付されているｃｓｖファイルの例である。受領者ＩＤや発行側ＩＤ、帳票名など予め指定されるべき項目には、所定のデータが入力されている。データ例１０００では、受領者ＩＤ「１００００００００００１」の「観音販売株式会社」、発行側ＩＤ「００００００００００５」の「カノン株式会社」（共に、１０２０を参照）が入力されており、データ例１０００の１行目の帳票名については「ＡＡＡＡプロジェクト請求書」の発行依頼であることが明記されている。

【0131】

データ例１０００のようなｃｓｖファイルを受信した請求書発行者は、図示しないｃｓｖエディタ（たとえば、Ｅｘｃｅｌ（登録商標））などでｃｓｖファイルを開き、必要な項目にデータを入力する。データ例１０１０は、請求書発行者により入力されたデータの例である。データ例１０１０の一行目のファイル名には、「ＡＡＡＡプロジェクト請求書．ｐｄｆ」と入力され、発行日付は「２０２３／４／２０」、請求額欄には「￥３２，８００」が入力されている。このデータは図１２の１２００の請求書の場合の一行の例である。

【0132】

以上のように、ｃｓｖファイルの共通のフォーマットを使うことにより、インデックスデータの紐付けを容易に設定することができる。

【0133】

以上のように、本願発明により、請求書発行者側の請求書発行システムの構築を必要とせずに、請求書受領者がインデックスデータを取得することができる。また、請求書発行者も個人宛に請求書を送付した際などに起こる送付先の漏れや紛失リスクを防止でき、図１３の画面例のように請求書を一覧で確認することができるので、請求書発行者側が送付漏れを防ぐことができる。また、請求書受領者側での確認有無（図１３の１３０３）が分かるので、請求書受領の確認の手間を低減できる。

【0134】

以上、本発明の実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

【0135】

また、本発明におけるプログラムは、図４または５に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図４乃至５の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図４または５の各装置の処理方法ごとのプログラムであってもよい。

【0136】

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。

【0137】

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。

【0138】

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＤＶＤ－ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。

【0139】

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

【0140】

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

【0141】

また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

【0142】

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

【符号の説明】

【0143】

１００ 情報処理システム
１０２ スキャナ装置
１０４ 請求書発行者用端末
１０５ バッチサーバ兼Ｗｅｂサーバ
１０６ データベースサーバ
１０８ ＭＦＰ
１１０ 請求書受領者用端末
１１２ インターネット回線
１１４ クラウド環境

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】