JP2014153836A - 課金システム、課金方法 - Google Patents

Abstract

【課題】アプリケーションの利用者が購入金を立て替えることなく、アプリケーションを入手できるようにする。
【解決手段】課金システムはアプリケーションの購入を、購入料金を指定して、代理購入者に対して申請する購入申請部と、申請を受け付けて、購入を申請したユーザが所属する部門を示す部門情報と前記購入料金とを対応付けて購入履歴情報として記憶する記憶制御部と、前記申請にて指定された前記アプリケーションの前記代理購入者による購入指示に従って、前記販売用サーバに対して購入を行う購入実行部と、購入した前記アプリケーションを前記ユーザの情報端末へと転送するように前記販売用サーバへと指示する転送指示部と、前記購入履歴情報における前記購入料金を集計して、前記部門ごとの合計金額を算出する集計部と、前記合計金額を前記部門に対して請求する処理を行う請求部と、を備える。
【選択図】図１

Description

本発明は、課金システム、課金方法に関する。

従来、ｉｐｈｏｎｅ（登録商標）やＡｎｄｒｏｉｄ（登録商標）などのスマートフォンにおいては、端末で使用することのできるアプリケーション流通用のＡｐｐＳｔｏｒｅ（登録商標）等の専用のマーケットプレイスが設けられている。ユーザは欲しいアプリケーションがあった場合、自らの専用のアカウントを用いてマーケットプレイスから購入することができ、購入した代金はアカウントと連動したクレジットカードなどにより決済することができる。

近年、こうした個人所有のスマートフォンを、会社の業務でも使用する流れが増加しており、業務で使用した通話料や、アプリケーション費用などを会社側で支払うようにするといったことが行われている。従来の社内システムにおける精算システムとしては、例えば特許文献１に記載のものが存在する。特許文献１においては、例えば購入者がアプリケーションの販売用サーバに対して購入を申し込むと、直接アプリケーションが購入者の端末にダウンロードされるのではなく、購入者に対して割り当てられたストレージ領域に格納される。したがって、購入者はアプリケーションが格納された位置情報を、実際にアプリケーションを使用するユーザに伝えることによって、所定のユーザが自ら金額を立て替えることなく、業務に用いるアプリケーションを入手することができるようになる。

しかしながら、例えば上述したＡｐｐｓｔｏｒｅのように、購入者が端末から直接購入してアプリケーションがダウンロードされる構成の場合、利用者がアプリケーションの購入費用を事前に立て替えて支払う必要があるため、精算の手間がかかってしまうという問題がある。

本発明は、上記に鑑みてなされたものであって、アプリケーションの利用者が購入金を立て替えることなく、アプリケーションを入手できるようにすることのできるアプリケーションの課金システムを提供することにある。

上述した課題を解決し、目的を達成するために、本発明の課金システムは、アプリケーションの購入を、購入料金を指定して、代理購入者に対して申請する購入申請部と、申請を受け付けて、購入を申請したユーザが所属する部門を示す部門情報と前記購入料金とを対応付けて購入履歴情報として記憶する記憶制御部と、前記申請にて指定された前記アプリケーションの前記代理購入者による購入指示に従って、前記販売用サーバに対して購入を行う購入実行部と、購入した前記アプリケーションを前記ユーザの情報端末へと転送するように前記販売用サーバへと指示する転送指示部と、前記購入履歴情報における前記購入料金を集計して、前記部門ごとの合計金額を算出する集計部と、前記合計金額を前記部門に対して請求する処理を行う請求部と、を備えることを特徴とする。

本発明によれば、アプリケーションの利用者が購入金を立て替えることなく、アプリケーションを入手できるようにすることができるという効果を奏する。

図１は、実施形態の課金システムの機能構成を示すブロック図である。 図２は、実施形態の部門マスタのテーブル構造を示す図である。 図３は、実施形態の購入履歴マスタのテーブル構造を示す図である。 図４は、実施形態のアプリケーション購入の業務フローを示す図である。

以下に添付図面を参照して、本発明の課金システムを具体化した実施形態について説明する。図１は、課金システム１の機能構成を示したブロック図である。図１に示されるように、課金システム１は、各利用者に対して付与されるＰＣ２がサーバ装置１００へと接続された構成となっており、サーバ装置１００に設けられたグループウェアを通じて機能を利用することができる。サーバ装置１００は、一般的なコンピュータと同様のハードウェア構成がなされている。グループウェアは、サーバ装置１００にインストールされたプログラムにより実現されており、ＰＣ２からブラウザを通じて所定のＵＲＬにアクセスすることで利用することができる。なお、グループウェアをこのようなＷＥＢサービスとして提供せずに、ローカルのシステムとして実現してもよい。

ユーザ用グループウェア１１０は、一般の社員が利用するグループウェアである。具体的な使用の態様の一例としては、ユーザごとに割り当てられた社員用の識別情報とパスワードを用いて所定のログイン画面からログイン操作をすることにより使用することができる。ユーザ用グループウェア１１０は、機能として購入申請部１１１を利用することができる。

購入申請部１１１は、一般の社員である利用者が、自らが所有するスマートフォンなどの情報端末１０００に業務で使用したいアプリケーションがある場合に、その購入の申請を行うための処理を行う。購入申請部１１１は、インタフェースとして利用者が購入したいアプリケーションの情報や、自らの識別情報、所属する部門の情報、アプリケーションの金額（購入料金）、情報端末１０００と関連付けたアプリケーションの販売用サーバ２００におけるアカウント情報を入力する操作画面をユーザ用グループウェア１１０に提供する。アプリケーションの情報としては、例えばアプリケーションの名称でもよいし、アプリケーションの販売用サーバ２００で提供されているアプリケーションの購入ページのＵＲＬであってもよい。なお、識別情報は、利用者が入力しなくとも、ログインする際に使用した識別情報を保持しておき、自動的に入力するようにしてもよい。購入申請部１１１のインタフェースに所定の情報を入力後に、例えば「送信する」などの操作ボタンが押されることによって、これらの申請情報を含む申請が送信される。

本実施形態においては、このようにして送信された申請は、予め決められた承認者へと送信される。承認者としては、例えば利用者の部門の上司などの決裁者が該当する。承認の要請があった旨の通知は、例えば承認者用の管理者用グループウェア１２０に送られ、管理者用グループウェア１２０から承認者に例えばメールなどの手段を用いて承認の要請があった旨が通知される。管理者用グループウェア１２０は、承認部１２１の機能を利用することができる。承認部１２１は、要請があった承認の内容を承認者が確認することができるインタフェースを提供する。例えば、承認者は申請を承認する場合には「承認する」のボタンを、却下する場合は「却下する」のボタンを操作する。そして、承認部１２１は、「承認する」が選択された場合に、アプリケーションの購入手続きを行う部門（代理購入者）へと申請を転送する。一方、承認部１２１は、「却下する」が選択された場合は、例えば承認をした利用者に対して、その旨を通知する。

請求用グループウェア１３０は、代理購入者であるアプリケーションの購入手続きを行う部門の担当者が使用するグループウェアである。例えば、代理購入者は、備品の購入などを行う総務部や、リース会社などが相当する。請求用グループウェア１３０には、機能として記憶制御部１３１、集計部１３２、請求部１３３、購入実行部１３４、及び転送指示部１３５を利用することができる。

記憶制御部１３１は、アプリケーション購入や集計に必要な情報を記憶し、予め設定されたデータベースに対して所定の情報を記憶したり、更新したりする処理を行う。記憶制御部１３１は、記憶領域としてデータを記憶させるデータベースとしては、例えば部門マスタ１３１ａ、及び購入履歴マスタ１３１ｂを利用する。図２、及び図３はそれぞれ部門マスタ１３１ａ、購入履歴マスタ１３１ｂのテーブル構成を示している。

図２で示される部門マスタ１３１ａ（部門記憶部）は、カラムとして、部門情報である部門ＩＤ、識別情報であるユーザＩＤ、及びユーザ名を備えている。部門マスタ１３１ａは、どの利用者がどの部門に所属しているかを示すものであり、ユーザＩＤの重複するレコードが存在しない構造となっている。なお、部門マスタ１３１ａには、カラムとして利用者の使用する情報端末１０００の登録情報として、ＡｐｐｌｅＩＤなどの販売用サーバ２００にて使用することのできるアカウント情報を追加してもよい。本例では、例えばユーザＩＤ「nakayama＿32」で示される「中山」が「営業１Ｇ」に所属することが示されている。部門マスタ１３１ａは、例えば新たに社員が入社したり、所属が変更されたりする際に操作されるデータベースであり、例えば管理者用グループウェア１２０から操作できるようにしてもよい。

購入履歴マスタ１３１ｂ（購入履歴記憶部）は、アプリケーションの購入申請が承認されるごとに記憶制御部１３１によって購入履歴情報のレコードが追加される。購入履歴マスタ１３１ｂは、カラムとしてユーザＩＤ、部門ＩＤ、購入したアプリケーションを識別する情報であるアプリＩＤ、購入したアプリケーションの金額のカラムを含む。また、カラムには、アプリケーションの購入申請のあった日時（以下、タイムスタンプという。）を記憶するようにしてもよい。これらの各情報は承認部１２１から送信された情報によって得られたものを用いてもよい。また、承認部１２１からはユーザＩＤとアプリケーションの金額、アプリＩＤの情報のみが送信されるようにし、記憶制御部１３１がユーザＩＤと対応する部門ＩＤを部門マスタ１３１ａから取得して購入履歴マスタ１３１ｂに記憶させるようにしてもよい。また、カラムとしてアカウント情報を追加してもよい。

購入実行部１３４は、販売用サーバ２００に対して指定されたアプリケーションの購入を実行する。なお、購入実行部１３４の実現の構成としては、サーバ装置１００の機能として提供するほか、販売用サーバ２００によって提供されるアプリケーションを例えば代理購入者のＰＣ２にインストールし、当該アプリケーションを用いて、サーバ装置１００を通さず購入するようにしてもよい。購入にあたっては、代理購入者が有するアプリケーション購入用のアカウントを利用して行われる。したがって、本実施形態の課金システムにおいては、アプリケーションの購入はすべて代理購入者のアカウントを通じて行われうる。購入にかかる決済は、代理購入者のアカウントと関連付けられたクレジットカードなどの決済手段で行われるため、アプリケーションの購入にかかる請求はすべて代理購入者の部門に対して行われる。

転送指示部１３５は、代理購入者が購入したアプリケーションを、購入の申請を行った利用者の情報端末１０００に対して転送する指示をだす。実際にアプリケーションの転送の処理を行う機能は、販売用サーバ２００において提供されている。すなわち、販売用サーバ２００には、正式にアプリケーションを購入したアカウントを用いて、そのアプリケーションを購入者本人ではなく、他のアカウントに使用権を譲渡する機能が設けられている。転送指示部１３５を通じて購入の申請者への譲渡の指示がされると、販売用サーバ２００は、情報端末１０００に対して、所定のアプリケーション自体を送信、もしくはダウンロードを行うためのＵＲＬを送信する。そして、利用者は、自らの情報端末１０００でアプリケーションをインストールして使用を開始することができる。なお、販売用サーバ２００から転送を支持する処理を行うためのＡＰＩ（Application Programming Interface）が提供されている場合は、サーバ装置１００内に転送指示部１３５の機能を実装することもできる。

集計部１３２は、購入履歴マスタ１３１ｂに記憶された履歴を参照して、社員、又は部門ごとのアプリケーションの購入金額の合計金額を算出する。集計のタイミングは、日ごと、月ごと、決算期ごと、年ごとなど適宜設定することができる。例えば、月ごとに部門ごとの金額を集計する場合は、購入履歴マスタ１３１ｂから、「部門ＩＤ」と「タイムスタンプ」の値を指定して、アプリ金額の値を合算すれば得られる。

請求部１３３は、集計部１３２が集計した部門ごとのアプリケーションの購入額を部門に対して請求する。代理購入者である部門が直接購入した場合、購入の履歴が社内のシステムには残らないため、部門の予算に振り替えて、社内システムとしての予算の実際の消化との整合性を取る。

図４は、以上に示した課金システムを用いて業務フローを示す図である。図４に示されるように、まずアプリ購入を申請した利用者が、ユーザ用グループウェア１１０を通じてアプリ購入申請を行う（ステップＳ１０１）。この処理では、購入申請部１１１が、利用者によるアカウント情報、部門情報、及びアプリケーションの購入料金の指定を受付け、指定された情報を含む申請データを承認者に対して送信する。

次いで、申請を行うとその通知が承認者の管理者用グループウェア１２０になされ、承認者は購入申請を承認するか否かを決定する（ステップＳ１０２）。決定された結果は、承認部１２１により実行される。承認が却下された場合（ステップＳ１０２：Ｎｏ）、アプリ購入者に対して申請が不許可であった旨が承認部１２１によって通知される（ステップＳ１０３）。

一方、申請が承認された場合（ステップＳ１０２：Ｙｅｓ）、承認部１２１はアプリ購入申請が購入部門へと通知されるように処理する（ステップＳ１０４）。この際、購入履歴マスタ１３１ｂに、記憶制御部１３１によってユーザＩＤ、部門ＩＤ、アプリＩＤ、アプリ料金などが記憶される（ステップＳ１０５）。購入部門は、購入履歴マスタ１３１ｂに記憶された履歴から、購入するアプリケーションを把握し、自らのアカウントを用いて購入実行部１３４から販売用サーバ２００にアクセスし、代理でアプリケーションを購入する（ステップＳ１０６）。購入に係る処理は、購入実行部１３４を用いて行われる。購入が完了すると、購入部門は、購入したアプリケーションを転送指示部１３５によって購入申請者の情報端末１０００に対してアカウントを指定して転送指示する（ステップＳ１０７）。転送を受け取ったアプリ購入者はアプリケーションを情報端末１０００にインストールする（ステップＳ１０８）。また、購入部門は、集計部１３２の機能を用いて所定のタイミングで部門ごとの購入履歴を集計し、合計されたアプリ金額を請求部１３３によって部門に対して請求する（ステップＳ１０９）。

以上に示した本実施形態の課金システム１にあっては、購入部門が利用者の変わりにアプリケーションを購入し、購入したアプリケーションを利用者の情報端末１０００に転送することができる。そのため、アプリケーションの購入を申請した利用者が、直接販売用サーバ２００からアプリケーションを購入して自分で支払いをしなくとも、業務に必要なアプリケーションを入手し、利用することができるようになる。

また、利用者が購入の申請時に、購入金額を指定して申請を出し、アプリ金額を購入履歴マスタに記憶させることで、販売用サーバ２００で直接購入した場合に、社内システム上に購入の履歴を残すことが出来ない場合であっても、購入部門は部門や社員ごとの購入額を集計可能になる。

本実施の形態のサーバ装置１００は、ＣＰＵなどの制御装置と、ＲＯＭ（Read Only Memory）やＲＡＭなどの記憶装置と、ＨＤＤ、ＣＤドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置を備えており、通常のコンピュータを利用したハードウェア構成となっている。なお、上述した各部は、単一のサーバ装置１００内に全て実装する必要はなく、例えば複数のハードウェア上に分散されて実装されるようにしてもよい。

本実施形態の課金システムで実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、本実施形態の課金システムで実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態の課金システムで実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。また、本実施形態の課金システムに係るプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

本実施の形態の課金システムで実行される各プログラムは、上述した各機能を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体からプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、各部が主記憶装置上に生成されるようになっている。

１ 課金システム
１００ サーバ装置
１１０ ユーザ用グループウェア
１１１ 購入申請部
１２０ 管理者用グループウェア
１２１ 承認部
１３０ 請求用グループウェア
１３１ 記憶制御部
１３１ａ 部門マスタ
１３１ｂ 購入履歴マスタ
１３２ 集計部
１３３ 請求部
１３４ 購入実行部
１３５ 転送指示部
２００ 販売用サーバ
１０００ 情報端末

国際公開第０２／００３１９９号

Claims (5)

1. アプリケーションの購入を、購入料金を指定して、代理購入者に対して申請する購入申請部と、
   申請を受け付けて、購入を申請したユーザが所属する部門を示す部門情報と前記購入料金とを対応付けて購入履歴情報として記憶する記憶制御部と、
   前記申請にて指定された前記アプリケーションの前記代理購入者による購入指示に従って、前記販売用サーバに対して購入を行う購入実行部と、
   購入した前記アプリケーションを前記ユーザの情報端末へと転送するように前記販売用サーバへと指示する転送指示部と、
   前記購入履歴情報における前記購入料金を集計して、前記部門ごとの合計金額を算出する集計部と、
   前記合計金額を前記部門に対して請求する処理を行う請求部と、
   を備えることを特徴とする課金システム。
2. 前記購入申請部は、前記アプリケーションの販売用サーバにおけるアカウント情報、所属する部門情報を前記購入料金とともに指定し、
   前記記憶制御部は、指定された前記部門情報と対応付けて前記購入料金を記憶させ、
   前記転送指示部は、指定された前記アカウント情報にて前記ユーザの情報端末を特定する、
   ことを特徴とする請求項１に記載の課金システム。
3. 利用するユーザの社員としての識別情報を、前記部門情報、及び前記アカウント情報と関連付けて予め記憶した部門記憶部と、
   を更に備え、
   前記購入申請部は、利用するユーザの社員としての識別情報を前記購入料金とともに指定し、
   前記記憶制御部は、前記部門記憶部において前記識別情報と対応付けられた前記部門情報と対応付けて前記購入料金を記憶させる、
   ことを特徴とする請求項１に記載の課金システム。
4. 前記購入申請部による申請を承認するか否かを決裁者に対して通知し、承認する旨の指示を受け付けた場合に、前記代理購入者に対して、前記申請が通知される承認部と、
   を更に備えることを特徴とする請求項１に記載の課金システム。
5. アプリケーションの購入を、アプリケーションの購入料金を指定して、代理購入者に対して申請する購入申請ステップと、
   申請を受け付けて、前記購入料金を購入を申請したユーザが所属する部門情報と対応付けて購入履歴情報として記憶する記憶制御ステップと、
   前記申請にて指定された前記アプリケーションの前記代理購入者による購入指示に従って、前記販売用サーバに対して購入を行う購入実行ステップと、
   購入した前記アプリケーションを前記ユーザの情報端末へと転送するように前記販売用サーバへと指示する転送指示ステップと、
   前記購入履歴情報における前記購入料金を集計して、部門ごとの合計金額を算出する集計ステップと、
   前記合計金額を前記部門に対して請求する処理を行う請求ステップと、
   を含むことを特徴とする課金方法。

Images