(57)【要約】【課題】請求及び支払いに要する作業の簡易化を実現する。【解決手段】取引管理装置は、請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力部と、入力部に入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成部と、請求生成部によって生成された合計請求データを請求先に送信する送信部とを備える。【選択図】図２
2020071787.tif 000002
【特許請求の範囲】
【請求項１】
請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力部と、
前記入力部に入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成部と、
前記請求生成部によって生成された合計請求データを前記請求先に送信する送信部と、
を備える取引管理装置。
【請求項２】
前記送信部が前記合計請求データを送信した前記請求先のユーザから、希望の支払い方法の情報を含み、前記ユーザが支払いをするためのコードの生成を要求するコード生成リクエストを受信するリクエスト受信部と、
前記リクエスト受信部が受信したコード生成リクエストが含む支払い方法で用いるコードを生成するコード生成部と、
をさらに備え、
前記送信部は、前記コード生成部が生成したコードを前記請求先のユーザに送信する
請求項１に記載の取引管理装置。
【請求項３】
請求先ＩＤと、当該請求先ＩＤで識別されるユーザが予め希望する金銭の支払い方法とを関連づける支払い方法データを記憶する支払い方法データ記憶部と、
前記支払い方法データにおいて前記請求先ＩＤと関連づけられる支払い方法で用いるコードを生成するコード生成部とをさらに備え、
前記請求生成部は、前記コード生成部が生成したコードを含む合計請求データを生成する
請求項１に記載の取引管理装置。
【請求項４】
ユーザのIDと、当該ユーザの金銭の支払いに使用される金融情報とを関連付ける金融データを記憶する金融データ記憶部と、
前記請求生成部が生成した合計請求データに対して前記ユーザからの支払い指示を受け付ける受付部と、
前記金融データ記憶部から前記ユーザのユーザIDと関連付けられる金融情報を抽出し、前記受付部が受け付けた支払い指示に対して、支払いを実行する実行部と、
をさらに備える請求項１に記載の取引管理装置。
【請求項５】
ユーザのIDと、当該ユーザの収支に関するデータと、当該ユーザの貯蓄に関するデータとを含む家計簿データを記憶する家計簿データ記憶部と、
前記請求生成部で生成された前記合計請求データの支払いに関する情報を、追加して前記家計簿データを更新する更新部と、
をさらに備える請求項１乃至４に記載の取引管理装置。
【請求項６】
前記請求生成部は、前記送信部が前記合計請求データを送信後に請求先による支払いがされる前に、前記入力部に前記請求先に対する複数の新たな請求データが入力されると、当該複数の新たな請求データに含まれる請求金額を加算して第２の合計請求金額を求めるとともに、前記送信部が送信した前記合計請求金額と、求めた前記第２の合計請求金額とを加算して第３の合計請求金額を求め、前記第３の合計請求金額を含む新たな合計請求データを生成し、
前記送信部は、前記新たな合計請求データを前記請求先に送信する
請求項２乃至５のいずれか１に記載の取引管理装置。
【請求項７】
前記請求生成部は、請求に対する支払いに対して前記請求先のユーザに報酬として付与されるポイントの値を求めるとともに、求めたポイント値を含む合計請求データを生成し、
前記合計請求データで通知された請求に対して支払いが完了すると、前記請求先のユーザの請求先IDと、前記ポイント値を関連付けてポイントデータとしてポイントデータ記憶部に記憶させるポイント記憶処理部を
さらに備える請求項１乃至６のいずれか１に記載の取引管理装置。
【請求項８】
前記請求生成部は、前記合計請求データの送信時から前記請求先のユーザによる支払い時までの支払い所要期間に応じ、前記支払い所要期間が短い場合には長い場合と比較して高くなるように定められたポイント値を求め、
前記ポイント記憶処理部は、前記請求先IDと、前記支払い所要期間に対して求められたポイント値とを関連付けてポイントデータ記憶部に記憶させる
請求項７に記載の取引管理装置。
【請求項９】
請求先のユーザの請求先IDと、前記請求先のユーザの支払いの即答性を評価するスコア値とが関連付けられるスコアデータを記憶するスコアデータ記憶部と、
前記合計請求で通知された請求に対して支払いが完了すると、前記合計請求データの送信時から前記請求先のユーザによる支払い時までの支払い所要期間毎に設定される前記請求先のユーザを評価するスコア値の演算方法に応じて、当該支払い所要期間に対する前記請求先のユーザのスコア値を求め、求めた前記スコア値により、前記スコアデータを更新するスコア演算部と、
をさらに備える請求項１乃至８のいずれか１に記載の取引管理装置。
【請求項１０】
前記スコア演算部は、前記請求先のユーザによる前記合計請求データの確認時から、前記請求について未払い期間が所定期間以上経過すると、当該未払い期間に応じて設定される前記請求先のユーザを評価するスコア値の演算方法に応じて、当該未払い期間に対する前記請求先のユーザのスコア値を求め、求めた前記スコア値により、前記スコアデータを更新する
請求項９に記載の取引管理装置。
【請求項１１】
前記合計請求データの送信後、前記請求先のユーザによる支払いがされない未払い期間が所定期間以上経過したとき、前記請求先のユーザに対し、支払いのリマインドデータを送信するリマインド送信部
をさらに備える請求項１乃至１０のいずれか１に記載の取引管理装置。
【請求項１２】
前記リマインド送信部は、前記請求先のユーザによる前記合計請求データの確認時から、前記請求先のユーザによる支払いがされない未払い期間が所定期間以上経過すると、前記請求先のユーザに対し、支払いのリマインドデータを送信する
請求項１１に記載の取引管理装置。
【請求項１３】
前記入力部に入力される請求データは、金銭の支払いに関する請求に付与された請求IDをさらに含み、
前記請求先のユーザから、特定の請求IDと、先払い期間とを含み、当該請求IDで特定される請求に関する先払いを希望する先払いリクエストを受信すると、当該先払い期間における前記請求IDに関して支払う合計先払い金額を演算する先払い演算部をさらに備え、
前記請求生成部は、前記先払い演算部で演算された合計先払い金額を含む先払い請求データを生成する
請求項１乃至１２のいずれか１に記載の取引管理装置。
【請求項１４】
請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力ステップと、
前記入力ステップで入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成ステップと、
前記請求生成ステップにおいて生成された合計請求データを前記請求先に送信する送信ステップと、
を有する取引管理方法。
【請求項１５】
コンピュータに、
請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力機能と、
前記入力機能に入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成機能と、
前記請求生成機能によって生成された合計請求データを前記請求先に送信する送信機能と、
を実現させる取引管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、請求及び支払いの作業の簡易化を実現する取引管理装置、取引管理システム、取引管理方法及び取引管理プログラムに関する。
【背景技術】
【０００２】
一般的な日常生活において、公共料金の支払い、ローンの返済、家賃の支払い、クレジットカードの代金の支払い等の複数の請求が発生し、それぞれに対して支払いを実行する現状がある。この場合、各請求は異なるタイミングで発生するため、請求元から請求先には、これらの請求が異なるタイミングで到着する。また、各請求に関する通知方法も統一されていない。例えば、ある請求に対しては請求書が郵送されるが、別の請求については電子データ等で送信されることもある。
【０００３】
このように通知される請求は、通知のタイミングが異なり、請求先には別々に届くため、支払いを忘れたり、支払い遅れることがある。支払いが滞ると、請求元では請求先に再度通知をする必要が生じる。また、請求先は、複数の異なる請求について、忘れずに支払いをするためには、各請求が発生する度にその請求の通知に規定される方法で支払いをする必要がある。このように、従来の方法では、請求元にとっても、請求先にとっても手間を要する可能性がある。
【０００４】
これに対し、例えば、特許文献１では、複数の請求案件について一括して支払いをする技術が開示される。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−８３１２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１によると、同一の請求元からの複数の請求に関して一の請求として扱う場合の技術について考慮されたものである。したがって、特許文献１では、複数の請求元からの請求については別の請求として扱われる。このため、請求先ではすべての手間を軽減することができるものではない。
【０００７】
そこで、本発明は、請求及び支払いに要する作業の簡易化を実現する。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明に係る取引管理装置は、請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力部と、入力部に入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成部と、請求生成部によって生成された合計請求データを請求先に送信する送信部とを備える。
【発明の効果】
【０００９】
本発明によれば、同一の請求先に対する複数の請求をまとめた合計請求により請求先に請求することで、請求及び支払いに関する取引に要する作業の簡易化を実現する取引管理装置、取引管理システム、取引管理方法及び取引管理プログラムを提供することができる。
【図面の簡単な説明】
【００１０】
【図１】（ａ）は一般的な取引を説明する概念図であって、（ｂ）は本実施形態に係る取引管理システムを説明する概念図である。
【図２】第１実施形態に係る取引管理システムを説明するブロック図である。
【図３】（ａ）は第１実施形態に係る取引管理システムで利用されるユーザデータの請求データリストの一例を示すデータ構成図であって、（ｂ）はユーザデータの合計請求データリストの一例を示すデータ構成図ある。
【図４】第１実施形態に係る取引管理システムで利用される家計簿データの一例を示すデータ構成図である。
【図５】（ａ）は第１実施形態に係る取引管理システムで利用されるポイントデータの一例を示す構成図であって、（ｂ）は同取引管理システムで使用されるスコアデータの一例を示す構成図である。
【図６】（ａ）及び（ｂ）は第１実施形態に係る取引管理装置が送信するデータによりユーザ端末で表示される画面の一例である。
【図７】第１実施形態に係る取引管理システムにおける処理の一例を説明するシーケンス図である。
【図８】第１実施形態の変形例に係る取引管理システムにおける処理の一例を説明するシーケンス図である。
【図９】第２実施形態に係る取引管理システムを説明するブロック図である。
【図１０】第２実施形態に係る取引管理システムで利用される支払い方法データの一例を示すデータ構成図である。
【図１１】第２実施形態に係る取引管理システムにおける処理の一例を説明するシーケンス図である。
【図１２】第２実施形態の変形例に係る取引管理システムにおける処理の一例を説明するシーケンス図である。
【図１３】第３実施形態に係る取引管理システムを説明するブロック図である。
【図１４】第３実施形態に係る取引管理システムにおける処理の一例を説明するシーケンス図である。
【図１５】第３実施形態の変形例に係る取引管理システムにおける処理の一例を説明するシーケンス図である。
【発明を実施するための形態】
【００１１】
以下に、図面を用いて本発明に係る取引管理システム、取引管理装置、取引管理方法及び管理プログラムの実施の形態を説明する。なお、この実施の形態により本発明が限定されるものではない。
【００１２】
図１は、一般的な金銭の支払い及び本発明に係る取引管理システムを利用する金銭の支払いに関する取引を説明する概念図である。図１（ａ）に示すように、請求先のユーザには、様々な方法で請求が発生する。例えば、公共料金等については、郵便で請求書による請求Ａが届き、コンビニや銀行等で支払う場合がある。また、インターネットショッピング等では、発生する請求Ｂを、電子取引によるクレジットカードで支払う場合がある。さらに、ＳＮＳ等の電子データによる請求Ｃが届き、知人や友人に手渡しする場合もある。このように、ユーザは、複数の請求に対してそれぞれ異なる方法によって支払いを行う。
【００１３】
これに対し、本発明に係る取引管理システムでは、図１（ｂ）に示すように、複数の請求Ａ〜Ｃをまとめて合計請求とし、その合計請求に対してユーザが支払いをすることができる。これにより、ユーザは、複数の支払い行為を行う必要なく、１回の支払い行為により複数の請求Ａ〜Ｃに関するタスクを終了させることができる。
【００１４】
以下に、本発明の各実施形態に係る取引管理システム及び変形例について、図面を参照して説明する。以下の説明において、同一の構成又は同一の処理については同一の符号を用いて重複する説明を省略する。
【００１５】
〈第１実施形態〉
図２を用いて、第１実施形態に係る取引管理システム１について説明する。図２に示すように、第１実施形態に係る取引管理システム１では、取引管理装置１０と、請求者装置２０Ａ〜２０Ｃと、ユーザ端末２０とがネットワーク３０を介して接続される。この取引管理システム１では、複数の請求元のユーザの請求者装置２０Ａ〜２０Ｃからユーザ端末２０の保有者であるユーザへの複数の請求を取引管理装置１０において一つの合計請求としてまとめる。また、この合計請求のデータを請求先のユーザが保有するユーザ端末２０に送信する。これにより、請求先のユーザは、複数の請求を一つの請求として処理することができるため、ユーザの支払いに関する手続き複数回する必要がなくなり、支払い手続きを簡略化させることができる。
【００１６】
ここで、請求者装置２０Ａ〜２０Ｃは、請求元のユーザが使用する装置であって、請求データを生成し、取引管理装置１０に送信する。例えば、請求者装置２０Ａ〜２０Ｃは、パーソナルコンピューターや携帯端末等の情報処理装置である。なお、図２において、説明の便宜上、取引管理システム１でネットワーク３０に接続される請求者装置の数は３台であるが、これに限定されない。
【００１７】
また、ユーザ端末２０は、請求先のユーザが使用する装置であって、ユーザ端末２０は、取引管理装置１０から送信された請求データを受信する。例えば、パーソナルコンピューターや携帯端末等の情報処理装置である。なお、図２において、説明の便宜上、取引管理システム１でネットワーク３０に接続されるユーザ端末の数は１台であるが、これに限定されない。
【００１８】
ネットワーク３０は、有線でも無線でもよい。また、ネットワーク３０は、取引管理装置１０、請求者装置２０A〜２０C及びユーザ端末２０間でデータの送受信を実行することが可能であれば、その通信プロトコルは限定されない。
【００１９】
《取引管理装置》
図２に示すように、取引管理装置１０は、金銭の支払いに関する請求に付与された請求ＩＤと、当該請求の請求元のユーザを識別する請求元ＩＤと、請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力部１１１と、同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成部１１２と、請求生成部１１２によって生成された合計請求データを請求先に送信する送信部１１３とを有する。
【００２０】
また、取引管理装置１０は、リクエスト受信部１１４、コード生成部１１５、更新部１１６、ポイント記憶処理部１１７、スコア演算部１１８、リマインド送信部１１９及び先払い演算部１２０を備えてもよい。
【００２１】
この取引管理装置１０は、例えば、制御部１１、記憶部１２及び通信部１３を備えるサーバ等の情報処理装置である。取引管理装置１０は、記憶部１２に記憶される管理プログラムP１が実行されることで、制御部１１が入力部１１１、請求生成部１１２、送信部１１３、リクエスト受信部１１４、コード生成部１１５、更新部１１６、ポイント記憶処理部１１７、スコア演算部１１８、リマインド送信部１１９及び先払い演算部１２０としての処理を実行する。制御部１１は、中央処理装置（ＣＰＵ）である。記憶部１２は、ＲＡＭやＲＯＭ等のデータを記憶する記憶装置である。通信部１３は、ネットワーク３０を介して外部の装置とのデータの通信に利用される通信インターフェースである。また、取引管理装置１０は、操作ボタンやキーボード等のデータの入力に利用される入力部１４及びディスプレイやスピーカ等のデータの出力に利用される出力部１５を備えてもよい。
【００２２】
記憶部１２は、管理プログラムP１の他、ユーザデータＤ１、家計簿データＤ２、ポイントデータＤ３及びスコアデータＤ４を記憶する。図２において、取引管理装置１０は、１台の装置として図示されるが、これに限定されず、複数の装置で構成されてもよい。例えば、一部の処理が異なる装置で実行される構成であってもよいし、記憶部１２で記憶されるデータのうち一部が外部の記憶装置に記憶されてもよい。
【００２３】
ユーザデータＤ１は、例えば、図３（ａ）に示す『請求データリスト』と、図３（ｂ）に示す『合計請求データリスト』とを含むデータである。図３（ａ）に示すように、例えば、請求データリストでは、ユーザを識別する「ユーザＩＤ」、請求を識別する「請求ＩＤ」、請求の発生した日付である「請求日」、請求元を識別する「請求元ＩＤ」、請求に内容を特定する「請求項目」、請求の金額である「請求金額」を有するレコードを含むデータである。図３（ｂ）に示すように、合計請求データリストでは、ユーザを識別する「ユーザＩＤ」、請求を識別する「合計請求ＩＤ」、合計請求の発生した日付である「請求日」、合計請求の元となる複数の各請求を識別する「請求ＩＤ」、合計の請求金額である「合計請求金額」、この合計請求について支払い済であるか否かの「支払いタグ」、支払い済である場合に支払いがされた日付である「支払日」とを有するレコードを含むデータである。
【００２４】
図３（ａ）及び図３（ｂ）に示す例では、ユーザＡに対する「請求ＩＤ」Ｘ００１，Ｘ００３，Ｘ００５の請求を合計して、「合計請求ＩＤ」Ｙ００１の合計請求が生成されたことがわかる。
【００２５】
家計簿データＤ２は、ユーザのIDと、ユーザの収支に関するデータと、ユーザの貯蓄に関するデータとを含むである。具体的には、ユーザのＩＤに、ユーザに収入が発生した日付及びその金額と、ユーザの支出が発生した日付及びその金額と、ユーザの貯蓄額に関する情報を含むデータである。
【００２６】
家計簿データＤ２は、例えば、図４に示すように、金銭の変動が生じた日付である「日」、金銭の変動の原因の内容を特定する「項目」、収入の金額である「収入」、支出の金額である「支出」、変動後の合計の貯蓄金額である「合計」とを有するレコードを含むデータである。なお、図４において、図示されていないが、この家計簿データＤ２は、ユーザＩＤと関連付けられる。なお、図２に示す例では、家計簿データＤ２は、ユーザデータＤ１から独立しているが、ユーザデータに含まれてもよい。
【００２７】
ポイントデータＤ３は、請求先のユーザの請求先IDと、ポイント値とが関連付けられるデータである。ポイントデータＤ３は、図５（ａ）に示すように、ユーザを識別する「ユーザＩＤ」と、このユーザに付与された「ポイント値」とが関連づけられるデータである。この「ポイント値」は、例えば、金銭の支払い等に使用したり、商品との交換が可能な「ポイント」の値を特定するものである。なお、図２に示す例では、ポイントデータＤ３は、ユーザデータＤ１から独立しているが、ユーザデータＤ１に含まれてもよい。
【００２８】
スコアデータＤ４は、請求先のユーザの請求先IDと、請求先のユーザの支払いの即答性を評価するスコア値とが関連付けられるデータである。スコアデータＤ４は、図５（ｂ）に示すように、ユーザを識別する「ユーザＩＤ」と、このユーザに付与された「スコア値」とが関連づけられるデータである。この「スコア値」は、ユーザの請求に対する支払いを評価するものである。例えば、スコア値によって、請求後に直ちに支払いをするユーザであるのか、支払いの滞りが生じやすいユーザであるのかを評価することができる。具体的には、請求の発生から支払いまでの期間が短いと、請求の発生から支払いまでの期間が長いよりも高スコアとなるように設定することができる。なお、図２に示す例では、スコアデータＤ４は、ユーザデータＤ１から独立しているが、ユーザデータＤ１に含まれてもよい。
【００２９】
入力部１１１は、金銭の支払いに関する請求に付与された請求ＩＤと、当該請求の請求元のユーザを識別する請求元ＩＤと、請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される。この請求データは、請求者装置２０Ａ〜２０Ｃから送信されるデータである。また、入力部１１１は、入力された請求データを、ユーザデータD１の請求データリストに追加する。
【００３０】
請求生成部１１２は、同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する。すなわち各請求者装置２０Ａ〜２０Ｃから、ユーザ端末２０を利用するユーザに対する請求を受信したとき、請求生成部１１２は、これら複数の請求を合計して合計請求金額を求め、この合計請求金額を含む合計請求データを生成する。また、請求生成部１１２は、生成した合計請求データを、ユーザデータＤ１の合計請求データリストに追加する。
【００３１】
ここで、複数の請求データをまとめることで、例えば、通常は手渡しでしか支払いをしないような少額の請求についても合計請求データに含めてコンビニ払い等の特別な支払いを利用することができる。また、まとめて請求することで、金銭の支払いに要する手数料も低減することができる。
【００３２】
ここで請求生成部１１２は、所定のタイミングで、合計請求データを生成する。所定のタイミングは、例えば、定期的なタイミングであったり、同一の請求先であるユーザに対して所定数の請求データが溜まったタイミングである。具体的には、請求生成部１１２は、月毎、半月毎、週毎等の定期的なタイミングで合計請求データを生成してもよい。または、請求生成部１１２は、各ユーザについて、所定数の請求データが溜まったタイミングで合計請求データを生成してもよい。さらに、請求生成部１１２は、これら両方を組み合わせたタイミングで合計請求データを生成してもよい。すなわち、請求生成部１１２は、予め定められる定期的なタイミングで合計請求データを生成するが、そのタイミングの前に所定数の請求データが溜まった場合には、そのタイミングで合計請求データを生成してもよい。
【００３３】
請求生成部１１２は、請求に対する支払いに対して請求先のユーザに報酬として付与されるポイントの値を求めるとともに、求めたポイント値を含む合計請求データを生成することができる。ここで、請求生成部１１２は、支払いの時期によって、異なるポイント値になるようにポイント値を求めることができる。例えば、請求生成部１１２は、合計請求データの送信時から請求先のユーザによる支払い時までの支払い所要期間に応じ、支払い所要期間が短い場合には長い場合と比較して高くなるように定められたポイント値を求める。具体的には、請求生成部１１２は、合計請求データの送信から３日以内に支払いした場合に最も高い値のポイントが付与され、１０日以内に支払いした場合にはその１／２の値のポイントが付与され、それ以降はポイントが付与されないようにポイント値を求めることができる。請求生成部１１２は、ポイント値を求めた場合、求めたポイント値を含む合計請求データを、ユーザデータＤ１の合計請求データリストに追加する。
【００３４】
送信部１１３は、請求生成部１１２によって生成された合計請求データを請求先に送信する。例えば、合計請求データは、送信部１１３が送信し、ユーザ端末２０に受信されると、ユーザ端末２０のディスプレイにおいて、図６（ａ）に示すような画面Ｗ１を表示するデータである。この送信部１１３による送信方法は、限定されない。例えば、電子メール、ショートメッセージサービス、ソーシャルネットワーキングサービス等、メッセージを送信することができる方法であればよい。また、例えば、送信部１１３が送信する合計請求データに、合計請求金額が含まれておらず、合計請求金額を表示するためのデータにアクセスするためのＵＲＬが含まれるものであってもよい。
【００３５】
リクエスト受信部１１４は、送信部１１３が合計請求データを送信した請求先のユーザのユーザ端末２０から、希望の支払い方法の情報を含み、ユーザが支払いをするためのコードの生成を要求するコード生成リクエストを受信する。このコードは、請求先のユーザが、合計請求金額の支払いに使用するものである。このように、請求先のユーザは希望の支払い方法を選択することが可能であるため、請求先の支払いを促進させることが可能となる。
【００３６】
コード生成部１１５は、リクエスト受信部１１４が受信したコード生成リクエストが含む支払い方法で用いるコードを生成する。このコードは、合計請求ＩＤと請求金額を特定することが可能な情報であって、例えば、バーコードや二次元バーコードである。
【００３７】
送信部１１３は、通信部１３を介してこのコード生成部１１５が生成したコードを請求先のユーザのユーザ端末２０に送信する。例えば、コードは、送信部１１３が送信し、ユーザ端末２０に受信されると、ユーザ端末２０のディスプレイにおいて、図６（ｂ）に示すように表示される。
【００３８】
更新部１１６は、請求生成部１１２で生成された合計請求データの支払いに関する情報を、追加して家計簿データＤ２を更新する。なお、この家計簿データＤ２をユーザの収支の統計に関する情報としてグラフ等により提示可能であってもよい。図示を用いた説明を省略するが、取引管理装置１０は、支払いを受けると、支払いに利用される機関の端末等から支払い完了データを取得することができる。取引管理装置１０では、これにより、取引の完了を把握することができる。
【００３９】
ポイント記憶処理部１１７は、合計請求データで通知された請求に対して支払いが完了すると、請求先のユーザの請求先IDと、ポイント値を関連付けてポイントデータＤ３として記憶部１２に記憶させることができる。また、ポイント記憶処理部１１７は、新たなポイント値が求められると、これにより記憶部１２で記憶されるポイントデータＤ３を更新することができる。
【００４０】
スコア演算部１１８は、合計請求で通知された請求に対して支払いが完了すると、合計請求データの送信時から請求先のユーザによる支払い時までの支払い所要期間毎に設定される請求先のユーザを評価するスコア値の演算方法に応じて、当該支払い所要期間に対する請求先のユーザのスコア値を求め、求めたスコア値により、記憶部１２で記憶されるスコアデータを更新する。
【００４１】
また、スコア演算部１１８は、請求先のユーザによる合計請求データの確認時から、請求について未払い期間が所定期間以上経過すると、当該未払い期間に応じて設定される請求先のユーザを評価するスコア値の演算方法に応じて、当該未払い期間に対する請求先のユーザのスコア値を求め、求めたスコア値により、スコアデータを更新することができる。
【００４２】
リマインド送信部１１９は、合計請求データの送信後、請求先のユーザによる支払いがされない未払い期間が所定期間以上経過したとき、請求先のユーザに対し、支払いのリマインドデータを送信する。
【００４３】
また、リマインド送信部１１９は、請求先のユーザによる合計請求データの確認時から、請求先のユーザによる支払いがされない未払い期間が所定期間以上経過すると、請求先のユーザに対し、支払いのリマインドデータを送信してもよい。これにより、ユーザが支払いを忘れていた場合に支払いを促すことができる。また、請求元では、請求の未払いを低減することが可能となる。
【００４４】
先払い演算部１２０は、請求先のユーザから、特定の請求IDと、先払い期間とを含み、当該請求IDで特定される請求に関する先払いを希望する先払いリクエストを受信すると、当該先払い期間における請求IDに関して支払う合計先払い金額を演算する。例えば、インターネット接続の通信費、家賃、ローンの支払い等、一定額を複数回支払い続けるものがある。このようなものについては、同一の請求元から、同一の請求額の請求データが定期的に通知される。このため、ユーザが自主的に先払いを提案してユーザ端末２０から先払いリクエストが受信されると、先払い演算部１２０が合計先払い金額を演算する。
【００４５】
また、請求生成部１１２は、先払い演算部１２０で演算された合計先払い金額を含む先払い請求データを生成する。また、ここで生成された先払い請求データも、送信部１１３によってユーザ端末２０に送信する。これにより、請求元では、請求データを複数回送信する必要は不要となるため請求処理のコストを削減し、また、請求先による支払いが滞ることもないため未払いを防止することができる。さらに、請求先でも、未来に生じる請求を予め支払うことが可能となるため、支払いの手間を低減することができる。
【００４６】
なお、請求生成部１１２では、ポイント値を求める際、先払いをした場合には通常の定期的な支払いをするよりも高いポイント値になるように演算方法が定められていてもよい。また、スコア演算部１１８においても、スコア値を求める際、先払いをした場合には通常の定期的な支払いをするよりも高いスコア値になるように演算方法が定められていてもよい。  
【００４７】
また、取引管理装置１０は、請求元からの支払いが終了すると、各請求先に支払われた合計請求金額の金銭を振り分ける支払い部を有してもよい（図示を省略）。この支払い部は、例えば、ユーザデータＤ１の合計請求データリストから支払いタグが「済」のレコードを抽出する。次に、支払い部は、抽出したレコードから、すべての「請求ＩＤ」を抽出する。また、支払い部は、ユーザデータＤ１の請求データリストから抽出した「請求ＩＤ」のレコードを抽出する。また、支払い部は、抽出したレコードの請求元ＩＤで特定される請求元に、請求金額の金銭の支払いの処理を実行する。
【００４８】
《取引管理処理》
図７に示すシーケンス図を用いて、第１実施形態に係る取引管理システム１における処理を説明する。
【００４９】
まず、取引管理装置１０に、複数の請求者装置２０A〜２０Cから送信された請求データが入力される（Ｓ１０１）。
その後、取引管理装置１０は、複数の請求データのうち同じ請求先に対する請求データから合計請求金額を算出する（Ｓ１０２）。
また、取引管理装置１０は、算出した合計請求金額を含む合計請求データを生成する（Ｓ１０３）。
取引管理装置１０は、生成した合計請求データをユーザ端末２０に送信する（Ｓ１０４）。
【００５０】
ユーザ端末２０では、受信した合計請求データを表示し、ユーザに確認させる（Ｓ１０５）。このとき、ユーザ端末２０から開封確認データが送信されてもよい。
【００５１】
ユーザ端末２０は、ユーザの操作により、合計請求データで通知された合計請求の支払いをするためのコードの生成を要求するリクエストを送信する（Ｓ１０６）。ここで、コードの生成の要求は、例えば、図６（ａ）を用いて上述したような画面Ｗ１をタップすることで実行されてもよい。また例えば、画面Ｗ１にコード生成要求ボタンを設け、このコード生成要求ボタンの選択により、実行されてもよい。
【００５２】
取引管理装置１０は、リクエストに応じて、コードを生成する（Ｓ１０７）。
また、取引管理装置１０は、生成したコードをユーザ端末２０に送信する（Ｓ１０８）。
仮に、コードの送信後に支払いがされないとき、取引管理装置１０は、支払いのリマインドデータをユーザ端末２０に送信する（Ｓ１０９）。
【００５３】
ユーザによってユーザ端末２０で受信したコードを利用して支払いがされると（Ｓ１１０）、取引管理装置１０は、その支払いの完了に関する支払い完了データを取得する（Ｓ１１１）。例えば、この支払い完了データは、支払いに利用される。
支払い完了データの取得後、取引管理装置１０は、支払いの情報を追加して記憶部１２に記憶される家計簿データＤ２を更新する（Ｓ１１２）。
【００５４】
また、取引管理装置１０は、この支払いによってユーザに付与されるポイント値を加算して、記憶部１２に記憶されるポイントデータＤ３を更新する（Ｓ１１３）。
【００５５】
さらに、取引管理装置１０は、この支払いによってユーザのスコア値が算出され（Ｓ１１４）、算出されたスコア値によって、記憶部１２に記憶されるスコアデータＤ４を更新する。なお、ステップＳ１１２〜Ｓ１１５の処理の順序はこれに限定されず、また、同時に実行されてもよい。
【００５６】
取引管理システム１では、このように処理が実行され、複数のユーザの支払いの処理を容易にし、請求及び支払いに要する作業の簡易化を実現することができる。したがって、請求先では、支払いの処理を一括化して支払いの手続きを複数回行う必要がなく、また、請求を忘れることによる不払いを防止することが可能となる。請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。
《変形例》
【００５７】
図８に示すシーケンス図を用いて、第１実施形態の変形例に係る取引管理システムにおける処理を説明する。第１実施形態の変形例に係る取引管理システムでは、ユーザに始めに合計請求（第１の請求）をし、ユーザからまだ支払いがされない場合に、新たに発生した別の合計請求をするとき、これも合計に含めて第２の請求とする。
【００５８】
ここで、請求生成部１１２は、送信部１１３が合計請求データを送信後に請求先による支払いがされる前に、入力部１１１に請求先に対する複数の新たな請求データが入力されると、当該複数の新たな請求データに含まれる請求金額を加算して第２の合計請求金額を求めるとともに、送信部１１３が送信した合計請求金額と、求めた第２の合計請求金額とを加算して第３の合計請求金額を求め、第３の合計請求金額を含む新たな合計請求データを生成する。また、送信部１１３は、新たな合計請求データを請求先に送信する。
【００５９】
なお、図８に示す例で、図７で用いた符号と同一の処理については、同一の符号を付す。また、図８に示すシーケンス図において追加された処理については、太枠又は太字により強調する。ここで、図８に示すように、ステップＳ１０１〜Ｓ１０５の処理（第１の請求）で始めに生成する合計請求データを第１の合計請求データとする。
【００６０】
ここで、ステップＳ１０４で取引管理装置１０からユーザ端末２０に送信された第１の合計請求データによる請求に対し、未払いであるときに、請求データが複数入力されると（Ｔ１０１）、取引管理装置１０は、第２の合計請求金額を算出する（Ｔ１０２）。
【００６１】
また、取引管理装置１０は、ステップＳ１０２で算出した未払いの第１の合計請求金額と、ステップＴ１０２で算出した未払いの第２の合計請求金額とを合わせて、第３の合計請求金額を算出する（Ｔ１０３）。
その後、取引管理装置１０は、第３の合計請求金額を含む合計請求データを生成し（Ｔ１０４）、ユーザ端末２０に送信する（Ｔ１０５）。
ユーザ端末２０では、この合計請求データが確認され（Ｔ１０６）、コードを生成するリクエストを取引管理装置１０に送信する（Ｓ１０６）。
【００６２】
取引管理装置１０は、リクエストに応じてコードを生成し（Ｓ１０７）、生成したコードをユーザ端末２０に送信する。このとき、取引管理装置１０は、ステップＴ１０３で算出した第３の合計請求金額の支払いに使用するコードを生成する。
なお、この変更例に係る取引管理システムでも、図７を用いて上述したステップＳ１０９〜Ｓ１１５の処理を実行する。
【００６３】
これにより、変形例に係る取引管理システムでは、複数のユーザの未払いである先にされた請求データ（第１の請求のデータ）を新たな請求データ（第２の請求のデータ）と合計して再請求することができる。したがって、請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。また、請求先では請求の手続きを一括化して容易にするとともに、請求の存在を忘れることによる不払いを防止することが可能となる。
【００６４】
〈第２実施形態〉
図９を用いて、第２実施形態に係る取引管理システム１Ａについて説明する。第２実施形態に係る取引管理システム１Ａも取引管理装置１０Ａと、請求者装置２０Ａ〜２０Ｃと、ユーザ端末２０とが、ネットワーク３０を介して接続される。第１実施形態に係る取引管理システム１の取引管理装置１は、ユーザのリクエストに応じてコードを生成していたのに対し、第２実施形態に係る取引管理システム１Ａの取引管理装置１０Ａは、合計請求データ生成の際に、コードを生成し、コードを含む合計請求データを生成する。
【００６５】
《取引管理装置》
図９に示すように、第２実施形態に係る取引管理システム１Ａの取引管理装置１０Ａは、図２を用いて上述した取引管理装置１０と比較して、リクエスト受信部１１４及びコード生成部１１５を備えず、コード生成部１１５ａを備える点で異なる。また、取引管理装置１０Aは、取引管理装置１０と比較して、記憶部１２に支払い方法データＤ５を記憶し、管理プログラムＰ１に代えて管理プログラムＰ２を記憶する点で異なる。
【００６６】
この取引管理装置１０Ａは、記憶部１２に記憶される管理プログラムＰ２が実行されることで、制御部１１が、入力部１１１、請求生成部１１２、送信部１１３、コード生成部１１５ａ、更新部１１６、ポイント記憶処理部１１７、スコア演算部１１８、リマインド送信部１１９及び先払い演算部１２０の処理を実行する。
【００６７】
支払い方法データＤ５は、請求先ＩＤと、当該請求先ＩＤで識別されるユーザが予め希望する金銭の支払い方法とを関連づけるデータである。例えば、支払い方法データＤ５は、図１０に示す一例のように、請求先のユーザを識別する「ユーザＩＤ」と、このユーザが希望する支払いの方法である「支払い方法」とを含む。また、図１０に示すように、支払い方法データＤ５は、ユーザの希望する支払い方法が『クレジットカード払い』である場合のクレジットカード番号や『口座引き落とし払い』である場合の口座番号等の「番号」を支払い方法に関連付ける。
【００６８】
コード生成部１１５ａは、請求先ＩＤと関連づけられる支払い方法で用いるコードを生成する。具体的には、コード生成部１１５ａは、支払い方法データＤ５からユーザの請求先ＩＤと関連付けられる支払い方法を抽出する。そして、コード生成部１１５ａは、抽出した支払い方法で用いる支払う場合に使用するコードを生成する。ここで、例えば、コード生成部１１５ａは、ユーザがクレジットカード払いを希望するときには、クレジットカードによる支払いで使用するコードを生成する。また、コード生成部１１５ａは、ユーザが口座引き落としを希望するとときには、口座引き落としで使用するコードを生成する。さらに、コード生成部１１５ａは、ユーザが銀行振り込みを希望するときには、銀行振り込みで使用するコードを生成する。また、コード生成部１１５ａは、ユーザがコンビニ払いを希望するときには、コンビニ払いで使用するコードを利用する。
【００６９】
なお、請求生成部１１２は、コード生成部１１５ａが生成したコードを含む合計請求データを生成する。
【００７０】
《取引管理処理》
図１１に示すシーケンス図を用いて、第２実施形態に係る取引管理システム１Ａにおける処理を説明する。なお、図１１に示すシーケンス図において、図７を用いて上述した処理と異なる処理については、太枠又は太字により強調し、同一の処理については、一部の説明を省略する。
【００７１】
まず、取引管理装置１０Ａに、複数の請求者装置２０A〜２０Cから送信された請求データが入力される（Ｓ１０１）。
その後、取引管理装置１０Ａは、複数の請求データから合計請求金額を算出する（Ｓ１０２）。
【００７２】
ここで、取引管理装置１０Ａは、支払い方法データＤ５から請求先のユーザが希望する支払い方法を抽出する（Ｓ２０１）。
また、取引管理装置１０Ａは、ステップＳ２０１で抽出した方法による支払で使用するコードを生成する（Ｓ２０２）。
【００７３】
続いて、取引管理装置１０Ａは、ステップＳ１０２で算出した合計請求金額、ステップＳ２０２で生成したコードを含む合計請求データを生成する（Ｓ２０３）。
取引管理装置１０Ａは、生成した合計請求データをユーザ端末２０に送信する（Ｓ１０４）。
【００７４】
ユーザ端末２０では、ユーザが、受信した合計請求データを確認する（Ｓ１０５）。第２実施形態に係る取引管理システム１Ａでは、既にコードの生成がされているため、図７で上述したステップＳ１０６〜Ｓ１０８の処理については実行されない。また、ステップＳ１０９〜Ｓ１１５の処理については、上述した処理と同一である。
【００７５】
取引管理システム１Ａでは、このように処理が実行され、複数のユーザの支払いの処理を容易にし、請求及び支払いに要する作業の簡易化を実現することができる。したがって、請求先では、支払いの処理を一括化して支払いの手続きを複数回行う必要がなく、また、請求を忘れることによる不払いを防止することが可能となる。請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。
【００７６】
《変形例》
図１２に示すシーケンス図を用いて、第２実施形態の変形例に係る取引管理システムにおける処理を説明する。第２実施形態の変形例に係る取引管理システムでは、ユーザに始めに合計請求（第１の請求）をし、ユーザからまだ支払いがされない場合に、次の合計請求をするとき、これも合計に含めて第２の請求とする。
【００７７】
ここで、請求生成部１１２は、送信部１１３が合計請求データを送信後に請求先による支払いがされる前に、入力部１１１に請求先に対する複数の新たな請求データが入力されると、当該複数の新たな請求データに含まれる請求金額を加算して第２の合計請求金額を求めるとともに、送信部１１３が送信した合計請求金額と、求めた第２の合計請求金額とを加算して第３の合計請求金額を求め、第３の合計請求金額を含む新たな合計請求データを生成する。また、送信部１１３は、新たな合計請求データを請求先に送信する。
【００７８】
なお、図１２に示す例で、図１１で用いた符号と同一の処理については、同一の符号を付す。また、図１２に示すシーケンス図において追加された処理については、太枠又は太字により強調する。ここで、図１２に示すように、ステップＳ１０１〜Ｓ１０５の処理（第１の請求）で始めに生成する合計請求データを第１の合計請求データとする。
【００７９】
ここで、ステップＳ１０４で取引管理装置１０Ａからユーザ端末２０に送信された第１の合計請求データによる請求に対し、未払いであるときに、請求データが複数入力されると（Ｔ２０１）、取引管理装置１０Ａは、第２の合計請求金額を算出する（Ｔ２０２）。
【００８０】
その後、取引管理装置１０Ａは、ステップＳ１０２で算出した未払いの第１の合計請求金額と、ステップＴ２０２で算出した未払いの第２の合計請求金額とを合わせて、第３の合計請求金額を算出する（Ｔ２０３）。
また、取引管理装置１０Ａは、支払い方法データＤ５から、ユーザが希望する支払い方法を抽出する（Ｔ２０４）。
その後、取引管理装置１０Ａは、ステップＴ２０４で抽出した支払い方法で第３の請求金額の支払いに使用するコードを生成する（Ｔ２０５）
【００８１】
続いて、取引管理装置１０Ａは、ステップＴ２０２で算出した第３の合計請求金額と、ステップＴ２０５で生成したコードを含む合計請求データを生成し（Ｔ２０６）、ユーザ端末２０に送信する（Ｔ２０７）。
【００８２】
ユーザ端末２０では、この合計請求データが確認される（Ｔ２０８）。その後の処理は、図１１を用いて上述したステップＳ１０９〜Ｓ１１５の処理であるため、図１２ではこれらの図示を省略し、説明も省略する。
【００８３】
これにより、変形例に係る取引管理システムでは、複数のユーザの未払いである先にされた請求データ（第１の請求のデータ）を新たな請求データ（第２の請求のデータ）と合計して再請求することができる。したがって、請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。また、請求先では請求の手続きを一括化して容易にするとともに、請求の存在を忘れることによる不払いを防止することが可能となる。
【００８４】
〈第３実施形態〉
図１３を用いて、第３実施形態に係る取引管理システム１Ｂについて説明する。第２実施形態に係る取引管理システム１Ａも取引管理装置１０Ａと、請求者装置２０Ａ〜２０Ｃと、ユーザ端末２０とが、ネットワーク３０を介して接続される。第１実施形態に係る取引管理システム１の取引管理装置１は、ユーザのリクエストに応じて支払いに使用するコードを生成していたのに対し、第３実施形態に係る取引管理システム１Ｂの取引管理装置１０Ｂは、ユーザの請求により、電子取引により支払いを実行する。
【００８５】
《取引管理装置》
図１３に示すように、第３実施形態に係る取引管理システム１Ｂの取引管理装置１０Ｂは、図２を用いて上述した取引管理装置１０と比較して、リクエスト受信部１１４及びコード生成部１１５を備えず、受付部１２１及び実行部１２２を備える点で異なる。また、取引管理装置１０Ｂは、取引管理装置１０と比較して、記憶部１２に金融データＤ６を記憶し、管理プログラムＰ１に代えて管理プログラムＰ３を記憶する点で異なる。
【００８６】
この取引管理装置１０Ｂは、記憶部１２に記憶される管理プログラムＰ３が実行されることで、制御部１１が、入力部１１１、請求生成部１１２、送信部１１３、更新部１１６、ポイント記憶処理部１１７、スコア演算部１１８、リマインド送信部１１９、先払い演算部１２０、受付部１２１及び実行部１２２の処理を実行する。
【００８７】
金融データＤ６は、ユーザのIDと、当該ユーザの金銭の支払いに使用される金融情報とを関連付けるデータである。この『金融情報』は、ユーザの有するクレジットカードのクレジットカード番号や銀行口座の銀行口座番号である。その他、ある請求に合計させるような支払い方法であってもよい。具体的には、電話料金に他の請求を合計して支払う方法や、通信費に他の請求を合計して支払う方法であってもよい。これにより、支払いを効率化することができる。
受付部１２１は、請求生成部１１２が生成した合計請求データに対してユーザからの支払い指示を受け付ける。
【００８８】
実行部１２２は、記憶部１２に記憶される金融データＤ６からユーザのユーザIDと関連付けられる金融情報を抽出し、受付部１２１が受け付けた支払い指示に対して、支払いを実行する。ここで、実行部１２２は、ユーザ端末２０又はクレジットカード会社や銀行等の金融機関の端末との間で、暗証番号等のセキュリティデータを送受信した後に、支払いを実行するものであってもよい。
【００８９】
《取引管理処理》
図１４に示すシーケンス図を用いて、第３実施形態に係る取引管理システム１Ｂにおける処理を説明する。なお、図１４に示すシーケンス図において、図７を用いて上述した処理と異なる処理については、太枠又は太字により強調し、同一の処理については、一部の説明を省略する。
【００９０】
まず、取引管理装置１０Ｂに、複数の請求者装置２０A〜２０Cから送信された請求データが入力される（Ｓ１０１）。
【００９１】
その後、取引管理装置１０Ｂは、複数の請求データから合計請求金額を算出する（Ｓ１０２）。
【００９２】
続いて、取引管理装置１０Ｂは、ステップＳ１０２で算出した合計請求金額を含む合計請求データを生成する（Ｓ１０３）。
取引管理装置１０Ｂは、生成した合計請求データをユーザ端末２０に送信する（Ｓ１０４）。
【００９３】
ユーザ端末２０では、ユーザが、受信した合計請求データを確認する（Ｓ１０５）。
その後、ユーザ端末２０から取引管理装置１０Ｂに支払い指示データが送信される（Ｓ３０１）。
【００９４】
また、取引管理装置１０Ｂは、ステップＳ３０１でユーザ端末２０から送信された支払い指示データにしたがって、支払いを実行する（Ｓ３０２）。
また、ステップＳ３０２に続いて実行されるステップＳ１１０〜Ｓ１１５の処理については、上述した処理と同一である。
【００９５】
取引管理システム１Ｂでは、このように処理が実行され、複数のユーザの支払いの処理を容易にし、請求及び支払いに要する作業の簡易化を実現することができる。したがって、請求先では、支払いの処理を一括化して支払いの手続きを複数回行う必要がなく、また、請求を忘れることによる不払いを防止することが可能となる。請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。
【００９６】
《変形例》
図１５に示すシーケンス図を用いて、第２実施形態の変形例に係る取引管理システムにおける処理を説明する。第２実施形態の変形例に係る取引管理システムでは、ユーザに始めに合計請求（第１の請求）をし、ユーザからまだ支払いがされない場合に、次の合計請求をするとき、これも合計に含めて第２の請求とする。
【００９７】
ここで、請求生成部１１２は、送信部１１３が合計請求データを送信後に請求先による支払いがされる前に、入力部１１１に請求先に対する複数の新たな請求データが入力されると、当該複数の新たな請求データに含まれる請求金額を加算して第２の合計請求金額を求めるとともに、送信部１１３が送信した合計請求金額と、求めた第２の合計請求金額とを加算して第３の合計請求金額を求め、第３の合計請求金額を含む新たな合計請求データを生成する。また、送信部１１３は、新たな合計請求データを請求先に送信する。
【００９８】
なお、図１５に示す例で、図１４で用いた符号と同一の処理については、同一の符号を付す。また、図１５に示すシーケンス図において追加された処理については、太枠又は太字により強調する。ここで、図１５に示すように、ステップＳ１０１〜Ｓ１０５の処理（第１の請求）で始めに生成する合計請求データを第１の合計請求データとする。
【００９９】
ここで、ステップＳ１０４で取引管理装置１０Ｂからユーザ端末２０に送信された第１の合計請求データによる請求に対し、未払いであるときに、請求データが複数入力されると（Ｔ３０１）、取引管理装置１０Ｂは、第２の合計請求金額を算出する（Ｔ３０２）。
【０１００】
その後、取引管理装置１０Ｂは、ステップＳ１０２で算出した未払いの第１の合計請求金額と、ステップＴ３０２で算出した未払いの第２の合計請求金額とを合わせて、第３の合計請求金額を算出する（Ｔ３０３）。
【０１０１】
続いて、取引管理装置１０Ｂは、ステップＴ３０２で算出した第３の合計請求金額を含む合計請求データを生成し（Ｔ３０４）、ユーザ端末２０に送信する（Ｔ３０５）。
ユーザ端末２０では、この合計請求データが確認される（Ｔ３０６）。
また、ユーザ端末２０から取引管理装置１０Ｂに支払い指示データが送信される（Ｓ３０１）。
【０１０２】
これにより、取引管理装置１０Ｂは、支払いを実行する（Ｓ３０２）。その後の処理は、図１１を用いて上述したステップＳ１０９〜Ｓ１１５の処理であるため、図１５ではこれらの図示を省略し、説明も省略する。
【０１０３】
これにより、変形例に係る取引管理システムでは、複数のユーザの未払いである先にされた請求データ（第１の請求のデータ）を新たな請求データ（第２の請求のデータ）と合計して再請求することができる。したがって、請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。また、請求先では請求の手続きを一括化して容易にするとともに、請求の存在を忘れることによる不払いを防止することが可能となる。
【符号の説明】
【０１０４】
１、１Ａ、１Ｂ  取引管理システム
１０、１０Ａ、１０Ｂ  取引管理装置
１１  制御部
１１１  入力部
１１２  請求生成部
１１３  送信部
１１４  リクエスト受信部
１１５  コード生成部
１１６  更新部
１１７  ポイント記憶処理部
１１８  スコア演算部
１１９  リマインド送信部
１２０  先払い演算部
１２  記憶部
Ｄ１  ユーザデータ
Ｄ２  家計簿データ
Ｄ３  ポイントデータ
Ｄ４  スコアデータ
Ｐ１、Ｐ２、Ｐ３  管理プログラム
２０Ａ〜２０Ｃ  請求者装置
２０  ユーザ端末
【図１】
2020071787.tif 000003
【図２】
2020071787.tif 000004
【図３】
2020071787.tif 000005
【図４】
2020071787.tif 000006
【図５】
2020071787.tif 000007
【図６】
2020071787.tif 000008
【図７】
2020071787.tif 000009
【図８】
2020071787.tif 000010
【図９】
2020071787.tif 000011
【図１０】
2020071787.tif 000012
【図１１】
2020071787.tif 000013
【図１２】
2020071787.tif 000014
【図１３】
2020071787.tif 000015
【図１４】
2020071787.tif 000016
【図１５】
2020071787.tif 000017
【手続補正書】
【提出日】令和2年2月25日(2020.2.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力部と、
前記入力部に入力された同一の請求先ＩＤに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成部と、
前記請求生成部によって生成された合計請求データを前記請求先に送信する送信部と、
ユーザのＩＤと、当該ユーザの収支に関するデータと、当該ユーザの貯蓄に関するデータとを含む家計簿データを記憶する家計簿データ記憶部と、
前記請求生成部で生成された前記合計請求データの支払いに関する情報を、追加して前記家計簿データを更新する更新部と、
を備える取引管理装置。
【請求項２】
前記送信部が前記合計請求データを送信した前記請求先のユーザから、希望の支払い方法の情報を含み、前記ユーザが支払いをするためのコードの生成を要求するコード生成リクエストを受信するリクエスト受信部と、
前記リクエスト受信部が受信したコード生成リクエストが含む支払い方法で用いるコードを生成するコード生成部と、
をさらに備え、
前記送信部は、前記コード生成部が生成したコードを前記請求先のユーザに送信する
請求項１に記載の取引管理装置。
【請求項３】
請求先ＩＤと、当該請求先ＩＤで識別されるユーザが予め希望する金銭の支払い方法とを関連づける支払い方法データを記憶する支払い方法データ記憶部と、
前記支払い方法データにおいて前記請求先ＩＤと関連づけられる支払い方法で用いるコードを生成するコード生成部とをさらに備え、
前記請求生成部は、前記コード生成部が生成したコードを含む合計請求データを生成する
請求項１に記載の取引管理装置。
【請求項４】
ユーザのＩＤと、当該ユーザの金銭の支払いに使用される金融情報とを関連付ける金融データを記憶する金融データ記憶部と、
前記請求生成部が生成した合計請求データに対して前記ユーザからの支払い指示を受け付ける受付部と、
前記金融データ記憶部から前記ユーザのユーザＩＤと関連付けられる金融情報を抽出し、
前記受付部が受け付けた支払い指示に対して、支払いを実行する実行部と、
をさらに備える請求項１に記載の取引管理装置。
【請求項５】
前記請求生成部は、前記送信部が前記合計請求データを送信後に請求先による支払いがされる前に、前記入力部に前記請求先に対する複数の新たな請求データが入力されると、当該複数の新たな請求データに含まれる請求金額を加算して第２の合計請求金額を求めるとともに、前記送信部が送信した前記合計請求金額と、求めた前記第２の合計請求金額とを加算して第３の合計請求金額を求め、前記第３の合計請求金額を含む新たな合計請求データを生成し、
前記送信部は、前記新たな合計請求データを前記請求先に送信する
請求項２乃至４のいずれか１に記載の取引管理装置。
【請求項６】
前記請求生成部は、請求に対する支払いに対して前記請求先のユーザに報酬として付与されるポイントの値を求めるとともに、求めたポイント値を含む合計請求データを生成し、
前記合計請求データで通知された請求に対して支払いが完了すると、前記請求先のユーザの請求先ＩＤと、前記ポイント値を関連付けてポイントデータとしてポイントデータ記憶部に記憶させるポイント記憶処理部を
さらに備える請求項１乃至５のいずれか１に記載の取引管理装置。
【請求項７】
前記請求生成部は、前記合計請求データの送信時から前記請求先のユーザによる支払い時までの支払い所要期間に応じ、前記支払い所要期間が短い場合には長い場合と比較して高くなるように定められたポイント値を求め、
前記ポイント記憶処理部は、前記請求先ＩＤと、前記支払い所要期間に対して求められたポイント値とを関連付けてポイントデータ記憶部に記憶させる
請求項６に記載の取引管理装置。
【請求項８】
請求先のユーザの請求先ＩＤと、前記請求先のユーザの支払いの即答性を評価するスコア値とが関連付けられるスコアデータを記憶するスコアデータ記憶部と、
前記合計請求で通知された請求に対して支払いが完了すると、前記合計請求データの送信時から前記請求先のユーザによる支払い時までの支払い所要期間毎に設定される前記請求先のユーザを評価するスコア値の演算方法に応じて、当該支払い所要期間に対する前記請求先のユーザのスコア値を求め、求めた前記スコア値により、前記スコアデータを更新するスコア演算部と、
をさらに備える請求項１乃至７のいずれか１に記載の取引管理装置。
【請求項９】
前記スコア演算部は、前記請求先のユーザによる前記合計請求データの確認時から、前記請求について未払い期間が所定期間以上経過すると、当該未払い期間に応じて設定される前記請求先のユーザを評価するスコア値の演算方法に応じて、当該未払い期間に対する前記請求先のユーザのスコア値を求め、求めた前記スコア値により、前記スコアデータを更新する
請求項８に記載の取引管理装置。
【請求項１０】
前記合計請求データの送信後、前記請求先のユーザによる支払いがされない未払い期間が所定期間以上経過したとき、前記請求先のユーザに対し、支払いのリマインドデータを送信するリマインド送信部
をさらに備える請求項１乃至９のいずれか１に記載の取引管理装置。
【請求項１１】
前記リマインド送信部は、前記請求先のユーザによる前記合計請求データの確認時から、前記請求先のユーザによる支払いがされない未払い期間が所定期間以上経過すると、前記請求先のユーザに対し、支払いのリマインドデータを送信する
請求項１０に記載の取引管理装置。
【請求項１２】
前記入力部に入力される請求データは、金銭の支払いに関する請求に付与された請求ＩＤをさらに含み、
前記請求先のユーザから、特定の請求ＩＤと、先払い期間とを含み、当該請求ＩＤで特定される請求に関する先払いを希望する先払いリクエストを受信すると、当該先払い期間における前記請求ＩＤに関して支払う合計先払い金額を演算する先払い演算部をさらに備え、
前記請求生成部は、前記先払い演算部で演算された合計先払い金額を含む先払い請求データを生成する
請求項１乃至１１のいずれか１に記載の取引管理装置。
【請求項１３】
請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力ステップと、
前記入力ステップで入力された同一の請求先ＩＤに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成ステップと、
前記請求生成ステップにおいて生成された合計請求データを前記請求先に送信する送信ステップと、
ユーザのＩＤと、当該ユーザの収支に関するデータと、当該ユーザの貯蓄に関するデータとを含む家計簿データを記憶する家計簿データ記憶ステップと、
前記請求生成ステップで生成された前記合計請求データの支払いに関する情報を、追加して前記家計簿データを更新する更新ステップと、
を有する取引管理方法。
【請求項１４】
コンピュータに、
請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力機能と、
前記入力機能に入力された同一の請求先ＩＤに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成機能と、
前記請求生成機能によって生成された合計請求データを前記請求先に送信する送信機能と、
ユーザのＩＤと、当該ユーザの収支に関するデータと、当該ユーザの貯蓄に関するデータとを含む家計簿データを記憶する家計簿データ記憶機能と、
前記請求生成機能で生成された前記合計請求データの支払いに関する情報を、追加して前記家計簿データを更新する更新機能と、
を実現させる取引管理プログラム。