特許 6362740 決済管理サーバ，プログラム，及び決済方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6362740

(24)【登録日】2018年7月6日

(45)【発行日】2018年7月25日

(54)【発明の名称】決済管理サーバ，プログラム，及び決済方法

(51)【国際特許分類】

   G06Q 20/14 20120101AFI20180712BHJP

   G06Q 20/24 20120101ALI20180712BHJP

【ＦＩ】

   G06Q20/14

   G06Q20/24

【請求項の数】8

【全頁数】18

(21)【出願番号】特願2017-136663(P2017-136663)

(22)【出願日】2017年7月12日

【審査請求日】2017年7月20日

【早期審査対象出願】

(73)【特許権者】

【識別番号】516134567

【氏名又は名称】株式会社Ｗａｒｒａｎｔｅｅ

(74)【代理人】

【識別番号】100116850

【弁理士】

【氏名又は名称】廣瀬 隆行

(74)【代理人】

【識別番号】100165847

【弁理士】

【氏名又は名称】関 大祐

(72)【発明者】

【氏名】庄野 裕介

【審査官】 緑川 隆

(56)【参考文献】

【文献】 特開２００８−００９６６７（ＪＰ，Ａ）

【文献】 特開２００２−３３４２１７（ＪＰ，Ａ）

【文献】 特許第６１０８５８１（ＪＰ，Ｂ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

(57)【特許請求の範囲】

【請求項1】

単位期間ごとに課金される商品をユーザに提供する場合において，ネットワークを通じて課金額の支払いをカード会社サーバに請求する管理サーバであって，
前記ユーザから前記商品の選択情報を受け付ける通信部と，
前記ユーザに選択された前記商品について，前記カード会社サーバに対し，課金対象となる単位期間１回分を超える所定期間分の金額の与信照会を行う与信照会部と，
前記所定期間分の金額の与信枠が確保された後，前記ユーザから得た商品の必要期間及び不要期間の両方又は少なくともいずれか一方に関する要否情報に基づいて，前記ユーザが前記商品の提供を受けることができるようになった時から所定の締め日又は商品がキャンセルされた時までの前記商品の提供可能期間において前記ユーザが課金要求を行った課金期間と前記ユーザが課金要求を行っていない非課金期間とを区別することにより，前記課金期間を求める課金期間計算部と，
前記課金期間に応じた金額の支払いを前記カード会社サーバに一括して請求する支払請求部と，を備える
管理サーバ。

【請求項2】

前記商品は，保険商品であり，
前記商品の提供可能期間は，保険商品の購入確定日から所定の締め日又は契約がキャンセルされた時までの期間である
請求項１に記載の管理サーバ。

【請求項3】

前記要否情報は，前記ユーザ自身又は前記ユーザが所有する物品の位置又は移動に関する情報を含む
請求項１に記載の管理サーバ。

【請求項4】

前記ユーザが保持するユーザ端末の位置情報に基づいて，前記商品の必要期間及び不要期間の両方又は少なくともいずれか一方を判断する要否判断部をさらに備える
請求項１から請求項３のいずれかに記載の管理サーバ。

【請求項5】

前記要否判断部は，前記ユーザ端末の位置情報に加えて，通信機能を持つ物品又は物品に取り付けられた電子タグと前記ユーザ端末が通信しているか否かを示す通信情報に基づいて，前記商品の必要期間及び不要期間の両方又は少なくともいずれか一方を判断する
請求項４に記載の管理サーバ。

【請求項6】

前記課金期間計算部は，前記商品の提供可能期間を当初の課金期間と推定し，当該当初の課金期間から前記ユーザが課金を要求していない非課金期間を差し引くことによって，実際の課金期間を求める
請求項１に記載の管理サーバ。

【請求項7】

コンピュータを請求項１に記載の管理サーバとして機能させるプログラム。

【請求項8】

単位期間ごとに課金される商品をユーザに提供する場合において，管理サーバがネットワークを通じて課金額の支払いをカード会社サーバに請求する決済方法であって，
前記管理サーバが前記ユーザから前記商品の選択情報を受け付ける工程と，
前記ユーザに選択された前記商品について，前記管理サーバから前記カード会社サーバに対し，課金対象となる単位期間１回分を超える所定期間分の金額の与信照会を行う工程と，
前記所定期間分の金額の与信枠が確保された後，前記管理サーバが，前記ユーザから得た商品の必要期間及び不要期間の両方又は少なくともいずれか一方に関する要否情報に基づいて，前記ユーザが前記商品の提供を受けることができるようになった時から所定の締め日又は商品がキャンセルされた時までの前記商品の提供可能期間において前記ユーザが課金要求を行った課金期間と前記ユーザが課金要求を行っていない非課金期間とを区別することにより，前記課金期間を求める工程と，
前記課金期間に応じた金額の支払いを前記管理サーバが前記カード会社サーバに一括して請求する工程と，を含む
決済方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は，カード会社サーバに対して商品に対する対価の支払いを請求する管理サーバ，それを機能させるためのコンピュータプログラム，さらには管理サーバが実行する決済方法に関する。

【背景技術】

【0002】

近年，消費者ニーズの多様化やインターネットの普及に伴い，商品（サービスを含む）に対する対価の課金が様々な方法で行われている。特に自動車保険や動産保険などの保険商品においては，１日単位型あるいは１時間単位型なども登場しており，必要な時期に必要な期間だけ保険の契約を行うことも可能となっている。

【0003】

また，インターネットを通じて商品が提供される場合，商品に対する対価はクレジットカードやデビットカードなどのカードによって支払われることが多い。カード決済の場合，まず商品を扱う商店（カードの加盟店）からカード会社に対してユーザのカード情報や請求額が送信され，カード会社においてカードの有効性を確認した上で，請求額が限度額内であるかどうかが判定される。カード会社により与信枠が確保された場合には，その場でユーザに対する費用の請求が確定し，その請求確定日と請求額がカードの利用明細書に掲載される。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１３−０１５８８１号

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで，１日単位型や１時間単位型のような小期間型の商品の場合，一般的に，ユーザが期間を指定して商品購入の申込みを行うと，まず商店が指定された期間分の金額についてカード会社に対し与信照会を行う。また，与信枠が確保できると，その場で瞬時にユーザに対する請求が確定し，その後商品が商店からユーザに提供されることとなる。このように，一般的な決済処理では，１日単位や１時間単位分の費用ごとに，カード会社からユーザに対する請求が前払式で確定することとなる。

【0006】

しかしながら，上記のように各単位分の金額の請求が前払式で確定することとなると，ユーザが小期間型の商品を複数回に分けて申し込んだような場合に，カード会社からユーザに通知される利用明細書には，請求項目が複数に分けて掲載されることとなる。特にユーザが細かい単位ごとに頻繁に商品を利用する場合，利用明細書には少額の請求額が多数掲載され，場合によってはそのような請求項目が何ページにも亘って掲載されることとなり，ユーザにとって利便性に欠けるという問題があった。

【0007】

他方で，上記のような問題を解消するために，商店がユーザに対して小期間型の商品を提供するにあたり，一定期間ユーザの利用履歴を記録しておき，所定の締め日（例えば月末）を迎えたときに，それまでにユーザが商品を利用した分をまとめてカード会社に請求するという後払い式の決済方法も考えられる。しかしながら，そのような場合には，請求額がカードの限度額が超えているにも関わらず商店がユーザに商品を提供するしてしまったり，あるいは所定の締め日にカード会社に与信照会を行ったときに与信枠を確保できずカード会社に対する請求が拒絶される場合がある。このように後払い式の決済方法では，商店が金銭的なリスクを負うこととなり，事業の安定性が損なわれるという問題があった。

【0008】

そこで，本発明は，カード加盟店及びカード利用者の双方にとって利用しやすい小期間型商品のカード決済方法を提供することを目的とする。

【課題を解決するための手段】

【0009】

本発明の発明者は，上記の目的を達成する手段について鋭意検討した結果，カード利用者（ユーザ）から小期間型の商品の購入申込みがあったときには，その時点でカード加盟店が申込み期間を超えた所定期間分の金額の与信照会をカード会社に対して行えるようにし，ある程度多めに与信枠を確保できるようにした。その上で，所定期間の中で実際にユーザが課金要求を行った期間分の金額を，確保済みの与信枠の範囲でカード加盟店がカード会社に一括して請求できるようにした。そして，本発明者は，このような知見に基づけば従来技術の課題を解決できることに想到し，本発明を完成させた。具体的に説明すると，本発明は以下の構成・工程を有する。

【0010】

本発明の第１の側面は，管理サーバに関する。商店が単位期間ごとに課金される商品をユーザに提供する場合において，管理サーバは，ネットワークを通じて課金額の支払いをカード会社サーバに請求する機能を持つ。本願明細書における「商品」とは，経済活動において生産・流通・交換される物財を広く包含し，売買の対象となる動産や不動産の他に，保険や賃貸，コンシェルジュ，仕事紹介などの様々なサービスや，あるいは情報そのものが含まれる。また，「カード会社サーバ」とは，カード会社が運用するサーバあるいはシステムであり，カードの種類はクレジットカードやデビットカードなどであるが，与信照会が求められるカードであればその種類は特に限定されない。なお，管理サーバやカード会社サーバは，一台のコンピュータで実現されるものに限られず，ネットワーク接続された複数台のコンピュータによって実現される分散型のサーバであってもよい。

【0011】

管理サーバは，通信部，与信照会部，課金期間計算部，及び支払い請求部を備える。通信部は，ユーザから商品の選択情報を受け付ける。与信照会部は，ユーザに選択された商品について，カード会社サーバに対し，課金対象となる単位期間１回分を超える所定期間分の金額の与信照会を行う。例えば商品が１日単位で課金されるものである場合，与信照会部は１ヶ月分の金額について与信照会を行うことができる。課金期間計算部は，所定期間分の金額の与信枠が確保された後，商品の提供可能期間の間にユーザが課金要求を行った課金期間を求める。その後，支払請求部は，課金期間に応じた金額の支払いをカード会社サーバに一括して請求する。なお，ここにいう「単位期間」とは，商品に対して対価が発生する最小期間であり，「所定期間」とは，単位期間の複数倍の期間であって，与信枠を確保する金額の算定基準となる期間である。また，「課金期間」は，商品の提供可能期間（つまり所定期間）の間にユーザが課金要求をした期間である。

【0012】

通常のカード決済の場合，カード加盟店から与信照会が行われ，カード会社にて与信枠が確保されると，その後すぐに与信枠と同額の金額がカード加盟店からカード会社に請求されて，カード会社からユーザに対する請求も同時に確定する。このように，通常は，与信照会と請求確定はほとんど間を空けることなく実行される。しかしながら，１日単位型や１時間単位型のような小期間型の商品の場合に，このような通常の決済処理を行うと，利用明細書に少額の請求項目が多数並ぶこととなりユーザにとって不便である。そこで，上記本発明のように，与信枠が確保されてから，カード加盟店がカード会社に金額を請求するまでの間を空けるようにすることで，ユーザによる商品購入の複数回分の費用をカード加盟店がカード会社に対して一括して請求できるようになる。これにより，利用明細書にも一括してまとめられた請求項目が掲載されるようになり，ユーザの利便性が向上する。また，カード加盟店も予め確保した与信枠の範囲内でユーザに商品を提供することで，商品に対する対価を取り損ねる事態を回避できる。

【0013】

本発明に係る管理サーバは，さらに要否情報記録部を有することが好ましい。要否情報記録部は，商品の提供可能期間の間，ユーザから得た商品の必要期間及び不要期間の両方又は少なくともいずれか一方に関する要否情報を記憶部に記録する。この場合，課金期間計算部は，記憶部に記録されている要否情報に基づいて課金期間を求める。商品の要否情報を取得する方法は，特に限定されない。例えば，商品の要否情報としては，ユーザが直接的に管理サーバに対して必要期間及び不要期間を通知することの他に，ユーザの位置情報や移動情報に基づいて必要期間及び不要期間を管理サーバにおいて判断することとしてもよい。また，ユーザが装着しているウェアラブルデバイスからユーザの生体情報（心拍，心音，体温，血圧等）を取得し，これに基づいて必要期間及び不要期間を管理サーバにおいて判断することとしてもよい。その他，要否情報としては，様々なＩｏＴデバイス（例えば家具，家電，電子機器，自動車，自転車，ペット，日用品，衣服，鞄などに取り付けられた通信機能を持つセンサ）から取得したセンシング情報に基づいて，必要期間及び不要期間を判断することもできる。

【0014】

本発明に係る管理サーバにおいて，要否情報は，ユーザ自身又はユーザが所有する物品の位置又は移動に関する情報を含むことが好ましい。これにより，例えばユーザが外出したときや，あるいは所定の場所に居るときにのみ，ユーザ自身やユーザの所有物に自動的に保険を掛けることが可能となる。また，例えばユーザの所在や移動状況に応じて，シェアリングサービスやコンシェルジュサービスを提供することもできる。

【0015】

本発明に係る管理サーバにおいて，要否判断部は，通信機能を持つ物品又は物品に取り付けられた電子タグがユーザ端末と通信しているか否かを示す通信情報に基づいて，商品の必要期間及び不要期間の両方又は少なくともいずれか一方を判断することとしてもよい。これにより，例えばユーザの所持品（カメラ等）に物損事故保険を掛けるような場合に，その所持品自体がインターネット接続機能を有していなくても，Bluetooth（登録商標）等によってユーザ端末と直接通信可能であったり，あるいはその所持品に電子タグを取り付けてユーザ端末と通信可能にすることにより，ユーザがその所持品及びユーザ端末を持って外出したときに限り，保険商品を提供することが可能となる。また，上記した管理サーバの決済機能により，ユーザの外出時に限り保険商品等の課金を行うなど，ユーザの行動に合致した適切な費用で保険商品等を提供することができる。

【0016】

本発明に係る管理サーバにおいて，課金期間計算部は，商品の提供可能期間の始期から終期までの間を当初の課金期間と推定し，当該当初の課金期間からユーザが課金要求していない非課金期間を差し引くことによって，実際の課金期間を求めることとしてもよい。このように，ユーザにとって商品の提供が不要な期間を当初の課金期間から控除することで，ユーザの納得を得やすい課金方法を提供できる。また，課金期間を加算する態様に比べ，当初の課金期間から非課金期間を控除する態様の方が，管理サーバにおける処理の負荷を軽減することができる。

【0017】

本発明の第２の側面は，コンピュータを上記した第１の側面に係る管理サーバとして機能させるプログラムに関する。なお，プログラムは，ＣＤ−ＲＯＭ等の情報記憶媒体に記憶されていてもよい。

【0018】

本発明の第３の側面は，決済方法に関する。本発明に係る決済方法は，単位期間ごとに課金される商品をユーザに提供する場合において，管理サーバがネットワークを通じて課金額の支払いをカード会社サーバに請求する方法である。まず，管理サーバがユーザから商品の選択情報を受け付ける。次に，ユーザに選択された商品について，管理サーバからカード会社サーバに対し，課金対象となる単位期間１回分を超える所定期間分の金額の与信照会を行う（与信照会工程）。次に，所定期間分の金額の与信枠が確保された後，管理サーバにおいて商品の提供可能期間の間にユーザが課金要求を行った課金期間を求める（課金期間計算工程）。その後，課金期間に応じた金額の支払いを管理サーバがカード会社サーバに一括して請求する（決済工程）。

【発明の効果】

【0019】

本発明によれば，カード加盟店及びカード利用者の双方にとって利用しやすい小期間型商品のカード決済方法を提供することができる。

【図面の簡単な説明】

【0020】

【図1】図１は，決済システム全体の構成例を示した模式図である。

【図2】図２は，１日単位型と１時間単位型の商品に対する対価の請求方式の一例を示している。

【図3】図３は，決済システムに含まれる各種装置の機能構成例を示したブロック図である。

【図4】図４は，決済方法のメインフローを示している。

【図5】図５は，与信照会工程の具体的なフローを示している。

【図6】図６は，課金期間計算工程の第１の実施形態を示したフローチャートである。

【図7】図７は，課金期間と非課金期間を判断する基準の一例を示している。

【図8】図８は，課金期間計算工程の第２の実施形態を示したフローチャートである。

【図9】図９は，課金期間計算工程の第３の実施形態を示したフローチャートである。

【図10】図１０は，決済工程の具体的なフローを示している。

【図11】図１１は，継続処理工程の具体的なフローを示している。

【発明を実施するための形態】

【0021】

以下，図面を用いて本発明を実施するための形態について説明する。本発明は，以下に説明する形態に限定されるものではなく，以下の形態から当業者が自明な範囲で適宜変更したものも含む。

【0022】

図１は，決済システム全体の構成の一例を示している。図１に示されるように，決済システムは，管理サーバ１００，ユーザ端末２００，及びカード会社サーバ３００を含み，各サーバ及び端末はインターネットを介して情報の授受が可能なように互いに接続されている。管理１００サーバは，商品をユーザに提供する商店によって運営されるウェブサーバである。商店は，カード加盟店であり，カード（クレジットカードやデビットカード）を利用して商品に対する対価の決済ができるようにカード会社と提携している。ユーザ端末２００は，商品の提供を受けるユーザによって所持された端末装置である。ユーザは，ユーザ端末２００を利用して商品の購入を商店に申し込むことができ，またその商品の対価をカードを利用して支払うことができる。カード会社サーバ３００は，カード会社が運営するサーバまたはシステムである。カード会社は多数存在しているが，本発明では，どのカード会社が運営するカード会社サーバ３００であっても特に制限なく利用することができる。

【0023】

本発明のシステムは，商店がユーザに対して単位期間ごとに課金される商品を提供することを想定している。「商品」の種類は特に制限されず，売買の対象となる動産や不動産の他に，様々なサービスや，あるいは情報そのものが広く含まれる。「商品」の例は，保険商品，レンタカー，カーシェアリング，タクシーによる輸送，オンラインゲームの会員権，スポーツジムの会員権，コンシェルジュサービス，空きスペースのレンタル，音楽や映画のストリーミング配信，インターネットオークション，飲食物の提供，マッサージ，電気通信サービスなど様々なものが考えられ，またここに挙げたものに限定されない。

【0024】

本願明細書では，本発明で取り扱われる商品の一例として，保険商品を例に挙げて本発明の内容を具体的に説明する。特に，保険商品の例として，ユーザの所有物を被保険物品とした物損事故保険を例に挙げる。図１に示した図では，ユーザが所有しているカメラが被保険物品１０となる。また，この被保険物品１０は，ユーザ端末２００との通信機能を有していないため，この被保険物品１０には電子タグ２０が取り付けられている。ユーザ端末２００は，この電子タグ２０から発せられた無線信号を受信することができる。なお，被保険物品１０自体がユーザ端末２００との通信機能を有している場合，この電子タグ２０を省略することも可能である。

【0025】

本発明の決済システムは，短期間ごとに課金される商品の決済に適している。このような商品の例を図２に示す。図２に示されるように，保険商品Ａは１日単位で課金されるタイプの商品であり，保険商品Ｂは１時間単位で課金される商品である。つまり，保険商品Ａは１日分の保険料が定められおり，保険商品Ｂは１時間分の保険料が定められている。なお，課金の単位は，１日や１時間に限定されず，その他に３時間，６時間，１２時間，２日，３日，１週間，１ヶ月など任意に設定することができる。ただし，本発明は，３日以下の短い期間ごとに課金を行う商品に適しているといえる。

【0026】

図２を参照して，本発明による決済方法の概要を説明する。例えば１日単位型の保険商品Ａを例に挙げる。従来のカード決済の場合，ユーザが３月１日に１日分の保険加入を商店に申し込むと，商店が保険商品Ａの１日分の金額をカード会社に対して与信照会を行い，与信枠が確保されればその場でその金額の請求が確定していた。また，ユーザが３月３日に１日分の保険加入を商店に申し入れた場合も同様に，１日分の金額の与信照会が行われてその場で請求金額が確定する。この場合，ユーザのカード明細書には，３月１日分の金額と３月３日分の金額とが別々に掲載されることとなる。また，１時間単位型の保険商品Ｂについても同様であり，ユーザは６時間分や１７時間分といったようにまとまった期間分の保険加入を申し込むことができるものの，従来のカード決済の場合には，ユーザのカード明細書には６時間分の請求金額と１７時間分の請求金額が別々に掲載されることとなる。この点について，カード明細書の記載が煩雑になることや，少ない金額が細々と請求されることを嫌がるユーザも多く，所定の締め日にそれまでに課金した商品の金額をまとめて請求して欲しいという潜在的なニーズが存在していた。そこで，本発明は，図２に示されるように，保険商品の最初の申込日（購入確定日）から所定の締め日又は契約がキャンセルされるされるまでの間に，ユーザが１日単位や１時間単位で自由に保険に加入することができるようにし，さらに所定の締め日又はキャンセル日の後に，それまでに課金された金額をユーザに一括して請求するようにした。つまり，保険商品Ａの請求金額（α円）は，「保険商品Ａの保険料×Ｎ日」で求められ，同様に保険商品Ｂの請求金額（β円）は，「保険商品Ｂの保険料×Ｎ時間」で求められる。商店は，α円やβ円といったまとまった金額の支払いをユーザに請求することが可能となる。また，α円＋β円の支払いを求めることも可能である。このように決済すればユーザ（カード利用者）及び商店（カード加盟店）の両方にメリットがあるといえる。このような決済方法を実現するための構成について，以下具体的に説明する。

【0027】

図３は，決済システムを構成する各装置の機能構成を示したブロック図である。図３に示されるように，管理サーバ１００は，ユーザ端末２００及びカード会社サーバ３００とインターネットを介して接続されている。また，ユーザ端末２００は，電子タグ２０が発する無線信号を受信することが可能である。なお，図３において，管理サーバ１００は，各種機能ブロックが１つのウェブサーバに集約されたように示されているが，複数のウェブサーバに機能ブロックを分散させた分散型のものであってもよい。また，ユーザ端末２００及び電子タグ２０は，通常それぞれ複数台ずつ存在している。また，管理サーバ１００と連携するカード会社サーバ３００は１種類に限られず，管理サーバ１００は複数種類のカード会社サーバ３００と連携することも可能である。

【0028】

管理サーバ１００は，ユーザに提供する商品に関する情報を管理する。また，管理サーバ１００は，ユーザが商品の対価をカード決済することを選択したときに，カード会社サーバ３００との間で決済処理を行う。

【0029】

管理サーバ１００は，処理部１１０，記憶部１２０，及びネットワーク通信部１３０を備える。処理部１１０としては，ＣＰＵ又はＧＰＵといったプロセッサを利用することができる。処理部１１０は，記憶部１２０に記憶されているサーバ用のプログラムを読み出し，このプログラムに従って他の要素を制御することにより，本システム全体の運用処理を実行する。記憶部１２０は，システムの運用に必要な各種情報を記憶するデータベースとして機能する。記憶部１２０のストレージ機能は，例えばＨＤＤ及びＳＤＤといった不揮発性メモリによって実現できる。また，記憶部１２０は，処理部１１０による演算処理の途中経過などを書き込む又は読み出すためのメモリとしての機能を有してもよい。記憶部１２０のメモリ機能は，ＲＡＭやＤＲＡＭといった揮発性メモリにより実現できる。ネットワーク通信部１３０は，インターネットなどの通信回線を通じてユーザ端末２００及びカード会社サーバ３００と通信する機能を持つ。通信規格は公知の標準化された規格に則ればよく，特に制限はない。

【0030】

ユーザ端末２００は，ユーザによって操作されるものであり，商品の選択や，購入，キャンセルなどの指示を管理サーバ１００に伝達する。ユーザ端末２００の例は，スマートフォン，ラップトップコンピュータ，タブレット端末などの携帯情報端末や，デスクトップコンピュータなどの据置型の情報端末である。ユーザ端末２００は，制御部２１０，記憶部２２０，ネットワーク通信部２３０，操作部２４０，表示部２５０，位置情報取得部２６０，及び近距離無線通信部２７０を有する。制御部２５０は，ＣＰＵ又はＧＰＵといったプロセッサにより実現できる。記憶部２２０は，ＨＤＤ又はＳＤＤといった不揮発性メモリや，ＲＡＭ又はＤＲＡＭといった揮発性メモリにより実現できる。ネットワーク通信部２３０は，インターネットなどの通信回線を通じて管理サーバ１００と通信する機能を持つ。操作部２４０は，マウス，キーボード，タッチパネル，マイクなどの入力装置により構成され，人による操作情報を受け付ける。表示部２５０は，液晶ディスプレイや有機ＥＬディスプレイのような表示装置である。表示部２５０は，操作部２４０一体となってタッチパネルディスプレイを構成していてもよい。位置情報取得部２６０の例は，ＧＰＳ（Global Positioning System）を利用した測位を行う機能を持つＧＰＳ測位部である。近距離無線通信部２７０は，例えばBluetooth（登録商標）などの公知の規格に従って，電子タグ２０から無線信号を受信する。

【0031】

ユーザ端末２００の記憶部２２０には，本システム専用のアプリケーションプログラムや汎用的なウェブブラウザプログラムが記憶されている。ユーザ端末２００は，これらのプログラムが起動されると，専用アプリケーションやウェブブラウザを介して管理サーバ１００にアクセスすることが可能となり，管理サーバ１００から情報の提供を受けたり，管理サーバ１００に向けて情報を送信したりすることができる。管理サーバ１００から受け取った情報はユーザ端末２００の表示部２５０に表示される。また，ユーザが操作部２４０を介して必要な情報を入力すると，その情報はネットワーク通信部２３０を介して管理サーバ１００に送信される。このようにして，管理サーバ１００をユーザ端末２００の間で情報の授受が行われる。

【0032】

カード会社サーバ３００は，管理サーバ１００から与信照会の要求があったときにユーザ（カード会員）のカード決済の限度額を確認して与信枠を確保する処理を行ったり，必要とされる金額を管理サーバ１００を運営する商店（カード加盟店）に支払うとともに，商店に支払った金額をユーザの銀行口座から引き落としたりする処理を行う。カード会社サーバ３００としては，公知の構成を採用することができる。

【0033】

電子タグ２０は，被保険物品１０がユーザ端末２００と通信できない場合に，その被保険物品１０に取り付けて使用される。電子タグ２０は，例えばBluetooth（登録商標）などの無線信号発信機やＲＦＩＤ（Radio Frequency IDentification）によって実現されるものであり，電磁界や電波等を用いた非接触型の近距離無線通信によって，ユーザ端末２００と交信を行う。本発明において，電子タグ１０の回路は，例えば，パッシブ型，セミパッシブ型，又はこれに準ずる構造を有するものを採用できる。

【0034】

電子タグ２０は，基本的に，発信部２１とＩＣチップ２２とを備える。ＩＣチップ２２は，電子タグ２０又はそれが取り付けられた被保険物品１０固有のＩＤ情報（タグＩＤ）を記憶している。発信部２１は，ＩＣチップ２２に記憶されているタグＩＤを無線信号に載せて発信する。例えば，パッシブ型の電子タグ２０は，ユーザ端末２００から発信された電波を受信し，受信した電波をアンテナのコイルやショットキーダイオードにより起電力に変換し，この起電力によってＩＣチップ２２を起動する。ＩＣチップ２２は，起動すると，そこに保持されている固有のタグＩＤを読み出し，このタグＩＤを発信部２１を介してユーザ端末２００に発信する。パッシブ型の電子タグ２０は，電波を起電力に変換して作動するものであるため，電源（例えば電池）が不要であり，製造が安価であるとともに，ほぼ恒久的に使用可能であるというメリットがある。また，セミパッシブ型の電子タグ２０も使用可能である。セミパッシブ型の電子タグ２０は，ユーザ端末２００から発信された電波を受信し，これを契機として内部の電源を作動させる。そして，電源から得た電力を利用して，ＩＣチップ２１を起動し，ユーザ端末２００に対して固有のタグＩＤを発信する。なお，電子タグ１０とユーザ端末２００の間の近距離無線通信は，Bluetooth（登録商標）などの公知の規格に従って行えばよい。

【0035】

続いて，管理サーバ１００の機能構成についてより詳細に説明する。図３に示されるように，管理サーバ１００の記憶部１２０には，顧客管理テーブル１２１，購買管理テーブル１２２，商品管理テーブル１２３，及び取引管理テーブル１２４が記憶されている。顧客管理テーブル１２１には，ユーザ固有のユーザＩＤに関連付けて，ユーザの名前，自宅の住所，メールアドレス，電話番号，交友関係（友人や親族）等の個人情報が記録される。また，顧客管理テーブル１２１には，被保険物品１０の保管場所（自宅等）の住所を一又は複数箇所記録しておくことができる。購買管理テーブル１２２には，ユーザＩＤに関連付けて，各ユーザが購入した製品に関する情報（製品名，型番，メーカ名，製造年月日等）が記録される。購買管理テーブル１２２に記録されている製品を，物損事故保険の対象とすることができる。商品管理テーブル１２３には，保険商品固有の保険ＩＤに関連付けて，各保険商品に関する情報が記録される。保険商品に関する情報としては，例えば，保険商品の内容や特約，保険料に関する情報を挙げることができる。また，被保険物品の種類や状態によって保険料が変わる場合には，保険料の算定基準に関する情報も商品管理テーブル１２３に記録される。取引管理テーブル１２４には，ユーザ固有のユーザＩＤに関連付けて，各ユーザが現在契約している保険の種類（保険ＩＤ）や，その契約期間又は契約始期と契約終期，予約済みの次の契約期間，あるいは過去の契約履歴に関する情報が記録される。また，ユーザ端末２００が電子タグ２０と連携している場合には，取引管理テーブル１２４には，電子タグ２０のタグＩＤとともに，ユーザ端末２００が電子タグ２０が通信している期間又は通信していない期間に関する情報が逐次記録される。

【0036】

管理サーバ１００の処理部１１０は，上記した記憶部１２０が有する各テーブル１２１〜１２４に情報を登録したり，あるいは各テーブル１２１〜１２５に登録されている情報を参照したり更新したりしながら，ユーザに保険商品を提供する期間を定める処理や，保険商品の対価を決済する処理を行うことができる。具体的に説明すると，管理サーバ１００の処理部１１０は，図３に示されるように，与信照会部１１１，要否判断部１１２，要否情報記録部１１３，課金期間計算部１１４，及び支払請求部１１５を含む。以下では，処理部１１０の各機能構成１１１〜１１５について，図４以降に示したフロー図を参照しながら詳しく説明する。

【0037】

図４は，本発明に係る決済方法を示したメインフローである。本発明の決済方法は，与信照会工程（ステップＳ１），課金期間計算工程（ステップＳ２），決済工程（ステップＳ３），及び継続処理工程（ステップＳ４）を含む。与信照会工程では，ユーザから保険商品に加入することの申込みがあったときに，管理サーバ１００が，カード会社サーバ３００に対し，課金対象となる単位期間１回分を超える所定期間分の金額の与信照会を行う。つまり，管理サーバ１００は，保険商品１回分の金額よりも大きい金額の与信枠を確保するようにカード会社サーバ３００に要求する。課金期間計算工程では，与信枠が確保された後，管理サーバ１００が，商品の提供可能期間の間にユーザが課金要求を行った課金期間を求める。決済工程では，課金期間に応じた金額の支払いを管理サーバ１００がカード会社サーバ３００に一括して請求する。このように，本発明では，カード会社サーバ３００において与信枠が確保された後に一旦決済が保留状態とされ，その保留中にユーザが自由に保険商品に申込み（課金）を行うことができるようになっている。継続処理工程は，決済後に改めて与信枠が確保できた場合には，契約を自動更新する工程である。継続処理工程は任意の工程であり，ユーザが希望しない場合には省略できる。

【0038】

図５は，与信照会工程（ステップＳ１）の詳細なフローを示している。まず，ユーザ端末２００を操作してユーザが購入を希望する保険商品を選択する（ステップＳ１−１）。保険商品の選択では，１日単位型や１時間単位型の保険商品の契約期間を選択したり，保険の内容や特約を選択したり，保険を掛ける被保険物品１０の種類や状態（使用期間，使用頻度，故障の有無等）を入力する。ユーザ端末２００は，ユーザが選択した保険商品に関する情報とともに，被保険物品１０に関する情報を管理サーバ１００に送信する。管理サーバ１００は，ユーザ端末２００から送信された保険商品の選択情報を受信する（ステップＳ１−２）。次に，管理サーバ１００は，商品の選択情報に基づいて，単位期間あたりの商品の購入金額をユーザに提示する（ステップＳ１−３）。例えば１日単位型の保険商品がユーザによって選択された場合に，管理サーバ１００は，１日あたりの金額を提示することとしてもよいし，もしくはユーザが選択した契約期間分の金額（例えば２日分をまとめた金額）を提示してもよい。購入金額は，ユーザ端末２００に表示される。その後，ユーザが購入金額に同意した場合には，その旨がユーザ端末２００に入力され，ユーザ端末２００から管理サーバ１００へと購入要求が送信される（ステップＳ１−４）。管理サーバ１００は，ユーザ端末２００から購入要求を受信する（ステップＳ１−５）。

【0039】

続いて，管理サーバ１００の与信照会部１１１は，カード会社サーバ３００に対して，少なくとも課金対象となる単位期間１回分を超える所定期間分の金額の与信照会を行う（ステップＳ１−６）。例えば，ユーザが１日単位型の保険商品の購入を要求している場合，与信照会を行う金額の算出根拠となる所定期間は２日以上となる。特に所定期間は，３日以上であることが好ましく，１週間分又は１ヶ月分であることが特に好ましい。また，例えば毎月の特定日がカードの請求の締め日であるような場合には，ユーザから購入要求があった日からそのカードの締め日までの期間を，上記の所定期間とすることもできる。また，ユーザが複数の単位期間について一度に購入要求を行った場合，管理サーバ１００の与信照会部１１１は，ユーザが要求している単位期間の合計を超える所定期間分の金額について，カード会社サーバ３００に与信照会を行う。例えば，ある保険商品の１日分（単位期間）の金額が１００円であり，ユーザが５日分の購入を要求している場合，与信照会部１１１は，少なくとも６日以上の所定期間，好ましくは３０日分の金額（３０００円）を求めて，この金額についてカード会社サーバ３００に与信照会を行う。このように，管理サーバ１００の与信照会部１１１は，ユーザが購入要求を行った期間を超える所定期間について与信照会を行い，決済用の与信枠を多めに確保するようにカード会社サーバ３００に要求する。

【0040】

続いて，カード会社サーバ３００は，管理サーバ１００から与信照会の依頼を受信すると，管理サーバ１００が求めている金額について与信枠を確保できるか否かを判断する（ステップＳ１−７）。具体的に説明すると，カード会社サーバ３００は，ユーザが利用しているカードの有効性等を確認したうえで，管理サーバ１００からの請求金額がカード限度額内であるかどうかを確認し，限度額内であれば，その請求金額分の与信枠を確保する。なお，限度額の確認は，これまでに既に確保した与信枠と今回確保する与信枠の合計が限度額内であるかどうかを判定する。このような処理を経て，もし与信枠が確保できないと判断した場合，カード会社サーバ３００は，管理サーバ１００に対してその旨を通知する。その場合，管理サーバ１００は，ユーザ端末２００に対して保険商品の購入が不可能であることを知らせる通知を送信し（ステップＳ１−８），ユーザ端末２００はこの通知を受信する（ステップＳ１−９）。与信枠が確保できない場合には，決算方法は終了する。他方で，カード会社サーバ３００は，与信枠が確保できると判断した場合，管理サーバ１００に対してその旨を通知する。与信枠確保成功の通知を受信した管理サーバ１００は，与信照会を行った所定期間額分の与信枠を予約する（ステップＳ１−１０）。これ以降，カード会社サーバ３００は，管理サーバ１００から支払い請求があるまでの間，該当商品についての決済処理が保留された状態となる。

【0041】

続いて，管理サーバ１００は，ユーザ端末２００に対して，商品の購入が確定したことを通知し（ステップＳ１−１１），ユーザ端末２００はこの通知を受信する（ステップＳ１−１２）。この購入確定通知がユーザ端末２００に通知された時点で，保険商品の契約期間（つまり保険商品の提供可能期間）が開始する。また，管理サーバ１００は，ユーザによる保険商品の購入が確定したことを記憶部１２に記録する（ステップＳ１−１３）。具体的には，管理サーバ１００の処理部１１０は，記憶部１２０の取引管理テーブル１２４に，契約を開始したユーザのユーザＩＤとともに，各ユーザが現在契約している保険の種類（保険ＩＤ）や，その契約期間又は契約始期と契約終期を記録する。

【0042】

図６，図８，及び図９は，課金期間計算工程（ステップＳ２）の詳細なフローをそれぞれ示している。図６，図８，及び図９は，課金期間計算工程の別々の実施形態を示している。課金期間計算工程としては，図６，図８，及び図９のいずれの実施形態を採用することも可能である。

【0043】

図６は，課金期間計算工程の第１の実施形態を示している。第１の実施形態において，管理サーバ１００は，被保険物品１０に取り付けられた電子タグ２０とユーザ端末２００との通信状態に関する情報と，ユーザ端末２００の位置情報とに基づいて，被保険物品１０に対して保険を掛けることが不要な期間（非課金期間）を特定し，この非課金期間を当初の課金期間から控除することにより，実際の課金期間を求める処理を行う。すなわち，本実施形態において，管理サーバ１００は，ユーザ端末２００が購入確定通知を受信したとき（ステップＳ１−１２）から，保険の契約がキャンセルされるか又は契約の締め日を迎えるとき（ステップＳ２−１０）までの期間を，当初の課金期間として特定する。特に何もなければこの当初の課金期間分の金額がユーザに請求されることとなる。他方で，当初の課金期間の間に，ユーザにとって保険が不要であると推測される状態が発生した場合には，その状態が発生している期間（非課金期間）を特定して，当初の課金期間から非課金期間を控除する。

【0044】

まず，ユーザ端末２００は，電子タグ２０から発せられている無線信号を受信し，電子タグ２０のタグＩＤを記憶部２２０に登録する（ステップＳ２−１）。その後，ユーザ端末２００は，電子タグ２０に関する情報（タグＩＤ等）を管理サーバ１００に送信し（ステップＳ２−２），管理サーバ１００は，これを受信する（ステップ２−３）。管理サーバ１００は，ユーザ端末２００から得たタグＩＤ等の情報を記憶部１２０に記録する（ステップＳ２−４）。具体的には，管理サーバ１００の処理部１１０は，記憶部１２０の取引管理テーブル１２４に電子タグ２０のタグＩＤを記録しておく。これにより，管理サーバ１００は，被保険物品１０に取り付けられている電子タグ２０を特定することが可能となる。

【0045】

続いて，ユーザ端末２００は，位置情報取得部２６０によって自己端末の現在位置を取得するとともに，近距離無線通信部２７０を通じて電子タグ２０との通信状態を確認する。通信状態とは，ユーザ端末２００が近距離無線通信部２７０を通じて電子タグ２０が発する無線信号を受信できているか，または受信できていないかのオン／オフ情報である。そして，ユーザ端末２００は，自己端末の位置情報とともに，電子タグ２０との通信状況に関する情報（オン／オフ情報）を，管理サーバ１００へと送信する。

【0046】

続いて，管理サーバ１００の要否判断部１１２は，ユーザ端末２００から受信した各種情報に基づいて，ユーザ端末２００と電子タグ２０が通信した状態にあり，かつ，ユーザ端末２００が移動した状態にあるかどうかを判断する（ステップＳ２−６）。ユーザ端末２００が移動した状態とは，例えばユーザの自宅など，ユーザが予め指定した被保険物品１０の保管場所から移動した状態を意味する。被保険物品１０の保管場所の住所は顧客管理テーブル１２１に記録されているため，要否判断部１１２は，顧客管理テーブル１２１に記録されている住所とユーザ端末２００の現在位置とを比較して，ユーザ端末２００の現在位置が被保険物品１０の保管場所と合致しているか否かを判断すればよい。このように，要否判断部１１２は，ユーザ端末２００の位置情報と，ユーザ端末２００が電子タグ２０と通信しているか否かを示す通信情報に基づいて，ユーザが保険商品を不要としている期間（非課金期間）を特定する。

【0047】

具体的に説明すると，図７に，ユーザが保険商品の利用を必要としている期間（必要期間）と不要としている期間（不要期間）の概念を示している。例えば，図７に示されるように，ユーザが保険商品の契約を開始した始期から終期までの期間が，保険商品の提供可能期間となる。なお，この商品の提供可能期間と，管理サーバ１００が与信枠を確保する金額の算定根拠となる所定期間は一致していることが好ましい。ここで，図７（ａ）に示されるように，商品の提供可能期間の間，ユーザ端末２００がユーザの自宅等に在り，かつ，ユーザ端末２００が被保険物品１０に取り付けられた電子タグ２０と通信している状態に在る場合，ユーザは自宅から外出せず，また被保険物品１０も保管場所から持ち出されていないと推測できる。そこで，このような場合には，管理サーバ１００の要否判断部１１２は，被保険物品１０に保険を掛ける必要はないと判断し，この状態に在る期間を保険商品の不要期間として特定する。他方で，図７（ｂ）に示されるように，商品の提供可能期間の間，ユーザ端末２００がユーザの自宅等から離れて外部に移動しており，かつ，ユーザ端末２００が被保険物品１０に取り付けられた電子タグ２０と通信している状態に在る場合，ユーザは自宅等から外出し，しかも被保険物品１０を持ち出していると推測できる。そこで，このような場合には，管理サーバ１００の要否判断部１１２は，被保険物品１０に保険を掛ける必要があると判断し，この状態に在る期間を保険商品の必要期間として特定する。さらに，図７（ｃ）に示されるように，商品の提供可能期間の間，ユーザ端末２００がユーザの自宅等から離れて外部に移動している場合であっても，ユーザ端末２００が被保険物品１０に取り付けられた電子タグ２０と通信していない状態に在る場合，ユーザは自宅等から外出しているものの，被保険物品１０は自宅等に置かれたままとなっており外部に持ち出していない可能性が高い。そこで，このような場合には，管理サーバ１００の要否判断部１１２は，被保険物品１０に保険を掛ける必要はないと判断し，この状態に在る期間を保険商品の不要期間と特定する。このように，ユーザ端末２００の位置情報と，ユーザ端末２００及び電子タグ２０間の通信状況に基づいて，保険商品の必要期間と不要期間を判断できる。そして，保険商品の必要期間を対価を課金する課金期間とし，保険商品の不要期間を対価を課金しない非課金期間とする。

【0048】

続いて，管理サーバ１００の要否情報記録部１１３は，ユーザ端末２００の移動及び電子タグ２０との通信状態が検知されていないと判断した場合に，その状態に在る期間（非課金期間）をカウントする（ステップＳ２−７）。つまり，要否情報記録部１１３は，保険商品の不要期間（非課金期間）が継続した時間を計測する。そして，要否情報記録部１１３は，非課金期間に関する情報を記憶部１２０の取引管理テーブル１２４に記録する（ステップＳ２−８）。例えば，要否情報記録部１１３は，非課金期間が開始した日時と非課金期間が終了した日時を取引管理テーブル１２４に記録すればよい。あるいは，非課金期間が開始した日時と非課金期間が継続した時間を記録してもよい。

【0049】

ここで説明した非課金期間を特定する処理（ステップＳ２−５〜Ｓ２−８）は，保険の契約がキャンセルされるか，もしくは契約の締め日を迎える（ステップＳ２−１０）まで繰り返し行われる（ステップＳ９）。キャンセル日又は契約の締め日になると，保険商品の提供可能期間が一旦終了する。

【0050】

その後，管理サーバ１００の課金期間計算部１１４は，記憶部１２０の取引管理テーブル１２４を参照して，商品の提供可能期間の間にカウントされた非課金期間を合算する（ステップＳ２−１１）。そして，課金期間計算部１１４は，当初の課金期間から非課金期間の合計値を差し引くことにより，実際の課金期間を算出する（ステップＳ２−１２）。つまり，ユーザ端末２００が購入確定通知を受信した日からキャンセル日又は締め日までの期間が当初の課金期間となり，その期間をＮとする。また，非課金期間の合計値をＭとする。この場合に，課金期間計算部１１４は，Ｎ−Ｍを求めればよい。このように非課金期間を控除することで，実際にユーザに請求する課金期間を算出することができる。

【0051】

図８は，課金期間計算工程（ステップＳ２）の第２の実施形態を示している。第２の実施形態において，管理サーバ１００は，被保険物品１０に取り付けられた電子タグ２０とユーザ端末２００との通信状態に関する情報と，ユーザ端末２００の位置情報とに基づいて，被保険物品１０に対して保険を掛けることが必要な期間（課金期間）を特定し，この課金期間を加算することにより，実際の課金期間を求める処理を行う。すなわち，本実施形態において，特に何もなければ保険料金は課金されない。他方で，ユーザにとって保険が必要であると推測される状態が発生した場合には，その状態が発生している期間（課金期間）を特定して保険商品を提供する。

【0052】

図８に示した第２の実施形態のステップＳ２−１３〜Ｓ２−１７は，図６に示した第１の実施形態のＳ２−１〜Ｓ２−５と同じである。他方で，第２の実施形態では，ステップＳ２−１８において，管理サーバ１００の要否情報記録部１１３は，ユーザ端末２００の移動及び電子タグ２０との通信状態が検知されていると判断した場合に，その状態に在る期間（課金期間）をカウントする（ステップＳ２−１９）。つまり，要否情報記録部１１３は，保険商品の必要期間（課金期間）が継続した時間を計測する。そして，要否情報記録部１１３は，課金期間に関する情報を記憶部１２０の取引管理テーブル１２４に記録する（ステップＳ２−２０）。例えば，要否情報記録部１１３は，課金期間が開始した日時と課金期間が終了した日時を取引管理テーブル１２４に記録すればよい。あるいは，課金期間が開始した日時と課金期間が継続した時間を記録してもよい。また，キャンセル日又は契約の締め日の後，管理サーバ１００の課金期間計算部１１４は，記憶部１２０の取引管理テーブル１２４を参照して，商品の提供可能期間の間にカウントされた課金期間を合算する（ステップＳ２−２３）。このようにして，課金期間計算部１１４は，実際の課金期間を算出する（ステップＳ２−２４）。このように，第２の実施形態は，課金期間をカウントする点において，非課金期間をカウントする第１の実施形態と異なる。

【0053】

図９は，課金期間計算工程（ステップＳ２）の第３の実施形態を示している。第３の実施形態は，ユーザ端末２００と通信可能な電子タグ２０を使用しない場合や，被保険物品１０自体がユーザ端末２００と通信できない場合を想定した実施形態である。第３の実施形態では，ユーザ端末２００が購入確定通知を受信した日（ステップＳ１−１２）からキャンセル日又は締め日（ステップＳ２−２７）までの商品の提供可能期間の間に，ユーザは，ユーザ端末２００を介して，任意のタイミングで，管理サーバ１００に保険商品の購入を要求することができる（ステップＳ２−２５）。ユーザ端末２００は，購入要求を送信する際に，保険商品の種類や，契約開始日，契約期間などの情報を管理サーバ１００に送信する。管理サーバ１００は，ユーザ端末２００から受信した購入要求に関する情報を記憶部１２０の取引管理テーブル１２４に記録する（ステップＳ２−２６）。商品の提供可能期間内であれば，ユーザは保険商品の購入要求を繰り返し行うことができる。そして，キャンセル日又は契約の締め日の後，管理サーバ１００の課金期間計算部１１４は，記憶部１２０の取引管理テーブル１２４を参照して，商品の提供可能期間の間に記録された課金期間を合算する（ステップＳ２−２８）。このようにして，課金期間計算部１１４は，実際の課金期間を算出する（ステップＳ２−２９）。

【0054】

図１０は，決済工程（ステップＳ３）の詳細なフローを示している。決済工程において，管理サーバ１００の支払請求部１１５は，上記した課金期間計算工程（ステップＳ２）で求めた実際の課金期間分の金額の支払いを，カード会社サーバ３００に対して一括して請求する（ステップＳ３−１）。上記したとおり，保険商品が１日単位型や１時間単位型のものの場合，課金期間は細かく別れることになると想定されるが，支払請求部１１５は，すべての課金期間の合計期間に対応する金額を算出して，その金額をまとめてカード会社サーバ３００に請求することとなる。また，ステップＳ３−１において支払請求部１１５がカード会社サーバ３００に請求する金額は，ステップＳ１−７においてカード会社サーバ３００が予め確保した与信枠内の金額となる。つまり，原則として請求金額が与信枠を超えることはないため，カード会社にとっても特段のリスクが発生しないようになっている。

【0055】

その後，カード会社サーバ３００は，管理サーバ１００から請求された金額について所定のトランザクション処理を行う（ステップＳ３−２）。ユーザ（カード利用者）の銀行口座からの金額の引き落としや，商店（カード加盟店）の銀行口座への金額の振込などを含むトランザクション処理が完了すると，カード会社サーバ３００は，管理サーバ１００に支払い通知を送信する。また，管理サーバ１００は，ユーザ端末２００に対して引き落とし通知を送信してもよい。これを受けて，ユーザ端末２００の表示部に，支払い完了の旨を表示させることも可能である（ステップＳ３−３）。

【0056】

図１１は，継続処理工程（ステップＳ４）の詳細なフローを示している。継続処理工程では，例えばユーザが保険商品の契約をキャンセルせずに契約の締め日を迎えた場合に，その契約を次の所定期間分だけ自動更新する。ただし，継続処理工程は，契約の自動更新を希望するユーザに対してのみ行うこととしてもよく，ユーザが自動更新を希望しない場合には継続処理工程は省略されて決済処理全体が終了する。

【0057】

図１１に示されるように，契約の自動更新を行う場合，管理サーバ１００の与信照会部１１１は，カード会社サーバ３００に対して，少なくとも課金対象となる単位期間１回分を超える所定期間分の金額の与信照会を行う（ステップＳ４−１）。カード会社サーバ３００は，管理サーバ１００から与信照会の依頼を受信すると，管理サーバ１００が求めている金額について与信枠を確保できるか否かを判断する（ステップＳ４−２）。また，カード会社サーバ３００は，与信枠が確保できると判断した場合，管理サーバ１００に対してその旨を通知する。与信枠確保成功の通知を受信した管理サーバ１００は，与信照会を行った所定期間額分の与信枠を予約する（ステップＳ４−３）。その後，管理サーバ１００は，ユーザ端末２００に対して，商品の購入が確定したことを通知し（ステップＳ４−４），ユーザ端末２００はこの通知を受信する（ステップＳ４−５）。この購入確定通知がユーザ端末２００に通知された時点で，保険商品の契約期間が継続することとなる。また，管理サーバ１００は，ユーザによる保険商品の購入が確定したことを記憶部１２０（データベース）に記録する（ステップＳ４−６）。保険商品の契約が自動更新されると，再び課金期間計算工程（ステップＳ２）へと処理が戻る。他方で，もしカード会社サーバ３００が与信枠が確保できないと判断した場合，契約の自動更新はなされずに決済処理全体が終了する。なお，与信枠が確保できない旨をカード会社サーバ３００から管理サーバ１００に通知することとしてもよい

【0058】

以上，本願明細書では，本発明の内容を表現するために，図面を参照しながら本発明の実施形態の説明を行った。ただし，本発明は，上記実施形態に限定されるものではなく，本願明細書に記載された事項に基づいて当業者が自明な変更形態や改良形態を包含するものである。

【符号の説明】

【0059】

１０…被保険物品 ２０…電子タグ
２１…発信部 ２２…ＩＣチップ
１００…管理サーバ １１０…処理部
１１１…与信照会部 １１２…要否判断部
１１３…要否情報記録部 １１４…課金期間計算部
１１５…支払請求部 １２０…記憶部
１２１…顧客管理テーブル １２２…購買管理テーブル
１２３…商品管理テーブル １２４…取引管理テーブル
１３０…ネットワーク通信部 ２００…ユーザ端末
２１０…制御部 ２２０…記憶部
２３０…ネットワーク通信部 ２４０…操作部
２５０…表示部 ２６０…位置情報取得部
２７０…近距離無線通信部 ３００…カード会社サーバ

【要約】      （修正有）

【課題】カード加盟店及びカード利用者の双方にとって利用しやすい小期間型商品のカード決済方法を提供する。
【解決手段】単位期間ごとに課金される商品をユーザに提供する場合において，管理サーバ１００は，ネットワークを通じて課金額の支払いをカード会社サーバ３００に請求する。管理サーバ１００は，ユーザから商品の選択情報を受け付け，ユーザに選択された商品について，カード会社サーバ３００に対し，課金対象となる単位期間１回分を超える所定期間分の金額の与信照会を行う。所定期間分の金額の与信枠が確保された後，管理サーバ１００は，商品の提供可能期間の間にユーザが課金要求を行った課金期間を求め，この課金期間に応じた金額の支払いをカード会社サーバ３００に一括して請求する。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】