JP5987158B2 - 情報処理装置およびアクセス権限付与方法 - Google Patents

Description

本発明は情報処理装置およびアクセス権限付与方法に関する。

請求書の管理を一括して行うシステムが知られている。例えば、同一の被請求人に対する電子請求書をとりまとめるとともに合計金額を算出する方法が知られている。

特表２００５−５３７５８８号公報 特開２００３−１８７１５９号公報

親会社が共通していても子会社間や、親会社と子会社では地理的に異なる地点にいるユーザーが、様々な取引先より入手する請求書をとりまとめ一元管理することが難しいという問題がある。また、１企業においても地理的に異なる各営業所、各支社、各工場にいる各ユーザーが入手した請求書をとりまとめ一元管理することが難しいという問題がある。なお、請求書について説明したが、コンピュータを介してやりとりする他の文書（以下、ビジネス文書）についても同様の問題がある。
１つの側面では、本発明は、会社全体またはその企業グループ全体の請求書の閲覧とその情報の一元管理を可能とすることを目的とする。

上記目的を達成するために、開示の情報処理装置が提供される。この情報処理装置は、第１の記憶部と、生成部と、第２の記憶部と、処理部とを有している。
第１の記憶部は、ユーザを特定するユーザ特定情報と少なくとも１つの固有の情報とをユーザ毎に関連づけたユーザ情報を記憶する。
生成部は、第１の記憶部に記憶される固有の情報とユーザ特定情報とを用いて所定の規則に基づきユーザ毎にコードを生成する。
第２の記憶部は、第１の記憶部に記憶されているユーザ情報が備える第１のユーザのユーザ特定情報を含む請求書情報を記憶する。

処理部は、第１の記憶部にユーザ情報が記憶されている第２のユーザからの請求書情報へのアクセス要求を受け付けると、第１のユーザの第１のコードと、第２のユーザの第２のコードが一致するか否かを判断し、第１のコードと第２のコードとが一致する場合、第２の記憶部に記憶されている第１のユーザが作成した請求書情報へのアクセス権限を第２のユーザに付与する。

１態様では、会社全体または企業グループ全体の請求書の閲覧とその情報の一元管理を可能とすることができる。

第１の実施の形態のシステムの構成を示す図である。 実施の形態の情報処理装置のハードウェア構成を示す図である。 実施の形態の情報処理装置の機能を示すブロック図である。 ユーザ情報を入力する画面の一例を示す図である。 ユーザ情報記憶部に記憶される情報の一例を示す図である。 ユーザ情報管理部分に設定されている情報の一例を示す図である。 ユーザ情報管理部分に設定されている情報の一例を示す図である。 生成情報管理部分に設定されている情報の一例を示す図である。 生成情報管理部分に設定されている情報の一例を示す図である。 請求書情報入力画面の一例を説明する図である。 請求書情報記憶部に記憶される情報の一例を示す図である。 請求書情報記憶部に記憶される情報の一例を示す図である。 請求元のユーザ情報と請求先のユーザ情報の関連づけの一例を説明する図である。 請求元のユーザ情報と請求先のユーザ情報の関連づけの一例を説明する図である。 請求元のユーザ情報と請求先のユーザ情報の関連づけの一例を説明する図である。 請求元のユーザ情報と請求先のユーザ情報の関連づけの一例を説明する図である。 請求元のユーザ情報と請求先のユーザ情報の関連づけの一例を説明する図である。 請求元のユーザ情報と請求先のユーザ情報の関連づけの一例を説明する図である。 請求元のユーザ情報と請求先のユーザ情報の関連づけの一例を説明する図である。 請求元のユーザ情報と請求先のユーザ情報の関連づけの一例を説明する図である。 共有依頼入力画面の一例を説明する図である。 共有者の登録を説明する図である。 登録処理部の処理を示すフローチャートである。 共有者登録処理を示すフローチャートである。 請求書情報の個別登録処理を説明するフローチャートである。 請求書情報の一括登録処理を説明するフローチャートである。 チェック処理を説明するフローチャートである。 請求書情報共有処理を説明する図である。 振込処理を説明する図である。 支払い内容確認画面の一例を示す図である。 第２の実施の形態のユーザ情報管理部分に設定されている情報の一例を示す図である。

＜第１の実施の形態＞
図１は、第１の実施の形態のシステムの構成を示す図である。
システム１は、情報処理装置１０と端末装置２０ａ、２０ｂ、２０ｃとがインターネット（internet）等のネットワーク５０を介して接続されている。

情報処理装置１０と、端末装置２０ａ、２０ｂ、２０ｃはＷｅｂプログラムを実装している。端末装置２０ａ、２０ｂ、２０ｃは、Ｗｅｂブラウザを介して請求書に関するデータを情報処理装置１０とやりとりする。なお、本実施の形態では請求書に関するデータのやりとりを例示するが、請求書はビジネス文書の一例であり、本発明は請求書のやりとりに限定されない。ビジネス文書の他の例としては、例えば見積書や注文書等が挙げられる。
端末装置２０ａ、２０ｂ、２０ｃは、それぞれ請求書を受発注するユーザ（例えば経理担当者）が操作する端末装置である。

例えば、端末装置２０ａはＡ社のユーザが操作する端末装置であり、端末装置２０ｂは、Ｂ社（Ａ社とは別会社）のユーザが操作する端末装置である。また、端末装置２０ｃは、Ａ社のグループ子会社であるＡｇ社のユーザが操作する端末装置である。

Ａ社、Ｂ社、Ａｇ社の各ユーザは、それぞれ自己に割り当てられたＥｍａｉｌアドレス等を用いて情報処理装置１０にユーザ登録を行うことにより、情報処理装置１０が構築する請求書処理システムにアクセスする環境を整える。

その後、Ａ社からＢ社宛に請求書を発行する場合、Ａ社のユーザは端末装置２０ａを操作することにより、請求書に関する情報（請求書情報）を作成する。端末装置２０ａで作成された請求書情報は、情報処理装置１０に一時的に記憶される。そして、Ｂ社のユーザが操作する端末装置２０ｂからの請求書へのアクセス要求に応じて情報処理装置１０は、Ａ社のユーザが作成した請求書情報を端末装置２０ｂが閲覧可能にする。

また、Ａｇ社のユーザがＢ社宛に請求書を発行した場合、情報処理装置１０は、子会社であるＡｇ社が発行した請求書をＡ社のユーザが閲覧できるようにすることができる。この処理は共有者登録処理として後に詳述する。

また、情報処理装置１０は、Ｂ社がＡ社とＡｇ社への請求金額を一括して処理できる機能を備える。情報処理装置１０は、Ｂ社が一括して支払った請求金額を、Ａ社とＡｇ社それぞれの口座に振り込む機能を備えている。
以下、情報処理装置１０の機能を具体的に説明する。

図２は、実施の形態の情報処理装置のハードウェア構成を示す図である。
情報処理装置１０は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０８を介してＲＡＭ（Random Access Memory）１０２と複数の周辺機器が接続されている。

ＲＡＭ１０２は、情報処理装置１０の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に使用する各種データが格納される。

バス１０８には、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、ドライブ装置１０６、および通信インタフェース１０７が接続されている。

ハードディスクドライブ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ハードディスクドライブ１０３は、情報処理装置１０の二次記憶装置として使用される。ハードディスクドライブ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリ等の半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ１０４ａが接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１０４ａの画面に表示させる。モニタ１０４ａとしては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や、液晶表示装置等が挙げられる。

入力インタフェース１０５には、キーボード１０５ａとマウス１０５ｂとが接続されている。入力インタフェース１０５は、キーボード１０５ａやマウス１０５ｂから送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１０５ｂは、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、例えばタッチパネル、タブレット、タッチパッド、トラックボール等が挙げられる。

ドライブ装置１０６は、例えば、光の反射によって読み取り可能なようにデータが記録された光ディスクや、ＵＳＢ（Universal Serial Bus）メモリ等の持ち運び可能な記録媒体に記録されたデータの読み取りを行う。例えば、ドライブ装置１０６が光学ドライブ装置である場合、レーザ光等を利用して、光ディスク２００に記録されたデータの読み取りを行う。光ディスク２００には、Ｂｌｕ−ｒａｙ（登録商標）、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。

通信インタフェース１０７は、ネットワーク５０に接続されている。通信インタフェース１０７は、ネットワーク５０を介して、他のコンピュータまたは通信機器との間でデータを送受信する。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図２には情報処理装置１０のハードウェア構成を示したが、端末装置２０ａ、２０ｂ、２０ｃも情報処理装置１０と同様のハードウェア構成で実現できる。
情報処理装置１０内には、以下のような機能が設けられる。

図３は、実施の形態の情報処理装置の機能を示すブロック図である。
情報処理装置１０は、ユーザ情報記憶部１１と、登録処理部１２と、請求書処理部１３と、請求書情報記憶部１４とを有している。
ユーザ情報記憶部１１には、端末装置２０ａ、２０ｂ、２０ｃが作成したユーザ情報が記憶される。
登録処理部１２は、ユーザが登録した情報（ユーザ情報）をユーザ情報記憶部１１に書き込む。このユーザ情報は請求書の処理に用いられる。
請求書情報記憶部１４には、端末装置２０ａ、２０ｂ、２０ｃが作成した請求書情報が記憶される。
請求書処理部１３は、通知部１３ａと振込処理部１３ｂとを有している。

通知部１３ａは、請求書情報記憶部１４に記憶される請求書情報から請求書情報を送信したユーザを特定する。そして、親会社が共通する会社（親会社も含む）からの請求書情報をとりまとめる。そして、通知部１３ａは、親会社が共通する会社からの各請求書を請求先に通知する。また、通知部１３ａは、親会社が共通する会社の請求金額をとりまとめた金額（とりまとめ金額）を請求先に通知する。
なお、請求書のとりまとめる単位は前述したものに限定されず、例えば会社名が同じ（親会社と子会社は区別した）各請求書をとりまとめるようにしてもよい。

振込処理部１３ｂは、請求先のユーザからの口座へのとりまとめ金額の振り込みに基づき、請求書に記載された金額毎に振り分けて親会社や子会社毎に振り込む処理を実行する。
次に、ユーザ情報記憶部１１に記憶される情報の一例を説明する。

図４は、ユーザ情報を入力する画面の一例を示す図である。
図４に示すユーザ情報入力画面２１は、例えば端末装置２０ａに接続されたモニタ２２に表示される。また、ユーザ情報入力画面２１には、送信ボタン２１ａ、および中止ボタン２１ｂが表示される。

ユーザ情報入力画面２１には、国名、Ｅｍａｉｌアドレス、会社名、英字会社名、氏名、ユーザ所在地郵便番号、ユーザ所在地、ユーザ電話番号、ユーザＦＡＸ番号、本社所在地郵便番号、本社所在地、および企業ＨＰＵＲＬの欄が設けられている。
国名の欄には、ユーザ情報を入力するユーザ（図４の説明において以下、単にユーザという）の勤務する会社所在地の国名を識別する情報が選択される。
Ｅｍａｉｌアドレスの欄には、社内においてユーザに割り当てられているＥｍａｉｌアドレスが入力される。
会社名の欄には、ユーザが勤務する会社名が日本語で入力される。
英字会社名の欄には、ユーザが勤務する会社名が英語で入力される。
氏名の欄には、ユーザの氏名が入力される。

ユーザ所在地郵便番号の欄には、ユーザが勤務する会社の所在地（例えば本社であれば本社、支社であれば支社、営業所であれば営業所）の郵便番号が入力される。
ユーザ所在地の欄には、ユーザが勤務する会社の所在地が入力される。
ユーザ電話番号の欄には、ユーザが連絡を希望する電話番号が入力される。
ユーザＦＡＸ番号の欄には、ユーザが連絡を希望するＦＡＸ番号が入力される。
本社所在地郵便番号の欄には、ユーザが勤務する会社の本社所在地の郵便番号が入力される。
本社所在地の欄には、ユーザが勤務する会社の本社所在地が入力される。
企業ＨＰＵＲＬの欄には、企業のホームページのＵＲＬ（Uniform Resource Locator）が入力される。

なお、図４には図示していないが、ユーザが属する社内の部署名を入力する欄や、従業員コードの欄や、代表原価負担部門の欄や代表勘定科目の欄が設けられていてもよい。
ユーザにより送信ボタン２１ａが押下されると、端末装置２０ａは、ユーザ情報を情報処理装置１０に送信する。

図５は、ユーザ情報記憶部に記憶される情報の一例を示す図である。
本実施の形態ではユーザ情報がテーブル化されて記憶されている。図５に示すユーザ情報管理テーブルＴ１には、管理番号を記憶する管理番号部分Ｄ１と、ユーザ情報が記憶されているユーザ情報管理部分Ｄ２と、生成情報が記憶されている生成情報管理部分Ｄ３とが設けられている。これらのうち、生成情報は、ユーザ情報に基づき登録処理部１２が生成した情報である。これら３つの情報は、互いに関連づけられており、連番が割り振られている。この連番によって各情報が識別される。

管理番号部分Ｄ１には、ユーザ情報を管理する番号が記憶される。例えば、図５に示すユーザ管理番号Ａｇ１のユーザは、Ａ社のグループ会社に所属していることを示している。このユーザ管理番号は、ユーザ情報に含まれる本社所在地やドメイン等に基づき重複しないように登録処理部１２が作成する。

図６および図７は、ユーザ情報管理部分に設定されている情報の一例を示す図である。
ユーザ情報管理部分Ｄ２の各項目としては、ユーザ管理番号、国名、Ｅｍａｉｌ、会社名、英字会社名、氏名、〒番号、ユーザ所在地、電話番号（ＴＥＬ）、ＦＡＸ番号（ＦＡＸ）、本社郵便番号、本社所在地、企業ＨＰＵＲＬ、社内共有者がある。

ユーザ情報管理部分Ｄ２における、図４に示すユーザ情報入力画面２１の欄と同じ名称の欄については、それぞれユーザ情報入力画面２１でユーザが入力した情報が記憶されている。このため詳細の説明は省略する。

社内共有者の欄には、当該ユーザ管理番号のユーザが作成し、請求書情報記憶部１４に記憶されている請求書にアクセス可能なユーザのＥｍａｉｌアドレスが設定される。図７では紙面の都合上、Ｅｍａｉｌアドレスの共通する部分については表記を省略している。例えば１行目の「2,3,4,5,[email protected]」は、[email protected]、[email protected]、[email protected]、[email protected]、[email protected]が設定されていることを示している。

図８および図９は、生成情報管理部分に設定されている情報の一例を示す図である。
図８および図９に示す生成情報管理部分Ｄ３の項目としては、Ｅｍａｉｌドメイン、ユーザ開始年月日、ユーザ変更年月日、ユーザ変更年月度、ユーザ所在地情報、ユーザ所在地（緯度）、ユーザ所在地（経度）、本社位置情報、本社位置（緯度）、本社位置（経度）、汎用企業グループコード、および汎用企業コードがある。横方向に並べられた情報同士が互いに関連づけられている。
Ｅｍａｉｌドメインの欄には、Ｅｍａｉｌアドレスのドメインが設定される。

ユーザ開始年月日の欄には、ユーザがユーザ情報を送付した年月日が設定される。この年月日は、ユーザ情報を受信した日付情報から登録処理部１２が作成する。

ユーザ変更年月日の欄には、ユーザがユーザ情報記憶部１１に記憶されているユーザ情報を変更した年月日が設定される。この年月日は、ユーザ情報を変更するＥｍａｉｌを受信した日付情報から作成する。

ユーザ変更年月度の欄には、ユーザがユーザ情報記憶部１１に記憶されているユーザ情報を変更した年および月が設定される。この年月度は、登録情報を変更するＥｍａｉｌを受信した日付情報から作成する。

ユーザ所在地情報の欄には、ユーザの所在地の緯度および経度（世界測地系（ＷＧＳ８４））が設定される。この情報は、例えば登録処理部１２がユーザ所在地から緯度および経度を割り出す。
ユーザ所在地（緯度）の欄には、ユーザの所在地の緯度が設定される。
ユーザ所在地（経度）の欄には、ユーザの所在地の経度が設定される。
本社位置情報の欄には、ユーザが所属する会社の本社所在地の緯度および経度（本社位置情報）が設定される。

本社位置（緯度）の欄には、本社位置情報に基づき登録処理部１２が生成した値が設定される。本社所在地の緯度が北緯３３度５２分２５．３４９秒である場合を例に説明する。まず、緯度の小数点以上の数値を羅列する。上記例では、３３５２２５となる。緯度が北緯の場合は先頭に「１」を設定し、南緯の場合は先頭に「２」を設定する。緯度が１桁、または２桁の場合は先頭に「０」をつけて３桁にする。小数点は四捨五入する。これにより、上記例の本社位置（緯度）の欄には、「１０３３５２２５」が設定される。

本社位置（経度）の欄には、本社位置情報に基づき登録処理部１２が生成した値が設定される。本社所在地の緯度が東経１３０度５２分２３．１８９秒である場合を例に説明する。まず、経度の数値の小数点以上を羅列する。上記例では、１３０５２２３となる。経度が東経の場合は先頭に「１」を設定し、西経の場合は先頭に「２」を設定する。経度が１桁、または２桁の場合は先頭に「０」をつけて３桁にする。小数点は四捨五入する。これにより、上記例の本社位置（経度）の欄には、「１１３０５２２３」が設定される。

汎用企業グループコードの欄には、ユーザ変更年月度の欄に設定された値と、本社位置（緯度）の欄に設定された値と、本社位置（経度）の欄に設定された値と、ドメインの欄に設定された値とが、この順番に並べられた値が設定される。図８および図９に示す生成情報Ｄ２のユーザ管理番号Ａｇ１の各欄の値を例に説明する。ユーザ管理番号Ａｇ１の汎用企業グループコードの欄には、国名の欄に設定された情報「ｊｐ」と、ユーザ変更年月度の欄に設定された値「２０１３０５」と、本社位置（緯度）の欄に設定された値「１０３３５２２５」と、本社位置（経度）の欄に設定された値「１１３０５２２３」と、ドメインの欄に設定された値「ｊｐ．ｘｘｘ」とが、この順番に並べられたコード「ｊｐ２０１３０５１０３３５２２５１１３０５２２３ｊｐ．ｘｘｘ」が設定されている。

汎用企業コードの欄には、汎用企業グループコードの欄に設定された値と、英字会社名の欄に設定された値がこの順番に並べられた値が設定される。なお、株式会社等の名称や、スペースやカンマは汎用企業コードには含めない。例えばユーザ管理番号Ａｇ１の汎用企業コードの欄には、汎用企業グループコードの欄に設定されたコード「ｊｐ２０１３０５１０３３５２２５１１３０５２２３ｊｐ．ｘｘｘ」と、英字会社名の欄に設定された情報「ｘｘｘ」が、この順番に並べられたコード「ｊｐ２０１３０５１０３３５２２５１１３０５２２３ｊｐ．ｘｘｘｘｘｘ」が設定されている。
次に、請求書情報を説明する。

図１０は、請求書情報入力画面の一例を説明する図である。
図１０に示す請求書情報入力画面２３は、例えば端末装置２０ａに接続されたモニタ２２に表示される。
請求書情報入力画面２３には、宛先（会社名）、請求書発行日付、請求内容、請求金額、振込指定口座、および指定口座番号・名義の欄が設けられている。また、請求書情報入力画面２３には、送信ボタン２３ａ、および中止ボタン２３ｂが表示される。
宛先（会社名）の欄には、宛先の会社名が入力される。
請求書発行日付の欄には、請求書を発行した日付が手動または自動で入力される。
請求内容の欄には、請求書を発行する対象の物品やサービスが入力される。
請求金額の欄には、請求金額（総額）が入力される。
振込指定口座の欄には、請求書情報を入力するユーザが、入金を希望する口座の銀行名および支店名が入力される。
指定口座番号・名義の欄には、請求書情報を入力するユーザが、入金を希望する口座の口座番号および名義が入力される。

なお、図１０には図示していないが、会社固有の請求書番号を入力する欄や、取引区分を入力する欄や、請求書に対応する見積書の番号を入力する欄や、単価を入力する欄が設けられていてもよい。

ユーザにより送信ボタン２３ａが押下されると、端末装置２０ａは、請求書情報を請求書情報を作成したユーザのＥｍａｉｌアドレスとともに情報処理装置１０に送信する。請求書処理部１３は、受信した請求書情報を請求書情報記憶部１４に書き込む。

図１１および図１２は、請求書情報記憶部に記憶される情報の一例を示す図である。
本実施の形態では請求書情報がテーブル化されて記憶されている。請求書情報管理テーブルＴ２には、管理番号、請求書情報番号、請求書宛先、宛先、住所、請求内容、請求金額、振込指定口座、指定口座番号・名義、ユーザ所在地情報、ユーザ所在地（緯度）およびユーザ所在地（経度）の欄が設けられている。横方向に並べられた情報同士が互いに関連づけられている。

管理番号の欄には、請求元のユーザと請求先のユーザを識別する情報が設定される。図１１および図１２には、ユーザ管理番号Ａ４のユーザが、ユーザ管理番号Ａｇ３、Ｂ３、Ｂｇ４、Ｃ３、Ｃ５、Ｃ６のユーザに対し請求書を作成した場合の請求書情報が図示されている。
請求書情報番号の欄には、請求書情報を識別する番号が設定される。
請求書宛先の欄には、請求書情報入力画面２３の請求先会社担当Ｅｍａｉｌアドレスに入力されたＥｍａｉｌアドレスが設定される。
宛先、請求内容、請求金額、振込指定口座、指定口座番号・名義の欄には、請求書情報入力画面２３にて入力された情報が設定される。

住所、ユーザ所在地情報、ユーザ所在地（緯度）およびユーザ所在地（経度）の欄には、請求書情報を作成したユーザのユーザ情報管理テーブルＴ１に設定されている情報が設定される。この処理は請求書処理部１３が、請求書情報を作成するためにユーザが請求書処理システムにログインするために入力したＥｍａｉｌアドレスからユーザ情報を特定する。そして、特定したユーザ情報を、請求書情報管理テーブルＴ２の各欄に設定する。

請求書処理部１３は、請求書情報が端末装置から送られてくると、請求元のユーザ情報と請求先のユーザ情報を関連づけておく。なお、関連づける方法としては、例えば実際にこれらを関連づけた情報をユーザ情報、請求書情報とは別個に作成して請求書情報記憶部１４に記憶するようにしてもよいし、別の例では、請求元のユーザのユーザ管理番号と請求先のユーザ管理番号同士を互いに関連づけた情報を請求書情報記憶部１４に記憶するようにしてもよい。

図１３〜図２０は、請求元のユーザ情報と請求先のユーザ情報の関連づけの一例を説明する図である。図１３〜図２０には、図１１および図１２にて示した請求書情報に対応する請求元のユーザ情報と請求先のユーザ情報が関連づけられた請求元ユーザ情報管理テーブルＴ３および請求先ユーザ情報管理テーブルＴ４を図示している。

図１３、図１４、図１５および図１６に示す請求元ユーザ情報管理テーブルＴ３は、請求元であるユーザ管理番号Ａ４のユーザのユーザ情報が、発行した請求書情報の数だけ図示されている。そして、図１７、図１８、図１９および図２０に示す請求先ユーザ情報管理テーブルＴ４は、請求先のユーザ管理番号Ａｇ３、Ｂ３、Ｂｇ４、Ｃ３、Ｃ５、Ｃ６のユーザ情報が発行した請求書情報の数だけ図示されている。

次に、共有者登録処理について説明する。共有者登録処理を実行することにより、汎用企業グループコードが同じユーザの範囲内で請求書情報の共有（閲覧等）が可能となる。

図２１は、共有依頼入力画面の一例を説明する図である。
図２１に示す共有依頼入力画面２４は、例えば端末装置２０ａに接続されたモニタ２２に表示される。共有依頼入力画面２４には、請求書情報共有者メールアドレスの欄が設けられている。この欄には、請求書情報の共有を希望する共有先のユーザ（以下、共有対象者と言う）のＥｍａｉｌアドレス（ユーザ特定情報）が、ユーザの操作により入力される。なお、ユーザを特定する情報は、メールアドレスに限定されない。図２１には、ユーザ管理番号Ｃ２が割り当てられているユーザがユーザ管理番号Ｃ３、Ｃ４、Ｃ５、Ｃ６が割り当てられているユーザと請求書情報の共有を希望する場合の例を示している。

ユーザの操作により送信ボタン２４ａが押下されると、端末装置２０ａは、共有者登録依頼情報を情報処理装置１０に送信する。この共有者登録依頼情報には、請求書情報共有者メールアドレスの欄に入力された各Ｅｍａｉｌアドレスを、ユーザ管理番号Ｃ２が割り当てられているユーザのＥｍａｉｌアドレスに関連づけられた情報が含まれている。

登録処理部１２は、請求書情報共有者メールアドレスの欄に入力されたＥｍａｉｌアドレスが端末装置２０ａから送られてくると、これらのＥｍａｉｌアドレス宛にユーザ管理番号Ｃ２のユーザを共有者として承認してよいか否かのＥｍａｉｌ（承認依頼メール）を送信する。

ところで、承認依頼メールを受信した共有依頼者が、ユーザ管理番号Ｃ２が割り当てられているユーザとの請求書情報の共有を承認する場合、承認依頼メールに含まれる共有者としての登録を承認するチェックボックス（図示せず）にチェックを入れる。そして、承認依頼メールを返信する。これにより、登録処理部１２が承認依頼メールの返信を受け取ると、登録処理部１２は、共有対象者のＥｍａｉｌアドレスをユーザ情報管理部分Ｄ２の社内共有者の欄に設定する。

図２２は、共有者の登録を説明する図である。
図２２に示すユーザ情報管理部分Ｄ２に示すように、データの共有を許可したユーザを登録することにより、そのユーザも共有許可者のデータへアクセスすることができる。例えば、図２２に示すユーザ情報は、斉藤２郎さんが作成した請求書情報は、その共有を許可した斉藤３郎、斉藤４郎、斉藤５郎、斉藤６郎さんもアクセスすることができる（請求書情報控えとしてデータを見ることが可能）。
次に、登録処理部１２の処理をフローチャートを用いて説明する。

図２３は登録処理部の処理を示すフローチャートである。
［ステップＳ１］ 登録処理部１２は、各端末装置から送られてくるユーザ情報を受け付ける。その後ステップＳ２に遷移する。
［ステップＳ２］ 登録処理部１２は、ステップＳ１にて受け付けたユーザ情報に含まれる国名を抽出し、ユーザ情報管理テーブルＴ１に設定する。その後、ステップＳ３に遷移する。

［ステップＳ３］ 登録処理部１２は、ユーザ情報を受け付けた日付をユーザ情報管理テーブルＴ１のユーザ開始年月日に設定する。その後、ステップＳ４に遷移する。

［ステップＳ４］ 登録処理部１２は、ユーザ情報に含まれるＥｍａｉｌアドレスに基づいてＥｍａｉｌドメインを抽出し、ユーザ情報管理テーブルＴ１に設定する。その後、ステップＳ５に遷移する。

［ステップＳ５］ 登録処理部１２は、ユーザ情報に含まれるユーザ所在地に基づき、ユーザ所在地情報を生成し、ユーザ情報管理テーブルＴ１に設定する。その後、ステップＳ６に遷移する。

［ステップＳ６］ 登録処理部１２は、ユーザ情報に含まれる本社所在地に基づき、本社位置情報を生成し、ユーザ情報管理テーブルＴ１に設定する。その後、ステップＳ７に遷移する。

［ステップＳ７］ 登録処理部１２は、前述した方法を用いて汎用企業グループコードを発番し、ユーザ情報管理テーブルＴ１に設定する。その後、ステップＳ８に遷移する。

［ステップＳ８］ 登録処理部１２は、前述した方法を用いて汎用企業コードを発番し、ユーザ情報管理テーブルＴ１に設定する。その後、ステップＳ９に遷移する。
［ステップＳ９］ 登録処理部１２は、ユーザＩＤおよびパスワードを発行する。その後、ステップＳ１０に遷移する。

［ステップＳ１０］ 登録処理部１２は、ユーザ情報に含まれるＥｍａｉｌアドレス宛に、ステップＳ９にて発行したユーザＩＤおよびパスワードを送信する。その後、図２３に示す処理を終了する。

次に、共有者登録処理を説明する。以下の説明ではユーザＡ１が端末装置２０ａを用いて共有者登録依頼情報を作成し、情報処理装置１０に送信した場合の処理を説明する。

図２４は、共有者登録処理を示すフローチャートである。
［ステップＳ２１］ 登録処理部１２は、ユーザＡ１が送信した共有者登録依頼情報を受け付ける。その後、ステップＳ２２に遷移する。
［ステップＳ２２］ 登録処理部１２は、ユーザ情報管理テーブルＴ１のＥｍａｉｌの欄を参照する。そして、登録処理部１２は、ステップＳ２１にて受け付けた共有者登録依頼情報に含まれるＥｍａｉｌアドレスに一致するＥｍａｉｌアドレスが、Ｅｍａｉｌの欄に存在するか否かを判断する。共有者登録依頼情報に含まれるＥｍａｉｌアドレスに一致するＥｍａｉｌアドレスが、Ｅｍａｉｌの欄に存在する場合（ステップＳ２２のＹｅｓ）、ステップＳ２３に遷移する。共有者登録依頼情報に含まれるＥｍａｉｌアドレスに一致するＥｍａｉｌアドレスが、Ｅｍａｉｌの欄に存在しない場合（ステップＳ２２のＮｏ）、ステップＳ２５に遷移する。

［ステップＳ２３］ 登録処理部１２は、ユーザ情報管理テーブルＴ１の汎用企業グループコードの欄を参照する。そして、登録処理部１２は、共有者登録依頼情報に含まれるＥｍａｉｌアドレスに関連づけられている汎用企業グループコードが、ユーザＡ１の汎用企業グループコードに一致するか否かを判断する。共有者登録依頼情報に含まれるＥｍａｉｌアドレスに関連づけられている汎用企業グループコードが、ユーザＡ１の汎用企業グループコードに一致する場合（ステップＳ２３のＹｅｓ）、ステップＳ２４に遷移する。共有者登録依頼情報に含まれるＥｍａｉｌアドレスに関連づけられている汎用企業グループコードが、ユーザＡ１の汎用企業グループコードに一致しない場合（ステップＳ２３のＮｏ）、ステップＳ２５に遷移する。

［ステップＳ２４］ 登録処理部１２は、共有者登録依頼情報に含まれるＥｍａｉｌアドレスを宛先とする承認依頼メールを送信する。この承認依頼メールには、例えば共有者としての登録を承認するか否かのチェックボックスが含まれる。その後、図２４に示す処理を終了する。

［ステップＳ２５］ 登録処理部１２は、ユーザＡ１のＥｍａｉｌアドレスを宛先とするエラー通知メールを送信する。エラー通知メールには、共有者の登録ができなかった旨の情報および解決方法を示す情報が含まれる。例えば、ステップＳ２２の処理にて共有者登録依頼情報に含まれるＥｍａｉｌアドレスに一致するＥｍａｉｌアドレスが、ユーザ情報管理テーブルＴ１のＥｍａｉｌの欄に存在しない場合にはその旨を通知し、共有者のユーザ登録を行うことで問題が解決することを併せて記述する。

ところで、前述したように、承認依頼メールを受信した共有対象者が、ユーザＡ１との請求書情報の共有を承認する場合、承認依頼メールに含まれる共有者としての登録を承認するチェックボックスにチェックを入れる。そして、承認依頼メールを返信する。これにより、登録処理部１２が承認依頼メールの返信を受け取ると、ユーザＡ１のユーザ情報管理部分Ｄ２の社内共有者の欄に共有対象者のＥｍａｉｌアドレスを設定する。また、共有対象者のユーザ情報管理部分Ｄ２の社内共有者の欄にユーザＡ１のＥｍａｉｌアドレスを設定する。

なお、本実施の形態では相互承認をする場合を例に説明したが、例えば共有対象者のユーザ情報管理部分Ｄ２の社内共有者の欄にユーザＡ１のＥｍａｉｌアドレスを設定し、ユーザＡ１のユーザ情報管理部分Ｄ２の社内共有者の欄に共有対象者のＥｍａｉｌアドレスを設定しないという処理を行うこともできる。これにより、例えばユーザＡ１は、共有者が作成した請求書情報を閲覧できるが、共有者はユーザＡ１が作成した請求書情報は閲覧できないというような処理を実行させることができる。
次に、請求書情報を情報処理装置１０に登録する処理を説明する。
以下の説明では請求書情報を送信したユーザを「請求元のユーザ」と言い、請求書情報を受け付けるユーザを「請求先のユーザ」と言う。

請求書情報を情報処理装置１０に登録する場合、１つずつ個別に登録する処理（個別登録処理）と、複数の請求書情報を一括して登録する処理（一括登録処理）がある。以下、順番に説明する。
図２５は、請求書情報の個別登録処理を説明するフローチャートである。
［ステップＳ３１］ 請求書処理部１３は、端末装置が送信した請求書情報を受信する。その後、ステップＳ３２に遷移する。

［ステップＳ３２］ 請求書処理部１３は、ステップＳ３１にて受け付けた請求書情報に含まれる請求先のユーザのＥｍａｉｌアドレスと宛先住所の組み合わせが、請求書情報に含まれる請求先のユーザのＥｍａｉｌアドレスにより特定される登録情報の宛先住所との組み合わせに一致するか否かを判断する。一致する場合（ステップＳ３２のＹｅｓ）、ステップＳ３３に遷移する。一致しない場合（ステップＳ３２のＮｏ）、ステップＳ３６に遷移する。

［ステップＳ３３］ 請求書処理部１３は、ステップＳ３１にて受け付けた請求書情報にユーザ情報管理テーブルＴ１に記憶されている請求元のユーザのユーザ情報と請求先のユーザのユーザ情報および生成情報を関連づける。その後、ステップＳ３４に遷移する。

［ステップＳ３４］ 請求書処理部１３は、請求書情報に含まれる銀行名の銀行のシステムに接続することで、ステップＳ３１にて受け付けた請求書情報に含まれる振込指定口座が存在するか、名義が一致するかをチェックする。その後、ステップＳ３５に遷移する。

［ステップＳ３５］ 請求書処理部１３は、ステップＳ３３にて請求元のユーザのユーザ情報と請求先のユーザのユーザ情報が付加された請求書情報を請求書情報記憶部１４に書き込む。その後、図２５の処理を終了する。

［ステップＳ３６］ 請求書処理部１３は、ステップＳ３１にて受け付けた請求書情報に含まれる請求先のユーザのＥｍａｉｌアドレスを宛先とするＥｍａｉｌを送信する。Ｅｍａｉｌの本文には新たなユーザに連絡を依頼する内容を記載する。その後、図２５の処理を終了する。

図２５に示す処理を情報処理装置１０が実行することにより、請求元のユーザおよび請求先のユーザは、請求書処理システムにログインすることで請求書情報にアクセスすることが可能となる。
次に、請求書情報を一括して登録するときの処理を説明する。
図２６は、請求書情報の一括登録処理を説明するフローチャートである。
［ステップＳ４１］ 請求書処理部１３は、請求書情報を一括して受け付ける。その後、ステップＳ４２に遷移する。

［ステップＳ４２］ 請求書処理部１３は、ステップＳ４１にて受け付けた請求書情報に請求元のユーザのユーザ情報と請求先のユーザのユーザ情報を付加する。その後、ステップＳ４３に遷移する。

［ステップＳ４３］ 請求書処理部１３は、請求書情報に含まれる銀行名の銀行のシステムに接続することで、請求書情報に含まれる振込指定口座が存在するか、名義が一致するかをチェックする。チェックが終了すると、図２６に示す処理を終了する。
次に、ステップＳ４３の処理（チェック処理）を詳しく説明する。
図２７は、チェック処理を説明するフローチャートである。

［ステップＳ４３ａ］ 請求書処理部１３は、請求書情報に含まれる請求先のユーザのＥｍａｉｌアドレスが、ユーザ情報管理テーブルＴ１の登録情報に存在するか否かを判断する。請求書情報に含まれる請求先のユーザのＥｍａｉｌアドレスが、ユーザ情報管理テーブルＴ１の登録情報に存在する場合（ステップＳ４３ａのＹｅｓ）、ステップＳ４３ｂに遷移する。請求書情報に含まれる請求先のユーザのＥｍａｉｌアドレスが、ユーザ情報管理テーブルＴ１の登録情報に存在しない場合（ステップＳ４３ａのＮｏ）、ステップＳ４３ｈに遷移する。

［ステップＳ４３ｂ］ 請求書処理部１３は、ステップＳ４１にて受け付けた請求書情報に含まれる請求先のユーザのＥｍａｉｌアドレスと宛先住所の組み合わせが、請求書情報に含まれる請求先のユーザのＥｍａｉｌアドレスにより特定される登録情報の宛先住所との組み合わせに一致するか否かを判断する。一致する場合（ステップＳ４３ｂのＹｅｓ）、ステップＳ４３ｃに遷移する。一致しない場合（ステップＳ４３ｂのＮｏ）、ステップＳ４３ｇに遷移する。

［ステップＳ４３ｃ］ 請求書処理部１３は、請求書情報の全ての入力必須項目に情報が記載されているか否かを判断する。請求書情報の全ての入力必須項目に情報が記載されている場合（ステップＳ４３ｃのＹｅｓ）、ステップＳ４３ｄに遷移する。請求書情報の全ての入力必須項目に情報が記載されていない場合、すなわち、請求書情報の入力必須項目に空欄が存在する場合（ステップＳ４３ｃのＮｏ）、ステップＳ４３ｇに遷移する。

［ステップＳ４３ｄ］ 請求書処理部１３は、請求書情報に含まれる銀行名の銀行のシステムに接続することで、ステップＳ４１にて受け付けた請求書情報に含まれる振込指定口座が存在するか否かを判断する。請求書情報に含まれる振込指定口座が存在する場合（ステップＳ４３ｄのＹｅｓ）、ステップＳ４３ｅに遷移する。請求書情報に含まれる振込指定口座が存在しない場合（ステップＳ４３ｄのＮｏ）、

［ステップＳ４３ｅ］ 請求書処理部１３は、、名義が一致するかをチェックする。名義が一致する場合（ステップＳ４３ｅのＹｅｓ）、ステップＳ４３ｆに遷移する。名義が一致しない場合（ステップＳ４３ｅのＮｏ）、ステップＳ４３ｇに遷移する。

［ステップＳ４３ｆ］ 登録処理部１２は、ステップＳ４１にて請求元のユーザのユーザ情報と請求先のユーザのユーザ情報が付加された請求書情報を請求書情報記憶部１４に書き込む。その後、図２７の処理を終了する。

［ステップＳ４３ｇ］ 請求書処理部１３は、ユーザＡ１のＥｍａｉｌアドレスを宛先とするエラー通知メールを送信する。エラー通知メールには、共有者の登録ができなかった旨の情報および解決方法を示す情報が含まれる。例えば、ステップＳ２２の処理にて共有者登録依頼情報に含まれるＥｍａｉｌアドレスに一致するＥｍａｉｌアドレスが、Ｅｍａｉｌの欄に存在しない場合にはその旨を通知し、共有者のユーザ登録を行うことで問題が解決することを併せて記述する。

［ステップＳ４３ｈ］ 請求書処理部１３は、ステップＳ４１にて受け付けた請求書情報に含まれる請求先のユーザのＥｍａｉｌアドレスを宛先とするＥｍａｉｌを送信する。Ｅｍａｉｌの本文には例えば請求書処理システムにユーザ登録を希望する旨を記載する。その後、図２７の処理を終了する。

ところで、請求先のユーザは、端末装置を操作することにより、請求書情報の登録処理によって請求書情報記憶部１４に記憶された請求書情報を受信し、検収する処理を行うことができる。

請求先のユーザは、請求書情報の各項目を確認後、内容に誤りが無い場合、ＷＥＢ上で検収する。他方、内容に誤りを発見した場合、誤りの項目の修正を依頼するＥｍａｉｌ（項目修正依頼メール）を請求元のユーザ宛に送信する。例えば、ＷＥＢ上の画面上に誤りの項目を指摘するチェックボックスがあり、誤りの項目のチェックボックスにチェックを入れ、修正依頼のボタンを押下することにより、端末装置が請求元のユーザのＥｍａｉｌアドレスを宛先とする項目修正依頼メールを作成し、送信する。

項目修正依頼メールを受信した請求元のユーザが項目を修正する際には、請求書処理システムにログインする。その後、モニタに表示される修正画面にて、指摘された誤りの項目を修正する。その後、修正完了のボタンを押下することにより、端末装置が請求先のＥｍａｉｌアドレスを宛先とする項目修正依頼メールを作成し、送信する。
次に、請求書情報共有処理を、フローチャートを用いて説明する。
図２８は、請求書情報共有処理を説明する図である。なお、図２８の処理の順番は時系列を示すものではない。

［ステップＳ５１］ ユーザＡ１により共有依頼入力画面２４にて請求書情報の共有を希望する共有対象者のＥｍａｉｌアドレスが記載され、送信ボタン２４ａが押下されると端末装置２０ａは、共有対象者のＥｍａｉｌアドレスを含む共有者登録依頼情報を送信する。

［ステップＳ５２］ 登録処理部１２は、共有者登録依頼情報を受信すると、ユーザ情報管理テーブルＴ１のＥｍａｉｌの欄を参照し、共有対象者がユーザ登録されているか否かを判断する。具体的には、共有対象者のＥｍａｉｌアドレスがＥｍａｉｌの欄に登録されているか否かを判断する。共有対象者のＥｍａｉｌアドレスがＥｍａｉｌの欄に登録されている場合、すなわち、共有対象者がユーザ登録されている場合（ステップＳ５２のＹｅｓ）、ステップＳ５３に遷移する。共有対象者のＥｍａｉｌアドレスがＥｍａｉｌの欄に登録されていない場合、すなわち、共有対象者がユーザ登録されていない場合（ステップＳ５２のＮｏ）、ステップＳ６０に遷移する。

［ステップＳ５３］ 登録処理部１２は、ユーザ情報管理テーブルＴ１の汎用企業グループコードの欄を参照し、共有対象者の汎用企業グループコードがユーザＡ１の汎用企業グループコードに一致するか否かを判断する。共有対象者の汎用企業グループコードがユーザＡ１の汎用企業グループコードに一致する場合（ステップＳ５３のＹｅｓ）、ステップＳ５４に遷移する。共有者の汎用企業グループコードがユーザＡ１の汎用企業グループコードに一致しない場合（ステップＳ５３のＮｏ）、ステップＳ５８に遷移する。

［ステップＳ５４］ 登録処理部１２は、共有対象者に承認依頼を通知するＥｍａｉｌ（共有承認依頼メール）を共有対象者のＥｍａｉｌアドレスを宛先として送信する。
［ステップＳ５５］ 端末装置２０ｂは、共有者承認依頼メールを受信する。

［ステップＳ５６］ 共有対象者により請求書処理システムへのログイン処理が実行されると、端末装置２０ｂは、共有者承認画面（図示せず）をＷＥＢブラウザ上に表示する。共有者承認画面には例えば、共有者としての承認を受諾するチェックボックスがある。共有者によりチェックボックスがチェックされ、送信ボタンを押下することにより、端末装置２０ｂが共有対象者のＥｍａｉｌアドレスを含む共有者承認情報を情報処理装置１０に応答する。その後、ステップＳ５７に遷移する。

［ステップＳ５７］ 登録処理部１２は、ユーザ情報管理テーブルＴ１における社内共有者の欄に本ステップＳ５７にて受け付けた共有者承認情報に含まれる共有対象者のＥｍａｉｌアドレスを設定する。これにより、ユーザＡ１が共有者が作成した請求書情報へアクセスすることが可能となる。

［ステップＳ５８］ 登録処理部１２は、ユーザＡ１のＥｍａｉｌアドレスを宛先とするエラー通知メールを送信する。エラー通知メールには、共有者の登録ができなかった旨の情報およびその理由を示す情報が含まれる。例えば、ステップＳ５２の処理にて共有者の汎用企業コードがユーザＡ１の汎用企業コードに一致しない場合にはその旨を通知する。
［ステップＳ５９］ 端末装置２０ａは、エラー通知メールを受信する。

［ステップＳ６０］ 登録処理部１２は、共有対象者のＥｍａｉｌアドレスを宛先とするユーザ登録依頼通知メールを送信する。ユーザ登録依頼通知メールには、ユーザＡ１から共有対象者への登録を促す情報および登録画面のＵＲＬが含まれる。

［ステップＳ６１］ 端末装置２０ｂは、ユーザ登録依頼通知メールを受信する。これにより、共有対象者によりユーザ登録が行われ、共有対象者が請求書処理システムにログインすると、登録処理部１２は、ステップＳ５３以降の処理を実行する。以上で図２８の説明を終了する。
次に、振込処理を説明する。
図２９は、振込処理を説明する図である。
［ステップＳ７１］ 端末装置２０ｂは、請求先のユーザＢ１がＢ社に関する請求書情報にアクセスし、検収したことを情報処理装置１０に通知する。

［ステップＳ７２］ 振込処理部１３ｂは、ステップＳ７１にて検収された請求書情報を用いて支払期日、支払い予定金額、支払い手数料、支払い予定明細書を作成する。ここで、支払金額、支払手数料は、振込先の口座番号毎にとりまとめられた金額とする。とりまとめる請求書情報の範囲としては例えば、（１）支払期日が一定期間内（例えば支払い期日が７月２４日〜７月３１日まで）というものをとりまとめて処理する方法や、（２）支払期日が完全同一なものをとりまとめて処理する方法等が挙げられる。その後、ステップＳ７３に遷移する。

［ステップＳ７３］ 振込処理部１３ｂは、ユーザＢ１のＥｍａｉｌアドレスを宛先とする支払い内容確認メールを作成する。この支払い内容確認メールには、後述する支払い内容確認画面にアクセスできるＵＲＬが含まれる。

［ステップＳ７４］ 端末装置２０ｂは、支払い内容確認メールを受信する。ユーザにより、支払い内容確認メールに含まれるＵＲＬへのリンクがクリックされると、端末装置２０ｂは、支払い内容確認画面をＷＥＢブラウザ上に表示する。
図３０は、支払い内容確認画面の一例を示す図である。

支払い内容確認画面２５には、例えば支払先企業名、支払期日、支払金額、支払手数料、支払明細、振込指定口座等が表示される。ここで、支払金額、支払手数料は、振込先の口座番号毎にとりまとめられた金額が表示される。支払明細には、例えば個々の請求の内訳などが表示される。振込指定口座には、請求書情報に含まれる、個々のユーザが指定した振込指定口座の口座番号の代わりに情報処理装置１０の管理者が情報処理装置１０に予め記憶させておいた口座番号が表示される。
支払い内容確認画面２５には、承認ボタン２５ａ、修正ボタン２５ｂ、却下ボタン２５ｃが表示される。
また、支払い内容確認画面２５の左上には支払先企業毎にタブに番号が割り振られている。

［ステップＳ７５］ ユーザＢ１により承認ボタン２５ａ、修正ボタン２５ｂ、却下ボタン２５ｃのうち、いずれかのボタンが押下されると、端末装置２０ｂがその旨を情報処理装置１０に応答する。

［ステップＳ７６］ 振込処理部１３ｂは、受信した応答の種別が承認か修正か却下かを判断する。受信した応答の種別が承認である場合（ステップＳ７６の承認）、ステップＳ７７に遷移する。受信した応答の種別が修正である場合（ステップＳ７６の修正）、ステップＳ８２に遷移する。受信した応答の種別が却下である場合（ステップＳ７６の却下）、ステップＳ８４に遷移する。

［ステップＳ７７］ 振込処理部１３ｂは、定期的に口座にアクセスし、入金を待機する。入金があれば（ステップＳ７７のＹｅｓ）、ステップＳ７８に遷移する。

［ステップＳ７８］ 振込処理部１３ｂは、請求元のユーザのＥｍａｉｌアドレスを宛先とする振込明細のメール（振込明細メール）を作成する。この振込明細メールには、振込明細画面へのＵＲＬが含まれる。その後、ステップＳ７９に遷移する。

端末装置２０ａは、振込明細メールを受信する。請求元のユーザにより、振込明細メールに含まれるＵＲＬへのリンクがクリックされると、端末装置２０ｂは、振込明細画面をＷＥＢブラウザ上に表示する。振込明細画面には例えば、振込予定金額、振込予定口座番号等が表示される。これらの情報は、振込処理部１３ｂが請求元のユーザが作成した請求書情報に基づき作成する。

また、支払い内容確認画面には、承認、修正ボタンが表示される。請求元のユーザは、表示された内容でよければ承認ボタンを押下する。内容の修正を行う場合は、振込予定口座番号の修正を行った上で修正ボタンを押下する。請求元のユーザにより、承認、修正のいずれかのボタンが押下されると、端末装置２０ｂがその旨を情報処理装置１０に応答する。

［ステップＳ７９］ 振込処理部１３ｂは、受信した応答の種別が承認か修正かを判断する。受信した応答の種別が承認である場合（ステップＳ７９の承認）、ステップＳ８１に遷移する。受信した応答の種別が修正である場合（ステップＳ７９の修正）、ステップＳ８０に遷移する。
［ステップＳ８０］ 振込処理部１３ｂは、請求書情報に含まれる振込指定口座を修正する。その後、ステップＳ８１に遷移する。
［ステップＳ８１］ 振込処理部１３ｂは、請求書情報に含まれる振込指定口座に振込処理を実行する。
［ステップＳ８２］ 振込処理部１３ｂは、ユーザＢ１のＥｍａｉｌアドレスを宛先とする修正依頼メールを作成し、送信する。

［ステップＳ８３］ 振込処理部１３ｂは、修正依頼メールに対する応答があると、請求書情報を修正し、ユーザＢ１のＥｍａｉｌアドレスを宛先とする支払い内容確認メールを再度、作成し、送信する。その後、端末装置２０ｂからの応答があると、ステップＳ７６に遷移し、ステップＳ７６以降の処理を引き続き実行する。
［ステップＳ８４］ 振込処理部１３ｂは、請求元のユーザのＥｍａｉｌアドレスを宛先とする却下通知メールを作成し、送信する。
以上述べたように、情報処理装置１０によれば、共有者登録処理を実行することにより

、親会社が共通する会社全体の請求書を閲覧することが可能となる。これにより、複数の企業同士でやりとりされる請求書が１インターフェースの請求書情報として統合されたサービスを提供することができる。具体的には、請求先のユーザは、請求書をデータで、ＷＥＢ経由でくださいと簡単にいえる。そして頼まれた請求元のユーザも簡単にそれを受け入れることができる。
また、ユーザは、ユーザ登録後、すぐに請求書処理システムを利用可能である。
また、規模の大きい企業でも規模の小さい企業でも、個人事業主でも、だれもが共通のインタフェースで請求書のやり取りが可能となる。

また、ユーザ間でのやり取りがある程度増え、例えば、１社で数十名のユーザーが利用するような状況になってくると、数十名が様々な企業から請求データを受けていることになる。社内で利用しているユーザを検索し、そのユーザと情報を共有化できるシステムとすることで、もらったデータを一元管理（統合）可能である。
まずはユーザーがメール感覚で使い始め、その後に請求者を共有し、請求書情報を統合していくしくみなので、特定の管理者がいない状態でも運用可能である。
なお、図示していないが、情報処理装置１０は、ユーザ情報の更新を促すＥｍａｉｌを登録されている各ユーザ宛に送信するようにしてもよい。

また、情報処理装置１０の管理者は、ユーザ情報をメインテナンスする際に社名の英語表記に誤りがあることを発見した場合に、その誤りを該当するユーザのＥｍａｉｌアドレス宛に送信し、登録情報の修正を促すようにしてもよい。

また、Ｅｍａｉｌアドレスより抽出したドメインが一致するユーザ、または汎用企業グループコードが一致するユーザーの範囲内で、ユーザー所在地位置情報、共有者情報をもとにＥｍａｉｌの一斉送信先を決めるようにしてもよい。これにより、定期的に一斉メールを送信することにより、手入力している「英字会社名」が周りと異なるユーザーを、他のユーザーが発見し、ユーザー間で連絡しあうことで、手入力誤りの修正を促すことができる。

＜第２の実施の形態＞
次に、第２の実施の形態のシステムについて説明する。
以下、第２の実施の形態のシステムについて、第１の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。
図３１は、第２の実施の形態のユーザ情報管理部分に設定されている情報の一例を示す図である。

第１の実施の形態では、汎用企業コードの作成時に英字会社名を用いた。しかし、これに限らず、英字会社名の代わりに、行政手続における特定の個人を識別するための番号の利用等に関する法律第５８条により指定され、通知された法人番号（所謂法人版マイナンバー）を用いるようにしてもよい。

この場合は、ユーザにより法人番号を入力してもらい、図３１に示すように、ユーザ情報管理部分Ｄ２には、法人番号を記憶しておく。そして、第１の実施の形態と同様の方法を用いて汎用企業コードを作成する。すなわち、第２の実施の形態の汎用企業コードの欄には、汎用企業グループコードの欄に設定された値と、法人番号の欄に設定された値がこの順番に並べられた値が設定される。
さらに、第２の実施の形態では、法人番号が、汎用企業コードを兼ねるようにしてもよい。
さらに、第２の実施の形態では、個人または個人事業主に適用できるマイナンバーが、汎用企業コードを兼ねるようにしてもよい。
第２の実施の形態のシステムによれば、第１の実施の形態のシステムと同様の効果が得られる。

なお、情報処理装置１０が行った処理が、複数の装置によって分散処理されるようにしてもよい。例えば、１つの装置が、登録情報の登録処理までを行い、他の装置が、その登録情報を用いて振込処理を行うようにしてもよい。また、本実施の形態の処理方法にて用いることができる通貨は現に流通する通貨でもよいし、例えばビットコインやリップル等の仮想通貨でもよい。

以上、本発明の情報処理装置およびアクセス権限付与方法を、図示の実施の形態に基づいて説明したが、本発明はこれに限定されるものではなく、各部の構成は、同様の機能を有する任意の構成のものに置換することができる。また、本発明に、他の任意の構成物や工程が付加されていてもよい。
また、本発明は、前述した各実施の形態のうちの、任意の２以上の構成（特徴）を組み合わせたものであってもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、情報処理装置１０が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記憶装置には、ハードディスクドライブ、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷ等が挙げられる。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）等が挙げられる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）等の電子回路で実現することもできる。

また、請求書発行システムに領収書発行機能を追加しすることもできる。具体的には、レジスターでのお会計（精算）時に、タブレットに触れるだけで即座にレシートを送る（一例としてタブレットに触れて、確認ボタンを一度押す程度でレシートを送る処理を完了させる。２秒以内）。そのためには予めアプリケーション等で指紋、顔写真等をユーザに登録してもらう。そして、指紋を登録した場合なら店舗側が保有するタブレットに触れて、領収書の送り先の電子メールアドレスを表示させる。ユーザが、ＯＫボタンを押下することにより、レシートを送信完了させる。一方、顔写真の場合は、例えば顔認証により領収書の送り先の電子メールアドレスを表示させる。

レジスターでメールアドレスをお客さんに入力してもらい、そのメールアドレス宛に店員がレシートのデータを送る、ということをしてもよいが、メールアドレスをレジで入力する手間があるので現実的には困難である。
ユーザがタブレットに触れると、そのユーザの登録したメールアドレスが表示され、店員がそのメールアドレス宛に領収書データを送る（レシートの控えは店に残すようにする）。これにより、企業の経費精算でのレシート（＝請求書と同じ扱い）を取り込むことになる。特に大企業で大きなニーズがある。

１ システム
１０ 情報処理装置
１１ ユーザ情報記憶部
１２ 登録処理部
１３ 請求書処理部
１３ａ 通知部
１３ｂ 振込処理部
１４ 請求書情報記憶部
２０ａ、２０ｂ、２０ｃ 端末装置
２１ ユーザ情報入力画面
２２ モニタ
２３ 請求書情報入力画面
２４ 共有依頼入力画面
Ｄ１ 管理番号部分
Ｄ２ ユーザ情報管理部分
Ｄ３ 生成情報管理部分
Ｔ１ ユーザ情報管理テーブル
Ｔ２ 請求書情報管理テーブル
Ｔ３ 請求元ユーザ情報管理テーブル
Ｔ４ 請求先ユーザ情報管理テーブル

Claims (6)

1. ユーザを特定するユーザ特定情報と少なくとも１つの位置を特定する固有の情報とをユーザ毎に関連づけたユーザ情報を記憶する第１の記憶部と、
   前記第１の記憶部に記憶される前記固有の情報とユーザ特定情報とを用いて所定の規則に基づきユーザ毎にコードを生成する生成部と、
   前記第１の記憶部に記憶されているユーザ情報が備える第１のユーザのユーザ特定情報を含むビジネス文書情報を記憶する第２の記憶部と、
   前記第１の記憶部にユーザ情報が記憶されている第２のユーザからの前記ビジネス文書情報へのアクセス要求を受け付けると、前記第１のユーザの第１のコードと、前記第２のユーザの第２のコードが一致するか否かを判断し、前記第１のコードと前記第２のコードとが一致する場合、前記第２の記憶部に記憶されている第１のユーザが作成したビジネス文書情報へのアクセス権限を前記第２のユーザに付与する処理部と、
   を備えることを特徴とする情報処理装置。
2. 前記ユーザ特定情報は、電子メールアドレスであり、前記ビジネス文書情報は、ビジネス文書の送付先のユーザの電子メールアドレスおよび発行元のユーザの電子メールアドレスを含み、
   前記処理部は、前記ビジネス文書情報に含まれる電子メールアドレスに基づきビジネス文書の送付先のユーザに関連づけられているコードを特定してビジネス文書情報に特定したコードを関連づけて記憶し、
   ビジネス文書の送付先のユーザの電子メールアドレスを含むビジネス文書の閲覧要求を受け付けると、前記閲覧要求に含まれる電子メールアドレスに基づきビジネス文書の送付先のユーザに関連づけられているコードを特定し、特定したコードに一致するコードが関連づけられているビジネス文書情報をとりまとめて前記送付先のユーザに閲覧可能な状態とする請求項２に記載の情報処理装置。
3. 前記ビジネス文書は請求書であり、前記処理部は、特定したコードに一致するコードが関連づけられているビジネス文書情報に記載された請求金額を集計し、集計した金額を前記送付先のユーザに閲覧可能な状態とする請求項２に記載の情報処理装置。
4. 前記ビジネス文書情報は、発行元が指定する第１の口座番号を含み、
   前記処理部は、集計した金額を前記送付先のユーザに閲覧させるときに、第１の口座番号とは異なる第２の口座番号を振込先に指定し、
   前記第２の口座番号の口座に入金された金額を前記ビジネス文書情報に含まれる請求金額毎に前記第１の口座番号の口座に振り込む請求項２または３に記載の情報処理装置。
5. 前記処理部は、ビジネス文書の送付先のユーザが検収を終了したビジネス文書情報をとりまとめる請求項２に記載の情報処理装置。
6. コンピュータが、
   ユーザを特定するユーザ特定情報と少なくとも１つの位置を特定する固有の情報とをユーザ毎に関連づけたユーザ情報を記憶する第１の記憶部に記憶される前記固有の情報とユーザ特定情報とを用いて所定の規則に基づきユーザ毎にコードを生成し、
   前記第１の記憶部に記憶されているユーザ情報が備える第１のユーザのユーザ特定情報を含むビジネス文書情報へのアクセス要求を前記第１の記憶部にユーザ情報が記憶されている第２のユーザから受け付けると、前記第１のユーザの第１のコードと、前記第２のユーザの第２のコードが一致するか否かを判断し、前記第１のコードと前記第２のコードとが一致する場合、第１のユーザが作成したビジネス文書情報へのアクセス権限を前記第２のユーザに付与する、
   ことを特徴とするアクセス権限付与方法。

Images