JP2023135345A - 情報処理装置、情報処理システム、情報処理方法及びプログラム - Google Patents

Abstract

【課題】債権保証契約の対象とする取引先を選択するための情報を出力する。【解決手段】利用者が用いる利用者端末とネットワークを介して通信可能な情報処理装置は、取引先の支払い状態を含む履歴情報を取得する取得部と、履歴情報を用いて取引先の取引状況を判定する判定部と、取引状況及び債権保証の契約状態を表示するための画面データを利用者端末に送信する通信部と、を備える。【選択図】図４

Description

この発明は、情報処理装置、情報処理システム、情報処理方法及びプログラムに関する。

商取引においては、債権者にとって債権が回収不能となるリスクがある。債権が回収不能となるリスクを低減するために、債権の保証を依頼することができる債権保証事業者がある。債権の債権を債権保証の対象とすることで、債権が回収不能となった際に債権保証事業者から保険金が支払われるため、回収不能となるリスクを低減することができる。

例えば、特許文献１には、商取引におけるリスクを低減するために、代金の支払い者からの仮決済情報により代金支払い先に対して支払能力があることを示すと共に、代金支払い先からの仮決済情報を含む本決済依頼と支払い者の承認による本決済を実行する発明が開示されている。

しかしながら、債権保証契約の対象とする取引先を適切に選択することは困難である、という課題がある。例えば、取引期間の短い新規の取引先を債権保証契約の対象とすることがある。一定の取引期間を経て信頼できる取引先と考えられる場合、よりリスクの高い他の取引先を債権保証の対象とした方が効率的であるが、利用者が利用可能な情報から取引先の取引状況を評価することは困難である。

この発明の一実施形態は、上記のような技術的課題に鑑みて、債権保証契約の対象とする取引先を選択するための情報を出力することである。

上記の課題を解決するために、この発明の一実施形態である情報処理装置は、利用者が用いる利用者端末とネットワークを介して通信可能な情報処理装置であって、取引先の支払い状態を含む履歴情報を取得する取得部と、履歴情報を用いて取引先の取引状況を判定する判定部と、取引状況及び債権保証の契約状態を表示するための画面データを利用者端末に送信する通信部と、を備える。

この発明の一実施形態によれば、債権保証契約の対象とする取引先を選択するための情報を出力することができる。

一実施形態における各企業の関係を示す概念図である。 一実施形態における情報処理システムの全体構成の一例を示す図である。 一実施形態における情報処理装置のハードウェア構成の一例を示す図である。 一実施形態における情報処理システムの機能構成の一例を示す図である。 一実施形態における取引先情報テーブルの一例を示す図である。 一実施形態における請求書情報テーブルの一例を示す図である。 一実施形態における債権保証情報テーブルの一例を示す図である。 一実施形態における履行情報テーブルの一例を示す図である。 一実施形態における取引状況基準情報テーブルの一例を示す図である。 一実施形態における評価条件情報テーブルの一例を示す図である。 一実施形態における与信情報テーブルの一例を示す図である。 一実施形態における取引状況情報テーブルの一例を示す図である。 一実施形態における債権管理情報テーブルの一例を示す図である。 一実施形態における取引開始処理の一例を示すフローチャートである。 一実施形態における取引状況表示処理の一例を示すフローチャートである。 一実施形態における取引状況判定処理の一例を示すフローチャートである。 一実施形態における取引状況画面の一例を示す図である。 一実施形態における解除実行処理の一例を示すフローチャートである。 一実施形態における解除実行画面の一例を示す図である。 一実施形態における追加取引先判定処理の一例を示すフローチャートである。 一実施形態における追加提案画面の一例を示す図である。 一実施形態における追加実行画面の一例を示す図である。 一実施形態における解除提案処理の一例を示すフローチャートである。 一実施形態における解除取引先判定処理の一例を示すフローチャートである。 一実施形態における解除提案画面の一例を示す図である。

以下、図面を参照しながら、この発明の実施の形態について、詳細に説明する。なお、図面中において同じ機能を有する構成部には同じ番号を付し、重複説明を省略する。

［実施形態］
〔企業間の関係〕
本実施形態における各企業間の関係を、図１を参照しながら説明する。図１は、本実施形態における各企業の関係を示す概念図である。

図１に示されているように、サービス利用企業Ａは、取引先企業Ｂに対して、商品又はサービスを提供することで、取引先企業Ｂから対価を受ける企業である。取引先企業Ｂは、サービス利用企業Ａの取引先である。この場合、サービス利用企業Ａが債権者となり、取引先企業Ｂが債務者となる関係が生じる。

サービス提供企業Ｃは、サービス利用企業Ａからの依頼を受けて、取引先企業Ｂとの取引で行われる一連の手続きを管理するサービスを提供する企業等である。また、本実施形態における情報処理システムが提供するサービスを利用するサービス利用企業をテナントと表現する場合がある。つまり、本実施形態においてテナントとは、事業者、団体や個人等である。以下、サービス提供企業Ｃが提供するサービスを「取引管理サービス」と呼ぶ。一連の手続きには、例えば、請求書の発行及び取引先への送付、並びに回収不能となった債権に対する債権保証の履行等が含まれる。

債権保証サービス企業Ｄは、サービス提供企業Ｃと連携して、回収不能となった債権に対して保険金を支払うサービスを提供する企業である。以下、債権保証サービス企業Ｄが提供するサービスを「債権保証サービス」と呼ぶ。

ここで、本実施形態における処理の概略を説明する。

まず、サービス利用企業Ａは、サービス提供企業Ｃに対して、取引先企業Ｂとの商取引に基づく請求書の作成、及び作成した請求書の取引先企業Ｂへの送付を要求する（Ｓ１）。これにより、サービス提供企業Ｃは、請求書を作成して、取引先企業Ｂに送付する（Ｓ２）。

次に、サービス利用企業Ａは、サービス提供企業Ｃに対して、債権保証契約に取引先企業Ｂを追加することを要求する（Ｓ３）。サービス提供企業Ｃは、サービス利用企業Ａからの要求に応じて、債権保証サービス企業Ｄに対して、債権保証契約に取引先企業Ｂを追加することを申請する（Ｓ４）。取引先企業Ｂがすでに債権保証契約の対象となっている場合、ステップＳ３及びＳ４は省略することができる。

続いて、サービス提供企業Ｃは、サービス利用企業Ａからの要求に応じて、取引先企業Ｂの取引状況を表示する（Ｓ５）。サービス利用企業Ａは、取引先企業Ｂの取引状況に基づいて、サービス提供企業Ｃに対して、債権保証契約の変更を要求する（Ｓ６）。サービス提供企業Ｃは、サービス利用企業Ａからの要求に応じて、債権保証サービス企業Ｄに対して、債権保証契約の変更を申請する（Ｓ７）。

債権保証契約の変更には、ある取引先企業Ｂを債権保証契約から解除すること、及びある取引先企業Ｂを債権保証契約に追加することが含まれる。取引先企業Ｂの取引状況により債権保証契約の変更が必要ない場合、ステップＳ６及びＳ７は省略することができる。

〔情報処理システムの全体構成〕
本実施形態における情報処理システムの全体構成を、図２を参照しながら説明する。図２は、本実施形態における情報処理システムの全体構成の一例を示すブロック図である。

図２に示されているように、本実施形態における情報処理システム１は、取引管理システム２、債権保証システム３及び利用者端末４０を含む。本実施形態における取引管理システム２は、帳票管理サーバ１０、債権保証サーバ２０及び債権管理サーバ３０を含む。情報処理システム１に含まれる各システム、サーバ及び端末は、それぞれ通信ネットワークＮ１に接続している。

通信ネットワークＮ１は、接続されている各装置が相互に通信可能となるように構成されている。通信ネットワークＮ１は、例えば、インターネット、ＬＡＮ（Local Area Network）、又はＷＡＮ（Wide Area Network）などの有線通信によるネットワークによって構築されている。

通信ネットワークＮ１は、有線通信だけでなく、例えば、無線ＬＡＮ、又は近距離無線通信等の無線通信、もしくはＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、ＬＴＥ（Long Term Evolution）、又は５Ｇ（5th Generation）等の移動体通信によるネットワークが含まれていてもよい。

利用者端末４０は、サービス利用企業Ａに設置されている。取引管理システム２は、サービス提供企業Ｃに設置されている。債権保証システム３は、債権保証サービス企業Ｄに設置されている。

帳票管理サーバ１０は、通信ネットワークＮ１を介して、帳票管理サービスを利用者端末４０に提供する。本実施形態における帳票管理サービスは、利用者端末４０からの要求に応じて、請求書を作成し、作成した請求書を取引先へ送付するサービスである。

債権保証サーバ２０は、通信ネットワークＮ１を介して、債権保証仲介サービスを利用者端末４０に提供する。本実施形態における債権保証仲介サービスは、利用者端末４０からの要求に応じて、未回収の債権に対して債権保証を履行するための手続きを、債権保証システム３に対して実行するサービスである。

債権管理サーバ３０は、通信ネットワークＮ１を介して、債権管理サービスを利用者端末４０に提供する。本実施形態における債権管理サービスは、取引先の取引状況を表示し、利用者端末４０からの要求に応じて、債権保証契約の変更を債権保証サーバ２０に要求するサービスである。

利用者端末４０は、利用者が使用する情報処理装置である。利用者は、サービス利用企業Ａの従業員等である。利用者端末４０は、利用者の操作に応じて、通信ネットワークＮ１を介して、取引管理システム２に含まれる各サーバが提供する各種サービスを利用する。

帳票管理サーバ１０、債権保証サーバ２０、債権管理サーバ３０及び利用者端末４０の一例は、情報処理装置である。なお、帳票管理サーバ１０、債権保証サーバ２０、債権管理サーバ３０及び利用者端末４０は、通信機能を備えた装置であれば、情報処理装置に限られない。

帳票管理サーバ１０、債権保証サーバ２０、債権管理サーバ３０及び利用者端末４０は、例えば、ＰＪ（Projector：プロジェクタ）、ＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）、デジタルサイネージ等の出力装置、ＨＵＤ（Head Up Display）装置、産業機械、撮像装置、集音装置、医療機器、ネットワーク家電、自動車（Connected Car）、ノートＰＣ（Personal Computer）、携帯電話、スマートフォン、タブレット端末、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、ウェアラブルＰＣまたはデスクトップＰＣ等であってもよい。

〔情報処理システムのハードウェア構成〕
本実施形態における情報処理システムのハードウェア構成を、図３を参照しながら説明する。図３は、帳票管理サーバ１０、債権保証サーバ２０、債権管理サーバ３０及び利用者端末４０がコンピュータで実現される場合のハードウェア構成の一例を示す図である。

図３に示されているように、本実施形態におけるコンピュータは、ＣＰＵ（Central Processing Unit）５０１、ＲＯＭ（Read Only Memory）５０２、ＲＡＭ（Random Access Memory）５０３、ＨＤ（Hard Disk）５０４、ＨＤＤ(Hard Disk Drive)コントローラ５０５、ディスプレイ５０６、外部機器接続Ｉ／Ｆ(Interface)５０８、ネットワークＩ／Ｆ５０９、バスライン５１０、キーボード５１１、ポインティングデバイス５１２、ＤＶＤ－ＲＷ(Digital Versatile Disk Rewritable)ドライブ５１４、メディアＩ／Ｆ５１６を備えている。

これらのうち、ＣＰＵ５０１は、コンピュータ全体の動作を制御する。ＲＯＭ５０２は、ＩＰＬ等のＣＰＵ５０１の駆動に用いられるプログラムを記憶する。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。ＨＤ５０４は、プログラム等の各種データを記憶する。ＨＤＤコントローラ５０５は、ＣＰＵ５０１の制御にしたがってＨＤ５０４に対する各種データの読み出し又は書き込みを制御する。

ディスプレイ５０６は、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。外部機器接続Ｉ／Ｆ５０８は、各種の外部機器を接続するためのインターフェースである。この場合の外部機器は、例えば、ＵＳＢ(Universal Serial Bus)メモリやプリンタ等である。ネットワークＩ／Ｆ５０９は、通信ネットワークＮ１を利用してデータ通信をするためのインターフェースである。バスライン５１０は、図３に示されているＣＰＵ５０１等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

また、キーボード５１１は、文字、数値、各種指示などの入力のための複数のキーを備えた入力手段の一種である。ポインティングデバイス５１２は、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行う入力手段の一種である。ＤＶＤ－ＲＷドライブ５１４は、着脱可能な記録媒体の一例としてのＤＶＤ－ＲＷ５１３に対する各種データの読み出し又は書き込みを制御する。なお、ＤＶＤ－ＲＷに限らず、ＤＶＤ－Ｒ等であってもよい。メディアＩ／Ｆ５１６は、フラッシュメモリ等の記録メディア５１５に対するデータの読み出し又は書き込み（記憶）を制御する。

〔情報処理システムの機能構成〕
本実施形態における情報処理システムの機能構成を、図４乃至図１３を参照しながら説明する。図４は、本実施形態における情報処理システムの機能構成の一例を示すブロック図である。

＜帳票管理サーバの機能構成＞
図４に示されているように、本実施形態における帳票管理サーバ１０は、帳票管理情報記憶部１００、記憶制御部１１及び通信部１２を備える。

帳票管理情報記憶部１００は、帳票管理サービスで用いる取引先情報及び請求書情報を記憶する。帳票管理情報記憶部１００は、例えば、図３に示されているＨＤ５０４を用いて実現される。

記憶制御部１１は、帳票管理情報記憶部１００に対するデータの書き込み及び読み出しを行う。記憶制御部１１は、例えば、図３に示されているＨＤ５０４からＲＡＭ５０３上に展開されたプログラムがＣＰＵ５０１及びＨＤＤコントローラ５０５に実行させる処理によって実現される。

通信部１２は、通信ネットワークＮ１を介して他のサーバ、装置、又はシステムと各種データの送受信を行う。通信部１２は、例えば、図３に示されているＨＤ５０４からＲＡＭ５０３上に展開されたプログラムがＣＰＵ５０１及びネットワークＩ／Ｆ５０９に実行させる処理によって実現される。

（取引先情報テーブル）
図５は、取引先情報を格納する取引先情報テーブルの一例を示す概念図である。帳票管理情報記憶部１００には、図５に示されているような取引先情報テーブルによって構成されている取引先情報管理ＤＢ１００１が構築されている。取引先情報テーブルには、サービス利用企業Ａの取引先である取引先企業Ｂに関する情報が格納されている。

図５に示されているように、取引先情報テーブルでは、テナント毎に、取引先の名称（会社名等）、取引先の住所（所在地）、取引先の連絡先（電話番号、メールアドレス等）、取引先の担当者名、及び取引先の口座情報（銀行名、支店名、口座種別、口座番号、及び口座名義等）等が関連付けて管理されている。

（請求書情報テーブル）
図６は、請求書情報を格納する請求書情報テーブルの一例を示す概念図である。帳票管理情報記憶部１００には、図６に示されているような請求書情報テーブルによって構成されている請求書情報管理ＤＢ１００２が構築されている。請求書情報テーブルには、サービス利用企業Ａが発行した請求書に関する情報が格納されている。

図６に示されているように、請求書情報テーブルでは、テナント毎に、請求先の名称（会社名等）、請求金額、請求日、支払い期限日、支払い状態（未払い又は支払い済み）、及び入金日等が関連付けて管理されている。支払い状態は、帳票管理サービスにおいて請求書が発行された際に「未払い」に設定され、入金が確認された際に「支払い済み」に設定される。

本実施形態における請求書情報は、過去に発行された請求書に関する情報を含む履歴情報である。請求書情報によれば、支払い期限日と入金日とを比較することにより、支払い状況（特に、支払い遅延が発生したか否か）を判定することができる。

＜債権保証サーバの機能構成＞
図４に示されているように、本実施形態における債権保証サーバ２０は、債権保証情報記憶部２００、記憶制御部２１及び通信部２２を備える。

債権保証情報記憶部２００は、債権保証仲介サービスで用いる債権保証情報及び履行情報を記憶する。債権保証情報記憶部２００は、例えば、図３に示されているＨＤ５０４を用いて実現される。

記憶制御部２１は、債権保証情報記憶部２００に対するデータの書き込み及び読み出しを行う。記憶制御部２１は、例えば、図３に示されているＨＤ５０４からＲＡＭ５０３上に展開されたプログラムがＣＰＵ５０１及びＨＤＤコントローラ５０５に実行させる処理によって実現される。

通信部２２は、通信ネットワークＮ１を介して他のサーバ、装置、又はシステムと各種データの送受信を行う。通信部２２は、例えば、図３に示されているＨＤ５０４からＲＡＭ５０３上に展開されたプログラムがＣＰＵ５０１及びネットワークＩ／Ｆ５０９に実行させる処理によって実現される。

（債権保証情報テーブル）
図７は、債権保証情報を格納する債権保証情報テーブルの一例を示す概念図である。債権保証情報記憶部２００には、図７に示されているような債権保証情報テーブルによって構成されている債権保証情報管理ＤＢ１１０１が構築されている。債権保証情報テーブルには、サービス利用企業Ａが債権保証契約の対象としている取引先企業Ｂに関して、債権保証の契約状態及び履行履歴を表す情報が格納されている。

図７に示されているように、債権保証情報テーブルでは、テナント毎に、取引先の名称（会社名等）、設定上限金額、債権保証を履行した履歴（履行履歴）、保証開始日、保証終了日、及び保証状態（保証中、保証未開始又は保証終了等）等が関連付けて管理されている。

設定上限金額は、テナントが取引先に対して設定した請求総額の上限である。設定上限金額は、債権保証契約に基づく保証上限金額及びテナントが許容可能なリスク等を鑑みて、テナントが任意に設定することができる。

本実施形態における債権保証情報は、過去に債権保証が履行された請求書に関する情報を含む履歴情報である。債権保証は、例えば回収が困難と判断された債権に対して履行を請求するため、債権保証の履行履歴が存在する場合、当該債権において取引先の債務不履行（例えば踏み倒し等）、倒産（例えば、破産、銀行取引停止又は私的整理等）、又は支払い遅延が発生していたものと判断することができる。

（履行情報テーブル）
図８は、履行情報を格納する履行情報テーブルの一例を示す概念図である。債権保証情報記憶部２００には、図８に示されているような履行情報テーブルによって構成されている履行情報管理ＤＢ１１０２が構築されている。履行情報テーブルには、サービス利用企業Ａが債権保証の履行を申請した履歴を表す情報が格納されている。

図８に示されているように、履行情報テーブルでは、テナントの名称、取引先の名称（会社名等）、請求金額、請求日、支払い期限日、履行状態（履行中又は履行済み）、履行実行日、保証上限金額及び保証期限等が関連付けて管理されている。

保証上限金額は、債権保証契約へ取引先企業Ｂを追加することを申請した際に、債権保証システム３において行われる審査により決定される。

＜債権管理サーバの機能構成＞
図４に示されているように、本実施形態における債権管理サーバ３０は、債権管理情報記憶部３００、画面データ記憶部３１０、記憶制御部３１、通信部３２、情報取得部３３、画面作成部３４、判定部３５及び実行部３６を備える。

債権管理情報記憶部３００は、債権管理サービスで用いる取引状況基準情報、評価条件情報、与信情報、取引状況情報及び債権管理情報を記憶する。

画面データ記憶部３１０は、利用者端末４０に提供（送信）する画面を表示させるための画面データを記憶する。画面データは、例えば、ＨＴＭＬ（HyperText Markup Language）等で記述された画面データであり、JavaScript（登録商標）等で記述されたアプリケーションを含んでもよい。

債権管理情報記憶部３００及び画面データ記憶部３１０は、例えば、図３に示されているＨＤ５０４を用いて実現される。

記憶制御部３１は、債権管理情報記憶部３００及び画面データ記憶部３１０に対するデータの書き込み及び読み出しを行う。記憶制御部３１は、例えば、図３に示されているＨＤ５０４からＲＡＭ５０３上に展開されたプログラムがＣＰＵ５０１及びＨＤＤコントローラ５０５に実行させる処理によって実現される。

通信部３２は、通信ネットワークＮ１を介して他のサーバ、装置、又はシステムと各種データの送受信を行う。通信部３２は、例えば、図３に示されているＨＤ５０４からＲＡＭ５０３上に展開されたプログラムがＣＰＵ５０１及びネットワークＩ／Ｆ５０９に実行させる処理によって実現される。

情報取得部３３は、通信部３２を用いて、取引管理システム２に含まれる各サーバから情報を取得し、記憶制御部３１を用いて、債権管理情報記憶部３００に記憶する。

画面作成部３４は、記憶制御部３１を用いて、画面データ記憶部３１０から画面データを読み出し、通信部３２を用いて、利用者端末４０に画面データを送信する。

判定部３５は、記憶制御部３１を用いて、債権管理情報記憶部３００に記憶されている情報を読み出し、それらの情報に基づいて所定の判断を行う。

実行部３６は、通信部３２を用いて、利用者端末４０から債権保証契約の変更要求を受信し、債権保証契約の変更要求を債権保証サーバ２０に送信する。

情報取得部３３、画面作成部３４、判定部３５及び実行部３６は、例えば、図３に示されているＨＤ５０４からＲＡＭ５０３上に展開されたプログラムがＣＰＵ５０１に実行させる処理によって実現される。

（取引状況基準テーブル）
図９は、取引状況基準情報を格納する取引状況基準テーブルの一例を示す概念図である。債権管理情報記憶部３００には、図９に示されているような取引状況基準テーブルによって構成されている取引状況基準管理ＤＢ１２０１が構築されている。取引状況基準テーブルには、取引先企業Ｂの取引状況を判定する際に用いる取引状況基準に関する情報が格納されている。

図９に示されているように、取引状況基準テーブルでは、テナント毎に、取引状況（例えば良好、可、注意、又は警告など）とスコア（例えば０以上１００以下の整数など）が関連付けて管理されている。また、取引状況の例示として、良好、可、注意、又は警告（あるいは０以上１００以下の整数などスコア形式も含む）を示したが、より細かな段階区分、他の評価文言、ランキング（Ａ、Ｂ、又はＣなど）など利用者への提示形式はこれに限るものではない。

（評価条件情報テーブル）
図１０は、評価条件情報を格納する評価条件情報テーブルの一例を示す概念図である。債権管理情報記憶部３００には、図１０に示されているような評価条件情報テーブルによって構成されている評価条件情報管理ＤＢ１２０２が構築されている。評価条件情報テーブルには、取引先企業Ｂの取引状況を判定する際に用いる取引条件に関する情報が格納されている。

図１０に示されているように、評価条件情報テーブルでは、テナント毎に、評価条件、スコア（０以上１００以下の整数など）、及び注意情報として利用者に提示する表示文字列が関連付けて管理されている。

（与信情報テーブル）
図１１は、与信情報を格納する与信情報テーブルの一例を示す概念図である。債権管理情報記憶部３００には、図１１に示されているような与信情報テーブルによって構成されている与信情報管理ＤＢ１２０３が構築されている。与信情報テーブルには、取引先企業Ｂの取引状況を判定する際に用いる与信に関する情報が格納されている。

図１１に示されているように、与信情報テーブルでは、テナント毎に、取引先の名称（会社名等）及び与信スコア（０以上１００以下の整数など）が関連付けて管理されている。

与信スコアは、例えば、様々な企業の経営等に関する情報を学習した機械学習モデルを用いて算出することができる。また、例えば、信用情報サービス企業が提供する、様々な企業の経営等に関する信頼度を示す信用情報を、与信スコアとして用いてもよい。

本実施形態における与信スコアは、与信スコアが高いほど、債権を回収できる見込みが高いことを表す。例えば、与信スコアが０であれば債権を回収できる見込みが１％であることを表し、１００であれば債権を回収できる見込みが９９％であることを表す。ただし、与信スコアをどのように定義するかは任意に決定すればよい。

（取引状況情報テーブル）
図１２は、取引状況情報を格納する取引状況情報テーブルの一例を示す概念図である。債権管理情報記憶部３００には、図１２に示されているような取引状況情報テーブルによって構成されている取引状況情報管理ＤＢ１２０４が構築されている。取引状況情報テーブルには、取引先企業Ｂの取引状況に関する情報が格納されている。

図１２に示されているように、取引状況情報テーブルでは、テナント毎に、取引先の名称（会社名等）、取引状況、スコア及び注意情報が関連付けて管理されている。取引状況は、取引状況基準テーブルに管理される取引状況のいずれかである。スコアは、取引状況を判定する基準となる取引先毎のスコアである。本実施形態における判定部３５による判定結果である「取引状況」は取引状況情報テーブルにおける取引状況を用いてもよいし、スコアを用いてもよい。言い替えると、後述する図１７の取引状況画面表示には、取引状況情報テーブルの取引状況が表示されても、スコアが取引状況として表示されてもよい。

（債権管理情報テーブル）
図１３は、債権管理情報を格納する債権管理情報テーブルの一例を示す概念図である。債権管理情報記憶部３００には、図１３に示されているような債権管理情報テーブルによって構成されている債権管理情報管理ＤＢ１２０５が構築されている。債権管理情報テーブルには、サービス利用企業Ａが債権保証契約の対象となっている取引先に発行した請求書に基づく債権に関する情報が格納されている。

図１３に示されているように、債権管理情報テーブルでは、テナント毎に、請求先の名称（会社名等）、請求金額、請求日、支払い期限日、支払い状態及び入金日等が関連付けて管理されている。

＜利用者端末の機能構成＞
図４に示されているように、本実施形態における利用者端末４０は、表示制御部４１、通信部４２及び受付部４３を備える。

表示制御部４１は、通信部４２を用いて受信した画面データに基づいて画面を表示する。表示制御部４１は、例えば、利用者端末４０が備えるウェブブラウザ機能である。表示制御部４１は、例えば、図３に示されているＨＤ５０４からＲＡＭ５０３上に展開されたプログラムがＣＰＵ５０１及びディスプレイ５０６に実行させる処理によって実現される。

通信部４２は、通信ネットワークＮ１を介して他のサーバ、装置、又はシステムと各種データの送受信を行う。通信部４２は、例えば、図３に示されているＨＤ５０４からＲＡＭ５０３上に展開されたプログラムがＣＰＵ５０１及びネットワークＩ／Ｆ５０９に実行させる処理によって実現される。

受付部４３は、利用者による各種の操作を受け付ける。受付部４３は、例えば、図３に示されているＣＰＵ５０１からの命令、及びキーボード５１１又はポインティングデバイス５１２によって実現される。

〔情報処理システムの処理手順〕
本実施形態における情報処理システムが実行する情報処理方法の処理手順を、図１４乃至図２５を参照しながら説明する。図１４、図１５、図１８及び図２３は、本実施形態における情報処理方法の処理手順の一例を示すシーケンス図である。本実施形態における情報処理方法は、取引開始処理（図１４参照）、取引状況表示処理（図１５参照）、解除実行処理（図１８参照）、及び解除提案処理（図２３参照）を含む。

＜取引開始処理＞
図１４は、本実施形態における取引開始処理の一例を示すシーケンス図である。

ステップＳ１１において、利用者端末４０が備える受付部４３は、利用者による請求書の発行を指示する操作を受け付ける。受付部４３は、請求書の発行を指示する操作を受け付ける前に、利用者によって入力されたテナントの識別情報であるテナントＩＤ等の認証情報を受け付ける。そして、通信部４２は、認証情報を帳票管理サーバ１０に送信し、帳票管理サーバ１０において所定の認証処理を行う。したがって、利用者が帳票管理サーバ１０において認証された場合のみ、受付部４３は、利用者による請求書の発行を指示する操作を受け付けることができる。

ステップＳ１２において、利用者端末４０が備える通信部４２は、請求書の発行を指示する操作に応じて、請求書の発行要求を帳票管理サーバ１０に送信する。当該発行要求には、利用者によって入力された請求書情報が含まれる。請求書情報には、例えば、請求先の名称、請求金額及び支払い期限日等、請求書に記載する情報が含まれる。

ステップＳ１３において、帳票管理サーバ１０が備える通信部１２は、利用者端末４０が送信した請求書の発行要求を受信する。次に、記憶制御部１１が、受信した請求書情報を請求書情報管理ＤＢ１００２に記憶する。

また、請求書情報に含まれる請求先が取引先情報管理ＤＢ１００１に登録されていない場合には、当該取引先に関する情報を取引先情報管理ＤＢ１００１に記憶する。

ステップＳ１４において、帳票管理サーバ１０が備える通信部１２は、登録した請求書情報に基づいて、請求書を作成し、取引先企業Ｂに送付する。請求書の送付方法は、例えば、印刷した請求書の郵送、請求書を添付した電子メールの送信、請求書を開くＵＲＬ（Uniform Resource Locator）リンクの通知等、様々な方法を用いることができる。

ステップＳ１５において、利用者端末４０が備える受付部４３は、利用者による債権保証契約に取引先を追加する操作を受け付ける。当該操作は、例えば、後述する取引状況画面において行われる。

ステップＳ１６において、利用者端末４０が備える通信部４２は、債権保証契約に取引先を追加する操作に応じて、取引先の追加要求を債権保証サーバ２０に送信する。当該追加要求には、請求書を発行した取引先を表す情報（取引先の名称等）が含まれる。

ステップＳ１７において、債権保証サーバ２０が備える通信部２２は、利用者端末４０が送信した取引先の追加要求を受信する。次に、通信部２２は、受信した取引先の追加要求に基づいて、取引先の追加申請を債権保証システム３に送信する。当該追加申請には、取引先を表す情報が含まれる。

ステップＳ１８において、債権保証システム３は、債権保証サーバ２０から受信した取引先の追加申請を登録する。その後、債権保証サービス企業Ｄの従業員である審査者が、登録されている取引先の追加申請を審査し、その審査結果を債権保証システム３に登録する。なお、上述の審査は、債権保証システム３が所定の条件に基づき取引先の追加申請を自動的に審査してもよく、その方式は問わない。そして、債権保証システム３は、登録された審査結果を、債権保証サーバ２０に返信する。

ステップＳ１９において、債権保証サーバ２０が備える通信部２２は、債権保証システム３が送信した審査結果を受信する。次に、記憶制御部２１が、受信した審査結果に基づいて、追加された取引先に関する債権保証情報を債権保証情報管理ＤＢ１１０１に登録する。このとき、保証開始日及び保証終了日は審査結果に示された日付が設定される。保証状態は、保証開始日が現在日時より後であれば「保証未開始」、現在日時以前であれば「保証中」に設定される。

＜取引状況表示処理＞
図１５は、本実施形態における取引状況表示処理の一例を示すシーケンス図である。

ステップＳ２１において、利用者端末４０が備える受付部４３は、利用者による取引状況画面の表示を指示する操作を受け付ける。取引状況画面の表示を指示する操作は、例えば、債権管理情報の一覧を表示する債権一覧画面が有するボタンを押下する操作等である。

ステップＳ２２において、利用者端末４０が備える通信部４２は、取引状況画面の表示を指示する操作に応じて、取引状況画面を表示させるための画面データの送付を債権管理サーバ３０に要求する。

ステップＳ２３において、債権管理サーバ３０が備える通信部３２は、利用者端末４０が送信した画面データの送付要求を受信する。次に、情報取得部３３は、通信部３２を用いて取引履歴情報の取得を帳票管理サーバ１０に要求する。当該取得要求には、利用者のテナントＩＤが含まれる。

ステップＳ２４において、帳票管理サーバ１０が備える通信部１２は、債権管理サーバ３０が送信した取引履歴情報の取得要求を受信する。次に、記憶制御部１１が、当該テナントの取引先を取引先情報管理ＤＢ１００１から読み出す。続いて、記憶制御部１１は、各取引先の請求書情報を請求書情報管理ＤＢ１００２から読み出す。

この際、記憶制御部１１は、当該テナントの請求書情報テーブルに加えて、他のテナントの請求書情報テーブルからも、当該取引先に関する請求書情報を読み出す。以下、読み出した請求書情報の集合を「取引履歴情報」と呼ぶ。すなわち、取引履歴情報には、当該テナントを取引相手とする取引に関する請求書情報と、他のテナントを取引相手とする取引に関する請求書情報とが含まれる。

ステップＳ２５において、帳票管理サーバ１０が備える通信部１２は、取引履歴情報を債権管理サーバ３０に送信する。債権管理サーバ３０では、通信部３２が、帳票管理サーバ１０が送信した取引履歴情報を受信する。次に、記憶制御部３１が、受信した取引履歴情報を債権管理情報記憶部３００に記憶する。

ステップＳ２６において、債権管理サーバ３０が備える情報取得部３３は、通信部３２を用いて履行履歴情報の取得を債権保証サーバ２０に要求する。当該取得要求には、取得対象とする取引先を表す情報が含まれる。取得対象とする取引先は、取引履歴情報を取得した取引先である。

ステップＳ２７において、債権保証サーバ２０が備える通信部２２は、債権管理サーバ３０が送信した履行履歴情報の取得要求を受信する。次に、記憶制御部２１が、受信した取得要求に含まれる各取引先の債権保証情報を債権保証情報管理ＤＢ１１０１から読み出す。

この際、記憶制御部２１は、当該テナントの債権保証情報テーブルに加えて、他のテナントの債権保証情報テーブルからも、当該取引先に関する債権保証情報を読み出す。以下、読み出した債権保証情報の集合を「履行履歴情報」と呼ぶ。すなわち、履行履歴情報には、当該テナントが契約している債権保証に関する債権保証情報と、他のテナントが契約している債権保証に関する債権保証情報とが含まれる。

ステップＳ２８において、債権保証サーバ２０が備える通信部２２は、履行履歴情報を債権管理サーバ３０に送信する。債権管理サーバ３０では、通信部３２が、債権保証サーバ２０が送信した履行履歴情報を受信する。次に、記憶制御部３１が、受信した履行履歴情報を債権管理情報記憶部３００に記憶する。

ステップＳ２９において、債権管理サーバ３０が備える判定部３５は、記憶制御部３１を用いて、債権管理情報記憶部３００から取引履歴情報、履行履歴情報、取引状況基準情報、評価条件情報及び与信情報を読み出す。次に、判定部３５は、読み出した各情報に基づいて、各取引先の取引状況を判定する。

≪取引状況判定処理≫
ここで、判定部３５が実行する取引状況判定処理（図１５のステップＳ２９）の処理について、図１６を参照しながら、より詳細に説明する。図１６は、本実施形態における取引状況判定処理の一例を示すフローチャートである。

なお、図１６に示す取引状況判定処理は、１つの取引先に対して実行する処理を示したものである。図１６に示す取引状況判定処理は、各取引先について繰り返し実行される。

ステップＳ２９－１において、判定部３５は、スコア及び注意情報を表す変数を初期化する。具体的には、スコアを０に設定し、注意情報を空文字列に設定する。

ステップＳ２９－２において、判定部３５は、評価条件の番号を表す変数ｎを初期化する。具体的には、変数ｎを１に設定する。

ステップＳ２９－３において、判定部３５は、取引先の請求書情報、債権保証情報及び与信情報に基づいて、評価条件情報に含まれるｎ番目の評価条件に一致するか否かを判定する。ｎ番目の評価条件に一致する場合（ＹＥＳ）、判定部３５は、ステップＳ２９－４に処理を進める。ｎ番目の評価条件に一致しない場合（ＮＯ）、判定部３５は、ステップＳ２９－４をスキップして、ステップＳ２９－５に処理を進める。

評価条件は、例えば、取引履歴に関する条件、債権保証の履行履歴に関する条件、取引金額に関する条件、及び与信情報に関する条件等がある。

取引履歴に関する条件とは、例えば、取引先に対する債権の履行遅延回数である。履行遅延回数は、債権の支払い期限日において入金がされていない請求書の数である。具体的には、請求書情報において、支払い期限日よりも入金日が遅れている請求書、又は支払い期限日を超過しているが支払い状態が「未払い」である請求書の数である。

例えば、「自社で１回の遅延」という評価条件は、利用者のテナントに関する請求書情報テーブルにおいて、履行が遅延した請求書が１件あることを表す。また、例えば、「他社で１回の遅延」という評価条件は、他のテナントに関する請求書情報テーブルにおいて、履行が遅延した請求書が１件あることを表す。

債権保証の履行履歴に関する条件とは、例えば、取引先に対する債権保証の履行回数である。債権保証の履行回数は、具体的には、債権保証情報において、履行履歴に設定されている履行日の数である。

例えば、「自社で１回の履行」という評価条件は、利用者のテナントに関する債権保証情報テーブルにおいて、履行履歴が１件あることを表す。また、例えば、「他社で１回の遅延」という評価条件は、他のテナントに関する債権保証情報テーブルにおいて、履行履歴が１件あることを表す。

取引金額に関する条件とは、例えば、所定期間における取引先への請求額の総額（取引総額）が予め設定した上限額を超えているか否かである。具体的には、請求日が所定期間（例えば、当月）に含まれる請求書情報の請求金額の総和を計算し、債権保証情報の設定上限金額と比較する。

与信情報に関する条件とは、例えば、取引先の与信スコアが予め設定した閾値以上であるか否かである。具体的には、与信情報の与信スコアと評価条件で設定されたスコアとを比較する。

ステップＳ２９－４において、判定部３５は、スコアを表す変数に、評価条件情報に含まれるｎ番目のスコアを加算する。また、判定部３５は、注意情報を表す変数に、評価条件情報に含まれるｎ番目の表示文字列を追加する。

例えば、「自社で１回の履行」という評価条件に一致する場合、スコアに１が加算され、注意情報に「自社で遅延傾向あり」という文字列が追加される。

ステップＳ２９－５において、判定部３５は、変数ｎが定数Ｎと等しいか否かを判定する。定数Ｎは、評価条件情報に含まれる評価条件の数である。変数ｎと評価条件数Ｎとが等しくない場合（ＮＯ）、判定部３５は、ステップＳ２９－６に処理を進める。変数ｎと評価条件数Ｎとが等しい場合（ＹＥＳ）、判定部３５は、ステップＳ２９－７に処理を進める。

ステップＳ２９－６において、判定部３５は、変数ｎをインクリメントする。すなわち、変数ｎをｎ＋１に設定する。その後、判定部３５は、ステップＳ２９－３に処理を戻す。

ステップＳ２９－７において、判定部３５は、取引状況基準に基づいて、スコアを表す変数を分類し、取引状況を決定する。例えば、スコアが０～４であれば取引状況は「良好」とする。スコアが５～９であれば取引状況は「可」とする。スコアが１０～１９であれば取引状況は「注意」とする。スコアが２０以上であれば取引状況は「警告」とする。

ステップＳ２９－８において、判定部３５は、記憶制御部３１を用いて、取引先の取引状況、スコア及び注意情報を取引状況情報管理ＤＢ１２０４に登録する。

図１５に戻って説明する。ステップＳ３０において、債権管理サーバ３０が備える記憶制御部３１は、取引状況画面を表示させるための画面データを画面データ記憶部３１０から読み出す。次に、画面作成部３４は、記憶制御部３１が読み出した画面データに基づいて、利用者端末４０に表示するための画面データを生成する。このとき、画面作成部３４は、各取引先の取引状況及び債権保証の契約状態を、取引状況画面を表示させるための画面データに埋め込む。

ステップＳ３１において、債権管理サーバ３０が備える通信部３２は、取引状況画面を表示させるための画面データを利用者端末４０に送信する。

ステップＳ３２において、利用者端末４０が備える通信部４２は、債権管理サーバ３０から取引状況画面を表示させるための画面データを受信する。次に、表示制御部４１は、受信した画面データに基づいて、取引状況画面をディスプレイ５０６に表示する。

≪取引状況画面≫
ここで、本実施形態における取引状況画面について、図１７を参照しながら説明する。図１７は、本実施形態における取引状況画面の一例を示す図である。

図１７に示すように、本実施形態における取引状況画面２０００は、対象期間表示欄２００１、評価期間選択欄２００２、取引先名表示欄２０１１、取引先選択欄２０１２、契約状態表示欄２０１３、取引状況表示欄２０１４、取引金額表示欄２０１５、注意情報表示欄２０１６、解除実行ボタン２０２１、追加実行ボタン２０２２、解除提案ボタン２０３１及び追加提案ボタン２０３２を有する。

これらのうち、取引先名表示欄２０１１、取引先選択欄２０１２、契約状態表示欄２０１３、取引状況表示欄２０１４、取引金額表示欄２０１５及び注意情報表示欄２０１６は、当該テナントと取引のあるすべての取引先についてそれぞれ表示される。

対象期間表示欄２００１は、取引状況を評価する対象期間を表示する。この対象期間は、例えば、取引状況判定処理において評価に用いる請求書情報及び債権保証情報の期間として用いられる。

評価期間選択欄２００２は、取引状況の評価に用いる履歴情報の対象期間を選択する。この対象期間は、例えば、債権の履行遅延回数又は債権保証の履行回数等を集計する期間として用いられる。

取引先名表示欄２０１１、取引状況表示欄２０１４及び注意情報表示欄２０１６は、それぞれ取引状況情報の取引先、取引状況及び注意情報を表示する。取引状況表示欄２０１４には、取引状況情報のスコアを表示してもよい。

契約状態表示欄２０１３は、債権保証の契約状態（取引先に対する保証の有無など）を表示する。債権保証の契約状態は、債権保証情報の保証状態、保証開始日及び保証終了日に基づいて決定される。すなわち、現在日時が保証開始日以降保証終了日以前であり、保証状態が「保証中」の場合、「保証有り」と表示され、それ以外の場合、「保証無し」と表示される。なお、保証状態の表示は、上述のような保証有り／無しの形式に限るものではない。利用者に対して債権保証の対象となっているかが表示されればよく、「保証中」「適用中」「対象」「有効」などの文言を用いて表示してもよい。

取引金額表示欄２０１５は、所定期間における当該取引先との取引金額をグラフ表示する。取引金額表示欄２０１５に表示される売掛、回収及び見積等の金額は、取引履歴情報に基づいて計算される。取引金額表示欄２０１５に表示される保証は、履行情報の保証上限金額を表す。自社設定上限額は、債権保証情報の設定上限金額を表す。

取引状況画面２０００において、利用者が取引先選択欄２０１２により取引先を選択して解除実行ボタン２０２１を押下すると、受付部４３が解除実行画面を表示する操作を受け付ける。受付部４３が解除実行画面を表示する操作を受け付けると、後述の解除実行処理が実行される。

取引状況画面２０００において、利用者が取引先選択欄２０１２により取引先を選択して追加実行ボタン２０２２を押下すると、受付部４３が追加実行画面を表示する操作を受け付ける。受付部４３が追加実行画面を表示する操作を受け付けると、後述の追加実行処理が実行される。

取引状況画面２０００において、利用者が解除提案ボタン２０３１を押下すると、受付部４３が解除提案画面を表示する操作を受け付ける。受付部４３が解除提案画面を表示する操作を受け付けると、後述の解除提案処理が実行される。

取引状況画面２０００において、利用者が追加提案ボタン２０３２を押下すると、受付部４３が追加提案画面を表示する操作を受け付ける。受付部４３が追加提案画面を表示する操作を受け付けると、後述の追加提案処理が実行される。

＜解除実行処理＞
図１８は、本実施形態における解除実行処理の一例を示すシーケンス図である。

ステップＳ４１において、利用者端末４０が備える受付部４３は、利用者による解除実行画面を表示する操作を受け付ける。当該操作は、債権保証契約を解除する取引先を特定して行われる。なお、利用者が特定する取引先は複数であってもよい。

表示制御部４１は、解除実行画面を表示する操作に応じて、解除実行画面をディスプレイ５０６に表示する。解除実行画面の画面データは、取引状況画面の画面データに含まれていてもよいし、通信部４２を用いて債権管理サーバ３０から解除実行画面の画面データを取得してもよい。

≪解除実行画面≫
ここで、本実施形態における解除実行画面について、図１９を参照しながら説明する。図１９は、本実施形態における解除実行画面の一例を示す図である。

図１９に示されているように、本実施形態における解除実行画面２１００は、取引先表示欄２１０１、ＯＫボタン２１０８及びキャンセルボタン２１０９を有する。取引先表示欄２１０１には、利用者が特定した取引先に関する取引先名、当月の取引総額及び取引状況が表示される。

解除実行画面２１００において、利用者がＯＫボタン２１０８を押下すると、受付部４３が債権保証契約の解除操作を受け付ける。解除実行画面２１００において、利用者がキャンセルボタン２１０９を押下すると、表示制御部４１が解除実行画面２１００を閉じ、取引状況画面２０００を再度表示する。

図１８に戻って説明する。ステップＳ４２において、利用者端末４０が備える通信部４２は、債権保証契約の解除操作に応じて、債権保証契約の解除要求を債権管理サーバ３０に送信する。当該解除要求には、利用者が特定した取引先を表す情報が含まれる。

ステップＳ４３において、債権管理サーバ３０が備える通信部３２は、利用者端末４０が送信した債権保証契約の解除要求を受信する。次に、実行部３６は、通信部３２を用いて債権保証契約の解除を債権保証サーバ２０に要求する。

ステップＳ４４において、債権保証サーバ２０が備える通信部２２は、債権管理サーバ３０が送信した債権保証契約の解除要求を受信する。次に、通信部２２は、受信した債権保証契約の解除要求に基づいて、債権保証契約の解除申請を債権保証システム３に送信する。当該解除申請には、取引先を表す情報が含まれる。

債権保証システム３は、債権保証サーバ２０から受信した債権保証契約の解除申請を登録する。その後、債権保証サービス企業Ｄの従業員である審査者が、登録されている債権保証契約の解除申請を審査し、その審査結果を債権保証システム３に登録する。そして、債権保証システム３は、登録された審査結果を、債権保証サーバ２０に返信する。なお、債権保証契約の解除申請に対しては、審査を不要としてもよい。この場合、債権保証システム３は、債権保証契約の解除申請が登録されると、自動的に審査が完了した旨の審査結果を登録する。

ステップＳ４５において、債権保証サーバ２０が備える通信部２２は、債権保証システム３が送信した審査結果を受信する。次に、記憶制御部２１が、受信した審査結果に基づいて、解除された取引先に関する債権保証情報を更新する。このとき、保証終了日は審査結果に示された日付が設定される。保証状態は、「保証終了」に設定される。

続いて、債権保証サーバ２０が備える通信部２２は、債権保証契約の解除通知を債権管理サーバ３０に送信する。当該解除通知には、取引先を表す情報が含まれる。

ステップＳ４６において、債権管理サーバ３０が備える判定部３５は、記憶制御部３１を用いて、債権管理情報記憶部３００から債権保証情報及び取引状況情報を読み出す。次に、判定部３５は、読み出した各情報に基づいて、債権保証契約に追加可能な取引先があるか否かを判定する。

≪追加取引先判定処理≫
ここで、判定部３５が実行する追加取引先判定処理（図１８のステップＳ４６）の処理について、図２０を参照しながら、より詳細に説明する。図２０は、本実施形態における追加取引先判定処理の一例を示すフローチャートである。

ステップＳ４６－１において、判定部３５は、保証無しの取引先があるか否かを判定する。保証無しの取引先がある場合（ＹＥＳ）、判定部３５は、ステップＳ４６－２へ処理を進める。保証無しの取引先がない場合（ＮＯ）、判定部３５は、追加取引先判定処理を終了する。

ステップＳ４６－２において、判定部３５は、保証無しの取引先のうち、取引状況が「注意」又は「警告」である取引先があるか否かを判定する。「注意」又は「警告」の取引先がある場合（ＹＥＳ）、判定部３５は、ステップＳ４６－３へ処理を進める。「注意」又は「警告」の取引先がない場合（ＮＯ）、判定部３５は、追加取引先判定処理を終了する。

ステップＳ４６－３において、判定部３５は、保証無しかつ取引状況が「注意」又は「警告」である取引先を、債権保証契約への追加を提案する取引先（以下、「追加提案取引先」とも呼ぶ）として決定する。次に、判定部３５は、追加提案取引先に関する情報を画面作成部３４に出力する。この際、判定部３５は、追加提案取引先に関する情報を、取引状況及び取引総額の降順でソートする。

上記の追加取引先判定処理では、取引状況が「注意」又は「警告」である取引先を提案対象の取引先としたが、提案対象とする取引状況は限定されない。例えば、取引状況が「警告」である取引先のみを提案対象の取引先としてもよい。

図１８に戻って説明する。ステップＳ４７において、債権管理サーバ３０が備える記憶制御部３１は、追加提案画面を表示させるための画面データを画面データ記憶部３１０から読み出す。次に、画面作成部３４は、記憶制御部３１が読み出した画面データに基づいて、利用者端末４０に表示するための画面データを生成する。このとき、画面作成部３４は、追加提案取引先に関する情報を、追加提案画面を表示させるための画面データに埋め込む。

ステップＳ４８において、債権管理サーバ３０が備える通信部３２は、追加提案画面を表示させるための画面データを利用者端末４０に送信する。

ステップＳ４９において、利用者端末４０が備える通信部４２は、債権管理サーバ３０から追加提案画面を表示させるための画面データを受信する。次に、表示制御部４１は、受信した画面データに基づいて、追加提案画面をディスプレイ５０６に表示する。

≪追加提案画面≫
ここで、本実施形態における追加提案画面について、図２１を参照しながら説明する。図２１は、本実施形態における追加提案画面の一例を示す図である。

図２１に示されているように、本実施形態における追加提案画面２２００は、取引先表示欄２２０１、ＯＫボタン２２０８及びキャンセルボタン２２０９を有する。取引先表示欄２２０１には、債権保証契約への追加を提案する取引先に関する取引先名、当月の取引総額及び取引状況が選択可能に表示される。

取引先表示欄２２０１に複数の取引先を表示する場合、取引状況及び取引総額でソートして表示するとよい。初期表示では、取引先表示欄２２０１に表示されるすべての取引先が選択されているとよい。

追加提案画面２２００において、利用者がＯＫボタン２２０８を押下すると、受付部４３が債権保証契約の追加操作を受け付ける。追加提案画面２２００において、利用者がキャンセルボタン２２０９を押下すると、表示制御部４１が追加提案画面２２００を閉じ、取引状況画面２０００を再度表示する。

図１８に戻って説明する。ステップＳ５０において、利用者端末４０が備える通信部４２は、債権保証契約の追加操作に応じて、債権保証契約の追加要求を債権管理サーバ３０に送信する。当該追加要求には、利用者が特定した取引先を表す情報が含まれる。

ステップＳ５１において、債権管理サーバ３０が備える通信部３２は、利用者端末４０が送信した債権保証契約の追加要求を受信する。次に、実行部３６は、通信部３２を用いて債権保証契約の追加を債権保証サーバ２０に要求する。

ステップＳ５２において、債権保証サーバ２０が備える通信部２２は、債権管理サーバ３０が送信した債権保証契約の追加要求を受信する。次に、通信部２２は、受信した債権保証契約の追加要求に基づいて、債権保証契約の追加申請を債権保証システム３に送信する。当該追加申請には、取引先を表す情報が含まれる。

債権保証システム３は、債権保証サーバ２０から受信した債権保証契約の追加申請を登録する。その後、債権保証サービス企業Ｄの従業員である審査者が、登録されている債権保証契約の追加申請を審査し、その審査結果を債権保証システム３に登録する。そして、債権保証システム３は、登録された審査結果を、債権保証サーバ２０に返信する。

ステップＳ５３において、債権保証サーバ２０が備える通信部２２は、債権保証システム３が送信した審査結果を受信する。次に、記憶制御部２１が、受信した審査結果に基づいて、追加された取引先に関する債権保証情報を更新する。このとき、保証開始日及び保証終了日は審査結果に示された日付が設定される。保証状態は、「保証中」に設定される。

続いて、債権保証サーバ２０が備える通信部２２は、債権保証契約の追加通知を債権管理サーバ３０に送信する。当該追加通知には、取引先を表す情報が含まれる。

ステップＳ５４において、債権管理サーバ３０が備える通信部３２は、債権保証サーバ２０が送信した債権保証契約の追加通知を受信する。次に、通信部３２は、債権保証契約の追加通知を利用者端末４０に送信する。

利用者端末４０では、通信部４２が、債権管理サーバ３０が送信した債権保証契約の追加通知を受信する。次に、表示制御部４１が、債権保証契約の追加通知をディスプレイ５０６に表示する。

＜追加実行処理＞
本実施形態における追加実行処理では、まず、利用者端末４０が備える受付部４３が、利用者による追加実行画面を表示する操作を受け付ける。当該操作は、債権保証契約に追加する取引先を特定して行われる。なお、利用者が特定する取引先は複数であってもよい。

表示制御部４１は、追加実行画面を表示する操作に応じて、追加実行画面をディスプレイ５０６に表示する。追加実行画面の画面データは、取引状況画面の画面データに含まれていてもよいし、通信部４２を用いて債権管理サーバ３０から追加実行画面の画面データを取得してもよい。

≪追加実行画面≫
ここで、本実施形態における追加実行画面について、図２２を参照しながら説明する。図２２は、本実施形態における追加実行画面の一例を示す図である。

図２２に示されているように、本実施形態における追加実行画面２３００は、取引先表示欄２３０１、ＯＫボタン２３０８及びキャンセルボタン２３０９を有する。取引先表示欄２３０１には、利用者が特定した取引先に関する取引先名、当月の取引総額及び取引状況が表示される。

追加実行画面２３００において、利用者がＯＫボタン２３０８を押下すると、受付部４３が債権保証契約の追加操作を受け付ける。追加実行画面２３００において、利用者がキャンセルボタン２３０９を押下すると、表示制御部４１が追加実行画面２３００を閉じ、取引状況画面２０００を再度表示する。

受付部４３が債権保証契約の追加操作を受け付けた後に行われる処理は、図１８に示した解除実行処理のステップＳ５０からＳ５４と同様である。

＜解除提案処理＞
図２３は、本実施形態における解除提案処理の一例を示すシーケンス図である。

ステップＳ６１において、利用者端末４０が備える受付部４３は、利用者による解除提案画面を表示する操作を受け付ける。

ステップＳ６２において、利用者端末４０が備える通信部４２は、解除提案画面を表示する操作に応じて、解除取引先の提案要求を債権管理サーバ３０に送信する。当該提案要求には、利用者のテナントＩＤが含まれる。

ステップＳ６３において、債権管理サーバ３０が備える通信部３２は、利用者端末４０が送信した解除取引先の提案要求を受信する。次に、判定部３５は、記憶制御部３１を用いて、債権管理情報記憶部３００から債権保証情報及び取引状況情報を読み出す。次に、判定部３５は、読み出した各情報に基づいて、債権保証契約から解除可能な取引先があるか否かを判定する。

≪解除取引先判定処理≫
ここで、判定部３５が実行する解除取引先判定処理（図２３のステップＳ６３）の処理について、図２４を参照しながら、より詳細に説明する。図２４は、本実施形態における解除取引先判定処理の一例を示すフローチャートである。

ステップＳ６３－１において、判定部３５は、保証有りの取引先があるか否かを判定する。保証有りの取引先がある場合（ＹＥＳ）、判定部３５は、ステップＳ６３－２へ処理を進める。保証有りの取引先がない場合（ＮＯ）、判定部３５は、解除取引先判定処理を終了する。

ステップＳ６３－２において、判定部３５は、保証有りの取引先のうち、取引状況が「良好」である取引先があるか否かを判定する。「良好」の取引先がある場合（ＹＥＳ）、判定部３５は、ステップＳ６３－３へ処理を進める。「良好」の取引先がない場合（ＮＯ）、判定部３５は、解除取引先判定処理を終了する。

ステップＳ６３－３において、判定部３５は、保証有りかつ取引状況が「良好」である取引先のうち、保証開始日から所定期間を経過していない取引先を除外する。所定期間は、取引の実情に応じて任意に定めればよいが、例えば６か月である。

ステップＳ６３－４において、判定部３５は、保証有りかつ取引状況が「良好」である取引先を、債権保証契約からの解除を提案する取引先（以下、「解除提案取引先」とも呼ぶ）として決定する。次に、判定部３５は、解除提案取引先に関する情報を画面作成部３４に出力する。この際、判定部３５は、解除提案取引先に関する情報を、取引総額の昇順でソートする。

上記の解除取引先判定処理では、取引状況が「良好」である取引先を提案対象の取引先としたが、提案対象とする取引状況は限定されない。例えば、取引状況が「良好」又は「可」である取引先を提案対象の取引先としてもよい。

図２３に戻って説明する。ステップＳ６４において、債権管理サーバ３０が備える記憶制御部３１は、解除提案画面を表示させるための画面データを画面データ記憶部３１０から読み出す。次に、画面作成部３４は、記憶制御部３１が読み出した画面データに基づいて、利用者端末４０に表示するための画面データを生成する。このとき、画面作成部３４は、解除提案取引先に関する情報を、解除提案画面を表示させるための画面データに埋め込む。

ステップＳ６５において、債権管理サーバ３０が備える通信部３２は、解除提案画面を表示させるための画面データを利用者端末４０に送信する。

ステップＳ６６において、利用者端末４０が備える通信部４２は、債権管理サーバ３０から解除提案画面を表示させるための画面データを受信する。次に、表示制御部４１は、受信した画面データに基づいて、解除提案画面をディスプレイ５０６に表示する。

≪解除提案画面≫
ここで、本実施形態における解除提案画面について、図２５を参照しながら説明する。図２５は、本実施形態における解除提案画面の一例を示す図である。

図２５に示されているように、本実施形態における解除提案画面２４００は、取引先表示欄２４０１、ＯＫボタン２４０８及びキャンセルボタン２４０９を有する。取引先表示欄２４０１には、債権保証契約からの解除を提案する取引先に関する取引先名、当月の取引総額及び取引状況が選択可能に表示される。

取引先表示欄２４０１に複数の取引先を表示する場合、取引総額でソートして表示するとよい。初期表示では、取引先表示欄２４０１に表示されるすべての取引先が選択されているとよい。

解除提案画面２４００において、利用者がＯＫボタン２４０８を押下すると、受付部４３が債権保証契約の解除操作を受け付ける。解除提案画面２４００において、利用者がキャンセルボタン２４０９を押下すると、表示制御部４１が解除提案画面２４００を閉じ、取引状況画面２０００を再度表示する。

受付部４３が債権保証契約の解除操作を受け付けた後に行われる処理は、図１８に示した解除実行処理のステップＳ４２からＳ５４と同様である。

＜追加提案処理＞
本実施形態における追加実行処理では、まず、利用者端末４０が備える受付部４３が、利用者による追加提案画面を表示する操作を受け付ける。表示制御部４１は、追加提案画面を表示する操作に応じて、図２１に示した追加提案画面２２００をディスプレイ５０６に表示する。

追加提案画面２２００において、利用者がＯＫボタン２２０８を押下すると、受付部４３が債権保証契約を追加する操作を受け付ける。

受付部４３が債権保証契約の追加操作を受け付けた後に行われる処理は、図１８に示した解除実行処理のステップＳ５０からＳ５４と同様である。

〔実施形態の主な効果〕
本実施形態における債権管理サーバ３０は、取引管理システム２に含まれる他のサーバから取得した履歴情報に基づいて、取引先の取引状況を判定し、各取引先の取引状況及び債権保証の契約状態を表示する画面を、利用者端末４０に表示される。これにより、利用者は、債権保証契約の対象とする取引先を選択するために有益な情報を得ることができる。したがって、本実施形態における情報処理システムによれば、利用者が債権保証契約の対象とする取引先を適切に選択することができる。

また、本実施形態における債権管理サーバ３０は、ある取引先を債権保証契約から解除した場合に、債権保証契約へ追加する取引先を提案するための追加提案画面を、利用者端末４０に表示させる。これにより、利用者は同程度の保険料で、より適切な取引先を債権保証契約の対象とすることができる。また、債権保証サービス企業Ｄにとっては、自然な流れで債権保証契約の利用継続を利用者に提案することができ、保険料収入の減少を防ぐことができる。

さらに、本実施形態における債権管理サーバ３０は、債権保証契約から解除する取引先を提案するための解除提案画面を、利用者端末４０に表示させる。このとき、保証開始日から所定期間を経過していない取引先は提案から除外する制御を行う。これにより、利用者は、多数の取引先がある場合でも債権保証契約から解除する取引先を適切に選択することができる。

特に、取引期間が短い新規の取引先を債権保証契約の対象とする場合、取引状況に問題がなくとも一定期間は債権保証契約の対象としておくことが望ましい。本実施形態における債権管理サーバ３０によれば、そのような取引先を債権保証契約の解除を提案しないように制御することができる。

［補足］
上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたASIC（Application Specific Integrated Circuit）、DSP（digital signal processor）、FPGA（field programmable gate array）や従来の回路モジュール等のデバイスを含むものとする。

実施例に記載された装置群は、本明細書に開示された実施形態を実施するための複数のコンピューティング環境のうちの１つを示すものにすぎない。ある実施形態では、帳票管理サーバ１０、債権保証サーバ２０及び債権管理サーバ３０は、サーバクラスタといった複数のコンピューティングデバイスを含む。複数のコンピューティングデバイスは、ネットワークや共有メモリなどを含む任意のタイプの通信リンクを介して互いに通信するように構成されており、本明細書に開示された処理を実施する。

以上、本発明の実施の形態について詳述したが、本発明はこれらの実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形又は変更が可能である。

１ 情報処理システム
２ 取引管理システム
３ 債権保証システム
１０ 帳票管理サーバ
２０ 債権保証サーバ
３０ 債権管理サーバ
４０ 利用者端末
１１，２１，３１ 記憶制御部
１２，２２，３２，４２ 通信部
３３ 情報取得部
３４ 画面作成部
３５ 判定部
３６ 実行部
４１ 表示制御部
４３ 受付部
１００ 帳票管理情報記憶部
２００ 債権保証情報記憶部
３００ 債権管理情報記憶部
３１０ 画面データ記憶部

特開２００４－７０９７５号公報

Claims (16)

1. 利用者が用いる利用者端末とネットワークを介して通信可能な情報処理装置であって、
   取引先の支払い状態を含む履歴情報を取得する取得部と、
   前記履歴情報を用いて前記取引先の取引状況を判定する判定部と、
   前記取引状況及び債権保証の契約状態を表示するための画面データを前記利用者端末に送信する通信部と、
   を備える情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記履歴情報は、前記取引先に関する取引履歴及び前記取引先に対する債権保証の履行履歴を含む、
   情報処理装置。
3. 請求項２に記載の情報処理装置であって、
   前記履歴情報は、前記取引先と前記利用者以外の取引相手との取引に関する前記履歴情報を含む、
   情報処理装置。
4. 請求項３に記載の情報処理装置であって、
   前記通信部は、前記債権保証から前記取引先を解除する解除実行画面を表示させるための画面データを前記利用者端末に送信する、
   情報処理装置。
5. 請求項４に記載の情報処理装置であって、
   前記通信部は、前記取引状況に基づいて前記債権保証に追加する前記取引先を提案する追加提案画面を表示させるための画面データを前記利用者端末に送信する、
   情報処理装置。
6. 請求項３に記載の情報処理装置であって、
   前記通信部は、前記取引状況に基づいて前記債権保証から解除する前記取引先を提案する解除提案画面を表示させるための画面データを前記利用者端末に送信する、
   情報処理装置。
7. 請求項６に記載の情報処理装置であって、
   前記解除提案画面は、前記債権保証の保証開始日から所定期間を経過していない前記取引先を除外して前記提案を行う、
   情報処理装置。
8. 利用者が用いる利用者端末と情報処理装置とがネットワークを介して通信可能な情報処理システムであって、
   前記情報処理装置は、
   取引先の支払い状態を含む履歴情報を取得する取得部と、
   前記履歴情報を用いて前記取引先の取引状況を判定する判定部と、
   前記取引状況及び債権保証の契約状態を表示するための画面データを前記利用者端末に送信する通信部と、
   を備え、
   前記利用者端末は、
   前記画面データを前記情報処理装置から受信する通信部と、
   前記画面データに基づいて前記取引状況及び債権保証の契約状態を表示する画面を表示する表示制御部と、
   を備える情報処理システム。
9. 利用者が用いる利用者端末とネットワークを介して通信可能なコンピュータが、
   取引先の支払い状態を含む履歴情報を取得する取得手順と、
   前記履歴情報を用いて前記取引先の取引状況を判定する判定手順と、
   前記取引状況及び債権保証の契約状態を表示するための画面データを前記利用者端末に送信する通信手順と、
   を実行する情報処理方法。
10. 請求項９に記載の情報処理方法であって、
    前記履歴情報は、前記取引先に関する取引履歴及び前記取引先に対する債権保証の履行履歴を含む、
    情報処理方法。
11. 請求項１０に記載の情報処理方法であって、
    前記履歴情報は、前記取引先と前記利用者以外の取引相手との取引に関する前記履歴情報を含む、
    情報処理方法。
12. 請求項１１に記載の情報処理方法であって、
    前記通信手順は、前記債権保証から前記取引先を解除する解除実行画面を表示させるための画面データを前記利用者端末にさらに送信する、
    情報処理方法。
13. 請求項１２に記載の情報処理方法であって、
    前記通信手順は、前記取引状況に基づいて前記債権保証に追加する前記取引先を提案する追加提案画面を表示させるための画面データを前記利用者端末にさらに送信する、
    情報処理方法。
14. 請求項１１に記載の情報処理方法であって、
    前記通信手順は、前記取引状況に基づいて前記債権保証から解除する前記取引先を提案する解除提案画面を表示させるための画面データを前記利用者端末にさらに送信する、
    情報処理方法。
15. 請求項１４に記載の情報処理方法であって、
    前記解除提案画面は、前記債権保証の保証開始日から所定期間を経過していない前記取引先を除外して前記提案を行う、
    情報処理方法。
16. 利用者が用いる利用者端末とネットワークを介して通信可能なコンピュータに、
    取引先の支払い状態を含む履歴情報を取得する取得手順と、
    前記履歴情報を用いて前記取引先の取引状況を判定する判定手順と、
    前記取引状況及び債権保証の契約状態を表示するための画面データを前記利用者端末に送信する通信手順と、
    を実行させるためのプログラム。

Images