(57)【要約】【課題】１回のオペレーションで複数のサービスに対する課金処理を実行する。【解決手段】サービスを利用する利用者装置１０１がサービスを受けるために実行されるアプリケーションが、サービスに基づいた課金を行う課金システム１０６へ課金と払い戻しと分割課金とのいずれかの要求を行うための要求信号にサービスを識別するためのサービス識別子を含めて送信し、アプリケーションから送信された要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別し、要求信号に含まれるサービス識別子を抽出し、サービス識別子に応じたサービスに対する識別した課金と払い戻しと分割課金とのいずれかを課金システム１０６へ要求する。【選択図】図１
2009276972.tif 000002
【特許請求の範囲】
【請求項１】
サービスの利用に基づいて課金の処理を行う課金処理方法であって、
前記サービスを利用する利用者装置が前記サービスを受けるために実行されるアプリケーションが、前記サービスに基づいた課金を行う課金システムへ課金と払い戻しと分割課金とのいずれかの要求を行うための要求信号に前記サービスを識別するために該サービス毎に付与されたサービス識別子を含めて送信する処理と、
前記アプリケーションから送信された要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別する処理と、
前記要求信号に含まれる前記サービス識別子を抽出する処理と、
前記サービス識別子に応じたサービスに対する前記識別した課金と払い戻しと分割課金とのいずれかを前記課金システムへ要求する処理とを有する課金処理方法。
【請求項２】
サービスを利用する利用者装置と、前記サービスの利用に基づいて課金を行う課金システムとに接続されたサービスプロバイダ装置であって、
前記利用者装置および前記課金システムと通信を行う通信部と、
前記利用者装置が前記サービスを受けるために実行され、前記課金システムへ課金と払い戻しと分割課金とのいずれかの要求を行うための要求信号に前記サービスを識別するために該サービス毎に付与されたサービス識別子を含めて送信するアプリケーションと、
前記アプリケーションからの要求に従って処理を行うＡＰＩとを有し、
前記ＡＰＩは、
前記アプリケーションから前記要求信号を受信するアプリケーションインタフェース部と、
前記要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別するオペレーション識別部と、
前記要求信号に含まれる前記サービス識別子を抽出する識別子抽出部と、
前記サービス識別子に応じたサービスに対する前記識別した課金と払い戻しと分割課金とのいずれかを、前記通信部を介して前記課金システムへ要求する出力部とを有するサービスプロバイダ装置。
【請求項３】
サービスを利用する利用者装置が前記サービスを受けるために実行されるアプリケーションが搭載されたサービスプロバイダ装置に実行させるプログラムであって、
前記アプリケーションから送信された要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別する手順と、
前記要求信号に含まれる前記サービスを識別するために該サービス毎に付与されたサービス識別子を前記要求信号から抽出する手順と、
前記サービス識別子に応じたサービスに対する前記識別した課金と払い戻しと分割課金とのいずれかを前記課金システムへ要求する手順とを実行させるプログラム。
【請求項４】
サービスを利用する利用者装置が前記サービスを受けるために実行されるアプリケーションと、前記サービスの利用に基づいて課金を行う課金システムとに接続されたＡＰＩであって、
前記アプリケーションから前記課金システムへ課金と払い戻しと分割課金とのいずれかの要求を行うための要求信号を受信するアプリケーションインタフェース部と、
前記要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別するオペレーション識別部と、
前記要求信号に含まれる前記サービスを識別するために該サービス毎に付与されたサービス識別子を抽出する識別子抽出部と、
前記サービス識別子に応じたサービスに対する前記識別した課金と払い戻しと分割課金とのいずれかを前記課金システムへ要求する出力部とを有するＡＰＩ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、課金処理方法、サービスプロバイダ装置、プログラムおよびＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）に関する。
【背景技術】
【０００２】
通信サービスを提供するための通信サービス向けアプリケーションを用いてサービスを行うために、様々なＡＰＩが考えられている。そのＡＰＩの中でＰａｒｌａｙ（パーレイ）グループが規定しているＰａｒｌａｙ  Ｘ（パーレイエックス）が近年普及している。
【０００３】
Ｐａｒｌａｙ  Ｘは、インターネットサービス用ＩＰネットワークと電話サービス用の電話網とをＩＰ通信網として統合したＮＧＮ（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ）に対応可能である。
【０００４】
Ｐａｒｌａｙ  Ｘは、複数種類のＡＰＩからなる。特に、Ｐａｒｌａｙ  ＸのＰａｒｔ６では、Ｐａｙｍｅｎｔ（課金処理）に関するＡＰＩが規定されている（例えば、非特許文献１参照）。
【０００５】
図６は、一般的なサービス提供システムの一例を示す図である。
【０００６】
図６に示したサービス提供システムは、利用者装置１００１と、Ｗｅｂサービスプロバイダ装置１００２と、ＳＭＳシステム１００３と、通話システム１００４と、Ｗｅｂシステム１００５と、課金システム１００６とから構成されている。
【０００７】
利用者装置１００１は、本サービス提供システムにて提供されるサービスを利用する利用者が操作する通信装置（例えば、通信端末等）である。利用者装置１００１は、Ｗｅｂサービスプロバイダ装置１００２を介して各システム（ＳＭＳシステム１００３、通話システム１００４、Ｗｅｂシステム１００５および課金システム１００６）へアクセスする。
【０００８】
Ｗｅｂサービスプロバイダ装置１００２は、利用者装置１００１が各システムへアクセスを行うＷｅｂサービスプロバイダに設けられた装置である。
【０００９】
また、Ｗｅｂサービスプロバイダ装置１００２には、アプリケーション１０２１と、ミドルウェア１０２２と、ＤＢ１０２３とが設けられている。
【００１０】
アプリケーション１０２１は、利用者装置１００１がサービスを受けるために実行される一般的なソフトウェアである。
【００１１】
ミドルウェア１０２２は、アプリケーション１０２１からの要求に従って処理を行うＡＰＩである。
【００１２】
ＤＢ１０２３は、アプリケーション１０２１から送信されるＲｅｆｅｒｅｎｃｅ  Ｃｏｄｅと、当該Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが対応しているサービス利用とを対応付けて登録するデータベースである。
【００１３】
ＳＭＳシステム１００３は、ＳＭＳ（Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ）提供するシステムである。
【００１４】
通話システム１００４は、通話サービスを提供するシステムである。
【００１５】
Ｗｅｂシステム１００５は、Ｗｅｂサービスを提供するシステムである。
【００１６】
課金システム１００６は、利用者装置１００１に提供されたサービスに基づいた課金を行うシステムである。
【００１７】
図７は、図６に示したサービス提供システムにおける一般的な課金処理を説明するためのシーケンス図である。
【００１８】
利用者装置１００１にサービスを提供するために、ＳＭＳシステム１００３と、通話システム１００４と、Ｗｅｂシステム１００５を利用した後、アプリケーション１０２１から課金の要求がミドルウェア１０２２に対して行われる（ステップＳ９０１）。この要求は、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅというパラメータが含まれる要求信号を用いて行われる。
【００１９】
すると、ミドルウェア１０２２にて、当該Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅがどのサービス利用に対応しているかがミドルウェア１０２２によってＤＢ１０２３の中から検索される（ステップＳ９０２）。具体的には、サービスを識別するためにサービスそれぞれに固有に付与された識別情報であるサービス識別子が検索される。
【００２０】
その後、検索された結果、ＳＭＳサービスのサービス識別子「ｓｍｓ１」を用いてミドルウェア１０２２から課金システム１００６へＳＭＳサービスの課金要求が行われる（ステップＳ９０３）。また、通話サービスのサービス識別子「通話１」を用いてミドルウェア１０２２から課金システム１００６へ通話サービスの課金要求が行われる（ステップＳ９０４）。また、Ｗｅｂサービスのサービス識別子「Ｗｅｂ１」を用いてミドルウェア１０２２から課金システム１００６へＷｅｂサービスの課金要求が行われる（ステップＳ９０５）。
【非特許文献１】ＥＴＳＩ  ＥＳ  ２０２  ５０４−６  ｖ０．０.４（２００７−０６）
【発明の開示】
【発明が解決しようとする課題】
【００２１】
しかしながら、上述した技術においては以下に示す３つの問題点がある。
【００２２】
１つ目の問題点は、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅの利用用途が不明確である、つまり、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが次の２つの用途のうち、一方しか利用できないということである。
・課金請求・払い戻し請求の管理番号
・サービス実施の確証
また、２つ目の問題点は、サービス実施の確証としてＲｅｆｅｒｅｎｃｅ  Ｃｏｄｅを利用する場合、複数のサービス実施に対する課金を行うと、課金要求前にＲｅｆｅｒｅｎｃｅ  Ｃｏｄｅの発行とサービス実施の確証（ｓｍｓ１、通話１、Ｗｅｂ１）との関連付け登録をアプリケーション１０２１が行う必要があるという点である。つまり、アプリケーション１０２１が「課金要求」と「関連付け登録」との２回ミドルウェア１０２２を呼び出さなければならないという問題点がある。
【００２３】
また、３つ目の問題点は、アプリケーション１０２１が「課金要求」と「関連付け登録」とを２つに分けて呼び出す場合、課金要求のタイミングと関連付け登録のタイミングとがずれてしまうということである。そのため、関連付けの登録が完了する前に課金請求が行われてしまうと、アプリケーション１０２１の期待とは異なる課金請求が行われてしまうという問題点がある。
【００２４】
本発明は、上述した課題を解決する課金処理方法、サービスプロバイダ装置、プログラムおよびＡＰＩを提供することを目的とする。
【課題を解決するための手段】
【００２５】
上記目的を達成するために本発明は、
サービスの利用に基づいて課金の処理を行う課金処理方法であって、
前記サービスを利用する利用者装置が前記サービスを受けるために実行されるアプリケーションが、前記サービスに基づいた課金を行う課金システムへ課金と払い戻しと分割課金とのいずれかの要求を行うための要求信号に前記サービスを識別するために該サービス毎に付与されたサービス識別子を含めて送信する処理と、
前記アプリケーションから送信された要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別する処理と、
前記要求信号に含まれる前記サービス識別子を抽出する処理と、
前記サービス識別子に応じたサービスに対する前記識別した課金と払い戻しと分割課金とのいずれかを前記課金システムへ要求する処理とを有する。
【００２６】
また、サービスを利用する利用者装置と、前記サービスの利用に基づいて課金を行う課金システムとに接続されたサービスプロバイダ装置であって、
前記利用者装置および前記課金システムと通信を行う通信部と、
前記利用者装置が前記サービスを受けるために実行され、前記課金システムへ課金と払い戻しと分割課金とのいずれかの要求を行うための要求信号に前記サービスを識別するために該サービス毎に付与されたサービス識別子を含めて送信するアプリケーションと、
前記アプリケーションからの要求に従って処理を行うＡＰＩとを有し、
前記ＡＰＩは、
前記アプリケーションから前記要求信号を受信するアプリケーションインタフェース部と、
前記要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別するオペレーション識別部と、
前記要求信号に含まれる前記サービス識別子を抽出する識別子抽出部と、
前記サービス識別子に応じたサービスに対する前記識別した課金と払い戻しと分割課金とのいずれかを、前記通信部を介して前記課金システムへ要求する出力部とを有する。
【００２７】
また、サービスを利用する利用者装置が前記サービスを受けるために実行されるアプリケーションが搭載されたサービスプロバイダ装置に実行させるプログラムであって、
前記アプリケーションから送信された要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別する手順と、
前記要求信号に含まれる前記サービスを識別するために該サービス毎に付与されたサービス識別子を前記要求信号から抽出する手順と、
前記サービス識別子に応じたサービスに対する前記識別した課金と払い戻しと分割課金とのいずれかを前記課金システムへ要求する手順とを実行させる。
【００２８】
また、サービスを利用する利用者装置が前記サービスを受けるために実行されるアプリケーションと、前記サービスの利用に基づいて課金を行う課金システムとに接続されたＡＰＩであって、
前記アプリケーションから前記課金システムへ課金と払い戻しと分割課金とのいずれかの要求を行うための要求信号を受信するアプリケーションインタフェース部と、
前記要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別するオペレーション識別部と、
前記要求信号に含まれる前記サービスを識別するために該サービス毎に付与されたサービス識別子を抽出する識別子抽出部と、
前記サービス識別子に応じたサービスに対する前記識別した課金と払い戻しと分割課金とのいずれかを前記課金システムへ要求する出力部とを有する。
【発明の効果】
【００２９】
以上説明したように本発明においては、サービスを利用する利用者装置がサービスを受けるために実行されるアプリケーションが、サービスに基づいた課金を行う課金システムへ課金と払い戻しと分割課金とのいずれかの要求を行うための要求信号にサービスを識別するためのサービス識別子を含めて送信し、アプリケーションから送信された要求信号が課金と払い戻しと分割課金とのいずれかの要求を示すものであるかを識別し、要求信号に含まれるサービス識別子を抽出し、サービス識別子に応じたサービスに対する識別した課金と払い戻しと分割課金とのいずれかを課金システムへ要求する構成としたため、１回のオペレーションで複数のサービスに対する課金処理を実行することができる。
【発明を実施するための最良の形態】
【００３０】
以下に、本発明の実施の形態について図面を参照して説明する。
【００３１】
図１は、本発明のＡＰＩが搭載された装置の実施の一形態を示す図である。
【００３２】
本形態は図１に示すように、利用者装置１０１と、Ｗｅｂサービスプロバイダ装置１０２と、ＳＭＳシステム１０３と、通話システム１０４と、Ｗｅｂシステム１０５と、課金システム１０６とから構成されている。
【００３３】
利用者装置１０１は、各システム（ＳＭＳシステム１０３、通話システム１０４、Ｗｅｂシステム１０５および課金システム１０６）から提供されるサービスを利用する利用者が操作する通信装置（例えば、通信端末等）である。利用者装置１０１は、Ｗｅｂサービスプロバイダ装置１０２を介して各システムへアクセスする。
【００３４】
Ｗｅｂサービスプロバイダ装置１０２は、利用者装置１０１が各システムへアクセスを行うＷｅｂサービスプロバイダに設けられたサービスプロバイダ装置である。
【００３５】
図２は、図１に示したＷｅｂサービスプロバイダ装置１０２の内部の一構成例を示す図である。
【００３６】
図１に示したＷｅｂサービスプロバイダ装置１０２には図２に示すように、通信部１２０と、アプリケーション１２１と、ミドルウェア１２２とが設けられて（搭載されて）いる。
【００３７】
通信部１２０は、利用者装置１０１、ＳＭＳシステム１０３、通話システム１０４、Ｗｅｂシステム１０５および課金システム１０６との間にて通信を行う。
【００３８】
アプリケーション１２１は、通信部１２０を介して接続してきた利用者装置１０１がサービスを受けるために実行されるソフトウェアである。
【００３９】
ミドルウェア１２２は、アプリケーション１２１からの要求に従って処理を行うＡＰＩである。また、ミドルウェア１２２は、プログラムによって構成されており、Ｗｅｂサービスプロバイダ装置１０２が有する記録媒体（不図示）に格納されているものである。そして、本プログラムを記録媒体から読み出して実行することにより、以下の処理が行われる。
【００４０】
ミドルウェア１２２にはさらに、アプリケーションインタフェース部２０１と、オペレーション識別部２０２と、識別子抽出部２０３と、出力部２０４とが設けられている。
【００４１】
アプリケーションインタフェース部２０１は、アプリケーション１２１から送信された要求信号を受信する。
【００４２】
オペレーション識別部２０２は、アプリケーションインタフェース部２０１にて受信した要求信号が何のオペレーションであるかを識別する。
【００４３】
識別子抽出部２０３は、アプリケーションインタフェース部２０１にて受信した要求信号に含まれるサービスを識別するためのサービス識別子を抽出する。
【００４４】
出力部２０４は、オペレーション識別部２０２にて識別されたオペレーションと、識別子抽出部２０３にて抽出されたサービス識別子とに基づいて、課金システム１０６へ課金要求、払い戻し要求や分割課金要求を行う信号を通信部１２０を介して送信する。
【００４５】
なお、図２には、図１に示したＷｅｂサービスプロバイダ装置１０２の内部の構成要素のうち本発明に関わる構成要素のみを示した。
【００４６】
ＳＭＳシステム１０３は、ＳＭＳ（Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ）提供するシステムである。
【００４７】
通話システム１０４は、通話サービスを提供するシステムである。
【００４８】
Ｗｅｂシステム１０５は、Ｗｅｂサービスを提供するシステムである。
【００４９】
課金システム１０６は、利用者装置１０１に提供されたサービスに基づいた課金を行うシステムである。
【００５０】
なお、サービスを提供するシステムは、ＳＭＳシステム１０３、通話システム１０４、Ｗｅｂシステム１０５および課金システム１０６以外の他のシステムが接続されているものであっても良いことは言うまでもない。
【００５１】
以下に、図１に示した形態における課金要求方法について説明する。
【００５２】
図３は、図１に示した形態における課金処理方法のうち課金要求の処理を説明するためのシーケンス図である。
【００５３】
利用者装置１０１にサービスを提供するために、ＳＭＳシステム１０３と、通話システム１０４と、Ｗｅｂシステム１０５とを利用した後、アプリケーション１２１から課金の要求がミドルウェア１２２に対して行われる（ステップＳ１）。この要求は、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅというパラメータが含まれる要求信号を用いて行われる。Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅは、課金要求、払い戻し要求や分割課金要求の管理番号が示されるものである。ここでは、課金要求の管理番号が示される場合（ｃｈａｒｇｅＡｍｏｕｎｔ）を例に挙げて説明する。またこのとき、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅに、ＣｏｎｆｉｒｍａｔｉｏｎＲｅｆというパラメータが追加されてミドルウェア１２２へ要求される。このＣｏｎｆｉｒｍａｔｉｏｎＲｅｆには、サービス実施の確証を行うための識別子が含まれ、ここでは、ＳＭＳシステム１０３から提供されたＳＭＳサービスのサービス識別子である「ｓｍｓ１」と、通話システム１０４から提供された通話サービスのサービス識別子である「通話１」と、Ｗｅｂシステム１０５から提供されたＷｅｂサービスのサービス識別子である「Ｗｅｂ１」とが含まれる。つまり、上述した課題に記載した「課金要求」と「関連付け登録」とを同時に行うＡＰＩを準備することとなる。これにより、図７に示したシーケンス図を用いて説明した一般的な課金処理におけるステップＳ９０２のような、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅがどのサービス利用に対応しているかをデータベースの中から検索する処理を行う必要がなくなり、アプリケーション１２１がミドルウェア１２２を呼び出す回数が１回で済む。
【００５４】
Ｒｅｆｅｒｅｎｃｅ  ＣｏｄｅとＣｏｎｆｉｒｍａｔｉｏｎＲｅｆとがアプリケーションインタフェース部２０１にて受信されると、オペレーション識別部２０２にて、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが何のオペレーションを示すものであるのかが識別される。この識別方法は一般的に用いられる方法であれば良い。ここでは、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが課金要求であることが識別される。
【００５５】
また、識別子抽出部２０３にて、ＣｏｎｆｉｒｍａｔｉｏｎＲｅｆに含まれるサービス識別子が抽出される。ここでは、「ｓｍｓ１」と、「通話１」と、「Ｗｅｂ１」とが抽出される。
【００５６】
その後、出力部２０４から通信部１２０を介して、ＳＭＳサービスのサービス識別子「ｓｍｓ１」を用いてミドルウェア１２２から課金システム１０６へＳＭＳサービスの課金要求が行われる（ステップＳ２）。また、出力部２０４から通信部１２０を介して、通話サービスのサービス識別子「通話１」を用いてミドルウェア１２２から課金システム１０６へ通話サービスの課金要求が行われる（ステップＳ３）。また、出力部２０４から通信部１２０を介して、Ｗｅｂサービスのサービス識別子「Ｗｅｂ１」を用いてミドルウェア１２２から課金システム１０６へＷｅｂサービスの課金要求が行われる（ステップＳ４）。
【００５７】
また、以下に、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが、払い戻し要求の管理番号が示されるものである場合（ｒｅｆｕｎｄＡｍｏｕｎｔ）を例に挙げて説明する。
【００５８】
図４は、図１に示した形態における課金処理方法のうち払い戻し要求の処理を説明するためのシーケンス図である。
【００５９】
利用者装置１０１にサービスを提供するために、ＳＭＳシステム１０３と、通話システム１０４と、Ｗｅｂシステム１０５とを利用した後、何らかの原因で払い戻しが発生した場合、アプリケーション１２１から払い戻し要求がミドルウェア１２２に対して行われる（ステップＳ１１）。このとき、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅに、ＣｏｎｆｉｒｍａｔｉｏｎＲｅｆとして、「ｓｍｓ１」と、「通話１」と、「Ｗｅｂ１」との識別子が含まれる。
【００６０】
Ｒｅｆｅｒｅｎｃｅ  ＣｏｄｅとＣｏｎｆｉｒｍａｔｉｏｎＲｅｆとがアプリケーションインタフェース部２０１にて受信されると、オペレーション識別部２０２にて、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが何のオペレーションを示すものであるのかが識別される。この識別方法は一般的に用いられる方法であれば良い。ここでは、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが払い戻し要求であることが識別される。
【００６１】
また、識別子抽出部２０３にて、ＣｏｎｆｉｒｍａｔｉｏｎＲｅｆに含まれるサービス識別子が抽出される。ここでは、「ｓｍｓ１」と、「通話１」と、「Ｗｅｂ１」とが抽出される。
【００６２】
その後、出力部２０４から通信部１２０を介して、ＳＭＳサービスのサービス識別子「ｓｍｓ１」を用いてミドルウェア１２２から課金システム１０６へＳＭＳサービスの払い戻し要求が行われる（ステップＳ１２）。また、出力部２０４から通信部１２０を介して、通話サービスのサービス識別子「通話１」を用いてミドルウェア１２２から課金システム１０６へ通話サービスの払い戻し要求が行われる（ステップＳ１３）。また、出力部２０４から通信部１２０を介して、Ｗｅｂサービスのサービス識別子「Ｗｅｂ１」を用いてミドルウェア１２２から課金システム１０６へＷｅｂサービスの払い戻し要求が行われる（ステップＳ１４）。
【００６３】
これにより、課金要求を行った場合と同様の効果が得られる。
【００６４】
また、以下に、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが、分割課金要求の管理番号が示されるものである場合（ｃｈａｒｇｅＳｐｌｉｔＡｍｏｕｎｔ）を例に挙げて説明する。
【００６５】
図５は、図１に示した形態における課金処理方法のうち分割課金要求の処理を説明するためのシーケンス図である。
【００６６】
利用者装置１０１にサービスを提供するために、ＳＭＳシステム１０３と、通話システム１０４と、Ｗｅｂシステム１０５とを利用した後、アプリケーション１２１から分割課金要求がミドルウェア１２２に対して行われる（ステップＳ２１）。このとき、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅに、ＣｏｎｆｉｒｍａｔｉｏｎＲｅｆとして、「ｓｍｓ１」と、「通話１」と、「Ｗｅｂ１」との識別子が含まれる。
【００６７】
Ｒｅｆｅｒｅｎｃｅ  ＣｏｄｅとＣｏｎｆｉｒｍａｔｉｏｎＲｅｆとがアプリケーションインタフェース部２０１にて受信されると、オペレーション識別部２０２にて、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが何のオペレーションを示すものであるのかが識別される。この識別方法は一般的に用いられる方法であれば良い。ここでは、Ｒｅｆｅｒｅｎｃｅ  Ｃｏｄｅが分割課金要求であることが識別される。
【００６８】
また、識別子抽出部２０３にて、ＣｏｎｆｉｒｍａｔｉｏｎＲｅｆに含まれるサービス識別子が抽出される。ここでは、「ｓｍｓ１」と、「通話１」と、「Ｗｅｂ１」とが抽出される。
【００６９】
その後、出力部２０４から通信部１２０を介して、ＳＭＳサービスのサービス識別子「ｓｍｓ１」を用いてミドルウェア１２２から課金システム１０６へＳＭＳサービスの分割課金要求が行われる（ステップＳ２２）。また、出力部２０４から通信部１２０を介して、通話サービスのサービス識別子「通話１」を用いてミドルウェア１２２から課金システム１０６へ通話サービスの分割課金要求が行われる（ステップＳ２３）。また、出力部２０４から通信部１２０を介して、Ｗｅｂサービスのサービス識別子「Ｗｅｂ１」を用いてミドルウェア１２２から課金システム１０６へＷｅｂサービスの分割課金要求が行われる（ステップＳ２４）。
【００７０】
これにより、課金要求を行った場合と同様の効果が得られる。
【００７１】
なお、二重課金が発生した場合であっても、上述したようにＣｏｎｆｉｒｍａｔｉｏｎＲｅｆにサービス実施の確証を行うための識別子が含まれることにより、二重となったサービスを特定することができるという効果も有する。
【図面の簡単な説明】
【００７２】
【図１】本発明のＡＰＩが搭載された装置の実施に一形態を示す図である。
【図２】図１に示したＷｅｂサービスプロバイダ装置の内部の一構成例を示す図である。
【図３】図１に示した形態における課金処理方法のうち課金要求の処理を説明するためのシーケンス図である。
【図４】図１に示した形態における課金処理方法のうち払い戻し要求の処理を説明するためのシーケンス図である。
【図５】図１に示した形態における課金処理方法のうち分割課金要求の処理を説明するためのシーケンス図である。
【図６】一般的なサービス提供システムの一例を示す図である。
【図７】図６に示したサービス提供システムにおける一般的な課金処理を説明するためのシーケンス図である。
【符号の説明】
【００７３】
１０１    利用者装置
１０２    Ｗｅｂサービスプロバイダ装置
１０３    ＳＭＳシステム
１０４    通話システム
１０５    Ｗｅｂシステム
１０６    課金システム
１２０    通信部
１２１    アプリケーション
１２２    ミドルウェア
２０１    アプリケーションインタフェース部
２０２    オペレーション識別部
２０３    識別子抽出部
２０４    出力部
【図１】
2009276972.tif 000003
【図２】
2009276972.tif 000004
【図３】
2009276972.tif 000005
【図４】
2009276972.tif 000006
【図５】
2009276972.tif 000007
【図６】
2009276972.tif 000008
【図７】
2009276972.tif 000009