JP6437155B1 - 支払管理サーバ、支払管理システム、支払管理方法及び支払管理プログラム - Google Patents

Abstract

【課題】給与の即時支払い及び労働者の意思表示に基づく一定の支払いが可能な支払管理サーバ、支払管理システム、支払管理方法及び支払管理プログラムを提供する。【解決手段】給与等の支払管理を行う支払管理システム１の支払管理サーバ１００は、その機能として、スタッフの住所及び勤務可能時間と支払会社の住所及び就業可能時間とをマッチングするマッチング部１３１と、スタッフが勤務した勤務情報を受け付ける勤務情報受付部１３２と、勤務情報への承認を受け付ける承認受付部１３３と、スタッフの意思表示に基づいて指定した一時金の支払可能な最大金額を算出する最大金額算出部１３４と、管理会社から支払会社へ貸出を行い、支払会社からスタッフへ資金移動を行う入金情報生成部１３５と、入金情報送信部１３６と、管理会社から支払会社への貸出に対する資金請求情報を生成する精算情報生成部１３７と、精算情報送信部１３８とを備える。【選択図】図３

Description

本開示は、管理会社に登録されているスタッフへの支払いを管理する支払管理サーバ、支払管理システム、支払管理方法及び支払管理プログラムに関する。

昨今、労働力不足が顕著となっており、特に小売店等で非正規雇用のアルバイトやパートタイマーを募集しても、なかなか応募者がいないという現状がある。そのため、学生や主婦といった人達の空き時間を利用して働いてもらうようにするため、短期間、例えば１日だけ働いてもらう、または短時間、例えば４時間だけ働いてもらう、というように、いわゆる日雇いのような雇用を促進する雇用のシェアリングが普及しつつある。

このような雇用のシェアリングを実現するために、例えば、求職者と雇用者とのマッチングを支援する求人マッチングシステムが知られている（例えば、特許文献１参照。）。特許文献１に開示されているシステムは、特に日雇いの求人についてのマッチングを支援するシステムであり、求人情報の配信、適切な人材の選定補助、実際の契約の雇用契約の締結、その後の求職者の勤務まで短時間で行うことを可能としている。

また、このような雇用のシェアリングでは、日雇いのような労働者に対して迅速に給与を支払うことも求められているが、労働者が学生等の場合、銀行口座を保有していない場合もある。そのため、労働者が銀行口座を保有していない場合であっても本人確認を行って給与の即時支払いを可能とするシステムが知られている（例えば、特許文献２、３参照。）。特許文献２に開示されているシステムは、顔認証技術を使用して本人確認を行うシステムであり、特許文献３に開示されているシステムは、支払者（雇用者）の口座情報や労働者の認証情報を暗号化した支払券を発行するシステムであり、本人確認を迅速に行うことで、給与の即時支払いを可能としている。

特開２０１７−１１７３７５号公報 特許第６３０１５１９号公報 特開２００９−１５１５５３号公報

ところで、給与は雇用者が労働者に直接支払うのが原則であるが、例えばコンビニエンスストアのようなフランチャイズチェーンの場合、雇用者であるオーナーはあまり現金を保有しておらず、特許文献２，３に開示されているようなシステムを利用しても、給与の支払者である雇用者が現金を自己の金融機関口座に入金していないため、給与の即時支払いは困難な場合もある。また、オーナーの現金に余裕がある場合であっても、支払いのタイミングごとに出金口座に現金を補充する手続が煩雑となる。給与の即時支払いに限らず、通常、月次の締めを経てから支払われる給与であっても、必要な場合に支払いを受けることが可能な支払システムが望まれていた。

そこで、本開示では、例えばフランチャイズチェーンのオーナーのようにあまり現金を保有していない雇用者であっても、給与の即時支払いが可能であり、労働者の意思表示に基づいて一定の支払いを受けることが可能な支払管理サーバ、支払管理システム、支払管理方法及び支払管理プログラムについて説明する。

本開示の一態様における支払管理サーバは、管理会社に登録されているスタッフへの支払いを管理する支払管理サーバであって、スタッフが有するアカウントを含む属性情報を記憶するスタッフ情報記憶部と、スタッフの勤務に対して支払いを行う支払会社が有するアカウントを含む属性情報を記憶する会社情報記憶部と、支払会社におけるスタッフの勤務情報を受け付ける勤務情報受付部と、勤務情報に基づき、スタッフが受け取れる最大金額を算出する最大金額算出部と、最大金額を限度とするスタッフの希望金額を管理会社から支払会社への貸出を行うために支払会社が有するアカウントへ入金する貸出情報を生成し、希望金額をスタッフへ資金移動するために支払会社が有するアカウントからスタッフが有するアカウントへ入金する移動情報を生成する入金情報生成部と、貸出の金額に基づき、支払会社への資金請求情報を生成する精算情報生成部と、を備える。

本開示の一態様における支払管理システムは、管理会社に登録されているスタッフへの支払いを管理する支払管理サーバと、スタッフの勤務に対して支払いを行う支払会社が金融機関口座を有し、支払会社からの支払いをスタッフが有する金融機関口座へ振り込む金融機関サーバと、を備える支払管理システムであって、支払管理サーバは、スタッフが有する金融機関口座の口座情報を含む属性情報を記憶するスタッフ情報記憶部と、支払会社が有する金融機関口座の口座情報を含む属性情報を記憶する会社情報記憶部と、支払会社におけるスタッフの勤務情報を受け付ける勤務情報受付部と、勤務情報に基づき、スタッフが受け取れる最大金額を算出する最大金額算出部と、最大金額を限度とするスタッフの希望金額を管理会社から支払会社への貸出を行うために支払会社が有する金融機関口座へ入金する貸出情報を生成し、希望金額をスタッフへ資金移動するために支払会社が有する金融機関口座からスタッフが有する金融機関口座へ入金する移動情報を生成する入金情報生成部と、貸出情報及び移動情報を金融機関サーバへ送信する送信部と、貸出の金額に基づき、支払会社への資金請求情報を生成する精算情報生成部と、を備え、金融機関サーバは、貸出情報及び移動情報を受信すると、貸出の金額を支払会社が有する金融機関口座へ入金し、支払会社が有する金融機関口座からスタッフが有する金融機関口座へスタッフの希望金額の振込を行う振込部を備える。

本開示の一態様における支払管理方法は、管理会社に登録されているスタッフへの支払いを管理する支払管理方法であって、勤務情報受付部が行う、スタッフの勤務に対して支払いを行う支払会社におけるスタッフの勤務情報を受け付ける勤務情報受付ステップと、最大金額算出部が行う、勤務情報に基づき、スタッフが受け取れる最大金額を算出する最大金額算出ステップと、入金情報生成部が行う、最大金額を限度とするスタッフの希望金額を管理会社から支払会社への貸出を行うために支払会社が有するアカウントへ入金する貸出情報を生成し、希望金額をスタッフへ資金移動するために支払会社が有するアカウントからスタッフが有するアカウントへ入金する移動情報を生成する入金情報生成ステップと、精算情報生成部が行う、貸出の金額に基づき、支払会社への資金請求情報を生成する精算情報生成ステップと、を備える。

また、本開示の一態様における支払管理プログラムは、管理会社に登録されているスタッフへの支払いを管理する支払管理プログラムであって、スタッフの勤務に対して支払いを行う支払会社におけるスタッフの勤務情報を受け付ける勤務情報受付ステップと、勤務情報に基づき、スタッフが受け取れる最大金額を算出する最大金額算出ステップと、最大金額を限度とするスタッフの希望金額を管理会社から支払会社への貸出を行うために支払会社が有するアカウントへ入金する貸出情報を生成し、希望金額をスタッフへ資金移動するために支払会社が有するアカウントからスタッフが有するアカウントへ入金する移動情報を生成する入金情報生成ステップと、貸出の金額に基づき、支払会社への資金請求情報を生成する精算情報生成ステップと、を電子計算機に実行させる。

本開示によれば、スタッフが登録されている管理会社から、スタッフの勤務に対して支払いを行う支払会社への貸出を行うため、支払会社が有するアカウントへ入金する貸出情報を生成する。これにより、例えばフランチャイズチェーンのオーナーである支払会社は管理会社からの貸出を受けられるため、入金の手間なく給与の即時支払いが可能になる。また、スタッフの意思表示に基づき、支払い可能な最大金額を限度とするスタッフの希望金額をスタッフへ資金移動するため、スタッフの意思表示に基づいて一定の支払いを受けることが可能になる。

本開示の一実施形態に係る支払管理システムを使用する目的を説明するためのブロック構成図である。 本開示の一実施形態に係る支払管理システムを示すブロック構成図である。 図１の支払管理サーバ１００を示す機能ブロック構成図である。 図１の金融機関サーバ２００を示す機能ブロック構成図である。 図３のスタッフ情報ＤＢ１２１に格納されるスタッフの属性情報の例を示す模式図である。 図３の店舗情報ＤＢ１２２に格納される会社の属性情報の例を示す模式図である。 図２の支払管理サーバ１００と、店舗端末３００と、スタッフ端末４００とによるマッチング処理の各動作の関連状態の例を示すフローチャートである。 図２のスタッフ端末４００に表示されるマッチング結果表示の例を示す模式図である。 図２の店舗端末３００に表示される勤務可能応答画面の例を示す模式図である。 図２の支払管理サーバ１００と、店舗端末３００と、スタッフ端末４００とによる入金情報生成処理の各動作の関連状態の例を示すフローチャートである。 図２のスタッフ端末４００に表示される勤務情報入力画面の例を示す模式図である。 図２のスタッフ端末４００に表示される支払情報入力画面の例を示す模式図である。 図２の店舗端末３００に表示される勤務承認入力画面の例を示す模式図である。 図２の支払管理サーバ１００と、金融機関サーバ２００とによる振込処理の各動作の関連状態の例を示すフローチャートである。 図２の支払管理サーバ１００と、店舗端末３００とによる精算処理の各動作の関連状態の例を示すフローチャートである。 本開示の一実施形態に係る支払管理システムのスタッフ情報ＤＢ１２１に格納されるスタッフの属性情報の例を示す模式図である。 本開示の一実施形態に係る支払管理システムを示すブロック構成図である。 図１７の支払管理サーバ１００Ａを示す機能ブロック構成図である。 図１８のアカウント情報ＤＢ１２５に格納されるアカウント情報の例を示す模式図である。 図１７の支払管理サーバ１００Ａによる支払処理の動作の例を示すフローチャートである。

以下、本開示の実施形態について図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また、実施形態に示される構成要素のすべてが、本開示の必須の構成要素であるとは限らない。

まず、本開示の実施形態に係る支払管理システムを使用する目的について説明する。図１は、本開示の実施形態に係る支払管理システムを使用する目的を説明するためのブロック構成図である。

本実施形態に係る支払管理システムは、図１に示す管理会社１０が支払会社２０とスタッフ３０との間で雇用のマッチングを行い、スタッフ３０に対して迅速に（例えば、即日）給与を支払うための支払管理システムである。管理会社１０は、例えばコンビニエンスストアのようなフランチャイズチェーンの店舗に対して人材を紹介する会社であり、スタッフ３０のような労働者が登録されている。支払会社２０は、例えばコンビニエンスストアの店舗である。このようなコンビニエンスストアの店舗自身でもスタッフの採用は行っているが、例えばシフトの都合がつかない場合に、管理会社１０に依頼してスタッフ３０のような労働者を紹介してもらう場合があり、そのような場合にこの支払管理システムは使用される。スタッフ３０は、管理会社１０に登録されている労働者である。管理会社１０とスタッフ３０との関係は、雇用契約がある場合とない場合とがあり、後者の場合、支払会社２０がマッチングされ、お互いの合意によりスタッフ３０は支払会社２０に雇用される関係になる。この場合、スタッフ３０の給与は支払会社２０が支払う必要があり、本実施形態ではこの場合について説明する。なお、スタッフ３０は、特定の支払会社２０に雇用されており、他の支払会社２０に紹介される場合にこの支払管理システムが用いられても良い。

この支払管理システムにおける支払会社２０とスタッフ３０とのマッチング及び給与支払いは、図１に示すステップＳ１〜ステップＳ８のような流れになる。ステップＳ１では、スタッフ３０の個人情報及び金融機関口座の情報が管理会社１０に登録される。ステップＳ２では、管理会社１０において支払会社２０とスタッフ３０とがマッチングされ、その旨が支払会社２０及びスタッフ３０に通知される。支払会社２０及びスタッフ３０がマッチングの結果に合意すると、ステップＳ３では、スタッフ３０は支払会社２０で勤務を行う。勤務終了後、ステップＳ４では、スタッフ３０は支払会社２０での勤怠報告を行い、ステップＳ５では、支払会社２０はスタッフ３０の勤怠報告を承認する。

このとき、ステップＳ４では、スタッフ３０が当該勤務に対する給与を即日受け取りたい場合、管理会社１０にその旨の意思表示を行うことが出来る。また、給与の全額ではなく、一部（一時金）のみ受け取りたい場合もあるので、希望金額を指定して受取を希望する旨意思表示を行うことが出来る。この場合、支払会社２０がスタッフ３０の勤務に対する給与、またはスタッフ３０が希望する金額を支払えば終了となるが、一般にコンビニエンスストアの店舗オーナーはあまり現金を保有していないことが多く、スタッフ３０への給与支払いを即時行うことは困難な場合が多い。そのため、ステップＳ６では、管理会社１０は支払会社２０に対して、スタッフ３０の支払相当額の貸出を行う。そして、ステップＳ７では、支払会社２０では貸出金からスタッフ３０に対して支払いを行う。その後、ステップＳ８では、管理会社１０は支払会社２０に対して、貸金請求を行う。このような流れにより、支払会社２０からスタッフ３０に対する給与または一時金を支払うことが可能になる。

（実施形態１）
＜構成＞
図２は、本開示の実施形態１に係る支払管理システム１を示すブロック構成図である。この支払管理システム１は、前述のように図１に示す支払会社２０とスタッフ３０との間で雇用のマッチングを行い、スタッフ３０に対して給与を金融機関口座への振込で支払うシステムである。

支払管理システム１は、支払管理サーバ１００と、金融機関サーバ２００と、店舗端末３００と、スタッフ端末４００と、ネットワークＮＷとを有している。支払管理サーバ１００と、金融機関サーバ２００と、店舗端末３００と、スタッフ端末４００とは、ネットワークＮＷを介して接続される。ネットワークＮＷは、インターネット、イントラネット、無線ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等により構成される。

支払管理サーバ１００は、支払会社２０からスタッフ３０への給与または一時金の支払い（資金移動）を管理する装置である。金融機関サーバ２００は、支払会社２０の金融機関口座を有し、支払会社２０からスタッフ３０への支払いを行う装置である。支払管理サーバ１００及び金融機関サーバ２００は、各種Ｗｅｂサービスを提供するサーバ装置により構成されている。店舗端末３００は、支払会社２０が有する端末装置であり、支払会社２０における就業可能時間を登録し、スタッフ３０の勤務情報を承認するために使用される。スタッフ端末４００は、スタッフ３０が有する端末装置であり、スタッフ３０の勤務可能時間を登録し、スタッフ３０の勤務情報を支払管理サーバ１００へ送信するために使用される。店舗端末３００及びスタッフ端末４００は、例えば、パーソナルコンピュータや携帯端末装置、タブレット端末等により構成される。

図３は、図１の支払管理サーバ１００を示す機能ブロック構成図である。支払管理サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを備える。

通信部１１０は、金融機関サーバ２００、店舗端末３００、及びスタッフ端末４００と通信を行うための通信インターフェースであり、例えばＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）等の通信規約により通信が行われる。

記憶部１２０は、各種制御処理や制御部１３０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等から構成される。また、記憶部１２０は、スタッフ３０の住所や金融機関口座（アカウント）を含む属性情報が格納されているスタッフ情報ＤＢ（スタッフ情報記憶部）１２１と、支払会社２０の住所や金融機関口座（アカウント）を含む属性情報が格納されている店舗情報ＤＢ（会社情報記憶部）１２２と、スタッフ３０が支払会社２０で勤務予定及び勤務した勤務情報が格納されている勤務情報ＤＢ１２３と、スタッフ３０に支払われる予定の給与及び支払われた給与の情報が格納されている支払情報ＤＢ１２４とを記憶する。さらに、記憶部１２０は、金融機関サーバ２００、店舗端末３００、及びスタッフ端末４００と通信を行ったデータを一時的に記憶する。

図５は、図３のスタッフ情報ＤＢ１２１に格納されるスタッフの属性情報の例を示す模式図である。スタッフ情報ＤＢ１２１には、図３に示すスタッフ情報ＤＢ１２１の列名に対応して、スタッフＩＤ、氏名、住所、金融機関情報、勤務可能時間として年月日、開始時刻、終了時刻の属性情報が含まれる。なお、これ以外に、例えばスタッフ３０が雇用されている支払会社２０の店舗名や、この支払管理システム１にログインするためのログインＩＤ及びパスワード等を格納することも可能であるが、図示を省略する。

スタッフＩＤは、スタッフ３０を一意に特定するための識別情報であり、図５に示す例では、「001」、「002」が格納されている。氏名は、スタッフ３０の氏名である。住所は、スタッフ３０の住所である。金融機関情報は、スタッフ３０が保有している金融機関口座の金融機関名、支店名、科目及び口座番号の情報であり、スタッフ３０が支払会社２０で勤務したときの給与が振り込まれる口座情報である。勤務可能時間は、そのスタッフが支払会社２０で勤務可能な日時であり、図５に示す例では、年月日に「20180601」、「20180603」等が格納され、開始時刻に「09:00:00」等が格納され、終了時刻に「18:00:00」等が格納されている。

スタッフ情報ＤＢ１２１に格納される勤務可能時間は、各スタッフが自己の予定に合わせて空いている時間帯を登録可能であり、後述するマッチングを経て勤務することが確定した場合、勤務情報ＤＢ１２３に登録され、スタッフ情報ＤＢ１２１の勤務可能時間は削除されるようになっている。

図６は、図３の店舗情報ＤＢ１２２に格納される会社の属性情報の例を示す模式図である。店舗情報ＤＢ１２２には、図６に示す店舗情報ＤＢ１２２の列名に対応して、店舗ＩＤ、店舗名、住所、金融機関情報、就業可能時間として年月日、開始時刻、終了時刻の属性情報が含まれる。なお、これ以外に、例えば同時間に就業可能な人数、支払会社２０のオーナーの個人情報や、この支払管理システム１にログインするためのログインＩＤ及びパスワード等を格納することも可能であるが、図示を省略する。

店舗ＩＤは、支払会社２０を一意に特定するための識別情報であり、図６に示す例では、「101」、「102」が格納されている。店舗名は、支払会社２０の名称である。住所は、支払会社２０の住所である。金融機関情報は、支払会社２０が保有している金融機関口座の科目及び口座番号の情報であり、スタッフ３０が支払会社２０で勤務したときの給与がこの口座から支払われる。就業可能時間は、その支払会社でスタッフ３０が勤務可能な日時であり、図６に示す例では、年月日に「20180601」、「20180604」等が格納され、開始時刻に「09:00:00」、「12:00:00」等が格納され、終了時刻に「14:00:00」、「17:00:00」等が格納されている。

店舗情報ＤＢ１２２に格納される就業可能時間は、支払会社２０に雇用されている従業員のシフト状況に合わせて就業人数が不足している時間帯を登録可能であり、後述するマッチングを経て勤務することが確定した場合、勤務情報ＤＢ１２３に登録され、人数が充足すると店舗情報ＤＢ１２２の就業可能時間は削除されるようになっている。

なお、本実施形態では、管理会社１０及び支払会社２０はこの金融機関に金融機関口座を保有しており、スタッフ３０はこの金融機関に金融機関口座を保有していない場合について説明している。この理由は、管理会社１０がコンビニエンスストアのような店舗に対して人材を紹介する会社であり、支払会社２０がコンビニエンスストアの店舗であるため、金融機関サーバ２００に係る特定の金融機関に金融機関口座を保有していることが多いが、スタッフ３０はその金融機関に金融機関口座を保有しているとは限らないためである。そのため、スタッフ情報ＤＢ１２１の金融機関情報には金融機関名、支店名、科目及び口座番号の情報が格納されており、店舗情報ＤＢ１２２の金融機関情報には科目及び口座番号の情報のみが格納されている。

勤務情報ＤＢ１２３には、スタッフ情報ＤＢ１２１と同様のスタッフＩＤや、スタッフ３０が勤務予定及び勤務した店舗名、勤務情報、支払会社２０からの承認情報等が格納され、支払情報ＤＢ１２４には、スタッフ情報ＤＢ１２１と同様のスタッフＩＤ及び金融機関情報、店舗情報ＤＢ１２２と同様のスタッフＩＤ及び金融機関情報や、後述するスタッフ３０の意思表示により支払われる予定の給与及び支払われた給与の金額等が格納されているが、図示を省略する。

なお、本実施形態では、スタッフ情報ＤＢ１２１及び店舗情報ＤＢ１２２をスタッフＩＤ及び店舗ＩＤをキーとするテーブルのように説明したが、スタッフ情報ＤＢ１２１及び店舗情報ＤＢ１２２はキー情報に従属して各種情報が格納されるＲＤＢ（Relational DataBase）に限られず、例えば各項目を独立した物理ファイルに格納しても良く、データ構造をオブジェクトとして格納しても良い。このことは、勤務情報ＤＢ１２３及び支払情報ＤＢ１２４についても同様である。

制御部１３０は、記憶部１２０に記憶されているプログラムを実行することにより、支払管理サーバ１００の全体の動作を制御するものであり、ＣＰＵ（Central Processing Unit）等から構成される。制御部１３０の機能として、マッチング部１３１と、勤務情報受付部１３２と、承認受付部１３３と、最大金額算出部１３４と、入金情報生成部１３５と、入金情報送信部１３６と、精算情報生成部１３７と、精算情報送信部１３８とを備えている。このマッチング部１３１、勤務情報受付部１３２、承認受付部１３３、最大金額算出部１３４、入金情報生成部１３５、入金情報送信部１３６、精算情報生成部１３７、及び精算情報送信部１３８は、記憶部１２０に記憶されているプログラムにより起動されて電子計算機により実行される。

マッチング部１３１は、スタッフ情報ＤＢ１２１に格納されているスタッフ３０の住所及び勤務可能時間と、店舗情報ＤＢ１２２に格納されている支払会社２０の住所及び就業可能時間とをマッチングし、支払会社２０で勤務可能なスタッフ３０を抽出する。このマッチングは、例えば、店舗情報ＤＢ１２２の住所の近傍（例えば、移動時間が３０分以内）にスタッフ情報ＤＢ１２１の住所が登録されているスタッフ３０を抽出し、店舗情報ＤＢ１２２の就業可能時間に重複するスタッフ情報ＤＢ１２１の勤務可能時間が登録されているスタッフ３０を抽出することにより行う。このとき、同日に他の支払会社２０での勤務が既に登録されている場合、支払会社２０間の移動時間も考慮される。具体的には、各店舗間の標準移動時間が予め算出され、同日の支払会社２０での勤務がある場合、ある支払会社２０での勤務終了時刻と他の支払会社２０での勤務開始時刻との間が標準移動時間以上空いていない場合、抽出しないようにする。マッチング結果は支払会社２０及びスタッフ３０に送信され、双方の勤務可能の応答及び就業可能の応答が受信されると、支払会社２０におけるスタッフ３０の勤務が決定される。また、支払会社２０またはスタッフ３０のいずれかから勤務不可能の応答または就業不可能の応答が受信されると、再度スタッフ３０の抽出を行う。

なお、本実施形態では、スタッフ３０の住所及び勤務可能時間と、支払会社２０の住所及び就業可能時間とをマッチングする構成として説明しているが、例えば、既に支払会社２０での勤務したスタッフ３０に対して、後述するように、スタッフ３０が給与の全額または指定した金額（一時金）の支払を希望する場合に即時振込を行う構成としても良い。この場合、マッチング部１３１は必須の構成ではなく、備えていなくても良い。

スタッフ３０を抽出する際の条件は、店舗情報ＤＢ１２２の就業可能時間をスタッフ情報ＤＢ１２１の勤務可能時間が完全にカバーすれば良い。例えば、図５に示すスタッフＩＤ「001」の年月日「20180601」における勤務可能時間は「09:00:00」から「18:00:00」であるが、図６に示す店舗ＩＤ「101」の年月日「20180601」における就業可能時間は「09:00:00」から「14:00:00」であり、完全にカバーするため、スタッフＩＤ「001」は抽出される。しかし、図５に示すスタッフＩＤ「002」の年月日「20180601」における勤務可能時間は「12:00:00」から「21:00:00」であるが、図６に示す店舗ＩＤ「102」の年月日「20180601」における就業可能時間は「18:00:00」から「22:00:00」であり、完全にはカバーしないため、スタッフＩＤ「002」は抽出されない。

勤務情報受付部１３２は、スタッフ３０が支払会社２０で勤務した後、スタッフ３０がスタッフ端末４００で勤務情報（勤務店舗、勤務日、勤務開始時刻、勤務終了時刻）を入力するので、その勤務情報を受け付け、勤務情報ＤＢ１２３に勤務した時間として登録される。なお、本実施形態ではスタッフ端末４００で勤務情報を登録する例として説明するが、支払会社２０の店舗端末３００から入力しても良い。

承認受付部１３３は、スタッフ３０が支払会社２０で勤務した後、スタッフ３０が入力した勤務情報に対して、支払会社２０がその勤務情報を承認する旨を入力するので、その承認情報を受け付け、勤務情報ＤＢ１２３に承認済み勤務情報として登録される。勤務情報ＤＢ１２３には、例えば勤務情報が未承認であるか承認済であるか給与計算済であるかを把握することが可能なステータス情報が格納されているので、そのステータス情報を更新することにより行われる。なお、支払会社２０が承認しない場合とは、スタッフ３０が入力した勤務情報に誤りがあった場合等であり、この場合、再度スタッフ３０は勤務情報を入力する。また、スタッフ３０が送信する勤務情報は、支払会社２０が承認した状態（例えば、支払会社２０のログインＩＤでログインされた状態で勤務情報を送信する場合。）で送信しても良く、この場合、承認受付部１３３を備えていなくても良い。

最大金額算出部１３４は、スタッフ３０が勤務終了後に給与の全額または指定した金額（一時金）の即時振込を希望する場合における、支払可能な金額の最大金額を算出する。日雇いのような労働者の場合、迅速に給与の支払を受けたいという希望が多く、また、給与の全額ではなく一部のみ受け取りたいという希望が多いため、スタッフ３０の意思表示に基づき、給与の全額または、最大金額を限度とするスタッフ３０が指定した金額の即日振込を行う。この最大金額は、通常はスタッフ３０の勤務に対する給与金額に基づいて算出されるが、給与金額の全額を支払可能としても良く、例えば給与金額に対する一定割合（例えば、９０％）で算出しても良い。そのため、まずスタッフ３０の勤務に対する給与金額を算出し、給与金額に基づいて最大金額を算出する。なお、例えば、過去の勤務に対する未払い分の給与金額が積み立てられて加算されるようにしても良い。

入金情報生成部１３５は、スタッフ３０が勤務終了後に即時振込を希望する場合、支払会社２０の金融機関口座からスタッフ３０の金融機関口座へ入金するための振込情報（移動情報）を生成する。このとき、前述のように支払会社２０のオーナーであるコンビニエンスストアのオーナーは、一般にあまり現金を保有していないことが多いが、給与は雇用者（支払会社２０）が労働者（スタッフ３０）へ直接支払うのが原則であるため、スタッフ３０への支払相当額を管理会社１０から支払会社２０へ貸出を行うための振込情報（貸出情報）を生成する。管理会社１０から支払会社２０への振込情報は、金融機関サーバ２００に係る特定の金融機関内の振込情報であり、支払会社２０からスタッフ３０への振込情報は、金融機関サーバ２００に係る特定の金融機関から他の金融機関の金融機関口座への振込情報になる。生成された振込情報は、支払情報ＤＢ１２４に格納される。

入金情報送信部１３６は、入金情報生成部１３５が生成した振込情報（貸出情報、移動情報）を、通信部１１０を経由して金融機関サーバ２００へ送信する。

精算情報生成部１３７は、管理会社１０から支払会社２０へ貸出された貸出金に対して、回収するための資金請求情報を生成する。この資金請求情報は、貸出金に所定の手数料か加算された金額についての、支払会社２０への請求データである。

精算情報送信部１３８は、精算情報生成部１３７が生成した資金請求情報を、通信部１１０を経由して店舗端末３００へ送信する。なお、本実施形態では、前述の貸金請求が支払管理サーバ１００から店舗端末３００へのデータ送信により行われる例について説明するが、請求書の発行及び郵送等により行われる場合、この精算情報送信部１３８を備えていなくても良い。

図４は、図１の金融機関サーバ２００を示す機能ブロック構成図である。金融機関サーバ２００は、通信部２１０と、記憶部２２０と、制御部２３０とを備える。

通信部２１０は、支払管理サーバ１００、店舗端末３００、及びスタッフ端末４００と通信を行うための通信インターフェースであり、例えばＴＣＰ／ＩＰ等の通信規約により通信が行われる。

記憶部２２０は、各種制御処理や制御部２３０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、支払会社２０の金融機関口座情報が格納されている口座情報ＤＢ２２１を記憶する。さらに、記憶部２２０は、支払管理サーバ１００、店舗端末３００、及びスタッフ端末４００と通信を行ったデータを一時的に記憶し、この金融機関における取引（出入金や振込等）ログを、通常は決算時まで記憶する。

口座情報ＤＢ２２１には、管理会社１０及び支払会社２０の法人の名称またはオーナーの氏名、金融機関口座の科目、口座番号及び残高等が格納されている。なお、本実施形態では、前述のように管理会社１０及び支払会社２０はこの金融機関に金融機関口座を保有しており、スタッフ３０はこの金融機関に金融機関口座を保有していない場合について説明するが、スタッフ３０がこの金融機関に金融機関口座を保有していても良い。

制御部２３０は、記憶部２２０に記憶されているプログラムを実行することにより、金融機関サーバ２００の全体の動作を制御するものであり、ＣＰＵ等から構成される。制御部２３０の機能として、通常の金融機関における勘定系の処理を行うための機能に加えて、振込部２３１を備えている。この振込部２３１は、記憶部２２０に記憶されているプログラムにより起動されて電子計算機により実行される。

振込部２３１は、各種振込処理を行う機能を有している。また、支払管理サーバ１００から送信された振込情報を通信部２１０を経由して受信すると、貸出情報に基づいて管理会社１０の金融機関口座から支払会社２０の金融機関口座へ、指定された金額の振込処理を行う。また、移動情報に基づいて支払会社２０の金融機関口座からスタッフ３０の金融機関口座へ、指定された金額の振込処理を行う。前述のようにスタッフ３０はこの金融機関に金融機関口座を保有していないため、スタッフ３０の金融機関口座への振込処理は、例えば全銀協制定フォーマットに従う振込情報を作成し、外部サーバに送信することにより行われる。

＜処理の流れ＞
まず、図７を参照しながら、支払管理システム１が実行するマッチング処理の流れの一例について説明する。図７は、図２の支払管理サーバ１００と、店舗端末３００と、スタッフ端末４００とによるマッチング処理の各動作の関連状態の例を示すフローチャートである。なお、このマッチング処理は、前述のようにマッチング部１３１を備えない構成の場合は行われない。

ステップＳ１０１の処理として、支払管理サーバ１００のマッチング部１３１では、スタッフ情報ＤＢ１２１に格納されているスタッフ３０の住所及び勤務可能時間と、店舗情報ＤＢ１２２に格納されている支払会社２０の住所及び就業可能時間とのマッチングが行われる。例えば、店舗情報ＤＢ１２２の住所の近傍にスタッフ情報ＤＢ１２１の住所が登録されているスタッフ３０が抽出され、店舗情報ＤＢ１２２の就業可能時間に重複するスタッフ情報ＤＢ１２１の勤務可能時間が登録されているスタッフ３０が抽出される。

ステップＳ１０２の処理として、支払管理サーバ１００のマッチング部１３１では、ステップＳ１０１で行われたマッチング結果を支払会社２０及びスタッフ３０に通知して勤務可否を問い合わせるため、マッチング結果が店舗端末３００及びスタッフ端末４００（前記スタッフの連絡先）へ、通信部１１０を介して送信される。

ステップＳ１０３の処理として、ステップＳ１０２で送信されたマッチング結果がスタッフ端末４００で受け付けられ、スタッフ端末４００のＷｅｂブラウザに表示される。

図８は、図２のスタッフ端末４００に表示されるマッチング結果表示の例を示す模式図である。スタッフ端末４００のＷｅｂブラウザには、例えば、図８に示すように、マッチング結果Ｔ１と、勤務可能ボタンＢ１と、勤務不可ボタンＢ２とが設けられたマッチング結果が表示される。このマッチング結果に対して、スタッフ３０が勤務可能な場合、勤務可能ボタンＢ１が押下され、勤務不可能な場合、勤務不可ボタンＢ２が押下される。

ステップＳ１０４の処理として、ステップＳ１０２で送信されたマッチング結果が店舗端末３００でも受け付けられ、店舗端末３００のＷｅｂブラウザに、図８に示すマッチング結果表示と同様に表示される。

ステップＳ１０５の処理として、ステップＳ１０３でスタッフ端末４００のＷｅｂブラウザに表示されたマッチング結果表示において、勤務可能ボタンＢ１または勤務不可ボタンＢ２が押下され、マッチング結果に対する勤務応答が支払管理サーバ１００へ送信される。ここでは、勤務可能ボタンＢ１が押下される例について説明する。

ステップＳ１０６の処理として、ステップＳ１０５で送信された勤務応答が支払管理サーバ１００の通信部１１０を介して受け付けられ、通信部１１０を介して店舗端末３００へ送信される。

ステップＳ１０７の処理として、ステップＳ１０６で送信された勤務応答が店舗端末３００で受け付けられ、店舗端末３００のＷｅｂブラウザに表示される。

図９は、図２の店舗端末３００に表示される勤務可能応答画面の例を示す模式図である。店舗端末３００のＷｅｂブラウザには、例えば、図９に示すように、勤務応答通知Ｔ２と、就業可能ボタンＢ３と、就業不可ボタンＢ４とが設けられた勤務可能応答画面が表示される。このスタッフ３０の勤務応答に対して、支払会社２０においてこのスタッフ３０が就業可能な場合、就業可能ボタンＢ３が押下され、就業不可能な場合、就業不可ボタンＢ４が押下される。

ステップＳ１０８の処理として、ステップＳ１０７で店舗端末３００のＷｅｂブラウザに表示された勤務可能応答画面において、就業可能ボタンＢ３または就業不可ボタンＢ４が押下され、マッチング結果に対する就業応答が支払管理サーバ１００へ送信される。ここでは、就業可能ボタンＢ３が押下される例について説明する。

ステップＳ１０９の処理として、ステップＳ１０８で送信された就業応答が支払管理サーバ１００の通信部１１０を介して受け付けられる。

ステップＳ１１０の処理として、支払管理サーバ１００のマッチング部１３１では、ステップＳ１０５で送信された勤務応答と、ステップＳ１０９で送信された就業応答とからマッチングが成立したと判断し、スタッフ３０の勤務が決定したことを支払会社２０及びスタッフ３０に通知するため、勤務決定通知が店舗端末３００及びスタッフ端末４００へ、通信部１１０を介して送信される。

ステップＳ１１１の処理として、ステップＳ１１０で送信された勤務決定通知がスタッフ端末４００で受け付けられ、スタッフ端末４００のＷｅｂブラウザに表示される。

ステップＳ１１２の処理として、ステップＳ１１０で送信された勤務決定通知が店舗端末３００で受け付けられ、店舗端末３００のＷｅｂブラウザに表示される。これにより、支払会社２０とスタッフ３０との間のマッチング処理を迅速に行うことが可能になる。

次に、図１０を参照しながら、支払管理システム１が実行する支払管理方法の一部である入金情報生成処理の流れの一例について説明する。図１０は、図２の支払管理サーバ１００と、店舗端末３００と、スタッフ端末４００とによる入金情報生成処理の各動作の関連状態の例を示すフローチャートである。

ステップＳ１２１の処理として、スタッフ端末４００では、スタッフ３０が支払会社２０で勤務した後、スタッフ３０により勤務情報（勤務店舗、勤務日、勤務開始時刻、勤務終了時刻）が入力され、支払管理サーバ１００へ送信される。

図１１は、図２のスタッフ端末４００に表示される勤務情報入力画面の例を示す模式図である。スタッフ端末４００の操作により支払管理システム１にログインし、勤務情報入力を選択すると、スタッフ端末４００のＷｅｂブラウザには、例えば、図１１に示すように、勤務店舗入力欄Ａ１と、勤務日入力欄Ａ２と、勤務時間入力欄Ａ３と、送信ボタンＢ５と、戻るボタンＢ６とが設けられた勤務情報入力画面が表示される。この勤務情報入力画面に勤務店舗、勤務日、及び勤務時間が入力され、送信ボタンＢ５が押下されると、入力された勤務情報が支払管理サーバ１００へ送信される。また、戻るボタンＢ６が押下されると画面遷移前の状態に戻る。

また、ステップＳ１２１の処理として、スタッフ端末４００では、スタッフ３０が即時振込を希望するか、希望する場合に給与全額の支払いを受け取るか、または指定金額の支払いを受け取るかのいずれかを選択する支払情報の意思表示が行われる。スタッフ端末４００の操作により支払情報が入力され、支払管理サーバ１００へ送信される。

図１２は、図２のスタッフ端末４００に表示される支払情報入力画面の例を示す模式図である。図１１に示す勤務情報入力画面の入力後、画面遷移により、スタッフ端末４００のＷｅｂブラウザには、例えば、図１２に示すように、支払希望入力欄Ｃ１と、金額入力欄Ａ４と、送信ボタンＢ７と、戻るボタンＢ８とが設けられた支払情報入力画面が表示される。この支払情報入力画面で支払希望入力欄Ｃ１のいずれかが選択され、指定金額の受け取りを希望する場合には指定金額が金額入力欄Ａ４に入力され、送信ボタンＢ７が押下されると、入力された支払情報が支払管理サーバ１００へ送信される。また、戻るボタンＢ８が押下されると画面遷移前の状態に戻る。

ステップＳ１２２の処理として、ステップＳ１２１で送信された勤務情報が支払管理サーバ１００の通信部１１０を介して受け付けられると、支払管理サーバ１００の勤務情報受付部１３２では、勤務情報が受け付けられ、勤務情報ＤＢ１２３に勤務した時間として登録される。

ステップＳ１２３の処理として、店舗端末３００では、スタッフ３０が入力した勤務情報に対して、支払会社２０によりその勤務情報を承認する旨が入力され、承認情報が支払管理サーバ１００へ送信される。

図１３は、図２の店舗端末３００に表示される勤務承認入力画面の例を示す模式図である。店舗端末３００の操作により支払管理システム１にログインし、勤務承認入力を選択すると、店舗端末３００のＷｅｂブラウザには、例えば、図１３に示すように、承認要求通知Ｔ３と、承認ボタンＢ７と、不承認ボタンＢ８とが設けられた勤務承認入力画面が表示される。この勤務承認入力画面で承認ボタンＢ７が押下されると、入力された承認情報が支払管理サーバ１００へ送信される。また、戻るボタンＢ８が押下されると画面遷移前の状態に戻る。

ステップＳ１２４の処理として、ステップＳ１２３で送信された承認情報が支払管理サーバ１００の通信部１１０を介して受け付けられると、支払管理サーバ１００の承認受付部１３３では、承認情報が受け付けられ、勤務情報ＤＢ１２３に承認済み勤務情報として登録される。なお、前述のように支払会社２０が承認した状態で勤務情報が送信される場合は、ステップＳ１２３〜ステップＳ１２４の処理は行われない。

ステップＳ１２５の処理として、支払管理サーバ１００の最大金額算出部１３４では、支払可能な金額の最大金額、例えばスタッフ３０の勤務に対する給与金額が算出される。また、過去の勤務に対する未払い分の給与金額の残額がある場合は加算される。

ステップＳ１２６の処理として、支払管理サーバ１００の入金情報生成部１３５では、ステップＳ１２１においてスタッフ３０が給与全額または指定金額の即時振込を希望する意思表示が入力された場合、管理会社１０の金融機関口座からスタッフ３０への支払相当額の貸出を、支払会社２０の金融機関口座へ振込を行うための振込情報が生成される。

ステップＳ１２７の処理として、支払管理サーバ１００の入金情報生成部１３５では、前述同様にステップＳ１２１において即時振込の意思表示が入力された場合、支払会社２０の金融機関口座からスタッフ３０の金融機関口座へ資金移動を行うための振込情報が生成される。

次に、図１４を参照しながら、支払管理システム１が実行する支払管理方法の一部である振込処理の流れの一例について説明する。図１４は、図２の支払管理サーバ１００と、金融機関サーバ２００とによる振込処理の各動作の関連状態の例を示すフローチャートである。

ステップＳ１３１の処理として、ステップＳ１２６及びステップＳ１２６にて、貸出及び資金移動を行うための振込情報がそれぞれ生成されると、支払管理サーバ１００の入金情報送信部１３６では、通信部１１０を介して金融機関サーバ２００へ送信される。

ステップＳ１３２の処理として、金融機関サーバ２００では、ステップＳ１３１で送信された振込情報が通信部２１０を介して受け付けられる。

ステップＳ１３３の処理として、金融機関サーバ２００の振込部２３１では、管理会社１０の金融機関口座から支払会社２０の金融機関口座への、スタッフ３０による給与金額または指定金額の振込処理が行われる。この振込処理は、金融機関サーバ２００の金融機関口座間の振込処理である。

ステップＳ１３４の処理として、金融機関サーバ２００の振込部２３１では、支払会社２０の金融機関口座からスタッフ３０の金融機関口座への、スタッフ３０による給与金額または指定金額の振込処理が行われる。この振込処理は、金融機関サーバ２００の金融機関口座から他の金融機関の金融機関口座への振込処理であるため、例えば全銀協制定フォーマットに従う振込情報を作成し、外部サーバに送信される。これにより、スタッフ３０への給与または希望金額の振込による支払いを迅速に行うことが出来る。

ステップＳ１３５の処理として、金融機関サーバ２００の振込部２３１では、振込処理が完了した旨の通知が通信部２１０を介して支払管理サーバ１００へ送信される。

ステップＳ１３６の処理として、支払管理サーバ１００では、ステップＳ１３５で金融機関サーバ２００によって送信された振込完了通知が通信部１１０を介して受信される。

次に、図１５を参照しながら、支払管理システム１が実行する支払管理方法の一部である精算処理の流れの一例について説明する。図１５は、図２の支払管理サーバ１００と、店舗端末３００とによる精算処理の各動作の関連状態の例を示すフローチャートである。

ステップＳ１４１の処理として、支払管理サーバ１００の精算情報生成部１３７では、管理会社１０から支払会社２０へ貸出された貸出金に対して、回収するための資金請求情報が生成される。この処理は、管理会社１０から支払会社２０への貸出の一定期間経過後（例えば、当月の締日経過後）に行われる。

ステップＳ１４２の処理として、支払管理サーバ１００の精算情報送信部１３８では、ステップＳ１４１で生成された資金請求情報が店舗端末３００へ送信される。前述のように、貸金請求が請求書の発行及び郵送等により行われる場合、この処理は行われない。

ステップＳ１４３の処理として、ステップＳ１４２で送信された資金請求情報が店舗端末３００で受け付けられる。この後、金融機関サーバ２００の振込処理等により清算が行われる。

以上のように、本実施形態に係る支払管理システムは、スタッフの住所及び勤務可能時間と、支払会社の住所及び就業可能時間とがマッチングされ、支払会社で勤務可能なスタッフが抽出される。双方にマッチングされた旨が通知され、双方の勤務可能応答及び就業可能応答を受けて支払会社におけるスタッフの勤務が決定される。これにより、支払会社とスタッフとの間のマッチング処理を迅速に行うことが可能になり、支払会社におけるスタッフの勤務を迅速に決定することが可能になる。

また、スタッフが勤務終了後に給与の全額または指定した金額の即時振込を希望する意思表示をした場合、スタッフへの支払相当額を管理会社から支払会社へ貸出を行うための振込情報が生成され、支払会社からスタッフへの資金移動を行うための振込情報が生成され、金融機関サーバにて振込処理が行われる。これにより、あまり現金を保有していない支払会社であってもスタッフへ直接給与を迅速に支払うことが可能になる。また、給与の全額は必要ないが一部金額のみ必要な場合であっても、スタッフの意思表示に基づいて支払を柔軟かつ迅速に行うことが可能になる。

（実施形態２）
図１６は、本開示の実施形態２に係る支払管理システム１における、支払管理サーバ１００のスタッフ情報ＤＢ１２１に格納されるスタッフの属性情報の例を示す模式図である。この支払管理システム１は、支払会社２０とスタッフ３０との間で雇用のマッチングを行い、スタッフ３０に対して給与を金融機関への振込で支払うシステムである点において実施形態１と同様であるが、図１６に示すようなスタッフ情報ＤＢ１２１を備えている点において、実施形態１と異なる。

スタッフ情報ＤＢ１２１には、図１６に示すスタッフ情報ＤＢ１２１の列名に対応して、スタッフＩＤ、氏名、住所１、住所２、勤務可能時間として年月日、開始時刻、終了時刻の属性情報が含まれる。スタッフＩＤ、氏名、勤務可能時間については、図５に示すスタッフ情報ＤＢ１２１と同様の情報であり、図５に示す金融機関情報も格納されているが図示を省略する。住所１は、スタッフ３０の住所であり、図５に示す住所と同様の情報である。住所２は、スタッフ３０の移動先の住所であり、例えば、スタッフ３０が学生である場合の通学先の住所や、スタッフ３０が自己の住所地以外で勤務を希望する場合の移動先住所情報である。この住所２は、例えば通学先の学校付近で短時間勤務する場合や、複数個所で勤務を希望する場合に対応するために設けられており、マッチング部１３１は、スタッフ３０の住所１または住所２と、勤務可能時間とに基づいてマッチングを行う。この場合、住所１における勤務可能時間と、住所２における勤務可能時間とを登録することが可能である。なお、本実施形態では住所１及び住所２を設けたが、３つ以上の住所を登録可能にしても良い。その他の構成及び処理の流れについては、実施形態１と同様である。

本実施形態によれば、上記実施形態１の効果に加え、スタッフ情報ＤＢに複数の住所を登録可能に構成したことにより、例えば通学先の学校付近で短時間勤務する場合や、複数個所で勤務を希望する場合等、より柔軟に支払会社とスタッフとのマッチングを行うことが可能になる。

（実施形態３）
図１７は、本開示の実施形態３に係る支払管理システム１Ａを示すブロック構成図である。この支払管理システム１Ａは、支払会社２０とスタッフ３０との間で雇用のマッチングを行い、スタッフ３０に対して給与を支払うシステムである点において実施形態１と同様であるが、実施形態１における支払管理サーバ１００とは異なる支払管理サーバ１００Ａを備え、金融機関サーバ２００を備えていない点において、実施形態１と異なる。

図１８は、図１７の支払管理サーバ１００Ａを示す機能ブロック構成図である。この支払管理サーバ１００Ａは、支払会社２０からスタッフ３０への給与または一時金の支払い（資金移動）を管理する点において実施形態１と同様であるが、記憶部１２０にアカウントＤＢ１２５を備え、制御部１３０に入金情報送信部１３６及び精算情報送信部１３８を備えていない点において、実施形態１と異なる。

本実施形態では、スタッフ３０の給与を金融機関口座への振込で支払う代わりに、支払管理サーバ１００Ａ内で管理されている、ユーザ間でポイントを移動可能なＷｅｂポイントサービスのポイントで支払う場合について説明する。このポイントは、例えば電子マネーや、各種決済に使用可能なＷｅｂポイントサービスのポイントであり、ポイント移動により決済等を行うことで現金の代わりに使用可能なものであり、現金として払出を行うことも可能なものである。アカウントＤＢ１２５には、管理会社１０、支払会社２０、及びスタッフ３０がユーザアカウントとして登録されており、ユーザ間の決済（貸出、資金移動）は支払管理サーバ１００Ａ内で完了するため、金融機関サーバ２００を備える必要はなく、金融機関サーバ２００へ送信するための機能を有する入金情報送信部１３６及び精算情報送信部１３８も備えていない。

図１９は、図１８のアカウント情報ＤＢ１２５に格納されるアカウント情報の例を示す模式図である。アカウント情報ＤＢ１２５には、図１９に示すアカウント情報ＤＢ１２５の列名に対応して、アカウントＩＤ、氏名／店舗名、入出金明細として年月日、摘要、金額、残高の情報が含まれる。なお、これ以外に、例えば対応するスタッフ情報ＤＢ１２１のスタッフＩＤや店舗情報ＤＢ１２２の店舗ＩＤ等を格納することも可能であるが、図示を省略する。

アカウントＩＤは、管理会社１０、支払会社２０、及びスタッフ３０のアカウントを一意に特定するための識別情報であり、図１９に示す例では、「201」、「202」が格納されている。氏名／店舗名は、スタッフ３０の氏名または支払会社２０の名称である。入出金明細は、入出金や貸出、払出を行った日付、金額及び残高を示す情報が格納されている。その他の構成については、実施形態１と同様である。

処理の流れとして、図２０を参照しながら、支払管理システム１Ａが実行する支払処理の流れの一例について、実施形態１と異なる点について説明する。実施形態１におけるステップＳ１０１〜ステップＳ１１２、ステップＳ１２１〜ステップＳ１２７、ステップＳ１４１〜ステップＳ１４３の処理は同様であるため、実施形態１におけるステップＳ１３１〜ステップＳ１３６に代えて行われる処理について説明する。図２０は、図１７の支払管理サーバ１００Ａによる支払処理の動作の例を示すフローチャートである。

ステップＳ１５１の処理として、支払管理サーバ１００Ａの入金情報生成部１３５では、管理会社１０のアカウントから支払会社２０のアカウントへの、スタッフ３０による給与金額または指定金額の貸出処理が行われる。

ステップＳ１５２の処理として、支払管理サーバ１００Ａの入金情報生成部１３５では、支払会社２０のアカウントからスタッフ３０のアカウントへの、スタッフ３０による給与金額または指定金額の資金移動処理が行われる。これにより、スタッフ３０への給与または希望金額の支払いを迅速に行うことが出来る。

本実施形態によれば、上記実施形態１及び２の効果に加え、管理会社、支払会社、及びスタッフのアカウントを管理するアカウントＤＢを備えたことにより、支払管理サーバ１００Ａ内の処理だけでスタッフへの給与または希望金額の支払いを行うことが出来る。これにより、スタッフの意思表示に基づいて支払をより迅速に行うことが可能になる。

以上、開示に係る実施形態について説明したが、これらはその他の様々な形態で実施することが可能であり、種々の省略、置換および変更を行なって実施することが出来る。これらの実施形態および変形例ならびに省略、置換および変更を行なったものは、特許請求の範囲の技術的範囲とその均等の範囲に含まれる。

１，１Ａ 支払管理システム、１０ 管理会社、２０ 支払会社、３０ スタッフ、１００，１００Ａ 支払管理サーバ、１１０ 通信部、１２０ 記憶部、１２１ スタッフ情報ＤＢ、１２２ 店舗情報ＤＢ、１２３ 勤務情報ＤＢ、１２４ 支払情報ＤＢ、１２５ アカウントＤＢ、１３０ 制御部、１３１ マッチング部、１３２ 勤務情報受付部、１３３ 承認受付部、１３４ 最大金額算出部、１３５ 入金情報生成部、１３６ 入金情報送信部、１３７ 精算情報生成部、１３８ 精算情報送信部、２００ 金融機関サーバ、３００ 店舗端末、４００ スタッフ端末、ＮＷ ネットワーク

Claims (13)

1. 管理会社に登録されているスタッフへの支払いを管理する支払管理サーバであって、
   前記スタッフが有するアカウントを含む属性情報を記憶するスタッフ情報記憶部と、
   前記スタッフの勤務に対して支払いを行う支払会社が有するアカウントを含む属性情報を記憶する会社情報記憶部と、
   前記支払会社における前記スタッフの勤務情報を受け付ける勤務情報受付部と、
   前記勤務情報に基づき、前記スタッフが受け取れる最大金額を算出する最大金額算出部と、
   前記最大金額を限度とする前記スタッフの希望金額を前記管理会社から前記支払会社への貸出を行うために前記支払会社が有するアカウントへ入金する貸出情報を生成し、前記希望金額を前記スタッフへ資金移動するために前記支払会社が有するアカウントから前記スタッフが有するアカウントへ入金する移動情報を生成する入金情報生成部と、
   前記貸出の金額に基づき、前記支払会社への資金請求情報を生成する精算情報生成部と、を備える支払管理サーバ。
2. 前記スタッフが有するアカウントは、前記スタッフが有する金融機関口座であり、
   前記支払会社が有するアカウントは、前記支払会社が有する金融機関口座であり、
   前記入金情報生成部は、前記貸出を前記支払会社が有する金融機関口座へ入金する貸出情報を生成し、前記希望金額を前記支払会社が有する金融機関口座から前記スタッフが有する金融機関口座へ入金する移動情報を生成する、請求項１に記載の支払管理サーバ。
3. 前記スタッフが有するアカウントは、ユーザ間でポイントを移動可能なＷｅｂポイントサービスにおける前記スタッフのユーザアカウントであり、
   前記支払会社が有するアカウントは、前記Ｗｅｂポイントサービスにおける前記支払会社のユーザアカウントであり、
   前記入金情報生成部は、前記貸出を行うために前記支払会社が有するユーザアカウントへポイント移動する貸出情報を生成し、前記希望金額を前記支払会社が有するユーザアカウントから前記スタッフが有するユーザアカウントへポイント移動する移動情報を生成する、請求項１に記載の支払管理サーバ。
4. 前記最大金額算出部は、前記スタッフの勤務に対する給与金額を前記最大金額とする、請求項１から請求項３のいずれか１項に記載の支払管理サーバ。
5. 前記勤務情報に対する、前記支払会社または前記スタッフの承認を受け付ける承認受付部を備え、
   前記最大金額算出部は、承認済の前記勤務情報に基づき前記最大金額を算出する、請求項１から請求項４のいずれか１項に記載の支払管理サーバ。
6. 前記資金請求情報を前記支払会社へ送信する精算情報送信部を備える、請求項１から請求項５のいずれか１項に記載の支払管理サーバ。
7. 前記スタッフ情報記憶部は、前記スタッフの住所情報及び勤務可能時間情報を含む属性情報を記憶し、
   前記会社情報記憶部は、前記支払会社の住所情報及び就業可能時間情報を含む属性情報を記憶し、
   前記スタッフの住所情報及び勤務可能時間と、前記支払会社の住所情報及び就業可能時間情報と、に基づき、前記支払会社で勤務可能な前記スタッフを抽出するマッチング部を備える、請求項１から請求項６のいずれか１項に記載の支払管理サーバ。
8. 前記マッチング部は、抽出された前記スタッフの連絡先に対して前記支払会社での勤務可否の問い合わせを送信し、そのスタッフの前記支払会社での勤務を決定する、請求項７に記載の支払管理サーバ。
9. 前記マッチング部は、抽出された前記スタッフの連絡先に対して前記支払会社での勤務可否の問い合わせを送信し、前記スタッフから勤務可能の応答を受信するとそのスタッフの前記支払会社での勤務を決定し、前記スタッフから勤務不可能の応答を受信すると他の前記スタッフを抽出する、請求項７に記載の支払管理サーバ。
10. 前記スタッフ情報記憶部は、前記スタッフの移動先住所情報を含む属性情報を記憶し、
    前記マッチング部は、前記スタッフの移動先住所情報及び勤務可能時間と、前記支払会社の住所情報及び就業可能時間情報と、に基づき、前記支払会社で勤務可能な前記スタッフを抽出する、請求項７から請求項９のいずれか１項に記載の支払管理サーバ。
11. 管理会社に登録されているスタッフへの支払いを管理する支払管理サーバと、前記スタッフの勤務に対して支払いを行う支払会社が金融機関口座を有し、前記支払会社からの支払いを前記スタッフが有する金融機関口座へ振り込む金融機関サーバと、を備える支払管理システムであって、
    前記支払管理サーバは、
    前記スタッフが有する金融機関口座の口座情報を含む属性情報を記憶するスタッフ情報記憶部と、
    前記支払会社が有する金融機関口座の口座情報を含む属性情報を記憶する会社情報記憶部と、
    前記支払会社における前記スタッフの勤務情報を受け付ける勤務情報受付部と、
    前記勤務情報に基づき、前記スタッフが受け取れる最大金額を算出する最大金額算出部と、
    前記最大金額を限度とする前記スタッフの希望金額を前記管理会社から前記支払会社への貸出を行うために前記支払会社が有する金融機関口座へ入金する貸出情報を生成し、前記希望金額を前記スタッフへ資金移動するために前記支払会社が有する金融機関口座から前記スタッフが有する金融機関口座へ入金する移動情報を生成する入金情報生成部と、
    前記貸出情報及び前記移動情報を前記金融機関サーバへ送信する入金情報送信部と、
    前記貸出の金額に基づき、前記支払会社への資金請求情報を生成する精算情報生成部と、を備え、
    前記金融機関サーバは、
    前記貸出情報及び前記移動情報を受信すると、前記貸出の金額を前記支払会社が有する金融機関口座へ入金し、前記支払会社が有する金融機関口座から前記スタッフが有する金融機関口座へ前記希望金額の振込を行う振込部を備える、支払管理システム。
12. 管理会社に登録されているスタッフへの支払いを管理する支払管理方法であって、
    勤務情報受付部が行う、前記スタッフの勤務に対して支払いを行う支払会社における前記スタッフの勤務情報を受け付ける勤務情報受付ステップと、
    最大金額算出部が行う、前記勤務情報に基づき、前記スタッフが受け取れる最大金額を算出する最大金額算出ステップと、
    入金情報生成部が行う、前記最大金額を限度とする前記スタッフの希望金額を前記管理会社から前記支払会社への貸出を行うために前記支払会社が有するアカウントへ入金する貸出情報を生成し、前記希望金額を前記スタッフへ資金移動するために前記支払会社が有するアカウントから前記スタッフが有するアカウントへ入金する移動情報を生成する入金情報生成ステップと、
    精算情報生成部が行う、前記貸出の金額に基づき、前記支払会社への資金請求情報を生成する精算情報生成ステップと、を備える支払管理方法。
13. 管理会社に登録されているスタッフへの支払いを管理する支払管理プログラムであって、
    前記スタッフの勤務に対して支払いを行う支払会社における前記スタッフの勤務情報を受け付ける勤務情報受付ステップと、
    前記勤務情報に基づき、前記スタッフが受け取れる最大金額を算出する最大金額算出ステップと、
    前記最大金額を限度とする前記スタッフの希望金額を前記管理会社から前記支払会社への貸出を行うために前記支払会社が有するアカウントへ入金する貸出情報を生成し、前記希望金額を前記スタッフへ資金移動するために前記支払会社が有するアカウントから前記スタッフが有するアカウントへ入金する移動情報を生成する入金情報生成ステップと、
    前記貸出の金額に基づき、前記支払会社への資金請求情報を生成する精算情報生成ステップと、を電子計算機に実行させる、支払管理プログラム。
    
    

Images