JP2023108064A - 給与プリペイドシステム - Google Patents

Abstract

【課題】 給与所得者のキャッシュレス決済を容易にし、心理的なプレッシャーをなくし、働く場としての企業の価値を高める。【解決手段】 雇用主企業はプリペイド口座６に預託金を入金し、従業員は、提供された給与プリペイドカードＣを店舗で提示する。プリペイドＩＤと使用要請額が店舗端末９から使用承認サーバ２に送信され、使用承認サーバ２はプリペイド金の使用合計額と使用要請額とを加算した額がプリペイド情報ファイル５４内のプリペイド設定額以下である場合に使用承認を店舗端末９に送信し、使用要請額を使用実績情報ファイル５５１に記録する。集計サーバ３は、集計期間のプリペイド金の使用合計額を給与支払日に支払われる給与から差し引くために集計用ファイル３２に記録する。【選択図】 図１

Description

この出願の発明は、給与の前払いを行うためのシステムに関するものである。

近年、ＩＴ技術の進歩により、商品・サービスの売買における決済方法も多様化している。キャッシュレス化の進展もその一つであり、クレジットカードによる決済に加え、スマホによる決済や、交通系やコンビニ系のプリペイドカードによる決済等が普及してきている。
このような決済を行う一般消費者の多くは、給与所得者である。給与所得者の場合、決済の原資は言うまでもなく給与である。給与については、労働者保護の立場から支払い方法が法律的で定められており、このことが、ある意味、決済の融通性の障害になっている。即ち、給与は現金で労働者に直接手渡すことが法律で定められている。銀行振込については、銀行預金口座の預金が現金として会計上扱われることや、労働者が確実に引き出せること等を考慮して例外的に認められている。

特開２０１６－０３３８２９号公報

上記のような状況は、給与所得者にとっては手間がかかっているともいえる。給与所得者は、支払われた給与を銀行口座から引き出し、例えば交通系のプリペイドカードにチャージする。そして、プリペイドカードを使用して残高がなくなったら、また銀行口座から預金を引き出してチャージする。クレジットカードの場合、給与の支払い口座から毎月引き落としが行われるようにすることができるので、このような面倒はないが、カード手数料がかかる。また、引き落としの際に銀行口座の残高が不足していると、引き落としができずに遅延損害金がかかったり、いわゆるブラックリストに載ってしまったりする。したがって、手間がかからない分、費用の負担が発生したり、心理的なプレッシャーがかかったりする問題がある。

本願の発明は、上記の点を考慮して為されたものであり、給与所得者にとってキャッシュレス決済を手間がかからずに容易に行えるようにするとともに、心理的なプレッシャーもかからないようにすることを目的とする。そして、そのための新しいユニークな給与支払いのシステムを企業（雇用主）に提供することで、働く場としての企業価値を高めるのに貢献することを目的とする。

上記課題を解決するため、この出願は、給与プリペイドシステムという発明を開示する。このシステムは、雇用主企業が従業員に対して給与を前払いする際に利用される給与プリペイドシステムであり、プリペイド金の使用を承認する使用承認サーバと、プリペイド金の使用額を集計する集計サーバと、記憶部とを備えている。
記憶部には、従業員の就労状況に応じて設定されたプリペイド設定額を記録したプリペイド設定情報ファイルと、プリペイド金の使用実績を記録した使用実績情報ファイルとが記憶されている。使用実績情報ファイルは、プリペイド金を使用する権利を有する従業員を特定するプリペイドＩＤと、集計期間内でのプリペイド金の使用額とを記録したファイルである。
使用承認サーバは、ネットワークを介して店舗側コンピュータからのアクセスを受け付けるサーバであって、店舗側コンピュータからプリペイドＩＤと使用要請額とがネットワークを介して送信した際、当該プリペイドＩＤについてのそれまでのプリペイド金の使用合計額と送信された使用要請額とを加算した額がプリペイド設定額以下である場合に当該店舗側コンピュータに使用承認情報を送信し、使用要請額を当該プリペイドＩＤについて使用実績情報ファイルに記録するサーバである。
集計サーバは、集計期間内のプリペイド金の使用合計額を使用実績情報ファイルから取得するサーバであって、使用合計額を給与支払日に支払われる給与から差し引くために集計用ファイルに記録するサーバである。
そして、記憶部には、プリペイド金の使用のための資金を預けたプリペイド口座の情報を記録したプリペイド口座情報ファイルが記憶されている。
プリペイド口座情報ファイルには、プリペイド金の使用のために雇用主企業が預けた預託金である企業所有預金の情報と、各プリペイドＩＤについて給与が前払いされることで従業員が個別に所有することになった預金である個別所有預金の情報と、各店舗が所有する預金である店舗所有預金の情報が記録されている。
使用承認サーバで承認されたプリペイド金の使用について当該承認されたプリペイドＩＤに係る個別所有預金から使用要請額を当該店舗に係る店舗所有預金に移す決済サーバが設けられており、決済サーバは、前記使用承認サーバでプリペイド金の使用が承認された際、当該承認されたプリペイドＩＤに係る個別所有預金に対して企業所有預金から個別所有預金に当該使用要請額を移動させ、その後、当該使用要請額を店舗所有預金に移すサーバである。
また、上記課題を解決するため、給与プリペイドシステムは、プリペイド金が通貨建て資産、仮想通貨、暗号資産、ポイントカードにおけるポイント、トークン、又は電子マネーであるという構成を持ち得る。
また、上記課題を解決するため、給与プリペイドシステムは、プリペイドＩＤがＩＤ担持物に担持された状態で店舗に提示される情報であり、ＩＤ担持物は、カード、モバイル端末又は認証可能な生体特徴部分であるという構成を持ち得る。

以下に説明する通り、この出願の発明に係る給与プリペイドシステムによれば、従業員の給与がプリペイド金という形で事前に支払われる。限度額はあるものの、従業員にとってはプリペイドＩＤを提示することで店舗での支払いができるので、極めて利便性が高い。従来であれば、自分で給与を銀行口座から現金を引き出してプリペイドカードにチャージする必要があるが、このシステムではそのような面倒はない。また、クレジットカードではないので、引き落とし日に銀行口座に確実に預金があるようにしなければならないというプレッシャーもない。このため、心理面のユーザビリティも非常に高い。
また、通常、給与の前払いというのは、従業員が会社に申請をして認められるが、このシステムによれば、事前の申請は特に不要である。申請をすると、申請を処理する部署にその事実が知れるから、従業員にとって心理的な負担もある。このシステムによれば、このような心理的な負担もなく、この点でもユーザビリティが非常に高い。
一方、雇用主企業にとっても、給与プリペイドの制度があることで従業員による評価が高まり、従業員を優遇している企業としての印象が高くなる。このため、優秀な人材を多く集めるのに貢献し、結果的に企業業績を高めていくことができる。この際、プリペイドとはいっても、個別に従業員の口座に現金を振り込むようなやり方であると煩雑この上ないが、限度額のあるプリペイド金の使用権限を供与するというだけであるので、極めて簡便である。
また、決済用の口座としてプリペイド口座が用意されており、決済のための資金がいったん当該従業員の保有になった後に店舗の保有に移されるので、前払いであっても法律的には給与が従業員に対して支給され、その後、決済のために使用されたという形がより明確になるという意義が生じる。

第一の実施形態の給与プリペイドシステムの概略図である。 雇用主企業情報ファイルの構造の一例を示した概略図である。 プリペイド口座に入金された資金の所有関係について示した概略図である。 プリペイド口座情報ファイルの各構造の一例を示した概略図である。 カード提供情報ファイルの構造の一例を示した概略図である。 三種類の設定額について示した概略図である。 プリペイド設定情報ファイルの構造の一例を示した概略図である。 使用実績情報ファイルの構造の一例を示した概略図である。 プリペイド発行ページの一例を示した概略図である。 設定額変更ページの一例を示した概略図である。 使用承認プログラムの概略を示したフローチャートである。 決済プログラムの概略を示したフローチャートである。 集計プログラムの概略を示したフローチャートである。 第二の実施形態の給与プリペイドシステムの概略図である。 第二の実施形態における使用実績情報ファイルの構造の一例を示した概略図である。 用途入力ページの一例を示した概略図である。 社用承認ページの一例を示した概略である。 第二の実施形態における集計プログラムの概略を示したフローチャートである。 第三の実施形態の給与プリペイドシステムの主要部を示した概略図である。 第四の実施形態の給与プリペイドシステムの主要部を示した概略図である。

以下、この出願の発明を実施するための形態（実施形態）について説明する。
図１は、第一の実施形態の給与プリペイドシステムの概略図である。図１に示す給与プリペイドシステム（以下、単にシステムということがある。）は、雇用主企業が従業員に対して給与を支払う際に利用されるシステムである。このシステムは、決められた給与支給日よりも前に一部の給与をプリペイド金の形で従業員に前払いするためのシステムとなっている。

この実施形態では、プリペイド金の供与は、給与プリペイドカードＣを各従業員に支給することで行われる。即ち、図１のシステムは、給与の一部が給与プリペイドカードＣの形で与えられること、及び給与支給日のよりも前に支給される即ち前払いがされること、
という二つの特徴点を実現するものとなっている。
尚、実施形態のシステムにおいて重要なのは、プリペイド金が使用される店舗において、プリペイド金を使用する権利を有する者であることを証明し、その者を特定する情報であるプリペイドＩＤが提示されることである。給与プリペイドカードＣは、そのような意味であるプリペイドＩＤを担持した媒体（以下、ＩＤ担持物という。）の一例である。

システムのより具体的な構成について説明すると、実施形態のシステムは、複数のサーバを備えて構成されている。これらサーバには、プリペイド発行サーバ１、使用承認サーバ２、集計サーバ３、決済サーバ、管理サーバ４等が含まれる。各サーバ１～４は、それぞれ単独のサーバコンピュータで実現される場合の他、複数のサーバ機能が一つのサーバコンピュータで実現される場合もある。

また、実施形態のシステムは、記憶部５を備えている。記憶部５は、いずれかのサーバ１～４が備えるハードディスク等のストレージの場合もあるし、専用に設けられたサーバ（ストレージサーバ）が備えるものである場合もある。したがって、各サーバ１～４は、いわゆるクラウドコンピューティングに係るものである場合もあり得る。尚、この実施形態のシステムは、各雇用主企業が各従業員に給与を前払いするという形を取るが、実際の運営は別の事業者（以下、運営事業者）に委ねられる。

プリペイド発行サーバ１は、各従業員に給与プリペイドカードＣを発行するためのサーバであり、厳密にはプリペイドＩＤを発行するためのサーバである。実施形態において、給与プリペイドカードＣは雇用主企業ごとに発行されるから、この場合の各従業員とは、各雇用主企業における各従業員である。
実施形態のシステムにおいて、運営事業者は、複数の雇用主企業に対して給与プリペイドカードＣの発行及び管理に関するサービス（以下、給与プリペイドサービスという。）を提供している。記憶部５には、サービス提供先の雇用主企業の情報を記録した雇用主企業情報ファイル５１が記憶されている。図２は、雇用主企業情報ファイルの構造の一例を示した概略図である。

図２に示すように、雇用主企業情報ファイル５１は、「企業ＩＤ」、「企業名」、「本社住所」、「担当部署」、「担当者名」、「登録従業員数」、「預託金額」、「プリペイド金初期値」等の情報を記録したデータベースファイルである。「担当部署」とは、実施形態にシステムについての雇用主企業内の担当部署であり、通常は総務部とか人事部といった部署になる。「担当者名」とは、実施形態のシステムの雇用主企業内の担当者（以下、企業内担当者という。）の名前である。

実施形態のシステムは、給与プリペイドカードＣの発行に際して、各雇用主企業から預託金を提供してもうらようにしている。預託金は、銀行口座（以下、プリペイド口座という。）６に入金される。プリペイド口座６は、通常、運営事業者が保有する銀行口座である。但し、プリペイド口座６に入れられた資金の所有関係は、雇用主企業、運営事業者、雇用主企業に所属する各従業員との契約により取り決められ、その時々で変動する。

図３は、プリペイド口座６に入金された資金の所有関係について示した概略図である。プリペイド口座６に入金された資金には、基本的には四つの異なる所有者が存在する。一つは、雇用主企業である。プリペイド口座６に入金された資金は、当初は預託金であり、その所有は雇用主企業のままである。もう一つは、当該雇用主企業に所属し且つプリペイド金を使用する権利を有する従業員全員である。労働組合が存在していれば労働組合が所有者となることもある。さらにもう一つは、プリペイドＩＤを有する各従業員個人である。さらにもう一つは、プリペイド金が使用される各店舗である。

実施形態の給与プリペイドシステムにおいて、プリペイド口座６に入れられた資金は、当初は預託金であるが、それは、従業員全員の共有分として所有権が移動する。そしてさらに、個々の決済のために個々の従業員の所有となる。またさらに、決済が行われると、資金は当該店舗の所有となる。

記憶部５には、プリペイド口座６に入金された資金の所有権を管理するためのファイル（以下、プリペイド口座情報ファイル）５２１～５２４が記録されている。所有権の移動は、プリペイド口座情報ファイル５２１～５２４の記録の変更という形で行われる。以下、説明の都合上、プリペイド口座６の資金のうち、雇用主企業が所有する部分６１について「企業アカウント」と呼び、当該雇用主企業の従業員全員の共有部分６２について「共有アカウント」と呼び、各従業員個別所有部分６３について個別アカウントと呼ぶ。また、各店舗の所有部分６４については、店舗アカウントと呼ぶ。

図４は、プリペイド口座情報ファイル５２１～５２４の各構造の一例を示した概略図である。図４に示すように、プリペイド口座情報ファイル５２１～５２４は、各アカウント６１～６４用にそれぞれ作成されている。以下、四種類のプリペイド口座情報ファイル５２１～５２４を、企業アカウント情報ファイル５２１、共有アカウント情報ファイル５２２、個別アカウント情報ファイル５２３、店舗アカウント情報ファイル５２４と呼ぶ。
図４に示すように、企業アカウント情報ファイル５２１は、「企業ＩＤ」、「日時」、「入金額」、「出金額」、「残高」等のフィールドから成るデータベースファイルである。「残高」は、預託金の残高を意味する。

また、共有アカウント情報ファイル５２２も、「企業ＩＤ」、「共有ＩＤ」、「日時」、「入金額」、「出金額」、「残高」等のフィールドから成るデータベースファイルである。「共有ＩＤ」は、共有者全員を特定するＩＤであり、例えば企業ＩＤを使用してそれに識別情報を付加したＩＤとされる。「残高」は、共有部分の資金の残高を意味する。
また、各個別アカウント情報ファイル５２３は、「企業ＩＤ」、「共有ＩＤ」、「プリペイドＩＤ」、「日時」、「入金額」、「出金額」、「残高」等のフィールドから成るデータベースファイルである。「残高」は、個別所有部分の資金の残高を意味する。

また、各店舗アカウント情報ファイル５２４は、「店舗ＩＤ」、「日時」、「使用ＩＤ」、「入金額」、「送金予定日」等のフィールドから成るデータベースファイルである。「日時」は、当該店舗で給与プリペイドカードＣが使用された日時又は後述する決済の日時が記録される。「入金額」は、承認された給与プリペイドカードＣの使用額が記録される。「送金予定日」は、プリペイド口座６から当該店舗が所有する銀行口座への送金の予定日が記録される。

尚、企業アカウント情報ファイル５２１は、雇用主企業ごとに別のファイルとされても良いし、運営事業者がサービスを提供している複数の雇用主企業について一つのファイルとしても良い。別々のファイルとする場合、企業ＩＤを使用したファイル名とする等にして識別可能にしておく。共有アカウント情報ファイル５２２や各個別アカウント情報ファイル５２３についても同様である。各店舗アカウント情報ファイル５２４についても、店舗別のファイルとしても良いし、複数又は全ての店舗について一つのファイルとしても良い。

雇用主企業からプリペイド口座６に入金される当初の預託金の額は、給与プリペイドカードＣが発行される従業員の数や従業員一人あたりのプリペイドの額に応じて各雇用主企業と運営事業者との間で契約により取り決められる。例えば、従業員が５百人の企業（給与プリペイドカード発行枚数５００枚）で、一人あたりの給与プリペイドカードＣの発行額（初期値）が５万円の場合、初期の預託金の額は２千５百万円となる。全従業員が限度額いっぱいのカード使用を行うことは可能性として低いので、これより少ない額でも良い。例えば、二千万円とか、一千５百万円とかである。企業アカウント情報ファイル５２１の「入金額」のフィールドには、この金額が記録される。雇用主企業情報ファイル５１の「プリペイド金初期値」には、上記一人あたりの給与プリペイドカードＣの初期の発行額が記録される。

尚、図示は省略するが、記憶部５には、企業内担当者がシステムにログインするためのログイン用ファイルが記憶されている。ログイン用ファイルは、ログインＩＤやパスワードを記録したファイルである。各雇用主企業には、ログインＩＤ及びパスワードが発行され、プリペイド発行サーバ１等へのログインが可能となっている。ログインＩＤには、企業ＩＤが兼用される場合もあるし、企業ＩＤとは別に発行される場合もある。企業ＩＤが兼用される場合、ログイン用ファイルには、ログインＩＤが提供された企業内担当者が所属する雇用主企業の企業ＩＤが記録される。

また、記憶部５には、各雇用主企業に提供した給与プリペイドカードＣのプリペイドＩＤを記録したデータベースファイルであるカード提供情報ファイル５３が記憶されている。図５は、カード提供情報ファイルの構造の一例を示した概略図である。
この実施形態では、給与プリペイドカードＣの発行は、プリペイドＩＤが記載された必要枚数の給与プリペイドカードＣを運営事業者が雇用主企業にまず提供し、雇用主企業の担当者が給与プリペイドカードＣを各従業員に配布することで行われる。カード提供情報ファイル５３は、どの雇用主企業にどのプリペイドＩＤの給与プリペイドカードＣが提供されたが判るようにしたファイルである。

具体的には、図５に示すように、カード提供情報ファイル５３は、「提供年月日」、「プリペイドＩＤ」、「有効期限」、「発行有無」のフィールドから成るレコードを記録したデータベースファイルである。
「発行有無」のフィールドは、デフォルトは偽値のフィールドであり、後述するように従業員ＩＤと紐付けられて給与プリペイドカードＣが発行された場合に真値となるフィールドである。尚、カード提供情報ファイル５３は、企業ＩＤを使用したファイル名となっており、企業ＩＤによって特定が可能である。

また、記憶部５には、プリペイド設定情報ファイル５４が記憶されている。
プリペイド設定情報ファイル５４に記録された重要な情報は、プリペイド金の使用限度額の情報である。この実施形態では、三つの異なる使用限度額が設定されるようになっている。一つは、集計期間において一定の限度額の情報である。以下、この限度額を固定設定額と呼ぶ。もう一つは、集計期間において額が徐々に増加していく限度額の情報である。以下、この限度額を変動限度額と呼ぶ。さらにもう一つは、従業員に対して特別に設定される使用限度額である。以下、この限度額を特別設定額と呼ぶ。

最初の二つの限度額は、従業員の就労の状況に応じて設定される額であり、労働債権に基づくものである。したがって、この分のプリペイド金の使用は給与の前払い的な性格を有する。特別設定額は、雇用主企業と従業員との雇用契約を前提とするものの、必ずしも就労状況に基づくものではない。したがって、労働債権を越えた額の使用を許可する限度額であり得る。この意味で、特別設定額は、いわゆる前借り（借金）としての使用を許可する限度額であり得る。

このような三種類の設定額について、図６を参照してより詳しく説明する。図６は、三種類の設定額について示した概略図である。このうち、図６（１－１）（１－２）には、固定設定額について示されている。
図６（１－１）は、最もシンプルな例を示している。この例では、給与の締め日とカード使用の締め日が同一の例となっている。したがって、カード使用の集計期間は、給与の集計期間と同じ毎月１６日から翌月１５日である。
図６（１－１）の例では、毎月１５日にカード使用が集計され、同月２５日の給与から引き落としがされる。そして、固定設定額は、毎月１５日にゼロとなるが、翌日１６日には固定設定額まで回復する。即ち、プリペイド金が再チャージされる。図６（１－１）において、実線は固定設定額を示す。使用した額に応じて実際に使用可能な額は減っていく。図６（１－１）において、破線は、使用可能額の推移の一例を示している。

尚、図６（１－１）の例において、ある月の１５日に給与が締められると、その給与は同月の２５日に支給される。この場合、その就労を根拠に発行されるプリペイド金は、同月の１６日に支給され、翌月の１５日まで使用可能である。翌月の１５日までに使用したプリペイド金は、翌月の２５日の給与から差し引かれる。つまり、就労を根拠として発行されたプリペイド金の使用は、当該就労についての給与ではなく、翌月の給与から差し引かれる。
途中で退職した場合、直ちにカード使用は停止されるが、通常は日割りで給与が計算され、翌月に支給されるから、そこから差し引かれる。ちょうど１５日で退職した場合は例外で、この場合は、その時点までの集計がされて同月２５日の給与から差し引かれる。

図６（１－１）の例でも実施可能であるが、給与計算の締めとカード使用の締めとが同日であり、煩雑となるので、実際には、図６（１－２）のようにカード使用の締めを給与の締めの数日前とする場合が多い。図６（１－２）では、カード使用の締めは、毎月１０日となっている。この例では、ある月の１５日に締められた就労を根拠として１６日に固定設定額のプリペイド金がチャージされ、そのプリペイド金は、翌月１０日まで使用可能となる。そして、翌月１０日にカード使用が締められ、翌月２５日の給与から差し引かれる。このようにすると、カード使用の締め日から給与計算の締め日まで５日あるので、その間にカード使用の集計等の業務を行うことができ、煩雑さが軽減される。
図６（１－２）の例では、１０日にカード使用が締められた後、１１日には固定設定額に再チャージがされる。１１日～１５日のカード使用については、１５日の給与計算の際には間に合わないので、翌月１０日に締められる分にカウントされ、翌月２５日の給与から差し引かれる。

一方、変動設定額は、給与計算の締め日の前であっても従業員は日々就労しており、労働債権が発生しているということを考慮する。即ち、変動設定額は、図６（２）に示すように、給与の集計期間の初日の翌日から少しずつ増加する。変動設定額は、集計期間のある時点で固定設定額を上回り、ある金額に達すると増加は停止する。例えば、１６日～翌１５日が給与の集計期間の場合、１７日から増加し始め、翌月の１０日まで徐々に増加する。図６（２）の例は、固定設定額が３万円で、変動設定額が最大５万円の例となっている。

図６（２）のように変動設定額を導入すると、特に就職して働き始めた直後からプリペイド金の使用が可能となるという点でメリットがある。雇用主企業が給与プリペイドサービスの利用を開始した直後についても同様である。固定設定額のみでは、集計期間で給与が締められてから固定設定額での使用が可能となるので、最初の集計期間に達するまではプリペイド金の使用ができない。一方、図６（２）に示すように、変動設定額ついては、日々の就労に応じて付与される限度額であるので、働き始めた直後から使用が可能となる。

変動設定額についての使用の締め日については、固定設定額と同様で良い。例えば、毎月１０日の時点で締め、それまでの変動設定額の分の使用を集計する。そして、翌日１１日から就労はスタートしているから、翌々日の１２日から変動設定額の付与を開始し、徐々に増加させる。尚、図６（２）においても、実線は変動設定額を示す。

図６（３）には、特別設定額の一例が示されている。特別設定額は、上記固定設定額や変動設定額とは別に特別に設定される額であるので、特に決まったパターンはない。雇用主企業の判断で自由に設定できる。図６（３）では、労働債権を越えた額の使用を許可するいわゆる前借りとして設定する例が示されている。この例では、特別設定額も、就労状況に応じて徐々に増加する額となっている。但し、日々発生する労働債権を超える額であり得る。例えば、１日の給与が１万円のアルバイト従業員に対して、１日の就労をした翌日に１万５千円の特別設定額の付与がされてそこから日々増加する場合もあり得る。

図７は、プリペイド設定情報ファイル５４の構造の一例を示した概略図である。図７に示すように、プリペイド設定情報ファイル５４は、「プリペイドＩＤ」、「企業ＩＤ」、「従業員ＩＤ」、「従業員氏名」、「固定設定額」、「変動設定額」、「特別設定額」等のフィールドから成るデータベースファイルである。
プリペイド設定情報ファイル５４において、一意のデータはプリペイドＩＤである。従業員ＩＤは、従業員情報ファイルにおけるものと同じデータである。「固定設定額」、「変動設定額」、「特別設定額」はそれぞれ上述した意味の使用限度額を記録したフィールドである。

「変動増加額」のフィールドは、変動設定額が１回に増加する際の額である。「変動設定額最大値」のフィールドは、変動設定額の最大値が記録されるフィールドである。「特別種別」のフィールドは、特定設定額が漸増型か固定型かの種別を記録したフィールドである。「特別増加額」のフィールドは、特別増加額が漸増型の場合、１回に増加する際の額を記録したフィールドである。「特別最大額」は、特別設定額が漸増型の場合、最大値が記録されるフィールドである。

このような変動設定額の増加や、漸増型である場合の特別設定額の増加をプリペイド設定情報ファイル５４に自動的に記録するため、実施形態のシステムは、額増加サーバ７を備えている。額増加サーバ７には、設定額増加プログラム７１が実装されている。

設定額増加プログラム７１は、雇用主企業ごとにカスタマイズされて実装される。従業員が全て正社員又はフルタイムの契約社員やアルバイト・パートである場合、設定額増加プログラム７１は、雇用主企業の出勤日のたびに自動実行されるようプログラミングされる。この場合、設定額増加プログラム７１は、起動すると、各従業員ＩＤについて、プリペイドＩＤを取得してプリペイド設定情報ファイル５４を開き、「変動増加額」の値を取得する。そして、変動増加額の値を「変動設定額」の値に加算し、加算後の額が「変動最大額」の値以下であれば、その加算後の額で「変動設定額」のフィールドを更新する。また、変動最大額を超えているようであれば、変動最大額で「変動設定額」を更新する。

「特別種別」の値が漸増型であれば、設定額増加プログラム７１は、「特別増加額」の値を取得し、その額を「特別設定額」の値に加算する。そして、加算後の額が「特別最大額」の値以下であれば、その加算後の額で「特別設定額」を更新し、「特別最大額」の値を超えていれば、「特別最大額」の値で「特別設定額」を更新する。

雇用主企業において、出勤日が不定であるアルバイトやパートがいる場合、設定額増加プログラム７１は、タイムカードシステムと連動した状態で実装される。この場合、設定額増加プログラム７１には、各従業員ＩＤについて、時給と、１日の給与（時給×時間）に対してどの程度の増加額とするかの情報が与えられる。例えば、１日の給与に対して１０％の額を変動増加額として与えるとか、１日の給与に対して２０％を特別増加額として与えるとかの情報である。そして、タイムカードシステムからのプログラム実行要求に従
って設定額増加プログラム７１が実行され、その際、就労時間が引数として与えられる。設定額増加プログラム７１は、増加額を計算し、正社員等の場合と同様に「変動設定額」の値に加算して更新する。特別設定額についても同様である。

一方、記憶部５には、使用実績情報ファイル５５１が記憶されている。図８は、使用実績情報ファイル５５１の構造の一例を示した概略図である。
図８に示すように、使用実績情報ファイル５５１は、「使用ＩＤ」、「使用日時」、「店舗ＩＤ」、「店舗名」、「使用金額」、「使用枠ＩＤ」、「固定枠合計」、「変動枠合計」、「特別枠合計」等のフィールドから成るレコードを記録したデータベースファイルである。

使用ＩＤは、給与プリペイドカードＣの全ての使用について識別できるようにしたＩＤである。例えば、プリペイドＩＤと使用日と連番とを組み合わせたＩＤとされる。使用実績情報ファイル５５１は、プリペイドＩＤごとに作成されており、プリペイドＩＤを使用したファイル名となっている。したがって、プリペイドＩＤによって特定が可能である。

また、記憶部５には、全プリペイドＩＤについて使用実績を記録した全使用実績情報ファイル５５２が記憶されている。全使用実績情報ファイルについては、図示を省略するが、全使用実績情報ファイル５５２は、「使用ＩＤ」、「プリペイドＩＤ」、「使用日時」、「店舗ＩＤ」、「店舗名」、「店舗所在地」、「使用金額」、「摘要」等のフィールドから成るレコードを記録したデータベースファイルである。
また、記憶部５には、抹消情報ファイル５６が記憶されている。抹消情報ファイル５６は、盗難や紛失などによって抹消されたカードＣのプリペイドＩＤを記憶したファイルである。雇用主企業を退職した場合も、当該従業員についてのプリペイドＩＤが抹消情報ファイル５６に直ちに記録される。

次に、プリペイド発行サーバ１について説明する。図１に示すように、プリペイド発行サーバ１には、プリペイド発行プログラム１１が実装されている。実施形態の給与プリペイドシステムにおいて、給与プリペイドカードＣの発行は、企業内担当者がプリペイドＩＤと従業員ＩＤとを紐付けてプリペイド設定情報ファイル５４に記録させることで行われる。具体的には、プリペイド発行サーバ１は、企業内担当者用にプリペイド発行ページを用意している。図９は、プリペイド発行ページの一例を示した概略図である。

企業内担当者は、端末（以下、企業内担当者端末）８１を操作してプリペイド発行サーバ１にログインし、プリペイド発行ページを表示する。プリペイド発行ページには、供与されている未発行のプリペイドＩＤのリストを表示した欄（以下、未発行プリペイドＩＤ一覧）１１１と、各プリペイドＩＤについて従業員ＩＤを入力する従業員ＩＤ入力欄１１２、従業員氏名を入力する従業員氏名入力欄１１３が設けられている。プリペイド発行ページは、一行で一枚の給与プリペイドカードＣの発行情報を送信するページである。即ち、各行において、左端にプリペイドＩＤが表示され、その右側に当該プリペイドＩＤに紐付ける従業員ＩＤの入力欄が表示され、さらにその右側に、その従業員ＩＤに紐付けられている従業員氏名の入力欄が表示されるようになっている。

プリペイド発行サーバ１は、ログインの際に送信されたログインＩＤに従って当該雇用主企業のカード提供情報ファイル５３を検索し、「発行有無」のフィールドが偽値である全てのレコードのプリペイドＩＤを取得する。そして、図９に示すように、プリペイド発行ページに組み込んで担当者用端末に送信して表示させる。
プリペイド発行ページには、登録ボタン１１４が設けられている。登録ボタン１１４には、確認用のページが設けられており、ここに設けられた送信ボタンは、プリペイド発行プログラム１１に含まれる登録モジュールの実行ボタンとなっている。

登録モジュールは、各行に表示・入力された情報を１件のカード発行情報としてプリペイド設定情報ファイル５４に記録するモジュールである。即ち、登録モジュールは、プリペイド設定情報ファイル５４に新規レコードを追加し、プリペイドＩＤ、従業員ＩＤ、従業員名等のカード発行情報を記録するようプログラミングされている。全ての件のカード発行情報を記録すると、登録モジュールは終了であり、プリペイド発行プログラム１１も終了である。

上記プリペイド発行において、固定設定額には上述した初期値が設定される。即ち、登録モジュールは、ログインＩＤに従って企業ＩＤを取得し、企業情報ファイルを開く。そして、プリペイド金初期値を取得して新規レコードのデフォルトの「固定設定額」は、全ての従業員について一律の値として設定され得る（例えば一律５万円）。プリペイド発行プログラム１１は、プリペイド設定情報ファイル５４に新規レコードを追加した際、このデフォルト値を「固定設定額」のフィールドに記録する。このように登録モジュールはプログラミングされている。

次に、プリペイド設定額の変更について説明する。
プリペイド発行サーバ１は、プリペイド設定額の変更のためのページ（以下、設定額変更ページ）を用意している。企業内担当者から企業内担当者ＩＤによりログインがされ、トップページから呼び出されると、プリペイド発行サーバ１は設定額変更ページを企業内担当者端末８１に表示する。

図１０は、設定額変更ページの一例を示した概略図である。
図１０に示すように、設定額変更ページは、従業員ＩＤ入力欄１２１と、プリペイド設定額表示欄１２２と、変更額入力欄１２３とを備えている。また、管理サーバ４には、プリペイド設定額変更プログラム４１が実装されている。プリペイド設定額変更プログラム４１は、額表示モジュールと、額変更モジュールとを含んでいる。

プリペイド設定額表示欄１２２は、現在のプリペイド設定額を表示する欄である。固定設定額、変動最大額、変動増加額、特別設定額のそれぞれについて、現在の値が表示されるようになっている。特別設定額については、漸増型の場合、特別設定増加額が表示される。従業員ＩＤ入力欄１２１の横に設けられた検索ボタン１２０は、額表示モジュールの実行ボタンとなっている。額表示モジュールは、ログインＩＤに従って企業ＩＤを取得し、当該雇用主企業のプリペイド設定情報ファイル５４を開く。そして、従業員ＩＤで検索をして該当するレコードの「固定設定額」、「変動最大額」等のフィールドの値を取得し、プリペイド設定額表示欄１２２に表示するようプログラミングされている。また、額表示モジュールは、当該レコードの「従業員名」を取得し、確認のために従業員名表示欄１２４に表示する。
変更額入力欄１２３の横に設けられた登録ボタン１２５は、額変更モジュールの実行ボタンである。額変更モジュールは、プリペイド設定情報ファイル５４の該当レコードの「プリペイド設定額」を変更額入力欄１２３に入力された値で更新するようプログラミングされている。

次に、給与プリペイドカードＣの使用のための構成について説明する。
後述するように、給与プリペイドカードＣは本人認証の上で使用されるようにしても良いが、この実施形態では、給与プリペイドカードＣは本人認証なしに使用されることになっている。即ち、給与プリペイドカードＣの使用に際しては、プリペイドＩＤの取得と、有効期限内及び使用限度額内であるかの確認と、当該給与プリペイドカードＣが抹消カードではないという確認がされれば足りるという技術構成となっている。以下、これらの点について説明する。

給与プリペイドカードＣが使用される各店舗には、店舗端末９が配置されている。店舗端末９は、この実施形態における店舗側コンピュータの例である。各店舗端末９には、ネットワーク（インターネット）を介してカード使用承認サーバ２にアクセスする承認要請プログラム９１がインストールされている。カード使用承認サーバ２には、使用承認プログラム２１が実装されている。図１１は、使用承認プログラムの概略を示したフローチャートである。

記憶部５には、店舗情報ファイル５７が記憶されている。店舗情報ファイル５７の構造の図示は省略するが、店舗情報ファイル５７は、「店舗ＩＤ」、「本部ＩＤ」、「店舗名」、「所在地」等のフィールドから成るデータベースファイルである。「本部ＩＤ」は、必要に応じて記録されるフィールドであり、チェーン展開されている店舗のように店舗を運営する事業体が別にあり、それを識別する必要がある場合に入力されるフィールドである。

各店舗端末９は、ＩＣカードリーダのような読み取り機能を備えた端末である。それとともに、各店舗端末９はメモリ等の記憶部を有しており、記憶部５には承認要請プログラム９１とともに店舗ＩＤが記憶されている。承認要請プログラム９１は、給与プリペイドカードＣが挿入された際に自動的に起動するよう各店舗端末９にインストールされている。また、各店舗端末９には、商品・サービスの販売代金を使用要請額として入力するテンキーが設けられている。販売代金をＰＯＳ機器から取得するよう店舗端末９がＰＯＳ機器に接続されている場合もある。

承認要請プログラム９１は、給与プリペイドカードＣが挿入された際に自動的に起動し、使用要請額の入力待ちの状態となる。使用要請額は、通常、店舗で係の者がテンキーで入力するか又はＰＯＳ機器から入力される。使用要請額が入力されると、承認要請プログラム９１は、給与プリペイドカードＣから読み取ったプリペイドＩＤと、入力された使用要請額と、店舗ＩＤとをカード使用承認サーバ２に送り、使用承認プログラム２１を起動するようプログラミングされている。
図１１に示すように、使用承認プログラム２１は、まずプリペイドＩＤで抹消情報ファイル５６を検索し、抹消された給与プリペイドカードでないかどうか判断する。抹消された給与プリペイドカードであれば、その旨を承認要請プログラム９１（店舗端末９）に返信し、プログラムを終了する。また、図示は省略されているが、使用承認プログラム２１は、プリペイドＩＤに従ってプリペイド設定情報ファイルを検索し、該当するレコードの有効期限を取得する。そして、有効期限を過ぎていれば、承認不可を戻してプログラムを終了する。

抹消情報ファイル５６にプリペイドＩＤが記録されておらず、有効期限も過ぎていなければ、使用承認プログラム２１は、プリペイドＩＤに従って該当するユーザー（従業員）のプリペイド設定情報ファイル５４を開き、「固定設定額」、「変動設定額」、「特別設定額」の値をそれぞれ取得する。そして、それらの値のうち、最も高い設定額について、対応する使用合計額の値を使用実績情報ファイル５５１の最後のレコード（最新の使用実績のレコード）から取得する。例えば、「固定設定額」が最も高ければ「固定枠合計」を取得する。「変動設定額」が最も高ければ「変動枠合計」を取得する。「特別設定額」が最も高ければ、「特別枠合計」を取得する。そして、取得した使用合計額と送信された使用要請額とを加算した額が当該設定額以下であれば、使用承認の戻り値を承認要請プログラム９１に戻す。例えば、固定設定額が最も高い場合、固定枠使用合計額と使用要請額とを加算した額が当該固定設定額以下であれば、使用承認の戻り値を戻す。

使用承認の戻り値を戻した場合、使用承認プログラム２１は、使用実績情報ファイル５
５１に新規レコード追加する。そして、使用限度額の種別に従い、「使用枠ＩＤ」を記録するととともに、該当する種別の使用合計額を使用要請額の額を加算して更新する。また、使用ＩＤを自動生成し、「使用ＩＤ」のフィールドに記録する。さらに、店舗ＩＤで店舗情報ファイル５７を検索して店舗名を取得し、使用実績情報ファイル５５１において追加したレコードにそれらの情報を記録する。また、全使用実績情報ファイル５５２にも新規レコードを追加し、店舗ＩＤや使用要請額等を記録する。一方、店舗端末９から送信された使用要請額が上記条件を満足しない場合、承認要請プログラム９１は、承認不可の戻り値を承認要請プログラム９１に送信して終了する。

次に、給与プリペイドカードＣが使用された店舗との決済のための構成について説明する。
ここでの決済サーバによる決済は、店舗が保有する銀行口座への送金ということでなくて、プリペイド口座６内での所有関係の変更（資金の移動）を意味している。技術的には、各プリペイド口座情報ファイル５２１～５２４の記録を変更することに相当している。

上述した使用承認サーバ２は、決済サーバとしても機能するようになっている。即ち、使用承認サーバ２には、決済プログラム２２が実装されている。また、実施形態のシステムは、企業アカウント６１から共有アカウント６２に資金を充填する充填サーバを備えており、使用承認サーバ２は充填サーバとしても機能するようになっている。即ち、決済プログラム２２は、資金充填を行うコードも含んでいる。
この実施形態では、決済プログラム２２は、給与プリペイドカードＣの使用の際にリアルタイムで行われるようになっており、決済プログラム２２は、使用承認プログラム２１から呼び出されて実行される。即ち、使用承認プログラム２１は、使用を承認して使用実績情報ファイル５５１に使用実績情報を記録した後、決済プログラム２２を実行して終了する。

図１２は、決済プログラム２２の概略を示したフローチャートである。決済プログラム２２は、プリペイドＩＤ、使用ＩＤ、使用要請額及び店舗ＩＤが引数として渡されて実行される。図１２に示すように、決済プログラム２２は、共有アカウント情報ファイル５２２を開き、新規レコードを追加する。そして、追加したレコードの「日時」にプログラムの実行日時を記録し、使用ＩＤを「使用ＩＤ」に記録し、使用要請額を「出金額」に記録し、プリペイドＩＤを「プリペイドＩＤ」に記録し、店舗ＩＤを「店舗ＩＤ」に記録する。「残高」のフィールドは、出金後の金額が自動計算されて記録される。

次に、当該プリペイドＩＤに係る個別アカウント情報ファイル５２３を開き、新規レコードを追加する。そして、プログラム実行日時を「日時」に、使用ＩＤを「使用ＩＤを」に、使用要請額を「入金額」に、店舗ＩＤを「店舗ＩＤ」にそれぞれ記録する。「残高」のフィールドは、入金後の金額が自動計算されて更新される。

次に、決済プログラム２２は、同じ個別アカウント情報ファイル５２３においてさらに新規レコードを追加する。そして、プログラム実行日時を「日時」に、使用ＩＤを「使用ＩＤを」に、使用要請額を「出金額」に、店舗ＩＤを「店舗ＩＤ」にそれぞれ記録する。「残高」のフィールドは、出金後の金額が自動計算されて更新される。通常は、残高はゼロとなる。

次に、決済プログラム２２は、店舗ＩＤに従って該当する店舗の店舗情報ファイル５７を開き、新規レコードを追加する。そして、プログラム実行日時を「日時」に、プリペイドＩＤを「プリペイドＩＤ」に、使用ＩＤを「使用ＩＤを」に、使用要請額を「入金額」にそれぞれ記録する。「残高」のフィールドは、入金後の金額が自動計算されて更新される。

その後、決済プログラム２２は、企業アカウント６１からの資金の充填を行う。即ち、企業アカウント情報ファイル５２１を開き、新規レコードを追加する。そして、プログラム実行日時を「日時」に、使用要請額を「出金額」に記録する。「残高」のフィールドは、出金後の金額が自動計算されて更新される。そして、共有アカウント情報ファイル５２２を開き、プログラム実行日時を「日時」に、使用要請額を「入金額」に記録する。

このように、決済プログラム２２は、共有アカウント６２、個別アカウント６３、店舗アカウント６４の順で資金を移動させる。その後、共有アカウント６２に対し、減った分の資金を企業アカウント６１から移動させて充填する。このように各ファイル５２１～５２４への情報記録が行われるよう、決済プログラム２２はプログラミングされている。

上記説明から解るように、決済プログラム２２は、決済用の資金を当該使用を行った従業員の個別アカウント６３に入れてから店舗アカウント６４に入れる。このため、法律上（契約上）は、決済用の資金は、いったん当該従業員の所有になった後、店舗の所有となる。
尚、実際の送金は、プリペイド口座６から、当該店舗が所有する銀行口座に対して行われる。これは、例えば２ヶ月に一回というような頻度で行われ、その間の決済金額を合計して銀行口座間の送金（振り込み）が行われる。

次に、給与プリペイドカードＣの使用額の集計について説明する。
上述したように店舗に対する支払いにおける給与プリペイドカードＣの使用については、給与から差し引かれる。したがって、給与計算の締め日又はそれ以前にカード使用額の集計が行われることが好ましい。例えば、給与計算の締め日が毎月１５日で、給与の支給日はその月の２５日の場合、集計は毎月１０日に行われる。

図１に示すように、実施形態のシステムは、集計プログラム３１が実装された集計サーバ３を備えている。集計サーバ３は、雇用主企業ごと、従業員ごとに給与プリペイドカードＣの使用額を集計するサーバである。集計された使用額は、当該雇用主企業が予め拠出した預託金を原資として精算される。

図１３は、集計プログラム３１の概略を示したフローチャートである。
図１３に示すように、集計プログラム３１は、従業員情報ファイルを開き、最初のレコードの従業員ＩＤを取得する。そして、プリペイド設定情報ファイル５４を開き、その従業員ＩＤに対応するプリペイドＩＤを取得する。そして、そのプリペイドＩＤについての使用実績情報ファイル５５１を開き、「固定枠合計」、「変動枠合計」、「特別枠合計」をそれぞれ取得する。次に、それらを合算し、その額（プリペイド使用総額）をプリペイドＩＤとともに集計用ファイル３２に新規レコードを追加して記録する。集計用ファイル３２は、集計時期に雇用主企業ごとに作成されるファイルであり、プリペイドＩＤ、プリペイド使用総額等を記録したデータベースファイルである。

次に、集計プログラム３１は、プリペイド設定情報ファイル５４を開き、該当するプリペイドＩＤのレコードについて、「変動設定額」の値をゼロにして更新する。また、「特別種別」が漸増型の場合、「特別設定額」の値もゼロにして更新する。
集計プログラム３１は、このようにして従業員ＩＤを次々に読み込み、プリペイド使用総額を算出し、その額を集計用ファイル３２の新規レコードに記録する。尚、図１３では省略されているが、実際には、運営事業者は多数の雇用主企業にサービスを提供しており、集計プログラム３１は、各雇用主企業における各従業員ＩＤについて実行され、集計用ファイル３２は、雇用主企業ごとに作成される。集計用ファイル３２は、企業ＩＤを使用したファイル名とされ、企業ＩＤによって特定が可能となっている。

このような実施形態の給与プリペイドシステムの動作について、以下にまとめて説明する。
運営事業者は、給与プリペイド導入について各雇用主企業に募り、応じてきた企業と契約を取り交わす。契約には、給与プリペイドカード発行枚数（プリペイドＩＤの発行数）と一人あたり（プリペイドＩＤ一個あたり）の初期のプリペイド設定額（プリペイド金初期値）が含まれる。契約した雇用主企業は、預託金をプリペイド口座６に振り込む。
運営事業者は、契約書に記載された枚数の給与プリペイドカードＣを雇用主企業に提供する。この際、カード提供情報ファイル５３が作成され、提供された各給与プリペイドカードＣのプリペイドＩＤがファイルに記録される。

給与プリペイドカードＣが届いた雇用主企業では、企業内担当者が企業内担当者端末８１を操作してプリペイド発行サーバ１にログインする。そして、プリペイド発行ページを企業内担当者端末８１に表示し、各プリペイドＩＤについて従業員ＩＤと従業員氏名とを入力する。ＯＫボタンをクリックして確認画面で確認した後、送信ボタンをクリックする。これにより、登録モジュールが実行され、プリペイド設定情報ファイル５４にそれぞれ新規レコードが追加され、従業員ＩＤ、従業員氏名等がそれぞれ記録される。そして、企業内担当者は、従業員ＩＤと紐付けた給与プリペイドカードＣを当該従業員に渡し、給与プリペイドカード発行を完了する。

給与プリペイドカードＣが発行されたユーザー（従業員）は、任意の店舗で給与プリペイドカードＣを使用する。即ち、精算の際に給与プリペイドカードＣを店舗に差し出す。差し出された給与プリペイドカードＣは、店舗端末９で読み取りがされ、承認要請プログラム９１が実行される。抹消カードではなく、また使用期限内であり、且つ最も大きな枠（設定額）における使用合計額と使用要請額とを加算した額が当該設定額以下であると、使用承認が返信される。使用承認が返信されると、精算がされたとして給与プリペイドカードＣをユーザーに返却する。この際、店舗端末９は簡易タイプのプリンタを備えている場合が多く、この場合にはカード使用の記録が印刷されてユーザーに渡される。

使用承認プログラム２１は、当該プリペイドＩＤの使用実績情報ファイル５５１を開き、新規レコード追加する。そして、使用した設定額の枠についての使用合計額に対して使用要請額を加算して更新する。さらに、店舗ＩＤで店舗情報ファイル５７を検索して店舗名等を取得し、使用実績情報ファイル５５１に追加したレコードにそれらの情報を記録する。また、全使用実績情報ファイル５５２にも新規レコードが追加され、店舗ＩＤや使用要請額等が記録される。

使用承認プログラム２１は、サブルーチンとして決済プログラム２２を実行する。決済プログラム２２は、プリペイド口座６において共有アカウント６２から個別アカウント６３に資金を移し替える操作（情報の記録）を行った後、個別アカウント６３から当該店舗ＩＤに係る店舗アカウント６４に資金を移す。その後、使用要請額の金額を企業アカウント６１から共有アカウント６２に充填する。

このようにして各給与プリペイドカードＣの各使用について承認がされ、各使用実績の情報が使用実績情報ファイル５５１及び全使用実績情報ファイル５５２に記録される。また、各使用について即座に決済がされる。そして、カード締め日が到来した際、集計プログラム３１が実行され、プリペイドＩＤごとにカード使用額が集計され、雇用主企業毎に集計用ファイル３２が作成されて記録される。集計された各カード使用額は、各従業員について給与から差し引かれる。

カード使用に伴い、企業アカウント６１の残高は減少していくから、雇用主企業は、プリペイド口座６に預託金を追加する。運営事業者は、定期的に雇用主企業ごとにカード使用の総額を集計し、それに基づいて預託金追加の請求をする。雇用主企業は、これに基づき預託金を追加する。

雇用主企業は、適宜の時期にプリペイド設定額を変更し得る。一般的には、給与締め日の後に、プリペイド設定額の変更が必要になった際に行われる。正社員の場合にはプリペイド設定額は頻繁に変更されない場合が多いが、アルバイトやパートタイマーの場合には、頻繁に変更され得る。例えば、給与を締めた際、あるアルバイトの給与が想定より低かった場合、プリペイド設定額が変更される。企業内担当者は管理サーバ４にログインし、プリペイド設定額変更ページを表示する。そして、変更する従業員の従業員ＩＤを入力し、変更後のプリペイド設定額を入力してプリペイド設定情報ファイル５４を更新させる。いったん下げたプリペイド設定額を上げる場合も、同様に企業内担当者が企業内担当者端末８１を操作して行う。正社員の場合でも、定期昇給等により昇給した場合、プリペイド設定額が適宜変更される。

運営事業者と各雇用主企業との間で締結される契約には、給与プリペイドサービスの利用料が含まれる。利用料は、例えばプリペイドＩＤ一つについて月額（使用が全くないプリペイドＩＤについてはゼロ）とされ、毎月集計がされて請求される。

このような実施形態の給与プリペイドシステムによれば、従業員の給与が給与プリペイドカードＣという形で事前に支払われる。限度額はあるものの、従業員にとっては給与プリペイドカードＣを提示するだけで店舗での支払いができるので、極めて利便性が高い。従来であれば、自分で給与を銀行口座から現金を引き出してプリペイドカードにチャージする必要があるが、この実施形態ではそのような面倒はない。また、クレジットカードではないので、引き落とし日に銀行口座に確実に預金があるようにしなければならないというプレッシャーもない。このため、心理面のユーザビリティも非常に高い。

また、通常、給与の前払いというは、従業員が会社に申請をして認められるが、この実施形態のシステムによれば、事前の申請は不要である。申請をすると、申請を処理する部署（総務部等）にその事実が知れるから、従業員にとって心理的な負担もある。実施形態のシステムによれば、このような心理的な負担もなく、この点でもユーザビリティが非常に高い。

一方、雇用主企業にとっても、給与プリペイドの制度があることで従業員による評価が高まり、従業員を優遇している企業としての印象が高くなる。このため、優秀な人材を多く集めるのに貢献し、結果的に企業業績を高めていくことができる。この際、プリペイドとはいっても、個別に従業員の口座に現金を振り込むようなやり方であると煩雑この上ないが、使用限度額のあるプリペイドカードＣを供与するというだけであるので、極めて簡便である。

また、上述したように、決済用の口座としてプリペイド口座６が用意されており、決済のための資金がいったん当該従業員の保有になった後に店舗に振り込まれるようにしている。これは、法律的に、前払いであっても給与が従業員に対して付与され、その後、決済のために使用されたという形をより明確にするという意義がある。

尚、プリペイド口座６において、企業アカウント６１とは別に共有アカウント６２や個別アカウント６３が設けられている点には、給与プリペイドサービスの利用を取りやめる際の損金を少なくするという意義がある。本願発明の実施に際しては、プリペイド口座６においてカウントを分けずに決済を行う構成も考えられる。しかしながら、現在の制度では、プリペイドカードについては返金が認められていない。プリペイド口座６に入れられた資金の所有関係を区分せずに決済を行うと、全体がプリペイドされた資金ということになるため、サービスの利用を取りやめる際、その口座の資金を回収することができない。このため、雇用主企業において大きな損金となり得る。

プリペイド口座６において所有関係を分け、共有アカウント６２や個別アカウント６３のみを決済用の資金（プリペイドされた資金）としておけば、サービスの利用を取りやめる場合にも企業アカウント６１の資金は回収することができる。このため、損金は極めて小さくなる。即ち、共有アカウント６２には、一回の決済に必要な最大額のみ資金があれば足りる。これは、一個のプリペイドＩＤについてのプリペイド設定額に相当しているから、その金額は大きくはない。したがって、一回の決済に必要な最大額のみを共有アカウント６２上の資金としておき、その都度、個別アカウント６３に移して決済すれば、共有アカウント６２上の資金は必要最小限の少額となり、損金になったとしても雇用主企業において問題とされる額にはならない。
尚、いわゆるプリペイドカードと同様の意味（狭義の意味）で捉えると、使う人自身が保有している資金ということになるから、プリペイド口座６うち共用アカウント６２と各個別アカウント６３の部分がプリペイド口座ということになる。この点を、図３中に破線で示す。

上記説明において、各設定額の変更は、企業内担当者が管理サーバ４にアクセスして個別に入力して行うように説明したが、給与システムとの連動等によって自動的に行われるようにする場合もあり、その方がさらに簡便になるので、好適である。例えば、給与システムは、給与を締めた場合、従業員ＩＤと支払い給与額とをＣＳＶのような汎用形式のデータベースファイルに記録して出力できる機能が実装されている場合が多い（以下、このファイルを給与情報ファイルという）。管理サーバ４上の設定変更プログラムは、給与情報ファイルを読み込んで自動的にプリペイド設定額を変更するようプログラミングされ得る。この場合は、例えば支払い給与額の２０％を一律にプリペイド設定額として変更設定するようプログラミングされ得る。企業内担当者は、給与情報ファイルを管理サーバ４に送信し、管理サーバ４はこれを引数にしてプリペイド変更プログラムを実行する。

また、上記実施形態では、特別設定額によるプリペイド金の使用も可能となっている。このため、前借りという形で固定設定額や変動設定額を超える額の使用ができるので、従業員にとってさらに利便性が高まる。また、雇用主企業にとっても、前借り枠設定という従業員優遇策を講じていることがさらに企業イメージアップにつながる。尚、特別設定額を前借りとする場合、金利を徴収しても良く、徴収しなくても良い。金利を徴収する場合、固定設定額や変動設定額とは別に使用を集計して区別するよう集計プログラム３１が実装される。

次に、第二の実施形態の給与プリペイドシステムについて説明する。図１４は、第二の実施形態の給与プリペイドシステムの概略図である。
第二の実施形態では、給与プリペイドカードＣが、従業員の私用だけではなく、当該雇用主企業の業務において必要な支払いという用途（以下、社用という。）のために使用できるようになっている。この点が上記実施形態と異なっている。

社用での使用を全従業員に対して許可する場合もあるが、通常は、営業担当の社員や役員である場合が多く、限定されている。したがって、プリペイド設定情報ファイル５４には、当該給与プリペイドカードＣを使用する従業員が社用許可であるかどうかの情報を記録したフィールドが設けられる。
また、社用での使用のため、当該プリペイドＩＤについては、固定設定額は通常より高い額とされる。雇用主企業の企業内担当者は、社用での使用が許可されている従業員について、通常よりも固定設定額を高くするよう設定額変更ページで設定を行う。

給与プリペイドカードＣの使用や使用承認については、第一の実施形態と特に変わるところはない。変更されている点は、給与プリペイドカードＣの使用について用途種別を入力できるようになっている点と、社用での使用を承認する社用承認プログラム４２が管理サーバ４に実装されている点である。尚、第一の実施形態においても、用途種別の入力および社用認証プログラムを実装し、いかなる時点でも私用から社用への用途変更にも対応できる構造としても良い。
図１５は、第二の実施形態における使用実績情報ファイル５５１の構造の一例を示した概略図である。図１５に示すように、この実施形態では、使用実績情報ファイル５５１の各レコードは、「用途種別」のフィールドと、「社用承認」のフィールドを有している。

管理サーバ４は、社用が許可された各従業員（以下、許可従業員という。）に対して用途入力ページを提供するものとなっている。図１６は、用途入力ページの一例を示した概略図である。
図１６に示すように、用途入力ページでは、当月のカード締め日で締められた自身の使用実績情報がリスト表示されるようになっている。各許可従業員には、用途入力ページにアクセスするためのログインＩＤとパスワードが提供される。ログインＩＤは、プリペイドＩＤと同じものとするか、又は企業ＩＤと従業員ＩＤを組み合わせたものとされる。許可従業員が自身の端末（ＰＣ、スマートフォン等）８２を使用してログインＩＤとパスワードを送信してログインすると、図１６に示す用途入力ページが表示される。用途入力ページを表示するモジュールは、ログインＩＤに対応するプリペイドＩＤに従って使用実績情報ファイル５５１を開き、当月の情報を図１６に示すようにリスト表示するようプログラミングされている。

図１６に示すように、用途入力ページでは、リストの各行に、「社用」、「私用」、「その他」の種別入力欄（ここではプルダウンリスト）４２１が設けられている。用途入力ページには、送信ボタン４２２が設けられている。送信ボタン４２２は、種別登録モジュールの実行ボタンとなっている。リストの各行には当該行の使用についての使用ＩＤが埋め込まれている。種別登録モジュールは、プリペイドＩＤに従って当該従業員の使用実績情報ファイル５５１を開き、該当する使用ＩＤのレコードの「用途種別」のフィールドに、種別入力欄で入力された値を記録するようプログラミングされている。尚、「用途種別」のデフォルトの値は社用である。

また、社用での使用の承認は、この実施形態では、雇用主企業の企業内担当者が個別に企業内担当者端末８１から承認送信をすることで行われる。社用承認プログラム４２は、この送信を行わせるためのプログラムである。
具体的に説明すると、社用承認プログラム４２は、社用承認ページを企業内担当者端末８１に表示するモジュールを含んでいる。図１７は、社用承認ページの一例を示した概略である。

図１７は、あるプリペイドＩＤが選択された状態を示している。企業内担当者端末８１においてログインがされて表示されるトップページには、社用承認ボタンが設けられており、これがクリックされると、許可従業員のリストが表示されるようになっている。ログインＩＤに従って当該企業ＩＤのプリペイド設定情報ファイル５４を開き、社用許可のフィールドが真値である従業員の氏名等を取得してリスト化するようモジュールがプログラミングされる。リスト表示された従業員から特定の従業員を選択すると、図１７に示す社用承認ページが表示される。

図１７に示すように、社用承認ページでは、当月のカード締め日で締められた各給与プリペイドカードＣの使用実績情報がリスト表示されるようになっている。社用承認ページを表示するモジュールは、プリペイドＩＤに従って使用実績情報ファイル５５１を開き、当月の情報を図１７に示すようにリスト表示するようプログラミングされている。
図１７に示すように、リストの各行には、用途種別表示欄４２３と、承認用のチェックボックス（以下、承認入力欄）４２４が設けられている。用途種別表示欄４２３は、使用実績情報ファイル５５１の「用途種別」の値が表示される。デフォルトの値は「社用」であるので、許可従業員が変更していない限り、「社用」の表示となる。この点は、社用での使用が多いことを想定し、変更入力の手間を大幅に削減することを考慮したものである。
「社用」の表示がされている行の使用について、企業内担当者は、給与プリペイドカードＣが使用された店舗名や摘要の情報から社用を承認して良いかどうか判断し、良い場合には承認入力欄（チェックボックス）４２４にチェックを入れる。

社用承認ページは、送信ボタン４２５が設けられている。送信ボタン４２５は、社用登録モジュールの実行ボタンとなっている。リストの各行には当該行の使用についての使用ＩＤが埋め込まれている。社用登録モジュールは、プリペイドＩＤに従って当該従業員の使用実績情報ファイル５５１を開く。使用実績情報ファイル５５１の各レコードは、「社用承認」のフィールドを有している。社用登録モジュールは、承認入力欄４２４にチェックが入れられた行の使用ＩＤを取得し、使用実績情報ファイル５５１の該当レコードの「社用承認」のフィールドに真値を記録する。社用登録モジュールは、この処理を、チェックが入った全ての使用について行う。企業内担当者は、社用が承認されている他の従業員についても同様の処理を行う。

一方、この実施形態において、集計プログラム３１が上記実施形態と異なっている。図１８は、第二の実施形態における集計プログラム３１の概略を示したフローチャートである。
図１８に示すように、この実施形態においても、集計プログラム３１は、最初の従業員ＩＤを読み込み、対応するプリペイドＩＤをプリペイド設定情報ファイル５４から取得する。そして、そのプリペイドＩＤについての使用実績情報ファイル５５１を開く。

次に、集計プログラム３１は、「社用」のフィールドが真値である全てのレコード（集計期間内の全てのレコード）の「使用額」のフィールドの値の合計を算出する。そして、プリペイドの使用額から社用での使用の合計を差し引く。これが、当該従業員の私用でのカード使用総額である。集計プログラム３１は、同様に集計用ファイル３２の当該従業ＩＤのレコードにこのカード使用総額を記録する。集計プログラム３１は、このような処理を全ての従業員ＩＤについて行う。

この実施形態によれば、給与プリペイドカードＣを社用でも使用することができる。このため、一枚の給与プリペイドカードＣを携帯するだけでプリペイド金で社用でも私用でも商品・サービスの決済をすることができ、極めて利便性が高い。そして、説明は省略したが、集計サーバ３は、社用分の集計を行うプログラムも実装しており、社用分の使用の精算も集計サーバ３により自動的に行われる。このため、ユーザー（従業員）にとって煩雑さは全くない。

また、別の実施形態として、一人の従業員に対して、私用の給与プリペイドカードと社用の給与プリペイドカードとを提供しても良い。これは、一人の従業員に対して私用のプリペイドＩＤと社用のプリペイドＩＤとを提供することを意味する。このようにしておくと、従業員は用途に応じて使い分ければ良く、用途変更の入力は不要になるので、さらに好適である。

次に、第三の実施形態の給与プリペイドシステムについて説明する。図１９は、第三の実施形態の給与プリペイドシステムの主要部を示した概略図である。
第三の実施形態では、プリペイド口座６の構成が上記各実施形態と行っている。図１９に示すように、第三の実施形態では、プリペイド口座（広義のプリペイド口座）６は、企業アカウントを含んでいない。そして、プリペイド口座６とは別の銀行口座として、企業アカウント口座６０が設けられる。

企業アカウント口座６０も、プリペイド口座６内の共用アカウント６２に対する充填用である。そして、この実施形態では、リアルタイムの資金充填を行うため、デビット方式を採用している。具体的には、この実施形態でも、使用承認サーバ２は決済サーバに兼用される。そして、使用承認サーバ２は、企業アカウント口座６０に対してデビット方式により資金引き落としの権限が与えられている。即ち、デビット方式による引き落としの契約が、雇用主企業と運営事業者との間で締結される。

使用承認サーバ２に実装された決済プログラム２２は、共用アカウント６２から個別アカウント６３、店舗アカウント６４に資金を移動して決済を行った後、デビッド方式により即座に資金を企業アカウント口座６０からプリペイド口座６内の共用アカウント６２に移動させるようプログラミングされている。その他の構成は、上記第一又は第二の実施形態と同様である。

この実施形態では、雇用主企業は、プリペイド口座６に預託金を入金する必要はないので、この部分の構成が簡略化される。即ち、運営事業者にとっては預託金の請求の手間はなく、雇用主企業にとっても預託金を入金する手間もない。このため、好適である。尚、この実施形態でも、一回に充填される資金は、一枚の給与プリペイドカードＣの一回の使用の最大額であるので、それより大きな額が一回のデビッド引き落としでされることはない。

次に、第四の実施形態の給与プリペイドシステムについて説明する。図２０は、第四の実施形態の給与プリペイドシステムの主要部を示した概略図である。
第四の実施形態の給与プリペイドシステムは、他事業者が行うプリペイドサービスを利用するものとなっており、この点が上記各実施形態と異なっている。例えば、銀行口座にある資金（預金）を根拠にプリペイドカードを発行するサービスを銀行系の事業者が提供する場合があり得るが、このような事業者が他事業者に該当する。以下、他事業者のプリペイドカードサービスを他事業者サービスという。

ユーザー（従業員）は、自身の銀行口座（以下、他サービス口座という）６００にある預金を根拠としてプリペイドカード（以下、他事業者カードという。）Ｃ’を発行してもらう。他事業者は、自身が運営するサーバ（以下、他事業者サーバという。）により、ユーザーアカウント６０１と、店舗アカウント６０２を管理しており、決済の際には銀行口座６００にある預金の名義を他事業者カードＣ’の利用に応じて店舗アカウント６０２に移す。

一方、運営事業者が管理するプリペイド口座６には同様に共用アカウント６２が存在している。そして、この実施形態では、プリペイド口座６から他サービス口座６００にデビット方式で資金を移動させる資金移動サーバ（不図示）が設けられる。資金移動サーバによる資金の移動は、他事業者サーバからの要求により行われる。具体的には、他事業者カードにおける残高が一定以下になったら自動的に資金を移動してチャージする構成が採用され得る。例えば、ユーザー自身が初期に預けた預金の額が５万円とし、給与プリペイドサービスにおける初期値のプリペイド設定額が５万円とすると、ユーザーアカウント６０１の残高が１０万円を下回った時点で、１０万円との差額を５万円を限度として資金移動サーバがデビット方式で銀行口座６００に充填する。これは、給与プリペイドの分が優先的に使われる構成であるが、５万円を下回った時点で５万円を限度して充填する構成でも良い。いずれにしても、資金の充填が、上記実施形態におけるプリペイド金の使用ということになる。

この実施形態によれば、プリペイドカードの発行や使用の承認、決済は他事業者が行うので、給与プリペイドサービスの運営事業者における業務の負担が軽減される。この実施形態では、一つの雇用主企業に属するユーザー（従業員）が異なる他事業者サービスを利用することも十分にあり得るから、給与プリペイドサービスの運営事業者は、異なる複数の他事業者と提携して給与プリペイドサービスを提供することになる。

尚、上記各実施形態では、プリペイド金の原資は、雇用主企業がプリペイド口座（銀行口座）６に預けた預託金であり、したがってプリペイド金は会計上は現預金である。しかしながら、本願発明の実施に際しては、プリペイド金は、他の種類の資産・資金であり得る。例えば、プリペイド口座は、通貨建て資産に係る口座であっても良い。この場合は、雇用主企業は通貨建て資産の形でプリペイド口座に預託金を預ける。さらに、プリペイド金は、仮想通貨、暗号資産、トークンやその他の電子マネーであっても良い。トークンは、既存のブロックチェーンを利用して発行される資産である。さらに、プリペイド金は、いわゆるポイントカードにおけるポイントの場合もあり得る。例えば、キャッシュバックサービスで使用されるポイントカードにチャージする形（ポイントという形）で給与が前払いされ、それが使用される場合もあり得る。この場合、ユーザー（従業員）は、キャッシュバックサービスにおけるポイントと前払いのポイントとを合算して使用することもできる。

また、上記各実施形態において、給与プリペイドカードＣは、ＩＤ担持物の一例である。本願発明の実施に際しては、プリペイドＩＤが店舗に提示されれば良いので、他の種類のＩＤ担持物とされることもあり得る。例えば、ＩＤ担持物は、スマートフォンやタブレットＰＣのようなモバイル端末であっても良い。モバイル端末上にプリペイドＩＤを表示して店舗に提示するとか、モバイル端末と店舗端末９との間で近距離通信（ＮＦＣ）を行って情報を取得したりする構成があり得る。

さらに、ＩＤ担持物は、ユーザー（従業員）自身である場合もあり得る。例えば、指紋、静脈、網膜、声紋といった生体上の特徴点によって認証する技術が種々開発されているが、このような生体特徴部分をＩＤ担持物とすることも可能である。この場合、店舗端末９には、そのような生体特徴部分を読み取る機能が実装されて、読み取られた生体特徴部分の情報は、使用要請額とともに使用承認サーバ２に送られる。記憶部５には、プリペイドＩＤと生体特徴部分の情報とを関連づけて記録したファイルが記憶されており、使用承認サーバ２は、このファイルにアクセスすることで、プリペイドＩＤの取得と使用の承認とを行う。
また、ＩＤ担持物がいわゆるデポジットカードである場合もあり得る。デポジットカードは、一般的には、発行に際してデポジット金（保証金）が必要なクレジットカードである。本願発明において、例えば給与プリペイドカードＣについて、預託金とは別に保証金を預けてもらう場合があり得る。預託金がゼロとなり、使用についての充填ができなくなった場合、保証金を取り崩して精算する場合があり得る。このような給与プリペイドカードＣは、発行に際して保証金を拠出してもらっているので、デポジットカードと呼び得る。

尚、上記各実施形態では、給与プリペイドカードＣの使用の際に本人認証（パスワード）は不要としたが、必要に応じてパスワード認証をする場合もあり得る。ユーザーが単に口頭で店舗にプリペイドＩＤを伝える場合もあり得るが、この場合には、通常、パスワード認証がされる。また、カードによる場合にも、セキュリティを考慮してパスワード認証をする場合もある。スマートフォン等のモバイル端末は、機器を立ち上げる際に機器の機能としてパスワード認証をしている場合が多いので、通常は不要とされる。いずれにしても、パスワード認証をする場合、パスワードを記録した認証用のファイルが記憶部５に記憶され、使用承認サーバ２は、このファイルにアクセスすることで使用の承認を行う。
使用の際に本人認証が要求される場合、給与プリペイドカードＣは、本人確認の上で提供される。即ち、本人限定型の書留郵便等の方法により本人確認の上で提供される。

また、上記各実施形態では、店舗側コンピュータは店舗端末９であったが、他の場合もあり得る。例えば、インターネットショッピングにおいてプリペイド金が使用される場合、ショッピングサイトを提供するサーバが承認要請を送信する場合があり、この場合には、そのサーバが店舗側コンピュータということになる。また、ユーザー（従業員）が端末を操作して承認要請をし、使用が承認された結果をショッピングサイトのサーバに送信する場合もあり得る。この場合には、ユーザーが操作する端末が店舗側コンピュータということになる。さらに、決済代行業者が決済をする場合もあり、決済代行業者が運営するサーバが店舗側コンピュータの場合もあり、決済代行業者内の担当者が操作する端末が店舗側コンピュータの場合もある。

１ プリペイド発行サーバ
１１ カード発行プログラム
２ 使用承認サーバ
２１ 使用承認プログラム
２２ 決済プログラム
３ 集計サーバ
３１ 集計プログラム
４ 管理サーバ
５ 記憶部
５４ プリペイド設定情報ファイル
６ プリペイド口座
６１ 企業アカウント
６２ 共有アカウント
６３ 個別アカウント
６４ 店舗アカウント
７ 額増加サーバ
７１ 額増加プログラム
８１ 企業内担当者端末
９ 店舗端末
Ｃ 給与プリペイドカード（ＩＤ担持物）

Claims (3)

1. 雇用主企業が従業員に対して給与を前払いする際に利用される給与プリペイドシステムであって、
   プリペイド金の使用を承認する使用承認サーバと、プリペイド金の使用額を集計する集計サーバと、記憶部とを備えており、
   記憶部には、従業員の就労状況に応じて設定されていて労働債権の範囲内であって借金ではないプリペイド設定額を記録したプリペイド設定情報ファイルと、プリペイド金の使用実績を記録した使用実績情報ファイルとが記憶されており、
   使用実績情報ファイルは、プリペイド金を使用する権利を有する従業員を特定するプリペイドＩＤと、集計期間内でのプリペイド金の使用額とを記録したファイルであり、
   使用承認サーバは、ネットワークを介して店舗側コンピュータからのアクセスを受け付けるサーバであって、店舗側コンピュータからプリペイドＩＤと使用要請額とがネットワークを介して送信した際、当該プリペイドＩＤについてのそれまでのプリペイド金の使用合計額と送信された使用要請額とを加算した額がプリペイド設定額以下である場合に当該店舗側コンピュータに使用承認情報を送信し、使用要請額を当該プリペイドＩＤについて使用実績情報ファイルに記録するサーバであり、
   集計サーバは、集計期間内のプリペイド金の使用合計額を使用実績情報ファイルから取得するサーバであって、使用合計額を給与支払日に支払われる給与から差し引くために集計用ファイルに記録するサーバであり、
   記憶部には、
   プリペイド金の使用のための資金を預けたプリペイド口座の情報を記録したプリペイド口座情報ファイルが記憶されており、
   プリペイド口座情報ファイルには、プリペイド金の使用のために雇用主企業が預けた預託金である企業所有預金の情報と、各プリペイドＩＤについて給与が前払いされることで従業員が個別に所有することになった預金である個別所有預金の情報と、各店舗が所有する預金である店舗所有預金の情報が記録されており、
   使用承認サーバで承認されたプリペイド金の使用について当該承認されたプリペイドＩＤに係る個別所有預金から使用要請額を当該店舗に係る店舗所有預金に移す決済サーバが設けられており、決済サーバは、使用承認サーバでプリペイド金の使用が承認された際、当該承認されたプリペイドＩＤに係る個別所有預金に対して企業所有預金から個別所有預金に当該使用要請額を移動させ、その後、当該使用要請額を店舗所有預金に移すサーバであることを特徴とする給与プリペイドシステム。
2. 前記プリペイド金は、通貨建て資産、仮想通貨、暗号資産、ポイントカードにおけるポイント、トークン又は電子マネーであることを特徴とする請求項１記載の給与プリペイドシステム。
3. 前記プリペイドＩＤは、ＩＤ担持物に担持された状態で店舗に提示される情報であり、
   ＩＤ担持物は、カード、モバイル端末又は認証可能な生体特徴部分であることを特徴とする請求項１又は２記載の給与プリペイドシステム。

Images